(57)【要約】      （修正有）【課題】強化されたセキュリティを有する取引相互監視システムを提供する。【解決手段】取引相互監視システムを構成する取引管理サーバは、複数のコンピュータのうちの第１のコンピュータから、取引請求データを受信する通信部を備える。ここで、取引請求データは、少なくとも取引情報および参照権限保持者情報を含む。また、暗号鍵および復号鍵を生成し、暗号鍵を使用して、取引情報を暗号化して、暗号化取引データを生成するように構成された制御部を備える。通信部は、暗号化取引データを送信し、複数のコンピュータのうちの、参照権限保持者情報に対応する第２のコンピュータから鍵送信要求を受信し、第２のコンピュータに復号鍵を送信する。共有される情報は、第２のコンピュータからの承認／非承認電文の送信によって更新される。【選択図】図３
2018085681.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンピュータと相互接続された取引相互監視システムであって、前記複数のコンピュータは、前記取引相互監視システムを通じて相互に情報を共有し、
前記複数のコンピュータのうちの第１のコンピュータから取引請求データを受信するように構成された通信部であって、前記取引請求データは、少なくとも取引情報、および参照権限保持者情報を含む、通信部と、
暗号鍵および復号鍵を生成し、
前記暗号鍵を使用して、前記取引情報を暗号化して、暗号化取引データを生成する
ように構成された制御部と、
を備え、
前記通信部は、
前記暗号化取引データを送信し、
前記複数のコンピュータのうちの、前記参照権限保持者情報に対応する第２のコンピュータから鍵送信要求を受信し、
前記第２のコンピュータに前記復号鍵を送信する
ようにさらに構成され、
前記共有される情報は、前記第２のコンピュータからの承認／非承認電文の送信によって更新される
ことを特徴とする取引相互監視システム。
【請求項２】
前記通信部は、前記参照権限保持者情報を送信するようにさらに構成されていることを特徴とする請求項１に記載の取引相互監視システム。
【請求項３】
前記複数のコンピュータからアクセス可能な記憶部をさらに備え、
前記制御部は、前記暗号化取引データおよび／または前記参照権限保持者情報を前記記憶部に記憶する
ようにさらに構成されていることを特徴とする請求項１に記載の取引相互監視システム。
【請求項４】
前記通信部は、前記暗号化取引データおよび／または前記参照権限保持者情報を前記複数のコンピュータの全てに送信するようにさらに構成されていることを特徴とする請求項１または２に記載の取引相互監視システム。
【請求項５】
複数のコンピュータと相互接続された取引相互監視決システムによって実行される方法であって、前記複数のコンピュータは、前記取引相互監視システムを通じて相互に情報を共有し、
前記複数のコンピュータのうちの第１のコンピュータから取引請求データを受信するステップであって、前記取引請求データは、少なくとも取引情報、および参照権限保持者情報を含む、ステップと、
暗号鍵および復号鍵を生成するステップと、
前記暗号鍵を使用して、前記取引情報を暗号化して、暗号化取引データを生成するステップと、
前記暗号化取引データを送信するステップと、
前記複数のコンピュータのうちの、前記参照権限保持者情報に対応する第２のコンピュータから鍵送信要求を受信するステップと、
前記第２のコンピュータに前記復号鍵を送信するステップと
を備え、
前記共有される情報は、前記第２のコンピュータからの承認／非承認電文の送信によって更新される
ことを特徴とする方法。
【請求項６】
請求項５に記載の方法をコンピュータに実行させることを特徴とするプログラム。
【請求項７】
請求項６に記載のプログラムを記録したことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、強化されたセキュリティを有する取引相互監視システムに関し、特に、参加人相互で取引を監視することによって、取引の正当性を担保しつつ、取引の機密性を保持する取引相互監視システムに関する。
【背景技術】
【０００２】
近年、ピアツーピア（Peer to Peer）型の決済網であるビットコイン（Bitcoin）と言われる仮想通貨が利用されている。ビットコインとは、ブロックチェーンと呼ばれる分散型コンピュータネットワークを利用して行われるオンライン仮想通貨またはその通貨を使用したオンライン決済である。
【０００３】
従来のオンラインによる取引（例えば、インターネット上の仮想商店街での商品売買）では、そのオンラインによる取引を行うオンラインシステムが存在し、そのシステムの参加者同士で取引を行う場合、銀行口座またはクレジットカードを通じてその取引に対する決済を行うことになる。このような決済では、一般的に、参加者は上記オンラインシステムにＩＤおよびパスワードを使用して自身の認証処理を行ってログインし、決済を行う際は、クレジットカード番号およびセキュリティコードを使用してクレジットカードに対する認証処理を行うことによって決済が成立する。この決済の正当性は、オンラインシステムを提供する事業者およびクレジットカードを発行する事業者などの第三者機関によって検証されることになる。
【０００４】
一方で、ブロックチェーンでは、参加者による決済が行われる都度、その決済に関する情報（例えば、決済を行う者の名称、残高、決済額など）が他の全参加者に公開され、その全参加者のうちのいずれかによる承認によって決済が成立する。つまり、ブロックチェーンでは、オンラインシステムを提供する事業者およびクレジットカードを発行する事業者などの代わりに、参加者全員による相互監視によって決済の正当性が検証される。また、決済だけでなく、各参加者の取引履歴なども公開されるので、取引の正当性も検証される。
【０００５】
ブロックチェーンを利用したオンライン取引（決済）の利点は、以下の通りである。１つ目に、取引の正当性が参加者全員による相互監視によって検証されることから、例えば、上述したオンラインシステムを提供する事業者または第三者機関が機能しない場合でも、取引が成立する。２つ目に、取引に関する情報が全参加者に公開されることから、取引の正当性がさらに担保されることになる。このように、ブロックチェーンは、従来存在しなかった参加者相互の監視による安全な取引を可能とする分散型コンピューターネットワークを実現する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】ビットバンク株式会社＆『ブロックチェーンの衝撃』編集委員会著、「ブロックチェーンの衝撃」、日経BP社、2016年6月8日
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、ブロックチェーンでは、取引に関する情報を参加者全員に公開することによって、取引の正当性が担保されているが、その公開される情報には、参加者が公開を望まないような機密情報が存在する可能性がある。そのような事実は、できるだけ多くの者が参加することが望ましいブロックチェーンにおいて、参加者を増やす阻害要因となりうる。
【０００８】
本発明は、このような問題に鑑みてなされたものであり、その目的とするところは、ピアツーピア型の分散型コンピューターネットワーク環境において参加者相互の監視の仕組みを利用することによって、取引の正当性を担保しつつ、参加者の機密情報を保護する取引監視スキームを提供することにある。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、本発明に係る取引相互監視システムは、複数のコンピュータと相互接続された取引相互監視システムであって、前記複数のコンピュータは、前記コンピュータシステムを通じて相互に情報を共有し、前記複数のコンピュータのうちの第１のコンピュータから取引請求データを受信するように構成された通信部であって、前記取引請求データは、少なくとも取引情報、および参照権限保持者情報を含む、通信部と、暗号鍵および復号鍵を生成し、前記暗号鍵を使用して、前記取引情報を暗号化して、暗号化取引データを生成するように構成された制御部と、を備え、前記通信部は、前記暗号化取引データを送信し、前記複数のコンピュータのうちの、前記参照権限保持者情報に対応する第２のコンピュータから鍵送信要求を受信し、前記第２のコンピュータに前記復号鍵を送信するようにさらに構成され、前記共有される情報は、前記第２のコンピュータに承認／非承認電文の送信によって更新されることを特徴とする。
【発明の効果】
【００１０】
本発明に係る取引相互監視システムによれば、参加者の取引に関する機密情報が保護されるので、参加者が安心して本システムに参加することができる。また、それによって、相互監視する参加者が増え、さらに相互監視による取引の正当性がさらに担保されるという好循環をもたらす。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る取引相互監視決システムの全体の構成の例を示すブロック図である。
【図２】本発明の一実施形態に係る取引相互監視システムを構成するコンピュータデバイスの詳細な構成の例を示すブロック図である。
【図３】本発明の一実施形態に係る取引相互監視システムが実行する取引請求処理の例を示すフローチャートである。
【図４】本発明の一実施形態に係る取引請求画面の例を示す図である。
【図５】本発明の一実施形態に係る取引データテーブルの例を示す図である。
【図６】本発明の一実施形態に係る鍵管理データテーブルの例を示す図である。
【図７】本発明の一実施形態に係る取引相互監視システムが実行する参照要求・鍵配布処理の例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下で、本発明の一実施形態に係る取引相互監視システムの詳細を説明する。
【００１３】
＜システム構成＞
図１を参照して、本発明の一実施形態に係る取引相互監視システムの全体の構成の例を説明する。図１は、本発明の一実施形態に係る取引相互監視システムの全体の構成の例を示すブロック図である。
【００１４】
本実施形態に係る取引相互監視システムは、取引管理サーバ１、公開ＷＥＢサーバ２、クライアント端末３ａ（例えば、スマートフォンなどの携帯電話、タブレット端末などの携帯情報端末）、クライアント端末３ｂ（例えば、デスクトップ型パーソナルコンピュータなど）、およびクライアント端末３ｃ（例えば、ノート型パーソナルコンピュータなど）（以下、「クライアント端末３」と総称する）を備え、それらはネットワーク４を介して相互に接続されている。ネットワーク４は、インターネットなどの公衆ネットワークである。
【００１５】
取引管理サーバ１は、本実施形態に係る取引相互監視システムに係るサービス（以下、「取引相互監視サービス」）を提供するにおいて、取引相互監視サービスに参加する参加者の機密情報の管理などを担当する事業者（以下、「サービス提供事業者」）に設置されたコンピューティングデバイスである。具体的には、参加者から取引請求を受けると、取引データを生成する。生成した取引データは、取引請求を行った参加者（以下、「取引請求者」）により指定された参加者のみが参照できるよう管理される。なお、取引管理サーバ１は単一のコンピュータデバイス、または、複数のコンピュータデバイスで実装されてもよい。
【００１６】
公開ＷＥＢサーバ２は、本実施形態に係る取引相互監視サービスを実現するにおいて、参加者が相互に情報を管理することができるＷＥＢページを提供するコンピューティングデバイスである。公開ＷＥＢサーバ２は、参加者全員がアクセス可能な（参加者のＩＤおよびパスワードによる認証を通じて）ＷＥＢページを提供し、そのＷＥＢページ上では、取引請求者が要求したことによって生成された取引データがアップロードされる（この取引データは、取引請求者により指定された参加者のみが参照することができる。また、当該ＷＥＢページ上では、各参加者ごとに取引相互監視サービスで使用することができる仮想通貨の残高（いわゆる電子ウォレット）を管理することができる。なお、公開ＷＥＢサーバ２も、単一のコンピュータデバイス、または、複数のコンピュータデバイスで実装されてもよい。
【００１７】
クライアント端末３は、本発明に係る取引相互監視サービスを利用する参加者が使用し、公開ＷＥＢサーバ２から上述したＷＥＢページをダウンロードするコンピュータデバイスである。クライアント端末３は、スマートフォンなどの携帯電話、タブレット端末などの携帯情報端末、およびパーソナルコンピュータ（ノート型およびデスクトップ型コンピュータを含む）など、ネットワーク４にアクセス可能であり、上述したＷＥＢページを表示することができるいずれかのコンピュータデバイスを含む。
【００１８】
図１で説明した公開ＷＥＢサーバ２およびクライアント端末３がネットワーク４によって相互接続される相互ネットワークは、既存のブロックチェーンを構成する。本発明に係る取引相互監視システムでは、このブロックチェーンにおいて、取引管理サーバ１が機密情報の管理機能を提供することになる。なお、ＷＥＢサーバ２は、サービス提供事業者によって提供されてもよく、または既存のブロックチェーンを構成するＷＥＢサーバを利用してもよい。
【００１９】
次に、図２を参照して、本発明の一実施形態に係る取引相互監視システムを構成するコンピュータデバイスの詳細な構成の例を説明する。図２は、本発明の一実施形態に係る取引相互監視システムを構成するコンピュータデバイスの詳細な構成の例を示すブロック図である。
【００２０】
図２は、図１で説明した取引管理サーバ１、公開ＷＥＢサーバ２、およびクライアント端末３それぞれの構成要素を示している。取引管理サーバ１は、通信部１１、制御部１２、主記憶部１３、および補助記憶部１４を備えている。また、図示しないが、取引管理サーバ１とネットワーク４との間には、ゲートウェイが設置されており、公開ＷＥＢサーバ２およびクライアント端末３から取引管理サーバ１に記憶されたデータにはアクセスすることができないようにファイヤウォールが設定されている（ポート単位または装置単位でアクセスをフィルタリングすることによって）。
【００２１】
通信部１１は、ネットワーク４を介して接続された公開ＷＥＢサーバ２およびクライアント端末３にデータを送信し、およびそれらの装置から制御情報を送受信するネットワークインタフェースである。
【００２２】
制御部１２は、中央処理装置（ＣＰＵ）とも呼ばれ、上記各構成要素の制御やデータの演算を行う。また、制御部１２は、本実施形態に係る各種処理を実行するための、補助記憶部１４に格納されている各種プログラムを主記憶部１３に読み取って実行する。
【００２３】
主記憶部１３は、メインメモリとも呼ばれ、取引管理サーバ１が受信した入力データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶する。
【００２４】
補助記憶部１４は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、制御部１２に、以下で説明する取引管理サーバによって実行されることになる各種処理を実行させるためのプログラム（図示せず）を記憶している。また、取引管理サーバ１は、ＤＢＭＳ（Database Management System）を実装しており、補助記憶部１４は、後述する取引管理データテーブルおよび鍵管理データテーブルなどのデータを記憶したデータベーステーブル１４ａを記憶している。
【００２５】
公開ＷＥＢサーバ２は、通信部２１、制御部２２、主記憶部２３、および補助記憶部２４を備えている。公開ウェブサーバは、全ての参加者が、認証を通じてアクセス可能である。通信部２１、制御部２２、および主記憶部２３は、取引管理サーバ１が有する通信部１１、制御部１２、および主記憶部１３と同等の機能を有するので、その説明は省略する。
【００２６】
補助記憶部２４は、以下で説明する公開ＷＥＢサーバ２によって実行されることになる各種処理を実行させるためのプログラム（図示せず）、およびクライアント端末３によって実行されることになる各種処理を実行させるためのプログラム（図示せず）を記憶している。後者のプログラムは、クライアント端末３からの要求に応じてダウンロードされる。また、補助記憶部２４は、上述したＷＥＢページを記憶している。
【００２７】
クライアント端末３は、通信部３１、制御部３２、主記憶部３３、補助記憶部３４、および表示部３５を備えている。通信部３１、制御部３２、主記憶部３３、および補助記憶部３４は、取引管理サーバ１が有する通信部１１、制御部１２、主記憶部１３、および補助記憶部１４と同等の機能を有するので、その説明は省略する。
【００２８】
表示部３５は、制御部３２が公開ＷＥＢサーバ２からダウンロードされたプログラムを実行することによって、公開ＷＥＢサーバ２からダウンロードされたＷＥＢページを表示する。参加者は、このＷＥＢページを通じて、取引データの参照、取引請求者による取引請求の承認、および電子ウォレットの管理などを行うことができる。
【００２９】
次に、図３を参照して、本発明の一実施形態に係る取引相互監視システムが実行する処理の例を説明する。図３は、本発明の一実施形態に係る取引相互監視システムが実行する処理の例を示すフローチャートである。上述したように、本発明に係る取引相互監視サービスは、公開ＷＥＢサーバ２によって生成されたＷＥＢページにクライアント端末３がアクセスすることによって、参加者による取引相互監視が実現する。参加者は、クライアント端末３に公開ＷＥＢサーバ２からダウンロードされたプログラムを実行し、ＷＥＢページをダウンロードしているものとする。また、参加者は、当該ＷＥＢページ上で取引相互監視システムに自身の登録処理を行うと、取引相互監視システムにおいて自身の識別子（参加者ＩＤ）が割り当てられる。この処理によって、自身のＩＤによる認証を通じて、以下で説明する取引請求画面などにアクセスすることができる。
【００３０】
＜取引請求処理＞
本実施形態では、取引請求者（以下、「請求者」）Ａが取引の相手である被請求者Ｂに取引請求を行うものとする。まず、請求者Ａが、公開ＷＥＢサーバ２からダウンロードされ、クライアント端末３の表示部３５に表示されたＷＥＢページの取引請求画面４００から取引請求情報を入力する（ステップＳ３０１）。ここで、図４を参照して、取引請求画面４００の例を説明する。
【００３１】
図４に示すように、取引請求画面４００は、請求者情報表示ボックス４０１、被請求者情報入力ボックス４０２、支払情報入力ボックス４０３、および参照者情報入力ボックス４０４を含む。
【００３２】
請求者情報表示ボックス４０１は、請求者Ａによる認証処理によって入力された取引請求者ＡのＩＤおよび名称が表示される（公開ＷＥＢサーバ２では、各参加者の参加者ＩＤ、名称、およびＩＰアドレス（参加者が有するクライアント端末のＩＰアドレス）などを含む参加者情報を管理する参加者データテーブル（図示せず）を記憶しており、そのデータテーブルから名称を取得する）。
【００３３】
被請求者情報入力ボックス４０２は、請求者Ａが支払を要求する被請求者ＢのＩＤおよび／または名称を入力するための入力ボックスである。支払情報入力ボックス４０３は、請求者Ａが被請求者Ｂに要求する支払額および支払期限日などの情報を入力するための入力ボックスである。参照者情報入力ボックス４０４は、請求者Ａが、この取引請求画面４００で入力された情報（つまり、取引請求情報）を参照することを許可する、参加者の中で請求者Ａおよび被請求者Ｂ以外の第三者（以下、「参照権限保持者」）を指定する。参照権限保持者については、任意の数の参照権限保持者を指定することができる。本実施形態では、参加者Ｃ、参加者Ｄ、および参加者Ｅが指定されるものとする。
【００３４】
取引請求情報が入力されると、クライアント端末３の通信部３１は、その入力された取引請求情報を公開ＷＥＢサーバ２にアップロード（送信）する。アップロードされた取引請求情報は、取引請求データとして、公開ＷＥＢサーバ２の通信部２２によって取引管理サーバ１に送信される（ステップＳ３０２）。なお、この取引請求データは、公開ＷＥＢサーバ２を介さず、クライアント端末３から取引管理サーバ１に直接送信されてもよい。
【００３５】
取引管理サーバ１の通信部が、ステップＳ３０２で送信された取引請求データを受信すると、制御部１２は、取引ａに対応する取引ＩＤを割り当て、受信した取引請求データに基づいて、取引管理データテーブル５００にレコードを追加する（ステップＳ３０３）。図５に取引管理データテーブル５００の例を示す。
【００３６】
取引管理データテーブル５００は、取引管理サーバ１の補助記憶部１４に記憶されたデータベーステーブルであり、ＤＢＭＳのＳＱＬ（Structured Query Language）によってレコードの追加、更新および削除などが実行される。図５に示すように、取引管理データテーブル５００は、データ項目「取引ＩＤ」、「請求者番号」、「被請求者番号」、「支払金額」および「支払期日」を含む。データ項目「取引ＩＤ」は、ステップＳ３０３で制御部１２によって割り当てられた取引ＩＤが設定され、その他のデータ項目は、ステップＳ３０２で送信された取引請求データに含まれる、対応するデータ項目の値が設定される（つまり、取引請求画面４００で入力された値が設定される）。
【００３７】
図３の説明に戻り、制御部１２は、ステップＳ３０３で取引管理データテーブル５００に追加した取引管理データレコードに対応するデータ（以下、「取引データ」）に基づいて、取引ａに対応する鍵を生成する（ステップＳ３０４）。この鍵とは、取引ａに対応する取引データ（平文）を暗号化する暗号鍵、および暗号化された取引データ（暗号文）を復号する復号鍵を意味する。この暗号鍵および復号鍵は、同一の鍵であってもよく（共通鍵暗号方式）、または異なる鍵であってもよい（公開鍵暗号方式）。また、公開鍵暗号方式では、公開鍵を暗号化に使用し、秘密鍵を復号に使用してもよく、またはその逆であってもよい。本実施形態では、公開鍵暗号方式を採用し、公開鍵を暗号化に使用し（暗号鍵）、秘密鍵を復号に使用する（復号鍵）ものとする。なお、鍵を生成するために、ＲＳＡ暗号方式などが使用されてもよいが、そのような技術は公知であるので、本明細書ではその説明は省略する。
【００３８】
鍵が生成されると、制御部１２は、ステップＳ３０３で割り当てられた取引ＩＤ、ステップＳ３０２で送信された取引請求データに含まれる参照権限保持者に対応する参加者ＩＤ（つまり、取引請求画面４００で指定された参照権限保持者）、およびステップＳ３０４で生成された鍵のうち秘密鍵（復号鍵）に基づいて、鍵管理データテーブル６００にレコードを追加する（ステップＳ３０５）。
図６に鍵管理データテーブル６００の例を示す。
【００３９】
鍵管理データテーブル６００も、取引管理サーバ１の補助記憶部１４に記憶されたデータベーステーブルである。図６に示すように、鍵管理データテーブル６００は、データ項目「取引ＩＤ」、「参照権限保持者番号」および「鍵値」を含む。各データテーブルは、ステップＳ３０５において、取引ＩＤおよび参照権限保持者番号ごとに生成され、データ項目「鍵値」には、ステップＳ３０４で生成された復号鍵の鍵値が設定される。本実施形態では、取引ａについて参加者Ｃ、参加者Ｄ、および参加者Ｅのそれぞれについてのレコードが追加される。
【００４０】
図３の説明に戻り、鍵管理データテーブル６００にレコードが追加されると、制御部１２は、取引ａに対応する取引データを、ステップＳ３０４で生成された鍵のうち公開鍵（暗号鍵）を使用して暗号化する（ステップＳ３０６）。ついで、通信部１１が、その公開鍵を公開ＷＥＢサーバ２に送信する（ステップＳ３０７）。
【００４１】
次に、公開ＷＥＢサーバ２の通信部２１が、ステップＳ３０７で送信された公開鍵を受信すると、制御部２２は、受信した公開鍵を、公開ＷＥＢサーバ２が提供する参加者全員がアクセス可能なＷＥＢページにアップロードする（ステップＳ３０８）。この処理によって、取引ａに対して生成された公開鍵が全参加者に対して公開されることになる。
【００４２】
次に、取引管理サーバ１の通信部１１は、ステップＳ３０６で暗号化した取引データ（以下、「暗号化取引データ」）を、公開ＷＥＢサーバ２に送信する（ステップＳ３０９）。
【００４３】
次に、公開ＷＥＢサーバ２の通信部２１が、ステップＳ３０８で送信された暗号化取引データを受信すると、制御部２２は、受信した暗号化取引データを、公開ＷＥＢサーバ２が提供する参加者全員がアクセス可能なＷＥＢページにアップロードする（ステップＳ３１０）。この処理によって、全参加者が、少なくとも取引ａが発生したことを把握することができる。
【００４４】
なお、ステップＳ３０８における暗号化取引データの公開ＷＥＢサーバ２への送信は、取引管理サーバ１の代わりに取引の当事者である請求者Ａおよび／または被請求者Ｂが有するクライアント端末３によって行われてもよい。クライアント端末３が暗号化取引データを公開ＷＥＢサーバ２に送信することによって、参加者相互の自律的な取引相互監視ネットワークが成立することになる。
【００４５】
次に、通信部１１は、ステップＳ３０５で鍵管理データテーブル６００に追加した鍵管理データレコードに対応するデータ（以下、「鍵管理データ」）を公開ＷＥＢサーバ２に送信する（ステップＳ３１１）。
【００４６】
次に、公開ＷＥＢサーバ２の通信部２１が、ステップＳ３１１で送信された鍵管理データを受信すると、制御部２２は、受信した鍵管理データを、公開ＷＥＢサーバ２が提供する参加者全員がアクセス可能なＷＥＢページにアップロードする（ステップＳ３１２）。この処理によって、全参加者が、少なくとも取引ａに対する参照権限保持者を把握することができる。
【００４７】
以上のように、ステップＳ３０１乃至Ｓ３１２の処理によって取引ａに対応する取引データおよび鍵管理データが生成され、暗号化取引データが公開ＷＥＢサーバ２において参加者全員によってアクセス可能な状態となるので、参加者全員は、少なくとも特定の取引が行われたことを把握することができる。しかしながら、公開ＷＥＢサーバ２にアップロードされた暗号化取引データは暗号化されているので、以下で説明する参照要求・鍵配布処理によって、参照権限保持者のみが参照することができる。鍵管理データは、公開ＷＥＢサーバ２において、参加者全員に公開されることになるので、参照権限保持者は、自身が特定の取引に対する取引データを参照する権限を有していることを把握することができる。
【００４８】
なお、本実施形態では、暗号化取引データは、取引管理サーバ１（または、請求者Ａおよび／もしくは被請求者Ｂが有するクライアント端末３）によって公開ＷＥＢサーバ２にアップロードされるがそのような形式に限定されない。例えば、取引管理サーバ１（または、クライアント端末３）によって、全参加者が有するクライアント端末３に暗号化取引データがブロードキャストされてもよい。ステップＳ３０８における公開鍵のアップロード、およびステップＳ３１２における鍵管理データのアップロードについても同様である。代わりに、鍵管理データについては、全参加者が有するクライアント端末３にブロードキャストするのではなく、参照権限保持者が有するクライアント端末３にのみ送信されるようにしてもよい。この場合、取引管理サーバ１（または、クライアント端末３）に、少なくとも各参加者の参加者ＩＤおよびメールアドレス（参加者が有するクライアント端末のＩＰアドレス）を含む参加者情報を管理する参加者データ（データベーステーブルまたはデータファイル）が記憶されており、その参加者データから各参加者のクライアント端末のＩＰアドレスを取得することになる。
【００４９】
＜参照要求・鍵配布処理＞
次に、図７を参照して、参照権限保持者（参加者Ｃ、参加者Ｄ、および参加者Ｅ）によって実行される、取引ａに対する取引データを参照する際の参照要求・鍵配布処理について説明する。図３で説明したステップＳ３０９での処理によって、参照権限保持者は自身が取引データを参照する権限を把握することができることは上述した。このような状態で、参照権限保持者が取引ａに対する取引データを参照することを希望するものとする。
【００５０】
まず、参照権限保持者が有するクライアント端末３の通信部３１は、取引管理サーバ３に鍵送信要求電文を送信する（ステップＳ７０１）。この鍵送信要求電文は、少なくとも、対象の取引ＩＤおよび参照権限保持者の参加者ＩＤを含む。この処理は、例えば、参照権限保持者が取引管理サーバ１もしくは公開ＷＥＢサーバ２からダウンロードされ、またはクライアント端末３に予め記憶された入力インタフェース（例えば、ＷＥＢページ）を通じて情報を入力することによって行われてもよい。
【００５１】
次に、取引管理サーバ１の通信部１１が、ステップＳ７０１で送信された鍵送信要求電文を受信すると、制御部１２は、その鍵送信要求電文に含まれる取引ＩＤおよび参加者ＩＤに基づいて、鍵管理データテーブル６００から該当のレコードを取得する（ステップＳ７０２）。
【００５２】
次に、通信部１１は、ステップＳ７０２で取得した鍵管理データレコードに含まれる秘密鍵の鍵値を、そのレコードに含まれる参照権限保持者ＩＤが示す参照権限保持者のクライアント端末３に送信する（上述した参加者データを参照することによってＩＰアドレスを取得する）（ステップＳ７０３）。
【００５３】
参照権限保持者のクライアント端末３の通信部３１が、ステップＳ７０３で送信された鍵値を取得すると、例えば、クライアント端末３の表示部３５に表示されたＷＥＢページなどでその受信通知がされる。そして、参照権限保持者が、暗号化取引データがアップロードされているＷＥＢページにアクセスすると、通信部３１が、受信した鍵値を公開ＷＥＢサーバ２に送信する（ステップＳ７０４）。
【００５４】
公開ＷＥＢサーバ２の通信部２１が、ステップＳ７０４で送信された鍵値を受信すると、制御部２２がその鍵値を使用して、暗号化取引ータを復号する（ステップＳ７０５）。復号した取引データは、通信部２１によってクライアント端末３に送信される（ダウンロード）（ステップＳ７０６）。
【００５５】
クライアント端末３の通信部３１がステップＳ７０６で送信された取引データを受信すると、参照権限保持者は取引ａに対する取引データを参照することができる。その後は、参照権限保持者が、例えば、該当のＷＥＢページに表示された「承認ボタン」または「否認ボタン」を押下することによって、その承認・否認電文が公開ＷＥＢサーバ２に送信される。公開ＷＥＢサーバ２の通信部２１が、この承認・否認電文を受信すると、その電文の値によって取引の成立可否が判定される。
【００５６】
上記ステップＳ７０１乃至Ｓ７０６の処理によって、参照権限保持者が取引データを参照することができるようになるが、クライアント端末３からの鍵送信要求電文に応答して秘密鍵を送信する代わりに、秘密鍵を生成した時点で、取引管理サーバ１から参照権限保持者のクライアント端末３に送信するようにしてもよい。
【００５７】
なお、取引管理サーバ１に記憶されている取引データおよび鍵管理データは、一定の期間が経過すると自動的に削除される。公開ＷＥＢサーバ２に記憶されている暗号化取引データ、鍵管理データ、および各クライアント端末３にダウンロードされた復号した取引データについても同様である。
【００５８】
以上のように、本実施形態に係る取引相互監視システムの例を説明した。本実施形態に係る取引相互監視システムによれば、取引データを暗号化し、参照権限保持者のみがその暗号化取引データを復号することができるので、参加者が指定した者のみに公開を制限することができる。これによって、参加者の情報の機密性が確保される。
【００５９】
また、暗号化取引データ自体は公開ＷＥＢサーバ２にアップロードされ（参加者全員がアクセス可能な）、参加者のうちのいずれかによる承認によって取引が成立するので、参加者相互の監視による自律性および取引の正当性が担保されることになる。
【００６０】
さらに、鍵管理データは、公開ＷＥＢサーバ２で公開されるので、参加者全員が、特定の取引に対してどの参加者が参照権限を有しているかを把握することができる。
【００６１】
なお、本実施形態で説明した取引管理データテーブル５００および鍵管理データテーブル６００などのデータ構造は例示的なものにすぎず、そのような構成に限定されない。また、図３で説明したフローチャートの順序は、本発明の基本的な概念から逸脱することなく、その順序が変更され、その一部が省略されてもよく、および／または一部の処理が追加されてもよい。
【００６２】
また、本実施形態で説明したスキームは、上述したような取引にのみ適用されるものではなく、相互ネットワークの参加者による監視、および機密情報の保持が必要とされる他の事例に適用されてもよい。また、図７で説明した参加者による承認／非承認は、取引に対してのみでなく、決済に対して承認／非承認が行われてもよい。
【００６３】
さらに、本実施形態では、取引管理サーバ、つまり機密情報の管理を担うサーバと、公開ＷＥＢサーバ、つまり取引相互監視ネットワークの中核を担うサーバとが別個のコンピュータデバイスまたはコンピュータシステムで実装されているが、その両方が単一のデバイスまたはシステムで実装されてもよい。この場合でも、取引管理データテーブル５００および鍵管理データテーブル６００は、参加者によってアクセスできないよう制御される必用がある。
【符号の説明】
【００６４】
１    取引管理サーバ
２    公開ＷＥＢサーバ
３ａ  クライアント端末
３ｂ  クライアント端末
３ｃ  クライアント端末
４    ネットワーク
４００    取引請求画面
４０１    請求者情報表示ボックス
４０２    被請求者情報入力ボックス
４０３    支払情報入力ボックス
４０４    参照者情報入力ボックス
５００    取引管理データテーブル
６００    鍵管理データテーブル
【図１】
2018085681.tif 000003
【図２】
2018085681.tif 000004
【図３】
2018085681.tif 000005
【図４】
2018085681.tif 000006
【図５】
2018085681.tif 000007
【図６】
2018085681.tif 000008
【図７】
2018085681.tif 000009