【文献】
佐藤 竜也,パーミッション型ブロックチェーンシステム向け運用スマートコントラクトの適用範囲拡大と共通コンポーネント化,電子情報通信学会技術研究報告 Vol.118 No.118 [online],日本,一般社団法人電子情報通信学会,2018年06月28日,第118巻,pp.41-46
(58)【調査した分野】(Int.Cl.,DB名)
前記要求処理部は、全ての参加希望者組織の情報を前記全ての参加希望者組織に通知し、前記参加希望者組織から前記合意条件を満たす合意が得られたら前記コンソーシアムの結成を確定する、
請求項1に記載のコンソーシアム支援システム。
前記コンソーシアム内のみで前記参加者組織が相互に情報を共有可能にする業務用システムとして、前記参加者組織が所属するブロックチェーンネットワークを作成する業務用システム作成部を更に有する、
請求項1に記載のコンソーシアム支援システム。
前記要求処理部は、前記参加希望者組織のそれぞれに対して、全ての参加希望者組織を知得可能にする第1画面と、前記コンソーシアムの結成に対する承認の意思を入力可能にする第2画面と、を提示し、前記第2画面から入力された前記承認の意思に基づいて、前記参加希望者組織から前記合意条件を満たす合意が得られたか否か判定する、
請求項2に記載のコンソーシアム支援システム。
前記要求処理部は、第1コンソーシアムと第2コンソーシアムを含む複数のコンソーシアムについて参加希望者組織を募っているとき、前記第1コンソーシアムの作成を申請した契約者組織が前記第2コンソーシアムへの参加を希望したら、前記第1コンソーシアムに参加を希望していた契約者組織に対して、前記第2コンソーシアムへの招待を送るか、あるいは前記第2コンソーシアムへの参加を希望した状態とする、
請求項1に記載のコンソーシアム支援システム。
【発明を実施するための形態】
【0011】
以下、本発明の実施形態について図面を参照して説明する。
【0012】
図1は、一実施の形態に係るコンソーシアム支援システムの動作概要を説明するための図である。
【0013】
本実施の形態に係るコンソーシアム支援システム1は、例えば、コンソーシアム型のブロックチェーン(以下「BC」という)技術に基づいて構成される。例えば、コンソーシアム支援システム1は、組織により構成されるコンソーシアムの作成および管理を行うためのBC基盤を提供する。BC基盤を管理する機構(以下「管理機構」という)が提供するシステム(以下「管理システム」という。
図1には図示せず)は、当該コンソーシアム支援システム1への参加の契約を締結した各会社(
図1に示すA社〜D社)に相当する組織をそのBC基盤に所属させる。或いは、コンソーシアム支援システム1のBC基盤は、管理機構が提供する管理システムと、各組織の組織システム2と、によって構成されるとも言える。なお、以下の説明において、コンソーシアム支援システム1を単にシステム1と表記する場合がある。
【0014】
図1は、システム1への参加の契約を締結している会社A〜会社Dがそれぞれ提供している組織システム2(1)〜2(4)(Org1〜Org4)に基づいて、BC基盤が構成されている例を示す。なお、システム1への参加の契約を締結している組織を「契約者組織」と呼んでもよい。
【0015】
各組織システムOrg1〜4は、BC技術に基づく台帳テーブル22及びスマートコントラクト(SC)を有する。この台帳テーブル22及びスマートコントラクトは、BC技術によって、各組織システム2の間で同期される。また、このBC技術による同期処理は、各組織システム2にて動作するPEER21によって実行される。
【0016】
本実施の形態に係るコンソーシアム支援システム1は、当該システム1(つまりBC基盤)に参加している会社が新たなコンソーシアムを容易に作成できる機能を提供する。次に、当該機能の概要について、
図1を参照して説明する。
【0017】
新たなコンソーシアム3を結成したい会社A(4(1))は、その旨をシステム1に指示する(S2)。
【0018】
システム1は、当該システム1に参加している全ての会社A,B,C,D(4(1)〜(4))に対して、新たなコンソーシアム3への招待メッセージを配信する(S2’)。
【0019】
新たなコンソーシアム3への招待メッセージを受信した各会社A,B,C,Dのうち、新たなコンソーシアムへの参加を希望する会社A,B,Cは、その旨をシステムに伝える(S3)。なお、新たなコンソーシアムへの参加を希望する組織を「参加希望組織」と呼んでもよい。また、新たなコンソーシアムへの招待メッセージを、募集情報と呼んでもよい。
【0020】
システムは、新たなコンソーシアム3への参加を表明した会社A,B,Cにおいて合意形成が成された場合(S4)、この新たなコンソーシアムに関する情報(例えば各会社の署名)を台帳テーブル22に登録する(S4’)。なお、新たなコンソーシアムに実際に参加した組織を「参加者組織」と呼んでもよい。
【0021】
そして、システム1は、この新たなコンソーシアム3のための業務用システムを作成する(S5)。例えば、システム1は、新たなコンソーシアム3に参加する会社A,B,Cの組織システムによって、新たなコンソーシアム3のための業務用システム(例えばBC基盤の台帳テーブル22)を作成する。
【0022】
このようにして、システム1に参加している企業は、容易に新たなコンソーシアムを結成することができる。以下、詳細に説明する。
【0023】
図2は、コンソーシアム支援システム1における管理システムの構成例を示す。なお、管理システムはOrg0と呼ばれてもよい。
【0024】
管理システムは、要求処理部11、組織生成部13、業務用システム作成部14、台帳テーブル12、及び、契約管理テーブル15を有する。管理システムにおける要求処理部11、組織生成部13、及び、業務用システム作成部14は、まとめてコンソーシアム結成制御部10と呼ばれてもよい。
【0025】
組織生成部13は、コンソーシアム支援システム1に新たに参加する会社の組織システムを、コンソーシアム支援システム1(つまりBC基盤)に参加させるための処理を行う。なお、組織生成部13の処理の具体例については後述する(
図9参照)。
【0026】
契約管理テーブル15は、コンソーシアム支援システム1に参加している会社(組織)の契約情報を管理する。
図2では、管理システムが契約管理テーブル15を保持する構成であるが、契約管理テーブル15は、台帳テーブル12、22と同様、BC技術によって、管理システム及び組織システム2が保持する構成であってもよい。なお、契約管理テーブル15の具体例については後述する(
図4参照)。
【0027】
業務用システム作成部14は、新たなコンソーシアム向けの業務用システムを作成するための処理を行う。なお、業務用システム作成部14の処理の具体例については後述する(
図14参照)。
【0028】
要求処理部11は、コンソーシアム招待部111、コンソーシアム参加判定部112、及び、コンソーシアム確定部113を有する。なお、要求処理部11、コンソーシアム招待部111、コンソーシアム参加判定部112、コンソーシアム確定部113、及び、台帳テーブル12については、
図3にて説明する。
【0029】
図3は、コンソーシアム支援システム1に生成された組織システム2の構成例を示す。組織システム2は、要求処理部21、及び、台帳テーブル22を有する。
【0030】
要求処理部21は、
図1に示すPEER21に相当し、例えば、新たなコンソーシアムの結成のための処理を実行する。要求処理部21は、コンソーシアム招待部211、コンソーシアム参加判定部212、及び、コンソーシアム確定部213を有する。
【0031】
コンソーシアム招待部211は、各組織システム2に対する、新たなコンソーシアムへの招待に関する処理を行う。なお、コンソーシアム招待部211の処理の具体例については後述する(
図11参照)。
【0032】
コンソーシアム参加判定部212は、組織システム2の、新たなコンソーシアムへの参加判定に関する処理を行う。なお、コンソーシアム参加判定部212の処理の具体例については後述する(
図12参照)。
【0033】
コンソーシアム確定部213は、組織システム2の、新たなコンソーシアムへの参加を確定するための処理を行う。なお、コンソーシアム確定部213の処理の具体例については後述する(
図13、
図15参照)。
【0034】
台帳テーブル22には、BC技術に基づいて、コンソーシアム支援システム1に参加している各組織システム2の間のトランザクションが記録される。例えば、台帳テーブル22には、どの会社(組織システム2)が、新たなコンソーシアムの結成に合意したかを示す情報などが記録される。
【0035】
図4は、契約管理テーブル15の構成例を示す。契約管理テーブル15は、システム1に参加している会社(組織システム2)の契約情報を管理する。
【0036】
契約情報は、
図4に示すように、契約ID151、会社名152、連絡先153、許容可能なシステム要件154、及び、BC上の組織名155を有する。
【0037】
契約ID151は、契約情報の識別子を示す。
会社名152は、システム1に参加している会社の名称を示す。
連絡先153は、システム1に参加している会社の連絡先(例えばメールアドレス)を示す。
許容可能なシステム要件154は、システム1に参加している会社が備えている計算機システムが許容可能なシステム要件を示す。
BC上の組織名155は、システム1(BC基盤)上における組織システム2の名称を示す。
【0038】
次に、許容可能なシステム要件154に含まれる各要素について説明する。
−internetのyes/noは、組織システム2が、インターネット経由の接続を許容するか否かを示す。
−vpnのyes/noは、組織システム2が、VPN経由の接続を許容するか否かを示す。
−security-levelのlow/mid/highは、組織システム2が許容するセキュリティレベルを示す。
−my-channelのyes/noは、組織システム2が、組織間専用のチャネルの作成を許容するか否かを示す。組織間専用のチャネルとは、特定の組織システム2の間だけで情報をやり取りできる専用のチャネルである。
【0039】
図5及び
図6は、台帳テーブル22における、組織システム情報の管理例を示す。
図5及び
図6に示すように、台帳テーブル22は、キー(key)221と値(Value)222の組で情報を管理する。台帳テーブル22における組織システム情報は、キー221としてBCにおける組織名を、値222としてその組織システム2に関する情報を有する。
【0040】
次に、組織システム2に関する情報に含まれる各要素について説明する。
−nameは、BC上の組織名を示す。
−company-nameは、会社名を示す。
−mailは、会社への連絡先(例えばメールアドレス)を示す。
−consortium-idは、会社が属するコンソーシアムのID(CID)を示す。
−consortiumは、子要素として、コンソーシアムに関する情報を含む。次に、consortiumに含まれる各要素について説明する。
−nameは、コンソーシアム名を示す。
−activeのyes/noは、コンソーシアムが有効か否かを示す。
−invitationは、コンソーシアムへの招待メッセージの情報を示す。
−consortiumの子要素であるconditionは、子要素として、コンソーシアムへの参加において組織システム2が満たすべき要件を示す情報を含む。次に、consortiumの子要素であるconditionに含まれる各要素について説明する。
−internetのyesは、コンソーシアムへの参加要件が、「組織システムがインターネット経由での接続を許容していること」であることを示す。
−vpnのyesは、コンソーシアムへの参加要件が、「組織システムがVPN経由での接続を許容していること」であることを示す。
−security-levelのmidは、コンソーシアムへの参加要件が、「組織システムのセキュリティレベルがmid以上であること」であることを示す。low、highについても同様である。
−my-channelのyesは、コンソーシアムへの参加の要件が、「組織システムがmy-channelの作成を許容していること」であることを示す。
−statusは、コンソーシアムへの登録状態を示す。
−consortium-networkidは、コンソーシアムに紐付く業務用システムのIDを示す。
【0041】
なお、consortiumの子要素でないconditionに含まれる要素については、
図4と同様であるので説明を省略する。
【0042】
図7は、コンソーシアム招待画面の一例を示す。新たなコンソーシアムへの招待メッセージを受信した会社の組織システム2は、例えば、
図7に示すコンソーシアム招待画面5を表示する。
【0043】
コンソーシアム招待画面5には、例えば、コンソーシアムの目的を示す情報51、及び、コンソーシアムに関する情報52が表示される。
【0044】
コンソーシアムに関する情報52として、コンソーシアム名521、コンソーシアムへの招待メッセージを受信した会社の識別コード522、及び、当該会社の名称523が表示される。また、コンソーシアムに関する情報52として、このコンソーシアムに参加を表明している会社(組織システム2)による、コンソーシアムの構成
図524が表示される。
【0045】
また、コンソーシアム招待画面5には、参加登録ボタン531、結成承認ボタン532、及び、拒否ボタン533が表示される。コンソーシアムへの招待メッセージを受信した会社は、コンソーシアムに参加を表明する場合、参加登録ボタン531を押下する。コンソーシアムへの参加を表明した会社は、コンソーシアム構成
図524に表示された会社によるコンソーシアムの結成を承認する場合、結成承認ボタン532を押下する。一方、コンソーシアムへの参加を表明した会社は、コンソーシアム構成
図524に表示された会社によるコンソーシアムの結成を承認しない場合、拒否ボタン533を押下する。
【0046】
図8は、所属先コンソーシアム管理テーブルの構成および遷移の一例を示す。なお、所属先コンソーシアム管理テーブルは、コンソーシアム支援システム1(BC基盤)に構成されてよい。
【0047】
所属先コンソーシアム管理テーブルは、各組織システム2が所属するコンソーシアムを管理するためのテーブルである。所属先コンソーシアム管理テーブルは、契約ID、組織名、及び、コンソーシアムID(CID)を対応付けて管理する。
【0048】
次に、
図8を参照して、或るコンソーシアムが、別のコンソーシアムに合流する例を説明する。例えば、同時に2つの類似する目的のコンソーシアムの作成が進行した場合、いずれか一方のコンソーシアムを他方に合流させることがありうる。
【0049】
ここでは、Org1によるコンソーシアムの作成と、Org2によるコンソーシアムの作成とが同時に進行したものとする。Org1が作成するコンソーシアムのCIDは「123」であり、Org2が作成するコンソーシアムのCIDは「456」である。Org3が、CID「456」のコンソーシアムに参加を表明すると、
図8の中段の所属先コンソーシアム管理テーブルに示すように、Org3に対応付けられているCIDが「456」に変更される。
【0050】
ここでは一例としてCID「123」のコンソーシアムの目的とCID「456」のコンソーシアムの目的とが類似しているため、それら2つのコンソーシアムが合流するものとする。ここでは、CID「456」のコンソーシアムを作成したOrg2がCID「123」のコンソーシアムへの参加を表明する。そうすると、Org2及びOrg3が属するCID「456」のコンソーシアムが、Org1が生成したCID「123」のコンソーシアムに合流することになる。その場合、
図8の下段の所属先コンソーシアム管理テーブルに示すように、Org2及びOrg3のそれぞれ対応付けられているCIDが「123」に変更される。これにより、CID「123」のコンソーシアムのBCネットワークは、Org1、2及び3の組織システム2によって構成されるようになる。
【0051】
このようにして、コンソーシアム支援システム1は、或るコンソーシアムを別のコンソーシアムに合流させることができる。
【0052】
図9は、組織生成部13の処理例を示すフローチャートである。本処理は、コンソーシアム支援システム1に新たな会社(組織システム2)が参加する場合に実行される。
【0053】
組織生成部13は、契約管理テーブル15に、新たな組織の契約情報が追加されたか否かを判定する(S11)。つまり、新たな組織が、システム1に参加したか否かを判定する。
【0054】
組織生成部13は、契約管理テーブル15に、新たな組織の契約情報が追加されていない場合(S11:NO)、S11の処理を繰り返す。
【0055】
組織生成部13は、契約管理テーブル15に、新たな組織の契約情報が追加された場合(S11:YES)、その追加された契約情報に対応する契約トランザクションを生成する(S12)。
【0056】
組織生成部13は、生成した契約トランザクションの承認及び登録を、例えば管理機構(Org0)に依頼する(S13)。管理機構は、問題が無ければ、その契約トランザクションを承認及び登録する。
【0057】
組織生成部13は、契約トランザクションが、管理機構によって承認及び登録されたことを確認する(S14)。
【0058】
組織生成部13は、契約者組織に対して、新たな組織の追加が完了したことを通知する(S15)。そして、組織生成部13は、S11の処理に戻る。
【0059】
図10は、要求処理部の処理例を示すフローチャートである。
【0060】
要求処理部は、システムにおいて発生した要求がコンソーシアム招待部211の呼び出しであるか否かを判定する(S21)。
【0061】
要求処理部は、コンソーシアム招待部211の呼び出しと判定した場合(S21:YES)、コンソーシアム招待部211を呼び出す(S30)。なお、コンソーシアム招待部211の処理については後述する(
図11参照)。
【0062】
要求処理部は、コンソーシアム招待部211を呼び出しでないと判定した場合(S21:NO)、発生した要求がコンソーシアム確定部213の呼び出しであるか否かを判定する(S22)。
【0063】
要求処理部は、コンソーシアム確定部213の呼び出しでないと判定した場合(S22:NO)、コンソーシアム参加判定部212を呼び出す(S40)。なお、コンソーシアム参加判定部212の処理については後述する(
図12参照)。
【0064】
要求処理部は、コンソーシアム確定部213の呼び出しであると判定した場合(S22:YES)、コンソーシアム確定部213を呼び出す(S50)。なお、コンソーシアム確定部213の処理については後述する(
図13参照)。
【0065】
図11は、コンソーシアム招待部211の処理例を示すフローチャートである。本処理は、或る会社が、新たなコンソーシアムの作成を申請した場合に、
図10のS30において呼び出される。本処理は、コンソーシアムの作成を申請した会社の組織システム2によって実行されてもよいし、管理システムによって実行されてもよい。
【0066】
コンソーシアム招待部211は、新たなコンソーシアムの作成を申請した会社の組織システム2に対して、コンソーシアム作成トランザクションの承認を依頼する(S31)。コンソーシアム招待部211は、コンソーシアム作成トランザクションが承認された場合、新たなコンソーシアムに関する情報を、台帳テーブル22に記録する。
【0067】
コンソーシアム招待部211は、台帳テーブル22の更新内容を確認する(S32)。
【0068】
コンソーシアム招待部211は、コンソーシアムへの参加を希望するか否かの判定要求(以下「参加希望判定要求」という)を、全ての組織システム2に対して送信する(S33)。コンソーシアムへの参加を希望する会社は、参加希望判定要求に対して、参加希望応答を返信する。
【0069】
コンソーシアム招待部211は、参加希望応答を返信してきた組織システム2に対して、コンソーシアムの結成承認要求を送信する(S34)。コンソーシアムの結成承認要求には、例えば、参加希望の会社を示す情報が含まれる。コンソーシアムの結成を承認する組織システム2は、コンソーシアムの結成承認要求に対して、結成承認応答を返信する。
【0070】
コンソーシアム招待部211は、コンソーシアムへの参加を希望している全ての組織システム2から結成承認応答を受信した場合、コンソーシアムを結成すると決定する。この場合、コンソーシアム招待部211は、契約管理テーブル15に登録されている会社のうち、新たなコンソーシアムに参加する会社の連絡先に対して、コンソーシアムが結成された旨を通知する(S35)。
【0071】
図12は、コンソーシアム参加判定部212の処理例を示すフローチャートである。本処理は、例えば、或る組織システム2が、コンソーシアムへの参加希望判定要求を送信した場合及び受信した場合に、
図10のS40において呼び出される。
【0072】
コンソーシアム参加判定部212は、参加希望判定要求の送信に関する処理であるか否かを判定する(S41)。
【0073】
まず、S41の判定結果がYESの場合の処理、すなわち、
図11のS33においてコンソーシアムの参加希望判定要求を送信する組織システム2における、コンソーシアム参加判定部212の処理について説明する。
【0074】
この場合、コンソーシアム参加判定部212は、台帳テーブル22における、コンソーシアムの作成を申請した組織のレコードから、コンソーシアムに関する情報を取得する(S42)。
【0075】
コンソーシアム参加判定部212は、契約管理テーブル15から、契約者組織の一覧を取得する(S43)。
【0076】
コンソーシアム参加判定部212は、S43で取得した全ての契約者組織システム2に対して、参加判定トランザクションを発生させ(S44)、本処理を終了する。参加判定トランザクションは、例えば、コンソーシアムに関する情報を入力データとし、呼び出し種別として応答を要求するトランザクションとして生成される。コンソーシアムに関する情報には、例えば、コンソーシアムID、コンソーシアム名、招待メッセージ、参加に関して組織システム2が満たすべき要件等が含まれる。
【0077】
次に、S41の判定の結果がNOの場合の処理、すなわち、コンソーシアムの参加希望判定要求を受信した組織システム2における、コンソーシアム参加判定部212の処理について説明する。
【0078】
コンソーシアム参加判定部212は、台帳テーブル22から、自組織(参加判定トランザクションを受けた組織)の参加条件(システム要件)を取得する(S45)。
【0079】
コンソーシアム参加判定部212は、自組織のシステム要件(
図4参照)とコンソーシアムのシステム要件(
図5及び
図6参照)が一致するか否かを判定する(S46)。
【0080】
コンソーシアム参加判定部212は、自組織のシステム要件がコンソーシアムのシステム要件と一致しないと判定した場合(S46:NO)、本処理を終了する。すなわち、自組織は、コンソーシアムへの参加を行わない。自組織の組織システム2と、作成される新たなコンソーシアムのBCネットワークとがシステム要件において整合しないため、自組織の管理者等による人的判断を経るまでもなく、参加を表明しないと決定するものである。
【0081】
コンソーシアム参加判定部212は、自組織のシステム要件がコンソーシアムのシステム要件と一致すると判定した場合(S46:YES)、自組織の連絡先に対して、コンソーシアムへの招待メッセージ(例えば電子メール)を送信する(S47)。
【0082】
コンソーシアム参加判定部212は、自組織がコンソーシアムへの参加を表明した場合、S44の参加判定トランザクションを承認する。さらに、コンソーシアム参加判定部212は、自組織が作成を申請した他コンソーシアムがあれば、他コンソーシアムに参加を表明した組織のコンソーシアムIDを更新する(S48)。すなわち、当該他コンソーシアムを、新たなコンソーシアムに合流させる。そして、コンソーシアム参加判定部212は、本処理を終了する。
【0083】
図13は、コンソーシアム確定部213の処理例を示すフローチャートである。
【0084】
コンソーシアム確定部213は、何れかの組織が属するコンソーシアムIDが変更されたか否かを判定する(S51)。コンソーシアム確定部213は、コンソーシアムIDが変更されていない場合(S51:NO)、S51の処理を継続する。
【0085】
コンソーシアム確定部213は、何れかの組織の属するコンソーシアムIDが変更された場合(S51:YES)、次のS52を実行する。すなわち、コンソーシアム確定部213は、新たなコンソーシアムへの参加を表明した組織が存在する場合、次のS52を実行する。
【0086】
コンソーシアム確定部213は、参加を表明した組織の連絡先に対して、コンソーシアムの結成を承認するか否かを確認するためのメッセージ(
図7参照)を送信する(S52)。
【0087】
コンソーシアム確定部213は、参加を表明した全ての組織がコンソーシアムの結成を承認したか否かを判定する(S53)。
【0088】
コンソーシアム確定部213は、参加を表明した組織のうちの少なくとも1つの組織がコンソーシアムの結成を承認しない場合(S53:NO)、S51の処理に戻る。
【0089】
コンソーシアム確定部213は、参加を表明した全ての組織がコンソーシアムの結成を承認した場合(S53:YES)、次のS54の処理を行う。
【0090】
コンソーシアム確定部213は、新たなコンソーシアムを構成する全ての組織システム2から、コンソーシアムを合意完了状態にするための合意トランザクションの承認を得て、台帳テーブル22を更新する(S54)。
【0091】
業務用システム作成部14は、業務用システム作成処理を実行する(S60)。業務用システム作成処理の詳細については後述する(
図14参照)。そして、コンソーシアム確定部213は、S51の処理に戻る。
【0092】
図14は、業務用システム作成部14の処理例を示すフローチャートである。本処理は、
図13のS60の処理に相当する。
【0093】
業務用システム作成部14は、台帳テーブル22から、新たなコンソーシアムに属する組織の一覧を取得する(S61)。
【0094】
業務用システム作成部14は、台帳テーブル22から、新たなコンソーシアムに関する情報を取得する(S62)。
【0095】
業務用システム作成部14は、S61で取得した組織の一覧に基づき、新たに結成するコンソーシアムのためのBCネットワークを作成する(S63)。なお、このBCネットワークは、コンソーシアムのシステム要件およびコンソーシアムに参加する各組織のシステム要件を満たすように作成される。
【0096】
業務用システム作成部14は、コンソーシアムを完了状態へ更新し、業務用システムのIDを更新する(S64)。具体的には、業務用システム作成部14は、コンソーシアムIDのデータを保持するレコード(組織)のコンソーシアム状態を「完了状態」に更新し、そのコンソーシアムIDに紐付く業務用システムのIDを更新する。
【0097】
以上の処理により、新たなコンソーシアムに参加した会社の組織システム2によって、新たなコンソーシアムのためのBCネットワーク(業務用システム)が作成される。
【0098】
図15は、コンソーシアム確定部213の処理の変形例を示すフローチャートである。コンソーシアム確定部213は、
図13に示す処理に代えて、
図15に示す処理を実行してもよい。
【0099】
コンソーシアム確定部213は、
図13に示すS51〜S52の処理を実行する。
【0100】
コンソーシアム確定部213は、新たなコンソーシアムを結成する組織の重み付けされた承認スコアが、所定値以上であるか否か判定する(S53A)。
【0101】
コンソーシアム確定部213は、承認スコアが所定値未満の場合(S53A:NO)、S51の処理に戻る。
【0102】
コンソーシアム確定部213は、承認スコアが所定値以上の場合(S53A:YES)、
図13に示すS54の処理を行う。
【0103】
業務用システム作成部14は、業務用システム作成処理を実行する(S60)。
【0104】
これにより、
図14のS53のように新たなコンソーシアムを結成する全ての組織の承認を得なくても、新たなコンソーシアムを結成する主要な組織の承認によって、新たなコンソーシアムを結成することができる。なお、組織の重み付けの例としては、コンソーシアムに提供するデータ量の大小に応じた重み付け、コンソーシアムの作成を申請した組織により指定された重み付け等がある。
【0105】
以上説明した本実施形態による開示は以下にまとめる事項を含む。ただし、本開示が以下の事項に限定されるわけではない。
本開示の一態様に係るコンソーシアム支援システム1は、所定の契約を行った組織である契約者組織に関する情報を契約管理情報として記録し、所定の管理機構と契約者組織とを管理用ブロックチェーンに所属させる組織生成部13と、契約管理情報に基づき、管理機構から契約者組織へ、コンソーシアムへ参加する組織を募集する募集情報を送信し、募集に応じた契約者組織である参加希望者組織から所定の合意条件を満たす合意が得られたら、管理用ブロックチェーンを利用して、参加希望者組織を参加者組織とするコンソーシアムの結成を確定する要求処理部11、21と、を有する。
【0106】
この構成により、参加希望者組織から所定の合意条件を満たす合意が得られたら、コンソーシアムを結成するので、必ずしも互いの信頼関係がない状態からでも複数の組織によるコンソーシアムの結成を支援することができる。
【0107】
要求処理部11,21は、全ての参加希望者組織の情報を全ての参加希望者組織に通知し、参加希望者組織から合意条件を満たす合意が得られたらコンソーシアムの結成を確定してよい。
【0108】
この構成により、参加希望者組織に相互の参加希望者組織の情報を通知して合意を確認するので、参加希望者は他の参加希望者としてどのような組織が含まれているか認識したうえで結成を承認することができる。
【0109】
要求処理部11,21は、コンソーシアムの結成を確定したら、コンソーシアムおよび該参加者組織の情報を管理用ブロックチェーン(例えば台帳テーブル12,22)の台帳情報として記録してよい。
【0110】
この構成により、管理用ブロックチェーンの台帳情報としてコンソーシアムおよびその参加者組織の情報を安全に記録することができる。
【0111】
コンソーシアム支援システム1は、コンソーシアム内のみで参加者組織が相互に情報を共有可能にする業務用システムとして、参加者組織が所属するブロックチェーンネットワークを作成する業務用システム作成部14を更に有してよい。
【0112】
この構成により、所定の合意条件により結成されるコンソーシアムに対して、参加者組織がコンソーシアム内で利用可能な情報システムとしてBC基盤を提供することができるので、結成したコンソーシアムによる情報共有においても参加者組織の負担を軽減することができる。
【0113】
契約管理情報には、契約者組織が業務用システムにおいて許容するシステム要件の情報が含まれ、コンソーシアムの作成を申請する作成者組織は、業務用システムに適用するシステム要件である適用システム要件を指定でき、要求処理部11,21は、適用システム要件を許容する契約者組織の内から参加希望者組織を募り、業務用システム作成部14は、システム要件を満たすように業務用システムを作成してよい。
【0114】
この構成により、コンソーシアムの業務用システムに適用するシステム要件を許容する組織によりコンソーシアムを結成し、そのシステム要件を満たすように業務用システムを作成するので、コンソーシアムと参加者組織のシステム要件に関する整合を取ることができる。
【0115】
要求処理部11,21は、参加希望者組織のそれぞれに対して、全ての参加希望者組織を知得可能にする第1画面(例えば
図7の構成
図524)と、コンソーシアムの結成に対する承認の意思を入力可能にする第2画面(例えば
図7の結成承認ボタン532)と、を提示し、第2画面から入力された承認の意思に基づいて、参加希望者組織から合意条件を満たす合意が得られたか否か判定してよい。
【0116】
この構成により、参加希望者組織では他にどの組織が参加を希望しているかを見てコンソーシアムの結成に合意するか否か判断できる。
【0117】
上記合意条件は、全ての参加希望者組織のそれぞれが全ての参加希望者組織を認識できる状態でコンソーシアムの結成を承認するという条件であり、要求処理部11,21は、全ての参加希望者組織がコンソーシアムの結成を承認したことを知得してコンソーシアムの結成を確定してよい。
【0118】
この構成により、全ての参加希望者組織の総意に基づいてコンソーシアムの結成を確定するので、コンソーシアムの結成において参加する全ての組織の納得を担保することができる。
【0119】
要求処理部11,21は、第1コンソーシアムと第2コンソーシアムを含む複数のコンソーシアムについて参加希望者組織を募っているとき、第1コンソーシアムの作成を申請した契約者組織が第2コンソーシアムへの参加を希望したら、第1コンソーシアムに参加を希望していた契約者組織に対して、第2コンソーシアムへの招待を送るか、あるいは第2コンソーシアムへの参加を希望した状態としてもよい。
【0120】
この構成により、複数のコンソーシアムの作成が同時に起こったときに、それらを併合したコンソーシアムを作成することができる。
【0121】
参加希望者組織にそれぞれに重み付けされたスコアが設定され、上記合意条件は、コンソーシアムの結成を承認した参加希望者組織のスコアの合計値が所定の閾値を超えるという条件であり、要求処理部11,21は、コンソーシアムの結成に対する承認の意思を知得し、承認の意思を示した参加希望者組織のスコアの合計値を算出し、該合計値を前記閾値と比較することにより、コンソーシアムの結成を確定するか否か決定してもよい。
【0122】
この構成により、参加希望者組織の重み付けしたスコアの合計値に基づいてコンソーシアムの結成を確定するので、例えば、コンソーシアムへの貢献の大きさが異なる場合など、参加する各組織の納得と各組織の重みづけとを考慮してコンソーシアムの結成を確定させることができる。合意条件を緩和することにより、全員の承認ではない条件でのコンソーシアムの結成を可能にする。
【0123】
管理用ブロックチェーン(例えば台帳テーブル11,21)の台帳情報は、全ての契約者組織のそれぞれの情報をレコードとして含み、要求処理部11,21は、各契約者組織が所属しているコンソーシアムの情報を台帳情報の該契約者組織のレコードに含めて記録してよい。
【0124】
この構成により、コンソーシアムの管理情報をブロックチェーンにより記録し共有することができる。
【0125】
要求処理部11,21は、コンソーシアムの結成を確定するとき、該コンソーシアムおよび該参加者組織の情報を管理用ブロックチェーン(例えば台帳テーブル11,21)に台帳情報として記録してよい。
【0126】
上述した実施形態は説明のための例示であり、本発明の範囲をそれらの実施形態に限定されることはない。当業者は、本発明の範囲を逸脱することなしに、他の様々な態様で本発明を実施することができる。