JP2023006758A - プログラム、情報処理方法、サーバ - Google Patents

Abstract

【課題】電子貨幣の使用に関する利便性を向上させる。【解決手段】第１端末および第２端末と通信するサーバによって実行されるプログラムは、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報をサーバの通信部によって第１端末から受信することと、第１情報の受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御をサーバの制御部によって行うことと、第１情報の受信に基づき、第２端末のユーザに第１端末から送金されたことを示す第２情報を通信部によって第２端末に送信することと、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに基づき、通知を第３端末に通信部によって送信することとがサーバによって実行される。【選択図】図１－１

Description

本開示は、プログラム、情報処理方法、サーバ等に関する。

昨今、スマートフォン等の端末で実行可能なアプリケーションによって、電子貨幣等を用いた支払い（決済）を実現するサービスが普及しつつある。例えば特許文献１には、商品の購買金額の決済を行う技術が開示されている。

特開２００２－１７６６７１号公報

本発明の第１の態様によると、第１端末および第２端末と通信するサーバによって実行されるプログラムは、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報をサーバの通信部によって第１端末から受信することと、第１情報の受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御をサーバの制御部によって行うことと、第１情報の受信に基づき、第２端末のユーザに第１端末から送金されたことを示す第２情報を通信部によって第２端末に送信することと、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに基づき、通知を第３端末に通信部によって送信することとがサーバによって実行される。
本発明の第２の態様によると、第１端末および第２端末と通信するサーバによって実行されるプログラムは、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報をサーバの通信部によって第１端末から受信することと、第１情報の受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御をサーバの制御部によって行うことと、第１情報の受信に基づき、第２端末のユーザに第１端末から送金されたことを示す第２情報を通信部によって第２端末に送信することと、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに基づき、通知を第３端末に通信部によって送信することとを含む。
本発明の第３の態様によると、第１端末および第２端末と通信するサーバは、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報を第１端末から受信する通信部と、第１情報の受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御を行う制御部とを備え、通信部は、第１情報の受信に基づき、第２端末のユーザに第１端末から送金されたことを示す第２情報を第２端末に送信し、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに基づき、通知を第３端末に送信する。
本発明の第４の態様によると、第１端末および第２端末と通信するサーバは、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報をサーバの通信部によって第１端末から受信することと、第１情報の受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御を実行することと、第１情報の受信に基づき、第２端末のユーザに第１端末から送金されたことを示す第２情報を通信部によって第２端末に送信することと、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに基づき、通知を第３端末に通信部によって送信することとを実行する。

実施形態に係る通信システムのシステム構成の一例を示す図。 実施形態に係る店舗ＰＯＳシステムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第１実施例に係るアカウント登録データの一例を示す図。 第１実施例に係るアカウント管理データベースの一例を示す図。 第１実施例に係る端末の制御部によって実現される機能の一例を示す図。 第１実施例に係る端末の記憶部に記憶される情報等の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１変形例に係るアカウント管理データベースの一例を示す図。 第１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１変形例に係るアカウント管理データベースの一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２変形例に係るサーバの記憶部に記憶される情報等の一例を示す図。 第２変形例に係る決済履歴管理データの一例を示す図。 第２変形例に係るアカウント管理データベースの一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る端末の表示部に表示される画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３変形例に係る端末の表示部に表示される画面の一例を示す図。 第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３変形例に係る端末の表示部に表示される画面の一例を示す図。 第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係るアカウント管理データベースの一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４実施例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第４変形例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５実施例に係る端末の表示部に表示される画面の一例を示す図。 第５変形例に係る端末の表示部に表示される画面の一例を示す図。 第６実施例に係る端末の表示部に表示される画面の一例を示す図。 第６変形例に係る端末の表示部に表示される画面の一例を示す図。 第６変形例に係る端末の表示部に表示される画面の一例を示す図。 第６変形例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係るアカウント管理データベースの一例を示す図。 第７実施例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る端末の表示部に表示される画面の一例を示す図。 第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係るアカウント管理データベースの一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第７変形例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る端末の表示部に表示される画面の一例を示す図。 第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第８変形例に係る端末の表示部に表示される画面の一例を示す図。 第８変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第８変形例に係る端末の表示部に表示される画面の一例を示す図。 第８変形例に係る端末の表示部に表示される画面の一例を示す図。 第８変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第８変形例に係る端末の表示部に表示される画面の一例を示す図。 第９実施例に係るアカウント管理データベースの一例を示す図。 第９実施例に係る端末の表示部に表示される画面の一例を示す図。 第９実施例に係る端末の表示部に表示される画面の一例を示す図。 第９変形例に係る端末の表示部に表示される画面の一例を示す図。 第９変形例に係る使用残高選択処理における処理方法の一例を示す図。 第９変形例に係る使用残高優先順位設定処理における処理方法の一例を示す図。 第１０実施例に係る端末の表示部に表示される画面の一例を示す図。 第１０変形例に係る端末の表示部に表示される画面の一例を示す図。 第１１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１１実施例に係る端末の表示部に表示される画面の一例を示す図。 第１１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１１変形例に係る端末の表示部に表示される画面の一例を示す図。 第１１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１２実施例に係るアカウント管理データベースの一例を示す図。 第１２実施例に係る端末の表示部に表示される画面の一例を示す図。 第１２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１２変形例に係る端末の表示部に表示される画面の一例を示す図。 第１２変形例に係るアカウント管理データの一例を示す図。 第１２変形例に係るアカウント管理データの一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１３実施例に係る端末の表示部に表示される画面の一例を示す図。 第１５実施例に係る端末の表示部に表示される画面の一例を示す図。 第１５実施例に係る端末の表示部に表示される画面の一例を示す図。 第１５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

＜実施形態＞
本明細書では、分かり易いように「限定ではなく例として」と記載する箇所があるが、該当箇所ばかりでなく、以下説明する実施形態の全体について、その記載内容に限定されるものではないことに留意されたい。

本開示に係るプログラム等を実施するための実施形態について、図面を参照して説明する。

システムとは、限定ではなく例として、複数の装置を有して構成されるものとすることができる。
複数の装置は、同じ種類の装置の組合せとしてもよいし、異なる種類の装置の組合せとしてもよいし、同じ種類の装置と異なる種類の装置との組合せとしてもよい。
なお、システムとは、限定ではなく例として、複数の装置が協働して何らかの処理を行うもの、と考えることもできる。

また、クライアント（クライアント装置）とサーバとに関するシステムとは、限定ではなく例として、少なくとも以下のいずれかと考えることができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この一例は、クライアントサーバシステムである。

サーバは、限定ではなく例として、以下の装置によって構成されており、単独の装置であってもよいし、複数の装置の組合せであってもよいものとする。

具体的には、サーバは、限定ではなく例として、少なくとも１つのプロセッサー（限定ではなく例として、ＣＰＵ：Central Processing Unit、ＧＰＵ：Graphics Processing Unit、ＡＰＵ：Accelerated Processing Unit、ＤＳＰ：Digital Signal Processor（限定ではなく例として、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array）等）、コンピュータ装置（プロセッサー＋メモリ）、制御装置、演算装置、処理装置等のいずれかを有して構成され、いずれか１つの装置の同種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＣＰＵ、ホモジニアスマルチコアプロセッサー等）や、いずれか１つの装置の異種を複数備える構成（限定ではなく例として、ＣＰＵ＋ＤＳＰ、ヘテロジニアスマルチコアプロセッサー等）としてもよいし、複数の装置の組み合わせ（限定ではなく例として、プロセッサー＋コンピュータ装置、プロセッサー＋演算装置、複数の装置をヘテロジニアス化したもの等）であってもよい。
なお、プロセッサーは、仮想プロセッサーとしてもよい。

また、サーバによって何らかの処理を実行する場合に、単一の装置で構成される場合は、単一の装置によって実施例に記載されている処理が実行される。また、複数の装置を有して構成されている場合には、一部の処理を一方の装置が実行し、その他の処理を他方の装置が実行するように構成されていてもよい。限定ではなく例として、プロセッサーと、演算装置とを有して構成される場合、第１処理をプロセッサーが実行し、第２処理を演算装置が実行するように構成されていてもよい。
また、複数の装置で構成する場合には、各々の装置が互いに物理的に離れた位置に配置されて構成されてもよい。

また、サーバの機能は、限定ではなく例として、クラウドコンピューティングにおけるＰａａＳやＩａａＳ、ＳａａＳの形態で提供されるようにしてもよい。

また、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。

また、システムの制御部が行う制御や処理（以下、包括的に「制御等」と称する。）は、（１Ａ）端末の制御部のみによって行うようにしてもよいし、（１Ｂ）サーバの制御部のみによって行うようにしてもよいし、（１Ｃ）端末の制御部とサーバの制御部との両方によって行うようにしてもよい。
また、（１Ｃ）では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

また、サーバの通信部という場合、サーバが単一の装置によって構成されている場合には、単一の装置が備える通信部そのものであってもよい。また、サーバが複数の装置を有して構成されている場合には、サーバの通信部は、各々の装置が備える各々の通信部を含む構成であってもよい。
限定ではなく例として、サーバは、第１装置と第２装置とを備え、第１装置は第１通信部を有し、第２装置は第２通信部を有する場合、サーバの通信部は、第１通信部と第２通信部とを含む概念としてもよい。

（２）は、限定ではなく例として、複数のサーバによって構成されるシステム（以下、「サーバシステム」と称する。）とすることができる。この場合、各々のサーバの構成としては、前述した構成を同様に適用することができる。

サーバシステムが行う制御等は、複数のサーバのうち、（２Ａ）一のサーバのみによって行うようにしてもよいし、（２Ｂ）他のサーバのみによって行うようにしてもよいし、（２Ｃ）一のサーバと他のサーバとが行うようにしてもよい。
また、（２Ｃ）では、限定ではなく例として、サーバシステムが行う制御等のうちの一部の制御等を一のサーバが行うようにし、残りの制御等を他のサーバが行うようにしてもよい。この場合、制御等の割り当て（割り振り）は、等分であってもよいし、等分ではなく異なる割合で割り当ててもよい。

（３）は、限定ではなく例として、複数の端末によって構成されるシステムとすることができる。
このシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。

なお、上記は、制御部に限らず、システムの構成要素となり得る入出力部、通信部、記憶部、時計部等の各機能部についても同様である。

以下の実施形態では、限定ではなく例として、端末とサーバとを含むシステム（限定ではなく例として、クライアントサーバシステム）を例示する。
なお、サーバとして、上記（２）のサーバシステムを適用することも可能である。

また、端末とサーバとを含むシステムに代えて、サーバを含まないシステム、限定ではなく例として、上記（３）のシステムを適用することも可能である。
この場合の実施形態は、前述したブロックチェーンの技術等に基づいて構成することが可能である。具体的には、限定ではなく例として、以下の実施形態で説明するサーバに記憶されて管理されるデータを、ブロックチェーン上に保管（格納）する。そして、端末が、ブロックチェーンへのトランザクションを生成し、トランザクションがブロックチェーン上で承認されると、ブロックチェーン上に保管されたデータが更新されるようにすることができる。

なお、端末と表現した場合でも、これは、クライアントサーバにおけるクライアントの装置としての端末の意味に限定されるものではない。
つまり、端末は、クライアントサーバにおけるものではない装置の概念を含むこともあり得る。

また、本明細書では、適宜「通信Ｉ／Ｆによって」という表現を用いる。これは、限定ではなく例として、装置が、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示してもよいものとする。

また、本明細書において「関する」、「関連する」と記載された用語について、「Ａに関するＢ」や「Ａに関連するＢ」という場合、限定ではなく例として、「Ａ」と何らかの関係性を有する「Ｂ」を意味してよいものとする。この具体例については後述する。

また、本明細書において、「ＡとＢとを送信する」、「ＡとＢとを受信する」といったように、装置が２以上のものを対象として処理を行うことには、「Ａ」と「Ｂ」とをタイミングを合わせて行うもの（以下、「同時」という。）と、「Ａ」と「Ｂ」とをタイミングをずらして行うもの（以下、「非同時」という。）とを含めてよいものとする。
限定ではなく例として、第１情報と第２情報とを送信するという場合、第１情報と第２情報とをタイミングを合わせて送信するものと、第１情報と第２情報とをタイミングをずらして送信するものとの両方の概念を含めてよいものとする。
なお、ラグ（タイムラグ）を考慮し、「同時」には「ほぼ同時」を含めてよいものとする。

なお、「Ａ」と「Ｂ」とをタイミングをずらして行うといっても、これはあくまでも「Ａ」と「Ｂ」とを対象として処理を行うものであればよく、その目的は必ずしも同じでなくてもよいものとする。
限定ではなく例として、上記のように第１情報と第２情報とを送信するという場合、第１情報と第２情報とを送信しさえすればよく、同じ目的で第１情報と第２情報とを送信する場合の他、異なる目的で第１情報と第２情報とを送信する場合も含めてよいものとする。

以下の実施例では、ユーザが支払いを行うためのサービス（以下、「支払いサービス」と称する。）を例示する。また、支払いサービスを実現するためのアプリケーションを「支払いアプリケーション」と称する。
支払いアプリケーションでは、限定ではなく例として、ユーザが電子貨幣を用いた支払い（決済）を行うようにことができるようにすることができる。

電子貨幣を用いた支払い方法としては、限定ではなく例として、「利用者提示型」のコード支払いと、「店舗提示型」のコード支払いとのうちのいずれかの方法を適用することができる。

「利用者提示型」のコード支払いは、限定ではなく例として、端末２０の表示部２４に表示されたコード情報をユーザが店舗の店員に提示し、店舗のコードリーダで読み取ってもらうことで支払いを行う方法とすることができる。
「店舗提示型」のコード支払いは、限定ではなく例として、店舗側が提示するコード情報をユーザが自己の端末２０のコードリーダに読み取らせて支払いを行う方法とすることができる。

いずれの支払い方法を適用することも可能であるが、以下の実施例では、簡明化のため「利用者提示型」のコード支払いを中心に説明する。ただし、「店舗提示型」のコード支払いについても同様に適用することが可能である。

また、以下の実施例では、ユーザがチャットを行うためのサービス（以下、「チャットサービス」と称する。）の一例として、メッセージングサービス（Messaging Service）を例示する。また、チャットサービスを実現するためのアプリケーションを「チャットアプリケーション」と称し、メッセージングサービスを実現するためのアプリケーションを「メッセージングアプリケーション」と称する。
チャットアプリケーションでは、限定ではなく例として、ユーザがチャットルームでチャットを行うことができるようにすることができる。

なお、メッセージングサービス：ＭＳ（インスタントメッセージサービス：ＩＭＳを含む。）は、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と考えることもできる。このため、メッセージンサービスとソーシャルネットワーキングサービスとを区別してもよいし、区別しなくてもよい。つまり、ソーシャルネットワーキングサービスにメッセージングサービスを含めてもよいものとする。

また、以下の実施例では、メッセージングサービスの一例として、サーバを介して複数の装置（限定ではなく例として、端末）間で、コンテンツを簡単なメッセージの形式で送受するインスタントメッセージングサービス：ＩＭＳ（Instant Messaging Service）を例示する。
インスタントメッセージングアプリケーションでは、限定ではなく例として、ユーザがトークルームでトークを行うようにすることができる。

チャットルーム（限定ではなく例として、トークルーム）とは、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）とすることができる。

また、トークルームには、一対一のユーザのトークルーム（以下、「一対一トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、公式アカウントのユーザとのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

なお、一対一トークルームは、データ管理上、一対一のユーザや一対一のアカウントのトークルームとして管理してもよいし、２名のユーザや２つのアカウントで構成されるグループのトークルームとして管理してもよい。

公式アカウントは、一般のユーザではなく事業者のアカウント（事業者のユーザのアカウント）であり、この公式アカウントのユーザも、限定ではなく例として、一般のユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でコンテンツ（メッセージ）の送受信を行うことができるようにすることができる。

本明細書において、コンテンツとは、送信元から送信先に送信される情報であってもよい。また、コンテンツは、１または複数のコンテンツであってもよい。

コンテンツには、限定ではなく例として、テキスト形式のテキストコンテンツ、画像（静止画像、動画像の少なくともいずれか一方を含む。）形式の画像コンテンツ、音（音声を含む。）形式の音コンテンツなどを含めてよいものとする。
なお、この他にも、ユーザの操作に供するボタンやアイコン等の操作コンテンツや、リンク情報（限定ではなく例として、ＵＲＩ（Uniform Resource Identifier）等を含む。）などのリンクコンテンツを含めてもよいものとする。

テキストには、限定ではなく例として、文字コードで表される各国の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくともいずれか１つを含めてよいものとする。
なお、テキストは、上記の文字、拡張文字、機種依存文字、数字、記号、図形及び符号の少なくとも１つを含まなくてもよく、その他のテキストを含んでもよい。

画像には、限定ではなく例として、アイコン、ボタン、スタンプ、絵文字、バナー画像といった各種の画像の情報のうちの少なくともいずれか１つを含めることができる。

支払いサービス（支払いアプリケーション）を実現するための形態としては、限定ではなく例として、以下のいずれかの形態を適用することができる。
（Ａ）メッセージングアプリケーションの一機能として支払いサービスの機能を持たせる形態
（Ｂ）支払いサービスの機能とメッセージングサービスの機能とを有するアプリケーション（統合的なアプリケーション）を構成する形態
（Ｃ）支払いアプリケーションとは別のアプリケーションとしてメッセージングアプリケーションを構成する形態

（Ａ）や（Ｂ）の形態では、限定ではなく例として、支払いサービス事業者を、メッセージングサービス事業者と同じ事業者とすることができる。
また、この場合、１つの方法として、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとを共通のアカウントとすることができる。
また、この場合、別の方法として、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとが自動的に関連付けられる（連携される）ようにすることができる。

（Ｃ）の形態では、限定ではなく例として、支払いサービス事業者を、メッセージングサービス事業者とは異なる事業者とすることができる。
また、（Ｃ）の形態では、メッセージングアプリケーションにおけるユーザのアカウントと、支払いアプリケーションにおけるユーザのアカウントとを関連付ける処理（連携する処理）を行うようにすることができる。

なお、上記とは異なり、支払いアプリケーションの一機能としてメッセージングサービスの機能を持たせるようにすることも可能である。

本明細書において、「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末、または端末のユーザが所有する電子的な貨幣を意味するものとしてよいものとする。
なお、「電子貨幣」は、「デジタル通貨（デジタル貨幣）」と考えてもよいものとする。

１つの考え方として、電子貨幣は、「電子マネー」、「仮想通貨（暗号資産）」、「中央銀行発行デジタル通貨（ＣＢＤＢ）」などを含む概念と考えてもよいものとする。

また、電子貨幣は、「法定通貨」でもよいし、「企業通貨」でもよいものとする。電子貨幣の実装方法としては、「中央集権型金融（ＣｅＦｉ）」としてもよいし、「分散型金融（ＤｅＦｉ）」としてもよいものとする。

以下説明する実施例では、限定ではなく例として、電子貨幣の一例として、中央集権型金融における企業通貨としての電子マネーについて例示する。

なお、企業通貨には、クーポンなどの物的貨幣を含めてもよいものとする。

＜第１実施例＞
第１実施例は、限定ではなく例として、一の端末２０（以下、適宜「第１端末」と称する。）のユーザから他の端末２０（以下、適宜「第２端末」と称する。）のユーザに対して電子貨幣が送金され、第２端末のユーザにより電子貨幣の少なくとも一部が使用されたことに基づき、通知が所定の端末２０（以下、適宜「第３端末」と称する。）に送信されるようにする実施例である。

以下では、前述したように、支払いアプリケーションによる支払いサービスを提供する事業者のことを「支払いサービス事業者」と称する。
なお、支払いサービス事業者は、支払いアプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
また、決済サービスを提供する事業者という意味で、決済サービスの事業者と表現することもできる。

また、支払いサービス事業者と提携し、店舗で提供される物販・サービスに対する支払いにおいて支払いアプリケーションを用いる支払いサービスが利用可能な店舗を「加盟店」とすることができる。

また、以下では、支払いアプリケーションの名称を、適宜「Ｐａｙｍｅｎｔ Ａｐｐ」と称して図示・説明する。

第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜システム構成＞
図１－１は、本開示の実施形態における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、１以上の店舗ＰＯＳシステム４０とが接続される。

サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に、所定のサービス（限定ではなく例として、支払いサービス、メッセージングサービス等）を提供する機能を有する。サーバ１０は、限定ではなく例として、支払いサーバ、決済サーバ、メッセージングサーバ等のように表現することもできる。
本実施形態では、支払いサービス事業者（運営者）やメッセージングサービス事業者（運営者）をサーバ１０のユーザとする。

なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、ＶＲ（Virtual Reality）端末、スマートスピーカ（音声認識用デバイス）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は、限定ではなく例として、同一とすることができる。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現してもよいし、しなくてもよい。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。

［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。

（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置や、端末２０で処理された処理結果を出力する装置等を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部２３は、限定ではなく例として、表示部２４、音入力部２５、音出力部２６、撮像部２７を備える。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。

音入力部２５は、音データ（音声データを含む。以下同様。）の入力に利用される。音入力部２５は、マイクなどを含む。
音出力部２６は、音データの出力に利用される。音出力部２６は、スピーカなどを含む。
撮像部２７は、画像データ（静止画像データ、動画像データを含む。以下同様。）の取得に利用される。撮像部２７は、カメラなどを含む。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。

位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。

位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））、ＵＷＢ（超広帯域無線：Ultra Wide Band）を利用して端末２０の位置を算出するためのセンサやユニットであるＵＷＢ測位センサ（ＵＷＢ測位ユニット）等を含む。

衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。

慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。

ＵＷＢ測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用ビーコンから発信されている測位用超広帯域パルス信号を含む超広帯域ＲＦ（Radio Frequency）信号をデジタル信号に変換する超広帯域ＲＦ受信回路や、超広帯域ＲＦ受信回路から出力されるデジタル信号に基づいて端末２０と測位用ビーコンとの相対位置を算出する相対位置算出処理回路等を有する。
なお、限定ではなく例として、ＵＷＢ測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域ＲＦ信号を送信することで、端末２０を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。

制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させるようにしてもよいし、そうしなくてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。

（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。

制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。

記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部１２は、サーバ１０に対する各種操作を入力する装置や、サーバ１０で処理された処理結果を出力する装置等を含む。入出力部１２は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入力部は、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。

出力部は、制御部１１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

あくまでも一例であるが、入出力部１２は、限定ではなく例として、表示部１３を備える。

表示部１３は、ディスプレイ等で実現される。ディスプレイは、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイは、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイは、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイは、これらに限定されない。

時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。

（３）店舗ＰＯＳのシステム構成
図１－２には、店舗ＰＯＳシステム４０のシステム構成の一例を示している。
店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者と提携している店舗に導入されて使用されるＰＯＳシステムであり、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とを含む。

店舗コードリーダ装置５０は、ＰＯＳ通信Ｉ／Ｆ５７（限定ではなく例として、店舗内の有線通信Ｉ／Ｆや無線通信Ｉ／Ｆ）によってコードレジ６０や店舗サーバ７０と通信接続され、コードレジ６０での会計の際に、端末２０の表示部２４に表示されるコード情報を読み取る。そして、読み取ったコード情報に基づいて、決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信し、サーバ１０で決済が行われた後、決済結果に関する情報を通信Ｉ／Ｆ５４によってサーバ１０から受信する。

店舗コードリーダ装置５０は、限定ではなく例として、制御部５１と、入出力部５２と、表示部５３と、通信Ｉ／Ｆ５４と、記憶部５５と、音出力部５６と、ＰＯＳ通信Ｉ／Ｆ５７と、コードリーダ５８、時計部５９とを有する。

コードリーダ５８は、一次元コード（一次元コード画像）や二次元コード（二次元コード画像）、限定ではなく例として、後述するウォレットコード情報等のコード情報を読み取るためのコードリーダである。

コードレジ６０は、限定ではなく例として、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０や店舗サーバ７０と通信接続され、店舗コードリーダ装置５０がサーバ１０から受信した決済完了通知等に基づいて、販売した商品の総額や、端末２０のユーザの電子貨幣の残高等の情報を印字したレシートを発行する。

また、限定ではなく例として、コードレジ６０と一体として、またはコードレジ６０と別体として設けられ、客側に表示面が向けられたディスプレイを構成することもできる。
コードレジ６０は、支払いアプリケーションに対応可能に構成されたレジであり、支払いアプリケーション対応の据置端末と言うこともできる。

店舗サーバ７０は、限定ではなく例として、自店舗に関する店舗情報や、自店舗で販売される商品に関する情報や自店舗で提供されるサービスに関する情報、自店舗での商品の販売やサービスの提供に伴う売上げに関する情報等の各種の情報を管理する。店舗サーバ７０は、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０やコードレジ６０と通信可能に構成されているとともに、ネットワーク３０を介してサーバ１０等の外部装置と通信可能に構成されている。

なお、店舗サーバ７０は、必ずしも店舗コードリーダ装置５０と直接的に通信可能に構成されている必要はなく、コードレジ６０を介して店舗コードリーダ装置５０と通信可能に構成されていてもよい。限定ではなく例として、店舗コードリーダ装置５０がサーバ１０から受信した決済完了通知等はコードレジ６０に送られ、その後、コードレジ６０から店舗サーバ７０に送られるようにするなどすることもできる。

（３）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。

なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

また、システムのプログラム（システムによって実行されるプログラム）という場合、システムについては前述した通りである。そして、前述したシステムのプログラムとは、システム全体で実行可能なプログラムであって、このプログラムは、限定ではなく例として、システムを構成する装置個々のプログラムで構成されてもよく、システムを構成する個々の装置に保存されるプログラムは、各々異なっていてもよいものとする。つまり、システムを構成する個々の装置で共通のプログラムでなくてもよいものとする。
限定ではなく例として、システムが端末とサーバとで構成されている場合、システムのプログラムをＰ１とすると、システムのプログラムＰ１は、端末に保存されたプログラムＰ２と、サーバに保存されたプログラムＰ３とで構成され、Ｐ２とＰ３とは、システムのプログラムを実行するためのものであり、それぞれ異なるプログラムとなっていてもよい。限定ではなく例として、端末に保存されたプログラムＰ２は、第１の処理を実行し、第１の処理をした結果をサーバに送信するプログラムであり、サーバに保存されたプログラムＰ３は、受信した第１の処理をした結果に対して第２の処理を行い、第２の処理を行った結果を端末に送信するプログラムであってもよい。

記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。

サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部、または全部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部、または全部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。

明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。

なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML Living Standardなどのマークアップ言語などを用いて実装される。

＜機能構成＞
（１）サーバの機能構成
図１－３は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶されたアプリケーション管理処理プログラム１５１に従ってアプリケーション管理処理を実行するためのアプリケーション管理処理部１１１を機能部として含む。

図１－４は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、アプリケーション管理処理として実行されるアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５とが記憶される。

アカウント登録データ１５３は、アプリケーション（本実施例では、支払いアプリケーション）のアカウントに関する登録データであり、そのデータ構成の一例を図１－５に示す。
アカウント登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、その他登録情報とが関連付けて記憶される。

ユーザ名は、このアプリケーションを利用する端末２０のアカウントの名称であり、限定ではなく例として、端末２０のユーザがアプリケーションを利用する際に登録する名称が記憶される。

アプリケーションＩＤは、アプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号（端末電話番号）、メールアドレス（端末メールアドレス）、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報といった各種の情報を含めるようにすることができる。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、一般ユーザ用のアプリケーションＩＤや公式ユーザ用のアプリケーションＩＤとすることができる。

なお、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。

また、限定ではなく例として、１つのアプリケーションＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。

また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号等の情報によってアカウントを管理する手法を適用することも可能である。
この場合、アプリケーションＩＤ等のＩＤの情報をアカウント登録データ１５３に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ１５３に記憶させるようにすることができる。

なお、以下の各種の実施例では、説明の簡明化のため、１つの端末２０につき１つのアカウントが登録されていることとして説明する。
また、この場合、上記のように「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」であるため、以下の説明で用いる「アカウントのユーザ」の用語は、「アカウントの端末」と実質的に同義としてよいものとする。

アカウント管理データベース１５５は、アカウント登録データ１５３に登録されたアカウントに関する情報を管理するためのデータベースであり、その一例であるアカウント管理データベース１５５Ａのデータ構成例を図１－６に示す。
アカウント管理データベース１５５Ａには、アカウントごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、通常電子マネー残高と、通知付き電子マネー管理データとが記憶される。

通常電子マネー残高は、このアプリケーションＩＤのアカウントに関連付けられた、通常（普通）の電子マネーの残高である。

通知付き電子マネー管理データは、このアプリケーションＩＤのアカウントに関連付けられた、通知付き電子マネーに関する情報を管理するためのデータであり、限定ではなく例として、通知先ＩＤと、通知者名と、通知付き電子マネー残高とが関連付けて記憶される。

以下説明する実施例では、送金元アカウント（または送金元ユーザ）の端末２０、またはサーバ１０が、送金先アカウント（または送金先ユーザ）に電子マネーを送金することに関する設定として、通知先アカウント（または通知先ユーザ）に対する通知を行う設定を行うことが可能に構成されていることとして説明する。また、この設定に基づいて送金を行うことを「通知付き送金」と称し、この設定に基づいて送金される電子マネーのことを「通知付き電子マネー」と称する。
通知には、限定ではなく例として、送金先アカウント（またはそのユーザ）によって通知付き電子マネーが使用されたことに基づく通知を含めることができる。この通知を「通知付き電子マネー使用通知」と称する。

通知先ＩＤは、通知付き電子マネー使用通知の通知先のアカウント（以下、「通知先アカウント」と称する。）を識別するための情報であり、限定ではなく例として、通知先アカウントとして設定されたアカウントのアプリケーションＩＤが記憶される。

通知者名は、この通知先ＩＤに対応するユーザ名である。アカウント登録データ１５３において、この通知先ＩＤに対応するアプリケーションＩＤに関連付けられたユーザ名が記憶される。

通知付き電子マネー残高は、この通知先ＩＤに関連付けられた通知付き電子マネーの残高である。

限定ではなく例として、送金元アカウントによって通知付き電子マネーが送金先アカウントに送金されるごとに、通知先ＩＤと、通知者名と、通知付き電子マネー残高とが関連付けられ、新たなレコードとして通知付き電子マネー管理データに追加・記憶されるようにすることができる。
そして、支払い等によって通知付き電子マネー残高が減少することで、通知先ＩＤのアカウントのユーザの端末２０に対して通知付き電子マネー使用通知が行われるようにすることができる。

なお、本実施例では、送金先アカウントのユーザに対して誰から通知付き電子マネーが送金されたかという情報は必須ではない。このため、通知付き電子マネー管理データでは、送金元ＩＤ等の情報は記憶させず、通知先ＩＤと関連付けて通知付き電子マネー残高を記憶させるようにしている。

また、限定ではなく例として、第１実施例～第３実施例では、「通知先アカウント＝送金元アカウント」とし、通知付き送金を行ったアカウント（またはそのユーザ）に対して通知付き電子マネー使用通知が行われることとして説明する。

（２）端末の機能構成
図１－７は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されたアプリケーション処理プログラム２８１に従ってアプリケーション処理を実行するためのアプリケーション処理部２１１を機能部として含む。

図１－８は、本実施例において端末２０の記憶部２８に記憶されるデータ等の一例を示す図である。
記憶部２８には、限定ではなく例として、アプリケーション処理として実行されるアプリケーション処理プログラム２８１と、この端末２０、または端末２０のユーザのアカウントに対応するアプリケーションＩＤ２８３とが記憶される。

＜表示画面＞
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。

スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。

以下では、ユーザによる操作を、限定ではなく例として、タップ（タップ操作）として説明する。
タップ（タップ操作）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。

なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。

図１－９は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。ここでは、
・送金元アカウント＝ユーザＢ．Ｂ（第１端末のユーザ）のアカウント
・送金先アカウント＝ユーザＡ．Ａ（第２端末のユーザ）のアカウント
・通知先アカウント＝送金元アカウント＝ユーザＢ．Ｂ（第１端末のユーザ）のアカウント
とする場合を例示する。

図１－９左側は、限定ではなく例として、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される支払いアプリケーションのメインメニュー画面である。

メニュー画面最上部中央には、支払いアプリケーションの名称として「Ｐａｙｍｅｎｔ Ａｐｐ」の文字が表示されている。また、画面最上部右方には、この端末２０Ｂのユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＢ．Ｂ）が表示されている。

また、その下には、支払いアプリケーションにおけるページ名を示すページ名表示領域が構成されており、この例では、ページ名が支払いアプリケーションのメインメニューであることを示す「ウォレットメインメニュー」の文字が、ページ名表示領域内に表示されている。

ページ名表示領域の下の領域には、このアカウントの電子マネー残高の情報を表示する残高表示領域ＢＲ１が構成されている。残高表示領域ＢＲ１には、限定ではなく例として、「残高」の文字とともに、このアカウントの最新の電子マネー残高と、通常電子マネー残高に電子マネーをチャージするためのチャージボタンＣＢＴとが表示される。

メインメニュー画面の下部に表示された「送金」の文字およびイラストを含む「送金」アイコンＩＣ１がタップされると、限定ではなく例として、図１－９中央の画面が表示される。
この画面は、送金先アカウントを設定するための画面であり、限定ではなく例として、送金先アカウントを指定するための情報として、「送金先を指定してください」のテキストとともに、送金先アカウントを電話番号で検索するための検索ボックスが表示されている。

また、その下には、過去に通知付き送金を行ったアカウントに関する情報が一覧表示されている。具体的には、この例では、ユーザＡ．Ａに対応するアイコン画像およびユーザ名（Ａ．Ａ）と、ユーザＣ．Ｃに対応するアイコン画像およびユーザ名（Ｃ．Ｃ）とが表示されている。また、それぞれの左側には、チェックボックスが設けられており、チェックボックスをタップすると、チェックボックスにチェックマークが入れられ、そのユーザのアカウントを送金先アカウントとして指定することが可能に構成されている。この例では、ユーザＡ．Ａに対応するチェックボックスにチェックが入れられた状態が示されている。

この状態で、画面下部の「決定」ボタンＢＴ１がタップされると、限定ではなく例として、図１－９右側の画面が表示される。
この画面は、送金金額の指定や通知設定を行うための画面であり、限定ではなく例として、画面上部には、送金金額の指定に関する情報として、「金額を指定してください」のテキストとともに、送金額を直接入力またはボタンを用いて指定するための情報が表示されている。

また、その下には、通知設定を行うための情報が表示されている。具体的には、限定ではなく例として、「送金先」の文字とともに、図１－９中央の画面で設定された送金先アカウントのユーザであるユーザＡ．Ａのアイコン画像およびそのユーザ名（Ａ．Ａ）が表示されている。

また、その下には、ユーザＡ．Ａによって電子マネーが使用された場合に、その旨を示す情報（以下、「通知付き電子マネー使用情報」と称する。）を受信するか否かを設定するためのスライドボタンが表示されている。この例では、スライドボタンに対するタップ操作、またはスライド操作がなされたことで、通知設定が「ＯＮ」とされた状態が示されている。

限定ではなく例として、通知付き電子マネー使用情報を通知先アカウントのユーザの端末２０で受信して表示や音出力等することで、送金先アカウントによって通知付き電子マネーが使用されたことが通知される。この通知を「通知付き電子マネー使用通知」と称する。

この状態で、画面下部の「送金」ボタンＢＴ２がタップされると、ユーザＡ．Ａの端末２０Ａの表示部２４に、限定ではなく例として、図１－１０左側の画面が表示される。
この画面は、端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
ページ名表示領域の下には、おしらせの内容が表示されるおしらせ領域が構成されており、おしらせ領域内の向かって左側に、通知付き電子マネーの送金結果に関する情報である通知付き電子マネー送金結果情報ＮＲ１が表示されている。
なお、ユーザＡ．Ａにとっては、通知付き電子マネーを受け取ったことを示す情報であるため、通知付き電子マネー受取結果情報と考えることも可能である。

通知付き電子マネー送金結果情報ＮＲ１には、限定ではなく例として、送金された金額（受け取った金額）と、サーバ１０によって通知付き電子マネー送金処理が行われた日時である送金日時と、受け取り側（送金先）であることを示す「受取」アイコンと、送金元と送金先とをイラスト化した情報と、詳細を確認するための「＞詳細を確認」ボタンとが含まれる。

この例では、送金金額として「１，０００円」が表示され、その横には、送金を受け取ったことを示す「受取」アイコンが表示されている。また、送金日時として「２０２１年４月５日１０時２３分」が表示され、送金元アカウントとしてユーザＢ．Ｂのアイコン画像およびそのユーザ名（Ｂ．Ｂ）が、送金先アカウントとしてユーザＡ．Ａのアイコン画像およびそのユーザ名（Ａ．Ａ）が表示されている。

ユーザＡ．Ａによって、限定ではなく例として、画面下部の「メニューに戻る」ボタンＢＴ３がタップされると、限定ではなく例として、図１－１０中央のメインメニュー画面が表示される。図１－９左側の端末２０Ｂのメインメニュー画面と同様に、端末２０Ａのメインメニュー画面には残高表示領域ＢＲ２が構成されている。

ここで、残高表示領域ＢＲ２に表示される残高は、限定ではなく例として、通常電子マネー残高と、通知付き電子マネー残高とを合算した値とすることができる。
限定ではなく例として、図１－６のアプリケーションＩＤ「Ｕ００１」のアカウントは、この例におけるユーザＡ．Ａのアカウントであり、通常電子マネー残高は「５００円」である。また、この例では、ユーザＢ．ＢからユーザＡ．Ａに対して通知付き送金として「１，０００円」が送金され、ユーザＡ．Ａがこれを受け取っている。このため、通常電子マネー残高と通知付き電子マネー残高とを合算すると「１，５００円」となる。このため、残高表示領域ＢＲ２には、電子マネー残高として「１，５００円」が表示されている。

その後、ユーザＡ．Ａが、限定ではなく例として、店舗で買い物を行おうとしているものとする。この場合、図１－１０中央のメインメニュー画面において、限定ではなく例として、「コード支払い」の文字を含む「コード支払い」アイコンＩＣ２がタップされると、限定ではなく例として、図１－１０右側の画面が表示される。

この画面は、コード支払いを行うためのコード支払い画面であり、ページ名表示領域には「コード支払い」の文字が表示されている。
また、その下の領域内には、ウォレットコード情報が表示されるウォレットコード情報表示領域ＷＣＲ１が構成されている。

この例では、ウォレットコード情報表示領域ＷＣＲ１には、ウォレットコード情報として、限定ではなく例として、ユーザＡ．Ａの電子マネー残高を示す「残高」の文字およびその金額（この例では「１，５００円」）と、一次元コード画像（限定ではなく例として、バーコード）で表される一次元ウォレットコード画像と、二次元コード画像（限定ではなく例として、ＱＲコード）で表される二次元ウォレットコード画像とが表示されている。

また、この例では、一次元コード画像の下には、ウォレットコード情報として、所定の桁数（この例では「１２桁」）で表されるウォレットトークン（この例では「１２３４５６７８９０００」）が表示されている。
このウォレットトークンは、限定ではなく例として、エンコードによって二次元ウォレットコード画像に格納されるようにすることができる。

なお、一次元ウォレットコード画像と二次元ウォレットコード画像との両方を必ずしも表示させる必要はなく、いずれか一方のみを表示させるようにしてもよい。
また、ウォレットトークンは表示させないようにしてもよい。
また、この図に示すように、ウォレットコード情報の有効期限に関する情報（限定ではなく例として、二次元ウォレットコード画像の下に表示される有効期限までの残り時間）を表示させてもよいし、表示させなくてもよい。

また、ウォレットコード情報は、支払い（決済）を行うために用いられるコード情報であるため、支払いコード情報や決済コード情報等のように称してもよい。

本実施例では、限定ではなく例として、通常電子マネー残高＜通知付き電子マネー残高である場合、サーバ１０は、以下に基づいて決済（決済処理）を行うようにすることができる。
（ａ）支払い金額≦通常電子マネー残高：通常電子マネー残高から決済
（ｂ）通常電子マネー残高＜支払い金額≦通知付き電子マネー残高：通知付き電子マネー残高から消費
（ｃ）通知付き電子マネー残高＜支払い金額：決済不可（決済ＮＧ）
つまり、本実施例では、通常電子マネー残高と、通知付き電子マネー残高との両方を用いた決済（合算決済）は行わない。

具体的には、
（ａ）は、この例では、５００円以下の支払いを行う場合は、通常電子マネー残高から決済を行うことを意味する。
（ｂ）は、この例では、５００円超１０００円以下の支払いを行う場合は、通知付き電子マネー残高から決済を行うことを意味する。
（ｃ）は、この例では、１０００円超の支払いを行う場合は、支払い不可であることを意味する。

なお、本実施例では、上記（ｃ）のように、支払い金額が通知付き電子マネー残高の最大値を超える場合は支払い不可とする。このため、上記のウォレットコード情報表示領域に表示される残高を、通知付き電子マネー残高とすることも可能である。

また、上記（ａ）で決済を行う場合にも、上記（ｂ）と同様に、通知付き電子マネー残高から決済を行うようにしてもよい。つまり、通知付き電子マネー残高を通常電子マネー残高よりも優先して使用して決済を行うようにしてもよい。

限定ではなく例として、通常電子マネー残高≧通知付き電子マネー残高である場合、サーバ１０は、以下に基づいて決済（決済処理）を行うようにすることができる。
（ｄ）支払い金額≦通知付き電子マネー残高：通知付き電子マネー残高から決済
（ｅ）通知付き電子マネー残高＜支払い金額≦通常電子マネー残高：通常電子マネー残高から消費
（ｆ）通常電子マネー残高＜支払い金額：決済不可（決済ＮＧ）

上記（ｄ）で決済を行う場合にも、上記（ｅ）と同様に、通常電子マネー残高から決済を行うようにしてもよい。つまり、通常電子マネー残高を通知付き電子マネー残高よりも優先して使用して決済を行うようにしてもよい。

図１－１０右側のコード支払い画面において、限定ではなく例として、一次元ウォレットコード画像または二次元ウォレットコード画像が、店舗コードリーダ装置５０のコードリーダ５８によって読み取られると、サーバ１０によって決済が行われる。
この例では、ユーザＡ．Ａは、「ＸＸ書店」において「１，０００円」の書籍を購入したとする。その結果、限定ではなく例として、図１－１１の左側の画面が表示される。

この例では、支払いが完了したことを示すロボットの画像や文字の他、限定ではなく例として、決済金額（この例では「１，０００円」）と、支払い日時（この例では「２０２１年４月５日１４時５０分」）と、支払い先（この例では「ＸＸ書店」）とが表示されている。

画面下部の「確認」ボタンＢＴ４がタップされると、限定ではなく例として、図１－１１中央の画面が表示される。この画面は、前述したメインメニュー画面であり、支払いによって、残高表示領域ＢＲ２に表示される残高が「１，５００円」から「５００円」に減少している。

図１－１１右側は、この場合に通知先アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このお知らせ画面では、図１－１０左側に示した端末２０Ａのおしらせ画面に表示される通知付き電子マネー送金結果情報ＮＲ１に対応する通知付き電子マネー送金結果情報ＮＲ２が表示されている。

通知付き電子マネー送金結果情報ＮＲ２には、限定ではなく例として、送金金額と、送金日時と、通知付き電子マネーの送金元であることを示す「送金」アイコンと、送金元と送金先とをイラスト化した情報と、「＞詳細を確認」ボタンとが含まれる。

また、その下には、ユーザＡ．Ａに送金した通知付き電子マネーがユーザＡ．Ａによって使用されたことを示す通知付き電子マネー使用情報ＮＵ２が表示されている。
この通知付き電子マネー使用情報ＮＵ２には、限定ではなく例として、通知付き送金で送金した金額が使用された日時（この例では「２０２１年４月５日１４時５０分」）と、使用されたことを示す文字（この例では「Ａ．Ａに送金した電子マネーが使用されました」）と、「＞詳細を確認」ボタンとが含まれる。
この通知付き電子マネー使用情報ＮＵ２により、ユーザＡ．Ａに送金を行ったユーザＢ．Ｂは、送金した金額がユーザＡ．Ａによって使用されたことを知ることができる。

＜処理＞
図１－１２，図１－１３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａの制御部２１が実行する処理、端末２０Ｂの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理、店舗ＰＯＳシステム４０が実行する処理の一例を示している。

なお、以下説明する処理は、本開示の手法を実現するための処理の一例に過ぎず、これらに限定されるものではない。
以下説明する処理に別のステップを追加してもよいし、以下説明する処理から一部のステップを省略（削除）してもよい。

ここでは、表示画面と同様に、
・送金元アカウント＝ユーザＢ．Ｂ（第１端末のユーザ）のアカウント
・送金先アカウント＝ユーザＡ．Ａ（第２端末のユーザ）のアカウント
・通知先アカウント＝送金元アカウント＝ユーザＢ．Ｂ（第１端末のユーザ）のアカウント
とする場合の処理を例示する。

最初に、端末２０Ｂの制御部２１は、入出力部２３に対するユーザ入力等に基づいて、通知付き電子マネーの送金に関する設定処理として、通知付き電子マネー送金設定処理を行う（Ｂ１１０）。具体的には、限定ではなく例として、送金する金額、送金先アカウント（この例ではユーザＡ．Ａのアカウント）、通知付き電子マネー通知を行うか否か（ＯＮ／ＯＦＦ）、通知先アカウント（この例ではユーザＢ．Ｂのアカウント）等の設定等を行う。

次いで、端末２０Ｂの制御部２１は、限定ではなく例として、送金元アカウントであるアプリケーションＩＤと、Ｂ１１０で設定した設定情報とを含む通知付き電子マネー送金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１２０）。

通信Ｉ／Ｆ１４によって端末２０Ｂから通知付き電子マネー送金依頼情報を受信すると、サーバ１０の制御部１１は、通知付き電子マネー送金処理を行う（Ｓ１１０）。
具体的には、設定情報に基づいて、ユーザＢ．Ｂのアカウント管理データの通常電子マネー残高から送金金額分の金額を減算する。また、ユーザＡ．Ａのアカウント管理データの通知付き電子マネー管理データに、通知先ＩＤ（この例では「Ｕ０００２」）と、通知者名（この例では「ユーザＢ．Ｂ」）と、通知付き電子マネー残高（送金金額分の金額）とを関連付けたレコードを追加する。

その後、サーバ１０の制御部１１は、通知付き電子マネー送金結果に関する情報である通知付き電子マネー送金結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ１２０）。
端末２０Ａの制御部２１と、端末２０Ｂの制御部２１とは、サーバ１０から受信した電子マネー送金結果情報を、それぞれ表示部２４に表示させる（Ａ１１０，Ｂ１３０）。

Ａ１１０の後、端末２０Ａの制御部２１は、入出力部２３に対するユーザ入力に基づいて、ウォレット支払い要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。
通信Ｉ／Ｆ１４によって端末２０Ａからウォレット支払い要求情報を受信すると、サーバ１０の制御部１１は、限定ではなく例として、前述したウォレットコード情報を生成した上で、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１３０）。
なお、電子マネー残高の情報をウォレットコード情報に含めてもよい。

通信Ｉ／Ｆ２２によってサーバ１０からウォレットコード情報を受信すると、端末２０Ａの制御部２１は、受信したウォレットコード情報を表示部２４に表示させる（Ａ１３０）。表示部２４に表示されたウォレットコード情報は、店舗ＰＯＳシステム４０の店舗コードリーダ装置５０（コードリーダ５８）によって読み取られる（Ｐ１１０）。

店舗コードリーダ装置５０は、限定ではなく例として、店舗情報（店舗ＩＤ等）、決済要求金額、読み取ったウォレットコード情報に含まれるウォレットトークン等を含む決済要求情報を、通信Ｉ／Ｆ４４によってサーバ１０に送信する（Ｐ１２０）。

通信Ｉ／Ｆ１４によって店舗ＰＯＳシステム４０から決済要求情報を受信すると、サーバ１０の制御部１１は、決済処理を行う（Ｓ１４０）。この場合、制御部１１は、限定ではなく例として、前述した（ａ）～（ｆ）の手法に基づいて決済を行う。

その後、サーバ１０の制御部１１は、決済の結果に関する情報である決済結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび店舗ＰＯＳシステム４０にそれぞれ送信する（Ｓ１５０）。

端末２０Ａの制御部２１は、サーバ１０から受信した決済結果情報を表示部２４に表示させる（Ａ１４０）。そして、端末２０Ａの制御部２１は、処理を終了する。

同様に、店舗コードリーダ装置５０の制御部５１は、サーバ１０から受信した決済結果情報を表示部５３に表示させる（Ｐ１３０）。そして、店舗コードリーダ装置５０の制御部５１は、処理を終了する。

Ｓ１５０の後、サーバ１０の制御部１１は、Ｓ１４０の決済処理において、決済に通知付き電子マネー残高を使用したか否かを判定する（Ｓ１６０）。
使用しなかったと判定したならば（Ｓ１６０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
一方、使用したと判定したならば（Ｓ１６０：ＹＥＳ）、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって、通知付き電子マネー使用情報を端末２０Ｂに送信する（Ｓ１７０）。そして、サーバ１０の制御部１１は、処理を終了する。

Ｂ１３０の後、端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から通知付き電子マネー使用情報を受信したか否かを判定する（Ｂ１４０）。
受信しなかったと判定したならば（Ｂ１４０：ＮＯ）、端末２０Ｂの制御部２１は、処理を終了する。
一方、受信したと判定したならば（Ｂ１４０：ＹＥＳ）、端末２０Ｂの制御部２１は、受信した通知付き電子マネー使用情報を表示部２４に表示させる（Ｂ１５０）。そして、端末２０Ｂの制御部２１は、処理を終了する。

＜第１実施例の効果＞
本実施例は、サーバ１０は、送金元アカウントのユーザの端末２０（限定ではなく、第１端末の一例）のユーザ（限定ではなく、第１端末のユーザの一例）によって通知に関する設定が行われた電子マネーである通知付き電子マネー（限定ではなく、第１電子貨幣の一例）の送金依頼情報（限定ではなく、第１電子貨幣を送金することに関する情報の一例）を受信する。
また、サーバ１０は、送金依頼情報の受信に基づき、送金先アカウントのユーザに送金される通知付き電子マネーを通知付き電子マネー残高に記憶する制御（限定ではなく、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶する制御の一例）を制御部１１によって行う。
また、サーバ１０は、送金依頼情報の受信に基づき、通知付き電子マネー送金結果情報（限定ではなく、第２端末のユーザに第１端末から送金されたことを示す第２情報の一例）を通信I／Ｆ１４によって送金先アカウントのユーザの端末２０に送信する。
そして、サーバ１０は、送金先アカウントのユーザにより通知付き電子マネーの少なくとも一部が使用されたことに基づき、通知付き電子マネー使用情報（限定ではなく、通知の一例）を通知先アカウントのユーザの端末２０（限定ではなく、第３端末の一例）に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を第２端末のユーザに送金することに関する情報である第１情報の第１端末からの受信に基づき、第２端末のユーザに送金される第１電子貨幣を第２端末のユーザに関連付けて記憶させるとともに、第２端末のユーザに第１端末から送金されたことを知らせることができる。また、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに関する内容を、第３端末のユーザに知らせることができる。

この場合、通知付き電子マネー使用情報は、送金先アカウントのユーザによって、通知付き電子マネーの少なくとも一部が使用されたことを示す情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２端末のユーザによって、第１電子貨幣の少なくとも一部が使用されたことを、第３端末のユーザに知らせることができる。

また、本実施例は、通知先アカウントのユーザの端末２０（限定ではなく、第３端末の一例）は、送金元アカウントのユーザの端末２０（限定ではなく、第１端末の一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことを、通知に関する設定を行った第１端末のユーザに知らせるができる。

１つの例として、子供に買い物等を行わせるために、親（母親、父親）が子供に電子マネーを送金することが考えられる。
この場合、限定ではなく例として、母親のアカウントを送金元アカウントとする。この場合、母親の端末２０が第１端末となる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末２０が第２端末となる。
また、限定ではなく例として、母親のアカウントを通知先アカウントとして設定する。この場合、母親の端末２０が第３端末（＝第１端末）となる。
そして、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、母親のアカウントに対して通知がいくようにすることができる。

また、本実施例は、サーバ１０が、通知付き電子マネー（限定ではなく、通知が設定された第１電子貨幣の一例）と、通常電子マネー（限定ではなく、第２端末のユーザに対して関連付けられた第２電子貨幣の一例）とを区別して記憶する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通知が設定された第１電子貨幣と、通知が設定されていない、第２端末のユーザに対して関連付けられた第２電子貨幣とを区別して管理することができ、ユーザの利便性を向上させることができる。

＜第１変形例（１）＞
上記の実施例において、送金元アカウントのユーザによって、通知先アカウントに通知する内容を設定することを可能としてもよい。

図１－１４は、本変形例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｂの一例を示す図である。
アカウント管理データベース１５５Ｂに含まれる各々のアカウント管理データに記憶される情報は、アカウント管理データベース１５５Ａと同様であるが、通知付き電子マネー管理データに記憶される情報が一部異なっている。

具体的には、通知付き電子マネー管理データには、通知先ＩＤと、通知者名と、通知付き電子マネー残高とに加えて、通知内容が記憶される。
通知内容は、通知先アカウントに通知するより詳細な内容であり、限定ではなく例として、通知付き電子マネーが使用された「金額」、通知付き電子マネーが使用された「店舗」等の情報をこれに含めることができる。

なお、この他にも、通知内容として、支払い先の店舗等で購入された商品やサービス等の情報を含めてもよいし、含めなくてもよい。この場合、店舗ＰＯＳシステム４０は、限定ではなく例として、ユーザが購入しようとしている商品やサービスに関する情報を決済要求情報に含めてサーバ１０に送信するようにすることができる。

また、上記の各種の情報のうちの少なくとも一つの情報を記憶させればよい。つまり、一つの情報を記憶させてもよいし、２以上の情報を記憶させてもよい。

送金元アカウントによって通知付き電子マネーが送金先アカウントに送金されるごとに、通知先ＩＤと、通知者名と、通知付き電子マネー残高と、通知内容とが関連付けられ、新たなレコードとして通知付き電子マネー管理データに追加・記憶される。

サーバ１０の制御部１１は、図１－１３のＰ１２０のステップで店舗ＰＯＳシステム４０から送信された通知内容を特定可能な情報を受信し、図１－１３のＳ１４０の決済処理を行う。そして、サーバ１０の制御部１１は、図１－１３のＳ１７０のステップにおいて、上記の通知内容を通知付き電子マネー使用情報に含めて、通知先アカウントのユーザの端末２０に送信する。そして、通知先アカウントのユーザの端末２０は、通知内容を含む通知付き電子マネー使用情報を表示部２４に表示する。

図１－１５は、本変形例における端末２０の表示画面の遷移の一例を示す図である。
図１－１５左側は、送金元アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂに表示される支払いアプリケーションの送金画面の一例であり、図１－９右側に対応する画面である。

この例では、通知付き電子マネー使用通知を受け取るか否かを設定するための領域に、通知内容を設定するための領域が構成されている。
具体的には、限定ではなく例として、「通知内容」の文字とともに、通知内容として「金額」、「支払い先」、「内容」の３つの項目が表示されており、それぞれの項目に関連付けてチェックボックスが表示されている。チェックボックスをタップすると、そのチェックボックスにチェックが入れられ、その項目を通知内容に含めることが可能に構成されている。この例では、「金額」の項目に対応するチェックボックスと、「支払い先」の項目に対応するチェックボックスとに、それぞれチェックが入れられ、「送金」ボタンＢＴ２がタップされた状態が示されている。

図１－１５中央は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面の一例を示す図であり、図１－１１左側の画面と同様のコード支払い完了画面である。

図１－１５右側は、この場合における通知先であるユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図であり、図１－１１右側に対応する画面である。
このお知らせ画面では、図１－１１右側の画面における通知付き電子マネー使用情報ＮＵ２に代えて、通知付き電子マネー使用情報ＮＵ３が表示されている。

この通知付き電子マネー使用情報ＮＵ３には、図１－１１右側の画面における通知付き電子マネー使用情報ＮＵ２に含まれる情報に加えて、限定ではなく例として、支払いに使用された通知付き電子マネーの金額（この例では「１，０００円」）と、その支払い先（この例では「ＸＸ書店」）とが表示されている。

本変形例において、サーバ１０は、図１－１３のＳ１７０のステップにおいて、通知内容を通知付き電子マネー使用情報に組み込んで、通知先アカウントのユーザの端末２０に送信するようにすることができる。

本変形例は、通知付き電子マネー使用情報は、送金先アカウントのユーザによる支払い金額（限定ではなく、第１電子貨幣のうち使用された金額の一例）、支払い先（限定ではなく、第２端末のユーザによって使用された場所の一例）、購入された商品やサービスのうち少なくとも一つを含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザによって第１電子貨幣のうち使用された金額、第２端末のユーザによって使用された場所、第２端末のユーザによって購入された商品、第２端末のユーザによって購入されたサービスのうち少なくとも一つを、第３端末のユーザに知らせることができる。

＜第１変形例（２）＞
サーバ１０において、通知付き電子マネー残高と、通常電子マネー残高とを区別せずに管理するようにすることも可能である。

図１－１６は、本変形例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｃのデータ構成例を示す図である。
各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、電子マネー残高と、電子マネー使用通知先管理データとが記憶される。

電子マネー残高は、前述した通常電子マネー残高と通知付き電子マネー残高とを区別しない共通の残高である。

電子マネー使用通知先管理データは、通知付き電子マネーが使用された場合の通知先を管理するためのデータであり、限定ではなく例として、通知先ＩＤと、通知者名とが関連付けて記憶される。

本変形例において、サーバ１０は、図１－１２のＳ１１０のステップにおいて、設定情報に基づいて、ユーザＢ．Ｂのアカウント管理データの電子マネー残高から送金金額分の金額を減算する。また、サーバ１０は、ユーザＡ．Ａのアカウント管理データの電子マネー使用通知先管理データに、通知先ＩＤ（前述した例では「Ｕ０００２」）と、通知者名（前述した例では「ユーザＢ．Ｂ」）とを関連付けたレコードを追加するとともに、電子マネー残高に送金金額分の金額を加算する。

また、サーバ１０は、電子マネーが使用されて電子マネー残高が「０」になったと判定したならば、電子マネー使用通知先管理データをクリアする。

本変形例は、サーバ１０が、通知付き電子マネー（限定ではなく、通知が設定された第１電子貨幣の一例）と、通常電子マネー（限定ではなく、第２端末のユーザに対して関連付けられた第２電子貨幣の一例）とを区別せずに記憶する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通知が設定された第１電子貨幣と、通知が設定されていない、第２端末のユーザに対して関連付けられた第２電子貨幣とを区別せずに管理することができる。

＜第１変形例（３）＞
第１実施例において支払いを行う際に、電子マネー残高が不足するなどして、決済不可（決済ＮＧ）となる場合があり得る。この一例は、前述した（ｃ）や（ｆ）のような場合である。
このような場合に、サーバ１０が、決済処理で決済不可と判定したならば、送金先アカウントのユーザの端末２０と、通知先アカウントのユーザの端末２０とのうちの少なくともいずれか一方の端末２０に、残高不足情報や決済不可情報を送信するなどして、残高不足通知や決済不可通知を行うようにしてもよい。

＜第２実施例＞
第２実施例は、通知付き電子マネーの残高に応じて通知付き電子マネー使用通知を行う実施例である。

第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、通知付き電子マネー残高が設定金額（設定値）以下、または設定金額よりも小さい場合、通知付き電子マネー使用通知を行わない。これは、限定ではなく例として、通知付き電子マネー残高がある程度少なければ、通知付き電子マネーから高額な支払い等を行うことは困難なためである。設定金額は、限定ではなく例として、送金元アカウントのユーザ（限定ではなく、第１端末のユーザ）によって設定されるようにすることができる。
なお、これに限定されず、サーバ１０（サーバ１０のユーザ）によって設定されるようにしてもよいし、通知先アカウントのユーザ（限定ではなく、第３端末のユーザの一例）によって設定されるようにしてもよい。

＜処理＞
図２－１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図１－１３に相当する部分を示したものである。
限定ではなく例として、図１－１２のＢ１１０のステップにおいて、端末２０Ｂの制御部２１は、入出力部２３に対するユーザ入力に基づいて、通知内容を設定するようにすることができる。

Ｓ１６０において通知付き電子マネー残高が使用されたと判定したならば（Ｓ１６０：ＹＥＳ）、端末２０Ｂの制御部２１は、通知付き電子マネー残高が設定金額以下であるか否かを判定する（Ｓ２１０）。
通知付き電子マネー残高が設定金額以下であると判定したならば（Ｓ２１０：ＹＥＳ）、端末２０Ｂの制御部２１は、処理を終了する。
一方、通知付き電子マネー残高が設定金額を超えていると判定したならば（Ｓ２１０：ＮＯ），端末２０Ｂの制御部２１は、Ｓ１７０に処理を進める。

なお、Ｓ２１０において、端末２０Ｂの制御部２１が、通知付き電子マネー残高が設定金額未満であるか否かを判定するようにしてもよい。

＜第２実施例の効果＞
本実施例は、通知付き電子マネー使用通知は、通知付き電子マネー残高が設定金額以下、または設定金額よりも小さい場合、サーバ１０によって通知先アカウントのユーザの端末２０（限定ではなく、第３端末の一例）に送信されない構成を示している。
このような構成により得られる実施例の効果の一例として、通知付き電子マネー残高がある程度小さい場合に、第３端末にサーバから通知が送信されないようにすることができる。

＜第２変形例（１）＞
通知付き電子マネー使用通知を行う条件、または行わない条件は、上記の実施例で説明したものに限定されない。
限定ではなく例として、１回あたりに使用された通知付き電子マネーの金額が設定金額以下、または設定金額よりも小さい場合、通知付き電子マネー使用通知がサーバ１０によって送信されないようにしてもよい。これは、１回あたりに使用される金額が小さければ、リスクの高い通知付き電子マネーの用途ではない可能性があるためである。

また、限定ではなく例として、通知付き電子マネーが使用されるごとに毎回通知を行うようにするのではなく、設定されたタイミングで通知を行うようにしてもよい。この場合に通知を行う条件としては、限定ではなく例として、以下のようなものを例示することができる。
・設定されたタイミング（月に１回、週に１回など）
・通知付き電子マネーが全て使用された場合
・通知付き電子マネーのうち使用された金額が設定金額以上、または設定金額よりも大きい場合
・通知付き電子マネーのうち使用された金額の割合が設定割合以上、または設定割合よりも大きい場合
・通知付き電子マネーの使用回数や使用頻度が設定値以上の場合（２４時間以内に５回以上使用された場合等）、または設定値よりも大きい場合
・上記の２以上の組合せ

上記の各種の条件は、限定ではなく例として、送金元アカウントのユーザ（限定ではなく、第１端末のユーザ）によって設定されるようにすることができる。
なお、これに限定されず、サーバ１０（サーバ１０のユーザ）によって設定されるようにしてもよいし、通知先アカウントのユーザ（限定ではなく、第３端末のユーザの一例）によって設定されるようにしてもよい。

本変形例は、通知付き電子マネー使用通知は、通知付き電子マネー（限定ではなく、第１電子貨幣の一例）のうち送金先アカウントのユーザ（限定ではなく、第２端末のユーザの一例）によって使用された金額が設定金額以下、または設定された金額よりも小さい場合、サーバ１０によって送信されない構成を示している。
このような構成により得られる変形例の効果の一例として、第１電子貨幣のうち第２端末のユーザによって使用された金額がある程度小さい場合に、サーバから第３端末に通知が送信されないようにすることができる。その結果、第３端末のユーザが通知を確認する労力を削減することができる。

また、本変形例は、通知付き電子マネー使用通知は、送金元アカウントのユーザ（限定ではなく、第１端末のユーザの一例）によって設定されたタイミングで、サーバ１０によって送信される構成を示している。
このような構成により得られる変形例の効果の一例として、第１端末のユーザが任意に設定したタイミングで、サーバから第３端末に通知が送信されるようにすることができる。

＜第２変形例（２）＞
通知先アカウントのユーザの端末２０に、通知付き電子マネーの使用履歴に関する情報を表示させるなどして、通知先アカウントのユーザが、通知付き電子マネーの使用履歴を確認できるようにしてもよい。

図２－２は、本変形例においてサーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
記憶部１５には、前述したプログラムやデータの他に、限定ではなく例として、決済履歴管理データ１５７が記憶される。

図２－３は、決済履歴管理データ１５７のデータ構成の一例を示す図である。
決済履歴管理データは、通知なしの通常電子マネー残高からの支払いによる決済履歴と、通知付き電子マネー残高からの支払いによる決済履歴とを管理するためのデータであり、限定ではなく例として、決済ＩＤと、アプリケーションＩＤと、使用店舗名と、決済日時と、決済金額とが関連付けて記憶される。

決済ＩＤは、決済を固有に識別するための識別情報であり、限定ではなく例として、電子マネーによる決済が行われるごとにサーバ１０によってユニークなＩＤが設定される。

アプリケーションＩＤには、その決済（決済に関する処理）を行った端末２０（またはその端末２０のユーザ）のアプリケーションＩＤがサーバ１０によって記憶される。
使用店舗名には、その決済ＩＤの決済を要求した店舗の店舗名がサーバ１０によって記憶される。
決済日時には、その決済ＩＤの決済処理がサーバ１０によって行われた日時がサーバ１０によって記憶される。
決済金額には、その決済ＩＤの決済金額がサーバ１０によって記憶される。

なお、使用店舗名に代えて、その決済ＩＤの決済を要求した店舗の店舗ＩＤ等を記憶させてもよい。

図２－４は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｄの一例を示す図である。
アカウント管理データベース１５５Ｄに含まれる各々のアカウント管理データには、アプリケーションＩＤと、通常電子マネー残高と、通知付き電子マネー管理データとの他に、限定ではなく例として、通知付き電子マネー使用履歴データが記憶される。

本データにおいて、通知付き電子マネー管理データには、限定ではなく例として、送金管理ＩＤと、通知先ＩＤと、通知者名と、通知付き電子マネー残高とが関連付けて記憶される。

前述した通知付き電子マネー管理データとは異なり、本実施例では、送金管理ＩＤに対して、通知先ＩＤと、通知者名と、通知付き電子マネー残高とが関連付けられている。

送金管理ＩＤは、通知付き電子マネーの送金をユニークに識別するためのＩＤであり、限定ではなく例として、通知付き電子マネーの送金がサーバ１０によって実行されるごとに、サーバ１０によって異なるＩＤが設定されて記憶される。
限定ではなく例として、ユーザＢ．Ｂの同じアカウントからユーザＡ．Ａの同じアカウントに対して、通知付き電子マネーが送金されたような場合であっても、それぞれ異なるＩＤが設定される。

通知付き電子マネー使用履歴データは、通知付き電子マネーの使用履歴に関するデータであり、限定ではなく例として、決済ＩＤと、送金管理ＩＤと、使用店舗名と、使用日時と、使用金額とが関連付けて記憶される。

決済ＩＤには、決済履歴管理データ１５７に記憶された決済ＩＤのうち、通知付き電子マネーを用いて行った決済に対応する決済ＩＤが記憶される。
この決済ＩＤを記憶させておくことで、商品やサービスの返品時等においても、必要な金額をサーバ１０が特定可能となる。

送金管理ＩＤには、通知付き電子マネー管理データに記憶された送金管理ＩＤのうち、この決済ＩＤの決済で使用された通知付き電子マネー残高に対応する送金管理ＩＤが記憶される。

使用店舗名には、決済履歴管理データ１５７に記憶された使用店舗名のうち、この決済ＩＤに対応する使用店舗名が記憶される。

使用日時には、決済履歴管理データ１５７に記憶された決済日時のうち、この決済ＩＤに対応する決済日時が記憶される。

使用金額には、決済履歴管理データ１５７に記憶された決済金額のうち、この決済ＩＤの決済で使用された通知付き電子マネーの金額が記憶される。

本実施例では、サーバ１０は、前述した（ａ）～（ｆ）の方法で決済を行う。
このうち、前述した（ｂ）・（ｄ）の場合は、通知付き電子マネー残高から決済されるため、その金額が使用金額として記憶されるようにすることができる。

なお、詳細は後述するが、通知なしの通常電子マネー残高と、通知付き電子マネー残高との両方を用いて決済を行うようにすることも可能である。この場合は、それらの金額を合算した金額が、決済履歴管理データ１５７（図２－３）の決済金額に記憶される。
また、この場合、その決済金額のうちの決済に使用した通知付き電子マネーの金額が、通知付き電子マネー使用履歴データ（図２－４）の使用金額に記憶されるようにすることができる。

限定ではなく例として、図２－４の最も手前側に図示しているアカウント管理データは、前述した送金先のユーザＡ．Ａのアカウント管理データであり、通知付き電子マネー管理データにおける送金管理ＩＤ「Ｔ０１００３」は、前述した送金元のユーザＢ．Ｂからの通知付き電子マネー送金によって「２，０００円」が送金され、通知付き電子マネー残高が「２，０００円」であった。
ぞの後、通知付き電子マネーを用いて、通知付き電子マネー使用履歴データにおける決済ＩＤ「Ｐ２１０５３」、「Ｐ２９９０３」、「Ｐ３２３０６」の決済が行われ、使用金額の総額が「１，０００円＋４００円＋２００円＝１，６００円」であったため、通知付き電子マネー残高は「２，０００円－１，６００円＝４００円」となっている。

図２－５左側は、本変形例における送金元アカウントのユーザおよび通知先アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。

このおしらせ画面には、通知付き電子マネー使用情報ＮＵ２１が表示されている。
この通知付き電子マネー使用情報ＮＵ２１には、限定ではなく例として、その通知付き送金の使用履歴をユーザが確認するための「使用履歴をみる」の文字を含む「使用履歴確認」ボタンＢＴ２１が設けられている。

この「使用履歴確認」ボタンＢＴ２１がタップされると、限定ではなく例として、図２－５中央の画面が表示される。
この画面は、支払いアプリケーションにおける通知付き電子マネー使用履歴画面の一例であり、上部には、ユーザＡ．Ａのアイコン画像およびそのユーザ名（Ａ．Ａ）とともに、通知付き送金金額の合計額（この例では「２，０００円」）と、そのうちの未使用の金額（この例では「４００円」）とが表示されている。

また、その下には、限定ではなく例として、「１週間」、「１ヶ月」、「６ヶ月」といった、過去所定期間における通知付き電子マネー使用履歴を閲覧可能とするための、ユーザが選択可能な選択用情報が設けられている。この選択用情報はタブに類するものであり、ここでは便宜的に「選択用タブ」と称する。

この例では、「１週間」に対応する選択用タブがタップされたことで、その選択用タブが反転表示され、その下に、過去１週間の期間における通知付き電子マネー使用履歴が一覧表示されている。具体的には、この例では、「ＸＸ書店」での「１，０００円」の支払いと、「コンビニＹＹ」での「４００円」の支払いと、「ＺＺスーパー」での「２００円」の支払いとが表示されている。つまり、通知付き送金金額の合計額（上記の「２，０００円」）のうちの「１，６００円」が使用されたことになる。

また、その下には、具体的な通知付き電子マネーの使用状況をユーザが確認するための「使用状況を見る」の文字を含む「使用状況確認」ボタンＢＴ２２が設けられている。この「使用状況確認」ボタンがタップされると、限定ではなく例として、図２－５右側の画面が表示される。
限定ではなく例として、「使用状況確認」ボタンＢＴ２２がタップされた際に表示されていた期間に対応する通知付き電子マネー残高の推移グラフが表示される。この例では、「使用状況確認」ボタンＢＴ２２がタップされた際に図２－５中央の画面で表示されていた過去「１週間」の期間における通知付き電子マネー使用履歴に対応して、図２－５右側の画面には、過去「１週間」の期間（この例では「２０２１年４月５日から２０２１年４月１１日までの期間」）における通知付き電子マネー残高の推移グラフが表示されている。

また、推移グラフの下には、「使用履歴一覧をみる」の文字を含む「使用履歴一覧をみる」ボタンＢＴ２３が設けられており、この「使用履歴一覧をみる」ボタンＢＴ２３がタップされると、図２－５中央の画面に戻る。

本変形例では、限定ではなく例として、各種の装置が、図１－１２～図２－１に基づく処理を実行するようにすることができる。
限定ではなく例として、通知付き電子マネー送金結果情報には、通知付き電子マネー送金処理によって設定された送金管理ＩＤを含めるようにしてもよい。

この処理において、通知先アカウントのユーザの端末２０の制御部２１は、限定ではなく例として、通知付き電子マネー使用情報を記憶部２８に記憶させる。そして、通知先アカウントのユーザの端末２０の制御部２１は、ユーザ入力に基づき、記憶部２８に記憶されている通知付き電子マネー使用情報に基づいて、通知付き電子マネーの使用履歴を表示部２４に表示させるようにすることができる。

なお、これとは異なり、通知先アカウントのユーザの端末２０の制御部２１が、通知付き電子マネー使用履歴データ要求情報をサーバ１０に送信し、サーバ１０の制御部１１は、通知付き電子マネー使用履歴データを通知先アカウントのユーザの端末２０に送信するようにしてもよい。

また、この場合、限定ではなく例として、通知先アカウントのユーザの端末２０の制御部２１が、記憶部２８に記憶されている通知付き電子マネー使用情報に基づいて、推移グラフを生成するようにすることができる。
なお、これとは異なり、サーバ１０の制御部１１が、通知付き電子マネー使用履歴データ（図２－４）に基づいて推移グラフを生成して、通知先アカウントのユーザの端末２０に送信するようにしてもよい。

本変形例は、サーバ１０が、送金先アカウントのユーザ（限定ではなく、第２端末のユーザの一例）による通知付き電子マネー（限定ではなく、第１電子貨幣の一例）の使用履歴に関する情報を、通知先アカウントのユーザの端末２０（限定ではなく、第３端末の一例）に送信する構成を示している。
このような構成により得られる変形例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されることに基づき、その使用履歴に関する情報を、第３端末のユーザに知らせることができる。

＜第２変形例（３）＞
前述したように、決済履歴管理データ１５７に決済ＩＤを記憶させておくことで、商品やサービスの返品時等においても、必要な金額をサーバ１０が特定可能となる。
この場合、送金先アカウントのユーザにより使用された通知付き電子マネーの少なくとも一部を返金する場合、サーバ１０の制御部１１は、店舗ＰＯＳシステム４０から送信される決済ＩＤを決済履歴管理データ１５７から特定する。これは、決済が行われたか否かを確認するとともに、その決済金額を特定するためである。

次いで、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｄのうち、送金先アカウントのユーザのアカウント管理データに含まれる通知付き電子マネー使用履歴データを参照し、特定した決済ＩＤに対応する送金管理ＩＤを特定する。

特定した決済ＩＤに対応する送金管理ＩＤが存在しない場合は、通知付き電子マネーは決済に使用されなかったことになる。このため、通常電子マネー残高に返金金額を加算する。通常電子マネーのみを使って決済した場合は、決済履歴管理データ１５７のうちの特定した決済ＩＤに対応する決済金額が、通常電子マネー残高への返金金額となる。

一方、特定した決済ＩＤに対応する送金管理ＩＤが存在する場合は、通知付き電子マネーが決済に使用されたことになる。このため、通知付き電子マネー使用履歴データから、特定した決済ＩＤに対応する使用金額を特定し、その使用金額を、通知付き電子マネー管理データのうちの対応する送金管理ＩＤの通知付き電子マネー残高に加算する。

本変形例は、サーバ１０は、送金先アカウントのユーザにより使用された通知付き電子マネーの少なくとも一部を返金する場合、通知付き電子マネーの少なくとも一部に通知が設定された状態で、送金先アカウントのユーザに返金する制御を制御部１１によって行う構成を示している。
このような構成により得られる変形例の効果の一例として、第２端末のユーザにより使用された第１電子貨幣の少なくとも一部を返金する必要がある場合に、第１電子貨幣の少なくとも一部に通知が設定された状態で、第２端末のユーザに返金することができる。

＜第３実施例＞
第３実施例は、通知付き電子マネーの送金や、通知付き電子マネーの送金先ユーザのアカウントとの関連付けを、送金先アカウントのユーザに確認することを可能にする実施例である。

第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図３－１左側は、送金先アカウントのユーザであるユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このお知らせ画面には、お知らせ領域の向かって左側に、ユーザＢ．Ｂからの通知付き電子マネーの受け取りを確認するための通知付き電子マネー受取確認情報ＮＣ３１が表示されている。

この通知付き電子マネー受取確認情報ＮＣ３１には、限定ではなく例として、送金される金額（この例では「１，０００円」）と、受け取る側であることを示す「受取」アイコンと、送金される通知付き電子マネーを受け取って使用するとユーザＢ．Ｂに対して通知がなされることを示すイラストと、通知付き電子マネー受取確認情報ＮＣ３１のサーバ１０による送信日時と、「通知付き電子マネーが届きました（使用状況がＢ．Ｂに通知されます）」の文字と、ユーザＢ．ＢからユーザＡ．Ａへの送金であることを示すイラストと、「＞詳細を確認」ボタンとが表示されている。また、その他に、通知付き電子マネーの受け取りを拒否するための「断る」ボタンＢＴ３１と、通知付き電子マネーの受け取りを許可するための「受け取る」ボタンＢＴ３２とが表示されている。

なお、ユーザＡ．Ａは未だ通知付き電子マネーを受け取っていない状態であるため、通知付き電子マネー受取確認情報ＮＣ３１では、限定ではなく例として、「通知付き電子マネーが届きました」という表現を用いている。

「断る」ボタンＢＴ３１がタップされると、ユーザＢ．ＢからユーザＡ．Ａに対する通知付き電子マネーの送金は行われない。また、送金元アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４には、限定ではなく例として、図３－１右側のような画面が表示される。
この画面は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図であり、お知らせ領域内の向かって左側に、通知付き電子マネーの受け取りが拒否されたことを示す通知付き電子マネー受取拒否情報ＮＤ３１が表示されている。

具体的には、限定ではなく例として、この通知付き電子マネー受取拒否情報ＮＤ３１のサーバ１０による送信日時と、「Ａ．Ａへの通知付き電子マネーの送金に失敗しました」の文字と、送金しようとした金額（この例では「１，０００円」）と、「＞詳細を確認」と示された「＞詳細を確認」ボタンとが表示されている。

一方、図３－１左側の画面において「受け取る」ボタンＢＴ３２がタップされると、ユーザＢ．ＢからユーザＡ．Ａに対する通知付き電子マネーの送金が行われる。

＜処理＞
図３－２，図３－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
端末２０Ｂから通知付き電子マネー送金依頼情報を受信すると、サーバ１０の制御部１１は、通知付き電子マネー受取確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ３１０）。
この場合、通知付き電子マネー受取確認情報には、限定ではなく例として、端末２０Ａのユーザに送金される電子マネーに対して通知の設定がされていることを示す情報を含めることができる。

これを受けて、端末２０Ａの制御部２１は、受信した通知付き電子マネー受取確認情報を表示部２４に表示させる（Ａ３１０）。

その後、端末２０Ａの制御部２１は、入出力部２３に対する受取を承諾するユーザ入力がなされたこと等に基づいて、通知付き電子マネーを受け取るか否かを判定する（Ａ３２０）。受け取らないと判定したならば（Ａ３２０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了する。

一方、受け取ると判定したならば（Ａ３２０：ＹＥＳ）、端末２０Ａの制御部２１は、通知付き電子マネー受取承諾情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３３０）。

Ｓ３１０の後、サーバ１０の制御部１１は、端末２０Ａから通知付き電子マネー受取承諾情報を受信したか否かを判定し（Ｓ３２０）、受信したと判定したならば（Ｓ３２０：ＹＥＳ）、Ｓ１１０に処理を移す。

一方、受信しなかったと判定したならば（Ｓ３２０：ＮＯ）、サーバ１０の制御部１１は、通知付き電子マネー受取拒否情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ３３０）。

Ｂ１２０の後、端末２０Ｂの制御部２１は、サーバ１０から通知付き電子マネー受取拒否情報を受信したか否かを判定し（Ｂ３１０）、受信しなかったと判定したならば（Ｂ３１０：ＮＯ）、Ｂ１３０のステップを実行する。

一方、受信したと判定したならば（Ｂ３１０：ＹＥＳ）、端末２０Ｂの制御部２１は、受信した通知付き電子マネー受取拒否情報を表示部２４に表示させる（Ｂ３２０）。そして、端末２０Ｂの制御部２１は、処理を終了する。

なお、上記の処理において、サーバ１０の制御部１１が、Ｓ３１０のステップで通知付き電子マネー受取確認情報を端末２０Ａに送信するのではなく、Ｓ１２０のステップにおいて、端末２０Ａのユーザに送金される電子マネーに対して通知の設定がされていることを示す情報を通知付き電子マネー送金結果情報に含めて、端末２０Ａに送信するようにしてもよい。

また、上記の処理において、端末２０Ａの制御部２１が、Ａ３２０のステップを実行せず、Ａ３１０のステップの後、Ａ３３０のステップを実行するようにしてもよい。

＜第３実施例の効果＞
本実施例は、サーバ１０が、通知付き電子マネー受取確認情報（限定ではなく、第２端末のユーザに送金された第１電子貨幣に対して通知の設定がされていることを示す通知設定情報の一例）を、通信Ｉ／Ｆ２２によって送金先アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザに送金された第１電子貨幣に対して通知の設定がされていること、第２端末のユーザに知らせることができる。

また、この場合、サーバ１０は、通知付き電子マネー受取確認情報が送信されたことに基づき、送金先アカウントのユーザの端末２０から送信された通知付き電子マネー受取承諾情報（限定ではなく、第２端末のユーザへの送金の許可に関する許可情報の一例）を、通信Ｉ／Ｆ１４によって受信する。そして、通知付き電子マネーは、この通知付き電子マネー受取承諾情報の受信に基づいて、送金先アカウントのユーザに関連付けて記憶される構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザによる許可なく、第１電子貨幣が第２端末のユーザに関連付けて記憶されることを防止することができる。

＜第３変形例（１）＞
限定ではなく例として、悪意のある送金元アカウントのユーザが、送金先アカウントのユーザの所在地等の情報を知ろうとして、意図的に通知付き電子マネーを送金するような場合があり得る。
また、限定ではなく例として、前述した親子の例において、通知付き電子マネーを受け取った子供が、ギフティング機能の一種である投げ銭などによって、赤の他人に通知付き電子マネーを送金してしまうようなこともあり得る。

そこで、通知付き電子マネーを使用した場合に、通知先アカウントのユーザの端末２０に対して通知がなされることを、送金先アカウントのユーザによって通知付き電子マネーの少なくとも一部が使用される前に、送金先アカウントに知らせるようにすることも可能である。

図３－４は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。
図３－４左側は、送金先アカウントのユーザであるユーザＡ．Ａの端末２０Ａの表示部２４に表示されるコード支払い画面である。
ウォレットコード情報表示領域ＷＣＲ１に表示されたウォレットコード情報が店舗コードリーダ装置５０によって読み取られると、限定ではなく例として、図３－４中央に示すように、コード支払い画面のウォレットコード情報表示領域ＷＣＲ１に重畳するように、送金先アカウント（この例では、ユーザＡ．Ａのアカウント）によって通知付き電子マネーの少なくとも一部が使用されることで、通知先アカウント（この例では、ユーザＢ．Ｂのアカウント）に対して通知付き電子マネー使用通知がなされることを、送金先アカウントのユーザに知らせる情報である通知付き電子マネー使用確認情報ＮＥ３１が表示される。

具体的には、この例では、「この支払いはＢ．Ｂに通知されます よろしいですか？」の文字と、通知付き電子マネーの使用を承諾して支払いを行うための「支払う」ボタンＢＴ３３と、通知付き電子マネーの使用を拒否して支払いをやめるための「やめる」ボタンＴ３４とが表示されている。

「支払う」ボタンＢＴ３３がタップされると、サーバ１０によって決済処理が行われる。そして、送金元アカウントのユーザおよび通知先アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４には、限定ではなく例として、図３－４右側の画面が表示される。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側のユーザＢ．ＢからユーザＡ．Ａへの通知付き電子マネーの送金が完了したことを示す通知付き電子マネー送金結果情報ＮＲ２の下に、ユーザＡ．Ａによって通知付き電子マネーが使用されたことを示す通知付き電子マネー使用情報ＮＵ３が表示されている。

図３－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ｓ１２０の後、サーバ１０の制御部１１は、ウォレット支払い要求情報を端末２０Ａから受信すると、通知付き電子マネー使用確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ３４０）。この通知付き電子マネー使用確認情報には、限定ではなく例として、送金先アカウント（この例では、ユーザＡ．Ａのアカウント）によって通知付き電子マネーの少なくとも一部が使用されることで、通知先アカウント（この例では、ユーザＢ．Ｂのアカウント）に対して通知付き電子マネー使用通知がなされることをユーザＡ．Ａに知らせる（通知する）情報を含めることができる。

Ａ１２０の後、端末２０Ａの制御部２１は、通知付き電子マネー使用確認情報をサーバ１０から受信すると、入出力部２３に対して通知付き電子マネーの使用を許可する入力がなされたか否かを判定するなどして、通知付き電子マネーを使用するか否かを判定する（Ａ３４０）。使用しないと判定したならば（Ａ３４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了する。

一方、通知付き電子マネーを使用すると判定したならば（Ａ３４０：ＹＥＳ）、端末２０Ａの制御部２１は、通知付き電子マネー使用承諾情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３５０）。

Ｓ３４０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから通知付き電子マネー使用承諾情報を受信したか否かを判定する（Ｓ３５０）。受信しなかったと判定したならば（Ｓ３５０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。

一方、通知付き電子マネー使用承諾情報を受信したと判定したならば（Ｓ３５０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１３０に処理を移す。

なお、通知付き電子マネー残高を優先的に使用して支払いを行う設定とされていれば、上記のように、サーバ１０の制御部１１は、Ｓ１２０のステップの後、Ｓ３４０のステップを実行するようにすることができる。
しかし、通常電子マネー残高を優先的に使用して支払いを行う設定とされている場合、サーバ１０の制御部１１は、支払い金額が分からなければ、通常電子マネー残高ではなく通知付き電子マネー残高を使用して支払いを行うか否かを判別することができず、通知付き電子マネー使用確認情報を端末２０Ａに送信する必要があるか否かを判別することができない。

そこで、限定ではなく例として、サーバ１０の制御部１１が、Ｓ１３０のステップにおいて、ウォレットコード情報とともに通知付き電子マネー使用確認情報を端末２０Ａに送信する。そして、図１－１３のＳ１４０のステップを実行する前に、通知付き電子マネー残高を使用した決済の許否を端末２０Ａに確認するようにしてもよい。

また、限定ではなく例として、サーバ１０の制御部１１が、図１－１３のＳ１４０のステップを実行する前に、店舗ＰＯＳシステム４０から受信した決済要求情報に含まれる支払い金額に基づいて、通知付き電子マネー残高が決済に使用されるか否かを判定する。そして、通知付き電子マネー残高が決済に使用されると判定した場合に、通知付き電子マネー使用確認情報を端末２０Ａに送信して、通知付き電子マネー残高を使用した決済の許否を端末２０Ａに確認するようにしてもよい。

本変形例は、サーバ１０が、送金先アカウントのユーザにより通知付き電子マネーの少なくとも一部が使用される前に、通知付き電子マネー使用確認情報（限定ではなく、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用される前に、第３端末に対して通知されることに関する第３情報の一例）を送金先アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる変形例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用される前に、第３端末に対して通知がされることを、第２端末のユーザに知らせることができる。

＜第３変形例（２）＞
限定ではなく例として、通知先アカウントのユーザに対して通知がなされることを、送金先アカウントのユーザが嫌がることも考えられる。
そこで、送金先アカウントのユーザが通知付き電子マネーの送金を受け取らない設定を行っている場合、通知付き電子マネーが送金先アカウントに関連付けられないようにしてもよい。また、この場合、通知付き送金ができないことを送金元アカウントのユーザに知らせるようにしてもよい。

ここで、通知付き電子マネーの送金を受け取らない設定（通知付き電子マネーの受け取りを拒否する設定）として、以下のものを例示する。
（Ｓ１）一括拒否
（Ｓ２）ブロック
（Ｓ３）ブラックリスト
（Ｓ４）ホワイトリスト

（Ｓ１）一括拒否は、限定ではなく例として、全てのアカウント（または全てのユーザ）から通知付き電子マネーの送金を受け取らないように設定することとすることができる。

（Ｓ２）ブロックは、限定ではなく例として、特定のアカウント（または特定のユーザ）からの通知付き電子マネーの送金を受け取らないように設定することとすることができる。

（Ｓ３）ブラックリストは、限定ではなく例として、デフォルトでは全てのアカウントから通知付き電子マネーの送金を受け取り可能として設定しておくが、その中から特定のアカウントからの通知付き電子マネーの送金を受け取らないように設定することとすることができる。

（Ｓ４）ホワイトリストは、限定ではなく例として、デフォルトでは全てのアカウントから通知付き電子マネーの送金を受け取り不可として設定しておくが、その中から特定のアカウントからの通知付き電子マネーの送金を受け取るように設定することとすることができる。

なお、（Ｓ３）ブラックリストや（Ｓ４）ホワイトリストは、（Ｓ２）ブロックの実装方法の一種と考えることもできる。
具体的には、限定ではなく例として、ブラックリストに特定のアカウントを追加することで、（Ｓ２）ブロックを実現することができる。
逆に、限定ではなく例として、ホワイトリストから特定のアカウントを削除することで、（Ｓ２）ブロック、を実現することもできる。

また、（Ｓ１）一括拒否を（Ｓ２）ブロックの一種とし、全てのアカウントをブロックすることと考えてもよい。

図３－６は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。
図３－６左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのウォレット設定画面の一例を示す図であり、電子マネーに関する設定内容として、限定ではなく例として、電子マネーへの自動チャージを行うための「自動的にチャージ」の項目や、全てのアカウントからの通知付き電子マネーの受け取りを拒否するための「通知付き電子マネーの受け取りを拒否」の項目等が表示されている。それぞれの項目の右側には、スライドボタンが関連付けて設けられており、スライドボタンをタップ、またはスライドすることによって、その項目を「ＯＮ」とすることが可能に構成されている。この例では、「通知付き電子マネーの受け取りを拒否」の項目が「ＯＮ」とされた状態が示されている。これは、前述した（Ｓ１）一括拒否、の画面図の一例である。

なお、上記の「通知付き電子マネーの受け取りを拒否」の項目を、この例ではユーザＢ．Ｂのアカウントからの通知付き電子マネーの受け取りの拒否と置き換えてもよい。この場合は、前述した（Ｓ２）ブロック、となる。
また、ユーザＢ．Ｂのアカウントをブラックリストに追加したり、ユーザＢ．Ｂのアカウントをホワイトリストから削除することを可能にする画面図を構成してもよい。この場合は、前述した（Ｓ３）ブラックリストや（Ｓ４）ホワイトリスト、となる。

この状態で画面下部の「設定」ボタンＢＴ３５がタップされると、限定ではなく例として、図３－６中央の画面が表示される。
この画面は、送金元アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される送金画面の一例を示す図であり、図１－９右側と同様の画面である。この画面において「送金」ボタンＢＴ２がタップされると、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面には、限定ではなく例として、図３－６右側に示すような表示がなされる。

具体的には、おしらせ領域内の向かって左側に、図３－１左側の画面図における（Ｓ１）一括拒否の設定に基づいて、ユーザＡ．Ａによって通知付き電子マネーの受け取りが拒絶されたことを示す通知付き電子マネー受取拒絶情報ＮＦ３１が表示されている。
この通知付き電子マネー受取拒絶情報ＮＦ３１には、限定ではなく例として、この通知付き電子マネー受取拒絶情報のサーバ１０による送信日時と、「Ａ．Ａへの通知付き電子マネーの送金に失敗しました」の文字と、「（Ａ．Ａのウォレット設定で、通知付き電子マネーの受け取りが拒否されています）」の文字と、送金しようとした金額（この例では「１，０００円」）と、「＞詳細を確認」ボタンとが表示されている。

なお、前述した通知付き電子マネー受取拒否情報と区別するため、本変形例では、便宜的に「通知付き電子マネー拒絶情報」と称している。
その一方で、支払いアプリケーションを利用するユーザにとっては用語が統一されている方が分かり易い可能性があるため、表示画面例では「拒否」の用語を用いている。

図３－７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
最初に、端末２０Ａの制御部２１は、入出力部２３に対する通知付き電子マネーの受取を拒絶するユーザ入力に基づいて、通知付き電子マネー受取拒絶設定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３６０）。

これを受けて、サーバ１０の制御部１１は、通知付き電子マネー受取拒絶設定処理を行う（Ｓ３６０）。この場合、制御部１１は、限定ではなく例として、送金元アカウント（この例ではユーザＢ．Ｂのアカウント）をブロックする設定を行うようにすることができる。サーバ１０は、ブロックする送金元アカウントについては、送金先アカウントに対して、通知付き電子マネーの送金を行わないようにすることができる。

その後、サーバ１０の制御部１１は、送金先アカウントが通知付き電子マネーの受取の拒絶を設定済みであるか否かを判定し（Ｓ３７０）、設定済みであると判定したならば（Ｓ３７０：ＹＥＳ）、通知付き電子マネー受取拒絶情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ３８０）。そして、サーバ１０の制御部１１は、Ｓ１３０に処理を移す。
一方、設定済みではないと判定したならば（Ｓ３７０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１１０に処理を移す。

Ｂ１２０の後、端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から通知付き電子マネー受取拒絶情報を受信したか否かを判定し（Ｂ３１０）、受信したと判定したならば（Ｂ３１０：ＹＥＳ）、この通知付き電子マネー受取拒絶情報を表示部２４に表示させる（Ｂ３２０）。そして、端末２０Ｂの制御部２１は、図１－１３のＢ１４０に処理を移す。
一方、受信しなかったと判定したならば（Ｂ３１０；ＮＯ）、端末２０Ｂの制御部２１は、Ｂ１３０に処理を移す。

Ａ３６０の後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から通知付き電子マネー送金結果情報を受信したか否かを判定し（Ａ３７０）、受信したと判定したならば（Ａ３７０：ＹＥＳ）、Ａ１１０に処理を移す。
一方、受信しなかったと判定したならば（Ａ３７０：ＮＯ）、端末２０Ａの制御部２１は、Ａ１２０に処理を進める。

本変形例は、サーバ１０が、送金先アカウントのユーザの端末２０からの通知付き電子マネー受取拒絶設定情報の受信に基づき、通知付き電子マネー受取拒絶設定処理を行った場合（限定ではなく、第２端末のユーザが、通知が設定されている送金を受け取らない設定を行っている場合の一例）、通知付き電子マネー送金処理（限定ではなく、第１電子貨幣を第２端末のユーザに関連付けることの一例）を行わず、通知付き電子マネー受取拒絶情報（限定ではなく、第２端末のユーザに送金ができないことを示す送金不可情報の一例）を送金元アカウントのユーザの端末２０（限定ではなく、第１端末の一例）に送信する構成を示している。
このような構成により得られる変形例の効果の一例として、第２端末のユーザが、通知が設定されている送金を受け取らない設定を行っている場合、第１電子貨幣を第２端末のユーザに関連付けられないようにすることができるとともに、第１端末のユーザに送金ができないことを知らせることができる。

また、この場合、送金先アカウントのユーザが、通知が設定されている送金を受け取らない設定は、送金元アカウントのユーザをブロックする設定を含むようにすることができる。
このような構成により得られる変形例の効果の一例として、第２端末のユーザが、通知が設定されている送金を受け取りたくないような場合、第１端末のユーザがブロックされるようにして、第１端末のユーザからの通知が設定されている送金を受け取らずに済むようにすることができる。

また、この場合、送金先アカウントのユーザが、通知が設定されている送金を受け取らない設定は、全てのアカウントのユーザをブロックする設定を含むようにすることができる。
このような構成により得られる変形例の効果の一例として、第２端末のユーザが、通知が設定されている送金を受け取りたくないような場合、全てのユーザがブロックされるようにして、第１端末のユーザからの通知が設定されている送金を受け取らずに済むようにすることができる。

＜第４実施例＞
第４実施例は、通知付き電子マネーと、通知が設定されていない、送金先アカウントのユーザに対して関連付けられた電子マネーとを区別する実施例である。

第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
図４－１は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｅのデータ構成例を示す図である。
このアカウント管理データベース１５５Ｅの各々のアカウント管理データにおいて、通知付き電子マネー管理データには、限定ではなく例として、送金管理ＩＤと、送金元ＩＤと、通知先ＩＤと、通知者名と、通知付き電子マネー残高とが関連付けて記憶される。

前述したアカウント管理データとは異なり、送金元ＩＤが追加して記憶されている。これにより、サーバ１０側で、送金元アカウントと、通知先アカウントとを区別して管理することが可能となる。

＜表示画面＞
図４－２，図４－３は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。
図４－２左側には、端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示しており、ユーザＢ．ＢからユーザＡ．Ａに対して送金された通知付き電子マネーを受け取ったことを示す通知付き電子マネー送金結果情報ＮＲ４１が表示されている。

この通知付き電子マネー送金結果情報ＮＲ４１には、限定ではなく例として、送金された金額（受け取った金額）と、「受取」アイコンと、受け取った通知付き電子マネーを使用するとユーザＢ．Ｂに対して通知がなされることを示すイラストと、この情報のサーバ１０による送信日時と、「通知付き電子マネーを受け取りました（使用状況がＢ．Ｂに通知されます）」の文字と、ユーザＢ．ＢからユーザＡ．Ａへの送金であることを示すイラストと、「＞詳細を確認」ボタンとが表示されている。

なお、ユーザＡ．Ａは、既に通知付き電子マネーを受け取った状態であるため、図３－１左側に示した通知付き電子マネー受取確認情報ＮＣ３１とは異なり、通知付き電子マネー送金結果情報ＮＲ４１では、限定ではなく例として、「通知付き電子マネーを受け取りました」という表現を用いている。

図４－２中央には、その後に、支払いアプリケーションのメインメニュー画面が表示された状態が示されている。画面上部の残高表示領域ＢＲ２には、「残高」の文字が表示され、その下に、通知付き電子マネー残高として、ユーザＢ．ＢからユーザＡ．Ａに対して送金された「１，０００円」の通知付き電子マネーに対応する残高が、「通知付き」の文字およびユーザＢ．Ｂに対して通知がなされることを示すイラストとともに表示されている。
また、その下には、通常電子マネー残高が、「通知なし」の文字およびチャージボタンＣＢＴとともに表示されている。

この画面において「コード支払い」アイコンＩＣ２がタップされると、限定ではなく例として、図４－２右側に示すような支払いアプリケーションのコード支払い画面が表示される。
このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１の残高に関する情報が表示される領域に、通知付き電子マネー残高と、通常電子マネー残高とのいずれの残高から支払いを行うかを選択するための情報が表示されている。

具体的には、「通知付き電子マネー残高」から支払いを行うための「通知付き」の文字と、通知付き電子マネー残高（この例では「１，０００円」）と、その残高から支払いが行われるとユーザＢ．Ｂに対して通知がされることを示すイラストとが表示されている。
また、その下には、「通常電子マネー残高」から支払いを行うための「通知なし」の文字と、通常電子マネー残高（この例では「５００円」）と、電子マネーを通常電子マネー残高にチャージするためのチャージボタンＣＢＴとが表示されている。

「通知付き」の文字の左と、「通知なし」の文字の左とには、それぞれラジオボタンが設けられており、通知付き電子マネー残高と、通常電子マネー残高とのいずれの残高から支払いを行うかを、対応するラジオボタンに対するタップによって選択可能に構成されている。この例では、通知付き電子マネーが選択された状態が示されている。この状態で支払いが行われると、限定ではなく例として、図４－３左側に示すような決済結果情報が表示される。

この場合、端末２０Ｂの表示部２４の支払いアプリケーションのおしらせ画面には、限定ではなく例として、図４－３右側に示すような表示がなされる。
具体的には、限定ではなく例として、送金した金額（この例では「１，０００円」）と、「送金」アイコンと、送金した通知付き電子マネーが使用されることでユーザＢ．Ｂに対して通知がなされることを示すイラストと、通知付き電子マネー送金結果情報のサーバ１０による送信日時と、「通知付き電子マネーを送金しました（使用状況が通知されます）」の文字と、ユーザＢ．ＢからユーザＡ．Ａへの送金であることを示すイラストと、「＞詳細を確認」ボタンとを含む通知付き電子マネー送金結果情報ＮＲ４２の下に、通知付き電子マネー使用情報ＮＵ３が表示されている。

＜処理＞
本実施例における処理において、限定ではなく上記の画面図の例では、限定ではなく例として、図１－１２のＳ１２０のステップにおいて、サーバ１０の制御部１１が、アカウント管理データベース１５５ＥのうちのユーザＡ．Ａのアカウントのアカウント管理データに含まれる通知付き電子マネー管理データのうちの送金管理ＩＤを、送金結果情報とともに端末２０Ａに送信するようにすることができる。このようにすることで、端末２０Ａにおいて送金管理ＩＤの指定が可能となり、限定ではなく例として図４－２右側の画面のように、ユーザＢ．Ｂのアカウントを送金元ＩＤとし、同じくユーザＢ．Ｂのアカウントを通知先ＩＤとする通知付き電子マネー残高をユーザが選択することが可能となる。

また、支払いに使用する電子マネー残高がユーザによって選択された後、図１－１２のＡ１２０のステップまたはその前後において、端末２０Ａの制御部２１は、選択された通知付き電子マネー残高に対応する送金管理ＩＤをサーバ１０に送信するようにすることができる。このようにすることで、サーバ１０は、ユーザによって選択された通知付き電子マネー残高を特定可能となる。

＜第４実施例の効果＞
本実施例は、サーバ１０が、通知付き電子マネー（限定ではなく、通知が設定された第１電子貨幣の一例）と、通常電子マネー（限定ではなく、第２端末のユーザに対して関連付けられた第２電子貨幣の一例）とを区別して記憶する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、通知が設定された第１電子貨幣と、通知が設定されていない、第２端末のユーザに対して関連付けられた第２電子貨幣とを区別して管理することができ、ユーザの利便性を向上させることができる。

＜第４変形例（１）＞
図２－４のアカウント管理データでは、前述したように、サーバ１０側で、送金元アカウントと、通知先アカウントとを区別して管理することが可能となる。
これにより、送金元アカウントのユーザは、限定ではなく例として、自己のアカウントとは異なるアカウントを通知先アカウントとする設定を行うことができる。この場合、一人のユーザが１つのアカウントしか所有することができない場合、通知先アカウントのユーザは、送金元アカウントのユーザとは異なるユーザとなる。その結果、送金元アカウントのユーザの端末２０とは異なる端末２０（＝通知先アカウントのユーザの端末２０）に、通知付き電子マネー使用通知が行われるように設定することができる。

限定ではなく前述した親子の例において、母親のアカウントを送金元アカウントとする。この場合、母親の端末２０が第１端末となる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末２０が第２端末となる。
また、限定ではなく例として、父親のアカウントを通知先アカウントとして設定する。この場合、父親の端末２０が第３端末となる。
この場合、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、父親のアカウントに対して通知がいくようにすることができる。

図４－４，図４－５は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。
図４－４左側は、端末２０Ｂの表示部２４に表示される支払いアプリケーションの送金画面であり、画面下部の送金先アカウントのユーザを設定する領域には、「使用通知を受け取る」と示された、自分に対して通知付き電子マネー使用通知が行われるように設定するためのスライドボタンと、「他のユーザに使用通知する」と示された、他のユーザに対して通知付き電子マネー使用通知が行われるように設定するためのスライドボタンとが設けられている。この例では、「他のユーザに使用通知する」のスライドボタンが「ＯＮ」とされた状態が示されている。

その下には、通知先アカウントを設定するための「通知先を設定」ボタンＢＴ３６が設けられている。また、通知先アカウントが未だ設定されていない状態であるため、画面下部の「送金」ボタンＢＴ２はグレーアウト状態で表示されており、タップしても送金が行われないようになっている。

この状態で「通知先を設定」ボタンＢＴ３６がタップされると、限定ではなく例として、図４－４中央の表示がなされる。
この画面は、図４－４左側と同様に送金画面であるが、画面上部に、「通知先を設定してください」の文字が表示され、その下に、通知先アカウント（そのユーザ）を電話番号で検索するための検索ボックスが設けられている。
また、その下には、過去に通知先として設定したことがある通知先アカウント（そのユーザ）が履歴として表示されており、この例では、ユーザＣ．Ｃのアイコン画像およびそのユーザ名が表示されている。その横には、チェックボックスが関連付けて設けられており、チェックを「ＯＮ」とすることで、このユーザを通知先として設定することが可能に構成されている。この例では、ユーザＣ．Ｃのチェックが「ＯＮ」とされた状態が示されている。

この状態で、画面下部の「設定」ボタンＢＴ３７がタップされると、限定ではなく例として、図４－４右側の表示がなされる。
この画面は、図４－４左側の画面に対応する画面であるが、図４－４中央の画面で通知先アカウントが設定されたことにより、「通知先」の文字とともに、図４－４中央の画面で通知先に設定されたユーザＣ．Ｃのアイコン画像およびそのユーザ名が表示されている。

また、通知先アカウントが設定されたことに伴い、「送金」ボタンＢＴ２のグレーアウト状態が解除されている。この状態で「送金」ボタンＢＴ２がタップされると、サーバ１０によって通知付き電子マネー送金処理が実行され、ユーザＢ．ＢからユーザＡ．Ａに対して、通知付き電子マネーが送金される。

図４－５左側は、この場合に送金先アカウントのユーザであるユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面の一例を示す図である。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側に、通知付き電子マネー送金結果情報ＮＲ４３が表示されている。

この通知付き電子マネー送金結果情報ＮＲ４３には、限定ではなく例として、送金された金額（受け取った金額）と、「受取」アイコンと、受け取った通知付き電子マネーを使用するとユーザＣ．Ｃに対して通知がなされることを示すイラストと、この情報のサーバ１０による送信日時と、「通知付き電子マネーを受け取りました（使用状況がＣ．Ｃに通知されます）」の文字と、ユーザＢ．ＢからユーザＡ．Ａへの送金であることを示すイラストと、「＞詳細を確認」ボタンとが表示されている。

その後、ユーザＡ．Ａによって通知付き電子マネーが使用されると、限定ではなく例として、図４－５中央に示すような支払いアプリケーションの決済結果画面が、端末２０Ａの表示部２４に表示される。

この場合、通知先として設定されたユーザＣ．Ｃの端末２０Ｃに対して、通知付き電子マネー使用情報が送信される。その結果、端末２０Ｃの表示部２４には、限定ではなく例として、図４－５右側に示すような表示がなされる。
この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側に、通知付き電子マネー使用情報ＮＵ４３が表示されている。具体的には、ユーザＢ．ＢからユーザＡ．Ａに送金された通知付き電子マネーがユーザＡ．Ａによって使用されたことを示す情報が表示されている。

本変形例は、通知付き電子マネー通知設定は、送金元アカウントのユーザの端末２０とは異なる端末２０に通知を行うことに関する設定を含む構成を示している。
このような構成により得られる変形例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことを、第１端末とは異なる第３端末のユーザに知らせることができる。

＜第４変形例（２）＞
第４実施例では、図４－２右側の画面に示したように、一人のユーザから送金された通知付き電子マネーと、通常電子マネーとのいずれかを選択して支払いを行う例を示したが、これに限定されない。
２以上のユーザから送金された各々の通知付き電子マネーと、通常電子マネーとから、いずれかの電子マネーを選択することができるようにしてもよい。

図４－６，図４－７は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。
図４－６左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側には、２つの通知付き電子マネー送金結果情報が表示されている。

時刻が古い方の通知付き電子マネー送金結果情報ＮＲ４５は、ユーザＢ．ＢからユーザＡ．Ａに対して送金された「１，０００円」の通知付き電子マネーの送金結果情報であり、通知先として送金元アカウントのユーザであるユーザＢ．Ｂが設定されたものである。
時刻が新しい方の通知付き電子マネー送金結果情報ＮＲ４６は、ユーザＣ．ＣからユーザＡ．Ａに対して送金された「２，０００円」の通知付き電子マネーの送金結果情報であり、通知先として送金元アカウントのユーザであるユーザＣ．Ｃが設定されたものである。

図４－６右側は、その後に、支払いアプリケーションのメインメニュー画面が表示された状態が示されている。画面上部の残高表示領域ＢＲ２には、「残高」の文字が表示され、その下に、通知付き電子マネー残高として、２つの通知付き電子マネー残高が表示されている。
具体的には、ユーザＢ．ＢからユーザＡ．Ａに対して送金された「１，０００円」の通知付き電子マネーに対応する残高が、「通知付き」の文字およびユーザＢ．Ｂに対して通知がなされることを示すイラストとともに表示されている。同様に、ユーザＣ．ＣからユーザＡ．Ａに対して送金された「２，０００円」の通知付き電子マネーに対応する残高が、「通知付き」の文字およびユーザＣ．Ｃに対して通知がなされることを示すイラストとともに表示されている。
また、その下には、通常電子マネー残高（この例では「５００円」）と、チャージボタンＣＢＴとが表示されている。

この画面において「コード支払い」アイコンＩＣ２がタップされると、限定ではなく例として、図４－７左側に示すような支払いアプリケーションのコード支払い画面が表示される。
このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１の残高に関する情報が表示される領域に、ユーザＢ．Ｂから送金された通知付き電子マネーの残高と、ユーザＣ．Ｃから送金された通知付き電子マネーの残高と、通常電子マネー残高とのいずれの残高から支払いを行うかを選択するための情報が表示されている。

具体的には、ユーザＢ．Ｂから送金された通知付き電子マネーの残高から支払いを行うための「通知付き」の文字と、通知付き電子マネー残高（この例では「１，０００円」）と、その残高から支払いが行われるとユーザＢ．Ｂに対して通知がされることを示すイラストとが表示されている。
同様に、ユーザＣ．Ｃから送金された通知付き電子マネーの残高から支払いを行うための「通知付き」の文字と、通知付き電子マネー残高（この例では「２，０００円」）と、その残高から支払いが行われるとユーザＣ．Ｃに対して通知がされることを示すイラストとが表示されている。
また、その下には、「通常電子マネー残高」から支払いを行うための「通知なし」の文字と、通常電子マネー残高（この例では「５００円」）と、電子マネーを通常電子マネー残高にチャージするためのチャージボタンＣＢＴとが表示されている。

それぞれの横にはラジオボタンが設けられており、対応するラジオボタンに対する操作に基づいて、対応する残高を選択することが可能に構成されている。この例では、ユーザＣ．Ｃから送金された通知付き電子マネーの残高が選択された状態が示されている。この状態で支払いが行われると、限定ではなく例として、図４－７中央に示すような決済結果情報が表示される。

図４－７右側は、この場合に通知先アカウントのユーザであるユーザＣ．Ｃの端末２０Ｃの表示部２４に表示されるおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、通知付き電子マネー送金結果情報ＮＲ４８が表示されている。この通知付き電子マネー送金結果情報ＮＲ４８には、限定ではなく例として、送金金額（この例では「２，０００円」）と、送金日時と、通知付き電子マネーの送金元であることを示す「送金」アイコンと、送金元と送金先とをイラスト化した情報と、「＞詳細を確認」ボタンとが含まれる。

また、ユーザＡ．Ａに送金した通知付き電子マネーが使用されたことに基づき、通知付き電子マネー送金結果情報ＮＲ４８の下には、通知付き電子マネー使用情報ＮＵ４８が表示されている。

＜第４変形例（３）＞
上記の実施例において、通知先アカウントとして、２以上のアカウントを設定可能としてもよい。
限定ではなく前述した親子の例において、母親のアカウントを送金元アカウントとする。この場合、母親の端末２０が第１端末となる。
また、限定ではなく例として、子供のアカウントを送金先アカウントとする。この場合、子供の端末２０が第２端末となる。
また、限定ではなく例として、母親のアカウントと父親のアカウントとの２つのアカウントを通知先アカウントとして設定する。この場合、母親の端末２０と父親の端末２０との２つの端末２０が第３端末となる。
この場合、子供が自身のアカウントによって、母親から送金された通知付き電子マネーを買い物等の支払いで使用すると、母親のアカウントと父親のアカウントとのそれぞれに対して通知がいくようにすることができる。

＜第４変形例（４）＞
第４実施例において、コード支払い等によって支払いが行われようとしているタイミングで、通知付き電子マネーが使用されようとしていることを示す情報（以下、「通知付き電子マネー使用企図情報」と称する。）が、通知先アカウントのユーザの端末２０に送信されるようにするなどして、通知付き電子マネーが使用されようとしていることを通知先アカウントに通知するようにしてもよい。

具体的には、限定ではなく例として、図４－２右側のコード支払い画面において、ウォレットコード情報表示領域ＷＣＲ１に表示された通知付き電子マネー残高に関連付けられたラジオボタンが「ＯＮ」とされると、端末２０Ａの制御部２１は、通知付き電子マネー残高が選択されたことを示す情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。これを受けて、サーバ１０の制御部１１は、通知付き電子マネー使用企図情報を、通信Ｉ／Ｆ１４によって、通知先アカウントのユーザの端末２０に送信する。

＜第４変形例（５）＞
前述した各種の実施例では、送金元アカウントによって通知付き電子マネー送金設定処理を行うこととしたが、これに限定されない。
第４実施例で説明したように、送金元アカウントと通知先アカウントとを異ならせることが可能である。

限定ではなく例として、一人のユーザが複数のアカウントを所有可能とする場合に、このユーザの第１のアカウントを送金元アカウントとし、このユーザの第２のアカウントを通知先アカウントとする。そして、このユーザの第２のアカウント（通知先アカウント）によって通知付き電子マネー送金設定を行うようにしてもよいし、しなくてもよい。この場合は、このユーザの端末２０で、通知付き電子マネー送金設定処理を行うようにすることができる。

また、限定ではなく例として、一人のユーザが１つのアカウントしか所有することができない場合、通知先アカウントのユーザは、送金元アカウントのユーザとは異なるユーザとすることができる。この場合も、その異なるユーザのアカウント（通知先アカウント）によって通知付き電子マネー送金設定を行うようにしてもよいし、しなくてもよい。この場合は、この異なるユーザの端末２０で、通知付き電子マネー送金設定処理を行うようにすることができる。

＜第５実施例＞
第５実施例は、通知付き電子マネーの少なくとも一部を銀行口座等へ出金することに関する実施例である。銀行口座等へ出金された通知付き電子マネーは、現金として引き出しが可能となる。

第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図５－１，図５－２は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。
図５－１左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面の一例を示す図であり、残高表示領域ＢＲ２には、ユーザＢ．Ｂを通知先アカウントのユーザとする通知付き電子マネー残高と、通常電子マネー残高と、チャージボタンＣＢＴとが表示されている。

この例では、その下に表示される複数の機能アイコンのうちの「出金」アイコンＩＣ３がタップされた状態が示されている。すると、限定ではなく例として、図５－１中央の画面が表示される。

この画面は、支払いアプリケーションの出金画面であり、「出金先を指定してください」の文字とともに、ユーザＡ．Ａが登録済みの銀行口座（この例では、「ＬＬ銀行 普通 ＸＸＸＸＸＸ」が表示されている。銀行口座の横には、ラジオボタンが設けられており、ラジオボタンを「ＯＮ」とすることで、その銀行口座を出金先として指定することが可能に構成されている。この例では、「ＬＬ銀行 普通 ＸＸＸＸＸＸ」のラジオボタンが「ＯＮ」とされた状態が示されている。

また、その下には、「出金元残高を指定してください」の文字とともに、通知付き電子マネー残高に関する情報と、通常電子マネー残高に関する情報とが表示されている。「通知付き」の横に表示されたラジオボタンを「ＯＮ」とすることで、通知付き電子マネー残高を出金元残高として指定し、「通知なし」の横に表示されたラジオボタンを「ＯＮ」とすることで、通常電子マネー残高を出金元残高として指定することが可能に構成されている。この例では、ユーザＢ．Ｂに対して通知が行われるように設定された残額「１，０００円」の通知付き電子マネー残高のラジオボタンが「ＯＮ」とされた状態が示されている。

この状態で、画面下部の「決定」ボタンＢＴ５１がタップされると、出金先と、出金元残高とが決定される。そして、限定ではなく例として、図５－１右側の画面が表示される。

この画面は、支払いアプリケーションの送金画面であり、この例では、上記のようにして決定された通知付き電子マネー残高のうちの全ての金額である「１，０００円」が入力された状態が示されている。この状態で、画面下部の「出金」ボタンＢＴ５２がタップされると、サーバ１０によって出金処理が行われる。その結果、端末２０Ａの表示部２４には、限定ではなく例として、図５－２左側のような表示がなされる。

この画面は、支払いアプリケーションのおしらせ画面であり、おしらせ領域内の向かって左側の通知付き電子マネー送金結果情報ＮＲ４１の下に、出金結果を示す出金結果情報ＷＲ５１が表示されている。具体的には、「金額」の文字とともに、出金金額（この例では「１，０００円」が表示され、その横に、出金であることを示す「出金」アイコンが表示されている。また、その下には、出金日時と、出金先と、「＞詳細を確認」ボタンとが表示されている。

図５－２右側は、この場合に通知先アカウントのユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側の通知付き電子マネー送金結果情報ＮＲ５１の下に、ユーザＡ．Ａによって通知付き電子マネーが出金されたことを示す通知付き電子マネー出金情報ＮＷ５１が表示されている。具体的には、出金日時とともに、「Ａ．Ａに送金した電子マネーが出金されました。」の文字が表示され、その下に、出金金額（この例では「１，０００円」）と、「＞詳細を確認」ボタンとが表示されている。

＜処理＞
本実施例における処理では、図１－１２，図１－１３等の前述した各種のフローチャートの処理において、端末２０Ａの制御部２１は、限定ではなく例としてＡ１４０のステップの後、入出力部２３に対して出金を要求するユーザ入力がなされたか否かを判定する。そして、なされたと判定したならば、限定ではなく例として、アプリケーションＩＤと、出金先と、出金元残高と、出金依頼金額とを含む出金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。

サーバ１０の制御部１１は、限定ではなく例としてＳ１７０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから出金依頼情報を受信したか否かを判定する。そして、受信したと判定したならば、出金処理を行う。具体的には、受信した出金依頼情報に含まれるアプリケーションＩＤのアカウント管理データにおいて出金元残高から出金依頼金額を減算する。そして、電子マネー振替を行って、出金先の金融機関のサーバ（金融機関のサーバ）に対して出金依頼金額を送金する。

その後、サーバ１０の制御部１１は、出金完了情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する。
また、サーバ１０の制御部１１は、出金元残高が通知付き電子マネー残高であった場合、通知付き電子マネー出金情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する。

＜第５実施例の効果＞
本実施例は、サーバ１０が、送金先アカウントのユーザにより通知付き電子マネーの少なくとも一部が出金された場合、通知付き電子マネー出金情報を通知先アカウントのユーザの端末２０に通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が出金された場合、それに関する内容を、第３端末のユーザに知らせることができる。

通知付き電子マネーを出金することを可能にすると、通知に関する設定が解除されると考えることもでき、その結果、出金されても通知先アカウントに通知がいかなくなってしまうと考えることもできる。そして、その結果として、送金先アカウントのユーザが自由に使用することを許容することになり得る。
しかし、本実施例のように、通知付き電子マネーが出金された場合に、通知先アカウントに通知がいくようにすることで、上記のような事態を防止できる。

＜第５変形例（１）＞
上記の問題に鑑み、第５実施例とは異なる手法の１つとして、通知付き電子マネーを出金することを不可とすることも可能である。

図５－３は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図５－３左側，図５－３中央の画面は、図５－１左側，図５－１中央の画面とそれぞれ同様である。
本変形例において図５－３中央の画面において「決定」ボタンＢＴ５１がタップされると、限定ではなく例として、図５－３右側の表示がなされる。

この画面は支払いアプリケーションの送金画面であるが、図５－１右側とは異なる表示となっている。具体的には、通知付き電子マネー出金不可情報として、「この残高は出金できません」の文字とともに、図５－３中央の画面でユーザＡ．Ａによって指定された出金元残高に関する情報が表示されている。

本変形例における処理では、図１－１２，図１－１３等の前述した各種のフローチャートの処理において、端末２０Ａの制御部２１は、限定ではなく例としてＡ１４０のステップの後、入出力部２３に対して出金を要求するユーザ入力がなされたか否かを判定する。そして、なされたと判定したならば、限定ではなく例として、アプリケーションＩＤと、出金先と、出金元残高と、出金依頼金額とを含む出金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。

サーバ１０の制御部１１は、限定ではなく例としてＳ１７０のステップの後、通信Ｉ／Ｆ１４によって端末２０Ａから出金依頼情報を受信したか否かを判定する。そして、受信したと判定したならば、受信した出金依頼情報に含まれる出金元残高が通知付き電子マネー残高であるか否かを判定する。そして、通知付き電子マネー残高であると判定したならば、通知付き電子マネー出金不可情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する。

なお、サーバ１０の制御部１１は、端末２０Ａに加えて送金元アカウントのユーザの端末２０Ｂに通知付き電子マネー出金不可情報を送信するようにしてもよい。

また、サーバ１０の制御部１１は、通知付き電子マネー残高の出金依頼情報を受信すると、送金元アカウントのユーザの端末２０Ｂに出金を承諾するか否かの問い合わせ情報を送信するようにしてもよい。この場合、限定ではなく例として、端末２０Ｂの入出力部２３に対する入力（ユーザ操作等）に基づいて、送金元アカウントのユーザが出金に承諾すると、通知付き電子マネー残高の出金処理が実行される。

本変形例は、サーバ１０が、送金先アカウントのユーザの端末２０により通知付き電子マネーの少なくとも一部を出金するための出金依頼情報を受信した場合、通知付き電子マネー出金不可情報（限定ではなく、出金不可情報の一例）を送金先アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末により第１電子貨幣の少なくとも一部を出金することに関する情報を通信部によって受信した場合、出金が不可であることを第２端末のユーザに知らせることができる。

＜第５変形例（２）＞
上記の実施例では、銀行口座等への出金が行われると通知先アカウントに通知が送信されることとしたが、これに限定されない。限定ではなく例として、支払いアプリケーションに現金自動預け払い機（ＡＴＭ）等からの現金出金機能が搭載されている場合、通知付き電子マネー残高がＡＴＭを用いて出金されると、通知先アカウントのユーザの端末２０Ｂに通知が送信されるようにしてもよい。

なお、第５変形例（１）と同様に、サーバ１０の制御部１１は、送金先アカウントの端末２０ＡがＡＴＭを用いて出金を試みると、端末２０Ａに通知付き電子マネー出金不可情報を送信するようにしてもよい。

＜第６実施例＞
第６実施例は、支払いアプリケーションに代えて、またはこれに加えて、メッセージングアプリケーションを利用する実施例である。

第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

メッセージングアプリケーションでは、限定ではなく例として、友だちとしてサーバ１０に登録しているアカウント同士で、一対一トークを行うことができるように構成することができる。また、限定ではなく例として、２以上のアカウントを含むグループを構成し、グループに含まれるアカウント同士で、グループトークを行うことができるように構成することができる。

＜表示画面＞
図６－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。
図６－１左側は、メッセージングアプリケーション（限定ではなく、チャットアプリケーションの一例）のトークルーム（限定ではなく、チャットルームの一例）の画面であり、画面最上部中央には、メッセージングアプリケーションの名称として「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の文字が表示されている。また、画面最上部右方には、この端末２０Ａのユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＡ．Ａ）が表示されている。

また、その下には、メッセージングアプリケーションにおけるトークルーム名を示すトークルーム名表示領域が構成されており、この例では、トークルーム名がユーザＢ．Ｂとの一対一トークルームであることを示す「Ｂ．Ｂ」の文字と、前の画面に戻るための「＜」のボタンとを含む「＜Ｂ．Ｂ」が表示されている。

その下には、トーク領域が構成されている。トーク領域では、限定ではなく例として、画面向かって右側に自分が送信元のコンテンツが表示され、画面向かって左側に相手が送信元のコンテンツが表示されるように構成され、時刻が古い順に下方向に時系列に表示されるように構成されている。また、限定ではなく例として、自分が送信元のコンテンツは、トーク領域の右端から吹き出しで表示され、相手が送信元のコンテンツは、トーク領域の左端にそのユーザのアイコン画像およびユーザ名と関連付けて吹き出しで表示されるように構成されている。

この例では、トーク領域内の向かって左側に、ユーザＢ．Ｂを送信元とする参考書の購入を促すテキストコンテンツＴＣ６１と、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツＮＲＣ６１とが表示されている。

通知付き電子マネー送金結果コンテンツＮＲＣ６１は、限定ではなく例として、ユーザＢ．Ｂから送金された「１，０００円」分の通知付き電子マネーを受け取ったことを示すコンテンツであり、通知先アカウントとしてユーザＢ．Ｂが設定されていることが示されている。
また、トーク領域内の向かって右側には、ユーザＡ．Ａを送信元とするお礼を述べるテキストコンテンツＴＣ６２が表示されている。

この状態で、不図示のユーザ入力に基づいて支払いアプリケーションによるコード支払いを行うための機能が呼び出され、前述したコード支払いによって、ユーザＢ．Ｂから送金された通知付き電子マネーを用いた決済処理が実行された結果、限定ではなく例として、図６－１中央の画面が表示される。この画面例では、図６－１左側のトークルーム画面においてトーク領域の一部に重畳するように、決済結果情報を表示する決済結果情報表示領域ＰＷＲが、トークルーム画面の下部からせり上がって表示されている。

図６－１右側は、この場合に端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
このトークルーム画面は、トーク相手をユーザＡ．Ａとする一対一トークルーム画面であり、トーク領域内の向かって左側に、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツＮＲＣ６２が表示され、その下には、ユーザＡ．Ａを送信元とする、前述したお礼を述べるテキストコンテンツＴＣ６２が表示されている。
また、その下には、支払いアプリケーションを送信元とするコンテンツとして、ユーザＡ．Ａによって通知付き電子マネーが使用されたことを示す通知付き電子マネー使用コンテンツＮＵＣ６２が表示されている。

＜処理＞
本実施例における処理は、限定ではなく例として、サーバ１０にメッセージングアプリケーションによるメッセージングサービスを提供する機能を持たせ、第１実施例～第５実施例で説明した処理を、メッセージングサービスの処理と組み合わせることによって実現可能である。

＜第６実施例の効果＞
本実施例は、サーバ１０が、通知付き電子マネー使用情報を、通知先アカウントのユーザを含むチャットルーム（限定ではなく、第１チャットルームの一例）に送信する制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末のユーザにより第１電子貨幣の少なくとも一部が使用されたことに関する内容を、第３端末のユーザを含む第１チャットルームへの表示という分かり易い形で、第３端末のユーザに知らせることができる。

＜第６変形例（１）＞
メッセージングアプリケーションにおいて３以上のアカウントを含むグループを構成し、送金先アカウントのユーザによって通知付き電子マネーが使用されることに基づいて、その他のアカウントのユーザに通知がいくようにすることも可能である。

図６－２は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。ここでは、前述した親子の例を挙げ、母親のアカウントと父親のアカウントと子供のアカウントとでグループ「家族」が構成されている場合の表示画面例について説明する。ユーザＡ．Ａを「子供」とし、ユーザＢ．Ｂを「母親」とし、ユーザＣ．Ｃを「父親」として説明する。

図６－２左側には、子供の端末２０Ａの表示部２４に表示される、グループ「家族」のグループトークルームの画面の一例を示している。このグループトークルーム画面では、トーク領域内の向かって左側に、ユーザＢ．Ｂのアカウントを送信元とする、前述した参考書の購入を子供に促すテキストコンテンツＴＣ６１と、支払いアプリケーションを送金元とする通知付き電子マネー送金結果コンテンツＮＲＣ６３と、ユーザＡ．Ａを送信元とするテキストコンテンツＴＣ６２と、ユーザＣ．Ｃを送信元とする買い食いをしないように子供に注意するテキストコンテンツＴＣ６４とが表示されている。

通知付き電子マネー送金結果コンテンツＮＲＣ６３は、限定ではなく例として、ユーザＢ．Ｂから送金された「１，０００円」分の通知付き電子マネーを受け取ったことを示すコンテンツであり、通知先アカウントとしてグループ「家族」が設定されていることが示されている。

通知先アカウントとしてグループ「家族」が設定されているため、ユーザＡ．Ａによって通知付き電子マネーが使用されると、グループ「家族」に含まれる全てのユーザの端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）に、通知付き電子マネー使用コンテンツが送信される。

なお、ユーザＡ．Ａに対して通知がいくようにするのは好ましくないと考えることもできる。このため、上記とは異なり、グループに含まれるアカウントのうち、送金先アカウント以外のアカウントのユーザの端末２０に対して、通知付き電子マネー使用コンテンツが送信されるようにしてもよい。

上記の状態で、不図示のユーザ入力に基づいて支払いアプリケーションによるコード支払いを行うための機能が呼び出され、前述したコード支払いによって、ユーザＢ．Ｂから送金された通知付き電子マネーを用いた決済処理が実行された結果、限定ではなく例として、図６－２中央の画面が表示される。この画面は、図６－１中央の画面と同様である。

図６－２右側は、この場合に端末２０Ｃの表示部２４に表示されるメッセージングアプリケーションのグループトークルーム画面の一例を示す図である。
このグループトークルーム画面では、トーク領域内の向かって左側に、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツＮＲＣ６４が表示され、その下には、ユーザＡ．Ａを送信元とするテキストコンテンツＴＣ６２と、ユーザＣ．Ｃを送信元とするテキストコンテンツＴＣ６４とが表示されている。

また、その下には、支払いアプリケーションを送信元とするコンテンツとして、ユーザＡ．Ａによって通知付き電子マネーが使用されたことを示す通知付き電子マネー使用コンテンツＮＵＣ６４が表示されている。

本変形例における処理は、第６実施例における処理を、メッセージングアプリケーションのグループを対象とする処理とすることで、同様に実現可能である。
この場合、サーバ１０の制御部１１は、限定ではなく例として、前述したように、通知付き電子マネー使用コンテンツを、グループに含まれる各々のユーザの端末２０に送信するようにすることができる。
なお、これとは異なり、サーバ１０の制御部１１は、通知付き電子マネー使用コンテンツを、送金先アカウントのユーザの端末２０には送信しないようにしてもよい。

＜第６変形例（２）＞
メッセージングアプリケーションのコンテンツに含まれる情報を引用して、コンテンツを送信することを可能としてもよい。

図６－３，図６－４は、本変形例において端末２０の表示部２４に表示される画面の一例を示す図である。
図６－３左側は、端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのトークルーム画面であり、トーク相手を支払いアプリケーションの公式アカウントとするＯＡトークルームの画面の一例である。

このＯＡトークルーム画面には、トーク領域内の向かって左側に、支払いアプリケーションを送信元とするコンテンツとして、前述した通知付き電子マネー送金結果コンテンツＮＲＣ６２と通知付き電子マネー使用コンテンツＮＵＣ６２とが時系列に表示されている。

この状態で、限定ではなく例として、通知付き電子マネー使用コンテンツＮＵＣ６２がタップされたことに基づき、その上側に、このコンテンツに基づいて実行させる機能をユーザが選択可能な表示領域として機能選択領域ＦＳＲが表示される。この例では、機能選択欄には、限定ではなく例として、タップされたコンテンツをコピーする「コピー」機能、タップされたコンテンツを転送する「転送」機能、タップされたコンテンツに対してリプライする「リプライ」機能、トークルーム内のコンテンツを所定位置（画面上部等）に固定表示する「アナウンス」機能等の複数の機能が含まれる。

限定ではなく例として、「リプライ」機能がタップされると、図６－３中央に示す画面が表示される。この画面は、トーク相手をユーザＡ．Ａとする一対一トークルーム画面であり、ユーザＢ．Ｂを送信元とするテキストコンテンツＴＣ６１と、ユーザＡ．Ａを送信元とするテキストコンテンツＴＣ６２とがトーク領域に表示されている。
また、トーク領域の一部に重畳するように、キーボード領域と、その上にリプライ領域とが表示されている。

リプライ領域には、限定ではなく例として、図６－３左側の画面に示した引用元コンテンツである通知付き電子マネー使用コンテンツＮＵＣ６２に関連する情報や通知付き電子マネー使用コンテンツＮＵＣ６２に含まれる少なくとも一部の情報を引用した第１引用情報が表示される引用情報表示領域ＱＩＲと、同じく引用元コンテンツである通知付き電子マネー使用コンテンツＮＵＣ６２に関連する情報や通知付き電子マネー使用コンテンツＮＵＣ６２に含まれる少なくとも一部の情報を引用した第２引用情報とともに送信するコンテンツをユーザが入力するためのコンテンツ入力領域ＣＩＲとが含まれる。
この例では、コンテンツ入力領域ＣＩＲとは異なる領域であって、ユーザによるコンテンツの入力が可能ではない領域として、引用情報表示領域ＱＩＲが表示されている。

この例では、引用情報表示領域ＱＩＲには、通知付き電子マネー使用コンテンツＮＵＣ６２に含まれる情報のうちの一部の情報として、「Ａ．Ａに送金した電子マネーが使用されました」の文字が表示されている。

なお、引用情報表示領域ＱＩＲに表示する第１引用情報に、引用元のコンテンツの送信元（送信者）に関する情報を含めてもよいし、含めなくてもよい。
コンテンツの送信元（送信者）に関する情報には、限定ではなく例として、送信元の名称（アカウント名、ユーザ名）やアイコン画像等を含めることができる。

図６－３中央の画面例では、引用情報表示領域ＱＩＲには、「Ａ．Ａに送金した電子マネーが使用されました」の文字と関連付けて、通知付き電子マネー使用コンテンツＮＵＣ６２の送信元である支払いアプリケーションのアイコン画像およびその名称（Ｐａｙｍｅｎｔ Ａｐｐ）が表示されている。

また、その下のコンテンツ入力領域ＣＩＲには、ユーザがコンテンツを入力するためのコンテンツ入力欄と、入力したコンテンツを引用情報とともに送信するための送信ボタンとが含まれる。
この例では、キーボードを用いてユーザＢ．Ｂによって「漫画買ってないでしょうね？」のテキストがコンテンツ入力欄に入力され、送信ボタンがタップされた状態が示されている。

すると、限定ではなく例として、図６－３右側の画面が表示される。
具体的には、ユーザＡ．Ａを送信元とするテキストコンテンツＴＣ６２の下に、ユーザＢ．Ｂを送信元とするコンテンツとして、図６－３中央の画面の引用情報として表示されていた支払いアプリケーションのアイコン画像およびその名称（Ｐａｙｍｅｎｔ Ａｐｐ）を含む第２引用情報と、図６－３中央の画面でユーザＢ．Ｂによって入力された「漫画買ってないでしょうね？」とを含む引用応答コンテンツ（リプライコンテンツ）ＱＣ６１が表示されている。また、その下には、ユーザＡ．Ａから送信された「ちゃんと参考書買ったよ」のテキストを含むテキストコンテンツＴＣ６６が表示されている。

この例では、ユーザＢ．Ｂによって入力されたコンテンツは、第２引用情報の下の領域に表示されている。
なお、この例とは異なり、ユーザＢ．Ｂによって入力されたコンテンツを、第２引用情報の上の領域に表示させてもよい。

また、この例では、限定ではなく例として、引用元のコンテンツである通知付き電子マネー使用コンテンツＮＵＣ６２には「＞詳細を確認」ボタンが含まれるが、トーク相手のユーザに送信される引用応答コンテンＱＣ６１には「＞詳細を確認」ボタンが含まれないようにしている。これは、１つの考え方として、通知付き電子マネーの使用履歴等の「詳細な情報」を確認することができるのは、通知先アカウントのユーザに限定するのが適切であるという考え方もできるためである。
ただし、これに限定されるわけではなく、引用応答コンテンＱＣ６１に「＞詳細を確認」ボタンを含めるようにしてもよい。

また、上記の例において、引用情報表示領域ＱＩＲに表示させる第１引用情報は、引用元コンテンツに含まれる全ての情報としてもよいし、一部の情報としてもよい。
また、ユーザによって入力されたコンテンツとともに送信する第２引用情報は、引用元コンテンツに含まれる全ての情報としてもよいし、一部の情報としてもよい。
また、第１引用情報と第２引用情報とは、完全に同一の情報としてもよいし、一部が相違する情報としてもよい。

また、上記の例とは異なり、コンテンツ入力領域ＣＩＲと引用情報表示領域ＱＩＲとを１つの領域としてもよい。つまり、コンテンツ入力領域ＣＩＲの中に第１引用情報が表示されるようにしてもよい。
また、上記の例とは異なり、コンテンツの送信元（送信者）に関する情報を引用情報表示領域ＱＩＲに表示させないようにしてもよい。

図６－４は、本変形例において端末２０Ｂの表示部２４に表示される画面の一例を示す図である。
図６－４左側は、トーク相手をグループ「家族」とするグループトークルーム画面の一例を示す図であり、トーク領域内の向かって左側には、支払いアプリケーションを送信元とする通知付き電子マネー送金結果コンテンツＮＲＣ６４と、ユーザＡ．Ａを送信元とする「おこずかいありがとう！」のテキストを含むテキストコンテンツＴＣ６７と、ユーザＡ．Ａに送金した通知付き電子マネーが使用されたことに基づく通知付き電子マネー使用コンテンツＮＵＣ６４とが時系列に表示されている。

この状態で、限定ではなく例として、通知付き電子マネー使用コンテンツＮＵＣ６４がタップされたことに基づき、その下側に、この通知付き電子マネー使用コンテンツＮＵＣ６４に基づいて実行させる機能をユーザが選択可能な表示領域として機能選択領域ＦＳＲが表示される。この例では、機能選択領域ＦＳＲには、前述した機能の他、限定ではなく例として、定期送金設定を行うための「定期送金設定」機能が含まれる。この「定期送金設定」機能がタップされると、限定ではなく例として、図６－４中央の画面が表示される。

この画面は、支払いアプリケーションにおける定期送金設定画面の一例であり、限定ではなく例として、送金日を設定するための送金日設定欄と、送金先アカウントを設定するための送金先アカウント設定欄と、通知先アカウントを設定するための通知先アカウント設定欄と、送金額を設定するための送金額設定欄とが設けられている。

送金日設定欄には、設定されている送金日が表示される。この例では、「毎月１日に送金」が設定された状態が示されている。また、右側の「変更」ボタンをタップすることで、通知付き電子マネーの送金日を変更することが可能に構成されている。

送金先アカウント設定欄には、設定されている送金先アカウントに関する情報が表示される。この例では、ユーザＡ．Ａのアイコン画像およびそのユーザ名（Ａ．Ａ）が表示されている。

通知先アカウント設定欄には、設定されている通知先アカウントに関する情報が表示される。この例では、メッセージングアプリケーションにおけるグループ「家族」が通知先アカウントとして設定された状態が示されている。また、右側の「変更」ボタンをタップすることで、通知先アカウントを変更することが可能に構成されている。

送金額設定欄には、設定されている通知付き電子マネーの送金額が表示される。この例では「３，０００円」が設定された状態が示されている。また、右側の「変更」ボタンをタップすることで、送金額を変更することが可能に構成されている。

この状態で、画面下部の「設定」ボタンＢＴ６１がタップされると、限定ではなく例として、図６－４右側の画面が表示される。
この画面は、図６－４左側のトークルーム画面に対応する画面であり、図６－４左側のトークルーム画面における通知付き電子マネー使用コンテンツＮＵＣ６４の下に、支払いアプリケーションを送信元とするコンテンツとして、定期送金設定が行われたこと（または定期送金設定が変更されたこと）を示す定期送金設定コンテンツＮＳＣ６１が表示されている。定期送金設定コンテンツＮＳＣ６１では、定期送金の送金額が「５，０００円」から「３，０００」円に減額されたことが示されている。

また、その下には、ユーザＢ．Ｂを送信元とする「ゲーム買ってるから来月からおこずかい減らすね」のテキストを含むテキストコンテンツＴＣ６８と、ユーザＡ．Ａを送信元とする「え、なんで？」のテキストを含むテキストコンテンツＴＣ６９とが表示されている。

＜処理＞
本実施例では、端末２０（限定ではなく例として、送金元アカウントのユーザの端末２０）の制御部２１は、自己の端末２０の表示部２４に表示されたメッセージングアプリケーションのトークルームにおける一のコンテンツ（限定ではなく例として、通知付き電子マネー使用コンテンツ）に対する入力に基づいて、そのコンテンツに対応させて機能選択領域を表示させる。

限定ではなく例として「リプライ」機能が選択された場合、制御部２１は、第１引用情報を含む引用情報表示領域と、コンテンツ入力領域とを表示させる。また、コンテンツ入力領域に対する操作を検知したことに基づいてキーボードを表示させる。そして、キーボードを介してユーザによって入力された入力コンテンツをコンテンツ入力領域に表示させ、送信ボタンが操作されたならば、第２引用情報と、入力コンテンツとを含む引用応答コンテンツを自己の端末２０のトークルームに表示させる。また、第２引用情報と、入力コンテンツとを、通信Ｉ／Ｆ２２によってサーバ１０に送信する。
これを受けて、サーバ１０の制御部１１は、受信した情報に基づいて引用応答コンテンツを生成し、通信Ｉ／Ｆ１４によってトーク相手の端末２０に送信する。
そして、トーク相手の端末２０の制御部２１は、受信した引用応答コンテンツを、自己の端末２０の表示部２４のトークルームに表示させる。

また、限定ではなく例として「定期送金設定」機能が選択された場合、制御部２１は、支払いアプリケーションを実行して、定期送金設定画面を表示部２４に表示させる。そして、ユーザ入力に基づいて設定した定期送金に関する設定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。
これを受けて、サーバ１０の制御部１１は、受信した設定情報に基づいて定期送金設定コンテンツを生成し、通信Ｉ／Ｆ１４によってトーク相手の端末２０に送信する。
そして、トーク相手の端末２０の制御部２１は、受信した定期送金設定コンテンツを、自己の端末２０の表示部２４のトークルームに表示させる。

本実施例は、通知先アカウントのユーザの端末２０は、送金元アカウントのユーザの端末２０であり（限定ではなく、第３端末が第１端末であることの一例）、トークルームは、送金元アカウントのユーザ（限定ではなく、第１端末のユーザの一例）と、送金先アカウントのユーザ（限定ではなく、第２端末のユーザの一例）とを含む。そして、サーバ１０は、トークルームに表示された通知付き電子マネー使用コンテンツ等への入力が行われた場合、定期送金設定用の情報（限定ではなく、設定された期間ごとに、通知の設定が行われた電子貨幣が第２端末のユーザに対して送金される金額を入力するための情報の一例）を通信Ｉ／Ｆ１４によって送金元アカウントのユーザの端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと第２端末のユーザとを含むチャットルームに表示された通知への入力が、第１端末のユーザによって行われたことに基づいて、設定された期間ごとに、通知の設定が行われた電子貨幣が第２端末のユーザに対して送金される金額を第１端末のユーザが入力できるようにすることを可能とすることができる。

＜第７実施例＞
第７実施例は、通知付き電子マネー残高の使用に制限を加えることを可能にする実施例である。

第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

図７－１は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｆの一例を示す図である。
アカウント管理データベース１５５Ｆに含まれる各々のアカウント管理データには、アプリケーションＩＤと、通常電子マネー残高との他に、限定ではなく例として、制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。

制限付き電子マネー管理データは、このアプリケーションＩＤのアカウントに関連付けられた、制限付き電子マネーに関する情報を管理するためのデータである。本データにて、制限付き電子マネー管理データには、限定ではなく例として、送金管理ＩＤと、送金元ＩＤと、通知先ＩＤと、通知者名と、制限付き電子マネー残高とが関連付けて記憶される。

送金管理ＩＤは、制限付き電子マネーの送金をユニークに識別するためのＩＤであり、限定ではなく例として、制限付き電子マネーの送金がサーバ１０によって実行されるごとに、サーバ１０によって異なるＩＤが設定されて記憶される。
限定ではなく例として、ユーザＢ．Ｂの同じアカウントからユーザＡ．Ａの同じアカウントに対して、制限付き電子マネーが送金されたような場合であっても、それぞれ異なるＩＤが設定される。

送金元ＩＤは、制限付き電子マネーをこのアプリケーションＩＤのアカウントに送金したアカウントを識別するための識別情報であり、限定ではなく例として、制限付き電子マネーを送金したアカウント（送金元アカウント）のアプリケーションＩＤが記憶される。

通知先ＩＤは、対応する制限付き電子マネー残高が使用された場合に、通知先アカウントを識別するための情報であり、限定ではなく例として、通知先アカウントとして設定されたアカウントのアプリケーションＩＤが記憶される。

通知者名は、この通知先ＩＤに対応するユーザ名である。限定ではなく例として、アカウント登録データ１５３において、この通知先ＩＤに対応するアプリケーションＩＤに関連付けられたユーザ名が記憶される。

制限付き電子マネー残高は、この送金管理ＩＤに関連付けられた制限付き電子マネーの残高である。

制限付き電子マネー使用履歴データは、制限付き電子マネーの使用履歴に関するデータであり、限定ではなく例として、決済ＩＤと、送金管理ＩＤと、使用店舗名と、使用日時と、使用金額とが関連付けて記憶される。
決済ＩＤと、送金管理ＩＤと、使用店舗名と、使用日時と、使用金額とは、限定ではなく例として、前述した通知付き電子マネー使用履歴データと同様に構成することができる。

電子マネー使用制限管理データは、制限付き電子マネーの使用制限を管理（規定）するためのデータであり、限定ではなく例として、送金管理ＩＤと、使用可否フラグと、使用可能状態終了日時とが関連付けて記憶される。

送金管理ＩＤは、電子マネー使用制限管理データにおいて制限付き電子マネー残高の使用制限がかけられる制限付き電子マネーを識別するための情報であり、限定ではなく例として、制限付き電子マネー管理データに格納される送金管理ＩＤのうち、限定ではなく例として、使用制限が送金者によって設定された送金管理ＩＤが記憶される。

使用可否フラグは、この制限付き電子マネー残高の使用（この制限付き電子マネー残高を用いる支払い）が可能か否かを示すためのフラグ情報であり、限定ではなく例として、使用可能である場合、「可能」のフラグが、使用不能である場合、「不能」のフラグが記憶される。

使用可能状態終了日時には、限定ではなく例として、この制限付き電子マネー残高が使用可能である場合、使用可能から使用不能となる日時が記憶される。

なお、本データでは、通知付き電子マネー残高の使用に関する制限として、限定ではなく例として、ある期限内において使用（支払い）が可能か否かについて例示しているが、これに限定されない。様々な制限をかける場合の電子マネー使用制限管理データの例については後述する。

＜表示画面＞
図７－２・図７－３・図７－４は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図７－２左側には、端末２０Ｂの表示部２４に表示される支払いアプリケーションの送金画面の一例を示している。この送金画面では、画面中央部から下部にかけて、前述した送金先アカウントのユーザを示す情報とともに、前述した通知付き電子マネー使用通知を受け取るか否かを選択するためのスライドボタンが設けられている。さらに、その下には、通知付き電子マネー残高の使用に制限をかけるか否かを選択するためのスライドボタンが設けられている。

また、その下には、制限付き電子マネーの使用を制限する内容を設定するための「使用制限を設定」ボタンＢＴ７１が設けられている。
なお、この例では、制限付き電子マネーの使用を制限する内容として「制限時間」が設定済みであることとして説明する。

ここでは、両方のスライドボタンが「ＯＮ」とされ、「送金」ボタンＢＴ２がタップされた状態が示されている。
図７－２中央は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面では、おしらせ領域内の向かって左側に、制限付き電子マネーが送金されたことを示す制限付き電子マネー送金結果情報ＲＲ７１が表示されている。

この例では、制限付き電子マネー送金結果情報ＲＲ７１には、制限付き電子マネーを使用するとユーザＢ．Ｂに通知付き電子マネー使用通知がされること、および、制限付き電子マネーを使用するにはユーザＢ．Ｂの許可が必要であることが示されている。
また、制限付き電子マネーを使用するとユーザＢ．Ｂに通知付き電子マネー使用通知がされることを示すイラストの右には、注意マーク／工事マークに類する、通知付き電子マネーの使用に制限がかけられていることを示すマーク（以下、「制限マーク」と称する。）ＲＭＫが表示されている。

図７－２右側は、端末２０Ａの表示部２４に表示されるコード支払い画面の一例を示す図である。
このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１内の上部の残高が表示される領域に、制限付き電子マネー残高に関する情報と、制限なしの電子マネー残高（つまり通常電子マネー残高）に関する情報とが表示されている。
「制限付き」と示された残高が制限付き電子マネー残高であるが、上記のように、制限付き電子マネーｗ使用するにはユーザＢ．Ｂの許可が必要であり、ユーザＡ．ＡはユーザＢ．Ｂからまだ許可を得ていない状態である。このため、制限付き電子マネーの残高に関する情報の表示部分はグレーアウトしており、ユーザＡ．Ａが「制限付き」の文字の左に設けられたラジオボタンをタップしても「ＯＮ」にすることができないようになっている。

図７－３左側は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図であり、おしらせ領域内の向かって左側に、制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報ＲＲ７２が表示されている。制限付き電子マネー送金結果情報ＲＲ７２には、送金した通知付き電子マネーの使用を設定時間（この例では「６０分」）に限り許可するための制限付き電子マネー使用許可ボタンＢＴ７２が設けられている。

図７－３右側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域の制限付き電子マネー送金結果情報ＲＲ７１の下には、ユーザＢ．Ｂによって制限付き電子マネーの使用が許可されたことを示す制限付き電子マネー使用許可情報ＲＰ７１が表示されている。
なお、この例において制限付き電子マネーを使用することのできる期間は、限定ではなく例として、端末２０Ｂから送信される制限付き電子マネーの使用を許可・承認する情報（後述する制限付き電子マネー使用承認情報）をサーバ１０が受信してから設定時間（この例では「６０分」間）が経過するまでの間とすることができる。

図７－４は、端末２０Ｂの表示部２４に表示されるコード支払い画面の一例を示す図である。
ユーザＢ．Ｂによって制限付き電子マネーの使用が許可されたことで、図７－２右側のコード支払い画面においてウォレットコード情報表示領域ＷＣＲ１に表示されていた制限付き電子マネーの残高に関する情報の表示部分のグレーアウトが解除され、ユーザＡ．Ａが「制限付き」の文字の左に設けられたラジオボタンをタップして「ＯＮ」とすることが可能となっている。そして、ここでは、ラジオボタンが「ＯＮ」とされた状態が示されている。この状態でコード支払いを行うことで、図７－４右側のように決済結果情報が表示される。

＜処理＞
図７－５～図７－６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
まず、端末２０Ｂの制御部２１は、入出力部２３に対するユーザ入力等に基づいて、制限付き電子マネーの送金に関する設定処理として、制限付き電子マネー送金設定処理を行う（Ｂ４１０）。

そして、端末２０Ｂの制御部２１は、限定ではなく例として、使用制限に関する設定と通知先アカウントとを含む設定情報を含む、通知付き電子マネー送金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ４２０）。

通信Ｉ／Ｆ１４によって端末２０Ｂから制限付き電子マネー送金依頼情報を受信すると、サーバ１０の制御部１１は、制限付き電子マネー送金処理を行う（Ｓ４１０）。
具体的には、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｆに含まれるアカウント管理データのうち、送金先アカウントのユーザであるユーザＡ．Ａ（または端末２０Ａ）のアカウントに対応するアカウント管理データを、端末２０Ｂから受信した通知付き電子マネー送金依頼情報に含まれる設定情報に基づいて更新する。
また、サーバ１０の制御部１１は、電子マネー使用制限管理データの使用可否フラグとして、限定ではなく例として、初期値として「不能」のフラグを設定する。

その後、サーバ１０の制御部１１は、制限付き電子マネー送金結果に関する情報である制限付き電子マネー送金結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ４２０）。なお、制限付き電子マネー送金結果情報に、制限付き電子マネー送金処理において生成された送金管理ＩＤを含めるようにしてもよい。
端末２０Ａの制御部２１と、端末２０Ｂの制御部２１とは、サーバ１０から受信した制限付き電子マネー送金結果情報を受信すると、それぞれ表示部２４に表示させる（Ａ４１０，Ｂ４３０）。

次いで、端末２０Ｂの制御部２１は、送金した制限付き電子マネー残高の使用を承認するか否かの選択用表示を表示部２４に表示させる（Ｂ４４０）。入出力部２３に対するユーザ入力等に基づいて、使用承認が選択される場合（Ｂ４４０：ＹＥＳ）、端末２０Ｂの制御部２１は、制限付き電子マネー使用承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ４５０）。なお、制限付き電子マネー使用承認情報に、使用承諾を行う制限付き電子マネー残高の送金管理ＩＤを含めるようにしてもよい。
使用承認が選択されない場合（Ｂ４４０：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ４５０のステップをスキップする。

通信Ｉ／Ｆ１４によって端末２０Ｂから制限付き電子マネー使用承認情報を受信する場合（Ｓ４３０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー使用承認処理を実行する（Ｓ４４０）。
具体的には、サーバ１０の制御部１１は、限定ではなく例として、アカウント管理データベース１５５Ｆに含まれるアカウント管理データにおける電子マネー使用制限管理データから、制限付き電子マネー使用承認情報で指定される送金管理ＩＤの使用可否フラグを「不能」から「可能」に変更する。また、使用可能状態終了日時に、所定の日時（限定ではなく例として、制限付き電子マネー使用承認情報を受信してから６０分後）を記憶させる。

通信Ｉ／Ｆ１４によって端末２０Ｂから制限付き電子マネー使用承認情報を受信しない場合（Ｓ４３０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４４０のステップをスキップする。

端末２０Ａの制御部２１は、受信したウォレットコード情報を表示部２４に表示させる（Ａ１３０）と、入出力部２３に対するユーザ入力等に基づいて、限定ではなく例として、支払いを行う残高を指定するための送金管理ＩＤを含む支払い残高選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ４２０）。なお、通常電子マネー残高から決済を行うことが選択される場合、支払い残高選択情報として通常電子マネー残高から決済を行うことを選択する情報を含めるようにしてもよい。また、端末２０Ａの制御部２１は、支払いを行う残高が指定されない場合、支払い残高選択情報をサーバ１０に送信しなくてもよい。

なお、端末２０Ａの制御部２１は、Ａ４２０のステップをＡ１２０のステップと同時に、または前後して実行するようにしてもよい。この場合、サーバ１０の制御部１１は、支払いを行う残高として指定された制限付き電子マネー残高の使用可否フラグが「不能」である場合、ウォレットコード情報を端末２０Ａに送信しないようにしてもよい。

通信Ｉ／Ｆ１４によって店舗ＰＯＳシステム４０から決済要求情報を受信し、端末２０Ａから支払い残高選択情報を受信すると、サーバ１０の制御部１１は、制限付き決済処理を実行する（Ｓ４５０）。

制限付き決済処理において、サーバ１０の制御部１１は、限定ではなく例として、支払い残高選択情報に基づいて、支払いを行う残高として指定された制限付き電子マネー残高の使用可否フラグが「可能」であり、かつ、使用可能状態終了日時を過ぎていない場合、指定された制限付き電子マネー残高を用いて決済の可否を判定する。決済が成功する場合、サーバ１０の制御部１１は、指定された制限付き電子マネー残高から決済金額を差し引く。
支払いを行う残高として指定された制限付き電子マネー残高の使用可否フラグが「不能」である場合、または、使用可能状態終了日時を過ぎている場合、サーバ１０の制御部１１は、指定された制限付き電子マネー残高を用いた決済を失敗と判定する。なお、使用可能状態終了日時を過ぎている場合、サーバ１０の制御部１１は、指定された制限付き電子マネー残高の使用可否フラグを「可能」から「不能」に変更し、使用可能状態終了日時を消去するようにしてもよい。
なお、残高不足や使用制限等で制限付き電子マネー残高を用いた決済が失敗する場合、サーバ１０の制御部１１は、通常電子マネー残高に切り替えて決済を実行するようにしてもよい。
支払いを行う残高として通常電子マネー残高が指定される場合、サーバ１０の制御部１１は、通常電子マネー残高を用いて決済を実行する。

なお、端末２０Ａから支払い残高選択情報を受信しない場合、サーバ１０の制御部１１は、第１実施例において述べた（ａ）～（ｆ）の手法に基づいて、通知付き電子マネー残高を制限付き電子マネー残高と読み替えて、支払いを行う残高を選択し、制限付き決済処理を行うようにしてもよい。

Ｓ１５０の後、サーバ１０の制御部１１は、Ｓ４５０の制限付き決済処理において、決済に制限付き電子マネー残高を使用したか否かを判定する（Ｓ４６０）。
使用しなかったと判定したならば（Ｓ４６０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
一方、使用したと判定したならば（Ｓ４６０：ＹＥＳ）、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって、制限付き電子マネー使用情報を端末２０Ｂに送信する（Ｓ４７０）。そして、サーバ１０の制御部１１は、処理を終了する。

端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー使用情報を受信したか否かを判定する（Ｂ４６０）。
受信しなかったと判定したならば（Ｂ４６０：ＮＯ）、端末２０Ｂの制御部２１は、処理を終了する。
一方、受信したと判定したならば（Ｂ４６０：ＹＥＳ）、端末２０Ｂの制御部２１は、受信した制限付き電子マネー使用情報を表示部２４に表示させる（Ｂ４７０）。そして、端末２０Ｂの制御部２１は、処理を終了する。

＜第７変形例（１）＞
上記の実施例では、制限付き電子マネー残高が使用されると通知先アカウントに通知される例を示したが、これに限定されない。限定ではなく例として、制限付き電子マネー残高が使用されても、送金者等の第三者に通知されないようにしてもよい。

この場合、限定ではなく例として、制限付き電子マネー管理データの通知先ＩＤと、通知者名とには、データが記憶されない（限定ではなく例として、ＮＵＬＬが格納される）。そして、制限付き決済処理において制限付き電子マネー残高を使用した場合でも、サーバ１０の制御部１１は、制限付き電子マネー使用情報を送信しない。

＜第７変形例（２）＞
上記の実施例では、制限付き決済処理において制限付き電子マネー残高の使用が出来ない場合が存在したが、これに限定されない。限定ではなく例として、制限付き決済処理において制限付き電子マネー残高の使用を常に認めるようにしてもよい。
この場合、限定ではなく例として、所定の送金管理ＩＤにおいて、電子マネー使用制限管理データにその送金管理ＩＤを記憶させないようにしてもよい。または、所定の送金管理ＩＤにおいて、電子マネー使用制限管理データの使用可否フラグを永続的に「可能」とし、使用可能状態終了日時を十分に先の未来（限定ではなく例として、５０億年後）に設定してもよい。このとき、制限付き決済処理において制限付き電子マネー残高の使用には制限が存在しないことと等価となる。

なお、制限付き決済処理において制限付き電子マネー残高の使用を制限せず、制限付き電子マネー残高の使用を通知先アカウントに通知する場合、制限付き電子マネー残高は通知付き電子マネー残高といってもよい。

＜第７変形例（３）＞
上記の実施例では、通常電子マネー残高と制限付き電子マネー残高を区別していたが、これに限定されない。限定ではなく例として、通常電子マネー残高を、制限付き電子マネー管理データにおいて通知先ＩＤ・通知者名無し、電子マネー使用制限管理データにおいて制限付き決済処理における使用制限なしの制限付き電子マネー残高としてもよい。この場合、制限付き電子マネー管理データにおいて、限定ではなく例として、送金管理ＩＤは電子マネーのチャージ時に生成されるＩＤとし、送金元ＩＤはアプリケーションＩＤと同一にすることができる。

すなわち、広義の「制限付き電子マネー残高」には、以下の概念を含めることができる。
（１）使用に関する制限が存在し、使用されると送金者等の第三者に通知される「通知付き制限付き電子マネー残高」。
（２）使用に関する制限が存在するが、使用しても第三者に通知されない「通知無し制限付き電子マネー残高」。
（３）使用に関する制限が存在せず、使用されると第三者に通知される（使用すると通知されるという制限が存在する）「通知付き制限無し電子マネー残高（通知付き電子マネー残高）」。
（４）使用に関する制限が存在せず、使用しても第三者に通知されない（制限が存在しない）「通知無し制限無し電子マネー残高（通常電子マネー残高）」。

＜第７変形例（４）＞
上記の実施例では、制限付き決済処理における残高使用の制限として、予め送金者の承認が必要である例を示したが、これに限定されない。
制限付き決済処理における残高使用の制限として、限定ではなく例として、特定の業種・業態の店舗やサービスにおいて支払いを行う残高として用いることができないようにしてもよい。

図７－７は、本変形例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｇの一例を示す図である。
アカウント管理データベース１５５Ｇにおいて、電子マネー使用制限管理データには、限定ではなく例として、送金管理ＩＤと、使用禁止店舗業種とが関連付けて記憶される。

使用禁止店舗業種は、この制限付き電子マネー残高の使用を禁止する業種・業態を記憶するための項目であり、限定ではなく例として、送金者による入力に基づいて設定され、記憶される。
図７－７では、限定ではなく例として、送金管理ＩＤ「Ｔ０１００３」で管理される制限付き電子マネー残高は、「アパレル」、「家具・家電」、「居酒屋・パブ」の業種に分類される店舗・サービスでは使用できないことが記憶されている。

図７－８～図７－９は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図７－８は、制限付き電子マネーの使用制限の別例に関する表示画面の一例を示す図である。
図７－８左側は、端末２０Ｂの表示部２４に表示される支払いアプリケーションの送金画面の一例を示す図であり、図７－２左側の画面に対応する画面図である。
この例では、制限付き電子マネーの使用を制限する内容が未だ設定されていない状態であるため、画面下部の「送金」ボタンがグレーアウトして表示されている。
前述した「使用制限を設定」ボタンＢＴ７１がタップされると、図７－８中央のような表示がなされる。

この画面では、制限付き電子マネーの使用を制限する内容として、限定ではなく例として、制限付き電子マネーの使用を禁止する店舗の業種を設定することが可能に構成されている。
この例では、「コンビニ」、「スーパー・ホームセンター」、「アパレル」、「家具・家電」、「居酒屋・パブ」、「コーヒーショップ」等の複数の店舗の業種が、それぞれイラストと業種名とを含むボックスで一覧表示されている。

制限付き電子マネーの使用を禁止したいボックスをタップすると、限定ではなく例として、そのボックスに関連付けてチェックマークが付される。そして、画面下部の「設定」ボタンＢＴ７３をタップすることで、チェックマークが付された業種を、制限付き電子マネーの使用を制限する業種として設定することが可能に構成されている。

この例では、ユーザＢ．Ｂによって「アパレル」、「家具・家電」、「居酒屋・パブ」の３つの業種が、制限付き電子マネーの使用を禁止したい業種としてタップされてチェックマークが付された状態が示されている。この状態で「設定」ボタンＢＴ７３がタップされることで、限定ではなく例として、図７－８右側の画面が表示される。

この画面は、支払いアプリケーションの送金画面であり、図７－８左側の画面に対応するものである。この例では、図７－８左側の送金画面における「使用制限を設定」ボタンＢＴ７１の上に、図７－８中央の画面で設定された業種に対応するアイコンが表示されている。具体的には、「アパレル」、「家具・家電」、「居酒屋・パブ」の３つの業種に対応するアイコンが表示されている。また、制限付き電子マネーの使用を禁止する業種が設定されたことで、図７－８左側の画面における「送金」ボタンのグレーアウトが解除されている。そして、ここでは、「送金」ボタンＢＴ２がタップされた状態が示されている。

図７－９左側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、制限付き電子マネー送金結果情報ＲＲ７３が表示されている。この制限付き電子マネー送金結果情報には、ユーザＢ．Ｂによって設定された制限付き電子マネーの使用を禁止する業種に対応するイラストが含まれる。具体的には、禁止マークおよび「以下の店舗では利用できません」の文字とともに、「アパレル」、「家具・家電」、「居酒屋・パブ」の３つの業種に対応するアイコンが表示されている。

その後、図７－９中央のコード支払い画面には、ウォレットコード情報表示領域ＷＣＲ１内の制限付き電子マネー残高のラジオボタンが「ＯＮ」とされた状態が示されている。この状態で、限定ではなく例として、ユーザＡ．Ａが電器店（この例では「ＸＸ電機」）で支払いを行おうとし、店舗のコードリーダによってウォレットコード情報を読み取ってもらったとする。しかし、電器店は、制限付き電子マネーの使用を禁止された業種「家具・家電」に含まれるため、制限付き電子マネーの使用が禁止される。その結果、限定ではなく例として、図７－９右側の画面が表示される。

この画面では、ウォレットコード情報表示領域ＷＣＲ１に重畳するように、残高不足であり支払いを行うことができないことを示す情報が表示されている。
具体的には、支払い金額が「１，０００円」であり、制限付き電子マネー残高が「１，０００円」であるため、実際には金額は足りている。しかし、制限付き電子マネー残高の使用が禁止されているため制限付き電子マネー残高「１，０００円」は支払いに使用することができない。このため、支払い金額「１，０００円」に対して「１，０００円」不足していることになり、残高不足となる。
なお、この例では、制限付き電子マネー残高のみが支払いに使用され、通常電子マネー残高は支払いに使用されないようにしている。

本変形例において、まず、端末２０Ｂの制御部２１は、図７－５のＢ４１０のステップにおいて、限定ではなく例として、入出力部２３に対するユーザ入力等に基づいて、制限付き電子マネー残高の使用を禁止する業種・業態を設定する。
図７－５のＳ４１０のステップにおいて、サーバ１０の制御部１１は、限定ではなく例として、端末２０Ｂから受信した通知付き電子マネー送金依頼情報に含まれる設定情報に基づいて、電子マネー使用制限管理データの使用禁止店舗業種を更新する。

また、端末２０Ｂの制御部２１は、図７－５のＢ４３０～Ｂ４５０のステップをスキップし、サーバ１０の制御部１１は、図７－５のＳ４３０～Ｓ４４０のステップをスキップする。

図７－５のＳ４５０のステップにおいて、サーバ１０の制御部１１は、限定ではなく例として、支払いを行う残高として指定された制限付き電子マネー残高の使用禁止店舗業種が決済要求情報から判定される業種・業態と一致しない場合、指定された制限付き電子マネー残高を用いて決済の可否を判定する。決済が成功する場合、サーバ１０の制御部１１は、指定された制限付き電子マネー残高から決済金額を差し引く。
支払いを行う残高として指定された制限付き電子マネー残高の使用禁止店舗業種が決済要求情報から判定される業種・業態と一致する場合、サーバ１０の制御部１１は、指定された制限付き電子マネー残高を用いた決済を失敗と判定する。

なお、制限付き電子マネー残高の使用制限には、限定ではなく例として、以下の様な制限が挙げられる。
・送金元アカウントや通知先アカウント等における使用承認。
・制限付き電子マネー残高が使用されることに関する通知。
・制限付き電子マネー残高が使用可能な日時・時間帯（限定ではなく例として、遠足の日や土日、１１：００～１３：００までの時間帯はは使用できる等）。
・制限付き電子マネー残高が使用不能な日時・時間帯（限定ではなく例として、平日や２２：００～６：００までの深夜時間帯は使用できない等）。
・決済を行う店舗・サービス事業者の業種・業態における使用制限（限定ではなく例として、決済要求情報に含まれる決済店舗の識別情報に基づいて、店舗・サービスの業種や業態による使用可能・不能を設定する等）
・決済を行う商品・サービスの品目における使用制限（限定ではなく例として、端末によって撮像された商品画像または決済要求情報に含まれるＪＡＮコードやＥＡＮコード等に基づいて、使用可能な商品・サービスを設定する等。より具体的には、限定ではなく例として、プラモデルの購入には使用できるがゲームソフトの購入には使用できない等。）
・決済金額に関する使用制限（限定ではなく例として、決済金額が１０００円以下であれば使用できる等）
・端末位置における使用制限（限定ではなく例として、自宅から半径５ｋｍ以内であれば使用できる等）
・出金に関する制限（限定ではなく例として、制限付き電子マネー残高からＡＴＭによる現金での出金や銀行口座への出金ができない等）
・制限付き電子マネー残高が初めて使用された時点からの有効期限。
・制限付き電子マネー残高が使用される回数（限定ではなく例として、「１０回」使用可能である等）。
・上記の制限の任意の組み合わせ。

また、制限付き電子マネー残高は、送金によって発生することに限定されない。限定ではなく例として、子供のアカウントに親がチャージを行うとき、親の端末または子供の端末を用いて使用制限を設定できるようにしてもよいし、そのようにしなくてもよい。

本変形例は、制限付き電子マネーに設定される制限は、支払いを行う端末２０のユーザが制限付き電子マネーを使用した場合に通知を行うことに関する制限、制限付き電子マネーを使用可能な店舗に関する制限、制限付き電子マネーを使用可能な商品またはサービスに関する制限、制限付き電子マネーを使用可能な商品またはサービスのカテゴリに関する制限、制限付き電子マネーを使用不可な商品に関する制限、制限付き電子マネーが使用できない時間帯に関する制限、制限付き電子マネーを使用できない日にち、制限付き電子マネーを使用できない日時に関する制限のうち少なくとも一つを含む構成を示している。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザが第１電子貨幣を使用した場合に第１情報処理装置のユーザに通知を行うことに関する制限、第１電子貨幣を使用可能な店舗に関する制限、第１電子貨幣を使用可能な商品またはサービスに関する制限、第１電子貨幣を使用可能な商品またはサービスのカテゴリに関する制限、第１電子貨幣を使用不可な商品に関する制限、第１電子貨幣が使用できない時間帯に関する制限、第１電子貨幣を使用できない日にちまたは日時に関する制限といった各種の制限が、第１情報処理装置のユーザによって第１電子貨幣に設定されるようにすることを可能とすることができ、第１情報処理装置のユーザの利便性を向上させることができる。

＜第７変形例（５）＞
上記の実施例では、支払いの時に制限付き電子マネー残高を用いているが、これに限定されない。
限定ではなく例として、支払いにおいて通常電子マネーを使用した後、限定ではなく例として、送金元アカウントや通知先アカウント等における使用承認に基づいて、制限付き電子マネー残高から通常電子マネー残高に残高を変換するようにしてもよい。すなわち、支払いの時点では制限付き電子マネーが使用できない場合でも、通常電子マネーを用いて立て替えて支払うことで、支払い後に制限付き電子マネー残高を使用できるようにしてもよい。

図７－１０～図７－１１は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図７－１０左側は、図７－９中央の画面と同様のコード支払い画面である。
この例では、チャージボタンＣＢＴがタップされてユーザＡ．Ａによって電子マネーが「５００円」分チャージされ、通常電子マネー残高が「５００円」から「１，０００円」に増加した状態が示されている。この状態で「１，０００円」のコード支払いを行うと、限定ではなく例として、図７－１０中央の決済結果情報が表示される。
この例では、通常電子マネーが支払いに使用されたことで、「制限なし」からの支払いが「１，０００円」であることが示されている。

図７－１０右側は、その後に表示される支払いアプリケーションのメインメニュー画面であり、残高表示領域に表示される残高が、「制限付き」は「１，０００円」の状態のままとされ、「制限なし」は「０円」に変化した表示されている。

図７－１１左側は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面には、制限付き電子マネー送金結果情報ＲＲ７４の下に、制限付き電子マネーの使用を許可するか否かを確認するための制限付き電子マネー使用確認情報ＲＶ７４が表示されている。この情報に含まれる「許可する」ボタンがタップされ、ユーザＡ．Ａに送金した制限付き電子マネーの使用を許可することがユーザＢ．Ｂによって選択されると、図７－１１中央に示すように、おしらせ領域にその旨（「許可する」のテキスト）が表示される。ただし、この制限付き電子マネーの使用の許可は、この例では、制限付き電子マネー残高から通常電子マネー残高に残高を変換することの許可である。

上記の許可に基づき、サーバ１０によってユーザＡ．Ａのアカウントの制限付き電子マネー残高から通常電子マネー残高に残高が変換される。そして、サーバ１０から端末２０Ｂに対して制限付き電子マネー使用情報ＲＵ７１が送信される。その結果、図７－１１中央に示すように、おしらせ領域には、制限付き電子マネー使用情報ＲＵ７１が表示されている。

一方、端末２０Ａの支払いアプリケーションのウォレットメインメニュー画面には、図７－１１右側のような表示がなされる。具体的には、サーバ１０によってユーザＡ．Ａのアカウントの制限付き電子マネー残高から通常電子マネー残高に残高が変換されたことにより、図７－１０右側の画面において残高表示領域ＢＲ２に表示されていた制限付き電子マネー残高に関する情報の表示が消去され、図７－１１右側の画面では、「１０００円」の残高（通常電子マネー残高）とチャージボタンＣＢＴとが表示されている。

＜第７変形例（６）＞
商品やサービスの返品時等において、返金が発生した場合、決済時に制限付き電子マネー残高が使用された場合には、返金される金額を決済時に使用した制限付き電子マネー残高に加算するようにしてもよい。この場合、処理としては、限定ではなく例として、第２変形例と同様に処理を実行することができる。

＜第８実施例＞
前述の実施例では、サーバ１０が、決済処理（制限付き決済処理）において、通常電子マネーと制限付き電子マネーとのうちのいずれか一方の電子マネーを用いて決済を実行していた。
第８実施例は、通常電子マネーと、１つの制限付き電子マネーとを用いて決済を行う実施例である。

第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図８－１は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。。
図８－１左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、「コード支払い」アイコンがタップされた状態が示されている。
すると、限定ではなく例として、図８－１中央のようなコード支払い画面が表示される。

この画面では、通知先アカウントがユーザＢ．Ｂのアカウントである制限付き通知マネー残高として「１，０００円」が表示され、通常電子マネー残高として「５００円」が表示されている。「コード支払い」アイコンＩＣ２がタップされると、図８－１中央のコード支払い画面が表示される。

このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１に、制限付き電子マネー残高と通常電子マネー残高とを合算した残高（この例では「１，５００円」）が表示されている。また、前述したように、制限付き電子マネー残高（制限付き）に関する情報と、通常電子マネー残高（制限なし）に関する情報とが表示されている。しかし、ここでは、これらの表示の横にラジオボタンは設けられておらず、制限付き電子マネー残高と、通常電子マネー残高とが自動的に支払いに用いられるようになっている。

ここでは「１，２００円」の商品を購入する場合を例示する。制限付き通知マネー残高と、通常電子マネー残高との合計は「１，５００円」であるため、支払い金額「１，２００円」を超えている。この場合、限定ではなく例として、制限付き電子マネーが優先的に使用され、不足分が通常電子マネーから使用されるようにすることができる。これに基づいて決済処理が行われることで、図８－１右側の決済結果情報が表示される。

具体的には、「１，２００円」の支払いが完了したことを示す情報が表示されており、内訳として、制限付き電子マネーから「１，０００円」が支払われ、通常電子マネーから残りの「２００円」が支払われたことを示す情報が表示されている。

＜処理＞
図８－２～図８－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。

通信Ｉ／Ｆ１４によって店舗ＰＯＳシステム４０から決済要求情報を受信すると、サーバ１０の制御部１１は、使用残高算出処理を実行する（Ｓ５００）。使用残高算出処理において、サーバ１０の制御部１１は、決済要求情報の支払い金額のうち、制限付き電子マネー残高から支払いを行う第１支払い金額と、通常電子マネー残高から支払いを行う第２支払い金額とを算出する。

ここで、第１支払い金額と第２支払い金額とは、「第１支払い金額」＋「第２支払い金額」＝「決済要求情報の支払い金額」の条件を満たす任意の金額であり、限定ではなく例として、以下のようにして定めることができる。
・制限付き電子マネー残高を優先使用。
「第１支払い金額」＝「制限付き電子マネー残高」（「第２支払い金額」＝「決済要求情報の支払い金額」－「第１支払い金額」）
・通常電子マネー残高を優先使用。
「第２支払い金額」＝「通常電子マネー残高」（「第１支払い金額」＝「決済要求情報の支払い金額」－「第２支払い金額」）
・それぞれの残高の比率に合わせて使用。
「第１支払い金額」：「第２支払い金額」＝「制限付き電子マネー残高」：「通常電子マネー残高」
以下では、支払いに用いる残高の優先順位を「使用残高優先順位」と称する。

限定ではなく例として、図８－１では、自動的に制限付き電子マネー残高を優先使用する例が示されている。上記に示す第１支払い金額と第２支払い金額との算出方法は、限定ではなく例として、サーバ１０のユーザによって予め設定されプログラムされる。

第１支払い金額と第２支払い金額とが算出されると、サーバ１０の制御部１１は、連続制限付き決済処理を行う（Ｓ５１０）。連続制限付き決済処理において、サーバ１０の制御部１１は、限定ではなく例として、第１支払い金額に対して制限付き電子マネー残高を用いる制限付き決済処理を、第２支払い金額に対して通常電子マネー残高を用いる決済処理を、逐次的に実行する。

制限付き決済処理と決済処理とが成功する場合、連続制限付き決済処理は決済成功となる。
制限付き決済処理と決済処理とのうちの少なくとも一方が失敗する場合、連続制限付き決済処理は決済失敗（決済不可）となる。連続制限付き決済処理が失敗する場合、限定ではなく例として、制限付き決済処理または決済処理のうち、決済が成功した処理について、その処理を取り消し、残高を戻す。

なお、第１支払い金額＝「０」の場合、制限付き決済処理を実行しないようにしてもよい。また、第２支払い金額＝「０」の場合、決済処理を実行しないようにしてもよい。これらの場合、実行されない制限付き決済処理（決済処理）は成功したものとして取り扱う。

制限付き決済処理が実行される場合、限定ではなく例として、サーバ１０の制御部１１は、決済履歴管理データ１５７において、決済ＩＤを制限付き決済処理ごとに生成し、決済履歴管理データ１５７に追加するようにすることができる。この場合、決済履歴管理データ１５７の決済金額には、決済要求情報の支払い金額が記憶され、制限付き電子マネー使用履歴データの使用金額には、第１支払い金額が記憶される。

なお、サーバ１０の制御部１１は、決済履歴管理データ１５７において、決済ＩＤを制限付き決済処理と決済処理とで別々に生成し、決済履歴管理データ１５７に追加するようにしてもよい。この場合、決済履歴管理データ１５７上では、一回の決済要求情報の処理に対して二回の決済が実行されたように記録される。そのため、店舗への返品等による返金の場合には、２つの決済ＩＤを指定することが必要となる。

本フローチャートでは、説明の簡略化のため、制限付き電子マネーのうち、通知付き制限付き電子マネー残高と通知付き制限無し電子マネー残高とにおける通知の送信処理を省略して表記している。連続制限付き決済処理において、通知付き制限付き電子マネー残高または通知付き制限無し電子マネー残高が使用され通知を行う場合、サーバ１０の制御部１１は、限定ではなく例として、図７－６と同様に通知先アカウントの端末である端末２０Ｂに制限付き電子マネー使用情報を送信するようにしてもよい。端末２０Ｂの制御部２１は、限定ではなく例として、制限付き電子マネー使用情報を受信すると、受信した制限付き電子マネー使用情報を表示部２４に表示させるようにしてもよい。

また、本フローチャートに先立って、限定ではなく例として、端末２０Ａの制御部２１は、入出力部２３に対するユーザ入力等に基づいて、通常電子マネー残高をチャージするためのチャージ要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信するようにしてもよい。この場合、通信Ｉ／Ｆ１４によって端末２０Ａからチャージ要求情報を受信すると、サーバ１０の制御部１１は、受信したチャージ要求情報に基づいて、通常電子マネー残高を増加させるためのチャージ処理を実行するようにしてもよい。

＜第８実施例の効果＞
本実施例は、端末２０Ｂ（限定ではなく、第１情報処理装置の一例）と通信する端末２０Ａ（限定ではなく、情報処理装置の一例）によって実行されるプログラムであって、ユーザＢ．Ｂ（限定ではなく、第１情報処理装置のユーザの一例）によって通知を含む利用制限（限定ではなく、制限の一例）が設定され、第１情報処理装置から送金された制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）の第１支払い金額（限定ではなく、第１電子貨幣の少なくとも一部の一例）と、ユーザＡ．Ａ（限定ではなく、情報処理装置のユーザの一例）に関連付けられた通常電子マネー残高（限定ではなく、第２電子貨幣の一例）の第２支払い金額（限定ではなく、第２電子貨幣の少なくとも一部の一例）とに基づいて、連続制限付き決済処理を行うためのウォレットコード情報表示処理（限定ではなく、第１決済に関する処理の一例）を情報処理装置の制御部によって行うことが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報処理装置のユーザによって制限が設定され、第１情報処理装置から送金された第１電子貨幣の少なくとも一部と、情報処理装置のユーザに関連付けられた第２電子貨幣の少なくとも一部とに基づいて第１決済に関する処理が行われることで、限定ではなく例として、少なくとも制限が設定された第１電子貨幣を含む少なくとも２つの電子貨幣を用いた決済を実現することができる。

この例では、情報処理装置を、制限付き電子マネーの送金先アカウントのユーザの端末２０（限定ではなく例として、端末２０Ａ）とし、第１情報処理装置を、制限付き電子マネーの送金元アカウントの端末２０（限定ではなく例として、端末２０Ｂ）としている。
しかし、これに限定されず、限定ではなく例として、情報処理装置を、制限付き電子マネーの送金先アカウントのユーザの端末２０とし、第１情報処理装置を、サーバ１０とするなどすることも可能である。
なお、これら以外の組合せとすることも可能である。

また、本実施例は、第１電子貨幣と、第２電子貨幣とは、予め設定された（予めプログラムされた）条件（限定ではなく、設定された条件の一例）に基づいて選択される構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、設定された条件に基づいて、決済に使用する第１電子貨幣と第２電子貨幣とが適切に選択されるようにすることができる。

また、本実施例は、設定された条件は、制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第１情報処理装置のユーザによって制限が設定され、第１情報処理装置から送金された第１電子貨幣が優先的に決済に使用されるようにすることができる。

また、本実施例は、制限付き電子マネーに設定される制限は、支払いを行う端末２０のユーザが制限付き電子マネーを使用した場合に通知を行うことに関する制限、制限付き電子マネーを使用可能な店舗に関する制限、制限付き電子マネーを使用可能な商品またはサービスに関する制限、制限付き電子マネーを使用可能な商品またはサービスのカテゴリに関する制限、制限付き電子マネーを使用不可な商品に関する制限、制限付き電子マネーが使用できない時間帯に関する制限、制限付き電子マネーを使用できない日にち、制限付き電子マネーを使用できない日時に関する制限のうち少なくとも一つを含む構成を示している。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザが第１電子貨幣を使用した場合に第１情報処理装置のユーザに通知を行うことに関する制限、第１電子貨幣を使用可能な店舗に関する制限、第１電子貨幣を使用可能な商品またはサービスに関する制限、第１電子貨幣を使用可能な商品またはサービスのカテゴリに関する制限、第１電子貨幣を使用不可な商品に関する制限、第１電子貨幣が使用できない時間帯に関する制限、第１電子貨幣を使用できない日にちまたは日時に関する制限といった各種の制限が、第１情報処理装置のユーザによって第１電子貨幣に設定されるようにすることを可能とすることができ、第１情報処理装置のユーザの利便性を向上させることができる。

また、本実施例は、制限付き電子マネー送金処理（限定ではなく、端末２０Ｂ（限定ではなく、第１情報処理装置の一例）および端末２０Ａ（限定ではなく、第２情報処理装置の一例）と通信するサーバによって実行されるプログラムであって、第１情報処理装置のユーザによって制限が設定された、第１情報処理装置から第２情報処理装置に送金された制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）と、第２情報処理装置のユーザとを関連付ける処理の一例）と、チャージ処理（限定ではなく、通常電子マネー残高（限定ではなく、第２電子貨幣の一例）と第２情報処理装置のユーザとを関連付ける処理の一例）と、をサーバの制御部によって行うことと、ウォレット支払い要求情報（限定ではなく、第２情報処理装置から送信された情報の一例）に基づいて、第１電子貨幣の少なくとも一部と、第２電子貨幣の少なくとも一部とに基づく連続制限付き決済処理（限定ではなく、第１決済の一例）に関する処理を制御部によって実行することが前記サーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報処理装置のユーザによって制限が設定された、第１情報処理装置から第２情報処理装置に送金された第１電子貨幣と、第２情報処理装置のユーザとを関連付けるとともに、第２電子貨幣と第２情報処理装置のユーザとを関連付けた上で、第２情報処理装置から送信された情報に基づいて、第１電子貨幣の少なくとも一部と、第２電子貨幣の少なくとも一部とに基づく第１決済を実現することができる。

また、本実施例は、制限は、通知先アカウントへの通知（限定ではなく、第１電子貨幣の少なくとも一部を第２情報処理装置のユーザが使用した場合、第２情報処理装置のユーザが使用したことを示す通知をサーバの通信部によって第１情報処理装置に送信する制限の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣の少なくとも一部が第２情報処理装置のユーザによって使用された場合、それに関する内容を第１情報処理装置のユーザに知らせることができる。

＜第８変形例（１）＞
上記の実施例では、制限付き電子マネー残高と通常電子マネー残高とが自動的に両方使用される例を示したが、これに限定されない。
限定ではなく例として、支払いを行う端末２０のユーザによる入力に基づいて、使用する電子マネー（残高）が決定されるようにしてもよい。

図８－４は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図８－４左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、図８－１左側の画面と同様である。「コード支払い」アイコンＩＣ２がタップされると、図８－４中央のコード支払い画面が表示される。

このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１に表示される情報として、前述したように、制限付き電子マネー残高と通常電子マネー残高とを合算した残高（この例では「１，５００円」）が表示されている。また、その下には、制限付き電子マネーを支払いに使用するか否かを選択するためのスライドボタンが設けられている。スライドボタンを「ＯＮ」とすることで、制限付き電子マネーを支払いに使用するように設定することが可能に構成されている。また、スライドボタンを「ＯＦＦ」とすると、制限付き電子マネーが支払いに使用されないように設定することが可能に構成されている。

この例では、スライドボタンが「ＯＮ」とされた状態が示されている。この場合、図８－１と同様に、制限付き電子マネーが優先的に使用され、不足分が通常電子マネーから使用されるようにすることができる。これに基づいて決済処理が行われることで、図８－４右側の決済結果情報が表示される。

なお、この例とは異なり、スライドボタンを「ＯＮ」とすることで、通常電子マネーが優先的に使用されるようにしてもよい。この場合は、スライドボタンを「ＯＦＦ」とすると、制限付き電子マネーが支払いに使用されないように設定することができる。

図８－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
限定ではなく例として、端末２０Ａの制御部２１は、ウォレットコード情報を表示すると（Ａ１３０）、限定ではなく例として、入出力部２３に対するユーザ入力に基づいて、制限付き電子マネー残高と通常電子マネー残高とを使用するか否かの設定を含む制限付き電子マネー使用選択情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５１０）。

通信Ｉ／Ｆ１４によって端末２０Ａから制限付き電子マネー使用選択情報を受信すると、サーバ１０の制御部１１は、制限付き電子マネー使用選択情報に基づいて、使用残高算出処理を実行する（Ｓ５００）。そして、算出された第１支払い金額と第２支払い金額とに基づいて、連続制限付き決済処理を実行する（Ｓ５１０）。

使用残高算出処理において、限定ではなく例として、制限付き電子マネー残高のみを使用する場合は「第２支払い金額」＝「０」に、通常電子マネー残高のみを使用する場合は「第１支払い金額」＝「０」に、それぞれ設定することができる。

なお、サーバ１０の制御部１１は、端末２０Ａから制限付き電子マネー使用選択情報を受信しない場合、限定ではなく例として、サーバ１０のユーザによって予め設定された使用残高優先順位（使用比率）に基づいて、使用残高算出処理を実行し、連続制限付き決済処理を実行するようにしてもよいし、そうしなくてもよい。

また、制限付き電子マネー使用選択情報において、制限付き電子マネー残高または通常電子マネー残高を使用しないことが選択されることにより、連続制限付き決済処理が失敗する場合、サーバ１０の制御部１１は、両方の残高を用いて決済を再実行するか否かを確認するための制限付き電子マネー使用確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。端末２０Ａの制御部２１は、サーバ１０から制限付き電子マネー使用確認情報を受信すると、入出力部２３に対するユーザ入力等に基づいて、制限付き電子マネー残高と通常電子マネー残高とを用いて決済を再実行することが選択される場合、再度制限付き電子マネー使用選択情報をサーバ１０に送信するようにしてもよい。その後、サーバ１０の制御部１１は、再送された制限付き電子マネー使用選択情報に基づいて、使用残高算出処理と連続制限付き決済処理とを再度実行するようにしてもよい。

また、支払いに使用する残高の選択は、支払い都度選択することに限定されない。限定ではなく例として、支払いに先立って予め、端末２０Ａの制御部２１は、入出力部２３に対するユーザ入力等に基づいて、制限付き電子マネー残高と通常電子マネー残高とのうち、どの残高を支払いに使用するかに関する規定設定を受け付ける。そして、規定設定受け付け後の支払いにおいて、限定ではなく例として、端末２０Ａの制御部２１はウォレットコード情報を表示すると（Ａ１３０）、端末２０Ａの制御部２１は、設定された規定設定を制限付き電子マネー使用選択情報としてサーバ１０に送信するようにしてもよい。

本変形例は、制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）と、通常電子マネー残高（限定ではなく、第２電子貨幣の一例）とは、端末２０Ａ（限定ではなく、情報処理装置の一例）のユーザによる入力に基づいて、選択される構成を示している。
このような構成により得られる実施例の効果の一例として、決済に使用する第１電子貨幣と、第２電子貨幣とを情報処理装置のユーザに選択させることが可能となり、情報処理装置のユーザの利便性を向上させることができる。

＜第８変形例（２）＞
上記の実施例では、第１支払い金額と第２支払い金額とは、限定ではなく例として、予めサーバ１０のユーザによって設定された使用残高優先順位に従って決定されたが、これに限定されない。
限定ではなく例として、使用残高優先順位は、支払いを行う端末２０のユーザによる入力に基づいて、決定されるようにしてもよい。

図８－６は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図８－６左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、「コード支払い」アイコンＩＣ２がタップされた状態が示されている。すると、図８－６中央のコード支払い画面が表示される。
このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１に表示される情報として、制限付き電子マネー残高（「制限付き」）と通常電子マネー残高（制限なし）とが別々に表示されており、制限付き電子マネー残高（「制限付き」）が上に、通常電子マネー残高（制限なし）がその下に表示されている。

限定ではなく例として、ユーザＡ．Ａが通常電子マネー残高の表示場所をタッチして制限付き電子マネー残高の表示場所の方向（この例では上方向）に向けてスライドさせる操作を行うと、図８－６右側に示すように、通常電子マネー残高の表示場所と制限付き電子マネー残高の表示場所とが入れ替わり、通常電子マネー残高が上に、制限付き電子マネー残高がその下に表示される。これにより、使用残高優先順位が入れ替わり、通常電子マネー残高が優先的に使用されるようになる。

なお、この例とは異なり、チェックボックス等を用いて、ユーザが優先的に使用する電子マネー残高を選択することができるようにしてもよい。

本変形例における処理は、限定ではなく例として、図８－５において、端末２０Ａの制御部２１はウォレットコード情報を表示すると（Ａ１３０）、限定ではなく例として、入出力部２３に対するユーザ入力に基づいて、制限付き電子マネー残高と通常電子マネー残高とにおける使用残高優先順位に関する設定を含む制限付き電子マネー使用選択情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５１０）。なお、制限付き電子マネー使用選択情報は、それぞれの残高の使用比率に関する情報を含むようにしてもよい。
通信Ｉ／Ｆ１４によって端末２０Ａから制限付き電子マネー使用選択情報を受信すると、サーバ１０の制御部１１は、制限付き電子マネー使用選択情報の使用残高優先順位（使用比率）に基づいて、使用残高算出処理を実行し（Ｓ５００）、連続制限付き決済処理を実行する（Ｓ５１０）。なお、サーバ１０の制御部１１は、端末２０Ａから制限付き電子マネー使用選択情報を受信しない場合、限定ではなく例として、サーバ１０のユーザによって予め設定された使用残高優先順位（使用比率）に基づいて、使用残高算出処理を実行し、連続制限付き決済処理を実行するようにしてもよいし、そうしなくてもよい。

なお、連続制限付き決済処理が失敗する場合、サーバ１０の制御部１１は、異なる第１支払い金額と第２支払い金額とで決済を再実行するか否かを確認するための制限付き電子マネー使用確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよい。端末２０Ａの制御部２１は、サーバ１０から制限付き電子マネー使用確認情報を受信すると、入出力部２３に対するユーザ入力等に基づいて、異なる第１支払い金額と第２支払い金額を設定して決済を再実行することが選択される場合、再度制限付き電子マネー使用選択情報をサーバ１０に送信するようにしてもよい。その後、サーバ１０の制御部１１は、再送された制限付き電子マネー使用選択情報に基づいて、使用残高算出処理と連続制限付き決済処理とを再度実行するようにしてもよい。

また、使用残高優先順位は、支払い都度選択することに限定されない。限定ではなく例として、限定ではなく例として、支払いに先立って予め、端末２０Ａの制御部２１は、入出力部２３に対するユーザ入力等に基づいて、制限付き電子マネー残高と通常電子マネー残高との使用残高優先順位に関する規定設定を受け付ける。そして、規定設定受け付け後の支払いにおいて、限定ではなく例として、端末２０Ａの制御部２１はウォレットコード情報を表示すると（Ａ１３０）、端末２０Ａの制御部２１は、設定された規定設定を制限付き電子マネー使用選択情報としてサーバ１０に送信するようにしてもよい。

本変形例は、設定された条件は、支払いを行う端末２０のユーザによって設定された条件である構成を示している。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザの意向を反映した条件に基づいて、決済に使用する第１電子貨幣と第２電子貨幣とが選択されるようにすることができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された条件は、制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣から決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された条件は、支払いを行う端末２０（限定ではなく、情報処理装置の一例）のユーザによって設定された順序で使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された順序で使用することに関する条件は、制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から順に使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。

＜第８変形例（３）＞
上記の実施例では、サーバ１０は、連続制限付き決済処理の実行後、使用された制限付き電子マネー残高と通常電子マネー残高とを含む決済結果情報を端末２０Ａに送信していたが、これに限定されない。
限定ではなく例として、連続制限付き決済処理において、サーバ１０の制御部１１は、第１支払い金額と第２支払い金額とが定まると、端末２０Ａに第１支払い金額と第２支払い金額とを送信するようにしてもよい。

図８－７は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図８－７左側のコード支払い画面において、ウォレットコード情報表示領域ＷＣＲ１に表示されているウォレットコード情報が店舗のコードリーダによって読み取られると、図８－７中央の表示がなされる。

この例では、ウォレットコード情報表示領域ＷＣＲ１の一部に重畳するように、サーバ１０から送信された制限付き電子マネー使用確認情報が表示されている。
この例では、限定ではなく例として、支払い先や支払い金額の他、第１支払い金額を含む制限付き電子マネー使用確認情報が端末２０Ａに送信される。その結果、限定ではなく例として、支払い先（この例では「ＸＸ書店」）と、支払い金額（この例では「１，２００円」）と、第１支払い金額（この例では制限付き電子マネーの「１，０００円」）とを含む制限付き電子マネー使用確認情報が表示されている。

また、この例では、制限付き電子マネー使用確認情報には、第１支払い金額の使用に同意するための「支払う」ボタンＢＴ８１と、第１支払い金額の使用を拒否するための「やめる」ボタンＢＴ８２とが含まれる。

限定ではなく例として「支払う」ボタンＢＴ８１がタップされると、サーバ１０によって連続制限付き決済処理が実行され、図８－７右側の決済結果情報が表示される。具体的には、制限付き電子マネーが優先的に使用され、制限付き電子マネーから第１支払い金額（この例では「１，０００円」）が、通常電子マネーから第２支払い金額（この例では「２００円」）が決済されたことが示されている。

なお、この例では、図８－７中央の画面において、支払い金額のうちの第１支払い金額のみが表示されることとしたが、これに限定されない。
具体的には、限定ではなく例として、第１支払い金額と第２支払い金額との両方の金額を表示させるようにしてもよい。この場合、サーバ１０は、第１支払い金額と第２支払い金額とを含む制限付き電子マネー使用確認情報を端末２０Ａに送信するようにすることができる。

図８－８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
通信Ｉ／Ｆ１４によって店舗ＰＯＳシステム４０から決済要求情報を受信すると、サーバ１０の制御部１１は、第１支払い金額と第２支払い金額とを算出する（Ｓ５００）。そして、サーバ１０の制御部１１は、算出された第１支払い金額を少なくとも含む制限付き電子マネー使用確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。

通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー使用確認情報を受信すると、端末２０Ａの制御部２１は、第１支払い金額の使用に同意するか否かの確認用画面を表示部２４に表示させる（Ａ５２０）。限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、制限付き電子マネー残高から第１支払い金額を支出することに同意することが選択される場合（Ａ５２０：ＹＥＳ）、端末２０Ａの制御部２１は、制限付き電子マネー使用許諾情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５３０）。

通信Ｉ／Ｆ１４によって端末２０Ａから制限付き電子マネー使用許諾情報を受信する場合（Ｓ５３０：ＹＥＳ）、サーバ１０の制御部１１は、連続制限付き決済処理を実行する（Ｓ５１０）。制限付き電子マネー使用許諾情報を受信しない場合（Ｓ５３０：ＮＯ）、サーバ１０の制御部１１は、連続制限付き決済処理をスキップする。

制限付き電子マネー残高から第１支払い金額を支出することに同意することが選択されない場合（Ａ５２０：ＮＯ）、端末２０Ａの制御部２１は、Ａ５３０のステップをスキップする。

なお、制限付き電子マネー残高から第１支払い金額を支出することに同意することが選択されない場合（Ａ５２０：ＮＯ）、端末２０Ａの制御部２１は、限定ではなく例として、入出力部２３に対するユーザ入力等に基づいて、第１支払い金額と第２支払い金額とを受け付けると、第１支払い金額と第２支払い金額とを通信Ｉ／Ｆ２２によってサーバ１０に送信する。サーバ１０の制御部１１は、端末２０Ａから第１支払い金額と第２支払い金額とを受信すると、受信した第１支払い金額と第２支払い金額とに基づいて、連続制限付き決済処理を実行するようにしてもよい。

＜第８変形例（４）＞
本変形例は、通知先アカウントへの通知内容に関する変形例である。
図８－９は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図８－９左側には、端末２０Ａの表示部２４に決済結果情報が表示された状態が示されている。この例では、制限付き電子マネー残高からの第１支払い金額が「７００円」であり、通常電子マネー残高からの第２支払い金額が「５００円」であり、合計「１，２００円」の決済が行われたことが示されている。

図８－９右側は、この場合に端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
この例では、制限付き電子マネー送金結果情報ＲＲ８１の下に、制限付き電子マネー使用情報ＲＵ８１が表示されている。この電子マネー使用情報では、ユーザＢ．ＢがユーザＡ．Ａに送金した制限付き電子マネー残高のうちの支払いに使用された金額（つまり第１支払い金額）を含む情報が表示されている。
具体的には、制限付き電子マネー残高から使用された金額（この例では「７００円」）と、支払い先（この例では「ＸＸ書店」）と、詳細確認ボタンとを含む情報が表示されている。

なお、これとは異なり、電子マネー使用情報において、支払い金額（第１支払い金額と第２支払い金額とを合算した金額）を表示させるようにしてもよい。

＜第９実施例＞
前述の実施例では、連続制限付き決済処理において、通常電子マネー残高と制限付き電子マネー残高とを用いて決済を行っていた。
第９実施例は、２以上の制限付き電子マネー残高のうちの任意の２以上の残高を用いて決済を行う実施例である。

第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

図９－１は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｈの一例を示す図である。
アカウント管理データベース１５５Ｈに含まれる各々のアカウント管理データには、アプリケーションＩＤと、通常電子マネー残高との他に、限定ではなく例として、制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。
アカウント管理データベース１５５Ｈに含まれる各々のアカウント管理データに記憶される情報は、アカウント管理データベース１５５Ｆと同様であるが、電子マネー使用制限管理データに記憶される情報が一部異なっている。

具体的には、電子マネー使用制限管理データには、限定ではなく例として、送金管理ＩＤと、使用可能店舗業種とが関連付けて記憶される。

使用可能店舗業種は、この制限付き電子マネー残高の使用が可能である業種・業態を記憶するための項目であり、限定ではなく例として、送金者による入力に基づいて設定され、記憶される。
図９－１では、限定ではなく例として、送金管理ＩＤ「Ｔ０２１０８」で管理される制限付き電子マネー残高は、「コンビニ」、「スーパー・ホームセンター」、「書籍・文具」の業種に分類される店舗・サービスで使用できることが記憶されている。また、送金管理ＩＤ「Ｔ０２５７１」で管理される制限付き電子マネー残高は、「書籍・文具」、「家具・家電」の業種に分類される店舗・サービスで使用できることが記憶されている。

＜表示画面＞
図９－２～図９－３は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図９－２左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、残高領域領域には電子マネー残高として「６，５００円」が表示されている。また、その内訳は、通常電子マネー残高が「２，５００円」であり、制限付き電子マネー残高が「４，０００円」であることが示されている。

また、制限付き電子マネー残高の左側には、その内訳を表示するためのボタンが表示されており、このボタンがタップされると、図９－２中央の表示がなされる。
具体的には、制限付き電子マネー残高の表示部分の下に、制限付き電子マネー残高の内訳が表示される。この例では、制限付き電子マネー残高「４，０００円」の内訳は、通知先アカウントのユーザをユーザＢ．Ｂとする「１，０００円」と、通知先アカウントのユーザをユーザＣ．Ｃとする「３，０００円」とであることが示されている。

図９－２中央の画面に示すように、通知先アカウントのユーザをユーザＣ．Ｃとする「３，０００円」の残高に関連付けて表示された制限マークＲＭＫがタップされると、限定ではなく例として、制限に関する情報が吹き出しで表示される。この例では、この制限付き電子マネーの使用が可能である店舗の業種がアイコンで表示されている。具体的には、「書籍・文具」のアイコンと、「家具・家電」のアイコンとが吹き出し内に表示され、これら２つの業種の店舗では、通知先アカウントのユーザをユーザＣ．Ｃとする制限付き電子マネーの使用が可能であることが示されている。

一方、図９－２右側の画面に示すように、通知先アカウントのユーザをユーザＢ．Ｂとする「１，０００円」の残高に関連付けて表示された制限マークＲＭＫがタップされると、限定ではなく例として、制限に関する情報が吹き出しで表示される。この例では、この制限付き電子マネーの使用が可能である店舗の業種がアイコンで表示されている。具体的には、「コンビニ」のアイコンと、「スーパー・ホームセンター」のアイコンと、「書籍・文具」のアイコンとが吹き出し内に表示され、これら３つの業種の店舗では、通知先アカウントのユーザをユーザＢ．Ｂとする制限付き電子マネーの使用が可能であることが示されている。

図９－３左側は、図９－２左側の画面に対応しており、「コード支払い」アイコンＩＣ２がタップされた状態が示されている。すると、限定ではなく例として、図９－３中央のコード支払い画面が表示される。
このコード支払い画面では、ウォレットコード情報表示領域ＷＣＲ１に、図９－２左側の画面の残高表示領域ＢＲ２に表示されていた表示と同様の残高表示がなされている。ウォレットコード情報を店舗のコードリーダによって読み取ってもらうことで、サーバ１０によって連続制限付き決済処理が実行され、図９－３右側の決済結果情報が表示される。

具体的には、通知先アカウントがユーザＢ．Ｂのアカウントである制限付き電子マネーから「１，０００円」が支払いに使用され、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーから「２００円」が支払いに使用されたことが示されている。

なお、この例では、通知先アカウントがユーザＢ．Ｂのアカウントである制限付き電子マネーと、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーとの両方が支払いに使用されている。このため、サーバ１０によって、制限付き電子マネー使用情報が、端末２０Ｂおよび端末２０Ｃにそれぞれ送信される。

＜処理＞
処理については、限定ではなく例として、図８－２～図８－３における使用残高算出処理（Ｓ５００）において、サーバ１０の制御部１１は、決済要求情報の支払い金額のうち、第１制限付き電子マネー残高から支払いを行う第３支払い金額と、第２制限付き電子マネー残高から支払いを行う第４支払い金額とを算出する。
限定ではなく例として、図９－１では、送金管理ＩＤ「Ｔ０２１０８」の残高を第１制限付き電子マネー残高に、送金管理ＩＤ「Ｔ０２５７１」の残高を第２制限付き電子マネー残高に、それぞれ当てはめることができる。

ここで、第３支払い金額と、第４支払い金額とは、「第３支払い金額」＋「第４支払い金額」＝「決済要求情報の支払い金額」の条件を満たす任意の金額である。ただし、限定ではなく例として、サーバ１０が受信した決済要求情報に基づいて、各制限付き電子マネー残高の使用制限を判定し、各制限付き電子マネー残高が使用できない場合には、その支払い金額を「０」とする。すなわち、第１制限付き電子マネー残高の使用制限に該当しその残高が使用不能である場合、「第３支払い金額」＝「０」となり、第２制限付き電子マネー残高の使用制限に該当しその残高が使用不能である場合、「第４支払い金額」＝「０」となる。

第１制限付き電子マネー残高と第２制限付き電子マネー残高とが使用可能である場合、第３支払い金額と、第４支払い金額とは、限定ではなく例として、以下の使用残高優先順位に従って定めることができる。
・残高が多い制限付き電子マネー残高を優先して使用。
・残高が少ない制限付き電子マネー残高を優先して使用。
・受け取った順序が古い制限付き電子マネー残高を優先して使用。
・使用可能な制限付き電子マネー残高の制限が厳しい順に使用。
・上記の任意の組み合わせ。

限定ではなく例として、第１制限付き電子マネー残高と、第２制限付き電子マネー残高とにおいて、第２制限付き電子マネー残高の制限に比べて第１制限付き電子マネー残高の制限が厳しい場合として、以下の例が挙げられる。
・第１制限付き電子マネー残高の使用通知先の人数＞第２制限付き電子マネー残高の使用通知先の人数（通知先人数が多い）。
・第１制限付き電子マネー残高の使用可能店舗・サービス業者数＜第２制限付き電子マネー残高の使用可能店舗・サービス業者数（使える店舗・サービス業者が少ない）。
・第１制限付き電子マネー残高の使用可能店舗業種数＜第２制限付き電子マネー残高の使用可能店舗業種数（使用可能な業種が狭い）。
・第１制限付き電子マネー残高の使用可能商品・サービス数＜第２制限付き電子マネー残高の使用可能商品・サービス数（購入可能な商品・サービスが少ない）。
・第１制限付き電子マネー残高の使用可能期限＜第２制限付き電子マネー残高の使用可能期限（使用不能になる期限が迫っている）。
・第１制限付き電子マネー残高の使用可能位置領域＜第２制限付き電子マネー残高の使用可能位置領域（使用可能な地図範囲が狭い）。
・所定の時間内（限定ではなく例として、一週間）における第１制限付き電子マネー残高の使用可能時間＜所定の時間内における第２制限付き電子マネー残高の使用可能時間（使用可能な時間帯が少ない）。
・所定の期間内（限定ではなく例として、１ヵ月間）における第１制限付き電子マネー残高の使用可能日数＜所定の期間内における第２制限付き電子マネー残高の使用可能日数（使用可能な日時が少ない）。
・上記の任意の組み合わせ。

第３支払い金額と第４支払い金額とが算出されると、サーバ１０の制御部１１は、連続制限付き決済処理を行う（Ｓ５１０）。連続制限付き決済処理において、サーバ１０の制御部１１は、限定ではなく例として、第３支払い金額に対して第１制限付き電子マネー残高を用いる制限付き決済処理を、第４支払い金額に対して第２制限付き電子マネー残高を用いる制限付き決済処理を、逐次的に実行する。

両方の制限付き決済処理が成功する場合、連続制限付き決済処理は決済成功となる。
制限付き決済処理の少なくとも一方が失敗する場合、連続制限付き決済処理は決済失敗（決済不可）となる。連続制限付き決済処理が失敗する場合、限定ではなく例として、制限付き決済処理のうち、決済が成功した処理について、その処理を取り消し、残高を戻す。
なお、第３支払い金額＝「０」の場合、第１制限付き電子マネー残高を用いる制限付き決済処理を実行しないようにしてもよい。また、第４支払い金額＝「０」の場合、第２制限付き電子マネー残高を用いる制限付き決済処理を実行しないようにしてもよい。これらの場合、実行されない制限付き決済処理は成功したものとして取り扱う。

なお、連続制限付き決済処理において、第１制限付き電子マネー残高と、第２制限付き電子マネー残高とに加えて、通常電子マネー残高を用いるようにしてもよい。限定ではなく例として、「第３支払い金額」＋「第４支払い金額」＜「決済要求情報の支払い金額」であるとする。使用残高優先順位として、制限付き電子マネー残高が通常電子マネー残高に優先して使用される場合、使用残高算出処理において、通常電子マネー残高から支払いを行う第２支払い金額は、「第２支払い金額」＝「決済要求情報の支払い金額」－「第３支払い金額」－「第４支払い金額」で算出することができる。なお、通常電子マネー残高は制限付き電子マネー残高に優先して使用されるようにしてもよい。

また、本実施例では、説明の簡略化のため制限付き電子マネー管理データに記憶される送金管理ＩＤが２つの場合について説明したが、これに限定されない。限定ではなく例として、制限付き電子マネー管理データに記憶される送金管理ＩＤが３以上の場合においても本実施例と同様に制限付き電子マネー残高の使用残高優先順位を設定することで取り扱うことができる。

＜第９実施例の効果＞
本実施例は、第１制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）と、第２制限付き電子マネー残高（限定ではなく、第２電子貨幣の一例）とは、残高が少ない制限付き電子マネー残高を優先して使用すること（限定ではなく、設定された条件の一例）に基づいて選択される構成を示している。
このような構成により得られる実施例の効果の一例として、設定された条件に基づいて、決済に使用される第１電子貨幣と第２電子貨幣とが適切に選択されるようにすることができる。

また、本実施例は、設定された条件は、第１制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。

また、本実施例は、制限が設定された電子貨幣から使用することに関する条件は、制限が厳しい電子貨幣から使用することを含む構成を示している。
このような構成により得られる実施例の効果の一例として、制限が厳しい電子貨幣が優先的に決済に使用されるようにすることができる。

また、本実施例は、制限が厳しい電子貨幣から使用することは、電子貨幣の残高が少ないこと、または使用可能なカテゴリが狭いことを少なくとも含む構成を示している。
このような構成により得られる実施例の効果の一例として、残高が少ない電子貨幣や使用可能なカテゴリが狭い電子貨幣が優先的に決済に使用されるようにすることができる。

＜第９変形例（１）＞
上記の実施例では、使用残高算出処理が実行されると、連続制限付き決済処理が実行されるとしたが、これに限定されない。
限定ではなく例として、使用残高算出処理が実行されると、サーバ１０の制御部１１は、第３支払い金額と第４支払い金額とを端末２０Ａに送信するようにしてもよい。

図９－４は、本変形例における端末２０の表示部２４に表示される画面の別例を示す図である。
図９－４左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのコード支払い画面であり、図９－３中央の画面に対応するものである。
ウォレットコード情報が店舗のコードリーダによって読み取られると、図９－４中央のような表示がなされる。

具体的には、ウォレットコード情報表示領域ＷＣＲ１の一部に重畳するように、サーバ１０から送信された制限付き電子マネー使用確認情報が表示されている。
この例では、限定ではなく例として、支払い先（この例では「ＹＹカメラ」）や支払い金額（この例では「３，８００円」）の他、支払いに使用する制限付き電子マネーに関する情報が表示されている。

この例では、制限付き電子マネーには、通知先アカウントがユーザＢ．Ｂのアカウントである制限付き電子マネーと、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーとがあるが、支払い先が「ＹＹカメラ」であり、店舗の業種は「家具・家電」である。このため、「家具・家電」の業種で使用することが許可されている制限付き電子マネーが支払いを行う制限付き電子マネーとして選択される。その結果、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーが選択され、これを使用して支払いを行うことをユーザＡ．Ａに確認するための情報が表示されている。

限定ではなく例として「支払う」ボタンＢＴ８１がタップされると、サーバ１０によって連続制限付き決済処理が実行され、図９－４右側の決済結果情報が表示される。具体的には、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーから「１３，０００円」が支払いに使用され、不足分の金額である「８００円」が通常電子マネーから支払いに使用されたことが示されている。

なお、この例では、図９－４中央の画面において、制限付き電子マネー使用確認情報において、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーから支払いに使用される金額（この例では「３，０００円」）のみを表示させることとしたが、これに限定されない。
この他にも、上記の例において、通常電子マネーから支払いに使用される金額「８００円」を併せて表示させるようにしてもよい。
さらに、上記の例において、支払いに使用されない制限付き電子マネー、つまり通知先アカウントがユーザＢ．Ｂのアカウントである制限付き電子マネーの支払い金額「０円」も併せて表示させるようにしてもよい。

処理については、限定ではなく例として、図８－８において、サーバ１０の制御部１１は、算出された第３支払い金額および／または第４支払い金額を含む制限付き電子マネー使用確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。そして、限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、制限付き電子マネー残高から第３支払い金額および／または第４支払い金額を支出することに同意することが選択される場合、端末２０Ａの制御部２１は、制限付き電子マネー使用許諾情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
なお、制限付き電子マネー使用確認情報として、通常電子マネー残高の使用分である第２支払い金額を含むようにしてもよい。

＜第９変形例（２）＞
上記の実施例では、使用残高算出処理において、自動的に各支払い金額を算出していたが、これに限定されない。
限定ではなく例として、支払いを行う端末２０のユーザによる入力に基づいて、各支払い金額が算出されるようにしてもよい。

本変形例における処理は、限定ではなく例として、図８－５において、限定ではなく例として、入出力部２３に対するユーザ入力に基づいて、各制限付き電子マネー残高と通常電子マネー残高とにおける使用残高優先順位に関する設定を含む制限付き電子マネー使用選択情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、サーバ１０の制御部１１は、残高使用順位に基づいて、使用残高算出処理を実行する。
なお、制限付き電子マネー使用選択情報には、支払いに用いる制限付き電子マネー残高（通常電子マネー残高）を指定する情報を含めるようにしてもよい。

なお、制限付き電子マネー使用選択情報における使用残高優先順位としては、限定ではなく例として、以下のような例が挙げられる。
・送金管理ＩＤごとに残高使用順位を指定
（限定ではなく例として、残高表示欄に対するユーザ操作に基づいて、送金管理ＩＤ「Ｔ０２５７１」の残高＞送金管理ＩＤ「Ｔ０２１０８」の残高＞「通常電子マネー残高」の残高使用順位を指定。）
・残高が少ない（多い）順に使用することを指定。
・受け取った順序が古い順に制限付き電子マネー残高を使用することを指定。
・各支払い金額を直接指定
（限定ではなく例として、決済要求情報の支払い金額が「１５００円」の場合、第３支払い金額＝「１０００円」、第４支払い金額＝「５００円」と指定。）
・それぞれの残高の比率に合わせて使用することを指定。

本変形例は、設定された条件は、支払いを行う端末２０のユーザによって設定された順序で使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された順序で使用することに関する条件は、制限が設定された電子貨幣から順に使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができ、情報処理装置のユーザの意に則した決済を実現することができる。

＜第９変形例（３）＞
上記の実施例では、サーバ１０において使用残高算出処理を実行することとしたが、これに限定されない。限定ではなく例として、使用残高算出処理の一部または全部の処理を端末２０において実行するようにしてもよい。

限定ではなく例として、使用残高算出処理は、使用残高選択処理と、支払い金額算出処理とに大別することができる。
使用残高算出処理は、１以上の制限付き電子マネー残高と、通常電子マネー残高とのうち、支払いに用いる残高を選択する処理である。また、支払い金額算出処理は、選択された残高について使用残高優先順位を設定し、各残高から支払う金額を算出する処理である。

図９－５は、使用残高選択処理における処理方法の一例を示す図である。

選択パターン「都度残高選択」では、端末２０の制御部２１は、支払いを行う都度、限定ではなく例として、表示部２４に表示される各残高と対応するチェックボックスに対する選択に基づいて、ユーザが支払いに用いる残高を選択する。

選択パターン「規定残高選択（１）」では、端末２０の制御部２１は、支払いを行う前に、限定ではなく例として、表示部２４に表示される各残高と対応するチェックボックスに対する選択に基づいて、ユーザが支払いに用いる残高選択の規定設定（以下、「残高選択規定設定」と称する。）を設定する。そして、支払いを行う際に、端末２０の制御部２１は、残高選択規定設定に基づいて、ユーザが支払いに用いる残高を選択する。

選択パターン「規定残高選択（２）」では、端末２０の制御部２１は、規定残高選択（１）と同様に残高選択規定設定を設定すると、残高選択規定設定を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、支払いを行う際に、サーバ１０の制御部１１は、受信した残高選択規定設定に基づいて、ユーザが支払いに用いる残高を選択する。

選択パターン「全選択」は、全ての残高を用いることがシステムによって選択されるパターンである。この場合、使用残高選択処理は実行されないこととしてもよい。

図９－６は、使用残高優先順位設定処理における処理方法の一例を示す図である。

処理パターン「全自動処理（１）」では、サーバ１０の制御部１１は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。
処理パターン「全自動処理（２）」では、端末２０の制御部２１は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。
全自動処理は、支払いを行う端末２０のユーザ意思が介在しない処理である。

処理パターン「サジェスト処理（１）」では、サーバ１０の制御部１１は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。そして、算出された各支払い金額に対して端末２０のユーザが承認を行うと、連続制限付き決済処理が実行される。
処理パターン「サジェスト処理（２）」では、端末２０の制御部２１は、規定されたシステム設定に従って、使用残高優先順位を設定し、各残高から支払う金額を算出する。そして、算出された各支払い金額に対して端末２０のユーザが承認を行うと、連続制限付き決済処理が実行される。
サジェスト処理は、システムが決定した各支払い金額に対して端末２０のユーザが承認を行う処理である。

処理パターン「規定設定処理（１）」では、限定ではなく例として、支払いに先立って、端末２０に対するユーザ操作に基づいて、規定の使用残高優先順位が設定される。そして、サーバ１０の制御部１１は、規定の使用残高優先順位に基づいて、各残高から支払う金額を算出する。
処理パターン「規定設定処理（２）」では、限定ではなく例として、支払いに先立って、端末２０に対するユーザ操作に基づいて、規定の使用残高優先順位が設定される。そして、端末２０の制御部２１は、規定の使用残高優先順位に基づいて、各残高から支払う金額を算出する。
規定設定処理は、端末２０のユーザによって支払い前に設定された規定の使用残高優先順位に基づいて、各支払い金額が算出される処理である。

処理パターン「規定確認処理（１）」では、「規定設定処理（１）」で算出された各支払い金額に対して、連続制限付き決済処理の実行前に端末２０のユーザが承認を行う。
処理パターン「規定確認処理（２）」では、「規定設定処理（２）」で算出された各支払い金額に対して、連続制限付き決済処理の実行前に端末２０のユーザが承認を行う。

処理パターン「都度設定処理（１）」では、支払いを行う都度、端末２０に対するユーザ操作に基づいて、使用残高優先順位が設定される。そして、サーバ１０の制御部１１は、設定された使用残高優先順位に基づいて、各残高から支払う金額を算出する。
処理パターン「都度設定処理（２）」では、支払いを行う都度、端末２０に対するユーザ操作に基づいて、使用残高優先順位が設定される。そして、端末２０の制御部２１は、設定された使用残高優先順位に基づいて、各残高から支払う金額を算出する。
都度設定処理は、支払いを行う都度、端末２０のユーザによって使用残高優先順位が設定され、各支払い金額が算出される処理である。

本変形例は、設定された条件は、支払いを行う端末２０のユーザによって設定された条件である構成を示している。
このような構成により得られる変形例の効果の一例として、情報処理装置のユーザの意向を反映した条件に基づいて、決済に使用する第１電子貨幣と第２電子貨幣とが選択されるようにすることができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された条件は、制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から使用することに関する条件を含む構成を示している。
このような構成により得られる変形例の効果の一例として、制限が設定された電子貨幣から決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。

また、本変形例は、制限が設定された電子貨幣から使用することに関する条件は、制限が厳しい電子貨幣から使用することを含む構成を示している。
このような構成により得られる変形例の効果の一例として、制限が厳しい電子貨幣が優先的に決済に使用されるようにすることができる。

また、本変形例は、制限が厳しい電子貨幣から使用することは、電子貨幣の残高が少ないこと、または使用可能なカテゴリが狭いことを少なくとも含む構成を示している。
このような構成により得られる変形例の効果の一例として、残高が少ない電子貨幣や使用可能なカテゴリが狭い電子貨幣が優先的に決済に使用されるようにすることができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された条件は、支払いを行う端末２０（限定ではなく、情報処理装置の一例）のユーザによって設定された順序で使用することに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによって設定された順序で電子貨幣が決済に使用されるため、情報処理装置のユーザの意に則した決済を実現することができる。

また、本変形例は、支払いを行う端末２０のユーザによって設定された順序で使用することに関する条件は、制限付き電子マネー残高（限定ではなく、制限が設定された電子貨幣の一例）から順に使用することに関する条件を含む構成を示している。
このような構成により得られる変形例の効果の一例として、制限が設定された電子貨幣が優先的に決済に使用されるようにすることができる。

＜第９変形例（４）＞
上記の実施例では、複数の通知付き制限付き電子マネー残高（通知付き電子マネー残高）が使用されると、全ての通知先アカウントに通知することとしたが、これに限定されない。限定ではなく例として、通知先アカウントがユーザＢ．Ｂである制限付き電子マネー残高と、通知先アカウントがユーザＣ．Ｃである制限付き電子マネー残高とが使用されると、サーバ１０の制御部１１は、ユーザＢ．Ｂの端末２０ＢまたはユーザＣ．Ｃの端末２０Ｃのどちら一方のみに通知を送信するようにしてもよい。

なお、通知先アカウントに優先順位を設定し、サーバ１０の制御部１１は、優先順位が最も高い通知先アカウントの端末２０のみに通知を送信するようにしてもよい。サーバ１０の制御部１１は、優先順位が上位「Ｎ」番目（「Ｎ」は任意の自然数）までの通知先アカウントの端末２０に通知を送信するようにしてもよい。

また、支払いにおいて２以上の通知付き制限付き電子マネー残高（通知付き電子マネー残高）が使用され、通知先アカウントが複数にまたがる場合、サーバ１０の制御部１１は、通知を送信しないようにしてもよい。

＜第９変形例（５）＞
商品やサービスの返品時等において、返金が発生した場合、決済時に使用された複数の制限付き電子マネー残高または／および通常電子マネー残高に対して、返金される金額を決済時に使用された金額に基づいてそれぞれの残金に加算するようにしてもよい。

この場合、送金先アカウントのユーザにより使用された制限付き電子マネー（通常電子マネー）の少なくとも一部を返金する場合、サーバ１０の制御部１１は、店舗ＰＯＳシステム４０から送信される決済ＩＤを決済履歴管理データ１５７から特定する。これは、決済が行われたか否かを確認するとともに、その決済金額（返金金額）を特定するためである。

次いで、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｈのうち、送金先アカウントのユーザのアカウント管理データに含まれる制限知付き電子マネー使用履歴データを参照し、特定した決済ＩＤに対応する送金管理ＩＤを特定する。決済時に複数の制限付き電子マネーが使用された場合、この送金管理ＩＤは複数のＩＤを含むこととなる。

特定した決済ＩＤに対応する送金管理ＩＤが存在する場合は、制限付き電子マネーの少なくとも一部が決済に使用されたことになる。このため、制限付き電子マネー使用履歴データから、特定した決済ＩＤに対応する使用金額を特定し、その使用金額を、制限付き電子マネー管理データのうちの対応する送金管理ＩＤの制限付き電子マネー残高に加算する。特定した決済ＩＤに対応する送金管理ＩＤが複数存在する場合、それぞれの送金管理ＩＤに対して、上記の処理を繰り返す。

そして、サーバ１０の制御部１１は、特定した決済ＩＤに対応する送金管理ＩＤごとの使用金額の総和を算出する。この総和を「制限付き電子マネー決済金額」と呼称する。
サーバ１０の制御部１１は、制限付き電子マネー決済金額が、決済ＩＤに対応する決済金額と等しいか否かを判定する。制限付き電子マネー決済金額が決済金額と等しい場合、通常電子マネーは決済に使用されていない。そのため、サーバ１０の制御部１１は、処理を終了させる。
制限付き電子マネー決済金額が決済金額と等しくない場合、通常電子マネーも決済に使用されている。そのため、サーバ１０の制御部１１は、通常電子マネー残高に「決済金額」－「制限付き電子マネー決済金額」で算出される金額を加算する。

一方、特定した決済ＩＤに対応する送金管理ＩＤが存在しない場合は、制限付き電子マネーは決済に使用されなかったことになる。このため、通常電子マネー残高に返金金額を加算する。通常電子マネーのみを使って決済した場合は、決済履歴管理データ１５７のうちの特定した決済ＩＤに対応する決済金額が、通常電子マネー残高への返金金額となる。

＜第１０実施例＞
第１０実施例は、連続制限付き決済処理による支払い前に、制限付き電子マネー残高の制限を加味した、その支払いにおいて使用可能な合算残高を端末２０のユーザが確認可能とする実施例である。

第１０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図１０－１は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。ここで、制限付き電子マネー残高は図９－２と同様である。
図１０－１左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、端末２０Ａが店舗「ＸＸ書店」に位置している場合に表示される画面の一例である。
後述する手法に基づいて、サーバ１０から店舗「ＸＸ書店」に関する店舗紹介情報が端末２０Ａに送信され、その結果、画面下部に「ＸＸ書店へようこそ 春の参考書フェア実施中！」の文字を含む店舗紹介情報が表示されている。
また、残高表示領域には、店舗「ＸＸ書店」でユーザＡ．Ａが使用可能である制限付き電子マネー残高と、通常電子マネー残高との総和である使用可能合算残高が表示されている。

ここで、この例における電子マネー残高の内訳や制限の内容等は、第９実施例の図９－２で示したものと同じである。
具体的には、通常電子マネー残高は「２，５００円」であり、制限付き電子マネー残高は「４，０００円」である。
また、制限付き電子マネー残高のうち、通知先アカウントをユーザＣ．Ｃのアカウントとする制限付き電子マネーの残高は「３，０００円」であり、使用可能な店舗の業種として「書籍・文具」、「家具・家電」が設定されている。
また、制限付き電子マネー残高のうち、通知先アカウントをユーザＢ．Ｂのアカウントとする制限付き電子マネーの残高は「１，０００円」であり、使用可能な店舗の業種として「コンビニ」、「スーパー・ホームセンター」、「書籍・文具」が設定されている。

図１０－１左側の画面例は、端末２０Ａが店舗「ＸＸ書店」に位置している場合であるが、上記の２つの制限付き電子マネーは両方とも「書店・文具」の業種の店舗で使用可能とされているため、全額が使用可能である。
このため、残高表示領域には、通常電子マネー残高と、制限付き電子マネー残高の全額とを合算した「２，５００円＋４，０００円＝６，５００円」が使用可能合算残高として表示されている。

一方、図１０－１中央の画面は、端末２０Ａが店舗「ＭＭスーパー」に位置している場合のメインメニュー画面の一例を示す図である。
上記の２つの制限付き電子マネーのうち「スーパー・ホームセンター」の業種の店舗で使用可能な制限付き電子マネーは、通知先アカウントをユーザＢ．Ｂのアカウントとする制限付き電子マネーのみである。
このため、残高表示領域には、通常電子マネー残高と、通知先アカウントをユーザＢ．Ｂのアカウントとする制限付き電子マネーの残高とを合算した「２，５００円＋１０００円＝３，５００円」が使用可能合算残高として表示されている。

一方、図１０－１右側の画面は、端末２０Ａが店舗「ＹＹカメラ」に位置している場合のメインメニュー画面の一例を示す図である。
上記の２つの制限付き電子マネーのうち「家具・家電」の業種の店舗で使用可能な制限付き電子マネーは、通知先アカウントをユーザＣ．Ｃのアカウントとする制限付き電子マネーのみである。
このため、残高表示領域には、通常電子マネー残高と、通知先アカウントをユーザＣ．Ｃのアカウントとする制限付き電子マネーの残高とを合算した「２，５００円＋３０００円＝５，５００円」が使用可能合算残高として表示されている。

＜処理＞
処理については、限定ではなく例として、図８－２において、端末２０Ａの制御部２１は、制限付き電子マネー送金結果情報を表示部２４に表示させると（Ａ４１０）、使用可能合算残高要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。ここで、使用可能合算残高要求情報には、限定ではなく例として、店舗に設置された不図示のビーコン装置から受信したビーコン信号や、位置算出用情報検出部２９Ｂによって取得された位置算出用情報に基づく、限定ではなく例として、緯度・経度・高度で示される端末２０Ａの位置情報を含めるようにしてもよい。

通信Ｉ／Ｆ１４によって端末２０Ａから使用可能合算残高要求情報を受信すると、サーバ１０の制御部１１は、使用可能合算残高算出処理を実行する。
使用可能合算残高算出処理において、限定ではなく例として、まず、サーバ１０の制御部１１は、受信した使用可能合算残高要求情報に基づいて、端末２０Ａの存在する店舗を判定する。そして、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｈの電子マネー使用制限管理データを参照し、制限付き電子マネー管理データに記憶される各制限付き電子マネー残高が使用可能か否かを判定する。そして、使用可能である制限付き電子マネー残高と、通常電子マネー残高との総和である使用可能合算残高を含む使用可能合算残高情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。
なお、使用可能合算残高情報に、個別の使用可能であると判定された制限付き電子マネー残高を含めるようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から使用可能合算残高情報を受信すると、端末２０Ａの制御部２１は、受信した使用可能合算残高情報を表示部２４に表示させる。

なお、電子マネー使用制限管理データとして、制限付き電子マネー残高が使用可能な日時・時間帯・使用期限が設定されている場合、使用可能合算残高算出処理において、サーバ１０の制御部１１は、時計部１９によって現在日時を取得し、各制限付き電子マネー残高が使用可能か否かを判定するようにしてもよい。

また、電子マネー使用制限管理データとして、制限付き電子マネー残高が使用可能な商品が設定されている場合、端末２０Ａの制御部２１は、撮像部２７によって撮像された店舗やサービスのブランドロゴや商品画像を使用可能合算残高要求情報に含めるようにしてもよい。この場合、サーバ１０の制御部１１は、使用可能合算残高要求情報に含まれる商品画像等に基づいて、購入予定の商品・サービスを特定し、各制限付き電子マネー残高が使用可能か否かを判定するようにしてもよい。

なお、使用可能合算残高算出処理は、サーバ１０で実行されることに限定されない。限定ではなく例として、端末２０Ａの制御部２１は、サーバ１０からアカウント管理データベース１５５Ｈの自端末アカウント管理データを取得すると、端末２０Ａの位置情報や現在日時に基づいて使用可能合算残高算出処理を実行し、使用可能合算残高を算出するようにしてもよい。

＜第１０実施例の効果＞
本実施例は、第１制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）と第２制限付き電子マネー残高（限定ではなく、第２電子貨幣の一例）とを含む、端末２０Ａ（限定ではなく、情報処理装置の一例）のユーザが利用可能な複数の電子貨幣のうち、連続制限付き決済処理（限定ではなく、第２決済の一例）に利用可能な使用可能合算残高（限定ではなく、電子貨幣の合計金額の一例）を情報処理装置に表示する制御を制御部によって行うことが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣と第２電子貨幣とを含む、情報処理装置のユーザが利用可能な複数の電子貨幣のうち、第１決済に利用可能な電子貨幣の合計金額を情報処理装置のユーザに知らせることが可能となり、利便性を向上させることができる。

＜第１０変形例（１）＞
上記の実施例では、端末２０Ａの状態（位置・日時等）によって使用可能合算残高を算出したが、これに限定されない。
限定ではなく例として、使用可能な店舗業種ごとの使用可能合算残高を算出し、一覧として端末２０Ａの表示部２４に表示させるようにしてもよい。

図１０－２は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１０－２左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、図１０－１左側の画面に対応するものである。
残高表示領域の「残高」の文字または残高の値（この例では「６，５００円」）の表示部分がタップされると、限定ではなく例として、図１０－２右側のような表示がなされる。

この例では、残高表示領域ＢＲ２の残高の値の下に、吹き出しによって、使用可能な店舗業種別の使用可能合算残高を含む使用可能残高表示領域ＵＲ２が表示されている。この例では、使用可能残高表示領域ＵＲ２内に、制限マークＲＭＫおよび「店舗別使用可能残高」の文字が表示され、その下に、店舗の業種別の使用可能合算残高が業種のアイコンと関連付けて表示されている。
具体的には、業種「コンビニ」、「スーパー・ホームセンター」については使用可能合算残高として「３，５００円」が、業種「書籍・文具」については使用可能合算残高として「６，５００円」が、業種「家具・家電」については使用可能合算残高として「５，５００円」がそれぞれ表示されている。

なお、一覧として使用可能合算残高を算出する対象は、店舗業種ごとに限定されない。限定ではなく例として、制限付き電子マネー残高の使用可能な日にちが指定される場合、カレンダー上の日付に対応させて使用可能合算残高を表示させるようにしてもよい。また、制限付き電子マネー残高の使用可能な時間帯が指定される場合、限定ではなく例として、アナログ時計状の表示内部にそれぞれの時間帯で使用可能合算残高を表示させるようにしてもよい。制限付き電子マネー残高の使用可能な商品・サービスが指定される場合、商品・サービスごとに、限定ではなく例として、「ゲーム：５００円」、「書籍：３０００円」等のように使用可能合算残高を表示させるようにしてもよい。制限付き電子マネー残高の使用可能な店舗が指定される場合、限定ではなく例として、地図上の領域内にそれぞれの領域における使用可能合算残高を表示させるようにしてもよい。

本変形例は、第１電子貨幣と第２電子貨幣とを含む、情報処理装置のユーザが利用可能な複数の電子貨幣のうち、店舗業種（限定ではなく、決済のカテゴリの一例）ごとに使用可能合算残高（限定ではなく、利用可能な金額の一例）を情報処理装置に表示する制御を制御部によって行うことが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣と第２電子貨幣とを含む、情報処理装置のユーザが利用可能な複数の電子貨幣のうち、決済のカテゴリごとに利用可能な金額を情報処理装置のユーザに知らせることが可能となり、利便性を向上させることができる。

＜第１１実施例＞
第１１実施例は、送金元アカウントのユーザから送金先アカウントのユーザに送金された制限付き電子マネー残高の残余を、所定の条件に基づいて、送金元アカウントのユーザ等に送金（返金、返還、返却と捉えてもよい。）することを可能にする実施例である。

第１１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜表示画面＞
図１１－１～図１１－２は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。ここで、制限付き電子マネー残高は図９－２と同様である。
図１１－１左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのコード支払い画面であり、ウォレットコード情報表示領域ＷＣＲ１に表示されたウォレットコード情報に基づいて支払いが行われると、図１１－１右側のような決済結果情報が表示される。この例では、支払い金額が「３，８００円」であり、内訳として、通知先アカウントをユーザＢ，Ｂのアカウントとする制限付き電子マネーから「１，０００円」が、通知先アカウントをユーザＣ．Ｃのアカウントとする制限付き電子マネーから「２，８００円」がそれぞれ支払われたことが示されている。

これにより、通知先アカウントがユーザＣ．Ｃのアカウントである制限付き電子マネーは「３，０００円－２，８００円＝２００円」に減少したことになる。ここでは、この制限付き電子マネーの残余の金額「２００円」が所定値以下となっていることに基づいて、この残余の金額「２００円」が送金元アカウントに送金される場合を例示する。
この例では、送金元アカウントは、通知先アカウントと同じユーザＣ．Ｃのアカウントとする。よって、サーバ１０を介して、ユーザＡ．ＡのアカウントからユーザＣ．Ｃのアカウントに対して「２００円」が送金される。

図１１－２左側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、支払いを行ったことを示す支払い結果情報ＰＲ１が表示され、その下に、返金の目的でユーザＣ．Ｃに制限付き電子マネーを「２００円」送金したことを示す制限付き電子マネー返金情報ＲＦ１が表示されている。

図１１－２中央は、この場合に端末２０Ｃの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、ユーザＡ．Ａに対して制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報ＲＲ９１が表示され、その下に、返金の目的でユーザＡ．Ａから制限付き電子マネー「２００円」が送金され、これを受け取ったことを示す制限付き電子マネー返金情報ＲＦ２が表示されている。

図１１－２右側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面の一例を示す図である。
上記の支払いと返金により、ユーザＡ．Ａのアカウントが所有する制限付き電子マネー残高は「０」となり、通常電子マネー残高のみが残る。その結果、残高表示領域ＢＲ２には、「残高」の文字とともに「２，５００円」の残高（通常電子マネー残高）とチャージボタンＣＢＴとが表示されている。

＜処理＞
図１１－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図１１－３は、限定ではなく例として、図８－２に引き続き実行される。

限定ではなく例として、連続制限付き決済処理が実行され（Ｓ５１０）、決済結果情報が送信される（Ｓ１５０）。すると、サーバ１０の制御部１１は、連続制限付き決済処理後の制限付き電子マネー残高のうち、所定値以下となる制限付き電子マネー残高が存在するか否かを判定する（Ｓ６１０）。

ここで、所定値は、限定ではなく例として、サーバ１０のユーザまたは端末２０のユーザによって定められる残高（限定ではなく例として、「２００円」）である。なお、サーバ１０の制御部１１は、所定値未満となる制限付き電子マネー残高が存在するか否かを判定するようにしてもよい。また、制限付き決済処理後の制限付き電子マネー残高のうち、所定値以下となる制限付き電子マネー残高が存在するか否かを判定する（Ｓ６１０）ようにしてもよいし、そのようにしなくてもよい。

所定値以下となる制限付き電子マネー残高が存在する場合（Ｓ６１０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー返還処理を実行する（Ｓ６２０）。制限付き電子マネー返還処理において、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｈの制限付き電子マネー管理データを参照し、その制限付き電子マネー残高が所定値以下となる送金管理ＩＤを探索する。そして、送金管理ＩＤと紐付けられた送金元ＩＤに対して、制限付き電子マネー残高の残額分を通常電子マネー残高として送金（返金・返還）する。その後、制限付き電子マネー管理データから、送金を行った送金管理ＩＤのレコードを削除する。

制限付き電子マネー返還処理を実行すると、サーバ１０の制御部１１は、端末２０Ａと、制限付き電子マネー残高の返還を行った送金元ＩＤのアカウントの端末２０Ｂとに、制限付き電子マネー返還結果情報を送信する（Ｓ６３０）。

所定値以下となる制限付き電子マネー残高が存在しない場合（Ｓ６１０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー返還結果情報を受信する場合（Ａ６１０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した制限付き電子マネー返還結果情報を表示させる（Ａ６２０）。サーバ１０から制限付き電子マネー返還結果情報を受信しない場合（Ａ６１０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。端末２０Ｂについても同様である。

＜第１１実施例の効果＞
本実施例は、端末２０Ａ（限定ではなく、情報処理装置の一例）のユーザによる制限付き電子マネー残高（限定ではなく、第１電子貨幣の一例）の残高が所定値以下となること（限定ではなく例として、使用に関する条件の一例）に基づいて、第１電子貨幣の残高が端末２０Ｂ（限定ではなく、第１情報処理装置の一例）のユーザに送金され、送金されたことを示す制限付き電子マネー返還結果情報（限定ではなく、第１情報の一例）を情報処理装置の通信部によって受信することが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、情報処理装置のユーザによる第１電子貨幣の使用に関する条件に基づいて、第１電子貨幣の残高が第１情報処理装置のユーザに送金されるようにすることができる。なお、これは、第１電子貨幣の残高が第１情報処理装置のユーザに返金、返還、返却されることと捉えてもよい。

＜第１１変形例（１）＞
上記の実施例では、連続制限付き決済処理を実行後、制限付き電子マネー残高が所定値以下となる場合、その制限付き電子マネー残高を送金元ＩＤのユーザに送金したが、これに限定されない。限定ではなく例として、送金元ＩＤのユーザが指定する他の任意のユーザ（アカウント）に送金するようにしてもよい。

＜第１１変形例（２）＞
上記の実施例では、制限付き電子マネー残高が所定値以下となる場合、制限付き電子マネー返還処理を実行したが、これに限定されない。限定ではなく例として、制限付き電子マネー返還処理を実行する承認を、支払いを実行した端末２０Ａにおいて得るようにしてもよい。

図１１－４は、本変形例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１１－４左側は、端末２０Ａの表示部２４に表示されるコード支払い画面の一例を示す図である。
ウォレットコード情報表示領域ＷＣＲ１に表示されたウォレットコード情報に基づいて支払いが行われると、図１１－４中央のような決済結果情報が表示される。その後、図１１－４右側のように、限定ではなく例として、決済結果情報の一部に重畳するように、制限付き電子マネーの残余を返還するか否かを確認するための制限付き電子マネー返還承認確認情報ＲＡ１が表示される。

この制限付き電子マネー返還承認確認情報ＲＡ１には、限定ではなく例として、「制限付き電子マネーを返還しますか？」の文字とともに、返還の目的で送金する金額（この例では「２００円」）と、返還によって通知先アカウントのユーザ（この例では「ユーザＣ．Ｃ」）に制限付き電子マネー使用通知がなされることを示すイラストと、送金元アカウントのユーザ（この例では「ユーザＣ．Ｃ」）に対して送金することを示すイラストとが含まれる。

また、その下には、返還を承認するための「返還する」ボタンＢＴ９１と、返還を拒否するための「やめる」ボタンＢＴ９２とが表示されており、「返還する」ボタンＢＴ９１がタップされると、制限付き電子マネーの残余の金額がユーザＣ．Ｃに返還される。

図１１－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。

所定値以下となる制限付き電子マネー残高が存在する場合（Ｓ６１０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー返還承認確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ６４０）。通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー返還承認確認情報を受信する場合（Ａ６３０：ＹＥＳ）、端末２０Ａの制御部２１は、制限付き電子マネー返還承認確認情報を表示部２４に表示させる（Ａ６４０）。限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、制限付き電子マネー残高を返還（送金）することが選択される場合（Ａ６４０：ＹＥＳ）、端末２０Ａの制御部２１は、制限付き電子マネー返還承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６５０）。
サーバ１０から制限付き電子マネー返還承認確認情報を受信しない場合（Ａ６３０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。
制限付き電子マネー残高を返還（送金）することが選択されない場合（Ａ６４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ１４によって端末２０Ａから制限付き電子マネー返還承認情報を受信する場合（Ｓ６５０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー返還処理を実行する（Ｓ６２０）。端末２０Ａから制限付き電子マネー返還承認情報を受信しない場合（Ｓ６５０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

なお、制限付き電子マネー返還処理を実行する承認を、送金元ＩＤの端末２０Ｂにおいて得るようにしてもよいし、そのようにしなくてもよい。また、支払い者の端末２０Ａと、送金元ＩＤの端末２０Ｂとの両方において承認が得られる場合、制限付き電子マネー返還処理を実行するようにしてもよいし、そのようにしなくてもよい。

本変形例は、第１電子貨幣の使用に関する条件に基づいて、第１電子貨幣の残高を第１情報処理装置のユーザに送金するための第２情報を情報処理装置の表示部に表示することが情報処理装置によって実行され、第１電子貨幣の残高は、第２情報に対する情報処理装置のユーザの入力に基づいて、第１情報処理装置のユーザに送金される。そして、情報処理装置は、第１情報を受信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣の使用に関する条件に基づいて、第１電子貨幣の残高を第１情報処理装置のユーザに返金することを、情報処理装置の表示部への第２情報の表示によって情報処理装置のユーザに知らせることができる。また、表示部に表示された第２情報に対する情報処理装置のユーザによる入力に基づいて、第１電子貨幣の残高が第１情報処理装置のユーザに送金されるようにすることができる。そして、その結果、限定ではなく例として、送金が行われたことを、情報処理装置の表示部への第１情報の表示によって、情報処理装置のユーザに知らせることができる。

＜第１１変形例（３）＞
上記の実施例では、制限付き電子マネー返還処理を実行する条件として、連続制限付き決済処理を実行後、制限付き電子マネー残高が所定値以下となる場合について説明したが、これに限定されない。制限付き電子マネー返還処理を実行する条件としては、限定ではなく例として、以下のような例が挙げられる。
・制限付き電子マネー残高が送金された時点での残高の所定割合（限定ではなく例として、「５％」）以下となる、または下回る場合。
限定ではなく例として、「１０，０００円」の制限付き電子マネー残高を受け取った場合、連続制限付き決済処理を実行後、制限付き電子マネー残高が「１０，０００円」×「５％」＝「５００円」以下となった場合、制限付き電子マネー返還処理が実行される。
・制限付き電子マネー残高の使用期限まで所定の時間（限定ではなく例として、「２４時間」）を切った場合。
限定ではなく例として、制限付き電子マネー残高の最初の利用により、使用期限が「７日後」である「２０２１年７月２３日中」に設定された場合、「２０２１年７月２３日午前０時となった場合、制限付き電子マネー返還処理が実行される。この場合、連続制限付き決済処理を実行後、期日を判定してもよいし、連続制限付き決済処理が実行されていなくとも、期日を判定してもよい。
・制限付き電子マネー残高が所定の回数（限定ではなく例として、「１０」回）使用された場合。
限定ではなく例として、ある制限付き電子マネー残高が１０回連続制限付き決済処理（制限付き決済処理）において使用された場合、制限付き電子マネー返還処理が実行される。

本変形例は、第１電子貨幣の使用に関する条件は、制限付き電子マネーの残高、または端末２０に送金された制限付き電子マネーの金額に対する残高の割合に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣の残高、または情報処理装置に送金された第１電子貨幣の金額に対する残高の割合に関する条件に基づいて、第１電子貨幣の残高が第１情報処理装置のユーザに適切に送金されるようにすることができる。

また、本変形例は、第１電子貨幣の使用に関する条件は、制限付き電子マネーを使用して端末２０が決済可能な期間に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣を使用して情報処理装置が決済可能な期間に関する条件に基づいて、第１電子貨幣の残高が第１情報処理装置のユーザに適切に送金されるようにすることができる。

また、本変形例は、第１電子貨幣の使用に関する条件は、制限付き電子マネーを利用して決済を行った回数に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣を利用して決済を行った回数に関する条件に基づいて、第１電子貨幣の残高が第１情報処理装置のユーザに適切に送金されるようにすることができる。

＜第１１変形例（３）＞
上記の実施例では、制限付き電子マネー返還処理が実行されると、送金元ＩＤのアカウントに残高が送金されることとしたが、これに限定されない。限定ではなく例として、支払いを行った端末２０Ａのアカウントの通常電子マネー残高に送金されることとしてもよい。この場合、連続制限付き決済処理を実行後、制限付き電子マネー残高の残高が所定値以下となる場合、端数の残高が通常電子マネー残高として組み込まれる。

なお、連続制限付き決済処理を実行後、制限付き電子マネー残高の残高が所定値以下となる場合、送金者（送金元ＩＤのアカウント）の承諾が得られると、残った制限付き電子マネー残高を通常電子マネー残高に送金するようにしてもよい。また、送金者（送金元ＩＤのアカウント）の承諾が得られる場合、任意のタイミングで、制限付き電子マネー残高を通常電子マネー残高に送金するようにしてもよい。

＜第１２実施例＞
上記の実施例では、制限付き電子マネー残高は、送金ごとに残高を分けて管理されていた。
第１２実施例は、同一の使用制限が付与された２つの制限付き電子マネー残高を併合（マージ）することで、１の制限付き電子マネー残高として管理・使用する実施例である。

第１２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
図１２－１は、本実施例におけるアカウント管理データベース１５５の一例であるアカウント管理データベース１５５Ｊのデータ構成例を示す図である。
このアカウント管理データベース１５５Ｊの各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、通常電子マネー残高と、制限付き電子マネー管理データと、併合済み制限付き電子マネー管理データと、制限付き電子マネー使用履歴データと、電子マネー使用制限管理データとが記憶される。

併合済み制限付き電子マネー管理データは、後述する制限付き電子マネー併合処理において併合された２以上の制限付き電子マネー（以下、「併合済み制限付き電子マネー」と呼称する。）に関する情報を管理するためのデータであり、限定ではなく例として、併合管理ＩＤと、併合前送金管理ＩＤと、併合済み制限付き電子マネー残高とが関連付けて記憶される。

併合管理ＩＤは、併合済み制限付き電子マネーをユニークに識別するためのＩＤであり、限定ではなく例として、制限付き電子マネー併合処理がサーバ１０によって実行されるごとに、サーバ１０によって異なるＩＤが設定されて記憶される。

併合前送金管理ＩＤは、併合する対象となった制限付き電子マネーに関する情報を管理するためのデータであり、限定ではなく例として、制限付き電子マネー併合処理がサーバ１０によって実行されると、併合対象となった制限付き電子マネーの送金管理ＩＤが追加され記憶される。

併合済み制限付き電子マネー残高は、この併合管理ＩＤに関連付けられた制限付き電子マネーの残高である。

制限付き電子マネー併合処理が実行されると、併合前送金管理ＩＤに記憶された制限付き電子マネー残高は使用が出来なくなる。アカウント管理データベース１５５Ｊでは、使用が出来なくなった制限付き電子マネー残高を、限定ではなく例として、「（）」をつけて表記することとする。アカウント管理データベース１５５Ｊでは、限定ではなく例として、制限付き電子マネー管理データにおいて、送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネーは併合管理ＩＤの制限付き電子マネーに併合されたため、制限付き電子マネー残高は「（１０００円）」と表記されている。「（）」内の金額は、限定ではなく例として、制限付き電子マネー併合処理が実行された時点での制限付き電子マネー残高である。このため、送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネーは使用できない（併合済みである）ことがわかる。

併合済み制限付き電子マネーが支払いに使用される場合、制限付き電子マネー使用履歴データには、併合管理ＩＤを送金管理ＩＤとしてレコードの追加が行われる。

なお、併合済み制限付き電子マネー管理データに、通知先ＩＤ等の通知先アカウントに関する情報を併合管理ＩＤと関連付けて記憶させるようにしてもよい。

＜表示画面＞
以下説明する第１制限付き電子マネーと第２制限付き電子マネーとには、いずれも通知に関する制限は設定されておらず、使用可能な店舗に関する制限のみが設定されていることとして説明する。

図１２－２は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１２－２左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、残高表示領域ＢＲ２には、制限付き電子マネー残高（この例では「１，０００円」）と、制限マークＲＭＫとが表示されている。そして、ここでは、制限マークＲＭＫがユーザによってタップされた状態が示されている。

この場合、限定ではなく例として、吹き出しによって、この制限付き電子マネーを使用可能な店舗の業種の情報を含む使用可能店舗情報が表示される。この例では、制限付き電子マネーを使用可能な店舗の業種として「書籍・文具」が表示されている。この制限付き電子マネーの残高は、送金元アカウントがユーザＢ．Ｂのアカウントである第１制限付き電子マネーに基づく残高であり、図１２－２中央の画面に示す第１制限付き電子マネー送金結果情報ＲＲ１０１に対応するものである。

図１２－２中央は、端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、上記の送金元アカウントがユーザＢ．Ｂのアカウントである第１制限付き電子マネーに対応する第１制限付き電子マネー送金結果情報ＲＲ１０１が表示されている。

その後、限定ではなく例として、ユーザＣ．ＣのアカウントからユーザＡ．Ａのアカウントに対して、第２制限付き電子マネーとして「２，０００円」が送金されたとする。その結果、第１制限付き電子マネー送金結果情報ＲＲ１０１の下に、第２制限付き電子マネー送金結果情報ＲＲ１０２が表示される。

第１制限付き電子マネーと第２制限付き電子マネーとは、いずれも使用可能な店舗の業種が「書籍・文具」で同じである。この場合、使用可能な店舗の業種が同じであることに基づいて、限定ではなく例として、第２制限付き電子マネーの着金時に、サーバ１０によって、これら２つの制限付き電子マネーが併合（マージ）される。

図１２－２右側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面の一例を示す図である。
制限付き電子マネーが併合されたことに基づいて、残高表示領域ＢＲ２には、併合済み制限付き電子マネーの残高として「１，０００円＋２，０００円＝３，０００円」が表示されている。そして、ここでは、制限マークＲＭＫがユーザによってタップされた状態が示されている。

この場合、限定ではなく例として、図１２－２左側の画面と同様に、吹き出しによって、併合済み制限付き電子マネーを使用可能な店舗の業種の情報を含む使用可能店舗情報が表示される。この例では、併合済み制限付き電子マネーを使用可能な店舗の業種として「書籍・文具」が表示されている。

＜処理＞
図１２－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図７－５に相当する部分を示したものである。

端末２０Ｂの制御部２１は、限定ではなく例として、図７－５のＢ４１０～Ｂ４２０と同様にして、第１制限付き電子マネー送金設定処理を実行し（Ｂ７１０）、第１制限付き電子マネー送金依頼情報をサーバ１０に送信する（Ｂ７２０）。第１制限付き電子マネー送金設定処理において設定された条件（制限）を「第１制限」と呼称する。サーバ１０の制御部１１は、限定ではなく例として、図７－５のＳ４１０～Ｓ４２０と同様にして、第１制限付き電子マネー送金処理を実行し（Ｓ７１０）、第１制限付き電子マネー送金結果情報を送信する（Ｓ７２０）。端末２０Ａの制御部２１と、端末２０Ｂの制御部２１とは、第１制限付き電子マネー送金結果情報を受信すると、表示部２４に表示させる（Ａ７１０・Ｂ７３０）。

次いで、端末２０Ｂの制御部２１は、限定ではなく例として、図７－５のＢ４１０～Ｂ４２０と同様にして、第２制限付き電子マネー送金設定処理を実行し（Ｂ７１５）、第２制限付き電子マネー送金依頼情報をサーバ１０に送信する（Ｂ７２５）。第２制限付き電子マネー送金設定処理において設定された条件（制限）を「第２制限」と呼称する。サーバ１０の制御部１１は、限定ではなく例として、図７－５のＳ４１０と同様にして、第２制限付き電子マネー送金処理を実行する（Ｓ７１５）。
なお、Ｂ７１５～Ｂ７２５のステップは、端末２０Ｂ以外の端末２０において実行されるようにしてもよい。

すると、サーバ１０の制御部１１は、限定ではなく例として、アカウント管理データベース１５５Ｊのアカウント管理データを読み出し、制限付き電子マネー管理データと電子マネー使用制限管理データとを参照することで、同一の使用制限（この例では使用可能店舗業種と通知先ＩＤ）が付与された制限付き電子マネーが存在するか否かを判定する（Ｓ７３０）。

制限が同一であると判定された場合（Ｓ７３０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー併合処理を実行する（Ｓ７４０）。制限付き電子マネー併合処理において、サーバ１０の制御部１１は、制限が同一である（限定ではなく例として、第１制限と第２制限が等しい）と判定された２以上の制限付き電子マネー（限定ではなく例として、第１制限付き電子マネーと第２制限付き電子マネー）の残高を合算し、併合済み制限付き電子マネー管理データの併合済み制限付き電子マネー残高として、生成した併合管理ＩＤと関連付けて記憶させる。また、サーバ１０の制御部１１は、制限が同一であると判定された２以上の制限付き電子マネーの送金管理ＩＤを、併合前送金管理ＩＤに追加する。サーバ１０の制御部１１は、制限付き電子マネー管理データにおいて、制限が同一であると判定された２以上の制限付き電子マネー残高を使用不能にする（「（）をつけて記憶する」）。

そして、サーバ１０の制御部１１は、生成した併合管理ＩＤと、併合済み制限付き電子マネー残高とを少なくとも含む制限付き電子マネー併合結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ７５０）。なお、制限付き電子マネー併合結果情報に、併合前送金管理ＩＤに記憶される送金管理ＩＤを含めるようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー併合結果情報を受信する場合（Ａ７２０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した制限付き電子マネー併合結果情報を表示部２４に表示させる（Ａ７３０）。サーバ１０から制限付き電子マネー併合結果情報を受信しない場合（Ａ７２０：ＮＯ）、端末２０Ａの制御部２１は、Ａ７３０のステップをスキップする。

なお、サーバ１０の制御部１１は、制限付き電子マネー併合結果情報を、併合済みとなった制限付き電子マネーの送金元ＩＤのアカウントの端末２０Ｂに送信するようにしてもよいし、そうしなくてもよい。サーバ１０から制限付き電子マネー併合結果情報を受信する場合、端末２０Ｂの制御部２１は、表示部２４に受信した制限付き電子マネー併合結果情報を表示させる。

制限が同一であると判定されない場合（Ｓ７３０：ＮＯ）、サーバ１０の制御部１１は、Ｓ７４０～Ｓ７５０のステップをスキップする。
そして、サーバ１０の制御部１１は、限定ではなく例として、図７－５のＳ４２０と同様にして、第２制限付き電子マネー送金結果情報を送信する（Ｓ７２５）。なお、制限付き電子マネー併合処理によって第２制限付き電子マネーが併合済みとなった場合、サーバ１０の制御部１１は、制限付き電子マネー併合結果情報を送信した端末２０Ａに、第２制限付き電子マネー送金結果情報を送信しないようにしてもよい。

端末２０Ａの制御部２１と、端末２０Ｂの制御部２１とは、第２制限付き電子マネー送金結果情報を受信すると、表示部２４に表示させる（Ａ７１５・Ｂ７３５）。

なお、支払いに使用する電子マネー残高がユーザによって選択された後、Ａ１２０のステップまたはその前後において、端末２０Ａの制御部２１は、選択された制限付き電子マネー残高に対応する送金管理ＩＤまたは併合管理ＩＤをサーバ１０に送信するようにすることができる。
また、制限付き電子マネー併合処理によって第１制限付き電子マネーと第２制限付き電子マネーとが併合済みとなった場合、端末２０Ａの制御部２１は、支払いの選択表示に併合済みの制限付き電子マネーを表示させないようにすることができる。なお、第１制限付き電子マネーと第２制限付き電子マネーとが併合済みとなった場合、サーバ１０の制御部１１は、第１制限付き電子マネーと第２制限付き電子マネーの情報をあたかも存在しないかのように端末２０Ａに送信しないようにしてもよい。このようにすることで、端末２０Ａとサーバ１０とは、併合元となった制限付き電子マネーを使用させないようにすることができる。

支払いに用いる電子マネーとして併合管理ＩＤが指定される場合、制限付き決済処理において、電子マネー使用制限管理データの送金管理ＩＤに格納される、指定された併合管理ＩＤと関連付けられた使用制限に従って使用の可否が判定され、併合済み制限付き電子マネー残高を消費して決済処理が実行される。

＜第１２実施例の効果＞
本実施例は、サーバ１０（限定ではなく、端末２０Ａ（限定ではなく、第１端末の一例）のユーザと電子貨幣とを関連付けて記憶するサーバの一例）によって実行されるプログラムであって、端末２０Ｂ（限定ではなく、第２端末の一例）のユーザによって第１制限が設定された、第２端末から第１端末に送金された第１制限付き電子マネー（限定ではなく、第１電子貨幣の一例）と、第１端末のユーザとを関連付ける処理と、端末２０Ｃ（限定ではなく、第３端末の一例）のユーザによって第２制限が設定された、第３端末から第１端末に送金された第２制限付き電子マネー（限定ではなく、第２電子貨幣の一例）と、第１端末のユーザとを関連付ける処理と、をサーバの制御部によって行うことと、第１制限と第２制限とに基づいて、制限付き電子マネー併合処理（限定ではなく、第１電子貨幣と前記第２電子貨幣とに基づく第３電子貨幣を第１端末のユーザに関連付ける処理の一例）を制御部によって行うこととがサーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１制限と第２制限とに基づいて、第１電子貨幣と第２電子貨幣とに基づく第３電子貨幣が、第１端末のユーザに関連付けられるようにすることができる。つまり、制限が設定された電子貨幣同士を、それらの制限に基づいて、いわば併合することが可能となる。

また、本実施例は、第１制限は、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含み、第２制限は、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含む構成を示している。
このような構成により得られる実施例の効果の一例として、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含む第１制限と、購入可能な商品に関する制限、購入可能な店舗に関する制限、通知に関する制限のうち少なくとも一つを含む第２制限とに基づいて、第１電子貨幣と第２電子貨幣とに基づく第３電子貨幣が、第１端末のユーザに関連付けられるようにすることができる。

また、本実施例は、併合済み制限付き電子マネー（限定ではなく例として、第３電子貨幣の一例）は、第１電子貨幣と第２電子貨幣とが合算された電子貨幣である構成を示している。
このような構成により得られる実施例の効果の一例として、第１電子貨幣と第２電子貨幣とが合算された第３電子貨幣が、第１端末のユーザと関連付けられるようにすることができる。

＜第１２変形例（１）＞
上記の実施例では、制限が同一である制限付き電子マネーが存在すると、自動的に併合することとしたが、これに限定されない。限定ではなく例として、制限が同一であると判定された場合、端末２０Ａのユーザの承認操作に基づいて、制限付き電子マネー併合処理が実行されるようにしてもよい。

図１２－４は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１２－４左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面の一例を示す図であり、図１２－２左側の画面に対応するものである。

図１２－４中央は、ユーザＣ．ＣのアカウントからユーザＡ．Ａのアカウントに対して、第２制限付き電子マネーとして「２，０００円」が送金され、ユーザＡ．Ａが受け取った場合の表示画面の一例である。残高表示領域ＢＲ２には、第１制限付き電子マネーの残高である「１，０００円」と、第２制限付き電子マネーの残高である「２，０００円」と、通常電子マネー残高である「５００円」とが個別に表示されている。

また、第１制限付き電子マネーと第２制限付き電子マネーとの使用可能な店舗の業種が共通であることに基づいてサーバ１０から端末２０Ａに送信された制限付き電子マネー併合確認情報ＭＣＲ１が、メインメニュー画面に重畳して表示されている。

具体的には、制限付き電子マネー併合確認情報ＭＣＲ１には、「制限付き電子マネーをまとめますか？」の文字とともに、併合する対象となる制限付き電子マネーである第１制限付き電子マネー残高（この例では「１，０００円」）および制限マークＲＭＫと、第２制限付き電子マネー残高（この例では「２，０００円」）および制限マークＲＭＫとが表示されている。その下には、第１制限付き電子マネーと、第２制限付き電子マネーとを共通に使用可能な店舗の業種が「書籍・文具」であることが示されている。

また、その下には、第１制限付き電子マネーと第２制限付き電子マネーとを併合することを承認するための「まとめる」ボタンＢＴ１０１と、拒否するための「やめる」ボタンＢＴ１０２とが表示されている。

「まとめる」ボタンＢＴ１０１がタップされると、サーバ１０によって、これら２つの制限付き電子マネーが併合（マージ）される。その結果、図１２－４右側に示すように、支払いアプリケーションのメインメニュー画面には、図１２－２右側と同様の表示がなされる。

なお、上記の画面図では第１制限付き電子マネーと第２制限付き電子マネーとの場合を例示したが、ユーザＡ．Ａが併合可能な３以上の制限付き電子マネーを所有している場合、制限付き電子マネー併合確認情報として、３以上の制限付き電子マネーを１つにまとめるか否かの情報を表示させるようにしてもよい。

本変形例における処理は、限定ではなく例として、図１２－３のＳ７３０において、制限が同一であると判定される場合（Ｓ７３０：ＹＥＳ）、サーバ１０の制御部１１は、制限付き電子マネー併合確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。端末２０Ａの制御部２１は、受信した制限付き電子マネー併合確認情報を表示部２４に表示させる。限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、制限付き電子マネーを併合することが選択される場合、端末２０Ａの制御部２１は、制限付き電子マネー併合承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
端末２０Ａから制限付き電子マネー併合承認情報を受信する場合、サーバ１０の制御部１１は、制限付き電子マネー併合処理を実行する。

なお、制限が同一であると判定された場合、併合対象とされる第１制限付き電子マネーと第２制限付き電子マネーとの送金元ＩＤのユーザの承認操作に基づいて、制限付き電子マネー併合処理が実行されるようにしてもよい。この場合、第１制限付き電子マネーの送金元ＩＤのユーザと第２制限付き電子マネーの送金元ＩＤのユーザとの両者の承認が得られる場合、制限付き電子マネー併合処理が実行されるようにしてもよいし、どちらか片方の承認が得られる場合、制限付き電子マネー併合処理が実行されるようにしてもよい

また、併合前の制限付き電子マネーの送金元ＩＤが３以上である（３以上の制限付き電子マネーを併合する）場合、制限付き電子マネー併合処理が実行されるためには、それぞれの送金元ＩＤのユーザ全員の承認が必要であるようにしてもよいし、所定数（限定ではなく例として、過半数）の承認が必要であるようにしてもよい。

＜第１２変形例（２）＞
上記の実施例では、制限が同一である場合、制限付き電子マネーを併合することとしたが、これに限定されない。限定ではなく例として、第１制限と第２制限が近い場合においても、第１制限付き電子マネーと第２制限付き電子マネーとの制限付き電子マネー併合処理が実行されるようにしてもよい。

ここで、第１制限と第２制限とが近いには、限定ではなく例として、以下のような例が挙げられる。
・第１制限は第２制限を含む。
・第２制限は第１制限を含む。
・第１制限と第２制限が類似する。

第１制限を第２制限が含む（または第２制限を第１制限が含む）場合には、限定ではなく例として、以下のような例が挙げられる。
・通知先の包含関係
限定ではなく例として、第１制限＝通知先がユーザＡ．ＡとユーザＢ．Ｂ、第２制限＝通知先がユーザＡ．Ａ（またはユーザＢ．Ｂ）の場合、第１制限は第２制限を含む。
・使用可能店舗業種・サービス業種の包含関係
限定ではなく例として、第１制限＝「コンビニ」「書籍・文具」で使用可能、第２制限＝「コンビニ」（または「書籍・文具」）で使用可能である場合、第１制限は第２制限を含む。
・購入可能な商品・サービスの包含関係
限定ではなく例として、第１制限＝「エンターテイメント」で使用可能、第２制限＝「ゲームソフト」（または「楽曲購入」等）で使用可能である場合、第１制限は第２制限を含む。
・使用可能な日時や時間帯に関する包含関係
限定ではなく例として、第１制限＝「９：００～２１：００」に使用可能、第２制限＝「１２：００～１３：００」に使用可能である場合、第１制限は第２制限を含む。また、第１制限＝送金した月である６月中に使用可能、第２制限＝遠足の日である６月１５日に使用可能である場合、第１制限は第２制限を含む。

第１制限と第２制限が類似する場合には、限定ではなく例として、以下のような例が挙げられる。
・通知先の類似
限定ではなく例として、第１制限＝支払い者の父親に通知、第２制限＝支払い者の母親に通知の場合、通知先が共に１親等であるため類似する。
・購入可能な商品・サービスの類似
限定ではなく例として、第１制限＝Ｘ．Ｘ社の家電製品が購入可能、第２制限＝Ｙ．Ｙ社の家電製品が購入可能である場合、同じ商品種別の商品が購入可能であるため類似する。また、第１制限＝Ｘ．Ｘ社の家電製品が購入可能、第２制限＝Ｘ．Ｘ社の食品飲料が購入可能である場合、同じメーカーの商品が購入可能であるため類似する。
・使用可能な日時や時間帯に関する包含関係
限定ではなく例として、第１制限＝「１１：００～１３：００」に使用可能、第２制限＝「１２：００～１４：００」に使用可能である場合、使用可能な時間帯において使用が許可される時間（この例では第１制限・第２制限とも２時間）の所定割合以上（限定ではなく例として、５割以上）がかぶっているため類似する。

本変形例は、第１制限が第２制限を含む場合、第２制限が第１制限を含む場合、および第１制限と第２制限とが同一の制限である場合のうちの少なくとも一つの場合、第１電子貨幣と第２電子貨幣とに基づく第３電子貨幣を第１端末のユーザに関連付ける処理を制御部によって行うこととがサーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１制限が第２制限を含む場合、第２制限が第１制限を含む場合、および第１制限と第２制限とが同一の制限である場合のうちの少なくとも一つの場合、第１制限と第２制限とに基づいて、第１電子貨幣と第２電子貨幣とに基づく第３電子貨幣が、第１端末のユーザに関連付けられるようにすることができる。

＜第１２変形例（３）＞
上記の実施例では、制限付き電子マネー併合処理において、併合対象である第１制限付き電子マネー残高と第２制限付き電子マネー残高との和を併合済み制限付き電子マネー残高とする例について例示したが、これに限定されない。限定ではなく例として、併合済み制限付き電子マネー残高を以下の式で算出するようにしてもよい。
「併合済み制限付き電子マネー残高」＝「第１制限付き電子マネー残高」＋「第２制限付き電子マネー残高」＋「併合ボーナス」
ここで、併合ボーナスは、制限付き電子マネーの併合を行うことで得られるボーナス残高であり、限定ではなく例として、第１制限付き電子マネー残高と第２制限付き電子マネー残高の合算値の１０％等に定めることができる。

なお、併合済み制限付き電子マネー残高を以下の式で算出するようにしてもよい。
「併合済み制限付き電子マネー残高」＝「第１制限付き電子マネー残高」＋「第２制限付き電子マネー残高」－「併合オーナス」
ここで、併合オーナスは、制限付き電子マネーの併合を行うことで端末２０のユーザが負担する残高であり、限定ではなく例として、第１制限付き電子マネー残高と第２制限付き電子マネー残高の合算値の５％等に定めることができる。

＜第１２変形例（４）＞
上記の実施例では、第１制限付き電子マネー残高と第２制限付き電子マネー残高とを併合した後も制限付き電子マネー管理データからはそれぞれの送金管理ＩＤで示されるレコードの関連付けが保存される例を示したが、これに限定されない。

図１２－５は、この場合、制限付き電子マネー併合処理が実行される前のアカウント管理データベース１５５Ｈに含まれるアカウント管理データの一例である。
送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネーと、送金管理ＩＤ「Ｔ０２５７２」の制限付き電子マネーとは、電子マネー使用制限管理データにおいて同一の使用可能店舗業種であるため、制限付き電子マネー併合処理が実行される。

図１２－６は、制限付き電子マネー併合処理が実行された後のアカウント管理データベース１５５Ｈに含まれるアカウント管理データの一例である。
この図では、制限付き電子マネー併合処理が実行されたことに基づいて、送金管理ＩＤ「Ｔ９０００１」が新たに発行（生成）される。そして、送金管理ＩＤ「Ｔ９０００１」の制限付き電子マネーの送金元ＩＤとして、送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネーの送金元ＩＤ「Ｕ０００２」と、送金管理ＩＤ「Ｔ０２５７２」の制限付き電子マネーの送金元ＩＤ「Ｕ０００３」とが記憶される。また、送金管理ＩＤ「Ｔ９０００１」の制限付き電子マネー残高には、送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネー残高「１，０００円」と、送金管理ＩＤ「Ｔ０２５７２」の制限付き電子マネー残高「２，０００円」とを加算した「３，０００円」が記憶される。

なお、サーバ１０の制御部１１は、制限付き電子マネー併合処理において、新たな送金管理ＩＤを発行しないようにしてもよい。この場合、送金管理ＩＤには、「Ｔ０２１０９」または「Ｔ０２５７２」が引き続き使用される。

＜第１２変形例（５）＞
上記の実施例では、制限付き電子マネー併合処理後のデータとして、第１制限付き電子マネーと第２制限付き電子マネーとを併合した併合済み制限付き電子マネー管理データを用いて管理していたが、これに限定されない。限定ではなく例として、制限付き電子マネー併合処理後のデータとして、図１２－５に示すデータを用いるようにしてもよい。ただし、送金管理ＩＤ「Ｔ０２１０９」の制限付き電子マネーと、送金管理ＩＤ「Ｔ０２５７２」の制限付き電子マネーには、併合されたことを示す併合済みフラグ情報が追加される。この場合、端末２０Ａの制御部２１は、電子マネー残高の一覧を要求する電子マネー残高要求情報をサーバ１０に送信すると、サーバ１０の制御部１１は、通常電子マネー残高と、制限付き電子マネー管理データとを端末２０Ａの制御部２１に送信する。そして、端末２０Ａの制御部２１は受信した制限付き電子マネー管理データに基づいて、併合済みフラグ情報が付加された制限付き電子マネー残高を加算して表示部２４に表示させる。このとき、端末２０Ａの制御部２１は、併合済みフラグ情報が付加されたそれぞれの制限付き電子マネー残高を表示部２４に表示させないようにしてもよい。

本変形例は、端末２０Ａ（限定ではなく、情報処理装置の一例）によって実行されるプログラムであって、端末２０Ｂ（限定ではなく、第１情報処理装置の一例）のユーザによって第１制限が設定された、第１情報処理装置から情報処理装置に送金された第１制限付き電子マネー（限定ではなく、第１電子貨幣の一例）の情報と、端末２０Ｃ（限定ではなく、第２情報処理装置の一例）のユーザによって第２制限が設定された、第２情報処理装置から第１情報処理装置に送金された第２制限付き電子マネー（限定ではなく、第２電子貨幣の一例）の情報とを情報処理装置に表示することと、第１制限と第２制限とに基づいて、第１電子貨幣と第２電子貨幣とに基づく併合済み制限付き電子マネー残高（限定ではなく例として、第３電子貨幣の一例）を表示部に表示する制御を情報処理装置の制御部によって行うこととが情報処理装置によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報処理装置のユーザによって第１制限が設定された、第１情報処理装置から情報処理装置に送金された第１電子貨幣の情報と、第２情報処理装置のユーザによって第２制限が設定された、第２情報処理装置から第１情報処理装置に送金された第２電子貨幣の情報とを、表示によって情報処理装置のユーザに認識させることができる。また、第１制限と第２制限とに基づいて、第１電子貨幣と第２電子貨幣とに基づく第３電子貨幣を、表示によって情報処理装置のユーザに認識させることができる。

＜第１２変形例（６）＞
上記の実施例では、第１制限付き電子マネー送金処理と、第２制限付き電子マネー送金処理とを実行後、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行することとしたが、これに限定されない。限定ではなく例として、サーバ１０の制御部１１は、第１制限付き電子マネー送金処理を実行後、第２制限付き電子マネー送金依頼情報を端末２０から受信すると、第２制限付き電子マネー送金依頼情報に基づいて、第２制限と送金処理済みの第１制限とが同一の制限であるか否かを判定する。そして、同一の制限である場合、サーバ１０の制御部１１は、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよい。同一の制限でない場合、サーバ１０の制御部１１は、第２制限付き電子マネー送金処理を実行する。

この場合、データ構成としては、限定ではなく例として、図１２－６に示したデータ構成を用いるようにしてもよい。また、限定ではなく例として、図１２－１に示したデータ構成において、制限付き電子マネー併合処理において、制限付き電子マネー管理データへの第２制限付き電子マネー送金依頼情報に基づく変更と、併合済み制限付き電子マネー管理データの変更を行うようにしてもよい。

＜第１２変形例（７）＞
上記の実施例では、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行することで、併合管理ＩＤで識別される併合済み制限付き電子マネーを生成したが、これに限定されない。限定ではなく例として、生成済みの併合済み制限付き電子マネーの併合を解除することで、第１制限付き電子マネーと第２制限付き電子マネーとに分割（復元）するようにしてもよい。

この場合、分割（復元）後の第１制限付き電子マネー残高と、第２制限付き電子マネー残高とは、分割時点における併合済み制限付き電子マネー残高を、限定ではなく例として、それぞれの制限付き電子マネー残高に記憶される「（）」内の残高比で分配することで、算出することができる。

なお、生成済みの併合済み制限付き電子マネーの併合を解除するためには、送金先アカウントの端末２０Ａにおいて承認が必要であるようにしてもよい。また、生成済みの併合済み制限付き電子マネーの併合を解除するためには、送金元アカウントの端末２０Ｂにおいて承認が必要であるようにしてもよい。

＜第１２変形例（８）＞
上記の実施例では、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行する例を例示したが、これに限定されない。限定ではなく例として、第１制限付き電子マネーと第２制限付き電子マネーとを併合した第１併合済み制限付き電子マネーと、第３制限付き電子マネーとにおいて、第１併合済み制限と第３制限とが同一の場合、第１併合済み制限付き電子マネーと第３制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよい。

この場合、制限付き電子マネー併合処理において、サーバ１０の制御部１１は、併合済み制限付き電子マネー管理データにおいて、第１併合済み制限付き電子マネーの併合管理ＩＤと関連付けて、併合前送金管理ＩＤに第３制限付き電子マネーの送金元ＩＤを追加して記憶する。また、併合済み制限付き電子マネー残高に、第１併合済み制限付き電子マネー残高と第３制限付き電子マネー残高とを加算して記憶する。そして、制限付き電子マネー管理データの第３制限付き電子マネー残高を使用不能とする。

なお、制限付き電子マネー併合処理において、サーバ１０の制御部１１は、併合済み制限付き電子マネー管理データにおいて、新たに併合管理ＩＤを生成し、第１併合済み制限付き電子マネーの送金元ＩＤと第３制限付き電子マネーの送金元ＩＤとを併合前送金管理ＩＤに関連付けて記憶させる。そして、第１併合済み制限付き電子マネー残高と第３制限付き電子マネー残高とを加算して新たに生成された併合管理ＩＤと関連付けて記憶するようにしてもよい。この場合、サーバ１０の制御部１１は、第１併合済み制限付き電子マネー残高を使用不能とする（限定ではなく例として、「（）」で囲う）。

なお、第１併合済み制限と第２併合済み制限とが同一である場合、第１併合済み制限付き電子マネーと第２併合済み制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよい。この場合、制限付き電子マネー併合処理の処理方法としては、限定ではなく例として、第１併合済み制限付き電子マネーの併合管理ＩＤと関連付けて、第２併合済み制限付き電子マネーの送金元ＩＤを追加し、第１併合済み制限付き電子マネー残高と第２併合済み制限付き電子マネー残高とを加算した金額を併合済み制限付き電子マネー残高として記憶する。

または、新たに併合管理ＩＤを発行し、発行された併合管理ＩＤと関連付けて、第１併合済み制限付き電子マネーの送金元ＩＤおよび第２併合済み制限付き電子マネーの送金元ＩＤとを併合前送金管理ＩＤに、第１併合済み制限付き電子マネー残高と第２併合済み制限付き電子マネー残高とを加算した金額を併合済み制限付き電子マネー残高に、記憶する。そして、サーバ１０の制御部１１は、第１併合済み制限付き電子マネー残高と第２併合済み制限付き電子マネー残高とを使用不能とする。

＜第１２変形例（９）＞
商品やサービスの返品時等において、返金が発生した場合、決済時に併合済み制限付き電子マネー残高が使用された場合には、返金される金額を決済時に使用した併合済み制限付き電子マネー残高に加算するようにしてもよい。

この場合、送金先アカウントのユーザにより使用された併合済み制限付き電子マネーの少なくとも一部を返金する場合、サーバ１０の制御部１１は、店舗ＰＯＳシステム４０から送信される決済ＩＤを決済履歴管理データ１５７から特定する。これは、決済が行われたか否かを確認するとともに、その決済金額（返金金額）を特定するためである。

次いで、サーバ１０の制御部１１は、アカウント管理データベース１５５Ｊのうち、送金先アカウントのユーザのアカウント管理データに含まれる制限付き電子マネー使用履歴データを参照し、特定した決済ＩＤに対応する送金管理ＩＤを特定する。決済時に併合済み制限付き電子マネーが使用された場合、この送金管理ＩＤは併合管理ＩＤを含むこととなる。

特定した決済ＩＤに対応する送金管理ＩＤに併合管理ＩＤが存在する場合は、併合済み制限付き電子マネーの少なくとも一部が決済に使用されたことになる。このため、制限付き電子マネー使用履歴データから、特定した決済ＩＤに対応する使用金額を特定し、その使用金額を、併合済み制限付き電子マネー管理データのうちの対応する併合管理ＩＤの併合済み制限付き電子マネー残高に加算する。

一方、特定した決済ＩＤに対応する送金管理ＩＤに併合管理ＩＤが存在しない場合は、併合済み制限付き電子マネーは決済に使用されなかったことになる。このため、限定ではなく例として、第７変形例と同様に処理を実行することができる。

＜第１３実施例＞
上記の実施例では、通知先を含む制限が同一である場合、制限付き電子マネー併合処理を実行した。
第１３実施例は、通知先は異なるが電子マネー使用制限管理データで管理される使用制限が同一である制限付き電子マネーを併合する実施例である。

第１３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
データ構成については、限定ではなく例として、図１２－１に示したアカウント管理データベース１５５Ｊを用いることができる。

＜表示画面＞
以下の例では、第１制限付き電子マネーと第２制限付き電子マネーとには、いずれも通知に関する制限と、通知に関する制限とは異なる制限とが設定されているものとする。また、第１制限付き電子マネーと第２制限付き電子マネーとは通知先アカウントが異なるが、通知に関する制限とは異なる制限は同じであることとして説明する。

図１３－１～図１３－２は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１３－１は、端末２０Ａの表示部２４に表示されるメインメニュー画面の一例を示す図である。この例では、第１制限付き電子マネーは、通知先アカウントのユーザをユーザＢ．Ｂとするアカウントとする。

図１３－１左側では、残高表示領域ＢＲ２には、通知先アカウントがユーザＢ．Ｂである第１制限付き電子マネー残高「１，０００円」と、通常電子マネー残高「５００円」とを所有していることが表示されている。

図１３－１中央の画面は、通知先アカウントがユーザＣ．Ｃである第２制限付き電子マネー残高「２，０００円」を受け取った場合の端末２０Ａにおける表示画面の一部である。この画面では、残高表示領域ＢＲ２には、第１制限付き電子マネー残高「１，０００円」と、通常電子マネー残高「５００円」とに加えて、通知先アカウントがユーザＣ．Ｃである第２制限付き電子マネー残高「２，０００円」とが表示されている。また、第１制限付き電子マネーと第２制限付き電子マネーととの通知に関する制限とは異なる制限（限定ではなく例として、使用可能店舗）が同じであることに基づいて、サーバ１０から端末２０Ａに送信された制限付き電子マネー併合確認情報ＭＣＲ２が表示されている。

具体的には、制限付き電子マネー併合確認情報ＭＣＲ２には、「制限付き電子マネーをまとめますか？」の文字とともに、第１制限付き電子マネー残高（この例では「１，０００円」）と、その通知先アカウントがユーザＢ．Ｂのアカウントであることを示すイラストおよび制限マークＲＭＫと、第２制限付き電子マネー残高（この例では「２，０００円」）と、その通知先アカウントがユーザＣ．Ｃのアカウントであることを示すイラストおよび制限マークＲＭＫとが表示されている。

また、その下には、前述した「まとめる」ボタンＢＴ１０１と、「やめる」ボタンＢＴ１０２とが表示されている。「まとめる」ボタンＢＴ１０１がタップされると、サーバ１０によって、これら２つの制限付き電子マネーが併合（マージ）される。その結果、図１３－１右側に示すように、残高表示領域ＢＲ２には、併合済み電子マネー残高として「３，０００円」が表示される。

また、この例では、通知先アカウントがそれぞれユーザＢ．Ｂ、ユーザＣ．Ｃである２つの制限付き電子マネーを併合したため、併合済み制限付き電子マネーの通知先アカウントとして、ユーザＢ．ＢとユーザＣ．Ｃとの両方が設定されている。

「コード支払いアイコン」ＩＣ２がタップされると、図１３－２左側のようなコード支払い画面が表示される。この例では、ウォレットコード情報表示領域ＷＣＲ１には、併合済み制限付き電子マネー残高（制限付き）と、通常電子マネー残高（制限なし）とが表示されており、それぞれに対応して、前述したラジオボタンが設けられている。そして、ここでは、併合済み制限付き電子マネー残高に対応するラジオボタンが「ＯＮ」とされた状態が示されている。この状態でコード支払いが行われると、併合済み制限付き電子マネーを用いて決済が行われ、その結果、図１３－２右側のような決済結果情報が表示される。

この例では、「ＸＸ書店」で「１，８００円」の商品が購入され、併合済み制限付き電子マネーから「１，８００円」が支払い（決済）に使用されたことが示されている。また、これにより、ユーザＢ．ＢとユーザＣ．Ｃとのそれぞれに対して制限付き電子マネー使用通知が行われることが示されている。

図１３－３左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、併合済み制限付き電子マネーを使用して支払いを行ったことを示す支払い結果情報ＰＲ１２１が表示されている。

図１３－３中央は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、ユーザＡ．Ａのアカウントに制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報ＲＲ１２１（この例では「１，０００円」）が表示され、その下に、ユーザＡ．Ａによって制限付き電子マネーが使用されたことを示す制限付き電子マネー使用情報ＲＵ１２１が表示されている。

図１３－３右側は、端末２０Ｃの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、ユーザＡ．Ａのアカウントに制限付き電子マネーを送金したことを示す制限付き電子マネー送金結果情報ＲＲ１２２（この例では「２，０００円」）が表示され、その下に、ユーザＡ．Ａによって制限付き電子マネーが使用されたことを示す制限付き電子マネー使用情報ＲＵ１２２が表示されている。

＜通知の別例＞
以下、制限付き電子マネー使用通知の別例について説明する。ここでは、各々の通知先アカウントに通知される金額を「通知金額」と称する。

図１３－４は、本実施例において端末２０の表示部２４に表示される画面である図１３－３の別例を示す図である。
この例では、ユーザＡ．Ａによって支払われた金額を、併合前の第１制限付き電子マネー残高と第２制限付き電子マネー残高との残高比で分配した金額（以下、「分配金額」と称する。）を、各々の通知先アカウントへの通知金額として通知する。

この例において、ユーザＢ．ＢがユーザＡ．Ａに送金した制限付き電子マネー（第１制限付き電子マネー）の金額は「１，０００円」であり、ユーザＣ．ＣがユーザＡ．Ａに送金した制限付き電子マネー（第２制限付き電子マネー）の金額は「２，０００円」である。また、その結果、図１３－１中央に示したメインメニュー画面の残高表示領域ＢＲ２には、第１制限付き電子マネー残高が「１，０００円」であり、第２制限付き電子マネー残高が「２，０００円」であることが表示されている。

また、この例において、ユーザＡ．Ａによって支払われた金額は「１，８００円」である。
この場合、ユーザＢ．Ｂに対応する分配金額は「１，８００円×（１０００円÷３０００円）＝６００円」と計算され、ユーザＣ．Ｃに対応する分配金額は「１，８００円×（２０００円÷３０００円）＝１，２００円」と計算される。

図１３－４左側は、端末２０の表示部２４に表示される支払いアプリケーションのおしらせ画面の一例であり、図１３－３左側と同様である。

図１３－４中央は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－３中央の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２３に含まれる情報が一部異なっている。この制限付き電子マネー使用情報ＲＵ１２３には、支払い先（この例では「ＸＸ書店」）の他に、ユーザＢ．Ｂに対応する分配金額（上記のように「６００円」）がユーザＢ．Ｂへの通知金額として表示されている。

図１３－４右側は、端末２０Ｃの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－３右側の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２４に含まれる情報が一部異なっている。この制限付き電子マネー使用情報ＲＵ１２４には、支払い先（この例では「ＸＸ書店」）の他に、ユーザＣ．Ｃに対応する分配金額（上記のように「１，２００円」）がユーザＣ．Ｃへの通知金額として表示されている。

図１３－５は、本実施例において端末２０の表示部２４に表示される画面である図１３－３の別例を示す図である。
この例では、ユーザＡ．Ａによって支払われた金額を、各々の通知先アカウントに通知する。

図１３－５左側は、端末２０の表示部２４に表示される支払いアプリケーションのおしらせ画面の一例であり、図１３－３左側と同様である。

図１３－５中央は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－４中央の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２５に含まれる通知金額が異なっている。具体的には、ユーザＡ．Ａによって支払われた金額（この例では「１，８００円」）がユーザＢ．Ｂへの通知金額として表示されている。

図１３－５右側は、端末２０Ｃの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－４右側の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２６に含まれる通知金額が異なっている。具体的には、ユーザＡ．Ａによって支払われた金額（この例では「１，８００円」）がユーザＣ．Ｃへの通知金額として表示されている。

図１３－６は、本実施例において端末２０の表示部２４に表示される画面の別例を示す図である。
この例では、併合前の第１制限付き電子マネーと併合前の第２制限付き電子マネーとに優先順位をつけ、併合済み制限付き電子マネーを使用する場合に、優先順位の高い方の残高分から金額が消費されるようにする。

この場合、限定ではなく例として、残高が少ない方の優先順位を高くすることができる。つまり、決済ごとに併合済み制限付き電子マネー管理データの併合済み制限付き電子マネー残高を更新するとともに、制限付き電子マネー管理データの「（）」で囲われた制限付き電子マネー残高を更新する。このとき、残高が少ない方の制限付き電子マネーの残高分から金額が消費されるようにする。そして、支払いごとに残高を更新し、制限付き電子マネー管理データの「（）」で囲われた制限付き電子マネー残高が「０」になったら、併合済み通知付き電子マネーの併合を解除する。そして、限定ではなく例として、残高が「０」になった方の制限付き電子マネーに対応する通知先アカウントに対しては通知を行わないようにする。

この例において、ユーザＢ．ＢがユーザＡ．Ａに送金した制限付き電子マネー（第１制限付き電子マネー）の金額は「１，０００円」であり、ユーザＣ．ＣがユーザＡ．Ａに送金した制限付き電子マネー（第２制限付き電子マネー）の金額は「２，０００円」である。また、その結果、図１３－１中央に示したメインメニュー画面の残高表示領域ＢＲ２には、第１制限付き電子マネー残高が「１，０００円」であり、第２制限付き電子マネー残高が「２，０００円」であることが表示されている。
この場合、第１制限付き電子マネー残高の方が第２制限付き電子マネー残高よりも少ないため、第１制限付き電子マネー残高分から金額が消費されるようにする。

また、この例では、支払い金額は「１，８００円」である。この場合、併合済み制限付き電子マネーのうち第１制限付き電子マネー残高分から全ての金額「１，０００円」が消費され、不足分の「８００円」が、第２制限付き電子マネー残高分から消費される。

図１３－６左側は、端末２０の表示部２４に表示される支払いアプリケーションのおしらせ画面の一例であり、図１３－３左側と同様である。

図１３－６中央は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－３中央の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２７に含まれる通知金額が異なっている。具体的には、上記のようにして計算された「１，０００円」がユーザＣ．Ｃへの通知金額として表示されている。

図１３－６右側は、端末２０Ｃの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
このおしらせ画面は、図１３－３中央の画面とほぼ同様であるが、制限付き電子マネー使用情報ＲＵ１２８に含まれる通知金額が異なっている。具体的には、上記のようにして計算された「８００円」がユーザＣ．Ｃへの通知金額として表示されている。

図１３－７は、本実施例において端末２０の表示部２４に表示される画面の別例を示す図である。
図１３－７左側は、端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、残高表示領域ＢＲ２には、通知先アカウントをユーザＢ．Ｂのアカウントとする第１制限付き電子マネーと、通知先アカウントをユーザＣ．Ｃのアカウントとする第２制限付き電子マネーとが併合された併合済み制限付き電子マネーの残高（この例では「３，０００円」）が示されている。

その後、ユーザＡ．Ａが、通知先アカウントをユーザＢ．Ｂのアカウントとする第３制限付き電子マネーを新たに受け取ったとする。この場合、図１３－７中央に示すように、残高表示領域ＢＲ２には、上記の併合済み電子マネーの残高（この例では「３，０００円」）に加えて、第３制限付き電子マネーの残高（この例では「１，５００円」）が表示される。また、併合済み制限付き電子マネーにおける通知以外の使用制限と、第３制限付き電子マネーにおける通知以外の使用制限とが同一であるとする。

制限付き電子マネー併合確認情報ＭＣＲ３には、「制限付き電子マネーをまとめますか？」の文字とともに、第３制限付き電子マネーの残高（この例では「１，５００円」）、その通知先アカウントがユーザＢ．Ｂのアカウントであることを示すイラストおよび制限マークＲＭＫと、併合済み制限付き電子マネーの残高（この例では「３，０００円」）、その通知先アカウントがユーザＢ．ＢのアカウントおよびユーザＣ．Ｃのアカウントであることを示すイラストおよび制限マークＲＭＫとが表示されている。

また、その下には、前述した「まとめる」ボタンＢＴ１０１と、「やめる」ボタンＢＴ１０２とが表示されている。「まとめる」ボタンＢＴ１０１がタップされると、サーバ１０によって、第３制限付き電子マネーと、併合済み制限付き電子マネーとが併合（マージ）される。その結果、図１３－７右側に示すように、残高表示領域ＢＲ２には、新たな併合済み制限付き電子マネー残高として「４，５００円」が表示される。

なお、上記とは異なり、通知の設定がなされた制限付き電子マネー同士は、併合できないようにしてもよい。
これは、前述した家族のような例ではさほど問題は生じない可能性もあり得るが、見ず知らずのユーザが通知先アカウントとなっている制限付き電子マネー同士が併合され、見ず知らずのユーザに対して、併合済み制限付き電子マネーが使用されたことに関する通知がなされてしまう可能性があるためである。

限定ではなく例として、ユーザＸ．ＸとユーザＹ．Ｙとが赤の他人であり、それぞれ自分のアカウントを通知先アカウントとして設定してユーザＡ．Ａに送金した制限付き電子マネーが併合されたとする。この場合、ユーザＡ．Ａが併合済み制限付き電子マネーを使用することで、限定ではなく例として、ユーザＸ．ＸやユーザＹ．Ｙが、想定していない通知（限定ではなく例として、想定していた使用金額とは異なる金額を含む通知等）を受け取ってしまう可能性があるためである。

また、通知の設定がなされた制限付き電子マネー同士が併合される場合、通知の設定が解除されるようにしてもよい。この場合、通知の設定以外の使用制限は、併合された併合済み制限付き電子マネーに引き継がれる。

＜処理＞
処理については、限定ではなく例として、図１２－３のＳ７３０において、サーバ１０の制御部１１は、通知先ＩＤ以外の制限が同一か否かを判定する。

なお、前述した実施例を参酌することで、限定ではなく例として、通知付き制限付き電子マネー（通知が付与された併合済み制限付き電子マネー）において、以下の処理を実行することができる。
・送信先ＩＤのアカウントの端末２０Ａにおいて、通知付き制限付き電子マネーが使用される前に通知先ＩＤのアカウントに通知が送信されることを表示する（第３変形例）。
・送信先ＩＤのアカウントの端末２０Ａにおいて通知付き制限付き電子マネーの受取を拒否する設定を行っている場合、送金元ＩＤのアカウントの端末２０Ｂに通知付き制限付き電子マネーの送金が拒否されたことを示す情報を表示させる（第３変形例）。
・送信先ＩＤのアカウントの端末２０Ａにおいて、端末２０Ｂのアカウントからの通知付き制限付き電子マネーの受取をブロックする（第３変形例）。
・端末２０Ａにおいて通知付き制限付き電子マネーを出金する処理を実行すると、サーバ１０の制御部１１は通知付き制限付き電子マネー出金不可情報を端末２０Ａに送信する（第５実施例）。

また、制限付き電子マネーを、通知付き電子マネーと限定しても同様に実行することができる。この場合、２以上の通知付き電子マネーは、無条件に併合することができる。この場合の通知パターンは上記のとおりである。

＜第１３実施例の効果＞
本実施例は、第１制限付き電子マネーは、第１制限とは異なる制限として、通知付き電子マネーとしての制限（限定ではなく、第１端末のユーザが電子貨幣を使用したことを示す通知に関する制限の一例）が第２端末のユーザによって設定される。また、第２制限付き電子マネーは、第２制限とは異なる制限として、通知付き電子マネーとしての制限（限定ではなく、第１端末のユーザが電子貨幣を使用したことを示す通知に関する制限の一例）が第３端末のユーザによって設定される構成を示している。
このような構成により得られる実施例の効果の一例として、第１制限とは異なる、第１端末のユーザが電子貨幣を使用したことを示す通知に関する制限が第２端末のユーザによって設定された第１電子貨幣と、第２制限とは異なる、第１端末のユーザが電子貨幣を使用したことを示す通知に関する制限が第３端末のユーザによって設定された第２電子貨幣とに基づく第３電子貨幣が、第１端末のユーザに関連付けられるようにすることができる。

また、この場合、サーバ１０は、併合済み制限付き電子マネー（限定ではなく、第３電子貨幣の一例）の少なくとも一部が第１端末のユーザによって使用された場合、通知を行う制限に基づき第２端末のユーザによって設定された通知先アカウントのユーザの端末２０（限定ではなく、第４端末の一例）に制限付き電子マネー使用情報を通信Ｉ／Ｆ１４によって送信し、通知を行う制限に基づき第３端末のユーザによって設定された通知先アカウントのユーザの端末２０（限定ではなく、第５端末の一例）に制限付き電子マネー使用情報を通信Ｉ／Ｆ１４によって送信するようにすることができる。
このような構成により得られる実施例の効果の一例として、第３電子貨幣の少なくとも一部が第１端末のユーザによって使用された場合、第２端末のユーザによって設定された第４端末と、第３端末のユーザによって設定された第５端末とに、通知が行われるようにすることができる。

また、この場合、サーバ１０は、第１制限付き電子マネー（限定ではなく、第１電子貨幣の一例）と第２制限付き電子マネー（限定ではなく、第２電子貨幣の一例）とに基づく併合済み制限付き電子マネーの少なくとも一部が第１端末のユーザによって使用された場合、制限付き電子マネー使用情報を送信しない制御を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第３電子貨幣の少なくとも一部が第１端末のユーザによって使用された場合であっても、通知が行われないようにすることができる。

また、この場合、サーバ１０は、通知を行う制限が設定された併合済み制限付き電子マネー（限定ではなく、第３電子貨幣の一例）と、第１端末のユーザとを関連付けるとともに、通知を行う制限が設定された制限付き電子マネー（限定ではなく、第４電子貨幣の一例）と、第１端末のユーザとを関連付ける処理を行う。この場合、通知を行う制限が設定された併合済み制限付き電子マネーと、通知を行う制限が設定された制限付き電子マネーとは、併合することができない構成を示している。
このような構成により得られる実施例の効果の一例として、第１制限と第２制限とに基づいて、第１端末のユーザに関連付けられた第３電子貨幣に通知に関する制限が設定されており、第４電子貨幣にも通知に関する制限が設定されている場合、これらの電子貨幣に基づく第５電子貨幣とされない、いわば併合されないようにすることができる。

また、この場合、サーバ１０は、第１端末のユーザにより第１制限付き電子マネーの少なくとも一部が使用される前に、第２端末に対して通知がなされることを確認する情報を通信Ｉ／Ｆ１４によって第１端末に送信するようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザにより第１電子貨幣の少なくとも一部が使用される前に、第２端末に対して通知がされることを第１端末のユーザに知らせることができる。

また、この場合、サーバ１０は、第１端末のユーザが、通知が設定されている送金を受け取らない設定を行っている場合、第１制限付き電子マネーを第１端末のユーザに関連付けず、第１端末のユーザに送金することができないことを示す情報を、通信Ｉ／Ｆ１４によって第２端末に送信するようにすることができる。
このような構成により得られる実施例の効果の一例として、第１端末のユーザの意に反して、第１電子貨幣が第１端末のユーザに関連付けられてしまうことを防止できる。また、第１端末のユーザに送金ができないことを第２端末のユーザに知らせることができる。

また、この場合、第１端末のユーザが、通知が設定されている送金を受け取らない設定は、第２端末のユーザをブロックする設定を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２端末のユーザをブロックする設定を行うことで、通知が設定されている送金を受け取らないようにすることができる。

また、本実施例は、サーバ１０が、第１端末のユーザにより併合済み制限付き電子マネーの少なくとも一部を出金するための出金依頼情報を受信した場合、併合済み制限付き電子マネーの出金不可情報を第１端末に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザにより第３電子貨幣の少なくとも一部を出金することに関する情報を通信部によって受信した場合、出金が不可であることを第１端末のユーザに知らせることができる。

＜第１３変形例（１）＞
上記の実施例では、通知先は制限付き電子マネー併合処理を実行するか否かの判定に関与しないが、これに限定されない。限定ではなく例として、通知先が類似し、かつ通知先ＩＤ以外の制限が同一である場合、制限付き電子マネー併合処理を実行するようにしてもよい。この場合、通知先が類似していると判定される条件としては、限定ではなく例として、通知先のユーザと、送金先のユーザとの関係が２親等以内である場合等が挙げられる。このようにすることで、家族内など親しいユーザ間に通知を行う通知付き制限付き電子マネーは併合するが、赤の他人に通知を行う通知付き制限付き電子マネーを誤って併合することを避けることができる。

＜第１４実施例＞
上記の実施例では、制限が同一である場合等に、制限付き電子マネーを併合することとした。
第１４実施例は、特殊な制限付き電子マネーについては、制限等の条件に寄らず制限付き電子マネーを併合しない実施例である。

第１４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、限定ではなく例として、親から子におつかい用の電子マネーを送金する。しかし、おつかい用の電子マネーについては、おつかいによる支払いが終わった後、子から親に返還（送金）されることが望ましい。このように、ある目的のために一時的に手渡す制限付き電子マネーを、「プール用制限付き電子マネー」と呼称する。プール用制限付き電子マネーは、通知付き電子マネーであってもよいし、電子マネー使用制限管理データによる使用制限が課された制限付き電子マネーであってもよい。また、通知付き制限付き電子マネーであってもよい。

プール用制限付き電子マネーは、ある所定の時期（限定ではなく例として、おつかいが終わった夜）になると、限定ではなく例として、第１１実施例に従って、自動的に送金元ＩＤのアカウントに送金（返還）される電子マネーである。そのため、所定の時期に送金（返還）されるという制限が付与された通常電子マネー残高として扱うこともできる。

＜データ構成＞
データ構成については、限定ではなく例として、図１２－１に示したアカウント管理データベース１５５Ｊを用いることができる。
制限付き電子マネー管理データには、限定ではなく例として、送金管理ＩＤと関連付けて、電子マネー送金日時が記憶される。電子マネー送金日時には、この制限付き電子マネーの残金が送金元ＩＤに送金（返還）される日時が記憶される。電子マネー送金日時は、限定ではなく例として、送金元アカウントの端末２０Ｂにおいて、第１制限付き電子マネー送金設定処理または第２制限付き電子マネー送金設定処理、もしくはその両方において設定される日時である。

＜処理＞
処理については、限定ではなく例として、図１２－３のＳ７３０のステップにおいて、サーバ１０の制御部１１は、制限付き電子マネー管理データを参照し、第１制限付き電子マネーまたは第２制限付き電子マネーに電子マネー送金日時が設定されている場合、制限付き電子マネー併合処理を実行しない。

なお、第１制限付き電子マネーの電子マネー送金日時と、第２制限付き電子マネーの電子マネー送金日時とが同一である場合、サーバ１０の制御部１１は、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行するようにしてもよいし、そうしなくてもよい。

サーバ１０の制御部１１は、限定ではなく例として、図７－６のＳ４７０のステップを実行すると、時計部１９によって現在日時を取得し、電子マネー送金日時を超過したか否かを判定する。電子マネー送金日時を超過した場合、サーバ１０の制御部１１は、電子マネー送金日時を超過した制限付き電子マネーを返還対象として、限定ではなく例として、図１１－３のＳ６２０以降のステップを実行する。
なお、サーバ１０の制御部１１は、所定期間ごと（限定ではなく例として、毎時０分ごと）に、電子マネー送金日時を超過したか否かを判定してもよいし、そうしなくてもよい。

＜第１５実施例＞
上記の実施例では、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理を実行すると、併合済み制限付き電子マネーが生成される例を示した。
第１５実施例は、制限付き電子マネーと通常電子マネーとを併合対象とする制限付き電子マネー併合処理を実行すると、通常電子マネーに併合される実施例である。

第１５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
データ構成については、限定ではなく例として、図１２－１に示したアカウント管理データベース１５５Ｊを用いることができる。なお、制限付き電子マネー同士の併合を考慮しない場合、限定ではなく例として、図７－１に示したアカウント管理データベース１５５Ｆや、図７－７に示したアカウント管理データベース１５５Ｇを用いることができる。

＜表示画面＞
図１４－１～図１４－２は、本実施例における端末２０の表示部２４に表示される画面の一例を示す図である。
図１４－１は、端末２０Ａの表示部２４に表示される支払いアプリケーションのコード支払い画面であり、ウォレットコード情報表示領域ＷＲ２には、制限付き電子マネーの残高（この例では「３，０００円」）および制限マークＲＭＫが表示されている。また、通常電子マネー残高として「５００円」が表示されている。そして、この例では、制限マークＲＭＫがタップされ、この制限付き電子マネーの使用可能店舗（この例では「書籍・文具」）が表示された状態が示されている。

その後、「ＸＸ書店」で制限付き電子マネーを用いて「２，８００円」の支払いが行われると、図１４－１中央のような決済結果情報が表示される。

図１４－１右側は、その後、端末２０Ａの表示部２４に支払いアプリケーションのメインメニュー画面が表示された状態が示されている。この例では、制限付き電子マネーが「２００円」残ったことに基づいて、この残った金額分の制限付き電子マネーを通常電子マネーに併合するか否かを確認するための制限付き電子マネー併合確認情報ＭＣＲ４が表示されている。制限付き電子マネー併合確認情報ＭＣＲ４において、前述した「まとめる」ボタンＢＴ１０１がタップされると、限定ではなく例として、図１４－２左側の表示がなされる。

サーバ１０によって制限付き電子マネー併合処理が実行され、制限付き電子マネーが通常電子マネーに併合されたことで、残高表示領域ＢＲ２には、通常電子マネー残高として「５００円＋２００円＝７００円」が表示されている。

この状態で、限定ではなく例として、「出金」アイコンＩＣ３がタップされたとする。この場合、限定ではなく例として、図１４－２中央の画面が表示される。
この画面は、前述した支払いアプリケーションの出金画面であり、ここでは、通常電子マネー残高「７００円」のうちの「５００円」を出金するための入力がなされ、「出金」ボタンＢＴ５２がタップされた状態が示されている。

図１４－２右側は、この場合に端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面の一例を示す図である。
おしらせ領域内の向かって左側には、図１４－１中央の画面に対応する支払い結果情報ＰＲ１３１が表示され、その下に、「５００円」の出金がされたことを示す出金結果情報ＷＲ１３１が表示されている。

＜処理＞
図１４－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートであり、図７－６に相当する部分を示したものである。なお、図１４－３に先んじて、端末２０Ａのユーザが通常電子マネーをチャージするための通常電子マネーチャージ要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信し、サーバ１０の制御部１１は、受信した通常電子マネーチャージ要求情報に基づいて、端末２０Ａのアカウントに対して通常電子マネーの残高をチャージするための通常電子マネーチャージ処理を実行するようにしてもよい。

端末２０Ａの制御部２１は、支払い残高選択情報として、限定ではなく例として、任意の端末において制限が設定され、端末２０Ａのユーザに送金された第６制限付き電子マネーの送金管理ＩＤを含む支払い残高選択情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ４２０）。なお、端末２０Ａの制御部２１は、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする併合済み制限付き電子マネーの併合管理ＩＤを含む支払い残高選択情報をサーバ１０に送信するようにしてもよい。

サーバ１０の制御部１１は、受信した支払い残高選択情報に基づいて、制限付き決済処理を実行し（Ｓ４５０）、決済結果情報を送信すると（Ｓ１５０）、支払いに用いた制限付き電子マネー残高（併合済み制限付き電子マネー残高）の残高が、所定残金以下か否かを判定する（Ｓ７６０）。なお、サーバ１０の制御部１１は、Ｓ７６０において、支払いに用いた制限付き電子マネー残高（併合済み制限付き電子マネー残高）の残高が、所定残金未満か否かを判定するようにしてもよい。

ここで、所定残金とは、制限付き電子マネー残高が十分に小さくなり、その残金単体では利用が難しくなる金額である。限定ではなく例として、所定残金は、「２００」円であり、サーバ１０のユーザによって設定される金額である。なお、所定残金は、端末２０Ａのユーザによって定められる金額としてもよいし、制限付き電子マネー残高（併合済み制限付き電子マネー残高）の送金元アカウントの端末２０によって指定される金額としてもよい。通知付き制限付き電子マネーである場合、所定残金は、通知先アカウントの端末２０によって指定可能としてもよい。

なお、所定残金は、設定されたある金額に限定されない。限定ではなく例として、「所定残金」＝「残額割合」×「送金時点での制限付き電子マネー残高（併合時点での併合済み制限付き電子マネー残高）」としてもよい。限定ではなく例として、残額割合は、「５％」等、サーバ１０のユーザによって設定される割合である。なお、残額割合は、端末２０Ａのユーザによって定められる割合としてもよいし、制限付き電子マネー残高（併合済み制限付き電子マネー残高）の送金元アカウントの端末２０によって指定される割合としてもよい。通知付き制限付き電子マネーである場合、残額割合は、通知先アカウントの端末２０によって指定可能としてもよい。

支払いに用いた制限付き電子マネー残高（併合済み制限付き電子マネー残高）の残高が、所定残金以下であると判定された場合（Ｓ７６０：ＹＥＳ）、サーバ１０の制御部１１は、通常電子マネー併合処理を実行する（Ｓ７７０）。
通常電子マネー併合処理において、サーバ１０の制御部１１は、限定ではなく例として、所定残金以下であると判定された送金管理ＩＤの制限付き電子マネー残高を通常電子マネー残高に加算する。そして、制限付き電子マネー管理データから送金管理ＩＤで指定されるレコードを消去する。
併合済み制限付き電子マネー残高が所定残金以下であると判定された場合、サーバ１０の制御部１１は、併合管理ＩＤの併合済み制限付き電子マネー残高を通常電子マネー残高に加算する。そして、併合済み制限付き電子マネー管理データから併合管理ＩＤで指定されるレコードを消去する。加えて、サーバ１０の制御部１１は、制限付き電子マネー管理データから、併合前送金管理ＩＤとして記憶された送金管理ＩＤのレコードを消去するようにしてもよい。

なお、通常電子マネーは、通知無し制限無し電子マネーとしての制限付き電子マネーとみなすこともできる。そのため、通常電子マネー併合処理は、制限付き電子マネー併合処理の一種とみなすこともできる。

また、通常電子マネー併合処理は、条件なしに実行されるようにしてもよい。

通常電子マネー併合処理が実行されると、サーバ１０の制御部１１は、通常電子マネー併合処理結果情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。なお、サーバ１０の制御部１１は、通常電子マネー併合処理結果情報を、通常電子マネー併合処理で併合された制限付き電子マネーの送金元アカウントの端末２０や、通知先アカウントの端末２０に送信するようにしてもよい。

支払いに用いた制限付き電子マネー残高（併合済み制限付き電子マネー残高）の残高が、所定残金より大きいと判定された場合（Ｓ７６０：ＮＯ）、サーバ１０の制御部１１は、Ｓ７７０とＳ７８０とのステップをスキップする。

通信Ｉ／Ｆ２２によってサーバ１０から通常電子マネー併合処理結果情報を受信すると判定される場合（Ｓ７４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した通常電子マネー併合処理結果情報を表示部２４に表示させる（Ａ７５０）。
サーバ１０から通常電子マネー併合処理結果情報を受信しないと判定される場合（Ｓ７４０：ＮＯ）、端末２０Ａの制御部２１は、Ａ７５０のステップをスキップする。

そして、端末２０Ａの制御部２１は、限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、通常電子マネー残高を出金することに関する通常電子マネー出金依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。通信Ｉ／Ｆ１４によって端末２０Ａから通常電子マネー出金依頼情報を受信すると、サーバ１０の制御部１１は、通常電子マネー出金処理を実行する。サーバ１０の制御部１１は、通常電子マネー出金処理の処理結果である通常電子マネー出金処理結果情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信し、端末２０Ａの制御部２１は、受信した通常電子マネー出金処理結果情報を表示部２４に表示させるようにしてもよい。

なお、限定ではなく例として、端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、制限付き電子マネー残高（併合済み制限付き電子マネー残高）から出金することに関する制限付き電子マネー出金依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。通信Ｉ／Ｆ１４によって端末２０Ａから制限付き電子マネー出金依頼情報を受信すると、サーバ１０の制御部１１は、出金が出来ないことを示す制限付き電子マネー出金不能情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。通信Ｉ／Ｆ２２によってサーバ１０から制限付き電子マネー出金不能情報を受信すると、端末２０Ａの制御部２１は、受信した制限付き電子マネー出金不能情報を表示部２４に表示させる。

＜第１５実施例の効果＞
本実施例は、第６制限付き電子マネー（限定ではなく例として、第４端末のユーザによって第３制限が設定された、第４端末から第１端末に送金された第６電子貨幣の一例）と、端末２０Ａ（限定ではなく、第１端末の一例）のユーザとを関連付ける制限付き電子マネー送金処理と、通常電子マネー（限定ではなく例として、制限が設定されていない第７電子貨幣の一例）と、第１端末のユーザとを関連付ける通常電子マネーチャージ処理とを、サーバの制御部によって行うことと、制限付き電子マネー出金依頼情報（限定ではなく例として、第１端末のユーザにより第６電子貨幣の少なくとも一部を現金として出金することに関する情報の一例）を受信した場合、現金による出金が不可であることを示す制限付き電子マネー出金不能情報（限定ではなく例として、出金不可情報の一例）を第１端末に送信し、通常電子マネー出金依頼情報（限定ではなく例として、第６電子貨幣と第７電子貨幣とに基づく第８電子貨幣の少なくとも一部を現金として出金することに関する情報の一例）を受信した場合、通常電子マネー（限定ではなく、第８電子貨幣の一例）の少なくとも一部を現金として出金することに関する通常電子マネー出金処理を制御部によって行うこととがサーバによって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザにより第６電子貨幣の少なくとも一部を出金することに関する情報を受信した場合、出金が不可であることを第１端末のユーザに知らせることができる。その一方で、第６電子貨幣と第７電子貨幣とに基づく第８電子貨幣の少なくとも一部を出金することに関する情報を受信した場合、第８電子貨幣の少なくとも一部を出金することを可能とすることができる。

また、本実施例は、制限付き電子マネー（限定ではなく、第６電子貨幣の一例）は、その制限付き電子マネー残高が所定残金以下となる条件（限定ではなく、設定された合算条件の一例）に基づいて、通常電子マネー（限定ではなく、第７電子貨幣の一例）と合算可能になり、第８電子貨幣は、第６電子貨幣と第７電子貨幣とが合算された電子貨幣である構成を示している。
このような構成により得られる実施例の効果の一例として、設定された合算条件に基づいて、第６電子貨幣を第７電子貨幣と合算して第８電子貨幣とすることができる。

また、本実施例は、合算条件は、所定残金（限定ではなく、第６電子貨幣の残高の一例）に関する条件、または残額割合（限定ではなく、第１端末に送金された第６電子貨幣の金額に対する残高の割合の一例）に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第６電子貨幣の残高に関する条件、または第１端末に送金された第６電子貨幣の金額に対する残高の割合に関する条件に基づいて、第６電子貨幣を第７電子貨幣とが適切に合算されるようにすることができる。

＜第１６実施例＞
上記の実施例では、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする併合済み制限付き電子マネーを用いて制限付き決済処理を行う例を示した。
第１６実施例は、併合済み制限付き電子マネーを用いて連続制限付き決済処理を実行する実施例である。

第１６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

限定ではなく例として、第１制限付き電子マネーと第２制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理において、第１併合済み制限付き電子マネーに併合されるとする。また、限定ではなく例として、第３制限付き電子マネーと第４制限付き電子マネーとを併合対象とする制限付き電子マネー併合処理において、第２併合済み制限付き電子マネーに併合されるとする。

この場合、限定ではなく例として、第１２実施例を参酌し、図１２－３のフローに従って、制限付き電子マネー併合処理を実行後、第９実施例を参酌し、図８－３のフローに従って、連続制限付き決済処理を実行することで、限定ではなく例として、以下の組み合わせにおいて決済処理を実行することができる。
・通常電子マネーと第１併合済み制限付き電子マネー
・通常電子マネーと第２併合済み制限付き電子マネー
・第１併合済み制限付き電子マネーと第２併合済み制限付き電子マネー
・通常電子マネーと第１併合済み制限付き電子マネーと第２併合済み制限付き電子マネー
・第５制限付き電子マネーと第１併合済み制限付き電子マネー
・第５制限付き電子マネーと第２併合済み制限付き電子マネー
・第５制限付き電子マネーと第１併合済み制限付き電子マネーと第２併合済み制限付き電子マネー
・通常電子マネーと第５制限付き電子マネーと第１併合済み制限付き電子マネー
・第５制限付き電子マネーと第６制限付き電子マネーと第１併合済み制限付き電子マネー
・通常電子マネーと第５制限付き電子マネーと第６制限付き電子マネーと第１併合済み制限付き電子マネーと第２併合済み制限付き電子マネー

すなわち、支払いには、通常電子マネーと、制限付き電子マネーと、併合済み制限付き電子マネーとの任意の組み合わせを用いて決済を実行することができる。

＜その他の実施例＞
上記の実施例では、電子貨幣を用いた支払い方法として、「利用者提示型」のコード支払いについて説明したが、これに限定されない。限定ではなく例として、「店舗提示型」のコード支払いを用いて処理を実行するようにしてもよい。
この場合、店舗ＰＯＳシステム４０は不用である。「店舗提示型」のコード支払いにおける処理としては、まず、端末２０Ａの制御部２１は、ウォレット支払い要求情報送信すると、サーバ１０は、端末２０にアカウント識別情報を送信する。限定ではなく例として、端末２０Ａの制御部２１は、撮像部２７によって、支払いを行う店舗に提示された店舗情報（店舗識別用コード情報）を読み取る。なお、端末２０Ａの制御部２１は、撮像部２７によって、購入する商品・サービスの画像を撮像し、撮像された画像に基づいて、購入する商品・サービスを識別するようにしてもよい。「利用者提示型」のコード支払いとは異なり、支払い金額を入力する前に、端末２０Ａの制御部２１は、各制限付き電子マネーにおいて使用可能な残高を判定することができる。そのため、「店舗提示型」のコード支払いでは、使用可能合算残高を参照して、支払い金額を入力することができる。なお、端末２０Ａの制御部２１は、店舗情報や撮像された画像をサーバ１０に送信し、サーバ１０において受信した店舗情報や撮像された画像に基づいて、使用可能合算残高を算出するようにしてもよい。
端末２０Ａの入出力部２３に対する入力（ユーザ操作）に基づいて、支払い金額が入力されると、端末２０Ａの制御部２１は、アカウント識別情報と店舗情報と支払い金額とを少なくとも含む決済要求情報をサーバ１０に送信し、サーバ１０は、受信した決済要求情報に基づいて、決済処理（制限付き決済処理・連続制限付き決済処理）を実行する。

なお、電子貨幣を用いた支払い方法として、コード支払いではなく、ＮＦＣ等の近距離無線通信を使用した支払い方法（ＮＦＣ決済）としてもよい。この場合、サーバ１０からウォレットコード情報を受信すると、端末２０Ａの制御部２１は、ウォレットコード情報を通信Ｉ／Ｆ２２によって店舗ＰＯＳシステム４０に送信する。通信Ｉ／Ｆ５４によって端末２０Ａからウォレットコード情報を受信すると、受信したウォレットコード情報に基づいて、決済要求情報をサーバ１０に送信する。

＜その他＞
上記の実施例では、端末を使用して支払いを行う例を例示したが、これに限定されない。限定ではなく例として、複数のサーバ１０（サーバ１０Ａ、サーバ１０Ｂ、・・・）において、サーバ１０Ａのユーザのアカウントにアカウント管理データを紐付ける。また、サーバ１０Ｂのユーザのアカウントにアカウント管理データを紐付ける。そして、端末２０Ａにおいて実行される処理をサーバ１０Ａに、端末２０Ｂにおいて実行される処理をサーバ１０Ｂに、それぞれ実行させるようにしてもよい。
なお、送金元アカウントの情報処理装置をサーバ１０Ｂ、送金先アカウントの情報処理装置を端末２０Ａとしてもよいし、そうしなくてもよい。また、送金元アカウントの情報処理装置を端末２０Ｂ、送金先アカウントの情報処理装置をサーバ１０Ａとしてもよいし、そうしなくてもよい。

１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
４０ 店舗ＰＯＳシステム

Claims (22)

1. 第１端末および第２端末と通信するサーバによって実行されるプログラムであって、
   前記第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を前記第２端末のユーザに送金することに関する情報である第１情報を前記サーバの通信部によって前記第１端末から受信することと、
   前記第１情報の受信に基づき、前記第２端末のユーザに送金される前記第１電子貨幣を前記第２端末のユーザに関連付けて記憶する制御を前記サーバの制御部によって行うことと、
   前記第１情報の受信に基づき、前記第２端末のユーザに第１端末から送金されたことを示す第２情報を前記通信部によって前記第２端末に送信することと、
   前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が使用されたことに基づき、前記通知を第３端末に前記通信部によって送信することとが前記サーバによって実行される。
2. 請求項１に記載のプログラムであって、
   前記通知は、前記第２端末のユーザによって、前記第１電子貨幣の少なくとも一部が使用されたことを示す情報を含む。
3. 請求項２に記載のプログラムであって、
   前記通知は、前記第２端末のユーザによって前記第１電子貨幣のうち使用された金額、前記第２端末のユーザによって使用された場所、前記第２端末のユーザによって購入された商品、前記第２端末のユーザによって購入されたサービスのうち少なくとも一つを含む。
4. 請求項１から請求項３のいずれか一項に記載のプログラムであって、
   前記通知は、前記第１電子貨幣の残高が設定された金額以下、または設定された金額よりも小さい場合、前記サーバによって送信されない。
5. 請求項１から請求項４のいずれか一項に記載のプログラムであって、
   前記通知は、前記第１電子貨幣のうち前記第２端末のユーザによって使用された金額が設定された金額以下、または設定された金額よりも小さい場合、前記サーバによって送信されない。
6. 請求項１から請求項５のいずれか一項に記載のプログラムであって、
   前記通知は、前記第１端末のユーザによって設定されたタイミングで、前記サーバによって送信される。
7. 請求項１から請求項６のいずれか一項に記載のプログラムであって、
   前記第２端末のユーザに送金された前記第１電子貨幣に対して前記通知の設定がされていることを示す通知設定情報を、前記通信部によって前記第２端末に送信することが前記サーバによって実行される。
8. 請求項７に記載のプログラムであって、
   前記第２端末に前記通知設定情報が送信されたことに基づき、前記第２端末から送信された、前記第２端末のユーザへの送金の許可に関する許可情報を前記通信部によって受信することが前記サーバによって実行され、
   前記第１電子貨幣は、前記許可情報の受信に基づいて、前記第２端末のユーザに関連付けて記憶される。
9. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
   前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が使用される前に、前記第３端末に対して前記通知されることに関する第３情報を前記通信部によって前記第２端末に送信することが前記サーバによって実行される。
10. 請求項１から請求項９のいずれか一項に記載のプログラムであって、
    前記第２端末のユーザが、前記通知が設定されている送金を受け取らない設定を行っている場合、前記第１電子貨幣を前記第２端末のユーザに関連付けることを行わず、前記第２端末のユーザに送金ができないことを示す送金不可情報を前記第１端末に送信することが前記サーバによって実行される。
11. 請求項１０に記載のプログラムであって、
    前記第２端末のユーザが、前記通知が設定されている送金を受け取らない設定は、前記第１端末のユーザをブロックする設定を含む。
12. 請求項１から請求項１１のいずれか一項に記載のプログラムであって、
    前記第３端末は、前記第１端末である。
13. 請求項１から請求項１２のいずれか一項に記載のプログラムであって、
    前記通知に関する設定は、前記第１端末とは異なる前記第３端末に前記通知を行うことに関する設定を含む。
14. 請求項１から請求項１３のいずれか一項に記載のプログラムであって、
    前記通知が設定された前記第１電子貨幣と、前記通知が設定されていない、前記第２端末のユーザに対して関連付けられた第２電子貨幣とを区別して記憶する制御を前記制御部によって行うことが前記サーバによって実行される。
15. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が出金された場合、前記通知を前記第３端末に前記通信部によって送信することが前記サーバによって実行される。
16. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記第２端末により前記第１電子貨幣の少なくとも一部を出金することに関する情報を前記通信部によって受信した場合、出金が不可であることを示す出金不可情報を前記第２端末に前記通信部によって送信することが前記サーバによって実行される。
17. 請求項１から請求項１６のいずれか一項に記載のプログラムであって、
    前記第２端末のユーザにより使用された前記第１電子貨幣の少なくとも一部を返金する場合、前記第１電子貨幣の少なくとも一部に前記通知が設定された状態で、前記第２端末のユーザに返金する制御を前記制御部によって行うことが前記サーバによって実行される。
18. 請求項１から請求項１７のいずれか一項に記載のプログラムであって、
    前記通知を前記第３端末のユーザを含むチャットルームに送信する制御を前記制御部によって行うことが前記サーバによって実行される。
19. 請求項１８に記載のプログラムであって、
    前記第３端末は、前記第１端末であり、
    前記チャットルームは、前記第１端末のユーザと、前記第２端末のユーザとを含み、
    前記第１端末のユーザによって、前記チャットルームに表示された前記通知への入力が行われた場合、設定された期間ごとに、前記通知の設定が行われた電子貨幣が前記第２端末のユーザに対して送金される金額を入力するための情報を前記通信部によって前記第１端末に送信することが前記サーバによって実行される。
20. 第１端末および第２端末と通信するサーバの情報処理方法であって、
    前記第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を前記第２端末のユーザに送金することに関する情報である第１情報を前記サーバの通信部によって前記第１端末から受信することと、
    前記第１情報の受信に基づき、前記第２端末のユーザに送金される前記第１電子貨幣を前記第２端末のユーザに関連付けて記憶する制御を前記サーバの制御部によって行うことと、
    前記第１情報の受信に基づき、前記第２端末のユーザに第１端末から送金されたことを示す第２情報を前記通信部によって前記第２端末に送信することと、
    前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が使用されたことに基づき、前記通知を第３端末に前記通信部によって送信することとを含む。
21. 第１端末および第２端末と通信するサーバであって、
    前記第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を前記第２端末のユーザに送金することに関する情報である第１情報を前記第１端末から受信する通信部と、
    前記第１情報の受信に基づき、前記第２端末のユーザに送金される前記第１電子貨幣を前記第２端末のユーザに関連付けて記憶する制御を行う制御部とを備え、
    前記通信部は、前記第１情報の受信に基づき、前記第２端末のユーザに第１端末から送金されたことを示す第２情報を前記第２端末に送信し、前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が使用されたことに基づき、前記通知を第３端末に送信する。
22. 第１端末および第２端末と通信するサーバであって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
    前記プロセッサーは、
    前記第１端末のユーザによって通知に関する設定が行われた第１電子貨幣を前記第２端末のユーザに送金することに関する情報である第１情報を前記サーバの通信部によって前記第１端末から受信することと、
    前記第１情報の受信に基づき、前記第２端末のユーザに送金される前記第１電子貨幣を前記第２端末のユーザに関連付けて記憶する制御を実行することと、
    前記第１情報の受信に基づき、前記第２端末のユーザに第１端末から送金されたことを示す第２情報を前記通信部によって前記第２端末に送信することと、
    前記第２端末のユーザにより前記第１電子貨幣の少なくとも一部が使用されたことに基づき、前記通知を第３端末に前記通信部によって送信することとを実行する。

Images