特許 7347674 制御方法、情報処理装置及び制御プログラム

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

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

(11)【特許番号】

(24)【登録日】2023-09-11

(45)【発行日】2023-09-20

(54)【発明の名称】制御方法、情報処理装置及び制御プログラム

(51)【国際特許分類】

   G06Q 10/06 20230101AFI20230912BHJP

【ＦＩ】

G06Q10/06

【請求項の数】 5

(21)【出願番号】P 2022532963

(86)(22)【出願日】2020-07-02

(86)【国際出願番号】 JP2020026054

(87)【国際公開番号】W WO2022003914

(87)【国際公開日】2022-01-06

【審査請求日】2022-12-09

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100107515

【弁理士】

【氏名又は名称】廣田 浩一

(72)【発明者】

【氏名】竹内 琢磨

(72)【発明者】

【氏名】森永 正信

【審査官】今井 悠太

(56)【参考文献】

【文献】特開２０２０－０４６７３８（ＪＰ，Ａ）

【文献】特開２０１９－３３０９（ＪＰ，Ａ）

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

Ｇ０６Ｑ １０／００ー９９／００

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

【請求項1】

評価対象の評価値を決定する要求を受け付けると、第１のユーザによる入力に応じて第１のブロックチェーンネットワークの台帳に記録された前記評価値の算定式と、第２のユーザによる入力に応じて第２のブロックチェーンネットワークの台帳に記録された前記算定式に含まれる変数の値の第１の条件とを取得し、
取得した前記評価値の算定式と、取得した前記第１の条件を満たす値から選定した値とに基づき、前記評価値を算定し、
選定した前記値が前記変数の値であることを示す情報について前記第２のブロックチェーンネットワークへの送信を制御する、
処理をコンピュータが実行することを特徴とする制御方法。

【請求項2】

算定した前記評価値が前記評価対象の評価値であることを示す情報について前記第１のブロックチェーンネットワークへの送信を制御する、
処理をコンピュータが実行することを特徴とする請求項１記載の制御方法。

【請求項3】

複数の前記要求に関して共通に適用される第２の条件を取得する、
処理をコンピュータが実行し、
前記評価値を算定する処理は、更に、取得した前記第２の条件をも満たす値から選定した値に基づき、前記評価値を算定する、
ことを特徴とする請求項１又は２記載の制御方法。

【請求項4】

評価対象の評価値を決定する要求を受け付けると、第１のユーザによる入力に応じて第１のブロックチェーンネットワークの台帳に記録された前記評価値の算定式と、第２のユーザによる入力に応じて第２のブロックチェーンネットワークの台帳に記録された前記算定式に含まれる変数の値の第１の条件とを取得する取得部と、
取得した前記評価値の算定式と、取得した前記第１の条件を満たす値から選定した値とに基づき、前記評価値を算定する算定部と、
選定した前記値が前記変数の値であることを示す情報について前記第２のブロックチェーンネットワークへの送信を制御する制御部と、
を有することを特徴とする情報処理装置。

【請求項5】

評価対象の評価値を決定する要求を受け付けると、第１のユーザによる入力に応じて第１のブロックチェーンネットワークの台帳に記録された前記評価値の算定式と、第２のユーザによる入力に応じて第２のブロックチェーンネットワークの台帳に記録された前記算定式に含まれる変数の値の第１の条件とを取得し、
取得した前記評価値の算定式と、取得した前記第１の条件を満たす値から選定した値とに基づき、前記評価値を算定し、
選定した前記値が前記変数の値であることを示す情報について前記第２のブロックチェーンネットワークへの送信を制御する、
処理をコンピュータに実行させることを特徴とする制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御方法、情報処理装置及び制御プログラムに関する。

【背景技術】

【0002】

ブロックチェーンに基づくシステムは、原則として、ブロックチェーンネットワークにおける多数のノードによる検証をベースとして、中央機関不在の信頼性を保っている。一方で、企業が運営するサービスやシステムの場合、ブロックチェーンに記録されている情報をアクセス制御したい場合もあり、その場合には企業ごとに異なるブロックチェーンを運用される可能性が有る。

【0003】

他方において、最近では、各々の企業が単独でビジネスを運営していくのではなく、企業同士が協力して成果を出すような共創型ビジネスが盛んである。、共創型ビジネスにおいては、複数の企業ごとに運営されるブロックチェーンネットワーク間を跨ぐワークフローが構成される可能性が有る。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０２０－０３０４７９号公報

【発明の概要】

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

【0005】

しかしながら、ブロックチェーンには改竄不可能という性質があり、上記のような単一のブロックチェーンによりワークフローが構成される場合、企業間でやり取りされる処理は改竄不可能となる。一方で、ブロックチェーンを跨ぐ処理というのは、企業が他社を含めて行う決断であるため、極めて重い判断を要するものもある。そのため、ブロックチェーンへの記録に要する負荷（例えば、ブロックチェーンに記録される事項に関しての企業内で意思決定する負荷等）が増加する可能性が有る。

【0006】

そこで、一側面では、ブロックチェーンへの記録に要する負荷を軽減することを目的とする。

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

【0007】

一つの案では、評価対象の評価値を決定する要求を受け付けると、第１のユーザによる入力に応じて第１のブロックチェーンネットワークの台帳に記録された前記評価値の算定式と、第２のユーザによる入力に応じて第２のブロックチェーンネットワークの台帳に記録された前記算定式に含まれる変数の値の第１の条件とを取得し、取得した前記評価値の算定式と、取得した前記第１の条件を満たす値から選定した値とに基づき、前記評価値を算定し、選定した前記値が前記変数の値であることを示す情報について前記第２のブロックチェーンネットワークへの送信を制御する、処理をコンピュータが実行する。

【発明の効果】

【0008】

一態様によれば、ブロックチェーンへの記録に要する負荷を軽減することができる。

【図面の簡単な説明】

【0009】

【図1】データの価格付けのワークフローの一例を示す図である。

【図2】本発明の実施の形態における取引制御システム１の構成例を示す図である。

【図3】本発明の実施の形態における連携サーバ１０のハードウェア構成例を示す図である。

【図4】ワークフローの第１ステップを説明するための図である。

【図5】ワークフローの第２ステップを説明するための図である。

【図6】ワークフローの第３ステップを説明するための図である。

【図7】ワークフローの第４ステップを説明するための図である。

【図8】本発明の実施の形態における取引制御システム１の機能構成例を示す図である。

【図9】取引制御システム１において実行される処理手順の一例を説明するためのシーケンス図である。

【図10】取引制御システム１において実行される処理手順の一例を説明するためのシーケンス図である。

【図11】取引制御システム１において実行される処理手順の一例を説明するためのシーケンス図である。

【図12】取引制御システム１において実行される処理手順の一例を説明するためのシーケンス図である。

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

【0010】

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、検討する問題設定として、データに関する価格付け問題を取り上げる。データとは、例えば、ビッグデータのように、経済的価値を有するデータである。すなわち、本実施の形態では、価格が評価値であり、データが評価値の評価対象である例について説明する。

【0011】

例えば、図１に示されるようなワークフローによってデータの価格付けが行われるとする。図１では、「申請者→直属上司→技術調査会社Ｑ→技術調査会社Ｒ→終点決済」というワークフローによって価格付けの処理が行われる例が示されている。

【0012】

会社Ｐの申請者は「データを売りたい」という申請を出すが、申請者自身は、当該データの属する技術分野（技術Ｑ、技術Ｒ）の専門家ではなく、当該データの価格の相場について精通していない。直属上司は、売るという判断にはＯＫを出したいが、自身も非専門家なので価格の妥当性を検証できない。そこで、当該データの価格は会社においては保留にされて、他社である技術調査会社の意見次第で決まることとする。技術調査会社は、その専門性に基づいてデータの価格を決める属性値を決定する。終点決済では、その属性値に基づいて最終的に価格が決定される。なお、各会社における決定事項は、会社別のブロックチェーン（ＢＣ）に記録されることとする。また、各技術調査会社において属性値を決定する者を、便宜上、「審査官」という。

【0013】

このような取引がシーケンシャルに流れる状況を考える。制約としては以下を想定する。

【0014】

（１）各技術調査会社の審査官に与えられる属性値付けには幅がある。すなわち、複数の取引に対して与えられる属性値の分散は０ではない。例えば、或る審査官が全での取引に高評価をつけたりする、などは許されない。一定期間の間、高～低評価まで、幅を持たせた評価付けが行われる必要がある。

【0015】

（２）各審査官の属性値付けは、自分より前の段階の審査官の判断に依存する可能性がある。例えば、１次審査では書類審査で篩にかけ、２次審査では技術審査で詳細に調査されるというイメージである。

【0016】

なお、このようなワークフローは、データ売買以外でも適用可能である。例えば、電力事業者における電力売買の利益配分システムに対して当該ワークフローが適用されてもよい。

【0017】

上記のワークフローに関して考えられるアプローチについて説明する。

【0018】

［アプローチ１：ブロックチェーン連携］
方式として、異なるブロックチェーンネットワーク間を連携する方式を用いて、ワークフローの処理が行われるたびに逐一評価結果が付与されることを想定する。異なるブロックチェーンネットワーク間を連携する方式の例として、「Shingo Fujimoto, Yoshiki Higashikado, Takuma Takeuchi、ConnectionChain：the Secure Interworking of Blockchains (2019)、＜URL：https://ieeexplore.ieee.org/document/8939267＞」に開示されたコネクションチェーンが存在する。

【0019】

単にコネクションチェーンを用いるだけの問題点としては、途中経過も含めて逐一属性値が付与され、当該属性値がブロックチェーンに記録されるため、ワークフローの後段になればなるほど、付与可能な属性値の自由度が低くなることが挙げられる。データの価格付けの例であれば、途中経過の時点で属性値の値が決定されると、最終的に審査官が付与できる属性値に制限がかかる難点がある。そのため、途中では属性値の付与は保留としたい。

【0020】

［アプローチ２：ブロックチェーン連携＋保留状態付与］
アプローチ１の改良として、ブロックチェーンの連携方式はアプローチ１と同様に用いて、途中経過の取引では属性値が付与されない（保留状態とされる）ことを示す変数をブロックチェーンに記録し、最終時点（終点決済）の取引において一括で保留状態の変数に属性値を付与する。この方法のメリットとして、最終取引の時点で属性値の自由度が高くなる。

【0021】

しかし、最終取引から遡って各ブロックチェーンにおいて保留状態の変数に属性値を付与するのは、多くの場合において処理性能が低下するというデメリットがある。各ブロックチェーンに順々に遡って承認依頼をかけるため、連携するブロックチェーンの台数（技術調査会社の数）に比例して処理時間が増加する。審査官の判断が前の審査官の判断に依存するため、順番に承認依頼をかけざるを得ないためである。

【0022】

ブロックチェーンによっては、取引が発行されてから承認されるまでに１０分以上かかるものもあるし、そもそも審査官の確認処理が人力で行われることを想定すると、申請の種類にもよるが１時間はかかるものと思われる（重要な処理であれば１日、１週間かかるものもある）。その場合、例えば、最終時点のブロックチェーン以外に４台のブロックチェーンがある場合、各々への確認処理が入り、４時間の所要時間が発生してしまう。これはワークフローの各処理が重要のものであるか、又は接続するブロックチェーンの台数が増えることにより顕著に表れるデメリットである。

【0023】

そこで、本実施の形態では、ブロックチェーンに対して保留状態の記録が許容される分散ワークフローに関して、「最終時点の取引における属性値付与の自由度を上げること」と「最終時点の取引の処理時間を短縮する」を同時に満たす例について説明する。そうすることで、ワークフローの各段階において、ブロックチェーンへの記録に要する負荷を軽減することができる。

【0024】

図２は、本発明の実施の形態における取引制御システム１の構成例を示す図である。図２に示されるように、取引制御システム１は、複数のブロックチェーンネットワーク（以下、「ＢＣ２０」という。）及び連携サーバ１０を含む。ＢＣ２０－１～ＢＣ２０－４等の各ＢＣ２０は、インターネット等のネットワークを介して連携サーバ１０に接続される。但し、連携サーバ１０の機能は、いずれかのＢＣ２０におけるスマートコントラクトによって実現されてもよい。

【0025】

各ＢＣ２０は、図１に示した、会社Ｐ、技術調査会社Ｑ、技術調査会社Ｐ、又は終点決済を実行する組織（以下、「終点組織」という。）において運用されるブロックチェーンネットワークである。例えば、ＢＣ２０－１が、会社Ｐのブロックチェーンネットワークであり、ＢＣ２０－２が、技術調査会社Ｑのブロックチェーンネットワークであり、ＢＣ２０－３が、技術調査会社Ｒのブロックチェーンネットワークであり、ＢＣ２０－４が、終点組織のブロックチェーンネットワークである。

【0026】

連携サーバ１０は、各ＢＣ２０における処理を保留状態とするための連携処理を実行する１以上のコンピュータ（情報処理装置）である。

【0027】

図３は、本発明の実施の形態における連携サーバ１０のハードウェア構成例を示す図である。図３の連携サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0028】

連携サーバ１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0029】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って連携サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0030】

なお、記録媒体１０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

【0031】

なお、各ＢＣ２０の各ノード（情報処理装置）も、図３に示されるようなハードウェア構成を有してよい。

【0032】

次に、取引制御システム１において実行されるワークフローの処理手順の概要を４つのステップ（第１ステップ～第４ステップ）に分けて説明する。

【0033】

図４は、ワークフローの第１ステップを説明するための図である。第１ステップでは、ＢＣ２０－１におけるデータの価格付けの申請取引の発行に応じ、連携サーバ１０は、当該価格付けのための評価式（評価値の算定式）を取得し、当該評価式を条件式ＤＢ１２１へ格納する。なお、図４において、当該評価式は、ｙ＝２００ｘ_１＋５０ｘ_２である。ｙは、データの価格である。ｘ_１は、当該価格の属性（変数）のうち、技術調査会社Ｑの審査官Ａ１によって値が決定される属性（変数）である。ｘ_２は、当該価格の属性（変数）のうち、技術調査会社Ｒの審査官Ａ２によって値が決定される属性（変数）である。なお、当該評価式は、例えば、申請者又は会社Ｐによって決定される。

【0034】

図５は、ワークフローの第２ステップを説明するための図である。第２ステップにおいて、保留状態となる取引が、各技術調査会社のＢＣ２０上で行われ際に、連携サーバ１０は、当該各ＢＣ２０から条件式を取得し、当該条件式を条件式ＤＢ１２１に格納する。当該各ＢＣ２０では、ｘ_１又はｘ_２について保留状態を含む取引が発行される。

【0035】

ここで、条件式は、評価式の変数（ｘ_１又はｘ_２）に関する条件を示す式である。図５では、審査官Ａ１によって、３≦ｘ_１≦５が入力され、審査官Ａ２によって、２≦ｘ_２≦４が入力された例が示されている。すなわち、第２ステップでは、各変数は一意に決定されずに、条件式によって保留状態とされる。

【0036】

図５において、３≦ｘ_１≦５は、条件式３として条件式ＤＢ１２１に格納されている。２≦ｘ_２≦４は、条件式４として条件式ＤＢ１２１に格納されている。なお、条件式１（審査官Ａ１，Ａ２の各取引の属性値の平均μは２≦μ≦３を満たす。）及び条件式２（属性値ｘ_１が３以下の場合、属性値ｘ_２は２である。）は、予め条件式ＤＢ１２１に対して登録されている条件式の一例である。条件式１及び２は、全てのワークフローに対して共通に適用される条件式（以下、「既定条件式」という。）である。

【0037】

図６は、ワークフローの第３ステップを説明するための図である。第３ステップにおいて、終点組織のＢＣ２０－４において保留状態の変数の値の決定が行われる。具体的には、条件式ＤＢ１２１及び結果ＤＢ１２２が参照され、条件式ＤＢ１２１に格納された全ての条件式を満たすように各変数（ｘ_１、ｘ_２）の値が決定されることで、価格ｙが決定され、終点決済取引が発行される。終点決済取引の発行により、決定された価格及び変数の値がＢＣ２０－４の台帳に記録される。当該価格及び変数の値は、また、連携サーバ１０へ送信される。図６の例では、ｘ_１＝３、ｘ_２＝４、ｙ＝２６００として決定された例が示されている。なお、結果ＤＢ１２２は、過去の価格及び変数の値の履歴が記憶されるデータベースである。結果ＤＢ１２２を参照する必要が有るのは、条件式１を満たすために、過去の取引の結果が必要だからである。

【0038】

図７は、ワークフローの第４ステップを説明するための図である。終点決済後の第４ステップにおいて、連携サーバ１０は、結果ＤＢ１２２に格納された終点決済取引の結果をＢＣ２０－２及びＢＣ２０－３に反映させるため、保留状態の変数への値（ｘ１又はｘ２）の代入要求を示す取引を発行して、各変数の値をＢＣ２０－２及びＢＣ２０－３へ送信するとともに、終点決済取引の結果（ｙ、ｘ１、ｘ２の値）を結果ＤＢ１２２に格納する。各ＢＣ２０は、それぞれの保留状態の変数の値を終点決済取引の結果の値によって更新する。なお、図７において破線で示されているように、代入要求を示す取引を発行によって、ＢＣ２０－１に対して変数ｙの値が送信されてもよい。この場合、ＢＣ２０－１において、変数ｙに対して値が代入されてもよい。

【0039】

第１ステップから第４ステップ等を実行可能とするため、取引制御システム１（各ＢＣ２０及び連携サーバ１０）は、図８に示されるような機能構成を有する。

【0040】

図８は、本発明の実施の形態における取引制御システム１の機能構成例を示す図である。図８に示されるように、各ＢＣ２０（の各ノード）は、リクエスト受付部２１、保留状態取引発行部２２、条件式ＤＢ更新要求部２３、保留状態値決定部２４、終点決済取引発行部２５、値決定通知部２６、値反映取引発行部２７、通知部２８及び通知受信部２９等を有する。これら各部は、ＢＣ２０にインストールされた１以上のプログラム（例えば、スマートコントラクト）が、ＢＣ２０を構成するノードのＣＰＵに実行させる処理により実現される。なお、終点決済取引発行部２５、値決定通知部２６及び値反映取引発行部２７は、終点決済取引を行うＢＣ２０－４以外のＢＣ２０は有していなくてもよい。

【0041】

リクエスト受付部２１は、ユーザ（申請者、審査官等）からのリクエストを受け付ける。

【0042】

保留状態取引発行部２２は、取引の結果としてＢＣ２０の台帳に記録される内容が保留状態であることを示す変数である取引（以下、「保留取引」という。）を発行する。ＢＣ２０－１においては、価格付けの申請が保留取引に該当する。ＢＣ２０－２及びＢＣ２０－３においては、条件式を含む取引が保留取引に該当する。

【0043】

条件式ＤＢ更新要求部２３は、ＢＣ２０において発行される保留取引に含まれる情報（評価式又は条件式）の登録要求を連携サーバ１０へ送信する。

【0044】

保留状態値決定部２４は、条件式ＤＢ１２１に格納されている条件式、及び結果ＤＢ１２２に格納されている過去の取引の結果等に基づいて、保留状態の変数の値を決定する。

【0045】

終点決済取引発行部２５は、終点決済取引を発行する。

【0046】

値反映取引発行部２７は、保留状態の変数の値を反映させるためのイベント又は取引を発行する。

【0047】

通知部２８は、連携サーバ１０に対して通知を送信する。通知受信部２９は、連携サーバ１０からの通知を受信する。

【0048】

一方、連携サーバ１０は、イベント監視部１１、条件式ＤＢ更新部１２、条件式ＤＢ参照部１３、結果ＤＢ参照部１４、結果ＤＢ更新部１５、値反映要求部１６、通知部１７及び通知受信部１８等を有する。これら各部は、連携サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。連携サーバ１０は、また、条件式ＤＢ１２１及び結果ＤＢ１２２等のデータベース（記憶部）を利用する。これら各データベースは、例えば、補助記憶装置１０２、又は連携サーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

【0049】

イベント監視部１１は、各ＢＣ２０におけるイベントの発行を監視する。

【0050】

条件式ＤＢ更新部１２は、条件式ＤＢ更新要求部２３によって発行されるイベントに応じ、評価式又は条件式を条件式ＤＢ１２１へ登録することで、条件式ＤＢ１２１を更新する。

【0051】

条件式ＤＢ参照部１３は、条件式ＤＢ１２１に格納されている条件式を保留状態値決定部２４へ送信する。

【0052】

結果ＤＢ参照部１４は、結果ＤＢ１２２に格納されている過去の取引の結果を保留状態値決定部２４へ送信する。

【0053】

結果ＤＢ更新部１５は、保留状態値決定部２４によって決定された値を結果ＤＢ１２２へ登録することで、結果ＤＢ１２２を更新する。

【0054】

値反映要求部１６は、保留状態の変数について、保留状態値決定部２４によって決定された値の反映を各ＢＣ２０へ要求する。

【0055】

通知部１７は、各ＢＣ２０に対して通知を送信する。通知受信部１８は、各ＢＣ２０からの通知を受信する。

【0056】

以下、取引制御システム１において実行される処理手順について説明する。図９～図１２は、取引制御システム１において実行される処理手順の一例を説明するためのシーケンス図である。

【0057】

ステップＳ１０１において、ＢＣ２０－１のリクエスト受付部２１は、データの価格付けの申請に関するリクエストの入力を申請者から受け付ける。当該リクエストには、例えば、上述した評価式（ｙ＝２００ｘ_１＋５０ｘ_２）が含まれる。

【0058】

続いて、ＢＣ２０－１の保留状態取引発行部２２は、当該リクエストに応じた申請取引をＢＣ２０－１内において発行する（Ｓ１０２）。その結果、ＢＣ２０－１内の各ノードの台帳には、当該リクエストに含まれている評価式が記録される。

【0059】

連携サーバ１０のイベント監視部１１は、当該申請取引の発行を検知すると、当該申請取引においてＢＣ２０－１の台帳に記録された評価式を取得する（Ｓ１０３）。続いて、条件式ＤＢ更新部１２は、当該評価式を条件式ＤＢ１２１に記録することで、条件式ＤＢ１２１を更新する（Ｓ１０４）。続いて、連携サーバ１０の通知部１７は、ワークフローの発生の通知をＢＣ２０－２へ送信する（Ｓ１０５）。

【0060】

ＢＣ２０－２の通知受信部２９が当該通知を受信すると、ＢＣ２０－２の通知部２８は、ワークフローの発生を審査官Ａ１に対して通知する（Ｓ１０６）。例えば、ＢＣ２０－２の通知部２８は、ＢＣ２０－２のスマートコントラクトと連携するアプリケーションに対してワークフローの発生を通知し、当該アプリケーションが、所定のユーザインタフェースを介して審査官Ａ１に対してワークフローの発生を通知してもよい。

【0061】

審査官Ａ１は、ワークフローの発生の通知に応じ、当該ワークフローの評価式のうち、審査官Ａ１が審査すべき変数（上記の例では、ｘ_１）の値の条件式を決定する。続いて、ＢＣ２０－２のリクエスト受付部２１は、当該条件式を含むリクエストの入力を受け付ける（Ｓ１０７）。なお、審査官Ａ１は、評価式のうち自らが審査すべき変数を事前に知っていることとする。ＢＣ２０－２の保留状態取引発行部２２は、当該リクエストの入力に応じ、当該変数の値について保留状態とする取引をＢＣ２０－２において発行する（Ｓ１０８）。その結果、当該条件式がＢＣ２０－２の各ノードの台帳に記録される。続いて、条件式ＤＢ更新要求部２３は、条件式ＤＢ１２１の更新要求を示すイベント又は取引を発行する（Ｓ１０９）。

【0062】

連携サーバ１０のイベント監視部１１は、当該イベント又は当該取引の発行を検知すると、ＢＣ２０－２の台帳に記録された条件式を取得する（Ｓ１１０）。続いて、条件式ＤＢ更新部１２は、当該条件式を条件式ＤＢ１２１に記録することで、条件式ＤＢ１２１を更新する（Ｓ１１１）。続いて、連携サーバ１０の通知部１７は、ワークフローの発生の通知をＢＣ２０－３へ送信する（図１０のＳ１１２）。

【0063】

ステップＳ１１３～Ｓ１１８においては、図９のステップＳ１０５～Ｓ１１１と同様の処理手順が実行される。但し、ステップＳ１１３～Ｓ１１８におけるユーザは、審査官Ａ２であり、ＢＣ２０は、ＢＣ２０－３であり、条件式は審査官Ａ２が審査すべき変数（上記の例では、ｘ_２）の値の条件式である。

【0064】

続いて、連携サーバ１０の通知部１７は、ワークフローの発生の通知をＢＣ２０－４へ送信する（図１１のＳ１１９）。ＢＣ２０－４の通知受信部２９が当該通知を受信すると、ＢＣ２０－４の保留状態値決定部２４は、条件式ＤＢ１２１及び結果ＤＢ１２２の値の参照要求を示すイベント又は取引をＢＣ２０－４において発行する（Ｓ１２０）。その結果、当該取引に関する情報がＢＣ２０－４の台帳に記録される。

【0065】

連携サーバ１０のイベント監視部１１が、当該イベント又は当該取引の発行を検知すると（Ｓ１２１）、連携サーバ１０の条件式ＤＢ参照部１３は、現在のワークフローに関する評価式及び当該評価式の各変数の条件式、並びに既定条件式等の値を結果ＤＢ１２２から取得し、取得した値をＢＣ２０－４の保留状態値決定部２４へ通知する（Ｓ１２２）。また、連携サーバ１０の結果ＤＢ参照部１４は、過去のワークフローに関するの各変数の値、及び評価式の値（すなわち、価格）の履歴を含む値を結果ＤＢ１２２から取得し、取得した値をＢＣ２０－４の保留状態値決定部２４へ通知する（Ｓ１２３）。その結果、ＢＣ２０－４の保留状態値決定部２４は、評価式、当該評価式の各変数の条件式、既定条件式、並びに過去のワークフローに関するの各変数の値、及び評価式の値（すなわち、価格）の履歴を含む値を取得する。

【0066】

ＢＣ２０－４の保留状態値決定部２４は、ステップＳ１２２及びＳ１２３において取得した各値に基づいて、保留状態の各値を決定（算定）する（Ｓ１２４）。すなわち、保留状態値決定部２４は、各変数について条件式及び既定条件式を満たす値から選定した値を評価式に代入することで、価格（評価値）を算定する。続いて、ＢＣ２０－４の終点決済取引発行部２５は、終点決済取引を発行する（Ｓ１２５）。終点決済取引の発行により、決定された価格及び各変数の値がＢＣ２０－４の台帳に記録される。

【0067】

続いて、ＢＣ２０－４の値決定通知部２６は、各ＢＣ２０上における保留状態の解除要求を示すイベント又は取引を発行する（図１２のＳ１２６）。なお、当該イベント又は取引の発行に応じてステップＳ１２７以降が実行される。したがって、当該イベント又は取引の発行は、ＢＣ２０－４において選定された各変数の値（又は算定された価格）について、Ｂ２０－２及びＢＣ２０－３（又はＢＣ２０－１）への送信の制御に相当する。

【0068】

連携サーバ１０のイベント監視部１１は、当該イベント又は当該取引の発行を検知すると（Ｓ１２７）、ＢＣ２０－４において算定された価格及び選定された各変数の値を取得する。続いて、連携サーバ１０の値反映要求部１６は、ＢＣ２０－２に対して、保留状態の変数への値の代入要求を示すイベント又は取引を発行する（Ｓ１２８）。当該イベント又は取引の発行に伴って、ＢＣ２０－２において保留状態とされている変数（ｘ_１）について選定された値を示す情報がＢＣ２０－２へ送信される。

【0069】

ＢＣ２０－２の値反映取引発行部２７は、当該情報を受信すると、保留状態とされている変数（ｘ_１）に対して当該情報が示す値を代入する（Ｓ１２９）。その結果、ＢＣ２０－２の台帳には、当該変数の値が記録（反映）される。続いて、ＢＣ２０－２の通知部２８は、保留状態の変数への値の反映の終了通知を連携サーバ１０へ送信する（Ｓ１３０）。連携サーバ１０の通知受信部１８が当該終了通知を受信すると、連携サーバ１０の結果ＤＢ更新部１５は、当該変数の値を結果ＤＢ１２２へ記録する（Ｓ１３１）。

【0070】

続くステップＳ１３２～Ｓ１３５では、ステップＳ１２８～Ｓ１３１と同様の処理手順がＢＣ２０－３に関して実行される。その結果、ＢＣ２０－３の台帳には、ＢＣ２０－３において保留状態だった変数（ｘ_２）の値が記録され、結果ＤＢ１２２には、当該変数の値が記録される。

【0071】

なお、ＢＣ２０－１についても、ステップＳ１２８～Ｓ１３１と同様の処理手順が実行されてもよい。その場合、ＢＣ２０－１の台帳には、価格ｙの値が記録されてもよい。

【0072】

上述したように、本実施の形態によれば、複数のブロックチェーンを跨ぐ、保留状態を含むワークフローについて、最終時点の取引（終点決済取引）における属性値付与の自由度を上げることができる。すなわち、途中の取引では条件式を除き保留状態となっているため、アプローチ１に比べて終点決済取引の自由度を高くすることができる。また、本実施の形態によれば、終点決済取引においては、当該取引に係るＢＣ２０－４と連携サーバ１０との間におけるやりとりが行われればよいため、アプローチ２に比べて時間を短縮することができる。その結果、ワークフローの各段階において、ブロックチェーンへの記録に要する負荷を軽減することができる。

【0073】

なお、本実施の形態において、申請者は、第１のユーザの一例である。審査官は、第２のユーザの一例である。ＢＣ２０－１は、第１のブロックチェーンネットワークの一例である。ＢＣ２０－２又はＢＣ２０－３は、第２のブロックチェーンネットワークの一例である。

【0074】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0075】

１ 取引制御システム
１０ 連携サーバ
１１ イベント監視部
１２ 条件式ＤＢ更新部
１３ 条件式ＤＢ参照部
１４ 結果ＤＢ参照部
１５ 結果ＤＢ更新部
１６ 値反映要求部
１７ 通知部
１８ 通知受信部
２０ ＢＣ
２１ リクエスト受付部
２２ 保留状態取引発行部
２３ 条件式ＤＢ更新要求部
２４ 保留状態値決定部
２５ 終点決済取引発行部
２６ 値決定通知部
２７ 値反映取引発行部
２８ 通知部
２９ 通知受信部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１２１ 条件式ＤＢ
１２２ 結果ＤＢ
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】