JP7089551B2

JP7089551B2 - プログラム、情報処理方法、サーバ、端末

Info

Publication number: JP7089551B2
Application number: JP2020104383A
Authority: JP
Inventors: 亮介濱窄; 洋輔真崎
Original assignee: Line Corp
Current assignee: Line Corp
Priority date: 2020-06-17
Filing date: 2020-06-17
Publication date: 2022-06-22
Anticipated expiration: 2040-06-17
Also published as: JP2022001971A; JP2022010423A

Description

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

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

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

本発明の第１の態様によると、端末と通信するサーバによって実行されるプログラムは、第１ユーザによる送金依頼に関する第１情報をサーバの通信部によって端末に送信することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を通信部によって端末に送信する制御をサーバの制御部によって行い、送金処理が実行された場合、第２情報を通信部によって端末に送信しない制御を制御部によって行うこととがサーバによって実行される。
本発明の第２の態様によると、端末と通信するサーバの情報処理方法は、第１ユーザによる送金依頼に関する第１情報をサーバの通信部によって端末に送信することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を通信部によって端末に送信する制御をサーバの制御部によって行い、送金処理が実行された場合、第２情報を通信部によって端末に送信しない制御を制御部によって行うこととを含む。
本発明の第３の態様によると、端末と通信するサーバは、第１ユーザによる送金依頼に関する第１情報を端末に送信する通信部と、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を通信部によって端末に送信する制御を行い、送金処理が実行された場合、第２情報を通信部によって端末に送信しない制御を行う制御部とを備える。
本発明の第４の態様によると、端末と通信するサーバは、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第１ユーザによる送金依頼に関する第１情報をサーバの通信部によって端末に送信することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を通信部によって端末に送信する制御を行い、送金処理が実行された場合、第２情報を通信部によって端末に送信しない制御を行うこととを実行する。
本発明の第５の態様によると、端末によって実行されるプログラムは、第１ユーザによる送金依頼に関する第１情報を端末の通信部によって受信することと、第１情報に基づく第１表示を端末の表示部によって表示することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく第２表示を表示部に表示する制御を端末の制御部によって行い、送金処理が実行された場合、第２表示を表示部に表示しない制御を制御部によって行うこととが端末によって実行され、前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
本発明の第６の態様によると、端末の情報処理方法は、第１ユーザによる送金依頼に関する第１情報を端末の通信部によって受信することと、第１情報に基づく第１表示を端末の表示部によって表示することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく第２表示を表示部に表示する制御を端末の制御部によって行い、送金処理が実行された場合、第２表示を表示部に表示しない制御を制御部によって行うこととを含み、前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
本発明の第７の態様によると、端末は、第１ユーザによる送金依頼に関する第１情報を受信する通信部と、第１情報に基づく第１表示を表示する表示部と、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく第２表示を表示部に表示する制御を行い、送金処理が実行された場合、第２表示を表示部に表示しない制御を行う制御部とを備え、前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
本発明の第８の態様によると、端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第１ユーザによる送金依頼に関する第１情報を端末の通信部によって受信することと、第１情報に基づく第１表示を端末の表示部によって表示することと、送金依頼に基づく、第１ユーザへの送金に関する送金処理が実行されない場合、送金依頼に基づく第２表示を表示部に表示する制御を行い、送金処理が実行された場合、第２表示を表示部に表示しない制御を行うこととを実行し、前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。

実施形態の一態様における通信システムの構成の一例を示す図。第１実施例に係るサーバの制御部により実現される機能の一例を示す図。第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。第１実施例に係るユーザ登録データの一例を示す図。第１実施例に係るユーザ管理データベースの一例を示す図。第１実施例に係る送金リクエスト管理データの一例を示す図。第１実施例に係る端末の制御部により実現される機能の一例を示す図。第１実施例に係る端末の記憶部に記憶される情報の一例を示す図。第１実施例に係る端末の表示画面の一例を示す図。第１実施例に係る端末の表示画面の一例を示す図。第１実施例に係る端末の表示画面の一例を示す図。第１実施例に係る端末の表示画面の一例を示す図。第１実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第１実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第１変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第２実施例に係る送金リクエスト管理データの一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末の表示画面の一例を示す図。第２実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第２実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第２変形例に係る端末の表示画面の一例を示す図。第２変形例に係る端末の表示画面の一例を示す図。第２変形例に係る端末の表示画面の一例を示す図。第２変形例に係る端末の表示画面の一例を示す図。第２変形例に係る端末の表示画面の一例を示す図。第２変形例に係る端末の表示画面の一例を示す図。第３実施例に係るタイミングチャートの一例を示す図。第３変形例に係るタイミングチャートの一例を示す図。第４実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第４実施例に係る送金リマインド条件データの一例を示す図。第４実施例に係る端末の表示画面の一例を示す図。第４実施例に係る端末の表示画面の一例を示す図。第４変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第５実施例に係る端末の表示画面の一例を示す図。第５実施例に係る端末の表示画面の一例を示す図。第５実施例に係る端末の表示画面の一例を示す図。第５実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第５実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る送金リクエストメッセージや送金リマインドメッセージの表示方法に関するテーブルの一例を示す図。第５変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第５変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第５変形例に係る端末の表示画面の一例を示す図。第６実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第６実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第６変形例に係る端末の表示画面の一例を示す図。第６変形例に係る端末の表示画面の一例を示す図。第６変形例に係る端末の表示画面の一例を示す図。第６変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第６変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第６変形例に係る端末の表示画面の一例を示す図。第６変形例に係る端末の表示画面の一例を示す図。第７実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第７実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第７変形例に係る送金リクエストに関連する情報の表示態様に関するテーブルの一例を示す図。第７変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第７変形例に係る端末、サーバの処理の流れの一例を示すフローチャート。第８実施例に係る送金リクエスト管理データの一例を示す図。第８実施例に係る送金リマインド判定テーブルの一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末の表示画面の一例を示す図。第８実施例に係る端末、サーバの処理の流れの一例を示すフローチャート。第８変形例に係るリマインド停止管理データの一例を示す図。第９実施例に係る送金リマインド判定テーブルの一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。第９実施例に係る端末の表示画面の一例を示す図。

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

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

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

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

サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に支払いサービスやメッセージングサービスを提供する機能を有する。サーバ１０は、支払い管理（メッセージング管理）サーバや支払いサービス（メッセージングサービス）サーバ等のように表現することもできる。

端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ、・・・）は、各実施例において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（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(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。

以下では、本発明をサーバクライアントシステムによって実現する実施例について説明する。

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

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

＜概要＞
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子貨幣による支払いを行うためのアプリケーション（支払いアプリケーション）、電子貨幣による決済を行うためのアプリケーション（決済アプリケーション）、電子貨幣による送金／受取を行うためのアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子貨幣（電子マネー）を用いた各種のサービスを受けることが可能になってきている。

「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末２０、または端末２０のユーザが所有する電子的な貨幣を意味する。

なお、電子貨幣は、「電子マネー」や「デジタル通貨（デジタル貨幣）」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」には、暗号通貨（暗号資産）を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。

本明細書では、基本的に「電子マネー」の用語を用いることとし、限定ではなく例として、端末２０のユーザの電子マネー口座の残高のことを「電子マネー口座残高」と称する。

また、以下では、端末２０のユーザから異なる端末２０のユーザ（相手のユーザ）に対して送金を行うように依頼することを「送金リクエスト」（送金依頼と同義。）と称する。そして、この送金リクエストに関する情報を「送金リクエスト情報」と称する。
送金を依頼することを「送金リクエストする」、「送金リクエストを行う」等のように表現する場合がある。
また、送金を依頼されることを「送金リクエストされる」、「送金リクエストが行われる」、等のように表現する場合がある。

また、以下では、送金リクエストの内容を相手のユーザに思い出させること、想起させること、再確認させること等を意味する用語を「送金リマインド」と称し、この送金リマインドに関する情報を「送金リマインド情報」と称する。
送金をリマインドすることを「送金リマインドする」、「送金リマインドを行う」等のように表現する場合がある。
また、送金をリマインドされることを「送金リマインドされる」、「送金リマインドが行われる」等のように表現する場合がある。

また、以下では、便宜的に、送金リクエストする側のユーザを「送金マスターユーザ」と称し、送金リクエストされる側のユーザを「送金リクエスト先ユーザ」と称する。
送金マスターユーザは、「送金リクエスト元ユーザ」や「送金リクエスト主ユーザ」等のように表現することもできる。

また、以下では、端末２０にインストールされた支払いアプリケーションやメッセージングアプリケーションによって、本発明に係る各種の処理が実行されることとして説明する。この場合、限定ではなく例として、支払いアプリケーションの一機能としてメッセージングサービスの機能を持たせる、またはメッセージングアプリケーションの一機能として支払いサービスの機能を持たせるようにすることができる。

メッセージングサービスでは、ユーザが、チャットルームを利用してチャットを行うことができるように構成されている。
チャットルームとは、コンピュータネットワーク上のデータ通信回線を用いて端末２０の１以上のユーザがコミュニケーションを行うための仮想的な部屋である。
メッセージングサービスでは、チャットルームを「トークルーム」と称する場合がある。

トークルームには、限定ではなく例として、一対一でユーザがトークを行うためのトークルームの他、メッセージングサービスにおいて形成された複数のユーザを含むグループでトークを行うためのグループトークルームが含まれる。

また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。

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

以下説明する実施例では、送金マスターユーザから送金リクエスト先ユーザに対する送金リクエストが行われた後、送金リマインドを行う。そして、送金リクエスト先ユーザの端末２０に表示される送金リマインド情報に基づく表示（以下、「送金リマインド表示」と称する。）に対する入力に基づいて、送金リクエスト先ユーザから送金マスターユーザへの送金を実現する。

＜第１実施例＞
第１実施例は、送金リクエスト先ユーザの端末２０が、受け取り済みの送金リクエストに基づいて、自動で送金リマインド表示を行う実施例である。以下、この手法を「端末リマインド」と称する。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

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

図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、制御部１１によって読み出され、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム１５１と、ユーザ登録データ１５３と、ユーザ管理データベース１５５と、送金リクエスト管理データ１５７とが記憶される。

ユーザ登録データ１５３は、支払いアプリケーションを利用する端末２０、またはその端末２０のユーザに関する登録データであり、そのデータ構成の一例を図１－４に示す。
ユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、端末電話番号と、その他登録情報とが関連付けて記憶される。

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

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

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

その他登録情報には、限定ではなく例として、端末２０のＩＤ：端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））、このユーザ名のユーザの端末２０のメールアドレス（端末メールアドレス）、支払いアプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワードを）等の認証情報等の情報を含めるようにすることができる。

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤとすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、アプリケーションＩＤとすることができる。なお、これを「ユーザＩＤ」としてもよいし、しなくてもよい。

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

なお、限定ではなく例として、１つのユーザＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。

ユーザ管理データベース１５５は、支払いアプリケーションを利用する端末２０、またはそのユーザに関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、その一例である第１ユーザ管理データベース１５５Ａの構成一例を図１－５に示す。

第１ユーザ管理データベース１５５Ａには、アプリケーションＩＤごとの管理データとして、ユーザ管理データが記憶される。
各々のユーザ管理データには、限定ではなく例として、アプリケーションＩＤと、そのアプリケーションＩＤによって識別されるユーザの電子マネー口座残高と、送金履歴データと、受金履歴データとが記憶される。

送金履歴データは、このアプリケーションＩＤのユーザから他のアプリケーションＩＤのユーザへの送金の履歴の情報（送金履歴情報）が記憶されたデータである。

受金履歴データは、このアプリケーションＩＤのユーザの他のアプリケーションＩＤのユーザからの受金の履歴の情報（受金履歴情報）が記憶されたデータである。

送金リクエスト管理データ１５７は、送金リクエストに関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、その一例である第１送金リクエスト管理データ１５７Ａの構成例を図１－６に示す。
第１送金リクエスト管理データ１５７Ａには、限定ではなく例として、日時と、送金リクエスト管理ＩＤと、送金マスターＩＤと、送金リクエスト先ＩＤと、送金リクエスト金額と、送金済みフラグとが関連付けて記憶される。

日時には、限定ではなく例として、対応する送金リクエストの送金リクエスト情報がサーバ１０から送金リクエスト先ユーザの端末２０に送信された日時が記憶される。

送金リクエスト管理ＩＤには、送金リクエストごとにサーバ１０によって一意に設定されるＩＤが記憶される。

送金マスターＩＤには、送金マスターユーザのアプリケーションＩＤが記憶される。
送金リクエスト先ＩＤには、送金リクエスト先ユーザのアプリケーションＩＤが記憶される。

送金リクエスト金額には、その送金リクエストによって送金マスターユーザから送金リクエスト先ユーザに送金が依頼された金額が記憶される。

送金済みフラグは、その送金リクエストに対応する送金が行われたか否かを識別するためのフラグであり、当初は「ＯＦＦ」に設定されており、送金が完了することで「ＯＮ」に設定される。

ここで、サーバ１０が送金リクエストを管理する手法としては、大きく分けて、以下の２つのパターンが考えられる。
「パターンＡ」：送金済み（送金済みフラグＯＮ）となった送金リクエストを削除せずに残す。
「パターンＢ」：送金済み（送金済みフラグＯＮ）となった送金リクエストを削除する。

どちらのパターンを適用することもできるが、以下では、基本的には「パターンＡ」の手法を適用するものとする。
つまり、サーバ１０は、送金済みフラグを「ＯＮ」に設定した送金リクエストについても、そのデータを削除せずに残すものとする。

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

図１－８は、本実施例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、制御部２１によって読み出され、支払いアプリケーション処理として実行される支払いアプリケーション処理プログラム２８１と、自己の端末２０またはそのユーザに関連付けられたアプリケーションＩＤ２８３とが記憶される。

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

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

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

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

図１－９は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。
表示部２４には、端末２０により実行される支払いアプリケーションの機能に基づいて、端末２０のユーザ（支払いアプリケーションのユーザ）に対して、送金リクエスト情報を受信したことを通知する送金リクエスト表示ＭＳ１が表示されている。

限定ではなく例として、送金リクエスト表示ＭＳ１は、プッシュ形式で表示される通知（以下、「プッシュ通知」と称する。）であり、その表示が支払いアプリケーションの機能に基づくことを示す「ＰａｙｍｅｎｔＡｐｐ」という文字およびアイコンと、送金リクエスト情報を受信したことと、送金リクエストを行った第１ユーザのユーザ名とを通知するメッセージ（限定ではなく例として、「Ａ．Ａ」、「送金リクエストがあります。」）とを含む。

また、送金リクエスト表示ＭＳ１の左側には、送金リクエストに関する詳細な情報を確認するためのボタンＢＴ１が表示されている。
限定ではなく、送金リクエスト表示ＭＳ１とボタンＢＴ１は、第１ユーザ（本例ではＡ．Ａ）による送金リクエストに関する第１情報（限定ではなく例として、送金リクエスト情報）を端末２０が受信したことに基づいて表示される第１表示の一例である。
ユーザが「開く」の文字が示されたボタンＢＴ１をタップすることで、支払いアプリケーションの機能に基づいて、送金リクエストの詳細が表示される。

図１－１０は、送金リクエスト情報を受信した端末２０のユーザがＢ．Ｂである例を示している。すなわち、図１－９において、端末２０のユーザであるＢ．Ｂが、ボタンＢＴ１をタップした結果、図１－１０に示す画面に移行する。
画面最上部中央には、この画面が支払いアプリケーションの機能に基づくことを示す「ＰａｙｍｅｎｔＡｐｐ」の文字が表示されている。その右側には、この端末２０の支払いアプリケーションにおけるユーザのアイコン画像およびユーザ名（本例では「Ｂ．Ｂ」）が表示されている。

また、その下方には、第１ユーザのユーザ名と、そのユーザから送金リクエスト情報を受信していることを示すメッセージ（限定ではなく例として、「Ａ．Ａ」、「送金リクエストがあります。」）が表示されている。
さらに下方には、送金リクエストの詳細を示す送金リクエスト表示ＭＳ２が表示されている。

送金リクエスト表示ＭＳ２は、その表示が送金リクエスト情報を受信したことに基づく表示であることを示すアイコン（本例では「リクエスト受信」の文字のアイコン）と、送金リクエストを行った第１ユーザ（Ａ．Ａ）のアイコン画像と、送金リクエスト情報により指定された金額であって第１ユーザに対して端末２０のユーザ（Ｂ．Ｂ）が送金すべき送金額（本例では「３，０００円」）と、端末２０のユーザが支払いを行う立場であることを通知するアイコン（本例では「支払い」の文字のアイコン）と、送金リクエスト情報を端末２０が受信した日時（本例では「２０２０．０４．２０２１：３０」）と、第１ユーザのユーザ名と、そのユーザから送金リクエスト情報を受信していることを示すメッセージ（本例では「Ａ．Ａさんから送金リクエストがあります。」）と、送金リクエストに関するより詳細な情報を表示させるためのリンク情報（本例では「＞詳細を確認」という文字が表示された部分）と、を含む。

さらに、送金リクエスト表示ＭＳ２は、支払いアプリケーションの機能に基づいて、第１ユーザ（Ａ．Ａ）に対して送金処理を実行するための送金ボタンＢＴ２を含む。
限定ではなく、送金リクエスト表示ＭＳ２は、第１ユーザ（本例ではＡ．Ａ）による送金依頼に関する第１情報に基づいて表示される第１表示の一例である。

この画面で、端末２０のユーザ（Ｂ．Ｂ）が、送金ボタンＢＴ２をタップすると、送金リクエスト情報により指定された金額を送金するための送金画面（限定ではなく例として、図２－８の画面）に移行する。この送金画面において画面下部の送金領域ＲＭ２をタップすると、送金確認画面（限定ではなく例として、図２－９の画面）に移行する。
端末２０のユーザＢ．Ｂが、送金確認画面において確認ボタンＢＴ６をタップすることで、送金リクエストにより指定された金額（送金リクエスト金額：送金リクエスト表示ＭＳ２により示されている金額）が、端末２０のユーザＢ．Ｂの電子マネー口座から第１ユーザ（Ａ．Ａ）の電子マネー口座に送金される。

第１ユーザ（Ａ．Ａ）の送金リクエスト金額に対応した金額が送金された場合、端末２０のユーザ（Ｂ．Ｂ）に対して、第１ユーザ（Ａ．Ａ）に送金するように再度促す送金リマインド表示（限定ではなく、送金依頼に基づく、第１表示とは異なる第２表示の一例）は、ユーザ（Ｂ．Ｂ）の端末２０の表示部２４に表示されないことになる。

一方で、他のユーザ（Ａ．Ａ）の送金リクエスト金額に対応した金額が送金されなかった場合、限定ではなく例として、所定期間内に端末２０のユーザ（Ｂ．Ｂ）が前述した送金操作を行わなかった場合等には、そのユーザ（Ｂ．Ｂ）の端末２０の表示部２４に、送金リマインド表示を表示させることが可能となる。

図１－１１の例において、表示部２４には、端末２０により実行される支払いアプリケーションの機能に基づいて、端末２０のユーザ（支払いアプリケーションのユーザ）に対して、送金リマインドが行われたことを通知する送金リマインド表示ＭＳ３が表示されている。

限定ではなく例として、送金リマインド表示ＭＳ３は、その端末２０の機能（支払いアプリケーションの機能）に基づいて送金リマインドが行われたこと（つまり、端末リマインドが行われたこと）と、送金リマインドに関する第１ユーザのユーザ名とを通知するメッセージ（限定ではなく例として、「Ａ．Ａ」、「（端末リマインド）送金リクエストがあります。」）を含む点において、図１－９に示した送金リクエスト表示ＭＳ１とは異なる。

また、送金リマインド表示ＭＳ３の左側には、送金リマインドに関する詳細な情報を確認するためのボタンＢＴ３が表示されている。限定ではなく、送金リマインド表示ＭＳ３とボタンＢＴ３は、送金依頼に基づく、第１表示とは異なる第２表示の一例である。
ユーザが「開く」の文字が示されたボタンＢＴ３をタップすることで、支払いアプリケーションの機能に基づいて、送金リマインドの詳細が表示される。

図１－１２は、送金リマインドの対象となった端末２０のユーザがユーザＢ．Ｂである例を示している。すなわち、図１－１１において、ユーザＢ．Ｂが、ボタンＢＴ３をタップした結果、図１－１２に示す画面に移行する。

図１－１２に示す画面には、送金リマインドの詳細を示す送金リマインド表示ＭＳ４が表示されている。

限定ではなく例として、送金リマインド表示ＭＳ４は、送金リクエスト情報に対応した送金処理が未だ実行されていないことを通知するとともに、その通知が端末２０の機能（支払いアプリケーションの機能）に基づくことを示す「端末リマインド」という文字のアイコンを含む点と、第１ユーザから送金リクエストがあったことを示すメッセージの後に、送金リクエスト情報を端末２０が受信した日時が表示されている（本例では「Ａ．Ａさんから送金リクエストがあります。（２０２０．０４２０．２１：３０）」）点において、図１－１２に示した送金リクエスト表示ＭＳ２とは異なる。
すなわち、送金リマインド表示ＭＳ４において、送金リクエストに対する送金処理が未だ実行されていないことに対しての送金リマインドが行われたことが、メッセージの内容または表示態様によって通知されている。

さらに、送金リマインド表示ＭＳ４は、支払いアプリケーションの機能に基づいて、第１ユーザ（Ａ．Ａ）に対して送金処理を実行するための送金ボタンＢＴ４を含む。
限定ではなく、送金リマインド表示ＭＳ４は、送金依頼に基づく、第１表示とは異なる第２表示の一例である。

この画面で、端末２０のユーザ（Ｂ．Ｂ）が、送金ボタンＢＴ４をタップすると、送金リマインド表示ＭＳ４により指定された金額を送金するための送金画面（限定ではなく例として、図２－８の画面）に移行する。この送金画面において画面下部の送金領域ＲＭ２をタップすると、送金確認画面（限定ではなく例として、図２－９の画面）に移行する。
端末２０のユーザ（Ｂ．Ｂ）が、送金確認画面において確認ボタンＢＴ６をタップすることで、送金リマインド表示ＭＳ４により指定された金額が、端末２０のユーザ（Ｂ．Ｂ）の電子マネー口座から第１ユーザ（Ａ．Ａ）の電子マネー口座に送金される。

このように、限定ではなく例として、端末２０のユーザ（Ｂ．Ｂ）による、表示部２４に表示された第２表示（送金リマインド表示ＭＳ３およびボタンＢＴ３、送金ボタンＢＴ４が含まれる送金リマインド表示ＭＳ４）に対する入力に基づいて、送金リクエストに基づく、端末のユーザ（Ｂ．Ｂ）から第１ユーザ（Ａ．Ａ）への送金に関する送金処理が、端末２０の制御部２１によって実行されることになる。

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

以下説明する処理は、あくまでも本開示の手法を実現するための処理の一例に過ぎず、これらの処理に限定されるものではない。
また、以下説明する処理に、別のステップを追加してもよいし、一部のステップを省略（削除）してもよい。
これは、以下説明する各フローチャート（処理）について同様である。

この処理では、左側から順に、端末２０Ａの制御部２１が実行する処理、端末２０Ｂの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理をそれぞれ示す。
限定ではなく例として、端末２０ＡのユーザＡ．Ａを送金マスターユーザとし、端末２０ＢのユーザＢ．Ｂを送金リクエスト先ユーザとする場合を例示する。

この処理は、送金リクエスト先ユーザの端末２０（この例では端末２０Ｂ）が、自動で送金リマインド表示を表示部２４に表示させる処理の一例である。
また、送金リマインドは１回に限らず２回以上行うことも可能であるが、ここでは簡単のため、処理の終了判定を省略して、送金リマインドが１回だけ行われる場合の処理として図示・説明する。送金リマインドを２回以上行う場合も同様である。

まず、端末２０Ａの制御部２１は、限定ではなく例として、送金リクエストの実行を要求するための入力（以下、「送金リクエスト実行入力」と称する。）が入力部に対してなされたか否かに基づいて、送金リクエストの実行を要求するか否かを判定する（Ａ１１０）。
送金リクエスト実行入力は、限定ではなく例として、送金リクエストの実行を要求するための操作（以下、「送金リクエスト実行操作」と称する。）とすることができる。

要求すると判定したならば（Ａ１１０：ＹＥＳ）、端末２０Ａの制御部２１は、送金リクエスト先ユーザの端末２０（この例では端末２０Ｂ）に対して送金リクエスト情報を送信するように要求（依頼）するための情報（以下、「送金リクエスト送信要求情報」と称する。）を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１２０）。

送金リクエスト送信要求情報には、限定ではなく例として、少なくとも、自己の端末２０ＡのユーザＡ．Ａの識別情報（限定ではなく例として、アプリケーションＩＤ）と、送金リクエスト先ユーザであるユーザＢ．Ｂの識別情報（限定ではなく例として、アプリケーションＩＤ）と、送金リクエスト金額（送金を依頼する金額）とを含めることができる。

通信Ｉ／Ｆ１４によって端末２０Ａから送金リクエスト送信要求情報を受信すると、サーバ１０の制御部１１は、受信した送金リクエスト送信要求情報に基づき、送金リクエスト管理ＩＤを設定した送金リクエスト情報を生成し、第１送金リクエスト管理データ１５７Ａを更新する。そして、サーバ１０の制御部１１は、生成した送金リクエスト情報を、送金リクエスト先のユーザであるユーザＢ．Ｂの端末２０Ｂに、通信Ｉ／Ｆ１４によって送信する（Ｓ１１０）。

送金リクエスト情報には、限定ではなく例として、送金リクエスト管理ＩＤの他、送金リクエストであることをユーザが識別可能（認識可能）な情報（限定ではなく例として、送金リクエストであることを示すテキスト、画像等）や、送金リクエスト金額の情報、送金マスターユーザの情報（限定ではなく例として、送金マスターユーザのユーザ名）等を含めることができる。

なお、送金マスターユーザの情報として、そのユーザ名に限らず、そのアプリケーションＩＤや、送金マスターユーザの端末電話番号や端末メールアドレス等の情報を含めるようにしてもよいし、しなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から送金リクエスト情報を受信すると、端末２０Ｂの制御部２１は、受信した送金リクエスト情報に基づく送金リクエスト表示を表示部２４に表示させる（Ｂ１１０）。
送金リクエスト表示は、受信した送金リクエスト情報に含まれる一部または全部の情報の表示の他、受信した送金リクエスト情報に関連する情報の表示や、受信した送金リクエスト情報に基づき送金を実現するための情報（限定ではなく例として、送金ボタン、送金アイコン等の操作用画像）の表示を含むようにすることができる。

その後、端末２０Ｂの制御部２１は、その送金リクエストに基づく送金を実行するか否かを判定する（Ｂ１２０）。限定ではなく例として、入力部に対して、送金リクエスト管理ＩＤを指定した送金の実行入力がなされたか否かを判定する。
送金を実行すると判定したならば（Ｂ１２０：ＹＥＳ）、端末２０Ｂの制御部２１は、送金の決済を要求するための送金決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１３０）。

送金決済要求情報には、限定ではなく例として、送金リクエスト管理ＩＤと、送金予定金額とを含めることができる。
送金予定金額とは、送金する金額として入力された金額であって、未だ送金が行われていない状態の金額である。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂから送金決済要求情報を受信したか否かを判定し（Ｓ１２０）、受信したと判定したならば（Ｓ１２０：ＹＥＳ）、送金決済処理を実行する（Ｓ１３０）。
具体的には、限定ではなく例として、ユーザＢ．Ｂの電子マネー口座残高から送金予定金額分の金額を送金金額として減算して更新するとともに、ユーザＡ．Ａの電子マネー口座残高に送金金額を加算して更新する。
送金金額とは、送金リクエスト先ユーザから送金マスターユーザに対して送金された金額である。
また、第１送金リクエスト管理データ１５７Ａにおける、受信した送金リクエスト管理ＩＤに対応する送金済みフラグを「ＯＮ」に設定する。
送金済みフラグが「ＯＮ」となった送金リクエスト管理ＩＤについては、以降、送金を行わない。

また、送金決済処理において、電子マネー口座残高が不足している場合（送金予定金額が電子マネー口座残高を超えている場合）は、送金を行わない。
なお、この場合に、サーバ１０の制御部１１が、端末２０Ｂに対して、電子マネー口座残高にチャージするように促す情報を送信する。そして、チャージを要求する情報を端末２０Ｂから受信したことに基づいて、電子マネー口座残高にチャージした上で、送金を行うようにしてもよいし、しなくてもよい。

その後、サーバ１０の制御部１１は、送金に関する情報である送金情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１４０）。
送金情報には、限定ではなく例として、送金が完了したことを通知するための送金完了通知の情報等が含まれる。

また、サーバ１０の制御部１１は、受金に関する情報である受金情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５０）。
受金情報には、限定ではなく例として、受金が完了したことを通知するための受金完了通知の情報等が含まれる。

通信Ｉ／Ｆ２２によってサーバ１０から受金情報を受信すると（Ａ１４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した受金情報を表示部２４に表示させる（Ａ１５０）。

通信Ｉ／Ｆ２２によってサーバ１０から送金情報を受信すると、端末２０Ｂの制御部２１は、受信した送金情報を表示部２４に表示させる（Ｂ１４０）。

その後、端末２０Ｂの制御部２１は、上記の送金リクエストに対する送金リマインド（本実施例では端末リマインド）を行うか否かを判定する（Ｂ１４５）。具体的には、限定ではなく例として、送金リマインド（端末リマインド）を行う設定となっている場合に、送金リマインドを行うと判定する。

なお、基本的には、Ｂ１２０において送金リクエストに基づく送金が実行されなかった場合に、送金リマインドを行うようにすることができる。
ただし、これとは異なり、送金リクエストに基づく送金が実行されたか否かに関わらず、送金リマインドを行うようにすることもできる。

また、この場合、Ｓ１１０においてサーバ１０から送信された送金リクエスト情報を受信した後、またはＢ１１０において送金リクエスト表示を表示部２４に表示した後、すぐに送金リマインドを行うのではなく、限定ではなく例として、一定時間が経過したタイミングで、送金リマインドを行うようにすることができる。

送金リマインドを行うと判定した場合（Ｂ１４５：ＹＥＳ）、サーバ１０の制御部１１は、先に受信した送金リクエスト情報に基づいて送金リマインド情報を作成する。そして、端末２０Ｂの制御部２１は、作成した送金リマインド情報に基づく送金リマインド表示を表示部２４に表示させる（Ｂ１５０）。

送金リマインド表示の内容は、限定ではなく例として、送金リマインドであることをユーザが識別可能（認識可能）な情報（限定ではなく例として、送金リマインドであることを示すテキスト、画像等）の他は、送金リクエスト表示と同様とすることができる。

なお、送金リクエスト表示の内容と、送金リマインド表示の内容とを、全て同じ内容としてもよいし、しなくてもよい。

送金リマインド表示は、受信した送金リマインド情報に含まれる一部または全部の情報の表示の他、受信した送金リマインド情報に関連する情報の表示や、受信した送金リマインド情報に基づき送金を実現するための情報（限定ではなく例として、送金ボタン、送金アイコン等の操作用画像）の表示等を含む概念とすることができる。

次いで、端末２０Ｂの制御部２１は、表示部２４に表示された送金リマインド表示に対する入力がなされたか否かを判定する（Ｂ１６０）。
「入力」は、限定ではなく例として入力部（操作部）に対する操作、限定ではなく例として、タップ（タップ操作）とすることができる。
また、この入力には、前述した各種の送金リマインド表示ＭＳに対する入力を含めることができる。送金ボタンのタップに限らず、限定ではなく例として、前述した各種の送金リマインド表示ＭＳのうちのいずれかの送金リマインド表示ＭＳについて、その表示領域がタップされたことを入力として、送金を実現するようにすることもできる。

入力がなされたと判定したならば（Ｂ１６０：ＹＥＳ）、端末２０Ｂの制御部２１は、その送金リマインド情報に基づいて、送金決済要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１３０）。
この場合も、限定ではなく例として、先に受信した送金リクエスト情報の送金リクエスト管理ＩＤと、送金予定金額とを送金決済要求情報に含めることができる。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂから送金決済要求情報を受信したか否かを判定し（Ｓ１２０）、受信したと判定したならば（Ｓ１２０：ＹＥＳ）、送金決済処理を実行する（Ｓ１３０）。この送金決済処理は、前述した通りである。

その後、サーバ１０の制御部１１は、前述した送金情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１４０）。
また、サーバ１０の制御部１１は、前述した受金情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５０）。
そして、サーバ１０の制御部１１は、処理を終了する。

通信Ｉ／Ｆ２２によってサーバ１０から送金情報を受信すると、端末２０Ｂの制御部２１は、受信した送金情報を表示部２４に表示させる（Ｂ１４０）。そして、端末２０Ｂの制御部２１は、処理を終了する。
また、通信Ｉ／Ｆ２２によってサーバ１０から受金情報を受信すると（Ａ１４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した受金情報を表示部２４に表示させる（Ａ１５０）。そして、端末２０Ａの制御部２１は、処理を終了する。

＜端末が実行する送金処理（第１送金処理）＞
端末２０（限定ではなく例として、送金リクエスト先ユーザの端末２０）が制御部２１によって実行する処理には、送金処理（以下、この端末が実行する送金処理を「第１送金処理」と称する。）が含まれる。
第１送金処理は、端末２０が実行する処理であって、送金リクエスト（送金依頼）に基づく、送金リクエスト先ユーザ（端末のユーザ）から送金マスターユーザ（第１ユーザ）への送金に関する処理である。

この第１送金処理には、限定ではなく例として、端末のユーザから第１ユーザへの送金を実現するための処理や、端末のユーザから第１ユーザへの送金に何らかの形で関連する処理を含めることができる。送金に直接的に関連する処理のみならず、送金に間接的に関連する処理も、端末が実行する送金処理に含めることができる。

上記の処理例では、限定ではなく例として、以下の処理が第１送金処理に含まれる。
（１）送金決済要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する処理
（２）送金情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する処理
（３）受信した送金情報を表示部２４に表示する処理

＜端末に関する入力＞
上記の処理では、送金リクエスト実行入力や、送金リマインド表示に対する入力などの、端末に対する入力または端末のユーザによる入力を、入力部（操作部）に対する操作入力としたが、これに限定されない。

限定ではなく例として、入力部（操作部）に対する操作入力に代えて、またはこれに加えて、入力部（音入力部２５）に対する音（音声を含む。）入力を可能としてもよいし、しなくてもよい。
これは、端末に対する他の入力や端末のユーザによる他の入力についても同様である。

＜第１実施例の効果＞
本実施例は、端末２０が、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金リクエスト情報（限定ではなく、送金依頼に関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金リクエスト表示（限定ではなく、第１表示の一例）を表示部２４に表示する。
また、端末２０は、送金リクエストに基づく、送金リクエスト情報とは異なる送金リマインド表示（限定ではなく、第２表示の一例）を表示部２４に表示する。そして、端末２０は、表示部２４に表示された送金リマインド表示に対する入力（限定ではなく、第２表示に対する入力の一例）に基づいて、送金リクエストに基づく第１送金処理（限定ではなく、端末のユーザから第１ユーザへの送金に関する送金処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の表示部に表示された第２表示に対する入力に基づいて、送金処理を端末の制御部によって実行して、端末のユーザから第１ユーザへの送金を簡単に実現することができる。

また、本実施例は、送金リクエスト表示は、送金リクエストに基づく送金リクエスト金額の情報（限定ではなく、送金依頼に基づく金額の情報の一例）を含み、送金リマインド表示は、同様の金額の情報（限定ではなく、送金依頼に基づく金額の情報の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく金額を、第１表示と第２表示とによって端末のユーザに確実に知らせることができる。

また、本実施例は、送金リクエスト表示は、送金マスターユーザのユーザ名等の情報（限定ではなく、第１ユーザの情報の一例）を含み、送金リマインド表示は、同様のユーザ名等の情報（限定ではなく、第１ユーザの情報の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金の依頼元のユーザの情報を、第１表示と第２表示とによって端末のユーザに確実に知らせることができる。

また、本実施例は、送金リクエスト表示（限定ではなく、第１表示の一例）と送金リマインド表示（限定ではなく、第２表示の一例）とは、端末２０にインストールされた支払いアプリケーション（限定ではなく、端末にインストールされたアプリケーションの一例）によって、表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第１表示と第２表示とを端末のユーザに簡単に認識させることができる。

また、本実施例は、第１送金処理は、送金情報（限定ではなく、送金依頼に基づく送金の処理が実行されたことを示す情報）を通信Ｉ／Ｆ２２によって受信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく送金の処理が実行されたことを端末のユーザに知らせることができる。

また、本実施例は、第１送金処理は、送金決済要求情報（限定ではなく、送金依頼に基づく送金の処理の依頼に関する情報の一例）を通信Ｉ／Ｆ２２によって送信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザからの送金依頼に基づく送金の処理を外部に依頼することができる。

＜第１変形例（１）＞
送金リクエスト先ユーザの端末２０において、第１送金処理が実行されていない場合（未実行の場合）、送金マスターユーザからの送金リクエストに基づく送金が行われていないことに関する表示（限定ではなく、第４表示の一例）を表示部２４に表示する。一方、送金リクエスト先ユーザの端末２０において、第１送金処理が実行されている場合（実行済みである場合）、送金マスターユーザからの送金リクエストに基づく送金が行われていることに関する表示（限定ではなく、第５表示の一例）を表示部２４に表示するようにしてもよいし、しなくてもよい。

送金マスターユーザからの送金リクエストに基づく送金が行われていないことに関する表示には、限定ではなく例として、「まだ送金されていません」、「未送金です」といったテキストや、未送金の状態であることを示す画像（マークやアイコン等）を含めることができる。
同様に、送金マスターユーザからの送金リクエストに基づく送金が行われていることに関する表示には、限定ではなく例として、「既に送金されています」、「送金済みです」といったテキストや、送金済みの状態であることを示す画像（マークやアイコン等）を含めることができる。

本変形例は、送金リクエスト先ユーザの端末２０は、第１送金処理（限定ではなく、送金処理の一例）が実行されていない場合、送金マスターユーザからの送金リクエストに基づく送金が行われていないことに関する表示（限定ではなく、第４表示の一例）を表示部２４に表示する。一方、送金リクエスト先ユーザの端末２０は、第１送金処理が実行されている場合（実行済みである場合）、送金マスターユーザからの送金リクエストに基づく送金が行われていることに関する表示（限定ではなく、第５表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる変形例の効果の一例として、送金依頼に基づく送金の状況（行われている／行われてない）を、端末のユーザに適切に知らせることができる。

＜第１変形例（２）＞
第１実施例では、送金リクエスト先ユーザの端末２０において、リマインド表示の１つとして、プッシュ通知を行うことができることとした。このプッシュ通知は、リマインド表示の一種とも言えるし、リマインド通知の一種とも言える。

このプッシュ通知の他にも、限定ではなく例として、以下のような制御に基づくリマインド通知処理を行うようにすることもできる。
・制御部２１が、音出力部２６に所定の音を出力させるように制御する。
・制御部２１が、不図示の振動部を制御して端末２０の筐体を振動させる。
・制御部２１が、不図示の発光部に所定の発光を行わせるように制御する。

なお、端末リマインドの実行タイミングとなったことの他に、リマインド通知を行うための条件（以下、「リマインド通知条件」と称する。）を設定しておき、リマインド通知条件が成立したことに基づいて、リマインド通知処理を実行するようにすることもできる。

リマインド通知条件には、限定ではなく例として、「現在の時刻が、ユーザが就寝している可能性の高い時間帯（夜遅く（翌日０時まで）の時間帯、未明（翌日３時まで）の時間帯、明け方（翌日３時から）の時間帯に含まれないこと）等の条件を設定しておくことができる。
このようにすることで、これらの設定時間帯では、リマインド通知条件が成立せず、リマインド通知処理が実行されないため、ユーザが就寝している可能性の高い時間帯にリマインド通知が行われないようにすることができる。

本変形例は、送金リクエスト先ユーザの端末２０は、設定されたリマインド通知条件（限定ではなく、第２条件の一例）に基づいて、制御部２１によってリマインド通知処理を実行する構成を示している。
このような構成により得られる変形例の効果の一例として、設定された条件に基づいて、端末リマインドの実行を、端末のユーザに適切なタイミングで通知することができる。

＜第１変形例（３）＞
第１実施例において、送金リクエスト先ユーザの端末２０で送金リクエストに基づく送金を実行する際に、限定ではなく例として、送金リマインドに基づく送金を実行する場合と同様に、表示部２４に表示された送金リクエスト表示に対する入力に基づいて、送金を実行するようにすることができる。

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

Ｂ１１０の後、端末２０Ｂの制御部２１は、表示部２４に表示された送金リクエスト表示に対する入力がなされたか否かを判定する（Ｂ１２５）。
この場合における入力は、前述した送金リマインド表示に対する入力と同様に、タップ（タップ操作）等の操作入力や、音入力等とすることができる。
入力がなされたと判定したならば（Ｂ１２５：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ１３０に処理を移す。

本変形例は、送金リクエスト先ユーザの端末２０が、送金リクエスト先ユーザによる送金リクエスト表示（限定ではなく、第１表示の一例）に対する入力に基づいて、送金リクエストに基づく、送金リクエスト先ユーザから送金マスターユーザへの送金を実現するための処理（限定ではなく、端末のユーザから第１ユーザへの送金に関する送金処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる第１表示に対する入力に基づいて、送金依頼に基づく送金を簡単に実現することができる。

＜第１変形例（４）＞
第１実施例では、第１ユーザを、一般ユーザである端末２０のユーザ（上記の例ではユーザＡ．Ａ）として説明したが、これに限定されない。
第１ユーザを、一般ユーザではなく、店舗等の事業者のユーザとしてもよいし、しなくてもよい。この場合における事業者には、限定ではなく例として、商品の販売（サービスの提供を含む。）を行う事業者や貸金業を営む事業者など、送金依頼によって端末２０のユーザに対して金銭の請求を行うことが想定される事業者（店舗）が含まれる。

この場合、上記の実施例において、これらの事業者が、支払いサービス（支払いアプリケーション）のアカウントを取得する。そして、このアカウントを用いて、サーバ１０を介して、金銭の請求先のユーザ（送金リクエスト先ユーザ）の端末２０に対して、送金リクエスト情報や送金リマインド情報を送信するようにすることができる。

なお、上記の事業者（店舗）が取得するアカウントは、端末２０のユーザ用のアカウントである一般アカウントとしてもよいし、事業者用のアカウントとしてもよい。

本変形例は、送金マスターユーザ（限定ではなく、第１ユーザの一例）は、送金リクエストに関する商品の販売を行う店舗である構成を示している。
このような構成により得られる変形例の効果の一例として、一般のユーザばかりでなく、店舗のユーザも、端末のユーザに対して送金依頼を行うことのできるユーザ（第１ユーザ）とすることができる。

＜第１変形例（５）＞
端末２０のユーザによっては、送金リクエスト先ユーザに対して送金リクエストや送金リマインドを行うことに気まずさを感じ、躊躇してしまう場合が想定される。限定ではなく例として、送金リクエスト先ユーザが自分よりも目上の人であったり、送金リクエスト先ユーザが親友である場合等である。

そこで、送金リクエストや送金リマインドの依頼元のユーザを、端末２０のユーザとするのではなく、業務用アカウントを利用するユーザとすることも可能である。
業務用アカウントは、限定ではなく例として、そのサービス（上記の例では支払いサービス）において公式のアカウント（以下、「公式アカウント」と称し、適宜「ＯＡ：Official Account」と表現する。）を有するユーザである。

一例として、公式アカウントを有するユーザは、限定ではなく例として、支払いサービス事業者とすることができる。この場合、サーバ１０が、送金リクエストや送金リマインドの依頼元のユーザを、端末２０のユーザではなく、支払いサービス事業者として、送金リクエスト情報や送金リマインド情報を、送金リクエスト先ユーザの端末２０に送信するようにすることができる。

本変形例は、送金依頼主のユーザ（限定ではなく、第１ユーザの一例）は、公式アカウント（限定ではなく、業務用アカウントの一例）を利用するユーザである構成を示している。
このような構成により得られる変形例の効果の一例として、送金依頼を行うことを希望するユーザに代わって、業務用アカウントを利用するユーザに送金依頼を行わせることが可能となり、ユーザの利便性を向上させることができる。

＜第２実施例＞
第２実施例は、送金リクエスト先ユーザの端末２０が、サーバ１０から送金リマインド情報を受信したことに基づいて、送金リマインド表示を行う実施例である。以下、この手法を「サーバリマインド」と称する。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜データ構成＞
図２－１は、サーバ１０の記憶部１５に記憶される、前述した送金リクエスト管理データ１５７の別例である第２送金リクエスト管理データ１５７Ｂの構成例を示す図である。
第２送金リクエスト管理データ１５７Ｂには、第１送金リクエスト管理データ１５７Ａにおける、日時と、送金リクエスト管理ＩＤと、送金マスターＩＤと、送金リクエスト先ＩＤと、送金リクエスト金額と、送金済みフラグとに加えて、限定ではなく例として、情報種別が関連付けて記憶される。

情報種別は、その送金リクエスト管理ＩＤに対応する情報の種別が、送金リクエストと送金リマインドとのいずれであるかを識別するための情報であり、限定ではなく例として、送金リクエストには「リクエスト」が、送金リマインドには「リマインド」がそれぞれ記憶される。

日時には、限定ではなく例として、対応する送金リクエストの情報種別が「リクエスト」であれば、その送金リクエスト情報がサーバ１０から送金リクエスト先ユーザの端末２０に送信された日時が記憶され、対応する送金リクエストの情報種別が「リマインド」であれば、その送金リマインド情報がサーバ１０から送金リクエスト先ユーザの端末２０に送信された日時が記憶される。

また、各々の送金リクエスト管理ＩＤについて、その送金リクエスト管理ＩＤによって識別される送金リクエスト情報に対応する送金リマインド情報には、送金リマインドが行われた回数に関係なく、送金リクエスト管理ＩＤと、送金リクエスト金額と、送金済みフラグとして、同じＩＤ、同じ金額、同じフラグがそれぞれ記憶される。
限定ではなく例として、図中黒枠で囲ったレコードのデータが、対応関係にある送金リクエストおよび送金リマインドのデータである。

＜表示画面＞
図２－２は、第１ユーザ（Ａ．Ａ）の端末２０で支払いアプリケーションが実行されている場合の、表示部２４に表示される情報の一例を示している。
表示部２４には、第１ユーザ（Ａ．Ａ）の電子マネー口座残高（本例では「２５，０００円」）が表示されるとともに、支払いアプリケーションにおいて実行可能な各機能のそれぞれに対応したアイコンが表示されている。
第１ユーザ（Ａ．Ａ）は、自分の口座に関する入金履歴を表示部２４に表示させることにより、送金が行われたか否か、並びに、送金が行われた場合における送金を行ったユーザおよび送金額を確認することができる。すなわち、送金依頼に応じて送金が行われたか否かを確認することが可能である。

支払いアプリケーションにより実行可能な機能として、指定したユーザに対して支払いを依頼する送金依頼機能があり、送金依頼機能に対応した「￥マーク」を含むアイコンＩＣ１とともに「送金リクエスト」の文字が表示されている。
第１ユーザ（Ａ．Ａ）が、このアイコンを選択して、送金依頼対象のユーザ（本例ではＢ．Ｂ）を指定し、送金依頼金額（送金リクエスト金額）（本例では「３，０００円」）を入力することで、指定されたユーザ（Ｂ．Ｂ）の端末２０に対して送金リクエスト情報が送信され、指定されたユーザの端末２０の表示部２４には、送金リクエスト表示ＭＳ１、ＭＳ２が表示される。

そして、第１ユーザ（Ａ．Ａ）の端末２０では、支払いアプリケーションにおいて、送金依頼の対象となったユーザに関する情報と、送金依頼金額とが、送金依頼履歴として管理される。
図２－２の例では、送金依頼履歴の閲覧機能に対応したアイコンＩＣ２とともに「送信リクエスト一覧」の文字が表示されている。
第１ユーザ（Ａ．Ａ）が、このアイコンを選択することで、過去に送金依頼の対象となったユーザと、そのユーザに対する送金依頼金額とを、個別に確認することができる。

本例では、図２－３に示すように、「送金リクエスト一覧」のタイトルの下方に、第１ユーザ（Ａ．Ａ）が過去に行った送金依頼のうち送金処理が未完了であるもの、すなわち、送金リマインドの対象とすることが可能であるものに関する情報が、個別に表示される。
本例では、送金依頼の対象となったユーザのアイコン画像およびユーザ名（本例では、Ｂ．Ｂ）と、そのユーザの端末２０が送金リクエスト情報を受信した日時（本例では、２０２０．０４．２０２１：３０）と、そのユーザに対する送金依頼金額（本例では、「３，０００円」）と、第１ユーザ（Ａ．Ａ）が、その送金依頼金額を受け取る立場であることを示すアイコン（本例では「受取」の文字のアイコン）と、が矩形状の領域Ｒ１内に関連付けて表示されている。

また、領域Ｒ１には、チェックボックスが設けられており、ユーザがチェックボックスをチェックした状態とすることで、領域Ｒ１内に表示されている各情報が選択された状態となる。

図２－３の例では、画面下部に「リマインドする」と表示された領域ＲＲが設けられている。第１ユーザ（Ａ．Ａ）が、チェックボックスがチェックされた状態で領域ＲＲをタップすることで、領域Ｒ１内に表示されていた情報に基づく送金リマインド情報が、送金リクエスト情報の送信対象となっていたユーザ（Ｂ．Ｂ）の端末２０に送信される。
そして、送金リマインド情報を受信した端末２０の表示部２４には、送金リマインド表示が表示される。

ユーザ（Ｂ．Ｂ）の端末２０が送金リマインド情報を受信するか、または、ユーザ（Ｂ．Ｂ）の端末２０で送金リマインド情報を受信したことに基づく送金リマインド表示が表示されると、図２－４に示すように、第１ユーザ（Ａ．Ａ）の端末２０には、送金リマインドが完了したことを通知する送金リマインド完了表示ＭＳ５が表示される。
送金リマインド完了表示ＭＳ５には、送金依頼の対象であったユーザのユーザ名（本例ではＢ．Ｂ）が含まれる。

送金リマインド情報を受信したユーザ（Ｂ．Ｂ）の端末２０には、図２－５に示すように、送金リマインド情報を受信したことに基づく送金リマインド表示ＭＳ３Ａが表示される。

限定ではなく例として、送金リマインド表示ＭＳ３Ａは、送金リマインド情報を受信したことに基づく、送金リマインドに関する第１ユーザのユーザ名を通知するメッセージ（限定ではなく例として、「Ａ．Ａ」、「［リマインド受信］送金リクエストがあります。」）を含む。
図１－１１に示した送金リマインド表示ＭＳ３では、自端末の機能に基づく送金リマインド表示であることに応じて「端末リマインド」と表示されているのに対して、送金リマインド表示ＭＳ３Ａでは、受信した送金リマインド情報に基づく送金リマインド表示であることに応じて「リマインド受信」と表示される点が異なる。

また、送金リマインド表示ＭＳ３Ａの左側には、送金リマインドに関する詳細な情報を確認するためのボタンＢＴ３Ａが表示されている。
限定ではなく、送金リマインド表示ＭＳ３ＡとボタンＢＴ３Ａは、送金依頼に基づく、第１表示とは異なる第２表示の一例である。
限定ではなく、送金リマインド表示ＭＳ３ＡとボタンＢＴ３Ａは、送金依頼に基づく第２情報を端末２０が受信したことに基づいて表示部２４に表示される第２表示の一例である。

ユーザが「開く」の文字が示されたボタンＢＴ３Ａをタップすることで、支払いアプリケーションの機能に基づいて、送金リマインドの詳細が表示される。
図２－５において、ユーザ（Ｂ．Ｂ）が、ボタンＢＴ３Ａをタップした結果、図２－６に示す画面に移行し、送金リマインドの詳細を示す送金リマインド表示ＭＳ４Ａが表示される。

限定ではなく例として、送金リマインド表示ＭＳ４Ａは、送金リマインド情報を受信したことに基づく「リマインド受信」という文字のアイコンと、送金リマインド情報を受信したことに基づく、第１ユーザのユーザ名を通知するメッセージ（限定ではなく例として、「［リマインド受信］Ａ．Ａさんから送金リクエストがあります。」）を含む。

図１－１２に示した送金リマインド表示ＭＳ４では、自端末の機能に基づく送金リマインド表示であることに応じて「端末リマインド」という文字のアイコンが表示されているのに対して、送金リマインド表示ＭＳ４Ａでは、送金リマインド情報を受信したことに基づく「リマインド受信」という文字のアイコンが表示されている点が異なる。
また、図２－６の送金リマインド表示ＭＳ４Ａでは、第１ユーザのユーザ名（Ａ．Ａ）の前に、送金リマインド情報に基づく送金リマインド表示であることに対応して［リマインド受信］という表示があるのに対して、図１－１２に示した送金リマインド表示ＭＳ４では、このような表示が無い点も異なる。

端末２０のユーザ（Ｂ．Ｂ）が、送金リマインド表示ＭＳ４Ａの「＞詳細を確認」と表示されたリンク情報をタップすると、図２－７の画面に移行する。
図２－７の画面では、送金リマインド表示ＭＳ４Ａによりリマインドされた送金依頼が、どのようなイベントにより生じたものであるか（本例では、４／２０に行われたイベントの会費であること）が通知される。また、端末２０のユーザ（Ｂ．Ｂ）が、支払いを行う立場であること（本例では、「支払い」の文字のアイコン）と、支払うべき金額（本例では、「３，０００円」）とが通知される。

図２－７の画面において、送金リマインドに関する情報は、前述した送金リマインド表示ＭＳ４Ａよりも大きな領域に動物のキャラクタとともに表示されている。その下方には、領域ＲＭ１が設けられている。

領域ＲＭ１には、第１ユーザのユーザ名（Ａ．Ａ）と、その第１ユーザによる送金依頼および送金リマインドが行われたことを通知する情報（本例では、「リマインド受信」、「Ａ．Ａさんから送金リクエストがあります。」というメッセージ）と、その第１ユーザに、送金依頼および送金リマインドに対応した金額を送金するためのリンク情報（本例では「＞送金する」という文字が表示された部分）が表示されている。

端末２０のユーザ（Ｂ．Ｂ）が、送金用のリンク情報をタップすると、図２－８に示す送金画面に移行する。
送金画面には、送金相手となる第１ユーザのアイコン画像およびユーザ名（Ａ．Ａ）と、第１ユーザに送金すべき送金額（本例では「３，０００円」）と、端末２０のユーザ（Ｂ．Ｂ）が支払いを行う立場であることを通知するアイコン（本例では「支払い」の文字のアイコン）と、現在の端末２０のユーザ（Ｂ．Ｂ）の送金可能額（本例では「５，０００円」）が表示されている。

第１ユーザに送金すべき送金額よりも、現在の端末２０のユーザ（Ｂ．Ｂ）の送金可能額が大きいことに基づいて、端末２０のユーザ（Ｂ．Ｂ）は第１ユーザ（Ａ．Ａ）に対して、送金リクエスト情報および送金リマインド情報に対応した金額を送金することが可能な状態となっている。

この送金画面において画面下部の送金領域ＲＭ２をタップすると、図２－９に示す送金確認画面に移行する。
限定ではなく例として、送金確認画面は、送金画面上に重畳表示される画面であり、送金相手となる第１ユーザのアイコン画像およびユーザ名（Ａ．Ａ）と、支払いアプリケーションを使用して第１ユーザに送金する予定の送金額（本例では３，０００円）と、「確認」という文字が表示された確認ボタンＢＴ６を含む。

端末２０のユーザ（Ｂ．Ｂ）が、確認ボタンＢＴ６をタップすることで、送金確認画面に表示されている金額（本例では「３，０００円」）が、端末２０のユーザ（Ｂ．Ｂ）の口座から第１ユーザ（Ａ．Ａ）の口座に送金される。
送金が完了すると、ユーザ（Ｂ．Ｂ）の端末２０には、図２－１０に示す送金完了画面が表示される。
限定ではなく例として、送金完了画面は、送金画面上に重畳表示される画面であり、送金相手となる第１ユーザのユーザ名（Ａ．Ａ）と、送金処理が完了したことを通知するメッセージが表示される。

＜処理＞
（１）処理の一例
図２－１１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図１－１３～図１－１４のフローチャートにおける図１－１４の処理部分に対応するフローチャートであり、サーバ１０が、送金リクエスト先ユーザの端末２０（この例では端末２０Ｂ）に対して、自動で送金リマインド情報を送信する処理を示すフローチャートである。

サーバ１０の制御部１１は、先の送金リクエストに対する送金リマインド（本実施例では、サーバリマインド）を行うか否かを判定する（Ｓ２６０）。具体的には、限定ではなく例として、Ｓ１２０において端末２０Ａから送金決済要求情報を受信しなかった場合に、送金リマインドを行うと判定する。

なお、この場合、Ｓ１１０において送金リクエスト情報を端末２０に送信した後、すぐに送金リマインドを行うのではなく、限定ではなく例として、一定時間が経過したタイミングで、送金リマインドを行うようにすることができる。

送金リマインドを行うと判定した場合（Ｓ２６０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１１０で設定した送金リクエスト管理ＩＤと同じＩＤを設定した送金リマインド情報を作成して、第２送金リクエスト管理データ１５７Ｂを更新する。そして、サーバ１０の制御部１１は、生成した送金リマインド情報を、送金リクエスト管理ＩＤとともに、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ２７０）。そして、サーバ１０の制御部１１は、Ｓ１２０に処理を移す。

通信Ｉ／Ｆ２２によってサーバ１０から送金リマインド情報を受信すると（Ｂ２４０：ＹＥＳ）、端末２０Ｂの制御部２１は、送金リマインド表示を表示部２４に表示させる（Ｂ２５０）。そして、端末２０Ｂの制御部２１は、Ｂ１６０に処理を移す。

（２）処理の別例
図２－１２は、本実施例において各装置が実行する処理の流れの別例を示すフローチャートである。
このフローチャートは、図１－１３～図１－１４のフローチャートにおける図１－１４の処理部分に対応するフローチャートであり、サーバ１０が、送金マスターユーザの端末２０（この例では端末２０Ａ）から送信される送金リマインド送信要求情報を受信したことに基づいて、送金リクエスト先ユーザの端末２０（この例では端末２０Ｂ）に対して送金リマインド情報を送信する処理を示すフローチャートである。

図１－１３のＡ１５０の後、端末２０Ａの制御部２１は、限定ではなく例として、送金リマインドの実行を要求するための入力（以下、「送金リマインド実行入力」と称する。）が入力部に対してなされたか否かに基づいて、送金リマインドの実行を要求するか否かを判定する（Ａ２６０）。
送金リマインド実行入力は、前述した送金リクエスト実行入力と同様に、限定ではなく例として、操作入力や音入力によって実現することができる。

要求すると判定したならば（Ａ２６０：ＹＥＳ）、端末２０Ａの制御部２１は、送金リマインド送信要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２７０）。そして、端末２０Ａの制御部２１は、Ａ１５０に処理を移す。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから送金リマインド送信要求情報を受信したか否かを判定し（Ｓ２６５）、受信したと判定したならば（Ｓ２６５：ＹＥＳ）、Ｓ２７０に処理を移す。

＜サーバが実行する送金処理（第２送金処理）＞
サーバ１０が制御部１１によって実行する処理には、送金処理（以下、このサーバが実行する送金処理を「第２送金処理」と称する。）が含まれる。
第２送金処理は、サーバ１０が実行する処理であって、送金リクエスト（送金依頼）に基づく、送金リクエスト先ユーザ（端末のユーザ）から送金マスターユーザ（第１ユーザ）への送金に関する処理である。

この第２送金処理には、限定ではなく例として、端末のユーザから第１ユーザへの送金を実現するための処理や、端末のユーザから第１ユーザへの送金に何らかの形で関連する処理を含めることができる。送金に直接的に関連する処理のみならず、送金に間接的に関連する処理も、端末が実行する送金処理に含めることができる。

上記の処理例では、限定ではなく例として、以下の処理が第２送金処理に含まれる。
（１）送金決済要求情報を通信Ｉ／Ｆ１４によって端末２０から受信する処理
（２）送金決済処理（電子マネー口座残高のバランス調整の処理等を含む。）
（３）送金情報／受金情報を通信Ｉ／Ｆ１４によって端末２０に送信する処理

＜第２実施例の効果＞
本実施例は、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金リクエストに関する送金リクエスト情報（限定ではなく、第１情報の一例）は、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金マスターユーザの端末２０への入力に基づいて、サーバ１０を介して送金リクエスト先ユーザの端末２０に送信される。
一方、送金リマインド情報（限定ではなく、第２情報の一例）は、サーバ１０によって、送金リクエスト先ユーザの端末２０に送信され、送金リマインド表示（限定ではなく、第２表示の一例）は、送金リマインド情報に基づいて、送金リクエスト先ユーザの端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第１ユーザの意向に応じて、第１情報がサーバを介して端末に送信されるようにすることができる。また、第２情報がサーバから端末に送信された上で、その第２情報に基づいて、第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、サーバ１０が、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金リクエストに関する送金リクエスト情報（限定ではなく、送金依頼に関する第１情報の一例）を送金リクエスト先ユーザの端末２０（限定ではなく、端末の一例）に通信Ｉ／Ｆ１４によって送信する。また、サーバ１０は、送金リクエストに基づく送金リマインド情報（限定ではなく、送金依頼に基づく第２情報の一例）を送金リクエスト先ユーザの端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、送金リクエスト先ユーザの端末２０の表示部２４に表示された、送金リマインド表示（限定ではなく、第２情報に基づく第２表示の一例）に対する入力に基づいて、第２送金処理（限定ではなく、送金依頼に基づく、端末のユーザから第１ユーザへの送金に関する送金処理の一例）を制御部１１によって実行する構成を示している。
このような構成により得られる変形例の効果の一例として、端末の表示部に表示された第２表示に対する入力に基づいて、送金処理をサーバの制御部によって実行して、端末のユーザから第１ユーザへの送金を簡単に実現することができる。

＜第２変形例（１）＞
第２実施例で説明した支払いアプリケーションにおける表示画面のユーザインターフェイスや、支払いアプリケーションの機能等については、適宜設計変更可能である。

限定ではなく例として、図２－１３には、ユーザ（Ｂ．Ｂ）の端末２０に表示される送金リクエスト一覧画面を示している。
この送金リクエスト一覧画面には、限定ではなく例として、「送金リクエスト一覧」のタイトルの下方に、端末のユーザ（Ｂ．Ｂ）に対する過去の送金依頼のうち送金処理が未完了であるものについての送金依頼履歴が表示されている。

この例では、端末２０のユーザ（Ｂ．Ｂ）が、第１ユーザであるＡ．Ａから、送金リクエスト情報を受信していることに基づいて、領域Ｒ２１に、Ａ．Ａのアイコン画像およびユーザ名と、「リクエスト受信」の文字のアイコンと、送金リクエスト情報の受信日時（２０２０．０４．２０２１：３０）と、Ａ．Ａに対して支払いを行う立場であることを示す「支払い」の文字のアイコンと、Ａ．Ａに対して支払うべき金額（３，０００円）と、が表示されている。

また、端末２０のユーザ（Ｂ．Ｂ）が、第１ユーザであるＤ．Ｄからも、送金リクエスト情報を受信していることに基づいて、領域Ｒ２３に、Ｄ．Ｄからの送金依頼に関する情報が表示されている。この例では、Ｄ．Ｄからの送金リクエスト情報の受信日時は２０２０．０４．２１０８：４２となっており、Ｄ．Ｄに対して支払うべき金額は「５００円」となっている。

複数（Ａ．Ａ，Ｂ．Ｂ）の第１ユーザのうち、Ａ．Ａからの送金依頼に関しては、端末２０が送金リクエスト情報を受信した後に、送金リマインド情報も受信していることに基づいて、領域Ｒ２１の下方の領域Ｒ２２（限定ではなく、送金リクエスト情報に関する表示領域に対応した送金リマインド情報に関する表示領域の一例）に、Ａ．Ａのアイコン画像およびユーザ名と、「リマインド受信」の文字のアイコンと、送金リマインド情報の受信日時（２０２０．０４．２３１７：００）と、Ａ．Ａに対して支払いを行う立場であることを示す「支払い」の文字のアイコンと、Ａ．Ａに対して支払うべき金額（３，０００円）と、が表示されている。

領域Ｒ２１に表示されている情報と、領域Ｒ２２に表示されている情報は、共通の送金リクエスト情報に基づく情報であるため、Ａ．Ａに対して支払いを行う立場であることを示す「支払い」の文字のアイコンと、Ａ．Ａに対して支払うべき金額（３，０００円）は同じである。

一方で、領域Ｒ２１と異なり、領域Ｒ２２には、領域Ｒ２１に表示されている情報に関連した情報であることを示す矢印が表示されている。また、Ｒ２２におけるＡ．Ａのアイコン画像およびユーザ名、「リマインド受信」の文字のアイコンは、それぞれ、領域Ｒ２１におけるＡ．Ａのアイコン画像およびユーザ名、「リクエスト受信」の文字のアイコンよりも右側に表示されている。

限定ではなく例として、端末２０が受信した送金リクエスト情報に基づいて表示される領域２１に表示された情報と、その送金リクエスト情報に基づく送金リマインド情報に基づいて表示される領域２２に表示された情報とで、少なくとも一部の情報（限定ではなく例として、第１ユーザの画像アイコンおよびユーザ名と、その上方に表示されるアイコン）の表示位置が異なることにより、ユーザは、送金依頼と送金リマインドとの対応関係を理解し易い。

限定ではなく例として、送金依頼履歴として表示されている情報は、端末２０のユーザの操作によってソートすることができる。
図２－１３で示した送金依頼履歴が表示されている画面において、ユーザによって空白領域がタップされたことに伴い、図２－１４に示すように、ソート項目選択領域ＳＲが表示される。

ソート項目選択領域ＳＲの上部には、下方に示された項目に基づいてソートを実行することを通知する情報（限定ではなく例として、「リクエストを並べ替える」という文字）が表示されている。
その下方には、送金リクエスト情報または送金リマインド情報の受信日時に基づくソートを実行するためのボタンＢＴＳ１と、送金額（限定ではなく例として、送金リクエスト情報または送金リマインド情報により送金を要求されている金額）に基づくソートを実行するためのボタンＢＴＳ２と、支払いアプリケーションまたは支払いアプリケーションと連携しているメッセージングアプリケーションにおいて友だち登録されているユーザ名に基づくソートを実行するためのボタンＢＴＳ３が表示されている。

限定ではなく例として、一の端末２０のユーザ（一のアカウント）が、自己の端末２０から、他の端末２０のユーザ（他のアカウント）を友だちとして追加するための処理を行い、サーバ１０によって友だちを追加・登録する処理（友だち追加処理、友だち登録処理）が実行されることで、サーバ１０を介して、友だち登録された端末２０間でメッセージの送受信等を行うことが可能となる。個人のユーザが所有するメッセージングアプリケーションのアカウントのことを「一般アカウント」と称する。一般アカウントを所有するユーザの端末２０間で送受信されたメッセージの履歴は、端末２０の表示部２４にトークルーム等として表示される。

限定ではなく例として、端末２０のユーザ（Ｂ．Ｂ）が、ボタンＢＴＳ３をタップすると、図２－１５に示すように、送金依頼履歴として表示されている情報がソートされて、送金依頼を行った第１ユーザ（限定ではなく例として、Ａ．ＡとＤ．Ｄ）のうち、友だち登録されているユーザ（限定ではなく例として、Ａ．ＡとＤ．Ｄ）のユーザ名が、アルファベット順に基づいて表示される。
本例では、領域Ｒ２１に、第１ユーザであるＡ．Ａのアイコン画像およびユーザ名が表示され、領域Ｒ２２に、第１ユーザであるＢ．Ｂのアイコン画像およびユーザ名が表示されている。

図２－１５に示す例は、図２－１４に示した例とは異なり、ソート後に、第１ユーザに関する情報として、「リクエスト受信」のアイコンおよび「リマインド受信」のアイコンは何れも表示されておらず、送金リクエスト情報の受信日時および送金リマインド情報の受信日時は何れも表示されておらず、送金額に関する情報も表示されていない。
図２－１５に示す画面では、少なくとも送金依頼を行った第１ユーザを把握することが可能な態様となっている。

図２－１５に示す画面で、端末２０のユーザ（Ｂ．Ｂ）が、友だち登録されている第１ユーザ（限定ではなく例としてＡ．Ａ）に対応した領域Ｒ２１をタップすると、図２－１６に示すように、選択された第１ユーザ（Ａ．Ａ）の送金依頼に関する詳細な情報が表示される。
画面上部の領域Ｒ２０には、選択された第１ユーザ（Ａ．Ａ）の送金依頼に関する履歴であることを通知する情報（限定ではなく例として、「Ａ．Ａの送金リクエスト一覧」という文字）が表示され、その下方には、選択された第１ユーザ（Ａ．Ａ）の送金依頼に関する詳細な履歴が、図２－１３に示された態様で表示される。

限定ではなく例として、図２－１３の領域Ｒ２１、Ｒ２２に表示された各情報（限定ではなく、送金リクエスト情報に基づく表示の一例、送金リマインド情報に基づく表示の一例）が、図２－１６の領域Ｒ２１、Ｒ２２に表示されている。
なお、選択されていない他の第１ユーザ（Ｄ．Ｄ）の送金依頼に関する履歴は表示されていない。

限定ではなく例として、図２－１４の画面で、端末２０のユーザ（Ｂ．Ｂ）が、ボタンＢＴＳ１をタップすると、図２－１７に示すように、送金依頼履歴として表示されている情報がソートされて、送金依頼を行った第１ユーザ（限定ではなく例として、Ａ．ＡとＤ．Ｄ）の履歴（限定ではなく、送金リクエスト情報に基づく表示の一例、送金リマインド情報に基づく表示の一例）が、受信日時に基づいて表示される。

この例では、最も新しい履歴が、第１ユーザであるＡ．Ａによる３，０００円の送金依頼に対応した送金リマインド情報（受信日時２０２０．０４．２３１７：００）に基づく履歴であるため、最上部の領域Ｒ２１には、Ａ．Ａのアイコン画像およびユーザ名とともに、「リマインド受信」のアイコンが表示される。
次に新しい履歴が、他の第１ユーザであるＢ．Ｂによる５００円の送金依頼に対応した送金リクエスト情報（受信日時２０２０．０４．２１０８：４２）に基づく履歴であるため、上から２番目の領域Ｒ２２には、Ｂ．Ｂのアイコン画像およびユーザ名とともに、「リクエスト受信」のアイコンが表示される。
次に新しい履歴が、第１ユーザであるＡ．Ａによる３，０００円の送金依頼に対応した送金リクエスト情報（受信日時２０２０．０４．２０２１：３０）に基づく履歴であるため、上から３番目の領域Ｒ２３には、Ａ．Ａのアイコン画像およびユーザ名とともに、「リクエスト受信」のアイコンが表示される。

領域Ｒ２１に表示されている情報と、領域Ｒ２３に表示されている情報は、何れも一方の第１ユーザ（Ａ．Ａ）からの共通の送金依頼に関する情報である。
しかしながら、一方の第１ユーザ（Ａ．Ａ）の第１送金依頼に基づく送金リクエスト情報の受信後に、他方の第１ユーザ（Ｄ．Ｄ）の第２送金依頼に基づく送金リクエスト情報を受信し、その後に、一方の第１ユーザ（Ａ．Ａ）の第１送金依頼に基づく送金リマインド情報を受信しているため、第１送金依頼に対応した情報が表示される領域Ｒ２１と、第１送金依頼に対応した情報が表示される領域Ｒ２３との間の領域である領域Ｒ２２に、第２送金依頼に対応した情報が表示されている。

限定ではなく例として、図２－１８に示すように、送金依頼または送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０には、その送金依頼または送金リマインドを行った第１ユーザが、支払いアプリケーションまたは支払いアプリケーションと連携しているメッセージングアプリケーションにおいて友だち登録されているユーザであるか否かを確認するための友だち登録確認画面が表示される。

限定ではなく例として、図２－７に示した画面において、端末２０のユーザ（Ｂ．Ｂ）が、領域ＲＭ１に表示されている送金用のリンク情報をタップすると、図２－８の送金画面に移行する前に、図２－１８の友だち登録確認画面が表示される。
限定ではなく例として、友だち登録確認画面は、図２－７の画面上に重畳表示される画面であり、送金しようとしている相手（限定ではなく例として、ＲＭ１に表示されているユーザ名（Ａ．Ａ）の第１ユーザ）が、友だち登録されている相手かどうかを端末２０のユーザ（Ｂ．Ｂ）に確認させるためのメッセージ（限定ではなく例として、「送金をリクエストした人が友だちかどうか再度ご確認ください。送金を行いますか？」）が表示される。

端末２０のユーザ（Ｂ．Ｂ）が、友だち登録画面の確認ボタンＢＴ７をタップすると、図２－８に示す送金画面に移行する。
このように、送金用のリンク情報がタップされた場合でも、送金画面に移行する前に、送金リマインドを行った第１ユーザが友だち登録されているユーザであるか否かを確認させる画面を表示することで、友だち登録されていないユーザに対して不用意に送金してしまうことを防止できる。

＜第２変形例（２）＞
第１変形例（２）に関連するが、送金リクエスト先ユーザの端末２０が、送金リマインド情報を受信したことに基づいて、リマインド通知処理を実行するようにすることができる。このリマインド通知処理は、限定ではなく例として、以下のいずれかの手法によって実現することができる。

・サーバ１０からプッシュ送信される送金リマインド情報を受信したことに基づいて、プッシュ通知を表示部２４に表示させるように制御する。
・制御部２１が、音出力部２６に所定の音を出力させるように制御する。
・制御部２１が、不図示の振動部を制御して端末２０の筐体を振動させる。
・制御部２１が、不図示の発光部に所定の発光を行わせるように制御する。

「プッシュ送信」とは、限定ではなく例として、送信対象とする情報（この例では、送金リマインド情報）が送信元の装置（この例では、サーバ１０）から送信されたこと、または送信先の装置（この例では、送金リクエスト先ユーザの端末２０）で受信されたことが、送信先の装置でプッシュ通知されるように送信することを意味する。

なお、送金リマインド情報を受信したことの他に、第１変形例（２）と同様のリマインド通知条件を設定しておき、リマインド通知条件が成立したことに基づいて、リマインド通知処理を実行するようにすることもできる。

本変形例は、送金リクエスト先ユーザの端末２０は、通信Ｉ／Ｆ２２による送金リマインド情報の受信に基づいて、リマインド通知処理（限定ではなく、端末による通知処理の一例）を制御部２１によって行う。この場合、リマインド通知処理は、設定されたリマインド通知条件（限定ではなく、第２条件の一例）に基づいて、制御部２１によって処理される構成を示している。
このような構成により得られる変形例の効果の一例として、第２情報が受信されたことを、第２条件に基づいて、端末のユーザに適切なタイミングで通知することができる。

＜第３実施例＞
第３実施例は、送金リマインド情報の表示・送信の手法・タイミングに関する実施例である。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

図３－１は、本実施例における送金リクエスト先ユーザの端末２０における送金リマインド表示の方法・表示タイミングを説明するためのタイミングチャートの一例を示す図である。
ここでは、第１実施例で説明した端末リマインドの手法を適用する場合における、送金リクエスト先ユーザの端末２０で送金リマインド表示を行うタイミングについて説明する。

このタイミングチャートでは、横軸を時間軸とし、送金リクエスト先ユーザの端末２０が、送金リクエスト表示・送金リマインド表示を行うタイミングを示している。送金リクエスト情報を白の丸で示し、送金リマインド情報を白のダイヤで示している。

設定として「オート」があり、これは、送金リクエスト先ユーザの端末２０が、送金リマインド情報を自動（オート）で表示する設定を示している。
この設定では、送金リクエスト先ユーザの端末２０は、限定ではなく例として、送金リクエスト表示を行ってから設定時間ｔｍが経過するごとに、送金リマインド表示を行う。

なお、これとは異なり、送金リクエスト先ユーザの端末２０が、限定ではなく例として、送金リクエスト情報をサーバ１０から受信してから設定時間ｔｍが経過するごとに、送金リマインド表示を行うようにしてもよいし、しなくてもよい。

＜第３実施例の効果＞
本実施例は、送金リクエスト情報（限定ではなく、第１情報の一例）は、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金マスターユーザの端末２０への入力に基づいて、サーバ１０を介して送金リクエスト先ユーザの端末２０に送信される。
また、送金リマインド表示（限定ではなく、第２表示の一例）は、送金リクエスト表示（限定ではなく、第１表示の一例）が送金リクエスト先ユーザの端末２０の表示部２４に表示された時刻、または送金リクエスト情報（限定ではなく、第１情報の一例）が送金リクエスト先ユーザの端末２０によって受信された時刻に基づいて、送金リクエスト先ユーザの端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示が端末の表示部に表示された時刻、または第１情報が端末によって受信された時刻に基づいて、適切なタイミングで第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、送金リクエスト先ユーザの端末２０は、第１送金リマインド表示（限定ではなく、第３表示の一例）を表示部２４に表示する。また、送金リクエスト先ユーザの端末２０は、第１送金リマインド表示を表示してから設定時間が経過したことに基づいて、第２送金リマインド表示（限定ではなく、第４表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第３表示が端末の表示部に表示されたことに基づいて、第４表示が端末の表示部に表示されるようにすることができる。

＜第３変形例（１）＞
第３実施例の手法は、第２実施例で説明したサーバリマインドの手法についても同様に適用可能である。

図３－２は、本変形例におけるサーバリマインドを説明するためのタイミングチャートの一例を示す図である。
図の見方は図３－１と同様であるが、マニュアルで送信する送金リマインド情報に対応するダイヤは「灰色」で示し、オートで送信する送金リマインド情報に対応するダイヤは「白色」で示している。

設定Ａは「マニュアル」であり、これは、送金マスターユーザの端末２０で送金リマインド実行入力がなされたことに基づいて、サーバ１０が、送金リマインド情報を送金リクエスト先ユーザの端末２０に送信する設定である。具体的には、サーバ１０は、送金マスターユーザの端末２０から送金リマインド送信要求情報を受信したことに基づいて、送金リクエスト先ユーザの端末２０に送金リマインド情報を送信する。

設定Ｂは「オート」であり、これは、サーバ１０が、送金マスターユーザの端末２０に依らず、送金リクエスト先ユーザの端末２０に送金リマインド情報を自動で送信する設定である。具体的には、サーバ１０は、送金リクエスト先ユーザの端末２０に送金リクエスト情報を送信してから設定時間ｔｎが経過するごとに、送金リクエスト先ユーザの端末２０に送金リマインド情報を送信する。

設定Ｃは「オート＆マニュアル」であり、これは、設定Ａと設定Ｂとを組み合わせた設定である。この設定では、サーバ１０は、基本的には設定Ｂ（オート）に従って送金リマインド情報を送信する。ただし、オートによる送金リマインド情報の送信の間にマニュアルによる送金リマインド情報の送信を挟んだ場合は、オートによる送金リマインド情報の送信を遅延させる。

具体的には、限定ではなく例として、サーバ１０は、基本的には送金リクエスト先ユーザの端末２０に送金リクエスト情報を送信してから設定時間ｔｎが経過するごとに、送金リクエスト先ユーザの端末２０に送金リマインド情報を送信する。ただし、オートによる送金リマインド情報の送信の間にマニュアルによる送金リマインド情報の送信を挟んだ場合は、オートによる最新の送金リマインド情報の送信タイミングに代えて、マニュアルによる最新の送金リマインド情報の送信タイミングから設定時間ｔｎが経過するごとに、送金リマインド情報を送信する。

設定Ａ～設定Ｃのいずれの設定を適用するかは、限定ではなく例として、送金マスターユーザによる自己の端末２０に対する入力に基づいて、設定に関する情報がサーバ１０に送信されて、サーバ１０で設定するようにすることができる。

なお、これに限らず、支払いサービスの事業者やサーバ１０の管理者等による入力に基づいて、サーバ１０側で上記の設定を行うようにしてもよいし、しなくてもよい。

本変形例は、送金リクエスト情報（限定ではなく、第１情報の一例）は、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金マスターユーザの端末２０への入力に基づいて、サーバ１０を介して送金リクエスト先ユーザの端末２０に送信される。
また、送金リマインド情報（限定ではなく、第２情報の一例）は、サーバ１０によって、送金リクエスト先ユーザの端末２０に送信され、送金リマインド表示（限定ではなく、第２表示の一例）は、送金リマインド情報に基づいて、送金リクエスト先ユーザの端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第１ユーザの意向に応じて、第１情報がサーバを介して端末に送信されるようにすることができる。また、第２情報がサーバから端末に送信された上で、その第２情報に基づいて、第２表示が端末の表示部に表示されるようにすることができる。

また、本変形例は、上記において、送金リマインド情報は、送金リクエスト情報が送金リクエスト先ユーザの端末２０に送信されてから設定時間が経過したことに基づいて（限定ではなく、第１情報が端末に送信された時刻、または第１情報が端末によって受信された時刻に基づいて一例）、端末に送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報が端末に送信された時刻、または第１情報が端末によって受信された時刻に基づいて、適切なタイミングで第２情報が端末に送信されるようにすることができる。

また、本変形例は、上記において、送金リクエスト先ユーザの端末２０は、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金マスターユーザの端末２０への入力に基づいて、送金マスターユーザの端末２０から送信される第１送金リマインド情報（限定ではなく、送金依頼に基づく第３情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、送金リクエスト先ユーザの端末２０は、第１送金リマインド表示（限定ではなく、第３表示の一例）を表示部２４に表示する。この場合、限定ではなく例として、第１送金リマインド情報が送信されてから設定時間が経過したことに基づいて、第２送金リマインド情報（限定ではなく、第２情報の一例）が、端末２０に送信される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第３情報が端末に送信されることに基づいて、送金依頼に基づく第２情報が適切に端末に送信されるようにすることができる。

＜第３変形例（２）＞
第３実施例で説明した端末リマインドの方法（設定：オート）について、１回目の送金リマインド情報の表示と、２回目以降の送金リマインド情報の表示とで、設定時間を異ならせるようにすることも可能である。

具体的には、限定ではなく例として、送金リクエスト先ユーザの端末２０は、送金リクエスト表示、または送金リクエスト情報の受信から第１設定時間が経過したタイミングで、１回目の送金リマインド表示を行う。
また、送金リクエスト先ユーザの端末２０は、１回目の表示から第２設定時間が経過したタイミングで、２回目の送金リマインド表示を行う。
また、送金リクエスト先ユーザの端末２０は、２回目の表示から第３設定時間が経過したタイミングで、３回目の送金リマインド表示を行う。
以下同様である。

この場合、限定ではなく例として、第１設定時間が最も長い時間となるようにすることができる。

一例として、第１設定時間を「２４時間」とし、他の設定時間（第２設定時間、第３設定時間、・・・）を「２４時間」よりも短い時間とすることができる。この場合、他の設定時間は、全て同じ時間としてもよいし、異なる時間としてもよい。

異なる時間とする場合は、限定ではなく例として、送金リマインド表示を行うごとに、設定時間が短くなるようにすることができる。
具体的には、限定ではなく例として、第１設定時間を「２４時間」、第２設定時間を「１８時間」、第３設定時間を「１２時間」、・・・、等のようにすることができる。
このようにすることで、送金リクエストに関する表示の時間間隔（表示時間間隔）が段階的に短くなっていくため、未だ送金が行われていないことを送金リクエスト先ユーザに認識させ、送金を早く行うように注意喚起することができる。

なお、上記とは逆に、第１設定時間が最も短い時間となるようにしてもよいし、しなくてもよい。

また、これらの内容は、図３－２で説明したサーバリマインドにおける、送金リマインド情報の送信の時間間隔（送信時間間隔）についても同様に適用可能である。

また、図３－２の設定Ｃ（オート＆マニュアル）において、サーバ１０によるオートによる送金リマインド情報の送信の間にマニュアルによる送金リマインド情報の送信を挟んだ場合に、オートによる送金リマインド情報の送信を遅延させるのではなく、オートによる送金リマインド情報の送信をスキップさせるようにしてもよいし、しなくてもよい。

＜第４実施例＞
第４実施例は、送金リマインドを行う条件に関する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、第１実施例で説明した端末リマインドの手法を適用し、送金リクエスト先ユーザの端末２０が送金リマインド条件の成否を判定して、端末リマインドを行う場合について説明する。

図４－１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図１－１３～図１－１４のフローチャートにおける図１－１４の処理部分に対応するフローチャートである。

図１－１３のＢ１４０の後、端末２０Ｂの制御部２１は、送金リマインド条件が成立するか否かを判定する（Ｂ４５０）。そして、成立すると判定したならば（Ｂ４５０：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ１５０に処理を移す。

図４－２は、本実施例における送金リマインド条件を定めた送金リマインド条件データの一例を示す図である。
送金リマインド条件データには、限定ではなく例として、カテゴリと、送金リマインド条件とが関連付けて定められている。

カテゴリには、限定ではなく例として、「時間」、「残高」、「入金（送金）」、「その他」といった、異なる複数の概念に基づく区分が含まれる。

送金リマインド条件には、限定ではなく例として、条件の番号を示す条件Ｎｏと、その条件Ｎｏの送金リマインド条件の内容とが含まれる。

具体例を挙げて説明する。
（１）カテゴリ「時間」
条件Ｎｏ「ＰＡ－１」については、送金リマインド条件の内容として「時刻が設定時刻となった」が定められている。設定時刻には、毎日の任意の時刻（限定ではなく例として深夜０時や昼１２時）を設定しておくことができる。
この条件は、現在の時刻が毎日の設定時刻となったタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

この場合、端末２０の制御部２１は、時計部２９Ａによる計時時刻が設定時刻となったか否かを判定し、なったと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＡ－２」については、送金リマインド条件の内容として「リマインドのタイミングとなった＆時刻が第１設定時間帯に含まれる」が定められている。第１設定時間帯には、毎日の任意の設定時間帯を設定しておくことができる。
この条件は、端末リマインドを行うタイミングとなった場合に、現在の時刻が設定時間帯に含まれれば、送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、ユーザが端末２０を閲覧する可能性が高い時間帯、限定ではなく例として、ユーザが帰宅して自由な時間を過ごしていることが多い夜９時から深夜０時までの時間帯等の時間帯を第１設定時間帯として設定しておくことができる。

この条件を適用する場合における端末リマインドのタイミングについては、限定ではなく例として、第３実施例（図３－１）で説明したタイミングを適用することができる。
この場合、端末２０の制御部２１は、端末リマインドを行うタイミングであるか否かを判定する。そして、端末リマインドを行うタイミングである場合は、時計部２９Ａによる計時時刻が第１設定時間帯に含まれているか否かを判定し、含まれていると判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＡ－３」については、送金リマインド条件の内容として「リマインドのタイミングとなった＆時刻が第２設定時間帯に含まれない」が定められている。第２設定時間帯には、毎日の任意の設定時間帯を設定しておくことができる。
この条件は、端末リマインドを行うタイミングとなった場合に、現在の時刻が設定時間帯に含まれなければ、送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、ユーザが端末２０を閲覧する可能性の低い時間帯、限定ではなく例として、ユーザが就寝している可能性が高い夜遅く（翌日０時まで）の時間帯、未明（翌日３時まで）の時間帯、明け方（翌日３時から）の時間帯等の時間帯を、第２設定時間帯として設定しておくことができる。

この条件を適用する場合における端末リマインドのタイミングについても、限定ではなく例として、第３実施例（図３－１）で説明したタイミングを適用することができる。
この場合、端末２０の制御部２１は、端末リマインドを行うタイミングであるか否かを判定する。そして、端末リマインドを行うタイミングである場合は、時計部２９Ａによる計時時刻が第２設定時間帯に含まれるか否かを判定し、含まれないと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＡ－４」については、送金リマインド条件の内容として「日付が設定されている日付となった」が定められている。この場合の日付には、任意の日付（限定ではなく例として「毎月１５日」や「毎月２５日」）を設定しておくことができる。
この条件は、現在の日付が設定されている日付となったタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、送金リクエスト先ユーザに金銭の余裕が生ずる日付、限定ではなく例として、給与が支給される日付（給料日）を設定しておくことができる。

この場合、端末２０の制御部２１は、時計部２９Ａの計時情報に基づき、現在の日付が設定された日付となったか否かを判定し、なったと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

（２）カテゴリ「残高」
条件Ｎｏ「ＰＢ－１」については、送金リマインド条件の内容として「電子マネー口座残高が設定金額以上」が定められている。設定金額には、任意の金額（限定ではなく例として「３０，０００円」）を設定しておくことができる。
この条件は、電子マネーの口座残高が設定金額以上となったタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、その送金リクエスト先ユーザに対する送金リクエスト金額のうちの最大の金額の２倍以上の金額や、３万円以上等のある程度大きな金額を、設定金額として設定するようにすることができる。

この場合、限定ではなく例として、端末２０の制御部２１は、通信Ｉ／Ｆ２２によって、自己の端末２０のユーザの電子マネー口座残高を問い合わせる。通信Ｉ／Ｆ１４によって端末２０から電子マネー口座残高の問い合わせを受けると、サーバ１０の制御部１１は、そのユーザの電子マネー口座残高の情報を、通信Ｉ／Ｆ１４によって端末２０に送信する。
そして、端末２０の制御部２１は、受信した電子マネー口座残高の情報に基づき、電子マネー口座残高が設定金額以上となったか否かを判定し、なったと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＢ－２」については、送金リマインド条件の内容として「所持残高が設定金額以上」が定められている。設定金額には、任意の金額（限定ではなく例として「３０，０００円」）を設定しておくことができる。
この条件は、ユーザによって端末２０に入力された所持残高が設定金額以上となったタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

この場合、端末２０の制御部２１は、所持残高の入力をユーザに促す画面を表示部２４に表示するなどして所持残高を入力させる。そして、入力された所持残高が設定金額以上であるか否かを判定し、所持残高が設定金額以上であると判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

（３）カテゴリ「入金（送金）」
条件Ｎｏ「ＰＣ－１」については、送金リマインド条件の内容として「ローンを借りることにより入金」が定められている。
この条件は、限定ではなく例として、ユーザがローンサービス、限定ではなく例として、ロークサービスの事業者によって提供されるサービスであって、ローンアプリケーション等の物的貨幣や電子貨幣に関するアプリケーションによってユーザがローンを借りることのできるサービスを利用して、銀行や電子マネーの口座残高に入金されたタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

ローンサービスの事業者は、限定ではなく例として、前述した支払いアプリケーションの事業者やメッセージングサービスの事業者と同じ事業者としてもよいし、異なる事業者としてもよい。
異なる事業者とするのであれば、ローンサービスの事業者は、支払いアプリケーションの事業者やメッセージングサービスの事業者と提携し、端末２０のユーザのローンの金額等に関する情報を、サーバ１０に送信するなどして、支払いアプリケーションの事業者やメッセージングアプリケーションの事業者に提供するようにすることができる。

限定ではなく例として、送金リクエスト先ユーザの銀行（限定ではなく例としてネットバンク）や支払いアプリケーションの電子マネーの口座残高に、ローンサービスの事業者から入金（送金）されることで、送金リクエスト先ユーザに経済的な余裕が発生した場合を、送金リマインド条件の内容として定めることができる。

この場合、端末２０の制御部２１は、限定ではなく例として、サーバ１０から送信される情報（通知を含む。）に基づいて、ローンを借りることにより入金されたか否かを判定する。そして、入金されたと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＣ－２」については、送金リマインド条件の内容として「出品した商品が購入されることにより入金」が定められている。
この条件は、限定ではなく例として、ユーザがフリーマーケットサービス、限定ではなく例として、フリーマーケットサービスの事業者によって提供されるサービスであって、フリーマーケットアプリケーション（以下、「フリマアプリケーション」と称する。）等のアプリケーションによって商品を出品・購入することのできるサービスを利用して、出品した商品が購入されるなどして電子マネー口座残高に入金されたタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、送金リクエスト先ユーザの支払いアプリケーションの電子マネーの口座残高に、フリマアプリケーションから入金（送金）されることで、送金リクエスト先ユーザに経済的な余裕が発生した場合を、送金リマインド条件の内容として定めることができる。

この場合、端末２０の制御部２１は、サーバ１０から送信される情報（通知を含む。）に基づいて、フリマアプリケーションで出品した商品が購入されることにより入金されたか否かを判定する。そして、入金されたと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

（３）カテゴリ「その他」
条件Ｎｏ「ＰＤ－１」については、送金リマインド条件の内容として「出品した商品が購入された（未入金）」が定められている。
この条件は、限定ではなく例として、ユーザがフリマアプリケーション等によって出品した商品が購入されたタイミング（電子マネーの口座残高に入金されていないタイミング）で送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、送金リクエスト先ユーザがフリマアプリケーション等によって出品した商品が購入された場合、限定ではなく例として、出品した商品が購入されたことによって、送金リクエスト先ユーザの電子マネーの口座残高にフリマアプリケーションから入金されていないものの、入金されることを見込むことができる。そのため、送金リクエスト先ユーザに経済的な余裕の発生を見込むことができる場合を、送金リマインド条件の内容として定めることができる。

この場合、端末２０の制御部２１は、サーバ１０から送信される情報（通知を含む。）に基づいて、フリマアプリケーションで出品した商品が購入されたか否かを判定し、購入されたと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＤ－２」については、送金リマインド条件の内容として「求職アプリケーションで求職中」が定められている。
この条件は、ユーザが求職サービス（求職アプリケーション）等のサービスにおいて、求職を行っている期間の所定のタイミング（求職アプリケーションで、限定ではなく例として、企業にエントリーしたタイミングや企業から内定通知がきたタイミング等）で送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、送金リクエスト先ユーザが求職サービス等において、求職を行っている場合、限定ではなく例として、送金リクエスト先ユーザが求職を行うことは、就労した後に賃金を得る見込みがあり、送金リクエスト先ユーザに経済的な余裕の発生を見込むことができる場合であるので、送金リマインド条件の内容として定めることができる。

この場合、端末２０の制御部２１は、自己の端末２０で求職アプリケーションを実行中であるか否かを判定し、実行中であると判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

条件Ｎｏ「ＰＤ－３」については、送金リマインド条件の内容として「フリマアプリケーションで商品購入」が定められている。
この条件は、ユーザがフリマアプリケーション等のサービスにおいて、出品された商品を購入したタイミングで送金リマインド表示を表示部２４に表示することによって、未だ送金が行われていないことをユーザに知らせる趣旨の条件である。

限定ではなく例として、送金リクエスト先ユーザがフリマアプリケーション等によって商品を購入した場合、限定ではなく例として、送金リクエスト先ユーザが商品を購入した場合、送金リクエスト先ユーザに経済的な余裕があると認識できる場合を、送金リマインド条件の内容として定めることができる。

この場合、端末２０の制御部２１は、サーバ１０から送信される情報（通知を含む。）に基づいて、フリマアプリケーションで出品された商品を購入したか否かを判定し、購入したと判定した場合に、送金リマインド表示を表示部２４に表示させるようにすることができる。

上記の送金リマインド条件は、限定ではなく例として、送金リクエスト先ユーザによる自分の端末２０に対する入力に基づいて、送金リクエスト先ユーザの端末２０によって設定され、送金リクエスト先ユーザの端末２０の記憶部２８に記憶されるようにすることができる。

なお、これに限らず、限定ではなく例として、送金マスターユーザによる自分の端末２０に対する入力に基づいて、送金マスターユーザの端末２０によって、上記の送金リマインド条件が設定されるようにしてもよいし、そのようにしなくてもよい。この場合は、限定ではなく例として、送金マスターユーザの端末２０によって設定された送金リマインド条件が、サーバ１０を介して、送金リクエスト先ユーザの端末２０に送信・通知されて、送金リクエスト先ユーザの端末２０の記憶部２８に記憶されるようにすることができる。

また、送金リクエスト先ユーザの端末２０が、上記の送金リマインド条件の成否を判定する場合に、１つの条件の成否を判定するようにしてもよいし、２以上の条件の成否を判定するようにしてもよい。つまり、２以上の条件を組み合わせて判定を行うようにしてもよい。

＜表示画面＞
図４－３は、限定ではなく例として、送金リクエスト情報を受信したが、未だ送金を完了していないユーザ（Ｂ．Ｂ）が、前述したフリマアプリケーションを利用して取引を行い、そのユーザ（Ｂ．Ｂ）の口座に売上金額に応じた入金があった例を示している。

ユーザ（Ｂ．Ｂ）の端末２０は、支払いアプリケーションの公式アカウントから、支払いアプリケーションによる取引が完了したことを示すメッセージＭＳ２５を受信する。
限定ではなく例として、このメッセージＭＳ２５には、取引が完了したことを示す「取引完了」の文字と、その取引による売上金額（本例では「１，６００円」）と、ユーザ（Ｂ．Ｂ）がその売上金額を受け取る立場であることを示す「受取」の文字のアイコンと、取引が完了した日時（本例では、２０２０．０４２３２０：５９）等が含まれる。

このメッセージＭＳ２５が表示された場合、ユーザ（Ｂ．Ｂ）の電子マネー口座には、少なくとも売上金額に相当する金額が残存している可能性が高い。

続けて、ユーザ（Ｂ．Ｂ）の端末２０は、図４－４に示すように、支払いアプリケーションの公式アカウントから、送金リマインド情報を受信したことを示すメッセージＭＳ２６を受信する。

メッセージＭＳ２６の内容は、第１ユーザ（Ａ．Ａ）のアイコン画像ではなく公式アカウントのアイコン画像が含まれる点を除いて、前述した送金リマインド表示ＭＳ４Ａの内容と同様である。

端末２０は、限定ではなく例として、メッセージＭＳ２５の受信直後に、メッセージＭＳ２６を受信する。従って、ユーザ（Ｂ．Ｂ）の電子マネー口座に、少なくとも売上金額に相当する金額が残存している状態で、そのユーザ（Ｂ．Ｂ）がメッセージＭＳ２６を確認する可能性が高いと言える。
限定ではなく例として、このメッセージＭＳ２６の表示によって、ユーザ（Ｂ．Ｂ）の口座に入金があったことに基づいて、その直後に送金を行うように促すことができる。

＜第４実施例の効果＞
本実施例は、送金リマインド表示（限定ではなく、第２表示の一例）は、送金リマインド条件（限定ではなく、第１条件の一例）に基づいて、送金リクエスト先ユーザの端末２０に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、設定された第１条件に基づいて、送金依頼に基づく第２表示を端末の表示部に適切に表示させることができる。

また、本実施例は、送金リマインド条件は、時刻、時間帯、日付、経過時間等の条件（限定ではなく、時間に関する条件の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、時間に関する条件に基づいて、送金依頼に基づく第２表示を端末の表示部に適切に表示させることができる。

また、本実施例は、送金リマインド条件は、送金リクエスト先ユーザの端末２０（限定ではなく、端末の一例）によって設定された時刻、または時間の条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じた適切なタイミングで、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、送金リマインド条件は、送金マスターユーザの端末２０（限定ではなく、第１ユーザの端末の一例）によって設定された時刻、または時間の条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第１ユーザの意向に応じた適切なタイミングで、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、送金リマインド条件は、送金リクエスト先ユーザの電子マネー口座残高や所持残高等の残高（限定ではなく、端末のユーザに関連付けられた残高の一例）に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼を受ける側のユーザの残高に応じた適切なタイミングで、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、送金リマインド条件は、送金リクエスト先ユーザへの入金（送金）に関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザへの送金に関する条件に基づいて、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、上記の送金リクエスト先ユーザへの入金（送金）に関する条件は、送金リクエスト先ユーザがローンを借りることにより入金（送金）されることを含む構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザがローンを借りることで、端末のユーザの金銭に余裕が生じた可能性が高いタイミングで、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、上記の送金リクエスト先ユーザへの入金（送金）に関する条件は、送金リクエスト先ユーザが出品した商品が購入されたことにより、商品の購入者によって送金リクエスト先ユーザに入金（送金）されることを含む構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザが出品した商品が購入されて購入者によって入金（送金）され、端末のユーザの金銭に余裕が生じた可能性が高いタイミングで、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

また、本実施例は、送金リクエスト条件は、送金リクエスト先ユーザが出品した商品が購入されたことに関する条件を含む構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザが出品した商品が購入されたことで、端末のユーザの金銭に余裕が生ずる見込みができたことに基づいて、送金依頼に基づく第２表示が端末の表示部に表示されるようにすることができる。

＜第４変形例（１）＞
第２実施例で説明したサーバリマインドの手法を適用し、サーバ１０が送金リマインド条件の成否を判定して、サーバリマインドを行うようにすることもできる。

この場合、基本的には、図４－２のテーブルに例示した送金リマインド条件と同様の条件を適用することができる。ただし、本変形例では、送金リマインド条件の判定主体が、端末２０ではなくサーバ１０となる。

カテゴリ「時間」の条件は、サーバ１０の制御部１１が、時計部１９の計時情報に基づいて判定することができる。
この場合、条件Ｎｏ「ＰＡ－２」または条件「ＰＡ－３」を適用する場合におけるリマインドのタイミングについては、限定ではなく例として、第３変形例（１）（図３－２）で説明したサーバリマインドのタイミングを適用することができる。

カテゴリ「残高」の条件は、サーバ１０の制御部１１が、記憶部１５に記憶して管理している端末２０のユーザの電子マネー口座残高の情報や、端末２０で入力されてサーバ１０に送信される所持残高の情報に基づいて判定することができる。

カテゴリ「入金（送金）」の条件は、サーバ１０の制御部１１が、送金決済処理によって、記憶部１５に記憶して管理している端末２０のユーザの電子マネー口座残高の情報が更新されたことに基づいて判定することができる。

カテゴリ「その他」の条件について、条件Ｎｏ「ＰＤ－１」の条件は、フリマサービスが支払いサービスの１つとして提供されるのであれば、サーバ１０の制御部１１が、フリマサービスを利用して端末２０のユーザが出品した商品が購入されたことを検知することで、判定することができる。
また、フリマサービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ１０の制御部１１が、フリマサービスを提供する事業者のサーバ等の装置から、端末２０のユーザが出品した商品が購入されたことを示す情報を取得できるように構成しておくことで、判定することができる。

条件Ｎｏ「ＰＤ－２」の条件は、求職サービスが支払いサービスの１つとして提供されるのであれば、サーバ１０の制御部１１が、求職サービスを利用して端末２０のユーザが求職情報を検索していることを検知することで、判定することができる。
また、求職サービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ１０の制御部１１が、求職サービスを提供する事業者のサーバ等の装置から、端末２０のユーザが求職サービスを利用していることを示す情報を取得できるように構成しておくことで、判定することができる。

条件Ｎｏ「ＰＤ－３」の条件は、フリマサービスが支払いサービスの１つとして提供されるのであれば、サーバ１０の制御部１１が、フリマサービスを利用して、出品されている商品を端末２０のユーザが購入したことを検知することで、判定することができる。
また、フリマサービスを提供する事業者が支払いサービスを提供する事業者と異なる場合は、サーバ１０の制御部１１が、フリマサービスを提供する事業者のサーバ等の装置から、出品されている商品を端末２０のユーザが購入したことを示す情報を取得できるように構成しておくことで、判定することができる。

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

図１－１３のＳ１５０の後、サーバ１０の制御部１１は、送金リマインド条件が成立するか否かを判定する（Ｓ４６０）。そして、成立すると判定したならば（Ｓ４６０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ２７０に処理を移す。

通信Ｉ／Ｆ２２によってサーバ１０から送金リマインド情報を受信すると、端末２０Ｂの制御部２１は、Ｂ２５０に処理を実行する。

本変形例は、送金リマインド条件（限定ではなく、第１条件の一例）の成否に基づいて、送金リクエスト先ユーザの端末２０が、送金リマインド情報（限定ではなく、送金依頼に基づく第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、送金リマインド表示は、送金リマインド情報の受信に基づいて、送金リクエスト先ユーザの端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１条件に基づいて、送金依頼に基づく第２情報を端末が受信して表示することができる。また、第１条件の成否を端末側で判定せずに済むため、端末の処理負荷を軽減することができる。

＜第４変形例（２）＞
第４変形例（１）において、サーバ１０の制御部１１が判定する送金リマインド条件に、「送金マスターユーザの端末から送金リマインド送信要求情報を受信したこと」を含めるようにしてもよいし、しなくてもよい。
この場合の処理は、図２－１２の処理と、図４－５の処理とを組み合わせることによって実現可能である。

＜第５実施例＞
第５実施例は、前述した送金リクエスト表示や送金リマインド表示を、チャットサービスによって利用可能なチャットルームに表示する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

本実施例では、チャットサービスをメッセージングサービス（限定ではなく例として、インスタントメッセージングサービス：ＩＭＳ）とし、端末２０にインストールされたメッセージングアプリケーションによって、送金リクエスト表示や送金リマインド表示を行う場合を例示する。
また、メッセージンサービス（メッセージングアプリケーション）を適用する場合のチャットルームとして、以下ではトークルームを例示する。

＜表示画面＞
以下の例では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるＡ．Ａと、Ｂ．Ｂと、Ｃ．Ｃが、何れもグループＸに属しており、友だち登録されているものとする。

図５－１の例は、ユーザＡ．Ａの端末２０の表示部２４に、グループＸのトークルーム（限定ではなく、チャットルームの一例）において、友だち間で相互にやり取りされたメッセージが表示されている。
この例では、Ａ．Ａが、Ｂ．ＢとＣ．Ｃに対して、メッセージにより送金を依頼しており、そのメッセージをＢ．ＢとＣ．Ｃは確認している（既読２）。
すなわち、Ａ．Ａは、送金依頼を行った第１ユーザの一例であり、Ｂ．Ｂと、Ｃ．Ｃが、送金リクエスト情報を受信した端末２０のユーザの一例である。

この例は、一方の端末２０のユーザであるＣ．Ｃからは送金した旨の返答があったものの、他方の端末２０のユーザであるＢ．Ｂからは返答がない状態を示している。
Ａ．Ａが、トークルームの下部に表示されたアイコンのうち、右下の送金アイコンをタップすると、トークルーム上に送金項目選択領域ＳＭＲが表示される。

送金項目選択領域ＳＭＲの上部には、下方に示されたボタンを操作することによって、送金に関する機能に基づく処理が実行されることを通知する情報（限定ではなく例として、「送金メニュー」という文字）が表示されている。
その下方には、他のユーザに送金するためのボタンＢＴＭ１と、他のユーザに送金リクエスト情報を送信するためのボタンＢＴＭ２と、送金依頼履歴を表示するためのボタンＢＴＭ３が表示されている。

限定ではなく例として、第１ユーザであるＡ．Ａが、ボタンＢＴＭ３をタップすると、Ａ．Ａの過去の送金依頼のうち、送金処理が未完了であるものに関する履歴が、トークルーム上に表示される。

この例では、第１ユーザ（Ａ．Ａ）が、端末２０のユーザであるＢ．Ｂに、送金リクエスト情報を送信したものの、この送金依頼に対しての送金処理が未完了であることに基づいて、領域Ｒ１に、Ｂ．Ｂのアイコン画像およびユーザ名と、「リクエスト送信」の文字のアイコンと、送金リクエスト情報の送信日時（２０２０．０４．２０２１：３０）と、Ｂ．Ｂから支払いを受ける立場であることを示す「受取」の文字のアイコンと、Ｂ．Ｂから受け取るべき金額（３，０００円）と、が表示されている。

また、この例では、画面下部に「リマインドする」と表示された領域ＲＲが設けられている。第１ユーザ（Ａ．Ａ）が、領域Ｒ２１のチェックボックスをチェックした状態とすることで、領域Ｒ２１内に表示されている各情報が選択された状態となる。
この状態で領域ＲＲがタップされることで、領域Ｒ１内に表示されていた情報に基づく送金リマインド情報が、送金リクエスト情報の送信対象となっていたユーザ（Ｂ．Ｂ）の端末２０に送信される。

図５－２は、限定ではなく例として、グループＸに属する第１ユーザ（Ａ．Ａ）の端末２０に表示されるメッセージと、第１ユーザによる送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０に表示されるメッセージと、第１ユーザによる送信リマインドの対象とならなかったユーザ（Ｃ．Ｃ）の端末２０に表示されるメッセージの関係を示している。

第１ユーザ（Ａ．Ａ）の端末２０には、Ｂ．Ｂの端末２０に対して送金リマインド情報が送信されたことに基づいて、自分（Ａ．Ａ）が送信したメッセージとして、メッセージＭＳ１１が表示されている。

限定ではなく例として、メッセージＭＳ１１には、グループ内のユーザに対して送金リマインド情報を送信したことを示す「リマインド送信」の文字のアイコンと、そのメッセージが支払いアプリケーションの機能に基づくことを示す［ＰａｙｍｅｎｔＡｐｐ］の文字と、送金リマインド情報を受信したグループ内のユーザのユーザ名（本例では、「Ｂ．Ｂへの送金リクエスト」という文字）と、送金リマインド情報により送金を依頼した金額（本例では￥３，０００）と、自分（Ａ．Ａ）が支払いを受ける立場であることを示す「受取」の文字のアイコンと、が含まれる。

限定ではなく例として、メッセージＭＳ１１の下部には、「送金する」の文字を含む送金ボタンＢＴ１１ａと、「断る」の文字を含むボタンＢＴ１１ｂが表示されている。
ここで、仮に、第１ユーザ（Ａ．Ａ）が、送金ボタンＢＴ１１ａをタップしたとしても、このメッセージＭＳ１１に関して送金先となっているのは自分（Ａ．Ａ）であるため、送金画面には移行せず、送金処理は実行されない。
従って、送金ボタンＢＴ１１ａは、操作に応じて送金処理が実行されないことから、選択不能態様で表示されている。

また、仮に、第１ユーザ（Ａ．Ａ）が、ボタンＢＴ１１ｂをタップしたとしても、このメッセージＭＳ１１に関して送金先となっているのは自分（Ａ．Ａ）であるため、他のユーザに対して、送金を断った旨のメッセージは送信されない。
従って、ボタンＢＴ１１ｂは、操作に応じてメッセージが送信されないことから、選択不能態様で表示されている。

送金リマインド情報を受信したＢ．Ｂの端末２０には、第１ユーザ（Ａ．Ａ）から送金リマインド情報が送信されたことに基づいて、第１ユーザ（Ａ．Ａ）のメッセージとして、メッセージＭＳ２１が表示されている。

限定ではなく例として、メッセージＭＳ２１には、グループ内のユーザから送金リマインド情報を受信したことを示す「リマインド受信」の文字のアイコンと、そのメッセージが支払いアプリケーションの機能に基づくことを示す［ＰａｙｍｅｎｔＡｐｐ］の文字と、送金リマインド情報を受信したグループ内のユーザ（自分）のユーザ名（本例では、「Ｂ．Ｂへの送金リクエスト」という文字）と、送金リマインド情報により送金を依頼された金額（本例では￥３，０００）と、自分（Ｂ．Ｂ）が支払いを行う立場であることを示す「支払い」の文字のアイコンと、が含まれる。

限定ではなく例として、メッセージＭＳ２１の下部には、「送金する」の文字を含む送金ボタンＢＴ２１ａと、「断る」の文字を含むボタンＢＴ２１ｂが表示されている。
端末２０のユーザ（Ｂ．Ｂ）が、送金ボタンＢＴ２１ａをタップすると、前述した送金画面に移行し、送金処理を実行可能となる。

すなわち、このメッセージＭＳ２１に関して送金先となっているのは、メッセージＭＳ２１に対応して画像アイコンとユーザ名が表示されている第１ユーザ（Ａ．Ａ）であるため、送金ボタン２１ａの操作によって、Ｂ．Ｂの口座からＡ．Ａの口座に、送金依頼金額（本例では３，０００円）に相当する金額が送金される。
従って、送金ボタンＢＴ２１ａは、操作に応じて送金処理が実行されることから、前述した送金ボタンＢＴ１１ａおよび後述する送金ボタン３１ａとは異なる選択可能態様で表示されている。

また、端末２０のユーザ（Ｂ．Ｂ）が、ボタンＢＴ２１ｂをタップすると、メッセージＭＳ２１に関連付けられた第１ユーザ（Ａ．Ａ）に対して、送金を断った旨のメッセージが送信される。
従って、ボタンＢＴ２１ｂは、操作に応じてメッセージが送信されることから、前述したボタンＢＴ１１ｂおよび後述するボタン３１ｂとは異なる選択可能態様で表示されている。

第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象となっているユーザ（Ｂ．Ｂ）でもない他のユーザ（Ｃ．Ｃ）の端末２０には、第１ユーザであるＡ．Ａが、Ｂ．Ｂに対して送金リマインド情報を送信したことに基づいて、第１（Ａ．Ａ）が送信したメッセージとして、メッセージＭＳ３１が表示されている。

限定ではなく例として、メッセージＭＳ３１には、自分とは異なる一方のユーザ（第１ユーザであるＡ．Ａ）から自分とは異なる他方のユーザ（Ｂ．Ｂ）に対して送金リマインド情報が送信されたことを示す「リマインド」の文字のアイコンと、そのメッセージが支払いアプリケーションの機能に基づくことを示す［ＰａｙｍｅｎｔＡｐｐ］の文字と、送金リマインド情報を受信したグループ内のユーザのユーザ名（本例では、「Ｂ．Ｂへの送金リクエスト」という文字）と、送金リマインド情報により送金が依頼された金額（本例では￥３，０００）と、第１ユーザ（Ａ．Ａ）のアイコン画像および送金リマインド情報を受信したユーザ（Ｂ．Ｂ）のアイコン画像、が含まれる。

なお、第１ユーザ（Ａ．Ａ）のアイコン画像から、送金リマインド情報を受信したユーザ（Ｂ．Ｂ）のアイコン画像に向かう矢印が表示されている。これにより、他のユーザ（Ｃ．Ｃ）は、自分とは異なる一方のユーザ（Ａ．Ａ）から、自分とは異なる他方のユーザ（Ｂ．Ｂ）に対して送金リマインド情報が送信されたことを認識できる。

また、限定ではなく例として、メッセージＭＳ３１には、メッセージＭＳ１１に含まれた「リマインド送信」の文字のアイコン、および、メッセージＭＳ２１に含まれた「リマインド受信」の文字のアイコンは、何れも含まれていない。これにより、メッセージＭＳ３１に関する送金リマインドが、自分から他のユーザに対してのものではなく、他のユーザから自分に対してのものでもないことを認識できる。

限定ではなく例として、メッセージＭＳ３１の下部には、「送金する」の文字を含む送金ボタンＢＴ３１ａと、「断る」の文字を含むボタンＢＴ３１ｂが、何れも選択不能態様で表示されている。

次に、送金リマインド情報を受信したユーザ（Ｂ．Ｂ）が、送金依頼金額の支払いを行った場合の例について、図５－３を用いて説明する。
送金リマインドの対象となっているユーザ（Ｂ．Ｂ）が送金ボタンＢＴ２１ａをタップしたことに基づいて、第１ユーザ（Ａ．Ａ）への送金処理が完了すると、図５－３に示すように、第１ユーザ（Ａ．Ａ）の端末２０には、送金を完了したユーザ（Ｂ．Ｂ）のメッセージとしてメッセージＭＳ１２が表示される。

限定ではなく例として、メッセージＭＳ１２には、［ＰａｙｍｅｎｔＡｐｐ］の文字とともに、第１ユーザのユーザ名と、その第１ユーザに対する送金依頼金額と、その送金依頼金額の支払いが完了したことを示すメッセージ（本例では、「Ａ．Ａさんに３，０００円を送金しました」という文字）が含まれる。

また、第１ユーザである自分（Ａ．Ａ）のメッセージとして、メッセージＭＳ１３が表示される。
限定ではなく例として、メッセージＭＳ１３には、［ＰａｙｍｅｎｔＡｐｐ］の文字とともに、送金リマインドの対象となったユーザのユーザ名と、そのユーザから送金依頼金額を受け取ったことを示すメッセージ（本例では、「送金受け取り」、「Ｂ．Ｂから送金を受け取りました。」）と、送金依頼金額（本例では３，０００円）と、その送金依頼金額を自分（Ａ．Ａ）が受け取った立場であることを示す「受取」の文字のアイコンが含まれる。

一方、送金リマインドの対象となったユーザであって、送金リマインド情報により指定された金額の支払いを行ったユーザ（Ｂ．Ｂ）の端末２０には、自分（Ｂ．Ｂ）のメッセージとして、メッセージＭＳ２２が表示される。
限定ではなく例として、メッセージＭＳ２２の内容は、メッセージＭＳ１２の内容と同様である。

また、第１ユーザ（Ａ．Ａ）のメッセージとして、メッセージＭＳ２３が表示される。メッセージＭＳ２３には、送金依頼金額を自分（Ｂ．Ｂ）が支払った立場であることを示す「支払い」の文字のアイコンが含まれ、「受取」の文字のアイコンは含まれない点で、メッセージＭＳ１３とは異なる。

また、第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象にもならなかった他のユーザ（Ｃ．Ｃ）の端末２０には、送金リマインド情報により指定された金額の支払いを行ったユーザ（Ｂ．Ｂ）のメッセージとして、メッセージＭＳ３２が表示される。
限定ではなく例として、メッセージＭＳ３２の内容は、メッセージＭＳ１２の内容と同様である。

また、第１ユーザ（Ａ．Ａ）のメッセージとして、メッセージＭＳ３３が表示される。メッセージＭＳ３３には、「受取」の文字のアイコンと、「支払い」の文字のアイコンが何れも含まれておらず、代わりに第１ユーザ（Ａ．Ａ）のアイコン画像と、送金リマインドの対象となったユーザ（Ｂ．Ｂ）のアイコン画像とが含まれる点で、メッセージＭＳ１３、ＭＳ２３とは異なる。

なお、自分（Ｃ．Ｃ）とは異なる第１ユーザ（Ａ．Ａ）のアイコン画像から、自分（Ｃ．Ｃ）とは異なるユーザ（Ｂ．Ｂ）のアイコン画像に向かう矢印が表示されている。これにより、他のユーザ（Ｃ．Ｃ）は、自分とは異なる一方のユーザ（Ａ．Ａ）から、自分とは異なる他方のユーザ（Ｂ．Ｂ）に対して送金リマインド情報が送信されたことを認識できる。

＜処理＞
図５－４～図５－５は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
これらのフローチャートは、図１－１３～図１－１４のフローチャートを、送金リクエスト情報、送金リマインド情報をトークルームに表示するように書き換えたフローチャートである。

通信Ｉ／Ｆ１４によって端末２０Ａから送金リクエスト送信要求情報を受信すると、サーバ１０の制御部１１は、送金リクエストメッセージを、ユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃとを少なくとも含むグループメンバーのグループトーク管理データ（グループトークルーム）に追加して更新する（Ｓ５１０）。

なお、この例では、３人のユーザを含むグループトークルームを例示するが、これに代えて、ユーザＡ．Ａと、ユーザＢ．Ｂとの２人を含むトークルームとしてもよいし、しなくてもよい。つまり、少なくとも送金の当事者（送金マスターユーザ、送金リクエスト先ユーザ）の２人が含まれるトークルームであればよい。

その後、サーバ１０の制御部１１は、追加した送金リクエストメッセージを、通信Ｉ／Ｆ１４によって端末２０Ａ、端末２０Ｂ、端末２０Ｃにそれぞれ送信する（Ｓ５２０）。
これを受けて、端末２０Ａ、端末２０Ｂ、端末２０Ｃは、それぞれの制御部２１によって、受信した送金リクエストメッセージを、グループトークルームにそれぞれ表示させる（Ａ５２０、Ｂ５２０、Ｃ５２０）。

端末２０Ｂの制御部２１は、グループトークルームに表示された送金リクエストメッセージに対する入力があったか否かを判定し（Ｂ５２５）、入力があったと判定したならば（Ｂ５２５：ＹＥＳ）、Ｂ１３０に処理を移す。

Ｓ１３０の後、サーバ１０の制御部１１は、送金メッセージまたは受金メッセージを、上記のグループトーク管理データに追加して更新する（Ｓ５４０）。

その後、サーバ１０の制御部１１は、追加した送金メッセージまたは受金メッセージを、通信Ｉ／Ｆ１４によって端末２０Ａ、端末２０Ｂ、端末２０Ｃにそれぞれ送信する（Ｓ５５０）。
これを受けて、端末２０Ａ、端末２０Ｂ、端末２０Ｃは、それぞれの制御部２１によって、受信した送金メッセージまたは受金メッセージを、グループトークルームにそれぞれ表示させる（Ａ５５０、Ｂ５５０、Ｃ５５０）。

Ｓ５５０の後、通信Ｉ／Ｆ１４によって端末２０Ａから送金リマインド送信要求情報を受信すると、サーバ１０の制御部１１は、送金リマインドメッセージを、上記のグループトーク管理データに追加して更新する（Ｓ５７０）。

その後、サーバ１０の制御部１１は、追加した送金リマインドメッセージを、通信Ｉ／Ｆ１４によって端末２０Ａ、端末２０Ｂ、端末２０Ｃにそれぞれ送信する（Ｓ５８０）。
これを受けて、端末２０Ａ、端末２０Ｂ、端末２０Ｃは、それぞれの制御部２１によって、受信した送金リマインドメッセージを、グループトークルームにそれぞれ表示させる（Ａ５８０、Ｂ５８０、Ｃ５８０）。

端末２０Ｂの制御部２１は、グループトークルームに表示された送金リマインドメッセージに対する入力があったか否かを判定し（Ｂ５９０）、入力があったと判定したならば、Ｂ１３０に処理を移す。

＜第５実施例の効果＞
本実施例は、送金リクエスト先ユーザの端末２０において、送金リクエストメッセージの表示（限定ではなく、第１情報に基づく第１表示の一例）と、送金リマインドメッセージの表示（限定ではなく、送金依頼に基づく、第１表示とは異なる第２表示の一例）とは、端末２０にインストールされたメッセージングアプリケーション（限定ではなく、アプリケーションの一例）によって、表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第１情報と第２情報とを、端末のユーザに認識させることができる。

また、本実施例は、送金リクエスト先ユーザの端末２０は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）と、送金マスターユーザ（限定ではなく、第１ユーザの一例）とを少なくとも含むグループトークルーム（限定ではなく、チャットルームの一例）を表示部２４に表示する。そして、送金リクエストメッセージの表示と、送金リマインドメッセージの表示とは、このグループトークルームに表示される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザと、第１ユーザとを少なくとも含むチャットルームへの表示によって、第１情報と第２情報とを、端末のユーザに効果的に認識させることができる。

＜第５変形例（１）＞
第５実施例では、グループに含まれる全てのグループユーザの端末２０に表示されるグループトークルームに、送金リクエストメッセージや送金リマインドメッセージが表示されることとしたが、これに限定されない。
一部のグループユーザの端末２０に表示されるグループトークルームに、送金リクエストメッセージや送金リマインドメッセージが表示されないようにすることも可能である。

＜表示画面＞
図５－６に示す例は、図５－２の変形例である。
第１ユーザ（Ａ．Ａ）の端末２０では、トークルーム上で自分（Ａ．Ａ）のメッセージＭＳ１１を見ることができる。
また、送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０では、トークルーム上で、第１ユーザ（Ａ．Ａ）のメッセージＭＳ２１を見ることができる。

一方で、第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象にもならなかった他のユーザ（Ｃ．Ｃ）の端末２０では、トークルーム上で、第１ユーザ（Ａ．Ａ）のメッセージＭＳ３１を見ることができない。

このように、限定ではなく例として、同じグループ（Ｘ）に属するユーザのうち、送金リマインドを行った第１ユーザ（Ａ．Ａ）ではなく、送金リマインドの対象となったユーザ（Ｂ．Ｂ）でもない他のユーザ（Ｃ．Ｃ）は、トークルーム上でその送金リマインドに関するメッセージを見ることができないようにしてもよい。

図５－７に示す例は、図５－２の変形例である。
送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０では、トークルーム上で、第１ユーザ（Ａ．Ａ）のメッセージＭＳ２１を見ることができる。

一方で、第１ユーザ（Ａ．Ａ）の端末２０では、トークルーム上で自分（Ａ．Ａ）のメッセージＭＳ１１を見ることができない。
また、第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象にもならなかった他のユーザ（Ｃ．Ｃ）の端末２０でも、トークルーム上で、第１ユーザ（Ａ．Ａ）のメッセージＭＳ３１を見ることができない。

このように、限定ではなく例として、同じグループ（Ｘ）に属するユーザのうち、送金リマインドの対象となったユーザ（Ｂ．Ｂ）以外のユーザに関しては、第１ユーザ（Ａ．Ａ）も含めて、その送金リマインドに関するメッセージを見ることができないようにしてもよい。

＜データ構成＞
図５－８は、本変形例における送金リクエストメッセージや送金リマインドメッセージの表示方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、設定Ｎｏと、表示フラグとが関連付けて定められている。

表示フラグは、そのユーザの端末２０の表示部２４に表示されるグループトークルームに、送金リクエストメッセージや送金リマインドメッセージを表示させるか否かを示すフラグである。

表示フラグには、限定ではなく例として、送金マスターユーザ（この例ではユーザＡ．Ａ）の表示フラグと、送金リクエスト先ユーザ（この例ではユーザＢ．Ｂ）の表示フラグと、他のグループユーザ（この例ではユーザＣ．Ｃ）の表示フラグとが含まれる。

具体的に説明する。
設定Ｎｏ「１」には、送金マスターユーザと、送金リクエスト先ユーザと、他のグループユーザとについて、全て表示フラグを「ＯＮ」とすることが定められている。
これは、送金依頼の当事者であるか否かに関係なく、同じグループに含まれる全てのユーザの端末２０に表示されるグループトークルームに、送金リクエストメッセージ・送金リマインドメッセージを表示させることを意味する。

設定Ｎｏ「２」には、送金マスターユーザと、送金リクエスト先ユーザとについては表示フラグを「ＯＮ」とし、他のグループユーザについては表示フラグを「ＯＦＦ」とすることが定められている。
これは、送金依頼の当事者である送金マスターユーザおよび送金リクエスト先ユーザの端末２０に表示されるグループトークルームには送金リクエストメッセージ・送金リマインドメッセージを表示させるが、当事者ではない他のグループユーザの端末２０に表示されるグループトークルームには送金リクエストメッセージ・送金リマインドメッセージを表示させないことを意味する。

設定Ｎｏ「３」には、送金マスターユーザと、送金リクエスト先ユーザとについては表示フラグを「ＯＮ」とし、他のグループユーザについては表示フラグを「ＯＦＦ」とすることが定められている。
これは、送金依頼の当事者である送金マスターユーザおよび送金リクエスト先ユーザの端末２０には送金リクエストメッセージ・送金リマインドメッセージを表示させるが、当事者ではない他のグループユーザの端末２０には、送金リクエストメッセージ・送金リマインドメッセージを表示させないことを意味する。

＜処理＞
図５－９～図５－１０は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図５－４～図５－５のフローチャートを、上記のテーブルに従って処理するように書き換えたフローチャートである。
ここでは、送金マスターユーザの端末２０に対する入力に基づいて、サーバ１０が表示フラグを設定する場合を例示する。

Ａ１２０において、端末２０Ａの制御部２１は、表示フラグの設定を要求するための情報を含む送金リクエスト送信要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。

サーバ１０の制御部１１は、端末２０Ａから受信した送金リクエスト送信要求情報に含まれる表示フラグの設定を要求するための情報に基づいて、表示フラグを設定する（Ｓ５０５）。

Ｓ５２０において、サーバ１０の制御部１１は、追加した送金リクエストメッセージを、通信Ｉ／Ｆ１４によって、表示フラグを「ＯＮ」に設定した端末２０に送信する。
これを受けて、表示フラグが「ＯＮ」に設定された端末２０は、受信した送金リクエストメッセージを、表示部２４のグループトークルームに表示させる。

同様に、Ｓ５５０において、サーバ１０の制御部１１は、追加した送金メッセージ／受金メッセージを、通信Ｉ／Ｆ１４によって、表示フラグを「ＯＮ」に設定した端末２０に送信する。
これを受けて、表示フラグが「ＯＮ」に設定された端末２０は、受信した送金メッセージ／受金メッセージを、表示部２４のグループトークルームに表示させる。

同様に、Ｓ５８０において、サーバ１０の制御部１１は、追加した送金リマインドメッセージを、通信Ｉ／Ｆ１４によって、表示フラグを「ＯＮ」に設定した端末２０に送信する。
これを受けて、表示フラグが「ＯＮ」に設定された端末２０は、受信した送金リマインドメッセージを、表示部２４のグループトークルームに表示させる。

なお、上記の処理では、送金マスターユーザの端末２０に対する入力に基づいて、サーバ１０が表示フラグを設定したが、これに限定されない。
これに代えて、送金リクエスト先ユーザの端末２０に対する入力に基づいて、サーバ１０が表示フラグを設定するようにしてもよいし、しなくてもよい。

また、上記の処理では、送金リクエストメッセージと、送金リマインドメッセージの両方について共通の表示フラグを設定することとしたが、これに限定されない。
これに代えて、送金リクエストメッセージと、送金リマインドメッセージとについて、個別に表示フラグを設定するようにしてもよいし、しなくてもよい。
この場合、あくまでも一例として、送金リクエストメッセージについては、設定Ｎｏ「１」の表示フラグの設定を適用し、送金リマインドメッセージについては、設定Ｎｏ「２」または設定Ｎｏ「３」の表示フラグの設定を適用するなどしてもよい。

本変形例は、上記のグループトークルームは、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）と、送金マスターユーザ（限定ではなく、第１ユーザの一例）と、他のグループユーザ（限定ではなく、第１ユーザとは異なる第２ユーザの一例）とを少なくとも含み、送金リマインドメッセージの表示は、他のグループユーザの端末２０に表示されるグループトークルームには表示されない構成を示している。
このような構成により得られる変形例の効果の一例として、送金依頼に関係ないユーザ、つまり、当事者ではないユーザに、送金依頼に基づく第２情報が知られないようにすることができる。

また、本変形例は、送金リマインドメッセージの表示は、送金マスターユーザの端末２０に表示されるグループトークルームに表示されない構成を示している。
第１ユーザは、送金依頼を行う側のユーザであり、少なくとも第１情報によって端末のユーザに送金依頼を行ったことを、自分で認識している。このため、送金依頼に基づく第２表示が、第１ユーザの端末に表示されるチャットルームに表示されないようにすることで、第１ユーザにとって必要のない情報が第１ユーザの端末に表示されることを防止することができる。

＜第５変形例（２）＞
第５実施例でグループトークルームに表示させる送金リマインド情報に基づくメッセージが、第１ユーザのメッセージとしてではなく、支払いアプリケーションの公式アカウントのメッセージとして表示されるようにしてもよいし、しなくてもよい。

図５－１１および図５－１２は、図５－２および図５－３の変形例である。
図５－２および図５－３の例では、第１ユーザ（Ａ．Ａ）から送金リマインドの対象となったユーザ（Ｂ．Ｂ）に対するメッセージＭＳ１１、ＭＳ２１、ＭＳ３１が、それぞれ第１ユーザ（Ａ．Ａ）のメッセージとして表示された。

限定ではなく例として、第１ユーザ（Ａ．Ａ）の端末２０では、メッセージＭＳ１１が自分のメッセージとして表示され、送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０では、メッセージＭＳ２１が第１ユーザ（Ａ．Ａ）のアイコン画像に関連付けて表示され、他のユーザ（Ｃ．Ｃ）の端末２０でも、メッセージＭＳ３１が第１ユーザ（Ａ．Ａ）のアイコン画像に関連付けて表示された。
すなわち、送金リマインド情報に基づくメッセージが、送金リマインド情報を送信するための操作を行った第１ユーザ（Ａ．Ａ）のメッセージとして表示された。

図５－１１および図５－１２では、限定ではなく例として、送金リマインド情報に基づくメッセージが、第１ユーザ（Ａ．Ａ）のメッセージとしてではなく、支払いアプリケーションの公式アカウントのメッセージとして表示される。

図５－１１に示すように、限定ではなく例として、Ａ．Ａ、Ｂ．Ｂ、およびＣ．Ｃの何れのユーザの端末２０においても、トークルーム上に、第１ユーザ（Ａ．Ａ）から他のユーザ（Ｂ．Ｂ）に対する送金リマインド情報に基づくメッセージが、支払いアプリケーションの公式アカウントのアイコン画像（本例では、「Ｐａｙ」の文字を含む画像）に関連付けて表示されている。

第１ユーザであるＡ．Ａの端末２０には、メッセージＭＳ１１ａが表示されており、送金リマインドの対象となったユーザであるＢ．Ｂの端末２０には、メッセージＭＳ２１ａが表示されており、その他のユーザであるＣ．Ｃの端末２０には、メッセージＭＳ３１ａが表示されている。
メッセージＭＳ１１ａ、ＭＳ２１ａ、およびＭＳ３１ａは、ボタンの表示態様を除いて同じ内容であり、何れも、支払いアプリケーションの公式アカウントのアイコン画像に関連付けられている。

限定ではなく例として、メッセージＭＳ１１ａ、ＭＳ２１ａ、およびＭＳ３１ａは、何れも「リマインド」の文字のアイコンを含んでおり、メッセージＭＳ１１に含まれていた「リマインド送信」の文字のアイコンや、メッセージＭＳ２１に含まれていた「リマインド受信」の文字のアイコンは含まれていない。

また、限定ではなく例として、メッセージＭＳ１１ａ、ＭＳ２１ａ、およびＭＳ３１ａは、何れも第１ユーザ（Ａ．Ａ）のアイコン画像および送金リマインドの対象となったユーザ（Ｂ．Ｂ）のアイコン画像とともに、前者のアイコン画像から後者のアイコン画像に向かう矢印を含んでいる。
メッセージＭＳ１１に含まれていた「受取」の文字のアイコンや、メッセージＭＳ２１に含まれていた「支払い」の文字のアイコンは含まれていない。

また、限定ではなく例として、メッセージＭＳ１１ａ、ＭＳ２１ａ、およびＭＳ３１ａに含まれる他の情報は、メッセージＭＳ１１、ＭＳ１２、およびＭＳ１３に含まれる他の情報とそれぞれ同様である。
限定ではなく例として、メッセージＭＳ１１ａには、選択不能態様の送金ボタンＢＴ１１ａおよびボタンＢＴ１１ｂが含まれる。また、メッセージＭＳ２１ａには、選択可能態様の送金ボタンＢＴ２１ａおよびボタンＢＴ２１ｂが含まれる。また、メッセージＭＳ３１ａには、選択不能態様の送金ボタンＢＴ３１ａおよびボタンＢＴ３１ｂが含まれる。

送金リマインドの対象となっているユーザ（Ｂ．Ｂ）が送金ボタンＢＴ２１ａをタップしたことに基づいて、第１ユーザ（Ａ．Ａ）への送金処理が完了すると、図５－１２に示すように、第１ユーザ（Ａ．Ａ）の端末２０には、送金を完了したユーザ（Ｂ．Ｂ）のメッセージとしてメッセージＭＳ１２が表示され、自分（Ａ．Ａ）のメッセージとしてメッセージＭＳ１３が表示される。

また、送金を完了したユーザ（Ｂ．Ｂ）の端末２０には、自分のメッセージとしてメッセージＭＳ２２が表示され、第１ユーザ（Ａ．Ａ）のメッセージとしてメッセージＭＳ２３が表示される。
また、他のユーザ（Ｃ．Ｃ）の端末２０には、送金を完了したユーザ（Ｂ．Ｂ）のメッセージとしてメッセージＭＳ３２が表示され、第１ユーザ（Ａ．Ａ）のメッセージとしてメッセージＭＳ３３が表示される。

メッセージＭＳ１２およびＭＳ１３、メッセージＭＳ２２およびＭＳ２３、ならびに、メッセージＭＳ３２およびＭＳ３３の内容は、図５－３に示した例と同様である。

限定ではなく、図５－１１および図５－１２に示した例によれば、第１ユーザ（Ａ．Ａ）からＢ．Ｂに対する送金依頼に基づく送金リマインド表示が、支払いアプリケーションの公式アカウントのメッセージとして表示されることにより、第１ユーザ（Ａ．Ａ）の操作に基づいて送金リマインド表示が表示されたという印象を和らげることができる。

一方で、送金処理の完了後は、送金を行ったことを通知するメッセージＭＳ１２、ＭＳ２２、ＭＳ２３を、送金依頼を受けたユーザ（Ｂ．Ｂ）のメッセージとして表示するとともに、送金依頼金額を受け取ったことを通知するメッセージＭＳ１３、ＭＳ２３、ＭＳ３３を、第１ユーザ（Ａ．Ａ）のメッセージとして表示することで、ユーザ間の関係を明確にしている。

図５－１３に示す例は、図５－１１の変形例である。
第１ユーザ（Ａ．Ａ）の端末２０では、トークルーム上で公式アカウントのメッセージＭＳ１１ａを見ることができる。
また、送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０では、トークルーム上で、公式アカウントのメッセージＭＳ２１ａを見ることができる。

一方で、第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象にもならなかった他のユーザ（Ｃ．Ｃ）の端末２０では、トークルーム上で、公式アカウントのメッセージＭＳ３１ａを見ることができない。

図５－１４に示す例は、図５－１１の変形例である。
送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０では、トークルーム上で公式アカウントのメッセージＭＳ２１ａを見ることができる。

一方で、第１ユーザ（Ａ．Ａ）の端末２０では、トークルーム上で公式アカウントのメッセージＭＳ１１ａを見ることができない。
また、第１ユーザ（Ａ．Ａ）でもなく、送金リマインドの対象にもならなかった他のユーザ（Ｃ．Ｃ）の端末２０でも、トークルーム上で公式アカウントのメッセージＭＳ３１ａを見ることができない。

＜第５変形例（３）＞
第５実施例でグループトークルームに表示させる送金リクエストメッセージと、送金リマインドメッセージとの少なくともいずれか一方を、メッセージングアプリケーションのメンション機能に基づくメッセージとしてもよいし、しなくてもよい。

図５－１５は、この場合におけるグループトークルームの一例を示す図である。
限定ではなく例として、トークルームに送金リマインド情報に基づくメッセージ（限定ではなく送金リマインド表示の一例）が表示される場合、自動的にメッセージングアプリケーションにおけるメンション機能が働き、「＠ユーザ名」という下線で強調される表記がなされる。

ここで、メンション機能とは、指定したユーザに対してメッセージ（コンテンツ）を送信するためのメッセージングアプリケーションの一機能である。
なお、メンション機能によってメッセージを受信するユーザの端末では、メッセージを受信したことを強調して示す通知が表示されるようにしてもよいし、そうしなくてもよい。

限定ではなく例として、「＠ユーザ名」の「ユーザ名」の部分には、第１ユーザ（Ａ．Ａ）が送金リマインド表示を表示させる端末２０のユーザとして指定したユーザ（限定ではなく例として、ドラッグ操作の対象となった送金依頼履歴に関連付けられたユーザ）のユーザ名が表示される。
このユーザ名は、限定ではなく例として、送金リマインド表示（限定ではなく例として、メッセージＭＳ１１ｂ、ＭＳ２１ｂ、ＭＳ３１ｂ）に含まれるユーザ名である。

図５－１５に示す例では、メンション機能によって指定されたユーザであるＢ．Ｂに対するメッセージとして、第１ユーザ（Ａ．Ａ）の端末２０には、メッセージＭＳ１１ｂが表示され、送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０には、メッセージＭＳ２１ｂが表示され、その他のユーザ（Ｃ．Ｃ）の端末２０には、メッセージＭＳ３１ｂが表示されている。
メッセージＭＳ１１ｂ、ＭＳ２１ｂ、およびＭＳ３１ｂの先頭には、それぞれ、メンション機能に基づいて、そのメッセージがＢ．Ｂに対してのメッセージであることを示す「＠Ｂ．Ｂ」という表記がなされている。

本変形例は、送金リマインドメッセージの表示は、少なくとも、メンション機能を利用して送金リクエスト先ユーザを指定する情報（限定ではなく、端末のユーザを示す情報の一例）を含む構成を示している。
このような構成により得られる変形例の効果の一例として、端末のユーザを示す情報を含む第２表示によって、その表示が自分を指定した表示であることを、端末のユーザに確実に認識させることができる。

＜第５変形例（４）＞
送金リクエスト先ユーザの端末２０の表示部２４に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様と、送金リクエスト先ユーザおよび送金マスターユーザを除く他のグループユーザの端末２０の表示部２４に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様とを、異ならせて表示させるようにしてもよい。

この場合、表示画面で示した例のように、メッセージに含まれるテキストの一部の内容を異ならせたり、メッセージに含まれるボタンの表示態様（選択可能態様／選択不能態様）を異ならせるばかりでなく、限定ではなく例として、当事者の端末２０には詳細な内容のメッセージを表示させる一方、当事者以外の端末２０には内容を簡易化したメッセージを表示させるなどしてもよい。異なる色でメッセージを表示させるなどしてもよい。

本変形例は、送金リマインドメッセージの表示は、送金リクエスト先ユーザの端末２０（限定ではなく、端末の一例）に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様（限定ではなく、第１表示態様の一例）と、送金リクエスト先ユーザおよび送金マスターユーザを除く他のグループユーザの端末２０（限定ではなく、第２ユーザの端末の一例）に表示されるグループトークルームに表示される送金リマインドメッセージの表示態様（限定ではなく、第２表示態様の一例）とで表示態様が異なる構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示態様と第２表示態様との表示態様の相違によって、端末のユーザに対しては自分が送金依頼の当事者であることを、第２ユーザに対しては自分が送金依頼の当事者ではないことを、それぞれ認識させることができる。

＜第５変形例（５）＞
送金リクエスト先ユーザが支払いを行わなかった場合に、メッセージングアプリケーションの機能の一部を制限するようにしてもよいし、しなくてもよい。

図５－１６の例では、支払いアプリケーションの公式アカウントのメッセージとして、第１ユーザ（Ａ．Ａ）の端末２０には、メッセージＭＳ１４が表示され、送金リマインドの対象となったユーザ（Ｂ．Ｂ）の端末２０には、メッセージＭＳ２４が表示され、その他のユーザ（Ｃ．Ｃ）の端末２０には、メッセージＭＳ３４が表示されている。
メッセージＭＳ１４、ＭＳ２４、およびＭＳ３４の先頭には、それぞれ、メンション機能に基づいて、そのメッセージがＢ．Ｂ（本例では、送金リマインドの対象となっているユーザ）に対してのメッセージであることを示す「＠Ｂ．Ｂ」という表記がなされている。

メッセージＭＳ１４、ＭＳ２４、およびＭＳ３４には、限定ではなく例として、それぞれ、［ＰａｙｍｅｎｔＡｐｐ］の文字と、メッセージングアプリケーションにおいて使用制限される機能および使用制限の条件を示す情報（本例では、「２４時間以内に送金がない場合、ＭｅｓｓａｇｉｎｇＡｐｐ内のスタンプ機能に制限がかかります。」という文字、および「期限内の送金を御願いします。」という文字）と、送金先となる第１ユーザのユーザ名（本例ではＡ．Ａ）と、送金依頼金額（本例では「３，０００円」）と、送金期限（本例では２０２０－０４－２４１７：００）が表示され、下部に送金ボタンが表示されている。

メッセージＭＳ１４の送金ボタンＢＴ１４と、メッセージＭＳ３４の送金ボタンＢＴ３４は、何れも非選択態様で表示され、メッセージＭＳ２４の送金ボタンＢＴ２４は、選択態様で表示されている。

＜第５変形例（６）＞
送金が完了していないユーザの端末２０に表示させるリマインド表示に、既に送金が完了しているユーザに関する情報を含めるようにしてもよいし、しなくてもよい。

図５－１７に示す例では、図５－１に示した例と同様に、Ａ．Ａの端末２０の表示部２４に、グループＸのトークルームにおいて、友だち間で相互にやり取りされたメッセージが表示されている。

この例は、一方の端末２０のユーザであるＣ．Ｃからは送金した旨の返答があったものの、他方の端末２０のユーザであるＢ．Ｂからは返答がない状態を示している。
限定ではなく例として、第１ユーザであるＡ．Ａが、ボタンＢＴＭ３をタップすると、Ａ．Ａの過去の送金依頼のうち、複数のユーザ（Ｂ．ＢおよびＣ．Ｃ）を対象としたものであって、少なくとも１のユーザに関して支払い処理が完了していないものに関する履歴が、トークルーム上に表示される。

本例では、第１ユーザ（Ａ．Ａ）が、複数のユーザ（Ｂ．ＢおよびＣ．Ｃ）に、共通のイベント（本例では会費が３，０００円のイベント）に関する送金リクエスト情報を送信している。そして、一方のユーザ（Ｂ．Ｂ）に対する送金依頼に関する送金処理が未完了であり、他方のユーザ（Ｃ．Ｃ）に対する送金依頼に関する送金処理は完了していることに基づいて、両方のユーザに関する情報が領域Ｒ１０に表示されている。

限定ではなく例として、領域Ｒ１０には、送金リクエスト情報の送信日時、「リクエスト送信」の文字のアイコン、複数のユーザ（Ａ．Ａ、Ｂ．Ｂ）各々から支払いを受ける立場であることを示す「受取」の文字のアイコンと、複数のユーザ（Ａ．Ａ、Ｂ．Ｂ）各々から受け取るべき金額（３，０００円）と、が表示されている。
その下方には、送金依頼の対象となったユーザの数を示す情報（本例では「メンバー２」）が表示され、さらに、送金を未だ行っていない一方のユーザ（Ｂ．Ｂ）に関する情報と、既に送金を行った他方のユーザ（Ｃ．Ｃ）に関する情報の両方が表示されている。

限定ではなく例として、第１ユーザ（Ａ．Ａ）が、一方のユーザ（Ｂ．Ｂ）に送金リクエスト情報を送信したものの、この送金依頼に対しての送金処理が未完了であることに基づいて、一方のユーザ（Ｂ．Ｂ）のアイコン画像およびユーザ名に関連付けて、送金依頼金額（本例では３，０００円）が表示されている。
また、限定ではなく例として、第１ユーザ（Ａ．Ａ）が、他方のユーザ（Ｃ．Ｃ）に送金リクエスト情報を送信し、この送金依頼に対しての送金処理が完了していることに基づいて、他方のユーザ（Ｃ．Ｃ）のアイコン画像およびユーザ名に関連付けて、送金が完了していることを示す情報（本例では、「送金済」の文字）が表示されている。

また、一方のユーザ（Ｂ．Ｂ）に関する情報の背景は白であり、他方のユーザ（Ｃ．Ｃ）に関する情報の背景は黒であり、前者の情報と後者の情報とで表示態様が異なり、区別しやすくなっている。
第１ユーザ（Ａ．Ａ）が、領域Ｒ１０のチェックボックスをチェックした状態とすることで、領域Ｒ１０内に表示されている各情報が選択された状態となる。
この状態で領域ＲＲがタップされることで、領域Ｒ１０内に表示されていた情報に基づく送金リマインド情報が、送金を行っていないユーザ（Ｂ．Ｂ）の端末２０に送信される。

図５－１８に示す例は、送金リマインド情報に基づく送金リマインド表示に、既に支払いを行った他方のユーザ（Ｃ．Ｃ）に関する情報も含まれる点で、図５－２に示した例とは異なっている。

第１ユーザ（Ａ．Ａ）の端末２０にはメッセージＭＳ１１ｃが表示され、一方のユーザ（Ｂ．Ｂ）の端末２０にはメッセージＭＳ２１ｃが表示され、他方のユーザ（Ｃ．Ｃ）の端末２０にはメッセージＭＳ３１ｃが表示されている。
メッセージＭＳ１１ｃ、ＭＳ２１ｃ、ＭＳ３１ｃの何れに関しても、共通のイベントに基づく送金依頼の対象となったユーザの数を示す情報（本例では「メンバー２」）が表示され、さらに、送金を未だ行っていない一方のユーザ（Ｂ．Ｂ）に関する情報と、既に送金を行った他方のユーザ（Ｃ．Ｃ）に関する情報の両方が表示されている。

限定ではなく例として、あるイベントに関して送金を未だ行っていない一方のユーザ（Ｂ．Ｂ）の端末２０に表示される送金リマインド表示に、同じイベントに関して既に送金を行った他方のユーザ（Ｃ．Ｃ）に関する情報を含めることにより、一方のユーザ（Ｂ．Ｂ）に対して送金を促すことができる。

図５－１９および図５－２０は、図５－１７および図５－１８の変形例である。
図５－１９および図５－２０に関しては、限定ではなく例として、送金リクエスト情報の送信対象となった複数のユーザ（Ｂ．Ｂ、Ｃ．Ｃ）に関して、それぞれ、送金リマインドの対象となった回数（限定ではなく例として、そのユーザを対象とした送金リマインド表示がそのユーザの端末２０に表示された回数）が示される点で、図５－１７及び図５－１８とは異なる。

図５－１９および図５－２０の例では、あるイベントの送金依頼に対する送金を行っていない一方のユーザ（Ｂ．Ｂ）のアイコン画像およびユーザ名に関連付けて、送金リマインドの対象となった回数（限定ではなく例として、Ｂ．Ｂを対象とした送金リマインド表示がＢ．Ｂの端末２０に表示された回数であり、本例では１０回）を示すアイコンＲＩＣ１が表示されており、同じイベントの送金依頼に対する送金を既に行った他方のユーザ（Ｃ．Ｃ）のアイコン画像およびユーザ名に関連付けて、送金リマインドの対象となった回数（限定ではなく例として、Ｃ．Ｃを対象とした送金リマインド表示がＣ．Ｃの端末２０に表示された回数であり、本例では０回）を示すアイコンＲＩＣ２が示されている。

限定ではなく例として、このような表示によって、各ユーザは、自分の他のユーザとのリマインド回数の比較、他のユーザ間のリマインド回数の比較を行うようになるため、できる限り送金リマインドの対象とならないように各ユーザに意識させることができる。

次に、送金リクエスト先ユーザへの送金リマインドを行わないようにする実施例について説明する。送金リマインドを行わないようにすることを「送金リマインドを停止する」と表現する場合がある。
この送金リマインドの停止を実現するための手法としては、大きく分けて、
・サーバ１０が送金リマインド情報の送信を停止する
・端末２０が送金リマインド表示の表示を停止する
の２つの手法が考えられる。以下、それぞれの手法について説明する。

＜第６実施例＞
第６実施例は、サーバ１０が、送金リクエスト先ユーザの端末２０への送金リマインド情報の送信を停止する実施例である。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

サーバ１０が送金リクエストを管理する手法として、限定ではなく例として、前述した２つのパターン（パターンＡ、パターンＢ）が考えられる。
「パターンＡ」を適用する場合、サーバ１０は、送金済みとなった送金リクエストを削除せずに残し、送金リクエスト先ユーザの端末２０への、その送金リクエストに対応する送金リマインド情報の送信を停止する。
「パターンＢ」を適用する場合、サーバ１０は、送金済みとなった送金リクエストを削除する。送金リクエストそのものが削除されるため、結果的に、送金リマインド情報の送信が停止される。

＜処理＞
図６－１～図６－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、限定ではなく例として、図１－１３から図２－１１に続くサーバリマインドの処理に基づくフローチャートである。

送金リマインドを行うと判定したならば（Ｓ２６０：ＹＥＳ）、サーバ１０の制御部１１は、その送金リマインドに対応する送金リクエストについて、リマインドが停止されているか否かを判定する（Ｓ２６７）。具体的には、限定ではなく例として、第２送金リクエスト管理データ１５７Ｂを参照し、対応する送金リクエスト管理ＩＤに対応する送金済みフラグが「ＯＮ」に設定されている場合に、リマインドが停止されていると判定する。

リマインドが停止されていないと判定したならば（Ｓ２６７：ＮＯ）、サーバ１０の制御部１１は、Ｓ２７０に処理を移す。
この場合は、サーバ１０から端末２０Ｂに対して送金リマインド情報が送信されるように制御される。

一方、リマインドが停止されていると判定したならば（Ｓ２６７：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１９０に処理を移す。
この場合は、サーバ１０から端末２０Ｂに対して送金リマインド情報が送信されないように制御される。

なお、上記の処理では、送金リマインド情報が、サーバ１０から端末２０Ｂに対して２回以上送信される場合がある。この場合、上記の処理において、端末２０Ｂの表示部２４に表示されたいずれかの送金リマインド表示に対する入力に基づいてサーバ１０によって送金決済処理が実行されると、それ以降、サーバ１０から端末２０に対して送金リマインド情報が送信されないように制御されることになる。

＜第６実施例の効果＞
本実施例は、サーバ１０が、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金リクエスト情報（限定ではなく、決済依頼に関する第１情報の一例）を通信Ｉ／Ｆ１４によって送金マスターユーザの端末２０から受信する。そして、サーバ１０は、送金リクエストに基づく第２送金処理（限定ではなく、第１ユーザへの送金に関する送金処理の一例）の実行に基づいて、送金リクエストに基づく送金リマインド情報（限定ではなく、送金依頼に基づく第２情報の一例）を送金リクエスト先ユーザの端末２０に送信する制御に関する送信制御を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく、第１ユーザへの送金に関する送金処理の実行に基づいて、送金依頼に基づく第２情報を端末に送信する制御に関する送信制御を行うことで、第１ユーザへの送金を端末のユーザに適切に行わせることができる。

また、本実施例は、送金リクエスト情報は、送金リクエスト金額の情報を含み、送金リマインド情報は、同様の金額の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく金額を、第１情報と第２情報とによって端末のユーザに確実に知らせることができる。

また、本実施例は、サーバ１０が、第２送金処理が実行されない場合、送金リマインド情報を送金リクエスト先ユーザの端末２０に通信Ｉ／Ｆ１４によって送信する制御を行い、第２送金処理が実行された場合、送金リマインド情報を送金リクエスト先ユーザの端末２０に通信Ｉ／Ｆ１４によって送信しない制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金処理が実行されない場合は、第２情報が端末に送信されるようにする一方、送金処理が実行された場合は、第２情報が端末に送信されないようにすることができる。

また、本実施例は、第２送金処理は、送金リクエスト表示（限定ではなく、第１情報に基づく第１表示の一例）が送金リクエスト先ユーザの端末２０に表示され、その端末２０のユーザによる送金リクエスト表示に対する入力に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報に基づく第１表示が端末に表示され、端末のユーザによる第１表示に対する入力に基づいて、送金処理が簡単に実行されるようにすることができる。また、この場合、上記の構成と相まって、第１表示に対する入力に基づいて送金処理が実行されたことに基づいて、サーバが、第２情報を端末に送信しないように制御することができる。

また、本実施例は、サーバ１０が、送金リクエストに基づく送金リマインド情報（限定ではなく、送金依頼に基づく第３情報の一例）を、通信Ｉ／Ｆ１４によって送金リクエスト先ユーザの端末２０に送信する。そして、第２送金処理は、送金リマインド表示（限定ではなく、第３情報に基づく第３表示の一例）が送金リクエスト先ユーザの端末２０に表示され、送金リクエスト先ユーザによる送金リマインド表示に対する入力に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第３情報に基づく第３表示に対する入力に基づいて、送金処理を実行することができる。また、この場合、上記の構成と相まって、第３表示に対する入力に基づいて送金処理が実行された場合は、第２情報が端末に送信されないようにすることができる。

また、本実施例は、サーバ１０が実行する送信制御は、第１送金リマインド情報（限定ではなく、第２情報の一例）がサーバ１０の通信Ｉ／Ｆ１４によって送金リクエスト先ユーザの端末２０に送信された場合、第２送金リマインド情報（限定ではなく、送金依頼に基づく第４情報の一例）を送金リクエスト先ユーザの端末２０に送信する制御を含み、第２送金処理は、第１送金リマインド表示（限定ではなく、第２情報に基づく第２表示の一例）が送金リクエスト先ユーザの端末２０に表示され、送金リクエスト先ユーザによる第１送金リマインド表示に対する入力に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第２情報がサーバから端末に送信された場合であっても、この第２情報とは別に、送金依頼に基づく第４情報がサーバから端末に送信されるようにすることができる。また、送金依頼に基づく第４情報がサーバから端末に送信された場合であっても、端末のユーザによる、端末に表示された第２情報に基づく第２表示に対する入力に基づいて、第１ユーザへの送金を端末のユーザに行わせることができる。

また、本実施例は、第２送金処理（限定ではなく、送金処理の一例）は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）から送金マスターユーザ（限定ではなく、第１ユーザの一例）への送金に関する処理である構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、送金処理によって、端末のユーザから第１ユーザへの送金を実現することができる。

＜第６変形例（１）＞
第６実施例において、パターンＢ（送金リクエストを削除する）を適用するようにすることもできる。
この場合、サーバ１０は、限定ではなく例として、送金決済処理によって送金を行った場合に、第２送金リクエスト管理データ１５７Ｂのうち、送金を行った送金リクエスト管理ＩＤに対応するレコードを削除する。その結果、送金リクエストのみならず、この送金リクエストに対応する送金リマインドも削除される。

＜第６変形例（２）＞
パターンＡ（送金リクエストを削除せずに残す）を適用する場合、サーバ１０で記憶・管理している送金リクエストは削除されない。このため、端末２０からサーバ１０に対して送金リクエストの閲覧要求がなされた場合、送金済みの送金リクエストに関する情報も、端末２０で閲覧可能となる。
そこで、送金済みの送金リクエストに関する情報については、未送金の送金リクエストに関する情報とは異なる表示態様に変更するようにしてもよいし、しなくてもよい。

限定ではなく例として、サーバ１０の制御部１１は、端末２０からの要求に基づいて、送金リクエスト一覧情報のページ（送金リクエスト一覧ページ）を端末２０に送信する。
この場合、サーバ１０の制御部１１は、第２送金リクエスト管理データ１５７Ｂにおいて、対応する送金リクエスト管理ＩＤに関連付けられて設定されている送金済みフラグに基づいて、端末２０Ｂに送信する送金リクエスト一覧ページを設定して送信する。

具体的には、限定ではなく例として、送金済みフラグが「ＯＦＦ」である送金リクエスト情報および送金リマインド情報については、デフォルトの表示とする一方、送金済みフラグが「ＯＮ」である送金リクエスト情報および送金リマインド情報については、その表示を送金済みであることを示す表示態様（限定ではなく例として、グレーアウト表示や送金済みマークを付した表示）に変更した送金リクエスト一覧ページを設定して送信する。

図６－３は、本実施例において端末２０Ｂの表示部２４に表示される送金リクエスト一覧画面の一例を示す図であり、図２－１３に対応する画面を示している。
この例では、領域Ｒ２１に示される送金リクエスト情報と、この送金リクエストに対応して領域Ｒ２２に示される送金リマインド情報とのそれぞれについて、送金済みであることを示す情報として、「ＤＯＮＥ」の文字を含む完了マークＭＫ１が表示されている。

なお、送金済みであることを示す表示は、これに限定されるわけでではない。
限定ではなく例として、図６－３のレイアウトの送金リクエスト一覧画面において、図６－４に示すように、領域Ｒ２１と領域Ｒ２２とをグレーアウト表示することによって、未送金の状態の送金リクエストや送金リマインドと区別するようにしてもよい。

また、図６－３のレイアウトとは異なる送金リクエスト一覧画面、限定ではなく例として、図２－１７に示したような受信日時に基づいて表示される送金リクエスト一覧画面において、限定ではなく例として図６－５に示すように領域Ｒ２１と領域Ｒ２３とに完了マークＭＫ１を表示するなどしてもよい。
また、これらの領域をグレーアウト表示するなどしてもよい。

＜第６変形例（３）＞
前述したように、端末２０が送金リマインド表示の表示を停止することによって、送金リマインドを停止することも可能である。
ここでは、端末リマインドの手法を適用する場合を例示する。

図６－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、限定ではなく例として、図１－１３～図１－１４の端末リマインドの処理に基づくフローチャートである。

送金リマインドを行うと判定したならば（Ｂ１４５：ＹＥＳ）、端末２０Ｂの制御部２１は、受信済みの送金リクエストに基づく送金を実行済みであるか否かを判定する（Ｂ４５５）。

送金を未実行であると判定したならば（Ｂ４５５：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ１５０に処理を移す。
この場合は、端末２０Ｂの制御部２１によって、送金リマインド表示を表示部２４に表示する制御が実行される。

一方、送金を実行済みであると判定したならば（Ｂ４５５：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ１９０に処理を移す。
この場合は、端末２０Ｂの制御部２１によって、送金リマインド表示を表示部２４に表示しない制御が実行される。

なお、上記の処理では、送金リマインド表示が、端末２０Ｂの表示部２４に２回以上表示される場合がある。
この場合、上記の処理において、端末２０の表示部２４に表示されたいずれかの送金リマインド表示に対する入力に基づいて送金が実行されると、それ以降、送金リマインド情報は、端末２０Ｂの表示部２４に表示されないように制御されることになる。

本変形例は、送金リクエスト先ユーザの端末２０が、送金マスターユーザ（限定ではなく、第１ユーザの一例）による送金リクエスト情報（限定ではなく、送金依頼に関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、送金リクエスト先ユーザの端末２０は、送金リクエスト表示（限定ではなく、第１情報に基づく第１表示の一例）を表示部２４に表示する。そして、送金リクエスト先ユーザの端末２０は、送金リクエストに基づく第１送金処理（限定ではなく、第１ユーザへの送金に関する送金処理の一例）の実行に基づいて、送金リクエストに基づく送金リマインド表示（限定ではなく、送金依頼に基づく第２表示の一例）を表示部２４に表示する制御に関する表示制御を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく、第１ユーザへの送金に関する送金処理の実行に基づいて、送金依頼に基づく第２表示を端末の表示部に表示する制御に関する表示制御を実行することで、第１ユーザへの送金を端末のユーザに適切に行わせることができる。

また、本変形例は、上記の表示制御は、第１送金処理が実行されない場合、送金リマインド表示を表示部２４に表示する制御を行い、第１送金処理が実行されない場合、送金リマインド表示を表示部２４に表示しない制御を行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金処理が実行されたか否かに基づいて、第２情報を表示させるか否かを適切に切り替えることができる。

また、本変形例は、第１送金処理は、送金リクエスト情報（限定ではなく、第１情報の一例）に基づく表示（限定ではなく、第１表示の一例）が送金リクエスト先ユーザの端末２０に表示され、送金リクエスト先ユーザによる、その表示に対する入力（限定ではなく、端末のユーザによる第１表示に対する入力の一例）に基づいて実行される構成を示している。
このような構成により得られる変形例の効果の一例として、第１情報に基づく第１表示が端末に表示され、端末のユーザによる第１表示に対する入力に基づいて、送金処理が簡単に実行されるようにすることができる。また、この場合、上記の構成と相まって、第１表示に対する入力に基づいて送金処理が実行されたことに基づいて、端末が、第２表示を表示部に表示しないように制御することができる。

＜第６変形例（４）＞
第６変形例（３）に関連するが、サーバリマインドの手法について、端末２０が送金リマインド表示の表示を停止することによって、送金リマインドを停止することも可能である。つまり、サーバ１０は送金リマインド情報の送信を停止しないが、端末２０が送金リマインド表示の表示を停止するようにすることも可能である。

図６－７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ｂ２４０においてサーバ１０から送金リマインド情報を受信したと判定したならば（Ｂ２４０：ＹＥＳ）、端末２０Ｂの制御部２１は、対応する送金リクエストに基づく送金を実行済みであるか否かを判定する（Ｂ４５５）。

送金を未実行であると判定したならば（Ｂ４５５：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ２５０に処理を移す。
この場合は、送金リマインド情報がサーバ１０から送信され、端末２０Ｂの制御部２１によって、その送金リマインド情報に基づく送金リマインド表示を表示部２４に表示する制御が実行される。

一方、送金を実行済みであると判定したならば（Ｂ４５５：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ１９０に処理を移す。
この場合は、送金リマインド情報がサーバ１０から送信されるが、端末２０Ｂの制御部２１によって、その送金リマインド情報に基づく送金リマインド表示を表示部２４に表示しないように制御される。

＜第６変形例（５）＞
さらに、送金リクエスト先ユーザの端末２０からの要求に基づいて、サーバ１０が送金リマインド情報の送信を停止するようにすることも可能である。
具体的には、限定ではなく例として、図６－８に示すように、送金リクエスト先ユーザであるユーザＢ．Ｂの端末２０Ｂの表示部２４に送金リクエスト一覧が表示された状態で、限定ではなく例として、ユーザＡ．Ａからの送金リマインドをタップすると、図６－９に示すような送金画面が表示される。

この送金画面の下部には、送金リマインドの内容を確認したことをサーバ１０に通知するため確認情報表示領域ＷＲ１が構成されている。この例では、確認情報表示領域ＷＲ１には、「［リマインド］Ａ．Ａさんから送金リクエスト」のテキストとともに、「確認しました」の文字を含むリンクが表示されている。そして、このリンクをタップすることで、送金リマインドの内容を確認したことを示す送金リマインド確認情報が、端末２０Ｂからサーバ１０に対して送信される。
サーバ１０は、端末２０Ｂから送金リマインド確認情報を受信したことに基づいて、送金リマインド情報の送信を停止する。

＜第７実施例＞
第７実施例は、第６実施例において、送金リクエスト表示や送金リマインド表示をチャットルームに表示する実施例である。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

＜処理＞
図７－１～図７－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
なお、ここでは簡明化のため、追加されたメッセージが端末２０Ｂで表示されるトークルームに表示される場合に着目した処理として図示・説明し、端末２０Ａでのトークルームの表示については省略する。

通信Ｉ／Ｆ１４によって端末２０Ａから送金リクエスト送信要求情報を受信すると、サーバ１０の制御部１１は、送金リクエストメッセージを、ユーザＡ．ＡとユーザＢ．Ｂとのトーク管理データ（トークルーム）に追加して更新する（Ｓ６１０）。
そして、サーバ１０の制御部１１は、追加した送金リクエストメッセージを、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ６２０）。

端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金リクエストメッセージを受信したか否かを判定し（Ｂ６１０）、受信したと判定したならば（Ｂ６１０：ＹＥＳ）、リクエスト通知処理を実行する（Ｂ６２０）。
このリクエスト通知処理は、限定ではなく例として、前述したリマインド通知処理と同様の手法によって実現することができる。

その後、端末２０Ｂの制御部２１は、入力部に対してトークルームを表示するための入力がなされたか否かに基づいて、トークルームを表示部２４に表示させるか否かを判定する（Ｂ６３０）。そして、表示させると判定したならば（Ｂ６３０：ＹＥＳ）、記憶部２８に記憶されている最新のトークデータに基づいて、トークルームを表示部２４に表示させる（Ｂ６４０）。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから送金リマインド送信要求情報を受信したか否かを判定し（Ｓ６５０）、受信したと判定したならば（Ｓ６５０：ＹＥＳ）、設定されている送金済みフラグに基づいて、リマインドが停止されているか否かを判定する（Ｓ６６０）。

送金済みフラグが「ＯＦＦ」であり、リマインドが停止されていないと判定したならば（Ｓ６６０：ＮＯ）、サーバ１０の制御部１１は、送金リマインドメッセージを、ユーザＡ．ＡとユーザＢ．Ｂとのトーク管理データ（トークルーム）に追加して更新する（Ｓ６７０）。
そして、サーバ１０の制御部１１は、追加した送金リマインドメッセージを、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ６８０）。

その後、サーバ１０の制御部１１は、処理を終了するか否かを判定し（Ｓ６９０）、処理を継続すると判定したならば（Ｓ６９０：ＮＯ）、Ｓ６５０に処理を戻す。一方、処理を終了すると判定したならば（Ｓ６９０：ＹＥＳ）、処理を終了する。

端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金リマインドメッセージを受信したか否かを判定し（Ｂ６５０）、受信したと判定したならば（Ｂ６５０：ＹＥＳ）、リマインド通知処理を実行する（Ｂ６６０）。
このリマインド通知処理は、限定ではなく例として、前述した手法を適用することができる。

その後、端末２０Ｂの制御部２１は、入力部に対してトークルームを表示するための入力がなされたか否かに基づいて、トークルームを表示部２４に表示させるか否かを判定する（Ｂ６７０）。そして、表示させると判定したならば（Ｂ６７０：ＹＥＳ）、記憶部２８に記憶されている最新のトークデータに基づいて、トークルームを表示部２４に表示させる（Ｂ６８０）。

その後、端末２０Ｂの制御部２１は、処理を終了するか否かを判定し（Ｂ６９０）、処理を継続すると判定したならば（Ｂ６９０：ＮＯ）、Ｂ６５０に処理を戻す。一方、処理を終了すると判定したならば（Ｂ６９０：ＹＥＳ）、処理を終了する。

＜第７実施例の効果＞
本実施例は、端末２０における送金リクエスト表示（限定ではなく、第１情報に基づく第１表示の一例）は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）と送金マスターユーザ（限定ではなく、第１ユーザの一例）とを少なくとも含むトークルーム（限定ではなく、チャットルームの一例）に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、チャットルームへの表示によって、少なくとも端末のユーザと第１ユーザとに、第１情報を簡易かつ適切に知らせることができる。

＜第７変形例＞
第６変形例（１）と同様に、前述したパターンＡを適用する場合に、送金済みの送金リクエストに関する情報については、未送金の送金リクエストに関する情報とは異なる表示態様に変更するようにしてもよいし、しなくてもよい。

メッセージングアプリケーションによっては、サーバ１０と端末２０とで、トーク情報を各々が独立して保存するものがある。
限定ではなく例として、サーバ１０で保存されるメッセージは、メッセージを端末２０に送信してから一定時間（限定ではなく例として、数週間）が経過すると自動的に削除されるが、端末２０で保存されるメッセージは、ユーザが削除しない限り、そのまま残るようなものである。

この場合、端末２０では、基本的にメッセージの履歴が削除されずに残るため、端末２０のユーザは、過去の送金リクエストメッセージや送金リマインドメッセージも、端末２０に保存されたデータに基づいて閲覧可能となる。
そこで、本変形例では、以下の手法によって、送金リクエストに関連する情報の表示態様を変更する。

図７－３は、この手法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、送金済みフラグと、情報種別と、メッセージとが関連付けて定められている。

送金済みフラグには、「ＯＦＦ」と「ＯＮ」とが含まれる。

情報種別は、そのメッセージの種別であり、限定ではなく例として、送金済みフラグ「ＯＦＦ」と「ＯＮ」とのそれぞれについて、「リクエスト」と「リマインド」とが定められている。

メッセージには、対応する送金済みフラグ「ＯＮ」／「ＯＦＦ」に応じて、端末２０のトークルームに表示するメッセージの種別が定められている。

具体的に説明する。
（１）送金済みフラグ「ＯＦＦ」
情報種別「リクエスト」には、メッセージとして「第１種送金リクエストメッセージ（未送金）」が定められている。これは、送金済みフラグが「ＯＦＦ」である場合、つまり、未送金の状態である場合は、トークルームに表示する送金リクエストメッセージを、第１種送金リクエストメッセージとすることを示している。

情報種別「リマインド」には、メッセージとして「第１種送金リマインドメッセージ（未送金）」が定められている。これは、送金済みフラグが「ＯＦＦ」である場合、つまり、未送金の状態である場合は、トークルームに表示する送金リマインドメッセージを、第１種送金リマインドメッセージとすることを示している。

（２）送金済みフラグ「ＯＮ」
情報種別「リクエスト」には、メッセージとして「第２種送金リクエストメッセージ（送金済み）」が定められている。これは、送金済みフラグが「ＯＮ」である場合、つまり、送金済みの状態である場合は、トークルームに表示する送金リクエストメッセージを、第２種送金リクエストメッセージとすることを示している。

情報種別「リマインド」には、メッセージとして「第２種送金リマインドメッセージ（送金済み）」が定められている。これは、送金済みフラグが「ＯＮ」である場合、つまり、送金済みの状態である場合は、トークルームに表示する送金リマインドメッセージを、第２種送金リマインドメッセージとすることを示している。

つまり、未送金の状態では、送金リクエストメッセージや送金リマインドメッセージを第１表示態様（限定ではなく例として、デフォルトの表示態様）で表示するが、送金が完了した後は、これらのメッセージの表示態様を、第１表示態様から第２表示態様（限定ではなく例として、送金済みであることを示す表示態様）に変更して表示する。

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

通信Ｉ／Ｆ１４によって端末２０Ａから送金リクエスト送信要求情報を受信すると、サーバ１０の制御部１１は、送金リクエストメッセージとして、第１種送金リクエストメッセージを、ユーザＡ．ＡとユーザＢ．Ｂとのトーク管理データ（トークルーム）に追加して更新する（Ｓ７１０）。

その後、サーバ１０の制御部１１は、送金リクエストメッセージとして、第１種送金リクエストメッセージと、第２種送金リクエストメッセージとを、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ７２０）。

Ｂ６２０の後、端末２０Ｂの制御部２１は、受信した送金リクエストメッセージ（第１種、第２種）を記憶部２８に記憶させる（Ｂ７２５）。

その後、端末２０Ｂの制御部２１は、入力部に対してトークルームを表示するための入力がなされたか否かに基づいて、トークルームを表示部２４に表示させるか否かを判定する（Ｂ７３０）。そして、表示させると判定したならば（Ｂ７３０：ＹＥＳ）、最新のトークデータに基づいて、トークルームを表示部２４に表示させる（Ｂ７４０）。
具体的には、送金リクエストメッセージとして、第１種送金リクエストメッセージをトークルームに表示させる。

Ｓ６６０においてリマインドが停止されていないと判定したならば（Ｓ６６０：ＮＯ）、サーバ１０の制御部１１は、送金リマインドメッセージとして、第１種送金リマインドメッセージを、ユーザＡ．ＡとユーザＢ．Ｂとのトーク管理データ（トークルーム）に追加して更新する（Ｓ７７０）。

その後、サーバ１０の制御部１１は、送金リマインドメッセージとして、第１種送金リマインドメッセージと、第２種送金リマインドメッセージとを、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ７８０）。

Ｂ６６０の後、端末２０Ｂの制御部２１は、受信した送金リマインドメッセージ（第１種、第２種）を記憶部２８に記憶させる（Ｂ７６５）。

その後、端末２０Ｂの制御部２１は、入力部に対してトークルームを表示するための入力がなされたか否かに基づいて、トークルームを表示部２４に表示させるか否かを判定する（Ｂ７７０）。そして、表示させると判定したならば（Ｂ７７０：ＹＥＳ）、最新のトークデータに基づいて、トークルームを表示部２４に表示させる（Ｂ７８０）。

具体的には、限定ではなく例として、トークルーム内のメッセージのうち、サーバ１０から送金情報を未受信の状態である場合は、対応する送金リクエストメッセージ・送金リマインドメッセージとして、第１種送金リクエストメッセージ・第１種送金リマインドメッセージを表示する。
一方、サーバ１０から送金情報を受信済みの状態である場合は、対応する送金リクエストメッセージ・送金リマインドメッセージとして、第２種送金リクエストメッセージ・第２種送金リマインドメッセージを表示する。

＜第８実施例＞
第８実施例は、送金リクエストや送金リマインドを経由せずに送金が実行された場合に関する実施例である。

送金リクエスト先ユーザが、送金リクエスト表示や送金リマインド表示を確認した上で、またはこれらを確認することなく、支払いアプリケーションにおける独立した送金機能を利用して、送金マスターユーザに対して送金を行うケースも想定される。
このようなケースでは、サーバ１０は、いずれの送金リクエスト管理ＩＤについて送金リマインドを停止すべきかを判定（特定）することができない。

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

図８－１は、サーバ１０の記憶部１５に記憶される、前述した送金リクエスト管理データ１５７の別例である第３送金リクエスト管理データ１５７Ｃの構成例を示す図である。
第３送金リクエスト管理データ１５７Ｃには、第２送金リクエスト管理データ１５７Ｂにおける、日時と、送金リクエスト管理ＩＤと、送金マスターＩＤと、送金リクエスト先ＩＤと、送金リクエスト金額と、送金済みフラグと、情報種別とに加えて、限定ではなく例として、リマインド停止フラグが関連付けて記憶される。

リマインド停止フラグは、対応する送金リクエスト管理ＩＤについて、送金リクエスト先ユーザの端末２０への送金リマインド情報の送信を停止するか否かを識別するためのフラグであり、送金リマインド情報の送信を停止するものについては「ＯＮ」が設定される。

前述した実施例と異なるのは、送金済みフラグが「ＯＦＦ」であっても、リマインド停止フラグが「ＯＮ」に設定される場合がある点である。

図８－２は、本実施例において、サーバ１０が送金リクエスト管理ＩＤを特定する方法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、設定Ｎｏと、対象端末と、判定用情報と、判定結果とが関連付けて定められている。

対象端末には、サーバ１０が、いずれの端末２０で選択・入力された情報に基づいて、停止する送金リマインドを判定するか定められている。

判定用情報には、サーバ１０が、停止する送金リマインドを判定するための情報が定められている。

判定結果には、サーバ１０が、停止する送金リマインドとして判定する結果が定められている。

具体的に説明する。
設定Ｎｏ「Ｓ１」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「選択された送金マスターユーザ」が、判定結果として「選択された送金マスターユーザからの送金リマインド」がそれぞれ定められている。
これは、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金用画面）において、限定ではなく例として、送金リクエストを受けているユーザ（送金マスターユーザ）の一覧を表示させるなどして、いずれかの送金マスターユーザを選択させる。そして、送金マスターユーザが選択されたことに基づいて、選択された送金マスターユーザからの送金リマインドが停止されることを示している。

この設定を適用する場合、サーバ１０は、送金リクエスト先ユーザからの送金を、選択された送金マスターユーザからその送金リクエスト先ユーザへの送金リクエストに基づく送金とみなして送金を実行する。そして、サーバ１０は、その送金マスターユーザからその送金リクエスト先ユーザへの送金リマインドを停止する。
具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、選択された送金マスターユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理ＩＤに対応するリマインド停止フラグを「ＯＮ」に設定する。
ただし、この設定では、送金リクエストを一意に特定することはできないため、送金済みフラグは「ＯＦＦ」のままとされるようにすることができる。

設定Ｎｏ「Ｓ２」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「選択された送金先ユーザ＆送金リマインドの停止選択有無」が、判定結果として「選択された送金先ユーザからの送金リマインド」がそれぞれ定められている。
これは、限定ではなく例として、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金用画面）において、送金リクエスト先ユーザによって送金先のユーザ（以下、「送金先ユーザ」と称する。）が選択され、その送金先ユーザからの送金リマインドを停止させることが選択されたことに基づいて、選択された送金先ユーザからの送金リマインドが停止されることを示している。

この設定を適用する場合、サーバ１０は、選択された送金先ユーザから送金リクエスト先ユーザに対する送金リクエストが存在するか否かを判定する。そして、存在すると判定したならば、送金リクエスト先ユーザからの送金を、選択された送金先ユーザから、その送金リクエスト先ユーザへの送金リクエストに基づく送金とみなして送金を実行する。そして、サーバ１０は、送金リマインドを停止させることが選択された場合、その送金先ユーザからその送金リクエスト先ユーザへの送金リマインドを停止する。
具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、選択された送金先ユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理ＩＤに対応するリマインド停止フラグを「ＯＮ」に設定する。
ただし、この設定でも、送金リクエストを一意に特定することはできないため、送金済みフラグは「ＯＦＦ」のままとされるようにすることができる。

なお、送金リマインドを停止させることが選択されなかった場合、サーバ１０は、送金リマインドを停止しない。以下同様である。

設定Ｎｏ「Ｓ３」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「選択された送金先ユーザ＆入力された送金金額」が、判定結果として「選択された送金先ユーザからの送金リマインド＆入力された送金金額と送金リクエスト金額が同じ送金リマインド」がそれぞれ定められている。
これは、限定ではなく例として、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金用画面）において、送金リクエスト先ユーザによって送金先ユーザが選択され、その送金先ユーザに対する送金金額が入力されたことに基づいて、選択された送金先ユーザからの送金リマインドであって、入力された送金金額と送金リクエスト金額が同じ送金リマインドが停止されることを示している。

この設定を適用する場合、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、選択された送金先ユーザから送金リクエスト先ユーザに対する送金リクエスト管理ＩＤの中から、送金リクエスト金額が、送金リクエスト先ユーザの端末２０で入力された送金金額と同じである送金リクエスト管理ＩＤを特定する。
そして、サーバ１０は、送金リクエスト先ユーザからの送金を、特定した送金リクエスト管理ＩＤの送金リクエストに基づく送金とみなして送金を実行する。そして、サーバ１０は、その送金リクエスト管理ＩＤの送金リクエストを対象として、送金リマインドを停止する。具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、特定した送金リクエスト管理ＩＤに対応する送金済みフラグを「ＯＮ」に設定するとともに、リマインド停止フラグも「ＯＮ」に設定する。

なお、入力された送金金額と送金リクエスト金額が同じ送金リマインドを停止するのに代えて、またはこれに加えて、入力された送金金額と送金リクエスト金額が近い送金リマインド（限定ではなく例として、金額の差が「３００円以下」である送金リマインド）を停止するようにしてもよいし、しなくてもよい。

設定Ｎｏ「Ｓ４」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「グループ内の選択された送金リクエスト」が、判定結果として「グループ内の選択された送金リクエストに対応する送金リマインド」がそれぞれ定められている。
これは、限定ではなく例として、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、グループリクエスト一覧画面）において、送金リクエスト先ユーザによって、自分に対する送金リクエストに加えて、他のグループユーザへの送金リクエストが一緒に選択されると、それらの送金リクエストに対応する送金リマインドが停止されることを示している。

この設定を適用する場合、サーバ１０は、送金リクエスト先ユーザからの送金を、グループ内の選択された送金リクエストに基づく送金とみなして送金を実行する。そして、サーバ１０は、その送金リクエスト先ユーザへの送金リクエストに対応する送金リマインドと、選択された他のグループユーザへの送金リクエストに対応する送金リマインドとを停止する。
具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、これらの送金リクエストの送金リクエスト管理ＩＤに対応する送金済みフラグを「ＯＮ」に設定するとともに、リマインド停止フラグも「ＯＮ」に設定する。

この設定では、限定ではなく例として、グループに含まれる一の送金リクエスト先ユーザが、自分が送金すべき金額に加えて、同じグループに含まれる他のグループユーザが送金すべき金額も併せて送金することによって、自分に対する送金リマインドと、同じグループに含まれる他のグループユーザに対する送金リマインドとを停止させることができる。

なお、上記の各々の設定において、送金リマインドを停止させるか否かの選択（送金リマインドの停止選択有無）を必須の要素とし、送金リマインドを停止させることが選択された場合に、送金リマインドを停止するようにしてもよいし、しなくてもよい。

＜表示画面＞
以下、一例として、上記の設定Ｎｏ「Ｓ２」の設定と設定Ｎｏ「Ｓ４」の設定とをそれぞれ適用した場合の表示画面例について説明する。

図８－３～図８－７には、設定Ｎｏ「Ｓ２」の設定を適用する場合の画面図の遷移の一例を示している。
図８－３は、端末２０Ｂの表示部２４に表示される支払いアプリケーションのメインメニュー画面であり、図２－２に対応する画面である。そして、ここでは「送金」のアイコンＩＣ３がタップされた状態が示されている。この場合、限定ではなく例として、図８－４に示す送金先ユーザ選択画面が表示される。

この送金先ユーザ選択画面は、送金先ユーザを選択する画面であり、限定ではなく例として、支払いアプリケーションＩＤから送金先ユーザの候補を検索する欄と、電話番号から送金先ユーザの候補を検索する欄とが設けられている。そして、この例では、支払いアプリケーションＩＤから送金先ユーザの候補を検索する欄が選択され、その検索結果として、「Ａ．Ａ」、「Ｃ．Ｃ」、「Ｄ．Ｄ」、「Ｅ．Ｅ」といった複数のユーザが表示された状態が示されている。そして、この例では、「Ａ．Ａ」の横のチェックボックスがチェックされることで、ユーザＡ．Ａが送金先ユーザとして選択された状態が示されている。

この状態で画面下部の選択領域ＲＭ３がタップされ、不図示の金額入力画面において送金予定金額が入力された後、限定ではなく例として、図８－５に示す画面が表示される。
この画面では、送金予定金額として「３，０００円」が入力されており、この状態で画面下部の送金領域ＲＭ２がタップされることで、図８－６に示すように、送金リマインド停止情報として、限定ではなく例として、ユーザＡ．Ａのアイコン画像およびユーザ名と、「このユーザからのリマインドを停止しますか？」というテキストと、ＯＫボタンＢＴ１０と、キャンセルボタンとを含む送金リマインド停止情報ＲＳ１が、画面中央部にポップアップ表示される。

この状態で送金リマインド停止情報ＲＳ１に含まれるＯＫボタンＢＴ１０がタップされると、送金先ユーザ選択情報（ユーザＡ．Ａが選択されたことを示す情報）と、送金リマインド停止要求情報とが、端末２０Ｂからサーバ１０に対して送信される。そして、サーバ１０によって送金が実行されるとともに、送金リマインドがされる。そして、限定ではなく例として、図８－７に示すように、送金が完了した旨と、送金リマインドが停止された旨とを含む送金完了通知が、画面中央部にポップアップ表示される。

図８－８は、本実施例において端末２０Ｂの表示部２４に表示される支払いアプリケーションのメインメニュー画面の一例を示す図である。
このメインメニュー画面は、図２－２に対応しており、ここでは「送金」のアイコンＩＣ３がタップされた状態が示されている。この場合、限定ではなく例として、図８－４に示す送金先ユーザ選択画面が表示される。

図８－８～図８－９には、設定Ｎｏ「Ｓ４」の設定を適用する場合の画面図の遷移の一例を示している。図８－８には、ユーザＣ．Ｃの端末２０Ｃの表示部２４に表示されるグループトークルームの一例を示している。
グループトークルームの下部に表示されたアイコンのうち、右下の送金アイコンＩＣ４がタップされると、前述したように、トークルーム上に送金項目選択領域ＳＭＲが表示される。

この送金項目選択領域ＳＭＲには、他のユーザに送金するためのボタンＢＴＭ１と、他のユーザに送金リクエスト情報を送信するためのボタンＢＴＭ２と、送金リクエスト一覧を表示するためのボタンＢＴＭ３とに加えて、グループリクエスト一覧を表示するためのボタンＢＴＭ４が表示されている。

ボタンＢＴＭ４がタップされると、限定ではなく例として、グループリクエストの一覧が画面内に表示される。この例では、グループリクエストとして、送金リクエスト金額を「３，０００円」とするユーザＡ．ＡからユーザＢ．Ｂへの送金リクエスト（ユーザＢ．ＢからユーザＡ．Ａへの送金）と、送金リクエスト金額を「３，０００円」とするユーザＡ．ＡからユーザＣ．Ｃへの送金リクエスト（ユーザＣ．ＣからユーザＡ．Ａへの送金）との２名分の送金リクエストが表示されている。

上記の２名分の送金リクエストの各々に関連付けられたチェックボックスがチェックされ、画面下部の送金領域ＲＭ２がタップされることで、送金リクエスト選択情報が、端末２０Ｃからサーバ１０に対して送信される。そして、サーバ１０によって、上記の２名分の送金リクエストに基づく送金が実行されるとともに、それぞれに対応する送金リマインドが停止される。

図８－９には、送金マスターユーザであるユーザＡ．Ａの端末２０Ａと、送金リクエスト先ユーザであるユーザＢ．Ｂの端末２０Ｂと、同じく送金リクエスト先ユーザであるユーザＣ．Ｃの端末２０Ｃとのそれぞれの表示部２４に表示されるグループトークルームを示している。
端末２０Ａに表示されるグループトークルームには、ユーザＣ．ＣからユーザＡ．Ａに対して２名分の送金があったことを示すメッセージＭＳ７１が表示され、その下に、その金額をユーザＡ．Ａが受け取ったことを示すメッセージＭ７２が表示されている。

端末２０Ｂに表示されるグループトークルームには、メッセージＭＳ７１に対応して、ユーザＣ．ＣからユーザＡ．Ａに対して２名分の送金があったことを示すメッセージＭＳ８１と、メッセージＭＳ７２に対応して、その金額をユーザＡ．Ａが受け取ったことを示すメッセージＭＳ８２とに加えて、ユーザＡ．ＡからユーザＢ．Ｂへの送金リマインドが停止されたことを示すメッセージＭ８３が表示されている。

また、端末２０Ｃに表示されるグループトークルームには、メッセージＭＳ７１に対応して、ユーザＣ．ＣからユーザＡ．Ａに対して２名分の送金を行ったことを示すメッセージＭＳ９１と、メッセージＭＳ７２に対応して、その金額をユーザＡ．Ａが受け取ったことを示すメッセージＭＳ９２とが表示されている。

この場合、ユーザＡ．ＡからユーザＢ．Ｂへの送金リマインドに加えて、ユーザＡ．ＡからユーザＣ．Ｃへの送金リマインドも停止される。しかし、自分に対する送金リマインドが停止されるのを承知の上で、ユーザＣ．Ｃは、ユーザＢ．Ｂの分も含めて支払いを行うと考えられるため、この例では、端末２０Ｃに表示されるグループトークルームには、ユーザＡ．ＡからユーザＣ．Ｃへの送金リマインドが停止されたことを示すメッセージは表示しないようにしている。

なお、これとは異なり、端末２０Ｃに表示されるグループトークルームに、ユーザＡ．ＡからユーザＣ．Ｃへの送金リマインドが停止されたことを示すメッセージを表示させるようにしてもよい。

＜処理＞
図８－１０は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
ここでは、端末２０Ｂの処理を左側に、サーバ１０の処理を右側にそれぞれ示し、端末２０Ａの処理については図示を省略する。
これらの処理は、限定ではなく例として、図６－１～図６－２の処理のサブルーチンの処理として、端末２０Ｂの制御部２１およびサーバ１０の制御部１１によってそれぞれ実行される処理である。

端末２０Ｂの制御部２１は、送金を実行するか否かを判定する（Ｂ８１０）。具体的には、限定ではなく例として、入力部に対して、前述した送金用画面や前述したグループリクエスト一覧画面等から、送金を実行するための入力がなされたか否かを判定する。

送金を実行すると判定したならば（Ｂ８１０：ＹＥＳ）、端末２０Ｂの制御部２１は、前述した判定用情報を含む送金決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ８３０）。

サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂから送金決済要求情報を受信したか否かを判定し（Ｓ８１０）、受信したと判定したならば（Ｓ８１０：ＹＥＳ）、受信した送金決済要求情報に判定用情報が含まれるか否かを判定する（Ｓ８２０）。

受信した送金決済要求情報に判定用情報が含まれると判定したならば（Ｓ８２０：ＹＥＳ）、サーバ１０の制御部１１は、送金リマインド停止判定処理を実行する（Ｓ８３０）。
具体的には、限定ではなく例として、図８－２のテーブルで説明した手法に従って、送金リマインドを停止する送金リクエスト管理ＩＤを判定（特定）する。

その後、サーバ１０の制御部１１は、送金決済処理を実行する（Ｓ１３０）。具体的には、限定ではなく例として、判定した送金リクエスト管理ＩＤが関連付けられた送金リクエストを対象として送金を行う。そして、前述した手法でフラグ（送金済みフラグ、リマインド停止フラグ）を設定する。

Ｂ１４０の後、端末２０Ｂの制御部２１は、処理を終了するか否かを判定し（Ｂ８９０）、処理を継続すると判定したならば（Ｂ８９０：ＮＯ）、Ｂ８１０に処理を戻す。
一方、処理を終了すると判定したならば（Ｂ８９０：ＹＥＳ）、端末２０Ｂの制御部２１は、処理を終了する。

同様に、Ｓ１５０の後、サーバ１０の制御部１１は、処理を終了するか否かを判定し（Ｓ８９０）、処理を継続すると判定したならば（Ｓ８９０：ＮＯ）、Ｓ８１０に処理を戻す。
一方、処理を終了すると判定したならば（Ｓ８９０：ＹＥＳ）、サーバ１０の制御部１１は、処理を終了する。

また、本処理では、図６－２のＳ２６７において、サーバ１０の制御部１１は、送信の要求を受けた送金リマインド情報に対応する送金リクエスト管理ＩＤについてリマインドが停止されているか否かを判定する。具体的には、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃを参照し、その送金リクエスト管理ＩＤに対応するリクエスト停止フラグが「ＯＮ」に設定されている場合に、リマインドが停止されていると判定する。

＜第８実施例の効果＞
本実施例は、サーバ１０によって実行される第２送金処理（限定ではなく、送金処理の一例）は、送金リクエスト先ユーザの端末２０の表示部２４に表示された送金マスターユーザ（限定ではなく、第１ユーザの一例）の選択に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末の表示部に表示された第１ユーザが選択されることに基づいて、その第１ユーザからの送金依頼に基づく送金とみなして、送金処理が実行されるようにすることができる。

また、本実施例は、第２送金処理は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）による、送金マスターユーザ（限定ではなく、第１ユーザの一例）の選択と、送金リマインド停止（限定ではなく、第２情報の送信を行わないことを示す情報）の選択とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザにより、第１ユーザの選択と、第２情報の送信を行わないことを示す情報の選択とに基づいて、送金処理が適切に実行されるようにすることができる。

また、本実施例は、第２送金処理は、送金マスターユーザ（限定ではなく、第１ユーザの一例）と、送金リクエスト金額（限定ではなく、送金依頼に基づく金額の一例）と、送金予定金額（限定ではなく、端末のユーザによって入力された金額の一例）とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの選択と、送金依頼に基づく金額と、端末のユーザによって入力された金額とに基づいて、送金処理が適切に実行されるようにすることができる。

また、本実施例は、上記において、第２送金処理は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）とは異なるグループユーザ（限定ではなく、第２ユーザの一例）による送金マスターユーザ（限定ではなく、第１ユーザの一例）への送金に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼された端末のユーザとは異なる第２ユーザによる第１ユーザへの送金に基づいて、送金処理が適切に実行されるようにすることができる。

また、この場合、送金リクエスト情報は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）と、送金マスターユーザ（限定ではなく、第１ユーザの一例）と、他のグループユーザ（限定ではなく、第２ユーザの一例）とを少なくとも含むグループに対して送信され、第２送金処理は、他のグループユーザによる、そのグループユーザの端末２０に表示された送金リクエスト情報に基づく送金リクエスト表示に対する入力に基づいて実行されるようにすることもできる。
このような構成により得られる実施例の効果の一例として、第２ユーザによる、第２ユーザの端末に表示された第１情報に基づく第１表示に対する入力に基づいて、送金処理が簡易かつ適切に実行されるようにすることができる。

また、本実施例は、送金マスターユーザのアイコン画像やユーザ名等の情報（限定ではなく、第１ユーザ情報の一例）が端末２０の表示部２４に表示され、第１送金処理は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）による、表示部２４に表示された第１ユーザ情報に対する入力に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる、表示部に表示された第１ユーザ情報に対する入力という、ユーザにとって分かり易い表示に対する入力に基づいて、送金処理が実行されるようにすることができる。

また、本実施例は、端末２０が、端末２０に対する入力に基づいて、送金先ユーザの選択情報（限定ではなく、第１ユーザが選択されたことを示す情報）と、送金予定金額の情報（限定ではなく、第１ユーザに送金する金額情報の一例）とを取得する。そして、第１送金処理は、送金リクエスト金額（送金依頼金額）の情報と、送金予定金額の情報とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、送金依頼に基づく金額と、ユーザに送金する金額とが同じ金額であるような場合に、そのユーザからの送金依頼に基づく送金とみなして、送金が行われるようにすることができる。

また、本実施例は、第１送金処理は、送金リクエスト先ユーザによる、端末２０に対する送金マスターユーザを選択するための入力や、送金リマインドを停止させるための入力（限定ではなく、送金依頼に基づく第１ユーザへの送金であることを示す入力の一例）に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼に基づく第１ユーザへの送金であることを示す入力に基づいて、送金処理が簡易かつ適切に実行されるようにすることができる。

＜第８変形例＞
第８実施例では、サーバ１０が、送金リマインド情報の送信を停止するか否かを、送金リクエスト管理データ１５７のリマインド停止フラグによって管理することとしたが、これに限定されない。
限定ではなく例として、送金リクエスト管理データとは異なるデータによって、送金リマインド情報の送信を停止するか否かを管理するようにしてもよいし、しなくてもよい。

図８－１１は、本変形例においてサーバ１０の記憶部１５に記憶されるリマインド停止管理データの一例を示す図である。
リマインド停止管理データには、限定ではなく例として、縦に送金リマインド情報を受信する側（受信側）のユーザのアプリケーションＩＤが、横に送金リマインド情報を送信する側（送信側）のユーザのアプリケーションＩＤがそれぞれ記憶され、送信側から受信側への送金リマインド情報の送信の有無（送信有／送信無）が、マトリックス形式で記憶されている。

デフォルトでは、送信側と受信側とが交差する全ての欄について「送信有」が記憶されているが、図８－１０の送金リマインド停止判定処理（Ｓ８３０）において、送金リマインド情報の送信を停止すると判定されたものについては、送信側と受信側とが交差する欄が「送信無」に更新される。
限定ではなく例として、送金マスターユーザをユーザＡ．Ａとし、送金リクエスト先ユーザをユーザＢ．Ｂとし、ユーザＡ．ＡからユーザＢ．Ｂへの送金リマインドを停止すると判定された場合は、送信側「Ｕ００１（ユーザＡ．Ａ）」と、受信側「Ｕ００２（ユーザＢ．Ｂ）」とが交差する欄が「送信無」に更新される。

＜第９実施例＞
第９実施例は、上記の実施例とは異なる例外的なケースによって、送金リマインドを停止する実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。

送金リマインドを停止する必要が生ずるケースとして、以下のようなケースが考えられる。
（Ａ）送金リクエストに基づく送金は未だ行われていないが、送金リマインドを停止することが希望されるケース
（Ｂ）支払いアプリケーションを利用せずに送金リクエストに対応する金額が支払われるなどして、送金リマインドを停止することが希望されるケース

（Ａ）は、限定ではなく例として、未送金の状態であるが、繰り返し送金リマインドが行われることを防止するため、主に当事者のユーザ（ただし、当事者以外のユーザの場合もあり得る。）によって送金リマインドを停止することが希望されるケースである。
また、送金マスターユーザが送金リクエストを放棄するようなケースも考えられる。

（Ｂ）は、限定ではなく例として、現金の手渡し、金融機関（銀行等）の口座振替などで金銭が支払われたようなケースである。この場合も、主に当事者のユーザによって送金リマインドを停止することが希望されると考えられる。

図９－１は、本実施例における送金リマインド情報の送信を停止する手法を説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、設定Ｎｏと、対象端末と、判定用情報と、判定結果と、送金マスターユーザの承認要否とが関連付けて定められている。

対象端末、判定用情報、判定結果の意味合いは、図８－２のテーブルと同様である。

送金マスターユーザの承認要否には、送金リマインドを停止するにあたり、送金マスターユーザによる承認が必要であるか否かを識別するための情報（承認要／承認不要）が定められている。

具体的に説明する。
設定Ｎｏ「Ｔ１」には、対象端末として「送金マスターユーザの端末」が、判定用情報として「選択された送金リクエスト先ユーザ＆送金リマインドの停止選択有無」が、判定結果として「選択された送金リクエスト先ユーザへの送金リマインド」が、送金マスターユーザの承認要否として「否」がそれぞれ定められている。
これは、限定ではなく例として、送金マスターユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金リクエスト先ユーザ一覧画面）において、送金マスターユーザによって送金リクエスト先ユーザが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエスト先ユーザへの送金リマインドが停止されることを示している。
また、送金マスターユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「否」が定められている。

この設定を適用する場合、サーバ１０は、その送金マスターユーザから、選択された送金リクエスト先ユーザへの全ての送金リマインドを停止する。
具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、その送金マスターユーザから、選択された送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理ＩＤに対応するリマインド停止フラグを「ＯＮ」に設定する。

設定Ｎｏ「Ｔ２」には、対象端末として「送金マスターユーザの端末」が、判定用情報として「選択された送金リクエスト＆送金リマインドの停止選択有無」が、判定結果として「選択された送金リクエストに対応する送金リマインド」が、送金マスターユーザの承認要否として「否」がそれぞれ定められている。
これは、限定ではなく例として、送金マスターユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金リクエスト一覧画面）において、送金マスターユーザによって送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエストに対応する送金リマインドが停止されることを示している。
また、送金マスターユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「否」が定められている。

この設定を適用する場合、サーバ１０は、選択された送金リクエストに対応する送金リマインドを停止する。具体的には、サーバ１０は、限定ではなく例として、第３送金リクエスト管理データ１５７Ｃにおいて、選択された送金リクエストの送金リクエスト管理ＩＤに対応するリマインド停止フラグを「ＯＮ」に設定する。

ただし、この設定では、送金リクエスト管理ＩＤを一意に特定することはできるが、その送金リクエストに基づく送金が実行済みであるか否かを特定することはできない。このため、送金済みフラグは「ＯＦＦ」のままとされる。
そこで、送金済みである場合は、送金マスターユーザの端末２０からサーバ１０に対して送金済み情報を送信することによって、サーバ１０によって送金済みフラグが「ＯＮ」に設定されるようにしてもよい。

設定Ｎｏ「Ｔ３」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「送金マスターユーザ＆送金リマインド停止選択有無」が、判定結果として「選択された送金マスターユーザからの送金リマインド」が、送金マスターユーザの承認要否として「要」がそれぞれ定められている。
これは、限定ではなく例として、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金マスターユーザ一覧画面）において、送金リクエスト先ユーザによって送金マスターユーザが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金マスターユーザからの送金リマインドが停止されることを示している。
また、送金リクエスト先ユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。

この設定を適用する場合、サーバ１０は、選択された送金マスターユーザの端末２０に対して、送金リマインドの停止を承認するか否かを確認する処理（以下、「承認確認処理」と称する。）を実行する。具体的には、サーバ１０は、送金リマインドの停止を承認するか否かを確認するための情報（以下、「承認確認情報」と称す。）を、選択された送金マスターユーザの端末２０に送信する。
送金マスターユーザの端末２０から承認することを示す情報（以下、「承認情報」と称する。）を受信すると、サーバ１０は、その送金マスターユーザから、送金リクエスト先ユーザへの送金リマインドを停止する。具体的には、第３送金リクエスト管理データ１５７Ｃにおいて、受信したアプリケーションＩＤによって識別される送金マスターユーザから、その送金リクエスト先ユーザへの全ての送金リクエストの送金リクエスト管理ＩＤに対応するリマインド停止フラグを「ＯＮ」に設定する。
一方、上記の送金マスターユーザの端末２０から承認情報を受信しなかった場合、サーバ１０は、送金リマインドを停止しない。つまり、リマインド停止フラグを「ＯＦＦ」のままとする。

設定Ｎｏ「Ｔ４」には、対象端末として「送金リクエスト先ユーザの端末」が、判定用情報として「選択された送金リクエスト＆送金リマインド停止選択有無」が、判定結果として「選択された送金リクエストに対応する送金リマインド」が、送金マスターユーザの承認要否として「要」がそれぞれ定められている。
これは、限定ではなく例として、送金リクエスト先ユーザの端末２０の表示部２４に表示される画面（限定ではなく例として、送金リクエスト一覧画面）において、送金リクエスト先ユーザによって送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された送金リクエストに対応する送金リマインドが停止されることを示している。
また、送金リクエスト先ユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。

この設定を適用する場合、サーバ１０は、選択された送金リクエストに対応する送金リマインドを停止する。具体的には、サーバ１０は、第３送金リクエスト管理データ１５７Ｃにおいて、選択された送金リクエストに対応する送金リクエスト管理ＩＤのリマインド停止フラグを「ＯＮ」に設定する。

ただし、この設定では、送金リクエスト管理ＩＤを一意に特定することはできるが、その送金リクエストに基づく送金が実行済みであるか否かを特定することはできない。このため、送金済みフラグは「ＯＦＦ」のままとされる。
そこで、送金済みである場合は、送金リクエスト先ユーザの端末２０からサーバ１０に対して送金済み情報を送信することによって、サーバ１０によって送金済みフラグが「ＯＮ」に設定されるようにしてもよい。

設定Ｎｏ「Ｔ５」には、対象端末として「当事者以外のユーザの端末」が、判定用情報として「選択された当事者の送金リクエスト＆送金リマインドの停止選択有無」が、判定結果として「選択された当事者の送金リクエストに対応する送金リマインド」が、送金マスターユーザの承認要否として「要」がそれぞれ定められている。
これは、限定ではなく例として、送金の当事者以外のユーザ（限定ではなく例として、同じグループに含まれる送金マスターユーザおよび送金リクエスト先ユーザ以外のユーザ）の端末２０の表示部２４に表示される画面（限定ではなく例として、グループリクエスト一覧画面）において、そのユーザによって、当事者の送金リクエストが選択され、送金リマインドを停止させることが選択されたことに基づいて、選択された当事者の送金リクエストに対応する送金リマインドが停止されることを示している。

これは、限定ではなく例として、グループに含まれる一のユーザが、同じグループに含まれる他のグループユーザ（送金リクエスト先ユーザ）に対する送金マスターユーザからの送金リクエストに対応する送金リマインドを停止させることを求めるような場合である。当事者以外のユーザが証人となって、当事者の送金リマインドを停止させる手法とも言える。
当事者以外のユーザの希望で送金リマインドを停止するため、送金マスターユーザの承認要否には「要」が定められている。

この設定を適用する場合、サーバ１０は、選択された当事者の送金リクエストに対応する送金リマインドを停止する。具体的には、サーバ１０は、第３送金リクエスト管理データ１５７Ｃにおいて、選択された当事者の送金リクエストに対応する送金リクエスト管理ＩＤのリマインド停止フラグを「ＯＮ」に設定する。

なお、送金マスターユーザの承認が「要」である設定では、サーバ１０は、限定ではなく例として、数時間に１回など、定期的なタイミングで承認確認処理を行うようにすることができる。これは、送金マスターユーザによる否認漏れを防止するためである。

また、１回目の承認確認処理を実行してから設定期間（限定ではなく例として、数日間）が経過しても送金マスターユーザの端末２０から承認情報を受信しない場合、サーバ１０は、送金マスターユーザによって承認されたとみなして、送金リマインドを停止するようにすることもできる。
逆に、１回目の承認確認処理を実行してから設定期間が経過しても送金マスターユーザの端末２０から承認情報を受信しない場合、サーバ１０は、送金マスターユーザによって否認されたとみなして、送金リマインドを停止しないようにすることもできる。

＜表示画面＞
一例として、上記の設定Ｎｏ「Ｔ２」の設定と、設定Ｎｏ「Ｔ４」の設定とをそれぞれ適用した場合の表示画面例について説明する。

図９－２は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。
この例では、送金マスターユーザをユーザＡ．Ａとし、送金リクエスト先ユーザをユーザＢ．Ｂとして、ユーザＡ．Ａが、ユーザＢ．Ｂに対して送った送金リクエストに対応する送金リマインドを停止する場合を説明する。

この送金リクエスト一覧画面には、ユーザＡ．ＡがユーザＢ．Ｂに対して送った送金リクエストに関する情報と、この送金リクエストに対応する送金リマインドに関する情報とが表示されている。

送金リクエストに関する情報の表示領域において、ユーザＢ．Ｂのアイコン画像およびユーザ名の横には、送金リマインドを停止させるための、限定ではなく例として、スピーカの画像を含むリマインド停止アイコンＩＣ１０が表示されている。
リマインド停止アイコンＩＣ１０は、限定ではなく例として、デフォルトの状態（送金リマインドを停止しない状態）ではスピーカの画像部分が白抜きされた黒色で表示されている。

リマインド停止アイコンＩＣ１０がタップされると、限定ではなく例として、図９－３に示すように、この送金リクエストに対応する送金リマインドを停止させるための第１送金リマインド停止情報が、画面中央にポップアップ表示される。
そして、第１リマインド停止確認情報に含まれるＯＫボタンＢＴ１０がタップされると、送金リクエスト選択情報と、第１送金リマインド停止要求情報とが端末２０Ａからサーバ１０に対して送信されて、選択された送金リクエストに対応する送金リマインドが停止される。

すると、限定ではなく例として、ユーザＡ．ＡからユーザＢ．Ｂに対する送金リクエストに関連付けられたリマインド停止アイコンＩＣ１０の表示態様が、図９－２に示した態様から変化する。具体的には、限定ではなく例として、図９－４に示すように、リマインド停止アイコンＩＣ１０のスピーカの画像部分以外の黒色で表示されていた領域も白抜きされて表示される。
また、送金リマインドが停止されたことに基づき、限定ではなく例として、図９－４に示すように、上記の送金リクエストに対応する送金リマインドの表示領域が退色して表示されている。

なお、送金リマインドを停止するばかりでなく、端末２０Ａに対するユーザによる入力に基づいて、金銭が支払い済みであることをサーバ１０に通知するようにしてもよい。
この場合、サーバ１０は、リマインド停止フラグを「ＯＮ」に設定するばかりでなく、送金済みフラグも「ＯＦＦ」に設定する。
これにより、限定ではなく例として、図９－５に示すように、端末２０Ａの表示部２４に表示される送金リクエスト一覧画面では、送金リクエストおよびそれに対応する送金リマインドの各々について、「ＤＯＮＥ」の文字を含む完了マークＭＫ１が表示される。

図９－６は、ユーザＢ．Ｂの端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。
この例では、送金マスターユーザをユーザＡ．Ａとし、送金リクエスト先ユーザをユーザＢ．Ｂとして、ユーザＢ．Ｂが、ユーザＡ．Ａから受け取った送金リクエストに対応する送金リマインドを停止するように依頼する場合を説明する。

この送金リクエスト一覧画面には、ユーザＢ．ＢがユーザＡ．Ａから受け取った送金リクエストに関する情報と、この送金リクエストに対応する送金リマインドに関する情報とが表示されている。
送金リクエストの表示領域において、ユーザＡ．Ａのアイコン画像およびユーザ名の横には、前述したリマインド停止アイコンＩＣ１０が表示されている。

リマインド停止アイコンＩＣ１０がタップされると、限定ではなく例として、図９－７に示すように、この送金リクエストに対応する送金リマインドを停止してもらうようにユーザＡ．Ａに依頼するための第２送金リマインド停止情報が、画面中央にポップアップ表示される。
そして、第２リマインド停止確認情報に含まれるＯＫボタンＢＴ１０がタップされると、送金リクエスト選択情報と、第２送金リマインド停止要求情報とが端末２０Ｂからサーバ１０に対して送信される。この場合、サーバ１０は、ユーザＡ．Ａの端末２０Ａに対して、
送金リマインドの停止を承認するか否かを確認するための情報を送信する。

図９－８は、この場合にユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面の一例を示す図である。
端末２０Ａの表示部２４には、送金リクエスト一覧画面の中央部に、サーバ１０から受信した送金リマインドの停止を承認するか否かを確認するための停止承認確認情報が表示されている。そして、承認確認情報に含まれるＯＫボタンＢＴ１０がタップされると、端末２０Ａからサーバ１０に対して、承認情報が送信される。そして、サーバ１０において、この送金リクエストに対応する送金リマインドが停止される。
その結果、端末２０Ｂの表示部２４には、限定ではなく例として、図９－９に示すような送金リクエスト一覧画面が表示される。

図９－９の送金リクエスト一覧画面では、限定ではなく例として、ユーザＡ．ＡからユーザＢ．Ｂに対する送金リクエストに関連付けられたリマインド停止アイコンＩＣ１０の表示態様が変化して表示されるとともに、この送金リクエストに対応する送金リマインドの表示領域が退色して表示されている。

＜第９実施例の効果＞
本実施例は、サーバ１０による送金リマインド情報（限定ではなく、第２情報の一例）の送信制御は、送金マスターユーザ（限定ではなく、第１ユーザの一例）の端末２０による入力（限定ではなく、第１入力の一例）に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第１ユーザの意向に応じて、送金依頼先のユーザの端末への第２情報の送信制御を行うことができる。

また、本実施例は、上記の第１入力は、送金リクエスト先ユーザの端末２０に対する送金リマインド情報の送信を行わないことに関する入力である構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼元の第１ユーザの意向に応じて、送金依頼先のユーザの端末に対して第２情報を送信しないように制御することができる。

また、本実施例は、上記の送信制御は、送金リクエスト先ユーザ（限定ではなく、端末のユーザの一例）による、自己の端末２０に対する入力（限定ではなく、第２入力の一例）に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じて、この送金依頼先のユーザの端末への第２情報の送信制御を行うことができる。

また、本実施例は、上記の第２入力は、送金リマインド情報の送信を行わないことに関する入力である構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼先のユーザの意向に応じて、この送金依頼先のユーザの端末に対して第２情報を送信しないように制御することができる。

また、本実施例は、上記の送信制御は、上記の第２入力と、送金マスターユーザによる第２情報の送信を行わないことの承認に関する情報（限定ではなく、第１ユーザによる第２入力に対する承認に関する情報の一例）とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第２入力があった場合であっても、送金依頼元の第１ユーザによる第２入力に対する承認がなければ、送金依頼先のユーザの端末に対して第２情報が送信されるようにすることができる。また、これとは逆に、限定ではなく例として、第２入力があった場合に、送金依頼元の第１ユーザによる第２入力に対する承認があれば、送金依頼先のユーザの端末に対して第２情報が送信されないようにすることができる。

＜その他＞
上記の実施例では、本発明における送金依頼に関する第１情報を「送金リクエスト情報」とし、送金依頼に基づく第２情報を「送金リマインド情報」としたが、これらに限定されない。

本発明における第１情報と第２情報との組合せは、以下の組合せのうちのいずれかの組合せとすることができる。
（１）第１の組合せ
・第１情報：送金リクエスト情報
・第２情報：送金リマインド情報
この組合せは、上記の実施例で説明した組合せである。

（２）第２の組合せ
・第１情報：送金リクエスト情報
・第２情報：送金免除情報
送金免除情報は、限定ではなく例として、送金マスターユーザが送金リクエスト先ユーザに対して送金を免除することを通知するための情報（送金を行う必要がないことを通知するための情報）である。
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して一旦は送金リクエストを行ったものの、何らかの事情により、送金を行う必要がないことを送金リクエスト先ユーザに知らせたいような場合に適用可能である。

（３）第３の組合せ
・第１情報：送金免除情報
・第２情報：送金免除リマインド情報
送金免除リマインド情報は、限定ではなく例として、送金マスターユーザが送金リクエスト先ユーザに対して送金を免除することを再確認させるための情報（送金を行う必要がないことを念押しするための情報）である。
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して送金を免除することを通知した後、そのことを念押ししたいような場合に適用可能である。

（４）第４の組合せ
・第１情報：送金免除情報
・第２情報：送金リクエスト情報
この組合せは、送金マスターユーザが、送金リクエスト先ユーザに対して一旦は送金を免除することを通知したものの、何らかの事情により、送金を行ってもらう必要が生じ、送金を依頼する場合に適用可能である。

１通信システム
１０サーバ
２０端末
３０ネットワーク

Claims

端末と通信するサーバによって実行されるプログラムであって、
第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を前記サーバの制御部によって行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うこととが前記サーバによって実行される。
請求項１に記載のプログラムであって、
前記第１情報は、前記送金依頼に基づく金額の情報を含み、
前記第２情報は、前記送金依頼に基づく前記金額の情報を含む。
請求項１または請求項２に記載のプログラムであって、
前記送金処理は、前記第１情報に基づく第１表示が前記端末に表示され、前記端末のユーザによる前記第１表示に対する入力に基づいて実行される。
請求項３に記載のプログラムであって、
前記第１表示は、前記端末のユーザと前記第１ユーザとを少なくとも含むチャットルームに表示される。
請求項１から請求項４のいずれか一項に記載のプログラムであって、
前記第２情報が前記通信部によって前記端末に送信された後、前記送金処理が実行されない場合、前記送金依頼に基づく第３情報を前記通信部によって前記端末に送信する制御を前記制御部によって行い、前記第２情報が前記通信部によって前記端末に送信された後、前記第２情報に基づく第２表示が前記端末に表示され、前記端末のユーザによる前記第２表示に対する入力に基づいて前記送金処理が実行された場合、前記第３情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うことが前記サーバによって実行される。
請求項１から請求項５のいずれか一項に記載のプログラムであって、
前記送金処理は、前記端末の表示部に表示された前記第１ユーザの選択に基づいて実行される。
請求項６に記載のプログラムであって、
前記送金処理は、前記端末のユーザによる、前記第１ユーザの選択と、前記第２情報の送信を行わないことを示す情報の選択とに基づいて実行される。
請求項６または請求項７に記載のプログラムであって、
前記送金処理は、前記第１ユーザの選択と、前記送金依頼に基づく金額と、前記端末のユーザによって入力された金額とに基づいて実行される。
請求項１から請求項８のいずれか一項に記載のプログラムであって、
前記送金処理は、前記端末のユーザから前記第１ユーザへの送金に関する処理である。
請求項１から請求項８のいずれか一項に記載のプログラムであって、
前記送金処理は、前記端末のユーザとは異なる第２ユーザによる前記第１ユーザへの送金に基づいて実行される。
請求項１０に記載のプログラムであって、
前記第１情報は、前記端末のユーザと、前記第１ユーザと、前記第２ユーザとを少なくとも含むグループに対して送信され、
前記送金処理は、前記第２ユーザによる、前記第２ユーザの端末に表示された前記第１情報に基づく第１表示に対する入力に基づいて実行される。
請求項１から請求項１１のいずれか一項に記載のプログラムであって、
前記第１ユーザを送信元として前記端末に表示させるための前記第１情報を前記サーバの通信部によって前記端末に送信することが前記サーバによって実行される。
端末と通信するサーバの情報処理方法であって、
第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を前記サーバの制御部によって行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うこととを含む。
端末と通信するサーバであって、
第１ユーザによる送金依頼に関する第１情報を前記端末に送信する通信部と、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を行う制御部とを備える。
端末と通信するサーバであって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
前記プロセッサーは、
第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を行うこととを実行する。
端末によって実行されるプログラムであって、
第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、
前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を前記端末の制御部によって行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を前記制御部によって行うこととが前記端末によって実行され、
前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
請求項１６に記載のプログラムであって、
前記送金処理は、前記端末のユーザによる前記第１表示に対する入力に基づいて実行される。
請求項１７に記載のプログラムであって、
前記端末のユーザと前記第１ユーザとを少なくとも含むチャットルームを前記表示部に表示することと、
前記チャットルームに前記第１表示を表示することとが前記端末によって実行される。
請求項１６に記載のプログラムであって、
前記送金依頼を行った前記第１ユーザに関する第１ユーザ情報を前記表示部に表示することが前記端末によって実行され、
前記送金処理は、前記端末のユーザによる、前記表示部に表示された前記第１ユーザ情報に対する入力に基づいて実行される。
請求項１６に記載のプログラムであって、
前記端末に対する入力に基づいて、前記第１ユーザが選択されたことを示す情報と、前記第１ユーザに送金する金額情報とを前記制御部によって取得することが前記端末によって実行され、
前記送金処理は、前記送金依頼に基づく金額と、前記第１ユーザに送金する前記金額情報とに基づいて実行される。
請求項１９または請求項２０に記載のプログラムであって、
前記送金処理は、前記端末のユーザによる前記端末に対する、前記送金依頼に基づく前記第１ユーザへの送金であることを示す入力に基づいて実行される。
請求項１６から請求項２１のいずれか一項に記載のプログラムであって、
前記第２表示が前記表示部に表示された後、前記送金処理が前記制御部によって行われない場合、前記送金依頼に基づく第３表示を前記表示部に表示する制御を行い、前記第２表示が前記表示部に表示された場合、前記端末のユーザによる、前記第２表示に対する入力に基づいて、前記送金処理が前記制御部によって行われ、前記送金依頼に基づく前記第３表示を前記表示部に表示しない制御を前記制御部によって行うことが前記端末によって実行される。
請求項１６から請求項２２のいずれか一項に記載のプログラムであって、
前記第１表示は、前記第１ユーザが送信元であることを示す情報を含む。
端末の情報処理方法であって、
第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、
前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を前記端末の制御部によって行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を前記制御部によって行うこととを含み、
前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
端末であって、
第１ユーザによる送金依頼に関する第１情報を受信する通信部と、
前記第１情報に基づく第１表示を表示する表示部と、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を行う制御部とを備え、
前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。
端末であって、
メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
前記プロセッサーは、
第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、
前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、
前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を行うこととを実行し、
前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。