特開2017-4256(P2017-4256A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社 ゆうちょ銀行の特許一覧

特開2017-4256情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム
<>
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000003
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000004
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000005
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000006
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000007
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000008
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000009
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000010
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000011
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000012
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000013
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000014
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000015
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000016
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000017
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000018
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000019
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000020
  • 特開2017004256-情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム 図000021
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2017-4256(P2017-4256A)
(43)【公開日】2017年1月5日
(54)【発明の名称】情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラム
(51)【国際特許分類】
   G06Q 20/06 20120101AFI20161209BHJP
   G06K 19/07 20060101ALI20161209BHJP
   G07G 1/12 20060101ALI20161209BHJP
   G07G 1/14 20060101ALI20161209BHJP
【FI】
   G06Q20/06 120
   G06K19/07 270
   G07G1/12 321P
   G07G1/14
【審査請求】未請求
【請求項の数】14
【出願形態】OL
【全頁数】21
(21)【出願番号】特願2015-117567(P2015-117567)
(22)【出願日】2015年6月10日
(71)【出願人】
【識別番号】507417422
【氏名又は名称】株式会社 ゆうちょ銀行
(74)【代理人】
【識別番号】100100549
【弁理士】
【氏名又は名称】川口 嘉之
(74)【代理人】
【識別番号】100113608
【弁理士】
【氏名又は名称】平川 明
(72)【発明者】
【氏名】秋山 陽太
【テーマコード(参考)】
3E142
5L055
【Fターム(参考)】
3E142CA17
3E142FA10
3E142GA16
3E142HA13
3E142JA03
5L055AA15
(57)【要約】
【課題】本願は、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させない技術を提供することを課題とする。
【解決手段】情報処理システムであって、電子マネーのリーダーライタに翳されたユーザ端末がリーダーライタから受信した情報を基に、リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、ユーザ端末がリーダーライタから受信した情報に含まれる決済額の情報を基に、ユーザ端末のユーザの口座の残高から決済額に相当する金額を減算処理する口座管理手段と、口座管理手段によって口座から減算される金額を基に、電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、バリュー生成手段が生成するバリューを基に、リーダーライタにおけるユーザ端末側の決済処理を実行する決済手段と、を備える。
【選択図】図6
【特許請求の範囲】
【請求項1】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、
前記口座管理手段によって前記口座から減算される金額を基に、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、
前記バリュー生成手段が生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済手段と、を備える、
情報処理システム。
【請求項2】
前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、
前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末から前記公衆通信回線を通じて送られる前記決済額の情報を取得すると前記減算処理を実行し、
前記バリュー生成手段は、前記減算処理が実行されると前記バリューを生成し、
前記決済手段は、前記ユーザ端末に設けられており、前記バリュー生成手段によって生成された前記バリューを前記公衆通信回線経由で取得すると、取得した前記バリューを基に前記決済処理を実行する、
請求項1に記載の情報処理システム。
【請求項3】
前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、
前記決済手段は、前記ユーザ端末に設けられており、前記ユーザ端末が前記公衆通信回線により通信不能な状態で前記決済処理を実行する際は前記決済額に相当する負債額の情報を前記ユーザ端末に蓄積し、
前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末に前記負債額の情報があることを前記公衆通信回線経由で前記ユーザ端末から検知すると、前記負債額に対応する金額の前記減算処理を実行し、
前記バリュー生成手段は、前記減算処理が実行されると、前記バリューの生成処理と共に、前記ユーザ端末に情報として格納されている前記負債額の解消処理を実行する、
請求項1または2に記載の情報処理システム。
【請求項4】
前記ユーザ端末には、複数種の電子マネーについての優先順位を定めた順位情報が記憶されており、
前記電子マネー特定手段は、前記ユーザ端末に設けられており、前記リーダーライタで決済可能な電子マネーが複数種ある場合は前記順位情報を基に前記リーダーライタで決済する電子マネーの種類を特定する、
請求項1から3の何れか一項に記載の情報処理システム。
【請求項5】
前記電子マネー特定手段は、前記リーダーライタで決済可能な電子マネーが複数種ある場合は、前記ユーザ端末のユーザが利用する店舗の利用履歴、電子マネーの利用履歴、電子マネーのポイント還元率、複数の電子マネー間のポイント変換率の少なくとも何れかを用いて特定された順位を基に、前記リーダーライタで決済する電子マネーの種類を特定す
る、
請求項1から3の何れか一項に記載の情報処理システム。
【請求項6】
前記電子マネー特定手段は、前記リーダーライタで決済する電子マネーの種類を特定すると、特定した電子マネーの種類を前記ユーザ端末のユーザへ通知すると共に決済の承認操作を受け付ける、
請求項1から5の何れか一項に記載の情報処理システム。
【請求項7】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、
前記口座管理手段によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成手段と、を備える、
情報処理装置。
【請求項8】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済手段と、を備える、
ユーザ端末。
【請求項9】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
前記口座管理処理によって前記口座から減算される金額を基に、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成処理と、
前記バリュー生成処理で生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、を情報処理システムが実行する、
情報処理方法。
【請求項10】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
前記口座管理処理によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成処理と、を情報処理装置が実行する、
情報処理方法。
【請求項11】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、をユーザ端末が実行する、
情報処理方法。
【請求項12】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
前記口座管理処理によって前記口座から減算される金額を基に、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成処理と、
前記バリュー生成処理で生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、を情報処理システムに実行させる、
情報処理プログラム。
【請求項13】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理処理と、
前記口座管理処理によって前記口座から減算される金額を基に、前記ユーザ端末が前記リーダーライタから受信した情報を基に特定された前記リーダーライタで決済する電子マネーの種類において定められている方式に従って生成されるバリューであり、前記リーダーライタにおける前記ユーザ端末側の決済処理の実行に用いられるバリューを生成するバリュー生成処理と、を情報処理装置に実行させる、
情報処理プログラム。
【請求項14】
電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定処理と、
前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額であり、前記ユーザ端末のユーザの口座の残高から減算される前記決済額に相当する金額を基にして生成される、前記電子マネー特定処理で特定した電子マネーの種類において定められている方式に従って生成されたバリューを基に、前記リーダーライタにおける前記ユーザ端末側の決済処理を実行する決済処理と、をユーザ端末に実行させる、
情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラムに関する。
【背景技術】
【0002】
情報通信技術の発達に伴い、電子マネーを使った決済が普及の一途を辿っている。例えば、特許文献1−5には、店舗等における決済を電子的な貨幣で取り交わす各種の技術が提案されている。(例えば、特許文献1−5を参照)。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2009−151692号公報
【特許文献2】特開2000−215258号公報
【特許文献3】特開2002−197388号公報
【特許文献4】特許第5189297号公報
【特許文献5】特開2002−259881号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
現行の電子マネーサービスでは、ユーザが加入してバリューを蓄積している電子マネー事業者の電子マネーしか利用することができないため、店頭に置かれたリーダーライタ(本願では単に「RW」と表記する場合がある)が当該ユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していて決済不能な場合がある。また、現行の電子マネーサービスでは基本的に決済に係る金額以上のバリューが蓄積されていることを前提としており、少額のバリューが残存している状態を解消することが容易でないので、様々な電子マネー事業者のサービスに加入したような場合に残存するバリューが増えすぎて不合理である。
【0005】
そこで、本願は、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させない技術を提供することを課題とする。
【課題を解決するための手段】
【0006】
上記課題を解決するため、本発明では、リーダーライタで決済可能な電子マネーの種類を特定すると、決済金額を口座の残高から減算する処理と、特定された電子マネーの種類に対応する方式で生成されたバリューを基にした当該リーダーライタにおける決済処理とを実行することにより、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないようにした。
【0007】
詳細には、情報処理システムであって、電子マネーのリーダーライタに翳されたユーザ端末が前記リーダーライタから受信した情報を基に、前記リーダーライタで決済する電子マネーの種類を特定する電子マネー特定手段と、前記ユーザ端末が前記リーダーライタから受信した情報に含まれる決済額の情報を基に、前記ユーザ端末のユーザの口座の残高から前記決済額に相当する金額を減算処理する口座管理手段と、前記口座管理手段によって前記口座から減算される金額を基に、前記電子マネー特定手段が特定した電子マネーの種類において定められている方式に従ってバリューを生成するバリュー生成手段と、前記バリュー生成手段が生成する前記バリューを基に、前記リーダーライタにおける前記ユーザ
端末側の決済処理を実行する決済手段と、を備える。
【0008】
上記の情報処理システムによって実現される電子マネー決済代行サービスであれば、ユーザが加入していると否とに関わらず、情報処理システムで取扱い可能なあらゆる電子マネー事業者の電子マネーをユーザが利用できるため、店頭に置かれたリーダーライタがユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していてユーザの電子マネーカードでは決済不能な場合であっても、電子マネーによる決済が可能である。また、上記実施形態において実現される電子マネー決済代行サービスでは基本的にバリューの蓄積が不要なので、例えば、様々な電子マネーに対応可能とするべく各電子マネー事業者のサービスに加入したような場合に生ずる、残存するバリューが増えすぎるという不合理が生じることもない。
【0009】
なお、前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末から前記公衆通信回線を通じて送られる前記決済額の情報を取得すると前記減算処理を実行し、前記バリュー生成手段は、前記減算処理が実行されると前記バリューを生成し、前記決済手段は、前記ユーザ端末に設けられており、前記バリュー生成手段によって生成された前記バリューを前記公衆通信回線経由で取得すると、取得した前記バリューを基に前記決済処理を実行するものであってもよい。
【0010】
このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザが外出先の店舗でユーザ端末を使い、滞りなく電子マネーの決済を行うことができる。
【0011】
また、前記ユーザ端末は、無線基地局に対する無線通信によって公衆通信回線を通じた通信が可能な端末であり、前記決済手段は、前記ユーザ端末に設けられており、前記ユーザ端末が前記公衆通信回線により通信不能な状態で前記決済処理を実行する際は前記決済額に相当する負債額の情報を前記ユーザ端末に蓄積し、前記口座管理手段は、前記ユーザ端末が前記公衆通信回線を通じてアクセス可能なサーバに設けられており、前記ユーザ端末に前記負債額の情報があることを前記公衆通信回線経由で前記ユーザ端末から検知すると、前記負債額に対応する金額の前記減算処理を実行し、前記バリュー生成手段は、前記減算処理が実行されると、前記バリューの生成処理と共に、前記ユーザ端末に情報として格納されている前記負債額の解消処理を実行するものであってもよい。
【0012】
このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザ端末が通信不能な状態においても滞りなく電子マネーの決済を行うことができる。
【0013】
また、前記ユーザ端末には、複数種の電子マネーについての優先順位を定めた順位情報が記憶されており、前記電子マネー特定手段は、前記ユーザ端末に設けられており、前記リーダーライタで決済可能な電子マネーが複数種ある場合は前記順位情報を基に前記リーダーライタで決済する電子マネーの種類を特定するものであってもよい。
【0014】
このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタが様々な電子マネーに対応可能な場合であっても電子マネーで速やかに決済を行うことが可能となる。
【0015】
また、前記電子マネー特定手段は、前記リーダーライタで決済可能な電子マネーが複数種ある場合は、前記ユーザ端末のユーザが利用する店舗の利用履歴、電子マネーの利用履歴、電子マネーのポイント還元率、複数の電子マネー間のポイント変換率の少なくとも何れかを用いて特定された順位を基に、前記リーダーライタで決済する電子マネーの種類を特定するものであってもよい。
【0016】
このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタが様々な電子マネーに対応可能な場合に適切な電子マネーで速やかに決済を行うことが可能となる。
【0017】
また、前記電子マネー特定手段は、前記リーダーライタで決済する電子マネーの種類を特定すると、特定した電子マネーの種類を前記ユーザ端末のユーザへ通知すると共に決済の承認操作を受け付けるものであってもよい。
【0018】
このような情報処理システムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、ユーザが特定の種類の電子マネーによる決済の実行を拒否することが可能となる。
【0019】
また、本発明は、上記情報処理システムの発明を情報処理装置、ユーザ端末、情報処理方法およびプログラムの側面から捉えたものであってもよい。
【発明の効果】
【0020】
上記情報処理システム、情報処理装置、ユーザ端末、情報処理方法及びプログラムであれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させることが無い。
【図面の簡単な説明】
【0021】
図1図1は、実施形態に係る情報処理システムの構成図の一例である。
図2図2は、サーバ及び携帯端末に実現される機能ブロックを示した図の一例である。
図3図3は、実施形態に係る情報処理システムによって実現される電子マネー決済代行サービスの全体像を示した図の一例である。
図4図4は、サーバが実現する処理フローを示した図の一例である。
図5図5は、携帯端末が実現する処理フローを示した図の一例である。
図6図6は、上記実施形態に係る情報処理システムのサーバ及び携帯端末によって実現される電子マネー決済代行サービスの全体的な処理の流れを示した図である。
図7図7は、変形例において携帯端末が実現する処理フローを示した図の一例である。
図8図8は、残高管理テーブルの一例を示した図である。
図9図9は、オフライン時の電子マネー決済代行サービスの全体的な処理の流れを示した図である。
図10図10は、サーバが実行する処理に追加される処理フローを示した図の一例である。
図11図11は、携帯端末が実行する処理に追加される処理フローを示した図の一例である。
図12図12は、携帯端末の表示画面に表示される画面の一例である。
図13図13は、電子マネーの種類を選択する処理の全体的な流れを示した図である。
図14図14は、電子マネーの種類の選定に用いるアルゴリズムの第1例をイメージした図である。
図15図15は、電子マネーの種類の選定に用いるアルゴリズムの第2例をイメージした図である。
図16図16は、電子マネーの種類の選定に用いるアルゴリズムの第3例をイメージした図である。
図17図17は、電子マネーの種類の選定に用いるアルゴリズムの第4例をイメージした図である。
図18図18は、携帯端末のユーザによる重み付けの手動設定をイメージした図である。
図19図19は、携帯端末のユーザによって重み付けが手動設定された場合の各電子マネーの順位の一例を示した図である。
【発明を実施するための形態】
【0022】
以下、実施形態について説明する。以下に示す実施形態は、単なる例示であり、本開示の技術的範囲を以下の態様に限定するものではない。
【0023】
図1は、実施形態に係る情報処理システムの構成図の一例である。実施形態に係る情報処理システム10は、図1に示すように、サーバ1(本願でいう「情報処理装置」の一例である)及び携帯端末2(本願でいう「ユーザ端末」の一例である)によって形成される。サーバ1は、後述する電子マネー決済代行サービスの実現に用いられる。サーバ1は、通信事業者が管理するネットワーク3や無線基地局4を使った公衆通信回線を経由して携帯端末2と通信可能である。サーバ1は、図示しないCPU(Central Processing Unit
)やRAM(Random Access Memory)、ROM(Read Only Memory)、ネットワーク3に繋がる通信I/F(インタフェース)、管理者用の入出力装置等を備え、コンピュータプログラムを実行することにより後述の各種機能部を実現する。
【0024】
携帯端末2は、後述する電子マネー決済代行サービスの実現に用いられる。携帯端末2は、ユーザが持ち歩き可能で、店舗等に設置される電子マネー用のリーダーライタ5と近距離無線通信が可能な情報処理装置である。ユーザが持ち歩き可能で、リーダーライタ5と近距離無線通信が可能な情報処理装置例としては、例えば、Felica(登録商標)等の近距離無線通信技術が搭載されたスマートフォンが挙げられる。リーダーライタ5と携帯端末2との間で取り交わされる近距離無線通信は、例えば、所定の暗号鍵等を用いた数cm程度の距離のセキュアな無線通信である。携帯端末2は、図示しないCPUやRAM、ROM、バッテリー、タッチパネル付きの液晶表示装置、無線基地局4やリーダーライタ5と無線通信を行う通信回路等を備え、コンピュータプログラムを実行することにより後述の各種機能部を実現する。
【0025】
図2は、サーバ1及び携帯端末2に実現される機能ブロックを示した図の一例である。サーバ1は、コンピュータプログラムを実行し、口座管理部F1Aやバリュー生成部F1Bを実現する。また、携帯端末2は、コンピュータプログラムを実行し、電子マネー特定部F2Aや決済部F2Bを実現する。口座管理部F1Aは、携帯端末2のユーザの口座を管理する機能を主に司る。また、バリュー生成部F1Bは、口座管理部F1Aによって管理されるお金を基にバリューを生成する機能を主に司る。また、電子マネー特定部F2Aは、電子マネーのリーダーライタから受信した情報を基に、リーダーライタ5で決済する電子マネーの種類を特定する機能を主に司る。また、決済部F2Bは、バリュー生成部F1Bが生成したバリューを基に、リーダーライタ5における決済処理を主に司る。
【0026】
本実施形態において、バリューの加算や減算に際しては、バリューの取扱い権限を示す暗号鍵に基づいて所定の暗号化がされる。サーバ1や携帯端末2は、バリューの加算や減算に際して正当性を判定し、正当であると判定した場合に限り、当該指示に従った処理を
実行する。正当性は、例えば、所定の暗号鍵で所定の暗号化がされていることをもって判定される。なお、本願においてバリューとは、貨幣価値に対応させた電子情報であり、例えば、サーバ1と携帯端末2とリーダーライタ5との間で移動可能な貨幣価値である。
【0027】
図3は、実施形態に係る情報処理システム10によって実現される電子マネー決済代行サービスの全体像を示した図の一例である。情報処理システム10によって実現される電子マネー決済代行サービスでは、サーバ1と携帯端末2が連携し、サーバ1または外部サーバによって入出金等が管理される銀行口座20及びお財布用口座30(本願でいう「口座」の一例である)と、携帯端末2のアプリケーション(以下、単に「アプリ」という)2APとを用いた電子マネーの決済が行われる。情報処理システム10によって実現される電子マネー決済代行サービスは、各電子マネー事業者が提供する複数の電子マネーを使った決済を可能にする。情報処理システム10によって実現される電子マネー決済代行サービスにおいて決済を可能にできる電子マネーとしては、例えば、SuicaやEdy、nanaco等(何れも登録商標)が挙げられる。実施形態に係る情報処理システム10によって実現される電子マネー決済代行サービスでは、携帯端末2がリーダーライタ5に翳されると、携帯端末2のアプリ2APが、当該リーダーライタ5で決済可能な電子マネーで決済を行う。また、アプリ2APによる決済の実行に伴って、当該決済に関わるバリューと預金との交換がお財布用口座30で行われる。なお、お財布用口座30は、電子マネーを用いた日常的な決済に用いられるお金が預金される口座である。ユーザは、例えば、お財布用口座30に預けるお金を銀行口座20よりも少額にしておくことで、携帯端末2を紛失した場合の被害額を抑制することができる。しかし、本実施形態に係る情報システム10は、ユーザが銀行口座20とお財布用口座30の2つの口座を持つことを前提としたものに限定されるものではない。本実施形態に係る情報システム10は、例えば、銀行口座20を管理しないサーバ1が後述の電子マネー決済代行サービスを実現してもよいし、お財布用口座30を介さずに銀行口座20の預金で電子マネーの決済が行われるようにしてもよい。
【0028】
図4は、サーバ1が実現する処理フローを示した図の一例である。サーバ1は、携帯端末2から情報を受信したか否かの判定を行う(S101)。サーバ1は、電子マネーの種類や決済に係る金額、携帯端末2のユーザが使用するお財布用口座30の情報(以下、単に「使用口座情報」という)に関する情報を受信した場合、ステップS101で肯定判定を行う。
【0029】
サーバ1は、ステップS101の処理で肯定判定を行った場合、お財布用口座30から決済に係る金額と等価な額の預金の払出処理を実行する(S102)。例えば、サーバ1自身がお財布用口座30の入出金を管理している場合、サーバ1は、ステップS102の処理において、携帯端末2のユーザが使用するお財布用口座30の預金額を、決済に係る金額と等価な額だけ減らす。また、例えば、外部サーバがお財布用口座30の入出金を管理している場合、サーバ1は、ステップS102の処理において、携帯端末2のユーザが使用するお財布用口座30の預金額を、決済に係る金額と等価な額だけ減らすよう当該外部サーバへ命令する。預金の払出処理は、主に口座管理部F1Aで実行される。
【0030】
サーバ1は、ステップS102の処理を実行した後、お財布用口座30からの払出に成功したか否かの判定処理を実行する(S103)。実施形態に係る情報処理システム10によって実現される電子マネー決済代行サービスにおいて、携帯端末2のユーザに対するお金の一時的な貸付が認められない場合、ステップS103では、例えば、携帯端末2のユーザが使用するお財布用口座30の預金額が、決済に係る金額を上回っていることを判定条件の一つにすることができる。
【0031】
サーバ1は、ステップS103で肯定判定を行った場合、お財布用口座30から減額さ
れた預金額と等価な電子マネーのバリューを生成する(S104)。そして、サーバ1は、ステップS104で生成したバリューを携帯端末2のアプリ2APへ送信する(S105)。一方、サーバ1は、ステップS103で否定判定を下した場合、決済不能である旨を示すエラー情報を携帯端末2へ送信する(S106)。バリューの生成は、主にバリュー生成部F1Bで実行される。
【0032】
図5は、携帯端末2が実現する処理フローを示した図の一例である。携帯端末2は、リーダーライタ5から送信される電波を受信したか否かの判定を行う(S201)。携帯端末2は、リーダーライタ5から送信される電波を受信した場合、ステップS201で肯定判定を行う。
【0033】
携帯端末2は、ステップS201で肯定判定を行った場合、リーダーライタ5から送信される電波の情報を基に、当該リーダーライタ5が決済を要求する電子マネーの種類を判別する(S202)。リーダーライタ5から送信される電波の情報には、当該リーダーライタ5で決済可能な電子マネーの種別に関する情報等が含まれる。そこで、携帯端末2は、リーダーライタ5から送信される電波の情報を基に、当該リーダーライタ5が決済を要求する電子マネーの種類の判別を行う。電子マネーの種類の判別は、主に電子マネー特定部F2Aで実行される。
【0034】
携帯端末2は、ステップS202で電子マネーの種類が判明した場合、当該リーダーライタ5が決済を要求する電子マネーの種類や決済に係る金額の情報を、使用口座情報と共にサーバ1へ送信する(S203)。
【0035】
携帯端末2は、ステップS203の処理を行った後、サーバ1からバリューを受信したか否かの判定を行う(S204)。そして、携帯端末2は、ステップS204の処理で肯定判定を行った場合、サーバ1から受信したバリューをリーダーライタ5へ送信する(S205)。また、携帯端末2は、ステップS204の処理で否定判定を行った場合、サーバ1からエラー情報を受信したか否かの判定を行う(S206)。携帯端末2は、ステップS206の処理で肯定判定を行った場合、エラー情報をリーダーライタ5へ送信する(S207)。バリューのリーダーライタ5への送信は、主に決済部F2Bで実行される。
【0036】
なお、上記実施形態ではサーバ1が使用口座情報を基に携帯端末2のユーザが使用するお財布用口座30を特定しているが、本実施形態はこのような形態に限定されるものではない。サーバ1は、例えば、各携帯端末2に付与されている固有の情報、各携帯端末2にインストールされている各アプリ2APに各々付与されている固有の情報、アプリ2APに登録されたユーザID、その他の各種情報に基づいてユーザが使用するお財布用口座30を特定するようにしてもよい。
【0037】
図6は、上記実施形態に係る情報処理システム10のサーバ1及び携帯端末2によって実現される電子マネー決済代行サービスの全体的な処理の流れを示した図である。例えば、店舗等で買い物をしたいユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ5から電波が送信される(SA1)。リーダーライタ5に翳された携帯端末2は、リーダーライタ5の電波を受信すると、上述したステップS201及びステップS202の処理で肯定判定を行った後にステップS203の処理を実行し、リーダーライタ5が決済を要求する電子マネーの種類や決済に係る金額の情報を、使用口座情報と共にサーバ1へ送信する(SA2)。
【0038】
携帯端末2から送信された情報を受信したサーバ1は、ステップS101の処理で肯定判定を行った後にステップS102の処理を実行し、お財布用口座30から決済に係る金額と等価な額の預金の払出処理を実行する(SA3)。お財布用口座30を管理するサー
バでは、サーバ1が携帯端末2から受信した決済に係る金額の情報や使用口座情報を基に、お財布用口座30の預金を払い出す処理が実行される(SA4)。そして、サーバ1は、お財布用口座30を管理するサーバにおける払い出しの処理結果を取得し、ステップS103で肯定判定を行う(SA5)。なお、払出処理の結果の取得に際しては、例えば、お財布用口座30の残高が携帯端末2へ通知されるようにしてもよい。サーバ1は、ステップS103で肯定判定を行った後にステップS104を実行し、お財布用口座30から払い出された額と等価な電子マネーのバリューを生成する(SA6)。ステップSA6で生成されるバリューは、ステップSA2で携帯端末2から通知された電子マネーの種類に対応するバリューである。サーバ1は、ステップS104でバリューを生成した後にステップS105を実行し、生成したバリューを携帯端末2へ送信する(SA7)。
【0039】
サーバ1から送信されたバリューを受信した携帯端末2は、ステップS204の処理で肯定判定を行った後にステップS205の処理を実行し、サーバ1から受信したバリューをリーダーライタ5へ送信する(SA8)。サーバ1から受信したバリューが携帯端末2を通じてリーダーライタ5へ送信されることにより、リーダーライタ5が繋がる店舗のレジスターでは電子マネーによる決済が執り行われる。そして、電子マネーの事業者において諸々の事務処理が行われ、お財布用口座30から払い出されたお金が最終的に店舗の事業者へ支払われる。
【0040】
上記実施形態において実現される電子マネー決済代行サービスであれば、ユーザが加入していると否とに関わらず、情報処理システム10で取扱い可能なあらゆる電子マネー事業者の電子マネーをユーザが利用できるため、店頭に置かれたリーダーライタ5がユーザの加入している電子マネー事業者の電子マネーに対応していない場合や、対応している場合であっても利用可能な電子マネーのバリューが不足していてユーザの電子マネーカードでは決済不能な場合であっても、電子マネーによる決済が可能である。また、上記実施形態において実現される電子マネー決済代行サービスでは基本的にバリューの蓄積が不要なので、例えば、様々な電子マネーに対応可能とするべく各電子マネー事業者のサービスに加入したような場合に生ずる、残存するバリューが増えすぎるという不合理が生じることもない。
【0041】
<オフライン処理を可能にする場合の変形例>
ところで、上記実施形態では、オンライン処理を前提としていた。しかし、上述の情報処理システム10によって実現される電子マネー決済代行サービスは、オフライン処理を可能にするものであってもよい。以下、オフライン処理を可能にする場合の変形例について、上記実施形態との相違点を中心に説明する。
【0042】
上述の情報処理システム10においてオフライン処理を可能にする場合、基本的に携帯端末2における処理が上述と少々異なる。図7は、本変形例において携帯端末2が実現する処理フローを示した図の一例である。本変形例において、上述の実施形態と同様の処理については同一の符号を付し、その詳細な説明を省略する。
【0043】
携帯端末2は、上述のステップS202で電子マネーの種類が判明した場合、携帯端末2が無線基地局4と通信可能な電波の圏内か否かの判定を行う(S202−1)。携帯端末2は、ステップS202−1で肯定判定を行った場合、上述したステップS203以降の処理を実行する。一方、携帯端末2は、ステップS202−1で否定判定を行った場合、携帯端末2のメモリに記憶されている残高管理テーブルを更新し、残高管理テーブルの残高を減算する(S202−2)。
【0044】
図8は、残高管理テーブルの一例を示した図である。本変形例においては、例えば、図8に示すような、電子マネーの種類や決済番号、決済が行われた日時、決済額等の決済情
報と残高とを記録する残高管理テーブルが携帯端末2のメモリに記憶される。そして、例えば、ステップS202−1で否定判定が行われた場合、携帯端末2は、リーダーライタ5から送信された情報を残高管理テーブルへ記録すると共に、残高管理テーブルに記録されている残高から決済額を減算する。
【0045】
携帯端末2は、ステップS202−2の処理を実行した後、残高管理テーブルの残高から減算された額(本願でいう「負債額」の一例である)と等価な電子マネーのバリューを生成する(S202−3)。携帯端末2は、ステップS202−3の処理を実行した後、上述したステップS205以降の処理を実行する。
【0046】
携帯端末2は、上述のステップS201で否定判定を行った場合、次に、残高管理テーブルの残高がマイナスであるか否かの判定を行う(S202−4)。携帯端末2は、ステップS202−4の処理で肯定判定を行った場合、次に、携帯端末2が無線基地局4と通信可能な電波の圏内に居るか否かの判定を行う(S202−5)。携帯端末2は、ステップS202−5の処理で肯定判定を行った場合、残高管理テーブルに記録されている各決済の情報を、使用口座情報と共にサーバ1へ送信する(S202−6)。携帯端末2は、ステップS202−6の処理を行った後、サーバ1からバリューを受信したか否かの判定を行う(S202−7)。そして、携帯端末2は、ステップS202−7の処理で肯定判定を行った場合、サーバ1から受信したバリューを基に、残高管理テーブルに記録されている決済情報を消去する(本願でいう「解消処理」の一例である)と共に残高を加算する(S202−8)。
【0047】
図9は、オフライン時の電子マネー決済代行サービスの全体的な処理の流れを示した図である。例えば、店舗等で買い物をしたユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ5から電波が送信される(SB1)。リーダーライタ5に翳された携帯端末2は、リーダーライタ5の電波を受信すると、上述したステップS201及びステップS202の処理で肯定判定を行った後にステップS202−1で否定判定を行い、ステップS202−2とステップS203−3の処理を実行してバリューを生成する。そして、携帯端末2は、ステップS205の処理を実行し、携帯端末2で生成したバリューをリーダーライタ5へ送信する(SB2)。携帯端末2で生成されたバリューがリーダーライタ5へ送信されることにより、リーダーライタ5が繋がる店舗のレジスターでは電子マネーによる決済が執り行われる。
【0048】
また、携帯端末2のユーザが店舗から離れて移動し、携帯端末2が無線基地局4と通信可能な電波の圏内に入ると、携帯端末2は、ステップS202−4及びステップS202−5の処理で肯定を行う。そして、携帯端末2は、ステップS202−6の処理を実行し、残高管理テーブルに記録されている各決済の情報を、使用口座情報と共にサーバ1へ送信する(SB3)。
【0049】
ステップS202−6の処理の実行により、携帯端末2から送信された情報を受信したサーバ1では、ステップS101からステップS105までの一連の処理が実行される。すなわち、携帯端末2から送信された情報を受信したサーバ1は、ステップS101の処理で肯定判定を行った後にステップS102の処理を実行し、お財布用口座30から決済に係る金額と等価な額の預金の払出処理を実行する(SB4)。そして、お財布用口座30を管理するサーバでは、サーバ1が携帯端末2から受信した決済に係る金額の情報や使用口座情報を基に、お財布用口座30の預金を払い出す処理が実行される(SA4)。そして、サーバ1は、お財布用口座30を管理するサーバにおける払い出しの処理結果を取得し、ステップS103で肯定判定を行う(SB5)。そして、サーバ1は、ステップS104を実行し、お財布用口座30から払い出された額と等価な電子マネーのバリューを
生成する(SB6)。そして、サーバ1は、ステップS105を実行し、生成したバリューを携帯端末2へ送信する(SB7)。
【0050】
ステップS105の処理の実行により、サーバ1から送信されたバリューを受信した携帯端末2では、ステップS202−7で肯定判定が行われてステップS202−8の処理が実行され、の処理で肯定判定を行った場合、サーバ1から受信したバリューを基に、残高管理テーブルに記録されている決済情報を消去すると共に残高を加算する(S202−8)。残高管理テーブルに記録されている全ての決済情報が消去されると、残高管理テーブルに記録されている残高がゼロになる(SB8)。
【0051】
本変形例によれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、携帯端末2がサーバ1にアクセスできない状態においても滞りなく電子マネーの決済を行うことができる。なお、本変形例では、残高管理テーブルの残高の制限に触れられていないが、本変形例は、例えば、残高管理テーブルの残高に下限値が設定されており、下限値を下回る場合は携帯端末2におけるバリューの生成が中止されるようにしてもよい。下限値は、例えば、携帯端末2のユーザが有する銀行口座の残高や電子マネーの利用実績、その他の各種の情報に基づいて動的に設定される値であってもよいし、或いは一律に設定される値であってもよい。
【0052】
<決済に用いる電子マネーの種類の選択>
ところで、上記実施形態では、リーダーライタ5が複数種類の電子マネーの決済に対応可能な場合に、決済に用いる電子マネーの種類を選択することに言及されていなかった。上記の情報処理システム10によって実現される電子マネー決済代行サービスは、リーダーライタ5が複数種類の電子マネーの決済に対応可能な場合に、決済に用いる電子マネーの種類を以下のように選択してもよい。
【0053】
上記の情報処理システム10によって実現される電子マネー決済代行サービスにおいて、決済に用いる電子マネーの種類を選択する処理を行う場合、サーバ1及び携帯端末2が実行する処理に以下のような処理が加わる。
【0054】
図10は、サーバ1が実行する処理に追加される処理フローを示した図の一例である。サーバ1は、リーダーライタ5で使用可能な電子マネーが複数種類あるか否かを、携帯端末2から送信される情報を基に判定する(S1001)。サーバ1は、ステップS1001の処理で肯定判定を行った場合、決済に用いることを推奨する電子マネーの種類を選定し、選定した一又は複数の電子マネーの種類に関する情報を携帯端末2へ通知する(S1002)。サーバ1は、ステップS1001の処理で否定判定を行った場合、又はステップS1002の処理を実行した後、上述したステップS101以降の一連の処理を実行する。
【0055】
図11は、携帯端末2が実行する処理に追加される処理フローを示した図の一例である。携帯端末2は、リーダーライタ5で使用可能な電子マネーが複数種類あるか否かを、リーダーライタ5から送信される電波の情報を基に判定する(S2001)。携帯端末2は、ステップS2001の処理で肯定判定を行った場合、リーダーライタ5から受信した情報をサーバ1へ送信する(S2002)。携帯端末2は、ステップS2002の処理を実行した後、サーバ1から送られる情報を受信したか否かの判定を行う(S2003)。携帯端末2は、サーバ1が選定した一又は複数の電子マネーの種類に関する情報を取得することにより、ステップS2003の処理で肯定判定を行った場合、決済に用いる電子マネーの種別を決定する(S2004)。図12は、携帯端末2の表示画面に表示される画面の一例である。決済に用いる電子マネーの種別の決定は、例えば、図12に示す携帯端末2の表示画面のように、サーバ1が選定した一又は複数の電子マネーの種類が表示され、
携帯端末2のユーザによる選択操作によって決定されてもよいし、或いは、サーバ1が選定した一又は複数の電子マネーの種類の中でサーバ1の推奨度が最も高いものが自動的に決定されてもよい。携帯端末2は、ステップS2004の処理を実行した後、決済に用いることが決定された電子マネーの種類をリーダーライタ5へ通知する(S2005)。
【0056】
図13は、電子マネーの種類を選択する処理の全体的な流れを示した図である。例えば、店舗等で買い物をしたいユーザが、電子マネーによる決済を希望する旨を店員に申し出ると、レジスターの操作が行われ、電子マネー用のリーダーライタ5から電波が送信される(SC1)。当該リーダーライタ5が複数種類の電子マネーに対応可能な場合、当該リーダーライタ5からは各電子マネーのプロトコルに各々従った各種の電波が交互に送信される。リーダーライタ5に翳された携帯端末2は、リーダーライタ5の電波を受信すると、上述したステップS2001の処理で肯定判定を行った後にステップS2002の処理を実行し、当該リーダーライタ5で決済可能な電子マネーの情報をサーバ1へ送信する(SC2)。
【0057】
携帯端末2から送信された情報を受信したサーバ1は、ステップS1001の処理で肯定判定を行った後にステップS1002の処理を実行し、決済に用いることを推奨する電子マネーの種類を選定し、選定した一又は複数の電子マネーの種類に関する情報を携帯端末2へ通知する(SC3)。
【0058】
サーバ1から送信された情報を受信した携帯端末2は、ステップS2003の処理で肯定判定を行った後にステップS2004の処理を実行し、決済に用いる電子マネーの種別を決定する(SC4)。携帯端末2は、ステップS2004の処理で決済に用いる電子マネーの種別を決定した後に、決済に用いることが決定された電子マネーの種類をリーダーライタ5へ通知する(SC5)。以降は、図6に示したステップSA1からステップSA8までの処理と同様の処理が行われる。
【0059】
本変形例によれば、様々な電子マネー事業者の電子マネーに対応可能であり且つ電子マネー事業者毎にバリューを残留させないのみならず、リーダーライタ5が様々な電子マネーに対応可能な場合であっても電子マネーで速やかに決済を行うことが可能となる。
【0060】
なお、決済に用いる電子マネーの種類の選定は、サーバ1を介さずに携帯端末2単体で行われるようにしてもよい。
【0061】
<電子マネーの種類の選定>
ところで、上述の説明においては、決済に用いることを推奨する電子マネーの種類の選定方法について詳述しなかったが、サーバ1がステップS1002の処理を実行する際は、例えば、携帯端末2に予め設定された順位に従って電子マネーの種類が設定されてもよいし、或いは、以下のようなアルゴリズムに従って電子マネーの種類を選定するようにしてもよい。
【0062】
<アルゴリズムの第1例>
図14は、電子マネーの種類の選定に用いるアルゴリズムの第1例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、携帯端末2のユーザが利用する店舗の利用履歴に基づいた選定方法が挙げられる。例えば、携帯端末2のユーザが利用する店舗の使用回数が図14の「1、お客さま利用履歴テーブル」のような形態で、サーバ1がアクセス可能なデータベースに保存されており、また、利用者に対し決済額に応じて付与される特典ポイントの付与対象となる電子マネーの種別の店舗毎の情報が図14の「2、店舗情報テーブル」のような形態でデータベースに保存されている場合、サーバ1は、ステップS1002の処理において「1、お客さま利用履歴
テーブル」及び「2、店舗情報テーブル」を照会して、ユーザが過去に電子マネーを決済で使用可能だった回数(以下、「使用可能回数」という)を電子マネーの種別毎に算出し、算出した使用可能回数に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップS1002の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、店舗の利用実績の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。
【0063】
<アルゴリズムの第2例>
図15は、電子マネーの種類の選定に用いるアルゴリズムの第2例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、電子マネーの利用履歴に基づいた選定方法が挙げられる。例えば、携帯端末2のユーザが過去の決済で利用した電子マネーの利用金額の合計を、サーバ1がアクセス可能なデータベースの情報を基に特定できる場合、サーバ1は、携帯端末2のユーザが過去の決済で利用した各電子マネーの合計利用金額に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップS1002の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、電子マネーの利用実績の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。なお、電子マネーの利用履歴に基づいた選定方法としては、携帯端末2のユーザが過去の決済で利用した電子マネーの利用金額の合計に基づく選定方法のみならず、例えば、携帯端末2のユーザが過去の決済で電子マネーを利用することにより蓄積されたポイントの合計に基づく選定方法が挙げられる。
【0064】
<アルゴリズムの第3例>
図16は、電子マネーの種類の選定に用いるアルゴリズムの第3例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、例えば、ポイントの還元率に基づいた選定方法が挙げられる。例えば、上記実施形態に係る情報処理システム10が実現する電子マネー決済代行サービスで決済可能な各電子マネーのポイント還元率の情報が、サーバ1がアクセス可能なデータベースに格納されている場合、サーバ1は、電子マネーのポイント還元率に基づいて算出した偏差値を基に各電子マネーを順位付けすることが可能である。ステップS1002の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、ポイント還元率の観点で最もポイントを貯めやすい電子マネーを容易に選ぶことができる。
【0065】
<アルゴリズムの第4例>
図17は、電子マネーの種類の選定に用いるアルゴリズムの第4例をイメージした図である。決済に用いることを推奨する電子マネーの種類の選定方法としては、上記第1例から第3例までの何れかに限定されるものでなく、例えば、携帯端末2のユーザが利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率の3つの要素を用いたアルゴリズム、換言すると、上記第1例から第3例までの3つのアルゴリズムを組み合わせたアルゴリズムに従う選定方法が挙げられる。上記第1例から第3例までの3つのアルゴリズムを組み合わせる場合、図17の「偏差値まとめテーブル」に示されるように、携帯端末2のユーザが利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率の3つの要素のそれぞれについて、電子マネーの種別毎に偏差値が得られる。サーバ1は、3つの要素のそれぞれの偏差値を基にした総合的な電子マネーの順位付けを行うことが可能である。ステップS1002の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、自身が利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率という3つの要素を総合して最も適切な電子マネーを容易に選ぶことができる。
【0066】
なお、このように複数の要素を用いたアルゴリズムに従って電子マネーの順位付けを行う場合、各要素の重み付けは、均等であってもよいし、サーバ1が所定のアルゴリズムに従って自動的に設定されてもよいし、携帯端末2のユーザが好みに応じて手動で設定されてもよい。図18は、携帯端末2のユーザによる重み付けの手動設定をイメージした図である。重み付けの手動設定の方法としては、例えば、図18に示される様に、携帯端末2等に表示される設定画面でユーザ操作を受け付け、要素毎の重み付けの設定操作を受け付け可能にすることが考えられる。なお、図18の設定画面の例では、店舗の利用履歴については重み付けが低く、電子マネーの利用履歴については重み付けが中程度とされ、ポイント還元率については重み付けが高くされるように設定されている。
【0067】
図19は、携帯端末2のユーザによって重み付けが手動設定された場合の各電子マネーの順位の一例を示した図である。例えば、図18の設定画面で「低」に設定された要素の重要度の値を「0」、「中」に設定された要素の重要度の値を「1」、「高」に設定された要素の重要度の値を「2」と仮定する。そして、設定された各要素の重要度の値に各要素の偏差値を乗算したものの合計値を当該電子マネーの総合点数として定め、総合点数順に各電子マネーの順位付けを行うと、サーバ1は、例えば、図19に示されるような順位付けの結果を得ることが可能である。ステップS1002の処理においてこのようなアルゴリズムに基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、自身が利用する店舗の利用履歴と電子マネーの利用履歴とポイント還元率という3つの要素を、自身が任意に設定した重み付けに従って総合することにより選定された最も適切な電子マネーを容易に選ぶことができる。
【0068】
<その他のアルゴリズム>
決済に用いる電子マネーの種類の選定に関しては、上記アルゴリズムに限定されるものでなく、その他の様々なものを適用できる。決済に用いる電子マネーの種類のその他の選定方法としては、例えば、複数の電子マネー間のポイント変換率に基づいた選定方法が挙げられる。例えば、各電子マネー間のポイント変換率の情報が、サーバ1がアクセス可能なデータベースに格納されている場合、サーバ1は、各電子マネー間のポイント変換率を基に各電子マネーを順位付けすることが可能である。電子マネー間のポイント変換率に基づく順位付けが行われれば、リーダーライタ5における電子マネーの決済に際し、ユーザは、例えば、普段利用している電子マネーでは決済不能の場合に、決済可能な幾つかの電子マネーの中から、普段利用している電子マネーへのポイントの変換率が最も高い電子マネーを容易に選ぶことができる。
【0069】
<その他の変形例>
ところで、上記実施形態や各変形例においては、電子マネーによる決済に際し、携帯端末2のユーザに対する決済の意思確認が特になされていなかった。よって、上記実施形態や各変形例では、情報処理システム10で取扱い可能な種類の電子マネーであれば、ユーザの意思に関わらず決済が実行される。しかし、上記実施形態や各変形例は、決済の実行前に、ユーザによる決済の可否の承認操作が行われるようにしてもよい。このような処理が行われる場合、ユーザは、例えば、特定の種類の電子マネーによる決済の実行を拒否することが可能となる。
【0070】
また、上記実施形態や各変形例においては、物理的に実在する店舗における電子マネーの決済を前提としていたが、上記実施形態や各変形例は、例えば、インターネットに接続可能なコンピュータ端末を使い、インターネット上の仮想店舗で支払を行う際、当該コンピュータ端末に設けられるリーダーライタを通じて行う電子マネーの決済に用いられてもよい。
【符号の説明】
【0071】
10・・情報処理システム:1・・サーバ:2・・携帯端末:3・・ネットワーク:4・・無線基地局:5・・リーダーライタ:F1A・・口座管理部:F1B・・バリュー生成部:F2A・・電子マネー特定部:F2B・・決済部:20・・銀行口座:30・・お財布用口座:2AP・・アプリ
図1
図2
図4
図5
図7
図8
図10
図11
図17
図3
図6
図9
図12
図13
図14
図15
図16
図18
図19