(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023114480
(43)【公開日】2023-08-18
(54)【発明の名称】データ管理システム
(51)【国際特許分類】
G06F 16/27 20190101AFI20230810BHJP
G06F 16/24 20190101ALI20230810BHJP
【ＦＩ】
G06F16/27
G06F16/24
【審査請求】未請求
【請求項の数】19
【出願形態】ＯＬ
(21)【出願番号】P 2022016784
(22)【出願日】2022-02-06
(71)【出願人】
【識別番号】506149519
【氏名又は名称】株式会社Ｓｋｅｅｄ
(74)【代理人】
【識別番号】100136146
【弁理士】
【氏名又は名称】小谷 明生
(72)【発明者】
【氏名】柴田 巧一
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175AA01
5B175CA09
5B175DA10
(57)【要約】
【課題】台帳が肥大化しない分散型台帳方式のデータ管理システムを提供する。
【解決手段】データ管理システム１は複数のノードＮを備える。いずれかのノードＮがデータ管理システム１の外部から台帳Ｌの更新を指示する更新要求Ｒを取得すると、そのノードＮは他のノードＮに更新要求Ｒを送信する。各ノードＮは、更新要求Ｒに従う台帳Ｌの更新が不可能である場合はその旨を通知する更新不可能通知Ｘを他のノードに送信し、更新可能の場合は更新要求Ｒに従い台帳Ｌを更新するための情報の候補である候補更新情報Ｖを他のノードＮに送信する。各ノードＮは、他のノードＮから受信した更新不可能通知Ｘの数が所定条件を満たす場合、台帳Ｌを更新しない。また、各ノードＮは、台帳Ｌを更新する場合、他のノードＮから受信した候補更新情報Ｖのうち同一内容の候補更新情報Ｖが最多である候補更新情報Ｖを用いて台帳Ｌを更新する。
【選択図】図３
【解決手段】データ管理システム１は複数のノードＮを備える。いずれかのノードＮがデータ管理システム１の外部から台帳Ｌの更新を指示する更新要求Ｒを取得すると、そのノードＮは他のノードＮに更新要求Ｒを送信する。各ノードＮは、更新要求Ｒに従う台帳Ｌの更新が不可能である場合はその旨を通知する更新不可能通知Ｘを他のノードに送信し、更新可能の場合は更新要求Ｒに従い台帳Ｌを更新するための情報の候補である候補更新情報Ｖを他のノードＮに送信する。各ノードＮは、他のノードＮから受信した更新不可能通知Ｘの数が所定条件を満たす場合、台帳Ｌを更新しない。また、各ノードＮは、台帳Ｌを更新する場合、他のノードＮから受信した候補更新情報Ｖのうち同一内容の候補更新情報Ｖが最多である候補更新情報Ｖを用いて台帳Ｌを更新する。
【選択図】図３
【特許請求の範囲】
【請求項1】
通信ネットワークに属する複数のノードが時系列順のデータの集まりである台帳を記憶するデータ管理システムを構成するノードであって、
前記データ管理システムを構成する複数のノードのうち自ノード以外のノードを他ノードとし、台帳の更新を指示する要求を更新要求とするとき、
前記データ管理システムの外部から台帳の更新要求を取得した場合、又は、いずれかの他ノードから台帳の更新要求を受信した場合、当該更新要求が自ノードの記憶している台帳に関する更新要求であれば当該更新要求に従い台帳を更新するための情報の候補である候補更新情報を生成し、当該候補更新情報を１以上の他ノードに送信し、他ノードから受信した当該更新要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している台帳を更新する
ノード。
前記データ管理システムを構成する複数のノードのうち自ノード以外のノードを他ノードとし、台帳の更新を指示する要求を更新要求とするとき、
前記データ管理システムの外部から台帳の更新要求を取得した場合、又は、いずれかの他ノードから台帳の更新要求を受信した場合、当該更新要求が自ノードの記憶している台帳に関する更新要求であれば当該更新要求に従い台帳を更新するための情報の候補である候補更新情報を生成し、当該候補更新情報を１以上の他ノードに送信し、他ノードから受信した当該更新要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している台帳を更新する
ノード。
【請求項2】
更新要求に従い生成し１以上の他のノードに送信した候補更新情報が他ノードから受信した当該更新要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報と同一内容でない場合、自ノードの記憶している台帳を更新する代わりに当該台帳を消去する
請求項１に記載のノード。
請求項１に記載のノード。
【請求項3】
更新要求に応じて自ノードの記憶している台帳を更新する代わりに当該台帳を消去した場合、１以上の他ノードに当該更新要求に従い更新された台帳の送信を要求し、当該要求に応じていずれかの他ノードから送信されてきた台帳を記憶する
請求項２に記載のノード。
請求項２に記載のノード。
【請求項4】
前記データ管理システムの外部から自ノードの記憶している台帳に関する更新要求を取得した場合、又は、いずれかの他ノードから自ノードの記憶している台帳に関する更新要求を受信した場合、当該更新要求に従う台帳の更新が可能である場合は当該更新要求に従い生成した候補更新情報を１以上の他ノードに送信し、当該更新要求に従う台帳の更新が不可能である場合は候補更新情報に代えて当該更新要求に従う台帳の更新が不可能であることを示す更新不可能通知を１以上の他ノードに送信し、他ノードから受信した当該更新要求に関する更新不可能通知の数が所定条件を満たせば、当該更新要求に従う台帳の更新を行わない
請求項１乃至３のいずれか１項に記載のノード。
請求項１乃至３のいずれか１項に記載のノード。
【請求項5】
前記データ管理システムの外部から自ノードの記憶している台帳を含む２以上の互いに関連する台帳に関する更新要求を取得した場合、又は、いずれかの他ノードから自ノードの記憶している台帳を含む２以上の互いに関連する台帳の更新要求を受信した場合、当該２以上の台帳の少なくとも１つに関し、他ノードから受信した当該更新要求に関する更新不可能通知の数が所定条件を満たせば、当該２以上の台帳の全てに関し当該更新要求に従う更新を行わない
請求項４に記載のノード。
請求項４に記載のノード。
【請求項6】
台帳から１以上の台帳を分離して２以上の台帳とする更新を指示する更新要求を分離要求とするとき、
前記データ管理システムの外部から自ノードの記憶している台帳に関する分離要求を取得した場合、又は、他ノードから自ノードの記憶している台帳に関する分離要求を受信した場合、自ノードのリソースに関する所定条件が満たされているか否かに基づき当該分離要求に従う台帳の分離が可能であるか否かを判定し、当該分離要求に従う台帳の分離が可能である場合は当該分離要求に従い台帳を分離するための情報の候補である候補更新情報を１以上の他ノードに送信し、当該分離要求に従う台帳の分離が不可能である場合は候補更新情報に代えて当該分離要求に従う台帳の分離が不可能であることを示す更新不可能通知を１以上の他ノードに送信する
請求項４に記載のノード。
前記データ管理システムの外部から自ノードの記憶している台帳に関する分離要求を取得した場合、又は、他ノードから自ノードの記憶している台帳に関する分離要求を受信した場合、自ノードのリソースに関する所定条件が満たされているか否かに基づき当該分離要求に従う台帳の分離が可能であるか否かを判定し、当該分離要求に従う台帳の分離が可能である場合は当該分離要求に従い台帳を分離するための情報の候補である候補更新情報を１以上の他ノードに送信し、当該分離要求に従う台帳の分離が不可能である場合は候補更新情報に代えて当該分離要求に従う台帳の分離が不可能であることを示す更新不可能通知を１以上の他ノードに送信する
請求項４に記載のノード。
【請求項7】
自ノードのリソースに関する所定条件が満たされた場合、自ノードの記憶している台帳と同じ台帳から１以上の台帳を分離して２以上の台帳とする更新を指示する更新要求である分離要求を１以上の他ノードに送信する
請求項４又は６に記載のノード。
請求項４又は６に記載のノード。
【請求項8】
分離要求は、台帳から当該台帳に含まれるデータの新しさに基づき１以上の台帳を分離することを指示する
請求項６又は７に記載のノード。
請求項６又は７に記載のノード。
【請求項9】
分離要求は、台帳から当該台帳に含まれるデータの属性に基づき１以上の台帳を分離することを指示する
請求項６又は７に記載のノード。
請求項６又は７に記載のノード。
【請求項10】
分離要求は、分離元の台帳を更新不可の台帳とすることを指示する
請求項６乃至９のいずれか１項に記載のノード。
請求項６乃至９のいずれか１項に記載のノード。
【請求項11】
第１の台帳に対し第２の台帳の情報を追加して当該第１の台帳を更新するとともに当該第２の台帳を更新不可とすることを指示する更新要求を統合要求とするとき、
前記データ管理システムの外部から統合要求を取得した場合、又は、いずれかの他ノードから統合要求を受信した場合、
自ノードが当該統合要求に関する第１の台帳及び第２の台帳の両方を記憶しているならば、当該統合要求に従い第１の台帳を更新するための情報の候補である候補更新情報を他ノードに送信し、他ノードから受信した当該統合要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している当該統合要求に関する第１の台帳を更新するとともに、自ノードの記憶している当該統合要求に関する第２の台帳を更新不可とし、
自ノードが当該統合要求に関する第１の台帳を記憶しており第２の台帳を記憶していないならば、他ノードから受信した当該統合要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している当該統合要求に関する第１の台帳を更新し、
自ノードが当該統合要求に関する第１の台帳を記憶しておらず第２の台帳を記憶しているならば、自ノードの記憶している第２の台帳を更新不可とする
請求項４に記載のノード。
前記データ管理システムの外部から統合要求を取得した場合、又は、いずれかの他ノードから統合要求を受信した場合、
自ノードが当該統合要求に関する第１の台帳及び第２の台帳の両方を記憶しているならば、当該統合要求に従い第１の台帳を更新するための情報の候補である候補更新情報を他ノードに送信し、他ノードから受信した当該統合要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している当該統合要求に関する第１の台帳を更新するとともに、自ノードの記憶している当該統合要求に関する第２の台帳を更新不可とし、
自ノードが当該統合要求に関する第１の台帳を記憶しており第２の台帳を記憶していないならば、他ノードから受信した当該統合要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて自ノードの記憶している当該統合要求に関する第１の台帳を更新し、
自ノードが当該統合要求に関する第１の台帳を記憶しておらず第２の台帳を記憶しているならば、自ノードの記憶している第２の台帳を更新不可とする
請求項４に記載のノード。
【請求項12】
前記データ管理システムの外部から自ノードの記憶している台帳に関する統合要求を取得した場合、又は、他ノードから自ノードの記憶している台帳に関する統合要求を受信した場合、自ノードのリソースに関する所定条件が満たされているか否かに基づき当該統合要求に従う台帳の統合が可能であるか否かを判定し、当該統合要求に従う台帳の統合が可能である場合は当該統合要求に従い台帳を統合するための情報の候補である候補更新情報を１以上の他ノードに送信し、当該統合要求に従う台帳の統合が不可能である場合は候補更新情報に代えて当該統合要求に従う台帳の統合が不可能であることを示す更新不可能通知を１以上の他ノードに送信する
請求項１１に記載のノード。
請求項１１に記載のノード。
【請求項13】
自ノードのリソースに関する所定条件が満たされた場合、自ノードの記憶している第１の台帳と同じ台帳に対し自ノードの記憶している第２の台帳と同じ台帳の情報を追加して、自ノードの記憶している第１の台帳と同じ台帳を更新するとともに、自ノードの記憶している第２の台帳と同じ台帳を更新不可とすることを指示する更新要求である統合要求を１以上の他ノードに送信する
請求項１１又は１２に記載のノード。
請求項１１又は１２に記載のノード。
【請求項14】
自ノードのリソースに関する所定条件が満たされた場合、自ノードの記憶している台帳を消去する
請求項１乃至１３のいずれか１項に記載のノード。
請求項１乃至１３のいずれか１項に記載のノード。
【請求項15】
自ノードの記憶している台帳に関する更新要求の受信頻度に関する所定条件が満たされた場合、当該台帳を消去する
請求項１乃至１４のいずれか１項に記載のノード。
請求項１乃至１４のいずれか１項に記載のノード。
【請求項16】
自ノードの記憶している台帳に関する更新要求に応じて他ノードから送信されてきた候補更新情報の数に関する所定条件が満たされた場合、当該台帳を消去する
請求項１乃至１５のいずれか１項に記載のノード。
請求項１乃至１５のいずれか１項に記載のノード。
【請求項17】
自ノードの記憶していない台帳に関する更新要求の受信頻度に関する所定条件が満たされた場合、１以上の他ノードに当該台帳の送信を要求し、当該要求に応じていずれかの他ノードから送信されてきた台帳を記憶する
請求項１乃至１６のいずれか１項に記載のノード。
請求項１乃至１６のいずれか１項に記載のノード。
【請求項18】
自ノードの記憶していない台帳に関する更新要求に応じて他ノードから送信されてきた候補更新情報の数に関する所定条件が満たされた場合、１以上の他ノードに当該台帳の送信を要求し、当該要求に応じていずれかの他ノードから送信されてきた台帳を記憶する
請求項１乃至１７のいずれか１項に記載のノード。
請求項１乃至１７のいずれか１項に記載のノード。
【請求項19】
通信ネットワークを介して他のコンピュータとデータ通信が可能なコンピュータに、請求項１乃至１８のいずれか１項に記載のノードが行う処理を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワーク内の多数のノードで共有されるデータを管理する技術に関する。
【背景技術】
【0002】
近年、ブロックチェーンが普及している。ブロックチェーンは、情報を記録するデータベース技術の一種であり、ブロックと呼ばれる単位でデータを管理し、新しいデータを含むブロックをチェーンのように順次連結して、経時変化してゆくデータの履歴を保管することができる。
【0003】
ブロックチェーンは分散型台帳技術の一種であり、多数のノードで共有されるため、いずれかのノードでデータが改ざんされても速やかにその改ざんが発見される。ブロックチェーンの改ざん困難性を活かして、ブロックチェーンは特にデータの正統性の保証が要求されるシステムにおいて活用されている。
【0004】
例えば、特許文献１には、ブロックチェーンを活用して、デジタルコンテンツのアクセス権を保証するシステムが提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開２０２２－２０５５７号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ブロックチェーンに代表される分散型台帳方式のデータ管理システムにおいては、台帳は過去の全てのデータを保持するため、時間の経過に伴いデータ量が増加の一途を辿る。台帳が肥大化すると、データ処理の負荷増大、通信量の増大による通信速度低下及び通信コストの増大、ストレージ容量の不足等のデメリットが大きくなる。
【0007】
上述した事情に鑑み、本発明は、台帳が肥大化しない分散型台帳方式のデータ管理システムを提供する。
【課題を解決するための手段】
【0008】
本発明は、通信ネットワークに属する複数のノードが時系列順のデータの集まりである台帳を記憶するデータ管理システムを構成するノードであって、前記データ管理システムを構成する複数のノードのうち自ノード以外のノードを他ノードとし、台帳の更新を指示する要求を更新要求とするとき、前記データ管理システムの外部から台帳の更新要求を取得した場合、又は、いずれかの他ノードから台帳の更新要求を受信した場合、当該更新要求が自ノードの記憶している台帳に関する更新要求であれば当該更新要求に従い台帳を更新するための情報の候補である候補更新情報を生成し、当該候補更新情報を１以上の他ノードに送信し、他ノードから受信した当該更新要求に関する候補更新情報のうち同一内容の候補更新情報の数が所定条件を満たす候補更新情報を用いて更新前の台帳を更新するノードを提案する。
【発明の効果】
【0009】
本発明によれば、分散型台帳方式のデータ管理システムにおいて台帳が肥大化しない。
【図面の簡単な説明】
【0010】
【図1】一実施形態に係るデータ管理システムにおける台帳更新の手順を示した図。
【図2】一実施形態に係るデータ管理システムにおける台帳更新の手順を示した図。
【図3】一実施形態に係るデータ管理システムにおける台帳更新の手順を示した図。
【図4】一実施形態に係るデータ管理システムにおいて各ノードが異なる台帳を記憶している様子を示した図。
【図5】一実施形態に係るデータ管理システムにおいて台帳から新たな台帳が分離される様子を示した図。
【図6】一実施形態に係るデータ管理システムにおいて台帳から新たな台帳が分離される様子を示した図。
【図7】一実施形態に係るデータ管理システムにおいて台帳から新たな台帳が分離される様子を示した図。
【図8】一実施形態に係るデータ管理システムにおいて台帳が統合される様子を示した図。
【図9】一実施形態に係るデータ管理システムにおいて２つの互いに関連する台帳に関する更新要求に従い、２つの台帳の更新が行われる手順を示した図。
【図10】一実施形態に係るデータ管理システムにおいて２つの互いに関連する台帳に関する更新要求に従い、２つの台帳の更新が行われる手順を示した図。
【図11】一実施形態に係るデータ管理システムにおいて２つの互いに関連する台帳に関する更新要求に従い、２つの台帳の更新が行われる手順を示した図。
【図12】従来技術に係るデータ管理システムと比較した場合の一実施形態に係るデータ管理システムのメリットを説明するための図。
【図13】従来技術に係るデータ管理システムにおける台帳更新の手順を示した図。
【図14】従来技術に係るデータ管理システムにおける台帳更新の手順を示した図。
【図15】従来技術に係るデータ管理システムにおける台帳更新の手順を示した図。
【発明を実施するための形態】
【0011】
［対比例］
以下に、本発明の一実施形態に係るノードにより構成されるデータ管理システムと対比される、一般的な分散型台帳方式のデータ管理システムにおける台帳更新の手順の例を説明する。本願において台帳とは、時系列順のデータの集まりを意味する。また、以下の説明において、台帳は単位量のデータであるブロックが時系列順に連結された形式のデータであるものとする。
以下に、本発明の一実施形態に係るノードにより構成されるデータ管理システムと対比される、一般的な分散型台帳方式のデータ管理システムにおける台帳更新の手順の例を説明する。本願において台帳とは、時系列順のデータの集まりを意味する。また、以下の説明において、台帳は単位量のデータであるブロックが時系列順に連結された形式のデータであるものとする。
【0012】
図１２～図１５は、一般的な分散型台帳方式のデータ管理システム９における台帳更新の手順を示した図である。データ管理システム９は、例えばブロックチェーンシステムである。データ管理システム９は、通信ネットワークに属する複数のノードＮで構成される。ノードＮの各々は、内容が同一の台帳Ｌ（１）を記憶している。
【0013】
いずれかのノードＮがデータ管理システム９の外部から台帳Ｌ（１）の更新要求Ｒを取得すると、更新要求Ｒを受け取ったノードＮは他のノードＮに更新要求Ｒを送信する（図１３）。なお、ノードＮ間のデータの送受信は、それらのノードＮ間で直接行われてもよいし、マルチホップ方式等の他のノードＮを介した方法により行われてもよい。
【0014】
更新要求Ｒを受け取ったノードＮのうち、所定の規則に従い定まる代表のノードＮ（Ｒ）１は、更新要求Ｒに従い台帳Ｌ（１）を更新するための情報である更新情報Ｕを生成し、他のノードＮに送信する（図１４）。更新情報Ｕは、例えば、更新要求Ｒに従い台帳Ｌ（１）に追加されるブロックＢと、台帳Ｌ（１）にブロックＢを追加した更新後の台帳Ｌ（２）のハッシュ値を含む。
【0015】
更新情報Ｕを受信したノードＮの各々は、更新情報Ｕが正しい更新情報であるか否かの検証を行い、更新情報Ｕが正しい更新情報であると検証した場合に限り、更新情報Ｕを用いて台帳Ｌ（１）を更新し台帳Ｌ（２）を生成する（図１５）。
【0016】
［実施形態］
続いて、本発明の一実施形態に係るノードにより構成されるデータ管理システム１を説明する。図１～図３は、データ管理システム１における台帳更新の手順を示した図である。データ管理システム１は、通信ネットワークに属する複数のノードＮで構成される。ノードＮの各々は、内容が同一の台帳Ｌ（１）を記憶している。
続いて、本発明の一実施形態に係るノードにより構成されるデータ管理システム１を説明する。図１～図３は、データ管理システム１における台帳更新の手順を示した図である。データ管理システム１は、通信ネットワークに属する複数のノードＮで構成される。ノードＮの各々は、内容が同一の台帳Ｌ（１）を記憶している。
【0017】
いずれかのノードＮがデータ管理システム１の外部から台帳Ｌ（１）の更新要求Ｒを取得すると、更新要求Ｒを受け取ったノードＮは他のノードＮに更新要求Ｒを送信する（図１）。なお、ノードＮ間のデータの送受信は、それらのノードＮ間で直接行われてもよいし、マルチホップ方式等の他のノードＮを介した方法により行われてもよい。
【0018】
更新要求Ｒを受け取ったノードＮの各々は、まず、更新要求Ｒに従う台帳Ｌ（１）の更新が可能であるか否かを判定する。例えば、台帳Ｌ（１）が銀行口座の入出金の履歴及び残高を示す場合、台帳Ｌ（１）が示す残高より多額の金額の出金を台帳Ｌ（１）に反映させるための更新要求Ｒは通常、許可されない。
【0019】
ノードＮは、更新要求Ｒに従う台帳Ｌ（１）の更新が不可能である判定した場合、更新要求Ｒに従う台帳Ｌの更新が不可能であることを示す更新不可能通知Ｘを他のノードＮに送信する（図２）。
【0020】
一方、ノードＮは、更新要求Ｒに従う台帳Ｌ（１）の更新が可能である判定した場合、更新要求Ｒに従い台帳Ｌ（１）を更新するための情報である候補更新情報Ｖを生成し、他のノードＮに送信する（図２）。候補更新情報Ｖは、例えば、更新要求Ｒに従い台帳Ｌ（１）に追加されるブロックＢと、台帳Ｌ（１）にブロックＢを追加した更新後の台帳Ｌ（２）のハッシュ値を含む。候補更新情報Ｖは、各ノードＮが提案する更新情報であり、まだ採用されるか否かが定まっていない状態の更新情報、すなわち、更新情報の候補である。
【0021】
各々のノードＮは、他のノードＮから受信した更新不可能通知Ｘの数が所定条件を満たす場合、更新要求Ｒに従う台帳Ｌ（１）の更新を行わない。また、各々のノードＮは、更新要求Ｒに従う台帳Ｌ（１）の更新を行う場合、他のノードＮから受信した候補更新情報Ｖのうち同一内容の候補更新情報Ｖの数が所定条件を満たす候補更新情報Ｖを用いて台帳Ｌ（１）を更新する（図３）。
【0022】
ノードＮが台帳Ｌの更新を行うか否かを決定する手順、及び、ノードＮが台帳Ｌの更新に用いる候補更新情報Ｖを決定する手順を以下に説明する。
【0023】
まず、ノードＮは、手元の更新不可能通知Ｘ又は候補更新情報Ｖの数が所定の閾値Ｓ以上となると、手元の候補更新情報Ｖを内容が同一のもの毎にグループ化する。
【0024】
ここで、手元の更新不可能通知Ｘとは自ノードが送信した更新不可能通知Ｘと他のノードＮから受信した更新不可能通知Ｘとの集まりを意味するものとする。ただし、これに代えて、手元の更新不可能通知Ｘが、自ノードが送信した更新不可能通知Ｘを含まず、他のノードＮから受信した更新不可能通知Ｘのみの集まりを意味してもよい。同様に、手元の候補更新情報Ｖとは、自ノードが生成した候補更新情報Ｖと他のノードＮから受信した候補更新情報Ｖとの集まりを意味するものとする。ただし、これに代えて、手元の候補更新情報Ｖが、自ノードが生成した候補更新情報Ｖを含まず、他のノードＮから受信した候補更新情報Ｖのみの集まりを意味してもよい。
【0025】
上記の閾値Ｓは固定値でもよいし、例えば、過去の台帳Ｌの更新において更新要求Ｒを受信した後の所定時間長の期間内に他のノードＮから受信した更新不可能通知Ｘ及び候補更新情報Ｖの数等に基づき変更される変動値であってもよい。従って、閾値ＳはノードＮ毎に異なってもよい。
【0026】
例えば、あるノードＮの現在の閾値Ｓが１００である場合、そのノードＮが他のノードＮから受信した更新不可能通知Ｘ又は候補更新情報Ｖの数が９９以上となると、手元の更新不可能通知Ｘ又は候補更新情報Ｖの数が１００以上となるため、そのノードＮは以下の処理を行う。
【0027】
まず、ノードＮは、手元の候補更新情報Ｖを、同一の内容のもの毎にグループ化する。
【0028】
続いて、ノードＮは、手元の更新不可能通知Ｘの数と、各グループに含まれる候補更新情報Ｖの数をカウントする。
【0029】
カウントした数の最大値が更新不可能通知Ｘの数であれば、ノードＮは更新要求Ｒに従う台帳Ｌ（１）の更新を行わない。
【0030】
一方、カウントした数の最大値がいずれかの候補更新情報Ｖのグループに含まれる候補更新情報Ｖの数であれば、ノードＮはそのグループの候補更新情報Ｖが、自ノードが生成した候補更新情報Ｖと同一内容であるか否かを判定する。それらの候補更新情報Ｖが同一内容である場合、ノードＮが記憶している台帳Ｌ（１）は最新であったことが確認されたことになる。その場合、ノードＮは、数が最多の候補更新情報Ｖ、すなわち、自ノードが生成した候補更新情報Ｖを用いて台帳Ｌ（１）を更新し台帳Ｌ（２）を生成する。
【0031】
数が最多の候補更新情報Ｖと自ノードが生成した候補更新情報Ｖが同一内容でない場合、ノードＮが記憶している台帳Ｌ（１）は最新ではなかったことが確認されたことになる。その場合、ノードＮは、自ノードが記憶している台帳Ｌ（１）を記憶領域から消去する。そのように台帳Ｌ（１）を消去した場合、ノードＮは、他のノードＮに対し、更新要求に従い台帳Ｌ（１）を更新して生成された台帳Ｌ（２）の送信を要求し、その要求に応じていずれかの他のノードＮから送信されてくる台帳Ｌ（２）を記憶してもよい。
【0032】
上記のように、データ管理システム１においては、多数のノードＮの各々が候補更新情報Ｖを生成し、各ノードＮは自ノード及び他ノードが生成した複数の候補更新情報Ｖのうち最多の候補更新情報Ｖを採用して台帳Ｌの更新を行う。このように、データ管理システム１においては、データ管理システム９における場合と比較し、台帳Ｌの更新がノードＮの各々によって、より自律的に行われる点に特徴がある。
【0033】
また、データ管理システム１においては、各ノードＮの手元の候補更新情報Ｖの中から多数決で台帳Ｌの更新に用いる候補更新情報Ｖを決定する。すなわち、全てのノードＮの合意がなくても、各ノードＮは独自の判断で更新要求Ｒに従う台帳Ｌの更新を実行できる。そのため、データ管理システム１においては、全てのノードＮが同一の台帳Ｌを記憶する必要はない。
【0034】
すなわち、データ管理システム１を構成するノードＮには、例えば、図４に示すように、台帳ＬＡと台帳ＬＢを記憶しているノードＮと、台帳ＬＡは記憶しているが台帳ＬＢは記憶していないノードＮと、台帳ＬＡは記憶していないが台帳ＬＢは記憶しているノードＮと、台帳ＬＡと台帳ＬＢのいずれも記憶していないノードＮが混在していてもよい。
【0035】
上記のように、データ管理システム１においては、全てのノードＮが必ずしも同じ台帳Ｌを記憶していなくてもよいため、１つの台帳Ｌから１以上の台帳を分離して新たな２以上の台帳を生成することが許容され、分離により生成される新たな２以上の台帳のうちの一部のみを記憶するノードＮの存在が許容される。
【0036】
図５は、台帳Ｌ（１）から、台帳Ｌ（１）に含まれるデータの新しさに基づき台帳Ｌ（２）が分離される様子を示した図である。図５（Ａ）は分離前の台帳Ｌを示し、図５（Ｂ）は分離後の台帳Ｌを示す。図５に示される台帳Ｌ（１）は、例えば１つの銀行口座の入出金履歴及び残高を示すデータのように、不連続なブロックを集めて連結した場合に、その連結により得られるデータは意味を成さない種類のデータである。
【0037】
図５の例では、ブロックＢ（１）～Ｂ（５）を含む台帳Ｌ（１）から、最新のブロックＢ（５）が分離され、分離されたブロックＢ（５）を含む台帳Ｌ（２）が新たに生成される。すなわち、この分離によって、１つの台帳Ｌ（１）が、２つの台帳、すなわち、台帳Ｌ（１）及び台帳Ｌ（２）となる。そして、この場合、将来の更新は台帳Ｌ（２）に対し行われるため、台帳Ｌ（１）は更新不可の台帳とされる。
【0038】
図６は、台帳Ｌ（１）から、台帳Ｌ（１）に含まれるデータの属性に基づき台帳Ｌ（２）が分離される様子を示した図である。図６（Ａ）は分離前の台帳Ｌを示し、図６（Ｂ）は分離後の台帳Ｌを示す。図６に示される台帳Ｌ（１）は、例えば、ユーザＰの銀行口座の入出金履歴及び残高を示すデータと、ユーザＱの銀行口座の入出金履歴及び残高を示すデータを含むデータのように、２以上の異なる属性のデータを含み、それらの属性毎に取り出して時系列順に連結した場合に、その連結により得られるデータが意味を成す種類のデータである。
【0039】
図６の例では、台帳Ｌ（１）はブロックＢＰ（１）、ＢＱ（１）、ＢＰ（２）、ＢＱ（２）、ＢＱ（３）を含む。ここで、ブロックＢＰ（１）、ＢＰ（２）は属性Ｐに関するブロックであり、ブロックＢＱ（１）、ＢＱ（２）、ＢＱ（３）は属性Ｑに関するブロックである。そして、台帳Ｌ（１）から、属性Ｐに関する最新のブロックＢＰ（２）が分離され、分離されたブロックＢＰ（２）を含む台帳Ｌ（２）が新たに生成される。すなわち、この分離によって、１つの台帳Ｌ（１）が、２つの台帳、すなわち、台帳Ｌ（１）及び台帳Ｌ（２）となる。そして、この場合、属性Ｐに関する将来の更新は台帳Ｌ（２）に対し行われ、属性Ｑに関する将来の更新は台帳Ｌ（１）に対し行われる。
【0040】
図７は、台帳Ｌ（１）から、台帳Ｌ（１）に含まれるデータの属性に基づき台帳Ｌ（２）と台帳Ｌ（３）が分離される様子を示した図である。図７（Ａ）は分離前の台帳Ｌを示し、図７（Ｂ）は分離後の台帳Ｌを示す。図７に示される台帳Ｌ（１）は、図６に示される台帳Ｌ（１）と同じものである。図７の例では、台帳Ｌ（１）から、属性Ｐに関する最新のブロックＢＰ（２）が分離され、分離されたブロックＢＰ（２）を含む台帳Ｌ（２）が新たに生成される。また、台帳Ｌ（１）から、属性Ｑに関する最新のブロックＢＱ（３）が分離され、分離されたブロックＢＱ（３）を含む台帳Ｌ（３）が新たに生成される。すなわち、この分離によって、１つの台帳Ｌ（１）が、３つの台帳、すなわち、台帳Ｌ（１）、台帳Ｌ（２）、及び、台帳Ｌ（３）となる。そして、この場合、属性Ｐに関する将来の更新は台帳Ｌ（２）に対し行われ、属性Ｑに関する将来の更新は台帳Ｌ（３）に対し行われるため、台帳Ｌ（１）は更新不可の台帳とされる。
【0041】
上記のような、１つの台帳からデータを分離し２以上の台帳とする更新要求Ｒを以下、分離要求Ｄという。分離要求Ｄは、例えば図５の例における台帳Ｌ（１）や図７の例における台帳Ｌ（１）のように、分離元の台帳を更新不可の台帳とすることを指示する場合がある。
【0042】
【0043】
なお、分離要求Ｄに従いノードＮが生成する候補更新情報Ｖ、すなわち、分離要求Ｄに従い台帳を分離するための情報の候補は、例えば、分離後の２以上の台帳の各々に関するハッシュ値と最新のブロックＢを含む。
【0044】
分離要求Ｄを受け取ったノードＮが、自ノードのリソースに関する所定条件が満たされているか否かに基づき、分離要求Ｄに従う台帳の分離が可能であるか否かを判定し、可能である場合は候補更新情報Ｖを他のノードＮに送信し、不可能である場合は候補更新情報Ｖに代えて、分離要求Ｄに従う台帳の分離が不可能であることを示す更新不可能通知Ｘを他のノードＮに送信するように構成されてもよい。
【0045】
ここで、ノードＮのリソースとは、ノードＮの記憶容量の空き容量、ノードＮが他のノードＮとの間で行うデータ通信の速度等を意味する。台帳の分離を行うと、分離後の台帳の数は増加する。従って、分離後の台帳を全て記憶し続ける場合、ノードＮの記憶容量の消費量が増加する。また、記憶している台帳の数が増加すると、一般的にノードＮが他のノードＮとの間で行う通信量は増加する。従って、ノードＮの記憶容量の空き容量が所定の閾値以下であったり、ノードＮが他のノードＮとの間で行うデータ通信の速度が所定の閾値以下であったりする場合は、ノードＮはその分離要求Ｄに関する更新不可能通知Ｘを送信することで、その分離要求Ｄに対する反対を他のノードＮに表明することができる。
【0046】
分離要求Ｄに関する更新不可能通知Ｘを送信したノードＮは、手元の更新不可能通知Ｘが最多にならず、手元の候補更新情報Ｖのいずれかが最多となった場合、この分離要求Ｄに関する自ノードが記憶している台帳を記憶領域から消去してもよい。それに代えて、ノードＮは、分離要求Ｄに従う台帳の分離を行った後、分離後の２以上の台帳のうち一部（例えば、更新不可とした台帳）を記憶領域から消去してもよい。
【0047】
なお、ノードＮは、分離要求Ｄに従う台帳の分離を行った場合に限られず、例えば、自ノードのリソースに関する所定条件が満たされた場合に、自ノードの記憶している台帳を記憶領域から消去するように構成されてもよい。例えば、ノードＮは、自ノードの記憶容量の空き容量が所定の閾値以下となった場合に自ノードの記憶している台帳を、例えば、最終更新のタイミングが遅いものから優先的に、消去することで、記憶容量の不足を回避することができる。
【0048】
また、ノードＮが、自ノードの記憶している台帳に関する更新要求Ｒの受信頻度に関する所定条件が満たされた場合に、その台帳を自ノードの記憶領域から消去するように構成されてもよい。その場合、ノードＮは、例えば、自ノードの記憶している台帳の各々に関し、過去の所定時間長の期間内に受信した更新要求Ｒの数をカウントし、その数が所定の閾値以下である台帳を消去することで、使用頻度の低い台帳を記憶し続ける無駄を回避することができる。
【0049】
また、ノードＮが、自ノードの記憶している台帳に関する更新要求に応じて他のノードＮから送信されてきた候補更新情報Ｖの数に関する所定条件が満たされた場合、その台帳を消去するように構成されてもよい。その場合、ノードＮは、例えば、自ノードの記憶している台帳の各々に関し、過去に他のノードＮから受信した候補更新情報Ｖの数、すなわち、その台帳を記憶している他のノードＮの数が所定の閾値以上である台帳を消去することで、必要以上に多くのノードＮが同じ台帳を記憶する無駄を回避することができる。
【0050】
なお、分離要求Ｄに応じた台帳の分離は、台帳の消去を伴う場合、むしろ、ノードＮにリソースの節約をもたらす。
【0051】
従って、例えば、ノードＮが、自ノードのリソースに関する所定条件が満たされた場合に、自ノードの記憶している台帳と同じ台帳から１以上の台帳を分離して２以上の台帳とする更新を指示する更新要求Ｒである分離要求Ｄを他のノードＮに送信する構成が採用されてもよい。
【0052】
この場合、ノードＮは、例えば、自ノードの記憶容量の空き容量が所定の閾値以下となった場合に、自ノードの記憶している台帳に関する分離要求Ｄを生成し、他のノードＮに送信する。その後、その分離要求Ｄに関する候補更新情報Ｖが多数決により採用されると、分離要求Ｄの発出元のノードＮは、その候補更新情報Ｖを用いて自ノードの記憶している台帳から１以上の台帳を分離し、分離後の２以上の台帳のうち一部（例えば、更新不可とした台帳）を記憶領域から消去することで、自ノードの記憶容量の空き容量を増やすことができる。
【0053】
データ管理システム１においては、台帳の統合、すなわち、第１の台帳に第２の台帳の情報を追加して第１の台帳を更新するとともに、第２の台帳を更新不可とすることも許容される。
【0054】
図８は、台帳Ｌ（１）に対し台帳Ｌ（２）の情報が追加されて、台帳Ｌ（３）（台帳Ｌ（１）を更新した台帳）が生成される様子を示した図である。図８（Ａ）は統合前の台帳Ｌを示し、図８（Ｂ）は統合後の台帳Ｌを示す。図８に示される台帳Ｌ（１）は、例えば、ユーザＰの銀行口座の入出金履歴及び残高を示すデータである。また、図８に示される台帳Ｌ（２）は、例えば、ユーザＱの銀行口座の入出金履歴及び残高を示すデータである。
【0055】
図８の例では、ブロックＢＰ（１）、ＢＰ（２）を含む台帳Ｌ（１）に対し、台帳Ｌ（２）の最新のブロックＢＱ（２）が追加されて、新たな台帳Ｌ（３）が生成される。そして、この場合、ユーザＰ及びユーザＱに関する将来の更新はいずれも台帳Ｌ（３）に対し行われるため、台帳Ｌ（２）は更新不可の台帳とされる。
【0056】
上記のような、第１の台帳に対し第２の台帳の情報を追加して第１の台帳を更新するとともに、第２の台帳を更新不可とすることを指示する更新要求Ｒを以下、統合要求Ｅという。
【0057】
なお、統合要求Ｅに従いノードＮが生成する候補更新情報Ｖ、すなわち、統合要求Ｅに従い台帳を統合するための情報の候補は、例えば、統合後の２以上の台帳（例えば、図８の例におけるＬ（２）及びＬ（３））の各々に関するハッシュ値と最新のブロックＢを含む。
【0058】
【0059】
ただし、既述のように、データ管理システム１においては、図４に示したように、各ノードＮが記憶している台帳は必ずしも同じではない。従って、ノードＮは、統合要求Ｅに関する第１の台帳と第２の台帳のいずれを記憶しているかによって、以下のように異なる処理を行う。
【0060】
統合要求Ｅに関する第１の台帳と第２の台帳の両方を記憶しているノードＮは、統合要求Ｅに従い第１の台帳を更新するための情報の候補である候補更新情報Ｖを他のノードＮに送信する。その後、そのノードＮは、手元の数が最多の候補更新情報Ｖを用いて、自ノードの記憶している第１の台帳を更新するとともに、自ノードの記憶している第２の台帳を更新不可とする。
【0061】
統合要求Ｅに関する第１の台帳を記憶しており、統合要求Ｅに関する第２の台帳を記憶していないノードＮは、候補更新情報Ｖを生成できない。従って、そのノードＮは、候補更新情報Ｖの送信は行わず、手元の数が最多の候補更新情報Ｖを用いた、自ノードの記憶している第１の台帳の更新のみを行う。
【0062】
統合要求Ｅに関する第１の台帳を記憶しておらず、統合要求Ｅに関する第２の台帳を記憶しているノードＮは、候補更新情報Ｖを生成できない。従って、そのノードＮは、候補更新情報Ｖの送信は行わず、自ノードの記憶している第２の台帳を更新不可とする処理のみを行う。
【0063】
一般的に、同じ量のデータを分割すると、分割後のデータの総量は分割前のデータの量よりも大きくなる。従って、自ノードのリソースが逼迫しているノードＮは、台帳の統合を行うことで、リソース不足を軽減できる。一方、自ノードのリソースに十分な余裕があるノードＮは、台帳の統合を行うメリットが乏しい。
【0064】
従って、データ管理システム１において、ノードＮが、自ノードのリソースに関する所定条件が満たされた場合、自ノードの記憶している第１の台帳と同じ台帳に対し自ノードの記憶している第２の台帳と同じ台帳の情報を追加して、自ノードの記憶している第１の台帳と同じ台帳を更新するとともに、自ノードの記憶している第２の台帳と同じ台帳を更新不可とすることを指示する更新要求Ｒである統合要求Ｅを他のノードＮに送信するように構成されてもよい。
【0065】
この場合、ノードＮは、例えば、自ノードの記憶容量の空き容量が所定の閾値以下となると、自ノードの記憶している第１の台帳と第２の台帳に関する統合要求Ｅを他のノードＮに送信する。
【0066】
統合要求Ｅを受け取ったノードＮのうち、統合要求Ｅに関する第１の台帳及び第２の台帳を記憶しているノードＮは、自ノードのリソースに関する所定条件が満たされているか否かに基づき、統合要求Ｅに従う台帳の統合が可能であるか否かを判定する。そして、統合要求Ｅに従う台帳の統合が可能である場合は、統合要求Ｅに従い台帳を統合するための情報の候補である候補更新情報Ｖを他のノードＮに送信する。一方、統合要求Ｅに従う台帳の統合が不可能である場合は、候補更新情報Ｖに代えて、統合要求Ｅに従う台帳の統合が不可能であることを示す更新不可能通知Ｘを他のノードＮに送信する。
【0067】
例えば、自ノードの記憶容量の空き容量が所定の閾値以下である場合、ノードＮは候補更新情報Ｖを他のノードＮに送信し、自ノードの記憶容量の空き容量が所定の閾値より大きい場合、ノードＮは更新不可能通知Ｘを他のノードＮに送信する。
【0068】
上記のように、リソースが逼迫しているノードＮは、統合要求Ｅを他のノードＮに送信することで、台帳の統合を提案することができる。そして、統合要求Ｅを受け取ったノードＮは、自ノードのリソースの状況に応じて、その統合要求Ｅに対する賛成又は反対を他のノードＮに対し表明することができる。
【0069】
ところで、データ管理システム１においては、例えば、ユーザＰの銀行口座の入出金履歴及び残高を示す台帳Ｌ（Ｐ）と、ユーザＱの銀行口座の入出金履歴及び残高を示す台帳Ｌ（Ｑ）は個別の台帳として扱うことが許容される。従って、例えば、ユーザＰの銀行口座の残高からユーザＱの銀行口座に対し１０，０００円の送金をそれらの台帳に反映させるための更新要求は、台帳Ｌ（Ｐ）に対し１０，０００円の出金を示すデータを追加するとともに現在の残高から１０，０００円を減算した金額を新たな残高とする、という処理を指示する更新要求Ｒ（Ｐ）と、台帳Ｌ（Ｑ）に対し１０，０００円の入金を示すデータを追加するとともに現在の残高に１０，０００円を加算した金額を新たな残高とする、という処理を指示する更新要求Ｒ（Ｑ）という、２つの更新要求Ｒとなる。
【0070】
この場合、例えば、ユーザＰの銀行口座の残高が５，０００円である場合、更新要求Ｒ（Ｑ）に従う台帳Ｌ（Ｑ）の更新は可能であるが、更新要求Ｒ（Ｐ）に従う台帳Ｌ（Ｐ）の更新は残高不足のため不可能である。その場合、仮に更新要求Ｒ（Ｑ）に従う台帳Ｌ（Ｑ）の更新が実行され、更新要求Ｒ（Ｐ）に従う台帳Ｌ（Ｐ）の更新が実行されなければ、台帳Ｌ（Ｐ）と台帳Ｌ（Ｑ）に不整合が生じる。
【0071】
上記の問題を回避するため、いずれかのノードＮがデータ管理システム１の外部から自ノードの記憶している台帳を含む２以上の互いに関連する台帳に関する更新要求Ｒを取得した場合、又は、いずれかの他のノードＮから自ノードの記憶している台帳を含む２以上の互いに関連する台帳の更新要求Ｒを受信した場合、それらの２以上の台帳の少なくとも１つに関し、他のノードＮから受信した更新要求Ｒに関する更新不可能通知Ｘの数が所定条件を満たせば、それらの２以上の台帳の全てに関し更新要求Ｒに従う更新を行わない、という構成が採用されてもよい。
【0072】
図９～図１１は、２つの互いに関連する台帳に関する更新要求Ｒに従い、それらの台帳の更新が行われる手順を示した図である。図９～図１１において、ノードＮが受け取る更新要求Ｒは、台帳Ｌ（Ｐ）の更新を要求する更新要求Ｒ（Ｐ）と、台帳Ｌ（Ｑ）の更新を要求する更新要求Ｒ（Ｑ）で構成される。そして、これらの更新要求Ｒ（Ｐ）と更新要求Ｒ（Ｑ）に従う台帳Ｌの更新は、両方の更新要求Ｒに従う台帳Ｌの更新が可能と判定された場合に限り、実行される。
【0073】
まず、データ管理システム１の外部から更新要求Ｒを取得したノードＮは、更新要求Ｒを他のノードＮに送信する（図９）。
【0074】
台帳Ｌ（Ｐ）を記憶しているノードＮは、更新要求Ｒ（Ｐ）に従う台帳Ｌ（Ｐ）の更新が可能か否かを判定し、可能であれば候補更新情報Ｖ（Ｐ）を生成し他のノードＮに送信し、不可能であれば候補更新情報Ｖ（Ｐ）に代えて更新不可能通知Ｘ（Ｐ）を他のノードＮに送信する（図１０）。
【0075】
台帳Ｌ（Ｑ）を記憶しているノードＮは、更新要求Ｒ（Ｑ）に従う台帳Ｌ（Ｑ）の更新が可能か否かを判定し、可能であれば候補更新情報Ｖ（Ｑ）を生成し他のノードＮに送信し、不可能であれば候補更新情報Ｖ（Ｑ）に代えて更新不可能通知Ｘ（Ｑ）を他のノードＮに送信する（図１０）。
【0076】
なお、台帳Ｌ（Ｐ）と台帳Ｌ（Ｑ）の両方を記憶しているノードＮは、更新要求Ｒ（Ｐ）に応じた上記の処理と、更新要求Ｒ（Ｑ）に応じた上記の処理との両方を行う（図１０）。
【0077】
そして、台帳Ｌ（Ｐ）を記憶しているノードＮは、手元の候補更新情報Ｖ（Ｐ）のいずれかが最多となり、かつ、手元の候補更新情報Ｖ（Ｑ）のいずれかが最多となった場合に限り、最多の候補更新情報Ｖ（Ｐ）を用いて自ノードの記憶している台帳Ｌ（Ｐ）を更新し台帳Ｌ（Ｐ’）を生成する（図１１）。すなわち、仮に手元の候補更新情報Ｖ（Ｐ）のいずれかが最多となり、更新要求Ｒ（Ｐ）に従う台帳Ｌ（Ｐ）の更新が可能と判定されても、手元の更新不可能通知Ｘ（Ｑ）が最多となり、更新要求Ｒ（Ｑ）に従う台帳Ｌ（Ｑ）の更新が不可能と判定された場合、ノードＮは候補更新情報Ｖ（Ｐ）を用いた台帳Ｌ（Ｐ）の更新を行わない。
【0078】
また、台帳Ｌ（Ｑ）を記憶しているノードＮは、手元の候補更新情報Ｖ（Ｐ）のいずれかが最多となり、かつ、手元の候補更新情報Ｖ（Ｑ）のいずれかが最多となった場合に限り、最多の候補更新情報Ｖ（Ｑ）を用いて自ノードの記憶している台帳Ｌ（Ｑ）を更新し台帳Ｌ（Ｑ’）を生成する（図１１）。すなわち、仮に手元の候補更新情報Ｖ（Ｑ）のいずれかが最多となり、更新要求Ｒ（Ｑ）に従う台帳Ｌ（Ｑ）の更新が可能と判定されても、手元の更新不可能通知Ｘ（Ｐ）が最多となり、更新要求Ｒ（Ｐ）に従う台帳Ｌ（Ｐ）の更新が不可能と判定された場合、ノードＮは候補更新情報Ｖ（Ｑ）を用いた台帳Ｌ（Ｑ）の更新を行わない。
【0079】
なお、台帳Ｌ（Ｐ）と台帳Ｌ（Ｑ）の両方を記憶しているノードＮは、台帳Ｌ（Ｐ）を記憶しているノードＮは、手元の候補更新情報Ｖ（Ｐ）のいずれかが最多となり、かつ、手元の候補更新情報Ｖ（Ｑ）のいずれかが最多となった場合に限り、最多の候補更新情報Ｖ（Ｐ）を用いて自ノードの記憶している台帳Ｌ（Ｐ）を更新するとともに、最多の候補更新情報Ｖ（Ｑ）を用いて自ノードの記憶している台帳Ｌ（Ｑ）を更新し、手元の更新不可能通知Ｘ（Ｐ）が最多となったか、もしくは、手元の更新不可能通知Ｘ（Ｑ）が最多となった場合、台帳Ｌ（Ｐ）と台帳Ｌ（Ｑ）のいずれも更新しない（図１１）。
【0080】
上記の処理により、互いに関連する台帳Ｌ（Ｐ）と台帳Ｌ（Ｑ）の更新における整合性が保たれる。
【0081】
既述のように、データ管理システム１においては、各ノードＮは自ノードが記憶する台帳を、例えば記憶容量の不足が生じないように、適宜消去することが許容される。従って、ある台帳に関し、その台帳を記憶しているノードＮの数が少なくなりすぎて、多数決により決定される候補更新情報Ｖや更新不可能通知Ｘの信頼性が確保できなくなる場合が生じ得る。
【0082】
そのような問題を回避するために、各ノードＮが、自ノードが記憶しておらず、記憶している他のノードＮの数が少ない台帳を、他のノードＮから取り寄せて記憶するように構成されてもよい。
【0083】
例えば、ノードＮが、自ノードの記憶していない台帳に関する更新要求Ｒの受信頻度に関する所定条件が満たされた場合、他のノードＮにその台帳の送信を要求し、その要求に応じていずれかの他のノードＮから送信されてきた台帳を記憶するように構成されてもよい。その場合、ノードＮは、例えば、過去の所定時間長の期間内に受信した更新要求Ｒの数を、その更新要求Ｒに関する台帳毎にカウントし、その数が所定の閾値以上である台帳を、他のノードＮから取り寄せて記憶する。その結果、使用頻度の高い台帳を記憶するノードＮの数が増えることになる。
【0084】
また、例えば、ノードＮが、自ノードの記憶していない台帳に関する更新要求Ｒに応じて他のノードＮから送信されてきた候補更新情報Ｖの数に関する所定条件が満たされた場合、他のノードＮにその台帳の送信を要求し、その要求に応じていずれかの他のノードＮから送信されてきた台帳を記憶するように構成されてもよい。その場合、ノードＮは、例えば、自ノードの記憶していない台帳の各々に関し、過去に他のノードＮから受信した候補更新情報Ｖの数、すなわち、その台帳を記憶している他のノードＮの数が所定の閾値以下である台帳を他のノードＮから取り寄せて記憶する。その結果、記憶しているノードＮが不足している台帳を新たに記憶するノードＮが増加し、その不足が解消する。
【0085】
なお、仮に、ノードＮが、自ノードの記憶していない台帳を他のノードＮから取り寄せて記憶するトリガとなる条件が、全てのノードＮで共通であれば、全てのノードが同じ台帳をいっせいに記憶することになり、望ましくない。従って、ノードＮが他のノードＮから台帳を取り寄せて記憶するトリガとなる条件は、例えば乱数等を用いて、ノードＮ毎に異なるように構成されることが望ましい。
【0086】
同様に、仮に、ノードＮが、自ノードの記憶している台帳を消去するトリガとなる条件が、全てのノードＮで共通であれば、全てのノードが同じ台帳をいっせいに消去することになり、望ましくない。従って、ノードＮが記憶している台帳を消去するトリガとなる条件は、例えば乱数等を用いて、ノードＮ毎に異なるように構成されることが望ましい。
【0087】
図１２は、データ管理システム９と比較した場合のデータ管理システム１のメリットを説明するための図である。図１２（Ａ）はデータ管理システム９を示し、図１２（Ｂ）はデータ管理システム１を示す。データ管理システム９においては、全てのノードが、全てのブロックを含む台帳を１つ記憶している。データ管理システム９においてノードが記憶する台帳のデータサイズは時間の経過に伴い肥大化する。また、台帳が更新される場合、全てのノードのコンセンサスを得るため、代表ノードの処理負荷が大きい。さらに、１つの台帳が全てのデータを含んでいるため、台帳の更新頻度が高く、通信ネットワークのトラフィックが大きい。
【0088】
一方、データ管理システム１においては、各ノードが必要なデータのみを含む小さいサイズの台帳を記憶すればよく、各ノードが記憶する台帳は異なってもよい。従って、各ノードが記憶する台帳が肥大化することはなく、台帳が各ノードの記憶容量の不足をもたらすことはない。また、台帳が更新される場合、各ノードが一部の他ノードから受信した候補更新情報に基づき正しい候補更新情報を決定するため、一部のノードに更新情報の検証のための処理負荷が集中することがなく、また、各ノードの処理負荷も小さい。さらに、各ノードは自ノードの記憶している台帳に関する更新のみを行えばよいため、台帳の更新頻度は低く、通信ネットワークのトラフィックが小さい。
【0089】
なお、上述した実施形態において、候補更新情報Ｖは更新後の台帳のハッシュ値と最新のブロックを含むものとしたが、台帳の更新を可能とする情報である限り、候補更新情報Ｖにどのような情報が含まれてもよい。例えば、候補更新情報Ｖが更新後の台帳全体を含んでもよい。
【0090】
候補更新情報Ｖが更新後の台帳全体を含む場合、更新要求Ｒに関する古い台帳を記憶しているノードＮは、更新要求Ｒに従い、古い台帳を消去するとともに、他のノードＮから受信した候補更新情報Ｖに含まれる台帳を記憶することで、自ノードの記憶する台帳を更新できる。
【0091】
【0092】
また、上述した実施形態において、統合要求Ｅに従い第１の台帳に追加されるデータの出所となる台帳の数は１つ（第２の台帳のみ）であるものとしたが、第１の台帳に追加されるデータの出所となる台帳の数は２つ以上であってもよい。
【0093】
本発明は、上述したデータ管理システム１に例示されるシステム、上述したデータ管理システム１を構成するノードＮに例示されるデータ処理装置、上述したデータ管理システム１を構成するノードＮに例示されるデータ処理装置が行う処理をコンピュータに実行させるためのプログラム、当該プログラムを持続的に記憶し当該プログラムに従うデータ処理を実行するプロセッサを有するコンピュータ、当該プログラムをコンピュータ読み取り可能に記録している記録媒体等を含む。
【0094】
本発明に係るプログラムは、コンピュータ読み取り可能な記録媒体に記録された状態で提供され、当該記録媒体からコンピュータにより読み取られて実行されてもよいし、通信ネットワークを介してコンピュータにダウンロードされて実行されてもよい。
【符号の説明】
【0095】
１…データ管理システム、９…データ管理システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
