知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024178981
(43)【公開日】2024-12-26
(54)【発明の名称】分散台帳システム、及び分散台帳システムの制御方法
(51)【国際特許分類】
G06Q 10/063 20230101AFI20241219BHJP
【ＦＩ】
G06Q10/063
【審査請求】未請求
【請求項の数】15
【出願形態】ＯＬ
(21)【出願番号】P 2023097435
(22)【出願日】2023-06-14
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000176
【氏名又は名称】弁理士法人一色国際特許事務所
(72)【発明者】
【氏名】佐藤 竜也
(72)【発明者】
【氏名】下沢 拓
(72)【発明者】
【氏名】伊藤 哲
【テーマコード（参考）】
5L010
5L049
【Ｆターム（参考）】
5L010AA06
5L010AA20
5L049AA06
5L049AA20
(57)【要約】
【課題】客観性のある情報に基づき分散台帳システムの全体としての健全性を監視する。
【解決手段】分散台帳システムは、複数の組織の夫々が有する分散台帳ノードを通信可能に接続することにより構成され、スマートコントラクトを実行することが可能であり、スマートコントラクトは、複数の組織の分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理する。分散台帳ノードは、組織のクライアントノード等の他の装置から受信したトランザクションに応じてスマートコントラクトを実行する。スマートコントラクトは、第１の組織が第２の組織の分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信し、受信した健全性監視結果を検証することにより第２の組織の分散台帳ノードの健全性を検証し、健全性を検証した結果である健全性検証結果を分散台帳に記録する。
【選択図】図５
【解決手段】分散台帳システムは、複数の組織の夫々が有する分散台帳ノードを通信可能に接続することにより構成され、スマートコントラクトを実行することが可能であり、スマートコントラクトは、複数の組織の分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理する。分散台帳ノードは、組織のクライアントノード等の他の装置から受信したトランザクションに応じてスマートコントラクトを実行する。スマートコントラクトは、第１の組織が第２の組織の分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信し、受信した健全性監視結果を検証することにより第２の組織の分散台帳ノードの健全性を検証し、健全性を検証した結果である健全性検証結果を分散台帳に記録する。
【選択図】図５
【特許請求の範囲】
【請求項1】
複数の組織の夫々により提供される分散台帳ノードを含み、
前記複数の分散台帳ノードにより構成される分散台帳ネットワークを提供する、
分散台帳システムであって、
外部から受信したトランザクションに応じてスマートコントラクトを実行し、
前記スマートコントラクトは、
複数の前記組織の前記分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理し、
第１の前記組織が第２の前記組織の前記分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信し、
受信した前記健全性監視結果を検証することにより前記第２の組織の前記分散台帳ノードの健全性を検証し、
健全性を検証した結果である健全性検証結果を前記分散台帳に記録する、
分散台帳システム。
前記複数の分散台帳ノードにより構成される分散台帳ネットワークを提供する、
分散台帳システムであって、
外部から受信したトランザクションに応じてスマートコントラクトを実行し、
前記スマートコントラクトは、
複数の前記組織の前記分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理し、
第１の前記組織が第２の前記組織の前記分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信し、
受信した前記健全性監視結果を検証することにより前記第２の組織の前記分散台帳ノードの健全性を検証し、
健全性を検証した結果である健全性検証結果を前記分散台帳に記録する、
分散台帳システム。
【請求項2】
請求項１に記載の分散台帳システムであって、
前記分散台帳は、前記組織の夫々が準備し提供すべき前記分散台帳ノードの構成を示した情報である構成設計情報を記録し、
前記スマートコントラクトは、
前記第２の組織の前記健全性検証結果を前記第２の組織の前記構成設計情報と比較対照することにより、前記組織が前記構成設計情報に準拠している度合いを示す情報である構成準拠状況を生成し、
生成した前記構成準拠状況を前記分散台帳に記録する、
分散台帳システム。
前記分散台帳は、前記組織の夫々が準備し提供すべき前記分散台帳ノードの構成を示した情報である構成設計情報を記録し、
前記スマートコントラクトは、
前記第２の組織の前記健全性検証結果を前記第２の組織の前記構成設計情報と比較対照することにより、前記組織が前記構成設計情報に準拠している度合いを示す情報である構成準拠状況を生成し、
生成した前記構成準拠状況を前記分散台帳に記録する、
分散台帳システム。
【請求項3】
請求項２に記載の分散台帳システムであって、
前記スマートコントラクトは、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は、前記第２の組織に前記分散台帳ノードの構成の見直しを指示する情報、又は、第３の前記組織が前記第２の組織の代わりに分散台帳ノードを用意することを指示する情報を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は、前記第２の組織に前記分散台帳ノードの構成の見直しを指示する情報、又は、第３の前記組織が前記第２の組織の代わりに分散台帳ノードを用意することを指示する情報を前記分散台帳に記録する、
分散台帳システム。
【請求項4】
請求項２に記載の分散台帳システムであって、
前記スマートコントラクトは、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は前記分散台帳ノードの構成が不足していることにより前記第２の組織にペナルティが課されることを示す情報を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は前記分散台帳ノードの構成が不足していることにより前記第２の組織にペナルティが課されることを示す情報を前記分散台帳に記録する、
分散台帳システム。
【請求項5】
請求項２に記載の分散台帳システムであって、
前記スマートコントラクトは、前記構成準拠状況に基づき、前記複数の組織の夫々の信頼度である組織信頼度を生成し、生成した前記複数の組織の夫々の前記組織信頼度を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記構成準拠状況に基づき、前記複数の組織の夫々の信頼度である組織信頼度を生成し、生成した前記複数の組織の夫々の前記組織信頼度を前記分散台帳に記録する、
分散台帳システム。
【請求項6】
請求項２又は５に記載の分散台帳システムであって、
前記スマートコントラクトは、前記複数の組織の夫々の前記健全性監視結果に基づき、前記複数の組織の夫々の信頼度である組織信頼度を生成し、生成した前記組織信頼度を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記複数の組織の夫々の前記健全性監視結果に基づき、前記複数の組織の夫々の信頼度である組織信頼度を生成し、生成した前記組織信頼度を前記分散台帳に記録する、
分散台帳システム。
【請求項7】
請求項１に記載の分散台帳システムであって、
前記複数の組織の夫々が有する、前記分散台帳ノードと通信可能に接続する複数のクライアントノードを含み、
第１の前記組織の前記クライアントノードは、
前記第２の組織の前記分散台帳ノードの健全性の監視を行い、
前記監視により得られる前記健全性監視結果を含む前記トランザクションを生成し、
生成した前記トランザクションを前記分散台帳ノードに送信する、
分散台帳システム。
前記複数の組織の夫々が有する、前記分散台帳ノードと通信可能に接続する複数のクライアントノードを含み、
第１の前記組織の前記クライアントノードは、
前記第２の組織の前記分散台帳ノードの健全性の監視を行い、
前記監視により得られる前記健全性監視結果を含む前記トランザクションを生成し、
生成した前記トランザクションを前記分散台帳ノードに送信する、
分散台帳システム。
【請求項8】
請求項７に記載の分散台帳システムであって、
前記分散台帳は、前記組織が前記第２の組織の前記分散台帳ノードの健全性を監視する際に用いる監視方法を示す情報である健全性監視方法定義を記録し、
前記クライアントノードは、前記健全性監視方法定義の前記監視方法に従って前記第２の組織の健全性を監視する、
分散台帳システム。
前記分散台帳は、前記組織が前記第２の組織の前記分散台帳ノードの健全性を監視する際に用いる監視方法を示す情報である健全性監視方法定義を記録し、
前記クライアントノードは、前記健全性監視方法定義の前記監視方法に従って前記第２の組織の健全性を監視する、
分散台帳システム。
【請求項9】
請求項７に記載の分散台帳システムであって、
前記クライアントノードは、サービスディスカバリ機能により前記第２の組織の分散台帳ノードの生死を確認することにより前記健全性の監視を行う、
分散台帳システム。
前記クライアントノードは、サービスディスカバリ機能により前記第２の組織の分散台帳ノードの生死を確認することにより前記健全性の監視を行う、
分散台帳システム。
【請求項10】
請求項１に記載の分散台帳システムであって、
前記分散台帳は、前記組織が前記第２の組織の前記分散台帳ノードの健全性を監視する際に用いる監視方法を示す情報である健全性監視方法定義を記録し、
前記スマートコントラクトは、前記複数の組織の夫々の前記分散台帳ノードの監視を担当する前記組織である監視担当組織を、前記スマートコントラクトの合意条件、前記健全性監視方法定義に含まれる健全性判定可能基準、及び前記健全性監視結果のうちの少なくともいずれかに基づき選出し、選出した前記監視担当組織を示す情報を前記分散台帳に記録する、
分散台帳システム。
前記分散台帳は、前記組織が前記第２の組織の前記分散台帳ノードの健全性を監視する際に用いる監視方法を示す情報である健全性監視方法定義を記録し、
前記スマートコントラクトは、前記複数の組織の夫々の前記分散台帳ノードの監視を担当する前記組織である監視担当組織を、前記スマートコントラクトの合意条件、前記健全性監視方法定義に含まれる健全性判定可能基準、及び前記健全性監視結果のうちの少なくともいずれかに基づき選出し、選出した前記監視担当組織を示す情報を前記分散台帳に記録する、
分散台帳システム。
【請求項11】
請求項６に記載の分散台帳システムであって、
前記スマートコントラクトは、前記複数の組織の夫々の前記分散台帳ノードの監視を担当する前記組織である監視担当組織を前記組織信頼度に基づき決定し、決定した前記監視担当組織を示す情報を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記複数の組織の夫々の前記分散台帳ノードの監視を担当する前記組織である監視担当組織を前記組織信頼度に基づき決定し、決定した前記監視担当組織を示す情報を前記分散台帳に記録する、
分散台帳システム。
【請求項12】
請求項２に記載の分散台帳システムであって、
前記スマートコントラクトは、前記組織の前記構成準拠状況に応じて、前記第２の組織の分散台帳ノードの監視を担当する前記組織である監視担当組織を選出する際の重み付けを示す情報を前記分散台帳に記録する、
分散台帳システム。
前記スマートコントラクトは、前記組織の前記構成準拠状況に応じて、前記第２の組織の分散台帳ノードの監視を担当する前記組織である監視担当組織を選出する際の重み付けを示す情報を前記分散台帳に記録する、
分散台帳システム。
【請求項13】
複数の組織の夫々により提供される分散台帳ノードを含み、
前記複数の分散台帳ノードにより構成される分散台帳ネットワークを提供し、
外部から受信したトランザクションに応じてスマートコントラクトを実行し、
前記スマートコントラクトは、複数の前記組織の前記分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理する、
分散台帳システムの制御方法であって、
前記スマートコントラクトが、
第１の前記組織が第２の前記組織の前記分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信するステップ、
受信した前記健全性監視結果を検証することにより前記第２の組織の前記分散台帳ノードの健全性を検証するステップ、及び、
健全性を検証した結果である健全性検証結果を前記分散台帳に記録するステップ、
を実行する、分散台帳システムの制御方法。
前記複数の分散台帳ノードにより構成される分散台帳ネットワークを提供し、
外部から受信したトランザクションに応じてスマートコントラクトを実行し、
前記スマートコントラクトは、複数の前記組織の前記分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理する、
分散台帳システムの制御方法であって、
前記スマートコントラクトが、
第１の前記組織が第２の前記組織の前記分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信するステップ、
受信した前記健全性監視結果を検証することにより前記第２の組織の前記分散台帳ノードの健全性を検証するステップ、及び、
健全性を検証した結果である健全性検証結果を前記分散台帳に記録するステップ、
を実行する、分散台帳システムの制御方法。
【請求項14】
請求項１３に記載の分散台帳システムの制御方法であって、
前記分散台帳が、前記組織の夫々が準備し提供すべき前記分散台帳ノードの構成を示した情報である構成設計情報を記録するステップ、及び、
前記スマートコントラクトが、前記第２の組織の前記健全性検証結果を前記第２の組織の前記構成設計情報と比較対照することにより、前記組織が前記構成設計情報に準拠している度合いを示す情報である構成準拠状況を生成し、生成した前記構成準拠状況を前記分散台帳に記録するステップ、
を更に実行する、分散台帳システムの制御方法。
前記分散台帳が、前記組織の夫々が準備し提供すべき前記分散台帳ノードの構成を示した情報である構成設計情報を記録するステップ、及び、
前記スマートコントラクトが、前記第２の組織の前記健全性検証結果を前記第２の組織の前記構成設計情報と比較対照することにより、前記組織が前記構成設計情報に準拠している度合いを示す情報である構成準拠状況を生成し、生成した前記構成準拠状況を前記分散台帳に記録するステップ、
を更に実行する、分散台帳システムの制御方法。
【請求項15】
請求項１４に記載の分散台帳システムの制御方法であって、
前記スマートコントラクトが、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は前記第２の組織に前記分散台帳ノードの構成の見直しを指示する情報を前記分散台帳に記録するステップ、
を更に実行する、分散台帳システムの制御方法。
前記スマートコントラクトが、前記第２の組織の前記構成準拠状況が前記構成設計情報を満たしているか否かを判定し、満たしていない場合は前記第２の組織に前記分散台帳ノードの構成の見直しを指示する情報を前記分散台帳に記録するステップ、
を更に実行する、分散台帳システムの制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、分散台帳システム、及び分散台帳システムの制御方法に関する。
【背景技術】
【0002】
近年、金融機関や政府等の中央集権機関を介して行われていた取引を、個々の利用者の情報処理装置を用いて構成されたＰ２Ｐ（Peer to Peer）ネットワーク（以下、「分散台帳ネットワーク」と称する。）において管理される分散台帳（以下、「ブロックチェーン」とも称する。）に記録することにより、利用者の間で直接行えるようにした技術（以下、「分散台帳技術」と称する。）が登場し、様々な分野への適用が進んでいる。
【0003】
分散台帳技術に関し、例えば、特許文献１には、ブロックチェーンにおけるトランザクションのエンドースメント（承認）を最適化された状態で行えるようにすることを目的として構成されたシステムについて記載されている。上記システムでは、エンドースメントを実行するための一つ又は複数のエンドースメント要求を識別し、エンドースメント要求を順序付けノードに送信し、ピア（Peer）の性能指標を監視し、性能指標に基づき１つ又は複数のエンドースメント要求をピアに割り当てる。
【0004】
また、例えば、非特許文献１には、金融機関や政府等の信頼できる中央集権機関を経由して実施されてきた取引を、分散台帳を用いて仮想通貨により利用者の間で直接行えるようにする技術について記載されている。
【0005】
また、例えば、非特許文献２及び非特許文献３には、事前に定義された処理をトランザクション等のイベントをトリガーとして実行することにより分散台帳を更新する技術であるスマートコントラクト（Smart Contract）（「Chaincode」とも称される。）について記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特願２０２０－５６２２０４号公報
【非特許文献】
【0007】
【非特許文献1】“A Peer-to-Peer Electronic Cash System”,[online]、［令和５年５月２６日検索］、インターネット＜URL：https://bitcoin.org/bitcoin.pdf＞
【非特許文献2】“Ethereum White Paper”,[online]、［令和５年５月２６日検索］、インターネット＜URL：https://ethereum.org/ja/whitepaper/＞
【非特許文献3】“Hyperledger Fabric”,[online]、［令和５年５月２６日検索］、インターネット＜URL：http://hyperledger-fabric.readthedocs.io/en/release-2.5/＞
【発明の概要】
【発明が解決しようとする課題】
【0008】
上記の分散台帳技術は次のような特徴を有する。
（１）分散台帳ネットワークの参加者の間の取引において、中央集権機関ではなく、任意もしくは特定の参加者による合意形成や承認により取引が確定する。
（２）複数のトランザクションをブロックとして管理し、ブロックを数珠繋ぎにして分散台帳に記録し、連続するブロックにハッシュ値を記録することにより、記録内容の改竄が実質的に不可能である。
（３）参加者全員が同一の台帳データを共有するため、参加者全員が取引の内容を確認することができる。
（１）分散台帳ネットワークの参加者の間の取引において、中央集権機関ではなく、任意もしくは特定の参加者による合意形成や承認により取引が確定する。
（２）複数のトランザクションをブロックとして管理し、ブロックを数珠繋ぎにして分散台帳に記録し、連続するブロックにハッシュ値を記録することにより、記録内容の改竄が実質的に不可能である。
（３）参加者全員が同一の台帳データを共有するため、参加者全員が取引の内容を確認することができる。
【0009】
このように、分散台帳技術によれば、中央集権機関による管理が不要となり、複数の主体間で情報の共有や取引を行うことが可能になる。
【0010】
分散台帳技術の利用形態として、非特許文献１に記載されているような特定の管理者の存在を前提としないパブリック型、単一の管理者の存在を前提とするプライベート型、及び非特許文献３に記載されているような複数の管理者の存在を前提とするコンソーシアム型がある。このうちプライベート型及びコンソーシアム型は、分散台帳ネットワークにおける運用の取り決めに管理者の許可が必要とされるためパーミッション型（許可型）とも称される。
【0011】
上記利用形態のうち、コンソーシアム型は、例えば、複数の組織（例えば、特定の業界におけるコンソーシアムやサプライチェーンに関係する複数企業間等）が協力して運営する場合に向いており、とくにエンタープライズ分野（金融、産業、流通、公共、ＩＴ基盤、社会インフラ等）での活用が有望視されている。コンソーシアム型では、例えば、分散台帳ネットワーク（コンソーシアム）に参加する複数の組織の夫々のノード（以下、「分散台帳ノード」と称する。）が合意形成プロトコルに基づき同期し連動しつつ、事前に取り決められた契約内容（スマートコントラクト）に従って取引を実行する。
【0012】
ところで、分散台帳ネットワークを用いて構成される情報処理システム（以下、「分散台帳システム」と称する。）の実際の運用状態（システム構成等）と参加組織全体として予定（設計）されていた運用状態との間に乖離が生じた場合、分散台帳システムの健全性や性能、可用性が損なわれてしまう可能性がある。また、コンソーシアム型では、各参加組織の夫々がノードを用意するため、参加組織全体として予定されていた運用状態が維持されているか否かを必ずしも容易に把握することができない。
【0013】
上記の特許文献１では、順序付けサービスがピア（peer）の性能指標を監視し、性能指標に基づきエンドースメント要求をピアに割り当てる。しかし、同文献には、コンソーシアム型の分散台帳システムの運用で生じる上記の課題を解決するための仕組みは記載されていない。また、性能指標の監視は単一の組織が行うため、監視された結果を信頼性のある証拠として利用することはできない。
【0014】
また、非特許文献３には、運用サービス（Operations Service）として、各ノードのヘルスチェック（Health Checks）やメトリック（Metrics）を取得することにより各ノードの状態を監視することが記載されている。また、同文献には、ゲートウェイ（Gateway）が、利用可能なノードを発見する仕組み（Service Discovery）が記載されている。しかし、同文献に記載されている仕組みは、組織の夫々が自身の所有するもしくは利用可能なノードを監視することを想定しており、参加組織の全体を監視するものではない。また、単一の組織（単一信頼点）が監視する仕組みであるため、監視の結果を信頼性のある証拠として利用することはできない。
【0015】
本発明は、こうした背景に鑑みてなされたものであり、客観性のある情報に基づき、分散台帳システム全体としての健全性を監視することが可能な、分散台帳システム及び分散台帳システムの制御方法を提供することを目的とする。
【課題を解決するための手段】
【0016】
上記課題を解決するための本発明の一つは、複数の組織の夫々により提供される分散台帳ノードを含み、前記複数の分散台帳ノードにより構成される分散台帳ネットワークを提供する、分散台帳システムであって、外部から受信したトランザクションに応じてスマートコントラクトを実行し、前記スマートコントラクトは、複数の前記組織の前記分散台帳ノードの間で合意形成を行いつつ分散台帳に情報を管理し、第１の前記組織が第２の前記組織の前記分散台帳ノードの健全性を監視することにより取得した情報である健全性監視結果を受信し、受信した前記健全性監視結果を検証することにより前記第２の組織の前記分散台帳ノードの健全性を検証し、健全性を検証した結果である健全性検証結果を前記分散台帳に記録する。
【0017】
その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。
【発明の効果】
【0018】
本発明によれば、客観性のある情報に基づき、分散台帳システム全体としての健全性を監視することができる。
【図面の簡単な説明】
【0019】
【図1】分散台帳システムの概略的な構成を示す図である。
【図2A】ブロックチェーン（ＢＣ）の一例である。
【図3】ステート情報の一例である。
【図4A】構成情報（組織情報）の一例である。
【図4B】構成情報（ＳＣ合意条件情報）の一例である。
【図5】健全性管理ＳＣ、ステート情報、及びＳＣイベントを説明するブロック図である。
【図6A】ステート情報（健全性監視方法定義）の一例である。
【図6B】ステート情報（健全性監視結果）の一例である。
【図6C】ステート情報（健全性検証結果）の一例である。
【図6D】ステート情報（構成設計情報）の一例である。
【図6E】ステート情報（構成準拠状況）の一例である。
【図6F】ステート情報（キャパシティ情報）の一例である。
【図6G】ステート情報（組織信頼度）の一例である。
【図6H】ステート情報（監視担当組織）の一例である。
【図7】メンバー登録処理を説明するフローチャートである。
【図8】ＳＣデプロイ／実行処理を説明するフローチャートである。
【図9】健全性報告処理を説明するフローチャートである。
【図10】健全性相互検証処理を説明するフローチャートである。
【図11】構成準拠状況検証処理を説明するフローチャートである。
【図12】信頼度算出処理を説明するフローチャートである。
【図13】監視担当組織選出処理を説明するフローチャートである。
【図14】監視結果表示ユーザインタフェースの一例である。
【図15】分散台帳システムの実現に用いる情報処理装置の一例である。
【発明を実施するための形態】
【0020】
以下、図面を参照しつつ本発明の実施形態について説明する。尚、以下の実施形態は、本発明を説明するための例示に過ぎず、説明の明確化のため、適宜、省略及び簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。とくに限定しない限り、各構成要素は単数でも複数でも構わない。
【0021】
以下では、各種情報の例として、「情報」、「データ」等の表現により説明することがあるが、各種情報はこれら以外のデータ構造（「テーブル」、「表」等）で表現してもよい。以下の説明において、識別情報について説明する際に、「識別子」、「ＩＤ」、「識別情報」等の表現を用いることがあるが、これらについては互いに置換することができる。以下の説明において、符号の前に付した「Ｓ」の文字は処理ステップの意味である。
【0022】
また、以下の説明において、分散台帳のことを「ブロックチェーン」又は「ＢＣ」とも称する。また、分散台帳を用いて利用者間で直接取引を行えるようにする技術のことを、以下、「分散台帳技術」と称する。また、分散台帳技術を利用するための基盤となる、通信ネットワークを介して通信可能に接続する複数の情報処理装置（以下、「分散台帳ノード」又は「コンソーシアム」と称する。）を用いて構成されるＰ２Ｐ（Peer to Peer）ネットワークのことを、以下、「分散台帳ネットワーク」と称する。また、分散台帳技術により提供されるスマートコントラクト（Smart Contract）のことを、以下、「ＳＣ」とも称する。また、スマートコントラクト（ＳＣ）に対して発行されるトランザクション（Transaction）のことを「ＴＸ」とも称する。
【0023】
また、本実施形態において、「健全性」は、例えば、以下の指標により判断するものとする。
（１）各ノードの死活状況（各組織からのノードの利用可能性、ネットワーク的な到達可能性、サービスの提供が可能な状態（Ready）になっているか否か等）
（２）設計した構成からの乖離（ノード数の過不足、仕様の過不足等）
（３）満たすべき性能や可用性の充足状況（外形監視（Synthetic Monitoring）の性能値が一定水準を満たすか等）
（４）設定値の正しさ（提供する機能有効/無効フラグの設定状況、ソフトウェアのバージョン等）
（１）各ノードの死活状況（各組織からのノードの利用可能性、ネットワーク的な到達可能性、サービスの提供が可能な状態（Ready）になっているか否か等）
（２）設計した構成からの乖離（ノード数の過不足、仕様の過不足等）
（３）満たすべき性能や可用性の充足状況（外形監視（Synthetic Monitoring）の性能値が一定水準を満たすか等）
（４）設定値の正しさ（提供する機能有効/無効フラグの設定状況、ソフトウェアのバージョン等）
【0024】
［第１実施形態］
図１に、第１実施形態として示す情報処理システムである分散台帳システム１の概略的な構成を示している。分散台帳システム１は、１つ以上の分散台帳ノード３と一つ以上のクライアントノード４とを含む。分散台帳ノード３及びクライアントノード４は、いずれも情報処理装置（コンピュータ）を用いて構成される。これらは通信ネットワーク５を介して互いに双方向の通信が可能な状態で接続されている。通信ネットワーク５は、ネットワーク機器を用いて構成される無線又は有線方式の通信基盤であり、例えば、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、各種公衆通信網、専用線等である。
図１に、第１実施形態として示す情報処理システムである分散台帳システム１の概略的な構成を示している。分散台帳システム１は、１つ以上の分散台帳ノード３と一つ以上のクライアントノード４とを含む。分散台帳ノード３及びクライアントノード４は、いずれも情報処理装置（コンピュータ）を用いて構成される。これらは通信ネットワーク５を介して互いに双方向の通信が可能な状態で接続されている。通信ネットワーク５は、ネットワーク機器を用いて構成される無線又は有線方式の通信基盤であり、例えば、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、各種公衆通信網、専用線等である。
【0025】
分散台帳システム１は、複数の分散台帳ノード３により構成されるコンソーシアム型の分散台帳ネットワークを含む。分散台帳ネットワークを利用する組織（以下、「参加組織」と称する）の夫々は、一つ以上の分散台帳ノード３と一つ以上のクライアントノード４を有する。コンソーシアム型の分散台帳ネットワーク（コンソーシアム）であるため、原則として各組織が夫々の分散台帳ノード３の運用を行う。尚、参加組織が有する分散台帳ノード３及びクライアントノード４は、参加組織が直接利用することが可能な状態（操作や管理が可能な状態）になっていればよく、必ずしも参加組織が所有していなくてもよい。
【0026】
同図に示すように、分散台帳ノード３は、記憶部３００、トランザクション管理部（以下、「ＴＸ管理部３２０」と称する。）、コンセンサス管理部３２５、スマートコントラクト実行管理部（以下、「ＳＣ実行管理部３３０」と称する）、承認済ＴＸ配信部３３５、トランザクション発行部（以下、「ＴＸ発行部３４０」と称する。）、ノード探索部３４５、メンバー管理部３５０、及び通信部３５５の各機能を有する。
【0027】
上記機能のうち、記憶部３００は、分散台帳３１０、コンソーシアム情報３０２、及び参加メンバー管理情報３０３の各情報（データ）を記憶（格納）する。
【0028】
分散台帳３１０は、ブロックチェーン（ＢＣ）（以下、「ＢＣ３１１」と称する。）、ステート情報３１２、組織の業務に関する処理を実現するスマートコントラクト（ＳＣ）である業務ＳＣ３１３、及び分散台帳システム１の健全性の管理に関する処理を行うスマートコントラクト（ＳＣ）である健全性管理ＳＣ３１４を含む。
【0029】
ＢＣ３１１には、例えば、トランザクション（ＴＸ）の履歴（受信履歴、実行履歴）が管理される。また、ステート情報３１２には、例えば、トランザクション（ＴＸ）の履歴に基づく情報やスマートコントラクト（ＳＣ）の実行に必要な情報（以下、「ステート情報」と称する。）が管理される。ステート情報３１２は、例えば、ＮＯＳＱＬのようなＤＢＭＳ（Data Base Management System）により管理されるデータベースのテーブルに管理される。ステート情報３１２は、例えば、Ｋｅｙ－Ｖａｌｕｅ形式で管理される、トランザクション（ＴＸ）の実行結果に基づく情報を含む。
【0030】
コンソーシアム情報３０２は、分散台帳ネットワークを構成する組織の情報、組織の間（分散台帳ノード３の間）で取り決められた各種の合意条件（トランザクション（ＴＸ）を受け入れてよいか等を決めるための条件（後述するＳＣ合意条件）等）に関する情報等を含む。ＳＣ合意条件は、分散台帳３１０のブロックチェーン（ＢＣ）（ＢＣ３１１）としても記録される。コンソーシアム情報３０２は、各組織の分散台帳ノード３の間で共有される。
【0031】
参加メンバー管理情報３０３は、参加組織のメンバー（ノード、管理者、ユーザ等を含む）に関する情報（識別情報、認証情報、各種属性情報等）を含む。
【0032】
ＴＸ管理部３２０は、クライアントノード４や他の分散台帳ノード３から送られてくるトランザクション（ＴＸ）を受信する。また、ＴＸ管理部３２０は、トランザクション（ＴＸ）の履歴（受信履歴、実行履歴）や実行結果の取得、トランザクション（ＴＸ）の実行結果の提示（ユーザインタフェースを介した提示等）等に関する処理を行う。また、ＴＸ管理部３２０は、トランザクション（ＴＸ）を受信した際、メンバー管理部３５０と連携し、トランザクション（ＴＸ）の発行元（クライアントノード、メンバー等）の認証に関する処理を行う。
【0033】
コンセンサス管理部３２５は、他の分散台帳ノード３との間での、クライアントノード４又は分散台帳ノード３から受信したトランザクション（ＴＸ）を受け入れてよいかの合意形成に関する処理を行う。合意が成立すると、コンセンサス管理部３２５は、ＳＣ実行管理部３３０と連携し、スマートコントラクト（ＳＣ）のデプロイ、デプロイ済みのスマートコントラクト（ＳＣ）の実行、トランザクション（ＴＸ）の履歴や実行結果の分散台帳３１０への記録等を行う。
【0034】
ＳＣ実行管理部３３０は、他の分散台帳ノード３との間で合意が成立した場合に、スマートコントラクト（ＳＣ）のデプロイやデプロイ済みのスマートコントラクト（ＳＣ）の実行に関する処理を行う。尚、合意形成やスマートコントラクト（ＳＣ）の実行は、必ずしも分散台帳ネットワークを構成する全ての分散台帳ノード３が行う必要はなく、一部の分散台帳ノード３の間で合意形成やスマートコントラクト（ＳＣ）の実行を行い、承認済ＴＸ配信部３３５と連携して結果を通信ネットワーク５を介して他の分散台帳ノード３に配信するようにしてもよい（その場合の取り決めは、合意形成のアルゴリズムに依存する）。
【0035】
承認済ＴＸ配信部３３５は、上記の合意形成やスマートコントラクト（ＳＣ）の実行に参加していない分散台帳ノード３に対し、上記の合意形成やスマートコントラクト（ＳＣ）の実行の結果（トランザクション（ＴＸ）の履歴や実行結果等）を通信ネットワーク５を介して配信する。
【0036】
ＴＸ発行部３４０は、分散台帳ノード３（自身を含む）に対してトランザクション（ＴＸ）を発行する。尚、このように本実施形態では、クライアントノード４だけでなく分散台帳ノード３も分散台帳ノード３に対してトランザクション（ＴＸ）を発行できるものとする。
【0037】
ノード探索部３４５は、クライアントノード４等の他の情報処理装置から送られてくる要求に応じて通信ネットワーク５を探索し、分散台帳システム１を構成している各分散台帳ノード３の状態や、各分散台帳ノード３の分散台帳ネットワークへの参加の状況に基づき、分散台帳システム１において現在利用可能な分散台帳ノード３を探索する。尚、上記の探索は、例えば、サービスディスカバリ（Service Discovery）（非特許文献３におけるGateway機能等）の仕組みにより行う。また、ノード探索部３４５は、探索した結果に基づき、トランザクション（ＴＸ）を送信する分散台帳ノード３や合意形成に用いる分散台帳ノード３を選出する。
【0038】
メンバー管理部３５０は、分散台帳ネットワークに参加する組織やメンバーの登録に関する処理を行う。また、メンバー管理部３５０は、参加組織やメンバーの認証処理を行う。メンバー管理部３５０は、例えば、公開鍵暗号方式における秘密鍵と公開鍵のペア（以下、「鍵ペア」と称する）を用いた参加組織やメンバーの認証、トランザクション（ＴＸ）への署名、スマートコントラクト（ＳＣ）の実行権限の制御を行う。参加する組織やメンバーの情報は、参加メンバー管理情報３０３に管理される。
【0039】
通信部３５５は、通信ネットワーク５を介して、クライアントノード４や他の分散台帳ノード３との間の通信に関する処理を行う。例えば、通信部３５５は、他の分散台帳ノード３の間での合意形成や、承認済のトランザクション（ＴＸ）の他の分散台帳ノード３への配信等に関する通信を行う。
【0040】
同図に示すように、クライアントノード４は、記憶部４００、ＴＸ発行部４２０、ノード探索部４２５、業務アプリ４３０、及び監視エージェント４３５の各機能を有する。
【0041】
記憶部４００は、ノード探索情報４０１を記憶する。ノード探索情報４０１は、ノード探索部４２５により探索された、分散台帳システム１において現在利用可能な分散台帳ノード３を示す情報を含む。
【0042】
ＴＸ発行部４２０は、トランザクション（ＴＸ）を分散台帳ノード３に送信（発行）する。ＴＸ発行部４２０は、例えば、組織のメンバーの操作入力に応じて上記のトランザクションを生成し、分散台帳ノード３に送信する。トランザクション（ＴＸ）には、当該トランザクション（ＴＸ）の発行元（組織、メンバー、クライアントノード４）の情報（識別情報、認証情報等）が付帯する。
【0043】
ノード探索部４２５は、分散台帳ノード３のノード探索部３４５と同様に、通信ネットワーク５を探索し、各分散台帳ノード３の状態や各分散台帳ノード３の分散台帳ネットワークへの参加状況に基づき、分散台帳システム１において現在利用可能な分散台帳ノード３を探索する。また、ノード探索部４２５は、探索した結果に基づき、トランザクション（ＴＸ）の送信先となる分散台帳ノード３や合意形成に用いる分散台帳ノード３を選出する。
【0044】
業務アプリ４３０は、組織が行う業務を遂行又は支援するアプリケーションソフトソフトウェア（プログラムやデータ）により実現される機能である。業務アプリ４３０は、例えば、業務に関する機能の提供に際し、ＴＸ発行部４２０と連携して業務ＳＣ３１３に関するトランザクション（ＴＸ）を分散台帳ノード３に送信（発行）する。
【0045】
監視エージェント４３５は、他の組織の分散台帳ノード３の健全性の監視に関する処理を行う。監視エージェント４３５は、分散台帳ノード３のステート情報３１２に格納されている後述の監視方法（例えば、外形監視やノード探索部３４５により取得された情報に基づく監視方法等。健全性監視方法定義５５１の内容）に従い、他の組織の分散台帳ノード３の健全性を監視する。監視エージェント４３５は、ＴＸ発行部４２０と連携し、分散台帳ノード３の健全性管理ＳＣ３１４に対して監視により取得した情報（他の組織の分散台帳ノード３の健全性を示す情報（以下、「健全性監視結果」とも称する。））を報告（通知）するためのトランザクション（ＴＸ）を生成し、生成したトランザクション（ＴＸ）を分散台帳ノード３に送信（発行）する。
【0046】
図２Ａ～図２Ｆは、図１に示した分散台帳３１０のブロックチェーン（ＢＣ）（ＢＣ３１１）の各ブロックのデータ構造の一例である。分散台帳技術では、複数のトランザクション（ＴＸ）が夫々ブロックとして管理され、ブロックチェーン（ＢＣ）（ＢＣ３１１）は、各ブロックが前のブロックのハッシュ値を持つように各ブロックを数珠繋ぎにした構造を有する。上記構造により、前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変化し、悪意者等による内容の改竄を困難にすることができる。
【0047】
尚、本実施形態では、１つのトランザクション（ＴＸ）と１つのブロックが一対一に対応している場合を例示するが、複数のトランザクション（ＴＸ）を１つのブロックに対応させるようにしてもよい。また、本例では、スマートコントラクト（ＴＸ）が単一のブロックチェーン（ＢＣ）として連なる構成であるが、参加組織の夫々が管理や参照することが可能であれば他の構成でもよい。また、本例では、複数のスマートコントラクト（ＴＸ）を個別に定義しているが、単一のスマートコントラクト（ＴＸ）に集約するようにしてもよい。
【0048】
【0049】
図２Ａに示すブロック３１１ａは、業務ＳＣ３１３のデプロイのためのトランザクション（ＴＸ）（以下、「デプロイＴＸ」と称する。）の情報を含む。尚、業務ＳＣ３１３は、例えば、商取引（企業等の組織間での仮想通貨の取引）におけるビジネスコントラクトに関する業務のスマートコントラクト（ＳＣ）である。
【0050】
同図に示すように、ブロック３１１ａのＴＸ情報２１は、タイムスタンプ２１１、ＳＣ＿ＩＤ２１２、ＴＸ種別２１３、ＳＣ実体２１４、ＳＣ入力仕様２１５、ＳＣメタ定義２１６、ＴＸ発行者２１７、ＴＸ実行／承認者２１８、承認済ＴＸ配信者２１９、及びＲＷセット２２０の各項目を含む。
【0051】
このうちタイムスタンプ２１１には、当該トランザクション（ＴＸ）が発行された日時（タイムスタンプ）が格納される。
【0052】
ＳＣ＿ＩＤ２１２には、スマートコントラクト（ＳＣ）の識別子（以下、「ＳＣ＿ＩＤ」と称する。）が格納される。
【0053】
ＴＸ種別２１３には、当該トランザクション（ＴＸ）の種別（「デプロイ」、「実行」、「参照」等）を示す情報（本例では「デプロイ」）が格納される。
【0054】
ＳＣ実体２１４には、スマートコントラクト（ＳＣ）の実体（例えば、実行可能なバイナリデータ（実行コード）等）が格納される。
【0055】
ＳＣ入力仕様２１５には、スマートコントラクト（ＳＣ）に含まれる関数名やその引数を利用者が把握するための情報が格納される。尚、例示するブロック３１１ａには、少なくとも以下の関数（以下、「ＳＣ関数」と称する。）を含む業務ＳＣ３１３が定義されている。
関数名：取引（）、入力引数：差出顧客ＩＤ, 差出顧客ＩＤ，送金額、戻り値：成否
関数名：全取引参照（）、入力引数：顧客ＩＤ、戻り値：指定顧客の全取引リスト
関数名：取引（）、入力引数：差出顧客ＩＤ, 差出顧客ＩＤ，送金額、戻り値：成否
関数名：全取引参照（）、入力引数：顧客ＩＤ、戻り値：指定顧客の全取引リスト
【0056】
ＳＣメタ定義２１６には、スマートコントラクト（ＳＣ）をデプロイした際に指定した入力引数に従って決定されるパラメータが格納される。上記のパラメータは、例えば、スマートコントラクト（ＳＣ）（当該業務ＳＣ）の実行時における合意条件（例えば、「参加組織の過半数以上の承認を持ってＴＸを受け入れる等」）、その他の各種定義情報等である。
【0057】
ＴＸ発行者２１７には、当該トランザクション（ＴＸ）の発行元の情報（例えば、発行者（クライアントノード４、分散台帳ノード３、管理者、ユーザ等）の識別子（以下、「メンバーＩＤ」と称する。）、電子署名に関する情報（発行元やデータの改竄有無の検証に用いる情報）等が格納される。尚、上記の電子署名は、メンバー管理部３５０が発行した各メンバーの秘密鍵を用いて行われ、上記秘密鍵の公開鍵（証明書）を用いて検証される。
【0058】
ＴＸ実行／承認者２１８には、ＴＸ発行者２１７と同様に、コンセンサス管理部３２５やＳＣ実行管理部３３０により行われる合意形成やスマートコントラクト（ＳＣ）の実行に関わった参加者（以下、「ＴＸ実行／承認者」と称する。）の情報が格納される。
【0059】
承認済ＴＸ配信者２１９には、承認済ＴＸ配信部３３５による配信処理に関わった参加者（以下、「承認済ＴＸ配信者」と称する。）の情報が格納される。
【0060】
ＲＷセット２２０には、当該トランザクション（ＴＸ）について行った処理に際して参照や更新を行った情報（以下、「ＲＷセット」（RW：Read-Write）と称する。）が格納される。尚、ＲＷセットは、後述のステート情報に相当する。ＲＷセット及びステート情報については後述する。
【0061】
【0062】
同図に示すように、例示するブロック３１１ｅのＴＸ情報は、タイムスタンプ２１１、ＳＣ＿ＩＤ２１２、ＴＸ種別２１３、呼び出し関数／入力引数２２１、ＴＸ発行者２１７、ＴＸ実行／承認者２１８、承認済ＴＸ配信者２１９、ＲＷセット２２０、及びＳＣイベント２２２の各項目を含む。尚、上記項目のうち、タイムスタンプ２１１、ＳＣ＿ＩＤ２１２、ＴＸ発行者２１７、ＴＸ実行／承認者２１８、承認済ＴＸ配信者２１９については図２Ａのブロック３１１ａと同様であるので説明を省略する。
【0063】
ＴＸ種別２１３には、当該実行ＴＸにより実行される処理が分散台帳３１０の更新処理を含む場合は「実行」が、当該実行ＴＸにより実行される処理が分散台帳３１０の更新処理を含まない参照処理である場合は「参照」が格納される。本例では、ＴＸ種別２１３に「実行」が格納されている。
【0064】
呼び出し関数／入力引数２２１には、スマートコントラクト（ＳＣ）により呼び出されるＳＣ関数とＳＣ関数に与える入力引数が格納される。本例では、呼び出し関数／入力引数２２１に、ＳＣ関数として「取引()」が、入力引数「顧客a, 顧客b, ＼1M」が格納されている。
【0065】
ＲＷセット２２０には、前述したように当該トランザクション（ＴＸ）について行った処理に際して参照や更新を行った情報（ＲＷセット、ステート情報）が格納される。本例では、ＲＷセット２２０に、スマートコントラクト（ＳＣ）のデプロイや実行に際して参照／更新された情報が格納されている。
【0066】
例示するブロック３１１ｅでは、ＲＷセット２２０に、ＲＷセットとして、ＳＣ＿ＩＤ２２０１、ＲＷ区分２２０２、Ｋｅｙ２２０３、Ｖａｌｕｅ２２０４、及びバージョン２２０５の各項目を有する一つ以上のレコードを有するテーブルが格納されている。
【0067】
上記項目のうちＳＣ＿ＩＤ２２０１には、スマートコントラクト（ＳＣ）の識別子（ＳＣ＿ＩＤ）が格納される。
【0068】
ＲＷ区分２２０２には、ＳＣ＿ＩＤ、参照（Read）か更新（Write）かを示す情報（以下、「ＲＷ区分」と称する。）が格納される。
【0069】
Ｋｅｙ２２０３、Ｖａｌｕｅ２２０４には、当該ＳＣ＿ＩＤで特定されるスマートコントラクト（ＳＣ）により参照や更新を行った情報が格納される。
【0070】
バージョン２２０５には、ＳＣ＿ＩＤとＫｅｙの組に対応する上記情報のバージョンを示す情報が格納される。上記バージョンは、例えば、上記情報が更新される度に１ずつ加算（インクリメント）される。
【0071】
同図の例では、スマートコントラクト（ＳＣ）のＳＣ関数である「登録（顧客ａ，顧客ｂ，￥１０Ｍ）」が実行され、Ｋｅｙ「顧客ａ」を参照してバージョン番号「４」のＶａｌｕｅ「￥１００Ｍ」を取得し（１行目）、Ｖａｌｕｅ「￥９０Ｍ」で更新した結果、バージョン番号が「５」に更新されたという情報がＲＷセットとして管理されている。
【0072】
このように、トランザクション（ＴＸ）の実行結果は、ＲＷセット（ステート情報）として管理される。このため、ＲＷセットを参照することで、スマートコントラクト（ＳＣ）を実行することなく、トランザクション（ＴＸ）の実行結果を直接取得することができる。このため、例えば、スマートコントラクト（ＳＣ）を実行しない分散台帳ノード３を含む複数の分散台帳ノード３の間でトランザクション（ＴＸ）の実行結果を効率よく共有することができる。
【0073】
同図に示すＳＣイベント２２２は、分散台帳ノード３が生成するイベントに関する情報（以下、「イベント情報」と称する。）が格納される。分散台帳ノード３のＴＸ管理部３２０は、分散台帳３１０のＢＣ３１１にトランザクション（ＴＸ）の履歴を追加する際等のタイミングでイベント情報を生成し、生成したイベント情報をＳＣイベント２２２に格納する。
【0074】
クライアントノード４や分散台帳システム１に参加している分散台帳ノード３は、通信ネットワーク５を介してＢＣ３１１のＳＣイベント２２２に格納されているイベント情報を参照することができる（即ち、ＳＣイベント２２２を介して、各分散台帳ノード３の間及び各分散台帳ノード３と各クライアントノード４の間でイベント情報を共有することができる。また、分散台帳ノード３やクライアントノード４は、イベント情報に従って各種の処理を実行することができる。
【0075】
以上、業務ＳＣ３１３のデプロイＴＸのブロック（図２Ａに示すブロック３１１ａ）及び業務ＳＣ３１３の実行ＴＸのブロック（図２Ｅに示すブロック３１１ｅ）について説明したが、健全性管理ＳＣ３１４のデプロイＴＸのブロック（図２Ｂに示すブロック３１１ｂ）及び健全性管理ＳＣ３１４の実行ＴＸのブロック（図２Ｆに示すブロック３１１ｆ）についても同様の構成を有する。尚、このように、業務ＳＣ３１３と健全性管理ＳＣ３１４のブロックは共通しており、両者を処理するための分散台帳ノード３の機能を共通化することができる。このため、本実施形態の仕組みは効率よく実現することが可能である。
【0076】
図３は、図１に示した分散台帳３１０のステート情報３１２のデータ構造である。ブロックチェーン（ＢＣ）による情報管理の仕組みでは、ブロックチェーン（ＢＣ）に管理される情報の最新の状態（例えば、ブロックチェーン（ＢＣ）に仮想通貨を管理している場合における仮想通貨の最新の残高)を取得するためにブロックチェーン（ＢＣ）を順に辿る必要があるため非効率である。そこで、本実施形態では、前述したＲＷセットの内容を全て反映することにより得られる、ブロックチェーン（ＢＣ）に管理される情報の最新の状態をステート情報３１２として管理する仕組み（例えば、非特許文献３に開示されている仕組み）を採用する。尚、本実施形態では、ＳＣ実行管理部３３０は、ＳＣ＿ＩＤをキーとしてスマートコントラクト（ＳＣ）の実体を取得してスマートコントラクト（ＳＣ）を実行するものとし、ステート情報３１２は、スマートコントラクト（ＳＣ）毎に管理される（データ格納領域が用意される）ものとする。
【0077】
同図に示すように、例示するステート情報３１２は、ＳＣ＿ＩＤ３１２１、ＳＣ実体３１２２、及び内部テーブル３１２３の各項目を有する一つ以上のレコードを含む。
【0078】
ＳＣ＿ＩＤ３１２１には、スマートコントラクト（ＳＣ）のＳＣ＿ＩＤが格納される。
【0079】
ＳＣ実体３１２２には、スマートコントラクト（ＳＣ）の実体（例えば、実行可能なバイナリデータ（実行コード）等）が格納される。これによりＳＣ実行管理部３３０は、ＳＣ＿ＩＤをキーとしてスマートコントラクト（ＳＣ）の実体を取得し実行することができる。
【0080】
内部テーブル３１２３には、スマートコントラクト（ＳＣ）の実行結果等のＳＣの実行に際して用いる情報が管理される。内部テーブル３１２３の内容はトランザクション（ＴＸ）が実行される度に更新される。本例では、内部テーブル３１２３に図２Ｅや図２Ｆに示したＲＷセット２２０に格納されているＲＷセットの最新の値が管理される。
【0081】
尚、同図の例では、内部テーブル３１２３にＫｅｙ－ｖａｌｕｅ形式で情報を格納しているが、ＶａｌｕｅについてはＪＳＯＮ（JavaScript Object Notation）（「Ｊａｖａ」、「Ｊａｖａｓｃｒｉｐｔ」はいずれも登録商標) 形式等の他の形式で内部テーブル３１２３に格納するようにしてもよい。それにより、例えば、任意のデータスキーマのテーブルとして内部テーブル３１２３に情報を格納するようにしてもよい。また、Ｋｅｙの設計を工夫することで、内部テーブル３１２３にスキーマの異なる複数の情報を仮想的に管理することもできる。
【0082】
【0083】
同図に示すように、例示する組織情報３０２ａは、業務ＩＤ３０２１、組織ＩＤ３０２２、メンバーＩＤ３０２３等の項目を有する複数のレコードで構成される。
【0084】
上記項目のうち、業務ＩＤ３０２１には、分散台帳ネットワークを用いて行われる業務の識別子である業務ＩＤ（「業務Ａ」、「業務Ｂ」等）が格納される。
【0085】
組織ＩＤ３０２２には、参加組織の識別子である組織ＩＤ（「組織１」、「組織２」、「組織３」、「組織４」等）が格納される。
【0086】
メンバーＩＤ３０２３には、参加組織のメンバーのメンバーＩＤ（「分散台帳ノード１１」、「クライアントノード１１」、「管理者１１」、「ユーザ１１」等）が格納される。
【0087】
図４Ｂは、図１に示したコンソーシアム情報３０２の他の一例（以下、「ＳＣ合意条件情報３０２ｂ」と称する。）である。ＳＣ合意条件情報３０２ｂは、業務毎（業務ＩＤ毎）に設定された、スマートコントラクト（ＳＣ）について合意が成立する（スマートコントラクト（ＳＣ）の実行結果を受け入れる）ための条件（以下、「ＳＣ合意条件」と称する。）に関する情報を含む。
【0088】
同図に示すように、例示するＳＣ合意条件情報３０２ｂは、業務ＩＤ３０２５及びＳＣ合意条件Ｄ３０２６等の項目を有する一つ以上のレコードで構成される。
【0089】
上記項目のうち、業務ＩＤ３０２５には、前述した業務ＩＤが格納される。
【0090】
ＳＣ合意条件Ｄ３０２６には、当該業務について設定されたＳＣ合意条件が格納される。尚、ＳＣ合意条件は、ＢＣ３１１の内容（図２ＡのＳＣメタ定義２１６に格納されているＳＣ合意条件）に基づき決定される。
【0091】
同図の例では、業務ＩＤが「業務Ａ」のレコードは、当該業務について「合意形成に至る（合意が成立する）ためには参加組織の多数決が必要」というＳＣ合意条件が設定されていることを示す。
【0092】
また、同図の例では、業務ＩＤが「業務Ｂ」のレコードは、当該業務について「障害が発生している分散台帳ノード３の数をｆとした場合に、合意形成に至る（合意が成立する）ためには参加組織の２ｆ＋１以上の合意が必要（例えば、ｆが１であれば、合意が成立するためには３組織以上の合意が必要」というＳＣ合意条件が設定されていることを示す。
【0093】
【0094】
同図に示すように、健全性管理ＳＣ３１４は、ＳＣ関数（健全性報告５１１、健全性相互検証５１２、構成準拠状況検証５１３、アクション指示５１４、組織信頼度算出５１５、監視担当組織選出５１６、及び各種データ参照５１７）を含む。ＳＣ関数は、実行に際し、ステート情報３１２やＢＣ３１１のＳＣイベント２２２に適宜アクセス（更新又は参照）する。
【0095】
同図に示すように、例示するステート情報３１２は、健全性監視方法定義５５１、健全性監視結果５５２、健全性検証結果５５３、構成設計情報５５４、構成準拠状況５５５、キャパシティ情報５５６、組織信頼度５５７、及び監視担当組織５５８を含む。また、例示するＳＣイベント２２２は、アクションイベント５８１を含む。
【0096】
ステート情報３１２のうち、健全性監視方法定義５５１は、各組織が他の組織の構成（分散台帳ノード３、クライアントノード４）の健全性を監視する際に用いるべき共通の監視方法や監視手段を規定（定義）した情報（以下、「健全性監視方法」と称する。）を含む。
【0097】
健全性監視結果５５２は、各組織のクライアントノード４が夫々、他の組織の構成（分散台帳ノード３、クライアントノード４）の健全性を監視した結果（以下、「健全性監視結果」と称する。）に関する情報を含む。
【0098】
健全性検証結果５５３は、各組織から相互に報告された健全性監視結果を検証することにより、各分散台帳ノード３の健全性（分散台帳ノード３の生死等）を判定した結果（以下、「健全性検証結果」と称する。）を示す情報を含む。
【0099】
構成設計情報５５４は、コンソーシアム全体の観点に基づく、個々の組織が準備し提供すべき構成についての情報（以下、「構成設計情報」と称する。）を含む。構成設計情報５５４は、コンソーシアム全体の観点からトップダウン的に設定されたものでもよいし、個々の組織の要望や提案に基づきボトムアップ的に設定されたものでもよい。尚、後述するように、構成設計情報５５４の内容は、アクションイベント５８１に基づき自動的に修正されることがある。
【0100】
構成準拠状況５５５は、健全性検証結果５５３と構成設計情報５５４を比較対照することにより導出される、各組織の構成が構成設計情報への準拠の度合いを示す情報（以下、「構成準拠状況」と称する。）を示す情報を含む。
【0101】
キャパシティ情報５５６は、各組織が提供可能なリソースの範囲や上限を示す情報（以下、「キャパシティ情報」と称する。）を含む。
【0102】
組織信頼度５５７は、各組織が他の組織の構成（分散台帳ノード３、クライアントノード４）を監視する場合における、各組織の信頼度を示す情報（以下、「組織信頼度」と称する。）を含む。
【0103】
監視担当組織５５８は、健全性の監視を担当する組織（以下、「監視担当組織」と称する。）を示す情報を含む。
【0104】
尚、キャパシティ情報５５６及び監視担当組織５５８の詳細については、後述の第２実施形態で説明する。
【0105】
ＳＣイベント２２２のアクションイベント５８１は、構成準拠状況が予め設定された基準（構成設計情報）に達していない場合に健全性管理ＳＣ３１４によって生成されるイベント（以下、「アクションイベント」とも称する。）の情報を含む。クライアントノード４の監視エージェント４３５は、通信ネットワーク５を介してＢＣ３１１のＳＣイベント２２２であるアクションイベント５８１を随時参照し、アクションイベント５８１に自身に対する指示が含まれていることを確認すると、アクションイベント５８１の内容に応じた処理（構成準拠情報が基準（構成設計情報）を満たすように組織に分散台帳ノード３の保守や増設を促す情報を出力する処理等）を実行する。
【0106】
健全性管理ＳＣ３１４のＳＣ関数である健全性報告５１１は、クライアントノード４から送られてくる健全性監視結果を報告するためのトランザクション（ＴＸ）を受信し、受信したトランザクション（ＴＸ）を実行することにより健全性監視結果をステート情報３１２に健全性監視結果５５２として記録する。
【0107】
上記のＳＣ関数である健全性相互検証５１２は、各組織から通知された健全性監視結果を検証し、検証した結果をステート情報３１２に健全性検証結果５５３として記録する。
【0108】
上記のＳＣ関数である構成準拠状況検証５１３は、健全性検証結果と構成設計情報とを比較対照することにより各組織の構成準拠状況を検証し、検証した結果をステート情報３１２に構成準拠状況５５５として記録する。
【0109】
上記のＳＣ関数であるアクション指示５１４は、構成準拠状況５５５を参照することにより健全性が不十分な組織を特定し、特定した組織（のクライアントノード４）を対象とするアクションイベントを生成し、生成したアクションイベントをアクションイベント５８１としてＳＣイベント２２２に格納する。
【0110】
上記のＳＣ関数である組織信頼度算出５１５は、健全性の監視に関わる各組織の組織信頼度を求め、求めた組織信頼度をステート情報３１２に組織信頼度５５７として記録する。尚、組織信頼度算出５１５の詳細については第２実施形態で説明する。
【0111】
上記のＳＣ関数である監視担当組織選出５１６は、健全性の監視を担当する組織を選出する。尚、監視担当組織選出５１６の詳細については第２実施形態で説明する。
【0112】
上記のＳＣ関数である各種データ参照５１７は、分散台帳３１０、コンソーシアム情報３０２、参加メンバー管理情報３０３等の情報源にアクセスして各種のデータを取得又は参照する関数（例えば、クエリ関数）である。
【0113】
尚、以上に示したＳＣ関数は、夫々を独立した関数として実装してもよいし、全部又は一部を統合した単一のＳＣ関数として実装してもよい。
【0114】
続いて、図５に示した各種の情報（データ）について説明する。
【0115】
図６Ａは、図５に示した健全性監視方法定義５５１の一例である。同図に示すように、例示する健全性監視方法定義５５１は、監視方法ＩＤ５５１１、監視方法５５１２、監視頻度５５１３、判定可能基準５５１４、判定方法５５１５等の項目を有する一つ以上のレコードで構成される。
【0116】
上記項目のうち、監視方法ＩＤ５５１１には、監視方法の識別子である監視方法ＩＤが格納される。
【0117】
監視方法５５１２には、健全性の監視に用いる監視方法を示す情報が格納される。
【0118】
監視頻度５５１３には、健全性の監視を実行する頻度を示す情報が格納される。
【0119】
判定可能基準５５１４には、分散台帳ノード３の健全性を決定するための基準を示す情報を示す情報（ＳＣ合意条件）が格納される。
【0120】
判定方法５５１５には、複数の組織による健全性監視結果に基づき分散台帳ノード３の健全性を決定する際の判定方法を示す情報が格納される。
【0121】
例えば、同図に示す健全性監視方法定義５５１の監視方法ＩＤが「監視方法０１」のレコードは、「サービスディスカバリＡＰＩ」を利用した監視方法（各組織のクライアントノード４がノード探索部３４５によりノード探索情報４０１を取得した結果に基づき健全性を監視する方法）を「６０秒」の監視頻度で実施することが定義されている。また、同レコードには、「ＳＣ合意条件」を満たす場合に健全性の監視結果の受け入れ（決定）が可能であり、複数の組織から集まった健全性監視結果の「多数決」により各ノードの生死を決定することが定義されている。
【0122】
また、同図に示す健全性監視方法定義５５１の監視方法ＩＤが「監視方法０２」のレコードは、各組織のクライアントノード４から各分散台帳ノード３の「外形監視によるＴＸ実行時間」を「６０秒」の監視頻度で監視することが定義されている。また、同レコードには、同レコードには、「ＳＣ合意条件」を満たす場合に健全性の監視結果の受け入れ（決定）が可能であり、集まった報告による実行時間の平均値が「３秒未満」であれば分散台帳ノード３は「正常」と判定することが定義されている。
【0123】
尚、例示する健全性監視方法定義５５１の例では、各項目の内容をテキスト形式で記載しているが、各項目の内容は、例えば、ＪＳＯＮ（JavaScript Object Notation）（「Ｊａｖａ」、「Ｊａｖａｓｃｒｉｐｔ」はいずれも登録商標)等の形式で記載してもよい。また、より複雑な処理を効率よく表現するため、例えば、プログラミング言語やＤＳＬ（Domain Specific Language）に従って各項目の内容を記述してもよい。
【0124】
図６Ｂは、図５に示した健全性監視結果５５２の一例である。同図に示すように、例示する健全性監視結果５５２は、監視組織ＩＤ５５２１、監視対象５５２２、監視結果５５２３、監視日時５５２４、タイムスパン５５２５等の項目を有する一つ以上のレコードで構成される。
【0125】
上記項目のうち、監視組織ＩＤ５５２１には、他の組織の分散台帳ノード３の監視を行ってその結果を報告してきた組織の組織ＩＤ（以下、「監視組織ＩＤ」とも称する。）が格納される。尚、監視組織ＩＤ５５２１に、組織が所有するクライアントノード４の識別子（以下、「クライアントノードＩＤ」と称する。）を格納してもよい。
【0126】
監視対象５５２２は、組織ＩＤ５５２２１及び分散台帳ノードＩＤ５５２２２を小項目として含む。組織ＩＤ５５２２１には、当該監視において監視対象となった組織の組織ＩＤ（以下、「監視対象組織ＩＤ」とも称する。）が格納される。また、分散台帳ノードＩＤ５５２２２には、当該監視において監視対象となった分散台帳ノード３の識別子（以下、「分散台帳ノードＩＤ」と称する。）が格納される。
【0127】
監視結果５５２３には、当該監視の結果を示す情報が格納される。本例では、監視の結果、監視対象の分散台帳ノード３の健全性が正常と判定された場合は「ＯＫ」が、健全性が異常と判定された場合は「ＮＧ」が格納される。
【0128】
監視日時５５２４には、当該レコードの監視結果についての報告が行われた日時を示す情報（タイムスタンプ）が格納される。クライアントノード４の監視エージェント４３５による他の組織の分散台帳ノード３の健全性の監視は、健全性監視方法定義５５１の監視頻度５５１３に従って繰り返し（定期的等）行われ、その結果が分散台帳ノード３に報告される。尚、上記日時には、組織の間で多少のばらつきが生じ得る。
【0129】
タイムスパン５５２５には、組織間の上記のばらつきを吸収する目的で用いる情報であるタイムスパンが格納される。タイムスパンは、例えば、健全性管理ＳＣや各組織の監視エージェント４３５により設定される。健全性相互検証５１２による検証は、タイムスパン毎の健全性監視結果を単位として行われる。例えば、同図に符号５５２ａで示すレコードは、「Ｓｐａｎ１－１」で特定されるタイムスパン内の日時「（略）：００：００１」に、「組織１」が「組織２」の「ノード１」の健全性の監視を行った結果が「ＯＫ」であったことを示している。
【0130】
【0131】
上記項目のうち、監視対象５５３１（組織ＩＤ５５３１１、分散台帳ノードＩＤ５５３１２）については、図６Ｂの監視対象５５２２と同様であるので説明を省略する。
【0132】
健全性検証結果履歴５５３２には、各組織から報告された健全性監視結果を検証して分散台帳ノード３の健全性（ＯＫ／ＮＧ）を検証した結果（健全性検証結果）が格納される。同図の例では、タイムスパン毎の健全性判定結果が時系列順に格納されている。例えば、一行目のレコード５５３ａには、「組織１」の「ノード２」の健全性検証結果が「Ｓｐａｎ１－１」及び「Ｓｐａｎ１－２」では「ＯＫ」、「Ｓｐａｎ１－３」では「ＮＧ」であることが（ＪＳＯＮ形式で）格納されている。
【0133】
図６Ｄは、構成設計情報５５４の一例である。構成設計情報５５４は、コンソーシアム全体として個々の組織が準備し提供すべき構成を示す情報を含む。同図に示すように、例示する構成設計情報５５４は、組織ＩＤ５５４１、準備ノード５５４２、仕様詳細５５４３等の項目を有する一つ以上のレコードで構成される。
【0134】
上記項目のうち、組織ＩＤ５５４１には、組織ＩＤが格納される。
【0135】
準備ノード５５４２には、組織がコンソーシアムのために準備し提供すべき分散台帳ノード３の数を示す情報が格納される。
【0136】
仕様詳細５５４３には、組織が準備し提供すべき分散台帳ノード３が満たすべき仕様（スペック）を示す情報が格納される。上記情報は、例えば、分散台帳ノード３のハードウェア仕様（プロセッサ、メモリ、ストレージ等の処理性能や容量等））を示す情報、ソフトウェア仕様（オペレーティングシステムやアプリケーションソフトウェア等のソフトウェアの種類やバージョン等）、分散台帳ノード３の機能（ＴＸ承認機能、承認済みＴＸ配信等）等を示す情報を含む。上記情報の内容は、例えば、コンソーシアムの運営方針に応じて決定される。尚、クライアントノード４による他の組織の分散台帳ノード３の健全性の監視において、上記情報への準拠状況を監視対象とするようにしてもよい。
【0137】
図６Ｅは、構成準拠状況５５５の一例である。構成準拠状況５５５は、図６Ｃの健全性検証結果５５３と図６Ｄの構成設計情報５５４とを比較対照することにより生成される、各組織の分散台帳ノード３の構成準拠状況を示す情報を含む。同図に示すように、例示する構成準拠状況５５５は、組織ＩＤ５５５１、準拠状況５５５２、構成準拠率５５５３、タイムスパン５５５４等の項目を有する一つ以上のレコードで構成される。
【0138】
上記項目のうち、組織ＩＤ５５５１には、組織ＩＤが格納される。
【0139】
準拠状況５５５２には、当該組織の構成準拠状況を示す情報が格納される
【0140】
構成準拠率５５５３には、当該組織の構成準拠率を示す情報が格納される。
【0141】
タイムスパン５５５４には、当該レコードの構成準拠状況を確認したタイムスパンを示す情報が格納される。尚、監視頻度毎に構成準拠状況の検証では粒度が細か過ぎる場合には、例えば、複数のタイムスパンを単位として構成準拠状況を確認するようにしてもよい。
【0142】
同図の場合、例えば、レコード５５５ａは、「組織１」の構成準拠状況がタイムスパン「Ｓｐａｎ１」では、構成準拠状況が「ＯＫ」であり、構成準拠率が「９９．９％」であることを示す。尚、タイムスパン「Ｓｐａｎ１」は、図６Ｃの健全性検証結果５５３における「Ｓｐａｎ１－ＸＸ」のデータを対象として集計したことを意味する。
【0143】
また、同図におけるレコード５５５ｂは、「組織１」の構成準拠状況がタイムスパン「Ｓｐａｎ１」では、構成準拠状況が「ＮＧ」であり、構成準拠率が「５０％」であることを示している。尚、同図に示すように、当該レコードの準拠状況５５５２には、本例で準拠状況が「ＮＧ」となった理由「１ノード不足」がＪＳＯＮ形式で格納されている。
【0144】
図６Ｆは、キャパシティ情報５５６の一例である。キャパシティ情報５５６は、各組織が提供可能なリソースの範囲や上限を示す情報を含む。同図に示すように、例示するキャパシティ情報５５６は、組織ＩＤ５５６１、準備可能ノード５５６２等の項目を有する一つ以上のレコードで構成される。
【0145】
上記項目のうち、組織ＩＤ５５６１には、組織ＩＤが格納される。
【0146】
準備可能ノード５５６２には、当該組織がコンソーシアムのために提供が可能なリソースの範囲や上限を示す情報が格納される。本例では、準備可能ノード５５６２に分散台帳ノード３の数を格納している。尚、準備可能ノード５５６２に、例えば、図６Ｄに示した仕様の情報を含めてもよい。
【0147】
図６Ｇは、組織信頼度５５７の一例である。組織信頼度５５７は、健全性監視に関わる各組織の信頼度を示す情報を含む。同図に示すように、例示する組織信頼度５５７は、組織ＩＤ５５７１、健全性報告内容信頼度５５７２、構成準拠信頼度５５７３等の項目を有する一つ以上のレコードで構成される。
【0148】
上記項目のうち、組織ＩＤ５５７１には、組織ＩＤが格納される。
【0149】
健全性報告内容信頼度５５７２には、当該組織から報告された健全性監視結果がどの程度信頼できるかを定量的に示した情報（以下、「健全性報告内容信頼度」とも称する。）が格納される。本例では、健全性報告内容信頼度５５７２に、他の組織の報告内容との一致度を百分率で表現した値を格納している。
【0150】
構成準拠信頼度５５７３には、当該組織が構成準拠という観点でどの程度信頼できるかを定量的に示した情報（以下、「構成準拠信頼度」とも称する。）が格納される。尚、図６Ｅに示した構成準拠率５５５３と同様に、構成準拠信頼度はタイムスパンを用いて把握してもよい。また、例えば、構成準拠率の過去の所定期間における累積値に基づき構成準拠信頼度を求めてもよい。
【0151】
図６Ｈは、監視担当組織５５８の一例である。監視担当組織５５８には、他の組織の分散台帳ノード３の健全性の監視を担当する組織を示す情報が格納される。同図に示すように、例示する監視担当組織５５８は、監視担当組織ＩＤ５５８１等の項目を有する複数のレコードで構成される。
【0152】
監視担当組織ＩＤ５５８１には、健全性監視報告を担当する組織の組織ＩＤのリストが格納される。同図における符号５５８ａで示すレコードは、「組織１」、「組織３」、「組織４」が健全性を監視し報告する組織であることを示している。
【0153】
図７は、分散台帳ネットワークに参加するメンバーの登録に際して分散台帳ノード３が行う処理（以下、「メンバー登録処理Ｓ７００」と称する。）を説明するフローチャートである。以下、同図とともにメンバー登録処理Ｓ７００について説明する。
【0154】
まず、メンバー管理部３５０が、クライアントノード４等からメンバーの登録要求（以下、「メンバー登録要求」と称する。）を受信する（Ｓ７１１）。メンバー登録要求には、登録の対象となるメンバー（以下、「対象メンバー」と称する。）が所属する組織の組織ＩＤや対象メンバーのメンバーＩＤを含む。
【0155】
続いて、メンバー管理部３５０は、メンバー登録要求に指定されている対象メンバーについて、秘密鍵と公開鍵の組（以下、秘密鍵と当該秘密鍵の公開鍵の組のことを「鍵ペア」と称する。）を生成し、生成した鍵ペアをメンバーＩＤと対応づける（Ｓ７１２）。
【0156】
続いて、メンバー管理部３５０は、対象メンバーの情報（組織ＩＤ、メンバーＩＤ等）と鍵ペアの公開鍵を他の分散台帳ノード３にブロードキャストする（Ｓ７１３）。ブロードキャストを受信した他の分散台帳ノード３は、受信した情報を参加メンバー管理情報３０３として管理する。
【0157】
続いて、メンバー管理部３５０は、Ｓ７１１でメンバー登録要求を送ってきた他の分散台帳ノード３に、Ｓ７１２で生成した鍵ペアの秘密鍵Ｄ３１を送信する（Ｓ７１４）。秘密鍵Ｄ３１を受信した他の分散台帳ノード３は、受信した秘密鍵Ｄ３１を自身の秘密鍵Ｄ３１として参加メンバー管理情報３０３に管理する。
【0158】
尚、以上では、メンバー管理部３５０が分散台帳ノード３の機能であるものとして説明したが、メンバー管理部３５０は、クライアントノード４やメンバー管理を行う専用のノード等の他のノードに実装するようにしてもよい。
【0159】
本実施形態では、Ｓ７１２で生成した鍵ペアを用い、分散台帳ネットワークに参加するメンバーの認証や各種トランザクション（ＴＸ）への署名、ＳＣ実行権限の制御等を行う。例えば、クライアントノード４が秘密鍵で電子署名したトランザクション（ＴＸ）、を発行し、これを検証する分散台帳ノード３が、秘密鍵に対応する公開鍵を用いて電子署名を検証することにより本人確認を行う。鍵ペアの生成方法や電子署名の検証方法、メンバーＩＤと鍵ペアを対応づける方法等は、例えば、公知技術や周知技術により行われる。
【0160】
図８は、分散台帳ノード３の分散台帳３１０へのスマートコントラクト（ＳＣ）のデプロイ又は実行に際して分散台帳ノード３が行う処理（以下、「ＳＣデプロイ／実行処理Ｓ８００」と称する。）を説明するフローチャートである。以下、同図とともにＳＣデプロイ／実行処理Ｓ８００について説明する。
【0161】
まず、ＴＸ管理部３２０が、クライアントノード４等の他のノードから、スマートコントラクト（ＳＣ）のデプロイ又は実行のためのトランザクション（ＴＸ）を受信する（Ｓ８１１）。
【0162】
続いて、分散台帳ノード３のコンセンサス管理部３２５が、受信したトランザクション（ＴＸ）が、デプロイＴＸ又は実行ＴＸのいずれであるかを判定する（Ｓ８１２）。受信したトランザクション（ＴＸ）がデプロイＴＸであれば（Ｓ８１２：デプロイＴＸ）、処理はＳ８２１に進む。受信したトランザクション（ＴＸ）が実行ＴＸであれば（Ｓ８１２：実行ＴＸ）、処理はＳ８３１に進む。
【0163】
Ｓ８２１では、コンセンサス管理部３２５は、他の分散台帳ノード３との間で、受信したデプロイＴＸの実行とＢＣ３１１への追加についての合意形成のための処理（以下、「合意形成処理」と称する。）を行う（Ｓ８２１）。尚、合意形成は、例えば、公知技術又は周知技術を用いて行われる。例えば、非特許文献３に開示されている「Endorser-Ordererモデル」により合意形成を行う場合は次の手順で合意形成が行われる。
【0164】
まず、コンセンサス管理部３２５は、分散台帳ネットワークに参加している分散台帳ノード３（自身を含む）の中から承認権限のある分散台帳ノード３を選出し、選出した分散台帳ノード３の夫々とデプロイＴＸを共有する。選出された分散台帳ノード３の夫々は、共有したデプロイＴＸが問題を有するか否かを検証（改竄の有無の検証、正当性の有無の検証等）する。
【0165】
コンセンサス管理部３２５は、選出された分散台帳ノード３の夫々から検証結果（「承認」又は「非承認」）を取得し、各分散台帳ノード３の検証結果を予め設定された合意条件（例えば、２組織以上の承認）と対照し、当該デプロイＴＸを受け入れるか否かを判定する。そして、コンセンサス管理部３２５は、判定した結果を分散台帳ネットワークに参加する全ての分散台帳ノード３に送信する。
【0166】
尚、このように「Endorser-Ordererモデル」による合意形成では、分散台帳ネットワークに参加する全ての分散台帳ノード３がトランザクション（ＴＸ）の検証を行う必要が無く、トランザクション（ＴＸ）を効率よく検証することができる。
【0167】
合意が成立すると、続いて、（当該分散台帳ノード３の）ＴＸ配信部３６が、分散台帳ネットワークに参加している全ての分散台帳ノード３にデプロイＴＸをブロードキャストする。そして、上記のデプロイＴＸを受信した分散台帳ノード３のＳＣ実行管理部３３０は、受信したデプロイＴＸを実行し、当該デプロイＴＸにかかるスマートコントラクト（ＳＣ）を分散台帳３１０にデプロイする（Ｓ８２２）。尚、デプロイは、デプロイＴＸの内容に基づきＳＣ＿ＩＤやスマートコントラクト（ＳＣ）の実体を分散台帳３１０上のステート情報として登録し、ブロックチェーン（ＢＣ）（ＢＣ３１１）の末尾に当該デプロイＴＸのブロックを追加することにより行われる。
【0168】
続いて、コンセンサス管理部３２５は、デプロイＴＸの実行結果を当該デプロイＴＸの送信元に送信する（Ｓ８２３）。
【0169】
一方、Ｓ８３１では、コンセンサス管理部３２５は、実行ＴＸについてＳ８２１と同様の合意形成処理を行う。合意が成立すると、続いて、承認済ＴＸ配信部３３５が、分散台帳ネットワークに参加している全ての分散台帳ノード３に実行ＴＸをブロードキャストする。上記実行ＴＸを受信した分散台帳ノード３のＳＣ実行管理部３３０は、実行ＴＸにより指定されるスマートコントラクト（ＳＣ）を実行する（Ｓ８３２）。尚、スマートコントラクト（ＳＣ）の実行は、実行ＴＸに指定されているスマートコントラクト（ＳＣ）に対し、実行ＴＸに指定されている呼び出し関数を指定し入力引数を与えることにより行われる。上記のスマートコントラクト（ＳＣ）が実行されることにより、分散台帳３１０の内容が更新され、ブロックチェーン（ＢＣ）（ＢＣ３１１）の末尾に当該実行ＴＸのブロックが追加される。
【0170】
続いて、当該分散台帳ノード３のコンセンサス管理部３２５は、実行ＴＸの実行結果を当該実行ＴＸの送信元に送信する（Ｓ８３３）。
【0171】
図９は、組織のクライアントノード４が他の組織の分散台帳ノード３の健全性の監視を行い、その結果を分散台帳ノード３に報告する際に分散台帳システム１にて行われる処理（以下、「健全性報告処理Ｓ９００」と称する。）を説明するフローチャートである。以下、同図とともに健全性報告処理Ｓ９００について説明する。尚、健全性報告処理Ｓ９００にて実行されるスマートコントラクト（ＳＣ）は、当該処理の実行前に各分散台帳ノード３にデプロイ済みであるものとする。
【0172】
クライアントノード４の監視エージェント４３５は、ステート情報３１２の健全性監視方法定義５５１で指定されている方法で他の組織の分散台帳ノード３の健全性監視を行う（Ｓ９１１）。
【0173】
例えば、監視エージェント４３５は、図６Ａに例示した健全性監視方法定義５５１の一つ（ここでは、監視方法ＩＤが「監視方法０１」のレコードの定義とする。）に従い、ノード探索部４２５と連携し、分散台帳ネットワークに存在する分散台帳ノード３の夫々が現在利用可能であるか否かを示す情報を取得し、取得した情報に基づき健全性を判定し、その結果を健全性の監視結果とする。
【0174】
続いて、クライアントノード４は、Ｓ９１１の健全性の監視結果を入力として、分散台帳ノード３に対し、健全性管理ＳＣ３１４のＳＣ関数「健全性報告５１１」を呼び出す（実行を指示する）実行ＴＸを送信（発行）する（Ｓ９１２）。
【0175】
分散台帳ノード３は、上記の健全性の監視結果及び実行ＴＸを受信すると、ＳＣ実行管理部３３０が、実行ＴＸに従い、受信した健全性の監視結果を入力としてＳＣ関数「健全性報告５１１」を実行する（Ｓ９２１）。
【0176】
ＳＣ関数「健全性報告５１１」の処理において、分散台帳ノード３は、まず、受信した実行ＴＸや当該実行ＴＸに付帯して受信した情報（当該実行ＴＸの送信者の組織の情報等）に基づき、当該組織が健全性の報告を行う権限を有しているか否かを確認する（Ｓ９２２）。そして、当該組織が上記の権限を有していることを確認すると、分散台帳ノード３は、クライアントノード４から受信した健全性の監視結果をステート情報３１２の健全性監視結果５５２に追加する（Ｓ９２３）。
【0177】
例えば、図６Ｂの健全性監視結果５５２の符号５５２ａ～５５２ｄで示す４つのレコードの情報は、「組織１」のクライアントノード４から送信された実行ＴＸにより健全性報告５１１が実行されて追加された情報である。これらのレコードには、タイムスパン「Ｓｐａｎ１－１」における健全性の監視結果として、他の組織である「組織２」と「組織３」の分散台帳ノード３の健全性の監視結果が格納されている。
【0178】
尚、各組織からの健全性の監視結果の報告は、例えば、報告を行った組織以外の他の組織が上書きすることができないようにアクセス制限を行ってもよい（例えば、非特許文献３の「ＡＢＡＣ， Ｓｔａｔｅエンドース」の方法でアクセス制限する等）。
【0179】
図１０は、クライアントノード４から分散台帳ノード３に図５の健全性管理ＳＣのＳＣ関数「健全性相互検証５１２」を呼び出す実行ＴＸが送信された際に分散台帳ノード３が行う処理（以下、「健全性相互検証処理Ｓ１０００」と称する。）を説明するフローチャートである。以下、同図とともに健全性相互検証処理Ｓ１０００について説明する。
【0180】
分散台帳ノード３は、上記の実行ＴＸを受信すると、ＳＣ実行管理部３３０が、健全性管理ＳＣのＳＣ関数「健全性相互検証５１２」を実行する（Ｓ１０１１）。
【0181】
ＳＣ関数「健全性相互検証５１２」の処理において、分散台帳ノード３は、検証対象期間（タイムスパン）のステート情報「健全性監視結果５５２」を参照し、当該検証対象期間における分散台帳ノード３の健全性を検証する（Ｓ１０１２）。
【0182】
尚、上記の検証対象期間は、例えば、実行ＴＸに付帯してクライアントノード４から受信した情報に基づくものでもよいし、また、現在の日時から自動的に決定するようにしてもよい。また、検証可能な全ての期間としてもよい。
【0183】
例えば、図６Ｂの健全性監視結果５５２では、タイムスパン５５２５が「Ｓｐａｎ１－１」のタイムスパンにおける組織２の「ノード１」の分散台帳ノード３は、「組織１」と「組織３」のいずれの監視結果についても監視結果５５２３に「ＯＫ」が格納されている。この場合、他の参加組織からの報告も「ＯＫ」であった場合は、判定可能基準５５１４「ＳＣ合意条件」（ここでは図４Ｂの業務ＩＤ３０２５が「業務Ａ」のＳＣ合意条件３０２６「参加組織の過半数以上の承認」とする。）を満し、判定方法５５１５「多数決」に従って健全性検証結果は「ＯＫ」となる。
【0184】
図１０に戻り、続くＳＣ関数「健全性相互検証５１２」の処理において、分散台帳ノード３は、健全性検証結果を、ステート情報３１２の「健全性検証結果５５３」に追加もしくは更新する（Ｓ１０１３）。例えば、健全性検証結果５５３が図６Ｂの内容である場合、図６Ｃの健全性検証結果５５３の「組織２」の「ノード１」のレコードに、健全性検証結果履歴５５３２として「Ｓｐａｎ１－１： ＯＫ」が追加される。
【0185】
尚、以上では、ある組織のクライアントノード４からＳＣ関数「健全性相互検証５１２」の実行ＴＸが送信（発行）されたことを契機として健全性相互検証処理Ｓ１０００が行われる場合を例示したが、他の事象を契機として健全性相互検証処理Ｓ１０００を実行してもよい。例えば、ＳＣ関数「健全性報告５１１」により健全性報告処理Ｓ９００が行われた際、分散台帳ノード３が、検証対象期間について健全性の検証が可能か否かの判定基準を満たす旨の報告を取得できている否かを判定し、取得できていると判定した場合にＳＣ関数「健全性相互検証５１２」を後続して実行するようにしてもよい。また、所定のＳＣイベントが生じたことを契機として健全性相互検証処理Ｓ１０００を実行するようにしてもよい。
【0186】
図１１は、クライアントノード４から、分散台帳ノード３群の分散台帳ノード３に対し、図５の健全性管理ＳＣ３１４のＳＣ関数「構成準拠状況検証５１３」の実行ＴＸが送信された場合に分散台帳ノード３において行われる処理（以下、「構成準拠状況検証処理Ｓ１１００」と称する。）、及び、ＳＣ関数「アクション指示５１４」の実行ＴＸが送信された場合に分散台帳ノード３において行われる処理（以下、「アクション処理Ｓ１１５０」と称する。）を説明するフローチャートである。以下、同図とともに構成準拠状況検証処理Ｓ１１００及びアクション処理Ｓ１１５０について説明する。
【0187】
まず、構成準拠状況検証処理Ｓ１１００に相当するＳ１１１１～Ｓ１１１４の処理について説明する。
【0188】
分散台帳ノード３群の各分散台帳ノード３は、実行ＴＸとして、健全性管理ＳＣ３１４のＳＣ関数「構成準拠状況検証５１３」の呼び出しを受信し、各分散台帳ノード３のＳＣ実行管理部３３０が、受信した実行ＴＸに従いＳＣ関数「構成準拠状況検証５１３」を実行する（Ｓ１１１１）。
【0189】
ＳＣ関数「構成準拠状況検証５１３」の処理において、分散台帳ノード３は、まず、構成設計情報５５４を取得する（Ｓ１１１２）。尚、ＳＣ関数「構成準拠状況検証５１３」は、例えば、データ参照関数を用いて構成設計情報５５４を取得する。
【0190】
続くＳＣ関数「構成準拠状況検証５１３」の処理において、分散台帳ノード３は、検証対象期間（タイムスパン）におけるステート情報３１２「健全性検証結果５５３」を参照し、当該検証対象期間における各組織の構成準拠状況を検証する（Ｓ１１１３）。
【0191】
尚、上記の検証対象期間は、例えば、実行ＴＸからの入力情報によって指定される。また、上記の検証対象期間は、例えば、現在日時に基づき分散台帳ノード３が自動的に決定するようにしてもよい。また、例えば、分散台帳ノード３が未検証の全ての期間を上記の検証対象期間とするようにしてもよい。
【0192】
分散台帳ノード３の構成準拠状況は、例えば、対象期間中における分散台帳ノード３の健全性を正常であった期間の割合から求め、対象期間中に健全性が正常であった分散台帳ノード３のノード数と構成設計情報５５４の準備ノード５５４２との差分から構成準拠率を求める。図６Ｃの健全性検証結果５５３と図６Ｄの構成設計情報５５４を例として具体的に説明する。
【0193】
まず、健全性検証結果５５３から、例えば、「Ｓｐａｎ１（Ｓｐａｎ１－Ｘ）」を検証対象期間とした場合、「組織１」の「ノード１」の健全性検証結果は「Ｓｐａｎ１－１にてＯＫ、Ｓｐａｎ１－２にてＯＫ、Ｓｐａｎ１－３にてＯＫ…」であるので、「Ｓｐａｎ１」のタイムスパンにおける「組織１」の「ノード１」の健全性は「３÷３＝１００％」となる。また、同様に「組織１」の「ノード２」の健全性は「１００％」となる。
【0194】
ここで構成設計情報５５４と比較すると、「組織１」については、準備ノード５５４２は「２ノード」であり、健全性検証結果５５３から、「ノード１」及び「ノード２」の２ノードが検証対象期間において健全性が「１００％」（正常）であることが確認できたため、当該検証対象期間における準拠状況は「ＯＫ」となり、当該検証対象期間における準拠率は「１００％」となる。
【0195】
また、「組織２」の「ノード１」の分散台帳ノード３の健全性検証結果は「Ｓｐａｎ１－１にてＯＫ、Ｓｐａｎ１－２にてＯＫ、Ｓｐａｎ１－３にてＯＫ…」であるので、「Ｓｐａｎ１」のタイムスパンにおける「組織２」の「ノード１」の健全性は「３÷３＝１００％」となる。一方、「組織２」の「ノード２」の健全性は０÷３で「０％」となる。
【0196】
ここで構成設計情報５５４と比較すると、「組織２」については、準備ノード５５４２は「２ノード」であり、健全性検証結果５５３から、「ノード２」の健全性が「０％」ある、当該検証対象期間における準拠状況は「ＮＧ」となり、その理由は「１ノード不足」となる。また、構成準拠率は「「１００％＋０％」／２＝５０％」となる。
【0197】
図１１に戻り、続くＳＣ関数「構成準拠状況検証５１３」の処理において、分散台帳ノード３は、検証結果を健全性管理ＳＣ３１４のステート情報３１２「構成準拠状況」に追加（更新）する（Ｓ１１１４）。
【0198】
尚、以上では、分散台帳ノード３がＳＣ関数「構成準拠状況検証５１３」の実行ＴＸを受信したことを契機として構成準拠状況検証処理Ｓ１１００を実行する場合を示したが、構成準拠状況検証処理Ｓ１１００は、他の事象を契機として実行してもよい。また、図６Ａに示した監視頻度５５１３のように予め設定した対象期間や実行頻度に従って構成準拠状況検証処理Ｓ１１００を実行するようにしてもよい。また、例えば、ＳＣ関数「健全性相互検証５１２」に後続してＳＣ関数「構成準拠状況検証５１３」を実行するようにしてもよい。また、ＳＣイベントの発生を契機としてＳＣ関数「構成準拠状況検証５１３」を実行するようにしてもよい。
【0199】
続いて、アクション処理Ｓ１１５０に相当するＳ１１５１～Ｓ１１５４及びＳ１１６１～Ｓ１１６３の処理について同図とともに説明する。
【0200】
各分散台帳ノード３は、実行ＴＸとして、健全性管理ＳＣのＳＣ関数「アクション指示５１４」を呼び出す実行ＴＸを受信（Ｓ１１５１）すると、ＳＣ実行管理部３３０が、受信した実行ＴＸに従いＳＣ関数「アクション指示５１４」を実行する。尚、ＳＣ関数「アクション指示５１４」は、ＳＣ関数「構成準拠状況検証５１３」に後続して分散台帳ノード３が自動実行するようにしてもよい。
【0201】
ＳＣ関数「アクション指示５１４」の処理において、分散台帳ノード３は、まず、現在の構成準拠状況が所定の条件から逸脱するか否かを判定する（Ｓ１１５２）。上記の条件としては、例えば、構成準拠状況において「ＮＧ」が一定期間が続くこと、全ての組織又はいずれかの組織の構成準拠率が所定の閾値を下回ること等がある。
【0202】
Ｓ１１５２において、現在の構成準拠状況が所定の条件から逸脱しない場合（Ｓ１１５２：Ｎｏ）」、アクション処理Ｓ１１５０は終了する。一方、現在の構成準拠状況が所定の条件から逸脱する場合（Ｓ１１５２：Ｙｅｓ）、ＳＣ関数「アクション指示５１４」は、現在の状況に応じてコンソーシアムの参加組織に向けたアクション（例えば、「構成見直し依頼」、「ペナルティを課す」等）を決定する（Ｓ１１５３）。
【0203】
図６Ｅの構成準拠状況５５５では、「Ｓｐａｎ１」において「組織２」の分散台帳ノード３が１台不足しており、構成準拠状況５５５が構成設計情報５５４から逸脱している。そのため、ＳＣ関数「アクション指示５１４」は、コンソーシアムとしてのアクションを次のようにして決定し発行する。
【0204】
まず、分散台帳ノード３は、構成の見直しを行い、コンソーシアムに不足分ノードを１台追加することを決定する。また、分散台帳ノード３は、当該ノードを用意する組織を選出するため、キャパシティ情報５５６を参照する。ここで例えば、図６Ｆのキャパシティ情報５５６を図６Ｄの構成設計情報５５４と比較すると、「組織１」、「組織３」、「組織４」のいずれも準備可能ノード５５６２に１台ずつ余裕があることがわかる。そこで、分散台帳ノード３は、例えば、現在の準備ノード５５４２が最も少ない「組織４」に対して、「組織２」の代わりにコンソーシアムへの分散台帳ノード３の提供を依頼するアクションの発行を決定する。一方、分散台帳ノード３は、「組織２」に対して構成設計情報５５４に指定されている構成を準備できなかったことについてペナルティ（「Ｓｐａｎ１」の期間中の損失額の支払い等）を課す旨のアクションの発行を決定する。分散台帳ノード３は、発行することを決定した以上のアクションを指示するアクションイベントを生成し、生成したアクションイベントをアクションイベント５８１としてＳＣイベント２２２に格納する（Ｓ１１５４）。
【0205】
クライアントノード４の監視エージェント４３５は、ＳＣイベント２２２を随時監視している。監視エージェント４３５は、上記のアクションイベント５８１の発生を検出すると（Ｓ１１６１）、自組織が当該アクションイベント５８１の対象組織であるかを確認する（Ｓ１１６２）。自組織がアクションイベント５８１の対象組織であった場合（Ｓ１１６２：ＹＥＳ）、クライアントノード４は、アクションイベント５８１に指示された内容に従ってアクションイベント５８１に対応する処理を実施する（Ｓ１１６３）。監視エージェント４３５は、アクションイベント５８１の処理の実施の結果を、必要に応じて、例えば、健全性管理ＳＣ３１４を介してコンソーシアムに報告する。
【0206】
各組織は、例えば、自組織についてのアクションイベント５８１の発生を確認すると、分散台帳ノード３をコンソーシアムに追加する等、アクションイベント５８１の内容に従った対応を行い、その結果を分散台帳ノード３に報告する。尚、分散台帳ノード３は、上記報告を受信すると、構成設計情報５５４を更新（例えば、「組織４」の準備ノードを１台追加し、「組織２」の準備ノードを１台減らす等）する。これによりコンソーシアムとしての構成を是正することができる。尚、組織２はアクションイベント５８１を受け、ペナルティ分の損失額を、例えば、仮想通貨としてコンソーシアムに支払う。
【0207】
以上に説明したように、本実施形態の分散台帳システム１によれば、健全性監視(構成の正しさ/死活)を(複数の)他組織が実施/検証することで客観性を確保できる。
【0208】
また、以上に示したように、所定の処理をスマートコントラクト（ＳＣ）により行うことで、各組織の健全性監視結果をオンチェーンに集約して分析処理することができる。このため、単一信頼点を排除して証拠としての価値を提供できる。
【0209】
また、本実施形態の分散台帳システム１によれば、組織を横断する情報収集を実現できる、信頼できる証拠に基づくアクションを実施できる等の効果がある。
【0210】
［第２実施形態］
続いて、第２実施形態の分散台帳システム１について説明する。尚、第２実施形態の分散台帳システム１の基本的な構成は、第１実施形態の分散台帳システム１と同様であるので、以下、第１実施形態との相違点を中心として説明する。
続いて、第２実施形態の分散台帳システム１について説明する。尚、第２実施形態の分散台帳システム１の基本的な構成は、第１実施形態の分散台帳システム１と同様であるので、以下、第１実施形態との相違点を中心として説明する。
【0211】
第２実施形態の分散台帳システム１は、第１実施形態の分散台帳システム１の構成に加え、各組織の報告の内容や構成準拠状況に基づき、各組織の信頼度（以下、「組織信頼度」と称する。）を求め、その結果を、コンソーシアムや各組織にフィードバックする構成を有する。また、第２実施形態の分散台帳システム１は、組織信頼度に基づき、他の分散台帳ノード３の健全性の監視を行う組織を選出する構成を有する。
【0212】
図１２は、第２実施形態の分散台帳システム１における分散台帳ノード３が、各組織の組織信頼度を求める際に行う処理（以下、「信頼度算出処理Ｓ１２００」と称する。）を説明するフローチャートである。以下、同図とともに信頼度算出処理Ｓ１２００について説明する。
【0213】
各分散台帳ノード３は、クライアントノード４から、実行ＴＸとして、図５に示す健全性管理ＳＣ３１４のＳＣ関数「組織信頼度算出５１５」を呼び出す実行ＴＸを受信すると、ＳＣ関数「組織信頼度算出５１５」を実行する（Ｓ１２１１）。尚、クライアントノード４は、所定のタイミング（例えば、定期的等）で上記実行ＴＸを各分散台帳ノード３に送信（発行）する。
【0214】
ＳＣ関数「組織信頼度算出５１５」の処理において、分散台帳ノード３は、まず、算出対象とする期間（例えば、タイムスパン。以下、「算出対象期間」と称する。）におけるステート情報３１２の健全性監視結果５５２と健全性検証結果５５３を参照する。そして、分散台帳ノード３は、取得した情報に基づき、当該算出対象期間における各組織の健全性の監視の内容についての信頼度（以下、「健全性報告内容信頼度」と称する。）を求める（Ｓ１２１２）。
【0215】
上記の算出対象期間は、例えば、クライアントノード４から分散台帳ノード３に送信する実行ＴＸに付帯させてもよいし、現在日時から自動的に設定してもよい。また、算出対象としていない全ての期間を対象としてもよい。
【0216】
健全性報告内容信頼度としては、例えば、算出の対象となる組織の各タイムスパンにおける健全性の監視結果が、各タイムスパンにおいて他の組織の判断結果（コンソーシアム全体の総意）との一致の度合い（割合）から求める。
【0217】
続くＳＣ関数「組織信頼度算出５１５」の処理において、分散台帳ノード３は、算出対象期間におけるステート情報３１２の構成準拠状況５５５を参照し、算出対象期間における各組織の構成準拠の度合い（以下、「構成準拠信頼度」と称する。）を求める（Ｓ１２１３）。
【0218】
構成準拠信頼度は、例えば、各組織の算出対象期間における全てのタイムスパンの構成準拠率の統計値（平均値、最小値、最大値等）から求める。
【0219】
続くＳＣ関数「組織信頼度算出５１５」の処理において、分散台帳ノード３は、Ｓ１２１２で求めた健全性報告内容信頼度とＳ１２１３で求めた構成準拠信頼度に基づく情報を組織信頼度として健全性管理ＳＣのステート情報３１２の組織信頼度５５７に追加（更新）する（Ｓ１２１４）。
【0220】
このように、組織信頼度を求めてステート情報３１２に記録するので、各組織の信頼度の客観的な評価を得ることができる。
【0221】
尚、健全性報告内容信頼度は、健全性相互検証の判定可能基準及び判定方法に活用してもよく、例えば、健全性報告内容信頼度の高い組織からの報告の重みを大きくする等の利用形態が考えられる。
【0222】
また、健全性報告内容信頼度を、健全性の監視を行う組織の選出に用いてもよく、例えば、健全性報告内容信頼の高い組織を優先して選出するようにする。
【0223】
このように、健全性報告内容信頼度を活用することで、健全性の監視の精度を高める効果が期待できる。
【0224】
また、構成準拠信頼度に基づきペナルティ額の重みづけを行う等、構成準拠信頼度は前述したアクションイベント５８１の内容を決定する際に用いることができる。これにより分散台帳システム１の運営の健全化を期待できる。
【0225】
また、構成準拠信頼度の利用形態としては、ある組織の分散台帳ノード３が不足している場合は、構成準拠信頼度が当該組織よりも高い他の組織に分散台帳ノード３の提供を依頼するといったことも考えられる。
【0226】
このように、構成準拠信頼度を積極的に活用することで、コンソーシアムとしての構成準拠率の維持向上を促進する効果が期待できる。
【0227】
図１３は、第２実施形態の分散台帳システム１における分散台帳ノード３が、健全性の監視を行う組織を選出する際に行う処理（以下、「監視担当組織選出処理Ｓ１３００」と称する。）を説明するフローチャートである。以下、同図とともに監視担当組織選出処理Ｓ１３００について説明する。
【0228】
各分散台帳ノード３は、クライアントノード４から、実行ＴＸとして、図５に示す健全性管理ＳＣ３１４のＳＣ関数「監視担当組織選出５１６」を呼び出す実行ＴＸを受信すると、ＳＣ関数「監視担当組織選出５１６」を実行する（Ｓ１３１１）。クライアントノード４は、適宜なタイミング（例えば、定期的等）で上記実行ＴＸを各分散台帳ノード３に送信（発行）する。
【0229】
ＳＣ関数「監視担当組織選出５１６」の処理において、分散台帳ノード３は、まず、ステート情報３１２の健全性監視方法定義５５１の判定可能基準５５１４に基づき監視担当組織の選出に用いる情報（ＳＣ合意条件等）を取得する（Ｓ１３１２）。例えば、上記処理において、分散台帳ノード３は、判定可能基準５５１４に「ＳＣ合意条件」が格納されている場合、分散台帳ノード３の記憶部３００が記憶するコンソーシアム情報３０２に含まれているＳＣ合意条件を取得する。本例では、ＳＣ合意条件「３組織以上からの承認」を取得するものとする。
【0230】
続くＳＣ関数「監視担当組織選出５１６」の処理において、分散台帳ノード３は、ステート情報３１２の組織信頼度５５７を取得する（Ｓ１３１３）。
【0231】
続いて、上記処理において、分散台帳ノード３は、分散台帳ノード３は、Ｓ１３１２とＳ１３１３で取得した情報を用いて監視担当組織を決定する（Ｓ１３１４）。例えば、分散台帳ノード３は、ＳＣ合意条件を最低限満たすために３つの組織を選出する。例えば、組織信頼度５５７が図６Ｇの内容である場合、ＳＣ関数「監視担当組織選出５１６」は、健全性報告内容信頼度５５７２が高い順に、「組織１」、「組織３」、「組織４」を選出する。
【0232】
続くＳＣ関数「監視担当組織選出５１６」の処理において、分散台帳ノード３は、選出した組織をステート情報３１２の監視担当組織５５８に追加（更新）する(Ｓ１３１５)。
【0233】
各組織のクライアントノード４の監視エージェント４３５は、例えば、健全性管理ＳＣ３１４を介して監視担当組織５５８を取得し、自身が監視担当組織に選出されている場合に他の組織の健全性の監視と分散台帳ノード３への報告を行う。
【0234】
また、例えば、健全性管理ＳＣ３１４は、監視担当組織５５８の情報を用いて、図９のＳ９２２において組織が権限を有するか否かの確認を行う。
【0235】
尚、以上では、判定可能基準５５１４（ＳＣ合意条件）を最低限満たす組織を選出したが、余裕をもって少し多めに組織を選出するようにしてもよい。そのようにすることで、例えば、健全性報告内容信頼度が低い組織しか存在しない場合に監視担当組織が不足する事態となるリスクを低減することができる。
【0236】
以上のように、健全性の監視の判定可能基準（とくにＳＣ合意条件等の分散台帳システムとしての合意条件）に基づき、必要最小限の監視担当組織を選出することで、分散台帳ノード３の健全性の監視の客観性確保と、リソース量や処理量の効率化とを両立させることができる。
【0237】
＜健全性に関する情報の提供＞
以上に説明した分散台帳システム１は、分散台帳ノード３の分散台帳３１０に管理されている情報をユーザに随時提供する仕組みを備える。上記仕組みは、分散台帳３１０に直接アクセスして上記情報を取得するものでもよいし、健全性管理ＳＣ３１４のように分散台帳ノード３（分散台帳３１０）にデプロイされたスマートコントラクト（ＳＣ）を利用して上記情報を取得するものでもよい。また、上記情報を提供する仕組みは、分散台帳ノード３やクライアントノード４に設けてもよいし、それら以外のノード（Ｗｅｂサーバ等）に設けてもよい。
以上に説明した分散台帳システム１は、分散台帳ノード３の分散台帳３１０に管理されている情報をユーザに随時提供する仕組みを備える。上記仕組みは、分散台帳３１０に直接アクセスして上記情報を取得するものでもよいし、健全性管理ＳＣ３１４のように分散台帳ノード３（分散台帳３１０）にデプロイされたスマートコントラクト（ＳＣ）を利用して上記情報を取得するものでもよい。また、上記情報を提供する仕組みは、分散台帳ノード３やクライアントノード４に設けてもよいし、それら以外のノード（Ｗｅｂサーバ等）に設けてもよい。
【0238】
図１４は、上記の情報を提供する情報処理装置がユーザに提示する画面（以下、「健全性情報提供画面１４００」と称する）の一例である。例示する健全性情報提供画面１４００には、ログイン中の組織ＩＤが「組織１」の組織に主眼を置いた情報が表示されている。
【0239】
例示する健全性情報提供画面１４００には、各組織の構成準拠状況１４１１、健全性検証結果履歴１４１２、当該組織による他の組織の健全性監視結果１４１３、他の組織による当該組織の健全性監視結果１４１４、コンソーシアムに参加している各組織の組織信頼度１４１５等が表示されている。
【0240】
このように、各組織のユーザは、健全性情報提供画面１４００を介して容易にステート情報３１２の内容を確認することができ、自組織の分散台帳ノード３についての健全性の管理に役立てることができる。
【0241】
＜技術的効果＞
以上に説明したように、本実施形態の分散台帳システム１における分散台帳ノード３は、第１の組織が第２の組織の分散台帳ノード３の健全性を監視した結果である健全性監視結果を受信し、受信した複数組織による健全性監視結果を検証し、検証した結果である健全性検証結果を分散台帳３１０に記録する。このため、各組織の分散台帳ノード３についての客観性のある健全性検証結果を分散台帳３１０に集約して管理することができ、客観性のある情報に基づき、分散台帳システム１全体としての健全性を効率よく監視することができる。
以上に説明したように、本実施形態の分散台帳システム１における分散台帳ノード３は、第１の組織が第２の組織の分散台帳ノード３の健全性を監視した結果である健全性監視結果を受信し、受信した複数組織による健全性監視結果を検証し、検証した結果である健全性検証結果を分散台帳３１０に記録する。このため、各組織の分散台帳ノード３についての客観性のある健全性検証結果を分散台帳３１０に集約して管理することができ、客観性のある情報に基づき、分散台帳システム１全体としての健全性を効率よく監視することができる。
【0242】
また、健全性監視結果の取得や健全性監視結果の検証をスマートコントラクト（ＳＣ）により行うので、各組織の健全性に関する情報を分散台帳にオンチェーンの情報として管理することができる。従って、単一信頼点を排除して信頼性／証拠性の高い情報を提供することができる。
【0243】
また、分散台帳ノード３は、健全性検証結果を第２の組織の構成設計情報と比較対照することにより、組織が構成設計情報に準拠している度合いを示す情報である構成準拠状況を生成して分散台帳３１０に記録する。このため、健全性の判断に用いる各組織の分散台帳ノード３の構成準拠情報を客観性の高い情報として管理し提供することができる。
【0244】
また、分散台帳ノード３は、第２の組織の構成準拠状況が構成設計情報を満たしていない場合、第２の組織に分散台帳ノード３の構成の見直しを指示する情報を分散台帳３１０に記録する。このため、第２の組織は、上記情報を参照することで、分散台帳ノード３の見直しが必要であることを認識することができる。
【0245】
また、分散台帳ノード３は、第２の組織の構成準拠状況が構成設計情報を満たしていない場合、分散台帳ノード３の構成が不足していることにより第２の組織にペナルティが課されることを示す情報を分散台帳に記録するので、第２の組織は、上記情報を参照することで、ペナルティを回避するために分散台帳ノードの見直しが必要であることを認識することができる。
【0246】
また、分散台帳ノード３は、構成準拠状況に基づき、複数の組織の夫々の信頼度である組織信頼度を生成して分散台帳に記録するので、各組織の組織信頼度を提供することができる。
【0247】
また、分散台帳ノード３は、健全性監視結果に基づき、複数の組織の夫々の信頼度である組織信頼度を生成して分散台帳に記録するので、各組織の組織信頼度を提供することができる。
【0248】
また、組織のクライアントノード４は、分散台帳３１０の健全性監視方法定義５５１に従って第２の組織の健全性を監視するので、組織間の健全性の監視方法のばらつきを防ぐことができる。
【0249】
また、分散台帳ノード３は、健全性監視結果に基づき監視担当組織を決定するので、信頼性の高い組織を監視担当組織として選出することができる。
【0250】
また、分散台帳ノード３は、組織信頼度に基づき監視担当組織を決定するので、信頼性の高い組織を監視担当組織として選出することができる。
【0251】
また、分散台帳ノード３は、構成成準拠状況に応じて監視担当組織を選出するので、信頼性の高い組織を監視担当組織として選出することができる。
【0252】
＜情報処理装置の例＞
図１５は、第１実施形態及び第２実施形態で説明した分散台帳システム１の実現に用いる情報処理装置（コンピュータ）の一例である。クライアントノード４や分散台帳ノード３は、例えば、同図に示す情報処理装置１０を用いて構成される。
図１５は、第１実施形態及び第２実施形態で説明した分散台帳システム１の実現に用いる情報処理装置（コンピュータ）の一例である。クライアントノード４や分散台帳ノード３は、例えば、同図に示す情報処理装置１０を用いて構成される。
【0253】
例示する情報処理装置１０は、プロセッサ１１、主記憶装置１２（メモリ）、補助記憶装置１３（外部記憶装置）、入力装置１４、出力装置１５、及び通信装置１６を備える。これらはバスや通信ケーブル等を介して通信可能に接続されている。情報処理装置１０の例として、パーソナルコンピュータ、各種サーバ装置、オフィスコンピュータ、汎用機（メインフレーム）、スマートフォン、タブレット等がある。
【0254】
情報処理装置１０は、その全部又は一部が、例えば、クラウドシステムによって提供される仮想サーバのように、仮想化技術やプロセス空間分離技術等を用いて提供される仮想的な情報処理資源を用いて実現されるものであってもよい。また、情報処理装置１０によって提供される機能の全部又は一部は、例えば、クラウドシステムがＡＰＩ（Application Programming Interface）等を介して提供するサービスによって実現してもよい。また、情報処理装置１０によって提供される機能の全部又は一部は、例えば、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、ＩａａＳ（Infrastructure as a Service）等を利用して実現されるものであってもよい。
【0255】
プロセッサ１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＡＩ（Artificial Intelligence）チップ等を用いて構成されている。
【0256】
主記憶装置１２は、プロセッサ１１がプログラムを実行する際に利用する装置であり、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性メモリ（ＮＶＲＡＭ（Non Volatile RAM））等である。分散台帳システム１の各構成要素において実現される各種の機能は、夫々のプロセッサ１１が、補助記憶装置１３に格納（記憶）されているプログラムやデータを主記憶装置１２に読み出して実行することにより実現される。
【0257】
補助記憶装置１３は、プログラムやデータを記憶する装置であり、例えば、ＳＳＤ（Solid State Drive）、ハードディスクドライブ、光学式記憶装置（ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等）、ＮＡＳ（Network Attached Storage）等の各種ストレージシステム、ＩＣカード、ＳＤカードや光学式記録媒体等の非一時的な記録媒体の読取／書込装置、クラウドサーバの非一時的な記憶領域等で構成することができる。補助記憶装置１３には、記録媒体の読取装置や通信装置１６を介して、非一時的な記録媒体や非一時的な記憶装置を備えた他の情報処理装置からプログラムやデータを読み込むことができる。補助記憶装置１３に格納（記憶）されているプログラムやデータは主記憶装置１２に随時読み込まれる。
【0258】
入力装置１４は、外部からの情報の入力を受け付けるインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、ペン入力方式のタブレット、音声入力装置等である。
【0259】
出力装置１５は、処理経過や処理結果等の各種情報を外部に出力するインタフェースである。出力装置１５は、例えば、上記の各種情報を可視化する表示装置（液晶モニタ、ＬＣＤ（Liquid Crystal Display）、グラフィックカード等）、上記の各種情報を音声化する装置（音声出力装置（スピーカ等））、上記の各種情報を文字化する装置（印字装置等）である。尚、例えば、情報処理装置１０が通信装置１６を介して他の装置との間で情報の入力や出力を行う構成としてもよい。
【0260】
入力装置１４と出力装置１５は、ユーザとの間での対話処理（情報の受け付け、情報の提供等）を実現するユーザインタフェースを構成する。
【0261】
通信装置１６は、他の装置との間の通信を実現する装置である。通信装置１６は、通信ネットワーク５を介して他の装置との間の通信を実現する、有線方式又は無線方式の通信インタフェースであり、例えば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢモジュール等である。
【0262】
情報処理装置１０には、例えば、オペレーティングシステム、ファイルシステム、ＤＢＭＳ（DataBase Management System）（リレーショナルデータベース、ＮｏＳＱＬ等）、ＫＶＳ（Key-Value Store）等が導入されていてもよい。
【0263】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【0264】
１ 分散台帳システム、３ 分散台帳ノード、３００ 記憶部、３０２ コンソーシアム情報、３０３ 参加メンバー管理情報、３１０ 分散台帳、３１１ ブロックチェーン（ＢＣ）、３１２ ステート情報、３１３ 業務ＳＣ、３１４ 健全性管理ＳＣ、３２０ ＴＸ管理部、３２５ コンセンサス管理部、３３０ ＳＣ実行管理部、３３５ 承認済ＴＸ配信部、３４０ ＴＸ発行部、３４５ ノード探索部、３５０ メンバー管理部、３５５ 通信部、４ クライアントノード、４００ 記憶部、４０１ ノード探索情報、４２０ ＴＸ発行部、４２５ ノード探索部、４３０ 業務アプリ、４３５ 監視エージェント、５１１ 健全性報告、５１２ 健全性相互検証、５１３ 構成準拠状況検証、５１４ アクション指示、５１５ 組織信頼度算出、５１６ 監視担当組織選出、５１７ 各種データ参照、５５１ 健全性監視方法定義、５５２ 健全性監視結果、５５３ 健全性検証結果、５５４ 構成設計情報、５５５ 構成準拠状況、５５６ キャパシティ情報、５５７ 組織信頼度、５５８ 監視担当組織、Ｓ７００ メンバー登録処理、Ｓ８００ ＳＣデプロイ／実行処理、Ｓ９００ 健全性報告処理、Ｓ１０００ 健全性相互検証処理、Ｓ１１００ 構成準拠状況検証処理、Ｓ１１５０ アクション処理、Ｓ１２００ 信頼度算出処理、Ｓ１３００ 監視担当組織選出処理、１４００ 健全性情報提供画面
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図2G】
【図3】
【図4A】
【図4B】
【図5】
【図6A】
【図6B】
【図6C】
【図6D】
【図6E】
【図6F】
【図6G】
【図6H】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】