JP2019161302A - 署名システム - Google Patents

Abstract

【課題】マルチシグトランザクションの信頼性を向上可能な新たな署名システムを提供すること。【解決手段】署名システム１０は、事業者システム５０が秘密鍵５４２によって署名して発行したトランザクション８０に対して、秘密鍵５４２に対応する秘密鍵３４２によって署名する。署名システム１０は、利用者端末４０からのトランザクション参照依頼をトリガーとして、秘密鍵３４２による署名が必要なマルチシグトランザクション８０Ｍを収集する。署名システム１０は、利用者端末４０から、収集したマルチシグトランザクション８０Ｍの署名承認を受信すると、署名承認されたマルチシグトランザクション８０Ｍに対して秘密鍵３４２によって署名する。【選択図】図２

Description

本発明は、ブロックチェーンのマルチシグトランザクションに署名する署名システムに関する。

例えば、特許文献１には、このタイプの署名システムを含むトランザクション処理ネットワークが開示されている。

特許文献１のトランザクション処理ネットワークは、複数のパブリックノードと、ｍ個のプライベートノードから構成されている。プライベートノードの夫々は、秘密鍵を有している。ｍ個のプライベートノードの秘密鍵は、互いに対応しており且つ互いに異なっている。トランザクション処理ネットワークにおいて、パブリックノードが作成したトランザクション（例えば、送金）は、下記のように処理される。

パブリックノードは、トランザクションを作成し、プライベートノードのうちの１つ（承認依頼元）にトランザクションを送信する。承認依頼元は、パブリックノードからトランザクションを受信すると、他のｍ−１個のプライベートノード（承認依頼先）に対して、承認依頼を送信する。承認依頼にはトランザクションの内容が付されており、且つ、承認依頼は承認依頼元の秘密鍵によって署名されている。承認依頼先の夫々は、承認依頼元の署名を検証すると共に、承認依頼に付されたトランザクションの内容が改ざんされていない等の検証を行い、これにより承認依頼の正当性を判断する。承認依頼先の夫々は、承認依頼が正当であると判断した場合、承認依頼元に対して、承認依頼先の秘密鍵によって署名された承認結果（即ち、トランザクションを承認する旨の通知）を送信する。承認依頼元は、承認依頼先の署名を検証し、これにより承認結果の正当性を判断する。

上述した処理の結果、承認依頼元を含めたｎ個のプライベートノードがトランザクションを承認すると、パブリックノードが作成したトランザクションが承認される。このように複数の秘密鍵を使用してトランザクションを承認するマルチシグニチャ技術により、承認されたトランザクションの信頼性が向上する。

特開２０１７−１８８８８３号公報

特許文献１のマルチシグニチャ技術によれば、パブリックノード（利用者端末）がトランザクションに署名し、このトランザクションは、互いに対応する秘密鍵を有する複数のプライベートノード（サーバ）のうちの所定数が検証して承認したときに有効になる。

しかしながら、マルチシグニチャ技術は、これに限られず、様々に応用可能である。例えば、利用者端末の発行依頼に応じて、２つのサーバが互いに対応する２つの秘密鍵によって署名したトランザクション（マルチシグトランザクション）を発行する場合もある。この場合、２つのサーバのうちの一方（署名依頼元）が自らの秘密鍵によって署名した後、２つのサーバのうちの他方（署名依頼先）に対して対応する秘密鍵による署名を依頼する。このとき、署名依頼されたマルチシグトランザクションの内容が署名依頼元によって改ざんされているといった明確な瑕疵がない限り、署名依頼先は、半ば自動的にマルチシグトランザクションに署名する。従って、例えば、署名依頼元（サーバ）の運用管理者が、自らが管理するサーバを使用して虚偽のマルチシグトランザクションを発行して署名した場合、このマルチシグトランザクションは、署名依頼先によって半ば自動的に署名される。即ち、秘密鍵を管理する者による不正な使用といった秘密鍵の悪用によってマルチシグトランザクションの信頼性が低下するおそれがある。

そこで、本発明は、マルチシグトランザクションの信頼性を向上可能な新たな署名システムを提供することを目的とする。

本発明は、第１の署名システムとして、
事業者システムが秘密鍵によって署名して発行したマルチシグトランザクションに対して、前記秘密鍵に対応する他の秘密鍵によって署名する署名システムであって、
利用者端末からのトランザクション参照依頼をトリガーとして、前記他の秘密鍵による署名が必要な前記マルチシグトランザクションを収集し、
前記利用者端末から、前記収集した前記マルチシグトランザクションの署名承認を受信し、
前記署名承認された前記マルチシグトランザクションに対して前記他の秘密鍵によって署名する
署名システムを提供する。

また、本発明は、第２の署名システムとして、第１の署名システムであって、
前記利用者端末から前記マルチシグトランザクションに対する前記署名承認を受信すると、前記署名承認された前記マルチシグトランザクションが所定の署名条件を満たすか否か判定し、前記署名条件を満たした前記マルチシグトランザクションに対して前記他の秘密鍵によって署名する
署名システムを提供する。

また、本発明は、第３の署名システムとして、第１又は第２の署名システムであって、
前記収集した前記マルチシグトランザクションに夫々対応するトランザクションデータのリストであるトランザクションデータリストを前記利用者端末に送信し、
前記利用者端末から、前記トランザクションデータに対応する前記マルチシグトランザクションの前記署名承認を受信する
署名システムを提供する。

また、本発明は、第４の署名システムとして、第３の署名システムであって、
前記事業者システムから受信したエントリデータ追加依頼に夫々応じて作成した１以上のエントリデータを有しており、
前記エントリデータは、前記マルチシグトランザクションと夫々対応しており、
前記エントリデータの夫々には、対応する前記マルチシグトランザクションを特定可能なトランザクション特定データが含まれており、
前記マルチシグトランザクションの前記収集を行う際、前記エントリデータの前記トランザクション特定データによって特定される前記マルチシグトランザクションを収集する
署名システムを提供する。

また、本発明は、第５の署名システムとして、第４の署名システムであって、
前記事業者システムから前記エントリデータ追加依頼を受信したとき、受信した前記エントリデータ追加依頼が所定のエントリデータ追加条件を満たすか否か判定し、前記エントリデータ追加条件を満たした場合に前記エントリデータを作成する
署名システムを提供する。

また、本発明は、第６の署名システムとして、第３から第５までのいずれかの署名システムであって、
前記トランザクションデータリストにおける前記トランザクションデータには、対応する前記マルチシグトランザクションを発行した前記事業者システムを識別可能なデータが含まれている
署名システムを提供する。

また、本発明は、第７の署名システムとして、第１の署名システムであって、
前記利用者端末からの前記トランザクション参照依頼をトリガーとして、前記事業者システムから前記マルチシグトランザクションを特定可能なトランザクション特定データを受信し、
前記マルチシグトランザクションの前記収集を行う際、前記受信した前記トランザクション特定データによって特定される前記マルチシグトランザクションを収集し、
前記利用者端末から、前記事業者システムを経由した二段階認証によって、前記収集した前記マルチシグトランザクションの前記署名承認を受信する
署名システムを提供する。

また、本発明は、第８の署名システムとして、第１から第７までのいずれかの署名システムであって、
パブリックシステムと、プライベートシステムとを備えており、
前記パブリックシステムは、前記マルチシグトランザクションの前記収集と、前記マルチシグトランザクションの前記署名承認の前記受信とを行い、
前記プライベートシステムは、前記マルチシグトランザクションの前記署名を行う
署名システムを提供する。

また、本発明は、第１の利用者端末として、
第３から第６までのいずれかの署名システムと通信可能な利用者端末であって、
表示装置を備えており、
前記署名システムに前記トランザクション参照依頼を送信し、
前記署名システムから受信した前記トランザクションデータリストに基づく表示データを前記表示装置に表示する
利用者端末を提供する。

また、本発明は、第１のプログラムとして、
コンピュータを、第１の利用者端末として機能させるためのプログラムを提供する。

また、本発明は、第９の署名システムとして、
利用者端末が秘密鍵によって署名して発行したマルチシグトランザクションに対して、前記秘密鍵に対応する他の秘密鍵によって署名する署名システムであって、
前記利用者端末からのトランザクション参照依頼をトリガーとして、前記他の秘密鍵による署名が必要な前記マルチシグトランザクションを収集し、
収集した前記マルチシグトランザクションに夫々対応するトランザクションデータのリストであるトランザクションデータリストを前記利用者端末に送信し、
前記利用者端末から前記トランザクションデータに対応する前記マルチシグトランザクションの署名承認を受信し、
前記署名承認された前記マルチシグトランザクションに対して前記他の秘密鍵によって署名する
署名システムを提供する。

また、本発明は、第１０の署名システムとして、第９の署名システムであって、
前記トランザクションデータリストにおける前記トランザクションデータには、前記利用者端末が発行した前記マルチシグトランザクションであることを識別可能なデータが含まれている
署名システムを提供する。

本発明によれば、利用者に関連するマルチシグトランザクション、例えば、利用者の発行依頼に応じて事業者システムが秘密鍵によって署名して発行したマルチシグトランザクションは、署名システムが利用者からの署名への承認を受信した場合に、署名システムの秘密鍵によって署名される。即ち、マルチシグトランザクションは、発行依頼した利用者による確認という手順を踏んで署名されるため、事業者システムの秘密鍵が漏洩した場合も、漏洩した秘密鍵の不正な使用による被害を防止できる。本発明によれば、マルチシグトランザクションの信頼性を向上可能な新たな署名システムを提供できる。

本発明の実施の形態による署名システム、利用者システム、事業者システム及びブロックチェーンのネットワークを示す図である。 図１の署名システム、利用者システム、事業者システム及びブロックチェーンの間で行われる処理を示す図である。 図１の署名システム、利用者システムブロックチェーンの間で行われる別の処理を示す図である。 図２の処理と図３の処理とを纏めて示す図である。 図１のブロックチェーンに含まれるトランザクションのデータ構造を部分的に示す図である。 図１の事業者システムが有する秘密鍵を、秘密鍵に対応するデータと共に示す図である。 図１の利用者システムが有する秘密鍵を、秘密鍵に対応するデータと共に示す図である。 図１の署名システムが有する秘密鍵を示す図である。 図１の署名システムが有する利用者情報のデータ構造を示す図である。 図４の事業者システムが署名システムに送信するエントリデータのデータ構造を示す図である。エントリデータに対応するトランザクションの対応するデータを描画している。 図４の署名システムが有するエントリのデータ構造を示す図である。データ内容を例示している。エントリのエントリデータに対して夫々対応するトランザクションを描画している。 図４の署名システムが利用者システムに送信するトランザクションデータリストの一例を示す図である。 図１１のエントリの別の例を示す図である。 図１２のトランザクションデータリストの別の例を示す図である。 図４の署名システムのパブリックシステム及びプライベートシステムを示す図である。 図１５のパブリックシステムのエントリデータ追加処理を示すフローチャートである。 図１５のパブリックシステムのエントリデータ更新処理を示すフローチャートである。 図１５のプライベートシステムの署名処理を示すフローチャートである。 図１７のエントリデータ更新処理において利用者システムに送信されるトランザクションデータリストの例を示す図である。 図１７のエントリデータ更新処理において更新されたエントリの例を示す図である。 図４の利用者システム（利用者端末）を示す図である。 図２１の利用者端末の処理を示すフローチャートである。 図２１の利用者端末の表示例を示す図である。 図２の処理の変形例を示す図である。

図１を参照すると、本発明の実施の形態におけるネットワークは、署名システム１０と、１以上の利用者システム４０（利用者システム１〜ｎ）と、１以上の事業者システム５０（事業者システム１〜ｍ）とを含んでいる。

利用者システム４０の夫々は、１以上の事業者システム５０と通信可能に接続されており、事業者システム５０の夫々は、１以上の利用者システム４０と通信可能に接続されている。また、署名システム１０は、１以上の利用者システム４０と通信可能に接続されており、且つ、１以上の事業者システム５０と通信可能に接続されている。署名システム１０、利用者システム４０及び事業者システム５０は、インターネットによって互いに接続されていてもよいし、他のネットワークによって互いに接続されていてもよい。

本実施の形態によれば、全ての利用者システム４０が全ての事業者システム５０と接続されている。また、署名システム１０は、全ての利用者システム４０及び全ての事業者システム５０と接続されている。署名システム１０は、全ての利用者システム４０及び全ての事業者システム５０に対して後述する署名サービスを提供する。但し、本発明は、これに限られない。例えば、利用者システム４０のうちの１つは、事業者システム５０の１つのみと接続されていてもよい。また、署名システム１０は、この１つの利用者システム４０及び１つの事業者システム５０のみと接続されていてもよい。即ち、署名システム１０は、１つの利用者システム４０及び１つの事業者システム５０のみに対して署名サービスを提供してもよい。

本実施の形態による利用者システム４０の夫々は、操作者（利用者）が保有するＰＣ（personal computer）やスマートフォン等の利用者端末４０である。但し、本発明は、これに限られない。例えば、利用者システム４０の夫々は、公共施設に設置された端末であってもよい。また、利用者は、署名システム１０や事業者システム５０の端末を、利用者端末（利用者システム）４０として使用してもよい。一方、利用者システム４０の夫々は、利用者の業務を行うために利用者が運営する複数のコンピュータからなるシステムであってもよい。即ち、本実施の形態における利用者システム４０は、利用者によって操作される端末やシステムである。

図１及び図９を参照すると、署名システム１０は、利用者システム４０のアカウントを登録した利用者情報２６を有している。利用者情報２６には、１以上の利用者特定データ２６２と、１以上の利用者認証データ２６４とが含まれている。利用者特定データ２６２は、署名システム１０が署名サービスを提供する利用者システム４０と夫々対応している。利用者特定データ２６２の夫々は、対応する利用者システム４０を一意に特定可能なデータである。例えば、利用者特定データ２６２の夫々は、対応する利用者システム４０が署名システム１０のアカウントを作成した際の利用者ＩＤ（identifier）やメールアドレスである。利用者認証データ２６４は、利用者特定データ２６２と夫々対応している。利用者認証データ２６４の夫々は、対応する利用者システム４０を認証するためのデータである。利用者認証データ２６４の夫々は、例えば、パスワードであってもよいし、指紋情報等の生体情報であってもよい。また、利用者情報２６は、必要に応じて設ければよい。

署名システム１０は、利用者情報２６に加えて、事業者システム５０のアカウントを登録した事業者情報（図示せず）を有していてもよい。但し、このような事業者情報は、本実施の形態に必須ではないため特に説明しない。

図１を参照すると、署名システム１０、利用者システム４０及び事業者システム５０は、更に他のノード（図示せず）と共にＰｔｏＰ（Peer to Peer）ネットワークを構成している。ＰｔｏＰネットワークは、ブロックチェーン７０を含んでいる。ブロックチェーン７０は、多数のトランザクション８０を含むデータ集合体である。詳しくは、ブロックチェーン７０は、１以上のブロック（図示せず）を含んでいる。ブロックの夫々は、直前のブロックのハッシュ値を有することで、チェーン状に互いに連結されている。ブロックの夫々は、１以上のトランザクション８０を含んでいる。

トランザクション８０は、送金等の取引を記録したデータ構造体である。トランザクション８０は、ＰｔｏＰネットワークによって分散的に管理されている。より具体的には、トランザクション８０は、多数のノードの記憶装置に分散して記憶されており、多数のノードは、互いに自律的に通信することで、トランザクション８０を整合させている。即ち、全てのトランザクション８０を物理的に一か所で管理する特定のノードは存在しない。但し、本実施の形態における図１等の図面は、トランザクション８０の全てを記憶したブロックチェーン７０が１箇所に存在しているように描画している。また、本発明は、このようなブロックチェーン７０が実際に存在している場合にも適用可能である。

トランザクション８０には、ノード間の様々な取引を記録可能である。例えば、トランザクション８０には、証券の取引を記録してもよく、円やドルなどの現実通貨の取引を記録してもよく、仮想通貨の取引を記録してもよい。本実施の形態において、トランザクション８０は、仮想通貨の取引を記録している。即ち、本実施の形態において、事業者システム５０は、仮想通貨の取引所システムであり、利用者システム４０は、仮想通貨の取引所を介して又は介さずに取引を行う会社や個人のシステムである。但し、本発明は、これに限られない。例えば、事業者システム５０は、証券所システムや銀行システムであってもよい。

トランザクション８０に記録された取引は、トランザクション８０に電子署名（以下、単に「署名」という。）を施すことで承認され有効になる。トランザクション８０は、１つの署名のみを施すことによって承認されるトランザクションに加えて、複数の署名（多重署名：マルチシグニチャ）を施すことによって承認されるマルチシグトランザクション８０Ｍを含んでいる。本発明は、マルチシグトランザクション８０Ｍに関連している。

本実施の形態において、事業者システム５０の夫々は、仮想通貨の保有額を記憶した１以上の口座と、口座に夫々対応する秘密鍵５４２とを有している。加えて、図１に示した利用者システム４０の夫々は、仮想通貨の保有額を記憶した１以上の口座と、口座に夫々対応する秘密鍵４４２とを有している。但し、本発明は、これに限られず、利用者システム４０は、自らの口座及び秘密鍵４４２を有していなくてもよい。

本実施の形態において、事業者システム５０の夫々は、自らの口座のうちの１つから他の事業者システム５０（又は利用者システム４０）の口座のうちの１つに仮想通貨を送金する。同様に、秘密鍵４４２を有する利用者システム４０の夫々は、自らの口座のうちの１つから他の利用者システム４０（又は事業者システム５０）の口座のうちの１つに仮想通貨を送金する。事業者システム５０（利用者システム４０）の夫々は、この送金取引の際に、送金取引の内容を記憶したマルチシグトランザクション８０Ｍを作成して秘密鍵によって署名し、ＰｔｏＰネットワークにブロードキャストする。即ち、利用者システム４０及び事業者システム５０の夫々は、送金取引を行う度に、秘密鍵によって署名したマルチシグトランザクション８０Ｍを発行する。

詳しくは、事業者システム５０の口座の夫々について、互いに対応する秘密鍵５４２及び秘密鍵３４２が設けられている。互いに対応する秘密鍵５４２及び秘密鍵３４２の夫々は、マルチシグトランザクション８０Ｍに署名を施すための複数の秘密鍵のうちの１つである。事業者システム５０は、互いに対応する秘密鍵５４２及び秘密鍵３４２のうちの一方（秘密鍵５４２）を有しており、署名システム１０は、他方（秘密鍵３４２）を有している。事業者システム５０が秘密鍵５４２によって署名して発行したマルチシグトランザクション８０Ｍは、署名システム１０が対応する秘密鍵３４２によって更に署名して発行することで有効になる。

同様に、利用者システム４０の口座の夫々について、互いに対応する秘密鍵４４２及び秘密鍵３４２が設けられている。互いに対応する秘密鍵４４２及び秘密鍵３４２の夫々は、マルチシグトランザクション８０Ｍに署名を施すための複数の秘密鍵のうちの１つである。利用者システム４０は、互いに対応する秘密鍵４４２及び秘密鍵３４２のうちの一方（秘密鍵４４２）を有しており、署名システム１０は、他方（秘密鍵３４２）を有している。利用者システム４０が秘密鍵４４２によって署名して発行したマルチシグトランザクション８０Ｍは、署名システム１０が対応する秘密鍵３４２によって更に署名して発行することで有効になる。

以下の説明において、事業者システム５０又は利用者システム４０が署名して発行した時点でのマルチシグトランザクション８０Ｍを、未承認のマルチシグトランザクション８０Ｍといい、署名システム１０が更に署名して発行した時点でのマルチシグトランザクション８０Ｍを、承認済みのマルチシグトランザクション８０Ｍという。換言すれば、以下の説明において、マルチシグトランザクション８０Ｍについての「未承認」とは、署名システム１０が未だ署名していないことを意味し、マルチシグトランザクション８０Ｍについての「承認済み」とは、署名システム１０が既に署名していることを意味する。即ち、未承認のマルチシグトランザクション８０Ｍは、署名システム１０の署名によって承認されて承認済みのマルチシグトランザクション８０Ｍになる。

本実施の形態において、未承認のマルチシグトランザクション８０Ｍの全てが、署名システム１０の署名対象である。但し、本発明は、これに限られず、ブロックチェーン７０は、署名システム１０の署名対象とならない未承認のマルチシグトランザクション８０Ｍを含んでいてもよい。換言すれば、署名システム１０は、ブロックチェーン７０に含まれる未承認のマルチシグトランザクション８０Ｍのうちの一部のみについて署名してもよい。

図５は、マルチシグトランザクション８０Ｍに含まれるデータのうち、以下の説明において必要なデータのみを示している。図１及び図５を参照すると、マルチシグトランザクション８０Ｍの夫々は、送信側アドレス８２と、送信先アドレス８４と、送信額８５と、トランザクション発行日時８６と、署名データ８８とを含んでいる。送信側アドレス８２は、マルチシグトランザクション８０Ｍを発行した発行側システム（利用者システム４０又は事業者システム５０）の口座を特定するデータである。送信先アドレス８４は、発行側システムに対する相手側システム（利用者システム４０又は事業者システム５０）の口座を特定するデータである。送信額８５は、送信先アドレス８４に対する仮想通貨の送金額を示すデータである。トランザクション発行日時８６は、マルチシグトランザクション８０Ｍを発行した日時である。署名データ８８は、発行側システムや署名システム１０の秘密鍵による署名である。

図５に描画したデータ構造は、本実施の形態を簡潔に説明するための模式的なデータ構造であり、マルチシグトランザクション８０Ｍの実際のデータ構造は、図５に限定されない。特に、署名データ８８は、マルチシグトランザクション８０Ｍが発行側システムや署名システム１０の秘密鍵（所定の秘密鍵）によって署名されているか否かを何らかの方法で判定できる限り、マルチシグトランザクション８０Ｍにデータとして含まれていなくてもよい。例えば、マルチシグトランザクション８０Ｍは、マルチシグトランザクション８０Ｍ全体を所定の秘密鍵によって暗号化することで署名してもよい。

図１及び図６を参照すると、事業者システム５０の夫々は、事業者秘密鍵５４を有している。事業者秘密鍵５４には、１以上の秘密鍵５４２が含まれている。秘密鍵５４２は、事業者秘密鍵５４のデータとして一括管理されていてもよいし、分散管理されていてもよい。

図１、図５及び図６を参照すると、秘密鍵５４２は、事業者システム５０の口座（送信側アドレス８２）に夫々対応している。より具体的には、秘密鍵５４２の夫々は、事業者システム５０が秘密鍵５４２に対応する口座から送金取引を行う際に、マルチシグトランザクション８０Ｍの署名データ８８を生成するために使用される。即ち、本実施の形態において、事業者システム５０が発行するマルチシグトランザクション８０Ｍの署名データ８８は、所定のデータを、マルチシグトランザクション８０Ｍの送信側アドレス８２に対応する秘密鍵５４２によって暗号化したものである。即ち、本実施の形態における秘密鍵５４２の夫々は、マルチシグトランザクション８０Ｍに署名するための秘密鍵である。但し、事業者システム５０は、事業者秘密鍵５４に加えて、マルチシグトランザクション８０Ｍ以外のトランザクション８０に署名するための秘密鍵を有していてもよい。

秘密鍵５４２の夫々は、公開鍵５４４及びマルチシグアドレス５４６と対応している。公開鍵５４４の夫々は、対応する秘密鍵５４２から生成されており、対応する秘密鍵５４２によって暗号化されたデータを復号可能である。マルチシグアドレス５４６の夫々は、対応する公開鍵５４４に対してハッシュ等の変換を施すことで生成されている。マルチシグアドレス５４６の夫々は、事業者システム５０の口座を特定する口座番号として機能する。公開鍵５４４及びマルチシグアドレス５４６は、秘密鍵５４２と合わせて事業者秘密鍵５４に含まれていてもよいし、事業者秘密鍵５４とは別に事業者システム５０内部に記憶されていてもよい。また、公開鍵５４４及びマルチシグアドレス５４６は、事業者システム５０が必要な時点で生成してもよい。

図１及び図７を参照すると、利用者システム４０の夫々は、事業者秘密鍵５４と同様な利用者秘密鍵４４を有している。利用者秘密鍵４４には、１以上の秘密鍵４４２が含まれている。秘密鍵４４２は、利用者秘密鍵４４のデータとして一括管理されていてもよいし、分散管理されていてもよい。

図１、図５及び図７を参照すると、秘密鍵４４２は、利用者システム４０の口座（送信側アドレス８２）に夫々対応している。より具体的には、秘密鍵４４２の夫々は、利用者システム４０が秘密鍵４４２に対応する口座から送金取引を行う際に、マルチシグトランザクション８０Ｍの署名データ８８を生成するために使用される。即ち、本実施の形態において、利用者システム４０が発行するマルチシグトランザクション８０Ｍの署名データ８８は、所定のデータを、マルチシグトランザクション８０Ｍの送信側アドレス８２に対応する秘密鍵４４２によって暗号化したものである。

即ち、本実施の形態における秘密鍵４４２の夫々は、マルチシグトランザクション８０Ｍに署名するための秘密鍵である。但し、利用者システム４０は、利用者秘密鍵４４に加えて、マルチシグトランザクション８０Ｍ以外のトランザクション８０に署名するための秘密鍵を有していてもよい。また、利用者システム４０は、自らの口座を有しておらず、事業者システム５０を介してのみマルチシグトランザクション８０Ｍを発行する場合、利用者秘密鍵４４を有していなくてもよい。即ち、利用者システム４０の夫々は、必要に応じて利用者秘密鍵４４を有していればよい。

秘密鍵４４２の夫々は、公開鍵４４４及びマルチシグアドレス４４６と対応している。公開鍵４４４の夫々は、対応する秘密鍵４４２から生成されており、対応する秘密鍵４４２によって暗号化されたデータを復号可能である。マルチシグアドレス４４６の夫々は、対応する公開鍵４４４に対してハッシュ等の変換を施すことで生成されている。マルチシグアドレス４４６の夫々は、利用者システム４０の口座を特定する口座番号として機能する。公開鍵４４４及びマルチシグアドレス４４６は、秘密鍵４４２と合わせて利用者秘密鍵４４に含まれていてもよいし、利用者秘密鍵４４とは別に利用者システム４０内部に記憶されていてもよい。また、公開鍵４４４及びマルチシグアドレス４４６は、利用者システム４０が必要な時点で生成してもよい。

図１及び図８を参照すると、署名システム１０は、事業者システム５０及び利用者システム４０から預かった預かり秘密鍵３４を有している。預かり秘密鍵３４には、事業者システム５０の夫々について、秘密鍵５４２に夫々対応する１以上の秘密鍵３４２と、秘密鍵３４２に夫々対応する１以上の公開鍵３４４とが含まれている。加えて、預かり秘密鍵３４には、利用者システム４０の夫々について、秘密鍵４４２に夫々対応する１以上の秘密鍵３４２と、秘密鍵３４２に夫々対応する１以上の公開鍵３４４とが含まれている。秘密鍵３４２及び公開鍵３４４は、預かり秘密鍵３４のデータとして一括管理されていてもよいし、分散管理されていてもよい。

例えば、預かり秘密鍵３４の事業者秘密鍵ｊ１Ｙ、事業者秘密鍵ｊ２Ｙ及び事業者秘密鍵ｊ３Ｙ（図８参照）は、事業者秘密鍵５４の事業者秘密鍵ｊ１Ｘ、事業者秘密鍵ｊ２Ｘ及び事業者秘密鍵ｊ３Ｘ（図６参照）と夫々対応しており、預かり秘密鍵３４の利用者秘密鍵ｉ１Ｙ、事業者秘密鍵ｉ２Ｙ及び事業者秘密鍵ｉ３Ｙ（図８参照）は、利用者秘密鍵４４の利用者秘密鍵ｉ１Ｘ、利用者秘密鍵ｉ２Ｘ及び利用者秘密鍵ｉ３Ｘ（図７参照）と夫々対応している。

上述したように、公開鍵３４４は、秘密鍵３４２と夫々対応している。また、秘密鍵３４２の夫々は、秘密鍵５４２及び秘密鍵４４２のうちのいずれか１つ（相手側秘密鍵）と対応している。更に、秘密鍵５４２は、公開鍵５４４と夫々対応しており（図６参照）、秘密鍵４４２は、公開鍵４４４と夫々対応している（図７参照）。公開鍵３４４の夫々は、対応する秘密鍵３４２の相手側秘密鍵の公開鍵５４４（又は、公開鍵４４４）と一致している。事業者システム５０又は利用者システム４０が相手側秘密鍵によって署名して発行した未承認のマルチシグトランザクション８０Ｍは、相手側秘密鍵と対応する秘密鍵３４２によって署名されることで承認され有効になる。換言すれば、マルチシグトランザクション８０Ｍは、事業者システム５０又は利用者システム４０が秘密鍵５４２又は秘密鍵４４２によって署名して発行した時点では未承認であり、署名システム１０の秘密鍵３４２による署名によって承認される。

より具体的には、マルチシグトランザクション８０Ｍの署名データ８８（図５参照）は、事業者システム５０（利用者システム４０）に対応する署名１（図示せず）と、署名システム１０に対応する署名２（図示せず）の２つのデータから構成してもよい。このように構成することで、署名システム１０は、マルチシグトランザクション８０Ｍが未承認なのか又は既に承認されているかを署名データ８８から判定できる。詳しくは、この場合、事業者システム５０（利用者システム４０）は、所定のデータを秘密鍵５４２（秘密鍵４４２）によって暗号化して署名データ８８の署名１に設定する。署名システム１０は、署名１を対応する公開鍵３４４によって復号して所定のデータを得ることで、署名１を検証する。また、署名システム１０は、他の所定のデータを署名１に対応する秘密鍵３４２によって暗号化して署名データ８８の署名２に設定する。

但し、マルチシグトランザクション８０Ｍが未承認なのか又は既に承認されているかを判定する方法は、上述した方法に限られない。例えば、事業者システム５０（利用者システム４０）は、マルチシグトランザクション８０Ｍ全体を秘密鍵５４２（秘密鍵４４２）によって暗号化することで署名してもよい。この場合、署名システム１０は、暗号化されたマルチシグトランザクション８０Ｍを対応する公開鍵３４４によって復号することで事業者システム５０（利用者システム４０）のみによって署名済みであること（未承認であること）を検証してもよい。また、署名システム１０は、暗号化されたマルチシグトランザクション８０Ｍ全体を秘密鍵３４２によって暗号化することで署名して承認してもよい。以下の説明においては、マルチシグトランザクション８０Ｍの署名に関して、署名データ８８に言及しない。

以上の説明から理解されるように、署名システム１０は、事業者システム５０から、事業者システム５０が有する秘密鍵５４２に対応する秘密鍵３４２を、秘密鍵５４２の公開鍵５４４（図６参照）と同一の公開鍵３４４と共に預かっている。同様に、署名システム１０は、利用者システム４０から、利用者システム４０が有する秘密鍵４４２に対応する秘密鍵３４２を、秘密鍵３４２の公開鍵４４４（図７参照）と同一の公開鍵３４４と共に預かっている。

即ち、事業者システム５０は、事業者システム５０が発行するマルチシグトランザクション８０Ｍを承認するために必要な２つの秘密鍵３４２，５４２の一方である秘密鍵５４２を有しており、署名システム１０は、他方である秘密鍵３４２と、秘密鍵５４２による暗号を復号可能な公開鍵３４４とを有している。同様に、利用者システム４０は、利用者システム４０が発行するマルチシグトランザクション８０Ｍを承認するために必要な２つの秘密鍵３４２，４４２の一方である秘密鍵４４２を有しており、署名システム１０は、他方である秘密鍵３４２と、秘密鍵４４２による暗号を復号可能な公開鍵３４４とを有している。

本実施の形態において、マルチシグトランザクション８０Ｍの夫々についての秘密鍵の数は３である。そのうちの２つは、上述したように、事業者システム５０（利用者システム４０）及び署名システム１０が夫々有しており、他の１つは、通常は使用できないように保管されている。トランザクション８０は、秘密鍵３４２，５４２（秘密鍵３４２，４４２）の一方のみの署名によっては有効にならず、２つの秘密鍵３４２，５４２（秘密鍵３４２，４４２）の署名（連署）によって有効になる。即ち、本実施の形態におけるマルチシグニチャは、２ｏｆ３方式である。但し、本発明は、これに限られず、様々な方式のマルチシグニチャに適用可能である。

以下、署名システム１０の署名サービスについて、利用者システム４０のうちの１つ（利用者システムｉ）及び事業者システム５０のうちの１つ（事業者システムｊ）に着目して説明する。以下の説明において、特に注記しない限り、「利用者システム４０」は、利用者システムｉを意味しており、「事業者システム５０」は、利用者システムｊを意味している。

図２から図４までを参照すると、署名システム１０は、利用者に関連して事業者システム５０が秘密鍵５４２によって署名して発行した未承認のマルチシグトランザクション８０Ｍに対して、秘密鍵５４２に対応する他の秘密鍵３４２によって署名する。図２を参照すると、署名システム１０は、署名サービスの１つとして、利用者システム４０及び事業者システム５０に対して、ＢｔｏＢｔｏＣサービス（business to business to consumerサービス）を提供する。加えて、図３を参照すると、署名システム１０は、署名サービスの他の１つとして、利用者システム４０に対して、ＢｔｏＣサービス（business to business to consumerサービス）を提供する。従って、図４を参照すると、署名システム１０は、利用者システム４０及び事業者システム５０に対して、上述したＢｔｏＢｔｏＣサービス（図２参照）とサービスＢｔｏＣサービス（図３参照）の２つのサービスを提供できる。

換言すれば、本実施の形態の署名システム１０は、図２に示されるＢｔｏＢｔｏＣサービスを提供する機能と、図３に示されるＢｔｏＢｔｏＣサービスを提供する機能との２つの機能を有している。但し、本発明は、これに限られない。例えば、署名システム１０は、ＢｔｏＢｔｏＣサービスを提供する機能のみを有していてもよく、ＢｔｏＣサービスを提供する機能のみを有していてもよい。また、署名システム１０は、これらのサービスと異なる署名サービスを提供する機能を更に有していてもよい。

以下、署名システム１０のＢｔｏＢｔｏＣサービスについて説明する。

図２を参照すると、まず、利用者システム４０は、利用者システム４０の操作者の操作に応じて、事業者システム５０に対して、マルチシグトランザクション８０Ｍの発行を依頼する（図２の（１）発行依頼）。例えば、事業者システム５０は、仮想通貨の口座を有しており、利用者システム４０は、事業者システム５０の口座に保管された仮想通貨の一部を所有している。利用者システム４０は、事業者システム５０の口座から、利用者システム４０が所有する仮想通貨の全部又は一部（以下、「送金額」という。）を、他の利用者システム４０又は事業者システム５０（図２において描画せず）の口座（以下、「送金先口座」という。）に対して送金するように依頼する。

本実施の形態において、図２の（１）発行依頼は、利用者システム４０から事業者システム５０へのデータ通信によって行われる。但し、本発明は、これに限られない。例えば、利用者システム４０の利用者が、電話やＦＡＸによって、事業者システム５０の管理者にマルチシグトランザクション８０Ｍの発行を依頼してもよい。

次に、発行依頼を受信した事業者システム５０は、利用者システム４０が実際に仮想通貨を所有しているかといった検証を行った後、マルチシグトランザクション８０Ｍを作成し、作成したマルチシグトランザクション８０Ｍに署名してマルチシグトランザクション８０Ｍを発行する（図２の（２）署名＆発行）。

図２、図５及び図６を参照すると、図２の（２）署名＆発行において、事業者システム５０は、マルチシグトランザクション８０Ｍの送信側アドレス８２に、利用者システム４０が所有する仮想通貨を保管している口座を特定するマルチシグアドレス５４６を設定し、送信先アドレス８４に、送金先口座を特定するデータを設定し、送信額８５に、送金額を設定し、トランザクション発行日時８６に、マルチシグトランザクション８０Ｍを作成した日時を設定する。次に、事業者システム５０は、送信側アドレス８２に設定したマルチシグアドレス５４６に対応する秘密鍵５４２によってマルチシグトランザクション８０Ｍに署名する。次に、事業者システム５０は、マルチシグトランザクション８０Ｍをブロードキャストする。この結果、事業者システム５０が作成したマルチシグトランザクション８０Ｍがブロックチェーン７０に記憶される。即ち、事業者システム５０が作成した未承認のマルチシグトランザクション８０Ｍが発行される。

以上のように発行されたマルチシグトランザクション８０Ｍの送信側アドレス８２には、マルチシグアドレス５４６が設定されている。換言すれば、図２の（２）署名＆発行において発行されるマルチシグトランザクション８０Ｍは、マルチシグアドレス５４６から発行されている。

図２を参照すると、次に、事業者システム５０は、発行したマルチシグトランザクション８０Ｍに対応するエントリデータ５６を作成する。次に、事業者システム５０は、署名システム１０に対して、作成したエントリデータ５６を付したエントリデータ追加依頼を送信し、これによりマルチシグトランザクション８０Ｍを発行したことを署名システム１０に通知する（図２の（３）エントリデータ追加依頼）。

図２及び図１０を参照すると、エントリデータ５６には、トランザクション特定データ５６０と、トランザクション発行日時５６２と、送信先アドレス５６４と、送信額５６５と、利用者特定データ５６６とが含まれている。事業者システム５０は、エントリデータ５６を作成する際、トランザクション発行日時５６２に、対応するマルチシグトランザクション８０Ｍのトランザクション発行日時８６を設定し、送信先アドレス５６４に、対応するマルチシグトランザクション８０Ｍの送信先アドレス８４を設定し、送信額５６５に、対応するマルチシグトランザクション８０Ｍの送信額８５を設定する。

事業者システム５０は、エントリデータ５６を作成する際、トランザクション特定データ５６０に、対応するマルチシグトランザクション８０Ｍを特定可能なデータを設定する。例えば、事業者システム５０は、対応するマルチシグトランザクション８０Ｍから、署名システム１０に通知しているハッシュ方法によるハッシュ値を生成し、生成したハッシュ値を、トランザクション特定データ５６０に設定する。但し、本発明は、これに限られない。署名システム１０が、ブロックチェーン７０におけるトランザクション８０から対応するマルチシグトランザクション８０Ｍを一意に特定できる限り、トランザクション特定データ５６０は、どのようなデータであってもよい。

事業者システム５０は、エントリデータ５６を作成する際、利用者特定データ５６６に、対応するマルチシグトランザクション８０Ｍの発行を依頼した利用者システム４０を特定可能なデータを設定する。例えば、事業者システム５０は、利用者システム４０が対応するマルチシグトランザクション８０Ｍの発行を依頼した際に（図２の（１）発行依頼）、利用者システム４０が利用者特定データ２６２として登録しているメールアドレスを利用者システム４０から受信し、受信したメールアドレスを利用者特定データ５６６に設定する。但し、本発明は、これに限られない。署名システム１０が、マルチシグトランザクション８０Ｍの発行を依頼した利用者システム４０を一意に特定できる限り、利用者特定データ５６６は、どのようなデータであってもよい。

図２及び図１１を参照すると、署名システム１０は、エントリ２４Ｃを有している。事業者システム５０が署名システム１０にエントリデータ５６を送信すると（図２の（３）エントリデータ追加依頼）、署名システム１０は、受信したエントリデータ５６をエントリ２４Ｃに追加する。

詳しくは、エントリ２４Ｃは、エントリデータ２４の集合体である。エントリデータ２４の夫々は、トランザクション特定データ２４０と、トランザクション発行日時２４２と、送信先アドレス２４４と、送信額２４５と、利用者特定データ２４６と、ステータス２４８とを有している。署名システム１０は、エントリデータ５６を受信する度に、受信したエントリデータ５６に基づいて、新たなエントリデータ２４を作成してエントリ２４Ｃに追加する。即ち、署名システム１０は、事業者システム５０から受信したエントリデータ追加依頼（図２の（３）エントリデータ追加依頼）に夫々応じて作成した１以上のエントリデータ２４を有している。エントリデータ２４の夫々は、マルチシグトランザクション８０Ｍと対応している。

図１０及び図１１を参照すると、受信したエントリデータ５６に基づくエントリデータ２４が追加されたとき、追加されたエントリデータ２４のトランザクション特定データ２４０、トランザクション発行日時２４２、送信先アドレス２４４、送信額２４５及び利用者特定データ２４６には、受信したエントリデータ５６のトランザクション特定データ５６０、トランザクション発行日時５６２、送信先アドレス５６４、送信額５６５及び利用者特定データ５６６が夫々設定され、ステータス２４８には「未承認」を意味するデータが設定される。後述するように、ステータス２４８の「未承認」を意味するデータは、利用者システム４０による署名承認や署名否認に応じて、「署名承認済み」を意味するデータや、「署名否認済み」を意味するデータに変更される。

図２及び図１１を参照すると、署名システム１０は、上述したように、事業者システム５０から受信したエントリデータ５６をエントリデータ２４として集めたエントリ２４Ｃを有している。エントリデータ２４の夫々は、事業者システム５０が利用者システム４０からの発行依頼（図２の（１）発行依頼）に応じて秘密鍵５４２によって署名して発行したマルチシグトランザクション８０Ｍと対応している。エントリデータ２４の夫々には、エントリデータ２４に対応するマルチシグトランザクション８０Ｍを特定可能なトランザクション特定データ２４０と、対応するマルチシグトランザクション８０Ｍを発行依頼した利用者システム４０を特定可能な利用者特定データ２４６とが含まれている。

図２を参照すると、利用者システム４０は、事業者システム５０に対してトランザクション８０の発行を依頼すると（図２の（１）発行依頼）、その後の所定の時点において、署名システム１０にログインする（図２の（４）ログイン）。

図２及び図９を参照すると、署名システム１０は、利用者システム４０からログイン要求を受けると（図２の（４）ログイン）、利用者特定データ２６２及び利用者認証データ２６４を使用して利用者システム４０を認証したうえで、利用者システム４０のログインを許容する。

本実施の形態による署名システム１０は、例えば、ログイン要求（図２の（４）ログイン）の際に、利用者システム４０から利用者システム４０の操作者のメールアドレスや生体情報を受信する。署名システム１０は、受信したメールアドレスを、利用者情報２６の利用者特定データ２６２と照合することで、利用者システム４０を特定する。また、署名システム１０は、受信した生体情報を、特定した利用者システム４０の利用者認証データ２６４と照合することで、利用者システム４０を認証する。

図２を参照すると、署名システム１０は、利用者システム４０のログイン要求（図２の（４）ログイン）によってトランザクション参照依頼が行われたと判断し、以下の処理を行う。但し、本発明は、これに限られない。例えば、利用者システム４０は、ログイン要求と異なるタイミングで、署名システム１０に対してトランザクション参照依頼を送信してもよい。また、署名システム１０は、ログイン中の利用者システム４０に対して、所定の時間が経過する度に、トランザクション参照依頼が行われたものとして以下の処理を行ってもよい。

まず、署名システム１０は、利用者システム４０からのトランザクション参照依頼（図２の（４）ログイン）をトリガーとして、ブロックチェーン７０のトランザクション８０から、署名対象となるマルチシグトランザクション８０Ｍを収集する（図２の（５）収集）。詳しくは、署名システム１０は、利用者に関連するマルチシグトランザクション８０Ｍであって署名システム１０の秘密鍵３４２による署名が必要なマルチシグトランザクション８０Ｍを収集する。

図２、図５及び図１１を参照すると、署名システム１０は、ＢｔｏＢｔｏＣサービスにおいて上述したマルチシグトランザクション８０Ｍの収集を行う際、エントリデータ２４のトランザクション特定データ２４０によって特定される未承認のマルチシグトランザクション８０Ｍを、利用者に関連するマルチシグトランザクション８０Ｍとして収集する。

図２を参照すると、次に、署名システム１０は、収集したマルチシグトランザクション８０Ｍからトランザクションデータリスト２８Ｌを作成し、作成したトランザクションデータリスト２８Ｌを、トランザクション参照依頼（図２の（４）ログイン）を送信した利用者システム４０に送信する（図２の（６）トランザクションデータリスト送信）。

図２及び図１２を参照すると、トランザクションデータリスト２８Ｌは、署名システム１０が収集した（図２の（５）収集）マルチシグトランザクション８０Ｍに夫々対応するトランザクションデータ２８のリストである。トランザクションデータ２８の夫々には、トランザクション特定データ２８０と、トランザクション発行日時２８２と、事業者識別データ２８４と、送信先アドレス２８６と、送信額２８８とが含まれている。

図２、図１１及び図１２を参照すると、トランザクションデータ２８の夫々は、署名システム１０が収集した（図２の（５）収集）マルチシグトランザクション８０Ｍに対応するエントリデータ２４に基づいて作成されている。換言すれば、トランザクションデータ２８の夫々は、エントリデータ２４のいずれかと対応している。トランザクションデータ２８の夫々におけるトランザクション特定データ２８０、トランザクション発行日時２８２、送信先アドレス２８６及び送信額２８８には、対応するエントリデータ２４のトランザクション特定データ２４０、トランザクション発行日時２４２、送信先アドレス２４４及び送信額２４５が夫々設定されている。

図２、図５及び図１２を参照すると、ＢｔｏＢｔｏＣサービスにおいて、トランザクションデータ２８の夫々における事業者識別データ２８４には、「ＡＡＡ取引所」といった、利用者システム４０の操作者が事業者システム５０を識別可能なデータが設定されている。例えば、署名システム１０は、トランザクションデータ２８の夫々について、対応するマルチシグトランザクション８０Ｍの送信側アドレス８２を参照して、事業者識別データ２８４を作成する。

詳しくは、前述したように、マルチシグトランザクション８０Ｍの送信側アドレス８２には、マルチシグトランザクション８０Ｍを発行した事業者システム５０のマルチシグアドレス５４６（図６参照）が設定されている。また、署名システム１０は、このマルチシグアドレス５４６を生成可能な公開鍵３４４（図８参照）を有している。署名システム１０は、マルチシグアドレス５４６を参照してマルチシグトランザクション８０Ｍを発行した事業者システム５０を特定し、特定した事業者システム５０を、例えば変換テーブルによって事業者名に変換して事業者識別データ２８４に設定する。

上述したように、トランザクションデータリスト２８Ｌにおけるトランザクションデータ２８の夫々には、対応するマルチシグトランザクション８０Ｍを発行した事業者システム５０を識別可能なデータである事業者識別データ２８４が含まれている。本実施の形態における事業者識別データ２８４は、事業者システム５０の事業者の名称である。但し、本発明は、これに限られない。例えば、事業者識別データ２８４は、事業者のロゴ等の画像データであってもよい。

図２を参照すると、利用者システム４０は、後述するように、受信したトランザクションデータリスト２８Ｌを利用者システム４０の操作者に表示する。利用者システム４０は、操作者の操作に応じて、トランザクションデータリスト２８Ｌのトランザクションデータ２８の夫々についての署名承認又は署名否認を署名システム１０に送信する（図２の（７）署名承認ｏｒ署名否認）。前述したように、トランザクションデータ２８の夫々は、マルチシグトランザクション８０Ｍのいずれかと対応している。トランザクションデータ２８の夫々についての署名承認又は署名否認は、対応するマルチシグトランザクション８０Ｍの署名承認又は署名否認である。

図２及び図１２を参照すると、署名システム１０は、利用者システム４０からトランザクションデータ２８の夫々に対応するマルチシグトランザクション８０Ｍの署名承認又は署名否認を受信する。図２、図１１及び図１２を参照すると、署名システム１０は、署名承認されたトランザクションデータ２８に対応するエントリデータ２４のステータス２４８に「署名承認済み」を意味するデータを設定し、署名否認されたトランザクションデータ２８に対応するエントリデータ２４のステータス２４８に「署名否認済み」を意味するデータを設定する。

図２及び図１１を参照すると、次に、署名システム１０は、署名承認されたマルチシグトランザクション８０Ｍに対して秘密鍵３４２によって署名して発行する（図２の（８）署名＆発行）。詳しくは、署名システム１０は、ブロックチェーン７０から、「署名承認済み」を意味するデータを設定したエントリデータ２４に対応するマルチシグトランザクション８０Ｍを取得する。次に、署名システム１０は、取得したマルチシグトランザクション８０Ｍに対して、送信側アドレス８２（図５参照）に設定されているマルチシグアドレス５４６（図６参照）に対応する秘密鍵３４２によって署名する。次に、署名システム１０は、署名したマルチシグトランザクション８０Ｍをブロードキャストする。この結果、署名システム１０が署名したことによって承認された有効なマルチシグトランザクション８０Ｍがブロックチェーン７０に記憶される。即ち、承認済みのマルチシグトランザクション８０Ｍが発行される。

署名システム１０は、承認済みのマルチシグトランザクション８０Ｍを発行した後、発行したマルチシグトランザクション８０Ｍに対応するエントリデータ２４のステータス２４８に「署名済み」を意味するデータを設定してもよい。

以上に説明したように、本実施の形態によれば、利用者に関連するマルチシグトランザクション８０Ｍ、例えば、利用者システム４０の発行依頼に応じて事業者システム５０が秘密鍵５４２によって署名して発行したマルチシグトランザクション８０Ｍは、署名システム１０が利用者システム４０からの署名への承認を受信した場合に、署名システム１０の秘密鍵３４２によって署名される。即ち、マルチシグトランザクション８０Ｍは、発行依頼した利用者システム４０の利用者による確認という手順を踏んで署名されるため、事業者システム５０の秘密鍵５４２が漏洩した場合も、漏洩した秘密鍵５４２の不正な使用による被害を防止できる。本発明によれば、マルチシグトランザクション８０Ｍの信頼性を向上可能な新たな署名システム１０を提供できる。

特に、本実施の形態によれば、利用者による署名承認が必要なマルチシグトランザクション８０Ｍは、トランザクションデータリスト２８Ｌに纏められて発行依頼した利用者システム４０に送信される。従って、利用者は、マルチシグトランザクション８０Ｍに対して署名承認すべきか署名否認すべきかを、取引内容を確認しつつ判断できる。

署名システム１０による署名サービスは、上述したＢｔｏＢｔｏＣサービスに限られず、必要に応じて様々に応用可能である。以下、署名システム１０のＢｔｏＣサービスについて説明する。

図３を参照すると、まず、利用者システム４０は、利用者システム４０の操作者の操作に応じて、利用者システム４０の口座から送金先口座に対して送金額を送金するという内容のマルチシグトランザクション８０Ｍを作成する。利用者システム４０は、作成したマルチシグトランザクション８０Ｍに対して秘密鍵４４２によって署名してマルチシグトランザクション８０Ｍを発行する（図３の（１）署名＆発行）。

図３、図５及び図７を参照すると、図３の（１）署名＆発行において、利用者システム４０は、ＢｔｏＢｔｏＣサービス（図２参照）における事業者システム５０と同様に、マルチシグトランザクション８０Ｍのデータを設定する。詳しくは、利用者システム４０は、送信側アドレス８２に、利用者システム４０の仮想通貨を保管している口座を特定するマルチシグアドレス４４６を設定し、送信先アドレス８４に、送金先口座を特定するデータを設定し、送信額８５に、送金額を設定し、トランザクション発行日時８６に、トランザクション８０を作成した日時を設定する。

次に、利用者システム４０は、送信側アドレス８２に設定したマルチシグアドレス４４６に対応する秘密鍵４４２によってマルチシグトランザクション８０Ｍに署名する。次に、利用者システム４０は、マルチシグトランザクション８０Ｍをブロードキャストする。この結果、利用者システム４０が作成したマルチシグトランザクション８０Ｍがブロックチェーン７０に記憶される。即ち、利用者システム４０が作成した未承認のマルチシグトランザクション８０Ｍが発行される。ＢｔｏＣサービスにおいて発行されたマルチシグトランザクション８０Ｍは、マルチシグアドレス４４６から発行されている。

図３を参照すると、利用者システム４０は、マルチシグトランザクション８０Ｍを発行すると（図３の（１）署名＆発行）、その後の所定の時点において、ＢｔｏＢｔｏＣサービス（図２参照）と同様に、署名システム１０にログインし、これにより、署名システム１０に対してトランザクション参照依頼を行う（図３の（２）ログイン）。署名システム１０は、利用者システム４０からログイン要求を受けると、ＢｔｏＢｔｏＣサービス（図２参照）と同様に、利用者特定データ２６２及び利用者認証データ２６４（図９参照）を使用して利用者システム４０を認証したうえで、利用者システム４０のログインを許容する。

署名システム１０は、利用者システム４０からのトランザクション参照依頼（図３の（２）ログイン）をトリガーとして、ブロックチェーン７０のトランザクション８０から、署名対象となる未承認のマルチシグトランザクション８０Ｍを収集する（図３の（３）収集）。詳しくは、署名システム１０は、ＢｔｏＣサービスにおいて、利用者システム４０が秘密鍵４４２によって署名してマルチシグアドレス４４６から発行したマルチシグトランザクション８０Ｍであって署名システム１０の秘密鍵３４２による署名が必要な未承認のマルチシグトランザクション８０Ｍを収集する。

図３、図５及び図１３を参照すると、署名システム１０は、収集したマルチシグトランザクション８０Ｍの夫々に基づいて対応するエントリデータ２４を作成してエントリ２４Ｃに追加する。署名システム１０は、追加したエントリデータ２４のトランザクション特定データ２４０に、対応するマルチシグトランザクション８０Ｍを特定可能なデータ、例えば、対応するマルチシグトランザクション８０Ｍのハッシュ値を設定する。署名システム１０は、追加したエントリデータ２４のトランザクション発行日時２４２、送信先アドレス２４４及び送信額２４５に、対応するマルチシグトランザクション８０Ｍのトランザクション発行日時８６、送信先アドレス８４及び送信額８５を夫々設定する。署名システム１０は、追加したエントリデータ２４のステータス２４８に、「未承認」を意味するデータを設定する。

署名システム１０は、追加したエントリデータ２４の利用者特定データ２４６に、ログインした利用者システム４０を特定可能なデータを設定する。例えば、署名システム１０は、利用者特定データ２４６に、ログインした利用者システム４０に対応する利用者特定データ２６２（図９参照）を設定する。但し、本発明は、これに限られず、利用者特定データ２４６は、署名システム１０が、ログインした利用者システム４０を一意に特定できる限り、どのようなデータであってもよい。

図３、図１３及び図１４を参照すると、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、収集したマルチシグトランザクション８０Ｍに夫々対応するトランザクションデータ２８のリストであるトランザクションデータリスト２８Ｌを作成し、作成したトランザクションデータリスト２８Ｌを、トランザクション参照依頼（図３の（２）ログイン）を送信した利用者システム４０に送信する（図３の（４）トランザクションデータリスト送信）。図１３及び図１４を参照すると、トランザクションデータ２８の夫々は、エントリデータ２４のいずれかと対応している。

図３及び図１４を参照すると、ＢｔｏＣサービスにおいて、トランザクションデータ２８の夫々における事業者識別データ２８４には、スペース等の初期値が設定されている。利用者システム４０は、事業者識別データ２８４に初期値が設定されていることで、事業者システム５０ではなく利用者システム４０が発行したマルチシグトランザクション８０Ｍに対応するトランザクションデータ２８であることを識別できる。即ち、ＢｔｏＣサービスにおいて、トランザクションデータリスト２８Ｌにおけるトランザクションデータ２８の夫々には、利用者システム４０が発行したマルチシグトランザクション８０Ｍであることを識別可能なデータである事業者識別データ２８４が含まれている。

図３を参照すると、利用者システム４０は、ＢｔｏＢｔｏＣサービスと同様に、受信したトランザクションデータリスト２８Ｌを利用者システム４０の操作者に表示する。利用者システム４０は、操作者の操作に応じて、トランザクションデータリスト２８Ｌのトランザクションデータ２８の夫々についての署名承認又は署名否認を署名システム１０に送信する（図３の（５）署名承認ｏｒ署名否認）。ＢｔｏＢｔｏＣサービスと同様に、トランザクションデータ２８の夫々は、マルチシグトランザクション８０Ｍのいずれかと対応している。トランザクションデータ２８の夫々についての署名承認又は署名否認は、対応するマルチシグトランザクション８０Ｍの署名承認又は署名否認である。

図３及び図１４を参照すると、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、利用者システム４０からトランザクションデータ２８の夫々に対応するマルチシグトランザクション８０Ｍの署名承認又は署名否認を受信する。図３及び図１３を参照すると、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、利用者システム４０から受信した署名承認又は署名否認に基づいて、エントリデータ２４のステータス２４８を設定する。次に、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、署名承認されたマルチシグトランザクション８０Ｍに対して秘密鍵３４２によって署名して発行する（図３の（６）署名＆発行）。

詳しくは、署名システム１０は、「署名承認済み」を意味するデータを設定したエントリデータ２４に対応するマルチシグトランザクション８０Ｍを取得する。次に、署名システム１０は、取得したマルチシグトランザクション８０Ｍに対して、送信側アドレス８２（図５参照）に設定されているマルチシグアドレス４４６（図７参照）に対応する秘密鍵３４２によって署名する。次に、署名システム１０は、マルチシグトランザクション８０Ｍをブロードキャストする。この結果、署名システム１０が署名したことによって承認された有効なマルチシグトランザクション８０Ｍがブロックチェーン７０に記憶される。即ち、承認済みのマルチシグトランザクション８０Ｍが発行される。

上述したように、署名システム１０は、利用者システム４０が秘密鍵４４２によって署名して発行したマルチシグトランザクション８０Ｍに対して、秘密鍵４４２に対応する他の秘密鍵３４２によって署名する。署名システム１０がＢｔｏＢｔｏＣサービスに加えてＢｔｏＣサービスを提供することで、マルチシグトランザクション８０Ｍの信頼性を更に向上できる。

図１を参照すると、以下、本実施の形態における署名システム１０のシステム構成を説明すると共に、署名システム１０が複数の利用者システム４０及び複数の事業者システム５０に対して２つのサービスを提供する際の署名システム１０の処理について説明する。

図１５を参照すると、署名システム１０は、パブリックシステム２０と、プライベートシステム３０とを備えている。

パブリックシステム２０は、ＣＰＵ（central processing unit：図示せず）を含めた様々な電子部品から構成されるパブリックサーバ２２と、エントリ２４Ｃ及び利用者情報２６を記憶した記憶装置とを備えている。パブリックサーバ２２は、この記憶装置に対して読み込み可能かつ書き込み可能に接続されている。例えば、パブリックサーバ２２は、ＣＰＵによって様々なプログラムを実行することで、エントリ２４Ｃ及び利用者情報２６の夫々を参照及び更新する。描画したエントリ２４Ｃ及び利用者情報２６は、夫々異なるディスクユニットに記憶されている。但し、本発明は、これに限られず。エントリ２４Ｃ及び利用者情報２６の物理的な記憶方法は特に限定されない。

パブリックサーバ２２は、通信回線によって、利用者システム４０及び事業者システム５０の夫々と通信可能に接続されている。また、パブリックサーバ２２は、通信回線を経由して、ブロックチェーン７０からマルチシグトランザクション８０Ｍを収集できる。

プライベートシステム３０は、パブリックシステム２０と同様に、ＣＰＵを含めた様々な電子部品から構成されるプライベートサーバ３２と、預かり秘密鍵３４が記憶された記憶装置とを備えている。プライベートサーバ３２は、この記憶装置に対して読み込み可能かつ書き込み可能に接続されている。例えば、プライベートサーバ３２は、ＣＰＵによって様々なプログラムを実行することで、預かり秘密鍵３４を参照可能である。

プライベートサーバ３２は、通信回線を経由して、ブロックチェーン７０にマルチシグトランザクション８０Ｍを発行できる。また、パブリックサーバ２２は、パブリックシステム２０のエントリ２４Ｃを読み込み可能かつ書き込み可能に接続されている。この接続を除き、パブリックシステム２０とプライベートシステム３０との間は、ファイアウォール等によって完全に遮断されており、これにより預かり秘密鍵３４が安全に保管されている。

本実施の形態において、パブリックサーバ２２及びプライベートサーバ３２の夫々がＣＰＵによって様々なプログラムを実行することで、署名システム１０の様々なサービスが提供される。換言すれば、署名システム１０のサービスは、パブリックサーバ２２を備えたパブリックシステム２０と、プライベートサーバ３２を備えたプライベートシステム３０とによって提供される。但し、署名システム１０がサービスを提供するためのシステム構成は本実施の形態に限られず、様々に変形可能である。

図４及び図１５を参照すると、本実施の形態において、パブリックシステム２０は、事業者システム５０からのエントリデータ５６の受信（図４の（３）エントリデータ追加依頼）と、エントリデータ５６に基づくエントリデータ２４のエントリ２４Ｃへの追加と、利用者システム４０からのトランザクション参照依頼の受信（図４の（５）ログイン）と、ブロックチェーン７０からのマルチシグトランザクション８０Ｍの収集（図４の（６）収集）と、トランザクションデータリスト２８Ｌの作成と、作成したトランザクションデータリスト２８Ｌの利用者システム４０への送信（図４の（７）トランザクションデータリスト送信）と、利用者システム４０からのマルチシグトランザクション８０Ｍの署名承認又は署名否認の受信（図４の（８）署名承認ｏｒ署名否認）とを行う。プライベートシステム３０は、マルチシグトランザクション８０Ｍの署名及び発行（図４の（９）署名＆発行）を行う。

上述したパブリックシステム２０の処理は、エントリデータ追加処理（図１６参照）と、エントリデータ更新処理（図１７参照）とに大別できる。一方、プライベートシステム３０は、署名処理（図１８参照）を行う。以下、エントリデータ追加処理、エントリデータ更新処理及び署名処理の夫々について、フローチャートを使用して詳細に説明する。

図１５及び図１６を参照すると、エントリデータ追加処理において、パブリックシステム２０のパブリックサーバ２２は、事業者システム５０から、エントリデータ５６を伴うエントリデータ追加依頼を受信する（Ｓ１６０２）。このとき、パブリックサーバ２２は、エントリデータ追加依頼が送信されたＩＰ（internet protocol）アドレスを参照して、エントリデータ５６を受信するか否かを判断してもよい。

次に、パブリックサーバ２２は、受信したエントリデータ追加依頼が所定のエントリデータ追加条件を満たすか否か判定する（Ｓ１６０４）。エントリデータ追加条件は、例えば、受信したエントリデータ５６に対応するマルチシグトランザクション８０Ｍが存在することである（Ｓ１６０４）。

詳しくは、パブリックサーバ２２は、ブロックチェーン７０から、受信したエントリデータ５６のトランザクション特定データ５６０（図１０参照）によって特定されるマルチシグトランザクション８０Ｍの取得を試みる。このマルチシグトランザクション８０Ｍが取得できない場合、パブリックサーバ２２は、エントリデータ追加条件が満たされていないと判定する。このマルチシグトランザクション８０Ｍが取得できた場合、パブリックサーバ２２は、エントリデータ５６のトランザクション発行日時５６２、送信先アドレス５６４及び送信額５６５（図１０参照）が取得したマルチシグトランザクション８０Ｍのデータと一致するか否か判定する。パブリックサーバ２２は、一致する場合、エントリデータ追加条件が満たされていると判定し、一致しない場合、エントリデータ追加条件が満たされていないと判定する。

パブリックサーバ２２は、エントリデータ追加条件が満たされていないと判定したとき（Ｓ１６０４のＮＧ）、事業者システム５０に警告を送信する（Ｓ１６０６）。

一方、パブリックサーバ２２は、エントリデータ追加条件が満たされていると判定したとき（Ｓ１６０４のＯＫ）、受信したエントリデータ５６をエントリ２４Ｃに追加する（Ｓ１６０８）。詳しくは、前述したように、エントリデータ５６に基づくエントリデータ２４をエントリ２４Ｃに追加する。

本実施の形態のエントリデータ追加処理によれば、署名システム１０は、事業者システム５０からエントリデータ５６を受信したとき、受信したエントリデータ５６が所定のエントリデータ追加条件を満たすか否か判定する。エントリデータ追加条件は、必要に応じて必要な条件を設定すればよい。署名システム１０は、エントリデータ追加条件を満たした場合にエントリデータ２４を作成してエントリ２４Ｃに追加する。一方、署名システム１０は、エントリデータ追加条件を満たさない場合、例えば、不正なエントリデータ５６を受信した旨の警告を、事業者システム５０に送信する。事業者システム５０への警告により、不正なマルチシグトランザクション８０Ｍの承認を防止でき、これによりマルチシグトランザクション８０Ｍの信頼性を更に向上できる。但し、本発明は、これに限られず、エントリデータ追加条件による判定は、必要に応じて行えばよい。

図１５及び図１７を参照すると、エントリデータ更新処理において、パブリックシステム２０のパブリックサーバ２２は、利用者システム４０からログインデータ（即ち、トランザクション参照依頼）を受信する（Ｓ１７０２）。

次に、パブリックサーバ２２は、受信したログインデータを使用して、ログインデータを送信した利用者システム４０を認証する（Ｓ１７０４）。例えば、パブリックサーバ２２は、ログインデータに含まれる利用者ＩＤが、利用者情報２６の利用者特定データ２６２のいずれかと一致するか否か判定する。パブリックサーバ２２は、更に、ログインデータに含まれる生体情報が、ログインデータの利用者ＩＤと一致する利用者特定データ２６２に対応する利用者認証データ２６４と一致するか否か判定する。

パブリックサーバ２２は、利用者システム４０を認証できなかったとき（Ｓ１７０４のＮＧ）、利用者システム４０からのログインを拒否する（Ｓ１７０６）。

一方、パブリックサーバ２２は、利用者システム４０を認証できたとき（Ｓ１７０４のＯＫ）、利用者システム４０のログインを許容する。次に、パブリックサーバ２２は、ブロックチェーン７０から、ログインした（即ち、トランザクション参照依頼を行った）利用者に関連して利用者システム４０のマルチシグアドレス４４６（図７参照）又は事業者システム５０のマルチシグアドレス５４６（図６参照）から発行されており、且つ、利用者システム４０の秘密鍵４４２（図７参照）又は事業者システム５０の秘密鍵５４２（図６参照）によって署名された未承認のマルチシグトランザクション８０Ｍを収集する。

上述の収集の際、パブリックサーバ２２は、エントリ２４Ｃを参照し、トランザクション参照依頼を行った利用者システム４０を特定している利用者特定データ２４６（図１３参照）を含むエントリデータ２４を選択し、選択したエントリデータ２４のトランザクション特定データ２４０（図１０参照）によって特定されるマルチシグトランザクション８０Ｍを、利用者に関連して発行されていると判定する（以下、「判定１」という）。

加えて、上述の収集の際、トランザクション参照依頼を行った利用者システム４０が利用者システム４０の秘密鍵４４２（図７参照）によって署名して発行したマルチシグトランザクション８０Ｍ、即ち、利用者システム４０のマルチシグアドレス４４６（図７参照）からのマルチシグトランザクション８０Ｍを、利用者に関連して発行されていると判定する（以下、「判定２」という）。パブリックサーバ２２は、この判定２において、更に、マルチシグトランザクション８０Ｍが所定の収集条件を満たすか否かを判定する。

上述の収集条件は、例えば、送信先アドレス８４（図５参照）がホワイトリストに載っていることであってもよいし、送信額８５（図５参照）の所定期間内（例えば、１日又は１ヵ月）の合計額が所定限度額を超えないことであってもよい。収集条件は、送信側アドレス８２（図５参照）がホワイトリストに載っていることであってもよい。収集条件は、利用者システム４０からの送信額８５の所定期間内の合計額が所定限度額を超えないことであってもよいし、利用者システム４０からの所定期間内のマルチシグトランザクション８０Ｍの発行回数が所定限度回数を超えないことであってもよい。

次に、パブリックサーバ２２は、判定２を満たすことで収集したマルチシグトランザクション８０Ｍに基づいてエントリ２４Ｃを更新する（Ｓ１７１０）。詳しくは、ＢｔｏＣサービスについて説明したように、パブリックサーバ２２は、収集したマルチシグトランザクション８０Ｍの夫々から新たなエントリデータ２４を作成してエントリ２４Ｃに追加する。

次に、パブリックサーバ２２は、収集したマルチシグトランザクション８０Ｍに夫々対応するトランザクションデータ２８のリストであるトランザクションデータリスト２８Ｌを作成する（Ｓ１７１２）。次に、パブリックサーバ２２は、作成したトランザクションデータリスト２８Ｌを、トランザクション参照依頼を行った利用者システム４０に送信する（Ｓ１７１４）。このとき、例えば、図１９に示されるトランザクションデータリスト２８Ｌが利用者システム４０に送信される。

その後、パブリックサーバ２２は、利用者システム４０からトランザクションデータ２８の夫々について、対応するマルチシグトランザクション８０Ｍの署名承認又は署名否認を受信する（Ｓ１７１６）。パブリックサーバ２２は、前述したように、署名承認されたマルチシグトランザクション８０Ｍに対応するエントリデータ２４を署名承認済みとし、署名否認されたマルチシグトランザクション８０Ｍに対応するエントリデータ２４を署名否認済みとする（Ｓ１７２０）。この結果、例えば、エントリデータ２４のステータス２４８は、図２０に示されるように更新される。

エントリデータ更新処理によれば、署名システム１０は、利用者システム４０が利用者システム４０の秘密鍵４４２（図７参照）によって署名して発行したマルチシグトランザクション８０Ｍを収集する際に、マルチシグトランザクション８０Ｍが収集条件を満たすか否かを判定する。収集条件は、前述したように、必要に応じて様々に設定すればよい。

署名システム１０は、収集条件を満たしたマルチシグトランザクション８０Ｍから作成したエントリデータ２４をエントリ２４Ｃに追加する。一方、署名システム１０は、収集条件を満たさないマルチシグトランザクション８０Ｍについて、例えば、不正なマルチシグトランザクション８０Ｍが発行されている旨の警告を、利用者システム４０に送信してもよい。利用者システム４０への警告により、不正なマルチシグトランザクション８０Ｍの承認を防止でき、これによりマルチシグトランザクション８０Ｍの信頼性を更に向上できる。但し、本発明は、これに限られず、収集条件による判定は、必要に応じて行えばよい。

図１５及び図１８を参照すると、プライベートシステム３０のプライベートサーバ３２は、例えば、所定の時間間隔で定期的に署名処理を行う。プライベートサーバ３２は、署名処理において、エントリ２４Ｃから、ステータス２４８（図２０参照）に「署名承認済み」を意味するデータが設定されているエントリデータ２４（署名承認済みのエントリデータ２４）を検索する（Ｓ１８０２）。プライベートサーバ３２は、署名承認済みのエントリデータ２４の夫々について、下記の処理を行う。

プライベートサーバ３２は、署名承認済みのエントリデータ２４に対応する未承認のマルチシグトランザクション８０Ｍ（即ち、署名承認対象のマルチシグトランザクション８０Ｍ）が所定の署名条件を満たすか否か判定する（Ｓ１８０４）。署名条件は、例えば、署名承認済みのエントリデータ２４が、対応する未承認のマルチシグトランザクション８０Ｍのデータと一致することである（Ｓ１８０４）。

詳しくは、プライベートサーバ３２は、ブロックチェーン７０から、署名承認対象のマルチシグトランザクション８０Ｍの取得を試みる。このマルチシグトランザクション８０Ｍが取得できない場合、プライベートサーバ３２は、署名条件が満たされていないと判定する。このマルチシグトランザクション８０Ｍが取得できた場合、プライベートサーバ３２は、エントリデータ２４のトランザクション発行日時２４２、送信先アドレス２４４及び送信額２４５（図２０参照）が取得したマルチシグトランザクション８０Ｍのデータと一致するか否か判定する。プライベートサーバ３２は、一致しない場合、署名条件が満たされていないと判定する。プライベートサーバ３２は、一致する場合、署名承認対象のマルチシグトランザクション８０Ｍが未だ承認されていないことを確認する。プライベートサーバ３２は、署名承認対象のマルチシグトランザクション８０Ｍが既に承認されている場合、署名条件が満たされていないと判定し、未だ承認されていない場合、署名条件が満たされていると判定する。

プライベートサーバ３２は、署名条件が満たされていないと判定したとき（Ｓ１８０４のＮＧ）、エントリデータ２４の利用者特定データ２４６（図２０参照）によって特定される利用者システム４０に警告を送信する（Ｓ１８０６）。

一方、プライベートサーバ３２は、署名条件が満たされていると判定したとき（Ｓ１８０４のＯＫ）、預かり秘密鍵３４から、署名承認済みのエントリデータ２４に対応する秘密鍵３４２を取得する（Ｓ１８０８）。次に、プライベートサーバ３２は、取得した秘密鍵３４２を使用して署名承認対象のマルチシグトランザクション８０Ｍに署名する（Ｓ１８１０）。次に、プライベートサーバ３２は、署名したマルチシグトランザクション８０Ｍを発行する（Ｓ１８１２）。

本実施の形態の署名処理によれば、署名システム１０は、利用者システム４０からトランザクションデータ２８に対応するマルチシグトランザクション８０Ｍに対する署名承認を受信すると、署名承認されたマルチシグトランザクション８０Ｍが所定の署名条件を満たすか否か判定し、署名条件を満たしたマルチシグトランザクション８０Ｍに対して秘密鍵３４２によって署名する。

署名条件は、必要に応じて様々に設定すればよい。例えば、署名条件のうちの１つは、エントリデータ２４が追加されてから署名が行われるまでの間に所定時間以上の時間が経過していないことであってもよい。署名システム１０は、署名条件を満たしたマルチシグトランザクション８０Ｍに署名する。一方、署名システム１０は、署名条件を満たさないマルチシグトランザクション８０Ｍについて、例えば、マルチシグトランザクション８０Ｍが改ざんされている旨の警告を、利用者システム４０に送信する。利用者システム４０への警告により、不正なマルチシグトランザクション８０Ｍの承認を防止でき、これによりマルチシグトランザクション８０Ｍの信頼性を更に向上できる。但し、本発明は、これに限られず、署名条件による判定は、必要に応じて行えばよい。

以下、利用者システム４０のシステム構成を説明すると共に、利用者システム４０が署名システム１０にログインする際の利用者システム４０の処理について、更に詳細に説明する。

図２１を参照すると、本実施の形態による利用者システム４０は、例えば、ＰＣやスマートフォン等の利用者端末４０である。利用者端末４０は、処理装置４２と、利用者秘密鍵４４が記憶された記憶装置と、入力装置４６と、表示装置４８とを備えている。処理装置４２は、ＣＰＵを含めた様々な電子部品から構成されている。入力装置４６は、例えば、ＰＣのキーボードやスマートフォンのタッチパネルである。表示装置４８は、例えば、ＰＣやスマートフォンの液晶ディスプレイである。但し、利用者システム４０のシステム構成はこれに限られず、様々に変形可能である。例えば、利用者システム４０は、複数のコンピュータからなるクライアントサーバシステムであってもよい。また、利用者システム４０は、必要に応じて利用者秘密鍵４４を有していればよい。

処理装置４２は、利用者秘密鍵４４が記憶された記憶装置に対して読み込み可能かつ書き込み可能に接続されている。例えば、処理装置４２は、ＣＰＵによって様々なプログラムを実行することで、入力装置４６から利用者（操作者）による入力情報を取得したり、利用者秘密鍵４４を参照したり、表示装置４８に表示情報を表示する等の様々な処理を行う。利用者端末４０は、通信回線によって、署名システム１０のパブリックシステム２０及び事業者システム５０の夫々と通信可能に接続されている。特に、利用者端末４０は、署名システム１０と通信可能である。また、本実施の形態の利用者端末４０は、通信回線を経由して、ブロックチェーン７０にマルチシグトランザクション８０Ｍを発行できる。但し、本発明は、これに限られない。例えば、利用者端末４０が利用者秘密鍵４４を有していない場合、利用者端末４０は、マルチシグトランザクション８０Ｍを発行できなくてもよい。

本実施の形態において、記憶装置に記憶されたプログラムを処理装置４２がローディングしてＣＰＵによって実行することで、利用者端末４０は、上述した様々な処理を行う。換言すれば、利用者端末４０の記憶装置は、コンピュータを利用者端末４０として機能させるためのプログラムを有している。以下、このプログラムによる利用者端末４０の処理について、フローチャートを使用して詳細に説明する。

図２１及び図２２を参照すると、利用者端末４０は、入力装置４６を使用した操作者のログイン操作により、署名システム１０（パブリックシステム２０）にログインデータを送信する（Ｓ２２０２）。ログインデータは、例えば、利用者端末４０の操作者のメールアドレスと認証データである。

利用者端末４０は、署名システム１０（パブリックシステム２０）からログインの許容又は拒否を受信し、これによりログインが成功したか否か判定する（Ｓ２２０４）。利用者端末４０は、ログインが成功しなかった場合（Ｓ２２０４のＮＯ）、処理を終了する（Ｓ２２０６）。

利用者端末４０は、ログインが成功した場合（Ｓ２２０４のＹＥＳ）、署名システム１０（パブリックシステム２０）にトランザクション参照依頼を送信する（Ｓ２２０８）。但し、ログインデータの送信がトランザクション参照依頼を兼ねていてもよい。即ち、利用者端末４０は、何らかの方法によって、署名システム１０にトランザクション参照依頼を送信すればよい。

次に、利用者端末４０は、署名システム１０（パブリックシステム２０）からトランザクションデータリスト２８Ｌを受信する（Ｓ２２１０）。利用者端末４０は、署名システム１０から受信したトランザクションデータリスト２８Ｌに基づく表示データを表示装置４８に表示する（Ｓ２２１２）。図２３を図１９と比較すると、トランザクションデータリスト２８Ｌのトランザクションデータ２８の夫々が表示装置４８に表示される。例えば、事業者識別データ２８４が設定されていないトランザクションデータ２８（図１９におけるトランザクションデータ１）について、事業者の名称に代えて「？」が表示される。

図２２及び図２３を参照すると、利用者端末４０の操作者は、入力装置４６のスワイプ等の操作により、表示装置４８に表示されたトランザクションデータ２８の夫々に対して、署名承認又は署名否認を入力する。利用者端末４０は、入力装置４６から入力された署名承認又は署名否認を署名システム１０に送信する（Ｓ２２１４）。

本実施の形態によれば、未承認のマルチシグトランザクション８０Ｍの内容を、マルチシグトランザクション８０Ｍに関連する利用者端末４０の表示装置４８に視覚的に表示する。従って、利用者端末４０の操作者は、未承認のマルチシグトランザクション８０Ｍが不正に発行されたものか否かを容易に確認できる。

本実施の形態は、既に説明した変形例に加えて、更に様々に変形可能である。例えば、図１５を参照すると、プライベートシステム３０は、マルチシグトランザクション８０Ｍを発行することなく、預かり秘密鍵３４の保管のみを行ってもよい。この場合、パブリックシステム２０は、必要に応じてプライベートシステム３０から必要な秘密鍵３４２及び公開鍵３４４を取得し、取得した秘密鍵３４２によって署名したマルチシグトランザクション８０Ｍを発行すればよい。

図２４を参照すると、変形例における利用者システム（利用者端末）４０は、トランザクション参照依頼及び署名承認を、図２に示されるように署名システム１０に対して直接的に行うのでなく、事業者システム５０を経由して、署名システム１０に対して間接的に行ってもよい。

本変形例において、利用者端末４０は、利用者端末４０の操作者（利用者）の操作に応じて、事業者システム５０に対して、マルチシグトランザクション８０Ｍの発行を依頼すると共に、二段階認証コードを送信する（図２２の（１）発行依頼ｗｉｔｈ二段階認証コード）。二段階認証コードは、例えば、利用者が、ワンタイムパスワード生成プログラム（図示せず）から取得したワンタイムパスワード（使い捨てパスワード）である。

本実施の形態において、図２２の（１）発行依頼ｗｉｔｈ二段階認証コードは、利用者が保有する利用者端末４０から事業者システム５０へのデータ通信によって行われる。但し、本発明は、これに限られない。例えば、利用者は、事業者である取引所に設置された端末（即ち、事業者システム５０の端末）を利用者端末（利用者システム）４０として操作してもよい。

事業者システム５０は、利用者が実際に仮想通貨を所有しているかといった検証を行った後、ＢｔｏＢｔｏＣサービスと同様に、マルチシグトランザクション８０Ｍを作成し、作成したマルチシグトランザクション８０Ｍに署名してマルチシグトランザクション８０Ｍを発行する（図２２の（２）署名＆発行）。

次に、事業者システム５０は、ＢｔｏＢｔｏＣサービスと同様に、発行したマルチシグトランザクション８０Ｍに対応するエントリデータ５６を作成する。次に、事業者システム５０は、署名システム１０に対して、作成したエントリデータ５６及び利用者端末４０から受信した二段階認証コードを付したエントリデータ追加依頼を送信し、これによりマルチシグトランザクション８０Ｍを発行したことを署名システム１０に通知する（図２２の（３）エントリデータ追加依頼ｗｉｔｈ二段階認証コード）。

署名システム１０は、受信した二段階認証コードを、例えば、ワンタイムパスワード生成プログラム（図示せず）が生成したはずのワンタイムパスワードと照合し、これにより、エントリデータ追加依頼が正当なものであるか否かを検証する。署名システム１０は、エントリデータ追加依頼が正当なものであると判断した場合、以下の処理を行う。一方、署名システム１０は、エントリデータ追加依頼が不当なものであると判断した場合、事業者システム５０に対して警告を送信し、受信したエントリデータ追加依頼についての処理を終了する。

署名システム１０は、エントリデータ追加依頼が正当なものであると判断した場合、ＢｔｏＢｔｏＣサービスと同様に、受信したエントリデータ５６に基づくエントリデータ２４をエントリ２４Ｃに追加する。次に、署名システム１０は、ブロックチェーン７０のトランザクション８０から、署名対象となるマルチシグトランザクション８０Ｍを収集する（図２２の（４）収集）。詳しくは、署名システム１０は、追加したエントリデータ２４のトランザクション特定データ２４０（図１１参照）によって特定される未承認のマルチシグトランザクション８０Ｍを、利用者に関連するマルチシグトランザクション８０Ｍとして収集する。

次に、署名システム１０は、収集したマルチシグトランザクション８０Ｍに対応するエントリデータ２４のステータス２４８（図１１参照）に「署名承認済み」を意味するデータを設定する。次に、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、署名承認されたマルチシグトランザクション８０Ｍに対して秘密鍵３４２によって署名して発行する（図２２の（５）署名＆発行）。

本変形例において、利用者端末４０から事業者システム５０へのマルチシグトランザクション８０Ｍの発行依頼は、利用者端末４０から署名システム１０へのトランザクション参照依頼をも意味する。署名システム１０は、事業者システム５０からエントリデータ追加依頼を受信することで、利用者端末４０からトランザクション参照依頼を検知する。署名システム１０は、事業者システム５０を経由して受信した利用者端末４０からのトランザクション参照依頼をトリガーとして、前述の処理を行う。

詳しくは、署名システム１０は、利用者端末４０からのトランザクション参照依頼をトリガーとして、事業者システム５０から、マルチシグトランザクション８０Ｍを特定可能なトランザクション特定データ５６０（図１０参照）を含むエントリデータ５６を受信する。署名システム１０は、マルチシグトランザクション８０Ｍの収集を行う際、受信したトランザクション特定データ５６０によって特定されるマルチシグトランザクション８０Ｍを収集する。即ち、署名システム１０は、ＢｔｏＢｔｏＣサービスと同様に、利用者端末４０からのトランザクション参照依頼をトリガーとして、秘密鍵３４２による署名が必要なマルチシグトランザクション８０Ｍを収集する。

また、署名システム１０は、事業者システム５０を経由して利用者端末４０から二段階認証コードを受信する。署名システム１０は、受信した二段階認証コードが正当なものである場合、利用者端末４０の利用者が署名承認したと判断して、マルチシグトランザクション８０Ｍに対して、署名システム１０の秘密鍵３４２によって署名する。即ち、本変形例によれば、署名システム１０は、利用者端末４０から、事業者システム５０を経由した二段階認証によって、収集したマルチシグトランザクション８０Ｍの署名承認を受信する。

本変形例によれば、マルチシグトランザクション８０Ｍは、発行依頼した利用者端末４０から送信された二段階認証コード（ワンタイムパスワード）による認証という手順を踏んで署名される。仮に、利用者端末４０から送信された二段階認証コードが漏洩した場合でも、漏洩した二段階認証コードを再度付したエントリデータ追加依頼が署名システム１０に対して送信されると、署名システム１０は、エントリデータ追加依頼が不当なものであると判断する。従って、事業者システム５０の秘密鍵５４２が漏洩した場合も、漏洩した秘密鍵５４２の不正な使用による被害を防止できる。本変形例によっても、マルチシグトランザクション８０Ｍの信頼性を向上可能な新たな署名システム１０を提供できる。

１０ 署名システム
２０ パブリックシステム
２２ パブリックサーバ
２４Ｃ エントリ
２４ エントリデータ
２４０ トランザクション特定データ
２４２ トランザクション発行日時
２４４ 送信先アドレス
２４５ 送信額
２４６ 利用者特定データ
２４８ ステータス
２６ 利用者情報
２６２ 利用者特定データ
２６４ 利用者認証データ
２８Ｌ トランザクションデータリスト
２８ トランザクションデータ
２８０ トランザクション特定データ
２８２ トランザクション発行日時
２８４ 事業者識別データ
２８６ 送信先アドレス
２８８ 送信額
３０ プライベートシステム
３２ プライベートサーバ
３４ 預かり秘密鍵
３４２ 秘密鍵
３４４ 公開鍵
４０ 利用者システム（利用者端末）
４２ 処理装置
４４ 利用者秘密鍵
４４２ 秘密鍵
４４４ 公開鍵
４４６ マルチシグアドレス
４６ 入力装置
４８ 表示装置
５０ 事業者システム
５４ 事業者秘密鍵
５４２ 秘密鍵
５４４ 公開鍵
５４６ マルチシグアドレス
５６ エントリデータ
５６０ トランザクション特定データ
５６２ トランザクション発行日時
５６４ 送信先アドレス
５６５ 送信額
５６６ 利用者特定データ
７０ ブロックチェーン
８０ トランザクション
８０Ｍ マルチシグトランザクション
８２ 送信側アドレス
８４ 送信先アドレス
８５ 送信額
８６ トランザクション発行日時
８８ 署名データ

Claims (10)

1. 事業者システムが秘密鍵によって署名して発行したマルチシグトランザクションに対して、前記秘密鍵に対応する他の秘密鍵によって署名する署名システムであって、
   利用者端末からのトランザクション参照依頼をトリガーとして、前記他の秘密鍵による署名が必要な前記マルチシグトランザクションを収集し、
   前記利用者端末から、前記収集した前記マルチシグトランザクションの署名承認を受信し、
   前記署名承認された前記マルチシグトランザクションに対して前記他の秘密鍵によって署名する
   署名システム。
2. 請求項１記載の署名システムであって、
   前記利用者端末から前記マルチシグトランザクションに対する前記署名承認を受信すると、前記署名承認された前記マルチシグトランザクションが所定の署名条件を満たすか否か判定し、前記署名条件を満たした前記マルチシグトランザクションに対して前記他の秘密鍵によって署名する
   署名システム。
3. 請求項１又は請求項２記載の署名システムであって、
   前記収集した前記マルチシグトランザクションに夫々対応するトランザクションデータのリストであるトランザクションデータリストを前記利用者端末に送信し、
   前記利用者端末から、前記トランザクションデータに対応する前記マルチシグトランザクションの前記署名承認を受信する
   署名システム。
4. 請求項３記載の署名システムであって、
   前記事業者システムから受信したエントリデータ追加依頼に夫々応じて作成した１以上のエントリデータを有しており、
   前記エントリデータは、前記マルチシグトランザクションと夫々対応しており、
   前記エントリデータの夫々には、対応する前記マルチシグトランザクションを特定可能なトランザクション特定データが含まれており、
   前記マルチシグトランザクションの前記収集を行う際、前記エントリデータの前記トランザクション特定データによって特定される前記マルチシグトランザクションを収集する
   署名システム。
5. 請求項４記載の署名システムであって、
   前記事業者システムから前記エントリデータ追加依頼を受信したとき、受信した前記エントリデータ追加依頼が所定のエントリデータ追加条件を満たすか否か判定し、前記エントリデータ追加条件を満たした場合に前記エントリデータを作成する
   署名システム。
6. 請求項３から請求項５までのいずれかに記載の署名システムであって、
   前記トランザクションデータリストにおける前記トランザクションデータには、対応する前記マルチシグトランザクションを発行した前記事業者システムを識別可能なデータが含まれている
   署名システム。
7. 請求項１記載の署名システムであって、
   前記利用者端末からの前記トランザクション参照依頼をトリガーとして、前記事業者システムから前記マルチシグトランザクションを特定可能なトランザクション特定データを受信し、
   前記マルチシグトランザクションの前記収集を行う際、前記受信した前記トランザクション特定データによって特定される前記マルチシグトランザクションを収集し、
   前記利用者端末から、前記事業者システムを経由した二段階認証によって、前記収集した前記マルチシグトランザクションの前記署名承認を受信する
   署名システム。
8. 請求項１から請求項７までのいずれかに記載の署名システムであって、
   パブリックシステムと、プライベートシステムとを備えており、
   前記パブリックシステムは、前記マルチシグトランザクションの前記収集と、前記マルチシグトランザクションの前記署名承認の前記受信とを行い、
   前記プライベートシステムは、前記マルチシグトランザクションの前記署名を行う
   署名システム。
9. 請求項３から請求項６までのいずれかに記載の署名システムと通信可能な利用者端末であって、
   表示装置を備えており、
   前記署名システムに前記トランザクション参照依頼を送信し、
   前記署名システムから受信した前記トランザクションデータリストに基づく表示データを前記表示装置に表示する
   利用者端末。
10. コンピュータを、請求項９記載の利用者端末として機能させるためのプログラム。

Images