JP2020039061A

JP2020039061A - 電子取引装置、電子取引検証装置、及び電子取引方法

Info

Publication number: JP2020039061A
Application number: JP2018165674A
Authority: JP
Inventors: 悠介新井; Yusuke Arai; 竜也佐藤; Tatsuya Sato; 洋輔肥村; Yosuke Himura
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2018-09-05
Filing date: 2018-09-05
Publication date: 2020-03-12
Anticipated expiration: 2038-09-05
Also published as: US11423409B2; JP7051648B2; EP3621013A1; US20200074468A1

Abstract

【課題】トランザクションの処理性能を低下させることなく安全に電子取引を行う電子取引装置、電子取引検証装置及び電子取引方法の提供。【解決手段】電子取引システムにおいて、電子取引装置（クライアントノード１００及び承認ノード２００）は、所定の取引における複数の関係者間の関係性を示した情報である参加者関係マップＴ１００を記憶している関係性マップ記憶部１０１と、取引の成立に必要な当該取引の関係者に関する要件であるポリシー要件Ｔ３００を記憶しているポリシー要件記憶部１０３と、所定の取引内容を保持しているトランザクションデータが示す取引の承認者に関する条件である合意ポリシーＰ１００を、関係性マップ及びポリシー要件に基づき生成する合意ポリシー算出部１３３と、生成した合意ポリシーに基づき特定された取引の承認者に対応づけられている所定の情報処理装置に、所定の承認依頼を送信する承認依頼送信部１３５とを備える。【選択図】図４

Description

本発明は、電子取引装置、電子取引検証装置、及び電子取引方法に関する。

従来、金融機関や政府等の中央集権機関を経由して実施されてきた関係者間の取引を、関係者間のＰ２Ｐ（Peer to Peer）による直接的な取引に代替するための技術として、いわゆる分散台帳技術（いわゆる、ブロックチェーン（BC: Block chain）が活用されてい
る（例えば、仮想通貨の一種であるBitcoinに関する非特許文献１）。分散台帳技術は、
信頼できるデータの管理及び共有並びに、契約に基づく取引の執行及び管理を行う仕組みとして、金融分野やＩｏＴ（Internet of Thing）等、幅広い分野での応用が検討されて
いる。例えば、非特許文献１に記載のBitcoinでは、Ｐ２Ｐネットワーク上で取引データ
（以下、トランザクションあるいはTXとも称する。）をマイナーと呼ばれるノードが正当性を判定した後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行っている。確定されたトランザクションは、１つのブロックにまとめられ、ブロックチェーンの形式で分散台帳に記録される。

分散台帳技術は、その構成に応じて、いくつかの種類に分類することが可能である。その分類としては、不特定多数のノード間で分散台帳ネットワークが構成される「パブリック型（Public）分散台帳」、複数の特定組織でコンソーシアムを形成し、それぞれの組織が所有するノード間で分散台帳ネットワークが構成される「コンソーシアム型（Consortium）分散台帳」、１つの特定組織内でのノード間で分散台帳ネットワークが構成される「プライベート型（Private）分散台帳」が挙げられる。特に、エンタープライズ用途等と
して提案されているコンソーシアム型分散台帳により、組織間にまたがるビジネスプロセスを効率化することが期待されている。

近年では、上記のBitcoinで実装されたBCをベースにして、BCおよび分散台帳に関して
様々な派生技術が提案され、進化を続けている。現状のBCの主な特徴としては、（１）BCネットワーク上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の分散台帳を共有することにより、参加者全員での取引の確認を可能とすることが挙げられる。また、分散台帳技術を非特許文献１のような仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくロジックも管理できるようになってきている。このロジックはスマートコントラクトと呼ばれる。

分散型台帳による取引を実現するための技術として、複数の者の間で取引（トランザクション）を共有するための合意プロセスを定める合意形成アルゴリズムがある。合意形成アルゴリズムは、例えば、ある取引参加者のノード（参加ノード）から発行されたトランザクションを別の参加ノードが承認するという合意形成を経ることで、複数の参加者間での信頼できる取引を実現する。例えば、特許文献１には、プルーフオブワークという合意形成アルゴリズムを用いるパブリック型分散台帳を対象に、ノードの信頼度を過去の取引データから算出し、ブロック生成権を強化する手法が開示されている。

コンソーシアム型分散台帳基盤に用いられる代表的な合意形成アルゴリズムとしては、参加ノード全体の多数決的なプロセスによってトランザクションの合意を取るPractical
Byzantine Fault Tolerance（PBFT）方式が挙げられる。このアルゴリズムではトランザ
クションを全ノードに送り、各ノードから承認を得る多数決的な方法でトランザクションの合意を行う。この手法は全ノードにトランザクションを送る必要があるため、ノード数が増えるとトランザクション性能を表す指標であるTPS（トランザクション/Sec）が低下
してしまうという問題がある。それに対して近年ではトランザクション性能を向上させるために、全ノードではなく、一部ノードからの承認によってトランザクションを受け入れる新たな合意形成アルゴリズムが登場してきている。

このような合意形成アルゴリズムの適用例としては、例えば非特許文献２に開示されている合意形成アルゴリズムでは、トランザクションを受け取った参加ノード（以下、クライアントノードと呼ぶ）が、他の参加ノードのうち一部の参加ノード（以下、承認ノードと呼ぶ。非特許文献２ではEndorserとも呼ばれる。）にのみトランザクションを送信し、承認を受けた後はさらに他の参加ノードであるブロック配信ノード（非特許文献２ではOrdererとも呼ばれる）に承認情報が付与されたトランザクションを送信する。ブロック配
信ノードは、トランザクションの順序及び整列、又は合意の可否の判断等を行い、承認ノード以外の参加ノードを含めた全ての参加ノードへ、トランザクションをまとめたブロックの配信を行う。他の参加ノードが承認後のトランザクションの結果（ブロック）を受信することで、承認処理を不要とすることができる。

このような、特定のノード（承認ノード）のみが承認を行うコンソーシアム型の合意形成アルゴリズムにおいては、ノードの選定や合意のための基準の情報が必要であり、そのような情報を以下では合意ポリシーという。

この合意ポリシーには、その設計に欠陥があると不正なトランザクションが行われやすいという問題がある。例えば、合意ポリシーの設計に欠陥がある場合、クライアントノードが承認ノードと結託することにより、通常であれば承認ノードが承認を拒絶するような不正なトランザクションをクライアントノードが発行し、承認ノードがこれを承認してしまうことができる。これにより、不正なトランザクションを有するブロックデータが、全参加ノードに配信されてしまう。

このような不正は、合意ポリシーの設計自体の問題であり、分散台帳技術におけるハッシュチェーンの耐改竄性等とは無関係に発生しうる。そのため、合意ポリシーの設計は分散台帳技術の信頼性に大きく影響する。

特開２０１７−９１１４９号公報

"A Peer-to-Peer Electronic Cash System"、［online］、［平成３０年２月２７日検索］、インターネット（URL: https://bitcoin.org/bitcoin.pdf） "Hyperledger Fabric"、［online］、［平成３０年２月２７日検索］、インターネット（URL: http://hyperledger-fabric.readthedocs.io/en/latest/）

この点、特許文献１の手法によれば、ノード（参加者）に関する情報を得ることでノード単体（言い換えると単一組織）としての信頼度を推定することはできるが、ノード間の関係性は考慮されていないため、ノード間の結託の抑止には効果的ではない。

そこで、ノード間による結託を防ぐためには承認ノード数を多くすることが考えられるが、このようにすると処理負荷がかかるため取引の迅速性に影響を与え、トランザクション性能が低下するおそれがある。

本発明は以上のような現状に鑑みてなされたもので、その目的は、トランザクションの処理性能を低下させることなく安全に電子取引を行うことが可能な電子取引装置、電子取引検証装置、及び電子取引方法を提供することにある。

上記課題を解決するための、本発明の一つは、電子取引装置であって、所定の取引における複数の関係者間の関係性を示した情報である関係性マップを記憶している関係性マップ記憶部と、前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶しているポリシー要件記憶部と、所定の取引内容を保持しているトランザクションデータが示す取引の、承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成する合意ポリシー算出部と、前記生成した合意ポリシーに基づき特定された取引の承認者に対応づけられている、所定の情報処理装置に、所定の承認依頼を送信する承認依頼送信部とを備える。

本発明によれば、トランザクションの処理性能を低下させることなく安全に電子取引を行うことができる。

本実施形態に係る電子取引システム１の基本的な構成の一例を説明する図である。本実施形態に係る電子取引システム１で行われる処理の概要を説明する図である。各ノードが備えるハードウェアの一例を説明する図である。クライアントノード及び承認ノードが備える機能の一例を示す図である。参加者関係性マップの一例を示す図である。ポリシー要件の一例を示す図である。合意ポリシーの一例を示す図である。コンソーシアム参加時審査情報の一例を示す図である。ブロック配信ノードが備える機能の一例を示す図である。合意形成処理の一例を説明するシーケンス図である。トランザクションデータの一例を示す図である。クライアントノードが生成する承認済トランザクションデータの一例を示す図である。ブロックチェーンデータの一例を示す図である。クライアントノードが行う合意ポリシー算出処理の一例を説明するフロー図である。参加者関係性計算処理の一例を示すフロー図である。更新トランザクションの一例を示す図である。

以下、本発明の実施の形態について図面を参照しつつ説明する。
＜＜システム構成＞＞
図１は、本実施形態に係る電子取引システム１の基本的な構成の一例を説明する図である。電子取引システム１は、インターネット、ＬＡＮ、ＷＡＮ等の有線又は無線の通信ネットワーク５を介して互いに接続された、複数の電子取引装置１０、及び１以上の電子取
引検証装置２０（以下、ブロック配信ノードともいう。）を含んで構成されている。電子取引システム１は、例えば、金融取引を行う銀行グループ等、複数の参加者から構成される団体（コンソーシアム）に対して導入される。本実施形態の電子取引システム１は、いわゆるブロックチェーン技術（分散台帳技術）のうち、コンソーシアム型（Consortium）分散台帳技術を用いて電子取引を行う情報処理システムであり、各電子取引装置１０は、他の電子取引装置１０と随時電子取引（トランザクション）を実行する。電子取引装置１０は、次述するように、クライアントノード及び承認ノードがある。

図２は、本実施形態に係る電子取引システム１で行われる処理の概要を説明する図である。同図に示すように、本実施形態の電子取引システム１では、クライアントノード１００から承認ノード２００への、所定の取引に関するトランザクションデータＴ２００の承認依頼処理（Ｓ３）と、ブロック配信ノード３００によるトランザクションデータＴ２００の承認処理（Ｓ５）と、承認後のトランザクションに関するブロックデータの配信処理（Ｓ９）等により構成される合意形成処理、及び、各参加者（ノード）間の関係性を特定する所定の計算を行う参加者関係性計算処理（Ｓ２０）が実行される。

具体的には、各ノードは、各ノード間の関係性（参加者間の関係性）の情報（参加者関係性マップＴ１００）を共有しており、クライアントノード１００は、取引（トランザクションデータＴ２００）に対する承認依頼を発行する際に、参加者関係性マップＴ１００と、取引の成立に必要な当該取引の関係者に関する要件であるポリシー要件Ｔ３００とに基づき、取引の承認者に関する条件である合意ポリシーＰ１００を算出することにより、自身と関係性の弱いノード等を承認ノード２００として決定する。そしてクライアントノード１００は、決定した承認ノード２００に承認依頼を発行し（Ｓ３）、承認ノード２００が承認を行うことにより、取引に関する合意形成が行われる。

その後、承認情報を含むトランザクションデータＴ２００はブロック配信ノード３００に送信され（Ｓ５）、ブロック配信ノード３００は改めてこのトランザクションデータＴ２００が合意ポリシーＰ１００を満たしているか否かを検証した上で、トランザクションデータＴ２００に関するブロックチェーンデータを生成して他の各ノード（各クライアントノード１００及び各承認ノード２００等）に送信する（Ｓ９）。各ノードは、受信したブロックチェーンデータを分散台帳Ｔ２５０にて共有する。

また、本実施形態の電子取引システム１では、クライアントノード１００及び承認ノード２００のそれぞれが、所定のタイミングで参加者関係性マップＴ１００を生成する参加者関係性計算処理Ｓ２０を実行する。参加者関係性計算処理Ｓ２０を実行したクライアントノード１００又は承認ノード２００は、生成した参加者関係性マップＴ１００を他のノードに送信することによりこれを共有する。

以上のように、電子取引システム１では、トランザクションデータＴ２００に関するブロックチェーンデータと、参加者関係性マップＴ１００に関するブロックチェーンデータとが各ノード間で共有されている。

なお、クライアントノード１００、承認ノード２００、及びブロック配信ノード３００のこれらの機能は、それぞれの電子取引装置１０及び電子取引検証装置２０が共通して備えていてもよいし、各電子取引装置１０又は電子取引検証装置２０ごとに割り当てられていてもよい。本実施形態では、トランザクションの発行主体が取引ごとに変わりうるため、クライアントノード１００及び承認ノード２００は互いに同一の機能を有するものとする。また、コンソーシアムの各参加者に対しては複数のノードを割り当てることができるが、本実施形態では各参加者に対して１のノードが割り当てられるものとする。

なお、図３は、各ノードが備えるハードウェアの一例を説明する図である。各ノードは、ＣＰＵ（Central Processing Unit）などの処理装置４１（プロセッサ）と、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の主記憶装置４２と、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の外部記憶装置からなる補助記憶装
置４３と、キーボード、マウス、タッチパネル等からなる入力装置４４と、モニタ（ディスプレイ）などからなる出力装置４５と、他のノードと通信する通信装置４６とを備え、これらは内部バス等により接続される。なお、各ノードは、物理的な計算機であっても、物理的な計算機上で動作する仮想的な計算機であってもよい。

＜＜機能＞＞
次に、電子取引システム１の各ノードが備える機能について説明する。

＜クライアントノード及び承認ノード＞
図４は、クライアントノード１００及び承認ノード２００が備える機能の一例を示す図である。クライアントノード１００及び承認ノード２００は、関係性マップ記憶部１０１と、ポリシー要件記憶部１０３と、参加者の電子署名及び認証情報を記憶しているメンバー管理部１０５と、参加者関係性マップＴ１００を算出する関係性マップ算出部１０７と、参加者関係性マップＴ１００を他のノードと共有する関係性マップ共有部１０９と、トランザクション発行部１３１と、合意ポリシー算出部１３３と、合意ポリシーＰ１００に基づき作成された、トランザクションに係る承認依頼をトランザクションデータと共に承認ノード２００に送信する承認依頼送信部１３５と、他のノードから、承認依頼を含むトランザクションデータを受信する承認依頼受信部１５１と、受信したトランザクションデータに基づいてスマートコントラクトを実行するスマートコントラクト実行部１５３と、承認依頼に対応する承認情報を付与したトランザクションデータを送信する承認情報送信部１５７と、ブロック受信部１７１と、合意ポリシー算出部１７２を有する合意ポリシー検証部１７３と、ブロック記憶部１７５とを備える。

関係性マップ記憶部１０１は、所定の取引における複数の関係者間の関係性を示した情報である関係性マップ（参加者関係性マップＴ１００）を記憶している。

参加者関係性マップＴ１００は、参加者間の関係を、参加者の所定の属性に関して記憶した情報である。本実施形態では、参加者関係性マップＴ１００は、所定の取引の関係者の業種もしくは役割、又は、当該関係者間の資本関係もしくは取引関係のうち少なくともいずれかの情報を含むものとするが、これに限られるわけではない。

ポリシー要件記憶部１０３は、取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件Ｔ３００を記憶している。
なお、ポリシー要件Ｔ３００は、事前に各コンソーシアムにつき１以上定められた情報である。

関係性マップ算出部１０７は、前記の所定の取引の関係者の属性の情報、又は、過去に取得したトランザクションデータのうち少なくともいずれかに基づき、関係性マップ（参加者関係性マップＴ１００）を生成又は更新する。

トランザクション発行部１３１は、トランザクションデータを生成する（発行する）。

合意ポリシー算出部１３３は、所定の取引内容を保持しているトランザクションデータが示す取引の、承認者に関する条件である合意ポリシーＰ１００を、関係性マップ（参加者関係性マップＴ１００）及びポリシー要件Ｔ３００に基づき生成する。

具体的には、例えば、合意ポリシー算出部１３３は、関係性マップから、トランザクションデータが示す取引について、関係性を示す評価値（以下、関係値ともいう。）が所定条件を満たす関係者を抽出し、抽出した関係者及びポリシー要件Ｔ３００に基づき、合意ポリシーＰ１００を生成する。

なお、所定条件とは、例えば、所定値以下、最小値等である。

また、合意ポリシー算出部１３３は、トランザクションデータから取引の関係者を抽出し、抽出した関係者から、トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を特定し、特定した関係者を前記合意ポリシーが示す関係者に含める。

承認依頼送信部１３５は、合意ポリシー算出部１３３が生成した合意ポリシーＰ１００に基づき特定された取引の承認者に対応づけられた、所定の情報処理装置（すなわち、承認ノード２００）に、所定の承認依頼を送信する。

ブロック受信部１７１は、少なくとも１台以上の前記電子取引装置（クライアントノード１００又は承認ノード２００）が送信した、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを含むブロックデータ（ブロックチェーンデータＴ２６０）を、所定の情報処理装置（配信ノード３００）から受信する。

合意ポリシー検証部１７３は、合意ポリシー算出部１７２を備える。合意ポリシー算出部１７２は、クライアントノード１００と同様の処理により、合意ポリシーＰ１００と同様の合意ポリシーを生成する。
すなわち、合意ポリシー検証部１７３は、ブロック受信部１７１が前記受信したブロックデータ（ブロックチェーンデータＴ２６０）におけるトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する。

ブロック記憶部１７５は、前記条件を満たしていると判定した場合には、ブロック受信部１７１が受信したブロックチェーンデータＴ２６０を分散台帳Ｔ２５０に記録する。

また、図４に示すように、クライアントノード１００は、コンソーシアム参加時審査情報Ｔ４００と、分散台帳Ｔ２５０とを記憶している。分散台帳Ｔ２５０は、ブロックチェーンデータＴ２６０と、現在の（最新の）トランザクションデータＴ２００を含む情報であるステート情報Ｔ２７０とを含む情報を記憶している。

ここで、クライアントノード１００（又は承認ノード２００）が記憶している各情報の詳細を説明する。
（参加者関係マップ）
図５は、参加者関係性マップＴ１００の一例を示す図である。参加者関係性マップＴ１００は、各参加者間の関係性の強さに関する情報を記憶している（同図の例では、第１参加者リストＴ１０２及び第２参加者リストＴ１０３の行列によるマトリックスにより記憶している）。この関係性は、本実施形態では、０以上１以下の評価値（関係値）にて表すものとし、その値が低いほど関係性は弱く、関係値が高いほど関係性は強いものとする。なお、各関係値は正規化されている。正規化は、例えば、上記マトリックスにおいて対角線部分を除いた各行列の要素の二乗和が１になるように各要素を共通の数で除することにより行われる。

このように、本実施形態の参加者関係性マップＴ１００は、関係者の業種もしくは役割、又は資本関係もしくは取引関係の情報を有しているので、取引に際して結託するおそれのある参加者を適切に抽出することができる。

（ポリシー要件情報）
次に、図６は、ポリシー要件Ｔ３００の一例を示す図である。ポリシー要件Ｔ３００は、承認ノードの決定方法（ポリシー）について規定した情報である。本実施形態では、ポリシー要件Ｔ３００は、指定したｎノードのうちxノードから承認を得た場合に合意形成
がなされる方式（x-of-n方式）規定しているものとする。すなわち、ポリシー要件Ｔ３００は、ポリシー要件を構成する各構成要件ごとに割り当てられた識別子が格納される要件Ｔ３０１、要件Ｔ３０１の項目が示すポリシー要件の構成要件の内容が格納されるキーＴ３０２、及び、キーＴ３０２の項目の構成要件に関するパラメータが格納されるバリューＴ３０３の各項目を有する、１以上のレコードで構成される。

本実施形態では、ポリシー要件には、ポリシー要件全般のルールを規定するポリシー条件式、必須ノード枠、必須ノードリスト、第三者ノード枠、及び、第三者ノード指定条件が含まれる。

ポリシー条件式は、クライアントノード１００が常に承認を求める承認ノードである必須ノード（例えば、参加者のうち、監査機関又は重要なステークホルダーが管理するノード）と、トランザクション等によって承認を求めるか否かが異なる承認ノードである第三者ノード（例えば、トランザクションの当事者と関係性の弱い参加者）との組み合わせに関する条件式である。

必須ノード枠は、必須ノードの必要数である。必須ノードリストは、必須ノードとして選択可能なノードのリストである。第三者ノード枠は、第三者ノードの必要数である。第三者ノード指定条件は、第三者ノードに関する制約条件である。

例えば、図６においてレコードＴ３０４は、ポリシー条件式としてx-of-n条件式を規定している。レコードＴ３０５は、必須ノード枠を規定している。レコードＴ３０６は、必須ノードのリストを規定している。レコードＴ３０７は、第三者ノード枠を規定している。レコードＴ３０８は、第三者ノード指定条件として、関係値が最も低いノードを第三者ノードとして１つ選択しなければならないことを規定している。第三者ノード指定条件には、例えば、関係性が最も弱い参加者をその関係性が弱い順から第三者ノードとしてｘ個指定する「ｍｉｎ＿ｘ条件」、関係値を示す値（関係値）が閾値ｔ以下の参加者を第三者ノードとして指定する「閾値条件」等がある。

なお、本実施形態のポリシー要件Ｔ３００はx-of-n方式によるが、他の方式でもよい。例えば、必須ノードのみを規定し、その他のノードを全て第三者ノードとして規定してもよい。また、必須ノード及び第三者ノード以外の他の種類のノードを規定してもよい。また、これらのノードについては組織のロールや具体的な組織の指定を組み合わせてもよい。

また、ポリシー要件Ｔ３００のデータの表現形式は任意であり、例えば、ポリシー条件式として単純なＡＮＤ／ＯＲ条件を用いてもよい。

（合意ポリシー）
図７は、合意ポリシーＰ１００の一例を示す図である。合意ポリシーＰ１００は、承認ノードの種別（必須ノード、又は第三者ノード）が格納されるノード種別Ｐ１０１、ノード種別Ｐ１０１の項目が示すノードの枠（必要数）が格納される枠Ｐ１０２、及び、ノー
ド種別Ｐ１０１の項目が示す種別のノードのリストが格納される組織名Ｐ１０３の各項目を有する、１以上のレコードで構成される。

同図の例では、トランザクションデータＴ２００を発行したノードに対する関係値が最も低いノード（参加者org2）が第三者ノードとして追加されている。

（コンソーシアム参加時審査情報）
図８は、コンソーシアム参加時審査情報Ｔ４００の一例を示す図である。コンソーシアム参加時審査情報Ｔ４００は、各参加者の属性の情報である参加者情報Ｔ４１０、及び、参加者間の関係性の情報である参加者関係性情報Ｔ４２０を含む。

参加者情報Ｔ４１０は、参加者を特定する情報（例えば、組織の名称）が格納される組織名Ｔ４１１、組織名Ｔ４１１の項目で特定される参加者の業種に関する情報が格納される業種Ｔ４１２、及び、組織名Ｔ４１１の項目で特定される参加者のコンソーシアムでの役割に関する情報が格納される役割Ｔ４１３の各項目を有する、１以上のレコードで構成される。

参加者関係性情報Ｔ４２０は、参加者間の関係性のそれぞれについて割り当てられた識別子が格納される関係情報Ｔ４２１、関係情報Ｔ４２１の項目が示す関係性を構成する参加者のリストが格納される組織Ｔ４２２、関係情報Ｔ４２１の項目が示す関係性の内容（例えば、資本提携や親子会社などの関係性）に関する情報が格納される関係性Ｔ４２３、及び、関係情報Ｔ４２１の項目が示す関係性の強さの情報が格納される程度Ｔ４２４の各項目を有する１以上のレコードで構成される。

なお、組織Ｔ４２２の項目において、３組織間（Ａ，Ｂ，Ｃ）の関係性を記録する場合には例えばレコードを３つ追加し、各レコードにそれぞれ、組織Ａ―Ｂ間、Ｂ―Ｃ間、及びＣ―Ａ間の関係性の情報を記録する。

＜ブロック配信ノード＞
次に、図９は、ブロック配信ノード３００が備える機能の一例を示す図である。ブロック配信ノード３００は、関係性マップ記憶部３０１と、ポリシー要件記憶部３０３と、承認済トランザクション受信部３１１と、合意ポリシーＰ１００を算出する合意ポリシー算出部３１２を有する合意ポリシー検証部３１３と、ブロック生成部３１５とを備える。

関係性マップ記憶部３０１は、クライアントノード１００（又は承認ノード２００）の関係性マップ記憶部１０１と同様であり、所定の取引における複数の関係者間の関係性を示した情報である関係性マップ（参加者関係性マップＴ１００）を記憶している。

ポリシー要件記憶部３０３は、クライアントノード１００（又は承認ノード２００）のポリシー要件記憶部１０３と同様であり、取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件Ｔ３００を記憶している。

承認済トランザクション受信部３１１は、所定の情報処理装置（例えば、クライアントノード１００又は承認ノード２００）から、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを受信する。

合意ポリシー検証部３１３は、承認済トランザクション受信部３１１が受信したトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、関係性マップ（参加者関係性マップＴ１００）及びポリシー要件（ポリシー要件Ｔ３００）に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関
係者が満たしているか否かを判定する。
すなわち、合意ポリシー検証部３１３は、合意ポリシー算出部３１２を備え、合意ポリシー算出部３１２は、クライアントノード１００と同様の処理により、合意ポリシーＰ１００と同様の合意ポリシーを生成する。

ブロック生成部３１５は、合意ポリシー検証部３１３が前記条件を満たしていると判定した場合に、承認済トランザクション受信部３１１が受信したトランザクションデータを含むブロックデータ（ブロックチェーンデータＴ２６０）を生成する。

そして、ブロック生成部３１５は、生成したブロックチェーンデータＴ２６０を、分散台帳Ｔ２５０を備える他のノード（クライアントノード１００及び承認ノード２００等）に送信（配信）する。

以上に説明した各ノードの機能は、各ノードのハードウェアによって、もしくは、各ノードの処理装置４１が主記憶装置４２や補助記憶装置４３に記憶されているプログラムを読み出して実行することによって実現される。また、これらのプログラムは、例えば、二次記憶デバイスや不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤなどの記憶デバイス、又は、ＩＣカード、ＳＤカード、ＤＶＤなどの、各ノードで読み取り可能な非一時的データ記憶媒体に格納される。

＜＜処理＞＞
次に、電子取引システム１において行われる処理について説明する。

まず、合意形成処理について説明する。
＜合意形成処理＞
図１０は、合意形成処理の一例を説明するシーケンス図である。合意形成処理は、例えば、トランザクションに関するクライアントノード１００への所定の情報の入力や、クライアントノード１００に予め組み込まれているトランザクションの自動実行プログラム等によって開始される。

まず、クライアントノード１００のトランザクション発行部１３１は、所定のトランザクション（以下、対象トランザクションという。例えば、金融取引。）に関するトランザクションデータＴ２００を生成する（ｓ１）。

（トランザクションデータ）
ここで、図１１は、トランザクションデータＴ２００の一例を示す図である。トランザクションデータＴ２００は、トランザクションの識別子であるトランザクション識別子Ｔ２０１、当該トランザクションの発行者（コンソーシアムにおける参加者のいずれか）である発行者Ｔ２０２、当該トランザクションに係るスマートコントラクトにおけるスマートコントラクト関数である関数Ｔ２０３、及び、当該スマートコントラクト関数における引数であるスマートコントラクト引数Ｔ２０４の各項目の情報を含んで構成されている。本実施形態では、スマートコントラクト引数Ｔ２０４は、スマートコントラクト関数ごとに異なる配列情報である。

図１１の例では、発行者org1によって送金スマートコントラクト関数Moveが呼びだされ、参加者org1から参加者org2に「１００」送金されている。

図１０に戻り、合意ポリシー算出部１３３は、ｓ１で生成したトランザクションデータＴ２００（以下、対象トランザクションデータという。）に対する合意ポリシーＰ１００を算出する処理（以下、合意ポリシー算出処理という。）を実行する（ｓ２）。この処理
の詳細は後述する。

そして、承認依頼送信部１３５は、合意ポリシー算出処理により決定した各承認ノード２００に対して、対象トランザクションに対する承認依頼が付帯した対象トランザクションデータ（以下、承認依頼トランザクションデータという。）を送信する（ｓ３）。

承認依頼トランザクションデータの送信先の各承認ノード２００の承認依頼受信部１５１は、当該承認依頼トランザクションデータを受信すると、スマートコントラクト実行部１５３が、承認依頼トランザクションデータにおける対象トランザクションデータの検証を行う（ｓ４）。

検証により、対象トランザクションデータの正当性が確認された場合、各承認ノード２００のトランザクション承認部１５５は、対象トランザクションデータに自身の承認情報（例えば、電子署名）を付与したトランザクションデータをクライアントノード１００に返信する（ｓ５）。なお、この検証により対象トランザクションデータの正当性が確認できなかった場合は、例えば、トランザクション承認部１５５は、クライアントノード１００に対する応答を行わないか、又は、所定の警告情報をクライアントノード１００に送信する。

クライアントノード１００の承認依頼送信部１３５は、承認情報が付与されたトランザクションデータを各承認ノード２００から受信すると、これらの承認情報をまとめた新たなトランザクションデータ（以下、承認済トランザクションデータという）を生成する。

（承認済トランザクションデータ）
ここで、図１２は、クライアントノード１００が生成する承認済トランザクションデータＴ２１０の一例を示す図である。承認済トランザクションデータＴ２１０は、トランザクションデータＴ２００に、承認ノード情報Ｔ２１１が付与された情報である。この承認ノード情報Ｔ２１１は配列形式であり、承認ノードの数によって要素の数が異なる。各要素は、承認ノードの識別子（例えば、参加者名）の情報に当該承認ノードによる電子署名が付与されている。同図の例では、承認ノードorg2、org3、org4からの承認が得られている。

図１０に戻り、クライアントノード１００の承認依頼送信部１３５は、承認済トランザクションデータＴ２１０の承認情報を参照し、それらの承認情報が合意ポリシーＰ１００を満たしているか否かを判定する（ｓ５ａ）。

具体的には、例えば、承認依頼送信部１３５は、ｓ２で算出した合意ポリシーＰ１００のノード種別Ｐ１０１及び組織名Ｐ１０３により特定される、必須ノード及び第三者ノードに対応する参加者の全てが、承認ノード情報Ｔ２１１に登録されているか否かを判定する。

全ての承認情報が合意ポリシーＰ１００を満たしている場合は、承認依頼送信部１３５は、承認済トランザクションデータＴ２１０をブロック配信ノード３００に送信する（ｓ６）。なお、合意ポリシーＰ１００を満たしていない承認情報がある場合、承認情報送信部１５７は、例えば、承認済トランザクションデータＴ２１０に関する処理は以後行わないか、又は、所定の警告情報をクライアントノード１００又はブロック配信ノード３００に送信する。

ブロック配信ノード３００の承認済トランザクション受信部３１１は、クライアントノード１００から承認済トランザクションデータＴ２１０を受信する。すると、合意ポリシ
ー検証部３１３は、受信した承認済トランザクションデータＴ２１０に基づき独自に合意ポリシーＰ１００を算出する処理を実行する（ｓ７）。この処理はｓ２における合意ポリシー算出処理と同様であり、詳細は後述する。

ブロック配信ノード３００の合意ポリシー検証部３１３は、受信した承認済トランザクションデータＴ２１０における承認情報が、ｓ７で算出した合意ポリシーを満たしているか否かを検証する処理（以下、合意ポリシー検証処理という。）を実行する（ｓ８）。

具体的には、例えば、合意ポリシー検証部３１３は、ｓ７で算出した合意ポリシーＰ１００のノード種別Ｐ１０１及び組織名Ｐ１０３により特定される所定の必須ノード及び第三者ノードの条件を、承認済トランザクションデータＴ２１０の承認ノード情報Ｔ２１１が満たしているか否かを判定する。

前記条件を満たしている場合、合意ポリシー検証部３１３は、その旨を一時的に記憶し蓄積しておく。合意ポリシー検証部３１３は、さらに別の承認済トランザクションデータＴ２１０を受信した場合にも、これまでに説明したものと同様の処理を行う。

そして、ブロック配信ノード３００のブロック生成部３１５は、所定のタイミングで（例えば、１０分おきに）、一時的に蓄積した各トランザクションデータ（トランザクションデータ群）に基づくブロックチェーンデータＴ２６０を生成し、生成したブロックチェーンデータＴ２６０を電子取引システム１における他の全てのノードに送信する（ｓ９）。

ここで、ブロックチェーンデータＴ２６０について説明する。
（ブロックチェーンデータ）
図１３は、ブロックチェーンデータＴ２６０の一例を示す図である。ブロックチェーンデータＴ２６０は、ハッシュデータＴ２６３を介して時系列的に連結された複数のブロックデータＴ２６１を含んで構成されている。各ブロックデータＴ２６１は、いわゆるハッシュチェーン（Hash Chain）により構成されたブロックチェーンデータであり、少なくとも１以上の承認済トランザクションデータＴ２１０の集合であるトランザクションデータ群Ｔ２２０と、１つ前のブロックデータＴ２６１のトランザクションデータ群Ｔ２２０から生成されたハッシュデータＴ２６３とを有する。

図１０に戻り、ブロックチェーンデータＴ２６０を受信した各ノードは、そのブロックチェーンデータＴ２６０における各トランザクションデータ及び承認情報に記録されている関係者が、合意ポリシーＰ１００により特定される関係者の条件を満たしているか否かを検証する（ｓ１０）。

この条件が満たされていることが確認された場合、そのノードは、当該ブロックチェーンデータＴ２６０を分散台帳Ｔ２５０に追加して記録すると共に、ステート情報Ｔ２７０を最新のトランザクションデータＴ２００により更新する（ｓ１１）。他方、条件が満たされていなかった場合、そのノードは、ブロックチェーンデータＴ２６０を分散台帳Ｔ２５０に記録しない（ｓ１１）。以上で合意形成処理は終了する。

ここで、前記の合理ポリシー算出処理の詳細を説明する。
＜合理ポリシー算出処理＞
図１４は、クライアントノード１００が行う合意ポリシー算出処理の一例を説明するフロー図である。合意ポリシー算出処理は、ポリシー要件Ｔ３００、参加者関係性マップＴ１００、及びトランザクションデータＴ２００から合意ポリシーＰ１００を生成する。なお、ブロック配信ノード３００も合意ポリシーＰ１００を生成するが、その処理は本処理
と同様である。

まずクライアントノード１００の合意ポリシー算出部１３３は、対象トランザクションを受信すると、必須ノードの情報を合意ポリシーＰ１００に追加する（Ｓ１０１、Ｓ１１０）。具体的には、例えば、合意ポリシー算出部１３３は、ポリシー要件Ｔ３００のレコードＴ３０５及びレコードＴ３０６を取得し、取得したレコードの情報からx-of-n式を生成し、生成したx-of-n式の内容（例えば、2-of-(orgA, orgB, orgC)）を、「必須ノード
」がノード種別Ｐ１０１に格納されている合意ポリシーＰ１００のレコードの枠Ｐ１０２及び組織名Ｐ１０３の各項目に格納する。

また、合意ポリシー算出部１３３は、第三者ノードの情報を合意ポリシーＰ１００に追加する（Ｓ１２０〜Ｓ１４０）。

すなわち、まず合意ポリシー算出部１３３は、第三者ノードに関するポリシー要件を取得しておく（Ｓ１２０）。具体的には、例えば、合意ポリシー算出部１３３は、ポリシー要件Ｔ３００のうち、キーＴ３０２に第三者ノード枠又は第三者ノード指定条件が格納されているレコードを特定し、特定したレコードの内容を取得する。

次に、合意ポリシー算出部１３３は、対象トランザクションにおける、発行者と第三者ノードの候補とからなるリスト（参加組織リスト）を生成する（Ｓ１２１）。具体的には、例えば、合意ポリシー算出部１３３は、トランザクションデータＴ２００の一つのレコードについて、発行者Ｔ２０２及びスマートコントラクト引数Ｔ２０４の内容を取得する。

そして、合意ポリシー算出部１３３は、取得した第三者ノードの各候補について、その各候補と発行者との間の関係値をそれぞれ参加者関係性マップＴ１００から取得する（Ｓ１２２）。そして、合意ポリシー算出部１３３は、これらの関係値の合計を算出する（Ｓ１２３）。例えば、合意ポリシー算出部１３３は、参加組織リストの各組織について、参加者関係性マップＴ１００の行を取得し、これらの行について、列ごとに関係値を加算し、対象トランザクションにおける関係値の合計を算出する。このようにして合意ポリシー算出部１３３は、各第三者ノードについて関係値を算出する。なお、この場合、合意ポリシー算出部１３３は、関係値の合計値ではなく、関係値の平均値を算出してもよい。

合意ポリシー算出部１３３は、以上のＳ１２１−Ｓ１２３の処理を、トランザクションデータＴ２００のレコードのそれぞれについて行う。

次に、合意ポリシー算出部１３３は、Ｓ１２３までで取得した第三者ノード指定条件及び第三者ノード枠に基づき、第三者ノードの候補から第三者ノードを決定する（Ｓ１３０−Ｓ１３２）。

例えば、合意ポリシー算出部１３３は、第三者指定条件が「ｍｉｎ＿ｘ条件」である場合（Ｓ１３１）、関係値の合計が低い候補ノード（第三者ノードの候補）をその関係値の合計の低い順からｘ個抽出し、抽出したｘ個の候補ノードを第三者ノードとして決定する。また、例えば、合意ポリシー算出部１３３は、第三者指定条件が「閾値条件」の場合（Ｓ１３２）、関係値の合計が所定の閾値以下の候補ノードを全て抽出し、抽出した各候補ノードを第三者ノードとして決定する。

合意ポリシー算出部１３３は、Ｓ１３０−Ｓ１３２により決定した第三者ノードと、Ｓ１２０で取得した第三者ノード枠とを、合意ポリシーＰ１００に登録する（Ｓ１４０）。具体的には、例えば、合意ポリシー算出部１３３は、合意ポリシーＰ１００における、ノ
ード種別Ｐ１０１が「第三者ノード」のレコードの枠Ｐ１０２に、Ｓ１２０で取得した第三者ノード枠を格納し、当該レコードの組織名Ｐ１０３に、Ｓ１３０−Ｓ１３２により指定した第三者ノードを格納する。

さらに、合意ポリシー算出部１３３は、ポリシー要件Ｔ３００に他のポリシー要件が規定されていれば、そのポリシー要件に関する情報を合意ポリシーＰ１００に追加する（Ｓ１６０）。

以上のように、各ノードは、自身で、合意ポリシーＰ１００を生成することができる。これにより、各ノード間で合意ポリシーＰ１００を共有するためのデータ転送を不要とし、電子取引システム１におけるトランザクションの処理性能の低下を防ぐことができる。

次に、参加者関係性計算処理について説明する。
＜参加者関係性計算処理＞
図１５は、参加者関係性計算処理の一例を示すフロー図である。参加者関係性計算処理は、例えば、所定のタイミング（例えば、所定の時刻又は所定の時間間隔）で行われる。ここではクライアントノード１００が行う場合を説明するが、承認ノード２００でも同様である。

まず、関係性マップ算出部１０７は、参加者関係性マップＴ１００が未だ作成されていない状態（初期状態）か否かを判定する（Ｓ２１０）。参加者関係性マップＴ１００が生成されていない場合は（Ｓ２１０：ＹＥＳ）、次述するＳ２１１の処理が行われ、参加者関係性マップＴ１００が生成されている場合は（Ｓ２１０：ＮＯ）、後述するＳ２２０の処理が行われる。

Ｓ２１１において関係性マップ算出部１０７は、各参加者（ノード）の属性を表すベクトルを算出する。そして、関係性マップ算出部１０７は、算出したベクトルに基づき各参加者間の関係値を算出する（Ｓ２１２）。

具体的には、例えば、関係性マップ算出部１０７は、コンソーシアム参加時審査情報Ｔ４００の参加者情報Ｔ４１０の各レコードの業種Ｔ４１２及び役割Ｔ４１３に基づき、各参加者の業種及び役割を特定することにより、その業種及び役割を要素とする所定のベクトル（属性ベクトル）を取得する。そして、関係性マップ算出部１０７は、各参加者の属性ベクトルの距離に基づき各参加者間の関係値を算出し、算出した各関係値を参加者関係性マップＴ１００に格納する。

なお、属性ベクトルは、例えば、予め記憶しておいた所定のデータベース等により取得してもよいし、各参加者（企業等）に関するデータベースやウェブサイト等から所定の要素データ（自然言語データ等）を取得し、これに基づきコーパスを作成することで算出してもよい。

例えば、前記のデータベースにおいて、業種軸では製造業＝０，小売業＝１、役割軸ではサプライヤー＝０，バイヤー＝１とした属性データが予め登録されている場合、参加者org1の属性ベクトルは（０，０）、参加者org2の属性ベクトルは（１，１），参加者org3の属性ベクトルは（０，１）となる。すなわち、参加者の業種や役割等が近いほど、類似するベクトルとなる。関係性マップ算出部１０７は、このようにして各参加者の属性ベクトルを算出後、参加者間の属性ベクトルのコサイン距離を関係値として算出することで、各参加者間の距離（関係値）を表す行列を作成する。関係性マップ算出部１０７は、これらの各参加者間の関係値を参加者関係性マップＴ１００に格納する。これにより、業種又は役割等が近い参加者間ほど関係性も近くなり、関係値は１も近づく。

次に、関係性マップ算出部１０７は、各参加者間の関係性を特定し（Ｓ２１３）、特定した関係性に基づきＳ２１２で算出した関係値を修正する（Ｓ２１４）。

具体的には、例えば、関係性マップ算出部１０７は、コンソーシアム参加時審査情報Ｔ４００の参加者関係性情報Ｔ４２０の各レコードの組織Ｔ４２２及び関係性Ｔ４２３を取得し、取得したその内容に基づき、参加者関係性マップＴ１００における参加者間の関係値を更新する。例えば、関係性マップ算出部１０７は、関係性Ｔ４２３の内容が親子会社又は資本提携等の関係である場合は、参加者関係性マップＴ１００における、対応する参加者間の関係値に所定の値を加算する修正を行う。また、関係性Ｔ４２３の内容が競合関係である場合は、関係性マップ算出部１０７は、所定の値を減算する修正を行う。

図８の例では、org1とorg2が親子会社関係なので、関係性マップ算出部１０７は、参加者関係性マップＴ１００においてorg1とorg2が交わる要素に係る関係値を、親子会社関係に対応して設定されたパラメータ値である「０．２」だけ増加させている。

このように、関係性マップ算出部１０７は、参加者関係性マップＴ１００を、コンソーシアム参加時審査情報Ｔ４００を用いて作成するので、各ノードは、これまでに電子取引システム１においてトランザクションが行っていない場合であっても、信頼性の高い電子取引を行うことができる。すなわち、コンソーシアム参加時審査情報Ｔ４００は、電子取引システム１内のデータからでは得られない参加者の背後関係の情報を含むため、トランザクションデータＴ２００を送受信しているノード間（参加者間）での結託リスクを下げることができる。

次に、関係性マップ算出部１０７は、生成した参加者関係性マップＴ１００を最新のトランザクションデータとしたブロックデータＴ２６１を含むブロックチェーンデータＴ２６０を生成し、生成したブロックチェーンデータＴ２６０を、トランザクションデータＴ２００により特定されるスマートコントラクト経由で全てのノードに送信する（Ｓ２１５）。その後、このブロックチェーンデータＴ２６０を受信した各ノードは、所定の検証を経た後、これを自身の分散台帳Ｔ２５０に記憶する。また、各ノードは、最新の参加者関係性マップＴ１００をステート情報Ｔ２７０に保存する。これにより、ブロックチェーンデータＴ２６０が各ノードで共有される。以上で参加者関係性計算処理は終了する。

このように、各ノードが、参加者関係性マップＴ１００をトランザクションデータとしてブロックチェーンデータの形式で共有することにより、各ノードは、他のノードに対して問い合わせ等をすることなく、最新の参加者関係性マップＴ１００を参照することができる。これにより、電子取引システム１におけるトランザクション処理性能を向上させることができる。

次に、前記のＳ２２０において関係性マップ算出部１０７は、コンソーシアム参加時審査情報Ｔ４００に対して新たな参加者（ノード）が追加されているか否かを確認する。新たな参加者（ノード）が追加されている場合は（Ｓ２２０：ＹＥＳ）、次述するＳ２２１の処理が行われ、新たな参加者（ノード）が追加されていない場合は（Ｓ２２０：ＮＯ）、後述するＳ２３０の処理が行われる。

Ｓ２２１において関係性マップ算出部１０７は、追加された参加者に関する、Ｓ２１２と同様の属性ベクトルを算出する。具体的には、例えば、関係性マップ算出部１０７は、コンソーシアム参加時審査情報Ｔ４００の参加者情報Ｔ４１０に新たに追加されたレコードについて、Ｓ２１２と同様の処理を行う。その後はＳ２１３以降の処理が行われる。

Ｓ２３０において関係性マップ算出部１０７は、分散台帳Ｔ２５０を用いて参加者関係性マップＴ１００を更新するか否かを判定する。具体的には、例えば、関係性マップ算出部１０７は、分散台帳Ｔ２５０が更新されているか否か、最後に分散台帳Ｔ２５０により更新してから所定時間が経過しているか否か等によって、参加者関係性マップＴ１００の更新是非を判定する。

分散台帳Ｔ２５０を用いて参加者関係性マップＴ１００を更新しないと判定した場合は（Ｓ２３０：ＮＯ）、参加者関係性計算処理は終了する。
他方、分散台帳Ｔ２５０を用いて参加者関係性マップＴ１００を更新すると判定した場合は（Ｓ２３０：ＹＥＳ）、関係性マップ算出部１０７は、まず、前回の参加者関係性マップＴ１００の更新後に更新されている分散台帳Ｔ２５０の内容（トランザクションデータ群Ｔ２２０）を取得する（Ｓ２３１）。

次に、関係性マップ算出部１０７は、分散台帳Ｔ２５０に記録されている各トランザクションの参加者をトランザクションデータごとに全て抽出する（Ｓ２３２）。具体的には、例えば、関係性マップ算出部１０７は、Ｓ２３１で取得したトランザクションデータ群Ｔ２２０の各承認済トランザクションデータＴ２１０の発行者Ｔ２０２及びスマートコントラクト引数Ｔ２０４を全て取得する。

なお、関係性マップ算出部１０７は、トランザクションの参加者を抽出する際に、トランザクションデータ群Ｔ２２０の承認ノード情報Ｔ２１１の情報を抽出してもよい。これにより、取引に関して承認を行った第三者ノードが後に関係値として考慮されるため、時間経過によって第三者ノードが固定化されてしまうことを防ぐことができる。

そして、関係性マップ算出部１０７は、各トランザクションについて、そのトランザクションの種類又はその参加者の組み合わせに対応して算出される所定のパラメータ値を、参加者関係性マップＴ１００において対応する関係値に加算する（Ｓ２３３）。その後はＳ２１５の処理が行われる。

例えば、あるトランザクションが参加者org1から参加者org2への送金トランザクションである場合、関係性マップ算出部１０７は、送金元の参加者org1及び送金先の参加者org2の間の関係値を０．１増加させ、その値を該当する参加者関係性マップＴ１００のマトリックスに格納する。なお、トランザクションの参加者が３以上である場合、例えば、関係性マップ算出部１０７は、参加者を二者の組み合わせに分解することで、二者間の関係値をｎＣ２組作成する。

分散台帳Ｔ２５０は、トランザクションが行われると更新されるため、以上のように分散台帳Ｔ２５０を用いて参加者関係性マップＴ１００を動的に更新することで、参加者関係性マップＴ１００のデータ固定化による参加者間の結託リスクを減らすことができる。

なお、以上のような分散台帳Ｔ２５０を用いた参加者関係性マップＴ１００の更新（Ｓ２２０−Ｓ２１５）は、前記のコンソーシアム参加時審査情報Ｔ４００を用いた参加者関係性マップＴ１００の更新（Ｓ２１１−Ｓ２１５）とは独立に行うことができる。

（参加者関係性マップの更新トランザクション）
ここで、Ｓ２１５で生成される参加者関係性マップＴ１００のトランザクションデータ（更新トランザクション）について説明する。

図１６は、更新トランザクションＴ５００の一例を示す図である。更新トランザクションＴ５００は、トランザクションの識別子Ｔ５０１、このトランザクションの発行者Ｔ５
０２、このトランザクションのトランザクション関数Ｔ５０３、及び、このトランザクション関数における引数Ｔ５０４の各項目を有する、１以上のレコードで構成される。引数Ｔ５０４には、更新された参加者関係性マップＴ１００のデータが格納される。

以上のように、本実施形態のクライアントノード１００（電子取引装置１０）は、トランザクションデータが示す取引の承認者に関する条件である合意ポリシーＰ１００を、参加者関係性マップＴ１００及びポリシー要件Ｔ３００に基づき生成し、生成した合意ポリシーＰ１００に基づき特定された取引の承認者の承認ノード２００に承認依頼を送信するので、取引における承認者を適切に選択することができる。これにより、トランザクションに係るデータ転送を増やすことなく、トランザクションの成立（分散台帳システムの合意形成プロセス）に際してのノード間の結託リスクを低下させることができる。また、参加者関係性マップＴ１００により取引の関係者間の関係性を定量的に評価することができ、また、従来手作業で決定されていた合意ポリシーに客観性を持たせることできるため、ノード間の結託リスクを低下させることができる。
このように、本実施形態のクライアントノード１００（電子取引装置１０）によれば、トランザクションの処理性能を低下させることなく安全に電子取引を行うことができる。

以上の実施形態の説明は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明はその趣旨を逸脱することなく、変更、改良され得ると共に本発明にはその等価物が含まれる。

例えば、本実施形態では、ポリシー要件Ｔ３００はコンソーシアム毎に設定されるものとしたが、ポリシー要件Ｔ３００はスマートコントラクトやスマートコントラクト関数ごとに設定してもよい。これにより、より精度よくポリシー管理が可能となり、ノード間の結託リスクを減じることができる。

また、合意ポリシー算出処理においては、トランザクションデータＴ２００の内容から合意ポリシーＰ１００を算出するのではなく、参加者の属性等の情報から合意ポリシーＰ１００を算出してもよい。この場合、合意ポリシー算出部１３３は、トランザクションデータＴ２００が発行される前に、参加者関係性マップＴ１００に基づき合意ポリシーＰ１００を参加者ごとに生成することができる。これにより、トランザクションデータＴ２００が生成等されるごとに合意ポリシーＰ１００を算出しなくてもよくなるので、処理負荷を軽減させることができる。

また、本実施形態の参加者関係性計算処理では、複数の第三者ノードの候補の関係値を単純に加算することにより関係値の合計を求めているが、参加者ごとに所定の重みづけの係数を乗算した上で関係値の合計を求めるようにしてもよい。この重みづけの係数は、例えば、トランザクションの発行者の属性、スマートコントラクト関数、当該関数の引数等から参加者の重要性を示す数値を求めることにより決定する。例えば、発行者なら「１．０」、引数として登録されている参加者であれば「０．５」等とする。

また、各ノードは、コンソーシアム参加時審査情報Ｔ４００を、各ノードの所定の認証局から取得し、また、外部のデータベース等から取得してもよい。

また、各ノードは、参加者関係性マップＴ１００の共有以外の方法によって合意ポリシーＰ１００を決定してもよい。例えば、クライアントノード１００は、トランザクションデータＴ２００の発行時に、ブロック配信ノード３００が算出した合意ポリシーＰ１００を取得し、これに基づき承認ノードを決定してもよい。また、各ノードは、参加者関係性マップＴ１００ではなく、参加者ごとの合意ポリシーＰ１００をスマートコントラクト経由で共有してもよい。この場合、クライアントノード１００が合意ポリシーを算出する必
要がなくなる。

また、本実施形態では、クライアントノード１００が、トランザクションデータＴ２００が発行されるごとに合意ポリシーＰ１００を計算しているが、クライアントノード１００は合意ポリシーＰ１００を事前に計算しておき、所定のタイミング（例えば、月１回）にて更新するようにしてもよい。

また、電子取引システム１において、予め想定される複数のパターンの合意ポリシーＰ１００を作成しておき、各ノードは随時これらを取得してトランザクションを行うようにしてもよい。

また、本実施形態では、１つのノードが全ての承認ノードを決定する構成を示したが、複数のノードが分担して承認ノードを決定してもよい。

また、各ノードの合意形成処理は、各ノードのスマートコントラクトの機能の一部として実装してもよい。

また、本実施形態の合意形成処理は、Practical Byzantine Fault Tolerance（PBFT）
方式による合意処理に対して適用してもよい。ＰＢＦＴでは、全ノードが承認を行い、ノード間の多数決的な手続きでトランザクションの合意が行われる。この場合、例えば、合意ポリシー算出部１３３が、参加ノードのうち第三者ノードにおいては多数決の際の重み付けを大きく行い、他ノードよりもトランザクションの合意可否の決定権を多く持つようにする。これにより、ノード数を増やすなどして多数決を悪用しようとする参加ノード（参加者）同士の不正を抑止することができる。

以上の本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の電子取引システム１においては、前記合意ポリシー算出部は、前記関係性マップから、前記トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を抽出し、抽出した関係者及び前記ポリシー要件に基づき、前記合意ポリシーを生成する、としてもよい。

このように、参加者関係性マップＴ１００から所定条件を満たす第三者ノード（例えば、関係性の薄い第三者ノード）を抽出することで合意ポリシーＰ１００を生成することにより、取引に関して結託するおそれの少ない（正当な承認を行う可能性が高い）取引参加者による承認が実現できるので、より安全に電子取引を行うことができる。
また、参加者関係性マップＴ１００が第三者ノードの情報を有していることにより、電子取引システム１自体が分散台帳システムとして適しているか（もし第三者ノードが無いような、参加者間の関係が密なネットワークの場合、分散台帳システムである必要がない）の評価も可能である。

また、本実施形態の電子取引システム１においては、前記所定の取引の関係者の属性の情報、又は、過去に取得したトランザクションデータのうち少なくともいずれかに基づき、前記関係性マップを生成又は更新する関係性マップ算出部を備える、としてもよい。

このように、参加者関係性マップＴ１００を、取引の関係者の属性又は過去のトランザクションデータに基づき生成又は更新することで、取引に際して結託するおそれのある参加者を早期に検出し、より安全に電子取引を行うことができるようになる。

また、本実施形態の電子取引システム１においては、前記合意ポリシー算出部は、前記トランザクションデータから取引の関係者を抽出し、抽出した関係者から、前記トランザ
クションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を特定し、特定した関係者を前記合意ポリシーが示す関係者に含める、としてもよい。

このように、トランザクションデータから取引の関係者を抽出し、その関係者の中から取引と関係性の薄い関係者を特定してこれを合意ポリシーの関係者に含めることで、関係者の取引状況から結託するおそれのある参加者を抽出でき、取引に際して結託するおそれのある参加者を適切に抽出することができる。

また、本実施形態の電子取引システム１においては、前記生成又は更新した関係性マップを他の電子取引装置に送信する関係性マップ共有部を備える、としてもよい。

このように、参加者関係性マップＴ１００をノード間で共有することで、各ノードは他のノードからこれを取得することなく、迅速に合意ポリシーＰ１００の算出等を行うことができる。これにより、トランザクションの処理性能を低下させることなく取引の合意形成を行うことができる。

また、本実施形態の電子取引システム１においては、電子取引装置が、少なくとも１台以上の前記電子取引装置が送信した、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを含むブロックデータを、所定の情報処理装置から受信するブロック受信部と、前記受信したブロックデータにおけるトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する合意ポリシー検証部と、を備える、としてもよい。

このように、電子取引装置（クライアントノード１００又は承認ノード２００）が、所定の情報処理装置（配信ノード２００）から受信した、各電子取引装置のブロックデータ（ブロックチェーンデータＴ２６０）に対して、参加者関係性マップＴ１００及び合意ポリシーに基づき検証を行うことで、取引に際して結託するおそれのある参加者を確実に排除し、いわゆるブロックチェーンによる電子取引を安全に行うようにすることができる。

また、本実施形態の電子取引システム１においては、電子取引検証装置が、所定の取引に関する複数の関係者間の関係性を示した情報である関係性マップを記憶している関係性マップ記憶部と、前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶しているポリシー要件記憶部と、所定の情報処理装置から、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを受信する承認済トランザクションデータ受信部と、前記受信したトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する合意ポリシー検証部と、前記条件を満たしていると判定した場合に、前記受信したトランザクションデータを含むブロックデータを生成するブロック生成部とを備える、としてもよい。

このように、電子取引検証装置２０（ブロック配信ノード３００）が、合意ポリシーを電子取引装置１０と同様に生成して検証を行い、正しく承認が行われていると判定した場合に、取引が成立した旨を示す情報（ブロックチェーンデータＴ２６０）を生成することで、取引に際して結託するおそれのある参加者を確実に排除し、いわゆるブロックチェーンによる電子取引を安全に行うようにすることができる。

１電子取引システム、１０電子取引装置、２０電子取引検証装置、１００クライアントノード、１０１関係性マップ記憶部、１０３ポリシー要件記憶部、１３３合意ポリシー算出部、Ｔ１００参加者関係性マップ、Ｔ３００ポリシー要件、Ｐ１００
合意ポリシー

Claims

所定の取引における複数の関係者間の関係性を示した情報である関係性マップを記憶している関係性マップ記憶部と、
前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶しているポリシー要件記憶部と、
所定の取引内容を保持しているトランザクションデータが示す取引の、承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成する合意ポリシー算出部と、
前記生成した合意ポリシーに基づき特定された取引の承認者に対応づけられている、所定の情報処理装置に、所定の承認依頼を送信する承認依頼送信部と
を備える電子取引装置。
前記合意ポリシー算出部は、前記関係性マップから、前記トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を抽出し、抽出した関係者及び前記ポリシー要件に基づき、前記合意ポリシーを生成する、
請求項１に記載の電子取引装置。
前記所定の取引の関係者の属性の情報、又は、過去に取得したトランザクションデータのうち少なくともいずれかに基づき、前記関係性マップを生成又は更新する関係性マップ算出部を備える、
請求項１に記載の電子取引装置。
前記合意ポリシー算出部は、前記トランザクションデータから取引の関係者を抽出し、抽出した関係者から、前記トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を特定し、特定した関係者を前記合意ポリシーが示す関係者に含める、
請求項１に記載の電子取引装置。
前記生成又は更新した関係性マップを他の電子取引装置と共有する関係性マップ共有部を備える、請求項３に記載の電子取引装置。
少なくとも１台以上の前記電子取引装置が送信した、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを含むブロックデータを、所定の情報処理装置から受信するブロック受信部と、
前記受信したブロックデータにおけるトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する合意ポリシー検証部と、
を備える、請求項１に記載の電子取引装置。
所定の取引に関する複数の関係者間の関係性を示した情報である関係性マップを記憶している関係性マップ記憶部と、
前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶しているポリシー要件記憶部と、
所定の情報処理装置から、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを受信する承認済トランザクションデータ受信部と、
前記受信したトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを
判定する合意ポリシー検証部と、
前記条件を満たしていると判定した場合に、前記受信したトランザクションデータを含むブロックデータを生成するブロック生成部と
を備える電子取引検証装置。
電子取引装置が、
所定の取引における複数の関係者間の関係性を示した情報である関係性マップを記憶する関係性マップ記憶処理と、
前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶するポリシー要件記憶処理と、
所定の取引内容を保持しているトランザクションデータが示す取引の、承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成する合意ポリシー算出処理と、
前記生成した合意ポリシーに基づき特定された取引の承認者に対応づけられている、所定の情報処理装置に、所定の承認依頼を送信する承認依頼送信処理と
を実行する電子取引方法。
前記電子取引装置が、
前記合意ポリシー算出処理において、前記関係性マップから、前記トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を抽出し、抽出した関係者及び前記ポリシー要件に基づき、前記合意ポリシーを生成する、
請求項８に記載の電子取引方法。
前記電子取引装置が、
前記所定の取引の関係者の属性の情報、又は、過去に取得したトランザクションデータのうち少なくともいずれかに基づき、前記関係性マップを生成又は更新する関係性マップ算出処理を実行する、
請求項８に記載の電子取引方法。
前記電子取引装置が、
前記合意ポリシー算出処理において、前記トランザクションデータから取引の関係者を抽出し、抽出した関係者から、前記トランザクションデータが示す取引について、関係性を示す評価値が所定条件を満たす関係者を特定し、特定した関係者を前記合意ポリシーが示す関係者に含める、
請求項８に記載の電子取引方法。
前記電子取引装置が、
前記生成又は更新した関係性マップを他の電子取引装置と共有する関係性マップ共有処理を実行する、請求項１０に記載の電子取引方法。
前記電子取引装置が、
少なくとも１台以上の前記電子取引装置が送信した、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを含むブロックデータを、所定の情報処理装置から受信するブロック受信処理と、
前記受信したブロックデータにおけるトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する合意ポリシー検証処理と、
を実行する、請求項８に記載の電子取引方法。
電子取引検証装置が、
所定の取引に関する複数の関係者間の関係性を示した情報である関係性マップを記憶する関係性マップ記憶処理と、
前記取引の成立に必要な、当該取引の関係者に関する要件であるポリシー要件を記憶するポリシー要件記憶処理と、
所定の情報処理装置から、所定の承認情報を含む、所定の取引内容を保持しているトランザクションデータを受信する承認済トランザクションデータ受信処理と、
前記受信したトランザクションデータが示す取引の承認者に関する条件である合意ポリシーを、前記関係性マップ及び前記ポリシー要件に基づき生成し、生成した合意ポリシーが示す関係者に関する条件を、前記所定の承認情報が示す関係者が満たしているか否かを判定する合意ポリシー検証処理と、
前記条件を満たしていると判定した場合に、前記受信したトランザクションデータを含むブロックデータを生成するブロック生成処理と
を実行する、請求項８に記載の電子取引方法。