JP7490394B2 - 情報共有支援方法、及び情報共有支援システム - Google Patents

Description

本発明は、情報共有支援方法、及び情報共有支援システムに関する。

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

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

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

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

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

このようにＢＣ技術の適用が様々な業種や利用シーンで進む中、ブロックチェーンシステムが商取引に関する性能要件を現実的なレベルで満たす必要が生じており、この性能の向上の実現を目指す技術（非特許文献３参照）が提案されている。非特許文献３の技術においては、複数のリクエストをＢＣに一括送信し、ＢＣにおける合意形成処理を並列化することで性能向上を実現しようとする旨が開示されている。

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

ところが、商取引が活発化し、大量のストリームデータを扱う場合には、商取引全体にわたる性能（スループット性能）の向上がより重大な課題となる。

この点、非特許文献３の技術によれば、ＢＣにおける合意形成処理の性能向上が期待される。しかし、ＢＣでは、書込みを直列におこなう仕組みにより、各組織のノード同士の状態の一致を担保することが必要であり、この書き込み性能がスループット性能に大きく影響する。しかし、非特許文献３では、ＢＣにおける書込み処理は実行順序を一意に決めた上で直列に行われるので、非特許文献３の技術では、スループット性能の向上にとって重要な書込み処理の性能の向上が期待できない。

本発明はこのような現状に鑑みてなされたものであり、その目的は、情報共有に係る通信のスループット性能（例えば、合意形成処理、書込み処理に関する性能）を向上させることが可能な情報共有支援方法、及び情報共有支援システムを提供することにある。

前記した課題を解決するための本発明の一つは、情報処理装置が、互いに通信可能な複数のノードでトランザクションの履歴をブロックチェーンデータの形式で共有するブロックチェーンシステムである情報処理システムに対する、所定の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る複数の要求を受信するリクエスト受信処理と、統合する要求が満たすべき条件、及び、前記情報処理システムが処理可能な形式にするために不要な情報を規定した所定のルールに従って、前記受信した複数の要求のうち前記条件を満たす複数の要求それぞれの内容たるバリューの全てを一つのバリューに再構成すると共に、再構成したバリューに対して、前記不要な情報を削除することにより、前記条件を満たす複数の要求を、前記情報処理システムの各ノードが処理可能な形式に変換しつつ統合して、前記統合した複数の要求に係る複数の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る新たな要求を作成する統合管理処理と、前記新たな要求を前記情報処理システムに送信することにより、当該情報処理システムの各ノードに、前記統合した複数の要求に係る複数の情報を記憶させ、前記新たな要求のトランザクションを前記ブロックチェーンデータに追加させるリクエスト処理とを実行する、情報共有支援方法、とする。

前記した課題を解決するための本発明の他の一つは、互いに通信可能な複数のノードでトランザクションの履歴をブロックチェーンデータの形式で共有するブロックチェーンシステムである情報処理システムに対する、所定の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る複数の要求を受信するリクエスト受信処理と、統合する要求が満たすべき条件、及び、前記情報処理システムが処理可能な形式にするために不要な情報を規定した所定のルールに従って、前記受信した複数の要求のうち前記条件を満たす複数の要求それぞれの内容たるバリューの全てを一つのバリューに再構成すると共に、再構成したバリューに対して、前記不要な情報を削除することにより、前記条件を満たす複数の要求を、前記情報処理システムの各ノードが処理可能な形式に変換しつつ統合して、前記統合した複数の要求に係る複数の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る新たな要求を作成する統合管理処理と、前記新たな要求を前記情報処理システムに送信することにより、当該情報処理システムの各ノードに、前記統合した複数の要求に係る複数の情報を記憶させ、前記新たな要求のトランザクションを前記ブロックチェーンデータに追加させるリクエスト処理とを実行する演算装置を備える、情報共有支援システム、とする。

本発明によれば、情報共有に係る通信のスループット性能を向上させることができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

第１実施形態に係る情報共有支援システムの構成の一例を説明する図である。 統合条件テーブルの一例を示す図である。 統合ポリシテーブルの一例を示す図である。 統合ルールテーブルの一例を示す図である。 キーマッピングテーブルの一例を示す図である。 クライアントノードが備える機能の一例を説明する図である。 メンバ管理ノードが備える機能の一例を説明する図である。 分散台帳ノードが備える機能の一例を説明する図である。 情報共有支援システムにおける各情報処理装置が備えるハードウェアの一例を説明する図である。 情報共有支援処理の概要を説明するフローチャートである。 統合要否判定処理の一例を説明するフローチャートである。 リクエスト解析処理の一例を説明するフローチャートである。 リクエスト統合処理の一例を説明するフローチャートである。 リクエスト変換処理の一例を説明するフローチャートである。 第２実施形態に係る情報共有支援システムの構成の一例を示す図である。

以下、本発明の実施の形態について図面を参照しつつ説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。各図面において、複数の図を通じて同一の符号は同一の構成要素を示している。

なお、本明細書において、情報処理装置がモジュール又はプログラムを実行することを説明する場合は、モジュール又はプログラムを主語にして当該説明を行う場合がある。

また、本明細書において、「ａａａテーブル」又は「ａａａデータベース」等の用語によってデータの内容が説明されている場合があるが、これらはデータ構造を限定する趣旨ではない。したがって、このことを示すために「ａａａ情報」と呼ぶことがある。同様に、「識別情報」、「識別子」、「名称」、「ＩＤ」といういずれの用語も、ある対象を特定するための情報の意味であって、それらの意味は同じである。

［第１実施形態］
＜システム構成＞
図１は、第１実施形態に係る情報共有支援システム１の構成の一例を説明する図である。

情報共有支援システム１は、所定の業務を行う特定のメンバ（事業者、業務の関係者、ベンダ、個人等）によって構成されている組織（業界団体、管理組織、コンソーシアム等）が利用するブロックチェーンシステムである。すなわち、情報共有支援システム１は、いわゆるコンソーシアム型のブロックチェーンシステムである。

具体的には、情報共有支援システム１は、複数のクライアントノード２０００と、各クライアントノード２０００と通信可能に接続される管理ノード１０００と、各クライアントノード２０００及び管理ノード１０００と通信可能に接続されるブロックチェーンシステム５０００とを含んで構成されている。

クライアントノード２０００は、各メンバが業務に使用する情報処理装置であり、例えば、各メンバの事業所、データセンタ等に設けられる。クライアントノード２０００は、メンバの業務に係るデータ（業務データ）を作成し、作成した業務データに係る、ブロックチェーンシステム５０００に対する所定の処理要求（以下、ＴＸ、リクエスト、又はト
ランザクションデータともいう）を管理ノード１０００に送信する。

なお、本実施形態では、ＴＸは、要求の識別子たるキー（Ｋｅｙ）及び、要求の内容たるバリュー（Ｖａｌｕｅ、すなわち業務データを含むデータ）を含んで構成される（ＫＶＳ：Key-Value Store）。

ブロックチェーンシステム５０００は、複数の分散台帳ノード４０００と、メンバ管理ノード３０００とを含んで構成され、これらは互いに通信可能に接続される。ブロックチェーンシステム５０００は、例えば、所定の事業所、データセンタ等に設けられる。

このうち分散台帳ノード４０００は、情報処理装置である。各分散台帳ノード４０００は、クライアントノード２０００が送信したＴＸの履歴をブロックチェーンデータの形式で共有して記憶している。分散台帳ノード４０００は、ＴＸにおけるキー及びバリューを特定することで、ＴＸの要求に応じた業務データに関する処理を行う。ブロックチェーンデータは、例えば、ＴＸ、ハッシュ、及びナンスを含んで構成されるブロックデータを時系列的に結合することにより、ＴＸの履歴を記録したデータである。

次に、メンバ管理ノード３０００は、情報処理装置である。メンバ管理ノード３０００は、ブロックチェーンシステム５０００に参加して業務データを他のメンバと共有しようとする者（新たなクライアントノード２０００）に対して、所定の認証情報（秘密鍵）を発行することにより、その者を新たなメンバとして登録する。

管理ノード１０００は、所定の管理業者等によって管理される情報処理装置であり、例えば、管理業者の事業所、データセンタに設けられる。

管理ノード１０００は、各クライアントノード２０００から送信されてくるＴＸを受信し、これらのＴＸを所定のポリシに従って統合又は変換し、統合又は変換した処理要求をブロックチェーンシステム５０００に送信する。ブロックチェーンシステム５０００の各分散台帳ノード４０００は、統合又は変換したＴＸに基づき、ブロックチェーンデータを作成又は更新する。

このように、本実施形態に係る情報共有支援システム１は、管理ノード１０００がクライアントノード２０００と分散台帳ノード４０００との間に介在してＴＸに関する処理をフックする（例えば、ＴＸを統合する）ことで、クライアントノード２０００が発行するＴＸに関するスループット性能を向上させることができる。

なお、情報共有支援システム１における各情報処理装置の間は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、専用線等の有線又は無線の
ネットワーク９０００によって通信可能に接続される。

次に、各情報処理装置が備える機能について説明する。

＜管理ノードの機能＞
まず、管理ノード１０００の機能を説明する。

図１に示すように、管理ノード１０００は、リクエスト受信モジュール１２０５と、統合要否判定モジュール１２１０、リクエスト解析モジュール１２２０、統合モジュール１２３０、及びリクエスト変換モジュール１２５０を有する統合管理モジュール１２０６と、リクエストモジュール１２４０とを含む各モジュールにより実現される機能を備える。

また、管理ノード１０００は、統合条件テーブル１１１０、統合ポリシテーブル１１２０、統合ルールテーブル１１３０、及びキーマッピングテーブル１１４０の各テーブルを記憶している。

リクエスト受信モジュール１２０５は、複数の分散台帳ノード４０００で業務データを共有するブロックチェーンシステム５０００に対する、当該業務データに関する所定の要求（すなわち、ＴＸ、リクエスト、又はトランザクションデータ）を複数受信する。

例えば、リクエスト受信モジュール１２０５は、所定の情報をブロックチェーンシステム５０００の各分散台帳ノード４０００に書き込む旨のＴＸ（以下、ＷｒｉｔｅＴＸという）を複数受信する。

また、例えば、リクエスト受信モジュール１２０５は、複数のＷｒｉｔｅＴＸが示す各業務データのうちいずれかの業務データである対象情報の取得の要求（以下、ＲｅａｄＴＸという）をクライアントノード２０００から受信する。

統合管理モジュール１２０６は、リクエスト受信モジュール１２０５が受信した複数のＴＸ（以下、これらのＴＸを統合前ＴＸともいう。）を、所定のルール（統合条件テーブル１１１０、統合ポリシテーブル１１２０、及び統合ルールテーブル１１３０）に従って、ブロックチェーンシステム５０００の各分散台帳ノード４０００が処理可能な形式に変換しつつ統合して新たな要求（以下、統合後ＴＸという）を作成する。

例えば、統合管理モジュール１２０６は、リクエスト受信モジュール１２０５が受信した複数のＴＸに基づき、書き込みに関する統合後ＴＸを作成する。

具体的には、まず、統合要否判定モジュール１２１０は、統合条件テーブル１１１０に規定されたポリシに基づき、ＴＸの統合の要否を判断する。

そして、例えば、統合要否判定モジュール１２１０は、ブロックチェーンシステム５０００における通信負荷が所定閾値を超えるか否かを判定し、当該通信負荷が当該閾値を超えると判定した場合にのみ、統合後ＴＸを作成する。

ここで、統合条件テーブル１１１０について説明する。

（統合条件テーブル）
図２は、統合条件テーブル１１１０の一例を示す図である。統合条件テーブル１１１０には、ＴＸの統合開始要件としての、通信負荷（Ｉ／Ｏパス）に関する情報が格納される。

統合条件テーブル１１１０には、ＴＸの送信先（宛先）のノードの種類である要素タイプ１１１１と、要素タイプ１１１１に係るノードの評価項目であるメトリックタイプ１１１２と、メトリックタイプ１１１２に係る評価項目がどのような状態である場合に要素タイプ１１１１に係るノードを送信先とするＴＸの統合を行うかを示す情報であるステータス１１１３とを含む各要素で構成される、１以上のレコードを有するデータベースである。

図２に示した例では、分散台帳ノード４０００のＣＰＵ利用率が閾値を超過した場合に、ＴＸの統合が必要と判断する条件と、分散台帳ノード４０００のＷｒｉｔｅエラー率が閾値を超過した場合にＴＸの統合が必要と判断する条件とが示されている。

なお、統合条件テーブル１１１０の要素タイプ１１１１には、分散台帳ノード４０００の情報の他、所定の効果（例えば、ＴＸに対する処理負荷が低減される）が得られる処理を行う他のノードの情報が設定されてもよい。例えば、メンバ管理ノード３０００、ＴＸの順序性を保証する所定の処理（Ｏｒｄｅｒｉｎｇ Ｓｅｒｖｉｃｅ）を行うノード（図
示しない）のような、ＴＸに関する処理を行う他のノードが設定されてもよい。また、情報共有支援システム１内の各ノード間で送受信されるＴＸを転送するＩＰスイッチ（図示しない）のような、ＴＸに関する処理を間接的に行うノードが設定されてもよい。また、ステータス１１１３には、評価項目の状態の詳細な内容、例えばエラーコードやエラー内容等が格納されてもよい。

なお、統合条件テーブル１１１０の内容は、予めユーザが設定し又は後で追加してもよい。また、所定の情報処理装置が各ノードの性能の劣化又は障害の発生を監視しておき、その結果を、統合条件テーブル１１１０の各レコードに自動的に反映するようにしてもよい。例えば、ステータス１１１３の値はユーザが手動で設定してもよいし、メトリックタイプ１１１２に係る評価項目の値がステータス１１１３に自動的に設定されてもよいし、他のレコードの情報に基づいた値が自動的にステータス１１１３に設定されてもよい。

また、統合条件テーブル１１１０には、複数のレコードの内容を統合した条件を設定してもよい。例えば、複数の障害イベントが同時に発生した場合を、ＡＮＤ等の論理式を用いる等して、新たな条件を設定してもよい。

次に、図１に示すようにリクエスト解析モジュール１２２０は、ＴＸを解析することにより、統合ポリシテーブル１１２０に規定されたポリシに基づき、統合するリクエストを選定する。

例えば、リクエスト解析モジュール１２２０は、リクエスト受信モジュール１２０５が受信した複数のＴＸの種類を判定し、当該種類が所定の条件を満たす場合にのみ、統合後ＴＸを作成する。

また、リクエスト解析モジュール１２２０は、統合後ＴＸを作成する際、リクエスト受信モジュール１２０５が受信した複数のＴＸのうち、ブロックチェーンシステム５０００の各分散台帳ノード４０００が処理可能な形式にするために不要な情報を削除することにより、統合後ＴＸを作成する。

また、リクエスト解析モジュール１２２０は、複数のＴＸを統合する際、リクエスト受信モジュール１２０５が受信した複数のＴＸのうち所定のＴＸ（例えば、最初に受信したＴＸ）を受信した時から所定期間（待ち時間）を経過したと判定した場合に、統合後ＴＸの作成を開始する。

また、リクエスト解析モジュール１２２０は、前記複数のＴＸを統合する際、リクエスト受信モジュール１２０５が受信した複数のＴＸの数が所定値を超えたか否かを判定し、当該数が当該所定値を超えたと判定した場合に、統合後ＴＸの作成を開始する。

ここで、統合ポリシテーブル１１２０について説明する。

（統合ポリシテーブル）
図３は、統合ポリシテーブル１１２０の一例を示す図である。統合ポリシテーブル１１２０は、統合条件テーブル１１１０に基づきＴＸの統合を行うと決定した場合において、ＴＸの種類に応じてどのような条件が満たされた場合に当該ＴＸの統合を開始するかについてのポリシを規定した情報である。

統合ポリシテーブル１１２０は、第２ポリシを特定する情報であるポリシＩＤ１１２１と、ポリシＩＤ１１２１に係る第２ポリシにおいて、統合を開始する対象たるＴＸの種類の情報である対象リクエスト種別１１２２と、ポリシＩＤ１１２１に係るポリシにおいて統合可能なＴＸの最大数である最大リクエスト数１１２３と、ポリシＩＤ１１２１に係るポリシにおいて、最大リクエスト数１１２３に係る数のＴＸの受信待機可能時間である待ち時間１１２４とを含む各要素を有する、１以上のレコードで構成される。

ここで、対象リクエスト種別１１２２には、ＴＸを区別可能な分類の情報を登録する。例えば、直接リクエストの名称を登録してもよいし（例えば、“Ｒｅｑｕｅｓｔ Ａ”）
、全ての種別のリクエストを統合対象とする旨を示す情報を登録してもよい（例えば、“ＡＬＬ”）。

図３に示した例では、管理ノード１０００が受信した全ての種類のＴＸ（「Ａｌｌ」）のそれぞれに関して、管理ノード１０００が当該種類のＴＸを「１００」回受信した場合、又は、その種類のＴＸを所定時に受信してから「１０秒」経過した場合に（例えば、１０秒間、管理ノード１０００がその種類のＴＸの蓄積を行った場合に）、受信した当該種類の各ＴＸの統合を開始する（ポリシＩＤ１１２１が「１」のポリシ）。

また、管理ノード１０００が受信した、「一時間に１０回未満」しか読み込まれないような業務データの書き込みをブロックチェーンシステム５０００に要求するＷｒｉｔｅＴＸに関して、管理ノード１０００がその種類のＴＸを「３０００」回受信した場合、又はその種類のＴＸを所定時に受信してから「５０秒」経過した場合に、受信した当該種類の各ＴＸの統合を開始する（ポリシＩＤ１１２１が「２」のポリシ）。

すなわち、このポリシはＷｒｉｔｅＴＸにより所定のデータを書き込んだ後、当該データが読み込まれることが1時間に１０回以下しかないようなＴＸを、「Ｒｅａｄ数 ＜
１０回／ｈ」として登録している。この場合、管理ノード１０００は、これまでに受信したＴＸの履歴を取得する（例えば、後述する統合一時格納テーブルを利用する）ことにより、読み込み頻度を特定する。

次に、管理ノード１０００が受信した「Ｒｅｑｕｅｓｔ Ａ」なる種類のＴＸに関して
、管理ノード１０００がその種類のＴＸを「５００」回受信した場合、又は、その種類のＴＸを所定時に受信してから「２０秒」経過した場合に、受信した当該種類の各ＴＸの統合を開始する（ポリシＩＤ１１２１が「３」のポリシ）。

なお、以上の統合ポリシテーブル１１２０の内容は、予めユーザが設定し又は後で追加してもよい。また、統合ポリシテーブル１１２０の内容はここで例示したものに限定されない。例えば、後述の統合ルールテーブル１１３０の内容を統合ポリシテーブル１１２０に設定してもよい。

次に、図１に示すように統合モジュール１２３０は、統合ルールテーブル１１３０に規定されたルールに従ってＴＸを統合して統合後ＴＸを作成する。

例えば、統合モジュール１２３０は、統合後ＴＸを作成する際、リクエスト受信モジュール１２０５が受信した複数のＴＸのうち、ブロックチェーンシステム５０００が処理可能な形式にするために不要な情報を削除することにより、統合後ＴＸを作成する。

ここで、統合ルールテーブル１１３０について説明する。

（統合ルールテーブル）
図４は、統合ルールテーブル１１３０の一例を示す図である。統合ルールテーブル１１３０は、ＴＸの種別ごとに設定された、ＴＸの統合規則の情報である。

統合ルールテーブル１１３０は、ＴＸの種別ごとに、１又は複数設けられる（統合ルールテーブル１１３０Ａ、１１３０Ｂ、１１３０Ｃ）。

統合ルールテーブル１１３０は、統合対象のＴＸの種類であるリクエスト種類１１３１（１１３１Ａ、１１３１Ｂ、１１３１Ｃ）と、統合するＴＸが満たすべき条件である統合条件１１３２（１１３２Ａ、１１３２Ｂ、１１３２Ｃ）と、統合条件１１３２に係る条件に基づきＴＸを統合する際の付加条件（オプション情報）たる統合オプション１１３３（１１３３Ａ、１１３３Ｂ、１１３３Ｃ）とを含む各要素を有する、少なくとも１以上のレコードを有して構成される。

図４の例では、統合ルールテーブル１１３０には、「Ｒｅｑｕｅｓｔ Ａ」なる種類のリクエストに関する統合ルールテーブル１１３０Ａと、「Ｒｅｑｕｅｓｔ Ｂ」なる種類のリクエストに関する統合ルールテーブル１１３０Ｂと、「Ｒｅｑｕｅｓｔ Ｃ」なる種類のリクエストに関する統合ルールテーブル１１３０Ｃとがある。

まず、統合ルールテーブル１１３０Ａは、ＴＸの引数属性を利用した論理式により規定された統合条件１１３１Ａと、これに対応する統合オプション１１３３Ａとを備える。具体的には、統合条件１１３１Ａには、「(equal arg2) and (equal arg3) and (equal arg4)」が設定され、これは、ＴＸにおける第２引数の値が等しい、かつ第３引数の値が等しい、かつ第４引数の値が等しい、という条件を規定している。また、統合条件１１３１Ａには、「(not arg1) and (not arg6) and (not arg7)」が設定され、これは、第１引数は統合後のリクエストに不要、かつ第６引数は統合後のリクエストに不要、かつ第７引数は統合後のリクエストに不要、というオプション情報を規定している。

統合ルールテーブル１１３０Ｂは、ＴＸの引数属性を利用するのではなく、情報共有支援システム１が保持する任意の他のテーブル（同図では「テーブルＡ」）を利用した論理式により規定された統合条件１１３１Ｂと、これに対応する統合オプション１１３３Ｂとを備える。具体的には、統合条件１１３１Ｂには、「(in table A.column X) and (in table A.column Y) and (in table A.column Z)」が設定され、これは、テーブルＡのエン
トリ毎にカラムＸ、Ｙ、Ｚの値を参照し、これらのカラムＸ、Ｙ、Ｚの値と同じ文字列が含まれるＴＸ同士を統合対象とする、という条件を規定している。また、統合オプション１１３３Ｂには、“Ｎｏｎｅ”と設定され、オプション情報は存在しない。

統合ルールテーブル１１３０Ｃの統合条件１１３２Ｃには、「引数の属性が全て同じリクエストを統合の対象とする」という論理式”ｅｑｕａｌ ａｒｇ”が設定されている。また、統合オプション１１３３Ｃには、「オプション情報が存在しない」という情報“Ｎｏｎｅ”が設定されている。すなわち、統合ルールテーブル１１３０Ｃは、統合に係る各ＴＸが示す要求の内容自体は同じであるが、ＴＸに付帯する他の要素（例えば、ＴＸによる要求実行のタイミング）が異なる場合などに利用されるテーブルである。例えば、統合ルールテーブル１１３０Ｃは、任意の情報が書き込まれた回数さえわかれば良い場合等に利用される。例えば、統合ルールテーブル１１３０Ｃのポリシを適用することにより、（引数の属性の異なるＴＸをそれぞれ処理せずとも、）統合対象のＴＸの個数を統合後ＴＸに設定しつつＴＸを統合することができる。

なお、統合ルールテーブル１１３０の項目及び内容はここで例示したものに限られない。例えば、以上のような各統合ルールテーブル１１３０における情報参照先のテーブルと
しては、情報共有支援システム１内の任意のテーブルを指定してもよい。例えば、統合条件１１３２に対して、クライアントノード２０００の業務情報管理テーブル２１１０、分散台帳ノード４０００の共有情報テーブル４１２０等を設定してもよい。

また、統合ルールテーブル１１３０の統合条件１１３２および統合オプション１１３３の項目及び内容は、予めユーザが設定し又は後に追加、修正、削除等してもよい。さらに、統合ルールテーブル１１３０の数は任意であり、新たな統合ルールテーブル１１３０を追加もしくは削除し、又は、複数の統合ルールテーブル１１３０を統合してもよい。

次に、図１に示すように、リクエストモジュール１２４０は、統合後ＴＸを、分散台帳ノード４０００に送信する。

すなわち、リクエストモジュール１２４０は、統合後ＴＸをブロックチェーンシステム５０００に送信することにより、ブロックチェーンシステム５０００の各分散台帳ノード４０００に、統合前ＴＸに係る要求を処理させる。

例えば、リクエストモジュール１２４０は、統合管理モジュール１２０６が作成した統合後ＴＸをブロックチェーンシステム５０００に送信することにより、当該ブロックチェーンシステム５０００の各分散台帳ノード４０００に、複数の統合前ＴＸに係る複数の情報を記憶させる。

また、リクエストモジュール１２４０は、ブロックチェーンシステム５０００から、統合後ＴＸに対するリプライデータを受信する。

リクエスト変換モジュール１２５０は、統合前ＴＸ及び統合後ＴＸの間の対応関係を規定したキーマッピングテーブル１１４０を作成し、これを記憶する。管理ノード１０００は、このキーマッピングテーブル１１４０を用いることにより、クライアントノード２０００とブロックチェーンシステム５０００との間で送受信されるＴＸの整合性を取ることができる。

また、リクエスト変換モジュール１２５０は、キーマッピングテーブル１１４０に基づき特定される、リクエスト受信モジュール１２０５が受信したＲｅａｄＴＸに対応する所定の取得要求（統合後ＴＸに対応させた新たなＲｅａｄＴＸ）に基づき、先に書き込んだ統合後ＴＸのうちいずれかのＴＸ（業務データ）を、ブロックチェーンシステム５０００に記憶させた複数のＴＸ（業務データ）から取得し、取得したＴＸ（業務データ）を、クライアントノード２０００に送信する。

ここで、キーマッピングテーブル１１４０について説明する。

（キーマッピングテーブル）
図５は、キーマッピングテーブル１１４０の一例を示す図である。キーマッピングテーブル１１４０には、クライアントノード２０００が送信したＴＸの識別子又はキー（以下、統合前識別子、又は統合前キーという）と、当該ＴＸに対応して管理ノード１０００が送信する新たなＴＸの識別子又はキー（以下、統合後識別子、又は統合後キーという）との対応関係を示す情報が格納される。

キーマッピングテーブル１１４０は、統合前識別子が設定されるオリジナルキー１１４１と、オリジナルキー１１４１に係る統合前識別子に対応づけられた統合後識別子が設定されるインテグレートキー１１４２と、オリジナルキー１１４１に係る統合前識別子に対応する、インテグレートキー１１４２に係る統合後識別子における副識別子又は副キー（
以下、統合後副識別子、又は統合後副キーという）である統合インデックス１１４３とを含む各項目を有する、１以上のレコードで構成されるデータベースである。

図５の例では、統合前識別子が「１」に対応する副識別子は「１」であるため、この統合前識別子に係るＴＸは、統合後識別子「ＳｕｐＡ－ＤｅｍＢ－Ｏｒｄｅｒ１１１」に係るＴＸにおける１番目の要素として統合されている。同様に、統合前識別子「２」に対応する副識別子は「３」であるため、この統合前識別子に係るＴＸは、統合後識別子「ＳｕｐＡ－ＤｅｍＢ－Ｏｒｄｅｒ１１１」に係るＴＸにおける３番目の要素として統合されている。

なお、キーマッピングテーブル１１４０は、統合前ＴＸ及び統合後ＴＸの対応関係を規定したものであればよく、ここで説明したものと異なる構成であってもよい。

＜クライアントノードの機能＞
次に、図６は、クライアントノード２０００が備える機能の一例を説明する図である。クライアントノード２０００は、業務プログラム２２１０、及びトランザクション発行プログラム２２２０のそれぞれにより実現される各機能を備える。また、クライアントノード２０００は、業務情報管理テーブル２１１０を記憶している。

業務プログラム２２１０は、メンバから業務に関する情報の入力を受け付け、入力された情報に基づき業務データを作成する。業務プログラム２２１０は、この業務データを業務情報管理テーブル２１１０に蓄積する。また、業務プログラム２２１０は、入力された業務データに係るＴＸを作成する。

本実施形態では、ＴＸには少なくとも、業務データをブロックチェーンシステム５０００の各分散台帳ノード４０００にブロックチェーンデータの形態で書き込む要求であるＷｒｉｔｅＴＸと、ブロックチェーンシステム５０００の各分散台帳ノード４０００が記憶したブロックチェーンデータのうち対象の業務データを読み込む要求であるＲｅａｄＴＸとがあるものとする。

なお、業務プログラム２２１０は、作成したＴＸに所定の発行者情報を付与するものとする。この発行者情報には、メンバ管理ノード３０００が予め作成した、各メンバの認証情報（ここでは秘密鍵とするが、他の種類の情報に限定されない）が付帯しているものとする。

トランザクション発行プログラム２２２０は、業務プログラム２２１０が作成したＴＸを管理ノード１０００に送信する。

＜メンバ管理ノードの機能＞
次に、図７は、メンバ管理ノード３０００が備える機能の一例を説明する図である。メンバ管理ノード３０００は、メンバ管理プログラム３２１０により実現される機能を備える。また、メンバ管理ノード３０００は、メンバ管理テーブル３１１０を記憶している。

メンバ管理プログラム３２１０は、ブロックチェーンシステム５０００（コンソーシアム）に参加する各メンバの認証情報（秘密鍵）を作成する。

また、メンバ管理プログラム３２１０は、分散台帳ノード４０００がクライアントノード２０００からＴＸを受信した際に、このＴＸに付帯している認証情報（秘密鍵）と、この認証情報に対応する情報（ここでは、公開鍵とする）とに基づき、ＴＸを送信してきたクライアントノード２０００の認証処理、このＴＸに対する署名付与処理、及び、このＴ
Ｘに係るスマートコントラクトのメンバへの実行権限等の制御等を行う。

このように、メンバ管理プログラム３２１０は、ＴＸが正当な権限を有するメンバ（クライアントノード２０００）により送信されたものであるか否かを判定する。これにより、正当な権限を有するメンバのみが、ＴＸに関する業務を行うことができる。

次に、メンバ管理テーブル３１１０は、各メンバの認証情報（秘密鍵）、及びこれに対応する公開鍵等の情報を記憶している。

＜分散台帳ノード＞
次に、図８は、分散台帳ノード４０００が備える機能の一例を説明する図である。分散台帳ノード４０００は、トランザクション発行プログラム４２２０、トランザクション管理プログラム４２３０、コンセンサス管理プログラム４２４０、及びスマートコントラクト実行管理プログラム（以下、ＳＣ実行管理プログラム４２５０ともいう）の各プログラムにより実現される機能を備える。また、分散台帳ノード４０００は、業務スマートコントラクト４２１０、ブロックチェーンデータ４１１０、共有情報テーブル４１２０、及び構成性能テーブル４１３０の各情報を記憶している。

トランザクション発行プログラム４２２０は、ＴＸを発行する（分散台帳ノード４０００は、自らＴＸを発行することができる）。

トランザクション管理プログラム４２３０は、ネットワーク９０００を介して送信されてきたＴＸを受信する。また、トランザクション管理プログラム４２３０は、管理ノード１０００を介したクライアントノード２０００からのＴＸが示す要求に応じて、ブロックチェーンデータ４１１０から所定のデータを取得し、取得したデータの内容をクライアントノード２０００の所定の画面に表示する。

なお、前述のように、トランザクション管理プログラム４２３０がＴＸを受信した際には、メンバ管理ノード３０００はメンバ管理プログラム３２１０を実行し、当該ＴＸの送信主体（クライアントノード２０００）が正当な権限を有するメンバであるか否かを確認する。

コンセンサス管理プログラム４２４０は、他の分散台帳ノード４０００との間で、トランザクション管理プログラム４２３０が受信したＴＸを受け付けて処理するか否かについての合意形成の処理を行う。

ＳＣ実行管理プログラム４２５０は、予めデプロイされた、後述する業務スマートコントラクト４２１０を含む各スマートコントラクトを実行する。ＳＣ実行管理プログラム４２５０は、各スマートコントラクトの実行により得られた情報（例えば、ＴＸに係る業務データ）を、ブロックチェーンデータ４１１０に記憶する。

また、ＳＣ実行管理プログラム４２５０は、ＴＸの現在の状態を示す情報（ステート情報）を共有情報テーブル４１２０に記憶する。なお、ＳＣ実行管理プログラム４２５０は、各スマートコントラクトのデプロイも実施する。

次に、業務スマートコントラクト４２１０は、各業務を実行するための処理プログラム（スマートコントラクト）である。業務スマートコントラクト４２１０は、各メンバの業務に係る業務システム毎のビジネスロジックを実装している。

ブロックチェーンデータ４１１０及び共有情報テーブル４１２０は、各種の業務に関する業務スマートコントラクト４２１０に関する情報である。

ブロックチェーンデータ４１１０は、トランザクション管理プログラム４２３０が受信したＴＸの履歴の情報である。ブロックチェーンデータ４１１０は、各分散台帳ノード４０００間で共有される。

共有情報テーブル４１２０は、統合条件テーブル１１１０、統合ポリシテーブル１１２０、及び統合ルールテーブル１１３０を記憶している。これらのテーブルは、各分散台帳ノード４０００間で共有される。

構成性能テーブル４１３０は、分散台帳ノード４０００等の情報処理装置の構成情報を記憶している。本実施形態では、この構成情報は、各情報処理装置のハードウェアの仕様又はハードウェアの性能の情報であるものとする。すなわち、構成情報は、例えば、情報処理装置のＣＰＵ又はメモリの仕様、情報処理装置で実行されているスマートコントラクトの情報、情報処理装置のＣＰＵ利用率又は書き込みエラー率等である。

＜ハードウェア＞
ここで、図９は、情報共有支援システム１における各情報処理装置（管理ノード１０００、クライアントノード２０００、メンバ管理ノード３０００、及び分散台帳ノード４０００）が備えるハードウェアの一例を説明する図である。これらの情報処理装置は、ＣＰＵ等のプロセッサ１４００、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の記憶デバイス１５００、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶デバイス１１００、キーボード又はタッチパネル等の入力デバイス１６００、モニタ又はディスプレイ等の出力デバイス１７００、他の情報処理装置と通信を行うネットワークインターフェイスカード等の通信デバイス１３００とを備え、これらがバスなどの内部通信線１８００により接続される。

以上に説明した、情報共有支援システム１における各情報処理装置の各機能は、専用ハードウェアにより、又は、プロセッサ１４００が記憶デバイス１５００又は補助記憶デバイス１１００に記憶されているプログラム（モジュール）を読み出し、また、入力デバイス１６００、出力デバイス１７００、通信デバイス１３００等を用いることにより実現される。また、各プログラム（モジュール）は、各情報処理装置が読み取り可能な記録媒体にあらかじめ記録されていてもよいし、記憶媒体又は所定の通信ネットワークを介して、必要なときに導入されてもよい。また、各プログラムは、ハイパーバイザ型もしくはコンテナ型といった仮想化環境上で実行されてもよい。

＜処理＞
次に、情報共有支援システム１において行われる処理について説明する。情報共有支援システム１は、管理ノード１０００がクライアントノード２０００からのＴＸに対して所定の処理を行うと共にブロックチェーンシステム５０００がこのＴＸに関する情報共有を行う処理（以下、情報共有支援処理という）を実行する。

＜情報共有支援処理＞
図１０は、情報共有支援処理の概要を説明するフローチャートである。情報共有支援処理は、例えば、管理ノード１０００及びブロックチェーンシステム５０００が起動した後に実行される。

まず、管理ノード１０００は、クライアントノード２０００からの、ＴＸの受信を待機する（ｓ１）。

具体的には、例えば、クライアントノード２０００の業務プログラム２２１０が、所定の業務に関するＴＸを作成し、トランザクション発行プログラム２２２０がそのＴＸを送信する。管理ノード１０００のリクエスト受信モジュール１２０５は、この送信されたＴＸの受信を待機する。

リクエスト受信モジュール１２０５は、クライアントノード２０００からＴＸを受信すると、受信したＴＸの要求を判定する（ｓ３）。

受信したＴＸがＷｒｉｔｅＴＸである場合は（ｓ３：ＷｒｉｔｅＴＸ）、統合要否判定モジュール１２１０は、受信したＷｒｉｔｅＴＸを含む複数のＷｒｉｔｅＴＸを一つのＴＸ（統合後ＴＸ）に統合するか否かを判定することを含む統合要否判定処理ｓ５０００の実行を開始する（ｓ５）。その後は、ｓ１の処理が繰り返される。

他方、受信したＴＸがＲｅａｄＴＸである場合は（ｓ３：ＲｅａｄＴＸ）、リクエスト変換モジュール１２５０は、受信したＲｅａｄＴＸを統合後ＴＸに対応するデータに変換することを含むリクエスト変換処理ｓ８０００を実行する。その後は、ｓ１の処理が繰り返される。

以下、統合要否判定処理ｓ５０００及びリクエスト変換処理ｓ８０００の詳細を説明する。

＜統合要否判定処理＞
図１１は、統合要否判定処理ｓ５０００の一例を説明するフローチャートである。統合要否判定モジュール１２１０は、ＷｒｉｔｅＴＸを受信すると（ｓ５００１）、受信したＷｒｉｔｅＴＸが示す宛先ノード（構成要素）の性能の情報を取得する（ｓ５００２）。

具体的には、例えば、統合要否判定モジュール１２１０は、予め取得してキャッシュしておいた又は本ステップで取得した構成性能テーブル４１３０を参照することで、受信したＷｒｉｔｅＴＸが示す宛先の性能の情報を取得する。

なお、構成性能テーブル４１３０の取得の他の方法としては、例えば、各分散台帳ノード４０００のトランザクション発行プログラム４２２０が構成性能テーブル４１３０の情報を管理ノード１０００に送信する合意を当該分散台帳ノード４０００間でした上で、各分散台帳ノード４０００が管理ノード１０００に対して構成性能テーブル４１３０を定期的に送信し、管理ノード１０００がこの構成性能テーブル４１３０を取得する、といった方法でもよい。このように、構成性能テーブル４１３０の取得の方法及びタイミングについては特に限定されない。

統合要否判定モジュール１２１０は、ｓ５００２で取得した性能の情報と、統合条件テーブル１１１０とを比較することで、ブロックチェーンシステム５０００の通信負荷が高いか否か、すなわち、受信したＷｒｉｔｅＴＸを他のＷｒｉｔｅＴＸと統合するか否かを判定する（ｓ５００３）。

具体的には、例えば、統合要否判定モジュール１２１０は、統合条件テーブル１１１０のうち要素タイプ１１１１に、受信したＷｒｉｔｅＴＸが示す宛先（ノード）が設定されているレコードの内容を全て取得し、取得したレコードのメトリックタイプ１１１２及びステータス１１１３により特定される性能の条件を、受信したＷｒｉｔｅＴＸが示す宛先（ノード）が満たしているか否かを判定する。

例えば、宛先が分散台帳ノード４０００である場合、図２の例では、「ＣＰＵ Ｕｓａ
ｇｅ」（メトリックタイプ１１１２）が「閾値超過」（ステータス１１１３）であるとい
う条件を各分散台帳ノード４０００が満たしているか否か（例えば、分散台帳ノード４０００のＣＰＵ使用率が９９％を超えているか否か）が判定される。

受信したＷｒｉｔｅＴＸを他のＷｒｉｔｅＴＸと統合すると判定した場合は（ｓ５００３：Ｙｅｓ）、統合要否判定モジュール１２１０は、次述するｓ５００４の処理を実行する。他方、受信したＷｒｉｔｅＴＸを他のＷｒｉｔｅＴＸと統合しないと判定した場合は（ｓ５００３：Ｎｏ）、統合要否判定モジュール１２１０は、ＷｒｉｔｅＴＸが示す処理を行うべく、後述するｓ５００５の処理を実行する。

ｓ５００４において統合要否判定モジュール１２１０は、リクエスト解析モジュール１２２０に、統合後ＴＸを作成すべくＷｒｉｔｅＴＸを解析する要求であるリクエスト解析処理要求を送信する（ｓ５００４）。その後は、統合後ＴＸが示す処理を実行すべくｓ５００５の処理が行われる。

ｓ５００５において統合要否判定モジュール１２１０は、ＷｒｉｔｅＴＸに関する処理（ＷｒｉｔｅＴＸの処理（ｓ５００３：Ｎｏの場合）、又は、統合後ＴＸの処理（ｓ５００３：Ｙｅｓの場合））の実行要求（すなわち、統合後ＴＸ）をリクエストモジュール１２４０に送信する（ｓ５００５）。リクエストモジュール１２４０は、この統合後ＴＸを、各分散台帳ノード４０００に送信する。

その後、各分散台帳ノード４０００は、受信した統合後ＴＸをブロックチェーンデータ４１１０に追加する。なお、各分散台帳ノード４０００は、このブロックチェーンデータ４１１０に関する所定の合意形成処理を行う。以上で、統合要否判定理は終了する（ｓ５００６）。

なお、以上の統合要否判定処理では、統合要否判定モジュール１２１０は、ＴＸの統合の要否を判定するため性能の情報（構成性能テーブル４１３０）を取得したが、その他の情報を取得してもよい。例えば、統合要否判定モジュール１２１０は、性能情報そのものを取得するのではなく、各ノードが各タイミングで作成した性能に関する情報（例えば、性能の閾値の判定の結果の情報、性能劣化のエラー情報等）を取得してもよい。

また、性能の劣化が発生していなくても常にＴＸの統合を行う場合も想定されるため、統合要否判定モジュール１２１０は、前記のｓ５００３の処理を実行せず、常にｓ５００４以降の処理を実行してもよい。

また、クライアントノード２０００が、管理ノード１０００を介して分散台帳ノード４０００にアクセスするか、又は直接分散台帳ノード４０００にアクセスするかを切り替えられるようにしてもよい。具体的には、例えば、クライアントノード２０００が、ＴＸに対応づけられたアクセス先の情報（例えば、分散台帳ノード４０００のアドレス及びサービス名称の情報、又は、管理ノード１０００のアドレス及びサービス名称の情報）を送信し、この情報に対応した主体（管理ノード１０００又は分散台帳ノード４０００）が当該ＴＸを処理する。

＜リクエスト解析処理＞
図１２は、リクエスト解析処理の一例を説明するフローチャートである。まず、リクエスト解析モジュール１２２０は、統合要否判定モジュール１２１０からリクエスト解析処理要求（ｓ５００４）を受信すると、ｓ５００１で受信したＴＸの種類を特定する（ｓ６００１）。

また、リクエスト解析モジュール１２２０は、統合ポリシテーブル１１２０を取得する
（ｓ６００２）。

リクエスト解析モジュール１２２０は、ｓ６００２で取得した統合ポリシテーブル１１２０に基づき、ｓ６００１で特定した種類のＷｒｉｔｅＴＸが統合対象のＴＸであるか否かを判定すると共に、その統合に際して適用するポリシを特定する（ｓ６００３）。

具体的には、例えば、リクエスト解析モジュール１２２０は、統合ポリシテーブル１１２０の各レコードを参照し、ｓ６００１で特定したＷｒｉｔｅＴＸの種類の情報が対象リクエスト種別１１２２に設定されているレコードを全て取得し、取得したレコードのうち一つを選択する。

例えば、図８において、ＷｒｉｔｅＴＸの種類が「Ｒｅｑｕｅｓｔ Ａ」である場合、
２つのレコード、すなわち、対象リクエスト種別１１２２に「Ａｌｌ」（全ての種類のＴＸ）が設定されているポリシＩＤ１１２１が「１」のレコード、及び、対象リクエスト種別１１２２に「Ｒｅｑｕｅｓｔ Ａ」が設定されているポリシＩＤ１１２１が「３」のレ
コードが特定される。そして、これらの２つのレコードのうち１つのみが選択される。このように、判定対象の種類のＴＸに対するポリシが複数ある場合は、いずれか一つのポリシに従ってリクエストを集約する。この場合のポリシの選択方法としては、例えば、あらかじめ定められた基準（例えば、最大リクエスト数１１２３に係る値が大きい方を選択する）によって選択してもよいし、ユーザにポリシを選択させるようにしてもよい。

このようにして、統合に際して適用するポリシを特定できた場合は（ｓ６００３：Ｙｅｓ）、リクエスト解析モジュール１２２０は、統合するＴＸの種類（以下、統合種類という）の情報を含む、ＴＸの統合を要求するリクエスト統合要求を、リクエスト統合モジュール１２３０に送信し（ｓ６００４）、リクエスト解析処理を終了し統合要否判定処理に戻る（ｓ６００５）。他方、統合に際して適用するポリシを特定できなかった場合は（ｓ６００３：Ｎｏ）、リクエスト解析モジュール１２２０は、リクエスト解析処理を終了し統合要否判定処理に戻る（ｓ６００５）。

＜リクエスト統合処理＞
図１３は、リクエスト統合処理の一例を説明するフローチャートである。統合モジュール１２３０は、リクエスト解析モジュール１２２０からリクエスト統合処理要求を受信すると、統合種類のＴＸを受信した場合にそのＴＸを、所定の統合用一時格納テーブル（図示しない）に蓄積する処理を開始する（ｓ７００１）。以後、この処理は、統合種類のＴＸが統合されるまで（ｓ７００６）継続される。

なお、統合用一時格納テーブルは、例えば、ＴＸの種類ごとに、受信した各ＴＸと、各ＴＸの受信時刻と、受信したＴＸの個数（受信回数）とを対応づけたレコードを記憶した情報とする。なお、統合用一時格納テーブルは、ＴＸの種類ごとではなく、その他の単位ごとの情報でもよい。例えば、統合ルールテーブル１１３０に示されるＴＸの種類ごとの情報であってもよい。

また、統合用一時格納テーブルは、管理ノード１０００以外の場所（例えば、他の情報処理装置、所定の記憶装置、クラウド等）に、所定のタイミング（例えば、後述するＴＸの統合が実行される前）で、バックアップを作成するようにしてもよい。これにより、何らかの障害で統合用一時格納テーブルの情報を参照できなくなる場合に備えることができる。

さらに、統合モジュール１２３０は、統合ポリシテーブル１１２０から、統合種類のＴＸに関する統合条件の情報を取得する（ｓ７００２）。

具体的には、例えば、統合モジュール１２３０は、統合ポリシテーブル１１２０を参照し、対象リクエスト種別１１２２に統合種類のＴＸの情報が設定されているレコードの最大リクエスト数１１２３及び待ち時間１１２４の内容を取得する。

統合モジュール１２３０は、統合用一時格納テーブルの内容と、ｓ７００２で取得した統合条件の情報とを比較することにより、統合種類のＴＸの統合を開始するか否かを判定する（ｓ７００３－Ｓ７００４）。

まず、統合モジュール１２３０は、統合種類のＴＸを統合するために必要な待ち時間が、所定の起算時から経過しているか否かを判定する（ｓ７００３）。

具体的には、例えば、統合モジュール１２３０は、統合用一時格納テーブルのうち、統合種類のＴＸに係るレコードの内容を全て取得することにより、当該種類のＴＸを最初に受信した時刻（又は統合用一時格納テーブルに格納した時刻）から現在時刻までの時間長さが、ｓ７００２で取得した統合条件たる待ち時間を超えているか否かを判定する。なお、統合モジュール１２３０は、現在時刻の情報をどのような方法によって取得してもよいが、統合種類のＴＸを最初に受信した時刻を取得した方法と同様の方法により取得することが好ましい。

必要な待ち時間を経過している場合は（ｓ７００３：Ｙｅｓ）、統合モジュール１２３０は、後述するｓ７００５の処理を実行し、必要な待ち時間を経過していない場合は（ｓ７００３：Ｎｏ）、統合モジュール１２３０は、次述するｓ７００４の処理を実行する。

ｓ７００４において統合モジュール１２３０は、統合種類のＴＸを、所定の起算時から所定回数（最大リクエスト数）以上、受信したか否かを判定する。

具体的には、例えば、統合モジュール１２３０は、統合用一時格納テーブルのうち、統合種類のＴＸに係るレコードの内容を全て取得することにより、統合種類のＴＸを最初に受信した時刻（又は統合用一時格納テーブルに格納した時刻）以降に当該統合種類のＴＸを受信した回数が、ｓ７００２で取得した統合条件たる最大リクエスト数を超えているか否かを判定する。

統合種類のＴＸを所定回数以上受信している場合は（ｓ７００４：Ｙｅｓ）、統合モジュール１２３０は、次述するｓ７００５の処理を実行し、統合種類のＴＸを所定回数以上受信していない場合は（ｓ７００４：Ｎｏ）、統合モジュール１２３０は、ｓ７００３以降の処理を繰り返す。

ｓ７００５において統合モジュール１２３０は、統合種類のＴＸの統合を開始するべく、まず、統合ルールテーブル１１３０から、統合種類のＴＸの統合方法の情報を取得する。

具体的には、例えば、統合モジュール１２３０は、複数の統合ルールテーブル１１３０のうち、統合種類のＴＸに係る統合ルールテーブル１１３０を特定し、特定した統合ルールテーブル１１３０の統合条件１１３２及び統合オプション１１３３の内容を取得する。

統合モジュール１２３０は、ｓ７００５で取得した情報に基づき、統合種類のＴＸを統合し、新たなＴＸ（すなわち統合後ＴＸ）を作成する（ｓ７００６）。

具体的には、例えば、統合モジュール１２３０は、ｓ７００５で取得した統合ルールテ
ーブル１１３０の統合条件１１３２が示す条件に従って、統合用一時格納テーブルに記録されている統合種類のＴＸにおけるバリュー（業務データ等）の全てを一つのバリューに再構成すると共に、再構成したバリューに対して、ｓ７００５で取得した統合オプション１１３３が示すルールを適用することにより、統合後ＴＸ（統合前のＴＸと比べてバリュー部分が変更されているＴＸ）を作成する。この際、統合モジュール１２３０は、統合後ＴＸにおける所定のキー（統合後キー）を統合後ＴＸに設定する。

統合モジュール１２３０は、ｓ７００６で統合する前のＴＸ（統合前ＴＸ）と、ｓ７００６で作成した統合後ＴＸとを対応付けるべく、キーマッピングテーブル１１４０を作成又は更新する（ｓ７００７）。キーマッピングテーブル１１４０は、後述する、ＲｅａｄＴＸに係るリクエスト変換処理に用いられる。その後は、リクエスト解析処理に戻る。

具体的には、例えば、統合モジュール１２３０は、統合用一時格納テーブルに記録されている統合種類の各ＴＸの識別子（キー）をオリジナルキー１１４１に設定し、ｓ７００６で作成した統合後ＴＸの識別子（キー）をインテグレートキー１１４２に設定し、統合用一時格納テーブルに記録されている統合種類の各ＴＸに対応する統合後副キーを統合インデックス１１４３に設定した新たな１又は複数のレコードを、キーマッピングテーブル１１４０に作成する、
なお、統合モジュール１２３０は、統合用一時格納テーブルのうち、ｓ７００６までの処理により統合を行ったＴＸに関するレコードを削除（破棄）する。これにより、記憶領域の浪費を回避できる。

（統合処理の具体例）
ここで、ｓ７００６、ｓ７００７の処理の具体例について説明する。まず、クライアントノード２０００のトランザクション発行プログラム２２２０が送信したＷｒｉｔｅＴＸが、以下の３つのＲｅｑｕｅｓｔであったとする：Ｒｅｑｕｅｓｔ Ａ（１、Ｃｏｍｐａｎｙ Ａ、Ｃｏｍｐａｎｙ Ｂ、Ｔｒａｄｅ１１１、ＩＤ＿０３ａ２３Ｘ８１ｚ１９ｎｄ、１、２）、Ｒｅｑｕｅｓｔ Ａ（２、Ｃｏｍｐａｎｙ Ａ、Ｃｏｍｐａｎｙ Ｂ、Ｔｒａｄｅ１１１、ＩＤ＿ＡｄｓｆＫｊ０３４ｈａｆｋ、２、２)、Ｒｅｑｕｅｓｔ Ａ（３、Ｃｏｍｐａｎｙ Ａ、Ｃｏｍｐａｎｙ Ｂ、Ｔｒａｄｅ１１２、ＩＤ＿９３ｊｄｌｆｈｄｉｊｅｒ１、１、２）。

この場合、統合モジュール１２３０は、ｓ７００５において、統合ルールテーブル１１３０Ａにおける、「Ｒｅｑｕｅｓｔ Ａ」に係る統合条件１１３２Ａに基づき、第２引数
、第３引数、及び第４引数が同一のリクエスト（ＴＸ）を、統合用一時格納テーブルにおける統合前ＴＸの情報から取得する。そして、統合モジュール１２３０は、統合ルールテーブル１１３０Ａの統合オプション１１３３Ａに基づき、当該リクエスト（ＴＸ）から不要な引数を削除する。これにより、統合後ＴＸとして、「Ｒｅｑｕｅｓｔ Ａ´（Ｃｏｍ
ｐａｎｙＡ－ＣｏｍｐａｎｙＢ－Ｔｒａｄｅ１１１、（ＩＤ＿０３ａ２３Ｘ８１ｚ１９ｎｄ、ＩＤ＿ＡｄｓｆＫｊ０３４ｈａｆｋ））」が作成される。

この後、統合モジュール１２３０は、キーマッピングテーブル１１４０に、統合前ＴＸの第一引数（ＫＶＳ（Key-Value Store）におけるＫｅｙ相当の情報を想定）と、統合後
ＴＸの第一引数の情報との対応関係の情報を追加する。この際、統合モジュール１２３０は、統合後ＴＸの第二引数における値の順序に従い、第一引数が「１」である統合前ＴＸに対応させて、キーマッピングテーブル１１４０の統合インデックス１１４３に「１」を統合後ＴＸの統合後ＴＸサブキーとして格納し、第一引数が「２」である統合前ＴＸに対応させて、キーマッピングテーブル１１４０の統合インデックス１１４３に「２」を統合後ＴＸの統合後ＴＸサブキーとして格納する。

なお、以上のリクエスト統合処理において統合モジュール１２３０は、ＴＸの統合を開始するタイミングとして、所定の起算時からの待ち時間（ｓ７００３）及び所定の起算時からの最大リクエスト数（ｓ７００４）を考慮したが、その他の方法によりＴＸの統合の開始を決定してもよい。

例えば、統合モジュール１２３０は、最大リクエスト数又は待ち時間のいずれかのみによってＴＸの統合の開始を決定してもよい。また、統合モジュール１２３０は、他の統合タイミングを設定してもよい。例えば、統合モジュール１２３０は、各クライアントノード２０００に対応づけて設定された所定のタイムアウト値に基づき、ＴＸの統合の開始のタイミングを決定してもよい。

また、統合モジュール１２３０は、統合用一時格納テーブルに格納されたＴＸの個数が、予め定めておいた任意の固定値に達した場合に、ｓ７００４以降の処理を実行してもよい。

また、統合モジュール１２３０は、その他の統合要件に基づき、ＴＸの統合の開始を決定してもよい。例えば、統合モジュール１２３０は、クライアントノード２０００の業務情報管理テーブル２１１０に格納されている、業務の内容を示すパラメータ値に基づき、ＴＸを統合する単位を決めても良い。例えば、所定の１個の製品のために１００個の部品を購入する業務を行うため、各部品の購入に係るＴＸを扱う場合、統合モジュール１２３０は、各部品に係る１００個のＴＸの全てを統合用一時格納テーブルに格納したか否かを、製品ＩＤと各部品ＩＤと対応関係を記録した業務情報管理テーブル２１１０を参照することにより判定し、１００個全ての部品に係るＴＸを統合用一時格納テーブルに格納した場合に、これらのＴＸの統合を行うようにしてもよい。

＜リクエスト変換処理＞
図１４は、リクエスト変換処理の一例を説明するフローチャートである。まず、管理ノード１０００のリクエスト受信モジュール１２０５がＲｅａｄＴＸを受信すると（ｓ８００１）、リクエスト変換モジュール１２５０は、キーマッピングテーブル１１４０を取得する（ｓ８００２）。

リクエスト変換モジュール１２５０は、ｓ８００１で受信したＲｅａｄＴＸが、リクエスト統合処理により統合されたＴＸ（統合後ＴＸ）であるかどうかを判定する（ｓ８００３）。

ＲｅａｄＴＸが、リクエスト統合処理により統合された統合後ＴＸである場合は（ｓ８００３：Ｙｅｓ）、次述するｓ８００４の処理を実行し、ＲｅａｄＴＸが、リクエスト統合処理により統合された統合後ＴＸでない場合は（ｓ８００３：Ｎｏ）、後述するｓ８００９の処理を実行する。

ｓ８００４においてリクエスト変換モジュール１２５０は、ｓ８００２で取得したキーマッピングテーブル１１４０に基づき、ｓ８００１で受信したＲｅａｄＴＸに係るキー（統合前キー）を、対応する統合後キーに変換する。

具体的には、例えば、リクエスト変換モジュール１２５０は、キーマッピングテーブル１１４０から、ＲｅａｄＴＸに係る統合前キーがオリジナルキー１１４１に設定されているレコードを特定し、特定したレコードのインテグレートキー１１４２を取得する。

リクエスト変換モジュール１２５０は、ｓ８００４で取得した統合後キーと、ｓ８００１で受信したＲｅａｄＴＸが示す読み込み対象の業務データとを対応づけて記憶した新た
なＲｅａｄＴＸ（業務データの読み込み要求）を作成し、新たなＲｅａｄＴＸを、リクエストモジュール１２４０に送信する（ｓ８００５）。リクエストモジュール１２４０は、受信したＲｅａｄＴＸに基づき、ブロックチェーンシステム５０００の分散台帳ノード４０００から、レスポンスデータたる、読み込み対象の業務データを含むレスポンスデータを受信する。

その後、リクエスト変換モジュール１２５０は、リクエストモジュール１２４０から、レスポンスデータを受信する（ｓ８００６）。

リクエスト変換モジュール１２５０は、受信したレスポンスデータのうち、ｓ８００１で受信したＲｅａｄＴＸが示す読み込み対象のＴＸ（業務データ）を抽出する（ｓ８００７）。これは、ｓ８００６で受信したレスポンスデータは、キーマッピングテーブル１１４０のインテグレートキー１１４２（統合後キー）が示す複数のキーに係る業務データを含んでいるため、それらの業務データの中から、このインテグレートキー１１４２に対応するオリジナルキー１１４１（統合前キー）が示す業務データのみを取得する必要があるためである。

リクエスト変換モジュール１２５０は、ｓ８００７で取得した業務データと、ｓ８００１で受信したＲｅａｄＴＸに係るキー（統合前キー）とを対応づけたデータ（クライアントノード２０００が送信してきたＲｅａｄＴＸに対するリプライデータ）を作成し、作成したリプライデータを、ＲｅａｄＴＸを送信してきたクライアントノード２０００に送信する（ｓ８００８）。以上でリクエスト変換処理は終了する。

他方、ｓ８００９、ｓ８０１０においてリクエスト変換モジュール１２５０は、特に処理を加えずにリプライデータをクライアントノード２０００に送信する。

すなわち、リクエスト変換モジュール１２５０は、ｓ８００１で受信したＲｅａｄＴＸをリクエストモジュール１２４０に送信する（ｓ８００９）。リクエストモジュール１２４０は、受信したＲｅａｄＴＸに基づき、ブロックチェーンシステム５０００の分散台帳ノード４０００から、レスポンスデータを受信する。リクエスト変換モジュール１２５０は、リクエストモジュール１２４０からレスポンスデータを受信する。

リクエスト変換モジュール１２５０は、受信したレスポンスデータと、ｓ８００１で受信したＲｅａｄＴＸに係るキー（統合前キー）とを対応づけたリプライデータを、ＲｅａｄＴＸを送信してきたクライアントノード２０００に送信する（ｓ８０１０）。以上でリクエスト変換処理は終了する。

以上のようなリクエスト変換処理によれば、クライアントノード２０００は、自身に追加的な実装をすることなく、通常のＲｅａｄＴＸのみで、先に統合して書き込まれたＴＸに係る業務データを読み込むことができる。

なお、本実施形態のリクエスト変換処理では、ｓ８００５の要求処理とｓ８００６の実行結果受信処理とが同期的に実行されることとしているが、これらの処理は非同期的であってもよい。例えば、ｓ８００５の実行後、非同期的にｓ８００６の実行を開始してもよい。

以上のように、本実施形態の情報共有支援方法においては、管理ノード１０００が、ブロックチェーンシステム５０００に対して送信されたＴＸ（ＷｒｉｔｅＴＸ等）を複数受信し、受信した複数のＴＸを所定のルール（統合条件テーブル１１１０、統合ポリシテーブル１１２０、及び統合ルールテーブル１１３０）に従って、ブロックチェーンシステム
５０００が対応可能な形式にしつつ統合して新たなＴＸを作成し、このＴＸをブロックチェーンシステム５０００に送信する。

これにより、ブロックチェーンシステム５０００に対するトランザクションに係るリクエスト数自体を削減できる。そして、これにより、ブロックチェーンシステム５０００における情報共有に係る通信のスループット性能の向上（合意形成処理、及び書込み処理を含む性能向上）を実現することができる。

また、管理ノード１０００によれば、例えば、管理ノード１０００は、情報共有支援システム１における負荷の状況等のルール又はポリシに基づいて複数のリクエストを統合し、ブロックチェーンにリクエストに係るデータを書込むことができるので、ブロックチェーンシステム５０００の性能向上を実現することができる。

具体的に説明すると、ブロックチェーンシステムにおいては、非特許文献２等に記載がある通り、各ＴＸを処理する際、ＴＸに係る合意形成、ＴＸのリクエスト順序の制御、及びＴＸに係るデータの書き込み等の各種処理が必要である。さらに、各処理において、クライアントノード２０００、Ｏｒｄｅｒｉｎｇノード（本実施形態では図示しない）、及び複数の分散台帳ノード４０００等の多くの管理計算機の間でＴＸが送受信されるという特徴がある。

したがって、ＴＸに係るリクエスト数を削減することが可能な本実施形態の情報共有支援方法によれば、ブロックチェーンシステムは、従来よりも特に高い性能を発揮することができるようになる。

特に、本実施形態で例示したコンソーシアム型のブロックチェーンシステムでは、リクエスト数の削減によりＴＸのサイズが大きくなることのデメリットに比べて、リクエスト数を削減することによる性能向上のメリットの効果が非常に大きい。これにより、大量のストリームデータを扱うブロックチェーンシステムを利用する場合であっても、当該データをブロックチェーンデータに効率良く格納することが可能となり、これまでブロックチェーンデータを扱い難かった業務システムに対しても、ブロックチェーンシステムを適用することが可能となる。

近年では、モノの活動に伴うＩｏＴデータやモバイルデータ、人の活動に伴うライフデータ等、社会において取り扱われるデータ量が増大している。これに伴い、大量のストリームデータを複数の組織間で共有しつつセキュアに保存する要請が高まることが想定される。そのような状況の中で、大量のストリームデータをブロックチェーンデータに効率よく格納できる本実施形態の情報共有支援方法は、そのような要請を満たすことが可能である。

［第２実施形態］
第１実施形態では、管理ノード１０００が１台であることを想定したが、管理ノード１０００は複数台存在していてもよい。このような場合としては、例えば、複数の管理組織（業界団体）が存在する場合がある。

図１５は、第２実施形態に係る情報共有支援システム１の構成の一例を示す図である。本実施形態の情報共有支援システム１は、ネットワーク９０００により互いに通信可能に接続された複数の管理ノード１０００を含んで構成されている。その他の各ノードの構成及び機能は、第１実施形態と同様である（なお、第１実施形態と同様であるため記載は省略している）。

この場合、複数の管理ノード１０００のそれぞれが、ＴＸの統合に関するルールの情報（統合条件テーブル１１１０、統合ポリシテーブル１１２０、又は統合ルールテーブル１１３０）を共有し、ブロックチェーンデータの形式でそれぞれ記憶する。これにより、複数の管理組織の間で統一したポリシに基づいて、ＴＸを共有できる。また、管理組織間でトランザクションの処理を整合的に行うことができる。

なお、管理ノード１０００ではなく、各分散台帳ノード４０００が、ＴＸの統合に関するルールの情報を共有し、ブロックチェーンデータの形式でそれぞれ記憶してもよい。この場合、各分散台帳ノード４０００は、各ルールの情報の作成、更新、又は削除等の変更があった場合、分散台帳ノード４０００間でこれらの変更に係る合意形成を行った上で、各ルールを共有することになる。

これにより、管理組織間でトランザクションの処理を整合的に行うことができる。例えば、クライアントノード２０００が複数の管理ノード１０００に各ＴＸを書き込む場合に、各ＴＸの統合の有無及びその統合の内容の統一性をとることができる。また、各管理組織に対応するクライアントノード２０００が複数存在する場合にも、各管理組織の間でＴＸの整合的な統合処理を行うことができる。また、管理ノード１０００の管理者との関係でも、管理者は、複数の管理ノード１０００のうち一つの管理ノード１０００で情報を設定するだけで、他の管理ノード１０００を含めた全ての管理ノード１０００において、整合的なＴＸの統合処理を行うことができる。

また、各管理ノード１０００は、キーマッピングテーブル１１４０を共有し、ブロックチェーンデータの形式でそれぞれ記憶する。これにより、複数の管理組織の間で統一したルールに従って、統合変換したＴＸの書き込み及びこれにより書き込まれた各業務データ（ＴＸ）の読み込みを正しく行うことができる。

なお、分散台帳ノード４０００がキーマッピングテーブル１１４０を共有して記憶するとしてもよい。この場合、キーマッピングテーブル１１４０に、どの管理ノード１０００からのＴＸに基づき統合後ＴＸを作成したかを特定する情報を設定する項目を追加してもよい。

これにより、各クライアントノード２０００は、どの管理ノード１０００を経由してＴＸをブロックチェーンシステム５０００に書き込んだ場合であっても、書き込んだＴＸに対応する適切な業務データをブロックチェーンシステム５０００から読み込むことができる。

以上、本発明を実施するための形態について具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

例えば、各実施形態では、情報共有支援システム１は、コンソーシアム型のブロックチェーンシステムであるものとしたが、特定のメンバから構成される他の形態のブロックチェーンシステムであってもよい。

また、管理ノード１０００が記憶しているテーブル、及びモジュールの少なくともいずれかは、分散台帳ノード４０００やクライアントノード２０００が記憶していてもよい。

また、本実施形態では、統合するＴＸの種類は同一である場合を前提としたが、異なる種類のＴＸを統合するようにしてもよい。例えば、一連で行われる複数の異なる処理を統合するようにしてもよい。

また、ＴＸの統合は複数の種類についてそれぞれ並列的に行っても良いし、同時期には一つの種類のＴＸについてのみ統合を行うようにしてもよい。

以上の本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、各実施形態の情報共有支援システム１においては、前記情報処理装置（管理ノード１０００）が、前記統合管理処理において、前記情報処理システムにおける通信負荷が所定閾値を超えるか否かを判定し、当該通信負荷が当該閾値を超えると判定した場合にのみ、前記新たな要求を作成する、としてもよい。

これにより、ブロックチェーンシステム５０００に負荷がかかっていてＴＸの統合処理等によるスループット性能の有意な向上が期待できない場合には、当該処理を行わないので、スループット性能を安定させることができる。

また、各実施形態の情報共有支援システム１においては、前記情報処理装置が、前記統合管理処理において、前記受信した複数の要求の種類を判定し、当該種類が所定の条件を満たす場合にのみ、前記新たな要求を作成する、としてもよい。

これにより、例えば、統合によるスループット性能の有意な向上が期待できる種類のＴＸに対してのみ、当該統合処理を行うことにより、スループット性能を向上させることができる。

また、各実施形態の情報共有支援システム１においては、前記情報処理装置が、前記統合管理処理において、前記新たな要求を作成する際、前記受信した複数の要求のうち、前記情報処理システムの各ノードが処理可能な形式にするために不要な情報を削除することにより、前記新たな要求を作成する、としてもよい。

このように、ＴＸを統合する際、統合前のＴＸから不要な情報を削除することで、システムに対する負荷を軽減し、スループット性能を向上させることができる。

また、各実施形態の情報共有支援システム１においては、前記情報処理装置が、前記統合管理処理において、前記複数の要求を統合する際、前記受信した複数の要求のうち所定の要求を受信した時から所定期間を経過したと判定した場合に、前記新たな要求の作成を開始する、としてもよい。

このように、所定のＴＸ（例えば、最初のＴＸ）を受信した時から所定期間を経過してからＴＸを統合することで、統合するＴＸの数を適切に減らすことができる。これにより、スループット性能を安定させることができる。

また、各実施形態の情報共有支援システム１においては、前記統合管理処理において、前記複数の要求を統合する際、前記受信した複数の要求の数が所定値を超えたか否かを判定し、当該数が当該所定値を超えたと判定した場合に、前記新たな要求の作成を開始する、としてもよい。

このように、受信したＴＸの数が多くなった場合にＴＸの統合を開始することで、統合するＴＸに係るリクエストの数が過大となることを防ぐことができる。これにより、スループット性能を安定させることができる。

また、各実施形態の情報共有支援システム１においては、前記情報処理装置が、前記リクエスト受信処理において、所定の情報を前記情報処理システムの各ノードに書き込む旨の要求を複数受信し、前記統合管理処理において、前記受信した複数の要求に基づき、書
き込みに関する前記新たな要求を作成し、前記リクエスト処理において、前記作成した新たな要求を前記情報処理システムに送信することにより、当該情報処理システムの各ノードに、前記複数の要求に係る複数の情報を記憶させる、としてもよい。

このように、管理ノード１０００が、受信した複数のＷｒｉｔｅＴＸに基づき統合後ＴＸを作成し、これをブロックチェーンシステム５０００に送信することで、トランザクションの書き込みに係るスループット性能を向上させることができる。

また、各実施形態の情報共有支援システム１においては、記情報処理装置が、
前記所定のルールとして、前記受信した複数の書き込む旨の要求のそれぞれと、前記新たな要求との対応づけの情報を記憶し、前記リクエスト受信処理において、前記複数の書き込む旨の要求が示す各情報のうちいずれかの情報の取得の要求を所定の装置から受信し、前記記憶した対応付けの情報に基づき特定される、前記受信した取得の要求に対応する前記新たな要求に対応づけられた、所定の取得要求に基づき、前記いずれかの情報を、前記情報処理システムに記憶されている複数の情報から取得し、取得した対象情報を含む情報を、前記所定の装置に送信するリクエスト変換処理を実行する、としてもよい。

このように、管理ノード１０００は、統合後ＴＸ（ＷｒｉｔｅＴＸ）によるデータの書き込みを行った後、そのデータのうち一部のデータに対するＲｅａｄＴＸを受信した場合は、キーマッピングテーブル１１４０により統合後ＴＸに対応した取得要求（新たなＲｅａｄＴＸ）を作成し、この取得要求によってブロックチェーンシステム５０００から上記一部データを取得し、これをクライアントノード２０００に送信する。これにより、複数のＴＸを統合した統合後ＴＸをブロックチェーンシステム５０００に書き込んだ場合であっても、そのブロックチェーンシステム５０００から統合前のＴＸに係る業務データを正しく選択して読み込むことができる。

また、各実施形態の情報共有支援システム１においては、複数の前記情報処理装置のそれぞれが、前記所定のルールを共有して記憶するポリシ共有処理を実行する、としてもよい。

これにより、複数の業界団体等があり管理ノード１０００が複数存在する場合であっても、各管理ノード１０００において、共通のルール（統合条件テーブル１１１０、統合ポリシテーブル１１２０、及び統合ルールテーブル１１３０）によってＴＸの統合を整合的に行うことができる。

また、各実施形態の情報共有支援システム１においては、複数の前記情報処理装置のそれぞれが、前記所定のルールとして、前記受信した複数の要求のそれぞれと、前記複数の要求の統合後の要求との対応づけの情報を記憶し、前記情報処理装置のそれぞれが、前記統合管理処理において、前記受信した複数の要求を前記記憶した情報に従って対応づけた、前記新たな要求を作成する、としてもよい。

このように、複数の管理ノード１０００が、対応づけ情報たるキーマッピングテーブル１１４０を共有し、各管理ノード１０００が統合後ＴＸを作成することで、複数の管理団体等があるため管理ノード１０００が複数存在する場合であっても、各管理ノード１０００において、ＴＸの統合を整合的に行うことができ、各管理団体間で業務データを正しく共有することができる。

１ 情報共有支援システム、１０００ 管理ノード、２０００ クライアントノード、３０００ メンバ管理ノード、４０００ 分散台帳ノード、５０００ ブロックチェーンシ
ステム

Claims (9)

1. 情報処理装置が、
   互いに通信可能な複数のノードでトランザクションの履歴をブロックチェーンデータの形式で共有するブロックチェーンシステムである情報処理システムに対する、所定の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る複数の要求を受信するリクエスト受信処理と、
   統合する要求が満たすべき条件、及び、前記情報処理システムが処理可能な形式にするために不要な情報を規定した所定のルールに従って、前記受信した複数の要求のうち前記条件を満たす複数の要求それぞれの内容たるバリューの全てを一つのバリューに再構成すると共に、再構成したバリューに対して、前記不要な情報を削除することにより、前記条件を満たす複数の要求を、前記情報処理システムの各ノードが処理可能な形式に変換しつつ統合して、前記統合した複数の要求に係る複数の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る新たな要求を作成する統合管理処理と、
   前記新たな要求を前記情報処理システムに送信することにより、当該情報処理システムの各ノードに、前記統合した複数の要求に係る複数の情報を記憶させ、前記新たな要求のトランザクションを前記ブロックチェーンデータに追加させるリクエスト処理とを実行する、
   情報共有支援方法。
2. 前記情報処理装置が、前記統合管理処理において、
   前記情報処理システムにおける通信負荷が所定閾値を超えるか否かを判定し、当該通信負荷が当該閾値を超えると判定した場合にのみ、前記新たな要求を作成する、
   請求項１に記載の情報共有支援方法。
3. 前記情報処理装置が、前記統合管理処理において、
   前記受信した複数の要求の種類を判定し、当該種類が所定の条件を満たす場合にのみ、前記新たな要求を作成する、
   請求項１に記載の情報共有支援方法。
4. 前記情報処理装置が、前記統合管理処理において、
   前記複数の要求を統合する際、前記受信した複数の要求のうち所定の要求を受信した時から所定期間を経過したと判定した場合に、前記新たな要求の作成を開始する、
   請求項１に記載の情報共有支援方法。
5. 前記情報処理装置が、前記統合管理処理において、
   前記複数の要求を統合する際、前記受信した複数の要求の数が所定値を超えたか否かを判定し、当該数が当該所定値を超えたと判定した場合に、前記新たな要求の作成を開始する、
   請求項４に記載の情報共有支援方法。
6. 前記情報処理装置が、
   前記統合した複数の要求のそれぞれと、前記新たな要求との対応づけの情報を記憶し、
   前記リクエスト受信処理において、前記統合した複数の要求に係る各情報のうちいずれかの情報の取得の要求を所定の装置から受信し、
   前記記憶した対応付けの情報に基づき特定される、前記受信した取得の要求に対応する前記新たな要求に対応づけられた、所定の取得要求に基づき、前記いずれかの情報を、前記情報処理システムに記憶させた複数の情報から取得し、取得した対象情報を含む情報を、前記所定の装置に送信するリクエスト変換処理を実行する、
   請求項１に記載の情報共有支援方法。
7. 複数の前記情報処理装置のそれぞれが、
   前記所定のルールを共有して記憶するポリシ共有処理を実行する、
   請求項１に記載の情報共有支援方法。
8. 複数の前記情報処理装置のそれぞれが、前記統合した複数の要求のそれぞれと、前記複数の要求の統合後の要求との対応づけの情報を記憶し、
   前記情報処理装置のそれぞれが、前記統合管理処理において、前記統合した複数の要求を前記記憶した情報に従って対応づけた、前記新たな要求を作成する、
   請求項１に記載の情報共有支援方法。
9. 互いに通信可能な複数のノードでトランザクションの履歴をブロックチェーンデータの形式で共有するブロックチェーンシステムである情報処理システムに対する、所定の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る複数の要求を受信するリクエスト受信処理と、
   統合する要求が満たすべき条件、及び、前記情報処理システムが処理可能な形式にするために不要な情報を規定した所定のルールに従って、前記受信した複数の要求のうち前記条件を満たす複数の要求それぞれの内容たるバリューの全てを一つのバリューに再構成すると共に、再構成したバリューに対して、前記不要な情報を削除することにより、前記条件を満たす複数の要求を、前記情報処理システムの各ノードが処理可能な形式に変換しつつ統合して、前記統合した複数の要求に係る複数の情報を前記情報処理システムの各ノードに書き込む旨のトランザクションに係る新たな要求を作成する統合管理処理と、
   前記新たな要求を前記情報処理システムに送信することにより、当該情報処理システムの各ノードに、前記統合した複数の要求に係る複数の情報を記憶させ、前記新たな要求のトランザクションを前記ブロックチェーンデータに追加させるリクエスト処理とを実行する演算装置を備える、
   情報共有支援システム。

Images