(57)【要約】  公平な取引を提供する電子取引システムを提供する。電子取引システムは、複数の管理サーバと、端末と、取引サーバと、含む。複数の管理サーバは、電子掲示板を提供する。端末は、暗号化された価格を含む入札データを電子掲示板に書き込む。取引サーバは、書き込まれた入札データを取得し、暗号化された価格を復号し、復号された価格を用いてザラバ方式により取引を実行する。
2019186978.tif 000002
【特許請求の範囲】
【請求項１】
電子掲示板を提供する、複数の管理サーバと、
暗号化された価格を含む入札データを前記電子掲示板に書き込む、端末と、
前記書き込まれた入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバと、
を含む、電子取引システム。
【請求項２】
未約定な入札データの暗号化された価格と、前記取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバをさらに備える、請求項１の電子取引システム。
【請求項３】
前記取引サーバは、
約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記電子掲示板に書き込む、請求項２の電子取引システム。
【請求項４】
前記端末は、
前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、請求項３の電子取引システム。
【請求項５】
前記端末は、前記検証サーバに対して、検証対象となる入札データのＩＤを含む検証データ生成要求を送信し、
前記検証サーバは、前記検証データ生成要求の受信に応じて前記検証データを生成し、前記生成された検証データを前記電子掲示板に書き込む、請求項４の電子取引システム。
【請求項６】
前記端末は、
前記書き込まれた検証データを取得し、前記検証データに含まれる検証文字列を検証関数に入力し、前記検証関数の出力結果に基づき、前記取引サーバによる前記検証対象の入札データの取引が正当であったか否かを判定する、請求項５の電子取引システム。
【請求項７】
前記取引サーバの取引の正当性に関する検証は、前記端末が入札データの価格を知ることはできず、且つ、前記取引サーバによる取引の正当性を検証可能とする、零知識証明である、請求項６の電子取引システム。
【請求項８】
前記検証サーバは、
売り入札データが約定しなかったことに関する前記検証データを生成する場合には、
未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高いという、第１命題を証明する前記検証文字列を生成する、請求項２乃至７のいずれか一項に記載の電子取引システム。
【請求項９】
前記検証サーバは、
売り入札データが約定したことに関する前記検証データを生成する場合には、
約定した買い入札データの買値は未約定な買い入札データの買値最高額である、という第２命題を証明する前記検証文字列と、
検証対象とする売り入札データの売値は未約定な買い入札データの買値最高額以下である、という第３命題を証明する前記検証文字列と、を生成する、請求項２乃至８のいずれか一項に記載の電子取引システム。
【請求項１０】
前記検証サーバは、
買い入札データが約定しなかったことに関する前記検証データを生成する場合には、
未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低いという、第４命題を証明する前記検証文字列を生成する、請求項２乃至９のいずれか一項に記載の電子取引システム。
【請求項１１】
前記検証サーバは、
買い入札データが約定したことに関する前記検証データを生成する場合には、
約定した売り入札データの売値は未約定な売り入札データの売値最低額である、という第５命題を証明する前記検証文字列と、
検証対象とする買い入札データの買値は未約定な売り入札データの売値最低額以上である、という第６命題を証明する前記検証文字列と、を生成する、請求項２乃至１０のいずれか一項に記載の電子取引システム。
【請求項１２】
前記複数の管理サーバは、相互に直接接続され、
前記複数の管理サーバのそれぞれが、外部から受信したデータを管理するためのデータ管理台帳を有し、外部の装置からデータを電子掲示板に書き込む旨の要求を取得するたびに、前記データ管理台帳にデータを追記する、請求項１乃至１１のいずれか一項に記載の電子取引システム。
【請求項１３】
端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバ。
【請求項１４】
端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、未約定な入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバ。
【請求項１５】
取引サーバにおいて、
端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得するステップと、
前記暗号化された価格を復号するステップと、
前記復号された価格を用いてザラバ方式により取引を実行するステップと、
を含む、電子取引方法。
【請求項１６】
取引サーバに搭載されたコンピュータに、
端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得する処理と、
前記暗号化された価格を復号する処理と、
前記復号された価格を用いてザラバ方式により取引を実行する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムに関する。
【背景技術】
【０００２】
近年、通信技術や情報処理技術の発展と共に、ネットワーク上にて種々のサービスが提供されている。例えば、特許文献１には、ネットワークを用いた電子取引システムが開示されている。また、特許文献２、特許文献３及び非特許文献１には、電力の売買をネットワーク上で行うためのシステムが開示されている。【０００３】
ネットワーク上で取引等を行う場合には、情報漏洩や不正の防止が重要となる。この点に関して、特許文献４には、各サーバの出力が入力に対して適正な処理を行った後にその順序を置換したものであることをより少ない計算量、通信量で効率的に証明、検証する方法及び装置を提供する、と記載されている。【０００４】
非特許文献２及び非特許文献３は、ある暗号文の平文が所定の範囲（レンジ）に収まることを、平文を明かさずに証明する手法を開示している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第２００２−２１５９３５号公報
【特許文献２】特許第６１７７４１０号公報
【特許文献３】特許第６２３４５４０号公報
【特許文献４】特開２００１−２１７８２４号公報
【非特許文献】
【０００６】
【非特許文献１】田中謙司等、“ブロックチェーンを用いた電力融通取引プラットフォームの一提案”、２０１８年１月２３日、ＳＣＩＳ２０１８
【非特許文献２】Jan Camenisch, etc、"Efficient Protocols for Set Membership and Range Proofs"、2008、Proceedings of the 14th International Conference on the Theory and Application of Cryptology and Information Security, 234-252
【非特許文献３】ODED GOLDREICH, etc、"Proofs that Yield Nothing But Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems"、July 1991、Journal of the ACM (JACM) Volume 38
【発明の概要】
【発明が解決しようとする課題】
【０００７】
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。【０００８】
上述のように、ネットワーク上では種々のサービスが提供されている。特に、非特許文献１には、電力取引にブロックチェーンを活用する技術が開示されている。非特許文献１の技術によれば、個々のユーザが自身の電力消費量や発電量に基づき、電力の過不足を推定し、ブロックチェーン上で電力取引を行うことで電力融通が実現できる。【０００９】
しかし、非特許文献１では、個々の発注情報（入札データ）は平文で登録されており、少なくとも電力融通システムの参加者は、他人の発注状況を把握可能となっている。他人の発注状況が把握可能であると、公平な取引を損なう可能性がある。例えば、売買する意志は無いにもかかわらず、大量の買い入札を行いあたかも電力需要が旺盛であるかのように見せかけ、有利な価格で売電を実現するような不正を許しかねない。【００１０】
本発明は、公平な取引を提供することに寄与する電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【００１１】
本発明乃至開示の第１の視点によれば、電子掲示板を提供する、複数の管理サーバと、暗号化された価格を含む入札データを前記電子掲示板に書き込む、端末と、前記書き込まれた入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバと、を含む、電子取引システムが提供される。【００１２】
本発明乃至開示の第２の視点によれば、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバが提供される。【００１３】
本発明乃至開示の第３の視点によれば、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得し、前記暗号化された価格を復号し、前記復号された価格を用いてザラバ方式により取引を実行する、取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、未約定な入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバが提供される。【００１４】
本発明乃至開示の第４の視点によれば、取引サーバにおいて、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得するステップと、前記暗号化された価格を復号するステップと、前記復号された価格を用いてザラバ方式により取引を実行するステップと、を含む、電子取引方法が提供される。【００１５】
本発明乃至開示の第５の視点によれば、取引サーバに搭載されたコンピュータに、端末が複数の管理サーバにより提供される電子掲示板に書き込んだ、暗号化された価格を含む入札データを取得する処理と、前記暗号化された価格を復号する処理と、前記復号された価格を用いてザラバ方式により取引を実行する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００１６】
本発明乃至開示の各視点によれば、公平な取引を提供することに寄与する電子取引システム、取引サーバ、検証サーバ、電子取引方法及びプログラムが、提供される。
【図面の簡単な説明】
【００１７】
【図１】一実施形態の概要を説明するための図である。
【図２】第１の実施形態に係る電子取引システムの構成の一例を示す図である。
【図３】第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。
【図４】入札データを説明するための図である。
【図５】約定データの一例を示す図である。
【図６】データ管理システムが提供する電子掲示板に書き込まれたデータの一例を示す図である。
【図７】第１の実施形態に係る取引サーバのハードウェア構成の一例を示すブロック図である。
【図８】第１の実施形態に係る取引サーバの処理構成の一例を示すブロック図である。
【図９】入札管理テーブルの一例を示す図である。
【図１０】取引実行部の動作の一例を示すフローチャートである。
【図１１】取引実行部の動作の一例を示すフローチャートである。
【図１２】第１の実施形態に係る端末の処理構成の一例を示すブロック図である。
【図１３】第２の実施形態に係る電子取引システムの構成の一例を示す図である。
【図１４】第２の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。
【図１５】第２の実施形態に係る端末の処理構成の一例を示す図である。
【図１６】第２の実施形態に係る検証サーバの処理構成の一例を示す図である。
【図１７】第２の実施形態に係る検証サーバの動作を説明するための図である。
【図１８】第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。
【図１９】第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。
【図２０】第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。
【図２１】第２の実施形態に係る端末の検証動作の一例を示すフローチャートである。
【発明を実施するための形態】
【００１８】
初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。
【００１９】
一実施形態に係る電子取引システムは、複数の管理サーバ１０１と、端末１０２と、取引サーバ１０３と、含む（図１参照）。複数の管理サーバ１０１は、電子掲示板を提供する。端末１０２は、暗号化された価格を含む入札データを電子掲示板に書き込む。取引サーバ１０３は、書き込まれた入札データを取得し、暗号化された価格を復号し、復号された価格を用いてザラバ方式（価格優先、時間優先）により取引を実行する。
【００２０】
上記電子取引システムにおいて、端末１０２は、入札データを、例えば、取引サーバ１０３の公開鍵により暗号化し、電子掲示板に登録する。暗号化された入札データを復号できるのは、秘密鍵を有する取引サーバ１０３であり、他の参加者は、その内容を知ることができない。その結果、入札に係る情報の秘密が保持され、上記電子取引システムは公平な取引を提供できる。
【００２１】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
【００２２】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００２３】
［システム構成概略］
図２は、第１の実施形態に係る電子取引システムの構成の一例を示す図である。図２を参照すると、電子取引システムは、取引サーバ１０と、複数の端末２０−１〜２０−Ｎ（Ｎは正の整数、以下同じ）と、データ管理システム３０と、を含んで構成される。
【００２４】
取引サーバ１０、端末２０−１〜２０−Ｎ及びデータ管理システム３０のそれぞれは、インターネット等のネットワークを介して相互に接続されている。
【００２５】
電子取引システムの取引対象は特に限定されないが、本願開示では主に「電力」を取引の対象として説明を行う。但し、本願開示の電子取引システムは、株式等の金融商品等の取引にも適用可能である。
【００２６】
取引サーバ１０は、電力の買い手と売り手の注文を仲介する装置である。
【００２７】
端末２０−１〜２０−Ｎは、電力取引の参加者が使用する端末である。例えば、パーソナルコンピュータやスマートフォン等の情報処理装置が、上記端末に相当する。なお、以降の説明において、端末２０−１〜２０−Ｎを区別する特段の理由が無い場合には、単に「端末２０」と表記する。
【００２８】
また、端末２０の使用者が買電を希望する場合に、当該使用者が利用する端末を「買い手端末」と表記する。同様に、端末２０の使用者が売電を希望する場合に、当該使用者が利用する端末を「売り手端末」と表記する。
【００２９】
データ管理システム３０は、取引サーバ１０の運営主体や電力取引の参加者（入札者；売り手、買い手）から独立した立場の機関等が運営するシステムである。データ管理システム３０は、外部（第３者）に対し追記及び読み出しの可能な電子掲示板を提供するシステムである。より具体的には、データ管理システム３０は、どのような主体でも情報を追記できると共に、書き込まれた情報を読み出すことができ、且つ、一度書き込まれた情報は消去されたり改竄されたりすることのない電子掲示板を提供する。データ管理システム３０は、所謂、ブロックチェーンと称される技術により上記特徴を持つ電子掲示板を提供する。
【００３０】
図２に示す電子取引システムでは、電力取引に必要な情報（以下、電力取引データと表記する）の授受を、ブロックチェーンにより実現される電子掲示板を介して行う。なお、上述のように、データ管理システム３０は、いずれの主体に対しても電子掲示板を提供するシステムであるため、当該電子掲示板には上記電力取引データとは無関係なデータが混在することとなる。
【００３１】
データ管理システム３０は、複数の管理サーバ４０−１〜４０−４から構成されている。なお、図２の例示は、データ管理システム３０を構成する管理サーバの台数を４台に限定する趣旨ではない。データ管理システム３０は２台以上の管理サーバを含んで構成されていればよい。また、端末２０と同様に、管理サーバ４０−１〜４０−４を区別する特段の理由がない場合には、単に「管理サーバ４０」と表記する。
【００３２】
データ管理システム３０をなす複数の管理サーバ４０は、図２に示すように、相互に直接接続されている。即ち、データ管理システム３０は、Ｐ２Ｐ（Peer to Peer）接続された複数の管理サーバ４０を含んで構成される。
【００３３】
データ管理システム３０では、Ｐ２Ｐ接続された複数の管理サーバ４０それぞれが、外部から受信したデータ（例えば、電力取引データ）を管理するためのデータ管理台帳を有する。データ管理システム３０は、当該データ管理台帳を複数の管理サーバ４０に分散し共有して、管理する。
【００３４】
データ管理システム３０をなす管理サーバ４０は、取引サーバ１０や端末２０から電力取引データを電子掲示板に書き込む旨の要求を取得するたびに、データ管理台帳に当該電力取引データを追記する。また、各管理サーバ４０は、当該データ管理台帳に追記するデータの正当性を証明するデータを生成する。具体的には、管理サーバ４０は、上記追記データの正当性を証明するデータとして各管理サーバ４０の電子署名（デジタル署名）を用いるものとする。
【００３５】
電子署名の生成が終了すると、管理サーバ４０は、データ管理台帳への追記データに電子署名を付して、他の管理サーバ４０に配布する。他の管理サーバ４０は、当該追記データを受信すると、その正当性を検証した後に自身のデータ管理台帳を更新する。
【００３６】
［システム動作概略］
次に、図面を参照しつつ、第１の実施形態に係る電子取引システムの動作概略を説明する。
【００３７】
図３は、第１の実施形態に係る電子取引システムの動作概略の一例を示すシーケンス図である。
【００３８】
売電を希望する参加者は、売買の種別（売り注文）、自身を特定する識別子（参加者ＩＤ；IDentifier）と、売却を希望する電力量（数量）と、売却希望額（価格）、を含む「売り手入札データ」を電子掲示板に書き込む（売り手入札；ステップＳ０１）。
【００３９】
その際、売り手端末は、売り手入札データを取引サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４（ａ）に示すデータが暗号化され、電子掲示板に書き込まれる。
【００４０】
同様に、買電を希望する参加者は、売買の種別（買い注文）、自身を特定する参加者ＩＤ、購入を希望する電力量と、購入希望額、を含む「買い手入札データ」を電子掲示板に書き込む（買い手入札；ステップＳ０２）。
【００４１】
買い手端末は、買い手入札データを取引サーバ１０の公開鍵で暗号化し、データ管理システム３０に送信する。例えば、図４（ｂ）に示すデータが暗号化され、電子掲示板に書き込まれる。
【００４２】
端末２０は、図４に示す４つの項目（売買種別、参加者ＩＤ、数量、価格）の全てを暗号化せずに、数量だけを暗号化してもよい。少なくとも数量が暗号化されていれば取引の安全は確保できるためである。このように、第１の実施形態に係る端末２０は、暗号化された価格を含む入札データを電子掲示板に書き込む。
【００４３】
なお、以降の説明において、売り手入札データと買い手入札データを区別する必要が無い場合には、単に「入札データ」と表記する。
【００４４】
取引サーバ１０は、電子掲示板に定期的にアクセスし、入札データを取得する（ステップＳ０３）。
【００４５】
取得した入札データは暗号化されているので、取引サーバ１０は、自身の秘密鍵を用いて取得した入札データの暗号文を復号する（ステップＳ０４）。
【００４６】
取引サーバ１０は、予め定めたタイミング等で、取得した入札データを用いた取引を実行する（ステップＳ０５）。取引サーバ１０による取引処理の詳細は後述する。
【００４７】
取引サーバ１０は、取引結果を電子掲示板に書き込む。
【００４８】
なお、電子掲示板に入札データが書き込まれると、当該入札データを特定するためのトランザクションＩＤ（以下、ＴＸＩＤと表記する）が付与される。取引サーバ１０は、当該ＴＸＩＤを利用して取引結果を電子掲示板に書き込む。具体的には、取引サーバ１０は、売り入札と買い入札が成立（約定）した場合には、当該約定した入札データのＴＸＩＤを含むデータを「約定データ」として電子掲示板に書き込む（図５参照）。
【００４９】
また、取引サーバ１０は、約定したＴＸＩＤを指定し、当該ＴＸＩＤを取引の場から削除した旨の削除データを電子掲示板に書き込む。当該削除データにより、端末２０は、取引の場に残る入札データ（未約定な入札データ）を把握することができる。
【００５０】
売り手と買い手は、電子掲示板にアクセスし、約定データを取得し、取引結果を確認する（ステップＳ０６、ステップＳ０７）。つまり、端末２０（売り手端末、買い手端末）は、電子掲示板に書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する。
【００５１】
端末２０は、約定データを参照することで、自身の入札データの状態（約定、未約定）を把握できる。あるいは、端末２０は、削除データを確認することによっても自身の入札が約定したか否かを確認できる。
【００５２】
端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応するものであれば、自身の入札が約定したことを把握できる。一方、端末２０は、約定データに記載されたＴＸＩＤが自身の入札に対応したものでなければ、自身の入札は約定せず、未約定な入札として電子掲示板（取引の場）に残っていることが把握できる。
【００５３】
例えば、図６に示すような電力取引データ（入札データ、約定データ）が電子掲示板に書き込まれているとする。図６は、ＴＸＩＤが「０１」、「０２」の売り入札が行われ、その後、ＴＸＩＤが「０３」の買い入札が行われていることを示している。その後、ＴＸＩＤが「０１」の売り入札とＴＸＩＤが「０３」の買い入札が約定し、ＴＸＩＤが「０４」の約定データとして電子掲示板に書き込まれている。なお、図６に示す「ＰＩＤ」は参加者ＩＤを示す。
【００５４】
取引サーバ１０、端末２０は、図６に示すような電力取引データ（入札データ、約定データ）を確認することで、ＴＸＩＤが「０２」の売り入札は未約定な入札データとして電子掲示板に残っていることも確認できる。
【００５５】
つまり、取引サーバ１０は、システム稼働時からの電子掲示板に書き込まれた電力取引データをトレースすることで最新の入札状況（未約定な状態で残っている入札データ）を把握することができる。同様に、端末２０は、電子掲示板に書き込まれた電力取引データをトレースすることで、最新の入札状況を把握することができる。
【００５６】
但し、端末２０は、自身の入札に関する状況（約定済み、未約定）を把握することができるが、入札データは暗号化されているため、電子掲示板に残っている入札データの詳細（少なくとも価格の詳細）を知ることはできない。
【００５７】
［ハードウェア構成］
次に、第１の実施形態に係る電子取引システムを構成する各種装置のハードウェア構成を説明する。
【００５８】
図７は、第１の実施形態に係る取引サーバ１０のハードウェア構成の一例を示すブロック図である。
【００５９】
取引サーバ１０は、情報処理装置（コンピュータ）により構成可能であり、図７に例示する構成を備える。例えば、取引サーバ１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インターフェイス１３及び通信手段であるＮＩＣ（Network Interface Card）１４等を備える。
【００６０】
但し、図７に示す構成は、取引サーバ１０のハードウェア構成を限定する趣旨ではない。取引サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス１３を備えていなくともよい。また、取引サーバ１０に含まれるＣＰＵ等の数も図７の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ１１が取引サーバ１０に含まれていてもよい。
【００６１】
メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）である。
【００６２】
入出力インターフェイス１３は、図示しない表示装置や入力装置のインターフェイスとなる手段である。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
【００６３】
取引サーバ１０の機能は、後述する各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ１２に格納されたプログラムをＣＰＵ１１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段があればよい。
【００６４】
なお、端末２０や管理サーバ４０も取引サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は取引サーバ１０と相違する点は無いので説明を省略する。
【００６５】
［取引サーバの処理構成］
次に、取引サーバ１０の詳細について説明する。取引サーバ１０は、電子掲示板に書き込まれた入札データを取得し、暗号化された価格を復号する。さらに、取引サーバ１０は、復号された価格を用いてザラバ方式により取引を実行する。
【００６６】
図８は、第１の実施形態に係る取引サーバ１０の処理構成の一例を示すブロック図である。図８を参照すると、取引サーバ１０は、通信制御部２０１と、データ管理部２０２と、復号部２０３と、取引実行部２０４と、記憶部２０５と、を含んで構成される。
【００６７】
通信制御部２０１は、ＮＩＣ１４を制御し、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部２０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
【００６８】
記憶部２０５は、メモリ１２により実現され、各処理モジュールの処理に必要な情報等を記憶する手段である。
【００６９】
データ管理部２０２は、電子掲示板にアクセスし、電力取引データ（入札データ、約定データ、削除データ）を管理する手段である。データ管理部２０２は、電子掲示板に定期的にアクセスし、電子掲示板に新規に書き込まれた（取引サーバ１０が一度も取得していない）入札データを取得する。データ管理部２０２は、取得した入札データを復号部２０３に引き渡す。また、データ管理部２０２は、取引実行部２０４による取引結果（約定データ、削除データ）を、通信制御部２０１を介して電子掲示板に書き込む。
【００７０】
復号部２０３は、取引サーバ１０の公開鍵で暗号化されている入札データを復号する手段である。より具体的には、復号部２０３は、暗号化されている入札データを、秘密鍵を用いて復号し、復号結果（平文の入札データ）を記憶部２０５に格納する。
【００７１】
取引実行部２０４は、入札データを用いた取引（電力取引）を実行する手段である。取引実行部２０４は、所謂、ザラバ方式と称される手法により電力取引を実現する。より具体的には、取引実行部２０４は、多数の売り入札と買い入札のなかで価格と数量が一致したものから順に取引を成立させていく。
【００７２】
より具体的には、取引実行部２０４は、「価格優先の原則」と「時間優先の原則」に従って取引を成立させていく。例えば、買い注文（買い入札）であれば、安い価格の買い注文よりも高い価格の買い注文が優先され、売り注文であれば、高い価格の売り注文よりも安い価格の売り注文が優先されて取引が成立する。同じ価格の注文の場合には、より早く入札があった方が優先され取引が成立する。
【００７３】
取引実行部２０４は、「入札管理テーブル」を用いて入札状況（未約定な入札データ）を管理し、当該テーブルを用いて取引を実行する。入札管理テーブルとは、売り注文、買い注文それぞれについて、未約定な入札価格を順に並べたテーブル情報である。
【００７４】
図９は、入札管理テーブルの一例を示す図である。図９に示すように、未約定な入札データの数量が価格順に並べられ、管理される。なお、図９を含む図面において、数量（売り数量、買い数量）や価格の単位を記載していないが、これらの単位は任意とすることができる。例えば、数量の単位は「ｋＷｈ」とし、価格の単位は「１円」とすることができる。
【００７５】
取引実行部２０４又はデータ管理部２０２が、システム稼働時からの電子掲示板に書き込まれた電力取引データをトレースすることで図９に示すような入札管理テーブルを作成できる。
【００７６】
ここで、上述のように、取引実行部２０４による電力取引は、価格優先の原則と時間優先の原則に従って行われる。そのため、図９に示すような価格と数量だけの単純な組み合わせによる管理ではなく、実際には、各価格に含まれる入札データの詳細が管理されている。例えば、図９の吹き出しに記載したように、価格ごとに未約定な入札データの詳細（参加者ＩＤ、数量、入札時間）が管理される。
【００７７】
なお、参加者ＩＤ及び数量は入札データに記載された情報を用いればよい。入札時間に関しては、入札データの生成日時（タイムスタンプ）を用いればよい。また、取引実行部２０４が、売り入札と買い入札を約定させた場合には、当該約定の結果を入札管理テーブルに反映する。
【００７８】
続いて、図１０及び図１１を参照しつつ、取引実行部２０４の動作を説明する。
【００７９】
取引実行部２０４は、記憶部２０５に格納された入札データを取得し、入札時間（タイムスタンプ）が古い入札データから順に処理をしていく。
【００８０】
その際、取引実行部２０４は、入札データが「売り手入札データ」であった場合には、図１０に示すフローチャートに従って処理をする。取引実行部２０４は、入札データが「買い手入札データ」であった場合には、図１１に示すフローチャートに従って処理をする。
【００８１】
初めに、入札データが「売り手入札データ」である場合の取引実行部２０４の動作を説明する。
【００８２】
図１０に示すステップＳ１０１において、取引実行部２０４は、処理対象となる売り手入札データの売値（売却希望額）が入札管理テーブルにより管理される買値（購入希望額）の最高額以下であるか否かを判定する。例えば、図９に示す例では、売値と買値の最高額である「１９」の大小が比較される。
【００８３】
売値が買値の最高額よりも高ければ（ステップＳ１０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の売り手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ１０２）。
【００８４】
売値が買値の最高額以下であれば（ステップＳ１０１、Ｙｅｓ分岐）、取引実行部２０４は、売り数量（売却希望電力量）が買値最高額の数量以下であるか否かを判定する（ステップＳ１０３）。例えば、図９に示す例では、売り数量と買値最高額の数量である「４０」の大小が比較される。
【００８５】
売り数量が買値最高額の数量以下であれば（ステップＳ１０３、Ｙｅｓ分岐）、取引実行部２０４は、買い入札の入札時間の古い順に約定する（ステップＳ１０４）。例えば、図９に示す例では、売り数量が「３０」であれば、売り入札と、入札時間の最も古い買い入札（入札時間；１２：０１）及び２番目に古い買い入札（入札時間；１２：１０）と、が約定する。
【００８６】
取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ１０５）。
【００８７】
売り数量が買値最高額の数量より大きければ（ステップＳ１０３、Ｎｏ分岐）、取引実行部２０４は、対象となる売り入札の売り数量の全てを買値最高額にて約定する（ステップＳ１０６）。
【００８８】
取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ１０７）。
【００８９】
ステップＳ１０８において、取引実行部２０４は、売り手入札データの売り数量のうち、ステップＳ１０６の処理にて約定しなかった売り数量が存在するか否かを判定する。例えば、図９に示す例では、売り数量が「５０」であれば、買値最高額である「１９」にて売り数量「４０」が約定し、売り数量の残は「１０」となる。
【００９０】
売り数量の残が存在すれば（ステップＳ１０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ１０１に戻り処理を継続する。具体的には、取引実行部２０４は、一部の売り数量が約定した結果が反映された入札管理テーブルを用いて、売り残が処理される。例えば、上記の例では、売り残の数量「１０」は、価格「１８」の買い入札と約定することになる。
【００９１】
売り数量の残が存在しなければ（ステップＳ１０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。
【００９２】
次に、入札データが「買い手入札データ」である場合の取引実行部２０４の動作を説明する。
【００９３】
図１１に示すステップＳ２０１において、取引実行部２０４は、処理対象となる買い手入札データの買値（購入希望額）が入札管理テーブルにより管理される売値（売却希望額）の最低額以上であるか否かを判定する。
【００９４】
買値が売値の最低額よりも低ければ（ステップＳ２０１、Ｎｏ分岐）、取引実行部２０４は、処理対象の買い手入札データを入札管理テーブルに反映し、処理を終了する（ステップＳ２０２）。
【００９５】
買値が売値の最低額以上であれば（ステップＳ２０１、Ｙｅｓ分岐）、取引実行部２０４は、買い数量（購入希望電力量）が売値最低額の数量以下であるか否かを判定する（ステップＳ２０３）。
【００９６】
買い数量が売値最低額の数量以下であれば（ステップＳ２０３、Ｙｅｓ分岐）、取引実行部２０４は、売り手入札の入札時間の古い順に約定する（ステップＳ２０４）。
【００９７】
取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映し、処理を終了する（ステップＳ２０５）。
【００９８】
買い数量が売値最低額の数量より大きければ（ステップＳ２０３、Ｎｏ分岐）、取引実行部２０４は、対象となる買い入札の買い数量の全てを売値最低額にて約定する（ステップＳ２０６）。
【００９９】
取引実行部２０４は、取引結果（約定結果）を入札管理テーブルに反映する（ステップＳ２０７）。
【０１００】
ステップＳ２０８において、取引実行部２０４は、買い手入札データの買い数量のうち、ステップＳ２０６の処理にて約定しなかった買い数量が存在するか否かを判定する。
【０１０１】
買い数量の残が存在すれば（ステップＳ２０８、Ｙｅｓ分岐）、取引実行部２０４は、ステップＳ２０１に戻り処理を継続する。
【０１０２】
買い数量の残が存在しなければ（ステップＳ２０８、Ｎｏ分岐）、取引実行部２０４は、処理を終了する。
【０１０３】
取引実行部２０４は、データ管理部２０２が新たに取得した入札データに関する処理を終了すると、必要に応じて取引結果（約定データ、削除データ）を記憶部２０５に記憶する。データ管理部２０２は、取引実行部２０４による上記取引結果（約定データ、削除データ）を、通信制御部２０１を介して電子掲示板に書き込む。
【０１０４】
［端末の処理構成］
次に、端末２０の詳細について説明する。
【０１０５】
図１２は、第１の実施形態に係る端末２０の処理構成の一例を示すブロック図である。図１２を参照すると、端末２０は、通信制御部３０１と、入札データ管理部３０２と、記憶部３０３と、を含んで構成される。
【０１０６】
通信制御部３０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部３０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
【０１０７】
記憶部３０３は、各処理モジュールの処理に必要な情報等を記憶する手段である。
【０１０８】
入札データ管理部３０２は、入札データ（売り手入札データ、買い手入札データ）に関する管理を行う手段である。具体的には、入札データ管理部３０２は、ユーザ（売り手、買い手）による操作に応じて、図４に示すような入札データを生成する。
【０１０９】
さらに、入札データ管理部３０２は、生成した入札データを取引サーバ１０の公開鍵を用いて暗号化する。入札データ管理部３０２は、当該暗号化された入札データを電子掲示板に書き込む。
【０１１０】
また、入札データ管理部３０２は、電子掲示板に記載された約定データを取得する。取得した約定データが自身の入札データに付与されたＴＸＩＤを有するものであれば、入札データ管理部３０２は、自身の入札は約定したものと判断する。その際、入札データ管理部３０２は、約定結果を液晶ディスプレイに表示する等の対応を行ってもよい。
【０１１１】
［管理サーバ］
データ管理システム３０をなす管理サーバ４０は、ブロックチェーン技術を用いて電子掲示板を提供する装置である。ブロックチェーンを利用した電子掲示板は当業者にとって明らかで有り、その説明を省略する。
【０１１２】
以上のように、第１の実施形態に係る電子取引システムでは、参加者は、自身の入札データを取引サーバ１０の公開鍵により暗号化し、電子掲示板に登録している。暗号化された入札データを復号できるのは、秘密鍵を有する取引サーバ１０であり、参加者（端末２０）は、その内容を知ることができない。その結果、入札に係る情報の秘密が保持され、第１の実施形態に係る電子取引システムは公平な取引を提供できる。
【０１１３】
また、第１の実施形態に係る電子取引システムでは、ブロックチェーン技術により実現される電子掲示板を介して電力取引データ（入札データ、約定データ、削除データ）のやり取りを行う。その結果、取引サーバ１０による約定データに対する不正（データの書き換え等）等を防止することができる。
【０１１４】
［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。
【０１１５】
第１の実施形態では、入札データを暗号化することで、電子取引システムの公正性を確保している。しかし、参加者は、取引サーバ１０により取引（入札の約定、未約定）が正当なものであるか否かを確認することができない。入札データは取引サーバ１０の公開鍵にて暗号化されているため、参加者は、電子掲示板にアクセスしても暗号化された入札データを取得できるに留まるためである。
【０１１６】
換言すれば、取引所（取引サーバ１０の管理者）が本来の取引（例えば、価格優先の原則等）を遂行せず、不正な取引を行う余地がある。例えば、参加者Ａの買値が参加者Ｂの買値よりも高いにもかかわらず、参加者Ｂの入札を優先して約定させるといった取引が生じ得る。第２の実施形態では、このような取引所（取引サーバ１０の管理者）による不正を防止する電子取引システムについて説明する。
【０１１７】
図１３は、第２の実施形態に係る電子取引システムの構成の一例を示す図である。図１３を参照すると、図２に示す第１の実施形態に係る電子取引システムに検証サーバ５０が追加されている。
【０１１８】
検証サーバ５０は、取引サーバ１０による取引の正当性を検証するための情報を提供する装置である。より具体的には、検証サーバ５０は、未約定な入札データの暗号化された価格と、正当性を検証する対象となる入札データの暗号化された価格と、を用いて取引サーバ１０の取引の正当性を検証するための検証文字列を含む検証データを生成する。検証サーバ５０の詳細は後述する。
【０１１９】
第２の実施形態に係る取引サーバ１０の構成、動作は第１の実施形態にて説明した内容と相違する点はないので、取引サーバ１０の図７、図８等に相当する説明を省略する。
【０１２０】
初めに、図１４を参照しつつ、第２の実施形態に係る電子取引システムの動作概要を説明する。図１４において、ステップＳ０７までの処理は図３を参照して説明した内容と同一とすることができるので、その説明を省略する。
【０１２１】
端末２０ａ（売り手端末、買い手端末）は、取引サーバ１０による取引結果（約定データ）が電子掲示板に書き込まれ、当該取引の正当性を検証したい場合に、検証サーバ５０に上記検証データの生成を要求する。具体的には、端末２０ａは、検証を要求する売買の種別と検証対象となる入札データのＴＸＩＤを指定し、検証サーバ５０に対して「検証データ生成要求」を送信する（ステップＳ０８）。なお、図１４では、売り手端末が売り手入札データの処理に関する正当性を検証する場合を図示している。
【０１２２】
検証サーバ５０は、上記検証データ生成要求を受信すると、検証者（端末２０ａ）には各入札データに記載された価格等の情報を与えずに、取引サーバ１０による取引の正当性を検証可能とする検証文字列を生成する。検証サーバ５０は、当該生成した検証文字列を含む情報を「検証データ」として電子掲示板に書き込む（ステップＳ０９）。このように、検証サーバ５０は、検証データ生成要求の受信に応じて検証データを生成し、生成された検証データを電子掲示板に書き込む。
【０１２３】
端末２０ａ（図１４では、売り手端末）は、電子掲示板に書き込まれた検証データを取得し、当該検証データに含まれる検証文字列を用いて取引サーバ１０による取引の正当性を検証する。より具体的には、端末２０ａは、検証データに含まれる検証文字列を後述する検証関数に入力し、当該検証関数の出力結果に基づき、検証サーバ５０による入札データの処理が正当であったか否かを判定する。
【０１２４】
なお、端末２０ａは、自身の入札データが正しく処理されたか否かを検証することはできるが、検証データから上記検証結果以外の情報を得ることはできない。具体的には、端末２０ａは、他者の入札価格等を知ることはできない。即ち、第２の実施形態に係る電子取引システムは、検証サーバ５０を証明者、端末２０ａを検証者とし、端末２０ａに何らの情報を与えることなく、取引サーバ１０による取引の正当性を検証可能とする「零知識証明」を実現する。つまり、検証サーバ５０の取引の正当性に関する検証は、端末２０ａが入札データの価格を知ることはできず、且つ、検証サーバ５０による取引の正当性を検証可能とする、零知識証明である。
【０１２５】
続いて、端末２０ａ及び検証サーバ５０の各装置について説明する。
【０１２６】
［端末の処理構成］
図１５は、第２の実施形態に係る端末２０ａの処理構成の一例を示す図である。図１５を参照すると、第２の実施形態に係る端末２０ａは、取引検証部３０４をさらに備えている。
【０１２７】
取引検証部３０４は、取引サーバ１０の取引に関する正当性を検証する手段である。取引検証部３０４は、電子掲示板から検証データを取得し、当該検証データに含まれる検証文字列を用いて、取引サーバ１０による取引の正当性を検証する。取引検証部３０４の詳細動作は、検証サーバ５０による検証文字列の生成動作と合わせて後述する。
【０１２８】
なお、第２の実施形態に係る端末２０ａの入札データ管理部３０２は、入札データをなす４要素（売買種別、参加者ＩＤ、数量、価格）のうち、少なくとも価格を暗号化する。その際、入札データ管理部３０２は、入札データの価格から取引サーバ１０の公開鍵を用いつつ準同型性を有する暗号文を生成する。第２の実施形態では、準同型性を有する暗号方式により入札データの価格を暗号化することで、暗号化された価格同士の演算を可能とする。
【０１２９】
端末２０ａが、他の要素（例えば、電力量）を暗号化する場合には、入札データ管理部３０２は、当該他の要素を価格とは別に（個別に）暗号化すればよい。
【０１３０】
［検証サーバの処理構成］
続いて、検証サーバ５０の詳細について説明する。なお、検証サーバ５０のハードウェア構成は、取引サーバ１０等と同一とすることができるので説明を省略する。
【０１３１】
検証サーバ５０は、端末２０ａからの検証データ生成要求に応じて取引サーバ１０による取引の正当性を検証可能とする検証文字列を生成し、当該生成した検証文字列を含む検証データを電子掲示板に書き込む。
【０１３２】
図１６は、第２の実施形態に係る検証サーバ５０の処理構成の一例を示す図である。図１６を参照すると、検証サーバ５０は、通信制御部４０１と、検証データ生成部４０２と、記憶部４０３と、を含んで構成される。
【０１３３】
通信制御部４０１は、他の装置（主に、管理サーバ４０）との間の通信を実現する手段である。通信制御部４０１は、他の装置から受信したメッセージ（パケット）を各処理モジュールに振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
【０１３４】
記憶部４０３は、各処理モジュールの処理に必要な情報等を記憶する手段である。
【０１３５】
検証データ生成部４０２は、端末２０ａからの要求に応じて、取引サーバ１０による取引の正当性を検証するための検証データを生成する手段である。検証データ生成部４０２は、検証データ生成要求を受信すると、電子掲示板に登録された電力取引データ（入札データ、約定データ）を用いて、取引サーバ１０による取引の正当性を証明する検証文字列を生成する。
【０１３６】
検証データ生成部４０２は、取引サーバ１０による以下の４つの取引に関する検証データを生成する。
【０１３７】
第１の取引は、売り入札が約定せず、未約定な入札データとして電子掲示板に残る場合である。
【０１３８】
第２の取引は、売り入札が約定し、電子掲示板から消える場合である。
【０１３９】
第３の取引は、買い約定が約定せず、未約定な入札データとして電子掲示板に残る場合である。
【０１４０】
第４の取引は、買い入札が約定し、電子掲示板から消える場合である。
【０１４１】
なお、検証データ生成部４０２は、端末２０ａから取得する情報（検証対象の売買とＴＸＩＤ）と電子掲示板から得られる情報（入札データ、約定データ）から、上記４つの取引のうちいずれが検証対象であるか判断できる。具体的には、検証データ生成部４０２は、端末２０ａから取得した売買種別が「売り」であって、取得したＴＸＩＤが約定データに含まれていなければ、上記第１の取引が対象であると把握できる。同様に、検証データ生成部４０２は、端末２０ａから取得した売買種別が「売り」であって、取得したＴＸＩＤが約定データに含まれていれば、上記第２の取引が対象であると把握できる。
【０１４２】
検証データ生成部４０２は、上記４つの取引の正当性を検証可能とする検証文字列を非特許文献２、３に開示された手法により生成する。非特許文献２、３は、ある暗号文の平文が所定の範囲（レンジ）に収まることを、平文を明かさずに証明する手法を開示している。当業者であれば、当該手法を用いて、２つの暗号文の加算（減算）の結果が所定の範囲（レンジ）に収まることを証明する検証文字列を容易に生成することができる。
【０１４３】
具体的には、上記非特許文献２、３には、上記検証文字列を生成するための生成関数Ｆ、当該生成関数Ｆにより生成された検証文字列Ｓ、検証文字列Ｓによる正当性検証を実現するための検証関数Ｇがそれぞれ開示されている。以下では、生成関数Ｆや検証関数Ｇをそれぞれ１つの関数として記述するが、Ｆ、Ｇは検証データを生成する装置と、検証する装置の間で対話的に処理されるものでもよい。
【０１４４】
生成関数Ｆは、第１暗号、第２暗号、乱数を入力とする。第１暗号、第２暗号のそれぞれは、準同型暗号方式により暗号化された価格である。以下の説明では、第１暗号、第２暗号に対応する価格のＴＸＩＤを用いてこれら２つの暗号を表記する。例えば、ＴＸＩＤが「０１」の価格（暗号化された価格）を第１暗号として表記する場合には、Ｅ１（０１）と表記する。同様に、上記ＴＸＩＤの価格を第２暗号として表記する場合には、Ｅ２（０１）と表記する。また、生成関数Ｆに入力する乱数をＲ１と表記する。
【０１４５】
生成関数Ｆは、下記の式（１）に示すように、上記３つのパラメータの入力に応じて、検証文字列Ｓを生成する。
Ｆ（第１暗号Ｅ１、第２暗号Ｅ２、乱数Ｒ１）＝Ｓ・・・（１）
【０１４６】
ここでは、上記生成関数Ｆは、第１暗号（暗号化された価格）から第２暗号を減算した結果（差分値）が正又はゼロである場合に、検証関数Ｇによる検証結果が「真」となるように設計されている。
【０１４７】
検証関数Ｇは、上記検証文字列Ｓと乱数を入力とする。検証関数Ｇに入力する乱数をＲ２と表記する。検証関数Ｇは、下記の式（２）に示すように、検証文字列Ｓを用いた検証が「真」であるか「偽」であるかを出力する。
Ｇ（Ｓ、Ｒ２）＝真／偽  ・・・（２）
【０１４８】
検証関数Ｇの出力が「真」であることは、検証文字列Ｓの生成条件（第１暗号と第２暗号の差分値が正又はゼロ）が成立していることを証明する。検証関数Ｇの出力が「偽」であることは、検証文字列Ｓの生成条件は不成立であることを証明する。
【０１４９】
以下、取引サーバ１０による上記４つの取引について検証データ生成部４０２の検証データ生成動作と、端末２０ａの取引検証部３０４による検証動作と、を合わせて説明する。
【０１５０】
［第１の取引；売り入札が未約定］
［検証データの生成動作］
第１の取引の正当性を検証可能とするため、検証データ生成部４０２は、
「未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高い」
という命題（以下、第１命題と表記する）を証明する検証文字列を生成する。
【０１５１】
検証データ生成部４０２は、上記第１命題を証明する検証文字列Ｓを、未約定な買い入札データの暗号化された買値を上記第２暗号、検証対象となる売り入札データの暗号化された売値を上記第１暗号としてそれぞれ扱い、検証文字列Ｓを生成する。検証データ生成部４０２は、未約定な買い入札データのそれぞれについて、検証文字列Ｓを生成する。
【０１５２】
検証データ生成部４０２は、生成した複数の検証文字列Ｓと、検証対象となる売り入札データのＴＸＩＤと、を含む検証データを電子掲示板に書き込む。当該検証データにより、検証対象の売り入札データが未約定であることの正当性が検証可能となる。
【０１５３】
例えば、検証対象の売り入札データが電子掲示板に書き込まれる直前の入札状況が図１７（ａ）のとおりとする。また、検証対象の売り入札データは、図１７（ｂ）のとおりとする。なお、図１７（ａ）には、数量のフィールドに未約定な入札データに対応するＴＸＩＤを括弧書きにて併記している。
【０１５４】
図１７に示す状況の場合、検証データ生成部４０２は、未約定な３つの買い入札データそれぞれの暗号化された買値を第２暗号、検証対象の売り入札データの暗号化された売値を第１暗号にそれぞれ設定し、生成関数Ｆを用いて以下の検証文字列Ｓを生成する。
【０１５５】
Ｆ（Ｅ１（３０）、Ｅ２（２１）、Ｒ１）＝Ｓ１（３０、２１）・・・（３）
Ｆ（Ｅ１（３０）、Ｅ２（２２）、Ｒ１’）＝Ｓ２（３０、２２）・・・（４）
Ｆ（Ｅ１（３０）、Ｅ２（２３）、Ｒ１’’）＝Ｓ３（３０、２３）・・・（５）
【０１５６】
上記式（３）〜（５）に記載したＥ１、Ｅ２のそれぞれは、第１暗号及び第２暗号を示し、その括弧内の数字は第１暗号及び第２暗号に設定したＴＸＩＤを示す。また、検証文字列Ｓに続く数字は生成された検証文字列Ｓを区別するためのサフィックスであり、括弧内の数字は生成関数Ｆに入力したＴＸＩＤを示す。なお、検証文字列Ｓの括弧内のＴＸＩＤは、検証データ生成部４０２が、各検証文字列Ｓの生成時に合わせて管理し、生成した検証文字列Ｓと対応付けておく。
【０１５７】
検証データ生成部４０２は、式（３）〜（５）に示す３つの検証文字列Ｓ及び対応するＴＸＩＤを「検証データ」として電子掲示板に書き込む。検証データ生成部４０２は、書き込んだ検証データが検証の対象とした売り入札データを特定するＴＸＩＤも併せて書き込む。
【０１５８】
上記の例では、ＴＸＩＤが「３０」の売り入札データが検証対象の入札データであるので、ＴＸＩＤ＝３０、Ｓ１（３０、２１）、Ｓ２（３０、２２）、Ｓ３（３０、２３）が検証データとして電子掲示板に書き込まれる。
【０１５９】
［第１の取引；売り入札が未約定］
［検証データによる検証動作］
続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図１８を参照しつつ説明する。
【０１６０】
端末２０ａの取引検証部３０４は、検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ３０１）。
【０１６１】
次に、取引検証部３０４は、各検証文字列Ｓに付随するＴＸＩＤを確認し、売り入札時点で未約定であった買い入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ３０２）。
【０１６２】
ＴＸＩＤが一致しなければ（ステップＳ３０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。例えば、電子掲示板には４つの未約定なデータが存在するにも関わらず、３つの検証文字列Ｓが検証データに含まれる場合には、当該検証データは不十分と判断される。この場合、端末２０ａはその旨を検証サーバ５０に通知する等の対応をする。
【０１６３】
ＴＸＩＤが一致すれば（ステップＳ３０２、Ｙｅｓ分岐）、取引検証部３０４は、検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、検証文字列Ｓそれぞれについての真偽を確認する（ステップＳ３０３）。
【０１６４】
取引検証部３０４は、検証関数Ｇによる全ての判定結果が「真」であれば（ステップＳ３０４、Ｙｅｓ分岐）、自身の売り入札データが未約定であることは正当であると判断する（ステップＳ３０５）。全ての判定結果が「真」であるという事実は、自身の売り入札データにおける売値は、売り入札の時点に残る未約定な買い入札データの買値よりも高いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定しないことは、正当と判断できる。
【０１６５】
対して、取引検証部３０４は、検証関数Ｇによる判定結果のうち少なくとも一部の結果が「偽」であれば（ステップＳ３０４、Ｎｏ分岐）、自身の売り入札データが未約定であることは不当であると判断する（ステップＳ３０６）。少なくとも一部の判定結果が「偽」であるという事実は、自身の売り入札データにおける売値よりも買値が高い未約定な買い入札データが存在することを意味する。従って、取引検証部３０４は、自身の売り入札データが約定しないことは、不当と判断できる。
【０１６６】
図１７に示す上述の例では、検証文字列Ｓ１（３０、２１）が真であれば、ＴＸＩＤが「３０」の価格（売り手入札の売値）は、ＴＸＩＤが「２１」の価格（未約定な買値）よりも高いことを示す。同様に、検証文字列Ｓ２（３０、２２）が真であれば、検証対象の売値（ＴＸＩＤ＝３０）は、未約定な買値（ＴＸＩＤ＝２２）よりも高い事を示す。このように、検証文字列Ｓが全て「真」であれば、検証対象の売値（暗号化された売値）が、未約定な買値（暗号化された買値）の全てよりも高いことが証明される。
【０１６７】
［第２の取引；売り入札が約定］
［検証データの生成動作］
続いて、第２の取引に関する検証データの生成について説明する。第２の取引の正当性を証明するには、検証データ生成部４０２は、２つの命題（第２命題、第３命題）を検証可能とする２つの検証文字列を生成する。
【０１６８】
第２命題は、
「約定した買い入札データの買値は、未約定な買い入札データの買値最高額である」
という命題である。
【０１６９】
第３命題は、
「検証対象とする売り入札データの売値が、未約定な買い入札データの買値最高額以下である」
という命題である。
【０１７０】
第２命題により、検証対象の売り入札データが約定する直前の未約定な買い入札データのうち、約定した買い入札データの買値が当該約定時の買値最高額であることが証明され、約定価格の正当性が証明される。また、第３命題により、売り入札データを約定することの正当性が証明される。
【０１７１】
検証データ生成部４０２は、未約定な買い入札データの買値の取り得る組み合わせを算出し、当該組み合わせをなす各買い入札データそれぞれの買値を第１暗号、第２暗号として、第２命題を証明する検証文字列Ｓを生成する。
【０１７２】
その後、検証データ生成部４０２は、生成した複数の検証文字列Ｓに検証関数Ｇを適用して（検証関数Ｇに検証文字列Ｓと乱数を入力して）、その真偽を得る。検証データ生成部４０２は、検証結果が「真」であれば第１暗号の価格が第２暗号の価格よりも高いことが把握できる。また、検証結果が「偽」であれば、検証データ生成部４０２は、第１暗号の価格は第２暗号の価格よりも低いことが把握できる。検証データ生成部４０２は、当該検証結果に基づき、買値が買値最高額であるＴＸＩＤを特定する。
【０１７３】
例えば、図１７の例では、未約定な買い入札データのＴＸＩＤの取り得る組み合わせは、（２１、２２）、（２１、２３）、（２２、２３）である。そこで、検証データ生成部４０２は、これらの各組み合わせについて暗号化された買値を生成関数Ｆに入力する。具体的には、検証データ生成部４０２は、生成関数Ｆを用いて以下の検証文字列Ｓを生成する。
Ｆ（Ｅ１（２１）、Ｅ２（２２）、Ｒ１）＝Ｓ４（２１、２２）・・・（６）
Ｆ（Ｅ１（２１）、Ｅ２（２３）、Ｒ１’）＝Ｓ５（２１、２３）・・・（７）
Ｆ（Ｅ１（２２）、Ｅ２（２３）、Ｒ１’’）＝Ｓ６（２２、２３）・・・（８）
【０１７４】
なお、検証文字列Ｓの括弧内の数字は検証文字列Ｓを生成する際に使用したＴＸＩＤであり、検証データ生成部４０２が、各検証文字列Ｓの生成時に合わせて管理し、生成した検証文字列Ｓと対応付けておく。
【０１７５】
式（６）〜（８）の検証文字列Ｓ４〜Ｓ６を用いた検証結果により、買値が買値最高額であるＴＸＩＤが特定される。例えば、式（６）の検証結果（検証関数Ｇによる真偽）が「真」であれば、ＴＸＩＤが「２１」である買い入札データの買値が、ＴＸＩＤが「２２」である買い入札データの買値より高いことを意味する。式（６）〜（８）の真偽を判定することで、ＴＸＩＤが「２１」の買い入札データの買値が買値最高額であると特定できる。
【０１７６】
検証データ生成部４０２は、買値最高額を上記第１暗号、検証対象の売り入札データの売値を上記第２暗号としてそれぞれ扱い、第３命題を証明する検証文字列Ｓを生成する。
【０１７７】
例えば、図１７の例では、第２命題の検証文字列Ｓを生成した際に、ＴＸＩＤが「２１」の買い入札データの買値が買値最高額であることが判明している。そこで、検証データ生成部４０２は、以下の式（９）で示される検証文字列Ｓを生成する。
Ｆ（Ｅ１（２１）、Ｅ２（３０）、Ｒ１）＝Ｓ７（２１、３０）・・・（９）
【０１７８】
検証データ生成部４０２は、第２命題、第３命題それぞれに対応して生成した検証文字列Ｓ及び対応するＴＸＩＤを電子掲示板に書き込む。その際、検証データ生成部４０２は、書き込んだ検証データが検証の対象とした売り入札データを特定するＴＸＩＤも併せて書き込む。
【０１７９】
上述の例では、ＴＸＩＤが「３０」の売り入札データが検証対象の入札データである。従って、ＴＸＩＤ＝３０、Ｓ４（２１、２２）、Ｓ５（２１、２３）、Ｓ６（２２、２３）、Ｓ７（２１、３０）が検証データとして電子掲示板に書き込まれる。上記検証文字列Ｓ４〜Ｓ７を含むデータが、売り入札データが約定したことの正当性を示す検証データとして電子掲示板に書き込まれる。
【０１８０】
［第２の取引；売り入札が約定］
［検証データによる検証動作］
続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図１９を参照しつつ説明する。
【０１８１】
取引検証部３０４は、第２命題用の検証文字列Ｓと第３命題用の検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ４０１）。
【０１８２】
次に、取引検証部３０４は、第２命題の検証文字列Ｓに付随するＴＸＩＤを確認し、売り入札時点で未約定であった買い入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ４０２）。
【０１８３】
ＴＸＩＤが一致しなければ（ステップＳ４０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。ＴＸＩＤが一致すれば（ステップＳ４０２、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ４０３以降の処理を実行する。
【０１８４】
取引検証部３０４は、第２命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ４０３）。
【０１８５】
取引検証部３０４は、検証関数Ｇによる判定結果（真偽）に応じて、買値が最高額であった買い入札データのＴＸＩＤを特定する（ステップＳ４０４）。具体的には、取引検証部３０４は、検証サーバ５０の検証データ生成部４０２と同様の処理により、買値が買値最高額であるＴＸＩＤを特定する。
【０１８６】
上述の例では、式（６）〜（８）により示される検証文字列Ｓを用いた判定結果により、取引検証部３０４は、ＴＸＩＤが「２１」である買い入札データの買値が買値最高額であると特定する。
【０１８７】
次に、取引検証部３０４は、電子掲示板に書き込まれた約定データにより、自身の売り入札データと約定した買い入札データのＴＸＩＤを特定する（ステップＳ４０５）。
【０１８８】
取引検証部３０４は、上記２つのＴＸＩＤが一致するか否かを判定する（ステップＳ４０６）。
【０１８９】
取引検証部３０４は、検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが不一致の場合（ステップＳ４０６、Ｎｏ分岐）、自身の売り入札データと約定した買い入札データは不当であると判定する（ステップＳ４０７）。２つのＴＸＩＤが異なるという事実は、検証対象の売り入札が、買値最高額以外の買い入札と約定したことを示すためである。
【０１９０】
検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが一致する場合（ステップＳ４０６、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ４０８以降の処理を実行する。ステップＳ４０８以降の処理は、第３命題による検証処理である。
【０１９１】
第２命題の正当性が確認されると、取引検証部３０４は、第３命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ４０８）。
【０１９２】
取引検証部３０４は、検証関数Ｇによる判定結果が「真」であれば（ステップＳ４０９、Ｙｅｓ分岐）、自身の売り入札データが約定したことは正当であると判定する（ステップＳ４１０）。判定結果が「真」であるという事実は、自身の売り入札データにおける売値は、約定した買い入札データの買値最高額よりも安いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定したことは、正当と判断できる。
【０１９３】
対して、取引検証部３０４は、検証関数Ｇによる判定結果が「偽」であれば（ステップＳ４０９、Ｎｏ分岐）、自身の売り入札データが約定したことは不当であると判断する（ステップＳ４０７）。判定結果が「偽」であるという事実は、自身の売り入札データにおける売値は、未約定な買い入札データの買値最高額よりも高いことを意味する。従って、取引検証部３０４は、自身の売り入札データが約定したことは、不当と判断できる。
【０１９４】
図１７に示す上述の例では、検証文字列Ｓ４〜Ｓ６により、「２１」が買値最高額のＴＸＩＤであると特定される。その後、検証文字列Ｓ７により、自身の売り入札の売値（ＴＸＩＤ＝３０）と買値最高額（ＴＸＩＤ＝２１）の大小が検証される。自身の売値よりも買値最高額が高ければ、検証対象の売り入札が約定することは正当と判断できる。
【０１９５】
続いて、検証対象が買い入札データの場合について説明する。検証対象が買い入札の場合も売り入札と同様の手法により取引サーバ１０による取引の正当性が検証できる。例えば、買い入札に関する検証文字列を生成する際、生成関数Ｆに入力する第１暗号、第２暗号を適宜入れ替えることで買い入札に関する正当性を検証可能とする検証文字列を生成できる。
【０１９６】
［第３の取引；買い入札が未約定］
［検証データの生成動作］
第３の取引の正当性を証明するには、検証データ生成部４０２は、
「未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低い」
という命題（以下、第４命題と表記する）を証明する検証文字列を生成する。
【０１９７】
検証データ生成部４０２は、上記第４命題を証明する検証文字列Ｓを、未約定な売り入札データの暗号化された買値を上記第１暗号、検証対象となる買い入札データの暗号化された売値を上記第２暗号としてそれぞれ扱い、検証文字列Ｓを生成する。検証データ生成部４０２は、未約定な売り入札データのそれぞれについて、検証文字列Ｓを生成する。
【０１９８】
検証データ生成部４０２は、生成した複数の検証文字列Ｓと、検証対象となる買い入札データのＴＸＩＤと、を含む検証データを電子掲示板に書き込む。当該検証データにより、検証対象の買い入札データが未約定であることの正当性が検証可能となる。
【０１９９】
［第３の取引；買い入札が未約定］
［検証データによる検証動作］
続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図２０を参照しつつ説明する。
【０２００】
端末２０ａの取引検証部３０４は、検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ５０１）。
【０２０１】
次に、取引検証部３０４は、各検証文字列Ｓに付随するＴＸＩＤを確認し、買い入札時点で未約定であった売り入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ５０２）。
【０２０２】
ＴＸＩＤが一致しなければ（ステップＳ５０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。
【０２０３】
ＴＸＩＤが一致すれば（ステップ５０２、Ｙｅｓ分岐）、取引検証部３０４は、検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、検証文字列Ｓそれぞれについての真偽を確認する（ステップＳ５０３）。
【０２０４】
取引検証部３０４は、検証関数Ｇによる全ての判定結果が「真」であれば（ステップＳ５０４、Ｙｅｓ分岐）、自身の買い入札データが未約定であることは正当であると判断する（ステップＳ５０５）。
【０２０５】
取引検証部３０４は、検証関数Ｇによる判定結果のうち少なくとも一部の結果が「偽」であれば（ステップＳ５０４、Ｎｏ分岐）、自身の買い入札データが未約定であることは不当であると判断する（ステップＳ５０６）。
【０２０６】
［第４の取引；買い入札が約定］
［検証データの生成動作］
第４の取引の正当性を証明するには、検証データ生成部４０２は、２つの命題（第５命題、第６命題）を証明する２つの検証文字列を生成する。
【０２０７】
第５命題は、
「約定した売り入札データの売値は、未約定な売り入札データの売値最低額である」
という命題である。
【０２０８】
第６命題は、
「検証対象とする買い入札データの買値が、未約定な売り入札データの売値最低額以上である」
という命題である。
【０２０９】
第５命題により、検証対象の買い入札データが約定する直前の未約定な売り入札データのうち、約定した売り入札データの売値が当該約定時の売値最低額であることが証明され、約定価格の正当性が証明される。また、第６命題により、買い入札データを約定することの正当性が証明される。
【０２１０】
検証データ生成部４０２は、未約定な売り入札データの売値の取り得る組み合わせを算出し、当該組み合わせをなす各売り入札データそれぞれの売値を第１暗号、第２暗号として、第５命題を証明する検証文字列Ｓを生成する。
【０２１１】
その後、検証データ生成部４０２は、生成した複数の検証文字列Ｓに検証関数Ｇを適用して（検証関数Ｇに検証文字列Ｓと乱数を入力して）、その真偽を得る。検証データ生成部４０２は、検証結果が「真」であれば第１暗号の価格が第２暗号の価格よりも高いことが把握できる。また、検証結果が「偽」であれば、検証データ生成部４０２は、第１暗号の価格は第２暗号の価格よりも低いことが把握できる。検証データ生成部４０２は、当該検証結果に基づき、売値が売値最低額であるＴＸＩＤを特定する。
【０２１２】
検証データ生成部４０２は、売値最低額を上記第２暗号、検証対象の買い入札データの買値を上記第１暗号としてそれぞれ扱い、第６命題を証明する検証文字列Ｓを生成する。
【０２１３】
検証データ生成部４０２は、第５命題、第６命題それぞれに対応して生成した検証文字列Ｓ及び対応するＴＸＩＤを電子掲示板に書き込む。その際、検証データ生成部４０２は、書き込んだ検証データが検証の対象とした買い入札データを特定するＴＸＩＤも併せて書き込む。
【０２１４】
［第４の取引；買い入札が約定］
［検証データによる検証動作］
続いて、上記検証データを用いた取引サーバ１０による取引の正当性検証動作について図２１を参照しつつ説明する。
【０２１５】
取引検証部３０４は、第５命題用の検証文字列Ｓと第６命題用の検証文字列Ｓを含む検証データを電子掲示板から取得する（ステップＳ６０１）。
【０２１６】
次に、取引検証部３０４は、第５命題の検証文字列Ｓに付随するＴＸＩＤを確認し、買い入札時点で未約定であった売り入札データのＴＸＩＤと一致するか否かを判定する（ステップＳ６０２）。
【０２１７】
ＴＸＩＤが一致しなければ（ステップＳ６０２、Ｎｏ分岐）、取引検証部３０４は、検証データは不十分と判断し、処理を終了する。ＴＸＩＤが一致すれば（ステップＳ６０２、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ６０３以降の処理を実行する。
【０２１８】
取引検証部３０４は、第５命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ６０３）。
【０２１９】
取引検証部３０４は、検証関数Ｇによる判定結果（真偽）に応じて、売値が最低額であった売り入札データのＴＸＩＤを特定する（ステップＳ６０４）。
【０２２０】
次に、取引検証部３０４は、電子掲示板に書き込まれた約定データにより、自身の買い入札データと約定した売り入札データのＴＸＩＤを特定する（ステップＳ６０５）。
【０２２１】
取引検証部３０４は、上記２つのＴＸＩＤが一致するか否かを判定する（ステップＳ６０６）。
【０２２２】
取引検証部３０４は、検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが不一致の場合（ステップＳ６０６、Ｎｏ分岐）、自身の買い入札データと約定した売り入札データは不当であると判定する（ステップＳ６０７）。
【０２２３】
検証文字列Ｓから特定したＴＸＩＤと、約定データから特定したＴＸＩＤが一致する場合（ステップＳ６０６、Ｙｅｓ分岐）、取引検証部３０４は、ステップＳ６０８以降の処理を実行する。ステップＳ６０８以降の処理は、第６命題による検証処理である。
【０２２４】
第５命題の正当性が確認されると、取引検証部３０４は、第６命題用の検証文字列Ｓと乱数Ｒ２を検証関数Ｇに入力し、真偽を確認する（ステップＳ６０８）。
【０２２５】
取引検証部３０４は、検証関数Ｇによる判定結果が「真」であれば（ステップＳ６０９、Ｙｅｓ分岐）、自身の買い入札データが約定したことは正当であると判定する（ステップＳ６１０）。
【０２２６】
取引検証部３０４は、検証関数Ｇによる判定結果が「偽」であれば（ステップＳ６０９、Ｎｏ分岐）、自身の買い入札データが約定したことは不当であると判断する（ステップＳ６０７）。
【０２２７】
なお、上記４つの取引に関する検証文字列は、「価格優先の原則」に従って取引サーバ１０が取引を実行しているか検証可能とするものである。取引サーバ１０が「時間優先の原則」に従って取引を実行しているか否かを検証するには、端末２０ａは、各入札データのタイムスタンプを確認すればよい。
【０２２８】
以上のように、第２の実施形態では、検証サーバ５０が取引サーバ１０の取引が正当であるか否かを検証可能とする検証文字列を生成する。取引の正当性を検証したい端末２０ａは、当該検証文字列を用いて取引の正当性を検証する。その際、端末２０ａは、未約定な入札データの価格を知ることはできない。検証文字列から得られる情報は、２つの暗号文の大小に留まるからである。このように、第２の実施形態では、端末２０ａに対して価格に関する何らの情報を与えず、取引サーバ１０による取引の正当性を検証する零知識証明を実現する。換言すれば、取引サーバ１０は、上記零知識証明により端末２０ａから取引を監視されることになり、ザラバ方式の原則に反するような不正を行うことができない。また、暗号化された入札価格は、取引サーバ１０、証明者（検証サーバ５０）及び検証者（端末２０）にて共有されており、取引サーバ１０が入札自体を抹消するような不正はできない。当該不正ができないことは、ブロックチェーン技術を用いた電子掲示板により担保されている。
【０２２９】
［変形例］
なお、第１及び第２の実施形態にて説明した電子取引システムの構成（図２、図１３）は例示であって、システムの構成を限定する趣旨ではない。例えば、検証サーバ５０の機能が取引サーバ１０に組み込まれていてもよい。
【０２３０】
上記実施形態では、端末２０が取引サーバ１０の公開鍵を用いて入札データを暗号化することを説明した。しかし、端末２０それぞれに共通鍵を配布し、端末２０は当該共通鍵を用いて入札データを暗号化してもよい。その場合、端末２０は、参加者ＩＤを暗号化せず、取引サーバ１０にて復号に使用する共通鍵を特定可能とすればよい。本願開示の暗号方式は、公開鍵及び秘密鍵を用いる公開鍵暗号基盤に限定されない。
【０２３１】
上記実施形態では、取引サーバ１０や端末２０がシステム稼働時からの電力取引データをトレースすることで最新の入札状況を把握できることを説明した。しかし、システムの稼働が長期に亘ると入札状況の把握に多大な労力（コスト）が必要となる。そこで、取引サーバ１０等が定期的に最新の入札状況を示すデータ（未約定な入札データの一覧）を電子掲示板に書き込んでもよい。
【０２３２】
上記第２の実施形態では、検証サーバ５０は、端末２０ａからの検証データ生成要求の受信に応じて検証データを生成している。しかし、検証サーバ５０は、検証データ生成要求を受信しなくとも検証データを生成し、電子掲示板に書き込んでもよい。例えば、検証サーバ５０は、取引が約定するたびに、売り入札及び買い入札それぞれの正当性を示す検証データを生成し、電子掲示板に登録してもよい。
【０２３３】
また、上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態は、内容が相反しない範囲で組み合わせることができる。
【０２３４】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係る電子取引システムのとおりである。
［付記２］
未約定な入札データの暗号化された価格と、前記取引サーバによる取引の正当性を検証する対象となる入札データの暗号化された価格と、を用いて前記取引サーバの取引の正当性を検証するための検証文字列を含む検証データを生成する、検証サーバをさらに備える、好ましくは付記１の電子取引システム。
［付記３］
前記取引サーバは、
約定した売り入札データのＩＤ（Identifier）と買い入札データのＩＤを含む約定データを前記電子掲示板に書き込む、好ましくは付記２の電子取引システム。
［付記４］
前記端末は、
前記書き込まれた約定データを取得し、自身の入札が約定したか否かを確認する、好ましくは付記３の電子取引システム。
［付記５］
前記端末は、前記検証サーバに対して、検証対象となる入札データのＩＤを含む検証データ生成要求を送信し、
前記検証サーバは、前記検証データ生成要求の受信に応じて前記検証データを生成し、前記生成された検証データを前記電子掲示板に書き込む、好ましくは付記４の電子取引システム。
［付記６］
前記端末は、
前記書き込まれた検証データを取得し、前記検証データに含まれる検証文字列を検証関数に入力し、前記検証関数の出力結果に基づき、前記取引サーバによる前記検証対象の入札データの取引が正当であったか否かを判定する、好ましくは付記５の電子取引システム。
［付記７］
前記取引サーバの取引の正当性に関する検証は、前記端末が入札データの価格を知ることはできず、且つ、前記取引サーバによる取引の正当性を検証可能とする、零知識証明である、好ましくは付記６の電子取引システム。
［付記８］
前記検証サーバは、
売り入札データが約定しなかったことに関する前記検証データを生成する場合には、
未約定な買い入札データの買値よりも検証対象とする売り入札データの売値が高いという、第１命題を証明する前記検証文字列を生成する、好ましくは付記２乃至７のいずれか一に記載の電子取引システム。
［付記９］
前記検証サーバは、
売り入札データが約定したことに関する前記検証データを生成する場合には、
約定した買い入札データの買値は未約定な買い入札データの買値最高額である、という第２命題を証明する前記検証文字列と、
検証対象とする売り入札データの売値は未約定な買い入札データの買値最高額以下である、という第３命題を証明する前記検証文字列と、を生成する、好ましくは付記２乃至８のいずれか一に記載の電子取引システム。
［付記１０］
前記検証サーバは、
買い入札データが約定しなかったことに関する前記検証データを生成する場合には、
未約定な売り入札データの売値よりも検証対象とする買い入札データの買値が低いという、第４命題を証明する前記検証文字列を生成する、好ましくは付記２乃至９のいずれか一に記載の電子取引システム。
［付記１１］
前記検証サーバは、
買い入札データが約定したことに関する前記検証データを生成する場合には、
約定した売り入札データの売値は未約定な売り入札データの売値最低額である、という第５命題を証明する前記検証文字列と、
検証対象とする買い入札データの買値は未約定な売り入札データの売値最低額以上である、という第６命題を証明する前記検証文字列と、を生成する、好ましくは付記２乃至１０のいずれか一に記載の電子取引システム。
［付記１２］
前記複数の管理サーバは、相互に直接接続され、
前記複数の管理サーバのそれぞれが、外部から受信したデータを管理するためのデータ管理台帳を有し、外部の装置からデータを電子掲示板に書き込む旨の要求を取得するたびに、前記データ管理台帳にデータを追記する、好ましくは付記１乃至１１のいずれか一に記載の電子取引システム。
［付記１３］
上述の第２の視点に係る取引サーバのとおりである。
［付記１４］
上述の第３の視点に係る検証サーバのとおりである。
［付記１５］
上述の第４の視点に係る電子取引方法のとおりである。
［付記１６］
上述の第５の視点に係るプログラムのとおりである。
なお、付記１３〜１６の形態は、付記１の形態と同様に、付記２の形態〜付記１２の形態に展開することが可能である。
【０２３５】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０２３６】
１０、１０３  取引サーバ
１１  ＣＰＵ（Central Processing Unit）
１２  メモリ
１３  入出力インターフェイス
１４  ＮＩＣ（Network Interface Card）
２０、２０ａ、２０−１〜２０−Ｎ、２０ａ−１〜２０ａ−Ｎ、１０２  端末
３０  データ管理システム
４０、４０−１〜４０−４、１０１  管理サーバ
５０  検証サーバ
２０１、３０１、４０１  通信制御部
２０２  データ管理部
２０３  復号部
２０４  取引実行部
２０５、３０３、４０３  記憶部
３０２  入札データ管理部
３０４  取引検証部
４０２  検証データ生成部
【図１】
2019186978.tif 000003
【図２】
2019186978.tif 000004
【図３】
2019186978.tif 000005
【図４】
2019186978.tif 000006
【図５】
2019186978.tif 000007
【図６】
2019186978.tif 000008
【図７】
2019186978.tif 000009
【図８】
2019186978.tif 000010
【図９】
2019186978.tif 000011
【図１０】
2019186978.tif 000012
【図１１】
2019186978.tif 000013
【図１２】
2019186978.tif 000014
【図１３】
2019186978.tif 000015
【図１４】
2019186978.tif 000016
【図１５】
2019186978.tif 000017
【図１６】
2019186978.tif 000018
【図１７】
2019186978.tif 000019
【図１８】
2019186978.tif 000020
【図１９】
2019186978.tif 000021
【図２０】
2019186978.tif 000022
【図２１】
2019186978.tif 000023
【国際調査報告】
2019186978.tif 000024
2019186978.tif 000025
2019186978.tif 000026
2019186978.tif 000027