JP2017004256A - 情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム - Google Patents

Abstract

【課題】本願は、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させない技術を提供することを課題とする。
【解決手段】情報処理システムであって、電子マネーのリーダーライタに翳されたユーザ端末がリーダーライタから受信した情報を基に、リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、ユーザ端末がリーダーライタから受信した情報に含まれる決済額の情報を基に、ユーザ端末のユーザの口座の残高から決済額に相当する金額を減算処理する口座管理手段と、口座管理手段によって口座から減算される金額を基に、電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、バリュー生成手段が生成するバリューを基に、リーダーライタにおけるユーザ端末側の決済処理を実行する決済手段と、を備える。
【選択図】図６

Description

本願は、情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラムに関する。

情報通信技術の発達に伴い、電子マネーを使った決済が普及の一途を辿っている。例えば、特許文献１−５には、店舗等における決済を電子的な貨幣で取り交わす各種の技術が提案されている。（例えば、特許文献１−５を参照）。

特開２００９−１５１６９２号公報 特開２０００−２１５２５８号公報 特開２００２−１９７３８８号公報 特許第５１８９２９７号公報 特開２００２−２５９８８１号公報

現行の電子マネーサービスでは、ユーザが加入してバリューを蓄積している電子マネー事業者の電子マネーしか利用することができないため、店頭に置かれたリーダーライタ（本願では単に「ＲＷ」と表記する場合がある）が当該ユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していて決済不能な場合がある。また、現行の電子マネーサービスでは基本的に決済に係る金額以上のバリューが蓄積されていることを前提としており、少額のバリューが残存している状態を解消することが容易でないので、様々な電子マネー事業者のサービスに加入したような場合に残存するバリューが増えすぎて不合理である。

そこで、本願は、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させない技術を提供することを課題とする。

上記課題を解決するため、本発明では、リーダーライタで決済可能な電子マネーの種類を特定すると、決済金額を口座の残高から減算する処理と、特定された電子マネーの種類に対応する方式で生成されたバリューを基にした当該リーダーライタにおける決済処理とを実行することにより、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないようにした。

詳細には、情報処理システムであって、電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、前記口座管理手段によって前記口座から減算される金額を基に、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、前記バリュー生成手段が生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ
端末側の決済処理を実行する決済手段と、を備える。

上記の情報処理システムによって実現される電子マネー決済代行サービスであれば、ユーザが加入していると否とに関わらず、情報処理システムで取扱い可能なあらゆる電子マネー事業者の電子マネーをユーザが利用できるため、店頭に置かれたリーダーライタがユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していてユーザの電子マネーカードでは決済不能な場合であっても、電子マネーによる決済が可能である。また、上記実施形態において実現される電子マネー決済代行サービスでは基本的にバリューの蓄積が不要なので、例えば、様々な電子マネーに対応可能とするべく各電子マネー事業者のサービスに加入したような場合に生ずる、残存するバリューが増えすぎるという不合理が生じることもない。

なお、前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末から前記公衆通信回線を通じて送られる前記決済額の情報を取得すると前記減算処理を実行し、前記バリュー生成手段は、前記減算処理が実行されると前記バリューを生成し、前記決済手段は、前記ユーザ端末に設けられており、前記バリュー生成手段によって生成された前記バリューを前記公衆通信回線経由で取得すると、取得した前記バリューを基に前記決済処理を実行するものであってもよい。

このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザが外出先の店舗でユーザ端末を使い、滞りなく電子マネーの決済を行うことができる。

また、前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、前記決済手段は、前記ユーザ端末に設けられており、前記ユーザ端末が前記公衆通信回線により通信不能な状態で前記決済処理を実行する際は前記決済額に相当する負債額の情報を前記ユーザ端末に蓄積し、前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末に前記負債額の情報があることを前記公衆通信回線経由で前記ユーザ端末から検知すると、前記負債額に対応する金額の前記減算処理を実行し、前記バリュー生成手段は、前記減算処理が実行されると、前記バリューの生成処理と共に、前記ユーザ端末に情報として格納されている前記負債額の解消処理を実行するものであってもよい。

このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザ端末が通信不能な状態においても滞りなく電子マネーの決済を行うことができる。

また、前記ユーザ端末には、複数種の電子マネーについての優先順位を定めた順位情報が記憶されており、前記電子マネー特定手段は、前記ユーザ端末に設けられており、前記リーダーライタで決済可能な電子マネーが複数種ある場合は前記順位情報を基に前記リーダーライタで決済する電子マネーの種類を特定するものであってもよい。

このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタが様々な電子マネーに対応可能な場合であっても電子マネーで速やかに決済を行うことが可能となる。

また、前記電子マネー特定手段は、前記リーダーライタで決済可能な電子マネーが複数種ある場合は、前記ユーザ端末のユーザが利用する店舗の利用履歴、電子マネーの利用履歴、電子マネーのポイント還元率、複数の電子マネー間のポイント変換率の少なくとも何れかを用いて特定された順位を基に、前記リーダーライタで決済する電子マネーの種類を特定するものであってもよい。

このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタが様々な電子マネーに対応可能な場合に適切な電子マネーで速やかに決済を行うことが可能となる。

また、前記電子マネー特定手段は、前記リーダーライタで決済する電子マネーの種類を特定すると、特定した電子マネーの種類を前記ユーザ端末のユーザへ通知すると共に決済の承認操作を受け付けるものであってもよい。

このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザが特定の種類の電子マネーによる決済の実行を拒否することが可能となる。

また、本発明は、上記情報処理システムの発明を情報処理装置、ユーザ端末、情報処理方法およびプログラムの側面から捉えたものであってもよい。

上記情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させることが無い。

図１は、実施形態に係る情報処理システムの構成図の一例である。 図２は、サーバ及び携帯端末に実現される機能ブロックを示した図の一例である。 図３は、実施形態に係る情報処理システムによって実現される電子マネー決済代行サービスの全体像を示した図の一例である。 図４は、サーバが実現する処理フローを示した図の一例である。 図５は、携帯端末が実現する処理フローを示した図の一例である。 図６は、上記実施形態に係る情報処理システムのサーバ及び携帯端末によって実現される電子マネー決済代行サービスの全体的な処理の流れを示した図である。 図７は、変形例において携帯端末が実現する処理フローを示した図の一例である。 図８は、残高管理テーブルの一例を示した図である。 図９は、オフライン時の電子マネー決済代行サービスの全体的な処理の流れを示した図である。 図１０は、サーバが実行する処理に追加される処理フローを示した図の一例である。 図１１は、携帯端末が実行する処理に追加される処理フローを示した図の一例である。 図１２は、携帯端末の表示画面に表示される画面の一例である。 図１３は、電子マネーの種類を選択する処理の全体的な流れを示した図である。 図１４は、電子マネーの種類の選定に用いるアルゴリズムの第１例をイメージした図である。 図１５は、電子マネーの種類の選定に用いるアルゴリズムの第２例をイメージした図である。 図１６は、電子マネーの種類の選定に用いるアルゴリズムの第３例をイメージした図である。 図１７は、電子マネーの種類の選定に用いるアルゴリズムの第４例をイメージした図である。 図１８は、携帯端末のユーザによる重み付けの手動設定をイメージした図である。 図１９は、携帯端末のユーザによって重み付けが手動設定された場合の各電子マネーの順位の一例を示した図である。

以下、実施形態について説明する。以下に示す実施形態は、単なる例示であり、本開示の技術的範囲を以下の態様に限定するものではない。

図１は、実施形態に係る情報処理システムの構成図の一例である。実施形態に係る情報処理システム１０は、図１に示すように、サーバ１（本願でいう「情報処理装置」の一例である）及び携帯端末２（本願でいう「ユーザ端末」の一例である）によって形成される。サーバ１は、後述する電子マネー決済代行サービスの実現に用いられる。サーバ１は、通信事業者が管理するネットワーク３や無線基地局４を使った公衆通信回線を経由して携帯端末２と通信可能である。サーバ１は、図示しないＣＰＵ（Central Processing Unit
）やＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ネットワーク３に繋がる通信Ｉ／Ｆ（インタフェース）、管理者用の入出力装置等を備え、コンピュータプログラムを実行することにより後述の各種機能部を実現する。

携帯端末２は、後述する電子マネー決済代行サービスの実現に用いられる。携帯端末２は、ユーザが持ち歩き可能で、店舗等に設置される電子マネー用のリーダーライタ５と近距離無線通信が可能な情報処理装置である。ユーザが持ち歩き可能で、リーダーライタ５と近距離無線通信が可能な情報処理装置例としては、例えば、Ｆｅｌｉｃａ（登録商標）等の近距離無線通信技術が搭載されたスマートフォンが挙げられる。リーダーライタ５と携帯端末２との間で取り交わされる近距離無線通信は、例えば、所定の暗号鍵等を用いた数ｃｍ程度の距離のセキュアな無線通信である。携帯端末２は、図示しないＣＰＵやＲＡＭ、ＲＯＭ、バッテリー、タッチパネル付きの液晶表示装置、無線基地局４やリーダーライタ５と無線通信を行う通信回路等を備え、コンピュータプログラムを実行することにより後述の各種機能部を実現する。

図２は、サーバ１及び携帯端末２に実現される機能ブロックを示した図の一例である。サーバ１は、コンピュータプログラムを実行し、口座管理部Ｆ１Ａやバリュー生成部Ｆ１Ｂを実現する。また、携帯端末２は、コンピュータプログラムを実行し、電子マネー特定部Ｆ２Ａや決済部Ｆ２Ｂを実現する。口座管理部Ｆ１Ａは、携帯端末２のユーザの口座を管理する機能を主に司る。また、バリュー生成部Ｆ１Ｂは、口座管理部Ｆ１Ａによって管理されるお金を基にバリューを生成する機能を主に司る。また、電子マネー特定部Ｆ２Ａは、電子マネーのリーダーライタから受信した情報を基に、リーダーライタ５で決済する電子マネーの種類を特定する機能を主に司る。また、決済部Ｆ２Ｂは、バリュー生成部Ｆ１Ｂが生成したバリューを基に、リーダーライタ５における決済処理を主に司る。

本実施形態において、バリューの加算や減算に際しては、バリューの取扱い権限を示す暗号鍵に基づいて所定の暗号化がされる。サーバ１や携帯端末２は、バリューの加算や減算に際して正当性を判定し、正当であると判定した場合に限り、当該指示に従った処理を
実行する。正当性は、例えば、所定の暗号鍵で所定の暗号化がされていることをもって判定される。なお、本願においてバリューとは、貨幣価値に対応させた電子情報であり、例えば、サーバ１と携帯端末２とリーダーライタ５との間で移動可能な貨幣価値である。

図３は、実施形態に係る情報処理システム１０によって実現される電子マネー決済代行サービスの全体像を示した図の一例である。情報処理システム１０によって実現される電子マネー決済代行サービスでは、サーバ１と携帯端末２が連携し、サーバ１または外部サーバによって入出金等が管理される銀行口座２０及びお財布用口座３０（本願でいう「口座」の一例である）と、携帯端末２のアプリケーション（以下、単に「アプリ」という）２ＡＰとを用いた電子マネーの決済が行われる。情報処理システム１０によって実現される電子マネー決済代行サービスは、各電子マネー事業者が提供する複数の電子マネーを使った決済を可能にする。情報処理システム１０によって実現される電子マネー決済代行サービスにおいて決済を可能にできる電子マネーとしては、例えば、ＳｕｉｃａやＥｄｙ、ｎａｎａｃｏ等（何れも登録商標）が挙げられる。実施形態に係る情報処理システム１０によって実現される電子マネー決済代行サービスでは、携帯端末２がリーダーライタ５に翳されると、携帯端末２のアプリ２ＡＰが、当該リーダーライタ５で決済可能な電子マネーで決済を行う。また、アプリ２ＡＰによる決済の実行に伴って、当該決済に関わるバリューと預金との交換がお財布用口座３０で行われる。なお、お財布用口座３０は、電子マネーを用いた日常的な決済に用いられるお金が預金される口座である。ユーザは、例えば、お財布用口座３０に預けるお金を銀行口座２０よりも少額にしておくことで、携帯端末２を紛失した場合の被害額を抑制することができる。しかし、本実施形態に係る情報システム１０は、ユーザが銀行口座２０とお財布用口座３０の２つの口座を持つことを前提としたものに限定されるものではない。本実施形態に係る情報システム１０は、例えば、銀行口座２０を管理しないサーバ１が後述の電子マネー決済代行サービスを実現してもよいし、お財布用口座３０を介さずに銀行口座２０の預金で電子マネーの決済が行われるようにしてもよい。

図４は、サーバ１が実現する処理フローを示した図の一例である。サーバ１は、携帯端末２から情報を受信したか否かの判定を行う（Ｓ１０１）。サーバ１は、電子マネーの種類や決済に係る金額、携帯端末２のユーザが使用するお財布用口座３０の情報（以下、単に「使用口座情報」という）に関する情報を受信した場合、ステップＳ１０１で肯定判定を行う。

サーバ１は、ステップＳ１０１の処理で肯定判定を行った場合、お財布用口座３０から決済に係る金額と等価な額の預金の払出処理を実行する（Ｓ１０２）。例えば、サーバ１自身がお財布用口座３０の入出金を管理している場合、サーバ１は、ステップＳ１０２の処理において、携帯端末２のユーザが使用するお財布用口座３０の預金額を、決済に係る金額と等価な額だけ減らす。また、例えば、外部サーバがお財布用口座３０の入出金を管理している場合、サーバ１は、ステップＳ１０２の処理において、携帯端末２のユーザが使用するお財布用口座３０の預金額を、決済に係る金額と等価な額だけ減らすよう当該外部サーバへ命令する。預金の払出処理は、主に口座管理部Ｆ１Ａで実行される。

サーバ１は、ステップＳ１０２の処理を実行した後、お財布用口座３０からの払出に成功したか否かの判定処理を実行する（Ｓ１０３）。実施形態に係る情報処理システム１０によって実現される電子マネー決済代行サービスにおいて、携帯端末２のユーザに対するお金の一時的な貸付が認められない場合、ステップＳ１０３では、例えば、携帯端末２のユーザが使用するお財布用口座３０の預金額が、決済に係る金額を上回っていることを判定条件の一つにすることができる。

サーバ１は、ステップＳ１０３で肯定判定を行った場合、お財布用口座３０から減額さ
れた預金額と等価な電子マネーのバリューを生成する（Ｓ１０４）。そして、サーバ１は、ステップＳ１０４で生成したバリューを携帯端末２のアプリ２ＡＰへ送信する（Ｓ１０５）。一方、サーバ１は、ステップＳ１０３で否定判定を下した場合、決済不能である旨を示すエラー情報を携帯端末２へ送信する（Ｓ１０６）。バリューの生成は、主にバリュー生成部Ｆ１Ｂで実行される。

図５は、携帯端末２が実現する処理フローを示した図の一例である。携帯端末２は、リーダーライタ５から送信される電波を受信したか否かの判定を行う（Ｓ２０１）。携帯端末２は、リーダーライタ５から送信される電波を受信した場合、ステップＳ２０１で肯定判定を行う。

携帯端末２は、ステップＳ２０１で肯定判定を行った場合、リーダーライタ５から送信される電波の情報を基に、当該リーダーライタ５が決済を要求する電子マネーの種類を判別する（Ｓ２０２）。リーダーライタ５から送信される電波の情報には、当該リーダーライタ５で決済可能な電子マネーの種別に関する情報等が含まれる。そこで、携帯端末２は、リーダーライタ５から送信される電波の情報を基に、当該リーダーライタ５が決済を要求する電子マネーの種類の判別を行う。電子マネーの種類の判別は、主に電子マネー特定部Ｆ２Ａで実行される。

携帯端末２は、ステップＳ２０２で電子マネーの種類が判明した場合、当該リーダーライタ５が決済を要求する電子マネーの種類や決済に係る金額の情報を、使用口座情報と共にサーバ１へ送信する（Ｓ２０３）。

携帯端末２は、ステップＳ２０３の処理を行った後、サーバ１からバリューを受信したか否かの判定を行う（Ｓ２０４）。そして、携帯端末２は、ステップＳ２０４の処理で肯定判定を行った場合、サーバ１から受信したバリューをリーダーライタ５へ送信する（Ｓ２０５）。また、携帯端末２は、ステップＳ２０４の処理で否定判定を行った場合、サーバ１からエラー情報を受信したか否かの判定を行う（Ｓ２０６）。携帯端末２は、ステップＳ２０６の処理で肯定判定を行った場合、エラー情報をリーダーライタ５へ送信する（Ｓ２０７）。バリューのリーダーライタ５への送信は、主に決済部Ｆ２Ｂで実行される。

なお、上記実施形態ではサーバ１が使用口座情報を基に携帯端末２のユーザが使用するお財布用口座３０を特定しているが、本実施形態はこのような形態に限定されるものではない。サーバ１は、例えば、各携帯端末２に付与されている固有の情報、各携帯端末２にインストールされている各アプリ２ＡＰに各々付与されている固有の情報、アプリ２ＡＰに登録されたユーザＩＤ、その他の各種情報に基づいてユーザが使用するお財布用口座３０を特定するようにしてもよい。

図６は、上記実施形態に係る情報処理システム１０のサーバ１及び携帯端末２によって実現される電子マネー決済代行サービスの全体的な処理の流れを示した図である。例えば、店舗等で買い物をしたいユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ５から電波が送信される（ＳＡ１）。リーダーライタ５に翳された携帯端末２は、リーダーライタ５の電波を受信すると、上述したステップＳ２０１及びステップＳ２０２の処理で肯定判定を行った後にステップＳ２０３の処理を実行し、リーダーライタ５が決済を要求する電子マネーの種類や決済に係る金額の情報を、使用口座情報と共にサーバ１へ送信する（ＳＡ２）。

携帯端末２から送信された情報を受信したサーバ１は、ステップＳ１０１の処理で肯定判定を行った後にステップＳ１０２の処理を実行し、お財布用口座３０から決済に係る金額と等価な額の預金の払出処理を実行する（ＳＡ３）。お財布用口座３０を管理するサー
バでは、サーバ１が携帯端末２から受信した決済に係る金額の情報や使用口座情報を基に、お財布用口座３０の預金を払い出す処理が実行される（ＳＡ４）。そして、サーバ１は、お財布用口座３０を管理するサーバにおける払い出しの処理結果を取得し、ステップＳ１０３で肯定判定を行う（ＳＡ５）。なお、払出処理の結果の取得に際しては、例えば、お財布用口座３０の残高が携帯端末２へ通知されるようにしてもよい。サーバ１は、ステップＳ１０３で肯定判定を行った後にステップＳ１０４を実行し、お財布用口座３０から払い出された額と等価な電子マネーのバリューを生成する（ＳＡ６）。ステップＳＡ６で生成されるバリューは、ステップＳＡ２で携帯端末２から通知された電子マネーの種類に対応するバリューである。サーバ１は、ステップＳ１０４でバリューを生成した後にステップＳ１０５を実行し、生成したバリューを携帯端末２へ送信する（ＳＡ７）。

サーバ１から送信されたバリューを受信した携帯端末２は、ステップＳ２０４の処理で肯定判定を行った後にステップＳ２０５の処理を実行し、サーバ１から受信したバリューをリーダーライタ５へ送信する（ＳＡ８）。サーバ１から受信したバリューが携帯端末２を通じてリーダーライタ５へ送信されることにより、リーダーライタ５が繋がる店舗のレジスターでは電子マネーによる決済が執り行われる。そして、電子マネーの事業者において諸々の事務処理が行われ、お財布用口座３０から払い出されたお金が最終的に店舗の事業者へ支払われる。

上記実施形態において実現される電子マネー決済代行サービスであれば、ユーザが加入していると否とに関わらず、情報処理システム１０で取扱い可能なあらゆる電子マネー事業者の電子マネーをユーザが利用できるため、店頭に置かれたリーダーライタ５がユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していてユーザの電子マネーカードでは決済不能な場合であっても、電子マネーによる決済が可能である。また、上記実施形態において実現される電子マネー決済代行サービスでは基本的にバリューの蓄積が不要なので、例えば、様々な電子マネーに対応可能とするべく各電子マネー事業者のサービスに加入したような場合に生ずる、残存するバリューが増えすぎるという不合理が生じることもない。

＜オフライン処理を可能にする場合の変形例＞
ところで、上記実施形態では、オンライン処理を前提としていた。しかし、上述の情報処理システム１０によって実現される電子マネー決済代行サービスは、オフライン処理を可能にするものであってもよい。以下、オフライン処理を可能にする場合の変形例について、上記実施形態との相違点を中心に説明する。

上述の情報処理システム１０においてオフライン処理を可能にする場合、基本的に携帯端末２における処理が上述と少々異なる。図７は、本変形例において携帯端末２が実現する処理フローを示した図の一例である。本変形例において、上述の実施形態と同様の処理については同一の符号を付し、その詳細な説明を省略する。

携帯端末２は、上述のステップＳ２０２で電子マネーの種類が判明した場合、携帯端末２が無線基地局４と通信可能な電波の圏内か否かの判定を行う（Ｓ２０２−１）。携帯端末２は、ステップＳ２０２−１で肯定判定を行った場合、上述したステップＳ２０３以降の処理を実行する。一方、携帯端末２は、ステップＳ２０２−１で否定判定を行った場合、携帯端末２のメモリに記憶されている残高管理テーブルを更新し、残高管理テーブルの残高を減算する（Ｓ２０２−２）。

図８は、残高管理テーブルの一例を示した図である。本変形例においては、例えば、図８に示すような、電子マネーの種類や決済番号、決済が行われた日時、決済額等の決済情
報と残高とを記録する残高管理テーブルが携帯端末２のメモリに記憶される。そして、例えば、ステップＳ２０２−１で否定判定が行われた場合、携帯端末２は、リーダーライタ５から送信された情報を残高管理テーブルへ記録すると共に、残高管理テーブルに記録されている残高から決済額を減算する。

携帯端末２は、ステップＳ２０２−２の処理を実行した後、残高管理テーブルの残高から減算された額（本願でいう「負債額」の一例である）と等価な電子マネーのバリューを生成する（Ｓ２０２−３）。携帯端末２は、ステップＳ２０２−３の処理を実行した後、上述したステップＳ２０５以降の処理を実行する。

携帯端末２は、上述のステップＳ２０１で否定判定を行った場合、次に、残高管理テーブルの残高がマイナスであるか否かの判定を行う（Ｓ２０２−４）。携帯端末２は、ステップＳ２０２−４の処理で肯定判定を行った場合、次に、携帯端末２が無線基地局４と通信可能な電波の圏内に居るか否かの判定を行う（Ｓ２０２−５）。携帯端末２は、ステップＳ２０２−５の処理で肯定判定を行った場合、残高管理テーブルに記録されている各決済の情報を、使用口座情報と共にサーバ１へ送信する（Ｓ２０２−６）。携帯端末２は、ステップＳ２０２−６の処理を行った後、サーバ１からバリューを受信したか否かの判定を行う（Ｓ２０２−７）。そして、携帯端末２は、ステップＳ２０２−７の処理で肯定判定を行った場合、サーバ１から受信したバリューを基に、残高管理テーブルに記録されている決済情報を消去する（本願でいう「解消処理」の一例である）と共に残高を加算する（Ｓ２０２−８）。

図９は、オフライン時の電子マネー決済代行サービスの全体的な処理の流れを示した図である。例えば、店舗等で買い物をしたユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ５から電波が送信される（ＳＢ１）。リーダーライタ５に翳された携帯端末２は、リーダーライタ５の電波を受信すると、上述したステップＳ２０１及びステップＳ２０２の処理で肯定判定を行った後にステップＳ２０２−１で否定判定を行い、ステップＳ２０２−２とステップＳ２０３−３の処理を実行してバリューを生成する。そして、携帯端末２は、ステップＳ２０５の処理を実行し、携帯端末２で生成したバリューをリーダーライタ５へ送信する（ＳＢ２）。携帯端末２で生成されたバリューがリーダーライタ５へ送信されることにより、リーダーライタ５が繋がる店舗のレジスターでは電子マネーによる決済が執り行われる。

また、携帯端末２のユーザが店舗から離れて移動し、携帯端末２が無線基地局４と通信可能な電波の圏内に入ると、携帯端末２は、ステップＳ２０２−４及びステップＳ２０２−５の処理で肯定を行う。そして、携帯端末２は、ステップＳ２０２−６の処理を実行し、残高管理テーブルに記録されている各決済の情報を、使用口座情報と共にサーバ１へ送信する（ＳＢ３）。

ステップＳ２０２−６の処理の実行により、携帯端末２から送信された情報を受信したサーバ１では、ステップＳ１０１からステップＳ１０５までの一連の処理が実行される。すなわち、携帯端末２から送信された情報を受信したサーバ１は、ステップＳ１０１の処理で肯定判定を行った後にステップＳ１０２の処理を実行し、お財布用口座３０から決済に係る金額と等価な額の預金の払出処理を実行する（ＳＢ４）。そして、お財布用口座３０を管理するサーバでは、サーバ１が携帯端末２から受信した決済に係る金額の情報や使用口座情報を基に、お財布用口座３０の預金を払い出す処理が実行される（ＳＡ４）。そして、サーバ１は、お財布用口座３０を管理するサーバにおける払い出しの処理結果を取得し、ステップＳ１０３で肯定判定を行う（ＳＢ５）。そして、サーバ１は、ステップＳ１０４を実行し、お財布用口座３０から払い出された額と等価な電子マネーのバリューを
生成する（ＳＢ６）。そして、サーバ１は、ステップＳ１０５を実行し、生成したバリューを携帯端末２へ送信する（ＳＢ７）。

ステップＳ１０５の処理の実行により、サーバ１から送信されたバリューを受信した携帯端末２では、ステップＳ２０２−７で肯定判定が行われてステップＳ２０２−８の処理が実行され、の処理で肯定判定を行った場合、サーバ１から受信したバリューを基に、残高管理テーブルに記録されている決済情報を消去すると共に残高を加算する（Ｓ２０２−８）。残高管理テーブルに記録されている全ての決済情報が消去されると、残高管理テーブルに記録されている残高がゼロになる（ＳＢ８）。

本変形例によれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、携帯端末２がサーバ１にアクセスできない状態においても滞りなく電子マネーの決済を行うことができる。なお、本変形例では、残高管理テーブルの残高の制限に触れられていないが、本変形例は、例えば、残高管理テーブルの残高に下限値が設定されており、下限値を下回る場合は携帯端末２におけるバリューの生成が中止されるようにしてもよい。下限値は、例えば、携帯端末２のユーザが有する銀行口座の残高や電子マネーの利用実績、その他の各種の情報に基づいて動的に設定される値であってもよいし、或いは一律に設定される値であってもよい。

＜決済に用いる電子マネーの種類の選択＞
ところで、上記実施形態では、リーダーライタ５が複数種類の電子マネーの決済に対応可能な場合に、決済に用いる電子マネーの種類を選択することに言及されていなかった。上記の情報処理システム１０によって実現される電子マネー決済代行サービスは、リーダーライタ５が複数種類の電子マネーの決済に対応可能な場合に、決済に用いる電子マネーの種類を以下のように選択してもよい。

上記の情報処理システム１０によって実現される電子マネー決済代行サービスにおいて、決済に用いる電子マネーの種類を選択する処理を行う場合、サーバ１及び携帯端末２が実行する処理に以下のような処理が加わる。

図１０は、サーバ１が実行する処理に追加される処理フローを示した図の一例である。サーバ１は、リーダーライタ５で使用可能な電子マネーが複数種類あるか否かを、携帯端末２から送信される情報を基に判定する（Ｓ１００１）。サーバ１は、ステップＳ１００１の処理で肯定判定を行った場合、決済に用いることを推奨する電子マネーの種類を選定し、選定した一又は複数の電子マネーの種類に関する情報を携帯端末２へ通知する（Ｓ１００２）。サーバ１は、ステップＳ１００１の処理で否定判定を行った場合、又はステップＳ１００２の処理を実行した後、上述したステップＳ１０１以降の一連の処理を実行する。

図１１は、携帯端末２が実行する処理に追加される処理フローを示した図の一例である。携帯端末２は、リーダーライタ５で使用可能な電子マネーが複数種類あるか否かを、リーダーライタ５から送信される電波の情報を基に判定する（Ｓ２００１）。携帯端末２は、ステップＳ２００１の処理で肯定判定を行った場合、リーダーライタ５から受信した情報をサーバ１へ送信する（Ｓ２００２）。携帯端末２は、ステップＳ２００２の処理を実行した後、サーバ１から送られる情報を受信したか否かの判定を行う（Ｓ２００３）。携帯端末２は、サーバ１が選定した一又は複数の電子マネーの種類に関する情報を取得することにより、ステップＳ２００３の処理で肯定判定を行った場合、決済に用いる電子マネーの種別を決定する（Ｓ２００４）。図１２は、携帯端末２の表示画面に表示される画面の一例である。決済に用いる電子マネーの種別の決定は、例えば、図１２に示す携帯端末２の表示画面のように、サーバ１が選定した一又は複数の電子マネーの種類が表示され、
携帯端末２のユーザによる選択操作によって決定されてもよいし、或いは、サーバ１が選定した一又は複数の電子マネーの種類の中でサーバ１の推奨度が最も高いものが自動的に決定されてもよい。携帯端末２は、ステップＳ２００４の処理を実行した後、決済に用いることが決定された電子マネーの種類をリーダーライタ５へ通知する（Ｓ２００５）。

図１３は、電子マネーの種類を選択する処理の全体的な流れを示した図である。例えば、店舗等で買い物をしたいユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ５から電波が送信される（ＳＣ１）。当該リーダーライタ５が複数種類の電子マネーに対応可能な場合、当該リーダーライタ５からは各電子マネーのプロトコルに各々従った各種の電波が交互に送信される。リーダーライタ５に翳された携帯端末２は、リーダーライタ５の電波を受信すると、上述したステップＳ２００１の処理で肯定判定を行った後にステップＳ２００２の処理を実行し、当該リーダーライタ５で決済可能な電子マネーの情報をサーバ１へ送信する（ＳＣ２）。

携帯端末２から送信された情報を受信したサーバ１は、ステップＳ１００１の処理で肯定判定を行った後にステップＳ１００２の処理を実行し、決済に用いることを推奨する電子マネーの種類を選定し、選定した一又は複数の電子マネーの種類に関する情報を携帯端末２へ通知する（ＳＣ３）。

サーバ１から送信された情報を受信した携帯端末２は、ステップＳ２００３の処理で肯定判定を行った後にステップＳ２００４の処理を実行し、決済に用いる電子マネーの種別を決定する（ＳＣ４）。携帯端末２は、ステップＳ２００４の処理で決済に用いる電子マネーの種別を決定した後に、決済に用いることが決定された電子マネーの種類をリーダーライタ５へ通知する（ＳＣ５）。以降は、図６に示したステップＳＡ１からステップＳＡ８までの処理と同様の処理が行われる。

本変形例によれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタ５が様々な電子マネーに対応可能な場合であっても電子マネーで速やかに決済を行うことが可能となる。

なお、決済に用いる電子マネーの種類の選定は、サーバ１を介さずに携帯端末２単体で行われるようにしてもよい。

＜電子マネーの種類の選定＞
ところで、上述の説明においては、決済に用いることを推奨する電子マネーの種類の選定方法について詳述しなかったが、サーバ１がステップＳ１００２の処理を実行する際は、例えば、携帯端末２に予め設定された順位に従って電子マネーの種類が設定されてもよいし、或いは、以下のようなアルゴリズムに従って電子マネーの種類を選定するようにしてもよい。

＜アルゴリズムの第１例＞
図１４は、電子マネーの種類の選定に用いるアルゴリズムの第１例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、携帯端末２のユーザが利用する店舗の利用履歴に基づいた選定方法が挙げられる。例えば、携帯端末２のユーザが利用する店舗の使用回数が図１４の「１、お客さま利用履歴テーブル」のような形態で、サーバ１がアクセス可能なデータベースに保存されており、また、利用者に対し決済額に応じて付与される特典ポイントの付与対象となる電子マネーの種別の店舗毎の情報が図１４の「２、店舗情報テーブル」のような形態でデータベースに保存されている場合、サーバ１は、ステップＳ１００２の処理において「１、お客さま利用履歴
テーブル」及び「２、店舗情報テーブル」を照会して、ユーザが過去に電子マネーを決済で使用可能だった回数（以下、「使用可能回数」という）を電子マネーの種別毎に算出し、算出した使用可能回数に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップＳ１００２の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、店舗の利用実績の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。

＜アルゴリズムの第２例＞
図１５は、電子マネーの種類の選定に用いるアルゴリズムの第２例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、電子マネーの利用履歴に基づいた選定方法が挙げられる。例えば、携帯端末２のユーザが過去の決済で利用した電子マネーの利用金額の合計を、サーバ１がアクセス可能なデータベースの情報を基に特定できる場合、サーバ１は、携帯端末２のユーザが過去の決済で利用した各電子マネーの合計利用金額に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップＳ１００２の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、電子マネーの利用実績の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。なお、電子マネーの利用履歴に基づいた選定方法としては、携帯端末２のユーザが過去の決済で利用した電子マネーの利用金額の合計に基づく選定方法のみならず、例えば、携帯端末２のユーザが過去の決済で電子マネーを利用することにより蓄積されたポイントの合計に基づく選定方法が挙げられる。

＜アルゴリズムの第３例＞
図１６は、電子マネーの種類の選定に用いるアルゴリズムの第３例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、ポイントの還元率に基づいた選定方法が挙げられる。例えば、上記実施形態に係る情報処理システム１０が実現する電子マネー決済代行サービスで決済可能な各電子マネーのポイント還元率の情報が、サーバ１がアクセス可能なデータベースに格納されている場合、サーバ１は、電子マネーのポイント還元率に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップＳ１００２の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、ポイント還元率の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。

＜アルゴリズムの第４例＞
図１７は、電子マネーの種類の選定に用いるアルゴリズムの第４例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、上記第１例から第３例までの何れかに限定されるものでなく、例えば、携帯端末２のユーザが利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率の３つの要素を用いたアルゴリズム、換言すると、上記第１例から第３例までの３つのアルゴリズムを組み合わせたアルゴリズムに従う選定方法が挙げられる。上記第１例から第３例までの３つのアルゴリズムを組み合わせる場合、図１７の「偏差値まとめテーブル」に示されるように、携帯端末２のユーザが利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率の３つの要素のそれぞれについて、電子マネーの種別毎に偏差値が得られる。サーバ１は、３つの要素のそれぞれの偏差値を基にした総合的な電子マネーの順位付けを行うことが可能である。ステップＳ１００２の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、自身が利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率という３つの要素を総合して最も適切な電子マネーを容易に選ぶことができる。

なお、このように複数の要素を用いたアルゴリズムに従って電子マネーの順位付けを行う場合、各要素の重み付けは、均等であってもよいし、サーバ１が所定のアルゴリズムに従って自動的に設定されてもよいし、携帯端末２のユーザが好みに応じて手動で設定されてもよい。図１８は、携帯端末２のユーザによる重み付けの手動設定をイメージした図である。重み付けの手動設定の方法としては、例えば、図１８に示される様に、携帯端末２等に表示される設定画面でユーザ操作を受け付け、要素毎の重み付けの設定操作を受け付け可能にすることが考えられる。なお、図１８の設定画面の例では、店舗の利用履歴については重み付けが低く、電子マネーの利用履歴については重み付けが中程度とされ、ポイント還元率については重み付けが高くされるように設定されている。

図１９は、携帯端末２のユーザによって重み付けが手動設定された場合の各電子マネーの順位の一例を示した図である。例えば、図１８の設定画面で「低」に設定された要素の重要度の値を「０」、「中」に設定された要素の重要度の値を「１」、「高」に設定された要素の重要度の値を「２」と仮定する。そして、設定された各要素の重要度の値に各要素の偏差値を乗算したものの合計値を当該電子マネーの総合点数として定め、総合点数順に各電子マネーの順位付けを行うと、サーバ１は、例えば、図１９に示されるような順位付けの結果を得ることが可能である。ステップＳ１００２の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、自身が利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率という３つの要素を、自身が任意に設定した重み付けに従って総合することにより選定された最も適切な電子マネーを容易に選ぶことができる。

＜その他のアルゴリズム＞
決済に用いる電子マネーの種類の選定に関しては、上記アルゴリズムに限定されるものでなく、その他の様々なものを適用できる。決済に用いる電子マネーの種類のその他の選定方法としては、例えば、複数の電子マネー間のポイント変換率に基づいた選定方法が挙げられる。例えば、各電子マネー間のポイント変換率の情報が、サーバ１がアクセス可能なデータベースに格納されている場合、サーバ１は、各電子マネー間のポイント変換率を基に各電子マネーを順位付けすることが可能である。電子マネー間のポイント変換率に基づく順位付けが行われれば、リーダーライタ５における電子マネーの決済に際し、ユーザは、例えば、普段利用している電子マネーでは決済不能の場合に、決済可能な幾つかの電子マネーの中から、普段利用している電子マネーへのポイントの変換率が最も高い電子マネーを容易に選ぶことができる。

＜その他の変形例＞
ところで、上記実施形態や各変形例においては、電子マネーによる決済に際し、携帯端末２のユーザに対する決済の意思確認が特になされていなかった。よって、上記実施形態や各変形例では、情報処理システム１０で取扱い可能な種類の電子マネーであれば、ユーザの意思に関わらず決済が実行される。しかし、上記実施形態や各変形例は、決済の実行前に、ユーザによる決済の可否の承認操作が行われるようにしてもよい。このような処理が行われる場合、ユーザは、例えば、特定の種類の電子マネーによる決済の実行を拒否することが可能となる。

また、上記実施形態や各変形例においては、物理的に実在する店舗における電子マネーの決済を前提としていたが、上記実施形態や各変形例は、例えば、インターネットに接続可能なコンピュータ端末を使い、インターネット上の仮想店舗で支払を行う際、当該コンピュータ端末に設けられるリーダーライタを通じて行う電子マネーの決済に用いられてもよい。

１０・・情報処理システム：１・・サーバ：２・・携帯端末：３・・ネットワーク：４・・無線基地局：５・・リーダーライタ：Ｆ１Ａ・・口座管理部：Ｆ１Ｂ・・バリュー生成部：Ｆ２Ａ・・電子マネー特定部：Ｆ２Ｂ・・決済部：２０・・銀行口座：３０・・お財布用口座：２ＡＰ・・アプリ

Claims (14)

1. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、
   前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、
   前記口座管理手段によって前記口座から減算される金額を基に、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、
   前記バリュー生成手段が生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済手段と、を備える、
   情報処理システム。
2. 前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、
   前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末から前記公衆通信回線を通じて送られる前記決済額の情報を取得すると前記減算処理を実行し、
   前記バリュー生成手段は、前記減算処理が実行されると前記バリューを生成し、
   前記決済手段は、前記ユーザ端末に設けられており、前記バリュー生成手段によって生成された前記バリューを前記公衆通信回線経由で取得すると、取得した前記バリューを基に前記決済処理を実行する、
   請求項１に記載の情報処理システム。
3. 前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、
   前記決済手段は、前記ユーザ端末に設けられており、前記ユーザ端末が前記公衆通信回線により通信不能な状態で前記決済処理を実行する際は前記決済額に相当する負債額の情報を前記ユーザ端末に蓄積し、
   前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末に前記負債額の情報があることを前記公衆通信回線経由で前記ユーザ端末から検知すると、前記負債額に対応する金額の前記減算処理を実行し、
   前記バリュー生成手段は、前記減算処理が実行されると、前記バリューの生成処理と共に、前記ユーザ端末に情報として格納されている前記負債額の解消処理を実行する、
   請求項１または２に記載の情報処理システム。
4. 前記ユーザ端末には、複数種の電子マネーについての優先順位を定めた順位情報が記憶されており、
   前記電子マネー特定手段は、前記ユーザ端末に設けられており、前記リーダーライタで決済可能な電子マネーが複数種ある場合は前記順位情報を基に前記リーダーライタで決済する電子マネーの種類を特定する、
   請求項１から３の何れか一項に記載の情報処理システム。
5. 前記電子マネー特定手段は、前記リーダーライタで決済可能な電子マネーが複数種ある場合は、前記ユーザ端末のユーザが利用する店舗の利用履歴、電子マネーの利用履歴、電子マネーのポイント還元率、複数の電子マネー間のポイント変換率の少なくとも何れかを用いて特定された順位を基に、前記リーダーライタで決済する電子マネーの種類を特定す
   る、
   請求項１から３の何れか一項に記載の情報処理システム。
6. 前記電子マネー特定手段は、前記リーダーライタで決済する電子マネーの種類を特定すると、特定した電子マネーの種類を前記ユーザ端末のユーザへ通知すると共に決済の承認操作を受け付ける、
   請求項１から５の何れか一項に記載の情報処理システム。
7. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、
   前記口座管理手段によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成手段と、を備える、
   情報処理装置。
8. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、
   前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済手段と、を備える、
   ユーザ端末。
9. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
   前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
   前記口座管理処理によって前記口座から減算される金額を基に、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成処理と、
   前記バリュー生成処理で生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、を情報処理システムが実行する、
   情報処理方法。
10. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
    前記口座管理処理によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成処理と、を情報処理装置が実行する、
    情報処理方法。
11. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
    前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、をユーザ端末が実行する、
    情報処理方法。
12. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
    前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
    前記口座管理処理によって前記口座から減算される金額を基に、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成処理と、
    前記バリュー生成処理で生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、を情報処理システムに実行させる、
    情報処理プログラム。
13. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
    前記口座管理処理によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成処理と、を情報処理装置に実行させる、
    情報処理プログラム。
14. 電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
    前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、をユーザ端末に実行させる、
    情報処理プログラム。