JP2020060821A - 組織管理支援システム、組織管理支援方法、および、組織管理支援装置 - Google Patents

Abstract

【課題】コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上で効率的に実行可能とする。【解決手段】組織管理支援システム１００の分散台帳ノード２０００において、特定組織のノードから、ビジネスネットワークへの新規参加のリクエストを受信した場合、当該ビジネスネットワークへの参加可否について、分散台帳システム上の他組織のノードに判定を依頼する依頼部２１５００と、少なくとも上述の他組織のノードによる判定結果を集計し、当該集計の結果に基づいて参加可否を最終判定し、当該最終判定の結果を特定組織のノードに回答する処理を実行する管理部２１４００を含む構成とする。【選択図】図１Ａ

Description

本発明は、組織管理支援システム、組織管理支援方法、および、組織管理支援装置に関する。

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

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

このようなＢＣを用いた分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融や製造業等、幅広い分野での応用が検討されている。

分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも、複数の主体間で情報共有や取引を行うことができる（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）。

なお、特定の複数または一つの団体・人により許可されたコンピュータのみが取引の承認者となるブロックチェーンまたは分散台帳を「コンソーシアム型」と呼ぶ。このコンソーシアム型では、承認者を選ぶ管理主体が存在するため、それだけ取引承認のスピードを早められるメリットがある。そのため分散台帳技術を、特定業界のコンソーシアム内で利用する場合、一般的にコンソーシアム型の分散台帳基盤が用いられる。

また、一部の分散台帳基盤においては、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で取引データだけでなく取引条件を記載したロジックも管理できる。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。

非特許文献１には、ＳＣの実行機能を有する分散台帳基盤に関する技術について開示されている。こうした分散台帳基盤では、分散台帳基盤を構成するノード間で所定の合意水準での合意形成を行いながらトランザクション（以下、ＴＸとも称する）を受け入れ、各ノードでＴＸを実行し、ＴＸの結果を保持することにより、複数ノード上で情報（台帳）を共有する。また、ＴＸに対して予め決めたロジックを実行するＳＣ実行機能を備える。
一方、コンソーシアム型ＢＣを組織間横断業務に用いることで、ビジネスプロセスの効率化を図る試みもなされている。

例えば、ＢＣを用いた分散台帳技術をサプライチェーン管理分野に応用し、事業者間での売買レコードを台帳上に記録し、必要に応じて当該レコードをつなぎ合わせることによ
り、事業者間での商品の流れをトレースする試みもなされている。

この場合、全ての事業者の出入荷や製造といった履歴情報を格納した台帳が、事業者間で共有されることになる。この状況は、各事業者の機密保持の観点上必ずしも好ましくないため、所定の取引関係がある組織同士のみで台帳を共有するケースも想定される。

そこで、非特許文献１にはそうしたケースに対応して、分散台帳を論理分割する「Ｃｈａｎｎｅｌ」と称する概念が出現している。以下、このＣｈａｎｎｅｌにて論理分割された分散台帳を、サブ台帳と呼ぶ。

この場合の分散台帳基盤は、全組織が参加するひとつの分散台帳基盤でありながらも、内部的には複数の分散台帳基盤に論理分割された構成となっている。以下、この論理分割された分散台帳基盤に属するノードの集合を「サブグループ」と呼ぶ。

上述のサブグループに属するノードは、当該サブグループ内のノードのみで所定のサブ台帳を共有すると共に、ＴＸ実行の際はサブシステム毎にインストールされたＳＣを実行し、サブ台帳のデータを更新する。

"Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ"， ［ｏｎｌｉｎｅ］、［平成３０年６月３０日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ−ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞

上述のようなコンソーシアム型ＢＣに対し、コンソーシアム外の組織Ａから参加リクエストが寄せられたとする。ところが現状では、そのコンソーシアムの既存組織間で合意形成の上、当該組織Ａの参加可否を決定する明確な仕組みが存在していない。

コンソーシアム外から見た場合、当該コンソーシアムにおける組織の構成や役割（誰が追加組織や対象組織の信頼度評価を実行するか）は不明であって、上述のように参加リクエストを行うにしても、コンソーシアムにおける誰に対し参加リクエストを行えば良いか判然としないという課題が存在する。

また、上述のサブグループに属する特定業務の関係者のみでサブ台帳を共有するケースにおいて、サブグループに新規組織が参加しようとする場合も、同様の課題が存在する。

そこで本発明の目的は、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上で効率的に実行可能とする技術を提供することにある。

上記課題を解決する本発明の組織管理支援システムは、分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードが、特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する依頼部と、少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理を実行する管理部と、を備えるものであることを特徴とする。

また、本発明の組織管理支援方法は、分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードが、特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する処理と、少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理と、を実行することを特徴とする。

また、本発明の組織管理支援装置は、分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードであって、特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する依頼部と、少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理を実行する管理部と、を備えることを特徴とする。

本発明によれば、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上で効率的に実行可能となる。

実施例１における組織管理支援システムの構成例を示す図である。 実施例１における分散台帳ノード（組織管理支援装置）の構成例を示す図である。 実施例１における分散台帳ノードの分散台帳が含むブロックチェーンの構成例を示す図である。 実施例１における分散台帳ノードの分散台帳が含むステート情報の構成例を示す図である。 実施例１におけるメンバー管理ノードが含むメンバー管理表の構成例を示す図である。 実施例１におけるメンバー管理ノードが含む組織構成管理表の構成例を示す図である。 実施例１におけるメンバー管理ノードが実行するメンバー新規登録処理の全体フロー例を示すフローチャートである。 実施例１における分散台帳ノードが実行するトランザクション実行処理の全体フロー例を示すフローチャートである。 実施例１における分散台帳ノードが実行するサブグループ参加ノード追加処理の全体フロー例を示すフローチャートである。 実施例１における分散台帳ノードが実行するノード追加可否判定依頼処理の全体フロー例を示すフローチャートである。 実施例１における分散台帳ノードが実行するノード追加可否判定処理の全体フロー例を示すフローチャートである。 実施例１における計算機システムを構成するノードの構成例を示す概念図である。 実施例１における計算機システムを構成するノードが実行するサブグループ参加ノード追加処理の例を示す概念図である。 実施例１における分散台帳ノードの分散台帳が含むブロックチェーンの構成例を示す図である。 実施例１における分散台帳ノードの分散台帳が含むステート情報の構成例を示す図である。 実施例２において分散台帳ノードが実行するサブグループ参加ノード追加処理の全体フロー例を示すフローチャートである。 実施例２において分散台帳ノードが実行するノード追加可否判定依頼処理の全体フロー例を示すフローチャートである。 実施例２において分散台帳ノードが実行するコンソーシアムへのノード追加可否判定依頼処理の全体フロー例を示すフローチャートである。 実施例２において分散台帳ノードが実行するノード追加可否判定処理の全体フロー例を示すフローチャートである。 実施例２において分散台帳ノードが含むコミュニティへの新規ノード追加可否確認画面の例を示す図である。 実施例２において計算機システムを構成するノードの構成例を示す概念図である。 実施例２において計算機システムを構成するノードが実行するサブグループ参加ノード追加処理の例を示す概念図である。 実施例２において計算機システムを構成するノードが実行するサブグループ参加ノード追加処理の例を示す概念図である。 実施例２において計算機システムを構成するノードの構成例を示す概念図である。 実施例２において計算機システムを構成するノードが実行するサブグループ参加ノード追加処理の例を示す概念図である。 実施例２における計算機システムの構成例を示す図である。 実施例２において分散台帳ノードの分散台帳が含むステート情報の構成例を示す図である。 実施例２における計算機システムの構成例を示す図である。

−−−実施例１−−−

図１Ａは、実施例１における組織管理支援システムの構成および当該組織管理支援システムに接続されるノードの構成を示す。また、図１Ｂは、実施例１における組織管理支援装置たる分散台帳ノード２００００の構成例を示す。また、図２から図４は各ノードに具備される情報を示す。

実施例１における組織管理支援システム１００は、１台以上のクライアントノード１００００、１台以上の分散台帳ノード２００００、および、１台以上のメンバー管理ノード３００００によって構成される。これらの機器は、物理的な通信回線を通してネットワーク４００００に接続される。

また本実施例では、分散台帳ノード２００００が複数台存在し、コンソーシアムを構成する複数の組織（例えば、複数の事業者／複数の組織／複数のベンダ）によって分散台帳ノードがそれぞれ管理されることを想定する。
同様に、クライアントノード１００００も複数台存在し、複数の組織がそれぞれ別のクライアントノードを利用することを想定する。

また、メンバー管理ノード３００００も複数台存在してよく、複数のメンバー管理ノードが同じ情報を共有しつつ並存することで、ノードでの障害発生時における冗長性を担保してもよい。

あるいは、コンソーシアム配下に１つまたは複数の組織からなるグループを設け、そのグループ毎に異なるメンバー管理ノードを使い分ける形態を取っても良い。メンバー管理
ノードが複数存在する場合、各分散台帳ノードはどのメンバー管理ノードにアクセスするかを設定情報として持っているものとする。また、メンバー管理ノードの機能およびデータを分散台帳ノード中に保持しても良い。

なお、クライアントノード１００００、分散台帳ノード２００００、およびメンバー管理ノード３００００の物理的な実体は、図１Ｂの分散台帳２００００の構成で例示するように、不揮発性メモリで構成された記憶部２０１、この記憶部２０１で保持するプログラム２０２を実行して必要な機能を実装するＣＰＵ等の演算部２０３、演算時に必要となる一次記憶領域を実装するメモリ２０４、および、ネットワーク４００００にアクセスして必要な通信処理を担う通信部２０５を、データバスで接続した一般的な計算機である。

また、図１Ａで示すクライアントノード１００００は、分散台帳システムにおけるビジネスネットワークに対し、所定業務の処理結果たるトランザクション（以後、ＴＸ）を発行するトランザクション発行部１１０００、および、業務アプリ１２０００によって構成される。

このうち業務アプリ１２０００は、ユーザより部品の受発注もしくは出荷に関する情報の入力を受けるアプリケーションである。この業務アプリ１２０００は、トランザクション発行部１１０００を介してＴＸを発行し、上述の部品の取引履歴を分散台帳ノード２００００に対して送信する。

なお、上述のＴＸには発行者情報を付与するが、この発行者情報としては、組織と紐つける形でメンバー管理ノード３００００より予め付与された組織ＩＤとノードＩＤ、およびメンバー管理ノード３００００によってノード毎に発行された認証情報（秘密鍵）を利用する。いずれにしても、こうしたＴＸの取扱自体は、既存の分散台帳システムと同様である。

また、分散台帳ノード２００００は、コンセンサス管理部２１１００、スマートコントラクト実行／管理部２１２００（以下、ＳＣ実行／管理部とも称する）、トランザクション管理部２１３００、サブグループ管理部２１４００、ノード追加可否判定依頼部２１５００、ノード追加可否判定部２１６００、ノード追加可否判定依頼ロジック２３０００、コンソ追加可否判定依頼ロジック２３１００、ノード追加可否判定ロジック２４０００、コンソ追加可否判定ロジック２４１００、分散台帳２５０００、および、サブ台帳２５１００によって構成される。

このうちノード追加可否判定依頼ロジック２３０００とノード追加可否判定ロジック２４０００は、サブグループ毎に定義され、当該サブグループに属するノード間で同じロジックが共有される。

なお、これらのロジックは、サブグループ上のスマートコントラクト（以後、ＳＣ）として定義されても良い。また、コンソーシアム全体で同じロジックを用いても良い。

また、コンソ追加可否判定依頼ロジック２３１００とコンソ追加可否判定ロジック２４１００は、コンソーシアム全体で１つのロジックが定義される。ノード追加可否判定依頼ロジック２３１００とノード追加可否判定ロジック２４１００については実施例２で説明する。

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

また、分散台帳ノード２００００のトランザクション管理部２１３００は、クライアントノード１００００等の各ノードからの要求に対して、ＴＸを受け付けたり、ＴＸの履歴情報を取得・閲覧したりする機能／インタフェースを提供する。

分散台帳２５０００およびサブ台帳２５１００ではそれぞれ、業務に関するスマートコントラクト２６０００、２６１００とＳＣによるＴＸ結果とを格納・管理する。

ＴＸ結果のデータ構造として、本実施例では、ＴＸの履歴をブロックチェーン２７０００、２７１００として、ＴＸの実行結果に基づくステート情報２８０００、２８１００をテーブル形式で保持することを想定する。
一方、メンバー管理ノード３００００は、メンバー管理部３１０００、メンバー管理表３２０００、組織構成管理表３２１００によって構成される。

このうちメンバー管理部３１０００は、コンソーシアムに参加するメンバーすなわち組織に関して、新規登録や認証機能を提供する。併せて、各組織がどのサブグループに所属しているかを管理する。なお、本実施例の分散台帳システムでは、秘密鍵と公開鍵のペアを用いて、参加組織の認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。各組織の鍵情報は、メンバー管理表３２０００上に格納・管理される。

また、分散台帳ノード２００００のトランザクション管理部２１３００は、ＴＸを受け付けた際に、適宜、メンバー管理ノード３００００のメンバー管理部３１０００の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認する。
図２および図３は、分散台帳ノード２００００の具備する分散台帳２５０００に格納するデータ構造の一例である。

図２は、分散台帳２５０００上で管理するデータ構造の一つであるブロックチェーン２７０００の例である。ＢＣを用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。

こうした管理によれば、前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変わるため、改ざんを困難にすることができる。なお、本実施例では説明をシンプルにするために、１つのＴＸにつき、１ブロックとするが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。

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

上述のブロックのうちブロック２７０１０は、ＳＣのデプロイＴＸを格納したブロックの一例である。本実施例のデプロイＴＸ２７３００は、コントラクトを一意に識別するコントラクトＩＤと、コントラクトのロジック（例えば実行可能なバイナリ）を含む。また、コントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。

この例では、「部品受発注」というＩＤを持つＳＣの関数名として「受発注」「出荷」「履歴参照」の３つが定義されており、各関数のロジックが定義されている。また、本ＳＣと紐付けられたサブグループのＩＤと、当該サブグループに属するノードのＩＤを含む。

さらに、このデプロイＴＸの発行元のＩＤと、データに改ざんが無いことを検証するために用いる電子署名を含む。この電子署名はメンバー管理ノード３００００のメンバー管理部３１０００が発行した秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。また、ＴＸの固有の識別子であるＩＤを含む。

また、ブロック２７０２０はＳＣの実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸ２７４００は、呼び出し対象となるコントラクトのコントラクトＩＤ、呼び出し対象となるコントラクトの関数名と入力する引数の情報を含む。

この例では、「部品受発注」というＩＤを持つＳＣの関数「受発注」を呼び出しており、その引数は発注組織ＩＤ、受注組織ＩＤ、伝票番号、型番、発注日、納期の６つであり、その値はそれぞれ”Ｏｒｇ１”、”Ｏｒｇ３”、”１０１”、”ＭＮＦ−１”、”２０１８／５／１”、”２０１８／５／２０”である。

さらに、このＴＸの発行元のＩＤと、データに改ざんが無いことを検証するために用いる電子署名を含む。なお、発行元だけでなく、合意形成に関わったノードの情報も管理／保持してもよい。また、ＴＸの固有の識別子であるＩＤを含む。

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

本実施例でも最新のステート情報を保持することを想定する。本実施例では、コントラクトが持つ関数毎にステートのデータ領域が用意されることとする。ステート情報はコントラクトの識別子であるＩＤ２８０１０と、そのコントラクトの実体２８０２０と、コントラクトに紐付けられたサブグループの識別子２８３００を保持する。

これにより、ＳＣ実行／管理部２１２００は、コントラクトＩＤと関数名をキーにして、コントラクトの実体を取得して実行することができる。また、ステート情報２８０００はＳＣの実行結果を保持するための内部テーブル２８０４０を備える。

ＴＸが実行されるか、当該ＳＣに紐付けられたサブグループへの参加ノードが増える度にこの内部テーブル２８０４０の内容を更新する。ステート情報２８０００の内部テーブル２８０４０は、図３のステート情報２８０００における構成要素２８０４０〜２８０５０に示すとおり「取引履歴」「参加ノード」の各テーブルに分かれており、ＴＸの引数で指定された情報を随時上書きする。
また図４Ａは、メンバー管理ノード３００００の具備するメンバー管理表３２０００の構成例を示す図である。

このメンバー管理表３２０００は、コンソーシアムに参加する組織の分散台帳基盤における識別子を登録するフィールド３２０１０と、当該組織の名前を登録するフィールド３２０２０と、当該組織がメンバー管理部３１０００を通じて認証を行う場合の公開鍵を登録するフィールド３２０３０と、を構成項目として含んでいる。
また図４Ｂは、メンバー管理ノード３００００の具備する組織構成管理表３２１００の構成例を示す図である。

この組織構成管理表３２１００は、コンソーシアムに参加する組織の分散台帳基盤における識別子を登録するフィールド３２１１０と、当該組織に属するノードの識別子を登録するフィールド３２１２０と、当該ノードが属するサブグループの識別子を登録するフィールド３２１３０と、当該ノードが属するサブグループにおける代表ノードであるか否かを登録するフィールド３２１４０と、を構成項目として含んでいる。代表ノードについては実施例２にて述べる。
以降では、実施例１における処理のフローについて説明する。図５は、コンソーシアムに参加するメンバーの新規登録処理の例を示すフローチャートである。

この場合、メンバー管理ノード３００００のメンバー管理部３１０００は、コンソーシアム未参加の組織が持つクライアントノードからメンバー登録要求を受け付ける（ステップ５１０１０）。また、メンバー管理部３１０００はメンバー登録要求を受けると、参加要求のあった組織を一意に識別するメンバーＩＤを、所定ルールにて付与するものとする。

次にメンバー管理部３１０００は、秘密鍵と公開鍵の組を生成し、これに対して上述のメンバーＩＤを紐付けてメンバー管理表３２０００に登録する（ステップ５１０２０）。
次に、メンバー管理部３１０００は、新規登録対象となるメンバーＩＤと上述の公開鍵を他のメンバー管理ノードにブロードキャストする（ステップ５１０３０）。ここでブロードキャストされたメンバーＩＤと公開鍵の情報は、各メンバー管理ノード上のメンバー管理表３２０００で保管する。

さらに、メンバー管理部３１０００は、メンバー登録要求を行った組織のクライアントノードに対し、ステップ５１０２０で生成した秘密鍵を返す（ステップ５１０４０）。こうして秘密鍵を受け取った組織のクライアントノードは、自身の秘密鍵として保管する。

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

具体的には、例えば、分散台帳ノード２００００は事前発行された秘密鍵で電子署名したＴＸを発行し、当該ＴＸを検証する側はメンバー管理ノード３００００上の公開鍵を用いて電子署名を検証することで、本人確認を実現できる。なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法については、公知または周知の技術を適用すれば良いので、本実施例１では詳述しない。

なお、本実施例では複数のメンバー管理ノード３００００が、メンバーＩＤと公開鍵の情報を共有することを前提として記載するが、メンバー管理ノードは単一であっても良い。
続いて図６は、ＴＸ実行処理、すなわち、ＳＣのデプロイおよび実行の例を示すフローチャートである。

この場合、分散台帳ノード２００００のトランザクション管理部２１３００は、クライアントノード等のＴＸ発行元からＴＸを受け取る（ステップ５２０１０）と、ＴＸにＩＤを付与した上で、コンセンサス管理部２１１００に渡す。

コンセンサス管理部２１１００は、他の分散台帳ノードとの間で、受け取ったＴＸを実行してよいか、すなわちブロックとしてＢＣに追加してよいかの合意形成処理を行う（ス
テップ５２０２０）。

具体的な合意形成処理方式としては、公知または周知の技術を適用すれば良い。具体的には、例えば、Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ（ＰＢＦＴ）と呼ばれるアルゴリズム等を採用することが考えられる。ＰＢＦＴは合意形成に参加するすべてのノードの間で一定（３分の２）以上のノードによる合意を条件とするアルゴリズムである。

ＰＢＦＴをベースとした合意形成を簡単に説明すると、分散台帳ノードはまず受け取ったＴＸをネットワークに参加するすべての分散台帳ノードに対してブロードキャストし、各分散台帳ノードでＴＸに対する署名検証を行って改ざんがされていないことやＴＸの内容の正当性を確認し、その確認結果を他の分散台帳ノードに対してブロードキャストする。

一定数以上の分散台帳ノードによる確認が取れた場合にＴＸの承認準備が完了したことを他の分散台帳ノードに対してブロードキャストする。そして、一定数以上の分散台帳ノードによる承認準備完了が確認できたことをもって合意形成が完了する。

上述のように合意形成が完了したら、トランザクション管理部２１３００は、ＳＣ実行／管理部２２０００を介して、ＴＸを分散台帳２５０００もしくはサブ台帳２５１００に登録する（ステップ５２０３０）。以下、分散台帳２５０００にＴＸの内容を反映するものとして説明する。

ＴＸの内容がＳＣのデプロイに関する場合、コントラクトＩＤやコントラクト実体を分散台帳上のステート情報２８０００として登録し、ブロックチェーン２７０００の末尾にこのＴＸを含むブロックを追加する。

ＴＸの内容がＳＣに定義された関数の実行に関する場合、ＴＸ内で指定されたコントラクトＩＤを持つＳＣに対して、ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳２５０００の内容を更新する。

すなわち、実行結果に基づいて、本コントラクトに関するステート情報２８０００を更新し、ブロックチェーン２７０００の末尾のブロックとして実行ＴＸを追加する。

この際、同じ台帳を共有する他の分散台帳ノードにおいても同様にブロックの追加を行う。ＴＸの内容がＳＣの設定変更に関する場合、ステート情報２８０００に定義された本コントラクトに関する設定情報を更新するとともに、ブロックチェーン２７０００の末尾のブロックとして実行ＴＸを追加する。
最後に、トランザクション管理部２１３００は、デプロイＴＸの実行結果をＴＸ発行元に返す（ステップ５２０４０）。

以上、本実施例では分散台帳２５０００を更新する場合について述べたが、サブ台帳２５１００を更新する場合についても同様の方法によって良い。その場合、合意形成処理はＳＣに定義されたサブグループ参加ノードの間でのみ実行する。

なお、本実施例ではステップ５２０３０におけるブロードキャストの処理を分散台帳ノード２００００が実施しているが、これをブロードキャストの処理に特化した独立したノードが行っても構わない。また、合意形成の手段はＰＢＦＴ以外の方法によっても良い。

続いて図７は、分散台帳ノード２００００が備えるサブグループ管理部２１４００の内
部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

サブグループ管理部２１４００は、自組織とは異なる組織に属するノードより、自組織が所属するサブグループへの参加要求を受け付けたとする（ステップ５３０１０）。

その場合、サブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２８１００に定義された、所属サブグループへの参加ノードデータを参照し、参加ノードの一覧を参照する（ステップ５３０２０）。参加要求元ノードが既に前記参加ノード一覧に存在する場合（ステップ５３０３０：Ｙｅｓ）、その旨を参加要求元ノードに回答し、処理を終了する。

一方、参加要求元ノードが前記参加ノード一覧に存在しない場合（ステップ５３０３０：Ｎｏ）、サブグループ管理部２１４００はノード追加可否判定依頼部２１５００に対し、参加要求元ノードのサブグループ追加可否判定を依頼する（ステップ５３０４０）。

その結果、ノード追加可否判定依頼部２１５００より追加否の判定が通知された場合（ステップ５３０５０：ＮＧ）、サブグループ管理部２１４００は、その旨を参加要求元ノードに回答し、処理を終了する。

一方、追加可の判定が通知された場合（ステップ５３０５０：ＯＫ）、サブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２８１００を更新し、参加要求元ノードをサブグループ参加ノードとして追加する（ステップ５３０６０）。

次に、サブグループ管理部２１４００は、メンバー管理ノード３００００のメンバー管理部３１０００に対し、組織構成管理表３２１００を更新して、参加要求元ノードをサブグループ参加ノードとして追加するよう指示する（ステップ５３０７０）。
最後に、サブグループ管理部２１４００は、サブグループ追加が完了した旨を参加要求元ノードに回答し（ステップ５３０８０）、処理を終了する。

なお、上述のフローのうちステップ５３０４０の詳細について図８のフロー例で示す。図８は、分散台帳ノード２００００が備えるノード追加可否判定依頼部２１５００が、Ｇｒｏｕｐ１内のノード間で共有されたノード追加可否判定依頼ロジック２３０００に基づいて実行する内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

この場合、まず、ノード追加可否判定依頼部２１５００は、サブ台帳２５１００上のステート情報２８１００に定義された、所属サブグループへの参加ノードデータを参照し、参加ノードの一覧を参照する（ステップ５４０１０）。

ノード追加可否判定依頼部２１５００は、上述の参加ノードの一覧に定義されたノードに対し、以下の処理を繰り返す。まず、当該ノードのノード追加可否判定部２１６００に対し、参加要求元ノードのサブグループへの参加可否を問い合わせる（ステップ５４０２０）。要求を受けたノードは、ノード追加可否判定処理を実行する（ステップ５４０３０）。ノード追加可否判定を依頼したノードは、問い合わせ先ノードより参加可否判定結果を受信する（ステップ５４０４０）。以降、ステップ５４０２０〜ステップ５４０４０の処理を全てのノードについて繰り返す。

次にノード追加可否判定依頼部２１５００は、問い合わせ先ノードからの回答を集計し、参加要求元ノードについてサブグループ参加可と回答したノードの割合が全体の３分の２を超えているか確認する（ステップ５４０５０）。確認の結果、参加可と回答したノー
ドの割合が全体の３分の２を超えていれば（ステップ５４０６０：Ｙｅｓ）、ノード追加可否判定依頼部２１５００は、参加要求元ノードの参加可、一方、超えていなければ（ステップ５４０６０：Ｎｏ）、ノード追加可否判定依頼部２１５００は、参加否とそれぞれ回答する（ステップ５４０６０）。

なお、上述のフローのうちステップ５４０３０の詳細について図９のフロー例で示す。図９は、分散台帳ノード２００００が備えるノード追加可否判定部２１６００が、Ｇｒｏｕｐ１内のノード間で共有されたノード追加可否判定ロジック２４０００に基づいて実行する内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

まず、ノード追加可否判定部２１６００は、サブ台帳２５１００上のステート情報２８１００に定義された、取引履歴データを参照し、参加要求元ノードの過去の取引の一覧を参照する（ステップ５５０１０）。
ノード追加可否判定部２１６００は、上述の過去の取引の一覧を参照し、過去の取引件数が１００件を超えているかを確認する（ステップ５５０２０）。

この結果、過去の取引件数が１００件を超えていた場合（ステップ５５０２０：ＹＥＳ）、ノード追加可否判定部２１６００は、上述の過去の取引の一覧を確認し、過去の納入遅延日数の平均値を算出する（ステップ５５０３０）。

この確認の結果、納入遅延日数の平均値が７日以内であれば（ステップ５５０４０：ＹＥＳ）、ノード追加可否判定部２１６００は、参加要求元ノードの参加可と回答し、処理を終了する。

一方、過去の取引件数が１００件を超えていないか（ステップ５５０２０：ＮＯ）、または、納入遅延日数の平均値が７日を超えていれば（ステップ５５０４０：ＮＯ）、ノード追加可否判定部２１６００は、参加否と回答し、処理を終了する。

以下に、図１０および図１１の模式図を用いて、実施例１の処理がどのようにサブグループ外のノードからの参加要求を承認し、参加手続きを実施するかを示す。

図１０は、本実施例においてコンソーシアムに参加する事業者を示した模式図である。コンソーシアムは、複数の参加組織から構成されており、Ｏｒｇ１〜Ｏｒｇ５が存在する。
各組織は、それぞれ１つもしくは複数の分散台帳ノードを持ち、例えば、組織Ｏｒｇ１は分散台帳ノードＮｏｄｅ１、Ｎｏｄｅ２を持つ。

また、コンソーシアム内には複数のサブグループが存在し、Ｇｒｏｕｐ１〜Ｇｒｏｕｐ３が存在する。各サブグループにはそれぞれ複数の分散台帳ノードが所属し、例えば、サブグループＧｒｏｕｐ１には組織Ｏｒｇ１の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ２の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ３の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ４の分散台帳ノードＮｏｄｅ１が属している。

図１１は、図１Ａ〜図９で説明した、各ノードが持つ情報のやり取りの過程を示した模式図である。以下、組織Ｏｒｇ５のＮｏｄｅ１がＧｒｏｕｐ１への参加を希望し、Ｇｒｏｕｐ１内の任意のグループ、例えば組織Ｏｒｇ１のＮｏｄｅ１に対し参加要求を行って承認されるまでの過程を説明する。

まずＯｒｇ５／Ｎｏｄｅ１のサブグループ管理部２１４００は、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００に対し、Ｇｒｏｕｐ１への参加要求を行う。すると、Ｏ
ｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２６１００に定義された、Ｇｒｏｕｐ１の参加ノードデータを参照し、Ｏｒｇ５／Ｎｏｄｅ１が上述の参加ノード一覧に存在しないことを確認する。

次に、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、ノード追加可否判定依頼部２１５００に対し、参加要求元ノードのサブグループ追加可否判定を依頼する。

Ｏｒｇ１／Ｎｏｄｅ１のノード追加可否判定依頼部２１５００は、サブ台帳２５１００上のステート情報２８１００に定義された、所属サブグループへの参加ノードデータを参照し、参加ノードの一覧を参照する。そして、上述の参加ノード一覧に定義されたＯｒｇ１／Ｎｏｄｅ１、Ｏｒｇ２／Ｎｏｄｅ１、Ｏｒｇ３／Ｎｏｄｅ１、Ｏｒｇ４／Ｎｏｄｅ１の各ノードに対し、Ｏｒｇ５／Ｎｏｄｅ１のサブグループへの参加可否を問い合わせる。

要求を受けた各ノードのノード追加可否判定部２１６００は、ノード追加可否判定処理を実行する。まず、サブ台帳２５１００上のステート情報２８１００に定義された、取引履歴データを参照し、参加要求元ノードの過去の取引の一覧を参照する。
その結果、過去の取引件数が１００件を超えていた場合、さらに上述の過去の取引の一覧を確認し、過去の納入遅延日数の平均値を算出する。
確認の結果、納入遅延日数の平均値が７日以内であった場合、Ｏｒｇ５／Ｎｏｄｅ１のＧｒｏｕｐ１への参加可と回答する。

ノード追加可否判定を依頼したＯｒｇ１／Ｎｏｄｅ１のノード追加可否判定依頼部２１５００は、Ｏｒｇ１／Ｎｏｄｅ１、Ｏｒｇ２／Ｎｏｄｅ１、Ｏｒｇ３／Ｎｏｄｅ１、Ｏｒｇ４／Ｎｏｄｅ１の各ノードより参加可否判定結果を受信する。

次にノード追加可否判定依頼部２１５００は、問い合わせ先ノードからの回答を集計し、Ｏｒｇ５／Ｎｏｄｅ１のＧｒｏｕｐ１への参加可と回答したノードの割合が全体の３分の２を超えているか確認する。

確認の結果、参加可と回答したノードの割合が全体の３分の２を超えていれば、サブグループ管理部２１４００に対し、Ｏｒｇ５／Ｎｏｄｅ１のＧｒｏｕｐ１への参加可と回答する。

次にＯｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２８１００を更新し、Ｏｒｇ５／Ｎｏｄｅ１をＧｒｏｕｐ１の参加ノードとして追加する。

次に、メンバー管理ノード３００００のメンバー管理部３１０００に対し、メンバー管理表３２０００を更新して、Ｏｒｇ５／Ｎｏｄｅ１をＧｒｏｕｐ１参加ノードとして追加するよう指示する。最後に、サブグループ追加が完了した旨をＯｒｇ５／Ｎｏｄｅ１に回答し、処理を終了する。

図１２Ａおよび図１２Ｂはそれぞれ、分散台帳２５０００上で管理するブロックチェーン２７０００およびステート情報２８０００の例である。図１２Ａにおけるブロック２７０１０〜２７０５０は一連のブロックの連なりであり、各ブロックは、それぞれ部品受発注ＳＣのデプロイ、実行、設定変更いずれかのＴＸ情報を含む。

このうちブロック２７０５０は部品受発注ＳＣの設定変更ＴＸを格納したブロックの一例である。本実施例の部品受発注ＳＣではデプロイＴＸにサブグループの参加ノードが定義されているが、設定変更ＴＸを実行することで、図１２Ｂに記載したとおり、ステート
情報２８０００の内部テーブルに参加ノードとしてＯｒｇ５／Ｎｏｄｅ１が追加される。

以上で示したとおり、本発明を用いることで、サブグループへの参加組織追加の際、当該サブグループに参加する組織間で合意形成の上、組織の新規参加可否を決定することができる。また、コンソ外の組織が新規にサブグループに新規参加しようとする場合、当該コンソーシアムもしくはサブグループの任意の組織にリクエストすれば良い。
−−−実施例２−−−

実施例２では、実施例１にて実施したノード追加可否判定依頼処理を、メンバー管理ノード３００００上に保持しているメンバー管理表３２０００を参照しつつ実施する方式について説明する。
図１３は、分散台帳ノード２００００が備えるサブグループ管理部２１４００の内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

サブグループ管理部２１４００は、自組織とは異なる組織に属するノードより、自組織が所属するサブグループへの参加要求を受け付け（ステップ５６０１０）、サブ台帳２５１００上のステート情報２８１００に定義された、所属サブグループへの参加ノードデータを参照し、参加ノードの一覧を参照する（ステップ５６０２０）。

参加要求元ノードが既に前記参加ノード一覧に存在する場合（ステップ５６０３０：Ｙｅｓ）、サブグループ管理部２１４００は、その旨を参加要求元ノードに回答し、処理を終了する。

一方、参加要求元ノードが前記参加ノード一覧に存在しない場合（ステップ５６０３０：Ｎｏ）、サブグループ管理部２１４００は、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得して、参加要求元ノードが既にコンソーシアムに参加しているかどうかを確認する（ステップ５６０４０）。
参加要求元ノードが既にコンソーシアムに存在する場合（ステップ５６０５０：Ｎｏ）、サブグループ管理部２１４００は、ステップ５６０８０の処理に移る。

一方、参加要求元ノードがコンソーシアムに存在しない場合（ステップ５６０５０：Ｙｅｓ）、サブグループ管理部２１４００はノード追加可否判定依頼部２１５００に対し、参加要求元ノードのコンソーシアム追加可否判定を依頼する（ステップ５６０６０）。

その結果、ノード追加可否判定依頼部２１５００より追加否の判定が通知された場合（ステップ５６０７０：ＮＧ）、サブグループ管理部２１４００はその旨を参加要求元ノードに回答し、処理を終了する。
なお、ステップ５６０８０以降の部分は、実施例１において図７で示したステップ５３０４０以降の処理の内容と同等である。

次に、サブグループ管理部２１４００は、参加要求元ノードのサブグループ追加可否判定を依頼するノードを特定する（ステップ５６０７５）。この場合、サブグループ管理部２１４００は、参加要求元ノードが参加しようとするサブグループに自ノードが属している場合、自ノード上のノード追加可否判定依頼部２１５００に依頼を行う。一方、参加要求元ノードが参加しようとするサブグループに自ノードが属していない場合、サブグループ管理部２１４００は、メンバー管理表３２０００の情報を元に、当該サブグループに属するいずれかのノード上のノード追加可否判定依頼部２１５００に依頼を行う。この場合、メンバー管理ノード３００００など管理用のノードが、サブグループ内のどのノード上のノード追加可否判定依頼部２１５００を呼び出すかを決定しても良い。

図１４は、分散台帳ノード２００００が備えるノード追加可否判定依頼部２１５００が、Ｇｒｏｕｐ１内のノード間でノード追加可否判定依頼ロジック２３０００に基づいて実行する内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

まず、ノード追加可否判定依頼部２１５００は、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得して、参加要求のあったノードと同一のサブグループに所属するノードを特定する（ステップ５７０１０）。

また、ノード追加可否判定依頼部２１５００は、ステップ５７０１０で特定したノードに対し、ステップ５７０２０以降の処理を繰り返す。ただし、ステップ５７０２０以降の部分は、実施例１において図８で示したステップ５４０２０以降の処理の内容と同等である。

なお、ステップ５７０１０において、参加要求のあったノードと同一のサブグループに所属するノードを特定する際、ノード追加可否判定依頼部２１５００は、各サブグループの代表ノードに各グループの参加ノードを問い合わることにより、これを実現しても良い。

また、ノード追加可否判定依頼部２１５００は、ステップ５７０１０〜５７０２０において、参加要求のあったノードと同一のサブグループに所属するノードを特定し、参加要求元ノードのサブグループへの参加可否を問い合わせる際、全ノードに問い合わせるのではなく、各サブグループの代表ノードに問い合わせても良い。その場合、ノード追加可否判定依頼部２１５００は、各サブグループの代表ノードからの回答を集計し、参加要求元ノードについてサブグループ参加可と回答したノードの割合が全体の３分の２を超えているか確認する

図１５は、分散台帳ノード２００００が備えるノード追加可否判定依頼部２１５００が、コンソーシアム内のノード間で共有されたコンソ追加可否判定依頼ロジック２３１００に基づいて実行する内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

まず、ノード追加可否判定依頼部２１５００は、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得して、コンソーシアム参加組織の一覧を参照する（ステップ５８０１０）。
ノード追加可否判定依頼部２１５００は、上述の参加組織の一覧に定義された組織に対し、以下の処理を繰り返す。

まず、ノード追加可否判定依頼部２１５００は、当該組織内の１ノードを選択し、当該ノードのノード追加可否判定部２１６００に対し、参加要求元ノードのコンソーシアムへの参加可否を問い合わせる（ステップ５８０２０）。一方、問い合わせを受けたノードは、ノード追加可否判定処理を実行する（ステップ５８０３０）。ノード追加可否判定を依頼したノードは、問い合わせ先ノードより参加可否判定結果を受信する（ステップ５８０４０）。以降、ステップ５８０２０〜ステップ５８０４０の処理を全てのノードについて繰り返す。

次にノード追加可否判定依頼部２１５００は、問い合わせ先ノードからの回答を集計し、参加要求元ノードについてコンソーシアム参加可と回答したノードの割合が全体の３分の２を超えているか確認する（ステップ５８０５０）。

この確認の結果、ノード追加可否判定依頼部２１５００は、参加可と回答したノードの
割合が全体の３分の２を超えていれば（ステップ５８０６０：Ｙｅｓ）、参加要求元ノードの参加可、超えていなければ（ステップ５８０６０：Ｎｏ）、参加否とそれぞれ回答する（ステップ５８０６０）。

続いて図１６は、分散台帳ノード２００００が備えるノード追加可否判定部２１６００が、コンソーシアム内のノード間で共有されたコンソ追加可否判定ロジック２４１００に基づいて実行する内部処理の例を示すフローチャートである。具体的な内部処理を以下に示す。

まず、ノード追加可否判定部２１６００は、所定のＧＵＩ（図１７の画面７１０００）上で分散台帳ノード管理者に対し、サブグループ参加要求元の組織をコンソーシアムに新規追加してよいか確認する（ステップ５９０１０）。

この確認の結果、分散台帳ノード管理者が参加を承認すれば（ステップ５９０２０：ＹＥＳ）、ノード追加可否判定部２１６００は、参加要求元ノードの参加可と回答する。

一方、分散台帳ノード管理者が参加を承認しない場合（ステップ５９０２０：ＮＯ）、ノード追加可否判定部２１６００は、参加否と回答し（ステップ５９０２０）、処理を終了する。

図１７は、ノード追加可否判定部２１６００による表示画面の例である。この画面７１０００には、コンソーシアムへの追加対象となる組織の名前およびＩＤと、「承認」「却下」ボタンが存在する。分散台帳ノード管理者は追加対象となる組織の情報を確認し、意思に対応したボタンを押下することで、ノード追加可否判定部２１６００に対し応答できる。

続いて図１８は、本実施例においてコンソーシアムに参加する事業者を示した模式図である。コンソーシアムの各サブグループにはそれぞれ複数の分散台帳ノードが所属し、例えば、サブグループＧｒｏｕｐ１には組織Ｏｒｇ１の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ２の分散台帳ノードＮｏｄｅ１が、Ｇｒｏｕｐ２には組織Ｏｒｇ３の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ４の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ５の分散台帳ノードＮｏｄｅ２が、Ｇｒｏｕｐ３には組織Ｏｒｇ１の分散台帳ノードＮｏｄｅ２と、組織Ｏｒｇ２の分散台帳ノードＮｏｄｅ２が属している。

また図１９Ａは、図１Ａ〜図９で説明した、各ノードが持つ情報のやり取りの過程を示した模式図である。以下、組織Ｏｒｇ５のＮｏｄｅ１が組織Ｏｒｇ１のＮｏｄｅ１に対し、Ｇｒｏｕｐ１への参加を要求し承認されるまでの過程を説明する。

まずＯｒｇ５／Ｎｏｄｅ１のサブグループ管理部２１４００は、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００に対し、Ｇｒｏｕｐ１への参加要求を行う。

すると、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２８１００に定義された、Ｇｒｏｕｐ１の参加ノードデータを参照し、Ｏｒｇ５／Ｎｏｄｅ１が上述の参加ノードの一覧に存在しないことを確認する。また、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得して、参加要求元ノードが既にコンソーシアムに参加していることを確認する。

次に、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、ノード追加可否判定依頼部２１５００に対し、参加要求元ノードのサブグループ追加可否判定を依頼する。

このケースでは、参加要求元ノードが参加しようとするサブグループ（Ｇｒｏｕｐ１）に自ノードが属しているので、自ノード上のノード追加可否判定依頼部２１５００に依頼すれば良い。Ｏｒｇ４／Ｎｏｄｅ１のノード追加可否判定依頼部２１５００は、メンバー管理ノード３００００のメンバー管理部３１００００からメンバー管理表３２０００を取得し、参加要求のあったノードと同一のサブグループに所属するノードを特定する。

図１８の構成例では、該当するノードはＯｒｇ３／Ｎｏｄｅ１、Ｏｒｇ４／Ｎｏｄｅ１の各ノードである。ノード追加可否判定依頼部２１５００はこれらのノードに対し、Ｏｒｇ５／Ｎｏｄｅ１のサブグループへの参加可否を問い合わせる。以降の処理は、図１１の説明に記載した処理と同じ流れである。
一方、図１９Ｂのケースでは、組織Ｏｒｇ５のＮｏｄｅ１が組織Ｏｒｇ４のＮｏｄｅ１に対し、Ｇｒｏｕｐ１への参加を要求している。

この場合、参加要求元ノードが参加しようとするサブグループ（Ｇｒｏｕｐ１）に組織Ｏｒｇ４のＮｏｄｅ１は属していないので、Ｏｒｇ４／Ｎｏｄｅ１のサブグループ管理部２１４００は、Ｇｒｏｕｐ１に属する任意のノード（例えば、Ｏｒｇ１／Ｎｏｄｅ１）上のノード追加可否判定依頼部２１５００に対し、参加要求元ノードのサブグループ追加可否判定を依頼する。

続いて図２０は、本実施例におけるコンソーシアム参加事業者の別形態を示した模式図である。コンソーシアムの各サブグループにはそれぞれ複数の分散台帳ノード２５０００が所属し、例えば、サブグループＧｒｏｕｐ１には組織Ｏｒｇ１の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ２の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ３の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ４の分散台帳ノードＮｏｄｅ１が、Ｇｒｏｕｐ２には組織Ｏｒｇ３の分散台帳ノードＮｏｄｅ１と、組織Ｏｒｇ４の分散台帳ノードＮｏｄｅ２が、Ｇｒｏｕｐ３には組織Ｏｒｇ１の分散台帳ノードＮｏｄｅ２と、組織Ｏｒｇ２の分散台帳ノードＮｏｄｅ２が属している。

また図２１は、図１Ａ〜図９で説明した、各ノードが持つ情報のやり取りの過程を示した模式図である。以下、組織Ｏｒｇ５のＮｏｄｅ１が組織Ｏｒｇ１のＮｏｄｅ１に対し、Ｇｒｏｕｐ１への参加を要求し承認されるまでの過程を説明する。

まずＯｒｇ５／Ｎｏｄｅ１のサブグループ管理部２１４００は、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００に対し、Ｇｒｏｕｐ１への参加要求を行う。

すると、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、サブ台帳２５１００上のステート情報２８１００に定義された、Ｇｒｏｕｐ１の参加ノードデータを参照し、Ｏｒｇ５／Ｎｏｄｅ１が上述の参加ノードの一覧に存在しないことを確認する。

また、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得して、参加要求元ノードがコンソーシアムに参加していないことを確認する。

次に、Ｏｒｇ１／Ｎｏｄｅ１のサブグループ管理部２１４００は、ノード追加可否判定依頼部２１５００に対し、参加要求元ノードのコンソーシアム追加可否判定を依頼する。

Ｏｒｇ１／Ｎｏｄｅ１のノード追加可否判定依頼部２１５００は、メンバー管理ノード３００００のメンバー管理部３１０００からメンバー管理表３２０００を取得し、コンソーシアム内の全ノードを特定する。ノード追加可否判定依頼部２１５００は各組織から１ノードを選択し、当該ノードに対し、Ｏｒｇ５のコンソーシアムへの参加可否を問い合わ
せる。具体的には、Ｏｒｇ１／Ｎｏｄｅ１、Ｏｒｇ２／Ｎｏｄｅ１、Ｏｒｇ３／Ｎｏｄｅ１、Ｏｒｇ４／Ｎｏｄｅ１の各ノードに対し、Ｏｒｇ５のコンソーシアムへの参加可否を問い合わせる。

問い合わせを受けた各ノードのノード追加可否判定部２１５００は、ノード追加可否判定処理を実行する。具体的には分散台帳ノード管理者がＯｒｇ５のコンソーシアムへの参加を承認した場合、参加可と回答する。

ノード追加可否判定を依頼したＯｒｇ１／Ｎｏｄｅ１のノード追加可否判定依頼部２１５００は、Ｏｒｇ１／Ｎｏｄｅ１、Ｏｒｇ２／Ｎｏｄｅ１、Ｏｒｇ３／Ｎｏｄｅ１、Ｏｒｇ４／Ｎｏｄｅ１の各ノードより参加可否判定結果を受信する。

次にノード追加可否判定依頼部２１５００は、問い合わせ先ノードからの回答を集計し、Ｏｒｇ５のコンソーシアムへの参加可と回答したノードの割合が全体の３分の２を超えているか確認する。確認の結果、参加可と回答したノードの割合が全体の３分の２を超えていれば、サブグループ管理部２１４００に対し、Ｏｒｇ５のコンソーシアムへの参加可と回答する。以降の処理は、図１１の説明に記載した処理と同じである。

以上で示したとおり、実施例２に記載の発明を用いることで、コンソーシアムやサブグループへの参加組織追加の際、当該組織の契約完遂能力（信頼度）を評価可能な別組織に対し、適切に参加可否判定を依頼することにより、結果として追加対象組織の契約完遂能力（信頼度）を評価した上で非中央集権的に組織追加を実行できる。

また、コンソ外の組織が新規にコンソーシアムもしくはサブグループに新規参加しようとする場合、当該コンソーシアムの任意の組織にリクエストすれば良く、またコンソーシアム内の既存参加者は、上記新規参加しようとする組織に、コンソーシアムやサブグループにおける各組織の役割を開示する必要がない。

なお、実施例１および２において、メンバー管理ノード３００００がメンバー管理表３２０００においてサブグループおよび参加ノードの対応関係を管理することとしていたが、上述の対応関係については、分散台帳ノード上の分散台帳２５０００において分散して管理しても良い。

図２２Ａに、想定するコンピュータシステムを模式的に示す。この場合、分散台帳ノード２００００は、分散台帳２５０００およびサブ台帳２５１００を具備する。分散台帳２５０００上のスマートコントラクト２６０００上には、ノード追加可否判定依頼部２１５００と、ノード追加可否判定部２１６００と、ノード追加可否判定依頼ロジック２３０００と、コンソ追加可否判定依頼ロジック２３１００と、コンソ追加可否判定ロジック２４１００に相当するロジックを保持する。

一方、サブ台帳上のスマートコントラクト２６１００上には、ノード追加可否判定部２１６００と、ノード追加可否判定ロジック２４０００に相当するロジックを保持する。その他の部分の構成は、メンバー管理ノード３００００が組織構成管理表３２１００を持たないことを除き、実施例１と同様である。

また図２２Ｂは、分散台帳２５０００上で管理するステート情報２８０００である。本実施例では、分散台帳ノード２００００上にサブグループ管理用コントラクトを持ち、ステートにもデータ領域が用意されることとする。ステート情報２８０００はコントラクトの識別子であるＩＤ２８０１０と、そのコントラクトの実体２８０２０と、ＳＣの実行結果を保持するための内部テーブル２８０３０を備える。

ＴＸが実行される度にこの内部テーブルの内容を更新する。サブグループ管理用ＳＣが内部テーブルに保持する組織構成管理表２８０６０は、実施例１において図４Ｂで示したメンバー管理ノード３００００の具備するメンバー管理表３２０００と同等である。

本構成では、図９および図１３〜図１６に示した一連の処理のうち、図９のノード追加可否判定処理をサブ台帳２５１００上のスマートコントラクト２６１００で、それ以外の処理を分散台帳２５０００上のスマートコントラクト２６０００で実行することとなる。

また、実施例１および２において、分散台帳ノード２００００が持つこととしていたノード追加可否判定依頼部２１５００、ノード追加可否判定依頼ロジック２３０００、およびコンソ追加可否判定依頼ロジック２３１００については、メンバー管理ノード３００００が持つこととしても良い。図２３において、想定するコンピュータシステムを模式的に示す。

この場合、メンバー管理ノード３００００は、ノード追加可否判定依頼部３３０００と、ノード追加可否判定依頼ロジック３４０００と、コンソ追加可否判定依頼ロジック３５０００を具備する。その他の部分の構成は実施例１と同様である。

本構成では、図７のステップ５３０４０、および図１３のステップ５６０６０、５６０８０において、分散台帳ノード２００００のサブグループ管理部２１４００は、自ノードのノード追加可否判定依頼部ではなく、メンバー管理ノード３００００上のノード追加可否判定依頼部３３０００にノード追加可否判定依頼およびコンソ追加可否判定依頼を実施させる。

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

こうした本実施形態によれば、コンソーシアムやサブグループへの参加組織追加の際、当該コンソーシアムもしくはサブグループに参加する組織間で合意形成の上、組織の新規参加可否を決定することができる。その際、当該組織の契約完遂能力（信頼度）を評価可能な別組織に対し、適切に参加可否判定を依頼することにより、結果として追加対象組織の契約完遂能力（信頼度）を評価した上で非中央集権的に組織追加を実行できる。また、コンソ外の組織が新規にコンソーシアムもしくはサブグループに新規参加しようとする場合、当該コンソーシアムもしくはサブグループの任意の組織にリクエストすれば良く、またコンソーシアム内の既存参加者は、上記新規参加しようとする組織に、コンソーシアムやサブグループにおける各組織の役割を開示する必要がない。
すなわち、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上で効率的に実行可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の組織管理支援システムにおいて、前記分散台帳システムが、前記分散台帳を論理分割したサブ台帳を、前記ビジネスネットワークにおける所定の組織群からなるサブグループ内でのみ共有する論理分割機能を有しているものであり、前記サブグループに属する第一の組織が保有する第一のノードは、前記依頼部において、前記サブグループへの新規参加のリクエストを、前記特定組織である第二の組織が保有する第二のノードから受信した場合、前記サブグループへの前記第二の組織の参加可否について、前記分散台帳システム上の前記他組織たる第三の組織上が保有する第三のノードに判定を依頼し、前記管理部において、少なくとも前記第三のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記第二のノードに回答するものである
、としてもよい。

これによれば、コンソーシアム型ブロックチェーンにおける重要な運用形態である、サブグループに関して、新規参加可否の判定を行うことが可能となり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記各組織の所定ノードは、前記ビジネスネットワークに対応するコンソーシアムまたは前記サブグループへの、前記参加可否について判定するノード追加可否判定プログラムと、前記コンソーシアムまたは前記サブグループへの前記参加可否について、前記分散台帳システム上のノードのうち判定依頼先のノードを決定して前記判定を依頼し、前記判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定するノード追加可否判定依頼プログラムを有するものである、としてもよい。

これによれば、コンソーシアム自体への新規参加または、コンソーシアムには参加済みであるものの当該コンソーシアムに含まれる所定のサブグループへの新規参加、について、その可否判定を行うことが可能となり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記分散台帳システムにおける分散台帳ノードとは別に設けられた所定の管理用ノードが、前記ノード追加可否判定依頼プログラムを保持および実行するものである、としてもよい。

これによれば、分散台帳システム上の全てのノードが処理を行うのではなく、参加リクエストを受ける管理用ノードが判定依頼とその結果の集計等を主導することとなり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記各組織の所定ノードは、分散台帳上で行われる業務もしくは運用の形態を定義したスマートコントラクトを、前記コンソーシアムまたは前記サブグループに属する参加ノード間で合意形成を行った上で共有し、前記スマートコントラクトを前記参加ノード間で合意形成の上で実行し、前記スマートコントラクトの実行結果を前記参加ノードの分散台帳上に時系列順に追記し、前記ノード追加可否判定依頼プログラムを、前記スマートコントラクトとして前記コンソーシアムまたは前記サブグループの前記参加ノード間で共有の上実行するものである、としてもよい。

これによれば、参加リクエストに対する可否判定処理をスマートコントラクトの形で共有し、公正で効率的な判定を行えることとなり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、より信頼性を担保した上で効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記分散台帳システムにおける分散台帳ノードとは別に設けられた所定の管理用ノードが、前記ノード追加可否判定依頼プログラムを実行するノードを選択する、としてもよい。

これによれば、分散台帳システム上の全てのノードが処理を行うのではなく、参加リクエストを受ける管理用ノードが判定依頼の対象ノードを選択することとなり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上
でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記各組織の所定ノードは、前記ノード追加可否判定プログラムを、前記スマートコントラクトとして前記コンソーシアムまたは前記サブグループの前記参加ノード間で共有の上実行するものである、としてもよい。

これによれば、参加リクエストに対する可否判定処理を、コンソーシアムまたはサブグループの参加ノード間にて、スマートコントラクトの形で共有し、公正で効率的な判定を行えることとなり、ひいては、コンソーシアム型ブロックチェーンにおけるコンソーシアムまたはサブグループに対する、メンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記第一もしくは第三のノードが、前記サブグループへの前記第二のノードの参加可否について判定する際、前記第一もしくは第三のノードが参照可能なサブ台帳に記載された、前記第二の組織に関する過去の取引履歴を参照する、としてもよい。

これによれば、参加可否判定に際して必要な信用に関する情報として、過去の取引履歴を参照可能となり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、より信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記第一のノードは、前記第二のノードの新規参加のリクエストが、前記第一のノードが所属する第一のサブグループと異なる第二のサブグループへの参加リクエストである場合、前記第二のサブグループに属する各ノードを前記第三のノードとして特定するものである、としてもよい。

これによれば、サブグループへの新規参加のリクエストに関して、当該サブグループのノードを参加可否判定の実行主体として選定し、判定処理を行わせることが可能となる。ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記第一のノードは、前記第二のサブグループに属する各ノードを前記第三のノードとして特定する際、前記分散台帳システム内のサブグループおよび当該サブグループに属する全ノードの一覧を記録したサブグループ管理表を参照するものである、としてもよい。

これによれば、サブグループ管理表に基づいて、上述の第三のノードを効率よく特定できることとなり、ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記第一のノードは、前記第二のサブグループに属する各ノードを前記第三のノードとして特定する際、前記分散台帳システム内のサブグループおよび当該サブグループの代表となる代表ノードを記録したサブグループ管理表を参照し、前記代表ノードに対し、前記サブグループに所属するノードを問い合わせた上で、該当するノードを前記第三のノードとして特定するものである、としてもよい。

これによれば、新規参加のリクエストの対象となったサブグループに関して、第一のノードが全てのノード探索・選定を行うのではなく、元々所属ノードについて把握済みの代
表ノードに当該処理を委任可能となる。ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

また、本実施形態の組織管理支援システムにおいて、前記第一のノードは、前記第二のノードの新規参加のリクエストが、前記第一のノードが所属する第一のサブグループと異なる第二のサブグループへの参加リクエストである場合、前記第二のサブグループの代表となるノードを前記第三のノードとして特定する、としてもよい。

これによれば、新規参加のリクエストの対象となったサブグループに関して、第一のノードが全てのノード探索・選定と実際の判定依頼を行うのではなく、元々所属ノードについて把握済みの代表ノードに当該処理を委任可能となる。ひいては、コンソーシアム型ブロックチェーンにおけるメンバーの加入管理を、信頼性を担保した上でより効率的に実行可能となる。

１００ 組織管理支援システム
２０１ 記憶部
２０２ プログラム
２０３ 演算部
２０４ メモリ
２０５ 通信部
１００００ クライアントノード
１１０００ トランザクション発行部
１２０００ 業務アプリ
２００００ 分散台帳ノード（組織管理支援装置）
２１１００ コンセンサス管理部
２１２００ スマートコントラクト実行／管理部
２１３００ トランザクション管理部
２１４００ サブグループ管理部
２１５００ ノード追加可否判定依頼部
２１６００ ノード追加可否判定部
２３０００ ノード追加可否判定依頼ロジック
２３１００ コンソ追加可否判定依頼ロジック
２４０００ ノード追加可否判定ロジック
２４１００ コンソ追加可否判定ロジック
２５０００ 分散台帳
２５１００ サブ台帳
２６０００ スマートコントラクト
２７０００ ブロックチェーン
２８０００ ステート情報
３００００ メンバー管理ノード
３１０００ メンバー管理部
３２０００ メンバー管理表
３２１００ 組織構成管理表
４００００ ネットワーク

Claims (14)

1. 分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードが、
   特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する依頼部と、
   少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理を実行する管理部と、
   を備えるものであることを特徴とする組織管理支援システム。
2. 前記分散台帳システムが、前記分散台帳を論理分割したサブ台帳を、前記ビジネスネットワークにおける所定の組織群からなるサブグループ内でのみ共有する論理分割機能を有しているものであり、
   前記サブグループに属する第一の組織が保有する第一のノードは、
   前記依頼部において、前記サブグループへの新規参加のリクエストを、前記特定組織である第二の組織が保有する第二のノードから受信した場合、前記サブグループへの前記第二の組織の参加可否について、前記分散台帳システム上の前記他組織たる第三の組織上が保有する第三のノードに判定を依頼し、
   前記管理部において、少なくとも前記第三のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記第二のノードに回答するものである、
   ことを特徴とする請求項１に記載の組織管理支援システム。
3. 前記各組織の所定ノードは、
   前記ビジネスネットワークに対応するコンソーシアムまたは前記サブグループへの、前記参加可否について判定するノード追加可否判定プログラムと、
   前記コンソーシアムまたは前記サブグループへの前記参加可否について、前記分散台帳システム上のノードのうち判定依頼先のノードを決定して前記判定を依頼し、前記判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定するノード追加可否判定依頼プログラムを有するものである、
   ことを特徴とする請求項１に記載の組織管理支援システム。
4. 前記分散台帳システムにおける分散台帳ノードとは別に設けられた所定の管理用ノードが、前記ノード追加可否判定依頼プログラムを保持および実行するものである、
   ことを特徴とする請求項３に記載の組織管理支援システム。
5. 前記各組織の所定ノードは、
   分散台帳上で行われる業務もしくは運用の形態を定義したスマートコントラクトを、前記コンソーシアムまたは前記サブグループに属する参加ノード間で合意形成を行った上で共有し、前記スマートコントラクトを前記参加ノード間で合意形成の上で実行し、前記スマートコントラクトの実行結果を前記参加ノードの分散台帳上に時系列順に追記し、
   前記ノード追加可否判定依頼プログラムを、前記スマートコントラクトとして前記コンソーシアムまたは前記サブグループの前記参加ノード間で共有の上実行するものである、
   ことを特徴とする請求項３に記載の組織管理支援システム。
6. 前記分散台帳システムにおける分散台帳ノードとは別に設けられた所定の管理用ノードが、前記ノード追加可否判定依頼プログラムを実行するノードを選択する、
   ことを特徴とする請求項５に記載の組織管理支援システム。
7. 前記各組織の所定ノードは、
   前記ノード追加可否判定プログラムを、前記スマートコントラクトとして前記コンソーシアムまたは前記サブグループの前記参加ノード間で共有の上実行するものである、
   ことを特徴とする請求項５に記載の組織管理支援システム。
8. 前記第一もしくは第三のノードが、
   前記サブグループへの前記第二のノードの参加可否について判定する際、前記第一もしくは第三のノードが参照可能なサブ台帳に記載された、前記第二の組織に関する過去の取引履歴を参照する、
   ことを特徴とする請求項２に記載の組織管理支援システム。
9. 前記第一のノードは、
   前記第二のノードの新規参加のリクエストが、前記第一のノードが所属する第一のサブグループと異なる第二のサブグループへの参加リクエストである場合、前記第二のサブグループに属する各ノードを前記第三のノードとして特定するものである、
   ことを特徴とする請求項２に記載の組織管理支援システム。
10. 前記第一のノードは、
    前記第二のサブグループに属する各ノードを前記第三のノードとして特定する際、前記分散台帳システム内のサブグループおよび当該サブグループに属する全ノードの一覧を記録したサブグループ管理表を参照するものである、
    ことを特徴とする請求項９に記載の組織管理支援システム。
11. 前記第一のノードは、
    前記第二のサブグループに属する各ノードを前記第三のノードとして特定する際、前記分散台帳システム内のサブグループおよび当該サブグループの代表となる代表ノードを記録したサブグループ管理表を参照し、前記代表ノードに対し、前記サブグループに所属するノードを問い合わせた上で、該当するノードを前記第三のノードとして特定するものである、
    ことを特徴とする請求項９に記載の組織管理支援システム。
12. 前記第一のノードは、
    前記第二のノードの新規参加のリクエストが、前記第一のノードが所属する第一のサブグループと異なる第二のサブグループへの参加リクエストである場合、前記第二のサブグループの代表となるノードを前記第三のノードとして特定する、
    ことを特徴とする請求項９に記載の組織管理支援システム。
13. 分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードが、
    特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する処理と、
    少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理と、
    を実行することを特徴とする組織管理支援方法。
14. 分散台帳システムにてビジネスネットワークを構成する各組織の所定ノードであって、
    特定組織のノードから、前記ビジネスネットワークへの新規参加のリクエストを受信した場合、前記ビジネスネットワークへの前記特定組織の参加可否について、前記分散台帳システム上の他組織のノードに判定を依頼する依頼部と、
    少なくとも前記他組織のノードによる判定結果を集計し、当該集計の結果に基づいて前記参加可否を最終判定し、当該最終判定の結果を前記特定組織のノードに回答する処理を実行する管理部と、
    を備えることを特徴とする組織管理支援装置。

Images