JP2020160652A - 仮想通貨の送金システム - Google Patents

Abstract

【課題】仮想通貨の送金の安全性を高める。【解決手段】２００は、サービス提供業者により運営される２０４と決済代行業者により運営される２０６を含む。２０４は、まず、仮想通貨の送金先、送金元、送金額等を指定した送金指示を受信する。２０６は、秘密コードを生成し、送金元とされたユーザに対して送金先の確認を要求する。このとき、秘密コードもユーザ（２１０）に通知される。ユーザは、送金先が間違いないか確認した上で、秘密コードを含む確認指示を２０４に送信する。２０６は、秘密コードが一致していれば本人から確認がとれたと判定し、仮想通貨の送金を実行する。【選択図】図２

Description

本発明は、仮想通貨の送金、特に、送金にともなうセキュリティ技術、に関する。

ブロックチェーンを用いた仮想通貨決済が実用化されている。一例として、ユーザは仮想通貨取引所に口座を開設し、仮想通貨を円貨で購入し、口座において仮想通貨を保有する。ユーザは、取引所にアクセスするためのウォレット（アプリケーション・ソフトウェアもしくはインターネットブラウザ等）をユーザ端末にダウンロードし、ウォレットから取引所のシステムにログインし（認証）、仮想通貨を送受する。

たとえば、ある商品を仮想通貨で購入するとき、店舗の決済端末にＱＲコード（登録商標）が表示される。ＱＲコード（登録商標）を読み取ると、ユーザ端末には送金先と購入金額（送金額）が表示される。確認後、ユーザが送金を指示すると、ブロックチェーンを介して仮想通貨の送金処理が実行される（非特許文献１参照）。

"お支払い方法 ビットコイン（ｂｉｔｃｏｉｎ）"、 ［online］、［平成31年1月22日検索］、インターネット＜https://www.biccamera.com/bc/c/info/payment/bitcoin.jsp＞

保有している仮想通貨を円貨に交換しなくても、仮想通貨のままで決済できるので、仮想通貨保有者にとって取引所を使った仮想通貨決済は便利である。その一方、仮想通貨決済には、送金指示後、仮想通貨が本当に正しく送金されたのか確認できないという不安がつきまとう。たとえば、第三者が、送金システムに不正侵入して送金前段階で送金先を書き換えてしまうと、送金者は送金したはずの仮想通貨をこの第三者に奪われてしまう。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、仮想通貨の送金の安全性を高めるための技術、を提供することにある。

本発明のある態様における仮想通貨の送金システムは、ユーザから仮想通貨の送金指示を受け付ける送金受付システムと、仮想通貨の送金を実行させる送金実行システムと、を備える。
送金受付システムは、ユーザから、仮想通貨の送金先を含む送金指示を取得する送金指示取得部と、送金指示を登録する送金指示登録部と、ユーザから、第１の秘密コードを含む確認指示を取得する確認取得部と、を含む。
送金実行システムは、送金元のユーザに対して、送金指示により指定された送金先および第２の秘密コードを通知する確認要求部と、通知した第２の秘密コードと確認指示により指定された第１の秘密コードが適合することを条件として、仮想通貨の送金を許可する送金判定部と、を含む。

本発明のある態様における仮想通貨の送金実行システムは、ユーザが送金先および送金元を指定して仮想通貨の送金を指示したとき、送金元として指定されたユーザに対して、指定された送金先と第２の秘密コードを通知する確認要求部と、第２の秘密コードの通知後、ユーザから入力された第１の秘密コードと第２の秘密コードが適合することを条件として、仮想通貨の送金を許可する送金判定部と、を備える。

本発明によれば、仮想通貨送金にともなうセキュリティを高めやすくなる。

一般的に想定される送金システムのハードウェア構成図である。 第１実施形態における送金システムのハードウェア構成図である。 第１実施形態における送金システムの機能ブロック図である。 送金予約テーブルのデータ構造図である。 第１実施形態における仮想通貨の送金過程を示すシーケンス図である。 第２実施形態における送金システムのハードウェア構成図である。 第２実施形態における送金システムの機能ブロック図である。 第２実施形態における仮想通貨の送金過程を示すシーケンス図である。

ブロックチェーン技術を利用した仮想通貨の送金に際しては、ユーザ（送金者）は秘密鍵をつかって送金データに電子署名をする。仮想通貨の送金システムを構築に際しては、第三者から秘密鍵を不正取得されないようにシステムを構成することが第一条件となる。

図１は、一般的に想定される送金システム１００のハードウェア構成図である。
図１に示す送金システム１００は、本発明者が説明のために想定した仮想事例である。送金システム１００は、送金受付システム１０４、送金実行システム１０６、送金データベース１０８およびユーザ端末１１０を含む。送金受付システム１０４は、仮想通貨による商品購入サービスを提供する店舗等の業者（以下、「サービス提供者」とよぶ）により運営される。

送金実行システム１０６は、仮想通貨取引の基盤となるシステムである。一般的には、仮想通貨取引の仕組みを提供する専門業者（以下、「決済代行業者」とよぶ）が、送金実行システム１０６により多数のサービス提供業者に仮想通貨取引の仕組み（インフラストラクチャ）を提供する。決済代行業者は、いわゆる仮想追加取引所の運営者であってもよい。なお、決済代行業者が、送金実行システム１０６だけでなく送金受付システム１０４も運営・提供する形態であってもよい。

ユーザ（送金者）がサービス提供者から仮想通貨によって商品を購入するとき、店舗の決済端末等にＱＲコード（登録商標）などの二次元コードが表示される。この二次元コードには、送金先となる仮想通貨口座のアドレス（以下、単に「送金先」とよぶ）が対応づけられる。ユーザは、スマートフォンなどのユーザ端末１１０により二次元コードを撮像することにより送金先をユーザ端末１１０に表示させる。ユーザは、ユーザ端末１１０から、送金先、送金元（ユーザＩＤ）および送金額を含む「送金指示」を、インターネット１０２を介して送金受付システム１０４に送信する。

送金受付システム１０４は、ウェブサーバ１１４とアプリケーションサーバ１１６を含む。ウェブサーバ１１４は、ファイアウォール１１２（プロキシサーバ）を介してインターネット１０２と接続される。ウェブサーバ１１４は、送金指示を受信し、アプリケーションサーバ１１６に送金指示を転送する。アプリケーションサーバ１１６は、送金指示を送金データベース１０８に送金ＩＤとともに登録する。送金ＩＤは送金指示を識別するために付与されるＩＤである。この段階では送金予約されただけであり、まだ送金は実行されていない。

送金実行システム１０６は、決済サーバ１１８を含む。
決済サーバ１１８は、ユーザ（送金者）の秘密鍵を保有する。決済サーバ１１８は、送金データベース１０８から送金指示を読み出し、送金元となるユーザの秘密鍵を使って電子署名を作った上で送金データをブロードキャストする。送金データは、採掘者とよばれる他のユーザからの認証手続きを経て、ブロックチェーン（巨大な取引台帳）に接続され、仮想通貨の送金が完結する。

ウェブサーバ１１４は、ファイアウォール１１２により防護されているものの、実質的にはインターネット１０２に対して公開されている。いいかえれば、ウェブサーバ１１４はもっとも不正侵入の脅威にさらされているといえる。一方、アプリケーションサーバ１１６は、ウェブサーバ１１４とはＬＡＮ（Local Area Network）を介して接続されており、インターネット１０２からアプリケーションサーバ１１６に直接アクセスすることはできない。決済サーバ１１８は、更に、アプリケーションサーバ１１６とはＶＰＮ（Virtual Private Network）または専用回線により接続されている。決済サーバ１１８も非公開のサーバである。インターネット１０２（公開通信回線）から決済サーバ１１８に侵入するためには、ファイアウォール１１２、ウェブサーバ１１４およびアプリケーションサーバ１１６を突破する必要があるため、決済サーバ１１８は大切な秘密鍵を安全に管理できる。
以上をまとめると、送金受付システム１０４のうち、ウェブサーバ１１４はインターネット１０２に対して公開されており、アプリケーションサーバ１１６、決済サーバ１１８および送金データベース１０８は非公開である。

ただし、決済サーバ１１８が秘密鍵を安全に管理したとしても不正送金リスクがゼロになるわけではない。攻撃者がウェブサーバ１１４に不正侵入し、送金指示に含まれる送金先を素早く書き換えてしまう可能性がある。たとえば、ユーザＰ１（送金者）が口座Ａ１を送金先として送金指示を出したつもりでも、送金先を攻撃者の管理下にある口座Ａ２に書き換えられてしまうと、ユーザＰ１は送金した仮想通貨を攻撃者に盗まれてしまう。
また、アプリケーションサーバ１１６のソフトウェアに脆弱性がある場合、インターネット１０２からアプリケーションサーバ１１６不正侵入される可能性もある。アプリケーションサーバ１１６は、ウェブサーバ１１４に比べると不正侵入リスクは小さいものの不正侵入されるリスクを想定しておく必要はある。

以下、第１実施形態および第２実施形態の２つの実施形態に分けて本発明の実施態様について説明する。以下、「本実施形態」という用語は「第１実施形態」「第２実施形態」を特に区別しない意味で使用する。

［第１実施形態］
図２は、第１実施形態における送金システム２００のハードウェア構成図である。
ユーザ（送金者）は、ユーザ端末２１０から、送金受付システム２０４に「送金指示」を送信する。送金指示には、送金先、送金元および送金額が含まれる。送金指示は、ウェブサーバ２１４に受け付けられ、アプリケーションサーバ２１６は送金データベース２０８に送金指示を送金ＩＤとともに登録する。ここまでは図１に示した送金システム１００と同じである。

アプリケーションサーバ２１６は、送金指示を送金データベース２０８に登録したとき、送金ＩＤ、送金先、送金元および送金額を送金実行システム２０６の決済サーバ２１８に通知する。決済サーバ２１８は、あらかじめ各ユーザの電子メールアドレスを管理している。決済サーバ２１８は、秘密コード（第２の秘密コード）を生成し、送金元のユーザに電子メール（以下、「確認要求」とよぶ）を送信する。確認要求には、アプリケーションサーバ２１６から通知された送金ＩＤ、送金先、送信元、送金額に加えて、秘密コードが記載される。ユーザは、ユーザ端末２１０により確認要求を受信し、実際に受け付けられた送金指示の内容を確認する。

たとえば、ユーザＰ１が送金先として口座Ａ１を指定し、確認要求にも送金先として口座Ａ１が記載されていれば、ユーザＰ１は、送金ＩＤと秘密コード（第２の秘密コード）を含む「確認指示」をウェブサーバ２１４に送信する。アプリケーションサーバ２１６は、この確認指示を受け取り、確認指示に含まれる送金ＩＤと秘密コードを決済サーバ２１８に通知する。決済サーバ２１８は、確認要求に際してユーザに通知した秘密コードと確認指示で指定された秘密コードが同一であれば、ユーザ本人からの承認が得られたとして、送金を許可する。同一でなければ、決済サーバ２１８は送金を実行しない。

たとえば、ユーザＰ１が送金先を口座Ａ１に指定し、そのあとに攻撃者によって送金先が密かに口座Ａ２に書き換えられたとする。この場合には、アプリケーションサーバ２１６は送金先として口座Ａ２を決済サーバ２１８に通知することになる。決済サーバ２１８は、口座Ａ２を送金先として記載された確認要求をユーザに通知することになるため、ユーザＰ１は送金先が書き換えられていることに気づく。ユーザＰ１が確認指示を出さなければ送金は実行されないので、不正送金を未然に防ぐことができる。

また、ユーザＰ１以外は、秘密コードを知ることができないため、攻撃者はユーザＰ１になりすまして確認指示を送金受付システム２０４に入力することもできない。

図３は、第１実施形態における送金システム２００の機能ブロック図である。
ユーザ端末２１０、ウェブサーバ２１４、アプリケーションサーバ２１６、決済サーバ２１８および送金データベース２０８の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
図７に示す第２実施形態における送金システム３００の機能ブロックについても同様である。

上述したように、送金システム２００は、ユーザ端末２１０、ウェブサーバ２１４，アプリケーションサーバ２１６、決済サーバ２１８および送金データベース２０８を含む。送金データベース２０８には未処理の送金指示（送金予約）が登録される。送金データベース２０８のデータ構造については次の図４に関連して詳述する。

（ユーザ端末２１０）
ユーザ端末２１０は、入力部２３０、出力部２３２および通信部２６８を含む。入力部２３０は、ユーザ（送金者）からの各種入力を受け付ける。出力部２３２は、ユーザに対して各種情報を出力する。通信部２６８は、ウェブサーバ２１４等との通信処理を担当する。

入力部２３０は、送金指示部２３４、確認指示部２３６、確認要求取得部２３８および送金情報取得部２６６を含む。
送金情報取得部２６６は、二次元コードを撮像することにより、送金先を特定する情報を取得する。送金指示部２３４は、ユーザから送金指示を受け付ける。送金指示には、送金先を示す仮想通貨口座のＩＤ、送金元を示すユーザＩＤ（仮想通貨口座）および送金額が含まれる。確認指示部２３６は、ユーザから確認指示を受け付ける。確認指示には、送金ＩＤおよび秘密コードが含まれる。確認要求取得部２３８は、決済サーバ２１８から確認要求を受信する。確認要求には、送金ＩＤ、送金先、送金元、送金額および秘密コードが含まれる。

出力部２３２は、送金情報表示部２４０を含む。送金情報表示部２４０は、送金情報取得部２６６が取得した送金先に関する情報を画面表示させる。また、送金情報表示部２４０は、確認要求により通知された情報も画面表示させる。

（ウェブサーバ２１４）
ウェブサーバ２１４は、送金指示取得部２４２および確認取得部２４４を含む。送金指示取得部２４２は、ユーザ端末２１０から送金指示を受信する。送金指示取得部２４２は、また、送金指示をアプリケーションサーバ２１６に転送する。確認取得部２４４は、ユーザ端末２１０から確認指示（送金承認）を受信する。確認取得部２４４は、確認指示をアプリケーションサーバ２１６に転送する。

（アプリケーションサーバ２１６）
アプリケーションサーバ２１６は、送金指示登録部２４６、送金指示通知部２４８および確認指示通知部２７０を含む。送金指示登録部２４６は、送金ＩＤとともに送金指示を送金データベース２０８に登録する。送金指示通知部２４８は、送金指示を受信したとき、送金ＩＤ、送金先、送金元、送金額を決済サーバ２１８に通知する（以下、「送金指示通知」とよぶ）。確認指示通知部２７０は、確認指示を受信したとき、確認指示に含まれる送金ＩＤと秘密コードを決済サーバ２１８に通知する（以下、「確認指示通知」とよぶ）。

（決済サーバ２１８）
決済サーバ２１８は、通信部２５０とデータ処理部２５２を含む。通信部２５０は、アプリケーションサーバ２１６、ユーザ端末２１０等との通信処理を担当する。データ処理部２５２は、通信部２５０により取得されたデータおよび送金データベース２０８に格納されているデータに基づいて各種処理を実行する。データ処理部２５２は、通信部２５０および送金データベース２０８のインタフェースとしても機能する。

通信部２５０は、送金指示受信部２５６、確認指示受信部２７２および確認要求部２５８を含む。
送金指示受信部２５６は、送金指示通知部２４８から送金指示通知を受信する。確認指示受信部２７２は、確認指示通知部２７０から確認指示通知を受信する。確認要求部２５８は、確認要求をユーザ端末２１０に送信する。

データ処理部２５２は、コード生成部２６０、送金判定部２６２および送金実行部２６４を含む。
コード生成部２６０は、送金指示通知を受信したとき、秘密コードを生成する。本実施形態においては、コード生成部２６０は英数字をランダムに選択することで複数桁の英数字列を秘密コードとして生成する。コード生成部２６０は、生成した秘密コードを送金システム２００において保持しておく。コード生成部２６０は、送金データベース２０８に秘密コードを生成したときにその旨を記録するが、秘密コードそのものを送金データベース２０８には登録することはない（図４に関連して後述）。送金判定部２６２は、確認要求によりユーザに通知した秘密コード（第２の秘密コード）と、確認指示通知された秘密コード（第１の秘密コード）が一致するか否かを判定する。送金実行部２６４は、２つの秘密コードが一致したとき、仮想通貨の送金を実行する。

図４は、送金予約テーブル２８０のデータ構造図である。
送金予約テーブル２８０は、送金データベース２０８に格納される。送金予約テーブル２８０には、未処理の送金指示が登録される。送金指示登録部２４６は、送金指示が受信されるごとに送金指示を送金データベース２０８に登録する。このとき、送金指示を識別するための送金ＩＤが付与される。図３によれば、送金ＩＤ＝Ｔ０３の送金指示（以下、「送金指示（Ｔ０３）」のように表記する）は、送金元（Ｃ０１）から送金先（Ｂ０２）への「２００（コイン）」の送金を意味する。送金指示（Ｔ０３）には秘密コードが付与されていない。したがって、送金指示（Ｔ０３）はアプリケーションサーバ２１６により受け付けられたものの決済サーバ２１８は秘密コードを生成していない段階にある。

送金指示（Ｔ０４）は、送金元（Ｃ０６）から送金先（Ｂ７７）への「２５（コイン）」の送金を示し、秘密コードは生成済みである。コード生成部２６０は、送金指示（Ｔ０４）について送金指示通知を受けたとき、秘密コード（例：１４１９）を生成し、秘密コードを生成した旨を送金予約テーブル２８０に登録するとともに確認要求部２５８に秘密コードを含む確認要求を送信させる。送金指示（Ｔ０４）はコード生成部２６０により秘密コードが登録されたものの、ユーザからの確認がとれていないため未送金の段階にある。ユーザが、送金指示（Ｔ０４）に対応して秘密コード（「１４１９」）を含む確認指示を送信したとき、決済サーバ２１８は送金を実行する。送金の実行後、コード生成部２６０は、決済サーバ２１８から送金指示（Ｔ０４）を削除する。

図５は、第１実施形態における仮想通貨の送金過程を示すシーケンス図である。
ユーザ（送金者）は、まず、ユーザ端末２１０に送金指示を入力する。送金指示は、送金元、送金先、送金額を含む。ユーザ端末２１０からウェブサーバ２１４に送金指示がなされ（Ｓ１０）、ウェブサーバ２１４は送金指示をアプリケーションサーバ２１６に転送し（Ｓ１２）、アプリケーションサーバ２１６の送金指示登録部２４６は送金ＩＤとともに送金指示を送金データベース２０８に登録する（Ｓ１４）。また、アプリケーションサーバ２１６の送金指示通知部２４８は、決済サーバ２１８に送金指示通知する（Ｓ１６）。コード生成部２６０は、送金指示通知に対応して秘密コードを生成する（Ｓ１８）。

確認要求部２５８は、送金ＩＤ、送金先、送金元、送金額および秘密コードを含む確認要求をユーザ端末２１０に送信する（Ｓ２０）。送金者は、送金内容を確認し、秘密コードを入力する（Ｓ２２）。ユーザ端末２１０の確認指示部２３６は、送金ＩＤと秘密コードを含む確認指示をウェブサーバ２１４に送信し（Ｓ２４）、ウェブサーバ２１４は確認指示をアプリケーションサーバ２１６に送信する（Ｓ２６）。アプリケーションサーバ２１６の確認指示通知部２７０は、送金ＩＤと秘密コードを決済サーバ２１８に通知する（Ｓ２８）。

決済サーバ２１８の送金判定部２６２は、確認要求時に通知した秘密コードと確認指示により新たに通知された秘密コードを比較する（Ｓ３２）。ここでは秘密コードは一致したものとする。送金実行部２６４は、秘密コードが一致したとき、送金を実行する（Ｓ３４）。送金判定部２６２は、送金実行後、送金データベース２０８から実行済みの送信指示を削除する（Ｓ３６）。

［第２実施形態］
第１実施形態においては、アプリケーションサーバ２１６は、送金指示を受信したとき、決済サーバ２１８に送金指示通知をする。これを契機として、決済サーバ２１８は秘密コードを含む確認要求をユーザ端末２１０に送信する。また、アプリケーションサーバ２１６は、ユーザ端末２１０から確認指示を受信したとき、決済サーバ２１８に確認指示通知をする。これを契機として、決済サーバ２１８は秘密コードの照合を行う。このように、第１実施形態においては、アプリケーションサーバ２１６から決済サーバ２１８へのアクセスが限定的ながら許可されている。

たとえ、アプリケーションサーバ２１６への不正侵入に成功したとしても、決済サーバ２１８まで不正侵入することは相当困難であると考えられる。しかしながら、決済サーバ２１８のソフトウェアに万が一にもセキュリティホールがあれば、アプリケーションサーバ２１６から決済サーバ２１８へアクセスするパス（アクセス経路）が存在する以上、アプリケーションサーバ２１６を経由して決済サーバ２１８への不正侵入を許してしまう懸念は残る。
第２実施形態においては、更に万全を期するため、アプリケーションサーバ３１６から決済サーバ３１８へのアクセス経路そのものを遮断する。
以下、第２実施形態において、第１実施形態と同一の符号を付されているものの機能および処理は同一であるものとして説明する。

図６は、第２実施形態における送金システム３００のハードウェア構成図である。
送金システム３００がユーザ（送金者）に提供するユーザインタフェースは第１実施形態と同じである。送金システム３００においては、アプリケーションサーバ３１６および決済サーバ３１８の構成が第１実施形態から若干変更されている。

ユーザは、ユーザ端末２１０を介して送金指示をウェブサーバ２１４に送信し、アプリケーションサーバ３１６は送金データベース２０８に送金指示を送金ＩＤとともに登録する。ここまでは第１実施形態と同じである。第２実施形態においては、アプリケーションサーバ３１６は送金指示を登録した旨を決済サーバ３１８に通知することはない。アプリケーションサーバ３１６から決済サーバ３１８へのアクセス経路は存在しない。または、アプリケーションサーバ３１６から決済サーバ３１８へのアクセスは全面的に禁止されている。

第２実施形態の決済サーバ３１８は、定期的に送金データベース２０８にアクセスすることで未処理の送金指示（送金予約）を読み出す。決済サーバ３１８は未処理の送金指示を検出したとき、これに対応する秘密コードを生成し、確認要求をユーザ端末２１０に送信する。

ユーザは、第１実施形態と同様、確認指示をウェブサーバ２１４に送信する。アプリケーションサーバ３１６は、確認指示に含まれる秘密コードを送金データベース２０８に登録する。決済サーバ３１８は、送金データベース２０８へのポーリング（定期的なアクセス）により、新たに秘密コードを登録された未処理の送金指示を検出する。生成した秘密コードと受け取った秘密コードが一致していれば、決済サーバ３１８は送金を許可する。

第２実施形態においては、決済サーバ３１８は送金データベース２０８に定期的にアクセスするが、他の装置から決済サーバ３１８にアクセスすることはできない。このため、万が一、アプリケーションサーバ３１６への不正侵入を許したとしても、アプリケーションサーバ３１６から決済サーバ３１８への侵入経路そのものが存在しないため、決済サーバ３１８への不正侵入を防止できる。

図７は、第２実施形態における送金システム３００の機能ブロック図である。
第２実施形態においては、アプリケーションサーバ３１６および決済サーバ３１８の構成が、第１実施形態のアプリケーションサーバ２１６および決済サーバ３１８から一部変更されている。
アプリケーションサーバ３１６は、送金指示を送金ＩＤとともに送金データベース２０８に登録する送金指示登録部２４６を含むが、送金指示通知部２４８および確認指示通知部２７０は含まない。

決済サーバ３１８の通信部３５０は、送金指示検出部３５６を含むが送金指示受信部２５６と確認指示受信部２７２は含まない。送金指示受信部２５６は、定期的に送金データベース２０８にアクセスし、新たに登録された送金指示を検出する。また、送金指示受信部２５６は、定期的に送金データベース２０８にアクセスし、確認指示により新たに秘密コードを登録された送金指示を検出する。

図８は、第２実施形態における仮想通貨の送金過程を示すシーケンス図である。
まずＳ１０からＳ１４までの処理過程は第１実施形態（図５参照）と同様である。決済サーバ３１８は、定期的に送金データベース２０８にアクセスすることで新着の送金指示を検出する（Ｓ４０）。

送金指示検出後の確認要求（Ｓ２０）から、秘密コードの生成を経て（Ｓ１８）、確認指示を受信する（Ｓ２６）までは第１実施形態と同様である。アプリケーションサーバ３１６の送金指示登録部２４６は、確認指示により受信した秘密コードを送金データベース２０８に登録する（Ｓ４４）。決済サーバ３１８は、定期的に送金データベース２０８にアクセスし、新たに秘密コードを登録された送信指示を検出する（Ｓ４６）。送金判定部２６２は、Ｓ１８で生成した秘密コードと、Ｓ４６において読み出した秘密コードを照合する（Ｓ３２）。２つの秘密コードが一致すれば、送金実行部２６４は送金を実行する（Ｓ３４）。

以上、第１実施形態および第２実施形態に基づいて送金システム２００，３００について説明した。
銀行間送金においては、銀行同士で送金元と送金先を確認できる。しかし、仮想通貨取引においては、従来、送金先に確実に送金されていることを保証する仕組みについて十分な提案がなされてこなかった。本実施形態においては、実際に送金する前に、ユーザ（送金者）に送金先を確認してもらってから仮想通貨の送金を実行する。また、確認要求には秘密コードが含まれるため、確認要求を受信したユーザしか送金を承認できない。このような制御方法により、サービス提供者が運営する送金受付システム１０４に不正侵入され、送金先の改ざんがなされたとしても、不正送金を未然に防ぐことができる。

また、仮に不正なユーザＰ２がユーザＰ１になりすましてユーザＰ１の仮想通貨口座からの送金をしようとしても、確認要求はユーザＰ１に届くため、ユーザＰ１は第三者（ユーザＰ２）による不正送金がなされようとしていることに気づくことができる。

サービス提供業者は、不正侵入を防止するため独自に送金受付システム２０４，３０４のセキュリティ対策を立てることになる。しかし、すべてのサービス提供業者が完璧なセキュリティ対策をできるとは想定するわけにはいかない。決済代行業者（送金実行システム２０６，３０６）としては、送金受付システム２０４，３０４は不正侵入される可能性があるという前提で送金実行システム２０６，３０６のセキュリティ対策をするべきである。本実施形態においては、送金受付システム２０４，２０６に不正侵入がされて送金先が書き換えられるのを防ぐという考え方ではなく、たとえ送金先が書き換えられてもそれを送金前に発覚させることでセキュリティを高めている。

第２実施形態においては、更に、アプリケーションサーバ３１６から決済サーバ３１８へのアクセスを禁止している。このような構成によれば、サービス提供者の送金受付システム３０４と決済代行業者の送金実行システム３０６をいっそう確実に分離できる。このため、多種多様な送金受付システム３０４のいずれかに脆弱性が発覚したとしても、送金実行システム３０６の決済サーバ３１８を不正アクセスから守りやすくなる。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

ウェブサーバ２１４とアプリケーションサーバ２１６、送金データベース２０８、決済サーバ２１８により送金システム２００が構成されるとして説明したが、ウェブサーバ２１４とアプリケーションサーバ２１６は単一の装置として構成されてもよいし、ウェブサーバ２１４とアプリケーションサーバ２１６の機能の一部が他の装置に割り当てられてもよい。決済サーバ２１８についても同様である。また、第２実施形態における送金システム３００についても同様である。

図３、図４において説明した送金システム２００，３００に関連して、１つまたは複数のハードウェアに対して、本発明を実現するために必要な複数の機能をどのように配分するかは、各ハードウェアの処理能力や送金システム２００，３００に求められる仕様等に鑑みて決定されればよい。

送金データベース２０８は、送金受付システム２０４，３０４の一部として形成されてもよいし、送金実行システム２０６，３０６の一部として形成されてもよい。送金データベース１０８は、ＶＰＮ等により、送金受付システム２０４等の外部装置からのアクセスを制限することが望ましい。

［変形例］
本実施形態においては、ユーザ端末２１０から送金受付システム２０４，３０４に送金指示および確認指示を、インターネット１０２を経由して送信するとして説明した。送金者はこれらの指示を送金受付システム２０４，３０４が提供する入力装置に直接入力してもよい。

確認要求は電子メール以外の通信手段によりユーザに通知されてもよい。たとえば、ＳＭＳ（Short Message Service）で通知されてもよいし、ＳＮＳ（Social Network Service）のメッセージ機能により通知されてもよい。

確認要求に秘密コードを含めることは必須ではない。たとえば、確認要求部２５８は、送金先、秘密コード等を非公開のユーザページ（ウェブサイト）に登録し、確認要求部２５８は確認要求によりこのユーザページのアドレスを通知し、ユーザはユーザページにアクセスすることで送金先等を確認してもよい。

本実施形態においては、秘密コードは英数字列をランダムに生成するとして説明した。変形例としてあらかじめ複数種類の秘密コードを用意しておき、コード生成部２６０は複数種類の秘密コードのうちのいずれかを選択した上で確認要求時にユーザに通知してもよい。

秘密コードは、あらかじめユーザが登録しているパスワードであってもよい。この場合にも、確認要求に秘密コードを含める必要はない。送金実行システム２０６，３０６は、送金先、送金額、送金元等を記載した確認要求をユーザに送信し、ユーザはあらかじめ設定しておいた秘密コードを含む確認指示を送金受付システム２０４，２０６に送信してもよい。このような制御方法によれば、確認要求において秘密コードがのぞき見されるリスクもなくなる。

本実施形態においては、確認要求に含まれる秘密コードと確認指示により指定される秘密コードが完全一致することを条件として、送金を許可するとして説明した。変形例として秘密コードの完全一致以外の方法にて２つの秘密コードの適合性をチェックしてもよい。たとえば、ユーザ端末１１０は、確認要求に含まれる秘密コードからハッシュ値を生成する。決済サーバ２１８，３１８は、確認要求に含まれる秘密コードのハッシュ値と確認指示により指定される秘密コードのハッシュ値を比較することで２つの秘密コードの適合性を判定してもよい。あるいは、２つの秘密コードの任意の一部を比較することで適合性を判定してもよい。

第１実施形態においては、決済サーバ２１８，３１８は、秘密コードを生成したあと、送金データベース２０８にこれを登録せずに決済サーバ２１８，内部で送金ＩＤとともに保存するとして説明した。変形例として、決済サーバ２１８，３１８は生成した秘密コードを送金データベース２０８にいったん登録してもよい。そして、確認指示により送金ＩＤと秘密コードが指定されたとき、送金データベース２０８に登録されている秘密コードと比較することで送金可否を判定してもよい。なお、確認要求の送信先となるユーザの電子メールアドレスも、もっとも不正侵入しづらい決済サーバ２１８，３１８だけで管理することが望ましい。

コード生成部２６０は、秘密コードに有効期間を設定してもよい。有効期間が満了するまでに確認指示が得られなかったとき、送金実行部２６４は送金指示をキャンセルしてもよい。確認要求部２５８は、秘密コードを暗号化してユーザ端末１１０に送信し、ユーザ端末１１０において秘密コードを復号してもよい。

ユーザは、送金先の書き換えが発覚したときには、ウェブサーバ２１４に不正通知を送信してもよい。アプリケーションサーバ２１６，３１６は、不正通知を受信したとき、不正な送金先として記録してもよい。このような制御方法によれば、不正送金被害の拡大を効果的に防止しやすくなる。また、サービス提供業者も送金受付システム２０４，３０４への不正侵入の可能性に気づくことができるため、早期にシステムの脆弱性を解消しやすくなると考えられる。

第２実施形態においては、送金指示検出部３５６は定期的に送金データベース２０８にアクセスするとして説明したが、アクセスは定期的である必要はない。たとえば、送金指示が多いときには、ブロックチェーンを介した送金には時間がかかるため、未送金の送金指示がたまっているときほど送金データベース２０８へのアクセス頻度を下げてもよい。

本実施形態においては、仮想通貨のブロックチェーンを介した送金を対象として説明したが、仮想通貨に限らずリアルマネーの送金に対しても応用可能である。また、お金に限らず、物品の配達をインターネット１０２経由で指示するときにも、不正配達を防止する上で有効であると考えられる。

なお、送金実行システムは、仮想通貨の送金指示が受け付けられてから送金が実行されるまでの処理過程において、他のシステムからのデータアクセスを受け付けないように構成されてもよい。

１００ 送金システム、１０２ インターネット、１０４ 送金受付システム、１０６ 送金実行システム、１０８ 送金データベース、１１０ ユーザ端末、１１２ ファイアウォール、１１４ ウェブサーバ、１１６ アプリケーションサーバ、１１８ 決済サーバ、２００ 送金システム、２０４ 送金受付システム、２０６ 送金実行システム、２０８ 送金データベース、２１０ ユーザ端末、２１４ ウェブサーバ、２１６ アプリケーションサーバ、２１８ 決済サーバ、２３０ 入力部、２３２ 出力部、２３４ 送金指示部、２３６ 確認指示部、２３８ 確認要求取得部、２４０ 送金情報表示部、２４２ 送金指示取得部、２４４ 確認取得部、２４６ 送金指示登録部、２４８ 送金指示通知部、２５０ 通信部、２５２ データ処理部、２５６ 送金指示受信部、２５８ 確認要求部、２６０ コード生成部、２６２ 送金判定部、２６４ 送金実行部、２６６ 送金情報取得部、２６８ 通信部、２７０ 確認指示通知部、２７２ 確認指示受信部、２８０ 送金予約テーブル、３００ 送金システム、３０４ 送金受付システム、３０６ 送金実行システム、３１６ アプリケーションサーバ、３１８ 決済サーバ、３５０ 通信部、３５６ 送金指示検出部

Claims (5)

1. ユーザから仮想通貨の送金指示を受け付ける送金受付システムと、仮想通貨の送金を実行させる送金実行システムと、を備え、
   前記送金受付システムは、
   ユーザから、仮想通貨の送金先を含む送金指示を取得する送金指示取得部と、
   送金指示を登録する送金指示登録部と、
   ユーザから、第１の秘密コードを含む確認指示を取得する確認取得部と、を含み、
   前記送金実行システムは、
   送金元のユーザに対して、送金指示により指定された送金先および第２の秘密コードを通知する確認要求部と、
   前記通知した第２の秘密コードと前記確認指示により指定された第１の秘密コードが適合することを条件として、仮想通貨の送金を許可する送金判定部と、を含むことを特徴とする仮想通貨の送金システム。
2. 前記送金受付システムは、
   送金指示が取得されたとき、前記送金実行システムに対して、送金元のユーザと仮想通貨の送金先を通知する送金指示通知部、を更に含み、
   前記送金実行システムの前記確認要求部は、前記送金指示通知部からの通知を受けたとき、送金元のユーザに対して、通知された送金先および第２の秘密コードを通知することを特徴とする請求項１に記載の仮想通貨の送金システム。
3. 前記送金受付システムおよび前記送金実行システムの双方からアクセス可能な送金データベースを更に備え、
   前記送金受付システムの送金指示登録部は、送金指示が取得されたとき、前記送金データベースに送金指示を登録し、
   前記送金実行システムは、前記送金データベースに自発的にアクセスすることにより未実行の送金指示を検出する送金指示検出部、を更に含み、
   前記送金実行システムの前記確認要求部は、未実行の送金指示が検出されたとき、送金元のユーザに対して、第２の秘密コードを通知することを特徴とする請求項１に記載の仮想通貨の送金システム。
4. 前記送金受付システムの前記確認取得部は、第１の秘密コードを含む確認指示を取得したとき、前記送金データベースに第１の秘密コードを登録し、
   前記送金実行システムの前記送金指示検出部は、更に、前記送金データベースに自発的にアクセスすることにより、第１の秘密コードが登録され、かつ、未実行の送金指示を検出し、
   前記送金判定部は、第１の秘密コードと第２の秘密コードが適合することを条件として、仮想通貨の送信を許可することを特徴とする請求項３に記載の仮想通貨の送金システム。
5. ユーザが送金先および送金元を指定して仮想通貨の送金を指示したとき、送金元として指定されたユーザに対して、前記指定された送金先と第２の秘密コードを通知する確認要求部と、
   第２の秘密コードの通知後、ユーザから入力された第１の秘密コードと第２の秘密コードが適合することを条件として、仮想通貨の送金を許可する送金判定部と、を備えることを特徴とする仮想通貨の送金実行システム。

Images