JP2019074910A - アクセス権管理方法、アクセス権管理システム、および、アクセス権管理装置 - Google Patents

Abstract

【課題】コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能とする。【解決手段】所定事業者によるビジネスネットワークを構成するアクセス権管理システム２０において、所定ノード２００が、所定処理の実行に伴い発行され、分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する構成とする。【選択図】図１Ａ

Description

本発明は、アクセス権管理方法、アクセス権管理システム、および、アクセス権管理装置に関するものであり、具体的には、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能とする技術に関する。

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

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

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

そうした応用例の一つとして、分散台帳技術を複雑な取引条件や多様なアプリケーションにも適用可能とすべく、分散台帳にて取引データだけでなく取引条件を記載したロジック、すなわちスマートコントラクト（以下、ＳＣとも称する）も管理しうる技術も提案されている。

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

上述のＳＣに関する従来技術としては、ＳＣの実行機能を有する分散台帳基盤に関する技術（非特許文献１および２参照）が提案されている。こうした分散台帳基盤では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも称する）を受け入れて、各ノードでＴＸを実行し、当該ＴＸの実行結果を保持することにより、複数ノード上で情報（台帳）を共有することとなる。また、上述のＴＸに対して予め決めたロジックを実行するＳＣ実行機能を備えている。

また、製造業、特にサプライチェーン管理分野における、ＢＣを用いた分散台帳技術の応用例としては、複数の事業者が参加する分散台帳基盤の上に、事業者間での売買レコードを暗号化して記録し、必要に応じて前記レコードをつなぎ合わせることにより、事業者間での商品の流れをトレースできるようにする技術（特許文献１参照）が提案されている。

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

米国特許公報９４３６９２３号

ところが、上述のコンソーシアム型の分散台帳基盤を、サプライチェーンにおけるトレーサビリティ管理に適用した場合、分散台帳技術の特徴たる分散台帳を介した参加者間でのデータ共有が、却って問題を生じるケースもある。

例えば、当該サプライチェーンを構成するバイヤー、サプライヤの立場や商習慣によっては、それぞれにおいて管理するデータを他の参加者に開示しない状況も一般的である。ところが、こうしたサプライチェーンにおけるトレーサビリティ管理に分散台帳技術をそのまま適用すれば、本来ならばデータ開示しない相手に対して当該データの共有がなされてしまう事態に至る。

具体的には、例えばバイヤーの立場において、当該バイヤーが製造した製品および当該製品に使用すべく各サプライヤから購入した部品、の各データについて参照可能であることは当然必要であるが、そうした各サプライヤとの取引関係や取引内容が他社に開示されることは営業上望ましくない。このことは、バイヤー、サプライヤを問わず、サプライチェーンの各参加者において同様に該当しうる。

そこで本発明の目的は、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能とする技術を提供することにある。

上記課題を解決する本発明のアクセス権管理方法は、所定事業者によるビジネスネットワークを構成する分散台帳システムにおいて、少なくともいずれかの所定ノードが、所定処理の実行に伴い発行され、分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する、ことを特徴とする。

また、本発明のアクセス権管理システムは、所定事業者によるビジネスネットワークを構成する分散台帳システムであって、所定処理の実行に伴い発行されたトランザクションを格納する分散台帳を少なくとも保持する記憶装置と、前記分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する演算装置と、を備えた複数の情報処理装置を含むことを特徴とする。

また、本発明のアクセス権管理装置は、所定事業者によるビジネスネットワークを構成する分散台帳システムの、少なくともいずれかの所定ノードであって、所定処理の実行に伴い発行されたトランザクションを格納する分散台帳を少なくとも保持する記憶装置と、前記分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する演算装置と、を備えることを特徴とする。

本発明によれば、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能とできる。

実施例１におけるアクセス権管理システムの構成例を示す図である。 実施例１における情報処理装置のハードウェア構成例を示す図である。 実施例１における取引履歴管理表の構成例１を示す図である。 実施例１における取引履歴管理表の構成例２を示す図である。 実施例１における製造履歴管理表の構成例１を示す図である。 実施例１における製造履歴管理表の構成例２を示す図である。 実施例１におけるブロックチェーンの構成例を示す図である。 実施例１におけるステート情報の構成例を示す図である。 実施例１における含むメンバー管理表の構成例を示す図である。 実施例１におけるアクセス権管理表の構成例を示す図である。 実施例１におけるアクセス権管理方法のフロー例１を示す図である。 実施例１におけるアクセス権管理方法のフロー例２を示す図である。 実施例１におけるアクセス権管理方法のフロー例３を示す図である。 実施例１におけるアクセス権管理方法のフロー例４を示す図である。 実施例１におけるアクセス権管理方法のフロー例５を示す図である。 実施例１におけるアクセス権管理方法のフロー例６を示す図である。 実施例１における画面例を示す図である。 実施例１のアクセス権管理表における書き込み処理例を示す概念図である。 実施例１の分散台帳およびアクセス権管理表における書き込み処理例を示す概念図である。 実施例２における計算機システムの構成例を示す図である。 実施例２におけるブロックチェーンの構成例１を示す図である。 実施例２におけるブロックチェーンの構成例２を示す図である。 実施例２におけるステート情報の構成例を示す図である。 実施例２におけるアクセス権管理方法のフロー例１を示す図である。 実施例２におけるアクセス権管理方法のフロー例２を示す図である。 実施例２におけるアクセス権管理方法のフロー例３を示す図である。 実施例２におけるアクセス権管理方法のフロー例４を示す図である。 実施例２におけるアクセス権管理方法のフロー例５を示す図である。 実施例２におけるアクセス権管理方法のフロー例６を示す図である。

−−−実施例１−−−
図１Ａは、実施例１におけるアクセス権管理システムの構成例を示す図である。ここでは、一例として製品製造に伴うサプライチェーンを成すビジネスネットワークに対して、アクセス権管理手法を適用し、当該サプライチェーンで生じる各種データのアクセス権管
理を行う状況を想定し、説明を進めるものとする。

図１Ａに例示するアクセス権管理システム２０は、分散台帳システムであって、１台以上のクライアントノード１００、１台以上の分散台帳ノード２００、および、１台以上のメンバー管理ノード３００によって構成される。また、これらの機器は、物理的な通信回線を通してネットワーク１に接続され、互いに通信可能となっている。

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

同様に、クライアントノード１００も複数台存在するものとしている。また、それぞれのクライアントノード１００は、ビジネスネットワークの参加者たるＳＣ利用者それぞれによって利用されることを想定する。

また、メンバー管理ノード３００も複数台存在するものと想定可能である。こうした複数台のメンバー管理ノード３００は、それぞれが同じ情報を共有しつつ並存することで、障害発生時などに対処する冗長性を担保可能となる。あるいは、コンソーシアムの配下に複数のサブグループを設け、そのサブグループ毎に異なるメンバー管理ノード３００を使い分ける形態を採用しても良い。メンバー管理ノード３００が複数存在する場合、分散台帳ノード２００のそれぞれは、どのメンバー管理ノード３００にアクセスするかを設定情報として事前に保持しているものとする。

なお、クライアントノード１００、分散台帳ノード２００、および、メンバー管理ノード３００の物理的な実体は、図１Ｂに例示するように、ＳＳＤなど不揮発性記憶素子からなる記憶装置１１、ＲＡＭなど揮発性記憶素子からなるメモリ１３、記憶装置１１に保持されるプログラム１２をメモリ１３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１４、ユーザからのキー入力や音声入力を受け付ける入力装置１５、処理データの表示を行うディスプレイ等の出力装置１６、ネットワーク１と接続し他装置との通信処理を担う通信装置１７、からなる一般的な計算機である。

また、上述のアクセス権管理システム２０を構成する機器のうち、クライアントノード１００は、トランザクション発行部１１０、ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）業務アプリ１２０、取引履歴管理表１３０、製造業務アプリ１４０、製造履歴管理表１５０、および、部品トレースアプリ１６０、によって構成される。

このうちＥＤＩ業務アプリ１２０および製造業務アプリ１４０は、ユーザより部品の出荷、入荷もしくは製造に関する情報の入力を受け、それぞれ取引履歴管理表１３０および製造履歴管理表１４０に当該情報を含んだ履歴を蓄積するアプリケーションである。

また、ＥＤＩ業務アプリ１２０および製造業務アプリ１４０は、上述の部品の出荷、入荷もしくは製造に関する情報の入力を受けると、トランザクション発行部１１０を介して、当該情報を含むＴＸを発行し、当該部品の取引もしくは製造の履歴を分散台帳ノード２００に対して送信する。

なお、上述のＴＸの発行者の主体は、部品出荷に伴うＴＸの場合、後述する取引履歴管理表１３０のフィールド１３０３に記載された出荷者である。一方、部品入荷に伴うＴＸの場合、当該ＴＸの発行者の主体は、後述する取引履歴管理表１３０のフィールド１３０
６に記載された入荷者である。また、部品製造に伴うＴＸの場合、当該ＴＸの発行者の主体は、後述する製造履歴管理表１５０のフィールド１５０１に記載された製造者である。
なお、ＴＸには発行者情報を付与するものとする。この発行者情報は、上述の出荷者、入荷者、もしくは製造者と紐つける形でメンバー管理ノード３００より予め付与されたメンバーＩＤとメンバー管理ノード３００によってメンバー毎に発行された認証情報（秘密鍵）とを含めるものとする。

また、部品トレースアプリ１６０は、トランザクション発行部１１０を介して、所定製品の製造に使われた部品の取引および製造の履歴に関する情報を取得するためのＴＸを発行し、それにより得た部品トレース情報をユーザに表示するアプリケーションである。
なお、クライアントノード１００は、ＥＤＩ業務アプリ１２０と製造業務アプリ１４０のうちいずれか一方のみを具備していても良い。

また、上述のアクセス権管理システム２０を構成する機器のうち、分散台帳ノード２００は、コンセンサス管理部２１０、スマートコントラクト実行／管理部２２０（以下、ＳＣ実行／管理部とも称する）、トランザクション管理部２３０、トランザクション発行部２４０、および、分散台帳２５０によって構成される。

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

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

なお、分散台帳２５０では、出荷、入荷、製造といった各種の業務に関するスマートコントラクト２６０、および当該ＳＣの実行結果を格納・管理する。そのデータ構造としては、例えば、ＴＸの履歴をブロックチェーン２７０として、ＴＸの実行結果に基づくステート情報２８０をテーブル形式で保持することを想定する。

また、上述のアクセス権管理システム２０を構成する機器のうち、メンバー管理ノード３００は、メンバー管理部３１０、メンバー管理表３２０、および、アクセス権管理表３３０によって構成される。

このうちメンバー管理部３１０は、コンソーシアムに参加するバイヤーやサプライヤといったメンバーの新規発行や認証機能を提供する。メンバー管理部３１０では、秘密鍵と公開鍵のペアを用いて、参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。こうしたメンバー管理に関する秘密鍵や公開鍵などの鍵情報は、メンバー管理表３２０に格納、管理される。一方、上述の分散台帳ノード２００におけるトランザクション管理部２３０は、ＴＸを受け付けた際に、メンバー管理ノード３００におけるメンバー管理部３１０の機能を介して、ＴＸの発行者が権限を持った正しい参加者かどうかを確認することとなる。

続いて、本実施例のアクセス権管理システム２０にて利用されるテーブル類について説明する。図２Ａ、図２Ｂに、本実施例における取引履歴管理表１３０のデータ構成例を示す。この取引履歴管理表１３０は、クライアントノード１００が具備するテーブルとなる
。

取引履歴管理表１３０は、この取引履歴管理表１３０を用いるＥＤＩ業務アプリ１２０の識別子を登録するフィールド１３０１と、ＥＤＩ業務で生じる部品や製品等の各取引に固有の伝票番号を登録するフィールド１３０２と、当該取引における出荷者を登録するフィールド１３０３と、取引対象となる部品の型番を登録するフィールド１３０４と、取引対象となる部品のシリアル番号を登録するフィールド１３０５と、当該取引における入荷者を登録するフィールド１３０６と、を構成項目として含んでいる。なお、部品の出荷は完了しているものの入荷に至っていない部品に関するレコードでは、フィールド１３０６が空欄となっている。

図２Ａに示す取引履歴管理表１３０の具体例では、「ＥＤＩ１」という識別子を持つＥＤＩ業務アプリ上で、伝票番号「１０１」で示される取引が行われており、その取引では出荷者「Ｔ２−２」が、型番「ＭＮＦ−１」およびシリアル番号「１００１」で示される部品を出荷しており、入荷者「Ｔ１−２」において当該部品が入荷済みであることを表している。

また、図２Ｂに示す取引履歴管理表１３０の具体例では、「ＥＤＩ２」という識別子を持つＥＤＩ業務アプリ上で、伝票番号「２０１」で示される取引が行われており、その取引では上述の図２Ａでは入荷者であった出荷者「Ｔ１−２」が、型番「ＭＮＦ−１１」およびシリアル番号「１１００１」で示される部品を出荷しており、入荷者「ＳＭ−１」において当該部品が入荷済みであることを表している。

つまり、出荷者「Ｔ２−２」が出荷した、型番「ＭＮＦ−１」およびシリアル番号「１００１」で示される部品を、入荷者「Ｔ１−２」が受領し、この部品を利用して型番「ＭＮＦ−１１」およびシリアル番号「１１００１」で示される部品を製造し、入荷者「ＳＭ−１」に向けて出荷しているサプライチェーン上の商流を示している。

続いて、図３に、本実施形態における製造履歴管理表１５０のデータ構成例を示す。この製造履歴管理表１５０は、クライアントノード１００が保持するテーブルであって、履歴登録対象の製品の製造者を登録するフィールド１５０１と、履歴登録対象の製品の型番を登録するフィールド１５０２と、製品シリアル番号を登録するフィールド１５０３と、当該製品の製造時に使用した部品の型番を登録するフィールド１５０４と、当該部品調達時に用いたＥＤＩ業務アプリの識別子の型番を登録するフィールド１５０５と、当該部品調達時の入荷伝票番号を登録するフィールド１５０６と、を構成項目として含んでいる。

図３Ａに示す製造履歴管理表１５０の具体例では、「Ｔ１−２」という識別子を持つ事業者が、型番「ＭＮＦ−１１」とシリアル番号「１１００１」で示される製品を製造した際、型番「ＭＮＦ−１」〜「ＭＮＦ−４」で示される部品を使用し、また、型番「ＭＮＦ−１」で示される部品はＥＤＩ業務アプリ「ＥＤＩ１」上の伝票番号「１０１」で示される取引によって入荷したことを表している。

一方、図３Ｂに示す製造履歴管理表１５０の具体例では、「ＳＭ−１」という識別子を持つ事業者が、型番「ＭＮＦ−１０１」とシリアル番号「１１１００１」で示される製品を製造した際、型番「ＭＮＦ−１１」〜「ＭＮＦ−１４」で示される部品を使用し、また、型番「ＭＮＦ−１１」で示される部品はＥＤＩアプリ「ＥＤＩ２」上の伝票番号「２０１」で示される取引によって入荷したことを表している。

続いて、分散台帳ノード２００の具備する分散台帳２５０の構成について説明する。 図４および図５は、分散台帳２５０におけるデータ構造例である。このうち図４は、分散
台帳２５０で管理するブロックチェーン２７０の例を示す図である。

ＢＣを用いた分散台帳管理では、一定時間に発行、合意形成された複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことで各ブロックを数珠つなぎにして管理する。こうした管理を行う場合、前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変わることになる。そのため、分散台帳２５０における改ざんは困難である。なお、本実施例では説明をシンプルにするために、１つのＴＸにつき１ブロックを構成した例を示すが、勿論、複数のＴＸをまとめて１ブロックに格納した構成も想定可能である。

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

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

図４の例では、「部品トレース」というＩＤを持つＳＣの関数名として「出荷」、「入荷」、「製造」、「履歴参照」の４つが定義されており、各関数のロジックが定義されている。

具体的には、「出荷」、「入荷」、「製造」については図１０に示す「ロジックＡ」が、また、「履歴参照」については図１１に示す「ロジックＢ」が定義されている。

また、このデプロイＴＸ２７３０は、当該デプロイＴＸ２７３０の発行元、すなわち、提供者を識別するための発行者ＩＤを含む。さらに、そうした発行元とデータに改ざんが無いことを検証するために用いる電子署名を含む。この電子署名は、メンバー管理ノード３００のメンバー管理部３１０が発行したコンソーシアム参加メンバー（すなわちＳＣ提供者や利用者）の秘密鍵を用いて生成され、そのペアとなる公開鍵によって検証をすることが可能である。また、デプロイＴＸ２７３０は、当該デプロイＴＸ２７３０の固有の識別子であるトランザクションＩＤを含む。

また、ブロック２７０２は、ＳＣの実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸ２７４０は、呼び出し対象となるスマートコントラクトのコントラクトＩＤ、呼び出し対象となるスマートコントラクトの関数名と入力する引数の情報を含む。この例では、「部品トレース」というＩＤを持つＳＣの関数「出荷」を呼び出しており、その引数はＥＤＩアプリＩＤ、伝票番号、型番、シリアル番号の４つであり、その値はそれぞれ”ＥＤＩ１”、”１０１”、”ＭＮＦ−１”、”１００１”である。さらに、この実行ＴＸ２７４０の発行元、すなわち、利用者を識別するための発行者ＩＤを含む。さらに発行元とデータに改ざんがないことを検証するために用いる利用者の電子署名を含む。なお、発行元だけでなく、合意形成に関わったコンソーシアム参加者の情報も管理／保持してもよい。また、実行ＴＸ２７４０は、本実行ＴＸ２７４０の固有の識別子であるトランザクションＩＤを含む。

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

本実施例でも、分散台帳２５０において、最新のステート情報２８０を保持することを想定する。本実施例では、スマートコントラクトが持つ関数毎にステートのデータ領域が用意されることとする。ステート情報２８０は、スマートコントラクトの識別子であるコントラクトＩＤ２８０１と、そのスマートコントラクトの実体２８０２を保持する。これにより、分散台帳ノード２００のＳＣ実行／管理部２２０は、コントラクトＩＤと関数名をキーにして、スマートコントラクトの実体を取得して実行することができる。また、ステート情報２８０は、ＳＣの実行結果を保持するための内部テーブル２８０３を備える。ＳＣ実行／管理部２２０は、ＴＸが実行される度にこの内部テーブル２８０３の内容を更新することとなる。
また図６は、本実施例のメンバー管理ノード３００が具備するメンバー管理表３２０の構成例を示す図である。

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

このアクセス権管理表３３０は、分散台帳ノード２００の具備する分散台帳２５０に格納されたトランザクションの識別子を登録するフィールド３３０１と、当該トランザクションの参照を許可されているメンバーの識別子を登録するフィールド３３０２と、を構成項目として含んでいる。

以下、本実施例におけるアクセス権管理方法の実際手順について図に基づき説明する。以下で説明するアクセス権管理方法に対応する各種動作は、アクセス権管理システム２０を構成する情報処理装置らがメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図８は、本実施形態におけるアクセス権管理方法のフロー例１を示す図であり、具体的には、上述のコンソーシアムに参加するメンバーの新規登録処理の例を示すフローチャートである。
まず、メンバー管理ノード３００のメンバー管理部３１０は、クライアントノード１００などの他ノードからメンバー登録要求を受け付ける（ｓ１００）。

続いて、メンバー管理部３１０は、上述のメンバー登録要求を受けると、要求メンバーを一意に識別するメンバーＩＤを適宜なルールで採番し、更に、当該要求メンバーに関して秘密鍵と公開鍵の組を生成する（ｓ１０１）。この場合、メンバー管理部３１０は、ｓ１０１で生成したメンバーＩＤと、上述のように生成した公開鍵とを紐付けて、メンバー管理表３２０に登録する。

次に、メンバー管理部３１０は、新規登録対象となる上述のメンバーＩＤおよび公開鍵を、他のメンバー管理ノード３００にブロードキャストする（ｓ１０２）。
ここでブロードキャストされたメンバーＩＤおよび公開鍵の情報は、各メンバー管理ノ
ード３００のアクセス権管理表３３０で保管される。

さらに、メンバー管理部３１０は、ｓ１００でメンバー登録要求を受けたノードに対し、ｓ１０１で生成した秘密鍵を返し（ｓ１０３）、処理を終了する。他方、この秘密鍵を受け取ったノードは、自身の秘密鍵として記憶装置において適宜に保管する。

本実施例では、以上のようにして生成した秘密鍵と公開鍵のペアを用いて、コンソーシアム参加メンバーの認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。
具体的には、例えば、クライアントノード１００は、発行された秘密鍵で電子署名したＴＸを発行し、これを検証するノードでは、上述の公開鍵を用いて当該電子署名を検証することで、本人確認を実現できる。なお、公開鍵と秘密鍵の組を生成する手法や署名検証をする手法については、公知または周知の技術を適用すれば良い。

また、本実施例では複数のメンバー管理ノード３００が、メンバーＩＤと公開鍵の情報を共有することを前提として説明を行うが、こうしたメンバー管理ノード３００は単一であっても良い。また、メンバー管理ノード３００の機能およびデータを分散台帳ノード２００にて保持しても良い。あるいは、コンソーシアムの配下に複数のサブグループを設け、そのサブグループ毎に異なるメンバー管理ノード３００を使い分ける形態を取っても良い。

続いて図９は、実施例１におけるアクセス権管理方法のフロー例２を示す図であり、具体的には、ＴＸ実行処理、すなわち、ＳＣのデプロイ、実行の例を示すフローチャートである。

この場合、分散台帳ノード２００のトランザクション管理部２３０が、クライアントノード１００などのＴＸ発行元からＴＸを受信し（ｓ１１０）、当該ＴＸにＩＤを付与した上で、コンセンサス管理部２１０に渡し、ＳＣ／ＴＸの種別に応じてＳＣのデプロイ、実行処理を行う。

続いて、コンセンサス管理部２１０は、上述のトランザクション管理部２３０にて受け取ったＴＸがＳＣのデプロイＴＸであった場合（ｓ１１１：ＹＥＳ）、他の分散台帳ノード２００との間で、受け取ったＴＸを実行してよいか、ブロックとして、ＢＣの末尾に追加してよいかの合意形成処理を行う（ｓ１１２）。

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

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

上述のように合意形成が完了したならば、コンセンサス管理部２１０は、ＳＣ実行／管
理部２２０を介して、当該ＴＸに含まれるＳＣを分散台帳２５０に登録する（ｓ１１３）。 具体的には、ＴＸの内容に基づき、コントラクトＩＤやコントラクト実体を分散台帳２５０のステート情報２８０として登録し、ＢＣの末尾にこのデプロイＴＸを含むブロックを追加する。この際、合意形成を行った他の分散台帳ノード２００においても同様にブロックの追加を行う。
最後に、コンセンサス管理部２１０は、デプロイＴＸの実行結果をＴＸ発行元に返す（ｓ１１４）。

なお、ｓ１１０で受け取ったＴＸが実行ＴＸの場合（ｓ１１１：ＮＯ）、コンセンサス管理部２１０は、デプロイＴＸと同様に合意形成処理を行う（ｓ１１５）。この合意形成処理はｓ１１２と同様である。

コンセンサス管理部２１０は、上述のｓ１１５での合意形成が完了したら、ＳＣ実行／管理部２２０を介して、ＳＣを実行して分散台帳２５０の内容を更新する（ｓ１１６）。
具体的には、実行ＴＸ内で指定されたコントラクトＩＤを持つＳＣ（登録済みであることを前提とする）に対して、実行ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。そして、その結果に基づき、分散台帳２５０の内容を更新することとなる。

上述の関数は、ＴＸの書き込みを行うものと、条件を指定してＴＸの読み込みを行うものとに大きく分かれる。ＳＣの実行内容の例については図１０および図１１にて述べる。

ｓ１１６におけるコンセンサス管理部２１０は、ＳＣの実行結果に基づいて、本スマートコントラクトに関するステート情報２８０を更新し、ブロックチェーン２７０の末尾のブロックとして実行ＴＸを追加する。

この際、実行した関数がＴＸの書き込みを行うものであった場合、合意形成を行った他の分散台帳ノード２００においても同様にブロックの追加を行う。ただし、図１０に示す処理のうち、メンバー管理ノード３００のメンバー管理部３１０に対する、アクセス権付与の指示は省略してもよい。
最後に、コンセンサス管理部２１０は、上述の実行ＴＸの実行結果（例えば、関数の戻り値）をＴＸ発行元に返し（ｓ１１７）、処理を終了する。

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

図１０Ａ、図１０Ｂは、図４のブロックチェーン２７０で示した「部品トレース」というＩＤを持つＳＣの関数のうち、ＴＸ書き込み関数である「出荷」、「入荷」、「製造」の呼び出し時の内部処理の例を示すフローチャートである。

この場合、分散台帳ノード２００のＳＣ実行／管理部２２０は、合意形成済みのＴＸとして、「部品トレース」ＳＣ関数の「出荷」、「入荷」、「製造」のいずれかの呼び出しを受け取る（ｓ１２０）と、当該ＳＣに定義された処理を実行する。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部２２０は、当該ＴＸの内容に基づき、本スマートコントラクトに関するステート情報２８０を更新する。ステート情報２８０の内部テーブル２８０３は、図５で例示したステート情報２８０における項目２８０４〜２８０５に示すとおり 、
「出荷」、「入荷」、「製造」といった関数毎にテーブルが分かれている。そのためＳＣ
実行／管理部２２０は、呼び出された関数に応じたテーブルにＴＸの引数で指定された情報を追加する。

次に、ＳＣ実行／管理部２２０は、ブロックチェーン２７０の末尾のブロックとして実行ＴＸを追加する（ｓ１２１）。その際、ＳＣ実行／管理部２２０は、前のブロックのハッシュ値とステート情報から生成したハッシュ値、および、トランザクションＩＤを合わせて登録する。

次に、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者に当該ＴＸへのアクセス権を付与するよう指示する。一方、メンバー管理部３１０はアクセス権管理表３３０を操作し、当該ＴＸに関してＳＣ実行者のアクセス権を付与する（ｓ１２２）。

続いて、上述の呼び出されたＳＣの関数が「出荷」、「製造」のいずれかの場合（ｓ１２３：「出荷」、「製造」）、ＳＣ実行／管理部２２０は、処理をｓ１３２に進める。他方、呼び出されたＳＣの関数が「入荷」の場合（ｓ１２３：「入荷」）、ＳＣ実行／管理部２２０は、処理をｓ１２４に進める。

ｓ１２４におけるＳＣ実行／管理部２２０は、ＴＸに含まれる入荷情報に定義された伝票番号を元に、対応する出荷情報を分散台帳２５０から検索する（ｓ１２４）。

次にＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者に当該出荷情報を定義したＴＸへのアクセス権を付与するよう指示する。他方、メンバー管理部３１０は、アクセス権管理表３３０を操作し、当該ＴＸに関してＳＣ実行者のアクセス権を付与する（ｓ１２５）。

次に、ＳＣ実行／管理部２２０は、上述の出荷情報に定義された出荷者、型番、および、シリアル情報を元に、対応する製造情報を分散台帳２５０から検索する（ｓ１２６）。
この検索の結果、該当する製造情報が分散台帳２５０に存在しない場合（ｓ１２７：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１３２に進める。

他方、上述の検索の結果、該当する製造情報が分散台帳２５０に存在する場合（ｓ１２７：ＹＥＳ）、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者に当該製造情報を定義したＴＸへのアクセス権を付与するよう指示する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を操作し、当該ＴＸに関してＳＣ実行者のアクセス権を付与する（ｓ１２８）。
次に、ＳＣ実行／管理部２２０は、上述の製造情報に定義された部品のリストについて、以下の処理を繰り返す（ｓ１２９〜ｓ１３０）。

まず、ＳＣ実行／管理部２２０は、上述の製造情報に定義された部品の型番および伝票番号を元に、対応する入荷情報を分散台帳２５０から検索する（ｓ１２９）。

次に、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者に当該入荷情報を定義したＴＸへのアクセス権を付与するよう指示する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を操作し、当該ＴＸに関してＳＣ実行者のアクセス権を付与する（ｓ１３０）。
以降、ＳＣ実行／管理部２２０は、上述のｓ１２４〜ｓ１３０の処理を、全ての部品について、これ以上辿れなくなるまで繰り返す（ｓ１３１）。
最後に、ＳＣ実行／管理部２２０は、本ＳＣの実行結果（例：成功）を返し（ｓ１３２）、処理を終了する。

図１１Ａ、図１１Ｂは、図４のブロックチェーン２７０で示した「部品トレース」というＩＤを持つＳＣの関数のうち、ＴＸ読み込み関数である「履歴検索」呼び出し時の内部処理の例を示すフローチャートである。

この場合、ＳＣ実行／管理部２２０は、合意形成済みのＴＸとして、「部品トレース」のＳＣ関数「履歴検索」の呼び出しを受け取る（ｓ１４０）と、当該ＳＣに定義された処理を実行する。具体的な内部処理を以下に示す。
まず、ＳＣ実行／管理部２２０は、実行ＴＸに定義された部品の型番および伝票番号を元に、対応する入荷情報を分散台帳２５０から検索する（ｓ１４１）。
上述の検索の結果、該当する入荷情報が分散台帳に存在しない場合（ｓ１４２：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１５６に進める。

他方、上述の検索の結果、該当する入荷情報が分散台帳に存在する場合（ｓ１４２：ＹＥＳ）、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者が当該入荷情報を定義したＴＸへのアクセス権を持つかどうかを照会する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を参照し、ＳＣ実行者が当該ＴＸに対するアクセス権を持つか確認する（ｓ１４３）。
この確認の結果、当該ＴＸに対するアクセス権がない場合（ｓ１４４：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１５６に進める。

他方、上述の確認の結果、当該ＴＸに対するアクセス権がある場合（ｓ１４４：ＹＥＳ）、ＳＣ実行／管理部２２０は、上述のＴＸに含まれる入荷情報に定義された伝票番号を元に、対応する出荷情報を分散台帳２５０から検索する（ｓ１４５）。

次にＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者が当該出荷情報を定義したＴＸへのアクセス権を持つかどうかを照会する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を参照し、ＳＣ実行者が当該ＴＸに対するアクセス権を持つか確認する（ｓ１４６）。
上述の確認の結果、当該ＴＸに対するアクセス権がない場合（ｓ１４７：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１５６に進める。

他方、上述の確認の結果、当該ＴＸに対するアクセス権がある場合（ｓ１４７：ＹＥＳ）、ＳＣ実行／管理部２２０は、上述の出荷情報に定義された出荷者、型番、および、シリアル情報を元に、対応する製造情報を分散台帳２５０から検索する（ｓ１４８）。
この検索の結果、該当する製造情報が分散台帳２５０に存在しない場合（ｓ１４９：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１５６に進める。

他方、上述の検索の結果、該当する製造情報が分散台帳２５０に存在する場合（ｓ１４９：ＹＥＳ）、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者が当該製造情報を定義したＴＸへのアクセス権を持つかどうかを照会する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を参照し、ＳＣ実行者が当該ＴＸに対するアクセス権を持つか確認する（ｓ１５０）。
上述の確認の結果、当該ＴＸに対するアクセス権がない場合（ｓ１５１：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１５６に進める。

他方、上述の確認の結果、当該ＴＸに対するアクセス権がある場合（ｓ１５１：ＹＥＳ）、ＳＣ実行／管理部２２０は、上述の製造情報に定義された部品のリストについて、以下の処理（ｓ１５２〜ｓ１５５）を繰り返す。

この場合まず、ＳＣ実行／管理部２２０は、上述の製造情報に定義された部品の型番および伝票番号を元に、対応する入荷情報を分散台帳２５０から検索する（ｓ１５２）。

続いて、ＳＣ実行／管理部２２０は、該当する入荷情報について、メンバー管理ノード３００のメンバー管理部３１０に対し、ＳＣ実行者が当該入荷情報を定義したＴＸへのアクセス権を持つかどうかを照会する。この場合、メンバー管理部３１０は、アクセス権管理表３３０を参照し、ＳＣ実行者が当該ＴＸに対するアクセス権を持つか確認する（ｓ１５３）。

上述の確認の結果、当該ＴＸに対するアクセス権がない場合（ｓ１５４：ＮＯ）、ＳＣ実行／管理部２２０は、上述のリストに定義された次の部品の処理へ進む。
以降、ＳＣ実行／管理部２２０は、ｓ１４５〜ｓ１５４の処理を全ての部品について、これ以上辿れなくなるまで繰り返す（ｓ１５５）。

最後に、ＳＣ実行／管理部２２０は、本ＳＣの実行結果として、ｓ１４１〜ｓ１５５の一連の処理で取得した部品の出荷、入荷、製造の履歴情報を返し（ｓ１５６）、処理を終了する。

こうして履歴情報をユーザが得るための具体的なＧＵＩについて説明する。図１２は、部品トレースアプリ１６０の表示画面１２００の例である。この画面１２００の上部には、使用されている部品の履歴を検索したい製品の型番およびシリアル番号を入力するためのフォーム１２０１、１２０２と、「検索」ボタン１２０３が存在する。

ユーザが、自身の操作するノード（例：クライアントノード１００）にて、製品の型番およびシリアル番号を上述のフォーム１２０１、１２０２に入力し、「検索」ボタン１２０３を押下すると、上述の各フローが実行され、指定した製品の出荷、入荷、製造の履歴情報がトレース結果１２０５として画面下部に表示される。この表示情報は、部品トレースアプリ１６０が分散台帳ノード２００のトランザクション管理部２３０に対しＳＣを実行し、関数「履歴検索」を呼び出すことで取得できる。

ここで、図１３Ａ、図１３Ｂの各図を用いて、実施例１の処理が、ユーザの入力に対して、そのノードがどのように分散台帳２５０上にデータを作成し、また部品トレースアプリ１６０を介した部品の履歴検索を実施するか示す。

図１３Ａは、本実施例においてコンソーシアムに参加する事業者を示した模式図である。事業者は、自動車など直接消費者に渡る最終製品を作成する「セットメーカー」、セットメーカーの下請けとして、最終製品を構成する部品を製作する「部品メーカー（Ｔｉｅｒ１）」、Ｔｉｅｒ１の下請けとしてより細かい部品を製作する「部品メーカー（Ｔｉｅｒ２）」に分けられる。つまり、これら事業者が自動車製造に関するサプライチェーンを構成している。

図中では、セットメーカーとして「ＳＭ−１」、「ＳＭ−２」が、Ｔｉｅｒ１メーカーとして「Ｔ１−１」〜「Ｔ１−３」が、Ｔｉｅｒ２メーカーとして「Ｔ２−１」〜「Ｔ２−４」がそれぞれ存在する。また、図中の矢印は部品の納入における依存関係を示している。

一方、図１３Ｂは、図１〜図７で説明した、各ノードが持つ情報のやり取りの過程を示した模式図である。以下、Ｔｉｅｒ２メーカー「Ｔ２−２」が部品を出荷し、Ｔｉｅｒ１メーカー「Ｔ１−２」が当該部品を入荷し、別の部品を組み合わせて新たな部品を製造して出荷し、セットメーカー「ＳＭ−１」が上述の「Ｔ１−２」の製造した部品を入荷する
までの過程を説明する。なお、各処理の実行主体は、ノードであるとする。

まず「Ｔ２−２」は、型番「ＭＮＦ−１」、シリアル番号「１００１」で示される部品を出荷し、その情報を、ＥＤＩ業務アプリ１２０Ａを通じて取引履歴管理表１４０に登録する。その取引の伝票番号は「１０１」である。また、ＥＤＩ業務アプリ１２０Ａは、当該出荷情報をスマートコントラクト２６０の関数「出荷」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「１１」である。

次に、スマートコントラクトはメンバー管理ノード３００のメンバー管理部３１０を通じ、アクセス権管理表３３０を更新して、当該トランザクションに「Ｔ２−２」からのアクセス権を付与する。

次に「Ｔ１−２」は、型番「ＭＮＦ−１」、シリアル番号「１００１」で示される部品を入荷し、その情報を、ＥＤＩ業務アプリを通じて取引履歴管理表１３０に登録する。また、ＥＤＩ業務アプリは、当該出荷情報をスマートコントラクトの関数「入荷」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「２１」である。

次に、スマートコントラクトは図１０に示す処理を実施し、メンバー管理ノード３００のアクセス権管理表３３０を更新して、当該トランザクション（ＩＤ：２１）と、同じ台帳番号を持つ出荷履歴を記録したトランザクション（ＩＤ：１１）に「Ｔ１−２」からのアクセス権を付与する。

次に「Ｔ１−２」は、入荷時の伝票番号「１０１」で示される取引により入荷した、型番「ＭＮＦ−１」で示される部品を用いて、型番「ＭＮＦ−１１」、シリアル番号「１１００１」で示される製品を製造し、その情報を、製造業務アプリ１４０Ａを通じて製造履歴管理表１５０に登録する。

製造業務アプリ１４０Ａは、当該製造情報をスマートコントラクトの関数「製造」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「３１」である。

次に、スマートコントラクトはメンバー管理ノード３００のアクセス権管理表３３０を更新して、当該トランザクションに「Ｔ１−２」からのアクセス権を付与する。

次に「Ｔ１−２」は、型番「ＭＮＦ−１１」、シリアル番号「１１００１」で示される上述の製造した部品を出荷し、その情報を、ＥＤＩ業務アプリ１２０Ｂを通じて取引履歴管理表１３０に登録する。その取引の伝票番号は「２０１」である。また、ＥＤＩ業務アプリ１２０Ｂは、当該出荷情報をスマートコントラクトの関数「出荷」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「４１」である。

次に、スマートコントラクトはメンバー管理ノード３００のアクセス権管理表３３０を更新して、当該トランザクションに「Ｔ１−２」からのアクセス権を付与する。

次に「ＳＭ−１」は、型番「ＭＮＦ−１１」、シリアル番号「１１００１」で示される部品を入荷し、その情報を、ＥＤＩ業務アプリを通じて取引履歴管理表１３０に登録する。ＥＤＩ業務アプリは、当該出荷情報をスマートコントラクトの関数「入荷」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「５１」である。

次に、スマートコントラクトは図１０に示す処理を実施し、メンバー管理ノード３００のアクセス権管理表３３０を更新して、当該トランザクション（ＩＤ：５１）と、上述の出荷履歴に記載された伝票番号を持つ入荷履歴を記録したトランザクション（ＩＤ：４１）と、上述の出荷履歴に記載された型番およびシリアル番号を持つ製造履歴を記録したトランザクション（ＩＤ：３１）と、上述の製造履歴に記載された伝票番号を持つ入荷履歴を記録したトランザクション（ＩＤ：２１）と、上述の出荷履歴に記載された伝票番号を持つ入荷履歴を記録したトランザクション（ＩＤ：１１）に「ＳＭ−１」からのアクセス権を付与する。

次に「ＳＭ−１」は、入荷時の伝票番号「２０１」で示される取引により入荷した、型番「ＭＮＦ−１１」で示される部品を用いて、型番「ＭＮＦ−２１」、シリアル番号「１１１０１」で示される製品を製造し、その情報を、製造業務アプリ１４０Ｂを通じて製造履歴管理表１５０に登録する。製造業務アプリ１４０Ｂは、当該製造情報をスマートコントラクトの関数「製造」を呼び出し、ＴＸを実行することで分散台帳２５０に登録する。その際のトランザクションＩＤは「６１」である。

次に、スマートコントラクトはメンバー管理ノード３００のアクセス権管理表３３０を更新して、当該トランザクションに「ＳＭ−１」からのアクセス権を付与する。

以上の結果、分散台帳ノード２００におけるステート情報２８０の内部テーブルには、図５に示すレコードが、メンバー管理ノード３００のアクセス権管理表３３０には図７の１行目〜６行目に示すレコードが生成される。

以後のいずれかの時期において、「ＳＭ−１」は、型番「ＭＮＦ−２１」、シリアル番号「１１１０１」で示される製品に何らかの問題が発生した場合、当該製品を構成する部品の一覧と取引の履歴を、部品トレースアプリ１６０を用いて検索することとなる。

この場合、当該ユーザがノードにて検索を指示すると、当該ノードの部品トレースアプリ１６０が分散台帳ノード２００のトランザクション管理部２３０に対してＳＣを実行し、関数「履歴検索」を呼び出す。その結果、図１２に示すとおり、指定した製品の出荷、入荷、製造の履歴情報が画面下部に表示される。

以上で示したとおり、本発明を用いることで、コンソーシアム型分散台帳システムにおいて、台帳上に複数の事業者の販売・製造履歴といった業務情報を共存させる場合に、各事業者が最低限必要な情報のみにアクセスできるようアクセス制御できる。

その際、アクセス権付与のポリシーをＳＣの中に埋め込んで定義しておくことで、アクセス権付与のポリシーについて事業者間で合意を取った上で足並みを揃えて実行することが可能となる。また、不正にアクセス権を得ようとする悪意を持った事業者が存在する場合にも、分散台帳システムの合意アルゴリズムが保証する範囲で正常なアクセス権付与を維持可能となる。

−−−実施例２−−−
実施例２では、上述の実施例１にてメンバー管理ノード３００上に保持していたアクセス権管理表３３０に相当する情報を、分散台帳ノード２００の分散台帳２５０に保持する方式について説明する。

図１４に、実施例２で想定するアクセス権管理システム２０の構成例を模式的に示す。この場合の分散台帳ノード２００の分散台帳２５０上では、業務に関するスマートコント
ラクト２６０およびＳＣによるＴＸ結果を格納・管理すると共に、アクセス権管理用のスマートコントラクト２９０およびこのアクセス権管理用のスマートコントラクト２９０によるＴＸ結果を格納・管理する。そのデータ構造としては、実施例１同様、ＴＸの履歴をブロックチェーン２７０として、ＴＸの実行結果に基づくステート情報２８０をテーブル形式で保持することを想定する。
なお、その他の部分の構成はメンバー管理ノード３００がアクセス権管理表３３０を持たないことを除き、実施例１と同様である。
図１５Ａ、図１５Ｂ、および、図１６は、実施例２において分散台帳ノード２００の具備する分散台帳２５０に格納するデータ構造の一例である。

図１５は、分散台帳２５０上で管理するデータ構造の一つであるブロックチェーン２７０の例である。このブロックチェーン２７０は、一連のブロック２７０１〜２７０７の連なりで構成される。これら各ブロックは、それぞれ部品トレース、もしくはアクセス権管理ＳＣのデプロイ、実行、いずれかのＴＸ情報を含む。

このうちブロック２７０１は、部品トレースＳＣのデプロイＴＸを格納したブロックの一例である。本実施例のデプロイＴＸ２７３０は、実施例１と同様、スマートコントラクトを一意に識別するコントラクトＩＤと、当該スマートコントラクトの実体を含む。また、スマートコントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。

本実施例の部品トレースＳＣでは、関数名として「出荷」、「入荷」、「製造」、「履歴参照」の４つが定義されており、各関数のロジックが定義されている。具体的には、「出荷」、「入荷」、「製造」については「ロジックＸ」（図１７）が、「履歴参照」については「ロジックＹ」（図１８）が定義されている。

また、ブロック２７０２は、アクセス権管理ＳＣのデプロイＴＸを格納したブロックの一例である。本実施例のアクセス権管理ＳＣでは、関数名として「アクセス権付与」、「アクセス権参照」の２つが定義されており、各関数のロジックが定義されている。具体的には、「アクセス権付与」については「ロジックＶ」（図１９）が、「アクセス権参照」については「ロジックＷ」（図２０）が定義されている。

また、ブロック２７０４および２７０６は、アクセス権管理ＳＣの実行ＴＸを格納したブロックの一例である。本実施例の実行ＴＸ２７４０は、実施例１と同様、呼び出し対象となるスマートコントラクトのコントラクトＩＤ、呼び出し対象となるスマートコントラクトの関数名と入力する引数の情報を含む。

図１６は、実施例２における分散台帳２５０上で管理するステート情報２８０の一例である。本実施例では、アクセス権管理用コントラクトについても、ステート情報２８０でのデータ領域が用意されることとする。

この場合のステート情報２８０は、スマートコントラクトの識別子であるコントラクトＩＤ２８０１と、そのスマートコントラクトの実体２８０２と、ＳＣの実行結果を保持するための内部テーブル２８０３とを備える。ＴＸが実行される度にこの内部テーブル２８０３の内容が更新されることとなる。また、アクセス権管理用ＳＣが内部テーブル２８０３に保持するアクセス権データ２８０６０は、実施例１において図７で示したメンバー管理ノード３００の具備するアクセス権管理表３３０の内容と同等である。

続いて、実施例２におけるアクセス権管理方法のフロー例について説明する。図１７Ａ、図１７Ｂは、図１５で示した部品トレースＳＣの関数のうち、ＴＸ書き込み関数である
「出荷」、「入荷」、「製造」、の呼び出し時の内部処理の例を示すフローチャートである。

本実施例では、当該フローにおけるｓ１２２、ｓ１２５、ｓ１２８、および、ｓ１３０において、ＳＣ実行者にＴＸへのアクセス権を付与する際、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０を呼び出すのに代わって、アクセス権管理ＳＣの「アクセス権付与」関数を実行する。それ以外の部分は、実施例１において図１０で示した処理の内容と同等である。

図１８Ａ、図１８Ｂは、図１５で示した部品トレースＳＣの関数のうち、ＴＸ読み込み関数である「履歴検索」の呼び出し時の内部処理の例を示すフローチャートである。

本実施例では、ｓ１４３、ｓ１４６、ｓ１５０、ｓ１５３においてＳＣ実行者のＴＸへのアクセス権を参照する際、ＳＣ実行／管理部２２０は、メンバー管理ノード３００のメンバー管理部３１０を呼び出すのに代わって、アクセス権管理ＳＣの「アクセス権参照」関数を実行する。それ以外の部分は、実施例１において図１１で示した処理の内容と同等である。

図１９は、図１５で示したアクセス権管理ＳＣの関数のうち、上述のＴＸ書き込み関数である「アクセス権付与」の呼び出し時の内部処理の例を示すフローチャートである。

ＳＣ実行／管理部２２０は、合意形成済みのＴＸとして、アクセス権管理ＳＣ関数「アクセス権付与」の呼び出しを受け取る（ｓ１６０）と、当該ＳＣに定義された処理を実行する。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部２２０は、当該ＴＸの内容に基づき、本スマートコントラクトに関するステート情報２８０を更新する。この場合、ステート情報２８０の内部テーブル２８０３には、図１６に示したようにアクセス権データ２８０６０が格納されており、ＳＣ実行／管理部２２０は、指定されたＴＸのＩＤに応じた行にＳＣ実行者のＩＤを追加する。

次に、ＳＣ実行／管理部２２０は、ブロックチェーン２７０の末尾のブロックとして実行ＴＸを追加する（ｓ１６１）。その際、ＳＣ実行／管理部２２０は、前のブロックのハッシュ値とステート情報２８０から生成したハッシュ値、トランザクションＩＤを合わせて登録する。
最後に、ＳＣ実行／管理部２２０は、本ＳＣの実行結果（例：成功）を返し（ｓ１６２）、処理を終了する。

図２０は、図１５で示したアクセス権管理ＳＣの関数のうち、上述のＴＸ書き込み関数である「アクセス権参照」の呼び出し時の内部処理の例を示すフローチャートである。

この場合、ＳＣ実行／管理部２２０は、合意形成済みのＴＸとして、アクセス権管理ＳＣ関数「アクセス権参照」の呼び出しを受け取る（ｓ１７０）と、当該ＳＣに定義された処理を実行する。具体的な内部処理を以下に示す。

まず、ＳＣ実行／管理部２２０は、実行ＴＸに定義されたアクセス権参照対象のＴＸＩＤを元に、対応するアクセス権情報を分散台帳２５０から検索する（ｓ１７１）。
この検索の結果、該当するアクセス権情報が分散台帳２５０に存在しない場合（ｓ１７２：ＮＯ）、ＳＣ実行／管理部２２０は、処理をｓ１７６に進める。

他方、上述の検索の結果、該当する入荷情報が分散台帳２５０に存在する場合（ｓ１７２：ＹＥＳ）、ＳＣ実行／管理部２２０は、取得したレコードを参照し、ＳＣ実行者が当該ＴＸへのアクセス権を持つか確認する（ｓ１７３）。

上述の確認の結果、当該ＴＸに対するアクセス権がある場合（ｓ１７４：ＹＥＳ）、ＳＣ実行／管理部２２０は、本ＳＣの実行結果として「アクセス権あり」と返し（ｓ１７５）、処理を終了する。一方、上述の確認の結果、当該ＴＸに対するアクセス権がない場合（ｓ１７４：ＮＯ）、ＳＣ実行／管理部２２０は、本ＳＣの実行結果として「アクセス権なし」と返し（ｓ１７６）、処理を終了する。

以上で示したとおり、実施例２に記載の構成を採用することで、実施例１と同等の効果を得ることができる。なお、本実施例では部品トレースＳＣとアクセス権管理ＳＣを別個のＳＣとして定義したが、これらは一体のＳＣとして定義されていても良い。

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

こうした本実施形態によれば、コンソーシアム型分散台帳基盤の参加者が、例えば自身の製品のトレーサビリティを管理するのに必要なデータのみにアクセスできるよう、アクセス制御できることとなる。
すなわち、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のアクセス管理方法において、前記所定ノードが、前記データアクセスの権限管理に関する所定処理として、前記トランザクション各々について、当該トランザクションに対する前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無に基づいて前記分散台帳が格納するトランザクションに対するデータアクセスを制御する、としてもよい。

これによれば、ビジネスネットワークの参加者を管理する特定ノードによって、スマートコントラクトの定義内容に沿った、上述のデータアクセスの権限有無を効率的に特定し、参加ノードからのデータアクセスに対する制御を精度良く行うことが可能となる。ひいては、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能となる。

また、本実施形態のアクセス管理方法において、前記所定ノードが、前記データアクセスの権限管理に関する所定処理として、前記トランザクション各々について、当該トランザクションに対する前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無の情報を含むトランザクションを発行して分散台帳に格納し、当該権限有無に基づいて前記分散台帳が格納するトランザクションに対するデータアクセスを制御する、としてもよい。

これによれば、ビジネスネットワークの参加ノードによって、スマートコントラクトの定義内容に沿った、上述のデータアクセスの権限有無を分散台帳でセキュアに管理し、参加ノードからのデータアクセスに対する制御を精度良く行うことが可能となる。ひいては、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能となる。

また、本実施形態のアクセス管理方法において、前記所定ノードが、前記トランザクシ
ョンの内容が示す業務の種類に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する、としてもよい。

これによれば、例えば、サプライチェーンにおける出荷、入荷、製造といった各業務の種類に応じたスマートコントラクトに沿って、上述のデータアクセスの権限有無を効率的かつ精度良く特定し、参加ノードからのデータアクセスに対する制御を好適に行うことが可能となる。ひいては、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能となる。

また、本実施形態のアクセス管理方法において、前記所定ノードが、前記データアクセスの権限管理に関する所定処理として、前記分散台帳に格納されたトランザクション、および、前記分散台帳において前記トランザクションと所定の関係にある他のトランザクション、の各々について、前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無に基づいて該当トランザクションに対するデータアクセスを制御する、としてもよい。

これによれば、分散台帳に格納されたトランザクションにおける、例えば、サプライチェーンにおけるバイヤーやサプライヤーの各間の関係性に応じて定まる相手方への開示可否、すなわちデータアクセスの権限有無を的確に踏まえ、参加ノードからのデータアクセスに対する制御を精度良く行うことが可能となる。ひいては、コンソーシアム型分散台帳基盤の参加者による、分散台帳におけるデータアクセスの権限を適宜に管理可能となる。

１ ネットワーク
１０ 情報処理装置
１１ 記憶装置
１２ プログラム
１３ メモリ
１４ 演算装置
１５ 入力装置
１６ 出力装置
１７ 通信装置
２０ アクセス権管理システム
１００ クライアントノード
１１０ トランザクション発行部
１２０ ＥＤＩ業務アプリ
１３０ 取引履歴管理表
１４０ 製造業務アプリ
１５０ 製造履歴管理表
１６０ 部品トレースアプリ
２００ 分散台帳ノード
２１０ コンセンサス管理部
２２０ スマートコントラクト実行／管理部
２３０ トランザクション管理部
２４０ トランザクション発行部
２５０ 分散台帳
２６０ スマートコントラクト
２７０ ブロックチェーン
２８０ ステート情報
３００ メンバー管理ノード
３１０ メンバー管理部
３２０ メンバー管理表
３３０ アクセス権管理表

Claims (7)

1. 所定事業者によるビジネスネットワークを構成する分散台帳システムにおいて、少なくともいずれかの所定ノードが、
   所定処理の実行に伴い発行され、分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する、
   ことを特徴とするアクセス権管理方法。
2. 前記所定ノードが、
   前記データアクセスの権限管理に関する所定処理として、前記トランザクション各々について、当該トランザクションに対する前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無に基づいて前記分散台帳が格納するトランザクションに対するデータアクセスを制御する、
   ことを特徴とする請求項１に記載のアクセス権管理方法。
3. 前記所定ノードが、
   前記データアクセスの権限管理に関する所定処理として、前記トランザクション各々について、当該トランザクションに対する前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無の情報を含むトランザクションを発行して分散台帳に格納し、当該権限有無に基づいて前記分散台帳が格納するトランザクションに対するデータアクセスを制御する、
   ことを特徴とする請求項１に記載のアクセス権管理方法。
4. 前記所定ノードが、
   前記トランザクションの内容が示す業務の種類に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する、
   ことを特徴とする請求項１に記載のアクセス権管理方法。
5. 前記所定ノードが、
   前記データアクセスの権限管理に関する所定処理として、前記分散台帳に格納されたトランザクション、および、前記分散台帳において前記トランザクションと所定の関係にある他のトランザクション、の各々について、前記参加者のノードによるデータアクセスの権限有無を、前記スマートコントラクトの実行結果に基づき特定し、当該権限有無に基づいて該当トランザクションに対するデータアクセスを制御する、
   ことを特徴とする請求項１に記載のアクセス権管理方法。
6. 所定事業者によるビジネスネットワークを構成する分散台帳システムであって、
   所定処理の実行に伴い発行されたトランザクションを格納する分散台帳を少なくとも保持する記憶装置と、
   前記分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する演算装置と、
   を備えた複数の情報処理装置を含むことを特徴とするアクセス権管理システム。
7. 所定事業者によるビジネスネットワークを構成する分散台帳システムの、少なくともい
   ずれかの所定ノードであって、
   所定処理の実行に伴い発行されたトランザクションを格納する分散台帳を少なくとも保持する記憶装置と、
   前記分散台帳に格納されたトランザクションの内容に応じて、所定のスマートコントラクトを実行し、当該スマートコントラクトの実行結果に基づき、前記ビジネスネットワークにおける参加者の所定ノードによる分散台帳でのデータアクセスの権限管理に関する所定処理を実行する演算装置と、
   を備えることを特徴とするアクセス権管理装置。