JP2024071177A - 蓄電装置の管理方法及び管理システム、並びにコンピュータ装置 - Google Patents

Abstract

【課題】車両事故発生時に、車両が備える蓄電装置の所有者に事故の発生を的確に知らせる。【解決手段】蓄電装置の管理方法が、蓄電装置を備える車両について事故が発生したことを示す情報を取得した場合に、当該車両を含む複数の車両に関する情報を管理するデータ管理装置から、蓄電装置の所有者を示す第１所有者情報を取得すること（Ｓ２１）と、取得された第１所有者情報を用いて、蓄電装置の所有者を特定すること（Ｓ２２）と、特定された蓄電装置の所有者の端末に対して、当該蓄電装置を備える車両の事故発生を知らせる通知を行うこと（Ｓ２３）とを含む。【選択図】図６

Description

本開示は、蓄電装置の管理方法及び管理システム、並びにコンピュータ装置に関する。

特開２０２２－０６４５２７号公報（特許文献１）には、車両に加えられた衝撃の大きさを検知する衝撃検知センサによって所定値以上の衝撃が検知された場合に、補機バッテリを駆動電源とする電子制御ユニットが電池モジュールの予め選択した電池セルのみを低電圧化制御する技術が開示されている。

特開２０２２－０６４５２７号公報

近年、世界各国で車両の電動化が進められており、「ＣＡＳＥ」と呼ばれる４つの分野（コネクティッド、自動化、シェアリング、電動化）の技術が特に注目されている。車両をユーザに貸し出す車両リースサービス（車両シェアリングサービスを含む）も、その１つである。しかしながら、上記特許文献１では、貸し出された車両について事故が発生すること、あるいは、貸し出された蓄電装置が搭載された車両について事故が発生することについては、十分な検討がなされていない。詳しくは、特許文献１に記載の技術によれば、車両のユーザが事故の発生を知ることはできるが、蓄電装置が貸し出されたものである場合に蓄電装置の所有者が事故の発生を知ることは困難である。

本開示は、上記課題を解決するためになされたものであり、その目的は、車両事故発生時に、車両が備える蓄電装置の所有者に事故の発生を的確に知らせることである。

本開示の第１観点に係る形態に従うと、以下に示す蓄電装置の管理方法が提供される。
（第１項）当該蓄電装置の管理方法は、蓄電装置を備える車両（以下、「対象車両」とも称する）について事故が発生したことを示す情報を取得した場合に、対象車両を含む複数の車両に関する情報を管理するデータ管理装置から、対象車両の蓄電装置の所有者を示す第１所有者情報を取得することと、取得された第１所有者情報を用いて、対象車両の蓄電装置の所有者を特定することと、特定された蓄電装置の所有者の端末に対して、当該蓄電装置を備える対象車両の事故発生を知らせる通知を行うこととを含む。

上記管理方法では、対象車両について事故が発生した場合に、その対象車両が備える蓄電装置の所有者が特定される。そして、蓄電装置の所有者の端末に対して、当該蓄電装置を備える対象車両の事故発生を知らせる通知が行われる。これにより、車両事故発生時に、対象車両が備える蓄電装置の所有者に事故の発生を的確に知らせることが可能になる。

上記対象車両は、電力を動力源の全てまたは一部として利用する電動車（ｘＥＶ）であってもよい。ｘＥＶの例としては、ＢＥＶ（電気自動車）、ＨＥＶ（ハイブリッド車）、ＰＨＥＶ（プラグインハイブリッド車）、ＦＣＥＶ（燃料電池車）などが挙げられる。

上記第１項に記載の方法は、以下に示す第２項に記載の構成を有し得る。
（第２項）第１項に記載の蓄電装置の管理方法が以下の特徴をさらに有する。データ管理装置は、複数の車両の各々に関して車載蓄電装置と車体部分との各々の所有者を示す情報を管理している。当該管理方法は、対象車両と他の車両との間で事故が発生したことを示す情報を取得した場合に、データ管理装置から、対象車両の蓄電装置の所有者を示す第１所有者情報と、他の車両の車体部分の所有者を示す第２所有者情報とを取得することと、取得された第２所有者情報を用いて、他の車両のユーザを特定することと、特定された他の車両のユーザの端末に対して、対象車両の蓄電装置の所有者を知らせる通知を行うこととを含む。

上記方法によれば、事故相手（他の車両のユーザ）に、対象車両の蓄電装置の所有者を知らせることができる。このため、事故によって対象車両の蓄電装置が損傷を受けた場合に、事故相手と対象車両の蓄電装置の所有者との間で損害賠償に関する交渉を行いやすくなる。

車両ユーザには、例えば、次に示す３種類の利用形態（部分リース／全部リース／全部所有）のいずれかの利用形態の車両が提供されてもよい。部分リースは、車体部分（蓄電装置を除く部分）がユーザの所有物であり、かつ、蓄電装置がリースによってユーザに提供されている利用形態である。全部リースは、車体部分と蓄電装置との両方がリースによってユーザに提供されている利用形態である。全部所有は、車体部分と蓄電装置との両方がユーザの所有物である利用形態である。

他の車両の利用形態が部分リースまたは全部所有である場合には、第２所有者情報から直接的に他の車両のユーザを特定できる。他の車両の利用形態が全部リースである場合には、例えば第２所有者情報を用いてリース事業者（他の車両の車体部分の所有者）に問い合わせることで、他の車両のユーザを特定できる。

ある形態に従うと、第１項または第２項に記載の蓄電装置の管理方法をコンピュータに実行させるプログラムが提供される。他の形態においては、そのプログラムを配信するコンピュータ装置が提供される。

本開示の第２観点に係る形態に従うと、以下に示すコンピュータ装置が提供される。
（第３項）当該コンピュータ装置は、プロセッサと、第１項または第２項に記載の蓄電装置の管理方法をプロセッサに実行させるプログラムを記憶する記憶装置とを備える。

上記のコンピュータ装置によれば、前述した蓄電装置の管理方法が好適に実行される。
本開示の第３観点に係る形態に従うと、以下に示す蓄電装置の管理システムが提供される。

（第４項）当該蓄電装置の管理システムは、第３項に記載のコンピュータ装置と、データ管理装置とを含む。データ管理装置は、分散型台帳を記憶する記憶装置と、複数の車両の各々に関して車載蓄電装置の所有者を示す情報を含むトランザクションデータを分散型台帳に登録する制御装置とを備える。

上記システムでは、分散型台帳技術（ＤＬＴ：Distributed Ledger Technology）を利用してデータを管理するため、データ改ざんを抑制できる。現状において、各国の当局が提供する車両の公証情報（自動車検査登録情報など）には、車載蓄電装置の所有者を示す情報が含まれていない。上記システムでは、セキュアなデータ管理が可能になるため、当局が提供する情報に準ずる信頼性の高い所有者情報をコンピュータ装置に提供することが可能になる。こうした所有者情報は、第三者対抗要件を満たし得る。制御装置は、電子公証を受けた情報のみを分散型台帳に登録してもよい。

上記第４項に記載の蓄電装置の管理システムは、以下に示す第５項または第６項に記載の構成を有し得る。

（第５項）第４項に記載の管理システムが以下の特徴をさらに有する。上記コンピュータ装置は、車両用の蓄電装置の損傷に関する保険サービスを提供する第１サーバである。事故が発生した車両は、事故発生を知らせる事故発生信号と、蓄電装置の損傷度合いを示す損傷情報と、事故が発生したときの車両の状況を示す事故データとを送信するように構成される。第１サーバは、事故発生信号を受信した場合に、事故データに基づいて、事故に関する車両のユーザの過失度合いを決定することと、損傷情報と過失度合いとに基づいて、保険サービスによって支払われる保険金を決定することとを実行するように構成される。

上記システムによれば、蓄電装置の損傷度合いと、事故に関する車両ユーザの過失度合いとに基づいて、保険金が適切に決定されやすくなる。また、車両ユーザが保険サービスを受けやすくなる。

第１サーバは、決定された保険金を、後述する第２サーバと、事故が発生した車両のユーザ端末との少なくとも一方へ送信してもよい。ユーザ端末は、車両に搭載された車載端末であってもよいし、車両のユーザが携帯する携帯端末であってもよい。ユーザ端末は、予め車両に紐付けて第１サーバと第２サーバとの少なくとも一方に登録されてもよい。

（第６項）第４項または第５項に記載の管理システムが以下の特徴をさらに有する。当該管理システムは、車両用の蓄電装置の交換を行う複数の交換ステーションをさらに含む。蓄電装置の所有者の端末は、車両用の蓄電装置を貸し出すリースサービスを提供する第２サーバである。第２サーバは、車両の事故発生を知らせる通知を受けた場合に、１つ以上の交換ステーションに対して蓄電装置の交換を許可するように構成される。

上記システムによれば、対象車両について事故が発生した場合に、その対象車両に搭載された蓄電装置を交換ステーションで交換しやすくなる。

本開示によれば、車両事故発生時に、車両が備える蓄電装置の所有者に事故の発生を的確に知らせることが可能になる。

本開示の実施の形態に係る蓄電装置の管理システムの概要について説明するための図である。 図１に示したデータ管理装置の構成を説明するための図である。 ＤＡＧ（Directed Acyclic Graph）データの一例を示す図である。 ブロックチェーンデータの一例を示す図である。 図１に示した車両の構成について説明するための図である。 本開示の実施の形態に係る蓄電装置の管理方法における事故発生時の制御を示すフローチャートである。 本開示の実施の形態に係る管理方法において、保険サービスの提供に係る処理を示すフローチャートである。 本開示の実施の形態に係る蓄電装置の管理方法において、リース事業者のサーバによって実行されるバッテリ交換に係る制御を示すフローチャートである。 本開示の実施の形態に係る蓄電装置の管理方法において、対象車両と交換ステーション端末とが実行するバッテリ交換に係る制御を示すフローチャートである。 本開示の実施の形態に係る交換ステーションの構成および動作について説明するための図である。

本開示の実施の形態について、図面を参照しながら詳細に説明する。図中、同一または相当部分には同一符号を付してその説明は繰り返さない。

図１は、この実施の形態に係る蓄電装置の管理システムの概要について説明するための図である。図１に示す管理システムは、ディーラ１００と、バッテリ交換ステーション（以下、「ＢＳｔａ」と表記する）２００と、管理センタ５００と、保険サーバ６００とを含む。

管理センタ５００は、複数のノード５１０と、サーバ５２０とを含む。この実施の形態では、ディーラ１００およびＢＳｔａ２００の各々にノード５１０が設置される。以下では、ディーラ１００に設置されたノード５１０を「ノード５１０Ａ」、ＢＳｔａ２００に設置されたノード５１０を「ノード５１０Ｂ」と称する。ただし、これらを区別しない場合には、「ノード５１０」と総称する。ノード５１０Ａ，５１０Ｂは、どちらも後述の図２に示す構成を有する。ただし、ノード５１０Ａ，５１０Ｂは、設置場所（ディーラ１００、ＢＳｔａ２００）および用途に合わせて別々にカスタマイズされてもよい。

サーバ５２０は、車両用（例えば、ｘＥＶ用）の蓄電装置を貸し出すリースサービスを提供するサーバである。サーバ５２０は、リースサービスに関する情報を管理する。サーバ５２０は、例えば自動車メーカに帰属する。この実施の形態では、自動車メーカがリース事業者を兼ねる。保険サーバ６００は、車両用（例えば、ｘＥＶ用）の蓄電装置の損傷に関する保険サービスを提供するサーバである。この保険サービスは、車両に搭載された蓄電装置の損傷に対する補償を行うサービスである。保険サーバ６００は、保険サービスに関する情報を管理する。保険サーバ６００は、例えば保険業者に帰属する。保険サーバ６００は、サーバ５２０と連携して、上記リースサービスによって貸し出された蓄電装置の損傷に関する保険サービスを提供する。保険サーバ６００、サーバ５２０は、それぞれ本開示に係る「第１サーバ」、「第２サーバ」の一例に相当する。

上記リースサービスでは、部分リース方式と全部リース方式とを含む複数種のリース方式が採用される。部分リース方式は、車両用の蓄電装置のみを貸し出すリース方式である。部分リース方式によって蓄電装置の貸出しを受けるユーザは、車両のうち蓄電装置を除く部分（車体部分）を自ら用意する。ユーザは、リース事業者から借りた蓄電装置を、ユーザ自身が所有する車体に搭載することができる。車体に蓄電装置が搭載されることによってｘＥＶは走行可能になる。部分リースの契約が終了したら、ユーザは蓄電装置だけをリース事業者に返却する。一方、全部リース方式では、車両全部（すなわち、車体部分および蓄電装置の両方）を貸し出すリース方式である。全部リースの契約が終了したら、ユーザは蓄電装置だけでなく車両全部をリース事業者に返却する。

自動車メーカは、ディーラ１００を通じて車両を販売またはリースする。ディーラ１００は、自動車メーカが製造した車両を販売するだけでなく、前述のリースサービスを提供する。ディーラ１００は、自動車メーカから提供される車体および蓄電装置の少なくとも一方を貸し出す。ディーラ１００は、例えば、部分リース方式によって図１に示す車両１０Ａの蓄電装置１２Ａをユーザに貸し出してもよい。この場合、車両１０Ａは部分リース車両（以下、「車両Ａ」と表記する場合がある）に相当し、車両１０Ａの車体１１Ａはユーザの所有物になる。そして、車両１０Ａの蓄電装置１２Ａは、リースによってユーザに提供され、自動車メーカの所有物になる。また、ディーラ１００は、例えば、全部リース方式によって図１に示す車両１０Ｂをユーザに貸し出してもよい。この場合、車両１０Ｂは全部リース車両（以下、「車両Ｂ」と表記する場合がある）に相当する。そして、車両１０Ｂの全部（車体１１Ｂおよび蓄電装置１２Ｂ）が、リースによってユーザに提供され、自動車メーカの所有物になる。また、ディーラ１００は、例えば、図１に示す車両１０Ｃをユーザに販売してもよい。この場合、車両１０Ｃは販売車両（以下、「車両Ｃ」と表記する場合がある）に相当する。そして、車両１０Ｃの全部（車体１１Ｃおよび蓄電装置１２Ｃ）が、ユーザに販売され、ユーザの所有物になる。

この実施の形態では、ディーラ１００が車両ユーザに請求するリース料金（例えば、毎月のリース料金）に保険料が含まれている。すなわち、車両Ａ，Ｂは、保険サーバ６００が提供する保険（より特定的には、蓄電装置の損傷に関する保険）に加入することになる。車両Ａ，Ｂの各々に関しては、当該車両に搭載された蓄電装置が損傷したときに保険が適用される。保険サービスにより、蓄電装置の損傷に対する補償が行われる。詳細は後述するが、保険サーバ６００は、保険サービスによって支払われる保険金を決定し、決定された保険金をサーバ５２０に通知する。決定された保険金は、保険業者からリース事業者に支払われる。そして、蓄電装置の損傷による損失額が保険金よりも大きい場合には、リース事業者が車両ユーザに差額を請求する。上記保険はリース向けであるため、車両Ｃは上記保険には加入しない。ただし、車両Ｃは別の保険に加入してもよい。

ＢＳｔａ２００は、車両用（例えば、ｘＥＶ用）の蓄電装置の交換を行うように構成される。ＢＳｔａ２００のノード５１０Ｂは、例えば有線で通信ネットワークＮＷと接続される。この実施の形態では、蓄電装置としてバッテリ（より特定的には、二次電池）が採用される。ただし、蓄電装置は、電力を貯蔵できる装置であればよく、蓄電装置の例としては、二次電池のほか、大容量キャパシタなどが挙げられる。

この実施の形態に係る蓄電装置の管理システムは複数のディーラ１００を含む。これらのディーラ１００は、当該管理システムの管轄エリアの全域をカバーする販売／リース拠点のネットワークが構築されるように、管轄エリア内の各拠点に設置される。さらに、当該管理システムは複数のＢＳｔａ２００を含む。これらのＢＳｔａ２００は、当該管理システムの管轄エリアの全域をカバーするバッテリ交換拠点のネットワークが構築されるように、管轄エリア内の各拠点に設置される。また、各ＢＳｔａ２００は、車両修理工場として機能してもよい。各ＢＳｔａ２００は、車体の修理を行うように構成されてもよい。ディーラ１００とＢＳｔａ２００とが同じ場所（または近隣）に設置されてもよい。

保険サーバ６００は、プロセッサ６１０、記憶装置６２０、および通信モジュール６３０を備える。プロセッサ６１０は、例えばＣＰＵ（Central Processing Unit）を含む。記憶装置６２０は、格納された情報を保存可能に構成される。記憶装置６２０はＨＤ（ハードディスク）ドライブまたはＳＳＤ（Solid State Drive）を含んでもよい。通信モジュール６３０は、例えば有線で通信ネットワークＮＷと接続される。各ノード５１０とサーバ５２０と保険サーバ６００とは通信ネットワークＮＷを介して相互に通信可能に構成される。通信ネットワークＮＷは、例えばインターネットと無線基地局とによって構築される広域ネットワークである。通信ネットワークＮＷは携帯電話網を含んでもよい。

管理センタ５００は、分散型台帳技術を用いて、複数の車両に関する情報を管理するデータ管理装置である。分散型台帳には、分散型台帳の運用が開始されてから現在までの全ての情報が記録される。図２は管理センタ５００の構成を説明するための図である。

図２を参照して、管理センタ５００は、分散型台帳ネットワーク（以下、「ＤＬＮ」と表記する）を形成する複数のノード５１０と、各ノード５１０と通信可能なサーバ５２０とを含む。各ノード５１０は認証局８００と通信可能に構成される。サーバ５２０は、プロセッサ５２１、記憶装置５２２、および通信モジュール５２３を備える。図２には４つのノード５１０を示しているが、ノード５１０の数は適宜変更可能である。

この実施の形態に係るノード５１０は、定置型コンピュータ（例えば、サーバ）である。ノード５１０は、制御装置５１１と、記憶装置５１２と、通信装置５１５と、入力装置５１６と、表示装置５１７とを含み、これらはバス５１８に接続されている。

制御装置５１１は、例えば、図示しないプロセッサ、ＲＯＭ（Read Only Memory）、およびＲＡＭ（Random Access Memory）を備え、情報処理可能に構成される。記憶装置５１２は、例えばハードディスクまたはフラッシュメモリを含み、情報を保存可能に構成される。記憶装置５１２は、制御装置５１１のプロセッサに実行されるプログラムのほか、プログラムで使用される情報を記憶する。通信装置５１５は、通信ネットワークＮＷ（図１）と接続されている。制御装置５１１は、通信装置５１５を通じて、外部の装置と情報をやり取りする。通信装置５１５は、他のノード５１０、サーバ５２０、および認証局８００の各々と通信可能に構成される。入力装置５１６は、ユーザから入力された情報（例えば、指示またはパラメータ値）を制御装置５１１に伝える。表示装置５１７は、制御装置５１１からの制御指令に従い、情報をユーザに表示する。

記憶装置５１２は、制御装置５１１により生成された一対の秘密鍵および公開鍵と、認証局８００から発行された電子証明書とをさらに記憶する。具体的には、制御装置５１１は、秘密鍵およびこれと対をなす公開鍵を生成し、生成された公開鍵を認証局８００に送信する。認証局８００は、認証機関に帰属するサーバを含む。認証局８００は、ノード５１０（電子証明書の申請者）から受けた公開鍵に対して電子証明書を生成し、公開鍵を含む電子証明書をノード５１０に発行する。ノード５１０は、発行された電子証明書をＤＬＮに送信する。電子証明書は、後述する電子署名の有効性の検証で用いられる。

管理センタ５００によるデータ管理においては、ＤＡＧ（Directed Acyclic Graph）を利用した分散型台帳技術が採用されてもよい。こうした形態では、サーバ５２０の記憶装置５２２と各ノード５１０の記憶装置５１２とが、以下に説明するＤＡＧデータを記憶する。図３は、ＤＡＧデータの一例を示す図である。

図３に示すように、ＤＡＧデータは、１つのトランザクションデータを一方向に、かつ、複数に、かつ、巡回しないように繋いだ構成を有する。ＤＬＮを形成する各ノード５１０の記憶装置５１２がＤＡＧデータを記憶する。これにより、データの改ざんが抑制される。あるユーザによってＤＡＧデータが改ざんされたとしても、他の複数のユーザが保有するＤＡＧデータを基準としてすぐに改ざんが検知される。

図３に示す例では、各トランザクションデータが、それよりも前に発生した２つのトランザクションに対応するトランザクションデータと繋がっている。すなわち、各トランザクションデータは、過去のトランザクションに係るデータのハッシュ値を含む。以下では、図３中のトランザクションデータＴＤ１１～ＴＤ１６をそれぞれ、単に「ＴＤ１１」～「ＴＤ１６」と表記する。図３に示すＤＡＧデータにおいては、ＴＤ１３に対応するトランザクションがＴＤ１１，ＴＤ１２の各々に対応するトランザクションよりも新しく、ＴＤ１４～ＴＤ１６の各々に対応するトランザクションがＴＤ１３に対応するトランザクションよりも新しい。以下、新たな情報（例えば、後述する所有者情報）をＤＡＧデータに追加する手順について説明する。

図２，図３を参照して、まず、ノード５１０のユーザが、入力装置５１６を操作して、新たに追加する情報に関するデータ（以下、「対象データ」と称する）をサーバ５２０の記憶装置５２２に記憶させる。この処理（データ追加に係るトランザクション）に応じて、ノード５１０は、この処理（トランザクション）に対応するＴＤ１３を生成する。制御装置５１１は、例えば次に示す方法によって電子署名付きの対象データを含むＴＤ１３を生成してもよい。

制御装置５１１は、サーバ５２０から対象データを取得して、ハッシュ関数を用いて対象データをハッシュ化する。続けて、制御装置５１１は、記憶装置５１２から秘密鍵を読み出し、秘密鍵を用いて電子署名を生成する。続けて、制御装置５１１は、秘密鍵を用いて、上記ハッシュ化された対象データを暗号化することで、電子署名付きの対象データを含むＴＤ１３を生成する。契約内容を示す対象データには、契約を結ぶ複数人の電子署名が付加されてもよい。ＤＬＮにおける他のノード５１０は、暗号化された電子署名を、電子証明書に含まれる公開鍵（詳しくは、上記秘密鍵と対をなす公開鍵）を用いて復号し、復号の結果に基づいて電子署名の有効性を検証してもよい。ただし、対象データを含むトランザクションデータの生成において、対象データに対して電子署名を行うことは必須ではない。

ノード５１０は、ＴＤ１３を生成するときに、過去のトランザクションデータの中から、例えばＴＤ１１，ＴＤ１２を選択し、選択されたＴＤ１１，ＴＤ１２の内容を検証する。選択方法は、過去のトランザクションデータの中からランダムに選択する方法であってもよいし、例えばマルコフ連鎖モンテカルロ法のような選択アルゴリズムを用いた選択方法であってもよい。検証の手法は、トランザクションデータに含まれる電子署名を用いた検証手法でもよいし、他の公知の検証手法であってもよい。ノード５１０は、ＴＤ１１，ＴＤ１２が直接的または間接的に承認しているトランザクションデータを遡って検証してもよい。

ノード５１０は、上記検証の結果、不正なトランザクションデータがなければ、検証したＴＤ１１，ＴＤ１２をそれぞれハッシュ化し、これらのハッシュ値をＴＤ１３に含める。これらのハッシュ値がＴＤ１３に含まれることは、ＴＤ１３の生成時にノード５１０がＴＤ１１，ＴＤ１２を承認したことを意味する。また、生成されたＴＤ１３には、上記対象データ（新たな情報に関するデータ）のハッシュ値がさらに含まれる。このハッシュ値は、ノード５１０がハッシュ関数を用いて対象データ（例えば、ドキュメントデータ）をハッシュ化した結果として得られる数値である。

続けて、ノード５１０は、上記のように生成され、検証され、承認されたＴＤ１３をＤＬＮへ送信する。これにより、ＴＤ１３がＤＡＧデータに追加される。ＤＡＧデータの更新された部分は、ＤＬＮにおける各ノード５１０が分散型台帳（例えば、コンソーシアム分散型台帳）に書き込む。これにより、新規のトランザクションデータが分散型台帳に登録される。

ノード５１０は、認証局８００から、生成されたＴＤ１３（対象データを含む）に対するタイムスタンプトークンを取得してもよい。認証局８００は、ノード５１０からの要求に応じて、国際標準時に追跡性がある時刻源に基づく時刻情報を結合させたタイムスタンプトークンを発行してもよい。制御装置５１１は、ハッシュ関数を用いてタイムスタンプトークンをハッシュ化して、ハッシュ化されたタイムスタンプトークンを分散型台帳（例えば、ＤＡＧデータ）に登録してもよい。このタイムスタンプトークンにより、対象データがその時刻に分散型台帳に存在していることを証明することができる。

ＤＡＧデータに追加されたＴＤ１３は、後に他のノード５１０によって、上記のように検証され、承認される。図３に示す例では、ＴＤ１３がＴＤ１４，ＴＤ１６の各々に承認されている。なお、ＤＡＧデータにおける各トランザクションデータに累積荷重が設定されてもよい。累積荷重は、当該トランザクションデータが有効である確率を示す。累積荷重は、例えば、当該トランザクションデータを承認している他のトランザクションデータの数を示してもよい。

管理センタ５００によるデータ管理においては、ブロックチェーン（以下、「ＢＬＣ」と表記する）を利用した分散型台帳技術が採用されてもよい。こうした形態では、サーバ５２０の記憶装置５２２と各ノード５１０の記憶装置５１２とが、以下に説明するＢＬＣデータを記憶する。図４は、ＢＬＣデータの一例を示す図である。

図４に示すように、ＢＬＣデータは、ひと繋ぎの複数のブロックで構成される。図４中のブロックＢＤ１１～ＢＤ１３は、右側に進むほど新しい。これらを古いほうから順に並べると、ブロックＢＤ１１，ＢＤ１２，ＢＤ１３となる。ＢＬＣデータは、トランザクションの履歴を示す。ＤＬＮを形成する各ノード５１０の記憶装置５１２がＢＬＣデータを記憶する。これにより、データの改ざんが抑制される。以下、新たな情報をＢＬＣデータに追加する手順について説明する。

図２，図４を参照して、まず、ノード５１０のユーザが、入力装置５１６を操作して、対象データ（新たな情報に関するデータ）をサーバ５２０の記憶装置５２２に記憶させる。この処理（データ追加に係るトランザクション）に応じて、ノード５１０が、この処理（トランザクション）に対応するトランザクションデータを生成する。具体的には、ノード５１０は、ハッシュ関数を用いて対象データをハッシュ化し、ハッシュ化の結果として得られる数値（ハッシュ値）を含むトランザクションデータを生成する。制御装置５１１は、前述した手順で電子署名付きの対象データを含むトランザクションデータを生成してもよい。

ノード５１０は、上記のようにして生成したトランザクションデータをＤＬＮに送信する。このトランザクションデータは、未認証であり、新規のブロックＢＤ１３に纏められる。トランザクションデータは、ＤＬＮに流れただけでは有効なものとは認められない。トランザクションデータは、ＤＬＮにおける各ノード５１０に保持される分散型台帳（ＢＬＣデータ）に追加されて初めて有効となる。

所定の要件が満たされた場合に、既存のブロックＢＤ１１，ＢＤ１２に対して新規のブロックＢＤ１３が追加される。例えば、ＰＯＷ（Proof of Work）と呼ばれるマイニング処理によって新規のブロックＢＤ１３がＢＬＣデータに追加される。これにより、新規のトランザクションデータが分散型台帳に登録される。ＰＯＷは、新規のブロックＢＤ１３の追加を複数のノード間で競う仕組みである。ＰＯＷに参加するノードは、一般的にマイナと呼ばれる。新規のブロックＢＤ１３を最も早く生成したマイナには、報酬が与えられる。このような仕組みを用いた合意形成アルゴリズムによって、ＢＬＣデータの耐改ざん性が確保される。

上記のように、管理センタ５００に含まれる各ノード５１０は、例えばＤＡＧまたはＢＬＣを利用した分散型台帳を記憶する記憶装置５１２と、トランザクションデータを分散型台帳に登録する制御装置５１１とを備える。管理センタ５００は、各拠点のディーラ１００が販売またはリースした複数の車両に関する情報（トランザクションデータ）を、車両の識別情報（車両ＩＤ）で区別して記憶している。車両ＩＤはＶＩＮ（Vehicle Identification Number）であってもよい。

この実施の形態では、ディーラ１００が車両を販売またはリースする際に、ディーラ１００のノード５１０Ａが、前述のトランザクションデータを分散型台帳に書き込む。これにより、販売契約またはリース契約に応じた所有者情報および保険情報が分散型台帳に書き込まれる。また、トランザクションデータに対するタイムスタンプトークンが分散型台帳に登録される。

上記トランザクションデータは、車両ＩＤ、仕様情報、所有者情報、保険情報、対象データのハッシュ値、時刻情報、登録者情報、過去のトランザクションデータのハッシュ値、および電子署名を含む。仕様情報は、車両ＩＤによって特定される車両に関して車体部分および蓄電装置の各々の仕様を示す。所有者情報は、車両ＩＤによって特定される車両に関して、その車両に搭載された蓄電装置の所有者と、その車両の車体部分の所有者とを示す。保険情報は、車両が加入した保険およびその保険業者を示す。車両Ａ，Ｂの各々に関する保険情報は、車両ユーザが契約した保険業者の連絡先として保険サーバ６００の通信アドレスを示す。上記電子署名は、例えば、車両ユーザ、リース事業者、および保険業者の各々の電子署名を含む。販売またはリースされた車両に関する車両ＩＤ、仕様情報、所有者情報、および保険情報は、当該車両の記憶装置（例えば、後述の図５に示す記憶装置１１１ｂ）にも書き込まれる。

所有者情報は、所有者の識別情報および連絡先情報を含む。所有者の識別情報は、所有者を特定するための情報（例えば、氏名、法人名、識別番号、識別記号など）を含む。所有者の連絡先情報は、所有者と連絡をとるための情報（例えば、所有者の端末の通信アドレス）を含む。具体的には、車両Ａ（部分リース車両）に関する所有者情報は、車体部分の所有者が車両ユーザ（連絡先は後述の図５に示す携帯端末２０）であり、かつ、蓄電装置の所有者がリース事業者（連絡先はサーバ５２０）であることを示す。車両Ｂ（全部リース車両）に関する所有者情報は、車体部分および蓄電装置の各々の所有者がリース事業者（連絡先はサーバ５２０）であることを示す。車両Ｃ（販売車両）に関する所有者情報は、車体部分および蓄電装置の各々の所有者が車両ユーザ（連絡先は携帯端末２０）であることを示す。

車両に搭載された蓄電装置の所有者（例えば、リース事業者）は、例えば所有証明書によって自身の所有権を第三者に証明することができる。所有者は、１つのノード５１０を用いて、認証局８００から発行された電子証明書を付帯させた所有証明書を作成できる。所有証明書には、例えば、車両ＩＤ、当該車両ＩＤに紐づけられた所有者情報（トランザクションデータ）、電子署名、および時刻情報（タイムスタンプトークン）が含まれる。所有証明書に含まれる所有者情報は、車両ＩＤが示す車両に関して、その車両に搭載された蓄電装置の所有者と、その車両の車体部分の所有者とを示してもよい。所有証明書を作成したノード５１０は、その所有証明書をＤＬＮに送信する。ＤＬＮにおける各ノード５１０は、ある車両に搭載された蓄電装置について、その車両の識別情報（車両ＩＤ）に対応する所有証明書をＤＬＮから取得することで、その蓄電装置の所有者を確認することができる。また、各ノード５１０は、所有証明書に付帯された電子証明書（公開鍵を含む）を用いて、所有証明書の有効性を検証することができる。また、各ノード５１０は、分散型台帳を参照して、車両ＩＤに紐づけられた所有者情報（トランザクションデータ）の履歴を確認することができる。こうした所有者情報は、第三者対抗要件を満たし得る。

以下では、ディーラ１００によって提供された車両を、「車両１０」と称する場合がある。この実施の形態に係る車両１０は、図１に示した車両Ａ，Ｂ，Ｃのいずれかである。図５は、車両１０の構成について説明するための図である。

図５を参照して、車両１０は、車体１１と、車体１１に搭載されたバッテリ１２とを備える。車両１０は、バッテリ１２の電力を用いて走行可能に構成される。車両１０は、例えば内燃機関を備えないＢＥＶである。バッテリ１２としては、公知の車両用蓄電装置（例えば、液式二次電池または全固体二次電池）を採用できる。車両用二次電池の例としては、リチウムイオン電池、ニッケル水素電池が挙げられる。複数の二次電池が組電池を形成してもよい。バッテリ１２は、本開示に係る「蓄電装置」の一例に相当する。

車体１１は、ＥＣＵ１１１と、バッテリＥＣＵ１１２と、ＢＭＳ（Battery Management System）１１２ａと、歪みセンサ１１２ｂと、温調システム１１２ｃと、インレット１１３と、充電器１１４と、ＳＭＲ（System Main Relay）１１５ａと、充電リレー１１５ｂと、ＰＣＵ（Power Control Unit）１１６ａと、ＭＧ（Motor Generator）１１６ｂと、ＨＭＩ（Human Machine Interface）１１７ａと、ナビゲーションシステム（以下、「ＮＡＶＩ」と表記する）１１７ｂと、ドライブレコーダ１１７ｃと、位置センサ１１８ａと、衝撃力センサ１１８ｂと、通信装置１１９とを備える。なお、ＥＣＵは、電子制御装置（Electronic Control Unit）を意味する。車体１１に搭載された各ＥＣＵを含む制御システムには、図示しない補機バッテリから電力が供給される。

ＥＣＵ１１１は、プロセッサ１１１ａと記憶装置１１１ｂとを備えるコンピュータである。記憶装置１１１ｂには、プロセッサ１１１ａに実行されるプログラムのほか、プログラムで使用される情報（例えば、マップ、数式、及び各種パラメータ）が記憶されている。記憶装置１１１ｂは、車両１０に関する各種情報をさらに保有する。これらの情報は車両１０の状況に応じて更新される。図５にはバッテリＥＣＵ１１２の構成を示していないが、バッテリＥＣＵ１１２も、ＥＣＵ１１１と同様のハードウェア構成を有するコンピュータである。ＥＣＵ１１１とバッテリＥＣＵ１１２とは相互に通信可能に構成される。これらのＥＣＵは、例えばＣＡＮ（Controller Area Network）で接続されている。

ＢＭＳ（Battery Management System）１１２ａは、バッテリ１２の状態（例えば、温度、電流、電圧）を検出するためのセンサを含む。歪みセンサ１１２ｂは、バッテリ１２のケース（バッテリケース）の歪み度合いを検出する。バッテリ１２に加わった衝撃力が大きくなるほどバッテリケースの歪み度合いは大きくなる。歪みセンサ１１２ｂは、ひずみゲージまたは変位センサであってもよい。ＢＭＳ１１２ａおよび歪みセンサ１１２ｂの各々による検出結果は、バッテリＥＣＵ１１２へ出力される。

温調システム１１２ｃは、バッテリ１２の温度調整を行う。温調システム１１２ｃは、ヒータおよび冷却装置の少なくとも一方を含んでもよい。冷却方式は水冷式であってもよい。温調システム１１２ｃは、バッテリＥＣＵ１１２によって制御される。

車両１０は、外部充電（車両外部からの電力によるバッテリ１２の充電）を実行可能に構成される。インレット１１３は、ＥＶＳＥ（Electric Vehicle Supply Equipment）のプラグ（例えば、充電ケーブルのコネクタ）が着脱可能に構成される。充電器１１４は、外部充電のための電力変換回路を含む。充電器１１４はＤＣ／ＤＣ変換回路とＡＣ／ＤＣ変換回路との少なくとも一方を含んでもよい。充電リレー１１５ｂは、充電ラインの接続／遮断を切り替える。図５に示す例では、インレット１１３、充電器１１４、および充電リレー１１５ｂを含む充電ラインが、ＳＭＲ１１５ａとＰＣＵ１１６ａとの間に接続されている。しかしこれに限られず、バッテリ１２とＳＭＲ１１５ａとの間に充電ラインが接続されてもよい。また、図５に示す構成は、外部給電（バッテリ１２から車両外部への給電）を実行できるように変更されてもよい。例えば、図５に示す充電器１１４が充放電器に変更されてもよい。

ＳＭＲ１１５ａは、バッテリ１２からＰＣＵ１１６ａまでの電路の接続／遮断を切り替える。車両１０の走行時には、ＳＭＲ１１５ａが接続状態にされ、充電リレー１１５ｂが遮断状態にされる。バッテリ１２とインレット１１３との間で電力のやり取りが行なわれるときには、ＳＭＲ１１５ａおよび充電リレー１１５ｂの両方が接続状態にされる。充電器１１４、ＳＭＲ１１５ａ、および充電リレー１１５ｂの各々は、バッテリＥＣＵ１１２によって制御される。バッテリＥＣＵ１１２は、ＥＣＵ１１１から制御指令を受ける。

ＰＣＵ１１６ａは、バッテリ１２から供給される電力を用いてＭＧ１１６ｂを駆動する。ＰＣＵ１１６ａは、例えばインバータおよびＤＣ／ＤＣコンバータを含む。ＰＣＵ１１６ａは、ＥＣＵ１１１によって制御される。ＭＧ１１６ｂは、車両１０の走行用モータとして機能する。ＭＧ１１６ｂは、ＰＣＵ１１６ａによって駆動され、車両１０の駆動輪を回転させる。また、ＭＧ１１６ｂは、車両１０の制動時に回生発電を行ない、発電した電力をバッテリ１２へ出力する。なお、車両１０が備える走行用モータの数は任意である。

ＨＭＩ１１７ａは入力装置および表示装置を含む。ＨＭＩ１１７ａは、タッチパネルディスプレイを含んでもよい。ＨＭＩ１１７ａは、メータパネルおよび／またはヘッドアップディスプレイを含んでもよい。ＨＭＩ１１７ａは、音声入力を受け付けるスマートスピーカを含んでもよい。

ＮＡＶＩ１１７ｂは、タッチパネルディスプレイと、ＧＰＳ（Global Positioning System）センサと、プロセッサと、地図情報を記憶する記憶装置とを含む。地図情報は、地図上に各ディーラ１００および各ＢＳｔａ２００の位置を示す。ＯＴＡ（Over The Air）によって地図情報が逐次更新されてもよい。ＮＡＶＩ１１７ｂは、ＧＰＳセンサを用いて車両１０の位置を検出し、上記地図情報に基づく地図上に、車両１０の位置をリアルタイムで表示する。ＮＡＶＩ１１７ｂは、上記地図情報を参照して、車両１０の現在位置から目的地までの最適ルート（例えば、最短ルート）を見つけるための経路探索を行う。

ドライブレコーダ１１７ｃは、車両１０の周囲の映像を取得するカメラと、カメラが取得した映像を記憶する記憶装置と、車両１０の加速度を検出する加速度センサ（Ｇセンサ）とを含む。ドライブレコーダ１１７ｃは、車両１０の周囲の映像を常時記録している。ただし、記憶装置に記録された映像の情報量が記憶装置の容量を超えると、最新の映像が上書き保存されることにより古い映像が消去される。このため、ドライブレコーダ１１７ｃが取得した映像のうち、長期保存されるべき映像（例えば、後述する事故データ）は、ＥＣＵ１１１（記憶装置１１１ｂ）に保存される。

位置センサ１１８ａは、車両１０の位置を検出する。衝撃力センサ１１８ｂは、車体１１（例えば、ボデーシェル）に加わった衝撃力を検出する。衝撃力センサ１１８ｂは、加速度センサと、ひずみゲージと、変位センサとの少なくとも１つを用いて、上記衝撃力を検出するように構成されてもよい。

通信装置１１９は、無線通信で通信ネットワークＮＷにアクセスするための通信Ｉ／Ｆ（インターフェース）を含む。通信装置１１９は、無線通信を行うＴＣＵ（Telematics Control Unit）またはＤＣＭ（Data Communication Module）を含んでもよい。通信装置１１９は、ノード５１０Ｂおよび携帯端末２０の各々と無線通信を行うための通信Ｉ／Ｆをさらに含む。ＥＣＵ１１１は、通信装置１１９を通じて、サーバ５２０、ノード５１０Ｂ、および携帯端末２０の各々と通信するように構成される。また、ＥＣＵ１１１は通信装置１１９を通じてノード５１０Ａおよび保険サーバ６００の各々と通信してもよい。

携帯端末２０は、ユーザによって持ち運び可能に構成される。携帯端末２０は、車両１０のユーザ（車両管理者）によって携帯されて操作される。この実施の形態では、携帯端末２０として、タッチパネルディスプレイを具備するスマートフォンを採用する。スマートフォンは、コンピュータを内蔵し、スピーカ機能を有する。ただしこれに限られず、携帯端末２０としては、車両１０のユーザが携帯可能な任意の端末を採用可能である。例えば、ラップトップ、タブレット端末、携帯型ゲーム機、ウェアラブルデバイス（スマートウォッチ、スマートグラス、スマートグローブなど）、電子キーも、携帯端末２０として採用可能である。

携帯端末２０には、サーバ５２０が提供するサービスを利用するためのアプリケーションソフトウェア（以下、「モバイルアプリ」と称する）がインストールされている。モバイルアプリにより、携帯端末２０の識別情報（端末ＩＤ）が、対応する車両１０の識別情報（車両ＩＤ）と紐付けられてサーバ５２０に登録される。携帯端末２０は、モバイルアプリを通じて、サーバ５２０と情報のやり取りを行うことができる。なお、携帯端末２０は、保険サーバ６００およびノード５１０の各々と通信可能に構成されてもよい。

車両１０においては、ＥＣＵ１１１が車両全体の統合制御を行う。ＥＣＵ１１１は、車両１０に搭載された各種センサ（位置センサ１１８ａおよび衝撃力センサ１１８ｂを含む）から検出結果を取得する。ＥＣＵ１１１は、バッテリＥＣＵ１１２、ＨＭＩ１１７ａ、ＮＡＶＩ１１７ｂ、ドライブレコーダ１１７ｃ、および通信装置１１９の各々からも情報を取得する。バッテリＥＣＵ１１２は、ＢＭＳ１１２ａの出力に基づいてバッテリ１２の状態（温度、電流、電圧など）を取得し、得られたバッテリ１２の状態をＥＣＵ１１１へ出力する。ＥＣＵ１１１が取得した車両の情報は記憶装置１１１ｂに保存される。

図６は、この実施の形態に係る蓄電装置の管理方法における事故発生時の制御を示すフローチャートである。以下では、フローチャート中の各ステップを、単に「Ｓ」と表記する。

例えば、車両１０のＥＣＵ１１１が起動したときに、起動したＥＣＵ１１１が以下に説明するＳ１１の処理を開始する。ＥＣＵ１１１は、例えば車両１０の起動スイッチの操作に応じて起動する。一般に、起動スイッチは「パワースイッチ」または「イグニッションスイッチ」などと称される。ただし、Ｓ１１の処理が実行される期間は任意である。例えば、ＥＣＵ１１１は、車両１０の走行中にのみ、Ｓ１１の処理を実行してもよい。図６に示す処理においては、Ｓ１１およびそれ以降の処理を実行する車両１０を「対象車両」と称する。

図１，図５とともに図６を参照して、Ｓ１１では、対象車両のＥＣＵ１１１が、当該対象車両について事故発生の有無を判断する。ＥＣＵ１１１は、例えば、衝撃力センサ１１８ｂによって検出された衝撃力が所定の閾値を超える場合に、対象車両について事故が発生したと判断する。この場合、事故前後の対象車両の状況を示す事故データ（例えば、ドライブレコーダ１１７ｃの映像）が記憶装置１１１ｂに保存される。他方、衝撃力センサ１１８ｂによって検出された衝撃力が上記所定の閾値以下である場合には、ＥＣＵ１１１は、対象車両について事故が発生していないと判断する。事故が発生していないと判断された場合には（Ｓ１１にてＮＯ）、処理はＳ１２以降に進まず、Ｓ１１の判断が繰り返される。なお、衝撃力センサ１１８ｂに代えてドライブレコーダ１１７ｃの加速度センサが衝撃力検出に使用されてもよい。

事故が発生したと判断された場合には（Ｓ１１にてＹＥＳ）、対象車両のＥＣＵ１１１が、Ｓ１２において、対象車両に搭載されたバッテリ１２の損傷度合いを求める。この実施の形態では、ＥＣＵ１１１が、バッテリ１２のケースの物理的な損傷度合い（例えば、歪みセンサ１１２ｂによって検出されたバッテリケースの歪み度合い）と、バッテリ１２を監視するシステムに関する通信レベル（例えば、通信の不安定化、通信途絶など）と、バッテリ１２の電気的な部品の損傷度合い（例えば、断線、バスバーの変形など）と、バッテリ１２の環境システムの損傷度合い（例えば、制御不調、故障など）との少なくとも１つに基づいて、バッテリ１２の損傷度合いを求める。この実施の形態では、バッテリＥＣＵ１１２およびＢＭＳ１１２ａの各々が、バッテリ１２を監視するシステムとして機能する。温調システム１１２ｃが、バッテリ１２の環境システムとして機能する。ＥＣＵ１１１は、バッテリ１２の損傷度合いに関する評価項目ごとに損傷度合いを採点し、それら評価項目ごとの点数の合計値を、バッテリ１２の損傷度合い（評価結果）として扱ってもよい。評価項目は、上述の４つの項目（ケース、通信レベル、電気的な部品、および環境システム）であってもよい。

バッテリ１２の損傷度合いの求め方は、上述の方法に限られず、任意の方法を採用可能である。例えば、ＥＣＵ１１１は、事故前後のバッテリ１２の特性変化（例えば、容量維持率の低下度合いまたは内部抵抗の上昇度合い）に基づいて、事故によるバッテリ１２の損傷度合いを算出してもよい。

続けて、対象車両のＥＣＵ１１１が、Ｓ１３において事故に関わる車両を特定する。具体的には、ＥＣＵ１１１は、事故が発生したときの対象車両の状況を示す事故データ（例えば、前述したドライブレコーダ１１７ｃの映像）に基づいて、対象車両だけの単独事故か、あるいは対象車両と他の車両との間での事故かを判定する。他の車両（事故相手の車両）が存在する場合には、ＥＣＵ１１１は、事故相手の車両の識別情報（車両ＩＤ）を取得する。対象車両のＥＣＵ１１１は、事故データから事故相手の車両ＩＤを特定できない場合には、対象車両のユーザ端末（例えば、携帯端末２０）に対して、事故相手の車両ＩＤを特定するための情報の入力を要求してもよい。

続けて、対象車両のＥＣＵ１１１は、Ｓ１４において、事故発生を知らせる事故発生信号と、Ｓ１２で取得したバッテリ１２の損傷度合いを示す損傷情報と、事故が発生したときの対象車両の状況を示す事故データとを、保険サーバ６００へ送信する。事故発生信号は、例えば対象車両の位置センサ１１８ａによって検出された事故発生場所の位置情報と、事故に関わる各車両の識別情報（車両ＩＤ）とを含む。単独事故の場合には、事故発生信号が対象車両のみの識別情報を含む。事故相手の車両が存在する場合には、事故発生信号が、対象車両の識別情報に加えて、事故相手の車両の識別情報をさらに含む。Ｓ１４の処理が実行されると、対象車両による一連の処理が終了する。

保険サーバ６００は、対象車両から上記事故発生信号（Ｓ１４）を受信すると、以下に説明するＳ２１～Ｓ２７の一連の処理を開始する。

Ｓ２１では、保険サーバ６００が、事故発生信号に含まれる車両ＩＤに基づいて、上記事故に関わる各車両の所有者情報を管理センタ５００（より特定的には、管理センタ５００が保有する前述の分散型台帳）から取得する。車両の所有者情報は、当該車両に搭載された蓄電装置の所有者を示す第１所有者情報と、当該車両の車体部分の所有者を示す第２所有者情報とを含む。

続くＳ２２では、保険サーバ６００が、Ｓ２１で取得した対象車両の所有者情報を用いて、対象車両に搭載されたバッテリ１２の所有者を特定する。続けて、保険サーバ６００は、Ｓ２３において、Ｓ２２で特定されたバッテリ１２の所有者の端末に対して、対象車両について事故が発生したことと、事故発生場所の位置とを知らせる通知を行う。対象車両が車両Ａまたは車両Ｂである場合には、保険サーバ６００が、対象車両の所有者情報に基づいてサーバ５２０（バッテリ１２の所有者の端末）の通信アドレスを特定するとともに、サーバ５２０に対して対象車両の事故発生を知らせる上記通知を行う。対象車両が車両Ｃである場合には、保険サーバ６００が、対象車両の所有者情報に基づいて、対象車両に対応する携帯端末２０（バッテリ１２の所有者の端末）の通信アドレスを特定するとともに、携帯端末２０に対して対象車両の事故発生を知らせる上記通知を行う。

この実施の形態では、保険サーバ６００が、上記事故発生信号（対象車両について事故が発生したことを示す情報を含む）を取得した場合に、Ｓ２２，Ｓ２３の処理を実行する。詳しくは、保険サーバ６００は、管理センタ５００から対象車両の第１所有者情報を取得し（Ｓ２１）、取得された第１所有者情報を用いて対象車両の蓄電装置の所有者を特定し（Ｓ２２）、特定された蓄電装置の所有者の端末に対して対象車両の事故発生を知らせる通知を行う（Ｓ２３）。これにより、車両事故発生時に、対象車両が備える蓄電装置の所有者に事故の発生を的確に知らせることが可能になる。

続くＳ２４では、保険サーバ６００が、上記事故発生信号（Ｓ１４）に基づいて、事故相手の車両が存在するか否かを判断する。事故発生信号が単独事故を示す場合は、Ｓ２４においてＮＯと判断され、処理がＳ２７に進む。

上記事故発生信号が単独事故ではないこと（すなわち、事故相手の車両が存在すること）を示す場合には（Ｓ２４にてＹＥＳ）、Ｓ２５において、保険サーバ６００が、Ｓ２１で取得した事故相手の車両の所有者情報を用いて、事故相手の車両のユーザを特定する。例えば、事故相手の車両が車両Ａまたは車両Ｃである場合には、保険サーバ６００は、事故相手の車両の車体部分の所有者を示す情報（第２所有者情報）から直接的に事故相手の車両のユーザを特定する。他方、事故相手の車両が車両Ｂである場合には、保険サーバ６００は、サーバ５２０（車体部分の所有者の端末）から、事故相手の車両のユーザを特定するための情報（例えば、事故相手の車両に対応する携帯端末２０の通信アドレス）を取得する。

続けて、保険サーバ６００は、Ｓ２６において、Ｓ２５で特定された事故相手の車両のユーザの端末（例えば、事故相手の車両に対応する携帯端末２０）に対して、対象車両に搭載されたバッテリ１２の所有者を知らせる通知を行う。その後、処理はＳ２７に進む。

この実施の形態では、保険サーバ６００が、対象車両と他の車両との間で事故が発生したことを示す事故発生信号を取得した場合に、Ｓ２１において、管理センタ５００から、対象車両の蓄電装置の所有者を示す第１所有者情報と、他の車両の車体部分の所有者を示す第２所有者情報とを取得し、Ｓ２５，Ｓ２６の処理を実行する。詳しくは、保険サーバ６００は、Ｓ２１で取得された上記第２所有者情報を用いて他の車両のユーザを特定し（Ｓ２５）、特定された他の車両のユーザの端末に対して、対象車両の蓄電装置の所有者を知らせる通知を行う（Ｓ２６）。これにより、事故によって対象車両の蓄電装置が損傷を受けた場合に、事故相手の車両のユーザ（または、当該ユーザと契約する保険業者）と蓄電装置のリース事業者（または、当該リース事業者と連携する保険業者）との間で損害賠償に関する交渉を行いやすくなる。

Ｓ２７では、保険サーバ６００が、以下に説明する図７に示すＳ３１～Ｓ３６の一連の処理を実行する。図７は、保険サーバ６００が実行する保険サービスの提供に係る処理を示すフローチャートである。

図１，図５とともに図７を参照して、Ｓ３１では、保険サーバ６００が、図６のＳ２４と同様に、事故相手の車両が存在するか否かを判断する。単独事故の場合は、Ｓ３１においてＮＯと判断され、処理がＳ３５に進む。

事故相手の車両が存在する場合には（Ｓ３１にてＹＥＳ）、保険サーバ６００は、Ｓ３２において、事故相手の車両が加入する保険を提供する保険業者のサーバ（事故相手の保険サーバ）を特定し、対象車両から受信した事故データ（図６のＳ１４）を事故相手の保険サーバへ提供する。保険サーバ６００は、事故データから事故相手の保険サーバを特定できない場合には、対象車両のユーザ端末（例えば、携帯端末２０）に対して、事故相手の保険サーバを特定するための情報を要求してもよい。保険サーバ６００は、事故データの提供（送信）に先立ち、事情を説明するための通知を事故相手の保険サーバに対して行ってもよい。

上記Ｓ３２の処理により、対象車両の保険サーバ６００と事故相手の保険サーバとの間で事故データが共有される。その後、これらの保険サーバによって、事故データに基づく事故分析が実行され（Ｓ３３，Ｓ４１）、事故分析の結果に基づいて対象車両のユーザの過失割合が決定される（Ｓ３４，Ｓ４２）。過失割合が大きいほど過失度合いは大きい。

続けて、保険サーバ６００は、Ｓ３５において、対象車両から受信した損傷情報（図６のＳ１４）と、事故に関する車両ユーザの過失割合（Ｓ３４）とに基づいて、保険サービスによって支払われる保険金を決定する。

単独事故（自損事故）の場合は、保険サーバ６００は、Ｓ３５において、損傷情報のみに基づいて保険金を決定してもよい。ただし、事故データからユーザが故意にバッテリ１２を損傷させたことが認定される場合には、保険サーバ６００は、保険が適用されないこと（保険金なし）を決定してもよい。

続くＳ３６では、保険サーバ６００が、対象車両の車両ＩＤと、対象車両のバッテリ１２の損傷度合いを示す損傷情報と、Ｓ３５で決定された保険金を示す情報とを含む信号（以下、「保険信号」とも称する）をサーバ５２０へ送信する。保険信号は、事故に関する車両ユーザの過失割合を示す情報を含んでもよい。Ｓ３６の処理が実行されると、保険サーバ６００によるＳ３１～Ｓ３６の一連の処理（図６のＳ２７）が終了し、サーバ５２０によるＳ５１～Ｓ５３の一連の処理が開始される。

Ｓ５１では、サーバ５２０が、上記損傷情報を用いて、バッテリ１２の損傷による損失額を求める。続くＳ５２では、バッテリ１２の損傷による損失額（Ｓ５１）が、上記保険信号によって示される保険金よりも大きいか否かを、サーバ５２０が判断する。バッテリ１２の損傷による損失額が保険金よりも大きい場合には（Ｓ５２にてＹＥＳ）、サーバ５２０は、Ｓ５３において、対象車両のユーザ端末（例えば、携帯端末２０）に対して差額（＝損失額－保険金）を請求する通知を行う。他方、バッテリ１２の損傷による損失額が保険金以下である場合には（Ｓ５２にてＮＯ）、サーバ５２０は、車両ユーザに対する請求（Ｓ５３）を行わない。なお、対象車両が車両Ｂ（全部リース車両）である場合における車体部分の損失については、保険金で全額補償されてもよいし、リース事業者（自動車メーカ）が車両ユーザに損失の少なくとも一部を請求してもよい。

図７に示した一連の処理が実行されることによって図６のＳ２７が完了し、図６に示した保険サーバ６００による一連の処理が終了する。この実施の形態では、事故が発生した対象車両が、図６のＳ１４において、事故発生を知らせる事故発生信号と、対象車両に搭載された蓄電装置の損傷度合いを示す損傷情報と、事故が発生したときの対象車両の状況を示す事故データとを送信する。そして、保険サーバ６００は、事故発生信号を受信した場合に、図６および図７に示した一連の処理を実行する。詳しくは、保険サーバ６００は、事故データに基づいて、事故に関する対象車両のユーザの過失度合いを決定し（図７のＳ３４）、損傷情報と過失度合いとに基づいて、保険サービスによって支払われる保険金を決定する（図７のＳ３５）。これにより、保険金が適切に決定されやすくなる。また、対象車両のユーザが保険サービスを受けやすくなる。

サーバ５２０は、保険サーバ６００から事故発生の通知（図６のＳ２３）を受けると、以下に説明する図８に示す一連の処理を開始する。この実施の形態において、サーバ５２０が上記事故発生の通知を受けたことは、車両Ａまたは車両Ｂについて事故が発生したことを意味する。

図８は、この実施の形態に係る蓄電装置の管理方法において、サーバ５２０によって実行される事故発生時の制御を示すフローチャートである。図１，図５とともに図８を参照して、Ｓ１０１では、サーバ５２０が、保険サーバ６００から通知された事故発生場所の位置（図６のＳ２３）に基づいて、事故発生場所の周辺に存在する１つ以上のＢＳｔａ２００を特定する。事故発生場所の周辺に存在する１つ以上のＢＳｔａ２００は、事故発生場所に最も近い１つのＢＳｔａ２００であってもよいし、事故発生場所の位置から所定距離以内に存在する少なくとも１つのＢＳｔａ２００であってもよい。

続くＳ１０２では、サーバ５２０が、Ｓ１０１で特定された１つ以上のＢＳｔａ２００のノード５１０Ｂに対して、対象車両に搭載されたバッテリ１２の交換を許可する。具体的には、サーバ５２０は、対象車両の識別情報（車両ＩＤ）を含む交換許可信号をノード５１０Ｂに送信する。この交換許可信号により、ＢＳｔａ２００による対象車両のバッテリ交換が許可される。ノード５１０Ｂは、交換許可信号に含まれる車両ＩＤに基づいて、交換対象の車両を特定する。交換許可信号に含まれる車両ＩＤはノード５１０Ｂに登録され、車両ＩＤが示す対象車両のバッテリ交換がノード５１０Ｂに予約される。ノード５１０Ｂは、後述の図９に示す処理により、予約されたバッテリ交換を実行できる。ただし、バッテリ交換が予約されてから所定の期間が経過しても当該バッテリ交換が実行されなかったときには、上記予約が解除されてもよい。

続けて、サーバ５２０は、Ｓ１０３において、対象車両に搭載されたバッテリ１２と交換可能な蓄電装置（交換用バッテリ）を確保することを、Ｓ１０１で特定された１つ以上のＢＳｔａ２００のノード５１０Ｂに対して要求する。具体的には、サーバ５２０は、対象車両の識別情報（車両ＩＤ）に基づいて、記憶装置５２２が記憶する分散型台帳の中から対象車両のバッテリ１２に関する仕様情報を抽出し、抽出された仕様情報をノード５１０Ｂへ送信することにより、ノード５１０Ｂに対して上記要求を実行する。この要求を受けたノード５１０Ｂは、サーバ５２０から要求された交換用バッテリの在庫が不足しているか否かを確認し、交換用バッテリの在庫が不足していれば、近くの倉庫または他のＢＳｔａ２００から交換用バッテリ（対象車両のための蓄電装置）を確保する。

この実施の形態では、サーバ５２０が、対象車両の事故発生を知らせる通知（図６のＳ２３）を受けた場合に、Ｓ１０１～Ｓ１０３の処理を実行する。詳しくは、サーバ５２０（対象車両の蓄電装置の所有者の端末）が、Ｓ１０２において、１つ以上のＢＳｔａ２００（交換ステーション）に対して対象車両の蓄電装置の交換を許可する。これにより、対象車両について事故が発生した場合に、その対象車両に搭載された蓄電装置を交換ステーションで交換しやすくなる。また、Ｓ１０３の処理により、事故後、早期にバッテリ交換を行いやすくなる。

事故が発生した対象車両は、自力走行で、またはレッカー車に運ばれて、事故発生場所の周辺に存在するＢＳｔａ２００（例えば、事故発生場所に最も近いＢＳｔａ２００）に到着する。そして、ＢＳｔａ２００において、対象車両に搭載されたバッテリ１２が交換される。図９は、対象車両とバッテリ交換ステーション端末（ノード５１０Ｂ）とが実行するバッテリ交換に係る処理を示すフローチャートである。

図１，図５とともに図９を参照して、Ｓ１１０～Ｓ１８０の一連の処理は、対象車両のＥＣＵ１１１によって実行される。Ｓ２１０～Ｓ２７０の一連の処理は、ノード５１０Ｂによって実行される。ノード５１０Ｂは、対象車両と無線通信可能に構成され、対象車両からバッテリ情報を取得する。ノード５１０Ｂと対象車両とは、例えば無線ＬＡＮ（Local Area Network）による近距離通信を行ってもよいし、通信ネットワークＮＷを介して通信してもよい。

対象車両は、ＢＳｔａ２００に到着した後、Ｓ１１０において、バッテリ交換を依頼する信号（以下、「依頼信号」とも称する）をノード５１０Ｂへ送信する。依頼信号は、対象車両の識別情報（車両ＩＤ）を含む。以下では、対象車両が備える交換前のバッテリ１２を、「バッテリＢ１」と表記する。対象車両は、ユーザからの指示に応じて、バッテリ交換の依頼（Ｓ１１０）を実行してもよい。

依頼信号を受信したノード５１０Ｂは、Ｓ２１０において、対象車両について所定の交換要件が満たされるか否かを判断する。具体的には、ノード５１０Ｂは、依頼信号に含まれる車両ＩＤと、交換許可信号に含まれる車両ＩＤ（図８のＳ１０２）とが一致するか否かに基づいて、交換要件の成否を判断する。すなわち、対象車両の車両ＩＤが登録（予約）されていれば交換要件が満たされ、対象車両の車両ＩＤが登録（予約）されていなければ交換要件は満たされない。

対象車両について交換要件が満たされる場合には（Ｓ２１０にてＹＥＳ）、ノード５１０ＢがＳ２２０において対象車両に許可の通知を送った後、処理がＳ２４０に進む。他方、対象車両について交換要件が満たされない場合には（Ｓ２１０にてＮＯ）、ノード５１０ＢがＳ２３０において対象車両に不許可の通知を送った後、Ｓ２１０～Ｓ２７０の一連の処理が終了する。この場合、バッテリ交換は行われない。

対象車両は、依頼信号（Ｓ１１０）を送信した後、ノード５１０Ｂからの返信を待つ。そして、対象車両は、ノード５１０Ｂから返信を受けると、Ｓ１２０において、バッテリ交換が許可されたか否かを判断する。そして、対象車両が上記許可の通知を受けた場合には（Ｓ１２０にてＹＥＳ）、処理がＳ１３０に進む。他方、対象車両が上記不許可の通知を受けた場合には（Ｓ１２０にてＮＯ）、Ｓ１１０～Ｓ１８０の一連の処理が終了する。この場合、バッテリ交換は行われない。

Ｓ１３０，Ｓ２４０においては、後述する手順でバッテリ交換が実行される（図１０参照）。対象車両とノード５１０Ｂとは、バッテリ交換のための情報をやり取りする。

以下では、上記バッテリ交換によって対象車両に取り付けられたバッテリ１２を、「バッテリＢ２」と表記する。バッテリ交換が完了すると、対象車両は、Ｓ１４０において、バッテリＢ２の検査を実行する。続けて、対象車両は、Ｓ１５０において、その検査の結果をノード５１０Ｂへ送信する。続けて、対象車両は、Ｓ１６０において、検査の結果に応じてバッテリ交換が成功したか否かを判断する。対象車両は、検査によって異常（例えば、接続不良、または電気性能の異常）が発見されなければバッテリ交換が成功したと判断し、検査によって異常が発見された場合には、バッテリ交換が失敗したと判断する。同様に、上記検査の結果を受信したノード５１０Ｂも、Ｓ２５０において、その検査の結果（異常なし／異常あり）に応じてバッテリ交換が成功したか否かを判断する。

バッテリ交換が成功した場合には（Ｓ１６０にてＹＥＳかつＳ２５０にてＹＥＳ）、対象車両とノード５１０Ｂとの各々が、Ｓ１７０，Ｓ２６０において、自らが保有するバッテリ情報（仕様情報）を更新した後、図９に示す一連の処理が終了する。ノード５１０Ｂは、Ｓ２６０において、管理センタ５００が管理する分散型台帳を更新してもよい。他方、バッテリ交換が失敗した場合には（Ｓ１６０にてＮＯかつＳ２５０にてＮＯ）、対象車両とノード５１０Ｂとの各々が、Ｓ１８０，Ｓ２７０において、所定の異常時処理を実行する。異常時処理は、バッテリ交換が失敗したことを対象車両のユーザに報知する処理を含んでもよい。異常時処理は、バッテリ交換が失敗したことをサーバ５２０に通知する処理を含んでもよい。また、異常時処理は、対象車両に取り付けられたバッテリＢ２をいったん対象車両から取り外して、バッテリ交換をやり直す処理を含んでもよい。異常時処理が実行された後、図９に示す一連の処理は終了する。なお、異常時処理は任意に設定できる。

図１０は、この実施の形態に係るバッテリ交換ステーション（ＢＳｔａ２００）の構成および動作について説明するための図である。

図１０を参照して、ＢＳｔａ２００は、保管装置２１０と検査部２２０とを備える。保管装置２１０は収容部（例えば、格納庫）を含む。検査部２２０は、例えば、充放電器、測定装置、および選別装置を含む。また、ＢＳｔａ２００は、蓄電装置を搬送するための搬送装置と、蓄電装置を交換するための交換装置とをさらに備える。搬送方式は、コンベア方式であってもよいし、搬送ロボットを利用した方式であってもよい。搬送装置および交換装置の各々は、ノード５１０Ｂによって制御される。

ノード５１０Ｂの記憶装置５１２（図２）は、ＢＳｔａ２００内に存在する各バッテリに関する情報をバッテリの識別情報（バッテリＩＤ）で区別して記憶している。ノード５１０Ｂが保有するバッテリ情報は、例えば、仕様（初期状態の容量、充電性能、放電性能など）と、ステータス（例えば、検査前／検査済み（再利用／他の用途／廃棄）／供給可のいずれか）と、ＳＯＨ（State of Health）と、ＳＯＣ（State Of Charge）とを含む。

なお、ＳＯＣは、蓄電残量を示し、満充電状態の蓄電量に対する現在の蓄電量の割合に相当する。ＳＯＨは健全度または劣化度を示す。ＳＯＨの例としては、容量維持率、内部抵抗が挙げられる。蓄電装置の内部抵抗が大きいほど蓄電装置の劣化度が大きいことを意味する。蓄電装置の容量維持率が低いほど蓄電装置の劣化度が大きいことを意味する。蓄電装置の容量維持率は、初期状態（劣化していない状態）の蓄電装置の容量に対する現在の蓄電装置の容量の割合に相当する。蓄電装置の容量は満充電状態の蓄電量に相当する。

ノード５１０Ｂは、保管装置２１０の収容部に収容された各バッテリＢ３（供給可能な蓄電装置）に関する情報（バッテリＩＤ、仕様、ＳＯＨなど）を、ＢＳｔａ２００の位置情報とともに、管理センタ５００が管理する分散型台帳に書き込んでもよい。こうした情報は、バッテリの在庫管理に役に立つ。ＢＳｔａ２００内に存在するバッテリは、自動車メーカの所有物である。自動車メーカの倉庫からＢＳｔａ２００に新しいバッテリが供給されることもあるし、車両１０から回収された中古バッテリがＢＳｔａ２００に保管されることもある。また、複数のＢＳｔａ２００間でバッテリが運搬されることもある。

対象車両は、ＢＳｔａ２００内の所定位置に駐車した後、ノード５１０Ｂにバッテリ交換を依頼する（図９のＳ１１０）。この依頼に応じて、ノード５１０Ｂがバッテリ交換のための制御（図９のＳ２４０）を開始する。ノード５１０Ｂは、例えば次のような手順で対象車両のバッテリを交換する。

ノード５１０Ｂは、保管装置２１０の収容部に収容された複数のバッテリＢ３の中から、バッテリＢ１に対応するバッテリ（交換用バッテリ）を選ぶ。選ばれたバッテリＢ３は、バッテリＢ１と同じ仕様（例えば、初期状態の容量、充電性能、および放電性能）を有する。ただし、バッテリＢ１の劣化度よりもバッテリＢ３の劣化度のほうが小さい。また、バッテリＢ３のＳＯＣは所定ＳＯＣ値（例えば、５０％）以上になっている。

続けて、交換装置が対象車両からバッテリＢ１を取り外す。以下では、対象車両から取り外されたバッテリを、「バッテリＢ４」と表記する。続けて、搬送装置がバッテリＢ３を保管装置２１０から交換装置へ搬送（供給）する。続けて、供給されたバッテリＢ３を交換装置が対象車両に取り付ける。これにより、対象車両のバッテリ交換が完了する。

また、ＢＳｔａ２００は、上記のバッテリ交換プロセスと並行して、対象車両から取り外されたバッテリＢ４の再利用プロセスを実行する。バッテリＢ４が対象車両から取り外されると、ノード５１０Ｂがバッテリ再利用のための制御を開始する。再利用プロセスは、例えば次のような手順で実行される。

搬送装置がバッテリＢ４を検査部２２０へ搬送（回収）する。続けて、検査部２２０が、回収されたバッテリＢ４の検査を実行する。検査部２２０の充放電器および測定装置によって検査が実行される。検査前にＳＯＨの回復処理がバッテリＢ４に施されてもよい。

上記検査においては、充放電器が、例えば、所定の第１ＳＯＣ値（例えば、空充電状態を示すＳＯＣ値）以下になるまでバッテリＢ４を放電した後、所定の第２ＳＯＣ値（例えば、満充電状態を示すＳＯＣ値）以上になるまでバッテリＢ４を充電する。測定装置は、各種センサを含み、充電中および／または放電中におけるバッテリＢ４の状態（例えば、温度、電流、および電圧）を測定する。そして、測定装置は、測定されたデータからバッテリＢ４のＳＯＨを検出する。なお、測定装置は、外観検査のためのカメラをさらに含んでもよい。また、測定装置が必要な検査データを取得するまで充放電器がバッテリＢ４の充放電を繰り返してもよい。

上記検査が完了すると、検査部２２０の選別装置が、その検査結果に応じて、車両用バッテリとしての再利用と、他の用途（車両用以外の用途）での利用と、廃棄とのいずれかに、バッテリＢ４を選別する。他の用途の例としては、定置用が挙げられる。バッテリ廃棄の手法は任意である。廃棄の過程でバッテリを材料レベルまで分解し、再生可能な材料（資源）を回収して再利用（資源リサイクル）してもよい。なお、選別装置は、外観に著しい損傷があるバッテリＢ４を、再利用不可（他の用途または廃棄）に分類してもよい。

車両用バッテリとして再利用可能なバッテリＢ４は、前述したバッテリＢ３として扱われる。上記検査後、搬送装置がバッテリＢ３を保管装置２１０へ搬送する。搬送されたバッテリＢ３は保管装置２１０に充填される。これにより、検査済みかつ充電済みのバッテリＢ３が保管装置２１０にセットされ、供給可能になる。ただしこれに限られず、保管装置２１０が検査済みのバッテリＢ３を充電するように構成されてもよい。

図１０には、バッテリの取外しとバッテリの取付けとが異なる場所で行われる例を示している。対象車両は、図示しない搬送装置（例えば、コンベア方式の搬送装置）によって取外し位置から取付け位置に搬送されてもよい。ただしこれに限られず、バッテリの取外しとバッテリの取付けとは同じ場所で行われてもよい。対象車両が静止した状態（例えば、駐車状態）でバッテリの交換（取外しおよび取付け）が行われてもよい。また、交換前のバッテリと交換後のバッテリとが同じ仕様を有することは必須ではない。車載バッテリは異なる仕様のバッテリに交換されてもよい。例えば、バッテリ交換によって車載バッテリの容量を増大させてもよい。

以上説明したように、この実施の形態に係る蓄電装置の管理方法は、図６～図９に示した各処理を含む。この実施の形態では、保険サーバ６００が、本開示に係る「コンピュータ装置」の一例に相当する。１つ以上のプロセッサが１つ以上のメモリに記憶されたプログラムを実行することにより、各処理が実行される。ただし、これらの処理は、ソフトウェアではなく、専用のハードウェア（電子回路）によって実行されてもよい。

上記実施の形態では、車両Ａ（部分リース車両）と車両Ｂ（全部リース車両）とについて、共通の処理フロー（図７参照）により、蓄電装置の損傷に関する保険金が算出される。しかしこれに限られず、車両Ａと車両Ｂとについて異なる処理フローにより保険金が算出されてもよい。例えば、保険サーバ６００は、車両Ａについては図７に示した処理フローを実行し、車両Ｂについては別の処理フロー（図示せず）を実行してもよい。保険サーバ６００は、車両Ｂに関しては、蓄電装置の損傷に対する補償だけでなく、車体の損傷に対する補償も行う保険サービスを提供してもよい。

図６～図９に示した処理フローは適宜変更可能である。例えば、目的に応じて、処理の順序が変更されてもよいし、不要なステップが省かれてもよい。また、いずれかの処理の内容が変更されてもよい。上記実施の形態では、保険サーバ６００が図６のＳ２１において第１所有者情報および第２所有者情報の両方を取得しているが、保険サーバ６００は管理センタ５００から第１所有者情報のみを取得してもよい。また、当局のデータ管理装置が管理する車両の公証情報（例えば、自動車検査登録情報）に第１所有者情報（車載蓄電装置の所有者を示す情報）が含まれる形態では、保険サーバ６００は、図６のＳ２１において、当局のデータ管理装置から第１所有者情報（公証情報）を取得してもよい。

管理センタ５００はバッテリパスポート情報として第１所有者情報を管理してもよい。また、管理センタ５００は、保険サーバ６００から所有者情報の送信を要求されたときに、所有者情報が示す所有者に許可を求め、所有者から許可が得られた場合に限り、その所有者情報を保険サーバ６００に送信してもよい。この実施の形態では、ノード５１０、サーバ５２０、および保険サーバ６００が、いずれもオンプレミスサーバである。しかしこれに限られず、各サーバの機能がクラウドコンピューティングによってクラウド上に実装されてもよい。すなわち、これらのサーバはクラウドサーバであってもよい。リースサービスを提供する場所は、ディーラ１００に限られない。例えば、サーバ５２０がオンラインで（例えば、クラウド上で）リースサービスを提供してもよい。また、リース方式は１種類（例えば、部分リース方式）のみであってもよい。

上記実施の形態では、バッテリのみが交換されているが、バッテリおよびその付属部品（例えば、バッテリＥＣＵ、ＢＭＳ、歪みセンサ、温調システム、およびＳＭＲの少なくとも１つ）を含む電池パックがまとめて交換されてもよい。車両は、ＢＥＶ以外のｘＥＶ（電動車）であってもよい。車両は内燃機関を備えてもよい。車両は、４輪の乗用車に限られず、バスまたはトラックであってもよいし、３輪または５輪以上のｘＥＶであってもよい。車両はソーラーパネルを備えてもよい。車両は非接触充電可能に構成されてもよい。車両は、自動運転可能に構成されてもよいし、飛行機能を備えてもよい。車両は、無人で走行可能な車両（例えば、ロボタクシー、無人搬送車、または農業機械）であってもよい。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 車両、１１ 車体、１２ バッテリ、２０ 携帯端末、１００ ディーラ、１１１ ＥＣＵ、２００ バッテリ交換ステーション、５００ 管理センタ、５１０ ノード、５２０ サーバ、６００ 保険サーバ。

Claims (6)

1. 蓄電装置を備える車両について事故が発生したことを示す情報を取得した場合に、当該車両を含む複数の車両に関する情報を管理するデータ管理装置から、前記蓄電装置の所有者を示す第１所有者情報を取得することと、
   取得された前記第１所有者情報を用いて、前記蓄電装置の所有者を特定することと、
   特定された前記蓄電装置の所有者の端末に対して、当該蓄電装置を備える前記車両の事故発生を知らせる通知を行うことと、
   を含む、蓄電装置の管理方法。
2. 前記データ管理装置は、前記複数の車両の各々に関して車載蓄電装置と車体部分との各々の所有者を示す情報を管理しており、
   当該管理方法は、
   前記車両と他の車両との間で事故が発生したことを示す情報を取得した場合に、前記データ管理装置から、前記蓄電装置に関する前記第１所有者情報と、前記他の車両の車体部分の所有者を示す第２所有者情報とを取得することと、
   取得された前記第２所有者情報を用いて、前記他の車両のユーザを特定することと、
   特定された前記他の車両のユーザの端末に対して、前記蓄電装置の所有者を知らせる通知を行うことと、
   を含む、請求項１に記載の蓄電装置の管理方法。
3. プロセッサと、請求項１に記載の蓄電装置の管理方法を前記プロセッサに実行させるプログラムを記憶する記憶装置とを備える、コンピュータ装置。
4. 請求項３に記載のコンピュータ装置と、前記データ管理装置とを含む蓄電装置の管理システムであって、
   前記データ管理装置は、
   分散型台帳を記憶する記憶装置と、
   前記複数の車両の各々に関して車載蓄電装置の所有者を示す情報を含むトランザクションデータを前記分散型台帳に登録する制御装置と、
   を備える、蓄電装置の管理システム。
5. 前記コンピュータ装置は、車両用の蓄電装置の損傷に関する保険サービスを提供する第１サーバであり、
   前記事故が発生した前記車両は、事故発生を知らせる事故発生信号と、前記蓄電装置の損傷度合いを示す損傷情報と、前記事故が発生したときの前記車両の状況を示す事故データとを送信するように構成され、
   前記第１サーバは、前記事故発生信号を受信した場合に、
   前記事故データに基づいて、前記事故に関する前記車両のユーザの過失度合いを決定することと、
   前記損傷情報と前記過失度合いとに基づいて、前記保険サービスによって支払われる保険金を決定することと、
   を実行するように構成される、請求項４に記載の蓄電装置の管理システム。
6. 当該管理システムは、車両用の蓄電装置の交換を行う複数の交換ステーションをさらに含み、
   前記蓄電装置の所有者の端末は、車両用の蓄電装置を貸し出すリースサービスを提供する第２サーバであり、
   前記第２サーバは、前記車両の事故発生を知らせる前記通知を受けた場合に、１つ以上の前記交換ステーションに対して前記蓄電装置の交換を許可するように構成される、請求項４に記載の蓄電装置の管理システム。

Images