JP7308618B2 - 仮想通貨管理方法 - Google Patents

Description

特許法第３０条第２項適用 「ＦｉｎｔｅｃｈＣｈａｌｌｅｎｇｅ ２０１８」のハッカソン（成果発表会）、平成３０年３月３日

本発明は、仮想通貨を管理する技術に関し、特に、ブロックチェーンで管理される仮想通貨の送金先を限定する技術に関するものである。

近年、ブロックチェーンで管理される仮想通貨が提案されている（非特許文献１）。そして、コストの低減や利便性の高さといった効果が期待できる仮想通貨を用いた具体的なサービスがハッカソンや実証実験などを通じて検討されている（非特許文献２）。

具体的なサービスは、様々提案されており、例えば、非特許文献２にはマイナー競技のアスリートなど、競技団体からの報奨金が少ない選手を応援したいという人の気持ちをブロックチェーンに載せるというコンセプトで、アスリートの中にチャレンジ達成者が現れて、クラウド投票により達成したことが認定された際に、スマートコントラクトが作動してコインが対象者に支払われるという仕組みが提案されている。

MUFGレポート 2017 経営陣からのメッセージ「デジタルストラテジー」https://www.mufg.jp/ir2017/message/digital_strategy/ MUFG INNOVATIONHUB「MUFGコインハッカソン "Fintech Challenge 2018" の大賞は『イノベーションのための報奨金プラットフォーム』！」https://innovation.mufg.jp/detail/id=247

仮想通貨を用いた具体的なサービスとして、仮想通貨の送金先や用途を限定するものが考えられる。たとえば、学生に対する奨学金を仮想通貨によって支給することを想定した場合、支給された奨学金を学生が浪費しないように、仮想通貨を使用可能な店舗を限定することが望ましい。あるいは、別の例として、地域振興や商品キャンペーンなどのために仮想通貨を発行する場合、その発行した仮想通貨は、地域や期間限定で使用できるものであることが求められる。

本発明はこのような課題に鑑みてなされたものであり、ブロックチェーンで管理される仮想通貨の送金先を限定することを目的とする。

かかる目的を達成するために、請求項１記載の発明は、アカウント識別情報および前記アカウント識別情報によって識別されるアカウントに係る仮想通貨の残高情報を管理するアカウント残高テーブルと、送金可能アカウント識別情報を管理する送金可能アカウントテーブルとを記憶するＤＢと、第１のアカウント識別情報、第２のアカウント識別情報、および、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額を含む取引情報を記憶するブロックチェーンと、を備える第１のコンピュータに接続する第２のコンピュータに、ユーザのアカウント識別情報を取得する第１のステップと、ユーザの端末において入力された送金先アカウント識別情報と、仮想通貨の送金額とを取得する第２のステップと、前記ユーザのアカウント識別情報を第１のアカウント識別情報とし、前記送金先口座識別情報を第２のアカウント識別情報とし、前記仮想通貨の送金額を、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額とする取引を実行する命令を前記第１のコンピュータに送信する第３のステップと、を実行させる仮想通貨送金方法であって、前記命令は、前記仮想通貨の送金額が、前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下であり、前記第２のアカウント識別情報が前記送金可能アカウント識別情報と一致する場合に前記第１のコンピュータによって実行されることを特徴とする。

請求項２記載の発明は、請求項１記載の発明において、前記ＤＢと前記ブロックチェーンとが用途情報ごとに管理され、前記第１のステップで、用途指定情報をさらに取得し、前記第３のステップで、前記用途指定情報を前記第１のコンピュータにさらに送信し、前記命令は、前記用途指定情報と一致する前記用途情報に係る前記ＤＢと前記ブロックチェーンとを備える前記第１のコンピュータによって実行されるものであって、前記仮想通貨の送金額が、前記ＤＢに記憶された前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下であり、前記第２のアカウント識別情報が、前記ＤＢに記憶された前記送金可能アカウント識別情報と一致する場合に前記第１のコンピュータによって実行されることを特徴とする。

請求項３記載の発明は、請求項２記載の発明において、前記送金可能アカウントテーブルが、条件情報をさらに管理し、前記第２のステップで、前記ユーザの端末のコンテキスト情報をさらに取得し、前記第３のステップで、前記コンテキスト情報を第１のコンピュータにさらに送信し、前記命令は、前記コンテキスト情報が、前記送金可能アカウント識別情報に対応する前記条件情報に係る条件をさらに満たす場合に実行されることを特徴とする。

請求項４記載の発明は、アカウント識別情報および前記アカウント識別情報によって識別されるアカウントに係る仮想通貨の残高情報を管理するアカウント残高テーブルを記憶する第１のＤＢと、第１のアカウント識別情報、第２のアカウント識別情報、および、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額を含む取引情報を記憶するブロックチェーンと、を備える第１のコンピュータに接続し、送金可能アカウント識別情報を管理する送金可能アカウントテーブルを記憶する第２のＤＢを備える第２のコンピュータに、ユーザのアカウント識別情報を取得する第１のステップと、ユーザの端末において入力された送金先アカウント識別情報と、仮想通貨の送金額とを取得する第２のステップと、前記ユーザのアカウント識別情報を第１のアカウント識別情報とし、前記送金先口座識別情報を第２のアカウント識別情報とし、前記仮想通貨の送金額を、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額とする取引を実行する命令を前記第１のコンピュータに送信する第３のステップと、を実行させる仮想通貨送金方法であって、前記第３のステップは、前記送金先口座識別情報が前記送金可能アカウント識別情報と一致する場合に実行され、前記命令は、前記仮想通貨の送金額が、前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下である場合に前記第１のコンピュータによって実行されることを特徴とする。

請求項５記載の発明は、請求項４記載の発明において、前記第１のＤＢと前記ブロックチェーンとが用途情報ごとに管理され、送金可能アカウントテーブルが、前記用途情報をさらに管理し、前記第１のステップで、用途指定情報をさらに取得し、前記第３のステップで、前記用途指定情報を前記第１のコンピュータにさらに送信し、前記第３のステップは、前記用途指定情報が前記用途情報に一致し、かつ、前記送金先口座識別情報が前記送金可能アカウント識別情報に一致するレコードが前記送金可能アカウントテーブルに存在する場合に実行され、前記命令は、前記用途指定情報と一致する前記用途情報に係る前記ＤＢと前記ブロックチェーンとを備える前記第１のコンピュータによって実行されるものであって、前記仮想通貨の送金額が、前記ＤＢに記憶された前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下である場合に前記第１のコンピュータによって実行されることを特徴とする。

請求項６記載の発明は、請求項５記載の発明において、前記送金可能アカウントテーブルが、条件情報をさらに管理し、前記第２のステップで、前記ユーザの端末のコンテキスト情報をさらに取得し、前記第３のステップは、前記コンテキスト情報が、前記レコードに対応する前記条件情報に係る条件をさらに満たす場合に実行されることを特徴とする。

請求項７記載の発明は、請求項１ないし６記載の発明において、前記ユーザのアカウント識別情報が、前記ユーザの端末において入力されたユーザ識別情報に基づいて取得されることを特徴とする。

請求項８記載の発明は、請求項７記載の発明において、前記ユーザ識別情報と、金融機関の口座管理システムが管理する口座識別情報とが、前記口座管理システムによって対応付けられていることを特徴とする。

請求項９記載の発明は、請求項１ないし８に記載の発明において、前記送金可能口座識別情報によって識別される口座の名義人ないし管理者に係るユーザ識別情報と、金融機関の口座管理システムが管理する口座識別情報とが、前記口座管理システムによって対応付けられていることを特徴とする。

本発明に係る仮想通貨送金方法によれば、ブロックチェーンで管理される仮想通貨の送金先を限定できる。

本発明の一実施の形態である仮想通貨管理方法を備えたシステムの構成例について概要を示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成するユーザ端末１の画面例について概要を示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成するステートＤＢ７のテーブル構成例を示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成するユーザ管理ＤＢ１１のテーブル構成例を示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成する口座管理システムが管理する口座ＤＢ１４のテーブル構成例を示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムのログイン操作受付から残高表示までの処理シーケンスを示す図である。 本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムの送金操作受付から送金処理結果受信までの処理シーケンスを示す図である。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。なお、本発明は多くの異なる形態で実施可能であり、以下に開示する記載内容のみに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

以下に示す本発明の仮想通貨送金方法は、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理、手段、機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を実行させることができる。すなわち、本発明における各処理や手段、機能は、プログラムとコンピュータとが共働した具体的手段によって実現される。プログラムの全部又は一部は、例えば、磁気ディスク、光ディスク、半導体メモリ、その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされ実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。また、本発明に係る仮想通貨送金方法は、単一の情報処理装置（例えば１台のパーソナルコンピュータ等）で構成することもでき、複数の情報処理装置（例えば複数台のサーバコンピュータ群等）で構成することもできる。なお、下記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではなく、実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

図１に、本発明の一実施の形態に係る仮想通貨送金方法を実行するシステム構成を示す。
同図に示す本発明の一実施に形態に係る仮想通貨送金方法を実行するシステムは、仮想通貨管理アプリ（図示せず）を備えた一又は二以上のユーザ端末１（１Ａ、１Ｂ、１Ｃ・・・１Ｎ、以下単にユーザ端末１とする）、コンピュータ２、ブロックチェーンネットワーク５を構成する二以上のコンピュータ６（６Ａ、６Ｂ、６Ｃ・・・６Ｎ、以下単にコンピュータ６とする）、ゲートウェイシステム１０、および、金融機関が管理する口座管理システム１３を備えたシステムとして構成されている。これらは、例えばインターネット等の所定のネットワーク１６を介して、相互にデータ通信可能に接続されている。
なお、ログイン処理をコンピュータ２又は口座管理システム１３が行う場合は、ゲートウェイシステム１０を省略できる。また、金融機関口座確認処理を行わない場合は、口座管理システム１３を省略できる。

ユーザ端末１は、仮想通貨を送金するユーザが操作する端末であり、例えばパーソナルコンピュータや専用端末装置、携帯端末、スマートフォン、ウェアラブル端末等であり、出力装置（例えばディスプレイ等）、入力装置（例えばキーボード、マウス等）を備える。ユーザ端末１は、コンピュータ２、ゲートウェイシステム１０、および、口座管理システム１３とデータ通信可能に接続され、ユーザ端末１において図示しない仮想通貨管理アプリが実装されている。各ユーザがユーザ端末１を操作することで、図示しない仮想通貨管理アプリを介して、本発明に係るシステムで提供される機能を実行することができる。仮想通貨アプリは、ユーザ端末１で実行されても良いし、ユーザ端末１を単なるビューア（ブラウザ）として機能させて、コンピュータ２やゲートウェイシステム１０で実行されても良い。

コンピュータ２は、残高要求・送信部３と送金処理部４を備え、例えば一又は二以上のサーバコンピュータや、クラウドコンピューティングサービス上に構成された一又は二以上の仮想サーバからなるサーバシステム等の情報処理装置によって構成することができる。

コンピュータ６は、ブロックチェーンネットワーク５を構成するコンピュータである。本実施の形態では、ＨｙｐｅｒＬｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃをプラットフォームとし、仮想通貨は、用途が限定されているものとする。ブロックチェーンネットワーク内に作られた仮想ネットワークであるチャネルが用途毎に設けられ、コンピュータ６は、チャネル毎にステートＤＢ７Ｎ（Ｎ＝１，２，…，ｎ、以下単にステートＤＢ７とする）と、ブロックチェーン８Ｎ（Ｎ＝１，２，…，ｎ、以下単にブロックチェーン８とする）とを備える。ステートＤＢは、Ｇｏｏｇｌｅ社がオープンソースとして公開したＫｅｙ－Ｖaｌｕｅ型データストアのライブラリであるＬｅｖｅｌＤＢで実装して、処理速度を高速なものとしても良いし、ＡｐａｃｈｅのＮｏＳＱＬデータベースであるＣｏａｃｈＤＢで実装して、データ構造が自由なドキュメントとしてデータを保存しても良い。また、コンピュータ６は、チェーンコード実行部９を備える。チャネル機能を使用しない場合は、Ａｃｃｏｕｎｔ Ｓtａtｅとブロックチェーンを備えるＥｔｈｅｒｅｕｍをブロックチェーンプラットフォームとしても良いし、ステートＤＢと同様の内容を管理するＤＢとブロックチェーンを備える他のブロックチェーンプラットフォームとしても良い。また、ステートＤＢ７と同様の内容を管理するＤＢをコンピュータ２やゲートウェイシステム１０が備えるようにしても良く、この場合、ステートＤＢを備えないブロックチェーンプラットフォームを採用しても良い。また、ブロックチェーン上の取引履歴から、後述するアカウント残高テーブル３１が管理するアカウントＩＤに対応する残高を計算する場合も、ステートＤＢを備えないブロックチェーンプラットフォームを採用しても良い。

ゲートウェイシステム１０は、ユーザ管理ＤＢ１１と、ログイン処理部１２とを備える。ユーザ管理ＤＢ１１と、ログイン処理部１２とは、コンピュータ２又は口座管理システム１３が備えるようにしても良い。

口座管理システム１３は、金融機関が管理するシステムで、口座ＤＢ１４と、口座確認処理部１５とを備える。

ネットワーク１６は、有線ネットワークまたは無線ネットワークもしくはそれらの組み合わせを含み、インターネット、イントラネット、ＬＡＮ、ＷＡＮ、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線電話網などを含んでも良い。

次に、以上のような構成からなる本実施の形態に係る仮想通貨管理方法を備えるシステムの具体的な構成や処理について、図２～図７を参照しつつ説明する。

図２は、本実施の形態における仮想通貨管理方法を備えたシステムを構成するユーザ端末１に表示される画面の一例を示す図である。
以下に示す動作は、ユーザ端末１によって仮想通貨アプリが実行されることによって行われる。

まず、ユーザは、ユーザ端末１を操作して、仮想通貨アプリを起動する（図示せず）。起動後表示されるログイン画面 ２１（図２ａ）において、ユーザが、例えば自己に割り当てられたユーザＩＤやパスワードを入力し、「ログイン」ボタン２１１を押すことによって、ログイン要求がゲートウェイシステム１０に送信される。ゲートウェイシステム１０によってログイン要求に含まれるユーザＩＤとパスワードが認証され、また、口座管理システム１３によってユーザＩＤに対応する金融機関口座の存在が確認されると、ゲートウェイシステム１０から仮想通貨を管理するためのアカウントＩＤがユーザ端末１に送信され、ユーザは、仮想通貨アプリにログインすることができる。アカウントＩＤは仮想通貨の用途ごとにユーザに割り振られている。ユーザが複数用途の仮想通貨を仮想通貨アプリで管理する場合、複数のアカウントＩＤがユーザ端末１に送信される。なお、アカウントＩＤは、ログイン要求のつどゲートウェイシステム１０からユーザ端末１に送信されるのではなく、ユーザ端末１にインストールされた仮想通貨アプリにおいて予め設定されていても良い。また、ユーザＩＤやパスワードをユーザ端末１にインストールされた仮想通貨アプリにおいて予め設定しておき、ログイン要求をゲートウェイシステム１０に送信せずに、仮想管理アプリがユーザＩＤやパスワードを認証しても良い。また、金融機関口座の存在を確認せずにユーザにログインを許可しても良い。

仮想通貨アプリにログインしたユーザ端末１には、例えば用途選択画面２２（図２ｂ）が表示される。用途選択画面２２において、ユーザは、仮想通貨の用途を選択する。なお、仮想通貨は用途が限定されなくてもよく、その場合は、用途選択画面２２は表示されず、一意に定まるユーザのアカウントＩＤに紐付く口座の仮想通貨残高などが表示される残高画面２３（図２ｃ）が表示される。

用途選択画面２２において、用途が選択されると、選択された用途と、選択された用途によって一意に定まるユーザのアカウントＩＤとが、コンピュータ２に送信される。コンピュータ２は、受信した用途に対応するチャネルに属するコンピュータ６に対して、ユーザのアカウントＩＤによって特定される仮想通貨残高を要求する。チャネル機能を利用しない場合、コンピュータ２は、いずれかのコンピュータ６に対して、ユーザのアカウントＩＤによって特定される仮想通貨残高を要求する。コンピュータ２は、コンピュータ６から残高を受信すると、ユーザ端末１に残高を送信する。ユーザ端末１は、受信した残高を、残高画面２３を表示する。なお、仮想通貨の用途が限定されていない場合は、一意に定まるユーザのアカウントＩＤによって特定される仮想通貨の残高が残高画面２３に表示される。

残高画面２３では、選択された用途に係る仮想通貨の残高とともに、所定期間（図２ｃでは、２０１８／９／１８～２０１８／１０／１７）における仮想通貨使用履歴が表示される。仮想通貨使用履歴として、仮想通貨を使用した店舗、仮想通貨を使用して購入した商品、使用した仮想通貨の額が表示される。また、ユーザが「送金」ボタン２３１を押すことで、送金画面２４（図２ｄ）が表示される。

送金画面２４では、ユーザは、「支払先」領域２４１から支払先を選択でき、また「数量」領域２４２で送金する仮想通貨額（量）を指定することができる。仮想通貨の用途が限定されている場合、「支払先」領域２４１から選択できる支払先は、用途ごとに異なる。また、ユーザが「送金」ボタン２４３を押すことで、送金要求がユーザ端末１からコンピュータ２に送信される。支払先の選択は、一般に行われているのと同様に、送金先の指定として、ＱＲコードで行っても良い。

図３は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成するステートＤＢ７のテーブル構成例を示す図である。
ステートＤＢ７では、アカウント残高テーブル３１（図３ａ）と、送金可能アカウントテーブル３２（図３ｂ）がチャネル毎（用途毎）に管理される。用途が限定されない仮想通貨の場合は、ステートＤＢ７の内容はいずれのコンピュータ６かを問わず共通である。

アカウント残高テーブル３１は、アカウント毎に、アカウントを識別するための「アカウントＩＤ」、および、仮想通貨の「残高」を管理する。
なお、図示しないが、チャネル機能を利用しなくても良く、その場合は、アカウント残高テーブル３１が、アカウント毎にアカウントを識別するための「アカウントＩＤ」、および、仮想通貨の「用途」「残高」を管理する。ステートＤＢをＬｅｖｅｌＤＢで実装する場合、「アカウントＩＤ」をＫｅｙ、「用途」と「残高」の組をＶaｌｕｅとする。

送金可能アカウントテーブル３２は、仮想通貨の送金先とすることができる仮想通貨アカウント（以下、「送金可能アカウント」という）毎に、送金可能アカウントを識別するための「アカウントＩＤ」と、チェーンコード実行部９によって送金処理のための取引が実行されるための「条件」を管理する。「条件」では、たとえば、ユーザ端末１の位置情報が満たすべき地理的範囲や、送金処理日が満たすべき時間的範囲などを管理する。仮想通貨アプリの送金画面２４における「支払先」領域２４１には、仮想通貨アプリの用途選択画面２２において選択された用途に対応するチャネルで管理される送金可能アカウントテーブル３２に記憶されたアカウントＩＤに紐付く送金可能アカウントすべてを表示しても良いし、さらにユーザ端末１の位置情報や送金処理日が満たす条件に対応するアカウントＩＤに紐づく送金可能アカウントのみを表示しても良い。一般に、ブロックチェーン上の仮想通貨の送金先の特定は、アカウントＩＤを表すＱＲコードを読み取ることで行われているが、これは、本発明のアカウント残高テーブル３１に相当するテーブルのみがブロックチェーン上で管理されており、そのテーブルに記憶されているアカウントＩＤが無数にあるため、本発明の「支払先」領域２４１のようなインターフェースで送金先の候補を表示するのが難しいことがひとつの技術的要因になっている。本発明では、アカウント残高テーブル３１とは別に送金可能アカウントテーブル３２を設けたために、アカウントＩＤが所定の数に限定したかたちで、「支払先」領域２４１に所定の数のアカウントＩＤを支払先の候補として表示することができる。さらにチャネル機能によって用途を限定して、用途毎に送金可能アカウントテーブル３２の内容を管理することによって、送金可能アカウントテーブル３２を検索して「支払先」領域２４１に表示する送金先の候補の数を限定し、表示処理の速度を上げることができる。
なお、図示しないが、チャネル機能を利用しなくても良く、その場合は、送金可能アカウントテーブル３２が、送金可能アカウント毎に送金可能アカウントを識別するための「アカウントＩＤ」、および、仮想通貨の「用途」「条件」を管理する。ステートＤＢをＬｅｖｅｌＤＢで実装する場合、「アカウントＩＤ」をＫｅｙ、「用途」と「条件」の組をＶaｌｕｅとする。

図４は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成するユーザ管理ＤＢ１１のテーブル構成例を示す図である。
ユーザ管理ＤＢ１１では、認証テーブル４１（図４ａ）と、ユーザテーブル４２（図４ｂ）と、クライアントテーブル４３（図４ｃ）とが管理される。

認証テーブル４１は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを利用するユーザ毎に、電子メールアドレスなど、ユーザを識別するための「ユーザＩＤ」と「パスワード」を管理する。なお、たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、認証テーブル４１を省略することができる。

ユーザテーブル４２は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを利用するユーザ毎に、電子メールアドレスなど、口座管理システム１３がユーザを識別するための「ユーザＩＤ」と、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステム内でユーザを識別するための「クライアントＩＤ」を管理する。

クライアントテーブル４３は、「クライアントＩＤ」「用途」「アカウントＩＤ」を管理する。「クライアントＩＤ」「用途」によって「アカウントＩＤ」が一意に定まる。
ユーザテーブル４２を省略し、クライアントテーブル４３が、「ユーザＩＤ」「アカウントＩＤ」「用途」を管理しても良い。

なお、認証テーブル４１、ユーザテーブル４２、およびクライアントテーブル４３では、ユーザ端末１を操作して仮想通貨を送金するユーザだけではなく、商品やサービスに対する対価として仮想通貨を受け取る店舗や企業などの仮想通貨口座の名義人や管理者も管理しても良い。

図５は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムを構成する口座管理システムが管理する口座ＤＢ１４のテーブル構成例を示す図である。

口座ＤＢ１４のテーブルは、金融機関に口座を開設しているユーザ毎に、「金融機関口座ＩＤ」と「ユーザＩＤ」を管理する。なお、たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム９ではなく口座管理システム１３が認証処理を行う場合は、口座ＤＢ１４のテーブルが、「パスワード」をさらに管理しても良い。

図６は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムのログイン操作受付から残高表示までの処理シーケンスを示す図である。

まず、ユーザがユーザ端末１において仮想通貨アプリを起動すると、ユーザＩＤとパスワードを入力するためのログイン画面２１がユーザ端末１に表示される（Ｓ６０１ログイン操作受付）。なお、たとえば、ＯｐｅｎＩＤなどの認証プロトコルを使ってゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、ログイン画面２１でユーザＩＤとパスワードに加えて、口座管理システム１３で認証を受ける旨の情報をユーザに入力させても良い。ＳＡＭＬなどの認証プロトコルを使って口座管理システム１３が認証処理を行う場合は、ログイン画面２１に替えて、口座管理システム１３で認証を受けることを了解する旨の情報をユーザが入力する画面をはじめに表示し、その後、口座管理システム１３で認証を受けることを了解する旨のユーザが入力した情報を受信したゲートウェイシステム１０が口座管理システム１３にセッションをリダイレクトして、口座管理システム１３がログイン画面２１を表示してもよい。

ユーザが、ユーザＩＤとパスワードを入力し、ログインボタン２１１を押すと、ユーザＩＤとパスワードを含むログイン要求がゲートウェイシステム１０に送信される（Ｓ６０２ログイン要求送信）。なお、たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、ログイン要求はゲートウェイシステム１０ではなく口座管理システム１３に送信される。

ゲートウェイシステム１０がログイン要求を受信すると（Ｓ６０３ログイン要求受信）、ログイン要求に含まれるユーザＩＤとパスワードの組が認証テーブル４１で管理されるレコードに含まれているかを確認する（Ｓ６０４認証処理）。なお、たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、口座管理システム１３が、ログイン要求に含まれるユーザＩＤとパスワードの組が口座ＤＢ１４のテーブルで管理されるレコードに含まれているかを確認する。

ユーザＩＤとパスワードの組が認証テーブル４１で管理されるレコードに含まれていることを確認すると、ゲートウェイシステム１０は、口座管理システム１３に対して、ユーザＩＤを含む金融機関口座確認要求を送信し（Ｓ６０５金融機関口座確認要求送信）、口座管理システム１３は、これを受信する（Ｓ６０６金融機関口座確認要求受信）。たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、Ｓ６０５とＳ６０６の処理を省略することができる。

口座管理システム１３は、金融機関口座確認要求を受信すると（Ｓ６０６金融機関口座確認要求受信）、金融機関口座確認要求に含まれるユーザＩＤが、口座ＤＢ１４のテーブルで管理されるレコードのいずれかのユーザＩＤと一致するかを確認する（Ｓ６０７金融機関口座確認処理）。

口座管理システム１３は、金融機関口座確認要求に含まれるユーザＩＤが、口座ＤＢ１４のテーブルで管理されるレコードのいずれかのユーザＩＤと一致するかを確認すると、その結果を送信し（Ｓ６０８金融機関口座確認結果送信）、ゲートウェイシステム１０が受信する（Ｓ６０９金融機関口座確認結果受信）。

金融機関口座の存在確認は、マネーロンダリングなどを防止するために有効な顧客確認（Ｋｎｏｗ Ｙｏｕｒ Ｃｕｓｔｏｍｅｒ（ＫＹＣ））をするためのものである。顧客確認の必要がない場合、または、必要があったとしても別の手段で解決する場合は、Ｓ６０５からＳ６０９までの処理を省略しても良い。

ゲートウェイシステム１０は、受信した金融機関口座確認結果が肯定的であった場合、ユーザテーブル４２からそのユーザＩＤに対応するクライアントＩＤを取得し（Ｓ６１０クライアントＩＤ取得）、クライアントテーブル４３から取得したクライアントＩＤに対応する用途とアカウントＩＤの組をユーザ端末１に送信する（Ｓ６１１用途・アカウントＩＤ送信）。なお、仮想通貨アプリが用途とアカウントＩＤを管理している場合、Ｓ６１０とＳ６１１の処理を省略し、金融機関口座確認結果が肯定的であった旨のみをユーザ端末１に送信しても良い。また、Ｓ６０５からＳ６０９までの処理を省略する場合、ゲートウェイシステム１０は、Ｓ６０４の確認結果が肯定的であった場合にユーザテーブル４２からそのユーザＩＤに対応するクライアントＩＤを取得し、取得したクライアントＩＤに対応する用途とアカウントＩＤの組をユーザ端末１に送信する。また、たとえば、ＯｐｅｎＩＤやＳＡＭＬなどの認証プロトコルを使って、ゲートウェイシステム１０ではなく口座管理システム１３が認証処理を行う場合は、Ｓ６０９の処理を省略し、口座管理システム１３が、クライアントテーブル４３と同様の内容のテーブルであって「クライアントＩＤ」を「ユーザＩＤ」に置換したものを管理し、Ｓ６１０とＳ６１１の処理を行っても良い。

ユーザ端末１が用途とアカウントＩＤを受信すると（Ｓ６１２用途・アカウントＩＤ受信）、用途選択画面２２がユーザ端末１に表示される。そして、ユーザが用途選択画面２２で仮想通貨の用途を選択すると（Ｓ６１３用途受付）、ユーザ端末１は、コンピュータ２に対して、アカウントＩＤと選択された用途の他、ユーザ端末１の位置情報などのコンテキスト情報を送信する（Ｓ６１４アカウントＩＤ・用途・コンテキスト情報送信）。なお、ユーザ端末１の位置などによって仮想通貨アプリの送金画面２４における「支払先」領域２４１に表示する送金可能アカウントを変えない場合や、仮想通貨の送信可否を制御しない場合は、コンテキスト情報は送信しなくても良い。また、用途選択画面２２でユーザが選択できる仮想通貨の用途は、本発明の一実施の形態である仮想通貨管理方法を備えたシステムの管理者が一元的に設定しても良いし、ユーザが自由に設定し、用途を識別する情報を送受信するなどして、他のユーザと共有しても良い。

コンピュータ２がアカウントＩＤ、選択された用途、およびコンテキスト情報を受信すると（Ｓ６１５アカウントＩＤ・用途・コンテキスト情報受信）、コンピュータ２は、受信した用途に対応するチャネルに属するコンピュータ６に対してアカウントＩＤとコンテキスト情報を送信する（Ｓ６１６残高要求送信）。チャネル機能によって用途の限定を実現せずに、アカウント残高テーブル３１が、「アカウントＩＤ」、「用途」、および「残高」を管理し、送金可能アカウントテーブル３２が、「アカウントＩＤ」、「用途」、および「条件」を管理する場合は、アカウントＩＤと用途を含む残高要求を、ブロックチェーンネットワーク５を構成するコンピュータ６のいずれかに対して送信する。

コンピュータ６が残高要求を受信すると（Ｓ６１７残高要求受信）、コンピュータ６は、アカウント残高テーブル３１から、残高要求に含まれるアカウントＩＤに対応する残高を取得し（Ｓ６１８残高取得）、コンピュータ２に対して送信する（Ｓ６１９残高送信）。チャネル機能によって用途の限定を実現せずに、アカウント残高テーブル３１が、「アカウントＩＤ」、「用途」、および「残高」を管理し、送金可能アカウントテーブル３２が、「アカウントＩＤ」、「用途」、および「条件」を管理する場合は、コンピュータ６は、アカウント残高テーブル３１から、残高要求に含まれるアカウントＩＤと用途の組に対応する残高を取得し（Ｓ６１８残高取得）、コンピュータ２に対して送信する（Ｓ６１９残高送信）。なお、ブロックチェーンプラットフォームとしてステートＤＢを備えないものを採用する場合は、アカウント残高テーブル３１を省略し、ブロックチェーン８で管理される取引履歴を使って、残高要求に含まれるアカウントＩＤと用途の組に対応する残高を計算する。また、アカウント残高テーブル３１をコンピュータ６が備える場合は、Ｓ６１６とＳ６１７を省略し、コンピュータ６がＳ６１８とＳ６１９を実行する。

コンピュータ２は、残高を受信すると（Ｓ６２０残高受信）、ユーザ端末１にその残高を送信する（Ｓ６２１残高送信）。アカウント残高テーブル３１をコンピュータ２が備える場合は、Ｓ６１６、Ｓ６１７、およびＳ６２０を省略し、コンピュータ２がＳ６１８、Ｓ６１９、およびＳ６２１を実行する。

ユーザ端末１が残高を受信すると（Ｓ６２２残高受信）、残高画面２３がユーザ端末１に表示される（Ｓ６２３残高表示）。

図７は、本発明の一実施の形態に係る仮想通貨管理方法を備えたシステムの送金操作受付から送金処理結果受信までの処理シーケンスを示す図である。

ユーザが、ユーザ端末１に表示された残高画面 ２３で「送金」２３１ボタンを押すと、送金画面 ２４がユーザ端末１に表示される（Ｓ７０１送金操作受付）。

ユーザが、ユーザ端末１に表示された送金画面 ２４で、「支払先」領域２４１から支払先を選択して、「数量」領域２４２で送金する仮想通貨額（量）を指定し、「送金」ボタン２４３を押すと、アカウントＩＤ、用途、選択された支払先、指定された送金する仮想通貨額（量）、および、ユーザ端末１の位置情報などを含む送金要求がユーザ端末１からコンピュータ２に送信される（Ｓ７０２送金要求送信）。なお、ユーザ端末１の位置などによって仮想通貨の送信可否を制御しない場合や、Ｓ６１４でコンピュータ２に送信されたコンテキスト情報を流用する場合は、位置情報などを送金要求に含めなくても良い。

コンピュータ２は、送金要求を受信すると（Ｓ７０３送金要求受信）、送金要求に含まれるアカウントＩＤを「送金元」、送金要求に含まれる選択された支払先を「送金先」、送金要求に含まれる指定された送金する仮想通貨額（量）を「送金額」、ユーザ端末１の位置情報などを「コンテキスト情報」とする取引データを生成する（Ｓ７０４取引生成）。なお、ユーザ端末１の位置などによって仮想通貨の送信可否を制御しない場合は、「コンテキスト情報」を取引データに含めなくても良い。また、チャネル機能によって用途の限定を実現せずに、アカウント残高テーブル３１が、「アカウントＩＤ」、「用途」、および「残高」を管理し、送金可能アカウントテーブル３２が、「アカウントＩＤ」、「用途」、および「条件」を管理する場合は、送金要求に含まれる用途を「用途指指定情報」として取引データに含める。

コンピュータ２は、送金要求に含まれる用途に対応するチャネルに属するコンピュータ６に対して、生成した取引データを送信する（Ｓ７０５取引送信）。具体的には、コンピュータ２は、ＨｙｐｅｒＬｅｄｇｅｒＦａｂｒｉｃなどブロックチェーンプラットフォームのＳＤＫを備え、ＳＤＫを通してコンピュータ６に対して取引データを送信する。いずれのコンピュータ６に取引データを送信するかは、ＳＤＫで設定する。
なお、チャネル機能によって用途の限定を実現せずに、アカウント残高テーブル３１が、「アカウントＩＤ」、「用途」、および「残高」を管理し、送金可能アカウントテーブル３２が、「アカウントＩＤ」、「用途」、および「条件」を管理する場合は、いずれかのコンピュータ６に対して、生成した取引データを送信する。また、ユーザ端末１がＨｙｐｅｒＬｅｄｇｅｒＦａｂｒｉｃなどブロックチェーンプラットフォームのＳＤＫを備え、仮想通貨アプリが取引データをコンピュータ６に送信する場合は、Ｓ７０２とＳ７０３を省略し、Ｓ７０４とＳ７０５を仮想通貨アプリが実行する。

コンピュータ６は、取引データを受信すると（Ｓ７０６取引受信）、チェーンコード実行部９aによって取引を実行する（Ｓ７０７取引実行）。具体的には、ＨｙｐｅｒＬｅｄｇｅｒＦａｂｒｉｃをプラットフォームとする場合は、取引データを受信したコンピュータ６は、取引を実行し、取引を承認できるかを確認する（取引のシミュレーション）。取引が承認される条件については後述する。なお、シミュレーション結果はブロックチェーンにコミットされない。次に、シミュレーションが無事に済むと、取引を成功したとみなし、コンピュータ６はコンピュータ２にＳＤＫを通してシミュレーション時に取得した更新前後の値セットを返却する（シミュレーションの完了）。その後、コンピュータ２からＯｒｄｅｒｅｒの役割を担うコンピュータ６に向けて更新前後の値セットを送信し（Ｏｒｄｅｒｅｒへのサブミット）、ＯｒｄｅｒｅｒからＰｅｅｒの役割を担う他のコンピュータ６に対してコミット要求を送信する（Ｏｒｄｅｒｅｒから各Ｐｅｅｒへのコミット要求の送信）。そして、各コンピュータ６は取引の実行を許可するかを判断するため最終的な検証を行う（取引の検証）。更新前後の値がコンピュータ２から送信された更新前後の値セットと今回の検証時に取得した更新前後の値セットが異なる場合、取引は却下される。そして、検証の結果、取引が承認された場合、ブロックチェーンに履歴を残し、ワールドステートの値を更新するとともに、アカウント残高テーブル３１が管理する、取引データの送金元として設定されたアカウントＩＤによって特定される仮想通貨の残高から取引データの送金額を減算し、取引データの送金先として設定されたアカウントＩＤによって特定される仮想通貨の残高に取引データの送金額を加算する。取引が却下された場合、ブロックチェーンに無効（失敗）マーク付で履歴を残すが、ワールドステートの値やアカウント残高テーブル３１の更新はしない。

取引が承認される条件は、取引データの送金額が、アカウント残高テーブル３１が管理する、取引データの送金元として設定されたアカウントＩＤによって特定される仮想通貨の残高以下であり、取引データの送金先として設定されたアカウントＩＤが、送金可能アカウントテーブル３２が管理するアカウントＩＤと一致し、取引データのコンテキスト情報が、送金可能アカウントテーブル３２が管理する前記アカウントＩＤに対応する条件を満たすことである。
なお、ユーザ端末１の位置などによって仮想通貨の送信可否を制御しない場合は、取引データのコンテキスト情報が、送金可能アカウントテーブル３２が管理する前記アカウントＩＤに対応する条件を満たす必要はない。
また、チャネル機能によって用途の限定を実現せずに、アカウント残高テーブル３１が、「アカウントＩＤ」、「用途」、および「残高」を管理し、送金可能アカウントテーブル３２が、「アカウントＩＤ」、「用途」、および「条件」を管理する場合、取引が承認される条件は、取引データの送金額が、アカウント残高テーブル３１が管理する、取引データの送金元として設定されたアカウントＩＤと取引データの用途指定情報として設定された用途との組に対応する仮想通貨の残高以下であり、取引データのコンテキスト情報が、送金可能アカウントテーブル３２が管理する、取引データの送金先として設定されたアカウントＩＤと取引データの用途指定情報として設定された用途との組に対応する条件を満たすことである。ユーザ端末１の位置などによって仮想通貨の送信可否を制御しない場合は、取引データのコンテキスト情報が、送金可能アカウントテーブル３２が管理する前記アカウントＩＤと前記用途との組に対応する条件を満たす必要はない。

コンピュータ６は、取引を実行すると、コンピュータ２に対して、取引が承認されたか却下されたかの取引の実行結果を送信し（Ｓ７０８取引実行結果送信）、コンピュータ２は、取引の実行結果を受信する（Ｓ７０９取引実行結果受信）。コンピュータ２は、取引の実行結果を受信すると、ユーザ端末１に対して、当該取引に対応する送金が成功したか否かの送金処理結果を送信し（Ｓ７１０送金処理結果結果送信）、ユーザ端末１は、送金処理結果を受信する（Ｓ７１１送金処理結果結果受信）。そして、ユーザ端末１は、送金処理結果を画面（図示せず）に表示する（Ｓ７１２送金処理結果表示）。
なお、ユーザ端末１がＨｙｐｅｒＬｅｄｇｅｒＦａｂｒｉｃなどブロックチェーンプラットフォームのＳＤＫを備え、仮想通貨アプリが取引データをコンピュータ６に送信する場合は、コンピュータ６は、ユーザ端末１に対して取引の実行結果を送信し（Ｓ７０８‘取引実行結果送信）、ユーザ端末１は、取引の実行結果を受信する（Ｓ７０９‘取引実行結果受信）。そして、Ｓ７１０とＳ７１１を省略し、ユーザ端末１は、当該取引に対応する送金が成功したか否かの送金処理結果を画面（図示せず）に表示する（Ｓ７１２‘送金処理結果表示）。

本発明は、ブロックチェーンで管理される仮想通貨の送金処理に利用できる。

２１１ 「ログイン」ボタン
２３１ 「送金」ボタン
２４１ 「支払先」領域
２４２ 「数量」領域
２４３ 「送金」ボタン

Claims (7)

1. アカウント識別情報および前記アカウント識別情報によって識別されるアカウントに係る仮想通貨の残高情報を管理するアカウント残高テーブルと、送金可能アカウント識別情報を管理する送金可能アカウントテーブルとを記憶するＤＢと、第１のアカウント識別情報、第２のアカウント識別情報、および、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額を含む取引情報を記憶するブロックチェーンと、を備える第１のコンピュータに接続する第２のコンピュータに、
   ユーザのアカウント識別情報を取得する第１のステップと、
   ユーザの端末において入力された送金先アカウント識別情報と、仮想通貨の送金額とを取得する第２のステップと、
   前記ユーザのアカウント識別情報を第１のアカウント識別情報とし、前記送金先アカウント識別情報を第２のアカウント識別情報とし、前記仮想通貨の送金額を、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額とする取引を実行する命令を前記第１のコンピュータに送信する第３のステップと、
   を実行させる仮想通貨送金方法であって、
   前記ＤＢと前記ブロックチェーンとが用途情報ごとに管理され、
   前記第１のステップで、用途指定情報をさらに取得し、
   前記第３のステップで、前記用途指定情報を前記第１のコンピュータにさらに送信し、
   前記命令は、
   前記用途指定情報と一致する前記用途情報に係る前記ＤＢと前記ブロックチェーンとを備える前記第１のコンピュータによって実行されるものであって、
   前記仮想通貨の送金額が、前記ＤＢに記憶された前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下であり、前記第２のアカウント識別情報が、前記ＤＢに記憶された前記送金可能アカウント識別情報と一致する場合に前記第１のコンピュータによって実行される、ことを特徴とする仮想通貨送金方法。
2. 前記送金可能アカウントテーブルが、条件情報をさらに管理し、
   前記第２のステップで、前記ユーザの端末のコンテキスト情報をさらに取得し、
   前記第３のステップで、前記コンテキスト情報を第１のコンピュータにさらに送信し、
   前記命令は、
   前記コンテキスト情報が、前記送金可能アカウント識別情報に対応する前記条件情報に係る条件をさらに満たす場合に実行される、
   請求項１記載の仮想通貨送金方法。
3. アカウント識別情報および前記アカウント識別情報によって識別されるアカウントに係る仮想通貨の残高情報を管理するアカウント残高テーブルを記憶する第１のＤＢと、第１のアカウント識別情報、第２のアカウント識別情報、および、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額を含む取引情報を記憶するブロックチェーンと、を備える第１のコンピュータに接続し、送金可能アカウント識別情報を管理する送金可能アカウントテーブルを記憶する第２のＤＢを備える第２のコンピュータに、
   ユーザのアカウント識別情報を取得する第１のステップと、
   ユーザの端末において入力された送金先アカウント識別情報と、仮想通貨の送金額とを取得する第２のステップと、
   前記ユーザのアカウント識別情報を第１のアカウント識別情報とし、前記送金先アカウント識別情報を第２のアカウント識別情報とし、前記仮想通貨の送金額を、前記第１のアカウント識別情報によって識別されるアカウントから前記第２のアカウント識別情報によって識別されるアカウントへ送金する仮想通貨の額とする取引を実行する命令を前記第１のコンピュータに送信する第３のステップと、
   を実行させる仮想通貨送金方法であって、
   前記第１のＤＢと前記ブロックチェーンとが用途情報ごとに管理され、
   送金可能アカウントテーブルが、前記用途情報をさらに管理し、
   前記第１のステップで、用途指定情報をさらに取得し、
   前記第３のステップで、前記用途指定情報を前記第１のコンピュータにさらに送信し、
   前記第３のステップは、前記用途指定情報が前記用途情報に一致し、かつ、前記送金先アカウント識別情報が前記送金可能アカウント識別情報に一致するレコードが前記送金可能アカウントテーブルに存在する場合に実行され、
   前記命令は、
   前記用途指定情報と一致する前記用途情報に係る前記第１のＤＢと前記ブロックチェーンとを備える前記第１のコンピュータによって実行されるものであって、
   前記仮想通貨の送金額が、前記第１のＤＢに記憶された前記第１のアカウント識別情報によって識別される前記残高情報に係る残高以下である場合に前記第１のコンピュータによって実行される、ことを特徴とする仮想通貨送金方法。
4. 前記送金可能アカウントテーブルが、条件情報をさらに管理し、
   前記第２のステップで、前記ユーザの端末のコンテキスト情報をさらに取得し、
   前記第３のステップは、前記コンテキスト情報が、前記レコードに対応する前記条件情報に係る条件をさらに満たす場合に実行される、
   請求項３記載の仮想通貨送金方法。
5. 前記ユーザのアカウント識別情報は、前記ユーザの端末において入力されたユーザ識別情報に基づいて取得される、
   請求項１から４のいずれかに記載の仮想通貨送金方法。
6. 前記ユーザ識別情報と、金融機関の口座管理システムが管理する口座識別情報とが、前記口座管理システムによって対応付けられている、
   請求項５記載の仮想通貨送金方法。
7. 前記送金可能アカウント識別情報によって識別される口座の名義人ないし管理者に係るユーザ識別情報と、金融機関の口座管理システムが管理する口座識別情報とが、前記口座管理システムによって対応付けられている、
   請求項１から６のいずれかに記載の仮想通貨送金方法。

Images