(57)【要約】【課題】バックアップを限定的に実施しても、ブロックチェーンの復元が可能な履歴管理の方法及び装置等の提供。【解決手段】車載ユニットは、ブロックチェーンＢＣを用いて車両Ｖの履歴情報を管理する履歴管理装置として機能する。車載ユニットは、車両Ｖの履歴情報から、ブロックチェーンＢＣに連結されるマスタブロックＢＬｍを生成し、そのバックアップブロックＢＬｃの保存先となるノードＮＤを、ブロック単位で設定する。その結果、各車載ユニットのブロック保存部６９には、マスタブロックＢＬｍ及びバックアップブロックＢＬｃが共に保存される。このバックアップブロックＢＬｃは、ネットワークを通じて配信される復元要求に基づき送信される。マスタブロックＢＬｍには、ブロック保存部６９に保存されているバックアップブロックＢＬｃを特定可能にするブロック特定情報ＩｎＢが記録される。【選択図】図１２
2020013349.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理方法であって、
少なくとも一つのプロセッサ（２１，６１）上において、
前記車両にて収集された前記履歴情報から、前記車両の前記ブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し（Ｓ１０）、
前記マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、前記車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、
前記履歴情報の収集元である前記車両が前記マスタブロックとは異なる前記バックアップブロックを、前記マスタブロックと共にブロック保存部（６９）に保存し（Ｓ９３）、
ネットワーク（ＮＷ）を通じて配信される復元要求に基づき、前記ブロック保存部に保存された前記バックアップブロックの中から、前記復元要求にて要求される特定車両（Ｖｒ）についての前記バックアップブロックを送信する（Ｓ１６８）、というステップを含み、
前記マスタブロックが生成されるとき、前記ブロック保存部に保存されている前記バックアップブロックを特定可能にするブロック特定情報（ＩｎＢ）が、前記マスタブロックに記録される履歴管理方法。
【請求項２】
前記復元要求に基づき送信された前記バックアップブロックから前記特定車両の前記ブロックチェーンを復元し（Ｓ１７０）、
復元された前記ブロックチェーンのうちで最新となるブロックに記録された前記ブロック特定情報に基づき、前記特定車両の前記ブロック保存部に保存されていた前記バックアップブロックの提供を、前記ネットワークを通じて要求する（Ｓ１８２）、
というステップをさらに含む請求項１に記載の履歴管理方法。
【請求項３】
前記バックアップブロックの提供要求に基づき送信された前記ブロックから、前記ブロック保存部に保存されていた他車両の前記バックアップブロックを復元する（Ｓ１９０）、というステップをさらに含む請求項２に記載の履歴管理方法。
【請求項４】
コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理方法であって、
少なくとも一つのプロセッサ（２１，６１）上において、
前記車両にて収集された前記履歴情報から、前記車両の前記ブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し（Ｓ１０）、
前記履歴情報が収集された前記車両を示す車両識別情報（ＩＤｎ）を前記マスタブロックに記録し（Ｓ１０５）、
前記マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、前記車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、
前記履歴情報の収集元である前記車両が前記マスタブロックとは異なる前記バックアップブロックを、前記マスタブロックと共にブロック保存部（６９）に保存し（Ｓ９３）、
前記ブロックチェーンを復元させる特定車両（Ｖｒ）の前記車両識別情報を、復元要求と共に前記ブロック保存部を有する複数の前記ノードへ向けて配信し（Ｓ１６１）、
前記ブロック保存部に保存された前記バックアップブロックの中から、前記特定車両の前記車両識別情報が記録された前記バックアップブロックを、前記復元要求の要求元へ向けて送信する（Ｓ１６８）、
というステップを含む履歴管理方法。
【請求項５】
前記マスタブロックを生成した第一ノード（ＮＤ１）とは異なる少なくとも一つの第二ノード（ＮＤ２）にて、新たに生成された前記マスタブロックに含まれるハッシュ値を計算し（Ｓ１２０）、
前記第二ノードにて算出された前記ハッシュ値が、前記第一ノードにて生成された前記ハッシュ値と異なる場合、前記第一ノードの前記ブロック保存部に保存されたデータに異常があると判定する（Ｓ１２５）、
というステップをさらに含む請求項１〜４のいずれか一項に記載の履歴管理方法。
【請求項６】
前記第二ノードにて前記ハッシュ値が算出される前に、前記第一ノード及び前記第二ノードにそれぞれ記憶された前記ハッシュ値の算出プログラム（Ｐｃ）が実質的に同一であるか否かを判定する（Ｓ１１５）、というステップをさらに含む請求項５に記載の履歴管理方法。
【請求項７】
前記バックアップブロックの保存先となる前記ノードの数（Ｋ）は、前記第二ノードの数（Ｎ）よりも少ない請求項５又は６に記載の履歴管理方法。
【請求項８】
前記ハッシュ値を計算する前記第二ノードの数が奇数である請求項５〜７のいずれか一項に記載の履歴管理方法。
【請求項９】
前記バックアップブロックの保存先の少なくとも一つは、前記ハッシュ値を計算した前記第二ノードから選択される請求項５〜８のいずれか一項に記載の履歴管理方法。
【請求項１０】
複数の車両（Ｖ）が通信可能に接続されるネットワーク（ＮＷ）において一つのノード（ＮＤ）として機能し、複数の前記車両のうちの一つである自車両（Ｖｉ）の履歴情報を、ブロックチェーン（ＢＣ）を用いて管理する履歴管理装置であって、
前記自車両にて収集された前記履歴情報から、前記自車両の前記ブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成するブロック生成部（７１）と、
前記マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、前記自車両と通信可能な他のノードの中から、ブロック単位で設定する保存先設定部（７５）と、
前記履歴情報の収集元である前記車両が前記マスタブロックとは異なる前記バックアップブロックを、前記マスタブロックと共に保存するブロック保存部（６９）と、
ネットワークを通じて配信される復元要求に基づき、前記ブロック保存部に保存された前記バックアップブロックの中から、前記復元要求にて要求される特定車両（Ｖｒ）についての前記バックアップブロックを送信するブロック送信部（７７）と、を備え、
前記ブロック生成部は、前記マスタブロックを生成するとき、前記ブロック保存部に保存されている前記バックアップブロックを特定可能にするブロック特定情報（ＩｎＢ）を、前記マスタブロックに記録する履歴管理装置。
【請求項１１】
ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理システムであって、
前記車両にて収集された前記履歴情報から、前記車両の前記ブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し、前記履歴情報が収集された前記車両を示す車両識別情報（ＩＤｎ）を前記マスタブロックに記録するブロック生成部（７１）と、
前記マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、前記車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定する保存先設定部（７５）と、
前記履歴情報の収集元である前記車両が前記マスタブロックとは異なる前記バックアップブロックを、前記マスタブロックと共に保存するブロック保存部（６９）と、
前記ブロックチェーンを復元させる特定車両（Ｖｒ）の前記車両識別情報を、復元要求と共に前記ブロック保存部を有する複数の前記ノードへ向けて配信する要求配信部（３２）と、
前記復元要求に基づき、前記ブロック保存部に保存された前記バックアップブロックの中から、前記特定車両の前記車両識別情報が記録された前記バックアップブロックを前記要求配信部へ向けて送信するブロック送信部（７７）と、
を備える履歴管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この明細書による開示は、車両の履歴情報を管理する履歴管理の技術に関する。
【背景技術】
【０００２】
従来、例えば特許文献１には、ネットワークに接続された多数のノード間での取引履歴を、ブロックチェーンを用いて記録する取引記録システムが記載されている。特許文献１の取引記録システムでは、各ノードの保有データ量を少なくするため、特定ネットワーク内での取引履歴は、特定ネットワークに配置されたノードのみにより共有される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１８−６７１０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本開示の発明者は、特許文献１のようなブロックチェーンの技術を、車両の履歴情報の保管に用いることを検討した。しかし、特許文献１のシステムでは、特定ネットワーク内での取引履歴を含んだ全てのブロックは、当該特定ネットワーク内の全ノードに複製される。こうした全ノードによる全ブロックの共有に起因して、通信量の増加又は各ノードの保存データ量の増加等が不可避となる。
【０００５】
こうした課題を解決するため、車両の履歴情報を含んだブロックのバックアップを、限定的に実施することがさらに検討された。しかし、ブロックのバックアップを限定的に実施した場合、ブロックチェーンの復元に必要なブロックの回収について、不可能となる虞があった。
【０００６】
本開示は、ブロックのバックアップを限定的に実施する形態であっても、ブロックチェーンの復元が可能な履歴管理方法、履歴管理装置及び履歴管理システムの提供を目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、開示された一つの態様は、コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理方法であって、少なくとも一つのプロセッサ（２１，６１）上において、車両にて収集された履歴情報から、車両のブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し（Ｓ１０）、マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、履歴情報の収集元である車両がマスタブロックとは異なるバックアップブロックを、マスタブロックと共にブロック保存部（６９）に保存し（Ｓ９３）、ネットワーク（ＮＷ）を通じて配信される復元要求に基づき、ブロック保存部に保存されたバックアップブロックの中から、復元要求にて要求される特定車両（Ｖｒ）についてのバックアップブロックを送信する（Ｓ１６８）、というステップを含み、マスタブロックが生成されるとき、ブロック保存部に保存されているバックアップブロックを特定可能にするブロック特定情報（ＩｎＢ）が、マスタブロックに記録される履歴管理方法とされる。
【０００８】
また開示された一つの態様は、複数の車両（Ｖ）が通信可能に接続されるネットワーク（ＮＷ）において一つのノード（ＮＤ）として機能し、複数の車両のうちの一つである自車両（Ｖｉ）の履歴情報を、ブロックチェーン（ＢＣ）を用いて管理する履歴管理装置であって、自車両にて収集された履歴情報から、自車両のブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成するブロック生成部（７１）と、マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、自車両と通信可能な他のノードの中から、ブロック単位で設定する保存先設定部（７５）と、履歴情報の収集元である車両がマスタブロックとは異なるバックアップブロックを、マスタブロックと共に保存するブロック保存部（６９）と、ネットワークを通じて配信される復元要求に基づき、ブロック保存部に保存されたバックアップブロックの中から、復元要求にて要求される特定車両（Ｖｒ）についてのバックアップブロックを送信するブロック送信部（７７）と、を備え、ブロック生成部は、マスタブロックを生成するとき、ブロック保存部に保存されているバックアップブロックを特定可能にするブロック特定情報（ＩｎＢ）を、マスタブロックに記録する履歴管理装置とされる。
【０００９】
これらの態様では、マスタブロックが生成されるとき、ブロック保存部に保存されているバックアップブロックを特定可能にするブロック特定情報が、マスタブロックに記録される。故に、ブロック保存部のデータに異常が生じた特定車両について、そのブロックチェーンを他ノードから送信されたブロックで復元できれば、ブロック保存部にバックアップされていた他車両のバックアップブロックが特定できる。
【００１０】
以上によれば、特定車両のブロック保存部は、自車両のマスタブロックだけでなく、他車両のバックアップブロックも復元された状態まで戻り得る。故に、バックアップブロックが完全に失われて、ブロックチェーンの復元に必要なブロックの回収が不可能となる事態は、回避され得る。したがって、履歴情報を含んだブロックを限定的にバックアップする形態であっても、ブロックチェーンの復元が可能となる。
【００１１】
さらに、開示された一つの態様は、コンピュータ（２０，１００）によって実施され、ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理方法であって、少なくとも一つのプロセッサ（２１，６１）上において、車両にて収集された履歴情報から、車両のブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し（Ｓ１０）、履歴情報が収集された車両を示す車両識別情報（ＩＤｎ）をマスタブロックに記録し（Ｓ１０５）、マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定し（Ｓ３０）、履歴情報の収集元である車両がマスタブロックとは異なるバックアップブロックを、マスタブロックと共にブロック保存部（６９）に保存し（Ｓ９３）、ブロックチェーンを復元させる特定車両（Ｖｒ）の車両識別情報を、復元要求と共にブロック保存部を有する複数のノードへ向けて配信し（Ｓ１６１）、ブロック保存部に保存されたバックアップブロックの中から、特定車両の車両識別情報が記録されたバックアップブロックを、復元要求の要求元へ向けて送信する（Ｓ１６８）、というステップを含む履歴管理方法とされる。
【００１２】
また開示された一つの態様は、ブロックチェーン（ＢＣ）を用いて複数の車両（Ｖ）の履歴情報を管理する履歴管理システムであって、車両にて収集された履歴情報から、車両のブロックチェーンに連結されるマスタブロック（ＢＬｍ）を生成し、履歴情報が収集された車両を示す車両識別情報（ＩＤｎ）をマスタブロックに記録するブロック生成部（７１）と、マスタブロックを複製したバックアップブロック（ＢＬｃ）の保存先を、車両と通信可能なノード（ＮＤ）の中から、ブロック単位で設定する保存先設定部（７５）と、
履歴情報の収集元である車両がマスタブロックとは異なるバックアップブロックを、マスタブロックと共に保存するブロック保存部（６９）と、ブロックチェーンを復元させる特定車両（Ｖｒ）の車両識別情報を、復元要求と共にブロック保存部を有する複数のノードへ向けて配信する要求配信部（３２）と、復元要求に基づき、ブロック保存部に保存されたバックアップブロックの中から、特定車両の車両識別情報が記録されたバックアップブロックを要求配信部へ向けて送信するブロック送信部（７７）と、を備える履歴管理システムとされる。
【００１３】
これらの態様では、履歴情報を収集した車両を示す車両識別情報がマスタブロックに記録されている。故に、バックアップブロックを保存している各ノードは、特定車両の車両識別情報を復元要求と共に取得することで、特定車両についてのバックアップブロックが自らのブロック保存部にあるか否かを正しく判断し得る。
【００１４】
以上によれば、バックアップブロックの保存先がブロック単位で設定されても、特定車両のブロックチェーンの復元に必要なバックアップブロックは、保存先とされた他のノードから適切に回収可能となる。したがって、履歴情報を含んだブロックを限定的にバックアップする形態であっても、ブロックチェーンの復元が可能となる。
【００１５】
尚、上記括弧内の参照番号は、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、技術的範囲を何ら制限するものではない。
【図面の簡単な説明】
【００１６】
【図１】本開示の一実施形態による車載ユニットを含む履歴保管のためのネットワークであって、履歴管理システムの全体像を示す図である。
【図２】複数の車載ユニットによって形成されるＰ２Ｐネットワークを模式的に示す図である。
【図３】車載ユニットの機能の詳細を示すブロック図である。
【図４】サーバの機能の詳細を示すブロック図である。
【図５】ブロックチェーンを形成する個々のブロックの内容を詳細に示す図である。
【図６】チェーン追加処理のメイン処理の詳細を示すフローチャートである。
【図７】ブロック生成処理の詳細を示すフローチャートである。
【図８】ブロック承認処理の詳細を示すフローチャートである。
【図９】保存先設定処理の詳細を示すフローチャートである。
【図１０】チェーン復元処理の詳細を示すフローチャートである。
【図１１】バックアップ復元処理の詳細を示すフローチャートである。
【図１２】ブロックチェーン及びバックアップブロックを復元する過程を説明するための図である。
【発明を実施するための形態】
【００１７】
図１に示す本開示の一実施形態による履歴管理システム１０は、複数の車載ユニット１００、及び少なくとも一つ以上のサーバ２０等によって構成されている。履歴管理システム１０は、ブロックチェーンＢＣ（図５参照）を用いて、車載ユニット１００を搭載した複数の車両Ｖの履歴情報を管理する。各車載ユニット１００及び各サーバ２０は、相互に通信可能に接続されており、ネットワークＮＷにおける一つのノードＮＤとしてそれぞれ機能する。
【００１８】
車載ユニット１００は、通信器４０と共に車両Ｖに搭載されている。車載ユニット１００は、通信器４０を介して、他のノードＮＤと通信可能である。通信器４０は、Ｖ２Ｘ通信のための複数種類のアンテナを備えた通信モジュールを主体に構成されている。通信器４０にて実施されるＶ２Ｘ通信には、Ｖ２Ｎ通信、Ｖ２Ｉ（路車間）通信、及びＶ２Ｖ（車車間）通信等が含まれている。Ｖ２Ｎ通信又はＶ２Ｉ通信にて交信するネットワークＮＷの範囲は、車載ユニット１００から見たネットワーククラウドＮＷＣとなる。
【００１９】
通信器４０は、ＬＴＥ（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）が、各メモリ装置に採用可能である。こうした記憶媒体の形態も、適宜変更されてよい。例えば記憶媒体は、メモリカード等の形態であって、スロット部に挿入されて、制御回路に電気的に接続される構成であってよい。さらに記憶媒体は、上述のような車載装置又はサーバ等のメモリ装置に限定されず、当該メモリ装置へのプログラムのコピー基となる光学ディスク及び汎用コンピュータのハードディスクドライブ等であってもよい。
【符号の説明】
【０１３０】
１０  履歴管理システム、２０  サーバ（コンピュータ）、２１  プロセッサ、３２  復元要求部（要求配信部）、６１  プロセッサ、６９  ブロック保存部、７１  ブロック生成部、７５  保存先設定部、７７  ブロック送信部、１００  車載ユニット（履歴管理装置，コンピュータ）、ＢＣ  ブロックチェーン、ＢＬ  ブロック、ＢＬｍ  マスタブロック（自車ブロック）、ＢＬｃ  バックアップブロック（他車ブロック）、ＩＤｎ  ノード識別情報（車両識別情報）、ＩｎＢ  ブロック特定情報、ＮＤ  ノード、ＮＤ１  依頼ノード（第一ノード）、ＮＤ２  承認ノード（第二ノード）、Ｋ  バックアップノード数、Ｎ  承認ノード数、ＮＷ  ネットワーク、ＮＷＣ  ネットワーククラウド、Ｐｃ  管理プログラム（算出プログラム）、Ｒｃ  通信範囲（特定範囲）、Ｖ  車両、Ｖａ  他車両、Ｖｉ  自車両、Ｖｒ  特定車両
【図１】
2020013349.tif 000003
【図２】
2020013349.tif 000004
【図３】
2020013349.tif 000005
【図４】
2020013349.tif 000006
【図５】
2020013349.tif 000007
【図６】
2020013349.tif 000008
【図７】
2020013349.tif 000009
【図８】
2020013349.tif 000010
【図９】
2020013349.tif 000011
【図１０】
2020013349.tif 000012
【図１１】
2020013349.tif 000013
【図１２】
2020013349.tif 000014