JP2020161092A - システム間連携方法およびノード - Google Patents

Abstract

【課題】単一信頼点が生じない環境下で、処理の透明性を確保しつつ、効率的で適宜なＢＣ間連携処理を実現可能とする。【解決手段】複数の分散台帳システム各々を構成するノード１０００が、他の分散台帳システム１上のプログラムからの呼び出し処理に関して、当該呼び出し処理の識別情報を管理して重複処理の有無を判定し、所定ポリシに基づいて前記呼び出し処理の重複排除を実行した上で、当該呼び出し処理を実行する構成とする。【選択図】図１

Description

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

従来、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた取引を、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）による直接的な取引で代替する技術が登場した。すなわち、ブロックチェーン（以下、ＢＣとも称する）を用いた分散台帳技術である。

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

また、当該分散台帳技術の応用例として、スマートコントラクト（以下、ＳＣとも称する）も提案されている。このＳＣは、複雑な取引条件や多様なアプリケーションにも分散台帳技術を適用可能とするもので、取引データだけでなく取引条件を記載したロジックとなる。
上述のＳＣに関する従来技術としては、ＳＣの実行機能を有する分散台帳基盤に関する技術（非特許文献１および非特許文献２参照）が提案されている。

また、いわゆるコンソーシアム型の分散台帳基盤も提案されている。この分散台帳基盤は、特定業界のコンソーシアムやサプライチェーンに関係する複数企業など、特定の複数または一つの団体、人により許可されたコンピュータのみが取引の承認者となるものである。こうしたコンソーシアム型の分散台帳基盤では、承認者を選ぶ管理主体が存在するため、取引承認のスピードを早められるメリットがある。

こうして進展してきた各種の分散台帳基盤では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも称する）を受け入れて、各ノードでＴＸを実行し、当該ＴＸの実行結果を保持することにより、複数ノード上で情報（台帳）を共有することとなる。また、上述のＴＸに対して予め決めたロジックを実行するＳＣ実行機能を備えている。

一方、ＢＣ技術の適用が、異なる業種や異なる利用シーンで進むことも想定されている。その場合、現実世界の商取引を写像するために、複数のＢＣシステム、またはＢＣシステムとＢＣ以外のシステム間で取引を連携動作させる必要が生じる。

そこで、そうした連携動作の実現に関する技術（非特許文献３および非特許文献４参照）も提案されている。例えば、非特許文献３の技術においては、ＢＣシステムとは別に、連携用システムを構築する。そしてこの連携用システムが、ＢＣ内の状態変化を監視し、状態変化が起きた場合、ＢＣシステム外のシステムに対して、状態変化に応じた処理を実行する。また、非特許文献４の技術においては、ＢＣシステム同士の連携のために、連携用ＢＣを別途用意し、アプリからのアクセスを全て連携用ＢＣ経由とすることで連携を実現している。

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

例えば、非特許文献３の技術においては、連携する各ＢＣとは別に連携用システムを設けることで連携を実現可能としている。しかしながら、連携に伴う処理は、ＢＣを用いていない当該連携用システムで実行される。そのため処理の透明性を確保できない。

一方、非特許文献４の技術においては、連携に伴う処理を連携用ＢＣのＳＣで記述することで、処理の透明性確保が可能としている。ただし、連携用ＢＣの情報を参照し、連携する各ＢＣを呼び出すためのノードが、ＢＣシステム外に必要となる。そのため当該ノードが単一信頼点かつ単一障害点となってしまい、システム全体としてＢＣを活用する価値が低下する。

他方、複数のＢＣシステム、またはＢＣシステムとＢＣ以外のシステム間での連携処理も含めた一連の処理の透明性を確保し、かつシステムにおける単一信頼点、障害点を作らないためには、連携する各システムに存在する複数組織のノード同士で連携する方法が考えられる。

しかし、呼出し元がＢＣシステムである場合、ＢＣシステムにおける各ノードでは、ＳＣの持つ相互検証性により同一の処理が実行される。そのため、呼出し元ＢＣの各ノードからのリクエストにより、呼出し先システムで重複した処理が実行され、誤った処理結果になるケースがある。また、正しい処理結果を得られたとしても、実行意味のない冗長な処理が発生しうる。

そこで本発明の目的は、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、効率的で適宜なＢＣ間連携処理を実現可能とする技術を提供することにある。

上記課題を解決する本発明のシステム間連携方法は、複数の分散台帳システム各々を構成するノードが、他の分散台帳システム上のプログラムからの呼び出し処理に関して、当該呼び出し処理の識別情報を管理して重複処理の有無を判定し、所定ポリシに基づいて前記呼び出し処理の重複排除を実行した上で、当該呼び出し処理を実行する、ことを特徴とする。

また、本発明のノードは、複数の分散台帳システム各々を構成するノードであって、他
の分散台帳システム上のプログラムからの呼び出し処理に関して、当該呼び出し処理の識別情報を管理して重複処理の有無を判定し、所定ポリシに基づいて前記呼び出し処理の重複排除を実行した上で、当該呼び出し処理を実行する演算装置を備える、ことを特徴とする。

本発明によれば、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、効率的で適宜なＢＣ間連携処理が実現可能となる。

実施例１による計算機システムの概略を説明するための図である。 実施例１に係る計算機システムの論理的な構成概念を示した図である。 実施例１に係る計算機システムの一例の構成図である。 実施例１に係るリクエスト管理テーブルの一例を示す図である。 実施例１に係るＴＸ実行処理のフローチャートである。 実施例１に係るノード毎に実施される重複リクエストのプロキシ処理のフローチャートである。 実施例１に係るイベント通知による更新処理のフローチャートである。 実施例２に係るリクエスト管理テーブルの一例を示す図である。 実施例２に係るノード跨りで実施される重複リクエストのプロキシ処理のフローチャートである。 実施例２に係る、ノード跨りで実施されるリクエスト管理テーブルの更新処理のフローチャートである。 実施例３に係るリクエスト管理テーブルの一例を示す図である。 実施例３に係るプロキシ処理のフローチャートである。

幾つかの実施例を、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。
なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。
そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。
さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信デバイス、管理Ｉ／Ｆ、データＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。
また、プログラムを主語として開示された処理は管理サーバ（管理計算機）等の計算機、情報処理装置が行う処理としてもよい。

また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。
また、各種プログラムは、ハイパーバイザ型もしくはコンテナ型といった仮想化環境上で実行されてもよい。
以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。
管理サーバが表示用情報を表示する場合は管理サーバが管理システムである。また、管理サーバと表示用計算機との組み合わせも管理システムである。

また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。
−−−実施例１−−−
＜システム構成＞
本実施例に係る計算機システムについて説明する。図１は、実施例１による計算機システムの概略を説明するための図である。

ここで例示する計算機システム１は、複数の分散台帳システムすなわちブロックチェーンシステム１、２から構成されている。また、それぞれのブロックチェーンシステム１、２には、クライアントノード２０００がアクセス可能に接続されている。

こうした計算機システム１においては、クライアントノード２０００がＴＸを発行し、このＴＸの相互検証のためにブロックチェーンシステム１の各分散台帳ノード１０００がＴＸ実行要求を受け付け、ブロックチェーンシステム２の分散台帳ノード１０００にそれぞれ処理要求を出すにあたり、重複する処理要求のフィルタリングをプロキシＳＣ１２２０が行った上で、当該処理の実行を業務ＳＣ１２１０にリクエストする。このことで、不正な処理や冗長な処理の実行を防ぐ。なお、上述のＴＸは、本発明における「呼び出し処理」に該当し、また以後は処理要求と称する（以下同様）。

この際、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０を用いて処理要求の実行状況を管理する。実施例１では、リクエスト管理テーブル１１３０は、分散台帳ノード１０００それぞれで管理される。

一方、後述する実施例２では、リクエスト管理テーブル１１３０は分散台帳ノード１０００を跨って共有管理される。他方、後述する実施例３では、処理要求の内容により、分散台帳ノード１０００それぞれでのリクエスト管理テーブル１１３０の管理と、分散台帳ノード１０００を跨ったリクエスト管理テーブル１１３０の共有管理とを使い分ける。

図２は、実施例１に係る計算機システム１の論理的な構成概念を示した図である。ブロックチェーンシステム間連携において、連携する各ブロックチェーンシステム１、２は、複数組織の持つ複数の分散台帳ノード１０００から構成される。

各ブロックチェーンシステム１、２の各参加組織の各分散台帳ノード１０００同士、所定の合意水準で合意形成しながらＴＸを実行し、当該ＴＸの実行結果を保持することにより、情報（台帳）を共有することとなる。また、上述のＴＸに対してＳＣとして予め決めたロジックを実行する。

図２に示す例では、ブロックチェーンシステム１に参加する組織は、組織１、２、３、４、ブロックチェーンシステム２に参加する組織は、組織１、２、５と、連携するそれぞれのブロックチェーンシステムに参加する組織が一部重複する例を示している。しかしながら、この形態例に限らず、各ブロックチェーンシステムの間で完全に参加組織が一致していても、或いは完全に異なっていても良い。

また、組織毎に、分散台帳ノード１０００以外にクライアントノード２０００、及びメ
ンバ管理ノード３０００を保有している例を示している。しかしながら、複数組織を跨ってクライアントノード２０００、及びメンバ管理ノード３０００を共有しても良く、図２の例示した形態に限定されない。

図３は、実施例１に係る計算機システム１の構成例を示す図である。本実施例に係る計算機システム１は、一台以上の分散台帳ノード１０００、一台以上のクライアントノード２０００、一台以上のメンバ管理ノード３０００を備える。

なお、各ノードは、ネットワーク１０に接続され互いに接続可能となっている。ネットワーク１０はＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等、どのようなネットワークでも良い。

また、分散台帳ノード１０００は通常複数存在し、コンソーシアムを構成する主体（例えば、複数の事業者、複数の組織、複数のベンダ）によってそれぞれ運営、管理されることを想定する。

こうした分散台帳ノード１０００は、メモリ１１００、通信デバイス１３００、プロセッサ１４００、出力デバイス１５００、入力デバイス１６００、および記憶デバイス１７００を備えている。これらは分散台帳ノード１０００内の内部バス１８００を介して互いに接続される。

このうちメモリ１１００には、ブロックチェーン１１１０、共有情報管理テーブル１１２０、リクエスト管理テーブル１１３０、構成・性能管理テーブル１１４０、業務スマートコントラクト１２１０、プロキシスマートコントラクト１２２０、トランザクション発行部１２３０、トランザクション管理部１２４０、コンセンサス管理部１２５０、およびスマートコントラクト実行・管理部１２６０（以後、ＳＣ実行・管理部１２６０）が格納される。

また、通信デバイス１３００は、分散台帳ノード１０００をネットワーク１０に接続するためのネットワークインターフェイスカード等の適宜なデバイスである。分散台帳ノード１０００は、通信デバイス１３００を利用し、ネットワーク１０を通して、クライアントノード２０００上で動作するプログラム、及びメンバ管理ノード３０００上で動作するプログラムと通信できる。
また、プロセッサ１４００は、メモリ１１００上に展開されている各種プログラムを実行する演算装置である。
また、出力デバイス１５００は、分散台帳ノード１０００が実行した処理結果を出力するデバイスであり、例えばディスプレイ等である。

また、入力デバイス１６００は、ブロックチェーンシステム管理者やブロックチェーンシステム利用者が分散台帳ノード１０００に指示を入力するためのデバイスであり、例えばキーボード等である。

また、記憶デバイス１７００は、情報を格納するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ等の記憶媒体である。

分散台帳ノード１０００は、ＳＣ実行／管理部１２６０の機能を介して、ＳＣのデプロイを実施した上で、トランザクション管理部１２４０の機能によりネットワーク１０を介してＴＸを受け付けて、コンセンサス管理部１２５０の機能によって、他のノードとの間で当該ＴＸを受け入れてよいかの合意形成を行う。

また、分散台帳ノード１０００は、合意形成がなされたらＳＣ実行／管理部１２６０の機能を介して、デプロイ済みのＳＣに対する実行を行い、当該ＴＸの履歴をブロックチェーン１１１０に、その実行結果に基づくステート情報を共有情報管理テーブル１１２０に記録する。
本実施例におけるＳＣは、業務スマートコントラクト１２１０とプロキシスマートコントラクト１２２０の二つである。
このうち業務スマートコントラクト１２１０は、業務システム毎にビジネスロジックを実装するプログラムである。
また、プロキシスマートコントラクトは、ブロックチェーンシステム間連携処理を実装するプログラムである。

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

なお、各種の業務に関するスマートコントラクト１２１０、及びプロキシスマートコントラクト１２２０の情報も、ブロックチェーン１１１０、及び共有情報管理テーブル１１２０において格納、管理される。
一方、クライアントノード２０００は、業務プログラム２２１０により実現される業務の関係者によって利用されることを想定する。

図３で例示するクライアントノード２０００は、メモリ２１００、通信デバイス１３００、プロセッサ１４００、出力デバイス１５００、入力デバイス１６００、および記憶デバイス１７００を備えている。これらはクライアントノード１０００内の内部バス１８００を介して互いに接続される。

このうちメモリ２１００には、業務情報管理テーブル２１１０、業務プログラム２２１０、構成・性能情報収集プログラム２２２０、およびトランザクション発行部２２３０が格納される。

業務プログラム２２１０は、ユーザからの業務に関する情報の入力を受け、業務情報管理テーブル２１１０に当該情報を蓄積する。加えて、業務プログラム２２１０は、トランザクション発行部２２３０を介して、当該情報を含むＴＸを発行し、当該ＴＸを分散台帳ノード１０００に対して送信する。

なお、業務プログラム２２１０は、上述のＴＸに発行者情報を付与するものとする。この発行者情報は、メンバ管理ノード３０００より予め付与されたメンバＩＤとメンバ管理ノード３０００によってメンバ毎に発行された認証情報（秘密鍵）とを含めるものとする。

また、構成・性能情報収集プログラム２２２０は、分散台帳ノード１０００、クライアントノード２０００、分散台帳ノード１０００、およびメンバ管理ノード３０００の構成情報、性能情報等を収集するためのプログラムである。
その他のクライアントノードの構成要素については、分散台帳ノード１０００と同様であるため説明を省略する。
一方、メンバ管理ノード３０００は、ブロックチェーンシステム１、２への参加者に対して認証情報（秘密鍵）を発行する役割を担う。

このメンバ管理ノード３０００は、メモリ３１００、通信デバイス１３００、プロセッサ１４００、出力デバイス１５００、入力デバイス１６００、および記憶デバイス１７００を備えている。これらはメンバ管理ノード１０００内の内部バス１８００を介して互いに接続される。
上述のメモリ３１００には、メンバ管理テーブル３１１０、メンバ管理プログラム３２１０が格納される。
このうちメンバ管理プログラム３２１０は、コンソーシアムに参加するメンバの認証情報の新規発行やＴＸ実行時の認証機能を提供する。
メンバ管理プログラム３２１０では、秘密鍵と公開鍵のペアを用いて、参加メンバの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。
こうしたメンバ管理に関する秘密鍵や公開鍵などの鍵情報は、メンバ・アクセス権管理テーブル３１１０に格納、管理される。

ここで、上述の分散台帳ノード１０００におけるトランザクション管理部１２４０は、ＴＸを受け付けた際に、メンバ管理ノード３０００におけるメンバ管理プログラム３２１０の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認することとなる。
その他のメンバ管理ノードの構成要素については、分散台帳ノード１０００と同様であるため説明を省略する。

なお、図３に示す例では、分散台帳ノード１０００、クライアントノード２０００、およびメンバ管理ノード３０００のいずれも、各種プログラム及びテーブルは、メモリに格納されているが、記憶デバイス１７００または他の記憶媒体（図示しない）に格納されても良い。
この場合、プロセッサ１４００は、プログラム実行時にメモリ上に対象のプログラムを読みだし、読みだしたプログラムを実行する。

続いて図４は、実施例１に係るリクエスト管理テーブル１１３０の一例を示す図である。リクエスト管理テーブル１１３０には、プロキシＳＣ１２２０により格納された、連携に係る処理要求の情報が格納される。

一例として、リクエスト管理テーブル１１３０には、ＲｅｑｕｅｓｔＩＤ １１３１、
Ｒｅｑｕｅｓｔ ＮｏｄｅＩＤ １１３２、Ｒｅｑｕｅｓｔ Ｃｏｎｔｅｎｔ１１３３、Ｓ
ｔａｔｕｓ １１３４、Ｒｅｓｕｌｔ １１３５のフィールドがある。
このうちＲｅｑｕｅｓｔＩＤ １１３１には、別のブロックチェーンシステムから送信
された処理要求を一意に識別するための識別子が格納される。

また、Ｒｅｑｕｅｓｔ ＮｏｄｅＩＤ １１３２には、処理要求を送信してきた別のブロックチェーンシステムにおける分散台帳ノード１０００を一意に識別するための識別子が格納される。また、Ｒｅｑｕｅｓｔ Ｃｏｎｔｅｎｔ １１３３には、処理要求の内容が格納される。

また、Ｓｔａｔｕｓ １１３４には、処理実行状態が格納される。図４の具体例では、
処理が完了していればＳｔａｔｕｓ １１３４に"Ｆｉｎ"が格納され、処理が実行中であ
れば"Ｐｒｏｃｅｓｓｉｎｇ"が格納され、処理が待機状態であれば"Ｗａｉｔｉｎｇ"が格納される例を示している。ただし、こうした格納値に限定されない。

また、Ｒｅｓｕｌｔ １１３５には、処理要求に対する処理の実行結果が格納される。
図４では具体例として、処理が成功していれば"Ｓｕｃｃｅｓｓ"と格納され、処理が完了
していない場合は"-"と格納される例を示しており、加えて、処理が失敗していれば"Ｆａｉｌｅｄ"の実行結果の情報が格納されることを想定しているが、これに限定されない。
なお、本発明におけるリクエスト管理情報の形態は、ここで例示したリクエスト管理テーブル１１３０に限定されることは無い。

例えば、連携に係る処理要求を識別可能な情報が格納されていれば良い。例えば、クライアントノード２０００が発行したトランザクションＩＤの情報や、処理要求を送信してきた別のブロックチェーンシステムを識別するための識別情報や、処理要求を送信してきた別のブロックチェーンシステムの種別情報、処理結果の詳細な内容、たとえばエラーコードやエラー内容等が格納されても良い。
＜フロー例１＞

続いて図５は、実施例１に係る計算機システム１におけるＴＸ実行処理のフローチャートである。本処理４０００は、分散台帳ノード１０００が、クライアントノード２０００におけるＴＸ発行部２２３０が業務プログラム２２１０の指示により発行したＴＸを受信することにより開始する（ステップ４００１）。

そして、分散台帳ノード１０００は、ＴＸ内の処理単位毎に、当該分散台帳ノード１０００が属するブロックチェーンシステムへの処理か、あるいは別のブロックチェーンシステムに対する処理かを判定する（ステップ４００２）。

この判定処理自体は、ＴＸ管理部１２４０で判定するものとし、発行されるＴＸそのものにいずれのブロックチェーンシステムに対する処理かについての情報が入っていることを想定している。

上述の判定の結果、当該分散台帳ノード１０００が属するブロックチェーンシステムへの処理の場合（ステップ４００２：Ｙｅｓ）、ＳＣ実行・管理部１２６０が、業務スマートコントラクト１２１０を実行し、発行されたＴＸの処理内容に応じて、ブロックチェーン１１１０及び共有情報管理テーブル１１２０を更新する（ステップ４００３）。

一方、上述の判定の結果、別のブロックチェーンシステムに対する処理の場合（ステップ４００２：Ｎｏ）、分散台帳ノード１０００は、連携処理を実行する（ステップ５０００）。

例えば、ブロックチェーンシステム１に「ＲｅｑｅｓｔＩＤ１：Ｗｒｉｔｅ（"ＸＹＺ
Ｏｗｎｅｒ"，Ｂ（ｔｅｎｔａｔｉｖｅ）)」、ＢＣシステム２に「ＲｅｑｅｓｔＩＤ２：Ｗｒｉｔｅ（"Ａ"， Ｒｅａｄ（"Ａ"）＋１００）；Ｗｒｉｔｅ（"Ｂ", Ｒｅａｄ（"
Ｂ"）―１００)」、ＢＣシステム１に「ＲｅｑｅｓｔＩＤ３：Ｗｒｉｔｅ（"ＸＹＺ Ｏ
ｗｎｅｒ"，Ｂ)」という３つの処理を実行するＴＸが発行された場合は、ＴＸ実行処理４０００において、ステップ４００３、ステップ５０００、ステップ４００３の順に処理が実行された後、ＴＸ実行処理完了となる。
ここで、連携処理５０００としてブロックチェーンシステムを呼び出す際には、処理要求にアクセスのための認証情報を付属させた上で実行する。

例えば、認証情報として、呼び出す側のブロックチェーンシステムの分散台帳ノード１０００の情報を、呼び出される側のブロックチェーンシステムのメンバ管理ノード３０００にあらかじめ登録しておくことで、当該分散台帳ノード用の秘密鍵・公開鍵情報を発行しておき、ＴＸ実行時には、呼び出す側で、当該秘密鍵情報を認証情報として付属させてリクエストを行うことで、呼び出される側のブロックチェーンシステムのメンバ管理ノード３０００からＴＸの実行許可を得ることが可能となる。

これ以外の方法、例えば、分散台帳ノード１０００ではなく、ＴＸを実行するユーザの情報を、呼び出される側のブロックチェーンシステムのメンバ管理ノード３０００にあらかじめ登録しておき、当該ユーザの秘密鍵情報を認証情報として付属させてリクエストをおこなうなど、他の方法を用いて認証情報の引き継ぎを行っても良い。

また、ブロックチェーンシステムを跨った認証情報として、ユーザに一対一で紐付くような情報、例えば指紋情報、声紋情報、静脈情報等を用いることにより、呼び出す側のブロックチェーンシステムで得た認証情報を、リクエストに付属させて呼び出し、呼び出される側のブロックチェーンシステムのメンバ管理ノード３０００からＴＸの実行許可を得るなどしても良い。いずれにしても例示の形態に限定されない。

また、実現方式によっては、ステップ４００３、ステップ５０００のように、ＳＣ実行に伴いすぐに更新処理を実行する場合以外に、非特許文献２に記載の方式のように、処理のシミュレーションフェーズと、処理の実行フェーズの二段階で更新処理を実行する場合がある。

この場合、ステップ４００３では、属するブロックチェーンシステムへの処理のシミュレーションを実施し、ステップ５０００の連携処理では、処理を実行するのではなく、実行予定の登録を行う、シミュレーションを実行して結果を呼出し側に返す、あるいはシミュレーションによる仮実行結果の登録を行うなどがおこなわれる。
このシミュレーションフェーズで、実行フェーズにおける実行に係るリソースを、実行予定、実行結果の登録に伴い予約しておくなどしても良い。

そして、ＴＸ内の処理単位毎のループが終了した後、属するブロックチェーンシステムへの処理の実行が実施され、リモート呼出しあるいはイベント通知等によって、シミュレーションフェーズで登録しておいた実行予定の内容を実行する、あるいはシミュレーション済みの処理を実行する。なお、処理の実行フェーズにおける、イベント通知による更新処理については、図７において説明する。
また図５において、連携処理における呼出しは同期的に実施されても良く、非同期的に実施されても良い。

非同期的に実施される場合は、呼び出される側における処理の実行状況を、呼び出す側から定期的にポーリングして監視する、イベント監視するなどしておくことで、ＴＸ内の処理単位毎のループが終わった後、呼び出される側における処理の成否も確認した上で、次の処理に進むことが可能となる。
＜フロー例２＞

図６は、実施例１に係るブロックチェーンシステム間の連携処理において、呼び出される側のブロックチェーンシステム（図１におけるブロックチェーンシステム２）における分散台帳ノード１０００上で動作するプロキシＳＣ１２２０が実行する処理のフローチャートである。

本処理５０００は、図５に示したＴＸ実行処理４０００において呼び出されることで開始する（ステップ５００１）。また本処理は、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００それぞれにおいて、実行される。

まず、プロキシＳＣ１２２０が、リクエスト管理テーブル１１３０の情報を取得する（ステップ５００２）。また、プロキシＳＣ１２２０は、ステップ５００１で受信した実行要求と同一のＲｅｑｕｅｓｔ ＩＤ１１３１を持つ情報が、ステップ５００２での取得情
報に存在するかどうかを判定する（ステップ５００３）。

上述の判定の結果、存在する場合（ステップ５００３：Ｙｅｓ）、プロキシＳＣ１２２０は、ステップ５００２での取得情報におけるＳｔａｔｕｓカラム１１３４の情報をチェックする（ステップ５００４）。

この結果、Ｓｔａｔｕｓカラム１１３４が「完了」を示すエントリが存在しない場合（ステップ５００４：Ｎｏ）、プロキシＳＣ１２２０は、呼び出し処理すなわち処理要求（クライアントノード２０００のＴＸ発行部２２３０が業務プログラム２２１０の指示により発行したＴＸに起因するもの。以下同様）が、呼び出される側のブロックチェーンシステムの同一の分散台帳ノード１０００において既に実行開始されており、かつ処理が完了していないと判断し、当該実行要求を一定時間の待機状態にし（ステップ５００５）、ステップ５００４に戻る。

一方、ステップ５００４で、Ｓｔａｔｕｓカラム１１３４が完了を示すエントリが存在する場合（ステップ５００４：Ｙｅｓ）、プロキシＳＣ１２２０は、同一ＴＸに起因する呼び出し処理が既に完了していると判断し、実行結果を確認する（ステップ５００６）。

上述の確認の結果、実行結果が成功の場合（ステップ５００６：Ｙｅｓ）、プロキシＳＣ１２２０は、同一のＲｅｑｕｅｓｔ ＩＤ１１３１を持つ情報のＲｅｓｕｌｔカラム１
１３５の情報を取得する（ステップ５００７）。

また、プロキシＳＣ１２２０は、ステップ５００７で得た情報をリクエスト管理テーブル１１３０に書き込み（ステップ５００８）、ステップ５０１４以降の処理を実行する。

一方、ステップ５００３で、同一のＲｅｑｕｅｓｔ ＩＤ１１３１を持つ情報が存在し
ない場合（ステップ５００３：Ｎｏ）、またはステップ５００６で実行結果が失敗であった場合（ステップ５００６：Ｎｏ）、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０に、当該処理要求の情報をＳｔａｔｕｓカラム１１３４に対し「実行中」として登録する（ステップ５００９）。

ここで処理失敗のケースとしては、実行処理において不正なパラメータが与えられた、実行権限が無かった、処理途中でエラー条件に該当した、等の場合が考えられる。

このようにあらかじめ決められた該当するエラーが返ってくる場合は、エラーと判断して、処理結果をリクエスト管理テーブル１１３０に書き込むことが考えられる。

また、その他の処理失敗のケースとしては、負荷がかかるなどして実行処理が停止してしまった、処理が重くて時間がかかっているなどが考えられ、このような場合は、処理実行タイムアウトを設けておき、ステップ５０１１で処理実行結果を取得できない場合でも、一定時間経過したら処理を打ち切り、ステップ５０１２でタイムアウトエラーの結果をリクエスト管理テーブル１１３０に書き込むことが考えられる。
次に、プロキシＳＣ１２２０は、業務ＳＣ１２１０に処理要求を出し（ステップ５０１０）、実行結果情報を受信する（ステップ５０１１）。

また、プロキシＳＣ１２２０は、ステップ５０１２で、リクエスト管理テーブル１１３０の当該処理要求を示すエントリのＳｔａｔｕｓカラム１１３４を処理完了の状態に更新し、Ｒｅｓｕｌｔカラム１１３５に処理実行結果を登録する。

ここで、実行結果が成功ではなかった場合（ステップ５０１３：Ｎｏ）、プロキシＳＣ
１２２０は、ステップ５００２に戻り、リトライを実行するか、あるいは同一ＴＸである他の処理要求の状況確認から再度実行し、同一識別情報を持ち、待機状態である、同一分散台帳ノード１０００における他の呼び出し処理を再開を実行する。

なお、実行結果が成功であった場合（ステップ５０１３：Ｙｅｓ）、プロキシＳＣ１２２０は、呼出した側のブロックチェーンシステム（図１におけるブロックチェーンシステム１）に結果を返す（ステップ５０１４）。

ステップ５００８の処理実行後にステップ５０１４の処理を実行する場合、処理実行結果は、同一ＴＸに起因して、呼び出す側のブロックチェーンシステムにおける別の分散台帳ノード１０００からの呼び出し処理により実行された結果となっている。

ここでは、呼出される側のブロックチェーンシステムにおいて、同一ＴＸに起因する呼び出し処理のうち、最初にリクエスト管理テーブル１１３０に書き込まれた呼び出し処理を無条件で実行することとしたが、これに限定されず、例えば、プロキシＳＣ１１２０において、呼び出し処理を一定時間キューイングしておき、同じＲｅｑｕｅｓｔ Ｃｏｎｔ
ｅｎｔを持つ呼び出し処理が、一定数以上キューイングされた場合に限り実行するなどしても良い。

これにより、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００において受け取った同一Ｒｅｑｕｅｓｔ ＩＤを持つ呼び出し処理の中に、不正のある呼び
出し処理が上記一定数以下あり、当該呼び出し処理が最初にリクエスト管理テーブル１１３０に書き込まれた場合にも、誤って実行せずに済む。

また、リクエスト管理テーブル１１３０に格納された情報は、ブロックチェーンシステム間の呼び出し処理に関するログ情報として、各分散台帳ノード１０００毎に管理され、一定時間経過した場合や、業務ＳＣを動作させるにあたって必要な数のリプライを呼出す側のブロックチェーンに返信した場合等、呼び出し処理管理の情報が不要になった場合には削除するなどが行われる。
また、ステップ５０１１で受信した処理結果が失敗だった場合に、ステップ５０１０に戻りリトライを実施するなどしても良い。

また、当該連携処理５０００が一定時間経っても成功しない場合には、処理途中であっても呼出し元に処理失敗の結果を送ることで、処理を終了することが可能である。

また、ステップ５０１３で失敗を一定数以上繰り返すようであれば、当該スレッドでの処理は待機状態で止めたままにし、同一ＴＸに起因する他スレッドでの処理が成功するのを待つなどしても良く、これに限定されない(図示しない)。

また、ここでは、ステップ５００１で処理実行要求を受信し、ステップ５０１４で処理実行結果を呼出し元に返す処理を記載したが、これに限定されず、例えば、非同期にステップ５０００の処理を実行して処理実行結果を格納しておき、呼出し元が定期的にその処理実行結果をポーリングすることで、連携を実現しても良い。
＜フロー例３＞

図７は、処理のシミュレーションフェーズと、処理の実行フェーズの二段階で更新処理を実行する場合に限り必要な、イベント通知による更新処理のフローチャートである。

本処理９０００は、図５に示したＴＸ内の処理単位毎のループが終了した後に、属するブロックチェーンシステムへの処理の実行が実施された後の処理にあたる。

呼び出す側のブロックチェーンシステム(ブロックチェーンシステム１)の分散台帳ノード１０００から、呼び出される側のブロックチェーンシステム(ブロックチェーンシステ
ム２)の分散台帳ノード１０００に対して、実行完了イベントが発行され、呼び出される
側のブロックチェーンシステムの分散台帳ノード１０００が当該イベントを受信することで、処理を開始する（ステップ９００１）。

イベント受信のためには、処理のシミュレーションフェーズでの連携処理実行時に、ＩＰアドレス等のイベント受信のために必要な情報、及びイベント通知を受けたい旨を示す情報を、呼び出す側のブロックチェーンシステムの分散台帳ノード１０００に設定しておくなどの必要がある。

このイベント連携処理９０００では、まず呼び出される側のブロックチェーンシステムのプロキシＳＣ１２２０が、呼び出す側のブロックチェーンシステムからの実行終了イベントを受信する（ステップ９００１）。
次に、プロキシＳＣ１２２０は、受信したイベントが実行成功を示すイベントか否かを判定する (ステップ９００２)。

上述の判定の結果、成功を示すイベントであった場合 (ステップ９００２：Ｙｅｓ)、
プロキシＳＣ１２２０は、処理のシミュレーションフェーズで登録しておいた実行予定の内容を実行する、シミュレーション済みの処理を実行する、あるいは成功イベントの中に呼び出される側のブロックチェーンシステムで実行すべき処理を記載しておき、その内容を実行するなど処理の実行をおこない、イベント連携処理を終了する（ステップ９００３）。
ここで処理の実行に失敗した場合には、シミュレーションフェーズで登録しておいた実行内容や、処理のシミュレーション結果の削除をおこなう。

また、ステップ９００１で受信したイベントが成功イベントをステップ９００２で判定する際、受信したイベント数あるいは受信したイベント数のうち成功イベント数が一定数以上になった場合に、ステップ９００３の実行処理をおこなうなどしても良く、これに限定されない。

以上、本実施例によれば、ブロックチェーンシステム間の連携において、呼び出される側のブロックチェーンシステムに連携のためのプロキシ機能を持つＳＣを用意することで、単一信頼点無く、無駄なく正しい連携処理を実現することが可能となる。

これにより、例えば商流に利用されるブロックチェーンシステムと、金流に利用されるブロックチェーンシステムとが、それぞれの要件に基づいて個別に構築されている場合に、決済まで結びつけた資産の取引、譲渡をおこなうことが可能となる。そのため、現実世界の商取引をブロックチェーンを活用したシステム上で実現可能となる。

ここで、一般にブロックチェーンシステムで利用される基盤は、仮想通貨に特化、性能を重視等の特徴を考慮して選定されることが多いため、一種類のブロックチェーンシステム基盤に統一される可能性は低い。よって、個々のブロックチェーンシステムがそれぞれ構築され、互いに連動させる必要性が出るケースも多くなることが想定される。

なお、本実施例では呼び出す側のブロックチェーンシステムの分散台帳ノード１０００それぞれが処理の主体となり、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００それぞれに対して、処理の実行を要求するケースを想定している。
そのため、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００毎に
、呼び出し処理を一つずつ実行する必要のあるケースをカバーする。
−−−実施例２−−−

本実施例に係る計算機システム１の構成例については、実施例１と同様の部分の説明については省略する。図８は、実施例２に係るリクエスト管理テーブル１１３０の一例を示す図である。
本実施例におけるリクエスト管理テーブル１１３０は、ブロックチェーン内の分散台帳ノード１０００を跨って共有される点が実施例１と異なる。

この場合、リクエスト管理テーブル１１３０には、プロキシＳＣ１２２０が、ブロックチェーンシステム間の連携に係る呼び出し処理すなわち処理要求の情報を格納する。

一例として、リクエスト管理テーブル１１３０には、ＲｅｑｕｅｓｔＩＤ １１３１、
Ｒｅｑｕｅｓｔ ＮｏｄｅＩＤ １１３２、Ｒｅｃｅｉｖｅ ＮｏｄｅＩＤ １１３６、Ｒ
ｅｑｕｅｓｔ Ｃｏｎｔｅｎｔ１１３３、Ｓｔａｔｕｓ １１３４、Ｒｅｓｕｌｔ １１３
５のフィールドがある。
このうちＲｅｑｕｅｓｔＩＤ １１３１には、別のブロックチェーンシステムから送信
された処理要求を一意に識別するための識別子が格納される。

また、Ｒｅｑｕｅｓｔ ＮｏｄｅＩＤ １１３２には、処理要求を送信してきた別のブロックチェーンシステムにおける分散台帳ノード１０００を一意に識別するための識別子が格納される。

また、Ｒｅｃｅｉｖｅ ＮｏｄｅＩＤ １１３６には、呼び出されたブロックチェーン
システムにおける分散台帳ノード１０００を一意に識別するための識別子が格納される。

また、Ｒｅｑｕｅｓｔ Ｃｏｎｔｅｎｔ １１３３には、処理要求の内容が格納され、Ｓｔａｔｕｓ １１３４には、処理実行状態が格納され、Ｒｅｓｕｌｔ １１３５には、処理の実行結果が格納される。
これらのカラムに格納される値の具体例については、図４と同じであるため説明を省略する。
＜フロー例４＞

図９は、実施例２に係るブロックチェーンシステム間の連携処理において、呼び出される側のブロックチェーンシステム（図１におけるブロックチェーンシステム２）における分散台帳ノード１０００上で動作するプロキシＳＣ１２２０が実行する処理のフローチャートである。

本処理６０００は、図５に示したＴＸ実行処理４０００において呼び出されることで開始する（ステップ６００１）。本処理は、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００それぞれにおいて、実行される。
まず、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０の情報を取得する（ステップ６００２）。

また、プロキシＳＣ１２２０は、ステップ６００１で受信した処理要求と同一のＲｅｑｕｅｓｔ ＩＤ１１３１を持つ情報が、ステップ６００２での取得情報に存在するかどう
か判定する（ステップ６００３）。

本実施例では、リクエスト管理テーブル１１３０はブロックチェーンシステム内の分散台帳ノード１０００を跨って共有されるため、いずれか一つの分散台帳ノード１０００に
おいて、該当するＴＸすなわち処理要求の実行が開始されている場合、取得情報が存在することになる。

上述の判定の結果、存在する場合（ステップ６００３：Ｙｅｓ）、プロキシＳＣ１２２０は、同取得情報におけるＳｔａｔｕｓカラム１１３４の情報をチェックする（ステップ６００４）。

上述の結果、Ｓｔａｔｕｓカラム１１３５が完了であるエントリが存在しない場合（ステップ６００４：Ｎｏ）、プロキシＳＣ１２２０は、呼び出し処理（クライアントノード２０００のＴＸ発行部２２３０が業務プログラム２２１０の指示により発行したＴＸに起因する）すなわち処理要求が、呼び出される側のブロックチェーンシステムのいずれかの分散台帳ノード１０００において既に実行開始されており、かつ処理が完了していないと判断し、当該処理要求を一定時間の待機状態にし（ステップ６００５）、ステップ６００４に戻る。

一方、上述の判定の結果、ステップ６００４でＳｔａｔｕｓカラム１１３４が完了状態となっているエントリが存在する場合（ステップ６００４：Ｙｅｓ）、プロキシＳＣ１２２０は、同一ＴＸに起因する呼び出し処理が既に完了していると判断し、実行結果を確認する（ステップ６００６）。

上述の結果、実行結果が成功の場合（ステップ６００６：Ｙｅｓ）、プロキシＳＣ１２２０は、同一のＲｅｑｕｅｓｔ ＩＤ１１３１を持つ情報のＲｅｓｕｌｔカラム１１３５
の情報を取得する（ステップ６００７）。
また、プロキシＳＣ１２２０は、当該情報をリクエスト管理テーブル１１３０に書き込み（ステップ６００８）、ステップ６０１４以降の処理を実行する。

また、プロキシＳＣ１２２０は、同一のＲｅｑｕｅｓｔ ＩＤ １１３１を持つ情報のＲｅｓｕｌｔカラム１１３５の情報を取得し（ステップ６００６）、ステップ７０００以降の処理を実行する。

一方、ステップ６００３で、同一のＲｅｑｕｅｓｔ ＩＤ １１３１を持つ情報が存在しない場合（ステップ６００３：Ｎｏ）、またはステップ６００６で実行結果が失敗であった場合（ステップ６００６：Ｎｏ）、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０に、当該処理要求の情報をＳｔａｔｕｓカラム１１３４が実行中として登録する（ステップ７０００）。ここでのリクエスト管理テーブル１１３０への登録処理については、図１０において説明する。
続いて、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０への情報の登録に成功したかどうかを判定する（ステップ６００９）。
上述の判定の結果、登録に失敗した場合（ステップ６００９：Ｎｏ）、プロキシＳＣ１２２０は、再度ステップ６００３の判定処理から実行する。
一方、上述の判定の結果、登録に成功した場合（ステップ６００９：Ｙｅｓ）、プロキシＳＣ１２２０は、ステップ６０１０に進む。
ステップ６０１０では、プロキシＳＣ１２２０は、業務ＳＣ１２１０に処理要求を出し、実行結果情報を受信する（ステップ６０１１）。

なお、ここで処理失敗のケースとしては、実行処理において不正なパラメータが与えられた、実行権限が無かった、処理途中でエラー条件に該当した、等の場合が考えられる。

このようにあらかじめ決められた該当するエラーが返ってくる場合は、エラーと判断して、処理結果をリクエスト管理テーブル１１３０に書き込むことが考えられる。
また、その他の処理失敗のケースとしては、負荷がかかるなどして実行処理が停止してしまった、処理が重くて時間がかかっているなどが考えられ、

このような場合は、処理実行タイムアウトを設けておき、ステップ６０１１で処理実行結果を取得できない場合でも、一定時間経過したら処理を打ち切り、ステップ７０００でタイムアウトエラーの結果をリクエスト管理テーブル１１３０に書き込むことが考えられる。
また、ステップ６０１１で受信した処理結果が失敗だった場合に、ステップ６０１０に戻りリトライを実施するなどしても良い。

また、当該連携処理６０００が一定時間経っても成功しない場合には、処理途中であっても呼出し元に処理失敗の結果を送ることで、処理を終了することが可能である。

また、ステップ６０１３で失敗を一定数以上繰り返すようであれば、当該スレッドでの処理は待機状態で止めたままにし、同一ＴＸに起因する他スレッドでの処理が成功するのを待つなどしても良く、これに限定されない(図示しない)。

また、ここでは、ステップ５００１で処理実行要求を受信し、ステップ５０１４で処理実行結果を呼出し元に返す処理を記載したが、これに限定されず、例えば、非同期にステップ５０００の処理を実行して処理実行結果を格納しておき、呼出し元が定期的にその処理実行結果をポーリングすることで、連携を実現しても良い。

続いて、プロキシＳＣ１２２０は、ステップ６０１２で、リクエスト管理テーブル１１３０の当該処理を示すエントリのＳｔａｔｕｓカラム１１３４を処理完了の状態に更新し、Ｒｅｓｕｌｔカラム１１３５に処理実行結果を登録する。

ここで、実行結果が成功ではなかった場合（ステップ６０１３：Ｎｏ）、プロキシＳＣ１２２０は、ステップ６００３に戻り、リトライを実行するか、あるいは同一ＴＸである他の呼び出し処理すなわち処理要求の状況確認から再度実行し、同一識別情報を持ち、待機状態である、同一ノードにおける他の呼び出し処理を再開を実行する。

実行結果が成功であった場合（ステップ６０１３：Ｙｅｓ）、プロキシＳＣ１２２０は、呼出した側のブロックチェーンシステム（図１におけるブロックチェーンシステム１）に結果を返す（ステップ６０１４）。

ステップ６００８の処理実行後にステップ６０１４の処理を実行する場合は、処理実行結果は、同一ＴＸに起因して、呼び出す側のブロックチェーンシステムにおける別のノードからの呼び出し処理により実行された結果となっている。

ここでは、呼出される側のブロックチェーンシステムにおいて、同一ＴＸに起因する呼び出し処理のうち、最初にリクエスト管理テーブル１１３０に書き込まれた処理を無条件で実行することとしたが、これに限定されない。

また、リクエスト管理テーブル１１３０に格納された情報は、ブロックチェーンシステム間の呼び出し処理に関するログ情報として、分散台帳ノード１０００を跨って管理され、一定時間経過した場合や、業務ＳＣ１２１０を動作させるにあたって必要な数のリプライを呼出す側のブロックチェーンに返信した場合等、呼び出し処理すなわち処理要求の管理の情報が不要になった場合には情報へのアクセス不可にするなどが行われる。
＜フロー例５＞

図１０は、実施例２に係るブロックチェーンシステム間の連携処理において、プロキシＳＣ１２２０がリクエスト管理テーブル１１３０の更新を実行する処理のフローチャートの一例である。

本処理７０００は、図９に示した連携処理６０００において呼び出されることで開始する。本実施例では、ブロックチェーンシステム内の分散台帳ノード１１１０を跨って、当該リクエスト管理テーブル１１３０の情報が共有される。

まず、プロキシＳＣ１１２０が、更新ＴＸを発行する（ステップ７００１）。また、プロキシＳＣ１２２０は、分散台帳ノード１０００間で当該ＴＸに対する合意形成処理を実行する（ステップ７００２）。

最後に、プロキシＳＣ１２２０は、合意形成処理結果を判定する（ステップ７００３）。この判定の結果、合意形成成功であれば（ステップ７００３：Ｙｅｓ）、プロキシＳＣ１２２０は、リクエスト管理テーブル１１３０を更新し、処理を終了する（ステップ７００４）。

ここでは、リクエスト管理テーブル１１３０をブロックチェーンを用いて保持することで、分散台帳ノード１０００の各間でその情報を共有する例を示しているが、これに限定されない。共有リソースへのアクセスを同期化する手段を提供できれば良く、例えば分散ロックマネージャを用いるなどしても良い。

以上、本実施例によれば、実施例１と同様の効果を、別構成でも実現可能となる。具体的には、本実施例では、呼び出される側のブロックチェーンシステムのいずれか一つの分散台帳ノード１０００が処理の主体となり、同ブロックチェーンシステム内の他の分散台帳ノード１０００それぞれに対して、処理の実行を要求するケースを想定している。

ここで、呼び出す側のブロックチェーンシステムの各分散台帳ノード１０００が、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００として、同一の分散台帳ノード１０００を呼び出すケースと、異なる分散台帳ノード１０００を呼び出すケースがあるが、いずれもカバーする。

異なる分散台帳ノード１０００を呼び出す方法としては、例えば、呼ぶ出す側のブロックチェーンシステムの分散台帳ノード１０００がランダムに選択するケースや、分散台帳ノード１０００毎に決まった分散台帳ノード１０００を呼び出すよう設定しておく等の方法が考えられるが、これに限定されない。

いずれのケースにおいても、呼び出される側のブロックチェーンシステムの中の一つの分散台帳ノード１０００において、呼び出し処理を一つ実行するケースとなる。
−−−実施例３−−−

本実施例に係る計算機システム１の構成例については、実施例１と同様の部分の説明については省略する。図１１は、実施例３に係るリクエスト管理テーブル１１３０の一例を示す図である。

この場合、リクエスト管理テーブル１１３０がブロックチェーンシステム内の分散台帳ノード１０００毎に共有されるケースと、ブロックチェーンシステム内の分散台帳ノード１０００を跨って共有されるケースを切り替えて管理する。
図１１に例示するリクエスト管理テーブル１１３０には、プロキシＳＣ１２２０が、ブロックチェーンシステム間の連携に係るリクエストの情報を格納する。

本実施例のリクエスト管理テーブル１１３０では、Ｒｅｑｕｅｓｔ Ｔｙｐｅ１１３７
のフィールドが含まれている。このフィールドには、ブロックチェーンシステム間の連携処理が密連携か疎連携かを表す情報が格納される。
具体的には、密連携の場合は"Ｔｉｇｈｔ"、疎連携の場合は"Ｌｏｏｓｅ"と格納する例を記載しているが、これに限定されない。

ここで密連携とは、実施例１で示した、呼び出す側のブロックチェーンシステムの分散台帳ノード１０００それぞれが処理の主体となり、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００それぞれに対して、処理の実行を要求するケースを表す。

一方、疎連携とは、実施例２で示した、呼び出される側のブロックチェーンシステムの任意の分散台帳ノード１０００が処理の主体となり、同ブロックチェーンシステムの他の分散台帳ノード１０００それぞれに対して、処理の実行を要求するケースを表す。その他のカラムについては、図８と同じであるため説明を省略する。

図１１において、リクエスト管理テーブル１１３０として一つのテーブル形式で示しているが、本実施例において、リクエスト管理テーブル１１３０のＲｅｑｕｅｓｔ Ｔｙｐ
ｅ１１３７が密結合のエントリの情報は、Ｒｅｃｅｉｖｅ Ｎｏｄｅ ＩＤで示される、呼び出される側のブロックチェーンシステムのノード毎に情報を持つ。

一方、リクエスト管理テーブル１１３０のＲｅｑｕｅｓｔ Ｔｙｐｅ１１３７が疎結合
のエントリの情報は、呼び出される側のブロックチェーンシステムの分散台帳ノード１０００の間で情報を共有する。
＜フロー例６＞

図１２は、実施例３に係るブロックチェーンシステム間の連携処理において、呼び出される側のブロックチェーンシステム（図１におけるブロックチェーンシステム２）における分散台帳ノード１０００上で動作するプロキシＳＣ１２２０が実行する処理のフローチャートである。
本処理８０００は、図５に示したＴＸ実行処理４０００において呼び出されることで開始する（ステップ８００１）。
まず、プロキシＳＣ１２２０は、ＴＸにおけるリクエスト種別が疎結合か密結合かを判定する（ステップ８００２）。
上述の判定の結果、疎結合の場合（ステップ８００２：Ｙｅｓ）、プロキシＳＣ１２２０は、図９のステップ６００３以降の処理を実行する。
一方、上述の判定の結果、密結合の場合（ステップ８００２：Ｎｏ）、プロキシＳＣ１２２０は、図６のステップ５００３以降の処理を実行する。

ここで、ＴＸには、リクエスト種別が疎結合か密結合かを判断するための情報が含まれ、例えば、呼び出し処理において利用されるプロトコルの種類、例えばＲＥＳＴ ＡＰＩ なのか、ブロックチェーンシステムの提供する独自ＡＰＩなのか等により、ＲＥＳＴ Ａ
ＰＩであれば疎結合、独自ＡＰＩであれば密結合などと、して判断をおこなうことができるが、判断内容はこれに限定されない。
例えば、呼出し先のブロックチェーンシステムの分散台帳ノード１０００で提供されるＡＰＩの種類などにより判断をおこなっても良い。

以上、本実施例によれば、ブロックチェーンシステム間連携において、実施例１に示した密結合の呼出しと、実施例２に示した疎結合の呼出しが混在する環境においても、プロ
キシＳＣ１２２０において処理を切り替えることで、単一信頼点無く、無駄なく正しい連携処理を実現することが可能となる。

連携する内容や、ブロックチェーンシステム基盤の種別に応じて、疎結合や密結合は決まるため、図２に示したような1対1でのブロックチェーンシステム間連携の場合、業務に応じて密結合と疎結合を切り替わることが想定される。

また、複数のブロックチェーンシステムからの呼出しを、呼び出される側のブロックチェーンが受信する場合は、呼び出す側のブロックチェーン毎に切り替わることなどが想定される。

ブロックチェーンシステムを利用する業務は多岐にわたり、また、異なる特徴を持つブロックチェーン基盤の種別を利用して、システム全体を構築するケースも多いことが想定されるため、本実施例による活用範囲は幅広いことが想定される。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、効率的で適宜なＢＣ間連携処理が実現可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のシステム間連携方法において、前記ノードが、前記重複排除の結果、実行を許可されなかった呼び出し処理を待ち状態とし、当該呼び出し処理に関する情報をリクエスト管理情報として管理する、としてもよい。

これによれば、重複処理を排除しつつも、呼び出し元の各ノードに対してのリプライは漏れなく行うことが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記ポリシに基づく重複排除として、同じ識別情報を保持する複数の呼び出し処理のうち、最初に受信した1
つの呼び出し処理に絞り込む、としてもよい。

これによれば、呼び出し処理の迅速な処理と重複排除とを両立することが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記ポリシに基づく重複排除として、同じ識別情報を保持する複数の呼び出し処理のうち、ノード間での合意形成を経て任意の1つの呼び出し処理に絞り込む、としてもよい。

これによれば、呼び出し処理の確からしさ（真正なものらしさ）を確保した上で重複排除を実行することが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、当該ノード毎に前記リクエスト管理情報を管理し、ノード毎に前記呼び出し処理の重複排除を実行して一度のみ実行する、としてもよい。

これによれば、各ノードで同じ呼び出し処理を複数受ける状況に対応して重複排除を効
率良く行うことが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記呼び出し処理が他のノードにおいて失敗した際に、当該呼び出し処理と識別情報が同一で待ち状態にある他の呼び出し処理を前記リクエスト管理情報にて特定し、前記特定した呼び出し処理の実行を再開する、としてもよい。

これによれば、同じ呼び出し処理を複数受け付ける状況を有効活用して、ノードや通信環境の不具合や或いは真正でない呼び出し処理の混入など種々の状況に由来する処理失敗の発生に対応し、全体として処理効率を良好に維持できることとなる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、当該ノードの属する分散台帳システム内のノード同士で前記リクエスト管理情報を共有し、当該ノード同士の間を跨って前記呼び出し処理の重複排除を実行し一度のみ実行する、としてもよい。

これによれば、或る分散台帳システムに属するノードそれぞれが、同じ呼び出し処理を受け付ける状況に対応して、処理の重複排除を効率良く行うことが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記ノード同士の間で相互承認を取ったうえで、前記リクエスト管理情報をブロックチェーンに格納し、当該ノード同士の間で共有する、としてもよい。

これによれば、リクエスト管理情報を同じ分散台帳システム内で効率的かつ的確に共有可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、分散台帳システムから呼び出される処理が、別システムにおいて失敗した際に、同一識別情報を持ち、待ち状態である、同一システム内の任意のノードにおける処理を再開する、としてもよい。

これによれば、同じ分散台帳システムのノードそれぞれが、同じ呼び出し処理を受け付ける状況を有効活用して、ノードや通信環境の不具合や或いは真正でない呼び出し処理の混入など種々の状況に由来する処理失敗の発生に対応し、全体として処理効率を良好に維持できることとなる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記呼び出し処理の発信元である前記他の分散台帳システムのノードにリプライする際、前記呼び出し処理の処理結果を、前記リクエスト管理情報において待ち状態とされている各呼び出し処理のリプライとして複製しリプライする、としてもよい。

これによれば、呼び出し処理の重複排除と確かなリプライとを両立することが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

また、本実施形態のシステム間連携方法において、前記ノードが、前記呼び出し処理に付帯する所定の認証情報を取得し、前記ノードが所属する分散台帳システムへのアクセスを前記認証情報に基づいて管理する、としてもよい。

これによれば、分散台帳システムの間で呼び出し処理の授受を行う際、相応のセキュアな環境で処理を行うことが可能となる。ひいては、単一信頼点が生じない環境下で、処理の透明性を確保しつつ、より効率的で適宜なＢＣ間連携処理が実現可能となる。

１ 計算機システム
１０ ネットワーク
１０００ 分散台帳ノード
１１００ メモリ
１１１０ ブロックチェーン
１１２０ 共有情報管理テーブル
１１３０ リクエスト管理テーブル
１１４０ 構成・性能管理テーブル
１２１０ 業務スマートコントラクト
１２２０ プロキシスマートコントラクト
１２３０ トランザクション発行部
１２４０ トランザクション管理部
１２５０ コンセンサス管理部
１２６０ スマートコントラクト実行・管理部
１３００ 通信デバイス
１４００ プロセッサ（演算装置）
１５００ 出力デバイス
１６００ 入力デバイス
１７００ 記憶デバイス
１８００ 内部バス
２０００ クライアントノード
２１００ メモリ
２１１０ 業務情報管理テーブル
２２２０ 構成・性能情報収集プログラム
２２３０ トランザクション発行部
３０００ メンバ管理ノード
３１００ メモリ
３１１０ メンバ管理テーブル
３２１０ メンバ管理プログラム

Claims (12)

1. 複数の分散台帳システム各々を構成するノードが、
   他の分散台帳システム上のプログラムからの呼び出し処理に関して、当該呼び出し処理の識別情報を管理して重複処理の有無を判定し、所定ポリシに基づいて前記呼び出し処理の重複排除を実行した上で、当該呼び出し処理を実行する、
   ことを特徴とするシステム間連携方法。
2. 前記ノードが、
   前記重複排除の結果、実行を許可されなかった呼び出し処理を待ち状態とし、当該呼び出し処理に関する情報をリクエスト管理情報として管理する、
   ことを特徴とする請求項１に記載のシステム間連携方法。
3. 前記ノードが、
   前記ポリシに基づく重複排除として、同じ識別情報を保持する複数の呼び出し処理のうち、最初に受信した1つの呼び出し処理に絞り込む、
   ことを特徴とする請求項１に記載のシステム間連携方法。
4. 前記ノードが、
   前記ポリシに基づく重複排除として、同じ識別情報を保持する複数の呼び出し処理のうち、ノード間での合意形成を経て任意の1つの呼び出し処理に絞り込む、
   ことを特徴とする請求項１に記載のシステム間連携方法。
5. 前記ノードが、
   当該ノード毎に前記リクエスト管理情報を管理し、ノード毎に前記呼び出し処理の重複排除を実行して一度のみ実行する、
   ことを特徴とする請求項２に記載のシステム間連携方法。
6. 前記ノードが、
   前記呼び出し処理が他のノードにおいて失敗した際に、当該呼び出し処理と識別情報が同一で待ち状態にある他の呼び出し処理を前記リクエスト管理情報にて特定し、前記特定した呼び出し処理の実行を再開する、
   ことを特徴とする請求項５に記載のシステム間連携方法。
7. 前記ノードが、
   当該ノードの属する分散台帳システム内のノード同士で前記リクエスト管理情報を共有し、当該ノード同士の間を跨って前記呼び出し処理の重複排除を実行し一度のみ実行する、
   ことを特徴とする請求項１に記載のシステム間連携方法。
8. 前記ノードが、
   前記ノード同士の間で相互承認を取ったうえで、前記リクエスト管理情報をブロックチェーンに格納し、当該ノード同士の間で共有する、
   ことを特徴とする請求項７に記載のシステム間連携方法。
9. 前記ノードが、
   分散台帳システムから呼び出される処理が、別システムにおいて失敗した際に、同一識別情報を持ち、待ち状態である、同一システム内の任意のノードにおける処理を再開する、
   ことを特徴とする請求項７に記載のシステム間連携方法。
10. 前記ノードが、
    前記呼び出し処理の発信元である前記他の分散台帳システムのノードにリプライする際、前記呼び出し処理の処理結果を、前記リクエスト管理情報において待ち状態とされている各呼び出し処理のリプライとして複製しリプライする、
    ことを特徴とする請求項２に記載のシステム間連携方法。
11. 前記ノードが、
    前記呼び出し処理に付帯する所定の認証情報を取得し、前記ノードが所属する分散台帳システムへのアクセスを前記認証情報に基づいて管理する、
    ことを特徴とする請求項１に記載のシステム間連携方法。
12. 複数の分散台帳システム各々を構成するノードであって、
    他の分散台帳システム上のプログラムからの呼び出し処理に関して、当該呼び出し処理の識別情報を管理して重複処理の有無を判定し、所定ポリシに基づいて前記呼び出し処理の重複排除を実行した上で、当該呼び出し処理を実行する演算装置を備える、
    ことを特徴とするノード。

Images