JP6445211B1 - 送金指示装置、送金指示方法、送金指示プログラム及び送金指示システム - Google Patents

Abstract

【課題】複数の交換業者からの支払いを包括的に扱い、顧客の利便性を図ること。
【解決手段】送金指示装置は、登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵のそれぞれと、を対応付けて記憶する鍵情報記憶部と、所定の送金実行サービスと、当該所定の送金実行サービスを利用するユーザとに基づいて、鍵情報記憶部の中から鍵を特定する特定部と、所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、特定された鍵を用いて所定の送金実行サービスに対して、指定された所定のデジタル通貨及び送金額について、指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、を備える。
【選択図】図２

Description

本発明は、送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムに関し、特にデジタル通貨の送金指示を行う送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムに関する。

ネットワーク化された現在における決済では、硬貨、紙幣及び小切手等の物理的通貨に代わって、通貨を電子的に表現したデジタル通貨による送金が一般的となっている。ネットワーク上の支払いにおいて、現時点では、クレジットカードや銀行振り込みなどが一般的である。例えば米国におけるＰａｙＰａｌ（登録商標）（特許文献１）という決済サービスでは、ユーザがクレジットカード番号や銀行口座番号を登録することにより、顧客が指定するクレジットカードや銀行口座を、商取引に利用することができる。店舗側は、ＰａｙＰａｌにてアカウントを作成し、顧客からの送金はこのアカウントに蓄積する。（以下、「店舗」という表現を用いているが、これは必ずしも商品を販売している店とは限らない。個人やサービス提供会社や単なる送金先口座などを表し、送金の受け手を代表するものとしてこの表現を使用している。）

他方、近年においては仮想通貨（又は「暗号通貨（Cryptocurrency）」とも呼ばれる。）に対する注目が集まってきている。送金をしやすくする名目で開発されてきた仮想通貨であるが、送金の匿名性に注力してきたこともあったため、送金者の特定がしにくい場合がある。この問題を解決するために、電子商取引を行う店舗は、個々の仮想通貨交換業者と契約し、送金サービスを利用することができる。例えば、日本のｂｉｔＦｌｙｅｒ（登録商標）社が提供するｂｉｔＷｉｒｅ（登録商標） ＳＨＯＰという決済サービスでは、送金先アドレスの自動生成とメールアドレスによる送金者の確認が行われる。このサービスもＰａｙＰａｌ同様、店舗はｂｉｔＦｌｙｅｒにおいてアカウントを作成し、顧客からの送金はこのアカウントに蓄積する。また、異なる取引所間の送金では送金先アドレスを入力しなくてはならず、現段階ではこれをＱＲコード（登録商標）のスキャンで代用することが、ユーザビリティが高いと言われている。

米国特許第７，０８９，２０８号明細書

ところが、店舗がより多くの顧客と商取引（特に仮想通貨による支払、決済）を行おうとする場合、複数の決済業者（仮想通貨交換業者）と提携しなければならない。しかし、小規模な店舗や個人が複数の仮想通貨交換業者と提携するのは手続やコスト面から実現性が低い。また、店舗が仮想通貨交換業者との提携を行わない場合には、店舗は各顧客に都度、送金先アドレスを伝え、個々の顧客が利用する交換業者を活用して手動による送金を依頼することになる。よって、顧客の利便性が損なわれる。そこで、複数の交換業者からの支払いを包括的に扱い、顧客の利便性を図るサービスの登場が望まれる。

本開示は、このような問題を解決するためになされたものであり、複数の交換業者からの支払いを包括的に扱い、顧客の利便性を図るための送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムを提供することを目的とする。

本開示の第１の態様にかかる送金指示装置は、
登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵のそれぞれと、を対応付けて記憶する鍵情報記憶部と、
所定の送金実行サービスと、当該所定の送金実行サービスを利用する前記ユーザとに基づいて、前記鍵情報記憶部の中から鍵を特定する特定部と、
所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨及び前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、
を備える。

本開示によれば、複数の交換業者からの支払いを包括的に扱い、顧客の利便性を図るための送金指示装置、送金指示方法、送金指示プログラム及び送金指示システムを提供することができる。

実施形態１にかかる送金指示装置におけるハードウェアの構成を表すブロック図である。 実施形態１にかかる仮想通貨の送金に関する情報システムの構成、及び、顧客の鍵を登録するシーケンスを表すブロック図である。 実施形態１にかかる顧客取引所において表示される、鍵情報ページの例である。 実施形態１にかかる送金指示装置にアクセスした際に表示される鍵登録ページの例である。 実施形態１にかかる送金指示装置において、鍵の名前を知ることのできる情報を返すメソッドの例。 実施形態１にかかる送金指示装置において、鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示すフローチャート図である。 実施形態１にかかる送金指示装置における日本語の翻訳テーブルの例である。 実施形態１にかかる送金指示装置における鍵情報テーブルの例である。 実施形態１にかかる支払い手続きに関係する構成、及び、支払手続きの流れを示すシーケンスを表すブロック図である。 実施形態１にかかる送金指示装置が生成する送金許可ページの例である。 実施形態１にかかる送金指示装置において、店舗情報を保持する店舗情報テーブルの例である。 実施形態２にかかる仮想通貨の送金に関する情報システムの構成、及び、支払い手続きのシーケンスを表すブロック図である。 実施形態２にかかる鍵定義テーブルのルックアップテーブルの例である。 実施形態２にかかる鍵情報テーブルの例である。 実施形態２にかかる鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示す。 実施形態２にかかる鍵登録ページの例である。 実施形態２にかかる送金許可ページの例である。 実施形態２にかかる送金指示装置において、換算レートを求める際のフローチャート図である。 実施形態３にかかる送金指示システムにおける送金許可シーケンスのブロック図である。 実施形態３にかかる送金指示システムにおけるスマートフォンアプリの送金許可画面の例である。 実施形態３にかかる送金指示システムにおいて、店舗情報を保持する店舗情報テーブルの例である。 実施形態３にかかる送金指示システムにおいて、各通貨の属性を保持する送金先アドレス生成制御テーブルの例である。 実施形態３にかかる送金指示システムにおいて、送金先アドレス生成用の鍵などを保持するデータベーステーブルの例である。 実施形態４にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。 実施形態４にかかる送金指示装置における送金許可ページの例である。 実施形態４にかかる送金指示装置において、取引所に交換注文を出す際のフローチャート図である。 実施形態５にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。 実施形態５にかかる送金指示装置における鍵情報データベースの例である。 実施形態５にかかる送金指示装置における取引ログの１エントリーの例である。 実施形態５にかかる送金指示装置における引き出し用ウェブページの例である。 実施形態５にかかる送金指示装置における取引ログの１エントリーの例である。 本実施形態６にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。 本実施形態６にかかる店舗サーバの商品ページの例である。 本実施形態６にかかる商品ページの価格表示欄付近のＨＴＭＬ記述の例である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。尚、本実施形態で取り扱う送金対象の通貨は、通貨を電子的に表現したデジタル通貨である。デジタル通貨は、例えば、仮想通貨、電子マネー等が挙げられるが、法定通貨との換金が保証されるか否かは問わない。また、デジタル通貨は、硬貨や紙幣が存在しない法定通貨であってもよい。また、以下の説明におけるｈｔｔｐｓ（Hypertext Transfer Protocol Secure）は、暗号化通信の一例に過ぎず、他の暗号化通信技術を適用しても構わない。

＜実施形態１＞
本実施形態では、デジタル通貨の取引所におけるサービス機能が送金実行サービスに組み込まれており、送金実行サービスで使われている鍵の名前がそのまま送金指示装置が提供するユーザインタフェースに表示される例を示す。

図１は、実施形態１にかかる送金指示装置１００におけるハードウェアの構成を表すブロック図である。同図において、ＣＰＵ（Central Processing Unit、中央処理装置）１０１は、本実施形態にかかる送金指示装置の処理が実装されたプログラム１０２１を実行する。プログラムメモリ１０２は、ＣＰＵ１０１により実行されるプログラム１０２１を記憶する。ＲＡＭ（Random Access Memory）１０３は、ＣＰＵ１０１によるプログラム実行時に、各種情報を一時的に記憶する揮発性記憶装置である。尚、ＣＰＵ１０１によるプログラム実行時に、ＲＡＭ１０３がプログラム１０２１を記憶することにより、ＲＡＭ１０３はプログラムメモリ１０２の役目を果たすように実装することもできる。ハードディスク１０４は、ＲＡＭ１０３に比べてより長期の間、各種情報を記憶する不揮発性記憶装置である。通信部１０５は、他の装置と通信するために利用される。ＣＰＵ１０１、プログラムメモリ１０２、ＲＡＭ１０３、ハードディスク１０４及び通信部１０５は、バス１０６により接続され、データや制御信号を互いに受け渡すために用いられる。本明細書では、ＣＰＵによるプログラム実行を説明するが、ＦＰＧＡ（Field-Programmable Gate Array）などの集積回路でも同様の機能が実装できる。

また、本実施形態において、データベース機能が使用されるが、データベースに保管するデータは、ハードディスク１０４上やＲＡＭ１０３上などに記憶される。あるいは、他の装置上に記憶され、通信部１０５を利用して、読み書きすることも可能である。

図２は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、顧客の鍵を登録する際のシーケンスを表すブロック図である。ここで、顧客取引所２０４は、１種類以上の仮想通貨の（通貨間の交換等の取引を含む）送金を仲介する仮想通貨交換業者が運用する情報システムである。顧客取引所２０４は、自己が管理する（登録済みの）複数のユーザ（例えば、顧客２０１）のそれぞれに対して、複数の仮想通貨を送金するサービスを提供する送金実行サービス２０４１を備える。ここで、顧客取引所２０４と送金実行サービス２０４１とは一対一で対応するものとする。そして、顧客取引所２０４は、鍵情報テーブル２０４２を記憶し、鍵情報テーブル２０４２は、顧客２０４２１ごとに、鍵情報２０４２２を対応付けて保存する。鍵情報２０４２２は、送金実行サービス２０４１として提供されるＡＰＩ（Application Programming Interface）を利用するための鍵（ＡＰＩ ｋｅｙ等）２０４２２２と、その種別である鍵種別２０４２２１との組合せを複数、含むものである。つまり、顧客２０４２１と鍵情報２０４２２とは一対一で対応し、鍵情報２０４２２には、鍵種別２０４２２１と鍵２０４２２２の組が１以上含まれる。よって、各鍵２０４２２２は、顧客２０４２１ごとに異なる。そして、顧客取引所２０４は、ＷＥＢシステム２０４３としての機能を有し、顧客２０１からの鍵情報要求に応じて、鍵情報テーブル２０４２の中から顧客２０１を顧客２０４２１として対応付けられた鍵情報２０４２２を読み出して、鍵情報２０４２２（鍵種別２０４２２１と鍵２０４２２２の組）を出力する。但し、鍵の保存方法や出力又は通知の仕方はこれに限定されない。

顧客コンピュータ２０２は、顧客２０１が操作するコンピュータ端末であり、例えば、ブラウザ等（アクセス処理部２０２１）が動作するパーソナルコンピュータ、スマートフォン、タブレット等である。尚、顧客２０１は「送金元」、及び、所定の送金実行サービスを利用するユーザの一例である。

送金指示装置２０３は、顧客及び取引所ごとの鍵情報を管理し、複数の取引所に対して送金指示を行うことが可能な情報処理装置である。尚、送金指示装置２０３は、複数台の情報処理装置により分散して、又は、冗長化して実現してもよい。送金指示装置２０３は、鍵定義テーブル２０３１と、鍵情報テーブル２０３２と、鍵登録処理部２０３３と、送金処理部２０３４とを備える。鍵定義テーブル２０３１は、複数の送金実行サービスのそれぞれごとに、前記鍵に関する定義を記憶するテーブルである。ここでは、鍵定義テーブル２０３１は、取引所及び言語ごとに、当該取引所で提供される送金実行サービスのＡＰＩを利用する際に必要となる鍵について、当該取引所の情報システム上で用いられる鍵の名称の文字列を鍵の種別ごとに管理するテーブルである。鍵定義テーブル２０３１は、取引所２０３１１、言語２０３１２、鍵種別２０３１３及び鍵名称２０３１４が対応付けられている。尚、鍵名称は、取引所ごとに少なくとも１以上であればよい。当然のことながら、鍵種別２０３１３は、鍵種別２０４２２１と同じ内容である必要はなく、配列内の位置で鍵種別を表してもよい。また、鍵定義テーブル２０３１は、言語ごとに別テーブルとしてもよい。

鍵情報テーブル２０３２は、顧客２０３２１及び取引所２０３２２ごとに、鍵情報２０３２３を管理するテーブルである。鍵情報２０３２３には、鍵種別２０３２３１と鍵２０３２３２との組が複数含まれる。

鍵登録処理部２０３３は、顧客からの鍵の登録要求に応じて鍵定義テーブル２０３１を参照して鍵登録ページを生成して返信し、鍵登録ページを介して入力された鍵を鍵情報テーブル２０３２に登録する。送金処理部２０３４は、顧客からの送金要求に応じて、指定された仮想通貨及び金額について指定された取引所に対して、鍵情報テーブル２０３２に登録された鍵を用いて送金先への送金指示を行う。

続いて、図２を用いて顧客の鍵を登録する処理の流れを説明する。まず、顧客コンピュータ２０２のアクセス処理部２０２１は、顧客２０１の操作に応じて、顧客取引所２０４に対して鍵情報要求を送信する（Ｓ１０１）。例えば、顧客コンピュータ２０２は、顧客２０１がアカウントを持つ顧客取引所２０４のウェブサイトにログインし、顧客取引所２０４のＷＥＢシステム２０４３は、鍵情報テーブル２０４２を参照し、顧客２０１に対応付けられた鍵情報２０４２２を読み出して、鍵２０４２２２とその鍵種別２０４２２１の名称の文字列とを対応付けた鍵情報ページを生成し、顧客コンピュータ２０２に表示させるために、鍵情報ページを送信する（Ｓ１０２）。尚、顧客取引所２０４と顧客コンピュータ２０２の間の通信方法については本発明の対象外のため、説明を省く。アクセス処理部２０２１は、顧客取引所２０４から受信した鍵情報ページを画面（不図示）に表示する。顧客コンピュータ２０２に表示される鍵情報ページ３００は、例えば図３のように鍵が２つとし、それぞれ鍵名称３１１「ＡＰＩキー」と鍵名称３２１「秘密鍵」という名前が付いているものとする。そして、鍵情報ページ３００は、鍵名称３１１に対応付けられた鍵３１２と、鍵名称３２１に対応付けられた鍵３２２とが表示されていることを示す。よって、顧客２０１は、顧客コンピュータ２０２の画面に表示された鍵情報ページ３００を介して、鍵名称ごとの鍵の文字列を目視及びコピーする等により、鍵を入手できる。

次に、顧客２０１は顧客コンピュータ２０２を操作して、先ほど入手した鍵を送金指示装置２０３に登録する。本実施形態では、送金指示装置２０３はウェブサーバの機能を持つものとする。そのため、顧客コンピュータ２０２と送金指示装置２０３とは原則としてｈｔｔｐｓを用いた通信を行う。まず、顧客コンピュータ２０２のアクセス処理部２０２１は、送金指示装置２０３が提供する鍵登録のためのウェブページ（鍵登録ＵＲＬ（Uniform Resource Locator））にアクセスする（Ｓ１１１）と、顧客２０１がまだログインをしていない場合、送金指示装置２０３は、顧客コンピュータ２０２にログインページを返信する（Ｓ１１２）。これに応じて、アクセス処理部２０２１は、受信したログインページを画面に表示する。顧客２０１がログインページに対してユーザ名とパスワードを入力すると、アクセス処理部２０２１はこれを送金指示装置２０３へ、認証情報として送信する（Ｓ１１３）。尚、アクセス処理部２０２１は、併せて、鍵の登録対象の取引所の識別情報（取引所ＩＤ等）を送金指示装置２０３へ送信してもよい。あるいは、前記鍵登録ＵＲＬに識別情報を含めてもよい。この認証情報が送金指示装置２０３に事前に登録してあるものと一致すれば、送金指示装置２０３の鍵登録処理部２０３３は鍵登録ページを生成する。このとき、鍵登録処理部２０３３は、鍵定義テーブル２０３１を参照し、ステップＳ１１３等で受信した取引所ＩＤ及びアクセス処理部２０２１側の表示言語に基づき、鍵種別２０３１３及び鍵名称２０３１４を読み出して、鍵名称２０３１４に対応する鍵の入力欄を含む鍵登録ページを生成する。そして、鍵登録処理部２０３３は、顧客コンピュータ２０２に、生成した鍵登録ページを送信する（Ｓ１１４）。このとき、認証状態を維持するために、鍵登録処理部２０３３はクッキーを顧客コンピュータ２０２に送ることもできる。アクセス処理部２０２１は、送金指示装置２０３から受信した鍵登録ページを画面に表示する。

顧客コンピュータ２０２に表示される鍵登録ページ４００は、例えば図４のように、取引所名称４０１について、鍵名称４１１「ＡＰＩキー」と鍵名称４２１「秘密鍵」を入力するテキストボックス（鍵入力欄４１２及び４２２）を含む。顧客２０１は、顧客コンピュータ２０２に表示される鍵登録ページ４００における、「ＡＰＩキー」と「秘密鍵」のそれぞれに対応する鍵入力欄４１２及び４２２に、図３からコピーした情報を入力する。

ここで、「ＡＰＩキー」と「秘密鍵」という名前（鍵名称）は、顧客取引所２０４の情報システム上で扱われる表現（文字列）に合わせてある。これが可能なのは、鍵定義テーブル２０３１において取引所と言語毎に鍵の名前を記録しているためである。このようにすることで、鍵登録処理部２０３３における鍵登録ページ（ウェブページ）の生成処理の実装が一度完了すれば、その後はＨＴＭＬなどのフロントエンド技術を知らないバックエンド技術者でも、新たな取引所に対応するプログラムを書き、この鍵の名前の対応を記述するだけで、鍵登録ページを自動生成できる。これにより、少ない人数でより多くの取引所に素早く対応することができるため、非常に重要である。また、鍵の名称が鍵登録ページと取引所の鍵情報ページとで一貫性があるため、顧客はどの鍵を入力すれば良いのか迷う必要がないため、ユーザビリティの観点からも有用である。

これを実現する一つの方法が、オブジェクト指向による継承と、国際化（Internationalization）技術を利用することである。ここでは、図５にＰｙｔｈｏｎ言語による具体例を示す。バックエンド技術者は図５のメソッドを全ての取引所クラスに定義するだけで良い。ここで取引所クラスとは、顧客取引所毎に定義され、各取引所に関する情報を保持するクラスである。図５のメソッドは、文字列（ｓｔｒ）と真偽値（ｂｏｏｌ）の対（ｔｕｐｌｅ）を配列（ｌｉｓｔ）に並べて返す処理を行うものである。ここで、配列の要素はそれぞれ１つの鍵に対応する。そのため、鍵が２種類ある場合、配列の長さは２となる。

鍵登録処理部２０３３は、これらの情報に基づき図４のウェブページを生成する。ここで、鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を図６に示す。前提として、当該手順の開始時には、ウェブページ上のテキストボックス以前の部分については既に生成されているものとする。また、鍵登録処理部２０３３は、ステップＳ１１１又はステップＳ１１３で受け付けた取引所ＩＤを特定している。まずステップ６０１で、鍵登録処理部２０３３は、顧客コンピュータ２０２のブラウザで選択されている表示言語を取得し、変数ｌｏｃａｌｅに代入する。次にステップ６０２で、鍵登録処理部２０３３は、図５のメソッドを呼び出し、得られた配列をｎａｍｅｓという変数に代入する。そして、配列ｎａｍｅｓの各要素のそれぞれについて（つまり、ｅａｃｈとして）、ステップ６０３からステップ６０６またはステップ６０７までを繰り返す。ステップ６０３では、鍵登録処理部２０３３は、まずｌｏｃａｌｅに対応した翻訳テーブル（鍵定義テーブル２０３１）よりｅａｃｈの最初の要素に対応した文字列を取得し、これを変数ｌａｂｅｌに代入する。翻訳テーブルについては後に説明する。次のステップ６０４で、鍵登録処理部２０３３は、変数ｌａｂｅｌに代入された文字列をテキストボックスに付随するラベルとして、ウェブページ上に追加する。ここで、ｅａｃｈの第２要素は、テキストボックスの属性を表す。鍵登録処理部２０３３は、ステップ６０５でｅａｃｈ［１］がＴｒｕｅであると判定した場合、ステップ６０７で顧客２０１が入力した文字列が伏せ字で表示されるテキストボックスをウェブページに追加する。逆に、ｅａｃｈ［１］がＦａｌｓｅの場合、鍵登録処理部２０３３は、入力した内容が見えるテキストボックスをウェブページに追加する。鍵登録処理部２０３３は、以上のループの後、ウェブページの残りの部分を追加し、ウェブページを完成する。

ここで、上述した翻訳テーブル（鍵定義テーブル２０３１）は、例えば図７のようにルックアップテーブルになっており、左の列（キー）にある文字列を検索し、右の列（鍵名称２０３１４）の文字列を取得する形式を取る。ここで、「キー」は、例えば、取引所２０３１１及び鍵種別２０３１３を組み合わせたものであるが、これに限定されない。図７は日本語の翻訳テーブルの例であるが、この翻訳テーブルを対応言語（言語２０３１２）の数だけ用意する。取引所毎言語毎に翻訳テーブルを用意しても良いが、この例では全ての取引所で用いられる鍵名称２０３１４の文字列を１つの翻訳テーブルに保持している。左の列（キー）の文字列は、図５のメソッドが返す文字列である。翻訳テーブルは、ハードディスク１０４上のファイルから読み込んでも、データベース内のテーブルであっても、保存場所は問わない。プログラムとは別の場所に翻訳テーブルを持つと、取引所の表現が変わった場合に、プログラマでない担当者でも鍵登録ページの表現を追随させることができる。

図２に戻り説明を続ける。アクセス処理部２０２１は、図４の鍵登録ページ４００の鍵入力欄４１２及び４２２に入力された鍵の文字列を鍵名称４１１及び４２１のそれぞれに対応する鍵種別に対応付けた鍵情報を、送金指示装置２０３へ送信する（Ｓ１１５）。そして、鍵登録処理部２０３３は、受信した鍵情報を鍵情報テーブル２０３２に登録する。例えば、鍵登録処理部２０３３は、ログインユーザを顧客２０３２１、取引所ＩＤを取引所２０３２２として、受信した鍵情報に含まれる鍵種別２０３２３１及び鍵２０３２３２の組と対応付けて、鍵情報テーブル２０３２に追加又は更新する。

ここで、鍵情報テーブル２０３２の例を図８に挙げる。取引所の列には、取引所を表す識別子（取引所ＩＤ等）を保持する。顧客の列には、顧客を表す識別子（ログインされたユーザＩＤ等）を保持する。鍵情報の列には、図４で入力した鍵がｊｓｏｎ（JavaScript（登録商標） Object Notation）形式で保持されている。ｊｓｏｎ形式の各対は、鍵の内部的な名前と図４で入力した鍵の値となっている。尚、鍵情報は配列でも構わないが、鍵情報を可変要素数の構造に保持している理由は、取引所によって鍵の数が異なるためである。尚、セキュリティを確保するために、鍵情報は暗号化するべきであるが、暗号化の方法は公知技術を用いることができるため説明を省略する。また、ＯＡｕｔｈなどの方法によりアクセストークンを入手する方法がある取引所においては、この方法によってアクセストークンを入手し、これを鍵として鍵情報テーブル２０３２に登録することもできる。

続いて、図９を用いて本実施形態にかかる支払い手続きに関係する構成を説明する。まず、図９では、図２の構成の一部を省略し、また、支払い手続きに関係する構成を追加している。送金指示装置２０３は、図２の構成に加え、店舗情報テーブル２０３５を備えるものとする。店舗情報テーブル２０３５は、後述する店舗サーバ２０５を運用する店舗に関する情報を管理するテーブルである。特に、店舗情報テーブル２０３５は、店舗公開鍵２０３５１を店舗ごとに管理しているものとする。店舗公開鍵２０３５１は、店舗サーバ２０５の暗号用の公開鍵である。尚、店舗情報テーブル２０３５のその他の構成は、後述する。

店舗サーバ２０５は、電子商取引のＷＥＢサイトを提供するコンピュータ装置である。尚、店舗サーバ２０５は、これを運用する店舗の業者と対応し、「送金先」の一例といえる。店舗サーバ２０５は、記憶装置に承認ＵＲＬ２０５１を保存している。承認ＵＲＬ２０５１は、送金許可のために顧客コンピュータ２０２がアクセスするべき送金指示装置２０３のＵＲＬである。尚、店舗サーバ２０５のその他の構成は、公知技術を用いて実現可能であるため、詳細な説明を省略する。店舗取引所２０７は、店舗サーバ２０５を運用する店舗の業者がユーザとして登録されている仮想通貨の取引所である。よって、店舗取引所２０７の構成は、顧客取引所２０４と同等であるため、詳細な説明を省略する。台帳２０８は、任意の仮想通貨の取引記録、例えば、ブロックチェーンを便宜上、機能ブロックとして記載したものである。

上記を踏まえ、図９を用いて支払手続きの流れを説明する。まず、顧客２０１が顧客コンピュータ２０２を利用して、店舗サーバ２０５での発注シーケンスに入る。発注シーケンスは、個々の店舗によって異なるので、ここでは説明しない。顧客２０１は、発注シーケンスの最後に購買を確定する操作を行う。店舗によっては、「注文を確定する」というボタンを顧客２０１がクリックする。これにより、アクセス処理部２０２１は、送金を開始するトリガーを店舗サーバ２０５へ送信する（Ｓ２０１）ことになる。すると、店舗サーバ２０５は、店舗ＩＤ、取引ＩＤ、通貨、金額、送金先アドレスの組（以後、「支払情報」と呼ぶ。）を店舗サーバ２０５の秘密鍵（非公開鍵）で電子署名した情報と、送金許可のための承認ＵＲＬ２０５１を顧客コンピュータ２０２に返信する（Ｓ２０２）。ここで「店舗ＩＤ」とは店舗に固有の識別子である。「取引ＩＤ」は、同じ店舗内であれば固有であり、支払いを識別する識別子である。アクセス処理部２０２１は、受信した電子署名付きの支払情報をボディ部に格納し、ｈｔｔｐｓにより承認ＵＲＬ２０５１にＰＯＳＴリクエストを発行する（アクセスする）（Ｓ２０３）。送金指示装置２０３の送金処理部２０３４は、店舗公開鍵２０３５１を用いて、受信した支払情報が店舗サーバ２０５の秘密鍵によって電子署名されていることを確認する。そして、この時点でログインされていなければ（有効なクッキーが顧客コンピュータ２０２に保存されていなければ）、送金処理部２０３４は、ログインページを顧客コンピュータ２０２へ返信する（Ｓ２０４）。これに応じて、アクセス処理部２０２１は、受信したログインページを画面に表示する。顧客２０１がログインページに対してユーザ名とパスワードを入力すると、アクセス処理部２０２１は、その認証情報（入力されたユーザ名とパスワードの組を含む）を送金指示装置２０３へ送信する（Ｓ２０５）。送金処理部２０３４は、受信した認証情報が予め保存されているものと一致していれば、支払情報の中の通貨と金額を含んだウェブページ（送金許可ページ）を生成する。そして、送金処理部２０３４は、生成した送金許可ページを送信詳細として顧客コンピュータ２０２へ送信する（Ｓ２０６）。アクセス処理部２０２１は、送金指示装置２０３から受信した送金許可ページを画面に表示する。

図１０は、本実施形態１にかかる送金許可ページ１０００の例である。送金許可ページ１０００は、店舗名１００１と、送金額１００２と、取引所選択欄１００３と、中止ボタン１００４と、承認ボタン１００５等を含む。店舗名１００１は、送金先の店舗名を表示する欄である。ここで、送金指示装置２０３が備える店舗情報テーブル２０３５は、一例として図１１のような構成とする。ここでは、店舗名の列にｊｓｏｎ形式のデータを保持している。構造体のキーとして表示言語を、値として店舗名を持つ。構造体に所望の言語が含まれていない場合には、キーが”ｄｅｆａｕｌｔ”の値を使用する。そのため、送金処理部２０３４は、受信した支払情報に含まれる店舗ＩＤにより店舗情報テーブル２０３５を検索して、店舗名を取得する。このとき、送金処理部２０３４は、顧客コンピュータ２０２のブラウザに指定されている表示言語をキーとしてこの構造体を検索することで、その表示言語に合わせた店舗名を取得できる。そして、送金処理部２０３４は、取得した店舗名を送金許可ページ１０００の店舗名１００１に挿入する。当然のことながら、図１１のテーブルには店舗に関する他の列があっても良い。

送金額１００２は、発注に伴い、顧客側から店舗側へ送金される金額を表示する欄である。そのため、送金指示装置２０３は、受信した支払情報に含まれる通貨における金額を送金額１００２に挿入する。ここで、顧客２０１の設定として基軸となる通貨（基軸通貨）が送金指示装置２０３内のデータベースに保存されている場合、送金額をその基軸通貨の価値に換算した換算額をウェブページに追加することが可能である。これにより、顧客２０１は、自身の基軸通貨に換算した額により送金額の現在の価値を容易に把握することができる。そのためには、送金指示装置２０３は、予め顧客取引所２０４から板情報を入手しておくこととなる。「板情報」とは、その取引所での２通貨間の買値と売値の一覧である。板情報が送金通貨の売り買いを基軸通貨で表した一覧である場合、送金額の換算額は、（送金額 × 最大買値 − 交換手数料）である。逆に、板情報が基軸通貨の売り買いを送金通貨で表した一覧である場合、送金額の換算額は、（送金額 ／ 最小売値 − 交換手数料）である。交換手数料が送金通貨によって引かれる場合には、それぞれ（（送金額 − 交換手数料）× 最大買値）と（（送金額 − 交換手数料）／ 最小売値）である。ここで、最大買値又は最小売値を換算レートとみなすことができる。

また、取引所選択欄１００３は、送金元の取引所を選択するドロップダウンメニューである。送金処理部２０３４は、鍵情報テーブル２０３２の中から、ログインしている顧客２０１に関連付けられた鍵が登録されている取引所のリストを取得する。そして、送金処理部２０３４は、取引所選択欄１００３が選択されると取得したリストが表示されるように送金許可ページ１０００を生成する。よって、顧客２０１は、表示されたリストの中から所望の取引所を選択できる。尚、顧客取引所２０４は、後にログインしている顧客２０１に関連付けられたこの鍵を元に顧客２０１のアカウントを特定することで、送金元を決定することができる。尚、上記換算額が表示されている場合に顧客２０１が取引所選択欄１００３により他の取引所を選択すると、アクセス処理部２０２１は、送金指示装置２０３へその旨を通知する。そして、送金処理部２０３４は、上記に基づき、選択された取引所における換算額を再度算出し、ウェブページを更新して顧客コンピュータ２０２へ送信する。これにより、アクセス処理部２０２１は、更新後の換算額を表示する。

また、中止ボタン１００４は、支払いプロセスを中止させるためのものである。顧客２０１が中止ボタン１００４を選択した場合、アクセス処理部２０２１は、送金指示装置２０３へその旨を通知し、送金処理部２０３４は店舗サーバ２０５に支払いプロセスの中止の旨を通知し、支払いプロセスは中止される。具体的には、送金処理部２０３４は、店舗情報テーブル２０３５内の店舗に応じた通知ＵＲＬの列よりＵＲＬ文字列を取得し、末尾に／ｃａｎｃｅｌを追加したＵＲＬにＰＯＳＴリクエストを店舗サーバ２０５へ送信することで、「通知」を実現してもよい。この際、送金処理部２０３４は、ＰＯＳＴリクエストのボディ部に、取引ＩＤを含む情報について送金指示装置２０３の秘密鍵で電子署名した情報を入れる。店舗サーバ２０５はこの取引ＩＤを元に注文のキャンセル手続きを行う。

また、承認ボタン１００５は、顧客２０１が送金を許可して、支払いプロセスを継続させるためのものである。顧客２０１が承認ボタン１００５を選択した場合、アクセス処理部２０２１は、送金許可ページ１０００上に表示された通貨、送金額及び取引所による送金が許可された旨を送金指示装置２０３へ通知し（Ｓ２０７）、送金処理部２０３４は、店舗サーバ２０５に送金許可の旨を通知する（Ｓ２０８）。具体的には、送金処理部２０３４は、店舗情報テーブル２０３５内の店舗に応じた通知ＵＲＬの列よりＵＲＬ文字列を取得し、末尾に／ｃｏｎｆｉｒｍｅｄを追加したＵＲＬにＰＯＳＴリクエストを送信することで、「通知」を実現してもよい。この際、送金処理部２０３４は、ＰＯＳＴリクエストのボディ部に、取引ＩＤを含む情報について送金指示装置２０３の秘密鍵で電子署名した情報を入れる。

店舗サーバ２０５に送金許可の旨の通知を送った後、送金指示装置２０３の送金処理部２０３４は顧客取引所２０４に送金指示を送信する（Ｓ２０９）。

より具体的には、送金処理部２０３４は、送金を許可つまり承認したユーザ（ログインユーザ）と、送金許可された取引所（送金許可ページ１０００上で選択された取引所、つまり送金実行サービス２０４１）との組に対応付けられた鍵情報を、鍵情報テーブル２０３２の中から特定して読み出す。そして、送金処理部２０３４は、特定された鍵情報を用いて、選択された取引所（ここでは、顧客取引所２０４）の送金実行サービス２０４１に対して、送金許可されたデジタル通貨及び送金額について送金先である店舗サーバ２０５の送金先アドレスへの送金指示を送信する。

ここで、送金指示の送信方法は取引所毎に異なるが、例えばｈｔｔｐｓ：／／ｅｘｃｈａｎｇｅ．ｃｏｍ／ａｐｉ／ｗｉｔｈｄｒａｗにＰＯＳＴリクエストを送ることで行う。このとき、送金処理部２０３４は、鍵情報テーブル２０３２の取引所に対応する行の鍵情報の列における鍵の１つ（例えば、秘密鍵）を用いて以下の情報を電子署名した情報を、リクエストのボディ部に含める。
・鍵情報テーブル２０３２の取引所に対応する行の鍵情報の列からもう１つの鍵（例えば、ＡＰＩキー）
・（送金許可された）通貨
・（送金許可された）送金額
・（送金許可された）送金先アドレス

顧客取引所２０４の送金実行サービス２０４１は、送金指示装置２０３からの送金指示を受信した場合に、送金指示に用いられた鍵情報に基づいてユーザ（顧客２０１）を特定し、送金指示に含まれる通貨及び送金額から当該ユーザが利用可能な送金元アドレスを特定する。例えば、送金実行サービス２０４１は、受信した送金指示に含まれるＡＰＩキーによりユーザが顧客２０１であること及び当該ユーザの鍵を特定する。そして、送金実行サービス２０４１は、受信した送金指示に含まれる情報に電子署名を、特定した鍵により検証し、検証された場合に、受信した送金指示に含まれる通貨に基づいて、当該特定したユーザに対応する送金元アドレスを特定する。このとき、送金実行サービス２０４１は、送金元アドレスとして固定のものを用いても、または、動的に生成したものを用いてもよい。
その後、送金実行サービス２０４１は、特定された送金元アドレスから送金指示に含まれる送金先アドレスへ、送金指示に含まれる送金額を、送金指示に含まれる通貨に対応する台帳２０８に送金事実（取引記録）を書き込むことにより、送金を行う（Ｓ２１０）。例えば通貨がビットコインの場合、送金実行サービス２０４１は、ビットコインのブロックチェーンに送金事実を書き込む。

顧客取引所２０４に送金指示を出した後、送金指示装置２０３の送金処理部２０３４は台帳２０８を監視し続け、送金先アドレスへの送金が完了したと見なせるかどうかを判断する。通貨がビットコインの場合、送金処理部２０３４は、ブロックチェーン上で予め指定された回数の承認がなされた場合に、送金が完了したと見なす。尚、送金処理部２０３４は、送金情報で指定された所定のデジタル通貨に対応する取引記録が承認条件を満たす場合に送金が完了したとみなす。ここで、承認条件を可変としてもよい。例えば、承認条件は、送金指示装置２０３又は外部（例えば、店舗サーバ２０５等）により更新されたものであってもよい。送金が完了したと見なされたら、送金処理部２０３４は店舗サーバ２０５に着金通知を送信する（Ｓ２１１）。具体的には、送金処理部２０３４は、店舗情報テーブル２０３５内の店舗に応じた通知ＵＲＬの列よりＵＲＬ文字列を取得し、末尾に／ｔｒａｎｓｆｅｒｒｅｄを追加したＵＲＬにＰＯＳＴリクエストを送信することで、「着金通知」を実現してもよい。この際、送金処理部２０３４は、ＰＯＳＴリクエストのボディ部に、取引ＩＤを含む情報について送金指示装置２０３の秘密鍵で電子署名した情報を入れる。

尚、上記の説明では、より多くのリクエストを処理できるようにするためのロードバランサに関連する記述を省略した。但し、本実施形態は、多数のリクエストに対する負荷分散のためにロードバランサ等の公知技術を用いることができる。また、鍵登録処理部２０３３は、鍵登録部の一例である。また、送金処理部２０３４は、送金情報取得部、検証部、換算部、表示情報生成部、特定部、送金指示部及び着金通知部の一例である。そして、送金指示装置１００内のＣＰＵ１０１は、プログラム１０２１を実行することにより、鍵登録処理部２０３３及び送金処理部２０３４として機能する。また、「支払情報」は、所定のデジタル通貨における送金額と送金先とが指定された送金情報の一例である。

以上のように、本実施形態では、顧客の認証後に送金詳細が顧客コンピュータに表示される送金指示装置の例を示した。本実施形態では、顧客取引所が提示する鍵の名称を、取引所毎及び表示言語毎に保持することにより、顧客が迷わず送金指示装置にそれらの鍵を登録できるようにした。そのため、複数の交換業者を利用する顧客の利便性が向上できる。また、このようにすることによって、同時に送金指示装置の開発効率を上げ、より早くより多くの取引所に対応することができる。つまり、複数の交換業者に対する送金指示を包括的に扱うことができる。

＜実施形態２＞
本実施形態２は、実施形態１の変形例であり、送金許可シーケンスの効率を優先して、顧客の認証と同時に送金許可も行うシステムの例を示す。

本実施形態２にかかる送金指示装置におけるハードウェアの構成は図１と同様であるものとする。よって、ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム１０２１には、本実施形態２にかかる送金指示装置の処理が実装されているものとする。

鍵を登録するシーケンスは、実施形態１と同じように図２に従うものとする。但し、本実施形態２は、実施形態１と比べて開発効率を優先する例を示す。具体的には、鍵の個数と順番だけを顧客取引所と鍵登録ページとで一致させる。

図１２は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、支払い手続きのシーケンスを表すブロック図である。尚、図２又は図９と同じ構成には同じ符号を付し、説明を省略する。送金指示装置２０３ａは、送金指示装置２０３と比べて鍵定義テーブル２０３１ａ、鍵情報テーブル２０３２ａ、鍵登録処理部２０３３ａ及び送金処理部２０３４ａを備える。

鍵定義テーブル２０３１ａは、取引所２０３１１ごとの鍵個数２０３１５を管理するテーブルである。鍵定義テーブル２０３１ａを実現する一つの方法として、ルックアップテーブルを利用する方法がある。尚、鍵の個数の代わりに鍵の名称を保持し、適宜、鍵の名称の個数をカウントすることにより、実施形態１においても、テーブルを利用して実現できることは言うまでもない。図１３は、鍵定義テーブル２０３１ａのルックアップテーブルの例を示す。

図１２に戻り説明を続ける。鍵情報テーブル２０３２ａは、顧客２０３２１及び取引所２０３２２ごとに、鍵情報２０３２３ａを管理するテーブルである。鍵情報２０３２３ａは、複数の鍵２０３２３２を登録順で保持する。図１４は、鍵情報テーブル２０３２ａの例を示す。鍵情報の列には、複数の鍵が登録順にカンマ（,）で接続されていることを示す。ここで、鍵情報は可変長配列として表現されている。ここで、配列に格納される順番は、後述する鍵登録ページに表示される順番に対応する。

図１２に戻り説明を続ける。鍵登録処理部２０３３ａは、顧客からの鍵の登録要求に応じて鍵定義テーブル２０３１ａを参照して鍵登録ページを生成して返信し、鍵登録ページを介して入力された鍵を鍵情報テーブル２０３２ａに登録する。図１５は、本実施形態における鍵登録ページの生成処理のうち、鍵を入力するテキストボックスをウェブページに追加する手順を示す。尚、図１５のフローを実行する前に、ウェブページの上部分は既に生成されているものとする。まず、ステップ１４０１で、鍵登録処理部２０３３ａは、顧客コンピュータ２０２から受信した取引ＩＤにより鍵定義テーブル２０３１ａ内を検索し、対応する取引所の鍵の個数を取得し、取得した鍵の個数を変数ｋｅｙ＿ｃｏｕｎｔに代入する。次に、ステップ１４０２からステップ１４０４を昇順のループカウンタ変数をｄとしてｋｅｙ＿ｃｏｕｎｔ回だけ繰り返す。ループの初めのステップ１４０２では、鍵登録処理部２０３３ａは、変数ｌａｂｅｌに文字列“Ｋｅｙ ％ｄ”を代入する。ここで％ｄは変換指定子であり、実際の表示文字列では、“％ｄ”の部分が変数ｄの値（整数値）で置き換えられることを示す。次にステップ１４０３で、鍵登録処理部２０３３ａは、ウェブページに変数ｌａｂｅｌの値を表示するラベルを追加する。その次のステップ１４０４で、鍵登録処理部２０３３ａは、ステップ１４０３で追加したラベルに付随する形でテキストボックスを追加する。フローの実行が終わったら、鍵登録処理部２０３３ａは、ウェブページの残りの部分を完成させる。これにより、取引所の鍵の個数に応じたテキストボックスとそのラベルを含んだウェブページ（鍵登録ページ）が生成される。

図１６は、本実施形態における鍵登録ページ４００ａの例である。鍵登録ページ４００ａは、図４の鍵登録ページ４００と比べて、鍵名称４１１ａ及び４２１ａが、汎用的な表記（“Key”）に順序を示す番号（”1”,”2”）が付されたものとなったことを示す。つまり、鍵名称４１１ａ及び４２１ａは、いずれの取引所であっても同一の名称が表示される。

顧客２０１は顧客コンピュータ２０２に表示される鍵登録ページ４００ａに顧客取引所２０４から入手した鍵を入力する。これに応じて、アクセス処理部２０２１は、鍵登録ページ４００ａの鍵入力欄４１２及び４２２に入力された鍵の文字列を表示順序と対応付けた鍵情報を、送金指示装置２０３ａへ送信する。ここでは、アクセス処理部２０２１は、鍵入力欄４１２に入力された鍵の文字列を表示順序「１」、鍵入力欄４２２に入力された鍵の文字列を表示順序「２」に対応付けて鍵情報とする。そして、鍵登録処理部２０３３ａは、受信した鍵情報を、ログインユーザを顧客２０３２１、取引所ＩＤを取引所２０３２２として、受信した鍵情報に含まれる順序に従って鍵２０３２３２を、鍵情報テーブル２０３２ａに追加又は更新する。

図１２に戻り説明を続ける。本実施形態では、顧客２０１の通貨を扱う顧客ウォレット２０６と取引所２０４ａは別のサービスであると仮定する。顧客ウォレット２０６に預金管理や送金実行の機能はあるものの取引所機能がない場合や、顧客２０１が指定する基軸通貨を顧客取引所（ウォレット）が扱わない場合などがこれに該当する。また、顧客ウォレット２０６は、鍵情報テーブル２０３２ａに保存された鍵２０３２３２を用いて利用可能な送金実行サービス２０６１を有するものとする。尚、店舗ウォレット２０７ａは、店舗取引所２０７とは異なるサービスであるが、店舗取引所２０７を用いても構わない。また、店舗サーバ２０５ａは、上述した店舗サーバ２０５の構成に加え、記憶装置に公開鍵２０５２をさらに保存している。ここで、公開鍵２０５２は、送金指示装置２０３ａの暗号用の公開鍵である。一方、店舗サーバ２０５ａは、記憶装置には予め承認ＵＲＬを保存していない。

続いて、図１２を用いて、支払手続きの流れを説明する。まず、顧客２０１が顧客コンピュータ２０２を利用して、店舗サーバ２０５ａでの発注シーケンスに入る。顧客２０１は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部２０２１は、送金を開始するトリガーを店舗サーバ２０５ａへ送信する（Ｓ２０１）。ここで、店舗サーバ２０５ａは送金指示装置２０３ａとＷｅｂＳｏｃｋｅｔ Ｓｅｃｕｒｅのような双方向通信のセッションで長期接続されている。そして、店舗サーバ２０５ａは、店舗ＩＤ、通貨、金額、送金先アドレスの組に店舗サーバ２０５ａの秘密鍵で電子署名した情報（以後、「支払情報」と呼ぶ。）を送金指示装置２０３ａに送る（Ｓ２０２−１）。つまり、実施形態２にかかる支払情報は、取引ＩＤを含まなくてよい。送金指示装置２０３ａの送金処理部２０３４ａは、店舗公開鍵２０３５１を用いて、店舗サーバ２０５ａの秘密鍵による電子署名を確認した後、取引ＩＤを生成し、取引ＩＤに対して送金指示装置２０３ａの秘密鍵で電子署名した情報（以下、単に「取引ＩＤ」という。）を、送金許可のための承認ＵＲＬにパラメータとして付加して、店舗サーバ２０５ａに送信する（Ｓ２０２−２）。ここで、取引ＩＤは、他の装置が生成できない規則で生成されているのが望ましい。例えば、連続的に生成される数値を送金指示装置２０３ａの秘密鍵で電子署名したような識別子を用いることができる。また、送金指示装置２０３ａは、この取引ＩＤと先程の支払情報とを対応付けてデータベース（不図示）に格納する。同時に生成時刻を記録することも可能である。ＷｅｂＳｏｃｋｅｔ Ｓｅｃｕｒｅで店舗サーバ２０５ａのＳＳＬ証明書を要求するよう設定されている場合、支払情報は電子署名しなくて良い。

店舗サーバ２０５ａは、受信した承認ＵＲＬ（パラメータに取引ＩＤを含む）を顧客コンピュータ２０２へ送信する（Ｓ２０２−３）。そして、顧客コンピュータ２０２は、ｈｔｔｐｓにより受信した承認ＵＲＬに対してＧＥＴリクエストを送る（Ｓ２０３ａ）と、送金指示装置２０３ａは、これを受信する。送金指示装置２０３ａの送金処理部２０３４ａは、承認ＵＲＬのパラメータから取引ＩＤを抽出し、これを使ってデータベースから支払情報を読み込む。このとき、データベースに記録された生成時刻から、取引ＩＤの有効期限を確認しても良い。送金処理部２０３４ａは、この支払情報から、送金許可ページ１０００ａを生成し、送金詳細として顧客コンピュータ２０２へ返信する（Ｓ２０６ａ）。

このとき、送金処理部２０３４ａは、送金許可ページ１０００ａの生成において、実施形態１と同じように店舗ＩＤを使って店舗情報テーブル２０３５より店舗名を取得する。また、送金処理部２０３４ａは、支払情報の中から通貨と金額を抽出する。ここで、実施形態２では、送金処理部２０３４ａが送金通貨の量をも考慮して基軸通貨への換算レートを求める場合について説明する。

図１７は、送金許可ページ１０００ａの例を示す。送金許可ページ１０００ａはユーザ名とパスワードを入力するためのテキストボックス（ユーザ情報入力欄１００６）があり、顧客２０１がこれら情報を入力することにより、認証と送金許可を同時に行うことができる。また、顧客２０１が基軸通貨を選択するためのドロップダウンメニュー（基軸通貨選択欄１００２ｃ）が用意されている。使用するウォレットは予め送金通貨毎のデフォルトとして設定されているものとする。

また、送金許可ページ１０００ａは、送金額１００２ａと基軸通貨換算額１００２ｂとを含む。送金額１００２ａは、支払情報に含まれる通貨及び金額である。基軸通貨換算額１００２ｂは、上述した実施形態１で説明した「換算額」を表示する欄である。ここでは、換算額は、既定の取引所における「板情報」に基づき、送金額１００２ａから顧客２０１の基軸通貨に換算された金額である。尚、送金処理部２０３４ａは、取引所から定期的に板情報を取得してもよい。

図１８は、換算レートを求める際のフローチャート図である。まずステップ１７００で、送金処理部２０３４ａは、取引所２０４ａより板情報を入手し、配列ｂｏａｒｄに代入する。板情報が送金通貨の売り買いを基軸通貨で表した一覧である場合、送金処理部２０３４ａは、ｂｏａｒｄに（買値、取引量）の対を買値が降順になるようにソートした配列を代入する。逆に、板情報が基軸通貨の売り買いを送金通貨で表した一覧である場合、送金処理部２０３４ａは、ｂｏａｒｄに（売値、取引量）の対を売値が昇順になるようにソートした配列を代入する。次にステップ１７０１で、送金処理部２０３４ａは、送金額を線形変換して変数ｓｉｚｅに代入する。この時の線形係数と定数項は通貨毎に調整する必要がある。次にステップ１７０２からステップ１７０４のループを変数ｉを昇順のループカウンタ変数として繰り返す。まずステップ１７０２で、送金処理部２０３４ａは、変数ａｓｋｂｉｄに配列ｂｏａｒｄのｉ番目の要素を代入する。これにより、構造体ａｓｋｂｉｄのｐｒｉｃｅフィールド（ａｓｋｂｉｄ．ｐｒｉｃｅ）には買値または売値が、ｖｏｌｕｍｅフィールド（ａｓｋｂｉｄ．ｖｏｌｕｍｅ）には取引量が保持されることとなる。次のステップ１７０３では、送金処理部２０３４ａは、変数ｓｉｚｅからａｓｋｂｉｄ．ｖｏｌｕｍｅだけ減算する。次のステップ１７０４で、送金処理部２０３４ａは、変数ｓｉｚｅと０の比較が行われ、ｓｉｚｅが０より大きければ、ループを続ける。逆にｓｉｚｅが０以下であれば、ステップ１７０５へと進む。ステップ１７０５では、送金処理部２０３４ａは、その時のａｓｋｂｉｄ．ｐｒｉｃｅを換算レートとする。ｂｏａｒｄに買値が保持されている場合、送金額の換算額は、（送金額 × 換算レート − 交換手数料）となる。ｂｏａｒｄに売値が保持されている場合には、送金額の換算額は、（送金額 ／ 換算レート − 交換手数料）となる。ただし、交換手数料が送金通貨で行われる場合には、それぞれ（（送金額 − 交換手数料）× 換算レート）と（（送金額 − 交換手数料）／ 換算レート）となる。つまり、この例では、換算額を算出する際に、実際の取引量（注文における取引額）を累積して、送金額に達したときの買値又は売値を換算レートとして用いることを示す。以上のように換算レートを求めるのは、通貨によっては取引量が少なかったり、あるいは売値または買値の提示が次の瞬間に消えてしまったりして、多めの取引をしようとした場合、思わぬ価格の乱高下に見舞われることがあるためである。

図１２に戻って、送金許可後のシーケンスを説明する。顧客コンピュータ２０２のアクセス処理部２０２１は、受信した送金許可ページ１０００ａを表示する。そして、顧客２０１は、送金許可ページ１０００ａに対してユーザ名とパスワードを入力し、必要に応じて基軸通貨選択欄１００２ｃの中から所望の通貨を選択して、基軸通貨換算額１００２ｂの表示を切り替える。その後、顧客２０１が承認ボタン１００５を選択した場合、アクセス処理部２０２１は、認証情報及び送金許可を送金指示装置２０３ａへ送信する（Ｓ２０７ａ）。具体的には、アクセス処理部２０２１は、送金許可ページ１０００ａのユーザ情報入力欄１００６に入力されたユーザ名とパスワードの組を含めて認証情報として送信する。また、アクセス処理部２０２１は、送金許可ページ１０００ａ上に表示された通貨、送金額及び取引所による送金が許可された旨を送金指示装置２０３ａへ送信する。

その後、送金指示装置２０３ａの送金処理部２０３４ａは店舗サーバ２０５ａに送金許可通知を送り（Ｓ２０８）、顧客ウォレット２０６に送金指示を発行する（Ｓ２０９ａ）。送金指示の送信方法は顧客ウォレット２０６が定義するが、送金許可された送金先及び送金額、並びに、鍵を含む情報を送信するなどできる。このとき、送金処理部２０３４ａは、鍵情報テーブル２０３２ａから顧客と取引所（顧客ウォレット２０６）が合致する行を検索し、鍵情報を取得する。尚、顧客ウォレット２０６が複数の通貨を扱うウォレットであれば、送金処理部２０３４ａは、送金指示に送金通貨も含めて指定する。

顧客ウォレット２０６の送金実行サービス２０６１は、送金指示装置２０３ａから受信した送金指示を受信した場合に、送金指示に含まれる送金先へ、送金指示に含まれる送金額を送金する（Ｓ２１０）、例えば、送金実行サービス２０６１は、通貨に対応する台帳２０８に送金事実を書き込むことにより、送金を行う。その後、送金実行サービス２０６１は、台帳２０８を監視し続ける。

そして、送金指示装置２０３ａは、顧客ウォレット２０６の定める方法によって着金の通知を待つ。例えば、送金実行サービス２０６１が台帳２０８のブロックチェーン上で予め指定された回数の承認がなされた場合に、送金が完了したと見なし、送金指示装置２０３ａに対して着金通知を送信する（Ｓ２１１−１）。送金指示装置２０３ａの送金処理部２０３４ａは、顧客ウォレット２０６より着金通知を受け取ると、長期接続のセッションを使って顧客サーバ２０５ａに取引ＩＤを含む情報によって着金通知を送る（Ｓ２１１−２）。

以上、本実施形態において、顧客の認証と同時に送金許可を行うシステムの例を示した。また、顧客ウォレットとは別の取引所サービスから板情報を取得する例を示した。特に、換算レートを求めるに当たって最大買値及び最小売値だけでなく複数の買値及び売値とその取引量を考慮することによって、大きな送金額の交換における予期せぬ価格下落を抑えることとした。また、着金監視を顧客ウォレットサービスに頼ることにして、本発明が様々な接続形態によっても実現できることを示した。

＜実施形態３＞
本実施形態３は、実施形態１又は２の変形例である。本実施形態３は、同じ店舗宛ての送金であっても支払ごとに異なる送金先アドレスを用いるために、送金先アドレスを動的に生成する例を示す。また、送金実行サービスの間で共通の方法で送金依頼ができる形式が定められるようになった場合、例えば、送金実行サービスを利用するためのインタフェースが統一された場合を想定する。更に、指定された通貨以外の通貨による送金にも対応する。

本実施形態３にかかる送金指示装置におけるハードウェアの構成は図１と同様であるものとする。よって、ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム１０２１には、本実施形態３にかかる送金指示サーバの処理が実装されているものとする。

鍵を登録するシーケンスは、実施形態１と同じように図２に従うものとする。また、本実施形態３では送金実行サービスの間で送金依頼の方法が共通化されているので、鍵の名前と数も共通化されている。故に鍵登録ページ上の鍵の名称は固定となる。例えば、顧客２０１がスマートフォンアプリから鍵を登録する場合、画面上の鍵の名前は固定で良い。また、顧客２０１がウェブページで鍵の登録を行う場合は、ＨＴＭＬ記述の中に鍵の名前が書き込んであれば良い。そのため、本実施形態３では、鍵定義テーブルが不要となる。

図１９に、本実施形態にかかる送金指示システムにおける送金許可シーケンスのブロック図を示す。ここで、送金指示サーバ２０３ｂは、店舗の送金先アドレス生成ためのアドレス生成鍵２０３６１を記憶装置に保存しているものとする。このアドレス生成鍵２０３６１は、予め店舗側が登録しても良いが、送金指示サーバ２０３ｂで自動生成しておいても良い。尚、送金指示サーバ２０３ｂは、図示しない構成として上述した鍵情報テーブル２０３２ａや店舗情報テーブル２０３５を備えるものとする。

また、他の実施形態では１つだった店舗サーバが、顧客のユーザインタフェースを提供する店舗販売サーバ２０５ｂと、注文を処理する店舗処理サーバ２０５ｃとに分かれる。また、本実施形態３では顧客コンピュータの代わりに顧客スマートフォン２０２ａを使用するものとする。顧客スマートフォン２０２ａにアプリ２０２２を実行させる場合、送金指示装置の一部機能を肩代わりできる。そのため、他の実施形態では送金指示装置としていたものを２つに分け、本実施形態３では送金指示サーバ２０３ｂの鍵登録処理部２０３３ｂ及び送金処理部２０３４ｂと顧客スマートフォン２０２ａ上のアプリ２０２２を合わせて送金指示システムとみなすものである。尚、顧客スマートフォン２０２ａは、記憶装置（不図示）に本実施形態３にかかるアプリ２０２２の処理が実装されたプログラムが記憶されており、プロセッサ（不図示）が記憶装置からメモリへ当該プログラムを読み込み実行することにより、本実施形態３にかかるアプリ２０２２の機能を実現するものとする。

顧客スマートフォン２０２ａ上のアプリ２０２２には認証機能が実装されており、顧客２０１がユーザ名とパスワードを入力すると、それらが送金指示サーバ２０３ｂに送られる。送金指示サーバ２０３ｂは、それらを受け取ると、データベース内に保持しているユーザ名とパスワードの組と照合し、一致すれば認証トークンを返す。認証トークンは認証を繰り返さなくても良くするための情報であり、例えば（ユーザ名、時刻）の組を送金指示サーバ２０３ｂの秘密鍵で電子署名したものを使うことができる。パスワードをそのまま送らずにチャレンジ・レスポンス方式でもパスワードの照合が可能であることは当業者の間では公知のことである。またパスワードをそのまま比較するのではなく、パスワードのハッシュ値を比較する手法も公知である。

まず、顧客２０１が顧客スマートフォン２０２ａを利用して、店舗販売サーバ２０５ｂでの発注シーケンスに入る。そして、顧客２０１は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部２０２１ａは、送金を開始するトリガーを店舗販売サーバ２０５ｂへ送信する（Ｓ３０１）。すると、店舗販売サーバ２０５ｂは、店舗ＩＤ、取引ＩＤ、通貨、金額の組（以後、「支払情報」と呼ぶ。）をパラメータとした送金許可のための承認ＵＲＬを、顧客スマートフォン２０２ａに返信する（Ｓ３０２）。つまり、実施形態３にかかる支払情報は、送金先アドレスを含まない。ここで、支払情報に含まれる取引ＩＤ、通貨及び金額は店舗処理サーバ２０５ｃとも共有され、後に店舗処理サーバ２０５ｃが内容を確認できる。顧客スマートフォン２０２ａのアクセス処理部２０２１ａは、受信した送金許可の承認ＵＲＬを開くと、ディープリンク機能（例えばｉＯＳの場合はＵｎｉｖｅｒｓａｌ Ｌｉｎｋ、Ａｎｄｒｏｉｄ（登録商標）の場合はＩｎｔｅｎｔ ＵＲＬ）により特定のアプリ２０２２が起動する。顧客スマートフォン２０２ａは、特定のアプリ２０２２が起動したら、まず認証トークンを送るとともにウォレットのリストを送金指示サーバ２０３ｂに要求する（Ｓ３０３）。これに応じて、送金指示サーバ２０３ｂの送金処理部２０３４ｂは、認証トークンの電子署名を確認して、以下の情報を顧客スマートフォン２０２ａの特定のアプリ２０２２に返信する（Ｓ３０４）。
・顧客ウォレット名のリスト
・各顧客ウォレットが扱うことのできる通貨のリスト
・通貨リストの各通貨から支払情報の通貨への換算レートのリスト

このとき、送金指示サーバ２０３ｂの送金処理部２０３４ｂは、図１４の鍵情報テーブル２０３２ａからユーザ名（顧客ＩＤ）に関連付けて鍵が登録してある顧客ウォレット名（取引所名）より、顧客ウォレット名のリストを作成する。アプリ２０２２は、送金指示サーバ２０３ｂから受信したウォレット名のリストを元に、ステップＳ２０３で受信した承認ＵＲＬのパラメータから支払情報を抽出し、図２０のような送金許可画面２０００を生成して表示する。ウォレット名はドロップダウンメニュー（取引所選択欄）２００３の選択肢となり、顧客２０１はその中から１つを選ぶことができる。ドロップダウンメニュー（通貨選択欄）２００７には、ドロップダウンメニュー２００３で選んだウォレットが扱うことのできる通貨が選べるようになっている。その他、送金許可画面２０００は、店舗名２００１、送金額２００２ａ、基軸通貨換算額２００２ｂ、中止ボタン２００４及び承認ボタン２００５を表示し、これらについては後述する。

ところで、デジタル通貨によっては送金時間に大きな差がある。そこで、送金指示サーバ２０３ｂの送金処理部２０３４ｂは過去の送金において、送金指示から着金までの時間を記録しておくことによって、通貨毎の送金時間の分布を求めることができる。そこで、送金処理部２０３４ｂは、図２１のように、店舗が希望する最長送金時間２０３５２を店舗ＩＤ毎に予め店舗情報テーブル２０３５ａとして保存する。そして、送金処理部２０３４ｂは、各顧客ウォレットが扱うことのできる通貨のリストを作成する際に、送金時間履歴テーブル２０３７を参照して、所定時間以内の送金が見込める通貨をウォレットごとに絞り込み、絞り込まれた通貨とウォレットの組のリスト（選択肢）をステップＳ３０４に含めて送信する。これにより、アプリ２０２２は、ドロップダウンメニュー２００７に表示する通貨の選択肢を絞り込むことができる。対象となる通貨が１つもないウォレットは、ドロップダウンメニュー２００３の候補から外す。例えば、ある通貨について過去１ヶ月の送金の９５％が保存された最長送金時間よりも短い送金時間で終わっていなければ、通貨の選択肢からその通貨を外す。尚、顧客側の希望によっても選択肢を絞り込むこともできることは言うまでもない。これにより、送金に予想外に時間がかかることをある程度防ぐことができる。

顧客２０１がドロップダウンメニュー２００７で通貨を選択すると、アプリ２０２２は、支払情報の通貨における金額を、選択された通貨に換算して換算金額として送金額２００２ａに表示する。この際の換算レートは他の実施形態で示した方法で求めても良いが、本実施形態では板情報の時系列情報を利用して求める方法を示す。具体的には、送金指示サーバ２０３ｂの送金処理部２０３４ｂは、取引所２０４ａから逐次板情報を取得し、時刻情報とともに各通貨対の板情報から最大買値と最小売値をデータベースに記録していく。そして、送金処理部２０３４ｂは、アプリ２０２２に顧客ウォレット名のリストを送るタイミング（Ｓ３０４）において、直近一定時間以内の最大買値及び最小売値の平均を求め、買値及び売値の換算レートとして併せてアプリ２０２２に送信する。このように換算レートを求めることにより、短時間での換算レートの大きな変動を抑えることができる。逆に、過去の板情報から、ディープラーニングなどの機械学習を用いて、近い将来の換算レートを予測することも可能である。このようにすることで、着金時に通貨交換する際の金額の変動を抑えることを狙う。

また、送金額２００２ａに表示する換算金額には、送金手数料を含めても良い。この場合、表示する支払金額は以下の式で求められる。
換算金額 ＝（支払情報の金額 × 換算レート ＋ 交換手数料）＋ 送金手数料
または
換算金額 ＝（支払情報の金額 ／ 換算レート ＋ 交換手数料）＋ 送金手数料

また、アプリ２０２２は、送金額２００２ａの換算金額に添えて、顧客２０１が指定する基軸通貨での金額を基軸通貨換算額２００２ｂに表示する。その場合の計算法は、実施形態１又は２と同じ方法をとることができる。あるいは例えば、換算金額を求めるときのように、換算レートとして過去買値及び売値の平均を使っても良い。いずれにしても、この基軸通貨での金額が最小となる通貨をドロップダウンメニュー２００７のデフォルト値とするのが、顧客２０１にとって都合が良い。

図２０の送金許可画面２０００で、顧客２０１が中止ボタン２００４を選択した場合は、アプリ２０２２は送金指示サーバ２０３ｂへその旨を通知し、送金処理部２０３４ｂは、その店舗ＩＤの取引ＩＤの支払いは中止されたものとしてデータベースに記録し、支払いプロセスはこれで中止される。仮に送金指示サーバ２０３ｂのホスト名がａｐｉ．ｓｅｎｄｅｒ．ｃｏｍの場合、店舗処理サーバ２０５ｃはｈｔｔｐｓ：／／ａｐｉ．ｓｅｎｄｅｒ．ｃｏｍ／ｖ１／ｐａｙｍｅｎｔｓ／｛店舗ＩＤ｝／｛取引ＩＤ｝にＧＥＴリクエストを発行することにより、データベースに記録されているその取引の詳細を知ることができる。ここでＵＲＬの｛店舗ＩＤ｝の部分は店舗ＩＤに、｛取引ＩＤ｝の部分は取引ＩＤに置き換える。取引の詳細情報には、通貨、金額及び状態が含まれ、店舗管理サーバ２０５ｃは内容が改竄されていないことも確認することができる。状態が「中止」となっていれば、支払いが中止になったことが分かる。

逆に、顧客２０１が図２０の送金許可画面２０００で承認ボタン２００５を選択した場合、アプリ２０２２は送金許可画面２０００上に表示又は選択された通貨、送金額及び取引所（顧客ウォレット）による送金が許可された旨を通知し（Ｓ３０５）、送金処理部２０３４ｂは、取引の状態を「許可」として記録する。店舗処理サーバ２０５ｃは、この状態を上記のＵＲＬより取得することができる。この間、送金指示サーバ２０３ｂの送金処理部２０３４ｂは、店舗処理サーバ２０５ｃへ支払情報を含めた送金許可通知を送信し（Ｓ３０６）、店舗処理サーバ２０５ｃは、支払情報の整合性を確認し、送金指示サーバ２０３ｂへ送金許可応答を送信する（Ｓ３０７）。そして、取引の状態を「許可」にした後、送金指示サーバ２０３ｂは、顧客ウォレット２０６に送金指示を発行する（Ｓ３０８）。その際に送るのは、図２０の送金許可画面２０００で選択した通貨、その換算金額（送金額）、後述する方法で生成された送金先アドレスである。また、送金処理部２０３４ｂは、顧客ウォレット２０６が指定する方法で、鍵情報テーブル２０３２ａからユーザ名に関連付けた鍵を用いて、送金指示の情報を電子署名などする。

ここで、送金先アドレスの生成法を説明する。つまり、送金指示サーバ２０３ｂは、所定のデジタル通貨の特性に応じて、当該デジタル通貨に対応するアドレスを前記送金先アドレスとして生成する。ここで、送金指示サーバ２０３ｂは、予め図２２のようなデータベースの送金先アドレス生成制御テーブル２０３８に各通貨ごとに（動的に送金先アドレスを生成するか否かを示す）属性が保持されているものとする。尚、送金先アドレス生成制御テーブル２０３８の代わりに、例えば、通貨ごとの上記属性がプログラムに書き込まれていても良い。例えば、ＢＴＣ（Ｂｉｔｃｏｉｎ）のように送金先アドレスの再利用が推奨されない通貨の場合、動的アドレス生成の列にｔｒｕｅが保持されている。逆に、ＸＲＰ（Ｒｉｐｐｌｅ）のように送金先アドレスの再利用が可能な通貨の場合、動的アドレス生成の列にｆａｌｓｅが保持されている。

また、送金指示サーバ２０３ｂは、送金先アドレス生成用の鍵などを保持するデータベースの送金先アドレス管理テーブル２０３９を記憶する。図２３は、送金先アドレス管理テーブル２０３９の例を示す。各行は店舗及び通貨の組毎に用意され、図２２の送金先アドレス生成制御テーブル２０３８における動的アドレス生成の列がｆａｌｓｅの通貨については、図２３の送金先アドレス管理テーブル２０３９の第３列は該当する店舗の送金先アドレスそのものを保持する。送金先アドレスそのものを保持する場合、送金指示の際に送る送金先アドレスにはこの値を利用する。逆に、図２２の送金先アドレス生成制御テーブル２０３８において動的アドレス生成の列がｔｒｕｅの通貨については、図２３の送金先アドレス管理テーブル２０３９の第３列は該当する店舗のアドレス生成用の鍵を保持する。アドレス生成用の鍵を保持する場合、送金指示サーバ２０３ｂの送金処理部２０３４ｂは、これを用いて送金先アドレスを生成する。例えば、ＢＴＣの場合、Ｄｅｔｅｒｍｉｎｉｓｔｉｃ Ｗａｌｌｅｔと呼ばれる機能で実現されている送金先アドレス生成法が定義されている（ＢＩＰ００３２など）。送金指示サーバ２０３ｂの送金処理部２０３４ｂは、データベースに保持されているアドレス生成用の鍵を用いて、アドレスを生成できる。そして、送金指示の際にこれを送金先アドレスとして利用できる。

図１９の説明に戻る。送金指示を受けた顧客ウォレット２０６の送金実行サービス２０６１は、台帳２０８に送金事実を書き込む（Ｓ３１１）。尚、顧客ウォレットによっては、二段階認証（電話やメールなど他の手段）によって顧客２０１に送金の再確認が行われる場合もある。例えば、ステップＳ３０８に応じて、送金実行サービス２０６１は、顧客スマートフォン２０２ａに対して、電話又はメール（つまり、アプリ２０２２以外が受信できる方法）により２ＦＡ（Two Factor Authentication）を行う（Ｓ３０９）。そして、顧客２０１が顧客スマートフォン２０２ａ（のアプリ２０２２以外の機能（電話番号によるＳＭＳ（Short Message Service）やメールアプリ等））に応答操作を行うことにより、顧客スマートフォン２０２ａは、送金実行サービス２０６１へ２ＦＡ許可を通知する（Ｓ３１０）。これにより、ウェブアプリのパスワードが漏洩した際にも不正な取引を防止することができる。尚、顧客２０１は、顧客スマートフォン２０２ａ以外に、通信可能な携帯電話端末、タブレット端末又はパソコン等の情報通信装置を所持していてもよい。その場合、送金実行サービス２０６１は、ステップＳ３０９において顧客２０１が所持する情報通信装置に対して２ＦＡを行い、ステップＳ３１０により当該情報通信装置からの２ＦＡ許可を受け付ける。

その後、送金指示サーバ２０３ｂは台帳２０８を監視し続け、送金状態を取引の状態に反映する。また、支払情報に指定した通貨と送金通貨が異なる可能性があるので、取引の詳細には送金通貨及び送金額が追加される。例えばＢＴＣのブロックチェーンの場合、送金事実を書き込んだ後に「承認」と呼ばれる処理が繰り返される。もし「承認」がｎ回行われた場合には、取引状態は「承認ｎ」とする。そして、ある一定回数Ｎを超える承認が繰り返されたら、取引状態を「承認Ｎ＋」とし、以後その送金の監視は辞める。そして、送金処理部２０３４ｂは、取引状態が「承認Ｎ＋」とされた取引ＩＤを含む着金通知を店舗処理サーバ２０５ｃへ送信する（Ｓ３１２）。

店舗処理サーバ２０５ｃは、受信した取引状態を確認し、所望の承認回数に達したら、例えば商品を発送するなどのプロセスを始めることができる。急を要するサービスの場合は、送金許可が下りた後にそのプロセスを始めることもできる。いつこのプロセスを始めるかは、店舗側の判断である。

以上、本実施形態では、送金先アドレスが動的に生成される例を示した。また、指定された通貨以外の通貨による送金にも対応した。送金先アドレス生成法としてＡｒｍｏｒｙ Ｄｅｔｅｒｍｉｎｉｓｔｉｃ Ｗａｌｌｅｔに採用されている方法を使えば、送金指示サーバでも送金先アドレス生成用に公開鍵のみを保管すれば良いことについても触れておく。

＜実施形態４＞
本実施形態４は、実施形態１、２又は３の変形例であり、任意の店舗あるいは個人が取引可能なシステムの例を示す。また、本実施形態４は、顧客が選択した通貨とは異なる通貨でも送金指示装置が換金を行った上で、送金指示を行うことができる。

本実施形態４にかかる送金指示装置におけるハードウェアの構成は、図１と同様であるものとする。よって、ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム１０２１には、本実施形態４にかかる送金指示装置の処理が実装されているものとする。

図２４は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図を示す。本実施形態では、預金管理を行うウォレット機能と通貨交換を行う取引所機能が、同じ顧客取引所２０４で行われるものとする。店舗サーバ２０５ｄは、電子商取引のＷＥＢサイトを提供するコンピュータ装置である。店舗サーバ２０５ｄは、記憶装置に承認ＵＲＬ２０５１及びＳＳＬ証明書２０５３（公開鍵証明書）を保存している。ここで、ＳＳＬ証明書２０５３は、信頼された認証局が店舗サーバ２０５ｄのサイト運営組織（及びＵＲＬ）の信頼性を証明した電子証明書である。尚、送金指示装置２０３ｄは、送金指示装置２０３と比べて送金処理部２０３４ｄを備える。送金指示装置２０３ｄの他の構成は、送金指示装置２０３、２０３ａ、送金指示サーバ２０３ｂ等と同等のものを用いることができる。よって、適宜、図示を省略している。

まず、顧客２０１が顧客コンピュータ２０２を利用して、店舗サーバ２０５ｄでの発注シーケンスに入る。顧客２０１は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部２０２１は、送金を開始するトリガーを店舗サーバ２０５ｄへ送信する（Ｓ４０１）。すると、店舗サーバ２０５ｄは、店舗サーバＵＲＬ（第１の宛先情報）、取引ＩＤ、通貨、金額の組に自身のＳＳＬ証明書２０５３の秘密鍵で電子署名した情報（以後、「支払情報」と呼ぶ。）をパラメータとした送金許可のための承認ＵＲＬを、顧客コンピュータ２０２に返信する（Ｓ４０２）。すると、顧客コンピュータ２０２のアクセス処理部２０２１は、新たなブラウザウィンドウを開いて、取得した承認ＵＲＬに対してＧＥＴリクエストを発行する（Ｓ４０３）。この時点で、顧客２０１が送金指示装置２０３ｄにログインしていなければ、上述したステップＳ２０４と同様のログインプロセスが行われる（Ｓ４０４、Ｓ４０５）。

ログインの後、送金指示装置２０３ｄの送金処理部２０３４ｄは、支払情報から店舗サーバＵＲＬを抽出し、そのＵＲＬからＳＳＬ証明書２０５３をダウンロードする（Ｓ４０６）。そして、送金処理部２０３４ｄは、ＳＳＬ証明書２０５３に記述されている公開鍵を用いて、抽出した支払情報が対応する秘密鍵で電子署名されていることを検証する。正しく電子署名されていることが確認されたら、送金処理部２０３４ｄは、図２５のようなウェブページ（送金許可ページ２５００、表示用ページ）を生成する。この場合、送金処理部２０３４ｄは、ダウンロードしたＳＳＬ証明書２０５３のＯｒｇａｎｉｚａｔｉｏｎ（Ｏ）フィールドから取得した組織名を店舗名２５０１として追加する。また、送金処理部２０３４ｄは、店舗サーバＵＲＬから抽出した文字列を店舗名２５０１の下のホスト名（第１の宛先情報に含まれる情報）として追加する。尚、ホスト名には、ＳＳＬ証明書２０５３のＣｏｍｍｏｎ Ｎａｍｅ（ＣＮ）フィールドから取得したもの（公開鍵証明書に含まれる情報）を用いても良い。送金処理部２０３４ｄは、店舗がＳＳＬ証明書によって検証されたことを示す場合にアイコン２５０８（公開鍵証明書により検証済みであることを示す情報）を追加する。送金処理部２０３４ｄは、顧客２０１が登録している取引所の内、支払情報に指定してある通貨での送金ができる取引所を選択肢として選択可能にドロップダウンメニュー（取引所選択欄）２５０３に設定する。送金処理部２０３４ｄは、ドロップダウンメニュー２５０３で選択された取引所が扱える通貨を選択肢として選択可能にドロップダウンメニュー（通貨選択欄）２５０７を設定する。

そして、送金処理部２０３４ｄは、生成した送金許可ページ２５００を送信詳細として顧客コンピュータ２０２へ送信する（Ｓ４０７）。アクセス処理部２０２１は、送金指示装置２０３ｄから受信した送金許可ページ２５００を画面に表示する。そして、顧客２０１が承認ボタン２５０５を選択すると、アクセス処理部２０２１は、送金許可ページ２５００上に表示された通貨、送金額及び取引所を含む送金許可を送金指示装置２０３ｄへ通知する（Ｓ４０８）。

ここで、本実施形態では送金対象の通貨を切り替えることができる。そのためには、顧客２０１が承認ボタン２５０５を押下する前に次のような操作を行うこととなる。例えば、顧客２０１がドロップダウンメニュー２５０７で通貨を選択すると、送金額２５０２ａに選択された通貨での換算金額が表示される。例えば、アクセス処理部２０２１は、選択された通貨を送金指示装置２０３ｄへ通知し、送金処理部２０３４ｄにより換算金額が更新された送金許可ページ２５００を取得し、表示してもよい。または、アクセス処理部２０２１は、選択された通貨に基づき換算金額を算出して、送金許可ページ２５００を更新してもよい。

また、顧客２０１が承認ボタン２５０５を選択した際のドロップダウンメニュー２５０７で選択された通貨が支払情報に含まれる通貨と同じ場合には、他の実施形態と同様に、送金処理部２０３４ｄは、その通貨で送金する。一方、顧客２０１が承認ボタン２５０５を選択した際のドロップダウンメニュー２５０７で選択された通貨が支払情報に含まれる通貨と異なる場合（通貨交換を伴う場合）には、送金処理部２０３４ｄは、選択した通貨を支払情報の通貨に交換してから送金する。この時、成行で注文することもできるが、換算金額以上の交換とならないように指し値で注文することも可能である。その時の指し値は換算金額を求める際に利用した換算レートである。特に指し値注文の場合、注文が成立しないことがあり得るので、注文を取り消す仕組みが必要である。

図２６に通貨交換を伴う通貨を選択した場合のフローチャート図を示す。顧客２０１が承認ボタン２５０５又は中止ボタン２５０４を選択したら、アクセス処理部２０２１は、ステップ２６０１でボタンの種類を特定し、上述した送金許可と共に、特定したボタンの種類を送金指示装置２０３ｄへ通知する。ボタンの種類が中止ボタン２５０４である場合、ステップ２６０８へと遷移し、送金処理部２０３４ｄは、直ちに支払いを中止する。一方、ボタンの種類が承認ボタン２５０５である場合、アクセス処理部２０２１は、ステップ２６０２で承認ボタンのラベルを「注文中」に変えてボタンを無効化する。そして、次のステップ２６０３で、送金処理部２０３４ｄは、顧客取引所２０４に注文を出す。つまり、送金処理部２０３４ｄは、顧客取引所２０４に対して通貨交換を要求する（図２４のＳ４１０）。具体的には、送金処理部２０３４ｄは、顧客取引所２０４に対して支払情報に含まれる通貨における送金額分を、選択された通貨に交換する指示を行う。その後ステップ２６０４で送金処理部２０３４ｄは、中止ボタン２５０４が選択されたかどうかを判断する。中止ボタン２５０４が選択されていなければステップ２６０６へと直接遷移する。中止ボタン２５０４が選択されていれば、ステップ２６０５で送金処理部２０３４ｄは、顧客取引所２０４に注文を取り消すように指示する。その後ステップ２６０６で送金処理部２０３４ｄは、注文の状態を顧客取引所２０４に問い合わせるなどして監視する。注文が完了していれば、顧客２０１が中止ボタン２５０４を選択したことがあったとしても、取引は許可されたものとして扱う（ステップ２６０７）。注文が中止になっていれば、取引が中止されたものとして扱う（ステップ２６０８）。そのいずれでもない場合には、ステップ２６０４に戻って中止ボタン２５０４が押されたかどうかの判定を繰り返す。

取引が中止したものとして扱われたら、ステップ２６０８にて、送金処理部２０３４ｄは、その店舗ＩＤの取引ＩＤの支払いは中止されたものとしてデータベースに記録し、支払いプロセスはこれで中止される。仮に送金指示装置２０３ｄのホスト名がａｐｉ．ｓｅｎｄｅｒ．ｃｏｍの場合、店舗サーバ２０５ｄはｈｔｔｐｓ：／／ａｐｉ．ｓｅｎｄｅｒ．ｃｏｍ／ｖ１／ｐａｙｍｅｎｔｓ／｛店舗ＩＤ｝／｛取引ＩＤ｝にＧＥＴリクエストを発行することにより、データベースに記録されているその取引の状態を知ることができる。ここでＵＲＬの｛店舗ＩＤ｝の部分は店舗ＩＤに、｛取引ＩＤ｝の部分は取引ＩＤに置き換える。状態が「中止」となっていれば、支払いが中止になったことが分かる。本実施形態では、これを店舗サーバ２０５ｄへの通知の一形態とする。

逆に、取引が完了したものとして扱われたら、ステップ２６０７にて、送金処理部２０３４ｄは、取引の状態を「許可」として記録する。店舗サーバ２０５ｄはこの状態を上記のＵＲＬより取得することができる。取引の状態を「許可」にした後、送金指示装置２０３ｄは、顧客取引所２０４に交換された金額を確認し、それを支払情報の送金先アドレスへ送金するよう、顧客取引所２０４に指示する（Ｓ４１１）。そして、顧客取引所２０４の送金実行サービス２０４１は、台帳２０８に送金事実を書き込む（Ｓ４１２）。その後、送金指示装置２０３ｄは、台帳２０８の監視を続け、取引の状態を更新する。尚、店舗サーバ２０５ｄは、送金指示装置２０３ｄに対してポーリングにより送金許可がされたか否かを確認するものとする。これにより、店舗サーバ２０５ｄが送金許可がされた旨を把握することができるため、図２４では、ステップＳ４０９として、送金許可通知として表現している。

以上、本実施形態では送金指示装置に店舗のアカウントが予め登録されていなくても、任意の店舗サーバが取引を開始できる送金指示装置を示した。ＳＳＬ証明書を利用することにより、店舗の信用が評価され、顧客が安心して支払いを済ませることができる。ここで、ＳＳＬ証明書の検証をなくせば、ウェブサーバを持たない任意の個人でもメールにＵＲＬを記載するなどして支払いを請求できるシステムになっている点にも触れておく。

＜実施形態５＞
本実施形態５は、実施形態１から４の変形例であり、ＵＲＬのリンクを開くことにより支払い手続きを開始する例を示す。

本実施形態５にかかる送金指示装置におけるハードウェアの構成は図１と同様であるものとする。よって、ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム１０２１には、本実施形態５にかかる送金指示装置の処理が実装されているものとする。

図２７は、本実施形態にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図である。店舗サーバ２０５ｅは、顧客コンピュータ２０２からの送金開始のトリガーその他の発注シーケンスに伴い、顧客２０１のメールアドレスを宛先とし、上述した承認ＵＲＬ２０５１を本文に記載した支払請求メールをメールサーバ２０９に対して送信する（Ｓ５００）。このとき、承認ＵＲＬ２０５１は、送金指示装置２０３ｅのウェブサイトのＵＲＬ（第２の宛先情報）である。そして、承認ＵＲＬ２０５１のＵＲＬパラメータは、店舗サーバ２０５ｅの１エンドポイント（第１の宛先情報）を指し示す。尚、支払請求メールは、店舗サーバ２０５ｅ以外の店員が操作する端末から送信されても構わない。

メールサーバ２０９は、一般的なメールサーバである。メールサーバ２０９は、店舗サーバ２０５ｅから支払請求メールを受信し、支払請求メール２０９１として記憶装置に記憶する。メールサーバ２０９は、顧客コンピュータ２０２のメールクライアント２０２３からのメール受信要求に応じて支払請求メール２０９１を顧客コンピュータ２０２へ送信する。

顧客コンピュータ２０２のメールクライアント２０２３は、起動時等にメールサーバ２０９に対してメール受信要求を送信し、メールサーバ２０９から承認ＵＲＬ２０５１を含む支払請求メール２０９１を受信する（Ｓ５０１）。顧客２０１が受信したメールに記載された承認ＵＲＬをクリック等すると、アクセス処理部２０２１は、承認ＵＲＬへのアクセスを行う（Ｓ５０２）。これにより、送金指示装置２０３ｅのウェブページが開く。ここで、送金指示装置２０３ｅの送金処理部２０３４ｅがウェブページを準備する時に、顧客２０１がログインしていなければ、上述したステップＳ２０４と同様に、送金処理部２０３４ｅは、ログインページを顧客コンピュータ２０２に送信する（Ｓ５０３）。顧客２０１がこのログインページにユーザ名とパスワードを入力すると、アクセス処理部２０２１はこれを送金指示装置２０３ｅへ、認証情報として送信する（Ｓ５０４）。送金指示装置２０３ｅの送金処理部２０３４ｅは、認証情報の受信に応じて、先ほどのステップＳ５０２でアクセスされた承認ＵＲＬのパラメータが指し示す店舗サーバ２０５ｅに対してＳＳＬ証明書を要求し、店舗サーバ２０５ｅからＳＳＬ証明書２０５３を取得する（Ｓ５０５）。送金処理部２０３４ｅは、取得したＳＳＬ証明書２０５３の内容を検証する。そして、送金処理部２０３４ｅは、承認ＵＲＬのパラメータとして指定されていたエンドポイントに対してＧＥＴリクエストを発行する。ＧＥＴリクエストを受けた店舗サーバ２０５ｅは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先を含む支払情報をｈｔｔｐｓによって返信する（Ｓ５０６）。ここでは、ｈｔｔｐｓを用いた例を示したが、支払情報を秘密にする必要がない場合には、支払情報がＳＳＬ証明書２０５３の秘密鍵によって電子署名されていれば、暗号化されていない通信方法でも改竄が防げるのは言うまでもない。また当然ながら、ｈｔｔｐ／ｈｔｔｐｓによらずとも他の通信方法によっても同様の効果が得られる。

支払情報は、ウェブページのようにＨＴＭＬ等の所定の構造化方式（構造化言語）で記述されていても良い。その場合、送金処理部２０３４ｅはＤＯＭ（Document Object Model）ツリーをパースして必要な情報を抽出する。例えば、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先がそれぞれ固有のｉｄを持った要素（エレメント）に含まれていれば、送金処理部２０３４ｅはそれらを探して抽出する。あるいは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先がそれぞれラベルと関連付けられてウェブページ内に配置してあれば、送金処理部２０３４ｅはまずそれらラベルを検索してから関連する情報を抽出すれば良い。

あるいは、支払情報は他の構造化方式であるｊｓｏｎ形式で記述されていても良い。この場合は情報にキーが付与されているので、送金処理部２０３４ｅの実装が簡単となる。逆に、支払情報をＨＴＭＬで記述する場合には、店舗サーバ２０５ｅを実装する際に、ＲＥＳＴ ＡＰＩの実装経験などがなくても良いという利点があり、店舗側にとって簡単となる。いずれにしても、支払情報をｈｔｔｐｓで送金指示装置２０３ｅに返すことにより、ウェブサーバに標準的に備わる方法によって、情報の改竄を防ぐことができ、開発効率を高めることができるのと同時に、新規開発に伴うバグによる脆弱性のリスクを軽減することができる。

支払情報を抽出した送金処理部２０３４ｅは、その内容を図２５のようなウェブページ（送金許可ページ２５００）に追加して、顧客コンピュータ２０２に送信する（Ｓ５０７）。ここで、アイコン２５０８はＳＳＬ証明書を検証したことを表すアイコンである。店舗名２５０１はＳＳＬ証明書のＯｒｇａｎｉｚａｔｉｏｎ（Ｏ）フィールドから取得したものであり、検証したＳＳＬ証明書がＥＶ（Ｅｘｔｅｎｄｅｄ Ｖａｌｉｄａｔｉｏｎ）証明書の場合にのみ表示する。その下のホスト名は、店舗サーバＵＲＬから抽出したものであり、ＳＳＬ証明書に含まれているドメイン名と合致する。

顧客２０１が支払情報を確認したら、承認ボタン２５０５を選択し、顧客コンピュータ２０２のアクセス処理部２０２１は、送金許可ページ２５００上に表示又は選択された通貨、送金額及び取引所による送金が許可された旨を送金許可として送金指示装置２０３ｅへ通知する（Ｓ５０８）。すると、送金指示装置２０３ｅの送金処理部２０３４ｅは、まず図２９のような情報を取引ログ２０３７１として送金履歴テーブル２０３７ａに追記する。取引ログ２０３７１には、ＳＳＬ証明書から取得したホスト名（cn）、送金通貨（currency）、送金額（amount）、送金先アドレス（destination）、並びに、記録時間（timestamp）及び支払留保フラグ（reserve）等が含まれる。また、送金指示装置２０３ｅは、さらに、送金先のアカウント２０３７２を管理してもよい。アカウント２０３７２は、店舗（店舗サーバ２０５ｅ）を一意に識別する情報であり、送金指示装置２０３ｅの送金先となるユーザ（店舗）を示す課金用のアカウントである。アカウント２０３７２には、例えば、取引ログ２０３７１内のホスト名（cn）、つまり、ＳＳＬ証明書内のホスト名を用いることができる。また、送金指示装置２０３ｅは、アカウント２０３７２を送金先として送金指示装置２０３ｅを介して送金指示サービスが使用された際に、アカウント２０３７２に課金される課金条件や後に説明する管理アドレスをさらに保持しているものとする。例えば、課金条件は、送金先として無料で利用可能な送金指示の上限回数であってもよい。

言い換えると、次のように言うことができる。すなわち、まず、送金処理部２０３４ｅは、ステップＳ５０５により店舗サーバ２０５ｅからＳＳＬ証明書２０５３を受信し、ステップＳ５０６によりＳＳＬ証明書２０５３の鍵により電子署名された支払情報を受信する。または、店舗サーバ２０５ｅと送金指示装置２０３ｅとの通信がｈｔｔｐｓ等により暗号化されていた場合には、支払情報に電子署名は不要となる。そして、送金処理部２０３４ｅは、ステップＳ５０８により顧客コンピュータ２０２から送金許可を受信した場合に、ＳＳＬ証明書の内容を用いて店舗サーバ２０５ｅの課金用のアカウントを生成し、生成したアカウントを送金履歴記憶部へ登録する。これにより、送金指示装置２０３ｅは、各店舗に対して事前のアカウント登録を要求せずに、送金発生時にアカウントを自動生成し、かつ、アカウントごとに課金状態を管理することができる。よって、送金指示装置２０３ｅは、自己の送金指示サービスの普及を、店舗を介して促進することができる。

ここで、送金処理部２０３４ｅは、ＳＳＬ証明書に含まれるホスト名を識別子としてアカウントを生成するとよい。ＳＳＬ証明書は、ホストごとに発行されるため、店舗の一意性を容易かつ確実に担保することができる。

また、送金処理部２０３４ｅは、送金履歴記憶部に登録されたアカウントを送金先とした送金指示の回数が所定の課金条件を満たした場合（例えば、上限回数を超えた場合）に、送金先への課金を開始することが望ましい。これにより、店舗は、送金指示装置２０３ｅのアカウントを事前に登録することなく、送金先として一定回数まで無料で送金指示サービスを利用できる。そして、送金指示装置２０３ｅは、無料での送金指示が一定回数を超えるアカウントに対して、課金することができ、課金を制御できる。

そして、取引ログ２０３７１に記録した後、送金処理部２０３４ｅは、店舗サーバ２０５ｅに支払いが承認されたことを通知する（Ｓ５０９）。具体的には、先の支払情報の通知先には送金許可通知の通知先ＵＲＬが含まれているので、送金処理部２０３４ｅは、通知先ＵＲＬに対してｈｔｔｐｓ ＰＯＳＴリクエストを発行する。通知先には明示的に取引ＩＤを送らなくても、ＵＲＬにその情報を組み入れることで、パラメータとして扱わずに同様の効果が得られる。

そして、送金処理部２０３４ｅは、顧客２０１の鍵を利用して送金通貨、送金額及び送金先アドレスを含めた送信指示を顧客取引所２０４へ送信する（Ｓ５１０）。ただし、ここでの送金先アドレスは取引ログ２０３７１に記録された内容に基づく。まず、送金処理部２０３４ｅは、取引ログ２０３７１を検索し、過去一定期間（例えば１ヶ月）の同じホスト名に対する取引回数が所定回数以下であるかどうかを確認する。所定回数以下であれば、送金処理部２０３４ｅは、店舗サーバ２０５ｅから取得した送金先アドレスを使用する。このとき、例えば、送金処理部２０３４ｅは、該当する取引ログ２０３７１の支払留保フラグ（“ｒｅｓｅｒｖｅ”キー）にｆａｌｓｅを設定する。逆に所定回数を超えていれば、送金処理部２０３４ｅは、送金指示装置２０３ｅが用意した送金先アドレス（送金額を留保するために、送金指示装置２０３ｅが管理する管理アドレス）を使用する。結果的に、取引回数が所定回数を超える場合には、支払いが特定のアドレスに一時的に留保されることになる。この時、例えば、送金処理部２０３４ｅは、該当する取引ログ２０３７１の支払留保フラグ（“ｒｅｓｅｒｖｅ”キー）にｔｒｕｅを設定する。

つまり少なくとも、送金処理部２０３４ｅは、前記生成したアカウントに、前記送金情報に含まれる前記送金先アドレスをさらに対応付けて前記送金履歴情報として前記送金履歴記憶部に登録し、前記送金指示の回数が前記課金条件を満たした場合に、前記送金先アドレスへの前記送金指示を行う代わりに、送金指示装置２０３ｅが管理する管理アドレスへ前記送金額を送金するための前記送金指示を行う。尚、送金処理部２０３４ｅは、送金履歴記憶部に登録された当該アカウントにおける送金履歴情報を数えることにより、送金指示の回数を算出してもよい。または、送金処理部２０３４ｅは、当該アカウントにおける送金履歴情報に対して所定の統計処理を行うことで、下記条件を満たすか否かを判定してもよい。

その後、顧客取引所２０４は送金指示に応じて台帳２０８に送金事実を書き込む（Ｓ５１１）。ここで、顧客２０１の鍵は、例えば図２８のようなＮｏＳＱＬのデータベースに予め保持されている。この例では、“ｕｓｅｒ”のキーに顧客の識別子、“ｅｘｃｈａｎｇｅ”に顧客取引所の識別子、“ａｐｉ＿ｋｅｙｓ”に顧客の鍵が保持されている。当然、他の形式のデータベースにも同様の情報を保持することができる。鍵の使用法は、顧客取引所が指定する方法に合わせるが、例えば、鍵のひとつで（送金通貨、送金額及び送金先アドレス）の組を電子署名して顧客取引所に送信するなどする。

顧客取引所２０４から応答として台帳上の識別子（Ｔｒａｎｓａｃｔｉｏｎ ＩＤ；ｔｘｉｄ）を得るので、送金指示の後、送金指示装置２０３ｅの送金処理部２０３４ｅは台帳２０８を監視し、着金があったと見なして良くなるまで待つ。先の支払情報の必要承認回数に指定された回数だけ台帳の承認が繰り返されたら、送金指示装置２０３ｅの送金処理部２０３４ｅは店舗サーバ２０５ｅに着金を通知する（Ｓ５１２）。そのために、支払情報の通知先に着金通知先ＵＲＬが含まれている場合、送金処理部２０３４ｅは、着金通知先ＵＲＬにｈｔｔｐｓ ＰＯＳＴリクエストを発行する。ボディ部には後に説明する引き出し用ＵＲＬを含める。ビットコイン（ＢＴＣ）などのブロックチェーン台帳においては、台帳の承認が繰り返されれば後で取り消される確率が減少するが、完全に０になるわけではない。そのために、店舗サーバ２０５ｅは、送金額や店舗の財務状況あるいは予想送金時間などに合わせて必要承認回数を、その都度調整するべきである。尚、店舗サーバ２０５ｅの代わりに送金処理部２０３４ｅが必要承認回数を調整してもよい。

すなわち、本実施形態にかかる着金通知は、次のような処理が可能であり、これらは上述した実施形態１から４にも適用可能である。まず、承認条件は、前記送金指示ごとに更新される。また、店舗サーバ２０５ｅは送金情報に含まれる前記送金額に基づいて前記承認条件を更新してもよい。また、店舗サーバ２０５ｅは、取引記録の承認履歴に基づいて前記承認条件を更新することが望ましい。また、前記承認条件は、前記送金先において前記送金情報に含まれる前記送金額に基づいて更新されたものであってもよい。また、前記承認条件は、当該送金先の資産情報に基づいて更新されたものであってもよい。

また、送金処理部２０３４ｅは、ＰＯＳＴリクエストのフォームデータとして、引き出し用ＵＲＬ（第３の宛先情報）を送信する。

すなわち、送金処理部２０３４ｅは、前記指定された所定のデジタル通貨に対応する取引記録が所定の承認条件を満たした場合に、前記送金先に対して前記送金額を引き出すための第３の宛先情報を含めて着金通知を行なう。

また、支払情報の通知先に着金通知先ＵＲＬの代わりにメールアドレスが指定されている場合には、送金処理部２０３４ｅは、着金通知文に加えて、引き出し用ＵＲＬをメール本文に記載して、指定メールアドレスにメールを送信する。尚、引き出し用ＵＲＬはホスト名毎に異なり、有効期限を設けることもできる。

店舗の従業員が店舗サーバ２０５ｅその他の端末からこの引き出し用ＵＲＬをウェブブラウザで開くと、図３０のような表を含んだウェブページが表示される。表の各行には通貨毎に留保されている金額が表示されている。店舗の従業員は、引き出しを希望する通貨の行の送金先アドレスの列に店舗の送金先アドレス（第２の送金先アドレス）を入力し、引き出しの列にあるボタンを選択する。すると、当該端末は、選択されたボタンの行に入力された送金先アドレスを送金指示装置２０３ｅへ送信し（つまり、引出要求を送信し）、送金指示装置２０３ｅの送金処理部２０３４ｅは、取引ログ２０３７１の中から、店舗のホスト名に対して、入力された送金先アドレスが過去に使用されたかどうかを確認する。送金先アドレスの使用が確認されたら、送金処理部２０３４ｅは、留保しているアドレスから入力された送金先アドレスに対して、留保されている金額から手数料を引いた通貨の金額（引出金額）を送金する。そして、送金処理部２０３４ｅは、図３１のような情報を、手数料込みの引き出し金額を負の数として取引ログ２０３７１に追記する。このようにすることで、取引ログのホスト名及び通貨毎に“ｒｅｓｅｒｖｅ”キーに対応する値がｔｒｕｅであるエントリーの“ａｍｏｕｎｔ”値の総和を取ることによって、留保残高が計算できるようになる。

すなわち、送金処理部２０３４ｅは、少なくとも、前記送金先からの引出要求に応じて、前記送金額から送金指示手数料を減額した額を引出金額として算出し、前記管理アドレスから前記送金先アドレスへ前記引出金額を送金するための前記送金指示を行う。このとき、送金処理部２０３４ｅは、前記送金先からの引出要求として第２の送金先アドレスの入力を受け付けた場合、前記送金履歴記憶部に登録された当該送金先のアカウントに対応付けられた前記送金先アドレスと前記第２の送金先アドレスとを照合し、前記送金先アドレスの１つと前記第２の送金先アドレスとが一致する場合、前記送金額から送金指示手数料を減額した額を引出金額として算出し、前記管理アドレスから前記第２の送金先アドレスへ前記引出金額を送金するための前記送金指示を行うことが望ましい。さらに、送金処理部２０３４ｅは、前記送金先から前記第３の宛先情報に対するアクセスの中で、前記引出要求を受け付けるとよい。これにより、送金指示装置２０３ｅは、課金を確実に行うことができる。また、店舗側も引出金額を容易かつ確実に取得することができる。これら引き出しにおける送金指示は、別の取引所やウォレットにおける送金実行サービスを利用してもよく、あるいは、送金指示装置２０３ｅに実装された送金実行サービスを利用してもよい。

以上、本実施形態では、ＵＲＬによる支払い請求の例を示した。この承認ＵＲＬはＵＲＬであるため、メールに記載するのみならず、ウェブページ上のリンクや印刷物のＱＲコード（登録商標）として活用するなどできる。支払情報を店舗のｈｔｔｐｓサーバが提供することにより、以下を含めた数多くのメリットが享受できる。
・支払情報等をＵＲＬパラメータに含めるのに比べ、短いＵＲＬにすることができ、メールや書類などに記載するのに都合が良い。
・短いＵＲＬであるにもかかわらず、その後取得される支払情報は暗号化されていることから、第三者が支払情報を偽造及び改竄することを防ぐことができ、顧客が意図しない宛先に送金してしまうことを防ぐことができる。利用形態としては例えば、所定回の送金手数料を無料にして、店舗サイトに本サービスのＵＲＬを表示してもらう。そして、当該店舗サイトのユーザ（顧客）がリンクをクリックすることで、本サービスのユーザ登録画面を自動的に表示できる。
・ＵＲＬ生成のために送金指示装置に取引を登録したり、店舗がアカウントを事前に作成したりする必要がなく、送金指示装置と店舗サーバの負担が軽い。例えば、ワンタイムのアカウントでも実現可能である。
・偽造及び改竄が難しく送金指示装置への負担も軽いので、承認ＵＲＬを不特定多数の人に公開して送金を依頼することができる。例えば、寄付金の送金先や小規模事業者又は個人が店舗側として自己の決済に利用する際にも適している。
・店舗サーバの実装者は、ウェブページに承認ＵＲＬを埋め込み、支払情報を記述したページを用意するだけでも、決済機能を実現できる。店舗サーバの実装は容易であり、ユーザはリンクをクリックするだけであるためユーザの利便性高い。よって、本サービスの普及を促進できる。

また、ＳＳＬ証明書内の情報を利用することにより、以下のメリットが享受できる。
・店舗の従業員がアカウントを作成する操作をしなくても、送金指示装置による課金が可能である。
・アカウントを作成するために、メールアドレスや名前やパスワードなどの個人情報を収集する必要がない。
・店舗のアカウントを手動で作成しなくても身元保証が可能なため、身元の確認のためのコストが不要である。

尚、本実施形態にかかる送金指示装置は、少なくとも送金先に関する公開鍵証明書に基づいて送金情報を受信するものであればよい。例えば、送金指示装置は、公開鍵証明書を用いた暗号化通信（例えば、ｈｔｔｐｓ）により送金情報を受信する場合や、送金先において公開鍵証明書の鍵により電子署名された送金情報を受信する場合が含まれる。

＜実施形態６＞
本実施形態６では、上述した各実施形態を送金実行サービスに適用する一例を示す。

本実施形態６にかかる送金実行装置におけるハードウェアの構成は図１と同等であるものとする。よって、ＦＰＧＡなど他の集積回路でも同様の構成で同じ機能が実現できる。但し、プログラム１０２１には、本実施形態６にかかる送金実行装置の処理が実装されているものとする。

図３２は、本実施形態６にかかる仮想通貨の送金に関する情報システムの構成、及び、送金許可シーケンスのブロック図を示す。他の実施形態と比較して、送金指示装置の機能と送金実行サービスの機能が、送金実行装置２０４ｂによって両方とも行われるところが、大きく異なる。尚、送金実行装置２０４ｂには、上述した鍵定義テーブル２０３１や鍵登録処理部２０３３が不要である。店舗サーバ２０５ｆは、電子商取引のＷＥＢサイトを提供するコンピュータ装置である。店舗サーバ２０５ｆは、記憶装置に送金実行装置２０４ｂのＵＲＬ２０５４及びＳＳＬ証明書２０５３を保存している。

まず、顧客２０１が顧客コンピュータ２０２を利用して、店舗サーバ２０５ｆでの発注シーケンスに入る。顧客２０１は、発注シーケンスの最後に購買を確定する操作を行う。これにより、アクセス処理部２０２１は、送金を開始するトリガーを店舗サーバ２０５ｆへ送信する（Ｓ６０１）。あるいは、実店舗の場合、店員が代わりに顧客コンピュータ２０２とは別のコンピュータでこれを行うこともできる。すると、店舗サーバ２０５ｆは、以下の情報をそれぞれＵＲＬパラメータとして、送金実行装置２０４ｂのＵＲＬ２０５４（第２の宛先情報）と組み合わせて新たなＵＲＬを作成する。本実施形態では、これを承認ＵＲＬと呼ぶことにする。
・支払情報を記載したウェブページのＵＲＬ（支払情報ＵＲＬ）（第１の宛先情報）
・今回の支払いを特定する識別子（取引ＩＤ）
ここで、支払情報ＵＲＬは店舗サーバ２０５ｆの１エンドポイントを指し示すこともあるが、他のサーバでも良い。本実施形態６では、店舗サーバ２０５ｆの１エンドポイントを指し示すものとして説明を続ける。

そして、店舗サーバ２０５ｆは、この承認ＵＲＬを、顧客コンピュータ２０２に送信する（Ｓ６０２）。また、顧客コンピュータ２０２にカメラがある場合にはＱＲコードによって承認ＵＲＬを読み込ませることもできる。さらに、赤外線通信、近距離無線通信など他の通信法でも同様である。すると、顧客コンピュータ２０２のアクセス処理部２０２１は、取得した承認ＵＲＬに対してＧＥＴリクエストを発行する（Ｓ６０３）。この時点で、顧客２０１が送金実行装置２０４ｂにログインしていなければ、上述したステップＳ２０４と同様のログインプロセスが行われる（Ｓ６０４、Ｓ６０５）。

ログインの後、送金実行装置２０４ｂの送金処理部２０４４は、承認ＵＲＬのＵＲＬパラメータから取得した支払情報ＵＲＬに対してＳＳＬ証明書を要求し、店舗サーバ２０５ｆからＳＳＬ証明書２０５３を取得する（Ｓ６０６）。送金処理部２０４４は、取得したＳＳＬ証明書の内容を検証する。そして、送金処理部２０４４は、支払情報ＵＲＬに対してＧＥＴリクエストを発行する。ＧＥＴリクエストを受けた店舗サーバ２０５ｆは、送金通貨、送金額、送金先アドレス、必要承認回数及び通知先を含む支払情報をｈｔｔｐｓによって返信する（Ｓ６０７）。

支払情報をＨＴＭＬで記述することを許すことにより、店舗サーバ２０５ｆは商品（サービス）を説明するウェブページを上記ＵＲＬパラメータとして提供するだけで良い。図３３は店舗サーバの商品ページ３３００の例である。「価格：」と表示される領域（価格表示欄３３１０）に商品の金額情報（税抜価格欄３３１１及び税込価格欄３３１２）が掲載されている。この部分をＨＴＭＬ形式で抜き取ると、例えば図３４のようになる。この例では、送金通貨、送金金額は、次のような手順で抽出できる。
１．送金処理部２０４４は、文字列「価格：」を含むｔｄエレメントをページ内から検索する。
２．送金処理部２０４４は、上記ｔｄエレメントが含まれるｔｒエレメントに属するエレメントの中から文字列「税込」を含むエレメントを検索する。
３．送金処理部２０４４は、上記「税込」を含むエレメント（税込価格欄３３１２）の文字列の中で数値を表す文字列を送金金額とする。（この例では0.00324。）
４．送金処理部２０４４は、上記「税込」を含むエレメントの文字列の中で、送金可能な通貨を表す文字列があれば、それを送金通貨とする。（この例ではＢＴＣ。）

また、この商品ページ３３００にはｉｄが"payment-attributes"であるエレメントがあり、その文字列は、送金先アドレスと通知先と必要承認回数を、送金実行装置２０４ｂの公開鍵で暗号化したものとなっている。送金先アドレスを暗号化することにより、顧客２０１が決められた手順を踏まずに送金先アドレスに送金することを防ぐことができる。また、通知先を暗号化することにより、不要なスパムメールなどを避けることができる。

支払情報を抽出した送金処理部２０４４は、その内容を図２５のようなウェブページ（送金許可ページ２５００）に追加して、顧客コンピュータ２０２に送信する（Ｓ６０８）。店舗名２５０１はＳＳＬ証明書のＯｒｇａｎｉｚａｔｉｏｎ（Ｏ）フィールドから取得したものである。その下のホスト名は、ＳＳＬ証明書に含まれているドメイン名である。

顧客２０１が支払情報を確認したら、承認ボタン２５０５を選択し、顧客コンピュータ２０２のアクセス処理部２０２１は、送金許可ページ２５００上に表示又は選択された通貨、送金額及び取引所による送金が許可された旨を送金許可として送金実行装置２０４ｂへ通知する（Ｓ６０９）。すると、送金実行装置２０４ｂの送金処理部２０４４は、店舗サーバ２０５ｆに支払いが承認されたことを通知する（Ｓ６１０）。具体的には、先の支払情報の通知先にメールアドレスが含まれているので、送金処理部２０４４は、このメールアドレスに対して支払いが承認された旨のメールを送る。メール本文には、先にＵＲＬパラメータとして取得した取引ＩＤを含めることで、メールの受け手はどの取引が承認されたのか認識できる。このメールは、送金実行装置２０４ｂの秘密鍵で電子署名または暗号化することにより、改竄を防止する。

そして、送金処理部２０４４は、送金通貨、送金額及び送金先アドレスを含めた送信指示を送金実行部２０４１ａに発行する（Ｓ６１１）。すると、送金実行部２０４１ａは送金指示に応じて台帳２０８に送金事実を書き込む（Ｓ６１２）。この時、ＢＴＣのように送金先アドレスを複数指定することができる通貨においては、送金実行部２０４１ａは、送金実行手数料を徴収する。具体的には、送金実行部２０４１ａは、店舗サーバ２０５ｆが指定した送金先アドレスに指定された金額から手数料を引いた分を送金し、送金実行装置２０４ｂが保持する別の送金先アドレスにも送金実行手数料分を送金する。台帳２０８に書き込む際に台帳上の識別子（Ｔｒａｎｓａｃｔｉｏｎ ＩＤ； ｔｘｉｄ）を得るので、送金指示の後、送金処理部２０４４は台帳２０８を監視し、着金があったと見なして良くなるまで待つ。先の必要承認回数に指定された回数だけ台帳の承認が繰り返されたら、送金処理部２０４４は先の通知先に指定されたメールアドレスに着金したことを知らせるメールを送信する（Ｓ６１３）。メール本文には取引ＩＤを含める。先の通知と同様、メールの暗号化や電子署名が可能である。

以上、本実施形態６では、送金実行と送金処理の両方をひとつの装置で行う例を示した。送金実行と送金処理が別々の装置で実装されていなくても、上述した実施形態１から５の利点を享受できることを示した。

＜その他の実施の形態＞
尚、上述した送金先アドレスや暗号化された文字列などは、例示に過ぎない。
また、上述した取引記録の承認は、プルーフオブワーク（ＰｏＷ）に限定されず、プルーフオブステーク（ＰｏＳ）、プルーフオブインポータンス（ＰｏＩ）、プルーフオブヒューマンワーク（ＰｏＨ）その他の方式を用いても構わない。

また、上述した各実施形態の送金指示装置又は送金実行装置は、以下のような構成を備えることができる。
すなわち、前記所定のデジタル通貨と他の通貨との換算レートに基づき前記送金額を当該他の通貨に換算した換算金額を算出する換算部をさらに備えることができる。
そして、前記ユーザの端末に表示させる表示用ページに、前記換算金額を追加する表示情報生成部をさらに備えることができる。
そして、前記表示情報生成部は、前記複数のデジタル通貨のそれぞれに対応する取引記録の承認履歴に基づき、前記複数の送金実行サービスのうち少なくとも一部を選択し、当該選択された送金実行サービスのリストを前記ユーザへの選択肢として前記表示用ページにさらに追加するとよい。
また、前記送金指示部は、前記ユーザにより前記他の通貨が選択された場合、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記選択された他の通貨へ交換させ、当該交換後の金額について前記送金指示を行うようにしてもよい。
また、前記特定部は、前記ユーザにより他の送金実行サービスが選択された場合、前記鍵情報記憶部の中から当該他の送金実行サービス及び前記ユーザに対応付けられた鍵を新たに特定し、前記送金指示部は、前記所定の送金実行サービスに代えて、前記新たに特定された鍵を用いて前記他の送金実行サービスに対して、前記換算金額の送金指示を行うとよい。
前記換算部は、前記所定の送金実行サービスによる送金手数料を加味して、前記換算金額を算出するとよい。
または、前記送金指示部は、前記送金額と比べて前記換算金額の方が前記ユーザの基軸通貨における費用総額が低い場合に、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金先アドレスへ前記送金指示を行うようにしてもよい。
また、前記換算部は、前記デジタル通貨の取引所から取得した前記換算レートを用いて、前記換算金額を算出するとよい。
また、前記換算部は、前記デジタル通貨の取引所から取得した板情報から前記換算レートを算出するとよい。
さらに、前記換算部は、前記板情報に含まれる通貨売買における取引量を加味して前記換算レートを算出するとよい。
また、前記他の通貨は、前記ユーザの基軸通貨であるとよい。
または、前記送金指示部は、前記送金額を前記所定のデジタル通貨から他の通貨に交換した場合の期待される処理時間が指定された時間以内の場合に、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金指示を行うようにしてもよい。

尚、上述した実施形態１、２，４及び５にかかる送金指示装置は、顧客コンピュータ２０２で実行されるＯＳ上で動作するアプリケーションとし、鍵定義テーブル２０３１等の各種テーブルを顧客コンピュータ２０２内の記憶装置に備えていても良い。その場合、顧客コンピュータ２０２と送金指示装置２０３等の間の通信は一部不要となる。

尚、上述の実施の形態では、ハードウェアの構成として説明したが、これに限定されるものではない。本開示は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。

１００ 送金指示装置
１０１ ＣＰＵ
１０２ プログラムメモリ
１０２１ プログラム
１０３ ＲＡＭ
１０４ ハードディスク
１０５ 通信部
１０６ バス
２０１ 顧客
２０２ 顧客コンピュータ
２０２ａ 顧客スマートフォン
２０２１ アクセス処理部
２０２１ａ アクセス処理部
２０２２ アプリ
２０２３ メールクライアント
２０３ 送金指示装置
２０３ａ 送金指示装置
２０３ｂ 送金指示サーバ
２０３ｄ 送金指示装置
２０３ｅ 送金指示装置
２０３１ 鍵定義テーブル
２０３１ａ 鍵定義テーブル
２０３１１ 取引所
２０３１２ 言語
２０３１３ 鍵種別
２０３１４ 鍵名称
２０３１５ 鍵個数
２０３２ 鍵情報テーブル
２０３２ａ 鍵情報テーブル
２０３２１ 顧客
２０３２２ 取引所
２０３２３ 鍵情報
２０３２３ａ 鍵情報
２０３２３１ 鍵種別
２０３２３２ 鍵
２０３３ 鍵登録処理部
２０３３ａ 鍵登録処理部
２０３３ｂ 鍵登録処理部
２０３４ 送金処理部
２０３４ａ 送金処理部
２０３４ｂ 送金処理部
２０３４ｄ 送金処理部
２０３４ｅ 送金処理部
２０３５ 店舗情報テーブル
２０３５ａ 店舗情報テーブル
２０３５１ 店舗公開鍵
２０３５２ 最長送金時間
２０３６１ アドレス生成鍵
２０３７ 送金時間履歴テーブル
２０３７ａ 送金履歴テーブル
２０３７１ 取引ログ
２０３７２ アカウント
２０３８ 送金先アドレス生成制御テーブル
２０３９ 送金先アドレス管理テーブル
２０４ 顧客取引所
２０４ａ 取引所
２０４ｂ 送金実行装置
２０４１ 送金実行サービス
２０４１ａ 送金実行部
２０４２ 鍵情報テーブル
２０４２１ 顧客
２０４２２ 鍵情報
２０４２２１ 鍵種別
２０４２２２ 鍵
２０４３ ＷＥＢシステム
２０４４ 送金処理部
２０５ 店舗サーバ
２０５ａ 店舗サーバ
２０５ｂ 店舗販売サーバ
２０５ｃ 店舗処理サーバ
２０５ｄ 店舗サーバ
２０５ｅ 店舗サーバ
２０５ｆ 店舗サーバ
２０５１ 承認ＵＲＬ
２０５２ 公開鍵
２０５３ ＳＳＬ証明書
２０５４ 送金実行装置ＵＲＬ
２０６ 顧客ウォレット
２０６１ 送金実行サービス
２０７ 店舗取引所
２０７ａ 店舗ウォレット
２０８ 台帳
２０９ メールサーバ
２０９１ 支払請求メール
３００ 鍵情報ページ
３１１ 鍵名称
３１２ 鍵
３２１ 鍵名称
３２２ 鍵
４００ 鍵登録ページ
４００ａ 鍵登録ページ
４０１ 取引所名称
４１１ 鍵名称
４１１ａ 鍵名称
４１２ 鍵入力欄
４２１ 鍵名称
４２１ａ 鍵名称
４２２ 鍵入力欄
１０００ 送金許可ページ
１０００ａ 送金許可ページ
１００１ 店舗名
１００２ 送金額
１００２ａ 送金額
１００２ｂ 基軸通貨換算額
１００２ｃ 基軸通貨選択欄
１００３ 取引所選択欄
１００４ 中止ボタン
１００５ 承認ボタン
１００６ ユーザ情報入力欄
２０００ 送金許可画面
２００１ 店舗名
２００２ａ 送金額
２００２ｂ 基軸通貨換算額
２００３ 取引所選択欄
２００４ 中止ボタン
２００５ 承認ボタン
２００７ 通貨選択欄
２５００ 送金許可ページ
２５０１ 店舗名
２５０２ａ 送金額
２５０２ｂ 基軸通貨換算額
２５０３ 取引所選択欄
２５０４ 中止ボタン
２５０５ 承認ボタン
２５０７ 通貨選択欄
２５０８ アイコン
３３００ 商品ページ
３３１０ 価格表示欄
３３１１ 税抜価格欄
３３１２ 税込価格欄

Claims (9)

1. 登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶する鍵情報記憶部と、
   所定の送金実行サービスと、当該所定の送金実行サービスを利用する前記ユーザとに基づいて、前記鍵情報記憶部の中から前記鍵情報を特定する特定部と、
   所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨及び前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、
   を備え、
   前記複数の鍵情報のそれぞれは、前記ユーザ及び前記送金実行サービスの組ごとに異なり、かつ、１以上の鍵を含み、
   前記鍵情報には、前記送金実行サービスにおいてユーザを一意に識別可能な情報が含まれる、
   送金指示装置。
2. 前記送金指示に基づく前記所定のデジタル通貨に対応する取引記録が所定の承認条件を満たした場合に、前記送金先へ着金通知を行う着金通知部をさらに備え、
   前記所定の承認条件は、前記取引記録が１以上の他の装置において承認されたか否かを判定するための承認条件であって、前記送金指示装置又は外部において更新されたものである
   請求項１に記載の送金指示装置。
3. 前記複数の送金実行サービスのそれぞれごとに、前記鍵情報に含まれる各鍵に関する定義を記憶する鍵定義記憶部と、
   前記鍵定義記憶部を用いて、前記ユーザの端末から当該ユーザが特定の送金実行サービスを利用するための鍵情報を受け付けて、当該受け付けた鍵情報に含まれる各鍵を前記ユーザ及び当該特定の送金実行サービスに対応付けて前記鍵情報記憶部へ登録する鍵登録部と、
   をさらに備える請求項１又は２に記載の送金指示装置。
4. 前記送金先から前記送金先アドレスを含めた前記送金情報を取得する送金情報取得部をさらに備える
   請求項１乃至３のいずれか１項に記載の送金指示装置。
5. 前記所定のデジタル通貨と他の通貨との換算レートに基づき前記送金額を当該他の通貨に換算した換算金額を算出する換算部をさらに備える
   請求項１乃至４のいずれか１項に記載の送金指示装置。
6. 前記送金指示部は、
   前記送金額を前記所定のデジタル通貨から他の通貨に交換した場合の期待される処理時間が指定された時間以内の場合に、前記所定の送金実行サービスに対して、前記送金額を前記所定のデジタル通貨から前記他の通貨へ交換させ、当該交換後の金額について前記送金指示を行う
   請求項１乃至５のいずれか１項に記載の送金指示装置。
7. コンピュータが、
   登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶した鍵情報記憶部の中から、所定の送金実行サービスと、当該所定の送金実行サービスを利用する前記ユーザとに基づいて、前記鍵情報を特定する特定ステップと、
   所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨及び前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示ステップと、
   を行い、
   前記複数の鍵情報のそれぞれは、前記ユーザ及び前記送金実行サービスの組ごとに異なり、かつ、１以上の鍵を含み、
   前記鍵情報には、前記送金実行サービスにおいてユーザを一意に識別可能な情報が含まれる、
   送金指示方法。
8. 登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶した鍵情報記憶部の中から、所定の送金実行サービスと、当該所定の送金実行サービスを利用する前記ユーザとに基づいて、前記鍵情報を特定する特定処理と、
   所定のデジタル通貨における送金額と送金先とが指定された送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨及び前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示処理と、
   をコンピュータに実行させ、
   前記複数の鍵情報のそれぞれは、前記ユーザ及び前記送金実行サービスの組ごとに異なり、かつ、１以上の鍵を含み、
   前記鍵情報には、前記送金実行サービスにおいてユーザを一意に識別可能な情報が含まれる、
   送金指示プログラム。
9. 登録済みの複数のユーザに対して複数のデジタル通貨を送金するサービスを提供する複数の送金実行サービスのそれぞれと、各ユーザと、各ユーザが各送金実行サービスを利用するための複数の鍵情報のそれぞれと、を対応付けて記憶する鍵情報記憶部を備えるサーバと、
   所定の送金実行サービスと、当該所定の送金実行サービスを利用する前記ユーザと、所定のデジタル通貨における送金額と送金先とが指定された送金情報とを前記サーバへ送信する送金要求部を備える端末と、を備え、
   前記サーバは、
   前記送金要求部から受信した前記所定の送金実行サービスと、前記ユーザとに基づいて、前記鍵情報記憶部の中から前記鍵情報を特定する特定部と、
   前記送金要求部から受信した前記送金情報に基づいて、前記特定された鍵情報を用いて前記所定の送金実行サービスに対して、前記指定された所定のデジタル通貨及び前記送金額について前記指定された送金先に対応する送金先アドレスへの送金指示を行う送金指示部と、
   を備え、
   前記複数の鍵情報のそれぞれは、前記ユーザ及び前記送金実行サービスの組ごとに異なり、かつ、１以上の鍵を含み、
   前記鍵情報には、前記送金実行サービスにおいてユーザを一意に識別可能な情報が含まれる、
   送金指示システム。

Images