JP7156888B2 - 決済処理方法 - Google Patents

Description

本発明は決済処理方法に関し、特に、決済用コードを用いた決済処理を行う技術に関する。

紙幣や硬貨等の実物の貨幣を介さず、電子的に決済を行う電子決済が普及してきている。電子決済においては、決済の前提として商品やサービスの対価を支払うユーザの認証が行われる場合があるが、このユーザ認証時に、画像化されたコードをカメラ等のコードリーダで読み取ることによって認証処理を実現する仕組みが普及しつつある（例えば、特許文献１）。

特表２０１７－５０３２５３号公報

特許文献１に記載されている技術は、バーコードやＱＲコード（登録商標）に埋め込まれた情報に基づいて認証処理を実行する。しかしながら、コードに埋め込むための情報の構造や符号化に関する規格が乱立しつつあり、種別の異なる規格では互換性がないという状況が生じている。このため、上記のような電子決済の利用を望むユーザにとっては、どの規格の電子決済を利用すればよいか判断に迷い、結果として電子決済の普及の妨げになりかねない。

本発明はこれらの点に鑑みてなされたものであり、ユーザが電子決済の種別を意識せずに決済を行えるようにする技術を提供することを目的とする。

本発明の第１の態様は、決済処理方法である。この方法は、第１ユーザが利用する第１ユーザ端末が、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバに、決済用トークンの取得要求を送信するステップと、前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられた決済用トークンを前記第１ユーザ端末に送信するステップと、前記第１ユーザ端末が、前記決済用トークンに基づいて生成した決済用コードを表示するステップと、前記第１決済事業者とは異なる第２決済事業者が管理する第２決済サーバに登録をしている第２ユーザ端末が、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む決済情報を仲介サーバに送信するステップと、前記仲介サーバが、前記決済用トークンに関連付けられている前記第１事業者識別子を取得するステップと、前記仲介サーバが、前記決済用トークンを生成した前記第１決済サーバに、前記決済用トークンを送信するステップと、前記第１決済サーバが、前記決済用トークンに基づいて前記第１ユーザのユーザ認証をするステップと、を含む。

本発明の第２の態様も、決済処理方法である。この方法は、第１ユーザが利用する第１ユーザ端末が、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバに、決済用トークンの取得要求を送信するステップと、前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを前記第１ユーザ端末に送信するステップと、前記第１ユーザ端末が、前記決済用トークンに基づいて生成した決済用コードを表示するステップと、第２ユーザ端末が、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む決済情報を前記第２ユーザ端末を利用する第２ユーザが利用可能な第２決済事業者が管理する第２決済サーバに送信するステップと、前記第２決済サーバが、前記第２ユーザ端末から受信した前記決済情報を仲介サーバに転送するステップと、前記仲介サーバが、前記第２決済サーバから受信した前記決済情報に含まれる前記決済用トークンから、前記第１事業者識別子を抽出するステップと、前記仲介サーバが、前記決済情報を前記第１事業者識別子で特定される前記第１決済事業者が管理する前記第１決済サーバに、前記決済用トークンを送信するステップと、前記第１決済サーバが、前記決済用トークンに基づいて前記第１ユーザの認証をするステップと、を含む。

本発明の第３の態様も、決済処理方法である。この方法は、第１ユーザが利用する第１ユーザ端末が、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバに、決済用トークンの取得要求を送信するステップと、前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられた決済用トークンを前記第１決済サーバが用いる暗号鍵である第１暗号鍵を用いて暗号化して前記第１ユーザ端末に送信するステップと、前記第１ユーザ端末が、前記第１決済サーバから受信した暗号化された前記決済用トークンを、前記第１暗号鍵を用いて復号するステップと、前記第１ユーザ端末が、前記決済用トークンに基づいて生成した決済用コードを表示するステップと、前記第１決済事業者とは異なる第２決済事業者が管理する第２決済サーバに登録をしている第２ユーザ端末が、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む決済情報を、前記第１決済サーバが用いる暗号鍵である第２暗号鍵を用いて暗号化して仲介サーバに送信するステップと、前記仲介サーバが、前記第２ユーザ端末から受信した暗号化されている前記決済情報を、前記第２暗号鍵を用いて復号するステップと、前記仲介サーバが、復号して得られた決済用情報に含まれる前記決済用トークンに関連付けられている前記第１事業者識別子を取得するステップと、前記仲介サーバが、復号した前記決済情報に含まれる決済用トークンを前記第１暗号鍵で暗号化するステップと、前記仲介サーバが、前記決済用トークンを生成した前記第１決済サーバに、暗号化した前記決済用トークンを送信するステップと、前記第１決済サーバが、前記仲介サーバから取得した暗号化された決済用トークンを前記第１暗号鍵を用いて復号するステップと、前記第１決済サーバが、復号した前記決済用トークンに基づいて前記第１ユーザのユーザ認証をするステップと、を含む。

前記決済処理方法は、前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して前記仲介サーバに送信するステップと、前記仲介サーバが、前記第１決済サーバから受信した決済用トークンと、前記第２ユーザ端末から受信した決済用トークンとが不一致の場合、決済処理を中止するステップとをさらに含んでもよい。

本発明の第４の態様も、決済処理方法である。この方法は、第１ユーザが利用する第１ユーザ端末が、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバを利用して決済をするための決済用トークンの取得要求を、仲介サーバに送信するステップと、前記仲介サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを前記第１ユーザ端末に送信するステップと、前記第１ユーザ端末が、前記決済用トークンに基づいて生成した決済用コードを表示するステップと、第２ユーザ端末が、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む決済情報を仲介サーバに送信するステップと、前記仲介サーバが、前記決済用トークンに関連付けられている前記第１事業者識別子を取得するステップと、前記仲介サーバが、前記決済用トークンを生成した前記第１決済サーバに、前記決済用トークンを送信するステップと、前記第１決済サーバが、前記決済用トークンに基づいて前記第１ユーザの認証をするステップと、を含む。

本発明の第５の態様も、決済処理方法である。この方法は、第１ユーザが利用する第１ユーザ端末から、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバを利用して決済をするための決済用トークンの取得要求を受信するステップと、前記第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを前記第１ユーザ端末に送信するステップと、前記決済用トークンに基づいて前記第１ユーザ端末が生成した決済用コードを読み取った第２ユーザ端末から、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む決済情報を受信するステップと、前記決済用トークンに対応する決済事業者の決済サーバである第１決済サーバに前記決済用トークンを送信するステップと、前記第１決済サーバから前記決済用トークンに基づく決済承認に関する情報を受信するステップと、を含む。

本発明によれば、ユーザが電子決済の種別を意識せずに決済を行えるようにする技術を提供することができる。

第１の実施の形態に係る決済処理システムの事前登録処理を説明するための図である。 第１の実施の形態に係る決済処理システムが備える各装置の機能構成を模式的に示す図である。 第１の実施の形態に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態に係る記憶部が記憶する決済用トークンデータベースのデータ構造を模式的に示す図である。 第１の実施の形態の第１の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態の第２の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態の第３の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態の第４の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態の第５の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第１の実施の形態の第６の変形例に係る決済処理システムが実行する決済処理を説明するための図である。 第２の実施の形態に係る決済処理システムが備える各装置の機能構成を模式的に示す図である。 第２の実施の形態に係る決済処理システムが実行する決済処理を説明するための図である。

［第１の実施の形態］
＜第１の実施の形態の概要＞
第１の実施の形態の概要を述べる。第１の実施の形態に係る仲介サーバは、ＱＲコード等を利用した電子決済の仲介をする装置である。第１の実施の形態に係る仲介サーバは、電子決済をしようとするユーザが用いるユーザ端末と、ユーザが利用する店舗に設置されている店舗端末と、ユーザが利用可能な決済事業者の決済サーバと、店舗が利用可能な決済事業者の決済サーバとの４者の間における情報のやり取りを仲介する。

ここで、コードを利用した電子決済の技術は、店舗を利用するユーザのユーザ端末に表示されたコードを店舗端末が読み取って決済サーバに送信する方式（以下、「ユーザ提示方式」と記載する。）と、店舗端末に表示されたコードをユーザ端末が読み取って決済サーバに送信する方式（以下、「店舗提示方式」と記載する。）との大きく分けて２種類の方式が存在する。

以下、第１の実施の形態において、コードを表示する端末のユーザを「第１ユーザ」、第１ユーザが利用する端末を「第１ユーザ端末」、第１ユーザが契約している決済事業者を「第１決済事業者」、第１決済事業者が管理している決済サーバを「第１決済サーバ」と記載する。また、第１ユーザ端末が表示するコードを読み取る端末を「第２ユーザ端末」、第２ユーザ端末を利用するユーザを「第２ユーザ」、第２ユーザが契約している決済事業者を「第２決済事業者」、第２決済事業者が管理している決済サーバを「第２決済サーバ」と記載する。

したがって、ユーザ提示方式の決済システムでは、店舗を利用するユーザのユーザ端末が第１ユーザ端末となり、ユーザが利用している店舗に設置されている店舗端末が第２ユーザ端末となる。この場合、第２ユーザは店舗の経営者等になる。また、店舗提示方式の決済システムでは、店舗を利用するユーザのユーザ端末が第２ユーザ端末となり、ユーザが利用している店舗に設置されている店舗端末が第１ユーザ端末となる。

一般に、ある電子決済の決済事業者が決済のために各ユーザ端末とやり取りする情報は、各決済事業者が個別に用いる暗号鍵で暗号化される。したがって、第１決済事業者と第２決済事業者とが異なる場合、第１決済事業者との通信のために第１事業者が用いる暗号鍵で暗号化された決済情報を第２決済事業者が受信しても、第２決済事業者は決済処理をすることは通常できない。

第１の実施の形態に係る仲介サーバは、あらかじめ複数の決済事業者から各決済事業者が用いる暗号鍵を取得し、各社が通信時に用いる暗号化された情報を読み取ることができるように構成されている。このため、第１の実施の形態に係る仲介サーバは、第１ユーザ端末が送信した第１決済サーバ用のトークンを含む決済情報を受信してその内容を読み取り、第２決済サーバに決済情報を転送することができる。

このように、第１の実施の形態に係る仲介サーバは、電子決済をしようとするユーザが契約している電子決済の決済事業者と、ユーザが利用する店舗が契約している決済事業者とが異なっても、両者の間を仲介して決済処理を実現させることができる。したがって、第１の実施の形態に係る仲介サーバは、ユーザが電子決済の種別を意識せずに決済を行えるようにすることができる。

＜事前登録処理＞
図１は、第１の実施の形態に係る決済処理システムＳの事前登録処理を説明するための図である。なお、以下では説明の便宜のため、決済処理システムＳがユーザ提示方式の決済を処理するシステムであることを前提として主に説明する。

図１に示すように、第１の実施の形態に係る決済処理システムＳは、第１ユーザＵ１が利用する端末である第１ユーザ端末Ｔ１、第１ユーザＵ１が利用する店舗Ｒに設置されている端末である第２ユーザ端末Ｔ２、第１ユーザＵ１が契約している決済事業者が管理する決済サーバＱである第１決済サーバＱ１、店舗Ｒの経営者である第２ユーザＵ２が契約している決済事業者の決済サーバＱである第２決済サーバＱ２、及び仲介サーバＭを含んでいる。

以下、図１を参照して第１の実施の形態に係る決済処理システムＳの事前登録処理を（１）から（５）の順序で説明するが、この数字は図１における（１）から（５）と対応する。

（１）第２ユーザＵ２は、第２決済事業者が提供する電子決済サービスを利用するために、第２決済事業者が管理する第２決済サーバＱ２にユーザ登録を行う。これにより、第２ユーザＵ２は、第２決済サーバＱ２が管理している電子決済用の口座を開設する。
（２）第２ユーザＵ２は、仲介サーバＭにユーザ登録を行う。

（３）第２決済事業者は仲介サーバＭに事業者登録を行い、第２決済事業者が通信時に情報を暗号化するための暗号鍵を仲介サーバＭに提供する。
（４）第１決済事業者は仲介サーバＭに事業者登録を行い、第１決済事業者が通信時に情報を暗号化するための暗号鍵を仲介サーバＭに提供する。
（５）第１ユーザＵ１は、第１決済事業者が提供する電子決済サービスを利用するために、第１決済事業者が管理する第１決済サーバＱ１にユーザ登録を行う。これにより、第１ユーザＵ１は、第１決済サーバＱ１が管理している電子決済用の口座を開設する。

ここで「決済用トークン」は、第１ユーザＵ１が第１決済サーバＱ１で決済しようとするときに、第１決済サーバＱ１が第１ユーザＵ１の第１ユーザ端末Ｔ１に送信するランダムな文字列である。第１決済サーバＱ１は、各第１ユーザＵ１に送信する決済用トークンが重複しないように各決済用トークンを生成する。第１決済サーバＱ１は、第１ユーザ端末Ｔ１からの要求があったときに決済用トークンを生成して第１ユーザＵ１のユーザ識別子と紐づけて記憶部に格納する。

ここで、第１決済サーバＱ１は、発行する各決済用トークンに有効期限を定める。第１決済サーバＱ１は、有効期限が切れた決済用トークンを、記憶部から削除する。有効期限は、決済に求められる安全性等を考慮して定めればよいが、例えば数分から数十分である。

第１ユーザ端末Ｔ１が決済用トークンに基づいて決済用コード（例えば、ＱＲコードやバーコード等の画像）を生成し、第１ユーザ端末Ｔ１の表示部に表示する。この決済用コードを第２ユーザ端末Ｔ２が読み取って決済金額とともに第１決済サーバＱ１に送信することができれば、第１決済サーバＱ１は受信した決済用トークンに紐付けられているユーザ識別子から第１ユーザＵ１を特定することができる。第１ユーザＵ１を特定できれば、第１決済サーバＱ１は、第２ユーザ端末Ｔ２から受信した決済金額で第１ユーザＵ１の口座から決済をすることができる。

ところが、第２ユーザＵ２が第１決済事業者の電子決済サービスを利用するためのユーザ登録を行っていない場合、第１ユーザ端末Ｔ１が表示部に表示した決済用コードを第２ユーザ端末Ｔ２が読み取っても、決済情報を第１決済サーバＱ１に送信する術がない。

また、一般に、ユーザ端末Ｔと決済サーバＱとの間では暗号化された情報がやり取りされるが、各決済サーバＱが情報の暗号化に用いる暗号鍵は互いに異なる。したがって、第２ユーザＵ２が第１決済事業者の電子決済サービスを利用するための加盟店登録を行っていない場合、第１ユーザ端末Ｔ１が表示部に表示した決済用コードを第２ユーザ端末Ｔ２が読み取っても、第２ユーザ端末Ｔ２は第１決済サーバＱ１が用いる暗号鍵を持っていないため、第１決済サーバＱ１で解読できるように決済用コードを暗号化することができない。

そこで、仲介サーバＭは、第２ユーザ端末Ｔ２と第１決済サーバＱ１との間の情報の送受信を仲介し、第２ユーザ端末Ｔ２から受信した情報を第１決済サーバＱ１が扱える情報に変換して第１決済サーバＱ１に送信する。これにより、仲介サーバＭは、第１ユーザＵ１が契約している電子決済の種別と第２ユーザＵ２が契約している電子決済の種別とが異なっても、電子決済を実現させることができる。

＜第１の実施の形態に係る決済処理システムＳの機能構成＞
図２は、第１の実施の形態に係る決済処理システムＳが備える各装置の機能構成を模式的に示す図である。決済処理システムＳは、第１ユーザ端末Ｔ１、第２ユーザ端末Ｔ２、仲介サーバＭ、第１決済サーバＱ１、及び第２決済サーバＱ２を備え、これらは通信ネットワークＮを介して通信可能な態様で接続している。第１ユーザ端末Ｔ１は、記憶部１０と制御部１１とを備える。第２ユーザ端末Ｔ２も、記憶部２０と制御部２１とを備える。同様に、仲介サーバＭは記憶部３０と制御部３１とを備え、第１決済サーバＱ１は記憶部４０と制御部４１とを備え、第２決済サーバＱ２は記憶部５０と制御部５１とを備える。

図２において、矢印は主なデータの流れを示しており、図２に示していないデータの流れがあってもよい。図２において、各機能ブロックはハードウェア（装置）単位の構成ではなく、機能単位の構成を示している。各機能ブロック間のデータの授受は、データバス、ネットワーク、可搬記憶媒体等、任意の手段を介して行われてもよい。

記憶部１０は、第１ユーザ端末Ｔ１を実現するコンピュータのＢＩＯＳ（Basic Input Output System）等を格納するＲＯＭ（Read Only Memory）や第１ユーザ端末Ｔ１の作業領域となるＲＡＭ（Random Access Memory）、ＯＳ（Operating System）やアプリケーションプログラム、当該アプリケーションプログラムの実行時に参照される種々の情報を格納するＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の大容量記憶装置である。

制御部１１は、第１ユーザ端末Ｔ１のＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等のプロセッサであり、記憶部１０に記憶されたプログラムを実行することによってトークン要求部１１０及び表示制御部１１１として機能する。

同様に、記憶部２０は、第２ユーザ端末Ｔ２を実現するコンピュータのＢＩＯＳ等を格納するＲＯＭや第２ユーザ端末Ｔ２の作業領域となるＲＡＭ、ＯＳやアプリケーションプログラム、当該アプリケーションプログラムの実行時に参照される種々の情報を格納するＨＤＤやＳＳＤ等の大容量記憶装置である。制御部２１は、第２ユーザ端末Ｔ２のＣＰＵやＧＰＵ等のプロセッサであり、記憶部２０に記憶されたプログラムを実行することによってコード読取部２１０及び決済情報送信部２１１として機能する。

記憶部３０は、仲介サーバＭを実現するコンピュータのＢＩＯＳ等を格納するＲＯＭや仲介サーバＭの作業領域となるＲＡＭ、ＯＳやアプリケーションプログラム、当該アプリケーションプログラムの実行時に参照される種々の情報を格納するＨＤＤやＳＳＤ等の大容量記憶装置である。制御部３１は、仲介サーバＭのＣＰＵやＧＰＵ等のプロセッサであり、記憶部３０に記憶されたプログラムを実行することによって決済情報受信部３１０、決済要求部３１１、及び通知部３１２として機能する。

記憶部４０は、第１決済サーバＱ１を実現するコンピュータのＢＩＯＳ等を格納するＲＯＭや仲介サーバＭの作業領域となるＲＡＭ、ＯＳやアプリケーションプログラム、当該アプリケーションプログラムの実行時に参照される種々の情報を格納するＨＤＤやＳＳＤ等の大容量記憶装置である。制御部４１は、第１決済サーバＱ１のＣＰＵやＧＰＵ等のプロセッサであり、記憶部４０に記憶されたプログラムを実行することによってトークン送信部４１０、決済管理部４１１、及び精算管理部４１２として機能する。

記憶部５０は、第２決済サーバＱ２を実現するコンピュータのＢＩＯＳ等を格納するＲＯＭや仲介サーバＭの作業領域となるＲＡＭ、ＯＳやアプリケーションプログラム、当該アプリケーションプログラムの実行時に参照される種々の情報を格納するＨＤＤやＳＳＤ等の大容量記憶装置である。制御部５１は、第２決済サーバＱ２のＣＰＵやＧＰＵ等のプロセッサであり、記憶部５０に記憶されたプログラムを実行することによってトークン送信部５１０、決済管理部５１１、及び精算管理部５１２として機能する。

図３は、第１の実施の形態に係る決済処理システムＳが実行する決済処理を説明するための図である。以下、図２及び図３を参照しながら、第１の実施の形態に係る決済処理システムＳが実行する決済処理を（１）から（１３）の順序で説明するが、この数字は図３における（１）から（１３）と対応する。

（１）第１ユーザ端末Ｔ１のトークン要求部１１０は、第１ユーザＵ１が利用可能な第１決済事業者が管理する第１決済サーバＱ１に、決済用トークンの取得要求を送信する。
（２）第１決済サーバＱ１のトークン送信部４１０は、第１ユーザ端末Ｔ１から取得した取得要求に応答して、第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して第１ユーザ端末Ｔ１に送信する。トークン送信部４１０は、第１ユーザ端末Ｔ１に送信した決済用トークンを、第１ユーザＵ１を特定するための第１ユーザ識別子と紐づけて記憶部４０に記憶させる。なお、第１決済サーバＱ１は、第１ユーザ端末Ｔ１のトークン要求部１１０からトークンの要求があったとき、又はトークンの要求に先立って、第１ユーザ端末Ｔ１を用いるユーザのユーザ認証を実行する。このユーザ認証が成功することを条件として、第１決済サーバＱ１のトークン送信部４１０は、決済用トークンを生成する。

図４は、第１の実施の形態に係る記憶部４０が記憶する決済用トークンデータベースのデータ構造を模式的に示す図である。決済用トークンデータベースは、各ユーザ識別子、決済用トークン、及び有効期限を紐づけて格納している。

図４に示す決済用トークンデータベースは、第１決済サーバＱ１の記憶部４０に格納されている。図４に示すように、決済用トークンは基本的にランダムな文字列であるが先頭の３つの文字はすべて共通の「００１」という文字列である。この文字列は第１事業者識別子に対応する。このように、図４に示す例では、決済用トークンに事業者識別子を含める形で決済用トークンと事業者識別子とが関連付けられている。これにより、決済用トークンを取得した装置は、どの決済サーバＱが扱う決済用トークンであるかを判別することができる。

図３の説明に戻る。
（３）第１ユーザ端末Ｔ１の表示制御部１１１は、第１決済サーバＱ１から受信した決済用トークンに基づいて生成した決済用コードを、第１ユーザ端末Ｔ１の表示部に表示させる。
（４）第２ユーザ端末Ｔ２のコード読取部２１０は、第１ユーザ端末Ｔ１の表示部に表示された決済用コードを読み取って決済用トークンを取得する。

（５）第２ユーザ端末Ｔ２の決済情報送信部２１１は、コード読取部２１０が読み取って取得した決済用トークンと、第２ユーザ端末Ｔ２を利用する第２ユーザＵ２を特定するための第２ユーザ識別子と、第２ユーザＵ２が利用可能な第２決済事業者を特定するための第２事業者識別子と、決済金額と、を含む決済情報を仲介サーバＭに送信する。

（６）仲介サーバＭの決済情報受信部３１０は、第２ユーザ端末Ｔ２から決済情報を受信する。
（７）仲介サーバＭの決済要求部３１１は、決済情報受信部３１０が受信した決済情報に含まれる決済用トークンから取得した第１事業者識別子で特定される第１決済事業者の第１決済サーバＱ１に、決済用トークンと決済金額とを送信する。

（８）第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致するか否かを判定することにより、ユーザ認証を実行する。第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致することを条件として、仲介サーバＭから受信した決済用トークンに紐付けられている第１ユーザ識別子を記憶部４０から取得し、第１ユーザ識別子で特定される第１ユーザＵ１の口座の残金で決済金額を決済できるか否かを判定し、結果を決済承認に関する情報として仲介サーバＭに通知する。

（９）仲介サーバＭの決済要求部３１１は、第１ユーザＵ１の口座の残金で決済金額を決済できる場合、第２決済事業者が管理する第２決済サーバＱ２に、第２ユーザ識別子と決済情報に含まれる決済金額の決済要求とを送信する。なお、第１ユーザＵ１の口座の残金で決済金額を決済できない場合、決済要求部３１１は決済処理を中止する。

（１０）第２決済サーバＱ２の決済管理部５１１は、仲介サーバＭの決済要求部３１１から受信した第２ユーザ識別子に基づくユーザ認証が成功することを条件として、仲介サーバＭから受信した決済金額で決済を実行する。具体的には、決済管理部５１１は、第２ユーザＵ２が開設している口座に決済金額に相当する額を振り込む。これは、第２決済サーバＱ２が第１ユーザＵ１の支払いを立て替えていることになる。なお、ユーザ認証に失敗した場合、すなわち、第２ユーザＵ２が第２決済事業者にユーザ登録をしていない場合、第２決済サーバＱ２の決済管理部５１１は決済処理を中止する。

（１１）決済管理部５１１は、決済が完了したことを第２ユーザ端末Ｔ２に通知する。
（１２）仲介サーバＭの通知部３１２は、第２決済サーバＱ２に決済要求を送信すると、決済が完了したことを第１ユーザ端末Ｔ１に通知する。

（１３）第２決済サーバＱ２の精算管理部５１２は、第１決済サーバＱ１の精算管理部４１２に精算要求を行う。この結果、第１決済サーバＱ１が管理する第１ユーザＵ１の口座から決済金額に相当する額が第２決済サーバＱ２に送金され、第２決済サーバＱ２が立て替えた第１ユーザＵ１の支払いが精算される。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。例えば、仲介サーバＭの図示しない精算仲介部が第２決済サーバＱ２の精算管理部５１２から精算要求を受信し、第１決済サーバＱ１の精算管理部４１２に転送してもよい。

このように、第１の実施の形態に係る仲介サーバＭは、第１ユーザ端末Ｔ１、第２ユーザ端末Ｔ２、第１決済サーバＱ１、及び第２決済サーバＱ２の間で行われる決済処理を仲介する。これにより、仲介サーバＭは、第１ユーザＵ１が契約している電子決済の種別と第２ユーザＵ２が契約している電子決済の種別とが異なっても、電子決済を実現させることができる。

＜第１の実施の形態に係る仲介サーバＭが奏する効果＞
以上説明したように、実施の形態に係る仲介サーバＭによれば、ユーザＵが電子決済の種別を意識せずに決済を行えるようにすることができる。

＜第１の実施の形態の第１の変形例＞
図５は、第１の実施の形態の第１の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。第１の実施の形態の第１の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳとは異なり、第１決済サーバＱ１が決済情報に基づいて決済処理を実行する。

以下、図５を参照しながら、第１の実施の形態の第１の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１２）の順序で説明するが、この数字は図５における（１）から（１２）と対応する。なお、（１）から（７）までの処理は図３における（１）から（７）までの処理と同様であるため省略する。

（８）第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致するか否かを判定することにより、ユーザ認証を実行する。第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致することを条件として、仲介サーバＭから受信した決済用トークンに紐付けられている第１ユーザ識別子を記憶部４０から取得し、第１ユーザ識別子で特定される第１ユーザＵ１の口座からの残金で決済金額を決済できるか否かを判定し、決済可能な場合は決済を実行して第１ユーザＵ１の口座から決済金額に相当する額を引き落とす。

（９）第１決済サーバＱ１の決済管理部４１１は、決済の結果を仲介サーバＭに送信する。
（１０）仲介サーバＭの通知部３１２は、第１決済サーバＱ１から受信した決済の結果を第２ユーザ端末Ｔ２に送信する。
（１１）仲介サーバＭの通知部３１２は、第１決済サーバＱ１から受信した決済の結果を第１ユーザ端末Ｔ１に送信する。

（１２）第１決済サーバＱ１の精算管理部４１２は、第２決済サーバＱ２の精算管理部５１２に精算要求を行う。この結果、第１決済サーバＱ１が管理する第１ユーザＵ１の口座から引き落とされた決済金額に相当する額が、第２決済サーバＱ２が管理する第２ユーザＵ２の口座に振り込まれる。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

このように、第１の実施の形態の第１の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳと異なり、第１ユーザＵ１が利用可能な決済事業者の第１決済サーバＱ１が決済処理を実行する。このため、第１の実施の形態の第１の変形例に係る決済処理システムＳは、第１ユーザＵ１の口座に決済金額を決済するだけの残高が存在すれば、残高確認の結果を仲介サーバＭに通知する処理を省略してすぐに決済処理が実行できるため、決済処理を迅速化することができる。

第１の実施の形態に係る決済処理システムＳと、第１の実施の形態の第１の変形例に係る決済処理システムＳとを考慮すると、仲介サーバＭの決済要求部３１１は、第１決済サーバＱ１と、第２決済サーバＱ２とのいずれか一方の決済サーバＱに、決済金額の決済要求を送信すればよいとも言える。決済要求を受信した一方の決済サーバＱが決済処理を実行して、他方の決済サーバＱに精算要求を送信することにより、決済処理システムＳは、第１ユーザＵ１が契約している電子決済の種別と第２ユーザＵ２が契約している電子決済の種別とが異なっても、電子決済を実現させることができる。

＜第１の実施の形態の第２の変形例＞
図６は、第１の実施の形態の第２の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。第１の実施の形態の第２の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳとは異なり、仲介サーバＭは、第１ユーザ端末Ｔ１及び第１決済サーバＱ１との間でやり取りする情報を第１決済サーバＱ１が用いる暗号鍵で暗号化する。また、仲介サーバＭは、第２ユーザ端末Ｔ２及び第２決済サーバＱ２との間でやり取りする情報を第２決済サーバＱ２が用いる暗号鍵で暗号化する。

以下、図６を参照しながら、第１の実施の形態の第２の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１４）の順序で説明するが、この数字は図６における（１）から（１４）と対応する。なお、（１）の処理は、図３における（１）の処理と同様であるため省略する。

（２）第１決済サーバＱ１のトークン送信部４１０は、第１ユーザ端末Ｔ１から取得した取得要求に応答して、第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成し、生成した決済用トークンを第１決済サーバＱ１が用いる暗号鍵で暗号化した上で第１ユーザ端末Ｔ１に送信する。トークン送信部４１０は、第１ユーザ端末Ｔ１に送信した決済用トークンを、第１ユーザＵ１を特定するための第１ユーザ識別子と紐づけて記憶部４０に記憶させる。なお、第１決済サーバＱ１は、第１ユーザ端末Ｔ１のトークン要求部１１０からトークンの要求があったとき、又はトークンの要求に先立って、第１ユーザ端末Ｔ１を用いるユーザのユーザ認証を実行する。このユーザ認証が成功することを条件として、第１決済サーバＱ１のトークン送信部４１０は、決済用トークンを生成する。

（３）第１ユーザ端末Ｔ１の表示制御部１１１は、第１決済サーバＱ１から受信した暗号化された決済用トークンを復号し、得られた決済用トークンに基づいて生成した決済用コードを、第１ユーザ端末Ｔ１の表示部に表示させる。
（４）第２ユーザ端末Ｔ２のコード読取部２１０は、第１ユーザ端末Ｔ１の表示部に表示された決済用コードを読み取って決済用トークンを取得する。

（５）第２ユーザ端末Ｔ２の決済情報送信部２１１は、コード読取部２１０が取得した決済用トークンと、第２ユーザ端末Ｔ２を利用する第２ユーザＵ２を特定するための第２ユーザ識別子と、第２ユーザＵ２が利用可能な第２決済事業者を特定するための第２事業者識別子と、決済金額とを含む決済情報を、第２決済サーバＱ２が利用する暗号鍵で暗号化して仲介サーバＭに送信する。

（６）仲介サーバＭの決済情報受信部３１０は、暗号化された決済情報を第２ユーザ端末Ｔ２から受信する。
（７）決済情報受信部３１０は、第２ユーザ端末Ｔ２から受信した暗号化された決済情報を、第２決済サーバＱ２が利用する暗号鍵を用いて復号する。

（８）仲介サーバＭの決済要求部３１１は、決済情報受信部３１０が受信した決済情報に含まれる決済用トークンから取得した第１事業者識別子で特定される第１決済事業者の第１決済サーバＱ１に、決済用トークンと決済金額とを含む情報を第１決済サーバＱ１が利用する暗号鍵で暗号化して送信する。

（９）第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致するか否かを判定することにより、ユーザ認証を実行する。第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致することを条件として、仲介サーバＭから受信した情報を復号して決済用トークンに紐付けられている第１ユーザ識別子を記憶部４０から取得する。決済管理部４１１は、第１ユーザ識別子で特定される第１ユーザＵ１の口座の残金で決済金額を決済できるか否かを判定し、結果を暗号化して仲介サーバＭに通知する。

（１０）仲介サーバＭの決済要求部３１１は、決済管理部４１１から受け取った通知を第１決済サーバＱ１が用いる暗号鍵で復号する。仲介サーバＭの決済要求部３１１は、第１ユーザＵ１の口座の残金で決済金額を決済できる場合（すなわち、第１決済サーバＱ１において第１ユーザＵＩのユーザ認証が成功し、残金がある場合）、第２決済事業者が管理する第２決済サーバＱ２に、決済情報に含まれる決済金額の決済要求と第２ユーザ識別子とを第２決済サーバＱ２が用いる暗号鍵で暗号化して送信する。

（１１）第２決済サーバＱ２の決済管理部５１１は、仲介サーバＭの決済要求部３１１から受信した第２ユーザ識別子に基づくユーザ認証が成功することを条件として、仲介サーバＭから受信した情報を復号し、決済金額で決済を実行する。
（１２）決済管理部５１１は、決済が完了したことを示す情報を第２決済サーバＱ２が用いる暗号鍵で暗号化して第２ユーザ端末Ｔ２に通知する。

（１３）仲介サーバＭの通知部３１２は、第２決済サーバＱ２に決済要求を送信すると、決済が完了したことを示す情報を第１決済サーバＱ１が用いる暗号鍵で暗号化して第１ユーザ端末Ｔ１に通知する。
（１４）第２決済サーバＱ２の精算管理部５１２は、第１決済サーバＱ１の精算管理部４１２に精算要求を行う。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

このように、仲介サーバＭは、第１ユーザ端末Ｔ１及び第１決済サーバＱ１との間でやり取りする情報を第１決済サーバＱ１が用いる暗号鍵で暗号化する。また、仲介サーバＭは、第２ユーザ端末Ｔ２及び第２決済サーバＱ２との間でやり取りする情報を第２決済サーバＱ２が用いる暗号鍵で暗号化する。これより、仲介サーバＭは、決済処理の安全性をより向上することができる。

＜第１の実施の形態の第３の変形例＞
図７は、第１の実施の形態の第３の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。第１の実施の形態の第３の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳと異なり、第１決済サーバＱ１は、生成した決済用トークンを仲介サーバＭにも送信する。

以下、図７を参照しながら、第１の実施の形態の第３の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１５）の順序で説明するが、この数字は図７における（１）から（１５）と対応する。なお、（１）及び（２）の処理は、図３における（１）及び（２）の処理と同様であるため省略する。

（３）トークン送信部４１０は、生成した決済用トークンを仲介サーバＭに送信する。
（４）第１ユーザ端末Ｔ１の表示制御部１１１は、第１決済サーバＱ１から受信した決済用トークンに基づいて生成した決済用コードを、第１ユーザ端末Ｔ１の表示部に表示させる。
（５）第２ユーザ端末Ｔ２のコード読取部２１０は、第１ユーザ端末Ｔ１の表示部に表示された決済用コードを読み取って決済用トークンを取得する。

（６）第２ユーザ端末Ｔ２の決済情報送信部２１１は、コード読取部２１０が取得した決済用トークンと、第２ユーザ端末Ｔ２を利用する第２ユーザＵ２を特定するための第２ユーザ識別子と、第２ユーザＵ２が利用可能な第２決済事業者を特定するための第２事業者識別子と、決済金額と、を含む決済情報を仲介サーバＭに送信する。

（７）仲介サーバＭの決済情報受信部３１０は、第２ユーザ端末Ｔ２から決済情報を受信する。
（８）仲介サーバＭの決済要求部３１１は、第１決済サーバＱ１から受信した決済用トークンと、第２ユーザ端末Ｔ２から受信した決済用トークンとが不一致の場合、決済処理を中止する。具体的には、決済要求部３１１は、第１決済サーバＱ１から受信した決済用トークンのうち有効期限が切れていない決済用トークンのいずれかに、第２ユーザ端末Ｔ２から受信した決済用トークンが含まれていない場合に不一致と判断する。

（９）仲介サーバＭの決済要求部３１１は、第１決済サーバＱ１から受信した決済用トークンと、第２ユーザ端末Ｔ２から受信した決済用トークンとが一致する場合、決済用トークンと決済金額とを第１決済サーバＱ１に送信する。

（１０）第１決済サーバＱ１の決済管理部４１１は、仲介サーバＭから受信した決済用トークンに紐付けられている第１ユーザ識別子を記憶部４０から取得し、第１ユーザ識別子で特定される第１ユーザＵ１の口座の残金で決済金額を決済できるか否かを判定し、結果を仲介サーバＭに通知する。

（１１）仲介サーバＭの決済要求部３１１は、第１ユーザＵ１の口座の残金で決済金額を決済できる場合、第２決済事業者が管理する第２決済サーバＱ２に、決済情報に含まれる決済金額の決済要求を送信する。
（１２）第２決済サーバＱ２の決済管理部５１１は、仲介サーバＭから受信した決済金額で決済を実行する。具体的には、決済管理部５１１は、第２ユーザＵ２が開設している口座に決済金額に相当する額を振り込む。

（１３）決済管理部５１１は、決済が完了したことを第２ユーザ端末Ｔ２に通知する。
（１４）仲介サーバＭの通知部３１２は、第２決済サーバＱ２に決済要求を送信すると、決済が完了したことを第１ユーザ端末Ｔ１に通知する。

（１５）第２決済サーバＱ２の精算管理部５１２は、第１決済サーバＱ１の精算管理部４１２に精算要求を行う。この結果、第１決済サーバＱ１が管理する第１ユーザＵ１の口座から決済金額に相当する額が第２決済サーバＱ２に送金される。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

このように、第１の実施の形態の第３の変形例に係る仲介サーバＭにおいて、決済要求部３１１は、第１決済サーバＱ１から受信した決済用トークンと、第２ユーザ端末Ｔ２から受信した決済用トークンとが不一致の場合、決済処理を中止する。これにより、仲介サーバＭは、第１決済サーバＱ１が残高確認等の処理を実行することを抑制できるため、第１決済サーバＱ１の負荷を軽減することができる。

なお、第１決済サーバＱ１は、第１ユーザ端末Ｔ１の決済用トークンの取得要求に応じて生成する決済用トークンに、第１事業者識別子を含めなくてもよい。この場合、仲介サーバＭは、第１決済サーバＱ１から決済用トークンを受信したとき、受信した決済用トークンを第１事業者識別子と関連付けて記憶部３０に記憶する。仲介サーバＭは、第２ユーザ端末Ｔ２から受信した決済情報に含まれる決済用トークンと一致する決済用トークンを記憶部３０から読み出し、その決済用トークンに関連付けられている第１事業者識別子を取得することで、第１ユーザＵ１が利用可能な決済事業者を特定することができる。

＜第１の実施の形態に係る第４の変形例＞
図８は、第１の実施の形態の第４の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。第１の実施の形態の第４の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳと異なり、決済用コードを読み取った第２ユーザ端末Ｔ２は、決済情報を仲介サーバＭではなく第２決済サーバＱ２に送信する。

以下、図８を参照しながら、第１の実施の形態の第４の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１４）の順序で説明するが、この数字は図８における（１）から（１４）と対応する。なお、（１）から（４）までの処理は、図３における（１）から（４）までの処理と同様であるため省略する。

（５）第２ユーザ端末Ｔ２の決済情報送信部２１１は、コード読取部２１０が取得した決済用トークンと、決済金額と、を含む決済情報を第２決済サーバＱ２に送信する。

（６）第２決済サーバＱ２の決済管理部５１１は、第２ユーザ端末Ｔ２から受信した決済情報に含まれる決済用トークンが第２決済サーバＱ２が用いる決済用トークンとは異なる場合、第２ユーザ端末Ｔ２から受信した決済情報を仲介サーバＭに転送する。
（７）仲介サーバＭの決済情報受信部３１０は、第２決済サーバＱ２から決済情報を受信する。
（８）仲介サーバＭの決済要求部３１１は、決済情報受信部３１０が受信した決済情報に含まれる決済用トークンから取得した第１事業者識別子で特定される第１決済事業者の第１決済サーバＱ１に、決済用トークンと決済金額とを送信する。

（９）第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致するか否かを判定することにより、ユーザ認証を実行する。第１決済サーバＱ１の決済管理部４１１は、第１ユーザ端末Ｔ１に送信した決済用トークンと仲介サーバＭから受信した決済用トークンとが一致することを条件として、仲介サーバＭから受信した決済用トークンに紐付けられている第１ユーザ識別子を記憶部４０から取得し、第１ユーザ識別子で特定される第１ユーザＵ１の口座の残金で決済金額を決済できるか否かを判定し、結果を仲介サーバＭに通知する。

（１０）仲介サーバＭの決済要求部３１１は、第１ユーザＵ１の口座の残金で決済金額を決済できる場合、第２決済事業者が管理する第２決済サーバＱ２に、決済情報に含まれる決済金額の決済要求を送信する。
（１１）第２決済サーバＱ２の決済管理部５１１は、仲介サーバＭの決済要求部３１１から受信した第２ユーザ識別子に基づくユーザ認証が成功することを条件として、仲介サーバＭから受信した決済金額で決済を実行する。
（１２）決済管理部５１１は、決済が完了したことを第２ユーザ端末Ｔ２に通知する。

（１３）仲介サーバＭの通知部３１２は、第２決済サーバＱ２に決済要求を送信すると、決済が完了したことを第１ユーザ端末Ｔ１に通知する。
（１４）第２決済サーバＱ２の精算管理部５１２は、第１決済サーバＱ１の精算管理部４１２に精算要求を行う。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

このように、第１の実施の形態の第４の変形例に係る決済処理システムＳでは、第２ユーザ端末Ｔ２は、決済情報を仲介サーバＭではなく第２決済サーバＱ２に送信する。第２決済サーバＱ２は、受信した決済情報に含まれる決済用トークンは第１決済サーバＱ１が生成したものであるため決済処理を実行できないので、決済情報を仲介サーバＭに転送する。第２ユーザ端末Ｔ２と仲介サーバＭとの間の情報のやり取りが不要となるため、第２ユーザＵ２が仲介サーバＭに加盟店登録を指定しなくても、第２決済サーバＱ２が仲介サーバＭに事業者登録をしていれば、仲介サーバＭは決済処理を仲介することができる。

＜第１の実施の形態の第５の変形例＞
図９は、第１の実施の形態の第５の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。第１の実施の形態の第５の変形例に係る決済処理システムＳは、第１の実施の形態に係る決済処理システムＳと異なり、第１ユーザ端末Ｔ１は、仲介サーバＭに決済用トークンの取得要求を送信する。

以下、図９を参照しながら、第１の実施の形態の第５の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１３）の順序で説明するが、この数字は図９における（１）から（１３）と対応する。

（１）第１ユーザ端末Ｔ１のトークン要求部１１０は、第１決済サーバＱ１を利用して決済をするための決済用トークンの取得要求を、仲介サーバＭに送信する。
（２）仲介サーバＭのトークン送信部（不図示）は、第１ユーザ端末Ｔ１から取得した取得要求に応答して、第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して第１ユーザ端末Ｔ１に送信する。記憶部３０は、第１ユーザ端末Ｔ１に送信した決済用トークンを、第１ユーザＵ１を特定するための第１ユーザ識別子と紐づけて記憶する。

なお、仲介サーバＭは、第１ユーザ端末Ｔ１のトークン要求部１１０からトークンの要求があったとき、又はトークンの要求に先立って、第１ユーザ端末Ｔ１を用いるユーザのユーザ認証を実行する。具体的には、第１ユーザ端末Ｔ１が、第１ユーザ識別子に関連付けられた識別子で仲介サーバＭにサインインすることをもって、仲介サーバＭはユーザ認証を実現できる。又は、仲介サーバＭは、第１ユーザ端末Ｔ１のトークン要求部１１０からトークンの要求があったときに、トークン要求部１１０から第１事業者識別子を取得することを条件として、ユーザ認証が成功したとみなしてもよい。このユーザ認証が成功することを条件として、第１決済サーバＱ１のトークン送信部４１０は、決済用トークンを生成する。

図９における（３）から（１３）までの処理は、図３における（３）から（１３）までの処理と同様であるため省略する。第１の実施の形態の第５の変形例に係る決済処理システムＳでは、仲介サーバＭにユーザ登録をしているユーザ端末Ｔから決済用トークンの取得要求があった場合、仲介サーバＭが決済用トークンを生成する。このように、決済用トークンの生成処理の一部を仲介サーバＭが担えるため、第１の実施の形態の第５の変形例に係る決済処理システムＳは、第１決済サーバＱ１の処理負荷を分散させることができる。

＜第１の実施の形態の第６の変形例＞
図１０は、第１の実施の形態の第６の変形例に係る決済処理システムＳが実行する決済処理を説明するための図である。具体的には、第６の変形例に係る決済処理システムＳは、店舗提示方式の決済システムである。したがって、第１ユーザ端末Ｔ１が店舗端末となり、第１ユーザＵ１は店舗端末が設置されている店舗Ｒの経営者等である。また、店舗Ｒの顧客が第２ユーザＵ２となり、第２ユーザＵ２のユーザ端末が第２ユーザ端末Ｔ２となる。

以下、図１０を参照しながら、第１の実施の形態の第６の変形例に係る決済処理システムＳが実行する決済処理を（１）から（１３）の順序で説明するが、この数字は図１０における（１）から（１３）と対応する。

（１）第１ユーザ端末Ｔ１のトークン要求部１１０は、第１ユーザＵ１が利用可能な第１決済事業者が管理する第１決済サーバＱ１に、決済用トークンの取得要求を送信する。
（２）第１決済サーバＱ１のトークン送信部４１０は、第１ユーザ端末Ｔ１から取得した取得要求に応答して、第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して第１ユーザ端末Ｔ１に送信する。

（３）第１ユーザ端末Ｔ１の表示制御部１１１は、第１決済サーバＱ１から受信した決済用トークンに基づいて生成した決済用コードを、第１ユーザ端末Ｔ１の表示部に表示させる。
（４）第２ユーザ端末Ｔ２のコード読取部２１０は、第１ユーザ端末Ｔ１の表示部に表示された決済用コードを読み取って決済用トークンを取得する。

（５）第２ユーザ端末Ｔ２の決済情報送信部２１１は、コード読取部２１０が取得した決済用トークンと、第２ユーザ端末Ｔ２を利用する第２ユーザＵ２を特定するための第２ユーザ識別子と、第２ユーザＵ２が利用可能な第２決済事業者を特定するための第２事業者識別子と、決済金額と、を含む決済情報を仲介サーバＭに送信する。

（６）仲介サーバＭの決済情報受信部３１０は、第２ユーザ端末Ｔ２から決済情報を受信する。
（７）仲介サーバＭの決済要求部３１１は、第２ユーザ端末Ｔ２を所持する第２ユーザＵ２が契約をしている第２決済事業者の第２決済サーバＱ２に、決済金額、及び第２ユーザＵ２を特定するための第２ユーザ識別子を送信する。

（８）第２決済サーバＱ２の決済管理部５１１は、仲介サーバＭから受信した第２ユーザ識別子を用いてユーザ認証を行う。認証が成功した場合、第２決済サーバＱ２の決済管理部５１１は、第２ユーザ識別子で特定される第２ユーザＵ２の口座の残金で決済金額を決済できるか否かを判定し、結果を仲介サーバＭに通知する。

（９）仲介サーバＭの決済要求部３１１は、第２ユーザＵ２の口座の残金で決済金額を決済できる場合、第１決済事業者が管理する第１決済サーバＱ１に、決済情報に含まれる決済金額の決済要求を送信する。
（１０）第１決済サーバＱ１の決済管理部４１１は、仲介サーバＭから受信した決済金額で決済を実行する。具体的には、決済管理部４１１は、第１ユーザＵ１が開設している口座に決済金額に相当する額を振り込む。

（１１）決済管理部４１１は、決済が完了したことを第１ユーザ端末Ｔ１に通知する。
（１２）仲介サーバＭの通知部３１２は、第１決済サーバＱ１に決済要求を送信すると、決済が完了したことを第２ユーザ端末Ｔ２に通知する。

（１３）第１決済サーバＱ１の精算管理部４１２は、第２決済サーバＱ２の精算管理部５１２に精算要求を行う。この結果、第２決済サーバＱ２が管理する第２ユーザＵ２の口座から決済金額に相当する額が第１決済サーバＱ１に送金される。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

これにより、決済処理システムＳは、第１ユーザＵ１が契約している電子決済の種別と第２ユーザＵ２が契約している電子決済の種別とが異なっても、電子決済を実現させることができる。

［第２の実施の形態］
＜第２の実施の形態の概要＞
第２の実施の形態の概要を述べる。第２の実施の形態に係る決済処理システムＳは、店舗提示方式の決済システムである。したがって、第２の実施の形態に係る決済処理システムＳにおいては、第１ユーザ端末Ｔ１は店舗Ｒに設置された店舗端末であり、第２ユーザ端末は店舗Ｒを利用する顧客が所持する顧客端末である。以下、第２の実施の形態に係る決済処理システムＳにおいては、第１ユーザ端末Ｔ１である店舗端末を「店舗端末Ｔ１」、第２ユーザ端末Ｔ２である顧客端末を「顧客端末Ｔ２」と記載する。

第２の実施の形態に係る顧客端末Ｔ２には、あらかじめ複数の異なる決済サーバＱで用いられるコード生成アルゴリズム及び暗号化鍵を備えるアプリケーションソフトウェア（以下、「決済用アプリ」と記載する。）がインストールされている。具体的には、顧客端末Ｔ２の所有者が仲介サーバＭにユーザ登録をすると、顧客端末Ｔ２は仲介サーバＭから決済用アプリをダウンロードすることができるようになる。

第２の実施の形態に係る顧客端末Ｔ２は決済用アプリを備えているため、店舗端末Ｔ１から読み取った決済用トークンをその決済用トークンを用いる決済サーバＱが用いるアルゴリズムで符号化したり、決済サーバＱが用いる暗号鍵で暗号化したりすることができる。第２の実施の形態に係る決済処理システムＳでは、顧客端末Ｔ２が、店舗端末Ｔ１から受信した情報を第１決済サーバＱ１が扱える情報に変換したり、変換した情報を第１決済サーバＱ１が用いる暗号鍵で暗号化したりすることを実行する。この点で、第１の実施の形態における特に第２の変形例に係る決済処理システムＳと異なる。

以下、第２の実施の形態に係る決済処理システムＳが備える各装置の機能構成、及び第２の実施の形態に係る決済処理システムＳが実行する決済処理を説明するが、第１の実施の形態に係る決済処理システムＳ又はその各種変形例と重複する記載については、適宜省略又は簡略化して説明する。

図１１は、第２の実施の形態に係る決済処理システムＳが備える各装置の機能構成を模式的に示す図である。図１１において、仲介サーバＭ、第１決済サーバＱ１、及び第２決済サーバＱ２は、図２に示す第１の実施の形態に係る仲介サーバＭ、第１決済サーバＱ１、及び第２決済サーバＱ２と同様の機能構成を有するため詳細な図示を省略している。図１１に示すように、第２の実施の形態に係る顧客端末Ｔ２の制御部２１が、暗号化部２１２を備えている点で、第１の実施の形態に係る第２ユーザ端末Ｔ２と異なる。

図１２は、第２の実施の形態に係る決済処理システムＳが実行する決済処理を説明するための図である。以下、図１１及び図１２を参照しながら、第２の実施の形態に係る決済処理システムＳが実行する決済処理を（１）から（１５）の順序で説明するが、この数字は図１２における（１）から（１５）と対応する。

（１）店舗端末Ｔ１のトークン要求部１１０は、店舗端末Ｔ１が設置されている店舗Ｒの経営者が利用可能な第１決済事業者が管理する第１決済サーバＱ１に、決済用トークンの取得要求を送信する。

（２）第１決済サーバＱ１のトークン送信部４１０は、店舗端末Ｔ１から取得した取得要求に応答して、第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して店舗端末Ｔ１に送信する。

（３）店舗端末Ｔ１の表示制御部１１１は、第１決済サーバＱ１から受信した決済用トークンに基づいて生成した決済用コードを、店舗端末Ｔ１の表示部に表示させる。
（４）顧客端末Ｔ２のコード読取部２１０は、第１ユーザ端末Ｔ１の表示部に表示された決済用コードを読み取って決済用トークンを取得する。

（５）顧客端末Ｔ２の暗号化部２１２は、顧客端末Ｔ２を所持する顧客が利用可能な第２決済事業者を特定するための第２事業者識別子と、決済用トークンと、決済金額と、を含む決済情報を、第１決済事業者の決済サーバである第１決済サーバＱ１が利用する暗号鍵で暗号化する。

（６）顧客端末Ｔ２の決済情報送信部２１１は、暗号化部２１２が暗号化した決済情報を仲介サーバＭに送信する。
（７）仲介サーバＭの決済情報受信部３１０は、顧客端末Ｔ２から暗号化された決済情報を受信する。

（８）仲介サーバＭの暗号化部２１２は、顧客端末Ｔ２から受信した決済情報を復号し、決済用トークンに含まれる第１事業者識別子を取得する。
（９）仲介サーバＭの決済要求部３１１は、顧客端末Ｔ２から取得した暗号化された決済情報を第１決済サーバＱ１に転送する。
（１０）第１決済サーバの決済管理部４１１は、仲介サーバＭから転送された決済情報に基づいて店舗端末Ｔ１のユーザである顧客のユーザ認証を実行して認証結果を仲介サーバＭに送信する。具体的には、第１決済サーバの決済管理部４１１は、トークン送信部４１０が店舗端末Ｔ１に送信した決済用トークンと、仲介サーバＭから受信した決済情報に含まれる決済用トークンとが一致する場合、顧客の認証が成功したと判定する。

（１１）仲介サーバＭの決済要求部３１１は、認証が成功した場合、第２決済サーバＱ２に決済金額の決済要求を送信する。
（１２）第２決済サーバＱ２の決済管理部５１１は、顧客の口座の残高で決済できる場合、決済を実行する。
（１３）第２決済サーバＱ２の決済管理部５１１は、決済完了の通知を仲介サーバＭに送信する。

（１４）仲介サーバＭの通知部３１２は、店舗端末Ｔ１及び顧客端末Ｔ２に決済完了を通知する。
（１５）第２決済サーバＱ２の精算管理部５１２は、第１決済サーバＱ１の精算管理部４１２に精算要求を行う。この結果、第２決済サーバＱ２が管理する顧客の口座から決済金額に相当する額が第１決済サーバＱ１に送金される。なお、仲介サーバＭは、第１決済サーバＱ１と第２決済サーバＱ２との間で行われる精算処理を仲介してもよい。

＜第２の実施の形態に係る決済処理システムＳが奏する効果＞
以上説明したように、第２の実施の形態に係る決済処理システムＳによれば、ユーザＵが電子決済の種別を意識せずに決済を行えるようにすることができる。

特に、第２の実施の形態に係る決済処理システムＳでは、顧客端末Ｔ２が、店舗端末Ｔ１から受信した情報を第１決済サーバＱ１が扱える情報に変換したり、変換した情報を第１決済サーバＱ１が用いる暗号鍵で暗号化したりすることを実行する。第２の実施の形態に係る決済処理システムＳでは、仲介サーバＭ又は決済サーバＱが実行すべき処理の一部を顧客端末Ｔ２が肩代わりするため、システム全体としての負荷を分散できる。

＜第２の実施の形態の第１の変形例＞
上記では、第２決済サーバＱ２が決済情報に基づいて決済し、事後的に第１決済サーバＱ１に精算要求をする場合について説明した。これに替えて、第１決済サーバＱ１が決済情報に基づいて決済し、事後的に第２決済サーバに精算要求をしてもよい。すなわち、仲介サーバＭの決済要求部３１１は、第１決済サーバＱ１と、第２決済サーバＱ２とのいずれか一方の決済サーバＱに、決済金額の決済要求を送信すればよいとも言える。決済要求を受信した一方の決済サーバＱが決済処理を実行して、他方の決済サーバＱに精算要求を送信することにより、決済処理システムＳは、店舗Ｒの経営者が契約している電子決済の種別と顧客が契約している電子決済の種別とが異なっても、電子決済を実現させることができる。

＜第２の実施の形態の第２の変形例＞
第２の実施の形態の第２の変形例に係る決済処理システムＳは、第２の実施の形態に係る決済処理システムＳと異なり、第１決済サーバＱ１は、生成した決済用トークンを仲介サーバＭにも送信する。

第２の実施の形態の第２の変形例に係る仲介サーバＭにおいて、決済要求部３１１は、第１決済サーバＱ１から受信した決済用トークンと、顧客端末Ｔ２から受信した決済用トークンとが不一致の場合、決済処理を中止する。より具体的には、仲介サーバＭは、第１決済サーバＱ１から第１決済サーバＱ１が用いる暗号鍵で暗号化された決済用トークンを受信し、同じ暗号鍵を用いて復号することで決済用トークンを取得する。また、仲介サーバＭは、顧客端末Ｔ２から第１決済サーバＱ１が用いる暗号鍵で暗号化された決済情報を受信し、同じ暗号鍵を用いて復号した上で決済用トークンを抽出する。仲介サーバＭは、第１決済サーバＱ１に由来する決済用トークンと、顧客端末Ｔ２に由来する決済用トークンとを比較して、両者が一致するか否かを判定する。これにより、仲介サーバＭは、第１決済サーバＱ１による店舗端末Ｔ１の認証処理に相当する処理を実行することになるので、第１決済サーバＱ１の負荷を軽減することができる。

＜第２の実施の形態の第３の変形例＞
第２の実施の形態の第３の変形例に係る決済処理システムＳは、第２の実施の形態に係る決済処理システムＳと異なり、店舗端末Ｔ１は、仲介サーバＭに決済用トークンの取得要求を送信する。これにより、決済用トークンの生成処理の一部を仲介サーバＭが担えるため、第２の実施の形態の第３の変形例に係る決済処理システムＳは、第１決済サーバＱ１の処理負荷を分散させることができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されず、その要旨の範囲内で種々の変形及び変更が可能である。例えば、装置の分散・統合の具体的な実施の形態は、以上の実施の形態に限られず、その全部又は一部について、任意の単位で機能的又は物理的に分散・統合して構成することができる。また、複数の実施の形態の任意の組み合わせによって生じる新たな実施の形態も、本発明の実施の形態に含まれる。組み合わせによって生じる新たな実施の形態の効果は、もとの実施の形態の効果を合わせ持つ。

Ｔ１・・・第１ユーザ端末
１０・・・記憶部
１１・・・制御部
１１０・・・トークン要求部
１１１・・・表示制御部
Ｔ２・・・第２ユーザ端末
２０・・・記憶部
２１・・・制御部
２１０・・・コード読取部
２１１・・・決済情報送信部
２１２・・・暗号化部
Ｍ・・・仲介サーバ
３０・・・記憶部
３１・・・制御部
３１０・・・決済情報受信部
３１１・・・決済要求部
３１２・・・通知部
Ｑ１・・・第１決済サーバ
４０・・・記憶部
４１・・・制御部
４１０・・・トークン送信部
４１１・・・決済管理部
４１２・・・精算管理部
Ｑ２・・・第２決済サーバ
５０・・・記憶部
５１・・・制御部
５１０・・・トークン送信部
５１１・・・決済管理部
５１２・・・精算管理部
Ｎ・・・通信ネットワーク
Ｓ・・・決済処理システム

Claims (6)

1. 第１ユーザが利用する第１ユーザ端末が、前記第１ユーザが利用可能な第１決済事業者が管理する第１決済サーバに、決済用トークンの取得要求を送信するステップと、
   前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられた決済用トークンを前記第１ユーザ端末に送信するステップと、
   前記第１ユーザ端末が、前記決済用トークンに基づいて生成した決済用コードを表示するステップと、
   第２ユーザが利用する第２ユーザ端末が、前記決済用コードを読み取って得られた決済用トークンと、決済金額と、を含む情報であって前記第２ユーザが利用可能な第２決済事業者であり前記第１決済事業者とは異なる第２決済事業者が通信時に情報を暗号化するための暗号鍵を用いて暗号化した決済情報を、前記第２ユーザが登録された仲介サーバであって、前記第１決済事業者を含む複数の決済事業者がそれぞれ通信時に情報を暗号化するための暗号鍵を有する仲介サーバに送信するステップと、
   前記仲介サーバが、前記決済用トークンに関連付けられている前記第１事業者識別子を取得するステップと、
   前記仲介サーバが、前記決済用トークンを生成した前記第１決済サーバに、前記第１決済事業者が通信時に情報を暗号化するための暗号鍵を用いて暗号化した前記決済情報を送信するステップと、
   前記第１決済サーバが、前記暗号鍵を用いて復号した前記決済情報に含まれる前記決済用トークンに基づいて前記第１ユーザのユーザ認証をするステップと、
   を含む決済処理方法。
2. 前記第２ユーザは、前記第１決済事業者が提供する決済サービスを利用するための登録を行っていないユーザである、
   請求項１に記載の決済処理方法。
3. 前記第１決済サーバは、前記第１ユーザ端末に送信した決済トークンと前記仲介サーバから受信した決済トークンとが一致することを条件として、前記第１ユーザが前記決済金額を決済できるか否かを判定した判定結果を前記仲介サーバに通知する、
   請求項１又は２に記載の決済処理方法。
4. 前記仲介サーバは、前記第１ユーザが前記決済金額を決済できる場合、前記第２ユーザが登録された第２決済事業者が管理する第２決済サーバに、前記決済情報に含まれる決済金額の決済要求を送信する、
   請求項３に記載の決済処理方法。
5. 前記仲介サーバは、前記第２決済事業者を特定するための第２事業者識別子を、前記第２ユーザ端末から取得する、
   請求項４に記載の決済処理方法。
6. 前記第１決済サーバが、前記第１決済事業者を特定するための第１事業者識別子が関連付けられたトークンを生成して前記仲介サーバに送信するステップと、
   前記仲介サーバが、前記第１決済サーバから受信した決済用トークンと、前記第２ユーザ端末から受信した決済情報に含まれる前記決済用トークンとが不一致の場合、決済処理を中止するステップとをさらに含む請求項１から５のいずれか一項に記載の決済処理方法。

Images