JP2020013347A - 履歴管理方法、及び履歴管理装置 - Google Patents

Abstract

【課題】車両の履歴情報を保管するのに適した履歴管理方法及び装置の提供。【解決手段】車載ユニット１００は、ブロックチェーンＢＣを用いて車両Ｖの履歴情報を管理する履歴管理装置として機能する。車載ユニット１００は、車両Ｖにて収集された履歴情報から、ブロックチェーンＢＣに連結されるブロックＢＬを生成し、生成したブロックＢＬのバックアップの保存先を、車両Ｖと通信可能なノードＮＤの中から、ブロック単位で設定する。ブロックＢＬのバックアップは、設定された保存先となるノードＮＤへ向けて送信される。【選択図】図２

Description

この明細書による開示は、車両の履歴情報を管理する履歴管理の技術に関する。

従来、例えば特許文献１には、ネットワークに接続された多数のノード間での取引履歴を、ブロックチェーンを用いて記録する取引記録システムが記載されている。特許文献１の取引記録システムでは、各ノードの保有データ量を少なくするため、特定ネットワーク内での取引履歴は、特定ネットワークに配置されたノードのみにより共有される。

特開２０１８−６７１０８号公報

本開示の発明者は、特許文献１のようなブロックチェーンの技術を、車両の履歴情報の保管に用いることを検討した。しかし、特許文献１のシステムでは、特定ネットワーク内での取引履歴を含んだ全てのブロックは、当該特定ネットワーク内の全ノードに複製される。こうした全ノードによる全ブロックの共有に起因して、通信量の増加又は各ノードの保存データ量の増加等が不可避となる。そのため、特許文献１のようなシステムは、車両の履歴情報の保管に適用困難であった。

本開示は、ブロックチェーンの技術を用いて車両の履歴情報を保管するのに適した履歴管理方法及び履歴管理装置の提供を目的とする。

上記目的を達成するため、開示された一つの態様は、コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて車両（Ｖ）の履歴情報を管理する履歴管理方法であって、少なくとも一つのプロセッサ（２１，６１）上において、車両にて収集された履歴情報から、ブロックチェーンに連結されるブロック（ＢＬ）を生成し（Ｓ１０）、生成したブロックのバックアップの保存先を、車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、設定した保存先となるノードへ向けて、ブロックのバックアップを送信する（Ｓ７０）、というステップを含む履歴管理方法とされる。

また開示された一つの態様は、ブロックチェーン（ＢＣ）を用いて車両（Ｖ）の履歴情報を管理する履歴管理装置であって、車両にて収集された履歴情報から、ブロックチェーンに連結されるブロック（ＢＬ）を生成するブロック生成部（７１）と、ブロック生成部にて生成されたブロックのバックアップの保存先を、車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定する保存先設定部（７５）と、保存先設定部にて設定された保存先のノードへ向けて、ブロックのバックアップを送信するブロック送信部（７７）と、を備える履歴管理装置とされる。

これらの態様では、車両の履歴情報から生成されるブロックのバックアップの保存先が、車両と通信可能なノードの中から、ブロック単位で設定される。そのため、ブロックチェーンの全ブロックが特定ネットワーク内の全ノードに複製される事態は、回避される。以上によれば、ブロックの共有に起因する通信量の増加又は各ノードの保存データ量の増加は、抑制され得る。したがって、ブロックチェーンの技術を用いて車両の履歴情報を保管するのに適した履歴管理方法及び履歴管理装置が実現される。

尚、上記括弧内の参照番号は、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、技術的範囲を何ら制限するものではない。

本開示の一実施形態による車載ユニットを含む履歴保管のためのネットワークであって、履歴管理システムの全体像を示す図である。 複数の車載ユニットによって形成されるＰ２Ｐネットワークを模式的に示す図である。 車載ユニットの機能の詳細を示すブロック図である。 サーバの機能の詳細を示すブロック図である。 ブロックチェーンを形成する個々のブロックの内容を詳細に示す図である。 チェーン追加処理のメイン処理の詳細を示すフローチャートである。 ブロック生成処理の詳細を示すフローチャートである。 ブロック承認処理の詳細を示すフローチャートである。 保存先設定処理の詳細を示すフローチャートである。 チェーン復元処理の詳細を示すフローチャートである。 バックアップ復元処理の詳細を示すフローチャートである。 ブロックチェーン及びバックアップブロックを復元する過程を説明するための図である。

図１に示す本開示の一実施形態による履歴管理システム１０は、複数の車載ユニット１００、及び少なくとも一つ以上のサーバ２０等によって構成されている。履歴管理システム１０は、ブロックチェーンＢＣ（図５参照）を用いて、車載ユニット１００を搭載した複数の車両Ｖの履歴情報を管理する。各車載ユニット１００及び各サーバ２０は、相互に通信可能に接続されており、ネットワークＮＷにおける一つのノードＮＤとしてそれぞれ機能する。

車載ユニット１００は、通信器４０と共に車両Ｖに搭載されている。車載ユニット１００は、通信器４０を介して、他のノードＮＤと通信可能である。通信器４０は、Ｖ２Ｘ通信のための複数種類のアンテナを備えた通信モジュールを主体に構成されている。通信器４０にて実施されるＶ２Ｘ通信には、Ｖ２Ｎ通信、Ｖ２Ｉ（路車間）通信、及びＶ２Ｖ（車車間）通信等が含まれている。Ｖ２Ｎ通信又はＶ２Ｉ通信にて交信するネットワークＮＷの範囲は、車載ユニット１００から見たネットワーククラウドＮＷＣとなる。

通信器４０は、ＬＴＥ（Long Term Evolution）及び５Ｇ等の通信規格に沿ったＶ２Ｎ（Vehicle to cellular Network）通信により、基地局ＢＳとの間で情報を送受信する。通信器４０は、Ｖ２Ｉ（Vehicle to roadside Infrastructure）通信により、道路に設置された路側機ＲＳＵとの間で情報を送受信する。通信器４０は、Ｖ２Ｖ（Vehicle to Vehicle）通信により、自車両（Ｖ１）周囲の特定範囲（以下、「通信範囲Ｒｃ」）に存在する他の車両（Ｖ２，Ｖ３）の通信器４０との間で、直接的に情報を送受信する。

各車載ユニット１００は、図２に示すように、通信器４０を介した他の車載ユニット１００との相互接続により、Ｐｅｅｒ ｔｏ Ｐｅｅｒ（Ｐ２Ｐ）通信可能なＰ２Ｐネットワークを形成する。車載ユニット１００は、Ｐ２Ｐ通信により、各車両Ｖ（Ｖ１〜Ｖ５）にて収集された履歴情報を相互に持ち合い、各車両Ｖの履歴情報を分散保存した状態を構築する。

詳記すると、各車載ユニット１００は、搭載された各車両Ｖにて収集された履歴情報をトランザクションとして扱ったブロックチェーンＢＣを生成する。ブロックチェーンＢＣは、車両Ｖ毎に生成され、履歴情報を含んだ多数のブロックＢＬを有している。車載ユニット１００には、ブロックＢＬを保管するための記憶領域として、ブロック保存部６９が確保されている。車載ユニット１００は、自ら生成した個々のブロックＢＬを、自らのブロック保存部６９に保存すると共に、他の車載ユニット１００のブロック保存部６９にも保存させる。その結果、各車両Ｖのブロック保存部６９には、少なくとも自車両を含む複数の車両Ｖにて生成されたブロックＢＬが保存されている。

ここで、ブロック保存部６９に保存される多数のブロックＢＬのうちで、そのブロック保存部６９を有する車両Ｖ（自車両）にて収集された履歴情報を含むブロックＢＬが、「マスタブロックＢＬｍ」である。マスタブロックＢＬｍは、自車ブロックであり、時系列に沿った鎖状連結により、ブロックチェーンＢＣを形成している。一方、マスタブロックＢＬｍを除く他のブロックＢＬが「バックアップブロックＢＬｃ」である。バックアップブロックＢＬｃは、履歴情報の収集元である車両ＶがマスタブロックＢＬｍとは異なる他車ブロックであり、他の車両Ｖにて生成されたマスタブロックＢＬｍの複製データである。

図１〜図３に示す車載ユニット１００は、プロセッサ６１、ＲＡＭ６２、メモリ装置６３及び入出力インターフェースを有する制御回路を主体に構成された車載コンピュータである。プロセッサ６１は、ＲＡＭ６２と結合された演算処理のためのハードウェアであって、種々のプログラムを実行可能である。

メモリ装置６３は、不揮発性の記憶媒体を含む構成である。メモリ装置６３には、上述のブロック保存部６９となる記憶領域が確保されている。加えてメモリ装置６３には、プロセッサ６１によって実行される種々のプログラムが格納されている。メモリ装置６３に格納されたプログラムには、多数の履歴情報をブロックチェーンＢＣ化して分散管理するための管理プログラムＰｃが少なくとも含まれている。管理プログラムＰｃは、後述するチェーン追加処理（図６参照）をプロセッサ６１に実施させる。プロセッサ６１による管理プログラムＰｃの実行により、情報収集部７０、ブロック生成部７１、承認依頼部７２、承認演算部７３、異常判定部７４、保存先設定部７５、ブロック管理部７６及びブロック送信部７７等の機能部が車載ユニット１００に実装される。

情報収集部７０は、車内ＬＡＮのネットワークバス４５に出力された種々の情報を収集可能である。情報収集部７０は、車両Ｖの履歴情報に加えて、ブロック生成の開始のトリガとなる情報を、ネットワークバス４５から取得する。履歴情報には、特定時点における車両Ｖの走行距離、走行用バッテリへの充電記録、及び部品交換の内容記録等が含まれる。これらの履歴情報は、各ブロックＢＬのトランザクション（図５「TX1〜TX3」参照）として用いられる。トリガ情報には、車両電源の切り替え情報、充電開始を示す情報、車両Ｖの位置情報、部品交換の実施を示す情報等が含まれる。

ブロック生成部７１は、情報収集部７０によって収集された履歴情報から、自車両ＶｉのブロックチェーンＢＣに連結される最新のブロックＢＬ（マスタブロックＢＬｍ）を生成する。ブロック生成部７１は、過去（ｎ−１番目まで）のブロックＢＬのいずれにも含まれていない履歴情報を、新規に生成する（ｎ番目の）ブロックＢＬに記録していく。

ブロック生成部７１は、複数の開始条件の成立に基づき、ブロックＢＬの生成を開始する。開始条件には、前回のブロックＢＬの生成から一定の時間が経過した、車両電源及びエンジン（イグニッション）がオン状態及びオフ状態に切り替えられた、充電が開始された、ディーラ等の特定地点に移動した、並びに部品交換を実施した等が含まれる。

ブロック生成部７１は、ブロックＢＬ（マスタブロックＢＬｍ）を生成したノードＮＤ（車載ユニット１００）を示すノード識別情報ＩＤｎ（図５「ID_NODE」参照）を、マスタブロックＢＬｍに記録する。ノード識別情報ＩＤｎは、ブロックＢＬに保存された履歴情報の収集元となる車両Ｖを示す車両識別情報としても機能する。尚、図２及び図３等では、同一の背景意匠（白抜きも含む）とされたブロックＢＬが、同一のノード識別情報ＩＤｎを有するブロックＢＬである。

加えてブロック生成部７１は、新たなマスタブロックＢＬｍを生成するとき、ブロック特定情報ＩｎＢ（図５「Info_BUP」参照）を、マスタブロックＢＬｍに記録する。ブロック特定情報ＩｎＢは、マスタブロックＢＬｍが生成された時点において、ブロック保存部６９に保存されていたバックアップブロックＢＬｃを特定可能にする情報である。ブロック特定情報ＩｎＢには、各バックアップブロックＢＬｃのノード識別情報ＩＤｎと、各ブロックチェーンＢＣにおいて何番目に連結されたブロックＢＬであるかを示す情報（図５「B/H」参照）とが、互いに紐付けられた状態でリスト状に記録されている。尚、ブロックチェーンＢＣにおける何番目のブロックＢＬであるかを示す情報を、以下、「ブロックハイト」という。また、ブロックチェーンの復元時にブロックハイトに替えて使用可能な情報として、ブロックＢＬ間の前後の関係を示す情報が、各ブロックＢＬに保持されていてもよい。

承認依頼部７２は、後述するブロック承認処理（図８参照）により、新たに生成されたブロックＢＬ（マスタブロックＢＬｍ）の承認を、自車両Ｖｉと通信可能な状態にある複数の他ノードＮＤに依頼する。承認の依頼先となるノード（以下、「承認ノードＮＤ２」）は、主に他車両Ｖａに搭載された車載ユニット１００である。承認依頼部７２によって承認を依頼される承認ノードＮＤ２の数Ｎは、奇数とされ、より望ましくは三以上のとされる。

承認依頼部７２は、承認ノード数Ｎ以上の他車両ＶａがＶ２Ｖ通信の通信範囲Ｒｃにいる場合、通信範囲Ｒｃ内にある各他車両Ｖａの車載ユニット１００に、Ｖ２Ｖ通信によってブロックＢＬの承認を依頼する。一方で、承認ノード数Ｎ未満の他車両ＶａしかＶ２Ｖ通信の通信範囲Ｒｃにいない場合、通信範囲Ｒｃ外にある他車両Ｖａの車載ユニット１００に、Ｖ２Ｎ通信又はＶ２Ｉ通信により、ネットワーククラウドＮＷＣを通じてブロックＢＬの承認を依頼する。

承認演算部７３は、他の車載ユニット１００（他ノードＮＤ）の承認依頼部７２から受信した承認依頼に基づき、他ノードＮＤにて生成されたブロックＢＬの正当性を検証する。承認演算部７３の演算により、自ノードＮＤは、承認ノードＮＤ２として機能する。承認演算部７３は、正当性の検証に必要な情報を他ノードＮＤから受信し、他ノードＮＤにて新規に生成されたマスタブロックＢＬｍの内容が正しいか否かを検証する。承認演算部７３は、検証結果に基づく承認可否の回答を、承認者である自ノードＮＤを示す固有のハッシュ値（図５「Aut_A〜C」参照）と共に、承認の依頼元である他ノードＮＤへ向けて送信する。

異常判定部７４は、他ノードＮＤの承認演算部７３から返信された承認可否の結果に基づき、新しいマスタブロックＢＬｍをブロックチェーンＢＣに連結するか否かを決定する。具体的には、承認ノード数Ｎのうちの過半数（Ｎ＝３の場合、三分の二以上）から、連結を肯定する内容の返信を受け取っている場合、異常判定部７４は、新しいマスタブロックＢＬｍのブロックチェーンＢＣへの連結を決定する。一方で、連結を肯定する内容の返信が承認ノード数Ｎの過半数未満（Ｎ＝３の場合、三分の二未満）である場合、異常判定部７４は、新しいマスタブロックＢＬｍの連結を回避すると共に、ブロック保存部６９に保存されているデータに異常があると判定する。尚、連結の可否の決定は、過半数を超えるか否かに限定されない。具体的には、承認ノード数Ｎに対応した閾値が設定され、当該閾値に基づき、連結の可否が決定されてもよい。

保存先設定部７５は、後述する保存先設定処理（図９参照）により、ブロックチェーンＢＣへの連結を許可された新規のマスタブロックＢＬｍのバックアップの保存先を、ブロック単位で設定する。保存先設定部７５は、一般的なブロックチェーン技術のように、ネットワーク上の全ノードにブロックのバックアップを送信させるのではなく、ごく一部且つ複数の他ノードＮＤへ向けて、限定的にバックアップを送信させる。

保存先設定部７５は、新規にブロックＢＬを生成するタイミングで、新規のマスタブロックＢＬｍの複製であるバックアップブロックＢＬｃについて、その保存先を、自車両Ｖｉと通信可能な状態にある他ノードＮＤの中から選択する。こうしたブロック単位での保存先の設定によれば、ブロックＢＬを共有するノードＮＤは、ブロックＢＬ毎に異なってくる。そして、バックアップブロックＢＬｃの保存先となるバックアップノードの数Ｋは、承認ノード数Ｎよりも少ない数に設定される。

保存先設定部７５は、通信可能な状態にある他ノードＮＤに保存先としての優先順位を付与し、優先順位の高い他ノードＮＤから順に、バックアップブロックＢＬｃの保存の可否を問い合わせる。保存先設定部７５は、複数の承認ノードＮＤ２の中から、バックアップブロックＢＬｃを共有する保存先を選択する。加えて保存先設定部７５は、ブロック追加の承認を後で実施した承認ノードＮＤ２ほど、高い優先順位を付与する。また保存先設定部７５は、ブロック保存部６９の記憶容量の残量が少ない他ノードＮＤよりも、当該残量の多い他ノードＮＤを、バックアップブロックＢＬｃの保存先として優先的に選択する。

さらに保存先設定部７５は、バックアップブロックＢＬｃの保存先となる他ノードＮＤを選択するルールを、ブロック生成の開始条件に応じて変更する。一例として、車両電源のオフ状態への切り替えが開始条件であった場合、保存先設定部７５は、自車両Ｖｉの近傍にて停車状態にある他車両Ｖａの車載ユニット１００を、保存先として優先的に選択する。また別の一例として、充電開始が開始条件であった場合、保存先設定部７５は、自車両Ｖｉの近傍にて充電状態にある他車両Ｖａの車載ユニット１００を、保存先として優先的に選択する。さらに別の一例として、部品交換の実施が開始条件であった場合、保存先設定部７５は、部品交換を行うディーラ等のサーバ２０を、保存先のノードＮＤとして優先的に選択できる。

ブロック管理部７６は、ブロック保存部６９へのブロックＢＬの保存を管理する。ブロック管理部７６は、新しいマスタブロックＢＬｍの連結が承認された場合に、当該マスタブロックＢＬｍを、バックアップブロックＢＬｃと共にブロック保存部６９に保存する。加えてブロック管理部７６は、他ノードＮＤからバックアップブロックＢＬｃを受信した場合、当該バックアップブロックＢＬｃを、マスタブロックＢＬｍと共にブロック保存部６９に保存する。

ブロック管理部７６は、マスタブロックＢＬｍの保存領域がブロック保存部６９に常に確保されるよう、バックアップブロックＢＬｃの受信を制御する。ブロック管理部７６は、ブロック保存部６９にバックアップブロックＢＬｃを保存可能な他車両Ｖａの数に、上限を設定している。加えてブロック管理部７６は、ブロック保存部６９に保存可能な一台の他車両ＶａあたりのバックアップブロックＢＬｃの数にも、上限を設定している。これらの上限を超える場合、ブロック管理部７６は、他ノードＮＤからのバックアップブロックＢＬｃの受け取りを拒否する。その結果、バックアップブロックＢＬｃは、多くの車載ユニット１００に分散された状態で、ネットワークＮＷに保存される。

ブロック送信部７７は、他ノードＮＤへ向けたブロックＢＬの送信を制御する。ブロック送信部７７は、新たに生成されたマスタブロックＢＬｍが承認された場合に、保存先設定部７５にて設定された保存先となるノードＮＤへ向けて、バックアップブロックＢＬｃを送信する。ブロック送信部７７は、保存先となる他ノードＮＤがＶ２Ｖ通信の通信範囲Ｒｃ内にいる場合、Ｖ２Ｖ通信によりバックアップブロックＢＬｃを保存先の他ノードＮＤへ向けて送信する。一方、保存先となる他ノードＮＤが通信範囲Ｒｃの外にいる場合、ブロック送信部７７は、Ｖ２Ｎ通信又はＶ２Ｉ通信により、ネットワーククラウドＮＷＣを通じて、バックアップブロックＢＬｃを保存先の他ノードＮＤへ向けて送信する。

加えてブロック送信部７７は、後述する復元要求及び提供要求を、ネットワーククラウドＮＷＣから取得する。復元要求及び提供要求には、要求元にて必要とされているブロックＢＬのノード識別情報ＩＤｎ（図５参照）等が付属している。ブロック送信部７７は、ブロック保存部６９に保存されているブロックＢＬの中から、取得したノード識別情報ＩＤｎ等に該当するブロックＢＬ、即ち、復元要求及び提供要求にて送信を要求されているブロックＢＬを探索する。要求にあるブロックＢＬがブロック保存部６９に保管されている場合、ブロック送信部７７は、該当するブロックＢＬを、要求元のノードＮＤ（サーバ２０等）へ向けて送信する。

図４，図１及び図３に示すサーバ２０は、各車両Ｖの修繕等を行うディーラ等に設置されたコンピュータである。一つのサーバ２０の演算処理能力は、一つの車載ユニット１００の演算処理能力よりも高い。サーバ２０は、ネットワークＮＷを構成する回線に実質的に常時接続されている。

ここで、履歴管理システム１０において、各車載ユニット１００にて生成したブロックＢＬを互いに持ち合うまでの処理は、実質全て、エッジ側となる各車両Ｖの各車載ユニット１００にて実施される。そのためサーバ２０は、ブロックＢＬを分散保存させる通常の処理に実質的に関与しないノードＮＤとなる。サーバ２０は、各車載ユニット１００間でのＰ２Ｐ通信の欠点を補完するノードＮＤとして機能し、各車載ユニット１００にて生じた異常に対処する。サーバ２０は、各車載ユニット１００に記憶された管理プログラムＰｃをチェックする機能と、異常と判定されたブロックＢＬ群を復元する機能とを備えている。

サーバ２０は、プロセッサ２１、ＲＡＭ２２、メモリ装置２３及び入出力インターフェースを有する制御回路を主体に構成されている。プロセッサ２１は、ＲＡＭ２２と結合された演算処理のためのハードウェアであって、種々のプログラムを実行可能である。メモリ装置２３は、不揮発性の記憶媒体を含む構成であって、プロセッサ２１によって実行される種々のプログラムを格納している。メモリ装置２３に格納されたプログラムには、履歴管理システム１０を保全する保全プログラムが少なくとも含まれている。保全プログラムは、後述する各復元処理（図１０及び図１１参照）をプロセッサ２１に実施させる。プロセッサ２１による保全プログラムの実行により、プログラム確認部３１、復元要求部３２及びデータ復元部３３等の機能部がサーバ２０に実装される。

プログラム確認部３１は、各車載ユニット１００からの問い合わせに応じて、各車載ユニット１００の管理プログラムＰｃが最新のバージョンであるか否かを確認する。プログラム確認部３１は、問い合わせ元となる車載ユニット１００へ向けて、確認結果を送信する。加えてプログラム確認部３１は、旧バージョンの管理プログラムＰｃを使用している車載ユニット１００へ向けて、最新バージョンの管理プログラムＰｃを送信する。

復元要求部３２は、ネットワークＮＷへの接続状態にある各ノードＮＤ、主に車載ユニット１００へ向けて、ブロックＢＬの提供を呼びかける要求をブロードキャスト配信する。ここで、ブロック保存部６９のデータに異常の虞がある車両Ｖを、特定車両Ｖｒとする。特定車両Ｖｒは、ユーザによってディーラ等に持ち込まれる。復元要求では、特定車両ＶｒのマスタブロックＢＬｍのバックアップを保管している車両Ｖ（車載ユニット１００）に対し、そのバックアップブロックＢＬｃの送信が要求される。復元要求部３２は、特定車両Ｖｒに搭載された車載ユニット１００のノード識別情報ＩＤｎ（図５参照）を、復元要求と共に各ノードＮＤへ向けて配信する。

復元要求部３２は、復元要求の送信後、さらに提供要求をネットワークＮＷにブロードキャスト配信する。提供要求では、特定車両Ｖｒのブロック保存部６９にバックアップされていたバックアップブロックＢＬｃの送信が要求される。復元要求部３２は、ノード識別情報ＩＤｎ（図５参照）にブロックハイトを組み合わせたデータを、提供要求と共に配信する。こうしたデータの配信により、復元要求部３２は、どのノードＮＤにて生成された何番目のブロックＢＬの送信が必要とされているのかを、各ノードＮＤに通知する。

データ復元部３３は、復元要求に応じて各ノードＮＤから送信されたバックアップブロックＢＬｃを受信する。データ復元部３３は、収集したバックアップブロックＢＬｃをマスタブロックＢＬｍとし、ブロックハイトの情報に基づき時系列で連結させて、特定車両ＶｒのブロックチェーンＢＣを復元する。データ復元部３３は、提供要求に応じて各ノードＮＤから送信されたブロックＢＬを受信し、バックアップブロックＢＬｃとして復元する。こうしてデータ復元部３３により復元されたブロックチェーンＢＣ及び各バックアップブロックＢＬｃの復元データは、特定車両Ｖｒのブロック保存部６９に複製される。

次に、各車載ユニット１００にて生成される各ブロックＢＬ及びブロックチェーンＢＣの詳細を、図５に基づき、図３を参照しつつ、さらに説明する。

各ブロックＢＬは、ブロックハイト、ノード識別情報ＩＤｎ及びブロック特定情報ＩｎＢに加えて、トランザクションとしての履歴情報、承認者情報、及びブロックヘッダを含むデータ構造である。トランザクション（TX1〜TX3）は、情報収集部７０によって収集され、一つのブロックＢＬに少なくとも一つ以上含まれている。一つのブロックＢＬに含まれるトランザクションの数は、適宜変更されてよい。各トランザクションは、当該トランザクションの発生時を示すタイムスタンプ（TS1〜TS3）と紐付けられた状態で記録されている。

承認者情報（Aut_A〜Aut_C）は、そのブロックＢＬを承認した承認ノードＮＤ２（図３参照）を示す情報である。承認者情報は、承認ノードＮＤ２から受信する情報であり、個々の承認ノードＮＤ２を示す固有のハッシュ値である。各ブロックＢＬには、承認ノード数Ｎに対応した数の承認者情報が記録されている。

ブロックヘッダ（BLOCK Header）には、ブロック生成時を示すタイムスタンプ（Time Stamp）、トランザクションのマークルルート、承認者情報のマークルルート、及び前ブロックＢＬのヘッダハッシュ値が含まれている。これらの情報は、ブロック生成部７１によって記録される。

トランザクションのマークルルート（TX-M_Root）は、ブロックＢＬに含まれる一つ以上のトランザクションのデータの要約であり、個々のトランザクションを末端とするマークルツリーのルートハッシュ値である。承認者のマークルルート（Aut-M_Root）は、複数の承認ノードＮＤ２から取得したハッシュ値の要約であり、各承認ノードＮＤ２の固有のハッシュ値を末端とするマークルツリーのルートハッシュ値である。

前ブロックＢＬのヘッダハッシュ値（Prev.Hash）は、前ブロックＢＬのブロックヘッダのデータをハッシュ関数に入力して得られる値である。ブロックチェーンＢＣは、各ブロックＢＬのブロックヘッダをハッシュ化し、次のブロックヘッダに組み込む入れ子構造を形成している。そのため、一つのブロックＢＬのトランザクション等を変更した場合、以降のブロックＢＬのヘッダハッシュ値も連鎖的に異なる値となる。故に、ヘッダハッシュ値の確認により、トランザクション等の破損及び改ざん等が検証可能となる。

以上のヘッダハッシュ値及び各マークルルートの演算には、ＳＨＡ−２５６等のハッシュ関数が使用される。このようなハッシュ関数の種類及びハッシュ値のビット数等の仕様は、適宜変更されてよい。例えば、ＭＤ−５、ＳＨＡ−１、ＳＨＡ−５１２及びＳＨＡ−３等のハッシュ関数が、ハッシュ値の生成に使用されてよい。また、ヘッダハッシュ値を算出するハッシュ関数と、各マークルルートを算出するハッシュ関数とは、互いに同一であってもよく、互いに異なっていてもよい。

次に、管理プログラムＰｃによる管理のもと、新たに収集された履歴情報からブロックＢＬを生成し、ブロックチェーンＢＣへの連結とバックアップの実施とを行うチェーン追加処理の詳細を、図６〜図９に基づき、図１，図３及び図５を参照しつつ説明する。図６に示すメイン処理は、上述の開始条件の成立に基づき、車載ユニット１００によって開始される。

メイン処理のＳ１０では、ブロック生成処理（図７参照）により、車両Ｖにて収集された履歴情報から、ブロックチェーンＢＣに新たに追加するブロックＢＬ（マスタブロックＢＬｍ）を生成し、Ｓ２０に進む。Ｓ２０では、ブロック承認処理（図８参照）により、Ｓ１０にて新たに生成したブロックＢＬの承認を、車両Ｖと通信可能な複数の他ノードＮＤに依頼し、Ｓ３０に進む。

Ｓ３０では、保存先設定処理（図９参照）により、Ｓ２０にて承認されたブロックＢＬのバックアップの保存先を、車両Ｖと通信可能な他ノードＮＤの中から設定し、Ｓ４０に進む。一つのブロックＢＬが新規に生成される度にＳ３０が実施されるため、個々のブロックＢＬのバックアップの保存先は、ブロック単位で設定されることとなる。

Ｓ４０以降の処理では、Ｓ３０の保存先設定処理の設定結果に基づき、優先順位の高い他ノードＮＤへ向けて、バックアップブロックＢＬｃの保存依頼を順に送信する。具体的に、Ｓ４０では、高優先度の他ノードＮＤ（例えば、最後の承認ノード）へ向けて、バックアップブロックＢＬｃの保存依頼を送信し、Ｓ５０に進む。Ｓ４０による保存依頼の送信先となる他ノードＮＤ（バックアップノード）は、保存依頼を受信し（Ｓ９１）、保存依頼の承認可否を送信する（Ｓ９２）。ノード数及びブロック数のいずれかの上限に達している場合には、受け取りを拒否する旨の通知が返信される。

Ｓ５０では、バックアップノードからの承認可否の結果を受信し、Ｓ６０に進む。Ｓ６０では、保存を承認する返信があったか否かを判定する。保存を拒否する返信を受け取った場合、又は返信がないままタイムアウトした場合、Ｓ６０からＳ４０に戻り、別の他ノードＮＤへ向けて保存依頼を送信する。一方、Ｓ６０にて、保存を承認する返信を取得したと判定した場合、Ｓ７０に進む。

Ｓ７０では、保存先となるバックアップノードへ向けて、バックアップブロックＢＬｃを送信し、Ｓ８０に進む。Ｓ７０にて送信されたバックアップブロックＢＬｃは、バックアップノードにて受信され、バックアップノードのブロック保存部６９に保存される（Ｓ９３）。

Ｓ８０では、バックアップブロックＢＬｃの送信先の数が、予め規定されたバックアップノード数Ｋに達したか否かを判定する。Ｓ８０にて、送信先の数がバックアップノード数Ｋよりも少ない場合、Ｓ４０に戻り、別の他ノードＮＤへ向けて保存依頼を送信する。一方、Ｓ８０にて、送信先の数がバックアップノード数Ｋに達したと判定した場合、チェーン追加処理を終了する。

次に、Ｓ１０にてサブ処理として実施されるブロック生成処理、Ｓ２０にてサブ処理として実施されるブロック承認処理、Ｓ３０にてサブ処理として実施される保存先設定処理、の各詳細を、順に説明する。

図７に示すブロック生成処理のＳ１０１では、トランザクション（TX1〜TX3）となる履歴情報、及び履歴情報を取得した時刻を示すタイムスタンプ（TS1〜TS3）を収集し、Ｓ１０２に進む。Ｓ１０２では、Ｓ１０１にて、トランザクションを収集できたか否かを判定する。Ｓ１０２にて、トランザクションが無いと判定した場合、ブロックＢＬの新規生成を行わず、チェーン追加処理を終了する。一方、Ｓ１０２にて、少なくとも一つのトランザクションを収集したと判定した場合、Ｓ１０３に進む。

Ｓ１０３では、ブロック保存部６９に現在保存されているバックアップブロックＢＬｃのリストをブロック特定情報ＩｎＢ（Info_BUP）として作成し、Ｓ１０４に進む。Ｓ１０４では、Ｓ１０１にて収集したトランザクションのマークルルート（TX-M_Root）を算出し、Ｓ１０５に進む。Ｓ１０５では、新たに追加するブロックＢＬを生成し、メイン処理のＳ２０に進む。Ｓ１０５では、例えば履歴情報が収集された車両Ｖを示すノード識別情報ＩＤｎ等が、ブロックＢＬに記録される。一方で、Ｓ１０５にて生成されるブロックＢＬは、承認前であるため、承認者情報及び承認者のマークルルートを有していない状態である。

図８に示すブロック承認処理では、一つのノードＮＤ（依頼ノードＮＤ１）の承認依頼部７２による承認依頼に基づき、他の複数のノードＮＤ（承認ノードＮＤ２）が、依頼ノードＮＤ１にて新しく生成された新規ブロックＢＬの正当性を検証する。ブロック承認処理のＳ１１１では、管理プログラムＰｃのバージョンを示すデータと、管理プログラムＰｃの本体（全体）のデータとを、それぞれハッシュ関数に入力し、二つのハッシュ値（Ｘ１，Ｙ１）を生成して、Ｓ１１２に進む。Ｓ１１２では、承認の依頼先となる承認ノードＮＤ２を設定し、承認ノードＮＤ２へ向けて、承認依頼及びハッシュ値（Ｘ１，Ｙ１）を送信する。

Ｓ１１３では、承認ノードＮＤ２が、承認依頼及びハッシュ値（Ｘ１，Ｙ１）を受信する。Ｓ１１４では、承認ノードＮＤ２に保存されている管理プログラムＰｃを、ブロック保存部６９から読み出す。そして、依頼ノードＮＤ１と同一のハッシュ関数を用いて、自ノードの管理プログラムＰｃのデータを入力とした二つのハッシュ値（Ｘａ，Ｙａ）を生成する。

Ｓ１１５では、Ｓ１１２にて受信した依頼ノードＮＤ１のハッシ値（Ｘ１，Ｙ１）と、Ｓ１１４にて生成した承認ノードＮＤ２のハッシュ値（Ｘａ，Ｙａ）とを比較し、共に同一であるか否かを判定する。即ち、Ｓ１１５では、依頼ノードＮＤ１及び承認ノードＮＤ２の使用する管理プログラムＰｃが互いに実質的に同一であるか否かを判定する。Ｓ１１５にて、二つのハッシュ値が共に同一である（Ｘ１＝Ｘａ，Ｙ１＝Ｙａ）と判定した場合、Ｓ１１６に進む。Ｓ１１６では、ブロックＢＬの正当性を検証するための検証用データの提供を、依頼ノードＮＤ１に要求する。

一方、Ｓ１１５にて、少なくとも一方のハッシュ値が相違していると判定した場合、承認ノードＮＤ２は、一連の処理を終了し、サーバ２０のプログラム確認部３１（図４参照）へ向けて、管理プログラムＰｃのバージョン等を問い合わせる。プログラム確認部３１は、依頼ノードＮＤ１及び承認ノードＮＤ２の各管理プログラムＰｃについて、正しい（最新）であるか否かを判断する。承認ノードＮＤ２は、管理プログラムＰｃに問題が無い旨の通知をプログラム確認部３１から取得した場合、依頼ノードＮＤ１の管理プログラムＰｃに問題がある旨の通知を、依頼ノードＮＤ１へ向けて送信してもよい。また、各管理プログラムＰｃのプログラムバージョンのハッシュ値は、エッジ側である各ノードＮＤではなく、クラウド側となるサーバ２０にて生成され、各ノードＮＤに通知されてもよい。こうした処理によれば、管理プログラムＰｃのプログラムバージョンの不整合が、事前にサーバ２０側にて確認可能となる。

Ｓ１１６にて送信された検証用データの要求は、Ｓ１１７にて、依頼ノードＮＤ１に取得される。そしてＳ１１８にて、依頼ノードＮＤ１は、検証用データを承認ノードＮＤ２へ向けて送信する。検証用データには、前ブロックＢＬのブロックヘッダに含まれる前々ブロックＢＬのヘッダハッシュ値（第一データ）、前ブロックＢＬのブロックヘッダの生成に必要な他のデータ（第二データ）が含まれる。加えて検証データには、追加されるブロックＢＬに含まれる前ブロックＢＬのブロックヘッダをハッシュ化したヘッダハッシュ値が含まれる。

Ｓ１１８にて送信された検証用データは、Ｓ１１９にて、承認ノードＮＤ２に取得される。そして承認ノードＮＤ２は、Ｓ１２０にて、検証演算を実施する。具体的に、検証演算では、Ｓ１１９にて取得した第一データ及び第二データから、承認ノードＮＤ２の管理プログラムＰｃに基づき、前ブロックＢＬのヘッダハッシュ値を算出する。そして、Ｓ１１９にて受信した依頼ノードＮＤ１にて算出のヘッダハッシュ値が、承認ノードＮＤ２にて算出されたヘッダハッシュ値と一致しているか否かを判定する。これら二つのハッシュ値が一致している場合、承認ノードＮＤ２は、新しいブロックＢＬの追加を承認する。一方、二つのハッシュ値が異なっている場合、承認ノードＮＤ２は、新しいブロックＢＬの追加を承認しない。

以上のように、ブロック承認処理では、マスタブロックＢＬｍを生成した依頼ノードＮＤ１とは異なる少なくとも一つの承認ノードＮＤ２にて、新規のマスタブロックＢＬｍに含まれるヘッダハッシュ値が計算される。そして、正しい（最新）の管理プログラムＰｃを用いてブロックＢＬを生成しており、且つ、その結果として得られたヘッダハッシュ値が正しいことを持って、新たに生成されたブロックＢＬの正当性が確認される。

Ｓ１２１では、Ｓ１２０による検証結果を依頼ノードＮＤ１へ向けて送信する。Ｓ１２０にて、ブロックＢＬの追加を承認した場合、追加を承認する旨の通知と、承認ノードＮＤ２の固有のハッシュ値を依頼ノードＮＤ１へ向けて送信する。一方、Ｓ１２０にて、ブロックＢＬの追加を承認しなかった場合、追加を承認しない旨の通知を依頼ノードＮＤ１へ向けて送信する。

Ｓ１２１にて送信された承認可否の結果等は、Ｓ１２２にて、依頼ノードＮＤ１に取得される。そして、承認する旨の通知を取得していた場合、Ｓ１２３にて、承認ノードＮＤ２のハッシュ値を承認者情報として、ブロックＢＬに記録し、Ｓ１２４に進む。Ｓ１２４では、承認を肯定する通知を、承認ノード数Ｎの三分の二（過半数）以上から取得できたか否かを判定する。Ｓ１２４にて、承認を肯定する通知が承認ノード数Ｎの三分の二未満であると判定した場合、Ｓ１１２に戻り、別の承認ノードＮＤ２へ向けて、承認依頼等を送信する。

一方、承認ノードＮＤ２にて算出されたヘッダハッシュ値が、依頼ノードＮＤ１にて生成されたヘッダハッシュ値と異なる旨の通知を取得していた場合、Ｓ１２５に進む。Ｓ１２５では、依頼ノードＮＤ１の保管データに改ざん等の異常があると判定し、チェーン追加処理を終了する。異常判定の結果は、車両Ｖに搭載された表示装置等を通じてユーザに通知される。

一方、Ｓ１２４にて、承認を肯定する通知が承認ノード数Ｎの三分の二以上から取得した場合、承認完了と判定し、Ｓ１２６に進む。Ｓ１２６では、承認者情報であるハッシュ値のマークルルートを算出し、当該マークルルートをブロックＢＬに記録して、Ｓ１２７に進む。Ｓ１２７では、新しいブロックＢＬをブロックチェーンＢＣに連結させて、メイン処理のＳ３０に進む。

図９に示すブロック承認処理のＳ１３１では、チェーン追加処理の開始条件を把握し、Ｓ１３２に進む。Ｓ１３２では、自車両Ｖｉの通信範囲Ｒｃ内にいる他ノードＮＤ（他車両Ｖａ）を把握し、Ｓ１３３に進む。Ｓ１３３では、通信可能な状態にある他ノードＮＤについて、ブロック保存部６９の記憶容量の残量を把握し、Ｓ１３４に進む。Ｓ１３４では、Ｓ１３１〜Ｓ１３３にて把握した情報に基づき、他ノードＮＤの中から、バックアップブロックＢＬｃの保存先とするノードを選択し、且つ、保存先とする優先順位を設定して、メイン処理のＳ４０に進む。

次に、Ｓ１２５での異常判定に基づき、ブロック保存部６９の保管データを復元する一連の復元処理の詳細を、図１０及び図１１に基づき、図１２及び図５を参照しつつ説明する。保管データの復元は、上述したように、特定車両Ｖｒが搬入されたディーラのサーバ２０によって実施される。サーバ２０は、ブロックチェーンＢＣを復元するチェーン復元処理と、バックアップブロックＢＬｃを復元するバックアップ復元処理とを順に実施する。尚、図１２では、ユーザ１の車両Ｖ１が特定車両Ｖｒとされる。また、ユーザ２の車両Ｖ２は、ネットワークＮＷに接続されていない状態である。

図１０に示すチェーン復元処理のＳ１６１では、特定車両Ｖｒのノード識別情報ＩＤｎと共に、復元要求をネットワークＮＷに一斉配信する。Ｓ１６１の復元要求は、Ｓ１６２にて、他ノードＮＤに受信される。復元要求を受信した他ノードＮＤは、Ｓ１６３にて、提供ノードとして、ノード識別情報ＩＤｎの一致するバックアップブロックＢＬｃが自らのブロック保存部６９にあるか否かを照合する。例えば、ユーザ４の車両Ｖ４のように、該当するバックアップブロックＢＬｃが無い提供ノードは、処理を終了する。

一方で、ユーザ３の車両Ｖ３のように、該当するバックアップブロックＢＬｃがあると判定した提供ノードは、Ｓ１６４を実施する。Ｓ１６４では、バックアップブロックＢＬｃ（ＢＬ１，ＢＬ２）を所持している旨の通知を、要求元であるサーバ２０へ向けて送信する。Ｓ１６４にて送信された所持通知は、Ｓ１６５にてサーバ２０に受信される。そして、Ｓ１６６にて、サーバ２０は、バックアップブロックＢＬｃの送信依頼を、提供ノードへ向けて送信する。

Ｓ１６６にて送信された送信依頼がＳ１６７にて提供ノードに受信されると、提供ノードは、Ｓ１６８にて、必要とされているバックアップブロックＢＬｃの送信を開始する。送信されるバックアップブロックＢＬｃは、特定車両Ｖｒのノード識別情報ＩＤｎが記録されたブロックＢＬ（ＢＬ１，ＢＬ２）である。こうして送信されたバックアップブロックＢＬｃは、Ｓ１６９にて、サーバ２０に受信される。サーバ２０は、受信したバックアップブロックＢＬｃから、マスタブロックＢＬｍを復元し、Ｓ１７０に進む。Ｓ１７０では、ブロックハイト、タイムスタンプ又はブロックＢＣ間の前後関係を示す情報に基づき、回収された各マスタブロックＢＬｍを時系列に連結させて、ブロックチェーンＢＣを復元し、Ｓ１７１に進む。

Ｓ１７１では、マスタブロックＢＬｍの不足を判定する。Ｓ１７１にて、マスタブロックＢＬｍに抜けがあると判定した場合、Ｓ１６５に戻り、不足しているブロックＢＬを他の提供ノードから受信する。一方、Ｓ１７１にて、全てのマスタブロックＢＬｍを回収し、ブロックチェーンＢＣを復元できたと判定した場合、チェーン復元処理を終了する。

図１１に示すバックアップ復元処理のＳ１８１では、サーバ２０が、チェーン復元処理にて復元されたブロックチェーンＢＣから、ブロック特定情報ＩｎＢを読み出し、Ｓ１８２に進む。ブロック特定情報ＩｎＢは、最後のブロックＢＬ（ＢＬ２）から読み出される。Ｓ１８２では、ブロック特定情報ＩｎＢに記録のあるバックアップブロックＢＬｃと同一のブロックＢＬの提供要求を、ネットワークＮＷに一斉配信する。提供要求の対象となる各ブロックＢＬは、ノード識別情報ＩＤｎ及びブロックハイトの組み合わせによって特定される。

Ｓ１８２による復元要求は、Ｓ１８３にて、各提供ノードに受信される。提供要求を受信した提供ノードは、Ｓ１８４にて、該当するブロックＢＬが自らのブロック保存部６９に保管されているか否かを照合する。Ｓ１８４にて、ブロックＢＬがあると判定した場合、Ｓ１８５に進む。

Ｓ１８５では、要求のあったブロックＢＬを所持している旨の通知を、要求元であるサーバ２０へ向けて送信する。Ｓ１８５にて送信された所持通知は、Ｓ１８６にてサーバ２０に受信される。そして、Ｓ１８７にて、サーバ２０は、ブロックＢＬの送信依頼を、提供ノードへ向けて送信する。

Ｓ１８７にて送信された送信依頼がＳ１８８にて提供ノードに受信されると、提供ノードは、Ｓ１８９にて、必要とされているブロックＢＬの送信を開始する。Ｓ１８９にて送信されたブロックＢＬは、Ｓ１９０にて、サーバ２０に受信される。そしてサーバ２０は、受信したブロックＢＬから、バックアップブロックＢＬｃを復元し、Ｓ１９１に進む。

Ｓ１９１では、Ｓ１８１にて取得したブロック特定情報ＩｎＢを参照し、復元されたバックアップブロックＢＬｃの不足を判定する。Ｓ１９１にて、バックアップブロックＢＬｃが不足していると判定した場合、Ｓ１８６に戻り、別の提供ノードからブロックＢＬをさらに取得する。例えば、ユーザ４の車両Ｖ４から二つのブロックＢＬ４，ＢＬ２を受信しても、バックアップブロックＢＬｃは不足した状態である。この場合、さらにユーザ３の車両Ｖ３から二つのブロックＢＬ１，ＢＬ３を受信する。そしてさらに、ユーザ５の車両Ｖ５から一つのブロックＢＬ１を受信する。こうした処理を継続し、Ｓ１９１にて、全てのバックアップブロックＢＬｃを復元できた判定した場合、バックアップ復元処理を終了する。

ここまで説明した本実施形態では、ブロックＢＬが生成されると、生成されたブロックＢＬのバックアップの保存先は、自車両Ｖｉと通信可能な他ノードＮＤの中から、ブロック単位で設定される。故に、ブロックチェーンＢＣを形成する全ブロックＢＬが全ノードＮＤによって共有されることが回避され得る。換言すれば、各車載ユニット１００にて生成されたブロックＢＬは、全てのノードＮＤに複製されず、ごく一部の複数のノードＮＤとの間で共有されるに留められる。以上によれば、ブロックＢＬの共有に起因する通信量の増加及び各ノードＮＤの保存データ量の増加は、抑制され得る。したがって、ブロックチェーンＢＣの技術を用いて車両Ｖの履歴情報を保管するのに適した履歴管理が実現される。

加えて本実施形態では、新たに生成されたブロックＢＬの承認が複数の承認ノードＮＤ２に依頼される。そして、バックアップの保存先となるバックアップノード数Ｋは、ブロックＢＬの承認の依頼先となる承認ノード数Ｎよりも少ない設定である。こうした設定により、バックアップノード数Ｋが抑制されれば、通信量及び保存データ量の増加は、いっそう抑制可能となる。

また本実施形態での承認ノード数Ｎは、奇数とされており、より望ましくは三以上の奇数とされる。こうした設定であれば、承認ノードＮＤ２の多数決に基づき、新規に作成されたブロックＢＬの連結の可否が判断可能となる。以上によれば、新規のブロックＢＬを追加するか否かの判断ロジックが単純化され得る。

さらに本実施形態におけるバックアップノードの少なくとも一つは、ヘッダハッシュ値の計算を行った複数の承認ノードＮＤ２の中から選択される。多くの場合、バックアップを送信しようとするタイミングでも、ヘッダハッシュ値の計算を依頼した承認ノードＮＤ２と自ノードＮＤとの通信可能な状態は、維持されていると想定される。故に、承認ノードＮＤ２からバックアップノードを選択すれば、ブロック追加の承認後、バックアップブロックＢＬｃを送信する処理への円滑な遷移が可能になる。

そして、ブロック追加の承認を後で実施した承認ノードＮＤ２ほど、バックアップノードとして選択される優先順位が高められる。こうした設定であれば、自ノードＮＤは、通信可能な状態を継続中の承認ノードＮＤ２を速やかにバックアップノードとして選択し、バックアップブロックＢＬｃの送信を実行できる。以上のことから、承認を最後に実施した承認ノードＮＤ２は、最初のバックアップノードに設定されるのが望ましい。

加えて本実施形態では、自ノードＮＤと通信可能な複数の他ノードＮＤのうちで、ブロック保存部６９の残容量の少ないノードよりも、ブロック保存部６９の残容量の多いノードが、バックアップノードとして優先的に選択される。このように、ブロック保存部６９の残容量が多いノードＮＤにバックアップブロックＢＬｃが優先的に移譲されれば、一つのノードＮＤへのバックアップブロックＢＬｃの集中が回避され得る。その結果、バックアップブロックＢＬｃがネットワークＮＷにおいて多くのノードＮＤに分散保存され易くなるため、バックアップの作成を制限していても、纏まったデータの損失が発生し難くなる。

また本実施形態では、バックアップノードを選択するルールが、新規ブロックＢＬの生成を開始する開始条件に応じて変更される。こうした制御によれば、自ノードＮＤは、ブロック生成を開始したタイミングにて自車両Ｖｉが置かれている状況に合わせて、通信可能な状態を維持し易い他ノードＮＤを優先的にバックアップノードに設定し得る。以上によれば、車両Ｖに搭載された車載ユニット１００をノードＮＤとして機能させる履歴管理システム１０であっても、バックアップブロックＢＬｃの送信は、安定的に実施可能となる。

加えて本実施形態では、自車両Ｖｉの履歴情報からマスタブロックＢＬｍを生成する車載ユニット１００が、他車両Ｖａの履歴情報のバックアップブロックＢＬｃを保管するノードＮＤとして機能する。故に、バックアップブロックＢＬｃを保管するための専用サーバ又は専用車載器等の設置の必要性が低減可能となる。

また本実施形態では、一つのブロック保存部６９にバックアップブロックＢＬｃを保存可能な他車両Ｖａの数には、上限が設定されている。こうした設定であれば、車載ユニット１００のブロック保存部６９に、マスタブロックＢＬｍ及びバックアップブロックＢＬｃの両方が保存可能であっても、マスタブロックＢＬｍを保存するための記憶領域が確保され得る。加えて、一つの車載ユニット１００へのバックアップの集中が回避され得るため、纏まったデータの損失が防止可能となる。

さらに本実施形態では、ブロック保存部６９に保存可能な一つの他車両Ｖａ（他ノードＮＤ）あたりのバックアップブロックＢＬｃの数には、上限が設定されている。こうした設定であれば、一つの車両ＶのバックアップブロックＢＬｃは、一つの車載ユニット１００に集中的に保管されることなく、多数の車載ユニット１００に分散保存され易くなる。以上によれば、一つの車載ユニット１００の保管データに異常が生じた場合に、別の車載ユニット１００のバックアップの大半が一斉に失われてしまう事態は、回避される。

加えて本実施形態では、Ｖ２Ｖ通信の通信範囲Ｒｃにいる他ノードＮＤがバックアップノードとして優先的に選択される。そして、通信範囲Ｒｃにバックアップノードがいる場合、Ｖ２Ｖ通信によってバックアップブロックＢＬｃが送信される。以上のように、Ｖ２Ｖ通信を積極的に活用すれば、バックアップに起因するネットワーククラウドＮＷＣ側のトラフィック増加が抑制され得る。

一方で、Ｖ２Ｖ通信の通信範囲Ｒｃに他ノードＮＤがいない場合、保存先設定部７５は、Ｖ２Ｖ通信以外の通信手段を用いて、Ｖ２Ｖ通信の通信範囲外のバックアップノードへ向けて、バックアップブロックＢＬｃを送信できる。故に、周囲に他車両ＶａがいないようなシーンでブロックＢＬが生成された場合でも、車載ユニット１００は、バックアップノードへ向けたバックアップの送信を実施できる。

また本実施形態では、マスタブロックＢＬｍが生成されるとき、ブロック保存部６９に保存されているバックアップブロックＢＬｃを特定可能にするブロック特定情報ＩｎＢが、マスタブロックＢＬｍに記録される。故に、保存データに異常が生じた特定車両Ｖｒについて、そのブロックチェーンＢＣを提供ノードから送信されたブロックＢＬで復元できれば、ブロック保存部６９にバックアップされていた他車両ＶａのバックアップブロックＢＬｃが特定できる。

以上によれば、特定車両Ｖｒのブロック保存部６９は、自車両ＶｉのマスタブロックＢＬｍだけでなく、他車両ＶａのバックアップブロックＢＬｃも復元された状態まで戻り得る。故に、バックアップブロックＢＬｃが完全に失われて、ブロックチェーンＢＣの復元に必要なブロックＢＬの回収が不可能となる事態は、回避され得る。したがって、履歴情報を含んだブロックＢＬを限定的にバックアップする形態であっても、ブロックチェーンＢＣの復元が可能となる。

さらに本実施形態では、履歴情報を収集した車両Ｖを示す車両識別情報として、ノード識別情報ＩＤｎがマスタブロックＢＬｍに記録されている。故に、バックアップブロックＢＬｃを保存している各ノードＮＤは、特定車両Ｖｒのノード識別情報ＩＤｎを復元要求と共に取得することで、特定車両ＶｒについてのバックアップブロックＢＬｃが自らのブロック保存部６９にあるか否かを正しく判断し得る。

以上によれば、バックアップブロックＢＬｃの保存先がブロック単位で設定されても、特定車両ＶｒのブロックチェーンＢＣの復元に必要なバックアップブロックＢＬｃは、保存先とされた他ノードＮＤから適切に回収可能となる。したがって、履歴情報を含んだブロックＢＬを限定的にバックアップする形態であっても、ブロックチェーンＢＣの復元が可能となる。

加えて本実施形態では、復元要求に基づき送信されたバックアップブロックＢＬｃからブロックチェーンＢＣを復元したうえで、復元されたブロックチェーンＢＣの最新のブロックＢＬに記録されたブロック特定情報ＩｎＢが読み出される。そして、読み出されたブロック特定情報ＩｎＢに記録されていたバックアップブロックＢＬｃの提供が呼びかけられる。以上によれば、サーバ２０は、データ異常の生じる直前にブロック保存部６９に保管されていたバックアップブロックＢＬｃを正確に把握したうえで、各提供ノードにブロックＢＬの送信を呼びかけることができる。

また本実施形態では、承認ノードＮＤ２でのヘッダハッシュ値の検算に基づき、新規ブロックＢＬの追加が承認される。このように、新規ブロックＢＬを追加するタイミングで、直前のブロックヘッダのヘッダハッシュ値を確認すれば、トランザクションのデータ又は管理プログラムＰｃの異常が、適切に検出可能となる。故に、正当性を検証されたブロックＢＬの鎖状連結を繰り返して、ブロックチェーンＢＣを生成していくことが可能になる。

さらに本実施形態では、新規に生成されたブロックＢＬの正当性を確認するためのヘッダハッシュ値を承認ノードＮＤ２にて算出するステップの前に、依頼ノードＮＤ１及び承認ノードＮＤ２の保有する管理プログラムＰｃの同一性が確認される。故に、算出されたヘッダハッシュ値が互いに異なっていた場合、車載ユニット１００は、管理プログラムＰｃの異常ではなく、トランザクション等のデータに異常があると、高精度に推定可能となる。

尚、上記実施形態では、マスタブロックＢＬｍが「自車ブロック」に相当し、バックアップブロックＢＬｃが「他車ブロック」に相当し、通信範囲Ｒｃが「特定範囲」に相当する。また、バックアップノード数Ｋが「バックアップの保存先となるノードの数」に相当し、承認ノード数Ｎが「ブロックの承認の依頼先となるノードの数」に相当する。さらに、サーバ２０が「コンピュータ」に相当し、車載ユニット１００が「履歴管理装置」及び「コンピュータ」に相当する。

（他の実施形態）
以上、本開示の一実施形態について説明したが、本開示は、上記実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。

上記実施形態において、バックアップを分散保存する一つのネットワークの全ノード数は、適宜変更されてよい。例えば、特定の規格を遵守した車載ユニットであれば、実質的な上限無く、ネットワークへの参加が許容されてもよい。この場合、車両を製造したメーカーに関係なく、各車載ユニットは、バックアップブロックを相互に持ち合うことができる。

一方、一つのネットワークに参加するノードには、一定の制限が設定されていてもよい。例えば、特定メーカーの車両に搭載された車載ユニットのみで、バックアップを分散保存する一つのネットワークが形成されてもよい。さらに、特定地域又は特定期間にて登録された車両の車載ユニットが、一つのネットワークを形成していてもよい。

そして、バックアップノード数Ｋ及び承認ノード数Ｎは、一つのネットワークに含まれる全ノード数よりも少ない値であれば、クラウド側のトラフィックを顕著に増加させない範囲で、適否設定されてよい。加えて、バックアップノード数Ｋは、承認ノード数Ｎと同じ値に設定されてもよく、又は承認ノード数Ｎよりも大きい値に設定されてもよい。さらに、承認ノード数Ｎは、偶数であってもよい。

バックアップノードを選択するルールは、適宜変更可能である。例えば保存先設定部は、バックアップを保存する車両が地理的に分散するように、ＧＮＳＳ信号等に基づいて、バックアップノードを選択してもよい。また保存先設定部は、承認ノードとは異なるノードを、バックアップノードとして優先的に選択してもよい。また保存先設定部は、過去にバックアップノードとして選択したことのある他ノードを優先的に今回のバックアップノードに選択してもよく、又は今回のバックアップノードとする対象から除外するようにしてもよい。加えて、保存先設定部は、開始条件に基づく優先順位の付与ルールの変更、及びメモリ残量に基づく優先順位の設定等を実施しなくてもよい。

上記実施形態にて、ブロック保存部に保存されるバックアップブロックについて、他ノード数及び一つのノードあたりのブロック数には、共に上限が設けられていた。これらの上限の具体的な値は、例えばブロック保存部の記憶容量等に応じて適宜変更されてよい。加えて、これらの上限は、設定されなくてもよい。

ブロックチェーンを構成する個々のブロックの内容及びデータサイズ等の仕様は、適宜変更されてよい。例えば、ブロックにトランザクションとして記録される履歴情報は、上記実施形態で例示した情報に限定されない。また、各トランザクションの取得時を示すタイムスタンプは、トランザクションと共にハッシュ値化されて、トランザクションのマークルルートに組み入れられてもよい。

さらに、ブロック特定情報及びノード識別情報等は、ブロックヘッダに組み入れられていてもよい。加えて、上記実施形態のノード識別情報は、車両識別情報としても機能する情報であった。しかし、各ブロックには、ノード識別情報と車両識別情報とが、別々の情報として記述されていてもよい。

上記実施形態のブロック生成部は、保管している各バックアップブロックのノード識別情報及びブロックハイトを収集し、新たに生成するマスタブロックに、ブロック特定情報として記録していた。こうしたブロック特定情報の内容は、バックアップブロックの保管情報を復元可能であれば、適宜変更されてよい。例えばブロックハイトに替えて、ブロックヘッダに記述されたタイムスタンプが、ブロック特定情報として残されてもよい。

上記実施形態では、一つの車両の履歴情報を保管するブロックチェーンが、車載ユニット毎に生成されていた。即ち、各車載ユニットのブロックチェーンは、互いに独立した存在であった。しかし、ヘッダハッシュ値を車載ユニット間で送信する処理により、複数の車載ユニットにて生成されるブロックが、ハッシュ値によってデータ的に連結されてもよい。以上によれば、一つのネットワークで収集された複数車両の履歴情報が、一つのブロックチェーンに集約される。その結果、トライザクション等の改ざんは、いっそう困難となる。

以上のように、一つのネットワーク全体で一つのブロックチェーンを生成する形態では、ノード識別情報及び車両識別情報は、ブロックに記録されなくてもよい。こうした形態では、ブロックハイト又はタイムスタンプが、ブロック保存部のデータ復元時において、提供ノードから収集すべきブロックを特定する情報として機能する。

上記実施形態では、ブロックチェーンの復元が完了した後に、バックアップブロックの復元が開始されていた。しかし、ブロックチェーンの復元と併行して、バックアップブロックの復元が実施されてもよい。例えば、収集された中で最新となるマスタブロックから読み出したブロック特定情報を用いれば、ブロックチェーンの復元完了前に、回収すべきバックアップブロックの少なくとも一部が把握可能となる。

上記実施形態では、車載ユニットに設けられたメモリ装置のブロック保存部に、マスタブロック及びバックアップブロックの両方が保存されていた。しかし、バックアップブロックを保存する記憶領域は、マスタブロックを保存する記憶領域と物理的に分けられていてもよい。さらに、サーバのメモリ装置にも、ブロック保存部が設けられていてもよい。加えて、バックアップブロックを保存しないノード、又はバックアップブロックの保存を主目的とするノードがネットワーク内に存在していてもよい。さらに、ネットワーク内にサーバを設けない完全なＰ２Ｐネットワークが、実質的に車載ユニットのみで形成されていてもよい。

上記実施形態では、依頼ノード及び承認ノード間にて、管理プログラム及びヘッダハッシュ値の同一性を順に確認し合う処理により、新規に生成されたブロックが承認されていた。しかし、新規に生成されたブロックを承認する具体的な処理の方法は、適宜変更されてよい。例えば、新規に生成されたブロックを承認する権限が、各車載ユニットではなく、管理者の管理下にある特定のサーバに与えられていてもよい。

本開示の履歴管理方法によって履歴情報が保管される車両は、ユーザによって個人所有された自家用車であってもよく、バス及び貨物車両のような業務用車両であってもよい。又は、モビリティサービスを提供する無人運転車両の履歴情報の保管に、本開示による履歴管理方法が用いられてもよい。モビリティサービス用の車両の履歴情報を管理する履歴管理システムが構築される場合、サーバは、例えば各車両の運行管理を行う管理センタ等に設置されてもよい。

上記実施形態では、ＬＴＥ及び５Ｇ通信や車車間通信等により、複数の車載ユニットが互いに通信可能な状態とされていた。しかし、各ノード同士の通信方法は、適宜変更されてよい。例えば、車車間通信を使用せず、Ｖ２Ｎ通信のみで、承認依頼及びバックアップ等の全データが送受信されてもよい。或いは車車間通信のみで、承認依頼及びバックアップ等の全データの送受信が完結してもよい。

さらに、通信器による通信が不可能な状況では、承認依頼及びバックアップ等の送信は、一時的に中断される。承認依頼及びバックアップ等の送信は、通信可能な状態に復帰した後、実施されてよい。加えて、ブロック生成部は、通信状況が不安定な環境下において、ブロックの新規の生成を開始しないように設定されていてもよい。

本開示の履歴管理方法を実施するコンピュータとして、上記実施形態では、サーバ及び車載ユニットが例示されていた。しかし、履歴管理方法を実施するコンピュータは、これらに限定されず、適宜変更されてよい。また、車載ユニットと、ネットワーククラウド上のサーバとが、ブロックチェーンの生成に関連する演算を分散処理してもよい。

加えて、ブロックチェーンを生成する機能は、専用の車載ユニットではなく、例えば自動運転用の車載ユニット又はＨＭＩ制御用の車載ユニット等に組み込まれていてもよい。さらに、複数の車載ユニットによって、ブロックチェーンの生成に関連する演算が分散処理されてもよい。また、ブロックチェーン及びバックアップブロックを復元する処理は、上記のようなサーバ側ではなく、車載ユニット等のエッジ側で実行されてもよい。

以上のように、上記実施形態にて車載ユニット及びサーバの各制御回路によって提供されていた各機能は、ソフトウェア及びそれを実行するハードウェア、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの複合的な組合せによっても提供可能である。さらに、こうした機能がハードウェアである電子回路によって提供される場合、各機能は、多数の論理回路を含むデジタル回路、又はアナログ回路によっても提供可能である。

加えて、管理プログラム及び保全プログラム等に関連したデータ処理、並びに命令及びコードを実行するプロセッサの具体的な構成は、適宜変更可能である。プロセッサは、ＣＰＵ（Central Processing Unit）に加えて、ＧＰＵ（Graphics Processing Unit）を含む構成であってもよい。またプロセッサは、ＦＰＧＡ（Field-Programmable Gate Array）及びＡＩの学習及び推論に特化したアクセラレータ（例えばＤＳＰ（Digital Signal Processor）等）を含んでいてもよい。さらにプロセッサは、ＡＳＩＣ（Application Specific Integrated Circuit）及びＦＰＧＡ等に実装された構成であってもよい。

各プログラム等を格納する構成として、フラッシュメモリ及びハードディスク等の種々の非遷移的実体的記憶媒体（non-transitory tangible storage medium）が、各メモリ装置に採用可能である。こうした記憶媒体の形態も、適宜変更されてよい。例えば記憶媒体は、メモリカード等の形態であって、スロット部に挿入されて、制御回路に電気的に接続される構成であってよい。さらに記憶媒体は、上述のような車載装置又はサーバ等のメモリ装置に限定されず、当該メモリ装置へのプログラムのコピー基となる光学ディスク及び汎用コンピュータのハードディスクドライブ等であってもよい。

１０ 履歴管理システム、２０ サーバ（コンピュータ）、２１ プロセッサ、３２ 復元要求部（要求配信部）、６１ プロセッサ、６９ ブロック保存部、７１ ブロック生成部、７５ 保存先設定部、７７ ブロック送信部、１００ 車載ユニット（履歴管理装置，コンピュータ）、ＢＣ ブロックチェーン、ＢＬ ブロック、ＢＬｍ マスタブロック（自車ブロック）、ＢＬｃ バックアップブロック（他車ブロック）、ＩＤｎ ノード識別情報（車両識別情報）、ＩｎＢ ブロック特定情報、ＮＤ ノード、ＮＤ１ 依頼ノード（第一ノード）、ＮＤ２ 承認ノード（第二ノード）、Ｋ バックアップノード数、Ｎ 承認ノード数、ＮＷ ネットワーク、ＮＷＣ ネットワーククラウド、Ｐｃ 管理プログラム（算出プログラム）、Ｒｃ 通信範囲（特定範囲）、Ｖ 車両、Ｖａ 他車両、Ｖｉ 自車両、Ｖｒ 特定車両

Claims (13)

1. コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて車両（Ｖ）の履歴情報を管理する履歴管理方法であって、
   少なくとも一つのプロセッサ（２１，６１）上において、
   前記車両にて収集された前記履歴情報から、前記ブロックチェーンに連結されるブロック（ＢＬ）を生成し（Ｓ１０）、
   生成した前記ブロックのバックアップの保存先を、前記車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、
   設定した保存先となる前記ノードへ向けて、前記ブロックのバックアップを送信する（Ｓ７０）、
   というステップを含む履歴管理方法。
2. 新たに生成した前記ブロックの承認を、前記車両と通信可能な複数の前記ノードに依頼する（Ｓ２０）、というステップをさらに含み、
   前記バックアップの保存先となる前記ノードの数（Ｋ）は、前記ブロックの承認の依頼先となる前記ノードの数（Ｎ）よりも少ない請求項１に記載の履歴管理方法。
3. 前記ブロックの承認の依頼先となる前記ノードの数が奇数である請求項２に記載の履歴管理方法。
4. 前記バックアップの保存先の少なくとも一つは、前記ブロックの承認を依頼された複数の前記ノードの中から選択される請求項２又は３に記載の履歴管理方法。
5. 前記車両と通信可能な複数の前記ノードのうちで、前記ブロックの保管のために確保された記憶容量の残量の少ない前記ノードよりも、当該残量の多い前記ノードが、前記バックアップの保存先として優先的に選択される請求項１〜４のいずれか一項に記載の履歴管理方法。
6. 前記ブロックの生成が、複数の開始条件の成立に基づき開始され、
   通信可能な複数の前記ノードの中から保存先となる前記ノードを選択するルールが、前記開始条件に応じて変更される請求項１〜５のいずれか一項に記載の履歴管理方法。
7. 個々の前記ブロックには、各前記ブロックを生成した前記ノードを示すノード識別情報（ＩＤｎ）が含まれている請求項１〜６のいずれか一項に記載の履歴管理方法。
8. 前記ブロックとしての自車ブロック（ＢＬｍ）が、他車両（Ｖａ）から取得した他車ブロック（ＢＬｃ）と共にブロック保存部（６９）に保存される請求項１〜７のいずれか一項に記載の履歴管理方法。
9. 前記ブロック保存部に前記他車ブロックを保存可能な前記他車両の数には、上限が設定されている請求項８に記載の履歴管理方法。
10. 前記ブロック保存部に保存可能な一つの前記他車両あたりの前記他車ブロックの数には、上限が設定されている請求項８又は９に記載の履歴管理方法。
11. 車車間通信にて前記車両と通信可能な特定範囲（Ｒｃ）に保存先となる前記ノードがいる場合、前記特定範囲内の前記ノードを保存先として、前記車車間通信により前記ブロックのバックアップを送信する請求項１〜１０のいずれか一項に記載の履歴管理方法。
12. 前記特定範囲に保存先となる前記ノードがいない場合、ネットワーククラウド（ＮＷＣ）を通じて通信可能な前記特定範囲外の前記ノードを保存先として、前記ブロックのバックアップを、前記ネットワーククラウドを通じて送信する請求項１１に記載の履歴管理方法。
13. ブロックチェーン（ＢＣ）を用いて車両（Ｖ）の履歴情報を管理する履歴管理装置であって、
    前記車両にて収集された前記履歴情報から、前記ブロックチェーンに連結されるブロック（ＢＬ）を生成するブロック生成部（７１）と、
    前記ブロック生成部にて生成された前記ブロックのバックアップの保存先を、前記車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定する保存先設定部（７５）と、
    前記保存先設定部にて設定された保存先の前記ノードへ向けて、前記ブロックのバックアップを送信するブロック送信部（７７）と、
    を備える履歴管理装置。

Images