(57)【特許請求の範囲】
【請求項１】
コンピュータを、
ユーザの識別子と、当該ユーザの公開鍵との対応関係を示し、前記公開鍵の更新を許可する管理ユーザの公開鍵を含むマッピング情報を記憶する記憶手段、
仮想通貨を第１のユーザに送金する第１の取引における、前記第１のユーザの識別子を含む第１の取引情報と、前記第１の取引により送金された金額の少なくとも一部を前記第１のユーザが送金する第２の取引における、前記第１のユーザの第１の公開鍵及び第１の電子署名を含む第２の取引情報とを記憶する記憶手段、及び
前記第２の取引情報に含まれる前記第１の公開鍵が、前記マッピング情報において、前記第１の取引情報に含まれる前記第１のユーザの識別子に対応付けられているか否か、及び、前記第２の取引情報に含まれる前記第１の公開鍵で前記第２の取引情報に含まれる前記第１の電子署名を検証できるか否かに基づいて、前記第２の取引の正当性を検証する検証手段、
第２のユーザの識別子、第２の公開鍵、及び第２の電子署名を含む更新情報を記憶する記憶手段、及び
前記マッピング情報において、前記更新情報に含まれる前記第２のユーザの識別子に対応付けられた前記管理ユーザの第３の公開鍵で、前記更新情報に含まれる前記第２の電子署名を検証可能な場合、前記マッピング情報において前記第２のユーザの識別子に対応付けられた前記第２のユーザの第４の公開鍵を、前記更新情報に含まれる前記第２の公開鍵に更新する更新手段、
として機能させる仮想通貨管理プログラム。
【請求項２】
前記マッピング情報は、前記第２のユーザの識別子に対応付けられた公開鍵として、第４及び第５の公開鍵を含み、
前記更新情報は、さらに、前記第５の公開鍵を含み、
前記更新手段は、
前記マッピング情報において、前記第２の電子署名を前記第３の公開鍵または前記第５の公開鍵で検証可能な場合、前記第２のユーザの識別子に対応付けられた公開鍵を、前記第４及び第５の公開鍵から、前記第２及び第５の公開鍵に更新する、請求項１に記載の仮想通貨管理プログラム。
【請求項３】
コンピュータが、
ユーザの識別子と、当該ユーザの公開鍵との対応関係を示し、前記公開鍵の更新を許可する管理ユーザの公開鍵を含むマッピング情報を記憶するステップと、
仮想通貨を第１のユーザに送金する第１の取引における、前記第１のユーザの識別子を含む第１の取引情報と、前記第１の取引により送金された金額の少なくとも一部を前記第１のユーザが送金する第２の取引における、前記第１のユーザの第１の公開鍵及び第１の電子署名を含む第２の取引情報とを記憶するステップと、
前記第２の取引情報に含まれる前記第１の公開鍵が、前記マッピング情報において、前記第１の取引情報に含まれる前記第１のユーザの識別子に対応付けられているか否か、及び、前記第２の取引情報に含まれる前記第１の公開鍵で前記第２の取引情報に含まれる前記第１の電子署名を検証できるか否かに基づいて、前記第２の取引の正当性を検証するステップと、
第２のユーザの識別子、第２の公開鍵、及び第２の電子署名を含む更新情報を記憶するステップ、及び
前記マッピング情報において、前記更新情報に含まれる前記第２のユーザの識別子に対応付けられた前記管理ユーザの第３の公開鍵で、前記更新情報に含まれる前記第２の電子署名を検証可能な場合、前記マッピング情報において前記第２のユーザの識別子に対応付けられた前記第２のユーザの第４の公開鍵を、前記更新情報に含まれる前記第２の公開鍵に更新するステップ、
を実行する仮想通貨管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想通貨管理プログラム、及び仮想通貨管理方法等に関する。
【背景技術】
【０００２】
近年、円やドルといった現実の貨幣による物品の取引だけでなく、電子マネー等の仮想通貨を用いた商取引が行われている。非特許文献１には、ビットコインと呼ばれる仮想通貨を用いて取引を行う技術について開示されている。
ビットコインによる取引では、ハッシュ関数と公開鍵暗号方式とを用いて、取引データの完全性が担保されている。暗号化を用いて行われた取引（以下、ビットコインの取引を「トランザクション」とも呼ぶ。）は、ビットコインを利用する全端末に対してブロードキャストで配信される。配信されたトランザクションは、マイナー（発掘者）と呼ばれる端末ソフトウェアによって正当性が検証され、発掘されたブロックにまとめられ、ブロックチェーンと呼ばれる台帳に記録され、それが他のマイナーたちにより追認されることで承認される。
【０００３】
非特許文献１には、公開鍵を用いてビットコインのコインの所有者を識別する方法について開示されている。非特許文献１に記載の方法によれば、コインの現在の所有者は、相手にコインを支払う際、現在のコイン（自分に宛てられたコインのデータ）と相手の公開鍵を合わせたデータに対して、ハッシュ関数を適用し、自分の秘密鍵を用いて署名を施す。コインを受け取った相手は、その一つ手前の取引におけるコインの受け手の公開鍵を用いて署名を検証すると共に、ハッシュ値を再計算することで、コインが正当な所有者から自分宛てに渡されたことを確認することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】斉藤賢爾著、「これでわかった  ビットコイン  [生き残る通貨の条件]」、初版、太郎次郎社エディタス、２０１４年５月５日、ｐ．９２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載の方法の場合、ビットコインのシステム内では、ユーザは公開鍵によって識別され、秘密鍵によってコインの所有者であることを証明する。そのため、たとえばユーザが秘密鍵を紛失してしまった場合、そのユーザは、自分が鍵を紛失する前のユーザと同一ユーザであることを証明できなくなってしまう。その結果、そのユーザはこれまで所有していたコインを利用することができなくなってしまう。
【０００６】
そこで、本発明は、上記事情に鑑み、鍵ペアを更新後も、更新前に利用していた仮想通貨を継続して利用可能とするための、仮想通貨管理プログラム、及び仮想通貨管理方法を提供することを目的とするものである。
【課題を解決するための手段】
【０００７】
本発明による仮想通貨管理プログラムは、コンピュータを、ユーザの識別子と、当該ユーザの公開鍵との対応関係を示すマッピング情報を記憶する記憶手段、仮想通貨を第１のユーザに送金する第１の取引における、第１のユーザの識別子を含む第１の取引情報と、第１の取引により送金された金額の少なくとも一部を第１のユーザが送金する第２の取引における、第１のユーザの第１の公開鍵及び第１の電子署名を含む第２の取引情報とを記憶する記憶手段、及び第２の取引情報に含まれる第１の公開鍵が、マッピング情報において、第１の取引情報に含まれる第１のユーザの識別子に対応付けられているか否か、及び、第２の取引情報に含まれる第１の公開鍵で第２の取引情報に含まれる第１の電子署名を検証できるか否かに基づいて、第２の取引の正当性を検証する検証手段として機能させるものを含む。
【０００８】
また、本発明による仮想通貨管理方法は、コンピュータが、ユーザの識別子と、当該ユーザの公開鍵との対応関係を示すマッピング情報を記憶するステップと、仮想通貨を第１のユーザに送金する第１の取引における、第１のユーザの識別子を含む第１の取引情報と、第１の取引により送金された金額の少なくとも一部を第１のユーザが送金する第２の取引における、第１のユーザの第１の公開鍵及び第１の電子署名を含む第２の取引情報とを記憶するステップと、第２の取引情報に含まれる第１の公開鍵が、マッピング情報において、第１の取引情報に含まれる第１のユーザの識別子に対応付けられているか否か、及び、第２の取引情報に含まれる第１の公開鍵で第２の取引情報に含まれる第１の電子署名を検証できるか否かに基づいて、第２の取引の正当性を検証するステップと、を実行する方法を含む。
【０００９】
本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【００１０】
また、本明細書等において、「部」とは、単に物理的構成を意味するものではなく、その構成が有する機能をソフトウェアによって実現する場合も含む。また、１つの構成が有する機能が２つ以上の物理的構成により実現されても、２つ以上の構成の機能が１つの物理的構成により実現されてもよい。
【発明の効果】
【００１１】
本発明によれば、鍵ペアを更新後も、更新前に利用していた仮想通貨を継続して利用可能とするための、仮想通貨管理プログラム、及び仮想通貨管理方法を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態における仮想通貨システムの構成図である。
【図２】本発明の実施形態における端末の機能ブロックの一例を示す図である。
【図３】本発明の実施形態におけるマッピング情報の構造の一例を示す図である。
【図４】本発明の実施形態における仮想通貨の、経過時間と減価額との対応関係の一例を示す図である。
【図５】本発明の実施形態における送金トランザクションの一例を示す図である。
【図６】本発明の実施形態におけるマップトランザクションの一例を示す図である。
【図７】本発明の実施形態におけるＩＤ認証処理の流れの一例を示す図である。
【図８】本発明の実施形態における更新許可処理の流れの一例を示す図である。
【図９】本発明の実施形態におけるマイニング処理の流れの一例を示す図である。
【図１０】本発明の実施形態における端末のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１３】
［第１の実施形態］
以下、本発明の実施の形態の１つについて詳細に説明する。なお、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。またさらに、必要に応じて示す上下左右等の位置関係は、特に断らない限り、図示の表示に基づくものとする。さらにまた、図面における各種の寸法比率は、その図示の比率に限定されるものではない。
【００１４】
＜１．システム構成の概要＞
図１は、仮想通貨システム１０の構成の一例を示している。図１に示すように、仮想通貨システム１０は、本発明に係る仮想通貨管理プログラムをインストールした、複数のクライアント装置同士が互いに通信を行う、Ｐ２Ｐの構成となっている。図１の例では、仮想通貨を用いて取引を行うユーザのクライアント端末を端末１００Ａ〜Ｃ（以下、端末１００Ａ〜Ｃをまとめて「端末１００」とも呼ぶ。）、送金トランザクションの検証や承認を行うユーザのクライアント端末を端末２００Ａ〜Ｃ（以下、端末２００Ａ〜Ｃをまとめて「端末２００」とも呼ぶ。）として説明する。
【００１５】
端末１００及び端末２００は、インターネットや専用線等のネットワーク４００に接続されたコンピュータである。具体的には、携帯電話やスマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）、タブレット、ウェアラブル（Ｗｅａｒａｂｌｅ）端末等が挙げられるが、これに限られない。ネットワーク４００に有線又は無線で接続された装置１００及び２００が、互いに通信可能に設定されることにより、仮想通貨システム１０を構成する。なお、本実施形態において、仮想通貨システム１０は、Ｐ２Ｐ型のシステムであるとして説明するが、これに限定されるものではない。例えば、仮想通貨システム１０は、クラウドコンピューティング形式のシステムとして構成されてもよい。この場合、ユーザは、仮想通貨システム１０のコンピュータ処理をネットワーク経由でサービスとして利用する。また、仮想通貨システム１０は、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）のサーバを含むシステムとして構成されてもよい。
【００１６】
＜２．仮想通貨の概要＞
まず、仮想通貨システム１０によって提供される仮想通貨（以下、仮想通貨システム１０によって提供される仮想通貨を「オーブ」とも呼ぶ。）の概要について説明する。オーブは既存のビットコインと同様に、インターネットを用いたＰ２Ｐデジタル通貨であり、公開鍵暗号方式とハッシュ関数を用いたデジタル署名によって取引情報の完全性が担保されている。また、オーブの取引に関する情報や履歴は、仮想通貨システム１０全体で分散して管理される。なお、本実施形態においてオーブは最小単位が「１Ｏｒｂ」である通貨として説明する。
【００１７】
オーブを利用するユーザは、まず仮想通貨管理プログラムをインストールする必要がある。仮想通貨管理プログラムには、ウォレットツールとマイニングツールとが含まれていることが望ましい。ウォレットツールは、オーブの購入やオーブを用いた取引を行うために必要なツールをいう。一方で、マイニングツールは、オーブを用いた取引の完全性や整合性を検証し、取引を承認するために必要なツールをいう。
【００１８】
ウォレットツールをクライアント端末にインストールしたユーザは、ネットワーク４００に一意なＩＤを生成する必要がある。ＩＤは、たとえば、ユーザのメールアドレスと任意の単語とを組み合わせた文字列のハッシュ値である。生成したＩＤは、オーブの購入や送金に利用する公開鍵と紐づけられ、後述するマッピング情報と呼ばれる構造体で管理される。マッピング情報の生成や更新に関するデータ（以下、マッピング情報の生成や更新に関するデータを「マップトランザクション」とも呼ぶ。）は、ネットワーク４００全体で共有される。
【００１９】
マッピング情報を生成したユーザは、オーブを購入することができるようになる。「オーブを購入する」とは、仮想通貨システム１０に新たなオーブを発生させることをいう。具体的には、ユーザによって、任意の金額の現実の通貨からオーブへと換金されることを指す。
【００２０】
さらにユーザは、購入したオーブを他のユーザに送金することができる。「オーブを送金する」とは、元の所有者から新たな所有者へとオーブの受け渡しが行われることをいう。
【００２１】
オーブの購入や送金に関するデータ（以下、オーブの購入や送金に関するデータを「送金トランザクション」とも呼ぶ。特に、オーブの購入に関するデータを「通貨発生トランザクション」とも呼ぶ。）は、後述するブロックチェーンと呼ばれる構造体によって管理される。ブロックチェーンは、ブロックと呼ばれるデータが時系列に並べられたものであり、オーブの送金を記した台帳としての役割を有している。マイニングツールをウォレットツールに加えてクライアント端末にインストールしたユーザ（以下、ウォレットツールのみをインストールしたユーザを単に「ユーザ」と呼び、ウォレットツールとマイニングツールとをインストールしたユーザを「マイナー」と呼ぶ。）は、送金トランザクションの正当性を検証し、正当な送金トランザクションを承認することができる。さらにマイナーは、承認済みの送金トランザクションから構成されるブロックを生成（以下、ブロックを生成することを「ブロックを発掘する」とも呼ぶ。）して、ブロックチェーンにつなぐことができる。
【００２２】
なお、オーブは、購入時から時間の経過とともに、減価するように構成されている。そのため、オーブを購入したユーザは、オーブが減価によって消滅してしまう前に消費する必要がある。オーブが減価するように構成されることで、ユーザは投資の対象とせず、結果として、オーブの価値を安定させることが可能になる。
【００２３】
＜３．機能構成＞
次に、図２を用いて、本実施形態に係る仮想通貨管理プログラムをインストールした端末１００及び２００の機能構成について説明する。
＜３−１．ウォレットツールの機能＞
図２（Ａ）は、ウォレットツールをインストールした、端末１００の機能ブロック図の一例を示す図である。ウォレットツールをインストールした端末１００には、送金トランザクションＤＢ１３１と、ブロック情報ＤＢ１３２と、マッピング情報ＤＢ１３３と、口座情報ＤＢ１３４と、マップトランザクション情報ＤＢ１３５と、送金受付部１０１と、インプットデータ作成部１０２と、アウトプットデータ作成部１０３と、送金トランザクション配信部１０４と、マッピング部１０５とが構築されることが望ましい。
【００２４】
送金トランザクション情報ＤＢ１３１には、端末１００又は２００がネットワーク４００にブロードキャストで配信した送金トランザクションの履歴が保存されている。１つの送金トランザクションには、通常、インプットデータ、アウトプットデータ、送金トランザクションが発生した時刻、送金トランザクションが後述するブロックチェーンに追加された時刻が含まれることが望ましい。なお、オーブの購入時に配信される通貨発生トランザクションには、インプットデータは含まれないとしてもよい。
【００２５】
送金トランザクションのアウトプットデータには、送金されるオーブの金額と、送金先のユーザＩＤとが含まれていることが望ましい。
【００２６】
送金トランザクションのインプットデータには、今回送金するオーブを送金元ユーザが受け取った送金トランザクションのアウトプットデータへのポインタと、後述する電子署名作成処理によって作成される送金元ユーザの電子署名と、送金元ユーザの公開鍵とが含まれていることが望ましい。
【００２７】
オーブを用いた取引では、過去に受け取った、又は購入したオーブを送金対象として指定し、別のユーザへと送金する。そのため、送金を行う際には、過去の送金トランザクションから、送金元ユーザが送金先ユーザとなったアウトプットデータを今回の送金対象として指定する必要がある。このように、オーブの送金トランザクションは、インプットデータが１つ前のアウトプットデータへのポインタを有する構造をしている。その結果、すべての送金トランザクションは、通貨発生トランザクションまでポインタを介して数珠つなぎとなるデータ構造となっている。
【００２８】
ブロック情報ＤＢ１３２には、生成されたブロックに関する情報が保存されている。ブロックには、マイナーが正当性を検証して承認した複数の送金トランザクションやマップトランザクションが格納されている。オーブの購入や送金、マッピング情報の生成や更新は、ブロックチェーンと呼ばれる構造体によって管理されている。ブロックチェーンは、ブロックと呼ばれるデータが時系列に並べられたものをいう。ブロックチェーンは仮想通貨システム１０の全端末が共有するが、ユーザはブロックチェーンのうち自己が関心をもつ部分のみを所持していればよい。マイナーはブロックチェーンの全体を所持していることが望ましい。
ブロックには、１つ前のブロックのハッシュ値、及び複数の送金トランザクションが含まれている。
【００２９】
マッピング情報ＤＢ１３３には、ウォレットツールをインストールした全ユーザのマッピング情報が保存されている。図３は、マップトランザクションによって生成、更新されるマッピング情報の構造の一例を示す概念図である。図３に示すように、マッピング情報は、ＩＤと、公開鍵と、公開鍵のスペア（以下、公開鍵のスペアを「スペアキー」とも呼ぶ。）と、複数の管理ユーザのＩＤが紐づけられた構造となっている。
【００３０】
ＩＤは、ウォレットツールをインストールした際に、ユーザが作成した、ネットワーク４００において一意な識別子である。
管理ユーザは、そのＩＤに紐づけられた公開鍵の更新を許可されたユーザである。管理ユーザはたとえば、公開鍵の所有者と、自治体や企業等のオーブの発行元と、オーブの製造者との３人である。なお、管理ユーザは、公開鍵の所有者が任意に設定できるとしてもよい。また、管理ユーザは２人以上であることが望ましいがこれに限定されない。
図３の例ではスペアキーは１つしか登録されていないが、これに限定されず、複数のスペアキーが登録されていてもよい。さらに、スペアキーが登録されていない構成であってもよい。
なお、管理ユーザのマッピング情報も、マッピング情報ＤＢ１３３に記憶されている。
【００３１】
口座情報ＤＢ１３４には、端末１００を利用するユーザの秘密鍵が保存されている。
【００３２】
マップトランザクション情報ＤＢ１３５には、端末１００又は２００がネットワーク４００にブロードキャストで配信したマップトランザクションの履歴が保存されている。１つのマップトランザクションには、通常、インプットデータ、及びアウトプットデータが含まれることが望ましい。マップトランザクションは、ユーザがＩＤを作成する場合（以下、ユーザがＩＤを作成する場合に配信されるマップトランザクションを特に「ＩＤ発生トランザクション」とも呼ぶ。）や、ユーザが古い鍵ペア（以下、更新される古い鍵ペアを「旧鍵ペア」と呼び、このうち古い公開鍵を「旧鍵」とも呼ぶ。）から新しい鍵ペア（以下、新しい鍵ペアを「新鍵ペア」と呼び、このうち新しい公開鍵を「新鍵」とも呼ぶ。）へと鍵ペアの更新を行う場合に配信されるトランザクションである。
【００３３】
マップトランザクションのアウトプットデータには、新鍵がユーザのＩＤに対応付けられた新たなマッピング情報（以下、新しいマッピング情報を「新マッピング」とも呼ぶ。また、更新される古いマッピング情報を「旧マッピング」とも呼ぶ。）が格納されていることが望ましい。
【００３４】
マップトランザクションのインプットデータには、ポインタと、所定の人数の管理ユーザの電子署名と公開鍵とが含まれていることが望ましい。ポインタは、今回更新される旧鍵を公開鍵に指定して、ユーザが過去にマッピング情報を更新または生成した、マップトランザクションのアウトプットデータを指し示すものである。
また、所定の人数の管理ユーザは、更新対象となるマッピング情報で指定されている複数の管理ユーザの少なくとも一部の人数の管理ユーザである。具体的には、旧マッピングでユーザがスペアキーとして登録した鍵を、新マッピングで公開鍵として指定する場合には、インプットデータには、管理ユーザの電子署名として、公開鍵の所有者の電子署名のみが含まれる。一方で、旧マッピングに登録されていない新たな鍵を新鍵として登録する場合には、たとえば３人の管理ユーザのうち、２人以上の電子署名が必要となる。
【００３５】
マップトランザクションも送金トランザクションと同様に、インプットデータが１つ前のアウトプットデータへのポインタを有する構造をしている。その結果、すべてのマップトランザクションも、ＩＤ発生トランザクションまでポインタを介して数珠つなぎとなるデータ構造となっている。なお、ＩＤ発生トランザクションには、インプットデータは含まれないことが望ましい。
【００３６】
図１に戻り、ウォレットツールをインストールした端末１００の各構成の続きを説明する。
送金受付部１０１は、ユーザから送金先のユーザと送金する金額との指定を受け付ける。送金受付部１０１は、送金受付画面を端末１００のディスプレイに提示することが望ましい。また、送金受付部１０１は通貨購入画面をディスプレイに提示して、ユーザからオーブの購入を受け付けてもよい。
【００３７】
インプットデータ作成部１０２は、送金受付部１０１が受け付けた送金金額に応じて送金トランザクションのインプットデータを作成する。インプットデータ作成部１０２は、インプットデータを作成するために、以下の４つの処理を行う。
・送金対象検索処理
・減価額計算処理
・ポインタ指定処理
・電子署名作成処理
【００３８】
（送金対象検索処理）
インプットデータ作成部１０２は、送金対象検索処理として、まず、送金対象として用いることができるアウトプットデータを有する送金トランザクションを送金トランザクション情報ＤＢ１３１から検索することができる。たとえば、インプットデータ作成部１０２は、送金トランザクション情報ＤＢ１３１から、送金元ユーザのＩＤが、送金先ＩＤとして指定されているアウトプットを有する送金トランザクションであって、他の送金トランザクションのインプットデータのポインタとして指定されていないアウトプットデータを有する送金トランザクションを抽出することが望ましい。
【００３９】
（減価額計算処理）
次に、インプットデータ作成部１０２は、抽出した送金トランザクションのアウトプットデータに含まれる送金金額を参照し、現在までに減額した金額（減価額）を計算する。まず、インプットデータ作成部１０２は、抽出した送金トランザクションのインプットデータに含まれるポインタを順次参照していき、通貨発生トランザクションを抽出する。そして、インプットデータ作成部１０２は、通貨発生トランザクションのトランザクション発生時刻を参照し、現在時刻との差分に基づいて減価率を計算する。
【００４０】
図４は、時間の経過とオーブの残高率との対応関係の一例を示す図である。図４の例では、オーブが購入されてから１０日経過するごとに現在の金額から１０％減価する様子を示している。オーブの減価率が図４の表のように定義されている場合には、インプットデータ作成部１０２は、たとえば購入から２２日経過したオーブに対しては、現在の残高は購入時の残高の８１％であり、減価率は１９％であると算出する。なお、オーブの減価の態様は図４の例に限定されず、たとえば、時間の経過ごとに一定金額が減額されるとしてもよいし、時間の経過につれて減価率が変化してもよい。
インプットデータ作成部１０２は、抽出した送金トランザクションのアウトプットデータの金額と計算した現在の減価率を用いて、当該金額の減価額を計算することができる。
【００４１】
（ポインタ指定処理）
次に、インプットデータ作成部１０２は、送金受付部１０１が受け付けた送金金額に基づいて、抽出した送金トランザクションの中から、ポインタを指定するのに適したアウトプットデータを選択する。具体的には、インプットデータ作成部１０２は、抽出したアウトプットデータの金額と、計算した減価率とに基づいて、各アウトプットデータの残高を計算する。そして、計算した残高が、送金受付部１０１が受け付けた送金金額を上回っているアウトプットデータへのポインタを、今回のインプットデータとして指定することができる。
なお、計算した残高が、送金受付部１０１が受け付けた送金金額を上回っているアウトプットデータが存在しない場合には、本実施形態では、インプットデータ作成部１０２は、送金金額をいくつかの金額へ分割したうえで、再度、計算した残高が分割した金額を上回っているアウトプットデータを検索することが望ましい。なお、これに限定されず、今回の送金金額よりも大きな金額のアウトプットデータを有する送金トランザクションが存在しない場合には、インプットデータ作成部１０２は、複数のアウトプットデータのポインタを指定するために複数のインプットデータを作成するとしてもよい。
【００４２】
インプットデータ作成部１０２は、送金受付部１０１が複数のユーザへの送金を受け付けた場合には、受け付けた送金金額の合計金額に基づいてポインタを選択することが望ましい。
【００４３】
（電子署名作成処理）
さらに、インプットデータ作成部１０２は、送金元ユーザの電子署名を作成する。たとえば、インプットデータ作成部１０２は、電子署名を格納する部分を除く、作成中の送金トランザクションのデータ全体から、ハッシュ関数を使ってダイジェストを生成する。そして、インプットデータ作成部１０２は、生成したダイジェストを送金元ユーザの秘密鍵で暗号化することで電子署名を作成することができる。
【００４４】
インプットデータ作成部１０２は、ポインタ指定処理において指定したポインタと、電子署名作成処理において作成した電子署名と、さらに送金元ユーザの公開鍵とを格納して、インプットデータを作成することができる。
【００４５】
図２（Ａ）に戻り、各機能ブロックの機能の続きについて説明する。
アウトプットデータ作成部１０３は、送金受付部１０１が受け付けた、送金先のユーザと送金する金額とに基づいて、送金トランザクションのアウトプットデータを作成する。たとえば、アウトプットデータ作成部１０３は、マッピング情報ＤＢ１３３を参照して、送信先ユーザのＩＤをアウトプットデータに指定することができる。
また、アウトプットデータ作成部１０３は、インプットデータ作成部１０２がポインタを指定したアウトプットデータの残高から、今回の送金金額の合計金額を減算し、差額を、送金元ユーザ宛の送金としてアウトプットデータを作成することが望ましい。
【００４６】
なお、アウトプットデータ作成部１０３は、送金受付部１０１が、ユーザからオーブの購入を受け付けた場合には、オーブの購入を入力したユーザを送金先ユーザとして、アウトプットデータを作成することが望ましい。
【００４７】
送金トランザクション配信部１０４は、今回の送金に関する送金トランザクションを作成し、ネットワーク４００へと配信する。送金トランザクション配信部１０４は、以下の２種類の送金トランザクションを作成する処理を行う。
・通常トランザクション（以下、通常トランザクションのことを単に「送金トランザクション」とも呼ぶ。）
・通貨発生トランザクション
【００４８】
（通常トランザクション）
通常トランザクションは、オーブの送金が行われた場合に、送金トランザクション配信部１０４が配信する送金トランザクションをいう。通常トランザクションには、インプットデータと、アウトプットデータと、送金トランザクションが発生した時刻と、送金トランザクションがブロックチェーンに追加された時刻とが含まれる。
送金トランザクション配信部１０４は、インプットデータ作成部１０２が作成したインプットデータと、アウトプットデータ作成部１０３が作成したアウトプットデータと、を通常トランザクションに格納し、さらに現在時刻をトランザクション発生時刻に指定して、通常トランザクションをネットワーク４００へブロードキャストで配信することができる。
【００４９】
（通貨発生トランザクション）
通貨発生トランザクションは、オーブが購入された場合に送金トランザクション配信部１０４が配信する送金トランザクションをいう。すべての送金トランザクションは、インプットデータのポインタを参照していくと通貨発生トランザクションに収束する。
通貨発生トランザクションには、インプットデータは含まれないことが望ましい。送金トランザクション配信部１０４は、アウトプットデータ作成部１０３が作成した、オーブの購入を入力したユーザを送金先ユーザとするアウトプットデータを通貨発生トランザクションに格納し、さらに現在時刻をトランザクション発生時刻に指定して、通貨発生トランザクションをネットワーク４００にブロードキャストで配信することができる。
【００５０】
マッピング部１０５は、マッピング情報の生成や更新をユーザから受け付け、マップトランザクションをブロードキャストでネットワーク４００に配信する。マッピング部１０５は、以下の処理を行うように構成される。
・発行受付処理
・ポインタ指定処理
・管理ユーザ指定処理
・配信処理
【００５１】
（発行受付処理）
マッピング部１０５は、発行受付処理として、ＩＤ発行情報の入力を受け付ける。ＩＤ発行情報は、たとえば、ユーザが新たに利用する鍵ペアのうちの公開鍵と、当該公開鍵を利用するユーザとして紐づけるユーザのＩＤである。マッピング部１０５は、ユーザから直接ＩＤの指定を受け付けてもよいし、メールアドレスや任意の文字列の入力を受け付けてもよい。マッピング部１０５は、メールアドレスや任意の文字列の入力を受け付けた場合には、受け付けたメールアドレスや任意の文字列からハッシュ値を生成しＩＤとすることができる。マッピング部１０５は、端末１００のディスプレイに発行受付画面を提示して、公開鍵の登録を受け付けることができる。マッピング部１０５は、このとき、スペアキーの登録も合わせて受け付けることも可能である。
ＩＤ発生トランザクションにおいて、マッピング部１０５は、ＩＤ発行情報と合わせて、管理ユーザ情報を受け付けてもよい。管理ユーザ情報は、管理ユーザとして登録するユーザのＩＤである。なお、管理ユーザ情報は、システムの管理者によって決定され、ユーザが自由に決定できないものとしてもよい。
【００５２】
（ポインタ指定処理）
マッピング部１０５は、ポインタ指定処理として、マップトランザクションのインプットデータに格納するポインタを指定する。マッピング部１０５は、まず、マッピング情報ＤＢ１３３を参照して、発行受付処理において受け付けたユーザのＩＤに対応する公開鍵（旧鍵）を特定する。次に、マッピング部１０５は、特定した旧鍵がアウトプットデータとして指定されているマップトランザクションを抽出する。マッピング部１０５は、抽出したマップトランザクションから、他のインプットデータからポインタとして参照されていないアウトプットデータを有するマップトランザクションを選択する。そして、マッピング部１０５は、選択したマップトランザクションのアウトプットデータへのポインタを、今回のインプットデータとして指定する。
【００５３】
（電子署名作成処理）
マッピング部１０５は、電子署名作成処理として、マッピング情報に登録された管理ユーザの電子署名を取得する。具体的には、電子署名を格納する部分を除く、作成中のマップトランザクションのデータ全体にハッシュ関数を用いてダイジェストを作成する。そして、作成したダイジェストに対して、管理ユーザの秘密鍵を用いて暗号化することで電子署名を作成する。
【００５４】
（配信処理）
マッピング部１０５は、配信処理として、インプットデータとアウトプットデータとを格納したマップトランザクションを、ネットワーク４００にブロードキャストで配信する。マッピング部１０５は、ＩＤ発生トランザクションの場合とそれ以外のマップトランザクションの場合とで、それぞれ以下の処理を行う。
【００５５】
・ＩＤ発生トランザクションの場合
マッピング部１０５は、発行受付処理を行った後に配信処理を行う。マッピング部１０５は、発行受付処理において受け付けたＩＤ発行情報と管理ユーザ情報とに基づいてマッピング情報を作成し、アウトプットデータに格納する。ＩＤ発生トランザクションにおいては、マップトランザクションはインプットデータを有していない。そのため、マッピング部１０５は、アウトプットデータのみを格納し、ＩＤ発生トランザクションをネットワーク４００にブロードキャストで配信する。
【００５６】
・ＩＤ発生トランザクション以外のマップトランザクションの場合
マッピング部１０５は、発行受付処理とポインタ指定処理と電子署名作成処理を行った後に、配信処理を行う。まず、マッピング部１０５は、アウトプットデータを作成するために、マッピング情報ＤＢ１３３を参照して、発行受付処理において受け付けたＩＤに対応するマッピング情報を抽出する。マッピング部１０５は、抽出したマッピング情報の公開鍵（旧鍵）を新鍵に更新し、アウトプットデータに格納する。なお、この場合、マッピング部１０５は、アウトプットデータに格納する新マッピングから、旧鍵を除外することが望ましい。
次に、マッピング部１０５は、インプットデータに、ポインタ指定処理において指定したポインタと、電子署名作成処理において作成した電子署名と当該電子署名に対応する公開鍵とを、格納する。
マッピング部１０５は、作成したインプットデータとアウトプットデータとを格納したマップトランザクションを、ネットワーク４００にブロードキャストで配信する。
【００５７】
＜３−２．オーブ送金処理フロー＞
次に図５を用いて、ユーザＡがユーザＢへオーブを送金する際の処理フローについて説明する。図５は、ユーザＡが端末１００Ａを用いて、購入したオーブをユーザＢへ送金する場合の送金トランザクションを模式的に示した図である。
この例では、オーブの送金元ユーザであるユーザＡが利用する端末を端末１００Ａ、オーブの送金先ユーザであるユーザＢが利用する端末をそれぞれ端末１００Ｂとして説明する。また、図５の例においても、経過時間とオーブの減価率とは図４に示した対応関係にあるとして説明する。
【００５８】
図５において、ブロックＢ０２は、ブロックチェーンの末尾のブロックであり、ブロックＢ０１はブロックＢ０２の１つ前のブロックであるとする。また、送金トランザクションＴ１１は通貨発生トランザクションであり、送金トランザクションＴ１２は、ユーザＡからユーザＢへのオーブの送金に関する通常トランザクションである。さらに、Ｏ１１〜Ｏ１３はそれぞれアウトプットデータを表し、Ｉ１１はインプットデータを表している。
【００５９】
まず、ユーザＡがオーブを１００００Ｏｒｂ購入するとする。この場合、送金受付部１０１によって、通貨購入画面が端末１００Ａのディスプレイに提示される。ユーザＡは提示された通貨購入画面から、購入するオーブの金額を１００００Ｏｒｂとして指定する。このとき、アウトプットデータ作成部１０３は、マッピング情報ＤＢ１３６を参照して、送金金額を１００００Ｏｒｂ、送金先をユーザＡとしてユーザＡのＩＤを指定してアウトプットデータＯ１１を作成する。
【００６０】
次に、送金トランザクション配信部１０４が、アウトプットデータＯ１１を送金トランザクションＴ１１に格納し、現在時刻をトランザクション発生時刻に指定して、通貨発生トランザクションを作成し、ネットワーク４００に配信する。配信した通貨発生トランザクションが、後述するマイナーの発掘処理によって、承認され、ブロックチェーンにつながれると、ユーザＡは購入したオーブを取引に使えるようになる。
【００６１】
ユーザＡは、たとえばオーブの購入から１１日後に、購入したオーブの一部（７０００Ｏｒｂ）をユーザＢに対して送金するとする。この場合、インプットデータ作成部１０２が、まず送金対象検索処理を実行し、これまでにユーザＡが送金先ユーザとして指定されているアウトプットデータを有する送金トランザクションを検索する。図５の例では、該当する送金トランザクションが送金トランザクションＴ１１だけであるため、インプットデータ作成部１０２は送金トランザクションＴ１１を抽出する。
【００６２】
次に、インプットデータ作成部１０２は、減価額計算処理を実行し、アウトプットデータＯ１１の減価額を計算する。今回の送金は、オーブの購入から１１日後に行われているため、減価率は１０％である。そのため、インプットデータ作成部１０２は、アウトプットデータＯ１１の減価額は、１０００Ｏｒｂであると算出する。インプットデータ作成部１０２は、算出した減価額（１０００Ｏｒｂ）をアウトプットデータＯ１１の送金金額（１００００Ｏｒｂ）から減算し、アウトプットデータＯ１１の残高を９０００Ｏｒｂであると算出する。これは、今回の送金金額である７０００Ｏｒｂを上回っているため、インプットデータ作成部１０２は、アウトプットデータＯ１１のポインタを、今回のインプットデータＩ１１に指定する。さらにインプットデータ作成部１０２は、電子署名作成処理を実行する。具体的には、電子署名を格納する部分を除く、作成中の送金トランザクションのデータ全体にハッシュ関数を用いてダイジェストを作成する。そして、口座情報ＤＢ１３４に保存されたユーザＡの秘密鍵を用いてインプットデータ作成部１０２は、生成したダイジェストを暗号化して電子署名を作成する。インプットデータ作成部１０２は、指定したポインタと、作成した電子署名と、送金元ユーザの公開鍵とを格納してインプットデータＩ１１を作成する。
【００６３】
次に、アウトプットデータ作成部１０３は、送金金額を７０００Ｏｒｂ、送金先をユーザＢとして、マッピング情報ＤＢ１３６からユーザＢのＩＤに対応するレコードを参照し、ユーザＢのＩＤと公開鍵とを指定して、アウトプットデータＯ１２を作成する。さらに、アウトプットデータ作成部１０３は、アウトプットデータＯ１１の残高９０００Ｏｒｂから今回のアウトプットデータＯ１２の送金金額である７０００Ｏｒｂを減算し、差分である２０００Ｏｒｂを、ユーザＡのＩＤを送金先とするアウトプットデータＯ１３を作成する。
【００６４】
送金トランザクション配信部１０４は、インプットデータＩ１１と、アウトプットデータＯ１２と、アウトプットデータＯ１３とを送金トランザクションＴ１２に格納し、現在時刻をトランザクション発生時刻に指定して、送金トランザクションＴ１２を配信する。
【００６５】
なお、上述の例で、送金金額がたとえば９５００Ｏｒｂである場合、送金金額がアウトプットデータＯ１１の残高である９０００Ｏｒｂを上回っているため、インプットデータ作成部１０２は、アウトプットデータＯ１１のポインタを指定することができない。この場合、インプットデータ作成部１０２は、送金金額をたとえば９０００Ｏｒｂと５００Ｏｒｂとの２つの金額に分割することができる。このとき、インプットデータ作成部１０２は、それぞれの送金金額に対応するインプットデータを作成し、ポインタで参照するアウトプットデータを検索することが望ましい。さらにこの場合、アウトプットデータ作成部１０３は、送金金額が９０００Ｏｒｂのアウトプットデータをと、５００Ｏｒｂのアウトプットデータとをそれぞれ作成するとしてもよい。
【００６６】
このように本実施形態に係るウォレットツールが、オーブが時間の経過とともに減額するように、端末１００を機能させることで、オーブは投資の対象とされにくくなり、通貨価値の変動を抑えることが可能となる。
【００６７】
＜マッピング情報更新処理フロー＞
図６を用いて、ユーザＡがマッピング情報を更新する場合の処理フローについて説明する。図６は、マッピング情報に登録している公開鍵を、新鍵に更新する場合のマップトランザクションを模式的に示した図である。この例では、マッピング情報ＤＢ１３３には、ユーザＡの管理ユーザとして、ユーザＡ、ユーザＢ、ユーザＣの３人のＩＤが登録されているとして説明する。また、ユーザＡが使用する端末を端末１００Ａとし、ユーザＢが使用する端末を端末１００Ｂとする。
【００６８】
図６において、ブロックＢ２２は、ブロックチェーンの末尾のブロックであり、ブロックＢ２１はユーザＡがＩＤを作成したＩＤ発生トランザクションが含まれるブロックであるとする。また、マップトランザクションＴ２１はＩＤ発生トランザクションであり、マップトランザクションＴ２２は、ユーザＡが公開鍵を旧鍵から新鍵へとマッピング情報を更新するトランザクションである。さらに、Ｏ２１とＯ２２とはアウトプットデータを表し、Ｉ２２はインプットデータを表している。
【００６９】
まずユーザＡは、ＩＤを新規に作成する。この場合、マッピング部１０５によって、発行受付画面が、端末１００Ａのディスプレイに提示される。ユーザは提示された発行受付画面に、ＩＤ発行情報として、メールアドレスや電話番号など任意の文字列を入力し、公開鍵とスペアキーとを登録する。さらに、ユーザＡは管理ユーザ情報として、登録するユーザのＩＤ（図６の例では、ユーザＡ、ユーザＢ、ユーザＣ）を指定する。マッピング部１０５は、入力された文字列のハッシュ値からＩＤを作成する。そして、マッピング部１０５は、作成したＩＤと受け付けたＩＤ発行情報と管理ユーザ情報とを紐づけてユーザＡのマッピング情報を作成し、アウトプットデータＯ２１に格納する。マッピング部１０５は、ＩＤ発生トランザクションＴ２１に作成したアウトプットデータＯ２１を格納し、ネットワーク４００にブロードキャストで配信する。配信されたＩＤ発生トランザクションＴ２１は、後述するマイナーの発掘処理によって、承認されると、ブロックチェーンにつながれる。ブロックチェーンにＩＤ発生トランザクションＴ２１がつながれると、ユーザＡのマッピング情報として、ネットワーク４００で共有される。
【００７０】
ユーザＡが、ＩＤを新規に作成した後、登録した公開鍵とペアになる秘密鍵を紛失した等の理由により、マッピング情報を更新するとする。この場合、マッピング部１０５は、まず発行受付処理を行い、登録する新鍵と、ユーザＡの登録済みのＩＤを受け付ける。
マッピング部１０５は、マッピング情報ＤＢ１３３を参照し、受け付けたＩＤに対応するマッピング情報（旧マッピング）を抽出する。マッピング部１０５は、抽出した旧マッピングの公開鍵（旧鍵）を新鍵に更新した新マッピングを作成し、アウトプットデータＯ２２に格納する。
【００７１】
次に、マッピング部１０５は、ポインタ指定処理を行う。具体的には、まずマッピング部１０５は、マッピング情報ＤＢ１３３に登録されているユーザＡの旧マッピングから、ユーザＡのＩＤと対応する公開鍵（旧鍵）を特定する。さらにマッピング部１０５は、特定した旧鍵を公開鍵とするマッピング情報がアウトプットデータとして指定されているマップトランザクションを抽出する。図６の例では、公開鍵の更新は今回初めて行われるので、マッピング部１０５は、ＩＤ発生トランザクションＴ２１を抽出する。マッピング部１０５は、ＩＤ発生トランザクションＴ２１のアウトプットデータＯ２１を参照するポインタを今回のインプットデータＩ２２に格納する。
【００７２】
次に、マッピング部１０５は、電子署名作成処理を実行する。この例では、マッピング部１０５は、ユーザＢとユーザＣとの電子署名を作成する。具体的には、電子署名を格納する部分を除く、作成中のマップションのデータ全体にハッシュ関数を用いてダイジェストを作成する。そして、ユーザＢの秘密鍵を用いてダイジェストを暗号化し、ユーザＢの電子署名を作成する。また、ユーザＣの秘密鍵を用いてダイジェストを暗号化し、ユーザＣの電子署名を作成する。
【００７３】
マッピング部１０５は、ユーザＢおよびＣの電子署名とユーザＢおよびＣの公開鍵、およびアウトプットデータＯ２１へのポインタをインプットデータＩ２２に格納する。
【００７４】
マッピング部１０５は、インプットデータＩ２２と、アウトプットデータＯ２２とをマップトランザクションＴ１２に格納し、配信する。
【００７５】
なお、上述の例で、ユーザＡがたとえば、秘密鍵を紛失しておらず、マッピング情報の公開鍵およびスペアキーを変更したい場合は、マッピング部１０５は、インプットデータＩ２２にユーザＡの電子署名と公開鍵とアウトプットデータＯ２１へのポインタとを格納し、他の管理ユーザの電子署名は格納しないとしてもよい。この場合、アウトプットデータＯ２１に格納されるマッピング情報（新マッピング）からは、旧鍵は削除されるとしてもよい。
【００７６】
図２に戻り、端末２００の機能について説明する。
＜３−４．マイニングツールの機能＞
図２（Ｂ）は、ウォレットツールに加えて、マイニングツールをインストールした、端末２００の機能ブロック図の一例を示す図である。マイニングツールをインストールした端末２００には、上述したウォレットツールによって作成される機能ブロックに加えて、検証部２０１と、発掘部２０２と、報酬計算部２０３と、更新許可部２０４とが構築されることが望ましい。
【００７７】
検証部２０１は、受信した送金トランザクションの正当性を検証するために、以下の３つの処理を実行する。
・ＩＤ検証処理
・完全性検証処理
・整合性検証処理
検証部２０１は上記３つの検証処理の結果、ＩＤと完全性と整合性とが認められた送金トランザクションを正当な送金トランザクションであると承認することができるとしてもよい。
【００７８】
（ＩＤ検証処理）
検証部２０１は、ＩＤ検証処理として、今回送金を行った送金元ユーザが、送金したオーブの正当な所有者であったかを、ＩＤを検証することによって確認する。たとえば、検証部２０１は、受信した送金トランザクションのインプットデータに含まれる電子署名と、ポインタが参照するアウトプットデータに含まれるＩＤとが、同一のユーザのものであるか否かを検証する。
図７は、ＩＤ検証処理の処理フローを示す図である。
まず、検証部２０１は、受信した送金トランザクションのインプットデータから送金元ユーザの電子署名と公開鍵とを取得する（Ｓ１１）。また、検証部２０１は、受信した送金トランザクションのインプットデータに含まれるポインタが参照するアウトプットデータに格納されている、ＩＤ（ＩＤ１とする）を取得する（Ｓ１２）。
次に、検証部２０１は、マッピング情報ＤＢ１３３を参照して、取得した公開鍵に紐づけられたユーザのＩＤ（ＩＤ２とする）を抽出し（Ｓ１３）、ＩＤ１とＩＤ２とが一致するか検証する（Ｓ１４）。一致した場合には、さらに、検証部２０１は、ＩＤ２に紐づけられている公開鍵で、送金トランザクションに含まれていた電子署名が復号できるか検証する（Ｓ１５）。復号できた場合には、検証部２０１は、送金を行ったユーザが、送金したオーブの正しい所有者であったと認証する（Ｓ１６）。なお、Ｓ１５の電子署名の検証は、受信した送金トランザクションにインプットデータに格納されている公開鍵で行うものとしてもよい。
このように、本実施形態に係る仮想通貨管理プログラムによれば、送金元ユーザの認証をＩＤによって行う。これによって、ユーザが公開鍵を更新した場合でも、更新前と同じユーザであると識別することができる。
【００７９】
（完全性検証処理）
検証部２０１は、完全性検証処理として、受信した送金トランザクションに対して改ざんが行われていないかを検証する。具体的には、検証部２０１は、まずマッピング情報ＤＢ１３３を参照して、受信した送金トランザクションのインプットデータに含まれる電子署名を、もとの所有者の公開鍵で復号して、インプットデータ作成部１０２が作成したダイジェストを取り出す。さらに検証部２０１は受信した送金トランザクションのデータ全体のうち電子署名を格納する部分を除いたデータから、ハッシュ関数を用いてダイジェストを生成する。検証部２０１は、復号したダイジェストと生成したダイジェストとが一致するか否かを検証し、一致する場合には送金トランザクションデータの完全性を承認することができる。検証部２０１は、送金トランザクションに含まれるすべてのインプットデータの電子署名を検証できた場合に、当該送金トランザクションの完全性を承認することができるとしてもよい。
【００８０】
（整合性検証処理）
検証部２０１は、整合性検証処理として、受信した送金トランザクションがブロックチェーン全体として整合性がとれた取引であるか否かを検証する。具体的には、検証部２０１は、上述した減価額計算処理と同様の処理を実行して、インプットデータの残高を計算して、計算した残高がアウトプットデータの金額より上回っているか検証する。
また、検証部２０１は、整合性検証処理として、検証対象の送金トランザクションのインプットデータと同じアウトプットデータを参照している送金トランザクションがすでに承認されていないかを確認して二重取引の検証を行うとしてもよい。具体的には、検証部２０１は、ブロック情報ＤＢ１３２を参照して、ブロックチェーンにつながれたブロックに含まれる送金トランザクションのインプットデータのポインタが参照するアウトプットデータを抽出する。さらに検証部２０１は、今回の検証対象の送金トランザクションのインプットデータとして指定されたポインタが参照するアウトプットデータが、すでに参照されているものか否かを検証する。今回の検証対象の送金トランザクションのインプットデータとして指定されたポインタが参照するアウトプットデータが、過去の送金トランザクションのインプットデータからポインタを指定されていない場合、検証部２０１は、今回の検証対象の送金トランザクションのインプットデータの整合性を承認することができる。
検証部２０１は、送金トランザクションに含まれるすべてのインプットデータの整合性が承認できた場合に、当該送金トランザクションの整合性を承認することができるとしてもよい。
【００８１】
発掘部２０２は、検証部２０１の処理によって送金元ユーザが認証され、完全性と整合性が認められた正当な送金トランザクションを格納するブロックを生成するために、マイニングの処理を行う。具体的には、発掘部２０２は、現在のブロックチェーンの末尾のハッシュ値を、ハッシュ関数を用いて計算する。計算したハッシュ値と、生成するブロックに所定の値とを合わせたデータに対して、発掘部２０２は、ハッシュ関数を用いてハッシュ値を計算する。このデータには、ブロックの生成時刻を含めてもよい。このハッシュ値が所定の値以下になる場合、本実施形態では「ブロックが発掘された」という。ブロックを発掘すると、発掘部２０２は、当該ブロックを、ブロックチェーンの末尾につなぐことができる。
発掘部２０２は、ブロックをブロックチェーンにつなぐ際に、現在時刻を、当該ブロックに格納されている送金トランザクションのブロックチェーン追加時刻として指定することが望ましい。
【００８２】
報酬計算部２０３は、ブロックに格納した正当な送金トランザクションの減価額に基づいて、マイナーの報酬を計算する。たとえば、報酬計算部２０３は、インプットデータのポインタとして指定されたアウトプットデータの金額の、減価額の合計をマイナーの報酬として計算してもよい。具体的には、報酬計算部２０３は、インプットデータに含まれるポインタを順次参照していき、通貨発生トランザクションを抽出する。そして、報酬計算部２０３は、通貨発生トランザクションのトランザクション発生時刻を参照し、現在時刻との差分に基づいて減価率を計算する。この処理は、インプットデータ作成部１０２の減価額計算処理と同様の処理であってもよい。報酬計算部２０３は、発掘部２０２が生成したブロックに格納される各送金トランザクションの減価額の合計をマイナーの報酬として計算することができる。
さらに報酬計算部２０３は、送金金額を計算した報酬の金額、送信先を端末２００を利用するマイナーに指定して、アウトプットデータを作成して、当該アウトプットデータに基づいて通貨発生トランザクションを作成することが望ましい。報酬計算部２０３は作成した通貨発生トランザクションを、ネットワーク４００にブロードキャストで配信する。この通貨発生トランザクションは生成するブロックに含めることでブロードキャストすることが望ましい。この通貨発生トランザクションがネットワーク４００に接続しているいずれかのマイナーの端末によって承認されることで、端末２００を利用するマイナーは、報酬を受け取ることができる。
【００８３】
更新許可部２０４は、マッピング情報の更新が、管理ユーザによって行われたものか否かに基づいて妥当性を検証し、妥当な場合には更新を許可する。たとえば、更新許可部２０４は、マップトランザクションに含まれる電子署名と公開鍵とを用いて、当該電子署名が更新対象となるマッピング情報に管理ユーザとして登録されたユーザのものであるか否かの検証を行う。
図８は、更新許可部２０４の更新許可処理フローの一例をチャートである。なお、図８では、更新許可部２０４が、図６のＴ２２に示したマップトランザクションにおいて行われる、マッピング情報の更新を検証する場合を例に説明する。
【００８４】
まず、マップトランザクションを受信すると更新許可部２０４は、アウトプットデータＯ２２に格納されたマッピング情報からユーザＡのＩＤを取得する（Ｓ２１）。次に、マッピング情報ＤＢ１３３を参照し、取得したユーザＡのＩＤがすでに登録済みのＩＤであるか否かを確認する（Ｓ２２）。取得したユーザＡのＩＤがマッピング情報ＤＢ１３３に登録されていないＩＤである場合（Ｓ２２：ＮＯ）には、取得したマッピング情報を、マッピング情報ＤＢ１３３に登録する。
【００８５】
一方で、取得したユーザＡのＩＤがマッピング情報ＤＢ１３３に登録されているＩＤである場合（Ｓ２２：ＹＥＳ）には、更新許可部２０４は、インプットデータＩ２２を参照し、更新処理に必要な人数分の正しい電子署名が格納されているか検証する（Ｓ２３）。更新処理に必要な人数は、たとえば３人中２人である。
【００８６】
更新許可部２０４は、インプットデータＩ２２に電子署名とともに格納されているユーザＢとユーザＣとの公開鍵を取得する。マッピング情報ＤＢ１３３を参照して、更新許可部２０４は、取得した公開鍵に対応するユーザＩＤを確認し、当該ユーザＩＤが管理ユーザとして登録されていたＩＤと一致するか検証する。一致した場合には、更新許可部２０４はさらに、取得したユーザＢとユーザＣそれぞれの公開鍵でそれぞれの電子署名が復号できるか検証する。
【００８７】
必要な人数分、正しい電子署名が格納されていた場合（Ｓ２３：ＹＥＳ）には、更新許可部２０４は、新マッピングで、公開鍵に指定されている新鍵が、ネットワーク４００においてユニークな鍵かを確認する（Ｓ２４）。具体的には、更新許可部２０４は、マッピング情報ＤＢ１３３を参照して、他のユーザの公開鍵として登録されていないを確認する。新鍵として指定されている公開鍵がユニークな鍵であれば（Ｓ２４：ＹＥＳ）、更新許可部２０４は、マッピング情報の更新を許可する。
【００８８】
このように、本実施形態に係る仮想通貨管理プログラムによれば、ユーザがマッピング情報を更新する際に、付与された電子署名が、管理ユーザとして登録されたユーザのものであるかを、マッピング情報を再帰的に参照する。これによって、更新後のユーザが更新前のユーザと同一視できるユーザであることを担保することができる。
【００８９】
＜３−５．マイニング処理フロー＞
図９を用いて、マイニングツールをインストールした端末２００のマイニング処理の処理フローについて、送金トランザクションをブロックに格納する場合を例に説明する。
まず、検証部２０１は、送金トランザクションＤＢ１３１を参照して、受信した送金トランザクションのうち、検証が行われていない未検証送金トランザクションが残っているか否か確認する（Ｓ１０１）。未検証送金トランザクションが残っている場合（Ｓ１０１：ＹＥＳ）には、検証部２０１は、当該未検証送金トランザクションを、検証を行うために取得する（Ｓ１０２）。
【００９０】
次に検証部２０１は、取得した検証対象の送金トランザクションに含まれるインプットデータのうち、未検証のインプットデータがある場合（Ｓ１０３：ＹＥＳ）、当該未検証のインプットを取得して（Ｓ１０４）、インプットデータの検証を行う。まず、検証部２０１は、取得したインプットデータのポインタから、当該インプットデータに用いられているオーブの通貨発生トランザクションを抽出する（Ｓ１０５）。さらに、検証部２０１は通貨発生トランザクションのトランザクション発生時刻と現在時刻との差分から、減価額とインプットデータの残高とを計算する（Ｓ１０６）。
【００９１】
次に、検証部２０１は、検証対象送金トランザクションに含まれるアウトプットデータの送金金額の合計金額が、計算した残高を上回っていないか確認して、当該インプットデータの正当性を検証する（Ｓ１０７）。送金金額の合計金額が、計算した残高を上回っている場合（Ｓ１０７：ＮＯ）には、検証部２０１は、検証対象の送金トランザクションは不正な送金トランザクションであるとして、ブロックには格納しない（Ｓ１５１）。一方で、検証対象送金トランザクションに含まれるアウトプットデータの送金金額の合計金額が、計算した残高を上回っていない場合（Ｓ１０７：ＹＥＳ）には、検証対象送金トランザクションは、正当なインプットデータであるとして、当該インプットデータを承認する。検証部２０１は、このＳ１０３〜１０７までの処理を送金トランザクションに含まれるすべてのインプットデータの検証が完了するまで繰り返し実行する。送金トランザクションに含まれるすべてのインプットデータが正当であると承認した場合には、検証は当該送金トランザクションを正当な送金トランザクションとしてブロックに格納する。
【００９２】
検証部２０１は、Ｓ１０１〜Ｓ１０７までの処理を未検証送金トランザクションがなくなるまで繰り返し実行する。端末２００が受信した送金トランザクションに未検証送金トランザクションがなくなると（Ｓ１０１：ＮＯ）、報酬計算部２０３は、ブロックに格納した送金トランザクションの減価額の合計金額に基づいて、マイナーの報酬を計算する。さらに報酬計算部２０３は、送金金額を計算した合計金額とし、送金先を当該マイナーに指定して、通貨発生トランザクションを作成し、ネットワーク４００にブロードキャストで配信する（Ｓ１０８）。配信した通貨発生トランザクションが他のマイナーに承認されると、報酬金が、通貨発生トランザクションを配信したマイナーに与えられる（Ｓ１０９）。
【００９３】
このように本実施形態に係るマイニングツールが、マイナーが獲得する報酬が承認したブロックに含まれる送金トランザクションの減価額に基づいて決定するように端末２００を機能させることで、マイナーに対する報酬を枯渇させないようにすることが可能となる。
【００９４】
（４  ハードウェア構成）
以下、図１０を参照しながら、上述してきた端末１００及び端末２００をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。
【００９５】
図１０に示すように、コンピュータ８００は、プロセッサ８０１、メモリ８０３、記憶装置８０５、入力Ｉ／Ｆ部８０７、データＩ／Ｆ部８０９、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。
【００９６】
プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、端末１００の送金受付部１０１やインプットデータ作成部１０２、アウトプットデータ作成部１０３、送金トランザクション配信部１０４、マッピング部１０５、端末２００の検証部２０１や発掘部２０２、報酬計算部２０３、更新許可部２０４などは、メモリ８０３に一時記憶された上で、主にプロセッサ８０１上で動作するプログラムとして実現可能である。
【００９７】
メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。
【００９８】
記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、送金トランザクション情報ＤＢ１３１や、ブロック情報ＤＢ１３２、マッピング情報ＤＢ１３３、口座情報ＤＢ１３４、マッピングトランザクション情報ＤＢ１３５を記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。
【００９９】
入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。
【０１００】
データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。
【０１０１】
通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。
【０１０２】
表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブル等を介してコンピュータ８００に接続される。
【０１０３】
[その他の実施形態]
以上、本発明の実施形態について述べたが、本発明は既述の実施形態に限定されるものではなく、本発明の技術的思想に基づいて各種の変形及び変更が可能である。
【０１０４】
例えば、既述の実施形態において、マイニングツールは、ウォレットツールと合わせてインストールされる構成として説明したが、これに限定されない。たとえば、端末２００はマイニングツールだけをインストールする構成としてもよい。この場合、端末２００には、検証部２０１、発掘部２０２、及び報酬計算部２０３とあわせて、送金トランザクション情報ＤＢ１３１、ブロック情報ＤＢ１３２、及び公開鍵情報ＤＢ１３３がインストールされることが望ましい。また、既述の実施形態において、仮想通貨は時間の経過とともに減価する構成を例に説明したが、これに限定されず、減価しないものであってもよい。さらに、仮想通貨は電子的に資産として管理や取引されるものであればよく、現実の通貨や株、債券、土地等に対応するものであってもよい。
【符号の説明】
【０１０５】
１０          仮想通貨システム
１００        端末
１０１        送金受付部
１０２        インプットデータ作成部
１０３        アウトプットデータ作成部
１０４        送金トランザクション配信部
１０５        マッピング部
１３１        送金トランザクション情報ＤＢ
１３２        ブロック情報ＤＢ
１３３        マッピング情報ＤＢ
１３４        口座情報ＤＢ
１３５        マッピングトランザクション情報ＤＢ
２００        端末
２０１        検証部
２０２        発掘部
２０３        報酬計算部
２０４        更新許可部
４００        ネットワーク
【要約】      （修正有）【課題】鍵ペアを更新後も、更新前に利用していた仮想通貨を継続して利用可能とする、仮想通貨管理プログラム、及び仮想通貨管理方法を提供する。【解決手段】ユーザの識別子と、ユーザの公開鍵との対応関係を示すマッピング情報を記憶する手段、仮想通貨を第１のユーザに送金する第１の取引における、第１のユーザの識別子を含む第１の取引情報と、第１の取引により送金された金額の少なくとも一部を第１のユーザが送金する第２の取引における、第１のユーザの第１の公開鍵及び第１の電子署名を含む第２の取引情報とを記憶する手段、及び第２の取引情報に含まれる第１の公開鍵が、マッピング情報において、第１の取引情報に含まれる第１のユーザの識別子に対応付けられているか否か、及び、第２の取引情報に含まれる第１の公開鍵で第２の取引情報に含まれる第１の電子署名を検証できるか否かに基づいて、第２の取引の正当性を検証する手段、を備える。【選択図】図７【図１】
0005858506.tif 000002
【図２】
0005858506.tif 000003
【図３】
0005858506.tif 000004
【図４】
0005858506.tif 000005
【図５】
0005858506.tif 000006
【図６】
0005858506.tif 000007
【図７】
0005858506.tif 000008
【図８】
0005858506.tif 000009
【図９】
0005858506.tif 000010
【図１０】
0005858506.tif 000011