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