特許 7607601 エビデンス管理方法、エビデンス管理システム及びノード

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-19

(45)【発行日】2024-12-27

(54)【発明の名称】エビデンス管理方法、エビデンス管理システム及びノード

(51)【国際特許分類】

   G06Q 10/06 20230101AFI20241220BHJP

   G06F 21/64 20130101ALI20241220BHJP

   H04L 9/32 20060101ALI20241220BHJP

【ＦＩ】

G06Q10/06

G06F21/64

H04L9/32 200Z

【請求項の数】 11

(21)【出願番号】P 2022007174

(22)【出願日】2022-01-20

(65)【公開番号】P2023106055

(43)【公開日】2023-08-01

【審査請求日】2024-02-21

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000176

【氏名又は名称】弁理士法人一色国際特許事務所

(72)【発明者】

【氏名】佐藤 竜也

(72)【発明者】

【氏名】下沢 拓

【審査官】宮地 匡人

(56)【参考文献】

【文献】国際公開第２０２１／２０１８２７（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０２１／０１２６７７７（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１３８８８０７８（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ０６Ｆ ２１／６４

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

複数組織のノードで構成される分散台帳システムにおいて、各組織のスマートコントラクトは、
前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行する、
ことを特徴とするエビデンス管理方法。

【請求項2】

前記スマートコントラクトは、
前記パブリック領域に公開された前記エビデンスを用いて、所定のデータ処理を実行する、
ことを特徴とする請求項１に記載のエビデンス管理方法。

【請求項3】

前記スマートコントラクトは、
前記データ処理に際し、前記プライベート領域で保持された前記エビデンスに基づいて一定の計算手順により求められた計算値と、前記パブリック領域に公開された前記情報が含む又は前記情報に基づく計算値とが一致することを確認する、
ことを特徴とする請求項２に記載のエビデンス管理方法。

【請求項4】

前記スマートコントラクトは、
前記エビデンスをプライベート領域に保持する際、当該エビデンスと組織毎の固有の値を合成した状態で管理する、
ことを特徴とする請求項１に記載のエビデンス管理方法。

【請求項5】

前記スマートコントラクトは、
前記公開するための処理として、前記エビデンスの公開開始イベントを発行し、
前記複数組織のエージェントノードは、
前記公開開始イベントを受けて、前記エビデンスの前記パブリック領域への公開を実行する、
ことを特徴とする請求項２に記載のエビデンス管理方法。

【請求項6】

前記スマートコントラクトまたは予め所定ルールで生成したサブグループにおいて、
前記公開に際し、前記サブグループ内で前記公開及び前記データ処理を実行し、当該データ処理の結果を他のサブグループに公開する、
ことを特徴とする請求項５に記載のエビデンス管理方法。

【請求項7】

前記スマートコントラクトは、
前記公開開始イベントの発行後、前記エビデンスに関する前記情報の、前記パブリック領域への公開又は当該情報の更新を拒否するか、或いは前記公開開始イベントの発行後に公開又は更新されたタイミングの情報を当該情報に付与する、
ことを特徴とする請求項５に記載のエビデンス管理方法。

【請求項8】

前記スマートコントラクトは、
前記公開するための処理として、前記契機に応じてエビデンス公開開始の仮イベントを発行し、
前記エージェントノードは、
前記仮イベントを受けて、前記複数組織の間での合意形成を経て、前記エビデンスの公開開始を確定させ、前記公開開始イベントを発行する、
ことを特徴とする請求項５に記載のエビデンス管理方法。

【請求項9】

前記スマートコントラクトは、
前記複数組織それぞれにおける、前記エビデンスの前記パブリック領域への公開に伴い、当該公開の状況が所定条件を満たした場合、前記データ処理の開始に関する仮イベントを発行し、
所定組織のエージェントノードは、
前記仮イベントを受けて、前記複数組織の間での合意形成を経て、前記データ処理を行う、
ことを特徴とする請求項５に記載のエビデンス管理方法。

【請求項10】

複数組織のノードで構成されるエビデンス管理システムであって、
各組織のスマートコントラクトは、前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行するものである、
ことを特徴とするエビデンス管理システム。

【請求項11】

分散台帳システムを構成する、複数組織のノードのいずれかであって、
前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行するスマートコントラクトを保持するものである、
ことを特徴とするノード。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、エビデンス管理方法、エビデンス管理システム及びノードに関するものである。

【背景技術】

【0002】

従来、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた取引を、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって直接的な取引に代替する技術として、分散台帳技術が登場している。
例えば非特許文献１には、仮想通貨を用いて、銀行などの中央集権機関を必要とせずに決済取引を行う技術について開示されている。本仮想通貨の仕組みでは、Ｐ２Ｐネットワーク上でマイナーと呼ばれるノードによる取引データ（以下、トランザクションとも称する）の正当性判定後、プルーフオブワークと呼ばれる特定のハッシュ値算出作業で確定処理を行っている。確定されたトランザクションは１つのブロックにまとめられ、ブロックチェーン（以下、ＢＣとも称する）と呼ばれる分散台帳に記載される。

【0003】

また近年では、上記の非特許文献１の技術に基づき実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術が提案され、進化を続けている。

【0004】

現状のＢＣの主な特徴としては、（１）分散台帳ネットワーク上の参加者間の取引において中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、などが挙げられる。

【0005】

このようなＢＣをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。

【0006】

分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）。

【0007】

以降では分散台帳に参加する参加者（およびそのノード）によって構成されるネットワークのことを分散台帳ネットワークと呼ぶ。

【0008】

分散台帳は非特許文献１のような単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくロジックも管理可能となってきている。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。

【0009】

例えば、非特許文献２および３には、こうしたＳＣの実行機能を有する分散台帳基盤に関する技術について開示されている。これらの分散台帳基盤では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも称する）を受け入れて、各ノードでＴＸを実行することにより、複数ノード上で情報（台帳）を共有する。

【0010】

また、ＴＸに対して予め決めたロジックを実行するスマートコントラクト（ＳＣ）実行
機能を備える。

【0011】

分散台帳技術の典型的な利用形態として、上述の非特許文献１に基づくＢＣのような不特定多数の計算リソース（ノード）が分散台帳ネットワークを形成するパブリック型に加えて、特定企業／組織間のノードで分散台帳ネットワークを形成するパーミッション型が、特にエンタープライズで有望視されている。

【0012】

そうしたパーミッション型のＢＣに参加する複数の組織間で各ノードが分散合意プロトコルに基づき同期／連動しながら、事前に取り決められ、かつ、コード化された契約内容（ＳＣ）に従って取引を自動実行することができるようになる。

【0013】

分散台帳技術を用いて構築したシステム（以下、分散台帳システム）では、その実用の一形態として、組織間でエビデンスを共有し、そこで共有することで集まったエビデンスを比較/集計するユースケースが想定される。このようなユースケースでは、エビデンス
の取扱いに関して透明性を確保するため、エンタープライズ型ＢＣを適用できる。

【0014】

より具体的なユースケースとしては、組織またぎの運用管理の形態である、ガバナンス目的の投票やシステム運用状況の申告に関して、各参加者から情報すなわちエビデンスを比較／集計するといったものがある。またその他にも、オークションや不動産、工事等に関する入札情報の比較／集計といったものもありうる。

【0015】

これらユースケースでは、エビデンスの管理や処理に関する透明性確保のため、最終的に当該エビデンスを各参加者に公開してもよい/したいが、比較や集計を行う前の途中段
階での公開は好ましくない。

【先行技術文献】

【非特許文献】

【0016】

【文献】“Ａ Ｐｅｅｒ－ｔｏ－Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍ”，［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｂｉｔｃｏｉｎ．ｏｒｇ／ｂｉｔｃｏｉｎ．ｐｄｆ＞

【特許文献】

【0017】

【文献】特開２０１９－２８５２５号公報

【文献】特開２０２１－６４８９１号公報

【発明の概要】

【発明が解決しようとする課題】

【0018】

エビデンスの取扱いに関する従来技術としては、例えば、分散台帳システムにおいて管理者が複数存在する状況下でも、ノード間でポリシーやタイミングを揃えた運用管理を可能とする技術（特許文献１参照）が提案されている。
この技術は、複数のノードで構成される分散台帳システムにおいて、前記複数のノードのうち少なくとも所定の複数ノードは、それぞれ、分散台帳にて当該分散台帳システムの運用管理用の運用スマートコントラクトを管理し、前記所定の複数ノードのうち少なくとも１つのノードがトランザクションを受け取った場合、前記トランザクションを受け取ったノードは、前記トランザクションの種別が前記運用スマートコントラクトか否かを判定し、当該判定結果に基づき、前記運用スマートコントラクトを実行するものである。

【0019】

また、Ｐａｉｒｉｎｇ演算を必要としない暗号方式を利用したコンソーシアムブロックチェーンシステム（特許文献２参照）も提案されている。

【0020】

この技術は、コンソーシアムブロックチェーンシステムであって、トランザクションデータと、ゼロ知識証明値を生成するための生成鍵と、を保持する第１計算機と、前記ゼロ知識証明値を検証するための検証鍵を保持する第２計算機と、を含み、前記第１計算機は、前記生成鍵を用いて前記トランザクションデータに基づくゼロ知識証明値を生成し、前記生成したゼロ知識証明値を、前記第２計算機に送信し、前記第２計算機は、前記第１計算機から送信されたゼロ知識証明値を、前記検証鍵を用いて検証し、前記トランザクションデータを受信し、前記ゼロ知識証明値の検証結果に基づいて前記トランザクションデータが示すトランザクションを承認又は拒否する、コンソーシアムブロックチェーンシステムである。

【0021】

上述の特許文献１に記載の技術においては、ＢＣを用いて各組織から運用エビデンスを収集する手段が開示されているものの、ＢＣの特性のまま、当該エビデンスは常時全組織に公開される前提となっている。

【0022】

また、特許文献２においては、ゼロ知識証明、すなわち自分の持っている命題(秘匿情
報に関係する)が真であることを証明する際、真であること以外は何の知識も伝えずに証
明が可能であるプロトコルを利用した技術が開示されている。確かに有用な技術であるがまだ発展途上であり、現実的なソリューションとして採用しにくい現状にある。

【0023】

なお、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃの機能として、プライベートデータなるものが存在し、特定の小グループ内での秘匿情報（上述のエビデンスが該当）について、そのハッシュ値だけをＢＣに格納する運用は可能である。ただし、本人しかアクセスできない秘匿情報の場合、他者にとってその真正性や取扱いの正しさが確認できず、そのまま組織横断の集計等には利用できない。

【0024】

そこで本発明の目的は、組織を跨いだ透明性ある適宜なエビデンスの収集/集計におい
て、組織間でのエビデンス開示のタイミングを、非中央集権的に制御可能とする技術を提供することにある。

【課題を解決するための手段】

【0025】

上記課題を解決する本発明のエビデンス管理方法は、複数組織のノードで構成される分散台帳システムにおいて、各組織のスマートコントラクトは、前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行する、ことを特徴とする。
なお、上述のプライベート領域は、他組織が参照できない状態でデータを保持可能な状態を、また、パブリック領域は、他組織も参照できる状態でデータを保持可能な状態、を意味しており、データ格納の場所や装置を切り分けて確保した特定の記憶領域のみを指すことは意図していない。
また、本発明のエビデンス管理システムは、複数組織のノードで構成されるエビデンス管理システムであって、各組織のスマートコントラクトは、 前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行するものである、ことを特徴とする。

【0026】

また、本発明のノードは、分散台帳システムを構成する、複数組織のノードのいずれかであって、前記複数組織それぞれのプライベート領域で保持されるエビデンスに関して、パブリック領域に公開された情報を参照し、当該情報が所定条件を達成することを契機に
、自組織の前記プライベート領域で保持されている前記エビデンスを、前記パブリック領域に公開するための処理を実行するスマートコントラクトを保持するものである、ことを特徴とする。

【発明の効果】

【0027】

本発明によれば、組織を跨いだ透明性ある適宜なエビデンスの収集/集計において、組
織間でのエビデンス開示のタイミングを、非中央集権的に制御可能となる。

【図面の簡単な説明】

【0028】

【図1】本実施形態におけるコンピュータシステムの構成例を示す図である。

【図2】本実施形態におけるノードの物理的な構成例を示すブロック図である。

【図3】分散台帳上のブロックチェーンのデータ構造例を示す図である。

【図4】分散台帳上のステート情報のデータ構造例を示す図である。

【図5A】電子記名投票に関してプライベート領域で保持するエビデンス例を示す図である。

【図5B】電子記名投票に関してプライベート領域で保持するエビデンス例を示す図である。

【図5C】電子記名投票に関してパブリック領域で公開しているエビデンスの情報例を示す図である。

【図5D】電子記名投票に関してパブリック領域で公開している集計結果例を示す図である。

【図6A】運用実行履歴に関してパブリック領域で保持する運用作業定義例を示す図である。

【図6B】運用実行履歴に関してプライベート領域で保持するエビデンス例を示す図である。

【図6C】運用実行履歴に関してプライベート領域で保持するエビデンス例を示す図である。

【図6D】運用実行履歴に関してパブリック領域で公開しているエビデンスの情報例を示す図である。

【図6E】運用実行履歴に関してパブリック領域で公開している集計結果例を示す図である。

【図7】本実施形態におけるエビデンス管理方法のフロー例を示す図である。

【図8】本実施形態におけるエビデンス管理方法のフロー例を示す図である。

【図9】本実施形態におけるエビデンス管理方法のフロー例を示す図である。

【図10】本実施形態のエビデンス管理スマートコントラクトの例を示す図である。

【図11】本実施形態におけるＳａｌｔ生成方法の概念を示す図である

【発明を実施するための形態】

【0029】

＜概要＞
図１に、本実施形態におけるコンピュータシステムとして、分散台帳システム１０とエージェントノード５を含む構成例を示す。本実施形態においては、分散台帳システム１０が、エージェントノード５との連携が必要な場合を前提とする。また、その連携に際し、分散台帳システム１０とエージェントノード５との接続パスを単一組織に依存しないように複数用意するものとする。

【0030】

さらに、複数組織における、システム運用や電子投票、入札などの所定業務に関するエビデンスの保持状況に応じて、各組織のプライベート領域で保持しているエビデンスをパブリック領域たるブロックチェーン（以下、ＢＣと称する）に自動移行する方法をエビデンス管理スマートコントラクト（以下、エビデンス管理ＳＣと称する）として規定する。

【0031】

また、分散台帳システム１０をクライアントノード４と共に構成する各分散台帳ノード３に対して、エビデンス公開開始要求としてエビデンス管理ＳＣの実行ＴＸが発行されると、当該分散台帳システム１０を介して、このエビデンス管理ＳＣ＿Ｄ１１にて定義された、エビデンス公開ルールに従って、各組織それぞれの分散台帳Ｄ１におけるプライベート領域Ｄ１１２で保持されるエビデンスに関して、パブリック領域Ｄ１１１たるＢＣに公開された情報を参照し、当該情報が所定条件を達成することを契機に、自組織のプライベート領域Ｄ１１２で保持されているエビデンスを、ＢＣ（パブリック領域Ｄ１１１）に公開するための処理を実行する。

【0032】

ここで、本実施形態における処理概要は以下のとおりとなる。

【0033】

１．エビデンス管理ＳＣを分散台帳Ｄ１上に配置する。エビデンス管理ＳＣは以下を含む。Ａ）エビデンス公開開始の条件の定義、Ｂ）エビデンスの集計処理方法（例：集計ロジック）の定義。

【0034】

２．エビデンス管理ＳＣは、組織それぞれの分散台帳ノード３のプライベート領域Ｄ１１２で保持されるエビデンスに関して、パブリック領域Ｄ１１１に公開された情報（例：組織ＩＤと、当該組織で得たエビデンス及びＳａｌｔを併せた値のハッシュ値）を参照し、一定数以上の組織からエビデンスの情報が公開されているといった条件が達成されることを契機に、自組織のプライベート領域Ｄ１１２で保持されているエビデンスを、パブリック領域Ｄ１１１に公開するため、エビデンスの公開開始イベントを発行する。

【0035】

３．エビデンス管理ＳＣは、上述の公開開始イベントの発行後、エビデンスに関する情報の、パブリック領域Ｄ１１１への公開又は当該情報の更新を拒否するか、或いは公開開始イベントの発行後に公開又は更新されたタイミングの情報を当該情報に付与する。

【0036】

４．エビデンス管理ＳＣは、パブリック領域Ｄ１１１に公開された各組織のエビデンスを用いて、エビデンスの集計を実行する。

【0037】

５．エビデンス管理ＳＣは、公開開始の契機に際し、エビデンス公開開始の仮イベントを発行する。

【0038】

６．エビデンス管理ＳＣは、各組織それぞれにおける、エビデンスのパブリック領域Ｄ１１１への公開に伴い、当該公開の状況が所定条件を満たした場合、データ処理開始の仮イベントを発行する。

【0039】

また、分散台帳システム１０とエージェントノード５との間での連携を行う際の処理概要は以下のとおりである。

【0040】

１．スマートコントラクトが、公開するための処理として、エビデンスの公開開始イベントを発行した際、エージェントノード５がこれを受け、エビデンスのパブリック領域Ｄ１１１への公開を実行する。

【0041】

２．エージェントノード５は、上述の公開に際し、あらかじめ決められた条件（例えばエビデンス管理SCごとに、あるいは集計回数ごとに定まる）で生成された所定数の組織のサブグループを用いて、当該サブグループ内でエビデンスの公開及びデータ処理を実行し、当該データ処理の結果を他のサブグループに公開する。さらに、サブグループ内の集計結果を用いて、データ処理を行う。これは多段に行ってもよく、あるいはサブグループなし(全組織)で行ってもよい。

【0042】

３．スマートコントラクトが、エビデンス公開のための処理として、エビデンスの情報のパブリック領域への登録を行った組織数が一定レベル以上となったなどの契機に応じて、エビデンス公開開始の仮イベントを発行した場合、エージェントノード５は、その仮イベントを受けて、各組織の間での合意形成を経てエビデンスの公開開始を確定させ、公開開始イベントを発行する。

【0043】

４．同様に、スマートコントラクトが、各組織それぞれにおける、エビデンスのパブリック領域Ｄ１１１への公開に伴い、パブリック領域へのエビデンス公開を行った組織数が一定レベル以上となったなど、当該公開の状況が所定条件を満たしたことに応じ、データ処理開始の仮イベントを発行した場合、エージェントノード５は、その仮イベントを受けて、複数組織の間での合意形成を経て、データ処理を行う。
＜ネットワーク構成例＞
以下、図１に基づき本実施形態にて想定するコンピュータシステムの構成について例示する。図１で示すコンピュータシステムは、１台以上の分散台帳ノード３、１台以上のクライアントノード４、およびエージェントノード５によって構成される。また、これらの機器は、物理的な通信回線２を通してネットワーク１に接続される。

【0044】

このうち分散台帳ノード３は、コンセンサス管理部３１、スマートコントラクト実行／管理部３２（以下、ＳＣ実行／管理部３２とも称する）、メンバー管理部３３、トランザクション管理部３４、トランザクション発行部３５、承認済トランザクション配信部３６、ネットワークプロトコル部３７、分散台帳Ｄ１、構成情報Ｄ２、および参加メンバー管理情報Ｄ３によって構成される。

【0045】

また分散台帳ノード３は、トランザクション管理部３４の機能によりＴＸを受け付けて、コンセンサス管理部３１の機能によって、他のノードとの間でＴＸを受け入れてよいかの合意形成を行う。この結果、合意形成がなされた場合、分散台帳ノード３は、ＳＣ実行／管理部３２の機能を介して、ＳＣのデプロイ、デプロイ済みのＳＣに対する実行を行い、ＴＸの履歴とその実行結果を分散台帳Ｄ１に記録する。

【0046】

ここで、合意形成やＳＣ実行は、必ずしも全ての分散台帳ノード３が行う必要はなく、一部の分散台帳ノード間で行ってその結果を他ノードに配信してもよい（その取り決めは合意形成アルゴリズムにも依存する）。

【0047】

そのため、承認済トランザクション配信部３６は、上述の合意形成やＳＣ実行に参加しなかった分散台帳ノード３に対してその結果（具体的には、ＴＸの履歴と実行結果）を配信する機能を提供する。

【0048】

ここで、分散台帳ノード３の間での合意形成や承認済ＴＸの配信といった分散台帳ノード３間の通信は、ネットワークプロトコル部３７の機能によって行う。

【0049】

また、分散台帳ノード３のトランザクション管理部３４は、クライアントノード４等の各ノードからの要求に対して、ＴＸを受け付ける機能／インターフェイスや、ＴＸの履歴情報を取得・閲覧する機能／インターフェイスを提供する。

【0050】

なお、本実施形態では、分散台帳ノード３（のエビデンス管理ＳＣＤ１１の指示を受けたトランザクション発行部３５）、及びクライアントノード４（のトランザクション発行部４２）がＴＸ発行可能であることとる。

【0051】

また、分散台帳ノード３のメンバー管理部３３は、分散台帳ネットワーク（分散台帳システム）に参加するメンバーの新規発行や認証機能を提供する。メンバー管理部３３では
、秘密鍵と公開鍵のペアを用いて、参加組織ならびにその組織に所属するメンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。こうしたメンバー管理に関する鍵情報は、参加メンバー管理情報Ｄ３上に格納・管理される。

【0052】

また、トランザクション管理部３４は、ＴＸを受け付けた際に、適宜、メンバー管理部３３の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認するものである。ただし、こうした機能等は公知技術であるため、詳細説明を省略する。

【0053】

なお、構成情報Ｄ２では、分散台帳ネットワークを構成する組織やその組織に属するメンバー（ノード、管理者、ユーザなどを含む）の情報を格納・管理する。本実施形態では本情報が分散台帳ノード３の機能の中で（例えば、メンバー管理部３３やネットワークプロトコル部３７）管理され、各ノードが互いに保持していることを想定できる。

【0054】

また、分散台帳上Ｄ１では、エビデンス管理スマートコントラクトＤ１１に関わる台帳情報を格納・管理する。そのデータ構造としては、本実施形態では、ＴＸの履歴をＢＣとして、ＴＸの実行結果に基づくステート情報をテーブル上で保持することを想定する。その内部テーブルではＫｅｙ－Ｖａｌｕｅの組として値を保持する想定である。

【0055】

ただし、エビデンス管理スマートコントラクトＤ１１に関わる台帳情報は、パブリック領域Ｄ１１１とプライベート領域Ｄ１１２の２つの領域のいずれかで保持、管理されており、パブリック領域Ｄ１１１がＢＣに該当する。このパブリック領域Ｄ１１１には、本実施形態におけるエビデンスに関する情報（例：エビデンスとＳａｌｔを併せた値のハッシュ値）が組織のＩＤと紐付けて格納される。

【0056】

一方、プライベート領域Ｄ１１２は、分散台帳ノード３の運用者たる組織にてセキュアに管理されるデータの格納領域である。つまり、本実施形態におけるエビデンスそのものが格納される領域となる。プライベート領域Ｄ１１２は、すなわち他組織が参照できない状態）で保持されていると言い換えることもでき、実現方法は様々ある。そして、組織ごとに管理されていて、エビデンス管理スマートコントラクトＤ１１を介して公開可能であれば、分散台帳Ｄ１の外にあってもかまわない。たとえば、Hyperledger Fabricの場合にはプライベートデータ機能を使って、単一組織のみが参照可能なプライベートデータを要しして実現してもよい。それ以外では、あるいは、組織毎に用意された分散台帳Ｄ１外部のストレージに格納してもかまわない。あるいは、他の組織の知らない秘密鍵で一旦暗号化したうえでパブリック領域に格納して、後でその秘密鍵を他組織に公開することで複合する形でもかまわない。

【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】

また、図５Ｄは、上述のパブリック領域Ｄ１１１に自動移行されたエビデンスの値を集計した集計結果例を示す。図５Ｄの例では、「投票１」の事案に関して、「賛成：１０、反対：３、棄権：２」であり、賛成多数により「可決」と判定した状態を示し、「投票２」の事案に関して、「賛成：３、反対：７、棄権：２、未投票：３」であり、反対多数により「否決」と判定した状態を示している。

【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】

この承認済ＴＸを受け取ったコンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、当該ＴＸに含まれるエビデンス管理ＳＣ＿Ｄ１１を分散台帳Ｄ１に登録する（Ｓ２０４）。具体的には、ＴＸの内容に基づき、ＳＣ＿ＩＤやＳＣ実態を分散台帳Ｄ１上のステート情報として登録し、ＢＣの末尾に、このデプロイＴＸを含むブロックを追加する。

【0124】

最後に、コンセンサス管理部３１は、デプロイＴＸの実行結果をＴＸ発行元に返す（Ｓ２０５）。

【0125】

受け取ったＴＸがエビデンス管理ＳＣ＿Ｄ１１の実行ＴＸの場合（Ｓ２０２の判定が「ＮＯ」の場合）について説明する。この場合にもデプロイＴＸと同様に合意形成処理を行う（Ｓ２０６）。この合意形成処理はＳ２０７と同様である。

【0126】

上述の合意形成が完了した場合、コンセンサス管理部３１は、ＳＣ実行／管理部３２を介して、エビデンス管理ＳＣ＿Ｄ１１を実行して分散台帳Ｄ１の内容を更新する（Ｓ２０７）。具体的には、実行ＴＸ内で指定されたＳＣ＿ＩＤを持つエビデンス管理ＳＣ＿Ｄ１１（登録済みであることを前提とする）に対して、実行ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。

【0127】

そして、コンセンサス管理部３１は、その実行結果に基づき、分散台帳Ｄ１の内容を更新する。実行結果に基づいて、本エビデンス管理ＳＣ＿Ｄ１１に関するステート情報Ｄ１２を更新し、ＢＣの末尾のブロックとして実行ＴＸを追加する。最後に、コンセンサス管理部３１は、この実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返す（Ｓ２０９）。
＜エビデンス管理ＳＣのフロー＞
図９は、エビデンス管理ＳＣ＿Ｄ１１における処理例を示すフロー図であり、図１０はエビデンス管理ＳＣ＿Ｄ１１の内部構成を示す図である。この場合、各分散台帳ノード３は、例えば、クライアントノード４が発行した実行ＴＸにより、エビデンス管理ＳＣ＿Ｄ１２のＳＣ関数「エビデンス登録」呼び出しを受ける（Ｓ３０１）と、ＳＣ実行／管理部
３２の機能によって、本実行ＴＸに従ったエビデンス登録処理の実行を行う。

【0128】

続いて、各分散台帳ノード３のエビデンス管理ＳＣ＿Ｄ１１は、クライアントノード４のトランザクション発行部４２からブロードキャストされたＴＸが含むエビデンス及びＳａｌｔを、分散台帳Ｄ１のプライベート領域Ｄ１１２に格納する（Ｓ３０２）。

【0129】

なお、クライアントノード４における、トランザクション生成部４３でのＴＸ生成、トランザクション発行部４２でのＴＸ発行の各処理については、既に説明したとおりである（図１１）。

【0130】

また、分散台帳ノード３のエビデンス管理ＳＣ＿Ｄ１１は、Ｓ３０２で得たエビデンス及びＳａｌｔを併せてハッシュ関数に入力して、ハッシュ関数を生成し、これをエビデンスハッシュ値としてパブリック領域Ｄ１１１に公開する（Ｓ３０３）。この時、エビデンスハッシュ値は、組織ＩＤおよび対象事象のＩＤ（投票ＩＤ、運用ＩＤなど）と紐付けてステート情報に格納される。

【0131】

各組織の分散台帳ノード３において、上述のＳ３０１～Ｓ３０３が実行されることで、分散台帳Ｄ１のパブリック領域Ｄ１１１には、各組織から公開されたエビデンスハッシュ値を含むレコードが蓄積されることになる。

【0132】

分散台帳ノード３のエビデンス管理ＳＣ＿Ｄ１１は、分散台帳Ｄ１のパブリック領域Ｄ１１１に公開された情報を参照し、例えば、一定数以上の組織からエビデンスハッシュ値（エビデンスに関する情報）が公開されているか判定する（Ｓ３０４）。

【0133】

上述の判定の結果、一定数以上の組織により、エビデンスハッシュ値が公開されていることが判明した場合（Ｓ３０４：Ｙｅｓ）、エビデンス管理ＳＣ＿Ｄ１１は、エビデンスの公開開始イベントを発行する（Ｓ３０５）。ＳＣイベントによって発行されるイベントは、BC内に埋め込まれ、BCを受け取った分散台帳ノード３が当該組織のエージェントノード５に通知する。

【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】

１ ネットワーク
２ 物理的な通信回線
３ 分散台帳ノード
１０ 分散台帳システム（エビデンス管理システム）
１００ Ｉ／Ｆ
１０１ プロセッサ
１０２ メモリ
１０３ データバス
３１ コンセンサス管理部
３２ スマートコントラクト実行／管理部（ＳＣ実行／管理部）
３３ メンバー管理部
３４ トランザクション管理部
３５ トランザクション発行部
３６ 承認済トランザクション配信部
３７ ネットワークプロトコル部
４ クライアントノード
４１ 業務アプリ
４２ トランザクション発行部
４３ トランザクション生成部
４３１ Ｓａｌｔ生成部
５ エージェントノード
５１ エージェントプログラム
５１１ イベント受信部
Ｄ１ 分散台帳
Ｄ１１ エビデンス管理スマートコントラクト
Ｄ１１１ パブリック領域
Ｄ１１２ プライベート領域
Ｄ２ 構成情報
Ｄ３ 参加メンバー管理情報

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図6A】

【図6B】

【図6C】

【図6D】

【図6E】

【図7】

【図8】

【図9】

【図10】

【図11】