(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-18
(45)【発行日】2022-10-26
(54)【発明の名称】送金指示装置、送金指示方法、送金指示プログラム及び送金指示システム
(51)【国際特許分類】
G06Q 20/06 20120101AFI20221019BHJP
G06Q 20/38 20120101ALI20221019BHJP
【FI】
G06Q20/06 300
G06Q20/38 322
(21)【出願番号】P 2018235584
(22)【出願日】2018-12-17
【審査請求日】2021-09-27
(73)【特許権者】
【識別番号】518301327
【氏名又は名称】鳥居 寛
(74)【代理人】
【識別番号】100103894
【氏名又は名称】家入 健
(72)【発明者】
【氏名】鳥居 寛
【審査官】樋口 龍弥
(56)【参考文献】
【文献】特開2016-218633(JP,A)
【文献】国際公開第2016/013048(WO,A1)
【文献】特開2006-279269(JP,A)
【文献】特開2011-076166(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
登録済みの複数のユーザに対してデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶する鍵情報記憶部と、
前記所定のユーザから所定の送金実行サービスの指定を受け付ける受付部と、
前記指定された前記所定の送金実行サービスに基づいて、前記鍵情報記憶部の中から前記鍵情報を特定する特定部と、
所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨における前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、
を備え、
前記複数の鍵情報のそれぞれは、前記送金実行サービスごとに異なり、1以上の鍵を含み、かつ、前記送金実行サービスにおいて前記所定のユーザを一意に識別可能な情報を含む、
送金指示装置。
【請求項2】
前記送金指示に基づく前記所定のデジタル通貨に対応する取引記録が所定の承認条件を満たした場合に、前記送金先へ着金通知を行う着金通知部をさらに備え、
前記所定の承認条件は、前記取引記録が1以上の他の装置において承認されたか否かを判定するための承認条件であって、前記送金指示装置又は外部において更新されたものである
請求項1に記載の送金指示装置。
【請求項3】
前記複数の送金実行サービスのそれぞれごとに、前記鍵情報に含まれる各鍵に関する定義を記憶する鍵定義記憶部と、
前記鍵定義記憶部を用いて、前記所定のユーザから当該ユーザが特定の送金実行サービスを利用するための鍵情報を受け付けて、当該受け付けた鍵情報に含まれる各鍵を当該特定の送金実行サービスに対応付けて前記鍵情報記憶部へ登録する鍵登録部と、
をさらに備える請求項1又は2に記載の送金指示装置。
【請求項4】
前記送金先から前記送金先アドレスを含めた前記送金情報を取得する送金情報取得部をさらに備える
請求項1乃至3のいずれか1項に記載の送金指示装置。
【請求項5】
前記所定のデジタル通貨と他の通貨との換算レートに基づき前記送金額を当該他の通貨に換算した換算金額を算出する換算部をさらに備える
請求項1乃至4のいずれか1項に記載の送金指示装置。
【請求項6】
前記送金指示部は、
前記送金額を前記所定のデジタル通貨から他の通貨に交換した場合の期待される処理時間が指定された時間以内の場合に、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金指示を行う
請求項1乃至5のいずれか1項に記載の送金指示装置。
【請求項7】
コンピュータが、
登録済みの複数のユーザに対してデジタル通貨を送金するサービスを提供する複数の送金実行サービスのうち所定の送金実行サービスの指定を、所定のユーザから受け付けるステップと、
前記複数の送金実行サービスのそれぞれと、前記所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶した鍵情報記憶部の中から、前記指定された送金実行サービスに基づいて、前記鍵情報を特定する特定ステップと、
所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨における前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示ステップと、
を行い、
前記複数の鍵情報のそれぞれは、前記送金実行サービスごとに異なり、1以上の鍵を含み、かつ、前記送金実行サービスにおいて前記所定のユーザを一意に識別可能な情報を含む、
送金指示方法。
【請求項8】
登録済みの複数のユーザに対してデジタル通貨を送金するサービスを提供する複数の送金実行サービスのうち所定の送金実行サービスの指定を、所定のユーザから受け付ける受付処理と、
前記複数の送金実行サービスのそれぞれと、前記所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶した鍵情報記憶部の中から、前記指定された送金実行サービスに基づいて、前記鍵情報を特定する特定処理と、
所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨における前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示処理と、
をコンピュータに実行させ、
前記複数の鍵情報のそれぞれは、前記送金実行サービスごとに異なり、1以上の鍵を含み、かつ、前記送金実行サービスにおいて前記所定のユーザを一意に識別可能な情報を含む、
送金指示プログラム。
【請求項9】
登録済みの複数のユーザに対してデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶する鍵情報記憶部を備える送金指示端末と、
支払情報を特定するための支払情報特定情報を出力する支払情報提示装置と、を備え、
前記送金指示端末は、
前記所定のユーザが指定した前記所定の送金実行サービスに基づいて、前記鍵情報記憶部の中から前記鍵情報を特定する特定部と、
前記支払情報特定情報により特定された前記支払情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、所定のデジタル通貨における送金額について前記支払情報に対応する送金先アドレスへの送金指示を行う送金指示部と、
を備え、
前記複数の鍵情報のそれぞれは、前記送金実行サービスごとに異なり、1以上の鍵を含み、かつ、前記送金実行サービスにおいて前記所定のユーザを一意に識別可能な情報を含む、
送金指示システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムに関し、特にデジタル通貨の送金指示を行う送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムに関する。
【背景技術】
【0002】
ネットワーク化された現在における決済では、硬貨、紙幣及び小切手等の物理的通貨に代わって、通貨を電子的に表現したデジタル通貨による送金が一般的となっている。ネットワーク上の支払いにおいて、現時点では、クレジットカードや銀行振り込みなどが一般的である。あるいは、実店舗における支払いにおいては、電子マネーによる支払いも普及している。例えば、特許文献1においては、二次元コードを利用した決済システムが開示されている。以下、「店舗」という表現を用いているが、これは必ずしも商品を販売している店とは限らない。個人やサービス提供会社や単なる送金先口座などを表し、送金の受け手を代表するものとしてこの表現を使用している。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところが、店舗がより多くの顧客と商取引を行おうとする場合、複数の決済業者と提携しなければならない。しかし、小規模な店舗や個人が複数の決済業者と提携するのは手続やコスト面から実現性が低い。例えば、仮想通貨による支払いにおいて、店舗が決済業者(仮想通貨交換業者)との提携を行わない場合には、店舗は各顧客に都度、送金先アドレスを伝え、個々の顧客が利用する交換業者を活用して手動による送金を依頼することになる。よって、顧客の利便性が損なわれる。そこで、複数の交換業者からの支払いを包括的に扱い、顧客の利便性を図るサービスの登場が望まれる。
【0005】
本開示は、このような問題を解決するためになされたものであり、複数の決済業者からの支払いを包括的に扱い、顧客の利便性を図るための送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本開示の第1の態様にかかる送金指示装置は、
登録済みの複数のユーザに対してデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶する鍵情報記憶部と、
前記所定のユーザから所定の送金実行サービスの指定を受け付ける受付部と、
前記指定された前記所定の送金実行サービスに基づいて、前記鍵情報記憶部の中から前記鍵情報を特定する特定部と、
所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨における前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、
を備え、
前記複数の鍵情報のそれぞれは、前記送金実行サービスごとに異なり、1以上の鍵を含み、かつ、前記送金実行サービスにおいて前記所定のユーザを一意に識別可能な情報を含む。
【発明の効果】
【0007】
本開示によれば、複数の決済業者からの支払いを包括的に扱い、顧客の利便性を図るための送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムを提供することができる。
【図面の簡単な説明】
【0008】
【
図1】実施形態1にかかる送金指示装置におけるハードウェアの構成を表すブロック図である。
【
図2】実施形態1にかかる仮想通貨の送金に関する情報システムの構成、及び、顧客の鍵を登録するシーケンスを表すブロック図である。
【
図3】実施形態1にかかる顧客取引所において表示される、鍵情報ページの例である。
【
図4】実施形態1にかかる送金指示装置にアクセスした際に表示される鍵登録ページの例である。
【
図5】実施形態1にかかる送金指示装置において、鍵の名前を知ることのできる情報を返すメソッドの例。
【
図6】実施形態1にかかる送金指示装置において、鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示すフローチャート図である。
【
図7】実施形態1にかかる送金指示装置における日本語の翻訳テーブルの例である。
【
図8】実施形態1にかかる送金指示装置における鍵情報テーブルの例である。
【
図9】実施形態1にかかる支払い手続きに関係する構成、及び、支払手続きの流れを示すシーケンスを表すブロック図である。
【
図10】実施形態1にかかる送金指示装置が生成する送金許可ページの例である。
【
図11】実施形態1にかかる送金指示装置において、店舗情報を保持する店舗情報テーブルの例である。
【
図12】実施形態2にかかる仮想通貨の送金に関する情報システムの構成、及び、支払い手続きのシーケンスを表すブロック図である。
【
図13】実施形態2にかかる鍵定義テーブルのルックアップテーブルの例である。
【
図14】実施形態2にかかる鍵情報テーブルの例である。
【
図15】実施形態2にかかる鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示す。
【
図16】実施形態2にかかる鍵登録ページの例である。
【
図17】実施形態2にかかる送金許可ページの例である。
【
図18】実施形態2にかかる送金指示装置において、換算レートを求める際のフローチャート図である。
【
図19】実施形態3にかかる送金指示システムにおける送金許可シーケンスのブロック図である。
【
図20】実施形態3にかかる送金指示システムにおけるスマートフォンアプリの送金許可画面の例である。
【
図21】実施形態3にかかる送金指示システムにおいて、店舗情報を保持する店舗情報テーブルの例である。
【
図22】実施形態3にかかる送金指示システムにおいて、各通貨の属性を保持する送金先アドレス生成制御テーブルの例である。
【
図23】実施形態3にかかる送金指示システムにおいて、送金先アドレス生成用の鍵などを保持するデータベーステーブルの例である。
【
図24】実施形態4にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
【
図25】実施形態4にかかる送金指示装置における送金許可ページの例である。
【
図26】実施形態4にかかる送金指示装置において、取引所に交換注文を出す際のフローチャート図である。
【
図27】実施形態5にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
【
図28】実施形態5にかかる送金指示装置における鍵情報データベースの例である。
【
図29】実施形態5にかかる送金指示装置における取引ログの1エントリーの例である。
【
図30】実施形態5にかかる送金指示装置における引き出し用ウェブページの例である。
【
図31】実施形態5にかかる送金指示装置における取引ログの1エントリーの例である。
【
図32】実施形態6にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
【
図33】実施形態6にかかる店舗サーバの商品ページの例である。
【
図34】実施形態6にかかる商品ページの価格表示欄付近のHTML記述の例である。
【
図35】実施形態7にかかる送金指示装置におけるハードウェアの構成を表すブロック図である。
【
図36】実施形態7にかかる仮想通貨の送金に関する情報システムの構成を表すブロック図である。
【
図37】実施形態7にかかる顧客の鍵を登録するシーケンスを表す図である。
【
図38】実施形態7にかかる送金指示装置に表示される取引所一覧画面の例である。
【
図39】実施形態7にかかる送金指示装置に表示される鍵登録画面の例である。
【
図40】実施形態7にかかる送金指示装置において、鍵の名前を知ることのできる情報を返すメソッドの例。
【
図41】実施形態7にかかる送金指示装置において、鍵登録画面の生成処理のうち、鍵を入力するテキストボックスを画面に追加する手順を示すフローチャート図である。
【
図42】実施形態7にかかる送金指示装置における鍵情報テーブルの例である。
【
図43】実施形態7にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
【
図44】実施形態7にかかる送金指示装置が送金指示を送る際のシーケンスを表す図である。
【
図45】実施形態7にかかる送金指示装置における送金許可画面の例である。
【
図46】実施形態8にかかるデジタル通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
【
図47】実施形態8にかかる送金指示装置が送金指示を送る際のシーケンスを表す図である。
【
図48】実施形態8にかかる送金指示装置における送金許可画面の例である。
【発明を実施するための形態】
【0009】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。尚、本実施形態で取り扱う送金対象の通貨は、通貨を電子的に表現したデジタル通貨である。デジタル通貨は、例えば、仮想通貨、電子マネー等が挙げられるが、法定通貨との換金が保証されるか否かは問わない。また、デジタル通貨は、硬貨や紙幣が存在しない法定通貨であっても、硬貨や紙幣と交換可能な法定通貨であってもよい。また、以下の説明におけるhttps(Hypertext Transfer Protocol Secure)は、暗号化通信の一例に過ぎず、他の暗号化通信技術を適用しても構わない。
【0010】
<実施形態1>
本実施形態では、デジタル通貨の取引所におけるサービス機能が送金実行サービスに組み込まれており、送金実行サービスで使われている鍵の名前がそのまま送金指示装置が提供するユーザインタフェースに表示される例を示す。
【0011】
図1は、実施形態1にかかる送金指示装置100におけるハードウェアの構成を表すブロック図である。同図において、CPU(Central Processing Unit、中央処理装置)101は、本実施形態にかかる送金指示装置の処理が実装されたプログラム1021を実行する。プログラムメモリ102は、CPU101により実行されるプログラム1021を記憶する。RAM(Random Access Memory)103は、CPU101によるプログラム実行時に、各種情報を一時的に記憶する揮発性記憶装置である。尚、CPU101によるプログラム実行時に、RAM103がプログラム1021を記憶することにより、RAM103はプログラムメモリ102の役目を果たすように実装することもできる。ハードディスク104は、RAM103に比べてより長期の間、各種情報を記憶する不揮発性記憶装置である。通信部105は、他の装置と通信するために利用される。CPU101、プログラムメモリ102、RAM103、ハードディスク104及び通信部105は、バス106により接続され、データや制御信号を互いに受け渡すために用いられる。本明細書では、CPUによるプログラム実行を説明するが、FPGA(Field-Programmable Gate Array)などの集積回路でも同様の機能が実装できる。
【0012】
また、本実施形態において、データベース機能が使用されるが、データベースに保管するデータは、ハードディスク104上やRAM103上などに記憶される。あるいは、他の装置上に記憶され、通信部105を利用して、読み書きすることも可能である。
【0013】
図2は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、顧客の鍵を登録する際のシーケンスを表すブロック図である。ここで、顧客取引所204は、1種類以上の仮想通貨の(通貨間の交換等の取引を含む)送金を仲介する仮想通貨交換業者が運用する情報システムである。顧客取引所204は、自己が管理する(登録済みの)複数のユーザ(例えば、顧客201)のそれぞれに対して、複数の仮想通貨を送金するサービスを提供する送金実行サービス2041を備える。ここで、顧客取引所204と送金実行サービス2041とは一対一で対応するものとする。そして、顧客取引所204は、鍵情報テーブル2042を記憶し、鍵情報テーブル2042は、顧客20421ごとに、鍵情報20422を対応付けて保存する。鍵情報20422は、送金実行サービス2041として提供されるAPI(Application Programming Interface)を利用するための鍵(API key等)204222と、その種別である鍵種別204221との組合せを複数、含むものである。つまり、顧客20421と鍵情報20422とは一対一で対応し、鍵情報20422には、鍵種別204221と鍵204222の組が1以上含まれる。よって、各鍵204222は、顧客20421ごとに異なる。そして、顧客取引所204は、WEBシステム2043としての機能を有し、顧客201からの鍵情報要求に応じて、鍵情報テーブル2042の中から顧客201を顧客20421として対応付けられた鍵情報20422を読み出して、鍵情報20422(鍵種別204221と鍵204222の組)を出力する。但し、鍵の保存方法や出力又は通知の仕方はこれに限定されない。
【0014】
顧客コンピュータ202は、顧客201が操作するコンピュータ端末であり、例えば、ブラウザ等(アクセス処理部2021)が動作するパーソナルコンピュータ、スマートフォン、タブレット等である。尚、顧客201は「送金元」、及び、所定の送金実行サービスを利用するユーザの一例である。
【0015】
送金指示装置203は、顧客及び取引所ごとの鍵情報を管理し、複数の取引所に対して送金指示を行うことが可能な情報処理装置である。尚、送金指示装置203は、複数台の情報処理装置により分散して、又は、冗長化して実現してもよい。送金指示装置203は、鍵定義テーブル2031と、鍵情報テーブル2032と、鍵登録処理部2033と、送金処理部2034とを備える。鍵定義テーブル2031は、複数の送金実行サービスのそれぞれごとに、前記鍵に関する定義を記憶するテーブルである。ここでは、鍵定義テーブル2031は、取引所及び言語ごとに、当該取引所で提供される送金実行サービスのAPIを利用する際に必要となる鍵について、当該取引所の情報システム上で用いられる鍵の名称の文字列を鍵の種別ごとに管理するテーブルである。鍵定義テーブル2031は、取引所20311、言語20312、鍵種別20313及び鍵名称20314が対応付けられている。尚、鍵名称は、取引所ごとに少なくとも1以上であればよい。当然のことながら、鍵種別20313は、鍵種別204221と同じ内容である必要はなく、配列内の位置で鍵種別を表してもよい。また、鍵定義テーブル2031は、言語ごとに別テーブルとしてもよい。
【0016】
鍵情報テーブル2032は、顧客20321及び取引所20322ごとに、鍵情報20323を管理するテーブルである。鍵情報20323には、鍵種別203231と鍵203232との組が複数含まれる。また、鍵情報20323は、顧客20321及び取引所20322の組ごとに異なり、少なくとも1以上の鍵を含み、かつ、取引所20322において顧客20321を一意に識別可能な情報を含むものであればよい。例えば、鍵の1つは取引所20322における顧客20321のユーザ識別子、あるいはユーザ識別子に変換可能な情報である。また、例えば、もう1つの鍵は、取引所20322と通信を行う上で使用する暗号化・電子署名用の秘密鍵である。
【0017】
鍵登録処理部2033は、顧客からの鍵の登録要求に応じて鍵定義テーブル2031を参照して鍵登録ページを生成して返信し、鍵登録ページを介して入力された鍵を鍵情報テーブル2032に登録する。送金処理部2034は、顧客からの送金要求に応じて、指定された仮想通貨及び金額について指定された取引所に対して、鍵情報テーブル2032に登録された鍵を用いて送金先への送金指示を行う。
【0018】
続いて、
図2を用いて顧客の鍵を登録する処理の流れを説明する。まず、顧客コンピュータ202のアクセス処理部2021は、顧客201の操作に応じて、顧客取引所204に対して鍵情報要求を送信する(S101)。例えば、顧客コンピュータ202は、顧客201がアカウントを持つ顧客取引所204のウェブサイトにログインし、顧客取引所204のWEBシステム2043は、鍵情報テーブル2042を参照し、顧客201に対応付けられた鍵情報20422を読み出して、鍵204222とその鍵種別204221の名称の文字列とを対応付けた鍵情報ページを生成し、顧客コンピュータ202に表示させるために、鍵情報ページを送信する(S102)。尚、顧客取引所204と顧客コンピュータ202の間の通信方法については本発明の対象外のため、説明を省く。アクセス処理部2021は、顧客取引所204から受信した鍵情報ページを画面(不図示)に表示する。顧客コンピュータ202に表示される鍵情報ページ300は、例えば
図3のように鍵が2つとし、それぞれ鍵名称311「APIキー」と鍵名称321「秘密鍵」という名前が付いているものとする。そして、鍵情報ページ300は、鍵名称311に対応付けられた鍵312と、鍵名称321に対応付けられた鍵322とが表示されていることを示す。よって、顧客201は、顧客コンピュータ202の画面に表示された鍵情報ページ300を介して、鍵名称ごとの鍵の文字列を目視及びコピーする等により、鍵を入手できる。
【0019】
次に、顧客201は顧客コンピュータ202を操作して、先ほど入手した鍵を送金指示装置203に登録する。本実施形態では、送金指示装置203はウェブサーバの機能を持つものとする。そのため、顧客コンピュータ202と送金指示装置203とは原則としてhttpsを用いた通信を行う。まず、顧客コンピュータ202のアクセス処理部2021は、送金指示装置203が提供する鍵登録のためのウェブページ(鍵登録URL(Uniform Resource Locator))にアクセスする(S111)と、顧客201がまだログインをしていない場合、送金指示装置203は、顧客コンピュータ202にログインページを返信する(S112)。これに応じて、アクセス処理部2021は、受信したログインページを画面に表示する。顧客201がログインページに対してユーザ名とパスワードを入力すると、アクセス処理部2021はこれを送金指示装置203へ、認証情報として送信する(S113)。尚、アクセス処理部2021は、併せて、鍵の登録対象の取引所の識別情報(取引所ID等)を送金指示装置203へ送信してもよい。あるいは、前記鍵登録URLに識別情報を含めてもよい。この認証情報が送金指示装置203に事前に登録してあるものと一致すれば、送金指示装置203の鍵登録処理部2033は鍵登録ページを生成する。このとき、鍵登録処理部2033は、鍵定義テーブル2031を参照し、ステップS113等で受信した取引所ID及びアクセス処理部2021側の表示言語に基づき、鍵種別20313及び鍵名称20314を読み出して、鍵名称20314に対応する鍵の入力欄を含む鍵登録ページを生成する。そして、鍵登録処理部2033は、顧客コンピュータ202に、生成した鍵登録ページを送信する(S114)。このとき、認証状態を維持するために、鍵登録処理部2033はクッキーを顧客コンピュータ202に送ることもできる。アクセス処理部2021は、送金指示装置203から受信した鍵登録ページを画面に表示する。
【0020】
顧客コンピュータ202に表示される鍵登録ページ400は、例えば
図4のように、取引所名称401について、鍵名称411「APIキー」と鍵名称421「秘密鍵」に対応する鍵を入力するためのテキストボックス(鍵入力欄412及び422)を含む。顧客201は、顧客コンピュータ202に表示される鍵登録ページ400における、「APIキー」と「秘密鍵」のそれぞれに対応する鍵入力欄412及び422に、
図3からコピーした情報を入力する。
【0021】
ここで、「APIキー」と「秘密鍵」という名前(鍵名称)は、顧客取引所204の情報システム上で扱われる表現(文字列)に合わせてある。これが可能なのは、鍵定義テーブル2031において取引所と言語毎に鍵の名前を記録しているためである。このようにすることで、鍵登録処理部2033における鍵登録ページ(ウェブページ)の生成処理の実装が一度完了すれば、その後はHTMLなどのフロントエンド技術を知らないバックエンド技術者でも、新たな取引所に対応するプログラムを書き、この鍵の名前の対応を記述するだけで、鍵登録ページを自動生成できる。これにより、少ない人数でより多くの取引所に素早く対応することができるため、非常に重要である。また、鍵の名称が鍵登録ページと取引所の鍵情報ページとで一貫性があるため、顧客はどの鍵を入力すれば良いのか迷う必要がないため、ユーザビリティの観点からも有用である。
【0022】
これを実現する一つの方法が、オブジェクト指向による継承と、国際化(Internationalization)技術を利用することである。ここでは、
図5にPython言語による具体例を示す。バックエンド技術者は
図5のメソッドを全ての取引所クラスに定義するだけで良い。ここで取引所クラスとは、顧客取引所毎に定義され、各取引所に関する情報を保持するクラスである。
図5のメソッドは、文字列(str)と真偽値(bool)の対(tuple)を配列(list)に並べて返す処理を行うものである。ここで、配列の要素はそれぞれ1つの鍵に対応する。そのため、鍵が2種類ある場合、配列の長さは2となる。
【0023】
鍵登録処理部2033は、これらの情報に基づき
図4のウェブページを生成する。ここで、鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を
図6に示す。前提として、当該手順の開始時には、ウェブページ上のテキストボックス以前の部分については既に生成されているものとする。また、鍵登録処理部2033は、ステップS111又はステップS113で受け付けた取引所IDを特定している。まずステップ601で、鍵登録処理部2033は、顧客コンピュータ202のブラウザで選択されている表示言語を取得し、変数localeに代入する。次にステップ602で、鍵登録処理部2033は、
図5のメソッドを呼び出し、得られた配列をnamesという変数に代入する。そして、配列namesの各要素のそれぞれについて(つまり、eachとして)、ステップ603からステップ606またはステップ607までを繰り返す。ステップ603では、鍵登録処理部2033は、まずlocaleに対応した翻訳テーブル(鍵定義テーブル2031)よりeachの最初の要素に対応した文字列を取得し、これを変数labelに代入する。翻訳テーブルについては後に説明する。次のステップ604で、鍵登録処理部2033は、変数labelに代入された文字列をテキストボックスに付随するラベルとして、ウェブページ上に追加する。ここで、eachの第2要素は、テキストボックスの属性を表す。鍵登録処理部2033は、ステップ605でeach[1]がTrueであると判定した場合、ステップ607で顧客201が入力した文字列が伏せ字で表示されるテキストボックスをウェブページに追加する。逆に、each[1]がFalseの場合、鍵登録処理部2033は、入力した内容が見えるテキストボックスをウェブページに追加する。鍵登録処理部2033は、以上のループの後、ウェブページの残りの部分を追加し、ウェブページを完成する。
【0024】
ここで、上述した翻訳テーブル(鍵定義テーブル2031)は、例えば
図7のようにルックアップテーブルになっており、左の列(キー)にある文字列を検索し、右の列(鍵名称20314)の文字列を取得する形式を取る。ここで、「キー」は、例えば、取引所20311及び鍵種別20313を組み合わせたものであるが、これに限定されない。
図7は日本語の翻訳テーブルの例であるが、この翻訳テーブルを対応言語(言語20312)の数だけ用意する。取引所毎言語毎に翻訳テーブルを用意しても良いが、この例では全ての取引所で用いられる鍵名称20314の文字列を1つの翻訳テーブルに保持している。左の列(キー)の文字列は、
図5のメソッドが返す文字列である。翻訳テーブルは、ハードディスク104上のファイルから読み込んでも、データベース内のテーブルであっても、保存場所は問わない。プログラムとは別の場所に翻訳テーブルを持つと、取引所の表現が変わった場合に、プログラマでない担当者でも鍵登録ページの表現を追随させることができる。
【0025】
図2に戻り説明を続ける。アクセス処理部2021は、
図4の鍵登録ページ400の鍵入力欄412及び422に入力された鍵の文字列を鍵名称411及び421のそれぞれに対応する鍵種別に対応付けた鍵情報を、送金指示装置203へ送信する(S115)。そして、鍵登録処理部2033は、受信した鍵情報を鍵情報テーブル2032に登録する。例えば、鍵登録処理部2033は、ログインユーザを顧客20321、取引所IDを取引所20322として、受信した鍵情報に含まれる鍵種別203231及び鍵203232の組と対応付けて、鍵情報テーブル2032に追加又は更新する。
【0026】
ここで、鍵情報テーブル2032の例を
図8に挙げる。取引所の列には、取引所を表す識別子(取引所ID等)を保持する。顧客の列には、顧客を表す識別子(ログインされたユーザID等)を保持する。鍵情報の列には、
図4で入力した鍵がjson(JavaScript(登録商標) Object Notation)形式で保持されている。json形式の各対は、鍵の内部的な名前と
図4で入力した鍵の値となっている。尚、鍵情報は配列でも構わないが、鍵情報を可変要素数の構造に保持している理由は、取引所によって鍵の数が異なるためである。尚、セキュリティを確保するために、鍵情報は暗号化するべきであるが、暗号化の方法は公知技術を用いることができるため説明を省略する。また、OAuthなどの方法によりアクセストークンを入手する方法がある取引所においては、この方法によってアクセストークンを入手し、これを鍵として鍵情報テーブル2032に登録することもできる。
【0027】
続いて、
図9を用いて本実施形態にかかる支払い手続きに関係する構成を説明する。まず、
図9では、
図2の構成の一部を省略し、また、支払い手続きに関係する構成を追加している。送金指示装置203は、
図2の構成に加え、店舗情報テーブル2035を備えるものとする。店舗情報テーブル2035は、後述する店舗サーバ205を運用する店舗に関する情報を管理するテーブルである。特に、店舗情報テーブル2035は、店舗公開鍵20351を店舗ごとに管理しているものとする。店舗公開鍵20351は、店舗サーバ205の暗号用の公開鍵である。尚、店舗情報テーブル2035のその他の構成は、後述する。
【0028】
店舗サーバ205は、電子商取引のWEBサイトを提供するコンピュータ装置である。尚、店舗サーバ205は、これを運用する店舗の業者と対応し、「送金先」の一例といえる。店舗サーバ205は、記憶装置に承認URL2051を保存している。承認URL2051は、送金許可のために顧客コンピュータ202がアクセスするべき送金指示装置203のURLである。尚、店舗サーバ205のその他の構成は、公知技術を用いて実現可能であるため、詳細な説明を省略する。店舗取引所207は、店舗サーバ205を運用する店舗の業者がユーザとして登録されている仮想通貨の取引所である。よって、店舗取引所207の構成は、顧客取引所204と同等であるため、詳細な説明を省略する。台帳208は、任意の仮想通貨の取引記録、例えば、ブロックチェーンを便宜上、機能ブロックとして記載したものである。
【0029】
上記を踏まえ、
図9を用いて支払手続きの流れを説明する。まず、顧客201が顧客コンピュータ202を利用して、店舗サーバ205での発注シーケンスに入る。発注シーケンスは、個々の店舗によって異なるので、ここでは説明しない。顧客201は、発注シーケンスの最後に購買を確定する操作を行う。店舗によっては、「注文を確定する」というボタンを顧客201がクリックする。これにより、アクセス処理部2021は、送金を開始するトリガーを店舗サーバ205へ送信する(S201)ことになる。すると、店舗サーバ205は、店舗ID、取引ID、通貨、金額、送金先アドレスの組(以後、「支払情報」と呼ぶ。)を店舗サーバ205の秘密鍵(非公開鍵)で電子署名した情報と、送金許可のための承認URL2051を顧客コンピュータ202に返信する(S202)。ここで「店舗ID」とは店舗に固有の識別子である。「取引ID」は、同じ店舗内であれば固有であり、支払いを識別する識別子である。アクセス処理部2021は、受信した電子署名付きの支払情報をボディ部に格納し、httpsにより承認URL2051にPOSTリクエストを発行する(アクセスする)(S203)。送金指示装置203の送金処理部2034は、店舗公開鍵20351を用いて、受信した支払情報が店舗サーバ205の秘密鍵によって電子署名されていることを確認する。そして、この時点でログインされていなければ(有効なクッキーが顧客コンピュータ202に保存されていなければ)、送金処理部2034は、ログインページを顧客コンピュータ202へ返信する(S204)。これに応じて、アクセス処理部2021は、受信したログインページを画面に表示する。顧客201がログインページに対してユーザ名とパスワードを入力すると、アクセス処理部2021は、その認証情報(入力されたユーザ名とパスワードの組を含む)を送金指示装置203へ送信する(S205)。送金処理部2034は、受信した認証情報が予め保存されているものと一致していれば、支払情報の中の通貨と金額を含んだウェブページ(送金許可ページ)を生成する。そして、送金処理部2034は、生成した送金許可ページを送信詳細として顧客コンピュータ202へ送信する(S206)。アクセス処理部2021は、送金指示装置203から受信した送金許可ページを画面に表示する。
【0030】
図10は、本実施形態1にかかる送金許可ページ1000の例である。送金許可ページ1000は、店舗名1001と、送金額1002と、取引所選択欄1003と、中止ボタン1004と、承認ボタン1005等を含む。店舗名1001は、送金先の店舗名を表示する欄である。ここで、送金指示装置203が備える店舗情報テーブル2035は、一例として
図11のような構成とする。ここでは、店舗名の列にjson形式のデータを保持している。構造体のキーとして表示言語を、値として店舗名を持つ。構造体に所望の言語が含まれていない場合には、キーが”default”の値を使用する。そのため、送金処理部2034は、受信した支払情報に含まれる店舗IDにより店舗情報テーブル2035を検索して、店舗名を取得する。このとき、送金処理部2034は、顧客コンピュータ202のブラウザに指定されている表示言語をキーとしてこの構造体を検索することで、その表示言語に合わせた店舗名を取得できる。そして、送金処理部2034は、取得した店舗名を送金許可ページ1000の店舗名1001に挿入する。当然のことながら、
図11のテーブルには店舗に関する他の列があっても良い。
【0031】
送金額1002は、発注に伴い、顧客側から店舗側へ送金される金額を表示する欄である。そのため、送金指示装置203は、受信した支払情報に含まれる通貨における金額を送金額1002に挿入する。ここで、顧客201の設定として基軸となる通貨(基軸通貨)が送金指示装置203内のデータベースに保存されている場合、送金額をその基軸通貨の価値に換算した換算額をウェブページに追加することが可能である。これにより、顧客201は、自身の基軸通貨に換算した額により送金額の現在の価値を容易に把握することができる。そのためには、送金指示装置203は、予め顧客取引所204から板情報を入手しておくこととなる。「板情報」とは、その取引所での2通貨間の買値と売値の一覧である。板情報が送金通貨の売り買いを基軸通貨で表した一覧である場合、送金額の換算額は、(送金額 × 最大買値 - 交換手数料)である。逆に、板情報が基軸通貨の売り買いを送金通貨で表した一覧である場合、送金額の換算額は、(送金額 / 最小売値 - 交換手数料)である。交換手数料が送金通貨によって引かれる場合には、それぞれ((送金額 - 交換手数料)× 最大買値)と((送金額 - 交換手数料)/ 最小売値)である。ここで、最大買値又は最小売値を換算レートとみなすことができる。
【0032】
また、取引所選択欄1003は、送金元の取引所を選択するドロップダウンメニューである。送金処理部2034は、鍵情報テーブル2032の中から、ログインしている顧客201に関連付けられた鍵が登録されている取引所のリストを取得する。そして、送金処理部2034は、取引所選択欄1003が選択されると取得したリストが表示されるように送金許可ページ1000を生成する。よって、顧客201は、表示されたリストの中から所望の取引所を選択できる。尚、顧客取引所204は、後にログインしている顧客201に関連付けられたこの鍵を元に顧客201のアカウントを特定することで、送金元を決定することができる。尚、上記換算額が表示されている場合に顧客201が取引所選択欄1003により他の取引所を選択すると、アクセス処理部2021は、送金指示装置203へその旨を通知する。そして、送金処理部2034は、上記に基づき、選択された取引所における換算額を再度算出し、ウェブページを更新して顧客コンピュータ202へ送信する。これにより、アクセス処理部2021は、更新後の換算額を表示する。
【0033】
また、中止ボタン1004は、支払いプロセスを中止させるためのものである。顧客201が中止ボタン1004を選択した場合、アクセス処理部2021は、送金指示装置203へその旨を通知し、送金処理部2034は店舗サーバ205に支払いプロセスの中止の旨を通知し、支払いプロセスは中止される。具体的には、送金処理部2034は、店舗情報テーブル2035内の店舗に応じた通知URLの列よりURL文字列を取得し、末尾に/cancelを追加したURLにPOSTリクエストを店舗サーバ205へ送信することで、「通知」を実現してもよい。この際、送金処理部2034は、POSTリクエストのボディ部に、取引IDを含む情報について送金指示装置203の秘密鍵で電子署名した情報を入れる。店舗サーバ205はこの取引IDを元に注文のキャンセル手続きを行う。
【0034】
また、承認ボタン1005は、顧客201が送金を許可して、支払いプロセスを継続させるためのものである。顧客201が承認ボタン1005を選択した場合、アクセス処理部2021は、送金許可ページ1000上に表示された通貨、送金額及び取引所による送金が許可された旨を送金指示装置203へ通知し(S207)、送金処理部2034は、店舗サーバ205に送金許可の旨を通知する(S208)。具体的には、送金処理部2034は、店舗情報テーブル2035内の店舗に応じた通知URLの列よりURL文字列を取得し、末尾に/confirmedを追加したURLにPOSTリクエストを送信することで、「通知」を実現してもよい。この際、送金処理部2034は、POSTリクエストのボディ部に、取引IDを含む情報について送金指示装置203の秘密鍵で電子署名した情報を入れる。
【0035】
店舗サーバ205に送金許可の旨の通知を送った後、送金指示装置203の送金処理部2034は顧客取引所204に送金指示を送信する(S209)。
【0036】
より具体的には、送金処理部2034は、送金を許可つまり承認したユーザ(ログインユーザ)と、送金許可された取引所(送金許可ページ1000上で選択された取引所、つまり送金実行サービス2041)との組に対応付けられた鍵情報を、鍵情報テーブル2032の中から特定して読み出す。そして、送金処理部2034は、特定された鍵情報を用いて、選択された取引所(ここでは、顧客取引所204)の送金実行サービス2041に対して、送金許可されたデジタル通貨及び送金額について送金先である店舗の送金先アドレスへの送金指示を送信する。
【0037】
ここで、送金指示の送信方法は取引所毎に異なるが、例えばhttps://exchange.com/api/withdrawにPOSTリクエストを送ることで行う。このとき、送金処理部2034は、鍵情報テーブル2032の取引所に対応する行の鍵情報の列における鍵の1つ(例えば、秘密鍵)を用いて以下の情報を電子署名した情報を、リクエストのボディ部に含める。
・鍵情報テーブル2032の取引所に対応する行の鍵情報の列からもう1つの鍵(例えば、APIキー)
・(送金許可された)通貨
・(送金許可された)送金額
・(送金許可された)送金先アドレス
【0038】
顧客取引所204の送金実行サービス2041は、送金指示装置203からの送金指示を受信した場合に、送金指示に用いられた鍵情報に基づいてユーザ(顧客201)を特定し、送金指示に含まれる通貨及び送金額から当該ユーザが利用可能な送金元アドレスを特定する。例えば、送金実行サービス2041は、受信した送金指示に含まれるAPIキーによりユーザが顧客201であること及び当該ユーザの鍵を特定する。そして、送金実行サービス2041は、受信した送金指示に含まれる情報に電子署名を、特定した鍵により検証し、検証された場合に、受信した送金指示に含まれる通貨に基づいて、当該特定したユーザに対応する送金元アドレスを特定する。このとき、送金実行サービス2041は、送金元アドレスとして固定のものを用いても、または、動的に生成したものを用いてもよい。
その後、送金実行サービス2041は、特定された送金元アドレスから送金指示に含まれる送金先アドレスへ、送金指示に含まれる送金額を、送金指示に含まれる通貨に対応する台帳208に送金事実(取引記録)を書き込むことにより、送金を行う(S210)。例えば通貨がビットコインの場合、送金実行サービス2041は、ビットコインのブロックチェーンに送金事実を書き込む。
【0039】
顧客取引所204に送金指示を出した後、送金指示装置203の送金処理部2034は台帳208を監視し続け、送金先アドレスへの送金が完了したと見なせるかどうかを判断する。通貨がビットコインの場合、送金処理部2034は、ブロックチェーン上で予め指定された回数の承認がなされた場合に、送金が完了したと見なす。尚、送金処理部2034は、送金情報で指定された所定のデジタル通貨に対応する取引記録が承認条件を満たす場合に送金が完了したとみなす。ここで、承認条件を可変としてもよい。例えば、承認条件は、送金指示装置203又は外部(例えば、店舗サーバ205等)により更新されたものであってもよい。送金が完了したと見なされたら、送金処理部2034は店舗サーバ205に着金通知を送信する(S211)。具体的には、送金処理部2034は、店舗情報テーブル2035内の店舗に応じた通知URLの列よりURL文字列を取得し、末尾に/transferredを追加したURLにPOSTリクエストを送信することで、「着金通知」を実現してもよい。この際、送金処理部2034は、POSTリクエストのボディ部に、取引IDを含む情報について送金指示装置203の秘密鍵で電子署名した情報を入れる。
【0040】
尚、上記の説明では、より多くのリクエストを処理できるようにするためのロードバランサに関連する記述を省略した。但し、本実施形態は、多数のリクエストに対する負荷分散のためにロードバランサ等の公知技術を用いることができる。また、鍵登録処理部2033は、鍵登録部の一例である。また、送金処理部2034は、送金情報取得部、検証部、換算部、表示情報生成部、特定部、送金指示部及び着金通知部の一例である。そして、送金指示装置100内のCPU101は、プログラム1021を実行することにより、鍵登録処理部2033及び送金処理部2034として機能する。また、「支払情報」は、所定のデジタル通貨における送金額と送金先とが指定された送金情報の一例である。
【0041】
以上のように、本実施形態では、顧客の認証後に送金詳細が顧客コンピュータに表示される送金指示装置の例を示した。本実施形態では、顧客取引所が提示する鍵の名称を、取引所毎及び表示言語毎に保持することにより、顧客が迷わず送金指示装置にそれらの鍵を登録できるようにした。そのため、複数の交換業者を利用する顧客の利便性が向上できる。また、このようにすることによって、同時に送金指示装置の開発効率を上げ、より早くより多くの取引所に対応することができる。つまり、複数の交換業者に対する送金指示を包括的に扱うことができる。
【0042】
<実施形態2>
本実施形態2は、実施形態1の変形例であり、送金許可シーケンスの効率を優先して、顧客の認証と同時に送金許可も行うシステムの例を示す。
【0043】
本実施形態2にかかる送金指示装置におけるハードウェアの構成は
図1と同様であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム1021には、本実施形態2にかかる送金指示装置の処理が実装されているものとする。
【0044】
鍵を登録するシーケンスは、実施形態1と同じように
図2に従うものとする。但し、本実施形態2は、実施形態1と比べて開発効率を優先する例を示す。具体的には、鍵の個数と順番だけを顧客取引所と鍵登録ページとで一致させる。
【0045】
図12は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、支払い手続きのシーケンスを表すブロック図である。尚、
図2又は
図9と同じ構成には同じ符号を付し、説明を省略する。送金指示装置203aは、送金指示装置203と比べて鍵定義テーブル2031a、鍵情報テーブル2032a、鍵登録処理部2033a及び送金処理部2034aを備える。
【0046】
鍵定義テーブル2031aは、取引所20311ごとの鍵個数20315を管理するテーブルである。鍵定義テーブル2031aを実現する一つの方法として、ルックアップテーブルを利用する方法がある。尚、鍵の個数の代わりに鍵の名称を保持し、適宜、鍵の名称の個数をカウントすることにより、実施形態1においても、テーブルを利用して実現できることは言うまでもない。
図13は、鍵定義テーブル2031aのルックアップテーブルの例を示す。
【0047】
図12に戻り説明を続ける。鍵情報テーブル2032aは、顧客20321及び取引所20322ごとに、鍵情報20323aを管理するテーブルである。鍵情報20323aは、複数の鍵203232を登録順で保持する。
図14は、鍵情報テーブル2032aの例を示す。鍵情報の列には、複数の鍵が登録順にカンマ(,)で接続されていることを示す。ここで、鍵情報は可変長配列として表現されている。ここで、配列に格納される順番は、後述する鍵登録ページに表示される順番に対応する。
【0048】
図12に戻り説明を続ける。鍵登録処理部2033aは、顧客からの鍵の登録要求に応じて鍵定義テーブル2031aを参照して鍵登録ページを生成して返信し、鍵登録ページを介して入力された鍵を鍵情報テーブル2032aに登録する。
図15は、本実施形態における鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示す。尚、
図15のフローを実行する前に、ウェブページの上部分は既に生成されているものとする。まず、ステップ1401で、鍵登録処理部2033aは、顧客コンピュータ202から受信した取引IDにより鍵定義テーブル2031a内を検索し、対応する取引所の鍵の個数を取得し、取得した鍵の個数を変数key_countに代入する。次に、ステップ1402からステップ1404を昇順のループカウンタ変数をdとしてkey_count回だけ繰り返す。ループの初めのステップ1402では、鍵登録処理部2033aは、変数labelに文字列“Key %d”を代入する。ここで%dは変換指定子であり、実際の表示文字列では、%dの部分が変数dの値(整数値)で置き換えられることを示す。次にステップ1403で、鍵登録処理部2033aは、ウェブページに変数labelの値を表示するラベルを追加する。その次のステップ1404で、鍵登録処理部2033aは、ステップ1403で追加したラベルに付随する形でテキストボックスを追加する。フローの実行が終わったら、鍵登録処理部2033aは、ウェブページの残りの部分を完成させる。これにより、取引所の鍵の個数に応じたテキストボックスとそのラベルを含んだウェブページ(鍵登録ページ)が生成される。
【0049】
図16は、本実施形態における鍵登録ページ400aの例である。鍵登録ページ400aは、
図4の鍵登録ページ400と比べて、鍵名称411a及び421aが、汎用的な表記(“Key”)に順序を示す番号(”1”,”2”)が付されたものとなったことを示す。つまり、鍵名称411a及び421aは、いずれの取引所であっても同一の名称が表示される。
【0050】
顧客201は顧客コンピュータ202に表示される鍵登録ページ400aに顧客取引所204から入手した鍵を入力する。これに応じて、アクセス処理部2021は、鍵登録ページ400aの鍵入力欄412及び422に入力された鍵の文字列を表示順序と対応付けた鍵情報を、送金指示装置203aへ送信する。ここでは、アクセス処理部2021は、鍵入力欄412に入力された鍵の文字列を表示順序「1」、鍵入力欄422に入力された鍵の文字列を表示順序「2」に対応付けて鍵情報とする。そして、鍵登録処理部2033aは、受信した鍵情報を、ログインユーザを顧客20321、取引所IDを取引所20322として、受信した鍵情報に含まれる順序に従って鍵203232を、鍵情報テーブル2032aに追加又は更新する。
【0051】
図12に戻り説明を続ける。本実施形態では、顧客201の通貨を扱う顧客ウォレット206と取引所204aは別のサービスであると仮定する。顧客ウォレット206に預金管理や送金実行の機能はあるものの取引所機能がない場合や、顧客201が指定する基軸通貨を顧客取引所(ウォレット)が扱わない場合などがこれに該当する。また、顧客ウォレット206は、鍵情報テーブル2032aに保存された鍵203232を用いて利用可能な送金実行サービス2061を有するものとする。尚、店舗ウォレット207aは、店舗取引所207とは異なるサービスであるが、店舗取引所207を用いても構わない。また、店舗サーバ205aは、上述した店舗サーバ205の構成に加え、記憶装置に公開鍵2052をさらに保存している。ここで、公開鍵2052は、送金指示装置203aの暗号用の公開鍵である。一方、店舗サーバ205aは、記憶装置には予め承認URLを保存していない。
【0052】
続いて、
図12を用いて、支払手続きの流れを説明する。まず、顧客201が顧客コンピュータ202を利用して、店舗サーバ205aでの発注シーケンスに入る。顧客201は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部2021は、送金を開始するトリガーを店舗サーバ205aへ送信する(S201)。ここで、店舗サーバ205aは送金指示装置203aとWebSocket Secureのような双方向通信のセッションで長期接続されている。そして、店舗サーバ205aは、店舗ID、通貨、金額、送金先アドレスの組に店舗サーバ205aの秘密鍵で電子署名した情報(以後、「支払情報」と呼ぶ。)を送金指示装置203aに送る(S202-1)。つまり、実施形態2にかかる支払情報は、取引IDを含まなくてよい。送金指示装置203aの送金処理部2034aは、店舗公開鍵20351を用いて、店舗サーバ205aの秘密鍵による電子署名を確認した後、取引IDを生成し、取引IDに対して送金指示装置203aの秘密鍵で電子署名した情報(以下、単に「取引ID」という。)を、送金許可のための承認URLにパラメータとして付加して、店舗サーバ205aに送信する(S202-2)。ここで、取引IDは、他の装置が生成できない規則で生成されているのが望ましい。例えば、連続的に生成される数値を送金指示装置203aの秘密鍵で電子署名したような識別子を用いることができる。また、送金指示装置203aは、この取引IDと先程の支払情報とを対応付けてデータベース(不図示)に格納する。同時に生成時刻を記録することも可能である。WebSocket Secureで店舗サーバ205aのSSL証明書を要求するよう設定されている場合、支払情報は電子署名しなくて良い。
【0053】
店舗サーバ205aは、受信した承認URL(パラメータに取引IDを含む)を顧客コンピュータ202へ送信する(S202-3)。そして、顧客コンピュータ202は、httpsにより受信した承認URLに対してGETリクエストを送る(S203a)と、送金指示装置203aは、これを受信する。送金指示装置203aの送金処理部2034aは、承認URLのパラメータから取引IDを抽出し、これを使ってデータベースから支払情報を読み込む。このとき、データベースに記録された生成時刻から、取引IDの有効期限を確認しても良い。送金処理部2034aは、この支払情報から、送金許可ページ1000aを生成し、送金詳細として顧客コンピュータ202へ返信する(S206a)。
【0054】
このとき、送金処理部2034aは、送金許可ページ1000aの生成において、実施形態1と同じように店舗IDを使って店舗情報テーブル2035より店舗名を取得する。また、送金処理部2034aは、支払情報の中から通貨と金額を抽出する。ここで、実施形態2では、送金処理部2034aが送金通貨の量をも考慮して基軸通貨への換算レートを求める場合について説明する。
【0055】
図17は、送金許可ページ1000aの例を示す。送金許可ページ1000aはユーザ名とパスワードを入力するためのテキストボックス(ユーザ情報入力欄1006)があり、顧客201がこれら情報を入力することにより、認証と送金許可を同時に行うことができる。また、顧客201が基軸通貨を選択するためのドロップダウンメニュー(基軸通貨選択欄1002c)が用意されている。使用するウォレットは予め送金通貨毎のデフォルトとして設定されているものとする。
【0056】
また、送金許可ページ1000aは、送金額1002aと基軸通貨換算額1002bとを含む。送金額1002aは、支払情報に含まれる通貨及び金額である。基軸通貨換算額1002bは、上述した実施形態1で説明した「換算額」を表示する欄である。ここでは、換算額は、既定の取引所における「板情報」に基づき、送金額1002aから顧客201の基軸通貨に換算された金額である。尚、送金処理部2034aは、取引所から定期的に板情報を取得してもよい。
【0057】
図18は、換算レートを求める際のフローチャート図である。まずステップ1700で、送金処理部2034aは、取引所204aより板情報を入手し、配列boardに代入する。板情報が送金通貨の売り買いを基軸通貨で表した一覧である場合、送金処理部2034aは、boardに(買値、取引量)の対を買値が降順になるようにソートした配列を代入する。逆に、板情報が基軸通貨の売り買いを送金通貨で表した一覧である場合、送金処理部2034aは、boardに(売値、取引量)の対を売値が昇順になるようにソートした配列を代入する。次にステップ1701で、送金処理部2034aは、送金額を線形変換して変数sizeに代入する。この時の線形係数と定数項は通貨毎に調整する必要がある。次にステップ1702からステップ1704のループを変数iを昇順のループカウンタ変数として繰り返す。まずステップ1702で、送金処理部2034aは、変数askbidに配列boardのi番目の要素を代入する。これにより、構造体askbidのpriceフィールド(askbid.price)には買値または売値が、volumeフィールド(askbid.volume)には取引量が保持されることとなる。次のステップ1703では、送金処理部2034aは、変数sizeからaskbid.volumeだけ減算する。次のステップ1704で、送金処理部2034aは、変数sizeと0の比較が行われ、sizeが0より大きければ、ループを続ける。逆にsizeが0以下であれば、ステップ1705へと進む。ステップ1705では、送金処理部2034aは、その時のaskbid.priceを換算レートとする。boardに買値が保持されている場合、送金額の換算額は、(送金額 × 換算レート - 交換手数料)となる。boardに売値が保持されている場合には、送金額の換算額は、(送金額 / 換算レート - 交換手数料)となる。ただし、交換手数料が送金通貨で行われる場合には、それぞれ((送金額 - 交換手数料)× 換算レート)と((送金額 - 交換手数料)/ 換算レート)となる。つまり、この例では、換算額を算出する際に、実際の取引量(注文における取引額)を累積して、送金額に達したときの買値又は売値を換算レートとして用いることを示す。以上のように換算レートを求めるのは、通貨によっては取引量が少なかったり、あるいは売値または買値の提示が次の瞬間に消えてしまったりして、多めの取引をしようとした場合、思わぬ価格の乱高下に見舞われることがあるためである。
【0058】
図12に戻って、送金許可後のシーケンスを説明する。顧客コンピュータ202のアクセス処理部2021は、受信した送金許可ページ1000aを表示する。そして、顧客201は、送金許可ページ1000aに対してユーザ名とパスワードを入力し、必要に応じて基軸通貨選択欄1002cの中から所望の通貨を選択して、基軸通貨換算額1002bの表示を切り替える。その後、顧客201が承認ボタン1005を選択した場合、アクセス処理部2021は、認証情報及び送金許可を送金指示装置203aへ送信する(S207a)。具体的には、アクセス処理部2021は、送金許可ページ1000aのユーザ情報入力欄1006に入力されたユーザ名とパスワードの組を含めて認証情報として送信する。また、アクセス処理部2021は、送金許可ページ1000a上に表示された通貨、送金額及び取引所による送金が許可された旨を送金指示装置203aへ送信する。
【0059】
その後、送金指示装置203aの送金処理部2034aは店舗サーバ205aに送金許可通知を送り(S208)、顧客ウォレット206に送金指示を発行する(S209a)。送金指示の送信方法は顧客ウォレット206が定義するが、送金許可された送金先及び送金額、並びに、鍵を含む情報を送信するなどできる。このとき、送金処理部2034aは、鍵情報テーブル2032aから顧客と取引所(顧客ウォレット206)が合致する行を検索し、鍵情報を取得する。尚、顧客ウォレット206が複数の通貨を扱うウォレットであれば、送金処理部2034aは、送金指示に送金通貨も含めて指定する。
【0060】
顧客ウォレット206の送金実行サービス2061は、送金指示装置203aから受信した送金指示を受信した場合に、送金指示に含まれる送金先へ、送金指示に含まれる送金額を送金する(S210)、例えば、送金実行サービス2061は、通貨に対応する台帳208に送金事実を書き込むことにより、送金を行う。その後、送金実行サービス2061は、台帳208を監視し続ける。
【0061】
そして、送金指示装置203aは、顧客ウォレット206の定める方法によって着金の通知を待つ。例えば、送金実行サービス2061が台帳208のブロックチェーン上で予め指定された回数の承認がなされた場合に、送金が完了したと見なし、送金指示装置203aに対して着金通知を送信する(S211-1)。送金指示装置203aの送金処理部2034aは、顧客ウォレット206より着金通知を受け取ると、長期接続のセッションを使って顧客サーバ205aに取引IDを含む情報によって着金通知を送る(S211-2)。
【0062】
以上、本実施形態において、顧客の認証と同時に送金許可を行うシステムの例を示した。また、顧客ウォレットとは別の取引所サービスから板情報を取得する例を示した。特に、換算レートを求めるに当たって最大買値及び最小売値だけでなく複数の買値及び売値とその取引量を考慮することによって、大きな送金額の交換における予期せぬ価格下落を抑えることとした。また、着金監視を顧客ウォレットサービスに頼ることにして、本発明が様々な接続形態によっても実現できることを示した。
【0063】
<実施形態3>
本実施形態3は、実施形態1又は2の変形例である。本実施形態3は、同じ店舗宛ての送金であっても支払ごとに異なる送金先アドレスを用いるために、送金先アドレスを動的に生成する例を示す。また、送金実行サービスの間で共通の方法で送金依頼ができる形式が定められるようになった場合、例えば、送金実行サービスを利用するためのインタフェースが統一された場合を想定する。更に、指定された通貨以外の通貨による送金にも対応する。
【0064】
本実施形態3にかかる送金指示装置におけるハードウェアの構成は
図1と同様であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム1021には、本実施形態3にかかる送金指示サーバの処理が実装されているものとする。
【0065】
鍵を登録するシーケンスは、実施形態1と同じように
図2に従うものとする。また、本実施形態3では送金実行サービスの間で送金依頼の方法が共通化されているので、鍵の名前と数も共通化されている。故に鍵登録ページ上の鍵の名称は固定となる。例えば、顧客201がスマートフォンアプリから鍵を登録する場合、画面上の鍵の名前は固定で良い。また、顧客201がウェブページで鍵の登録を行う場合は、HTML記述の中に鍵の名前が書き込んであれば良い。そのため、本実施形態3では、鍵定義テーブルが不要となる。
【0066】
図19に、本実施形態にかかる送金指示システムにおける送金許可シーケンスのブロック図を示す。ここで、送金指示サーバ203bは、店舗の送金先アドレス生成ためのアドレス生成鍵20361を記憶装置に保存しているものとする。このアドレス生成鍵20361は、予め店舗側が登録しても良いが、送金指示サーバ203bで自動生成しておいても良い。尚、送金指示サーバ203bは、図示しない構成として上述した鍵情報テーブル2032aや店舗情報テーブル2035を備えるものとする。
【0067】
また、他の実施形態では1つだった店舗サーバが、顧客のユーザインタフェースを提供する店舗販売サーバ205bと、注文を処理する店舗処理サーバ205cとに分かれる。また、本実施形態3では顧客コンピュータの代わりに顧客スマートフォン202aを使用するものとする。顧客スマートフォン202aにアプリ2022を実行させる場合、送金指示装置の一部機能を肩代わりできる。そのため、他の実施形態では送金指示装置としていたものを2つに分け、本実施形態3では送金指示サーバ203bの鍵登録処理部2033b及び送金処理部2034bと顧客スマートフォン202a上のアプリ2022を合わせて送金指示システムとみなすものである。尚、顧客スマートフォン202aは、記憶装置(不図示)に本実施形態3にかかるアプリ2022の処理が実装されたプログラムが記憶されており、プロセッサ(不図示)が記憶装置からメモリへ当該プログラムを読み込み実行することにより、本実施形態3にかかるアプリ2022の機能を実現するものとする。
【0068】
顧客スマートフォン202a上のアプリ2022には認証機能が実装されており、顧客201がユーザ名とパスワードを入力すると、それらが送金指示サーバ203bに送られる。送金指示サーバ203bは、それらを受け取ると、データベース内に保持しているユーザ名とパスワードの組と照合し、一致すれば認証トークンを返す。認証トークンは認証を繰り返さなくても良くするための情報であり、例えば「ユーザ名、時刻」の組を送金指示サーバ203bの秘密鍵で電子署名したものを使うことができる。パスワードをそのまま送らずにチャレンジ・レスポンス方式でもパスワードの照合が可能であることは当業者の間では公知のことである。またパスワードをそのまま比較するのではなく、パスワードのハッシュ値を比較する手法も公知である。
【0069】
まず、顧客201が顧客スマートフォン202aを利用して、店舗販売サーバ205bでの発注シーケンスに入る。そして、顧客201は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部2021aは、送金を開始するトリガーを店舗販売サーバ205bへ送信する(S301)。すると、店舗販売サーバ205bは、店舗ID、取引ID、通貨、金額の組(以後、「支払情報」と呼ぶ。)をパラメータとした送金許可のための承認URLを、顧客スマートフォン202aに返信する(S302)。つまり、実施形態3にかかる支払情報は、送金先アドレスを含まない。ここで、支払情報に含まれる取引ID、通貨及び金額は店舗処理サーバ205cとも共有され、後に店舗処理サーバ205cが内容を確認できる。顧客スマートフォン202aのアクセス処理部2021aは、受信した送金許可の承認URLを開くと、ディープリンク機能(例えばiOS(登録商標)の場合はUniversal Link、Android(登録商標)の場合はIntent URL)により特定のアプリ2022が起動する。顧客スマートフォン202aは、特定のアプリ2022が起動したら、まず認証トークンを送るとともにウォレットのリストを送金指示サーバ203bに要求する(S303)。これに応じて、送金指示サーバ203bの送金処理部2034bは、認証トークンの電子署名を確認して、以下の情報を顧客スマートフォン202aの特定のアプリ2022に返信する(S304)。
・顧客ウォレット名のリスト
・各顧客ウォレットが扱うことのできる通貨のリスト
・通貨リストの各通貨から支払情報の通貨への換算レートのリスト
【0070】
このとき、送金指示サーバ203bの送金処理部2034bは、
図14の鍵情報テーブル2032aからユーザ名(顧客ID)に関連付けて鍵が登録してある顧客ウォレット名(取引所名)より、顧客ウォレット名のリストを作成する。アプリ2022は、送金指示サーバ203bから受信したウォレット名のリストを元に、ステップS203で受信した承認URLのパラメータから支払情報を抽出し、
図20のような送金許可画面2000を生成して表示する。ウォレット名はドロップダウンメニュー(取引所選択欄)2003の選択肢となり、顧客201はその中から1つを選ぶことができる。ドロップダウンメニュー(通貨選択欄)2007には、ドロップダウンメニュー2003で選んだウォレットが扱うことのできる通貨が選べるようになっている。その他、送金許可画面2000は、店舗名2001、送金額2002a、基軸通貨換算額2002b、中止ボタン2004及び承認ボタン2005を表示し、これらについては後述する。
【0071】
ところで、デジタル通貨によっては送金時間に大きな差がある。そこで、送金指示サーバ203bの送金処理部2034bは過去の送金において、送金指示から着金までの時間を記録しておくことによって、通貨毎の送金時間の分布を求めることができる。そこで、送金処理部2034bは、
図21のように、店舗が希望する最長送金時間20352を店舗ID毎に予め店舗情報テーブル2035aとして保存する。そして、送金処理部2034bは、各顧客ウォレットが扱うことのできる通貨のリストを作成する際に、送金時間履歴テーブル2037を参照して、所定時間以内の送金が見込める通貨をウォレットごとに絞り込み、絞り込まれた通貨とウォレットの組のリスト(選択肢)をステップS304に含めて送信する。これにより、アプリ2022は、ドロップダウンメニュー2007に表示する通貨の選択肢を絞り込むことができる。対象となる通貨が1つもないウォレットは、ドロップダウンメニュー2003の候補から外す。例えば、ある通貨について過去1ヶ月の送金の95%が保存された最長送金時間よりも短い送金時間で終わっていなければ、通貨の選択肢からその通貨を外す。尚、顧客側の希望によっても選択肢を絞り込むこともできることは言うまでもない。これにより、送金に予想外に時間がかかることをある程度防ぐことができる。
【0072】
顧客201がドロップダウンメニュー2007で通貨を選択すると、アプリ2022は、支払情報の通貨における金額を、選択された通貨に換算して換算金額として送金額2002aに表示する。この際の換算レートは他の実施形態で示した方法で求めても良いが、本実施形態では板情報の時系列情報を利用して求める方法を示す。具体的には、送金指示サーバ203bの送金処理部2034bは、取引所204aから逐次板情報を取得し、時刻情報とともに各通貨対の板情報から最大買値と最小売値をデータベースに記録していく。そして、送金処理部2034bは、アプリ2022に顧客ウォレット名のリストを送るタイミング(S304)において、直近一定時間以内の最大買値及び最小売値の平均を求め、買値及び売値の換算レートとして併せてアプリ2022に送信する。このように換算レートを求めることにより、短時間での換算レートの大きな変動を抑えることができる。逆に、過去の板情報から、ディープラーニングなどの機械学習を用いて、近い将来の換算レートを予測することも可能である。このようにすることで、着金時に通貨交換する際の金額の変動を抑えることを狙う。
【0073】
また、送金額2002aに表示する換算金額には、送金手数料を含めても良い。この場合、表示する支払金額は以下の式で求められる。
換算金額 =(支払情報の金額 × 換算レート + 交換手数料)+ 送金手数料
または
換算金額 =(支払情報の金額 / 換算レート + 交換手数料)+ 送金手数料
【0074】
また、アプリ2022は、送金額2002aの換算金額に添えて、顧客201が指定する基軸通貨での金額を基軸通貨換算額2002bに表示する。その場合の計算法は、実施形態1又は2と同じ方法をとることができる。あるいは例えば、換算金額を求めるときのように、換算レートとして過去買値及び売値の平均を使っても良い。いずれにしても、この基軸通貨での金額が最小となる通貨をドロップダウンメニュー2007のデフォルト値とするのが、顧客201にとって都合が良い。
【0075】
図20の送金許可画面2000で、顧客201が中止ボタン2004を選択した場合は、アプリ2022は送金指示サーバ203bへその旨を通知し、送金処理部2034bは、その店舗IDの取引IDの支払いは中止されたものとしてデータベースに記録し、支払いプロセスはこれで中止される。仮に送金指示サーバ203bのホスト名がapi.sender.comの場合、店舗処理サーバ205cはhttps://api.sender.com/v1/payments/{店舗ID}/{取引ID}にGETリクエストを発行することにより、データベースに記録されているその取引の詳細を知ることができる。ここでURLの{店舗ID}の部分は店舗IDに、{取引ID}の部分は取引IDに置き換える。取引の詳細情報には、通貨、金額及び状態が含まれ、店舗管理サーバ205cは内容が改竄されていないことも確認することができる。状態が「中止」となっていれば、支払いが中止になったことが分かる。
【0076】
逆に、顧客201が
図20の送金許可画面2000で承認ボタン2005を選択した場合、アプリ2022は送金許可画面2000上に表示又は選択された通貨、送金額及び取引所(顧客ウォレット)による送金が許可された旨を通知し(S305)、送金処理部2034bは、取引の状態を「許可」として記録する。店舗処理サーバ205cは、この状態を上記のURLより取得することができる。この間、送金指示サーバ203bの送金処理部2034bは、店舗処理サーバ205cへ支払情報を含めた送金許可通知を送信し(S306)、店舗処理サーバ205cは、支払情報の整合性を確認し、送金指示サーバ203bへ送金許可応答を送信する(S307)。そして、取引の状態を「許可」にした後、送金指示サーバ203bは、顧客ウォレット206に送金指示を発行する(S308)。その際に送るのは、
図20の送金許可画面2000で選択した通貨、その換算金額(送金額)、後述する方法で生成された送金先アドレスである。また、送金処理部2034bは、顧客ウォレット206が指定する方法で、鍵情報テーブル2032aからユーザ名に関連付けた鍵を用いて、送金指示の情報を電子署名などする。
【0077】
ここで、送金先アドレスの生成法を説明する。つまり、送金指示サーバ203bは、所定のデジタル通貨の特性に応じて、当該デジタル通貨に対応するアドレスを前記送金先アドレスとして生成する。ここで、送金指示サーバ203bは、予め
図22のようなデータベースの送金先アドレス生成制御テーブル2038に各通貨ごとに(動的に送金先アドレスを生成するか否かを示す)属性が保持されているものとする。尚、送金先アドレス生成制御テーブル2038の代わりに、例えば、通貨ごとの上記属性がプログラムに書き込まれていても良い。例えば、BTC(Bitcoin)のように送金先アドレスの再利用が推奨されない通貨の場合、動的アドレス生成の列にtrueが保持されている。逆に、XRP(Ripple)のように送金先アドレスの再利用が可能な通貨の場合、動的アドレス生成の列にfalseが保持されている。
【0078】
また、送金指示サーバ203bは、送金先アドレス生成用の鍵などを保持するデータベースの送金先アドレス管理テーブル2039を記憶する。
図23は、送金先アドレス管理テーブル2039の例を示す。各行は店舗及び通貨の組毎に用意され、
図22の送金先アドレス生成制御テーブル2038における動的アドレス生成の列がfalseの通貨については、
図23の送金先アドレス管理テーブル2039の第3列は該当する店舗の送金先アドレスそのものを保持する。送金先アドレスそのものを保持する場合、送金指示の際に送る送金先アドレスにはこの値を利用する。逆に、
図22の送金先アドレス生成制御テーブル2038において動的アドレス生成の列がtrueの通貨については、
図23の送金先アドレス管理テーブル2039の第3列は該当する店舗のアドレス生成用の鍵を保持する。アドレス生成用の鍵を保持する場合、送金指示サーバ203bの送金処理部2034bは、これを用いて送金先アドレスを生成する。例えば、BTCの場合、Deterministic Walletと呼ばれる機能で実現されている送金先アドレス生成法が定義されている(BIP0032など)。送金指示サーバ203bの送金処理部2034bは、データベースに保持されているアドレス生成用の鍵を用いて、アドレスを生成できる。そして、送金指示の際にこれを送金先アドレスとして利用できる。
【0079】
図19の説明に戻る。送金指示を受けた顧客ウォレット206の送金実行サービス2061は、台帳208に送金事実を書き込む(S311)。尚、顧客ウォレットによっては、二段階認証(電話やメールなど他の手段)によって顧客201に送金の再確認が行われる場合もある。例えば、ステップS308に応じて、送金実行サービス2061は、顧客スマートフォン202aに対して、電話又はメール(つまり、アプリ2022以外が受信できる方法)により2FA(Two Factor Authentication)を行う(S309)。そして、顧客201が顧客スマートフォン202a(のアプリ2022以外の機能(電話番号によるSMS(Short Message Service)やメールアプリ等))に応答操作を行うことにより、顧客スマートフォン202aは、送金実行サービス2061へ2FA許可を通知する(S310)。これにより、ウェブアプリのパスワードが漏洩した際にも不正な取引を防止することができる。尚、顧客201は、顧客スマートフォン202a以外に、通信可能な携帯電話端末、タブレット端末又はパソコン等の情報通信装置を所持していてもよい。その場合、送金実行サービス2061は、ステップS309において顧客201が所持する情報通信装置に対して2FAを行い、ステップS310により当該情報通信装置からの2FA許可を受け付ける。
【0080】
その後、送金指示サーバ203bは台帳208を監視し続け、送金状態を取引の状態に反映する。また、支払情報に指定した通貨と送金通貨が異なる可能性があるので、取引の詳細には送金通貨及び送金額が追加される。例えばBTCのブロックチェーンの場合、送金事実を書き込んだ後に「承認」と呼ばれる処理が繰り返される。もし「承認」がn回行われた場合には、取引状態は「承認n」とする。そして、ある一定回数Nを超える承認が繰り返されたら、取引状態を「承認N+」とし、以後その送金の監視は辞める。そして、送金処理部2034bは、取引状態が「承認N+」とされた取引IDを含む着金通知を店舗処理サーバ205cへ送信する(S312)。
【0081】
店舗処理サーバ205cは、受信した取引状態を確認し、所望の承認回数に達したら、例えば商品を発送するなどのプロセスを始めることができる。急を要するサービスの場合は、送金許可が下りた後にそのプロセスを始めることもできる。いつこのプロセスを始めるかは、店舗側の判断である。
【0082】
以上、本実施形態では、送金先アドレスが動的に生成される例を示した。また、指定された通貨以外の通貨による送金にも対応した。送金先アドレス生成法としてArmory Deterministic Walletに採用されている方法を使えば、送金指示サーバでも送金先アドレス生成用に公開鍵のみを保管すれば良いことについても触れておく。
【0083】
<実施形態4>
本実施形態4は、実施形態1、2又は3の変形例であり、任意の店舗あるいは個人が取引可能なシステムの例を示す。また、本実施形態4は、顧客が選択した通貨とは異なる通貨でも送金指示装置が換金を行った上で、送金指示を行うことができる。
【0084】
本実施形態4にかかる送金指示装置におけるハードウェアの構成は、
図1と同様であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム1021には、本実施形態4にかかる送金指示装置の処理が実装されているものとする。
【0085】
図24は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図を示す。本実施形態では、預金管理を行うウォレット機能と通貨交換を行う取引所機能が、同じ顧客取引所204で行われるものとする。店舗サーバ205dは、電子商取引のWEBサイトを提供するコンピュータ装置である。店舗サーバ205dは、記憶装置に承認URL2051及びSSL証明書2053(公開鍵証明書)を保存している。ここで、SSL証明書2053は、信頼された認証局が店舗サーバ205dのサイト運営組織(及びURL)の信頼性を証明した電子証明書である。尚、送金指示装置203dは、送金指示装置203と比べて送金処理部2034dを備える。送金指示装置203dの他の構成は、送金指示装置203、203a、送金指示サーバ203b等と同等のものを用いることができる。よって、適宜、図示を省略している。
【0086】
まず、顧客201が顧客コンピュータ202を利用して、店舗サーバ205dでの発注シーケンスに入る。顧客201は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部2021は、送金を開始するトリガーを店舗サーバ205dへ送信する(S401)。すると、店舗サーバ205dは、店舗サーバURL(第1の宛先情報)、取引ID、通貨、金額の組に自身のSSL証明書2053の秘密鍵で電子署名した情報(以後、「支払情報」と呼ぶ。)をパラメータとした送金許可のための承認URLを、顧客コンピュータ202に返信する(S402)。すると、顧客コンピュータ202のアクセス処理部2021は、新たなブラウザウィンドウを開いて、取得した承認URLに対してGETリクエストを発行する(S403)。この時点で、顧客201が送金指示装置203dにログインしていなければ、上述したステップS204と同様のログインプロセスが行われる(S404、S405)。
【0087】
ログインの後、送金指示装置203dの送金処理部2034dは、支払情報から店舗サーバURLを抽出し、そのURLからSSL証明書2053をダウンロードする(S406)。そして、送金処理部2034dは、SSL証明書2053に記述されている公開鍵を用いて、抽出した支払情報が対応する秘密鍵で電子署名されていることを検証する。正しく電子署名されていることが確認されたら、送金処理部2034dは、
図25のようなウェブページ(送金許可ページ2500、表示用ページ)を生成する。この場合、送金処理部2034dは、ダウンロードしたSSL証明書2053のOrganization(O)フィールドから取得した組織名を店舗名2501として追加する。また、送金処理部2034dは、店舗サーバURLから抽出した文字列を店舗名2501の下のホスト名(第1の宛先情報に含まれる情報)として追加する。尚、ホスト名には、SSL証明書2053のCommon Name(CN)フィールドから取得したもの(公開鍵証明書に含まれる情報)を用いても良い。送金処理部2034dは、店舗がSSL証明書によって検証されたことを示す場合にアイコン2508(公開鍵証明書により検証済みであることを示す情報)を追加する。送金処理部2034dは、顧客201が登録している取引所の内、支払情報に指定してある通貨での送金ができる取引所を選択肢として選択可能にドロップダウンメニュー(取引所選択欄)2503に設定する。送金処理部2034dは、ドロップダウンメニュー2503で選択された取引所が扱える通貨を選択肢として選択可能にドロップダウンメニュー(通貨選択欄)2507を設定する。
【0088】
そして、送金処理部2034dは、生成した送金許可ページ2500を送信詳細として顧客コンピュータ202へ送信する(S407)。アクセス処理部2021は、送金指示装置203dから受信した送金許可ページ2500を画面に表示する。そして、顧客201が承認ボタン2505を選択すると、アクセス処理部2021は、送金許可ページ2500上に表示された通貨、送金額及び取引所を含む送金許可を送金指示装置203dへ通知する(S408)。
【0089】
ここで、本実施形態では送金対象の通貨を切り替えることができる。そのためには、顧客201が承認ボタン2505を押下する前に次のような操作を行うこととなる。例えば、顧客201がドロップダウンメニュー2507で通貨を選択すると、送金額2502aに選択された通貨での換算金額が表示される。例えば、アクセス処理部2021は、選択された通貨を送金指示装置203dへ通知し、送金処理部2034dにより換算金額が更新された送金許可ページ2500を取得し、表示してもよい。または、アクセス処理部2021は、選択された通貨に基づき換算金額(例えば、基軸通貨換算額2502b)を算出して、送金許可ページ2500を更新してもよい。
【0090】
また、顧客201が承認ボタン2505を選択した際のドロップダウンメニュー2507で選択された通貨が支払情報に含まれる通貨と同じ場合には、他の実施形態と同様に、送金処理部2034dは、その通貨で送金する。一方、顧客201が承認ボタン2505を選択した際のドロップダウンメニュー2507で選択された通貨が支払情報に含まれる通貨と異なる場合(通貨交換を伴う場合)には、送金処理部2034dは、選択した通貨を支払情報の通貨に交換してから送金する。この時、成行で注文することもできるが、換算金額以上の交換とならないように指し値で注文することも可能である。その時の指し値は換算金額を求める際に利用した換算レートである。特に指し値注文の場合、注文が成立しないことがあり得るので、注文を取り消す仕組みが必要である。
【0091】
図26に通貨交換を伴う通貨を選択した場合のフローチャート図を示す。顧客201が承認ボタン2505又は中止ボタン2504を選択したら、アクセス処理部2021は、ステップ2601でボタンの種類を特定し、上述した送金許可と共に、特定したボタンの種類を送金指示装置203dへ通知する。ボタンの種類が中止ボタン2504である場合、ステップ2608へと遷移し、送金処理部2034dは、直ちに支払いを中止する。一方、ボタンの種類が承認ボタン2505である場合、アクセス処理部2021は、ステップ2602で承認ボタンのラベルを「注文中」に変えてボタンを無効化する。そして、次のステップ2603で、送金処理部2034dは、顧客取引所204に注文を出す。つまり、送金処理部2034dは、顧客取引所204に対して通貨交換を要求する(
図24のS410)。具体的には、送金処理部2034dは、顧客取引所204に対して支払情報に含まれる通貨における送金額分を、選択された通貨に交換する指示を行う。その後ステップ2604で送金処理部2034dは、中止ボタン2504が選択されたかどうかを判断する。中止ボタン2504が選択されていなければステップ2606へと直接遷移する。中止ボタン2504が選択されていれば、ステップ2605で送金処理部2034dは、顧客取引所204に注文を取り消すように指示する。その後ステップ2606で送金処理部2034dは、注文の状態を顧客取引所204に問い合わせるなどして監視する。注文が完了していれば、顧客201が中止ボタン2504を選択したことがあったとしても、取引は許可されたものとして扱う(ステップ2607)。注文が中止になっていれば、取引が中止されたものとして扱う(ステップ2608)。そのいずれでもない場合には、ステップ2604に戻って中止ボタン2504が押されたかどうかの判定を繰り返す。
【0092】
取引が中止したものとして扱われたら、ステップ2608にて、送金処理部2034dは、その店舗IDの取引IDの支払いは中止されたものとしてデータベースに記録し、支払いプロセスはこれで中止される。仮に送金指示装置203dのホスト名がapi.sender.comの場合、店舗サーバ205dはhttps://api.sender.com/v1/payments/{店舗ID}/{取引ID}にGETリクエストを発行することにより、データベースに記録されているその取引の状態を知ることができる。ここでURLの{店舗ID}の部分は店舗IDに、{取引ID}の部分は取引IDに置き換える。状態が「中止」となっていれば、支払いが中止になったことが分かる。本実施形態では、これを店舗サーバ205dへの通知の一形態とする。
【0093】
逆に、取引が完了したものとして扱われたら、ステップ2607にて、送金処理部2034dは、取引の状態を「許可」として記録する。店舗サーバ205dはこの状態を上記のURLより取得することができる。取引の状態を「許可」にした後、送金指示装置203dは、顧客取引所204に交換された金額を確認し、それを支払情報の送金先アドレスへ送金するよう、顧客取引所204に指示する(S411)。そして、顧客取引所204の送金実行サービス2041は、台帳208に送金事実を書き込む(S412)。その後、送金指示装置203dは、台帳208の監視を続け、取引の状態を更新する。尚、店舗サーバ205dは、送金指示装置203dに対してポーリングにより送金許可がされたか否かを確認するものとする。これにより、店舗サーバ205dが送金許可がされた旨を把握することができるため、
図24では、ステップS409として、送金許可通知として表現している。
【0094】
以上、本実施形態では送金指示装置に店舗のアカウントが予め登録されていなくても、任意の店舗サーバが取引を開始できる送金指示装置を示した。SSL証明書を利用することにより、店舗の信用が評価され、顧客が安心して支払いを済ませることができる。ここで、SSL証明書の検証をなくせば、ウェブサーバを持たない任意の個人でもメールにURLを記載するなどして支払いを請求できるシステムになっている点にも触れておく。
【0095】
<実施形態5>
本実施形態5は、実施形態1から4の変形例であり、URLのリンクを開くことにより支払い手続きを開始する例を示す。
【0096】
本実施形態5にかかる送金指示装置におけるハードウェアの構成は
図1と同様であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム1021には、本実施形態5にかかる送金指示装置の処理が実装されているものとする。
【0097】
図27は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。店舗サーバ205eは、顧客コンピュータ202からの送金開始のトリガーその他の発注シーケンスに伴い、顧客201のメールアドレスを宛先とし、上述した承認URL2051を本文に記載した支払請求メールをメールサーバ209に対して送信する(S500)。このとき、承認URL2051は、送金指示装置203eのウェブサイトのURL(第2の宛先情報)である。そして、承認URL2051のURLパラメータは、店舗サーバ205eの1エンドポイント(第1の宛先情報)を指し示す。尚、支払請求メールは、店舗サーバ205e以外の店員が操作する端末から送信されても構わない。
【0098】
メールサーバ209は、一般的なメールサーバである。メールサーバ209は、店舗サーバ205eから支払請求メールを受信し、支払請求メール2091として記憶装置に記憶する。メールサーバ209は、顧客コンピュータ202のメールクライアント2023からのメール受信要求に応じて支払請求メール2091を顧客コンピュータ202へ送信する。
【0099】
顧客コンピュータ202のメールクライアント2023は、起動時等にメールサーバ209に対してメール受信要求を送信し、メールサーバ209から承認URL2051を含む支払請求メール2091を受信する(S501)。顧客201が受信したメールに記載された承認URLをクリック等すると、アクセス処理部2021は、承認URLへのアクセスを行う(S502)。これにより、送金指示装置203eのウェブページが開く。ここで、送金指示装置203eの送金処理部2034eがウェブページを準備する時に、顧客201がログインしていなければ、上述したステップS204と同様に、送金処理部2034eは、ログインページを顧客コンピュータ202に送信する(S503)。顧客201がこのログインページにユーザ名とパスワードを入力すると、アクセス処理部2021はこれを送金指示装置203eへ、認証情報として送信する(S504)。送金指示装置203eの送金処理部2034eは、認証情報の受信に応じて、先ほどのステップS502でアクセスされた承認URLのパラメータが指し示す店舗サーバ205eの店舗サーバURLに対してSSL証明書を要求し、店舗サーバ205eからSSL証明書2053を取得する(S505)。送金処理部2034eは、取得したSSL証明書2053の内容を検証する。そして、送金処理部2034eは、承認URLのパラメータとして指定されていたエンドポイントに対してGETリクエストを発行する。GETリクエストを受けた店舗サーバ205eは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先を含む支払情報をhttpsによって返信する(S506)。ここでは、httpsを用いた例を示したが、支払情報を秘密にする必要がない場合には、支払情報がSSL証明書2053の秘密鍵によって電子署名されていれば、暗号化されていない通信方法でも改竄が防げるのは言うまでもない。また当然ながら、http/httpsによらずとも他の通信方法によっても同様の効果が得られる。
【0100】
支払情報は、ウェブページのようにHTML等の所定の構造化方式(構造化言語)で記述されていても良い。その場合、送金処理部2034eはDOM(Document Object Model)ツリーをパースして必要な情報を抽出する。例えば、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先がそれぞれ固有のidを持った要素(エレメント)に含まれていれば、送金処理部2034eはそれらを探して抽出する。あるいは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先がそれぞれラベルと関連付けられてウェブページ内に配置してあれば、送金処理部2034eはまずそれらラベルを検索してから関連する情報を抽出すれば良い。
【0101】
あるいは、支払情報は他の構造化方式であるjson形式で記述されていても良い。この場合は情報にキーが付与されているので、送金処理部2034eの実装が簡単となる。逆に、支払情報をHTMLで記述する場合には、店舗サーバ205eを実装する際に、REST APIの実装経験などがなくても良いという利点があり、店舗側にとって簡単となる。いずれにしても、支払情報をhttpsで送金指示装置203eに返すことにより、ウェブサーバに標準的に備わる方法によって、情報の改竄を防ぐことができ、開発効率を高めることができるのと同時に、新規開発に伴うバグによる脆弱性のリスクを軽減することができる。
【0102】
支払情報を抽出した送金処理部2034eは、その内容を
図25のようなウェブページ(送金許可ページ2500)に追加して、顧客コンピュータ202に送信する(S507)。ここで、アイコン2508はSSL証明書を検証したことを表すアイコンである。店舗名2501はSSL証明書のOrganization(O)フィールドから取得したものであり、検証したSSL証明書がEV(Extended Validation)証明書の場合にのみ表示する。その下のホスト名は、店舗サーバURLから抽出したものであり、SSL証明書に含まれているドメイン名と合致する。
【0103】
顧客201が支払情報を確認したら、承認ボタン2505を選択し、顧客コンピュータ202のアクセス処理部2021は、送金許可ページ2500上に表示又は選択された通貨、送金額及び取引所による送金が許可された旨を送金許可として送金指示装置203eへ通知する(S508)。すると、送金指示装置203eの送金処理部2034eは、まず
図29のような情報を取引ログ20371として送金履歴テーブル2037aに追記する。取引ログ20371には、SSL証明書から取得したホスト名(cn)、送金通貨(currency)、送金額(amount)、送金先アドレス(destination)、並びに、記録時間(timestamp)及び支払留保フラグ(reserve)等が含まれる。また、送金指示装置203eは、さらに、送金先のアカウント20372を管理してもよい。アカウント20372は、店舗(店舗サーバ205e)を一意に識別する情報であり、送金指示装置203eの送金先となるユーザ(店舗)を示す課金用のアカウントである。アカウント20372には、例えば、取引ログ20371内のホスト名(cn)、つまり、SSL証明書内のホスト名を用いることができる。また、送金指示装置203eは、アカウント20372を送金先として送金指示装置203eを介して送金指示サービスが使用された際に、アカウント20372に課金される課金条件や後に説明する管理アドレスをさらに保持しているものとする。例えば、課金条件は、送金先として無料で利用可能な送金指示の上限回数であってもよい。
【0104】
言い換えると、次のように言うことができる。すなわち、まず、送金処理部2034eは、ステップS505により店舗サーバ205eからSSL証明書2053を受信し、ステップS506によりSSL証明書2053の鍵により電子署名された支払情報を受信する。または、店舗サーバ205eと送金指示装置203eとの通信がhttps等により暗号化されていた場合には、支払情報に電子署名は不要となる。そして、送金処理部2034eは、ステップS508により顧客コンピュータ202から送金許可を受信した場合に、SSL証明書の内容を用いて店舗サーバ205eの課金用のアカウントを生成し、生成したアカウントを送金履歴記憶部へ登録する。これにより、送金指示装置203eは、各店舗に対して事前のアカウント登録を要求せずに、送金発生時にアカウントを自動生成し、かつ、アカウントごとに課金状態を管理することができる。よって、送金指示装置203eは、自己の送金指示サービスの普及を、店舗を介して促進することができる。
【0105】
ここで、送金処理部2034eは、SSL証明書に含まれるホスト名を識別子としてアカウントを生成するとよい。SSL証明書は、ホストごとに発行されるため、店舗の一意性を容易かつ確実に担保することができる。
【0106】
また、送金処理部2034eは、送金履歴記憶部に登録されたアカウントを送金先とした送金指示の回数が所定の課金条件を満たした場合(例えば、上限回数を超えた場合)に、送金先への課金を開始することが望ましい。これにより、店舗は、送金指示装置203eのアカウントを事前に登録することなく、送金先として一定回数まで無料で送金指示サービスを利用できる。そして、送金指示装置203eは、無料での送金指示が一定回数を超えるアカウントに対して、課金することができ、課金を制御できる。
【0107】
そして、取引ログ20371に記録した後、送金処理部2034eは、店舗サーバ205eに支払いが承認されたことを通知する(S509)。具体的には、先の支払情報の通知先には送金許可通知の通知先URLが含まれているので、送金処理部2034eは、通知先URLに対してhttps POSTリクエストを発行する。通知先には明示的に取引IDを送らなくても、URLにその情報を組み入れることで、パラメータとして扱わずに同様の効果が得られる。
【0108】
そして、送金処理部2034eは、顧客201の鍵を利用して送金通貨、送金額及び送金先アドレスを含めた送金指示を顧客取引所204へ送信する(S510)。ただし、ここでの送金先アドレスは取引ログ20371に記録された内容に基づく。まず、送金処理部2034eは、取引ログ20371を検索し、過去一定期間(例えば1ヶ月)の同じホスト名に対する取引回数が所定回数以下であるかどうかを確認する。所定回数以下であれば、送金処理部2034eは、店舗サーバ205eから取得した送金先アドレスを使用する。このとき、例えば、送金処理部2034eは、該当する取引ログ20371の支払留保フラグ(“reserve”キー)にfalseを設定する。逆に所定回数を超えていれば、送金処理部2034eは、送金指示装置203eが用意した送金先アドレス(送金額を留保するために、送金指示装置203eが管理する管理アドレス)を使用する。結果的に、取引回数が所定回数を超える場合には、支払いが特定のアドレスに一時的に留保されることになる。この時、例えば、送金処理部2034eは、該当する取引ログ20371の支払留保フラグ(“reserve”キー)にtrueを設定する。
【0109】
つまり少なくとも、送金処理部2034eは、前記生成したアカウントに、前記送金情報に含まれる前記送金先アドレスをさらに対応付けて前記送金履歴情報として前記送金履歴記憶部に登録し、前記送金指示の回数が前記課金条件を満たした場合に、前記送金先アドレスへの前記送金指示を行う代わりに、送金指示装置203eが管理する管理アドレスへ前記送金額を送金するための前記送金指示を行う。尚、送金処理部2034eは、送金履歴記憶部に登録された当該アカウントにおける送金履歴情報を数えることにより、送金指示の回数を算出してもよい。または、送金処理部2034eは、当該アカウントにおける送金履歴情報に対して所定の統計処理を行うことで、下記条件を満たすか否かを判定してもよい。
【0110】
その後、顧客取引所204は送金指示に応じて台帳208に送金事実を書き込む(S511)。ここで、顧客201の鍵は、例えば
図28のようなNoSQLのデータベースに予め保持されている。この例では、“user”のキーに顧客の識別子、“exchange”に顧客取引所の識別子、“api_keys”に顧客の鍵が保持されている。当然、他の形式のデータベースにも同様の情報を保持することができる。鍵の使用法は、顧客取引所が指定する方法に合わせるが、例えば、鍵のひとつで「送金通貨、送金額及び送金先アドレス」の組を電子署名して顧客取引所に送信するなどする。
【0111】
顧客取引所204から応答として台帳上の識別子(Transaction ID;txid)を得るので、送金指示の後、送金指示装置203eの送金処理部2034eは台帳208を監視し、着金があったと見なして良くなるまで待つ。先の支払情報の必要承認回数に指定された回数だけ台帳の承認が繰り返されたら、送金指示装置203eの送金処理部2034eは店舗サーバ205eに着金を通知する(S512)。そのために、支払情報の通知先に着金通知先URLが含まれている場合、送金処理部2034eは、着金通知先URLにhttps POSTリクエストを発行する。ボディ部には後に説明する引き出し用URLを含める。ビットコイン(BTC)などのブロックチェーン台帳においては、台帳の承認が繰り返されれば後で取り消される確率が減少するが、完全に0になるわけではない。そのために、店舗サーバ205eは、送金額や店舗の財務状況あるいは予想送金時間などに合わせて必要承認回数を、その都度調整するべきである。尚、店舗サーバ205eの代わりに送金処理部2034eが必要承認回数を調整してもよい。
【0112】
すなわち、本実施形態にかかる着金通知は、次のような処理が可能であり、これらは上述した実施形態1から4にも適用可能である。まず、承認条件は、前記送金指示ごとに更新される。また、店舗サーバ205eは送金情報に含まれる前記送金額に基づいて前記承認条件を更新してもよい。また、店舗サーバ205eは、取引記録の承認履歴に基づいて前記承認条件を更新することが望ましい。また、前記承認条件は、前記送金先において前記送金情報に含まれる前記送金額に基づいて更新されたものであってもよい。また、前記承認条件は、当該送金先の資産情報に基づいて更新されたものであってもよい。
【0113】
また、送金処理部2034eは、POSTリクエストのフォームデータとして、引き出し用URL(第3の宛先情報)を送信する。
【0114】
すなわち、送金処理部2034eは、前記指定された所定のデジタル通貨に対応する取引記録が所定の承認条件を満たした場合に、前記送金先に対して前記送金額を引き出すための第3の宛先情報を含めて着金通知を行なう。
【0115】
また、支払情報の通知先に着金通知先URLの代わりにメールアドレスが指定されている場合には、送金処理部2034eは、着金通知文に加えて、引き出し用URLをメール本文に記載して、指定メールアドレスにメールを送信する。尚、引き出し用URLはホスト名毎に異なり、有効期限を設けることもできる。
【0116】
店舗の従業員が店舗サーバ205eその他の端末からこの引き出し用URLをウェブブラウザで開くと、
図30のような表を含んだウェブページが表示される。表の各行には通貨毎に留保されている金額が表示されている。店舗の従業員は、引き出しを希望する通貨の行の送金先アドレスの列に店舗の送金先アドレス(第2の送金先アドレス)を入力し、引き出しの列にあるボタンを選択する。すると、当該端末は、選択されたボタンの行に入力された送金先アドレスを送金指示装置203eへ送信し(つまり、引出要求を送信し)、送金指示装置203eの送金処理部2034eは、取引ログ20371の中から、店舗のホスト名に対して、入力された送金先アドレスが過去に使用されたかどうかを確認する。送金先アドレスの使用が確認されたら、送金処理部2034eは、留保しているアドレスから入力された送金先アドレスに対して、留保されている金額から手数料を引いた通貨の金額(引出金額)を送金する。そして、送金処理部2034eは、
図31のような情報を、手数料込みの引き出し金額を負の数として取引ログ20371に追記する。このようにすることで、取引ログのホスト名及び通貨毎に“reserve”キーに対応する値がtrueであるエントリーの“amount”値の総和を取ることによって、留保残高が計算できるようになる。
【0117】
すなわち、送金処理部2034eは、少なくとも、前記送金先からの引出要求に応じて、前記送金額から送金指示手数料を減額した額を引出金額として算出し、前記管理アドレスから前記送金先アドレスへ前記引出金額を送金するための前記送金指示を行う。このとき、送金処理部2034eは、前記送金先からの引出要求として第2の送金先アドレスの入力を受け付けた場合、前記送金履歴記憶部に登録された当該送金先のアカウントに対応付けられた前記送金先アドレスと前記第2の送金先アドレスとを照合し、前記送金先アドレスの1つと前記第2の送金先アドレスとが一致する場合、前記送金額から送金指示手数料を減額した額を引出金額として算出し、前記管理アドレスから前記第2の送金先アドレスへ前記引出金額を送金するための前記送金指示を行うことが望ましい。さらに、送金処理部2034eは、前記送金先から前記第3の宛先情報に対するアクセスの中で、前記引出要求を受け付けるとよい。これにより、送金指示装置203eは、課金を確実に行うことができる。また、店舗側も引出金額を容易かつ確実に取得することができる。これら引き出しにおける送金指示は、別の取引所やウォレットにおける送金実行サービスを利用してもよく、あるいは、送金指示装置203eに実装された送金実行サービスを利用してもよい。
【0118】
以上、本実施形態では、URLによる支払い請求の例を示した。この承認URLはURLであるため、メールに記載するのみならず、ウェブページ上のリンクや印刷物の二次元コードとして活用するなどできる。支払情報を店舗のhttpsサーバが提供することにより、以下を含めた数多くのメリットが享受できる。
・支払情報等をURLパラメータに含めるのに比べ、短いURLにすることができ、メールや書類などに記載するのに都合が良い。
・短いURLであるにもかかわらず、その後取得される支払情報は暗号化されていることから、第三者が支払情報を偽造及び改竄することを防ぐことができ、顧客が意図しない宛先に送金してしまうことを防ぐことができる。利用形態としては例えば、所定回の送金手数料を無料にして、店舗サイトに本サービスのURLを表示してもらう。そして、当該店舗サイトのユーザ(顧客)がリンクをクリックすることで、本サービスのユーザ登録画面を自動的に表示できる。
・URL生成のために送金指示装置に取引を登録したり、店舗がアカウントを事前に作成したりする必要がなく、送金指示装置と店舗サーバの負担が軽い。例えば、ワンタイムのアカウントでも実現可能である。
・偽造及び改竄が難しく送金指示装置への負担も軽いので、承認URLを不特定多数の人に公開して送金を依頼することができる。例えば、寄付金の送金先や小規模事業者又は個人が店舗側として自己の決済に利用する際にも適している。
・店舗サーバの実装者は、ウェブページに承認URLを埋め込み、支払情報を記述したページを用意するだけでも、決済機能を実現できる。店舗サーバの実装は容易であり、ユーザはリンクをクリックするだけであるためユーザの利便性高い。よって、本サービスの普及を促進できる。
【0119】
また、SSL証明書内の情報を利用することにより、以下のメリットが享受できる。
・店舗の従業員がアカウントを作成する操作をしなくても、送金指示装置による課金が可能である。
・アカウントを作成するために、メールアドレスや名前やパスワードなどの個人情報を収集する必要がない。
・店舗のアカウントを手動で作成しなくても身元保証が可能なため、身元の確認のためのコストが不要である。
【0120】
尚、本実施形態にかかる送金指示装置は、少なくとも送金先に関する公開鍵証明書に基づいて送金情報を受信するものであればよい。例えば、送金指示装置は、公開鍵証明書を用いた暗号化通信(例えば、https)により送金情報を受信する場合や、送金先において公開鍵証明書の鍵により電子署名された送金情報を受信する場合が含まれる。
【0121】
<実施形態6>
本実施形態6では、上述した各実施形態を送金実行サービスに適用する一例を示す。
【0122】
本実施形態6にかかる送金実行装置におけるハードウェアの構成は
図1と同等であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム1021には、本実施形態6にかかる送金実行装置の処理が実装されているものとする。
【0123】
図32は、本実施形態6にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図を示す。他の実施形態と比較して、送金指示装置の機能と送金実行サービスの機能が、送金実行装置204bによって両方とも行われるところが、大きく異なる。尚、送金実行装置204bには、上述した鍵定義テーブル2031や鍵登録処理部2033が不要である。店舗サーバ205fは、電子商取引のWEBサイトを提供するコンピュータ装置である。店舗サーバ205fは、記憶装置に送金実行装置204bのURL2054及びSSL証明書2053を保存している。
【0124】
まず、顧客201が顧客コンピュータ202を利用して、店舗サーバ205fでの発注シーケンスに入る。顧客201は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部2021は、送金を開始するトリガーを店舗サーバ205fへ送信する(S601)。あるいは、実店舗の場合、店員が代わりに顧客コンピュータ202とは別のコンピュータでこれを行うこともできる。すると、店舗サーバ205fは、以下の情報をそれぞれURLパラメータとして、送金実行装置204bのURL2054(第2の宛先情報)と組み合わせて新たなURLを作成する。本実施形態では、これを承認URLと呼ぶことにする。
・支払情報を記載したウェブページのURL(支払情報URL)(第1の宛先情報)
・今回の支払いを特定する識別子(取引ID)
ここで、支払情報URLは店舗サーバ205fの1エンドポイントを指し示すこともあるが、他のサーバでも良い。本実施形態6では、店舗サーバ205fの1エンドポイントを指し示すものとして説明を続ける。
【0125】
そして、店舗サーバ205fは、この承認URLを、顧客コンピュータ202に送信する(S602)。また、顧客コンピュータ202にカメラがある場合には二次元コードによって承認URLを読み込ませることもできる。さらに、赤外線通信、近距離無線通信など他の通信法でも同様である。すると、顧客コンピュータ202のアクセス処理部2021は、取得した承認URLに対してGETリクエストを発行する(S603)。この時点で、顧客201が送金実行装置204bにログインしていなければ、上述したステップS204と同様のログインプロセスが行われる(S604、S605)。
【0126】
ログインの後、送金実行装置204bの送金処理部2044は、承認URLのURLパラメータから取得した支払情報URLに対してSSL証明書を要求し、店舗サーバ205fからSSL証明書2053を取得する(S606)。送金処理部2044は、取得したSSL証明書の内容を検証する。そして、送金処理部2044は、支払情報URLに対してGETリクエストを発行する。GETリクエストを受けた店舗サーバ205fは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先を含む支払情報をhttpsによって返信する(S607)。
【0127】
支払情報をHTMLで記述することを許すことにより、店舗サーバ205fは商品(サービス)を説明するウェブページを上記URLパラメータとして提供するだけで良い。
図33は店舗サーバの商品ページ3300の例である。「価格:」と表示される領域(価格表示欄3310)に商品の金額情報(税抜価格欄3311及び税込価格欄3312)が掲載されている。この部分をHTML形式で抜き取ると、例えば
図34のようになる。この例では、送金通貨、送金金額は、次のような手順で抽出できる。
1.送金処理部2044は、文字列「価格:」を含むtdエレメントをページ内から検索する。
2.送金処理部2044は、上記tdエレメントが含まれるtrエレメントに属するエレメントの中から文字列「税込」を含むエレメントを検索する。
3.送金処理部2044は、上記「税込」を含むエレメント(税込価格欄3312)の文字列の中で数値を表す文字列を送金金額とする。(この例では0.00324。)
4.送金処理部2044は、上記「税込」を含むエレメントの文字列の中で、送金可能な通貨を表す文字列があれば、それを送金通貨とする。(この例ではBTC。)
【0128】
また、この商品ページ3300にはidが"payment-attributes"であるエレメントがあり、その文字列は、送金先アドレスと通知先と必要承認回数を、送金実行装置204bの公開鍵で暗号化したものとなっている。送金先アドレスを暗号化することにより、顧客201が決められた手順を踏まずに送金先アドレスに送金することを防ぐことができる。また、通知先を暗号化することにより、不要なスパムメールなどを避けることができる。
【0129】
支払情報を抽出した送金処理部2044は、その内容を
図25のようなウェブページ(送金許可ページ2500)に追加して、顧客コンピュータ202に送信する(S608)。店舗名2501はSSL証明書のOrganization(O)フィールドから取得したものである。その下のホスト名は、SSL証明書に含まれているドメイン名である。
【0130】
顧客201が支払情報を確認したら、承認ボタン2505を選択し、顧客コンピュータ202のアクセス処理部2021は、送金許可ページ2500上に表示又は選択された通貨、送金額及び取引所による送金が許可された旨を送金許可として送金実行装置204bへ通知する(S609)。すると、送金実行装置204bの送金処理部2044は、店舗サーバ205fに支払いが承認されたことを通知する(S610)。具体的には、先の支払情報の通知先にメールアドレスが含まれているので、送金処理部2044は、このメールアドレスに対して支払いが承認された旨のメールを送る。メール本文には、先にURLパラメータとして取得した取引IDを含めることで、メールの受け手はどの取引が承認されたのか認識できる。このメールは、送金実行装置204bの秘密鍵で電子署名または暗号化することにより、改竄を防止する。
【0131】
そして、送金処理部2044は、送金通貨、送金額及び送金先アドレスを含めた送金指示を送金実行部2041aに発行する(S611)。すると、送金実行部2041aは送金指示に応じて台帳208に送金事実を書き込む(S612)。この時、BTCのように送金先アドレスを複数指定することができる通貨においては、送金実行部2041aは、送金実行手数料を徴収する。具体的には、送金実行部2041aは、店舗サーバ205fが指定した送金先アドレスに指定された金額から手数料を引いた分を送金し、送金実行装置204bが保持する別の送金先アドレスにも送金実行手数料分を送金する。台帳208に書き込む際に台帳上の識別子(Transaction ID; txid)を得るので、送金指示の後、送金処理部2044は台帳208を監視し、着金があったと見なして良くなるまで待つ。先の必要承認回数に指定された回数だけ台帳の承認が繰り返されたら、送金処理部2044は先の通知先に指定されたメールアドレスに着金したことを知らせるメールを送信する(S613)。メール本文には取引IDを含める。先の通知と同様、メールの暗号化や電子署名が可能である。
【0132】
以上、本実施形態6では、送金実行と送金処理の両方をひとつの装置で行う例を示した。送金実行と送金処理が別々の装置で実装されていなくても、上述した実施形態1から5の利点を享受できることを示した。
【0133】
<実施形態7>
本実施形態では、上述した実施形態1から6の変形例であり、本発明をスマートフォンアプリなど顧客と店舗の装置上に実装したシステムの例を示す。
【0134】
図35は、実施形態7にかかる送金指示装置3500におけるハードウェアの構成を表すブロック図である。同図において、CPU101は、本実施形態にかかる送金指示装置の処理が実装されたプログラム35021を実行する。プログラムメモリ102は、CPU101により実行されるプログラム35021を記憶する。RAM103は、CPU101によるプログラム実行時に、各種情報を一時的に記憶する揮発性記憶装置である。尚、CPU101によるプログラム実行時に、RAM103がプログラム35021を記憶することにより、RAM103はプログラムメモリ102の役目を果たすように実装することもできる。長期記憶装置3504は、RAM3503に比べてより長期の間、各種情報を記憶するフラッシュメモリなどの不揮発性記憶装置である。通信部105は、他の装置と通信するために利用される。撮像装置3506は、装置外の周辺環境を撮影して画像として取得するために利用される。バーコードを読み取る場合には、バーコードリーダを備えることもできる。CPU101、プログラムメモリ102、RAM103、長期記憶装置3504、通信部105、表示装置3507及び撮像装置3506は、バス106により接続され、データや制御信号を互いに受け渡すために用いられる。本明細書では、CPUによるプログラム実行を説明するが、FPGAなどの集積回路でも同様の機能が実装できる。
【0135】
本実施形態において後述する支払情報提示装置も送金指示装置3500同様の構成を取ることができる。また、本実施形態において、データベース機能が使用されるが、データベースに保管するデータは、長期記憶装置3504上やRAM103上などに記憶される。他の手段によって記憶されても、発明の本質は損なわれない。送金指示装置3500や支払情報提示装置は、スマートフォンやタブレットとして実装されると考えると、使用状況が想像しやすい。
【0136】
図36は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、顧客の鍵を登録する際のシーケンスを表すブロック図である。ここで、顧客取引所204は、1種類以上の仮想通貨の(通貨間の交換等の取引を含む)送金を仲介する仮想通貨交換業者が運用する情報システムである。顧客取引所204は、自己が管理する(登録済みの)複数のユーザ(例えば、顧客201)のそれぞれに対して、複数の仮想通貨を送金するサービスを提供する送金実行サービス2041を備える。ここで、顧客取引所204と送金実行サービス2041とは一対一で対応するものとする。そして、顧客取引所204は、鍵情報テーブル2042を記憶し、鍵情報テーブル2042は、顧客20421ごとに、鍵情報20422を対応付けて保存する。鍵情報20422は、送金実行サービス2041として提供されるAPIを利用するための鍵(API key等)204222と、その種別である鍵種別204221との組合せを複数、含むものである。つまり、顧客20421と鍵情報20422とは一対一で対応し、鍵情報20422には、鍵種別204221と鍵204222の組が1以上含まれる。よって、各鍵204222は、顧客20421ごとに異なる。そして、顧客取引所204は、WEBシステム2043としての機能を有し、顧客201からの鍵情報要求に応じて、鍵情報テーブル2042の中から顧客201を顧客20421として対応付けられた鍵情報20422を読み出して、鍵情報20422(鍵種別204221と鍵204222の組)を出力する。但し、鍵の保存方法や出力の仕方はこれに限定されない。
【0137】
送金指示装置203Aは、顧客201(所定のユーザ)が操作するコンピュータ端末であり、例えば、ブラウザ等(アクセス処理部2021A)やアプリケーションソフトウェア等(UI表示部36036Aや送金処理部2034Aや鍵登録処理部2033Aやアクセス処理部2021A)が動作するパーソナルコンピュータ、スマートフォン、タブレット等である。尚、顧客201は「送金元」、及び、所定の送金実行サービスを利用するユーザの一例である。
【0138】
また送金指示装置203Aは、顧客201がアカウントを持つ取引所ごとの鍵情報を管理し、複数の取引所に対して送金指示を行うことが可能な情報処理装置である。送金指示装置203Aは、鍵定義テーブル2031と、鍵情報テーブル2032Aと、鍵登録処理部2033Aと、送金処理部2034Aと、アクセス処理部2021Aと、UI表示部36036Aとを備える。鍵定義テーブル2031は、複数の送金実行サービスのそれぞれごとに、前記鍵に関する定義を記憶するテーブルである。ここでは、鍵定義テーブル2031は、取引所及び言語ごとに、当該取引所で提供される送金実行サービスのAPIを利用する際に必要となる鍵について、当該取引所の情報システム上で用いられる鍵の名称の文字列を鍵の種別ごとに管理するテーブルである。鍵定義テーブル2031は、取引所20311、言語20312、鍵種別20313及び鍵名称20314が対応付けられている。尚、鍵名称は、取引所ごとに少なくとも1以上であればよい。当然のことながら、鍵種別20313は、鍵種別204221と同じ内容である必要はなく、配列内の位置で鍵種別を表してもよい。また、鍵定義テーブル2031は、言語ごとに別テーブルとしてもよい。
【0139】
鍵情報テーブル2032Aは、取引所20322ごとに、鍵情報20323を管理するテーブルである。鍵情報20323には、鍵種別203231と鍵203232との組が複数含まれる。また、鍵情報20323は、取引所20322ごとに異なり、少なくとも1以上の鍵を含み、かつ、取引所20322において顧客201を一意に識別可能な情報を含むものであればよい。例えば、鍵の1つは取引所20322における顧客201のユーザ識別子、あるいはユーザ識別子に変換可能な情報である。また、例えば、もう1つの鍵は、取引所20322と通信を行う上で使用する暗号化・電子署名用の秘密鍵である。ここで、鍵情報テーブル2032Aは、鍵情報記憶部の一例であり、複数の送金実行サービスのそれぞれと、所定のユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を少なくとも対応付けて記憶するものである。
【0140】
鍵登録処理部2033Aは、顧客からの鍵の登録要求に応じて鍵定義テーブル2031を参照して鍵登録ページを生成して返信し、鍵登録ページを介して入力された鍵を鍵情報テーブル2032Aに登録する。送金処理部2034Aは、顧客からの送金要求に応じて、指定された仮想通貨及び金額について指定された取引所に対して、鍵情報テーブル2032Aに登録された鍵を用いて送金先への送金指示を行う。
【0141】
続いて、
図36を用いて顧客の鍵を登録する処理の流れを説明する。まず、送金指示装置203Aのアクセス処理部2021Aは、顧客201の操作に応じて、顧客取引所204に対して鍵情報要求を送信する(S101a)。例えば、送金指示装置203Aは、顧客201がアカウントを持つ顧客取引所204のウェブサイトにログインし、顧客取引所204のWEBシステム2043は、鍵情報テーブル2042を参照し、顧客201に対応付けられた鍵情報20422を読み出して、鍵204222とその鍵種別204221の名称の文字列とを対応付けた鍵情報ページを生成し、顧客コンピュータ202に表示させるために、鍵情報ページを送信する(S102a)。尚、顧客取引所204と送金指示装置203Aの間の通信方法については本発明の対象外のため、説明を省く。アクセス処理部2021Aは、顧客取引所204から受信した鍵情報ページを表示装置3507に表示する。送金指示装置203Aに表示される鍵情報ページ300は、例えば
図3のように鍵が2つとし、それぞれ鍵名称311「APIキー」と鍵名称321「秘密鍵」という名前が付いているものとする。そして、鍵情報ページ300は、鍵名称311に対応付けられた鍵312と、鍵名称321に対応付けられた鍵322とが表示されていることを示す。よって、顧客201は、顧客コンピュータ202の画面に表示された鍵情報ページ300を介して、鍵名称ごとの鍵の文字列を目視及びコピーする等により、鍵を入手できる。
【0142】
次に、顧客201は送金指示装置203Aを操作して、先ほど入手した鍵を登録する。この時、送金指示装置203Aやアプリケーションを利用するためのロックは既に解除しているものと仮定する。これより登録対象の取引所に関する鍵登録画面を表示するシーケンスを
図36と
図37を用いて説明する。鍵登録画面は、例えば
図38のような取引所一覧画面3800において、登録対象の取引所を表すボタン3801を選択(S3701)した後に表示される。このとき、鍵登録処理部2033Aは、鍵定義テーブル2031を参照し、選択された取引所(S3702)及びUI表示部36036Aの表示言語に基づき、鍵種別20313及び鍵名称20314を読み出して、UI表示部36036Aに渡す(S3703)。そして、UI表示部36036Aは、表示装置3507に、渡された情報を元に鍵名称20314に対応する鍵の入力欄を含む鍵登録画面を表示する(S3704)。
【0143】
送金指示装置203Aに表示される鍵登録画面3900は、例えば
図39のように、取引所名称401について、鍵名称411「APIキー」と鍵名称421「秘密鍵」に対応する鍵を入力するためのテキストボックス(鍵入力欄412及び422)を含む。顧客201は、送金指示装置203Aに表示される鍵登録画面3900における、「APIキー」と「秘密鍵」のそれぞれに対応する鍵入力欄412及び422に、
図3からコピーした情報を入力する。ここで「APIキー」は、顧客取引所204において顧客201を特定する識別子である。
【0144】
ここで、「APIキー」と「秘密鍵」という名前(鍵名称)は、顧客取引所204の情報システム上で扱われる表現(文字列)に合わせてある。これが可能なのは、鍵定義テーブル2031において取引所と言語毎に鍵の名前を記録しているためである。このようにすることで、鍵登録処理部2033Aにおける鍵登録画面表示の実装が一度完了すれば、その後はUI表示技術を知らないプログラマでも、新たな取引所に対応するプログラムを書き、この鍵の名前の対応を記述するだけで、鍵登録画面を表示できる。これにより、少ない人数でより多くの取引所に素早く対応することができるため、非常に重要である。また、鍵の名称が鍵登録画面と取引所の鍵情報ページとで一貫性があるため、顧客はどの鍵を入力すれば良いのか迷う必要がないため、ユーザビリティの観点からも有用である。
【0145】
これを実現する一つの方法が、オブジェクト指向による継承と、国際化(Internationalization)技術を利用することである。ここでは、
図40にJava(登録商標)言語による具体例を示す。プログラマは
図40のメソッドを全ての取引所クラスに定義するだけで良い。ここで取引所クラスとは、顧客取引所毎に定義され、各取引所に関する情報を保持するクラスである。
図40のメソッドは、鍵の名称に関する情報(KeyInfo)を配列(array)に並べて返す処理を行うものである。ここで、配列の要素はそれぞれ1つの鍵に対応する。そのため、鍵が2種類ある場合、配列の長さは2となる。配列の各要素は、それぞれ文字列(String)と真偽値(boolean)を保持するインスタンスである。
【0146】
UI表示部36036Aは、これらの情報に基づき
図39の画面を表示する。ここで、鍵登録画面の生成処理のうち、鍵を入力するテキストボックスを画面に追加する手順を
図41に示す。前提として、当該手順の開始時には、画面のテキストボックスより上の部分については既に生成されているものとする。また、UI表示部36036Aは、ステップS3701で選択された取引所の識別子(取引所ID)を特定している。まずステップ4101で、UI表示部36036Aは、予め選択されている表示言語を取得し、変数localeに代入する。次にステップ4102でUI表示部36036Aは、
図40のメソッドを呼び出し、得られた配列をnamesという変数に代入する。そして、配列namesの各要素のそれぞれについて(つまり、eachとして)、ステップ4103からステップ4106またはステップ4107までを繰り返す。ステップ4103では、UI表示部36036Aは、まずlocaleに対応した翻訳テーブル(鍵定義テーブル2031)よりeach.getName()が返すキーに対応した文字列を取得し、これを変数labelに代入する。翻訳テーブルについては後に説明する。次のステップ4104で、UI表示部36036Aは、変数labelに代入された文字列をテキストボックスに付随するラベルとして、画面上に追加する。ここで、each.hide()はテキストボックスの属性を表す。UI表示部36036Aは、ステップ4105でeach.hide()がtrueであると判定した場合、ステップ4107で顧客201が入力した文字列が伏せ字で表示されるテキストボックスを画面に追加する。逆に、each.hide()がfalseの場合、UI表示部36036Aは、入力した内容が見えるテキストボックスを画面に追加する。UI表示部36036Aは、以上のループの後、画面の残りの部分を追加し、画面を完成する。
【0147】
ここで、上述した翻訳テーブル(鍵定義テーブル2031)は、例えば
図7のようにルックアップテーブルになっており、左の列(キー)にある文字列を検索し、右の列(鍵名称20314)の文字列を取得する形式を取る。ここで、「キー」は、例えば、取引所20311及び鍵種別20313を組み合わせたものであるが、これに限定されない。
図7は日本語の翻訳テーブルの例であるが、この翻訳テーブルを対応言語(言語20312)の数だけ用意する。取引所毎言語毎に翻訳テーブルを用意しても良いが、この例では全ての取引所で用いられる鍵名称20314の文字列を1つの翻訳テーブルに保持している。左の列(キー)の文字列は、
図40のメソッドが返す文字列である。翻訳テーブルは、長期記憶装置3504上のファイルから読み込んでも、データベース内のテーブルであっても、保存場所は問わない。プログラムとは別の場所に翻訳テーブルを持つと、取引所の表現が変わった場合に、プログラマでない担当者でも鍵登録ページの表現を追随させることができる。
【0148】
図36と
図37に戻り説明を続ける。UI表示部36036Aは、
図39の鍵登録画面3900の鍵入力欄412及び422に入力(S3705)された鍵の文字列と鍵名称411及び421のそれぞれに対応する鍵種別とを対応付けた鍵情報を、鍵登録処理部2033Aに渡す(S3706)そして、鍵登録処理部2033Aは、受けた鍵情報を鍵情報テーブル2032Aに登録する。例えば、鍵登録処理部2033Aは、取引所IDを取引所20322として、受信した鍵情報に含まれる鍵種別203231及び鍵203232の組と対応付けて、鍵情報テーブル2032Aに追加又は更新する。
【0149】
ここで、鍵情報テーブル2032Aの例を
図42に挙げる。取引所の列には、取引所を表す識別子(取引所ID等)を保持する。鍵情報の列には、
図4で入力した鍵がjson(JavaScript(登録商標) Object Notation)形式で保持されている。json形式の各対は、鍵の内部的な名前と
図39で入力した鍵の値となっている。尚、鍵情報は配列でも構わないが、鍵情報を可変要素数の構造に保持している理由は、取引所によって鍵の数が異なるためである。尚、セキュリティを確保するために、鍵情報は暗号化するべきであるが、暗号化の方法は公知技術を用いることができるため説明を省略する。また、OAuthなどの方法によりアクセストークンを入手する方法がある取引所においては、この方法によってアクセストークンを入手し、これを鍵として鍵情報テーブル2032Aに登録することもできる。また、顧客201に代わって顧客取引所204にログインし、自動的に鍵情報20422を取得しても良いことは言うまでもない。尚、本実施形態7においても、上述した実施形態2のように、鍵定義テーブルにおいて鍵の個数を管理するものとしてもよい。この場合、本実施形態7の鍵情報テーブルや鍵登録処理部を実施形態2の構成を踏まえて、鍵の個数を用いた処理に修正することで実現できる。
【0150】
図43は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図を示す。本実施形態では、預金管理を行うウォレット機能と通貨交換を行う取引所機能が、同じ顧客取引所204で行われるものとする。店舗サーバ205Aは、店舗の公式ウェブサイトを提供するコンピュータ装置である。店舗サーバ205Aは、記憶装置にSSL証明書2053(公開鍵証明書)を保存している。ここで、SSL証明書2053は、信頼された認証局が店舗サーバ205AのURL(及びサイト運営組織)の信頼性を証明した電子証明書である。
図43の送金指示装置203Aは、
図36の送金指示装置203Aと同じものであるが、一部構成を省略している。
【0151】
送金指示を行う際のシーケンスを
図43と
図44を参照して説明する。まず、販売員4201が支払情報提示装置4205を操作して、二次元コードを顧客201に提示する。支払情報提示装置4205はタブレットのようなディスプレイがついたものが使用状況を想像しやすいが、パーソナルコンピュータやスマートフォンや専用端末など他の情報処理装置であっても良い。二次元コードには、店舗公開鍵URL(第1の宛先情報)、取引ID、送金先アドレス、通貨、金額の組に店舗秘密鍵42051で電子署名した情報(以後、「支払情報」と呼ぶ)をパラメータとした承認URLが符号化されている。(以下、「電子署名」と記述する場合、「暗号化」によっても同様以上の効果が得られるので、「電子署名あるいは暗号化」を表して「電子署名」とだけ記述する。)顧客201が送金指示装置203Aを操作し、撮像装置3506によってこれを読み取らせる(S4201、S4701)。ここでは、二次元コードを使用した例を示すが、バーコードなど他の光学的情報を利用しても良い。また、通信部105を利用して他の手段で支払情報を受け取っても良い。ここで、店舗公開鍵URLは、(店舗の公開鍵の保存先である)店舗サーバのホスト名及びドメイン名を用いたURLにおいて、ディレクトリ及びパス名として店舗の公開鍵を記述したものである。例えば、店舗サーバ205AのURLが「https://example.com」であり、店舗の公開鍵が「XY・・・Z」である場合、店舗公開鍵URLは、「https://example.com/XY・・・Z」と記述することができる。そのため、店舗公開鍵URLは、店舗サーバURLを含むものといえる。送金指示装置203Aは、承認URLを復号化すると、ディープリンク機能により、送金処理部2034AやUI表示部36036Aなどを含んだ送金指示アプリケーションソフトウェアを起動する(S4702)。
【0152】
送金指示アプリケーションソフトウェアが起動した後、送金処理部2034Aは、支払情報から店舗公開鍵URLを抽出し、そのURLのホスト名(店舗サーバURL)によって示される店舗サーバ205AのSSL証明書2053をhttps通信が定める方法によりダウンロードし(S4202、S4703)、その正当性を検証する。そして、送金処理部2034Aは、店舗公開鍵URLから店舗公開鍵42052をhttps通信によりダウンロードして、抽出した支払情報について(支払情報提示装置4205において)店舗公開鍵42052に対応する店舗秘密鍵42051を用いて電子署名されていることを検証する(S4203、S4704)。正しく電子署名されていることが確認されたら、送金処理部2034Aは、
図45のような画面(送金許可画面4300)を生成するのに必要な情報をUI表示部36036Aに渡す(S4705)。この時、UI表示部36036Aは、ダウンロードしたSSL証明書2053がEV証明書ならば、Organization(O)フィールドから取得した組織名を店舗名2501として画面に追加する。また、送金処理部2034Aは、店舗サーバURLから抽出した文字列を店舗名2501の下のホスト名(第1の宛先情報に含まれる情報)として追加する。尚、ホスト名には、SSL証明書2053のCommon Name(CN)フィールドから取得したもの(公開鍵証明書に含まれる情報)を用いても良い。送金処理部2034Aは、店舗がSSL証明書によって検証されたことを示す場合にアイコン2508(公開鍵証明書により検証済みであることを示す情報)を追加する。送金処理部2034Aは、顧客201が登録している取引所の内、支払情報に指定してある通貨での送金ができる取引所を選択肢として選択可能にドロップダウンメニュー(取引所選択欄)2503に設定する。送金処理部2034Aは、ドロップダウンメニュー2503で選択された取引所が扱える通貨を選択肢として選択可能にドロップダウンメニュー(通貨選択欄)2507を設定する。
【0153】
そして、UI表示部36036Aは、生成した送金許可画面4300を画面に表示する(S4204、S4706)。そして、顧客201が承認ボタン2505を選択すると(S4707)、UI表示部36036Aは、送金許可画面4300上に表示された通貨、送金額及び取引IDを含む送金許可を送金処理部2034Aに通知する(S4205、S4708)。
【0154】
さて、上記店舗公開鍵URLのパスには文字列パターンに制限を設けても良い。例えば、店舗公開鍵URLは半角のスラッシュ(/)を3つまでしか含まないとすれば、ウェブサイトのホスティングサービス(つまり他社)のSSL証明書を流用することは難しくなる。また、特定のドメインの利用を禁止しても良く、また特定のドメインでは文字列パターンの制限を変更または解除しても良い。
【0155】
本実施形態では送金対象の通貨を切り替えることができる。そのためには、顧客201が承認ボタン2505を押下する前に次のような操作を行うこととなる。例えば、顧客201がドロップダウンメニュー2507で通貨を選択すると、送金額2502aに選択された通貨での換算金額が表示される。例えば、UI表示部36036Aは、選択された通貨を送金処理部2034Aへ通知し、送金処理部2034Aにより算出した換算金額を得て、更新された送金許可画面4300を表示しても良い。
【0156】
また、顧客201が承認ボタン2505を選択した際のドロップダウンメニュー2507で選択された通貨が支払情報に含まれる通貨と同じ場合には、他の実施形態と同様に、送金処理部2034Aは、その通貨で送金する。より具体的には、送金処理部2034Aは特定部として、送金許可に含まれる取引所ID(送金実行サービス)に対応付けられた鍵情報20323を、鍵情報テーブル2032Aの中から特定して読み出す。そして、送金処理部2034Aは、特定された鍵情報を用いて、選択された取引所(ここでは、顧客取引所204)の送金実行サービス2041に対して、送金許可されたデジタル通貨及び送金額について送金先である店舗の送金先アドレスへの送金指示を送信する(S4207、S4711)。
【0157】
一方、顧客201が承認ボタン2505を選択した際のドロップダウンメニュー2507で選択された通貨が支払情報に含まれる通貨と異なる場合(通貨交換を伴う場合)には、送金処理部2034Aは、選択した通貨を支払情報の通貨に交換して(S4206、S4709)から送金する。この時、成行で注文することもできるが、換算金額以上の交換とならないように指し値で注文することも可能である。その時の指し値は換算金額を求める際に利用した換算レートである。
【0158】
通貨交換が行われた後、送金処理部2034Aは、顧客取引所204に交換された換金額を確認し(S4710)、換金額を支払情報の送金先アドレスへ送金するよう、顧客取引所204に送金指示を送信する(S4207、S4711)。そして、顧客取引所204の送金実行サービス2041は、台帳208に送金事実を書き込む(S4208)。その後、店舗取引所207は台帳208を監視し、店舗取引所207は台帳208を監視し、当該店舗の送金先アドレスへの着金を検出し、送金先アドレスの残高を支払情報提示装置4205へ送信することができるので、支払情報提示装置4205はその残高を確認することにより、着金を知ることができる。店舗に複数の支払情報提示装置がある場合には、それぞれに送金先アドレスを割り振ると着金の監視がしやすい。あるいは、メモリ容量が許す場合、支払情報提示装置4205は、台帳208を直接監視しても良い。その際、送金指示装置203Aより送金の際の台帳上の識別子(Transaction ID; txid)を二次元コードなどで取得すれば、より効率よく監視が可能となる。あるいは、取引の度に新しい送金先アドレスを生成すれば顧客と取引との対応関係を明確にすることもできる。あるいは実施形態8で示すような方法で店舗サーバ205Aの通知先にtxidを送信すると、店舗側が着金を確実に捉えることができる。
【0159】
以上、本実施形態では送金指示装置に店舗の情報(店舗名や送金先アドレスなど)が予め登録されていなくても、任意の店舗サーバが取引を開始できる送金指示装置を示した。SSL証明書を利用することにより、店舗の信用が評価され、顧客が安心して支払いを済ませることができる。また、これにより店舗の二次元コードの上に偽のシールを貼る詐欺行為なども防ぐことができる。更に本実施形態では、支払情報の電子署名を検証するための公開鍵を、SSL証明書で保証されたhttpsサーバに置くことにより、支払情報の署名元を保証できている。SSL証明書の秘密鍵を支払情報提示装置と共有することなくこれを可能とすることで、SSL証明書の秘密鍵が漏洩するリスクを低減している。また、これまで発行した承認URLを無効にするためには、店舗サーバ上の公開鍵を削除するだけで良い。
【0160】
ここで、SSL証明書や電子署名の検証をなくせば、ウェブサーバを持たない任意の個人でも支払情報提示装置と同じ構成の装置で支払いを請求できるシステムになっている点にも触れておく。つまり返金処理は、顧客側が二次元コードを提示し、店舗側が送金指示装置を利用することで簡単に行うことができる。
【0161】
また、支払情報に含まれる複数の要素(店舗公開鍵URL、取引ID、送金先アドレス(送金先口座)、通貨、金額、通知先等)の内、どの要素を承認URLのパラメータとし、どの要素を店舗サーバによって提供するかは、変更しても良い。また、その要素の一部を顧客が入力することにしても良い。例えば、実施形態2のように承認URLのパラメータとして取引IDを含め、上記の他の要素を店舗サーバ205Aから提供しても良い。この場合、支払情報提示装置4205は、送金先アドレス、通貨、金額及び通知先等を含めた支払情報(と取引IDと)を、(店舗サーバURLに対応する)店舗サーバ205Aへ予め通知しておく。(取引IDは、店舗サーバ205Aが発行しても良い。)そして、支払情報提示装置4205は、パラメータに店舗サーバURLと取引IDを指定した承認URLを、送金指示装置203Aに対して出力する。送金指示装置203Aの送金処理部2034Aは、承認URLを取得すると、承認URLのパラメータから店舗サーバURLと取引IDを抽出し、店舗サーバURL及び取引IDを用いて店舗サーバ205Aへ支払情報要求を送信する。店舗サーバ205Aは、送金指示装置203Aから受け付けた取引IDを元に支払情報を(必要に応じて生成し、)送金指示装置203Aへ返信する。あるいは、実施形態5及び6のように、承認URLのパラメータに上述した支払情報URL(支払情報を記載したウェブページのURL)を含め、店舗サーバ205Aから送金指示装置203Aに支払情報を提供しても良い。この場合、支払情報提示装置4205は、パラメータに支払情報URLを指定した承認URLを送金指示装置203Aに対して出力する。送金指示装置203Aの送金処理部2034Aは、承認URLを取得すると、承認URLのパラメータから支払情報URLを抽出し、支払情報URLを用いて店舗サーバ205Aへ支払情報要求を送信する。店舗サーバ205Aは、支払情報URLに対する支払情報要求に応じて要求元の送金指示装置203Aへ支払情報を返信する。
【0162】
また、支払情報提示装置は、少なくとも、支払情報を特定するための支払情報特定情報を出力するものということができる。ここで、支払情報特定情報は、支払情報そのものであるか、支払情報へのアクセス情報(例えば、支払情報URL、取引ID、店舗サーバURL、店舗公開鍵URL等)であってもよい。また、支払情報特定情報は、支払情報又は支払情報へのアクセス情報をパラメータに指定した承認URLなどの電子的情報や、これらを二次元コードなどの視覚的情報で表現したものであってもよい。これらの場合、送金指示装置203Aの送金処理部2034Aは、支払情報提示装置4205から取得した支払情報特定情報に基づいて支払情報を特定し、特定した支払情報に基づいて送金指示を行う。例えば、支払情報特定情報が支払情報へのアクセス情報である場合、送金処理部2034Aは、支払情報特定情報からアクセス情報を抽出し、当該アクセス情報により店舗サーバから支払情報を取得できる。
【0163】
支払情報提示装置による支払情報特定情報の出力の仕方には、次のようなものが挙げられる。例えば、支払情報提示装置は、自身に搭載されるか又は接続されたディスプレイに対して支払情報特定情報を表示させるために出力してもよい。この場合、上述した通り、送金指示装置は、自己に搭載されたカメラ等の読取部を介して、上記ディスプレイに表示された支払情報特定情報を取得できる。または、支払情報提示装置は、送金指示装置に対して有線又は無線通信により支払情報特定情報を送信することにより出力してもよい。この場合、送金指示装置は、支払情報提示装置から受信した支払情報特定情報を自己の表示部に表示してもよい。または、送金指示装置は、支払情報提示装置に対して支払情報特定情報の取得要求を送信し、支払情報提示装置は、取得要求の応答として支払情報特定情報を返信してもよい。この場合も、送金指示装置は、受信した支払情報特定情報を自己の表示部に表示してもよい。または、送金指示装置は、受信した支払情報特定情報から支払情報やアクセス情報の抽出を行ってもよい。
【0164】
本実施形態では特に、送金指示サービスを提供する企業は一切のサーバを管理する必要がなく、鍵の管理も顧客に任せることができるため、極めて低いコストで送金が可能となる。また、支払情報提示装置が支払情報を提示する際にサーバと通信する必要がないので、支払情報を遅延なく提示することができるのも利点である。同時に、支払情報は各店舗サーバが用意し、送金指示も各顧客端末が処理するため、処理負荷が分散され、また送金実行サービスは通常高負荷に耐えうる設計となっているため、極めて安価に処理能力の高い包括的決済サービスが提供できる。
【0165】
本実施形態では、ディープリンク機能により送金指示アプリケーションソフトウェアが起動する例を示したが、送金指示アプリケーションソフトウェア自体に二次元コードを撮影し、認識する機能を実装することで、送金処理部の処理を開始しても良い。
【0166】
また、本実施形態でも、上述した実施形態1から6と同様に、複数の決済業者からの支払いを包括的に扱い、顧客の利便性を図ることができる。
【0167】
<実施形態8>
本実施形態は、他の実施形態の変形例であり、URLのリンクを開くことにより支払い手続きを開始する例を示す。送金を扱うのは、電子マネーやショッピングポイントや法定通貨などを扱う金融機関や決済サービスを想定しているが、APIによって送金・支払いが指示できるものと仮定している。これら金融機関や決済サービスを一括して「金融機関」と呼ぶことにする。また、送金や振込や支払いや決済や送金予約などデジタル通貨を送ることに関する用語もまとめて「送金」と呼ぶことにする。
【0168】
本実施形態にかかる送金指示装置におけるハードウェアの構成は
図35と同様であるものとする。よって、FPGAなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム35021には、本実施形態にかかる送金指示装置の処理が実装されているものとする。
【0169】
図46は、本実施形態にかかるデジタル通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。
図46と
図47のシーケンス図を用いて本実施形態における送金の流れを説明する。店舗サーバ205Bは、送金指示装置203Bからの送金開始のトリガーその他の発注シーケンスに伴い、顧客201のメールアドレスを宛先とし、承認URL2051を本文に記載した支払請求メールをメールサーバ209に対して送信する(S4401、S4801)。このとき、承認URL2051は、送金処理部2034BやUI表示部36036Bなどを含んだ送金指示アプリケーションソフトウェア(以下、送金指示アプリ)を起動するためのディープリンクである。(送金指示アプリがインストールされていない場合には、承認URLは送金指示アプリをインストールすることを勧めるウェブページ、あるいはウェブサーバ上に実装されている送金指示装置を指す。)尚、支払請求メールは、店舗サーバ205B以外の店員が操作する端末から送信されても構わない。
【0170】
メールサーバ209は、一般的なメールサーバである。メールサーバ209は、店舗サーバ205Bから支払請求メールを受信し、支払請求メール2091として記憶装置に記憶する。メールサーバ209は、送金指示装置203Bのメールクライアント2023からのメール受信要求に応じて支払請求メール2091を送金指示装置203Bへ送信する。
【0171】
送金指示装置203Bのメールクライアント2023は、起動時等にメールサーバ209に対してメール受信要求を送信し、メールサーバ209から承認URL2051を含む支払請求メール2091を受信する(S4402、S4802)。受信した支払い請求メール2091は顧客201に表示される(S4403、S4803)。顧客201が受信したメールに記載された承認URLを選択すると(S4404、S4804)、送金指示アプリが起動する(S4805)。送金指示アプリが起動する際に、顧客201のパスワード入力や生体認証など認証手順を求めることができる。送金処理部2034Bは送金指示アプリ起動後、先ほどのステップS4404(S4804)で選択された承認URLのパラメータ(あるいは、そのリダイレクト先)が指し示す店舗サーバ205Bの店舗サーバURLに対してSSL証明書を要求し、店舗サーバ205BからSSL証明書2053を取得する(S4405、S4806)。送金処理部2034Bは、取得したSSL証明書2053の内容を検証する。検証が成功すると、送金処理部2034Bは、承認URLのパラメータ(あるいはそのリダイレクト先)として指定されていたエンドポイントに対してGETリクエストを発行する。GETリクエストを受けた店舗サーバ205Bは、送金通貨、送金額、送金先アドレス(送金口座)、及び通知先を含む支払情報をhttpsによって返信する(S4406、S4807)。ここでは、httpsを用いた例を示したが、支払情報を秘密にする必要がない場合には、支払情報がSSL証明書2053の秘密鍵によって電子署名されていれば、暗号化されていない通信方法でも改竄が防げるのは言うまでもない。また当然ながら、http/httpsによらずとも他の通信方法によっても同様の効果が得られる。
【0172】
送金処理部2034Bは、取得した支払情報やSSL証明書の内容をUI表示部36036Bに渡し(S4808)、UI表示部36036Bはその内容を
図48のような画面(送金許可画面4500)に表示する(S4407、S4809)。ここで、アイコン2508はSSL証明書を検証したことを表すアイコンである。店舗名2501はSSL証明書のOrganization(O)フィールドから取得したものであり、検証したSSL証明書がEV証明書あるいはOV(Organizational Validation)証明書の場合にのみ表示する。その下のホスト名は、店舗サーバURLから抽出したものであり、SSL証明書に含まれているドメイン名と合致する。ドロップダウンメニュー2503では、送金を行う金融機関(決済サービス)を選ぶことができる。(
図48では、金融機関として「ポイントカードA」が選択されている。)金額4502aは、ドロップダウンメニュー2503で選ばれた金融機関が扱う通貨での換算金額が表示される。
【0173】
顧客201が支払情報を確認したら、承認ボタン2505を選択し(S4810)、UI表示部36036Bは送金処理部2034Bにその旨通知する(S4408、S4811)。送金処理部2034Bは、送金許可画面4500上に表示または選択された送金額及び金融機関による送金が許可された旨を送金許可として、店舗サーバ205Bに通知する(S4409、S4812)。具体的には、先の支払情報の通知先には送金許可通知の通知先URLが含まれているので、送金処理部2034Bは、通知先URLに対してhttps POSTリクエストを発行する。通知先には明示的に取引IDを送らなくても、URLにその情報を組み入れることで、パラメータとして扱わずに同様の効果が得られる。
【0174】
また、支払情報の通知先に通知先URLの代わりに電話番号が指定されている場合には、送金処理部2034Bは、送金許可通知文をその電話番号宛てにSMSとして送る。あるいは、自動音声メッセージとしてその電話番号に音声通話を行っても良い。
【0175】
そして、送金処理部2034Bは、顧客201の鍵を利用して送金指示を金融機関4404へ送信する(S4410、S4813)。鍵の使用法は、金融機関が指定する方法に合わせるが、例えば、鍵のひとつ(秘密鍵)で「もうひとつの鍵、送金額及び送金先口座」の組を電子署名して金融機関に送信するなどして送金指示を行う。もうひとつの鍵は送金元口座などを表す識別子である。この後、送金指示を受信した金融機関4404の送金実行サービス44041は、送金を行う。
【0176】
以上、本実施形態では、URLを利用して送金を行う例を示した。本実施形態では、メールによりURLを送信する例を示したが、当然ウェブページにURLを記述することも可能である。
【0177】
また、本実施形態でも、上述した実施形態1から7と同様に、複数の決済業者からの支払いを包括的に扱い、顧客の利便性を図ることができる。
【0178】
<その他の実施の形態>
尚、上述した送金先アドレスや暗号化された文字列などは、例示に過ぎない。
【0179】
また、上述した取引記録の承認は、プルーフオブワーク(PoW)に限定されず、プルーフオブステーク(PoS)、プルーフオブインポータンス(PoI)、プルーフオブヒューマンワーク(PoH)その他の方式を用いても構わない。
【0180】
また、上述した各実施形態の送金指示装置又は送金実行装置は、以下のような構成を備えることができる。ここで、「ページ」と表記したものは、ウェブページのページであっても、アプリケーションソフトウェアの画面であっても良い。
【0181】
すなわち、前記所定のデジタル通貨と他の通貨との換算レートに基づき前記送金額を当該他の通貨に換算した換算金額を算出する換算部をさらに備えることができる。
【0182】
そして、前記ユーザの端末に表示させる表示用ページに、前記換算金額を追加する表示情報生成部をさらに備えることができる。
【0183】
そして、前記表示情報生成部は、前記複数のデジタル通貨のそれぞれに対応する取引記録の承認履歴に基づき、前記複数の送金実行サービスのうち少なくとも一部を選択し、当該選択された送金実行サービスのリストを前記ユーザへの選択肢として前記表示用ページにさらに追加するとよい。
【0184】
また、前記送金指示部は、前記ユーザにより前記他の通貨が選択された場合、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記選択された他の通貨へ交換させ、当該交換後の金額について前記送金指示を行うようにしてもよい。
【0185】
また、前記特定部は、前記ユーザにより他の送金実行サービスが選択された場合、前記鍵情報記憶部の中から当該他の送金実行サービス及び前記ユーザに対応付けられた鍵を新たに特定し、前記送金指示部は、前記所定の送金実行サービスに代えて、前記新たに特定された鍵を用いて前記他の送金実行サービスに対して、前記換算金額の送金指示を行うとよい。
【0186】
前記換算部は、前記所定の送金実行サービスによる送金手数料を加味して、前記換算金額を算出するとよい。
【0187】
または、前記送金指示部は、前記送金額と比べて前記換算金額の方が前記ユーザの基軸通貨における費用総額が低い場合に、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金先アドレスへ前記送金指示を行うようにしてもよい。
【0188】
また、前記換算部は、前記デジタル通貨の取引所から取得した前記換算レートを用いて、前記換算金額を算出するとよい。
【0189】
また、前記換算部は、前記デジタル通貨の取引所から取得した板情報から前記換算レートを算出するとよい。
【0190】
さらに、前記換算部は、前記板情報に含まれる通貨売買における取引量を加味して前記換算レートを算出するとよい。
【0191】
また、前記他の通貨は、前記ユーザの基軸通貨であるとよい。
【0192】
または、前記送金指示部は、前記送金額を前記所定のデジタル通貨から他の通貨に交換した場合の期待される処理時間が指定された時間以内の場合に、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金指示を行うようにしてもよい。
【0193】
また、支払情報はSSL証明書の秘密鍵の代わりに、店舗秘密鍵で電子署名されても良い。
【0194】
また、支払情報に含まれる複数の要素(店舗サーバURL、取引ID、送金先アドレス(送金先口座)、通貨、金額、通知先等)の内、どの要素を承認URLのパラメータとし、どの要素を店舗サーバによって提供するかは、変更しても良い。また、その要素の一部を顧客が入力することにしても良い。特に、支払情報の要素の一つである「金額」を店舗サーバで提供すれば、承認URLは店舗あるいはキャッシュレジスターで固定することができ、二次元コードであればシールを貼り付けるなどできる。または、「金額」が承認URLに含まれていても、商品毎に承認URLを固定することは可能である。
【0195】
尚、上述した実施形態1、2,4及び5にかかる送金指示装置は、顧客コンピュータ202で実行されるOS上で動作するアプリケーションとして実現してもよい。その場合、顧客コンピュータ202内の記憶装置は、鍵定義テーブル及び鍵情報テーブルその他の各種テーブル、並びに、鍵登録処理部及び送金処理部その他の各種処理部を実装したプログラムを記憶してもよい。そして、顧客コンピュータ202内のプロセッサが記憶装置から当該プログラムをメモリに読み込み実行することにより、顧客コンピュータ202が鍵登録処理部及び送金処理部その他の各種処理部として動作する。尚、この場合、顧客コンピュータ202と送金指示装置203等の間の通信は、顧客コンピュータ202内部の通信に置き換わる。また、鍵情報テーブルを顧客コンピュータに置く場合、ユーザが一意に決まり、顧客を特定する処理は不要となることがある。
【0196】
尚、上述の実施の形態では、ハードウェアの構成として説明したが、これに限定されるものではない。本開示は、任意の処理を、CPUにコンピュータプログラムを実行させることにより実現することも可能である。
【0197】
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD-ROM(Read Only Memory)、CD-R、CD-R/W、DVD(Digital Versatile Disc)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0198】
尚、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。