JP2023006759A - プログラム、情報処理方法、情報処理装置 - Google Patents
プログラム、情報処理方法、情報処理装置 Download PDFInfo
- Publication number
- JP2023006759A JP2023006759A JP2021109517A JP2021109517A JP2023006759A JP 2023006759 A JP2023006759 A JP 2023006759A JP 2021109517 A JP2021109517 A JP 2021109517A JP 2021109517 A JP2021109517 A JP 2021109517A JP 2023006759 A JP2023006759 A JP 2023006759A
- Authority
- JP
- Japan
- Prior art keywords
- electronic money
- user
- notification
- terminal
- information processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 218
- 238000003672 processing method Methods 0.000 title claims description 9
- 238000000034 method Methods 0.000 claims abstract description 259
- 230000008569 process Effects 0.000 claims abstract description 238
- 238000012545 processing Methods 0.000 claims description 234
- 238000004891 communication Methods 0.000 claims description 163
- 238000012546 transfer Methods 0.000 claims description 11
- 238000007726 management method Methods 0.000 description 318
- 238000012986 modification Methods 0.000 description 157
- 230000004048 modification Effects 0.000 description 157
- 238000010586 diagram Methods 0.000 description 106
- 230000000694 effects Effects 0.000 description 84
- 238000012790 confirmation Methods 0.000 description 55
- 230000006870 function Effects 0.000 description 55
- 238000004364 calculation method Methods 0.000 description 40
- 230000005540 biological transmission Effects 0.000 description 16
- 238000010079 rubber tapping Methods 0.000 description 12
- 230000004044 response Effects 0.000 description 11
- 230000007704 transition Effects 0.000 description 10
- 238000001514 detection method Methods 0.000 description 9
- 230000033228 biological regulation Effects 0.000 description 7
- 238000003384 imaging method Methods 0.000 description 6
- 230000000737 periodic effect Effects 0.000 description 6
- 230000000903 blocking effect Effects 0.000 description 5
- 230000015556 catabolic process Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 230000007423 decrease Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- DCYGAPKNVCQNOE-UHFFFAOYSA-N 2,2,2-triphenylacetic acid Chemical compound C=1C=CC=CC=1C(C=1C=CC=CC=1)(C(=O)O)C1=CC=CC=C1 DCYGAPKNVCQNOE-UHFFFAOYSA-N 0.000 description 2
- 101150004219 MCR1 gene Proteins 0.000 description 2
- 241000556720 Manga Species 0.000 description 2
- 101100206347 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pmh1 gene Proteins 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 235000013361 beverage Nutrition 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000006735 deficit Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 229920001690 polydopamine Polymers 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
本発明の第2の態様によると、第1情報処理装置と通信する情報処理装置の情報処理方法は、第1情報処理装置のユーザによって制限が設定され、第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を情報処理装置の制御部によって行うことを含む。
本発明の第3の態様によると、第1情報処理装置と通信する情報処理装置は、第1情報処理装置のユーザによって制限が設定され、第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を行う制御部を備える
本発明の第4の態様によると、第1情報処理装置と通信する情報処理装置は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第1情報処理装置のユーザによって制限が設定され、第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を行うことを実行する。
本発明の第5の態様によると、第1情報処理装置および第2情報処理装置と通信するサーバによって実行されるプログラムは、第1情報処理装置のユーザによって制限が設定された、第1情報処理装置から第2情報処理装置に送金された第1電子貨幣と、第2情報処理装置のユーザとを関連付ける処理と、第2電子貨幣と第2情報処理装置のユーザとを関連付ける処理と、をサーバの制御部によって行うことと、第2情報処理装置から送信された情報に基づいて、第1電子貨幣の少なくとも一部と、第2電子貨幣の少なくとも一部とに基づく第1決済に関する処理を制御部によって実行することがサーバによって実行される。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。
(1)端末&サーバ
(2)サーバ
(3)端末
なお、プロセッサーは、仮想プロセッサーとしてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
限定ではなく例として、サーバは、第1装置と第2装置とを備え、第1装置は第1通信部を有し、第2装置は第2通信部を有する場合、サーバの通信部は、第1通信部と第2通信部とを含む概念としてもよい。
また、(2C)では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て(割り振り)は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
なお、サーバとして、上記(2)のサーバシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管(格納)する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。
限定ではなく例として、第1情報と第2情報とを送信するという場合、第1情報と第2情報とをタイミングを合わせて送信するものと、第1情報と第2情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ(タイムラグ)を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。
限定ではなく例として、上記のように第1情報と第2情報とを送信するという場合、第1情報と第2情報とを送信しさえすればよく、同じ目的で第1情報と第2情報とを送信する場合の他、異なる目的で第1情報と第2情報とを送信する場合も含めてよいものとする。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い(決済)を行うようにことができるようにすることができる。
「店舗提示型」のコード支払いは、限定ではなく例として、店舗側が提示するコード情報をユーザが自己の端末20のコードリーダに読み取らせて支払いを行う方法とすることができる。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報(限定ではなく例として、URI(Uniform Resource Identifier)等を含む。)などのリンクコンテンツを含めてもよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも1つを含まなくてもよく、その他のテキストを含んでもよい。
(A)メッセージングアプリケーションの一機能として支払いサービスの機能を持たせる形態
(B)支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション(統合的なアプリケーション)を構成する形態
(C)支払いアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態
また、この場合、1つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる(連携される)ようにすることができる。
また、(C)の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとを関連付ける処理(連携する処理)を行うようにすることができる。
なお、「電子貨幣」は、「デジタル通貨(デジタル貨幣)」と考えてもよいものとする。
第1実施例は、限定ではなく例として、一の端末20(以下、適宜「第1端末」と称する。)のユーザから他の端末20(以下、適宜「第2端末」と称する。)のユーザに対して電子貨幣が送金され、第2端末のユーザにより電子貨幣の少なくとも一部が使用されたことに基づき、通知が所定の端末20(以下、適宜「第3端末」と称する。)に送信されるようにする実施例である。
なお、支払いサービス事業者は、支払いアプリケーションを提供する事業者や、サーバ10の事業者と表現することもできる。
また、決済サービスを提供する事業者という意味で、決済サービスの事業者と表現することもできる。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図1-1は、本開示の実施形態における通信システム1のシステム構成の一例を示す図である。
通信システム1では、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)と、1以上の店舗POSシステム40とが接続される。
本実施形態では、支払いサービス事業者(運営者)やメッセージングサービス事業者(運営者)をサーバ10のユーザとする。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
通信システム1に含まれる各装置のHW構成について説明する。
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
図1-2には、店舗POSシステム40のシステム構成の一例を示している。
店舗POSシステム40は、サーバ10を運用する事業者と提携している店舗に導入されて使用されるPOSシステムであり、限定ではなく例として、店舗コードリーダ装置50と、コードレジ60と、店舗サーバ70とを含む。
コードレジ60は、支払いアプリケーションに対応可能に構成されたレジであり、支払いアプリケーション対応の据置端末と言うこともできる。
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをP1とすると、システムのプログラムP1は、端末に保存されたプログラムP2と、サーバに保存されたプログラムP3とで構成され、P2とP3とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムP2は、第1の処理を実行し、第1の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムP3は、受信した第1の処理をした結果に対して第2の処理を行い、第2の処理を行った結果を端末に送信するプログラムであってもよい。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
(1)サーバの機能構成
図1-3は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶されたアプリケーション管理処理プログラム151に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部111を機能部として含む。
記憶部15には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155とが記憶される。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションIDや公式ユーザ用のアプリケーションIDとすることができる。
また、1つの端末20につき1つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」とすることができる。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。
また、この場合、上記のように「端末20を識別するための識別情報=端末20のユーザを識別するための識別情報=アプリケーションID」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。
アカウント管理データベース155Aには、アカウントごとの管理データとして、アカウント管理データが記憶される。
通知には、限定ではなく例として、送金先アカウント(またはそのユーザ)によって通知付き電子マネーが使用されたことに基づく通知を含めることができる。この通知を「通知付き電子マネー使用通知」と称する。
そして、支払い等によって通知付き電子マネー残高が減少することで、通知先IDのアカウントのユーザの端末20に対して通知付き電子マネー使用通知が行われるようにすることができる。
図1-7は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶されたアプリケーション処理プログラム281に従ってアプリケーション処理を実行するためのアプリケーション処理部211を機能部として含む。
記憶部28には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム281と、この端末20、または端末20のユーザのアカウントに対応するアプリケーションID283とが記憶される。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
タップ(タップ操作)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。
・送金元アカウント=ユーザB.B(第1端末のユーザ)のアカウント
・送金先アカウント=ユーザA.A(第2端末のユーザ)のアカウント
・通知先アカウント=送金元アカウント=ユーザB.B(第1端末のユーザ)のアカウント
とする場合を例示する。
この画面は、送金先アカウントを設定するための画面であり、限定ではなく例として、送金先アカウントを指定するための情報として、「送金先を指定してください」のテキストとともに、送金先アカウントを電話番号で検索するための検索ボックスが表示されている。
この画面は、送金金額の指定や通知設定を行うための画面であり、限定ではなく例として、画面上部には、送金金額の指定に関する情報として、「金額を指定してください」のテキストとともに、送金額を直接入力またはボタンを用いて指定するための情報が表示されている。
この画面は、端末20Aの表示部24に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
ページ名表示領域の下には、おしらせの内容が表示されるおしらせ領域が構成されており、おしらせ領域内の向かって左側に、通知付き電子マネーの送金結果に関する情報である通知付き電子マネー送金結果情報NR1が表示されている。
なお、ユーザA.Aにとっては、通知付き電子マネーを受け取ったことを示す情報であるため、通知付き電子マネー受取結果情報と考えることも可能である。
限定ではなく例として、図1-6のアプリケーションID「U001」のアカウントは、この例におけるユーザA.Aのアカウントであり、通常電子マネー残高は「500円」である。また、この例では、ユーザB.BからユーザA.Aに対して通知付き送金として「1,000円」が送金され、ユーザA.Aがこれを受け取っている。このため、通常電子マネー残高と通知付き電子マネー残高とを合算すると「1,500円」となる。このため、残高表示領域BR2には、電子マネー残高として「1,500円」が表示されている。
また、その下の領域内には、ウォレットコード情報が表示されるウォレットコード情報表示領域WCR1が構成されている。
このウォレットトークンは、限定ではなく例として、エンコードによって二次元ウォレットコード画像に格納されるようにすることができる。
また、ウォレットトークンは表示させないようにしてもよい。
また、この図に示すように、ウォレットコード情報の有効期限に関する情報(限定ではなく例として、二次元ウォレットコード画像の下に表示される有効期限までの残り時間)を表示させてもよいし、表示させなくてもよい。
(a)支払い金額≦通常電子マネー残高:通常電子マネー残高から決済
(b)通常電子マネー残高<支払い金額≦通知付き電子マネー残高:通知付き電子マネー残高から消費
(c)通知付き電子マネー残高<支払い金額:決済不可(決済NG)
つまり、本実施例では、通常電子マネー残高と、通知付き電子マネー残高との両方を用いた決済(合算決済)は行わない。
(a)は、この例では、500円以下の支払いを行う場合は、通常電子マネー残高から決済を行うことを意味する。
(b)は、この例では、500円超1000円以下の支払いを行う場合は、通知付き電子マネー残高から決済を行うことを意味する。
(c)は、この例では、1000円超の支払いを行う場合は、支払い不可であることを意味する。
(d)支払い金額≦通知付き電子マネー残高:通知付き電子マネー残高から決済
(e)通知付き電子マネー残高<支払い金額≦通常電子マネー残高:通常電子マネー残高から消費
(f)通常電子マネー残高<支払い金額:決済不可(決済NG)
この例では、ユーザA.Aは、「XX書店」において「1,000円」の書籍を購入したとする。その結果、限定ではなく例として、図1-11の左側の画面が表示される。
このお知らせ画面では、図1-10左側に示した端末20Aのおしらせ画面に表示される通知付き電子マネー送金結果情報NR1に対応する通知付き電子マネー送金結果情報NR2が表示されている。
この通知付き電子マネー使用情報NU2には、限定ではなく例として、通知付き送金で送金した金額が使用された日時(この例では「2021年4月5日14時50分」)と、使用されたことを示す文字(この例では「A.Aに送金した電子マネーが使用されました」)と、「>詳細を確認」ボタンとが含まれる。
この通知付き電子マネー使用情報NU2により、ユーザA.Aに送金を行ったユーザB.Bは、送金した金額がユーザA.Aによって使用されたことを知ることができる。
図1-12,図1-13は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20Aの制御部21が実行する処理、端末20Bの制御部21が実行する処理、サーバ10の制御部11が実行する処理、店舗POSシステム40が実行する処理の一例を示している。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略(削除)してもよい。
・送金元アカウント=ユーザB.B(第1端末のユーザ)のアカウント
・送金先アカウント=ユーザA.A(第2端末のユーザ)のアカウント
・通知先アカウント=送金元アカウント=ユーザB.B(第1端末のユーザ)のアカウント
とする場合の処理を例示する。
具体的には、設定情報に基づいて、ユーザB.Bのアカウント管理データの通常電子マネー残高から送金金額分の金額を減算する。また、ユーザA.Aのアカウント管理データの通知付き電子マネー管理データに、通知先ID(この例では「U0002」)と、通知者名(この例では「ユーザB.B」)と、通知付き電子マネー残高(送金金額分の金額)とを関連付けたレコードを追加する。
端末20Aの制御部21と、端末20Bの制御部21とは、サーバ10から受信した電子マネー送金結果情報を、それぞれ表示部24に表示させる(A110,B130)。
通信I/F14によって端末20Aからウォレット支払い要求情報を受信すると、サーバ10の制御部11は、限定ではなく例として、前述したウォレットコード情報を生成した上で、通信I/F14によって端末20Aに送信する(S130)。
なお、電子マネー残高の情報をウォレットコード情報に含めてもよい。
使用しなかったと判定したならば(S160:NO)、サーバ10の制御部11は、処理を終了する。
一方、使用したと判定したならば(S160:YES)、サーバ10の制御部11は、通信I/F14によって、通知付き電子マネー使用情報を端末20Bに送信する(S170)。そして、サーバ10の制御部11は、処理を終了する。
受信しなかったと判定したならば(B140:NO)、端末20Bの制御部21は、処理を終了する。
一方、受信したと判定したならば(B140:YES)、端末20Bの制御部21は、受信した通知付き電子マネー使用情報を表示部24に表示させる(B150)。そして、端末20Bの制御部21は、処理を終了する。
本実施例は、サーバ10は、送金元アカウントのユーザの端末20(限定ではなく、第1端末の一例)のユーザ(限定ではなく、第1端末のユーザの一例)によって通知に関する設定が行われた電子マネーである通知付き電子マネー(限定ではなく、第1電子貨幣の一例)の送金依頼情報(限定ではなく、第1電子貨幣を送金することに関する情報の一例)を受信する。
また、サーバ10は、送金依頼情報の受信に基づき、送金先アカウントのユーザに送金される通知付き電子マネーを通知付き電子マネー残高に記憶する制御(限定ではなく、第2端末のユーザに送金される第1電子貨幣を第2端末のユーザに関連付けて記憶する制御の一例)を制御部11によって行う。
また、サーバ10は、送金依頼情報の受信に基づき、通知付き電子マネー送金結果情報(限定ではなく、第2端末のユーザに第1端末から送金されたことを示す第2情報の一例)を通信I/F14によって送金先アカウントのユーザの端末20に送信する。
そして、サーバ10は、送金先アカウントのユーザにより通知付き電子マネーの少なくとも一部が使用されたことに基づき、通知付き電子マネー使用情報(限定ではなく、通知の一例)を通知先アカウントのユーザの端末20(限定ではなく、第3端末の一例)に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第1端末のユーザによって通知に関する設定が行われた第1電子貨幣を第2端末のユーザに送金することに関する情報である第1情報の第1端末からの受信に基づき、第2端末のユーザに送金される第1電子貨幣を第2端末のユーザに関連付けて記憶させるとともに、第2端末のユーザに第1端末から送金されたことを知らせることができる。また、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用されたことに関する内容を、第3端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第2端末のユーザによって、第1電子貨幣の少なくとも一部が使用されたことを、第3端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用されたことを、通知に関する設定を行った第1端末のユーザに知らせるができる。
この場合、限定ではなく例として、母親のアカウントを送金元アカウントとする。この場合、母親の端末20が第1端末となる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末20が第2端末となる。
また、限定ではなく例として、母親のアカウントを通知先アカウントとして設定する。この場合、母親の端末20が第3端末(=第1端末)となる。
そして、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、母親のアカウントに対して通知がいくようにすることができる。
このような構成により得られる実施例の効果の一例として、通知が設定された第1電子貨幣と、通知が設定されていない、第2端末のユーザに対して関連付けられた第2電子貨幣とを区別して管理することができ、ユーザの利便性を向上させることができる。
上記の実施例において、送金元アカウントのユーザによって、通知先アカウントに通知する内容を設定することを可能としてもよい。
アカウント管理データベース155Bに含まれる各々のアカウント管理データに記憶される情報は、アカウント管理データベース155Aと同様であるが、通知付き電子マネー管理データに記憶される情報が一部異なっている。
通知内容は、通知先アカウントに通知するより詳細な内容であり、限定ではなく例として、通知付き電子マネーが使用された「金額」、通知付き電子マネーが使用された「店舗」等の情報をこれに含めることができる。
図1-15左側は、送金元アカウントのユーザであるユーザB.Bの端末20Bに表示される支払いアプリケーションの送金画面の一例であり、図1-9右側に対応する画面である。
具体的には、限定ではなく例として、「通知内容」の文字とともに、通知内容として「金額」、「支払い先」、「内容」の3つの項目が表示されており、それぞれの項目に関連付けてチェックボックスが表示されている。チェックボックスをタップすると、そのチェックボックスにチェックが入れられ、その項目を通知内容に含めることが可能に構成されている。この例では、「金額」の項目に対応するチェックボックスと、「支払い先」の項目に対応するチェックボックスとに、それぞれチェックが入れられ、「送金」ボタンBT2がタップされた状態が示されている。
このお知らせ画面では、図1-11右側の画面における通知付き電子マネー使用情報NU2に代えて、通知付き電子マネー使用情報NU3が表示されている。
このような構成により得られる実施例の効果の一例として、第2端末のユーザによって第1電子貨幣のうち使用された金額、第2端末のユーザによって使用された場所、第2端末のユーザによって購入された商品、第2端末のユーザによって購入されたサービスのうち少なくとも一つを、第3端末のユーザに知らせることができる。
サーバ10において、通知付き電子マネー残高と、通常電子マネー残高とを区別せずに管理するようにすることも可能である。
各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、電子マネー残高と、電子マネー使用通知先管理データとが記憶される。
このような構成により得られる実施例の効果の一例として、通知が設定された第1電子貨幣と、通知が設定されていない、第2端末のユーザに対して関連付けられた第2電子貨幣とを区別せずに管理することができる。
第1実施例において支払いを行う際に、電子マネー残高が不足するなどして、決済不可(決済NG)となる場合があり得る。この一例は、前述した(c)や(f)のような場合である。
このような場合に、サーバ10が、決済処理で決済不可と判定したならば、送金先アカウントのユーザの端末20と、通知先アカウントのユーザの端末20とのうちの少なくともいずれか一方の端末20に、残高不足情報や決済不可情報を送信するなどして、残高不足通知や決済不可通知を行うようにしてもよい。
第2実施例は、通知付き電子マネーの残高に応じて通知付き電子マネー使用通知を行う実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
なお、これに限定されず、サーバ10(サーバ10のユーザ)によって設定されるようにしてもよいし、通知先アカウントのユーザ(限定ではなく、第3端末のユーザの一例)によって設定されるようにしてもよい。
図2-1は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図1-13に相当する部分を示したものである。
限定ではなく例として、図1-12のB110のステップにおいて、端末20Bの制御部21は、入出力部23に対するユーザ入力に基づいて、通知内容を設定するようにすることができる。
通知付き電子マネー残高が設定金額以下であると判定したならば(S210:YES)、端末20Bの制御部21は、処理を終了する。
一方、通知付き電子マネー残高が設定金額を超えていると判定したならば(S210:NO),端末20Bの制御部21は、S170に処理を進める。
本実施例は、通知付き電子マネー使用通知は、通知付き電子マネー残高が設定金額以下、または設定金額よりも小さい場合、サーバ10によって通知先アカウントのユーザの端末20(限定ではなく、第3端末の一例)に送信されない構成を示している。
このような構成により得られる実施例の効果の一例として、通知付き電子マネー残高がある程度小さい場合に、第3端末にサーバから通知が送信されないようにすることができる。
通知付き電子マネー使用通知を行う条件、または行わない条件は、上記の実施例で説明したものに限定されない。
限定ではなく例として、1回あたりに使用された通知付き電子マネーの金額が設定金額以下、または設定金額よりも小さい場合、通知付き電子マネー使用通知がサーバ10によって送信されないようにしてもよい。これは、1回あたりに使用される金額が小さければ、リスクの高い通知付き電子マネーの用途ではない可能性があるためである。
・設定されたタイミング(月に1回、週に1回など)
・通知付き電子マネーが全て使用された場合
・通知付き電子マネーのうち使用された金額が設定金額以上、または設定金額よりも大きい場合
・通知付き電子マネーのうち使用された金額の割合が設定割合以上、または設定割合よりも大きい場合
・通知付き電子マネーの使用回数や使用頻度が設定値以上の場合(24時間以内に5回以上使用された場合等)、または設定値よりも大きい場合
・上記の2以上の組合せ
なお、これに限定されず、サーバ10(サーバ10のユーザ)によって設定されるようにしてもよいし、通知先アカウントのユーザ(限定ではなく、第3端末のユーザの一例)によって設定されるようにしてもよい。
このような構成により得られる変形例の効果の一例として、第1電子貨幣のうち第2端末のユーザによって使用された金額がある程度小さい場合に、サーバから第3端末に通知が送信されないようにすることができる。その結果、第3端末のユーザが通知を確認する労力を削減することができる。
このような構成により得られる変形例の効果の一例として、第1端末のユーザが任意に設定したタイミングで、サーバから第3端末に通知が送信されるようにすることができる。
通知先アカウントのユーザの端末20に、通知付き電子マネーの使用履歴に関する情報を表示させるなどして、通知先アカウントのユーザが、通知付き電子マネーの使用履歴を確認できるようにしてもよい。
記憶部15には、前述したプログラムやデータの他に、限定ではなく例として、決済履歴管理データ157が記憶される。
決済履歴管理データは、通知なしの通常電子マネー残高からの支払いによる決済履歴と、通知付き電子マネー残高からの支払いによる決済履歴とを管理するためのデータであり、限定ではなく例として、決済IDと、アプリケーションIDと、使用店舗名と、決済日時と、決済金額とが関連付けて記憶される。
使用店舗名には、その決済IDの決済を要求した店舗の店舗名がサーバ10によって記憶される。
決済日時には、その決済IDの決済処理がサーバ10によって行われた日時がサーバ10によって記憶される。
決済金額には、その決済IDの決済金額がサーバ10によって記憶される。
アカウント管理データベース155Dに含まれる各々のアカウント管理データには、アプリケーションIDと、通常電子マネー残高と、通知付き電子マネー管理データとの他に、限定ではなく例として、通知付き電子マネー使用履歴データが記憶される。
限定ではなく例として、ユーザB.Bの同じアカウントからユーザA.Aの同じアカウントに対して、通知付き電子マネーが送金されたような場合であっても、それぞれ異なるIDが設定される。
この決済IDを記憶させておくことで、商品やサービスの返品時等においても、必要な金額をサーバ10が特定可能となる。
このうち、前述した(b)・(d)の場合は、通知付き電子マネー残高から決済されるため、その金額が使用金額として記憶されるようにすることができる。
また、この場合、その決済金額のうちの決済に使用した通知付き電子マネーの金額が、通知付き電子マネー使用履歴データ(図2-4)の使用金額に記憶されるようにすることができる。
ぞの後、通知付き電子マネーを用いて、通知付き電子マネー使用履歴データにおける決済ID「P21053」、「P29903」、「P32306」の決済が行われ、使用金額の総額が「1,000円+400円+200円=1,600円」であったため、通知付き電子マネー残高は「2,000円-1,600円=400円」となっている。
この通知付き電子マネー使用情報NU21には、限定ではなく例として、その通知付き送金の使用履歴をユーザが確認するための「使用履歴をみる」の文字を含む「使用履歴確認」ボタンBT21が設けられている。
この画面は、支払いアプリケーションにおける通知付き電子マネー使用履歴画面の一例であり、上部には、ユーザA.Aのアイコン画像およびそのユーザ名(A.A)とともに、通知付き送金金額の合計額(この例では「2,000円」)と、そのうちの未使用の金額(この例では「400円」)とが表示されている。
限定ではなく例として、「使用状況確認」ボタンBT22がタップされた際に表示されていた期間に対応する通知付き電子マネー残高の推移グラフが表示される。この例では、「使用状況確認」ボタンBT22がタップされた際に図2-5中央の画面で表示されていた過去「1週間」の期間における通知付き電子マネー使用履歴に対応して、図2-5右側の画面には、過去「1週間」の期間(この例では「2021年4月5日から2021年4月11日までの期間」)における通知付き電子マネー残高の推移グラフが表示されている。
限定ではなく例として、通知付き電子マネー送金結果情報には、通知付き電子マネー送金処理によって設定された送金管理IDを含めるようにしてもよい。
なお、これとは異なり、サーバ10の制御部11が、通知付き電子マネー使用履歴データ(図2-4)に基づいて推移グラフを生成して、通知先アカウントのユーザの端末20に送信するようにしてもよい。
このような構成により得られる変形例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用されることに基づき、その使用履歴に関する情報を、第3端末のユーザに知らせることができる。
前述したように、決済履歴管理データ157に決済IDを記憶させておくことで、商品やサービスの返品時等においても、必要な金額をサーバ10が特定可能となる。
この場合、送金先アカウントのユーザにより使用された通知付き電子マネーの少なくとも一部を返金する場合、サーバ10の制御部11は、店舗POSシステム40から送信される決済IDを決済履歴管理データ157から特定する。これは、決済が行われたか否かを確認するとともに、その決済金額を特定するためである。
このような構成により得られる変形例の効果の一例として、第2端末のユーザにより使用された第1電子貨幣の少なくとも一部を返金する必要がある場合に、第1電子貨幣の少なくとも一部に通知が設定された状態で、第2端末のユーザに返金することができる。
第3実施例は、通知付き電子マネーの送金や、通知付き電子マネーの送金先ユーザのアカウントとの関連付けを、送金先アカウントのユーザに確認することを可能にする実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図3-1左側は、送金先アカウントのユーザであるユーザA.Aの端末20Aの表示部24に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このお知らせ画面には、お知らせ領域の向かって左側に、ユーザB.Bからの通知付き電子マネーの受け取りを確認するための通知付き電子マネー受取確認情報NC31が表示されている。
この画面は、端末20Bの表示部24に表示される支払いアプリケーションのおしらせ画面の一例を示す図であり、お知らせ領域内の向かって左側に、通知付き電子マネーの受け取りが拒否されたことを示す通知付き電子マネー受取拒否情報ND31が表示されている。
図3-2,図3-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
端末20Bから通知付き電子マネー送金依頼情報を受信すると、サーバ10の制御部11は、通知付き電子マネー受取確認情報を、通信I/F14によって端末20Aに送信する(S310)。
この場合、通知付き電子マネー受取確認情報には、限定ではなく例として、端末20Aのユーザに送金される電子マネーに対して通知の設定がされていることを示す情報を含めることができる。
本実施例は、サーバ10が、通知付き電子マネー受取確認情報(限定ではなく、第2端末のユーザに送金された第1電子貨幣に対して通知の設定がされていることを示す通知設定情報の一例)を、通信I/F22によって送金先アカウントのユーザの端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第2端末のユーザに送金された第1電子貨幣に対して通知の設定がされていること、第2端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第2端末のユーザによる許可なく、第1電子貨幣が第2端末のユーザに関連付けて記憶されることを防止することができる。
限定ではなく例として、悪意のある送金元アカウントのユーザが、送金先アカウントのユーザの所在地等の情報を知ろうとして、意図的に通知付き電子マネーを送金するような場合があり得る。
また、限定ではなく例として、前述した親子の例において、通知付き電子マネーを受け取った子供が、ギフティング機能の一種である投げ銭などによって、赤の他人に通知付き電子マネーを送金してしまうようなこともあり得る。
図3-4左側は、送金先アカウントのユーザであるユーザA.Aの端末20Aの表示部24に表示されるコード支払い画面である。
ウォレットコード情報表示領域WCR1に表示されたウォレットコード情報が店舗コードリーダ装置50によって読み取られると、限定ではなく例として、図3-4中央に示すように、コード支払い画面のウォレットコード情報表示領域WCR1に重畳するように、送金先アカウント(この例では、ユーザA.Aのアカウント)によって通知付き電子マネーの少なくとも一部が使用されることで、通知先アカウント(この例では、ユーザB.Bのアカウント)に対して通知付き電子マネー使用通知がなされることを、送金先アカウントのユーザに知らせる情報である通知付き電子マネー使用確認情報NE31が表示される。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側のユーザB.BからユーザA.Aへの通知付き電子マネーの送金が完了したことを示す通知付き電子マネー送金結果情報NR2の下に、ユーザA.Aによって通知付き電子マネーが使用されたことを示す通知付き電子マネー使用情報NU3が表示されている。
S120の後、サーバ10の制御部11は、ウォレット支払い要求情報を端末20Aから受信すると、通知付き電子マネー使用確認情報を、通信I/F14によって端末20Aに送信する(S340)。この通知付き電子マネー使用確認情報には、限定ではなく例として、送金先アカウント(この例では、ユーザA.Aのアカウント)によって通知付き電子マネーの少なくとも一部が使用されることで、通知先アカウント(この例では、ユーザB.Bのアカウント)に対して通知付き電子マネー使用通知がなされることをユーザA.Aに知らせる(通知する)情報を含めることができる。
しかし、通常電子マネー残高を優先的に使用して支払いを行う設定とされている場合、サーバ10の制御部11は、支払い金額が分からなければ、通常電子マネー残高ではなく通知付き電子マネー残高を使用して支払いを行うか否かを判別することができず、通知付き電子マネー使用確認情報を端末20Aに送信する必要があるか否かを判別することができない。
このような構成により得られる変形例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用される前に、第3端末に対して通知がされることを、第2端末のユーザに知らせることができる。
限定ではなく例として、通知先アカウントのユーザに対して通知がなされることを、送金先アカウントのユーザが嫌がることも考えられる。
そこで、送金先アカウントのユーザが通知付き電子マネーの送金を受け取らない設定を行っている場合、通知付き電子マネーが送金先アカウントに関連付けられないようにしてもよい。また、この場合、通知付き送金ができないことを送金元アカウントのユーザに知らせるようにしてもよい。
(S1)一括拒否
(S2)ブロック
(S3)ブラックリスト
(S4)ホワイトリスト
具体的には、限定ではなく例として、ブラックリストに特定のアカウントを追加することで、(S2)ブロックを実現することができる。
逆に、限定ではなく例として、ホワイトリストから特定のアカウントを削除することで、(S2)ブロック、を実現することもできる。
図3-6左側は、端末20Aの表示部24に表示される支払いアプリケーションのウォレット設定画面の一例を示す図であり、電子マネーに関する設定内容として、限定ではなく例として、電子マネーへの自動チャージを行うための「自動的にチャージ」の項目や、全てのアカウントからの通知付き電子マネーの受け取りを拒否するための「通知付き電子マネーの受け取りを拒否」の項目等が表示されている。それぞれの項目の右側には、スライドボタンが関連付けて設けられており、スライドボタンをタップ、またはスライドすることによって、その項目を「ON」とすることが可能に構成されている。この例では、「通知付き電子マネーの受け取りを拒否」の項目が「ON」とされた状態が示されている。これは、前述した(S1)一括拒否、の画面図の一例である。
また、ユーザB.Bのアカウントをブラックリストに追加したり、ユーザB.Bのアカウントをホワイトリストから削除することを可能にする画面図を構成してもよい。この場合は、前述した(S3)ブラックリストや(S4)ホワイトリスト、となる。
この画面は、送金元アカウントのユーザであるユーザB.Bの端末20Bの表示部24に表示される送金画面の一例を示す図であり、図1-9右側と同様の画面である。この画面において「送金」ボタンBT2がタップされると、端末20Bの表示部24に表示される支払いアプリケーションのおしらせ画面には、限定ではなく例として、図3-6右側に示すような表示がなされる。
この通知付き電子マネー受取拒絶情報NF31には、限定ではなく例として、この通知付き電子マネー受取拒絶情報のサーバ10による送信日時と、「A.Aへの通知付き電子マネーの送金に失敗しました」の文字と、「(A.Aのウォレット設定で、通知付き電子マネーの受け取りが拒否されています)」の文字と、送金しようとした金額(この例では「1,000円」)と、「>詳細を確認」ボタンとが表示されている。
その一方で、支払いアプリケーションを利用するユーザにとっては用語が統一されている方が分かり易い可能性があるため、表示画面例では「拒否」の用語を用いている。
最初に、端末20Aの制御部21は、入出力部23に対する通知付き電子マネーの受取を拒絶するユーザ入力に基づいて、通知付き電子マネー受取拒絶設定情報を、通信I/F22によってサーバ10に送信する(A360)。
一方、設定済みではないと判定したならば(S370:NO)、サーバ10の制御部11は、S110に処理を移す。
一方、受信しなかったと判定したならば(B310;NO)、端末20Bの制御部21は、B130に処理を移す。
一方、受信しなかったと判定したならば(A370:NO)、端末20Aの制御部21は、A120に処理を進める。
このような構成により得られる変形例の効果の一例として、第2端末のユーザが、通知が設定されている送金を受け取らない設定を行っている場合、第1電子貨幣を第2端末のユーザに関連付けられないようにすることができるとともに、第1端末のユーザに送金ができないことを知らせることができる。
このような構成により得られる変形例の効果の一例として、第2端末のユーザが、通知が設定されている送金を受け取りたくないような場合、第1端末のユーザがブロックされるようにして、第1端末のユーザからの通知が設定されている送金を受け取らずに済むようにすることができる。
このような構成により得られる変形例の効果の一例として、第2端末のユーザが、通知が設定されている送金を受け取りたくないような場合、全てのユーザがブロックされるようにして、第1端末のユーザからの通知が設定されている送金を受け取らずに済むようにすることができる。
第4実施例は、通知付き電子マネーと、通知が設定されていない、送金先アカウントのユーザに対して関連付けられた電子マネーとを区別する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図4-1は、本実施例におけるアカウント管理データベース155の一例であるアカウント管理データベース155Eのデータ構成例を示す図である。
このアカウント管理データベース155Eの各々のアカウント管理データにおいて、通知付き電子マネー管理データには、限定ではなく例として、送金管理IDと、送金元IDと、通知先IDと、通知者名と、通知付き電子マネー残高とが関連付けて記憶される。
図4-2,図4-3は、本実施例において端末20の表示部24に表示される画面の一例を示す図である。
図4-2左側には、端末20Aの表示部24に表示される支払いアプリケーションのおしらせ画面の一例を示しており、ユーザB.BからユーザA.Aに対して送金された通知付き電子マネーを受け取ったことを示す通知付き電子マネー送金結果情報NR41が表示されている。
また、その下には、通常電子マネー残高が、「通知なし」の文字およびチャージボタンCBTとともに表示されている。
このコード支払い画面では、ウォレットコード情報表示領域WCR1の残高に関する情報が表示される領域に、通知付き電子マネー残高と、通常電子マネー残高とのいずれの残高から支払いを行うかを選択するための情報が表示されている。
また、その下には、「通常電子マネー残高」から支払いを行うための「通知なし」の文字と、通常電子マネー残高(この例では「500円」)と、電子マネーを通常電子マネー残高にチャージするためのチャージボタンCBTとが表示されている。
具体的には、限定ではなく例として、送金した金額(この例では「1,000円」)と、「送金」アイコンと、送金した通知付き電子マネーが使用されることでユーザB.Bに対して通知がなされることを示すイラストと、通知付き電子マネー送金結果情報のサーバ10による送信日時と、「通知付き電子マネーを送金しました(使用状況が通知されます)」の文字と、ユーザB.BからユーザA.Aへの送金であることを示すイラストと、「>詳細を確認」ボタンとを含む通知付き電子マネー送金結果情報NR42の下に、通知付き電子マネー使用情報NU3が表示されている。
本実施例における処理において、限定ではなく上記の画面図の例では、限定ではなく例として、図1-12のS120のステップにおいて、サーバ10の制御部11が、アカウント管理データベース155EのうちのユーザA.Aのアカウントのアカウント管理データに含まれる通知付き電子マネー管理データのうちの送金管理IDを、送金結果情報とともに端末20Aに送信するようにすることができる。このようにすることで、端末20Aにおいて送金管理IDの指定が可能となり、限定ではなく例として図4-2右側の画面のように、ユーザB.Bのアカウントを送金元IDとし、同じくユーザB.Bのアカウントを通知先IDとする通知付き電子マネー残高をユーザが選択することが可能となる。
本実施例は、サーバ10が、通知付き電子マネー(限定ではなく、通知が設定された第1電子貨幣の一例)と、通常電子マネー(限定ではなく、第2端末のユーザに対して関連付けられた第2電子貨幣の一例)とを区別して記憶する制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通知が設定された第1電子貨幣と、通知が設定されていない、第2端末のユーザに対して関連付けられた第2電子貨幣とを区別して管理することができ、ユーザの利便性を向上させることができる。
図2-4のアカウント管理データでは、前述したように、サーバ10側で、送金元アカウントと、通知先アカウントとを区別して管理することが可能となる。
これにより、送金元アカウントのユーザは、限定ではなく例として、自己のアカウントとは異なるアカウントを通知先アカウントとする設定を行うことができる。この場合、一人のユーザが1つのアカウントしか所有することができない場合、通知先アカウントのユーザは、送金元アカウントのユーザとは異なるユーザとなる。その結果、送金元アカウントのユーザの端末20とは異なる端末20(=通知先アカウントのユーザの端末20)に、通知付き電子マネー使用通知が行われるように設定することができる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末20が第2端末となる。
また、限定ではなく例として、父親のアカウントを通知先アカウントとして設定する。この場合、父親の端末20が第3端末となる。
この場合、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、父親のアカウントに対して通知がいくようにすることができる。
図4-4左側は、端末20Bの表示部24に表示される支払いアプリケーションの送金画面であり、画面下部の送金先アカウントのユーザを設定する領域には、「使用通知を受け取る」と示された、自分に対して通知付き電子マネー使用通知が行われるように設定するためのスライドボタンと、「他のユーザに使用通知する」と示された、他のユーザに対して通知付き電子マネー使用通知が行われるように設定するためのスライドボタンとが設けられている。この例では、「他のユーザに使用通知する」のスライドボタンが「ON」とされた状態が示されている。
この画面は、図4-4左側と同様に送金画面であるが、画面上部に、「通知先を設定してください」の文字が表示され、その下に、通知先アカウント(そのユーザ)を電話番号で検索するための検索ボックスが設けられている。
また、その下には、過去に通知先として設定したことがある通知先アカウント(そのユーザ)が履歴として表示されており、この例では、ユーザC.Cのアイコン画像およびそのユーザ名が表示されている。その横には、チェックボックスが関連付けて設けられており、チェックを「ON」とすることで、このユーザを通知先として設定することが可能に構成されている。この例では、ユーザC.Cのチェックが「ON」とされた状態が示されている。
この画面は、図4-4左側の画面に対応する画面であるが、図4-4中央の画面で通知先アカウントが設定されたことにより、「通知先」の文字とともに、図4-4中央の画面で通知先に設定されたユーザC.Cのアイコン画像およびそのユーザ名が表示されている。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側に、通知付き電子マネー送金結果情報NR43が表示されている。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側に、通知付き電子マネー使用情報NU43が表示されている。具体的には、ユーザB.BからユーザA.Aに送金された通知付き電子マネーがユーザA.Aによって使用されたことを示す情報が表示されている。
このような構成により得られる変形例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用されたことを、第1端末とは異なる第3端末のユーザに知らせることができる。
第4実施例では、図4-2右側の画面に示したように、一人のユーザから送金された通知付き電子マネーと、通常電子マネーとのいずれかを選択して支払いを行う例を示したが、これに限定されない。
2以上のユーザから送金された各々の通知付き電子マネーと、通常電子マネーとから、いずれかの電子マネーを選択することができるようにしてもよい。
図4-6左側は、端末20Aの表示部24に表示される支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側には、2つの通知付き電子マネー送金結果情報が表示されている。
時刻が新しい方の通知付き電子マネー送金結果情報NR46は、ユーザC.CからユーザA.Aに対して送金された「2,000円」の通知付き電子マネーの送金結果情報であり、通知先として送金元アカウントのユーザであるユーザC.Cが設定されたものである。
具体的には、ユーザB.BからユーザA.Aに対して送金された「1,000円」の通知付き電子マネーに対応する残高が、「通知付き」の文字およびユーザB.Bに対して通知がなされることを示すイラストとともに表示されている。同様に、ユーザC.CからユーザA.Aに対して送金された「2,000円」の通知付き電子マネーに対応する残高が、「通知付き」の文字およびユーザC.Cに対して通知がなされることを示すイラストとともに表示されている。
また、その下には、通常電子マネー残高(この例では「500円」)と、チャージボタンCBTとが表示されている。
このコード支払い画面では、ウォレットコード情報表示領域WCR1の残高に関する情報が表示される領域に、ユーザB.Bから送金された通知付き電子マネーの残高と、ユーザC.Cから送金された通知付き電子マネーの残高と、通常電子マネー残高とのいずれの残高から支払いを行うかを選択するための情報が表示されている。
同様に、ユーザC.Cから送金された通知付き電子マネーの残高から支払いを行うための「通知付き」の文字と、通知付き電子マネー残高(この例では「2,000円」)と、その残高から支払いが行われるとユーザC.Cに対して通知がされることを示すイラストとが表示されている。
また、その下には、「通常電子マネー残高」から支払いを行うための「通知なし」の文字と、通常電子マネー残高(この例では「500円」)と、電子マネーを通常電子マネー残高にチャージするためのチャージボタンCBTとが表示されている。
おしらせ領域内の向かって左側には、通知付き電子マネー送金結果情報NR48が表示されている。この通知付き電子マネー送金結果情報NR48には、限定ではなく例として、送金金額(この例では「2,000円」)と、送金日時と、通知付き電子マネーの送金元であることを示す「送金」アイコンと、送金元と送金先とをイラスト化した情報と、「>詳細を確認」ボタンとが含まれる。
上記の実施例において、通知先アカウントとして、2以上のアカウントを設定可能としてもよい。
限定ではなく前述した親子の例において、母親のアカウントを送金元アカウントとする。この場合、母親の端末20が第1端末となる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末20が第2端末となる。
また、限定ではなく例として、母親のアカウントと父親のアカウントとの2つのアカウントを通知先アカウントとして設定する。この場合、母親の端末20と父親の端末20との2つの端末20が第3端末となる。
この場合、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、母親のアカウントと父親のアカウントとのそれぞれに対して通知がいくようにすることができる。
第4実施例において、コード支払い等によって支払いが行われようとしているタイミングで、通知付き電子マネーが使用されようとしていることを示す情報(以下、「通知付き電子マネー使用企図情報」と称する。)が、通知先アカウントのユーザの端末20に送信されるようにするなどして、通知付き電子マネーが使用されようとしていることを通知先アカウントに通知するようにしてもよい。
前述した各種の実施例では、送金元アカウントによって通知付き電子マネー送金設定処理を行うこととしたが、これに限定されない。
第4実施例で説明したように、送金元アカウントと通知先アカウントとを異ならせることが可能である。
第5実施例は、通知付き電子マネーの少なくとも一部を銀行口座等へ出金することに関する実施例である。銀行口座等へ出金された通知付き電子マネーは、現金として引き出しが可能となる。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図5-1,図5-2は、本実施例において端末20の表示部24に表示される画面の一例を示す図である。
図5-1左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面の一例を示す図であり、残高表示領域BR2には、ユーザB.Bを通知先アカウントのユーザとする通知付き電子マネー残高と、通常電子マネー残高と、チャージボタンCBTとが表示されている。
おしらせ領域内の向かって左側の通知付き電子マネー送金結果情報NR51の下に、ユーザA.Aによって通知付き電子マネーが出金されたことを示す通知付き電子マネー出金情報NW51が表示されている。具体的には、出金日時とともに、「A.Aに送金した電子マネーが出金されました。」の文字が表示され、その下に、出金金額(この例では「1,000円」)と、「>詳細を確認」ボタンとが表示されている。
本実施例における処理では、図1-12,図1-13等の前述した各種のフローチャートの処理において、端末20Aの制御部21は、限定ではなく例としてA140のステップの後、入出力部23に対して出金を要求するユーザ入力がなされたか否かを判定する。そして、なされたと判定したならば、限定ではなく例として、アプリケーションIDと、出金先と、出金元残高と、出金依頼金額とを含む出金依頼情報を、通信I/F22によってサーバ10に送信する。
また、サーバ10の制御部11は、出金元残高が通知付き電子マネー残高であった場合、通知付き電子マネー出金情報を、通信I/F14によって端末20Bに送信する。
本実施例は、サーバ10が、送金先アカウントのユーザにより通知付き電子マネーの少なくとも一部が出金された場合、通知付き電子マネー出金情報を通知先アカウントのユーザの端末20に通信I/F14によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が出金された場合、それに関する内容を、第3端末のユーザに知らせることができる。
しかし、本実施例のように、通知付き電子マネーが出金された場合に、通知先アカウントに通知がいくようにすることで、上記のような事態を防止できる。
上記の問題に鑑み、第5実施例とは異なる手法の1つとして、通知付き電子マネーを出金することを不可とすることも可能である。
図5-3左側,図5-3中央の画面は、図5-1左側,図5-1中央の画面とそれぞれ同様である。
本変形例において図5-3中央の画面において「決定」ボタンBT51がタップされると、限定ではなく例として、図5-3右側の表示がなされる。
このような構成により得られる実施例の効果の一例として、第2端末により第1電子貨幣の少なくとも一部を出金することに関する情報を通信部によって受信した場合、出金が不可であることを第2端末のユーザに知らせることができる。
上記の実施例では、銀行口座等への出金が行われると通知先アカウントに通知が送信されることとしたが、これに限定されない。限定ではなく例として、支払いアプリケーションに現金自動預け払い機(ATM)等からの現金出金機能が搭載されている場合、通知付き電子マネー残高がATMを用いて出金されると、通知先アカウントのユーザの端末20Bに通知が送信されるようにしてもよい。
第6実施例は、支払いアプリケーションに代えて、またはこれに加えて、メッセージングアプリケーションを利用する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図6-1は、本実施例において端末20の表示部24に表示される画面の一例を示す図である。
図6-1左側は、メッセージングアプリケーション(限定ではなく、チャットアプリケーションの一例)のトークルーム(限定ではなく、チャットルームの一例)の画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Messaging App」の文字が表示されている。また、画面最上部右方には、この端末20Aのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名(この例ではユーザA.A)が表示されている。
また、トーク領域内の向かって右側には、ユーザA.Aを送信元とするお礼を述べるテキストコンテンツTC62が表示されている。
このトークルーム画面は、トーク相手をユーザA.Aとする一対一トークルーム画面であり、トーク領域内の向かって左側に、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツNRC62が表示され、その下には、ユーザA.Aを送信元とする、前述したお礼を述べるテキストコンテンツTC62が表示されている。
また、その下には、支払いアプリケーションを送信元とするコンテンツとして、ユーザA.Aによって通知付き電子マネーが使用されたことを示す通知付き電子マネー使用コンテンツNUC62が表示されている。
本実施例における処理は、限定ではなく例として、サーバ10にメッセージングアプリケーションによるメッセージングサービスを提供する機能を持たせ、第1実施例~第5実施例で説明した処理を、メッセージングサービスの処理と組み合わせることによって実現可能である。
本実施例は、サーバ10が、通知付き電子マネー使用情報を、通知先アカウントのユーザを含むチャットルーム(限定ではなく、第1チャットルームの一例)に送信する制御を制御部11によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第2端末のユーザにより第1電子貨幣の少なくとも一部が使用されたことに関する内容を、第3端末のユーザを含む第1チャットルームへの表示という分かり易い形で、第3端末のユーザに知らせることができる。
メッセージングアプリケーションにおいて3以上のアカウントを含むグループを構成し、送金先アカウントのユーザによって通知付き電子マネーが使用されることに基づいて、その他のアカウントのユーザに通知がいくようにすることも可能である。
このグループトークルーム画面では、トーク領域内の向かって左側に、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツNRC64が表示され、その下には、ユーザA.Aを送信元とするテキストコンテンツTC62と、ユーザC.Cを送信元とするテキストコンテンツTC64とが表示されている。
この場合、サーバ10の制御部11は、限定ではなく例として、前述したように、通知付き電子マネー使用コンテンツを、グループに含まれる各々のユーザの端末20に送信するようにすることができる。
なお、これとは異なり、サーバ10の制御部11は、通知付き電子マネー使用コンテンツを、送金先アカウントのユーザの端末20には送信しないようにしてもよい。
メッセージングアプリケーションのコンテンツに含まれる情報を引用して、コンテンツを送信することを可能としてもよい。
図6-3左側は、端末20Bの表示部24に表示されるメッセージングアプリケーションのトークルーム画面であり、トーク相手を支払いアプリケーションの公式アカウントとするOAトークルームの画面の一例である。
また、トーク領域の一部に重畳するように、キーボード領域と、その上にリプライ領域とが表示されている。
この例では、コンテンツ入力領域CIRとは異なる領域であって、ユーザによるコンテンツの入力が可能ではない領域として、引用情報表示領域QIRが表示されている。
コンテンツの送信元(送信者)に関する情報には、限定ではなく例として、送信元の名称(アカウント名、ユーザ名)やアイコン画像等を含めることができる。
この例では、キーボードを用いてユーザB.Bによって「漫画買ってないでしょうね?」のテキストがコンテンツ入力欄に入力され、送信ボタンがタップされた状態が示されている。
具体的には、ユーザA.Aを送信元とするテキストコンテンツTC62の下に、ユーザB.Bを送信元とするコンテンツとして、図6-3中央の画面の引用情報として表示されていた支払いアプリケーションのアイコン画像およびその名称(Payment App)を含む第2引用情報と、図6-3中央の画面でユーザB.Bによって入力された「漫画買ってないでしょうね?」とを含む引用応答コンテンツ(リプライコンテンツ)QC61が表示されている。また、その下には、ユーザA.Aから送信された「ちゃんと参考書買ったよ」のテキストを含むテキストコンテンツTC66が表示されている。
なお、この例とは異なり、ユーザB.Bによって入力されたコンテンツを、第2引用情報の上の領域に表示させてもよい。
ただし、これに限定されるわけではなく、引用応答コンテンQC61に「>詳細を確認」ボタンを含めるようにしてもよい。
また、ユーザによって入力されたコンテンツとともに送信する第2引用情報は、引用元コンテンツに含まれる全ての情報としてもよいし、一部の情報としてもよい。
また、第1引用情報と第2引用情報とは、完全に同一の情報としてもよいし、一部が相違する情報としてもよい。
また、上記の例とは異なり、コンテンツの送信元(送信者)に関する情報を引用情報表示領域QIRに表示させないようにしてもよい。
図6-4左側は、トーク相手をグループ「家族」とするグループトークルーム画面の一例を示す図であり、トーク領域内の向かって左側には、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツNRC64と、ユーザA.Aを送信元とする「おこずかいありがとう!」のテキストを含むテキストコンテンツTC67と、ユーザA.Aに送金した通知付き電子マネーが使用されたことに基づく通知付き電子マネー使用コンテンツNUC64とが時系列に表示されている。
この画面は、図6-4左側のトークルーム画面に対応する画面であり、図6-4左側のトークルーム画面における通知付き電子マネー使用コンテンツNUC64の下に、支払いアプリケーションを送信元とするコンテンツとして、定期送金設定が行われたこと(または定期送金設定が変更されたこと)を示す定期送金設定コンテンツNSC61が表示されている。定期送金設定コンテンツNSC61では、定期送金の送金額が「5,000円」から「3,000」円に減額されたことが示されている。
本実施例では、端末20(限定ではなく例として、送金元アカウントのユーザの端末20)の制御部21は、自己の端末20の表示部24に表示されたメッセージングアプリケーションのトークルームにおける一のコンテンツ(限定ではなく例として、通知付き電子マネー使用コンテンツ)に対する入力に基づいて、そのコンテンツに対応させて機能選択領域を表示させる。
これを受けて、サーバ10の制御部11は、受信した情報に基づいて引用応答コンテンツを生成し、通信I/F14によってトーク相手の端末20に送信する。
そして、トーク相手の端末20の制御部21は、受信した引用応答コンテンツを、自己の端末20の表示部24のトークルームに表示させる。
これを受けて、サーバ10の制御部11は、受信した設定情報に基づいて定期送金設定コンテンツを生成し、通信I/F14によってトーク相手の端末20に送信する。
そして、トーク相手の端末20の制御部21は、受信した定期送金設定コンテンツを、自己の端末20の表示部24のトークルームに表示させる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザと第2端末のユーザとを含むチャットルームに表示された通知への入力が、第1端末のユーザによって行われたことに基づいて、設定された期間ごとに、通知の設定が行われた電子貨幣が第2端末のユーザに対して送金される金額を第1端末のユーザが入力できるようにすることを可能とすることができる。
第7実施例は、通知付き電子マネー残高の使用に制限を加えることを可能にする実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
アカウント管理データベース155Fに含まれる各々のアカウント管理データには、アプリケーションIDと、通常電子マネー残高との他に、限定ではなく例として、制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。
限定ではなく例として、ユーザB.Bの同じアカウントからユーザA.Aの同じアカウントに対して、制限付き電子マネーが送金されたような場合であっても、それぞれ異なるIDが設定される。
決済IDと、送金管理IDと、使用店舗名と、使用日時と、使用金額とは、限定ではなく例として、前述した通知付き電子マネー使用履歴データと同様に構成することができる。
図7-2・図7-3・図7-4は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。
図7-2左側には、端末20Bの表示部24に表示される支払いアプリケーションの送金画面の一例を示している。この送金画面では、画面中央部から下部にかけて、前述した送金先アカウントのユーザを示す情報とともに、前述した通知付き電子マネー使用通知を受け取るか否かを選択するためのスライドボタンが設けられている。さらに、その下には、通知付き電子マネー残高の使用に制限をかけるか否かを選択するためのスライドボタンが設けられている。
なお、この例では、制限付き電子マネーの使用を制限する内容として「制限時間」が設定済みであることとして説明する。
図7-2中央は、この場合に端末20Aの表示部24に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面では、おしらせ領域内の向かって左側に、制限付き電子マネーが送金されたことを示す制限付き電子マネー送金結果情報RR71が表示されている。
また、制限付き電子マネーを使用するとユーザB.Bに通知付き電子マネー使用通知がされることを示すイラストの右には、注意マーク/工事マークに類する、通知付き電子マネーの使用に制限がかけられていることを示すマーク(以下、「制限マーク」と称する。)RMKが表示されている。
このコード支払い画面では、ウォレットコード情報表示領域WCR1内の上部の残高が表示される領域に、制限付き電子マネー残高に関する情報と、制限なしの電子マネー残高(つまり通常電子マネー残高)に関する情報とが表示されている。
「制限付き」と示された残高が制限付き電子マネー残高であるが、上記のように、制限付き電子マネーw使用するにはユーザB.Bの許可が必要であり、ユーザA.AはユーザB.Bからまだ許可を得ていない状態である。このため、制限付き電子マネーの残高に関する情報の表示部分はグレーアウトしており、ユーザA.Aが「制限付き」の文字の左に設けられたラジオボタンをタップしても「ON」にすることができないようになっている。
おしらせ領域の制限付き電子マネー送金結果情報RR71の下には、ユーザB.Bによって制限付き電子マネーの使用が許可されたことを示す制限付き電子マネー使用許可情報RP71が表示されている。
なお、この例において制限付き電子マネーを使用することのできる期間は、限定ではなく例として、端末20Bから送信される制限付き電子マネーの使用を許可・承認する情報(後述する制限付き電子マネー使用承認情報)をサーバ10が受信してから設定時間(この例では「60分」間)が経過するまでの間とすることができる。
ユーザB.Bによって制限付き電子マネーの使用が許可されたことで、図7-2右側のコード支払い画面においてウォレットコード情報表示領域WCR1に表示されていた制限付き電子マネーの残高に関する情報の表示部分のグレーアウトが解除され、ユーザA.Aが「制限付き」の文字の左に設けられたラジオボタンをタップして「ON」とすることが可能となっている。そして、ここでは、ラジオボタンが「ON」とされた状態が示されている。この状態でコード支払いを行うことで、図7-4右側のように決済結果情報が表示される。
図7-5~図7-6は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
まず、端末20Bの制御部21は、入出力部23に対するユーザ入力等に基づいて、制限付き電子マネーの送金に関する設定処理として、制限付き電子マネー送金設定処理を行う(B410)。
具体的には、サーバ10の制御部11は、アカウント管理データベース155Fに含まれるアカウント管理データのうち、送金先アカウントのユーザであるユーザA.A(または端末20A)のアカウントに対応するアカウント管理データを、端末20Bから受信した通知付き電子マネー送金依頼情報に含まれる設定情報に基づいて更新する。
また、サーバ10の制御部11は、電子マネー使用制限管理データの使用可否フラグとして、限定ではなく例として、初期値として「不能」のフラグを設定する。
端末20Aの制御部21と、端末20Bの制御部21とは、サーバ10から受信した制限付き電子マネー送金結果情報を受信すると、それぞれ表示部24に表示させる(A410,B430)。
使用承認が選択されない場合(B440:NO)、端末20Bの制御部21は、B450のステップをスキップする。
具体的には、サーバ10の制御部11は、限定ではなく例として、アカウント管理データベース155Fに含まれるアカウント管理データにおける電子マネー使用制限管理データから、制限付き電子マネー使用承認情報で指定される送金管理IDの使用可否フラグを「不能」から「可能」に変更する。また、使用可能状態終了日時に、所定の日時(限定ではなく例として、制限付き電子マネー使用承認情報を受信してから60分後)を記憶させる。
支払いを行う残高として指定された制限付き電子マネー残高の使用可否フラグが「不能」である場合、または、使用可能状態終了日時を過ぎている場合、サーバ10の制御部11は、指定された制限付き電子マネー残高を用いた決済を失敗と判定する。なお、使用可能状態終了日時を過ぎている場合、サーバ10の制御部11は、指定された制限付き電子マネー残高の使用可否フラグを「可能」から「不能」に変更し、使用可能状態終了日時を消去するようにしてもよい。
なお、残高不足や使用制限等で制限付き電子マネー残高を用いた決済が失敗する場合、サーバ10の制御部11は、通常電子マネー残高に切り替えて決済を実行するようにしてもよい。
支払いを行う残高として通常電子マネー残高が指定される場合、サーバ10の制御部11は、通常電子マネー残高を用いて決済を実行する。
使用しなかったと判定したならば(S460:NO)、サーバ10の制御部11は、処理を終了する。
一方、使用したと判定したならば(S460:YES)、サーバ10の制御部11は、通信I/F14によって、制限付き電子マネー使用情報を端末20Bに送信する(S470)。そして、サーバ10の制御部11は、処理を終了する。
受信しなかったと判定したならば(B460:NO)、端末20Bの制御部21は、処理を終了する。
一方、受信したと判定したならば(B460:YES)、端末20Bの制御部21は、受信した制限付き電子マネー使用情報を表示部24に表示させる(B470)。そして、端末20Bの制御部21は、処理を終了する。
上記の実施例では、制限付き電子マネー残高が使用されると通知先アカウントに通知される例を示したが、これに限定されない。限定ではなく例として、制限付き電子マネー残高が使用されても、送金者等の第三者に通知されないようにしてもよい。
上記の実施例では、制限付き決済処理において制限付き電子マネー残高の使用が出来ない場合が存在したが、これに限定されない。限定ではなく例として、制限付き決済処理において制限付き電子マネー残高の使用を常に認めるようにしてもよい。
この場合、限定ではなく例として、所定の送金管理IDにおいて、電子マネー使用制限管理データにその送金管理IDを記憶させないようにしてもよい。または、所定の送金管理IDにおいて、電子マネー使用制限管理データの使用可否フラグを永続的に「可能」とし、使用可能状態終了日時を十分に先の未来(限定ではなく例として、50億年後)に設定してもよい。このとき、制限付き決済処理において制限付き電子マネー残高の使用には制限が存在しないことと等価となる。
上記の実施例では、通常電子マネー残高と制限付き電子マネー残高を区別していたが、これに限定されない。限定ではなく例として、通常電子マネー残高を、制限付き電子マネー管理データにおいて通知先ID・通知者名無し、電子マネー使用制限管理データにおいて制限付き決済処理における使用制限なしの制限付き電子マネー残高としてもよい。この場合、制限付き電子マネー管理データにおいて、限定ではなく例として、送金管理IDは電子マネーのチャージ時に生成されるIDとし、送金元IDはアプリケーションIDと同一にすることができる。
(1)使用に関する制限が存在し、使用されると送金者等の第三者に通知される「通知付き制限付き電子マネー残高」。
(2)使用に関する制限が存在するが、使用しても第三者に通知されない「通知無し制限付き電子マネー残高」。
(3)使用に関する制限が存在せず、使用されると第三者に通知される(使用すると通知されるという制限が存在する)「通知付き制限無し電子マネー残高(通知付き電子マネー残高)」。
(4)使用に関する制限が存在せず、使用しても第三者に通知されない(制限が存在しない)「通知無し制限無し電子マネー残高(通常電子マネー残高)」。
上記の実施例では、制限付き決済処理における残高使用の制限として、予め送金者の承認が必要である例を示したが、これに限定されない。
制限付き決済処理における残高使用の制限として、限定ではなく例として、特定の業種・業態の店舗やサービスにおいて支払いを行う残高として用いることができないようにしてもよい。
アカウント管理データベース155Gにおいて、電子マネー使用制限管理データには、限定ではなく例として、送金管理IDと、使用禁止店舗業種とが関連付けて記憶される。
図7-7では、限定ではなく例として、送金管理ID「T01003」で管理される制限付き電子マネー残高は、「アパレル」、「家具・家電」、「居酒屋・パブ」の業種に分類される店舗・サービスでは使用できないことが記憶されている。
図7-8は、制限付き電子マネーの使用制限の別例に関する表示画面の一例を示す図である。
図7-8左側は、端末20Bの表示部24に表示される支払いアプリケーションの送金画面の一例を示す図であり、図7-2左側の画面に対応する画面図である。
この例では、制限付き電子マネーの使用を制限する内容が未だ設定されていない状態であるため、画面下部の「送金」ボタンがグレーアウトして表示されている。
前述した「使用制限を設定」ボタンBT71がタップされると、図7-8中央のような表示がなされる。
この例では、「コンビニ」、「スーパー・ホームセンター」、「アパレル」、「家具・家電」、「居酒屋・パブ」、「コーヒーショップ」等の複数の店舗の業種が、それぞれイラストと業種名とを含むボックスで一覧表示されている。
おしらせ領域内の向かって左側には、制限付き電子マネー送金結果情報RR73が表示されている。この制限付き電子マネー送金結果情報には、ユーザB.Bによって設定された制限付き電子マネーの使用を禁止する業種に対応するイラストが含まれる。具体的には、禁止マークおよび「以下の店舗では利用できません」の文字とともに、「アパレル」、「家具・家電」、「居酒屋・パブ」の3つの業種に対応するアイコンが表示されている。
具体的には、支払い金額が「1,000円」であり、制限付き電子マネー残高が「1,000円」であるため、実際には金額は足りている。しかし、制限付き電子マネー残高の使用が禁止されているため制限付き電子マネー残高「1,000円」は支払いに使用することができない。このため、支払い金額「1,000円」に対して「1,000円」不足していることになり、残高不足となる。
なお、この例では、制限付き電子マネー残高のみが支払いに使用され、通常電子マネー残高は支払いに使用されないようにしている。
図7-5のS410のステップにおいて、サーバ10の制御部11は、限定ではなく例として、端末20Bから受信した通知付き電子マネー送金依頼情報に含まれる設定情報に基づいて、電子マネー使用制限管理データの使用禁止店舗業種を更新する。
支払いを行う残高として指定された制限付き電子マネー残高の使用禁止店舗業種が決済要求情報から判定される業種・業態と一致する場合、サーバ10の制御部11は、指定された制限付き電子マネー残高を用いた決済を失敗と判定する。
・送金元アカウントや通知先アカウント等における使用承認。
・制限付き電子マネー残高が使用されることに関する通知。
・制限付き電子マネー残高が使用可能な日時・時間帯(限定ではなく例として、遠足の日や土日、11:00~13:00までの時間帯はは使用できる等)。
・制限付き電子マネー残高が使用不能な日時・時間帯(限定ではなく例として、平日や22:00~6:00までの深夜時間帯は使用できない等)。
・決済を行う店舗・サービス事業者の業種・業態における使用制限(限定ではなく例として、決済要求情報に含まれる決済店舗の識別情報に基づいて、店舗・サービスの業種や業態による使用可能・不能を設定する等)
・決済を行う商品・サービスの品目における使用制限(限定ではなく例として、端末によって撮像された商品画像または決済要求情報に含まれるJANコードやEANコード等に基づいて、使用可能な商品・サービスを設定する等。より具体的には、限定ではなく例として、プラモデルの購入には使用できるがゲームソフトの購入には使用できない等。)
・決済金額に関する使用制限(限定ではなく例として、決済金額が1000円以下であれば使用できる等)
・端末位置における使用制限(限定ではなく例として、自宅から半径5km以内であれば使用できる等)
・出金に関する制限(限定ではなく例として、制限付き電子マネー残高からATMによる現金での出金や銀行口座への出金ができない等)
・制限付き電子マネー残高が初めて使用された時点からの有効期限。
・制限付き電子マネー残高が使用される回数(限定ではなく例として、「10回」使用可能である等)。
・上記の制限の任意の組み合わせ。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザが第1電子貨幣を使用した場合に第1情報処理装置のユーザに通知を行うことに関する制限、第1電子貨幣を使用可能な店舗に関する制限、第1電子貨幣を使用可能な商品またはサービスに関する制限、第1電子貨幣を使用可能な商品またはサービスのカテゴリに関する制限、第1電子貨幣を使用不可な商品に関する制限、第1電子貨幣が使用できない時間帯に関する制限、第1電子貨幣を使用できない日にちまたは日時に関する制限といった各種の制限が、第1情報処理装置のユーザによって第1電子貨幣に設定されるようにすることを可能とすることができ、第1情報処理装置のユーザの利便性を向上させることができる。
上記の実施例では、支払いの時に制限付き電子マネー残高を用いているが、これに限定されない。
限定ではなく例として、支払いにおいて通常電子マネーを使用した後、限定ではなく例として、送金元アカウントや通知先アカウント等における使用承認に基づいて、制限付き電子マネー残高から通常電子マネー残高に残高を変換するようにしてもよい。すなわち、支払いの時点では制限付き電子マネーが使用できない場合でも、通常電子マネーを用いて立て替えて支払うことで、支払い後に制限付き電子マネー残高を使用できるようにしてもよい。
図7-10左側は、図7-9中央の画面と同様のコード支払い画面である。
この例では、チャージボタンCBTがタップされてユーザA.Aによって電子マネーが「500円」分チャージされ、通常電子マネー残高が「500円」から「1,000円」に増加した状態が示されている。この状態で「1,000円」のコード支払いを行うと、限定ではなく例として、図7-10中央の決済結果情報が表示される。
この例では、通常電子マネーが支払いに使用されたことで、「制限なし」からの支払いが「1,000円」であることが示されている。
このおしらせ画面には、制限付き電子マネー送金結果情報RR74の下に、制限付き電子マネーの使用を許可するか否かを確認するための制限付き電子マネー使用確認情報RV74が表示されている。この情報に含まれる「許可する」ボタンがタップされ、ユーザA.Aに送金した制限付き電子マネーの使用を許可することがユーザB.Bによって選択されると、図7-11中央に示すように、おしらせ領域にその旨(「許可する」のテキスト)が表示される。ただし、この制限付き電子マネーの使用の許可は、この例では、制限付き電子マネー残高から通常電子マネー残高に残高を変換することの許可である。
商品やサービスの返品時等において、返金が発生した場合、決済時に制限付き電子マネー残高が使用された場合には、返金される金額を決済時に使用した制限付き電子マネー残高に加算するようにしてもよい。この場合、処理としては、限定ではなく例として、第2変形例と同様に処理を実行することができる。
前述の実施例では、サーバ10が、決済処理(制限付き決済処理)において、通常電子マネーと制限付き電子マネーとのうちのいずれか一方の電子マネーを用いて決済を実行していた。
第8実施例は、通常電子マネーと、1つの制限付き電子マネーとを用いて決済を行う実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図8-1は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。。
図8-1左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、「コード支払い」アイコンがタップされた状態が示されている。
すると、限定ではなく例として、図8-1中央のようなコード支払い画面が表示される。
図8-2~図8-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
・制限付き電子マネー残高を優先使用。
「第1支払い金額」=「制限付き電子マネー残高」(「第2支払い金額」=「決済要求情報の支払い金額」-「第1支払い金額」)
・通常電子マネー残高を優先使用。
「第2支払い金額」=「通常電子マネー残高」(「第1支払い金額」=「決済要求情報の支払い金額」-「第2支払い金額」)
・それぞれの残高の比率に合わせて使用。
「第1支払い金額」:「第2支払い金額」=「制限付き電子マネー残高」:「通常電子マネー残高」
以下では、支払いに用いる残高の優先順位を「使用残高優先順位」と称する。
制限付き決済処理と決済処理とのうちの少なくとも一方が失敗する場合、連続制限付き決済処理は決済失敗(決済不可)となる。連続制限付き決済処理が失敗する場合、限定ではなく例として、制限付き決済処理または決済処理のうち、決済が成功した処理について、その処理を取り消し、残高を戻す。
本実施例は、端末20B(限定ではなく、第1情報処理装置の一例)と通信する端末20A(限定ではなく、情報処理装置の一例)によって実行されるプログラムであって、ユーザB.B(限定ではなく、第1情報処理装置のユーザの一例)によって通知を含む利用制限(限定ではなく、制限の一例)が設定され、第1情報処理装置から送金された制限付き電子マネー残高(限定ではなく、第1電子貨幣の一例)の第1支払い金額(限定ではなく、第1電子貨幣の少なくとも一部の一例)と、ユーザA.A(限定ではなく、情報処理装置のユーザの一例)に関連付けられた通常電子マネー残高(限定ではなく、第2電子貨幣の一例)の第2支払い金額(限定ではなく、第2電子貨幣の少なくとも一部の一例)とに基づいて、連続制限付き決済処理を行うためのウォレットコード情報表示処理(限定ではなく、第1決済に関する処理の一例)を情報処理装置の制御部によって行うことが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第1情報処理装置のユーザによって制限が設定され、第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて第1決済に関する処理が行われることで、限定ではなく例として、少なくとも制限が設定された第1電子貨幣を含む少なくとも2つの電子貨幣を用いた決済を実現することができる。
しかし、これに限定されず、限定ではなく例として、情報処理装置を、制限付き電子マネーの送金先アカウントのユーザの端末20とし、第1情報処理装置を、サーバ10とするなどすることも可能である。
なお、これら以外の組合せとすることも可能である。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、設定された条件に基づいて、決済に使用する第1電子貨幣と第2電子貨幣とが適切に選択されるようにすることができる。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第1情報処理装置のユーザによって制限が設定され、第1情報処理装置から送金された第1電子貨幣が優先的に決済に使用されるようにすることができる。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザが第1電子貨幣を使用した場合に第1情報処理装置のユーザに通知を行うことに関する制限、第1電子貨幣を使用可能な店舗に関する制限、第1電子貨幣を使用可能な商品またはサービスに関する制限、第1電子貨幣を使用可能な商品またはサービスのカテゴリに関する制限、第1電子貨幣を使用不可な商品に関する制限、第1電子貨幣が使用できない時間帯に関する制限、第1電子貨幣を使用できない日にちまたは日時に関する制限といった各種の制限が、第1情報処理装置のユーザによって第1電子貨幣に設定されるようにすることを可能とすることができ、第1情報処理装置のユーザの利便性を向上させることができる。
このような構成により得られる実施例の効果の一例として、第1情報処理装置のユーザによって制限が設定された、第1情報処理装置から第2情報処理装置に送金された第1電子貨幣と、第2情報処理装置のユーザとを関連付けるとともに、第2電子貨幣と第2情報処理装置のユーザとを関連付けた上で、第2情報処理装置から送信された情報に基づいて、第1電子貨幣の少なくとも一部と、第2電子貨幣の少なくとも一部とに基づく第1決済を実現することができる。
このような構成により得られる実施例の効果の一例として、第1電子貨幣の少なくとも一部が第2情報処理装置のユーザによって使用された場合、それに関する内容を第1情報処理装置のユーザに知らせることができる。
上記の実施例では、制限付き電子マネー残高と通常電子マネー残高とが自動的に両方使用される例を示したが、これに限定されない。
限定ではなく例として、支払いを行う端末20のユーザによる入力に基づいて、使用する電子マネー(残高)が決定されるようにしてもよい。
図8-4左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、図8-1左側の画面と同様である。「コード支払い」アイコンIC2がタップされると、図8-4中央のコード支払い画面が表示される。
限定ではなく例として、端末20Aの制御部21は、ウォレットコード情報を表示すると(A130)、限定ではなく例として、入出力部23に対するユーザ入力に基づいて、制限付き電子マネー残高と通常電子マネー残高とを使用するか否かの設定を含む制限付き電子マネー使用選択情報を通信I/F22によってサーバ10に送信する(A510)。
このような構成により得られる実施例の効果の一例として、決済に使用する第1電子貨幣と、第2電子貨幣とを情報処理装置のユーザに選択させることが可能となり、情報処理装置のユーザの利便性を向上させることができる。
上記の実施例では、第1支払い金額と第2支払い金額とは、限定ではなく例として、予めサーバ10のユーザによって設定された使用残高優先順位に従って決定されたが、これに限定されない。
限定ではなく例として、使用残高優先順位は、支払いを行う端末20のユーザによる入力に基づいて、決定されるようにしてもよい。
図8-6左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、「コード支払い」アイコンIC2がタップされた状態が示されている。すると、図8-6中央のコード支払い画面が表示される。
このコード支払い画面では、ウォレットコード情報表示領域WCR1に表示される情報として、制限付き電子マネー残高(「制限付き」)と通常電子マネー残高(制限なし)とが別々に表示されており、制限付き電子マネー残高(「制限付き」)が上に、通常電子マネー残高(制限なし)がその下に表示されている。
通信I/F14によって端末20Aから制限付き電子マネー使用選択情報を受信すると、サーバ10の制御部11は、制限付き電子マネー使用選択情報の使用残高優先順位(使用比率)に基づいて、使用残高算出処理を実行し(S500)、連続制限付き決済処理を実行する(S510)。なお、サーバ10の制御部11は、端末20Aから制限付き電子マネー使用選択情報を受信しない場合、限定ではなく例として、サーバ10のユーザによって予め設定された使用残高優先順位(使用比率)に基づいて、使用残高算出処理を実行し、連続制限付き決済処理を実行するようにしてもよいし、そうしなくてもよい。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザの意向を反映した条件に基づいて、決済に使用する第1電子貨幣と第2電子貨幣とが選択されるようにすることができる。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣から決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。
上記の実施例では、サーバ10は、連続制限付き決済処理の実行後、使用された制限付き電子マネー残高と通常電子マネー残高とを含む決済結果情報を端末20Aに送信していたが、これに限定されない。
限定ではなく例として、連続制限付き決済処理において、サーバ10の制御部11は、第1支払い金額と第2支払い金額とが定まると、端末20Aに第1支払い金額と第2支払い金額とを送信するようにしてもよい。
図8-7左側のコード支払い画面において、ウォレットコード情報表示領域WCR1に表示されているウォレットコード情報が店舗のコードリーダによって読み取られると、図8-7中央の表示がなされる。
この例では、限定ではなく例として、支払い先や支払い金額の他、第1支払い金額を含む制限付き電子マネー使用確認情報が端末20Aに送信される。その結果、限定ではなく例として、支払い先(この例では「XX書店」)と、支払い金額(この例では「1,200円」)と、第1支払い金額(この例では制限付き電子マネーの「1,000円」)とを含む制限付き電子マネー使用確認情報が表示されている。
具体的には、限定ではなく例として、第1支払い金額と第2支払い金額との両方の金額を表示させるようにしてもよい。この場合、サーバ10は、第1支払い金額と第2支払い金額とを含む制限付き電子マネー使用確認情報を端末20Aに送信するようにすることができる。
通信I/F14によって店舗POSシステム40から決済要求情報を受信すると、サーバ10の制御部11は、第1支払い金額と第2支払い金額とを算出する(S500)。そして、サーバ10の制御部11は、算出された第1支払い金額を少なくとも含む制限付き電子マネー使用確認情報を通信I/F14によって端末20Aに送信する。
本変形例は、通知先アカウントへの通知内容に関する変形例である。
図8-9は、本変形例における端末20の表示部24に表示される画面の一例を示す図である。
図8-9左側には、端末20Aの表示部24に決済結果情報が表示された状態が示されている。この例では、制限付き電子マネー残高からの第1支払い金額が「700円」であり、通常電子マネー残高からの第2支払い金額が「500円」であり、合計「1,200円」の決済が行われたことが示されている。
この例では、制限付き電子マネー送金結果情報RR81の下に、制限付き電子マネー使用情報RU81が表示されている。この電子マネー使用情報では、ユーザB.BがユーザA.Aに送金した制限付き電子マネー残高のうちの支払いに使用された金額(つまり第1支払い金額)を含む情報が表示されている。
具体的には、制限付き電子マネー残高から使用された金額(この例では「700円」)と、支払い先(この例では「XX書店」)と、詳細確認ボタンとを含む情報が表示されている。
前述の実施例では、連続制限付き決済処理において、通常電子マネー残高と制限付き電子マネー残高とを用いて決済を行っていた。
第9実施例は、2以上の制限付き電子マネー残高のうちの任意の2以上の残高を用いて決済を行う実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
アカウント管理データベース155Hに含まれる各々のアカウント管理データには、アプリケーションIDと、通常電子マネー残高との他に、限定ではなく例として、制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。
アカウント管理データベース155Hに含まれる各々のアカウント管理データに記憶される情報は、アカウント管理データベース155Fと同様であるが、電子マネー使用制限管理データに記憶される情報が一部異なっている。
図9-1では、限定ではなく例として、送金管理ID「T02108」で管理される制限付き電子マネー残高は、「コンビニ」、「スーパー・ホームセンター」、「書籍・文具」の業種に分類される店舗・サービスで使用できることが記憶されている。また、送金管理ID「T02571」で管理される制限付き電子マネー残高は、「書籍・文具」、「家具・家電」の業種に分類される店舗・サービスで使用できることが記憶されている。
図9-2~図9-3は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。
図9-2左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、残高領域領域には電子マネー残高として「6,500円」が表示されている。また、その内訳は、通常電子マネー残高が「2,500円」であり、制限付き電子マネー残高が「4,000円」であることが示されている。
具体的には、制限付き電子マネー残高の表示部分の下に、制限付き電子マネー残高の内訳が表示される。この例では、制限付き電子マネー残高「4,000円」の内訳は、通知先アカウントのユーザをユーザB.Bとする「1,000円」と、通知先アカウントのユーザをユーザC.Cとする「3,000円」とであることが示されている。
このコード支払い画面では、ウォレットコード情報表示領域WCR1に、図9-2左側の画面の残高表示領域BR2に表示されていた表示と同様の残高表示がなされている。ウォレットコード情報を店舗のコードリーダによって読み取ってもらうことで、サーバ10によって連続制限付き決済処理が実行され、図9-3右側の決済結果情報が表示される。
処理については、限定ではなく例として、図8-2~図8-3における使用残高算出処理(S500)において、サーバ10の制御部11は、決済要求情報の支払い金額のうち、第1制限付き電子マネー残高から支払いを行う第3支払い金額と、第2制限付き電子マネー残高から支払いを行う第4支払い金額とを算出する。
限定ではなく例として、図9-1では、送金管理ID「T02108」の残高を第1制限付き電子マネー残高に、送金管理ID「T02571」の残高を第2制限付き電子マネー残高に、それぞれ当てはめることができる。
・残高が多い制限付き電子マネー残高を優先して使用。
・残高が少ない制限付き電子マネー残高を優先して使用。
・受け取った順序が古い制限付き電子マネー残高を優先して使用。
・使用可能な制限付き電子マネー残高の制限が厳しい順に使用。
・上記の任意の組み合わせ。
・第1制限付き電子マネー残高の使用通知先の人数>第2制限付き電子マネー残高の使用通知先の人数(通知先人数が多い)。
・第1制限付き電子マネー残高の使用可能店舗・サービス業者数<第2制限付き電子マネー残高の使用可能店舗・サービス業者数(使える店舗・サービス業者が少ない)。
・第1制限付き電子マネー残高の使用可能店舗業種数<第2制限付き電子マネー残高の使用可能店舗業種数(使用可能な業種が狭い)。
・第1制限付き電子マネー残高の使用可能商品・サービス数<第2制限付き電子マネー残高の使用可能商品・サービス数(購入可能な商品・サービスが少ない)。
・第1制限付き電子マネー残高の使用可能期限<第2制限付き電子マネー残高の使用可能期限(使用不能になる期限が迫っている)。
・第1制限付き電子マネー残高の使用可能位置領域<第2制限付き電子マネー残高の使用可能位置領域(使用可能な地図範囲が狭い)。
・所定の時間内(限定ではなく例として、一週間)における第1制限付き電子マネー残高の使用可能時間<所定の時間内における第2制限付き電子マネー残高の使用可能時間(使用可能な時間帯が少ない)。
・所定の期間内(限定ではなく例として、1ヵ月間)における第1制限付き電子マネー残高の使用可能日数<所定の期間内における第2制限付き電子マネー残高の使用可能日数(使用可能な日時が少ない)。
・上記の任意の組み合わせ。
制限付き決済処理の少なくとも一方が失敗する場合、連続制限付き決済処理は決済失敗(決済不可)となる。連続制限付き決済処理が失敗する場合、限定ではなく例として、制限付き決済処理のうち、決済が成功した処理について、その処理を取り消し、残高を戻す。
なお、第3支払い金額=「0」の場合、第1制限付き電子マネー残高を用いる制限付き決済処理を実行しないようにしてもよい。また、第4支払い金額=「0」の場合、第2制限付き電子マネー残高を用いる制限付き決済処理を実行しないようにしてもよい。これらの場合、実行されない制限付き決済処理は成功したものとして取り扱う。
本実施例は、第1制限付き電子マネー残高(限定ではなく、第1電子貨幣の一例)と、第2制限付き電子マネー残高(限定ではなく、第2電子貨幣の一例)とは、残高が少ない制限付き電子マネー残高を優先して使用すること(限定ではなく、設定された条件の一例)に基づいて選択される構成を示している。
このような構成により得られる実施例の効果の一例として、設定された条件に基づいて、決済に使用される第1電子貨幣と第2電子貨幣とが適切に選択されるようにすることができる。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。
このような構成により得られる実施例の効果の一例として、制限が厳しい電子貨幣が優先的に決済に使用されるようにすることができる。
このような構成により得られる実施例の効果の一例として、残高が少ない電子貨幣や使用可能なカテゴリが狭い電子貨幣が優先的に決済に使用されるようにすることができる。
上記の実施例では、使用残高算出処理が実行されると、連続制限付き決済処理が実行されるとしたが、これに限定されない。
限定ではなく例として、使用残高算出処理が実行されると、サーバ10の制御部11は、第3支払い金額と第4支払い金額とを端末20Aに送信するようにしてもよい。
図9-4左側は、端末20Aの表示部24に表示される支払いアプリケーションのコード支払い画面であり、図9-3中央の画面に対応するものである。
ウォレットコード情報が店舗のコードリーダによって読み取られると、図9-4中央のような表示がなされる。
この例では、限定ではなく例として、支払い先(この例では「YYカメラ」)や支払い金額(この例では「3,800円」)の他、支払いに使用する制限付き電子マネーに関する情報が表示されている。
この他にも、上記の例において、通常電子マネーから支払いに使用される金額「800円」を併せて表示させるようにしてもよい。
さらに、上記の例において、支払いに使用されない制限付き電子マネー、つまり通知先アカウントがユーザB.Bのアカウントである制限付き電子マネーの支払い金額「0円」も併せて表示させるようにしてもよい。
なお、制限付き電子マネー使用確認情報として、通常電子マネー残高の使用分である第2支払い金額を含むようにしてもよい。
上記の実施例では、使用残高算出処理において、自動的に各支払い金額を算出していたが、これに限定されない。
限定ではなく例として、支払いを行う端末20のユーザによる入力に基づいて、各支払い金額が算出されるようにしてもよい。
なお、制限付き電子マネー使用選択情報には、支払いに用いる制限付き電子マネー残高(通常電子マネー残高)を指定する情報を含めるようにしてもよい。
・送金管理IDごとに残高使用順位を指定
(限定ではなく例として、残高表示欄に対するユーザ操作に基づいて、送金管理ID「T02571」の残高>送金管理ID「T02108」の残高>「通常電子マネー残高」の残高使用順位を指定。)
・残高が少ない(多い)順に使用することを指定。
・受け取った順序が古い順に制限付き電子マネー残高を使用することを指定。
・各支払い金額を直接指定
(限定ではなく例として、決済要求情報の支払い金額が「1500円」の場合、第3支払い金額=「1000円」、第4支払い金額=「500円」と指定。)
・それぞれの残高の比率に合わせて使用することを指定。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができ、情報処理装置のユーザの意に則した決済を実現することができる。
上記の実施例では、サーバ10において使用残高算出処理を実行することとしたが、これに限定されない。限定ではなく例として、使用残高算出処理の一部または全部の処理を端末20において実行するようにしてもよい。
使用残高算出処理は、1以上の制限付き電子マネー残高と、通常電子マネー残高とのうち、支払いに用いる残高を選択する処理である。また、支払い金額算出処理は、選択された残高について使用残高優先順位を設定し、各残高から支払う金額を算出する処理である。
処理パターン「全自動処理(2)」では、端末20の制御部21は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。
全自動処理は、支払いを行う端末20のユーザ意思が介在しない処理である。
処理パターン「サジェスト処理(2)」では、端末20の制御部21は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。そして、算出された各支払い金額に対して端末20のユーザが承認を行うと、連続制限付き決済処理が実行される。
サジェスト処理は、システムが決定した各支払い金額に対して端末20のユーザが承認を行う処理である。
処理パターン「規定設定処理(2)」では、限定ではなく例として、支払いに先立って、端末20に対するユーザ操作に基づいて、規定の使用残高優先順位が設定される。そして、端末20の制御部21は、規定の使用残高優先順位に基づいて、各残高から支払う金額を算出する。
規定設定処理は、端末20のユーザによって支払い前に設定された規定の使用残高優先順位に基づいて、各支払い金額が算出される処理である。
処理パターン「規定確認処理(2)」では、「規定設定処理(2)」で算出された各支払い金額に対して、連続制限付き決済処理の実行前に端末20のユーザが承認を行う。
処理パターン「都度設定処理(2)」では、支払いを行う都度、端末20に対するユーザ操作に基づいて、使用残高優先順位が設定される。そして、端末20の制御部21は、設定された使用残高優先順位に基づいて、各残高から支払う金額を算出する。
都度設定処理は、支払いを行う都度、端末20のユーザによって使用残高優先順位が設定され、各支払い金額が算出される処理である。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザの意向を反映した条件に基づいて、決済に使用する第1電子貨幣と第2電子貨幣とが選択されるようにすることができる。
このような構成により得られる変形例の効果の一例として、制限が設定された電子貨幣から決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。
このような構成により得られる変形例の効果の一例として、制限が厳しい電子貨幣が優先的に決済に使用されるようにすることができる。
このような構成により得られる変形例の効果の一例として、残高が少ない電子貨幣や使用可能なカテゴリが狭い電子貨幣が優先的に決済に使用されるようにすることができる。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。
このような構成により得られる変形例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。
上記の実施例では、複数の通知付き制限付き電子マネー残高(通知付き電子マネー残高)が使用されると、全ての通知先アカウントに通知することとしたが、これに限定されない。限定ではなく例として、通知先アカウントがユーザB.Bである制限付き電子マネー残高と、通知先アカウントがユーザC.Cである制限付き電子マネー残高とが使用されると、サーバ10の制御部11は、ユーザB.Bの端末20BまたはユーザC.Cの端末20Cのどちら一方のみに通知を送信するようにしてもよい。
商品やサービスの返品時等において、返金が発生した場合、決済時に使用された複数の制限付き電子マネー残高または/および通常電子マネー残高に対して、返金される金額を決済時に使用された金額に基づいてそれぞれの残金に加算するようにしてもよい。
サーバ10の制御部11は、制限付き電子マネー決済金額が、決済IDに対応する決済金額と等しいか否かを判定する。制限付き電子マネー決済金額が決済金額と等しい場合、通常電子マネーは決済に使用されていない。そのため、サーバ10の制御部11は、処理を終了させる。
制限付き電子マネー決済金額が決済金額と等しくない場合、通常電子マネーも決済に使用されている。そのため、サーバ10の制御部11は、通常電子マネー残高に「決済金額」-「制限付き電子マネー決済金額」で算出される金額を加算する。
第10実施例は、連続制限付き決済処理による支払い前に、制限付き電子マネー残高の制限を加味した、その支払いにおいて使用可能な合算残高を端末20のユーザが確認可能とする実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図10-1は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。ここで、制限付き電子マネー残高は図9-2と同様である。
図10-1左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、端末20Aが店舗「XX書店」に位置している場合に表示される画面の一例である。
後述する手法に基づいて、サーバ10から店舗「XX書店」に関する店舗紹介情報が端末20Aに送信され、その結果、画面下部に「XX書店へようこそ 春の参考書フェア実施中!」の文字を含む店舗紹介情報が表示されている。
また、残高表示領域には、店舗「XX書店」でユーザA.Aが使用可能である制限付き電子マネー残高と、通常電子マネー残高との総和である使用可能合算残高が表示されている。
具体的には、通常電子マネー残高は「2,500円」であり、制限付き電子マネー残高は「4,000円」である。
また、制限付き電子マネー残高のうち、通知先アカウントをユーザC.Cのアカウントとする制限付き電子マネーの残高は「3,000円」であり、使用可能な店舗の業種として「書籍・文具」、「家具・家電」が設定されている。
また、制限付き電子マネー残高のうち、通知先アカウントをユーザB.Bのアカウントとする制限付き電子マネーの残高は「1,000円」であり、使用可能な店舗の業種として「コンビニ」、「スーパー・ホームセンター」、「書籍・文具」が設定されている。
このため、残高表示領域には、通常電子マネー残高と、制限付き電子マネー残高の全額とを合算した「2,500円+4,000円=6,500円」が使用可能合算残高として表示されている。
上記の2つの制限付き電子マネーのうち「スーパー・ホームセンター」の業種の店舗で使用可能な制限付き電子マネーは、通知先アカウントをユーザB.Bのアカウントとする制限付き電子マネーのみである。
このため、残高表示領域には、通常電子マネー残高と、通知先アカウントをユーザB.Bのアカウントとする制限付き電子マネーの残高とを合算した「2,500円+1000円=3,500円」が使用可能合算残高として表示されている。
上記の2つの制限付き電子マネーのうち「家具・家電」の業種の店舗で使用可能な制限付き電子マネーは、通知先アカウントをユーザC.Cのアカウントとする制限付き電子マネーのみである。
このため、残高表示領域には、通常電子マネー残高と、通知先アカウントをユーザC.Cのアカウントとする制限付き電子マネーの残高とを合算した「2,500円+3000円=5,500円」が使用可能合算残高として表示されている。
処理については、限定ではなく例として、図8-2において、端末20Aの制御部21は、制限付き電子マネー送金結果情報を表示部24に表示させると(A410)、使用可能合算残高要求情報を通信I/F22によってサーバ10に送信する。ここで、使用可能合算残高要求情報には、限定ではなく例として、店舗に設置された不図示のビーコン装置から受信したビーコン信号や、位置算出用情報検出部29Bによって取得された位置算出用情報に基づく、限定ではなく例として、緯度・経度・高度で示される端末20Aの位置情報を含めるようにしてもよい。
使用可能合算残高算出処理において、限定ではなく例として、まず、サーバ10の制御部11は、受信した使用可能合算残高要求情報に基づいて、端末20Aの存在する店舗を判定する。そして、サーバ10の制御部11は、アカウント管理データベース155Hの電子マネー使用制限管理データを参照し、制限付き電子マネー管理データに記憶される各制限付き電子マネー残高が使用可能か否かを判定する。そして、使用可能である制限付き電子マネー残高と、通常電子マネー残高との総和である使用可能合算残高を含む使用可能合算残高情報を通信I/F14によって端末20Aに送信する。
なお、使用可能合算残高情報に、個別の使用可能であると判定された制限付き電子マネー残高を含めるようにしてもよい。
本実施例は、第1制限付き電子マネー残高(限定ではなく、第1電子貨幣の一例)と第2制限付き電子マネー残高(限定ではなく、第2電子貨幣の一例)とを含む、端末20A(限定ではなく、情報処理装置の一例)のユーザが利用可能な複数の電子貨幣のうち、連続制限付き決済処理(限定ではなく、第2決済の一例)に利用可能な使用可能合算残高(限定ではなく、電子貨幣の合計金額の一例)を情報処理装置に表示する制御を制御部によって行うことが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第1電子貨幣と第2電子貨幣とを含む、情報処理装置のユーザが利用可能な複数の電子貨幣のうち、第1決済に利用可能な電子貨幣の合計金額を情報処理装置のユーザに知らせることが可能となり、利便性を向上させることができる。
上記の実施例では、端末20Aの状態(位置・日時等)によって使用可能合算残高を算出したが、これに限定されない。
限定ではなく例として、使用可能な店舗業種ごとの使用可能合算残高を算出し、一覧として端末20Aの表示部24に表示させるようにしてもよい。
図10-2左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、図10-1左側の画面に対応するものである。
残高表示領域の「残高」の文字または残高の値(この例では「6,500円」)の表示部分がタップされると、限定ではなく例として、図10-2右側のような表示がなされる。
具体的には、業種「コンビニ」、「スーパー・ホームセンター」については使用可能合算残高として「3,500円」が、業種「書籍・文具」については使用可能合算残高として「6,500円」が、業種「家具・家電」については使用可能合算残高として「5,500円」がそれぞれ表示されている。
このような構成により得られる実施例の効果の一例として、第1電子貨幣と第2電子貨幣とを含む、情報処理装置のユーザが利用可能な複数の電子貨幣のうち、決済のカテゴリごとに利用可能な金額を情報処理装置のユーザに知らせることが可能となり、利便性を向上させることができる。
第11実施例は、送金元アカウントのユーザから送金先アカウントのユーザに送金された制限付き電子マネー残高の残余を、所定の条件に基づいて、送金元アカウントのユーザ等に送金(返金、返還、返却と捉えてもよい。)することを可能にする実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図11-1~図11-2は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。ここで、制限付き電子マネー残高は図9-2と同様である。
図11-1左側は、端末20Aの表示部24に表示される支払いアプリケーションのコード支払い画面であり、ウォレットコード情報表示領域WCR1に表示されたウォレットコード情報に基づいて支払いが行われると、図11-1右側のような決済結果情報が表示される。この例では、支払い金額が「3,800円」であり、内訳として、通知先アカウントをユーザB,Bのアカウントとする制限付き電子マネーから「1,000円」が、通知先アカウントをユーザC.Cのアカウントとする制限付き電子マネーから「2,800円」がそれぞれ支払われたことが示されている。
この例では、送金元アカウントは、通知先アカウントと同じユーザC.Cのアカウントとする。よって、サーバ10を介して、ユーザA.AのアカウントからユーザC.Cのアカウントに対して「200円」が送金される。
おしらせ領域内の向かって左側には、支払いを行ったことを示す支払い結果情報PR1が表示され、その下に、返金の目的でユーザC.Cに制限付き電子マネーを「200円」送金したことを示す制限付き電子マネー返金情報RF1が表示されている。
おしらせ領域内の向かって左側には、ユーザA.Aに対して制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報RR91が表示され、その下に、返金の目的でユーザA.Aから制限付き電子マネー「200円」が送金され、これを受け取ったことを示す制限付き電子マネー返金情報RF2が表示されている。
上記の支払いと返金により、ユーザA.Aのアカウントが所有する制限付き電子マネー残高は「0」となり、通常電子マネー残高のみが残る。その結果、残高表示領域BR2には、「残高」の文字とともに「2,500円」の残高(通常電子マネー残高)とチャージボタンCBTとが表示されている。
図11-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図11-3は、限定ではなく例として、図8-2に引き続き実行される。
本実施例は、端末20A(限定ではなく、情報処理装置の一例)のユーザによる制限付き電子マネー残高(限定ではなく、第1電子貨幣の一例)の残高が所定値以下となること(限定ではなく例として、使用に関する条件の一例)に基づいて、第1電子貨幣の残高が端末20B(限定ではなく、第1情報処理装置の一例)のユーザに送金され、送金されたことを示す制限付き電子マネー返還結果情報(限定ではなく、第1情報の一例)を情報処理装置の通信部によって受信することが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによる第1電子貨幣の使用に関する条件に基づいて、第1電子貨幣の残高が第1情報処理装置のユーザに送金されるようにすることができる。なお、これは、第1電子貨幣の残高が第1情報処理装置のユーザに返金、返還、返却されることと捉えてもよい。
上記の実施例では、連続制限付き決済処理を実行後、制限付き電子マネー残高が所定値以下となる場合、その制限付き電子マネー残高を送金元IDのユーザに送金したが、これに限定されない。限定ではなく例として、送金元IDのユーザが指定する他の任意のユーザ(アカウント)に送金するようにしてもよい。
上記の実施例では、制限付き電子マネー残高が所定値以下となる場合、制限付き電子マネー返還処理を実行したが、これに限定されない。限定ではなく例として、制限付き電子マネー返還処理を実行する承認を、支払いを実行した端末20Aにおいて得るようにしてもよい。
図11-4左側は、端末20Aの表示部24に表示されるコード支払い画面の一例を示す図である。
ウォレットコード情報表示領域WCR1に表示されたウォレットコード情報に基づいて支払いが行われると、図11-4中央のような決済結果情報が表示される。その後、図11-4右側のように、限定ではなく例として、決済結果情報の一部に重畳するように、制限付き電子マネーの残余を返還するか否かを確認するための制限付き電子マネー返還承認確認情報RA1が表示される。
サーバ10から制限付き電子マネー返還承認確認情報を受信しない場合(A630:NO)、端末20Aの制御部21は、処理を終了させる。
制限付き電子マネー残高を返還(送金)することが選択されない場合(A640:NO)、端末20Aの制御部21は、処理を終了させる。
このような構成により得られる実施例の効果の一例として、第1電子貨幣の使用に関する条件に基づいて、第1電子貨幣の残高を第1情報処理装置のユーザに返金することを、情報処理装置の表示部への第2情報の表示によって情報処理装置のユーザに知らせることができる。また、表示部に表示された第2情報に対する情報処理装置のユーザによる入力に基づいて、第1電子貨幣の残高が第1情報処理装置のユーザに送金されるようにすることができる。そして、その結果、限定ではなく例として、送金が行われたことを、情報処理装置の表示部への第1情報の表示によって、情報処理装置のユーザに知らせることができる。
上記の実施例では、制限付き電子マネー返還処理を実行する条件として、連続制限付き決済処理を実行後、制限付き電子マネー残高が所定値以下となる場合について説明したが、これに限定されない。制限付き電子マネー返還処理を実行する条件としては、限定ではなく例として、以下のような例が挙げられる。
・制限付き電子マネー残高が送金された時点での残高の所定割合(限定ではなく例として、「5%」)以下となる、または下回る場合。
限定ではなく例として、「10,000円」の制限付き電子マネー残高を受け取った場合、連続制限付き決済処理を実行後、制限付き電子マネー残高が「10,000円」×「5%」=「500円」以下となった場合、制限付き電子マネー返還処理が実行される。
・制限付き電子マネー残高の使用期限まで所定の時間(限定ではなく例として、「24時間」)を切った場合。
限定ではなく例として、制限付き電子マネー残高の最初の利用により、使用期限が「7日後」である「2021年7月23日中」に設定された場合、「2021年7月23日午前0時となった場合、制限付き電子マネー返還処理が実行される。この場合、連続制限付き決済処理を実行後、期日を判定してもよいし、連続制限付き決済処理が実行されていなくとも、期日を判定してもよい。
・制限付き電子マネー残高が所定の回数(限定ではなく例として、「10」回)使用された場合。
限定ではなく例として、ある制限付き電子マネー残高が10回連続制限付き決済処理(制限付き決済処理)において使用された場合、制限付き電子マネー返還処理が実行される。
このような構成により得られる実施例の効果の一例として、第1電子貨幣の残高、または情報処理装置に送金された第1電子貨幣の金額に対する残高の割合に関する条件に基づいて、第1電子貨幣の残高が第1情報処理装置のユーザに適切に送金されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1電子貨幣を使用して情報処理装置が決済可能な期間に関する条件に基づいて、第1電子貨幣の残高が第1情報処理装置のユーザに適切に送金されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1電子貨幣を利用して決済を行った回数に関する条件に基づいて、第1電子貨幣の残高が第1情報処理装置のユーザに適切に送金されるようにすることができる。
上記の実施例では、制限付き電子マネー返還処理が実行されると、送金元IDのアカウントに残高が送金されることとしたが、これに限定されない。限定ではなく例として、支払いを行った端末20Aのアカウントの通常電子マネー残高に送金されることとしてもよい。この場合、連続制限付き決済処理を実行後、制限付き電子マネー残高の残高が所定値以下となる場合、端数の残高が通常電子マネー残高として組み込まれる。
上記の実施例では、制限付き電子マネー残高は、送金ごとに残高を分けて管理されていた。
第12実施例は、同一の使用制限が付与された2つの制限付き電子マネー残高を併合(マージ)することで、1の制限付き電子マネー残高として管理・使用する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図12-1は、本実施例におけるアカウント管理データベース155の一例であるアカウント管理データベース155Jのデータ構成例を示す図である。
このアカウント管理データベース155Jの各々のアカウント管理データには、限定ではなく例として、アプリケーションIDと、通常電子マネー残高と、制限付き電子マネー管理データと、併合済み制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。
以下説明する第1制限付き電子マネーと第2制限付き電子マネーとには、いずれも通知に関する制限は設定されておらず、使用可能な店舗に関する制限のみが設定されていることとして説明する。
図12-2左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、残高表示領域BR2には、制限付き電子マネー残高(この例では「1,000円」)と、制限マークRMKとが表示されている。そして、ここでは、制限マークRMKがユーザによってタップされた状態が示されている。
おしらせ領域内の向かって左側には、上記の送金元アカウントがユーザB.Bのアカウントである第1制限付き電子マネーに対応する第1制限付き電子マネー送金結果情報RR101が表示されている。
制限付き電子マネーが併合されたことに基づいて、残高表示領域BR2には、併合済み制限付き電子マネーの残高として「1,000円+2,000円=3,000円」が表示されている。そして、ここでは、制限マークRMKがユーザによってタップされた状態が示されている。
図12-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図7-5に相当する部分を示したものである。
なお、B715~B725のステップは、端末20B以外の端末20において実行されるようにしてもよい。
そして、サーバ10の制御部11は、限定ではなく例として、図7-5のS420と同様にして、第2制限付き電子マネー送金結果情報を送信する(S725)。なお、制限付き電子マネー併合処理によって第2制限付き電子マネーが併合済みとなった場合、サーバ10の制御部11は、制限付き電子マネー併合結果情報を送信した端末20Aに、第2制限付き電子マネー送金結果情報を送信しないようにしてもよい。
また、制限付き電子マネー併合処理によって第1制限付き電子マネーと第2制限付き電子マネーとが併合済みとなった場合、端末20Aの制御部21は、支払いの選択表示に併合済みの制限付き電子マネーを表示させないようにすることができる。なお、第1制限付き電子マネーと第2制限付き電子マネーとが併合済みとなった場合、サーバ10の制御部11は、第1制限付き電子マネーと第2制限付き電子マネーの情報をあたかも存在しないかのように端末20Aに送信しないようにしてもよい。このようにすることで、端末20Aとサーバ10とは、併合元となった制限付き電子マネーを使用させないようにすることができる。
本実施例は、サーバ10(限定ではなく、端末20A(限定ではなく、第1端末の一例)のユーザと電子貨幣とを関連付けて記憶するサーバの一例)によって実行されるプログラムであって、端末20B(限定ではなく、第2端末の一例)のユーザによって第1制限が設定された、第2端末から第1端末に送金された第1制限付き電子マネー(限定ではなく、第1電子貨幣の一例)と、第1端末のユーザとを関連付ける処理と、端末20C(限定ではなく、第3端末の一例)のユーザによって第2制限が設定された、第3端末から第1端末に送金された第2制限付き電子マネー(限定ではなく、第2電子貨幣の一例)と、第1端末のユーザとを関連付ける処理と、をサーバの制御部によって行うことと、第1制限と第2制限とに基づいて、制限付き電子マネー併合処理(限定ではなく、第1電子貨幣と前記第2電子貨幣とに基づく第3電子貨幣を第1端末のユーザに関連付ける処理の一例)を制御部によって行うこととがサーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第1制限と第2制限とに基づいて、第1電子貨幣と第2電子貨幣とに基づく第3電子貨幣が、第1端末のユーザに関連付けられるようにすることができる。つまり、制限が設定された電子貨幣同士を、それらの制限に基づいて、いわば併合することが可能となる。
このような構成により得られる実施例の効果の一例として、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含む第1制限と、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含む第2制限とに基づいて、第1電子貨幣と第2電子貨幣とに基づく第3電子貨幣が、第1端末のユーザに関連付けられるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1電子貨幣と第2電子貨幣とが合算された第3電子貨幣が、第1端末のユーザと関連付けられるようにすることができる。
上記の実施例では、制限が同一である制限付き電子マネーが存在すると、自動的に併合することとしたが、これに限定されない。限定ではなく例として、制限が同一であると判定された場合、端末20Aのユーザの承認操作に基づいて、制限付き電子マネー併合処理が実行されるようにしてもよい。
図12-4左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面の一例を示す図であり、図12-2左側の画面に対応するものである。
端末20Aから制限付き電子マネー併合承認情報を受信する場合、サーバ10の制御部11は、制限付き電子マネー併合処理を実行する。
上記の実施例では、制限が同一である場合、制限付き電子マネーを併合することとしたが、これに限定されない。限定ではなく例として、第1制限と第2制限が近い場合においても、第1制限付き電子マネーと第2制限付き電子マネーとの制限付き電子マネー併合処理が実行されるようにしてもよい。
・第1制限は第2制限を含む。
・第2制限は第1制限を含む。
・第1制限と第2制限が類似する。
・通知先の包含関係
限定ではなく例として、第1制限=通知先がユーザA.AとユーザB.B、第2制限=通知先がユーザA.A(またはユーザB.B)の場合、第1制限は第2制限を含む。
・使用可能店舗業種・サービス業種の包含関係
限定ではなく例として、第1制限=「コンビニ」「書籍・文具」で使用可能、第2制限=「コンビニ」(または「書籍・文具」)で使用可能である場合、第1制限は第2制限を含む。
・購入可能な商品・サービスの包含関係
限定ではなく例として、第1制限=「エンターテイメント」で使用可能、第2制限=「ゲームソフト」(または「楽曲購入」等)で使用可能である場合、第1制限は第2制限を含む。
・使用可能な日時や時間帯に関する包含関係
限定ではなく例として、第1制限=「9:00~21:00」に使用可能、第2制限=「12:00~13:00」に使用可能である場合、第1制限は第2制限を含む。また、第1制限=送金した月である6月中に使用可能、第2制限=遠足の日である6月15日に使用可能である場合、第1制限は第2制限を含む。
・通知先の類似
限定ではなく例として、第1制限=支払い者の父親に通知、第2制限=支払い者の母親に通知の場合、通知先が共に1親等であるため類似する。
・購入可能な商品・サービスの類似
限定ではなく例として、第1制限=X.X社の家電製品が購入可能、第2制限=Y.Y社の家電製品が購入可能である場合、同じ商品種別の商品が購入可能であるため類似する。また、第1制限=X.X社の家電製品が購入可能、第2制限=X.X社の食品飲料が購入可能である場合、同じメーカーの商品が購入可能であるため類似する。
・使用可能な日時や時間帯に関する包含関係
限定ではなく例として、第1制限=「11:00~13:00」に使用可能、第2制限=「12:00~14:00」に使用可能である場合、使用可能な時間帯において使用が許可される時間(この例では第1制限・第2制限とも2時間)の所定割合以上(限定ではなく例として、5割以上)がかぶっているため類似する。
このような構成により得られる実施例の効果の一例として、第1制限が第2制限を含む場合、第2制限が第1制限を含む場合、および第1制限と第2制限とが同一の制限である場合のうちの少なくとも一つの場合、第1制限と第2制限とに基づいて、第1電子貨幣と第2電子貨幣とに基づく第3電子貨幣が、第1端末のユーザに関連付けられるようにすることができる。
上記の実施例では、制限付き電子マネー併合処理において、併合対象である第1制限付き電子マネー残高と第2制限付き電子マネー残高との和を併合済み制限付き電子マネー残高とする例について例示したが、これに限定されない。限定ではなく例として、併合済み制限付き電子マネー残高を以下の式で算出するようにしてもよい。
「併合済み制限付き電子マネー残高」=「第1制限付き電子マネー残高」+「第2制限付き電子マネー残高」+「併合ボーナス」
ここで、併合ボーナスは、制限付き電子マネーの併合を行うことで得られるボーナス残高であり、限定ではなく例として、第1制限付き電子マネー残高と第2制限付き電子マネー残高の合算値の10%等に定めることができる。
「併合済み制限付き電子マネー残高」=「第1制限付き電子マネー残高」+「第2制限付き電子マネー残高」-「併合オーナス」
ここで、併合オーナスは、制限付き電子マネーの併合を行うことで端末20のユーザが負担する残高であり、限定ではなく例として、第1制限付き電子マネー残高と第2制限付き電子マネー残高の合算値の5%等に定めることができる。
上記の実施例では、第1制限付き電子マネー残高と第2制限付き電子マネー残高とを併合した後も制限付き電子マネー管理データからはそれぞれの送金管理IDで示されるレコードの関連付けが保存される例を示したが、これに限定されない。
送金管理ID「T02109」の制限付き電子マネーと、送金管理ID「T02572」の制限付き電子マネーとは、電子マネー使用制限管理データにおいて同一の使用可能店舗業種であるため、制限付き電子マネー併合処理が実行される。
この図では、制限付き電子マネー併合処理が実行されたことに基づいて、送金管理ID「T90001」が新たに発行(生成)される。そして、送金管理ID「T90001」の制限付き電子マネーの送金元IDとして、送金管理ID「T02109」の制限付き電子マネーの送金元ID「U0002」と、送金管理ID「T02572」の制限付き電子マネーの送金元ID「U0003」とが記憶される。また、送金管理ID「T90001」の制限付き電子マネー残高には、送金管理ID「T02109」の制限付き電子マネー残高「1,000円」と、送金管理ID「T02572」の制限付き電子マネー残高「2,000円」とを加算した「3,000円」が記憶される。
上記の実施例では、制限付き電子マネー併合処理後のデータとして、第1制限付き電子マネーと第2制限付き電子マネーとを併合した併合済み制限付き電子マネー管理データを用いて管理していたが、これに限定されない。限定ではなく例として、制限付き電子マネー併合処理後のデータとして、図12-5に示すデータを用いるようにしてもよい。ただし、送金管理ID「T02109」の制限付き電子マネーと、送金管理ID「T02572」の制限付き電子マネーには、併合されたことを示す併合済みフラグ情報が追加される。この場合、端末20Aの制御部21は、電子マネー残高の一覧を要求する電子マネー残高要求情報をサーバ10に送信すると、サーバ10の制御部11は、通常電子マネー残高と、制限付き電子マネー管理データとを端末20Aの制御部21に送信する。そして、端末20Aの制御部21は受信した制限付き電子マネー管理データに基づいて、併合済みフラグ情報が付加された制限付き電子マネー残高を加算して表示部24に表示させる。このとき、端末20Aの制御部21は、併合済みフラグ情報が付加されたそれぞれの制限付き電子マネー残高を表示部24に表示させないようにしてもよい。
このような構成により得られる実施例の効果の一例として、第1情報処理装置のユーザによって第1制限が設定された、第1情報処理装置から情報処理装置に送金された第1電子貨幣の情報と、第2情報処理装置のユーザによって第2制限が設定された、第2情報処理装置から第1情報処理装置に送金された第2電子貨幣の情報とを、表示によって情報処理装置のユーザに認識させることができる。また、第1制限と第2制限とに基づいて、第1電子貨幣と第2電子貨幣とに基づく第3電子貨幣を、表示によって情報処理装置のユーザに認識させることができる。
上記の実施例では、第1制限付き電子マネー送金処理と、第2制限付き電子マネー送金処理とを実行後、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行することとしたが、これに限定されない。限定ではなく例として、サーバ10の制御部11は、第1制限付き電子マネー送金処理を実行後、第2制限付き電子マネー送金依頼情報を端末20から受信すると、第2制限付き電子マネー送金依頼情報に基づいて、第2制限と送金処理済みの第1制限とが同一の制限であるか否かを判定する。そして、同一の制限である場合、サーバ10の制御部11は、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよい。同一の制限でない場合、サーバ10の制御部11は、第2制限付き電子マネー送金処理を実行する。
上記の実施例では、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行することで、併合管理IDで識別される併合済み制限付き電子マネーを生成したが、これに限定されない。限定ではなく例として、生成済みの併合済み制限付き電子マネーの併合を解除することで、第1制限付き電子マネーと第2制限付き電子マネーとに分割(復元)するようにしてもよい。
上記の実施例では、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行する例を例示したが、これに限定されない。限定ではなく例として、第1制限付き電子マネーと第2制限付き電子マネーとを併合した第1併合済み制限付き電子マネーと、第3制限付き電子マネーとにおいて、第1併合済み制限と第3制限とが同一の場合、第1併合済み制限付き電子マネーと第3制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよい。
商品やサービスの返品時等において、返金が発生した場合、決済時に併合済み制限付き電子マネー残高が使用された場合には、返金される金額を決済時に使用した併合済み制限付き電子マネー残高に加算するようにしてもよい。
上記の実施例では、通知先を含む制限が同一である場合、制限付き電子マネー併合処理を実行した。
第13実施例は、通知先は異なるが電子マネー使用制限管理データで管理される使用制限が同一である制限付き電子マネーを併合する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
データ構成については、限定ではなく例として、図12-1に示したアカウント管理データベース155Jを用いることができる。
以下の例では、第1制限付き電子マネーと第2制限付き電子マネーとには、いずれも通知に関する制限と、通知に関する制限とは異なる制限とが設定されているものとする。また、第1制限付き電子マネーと第2制限付き電子マネーとは通知先アカウントが異なるが、通知に関する制限とは異なる制限は同じであることとして説明する。
図13-1は、端末20Aの表示部24に表示されるメインメニュー画面の一例を示す図である。この例では、第1制限付き電子マネーは、通知先アカウントのユーザをユーザB.Bとするアカウントとする。
おしらせ領域内の向かって左側には、併合済み制限付き電子マネーを使用して支払いを行ったことを示す支払い結果情報PR121が表示されている。
おしらせ領域内の向かって左側には、ユーザA.Aのアカウントに制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報RR121(この例では「1,000円」)が表示され、その下に、ユーザA.Aによって制限付き電子マネーが使用されたことを示す制限付き電子マネー使用情報RU121が表示されている。
おしらせ領域内の向かって左側には、ユーザA.Aのアカウントに制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報RR122(この例では「2,000円」)が表示され、その下に、ユーザA.Aによって制限付き電子マネーが使用されたことを示す制限付き電子マネー使用情報RU122が表示されている。
以下、制限付き電子マネー使用通知の別例について説明する。ここでは、各々の通知先アカウントに通知される金額を「通知金額」と称する。
この例では、ユーザA.Aによって支払われた金額を、併合前の第1制限付き電子マネー残高と第2制限付き電子マネー残高との残高比で分配した金額(以下、「分配金額」と称する。)を、各々の通知先アカウントへの通知金額として通知する。
この場合、ユーザB.Bに対応する分配金額は「1,800円×(1000円÷3000円)=600円」と計算され、ユーザC.Cに対応する分配金額は「1,800円×(2000円÷3000円)=1,200円」と計算される。
このおしらせ画面は、図13-3中央の画面とほぼ同様であるが、制限付き電子マネー使用情報RU123に含まれる情報が一部異なっている。この制限付き電子マネー使用情報RU123には、支払い先(この例では「XX書店」)の他に、ユーザB.Bに対応する分配金額(上記のように「600円」)がユーザB.Bへの通知金額として表示されている。
このおしらせ画面は、図13-3右側の画面とほぼ同様であるが、制限付き電子マネー使用情報RU124に含まれる情報が一部異なっている。この制限付き電子マネー使用情報RU124には、支払い先(この例では「XX書店」)の他に、ユーザC.Cに対応する分配金額(上記のように「1,200円」)がユーザC.Cへの通知金額として表示されている。
この例では、ユーザA.Aによって支払われた金額を、各々の通知先アカウントに通知する。
このおしらせ画面は、図13-4中央の画面とほぼ同様であるが、制限付き電子マネー使用情報RU125に含まれる通知金額が異なっている。具体的には、ユーザA.Aによって支払われた金額(この例では「1,800円」)がユーザB.Bへの通知金額として表示されている。
このおしらせ画面は、図13-4右側の画面とほぼ同様であるが、制限付き電子マネー使用情報RU126に含まれる通知金額が異なっている。具体的には、ユーザA.Aによって支払われた金額(この例では「1,800円」)がユーザC.Cへの通知金額として表示されている。
この例では、併合前の第1制限付き電子マネーと併合前の第2制限付き電子マネーとに優先順位をつけ、併合済み制限付き電子マネーを使用する場合に、優先順位の高い方の残高分から金額が消費されるようにする。
この場合、第1制限付き電子マネー残高の方が第2制限付き電子マネー残高よりも少ないため、第1制限付き電子マネー残高分から金額が消費されるようにする。
このおしらせ画面は、図13-3中央の画面とほぼ同様であるが、制限付き電子マネー使用情報RU127に含まれる通知金額が異なっている。具体的には、上記のようにして計算された「1,000円」がユーザC.Cへの通知金額として表示されている。
このおしらせ画面は、図13-3中央の画面とほぼ同様であるが、制限付き電子マネー使用情報RU128に含まれる通知金額が異なっている。具体的には、上記のようにして計算された「800円」がユーザC.Cへの通知金額として表示されている。
図13-7左側は、端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面であり、残高表示領域BR2には、通知先アカウントをユーザB.Bのアカウントとする第1制限付き電子マネーと、通知先アカウントをユーザC.Cのアカウントとする第2制限付き電子マネーとが併合された併合済み制限付き電子マネーの残高(この例では「3,000円」)が示されている。
これは、前述した家族のような例ではさほど問題は生じない可能性もあり得るが、見ず知らずのユーザが通知先アカウントとなっている制限付き電子マネー同士が併合され、見ず知らずのユーザに対して、併合済み制限付き電子マネーが使用されたことに関する通知がなされてしまう可能性があるためである。
処理については、限定ではなく例として、図12-3のS730において、サーバ10の制御部11は、通知先ID以外の制限が同一か否かを判定する。
・送信先IDのアカウントの端末20Aにおいて、通知付き制限付き電子マネーが使用される前に通知先IDのアカウントに通知が送信されることを表示する(第3変形例)。
・送信先IDのアカウントの端末20Aにおいて通知付き制限付き電子マネーの受取を拒否する設定を行っている場合、送金元IDのアカウントの端末20Bに通知付き制限付き電子マネーの送金が拒否されたことを示す情報を表示させる(第3変形例)。
・送信先IDのアカウントの端末20Aにおいて、端末20Bのアカウントからの通知付き制限付き電子マネーの受取をブロックする(第3変形例)。
・端末20Aにおいて通知付き制限付き電子マネーを出金する処理を実行すると、サーバ10の制御部11は通知付き制限付き電子マネー出金不可情報を端末20Aに送信する(第5実施例)。
本実施例は、第1制限付き電子マネーは、第1制限とは異なる制限として、通知付き電子マネーとしての制限(限定ではなく、第1端末のユーザが電子貨幣を使用したことを示す通知に関する制限の一例)が第2端末のユーザによって設定される。また、第2制限付き電子マネーは、第2制限とは異なる制限として、通知付き電子マネーとしての制限(限定ではなく、第1端末のユーザが電子貨幣を使用したことを示す通知に関する制限の一例)が第3端末のユーザによって設定される構成を示している。
このような構成により得られる実施例の効果の一例として、第1制限とは異なる、第1端末のユーザが電子貨幣を使用したことを示す通知に関する制限が第2端末のユーザによって設定された第1電子貨幣と、第2制限とは異なる、第1端末のユーザが電子貨幣を使用したことを示す通知に関する制限が第3端末のユーザによって設定された第2電子貨幣とに基づく第3電子貨幣が、第1端末のユーザに関連付けられるようにすることができる。
このような構成により得られる実施例の効果の一例として、第3電子貨幣の少なくとも一部が第1端末のユーザによって使用された場合、第2端末のユーザによって設定された第4端末と、第3端末のユーザによって設定された第5端末とに、通知が行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第3電子貨幣の少なくとも一部が第1端末のユーザによって使用された場合であっても、通知が行われないようにすることができる。
このような構成により得られる実施例の効果の一例として、第1制限と第2制限とに基づいて、第1端末のユーザに関連付けられた第3電子貨幣に通知に関する制限が設定されており、第4電子貨幣にも通知に関する制限が設定されている場合、これらの電子貨幣に基づく第5電子貨幣とされない、いわば併合されないようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザにより第1電子貨幣の少なくとも一部が使用される前に、第2端末に対して通知がされることを第1端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザの意に反して、第1電子貨幣が第1端末のユーザに関連付けられてしまうことを防止できる。また、第1端末のユーザに送金ができないことを第2端末のユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第2端末のユーザをブロックする設定を行うことで、通知が設定されている送金を受け取らないようにすることができる。
このような構成により得られる実施例の効果の一例として、第1端末のユーザにより第3電子貨幣の少なくとも一部を出金することに関する情報を通信部によって受信した場合、出金が不可であることを第1端末のユーザに知らせることができる。
上記の実施例では、通知先は制限付き電子マネー併合処理を実行するか否かの判定に関与しないが、これに限定されない。限定ではなく例として、通知先が類似し、かつ通知先ID以外の制限が同一である場合、制限付き電子マネー併合処理を実行するようにしてもよい。この場合、通知先が類似していると判定される条件としては、限定ではなく例として、通知先のユーザと、送金先のユーザとの関係が2親等以内である場合等が挙げられる。このようにすることで、家族内など親しいユーザ間に通知を行う通知付き制限付き電子マネーは併合するが、赤の他人に通知を行う通知付き制限付き電子マネーを誤って併合することを避けることができる。
上記の実施例では、制限が同一である場合等に、制限付き電子マネーを併合することとした。
第14実施例は、特殊な制限付き電子マネーについては、制限等の条件に寄らず制限付き電子マネーを併合しない実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
データ構成については、限定ではなく例として、図12-1に示したアカウント管理データベース155Jを用いることができる。
制限付き電子マネー管理データには、限定ではなく例として、送金管理IDと関連付けて、電子マネー送金日時が記憶される。電子マネー送金日時には、この制限付き電子マネーの残金が送金元IDに送金(返還)される日時が記憶される。電子マネー送金日時は、限定ではなく例として、送金元アカウントの端末20Bにおいて、第1制限付き電子マネー送金設定処理または第2制限付き電子マネー送金設定処理、もしくはその両方において設定される日時である。
処理については、限定ではなく例として、図12-3のS730のステップにおいて、サーバ10の制御部11は、制限付き電子マネー管理データを参照し、第1制限付き電子マネーまたは第2制限付き電子マネーに電子マネー送金日時が設定されている場合、制限付き電子マネー併合処理を実行しない。
なお、サーバ10の制御部11は、所定期間ごと(限定ではなく例として、毎時0分ごと)に、電子マネー送金日時を超過したか否かを判定してもよいし、そうしなくてもよい。
上記の実施例では、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行すると、併合済み制限付き電子マネーが生成される例を示した。
第15実施例は、制限付き電子マネーと通常電子マネーとを併合対象とする制限付き電子マネー併合処理を実行すると、通常電子マネーに併合される実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
データ構成については、限定ではなく例として、図12-1に示したアカウント管理データベース155Jを用いることができる。なお、制限付き電子マネー同士の併合を考慮しない場合、限定ではなく例として、図7-1に示したアカウント管理データベース155Fや、図7-7に示したアカウント管理データベース155Gを用いることができる。
図14-1~図14-2は、本実施例における端末20の表示部24に表示される画面の一例を示す図である。
図14-1は、端末20Aの表示部24に表示される支払いアプリケーションのコード支払い画面であり、ウォレットコード情報表示領域WR2には、制限付き電子マネーの残高(この例では「3,000円」)および制限マークRMKが表示されている。また、通常電子マネー残高として「500円」が表示されている。そして、この例では、制限マークRMKがタップされ、この制限付き電子マネーの使用可能店舗(この例では「書籍・文具」)が表示された状態が示されている。
この画面は、前述した支払いアプリケーションの出金画面であり、ここでは、通常電子マネー残高「700円」のうちの「500円」を出金するための入力がなされ、「出金」ボタンBT52がタップされた状態が示されている。
おしらせ領域内の向かって左側には、図14-1中央の画面に対応する支払い結果情報PR131が表示され、その下に、「500円」の出金がされたことを示す出金結果情報WR131が表示されている。
図14-3は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図7-6に相当する部分を示したものである。なお、図14-3に先んじて、端末20Aのユーザが通常電子マネーをチャージするための通常電子マネーチャージ要求情報を通信I/F22によってサーバ10に送信し、サーバ10の制御部11は、受信した通常電子マネーチャージ要求情報に基づいて、端末20Aのアカウントに対して通常電子マネーの残高をチャージするための通常電子マネーチャージ処理を実行するようにしてもよい。
通常電子マネー併合処理において、サーバ10の制御部11は、限定ではなく例として、所定残金以下であると判定された送金管理IDの制限付き電子マネー残高を通常電子マネー残高に加算する。そして、制限付き電子マネー管理データから送金管理IDで指定されるレコードを消去する。
併合済み制限付き電子マネー残高が所定残金以下であると判定された場合、サーバ10の制御部11は、併合管理IDの併合済み制限付き電子マネー残高を通常電子マネー残高に加算する。そして、併合済み制限付き電子マネー管理データから併合管理IDで指定されるレコードを消去する。加えて、サーバ10の制御部11は、制限付き電子マネー管理データから、併合前送金管理IDとして記憶された送金管理IDのレコードを消去するようにしてもよい。
サーバ10から通常電子マネー併合処理結果情報を受信しないと判定される場合(S740:NO)、端末20Aの制御部21は、A750のステップをスキップする。
本実施例は、第6制限付き電子マネー(限定ではなく例として、第4端末のユーザによって第3制限が設定された、第4端末から第1端末に送金された第6電子貨幣の一例)と、端末20A(限定ではなく、第1端末の一例)のユーザとを関連付ける制限付き電子マネー送金処理と、通常電子マネー(限定ではなく例として、制限が設定されていない第7電子貨幣の一例)と、第1端末のユーザとを関連付ける通常電子マネーチャージ処理とを、サーバの制御部によって行うことと、制限付き電子マネー出金依頼情報(限定ではなく例として、第1端末のユーザにより第6電子貨幣の少なくとも一部を現金として出金することに関する情報の一例)を受信した場合、現金による出金が不可であることを示す制限付き電子マネー出金不能情報(限定ではなく例として、出金不可情報の一例)を第1端末に送信し、通常電子マネー出金依頼情報(限定ではなく例として、第6電子貨幣と第7電子貨幣とに基づく第8電子貨幣の少なくとも一部を現金として出金することに関する情報の一例)を受信した場合、通常電子マネー(限定ではなく、第8電子貨幣の一例)の少なくとも一部を現金として出金することに関する通常電子マネー出金処理を制御部によって行うこととがサーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第1端末のユーザにより第6電子貨幣の少なくとも一部を出金することに関する情報を受信した場合、出金が不可であることを第1端末のユーザに知らせることができる。その一方で、第6電子貨幣と第7電子貨幣とに基づく第8電子貨幣の少なくとも一部を出金することに関する情報を受信した場合、第8電子貨幣の少なくとも一部を出金することを可能とすることができる。
このような構成により得られる実施例の効果の一例として、設定された合算条件に基づいて、第6電子貨幣を第7電子貨幣と合算して第8電子貨幣とすることができる。
このような構成により得られる実施例の効果の一例として、第6電子貨幣の残高に関する条件、または第1端末に送金された第6電子貨幣の金額に対する残高の割合に関する条件に基づいて、第6電子貨幣を第7電子貨幣とが適切に合算されるようにすることができる。
上記の実施例では、第1制限付き電子マネーと第2制限付き電子マネーとを併合対象とする併合済み制限付き電子マネーを用いて制限付き決済処理を行う例を示した。
第16実施例は、併合済み制限付き電子マネーを用いて連続制限付き決済処理を実行する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
・通常電子マネーと第1併合済み制限付き電子マネー
・通常電子マネーと第2併合済み制限付き電子マネー
・第1併合済み制限付き電子マネーと第2併合済み制限付き電子マネー
・通常電子マネーと第1併合済み制限付き電子マネーと第2併合済み制限付き電子マネー
・第5制限付き電子マネーと第1併合済み制限付き電子マネー
・第5制限付き電子マネーと第2併合済み制限付き電子マネー
・第5制限付き電子マネーと第1併合済み制限付き電子マネーと第2併合済み制限付き電子マネー
・通常電子マネーと第5制限付き電子マネーと第1併合済み制限付き電子マネー
・第5制限付き電子マネーと第6制限付き電子マネーと第1併合済み制限付き電子マネー
・通常電子マネーと第5制限付き電子マネーと第6制限付き電子マネーと第1併合済み制限付き電子マネーと第2併合済み制限付き電子マネー
上記の実施例では、電子貨幣を用いた支払い方法として、「利用者提示型」のコード支払いについて説明したが、これに限定されない。限定ではなく例として、「店舗提示型」のコード支払いを用いて処理を実行するようにしてもよい。
この場合、店舗POSシステム40は不用である。「店舗提示型」のコード支払いにおける処理としては、まず、端末20Aの制御部21は、ウォレット支払い要求情報送信すると、サーバ10は、端末20にアカウント識別情報を送信する。限定ではなく例として、端末20Aの制御部21は、撮像部27によって、支払いを行う店舗に提示された店舗情報(店舗識別用コード情報)を読み取る。なお、端末20Aの制御部21は、撮像部27によって、購入する商品・サービスの画像を撮像し、撮像された画像に基づいて、購入する商品・サービスを識別するようにしてもよい。「利用者提示型」のコード支払いとは異なり、支払い金額を入力する前に、端末20Aの制御部21は、各制限付き電子マネーにおいて使用可能な残高を判定することができる。そのため、「店舗提示型」のコード支払いでは、使用可能合算残高を参照して、支払い金額を入力することができる。なお、端末20Aの制御部21は、店舗情報や撮像された画像をサーバ10に送信し、サーバ10において受信した店舗情報や撮像された画像に基づいて、使用可能合算残高を算出するようにしてもよい。
端末20Aの入出力部23に対する入力(ユーザ操作)に基づいて、支払い金額が入力されると、端末20Aの制御部21は、アカウント識別情報と店舗情報と支払い金額とを少なくとも含む決済要求情報をサーバ10に送信し、サーバ10は、受信した決済要求情報に基づいて、決済処理(制限付き決済処理・連続制限付き決済処理)を実行する。
上記の実施例では、端末を使用して支払いを行う例を例示したが、これに限定されない。限定ではなく例として、複数のサーバ10(サーバ10A、サーバ10B、・・・)において、サーバ10Aのユーザのアカウントにアカウント管理データを紐付ける。また、サーバ10Bのユーザのアカウントにアカウント管理データを紐付ける。そして、端末20Aにおいて実行される処理をサーバ10Aに、端末20Bにおいて実行される処理をサーバ10Bに、それぞれ実行させるようにしてもよい。
なお、送金元アカウントの情報処理装置をサーバ10B、送金先アカウントの情報処理装置を端末20Aとしてもよいし、そうしなくてもよい。また、送金元アカウントの情報処理装置を端末20B、送金先アカウントの情報処理装置をサーバ10Aとしてもよいし、そうしなくてもよい。
10 サーバ
20 端末
30 ネットワーク
40 店舗POSシステム
Claims (23)
- 第1情報処理装置と通信する情報処理装置によって実行されるプログラムであって、
前記第1情報処理装置のユーザによって制限が設定され、前記第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、前記情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を前記情報処理装置の制御部によって行うことが前記情報処理装置によって実行される。 - 請求項1に記載のプログラムであって、
前記第1電子貨幣と、前記第2電子貨幣とは、前記情報処理装置のユーザによる入力に基づいて、選択される。 - 請求項1に記載のプログラムであって、
前記第1電子貨幣と、前記第2電子貨幣とは、設定された条件に基づいて選択される。 - 請求項3に記載のプログラムであって、
前記設定された条件は、前記情報処理装置のユーザによって設定された条件である。 - 請求項4に記載のプログラムであって、
前記設定された条件は、前記制限が設定された電子貨幣から使用することに関する条件を含む。 - 請求項5に記載のプログラムであって、
前記制限が設定された電子貨幣から使用することに関する条件は、前記制限が厳しい電子貨幣から使用することを含む。 - 請求項6に記載のプログラムであって、
前記制限が厳しい電子貨幣から使用することは、電子貨幣の残高が少ないこと、または使用可能なカテゴリが狭いことを少なくとも含む。 - 請求項4から請求項7のいずれか一項に記載のプログラムであって、
前記情報処理装置のユーザによって設定された条件は、前記情報処理装置のユーザによって設定された順序で使用することに関する条件を含む。 - 請求項8に記載のプログラムであって、
前記情報処理装置のユーザによって設定された条件は、前記制限が設定された電子貨幣から使用することに関する条件を含む。 - 請求項1から請求項9のいずれか一項に記載のプログラムであって、
前記第1電子貨幣と前記第2電子貨幣とを含む、前記情報処理装置のユーザが利用可能な複数の電子貨幣のうち、前記第1決済に利用可能な電子貨幣の合計金額を前記情報処理装置に表示する制御を前記制御部によって行うことが前記情報処理装置によって実行される。 - 請求項1から請求項10のいずれか一項に記載のプログラムであって、
前記第1電子貨幣と前記第2電子貨幣とを含む、前記情報処理装置のユーザが利用可能な複数の電子貨幣のうち、決済のカテゴリごとに利用可能な金額を前記情報処理装置に表示する制御を前記制御部によって行うことが前記情報処理装置によって実行される。 - 請求項1に記載のプログラムであって、
前記情報処理装置のユーザによる前記第1電子貨幣の使用に関する条件に基づいて、前記第1電子貨幣の残高が前記第1情報処理装置のユーザに送金され、前記送金に基づく第1情報を前記情報処理装置の通信部によって受信することが前記情報処理装置によって実行される。 - 請求項12に記載のプログラムであって、
前記第1電子貨幣の使用に関する条件は、前記第1電子貨幣の残高、または前記情報処理装置に送金された前記第1電子貨幣の金額に対する残高の割合に関する条件を含む。 - 請求項12または請求項13に記載のプログラムであって、
前記第1電子貨幣の使用に関する条件は、前記第1電子貨幣を使用して前記情報処理装置が決済可能な期間に関する条件を含む。 - 請求項12から請求項14のいずれか一項に記載のプログラムであって、
前記第1電子貨幣の使用に関する条件は、前記第1電子貨幣を利用して決済を行った回数に関する条件を含む。 - 請求項12から請求項15のいずれか一項に記載のプログラムであって、
前記第1電子貨幣の使用に関する条件に基づいて、前記第1電子貨幣の残高を前記第1情報処理装置のユーザに送金するための第2情報を前記情報処理装置の表示部に表示することが前記情報処理装置によって実行され、
第1電子貨幣の残高は、前記第2情報に対する前記情報処理装置のユーザの入力に基づいて、前記第1情報処理装置のユーザに送金され、前記第1情報が受信される。 - 請求項1から請求項16のいずれか一項に記載のプログラムであって、
前記制限は、前記情報処理装置のユーザが前記第1電子貨幣を使用した場合に前記第1情報処理装置のユーザに通知を行うことに関する制限、前記第1電子貨幣を使用可能な店舗に関する制限、前記第1電子貨幣を使用可能な商品またはサービスに関する制限、前記第1電子貨幣を使用可能な商品またはサービスのカテゴリに関する制限、前記第1電子貨幣を使用不可な商品に関する制限、前記第1電子貨幣が使用できない時間帯に関する制限、前記第1電子貨幣を使用できない日にちまたは日時に関する制限のうち少なくとも一つを含む。 - 第1情報処理装置と通信する情報処理装置の情報処理方法であって、
前記第1情報処理装置のユーザによって制限が設定され、前記第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、前記情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を前記情報処理装置の制御部によって行うことを含む。 - 第1情報処理装置と通信する情報処理装置であって、
前記第1情報処理装置のユーザによって制限が設定され、前記第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、前記情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を行う制御部を備える。 - 第1情報処理装置と通信する情報処理装置であって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
前記プロセッサーは、前記第1情報処理装置のユーザによって制限が設定され、前記第1情報処理装置から送金された第1電子貨幣の少なくとも一部と、前記情報処理装置のユーザに関連付けられた第2電子貨幣の少なくとも一部とに基づいて、第1決済に関する処理を行うことを実行する。 - 第1情報処理装置および第2情報処理装置と通信するサーバによって実行されるプログラムであって、
前記第1情報処理装置のユーザによって制限が設定された、前記第1情報処理装置から前記第2情報処理装置に送金された第1電子貨幣と、前記第2情報処理装置のユーザとを関連付ける処理と、第2電子貨幣と前記第2情報処理装置のユーザとを関連付ける処理と、を前記サーバの制御部によって行うことと、
前記第2情報処理装置から送信された情報に基づいて、前記第1電子貨幣の少なくとも一部と、前記第2電子貨幣の少なくとも一部とに基づく第1決済に関する処理を前記制御部によって実行することが前記サーバによって実行される。 - 請求項21に記載のプログラムであって、
前記制限は、前記第1電子貨幣の少なくとも一部を前記第2情報処理装置のユーザが使用した場合、前記第2情報処理装置のユーザが使用したことを示す通知を前記サーバの通信部によって前記第1情報処理装置に送信する制限を含む。 - 請求項22に記載のプログラムであって、
前記第2電子貨幣に前記制限が設定されていた場合、前記第1情報処理装置に対して前記通知の送信を行わないように前記制御部によって制御することが前記サーバによって実行される。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021109517A JP7492942B2 (ja) | 2021-06-30 | 2021-06-30 | プログラム、情報処理方法、情報処理装置 |
PCT/JP2022/025708 WO2023277001A1 (ja) | 2021-06-30 | 2022-06-28 | プログラム、情報処理方法、サーバ、情報処理装置 |
JP2024046864A JP2024075718A (ja) | 2021-06-30 | 2024-03-22 | プログラム、情報処理方法、情報処理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021109517A JP7492942B2 (ja) | 2021-06-30 | 2021-06-30 | プログラム、情報処理方法、情報処理装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2024046864A Division JP2024075718A (ja) | 2021-06-30 | 2024-03-22 | プログラム、情報処理方法、情報処理装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2023006759A true JP2023006759A (ja) | 2023-01-18 |
JP7492942B2 JP7492942B2 (ja) | 2024-05-30 |
Family
ID=85106912
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021109517A Active JP7492942B2 (ja) | 2021-06-30 | 2021-06-30 | プログラム、情報処理方法、情報処理装置 |
JP2024046864A Pending JP2024075718A (ja) | 2021-06-30 | 2024-03-22 | プログラム、情報処理方法、情報処理装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2024046864A Pending JP2024075718A (ja) | 2021-06-30 | 2024-03-22 | プログラム、情報処理方法、情報処理装置 |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP7492942B2 (ja) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008269062A (ja) * | 2007-04-17 | 2008-11-06 | Bitwallet Inc | 情報処理装置、及び情報処理方法 |
WO2014103046A1 (ja) * | 2012-12-28 | 2014-07-03 | 楽天Edy株式会社 | 電子マネーサーバ、電子マネー送金方法、プログラム及び記録媒体 |
JP2018132837A (ja) * | 2017-02-13 | 2018-08-23 | 三井住友カード株式会社 | クレジットカード利用通知システム |
WO2018163312A1 (ja) * | 2017-03-08 | 2018-09-13 | 株式会社ミックナイン | 電子ウォレット及びコンピュータプログラム |
WO2018179805A1 (ja) * | 2017-03-31 | 2018-10-04 | ソニー株式会社 | 情報処理装置、情報処理方法、およびプログラム |
JP2018163533A (ja) * | 2017-03-27 | 2018-10-18 | 株式会社日本総合研究所 | 親端末、子端末、決済処理方法、およびプログラム |
-
2021
- 2021-06-30 JP JP2021109517A patent/JP7492942B2/ja active Active
-
2024
- 2024-03-22 JP JP2024046864A patent/JP2024075718A/ja active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008269062A (ja) * | 2007-04-17 | 2008-11-06 | Bitwallet Inc | 情報処理装置、及び情報処理方法 |
WO2014103046A1 (ja) * | 2012-12-28 | 2014-07-03 | 楽天Edy株式会社 | 電子マネーサーバ、電子マネー送金方法、プログラム及び記録媒体 |
JP2018132837A (ja) * | 2017-02-13 | 2018-08-23 | 三井住友カード株式会社 | クレジットカード利用通知システム |
WO2018163312A1 (ja) * | 2017-03-08 | 2018-09-13 | 株式会社ミックナイン | 電子ウォレット及びコンピュータプログラム |
JP2018163533A (ja) * | 2017-03-27 | 2018-10-18 | 株式会社日本総合研究所 | 親端末、子端末、決済処理方法、およびプログラム |
WO2018179805A1 (ja) * | 2017-03-31 | 2018-10-04 | ソニー株式会社 | 情報処理装置、情報処理方法、およびプログラム |
Non-Patent Citations (2)
Title |
---|
"d払いで、dポイントの利用/利用しないを切り替える方法(Amazon・店舗、期間限定ポイントも)", [ONLINE], JPN6023001527, 15 May 2021 (2021-05-15), ISSN: 0005165304 * |
"期間限定ポイントとは?期間・用途限定のdポイントの確認方法とつかい方", [ONLINE], JPN6023001526, 31 March 2020 (2020-03-31), ISSN: 0005165305 * |
Also Published As
Publication number | Publication date |
---|---|
JP2024075718A (ja) | 2024-06-04 |
JP7492942B2 (ja) | 2024-05-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10496978B2 (en) | Social proximity payments | |
US9524500B2 (en) | Transferring assets | |
WO2020129264A1 (ja) | 生成方法、プログラム、情報処理装置 | |
EP3479322A2 (en) | Physical, logical separation of balances of funds | |
US20140214640A1 (en) | Parental management of digital assets | |
US8566169B2 (en) | Virtual gift card | |
CN108292412A (zh) | 在交易中提供补充信息的***和方法 | |
BR112013021057A2 (pt) | aparelhos, métodos e sistemas de pagamento eletrônico universal | |
WO2020129263A1 (ja) | 認証方法、プログラム、端末 | |
JP2023543377A (ja) | 非接触支払のためのアプリケーション統合 | |
US10963872B1 (en) | Configurable management of ghost accounts | |
US20160171503A1 (en) | Systems and methods for promotion of selected transactions | |
JP7460686B2 (ja) | プログラム、情報処理方法、サーバ | |
CN113139864A (zh) | 信息处理方法、信息处理装置、程序及信息处理终端 | |
JP7175877B2 (ja) | プログラム、表示方法、端末 | |
WO2021137269A1 (ja) | プログラム、情報処理方法、端末 | |
JP7456986B2 (ja) | プログラム、情報処理方法、端末 | |
JP7306772B2 (ja) | プログラム、情報処理方法、サーバ | |
WO2023277001A1 (ja) | プログラム、情報処理方法、サーバ、情報処理装置 | |
JP7492942B2 (ja) | プログラム、情報処理方法、情報処理装置 | |
JP7417796B2 (ja) | プログラム、情報処理方法、サーバ | |
KR101707648B1 (ko) | 트라스트 뱅킹 방법 및 시스템 | |
JP2021105876A (ja) | ウォレットサーバ、ウォレットプログラムおよびウォレットシステム | |
JP7250186B2 (ja) | サーバ、プログラム、情報処理方法 | |
JP7405930B2 (ja) | プログラム、情報処理方法、端末 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20221012 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20221012 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230124 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20230323 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230414 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230704 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230714 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20231003 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20231027 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20231109 |
|
AA92 | Notification that decision to refuse application was cancelled |
Free format text: JAPANESE INTERMEDIATE CODE: A971092 Effective date: 20231219 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20231226 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20240322 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20240401 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20240423 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240520 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7492942 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |