WO2021019683A1

WO2021019683A1 - 仮想債券回収装置、仮想債券回収プログラム及び仮想債券回収方法

Info

Publication number: WO2021019683A1
Application number: PCT/JP2019/029812
Authority: WO
Inventors: 松本　光弘; 洋横地; 大輝中島
Original assignee: 三菱電機株式会社
Priority date: 2019-07-30
Filing date: 2019-07-30
Publication date: 2021-02-04
Also published as: US20220101431A1; GB2599332A; JP6752384B1; CN114144802A; JPWO2021019683A1

Abstract

スマートコントラクト（８００）は、債券発行部（８３２）と債券回収部（８３３）を備える。債券発行部（８３２）は、買い主である取引所から売り主であるユーザに支払うべき支払額が、取引所の預金ウォレットの預金額で支払えるかを判定し、支払えない場合、支払額の少なくとも一部の金額に相当する債券をユーザに発行し、債券の金額をユーザの債券ウォレットに格納し、ユーザを債権者リストに登録する。債券回収部（８３３）は、取引所の預金ウォレットへの入金がある場合、入金を契機として債権者リストに登録されている債権者を選択し、入金額と債権者に発行されている債券の金額とを比較する。債券回収部（８３３）は、入金額によって債券の金額の少なくとも一部を返済できる場合は、入金額によって、債権者に債券の金額の少なくとも一部を返済する。

Description

仮想債券回収装置、仮想債券回収プログラム及び仮想債券回収方法

　この発明は、分散台帳ネットワークにおける仮想債券を回収する仮想債券回収装置に関する。

　従来では、仮想通貨を用いた所持金以上の取引は、できなかった。所持金以上の取引を実行すると、トランザクションが許可されず、ブロックチェーンに登録できないからである。

　一方、仮想通貨にはトークンという独自通貨の仕組みがあり、トークンは独自に発行したり、他の人に送付したりすることができる。トークンであるカラードコインというビットコインに付加情報を与えて、金あるいは株式のような取引を記録する方法がある。カラードコインの方法を用いて債券及び手形のような有価証券取引を、ブロックチェーンで管理する方法が提案されている（特許文献１，２）。

　また、スマートコントラクトと呼ばれるプログラムを実行ができるブロックチェーンもある。スマートコントラクトのようなプログラムにより制御されたトークンによって、資産を管理することができる。
　例えば、知的財産権をトークンとして管理する方法が提案されている（特許文献３）。

特開２０１８－７７７１４号公報特開２０１８－８１４９８号公報特開２０１９－２３８４３号公報

　スマートコントラクトを用いることで、取引をプログラムにより制御できるため、信頼できない２者間であっても、安全に取引を行うことができる。例えば、ユーザが取引所にコモディティを売る場合、ユーザがコモディティを取引所に渡し、取引所が通貨を支払う。この時、取引所が通貨を支払わなかった場合、ユーザはコモディティの対価を受け取ることができない。
　スマートコントラクトを用いた場合、予め取引所がスマートコントラクトに通貨を預けておき、この預金から自動的に支払いが実行されれば、ユーザは対価を受け取ることができる。

　しかし、債券を考慮していないと、以下の課題が発生する。
（１）預金以上の売り注文を受け付けることができないため、取引所は想定以上の通貨をスマートコントラクトに預金しておく必要があり、預けたお金はその他の取引に利用できない。したがって、キャッシュフローが下がる。
（２）ユーザが大金の売り注文を出すと、注文を約定させるために、取引所は預金を確保しなければならず、他のユーザの売り注文を受け付けることができない。
（３）ユーザは、コモディティを売らないという空売り注文ができるため、サイバー攻撃のＤＯＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅ　ａｔｔａｃｋ）に似た攻撃が可能となる。
　もし、注文順ではなく、約定順、すなわち、コモディティの売りが成立した順に支払いを行えば、上記の空売りの課題（３）はなくなる。しかし、売り注文の成立を保証することができなくなるため、コモディティを取引所に渡したのに通貨を得ることができないという状況が発生し、安心して取引を行うことができない。
　注文が受け付けられたことで取引成立を約束される、という状況の方がユーザにとって好ましい。

　債券という概念を加えることで、通貨が不足しても債券を発行すれば、上記のような課題は起こらず、取引所は、全ての取引を成立させることができる。

　一方、従来では債券をトークン（独自通貨）として管理する方法は提案されているが、債券を強制的に回収する仕組みがない。
　このため、仮想通貨が不足した場合に債券を発行しても、債券分が仮想通貨として返ってくる保証がなく、債券を考慮した仮想通貨で、電力の売買のようなコモディティ取引を実現できないという課題があった。

　この発明は、仮想通貨を用いたコモディティ取引を、円滑に行うことを目的とする。

　本発明の仮想債券回収装置は、
　仮想通貨の入金を検出する入金検出部と、
　前記仮想通貨の入金が検出された場合に、電子データである仮想債券を有する債権者が管理されている債権者情報を参照し、前記仮想債券の示す金額の少なくとも一部を前記債権者に返済する債券回収部と、を備える。

　この発明の仮想債券回収装置は、債券回収部を備えているので、仮想通貨を用いたコモディティ取引を、円滑に行うことができる。

実施の形態１の図で、ブロックチェーンネットワーク３０のネットワーク構成図。実施の形態１の図で、ユーザ端末１００及び取引所端末４００のソフトウェア構成図。実施の形態１の図で、注文アプリ２００の機能構成図。実施の形態１の図で、約定アプリ６００の機能構成図。実施の形態１の図で、スマートコントラクト８００の機能構成図。実施の形態１の図で、データＤ１００の構成図。実施の形態１の図で、ノード１０のハードウェア構成図。実施の形態１の図で、ユーザ端末１００のソフトウェア構成を示す図。実施の形態１の図で、取引所端末４００のソフトウェア構成を示す図。実施の形態１の図で、買い注文（Ｆ０００）におけるお金の流れを示す図。実施の形態１の図で、売り注文（Ｆ１００）におけるお金の流れを示す図。実施の形態１の図で、取引所の預金（Ｆ）を示す図。実施の形態１の図で、注文アプリ２００による画面表示を示す図。実施の形態１の図で、注文アプリ２００による画面表示を示す図。実施の形態１の図で、約定アプリ６００による画面表示を示す図。実施の形態１の図で、約定アプリ６００による画面表示を示す図。実施の形態１の図で、買い注文処理（Ｆ０００）のフローチャート。実施の形態１の図で、売り注文処理（Ｆ１００）のフローチャート。実施の形態１の図で、キャンセル処理（Ｆ２００）のフローチャート。実施の形態１の図で、返金処理（Ｆ３００）のフローチャート。実施の形態１の図で、約定処理（Ｆ４００）のフローチャート。実施の形態１の図で、買い約定処理（Ｆ５００）のフローチャート。実施の形態１の図で、売り約定処理（Ｆ６００）のフローチャート。実施の形態１の図で、入金処理（Ｆ７００）のフローチャート。実施の形態１の図で、出金処理（Ｆ８００）のフローチャート。実施の形態１の図で、取引設定処理（Ｆ８１０）のフローチャート。実施の形態１の図で、債権者への返金処理（Ｆ９００）のフローチャート。実施の形態１の図で、債券の発行と回収の例を示す図。実施の形態２の図で、申請部８１４を備えるスマートコントラクト８００の機能構成図。実施の形態２の図で、申請部８１４による画面表示を示す図。実施の形態３の図で、履歴閲覧部２２３を備える注文アプリ２００の機能構成図。実施の形態４の図で、ブロックチェーンネットワーク３０に接続する取引管理端末９００を示す図。

　以下、本発明の実施の形態について、図を用いて説明する。なお、各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。
　以下の実施の形態の説明では債権者という用語を使用している。債権者とは、債券の回収により返金を受ける権利を有するユーザをいう。
　以下の実施の形態の説明では債券という用語を使用している。以下の実施の形態で用いる債券とは、電子データである仮想債券である。
　なお、以下の実施の形態では「ブロックチェーン」を説明しているが、ブロックチェーンは電子データである分散台帳の例である。以下の実施の形態は、分散台帳及び分散台帳を処理する分散台帳ネットワークに適用できる。すなわち実施の形態のスマートコントラクトは、分散台帳及び分散台帳を処理する分散台帳ネットワークに適用できる。

　実施の形態１．
　図１は、実施の形態１で用いるブロックチェーンネットワークのネットワーク構成図である。インターネット２０に接続されたノード１０と呼ばれる端末が、互いにＰ２Ｐ通信をして、データを共有する。インターネット２０を介したＰ２Ｐ通信によって、ブロックチェーン７１０を共有するネットワークを、ブロックチェーンネットワーク３０と呼ぶ。ブロックチェーンネットワーク３０は仮想通貨に使用される。仮想通貨には、ビットコイン及びイーサリアムといった仮想通貨がある。ビットコインとイーサリアムとの大きな違いは、イーサリアムは、ブロックチェーン７１０上で動作するプログラムである、スマートコントラクトという機能を有している点である。
　各ノード１０は、ブロックチェーン７１０とスマートコントラクト８００を有する。スマートコントラクト８００はブロックチェーン７１０で使用される。スマートコントラクト８００によって、ブロックチェーン７１０に登録するデータを制御できる。各ノード１０は、イーサリアムのようなスマートコントラクト８００を有するブロックチェーン７１０を前提に動作する。

　図２は、コモディティ取引を行うユーザ端末１００及び取引所端末４００のソフトウェア構成図である。コモディティ取引を行うユーザは、ユーザ端末１００を有する。コモディティ取引を行う取引所は、取引所端末４００を有する。ユーザ端末１００及び取引所端末４００は、インターネット２０に接続している。ユーザ端末１００と取引所端末４００は、図１のノード１０として、ブロックチェーンネットワーク３０に参加する。ユーザ端末１００は、注文アプリ２００とブロックチェーンクライアント３００という２つのソフトウェアを持つ。

　取引所端末４００は、約定アプリ６００とブロックチェーンクライアント７００との２つの　ソフトウェアを持つ。また取引所端末４００は、スマートコントラクト作成部５００を有する。スマートコントラクト作成部５００は、スマートコントラクト８００を作成し、スマートコントラクト８００をコンパイルし、ブロックチェーンクライアント７００を介して、ブロックチェーン７１０に、スマートコントラクト８００を登録する。一般的に、スマートコントラクト８００は、スマートコントラクト開発環境で開発される。スマートコントラクト開発環境とは、イーサリアムでいうと、ＲｅｍｉｘあるいはＴｒｕＦＦｌｅである。

　ブロックチェーンクライアント３００及びブロックチェーンクライアント７００は、ブロックチェーンネットワーク３０を構成するソフトウェアである。ブロックチェーンクライアント３００及びブロックチェーンクライアント７００は、仮想通貨のアカウントを管理し、ブロックチェーン７１０を他のブロックチェーンクライアントと共有する。

　注文アプリ２００は、ユーザがコモディティの売買注文を出すアプリである。

　約定アプリ６００は、取引所がユーザからリクエストされた注文を約定するアプリである。

　図３は、実施の形態１において、コモディティ取引を行う際にユーザが利用する注文アプリ２００の機能構成図である。ユーザ端末１００で動作する注文アプリ２００は、注文を処理する注文部２１０、取引履歴を扱う取引履歴部２２０、及び返金された通貨をユーザのアカウントウォレットに送金する返金部２３０を備える。注文部２１０は、ユーザが注文内容を入力する注文入力部２１１、入力された注文内容をブロックチェーンネットワーク３０に送信する注文送信部２１２及び注文内容をキャンセルするキャンセル部２１３を備える。取引履歴部２２０は、ブロックチェーン７１０から取引履歴を取得する取引履歴取得部２２１と、取得した取引履歴を表示する取引履歴表示部２２２とを備える。

　図４は、コモディティ取引を行う際に取引所が利用する、約定アプリ６００の機能構成図である。

　取引所端末４００で動作する約定アプリ６００は、約定を処理する約定部６１０、取引内容を設定する取引設定部６２０、取引履歴を扱う取引履歴部６３０、及び預金を管理する預金部６４０を備える。約定部６１０は、注文アプリ２００からリクエストされた注文内容を取得する注文取得部６１１、取得した注文に対して、約定内容が入力される約定入力部６１２、及び入力された約定内容をブロックチェーンネットワーク３０に送信し、約定を実行する約定送信部６１３を備える。取引履歴部６３０は、ブロックチェーン７１０から取引履歴を取得する取引履歴取得部６３１、及び取得した取引履歴を表示する取引履歴表示部６３２を備える。取引設定部６２０は、売買価格及び約定期限のような取引に関する設定情報が入力される設定入力部６２１、及び設定情報をブロックチェーンネットワーク３０に送信する設定送信部６２２を備える。

　預金部６４０は、入金額入力部６４１、入金送信部６４２、出金額入力部６４３、及び出金送信部６４４を備える。預金部６４０は、取引所がユーザからのコモディティ売り注文に対して支払い用の通貨を用意するための預金を管理する。入金額入力部６４１は、取引所が入金額を入力する。入金送信部６４２は、入力された入金額を預金として入金するために、入金額をブロックチェーンネットワーク３０に送信する。
　出金額入力部６４３は、預金から通貨を引き出すために、取引所が出金額を入力する。出金送信部６４４は、入力された出金額を預金から出金するために、出金額をブロックチェーンネットワーク３０に送信する。

　図５は、コモディティ取引を制御するスマートコントラクト８００の機能構成図である。スマートコントラクト作成部５００によって作成されたスマートコントラクト８００は、ブロックチェーンネットワーク３０に送信され、全てのコモディティ取引は、スマートコントラクト８００によって制御される。スマートコントラクト８００は、ユーザリクエスト受付部８１０、取引所リクエスト受付部８２０、決済部８３０、取引履歴出力部８４０及び処理完了通知部８５０を備える。

　ユーザリクエスト受付部８１０は、ユーザからのリクエストを受け付ける。取引所リクエスト受付部８２０は、取引所からのリクエストを受け付ける。決済部８３０は、決済処理を行う。取引履歴出力部８４０は、取引履歴を出力する。処理完了通知部８５０は、注文登録及び約定処理のような処理が完了したことを、注文アプリ２００と約定アプリ６００に通知する。

　ユーザリクエスト受付部８１０は、ユーザからの注文を登録する注文部８１１と、ユーザからの注文キャンセルを登録するキャンセル部８１２と、ユーザからの返金リクエストに応えて、ユーザのウォレットに返金額を送金する返金部８１３を備える。
　注文部８１１は、初めて注文を出したユーザに対して、自動的にアカウントを登録するアカウント登録部８１１Ａと、登録されたアカウントに対して注文を登録する注文登録部８１１Ｂを備える。
　取引所リクエスト受付部８２０は、登録された注文に対して取引所が約定を送信した際に、約定内容に応じて約定処理を行う約定部８２１と、取引所が設定した取引内容に合わせて、取引内容を設定する取引設定部８２２と、取引所が設定した入金額の通貨をユーザのウォレットから預金に送金する入金部８２３と、取引所が設定した出金額を預金からユーザのウォレットに送金する出金部８２４を備える。
　決済部８３０は、買い手の支払い金を売り手に送金する送金部８３１と、ユーザの売り注文に対して預金を超える売り価格で約定した際に、通貨の代わりに債券を自動的に発行する債券発行部８３２と、取引所からの入金や他ユーザの買い注文約定によって通貨を取得することで、発行した債券を自動的に通貨に換金する債券回収部８３３を備える。

　図６は、スマートコントラクト８００で管理するデータＤ１００の構成を示す。図６を参照して、スマートコントラクト８００で管理するデータＤ１００を説明する。ユーザのための管理データＤ１１０として、一時金ウォレットＤ１１１、返金ウォレットＤ１１２、債券ウォレットＤ１１３、取引履歴Ｄ１１４がある。一時金ウォレットＤ１１１は、ユーザがコモディティの買い注文を送信時に支払う金額が一時的に保存される場所である。返金ウォレットＤ１１２は、ユーザのおつりや売り代金を入れる場所である。買い注文約定時に、一時金ウォレットＤ１１１から約定額に従って、預金ウォレットＤ１３１に通貨が移動し、おつりが返金ウォレットＤ１１２に移動する。
　また、売り注文約定時に、預金ウォレットＤ１３１から返金ウォレットＤ１１２に通貨が移動することで、支払いが行われる。債券ウォレットＤ１１３は、売り注文約定時に、預金ウォレットＤ１３１の残代が少なく、売り代金を支払えない場合に、支払えなかった代金を記録しておく場所である。取引履歴Ｄ１１４は、ユーザの注文内容と約定内容を履歴として記録しておく場所である。取引所のための管理データとして、預金ウォレットＤ１３１、ユーザリストＤ１３２、債権者リストＤ１３３がある。預金ウォレットＤ１３１は、取引所からの入金されたお金または買い注文約定時にユーザから支払われた代金が、保存される場所である。
　ユーザリストＤ１３２は、注文を出したユーザを記録する場所である。債権者リストＤ１３３は、債券が発行されたユーザを記録する場所である。取引設定データＤ１４０は、売買価格Ｄ１４１と約定期限Ｄ１４２を記録する。売買価格Ｄ１４１は、買いレートと売りレートがあり、例えば、１ｋｗｈあたり、３０円で買い、２５円で売るといったデータを記録する。約定期限Ｄ１４２は、注文が出されてから、約定するまで期限を設定するためのデータであり、約定期限が過ぎると、取引所は約定することはできず、ユーザは注文をキャンセルできる。

　図７は、ノード１０のハードウェア構成を示す。ノード１０はユーザ端末１００及び取引所端末４００であるから、図７はユーザ端末１００及び取引所端末４００のハードウェア構成を示す。

　ノード１０は、コンピュータである。ノード１０は、プロセッサ９２０を備える。ノード１０は、プロセッサ９２０の他に、主記憶装置９３０、補助記憶装置９４０、入出力インタフェース９５０及びネットワークインタフェース９６０といった、他のハードウェアを備える。プロセッサ９２０は、信号線１７０を介して、他のハードウェアと接続され、他のハードウェアを制御する。

　図８は、ノード１０がユーザ端末１００の場合のソフトウェア構成を示す。ノード１０がユーザ端末１００の場合、ユーザ端末１００は、プログラムとして、注文アプリ２００及びブロックチェーンクライアント３００を備える。ブロックチェーンクライアント３００は、ブロックチェーン７１０とスマートコントラクト８００を備えている。スマートコントラクト８００はコードとして図８に示すように、ブロックチェーン７１０に含まれてもよいし、ブロックチェーン７１０以外の方法、例えば、スマートコントラクトコードが記録されているファイル（以下、スマートコントラクトファイル）として保管してもよい。スマートコントラクトファイルの場合は、Ｐ２Ｐあるいはクラウドを利用してブロックチェーンクライアント間でスマートコントラクトファイルを共有する必要がある。
　プロセッサ９２０は、ブロックチェーンクライアント３００を介して、ブロックチェーンに登録されているスマートコントラクトコードを実行してもよいし、スマートコントラクトファイルを直接実行してもよい。

　図９は、ノード１０が取引所端末４００の場合のソフトウェア構成を示す。ノード１０が取引所端末４００の場合、取引所端末４００は、プログラムとして、スマートコントラクト作成部５００、約定アプリ６００及びブロックチェーンクライアント７００を備える。ブロックチェーンクライアント７００は、ブロックチェーン７１０を備えている。スマートコントラクト８００はブロックチェーン７１０に含まれてもよいし、スマートコントラクトファイルとして保管してもよい。プロセッサ９２０が、スマートコントラクト作成部５００、約定アプリ６００及びブロックチェーンクライアント７００を実行する。プロセッサ９２０によるスマートコントラクトの実行はユーザ端末１００の場合と同じであるので、説明は省略する。

　プロセッサ９２０は、演算処理を行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）である。プロセッサ９２０の具体例は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。

　主記憶装置９３０は記憶装置である。主記憶装置９３０の具体例は、ＳＲＡＭ（Ｓｔａｔｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。主記憶装置９３０は、プロセッサ９２０の演算結果を保持する。

　補助記憶装置９４０は、データを不揮発的に保管する記憶装置である。補助記憶装置９４０の具体例は、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）である。また、補助記憶装置９４０は、ＳＤ（登録商標）（Ｓｅｃｕｒｅ　Ｄｉｇｉｔａｌ）メモリカード、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ）といった可搬記録媒体であってもよい。ノード１０がユーザ端末１００の場合、補助記憶装置９４０は、注文アプリ２００、ブロックチェーンクライアント３００及びスマートコントラクト８００を格納する。ノード１０が取引所端末４００の場合、補助記憶装置９４０は、スマートコントラクト作成部５００、約定アプリ６００、ブロックチェーンクライアント７００及びスマートコントラクト８００を格納する。スマートコントラクト８００は、仮想債券回収プログラムに相当する。債券回収プログラムは、入金検出部である入金部８２３、入金検出部である送金部８３１、債券発行部８３２及び債券回収部８３３の「部」を「処理」、「手順」あるいは「工程」に読み替えた各処理、各手順あるいは各工程をコンピュータに実行させるプログラムである。

　入出力インタフェース９５０は、プロセッサ９２０が各装置とデータを入出力するポートである。入出力インタフェース９５０は、入力装置９５１及び表示装置９５２と接続している。入力装置９５１はマウス及びタッチパネルのような装置である。
表示装置９５２は液晶ディスプレイのような装置である。

　ノード１０は、プロセッサ９２０を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、プログラムの実行を分担する。それぞれのプロセッサは、プロセッサ９２０と同じように、プログラムを実行する装置である。単一のプロセッサ及び複数のプロセッサは、プロセッシングサーキットリとも呼ばれる。ユーザ端末１００の注文アプリ２００、ブロックチェーンクライアント３００及びスマートコントラクト８００の機能はプロセッシングサーキットリによって実現される。また、取引所端末４００のスマートコントラクト作成部５００、約定アプリ６００、ブロックチェーンクライアント７００及びスマートコントラクト８００の機能は、プロセッシングサーキットリによって実現される。

　仮想債券回収プログラムは、コンピュータ読み取り可能な記録媒体に格納されて提供されてもよい。

＊＊＊動作の説明＊＊＊
　次に、図面を参照して動作を説明する。
　以下に示すスマートコントラクト８００の動作は、仮想債券回収装置である取引所端末４００におけるスマートコントラクト８００の動作であり、また、仮想債券回収装置であるユーザ端末１００である。これは、取引所端末４００のスマートコントラクト８００で実行されるメソッドＭは、ユーザ端末１００のスマートコントラクト８００でも同様に実行されるからである。仮想債券回収装置の動作手順は、仮想債券回収方法に相当する。仮想債券回収装置の動作を実現するプログラムは、仮想債券回収プログラムに相当する。
図１０は、買い注文（Ｆ０００）におけるお金の流れを示す図である。
図１１は、売り注文（Ｆ１００）におけるお金の流れを示す図である。
図１２は、取引所の預金（Ｆ）を示す図である。
図１３と図１４は、注文アプリ２００による画面表示を示す図である。
図１３と図１４の内容が１画面に表示される。図１３が画面上側、図１３が画面の下側である。
図１５と図１６は、約定アプリ６００による画面表示を示す図である。
図１５と図１６の内容が１画面に表示される。図１５が画面上側、図１６が画面下側である。
図１７は、買い注文処理（Ｆ０００）のフローチャートである。
図１８は、売り注文処理（Ｆ１００）のフローチャートである。
図１９は、キャンセル処理（Ｆ２００）のフローチャートである。
図２０は、返金処理（Ｆ３００）のフローチャートである。
図２１は、約定処理（Ｆ４００）のフローチャートである。
図２２は、買い約定処理（Ｆ５００）のフローチャートである。
図２３は、売り約定処理（Ｆ６００）のフローチャートである。
図２４は、入金処理（Ｆ７００）のフローチャートである。
図２５は、出金処理（Ｆ８００）のフローチャートである。
図２６は、取引設定処理（Ｆ８１０）のフローチャートである。
図２７は、債権者への返金処理（Ｆ９００）のフローチャートである。
図２８は、債券の発行と回収の例を示す図である。

＜Ｆ０００、Ｆ１００＞
　図１０、図１７及び図１８を参照して、まず、ユーザが売買取引を開始するところから説明する。
　ユーザは、注文アプリ２００の注文入力部２１１に、「電力を１，０００円分買う」のような、注文内容を入力する。注文送信部２１２は、注文内容をブロックチェーンネットワーク３０に送信する。買い注文（Ｆ０００）の場合は、注文に従った代金が送金される。

　ブロックチェーンネットワーク３０では、スマートコントラクト８００の注文部８１１が、送信された注文を処理する。まず、注文部８１１のアカウント登録部８１１Ａは、初めて注文を出したアカウントかどうかを判断する。アカウント登録部８１１Ａは、初めて注文を出したアカウントであれば、アカウントをユーザリストＤ１３２に追加する（Ｆ００１）。さらに、注文登録部８１１Ｂは、アカウントに対応付けて、注文を登録する（Ｆ００３）。注文登録部８１１Ｂは、注文を登録すると、注文番号を、ユーザ端末１００の注文アプリ２００に返信する（Ｆ００４）。買い注文の場合は通貨が送金されてくるため（Ｆ００２）、注文登録部８１１Ｂは、予約金としてユーザ用一時金ウォレットＤ１１１に保存される（Ｍ１０１）。処理完了通知部８５０により、注文アプリ２００と約定アプリ６００に、処理完了の通知が送られる（Ｆ００５）。

＜Ｆ４００、Ｆ５００、Ｆ６００＞
　図２１、図２２及び図２３を参照して、スマートコントラクト８００による約定処理を説明する。

　取引所がユーザの注文を約定する際の動作を説明する。約定アプリ６００は、注文取得部６１１によって登録された注文内容を取得する。取引所では、約定入力部６１２が、注文内容に基づき、約定内容を受け付ける。次に、約定送信部６１３が、約定内容をブロックチェーンネットワーク３０に送信する。ブロックチェーンネットワーク３０では、スマートコントラクト８００の決済部８３０が、約定処理Ｆ４００を実施する。

＜Ｆ４００＞
　約定処理Ｆ４００では、取引所がスマートコントラクト８００をブロックチェーンに登録した人（以下、スマートコントラクト８００のオーナー）である場合は、決済部８３０が、約定の実行者がスマートコントラクト８００のオーナーかどうかを確認し（Ｆ４０１）、スマートコントラクト８００のオーナーであれば、注文が有効かを確認する（Ｆ４０２）。
　その後、注文が買い注文であれば（Ｆ４０３で買い）、決済部８３０は、買い約定処理Ｆ５００を実行する。注文が売り注文であれば（Ｆ４０３で売り）、決済部８３０は、売り約定処理Ｆ６００を実行する。最後に処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知送信する（Ｆ００５）。

＜Ｆ５００＞
　送金部８３１は、仮想通貨の入金を検出する入金検出部である。
　入金検出部は、仮想通貨の入金として、買い主である取引所が売り主であるユーザへ支払う仮想通貨の入金（Ｆ５０６）と、取引所による仮想通貨の預金のための仮想通貨の入金（Ｆ７０１）とを検出する。仮想通貨の預金のための仮想通貨の入金（Ｆ７０１）は後述する。
　送金部８３１が仮想通貨の入金を検出した場合、買い約定処理Ｆ５００では、スマートコントラクト８００の送金部８３１が、ユーザ用債券ウォレットＤ１１３の債券を確認し（Ｆ５０６）、債券が０の場合は（Ｆ５０６のＹＥＳ）、ユーザ用一時金ウォレットＤ１１１から約定額を引き出す（Ｆ５０１）。債券が０でない場合は（Ｆ５０６のＮＯ）、送金部８３１は、約定額と債券額とを比較する（Ｆ５０７）。約定額が債券額以上の場合（Ｆ５０７のＹＥＳ）、送金部８３１は、ユーザ用債券ウォレットＤ１１３から債券額を引き出し（Ｆ５０８）、ユーザを債権者リストＤ１３３から外し（Ｆ５０９）、一時金ウォレットＤ１１１から不足額を差し引く（Ｆ５１０）。約定額が債券額より小さい場合（Ｆ５０７のＮＯ）、送金部８３１は、ユーザ用債券ウォレットＤ１１３から約定額を引き出し（Ｆ５１１）、処理はＦ５０２に進む。
　送金部８３１は差額である注文額から約定額を引いた額を、おつりとして返金ウォレットＤ１１２に入れる（Ｆ５０２、Ｍ１０３）。送金部８３１は、約定額を預金ウォレットＤ１３１に入れる（Ｆ５０３，Ｍ１０５）。その後、送金部８３１は、約定内容を取引履歴Ｄ１１４に記録し（Ｆ５０４）、取引内容の注文の状態を「完了」にする（Ｆ５０５）。図１３から図１６において、取引履歴部６３０の注文の状態として、「発注」「キャンセル」「完了」がある。最後に、債券回収部８３３が、約定額に従って（Ｍ１０６）、債権者への返金を行う（Ｆ９００、Ｍ１０７）。

＜Ｆ６００＞
　売り約定処理Ｆ６００を説明する。債券発行部８３２は、買い主である取引所から売り主であるユーザに支払うべき支払額を示す支払額データと、買い主の有する預金額を示す預金データとを比較する。債券発行部８３２は、比較結果に基づいて取引所は債券を売り主に発行し、債券が発行された売り主を債権者情報である債権者リストＤ１３３に登録する。以下に具体的に説明する。
　売り約定処理Ｆ６００では、スマートコントラクト８００の債券発行部８３２が、預金ウォレットＤ１３１に入っているお金で約定額を支払えるかどうかを確認する（Ｆ６０１）。支払える場合（Ｆ６０１でＹＥＳ）は、送金部８３１は、約定額のお金を預金ウォレットＤ１３１からユーザの返金ウォレットＤ１１２に移動する（Ｆ６０２、Ｍ２０２）。もし、預金額が足りない場合（Ｆ６０１でＮＯ）は、債券発行部８３２は、預金額が０より多いかを確認する（Ｆ６０３）。０より多い場合は（Ｆ６０３でＹＥＳ）、約定額の一部を支払えるだけ支払うために、送金部８３１は、預金ウォレットＤ１３１の全額を返金ウォレットＤ１１２に移動する（Ｆ６０４、Ｍ２０２）。債券発行部８３２は、不足分の債券を発行し、債券ウォレットＤ１１３に入れる（Ｆ６０５，Ｍ２０１）。

　もし、預金額が０以下であれば（Ｆ６０３でＮＯ）、債券発行部８３２は、不足分の債券を発行し、債券ウォレットＤ１１３に入れる（Ｆ６０６，Ｍ２０１）。

　Ｆ６０５またはＦ６０６で債券が発行された場合は、債券発行部８３２は、債権者を債権者リストＤ１３３に登録する（Ｆ６０７）。上記決済が完了後、約定部８２１は、約定内容を取引履歴Ｄ１１４に記録し（Ｆ６０８）、注文の状態を完了にする（Ｆ６０９）。

　以上のＦ６０５またはＦ６０６で述べたように、債券発行部８３２は、買い主であるオーナーから売り主であるユーザに支払うべき支払額を示す支払額データが、買い主の預金ウォレットに預金されている預金額を示す預金データで支払えるかを判定する（Ｆ６０４）。債券発行部８３２は、預金データで支払額を支払えないと判定した場合、支払額の少なくとも一部の金額に相当する債券を債券データとして売り主に発行し、発行した債券データを、ユーザごとに設定されている債券ウォレットのうちの、前記債券が発行された前記売り主の債券ウォレットに格納する（Ｆ６０５、Ｆ６０６）。そして債券発行部８３２は、債券が発行された売り主を債権者リストＤ１３３に登録する（Ｆ６０７）。

＜Ｆ２００＞
　次に、図１９を参照して、キャンセル処理Ｆ２００を説明する。ユーザは、自らが出した売買注文をキャンセルすることができる。ユーザは注文アプリ２００の取引履歴部２２０からキャンセルする注文を選び、注文アプリ２００のキャンセル部２１３でキャンセルを実行する（Ｆ２００）。注文アプリ２００のキャンセル部２１３が、キャンセル内容を、ブロックチェーンネットワーク３０に送信する。

　ブロックチェーンネットワーク３０では、スマートコントラクト８００のキャンセル部８１２が、キャンセル可否を確認する（Ｆ２０１）。具体的には、注文の状態が「発注」で約定期限を過ぎていれば、キャンセル可能である（Ｆ２０１でＹＥＳ）。キャンセルが可能であれば、キャンセル部８１２は、注文の状態をキャンセルにし（Ｆ２０２）、注文内容の「買い／売り」を確認し（Ｆ２０３）する。「買い」であれば（Ｆ２０３でＹＥＳ）、送金部８３１が、注文額分を、一時金ウォレットＤ１１１から返金ウォレットＤ１１２に移動する（Ｆ２０４、Ｍ１０３）。最後に、処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知を送る（Ｆ００５）。

＜Ｆ３００＞
　次に、図２０を参照して、返金処理Ｆ３００を説明する。ユーザは、返金されたお金を、返金ウォレットＤ１１２からアカウントウォレットに送金できる（Ｍ１０４）。アカウントウォレットは、アカウント本人が自由に使える仮想通貨が入ったウォレットである。ユーザは、注文アプリ２００の返金部２３０から返金を実行すると、返金内容がブロックチェーンネットワーク３０に送信される。

　ブロックチェーンネットワーク３０では、スマートコントラクト８００の返金部８１３が、返金を処理する（Ｆ３００）。具体的には、返金部８１３は、返金ウォレットＤ１１２の通貨の値を０にし（Ｆ３０１）、返金ウォレットＤ１１２に入っていた通貨分を、ユーザに送金する（Ｆ３０２）。最後に、処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知を送る（Ｆ００５）。

＜Ｆ７００＞
　次に、図２４を参照して、取引所の入金処理Ｆ７００を説明する。取引所は、ユーザからの売り取引に対して、預金ウォレットＤ１３１から売り代金を支払うため、予め預金ウォレットＤ１３１に入金しておくことができる。取引所では、約定アプリ６００の入金額入力部６４１は入金額を入力され、入金送信部６４２が入金額をブロックチェーンネットワーク３０に送信する。

　入金部８２３は仮想通貨の入金を検出する入金検出部である。入金部８２３は仮想通貨の入金を検出した場合、ブロックチェーンネットワーク３０では、スマートコントラクト８００の入金部８２３が、入金された金額を預金ウォレットＤ１３１に格納する（Ｆ７０１，Ｍ３０１）。
　その後、預金額に応じて債権者の債券が回収される（Ｆ９００）。最後に、処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知を送る（Ｆ００５）。

＜Ｆ８００＞
　次に、図２５を参照して、出金処理８００を説明する。取引所は、自分が入金したお金あるいは売買取引によって得られたお金を、引き出すことができる。取引所は、約定アプリ６００の出金額入力部６４３に出金額を入力し、出金送信部６４４で出金額をブロックチェーンネットワーク３０に送信する。

　ブロックチェーンネットワーク３０では、スマートコントラクト８００の出金部８２４が、出金者が対象の取引所かどうか、つまり、出金者がスマートコントラクト８００のオーナーかどうかを確認する（Ｆ８０１）。出金者が対象の取引所とは、出金者がスマートコントラクト８００のオーナーであることを意味する。対象の取引所であれば（Ｆ８０１でＹＥＳ）、出金部８２４は、預金ウォレットＤ１３１から、指定された出金額を引き（Ｆ８０２）、出金額を取引所のアカウントウォレットに送金する（Ｆ８０３）。最後に、処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知を送る（Ｆ００５）。

＜Ｆ８１０＞
　次に、図２６を参照して、取引設定処理Ｆ８１０を説明する。取引所は、取引条件である売買価格と約定期限を設定及び変更できる。取引所は、約定アプリ６００の設定入力部６２１から設定内容を入力し、設定送信部６２２により、設定内容をブロックチェーンネットワーク３０に送信する。

　ブロックチェーンネットワーク３０では、スマートコントラクト８００の取引設定部８２２が、取引設定データＤ１４０の売買価格Ｄ１４１及び約定期限Ｄ１４２を設定する（Ｆ８１１）。最後に処理完了通知部８５０が、注文アプリ２００と約定アプリ６００に、処理完了の通知を送る（Ｆ００５）。

＜Ｆ９００＞
　最後に、図２７を参照して、債権者への返金処理Ｆ９００について説明する。
債権者への返金処理Ｆ９００は債券回収処理である。債券は、債券回収部８３３が、取引所からの入金、または、ユーザの買い取引による支払額に応じて、自動的に回収する。
　債券回収部８３３は、仮想通貨の入金が入金部８２３または送金部８３１によって検出された場合、債券を有する債権者が管理されている債権者リストＤ１３３を参照し、債券の示す金額の少なくとも一部を債権者に返済する。債権者リストＤ１３３は債権者情報である。以下に具体的に説明する。

　債券回収部８３３は、債権者情報である債権者リストＤ１３３から債権者を選択し、選択した債権者に、仮想債券の示す金額の少なくとも一部を返済する（Ｆ９０１からＦ９０５）。
　まず、債券回収部８３３は、入金額または支払額で、一人の債権者が完済されるかを確認する（Ｆ９０１）。完済可能であれば（Ｆ９０１でＹＥＳ）、債券額分のお金を、債券ウォレットＤ１１３から返金ウォレットＤ１１２に移動する（Ｆ９０２、Ｍ１０２）。
　次に、債券回収部８３３は、入金額または支払額から、債券分を差し引き（Ｆ９０３）、債権者リストＤ１３３から債券回収に該当する債権者を外す（Ｆ９０４）。上記で差し引いた額、つまり、入金額または支払額から債券分の金額を引いた額を基に、次の債権者が完済できるかを確認する（Ｆ９０１）。これを繰り返すことで、債券回収部８３３は、自動的に債権者の債券を回収する。

　もし、入金額または支払額で債権者が完済できない場合は（Ｆ９０１でＮＯ）、債券回収部８３３は、入金額または支払額分のお金を債券ウォレットＤ１１３から返金ウォレットＤ１１２に移動し（Ｆ９０５、Ｍ１０７）、債権者への返金処理が完了する。
　ここでは、債権者毎に債券を回収しているが、注文単位で債券を回収してもよい。また、債券の回収順については、債権者として登録された順に、回収していくのが一般的であるが、どのような回収順でも構わない。例えば、過去の利用頻度や支払額が高い順に回収する方法や、優良会員を優先して回収するといった方法が考えられる。

　以上のＦ９００で説明したように、債券回収部８３３は、預金ウォレットへの入金がある場合（Ｆ５０３及びＦ７０１）、この入金を契機として債権者リストＤ１３３に登録されているいずれかの債権者を選択し、入金される入金額と選択した債権者に発行されている債券データの示す金額とを比較する（Ｆ９０１）。債券回収部８３３は、比較の結果、入金額によって債券データの示す金額の少なくとも一部を返済できる場合には、入金された入金額によって、選択した債権者に債券データの示す金額の少なくとも一部を返済する（Ｆ９０２及びＦ９０５）。債券回収の契機となる入金はＦ５０３及びＦ７０１である。これらの預金ウォレットへの入金は、買い主であるユーザから売り主であるユーザへの支払いと（Ｆ５０３）、オーナーによる預金（Ｆ７０１）とのいずれかである。

＊＊＊実施の形態１の効果＊＊＊
取引所が発行した債券は、通常は取引所が後日、債券回収処理を実施することで、ユーザは債券分の通貨を入手できる。しかし、従来では、取引所が債券回収処理をしなければ、ユーザは通貨を得られないという課題があった。
　実施の形態１ではスマートコントラクト８００が通貨を得るタイミング（買い注文のＦ５０３及び、預金の入金のＦ７０１）で、自動的に債券回収処理を実行することで、取引所の意図に関わらず、ユーザは通貨を得ることができる。
債券回収処理は、取引所の意思とは無関係に、買い注文のＦ５０３及び預金の入金のＦ７０１を契機として、自動的に開始する。
　そして、債権者は、他人の取引によって債券を回収できる。つまり、ユーザＵ１が債権者の場合に、ユーザＵ２による買い注文の買い約定が確定し、Ｆ５０３でオーナーの預金ウォレットＤ１３１へ入金があるとする。ユーザＵ２は債権者でなくてもよいし債権者でもよい。スマートコントラクト８００の債券回収部８３３は、ユーザＵ２からの入金を、ユーザＵ１の債券回収に使用することができる。
　以上のように、預金が不足している場合に、債券を発行するようにしているので、以下の効果を得ることができる。
（１）預金が不足することによる取引停止を防止することができる。すなわち、取引の可用性を向上できる。
（２）取引所は、預金不足を懸念して、多めに入金しておく必要がない。すなわち、キャッシュフローの向上を図ることができる。
（３）ユーザの空売り注文による売り取引停止の妨害を防止することができる。すなわち、悪意ある注文を無効化することができる。
また、他ユーザの買い取引や取引所の入金により得られたお金を、強制的に債券回収に使うことで、以下の効果を得ることができる。
（４）ユーザが安心して売り取引を実施することができる。すなわち、取引の信頼性を向上することができる。
（５）取引所は、債権者への返金を気にする必要がない。すなわち、管理負担を軽減することができる。

　図２８は、債券の発行と回収とを具体例で示す。図２８を参照して、債券の発行と回収を具体例で説明する。以下の説明ではユーザＵ１、ユーザＵ２及び取引所が登場する。
＜初期状態＞
初期状態では、以下のようである。
ユーザＵ１のアカウントウォレット：１００円、
返金額：０円、
債券：０円、
支払金０円。
ユーザＵ２のアカウントウォレット：１００円、
返金額：０円、
債券：０円、
支払金０円。
取引所のアカウントウォレット：１００円、
預金額：５０円。

（１）ユーザＵ１がコモディティ１００円分の売り注文を出し、取引所が１００円分を約定した。
（１）の状態は、以下のようである。
ユーザＵ１のアカウントウォレット：１００円、
返金額：５０円（＋５０）、
債券：５０円（＋５０）、
支払金０円。
ユーザＵ２のアカウントウォレット：１００円、
返金額：０円、
債券：０円、
支払金０円。
取引所のアカウントウォレット：１００円、
預金額：－５０円（－１００）。

（２）ユーザＵ２がコモディティ１００円分の買い注文を出した。
（２）の状態は、以下のようである。
ユーザＵ１のアカウントウォレット：１００円、
返金額：５０円、
債券：５０円、
支払金０円。
ユーザＵ２のアカウントウォレット：０円（－１００）、
返金額：０円、
債券：０円、
支払金１００円（＋１００）。
取引所のアカウントウォレット：１００円、
預金額：－５０円。

（３）取引所がユーザＵ２の買い注文１００円分を約定した。
（３）の状態は、以下のようである。
ユーザＵ１のアカウントウォレット：１００円、
返金額：１００円（＋５０）、
債券：０円（－５０）、
支払金０円。
ユーザＵ２のアカウントウォレット：０円、
返金額：０円、
債券：０円、
支払金０円（－１００）。
取引所のアカウントウォレット：１００円、
預金額：５０円（＋１００）。

（４）ユーザＵ１が返金を実行した。
（４）の状態は、以下のようである。
ユーザＵ１のアカウントウォレット：２００円（＋１００）、
返金額：０円（－１００）、
債券：０円、
支払金０円。
ユーザＵ２のアカウントウォレット：０円、
返金額：０円、
債券：０円、
支払金０円。
取引所のアカウントウォレット：１００円、
預金額：５０円。

　ユーザＵ１が１００円分のコモディティを売り、ユーザＵ２が１００円分のコモディティを買った。このため、最終的には、ユーザＵ１のアカウントウォレットが１００円増え、ユーザＵ２のアカウントウォレットが１００円減っており、取引所の変化はない。

　実施の形態２．
　図２９及び図３０を参照して、実施の形態２を説明する。
　図２９は、スマートコントラクト８００のユーザリクエスト受付部８１０が、取引内容の申請を受け付ける申請部８１４を備える構成を示す。
　図３０は、申請部８１４の画面表示を示す。
　以上の実施の形態１に加え、スマートコントラクト８００は、ユーザが取引内容を記録できる申請部８１４を備えても良い。

申請部８１４は、ユーザの注文アプリ２００から取引内容の申請を取得し、取得した前記申請を、電子データである分散台帳であるブロックチェーン７１０に書き込む。申請部８１４は、書込部である。

　図３０は、申請部８１４がユーザ端末１００の表示装置９５２に表示する申請画面を示す。申請部８１４により、ユーザ側で真正な取引量を登録しておけば、取引所の不正を追及することができる。図３０では、ユーザが枠９８１で示す電力３ｋｗｈを取引所に提供したにも関わらず、取引所は枠９８２で示す２ｋｗｈしかもらっていないと記録したことを示す。このため、ユーザには、本来支払ってもらえる額より少ない額が、支払われたことになる。そこで、ユーザが３ｋｗｈの取引があったということを登録し、不正な取引を明らかにすることができる。

　実施の形態３．
　実施の形態２では、ユーザが取引内容を登録することで不正な取引を摘発するが、一つのデータだけでは、ユーザと取引所のどちらが虚偽の取引を登録しているか分からない。そこで、ユーザおよび取引所が安心して取引ができるように、自分以外のユーザとの取引履歴、取引所の預金履歴のような情報を閲覧できる履歴閲覧部２２３を追加しても良い。

　図３１は、注文アプリ２００の取引履歴部２２０が、履歴閲覧部２２３を有する構成を示す。

　自分以外のユーザとの取引履歴は、初めて取引所を利用するユーザにとって、虚偽の申告をしていない取引所なのか、日々どれくらい多くの取引が行われているかといったことを知ることができるため、取引所の信頼性を測るバロメータとなる。
　取引所の預金履歴は、売り取引の際に、どれだけ素早く債券が回収されるのかを知るバロメータとなる。履歴閲覧部２２３は、一つ一つの取引履歴を閲覧することはもちろんのこと、ＥＣサイトのレビューのように、ユーザと取引所の取引内容の齟齬の回数や乖離度等から、定量的に評価するような指標があっても良い。

　実施の形態３によれば、履歴閲覧部２２３により預金履歴及び取引履歴をユーザに示すことにより、ユーザが取引所の信頼度をもとに取引所を選択することができる効果がある。

　実施の形態４．
　実施の形態１では、ユーザと取引所との２者で取引を実施した。スマートコントラクト８００は取引所が作成するため、ユーザは取引所が妥当なスマートコントラクト８００を作成しているのかを評価する必要がある。
しかし、スマートコントラクト８００のプログラムを解読するのは簡単ではないため、妥当なスマートコントラクト８００かどうかの評価は難しい。

　そこで、図３２のように、ブロックチェーンネットワーク３０に取引管理端末９００を設ける。
　図３２は、ブロックチェーンネットワーク３０に接続する取引管理端末９００を示す。
　スマートコントラクト８００は、真正であることが認証されている取引管理装置である取引管理端末９００によって、真正であることが認証されている。すなわち、仮想債券回収プログラムは、取引管理装置である取引管理端末９００によって、真正であることが認証されている

　信頼のある取引管理組織の取引管理端末９００が、スマートコントラクト８００を保証し、スマートコントラクト８００をブロックチェーン７１０に登録する。ユーザ及び取引所は、取引管理端末９００が登録したスマートコントラクト８００を使って、取引を行う。

　スマートコントラクト８００のオーナーは取引管理組織となるため、信頼性のある取引が可能となる。
　また、取引所の不足した預金に対しては、取引所毎に債券を発行しても良いが、取引管理組織が債券を発行することで、取引所単位ではなく、全体の取引単位で債券を回収できる。例えば、ユーザＵ１が取引所１、ユーザＵ２が取引所２でそれぞれ債券を発行された場合、ユーザＵ１が先に債権者になった場合は、取引所２で入金があれば、ユーザＵ１の債券を先に回収することが可能になる。

　１０　ノード、２０　インターネット、３０　ブロックチェーンネットワーク、１００　ユーザ端末、２００　注文アプリ、２１０　注文部、２１１　注文入力部、２１２　注文送信部、２１３　キャンセル部、２２０　取引履歴部、２２１　取引履歴取得部、２２２　取引履歴表示部、２２３　履歴閲覧部、２３０　返金部、３００　ブロックチェーンクライアント、４００　取引所端末、５００　スマートコントラクト作成部、６００　約定アプリ、６１０　約定部、６１１　注文取得部、６１２　約定入力部、６１３　約定送信部、６２０　取引設定部、６２１　設定入力部、６２２　設定送信部、６３０　取引履歴部、６３１　取引履歴取得部、６３２　取引履歴表示部、６４０　預金部、６４１　入金額入力部、６４２　入金送信部、６４３　出金額入力部、６４４　出金送信部、７００　ブロックチェーンクライアント、７１０　ブロックチェーン、８００　スマートコントラクト、８１０　ユーザリクエスト受付部、８１１　注文部、８１１Ａ　アカウント登録部、８１１Ｂ　注文登録部、８１２　キャンセル部、８１３　返金部、８１４　申請部、８２０　取引所リクエスト受付部、８２１　約定部、８２２　取引設定部、８２３　入金部、８２４　出金部、８３０　決済部、８３１　送金部、８３２　債券発行部、８３３　債券回収部、８４０　取引履歴出力部、８５０　処理完了通知部、９００　取引管理端末、９１０　ブロックチェーンクライアント、９２０　プロセッサ、９３０　主記憶装置、９４０　補助記憶装置、９５０　入出力インタフェース、９５１　入力装置、９５２　表示装置、９６０　ネットワークインタフェース、９７０　信号線、９８１，９８２　枠、Ｄ１００　データ、Ｄ１１０　管理データ、Ｄ１１１　一時金ウォレット、Ｄ１１２　返金ウォレット、Ｄ１１３　債券ウォレット、Ｄ１１４　取引履歴、Ｄ１３０　取引所用管理データ、Ｄ１３１　預金ウォレット、Ｄ１３２　ユーザリスト、Ｄ１３３　債権者リスト、Ｄ１４０　取引設定データ、Ｄ１４１　売買価格、Ｄ１４２　約定期限。

Claims

　仮想通貨の入金を検出する入金検出部と、
　前記仮想通貨の入金が検出された場合に、電子データである仮想債券を有する債権者が管理されている債権者情報を参照し、前記仮想債券の示す金額の少なくとも一部を前記債権者に返済する債券回収部と、
を備える仮想債券回収装置。
　前記入金検出部は、
　前記仮想通貨の前記入金として、買い主が売り主へ支払う仮想通貨の入金と、仮想通貨の預金のための仮想通貨の入金とを検出する請求項１に記載の仮想債券回収装置。
　前記債券回収部は、
　前記債権者情報から前記債権者を選択し、選択した前記債権者に、前記仮想債券の示す金額の少なくとも一部を返済する請求項１または請求項２に記載の仮想債券回収装置。
　前記仮想債券回収装置は、さらに、
　買い主から売り主に支払うべき支払額を示す支払額データと、前記買い主の有する預金額を示す預金データとを比較し、比較結果に基づいて前記仮想債券を前記売り主に発行し、前記債券が発行された前記売り主を前記債権者情報に登録する債券発行部を備える請求項１から請求項３のいずれか一項に記載の仮想債券回収装置。
　前記仮想債券回収装置は、さらに、
　ユーザから取引内容の申請を取得し、取得した前記申請を電子データである分散台帳に書き込む書込部を備える請求項１から請求項４のいずれか１項に記載の仮想債券回収装置。
　コンピュータに、
　仮想通貨の入金を検出する入金検出処理と、
　前記仮想通貨の入金が検出された場合に、電子データである仮想債券を有する債権者が管理されている債権者情報を参照し、前記仮想債券の示す金額の少なくとも一部を前記債権者に返済する仮想債券回収処理と、
を実行させるための仮想債券回収プログラム。
　前記仮想債券回収プログラムは、
　取引を管理する取引管理装置によって、真正であることが認証されている請求項６に記載の仮想債券回収プログラム。
　コンピュータが、
　仮想通貨の入金を検出し、
　前記仮想通貨の入金が検出された場合に、電子データである仮想債券を有する債権者が管理されている債権者情報を参照し、前記仮想債券の示す金額の少なくとも一部を前記債権者に返済する、
仮想債券回収方法。