JP7327480B2 - 電子取引システム、取引管理サーバ、電子取引方法及びプログラム - Google Patents

Description

本発明は、電子取引システム、取引管理サーバ、電子取引方法及びプログラムに関する。

近年、通信技術や情報処理技術の発展と共に、ネットワーク上にて種々のサービスが提供されている。例えば、非特許文献１には、電力の売買をネットワーク上で行うためのシステムが開示されている。

特許文献１には、電力消費者がデマンドレスポンスシステムと匿名で通信する技術が開示されている。特許文献２には、入札価格に対応する公開鍵のリストを入札者に公開する必要がなく、かつ価格秘匿性の証明が可能な電子入札システム、電子入札方法を提供する、と記載されている。特許文献３には、入札者のプライバシを保護し談合を防止し依頼者利益を保護する、と記載されている。

特開２０１７－０５９８７２号公報 国際公開２００７／０６３８７６号 特開２００１－１０１３１６号公報

田中謙司等、"ブロックチェーンを用いた電力融通取引プラットフォームの一提案"、２０１８年１月２３日、ＳＣＩＳ２０１８

上述のように、非特許文献１には、電力取引にブロックチェーンを活用する技術が開示されている。当該非特許文献１によれば、個々のユーザが自身の電力消費量や発電量に基づき、電力の過不足を推定し、ブロックチェーン上で電力の発注、売買を行うことで電力取引が実現できる。

しかしながら、非特許文献１では、参加者の入札は他の参加者が見えるような平文で登録されている。そのため、参加者は、他人の発注状況、取引価格、取引量を把握可能となっている。他人の発注状況が把握可能であると、公平な取引が損なわれる可能性がある。例えば、売買する意志は無いにもかかわらず、大量の買い入札を行いあたかも電力需要が旺盛であるかのように見せかけ、有利な価格で売電を実現するような不正を許しかねない。

なお、特許文献１乃至３に開示された技術では、上記問題点を解決することはできない。例えば、特許文献１に開示された技術は匿名通信を実現するためのものであり、不正の防止には適用できない。また、特許文献２及び３に開示された技術は、封印入札に関する技術であり、非特許文献１に開示されたような電力取引システムに適用することはできない。

本発明は、公平な取引を提供することに寄与する電子取引システム、取引管理サーバ、電子取引方法及びプログラムを提供することを主たる目的とする。

本発明の第１の視点によれば、第１の電子掲示板を提供する、複数の管理サーバと、入札データを前記第１の電子掲示板に書き込む、参加者端末と、前記書き込まれた入札データを取得し、前記取得された入札データを用いてザラバ方式により取引を実行する、取引管理サーバと、を含み、前記取引管理サーバは、公開鍵及び秘密鍵を生成し、前記参加者端末は、前記取引管理サーバが生成した公開鍵を用いて前記入札データを暗号化し、前記取引管理サーバは、前記秘密鍵を用いて前記暗号化された入札データを復号する、電子取引システムが提供される。

本発明の第２の視点によれば、公開鍵及び秘密鍵を生成し、電子掲示板を提供する複数の管理サーバと、前記公開鍵を用いて暗号化された入札データを前記電子掲示板に書き込む参加者端末と、に接続され、前記書き込まれた入札データを取得し、前記暗号化された入札データを前記秘密鍵により復号すると共に、前記入札データを用いてザラバ方式により取引を実行する、取引管理サーバが提供される。

本発明の第３の視点によれば、電子掲示板を提供する、複数の管理サーバと、入札データを前記電子掲示板に書き込む、参加者端末と、前記書き込まれた入札データを取得し、前記取得された入札データを用いてザラバ方式により取引を実行する、取引管理サーバと、を含む電子取引システムにおいて、公開鍵及び秘密鍵を生成するステップと、前記取引管理サーバが生成した公開鍵を用いて前記入札データを暗号化するステップと、前記秘密鍵を用いて前記暗号化された入札データを復号するステップと、を含む電子取引方法が提供される。

本発明の第４の視点によれば、公開鍵及び秘密鍵を生成し、電子掲示板を提供する複数の管理サーバと、前記公開鍵を用いて暗号化された入札データを前記電子掲示板に書き込む参加者端末と、に接続された取引管理サーバに搭載されたコンピュータに、前記書き込まれた入札データを取得する処理と、前記暗号化された入札データを前記秘密鍵により復号する処理と、前記入札データを用いてザラバ方式により取引を実行する処理と、を実行させるプログラムが提供される。

本発明の各視点によれば、公平な取引を提供することに寄与する電子取引システム、取引管理サーバ、電子取引方法及びプログラムが提供される。なお、本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

一実施形態の概要を説明するための図である。 第１の実施形態に係る電子取引システムの構成の一例を示す図である。 第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。 入札データの一例を示す図である。 約定データの一例を示す図である。 汎用データ掲示板に書き込まれた情報の一例を示す図である。 第１の実施形態に係る取引管理サーバの処理構成の一例を示すブロック図である。 入札管理テーブルの一例を示す図である。 取引実行部の動作の一例を示すフローチャートである。 取引実行部の動作の一例を示すフローチャートである。 第１の実施形態に係る参加者端末の処理構成の一例を示すブロック図である。 第１の実施形態に係る管理サーバの処理構成の一例を示すブロック図である。 第１の実施形態に係る電子取引システムの動作の一例を示すシーケンス図である。 第２の実施形態に係る電子取引システムの構成の一例を示す図である。 第２の実施形態に係る取引管理サーバと制御装置を説明するための図である。 第２の実施形態に係る取引管理サーバの処理構成の一例を示す図である。 第２の実施形態に係る取引管理サーバの動作の一例を示すシーケンス図である。 第２の実施形態に係る電子取引システムの動作の一例を示すシーケンス図である。 取引管理サーバのハードウェア構成の一例を示す図である。 取引実行装置と取引検証装置を説明するための図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

一実施形態に係る電子取引システムは、複数の管理サーバ１０１と、参加者端末１０２と、取引管理サーバ１０３と、を含む（図１参照）。複数の管理サーバ１０１は、第１の電子掲示板を提供する。参加者端末１０２は、入札データを第１の電子掲示板に書き込む。取引管理サーバ１０３は、書き込まれた入札データを取得し、取得された入札データを用いてザラバ方式により取引を実行する。取引管理サーバ１０３は、公開鍵及び秘密鍵を生成する。参加者端末１０２は、取引管理サーバ１０３が生成した公開鍵を用いて入札データを暗号化する。取引管理サーバ１０３は、秘密鍵を用いて暗号化された入札データを復号する。

上記電子取引システムにおいて、参加者端末１０２は、入札データを取引管理サーバ１０３の公開鍵を用いて暗号化し、電子掲示板に登録する。暗号化された入札データを復号できるのは、秘密鍵を有する取引管理サーバ１０３であり、他の参加者は、その内容を知ることができない。その結果、入札に係る情報の秘密が保持され、上記電子取引システムは公平な取引を提供できる。

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

［システム構成概略］
図２は、第１の実施形態に係る電子取引システムの構成の一例を示す図である。図２を参照すると、電子取引システムは、取引管理サーバ１０と、複数の参加者端末２０－１～２０－Ｌ（Ｌは正の整数、以下同じ）と、データ管理システム３０と、を含んで構成される。

取引管理サーバ１０、参加者端末２０－１～２０－Ｌ及びデータ管理システム３０のそれぞれは、インターネット等のネットワークを介して相互に接続されている。

電子取引システムの取引対象は特に限定されないが、本願開示では主に「電力」を取引の対象として説明を行う。但し、本願開示の電子取引システムは、株式等の金融商品等の取引にも適用可能である。

取引管理サーバ１０は、電力の買い手と売り手の注文を仲介する装置である。

参加者端末２０－１～２０－Ｌは、電力取引の参加者が使用する端末である。例えば、パーソナルコンピュータやスマートフォン等の情報処理装置が、上記参加者端末２０に相当する。なお、以降の説明において、参加者端末２０－１～２０－Ｌを区別する特段の理由が無い場合には、単に「参加者端末２０」と表記する。

また、参加者端末２０の使用者が買電を希望する場合に、当該使用者が利用する端末を「買い手端末」と表記する。同様に、参加者端末２０の使用者が売電を希望する場合に、当該使用者が利用する端末を「売り手端末」と表記する。

データ管理システム３０は、取引管理サーバ１０の運営主体や電力取引の参加者（入札者；売り手、買い手）から独立した立場の機関等が運営するシステムである。データ管理システム３０は、外部（第３者）に対し追記及び読み出しの可能な電子掲示板を提供するシステムである。より具体的には、データ管理システム３０は、どのような主体でも情報を追記できると共に、書き込まれた情報を読み出すことができ、且つ、一度書き込まれた情報は消去されたり改竄されたりすることのない電子掲示板を提供する。データ管理システム３０は、所謂、ブロックチェーンと称される技術により上記特徴を持つ電子掲示板を提供する。

図２に示す電子取引システムでは、電力取引に必要な情報（以下、電力取引データと表記する）の授受を、ブロックチェーンにより実現される電子掲示板を介して行う。なお、上述のように、データ管理システム３０は、任意の主体（電力取引に係る参加者を含む任意の主体）に対しても電子掲示板を提供するシステムであるため、当該電子掲示板には上記電力取引データとは無関係なデータが混在することとなる。

以降の説明において、データ管理システム３０が提供する電子掲示板を「汎用データ掲示板」と表記する。また、汎用データ掲示板の基礎となる台帳を「汎用データ管理台帳」と表記する。

データ管理システム３０は、複数の管理サーバ４０－１～４０－Ｍ（Ｍは正の整数、以下同じ）から構成されている。また、参加者端末２０と同様に、管理サーバ４０－１～４０－Ｍを区別する特段の理由がない場合には、単に「管理サーバ４０」と表記する。

データ管理システム３０をなす複数の管理サーバ４０は、図２に示すように、相互に直接接続されている。即ち、データ管理システム３０は、Ｐ２Ｐ（Peer to Peer）接続された複数の管理サーバ４０を含んで構成される。

データ管理システム３０では、Ｐ２Ｐ接続された複数の管理サーバ４０それぞれが、外部から受信したデータ（例えば、電力取引データ）を管理するためのデータ管理台帳を有する。データ管理システム３０は、当該データ管理台帳を複数の管理サーバ４０に分散し共有して、管理する。

データ管理システム３０をなす管理サーバ４０は、取引管理サーバ１０や参加者端末２０から電力取引データを汎用データ掲示板に書き込む旨の要求（データ記録要求）を取得するたびに、汎用データ管理台帳に当該電力取引データを追記する。また、各管理サーバ４０は、当該汎用データ管理台帳に追記するデータの正当性を証明するデータを生成する。具体的には、管理サーバ４０は、上記追記データの正当性を証明するデータとして各管理サーバ４０の電子署名（デジタル署名）を用いるものとする。

電子署名の生成が終了すると、管理サーバ４０は、汎用データ管理台帳への追記データに電子署名を付して、他の管理サーバ４０に配布する。他の管理サーバ４０は、当該追記データを受信すると、その正当性を検証した後に自身の汎用データ管理台帳を更新する。

［システム動作概略］
次に、図面を参照しつつ、第１の実施形態に係る電子取引システムの動作概略を説明する。

図３は、第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。

売電を希望する参加者は、売買の種別（売り注文）、自身を特定する識別子（参加者ＩＤ；IDentifier）と、売却を希望する電力量（数量）と、売却希望額（価格）、を含む「売り手入札データ」を汎用データ掲示板に書き込む（売り手入札；ステップＳ０１）。

その際、売り手端末は、売り手入札データを取引管理サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４の上段に示すようなデータが暗号化され、汎用データ掲示板に書き込まれる。

同様に、買電を希望する参加者は、売買の種別（買い注文）、自身を特定する参加者ＩＤ、購入を希望する電力量と、購入希望額、を含む「買い手入札データ」を汎用データ掲示板に書き込む（買い手入札；ステップＳ０２）。

買い手端末は、買い手入札データを取引管理サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４の下段に示すようなデータが暗号化され、汎用データ掲示板に書き込まれる。

参加者端末２０は、図４に示す４つの項目（売買種別、参加者ＩＤ、数量、価格）の全てを暗号化せずに、数量だけを暗号化してもよい。少なくとも数量が暗号化されていれば取引の安全は確保できるためである。このように、第１の実施形態に係る参加者端末２０は、暗号化された価格を含む入札データを汎用データ掲示板に書き込む。

なお、以降の説明において、売り手入札データと買い手入札データを区別する必要が無い場合には、単に「入札データ」と表記する。

取引管理サーバ１０は、汎用データ掲示板に定期的にアクセスし、入札データを取得する（ステップＳ０３）。

取得した入札データは暗号化されているので、取引管理サーバ１０は、自身の秘密鍵を用いて取得した入札データの暗号文を復号する（ステップＳ０４）。

取引管理サーバ１０は、予め定めたタイミング等で、取得した入札データを用いた取引を実行する（ステップＳ０５）。取引管理サーバ１０による取引処理の詳細は後述する。

取引管理サーバ１０は、取引結果を汎用データ掲示板に書き込む。

なお、汎用データ掲示板に入札データが書き込まれると、当該入札データを特定するためのトランザクションＩＤ（以下、ＴＸＩＤと表記する）が付与される。取引管理サーバ１０は、当該ＴＸＩＤを利用して取引結果を汎用データ掲示板に書き込む。具体的には、取引管理サーバ１０は、売り入札と買い入札が成立（約定）した場合には、当該約定した入札データのＴＸＩＤを含むデータを「約定データ」として汎用データ掲示板に書き込む（図５参照）。

汎用データ掲示板に書き込まれた約定データを確認すれば、参加者は自分の未約定なデータを把握することができる。あるいは、取引管理サーバ１０は、約定したＴＸＩＤを指定し、当該ＴＸＩＤを取引の場から削除した旨の削除データを汎用データ掲示板に書き込んでもよい。当該削除データにより、参加者は、取引の場に残る入札データ（未約定な入札データ）を把握してもよい。

売り手と買い手は、汎用データ掲示板にアクセスすることで約定データを取得し、取引結果を確認する（ステップＳ０６、ステップＳ０７）。参加者端末２０（売り手端末、買い手端末）は、汎用データ掲示板に書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する。

参加者端末２０は、約定データを参照することで、自身の入札データの状態（約定、未約定）を把握できる。あるいは、参加者端末２０は、削除データを確認することによっても自身の入札が約定したか否かを確認してもよい。

参加者端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応するものであれば、自身の入札が約定したことを把握できる。一方、参加者端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応したものでなければ、自身の入札は約定せず、未約定な入札として汎用データ掲示板（取引の場）に残っていることが把握できる。

例えば、図６に示すような電力取引データ（入札データ、約定データ）が汎用データ掲示板に書き込まれているとする。図６は、ＴＸＩＤが「０１」、「０２」の売り入札が行われ、その後、ＴＸＩＤが「０３」の買い入札が行われていることを示している。その後、ＴＸＩＤが「０１」の売り入札とＴＸＩＤが「０３」の買い入札が約定し、ＴＸＩＤが「０４」の約定データとして汎用データ掲示板に書き込まれている。なお、図６に示す「ＰＩＤ」は参加者ＩＤを示す。

取引管理サーバ１０、参加者端末２０は、図６に示すような電力取引データ（入札データ、約定データ）を確認することで、ＴＸＩＤが「０２」の売り入札は未約定な入札データとして汎用データ掲示板に残っていることも確認できる。

つまり、取引管理サーバ１０は、システム稼働時からの汎用データ掲示板に書き込まれた電力取引データをトレースすることで最新の入札状況（未約定な状態で残っている入札データ）を把握することができる。同様に、参加者端末２０は、汎用データ掲示板に書き込まれた電力取引データをトレースすることで、最新の入札状況を把握することができる。

但し、参加者端末２０は、自身の入札に関する状況（約定済み、未約定）を把握することができるが、入札データは暗号化されているため、汎用データ掲示板に残っている入札データの詳細（少なくとも価格の詳細）を知ることはできない。

［取引サーバの処理構成］
次に、取引管理サーバ１０の詳細について説明する。取引管理サーバ１０は、汎用データ掲示板に書き込まれた入札データを取得し、暗号化された価格を復号する。さらに、取引管理サーバ１０は、復号された価格を用いてザラバ方式により取引を実行する。

図７は、第１の実施形態に係る取引管理サーバ１０の処理構成の一例を示すブロック図である。図７を参照すると、取引管理サーバ１０は、通信制御部２０１と、データ管理部２０２と、復号部２０３と、取引実行部２０４と、鍵生成部２０５と、署名検証部２０６と、記憶部２０７と、を含んで構成される。

通信制御部２０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部２０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。

鍵生成部２０５は、公開鍵及び秘密鍵の鍵ペアを生成する手段である。公開鍵は公開され、秘密鍵は記憶部２０７に格納される。

署名検証部２０６は、入札データに付与された参加者端末２０の署名を検証する手段である。署名の検証に成功した入札データは正規な入札データとして扱われる。

記憶部２０７は、各処理モジュールの処理に必要な情報等を記憶する手段である。

データ管理部２０２は、汎用データ掲示板にアクセスし、電力取引データ（入札データ、約定データ）を管理する手段である。データ管理部２０２は、汎用データ掲示板に定期的にアクセスし、当該掲示板に新規に書き込まれた（取引管理サーバ１０が一度も取得していない）入札データを取得する。データ管理部２０２は、取得した入札データを復号部２０３に引き渡す。また、データ管理部２０２は、取引実行部２０４による取引結果（約定データ）を、通信制御部２０１を介して汎用データ掲示板に書き込む。

復号部２０３は、取引管理サーバ１０の公開鍵で暗号化されている入札データを復号する手段である。より具体的には、復号部２０３は、暗号化されている入札データを、秘密鍵を用いて復号し、復号結果（平文の入札データ）を記憶部２０７に格納する。

取引実行部２０４は、入札データを用いた取引（電力取引）を実行する手段である。取引実行部２０４は、所謂、ザラバ方式と称される手法により電力取引を実現する。より具体的には、取引実行部２０４は、多数の売り入札と買い入札のなかで価格と数量が一致したものから順に取引を成立させていく。

取引実行部２０４は、「価格優先の原則」と「時間優先の原則」に従って取引を成立させていく。例えば、買い注文（買い入札）であれば、安い価格の買い注文よりも高い価格の買い注文が優先され、売り注文であれば、高い価格の売り注文よりも安い価格の売り注文が優先されて取引が成立する。同じ価格の注文の場合には、より早く入札があった方が優先され取引が成立する。

取引実行部２０４は、「入札管理テーブル」を用いて入札状況（未約定な入札データ）を管理し、当該テーブルを用いて取引を実行する。入札管理テーブルとは、売り注文、買い注文それぞれについて、未約定な入札価格を順に並べたテーブル情報である。即ち、入札管理テーブルにより未約定な入札データが管理される。

図８は、入札管理テーブルの一例を示す図である。図８に示すように、未約定な入札データの数量が価格順に並べられ、管理される。なお、図８を含む図面において、数量（売り数量、買い数量）や価格の単位を記載していないが、これらの単位は任意とすることができる。例えば、数量の単位は「ｋＷｈ」とし、価格の単位は「１円」とすることができる。

取引実行部２０４又はデータ管理部２０２が、システム稼働時からの汎用データ掲示板に書き込まれた電力取引データをトレースすることで図８に示すような入札管理テーブルを作成できる。

ここで、上述のように、取引実行部２０４による電力取引は、価格優先の原則と時間優先の原則に従って行われる。そのため、図８に示すような価格と数量だけの単純な組み合わせによる管理ではなく、実際には、各価格に含まれる入札データの詳細が管理されている。例えば、図８の吹き出しに記載したように、価格ごとに未約定な入札データの詳細（参加者ＩＤ、数量、入札時間）が管理される。

なお、参加者ＩＤ及び数量は入札データに記載された情報を用いればよい。入札時間に関しては、入札データの生成日時、あるいは掲示板に記録された時間（タイムスタンプ）を用いればよい。また、取引実行部２０４が、売り入札と買い入札を約定させた場合には、当該約定の結果を入札管理テーブルに反映する。

続いて、図９及び図１０を参照しつつ、取引実行部２０４の動作を説明する。

取引実行部２０４は、記憶部２０７に格納された入札データを取得し、入札時間（タイムスタンプ）が古い入札データから順に処理をしていく。

その際、取引実行部２０４は、入札データが「売り手入札データ」であった場合には、図９に示すフローチャートに従って処理をする。取引実行部２０４は、入札データが「買い手入札データ」であった場合には、図１０に示すフローチャートに従って処理をする。

はじめに、入札データが「売り手入札データ」である場合の取引実行部２０４の動作を説明する。

図９に示すステップＳ１０１において、取引実行部２０４は、処理対象となる売り手入札データの売値（売却希望額）が入札管理テーブルにより管理される買値（購入希望額）の最高額以下であるか否かを判定する。例えば、図８に示す例では、売値と買値の最高額である「１９」の大小が比較される。

売値が買値の最高額よりも高ければ（ステップＳ１０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の売り手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ１０２）。

売値が買値の最高額以下であれば（ステップＳ１０１、Ｙｅｓ分岐）、取引実行部２０４は、売り数量（売却希望電力量）が買値最高額の数量以下であるか否かを判定する（ステップＳ１０３）。例えば、図８に示す例では、売り数量と買値最高額の数量である「４０」の大小が比較される。

売り数量が買値最高額の数量以下であれば（ステップＳ１０３、Ｙｅｓ分岐）、取引実行部２０４は、買い入札の入札時間の古い順に約定する（ステップＳ１０４）。例えば、図８に示す例では、売り数量が「３０」であれば、売り入札と、入札時間の最も古い買い入札（入札時間；１２：０１）及び２番目に古い買い入札（入札時間；１２：１０）と、が約定する。

取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ１０５）。

売り数量が買値最高額の数量より大きければ（ステップＳ１０３、Ｎｏ分岐）、取引実行部２０４は、対象となる売り入札の売り数量の全てを買値最高額にて約定する（ステップＳ１０６）。

取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ１０７）。

ステップＳ１０８において、取引実行部２０４は、売り手入札データの売り数量のうち、ステップＳ１０６の処理にて約定しなかった売り数量が存在するか否かを判定する。例えば、図８に示す例では、売り数量が「５０」であれば、買値最高額である「１９」にて売り数量「４０」が約定し、売り数量の残は「１０」となる。

売り数量の残が存在すれば（ステップＳ１０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ１０１に戻り処理を継続する。具体的には、取引実行部２０４は、一部の売り数量が約定した結果が反映された入札管理テーブルを用いて、売り残が処理される。例えば、上記の例では、売り残の数量「１０」は、価格「１８」の買い入札と約定することになる。

売り数量の残が存在しなければ（ステップＳ１０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。

次に、入札データが「買い手入札データ」である場合の取引実行部２０４の動作を説明する。

図１０に示すステップＳ２０１において、取引実行部２０４は、処理対象となる買い手入札データの買値（購入希望額）が入札管理テーブルにより管理される売値（売却希望額）の最低額以上であるか否かを判定する。

買値が売値の最低額よりも低ければ（ステップＳ２０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の買い手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ２０２）。

買値が売値の最低額以上であれば（ステップＳ２０１、Ｙｅｓ分岐）、取引実行部２０４は、買い数量（購入希望電力量）が売値最低額の数量以下であるか否かを判定する（ステップＳ２０３）。

買い数量が売値最低額の数量以下であれば（ステップＳ２０３、Ｙｅｓ分岐）、取引実行部２０４は、売り手入札の入札時間の古い順に約定する（ステップＳ２０４）。

取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ２０５）。

買い数量が売値最低額の数量より大きければ（ステップＳ２０３、Ｎｏ分岐）、取引実行部２０４は、対象となる買い入札の買い数量の全てを売値最低額にて約定する（ステップＳ２０６）。

取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ２０７）。

ステップＳ２０８において、取引実行部２０４は、買い手入札データの買い数量のうち、ステップＳ２０６の処理にて約定しなかった買い数量が存在するか否かを判定する。

買い数量の残が存在すれば（ステップＳ２０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ２０１に戻り処理を継続する。

買い数量の残が存在しなければ（ステップＳ２０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。

取引実行部２０４は、データ管理部２０２が新たに取得した入札データに関する処理を終了すると、必要に応じて取引結果（約定データ）を記憶部２０７に記憶する。データ管理部２０２は、取引実行部２０４による上記取引結果（約定データ）を、通信制御部２０１を介し汎用データ掲示板に書き込む。その際、データ管理部２０２は、約定データ等に自身（取引管理サーバ１０）の署名を付与する。

［参加者端末の処理構成］
次に、参加者端末２０の詳細について説明する。

図１１は、第１の実施形態に係る参加者端末２０の処理構成の一例を示すブロック図である。図１１を参照すると、参加者端末２０は、通信制御部３０１と、入札データ管理部３０２と、鍵生成部３０３と、記憶部３０４と、を含んで構成される。

通信制御部３０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部３０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。

鍵生成部３０３は、公開鍵及び秘密鍵の鍵ペアを生成する手段である。公開鍵は公開され、秘密鍵は記憶部３０４に格納される。

記憶部３０４は、各処理モジュールの処理に必要な情報等を記憶する手段である。例えば、記憶部３０４は、取引管理サーバ１０から公開された公開鍵を記憶する。当該公開鍵は、入札データ管理部３０２により署名が検証される際に使用される。即ち、記憶部３０４に格納された取引管理サーバ１０の公開鍵は、参加者端末２０における「署名検証鍵」としての役割を有する。

入札データ管理部３０２は、入札データ（売り手入札データ、買い手入札データ）に関する管理を行う手段である。具体的には、入札データ管理部３０２は、ユーザ（売り手、買い手）による操作に応じて、図４に示すような入札データを生成する。

さらに、入札データ管理部３０２は、生成した入札データに自身の秘密鍵を用いて署名を付与したのちに、取引管理サーバ１０の公開鍵を用いて入札データを暗号化する。そして、入札データ管理部３０２は、暗号化された入札データを汎用データ掲示板に書き込む。ここで、入札データ管理部３０２が、署名を施してから入札データを暗号化するのは、同じ参加者の入札データの署名がその参加者の公開鍵で検証できてしまうことにより、入札データがお互いに関連付けられてしまうことを防ぐためである。なお、参加者端末２０による署名の生成は、参加者端末２０の秘密鍵を用いて行われるので、当該秘密鍵は「署名鍵」としての役割を有する。

また、入札データ管理部３０２は、汎用データ掲示板に記載された約定データを取得する。入札データ管理部３０２は、約定データに付与された取引管理サーバ１０の署名を検証し、署名の検証に成功した場合に、当該約定データを正規なデータとして受け入れる。取得した約定データが自身の入札データに付与されたＴＸＩＤを有するものであれば、入札データ管理部３０２は、自身の入札は約定したものと判断する。その際、入札データ管理部３０２は、約定結果を液晶ディスプレイに表示する等の対応を行ってもよい。

［管理サーバ］
データ管理システム３０をなす管理サーバ４０は、ブロックチェーン技術を用いて電子掲示板（汎用データ掲示板）を提供する装置である。

図１２は、第１の実施形態に係る管理サーバ４０の処理構成の一例を示すブロック図である。図１２を参照すると、管理サーバ４０は、通信制御部４０１と、台帳制御部４０２と、署名検証部４０３と、記憶部４０４と、を含んで構成される。

通信制御部４０１は、他の装置との間の通信を実現する手段である。通信制御部４０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。

記憶部４０４は、各処理モジュールの処理に必要な情報等を記憶する手段である。例えば、記憶部４０４は、ブロックチェーンによる電子掲示板（汎用データ掲示板）を実現するための台帳を記憶する。

台帳制御部４０２は、台帳に記入するトランザクションの作成やトランザクションを台帳に記入するための合意形成に係るメッセージの作成を制御する。台帳制御部４０２は、取引管理サーバ１０や参加者端末２０から電力取引データを汎用データ掲示板に書き込むよう依頼されるたびに、共有台帳（汎用データ管理台帳）に当該データを追記する。当該データを追記する際に管理サーバ４０のそれぞれは合意形成を行う。合意形成の方法には、例えば、ＰＢＦＴ（Practical Byzantine Fault Tolerance）プロトコルを用いることができる。なお、ブロックチェーンを利用した電子掲示板は当業者にとって明らかなため、台帳制御部４０２に関する更なる説明は省略する。

署名検証部４０３は、他の管理サーバ４０との間で合意を形成する際に当該他の管理サーバ４０の署名を検証する手段である。署名の検証に成功した場合に、受信データは正規なデータとして扱われブロックチェーンに書き込まれる。

続いて、図面を参照しつつ第１の実施形態に係る電子取引システムの動作を説明する。図１３は、第１の実施形態に係る電子取引システムの動作の一例を示すシーケンス図である。

参加者端末２０は、入札データを生成する（ステップＳ１１）。例えば、参加者端末２０は、図４の上段に示すような入札データを生成する。

参加者端末２０は、入札データに署名を付与した後、当該署名付きの入札データを取引管理サーバ１０の公開鍵で暗号化してデータ管理システム３０（管理サーバ４０）に送信する（ステップＳ１２）。なお、参加者端末２０は、参加者が特定されることを防ぐため、例えば、確率的暗号を使用して入札データの暗号文を生成することが望ましい。なお、入札データが暗号化され、一見しただけではどのような情報か不明となるので、参加者端末２０は、汎用データ掲示板に書き込まれたデータが入札データであることを示すためのタグをつけてもよい。タグは取引管理サーバ１０が認識できるデータであればどのようなデータでもよく、例えば、「入札データ」等の文字であってもよい。

データ管理システム３０をなす複数の管理サーバ４０のそれぞれは、受信データに付与された他の管理サーバ４０が付与した署名を検証する。各管理サーバ４０は、署名の検証に成功すると、共通の台帳に記載するデータの合意形成を行う（ステップＳ１３）。各管理サーバ４０は、例えば、マルチシグやＰＢＦＴ等のアルゴリズムを用いて互いに合意形成を行う。

複数の管理サーバ４０の間で合意が形成されれば、当該入札データは共通台帳（汎用データ管理台帳）に記録される（ステップＳ１４）。

取引管理サーバ１０は、汎用データ掲示板にアクセスし、新規入札データの有無を確認する（ステップＳ１５）。

取引管理サーバ１０は、新規入札データが汎用データ掲示板に書き込まれていれば、当該入札データを取得する（ステップＳ１６）。

取引管理サーバ１０は、暗号化された入札データを復号する（ステップＳ１７）。そして、取引管理サーバ１０は、復号した入札データに付与された署名を検証する。取引管理サーバ１０は、署名が無効であれば入札データを無視（破棄）する。

取引管理サーバ１０は、入札データに記載された取引内容を確認し、約定処理を実行する（ステップＳ１８）。

入札データが約定した場合には、取引管理サーバ１０は、約定データをデータ管理システム３０（管理サーバ４０）に送信する（ステップＳ１９）。なお、約定データには、図５に示すように、約定した２つの入札データのＩＤが含まれる。また、取引管理サーバ１０は、約定データに署名して署名付きの約定データをデータ管理システム３０に送信する。

各管理サーバ４０は、取得した約定データを汎用データ掲示板に書き込む（ステップＳ２０）。

参加者端末２０は、汎用データ掲示板にアクセスし、新規約定データの有無を確認（照会）する（ステップＳ２１）。

管理サーバ４０は、参加者端末２０に新規約定データを送信する（ステップＳ２２）。参加者端末２０は、約定データに有効な署名が付与されていれば、汎用データ掲示板から読み出した新規約定データは正規なデータであると扱う。

以上のように、第１の実施形態に係る電子取引システムでは、参加者は、自身の入札データを取引管理サーバ１０の公開鍵により暗号化し、汎用データ掲示板に登録する。暗号化された入札データを復号できるのは、秘密鍵を有する取引管理サーバ１０であり、参加者（参加者端末２０）は、その内容を知ることができない。その結果、入札に係る情報の秘密やプライバシが保持され、第１の実施形態に係る電子取引システムは公平な取引を提供できる。

また、第１の実施形態に係る電子取引システムでは、ブロックチェーン技術により実現される電子掲示板（汎用データ掲示板）を介して電力取引データ（入札データ、約定データ）のやり取りを行う。その結果、取引管理サーバ１０による約定データに対する不正（データの書き換え等）等を防止することができる。

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

第１の実施形態では、電力取引システムにおいて、商業的に機微な情報である、取引価格や取引量を秘匿可能とするシステムについて説明した。しかし、第１の実施形態に係る電子取引システムでは、取引管理サーバ１０による不正を許す余地がある。例えば、不正の意図を持った取引管理サーバ１０は、本来約定すべきでない取引を約定させることができる。

第２の実施形態では、このような取引管理サーバ１０の不正な行為を防止するための電子取引システムに関して説明する。

図１４は、第２の実施形態に係る電子取引システムの構成の一例を示す図である。図１４に示すように、第２の実施形態に係る電子取引システムは、複数の取引管理サーバ１０－１～１０－Ｎ（Ｎは３以上の正の整数、以下同じ）を含む。取引管理サーバ１０－１～１０－Ｎを区別する特段の理由がない場合には、単に「取引管理サーバ１０」と表記する。

なお、上記複数の取引管理サーバ１０の大半（例えば、過半数以上）は、不正な行為を行わないことを前提とする。即ち、システムに含まれる大半の取引管理サーバ１０は、不正な約定処理を行わないものとする。

ここで、複数の取引管理サーバ１０のなかから１台のリーダ装置（メイン装置）が選択される。なお、リーダ装置の選択はシステム管理者が決定し、リーダ装置にその旨を入力してもよいし、取引管理サーバ１０の間で決定されてもよい。例えば、乱数によりリーダ装置が選択されてもよいし、持ち回りによりリーダ装置が選択されてもよい。

あるいは、図１５に示すように、取引管理サーバ１０の上位装置である制御装置５０が、リーダ装置を選択し、当該選択の結果を取引管理サーバ１０（リーダ装置、フォロワー装置）に通知してもよい。

電子取引システムに含まれる複数の取引管理サーバ１０のうち、リーダ装置以外の取引管理サーバ１０のそれぞれはフォロワー装置（サブ装置）として動作する。少なくとも複数のフォロワー装置のそれぞれは、未約定な入札データを管理するための電子掲示板（後述する取引データ掲示板）を形成する。

以降の説明において、リーダ装置による約定処理の結果を「仮約定データ」と表記する。

リーダ装置となった取引管理サーバ１０は、データ管理システム３０が提供する汎用データ掲示板から読み出した新規な入札データに対して約定処理を実行する。リーダ装置は、約定処理の結果（約定、未約定）と汎用データ掲示板から読み出した新規入札データを他の取引管理サーバ１０（複数のフォロワー装置）に送信する。その際、リーダ装置は、約定処理の結果に署名を付与する。

リーダ装置は、上記署名付きの仮約定データを複数のフォロワー装置に一斉送信（ブロードキャスト）する。あるいは、リーダ装置は、予め定められた順番で上記署名付きの仮約定データをフォロワー装置に送信してもよい。

例えば、図１４に示すように、取引管理サーバ１０－１がリーダ装置として動作する場合には、取引管理サーバ１０－１は、自身の署名を付した仮約定データを、取引管理サーバ１０－２、１０－３、・・・、１０－Ｎに向けて送信する。

ここで、複数の取引管理サーバ１０は、データ管理システム３０が提供する電子掲示板（汎用データ掲示板）とは異なる独自の電子掲示板を構成する。なお、本願開示において、取引管理サーバ１０が構成する電子掲示板を「取引データ掲示板」と表記する。取引管理サーバ１０が構成する電子掲示板は、取引データ管理台帳を基礎として構成される。なお、取引データ掲示板もブロックチェーン技術を用いて運用、管理される。

リーダ装置を含む複数の取引管理サーバ１０のそれぞれは、上記取引データ管理台帳を用いて第１の実施形態で説明した「入札管理テーブル」の情報を記憶する。換言すれば、入札管理テーブルの情報は、取引データ掲示板に書き込まれる。

フォロワー装置は、リーダ装置から取得した仮約定データの正当性を検証する。

はじめに、フォロワー装置のそれぞれは、リーダ装置から取得した仮約定データに付与された署名の検証を行う。各フォロワー装置は、仮約定データに付与された署名が不当であれば、仮約定データを破棄する。各フォロワー装置は、仮約定データに付与された署名が正当であれば、当該仮約定データの正当性を検証する。

具体的には、各フォロワー装置は、自身が保持する取引データ管理台帳に記載された入札管理テーブルとリーダ装置から取得した新規入札データを用いて約定処理を行う。各フォロワー装置は、当該自身の約定結果とリーダ装置から受信した仮約定データの結果が一致するか否かを判定する。

各フォロワー装置は、２つの約定結果が一致すれば、仮約定データの検証結果を「受け入れ可」に設定する。対して、各フォロワー装置は、２つの約定結果が不一致であれば、仮約定データの検証結果を「受け入れ不可」に設定する。

各フォロワー装置は、自身の検証結果（受け入れ可、受け入れ不可）を他のフォロワー装置（リーダ装置を除く他の取引管理サーバ１０）に一斉送信（ブロードキャスト）する。なお、各フォロワー装置は、上記検証結果に署名を付与し、当該署名が付与された検証結果をブロードキャストする。

各フォロワー装置は、他のフォロワー装置から検証結果を取得すると、当該検証結果に付与された署名を検証する。各フォロワー装置は、署名の検証に失敗すれば、取得した検証結果を破棄する。各フォロワー装置は、署名の検証に成功すれば、仮約定データに対する受け入れ可否に関する合意形成処理を行う。

具体的には、各フォロワー装置は、システムに含まれるフォロワー装置（自装置も含むフォロワー装置；リーダ装置以外のフォロワー装置）の一定数以上の装置による検証結果が、「仮約定データは受け入れ可」であるか否かを確認する。なお、上記仮約定データの受け入れ可否を決める一定数は、合意形成の方式に応じて変化する。

例えば、ＭｉｎＢＦＴ合意形成プロトコルが用いられ、且つ、電子取引システムに含まれる取引管理サーバ１０の数は６（Ｎ＝６）の場合を考える。ＭｉｎＢＦＴ合意形成プロトコルでは、上記一定数は「過半数」である。また、システムに含まれるフォロワー装置の数は５である。従って、５台のフォロワー装置のうち３台以上のフォロワー装置が、「仮約定データは受け入れ可」という結果を得たか否かが判断される。

複数のフォロワー装置のうち一定数以上のフォロワー装置が、「仮約定データは受け入れ可」という結論であれば、リーダ装置による約定処理の結果（仮約定データ）は正当であると判断され、その旨の合意が形成される。この場合、各フォロワー装置は、自身で管理する取引データ管理台帳（入札管理テーブル）に、新規入札データと仮約定データを反映する。

複数のフォロワー装置のうち一定数以上のフォロワー装置が、「仮約定データは受け入れ可」という結論でなければ、リーダ装置による約定処理の結果（仮約定データ）は不当であると判断され、その旨の合意が形成される。この場合、各フォロワー装置は、リーダ装置から取得した仮約定データ、新規入札データを破棄する。

リーダ装置は、仮約定データを送信してから所定期間経過後に、各フォロワー装置により形成される取引データ掲示板にアクセスする。リーダ装置は、取引データ掲示板に新規入札データ、仮約定データが反映されているか確認する。

リーダ装置は、仮約定データ等の内容が取引データ掲示板に反映されていれば、自身の約定処理結果に対するフォロワー装置の合意が得られたものと判断する。この場合、リーダ装置は、自身の取引データ管理台帳に新規入札データ及び仮約定データを反映する。さらに、リーダ装置は、約定処理の結果を必要に応じて汎用データ掲示板に書き込む。具体的には、リーダ装置は、第１の実施形態にて説明した約定データを汎用データ掲示板に書き込む。

リーダ装置は、仮約定データ等の内容が取引データ掲示板に反映されていなければ、自身の約定処理結果に対するフォロワー装置の合意が得られなかったと判断する。この場合、リーダ装置は、予め定められたエラー処理（例えば、所定回数のリトライ処理等）を行う。

このように、複数のフォロワー装置のそれぞれは、リーダ装置の約定結果の正当性を検証する。また、複数のフォロワー装置のそれぞれは、リーダ装置の約定結果が正当であるとの合意を他のフォロワー装置との間で得られた場合に、リーダ装置の約定結果を取引データ掲示板に反映する。リーダ装置は、自身の約定結果が電子掲示板（取引データ掲示板）に書き込まれた場合に、自身の約定結果をデータ管理システム３０が提供する電子掲示板（汎用データ掲示板）に反映する。

図１６は、第２の実施形態に係る取引管理サーバ１０の処理構成（処理モジュール）の一例を示す図である。図１６を参照すると、第１の実施形態に係る取引管理サーバ１０に台帳制御部２０８及び仮約定データ検証部２０９が追加となっている。

台帳制御部２０８は、第１の実施形態と同様に、台帳（取引データ管理台帳）を制御する手段である。

仮約定データ検証部２０９は、リーダ装置から取得した仮約定データの受け入れ可否を検証する手段である。

なお、複数の取引管理サーバ１０のそれぞれは、秘密鍵及び公開鍵（入札データの復号用の秘密鍵と公開鍵）を必要とするが、これらの鍵は各取引管理サーバ１０で共有することができる。例えば、リーダ装置が秘密鍵及び公開鍵の鍵ペアを作成し、フォロワー装置に当該鍵ペアを配布すればよい。

はじめに、取引管理サーバ１０がリーダ装置として動作する場合について説明する。

この場合、取引実行部２０４が、新規入札データと約定処理の結果（仮約定データ）を他のフォロワー装置に送信する。その後、所定期間経過後、取引実行部２０４は、取引データ掲示板にアクセスし、仮約定データ等が反映されているか否かを確認する。仮約定データ等が取引データ掲示板に反映されていれば、取引実行部２０４は、その旨を台帳制御部２０８及びデータ管理部２０２に通知する。

台帳制御部２０８は、新規入札データ及び仮約定データを自身の管理する取引データ管理台帳に反映する。

データ管理部２０２は、必要に応じて、通信制御部２０１を介して、約定データをデータ管理システム３０に送信する。その際、データ管理部２０２は、約定結果（約定データ）と共に、ポインタを管理サーバ４０に送信する。当該送信されたポインタは汎用データ掲示板に記録される。上記ポインタの詳細は後述する。

なお、リーダ装置の取引実行部２０４は、上記仮約定データを送信すると、当該仮約定データの送信（トランザクション）を特定するトランザクションＩＤを管理サーバ４０（データ管理システム３０）に送信する。当該トランザクションＩＤは、汎用データ掲示板に記録される。即ち、リーダ装置は、自身の約定結果を複数のフォロワー装置に送信した際のトランザクションＩＤを汎用データ掲示板に書き込む。

続いて、取引管理サーバ１０がフォロワー装置として動作する場合について説明する。

この場合、通信制御部２０１は、リーダ装置から仮約定データ及び新規入札データを取得すると、これらのデータを仮約定データ検証部２０９に引き渡す。

仮約定データ検証部２０９は、新規入札データを取引実行部２０４に引き渡すと共に、当該新規入札データを用いた約定処理の実行を指示する。仮約定データ検証部２０９は、取引実行部２０４から約定結果を（新規入札データは約定、未約定）を得る。仮約定データ検証部２０９は、仮約定データの結果と取引実行部２０４による結果に基づいて、「仮約定データ受け入れ可」又は「仮約定データ受け入れ不可」を決定する。

仮約定データ検証部２０９は、検証結果（受け入れ可、受け入れ不可）を他のフォロワー装置に向けて送信する。

仮約定データ検証部２０９は、他のフォロワー装置から受信した検証結果に基づいて、リーダ装置による約定処理の結果（仮約定データ）は正当であるか否かを判断する。仮約定データ検証部２０９は、自装置を含む一定数以上のフォロワー装置が「仮約定データは受け入れ可」と判断した場合には、仮約定データは正当であると判断する。この場合、リーダ装置による約定結果が正当である旨の合意が他のフォロワー装置との間で形成されたものと判断し、仮約定データ検証部２０９は、新規入札データ及び仮約定データを台帳制御部２０８に引き渡す。台帳制御部２０８は、これらのデータを取引データ掲示板に書き込む（入札管理テーブルに反映する）。

続いて、図面を参照しつつ、第２の実施形態に係る取引管理サーバ１０の動作を説明する。

図１７は、第２の実施形態に係る取引管理サーバ（リーダ装置、フォロワー装置）１０の動作の一例を示すシーケンス図である。

リーダ装置は、汎用データ掲示板から新規入札データを取得する（ステップＳ３１）。

リーダ装置は、当該新規入札データを用いて約定処理を実行する。リーダ装置は、約定処理の結果（新規入札データは約定、新規入札データは未約定）を仮約定データとしてフォロワー装置に送信する（ステップＳ３２）。その際、リーダ装置は、汎用データ掲示板から取得した新規入札データもフォロワー装置に送信する。

各フォロワー装置は、リーダ装置から取得した仮約定データの検証を行う（ステップＳ３３）。具体的には、各フォロワー装置は、取得した仮約定データと自身が管理する入札管理テーブルに基づき、約定処理を実行する。

各フォロワー装置は、リーダ装置から取得した仮約定データの結果と自身の約定処理の結果を比較する。２つの処理結果が一致すれば、各フォロワー装置は、「仮約定データは受け入れ可」という検証結果に設定する。２つの処理結果が不一致であれば、各フォロワー装置は、「仮約定データは受け入れ不可」という検証結果に設定する。

各フォロワー装置は、仮約定データの検証結果を他のフォロワー装置に送信する（ステップＳ３４）。

各フォロワー装置は、他のフォロワー装置から送信（ブロードキャスト）される検証結果に基づき、仮約定データに関する合意形成処理を実行する（ステップＳ３５）。具体的には、各フォロワー装置は、一定数以上のフォロワー装置による検証結果が「仮約定データは受け入れ可」であればリーダ装置による約定結果は正当であると判定する。この場合、リーダ装置による約定処理は正当である旨の合意がフォロワー装置間で形成されたものと判定される。

リーダ装置による約定処理が正当である旨の合意が形成されると、各フォロワー装置は、リーダ装置による約定処理の結果を取引データ掲示板に反映する（ステップＳ３６）。

リーダ装置は、仮約定データ等をフォロワー装置に送信してから所定期間の経過後、取引データ掲示板にアクセスし、自身の約定結果（仮約定データ）が当該掲示板に反映されているか否かを確認する（ステップＳ３７）。

リーダ装置は、自身の約定結果が正しく取引データ掲示板に反映されていれば、新規入札データ及び仮約定データの内容を自身の取引データ管理台帳にも反映する（ステップＳ３８）。

リーダ装置は、自身の約定処理の承認が得られると（仮約定データの正当性が確認されると）、必要に応じて約定データを汎用データ掲示板に書き込む（図１７に図示せず）。

続いて、図面を参照しつつ第２の実施形態に係る電子取引システムの動作を説明する。図１８は、第２の実施形態に係る電子取引システムの動作の一例を示すシーケンス図である。図１８において、第１の実施形態に係る電子取引システムの動作と同一とすることができる動作には同じ符号（ステップ名）を与え、説明を省略する。具体的には、第１及び第２の実施形態では、ステップＳ１１～Ｓ１７を同一とすることができるので、これらの処理に関する詳細な説明を省略する。

複数の取引管理サーバ１０のうちリーダ装置は、新規入札データを用いた約定処理を実行する（ステップＳ４１）。

リーダ装置は、約定処理の結果（仮約定データ）と新規入札データを含むトランザクションを生成し、他の取引管理サーバ１０（フォロワー装置）に送信する（ステップＳ４２）。

リーダ装置は、上記生成したトランザクションに対応するトランザクションＩＤを管理サーバ４０に送信する（ステップＳ４３）。

上記トランザクションＩＤを受信した管理サーバ４０は、受信したトランザクションＩＤを電子掲示板（汎用データ管理台帳）に記録する（ステップＳ４４）。

リーダ装置からトランザクションを受信したフォロワー装置は、リーダ装置の約定処理に関する検証及び合意形成に関する処理を行う（ステップＳ４５）。これらの処理については、図１７等を用いて説明した内容と重複するので更なる説明を省略する。

リーダ装置は、電子掲示板（取引データ掲示板）にアクセスし、自身の約定処理が承認されたか否かを確認する。具体的には、リーダ装置は、取引データ掲示板にアクセスし、自身の約定結果が電子掲示板に反映されているか否かを確認する（ステップＳ４６、Ｓ４７）。

リーダ装置は、取引データ掲示板の新規記録を参照することで、自身の約定結果が取引データ掲示板に反映されていることを確認すると、約定結果とその約定結果へのポインタを管理サーバ４０に送信する（ステップＳ４８）。管理サーバ４０は、受信した約定結果とそのポインタを汎用データ掲示板に記録する（ステップＳ４９）。

約定結果へのポインタは、例えば、取引データ掲示板を構成するブロックチェーンのブロックのヘッダーである。リーダ装置は、自身の約定処理の結果が反映されたブロックのヘッダーを「約定結果へのポインタ」として汎用データ掲示板に記録する。なお、ブロックのヘッダーは、ブロックの内容とその前のブロックのヘッダーのハッシュ値である。従って、事後的にブロックの内容が変更されれば、当該ブロックの変更はブロックヘッダーを参照することで検知可能である。

上記説明したように、リーダ装置は、仮約定データをフォロワー装置に送信すると当該仮約定データを含むトランザクションのＩＤを汎用データ掲示板に書き込む。また、リーダ装置は、上記仮約定データに対する約定結果がフォロワー装置により承認されると、約定結果へのポインタ（例えば、入力データと出力データのハッシュ値）を汎用データ掲示板に書き込む。

このように、リーダ装置が、ブロックチェーンへのインプットトランザクションと約定結果へのポインタを汎用データ掲示板に記載することで、取引データ管理台帳に不当な結果が記載（取引の内容が改竄）されたとしても第３者は当該不正行為を検知できる。具体的には、第３者は、汎用データ掲示板に記載された情報に従い約定処理を実行し上記ポインタと同じハッシュ値（入力データと出力データのハッシュ値）を計算する。その後、第３者は、当該計算されたハッシュ値と汎用データ掲示板に記載されたハッシュ値を比較し、２つのハッシュ値が一致を確認することで取引管理サーバ１０の不正行為がないことを確認できる。

上記不正行為の検知は、例えば、複数の取引管理サーバ１０（複数のフォロワー装置）の過半数以上が不正な処理をしないという前提がくずれ、不当な約定結果が取引データ掲示板に記載された場合に有効である。つまり、取引管理サーバ１０が不正行為を行うと、汎用データ掲示板に書き込まれるハッシュ値（リーダ装置が汎用データ掲示板に書き込むポインタ）と汎用データ掲示板の情報を遡って得られるハッシュ値が不一致となる。第３者は、このような不一致の不無を検証することで、取引管理サーバ１０による不正行為（取引内容の改竄；例えば、約定すべきデータが約定しない、あるいは、約定すべきではないデータが約定する）を検知できる。

図１８に示すステップＳ５０及びＳ５１の処理は、図１３に示すステップＳ２１及びＳ２２の処理と同一とすることができる。

以上のように、第２の実施形態に係る電子取引システムは、複数の取引管理サーバ１０を含む。当該複数の取引管理サーバ１０が、１台の取引管理サーバ１０による約定処理を監視し、正規な約定結果であると合意が形成されたデータが取引データ掲示板に書き込まれる。その結果、１台の取引管理サーバ１０による不正行為（不正操作）を防止できる。より厳密には、過半数以上の取引管理サーバ１０が正常に動作している場合、正しい約定処理が行われることが担保できる。

また、約定結果へのポインタが汎用データ掲示板に記録されることで、取引データ管理台帳の内容が改竄された場合であっても、参加者を含む第３者は、当該改竄を検知できる。即ち、第２の実施形態では、２種類の電子掲示板（ブロックチェーン）を用いて、電子取引が実行される。第１の電子掲示板は、全ての参加者から見える（アクセスできる）掲示板であり、第２の電子掲示板は、取引管理者だけが見える（アクセスできる）掲示板である。第２の実施形態では、これら２つの電子掲示板を用途に応じて使い分け、取引の安全と不正検知を両立させている。

続いて、電子取引システムを構成する各装置のハードウェアについて説明する。図１９は、取引管理サーバ１０のハードウェア構成の一例を示す図である。

取引管理サーバ１０は、情報処理装置（所謂、コンピュータ）により構成可能であり、図１９に例示する構成を備える。例えば、取引管理サーバ１０は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

但し、図１９に示す構成は、取引管理サーバ１０のハードウェア構成を限定する趣旨ではない。取引管理サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、取引管理サーバ１０に含まれるプロセッサ３１１等の数も図１９の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１が取引管理サーバ１０に含まれていてもよい。

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

取引管理サーバ１０の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

なお、参加者端末２０、管理サーバ４０等も取引管理サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は取引管理サーバ１０と相違する点はないので説明を省略する。

［変形例］
なお、上記実施形態にて説明した電子取引システム、各種サーバ等の構成、動作は例示であって、システムの構成等を限定する趣旨ではない。例えば、リーダ装置はフォロワー装置としての機能も備えていてもよい。即ち、リーダ装置が取引データ掲示板を形成するサーバ群（複数のフォロワー装置）の一部として動作してもよい。この場合、リーダ装置も合意形成に参加するので、合意形成に必要なフォロワー装置の数が１台少なくなる。そのため、例えば「過半数以上」のフォロワー装置の合意が必要な場合には、「半数以上」のフォロワー装置の合意が必要となる。なぜなら、リーダ装置の約定処理が「受け入れ可」としていると取り扱われると、「受け入れ可」が全ての取引管理サーバ１０の過半数以上になるためである。

あるいは、第２の実施形態に係る取引管理サーバ１０を機能の面から説明すると、図２０に示すように、リーダ装置は取引実行装置６０として動作し、フォロワー装置は取引検証装置７０として動作する。

また、上記実施形態では、リーダ装置も取引データ掲示板を形成するための台帳を備える場合について説明したが、リーダ装置は当該台帳を備えていなくともよい。即ち、リーダ装置は、約定処理の実行に必要なデータを、複数のフォロワー装置が提供する取引データ掲示板から取得してもよい。

また、リーダ装置の取引実行機能やフォロワー装置の約定結果に対する検証機能はスマートコントラクトにより実現されてもよい。即ち、ブロックチェーンを構成する取引管理サーバ１０に、上記説明した取引実行機能や検証機能がスマートコントラクトにより実装されていてもよい。

また、上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
第１の電子掲示板を提供する、複数の管理サーバ（４０、１０１）と、
入札データを前記第１の電子掲示板に書き込む、参加者端末（２０、１０２）と、
前記書き込まれた入札データを取得し、前記取得された入札データを用いてザラバ方式により取引を実行する、取引管理サーバ（１０、１０３）と、
を含み、
前記取引管理サーバ（１０、１０３）は、公開鍵及び秘密鍵を生成し、
前記参加者端末（２０、１０２）は、前記取引管理サーバ（１０、１０３）が生成した公開鍵を用いて前記入札データを暗号化し、
前記取引管理サーバ（１０、１０３）は、前記秘密鍵を用いて前記暗号化された入札データを復号する、電子取引システム。
［付記２］
前記取引管理サーバ（１０、１０３）は、約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記第１の電子掲示板に書き込む、付記１に記載の電子取引システム。
［付記３］
前記参加者端末（２０、１０２）は、前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、付記２に記載の電子取引システム。
［付記４］
前記複数の管理サーバ（４０、１０１）は、相互に直接接続され、
前記複数の管理サーバ（４０、１０１）のそれぞれは、外部から受信したデータを管理するためのデータ管理台帳を有し、
前記参加者端末（２０、１０２）と前記取引管理サーバ（１０、１０３）からデータ記録要求を受信するたびに前記データ管理台帳にデータを追記する、付記１乃至３のいずれか一つに記載の電子取引システム。
［付記５］
複数の前記取引管理サーバ（１０、１０３）を含み、
前記複数の取引管理サーバ（１０、１０３）のうち１台の取引管理サーバ（１０、１０３）はリーダ装置として動作し、前記リーダ装置以外の取引管理サーバ（１０、１０３）のそれぞれはフォロワー装置として動作し、
少なくとも前記複数のフォロワー装置のそれぞれは、未約定な入札データを管理するための第２の電子掲示板を形成し、
前記リーダ装置は、前記第１の電子掲示板から取得した入札データを用いて約定処理を実行すると共に、前記第１の電子掲示板から取得した入札データと約定結果を前記複数のフォロワー装置に送信し、
前記複数のフォロワー装置のそれぞれは、前記リーダ装置の約定結果の正当性を検証すると共に、前記リーダ装置の約定結果が正当であるとの合意を他のフォロワー装置との間で得られた場合に、前記リーダ装置の約定結果を前記第２の電子掲示板に反映する、付記１乃至４のいずれか一つに記載の電子取引システム。
［付記６］
前記リーダ装置は、自身の約定結果が前記第２の電子掲示板に反映された場合に、自身の約定結果を前記第１の電子掲示板に反映する、付記５に記載の電子取引システム。
［付記７］
前記複数のフォロワー装置の一定数以上のフォロワー装置が前記リーダ装置の約定結果は正当であると判断した場合に、前記リーダ装置の約定結果は正当である旨の合意が形成される、付記５又は６に記載の電子取引システム。
［付記８］
前記複数のフォロワー装置のそれぞれは、前記リーダ装置の約定結果と、前記リーダ装置から取得した入札データ及び前記第２の電子掲示板に格納された未約定な入札データを用いた約定処理の結果と、が一致する場合に、前記リーダ装置の約定結果は正当であると判定する、付記７に記載の電子取引システム。
［付記９］
前記複数のフォロワー装置のそれぞれは、自身の約定結果を他のフォロワー装置に送信する、付記８に記載の電子取引システム。
［付記１０］
前記リーダ装置は、自身の約定結果を前記複数のフォロワー装置に送信した際のトランザクションＩＤを前記第１の電子掲示板に書き込む、付記５乃至９のいずれか一つに記載の電子取引システム。
［付記１１］
前記リーダ装置は、前記第２の電子掲示板を形成するブロックチェーンのブロックのうち自身の約定結果が反映されたブロックのヘッダーを約定結果へのポインタとして前記第１の電子掲示板に書き込む、付記５乃至１０のいずれか一つに記載の電子取引システム。
［付記１２］
前記複数のフォロワー装置が有する少なくとも、リーダ装置の約定結果に対する検証機能はスマートコントラクトにより実現される、付記５乃至１１のいずれか一つに記載の電子取引システム。
［付記１３］
公開鍵及び秘密鍵を生成し、
電子掲示板を提供する複数の管理サーバ（４０、１０１）と、前記公開鍵を用いて暗号化された入札データを前記電子掲示板に書き込む参加者端末（２０、１０２）と、に接続され、
前記書き込まれた入札データを取得し、前記暗号化された入札データを前記秘密鍵により復号すると共に、前記入札データを用いてザラバ方式により取引を実行する、取引管理サーバ（１０、１０３）。
［付記１４］
電子掲示板を提供する、複数の管理サーバ（４０、１０１）と、
入札データを前記電子掲示板に書き込む、参加者端末（２０、１０２）と、
前記書き込まれた入札データを取得し、前記取得された入札データを用いてザラバ方式により取引を実行する、取引管理サーバ（１０、１０３）と、
を含む電子取引システムにおいて、
公開鍵及び秘密鍵を生成するステップと、
前記取引管理サーバ（１０、１０３）が生成した公開鍵を用いて前記入札データを暗号化するステップと、
前記秘密鍵を用いて前記暗号化された入札データを復号するステップと、
を含む電子取引方法。
［付記１５］
公開鍵及び秘密鍵を生成し、
電子掲示板を提供する複数の管理サーバ（４０、１０１）と、前記公開鍵を用いて暗号化された入札データを前記電子掲示板に書き込む参加者端末（２０、１０２）と、に接続された取引管理サーバ（１０、１０３）に搭載されたコンピュータ（３１１）に、
前記書き込まれた入札データを取得する処理と、
前記暗号化された入札データを前記秘密鍵により復号する処理と、
前記入札データを用いてザラバ方式により取引を実行する処理と、
を実行させるプログラム。
なお、付記１３の形態～付記１５の形態は、付記１の形態と同様に、付記２の形態～付記１２の形態に展開することが可能である。

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。

１０、１０－１～１０－Ｎ、１０３ 取引管理サーバ
２０、２０－１～２０－Ｌ、１０２ 参加者端末
３０ データ管理システム
４０、４０－１～４０－Ｍ、１０１ 管理サーバ
５０ 制御装置
６０ 取引実行装置
７０ 取引検証装置
２０１、３０１、４０１ 通信制御部
２０２ データ管理部
２０３ 復号部
２０４ 取引実行部
２０５、３０３ 鍵生成部
２０６、４０３ 署名検証部
２０７、３０４、４０４ 記憶部
２０８、４０２ 台帳制御部
２０９ 仮約定データ検証部
３０２ 入札データ管理部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス

Claims (11)

1. ブロックチェーン技術を用いて単一の第１の電子掲示板を提供する、複数の管理サーバと、
   入札データを前記第１の電子掲示板に書き込む、参加者端末と、
   前記書き込まれた入札データを取得し、前記取得された入札データと過去に取得済みの他の入札データとの比較結果に応じて、前記入札データで示される取引を実行する、複数の取引管理サーバと、
   を含み、
   前記取引管理サーバは、公開鍵及び秘密鍵を生成し、
   前記参加者端末は、前記取引管理サーバが生成した公開鍵を用いて前記入札データを暗号化して、前記暗号化した入札データを前記第１の電子掲示板に送信し、
   前記取引管理サーバは、前記秘密鍵を用いて前記暗号化された入札データを復号することにより、前記書き込まれた入札データを取得し、
   前記複数の取引管理サーバのうち１台の取引管理サーバはリーダ装置として動作し、前記リーダ装置以外の取引管理サーバは複数のフォロワー装置として動作し、
   少なくとも前記複数のフォロワー装置のそれぞれは、前記リーダ装置により実行される約定処理が実行されていない未約定な入札データを管理するためのブロックチェーン技術を用いた単一の第２の電子掲示板を形成し、
   前記リーダ装置は、前記第１の電子掲示板から取得した複数の入札データの比較結果に応じて仮約定処理を実行すると共に、前記仮約定処理に用いた複数の入札データと前記仮約定処理による仮約定結果を前記複数のフォロワー装置に送信し、
   前記複数のフォロワー装置のそれぞれは、前記リーダ装置から受信した入札データを用いて約定処理を実行することにより前記リーダ装置の仮約定結果の正当性を検証すると共に、他のフォロワー装置と通信することにより、前記他のフォロワー装置により前記リーダ装置から受信した入札データを用いた約定処理による仮約定結果の検証に基づく前記リーダ装置の仮約定結果が正当であるとの合意を前記他のフォロワー装置との間で得られた場合に、前記リーダ装置の仮約定結果を正当な約定結果として前記第２の電子掲示板に書き込み、
   前記リーダ装置は、前記第２の電子掲示板を形成するブロックチェーンのブロックのうち自身の約定結果が書き込まれたブロックの内容と直前ブロックのヘッダーのハッシュ値を、前記第２の電子掲示板に書き込まれた約定結果へのポインタとして、前記第１の電子掲示板に書き込む、電子取引システム。
2. 前記入札データは、売り手入札データと買い手入札データを区別する売買種別データと、当該入札データを特定するＩＤ（Identifier）とを含み、
   前記取引管理サーバは、約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記第１の電子掲示板に書き込む、請求項１に記載の電子取引システム。
3. 前記参加者端末は、前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、請求項２に記載の電子取引システム。
4. 前記複数の管理サーバは、Ｐ２Ｐ（Peer to Peer）接続され、
   前記複数の管理サーバのそれぞれは、
   データを管理するためのデータ管理台帳を有し、
   前記参加者端末からの入札データと前記取引管理サーバからの取引結果データを前記第１の電子掲示板に書き込むためのデータ記録要求を受信するたびに前記データ管理台帳にデータを追記する、
   請求項１乃至３のいずれか一項に記載の電子取引システム。
5. 前記リーダ装置は、自身の約定結果が前記第２の電子掲示板に書き込まれた場合に、自身の約定結果を前記第１の電子掲示板に書き込む、請求項１乃至４のうちいずれか一項に記載の電子取引システム。
6. 前記複数のフォロワー装置の各々により前記リーダ装置から取得した入札データを用いた約定処理による仮約定結果の検証に基づき、前記複数のフォロワー装置の一定数以上のフォロワー装置が前記リーダ装置の仮約定結果は正当であると判断した場合に、前記リーダ装置の約定結果は正当である旨の合意が形成される、請求項１乃至５のうち何れか一項に記載の電子取引システム。
7. 前記複数のフォロワー装置のそれぞれは、前記リーダ装置の仮約定結果と、前記リーダ装置から取得した入札データ及び前記第２の電子掲示板に格納された未約定な入札データを用いた約定処理の結果と、が一致する場合に、前記リーダ装置の仮約定結果は正当であると判定する、請求項６に記載の電子取引システム。
8. 前記複数のフォロワー装置のそれぞれは、前記リーダ装置から取得した入札データを用いた約定処理による仮約定結果の検証結果を他のフォロワー装置に送信する、請求項７に記載の電子取引システム。
9. 前記リーダ装置は、前記仮約定処理に用いた複数の入札データと前記仮約定処理による仮約定結果を、トランザクションＩＤとともに、前記複数のフォロワー装置に送信し、当該送信した際のトランザクションＩＤを前記第１の電子掲示板に書き込む、請求項１乃至８のいずれか一項に記載の電子取引システム。
10. 前記複数のフォロワー装置が有する少なくとも、前記リーダ装置の仮約定結果に対する検証機能はスマートコントラクトにより実現される、請求項１乃至９のいずれか一項に記載の電子取引システム。
11. ブロックチェーン技術を用いて単一の第１の電子掲示板を提供する、複数の管理サーバと、
    入札データを前記電子掲示板に書き込む、参加者端末と、
    前記書き込まれた入札データを取得し、前記取得された入札データと過去に取得済みの他の入札データとの比較結果に応じて、前記入札データで示される取引を実行する、複数の取引管理サーバと、
    を含む電子取引システムにおいて、
    公開鍵及び秘密鍵を生成するステップと、
    前記取引管理サーバが生成した公開鍵を用いて前記入札データを暗号化して、前記暗号化した入札データを前記第１の電子掲示板に送信するステップと、
    前記秘密鍵を用いて前記暗号化された入札データを復号することにより、前記書き込まれた入札データを取得するステップと、
    前記複数の取引管理サーバのうち１台の取引管理サーバがリーダ装置として動作し、前記リーダ装置以外の取引管理サーバは複数のフォロワー装置として動作するステップと
    少なくとも前記複数のフォロワー装置のそれぞれが、前記リーダ装置により実行される約定処理が実行されていない未約定な入札データを管理するためのブロックチェーン技術を用いた単一の第２の電子掲示板を形成するステップと、
    前記リーダ装置が、前記第１の電子掲示板から取得した複数の入札データの比較結果に応じて仮約定処理を実行すると共に、前記仮約定処理に用いた複数の入札データと前記仮約定処理による仮約定結果を前記複数のフォロワー装置に送信するステップと、
    前記複数のフォロワー装置のそれぞれが、前記リーダ装置から受信した入札データを用いて約定処理を実行することにより前記リーダ装置の仮約定結果の正当性を検証すると共に、他のフォロワー装置と通信することにより、前記他のフォロワー装置により前記リーダ装置から受信した入札データを用いた約定処理による仮約定結果の検証に基づく前記リーダ装置の仮約定結果が正当であるとの合意を前記他のフォロワー装置との間で得られた場合に、前記リーダ装置の仮約定結果を正当な約定結果として前記第２の電子掲示板に書き込むステップと、
    前記リーダ装置が、前記第２の電子掲示板を形成するブロックチェーンのブロックのうち自身の約定結果が書き込まれたブロックの内容と直前ブロックのヘッダーのハッシュ値を、前記第２の電子掲示板に書き込まれた約定結果へのポインタとして、前記第１の電子掲示板に書き込むステップと、を含む電子取引方法。

Images