JP7025365B2 - データ連携管理方法、データ連携管理システム、およびノード - Google Patents

Description

本発明は、データ連携管理方法、データ連携管理システム、およびノードに関するものである。

従来、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた取引を、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって直接的な取引に代替する技術として、分散台帳技術が登場している。

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

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

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

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

分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）。
以降では分散台帳に参加する参加者（およびそのノード）によって構成されるネットワークのことを分散台帳ネットワークと呼ぶ。

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

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

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

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

分散台帳技術を用いて構築したシステム（以下、分散台帳システム）では、その実用の一形態として、外部システム（特に非分散台帳システム）を介在してデータを入出力するユースケースが想定される。

例えば、外部システムで生成／管理されるデータを分散台帳システムに流し込み、複数組織内で共有するケースがあげられる（データの流れ：外部データ取得→分散台帳）。

この具体例としては、外部生成される、温度などのＩｏＴセンサデータや自動車の走行データを分散台帳に取り込んで、その値に応じて契約執行（温度や速度超過の罰金）を行うケースなどが想定できる。

また別の例としては、ある目的に対して、コンソーシアムの参加者が外部システムで分析した結果を分散台帳システムに登録し、当該コンソーシアムの複数組織内でそのデータに基づいて、何らかの処理や判断を行うケースもあげられる。

この具体例としては、分散台帳上に蓄積された取引データや決済データを入力に、顧客や企業の優良スコアを分析する場合に、分析処理用の外部システムを用いてＡＩ（人工知能）などを用いた複雑な分析を行い（非分散台帳での処理）、その結果を再び分散台帳に格納するケースがあげられる（データの流れ：分散台帳→外部データ処理→分散台帳）。

あるいは、優良スコア問合せのみを分散台帳を介して行い、個々の組織の持つ外部システムに蓄積されたデータと分析機構を用いて分析処理を行って、その結果を分散台帳システムに格納するケースなども想定される（データの流れ：外部データ処理→→分散台帳）。

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

特開２０１７－２０４７０７号公報

上述のような、非分散台帳システムとの連携を伴う分散台帳システムにおけるユースケースでは、非中央集権での処理機構によって信頼性／安全性を担保する分散台帳システムの外側で処理が行われる。

そのため、外部システムを介在して処理／登録されるデータに関する安全性が低下する（信頼性低下、不正リスク発生）。例えば、単一組織によって外部システムを介したデータ処理や入力が発生する場合、その組織が単一信頼点になる。

これに対して、データ生成方法自体を組織間で共通化し、データ生成時にデータのハッシュ値と、データに付随するメタデータ（ＧＰＳ，端末情報など）を分散台帳に登録することで、データの真正性を保証する技術が提案されている（特許文献１参照）。この例では、データ生成方法に手を加えられる前提であれば真正性を保証可能である。

しかし、必ずしも外部システムのデータ生成部に手を加えられるとは限らない。そのため、適用範囲が限られるという問題がある。また、この例では、共通化したデータ生成方法／データ分析方法を管理する中央組織を必要とする。これは分散台帳システムの非中央集権の特徴を十分に生かしきれないという問題につながる。

また別の方法として、既に述べた非特許文献２および３などのような従来の分散台帳／ＳＣの仕組みを応用し、複数組織がそれぞれ外部システムに接続するパスを用意し、複数組織がそれぞれ外部システムからデータを取得して、その合意形成ができれば、単一組織による不正を防止可能である。

しかしながら、非特許文献２および３などの現行の分散台帳では、非決定的な処理を含むＴＸを扱うことができない。ここで非決定的な処理とは、ノードや実行タイミングによって結果が異なる処理のことである。

この場合、分散台帳では複数のノードが並列して共通処理を行うために、非決定的なＴＸがあるとノード間で状態／計算結果がずれてしまい、大きな問題となる。

つまり、各組織が取得するデータが完全一致していなければ、個々の計算結果がずれて合意に失敗（非決定的処理と呼ばれる）する。そのため、複数組織が取得できたとしても、外部システムデータの取得タイミング／手段／権限などによって、ズレやばらつきが発生し得る。そのため適用困難という問題がある。

そこで本発明の目的は、分散台帳システムと非分散台帳システムとの間の効率的なデータ連携を、単一組織に依存せず、かつ客観性をもって実施可能とする技術を提供することにある。

上記課題を解決する本発明のデータ連携管理方法は、複数のノードで構成される分散台帳システムにおいて、前記複数のノードのうち少なくとも所定の複数組織の各ノードは、前記各ノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成する、ことを特
徴とする。

また、本発明のデータ連携管理システムは、複数のノードで構成される分散台帳システムであって、前記複数のノードのうち少なくとも所定の複数組織の各ノードは、前記各ノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成するものである、ことを特徴とする。

また、本発明のノードは、分散台帳システムを構成する複数のノードのいずれかであって、前記複数のノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成するものである、ことを特徴とする。

本発明によれば、分散台帳システムと非分散台帳システムとの間の効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

実施例１におけるコンピュータシステムの構成例を示す図である。 実施例１におけるノードの物理的な構成例を示すブロック図である。 分散台帳上のブロックチェーンのデータ構造例を示す図である。 分散台帳上のステート情報のデータ構造例を示す図である。 構成情報のデータ構造例を示す図である。 データ連携ＳＣのデータ構造および処理内容を示す図である。 データ連携ＳＣのステート情報として管理されるデータ連携調整／収束ルールを示す図である。 データ連携調整／収束ルールのデータ取得処理の例１を示す図である。 データ連携調整／収束ルールのデータ取得処理の例２を示す図である。 データ連携ＳＣのステート情報として管理される登録データを示す図である。 データ連携ＳＣのイベントとして発行される連携処理イベントを示す図である。 分散台帳ネットワークに参加するメンバーの新規登録処理例を示すフロー図である。 ＳＣのトランザクション処理例を示すフロ図である。 実施例１における、システム全体としてのデータ連携ＳＣに従ったデータ連携処理の例１を示すシーケンス図である。 実施例１における、システム全体としてのデータ連携ＳＣに従ったデータ連携処理の例２を示すシーケンス図である。 データ連携ＳＣの内部処理例を示すフロー図である。 外部連携エージェントの処理例を示すフローチャートである。 実施例２におけるコンピュータシステムの構成例を示す図である。 実施例３における、データ連携ＳＣのステート情報として管理されるデータ連携成否結果を示す図である。 実施例３における、データ連携ＳＣのステート情報として管理されるデータ連携信用分析結果を示す図である。 実施例３におけるデータ連携信用分析処理の例を示すフロー図である。

＜実施例１＞

図１に、実施例１におけるコンピュータシステムとして、分散台帳システム１０と外部システム５を含む構成例を示す。実施例１においては、分散台帳システム１０が、外部システム５（主には非分散台帳システム）とのデータ連携が必要な場合を前提とする。また、そのデータ連携に際し、分散台帳システム１０と外部システム５との接続パスを単一組織に依存しないように複数用意するものとする。

さらに、複数組織による、外部システム５を介したデータ入出力結果に対するデータの許容範囲（データ間での値のぶれの許容範囲）とその収束方法（データ連携調整／収束ルールと呼ぶ）をデータ連携ＳＣ（共通フレームワーク）として規定する。

また、分散台帳システム１０を構成するノード（以下、分散台帳ノード３）に対して、データ連携要求としてデータ連携ＳＣの実行ＴＸが発行されると、当該分散台帳システム１０を介して、このデータ連携ＳＣ＿Ｄ１２にて定義されたデータ連携調整／収束ルールに従って、外部システム５を介するデータ取得／処理が実施される。そして、その結果がある一定の幅の中で一意なデータとして収束する。

上述の収束等の各処理は、複数の分散台帳ノード３上でのＳＣ機能で管理されるため、コンソーシアム（分散台帳ノード３をそれぞれ運用する複数の組織から構成）の取り決めに従って、単一組織に寄らず外部データを連携でき、業務（ＳＣ）レイヤでの合意形成に基づいた非決定的なデータの取り扱いを実現することができる。
ここで、本実施例における処理概要は以下の通りとなる。
１．データ連携ＳＣを（業務やデータごとに）定義し、分散台帳Ｄ１上に配置する。データ連携ＳＣは以下を含む。
－外部連携処理組織の選定（と各データ取得）方法の定義。
－処理結果に対する許容範囲と収束方法（例：集約ロジック）の定義。

２．データ連携ＳＣに対する要求ＴＸが発行されると、当該データ連携ＳＣは、当該要求ＴＸを受けて複数組織に対する連携処理を依頼する。またデータ連携ＳＣは、当該複数組織が外部システムを介して取得／処理した結果を仮のデータエントリとして分散台帳Ｄ１に登録する。それらの複数の仮のデータエントリについて、合意組織数が所定の合意基準を満たし、かつ、当該データの値が許容範囲内であるかを判定し、各基準を満たした場合に複数エントリを収束させた一意な値を計算し、確定データとして分散台帳Ｄ１に登録する。
また、分散台帳システム１０と外部システム５との間でのデータ連携を行うパターンとしては主に以下が想定される。
・データの流れ：外部データ取得→分散台帳。

－例１：外部生成されるメータリングデータ（ＩｏＴセンサデータや自動車の走行データ）を分散台帳Ｄ１に取り込んで、その値に応じて契約執行（温度や速度超過の罰金）を行う。

なお、メータリングＡＰＩのコンソーシアム公開、同一観測対象に対する複数個のセンサ配置、周辺自動車からのモニタリングなどによって、複数参加者からのデータ取得パスを用意可能である。この場合にもＡＰＩ経由の取得タイミングによるズレやセンサーが異なることによるズレやばらつきが発生し得る。

－例２：クラウドサービスのメータリングデータを分散台帳に取り込んで、その値に応じて課金額やＳＬＡ（Service Level Agreement）順守状況を管理する。メータリングＡＰ
Ｉやサービス利用履歴ＡＰＩ、ログ参照ＡＰＩを公開することで、複数参加者のデータ取得パスを用意可能である。この場合にもＡＰＩ経由の取得タイミング、権限、取得手段によってズレやばらつきが発生し得る。
・データの流れ：分散台帳→外部データ処理→分散台帳。

－例：分散台帳Ｄ１上に蓄積された取引データや決済データを入力として、分析処理用の外部システム５（例：ＡＩ）など顧客や企業の優良スコアを分析する。単一組織が分析するだけでは正しい入出力がされたか不明なため、複数組織によって分析を行うことが望ましい。一方、ＡＩなどを用いた複雑な分析処理は、学習や実行時の乱数のズレなどにより、同一の入力データを用いても結果が若干ずれることがある。
・データの流れ：外部データ処理→分散台帳。

－例：優良スコア問合せのみを分散台帳Ｄ１を介して行い、個々の組織の持つ外部システム５に蓄積されたデータと分析機構を用いて分析処理を行って、その結果を分散台帳システム１０に格納するケースなども想定される。この場合には、各組織で用いるデータや処理内容はブラックボックス化されているため、結果がずれたり、ばらついたりすることが想定される。

本実施例におけるデータ連携管理技術は上記いずれのケースでも適用可能である。なお、本実施例の技術は以下のすべてが該当するケースで特に有効に活用することができる。・適用条件１：外部システム５を経由（してデータ処理）した結果を、分散台帳システム１０に登録する
・適用条件２：各組織によって処理／取得された複数データエントリを１エントリとして登録したい。
・適用条件３：データが厳密に完全一致しなくてもある程度の範囲内で決まれば支障がない（重要度が安全性（不正防止／信頼性）＞＞誤差である）。
－－－ネットワーク構成例－－－

以下、図１に基づき実施例１で想定するコンピュータシステムの構成について例示する。図１で示すコンピュータシステムは、１台以上の分散台帳ノード３、１台以上のクライアントノード４、および外部システム５（非分散台帳）によって構成される。また、これらの機器は、物理的な通信回線２を通してネットワーク１に接続される。

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

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

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

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

また、分散台帳ノード３のトランザクション管理部３４は、クライアントノード４等の各ノードからの要求に対して、ＴＸを受け付ける機能／インターフェイスや、ＴＸの履歴情報を取得・閲覧する機能／インターフェイスを提供する。
なお、本実施例では分散台帳ノード３がＴＸ発行可能であることとし、トランザクション発行部３５を介して各種ＴＸを発行する。

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

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

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

また、分散台帳上Ｄ１では、業務に関するＳＣ（以下、業務ＳＣ＿Ｄ１１）、外部システム５とのデータ連携に関するＳＣ（以下、データ連携ＳＣ＿Ｄ１２）に関わる台帳情報を格納・管理する。

そのデータ構造としては、本実施例では、ＴＸの履歴をＢＣとして、ＴＸの実行結果に基づくステート情報をテーブル上で保持することを想定する。その内部テーブルではＫｅｙ－Ｖａｌｕｅの組として値を保持する想定である。

一方、クライアントノード４は、トランザクション発行部３５、業務アプリ４１、外部システム連携部４２、外部連携エージェント４３、およびイベント受信部４４によって構成される。

ＳＣの利用者もしくは提供者は、クライアントノード４のトランザクション発行部３５を介して、各種ＴＸを発行して分散台帳ノード３に対して送信する。なお、ＴＸには発行者情報を付与するが、この情報としては参加メンバー管理情報Ｄ３によって発行された認証情報（秘密鍵）を利用する。
また、業務アプリ４１は、トランザクション発行部３５を介して、業務ＳＣ＿Ｄ１１に関するＴＸを発行することで、業務処理を実行／管理するアプリである。

また、外部システム連携部４２は、外部システム５に外部システムＡＰＩ５１を介してアクセスして、外部システム５を用いた処理やデータ取得を行う。また、外部システム連
携部４２は、トランザクション発行部３５を介して、上述の処理やデータ取得等の結果を用いて、データ連携ＳＣ＿Ｄ１２に関するＴＸを発行する。このことで、外部システム５と分散台帳システム１０との間のデータ連携を実現する。

また、外部システム連携部４２は、業務アプリ４１や外部連携エージェント４３によって利用される。外部連携エージェント４３は、イベント受信部４４を介して分散台帳ノード３からの連携処理イベントを受信して、そのイベントに従って外部システム連携部４２を介したデータ連携を行う。なお、組織の役割によっては、クライアントノード４が外部システム５に関する機能（外部システム連携部４２、外部連携エージェント４３、イベント受信部４４）を備えずともよい。

本実施例では、分散台帳ノード３が複数台存在し、複数の主体（例えば、複数の事業者／複数の組織／複数のベンダ）によって分散台帳ノード３がそれぞれ管理されることを想定する。

同様に、クライアントノード４も複数台存在し、複数のＳＣ利用者がそれぞれ別のクライアントノード４を利用することを想定する。なお、クライアントノード４に関しては、ＴＸに付与する認証情報をユーザ毎に切り替えることにより、複数のＳＣ利用者が共用することも可能である。
－－－ハードウェア構成－－－

図２は、実施例１における分散台帳ノード３あるいはクライアントノード４の物理的な構成を示すブロック図である。ここでは分散台帳ノード３を例に挙げて説明するものとする。

分散台帳ノード３は、インターフェイス（Ｉ／Ｆ）１００、プロセッサ１０１、およびメモリ１０２を備える計算機である。これらＩ／Ｆ１００、プロセッサ１０１、メモリ１０２はデータバス１０３によって接続される。

分散台帳ノード３は、Ｉ／Ｆ１００を介して、ネットワーク１と通信する。また、プロセッサ１０１は、ＣＰＵ等の演算装置である。また、メモリ１０２は、プログラムおよびデータを保持するための記憶領域である。

また、プロセッサ１０１は、メモリ１０２からデータバス３４を介してプログラムを読み出して実行し、必要な機能を実装する。この機能とは、上述のコンセンサス管理部３１～ネットワークプロトコル部３７等が該当する。
－－－データ構成例－－－
図３および図４は、分散台帳Ｄ１に格納するデータ構造の一例である。図３は、分散台帳Ｄ１上で管理するデータ構造の一つであるＢＣの例である。

ＢＣを用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変わるため、改ざんを困難にすることができる。

なお、本実施例では説明をシンプルにするために、１つのＴＸにつき、１ブロックとするが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。

また、本実施例では各ＳＣ（Ｄ１１～Ｄ１２）が単一のＢＣとして連なっているが、参加組織がそれぞれ管理／参照可能であればＢＣ自体は別々であっても構わない。逆に、各
ＳＣを別々にしているが同等の機能セットがあれば同一のＳＣ内で定義されていてもよい。

図３におけるＤ１０００～Ｄ１００６は一連のブロックの連なりとなる。各ブロックは、それぞれ業務ＳＣのデプロイ、実行、データ連携ＳＣのデプロイ、実行、いずれかのＴＸ情報を含む。各ブロックは前ブロックのハッシュ値を含み、後述のステート情報から生成したハッシュ値を含む。
上記のようなデータ構造により、業務ＳＣのデプロイ、実行、データ連携ＳＣのデプロイ、実行のＴＸ履歴がＢＣ中でデータの連鎖として管理される。

上述のブロックのうちＤ１０００は、業務ＳＣのデプロイＴＸを格納したブロックの一例である。この例では、「業務Ｂ」として複数企業／組織間での商取引（仮想通貨取引）に関するビジネスコントラクトの例を示している。

本実施例のデプロイＴＸは、ＴＸが発行されたタイムスタンプ、ＳＣが業務かデータ連携かを特定するＳＣ種別、ＳＣを一意に識別するＳＣ＿ＩＤ、ＴＸがデプロイか実行か参照かを特定するＴＸ種別、ＳＣの実体（例えば実行可能なバイナリ）を含む。また、ＳＣが持つ関数名やその引数を利用者が把握するためのＳＣ入力仕様を含む。

さらに、デプロイ時に指定した入力引数にしたがって決めたパラメータ（例えばこのＳＣの実行時における合意形成条件（例：３組織以上の承認を持ってＴＸを受け入れる）や各種定義情報等）であるＳＣメタ定義を含む。

また、こうしたＴＸは当該ＴＸの発行者の情報を含む。ＴＸ発行者の情報は、発行者のメンバーＩＤ情報と発行元とデータに改ざんが無いことを検証するために用いる電子署名情報とを含む。

この電子署名は、メンバー管理部３３が発行した各ネットワーク参加メンバー（すなわちＳＣ提供者や利用者）の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。

ＴＸ発行者の情報と同様に、ＴＸ実行／承認者（言い換えると、コンセンサス管理部３１、ＳＣ管理／実行部３２を用いた合意形成ならびにＳＣ実行処理に関わった参加者の情報）の情報や承認済ＴＸ配信者（言い換えると、承認済ＴＸ配信部３６による配信処理に関わった参加者の情報）の情報も含む。

さらに本ＴＸで参照／更新を行ったステート情報であるＲｅａｄ－Ｗｒｉｔｅ（ＲＷ）セットの情報も含む。ＲＷセットについては後述の実行ＴＸの説明にて詳細に述べる。ここで、以降では、ＳＣが持つ関数のことをＳＣ関数とも称する。

図３のＢＣのうちＤ１０００でデプロイされているＳＣは、ＳＣ＿ＩＤ「業務Ｂ」として組織“Ｏｒｇ１”の「管理者」によって提供され、少なくとも以下のＳＣ関数が定義されている。
・関数名：取引（）、入力引数：差出顧客ＩＤ，差出顧客ＩＤ，送金額、戻り値：成否。・関数名：全取引参照（）、入力引数：顧客ＩＤ、戻り値：指定顧客の全取引リスト。

一方、図３のＢＣのうちＤ１００４は、業務ＳＣの実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸは、基本的にデプロイＴＸと同様であるが、ＳＣの実体やＳＣ入力仕様はなく、その代わりに呼び出すＳＣ関数名と入力する引数の情報とを含む。

なお、本実施例では、ＴＸ種別については、分散台帳Ｄ１の更新を含むＴＸ実行の場合には「実行」、分散台帳Ｄ１の更新を行わない参照処理の場合には「参照」を指定することとする。

上述のＤ１００４のＴＸでは、ＳＣ＿ＩＤに「業務Ｂ」を指定し、ＳＣ関数「取引（）」に入力引数「顧客ａ，顧客ｂ，￥１Ｍ」を指定した実行要求を行う例を示す。すなわち、Ｄ１０００に示したＳＣを呼び出している例である。

ＲＷセットでは、ＳＣ（の関数）のデプロイや実行にて、参照／更新されたステート情報を示し、ＳＣ＿ＩＤ、参照（Ｒｅａｄ）か更新（Ｗｒｉｔｅ）かを識別する「ＲＷ区分」、対象となるステート情報のＫｅｙ、Ｖａｌｕｅの情報を含む。

さらにこのＶａｌｕｅの更新バージョン番号の情報を示す。このバージョン番号はＳＣ＿ＩＤのＫｅｙ毎に管理されて、更新のたびに１ずつインクリメントされることとする。

Ｄ１００５の例では、関数呼び出し「登録（顧客ａ，顧客ｂ，￥１Ｍ）」の実行処理の中で、Ｋｅｙ「顧客ａ」を参照しバージョン番号「４」のＶａｌｕｅ「￥１００Ｍ」を取得し（１行目）、Ｖａｌｕｅ「￥９９Ｍ」で更新して、その結果、バージョン番号が「５」に更新されたことを示す。

このようにＴＸの実行結果をＲＷセットとして管理／保持することで、ＳＣを実行せずともその実行結果を把握することができ、これによりＳＣを実行しなかったノードに対してもＳＣ実行結果を共有できるため、処理が効率的である。

なお、ブロックＤ１００１およびブロックＤ１００５は、データ連携ＳＣのデプロイＴＸおよび実行ＴＸを格納したブロックの一例である。本実施例のデータ連携ＳＣのデプロイＴＸおよび実行ＴＸは、大枠のデータ構造としては、業務ＳＣの同ＴＸと同様の情報を含む。

単純に業務に関わるＳＣが記述されているか、外部システム５とのデータ連携処理に関するＳＣが記述されているかの違いしかない想定である。これにより分散台帳システム１０の内部（具体的には分散台帳ノード３の３１～３７の各機能）に手を加えなくとも、外側の機能として本発明を実装することが可能である。

続いて図４は、分散台帳Ｄ１上で管理するステート情報の構成例である。ＢＣを用いた分散台帳管理では、通常、（最新の）ステート（例えば、仮想通貨の場合にはアカウントの残高）を取得するためには、ＢＣを辿らなければならない。これでは処理効率が悪いため、ＢＣとは別に、最新のステート情報をキャッシュしておく方法が存在する（非特許文献３等）。

本実施例でも最新のステート情報を保持することを想定する。本実施例では、ＳＣ毎にステートのデータ領域が用意されることとする。ステート情報はＳＣ＿ＩＤとそのＳＣの実態を保持する。これにより、ＳＣ実行／管理部３２は、ＳＣ＿ＩＤをキーにして、ＳＣの実体を取得して実行することができる。

また、ステート情報はＳＣの実行結果を保持するための内部テーブルＤ１１０４を備える。ＴＸが実行される度にこの内部テーブルＤ１１０４の内容は更新される。本ステート情報に関しても業務ＳＣ、データ連携ＳＣなどの各ＳＣの情報が格納される。

ここで、Ｄ１１１０の内部テーブルＤ１１０４に着目すると、図３の説明で述べたＲＷ
セットと対応づいており、ＲＷセットをすべて反映した最新の状態が保持されている。なお、典型的な実装例では、このようにＫｅｙ－ｖａｌｕｅ形式でデータを保持するが、ＶａｌｕｅにＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ （ＪＳＯＮ）形式などの構造化されたデータも格納できる。そうすれば、任意のデータスキーマのテーブルを保持できることになる。

またＫｅｙの設計を工夫すれば、内部テーブル内で複数のテーブル（スキーマの異なる情報）を仮想的に管理することができる。後述のデータ連携ＳＣに関する内部テーブルは、説明をシンプルにするために、Ｖａｌｕｅに構造化されたデータを格納するケースで、Ｋｅｙ－Ｖａｌｕｅ－バージョンの記載などを省略した表現をしている。

また、分散台帳システムでは、分散台帳Ｄ１にＴＸが追加されたことを契機にしてイベントを発行して、各参加組織（の分散台帳ノード３やクライアントノード４）に通知する機能も提供可能である。各参加組織はこのようなイベントに従った振る舞いを行うことも可能である。
図３のＴＸ情報に含まれるＳＣイベントは、そのような分散台帳のイベント管理機能を用いた場合に発行されるイベント情報である。

続いて図５は、構成情報Ｄ２のデータ構造例を示す図である。この構成情報Ｄ２は、分散台帳ネットワークを構成する組織やその組織に属するメンバー（分散台帳ノード３、クライアント４、管理者、ユーザなどを含む）の情報を格納する。

このうち業務Ｄ２０００は、分散台帳ネットワーク中で特定業務を行うグループである。組織ＩＤ＿Ｄ２００１は、分散台帳ネットワーク（ならびに業務）に参加する組織を示す。また、メンバーＩＤ＿Ｄ２００２は、参加組織中のメンバーを識別する情報である。具体的には、管理者、分散台帳ノード３、クライアントノード４、ユーザを識別する情報である。

この構成情報の例では、業務として“業務Ａ”と“業務Ｂ”が存在し、“業務Ｂ”には“組織１”，“組織２”，“組織３”，“組織ａ”が、“業務Ａ”には“組織３”，“組織４”が少なくとも参加しているネットワークの状態を示している。
なお、組織は必ずしも分散台帳ノード３を持つ必要はなく、クライアントノード４を介して分散台帳システム１０を利用するだけの場合もある。
また、外部システムアクセス権限Ｄ２００３は、外部システム５との間でのデータ連携をするうえでのアクセス権限である。

この例では、“業務Ｂ”において“組織１”と“組織２”は、管理者としてのアクセス権限、“組織３”は一般ユーザとしてのアクセス権限があり、一方、“組織ａ”は権限がない。そのため、“組織ａ”は外部データに直接アクセスすることはできない。そのため、外部システム５を介在させたデータが必要な場合、この“組織ａ”は他組織にデータ連携を依頼する必要がある。

図６は、データ連携ＳＣ＿Ｄ１２のデータ構造およびＳＣ関数の例を示す図である。このデータ構造は、ステート情報として管理・保持される。また、データ連携ＳＣ＿Ｄ１２内のデータ構造では、データ連携に関するルールとして、データ連携調整／収束ルールＤ１２０が記述されている。

また、外部システム５を介した登録データとして登録データＤ１２１が管理される。登録データＤ１２１内には、調整／収束処理前の各組織による仮データと、調整／収束処理によって一意な値が確定した確定データが管理される。
また、データ連携成否結果Ｄ１２２およびデータ連携信用分析結果Ｄ１２３は、実施例３でのみ利用するため、詳細は後述する。

また、連携処理イベントＤ１２４は、データ連携ＳＣ＿Ｄ１２内で連携要求時に発行されるＳＣイベントである。この連携処理イベントＤ１２４は、外部連携エージェント経由で外部システム連携処理を行う場合に、外部連携エージェント４３に連携処理を通知するために利用する。それぞれのデータ構造の詳細については後述する。

また、ＳＣ関数としては、本発明の主要な機能として、外部データ連携処理を要求するための「データ連携要求」と、当該データ連携要求に対して各組織が外部システム５との連携処理を行った結果を登録してデータ連携調整／収束ルールに従って複数組織からのデータエントリを収束させ、単一エントリに確定させる「データ連携調整／収束」が定義されることとする。
実装方法や連携方法によっては、「データ連携要求」と「データ調整／収束」は単一のＳＣ関数に統合してもよい。
さらに、データ連携調整／収束ルールＤ１２０を定義するための「データ連携定義」、各種データを取得／参照するための参照関数を備えることとする。
なお、「仮データ削除」は、登録データが確定した後に不要になった仮データを削除するための関数であり、実施例２でのみ利用する。
また、「データ連携信用分析」は、データ連携処理に関する各組織の信用度を計算するための関するであり、実施例３でのみ利用する。
また、ＳＣ関数「データ連携要求」および「データ調整／収束」の具体的な流れについてはフローチャートを用いて後述する。

続いて図７Ａは、データ連携ＳＣ内で管理されるデータ連携調整／収束ルールＤ１２０のデータ構造例を示す図である。図中に示すデータ連携調整／収束ルールＤ１２０のデータ構造は、Ｄ１１１１（図４のステート情報）の内部テーブルＤ１１０４内で管理された状態を想定したものである。

本実施例ではデータ連携調整／収束ルールＤ１２０が、業務（業務ＳＣ）に紐づくものとし、業務ＳＣおよびそのステート種別に応じて複数定義されることとする。

なお、本実施例では、同一の業務ＳＣとデータ連携ＳＣのステートは、相互に参照／利用可能であることとする。また、テーブルの説明をしやすくするために、複数業務ＳＣ（複数連携ＳＣ）に対応するデータを単一テーブル上に記載するが、実際にはＳＣごとに分かれていてもよい。これらは以降の図におけるデータ構造についても同様である。

ＳＣ＿ＩＤ（Ｄ１２０００）列は、対象となるＳＣを識別する情報である。本実施例では、この指定が業務の指定も兼ねている。この指定としては、例えば、「業務ＳＣ＿ＩＤ＋アンダバー＋外部システムでの処理名称」の形式で記述することとする。

また、ステート種別Ｄ１２００１は、対象となるステート情報を示す情報である。また、合意水準Ｄ１２００３は、各組織から取得される外部システム処理結果（仮データ）をコンソーシアムで受け入れて確定させるための条件である。この合意水準Ｄ１２００３は、本実施例では組織数Ｄ１２００４と許容範囲Ｄ１２００５を含む。

また組織数Ｄ１２００４は、合意をするうえで必要となる外部システム連携処理を行う組織数を示す。この条件を満たす組織から連携処理結果が登録されていれば組織数の合意水準を満たすものとする。

また、許容範囲Ｄ１２００５は、複数組織によってエントリされた外部連携データの幅の許容範囲である。全ての仮データがこの条件を満たした場合に許容範囲の合意水準を満たす。
また、収束方法Ｄ１２００６は、複数組織からエントリされた外部連携データを単一エントリに確定させるための値の計算／集約方法である。

なお、上述のＤ１２００４～Ｄ１２００６の各列は、本実施例では説明を簡便化するためテキストベースで記載をしているが、実際にはＪＳＯＮなどのデータ構造で記載されることを想定する。より複雑な処理が必要な場合には、ＳＣの記述に用いるプログラミング言語もしくはＤｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ （ＤＳＬ）に従ったプログラムコードによって記述されていてもよい。

また、処理組織選択方法Ｄ１２００７は、データ連携要求に対して、実際に外部システム５との連携処理の実施を依頼する処理組織の選択方法である。本実施例では、構成情報Ｄ２を参照して、業務Ｄ２０００や外部システムアクセス権限Ｄ２００３に基づいて、外部システム５との連携処理可能な組織を抽出し、処理組織選択方法Ｄ１２００７に記載の方法でその中から組織を選び出す。

この場合の選択方法としては、連携処理可能な組織からの「ランダム選択」、「順次選択」、「全組織選択」あるいは信頼度の高い組織からを優先した「信頼度優先選択」などがあげられる。
なお、処理組織選択方法Ｄ１２００７は、実行ＴＸの合意形成を依頼する実行／承認者組織と同一でよい場合には利用しなくてもよい。

また、データ取得方法Ｄ１２００８は、外部システム５を介した処理を行い、その処理結果を取得する方法を示す。本実施例のデータ取得方法Ｄ１２００８では、ＳＣ内からデータ取得を行うか、エージェント経由で行うかを示す情報Ｄ１２００９と、具体的なデータ取得処理内容Ｄ１２０１０を含む。このうち情報Ｄ１２００９は、文字通り、外部システム５を介した処理およびデータ取得を、ＳＣ内で行うか、それとも外部連携エージェント経由で行うかを示す情報である。
また、データ取得処理Ｄ１２０１０は、具体的な処理内容を参照情報として記述した情報であり、その詳細は図７Ｂ、図７Ｃに記載している。
この場合、ステップＩＤ（Ｄ１２０１１）は外部システム５上での処理が複数手順ある場合の番号である。
また、外部処理ＩＤ（Ｄ１２０１２）は、その外部処理の名称のラベルである。
また、対象Ｄ１２０１３は、処理対象となるシステムを示す情報であり、単一連携処理内で処理／参照するべき（外部）システムが複数ある場合に活用する。

また、区分Ｄ１２０１４は、外部システム５からデータアクセスする手段を識別する情報である。この情報をもとに外部連携エージェント４３はデータアクセス手段を切り替える。
また、入力Ｄ１２０１５は、本ステップの処理の入力となる情報である。
また、処理Ｄ１２０１６は、本ステップの具体的な外部システム５を用いた処理であり、出力Ｄ１２０１７は、取得するべきその出力である。

処理Ｄ１２０１６はアクセス先のＡＰＩのＵＲＬやコマンドライクな表現をしており、｛｝で囲まれた記述は入力や環境変数によって代入されるパラメータ（引数）を表している。なお、処理Ｄ１２０１６の記述についても、エージェント側やＳＣ内処理で取り扱えるのであれば、コマンド列／シェルスクリプト、ＤＳＬ、プログラミング言語を用いて複雑に表現されていても構わない。

また、本実施例では、外部連携処理を入力、処理、出力などこと細かに記載する例を示しているが、データ連携調整／収束ルールＤ１２０にはこのような詳細は持たせずに、外部連携エージェント４３側で管理してもよい。

本実施例のように具体的なデータ取得処理を記載することで、複数組織の間で連携処理を均一化しやすくなるというメリットがある。一方、詳細をエージェント側で管理すればより柔軟な外部システム連携処理を行いやすくなるというメリットがある。

ここで、データ連携調整／収束ルールＤ１２０について具体例を用いて説明する。図７ＡのＤ１２０２０行、および図７ＢのＤ１２０２０－１は、ある業務（ＳＣ）「業務Ａ」の外部システム連携処理「メータリング」におけるステート情報「ユーザ利用」のデータ連携方法を記載したルールである。

この例では、データ連携要求に対して「合計３組織以上」から外部システム連携結果となるデータが登録されて、かつその複数エントリデータの範囲が「時刻が±３秒以内」かつ「値が±５％以内」に収まるのであれば合意水準を満たすものとしている。その合意水準を満たしたデータの収束方法としては、「時刻に関してはエントリされたデータの最大値」、「値に関してはエントリされたデータの平均値」によってデータを確定させるという調整／収束方法が記載されている。

また、処理組織選択方法Ｄ１２００７は「順次選択」によって行い、「エージェント」経由で各処理組織に依頼をする。データ取得処理は、Ｄ１２０２０－１行に記載の通り、単一のステップから成り、外部処理「データ取得」として外部システム５の対象「サービス１」に「ＲＥＳＴ」でアクセスして、要求ＴＸから得られた「ユーザＩＤ」情報を入力として、ＵＲＬ「｛ＡＰＩ＿ＵＲＬ｝／ｍｅｔｅｒ／ｕｓｅｒ／｛ユーザ名｝」にアクセスしてデータを取得し、その出力結果をデータ連携ＳＣに登録（各組織からのデータ調整／収束依頼）することを表している。

もう一つの例として、Ｄ１２０２１およびＤ１２０２１－１，２は、前述した業務（ＳＣ）「業務Ｂ」の外部システム連携処理「優良顧客分析」におけるステート情報「顧客スコア」のデータ連携方法を記載したルールである。

この例では、データ連携要求に対して「合計３組織以上」から外部システム連携結果となるデータが登録されて、かつその複数エントリデータの範囲が「時刻が±１０秒以内」かつ「値が±３％以内」に収まるのであれば合意水準を満たすものとしている。また、合意水準を満たしたデータの収束方法としては、「時刻に関してはエントリされたデータの最大値」、「値に関してはエントリされたデータの最小値」によってデータを確定させるという調整／収束方法が記載されている。

また、処理組織選択方法は「ランダム選択」によって行い、「エージェント」経由で各処理組織に依頼をする。データ取得処理は、Ｄ１２０２０－１，２行に記載の通り、二つのステップから成る。

まずステップ１として処理「データロード」として外部連携エージェント４３側で分散台帳システム１０にアクセスして業務Ｂ（ＳＣ）の全取引参照関数を顧客ＩＤをキーに呼び出し、分析用のデータである、顧客の全取引リストを各処理組織のローカルにロードする。

さらにステップ２として、処理「顧客分析コマンド実行」として、外部システム「分析
アプリ」をステップ１の出力結果を引数として、コマンド「ｃｕｓｔｏｍｅｒ＿ａｎａｌｙｓｉｓ」を呼び出すことで分析を行い、その結果をデータ連携ＳＣに登録（各組織からのデータ調整／収束依頼）することを表している。

なお収束方法については「平均」「最大」「最小」などの簡易的な統計処理内容を例示したが、収束処理実行時に一意データに変換できるのであれば、より複雑な集約関数や変換処理を用いてもかまわない。これは許容範囲の判定条件に関しても同様である。

これらのデータ連携調整／収束ルールＤ１２０は、分散台帳ネットワークの参加者によって予め合議されて、定義（デプロイ）されていることを想定する。なお、データ連携調整／収束ルールＤ１２０は、参加者による合議の上で随時更新されても構わない。これらのデータ連携調整／収束ルールＤ１２０を用いた具体的な処理については後述のフローチャートの説明にて詳細に述べる。

続いて図８に、データ連携ＳＣ＿Ｄ１２内で管理される登録データＤ１２１のデータ構造例を示す。図中に示すデータ構造例は、Ｄ１１１１（図４参照）の内部テーブルＤ１１０４内で管理された状態を想定したものである。
ここで、データ連携要求に対して、収束処理前の複数組織による仮データと、収束処理後の確定データの両方が登録／管理される想定である。

列Ｄ１２１００～Ｄ１２１０１はデータ連携対象を識別するＳＣ＿ＩＤとステート種別であり、データ連携調整／収束ルールＤ１２０の列Ｄ１２０００とＤ１２００１に対応する。

ステートＩＤ＿Ｄ１２１０２は、ステート種別Ｄ１２１０１に対応する具体的なキーである。例えば、行Ｄ１２１２４では「顧客ｂ」の「顧客スコア」のデータであることを示す。

また、リクエストＩＤ＿Ｄ１２１０３は、データ連携調整／収束ルールＤ１２０に対するデータ連携要求を一意に識別するための識別子である。このリクエストＩＤ＿Ｄ１２１０３は、本実施例ではクライアントあるいはＳＣ内部処理によって採番される想定である（例えば分散台帳ノード３が発行するＴＸ＿ＩＤが兼ねてもよい）。
また、管理状態Ｄ１２１０４は、このデータが仮データか確定データかを識別する情報である。
また、登録組織Ｄ１２１０６は、このデータを登録した組織の情報である。確定データの場合には、仮データを登録した複数組織の情報が記載される。
また、時刻Ｄ１２１０５と値Ｄ１２１０７は、このデータの時刻と値の情報である。

また、外部処理エビデンスＤ１２１０８は、各組織による外部システム連携処理の結果であり、具体的には、処理方法Ｄ１２０１０に従った各組織の各ステップの外部処理呼び出し履歴および実行結果履歴などを想定する。
エビデンスの登録は行わなくても構わないが、各組織による外部システム５を介した処理が期待した通りに実施されたかを検証／確認するうえで役立つ。

なお、行Ｄ１２１２０～Ｄ１２１２３は、行Ｄ１２０２０に従ってデータ連携を行った登録データの一例であり、行Ｄ１２１２０～Ｄ１２１２２は各組織からの仮データ、行Ｄ１２１２３は確定データである。

同様に行Ｄ１２１２４～Ｄ１２１２７は、行Ｄ１２０２１に従ってデータ連携を行った登録データの一例であり、行Ｄ１２１２４～Ｄ１２１２６は各組織からの仮データ、行Ｄ
１２１２７は確定データである。

続いて図９に、データ連携ＳＣ＿Ｄ１２内で発行される連携処理イベントＤ１２４のデータ構造例を示す。本データは外部連携エージェント経由で外部システム連携処理を行う場合にのみ利用する。

なお、図中では説明の冗長性を防ぐため、連携処理イベントＤ１２４をテーブル形式で記載しているが、実際にはデータ連携要求ごとに各行が単一のＳＣイベントとしてブロックに埋め込まれて各組織に通知される想定である。
図中において列Ｄ１２４００～Ｄ１２４０３は、それぞれ列Ｄ１２１００～Ｄ１２１０３と同様である。

また、処理担当組織Ｄ１２４０４は、データ連携要求の結果、処理担当に選ばれた組織であり、この情報を参照することで各エージェントは自組織が処理を実行する必要があるか否かを判別できる。

また、入力Ｄ１２４０５は、本データ連携要求に対する入力情報であり、行Ｄ１２４２１の例では変数「顧客ＩＤ」に「顧客ｂ」を入力する例を表している。データ取得処理Ｄ１２４０６列はＤ１２０１０と同様の情報であり、Ｄ１２０１０を参照して埋め込む。
－－－メンバー登録－－－

以下、本実施形態におけるデータ連携管理方法の実際手順について図に基づき説明する。以下で説明するデータ連携管理方法に対応する各種動作は、データ連携管理システム１０を構成するノード（分散台帳ノード３、クライアントノード４）らがメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
以降では、実施例１における処理のフローについて説明する。図１０は、分散台帳ネットワークに参加するメンバーの新規登録処理の例を示すフロー図である。

この場合、分散台帳ノード３のメンバー管理部３３は、クライアントノード４等の他ノードからメンバー登録要求を受け付ける（Ｓ１０１）。ここで、上述のメンバー登録要求には、要求メンバーを一意に識別するメンバーＩＤが含まれることとする。

続いてメンバー管理部３３は、既知の一般的手法により秘密鍵Ｄ３１と公開鍵Ｄ３２の組を生成し、これを、Ｓ１０１で受け付けたメンバーＩＤと紐付ける（Ｓ１０２）。
次に、メンバー管理部３３は、新規登録対象となるメンバーＩＤとＳ１０２で生成した公開鍵Ｄ３２とを、他のノードにブロードキャストする（Ｓ１０３）。
なお、ブロードキャストされたメンバーＩＤおよび公開鍵Ｄ３２の情報は、各ノード上で参加メンバー管理情報Ｄ３として保管される。

さらに、メンバー管理部３３は、メンバー登録要求を行ったノードに対し、Ｓ１０２で生成した秘密鍵Ｄ３１を返す（Ｓ１０４）。この秘密鍵Ｄ３１を受け取った該当ノードは、参加メンバー管理情報Ｄ３に、自身の秘密鍵Ｄ３１として保管する。

本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、ネットワーク参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。

具体的には、例えば、クライアントノード４の側では、発行された秘密鍵で電子署名したＴＸを発行し、分散台帳ノード３などの検証ノードの側が公開鍵を用いて電子署名を検証することで、本人確認を実現できる。

なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法、鍵とＩＤを紐付ける手法については、公知または周知の技術を適用すれば良い。そのため本実施例１では詳述しない。

また、本実施例ではメンバー管理部３３の機能を分散台帳ノード３中に機能として示したが、外部にメンバー管理専用のノードを立て、そのノードがメンバー管理部３３と同等の機能を提供するとしてもよい。
－－－トランザクション処理－－－

図１１は、ＴＸ実行処理、すなわち、ＳＣのデプロイ、実行処理の例を示すフロー図である。ＳＣの種別としては、業務、データ連携等があるが、本実施例では、これらのＳＣ種別による処理の違いは、ＳＣ内部処理の違いとして表現可能であり、ＳＣにおけるＴＸ実行処理の流れ自体は共通であることとする。

ここで、分散台帳ノード３のトランザクション管理部３４が、クライアントノード４等のＴＸ発行元からＴＸを受け取る（Ｓ２０１）。そして、このＴＸをコンセンサス管理部３１に渡し、当該ＴＸの種別に応じてＳＣのデプロイ、実行処理を行う。

コンセンサス管理部３１が受け取った上述のＴＸが、ＳＣのデプロイＴＸの場合（Ｓ２０２の判定が「ＹＥＳ」の場合）について説明する。この場合には、まずコンセンサス管理部３１は、他の分散台帳ノード３との間で、受け取ったＴＸを実行してよいか、ブロックとして、ＢＣの末尾に追加してよいかの合意形成処理を行う（Ｓ２０３）。具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。

例えば、Ｐｌａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｒｅｒａｎｃｅ（以後、ＰＢＦＴ）と呼ばれるアルゴリズム等を採用することが考えられる。このＰＢＦＴは、合意形成に参加するすべてのノード（すなわち検証ノード）の間で一定（３分の２）以上のノードによる合意を条件とするアルゴリズムである。

また別の例として、非特許文献３に記載の分散台帳システムでは、Ｅｎｄｏｒｓｅｒ－Ｏｒｄｅｒｅｒモデルと呼ばれる合意形成アルゴリズムが用いられる。Ｅｎｄｏｒｓｅｒ－Ｏｒｄｅｒｅｒモデルでは、分散台帳ノード３の中から、承認権限のある一部の分散台帳ノード３を選定／ＴＸを送信し、それらの選択された分散台帳ノードのみが問題がないかの検証を行い、問題がなければ承認を返す。

予め決めた合意形成条件（例えば、２組織以上の承認）を満たした場合、そのＴＸを受け入れる。さらに、その承認済ＴＸを全分散台帳ノード３に配信する。Ｅｎｄｏｒｓｅｒ－Ｏｒｄｅｒｅｒモデルでは、全分散台帳ノード３がＴＸ検証を行う必要が無いため、ＰＢＦＴに比べて効率的である。

ここではＥｎｄｏｒｓｅｒ－Ｏｒｄｅｒｅｒモデルをベースとした合意形成以降の流れを簡単に説明する。分散台帳ノード３は、受け取ったＴＸを分散台帳ネットワークに参加しており、ＴＸの承認権限のある分散台帳ノード３に対して送信する。一方、このＴＸを受け取った各分散台帳ノード３は、当該ＴＸに対する署名検証を行い、改ざんがされていないこと、および当該ＴＸの内容の正当性を確認する。また、当該分散台帳ノード３は、上述のＴＸを送信した分散台帳ノード３に対して確認結果を返却する。予め決めた合意形成条件が満たされた場合にＴＸの承認完了したこととし、確認できたことをもって合意形成が完了する。
コンセンサス管理部３１は、承認済ＴＸ配信部３６の機能を用いて、全ての分散台帳ノ
ード３に対し、承認済ＴＸをブロードキャストする。

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

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

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

そして、コンセンサス管理部３１は、その実行結果に基づき、分散台帳Ｄ１の内容を更新する。実行結果に基づいて、本ＳＣに関するステート情報Ｄ１２を更新し、ＢＣの末尾のブロックとして実行ＴＸを追加する。最後に、コンセンサス管理部３１は、この実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返す（Ｓ２０９）。
－－－外部システム連携処理－－－

図１２Ａおよび図１２Ｂに、実施例１における、システム全体としてのデータ連携ＳＣに従った外部システム連携処理の流れを示す。なお、以降の説明では、実行／参照される各種ＳＣは既に分散台帳Ｄ１上にデプロイ済みであることとする。

図１２Ａには、外部システム連携処理のパターン例１として、要求組織が外部システム５のデータにアクセス可能、かつ外部連携エージェント４３によるエージェント連携によって連携処理を行う例を示す。

この場合、要求組織となるクライアントノード４が、データ連携要求を開始する。このクライアントノード４は、要求時点で外部システム５との連携処理を事前に行い、その連携処理結果を、データ連携ＳＣに対する実行ＴＸに同梱してもしなくてもよい。外部システム５との連携処理を事前に実行すると実行ＴＸ数を１つ減らすことができるが、実行タイミングのズレが発生しやすくなる可能性がある。
また、要求組織となるクライアントノード４は、分散台帳ノード３に対して、データ連携ＳＣの実行ＴＸ「データ連携要求」を発行する。

一方、各分散台帳ノード３は、上述の実行ＴＸを受け取ると、他ノード間で合意形成をしながら、受け取った実行ＴＸに従ってデータ連携要求処理Ｓ３を実施する。

本処理における分散台帳ノード３は、上述の実行ＴＸに含まれる要求情報、および既に要求組織によって連携処理が済んでいる場合には仮データを、分散台帳Ｄ１に登録する。そしてデータ連携調整／収束ルールＤ１２０に従って組織選定を行い、本要求に対する連携処理イベントを発行する。

各組織のクライアントノード４の外部連携エージェント４３は、上述の連携処理イベントを受け取ると、自身が処理担当組織だった場合には外部システム５にアクセスして連携
処理を実行する。そして当該外部連携エージェント４３は、その連携処理結果を含む、データ連携ＳＣの実行ＴＸ「データ連携調整／収束」を、分散台帳ノード３に対して発行する。

一方、各分散台帳ノード３は上述の実行ＴＸを外部連携エージェント４３から受け取ると、他ノード間で合意形成をしながら、受け取った実行ＴＸに従ってデータ連携調整／収束処理Ｓ４を実施する。この場合、分散台帳ノード３は、上述の実行ＴＸに含まれる各組織からの処理実行結果を仮データとして分散台帳Ｄ１に登録する。また、分散台帳ノード３は、データ連携調整／収束ルールＤ１２０に従って組織数合意判定とデータ許容範囲判定を行い、両方の判定に関する合意水準を満たした場合、上述の仮データの調整／収束処理を行う。また、分散台帳ノード３は、仮データの調整／収束処理の結果を確定データとして分散台帳Ｄ１に登録する。

他方、図１２Ｂには、外部システム連携処理のパターン例２として、要求組織が外部システム５のデータにアクセス不可かつＳＣ内での外部システムアクセスによって連携処理を行う例を示す。ただし、基本的な流れはパターン例１と同様である。

パターン例１との相違点は、ＳＣ内部処理によって外部システムアクセスが行われるため外部連携エージェント４３が登場しない点、実行ＴＸの合意形成を依頼する実行／承認者組織がデータ連携の処理組織を兼ねるため組織選定が不要な点、および単一のＴＸ処理の中でデータ連携要求と調整／収束処理を行っている点、である。
ＳＣ内部処理で外部システム５にアクセスする場合には、外部システムＡＰＩ＿５１に直接アクセスする想定である。

なお、外部システム連携は、これらパターン例１，２で示した方法に限定されるものではなく、要求組織による外部データアクセス可否や連携方法は任意の組み合わせが可能である。
－－－データ連携ＳＣの内部処理－－－

図１３は、データ連携ＳＣの内部処理（データ連携要求およびデータ連携調整／収束）の例を示すフロー図である。以降の説明では、これまでに述べた「業務Ｂ」の「優良顧客分析」を対象に具体的に説明している。

この場合、各分散台帳ノード３は、実行ＴＸとして、データ連携ＳＣ＿Ｄ１２のＳＣ関数「データ連携要求」呼び出しを受け取る（Ｓ３０１）と、ＳＣ実行／管理部３２の機能によって、本実行ＴＸに従ったデータ連携処理の実行を行う。ここではＳＣ関数の引数として「顧客ＩＤ」に対する入力「顧客ｂ」が含まれていることとする。

続いて、各分散台帳ノード３は、データ連携ＳＣ＿Ｄ１２のステート情報「データ連携調整／収束ルール」を取得する（Ｓ３０２）。図８に示したデータ連携調整／収束ルールを具体例に説明すると、行Ｄ１２０２１が「業務Ｂ」の「優良顧客分析」に関するデータ連携調整／収束ルールである。
次にデータ連携ＳＣ＿Ｄ１２では、本データ連携要求を一意に特定するリクエストＩＤを発行する（Ｓ３０３）。
次に、データ連携ＳＣ＿Ｄ１２は、上述の実行ＴＸが引数として要求組織による仮データを含むかどうかを判定する（Ｓ３０４）。

上述の判定の結果、引数として仮データが含まれる場合（ｓ３０４：ＹＥＳ）、データ連携ＳＣ＿Ｄ１２は、ステート情報「登録データ」に対して、仮データを追記・更新する（Ｓ３０５）。
他方、上述の判定の結果、引数として仮データが含まれない場合（ｓ３０４：ＮＯ）、データ連携ＳＣ＿Ｄ１２は、Ｓ３０５をスキップする。

その後、データ連携ＳＣ＿Ｄ１２は、取得したデータ連携調整／収束ルールＤ１２０のＤ１２００９を参照し、本データ連携処理が、ＳＣ内からデータ取得なのか連携エージェント経由で実施されるのかを判定する（Ｓ３０６）。

上述の判定の結果、エージェント経由の実施の場合（ｓ３０６：エージェント）、データ連携ＳＣ＿Ｄ１２は、データ連携調整／収束ルールＤ１２０の処理組織選択方法Ｄ１２００７と構成情報Ｄ２に従って、処理組織を選定する（Ｓ３０７）。

そしてデータ連携ＳＣ＿Ｄ１２は、データ連携調整／収束ルールＤ１２０に記載の情報、ＳＣ関数の引数から入力およびその情報から生成し対象となるステートＩＤ、Ｓ３０７で選定した処理組織の情報に基づき、連携処理イベントを生成し、ＳＣイベントとして設定する（Ｓ３０８）。

これにより、本ＴＸによるブロック確定時にＳＣイベントが発行されて、各組織の外部連携エージェント４３に通知される。その後、データ連携ＳＣ＿Ｄ１２は、ＳＣの実行結果を返し（Ｓ３０９）、処理を終了する。

一方、各組織のクライアントノード４の外部連携エージェント４３は、上述の連携処理イベントを受け取ると、自身が処理担当組織だった場合には外部システム５にアクセスして連携処理を行う。そして外部連携エージェント４３は、その連携処理結果を含む、データ連携ＳＣ＿Ｄ１２の実行ＴＸ「データ連携調整／収束」を分散台帳ノード３に対して発行する。

他方、各分散台帳ノード３は、実行ＴＸとして、データ連携ＳＣ＿Ｄ１２のＳＣ関数「データ連携調整／収束」呼び出しを受け取る（Ｓ４０１－１）と、ＳＣ実行／管理部３２の機能によって、本ＴＸに従った後続のデータ連携調整／収束処理を実行する。
ここではＳＣ関数の引数には、各組織で外部システム連携処理を行った仮データ（外部処理エビデンスを含んでもよい）を含むこととする。

各分散台帳ノード３は、ＴＸを受け取ると、Ｓ３０２と同様にデータ連携ＳＣ＿Ｄ１２のステート情報「データ連携調整／収束ルール」を取得する（Ｓ４０２）。そして、データ連携ＳＣ＿Ｄ１２のステート情報「登録データ」に対して引数に含まれる仮データを追記・更新する（Ｓ４０３）。

次に、各分散台帳ノード３は、データ連携ＳＣ＿Ｄ１２のステート情報「登録データ」から本データ連携要求に関する仮データをすべて取得する（Ｓ４０４）。例えば、リクエストＩＤが「２００１」の例では、行Ｄ１２１２４～Ｄ１２１２６が該当する。

そして各分散台帳ノード３は、上述のＳ４０４で取得した仮データとデータ連携調整／収束ルールの合意水準Ｄ１２００３とに基づき、組織数合意判定（Ｓ４０５）およびデータの許容範囲判定（Ｓ４０６）を行う。

各分散台帳ノード３は、上述の各判定とも当該判定における所定基準を満たす結果（Ｓ４０５：ＹＥＳ、Ｓ４０６：ＹＥＳ）とならない限り、後続の処理をスキップして、ＳＣの実行結果を返し（Ｓ４０９）、処理を終了する。

他方、上述のＳ４０５およびＳ４０６の両判定で所定基準を満たす場合（Ｓ４０５：Ｙ
ＥＳ、Ｓ４０６：ＹＥＳ）、各分散台帳ノード３は、データ連携調整／収束ルールの収束方法Ｄ１２００６に基づいてデータ収束処理を行う（Ｓ４０７）。

また、各分散台帳ノード３は、Ｓ４０７のデータ収束処理結果をデータ連携ＳＣ＿Ｄ１２のステート情報「登録データ」の確定データとして追記、更新する（Ｓ４０８）。
また、各分散台帳ノード３は、Ｓ４０８の確定データをＳＣの実行結果として返し（Ｓ４０９）、処理を終了する。

例えば、リクエストＩＤが「２００１」の例では、行Ｄ１２１２４～Ｄ１２１２６より、組織数３以上、値と時刻が許容範囲内である。そして収束処理により、時刻の最大値をとった（略）：３５、値の最小値をとった「８９」が確定データとなる。この例の確定データの格納結果は行Ｄ１２１２７に示すとおりである。

上述のＳ３０６の処理結果が「ＳＣ内」の場合には、各分散台帳ノード３は、データ連携要求の後続で、ＳＣ内から外部連携処理を実行して連携処理結果を取得し（Ｓ４０１－２）、その後は上記と同様にＳ４０３以降を実行する。
－－－外部連携エージェントの処理－－－

図１４は、外部連携エージェント４３の処理例を示すフロー図である。各組織のクライアントノード４の外部連携エージェント４３は、連携処理イベントを受け付ける（Ｓ５０１）と、自身が処理組織かどうかを確認する（Ｓ５０２）。
上述のＳ５０２の結果、自身が処理組織でない場合（Ｓ５０２：ＮＯ）、外部連携エージェント４３は後続の処理をスキップし、処理を終了する。

一方、上述のＳ５０２の結果、自身が処理組織である場合（Ｓ５０２：ＹＥＳ）、外部連携エージェント４３は、連携処理イベントに従いながら、処理対象となる外部システム５にアクセスし、順次外部処理を行う（Ｓ５０３）。

また、外部連携エージェント４３は、Ｓ５０３の処理結果に基づき、データ連携ＳＣ＿Ｄ１２のＳＣ関数「データ連携調整／収束」の実行ＴＸを生成する（Ｓ５０４）。
また、外部連携エージェント４３は、上述のＳ５０４で生成した実行ＴＸを分散台帳ノード３に対して発行し（Ｓ５０５）、処理を終了する。

以上で示したとおり、外部システム５（非分散台帳システム）との接続パスを単一組織に依存しないように複数用意し、複数組織による、外部システム５を介したデータ入出力結果に対するデータの許容範囲（幅）とその収束方法（データ連携調整／収束ルール）をデータ連携ＳＣ（共通フレームワーク）として規定すること、また、このデータ連携ＳＣにて定義されたデータ連携調整／収束ルールに従ってデータ連携処理を行うことで、複数組織による、外部システム５を介したデータ取得／処理の結果を、ある一定の幅の中で一意なデータとして収束させることができる。

このような特徴を持つ本技術を用いれば、複数組織による外部システム５（非分散台帳システム）とのデータ入出力タイミングや手段、権限などにより、上述のデータ取得／処理の結果の間にばらつきが発生したとしても、分散台帳システム１０で処理可能となり、分散台帳システム１０と外部システム５（非分散台帳システム）との間で安全にデータのやり取りを行うことが可能となる。

また、複数の分散台帳ノード３の上でのＳＣ機能で管理されるため、コンソーシアムの取り決めに従って単一組織に寄らず外部データを連携できる。また、業務（ＳＣ）レイヤでの合意形成に基づいた非決定的なデータの取り扱いを実現することができる効果がある
。また、外部システム５の側に手を加えることなく、単一組織に依存せずに客観性をもってデータ連携が実施可能となる効果がある。

なお、本実施例では、簡単のために１ブロックあたり１トランザクションを格納する例を示しているが、複数トランザクションを格納しても構わない。本発明はその場合にも適用可能である。

また、構成情報Ｄ２は分散台帳ノード３の機能の中で管理するデータとして記載しているが、ＳＣ上で管理してもよい。複数の組織で構成情報が確認できればそのような方法でも構わない。

また、データ連携調整／収束ルールＤ１２０における計算ロジックは、メタ言語やＤｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ（ＤＳＬ）として、引数の中で定義しても良い。或いは、予め、ＳＣ関数の中に埋め込んでもよい。上述のようにメタ言語化することで外部定義が可能となり、柔軟性が高まるメリットがある。一方、ＳＣ関数の中で埋め込むと管理が容易になるというメリットがある。
＜実施例２＞
以降では、本発明の実施例の様々なバリエーションを示す。基本的には実施例１をベースとするため、共通部分の説明は省略する。

実施例２は、上述の実施例１に対して、データ確定までの一時データである仮データをプライベート用の分散台帳で管理し、不要になれば削除を行う例について示す。なお、実施例１とは、仮データをプライベート用分散台帳Ｄ４上で管理し、さらに図６中のＳＣ関数「仮データ削除」を利用する点が異なる。それ以外の処理は基本的に共通である。

図１５は、実施例２で想定するコンピュータシステムを模式的に示す。本コンピュータシステムは、基本的に実施例１と同じであるが、プライベート用分散台帳Ｄ４が追加されている点が異なる。

この場合、登録データＤ１２１の仮データは、分散台帳Ｄ１ではなくプライベート用分散台帳Ｄ４に格納する。また、当該仮データの収束等の各処理が完了し確定した後は、ＳＣ関数「仮データ削除」を呼び出し、確定済みのデータに対する仮データ削除を実行する。
この仮データ削除は、プライベート用分散台帳Ｄ４の空き容量の大小など、適宜な条件に応じて実行するとしてもよい。

こうした実施例２の形態を採用すれば、仮データという一時的な中間データで分散台帳Ｄ１を汚染せずに済む。また、プライベート用分散台帳Ｄ４からは適宜データを削除することでデータ容量を削減できる効果がある。
＜実施例３＞

また実施例３は、上述の実施例１に対して、データ連携処理に関する各組織の登録内容（成否）に基づき、当該組織の信用度を計算して、その結果をコンソーシアムや各組織にフィードバックする例を示す。

図１６は、データ連携ＳＣ＿Ｄ１２のステート情報として管理されるデータ連携成否結果を示す図である。これはデータ連携調整／収束処理Ｓ４において、データの許容範囲判定（Ｓ４０６）の判定結果を管理する情報である。

このデータ連携成否結果は、実施例１の処理Ｓ４０６の後続で、データ連携ＳＣ＿Ｄ１
２のステート情報「データ連携成否結果１２２」に追記・更新されることとする。
図１６における列Ｄ１２２００～Ｄ１２２０３は、それぞれ列Ｄ１２１００～Ｄ１２１０３と同様であり、組織Ｄ１２２０４は本処理を行った組織である。

また、判定結果Ｄ１２２０５は、このデータの許容範囲判定結果であり、判定に従って「成功」または「却下」が記録される。理由Ｄ１２２０６は、判定結果が「却下」だった場合の理由を示す情報である。
また図１７は、データ連携ＳＣ＿Ｄ１２のステート情報として管理されるデータ連携信用分析結果Ｄ１２３を示す図である。

データ連携信用分析結果Ｄ１２３は、あるデータ連携ＳＣ＿Ｄ１２の対象となるステート種別に対する各組織の信頼度を示す情報である。Ｄ１２３００、Ｄ１２３０１は、データ連携ＳＣ＿Ｄ１２のＳＣ＿ＩＤ、ステート種別を示す。また、このＤ１２３００、Ｄ１２３０１は、Ｄ１２０００とＤ１２００１と同様である。

組織Ｄ１２３０２は、このデータ連携ＳＣ＿Ｄ１２のステート種別に対する信頼度の対象となる組織を、また信用度Ｄ１２３０３は、当該組織の信頼度をスコアリングした結果である。

図１８は、実施例３におけるデータ連携信用分析処理の例を示すフローチャートである。本実施例では、あるデータ連携ＳＣ＿Ｄ１２の対象となるステート種別に対する各組織の信頼度を、（対象組織のデータ連携成功件数／全データ連携リクエスト件数）×１００で計算することとする。
この場合、各分散台帳ノード３は、実行ＴＸとして、データ連携ＳＣ＿Ｄ１２のＳＣ関数「データ連携信用分析」呼び出しを受け取る（Ｓ６０１）。

続いて各分散台帳ノード３は、ＳＣ実行／管理部３２の機能によって、本実行ＴＸに従ったデータ連携処理を実行する。ここではＳＣ関数の引数として対象組織の情報が含まれていることとする。

各分散台帳ノード３は、上述の実行ＴＸで指定された情報に関係する、データ連携ＳＣ＿Ｄ１２のステート情報「データ連携成否結果１２２」をすべて取得する（Ｓ６０２）。
そして、各分散台帳ノード３は、上述のＳ６０２で取得したデータ連携成否結果１２２を用いて、データ連携信用分析を行う（Ｓ６０３）。この分析は、上述のように、（対象組織のデータ連携成功件数／全データ連携リクエスト件数）×１００、と信用度を計算することが該当する。
続いて、各分散台帳ノード３は、上述のＳ６０３の計算結果を用いてステート情報「データ連携信用分析結果１２３」を追記、更新する（Ｓ６０４）。
また、各分散台帳ノード３は、上述のＳ６０４で得たデータ連携信用分析結果１２３に基づいてＳＣ実行結果を返し（Ｓ６０５）、処理を終了する。

こうした実施例３では、各組織が問い合わせによって、上記組織のデータ連携成否結果とデータ連携信用分析結果を参照することで、自身や各組織の信頼度やデータ連携精度を把握できる効果がある。さらに信用度に応じてデータ連携処理組織を選択することで、データ連携の成功率を向上させることが期待できる効果がある。

なお、上述の各実施例では、説明の簡便化のため、業務ＳＣとデータ連携ＳＣとを分けて記載した例を示したが、業務ＳＣ内にデータ連携ＳＣを同梱していてもかまわない。その場合には、単一のＳＣ内で処理が完結するメリットがある。

また各実施例では、数値や時刻を例に記載しているが、これらに限定されない。例えば、ＯＫ／ＮＧ判定や文字列の収束に適用してもよい。この場合にはＯＫ／ＮＧの一致率や文字列の部分一致率によって判定と収束する方法が考えられる。

また全データを幅を持たせた処理の対象とするのではなく、データのうちの一部分のみを幅を持たせる対象として、それ以外の部分は完全一致のみを受け入れてもかまわない。

また、分散台帳システムと非分散台帳システムとの間でのデータ連携を例に記載したが、本発明は単一分散台帳システム内のデータ連携や複数分断台帳システム間でのデータ連携にも適用可能である。分散台帳間の場合には、標準でデータを安全にやり取りする手段が別途確保されていると期待されるが、仮にそのような手段が提供されていない場合や、やむを得ず例外的な利用が必要な場合であっても本発明を適用することで安全なやり取りを実施可能となる。

また、外部データ連携の許容範囲判定処理や単一エントリに収束させる処理はＳＣの機能として示したが、この実装方法には限定されない。具体的には、例えば、分散台帳ノードの備える （機能部３１～３７と同様の）基盤機能として実装してもかまわない。この場合には、基盤としてのより強制力の高い機能として本発明を利用できるメリットがある。

以上、本発明の実施例について図面を参照して詳述してきたが、具体的な構成はこの実施例に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。

こうした本実施形態によれば、分散台帳システムにおける複数組織による非分散台帳システムとのデータ入出力タイミングや手段、権限などにより、取り扱いデータの値にばらつきが発生したとしても、所定ルールに沿って好適に処理可能となる。また、分散台帳システムと非分散台帳システムとの間で安全にデータのやり取りを行うことが可能となる効果も有する。また、非分散台帳システム側に手を加えることなく、当該非分散台帳システムを介したデータ処理／登録を、単一組織に依存せず客観性をもって実施可能となる効果もある。
すなわち、分散台帳システムと非分散台帳システムとの間の効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のデータ連携管理方法において、前記各ノードは、前記各ノードにより取得された前記データを、単一の一意なデータである単一データに収束させる収束方法ルールを更に保持し、前記相違を許容するに際し、前記収束方法ルールに従って、前記トランザクションが示す前記データを前記単一データに確定させる収束処理を行い、前記確定した単一データを分散台帳に格納する、としてもよい。

これによれば、各ノードが外部システムから得たデータの間における相違を、効率的に収束し、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、前記分散台帳システムと前記外部システムとの間のデータ連携方法に関して、前記許容範囲ルールと前記収束方法ルールとを少なくとも規定したデータ連携スマートコントラクトとして管理する、としてもよい。

これによれば、許容範囲ルールに基づく判定や収束方法ルールに基づく単一データ化が
効率的なものとなり、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、前記各ノードにより取得された前記データを仮データとして前記分散台帳に格納し、前記判定および前記収束処理に際し、前記仮データを前記分散台帳から取得して前記判定および前記収束処理の処理対象とする、としてもよい。

これによれば、確定前のデータについて簡易な取り扱いとして分散台帳の利用効率を向上させ、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、第２の分散台帳を備え、前記仮データを前記第２の分散台帳に格納し、前記判定および前記収束処理を経た確定済みの仮データについては前記第２の分散台帳から削除する処理を更に実行する、としてもよい。

これによれば、確定前のデータについて簡易な取り扱いとするとともに、収束方法ルールに沿って収束させ確定した仮データについては削除することで、分散台帳の利用効率を向上させ、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、前記データ連携スマートコントラクトにおいて、前記外部システムに接続する組織を前記複数組織の内から選択する組織選択ルールを更に備え、当該組織選択ルールを、前記複数組織に関して予め保持する所定の構成情報に適用し、前記外部システムに接続する組織を選定する処理を更に実行する、としてもよい。

これによれば、外部システムからデータを得る組織をその権限等に応じて効率的に選択し、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記データ連携スマートコントラクトにおける所定イベントの発行に伴い、前記複数組織の組織それぞれの情報処理装置に備わる所定の外部連携エージェントが、当該イベントを受け取り、前記外部システムに関する処理を実行し、当該処理の結果を前記データ連携スマートコントラクトに通知する、としてもよい。

これによれば、具体的なデータ取得処理の詳細を外部連携エージェントで管理することで、より柔軟な外部システム連携処理を行いやすくなる。ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、前記データ連携スマートコントラクトにおいて、前記外部システムに関する処理内容を、前記発行する所定イベントに埋め込み、前記外部連携エージェントは、前記埋め込まれた処理内容に従って前記外部システムに関する処理を実行する、としてもよい。

これによれば、より柔軟な外部システム連携処理を更に効率良く行うこととなり、ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一
組織に依存せず、かつ客観性をもって実施可能となる。

また、本実施形態のデータ連携管理方法において、前記各ノードは、前記許容範囲ルールに従った前記許容可否の判定結果を保持し、前記判定結果に基づき前記複数組織のそれぞれの信頼度を算出する、としてもよい。

これによれば、組織それぞれにおけるデータの信頼性を明示的に提示し、それに応じた当該組織の取扱等を考慮可能となる。ひいては、分散台帳システムと非分散台帳システムとの間のより効率的なデータ連携が、単一組織に依存せず、かつ客観性をもって実施可能となる。

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

Claims (11)

1. 複数のノードで構成される分散台帳システムにおいて、前記複数のノードのうち少なくとも所定の複数組織の各ノードは、
   前記各ノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成する、
   ことを特徴とするデータ連携管理方法。
2. 前記各ノードは、
   前記各ノードにより取得された前記データを、単一の一意なデータである単一データに収束させる収束方法ルールを更に保持し、
   前記相違を許容するに際し、前記収束方法ルールに従って、前記トランザクションが示す前記データを前記単一データに確定させる収束処理を行い、前記確定した単一データを分散台帳に格納する、
   ことを特徴とする請求項１に記載のデータ連携管理方法。
3. 前記各ノードは、
   前記分散台帳システムと前記外部システムとの間のデータ連携方法に関して、前記許容範囲ルールと前記収束方法ルールとを少なくとも規定したデータ連携スマートコントラクトとして管理する、
   ことを特徴とする請求項２に記載のデータ連携管理方法。
4. 前記各ノードは、
   前記各ノードにより取得された前記データを仮データとして前記分散台帳に格納し、前記判定および前記収束処理に際し、前記仮データを前記分散台帳から取得して前記判定および前記収束処理の処理対象とする、
   ことを特徴とする請求項３に記載のデータ連携管理方法。
5. 前記各ノードは、
   第２の分散台帳を備え、前記仮データを前記第２の分散台帳に格納し、前記判定および前記収束処理を経た確定済みの仮データについては前記第２の分散台帳から削除する処理を更に実行する、
   ことを特徴とする請求項４に記載のデータ連携管理方法。
6. 前記各ノードは、
   前記データ連携スマートコントラクトにおいて、前記外部システムに接続する組織を前記複数組織の内から選択する組織選択ルールを更に備え、当該組織選択ルールを、前記複数組織に関して予め保持する所定の構成情報に適用し、前記外部システムに接続する組織を選定する処理を更に実行する、
   ことを特徴とする請求項３に記載のデータ連携管理方法。
7. 前記データ連携スマートコントラクトにおける所定イベントの発行に伴い、前記複数組織の組織それぞれの情報処理装置に備わる所定の外部連携エージェントが、当該イベントを受け取り、前記外部システムに関する処理を実行し、当該処理の結果を前記データ連携スマートコントラクトに通知する、
   ことを特徴とする請求項３に記載のデータ連携管理方法。
8. 前記各ノードは、
   前記データ連携スマートコントラクトにおいて、前記外部システムに関する処理内容を、前記発行する所定イベントに埋め込み、前記外部連携エージェントは、前記埋め込まれた処理内容に従って前記外部システムに関する処理を実行する、
   ことを特徴とする請求項７に記載のデータ連携管理方法。
9. 前記各ノードは、
   前記許容範囲ルールに従った前記許容可否の判定結果を保持し、前記判定結果に基づき前記複数組織のそれぞれの信頼度を算出する、
   ことを特徴とする請求項１に記載のデータ連携管理方法。
10. 複数のノードで構成される分散台帳システムであって、
    前記複数のノードのうち少なくとも所定の複数組織の各ノードは、前記各ノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成するものである、
    ことを特徴とするデータ連携管理システム。
11. 分散台帳システムを構成する複数のノードのいずれかであって、
    前記複数のノードにおいて所定の外部システムから取得されるデータの間の相違に関して、許容範囲を規定した許容範囲ルールを保持し、前記各ノードが前記データに関して発行したトランザクションについて、前記許容範囲ルールに従った当該データの間の相違に関する許容可否の判定を経ることで、前記データの間の相違を許容して合意形成するものである、
    ことを特徴とするノード。

Images