JP7183217B2 - プログラム、情報処理方法、端末 - Google Patents

プログラム、情報処理方法、端末 Download PDF

Info

Publication number
JP7183217B2
JP7183217B2 JP2020113408A JP2020113408A JP7183217B2 JP 7183217 B2 JP7183217 B2 JP 7183217B2 JP 2020113408 A JP2020113408 A JP 2020113408A JP 2020113408 A JP2020113408 A JP 2020113408A JP 7183217 B2 JP7183217 B2 JP 7183217B2
Authority
JP
Japan
Prior art keywords
user
terminal
remittance
information
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020113408A
Other languages
English (en)
Other versions
JP2022011963A (ja
Inventor
亮介 濱窄
洋輔 真崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Line Corp
Original Assignee
Line Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Line Corp filed Critical Line Corp
Priority to JP2020113408A priority Critical patent/JP7183217B2/ja
Priority to CN202180046235.2A priority patent/CN115803766A/zh
Priority to KR1020227044389A priority patent/KR20230031215A/ko
Priority to PCT/JP2021/022487 priority patent/WO2022004339A1/ja
Publication of JP2022011963A publication Critical patent/JP2022011963A/ja
Priority to JP2022186509A priority patent/JP2023015366A/ja
Application granted granted Critical
Publication of JP7183217B2 publication Critical patent/JP7183217B2/ja
Priority to US18/090,888 priority patent/US20230138065A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

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などのマークアップ言語などを用いて実装される。
以下では、本発明をサーバクライアントシステムによって実現する実施例について説明する。
ただし、サーバクライアントシステムに限らず、サーバを含まないシステムによって本発明を実現することも可能である。これは、限定ではなく例として、以下のようなシステムである。
・サーバの機能を端末２０に持たせるシステム（分散システム）。これは、限定ではなく例として、ブロックチェーン（チェイン）の技術を用いて実現することが可能である。
・端末２０同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてＰ２Ｐ（ピアツーピア）方式等で通信を行うことで実現可能である。
また、以下では、適宜「通信Ｉ／Ｆによって」という表現を使用する。これは、装置が、限定ではなく例として、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示す。
＜概要＞
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子貨幣による支払いを行うためのアプリケーション（支払いアプリケーション）、電子貨幣による決済を行うためのアプリケーション（決済アプリケーション）、電子貨幣による送金／受取を行うためのアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子貨幣（電子マネー）を用いた各種のサービスを受けることが可能になってきている。
「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末２０、または端末２０のユーザが所有する電子的な貨幣を意味する。
なお、電子貨幣は、「電子マネー」や「デジタル通貨（デジタル貨幣）」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」には、暗号通貨（暗号資産）を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
本明細書では、一例として「電子マネー」の用語を用いることとし、限定ではなく例として、端末２０のユーザの電子マネーの口座の残高のことを「電子マネー口座残高」と称する。
また、以下では、端末２０のユーザから異なる端末２０のユーザ（相手のユーザ）に対して送金を行うように依頼することを「送金リクエスト」（送金依頼と同義。）と称する。そして、この送金リクエストに関する情報を「送金リクエスト情報」と称する。
送金を依頼することを「送金リクエストする」、「送金リクエストを行う」等のように表現する場合がある。
また、送金を依頼されることを「送金リクエストされる」、「送金リクエストが行われる」、等のように表現する場合がある。
また、送金リクエストを送ることを「送金リクエストを送信する」、「送金リクエストを送付する」等のように表現するが、これらは実質的に同義である。
また逆に、送金リクエストを受け取ることを「送金リクエストを受信する」、「送金リクエストを受け取る」等のように表現するが、これらは実質的に同義である。
また、以下では、送金リクエストの内容を相手のユーザに思い出させること、想起させること、再確認させること等を意味する用語を「送金リマインド」と称し、この送金リマインドに関する情報を「送金リマインド情報」と称する。
送金をリマインドすることを「送金リマインドする」、「送金リマインドを行う」等のように表現する場合がある。
また、送金をリマインドされることを「送金リマインドされる」、「送金リマインドが行われる」等のように表現する場合がある。
また、送金リクエスト情報（送金リマインド情報も同様。）には、少なくとも、送金が依頼されたことを示す情報、送金依頼主（送金依頼元）のユーザの情報、送金依頼先のユーザの情報が含まれればよい。
なお、後述するが、送金を依頼する金額（以下、「送金リクエスト金額」と称する。）、送金を行う事由、送金による支払いの期限（以下、「支払い期限」と称する。）等の情報を、送金リクエスト情報に含めることもできる。
また、以下では、端末２０にインストールされたアプリケーション（支払いアプリケーションやメッセージングアプリケーション）によって、本発明に係る各種の処理が実行されることとして説明する。
なお、支払いアプリケーションの一機能としてチャットサービス（限定ではなく例として、メッセージングサービス）の機能を持たせる、またはチャットアプリケーション（限定ではなく例として、メッセージングアプリケーション）の一機能として支払いサービスの機能を持たせるようにすることもできる。
メッセージングサービスでは、ユーザが、チャットルームを利用してチャットを行うことができるように構成されている。
以下の説明では、適宜、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）を「トークルーム」と称する。また、トークルームをチャットルームと称してもよい。
なお、トークルームには、限定ではなく例として、一対一のユーザのトークルームの他、複数のユーザを含むグループのトークルーム（グループトークルーム）を含めることができる。この場合におけるトークルームは、複数のユーザを含むグループの各端末間で送受信されるコンテンツをグループに含まれるユーザが閲覧できるＵＩやＧＵＩのことを意味する。
また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。
なお、メッセージングサービス：ＭＳ（ＩＭＳを含む。）を、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と捉える考え方もある。
このため、メッセージングサービス：ＭＳと、ソーシャルネットワーキングサービス：ＳＮＳとは区別してもよいし、区別しなくてもよい。
＜実施例＞
以下、本発明を適用した実施例について説明する。
相手のユーザ（第１ユーザ）から自分（端末のユーザ）への送金依頼（送金リクエスト）や、自分から相手のユーザへの送金依頼（送金リクエスト）が処理されずに、複数の送金リクエストが端末２０に蓄積していく場合がある。限定ではなく例として、送金リクエストを処理することをうっかり忘れてしまったような場合である。
この場合、未処理の送金リクエストを一つ一つ処理していこうとすると、時間がかかってしまい、不便である。また、未処理の送金リクエストを一つ一つ処理していこうとすると、ユーザの残高が足りなくなってしまうような場合もあり得る。
そこで、複数の送金リクエスト（ここでは、未処理の複数の送金リクエスト）を一括的に処理する手法について説明する。この一括的な処理のことを「一括処理」と称する。
一括処理には、大きく分けて、少なくとも以下の処理を含めることができる。
（１）一括的な精算（以下、「一括精算」と称する。）に関する処理
（２）送金リクエストの相殺（以下、「リクエスト相殺」と称する。）に関する処理
（３）一括的な送金リクエスト（以下、「一括送金リクエスト」と称する。）の作成に関する処理
（４）特殊な一括精算（以下、「特殊一括精算」と称する。）に関する処理・特殊な一括送金リクエスト（以下、「特殊一括送金リクエスト」と称する。）の作成に関する処理
また、以下説明する実施例では、相手のユーザを一人のユーザとする場合、つまり、第２ユーザは第１ユーザである（または第１ユーザは第２ユーザである）場合を例示する。
なお、変形例等でも説明するが、相手のユーザを異なる複数のユーザとする場合、つまり、第１ユーザは第２ユーザとは異なるユーザである（第２ユーザは第１ユーザとは異なるユーザである）場合についても、以下説明する手法を同様に適用することができる。
＜第１実施例＞
第１実施例は、上記の一括処理のうちの一括精算に関する実施例である。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜機能構成＞
（１）サーバ
図１－２は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
サーバ１０の制御部１１は、限定ではなく例として、記憶部１５に記憶されている支払いアプリケーション管理処理プログラム１５１に従って、支払いアプリケーションによる各種の支払いサービスを端末２０、または端末２０のユーザに提供するための処理を行う支払いアプリケーション管理処理部１１１を機能部として含む。
図１－３は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、制御部１１によって読み出され、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム１５１と、ユーザ登録データ１５３と、ユーザ管理データベース１５５と、送金リクエスト管理データ１５７とが記憶される。
ユーザ登録データ１５３は、支払いアプリケーションを利用する端末２０、またはその端末２０のユーザに関する登録データであり、そのデータ構成の一例を図１－４に示す。
ユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、アプリケーションＩＤと、端末電話番号と、その他登録情報とが関連付けて記憶される。
ユーザ名は、支払いアプリケーションを利用する端末２０のユーザの名称であり、限定ではなく例として、端末２０のユーザが支払いアプリケーションを利用する際に登録する名称が記憶される。
アプリケーションＩＤは、支払いアプリケーションのアカウントを識別するために用いられる情報、またはアカウントそのものである。
このアプリケーションＩＤは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ１０によってアカウントごとに一意な値（固有の値）が設定されて記憶される。
アプリケーションＩＤは、端末２０、またはその端末２０のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、限定ではなく例として、端末２０のユーザが支払いアプリケーションを利用する際に登録する端末２０の電話番号が記憶される。
その他登録情報には、限定ではなく例として、端末２０のＩＤ：端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））、このユーザ名のユーザの端末２０のメールアドレス（端末メールアドレス）、支払いアプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワードを）等の認証情報等の情報を含めるようにすることができる。
端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤとすることができる。
また、端末２０のユーザを識別するための識別情報は、限定ではなく例として、アプリケーションＩＤとすることができる。なお、これを「ユーザＩＤ」としてもよいし、しなくてもよい。
また、１つの端末２０につき１つのアカウントしか登録することのできないアプリケーションであれば、限定ではなく例として、「端末２０を識別するための識別情報＝端末２０のユーザを識別するための識別情報＝アプリケーションＩＤ」とすることができる。
また、限定ではなく例として、１つのユーザＩＤに、複数の端末ＩＤを割り当てることを可能としてもよいし、そのようにしなくてもよい。
なお、端末電話番号の登録は必須ではなく、端末電話番号をユーザ登録データ１５３に記憶させないようにしてもよい。
また、アプリケーションＩＤ等の各種のＩＤに代えて、端末電話番号によってアカウントを管理する手法を適用することも可能である。この場合、アプリケーションＩＤ等のＩＤをユーザ登録データ１５３に記憶させるのに代えて、端末電話番号をユーザ登録データ１５３に記憶させるようにすることができる。
ユーザ管理データベース１５５は、支払いアプリケーションを利用する端末２０、またはそのユーザに関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、その一例である第１のユーザ管理データベース１５５Ａの構成一例を図１－５に示す。
第１のユーザ管理データベース１５５Ａには、アプリケーションＩＤごとの管理データとして、ユーザ管理データが記憶される。
各々のユーザ管理データには、限定ではなく例として、アプリケーションＩＤと、そのアプリケーションＩＤによって識別されるユーザの電子マネー口座残高と、送金履歴データと、受金履歴データとが記憶される。
送金履歴データは、このアプリケーションＩＤのユーザから他のアプリケーションＩＤのユーザへの送金の履歴の情報（送金履歴情報）が記憶されたデータである。
受金履歴データは、このアプリケーションＩＤのユーザの他のアプリケーションＩＤのユーザからの受金の履歴の情報（受金履歴情報）が記憶されたデータである。
送金リクエスト管理データ１５７は、送金リクエストに関する情報を管理するためのデータを蓄積的に記憶したデータベースであり、その一例である第１の送金リクエスト管理データ１５７Ａの構成例を図１－６に示す。
第１の送金リクエスト管理データ１５７Ａには、限定ではなく例として、日時と、送金リクエスト管理ＩＤと、送金マスターＩＤと、送金リクエスト先ＩＤと、送金リクエスト金額と、送金済みフラグとが関連付けて記憶される。
日時には、限定ではなく例として、対応する送金リクエストの送金リクエスト情報がサーバ１０から送金リクエスト先ユーザの端末２０に送信された日時が記憶される。
送金リクエスト管理ＩＤには、送金リクエストごとにサーバ１０によって一意に設定されるＩＤが記憶される。
送金マスターＩＤには、送金を依頼したユーザ（送金マスターユーザとも言う。）のアプリケーションＩＤが記憶される。
送金リクエスト先ＩＤには、送金を依頼されたユーザ（送金リクエスト先ユーザとも言う。）のアプリケーションＩＤが記憶される。
送金リクエスト金額には、その送金リクエストによって送金マスターユーザから送金リクエスト先ユーザに送金が依頼された金額が記憶される。
送金済みフラグは、制御部１１によって精算処理が実行されることで、その送金リクエストに対応する送金が完了したか否かを示すフラグであり、デフォルトは「ＯＦＦ」とされ、送金が完了することで「ＯＮ」に設定される。
サーバ１０が送金リクエストを管理する手法としては、以下の２つのパターンが考えられる。
（１）パターンＡ：送金を実行した送金リクエストを削除せずに残す。
（２）パターンＢ：送金を実行した送金リクエストを削除する。
このどちらのパターンを適用することもできるが、パターンＡを適用する場合は、送金済みフラグを「ＯＮ」とした送金リクエストのデータは削除せずに残す。
一方、パターンＢを適用する場合は、送金を実行した送金リクエストのデータのレコードを削除する。
（２）端末
図１－７は、本実施例において端末２０の制御部２１によって実現される機能の一例を示す図である。
制御部２１は、限定ではなく例として、記憶部２８に記憶されている支払いアプリケーション処理プログラム２８１に従って、支払いアプリケーション処理を実行する支払いアプリケーション処理部２１１を機能部として含む。
図１－８は、本実施例において端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、制御部２１によって読み出され、支払いアプリケーション処理として実行される支払いアプリケーション処理プログラム２８１と、自己の端末２０またはそのユーザに関連付けられたアプリケーションＩＤ２８３とが記憶される。
＜表示画面＞
以下では、限定ではなく例として、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置され、これによってタッチスクリーンが構成される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによって操作された場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。
以下では、ユーザによる操作を、限定ではなく例として、タップ（タップ操作）として説明する。
タップ（タップ操作）とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部２４（タッチスクリーン）を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。
なお、以下説明する表示画面の遷移は、本開示の手法を実現するための表示画面の遷移の一例に過ぎない。以下に例示する表示画面の遷移について、一部の表示画面の表示を省略してもよいし、別の表示画面を追加してもよい。
図１－９は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面である。
メニュー画面最上部中央には、支払いアプリケーションの名称として「Ｐａｙｍｅｎｔ Ａｐｐ」の文字が表示されている。また、画面最上部右方には、この端末２０のユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＡ．Ａ）が表示されている。
また、その下には、支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１が構成されており、この例では、現在位置が支払いアプリケーションのメインメニューであることを示す「ウォレットメインメニュー」の文字が、現在位置表示領域内に表示されている。
メインメニュー画面の下部に表示された送金リクエスト一覧アイコンＩＣ１がタップされると、端末２０Ａからサーバ１０に対して、送金リクエスト一覧情報を要求する情報が送信され、サーバ１０から端末２０Ａに対して、送金リクエスト一覧情報が送信される。その結果、限定ではなく例として、図１－１０に示すような送金リクエスト一覧画面が表示される。
現在位置表示領域ＣＬＲ１には、送金リクエスト一覧情報を表示していることを示す「送金リクエスト一覧」の文字が表示されている。
この送金リクエスト一覧画面は、自己の端末２０のユーザ（ユーザＡ．Ａ）に関する送金リクエストとして、異なる端末２０のユーザとの間の未処理の送金リクエスト（以下、「未処理リクエスト」と称する。）が、異なる端末２０のユーザ別に表示されている。
以下では、一括処理を行うことを提案するユーザのことを、適宜「提案者のユーザ」と称する。
また、提案者のユーザによって一括処理が提案されるユーザのことを、適宜「相手のユーザ」と称する。
具体的には、相手として、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ等の複数のユーザについて、各々のユーザのアイコン画像およびユーザ名と関連付けて、そのユーザとの間の未処理リクエストの件数と、そのユーザとの間の未処理リクエストを一括して処理した場合における精算金額（以下、「一括精算金額」と称する。）とが表示されている。
ここで、相手から自分に依頼された送金リクエストによって自分が相手に支払うことになる金額を適宜「支払い金額」と称し、自分から相手に依頼した送金リクエストによって自分が相手から受け取る金額を適宜「受取金額」と称する。
この場合、「一括精算金額」は、未処理リクエストの全部を一括して処理した場合の、各々の未処理リクエストに対応する支払い金額、受取金額を正負の符号を逆転させて合算した金額となる。この一括精算金額は、限定ではなく例として、サーバ１０の制御部１１が実行する精算処理において算出される。
また、この表示画面例では、一括精算金額の横には、自分が相手に対してその一括精算金額を支払う場合には「支払い」であることを示す支払いマークが関連付けて表示され、自分が相手からその一括精算金額を受け取る場合には「受取」であることを示す受取マークが関連付けて表示される。
限定ではなく例として、ユーザＡ．Ａ（自分）はユーザＢ．Ｂ（相手）との間で４件の未処理リクエストがあり、これら４件の未処理リクエストを一括して処理した場合、ユーザＡ．ＡはユーザＢ．Ｂに対して一括精算金額として「１，０００円」を支払うことになることが示されている。
同様に、限定ではなく例として、ユーザＡ．Ａ（自分）はユーザＣ．Ｃ（相手）との間で４件の未処理リクエストがあり、これら４件の未処理リクエストを一括して処理した場合、ユーザＡ．ＡはユーザＣ．Ｃから一括精算金額として「４，０００円」を受け取ることになることが示されている。
また、画面下部には、全ての未処理リクエストの一括精算をサーバ１０に要求するための精算ボタンＢＴ１が表示されている。
この画面において、限定ではなく例として、ユーザＣ．Ｃの表示領域ＷＲ１がタップされると、図１－１１に示す送金リクエスト詳細画面が表示される。この送金リクエスト詳細画面には、ユーザＣ．Ｃとの間の未処理リクエストの詳細が表示されている。
一括精算とは、複数の未処理リクエストに基づき一括して精算を行うことであり、限定ではなく例として、未処理リクエストの全部を一括して精算する「全選択一括精算」と、未処理リクエストの一部かつ複数を一括して精算する「一部選択一括精算」とが含まれる。
画面上部の現在位置表示領域ＣＬＲ１には、ユーザＣ．Ｃとの間の未処理リクエストを表示していることを示す「Ｃ．Ｃとの送金リクエスト」の文字が表示されている。
また、現在位置表示領域ＣＬＲ１の下には、ユーザＣ．Ｃのアイコン画像およびユーザ名と関連付けて、全選択一括精算を行うと仮定した場合の一括精算金額（この例では「４，０００円」）およびマーク（この例では「受取マーク」）が表示されている。
ユーザＣ．Ｃのアイコン画像の横には、タップによってチェックの「ＯＮ／ＯＦＦ」を切替可能に構成されたチェック領域ＡＳＲ１が設けられており、チェックを「ＯＮ」とすることでチェック領域にチェックマークが表示され、全ての未処理リクエストを一括精算することが可能に構成されている。
その下には、相手をユーザＣ．Ｃとする送金リクエストが一覧表示されている。この例では、相手をユーザＣ．Ｃとする未処理リクエストが上から古い順に時系列で一覧表示され、未処理リクエストの一覧表示の下に、処理済みのリクエスト（以下、「処理済みリクエスト」と称する。）が上から古い順に時系列で一覧表示されている。また、処理済みリクエストについては、未処理リクエストと区別するため、異なる表示態様（この例ではグレーアウト）で表示されている。
以下では、自分から相手に送信済みの送金リクエストを「送信済み送金リクエスト」と称し、自分が相手から受信済みの送金リクエストを「受信済み送金リクエスト」と称する。
この場合、未処理リクエストのうちの送信済み送金リクエストについては「リクエスト送信」と示されたリクエスト送信マークが表示され、未処理リクエストのうちの受信済み送金リクエストについては「リクエスト受信」と示されたリクエスト受信マークが表示される。
また、各々の未処理リクエストには、送信済み送金リクエストについては、そのリクエストを自己の端末２０から相手のユーザの端末２０に送信した日時が、受信済み送金リクエストについては、そのリクエストを自己の端末２０が相手のユーザの端末２０から受信した日時が、それぞれ関連付けて表示されている。
また、各々の未処理リクエストには、限定ではなく例として、その未処理リクエストによって送金を行う事由が関連付けて表示されている。
なお、送金リクエスト金額の情報を送金リクエスト情報に含めず、送金リクエスト金額の情報を表示しないようにしてもよい。この場合、限定ではなく例として、提案者のユーザが、送金リクエスト金額の情報を、サーバ１０に問い合わせる、または相手のユーザに問い合わせるようにすることができる。
また、送金リクエスト金額の情報を送金リクエスト情報に含めるが、送金リクエストの一覧画面や送金リクエストの個別画面には表示しないようにしてもよい。また、この場合、限定ではなく例として、送金リクエストの個別画面において、送金リクエストの詳細内容を確認するための入力がなされたことに基づいて、送金リクエスト金額の情報を含む送金リクエストの詳細画面を表示するようにしてもよい。
なお、これらは、送金を行う事由の情報など、送金リクエストに関する他の情報についても同様である。
また、各々の未処理リクエストには、限定ではなく例として、送信済み送金リクエストについては、その送信済み送金リクエストを処理することによって自分が相手から受け取ることになる受取金額と受取マークとが関連付けて表示され、受信済み送金リクエストについては、その受信済み送金リクエストを処理することによって自分が相手に支払うことになる支払い金額と支払いマークとが関連付けて表示される。
また、各々の未処理リクエストの横には、タップによってチェックの「ＯＮ／ＯＦＦ」を切替可能に構成されたチェック領域ＳＲ１が設けられており、チェックを「ＯＮ」とすることでチェック領域ＳＲ１にチェックマークが表示され、その未処理リクエストを一括精算の対象として選択することができるように構成されている。
また、画面下部には、選択された未処理リクエストの一括精算をサーバ１０に要求するための精算ボタンＢＴ２が表示されている。
なお、図１－１１では、未処理リクエストとともに処理済みリクエストも表示させることとしたが、処理済みリクエストは表示させないようにしてもよい。
限定ではなく例として、３つ目の送信済み送金リクエスト（受取 １０，０００円）と、４つ目の受信済み送金リクエスト（支払い ３，０００円）との２つのリクエストのチェックが「ＯＮ」とされて選択され、精算ボタンＢＴ２がタップされると、図１－１２に示すような表示が表示される。
図１－１２では、図１－１１の画面下部に、一括精算の内容をユーザに確認させるための一括精算確認情報が表示される。この例では、「ウォレット残高」のテキストを含む電子マネー口座残高表示領域ＷＢＲ１内に、自分の現在の電子マネー口座残高が一括精算によってどのように変化するかを示す精算内容確認領域ＡＣＲ１が設けられている。
精算内容確認領域ＡＣＲ１には、限定ではなく例として、左側に自分（ユーザＡ．Ａ）の現在の電子マネー口座残高が、右側に精算後の自分の電子マネー口座残高がそれぞれ表示される。
また、その下には、「この内容で精算を提案しますか？」のテキストとともに、精算を提案するための「提案」と示された提案ボタンＢＴ３と、精算をキャンセルするための「キャンセル」と示されたキャンセルボタンとが表示されている。
この例では、ユーザＡ．Ａの現在の電子マネー口座残高は「５００円」である。
そして、上記で選択された２つのリクエストが一括精算されると、ユーザＡ．Ａにとっては、「受取 １０，０００円」と「支払い ３，０００円」とで「受取 ７，０００円」となる。よって、現在の電子マネー口座残高「５００円」に一括精算金額「７，０００円」が加算されることで、精算後の電子マネー口座残高が「７，５００円」となることが示されている。
図１－１３は、上記の画面において提案ボタンＢＴ３がタップされたことに基づいて表示される支払いアプリケーションのおしらせ画面の一例を示す図である。このおしらせ画面は、ユーザＡ．Ａの相手方であるユーザＣ．Ｃの端末２０Ｃの表示部２４に表示される画面の一例である。
図１－１２の端末２０Ａの表示部２４に表示される画面において提案ボタンＢＴ３がタップされることで、端末２０Ａからサーバ１０に対して一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｃの表示部２４に表示される。
このおしらせ画面の上部には、現在位置表示領域ＣＬＲ２が構成されており、支払いアプリケーションに関するおしらせを表示していることを示す「おしらせ」の文字が表示されている。
現在位置表示領域ＣＬＲ２の下には、サーバ１０を介してユーザＡ．Ａの端末２０Ａから送金リクエストの精算提案を受けたことを示す通知として、ベルのマークとともに、「送金リクエストの精算提案が届きました。」の文字を含む通知ＮＴ１が表示されている。
また、その下には、おしらせ情報を表示するためのおしらせ情報表示領域ＮＴＲ１が構成されており、このおしらせ情報表示領域ＮＴＲ１に、上記の通知ＮＴ１に対応する情報が表示される。
この例では、一括精算承認確認情報として、「精算提案」のテキストとともに、相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。この例では、一括精算金額として、ユーザＣ．ＣはユーザＡ．Ａに対して「７，０００円」を支払う必要があることが表示されている。
また、一括精算承認確認情報には、一括精算の詳細内容を確認するための「詳細を確認」のテキストが示されたリンクＬＫ１が形成されており、このリンクＬＫ１をタップすると、一括精算の詳細内容（限定ではなく例として、内訳）を確認することができるように構成されている。
なお、「詳細を確認」のリンクＬＫ１から一括精算の詳細内容を表示させるようにするのではなく、限定ではなく例として、一括精算の詳細内容を、左右方向や奥行き方向に切替可能に表示させるようにしてもよい。この一例としては、限定ではなく例として、カルーセル表示が挙げられる。
この手法は、いずれの実施例についても同様に適用可能である。
また、一括精算承認確認情報には、上記の内容で精算を承認するための「精算する」と示された精算ボタンと、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
上記のリンクＬＫ１がタップされると、限定ではなく例として、図１－１４に示すような画面が表示される。
この画面は、端末２０Ｃの表示部２４に表示される送金リクエスト一覧画面のうち、相手であるユーザＡ．Ａとの間の未処理リクエストの一覧が表示される画面である。この画面は、図１－１２に示した端末２０Ａの表示部２４に表示される画面に対応する画面である。
現在位置表示領域ＣＬＲ２には、ユーザＡ．Ａとの間の未処理リクエストを表示していることを示す「Ａ．Ａとの送金リクエスト」の文字が表示されている。
画面下部の精算内容確認領域ＡＣＲ２には、限定ではなく例として、左側に自分（ユーザＣ．Ｃ）の現在の電子マネー口座残高が、右側に精算後の自分の電子マネー口座残高がそれぞれ表示される。
また、その下には、「この内容で精算しますか？」のテキストとともに、精算を承認するための「精算」と示された精算ボタンＢＴ４と、精算を承認せずに精算の修正提案を行うための「修正提案」と示された修正提案ボタンとが表示されている。
この例では、ユーザＣ．Ｃの現在の電子マネー口座残高は「１１，０００円」である。
そして、ユーザＡ．Ａから提案された２つのリクエストが一括精算されると、ユーザＣ．Ｃにとっては、「支払い １０，０００円」と「受取 ３，０００円」とで「支払い ７，０００円」となる。よって、現在の電子マネー口座残高「１１，０００円」から一括精算金額「７，０００円」が減算されることで、精算後の電子マネー口座残高が「４，０００円」となることが示されている。
図１－１５は、上記の精算ボタンＢＴ４がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、ユーザＣ．Ｃとの間で一括精算が行われたことで、その一括精算の内容として、２件の精算結果情報が表示されている。
具体的には、限定ではなく例として、図１－１１、図１－１２で選択した３件目の送金リクエストと４件目の送金リクエストのそれぞれに対応する精算結果情報が表示されている。
各々の精算結果情報には、「リクエスト精算」および相手のユーザのアイコン画像とともに、個別の金額が表示されている。
なお、選択された送金リクエストのそれぞれに対応する精算結果情報を表示するのではなく、限定ではなく例として、図１－１６に示すように、一括精算の結果として１つにまとめて精算結果情報が表示されるようにすることもできる。
限定ではなく例として、図１－１６の精算結果情報に含まれる詳細確認のリンクＬＫ２がタップされると、図１－１７に示すような画面が表示される。
この画面の現在位置表示領域ＣＬＲ１には、一括精算の結果を表示していることを示す「リクエスト精算」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、ユーザＣ．Ｃのアイコン画像およびユーザ名と関連付けて、実行された一括精算の一括精算金額（この例では「７，０００円」）およびマーク（この例では「受取マーク」）が表示されている。
その下には、一括精算で処理された送金リクエストが一覧表示されている。
また、画面下部には、電子マネー口座残高表示領域ＷＢＲ１が表示されている。
この電子マネー口座残高表示領域ＷＢＲ１には、「ウォレット残高」の文字が表示され、その下には、一括精算によって自分の電子マネー口座残高がどのように変化したかを示す精算結果残高表示領域ＡＲＲ１が表示されている。
精算結果残高表示領域ＡＲＲ１には、限定ではなく例として、左側に自分（ユーザＡ．Ａ）の現在の電子マネー口座残高が、右側に一括精算結果の自分の電子マネー口座残高がそれぞれ表示される。
また、その下には、一括精算を行ったことを示すテキストとして「２件のリクエストを精算しました。」のテキストが表示されている。
この例では、ユーザＡ．Ａの電子マネー口座残高が、一括精算が行われたことによって、「５００円」から「７，５００円」に変化したことが示されている。
＜処理＞
（１）処理の一例
まず、本実施例における処理の一例について説明する。
以下説明する処理は、あくまでも本開示の手法を実現するための処理の一例に過ぎず、これらの処理に限定されるものではない。
また、以下説明する処理に、別のステップを追加してもよいし、一部のステップを省略（削除）してもよい。
これは、以下説明する各フローチャート（処理）について同様である。
図１－１８は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末２０Ａの制御部２１が実行する処理、端末２０Ｂの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理をそれぞれ示している。
限定ではなく例として、端末２０ＡのユーザＡ．Ａが、端末２０ＢのユーザＢ．Ｂとの間で行われる送金リクエストを一括して処理することを要求する場合を例示する。
この処理では、簡明化のため、処理の終了判定を省略する。
まず、端末２０Ａの制御部２１は、入力部に対する入力に基づいて、限定ではなく例として、送金リクエストの一覧を要求するための送金リクエスト一覧要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１１０）。
これを受けて、サーバ１０の制御部１１は、第１の送金リクエスト管理データ１５７Ａを参照し、ユーザＡ．Ａに関する送金リクエスト一覧情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２０）。
通信Ｉ／Ｆ２２によって送金リクエスト一覧情報を受信すると、端末２０Ａの制御部２１は、受信した送金リクエスト一覧情報を表示部２４に表示させる（Ａ１２０）。
その後、端末２０Ａの制御部２１は、１以上の送金リクエストが選択されたか否かを判定し（Ａ１３０）、選択されたと判定したならば（Ａ１３０：ＹＥＳ）、選択された送金リクエストに関するリクエスト選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａからリクエスト選択情報を受信したか否かを判定し（Ｓ１４０）、受信したと判定したならば、精算処理を実行する（Ｓ１５０）。
図１－１９は、精算処理の一例である第１の精算処理の流れの一例を示すフローチャートである。
サーバ１０の制御部１１は、端末２０Ａから受信したリクエスト選択情報に基づき、精算対象が一括精算対象であるか否かを判定する（Ｓ１５１０）。具体的には、選択された送金リクエストが２以上（複数）の送金リクエストであるか否かを判定する。
一括精算対象であると判定したならば（Ｓ１５１０：ＹＥＳ）、サーバ１０の制御部１１は、選択された送金リクエストの送金リクエスト金額と、選択された各々の送金リクエストの種別（受信済み送金リクエスト（支払い）／送信済み送金リクエスト（受取））とに基づいて、一括精算金額を算出する（Ｓ１５１５）。
その後、サーバ１０の制御部１１は、算出した一括精算金額に基づいて、提案者のユーザと、相手のユーザとの少なくともいずれか一方の電子マネー口座残高がマイナスになるか否かを判定する（Ｓ１５２０）。
マイナスになると判定したならば（Ｓ１５２０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、一括精算ができないことを示す一括精算ＮＧ情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５２３）。
そして、サーバ１０の制御部１１は、第１の精算処理を終了する。
一方、電子マネー口座残高がマイナスにならないと判定したならば（Ｓ１５２０：ＮＯ）、サーバ１０の制御部１１は、算出した一括精算金額の情報である一括精算金額情報を含む精算確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５２５）。
通信Ｉ／Ｆ２２によってサーバ１０から精算確認情報を受信すると、端末２０Ａの制御部２１は、受信した精算確認情報を表示部２４に表示させる（Ａ１５０）。
その後、端末２０Ａの制御部２１は、限定ではなく例として、表示部２４に表示された精算確認情報に対する入力がなされたか否かに基づいて、精算の実行をサーバ１０に要求するか否かを判定する（Ａ１６０）。そして、精算の実行を要求すると判定したならば（Ａ１６０：ＹＥＳ）、端末２０Ａの制御部２１は、精算実行要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１７０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから精算実行要求情報を受信したか否かに基づいて、精算を実行するか否かを判定する（Ｓ１５３０）。そして、精算を実行すると判定したならば（Ｓ１５３０：ＹＥＳ）、サーバ１０の制御部１１は、一括精算を実行する（Ｓ１５４０）。
図１－２０は、一括精算を説明するためのテーブルの一例を示す図である。
このテーブルでは、一括精算の提案者のユーザ（本処理例ではユーザＡ．Ａ）の未処理リクエストの種類を縦と横に示し、相手のユーザ（本処理例ではユーザＢ．Ｂ）を１人のユーザとする場合に、提案者のユーザによる提案に基づいて、２つの未処理リクエストを一括精算する場合の処理を示している。
縦と横の未処理リクエストには、それぞれ受信済み送金リクエストと、送信済み送金リクエストとが含まれる。
（１－１）受信済み送金リクエストと受信済み送金リクエストとの組合せ
この組合せでは、提案者のユーザ（ユーザＡ．Ａ）が、相手のユーザ（ユーザＢ．Ｂ）から受信済みの未処理の２つの送金リクエストに基づいて、相手のユーザに対して送金を行う。
この場合、サーバ１０の制御部１１は、一括精算において、提案者のユーザから相手のユーザに対して、２つの受信済み送金リクエストの送金リクエスト金額を加算した金額を一括精算金額として送金する処理を実行する。具体的には、サーバ１０の制御部１１は、提案者のユーザの電子マネー口座残高から一括精算金額を減算して更新し、相手のユーザの電子マネー口座残高に一括精算金額を加算して更新する。
（１－２）受信済み送金リクエストと送信済み送金リクエストとの組合せ・（１－３）送信済み送金リクエストと受信済み送金リクエストとの組合せ
この組合せでは、提案者のユーザが、相手のユーザから受信済みの未処理の送金リクエストと、相手のユーザに送信済みの未処理の送金リクエストとに基づいて、相手のユーザへの送金／相手のユーザからの受金を行う。この場合、支払いと受取の関係になるため、受信済み送金リクエストの送金リクエスト金額と、送信済み送金リクエストの送金リクエスト金額との差額分の金額が、一括精算金額となる。
以下では、この送金リクエスト金額の差額をとること（金額を差し引くこと）を「金額差し引き」と称する。
なお、金額差し引きには、金額の相殺（以下、「金額相殺」と称する。）が含まれる。
金額相殺とは、限定ではなく例として、処理対象として選択された送金リクエスト同士の金額差し引きによって、金額が互いに消し合ってゼロとなることを意味する。
金額差し引きのうちの差し引きゼロとなる場合が金額相殺である。
この例では、受信済み送金リクエストの送金リクエスト金額（送金することになる金額）と、送信済み送金リクエストの送金リクエスト金額（受金することになる金額）とが同じ金額である場合に、金額相殺されることになる。
この場合、サーバ１０の制御部１１は、受信済み送金リクエストの送金リクエスト金額（第２金額）が送信済み送金リクエストの送金リクエスト金額（第１金額）よりも大きい場合、受信済み送金リクエストの送金リクエスト金額から、送信済み送金リクエストの送金リクエスト金額を差し引いた金額（第３金額）を一括精算金額として算出する。そして、提案者のユーザの電子マネー口座残高から一括精算金額を減算して更新し、相手のユーザの電子マネー口座残高に一括精算金額を加算して更新する。
また、逆の場合は、相手のユーザの電子マネー口座残高から一括精算金額を減算して更新し、提案者のユーザの電子マネー口座残高に一括精算金額を加算して更新する。
また、受信済み送金リクエストの送金リクエスト金額（第２金額）と送信済み送金リクエストの送金リクエスト金額（第１金額）とが同じ金額である場合は、金額相殺されるため、送金は行われない。
なお、後の実施例で詳細に説明するが、受信済み送金リクエストと送信済み送金リクエストの組合せにおいて、限定ではなく例として、「送金＋送金リマインド（または新規の送金リクエスト）」の処理を行うようにすることも可能である。
つまり、受信済み送金リクエストに基づいて相手のユーザに送金するとともに、送信済み送金リクエストに基づいて相手のユーザに送金リマインド（または新規の送金リクエスト）を行うようにすることも可能である。
（１－４）送信済み送金リクエストと送信済み送金リクエストとの組合せ
この組合せでは、一括精算の提案者のユーザが、相手のユーザ宛の未処理の２つの送金リクエスト（送信済み送金リクエスト）に基づいて、これらを１つにまとめた新たな送金リクエストを相手のユーザに送付する。
この送金リクエストは、複数の送金リクエストをまとめた送金リクエスト（以下、「一括送金リクエスト」と称する。）の一種であって、送金依頼済みの金額をまとめて送金するように促すなどの目的で利用されるものである。
便宜的に、この送金リクエストを「確認用一括送金リクエスト」と称する。
この場合、サーバ１０の制御部１１は、提案者の端末２０からの要求に基づいて、確認用一括送金リクエストを作成する。そして、サーバ１０の制御部１１は、作成した確認用一括送金リクエストに対応する確認用一括送金リクエスト情報を、相手のユーザの端末２０に送信する。
なお、この（１－４）の組合せにおいて、サーバ１０の制御部１１は、確認用一括送金リクエスト情報を相手のユーザの端末２０に送信するのに代えて、選択された複数の送信済み送金リクエストの各々に対応する送金リマインド情報を、相手のユーザの端末２０に送信するようにしてもよいし、しなくてもよい。
また、（１－４）の組合せにおいて、一括精算の提案者のユーザ（この処理例ではユーザＡ．Ａ）が、相手のユーザ（この処理例ではユーザＢ．Ｂ）に依頼した未処理の２つの送金リクエストに基づいて、相手のユーザから受金するようにしてもよいし、しなくてもよい。
この場合、サーバ１０の制御部１１は、一括精算において、相手のユーザから提案者のユーザに対して、選択された送信済み送金リクエストの送金リクエスト金額を合算した金額を一括精算金額として送金する処理を実行する。具体的には、サーバ１０の制御部１１は、相手のユーザの電子マネー口座残高から一括精算金額を減算して更新し、提案者のユーザの電子マネー口座残高に一括精算金額を加算して更新する。
確認用一括送金リクエストを行うこと（確認用一括送金リクエスト情報の送信）や、送金リマインドを行うこと（送金リマインド情報の送信）は、厳密には「精算」とは意味合い・概念が異なると考えることもできる。
しかし、本明細書では簡明化のため、これらも精算に含まれる（精算の一種である）こととして図示・説明する。
図１－１９に戻り、Ｓ１５４０において一括精算を実行した後、サーバ１０の制御部１１は、第１の精算処理を終了する。
一方、精算対象が一括精算対象ではない、つまり、選択された送金リクエストが１つであると判定したならば（Ｓ１５１０：ＮＯ）、サーバ１０の制御部１１は、提案者のユーザの電子マネー口座残高がマイナスになるか否かを判定する（Ｓ１５７０）。そして、マイナスになると判定したならば（Ｓ１５７０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、精算ができないことを示す精算ＮＧ情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５７３）。
そして、サーバ１０の制御部１１は、第１の精算処理を終了する。
一方、電子マネー口座残高がマイナスにならないと判定したならば（Ｓ１５７０：ＮＯ）、サーバ１０の制御部１１は、精算金額（選択された受信済み送金リクエストの送金リクエスト金額）を含む精算確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５７５）。
通信Ｉ／Ｆ２２によってサーバ１０から精算確認情報を受信すると、端末２０Ａの制御部２１は、受信した精算確認情報を表示部２４に表示させる（Ａ１５０）。
その後、端末２０Ａの制御部２１は、限定ではなく例として、表示部２４に表示された精算確認情報に対する入力がなされたか否かに基づいて、精算の実行を要求するか否かを判定する（Ａ１６０）。そして、精算の実行を要求すると判定したならば（Ａ１６０：ＹＥＳ）、端末２０Ａの制御部２１は、精算実行要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１７０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから精算実行要求情報を受信したか否かに基づいて、精算を実行するか否かを判定する（Ｓ１５８０）。そして、実行すると判定したならば（Ｓ１５８０：ＹＥＳ）、サーバ１０の制御部１１は、精算を実行する（Ｓ１５９０）。
そして、サーバ１０の制御部１１は、第１の精算処理を終了する。
図１－１８に戻り、精算処理を実行したならば、サーバ１０の制御部１１は、精算結果が「ＯＫ」であったか否かを判定する（Ｓ１７０）。そして、「ＯＫ」であったと判定したならば（Ｓ１７０：ＹＥＳ）、サーバ１０の制御部１１は、精算結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ１９０）。そして、サーバ１０の制御部１１は、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信すると、端末２０Ａの制御部２１は、受信した精算結果情報を表示部２４に表示させる（Ａ１９０）。
そして、端末２０Ａの制御部２１は、処理を終了する。
同様に、通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信すると、端末２０Ｂの制御部２１は、受信した精算結果情報を表示部２４に表示させる（Ｂ１９０）。
そして、端末２０Ｂの制御部２１は、処理を終了する。
（２）処理の別例
次に、本実施例における処理の別例について説明する。
一括精算を行う場合に、相手のユーザの承認を必要とすることもできる。これは、以下のようなケースが考えられるためである。
（Ａ）悪意のあるユーザが一括精算によって得をしようと考えるケース
これは、送金リクエストをユーザの操作によって作成することのできるシステムでは避けることのできない問題とも言える。
限定ではなく例として、悪意のあるユーザによって、虚偽の送金リクエストが相手のユーザに送付されることが考えられる。具体的には、悪意のあるユーザが、虚偽の送金リクエストを作成して相手のユーザに送付した上で、一括精算によって金額相殺を行うことが想定される。より具体的には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから所定の送金リクエスト金額（例えば「３，０００円」）の送金リクエストを受け取った場合に、ユーザＡ．Ａが、これと同じ金額を送金リクエスト金額（例えば「３，０００円」）とする送金リクエストを作成してユーザＢ．Ｂに送り返した後に、ユーザＡ．Ａによって一括精算が行われるような場合である。
また、この他にも、悪意のあるユーザが、送金リクエストの中に虚偽の送金リクエストを紛れ込ませることも考えられる。具体的には、相手のユーザが気付かぬうちに虚偽の送金リクエストをいくつか作成して送付しておき、この虚偽の送金リクエストを用いて一括精算を行うような場合である。
これらのケースでは、相手のユーザの承認を必要としなければ、相手のユーザは騙されてしまうことになる。
（Ｂ）相手の意に沿わない一括精算が行われるケース
これは、限定ではなく例として、相手のユーザに送付済みの送金リクエストのうちの少なくとも１つの送金リクエストを対象に含めて一括精算が行われることで、相手のユーザにとっては送金（支払い）の立場となる送金リクエストが一括精算対象に含まれるため、相手のユーザが損をしたと感じる可能性がある。
ただし、全ての送金リクエストが処理されれば、正当な送金リクエストが処理される限り、最終的な結果は同じである。
上記のいずれのケースでも、一括精算の対象とされた送金リクエストが、正当な送金リクエストであるかどうか（本当に正しいかどうか）を相手のユーザに確認させる意味においても、相手のユーザの承認を必要とすることができる。
図１－２１は、本実施例において各装置が実行する処理の流れの別例を示すフローチャートである。図の見方は、図１－１８と同様である。
この処理では、サーバ１０の制御部１１は、Ｓ１５０において第２の精算処理を実行する。
図１－２２は、第２の精算処理の流れの一例を示すフローチャートである。
Ｓ１５３０において一括精算実行要求がなされたと判定したならば（Ｓ１５３０：ＹＥＳ）、サーバ１０の制御部１１は、相手のユーザの承認が必要であるか否かを判定する（Ｓ１５３１）。具体的には、限定ではなく例として、選択された２以上の送金リクエストの送金リクエスト管理ＩＤの中に、関連付けられた送金マスターＩＤがユーザＡ．ＡのアプリケーションＩＤであり、関連付けられた送金リクエスト先ＩＤがユーザＡ．Ａ以外のユーザのアプリケーションＩＤである送金リクエスト管理ＩＤが含まれるか否か、つまり、相手（ユーザＢ．Ｂ）から提案者のユーザ（ユーザＡ．Ａ）への送金リクエストが含まれるか否かを判定する。
相手のユーザの承認が必要であると判定したならば（Ｓ１５３１：ＹＥＳ）、サーバ１０の制御部１１は、一括精算することに承認するか否かを相手のユーザ（この例ではユーザＢ．Ｂ）に確認するための情報として、一括精算金額情報を含む一括精算承認確認情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１５３３）。
端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から一括精算承認確認情報を受信したか否かを判定し（Ｂ１５０）、受信したと判定したならば（Ｂ１５０：ＹＥＳ）、受信した一括精算承認確認情報を表示部２４に表示させる（Ｂ１６０）。
その後、端末２０Ｂの制御部２１は、入力部に対して一括精算を承認する入力がなされたか否かに基づいて、一括精算を承認するか否かを判定する（Ｂ１７０）。そして、承認すると判定したならば（Ｂ１７０：ＹＥＳ）、端末２０Ｂの制御部２１は、一括精算を承認することを示す一括精算承認情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１８０）。
Ｓ１５３３の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂから一括精算承認情報を受信したか否かに基づいて、相手のユーザによって一括精算が承認されたか否かを判定する（Ｓ１５３５）。そして、承認されたと判定したならば（Ｓ１５３５：ＹＥＳ）、Ｓ１５４０に処理を移す。
＜端末による第１処理）＞
端末が制御部によって実行する処理であって、第１情報と第２情報とに基づく第１処理には、限定ではなく例として、提案者のユーザ（端末のユーザ）から相手のユーザ（第１ユーザ、第２ユーザ）への送金に何らかの形で関連する処理、提案者のユーザが相手のユーザから送金された金額を受け取ること（受金すること）に何らかの形で関連する処理を含めることができる。送金や受金に直接的に関連する処理のみならず、送金や受金に間接的に関連する処理も、第１処理に含めることができる。
限定ではなく例として、少なくとも以下の処理が第１処理に含まれる。
・送金リクエストを選択する処理
・選択した送金リクエストをサーバ１０に通知する処理
・精算確認情報をサーバ１０から取得する処理、これを表示部２４に表示する処理
・精算の実行をサーバ１０に要求する処理
・精算結果情報をサーバ１０から取得する処理、これを表示部２４に表示する処理
・金額差し引き（金額相殺を含む）をサーバ１０に要求する処理
・確認用一括送金リクエストの作成をサーバ１０に要求する処理
＜端末に対する入力等＞
上記の処理では、端末に対する入力または端末のユーザによる入力を、入力部（操作部）に対する操作入力としたが、これに限定されない。
限定ではなく例として、入力部（操作部）に対する操作入力に代えて、またはこれに加えて、入力部（音入力部２５）に対する音（音声を含む。）入力を可能としてもよいし、しなくてもよい。
これは、端末に対する他の入力や端末のユーザによる他の入力についても同様である。
＜第１実施例の効果＞
本実施例によれば、限定ではなく例として、複数の送金リクエストを一括して処理することができるため、ユーザの利便性を向上させることができる。
また、限定ではなく例として、ユーザの残高を超えない範囲で送金や受金を行うことができるため、ユーザの利便性を向上させることができる。
より具体的には、本実施例は、端末２０が、自己の端末２０とは異なる第１ユーザの端末２０の第１ユーザ（限定ではなく、第１ユーザの一例）から自己の端末２０のユーザ（限定ではなく、端末のユーザの一例）への送金リクエストに関する送金リクエスト情報（限定ではなく、第１情報の一例）、または自己の端末２０のユーザから第１ユーザへの送金リクエストに関する第１送金リクエスト情報（限定ではなく、第１情報の一例）に基づく表示（限定ではなく、第１表示の一例）と、上記の第１ユーザ（限定ではなく、第２ユーザの一例）との間の第２送金リクエスト情報に基づく表示（限定ではなく、第２表示の一例）とを少なくとも表示部２４に表示する。
そして、端末２０は、上記の第１表示と第２表示とが表示された自己の端末２０に対する入力に基づいて、第１送金リクエスト情報と、第２送金リクエスト情報とに基づく第１処理（限定ではなく、第１情報と、第２情報とに基づく第１処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザから端末のユーザへの送金依頼、または端末のユーザから第１ユーザへの送金依頼に関する第１情報に基づく第１表示と、第２ユーザから端末のユーザへの送金依頼、または端末のユーザから第２ユーザへの送金依頼に関する第２情報に基づく第２表示とが表示された端末に対する入力に基づいて、送金依頼に関する複数の情報を一括して処理することが可能となり、ユーザの利便性を向上させることができる。
また、本実施例は、第１送金リクエスト情報は、相手のユーザから自己の端末２０のユーザへの送金依頼に関する情報（限定ではなく、第１ユーザから端末のユーザへの送金依頼に関する情報の一例）を含み、第２送金リクエスト情報は、自己の端末２０のユーザから相手のユーザへの送金依頼に関する情報（限定ではなく、端末のユーザから第２ユーザへの送金依頼に関する情報の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、上記の一括の処理によって、限定ではなく例として、端末のユーザが第１ユーザに送金する金額（端末のユーザが支払う金額）と、端末のユーザが第２ユーザから送金される金額（端末のユーザが受け取る金額）との差額の金額を、第１ユーザに送金する、または第２ユーザから送金されるようにすることができる。この場合、送金する金額、または送金される金額は、送金依頼に関する複数の情報を１つずつ処理する場合と比べて小さくなる（差額の金額の絶対値が小さくなる）。このため、限定ではなく１つの効果として、ユーザの残高の範囲内で処理できる可能性が高くなり、ユーザが送金を行うためにチャージやローンといった面倒な手間をかけずに済む。また、限定ではなく１つの効果として、複数の情報を一括して処理可能となるため、処理される件数の増加が見込める。
また、本実施例は、第１送金リクエスト情報は、第１送金リクエスト金額（限定ではなく、送金に関する第１金額の一例）の情報を含み、第２送金リクエスト情報は、第２送金リクエスト金額（限定ではなく、送金に関する第２金額の一例）の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とによって、送金に関する第１金額と送金に関する第２金額とを端末のユーザに知らせることができる。
また、本実施例は、第１処理は、第１送金リクエスト金額と第２送金リクエスト金額とに基づく処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第１金額と第２金額との差額分の金額に基づいて、一括精算等の処理を行うことが可能となる。
また、本実施例は、端末２０が、第２送金リクエスト情報に基づく一括精算確認情報を、サーバ１０を介して第１ユーザの端末２０（限定ではなく、第２ユーザの端末の一例）に通信Ｉ／Ｆ２２によって送信する。この場合、第１処理は、一括精算確認情報に基づく、第１ユーザによる第１処理の実行の承認に基づいて、制御部２１によって処理が実行される構成を示している。
このような構成により得られる実施例の効果の一例として、相手によって承認された場合に、第１処理を実行することができる。また、限定ではなく例として、相手によって承認されなかった場合は、第１処理を実行しないようにすることもできる。
また、本実施例は、第２ユーザは、第１ユーザである構成を示している。
このような構成により得られる実施例の効果の一例として、自己の端末２０のユーザとは異なる１人のユーザ（第１ユーザ）との間の複数の送金依頼に関する情報に基づいて、第１処理を実行することができる。
また、本実施例は、第１処理は、第２送金リクエスト金額が第１送金リクエスト金額よりも大きい場合、第２送金リクエスト金額から第１送金リクエスト金額を差し引いた金額（限定ではなく、第３金額の一例）を第１ユーザに送金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２金額と第１金額との差額分の金額を第１ユーザに送金することができるため、１つの情報に基づいて送金を行う場合と比べて支払う金額が小さくすることが可能となり、ユーザの利便性を向上させることができる。
また、本実施例は、第１送金リクエスト情報（限定ではなく、第１情報の一例）は、第１送金リクエスト金額（限定ではなく、第１金額の一例）の情報を含み、第２送金リクエスト情報（限定ではなく、第２情報の一例）は、第２送金リクエスト金額（限定ではなく、第２金額の一例）の情報を含み、第１処理は、第１送金リクエスト金額と、第２送金リクエスト金額と、自己の端末２０のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）とに基づいて制御部２１によって行われる構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高を考慮して、第１金額と、第２金額とに基づく第１処理が実行されるようにすることができる。これにより、限定ではなく例として、端末のユーザの残高が足りる場合は第１処理が実行されるが、端末のユーザの残高が足りない場合は第１処理が実行されないようにすることができる。
また、本実施例は、第１処理は、自己の端末２０のユーザによる、提案ボタンに対する操作（限定ではなく、第５表示に対する入力の一例）と、一括精算に関する相手のユーザの承認（限定ではなく、第１処理の実行に関する第１ユーザ、または第２ユーザの承認の一例）とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる第５表示に対する入力ばかりでなく、第１処理の実行に関する第１ユーザ、または第２ユーザの承認もなければ、第１処理が実行されないようにすることができる。
また、本実施例は、第１処理は、提案者のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）と、相手のユーザの電子マネー口座残高（限定ではなく、第１ユーザ、または第２ユーザの残高の一例）とに基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高ばかりでなく、第１ユーザ、または第２ユーザの残高も考慮して、第１処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザ、または第２ユーザの残高が足りる場合は第１処理が実行されるが、第１ユーザ、または第２ユーザの残高が足りない場合は第１処理が実行されないようにすることができる。
また、本実施例は、第１処理は、第１送金リクエスト情報と第２送金リクエスト情報とを含む、提案者のユーザに関する複数の送金リクエスト情報（限定ではなく、第１情報と第２情報とを少なくとも含む、端末のユーザへの送金依頼、または端末のユーザによる送金依頼に関する複数の情報の一例）のうち、提案者のユーザによる端末２０に対する入力に基づいて、第１送金リクエスト情報と第２送金リクエスト情報とに基づく処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とを少なくとも含む、端末のユーザへの送金依頼、または端末のユーザによる送金依頼に関する複数の情報のうち、端末のユーザによる端末に対する入力に基づいて、第１情報と第２情報とを適切に処理することができる。
また、本実施例は、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、相手のユーザから提案者のユーザへの送金に関する処理、または提案者のユーザから相手のユーザへの送金に関する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、同じ一人のユーザ（第１ユーザ＝第２ユーザ）を相手のユーザとして、送金依頼に関する複数の情報に基づいて、第１ユーザから端末のユーザへの送金、または端末のユーザから第１ユーザへの送金を実現することができる。
また、本実施例は、上記の送金に関する処理は、一括精算確認情報や一括精算結果情報（限定ではなく、第１情報に基づく送金依頼の処理と、第２情報に基づく送金依頼の処理とが実行されたことを示す情報の一例）を表示部２４に表示する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報に基づく送金依頼の処理と、第２情報に基づく送金依頼の処理とが実行されたことを、端末のユーザに知らせることができる。
＜第１変形例（１）＞
前述したように、相手のユーザが異なる複数のユーザである場合についても、上記の実施例の手法を同様に適用可能である。
図１－２３は、本変形例において端末２０の表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。この画面は、端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例であり、限定ではなく例として、図１－９のメインメニュー画面において送金リクエスト一覧アイコンがタップされたことに基づいて表示される画面の一例である。
現在位置表示領域ＣＬＲ１には、送金リクエスト一覧情報を表示していることを示す「送金リクエスト一覧」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、異なる複数の端末２０のユーザとの間で送受信された未処理リクエストが、限定ではなく例として、上から日付が古い順に時系列で表示されている。この例では、上から順に、ユーザＢ．Ｂからの受信済み送金リクエスト、ユーザＣ．Ｃからの受信済み送金リクエスト、ユーザＢ．Ｂからの受信済み送金リクエスト、ユーザＣ．Ｃからの受信済み送金リクエスト、ユーザＤ．Ｄからの受信済み送金リクエスト、ユーザＣ．Ｃへの送信済み送金リクエスト、・・・、が表示されている。
各々の送金リクエストの横には、タップによってチェックの「ＯＮ／ＯＦＦ」を切替可能に構成されたチェック領域ＳＲ２が設けられており、チェックを「ＯＮ」とすることでチェック領域ＳＲ２にチェックマークが表示され、そのユーザとの間のその送金リクエストを、一括精算の対象として選択することができるように構成されている。
この例では、１番目のユーザＢ．Ｂからの受信済み送金リクエスト（支払い ２，０００円）と、４番目のユーザＣ．Ｃからの受信済み送金リクエスト（支払い １，０００円）とが選択された状態が示されている。この状態で画面下部の精算ボタンＢＴ５がタップされると、この選択された２つの送金リクエストの一括精算を要求するための精算要求情報が、端末２０Ａからサーバ１０に送信される。
この例では、ユーザＡ．ＡからユーザＢ．Ｂへの送金（支払い）、および、ユーザＣ．ＣからユーザＣ．Ｃへの送金（支払い）であり、相手のユーザからの送金（受取）はないため、相手のユーザの承認は不要とすることができる。
そして、サーバ１０によって一括精算が実行されて、ユーザＡ．ＡからユーザＢ．Ｂへの「２，０００円」の送金（支払い）と、ユーザＡ．ＡからユーザＣ．Ｃへの「１，０００円」の送金（支払い）とが実現される。
本変形例は、第１ユーザは、第２ユーザとは異なるユーザである構成を示している。
このような構成により得られる変形例の効果の一例として、自己の端末２０のユーザとは異なる少なくとも２人のユーザ（第２ユーザとは異なる第１ユーザ、第２ユーザ）との間の複数の送金依頼に関する情報に基づいて、第１処理を実行することができる。
＜第１変形例（２）＞
第１実施例では、提案者のユーザが、一括精算対象とする送金リクエストを手動で選択することとしたが、これに限定されない。
提案者のユーザの端末２０が、またはサーバ１０が、一括精算対象とする送金リクエストを自動で選択するようにしてもよいし、しなくてもよい。
この提案者のユーザの端末２０、またはサーバ１０による一括精算対象とする送金リクエストの自動選択には、選択した送金リクエストを提案者のユーザに提案（サジェスト）する意味も含まれる。
具体的には、提案者の端末２０の制御部２１は、提案者のユーザの現在の電子マネー口座残高をサーバ１０に問い合わせる処理を行う。そして、提案者の端末２０の制御部２１は、サーバ１０から受信した送金リクエスト一覧情報に含まれる送金リクエストの中から、各々の送金リクエスト金額と、各々の送金リクエストの種別（受信済み送金リクエスト（支払い）／送信済み送金リクエスト（受取））とに基づいて、限定ではなく例として、提案者のユーザの現在の電子マネー口座残高が支払い金額の上限となるように、１または複数の送金リクエストを選択する。つまり、提案者のユーザの現在の電子マネー口座残高がマイナスとならない範囲で、１または複数の送金リクエストを選択する。
なお、サーバ１０の制御部１１が送金リクエストを選択する場合は、第１の送金リクエスト管理データ１５７Ａに記憶されている送金リクエストのデータに基づいて同様の処理を行えばよい。
本変形例は、第１処理は、提案者のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）に基づいて、複数の送金リクエスト情報（限定ではなく、複数の情報の一例）のうち、少なくとも第１送金リクエスト情報と第２送金リクエスト情報とが選択され、この第１送金リクエスト情報と第２送金リクエスト情報とに少なくとも基づく処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高を考慮して、複数の情報のうちの少なくとも第１情報と第２情報とが自動で選択されて、精算が行われるようにすることができる。この場合、端末のユーザが情報を手動で選択せずに済むため、ユーザの利便性を向上させることができる。
＜第１変形例（３）＞
第１実施例の＜表示画面＞で示した表示画面のユーザインタフェイスは、あくまでも一例であり、これらに限定されるものではない。
図１－２４は、端末２０の表示部２４に表示される表示画面のＵＩ（ユーザインタフェイス）の別例を示す図である。この表示画面は、端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例であり、図１－１２に対応する送金リクエスト一覧画面の別例を示す図である。
この表示画面では、ユーザＣ．Ｃとの送金リクエストの一覧として、受信済み送金リクエストと、送信済み送金リクエストとが、テーブル形式で表示されている。この例では、テーブルの左欄には受信済み送金リクエストの一覧が、テーブルの右欄には送信済み送金リクエストの一覧がそれぞれ表示されている。
受信済み送金リクエストの一覧と、送信済み送金リクエストの一覧とのそれぞれについて、各々の送金リクエストの表示欄には、その送金リクエストの受信日時／送信日時、支払い事由、リクエスト種別「支払い／受取」、送金リクエスト金額等の情報が表示されている。
このような表示を行うことで、受信済み送金リクエストと送信済み送金リクエストとを対比しながら確認することが可能となり、ユーザの利便性を向上させることができる。
また、上記の実施例では、未処理の送金リクエストが送金リクエスト一覧画面に表示されることとしたが、これに限定されない。
この他にも、限定ではなく例として、支払いアプリケーションのおしらせ画面や、支払いアプリケーションのプロフィール画面、支払いアプリケーションのトップ画面等の画面から、未処理の送金リクエストの一覧を確認することができるようにしてもよいし、しなくてもよい。
＜第１変形例（４）＞
上記の実施例では、一括精算において相手のユーザの承認を必要とするケースについて説明した。しかし、送金リクエストをユーザの操作に基づいて作成することができないように構成されたシステムであれば、相手のユーザの承認を不要とすることもできる。
このようなシステムとしては、限定ではなく例として、ユーザの電子マネーや電子決済と、送金リクエストとを紐づけて管理するシステムが考えられる。より具体的には、一のユーザによって電子マネーによる電子決済が行われた後、その決済金額のうちの少なくとも一部の金額を立て替えた金額（立替金額）として、送金リクエストによって別のユーザに請求することのできるシステムが考えられる。このシステムの用途としては、限定ではなく例として、複数のユーザで割り勘を行うような場合である。
この場合、サーバ１０は、電子決済を行った後、ユーザ操作に従って立替金額を送金リクエスト金額とする送金リクエストを作成して、別のユーザの端末２０に送信するようにすることができる。
かかるシステムでは、一括精算を行おうとするユーザは、一度は自分の電子マネー口座残高を消費して電子決済を行う必要があるため、上記の一括処理が悪用されるリスクを限りなく低減させることができる。
＜第１変形例（５）＞
一括精算を行うにあたり、一のユーザが相手のユーザから支払いを行うように提案された精算提案（一のユーザが相手のユーザに支払う必要のある精算提案）を、相手のユーザから送金を依頼された新規の送金リクエストとし、この新規の送金リクエストが、一のユーザの未処理の受信済み送金リクエストとして、サーバ１０側で管理されるようにしてもよい。
具体的には、限定ではなく例として、図１－１３の例において、ユーザＣ．Ｃ（一のユーザ）がユーザＡ．Ａ（相手のユーザ）から「７，０００円」の支払いを行うように提案された精算提案を、ユーザＡ．Ａから「７，０００円」の送金を依頼された新規の送金リクエストとし、この送金リクエストが、ユーザＣ．Ｃの「支払い ７，０００円」の未処理の受信済み送金リクエストとしてサーバ１０側で管理されるようにしてもよい。
また、限定ではなく例として、端末２０が表示部２４に表示する送金リクエスト一覧画面等において、上記のようにして新規に作成された受信済み送金リクエストがタップされることに基づいて、その受信済み送金リクエストの作成に寄与した送金リクエスト（その受信済み送金リクエストが作成される要因となった送金リクエスト）に関する情報（限定ではなく例として、送金リクエストの種別、送金リクエスト金額、日時、事由等の詳細情報）を、時間軸方向に階層的に表示させることを可能にするなどして、一の送金リクエストに関する履歴をユーザが辿れるようにすることもできる。
具体的には、上記のユーザＣ．Ｃの「支払い ７，０００円」の未処理の受信済み送金リクエストがタップされると、この受信済み送金リクエストの作成に寄与した送金リクエスト、限定ではなく例として、図１－１４の例における３番目の受信済み送金リクエスト「支払い １０，０００円」と４番目の送信済み送金リクエスト「受取 ３，０００円」との各々の送金リクエストに関する情報が表示されるようにしてもよい。
なお、この手法は、送信済み送金リクエストについても同様に適用可能である。
＜第１変形例（６）＞
第１実施例では、第１ユーザおよび第２ユーザを、一般ユーザである端末２０のユーザとして説明したが、これに限定されない。
第１ユーザおよび第２ユーザのうちの少なくともいずれか一方のユーザを、一般ユーザではなく、店舗等の事業者のユーザとしてもよいし、しなくてもよい。この場合における事業者には、限定ではなく例として、商品の販売（サービスの提供を含む。）を行う事業者や貸金業を営む事業者など、送金依頼によって端末２０のユーザに対して金銭の請求を行うことが想定される事業者（店舗）が含まれる。
この場合、上記の実施例において、これらの事業者が、支払いサービス（支払いアプリケーション）のアカウントを取得する。そして、このアカウントを用いて、サーバ１０を介して、金銭の請求先のユーザ（送金リクエスト先ユーザ）の端末２０に対して、送金リクエスト情報や送金リマインド情報を送信するようにすることができる。
なお、上記の事業者（店舗）が取得するアカウントは、端末２０のユーザ用のアカウントである一般アカウントとしてもよいし、事業者用のアカウントとしてもよい。
本変形例は、第１ユーザおよび第２ユーザのうちの少なくともいずれか一方のユーザは、送金リクエストに関する商品の販売を行う店舗である構成を示している。
このような構成により得られる変形例の効果の一例として、一般のユーザばかりでなく、店舗のユーザも、端末のユーザに対して送金依頼を行うことのできるユーザとすることができる。
＜第１変形例（７）＞
端末２０のユーザによっては、相手のユーザに対して一括精算を提案することに気まずさを感じ、躊躇してしまう場合が想定される。限定ではなく例として、相手のユーザが自分よりも目上の人であったり、相手のユーザが親友など特に親しい関係にある人であるような場合である。
そこで、一括提案の提案元のユーザを、端末２０のユーザに代えて、業務用アカウントを利用するユーザとすることも可能である。
業務用アカウントは、限定ではなく例として、そのサービス（上記の例では支払いサービス）において公式のアカウント（以下、「公式アカウント」と称し、適宜「ＯＡ：Official Account」と表現する。）を有するユーザである。
一例として、公式アカウントを有するユーザは、限定ではなく例として、支払いサービスの事業者やメッセージングサービスの事業者とすることができる。
この場合、サーバ１０は、一括精算の提案元のユーザを、支払いサービスの事業者やメッセージングサービスの事業者として、相手のユーザの端末２０に一括精算承認確認情報を送信するようにすることができる。
本変形例は、一括精算の提案者のユーザを、公式アカウント（限定ではなく、業務用アカウントの一例）を利用するユーザとする構成を示している。
このような構成により得られる変形例の効果の一例として、一括精算を希望するユーザ本人に代わって、業務用アカウントを利用するユーザに一括精算の要求を行わせることができるため、ユーザの利便性を向上させることができる。
＜第２実施例＞
第２実施例は、第１実施例で説明した一括精算においてユーザの残高が不足している場合の処理に関する実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図２－１は、本実施例において端末２０の表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。
この送金リクエスト一覧画面は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される画面であり、相手をユーザＢ．Ｂとする送金リクエストの一覧画面である。
画面上部の現在位置表示領域ＣＬＲ１には、ユーザＢ．Ｂとの間の未処理リクエストを表示していることを示す「Ｂ．Ｂとの送金リクエスト」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、相手をユーザＢ．Ｂとする送金リクエストが一覧表示されている。この例では、１番目の受信済み送金リクエストと、２番目の受信済み送金リクエストと、４番目の送信済み送金リクエストとが選択され、画面下部の電子マネー口座残高表示領域ＷＢＲ２内の精算内容確認領域ＡＣＲ３に、自分（ユーザＡ．Ａ）の電子マネー口座残高の変化が示されている。この例では、自分の現在の電子マネー口座残高が「５００円」であり、一括精算によって、自分の電子マネー口座残高が「０円」となることが示されている。この場合は、残高が足りるため、一括精算することが可能である。
また、電子マネー口座残高表示領域ＷＢＲ２の、「ウォレット残高」の文字の右側には、丸にプラスのアイコンで示される、ウォレット残高にチャージを実行するためのチャージボタンが加えて表示されている。
図２－２は、図２－１の画面と同様の送金リクエスト一覧画面を示す図であるが、選択された送金リクエストが異なっている。
この例では、１番目の受信済み送金リクエストと、２番目の受信済み送金リクエストと、４番目の送信済み送金リクエストとに加えて、３番目の受信済み送金リクエストが選択され、画面下部の電子マネー口座残高表示領域ＷＢＲ２内の精算内容確認領域ＡＣＲ４に、自分（ユーザＡ．Ａ）の電子マネー口座残高の変化が示されている。この例では、自分の現在の電子マネー口座残高が「５００円」であり、一括精算によって、自分の電子マネー口座残高が「－５００円」となることが示されている。この例では、「支払い １０００円」であるのに対し、自分の現在の電子マネー口座残高が「５００円」であるため、「５００円」不足していることになり、一括精算することができない。
この場合、精算内容確認領域ＡＣＲ４内には、電子マネー口座残高が不足していることを示す残高不足情報として、限定ではなく例として、警告マークとともに、「残高不足です！」のテキストが表示されている。この状態で、提案ボタンＢＴ６がタップされると、図２－３に示すような表示がなされる。
図２－３では、図２－２の送金リクエスト一覧画面の画面中央部に、電子マネー口座残高へのチャージを行うか否かをユーザに確認するための情報として、チャージ確認情報ＣＧ１がポップアップ表示されている。具体的には、「不足額５００円をチャージしますか？」というテキストとともに、チャージすることに承認するためのＯＫボタンと、チャージをキャンセルするためのキャンセルボタンとが表示されている。
この状態でＯＫボタンがタップされると、サーバ１０によって、ユーザＡ．Ａの電子マネー口座残高に「５００円」をチャージするチャージ処理が実行される。そして、その後、一括精算が行われる。
＜処理＞
図２－４～図２－５は、本実施例においてサーバ１０の制御部１１が実行する精算処理の一例である第３の精算処理の流れの一例を示すフローチャートである。
Ｓ１５２０においていずれかのユーザの電子マネー口座残高がマイナスになると判定したならば（Ｓ１５２０：ＹＥＳ）、サーバ１０の制御部１１は、電子マネー口座残高がマイナスになるユーザは提案者のユーザであるか否かを判定する（Ｓ１５５０）。そして、提案者のユーザであると判定したならば（Ｓ１５５０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、一括精算金額情報と、残高不足情報とを含む一括精算確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５５１）。
その後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから精算実行要求情報を受信したか否かに基づいて、一括精算の実行が要求されたか否かを判定する（Ｓ１５５３）。そして、要求されたと判定したならば（Ｓ１５５３：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＡ．Ａの電子マネー口座残高にチャージを行うか否かを判定する（Ｓ１５５５）。具体的には、限定ではなく例として、前述したチャージ確認情報を端末２０Ａに送信して表示部２４に表示させ、端末２０Ａからチャージを承認するための情報を受信したか否かを判定する。
チャージを行うと判定したならば（Ｓ１５５５：ＹＥＳ）、サーバ１０の制御部１１は、チャージ処理を実行する（Ｓ１５５７）。具体的には、あらかじめ登録されたユーザＡ．Ａの銀行口座やクレジットカードによって、一括精算の不足分の金額を、ユーザＡ．Ａの電子マネー口座残高に補充する処理を実行する。そして、サーバ１０の制御部１１は、Ｓ１５３１に処理を移す。
一方、電子マネー口座残高がマイナスになるユーザが提案者のユーザではない、つまり、電子マネー口座残高がマイナスになるユーザが相手のユーザであると判定したならば、（Ｓ１５５０：ＮＯ）サーバ１０の制御部１１は、一括精算金額情報を含む一括精算確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５５９）。
その後、端末２０Ａから一括精算の実行が要求されたと判定したならば（Ｓ１５６１：ＹＥＳ）、サーバ１０の制御部１１は、一括精算金額情報と残高不足情報とを含む一括精算承認確認情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１５６３）。
その後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂから一括精算承認情報を受信したか否かに基づいて、一括精算が承認されたか否かを判定する（Ｓ１５６５）。
一括精算が承認されたと判定したならば（Ｓ１５６５：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＢ．Ｂの電子マネー口座残高にチャージを行うか否かを判定する（Ｓ１５６７）。具体的には、限定ではなく例として、前述したチャージ確認情報を端末２０Ｂに送信して表示部２４に表示させ、端末２０Ｂからチャージを承認するための情報を受信したか否かを判定する。
チャージを行うと判定したならば（Ｓ１５６７：ＹＥＳ）、サーバ１０の制御部１１は、チャージ処理を実行する（Ｓ１５６９）。具体的には、あらかじめ登録されたユーザＢ．Ｂの銀行口座やクレジットカードによって、一括精算の不足分の金額を、ユーザＢ．Ｂの電子マネー口座残高に補充する処理を実行する。
そして、サーバ１０の制御部１１は、Ｓ１５４０に処理を移す。
Ｓ１５５３において一括精算の実行が要求されなかったと判定した場合（Ｓ１５５３：ＮＯ）、またはＳ１５５５においてチャージを行わないと判定した場合（Ｓ１５５５：ＮＯ）、サーバ１０の制御部１１は、第３の精算処理を終了する。
また、Ｓ１５６１において一括精算の実行が要求されなかったと判定した場合（Ｓ１５６１：ＮＯ）、Ｓ１５６５において一括精算が承認されなかったと判定した場合（Ｓ１５６５：ＮＯ）、またはＳ１５６７においてチャージを行わないと判定した場合（Ｓ１５６７：ＮＯ）、サーバ１０の制御部１１は、第３の精算処理を終了する。
なお、Ｓ１５４０の処理を実行する前に、再度Ｓ１５２０と同様の処理を実行し、いずれかのユーザの電子マネー口座残高がマイナスになると判定したならば、Ｓ１５４０の処理を保留するようにしてもよいし、そうしなくてもよい。
＜第２実施例の効果＞
本実施例は、第１送金リクエスト情報（限定ではなく、第１情報の一例）は、第１送金リクエスト金額（限定ではなく、第１金額の一例）の情報を含み、第２送金リクエスト情報（限定ではなく、第２情報の一例）は、第２送金リクエスト金額（限定ではなく、第２金額の一例）の情報を含み、第１処理は、第１送金リクエスト金額と、第２送金リクエスト金額と、自己の端末２０のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）とに基づいて制御部２１によって行われる構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高を考慮して、第１金額と、第２金額とに基づき第１処理を適切に実行することができる。
また、本実施例は、第１送金リクエスト金額と第２送金リクエスト金額との合計が、自己の端末２０のユーザの電子マネー口座残高を超え、自己の端末２０のユーザから送金を行う場合、残高不足情報の表示（限定ではなく、第１処理が実行できないことを示す第３表示の一例）が自己の端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と第２金額との合計が端末のユーザの残高を超えているにも関わらず、端末のユーザから送金を行うことになるような場合に、第１処理を実行できないことを端末のユーザに知らせることができる。
また、本実施例は、第１送金リクエスト金額と第２送金リクエスト金額との合計が、自己の端末２０のユーザの電子マネー口座残高を超え、自己の端末２０のユーザから送金を行う場合、自己の端末２０のユーザの電子マネー口座残高へのチャージ確認情報の表示（限定ではなく、残高にチャージすることを示す第４表示の一例）が自己の端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と第２金額との合計が端末のユーザの残高を超えているにも関わらず、端末のユーザから送金を行うことになるような場合に、残高にチャージして不足分の金額を補うことが可能であることを端末のユーザに知らせることができる。
＜第２変形例＞
第２実施例において、端末２０が、限定ではなく例として、送金リクエスト一覧画面を表示部２４に表示する際に、自分の電子マネー口座残高にチャージを行うことができることを示す情報（チャージ情報）や、ローン（融資）を行うことができることを示す情報（ローン情報）を、表示部２４に併せて表示させるようにしてもよいし、しなくてもよい。
ローンを行う事業者としては、限定ではなく例として、支払いサービスの事業者（支払いアプリケーションの事業者）／メッセージングサービスの事業者（メッセージングアプリケーションの事業者）や、銀行等の金融機関とすることができる。
この場合、ユーザによってローンを依頼する入力がなされたことに基づいて、サーバ１０が、一定の融資額の範囲内で、電子マネーの形で（電子マネーを手段として）、金銭を融資することができる。または、サーバ１０が、提携している金融機関のサーバと通信を行って融資を依頼して、融資を認可してもらうようにすることができる。
なお、この場合、電子マネー口座残高をマイナスとして扱ってもよいし、プラスとして扱ってもよい。
ローンによって精算を行ったならば、限定ではなく例として、定められた返済期限までに、ユーザに融資額の返済を行わせるようにすることができる。
なお、この場合における返済の方法としては、一般的なローンと同様の返済の方法を適用するなどすることができる。
本変形例は、端末２０が、第１送金リクエスト情報に基づく表示（限定ではなく、第１表示の一例）と、第２送金リクエスト情報に基づく表示（限定ではなく、第２表示の一例）と、チャージ情報の表示（限定ではなく、残高のチャージに関する表示の一例）、またはローン情報（限定ではなく、ローンを行うことに関する表示の一例）とを、表示部２４に表示する構成を示している。
このような構成により得られる変形例の効果の一例として、第１情報に基づく第１表示と、第２情報に基づく第２表示とを表示する際に、残高のチャージに関する表示、またはローンを行うことに関する表示を併せて表示することで、ユーザが残高のチャージやローンを容易に行うことを可能とすることができる。
＜第３実施例＞
第３実施例は、第２実施例に関連して、一括精算の実行に関連する表示の表示態様を変更する実施例である。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図３－１は、本実施例において端末２０の表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。
この送金リクエスト一覧画面は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される図２－１の画面に対応する画面であり、ユーザＡ．Ａの電子マネー口座残高が足りている場合に表示される画面である。
画面下部の精算内容確認領域ＡＣＲ５には、一括精算によって、自分の電子マネー口座残高が「０円」となるが、一括精算は可能なことが示されている。
この場合、提案ボタンＢＴ７に対する操作（タップ）が行われると、端末２０Ａはその一括精算を提案する操作を受け付ける。
図３－２は、本実施例において端末２０の表示部２４に表示される送金リクエスト一覧画面の別例を示す図である。
この送金リクエスト一覧画面は、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される図２－２の画面に対応する画面であり、ユーザＡ．Ａの電子マネー口座残高が不足している場合に表示される画面である。
この画面では、ユーザＡ．Ａの電子マネー口座残高が不足していることに基づき、画面下部の精算内容確認領域ＡＣＲ５内に表示される提案ボタンＢＴ７が、図３－１とは異なる表示態様で表示されている。具体的には、限定ではなく例として、提案ボタンＢＴ７がグレーアウトして表示されており、提案ボタンＢＴ７に対する操作（タップ）を行っても、端末２０Ａがその操作を受け付けないようになっている。
なお、図３－２において、電子マネー口座残高表示領域ＷＢＲ１に電子マネー口座へのチャージボタンを表示させ、ユーザにチャージを促すようにしてもよいし、しなくてもよい。
また、支払いサービスを運営する事業者が金融機関と提携している場合、その金融機関からの融資を受け、電子マネー口座へチャージするためのローン機能ボタンを表示するようにしてもよいし、しなくてもよい。
＜第３実施例の効果＞
本実施例は、端末２０が、提案ボタンの表示（限定ではなく、第１処理の実行に関する第５表示の一例）を表示部２４に表示する。この場合、提案ボタンの表示は、第１送金リクエスト金額と、第２送金リクエスト金額と、自分の電子マネー口座残高とに基づいて、表示態様が変更される構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と、第２金額と、端末のユーザの残高とに基づいて、第１処理の実行に関する第５表示の表示態様が変更されるため、限定ではなく例として、端末のユーザの残高を考慮して、第１処理が実行できないことを端末のユーザに簡易かつ適切に知らせることができる。
また、本実施例は、提案ボタンの表示は、第１送金リクエスト金額と第２送金リクエスト金額との合計が、自己の端末２０のユーザの電子マネー口座残高を超え、自己の端末２０のユーザから送金を行う場合、操作を受け付けないことを示す表示態様（限定ではなく、第１処理が実行できないことを示す表示態様の一例）で自己の端末２０の表示部２４に表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と第２金額との合計が端末のユーザの残高を超えているにも関わらず、端末のユーザから送金を行うことになるような場合に、第１処理が実行できないことを端末のユーザに知らせることができる。
＜第４実施例＞
第４実施例は、一括精算の処理の方式（アルゴリズム）に関する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜処理＞
サーバ１０が実行する一括精算には、限定ではなく例として、以下の２つの方式を含めることができる。
（１）回分精算（バッチ精算）
（２）逐次精算（シーケンシャル精算）
（１）の回分精算は、限定ではなく例として、選択された２以上の送金リクエストを一度に処理する一括精算の方式である。
この手法では、サーバ１０の制御部１１は、選択された各々の送金リクエストの送金リクエスト金額と、その種別（受信済み送金リクエスト／送信済み送金リクエスト）とに基づいて、最終的な一括精算金額を算出する。
この場合、算出した一括精算金額に基づいて精算を行っても、提案者の端末２０のユーザの電子マネー口座残高と、相手のユーザの電子マネー口座残高とが両方ともマイナスとならない場合は、精算ＯＫとする。
一方、算出した一括精算金額に基づいて精算を行うと、提案者の端末２０のユーザの電子マネー口座残高と、相手のユーザの電子マネー口座残高とのいずれか一方がマイナスとなる場合は、精算ＮＧとする。
（２）の逐次精算は、限定ではなく例として、選択された２以上の送金リクエストを逐次的に処理していく一括精算の方式である。
この手法では、サーバ１０の制御部１１は、選択された２以上の送金リクエストについて、各々の送金リクエスト金額と、その種別（受信済み送金リクエスト／送信済み送金リクエスト）とに基づいて、精算金額の算出と、提案者のユーザの電子マネー口座残高および相手のユーザの電子マネー口座残高の更新とを含む逐次処理を繰り返す。
逐次処理の途中で、提案者の端末２０のユーザの電子マネー口座残高と、相手のユーザの電子マネー口座残高とのいずれか一方がマイナスとなる場合は、その順序での精算をＮＧとする。そして、送金リクエストを処理する順序を異ならせて再度逐次処理を頭から行う。
一方、最後の送金リクエストまで逐次処理を行った結果、提案者の端末２０のユーザの電子マネー口座残高と、相手のユーザの電子マネー口座残高とのうちの少なくともいずれか一方がマイナスとならない場合は、精算ＯＫとし、その順序で精算を行う。
なお、送金リクエストを処理する順序を異ならせて総当りしても、逐次処理の途中で、提案者の端末２０のユーザの電子マネー口座残高と、相手のユーザの電子マネー口座残高とのいずれか一方がマイナスとなる場合、逐次精算は実行できないため、精算ＮＧとすることができる。
＜表示画面＞
前述した図３－１の例を参照して、回分精算と逐次精算との違いについて説明する。
ここでは、以下の２つのケースで考える。
（ケース１）ユーザＡ．Ａの現在の電子マネー口座残高＝５００円、ユーザＢ．Ｂの現在の電子マネー口座残高＝１，５００円
（ケース２）ユーザＡ．Ａの現在の電子マネー口座残高＝５００円、ユーザＢ．Ｂの現在の電子マネー口座残高＝１，０００円
まず、（ケース１）について説明する。
（１）回分精算を適用する場合
回分精算を適用する場合は、図３－１で選択された、１番目の受信済み送金リクエストと、２番目の受信済み送金リクエストと、４番目の送信済み送金リクエストとを同時に処理することになる。
この場合、一括精算は、「支払い ２，０００円」と、「支払い ５００円」と、「受取 ２，０００円」とで「支払い ５００円」（ユーザＡ．ＡからユーザＢ．Ｂに５００円の支払い）となる。
ユーザＡ．Ａの現在の電子マネー口座残高は「５００円」であり、ユーザＡ．Ａの残高はマイナスとならないため、回分精算を行えば、ユーザＢ．Ｂの電子マネー口座残高に関わらず、精算が可能となる。
（２）逐次精算を適用する場合
逐次精算を適用する場合は、図３－１で選択された、１番目の受信済み送金リクエストと、２番目の受信済み送金リクエストと、４番目の送信済み送金リクエストとを、１つずつ処理していくことになる。
限定ではなく例として、２番目の受信済み送金リクエスト→４番目の送信済み送金リクエスト→１番目の受信済み送金リクエストの順序で処理する場合を考える。
まず、２番目の受信済み送金リクエストは、ユーザＡ．ＡからユーザＢ．Ｂへの「５００円」の支払いであるため、この精算が行われると、ユーザＡ．Ａの電子マネー口座残高は「５００円→０円」となり、ユーザＢ．Ｂの電子マネー口座残高は「１，５００円→２，０００円」となる。
次に、４番目の送信済み送金リクエストは、ユーザＡ．ＡがユーザＢ．Ｂから「２，０００円」の受取であるため、この精算が行われると、ユーザＡ．Ａの電子マネー口座残高は「０円→２，０００円」となり、ユーザＢ．Ｂの電子マネー口座残高は「２，０００円→０円」となる。
最後に、１番目の受信済み送金リクエストは、ユーザＡ．ＡからユーザＢ．Ｂへの「２，０００円」の支払いであるため、この精算が行われると、ユーザＡ．Ａの電子マネー口座残高は「２，０００円→０円」となり、ユーザＢ．Ｂの電子マネー口座残高は「０円→２，０００円」となる。
ユーザＢ．Ｂの現在の電子マネー口座残高は「１，５００円」であるため、上記の精算によって、結果的に、ユーザＢ．ＢはユーザＡ．Ａから「５００円」を受け取ることになる。
この例では、ユーザＡ．Ａの電子マネー口座残高と、ユーザＢ．Ｂとの電子マネー口座残高とがいずれもマイナスとならないため、逐次精算によっても、精算が可能となる。
次に、（ケース２）について説明する。
（１）回分精算を適用する場合
回分精算を適用する場合は、（ケース１）と同じである。
つまり、ユーザＡ．Ａの現在の電子マネー口座残高は「５００円」であり、ユーザＡ．Ａの残高はマイナスとならないため、回分精算を行えば、ユーザＢ．Ｂの電子マネー口座残高に関わらず、精算が可能となる。
（２）逐次精算を適用する場合
逐次精算を適用する場合は、（ケース２）と同様に、図３－１で選択された、１番目の受信済み送金リクエストと、２番目の受信済み送金リクエストと、４番目の送信済み送金リクエストとを、１つずつ処理していくことになる。
しかしながら、（ケース２）では、（ケース１）とは異なり、ユーザＢ．Ｂの現在の電子マネー口座残高が「１，０００円」であることに起因して、図３－１で選択された、１番目の受信済み送金リクエスト、２番目の受信済み送金リクエスト、４番目の送信済み送金リクエストをどのような順序で処理したとしても、ユーザＡ．Ａの電子マネー口座残高と、ユーザＢ．Ｂとの電子マネー口座残高とのいずれもマイナスとならないように精算することはできない。
以上のことから、（ケース１）では、回分精算、逐次精算のいずれによっても精算が可能であるが、（ケース２）では、回分精算による精算は可能であるが、逐次精算による精算はできないことになる。
なお、上記の両方のケースにおいて、限定ではなく例として、支払いサービスを運営する事業者が金融機関と提携している場合、一時的にユーザの電子マネー口座の残高不足を口座残高のマイナス値として許容することで、精算を可能にしてもよいし、そうしなくてもよい。
図４－１は、上記の（ケース１）で逐次精算を適用した場合に端末２０Ｂの表示部２４に表示されるおしらせ画面の一例を示す図である。
おしらせ画面の上部には、現在位置表示領域ＣＬＲ３が構成されており、支払いアプリケーションに関するおしらせを表示していることを示す「おしらせ」の文字が表示されている。
現在位置表示領域ＣＬＲ３の下のおしらせ情報表示領域ＮＴＲ３には、ユーザＡ．Ａからの提案に基づきサーバ１０から端末２０Ｂに送信された一括精算承認確認情報が表示されている。
（ケース１）では逐次精算による精算が可能であるため、一括精算承認確認情報に含まれる精算ボタンＢＴ８が、操作を受付可能な状態で表示されている。
それに対し、図４－２は、上記の（ケース２）で逐次精算を適用した場合に端末２０Ｂの表示部２４に表示されるおしらせ画面の一例を示す図である。
このおしらせ画面に表示される情報は、図４－１と同様であるが、（ケース２）では逐次精算による精算ができないため、一括精算承認確認情報に含まれる精算ボタンＢＴ８がグレーアウトして表示されており、精算ボタンに対する操作（タップ）を行っても、端末２０Ｂがその操作を受け付けないようになっている。
＜第５実施例＞
第５実施例は、前述した一括処理のうちの「リクエスト相殺」に関する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
前述したように、選択された受信済み送金リクエストの送金リクエスト金額（送金することになる金額）と、選択された送信済み送金リクエストの送金リクエスト金額（受金することになる金額）とが同じ金額である場合は、一括精算によって金額を相殺させることが可能である。
しかし、このような場合に、一括精算を行う代わりに、リクエスト相殺を行うようにすることも可能である。
リクエスト相殺とは、限定ではなく例として、処理対象として選択された送金リクエスト同士を互いに消し合って、それらの送金リクエストをなくすこと、それらの送金リクエストのデータを削除すること、を意味する。
＜表示画面＞
図５－１は、本実施例においてユーザＡ．Ａの端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。この送金リクエスト一覧画面は、相手のユーザをユーザＢ．Ｂとする画面である。
この送金リクエスト一覧画面では、１番目の受信済み送金リクエスト（支払い ２，０００円）と、４番目の送信済み送金リクエスト（受取 ２，０００円）とが選択された状態が示されている。
画面下部の精算内容確認領域ＡＣＲ６内には、ユーザＡ．Ａの現在の電子マネー口座残高と、ユーザＡ．Ａの精算後の電子マネー口座残高とが表示されている。選択された上記の２つの送金リクエストに基づき一括精算が行われると、金額相殺される。このため、この例では、ユーザＡ．Ａの現在の電子マネー口座残高と、ユーザＡ．Ａの精算後の電子マネー口座残高とが同じ金額（５００円）となっている。
また、その下には、「リクエストの相殺を提案しますか？」のテキストとともに、提案ボタンと、キャンセルボタンとが表示されている。
限定ではなく例として、提案ボタンがタップされると、リクエスト相殺を要求するための情報が端末２０Ａからサーバ１０に送信される。そして、サーバ１０によってリクエスト相殺処理が実行されて、選択された２つの送金リクエストのデータは削除される。
＜処理＞
（１）処理の一例
図５－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ｓ１４０において端末２０Ａからリクエスト選択情報を受信したと判定したならば（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、リクエスト相殺処理を実行する（Ｓ３５０）。
リクエスト相殺処理では、サーバ１０の制御部１１は、端末２０Ａによって選択された送金リクエストに基づいて一括精算金額を算出し、算出した一括精算金額に基づいて、送金リクエストを相殺できるか否かを判定する。そして、相殺できると判定したならば、サーバ１０の制御部１１は、端末２０Ａにリクエスト相殺確認情報を送信する。
端末２０Ａでは、リクエスト相殺確認情報が表示部２４に表示され（Ａ３５０）、この表示に対する入力に基づいてリクエスト相殺実行要求を行うと判定されると（Ａ３６０：ＹＥＳ）、端末２０Ａからサーバ１０に対してリクエスト相殺実行要求情報が送信される（Ａ３７０）。
サーバ１０の制御部１１は、端末２０Ａからリクエスト相殺実行要求情報を受信したことに基づいて、リクエスト相殺を実行する。具体的には、相殺の対象とする送金リクエストのデータを、第１の送金リクエスト管理データ１５７Ａから削除する。
なお、送金リクエストのデータを削除せずに、相殺の対象とする送金リクエストの送金済みフラグを「ＯＮ」にしてもよい。
そして、サーバ１０の制御部１１は、リクエスト相殺処理を終了する。
その後、サーバ１０の制御部１１は、リクエスト相殺結果が「ＯＫ」であったか否かを判定する（Ｓ３７０）。そして、「ＯＫ」であったと判定したならば（Ｓ３７０：ＹＥＳ）、サーバ１０の制御部１１は、リクエスト相殺結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ３９０）。そして、サーバ１０の制御部１１は、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０からリクエスト相殺結果情報を受信すると、端末２０Ａの制御部２１は、受信したリクエスト相殺結果情報を表示部２４に表示させる（Ａ３９０）。
そして、端末２０Ａの制御部２１は、処理を終了する。
同様に、通信Ｉ／Ｆ２２によってサーバ１０からリクエスト相殺結果情報を受信すると、端末２０Ｂの制御部２１は、受信したリクエスト相殺結果情報を表示部２４に表示させる（Ｂ３９０）。
そして、端末２０Ｂの制御部２１は、処理を終了する。
（２）処理の別例
上記のリクエスト相殺を行う場合に、相手のユーザの承認を必要とすることもできる。相手のユーザの承認を必要とするケースは、一括精算で説明したケースと同様である。
この場合の処理は、一括精算において相手のユーザの承認を必要とする場合の処理（限定ではなく例として、図１－２１～図１－２２の処理）に倣って同様に構成することができるため、図示および詳細な説明を省略する。
＜第５実施例の効果＞
本実施例は、第１処理は、第１送金リクエスト情報と第２送金リクエスト情報とを含む、提案者のユーザに関する複数の送金リクエスト情報（限定ではなく、第１情報と第２情報とを少なくとも含む、端末のユーザへの送金依頼、または端末のユーザによる送金依頼に関する複数の情報の一例）のうち、提案者のユーザによる端末２０に対する入力に基づいて、第１送金リクエスト情報と第２送金リクエスト情報とに基づく処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とを少なくとも含む、端末のユーザへの送金依頼、または端末のユーザによる送金依頼に関する複数の情報のうち、端末のユーザによる端末に対する入力に基づいて、第１情報と第２情報とを適切に処理することができる。
また、本実施例は、第１送金リクエスト情報と第２送金リクエスト情報とは、同じ送金リクエスト金額の情報であり、第１処理は、第１送金リクエスト情報と第２送金リクエスト情報とに基づき、第１送金リクエスト情報と第２送金リクエスト情報とをリクエスト相殺（限定ではなく、第１情報と第２情報との相殺の一例）する処理である構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とが同じ金額の情報である場合に、これらの情報を相殺することができる。その結果、第１情報による送金依頼元のユーザと、第２情報による送金依頼元のユーザとの両者の利便性を向上させることができる。
＜第５変形例＞
第５実施例において、処理対象として選択された送金リクエストの送金リクエスト金額が相殺されない場合に、差額分の金額を送金リクエスト金額とする、金額差し引きの結果の正負の符号によって種別（支払い／受け取り）が定まる新たな送金リクエストを作成するようにしてもよいし、しなくてもよい。
＜第６実施例＞
第６実施例は、前述した一括処理のうちの「一括送金リクエストの作成」に関する実施例である。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図６－１は、本実施例において端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例を示す図である。
この画面上部の現在位置表示領域ＣＬＲ１には、ユーザＤ．Ｄとの間の未処理リクエストを表示していることを示す「Ｄ．Ｄとの送金リクエスト」の文字が表示されている。
また、現在位置表示領域ＣＬＲ１には、ユーザＤ．Ｄとの間の未処理リクエストのうち、１番目～４番目の送金リクエストが選択された状態が示されている。
選択された１番目～４番目の送金リクエストを一括精算する場合、一括精算は「支払い １，１００円」となり、ユーザＡ．ＡからユーザＤ．Ｄに対して「１，１００円」を支払うことになる。しかし、この例では、ユーザＡ．Ａの現在の電子マネー口座残高は「５００円」であるため、支払い金額が「６００円」不足することになる。
そこで、本実施例では、サーバ１０が、一括精算を行った場合の支払いの不足分の金額に基づいて、一括送金リクエストを作成する。
ただし、本実施例では、一括送金リクエストは作成されるが、一括精算は行われない。
具体的には、画面下部の精算内容確認領域ＡＣＲ７には、自分の現在の電子マネー口座残高、および、精算を行った場合の自分の電子マネー口座残高として「５００円」がそれぞれ表示されている。
また、その下には、「リクエストをまとめる提案をしますか？」のテキストとともに、提案ボタンＢＴ９と、キャンセルボタンとが表示されている。
この状態で提案ボタンＢＴ９がタップされると、支払いの不足分の金額である「１，１００円」に基づいて、新たな送金リクエストが作成される。その結果、図６－２に示すような画面が表示される。
図６－２では、新たに作成された送金リクエストとして、受信済み送金リクエストであって、４件分の送金リクエストをまとめた、支払い金額を「１，１００円」とする一括送金リクエストが表示されている。
この表示画面例では、一括送金リクエストには、図６－１で選択された４件分の送金リクエスト、つまり、その一括送金リクエストの作成に用いられた送金リクエスト（まとめられた送金リクエスト）がぶら下がる形式で表示されている。また、ユーザが認識し易いように、これらの送金リクエストは、それ以外の送金リクエストとは異なる表示態様（この例ではグレーアウト）で表示されている。
なお、この表示画面例とは異なり、一括送金リクエストの作成に用いられた送金リクエストを表示させないようにしてもよい。
また、一括送金リクエストがタップされたことに基づいて、その一括送金リクエストの作成に用いられた送金リクエストを表示させるようにしてもよい。
＜処理＞
図６－３は、本実施例においてサーバ１０の制御部１１が実行する一括送金リクエスト作成処理の流れの一例を示すフローチャートである。
サーバ１０の制御部１１は、端末２０から一括送金リクエスト作成要求情報を受信したか否かに基づいて、端末２０から一括送金リクエストの作成が要求されたか否かを判定する（Ｓ５１０）。
一括送金リクエスト作成要求情報には、限定ではなく例として、一括送金リクエストの作成対象とする送金リクエストの選択情報を含めることができる。
要求されたと判定したならば（Ｓ５１０：ＹＥＳ）、サーバ１０の制御部１１は、送金リクエスト管理データ１５７を参照し、選択された各々の送金リクエストの送金リクエスト金額と、その種別（受信済み送金リクエスト（支払い）／送信済み送金リクエスト（受取））とに基づいて、作成する一括送金リクエストの送金リクエスト金額（以下、「一括送金リクエスト金額」と称する。）を算出する（Ｓ５３０）。
その後、サーバ１０の制御部１１は、算出した一括送金リクエスト金額に基づいて、一括送金リクエストを作成し、作成した一括送金リクエストのデータを、送金リクエスト管理データ１５７に記憶させる（Ｓ５５０）。
次いで、サーバ１０の制御部１１は、一括送金リクエストの作成結果に関する一括送金リクエスト作成結果情報を、通信Ｉ／Ｆ１４によって、要求元の端末２０に送信する（Ｓ５７０）。
そして、サーバ１０の制御部１１は、一括送金リクエスト作成処理を終了する。
この処理を行った後、端末２０では、表示部２４に表示される送金リクエスト一覧画面等において、一括送金リクエストに対応する一括送金リクエスト情報が表示される。そして、この一括送金リクエストに基づいて、一括精算を実行することが可能となる。
なお、Ｓ５１０において端末２０から一括送金リクエストの作成が要求されなかったと判定した場合（Ｓ５１０：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、端末２０からの要求に基づいて、前述した一括精算や、前述したリクエスト相殺といった他の一括処理を行うようにすることもできる。
なお、悪意のあるユーザが、前述した虚偽の送金リクエストを作成した上で、その送金リクエストを含む一括送金リクエストを作成するおそれもある。
そこで、一括送金リクエストの作成に相手の承認を必要とするようにしてもよいし、そのようにしなくてもよい。
＜第６実施例の効果＞
本実施例は、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、第１送金リクエスト情報と第２送金リクエスト情報との送金リクエスト金額が合計された送金リクエスト情報（限定ではなく、第１ユーザから端末のユーザへの送金依頼、または端末のユーザから相手のユーザへの送金依頼に関する第３情報の一例）に基づく一括送金リクエストの表示（限定ではなく、第６表示の一例）を表示部２４に表示する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、相手のユーザを一人のユーザとする場合に、複数の送金依頼に関する情報をまとめた第３情報に基づく第６表示を表示して、第３情報を端末のユーザに知らせることができる。また、限定ではなく例として、複数の送金依頼に関する情報をまとめた第３情報に基づいて包括的な精算を行うことが可能となるため、ユーザの利便性を向上させることができる。
＜第７実施例＞
第７実施例は、前述した一括処理のうちの「特殊一括精算・特殊一括送金リクエストの作成」に関する実施例である。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図７－１は、本実施例において端末２０Ａの表示部２４に表示される送金リクエスト一覧画面の一例を示す図であり、図６－１と同様に、ユーザＤ．Ｄとの間の送金リクエストの一覧が表示される画面を示している。ここでは、図６－１と同様に、１番目～４番目の送金リクエストが選択された状態が示されている。
選択された１番目～４番目の送金リクエストを一括精算する場合、一括精算は「支払い １，１００円」となり、ユーザＡ．ＡからユーザＤ．Ｄに対して「１，１００円」を支払うことになる。しかし、この例では、ユーザＡ．Ａの現在の電子マネー口座残高は「５００円」であるため、支払い金額が「６００円」不足することになる。
この場合、本実施例では、サーバ１０の制御部１１は、ユーザＡ．Ａの現在の電子マネー口座残高の全ての金額をユーザＤ．Ｄに送金して精算する一括精算を行う。
また、サーバ１０の制御部１１は、一括精算での支払いの不足分の金額を送金リクエスト金額とする新たな送金リクエストを作成する。
つまり、本実施例では、第６実施例とは異なり、提案者のユーザの残高で支払えるところまで支払いを行った上で、支払いを行うことができない金額を送金リクエスト金額とする新たな送金リクエストを作成する。
便宜的に、複数の送金リクエストに基づいて、可能なところまでの支払いを行う一括精算を「特殊一括精算」と称し、特殊一括精算を行った後に新たに作成される一括送金リクエストを「特殊一括送金リクエスト」と称する。
具体的には、画面下部の精算内容確認領域ＡＣＲ８には、自分の現在の電子マネー口座残高として「５００円」が、精算を行った場合の自分の電子マネー口座残高として「０円」がそれぞれ表示されている。そして、この状態で提案ボタンがタップされると、ユーザＡ．Ａの現在の電子マネー口座残高の全ての金額である「５００円」がユーザＡ．ＡからユーザＤ．Ｄに送金されて支払われる特殊一括精算が実行される。その後、支払いの不足分の金額である「６００円」に基づいて、特殊一括送金リクエストが作成される。その結果、図７－２に示すような画面が表示される。
図７－２では、特殊一括送金リクエストとして、支払い金額を「６００円」とする特殊一括送金リクエストが表示されている。
この表示画面例では、特殊一括送金リクエストには、図７－１で選択された４件分の送金リクエスト、つまり、その特殊一括送金リクエストの作成に用いられた送金リクエスト（まとめられた送金リクエスト）がぶら下がる形式で表示されている。また、ユーザにとって分かり易いように、これらの送金リクエストは、通常の送金リクエストとは異なる表示態様（この例ではグレーアウト）で表示されている。
なお、この表示画面例とは異なり、特殊一括送金リクエストの作成に用いられた送金リクエストを表示させないようにしてもよい。
また、特殊一括送金リクエストがタップされたことに基づいて、その特殊一括送金リクエストの作成に用いられた送金リクエストを表示させるようにしてもよい。
＜処理＞
図７－３～図７－４は、本実施例においてサーバ１０の制御部２１が実行する第４の精算処理の一例を示す図である。
Ｓ１５１５の後、サーバ１０の制御部１１は、いずれかのユーザの電子マネー口座残高がマイナスになるか否かを判定し（Ｓ１５２０）、マイナスになると判定したならば（Ｓ１５２０：ＹＥＳ）、電子マネー口座残高がマイナスになるのは提案者のユーザであるか否かを判定する（Ｓ１５７０）。
電子マネー口座残高がマイナスになるのは提案者のユーザであると判定したならば（Ｓ１５７０：ＹＥＳ）、サーバ１０の制御部１１は、一括精算金額を含む、実行する一括精算の種別（通常の一括精算／特殊一括精算）を確認するための一括精算種別確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１５７１）。
なお、この場合に、前述した残高不足情報を一括精算種別確認情報に含めて送信するようにしてもよいし、しなくてもよい。
その後、サーバ１０の制御部１１は、実行を要求する一括精算の種別の情報を含む精算実行要求情報を端末２０Ａから受信したことに基づいて、特殊一括精算の実行が要求されたか否かを判定する（Ｓ１５７４）。特殊一括精算ではなく、前述した通常の一括精算の実行が要求されたと判定した場合（Ｓ１５７４：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、図２－５のＳ１５５５に処理を移す。
一方、特殊一括精算の実行が要求されたと判定したならば（Ｓ１５７４：ＹＥＳ）、サーバ１０の制御部１１は、相手のユーザの承認が必要であるか否かを判定する（Ｓ１５７５）。
相手のユーザの承認が必要であると判定したならば（Ｓ１５７５：ＹＥＳ）、サーバ１０の制御部１１は、特殊一括精算による精算金額（以下、「特殊一括精算金額」と称する。）の情報である特殊一括精算金額情報を含む特殊一括精算承認確認情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１５７７）。
特殊一括精算金額は、限定ではなく例として、提案者のユーザの現在の電子マネー口座残高に相当する金額とすることができる。
なお、これに限定されず、特殊一括精算金額は、「０」より大きく、提案者のユーザの現在の電子マネー口座残高以下であれば、任意の金額とすることもできる。
その後、サーバ１０の制御部１１は、特殊一括精算を承認することを示す特殊一括精算承認情報を端末２０Ｂから受信したか否かを判定することによって、特殊一括精算が承認されたか否かを判定する（Ｓ１５７９）。
そして、承認されたと判定したならば（Ｓ１５７９：ＹＥＳ）、サーバ１０の制御部１１は、特殊一括精算を実行する（Ｓ１５８１）。具体的には、サーバ１０の制御部１１は、提案者のユーザ（この例ではユーザＡ．Ａ）の電子マネー口座残高をゼロに更新し、特殊一括精算金額を、相手のユーザ（この例ではユーザＢ．Ｂ）の電子マネー口座残高に加算して更新する。
その後、サーバ１０の制御部１１は、特殊一括送金リクエストを作成する（Ｓ１５８３）。具体的には、サーバ１０の制御部１１は、一括精算金額から特殊一括精算金額を減算した金額を送金リクエスト金額とする、相手のユーザから提案者のユーザに対する送金リクエストを特殊一括送金リクエストとして作成する。
そして、サーバ１０の制御部１１は、第４の精算処理を終了する。
なお、上記のように、提案者のユーザの残高で支払えるところまで支払いを行う手法は、上記のように複数の送金リクエストが選択される場合に限らず、１つの送金リクエストが選択される場合にも適用可能である。
つまり、提案者のユーザの現在の電子マネー口座残高の金額よりも送金リクエスト金額の方が大きい受信済み送金リクエストが１つ選択された場合、サーバ１０の制御部１１は、その送金リクエスト金額から電子マネー口座残高の金額を減算した金額（不足分の金額）を送金リクエスト金額とする送金リクエストを作成する。
＜端末による第２処理）＞
本実施例では、端末２０の制御部２１は、前述した第１処理に加えて、端末２０のユーザの電子マネー口座残高（端末のユーザの残高）に基づいて、少なくとも一つの情報を処理する第２処理を実行するようにすることができる。
限定ではなく例として、少なくとも以下の処理が第２処理に含まれる。
・リクエスト選択情報をサーバ１０に送信する処理
・一括精算確認情報をサーバ１０から受信する処理
・一括精算確認情報を表示する処理
・一括精算結果情報をサーバ１０から受信する処理
・一括精算結果情報を表示する処理
・金額差し引き（金額相殺を含む）をサーバ１０に要求する処理
・特殊一括精算の実行をサーバ１０に要求する処理
・特殊一括送金リクエストの作成をサーバ１０に要求する処理
＜第７実施例の効果＞
本実施例は、一括精算の提案者のユーザ（限定ではなく、端末のユーザの一例）への送金リクエスト、または一括精算の提案者のユーザによる送金リクエストに関する複数の送金リクエスト情報のうち、一括精算の提案者のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）に基づいて、少なくとも一つの送金リクエスト情報に対する一括精算のための第２処理（限定ではなく、少なくとも一つの情報を処理する第２処理の一例）が、一括精算の提案者のユーザの端末２０によって実行される構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高を考慮して、端末のユーザへの送金依頼、または端末のユーザによる送金依頼に関する複数の情報のうちの少なくとも一つの情報を第２処理によって処理することができるため、ユーザの利便性を向上させることができる。
＜第７変形例＞
第１変形例（３）と関連するが、第７実施例において、提案者の端末２０、またはサーバ１０が、提案者のユーザの現在の電子マネー口座残高に基づいて、送金リクエストを自動で選択（サジェストを含む。）するようにしてもよいし、しなくてもよい。
具体的には、提案者の端末２０の制御部２１は、提案者のユーザの現在の電子マネー口座残高をサーバ１０に問い合わせる処理を行う。そして、提案者の端末２０の制御部２１は、サーバ１０から受信した送金リクエスト一覧情報に含まれる送金リクエストの中から、各々の送金リクエスト金額と、各々の送金リクエストの種別（受信済み送金リクエスト（支払い）／送信済み送金リクエスト（受取））とに基づいて、限定ではなく例として、提案者のユーザの現在の電子マネー口座残高を超えた支払いが生ずる送金リクエストの組合せを特定して選択する。
この場合、限定ではなく例として、図７－１において、ユーザＤ．Ｄとの間の未処理リクエストのうち、限定ではなく例として、過去の送金リクエストから順に、自動的に一括精算の処理対象リクエストとして選択され、残高不足となる送金リクエスト（この例では４件目）まで選択された状態をユーザに提案するようにしてもよいし、しなくてもよい。
なお、サーバ１０の制御部１１が送金リクエストを選択する場合は、送金リクエスト管理データ１５７に記憶されている送金リクエストのデータに基づいて同様の処理を行えばよい。
本変形例は、第２処理は、複数の送金リクエスト情報のうち、提案者のユーザの電子マネー口座残高（限定ではなく、端末のユーザの残高の一例）で処理可能な送金リクエスト情報を選択する処理を含み、選択された情報を処理する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザの残高で処理可能な情報が選択されて処理されるため、限定ではなく例として、端末のユーザの残高がマイナスとならない範囲で情報が処理されるようにすることができるため、ユーザの利便性をより一層向上させることができる。
＜第８実施例＞
第８実施例は、端末２０のユーザが、相手のユーザに送金を行ったり、相手のユーザに送金リクエストを行う際に、未処理リクエストを表示する実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図８－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションの送金機能であることを示す「送金」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、送金先として選択されたユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＥ．Ｅ）が表示されている。また、その下には、送金先として選択されたユーザへの送金金額（この例では、「５００円」）と、送金金額を一定額増額させるための機能ボタンとが表示されている。
さらにその下には、送金先として選択されたユーザ（この例ではユーザＥ．Ｅ）と、送金を行うユーザ（この例ではユーザＡ．Ａ）との未処理リクエストを確認可能にするために構成された未処理リクエスト確認領域ＵＲＲ１が表示されている。
未処理リクエスト確認領域ＵＲＲ１最上部には、ユーザＥ．Ｅとの間の未処理リクエストを表示していることを示す「Ｅ．Ｅとの未精算リクエスト」の文字が表示されている。
また、その下には、全選択一括精算を行うと仮定した場合の一括精算金額（この例では「１，５００円」）およびマーク（この例では「支払いマーク」）が表示されている。
なお、この全選択一括精算を行うと仮定した場合の表示欄はなくてもよい。
その下には、相手をユーザＥ．Ｅとする送金リクエストが一覧表示されている。この例では、相手をユーザＥ．Ｅとする未処理リクエストが上から古い順に時系列で一覧表示されている。
また、未処理リクエスト確認領域ＵＲＲ１の下には、送金（送金処理）を実行させるための、「送金する」と示された送金ボタンが表示されている。
送金ボタンがタップされると、送金処理（ユーザＡ．ＡからユーザＥ．Ｅに対する送金）がサーバ１０によって実行される。
なお、送金ボタンは、限定ではなく例として、送金金額を一定額増額させるための機能ボタンの表示領域の下で、未処理リクエスト確認領域ＵＲＲ１の上の領域等に表示させてもよい。
このように、本実施例では、送金用の情報とともに、未処理リクエストを表示することで、ユーザが送金を行う際に、未処理リクエストを併せて確認することができるように構成されている。
図８－２は、本実施例において端末２０の表示部２４に表示される画面の別例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金リクエスト画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションの送金リクエスト機能であることを示す「送金リクエスト」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、送金リクエストの送信先として選択されたユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＥ．Ｅ）が表示されている。また、その下には、送金リクエストの送信先として選択されたユーザに対する送金リクエスト金額（この例では、「５００円」）と、送金リクエスト金額を一定額増額させるための機能ボタンとが表示されている。
なお、送金リクエストの送信先として選択されたユーザが送金リクエストを受け入れる場合、送金リクエストの送信先として選択されたユーザの電子マネー口座から送金リクエストを行った（送信した）ユーザの電子マネー口座に対して、送金リクエスト金額分の送金が実行される。
また、その下には、図８－１と同様に、未処理リクエスト確認領域ＵＲＲ１が表示されている。そして、その下には、送金リクエストの送信（送金リクエスト送信処理）を実行させるための、「送金リクエストする」と示された送金リクエストボタンが表示されている。
送金リクエストボタンがタップされると、送金リクエスト送信処理（ユーザＡ．ＡからユーザＥ．Ｅに対する送金リクエスト情報の送信）がサーバ１０によって実行される。
なお、送金リクエストボタンは、限定ではなく例として、送金リクエスト金額を一定額増額させるための機能ボタンの表示領域の下で、未処理リクエスト確認領域ＵＲＲ１の上の領域等に表示させてもよい。
このように、本実施例では、送金リクエスト送信用の情報とともに、未処理リクエストを表示することで、ユーザが送金リクエストを行う際に、未処理リクエストを併せて確認することができるように構成されている。
＜処理＞
図８－３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、一例として、図８－１で説明した、ユーザが送金を行う際に未処理リクエストを表示する処理について説明する。
最初に、端末２０Ａの制御部２１は、入力部に対して送金画面を表示するための入力がなされたか否かを判定する（Ａ１０５）。
入力がなされたと判定したならば（Ａ１０５：ＹＥＳ）、端末２０Ａの制御部２１は、Ａ１１０の処理を行い、通信Ｉ／Ｆ２２によってサーバ１０から送金リクエスト一覧情報を受信したことに基づいて、その送金リクエスト一覧情報を含む送金画面（送金用の画面）を表示部２４に表示させる（Ａ１２５）。
その後、端末２０Ａの制御部２１は、送金を実行するための入力（限定ではなく例として、送金ボタンの操作）がなされたか否かを判定する（Ａ６３０）。
送金を実行するための入力がなされなかったと判定したならば（Ａ６３０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了する。
一方、送金を実行するための入力がなされたと判定したならば（Ａ６３０：ＹＥＳ）、端末２０Ａの制御部２１は、送金を要求するための送金要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６４０）。
Ｓ１２０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから送金要求情報を受信したか否かを判定する（Ｓ６４０）。
送金要求情報を受信しなかったと判定したならば（Ｓ６４０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
一方、送金要求情報を受信したと判定したならば（Ｓ６４０：ＹＥＳ）、サーバ１０の制御部１１は、送金処理を実行する（Ｓ６５０）。具体的には、限定ではなく例として、送金内容を確認するための送金確認情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信し、通信Ｉ／Ｆ１４によって端末２０Ａから送金実行要求情報を受信したことに基づいて、ユーザＡ．ＡからユーザＢ．Ｂへの送金を実行する。
この場合、端末２０Ａの制御部２１は、限定ではなく例として、Ａ６５０～Ａ６７０の処理を実行する。
その後、サーバ１０の制御部１１は、送金結果が「ＯＫ」であったか否かを判定する（Ｓ６７０）。そして、「ＯＫ」であったと判定したならば（Ｓ６７０：ＹＥＳ）、サーバ１０の制御部１１は、送金結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ６９０）。
そして、サーバ１０の制御部１１は、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報を受信すると、端末２０Ａの制御部２１は、受信した送金結果情報を表示部２４に表示させる（Ａ６９０）。
そして、端末２０Ａの制御部２１は、処理を終了する。
同様に、通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報を受信すると、端末２０Ｂの制御部２１は、受信した送金結果情報を表示部２４に表示させる（Ｂ６９０）。
そして、端末２０Ｂの制御部２１は、処理を終了する。
なお、図８－２で説明した、ユーザが送金リクエストを行う際に未処理リクエストを表示する処理については、図８－３の処理における「送金」を「送金リクエスト送信」に置き換えることで同様に構成可能であるため、図示・説明を省略する。
具体的には、端末２０Ａの処理において、Ａ１０５で送金リクエスト送信画面を表示するための入力がなされたか否かを判定し、Ａ１２５で送金リクエスト一覧情報を含む送金リクエスト送信画面を表示し、Ａ６３０で送金リクエスト送信を実行するか否かを判定し、Ａ６４０で送金リクエスト送信要求情報を送信し、Ａ６５０で送金リクエスト送信確認情報を表示し、Ａ６６０で送金リクエスト送信実行要求がなされたか否かを判定し、Ａ６７０で送金リクエスト送信実行要求情報を送信し、Ａ６９０で送金リクエスト送信結果情報を表示する。
また、端末２０Ｂの処理において、Ｂ６９０で送金リクエスト送信結果情報を表示する。
また、サーバ１０の処理において、Ｓ６４０で送金リクエスト送信要求情報を受信したか否かを判定し、Ｓ６５０で送金リクエスト送信処理を実行し、Ｓ６７０で送金リクエスト送信結果がＯＫであるか否かを判定し、Ｓ６９０で送金リクエスト送信結果情報を送信する。
＜未処理リクエストの表示＞
端末２０の表示部２４に表示する未処理リクエストは、限定ではなく例として、以下のいずれか一方、または両方とすることができる。
・送金する相手のユーザ（送金先ユーザ）、または送金リクエストを送信する相手のユーザ（送金リクエスト先ユーザ）に対応する未処理リクエスト
・送金する相手のユーザ（送金先ユーザ）、または送金リクエストを送信する相手のユーザ（送金リクエスト先ユーザ）とは異なるユーザに対応する未処理リクエスト
相手のユーザに対応する未処理リクエストを表示するようにすることができる。限定ではなく例として、図８－１に示すようにユーザＡ．ＡがユーザＥ．Ｅを送金先ユーザとして送金する場合や、図８－２に示すようにユーザＡ．ＡがユーザＥ．Ｅを送金リクエスト先ユーザとして送金リクエストを送信する場合は、ユーザＥ．Ｅに対応する未処理リクエストを表示することができる。
しかし、ユーザによっては、相手のユーザとは異なるユーザに対応する未処理リクエストを確認したいと思うことも考えられる。
そこで、限定ではなく例として、図８－１や図８－２において、ユーザＥ．Ｅに対応する未処理リクエストに加えて、限定ではなく例として、ユーザＢ．ＢやユーザＣ．Ｃに対応する未処理リクエストを表示するようにすることもできる。
なお、この場合に、ユーザＥ．Ｅに対応する未処理リクエストを表示せず、限定ではなく例として、ユーザＢ．ＢやユーザＣ．Ｃに対応する未処理リクエストを表示するようにすることもできる。
つまり、未処理リクエストを表示するパターンとしては、限定ではなく例として、以下の３つのパターンが考えられる。
（パターン１）相手のユーザに対応する未処理リクエスト
（パターン２）相手のユーザに対応する未処理リクエスト＋相手のユーザとは異なるユーザに対応する未処理リクエスト
（パターン３）相手のユーザとは異なるユーザに対応する未処理リクエスト
また、上記のいずれのパターンを適用する場合も、各々のユーザについて、そのユーザに対応する全部の未処理リクエストを表示するようにしてもよいし、そのユーザに対応する一部の未処理リクエストを表示するようにしてもよい。
つまり、未処理リクエストを表示するユーザ（相手のユーザ／相手のユーザとは異なるユーザ）と、表示する未処理リクエストの範囲（全部／一部）とは、任意に組み合わせることができる。限定ではなく例として（パターン２）において、相手のユーザに対応する未処理リクエストは全部の未処理リクエストを表示するが、相手のユーザとは異なるユーザに対応する未処理リクエストは一部の未処理リクエストを表示するなどしてもよい。
また、一部の未処理リクエストを表示する場合、各種の情報（条件）に基づいて、表示する未処理リクエストを決定することもできる。
この場合、後述する第１６実施例の内容を組み合わせることができる。第１６実施例でも説明するが、各種の情報としては、限定ではなく例として、以下の情報が挙げられる。
・送金リクエストを送信／受信した日付や日時
・送金リクエスト金額
・送金リクエストの支払い期限
・送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエスト
なお、これらの情報はあくまでも一例であり、これらに限定されるものではない。
また、これらの情報のうちの複数の情報を組み合わせて適用することもできる。
日付や日時が一定以上古い未処理リクエストは、ユーザが忘れている場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
送金リクエスト金額が一定以上大きい未処理リクエストは、重要性が高い場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエストも、重要性が高い場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
支払い期限が一定期間内に迫っている未処理リクエストは、早急の処理を要する場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
また、第１６実施例でも説明するが、未処理リクエストを、上記の各種の情報（条件）に基づいて昇順／降順に並び替えて表示するようにすることもできる。一例としては、重要性が高い未処理リクエストほど、上位に表示されるようにすることができる。
これらの他にも、端末２０の表示部２４に表示する未処理リクエストを、限定ではなく例として、入力部に対する端末２０のユーザの入力に基づいて非表示にすることができる。
この場合、限定ではなく例として、一部のユーザに対応する未処理リクエストを非表示としてもよいし、全てのユーザに対応する未処理リクエストを非表示としてもよい。
また、ユーザによっては、未処理リクエストが表示されることに煩わしさを感じる場合もあると考えられる。
そこで、未処理リクエストの表示／非表示の設定を、不図示の設定画面等において行うことを可能としてもよい。
具体的には、アプリケーションの設定画面において、未処理リクエストの表示に関する設定用情報として、限定ではなく例として、未処理リクエストの表示／非表示を切替可能なスライドボタンやチェックボックスを表示させる。そして、このスライドボタンやチェックボックスに対する操作に基づいて、表示／非表示の設定を端末２０またはサーバ１０に行わせるようにすることができる。
この場合、全部のユーザについて一括的に未処理リクエストの表示／非表示を設定可能としてもよいし、ユーザごとに個別に未処理リクエストの表示／非表示を設定可能としてもよい。
また、全部の未処理リクエストの表示／非表示を設定可能としてもよいし、一部の未処理リクエストの表示／非表示を設定可能としてもよい。
なお、これらの内容は、以下の実施例についても同様である。
＜第８実施例の効果＞
本実施例は、提案者のユーザの端末２０が、提案者のユーザ（限定ではなく、端末のユーザの一例）から相手のユーザ（限定ではなく、第１ユーザの一例）への送金用の情報（限定ではなく、端末のユーザから第１ユーザへの送金に関する第１情報の一例）、または提案者のユーザから相手のユーザへの送金リクエスト送信用の情報（限定ではなく、端末のユーザから第１ユーザへ送信する送金依頼に関する第１情報の一例）に基づく第１表示と、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）、または提案者のユーザが相手のユーザに送信済みの送信済み送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザが第１情報を確認する際に、第２情報を併せて確認できるようにすることができる。
また、本実施例は、提案者のユーザの端末２０は、提案者のユーザによる、第１表示が表示された端末２０に対する入力に基づいて、送金するための処理（限定ではなく、送金に関する処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示が表示された端末に対する入力に基づいて、相手のユーザへの送金を簡単に実現することができる。
＜第８変形例＞
上記の実施例において、相手のユーザへの送金用の情報や相手のユーザへの送金リクエスト送信用の情報とともに表示される未処理リクエストの情報に対する入力に基づいて、精算（未処理リクエストの一括精算を含む。）が実行されるようにすることもできる。
具体的には、限定ではなく図８－１の画面例において、送金ボタンに加えて、選択された未処理リクエストの精算（複数選択された場合は一括精算）を実行させるための精算ボタンを表示させる。
そして、精算ボタンがタップされると、選択された未処理リクエストの精算処理がサーバ１０によって実行されるようにすることができる。
同様に、限定ではなく図８－２の画面例において、送金リクエストボタンに加えて、選択された未処理リクエストの精算（複数選択された場合は一括精算）を実行させるための精算ボタンを表示させる。
そして、精算ボタンがタップされると、選択された未処理リクエストの精算処理がサーバ１０によって実行されるようにすることができる。
なお、未処理リクエストの精算処理については、前述した通りであるため、再度の説明を省略する。
図８－４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、一例として、図８－３に示したユーザが送金を行う際に未処理リクエストを表示する処理において、送金と、未処理リクエストの精算とのいずれか一方を行う処理について説明する。
Ａ１２５の後、端末２０Ａの制御部２１は、入力部に対する入力に基づいて、実行対象を判定する（Ａ６３１）。
実行対象が未処理リクエストの精算（複数選択された場合は一括精算）であると判定したならば（Ａ６３１：未処理リクエストの精算）、端末２０Ａの制御部２１は、選択された未処理リクエストを示す未処理リクエスト選択情報を含むリクエスト選択情報を設定する（Ａ６３２）。
一方、実行対象が送金であると判定したならば（Ａ６３１：送金）、端末２０Ａの制御部２１は、実行する送金に関する送金情報を含むリクエスト選択情報を設定する（Ａ１３３）。
Ａ６３２またはＡ１３３の後、端末２０Ａの制御部２１は、設定されたリクエスト選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。
そして、端末２０Ａの制御部２１は、Ａ１５０に処理を移す。
Ｓ１２０の後、端末２０Ａからリクエスト選択情報を受信したと判定した場合（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、受信したリクエスト選択情報に基づいて、処理対象を判定する（Ｓ６４１）。
処理対象が「未処理リクエストの精算」であると判定したならば、サーバ１０の制御部１１は、選択された未処理リクエストを精算対象（複数選択された場合は一括精算対象）として設定する（Ｓ６４２）。
一方、処理対象が「送金」であると判定したならば、サーバ１０の制御部１１は、送金を精算対象として設定する（Ｓ１４３）。
Ｓ６４２またはＳ１４３の後、サーバ１０の制御部１１は、Ｓ１５０の精算処理を実行する。
限定ではなく例として図１－１９で説明した第１の精算処理を適用する場合、
Ｓ６４２の設定がなされた場合であって、処理対象の未処理リクエストが複数である場合は、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＹＥＳ」となる。その結果、この複数の未処理リクエストを一括精算対象として、Ｓ１５１５以降の処理が実行される。また、Ｓ６４２の設定がなされた場合であって、処理対象の未処理リクエストが１つである場合は、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＮＯ」となる。その結果、この１つの未処理リクエストを精算対象として、Ｓ１５７０以降の処理が実行される。
一方、Ｓ１４３の設定がなされた場合、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＮＯ」となる。その結果、送金を精算対象として、Ｓ１５７０以降の処理が実行される。
なお、ユーザが送金リクエストを行う際に未処理リクエストを表示し、送金リクエストの送信と、未処理リクエストの精算とのいずれか一方を行う処理については、図８－４の処理における「送金」を「送金リクエスト送信」に置き換えることで同様に構成可能であるため、図示・説明を省略する。
具体的には、端末２０Ａの処理において、Ａ１０５で送金リクエスト送信画面を表示するための入力がなされたか否かを判定し、Ａ１２５で送金リクエスト一覧情報を含む送金リクエスト送信画面を表示し、Ａ６３１で実行対象が未処理リクエストの精算と送金リクエスト送信とのいずれであるかを判定し、Ａ１３３で送金リクエスト送信情報を含むリクエスト選択情報を設定する。
また、サーバ１０の処理において、Ｓ６４１で処理対象が未処理リクエストの精算と送金リクエスト送信とのいずれであるかを判定し、Ｓ１４３で送金リクエスト送信を精算対象として設定する。
本変形例は、提案者のユーザの端末２０が、提案者のユーザ（限定ではなく、端末のユーザの一例）から相手のユーザ（限定ではなく、第１ユーザの一例）への送金用の情報（限定ではなく、端末のユーザから第１ユーザへの送金に関する第１情報の一例）、または提案者のユーザから相手のユーザへの送金リクエスト送信用の情報（限定ではなく、端末のユーザから第１ユーザへ送信する送金依頼に関する第１情報の一例）に基づく第１表示と、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）、または提案者のユーザが相手のユーザに送信済みの送信済み送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示とを表示部２４に表示する。
そして、提案者のユーザの端末２０は、提案者のユーザによる、第１表示または第２表示が表示された端末２０に対する入力に基づいて、送金するための処理、または送金された金額を受け取るための処理、または送金リクエスト（送金リマインド）の送信／受信を行うための処理（限定ではなく、送金に関する、または送金の受け取りに関する、または送金の依頼に関する第１処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示または第２表示が表示された端末に対する入力に基づいて、相手のユーザへの送金や、相手のユーザからの送金の受け取り、相手のユーザへの送金依頼の送信／受信を簡単に実現することができる。
次に、第８実施例に関連する実施例として、端末２０のユーザが、相手のユーザに送金したり、相手のユーザに送金リクエストを送信する場合に、表示された未処理リクエストの中から選択された未処理リクエストも併せて処理する実施例について説明する。
以下の実施例では、大きく分けて下記の５つのパターンについて説明する。
（Ａ）送金＋受信済み送金リクエストを処理するパターン
（Ｂ）送金＋送信済み送金リクエストを処理するパターン
（Ｃ）送金リクエストを送信＋受信済み送金リクエストを処理するパターン
（Ｄ）送金リクエストを送信＋送信済み送金リクエストを処理するパターン
（Ｅ）送金リクエスト＋受信済み送金リクエスト＋送信済み送金リクエストを処理するパターン
各々のパターンについて、実施例を分けて説明する。
第８変形例にも示したが、端末２０が制御部２１によって実行する処理（第１処理等）には、限定ではなく例として、送金を行うための処理（限定ではなく、送金に関する処理の一例）、送金の受け取り（受金）を行うための処理（限定ではなく、送金の受け取りに関する処理の一例）、送金リクエストを送信／受信するための処理（限定ではなく、送金の依頼に関する処理の一例）等の処理が含まれる。
なお、以下ではサーバクライアントシステムを例示し、送金や送金リクエストの送信等は、サーバ１０を介して行われるものとする。
また、以下では、前述したように、相手のユーザを一人のユーザとする場合、つまり、第２ユーザは第１ユーザである（または第１ユーザは第２ユーザである）場合を例示する。
なお、前述したように、相手のユーザを異なる複数のユーザとする場合、つまり、第１ユーザは第２ユーザとは異なるユーザである（第２ユーザは第１ユーザとは異なるユーザである）場合についても、以下説明する手法を同様に適用することができる。
＜第９実施例＞
第９実施例は、上記（Ａ）のパターンの処理に関する実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、未処理リクエストのうちの「受信済み送金リクエスト」を一括精算対象に含めるのに加えて、「送金」を一括精算対象に含めて一括精算を行う。
図９－１は、各々のパターンそれぞれに対応する処理方法を説明するためのテーブルの一例を示す図である。
テーブルの縦方向には項目として今から新規に実行しようとする処理の対象（新規処理対象）を、テーブルの横方向には項目として未処理リクエストの種別をそれぞれ示している。そして、縦の項目と横の項目とが交差する欄には、その新規処理対象とその種別の未処理リクエストとの組合せによって実現される処理の一例を示している。
本実施例では、（Ａ）送金＋受信済み送金リクエスト、のパターンの処理について説明する。このパターンでは、（Ａ１）送金［送金＋送金］、の処理を行うことができる。
つまり、相手のユーザへの新規の送金を行う際に、相手のユーザからの受信済みの送金リクエストに基づいて相手に対する送金を併せて行う。より具体的には、新規の送金によって相手のユーザに送金する金額と、受信済み送金リクエスト情報に含まれる送金リクエスト金額（相手のユーザから送金を依頼された金額）とを合算した金額を、相手のユーザに送金する。
＜表示画面＞
上記（Ａ１）の処理を行う場合の表示画面例について説明する。
図９－２は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションの送金機能であることを示す「送金」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、送金先として選択されたユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＥ．Ｅ）が表示されている。また、その下には、送金先として選択されたユーザへの送金金額（この例では、「５００円」）と、送金金額を一定額増額させるための機能ボタンとが表示されている。
さらにその下には、送金先として選択されたユーザ（この例ではユーザＥ．Ｅ）と、送金を行うユーザ（この例ではユーザＡ．Ａ）との未処理リクエストを確認可能にするために構成された未処理リクエスト確認領域ＵＲＲ１が表示されている。
未処理リクエスト確認領域ＵＲＲ１最上部には、ユーザＥ．Ｅとの間の未処理リクエストを表示していることを示す「Ｅ．Ｅとの未精算リクエスト」の文字が表示されている。
また、その下に、全選択一括精算を行うと仮定した場合の一括精算金額（この例では「１，５００円」）およびマーク（この例では「支払いマーク」）が表示されている。
その下には、相手をユーザＥ．Ｅとする送金リクエストが一覧表示されている。この例では、相手をユーザＥ．Ｅとする未処理リクエストが上から古い順に時系列で一覧表示されている。各々の未処理リクエストの表示態様については、限定ではなく例として、図１－１１と同様に構成可能なため、再度の説明は省略する。
未処理リクエスト確認領域ＵＲＲ１の下には、送金処理と全選択一括精算とを実行させるための、「すべて精算して送金」と示された送金全選択一括精算ボタンが表示されている。その下には、送金処理と、未処理リクエスト確認領域ＵＲＲ１で選択された未処理リクエストの一部選択一括精算とを実行させるための、「１件の精算と送信」と示された送金一括精算ボタンＢＴ１１が表示されている。さらにその下には、送金処理のみを実行させるための、「送金だけする」と示された送金ボタンが表示されている。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、１つ目の受信済み送金リクエスト（支払い ２，５００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金一括精算ボタンＢＴ１１がタップされると、端末２０Ａからサーバ１０に対して、送金と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、その実行結果に関する精算結果情報が送信される。
図９－３は、上記の送金一括精算ボタンＢＴ１１がタップされたことに基づいて端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ４には、送金と一括精算の内容として、２件の精算結果情報が表示されている。
具体的には、限定ではなく例として、ユーザＡ．ＡがユーザＥ．Ｅに送金した送金金額「５００円」の受け取りと、図９－２で選択された１件目の送金リクエストによる、ユーザＡ．ＡがユーザＥ．Ｅから受信した送金リクエストによる送金リクエスト金額「２，５００円」に基づいて送金した送金金額「２，５００円」の受け取りとのそれぞれに対応する精算結果情報が表示されている。
なお、図９－４で示すように、２件の精算結果情報をまとめて、１つの精算結果情報としておしらせ画面のおしらせ情報表示領域ＮＴＲ４に表示させるようにしてもよいし、そのようにしなくてもよい。
限定ではなく例として、図９－４では、精算結果情報として、ユーザＥ．Ｅは、ユーザＡ．Ａからの送金の受け取りによる送金金額「５００円」と、ユーザＡ．Ａへの送金リクエストによる送金リクエスト金額「２，５００円」の受け取りによる送金金額「２，５００円」とを加算した「３，０００円」を受け取ることに関する情報が表示されている。
図９－２では、未処理リクエスト確認領域ＵＲＲ１には、送金先として選択されたユーザと、送金を行うユーザとの未処理リクエストを表示するとしたが、これに限定されない。
図９－５に、送金を行うユーザの全ての未処理リクエストを表示する場合の表示画面の一例を示す。図９－５は、図９－２の送金画面の別例である。
図９－５では、未処理リクエスト確認領域ＵＲＲ２には、送金を行うユーザの全ての未処理リクエストが上から古い順に時系列で一覧表示されている。また、未処理リクエスト確認領域ＵＲＲ２の下には、送金一括精算ボタンＢＴ１１と、送金ボタンとが表示されている。限定ではなく例として、未処理リクエスト確認領域ＵＲＲ２において、４つ目のユーザＥ．Ｅからの受信済み送金リクエスト（支払い ２，５００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金一括精算ボタンＢＴ１１がタップされると、図９－３の表示画面が端末２０Ｅの表示部２４に表示される。
＜処理＞
図９－６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図１－１８のフローチャートを、新規処理対象を「送金」とする処理に書き換えたフローチャートである。
本実施例における（Ａ）送金＋受信済み送金リクエスト、のパターンの処理では、相手のユーザに対して一方的に送金を行うため、一括精算を行う際に、相手のユーザの承認は不要とすることができる。そこで、ここでは、相手のユーザの承認を不要とする処理として図示・説明する。
なお、これに限定されるわけではなく、相手のユーザの承認を必要としてもよい。
Ａ１２５の後、端末２０Ａの制御部２１は、送金リクエスト一覧情報の中から未処理リクエストが選択されたか否かを判定する（Ａ１３１）。
未処理リクエストが選択された場合、つまり、送金＋未処理リクエストの処理の実行を要求すると判定したならば（Ａ１３１：ＹＥＳ）、端末２０Ａの制御部２１は、実行する送金に関する送金情報と、選択された未処理リクエストを示す未処理リクエスト選択情報とを含むリクエスト選択情報を設定する（Ａ１３２）。
一方、送金リクエスト一覧情報の中から未処理リクエストが選択されなかった場合、つまり、送金のみを実行すると判定した場合（Ａ１３１：ＮＯ）、端末２０Ａの制御部２１は、実行する送金に関する送金情報を含むリクエスト選択情報を設定する（Ａ１３３）。
なお、この処理では、送金を行うことを前提として説明する。
実際には、送金を行わずに未処理リクエストのみを処理することが選択される場合もあり得るが、この場合の処理は、前述した未処理リクエストの一括精算の処理と同様となるため、図示・再度の説明を省略する、
Ａ１３２またはＡ１３３の後、端末２０Ａの制御部２１は、設定されたリクエスト選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。
そして、端末２０Ａの制御部２１は、Ａ１５０に処理を移す。
Ｓ１４０において端末２０Ａからリクエスト選択情報を受信したと判定したならば（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、受信したリクエスト選択情報に含まれる情報に基づいて、送金＋未処理リクエスト、を処理するか否かを判定する（Ｓ１４１）。そして、処理すると判定したならば（Ｓ１４１：ＹＥＳ）、サーバ１０の制御部１１は、送金＋選択された未処理リクエストの精算（複数選択された場合は一括精算）、を一括精算対象として設定する（Ｓ１４２）。
一方、送金＋未処理リクエストの処理ではない、つまり、送金のみを実行すると判定したならば（Ｓ１４１：ＮＯ）、サーバ１０の制御部１１は、送金を精算対象として設定する（Ｓ１４３）。
Ｓ１４２またはＳ１４３の後、サーバ１０の制御部１１は、Ｓ１５０の精算処理を実行する。
限定ではなく例として図１－１９で説明した第１の精算処理を適用する場合、
Ｓ１４２の設定がなされた場合、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＹＥＳ」となる。その結果、送金＋選択された未処理リクエストの精算を一括精算対象として、Ｓ１５１５以降の処理が実行される。
一方、Ｓ１４３の設定がなされた場合、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＮＯ」となる。その結果、送金を精算対象として、Ｓ１５７０以降の処理が実行される。
＜第９実施例の効果＞
本実施例は、提案者のユーザの端末２０が、提案者のユーザ（限定ではなく、端末のユーザの一例）から相手のユーザ（限定ではなく、第１ユーザの一例）への送金情報（限定ではなく、端末のユーザから第１ユーザへの送金に関する第１情報の一例）、または提案者のユーザから相手のユーザへ送信する送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第１ユーザへ送信する送金依頼に関する第１情報の一例）に基づく第１表示と、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）、または提案者のユーザが相手のユーザに送信済みの送信済み送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示とを表示部２４に表示する。
そして、提案者のユーザの端末２０は、提案者のユーザによる、第１表示または第２表示が表示された端末２０に対する入力に基づいて、送金するための処理、または送金された金額を受け取るための処理、または送金リクエスト（送金リマインド）の送信／受信を行うための処理（限定ではなく、送金に関する、または送金の受け取りに関する、または送金の依頼に関する第１処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示または第２表示が表示された端末に対する入力に基づいて、相手のユーザへの送金や、相手のユーザからの送金の受け取り（受金）、相手のユーザへの送金依頼の送信、相手のユーザからの送金依頼の受信等を簡単に実現することができる。
また、本実施例は、第１処理は、第１表示と第２表示とに対する入力に基づいて、第１情報と第２情報とに基づく処理が制御部２１によって行なわれる構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とに対する入力に基づいて、第１情報と第２情報とに基づく処理が簡単に行われるようにすることができる。
また、本実施例は、第１情報は、提案者のユーザから相手のユーザへの送金情報（限定ではなく、端末のユーザから第１ユーザへの送金に関する情報の一例）であり、第２情報は、相手のユーザからの受信済みの送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する情報の一例）であり、第１処理は、送金情報と受信済み送金リクエスト情報とに基づいて、相手のユーザに送金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とに対する入力に基づいて、端末のユーザから第１ユーザへの送金に関する情報と第２ユーザから端末のユーザに送信された送金依頼に関する情報とに基づく、第１ユーザと第２ユーザとの送金を簡単に実現することができる。
また、この場合に、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、提案者のユーザから相手のユーザに送金する金額と、相手のユーザからの受信済み送金リクエスト情報に含まれる送金リクエスト金額とを合算した金額（限定ではなく、第１情報と第２情報とに基づく金額の一例）を相手のユーザに送金する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、一人の同じユーザを相手として、第１情報と第２情報とに基づく金額を送金することができる。
＜第９変形例＞
上記の実施例では、第１情報と第２情報とに基づく金額の一例として、提案者のユーザから相手のユーザに送金する金額と、相手のユーザからの受信済み送金リクエスト情報に含まれる送金リクエスト金額とを合算した金額を、相手のユーザに送金する場合を例示したが、これに限定されない。
提案者のユーザが、相手のユーザからお金を借りているような場合が想定される。このような場合に、限定ではなく例として、提案者のユーザから相手のユーザに利子をつけて送金するようにすることもできる。
具体的には、限定ではなく例として、提案者のユーザの端末２０側で、またはサーバ１０側で、上記の金額を合算した金額に、あらかじめ設定された割合の利子（限定ではなく例として、５％の利子）を自動的に付加する処理を行い、利子が付加された金額を送金金額として、提案者のユーザから相手のユーザに送金するようにすることができる。
なお、この手法は、第１情報と第２情報とに基づく金額を相手のユーザから送金される場合についても同様である。
＜第１０実施例＞
第１０実施例は、前述した（Ｂ）のパターンの処理に関する実施例である。
第１０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、未処理リクエストのうちの「送信済み送金リクエスト」を一括精算対象に含めるのに加えて、「送金」を一括精算対象に含めて一括精算を行う。
図９－６のテーブルを再び参照して説明する。
本実施例では、（Ｂ）送金＋送信済み送金リクエスト、のパターンの処理を行う。
このパターンでは、（Ｂ１）送金＋送金リマインド、（Ｂ２）［送金＋受金］（金額差し引き可）、のいずれかの処理を行うことができる。
（Ｂ１）の処理では、相手のユーザへの新規の送金を行う際に、相手のユーザへの送信済み送金リクエストに基づいて相手のユーザへの送金リマインドを併せて行う。
なお、送金リマインドに代えて、新規の送金リクエストを併せて行うようにしてもよいし、しなくてもよい。
（Ｂ２）の処理では、相手のユーザへの新規の送金を行う際に、相手のユーザへの送信済み送金リクエストに基づいて相手のユーザから送金してもらって受金する。
この場合、金銭の支払いと受取との相反する関係になるため、送金リクエスト金額の差額分の金額を送金する／受金することができる。
また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
具体的には、提案者のユーザから相手のユーザに送金する金額から、送信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザに送金する。
または、これとは逆に、送信済み送金リクエスト情報に含まれる送金リクエスト金額から、提案者のユーザから相手のユーザに送金する金額を差し引いた金額を、相手のユーザから受金する。
＜表示画面＞
最初に、上記（Ｂ１）の処理を行う場合の表示画面例について説明する。
図１０－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金画面である。画面構成の詳細については、限定ではなく例として、図９－２と同様に構成することが可能なため、詳細については説明を省略する。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、２つ目の送信済み送金リクエスト（受取 １，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金一括精算ボタンＢＴ１１がタップされると、端末２０Ａからサーバ１０に対して、送金と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、その実行結果に関する精算結果情報が送信される。
図１０－２は、上記の送金一括精算ボタンＢＴ１１がタップされたことに基づいて端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ４には、送金と一括精算の内容として、２件の精算結果情報が表示されている。
具体的には、限定ではなく例として、ユーザＡ．ＡがユーザＥ．Ｅに送金した送金金額「５００円」の受け取りに対応する精算結果情報と、図１０－１で選択された２件目の送金リクエスト（ユーザＡ．ＡがユーザＥ．Ｅに送信した送金リクエスト金額「１，０００円」の送金リクエスト）に対応するリマインドとが表示されている。
次に、上記（Ｂ２）の処理を行う場合の表示画面例について説明する。
図１０－３は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金画面である。画面構成の詳細については、限定ではなく例として、図９－２と同様に構成することが可能なため、詳細については説明を省略する。なお、図１０－３では、限定ではなく例として、送金先として選択されたユーザへの送金金額を「１，５００円」とする。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、２つ目の送信済み送金リクエスト（受取 １，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金一括精算ボタンＢＴ１１がタップされると、端末２０Ａからサーバ１０に対して、送金と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｅの表示部２４に表示される。
図１０－４は、送金一括精算ボタンＢＴ１１がタップされたことに基づいて表示されるおしらせ画面の一例を示す図である。
おしらせ情報表示領域ＮＴＲ４には、一括精算承認確認情報として、「精算提案」の相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。
一括精算承認確認情報には、一括精算の内容として、ユーザＥ．Ｅは、ユーザＡ．ＡからユーザＥ．Ｅに送金される今回の送金によって「１，５００円」を受け取り、ユーザＡ．Ａからの過去の送金リクエストの受信に基づいて送金リクエスト金額「１，０００円」を支払うことが表示されている。
なお、一括精算の内容は、限定ではなく例として、一括精算承認確認情報の「とじる」アイコンをタップすることで格納可能であり、格納された状態から「概要」アイコンをタップすることで伸長させることが可能である。
また、一括精算承認確認情報には、一括精算金額として、ユーザＥ．ＥはユーザＡ．Ａから、送金による受け取り金額「１，５００円」から送金リクエストによる送金リクエスト金額「１０００円」を減算した「５００円」を受け取ることが表示されている。
一括精算承認確認情報の下部には、上記の内容で精算を承認するための「精算する」と示された精算ボタンＢＴ１２と、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
図１０－５は、上記の精算ボタンＢＴ１２がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
現在位置表示領域ＣＬＲ１の下には、サーバ１０を介してユーザＥ．Ｅの端末２０Ｅから送金リクエストの一括精算が承認され、その結果送金が行われた通知として、ベルのマークとともに、「５００円を送金しました。」の文字を含む通知ＮＴ２が表示されている。
また、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、上記の通知ＮＴ２に対応する情報が表示される。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、ユーザＥ．Ｅとの間で一括精算が行われたことで、その一括精算の内容として、精算結果情報（この例では、ユーザＡ．ＡがユーザＥ．Ｅに送金した送金金額「５００円」の支払い）が表示されている。
なお、図１０－３において、送金一括精算ボタンＢＴ１１がタップされる場合、端末２０Ａの表示部２４に、精算が行われる場合にはユーザＡ．Ａは一括精算金額「５００円」を支払うことになる旨の確認用画面を表示させ、ユーザＡ．Ａの承認に基づいて送金と選択された未処理リクエストの一括精算との実行が依頼されるようにしてもよいし、そのようにしなくてもよい。
＜処理＞
本実施例において各装置が実行する処理は、図９－６の処理に倣って同様に実現することができる。
ただし、（Ｂ２）［送金＋受金］（金額差し引き可）、の処理を実行する場合は、相手のユーザによって送金される処理が含まれる。このため、前述したように、一括精算を行うにあたり、相手のユーザの承認を必要とすることもできる。
図１０－６は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、限定ではなく例として、図１－２１の処理を図９－６の処理に適用したフローチャートである。
図９－６の処理と異なるのは、端末２０Ｂの制御部２１が実行する処理として、Ｂ１５０～Ｂ１９０のステップが追加されている点である。
＜第１０実施例の効果＞
本実施例は、前述した第１情報は、提案者のユーザから相手のユーザへの送金情報（限定ではなく、端末のユーザから第１ユーザへの送金に関する情報の一例）であり、第２情報は、提案者のユーザから相手のユーザへ送信済みの送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザに送信された送金依頼に関する情報の一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザから第１ユーザへの送金と、端末のユーザから第２ユーザに送信された送金依頼とを、併せて処理することができる。
また、この場合に、第１処理は、送金情報に基づいて相手のユーザに送金し、送信済み送金リクエスト情報に基づいて相手のユーザに送金リマインドを送信する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザへの送金と、第第２ユーザへの送金依頼とを、併せて行うことができる。
また、本実施例は、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、提案者のユーザから相手のユーザに送金する金額と、送信済み送金リクエスト情報に含まれる送金リクエスト金額とに基づく金額（限定ではなく、第１情報と第２情報とに基づく金額の一例）を、相手のユーザに送金する処理（限定ではなく、第１ユーザに送金する処理の一例）、または第１ユーザから受金する処理（限定ではなく、第１ユーザから送金される処理の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、一人の同じユーザを相手として、第１情報と第２情報とに基づく金額を送金する、または第１情報と第２情報とに基づく金額を送金してもらって受け取ることができる。
また、この場合に、第１処理は、提案者のユーザから相手のユーザに送金する金額（限定ではなく、第１金額の一例）から、送信済み送金リクエスト情報に含まれる送金リクエスト金額（限定ではなく、第２金額の一例）を差し引いた金額を相手のユーザに送金する処理（限定ではなく、第１ユーザに送金する処理の一例）、または送信済み送金リクエスト情報に含まれる送金リクエスト金額（第２金額）から、提案者のユーザから相手のユーザに送金する金額（第１金額）を差し引いた金額を、相手のユーザから受金する処理（限定ではなく、第１ユーザから送金される処理の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、一人の同じユーザを相手として、第１金額と第２金額との差額分の金額を送金する、または第１金額と第２金額との差額分の金額を送金してもらって受け取ることができる。
また、本実施例は、第１処理は、相手のユーザの端末に対する入力に基づく、相手のユーザによる承認に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの端末に対する入力に基づく、第１ユーザによる承認に基づいて、第１処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザの意に沿わずに第１処理が実行されることを防止することができる。
＜第１１実施例＞
第１１実施例は、前述した（Ｃ）のパターンの処理に関する実施例である。
第１１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、未処理リクエストのうちの「受信済み送金リクエスト」を一括精算対象に含めるのに加えて、「送金リクエストの送信」を一括精算対象に含めて一括精算を行う。
図９－６のテーブルを再び参照して説明する。
本実施例では、（Ｃ）送金リクエストを送信＋受信済み送金リクエスト、のパターンの処理を行う。
このパターンでは、（Ｃ１）送金リクエスト＋送金、（Ｃ２）［受金＋送金］（金額差し引き可）、のいずれかの処理を行うことができる。
（Ｃ１）の処理では、相手のユーザへの新規の送金リクエストを行う際に、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザへの送金を併せて行う。
（Ｃ２）の処理では、相手のユーザへの新規の送金リクエストを行う際に、この新規の送金リクエストに基づいて相手のユーザから送金してもらって受金するとともに、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザへの送金を併せて行う。
この場合、送金リクエスト金額の差額分の金額を受金する／送金することができる。
また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
＜表示画面＞
最初に、上記（Ｃ１）の処理を行う場合の表示画面例について説明する。
図１１－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金リクエスト画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションの送金リクエスト機能であることを示す「送金リクエスト」の文字が表示されている。
現在位置表示領域ＣＬＲ１の下には、送金リクエストの送信先として選択されたユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＥ．Ｅ）が表示されている。また、その下には、送金リクエストの送信先として選択されたユーザに対する送金リクエスト金額（この例では、「５００円」）と、送金リクエスト金額を一定額増額させるための機能ボタンとが表示されている。送金リクエストの送信先として選択されたユーザが送金リクエストを受け入れる場合、送金リクエストの送信先として選択されたユーザの電子マネー口座から送金リクエストを行った（送信した）ユーザの電子マネー口座に対して、送金リクエスト金額分の送金が実行される。
さらにその下には、未処理リクエスト確認領域ＵＲＲ１が表示されている。未処理リクエスト確認領域ＵＲＲ１については、限定ではなく例として、図９－２と同様に構成可能であるため説明を省略する。
未処理リクエスト確認領域ＵＲＲ１の下には、送金リクエストの送信処理と全選択一括精算とを実行させるための、「すべて精算して送金リクエスト」と示された送金リクエスト送信全選択一括精算ボタンが表示されている。その下には、送金リクエストの送信処理と、未処理リクエスト確認領域ＵＲＲ１で選択された未処理リクエストの一部選択一括精算とを実行させるための、「１件の精算と送金リクエスト」と示された送金リクエスト送信一括精算ボタンＢＴ１３が表示されている。さらにその下には、送金リクエスト送信処理のみを実行させるための、「送金リクエストだけする」と示された送金リクエスト送信ボタンが表示されている。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、１つ目の受信済み送金リクエスト（支払い ２，５００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送信一括精算ボタンＢＴ１３がタップされると、端末２０Ａからサーバ１０に対して、新規の送金リクエスト送信と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、送金リクエスト情報と、一括精算の実行結果に関する精算結果情報とが送信される。
図１１－２は、上記の送金リクエスト送信一括精算ボタンＢＴ１３がタップされたことに基づいて端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ４には、図１１－１において選択された１件の送金リクエストに関する精算結果情報と、新規の送金リクエスト情報とが表示されている。
精算結果情報には、ユーザＥ．Ｅは、ユーザＡ．Ａに対する送金リクエストによる送金リクエスト金額「２，５００円」を受け取ったことに関する情報が表示されている。
送金リクエスト情報には、限定ではなく例として、ユーザＡ．ＡがユーザＥ．Ｅに送信した送金リクエスト金額「５００円」の送金リクエストと、この送金リクエストを了承し、送金リクエストに基づいて送金するための「送金する」と示された送金リクエスト送金ボタンと、この送金リクエストを承認せずに断るための「断る」と示された送金リクエスト拒否ボタンとが表示されている。
次に、（Ｃ２）の処理を行う場合の表示画面例について説明する。
図１１－３は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金リクエスト画面である。画面構成の詳細については、限定ではなく例として、図１１－１と同様に構成することが可能なため、詳細については説明を省略する。なお、図１１－３では、限定ではなく例として、送金リクエストの送信先として選択されたユーザ（この例ではユーザＥ．Ｅ）への送金リクエスト金額を「１，０００円」とする。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、１つ目の受信済み送金リクエスト（支払い ２，５００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送信一括精算ボタンＢＴ１３がタップされると、端末２０Ａからサーバ１０に対して、新規の送金リクエスト送信と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｅの表示部２４に表示される。
図１１－４は、送金リクエスト送信一括精算ボタンＢＴ１３がタップされたことに基づいて表示されるおしらせ画面の一例を示す図である。
おしらせ情報表示領域ＮＴＲ４には、一括精算承認確認情報として、「リクエスト精算と送金リクエスト」の相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。
この例では、一括精算承認確認情報には、一括精算の内容として、ユーザＥ．Ｅは、ユーザＡ．Ａに送信した送金リクエストに基づいて送金リクエスト金額「２，５００円」を受け取り、ユーザＡ．Ａからの今回の送金リクエストの受信に基づいて送金リクエスト金額「１，０００円」を支払うこととが表示されている。
また、一括精算承認確認情報には、一括精算金額として、ユーザＥ．ＥはユーザＡ．Ａから、受け取りの送金リクエスト金額「２，５００円」から支払いの送金リクエスト金額「１，０００円」を減算した「１，５００円」を受け取ることが表示されている。
一括精算承認確認情報の下部には、上記の内容で精算を承認するための「精算する」と示された精算ボタンＢＴ１４と、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
図１１－５は、上記の精算ボタンＢＴ１４がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
現在位置表示領域ＣＬＲ１の下には、サーバ１０を介してユーザＥ．Ｅの端末２０Ｅから送金リクエストの一括精算が承認され、その結果送金が行われた通知として、ベルのマークとともに、「１，５００円を送金しました。」の文字を含む通知ＮＴ３が表示されている。
また、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、上記の通知ＮＴ３に対応する情報が表示される。
具体例には、ユーザＥ．Ｅとの間で一括精算が行われたことで精算結果情報が表示されている。精算結果情報には、この例では、一括精算金額として、ユーザＡ．ＡからユーザＥ．Ｅへ「１，５００円」の送金が行われたことが表示されている。
また、精算結果情報には、一括精算の内容として、過去の送金リクエストの受信に基づいて「２，５００円」を支払い、今回の送金リクエストの送信に基づいて「１，０００円」を受け取ることが表示されている。
なお、図１１－３において、送金リクエスト送信一括精算ボタンＢＴ１３がタップされる場合、端末２０Ａの表示部２４に、精算が行われる場合、ユーザＡ．Ａは「１，０００円」を受け取ることになる旨の確認用画面を表示させ、ユーザＡ．Ａの承認に基づいて送金リクエストの送信と選択された未処理リクエストの一括精算との実行が依頼されるようにしてもよいし、そのようにしなくてもよい。
＜処理＞
図１１－６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートは、図１－１８のフローチャートを、新規処理対象を「送金リクエストを送信」とする処理に書き換えたフローチャートである。
送金リクエストを行うこと（送金リクエストの送信）は、厳密には、精算（一括精算を含む。）とは意味合い・概念が異なると考えることもできる。しかし、ここでは簡明化のため、送金リクエストを行うこと（送金リクエストの送信）も精算の一種であるものとして、処理（フローチャート）を図示・説明する。
なお、これとは異なり、送金リクエストを行うこと（送金リクエストの送信）を精算とは別の処理として、フローチャートを構成することもできる。
また、本実施例における（Ｃ）のパターンの処理では、限定ではなく例として、（Ｃ１）の処理を行う場合は相手のユーザの承認を不要とし、（Ｃ２）の処理を行う場合は相手のユーザの承認を必要とすることができる。
ここでは、簡単のため、相手のユーザの承認を不要とする場合の処理（フローチャート）を例示する。
最初に、端末２０Ａの制御部２１は、入力部に対して送金リクエストの送信を実行するための入力がなされたか否かに基づいて、送金リクエストの送信を行うか否かを判定する（Ａ１０７）。
送金リクエストの送信を行うと判定したならば（Ａ１０７：ＹＥＳ）、端末２０Ａの制御部２１は、Ａ１１０の処理を実行する。その後、通信Ｉ／Ｆ２２によってサーバ１０から送金リクエスト一覧情報を受信したことに基づいて、端末２０Ａの制御部２１は、受信した送金リクエスト一覧情報を含む送金リクエスト送信画面（送金リクエスト送信用の画面）を表示部２４に表示させる（Ａ１２７）。
その後、端末２０Ａの制御部２１は、送金リクエスト一覧情報の中から未処理リクエストが選択されたか否かを判定する（Ａ１３５）。
未処理リクエストが選択された場合、つまり、送金リクエストの送信＋未処理リクエストの処理の実行を要求すると判定したならば（Ａ１３５：ＹＥＳ）、端末２０Ａの制御部２１は、実行する送金リクエストの送信に関する送金リクエスト送信情報と、選択された未処理リクエストを示す未処理リクエスト選択情報とを含むリクエスト選択情報を設定する（Ａ１３６）。
一方、送金リクエスト一覧情報の中から未処理リクエストが選択されなかった場合、つまり、送金リクエストの送信のみを実行すると判定した場合（Ａ１３５：ＮＯ）、端末２０Ａの制御部２１は、送金リクエスト送信情報を含むリクエスト選択情報を設定する（Ａ１３７）。
なお、この処理では、送金リクエストの送信を行うことを前提として説明する。
実際には、送金リクエストの送信を行わずに、未処理リクエストのみを処理することが選択される場合もあり得るが、この場合の処理は、前述した未処理リクエストの一括精算の処理と同様となるため、図示・再度の説明を省略する。
Ａ１３６またはＡ１３７の後、端末２０Ａの制御部２１は、設定されたリクエスト選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。
そして、端末２０Ａの制御部２１は、Ａ１５０に処理を移す。
Ｓ１４０において端末２０Ａからリクエスト選択情報を受信したと判定したならば（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、受信したリクエスト選択情報に含まれる情報に基づいて、送金リクエスト送信＋未処理リクエスト、を処理するか否かを判定する（Ｓ１４４）。そして、処理すると判定したならば（Ｓ１４５：ＹＥＳ）、サーバ１０の制御部１１は、送金リクエスト送信＋選択された未処理リクエストの精算（複数選択された場合は一括精算）、を一括精算対象として設定する（Ｓ１４６）。
一方、送金リクエスト送信＋未処理リクエスト、の処理ではない、つまり、送金リクエスト送信のみを実行すると判定したならば（Ｓ１４５：ＮＯ）、サーバ１０の制御部１１は、送金リクエスト送信を精算対象として設定する（Ｓ１４７）。
Ｓ１４６またはＳ１４７の後、サーバ１０の制御部１１は、Ｓ１５０の精算処理を実行する。
限定ではなく例として図１－１９で説明した第１の精算処理を適用する場合、
Ｓ１４６の設定がなされた場合、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＹＥＳ」となる。その結果、送金リクエスト送信＋選択された未処理リクエストの精算、を一括精算対象として、Ｓ１５１５以降の処理が実行される。
一方、Ｓ１４７の設定がなされた場合、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＮＯ」となる。その結果、送金リクエスト送信を精算対象として、Ｓ１５７０以降の処理が実行される。
＜第１１実施例の効果＞
本実施例は、第１情報は、提案者のユーザから相手のユーザに送金リクエストを送信するための送金リクエスト送信情報（限定ではなく、端末のユーザから第１ユーザへ送信する送金依頼に関する情報の一例）であり、第２情報は、相手のユーザから受信済みの送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する情報の一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザから第１ユーザへ送信する送金依頼と、第２ユーザから端末のユーザに送信された送金依頼とを、併せて処理することができる。
また、この場合に、第１処理は、送金リクエスト送信情報に基づいて相手のユーザに送金リクエスト情報を送信し、受信済み送金リクエスト情報に基づいて相手のユーザに送金する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザへの送金依頼と、第２ユーザへの送金とを、併せて行うことができる。
また、本実施例は、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、相手のユーザに送信する送金リクエスト情報に含まれる送金リクエスト金額と、相手のユーザからの受信済み送金リクエスト情報に含まれる送金リクエスト金額とに基づく金額を、相手のユーザに送金する、または相手のユーザから受金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とに基づく金額を第１ユーザに送金する、または第１ユーザから送金してもらって受け取ることができる。
また、この場合に、第１処理は、相手のユーザからの受信済み送金リクエスト情報に含まれる送金リクエスト金額（第２金額）から、相手のユーザに送信する送金リクエスト情報に含まれる送金リクエスト金額（第１金額）を差し引いた金額を、相手のユーザに送金する処理、または相手のユーザに送信する送金リクエスト情報に含まれる送金リクエスト金額（第１金額）から、相手のユーザからの受信済み送金リクエスト情報に含まれる送金リクエスト金額（第２金額）を差し引いた金額を、相手のユーザから受金する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、一人の同じユーザを相手として、第１金額と第２金額との差額分の金額を送金する、または第１金額と第２金額との差額分の金額を送金してもらって受け取ることができる。
また、本実施例は、第１処理は、相手のユーザの端末に対する入力に基づく、相手のユーザによる承認に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの端末に対する入力に基づく、第１ユーザによる承認に基づいて、第１処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザの意に沿わずに第１処理が実行されることを防止することができる。
＜第１２実施例＞
第１２実施例は、前述した（Ｄ）のパターンの処理に関する実施例である。
第１２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、未処理リクエストのうちの「送信済み送金リクエスト」を一括精算対象に含めるのに加えて、「送金リクエストの送信」を一括精算対象に含めて一括精算を行う。
図９－６のテーブルを再び参照して説明する。
本実施例では、（Ｄ）送金リクエストを送信＋送信済み送金リクエスト、のパターンの処理を行う。
このパターンでは、（Ｄ１）送金リクエスト＋［送金リクエストｏｒ送金リマインド］、（Ｄ２）統合送金リクエスト、のいずれかの処理を行うことができる。
（Ｄ１）の処理では、相手のユーザへの新規の送金リクエストを行う際に、相手のユーザへの送信済み送金リクエストに基づいて、相手のユーザへの送金リクエスト、または相手のユーザへの送金リマインドを併せて行う。
なお、この場合に、送信済み送金リクエストに基づく送金リクエストを送信済み送金リクエストと同じ送金リクエストとして、新規の送金リクエストと送信済み送金リクエストとの異なる２つの送金リクエストを相手のユーザに送付するようにしてもよいし、送信済み送金リクエストに基づく送金リクエストを送金リマインドとして、新規の送金リクエストと送金リマインドとを相手のユーザに送付するようにしてもよい。
（Ｄ２）の処理では、相手のユーザへの新規の送金リクエストを行う際に、この新規の送金リクエストと、相手のユーザへの送信済み送金リクエストに基づく送金リクエストとをまとめた（統合した）リクエストとして、統合送金リクエストを相手のユーザに送信する。
＜表示画面＞
上記（Ｄ１）、（Ｄ２）それぞれの処理を行う場合の表示画面例について説明する。
図１２－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金リクエスト画面である。画面構成の詳細については、限定ではなく例として、図１１－３と同様に構成することが可能なため、詳細については説明を省略する。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、２つ目の送信済み送金リクエスト（受取 １，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送信一括精算ボタンＢＴ１３がタップされると、端末２０Ａからサーバ１０に対して、新規の送金リクエスト送信と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、新規の送金リクエスト情報と、過去の送金リクエスト送信に基づく送金リマインド情報とが送信され、端末２０Ｅの表示部２４に表示される。
図１２－２は、上記の送金リクエスト送信一括精算ボタンＢＴ１３がタップされたことに基づいて端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ４には、図１２－１において選択された１件の送金リクエストに関するリマインド情報（この例では、ユーザＡ．ＡからユーザＥ．Ｅへの送金リクエスト金額「１，０００円」の送金リクエストに関するリマインド）と、新規の送金リクエスト情報（この例では、ユーザＡ．ＡからユーザＥ．Ｅへの送金リクエスト金額「１，５００円」の送金リクエスト）とが表示されている。
また、一括精算処理において、新規の送金リクエストと、過去の送金リクエストとを統合することもできる。
図１２－３は、この場合の端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
おしらせ情報表示領域ＮＴＲ４には、一括精算承認確認情報として、「送金リクエスト」の相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。この例では、一括精算金額として、ユーザＥ．Ｅは、ユーザＡ．Ａに送金リクエスト金額「１，０００円」と送金リクエスト金額「１，５００円」とを加算した「２，５００円」を支払うことが表示されている。
また、一括精算承認確認情報には、一括精算の内容として、ユーザＥ．Ｅは、ユーザＡ．ＡがユーザＥ．Ｅに送信した過去の送金リクエストに基づいて送金リクエスト金額「１，０００円」を支払い、今回の送金リクエストに基づいて送金リクエスト金額「１，５００円」を支払うこととが表示されている。
一括精算承認確認情報の下部には、上記の内容で精算を承認するための「精算する」と示された精算ボタンＢＴ１５と、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
図１２－４は、上記の精算ボタンＢＴ１５がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
現在位置表示領域ＣＬＲ１の下には、サーバ１０を介してユーザＥ．Ｅの端末２０Ｅから送金リクエストの一括精算が承認され、その結果ユーザＥ．Ｅから送金を受けた通知として、ベルのマークとともに、「送金がありました。」の文字を含む通知ＮＴ４が表示されている。
また、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、上記の通知ＮＴ４に対応する情報が表示される。
具体例には、ユーザＥ．Ｅとの間で一括精算が行われたことで精算結果情報が表示されている。精算結果情報には、この例では、ユーザＡ．Ａは、ユーザＥ．Ｅへの送金リクエスト金額「１，０００円」と送金リクエスト金額「１，５００」とを加算した一括精算金額「２，５００円」の送金を受け取ったことが表示されている。
また、精算結果情報には、一括精算の内容として、ユーザＡ．Ａは、ユーザＥ．Ｅへの過去の送金リクエストの送信に基づいて送金リクエスト金額「１，０００円」を受け取り、今回の送金リクエストの送信に基づいて送金リクエスト金額「１，５００円」を受け取ったことが表示されている。
＜処理＞
本実施例において各装置が実行する処理は、図１１－６の処理に倣って同様に実現することができるため、図示および詳細な説明を省略する。
＜第１２実施例の効果＞
本実施例は、第１情報は、提案者のユーザから相手のユーザに送金リクエストを送信するための送金リクエスト送信情報（限定ではなく、端末のユーザから第１ユーザへ送信する送金依頼に関する情報の一例）であり、第２情報は、提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２端末のユーザに送信された送金依頼に関する情報の一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザから第１ユーザへの送金依頼と、端末のユーザから第２端末のユーザへの送金依頼とを、併せて処理することができる。
また、上記において、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、送金リクエスト送信情報に基づいて相手のユーザに送金リクエスト（限定ではなく、第１送金依頼の一例）を送信し、送信済み送金リクエスト情報に基づいて相手のユーザに送金リクエストまたは送金リマインド（限定ではなく、第２送金依頼の一例）を送信する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザへの第１送金依頼と、第１ユーザへの第２送金依頼とを、併せて行うことができる。
また、上記において、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、相手のユーザに送る送金リクエストの送金リクエスト金額と、送信済み送金リクエスト情報に含まれる送金リクエスト金額とを合算した金額を送金リクエスト金額とする統合送金リクエスト（限定ではなく、第３送金依頼の一例）を第１ユーザに送信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と第２金額との合計である第３金額に基づく、まとまった第３送金依頼を第１ユーザに送信することで、端末のユーザへの送金を行うように第１ユーザに効果的に促すことができる。
＜第１３実施例＞
第１３実施例は、前述した（Ｅ）のパターンの処理に関する実施例である。
第１３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、未処理リクエストのうちの「受信済み送金リクエスト」および「送信済み送金リクエスト」を一括精算対象に含めるのに加えて、「送金リクエストの送信」を一括精算対象に含めて一括精算を行う。
図９－６のテーブルを再び参照して説明する。
このパターンでは、（Ｅ１）送金リクエスト＋［送金＋受金］（金額差し引き可）、（Ｅ２）［受金＋送金］（金額差し引き可）＋［送金リクエストｏｒ送金リマインド］、（Ｅ３）［受金＋送金］（金額差し引き可）＋［送金＋受金］（金額差し引き可）、のいずれかの処理を行うことができる。
（Ｅ１）の処理では、相手のユーザへの新規の送金リクエストを行う際に、相手のユーザからの受信済み送金リクエストと相手のユーザへの送信済み送金リクエストとに基づいて送金と受金とを併せて行う。この場合、送金リクエスト金額の差額分の金額を送金する／受金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
（Ｅ２）の処理では、相手のユーザへの新規の送金リクエストを行う際に、この新規の送金リクエストに基づいて相手のユーザから送金してもらって受金するとともに、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザへの送金を併せて行う。この場合、送金リクエスト金額の差額分の金額を受金する／送金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
また、相手のユーザへの送信済み送金リクエストに基づいて、同じ送金リクエストを相手のユーザに行う、または送金リマインドを相手のユーザに行う。
（Ｅ３）の処理では、相手のユーザへの新規の送金リクエストを行う際に、この新規の送金リクエストに基づいて相手のユーザから送金してもらって受金するとともに、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザへの送金を併せて行う。この場合、送金リクエスト金額の差額分の金額を受金する／送金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
また、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザに送金するとともに、相手のユーザへの送信済み送金リクエストに基づいて相手のユーザから送金してもらって受金する。この場合、送金リクエスト金額の差額分の金額を送金する／受金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
＜表示画面＞
図１３－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金リクエスト画面である。画面構成の詳細については、限定ではなく例として、図１１－１と同様に構成することが可能なため、詳細については説明を省略する。なお、図１３－１では、限定ではなく例として、送金リクエストの送信先として選択されたユーザ（この例では、ユーザＥ．Ｅ）への送金リクエスト金額を「１，２００円」とする。
限定ではなく例として、未処理リクエスト確認領域ＵＲＲ１において、１つ目の受信済み送金リクエスト（支払い ２，５００円）と、２つ目の送信済み送金リクエスト（受取 １，０００円）との両リクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送信一括精算ボタンＢＴ１３がタップされると、端末２０Ａからサーバ１０に対して、新規の送金リクエスト送信と、選択された未処理リクエストの一括精算との実行が依頼される。すると、サーバ１０から相手方であるユーザＥ．Ｅの端末２０Ｅに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｅの表示部２４に表示される。
図１３－２は、送金リクエスト送信一括精算ボタンＢＴ１３がタップされたことに基づいて表示されるおしらせ画面の一例を示す図である。
おしらせ情報表示領域ＮＴＲ４には、一括精算承認確認情報として、「リクエスト精算と送金リクエスト」の相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。
この例では、一括精算承認確認情報には、一括精算の内容として、ユーザＥ．Ｅは、ユーザＡ．Ａへの過去の送金リクエストの送信に基づいて送金リクエスト金額「２，５００円」を受け取り、ユーザＡ．Ａからの過去の送金リクエストの受信に基づいて送金リクエスト金額「１，０００円」を支払い、ユーザＡ．Ａからの今回の送金リクエストの受信に基づいて送金リクエスト金額「１，２００円」を支払うこととが表示されている。
また、一括精算承認確認情報には、一括精算金額として、ユーザＥ．Ｅは、ユーザＡ．Ａから受け取る送金リクエスト金額「２，５００円」からユーザＡ．Ａへ支払う送金リクエスト金額「１，０００円」と送金リクエスト金額「１，２００円」とを減算した「３００円」を受け取ることが表示されている。
一括精算承認確認情報の下部には、上記の内容で精算を承認するための「精算する」と示された精算ボタンＢＴ１６と、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
図１３－３は、上記の精算ボタンＢＴ１６がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
現在位置表示領域ＣＬＲ１の下には、サーバ１０を介してユーザＥ．Ｅの端末２０Ｅから送金リクエストの一括精算が承認され、その結果送金が行われた通知として、ベルのマークとともに、「３００円を送金しました。」の文字を含む通知ＮＴ５が表示されている。
また、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、上記の通知ＮＴ５に対応する情報が表示される。
具体例には、ユーザＥ．Ｅとの間で一括精算が行われたことで精算結果情報が表示されている。精算結果情報には、この例では、一括精算金額として、ユーザＡ．ＡはユーザＥ．Ｅへ「３００円」を支払ったことが表示されている。
また、精算結果情報には、一括精算の内容として、ユーザＡ．Ａは、ユーザＥ．Ｅからの過去の送金リクエストの受信に基づいて送金リクエスト金額「２，５００円」を支払い、ユーザＥ．Ｅへの過去の送金リクエストの送信に基づいて送金リクエスト金額「１，０００円」を受け取り、ユーザＥ．Ｅへの今回の送金リクエストの送信に基づいて送金リクエスト金額「１，２００円」を受け取ったことが表示されている。
＜処理＞
上記（Ｅ１）～（Ｅ３）に関する処理は、先の実施例で説明した処理に基づき同様に構成可能であり、自明であるため、図示および詳細な説明は省略する。
＜第１４実施例＞
第１４実施例は、前述したパターンとは異なるパターンの処理に関する実施例である。
第１４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
前述したパターンの他にも、限定ではなく例として、図９－６のテーブルにおける新規処理対象同士の組合せのパターン、つまり、
・送金＋送金リクエストを送信
のパターンの処理を行うようにすることも可能である。
このパターンの処理は、パターン（Ｃ）の処理と同様となる。
つまり、「送金＋送金リクエストを送信」、「送金＋受金（金額差し引き可）」のいずれかの処理を行うことができる。
なお、「送金＋受金（金額差し引き可）」の処理を行う場合に、相手のユーザの承認を必要として、相手のユーザの承認を得るようにしてもよいし、しなくてもよい。
＜第１４実施例の効果＞
本実施例は、第１情報は、提案者のユーザから相手のユーザへの送金リクエスト情報であり、提案者のユーザの端末２０は、提案者のユーザから相手のユーザへ送信する送金リクエスト情報（限定ではなく、第３情報の一例）に基づく第３表示を表示部２４に表示する。そして、提案者のユーザの端末２０は、提案者のユーザによる、提案者のユーザから相手のユーザへの送金表示（限定ではなく第１表示の一例）と、上記の第３表示とが表示された端末２０に対する入力に基づいて、送金、または受金、または送金リクエストに関する第２処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金、または送金の受け取り、または送金の依頼を併せて行うことができる。
また、上記において、第２処理は、送金情報（限定ではなく、第１情報の一例）に基づいて相手のユーザに送金し、提案者のユーザから相手のユーザへ送信する送金リクエスト情報に基づいて相手のユーザに送金リクエストを送信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報に基づく第１ユーザへの送金と、第３情報に基づく第１ユーザへの送金依頼の送信とを併せて行うことができる。
また、上記において、第２処理は、提案者のユーザが相手のユーザに送金する金額と、提案者のユーザが相手のユーザに依頼する送金リクエスト金額とに基づく金額（限定ではなく、第１情報と第３情報とに基づく金額の一例）を相手のユーザに送金する、または相手のユーザから受金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第３情報とに基づく金額を第１ユーザに支払う、または第１ユーザから受け取ることができる。
また、この場合、第２処理は、提案者のユーザが相手のユーザに送金する金額から、提案者のユーザが相手のユーザに依頼する送金リクエスト金額を差し引いた金額を相手のユーザに送金する、または提案者のユーザが相手のユーザに依頼する送金リクエスト金額から、提案者のユーザが相手のユーザに送金する金額を差し引いた金額を相手のユーザから受金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額と第３金額との差額分の金額を第１ユーザに支払う、または第１ユーザから受け取ることができる。
また、この場合、第２処理は、相手のユーザ（限定ではなく、第１ユーザの一例）の端末２０に対する入力に基づく、相手のユーザによる承認に基づいて実行されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１ユーザの端末に対する入力に基づく、第１ユーザによる承認に基づいて、第２処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザの意に沿わずに第２処理が実行されることを防止することができる。
＜第１５実施例＞
第１５実施例は、第１４実施例と同様に、前述したパターンとは異なるパターンの処理に関する実施例である。
第１５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
前述したパターンの他にも、限定ではなく例として、図９－６のテーブルの横方向に示した、未処理リクエスト同士の組合せのパターン、つまり、
・受信済み送金リクエスト＋送信済みリクエスト
のパターンの処理を行うようにすることも可能である。
このパターンの処理は、パターン（Ｂ）の処理と同様となる。
つまり、「送金＋受金（金額差し引き可）」、「送金＋送金リクエストを送信」のいずれかの処理を行うことができる。
なお、「送金＋受金（金額差し引き可）」の処理を行う場合に、相手のユーザの承認を必要として、相手のユーザの承認を得るようにしてもよいし、しなくてもよい。
＜第１５実施例の効果＞
本実施例は、第２情報は、相手のユーザから提案者のユーザへの送金リクエスト情報であり、提案者のユーザの端末２０は、提案者のユーザから相手のユーザへ送信された送信済み送金リクエスト情報（限定ではなく、第４情報の一例）に基づく第４表示を表示部２４に表示する。そして、提案者のユーザの端末２０は、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２情報の一例）に基づく第２表示と、上記の第４表示とが表示された端末２０に対する入力に基づいて、送金、または受金、または送金リクエストに関する第３処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、送金、または送金の受け取り、または送金の依頼を併せて行うことができる。
また、上記の第３処理は、受信済み送金リクエスト情報に基づいて相手のユーザに送金し、送信済み送金リクエスト情報に基づいて相手のユーザに送金リクエストを送信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報に基づく第２ユーザへの送金と、第４情報に基づく第２ユーザへの送金依頼の送信とを併せて行うことができる。
また、上記の第３処理は、受信済み送金リクエスト情報と送信済み送金リクエスト情報とに基づく金額を相手のユーザに送金する、または相手のユーザから受金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報と第４情報とに基づく金額を第２ユーザに支払う、または第１ユーザから受け取ることができる。
また、上記の第３処理は、受信済み送金リクエスト情報の送金リクエスト金額から送信済み送金リクエスト情報の送金リクエスト金額を差し引いた金額を相手のユーザに送金する、または送信済み送金リクエスト情報の送金リクエスト金額から受信済み送金リクエスト情報の送金リクエスト金額を差し引いた金額を相手のユーザから受金する処理を含む構成を示している。
このような構成により得られる実施例の金額として、第２金額と第４金額との差額分の金額を第２ユーザに支払う、または第２ユーザから受け取ることができる。
また、この場合、第３処理は、相手のユーザ（限定ではなく、第２ユーザの一例）の端末２０に対する入力に基づく、相手のユーザによる承認に基づいて実行されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２ユーザの端末に対する入力に基づく、第２ユーザによる承認に基づいて、第３処理が実行されるようにすることができる。これにより、限定ではなく例として、第２ユーザの意に沿わずに第３処理が実行されることを防止することができる。
＜第１６実施例＞
第１６実施例は、送金リクエスト情報の表示手法に関する実施例である。
第１６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図１４－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションの送金画面である。
現在位置表示領域ＣＬＲ１の下には、送金先として選択されたユーザの支払いアプリケーションにおけるアイコン画像およびユーザ名（この例ではユーザＣ．Ｃ）が表示されている。
送金金額を一定額増額させるための機能ボタンの下には、送金先として選択されたユーザ（この例ではユーザＣ．Ｃ）と、送金を行うユーザ（この例ではユーザＡ．Ａ）との未処理リクエストを確認可能にするために構成された未処理リクエスト確認領域ＵＲＲ３が表示されている。
未処理リクエスト確認領域ＵＲＲ３最上部には、ユーザＣ．Ｃとの間の未処理リクエストを表示していることを示す「Ｃ．Ｃとの未精算リクエスト」の文字が表示されている。
その右側には、未処理の送金リクエストの表示順を変更させるための送金リクエスト履歴ソートボタンＳＴＢ１が表示されている。他の表示態様は未処理リクエスト確認領域ＵＲＲ１と同様である。
送金リクエスト履歴ソートボタンＳＴＢ１がタッチされると、限定ではなく例として、画面下部からソート順を選択するためのソート選択領域がせり上がり表示される。
ソート選択領域に対するユーザ操作に基づいて、未処理の送金リクエストの表示順を、限定ではなく例として、送金リクエストを送信／受信した日付順や、送金リクエストの送金リクエスト金額等によって、昇／降順に並び変え、表示させることができる。
なお、送金リクエストを送信／受信した日付順に代えて、送金リクエストを送信／受信した日時順で、未処理の送金リクエストの表示順を並び替え、表示させるようにすることもできる。
図１４－２は、限定ではなく例として、ソート選択領域に対するユーザ操作に基づいて、未処理リクエスト確認領域ＵＲＲ３の送金リクエストを、送金リクエスト金額で降順に並び替えた場合における表示画面の一例を示す図である。
図１４－１では、未処理リクエスト確認領域ＵＲＲ３の送金リクエストは、日付に関する昇順で並んでいるが、図１４－２では、送金リクエスト金額に関する降順に並び替えられている。
なお、送金リクエストに対して支払い期限が設定される場合、限定ではなく例として、その支払い期限が迫る順に送金リクエストを表示させるようにしてもよいし、そうしなくてもよい。支払い期限を設定するのは、一般ユーザ間（ＣｔｏＣ）での支払いの他、限定ではなく例として、金融機関等の事業者からの融資・ローン（ＣｔｏＢ）の返済期限を設定することも含まれる。
また、送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエストを、優先的に表示させるようにしてもよい。限定ではなく例として、他のユーザが割り勘のメンバーとして含まれているような場合である。
また、未処理リクエスト確認領域ＵＲＲ３には、未処理の送金リクエストが表示されることとしたが、これに限定されない。
図１４－３は、未処理リクエスト確認領域ＵＲＲ３に処理済みの送金リクエストを混在させた場合の表示画面の一例である。
図１４－３では、限定ではなく例として、未処理リクエスト確認領域ＵＲＲ３の１つ目の送金リクエストには、送金リクエスト金額「１，０００円」の支払いに関する送金リクエストを受信したことが、処理済みの送金リクエストであることを表すグレーアウトの表示態様で表示されている。処理済みの送金リクエストは一括精算対象として選択されないため、チェック領域は存在しない。
＜第１６実施例の効果＞
本実施例は、提案者のユーザの端末２０は、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第４情報の一例）、または提案者のユーザが相手のユーザに送信済みの送信済み送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第４情報の一例）に基づく第４表示を表示部２４に表示する。そして、提案者のユーザの端末２０は、前述した第２情報と上記の第４情報とに基づく順序で、第２表示と第４表示とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報と第４情報とに基づく適切な順序で、第２表示と第４表示とを表示することができる。
また、本実施例は、上記の第２情報と第４情報とは、送金リクエストを送信／受信した日付に関する情報（限定ではなく、日付に関する情報の一例）、または送金リクエストを送信／受信した日時に関する情報（限定ではなく、日時に関する情報の一例）を含み、第２表示と第４表示を表示する順序は、この日付または日時に関する情報に基づき決定される構成を示している。
このような構成により得られる実施例の効果の一例として、日時または日付に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
また、本実施例は、上記の第２情報と第４情報とは、送金依頼する金額に関する情報（限定ではなく、金額に関する情報の一例）を含み、第２表示と第４表示を表示する順序は、この金額に関する情報に基づき決定される構成を示している。
このような構成により得られる実施例の効果の一例として、金額に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
また、この場合、送金依頼する金額に関する情報には、送金リクエスト金額の他、限定ではなく例として、支払い期限に関する情報を含めることができる。
このような構成により得られる実施例の効果の一例として、支払い期限に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
次に、第９実施例～第１６実施例とは逆の考え方として、端末２０のユーザが、相手のユーザから送金された金額を受け取ったり（受金したり）、相手のユーザから送金リクエストを受信する場合の処理に関する実施例について説明する。
＜第１７実施例＞
第１７実施例は、端末２０のユーザが、相手のユーザから送金された金額を受け取ったり、相手のユーザから送金リクエストを受信する際に、未処理リクエストを表示する実施例である。
第１７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図１５－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションのおしらせ機能であることを示す「おしらせ」の文字が表示されている。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金の受け取り（受金）に関する内容として、送金結果情報ＮＣ１が表示されている。
なお、サーバ１０にとっては送金処理を行った結果であるため送金結果情報であり、相手のユーザ（この例ではユーザＢ．Ｂ）にとっても送金結果情報であるが、自分（この例ではユーザＡ．Ａ）にとっては受金の結果であるため受金結果情報であるとも言える。
この送金結果情報ＮＣ１には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから送金された（受金した）送金金額「５００円」の受け取りに対応する内容が表示されている。
その下には、送金を受け取った時点で受金したユーザ（この例ではユーザＡ．Ａ）の未処理である送金リクエストが一覧表示されている。この例では、４件の未処理リクエストが古い順に時系列で一覧表示されている。各々の未処理リクエストの表示態様については、限定ではなく例として、図１－２３と同様に構成可能なため、再度の説明は省略する。
なお、未処理リクエストとして、送金されたユーザ（この例ではユーザＡ．Ａ）と、送金を行ったユーザ（この例ではユーザＢ．Ｂ）との未処理リクエストのみを表示するようにしてもよいし、そのようにしなくてもよい。
このように、本実施例では、送金結果（受金結果）の情報とともに、未処理リクエストを表示することで、送金された金額をユーザが受け取ったことを確認する場合に、未処理リクエストを併せて確認することができるように構成されている。
図１５－２は、本実施例において端末２０の表示部２４に表示される画面の別例を示す図である。この画面は、図１５－１に対応するが、その表示内容が一部異なっている。
具体的には、限定ではなく例として、送金結果情報ＮＣ１内に、送金を承諾して受け取るための、「送金受け取り」と示された送金受け取りボタンが表示されている。
ユーザＡ．Ａによって送金受け取りボタンがタップされるまでは、送金処理は完了しておらず、送金受け取りボタンがタップされると、送金されたユーザ（この例ではユーザＡ．Ａ）の電子マネー口座残高に送金金額（この例では「５００円」）が加算される。
この例では、相手のユーザ（第１ユーザや第２ユーザ）から提案者のユーザ（端末のユーザ）に送金される場合に、提案者のユーザ側で、送金される金額の受け取り（受金）をとめることが可能に構成されている。
詳細は後述するが、これを「送金の受け取りの保留」や「受金の保留」と称する。
なお、送金が未完了となるため、これを「送金の保留」と捉えることもできる。
このように、本実施例では、送金の受け取りが保留される送金結果（受金結果）の情報とともに、未処理リクエストを表示することで、送金された金額をユーザが受け取るか否かを判断する場合に、未処理リクエストを併せて確認することができるように構成されている。
図１５－３は、本実施例において端末２０の表示部２４に表示される画面の別例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金リクエストの受信に関する内容として、送金リクエスト情報ＮＣ７が表示されている。
送金リクエスト情報ＮＣ７には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから受信した送金リクエスト金額「５００円」の送金リクエストに対応する内容が表示されている。また、送金リクエスト情報ＮＣ７には、この送金リクエストに承諾して送金を行うための、「送金する」と示された送金リクエスト送金ボタンと、この送金リクエストを拒否するための、「断る」と示された送金リクエスト拒否ボタンとが表示されている。
その下には、送金リクエストを受信した時点で送金リクエストを受け取ったユーザ（この例ではユーザＡ．Ａ）が未処理である送金リクエストが一覧表示されている。
なお、未処理リクエストとして、送金リクエストを受信したユーザ（この例ではユーザＡ．Ａ）と、送金リクエストを送信したユーザ（この例ではユーザＢ．Ｂ）との未処理リクエストのみを表示するようにしてもよいし、そのようにしなくてもよい。
このように、本実施例では、送金リクエストの受信結果の情報とともに、未処理リクエストを表示することで、送金リクエストを受信したことをユーザが確認する場合に未処理リクエストを併せて確認することができるように構成されている。
＜処理＞
図１５－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、一例として、図１５－１で説明した、ユーザが送金の受け取り（受金）を行う際に未処理リクエストを表示する処理について説明する。
サーバ１０の制御部１１は、不図示の端末２０Ｂからの要求に基づいて、端末２０ＡのユーザＡ．Ａに対する送金処理を実行する（Ｓ２１０）。具体的には、限定ではなく例として、ユーザＢ．Ｂの電子マネー口座残高から送金金額を減算して更新するとともに、ユーザＡ．Ａの電子マネー口座残高に送金金額を加算して更新する。
そして、サーバ１０の制御部１１は、送金結果情報と送金リクエスト一覧情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２２０）。
そして、サーバ１０の制御部１１は、処理を終了する。
なお、この場合に、サーバ１０の制御部１１が、送金結果情報を端末２０Ｂに送信するようにしてもよいし、しなくてもよい。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報と送金リクエスト一覧情報とを受信したか否かを判定し（Ａ２０５）、受信したと判定したならば（Ａ２０５：ＹＥＳ）、送金結果情報と送金リクエスト一覧情報とを含む一括精算画面を表示部２４に表示させる（Ａ２２５）。
一括精算画面は、限定ではなく例として、表示画面例に示したおしらせ画面である。
そして、端末２０Ａの制御部２１は、処理を終了する。
図１５－５は、本実施例において各装置が実行する処理の流れの別例を示すフローチャートである。ここでは、一例として、図１５－２で説明した、送金の受け取りの保留（受金の保留）を適用する場合の処理について説明する。
サーバ１０の制御部１１は、不図示の端末２０Ｂからの要求に基づいて、端末２０ＡのユーザＡ．Ａに対する第１送金処理を実行する（Ｓ３１０ａ）。具体的には、限定ではなく例として、ユーザＢ．Ｂの電子マネー口座残高から送金金額を減算して更新する。
第１送金処理では、図１５－４の送金処理（Ｓ２１０）とは異なり、送金元のユーザの電子マネー口座残高から送金金額を減算するが、送金先ユーザの電子マネー口座残高には送金金額を加算しない。この状態は、送金が未完了の状態である。
その後、サーバ１０の制御部１１は、第１送金処理の送金結果情報と、送金リクエスト一覧情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ３２０）。
なお、この場合に、サーバ１０の制御部１１が、第１送金処理の送金結果情報を端末２０Ｂに送信するようにしてもよいし、しなくてもよい。
Ａ２２５の後、端末２０Ａの制御部２１は、入力部に対して送金受け取りの入力がなされたか否かを判定し（Ａ７３０）、なされたと判定したならば（Ａ７３０：ＹＥＳ）、送金受取を要求するための送金受取情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ７４０）。
Ｓ３２０の後、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから送金受取情報を受信したか否かを判定し（Ｓ７４０）、受信したと判定したならば（Ｓ７４０：ＹＥＳ）、第２送金処理を実行する（Ｓ３１０ｂ）。具体的には、限定ではなく例として、第１送金処理の結果に基づき、ユーザＡ．Ａの電子マネー口座残高に送金金額を加算して更新する。つまり、送金の受け取り（受金）が保留された状態が解除され、完全に送金された状態となる。
その後、サーバ１０の制御部１１は、第２送金処理の送金結果情報を、通信Ｉ／Ｆ１４によって端末２０Ａおよび端末２０Ｂにそれぞれ送信する（Ｓ７９０）。
そして、サーバ１０の制御部１１は、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報を受信すると、端末２０Ａの制御部２１は、受信した送金結果情報を表示部２４に表示させる（Ａ７９０）。
そして、端末２０Ａの制御部２１は、処理を終了する。
同様に、通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報を受信すると、端末２０Ｂの制御部２１は、受信した送金結果情報を表示部２４に表示させる（Ｂ７９０）。
そして、端末２０Ｂの制御部２１は、処理を終了する。
なお、図１５－３で説明した、ユーザが送金リクエストを受信する際に未処理リクエストを表示する処理については、図１５－４の処理における「送金」（ユーザＡ．Ａにとっては受金）を「送金リクエスト受信」に置き換えることで同様に構成可能であるため、図示・説明を省略する。
具体的には、端末２０Ａの処理において、Ａ２０５で送金リクエスト送信結果情報と送金リクエスト一覧情報とを受信したか否かを判定し、Ａ２２５でこれらの情報を含む一括精算画面を表示する。
また、サーバ１０の処理において、Ｓ２１０で送金リクエスト送信処理を実行し、Ｓ２２０で送金リクエスト送信結果情報と送金リクエスト一覧情報とを送信する。
＜未処理リクエストの表示＞
端末２０の表示部２４に表示する未処理リクエストは、限定ではなく例として、以下のいずれか一方、または両方とすることができる。
・自分に対して送金する相手のユーザ（送金元ユーザ）、または自分に対して送金リクエストを送信する相手のユーザ（送金リクエスト元ユーザ）に対応する未処理リクエスト
・自分に対して送金する相手のユーザ（送金元ユーザ）、または自分に対して送金リクエストを送信する相手のユーザ（送金リクエスト元ユーザ）とは異なるユーザに対応する未処理リクエスト
相手のユーザに対応する未処理リクエストを表示するようにすることができる。限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂを送金元ユーザとして送金受け取りを行う場合や、ユーザＡ．ＡがユーザＢ．Ｂを送金リクエスト元ユーザとして送金リクエストを受信する場合は、ユーザＢ．Ｂに対応する未処理リクエストを表示することができる。
しかし、ユーザによっては、相手のユーザとは異なるユーザに対応する未処理リクエストを確認したいと思うことも考えられる。
そこで、図１５－１～図１５－３に例示したように、ユーザＢ．Ｂに対応する未処理リクエストに加えて、限定ではなく例として、ユーザＣ．Ｃに対応する未処理リクエストを表示するようにすることもできる。
なお、この場合に、ユーザＢ．Ｂに対応する未処理リクエストを表示せず、限定ではなく例として、ユーザＣ．Ｃに対応する未処理リクエストを表示するようにすることもできる。
つまり、第８実施例と同様に、未処理リクエストを表示するパターンとしては、限定ではなく例として、以下の３つのパターンが考えられる。
（パターン１）相手のユーザに対応する未処理リクエスト
（パターン２）相手のユーザに対応する未処理リクエスト＋相手のユーザとは異なるユーザに対応する未処理リクエスト
（パターン３）相手のユーザとは異なるユーザに対応する未処理リクエスト
また、上記のいずれのパターンを適用する場合も、各々のユーザについて、そのユーザに対応する全部の未処理リクエストを表示するようにしてもよいし、そのユーザに対応する一部の未処理リクエストを表示するようにしてもよい。
つまり、未処理リクエストを表示するユーザ（相手のユーザ／相手のユーザとは異なるユーザ）と、表示する未処理リクエストの範囲（全部／一部）とは、任意に組み合わせることができる。限定ではなく例として（パターン２）において、相手のユーザに対応する未処理リクエストは全部の未処理リクエストを表示するが、相手のユーザとは異なるユーザに対応する未処理リクエストは一部の未処理リクエストを表示するなどしてもよい。
また、一部の未処理リクエストを表示する場合、各種の情報（条件）に基づいて、表示する未処理リクエストを決定することもできる。
この場合、後述する第２６実施例の内容を組み合わせることができる。第２６実施例でも説明するが、各種の情報としては、限定ではなく例として、以下の情報が挙げられる。
・送金リクエストを送信／受信した日付や日時
・送金リクエスト金額
・送金リクエストの支払い期限
・送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエスト
なお、これらの情報はあくまでも一例であり、これらに限定されるものではない。
また、これらの情報のうちの複数の情報を組み合わせて適用することもできる。
日付や日時が一定以上古い未処理リクエストは、ユーザが忘れている場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
送金リクエスト金額が一定以上大きい未処理リクエストは、重要性が高い場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエストも、重要性が高い場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
支払い期限が一定期間内に迫っている未処理リクエストは、早急の処理を要する場合がある。このため、たとえ相手のユーザとは異なるユーザに対応する未処理リクエストであっても、表示するように決定することができる。
また、第２６実施例でも説明するが、未処理リクエストを、上記の各種の情報（条件）に基づいて昇順／降順に並び替えて表示するようにすることもできる。一例としては、重要性が高い未処理リクエストほど、上位に表示されるようにすることができる。
これらの他にも、端末２０の表示部２４に表示する未処理リクエストを、限定ではなく例として、入力部に対する端末２０のユーザの入力に基づいて非表示にすることができる。
この場合、限定ではなく例として、一部のユーザに対応する未処理リクエストを非表示としてもよいし、全てのユーザに対応する未処理リクエストを非表示としてもよい。
また、ユーザによっては、未処理リクエストが表示されることに煩わしさを感じる場合もあると考えられる。
そこで、未処理リクエストの表示／非表示の設定を、不図示の設定画面等において行うことを可能としてもよい。
具体的には、アプリケーションの設定画面において、未処理リクエストの表示に関する設定用情報として、限定ではなく例として、未処理リクエストの表示／非表示を切替可能なスライドボタンやチェックボックスを表示させる。そして、このスライドボタンやチェックボックスに対する操作に基づいて、表示／非表示の設定を端末２０またはサーバ１０に行わせるようにすることができる。
この場合、全部のユーザについて一括的に未処理リクエストの表示／非表示を設定可能としてもよいし、ユーザごとに個別に未処理リクエストの表示／非表示を設定可能としてもよい。
また、全部の未処理リクエストの表示／非表示を設定可能としてもよいし、一部の未処理リクエストの表示／非表示を設定可能としてもよい。
なお、これらの内容は、以下の実施例についても同様である。
＜第１７実施例の効果＞
本実施例は、提案者のユーザの端末２０が、相手のユーザからの送金結果情報（限定ではなく、第１ユーザから端末のユーザへの送金に関する第１情報の一例）、または相手のユーザから送信された送金リクエスト情報（限定ではなく、第１ユーザから端末のユーザへ送信された送金依頼に関する第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。
そして、提案者のユーザの端末２０は、受信した情報に基づく第１表示を表示部２４に表示し、第１情報の受信に基づいて、相手のユーザからの受信済み送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）や、相手のユーザへの送信済み送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザが第１情報を確認する際に、第２情報を併せて確認できるようにすることができる。
また、本実施例は、提案者のユーザの端末２０は、提案者のユーザによる、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、送金された金額を受け取るための処理（限定ではなく、送金の受け取りに関する第１処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とが表示された端末に対する入力に基づいて、相手のユーザからの送金の受け取りを簡単に実現することができる。
＜第１７変形例（１）＞
第１７実施例において、相手のユーザからの送金結果情報や相手のユーザから送信された送金リクエスト情報とともに表示される未処理リクエストの情報に対する入力に基づいて、精算（未処理リクエストの一括精算を含む。）が実行されるようにしてもよい。
具体的には、限定ではなく図１５－１～図１５－３の画面例において、選択された未処理リクエストの精算（複数選択された場合は一括精算）を実行させるための精算ボタンを表示させる。
そして、精算ボタンがタップされると、選択された未処理リクエストの精算処理がサーバ１０によって実行されるようにすることができる。
なお、未処理リクエストの精算処理については、前述した通りであるため、再度の説明を省略する。
図１５－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。ここでは、一例として、図１５－５に示した送金の受け取り保留（受金保留）の処理において、送金受け取りと、未処理リクエストの精算とのいずれか一方を行う場合の処理について説明する。
Ａ２２５の後、端末２０Ａの制御部２１は、入力部に対する入力に基づいて、実行対象を判定する（Ａ８３１）。
実行対象が未処理リクエストの精算（複数選択された場合は一括精算）であると判定したならば（Ａ８３１：未処理リクエストの精算）、端末２０Ａの制御部２１は、Ａ６３２に処理を移す。つまり、選択された未処理リクエストを示す未処理リクエスト選択情報を含むリクエスト選択情報を設定する。
一方、実行対象が送金の受け取りであると判定したならば（Ａ８３１：送金受取）、端末２０Ａの制御部２１は、送金受取情報を含むリクエスト選択情報を設定する（Ａ３３３）。
Ａ６３２またはＡ３３３の後、端末２０Ａの制御部２１は、設定されたリクエスト選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。
そして、端末２０Ａの制御部２１は、Ａ１５０に処理を移す。
Ｓ１４０において端末２０Ａからリクエスト選択情報を受信したと判定した場合（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、受信したリクエスト選択情報に基づいて、処理対象を判定する（Ｓ８４１）。
処理対象が未処理リクエストの精算であると判定したならば（Ｓ８４１：未処理リクエストの精算）、サーバ１０の制御部１１は、Ｓ６４２に処理を移す。つまり、選択された未処理リクエストを精算対象（複数選択された場合は一括精算対象）として設定する。そして、サーバ１０の制御部１１は、Ｓ１５０の精算処理を実行する。
一方、処理対象が送金の受け取りであると判定したならば（Ｓ８４１：送金受取）、サーバ１０の制御部１１は、Ｓ３１０ｂに処理を移す。つまり、第２送金処理を実行する。
そして、サーバ１０の制御部１１は、Ｓ１７０に処理を移す。
限定ではなく例として図１－１９で説明した第１の精算処理を適用する場合、
Ｓ６４２の設定がなされた場合であって、処理対象の未処理リクエストが複数である場合は、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＹＥＳ」となる。その結果、この複数の未処理リクエストを一括精算対象として、Ｓ１５１５以降の処理が実行される。
また、Ｓ６４２の設定がなされた場合であって、処理対象の未処理リクエストが１つである場合は、Ｓ１５１０における精算対象が一括精算対象であるか否かの判定結果は「ＮＯ」となる。その結果、この１つの未処理リクエストを精算対象として、Ｓ１５７０以降の処理が実行される。
なお、ユーザが送金受け取りを保留することなく、送金された金額を受け取る際に未処理リクエストを表示し、未処理リクエストの精算を行う処理については、図１５－６に倣って同様に構成可能であるため、図示・説明を省略する。
また、ユーザが送金リクエストを受信する際に未処理リクエストを表示し、送金と、未処理リクエストの精算とのいずれか一方を行う処理についても、図１５－６に倣って同様に構成可能であるため、図示・説明を省略する。
本変形例は、提案者のユーザの端末２０が、相手のユーザからの送金結果情報（限定ではなく、第１ユーザから端末のユーザへの送金に関する第１情報の一例）、または相手のユーザから送信された送金リクエスト情報（限定ではなく、第１ユーザから端末のユーザへ送信された送金依頼に関する第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。
また、提案者のユーザの端末２０は、受信した情報に基づく第１表示を表示部２４に表示し、第１情報の受信に基づいて、相手のユーザからの受信済み送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）や、相手のユーザへの送信済み送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示を表示部２４に表示する。
そして、提案者のユーザの端末２０は、提案者のユーザによる、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、送金するための処理、または送金された金額を受け取るための処理、または送金リクエストを送信するための処理、または送金リクエストを受信するための処理（限定ではなく、送金に関する、または送金の受け取りに関する、または送金の依頼に関する第１処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とが表示された端末に対する入力に基づいて、相手のユーザへの送金や、相手のユーザからの送金の受け取り、相手のユーザへの送金依頼の送信／受信を簡単に実現することができる。
＜第１７変形例（２）＞
上記の実施例では、第１情報に基づいて表示画面中の精算結果情報がレンダリングされ、表示されている。すなわち、第１表示と第２表示とは、実質的には同時に表示されている。
しかし、上記の実施例において、第１表示および第２表示の表示には、以下の２つのケースが含まれる。
（１）第１情報の受信→第１表示→第２表示
（２）第１情報の受信→第１表示、第１情報の受信→第２表示
（１）は、受信された第１情報に基づいて第１表示を表示し、表示した第１表示に基づいて第２表示を表示するケースである。
（２）は、受信された第１情報に基づいて第１表示を表示し、受信された第１情報に基づいて第２表示を表示するケースである。
いずれにせよ、第１情報の受信が契機となっていることに変わりはない。
また、第１表示および第２表示を表示する順序は、順不同とすることができる。
つまり、上記の（１）のケースを「第１情報の受信→第２表示→第１表示」としたり、上記の（２）のケースを「第１情報の受信→第２表示、第１情報の受信→第１表示」とすることもできる。
なお、このことは、以下説明する実施例についても同様である。
次に、第１７実施例に関連する実施例として、端末２０のユーザが、相手のユーザから送金された金額を受け取ったり（受金したり）、相手のユーザから送金リクエストを受信する場合に、表示された未処理リクエストの中から選択された未処理リクエストも併せて処理する実施例について説明する。
以下の実施例では、大きく分けて下記の５つのパターンについて説明する。
（ａ）受金＋受信済み送金リクエストを処理するパターン
（ｂ）受金＋送信済み送金リクエストを処理するパターン
（ｃ）受金＋受信済み送金リクエストを処理する＋送信済み送金リクエストを処理するパターン
（ｄ）送金リクエストを受信＋受信済み送金リクエストを処理するパターン
（ｅ）送金リクエストを受信＋送信済み送金リクエストを処理するパターン
各々のパターンについて、実施例を分けて説明する。
第１７変形例にも示したが、端末２０が制御部２１によって実行する処理（第１処理等）には、限定ではなく例として、送金を行うための処理（限定ではなく、送金に関する処理の一例）、送金の受け取り（受金）を行うための処理（限定ではなく、送金の受け取りに関する処理の一例）、送金リクエストを送信／受信するための処理（限定ではなく、送金の依頼に関する処理の一例）等の処理が含まれる。
なお、以下ではサーバクライアントシステムを例示し、送金や送金リクエストの送信等は、サーバ１０を介して行われるものとする。
また、以下では、前述したように、相手のユーザを一人のユーザとする場合、つまり、第２ユーザは第１ユーザである（または第１ユーザは第２ユーザである）場合を例示する。
なお、前述したように、相手のユーザを異なる複数のユーザとする場合、つまり、第１ユーザは第２ユーザとは異なるユーザである（第２ユーザは第１ユーザとは異なるユーザである）場合についても、以下説明する手法を同様に適用することができる。
＜第１８実施例＞
本実施例は、上記（ａ）のパターンの処理に関する実施例である。
第１８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図１６－１は、上記のパターンそれぞれに対応する処理方法を説明するためのテーブルの一例を示す図である。
テーブルの縦方向には項目として今から新規に実行しようとする処理の対象（新規処理対象）を、テーブルの横方向には項目として未処理リクエストの種別をそれぞれ示している。そして、縦の項目と横の項目とが交差する欄には、その新規処理対象と未処理リクエストの種別との組合せによって実現される処理の一例を示している。
順番に説明する。
（ａ）受金＋受信済み送金リクエスト、のパターンでは、（ａ１）受金＋送金、の処理を行うことができる。つまり、相手のユーザから受金を行う際に、相手のユーザからの受信済みの送金リクエストに基づいて、相手のユーザに対する送金も併せて行う。
＜表示画面＞
図１６－２は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
支払いアプリケーションにおける現在位置を示す現在位置表示領域ＣＬＲ１には、現在位置が支払いアプリケーションのおしらせ機能であることを示す「おしらせ」の文字が表示されている。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金の受け取り（受金）に関する内容として、送金結果情報ＮＣ１が表示されている。
以下では、便宜的に、送金結果情報の中に送金リクエスト一覧情報を含めて図示する場合がある。この場合、送金結果情報は一括精算情報と言ってもよい。
また、サーバ１０にとっては送金処理を行った結果であるため送金結果情報であり、相手のユーザ（この例ではユーザＢ．Ｂ）にとっても送金結果情報であるが、自分（この例ではユーザＡ．Ａ）にとっては受金の結果であるため受金結果情報であるとも言える。
この送金結果情報ＮＣ１には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから送金された（受金した）送金金額「５００円」の受け取りに対応する内容が表示されている。
その下には、送金を受け取った時点で受金したユーザ（この例ではユーザＡ．Ａ）の未処理である送金リクエストが一覧表示されている。この例では、４件の未処理リクエストが古い順に時系列で一覧表示されている。各々の未処理リクエストの表示態様については、限定ではなく例として、図１－２３と同様に構成可能なため、再度の説明は省略する。
なお、未処理リクエストとして、送金されたユーザ（この例ではユーザＡ．Ａ）と、送金を行ったユーザ（この例ではユーザＢ．Ｂ）との未処理リクエストのみを表示するようにしてもよいし、そのようにしなくてもよい。この場合、各々の未処理リクエストの表示態様については、限定ではなく例として、図１－１１と同様に構成可能である。
送金結果情報ＮＣ１の最下部には、全選択一括精算を実行させるための、「すべて精算」と示された全選択一括精算ボタンが表示されている。また、全選択一括精算ボタンの横には、送金結果情報ＮＣ１に表示される未処理リクエストのうち、ユーザによって選択された未処理リクエストの一部選択一括精算を実行させるための、「１件の精算」と示された一部選択一括精算ボタンＢＴ１７とが表示されている。
限定ではなく例として、送金結果情報ＮＣ１において、１つ目の受信済み送金リクエスト（ユーザＣ．Ｃへの支払い ２，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、一部選択一括精算ボタンＢＴ１７がタップされると、端末２０Ａからサーバ１０に対して、選択された未処理リクエストの一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃと、当方であるユーザＡ．Ａの端末２０Ａとに対して、その実行結果に関する精算結果情報が送信される。
図１６－３は、上記の一部選択一括精算ボタンＢＴ１７がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金結果情報ＮＣ１の下に、一括精算の内容として、精算結果情報ＮＣ２が表示されている。
精算結果情報ＮＣ２には、限定ではなく例として、ユーザＡ．Ａは、ユーザＣ．Ｃからの送金リクエストによる送金リクエスト金額「２，０００円」の支払いに関する精算によって、ユーザＣ．Ｃへ送金金額「２，０００円」の送金を実行したことに関する情報が表示されている。
なお、ユーザＣ．Ｃの端末２０Ｃに表示される精算結果情報には、ユーザＡ．Ａからの送金金額「２，０００円」の受け取りの表示の他、送金結果情報ＮＣ１の表示態様に従って、ユーザＣ．Ｃの未処理リクエストの一覧が付加されて表示される。
＜処理＞
図１６－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
サーバ１０の制御部１１は、端末２０Ｂからの要求に基づいて、端末２０ＡのユーザＡ．Ａに対する送金処理を実行する（Ｓ２１０）。具体的には、限定ではなく例として、ユーザＢ．Ｂの電子マネー口座残高から送金金額を減算して更新するとともに、ユーザＡ．Ａの電子マネー口座残高に送金金額を加算して更新する。
そして、サーバ１０の制御部１１は、送金結果情報と送金リクエスト一覧情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２２０）。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金結果情報と送金リクエスト一覧情報とを受信したか否かを判定し（Ａ２０５）、受信したと判定したならば（Ａ２０５：ＹＥＳ）、送金結果情報と送金リクエスト一覧情報とを含む一括精算画面を表示部２４に表示させる（Ａ２２５）。
Ａ１３１において未処理リクエストが選択されたと判定したならば（Ａ１３１：ＹＥＳ）、端末２０Ａの制御部２１は、未処理リクエスト選択情報をリクエスト選択情報として設定する（Ａ２３２）。そして、端末２０Ａの制御部２１は、Ａ１４０に処理を移す。
一方、未処理リクエストが選択されなかったと判定したならば（Ａ１３１：ＮＯ）、端末２０Ａの制御部２１は、処理を終了する。
Ｓ１４１において未処理リクエストを処理すると判定したならば（Ｓ１４１：ＹＥＳ）、サーバ１０の制御部１１は、選択された未処理リクエストの一括精算を一括精算対象として設定する（Ｓ２４２）。そして、サーバ１０の制御部１１は、Ｓ１５０に処理を移す。
また、未処理リクエストの処理ではないと判定したならば（Ｓ１４１：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
＜第１８実施例の効果＞
本実施例は、提案者のユーザの端末２０が、相手のユーザからの送金結果情報（限定ではなく、第１ユーザから端末のユーザへの送金に関する第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。
また、提案者のユーザの端末２０は、受信した送金結果情報に基づく第１表示（限定ではなく、第１表示の一例）を表示部２４に表示し、送金結果情報の受信に基づいて、相手のユーザからの受信済み送金リクエストに関する受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）に基づく第２表示（限定ではなく、第２表示の一例）を表示部２４に表示する。
そして、提案者のユーザの端末２０が、提案者のユーザによる、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、送金に関する、または受金（限定ではなく、送金の受け取りの一例）に関する第１処理を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とが表示された端末に対する入力に基づいて、送金に関する、または送金の受け取りに関する第１処理を簡易かつ適切に行うことができる。
また、本実施例は、第２情報は、送金結果情報（限定ではなく、第１ユーザからの端末のユーザへの送金に関する情報の一例）であり、第２情報は、受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する情報の一例）であり、第１処理は、第２表示が表示された端末２０への入力に基づいて、相手のユーザ（限定ではなく、第２ユーザの一例）に送金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザから端末のユーザへ送金が行われる予定であることを端末のユーザに知らせるとともに、第２表示が表示された端末への入力に基づいて、第２ユーザに送金することができる。
また、本実施例は、第１表示と第２表示とは、提案者のユーザの端末２０にインストールされた支払いアプリケーションによって表示部２４に表示され、支払いアプリケーションは、本開示に係るプログラムに含まれる構成を示している。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第１表示と第２表示とが端末の表示部に表示されるようにすることができる。
＜第１８変形例＞
上記の実施例では、提案者のユーザの端末２０で送金結果情報を受信した時点で相手のユーザからの送金が完了しているものとしたが、これに限定されない。
具体的には、前述した送金の受け取りの保留（受金の保留）の手法を適用し、第２表示が表示された状態で、送金受け取りの入力（操作等）がなされたことに基づいて、相手のユーザからの送金が完了するようにしてもよいし、しなくてもよい。
なお、このことは、他の実施例についても同様である。
＜第１９実施例＞
第１９実施例は、前述した（ｂ）のパターンの処理に関する実施例である。
第１９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
（ｂ）受金＋送信済み送金リクエスト、のパターンでは、（ｂ１）受金＋送金リマインド、の処理を行うことができる。つまり、相手のユーザから受金を行う際に、相手のユーザへの送信済み送金リクエストに基づいて、この送金リクエストに対する送金リマインドを行う。
なお、この場合に、送金リマインドではなく、新規の送金リクエストを行うようにしてもよいし、しなくてもよい。
＜表示画面＞
図１７－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。画面構成の詳細については、限定ではなく例として、図１６－２と同様に構成することが可能なため、詳細については説明を省略する。
限定ではなく例として、送金結果情報ＮＣ１において、３つ目の受信済み送金リクエスト（ユーザＣ．Ｃからの受取 １，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、一部選択一括精算ボタンＢＴ１７がタップされると、端末２０Ａからサーバ１０に対して選択された未処理リクエストの一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃに対して、その実行結果に関する精算結果情報が送信される。
図１７－２は、上記の一部選択一括精算ボタンＢＴ１７がタップされたことに基づいて端末２０Ｃの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ１には、一括精算の内容として、精算結果情報ＮＣ３が表示されている。
精算結果情報ＮＣ３には、限定ではなく例として、図１７－１で選択された３件目の送金リクエスト（ユーザＡ．ＡがユーザＣ．Ｃに送信した送金リクエスト金額「１，０００円」の送金リクエスト）に対応するリマインドが表示されている。
なお、上記の一部選択一括精算ボタンＢＴ１７がタップされると、端末２０Ａのおしらせ情報表示領域ＮＴＲ２に、ユーザＣ．Ｃに対して送金リマインドを送信したことを示す、「ユーザＣ．Ｃにリマインドを送信しました」の文字で示されるような情報を表示するようにしてもよいし、そのようにしなくてもよい。
＜処理＞
本実施例において各装置が実行する処理は、図１６－４の処理に倣って同様に実現することができるため、図示および詳細な説明を省略する。
＜第１９実施例の効果＞
本実施例は、提案者のユーザの端末２０が、相手のユーザからの送金結果情報（限定ではなく、第１ユーザから端末のユーザへの送金に関する第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。
また、提案者のユーザの端末２０は、受信した送金結果情報に基づく第１表示（限定ではなく、第１表示の一例）を表示部２４に表示し、送金結果情報の受信に基づいて、相手のユーザへの送信済み送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく表示（限定ではなく、第２表示の一例）を表示部２４に表示する。
そして、提案者のユーザの端末２０が、提案者のユーザによる、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、受金（限定ではなく、送金の受け取りの一例）に関する、または送金リマインドや新規の送金リクエスト（限定ではなく、送金の依頼の一例）に関する第１処理を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とが表示された端末に対する入力に基づいて、送金の受け取りに関する、または送金の依頼に関する第１処理を簡易かつ適切に行うことができる。
また、本実施例は、第１情報は、相手のユーザからの送金結果情報（限定ではなく、第１ユーザからの端末のユーザへの送金に関する情報の一例）であり、第２情報は、提案者のユーザから相手のユーザへの送信済みの送金リクエストに関する送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザに送信された送金依頼に関する情報の一例）である構成を示している。
このような構成により得られる実施例の効果として、第１ユーザからの端末のユーザへの送金と、端末のユーザから第２ユーザに送信された送金依頼とに基づく処理を一括して行うことができる。
また、この場合、第１処理は、第２表示が表示された端末２０に対する入力に基づいて、相手のユーザ（限定ではなく、第２ユーザの一例）に送金リマインドや新規の送金リクエストを送信する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２表示が表示された端末に対する入力に基づいて、第２ユーザに簡単に送金依頼することができる。
＜第２０実施例＞
第２０実施例は、前述した（ｃ）のパターンの処理に関する実施例である。
第２０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
（ｃ）受金＋受信済み送金リクエスト＋送信済み送金リクエスト、のパターンでは、（ｃ１）［受金＋送金］（金額差し引き可）＋［送金＋受金］（金額差し引き可）、の処理を行うことができる。
この処理では、相手のユーザから受金する際に、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザへの送金を併せて行う。この場合、送金リクエスト金額の差額分の金額を受金する／送金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
また、相手のユーザからの受信済み送金リクエストに基づいて相手のユーザに送金するとともに、相手のユーザへの送信済み送金リクエストに基づいて相手のユーザから送金してもらって受金する。この場合、送金リクエスト金額の差額分の金額を送金する／受金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
＜表示画面＞
ここでは、一例として、前述した送金の受け取りの保留（受金の保留）を適用する場合の表示画面例について説明する。
図１８－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金の受け取り（受金）に関する内容として、送金結果情報ＮＣ４が表示されている。
送金結果情報ＮＣ４には、限定ではなく例として、ユーザＡ．ＡがユーザＣ．Ｃから送金された送金金額「５００円」の受け取りに対応する内容が表示されている。
送金結果情報ＮＣ４には、送金を承諾して受け取るための、「送金受け取り」と示された送金受け取りボタンが表示されている。すなわち、ユーザＡ．Ａによって送金受け取りボタンがタップされるまでは、送金処理は完了しておらず、送金受け取りボタンがタップされると、送金されたユーザ（この例ではユーザＡ．Ａ）の電子マネー口座残高に送金金額（この例では「５００円」）が加算される。
また、送金結果情報ＮＣ４には、送金結果情報ＮＣ１と同様に、送金を受け取った時点で送金されたユーザ（この例ではユーザＡ．Ａ）が未処理である送金リクエストが一覧表示されている。
送金結果情報ＮＣ４の最下部には、送金を承諾したと仮定し全選択一括精算を実行させるための、「すべて精算して送金受け取り」と示された受金全選択一括精算ボタンが表示されている。また、受金全選択一括精算ボタンの横には、送金を承諾したと仮定し、送金結果情報ＮＣ４に表示される未処理リクエストのうち、ユーザによって選択された未処理リクエストの一部選択一括精算を実行させるための、「１件の精算」と示された受金一括精算ボタンＢＴ１８とが表示されている。
送金結果情報ＮＣ４の送金受け取りボタンがユーザＡ．Ａによってタップされる場合、限定ではなく例として、送金結果情報ＮＣ４の表示態様は、送金を行ったユーザをユーザＣ．Ｃとした場合の送金結果情報ＮＣ１と同様に変化する。
限定ではなく例として、送金結果情報ＮＣ４において、１つ目の受信済み送金リクエスト（ユーザＣ．Ｃへの支払い ２，０００円）のリクエストと、３つ目の送信済み送金リクエスト（ユーザＣ．Ｃからの受取 １，０００円）とのリクエストのチェックが「ＯＮ」とされて選択され、受金一括精算ボタンＢＴ１８がタップされると、端末２０Ａからサーバ１０に対して、送金（ユーザＣ．ＣからユーザＡ．Ａへの送金）と、選択された未処理リクエストの一括精算との実行が依頼される。この送金は、ユーザＡ．Ａにとっては、送金の受け取り（受金）である。
すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｃの表示部２４に表示される。
図１８－２は、受金一括精算ボタンＢＴ１８がタップされたことに基づいて表示されるおしらせ画面の一例を示す図である。
おしらせ情報表示領域ＮＴＲ１には、一括精算承認確認情報ＮＣ５として、「精算提案」の相手であるユーザＡ．Ａのアイコン画像と、一括精算金額とが表示されている。
一括精算承認確認情報ＮＣ５には、一括精算の内容として、ユーザＣ．Ｃは、ユーザＡ．Ａへの過去の送金リクエストの送信に基づいて送金リクエスト金額「２，０００円」を受け取り、ユーザＡ．Ａからの過去の送金リクエストの受信に基づいて送金リクエスト金額「１，０００円」を支払い、ユーザＡ．Ａへの今回の送金によって「５００円」を支払うこととが表示されている。
また、一括精算承認確認情報ＮＣ５には、一括精算金額として、ユーザＣ．ＣはユーザＡ．Ａから、送金リクエストの送信による受け取り金額「２，０００円」から、送金リクエストの受信による送金リクエスト金額「１０００円」と今回の送金金額「５００円」とを減算した「５００円」を受け取ることが表示されている。
一括精算承認確認情報ＮＣ５の下部には、上記の内容で精算を承認するための「精算する」と示された精算ボタンＢＴ１９と、上記の内容で精算を承認せずに断るための「断る」と示された拒否ボタンとが表示されている。
図１８－３は、上記の精算ボタンＢＴ１９がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金結果情報ＮＣ４の下に、一括精算の内容として、精算結果情報ＮＣ６が表示されている。
精算結果情報ＮＣ６には、限定ではなく例として、ユーザＡ．ＡとユーザＣ．Ｃとの間で一括精算が行われたことで、その一括精算の内容として、精算結果の金額（この例では、ユーザＡ．ＡがユーザＣ．Ｃに送金した送金金額「５００円」の支払い）が表示されている。
すなわち、本実施例では、送金結果情報ＮＣ４において、受金全選択一括精算ボタンや受金一括精算ボタンＢＴ１８がタップされても、その送金の受け取りが即座に実行される訳ではない。送金された金額について一度受け取りを保留し（送金の受け取りの保留、受金保留）、一括精算の内容に含めることで、まとめて精算を実行している。
なお、サーバ１０によって送金結果情報が送信されてから一定時間が経過すると、送金がキャンセルされるようにしてもよい。また、逆に、強制的に送金が完了するようにしてもよい。
なお、図１８－１において、受金一括精算ボタンＢＴ１８がタップされる場合、端末２０Ａの表示部２４に、精算が行われる場合にはユーザＡ．Ａは一括精算金額「５００円」を支払うことになる旨の確認用画面を表示させ、ユーザＡ．Ａの承認に基づいて送金の受け取りと選択された未処理リクエストの一括精算との実行が依頼されるようにしてもよいし、そのようにしなくてもよい。
＜処理＞
図１８－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ａ１３１において未処理リクエストが選択されたと判定したならば（Ａ１３１：ＹＥＳ）、端末２０Ａの制御部２１は、第１送金処理での送金の受け取りに関する送金受取情報と、未処理リクエスト選択情報とをリクエスト選択情報として設定する（Ａ３３２）。
一方、未処理リクエストが選択されなかったと判定したならば（Ａ１３１：ＮＯ）、端末２０Ａの制御部２１は、送金受取情報をリクエスト選択情報として設定する（Ａ３３３）。
なお、Ａ１３１において、明示的に送金の受け取りが選択された場合にのみ、Ａ３３３の処理を実行し、選択されない場合には、端末２０Ａの制御部２１は処理を終了させるようにしてもよいし、しなくてもよい。
Ａ３３２またはＡ３３３の後、端末２０Ａの制御部２１は、Ａ１４０に処理を移す。
Ｓ１４１において未処理リクエストを処理すると判定したならば（Ｓ１４１：ＹＥＳ）、サーバ１０の制御部１１は、送金（ユーザＢ．ＢからユーザＡ．Ａへの送金）と、未処理リクエストの一括精算とを一括精算対象として設定する（Ｓ３４２）。そして、サーバ１０の制御部１１は、Ｓ１５０に処理を移す。
一方、未処理リクエストを処理しないと判定したならば（Ｓ１４１：ＮＯ）、サーバ１０の制御部１１は、Ｓ３１０ｂに処理を移す。つまり、第２送金処理を実行する。
そして、サーバ１０の制御部１１は、Ｓ１７０に処理を移す。
端末２０Ｂの制御部２１は、Ｂ１５０～Ｂ１９０の処理を実行する。
そして、端末２０Ｂの制御部２１は、処理を終了する。
＜第２０実施例の効果＞
本実施例は、提案者のユーザの端末２０が、相手のユーザからの未完了の送金結果情報（限定ではなく、第１ユーザから端末のユーザへの送金に関する第１情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。
また、提案者のユーザの端末２０は、受信した未完了の送金結果情報に基づく第１表示（限定ではなく、第１表示の一例）を表示部２４に表示し、送金結果情報の受信に基づいて、受信済み送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第２情報の一例）、または送信済み送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報の一例）に基づく第２表示（限定ではなく、第２表示の一例）を表示部２４に表示する。
そして、提案者のユーザの端末２０が、提案者のユーザによる、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、送金、または受金（限定ではなく、送金の受け取りの一例）に関する第１処理を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とが表示された端末に対する入力に基づいて、送金に関する、または送金の受け取りに関する第１処理を簡易かつ適切に行うことができる。
また、この場合、第１処理は、第１表示が表示部２４に表示された後、送金受け取りの操作（限定ではなく、第１表示が表示された端末への入力の一例）に基づいて、相手のユーザから送金された金額を受け取る処理（限定ではなく、第１ユーザから端末のユーザへ送金された金額を受け取る処理の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示が表示された端末への入力に基づいて、第１ユーザから送金された金額を受け取ることができる。
また、本実施例は、相手のユーザは一人のユーザであり（限定ではなく、第２ユーザは第１ユーザであることの一例）、第１処理は、受信済み送金リクエスト情報と送信済み送金リクエスト情報とに基づく金額を相手のユーザに送金する、または相手のユーザから送金される処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とに基づく金額を第１ユーザに送金する、または第１ユーザから送金してもらって受金することができる。
また、この場合、第１処理は、受信済み送金リクエスト情報に含まれる送金リクエスト金額から送信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザに送金する、または送信済み送金リクエスト情報に含まれる送金リクエスト金額から受信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザから送金される処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、差額分の金額を第１ユーザに送金する、または第１ユーザから送金してもらって受金することができる。
また、この場合、第１処理は、相手のユーザの端末２０に対する入力に基づく、相手のユーザによる承認に基づいて実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザの端末に対する入力に基づく、第１ユーザによる承認に基づいて、第１処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザの意に沿わずに第１処理が実行されることを防止することができる。
＜第２０変形例＞
上記の実施例に関連するが、図１６－１のテーブルにおける新規処理対象のうちの「受金」を「受金保留」とすることもできる。
この場合、
・受金保留＋受信済み送金リクエスト
・受金保留＋送信済み送金リクエスト
・受金保留＋受信済み送金リクエスト＋送信済み送金リクエスト
のいずれかのパターンの処理を行うようにすることができる。
これらのパターンの処理は、それぞれパターン（ａ）～パターン（ｃ）の処理と同様となる。送金された金額をすぐに受け取るか、時間を置いて後から受け取るかの相違に過ぎないためである。
＜第２１実施例＞
第２１実施例は、前述した（ｄ）のパターンの処理に関する実施例である。
第２１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
（ｄ）送金リクエストを受信＋受信済み送金リクエスト、のパターンでは、（ｄ１）送金［送金＋送金］、の処理を行うことができる。つまり、相手のユーザから送金リクエストを受け取ったことに基づいて相手のユーザへの送金を行うとともに、相手のユーザからの受信済みの送金リクエストに基づいて相手のユーザに対する送金を行う。
＜表示画面＞
図１９－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、リクエスト送金の受信に関する内容として、送金リクエスト情報ＮＣ７が表示されている。
送金リクエスト情報ＮＣ７には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから受信した送金リクエスト金額「５００円」の送金リクエストに対応する内容が表示されている。また、送金リクエスト情報ＮＣ７には、この送金リクエストに承諾して送金を行うための、「送金する」と示された送金リクエスト送金ボタンと、この送金リクエストを拒否するための、「断る」と示された送金リクエスト拒否ボタンとが表示されている。
その下には、送金リクエストを受信した時点で送金リクエストを受け取ったユーザ（この例ではユーザＡ．Ａ）が未処理である送金リクエストが一覧表示されている。未処理リクエストの表示態様については、限定ではなく例として、図１６－２と同様に構成可能なため、詳細な説明を省略する。
なお、未処理リクエストとして、送金リクエストを受信したユーザ（この例ではユーザＡ．Ａ）と、送金リクエストを送信したユーザ（この例ではユーザＢ．Ｂ）との未処理リクエストのみを表示するようにしてもよいし、そのようにしなくてもよい。
送金リクエスト情報ＮＣ７の最下部には、この送金リクエストによる送金と全選択一括精算とを実行させるための、「すべて精算して送金」と示された送金リクエスト送金全選択一括精算ボタンが表示されている。また、送金リクエスト送金全選択一括精算ボタンの横には、この送金リクエストによる送金と、送金リクエスト情報ＮＣ７に表示される未処理リクエストのうち、ユーザによって選択された未処理リクエストの一部選択一括精算を実行させるための、「１件の精算と送金」と示された送金リクエスト送金一部選択一括精算ボタンＢＴ２０とが表示されている。
限定ではなく例として、送金リクエスト情報ＮＣ７において、２つ目の受信済み送金リクエスト（ユーザＢ．Ｂへの支払い ３，５００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送金一部選択一括精算ボタンＢＴ２０がタップされると、端末２０Ａからサーバ１０に対して選択された未処理リクエストの一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＢ．Ｂの端末２０Ｂと、当方であるユーザＡ．Ａの端末２０Ａとに対して、その実行結果に関する精算結果情報が送信される。
図１９－２は、上記の送金リクエスト送金一部選択一括精算ボタンＢＴ２０がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金リクエスト情報ＮＣ７の下に、一括精算の内容として、精算結果情報ＮＣ８と精算結果情報ＮＣ９とが表示されている。
精算結果情報ＮＣ８には、限定ではなく例として、ユーザＡ．Ａは、ユーザＢ．Ｂからの過去の送金リクエストによる送金リクエスト金額「３，５００円」の支払いに関する精算によって、ユーザＢ．Ｂへ送金金額「３，５００円」の送金を実行したことに関する情報が表示されている。
精算結果情報ＮＣ９には、限定ではなく例として、ユーザＡ．Ａは、ユーザＢ．Ｂからの今回の送金リクエストによる送金リクエスト金額「５００円」の支払いに関する精算によって、ユーザＢ．Ｂへ送金金額「５００円」の送金を実行したことに関する情報が表示されている。
なお、ユーザＢ．Ｂの端末２０Ｂに表示される精算結果情報には、ユーザＡ．Ａからの送金受け取りの表示の他、送金結果情報ＮＣ１の表示態様に従って、ユーザＢ．Ｂの未処理リクエストの一覧が付加されて表示される。
図１９－３は、図１９－２の表示画面の別例である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金リクエスト情報ＮＣ７の下に、一括精算の内容として、精算結果情報ＮＣ１０が表示されている。
精算結果情報ＮＣ１０には、限定ではなく例として、ユーザＡ．ＡとユーザＢ．Ｂとの間で一括精算が行われたことで、一括精算金額として、ユーザＡ．ＡはユーザＢ．Ｂへ、過去の送金リクエストの受信による送金リクエスト金額「３，５００円」と、今回の送金リクエストの受信による送金リクエスト金額「５００円」とを加算した、「１，０００円」を支払った（送金した）ことが表示されている。
なお、ユーザＢ．Ｂの端末２０Ｂに表示される精算結果情報においても、一括精算の内容をまとめて一つの精算結果情報として表示させるようにしてもよいし、そのようにしなくてもよい。
＜処理＞
図１９－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
サーバ１０の制御部１１は、端末２０Ｂからの要求に基づいて、ユーザＢ．Ｂからの送金リクエスト情報と、送金リクエスト一覧情報とを、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ４２０）。
そして、サーバ１０の制御部１１は、Ｓ１４０に処理を移す。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金リクエスト情報と送金リクエスト一覧情報とを受信したか否かを判定し（Ａ４０５）、受信したと判定したならば（Ａ４０５：ＹＥＳ）、これらの情報を含む一括精算画面を表示部２４に表示させる（Ａ４２５）。
Ａ１３１において未処理リクエストが選択されたと判定した場合（Ａ１３１：ＹＥＳ）、端末２０Ａの制御部２１は、Ａ１３２に処理を移す。つまり、受信した送金リクエスト情報に基づく送金に関する送金情報と、選択された未処理リクエストを示す未処理リクエスト選択情報とを含むリクエスト選択情報を設定する。
一方、Ａ１３１において未処理リクエストが選択されなかったと判定した場合（Ａ１３１：ＮＯ）、端末２０Ａの制御部２１は、Ａ１３３に処理を移す。つまり、受信した送金リクエスト情報に基づく送金に関する送金情報を含むリクエスト選択情報を設定する。
なお、この処理では、受信した送金リクエスト情報に基づく送金を行うことを前提として説明する。
実際には、受信した送金リクエスト情報に基づく送金を行わずに未処理リクエストのみを処理することが選択される場合もあり得るが、この場合の処理は、前述した未処理リクエストの一括精算の処理と同様となるため、図示・再度の説明を省略する。
Ｓ１４１において未処理リクエストの処理を行うと判定した場合（Ｓ１４１：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１４２に処理を移す。
一方、Ｓ１４１において未処理リクエストの処理を行わないと判定した場合（Ｓ１４１：ＮＯ）、サーバ１０の制御部１１は、Ｓ１４３に処理を移す。
＜第２１実施例の効果＞
本実施例は、第１情報は、相手のユーザから受信する送金リクエストに関する送金リクエスト情報であり、第２情報は、相手のユーザから受信済みの送金リクエストの関する受信済み送金リクエスト情報であり、第１処理は、第１表示と第２表示とを表示する端末２０に対する入力に基づいて、相手のユーザに送金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とを表示する端末に対する入力に基づいて、第１ユーザと第２ユーザとに簡単に送金することができる。
また、この場合、相手のユーザは一人のユーザであり、第１処理は、第１表示と第２表示とを表示する端末２０に対する入力に基づいて、相手のユーザに送金する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とを表示する端末に対する入力に基づいて、一人のユーザ（第１ユーザ）を相手のユーザとして簡単に送金することができる。
＜第２２実施例＞
第２２実施例は、前述した（ｅ）のパターンの処理に関する実施例である。
第２２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
（ｅ）送金リクエストを受信＋送信済み送金リクエスト、のパターンでは、（ｅ１）送金＋送金リマインド、（ｅ２）［送金＋受金］（金額差し引き可）、のいずれかの処理を行うことができる。
（ｅ１）の処理では、相手のユーザから送金リクエストを受け取ったことに基づいて相手のユーザへの送金を行うとともに、相手のユーザへの送信済み送金リクエストに基づいて送金リマインドを併せて行う。
なお、この場合に、送金リマインドではなく、新規の送金リクエストを行うようにしてもよいし、しなくてもよい。
（ｅ２）の処理では、相手のユーザから送金リクエストを受け取ったことに基づいて相手のユーザへの送金を行うとともに、相手のユーザへの送信済み送金リクエストに基づいて相手のユーザから送金してもらって受金する。この場合、送金リクエスト金額の差額分の金額を送金する／受金することができる。また、送金リクエスト金額が同じ金額であれば、金額相殺させることが可能である。
なお、この場合に、相手のユーザの承認を必要として、相手のユーザの承認を得るようにしてもよいし、しなくてもよい。
＜表示画面＞
図２０－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。画面構成の詳細については、限定ではなく例として、送金リクエストの送信者をユーザＣ．Ｃとした場合の図１９－１と同様に構成することが可能なため、詳細については説明を省略する。
なお、送金リクエストの送信者をユーザＣ．Ｃとした場合の送金リクエスト情報を、ここでは送金リクエスト情報ＮＣ１１とする。
限定ではなく例として、送金リクエスト情報ＮＣ１１において、３つ目の送信済み送金リクエスト（ユーザＣ．Ｃからの受取 １，０００円）のリクエストのチェックが「ＯＮ」とされて選択され、送金リクエスト送金一部選択一括精算ボタンＢＴ２１がタップされると、端末２０Ａからサーバ１０に対して選択された未処理リクエストの一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃと、当方であるユーザＡ．Ａの端末２０Ａとに対して、その実行結果に関する精算結果情報が送信される。
図２０－２は、上記の送金リクエスト送金一部選択一括精算ボタンＢＴ２１がタップされたことに基づいて端末２０Ｅの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ１には、一括精算の内容として、精算結果情報ＮＣ１２と精算結果情報ＮＣ１３とが表示されている。
精算結果情報ＮＣ１２には、限定ではなく例として、今回の送金リクエストに基づいて、ユーザＣ．Ｃは、ユーザＡ．Ａへの送金リクエストによる送金リクエスト金額「５００円」を受け取ったことが表示されている。その下には、ユーザＣ．Ｃの未処理リクエストが、限定ではなく例として、２件存在することが表示されている。
精算結果情報ＮＣ１３には、限定ではなく例として、図２０－１で選択された３件目の送金リクエスト（ユーザＡ．ＡがユーザＣ．Ｃに送信した送金リクエスト金額「１，０００円」の送金リクエスト）に対応するリマインドが表示されている。
図２０－３は、図２０－２の表示画面の別例である。
図２０－３では、送金リクエスト情報ＮＣ１１において、３つ目の送信済み送金リクエスト（ユーザＣ．Ｃからの受取 １，０００円）のリクエストが選択され、送金リクエスト送金一部選択一括精算ボタンＢＴ２１がタップされると、端末２０Ａからサーバ１０に対して、選択された未処理リクエストの一括精算の実行が依頼される。すると、サーバ１０から相手方であるユーザＣ．Ｃの端末２０Ｃに対して、一括精算に承認するか否かの意思確認を行うための一括精算承認確認情報が送信されて、端末２０Ｃの表示部２４に表示される。
図２０－３では、おしらせ画面のおしらせ情報表示領域ＮＴＲ１には、精算結果情報ＮＣ１２と精算結果情報ＮＣ１３との代わりに、一括精算承認確認情報ＮＣ１４が表示されている。
一括精算承認確認情報ＮＣ１４には、一括精算の内容として、ユーザＣ．Ｃは、ユーザＡ．Ａからの過去の送金リクエストの受信に基づいて送金リクエスト金額「１，０００円」を支払い、ユーザＡ．Ａへの今回の送金リクエストの送信に基づいて送金リクエスト金額「５００円」を受け取ることとが表示されている。
また、一括精算承認確認情報ＮＣ１４には、一括精算金額として、ユーザＣ．ＣはユーザＡ．Ａから、送金リクエストの受信による送金リクエスト金額「１，０００円」から今回の送金リクエストの送信による送金リクエスト金額「５００円」を減算した「５００円」を支払うことが表示されている。
図２０－４は、図２０－３の精算ボタンＢＴ２２がタップされたことに基づいて端末２０Ａの表示部２４に表示されるおしらせ画面の一例を示す図である。
この例では、おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金リクエスト情報ＮＣ１１の下に、一括精算の内容として、精算結果情報ＮＣ１５が表示されている。
精算結果情報ＮＣ１５には、限定ではなく例として、ユーザＡ．ＡとユーザＣ．Ｃとの間で一括精算が行われたことで、その一括精算の内容として、精算結果の金額（この例では、ユーザＡ．ＡがユーザＣ．Ｃから送金された送金金額「５００円」の受取）が表示されている。
また、一括精算の内容の下には、ユーザＡ．Ａの未処理リクエストが表示されており、その下には、全選択一括精算ボタンと一部選択一括精算ボタンとが表示されている。
限定ではなく例として、精算結果情報ＮＣ１５に表示される未処理リクエストは、送金リクエスト情報ＮＣ１１に表示された未処理リクエストのうち、今回処理を行った３つ目の送信済み送金リクエストを外した（消した）３件の送金リクエストとなる。
＜処理＞
本実施例において各装置が実行する処理は、図１９－４の処理に倣って同様に実現することができるため、図示および詳細な説明を省略する。
＜第２２実施例の効果＞
本実施例は、第１情報は、相手のユーザから提案者のユーザに送信された送金リクエストに関する送金リクエスト情報であり、第２情報は、提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報である構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザから端末のユーザへの送金依頼と、端末のユーザから第２ユーザに送信された送金依頼とに基づく処理を一括して行うことができる。
また、この場合、第１処理は、第１表示と第２表示とが表示された端末２０に対する入力に基づいて、相手のユーザに送金し、相手のユーザに送金リマインドまたは新規の送金リクエストを送信する処理を含むようにすることができる。
また、相手のユーザは一人のユーザであり、第１処理は、相手のユーザから提案者のユーザに送信された送金リクエストに関する送金リクエスト情報と、提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報とに基づく金額を相手のユーザに送金する、または相手のユーザから送金される処理を含むようにすることもできる。
このような構成により得られる実施例の効果の一例として、第１情報と第２情報とに基づく金額を第１ユーザに送金する、または第１ユーザから送金してもらって受金することができる。
また、この場合、第１処理は、相手のユーザから提案者のユーザに送信された送金リクエストに関する送金リクエスト情報に含まれる送金リクエスト金額から、提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザに送金する、または提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報に含まれる送金リクエスト金額から、相手のユーザから提案者のユーザに送信された送金リクエストに関する送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザから受金する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、差額分の金額を第１ユーザに送金する、または第１ユーザから送金してもらって受金することができる。
また、この場合、第１処理は、相手のユーザの端末２０に対する入力に基づく、相手のユーザの承認に基づいて実行されるようにすることもできる。
このような構成により得られる実施例の効果の一例として、第１ユーザの端末に対する入力に基づく、第１ユーザによる承認に基づいて、第１処理が実行されるようにすることができる。これにより、限定ではなく例として、第１ユーザの意に沿わずに第１処理が実行されることを防止することができる。
＜第２３実施例＞
第２３実施例は、前述したパターンとは異なるパターンの処理に関する実施例である。
第２３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
前述したパターンの他にも、限定ではなく例として、図１６－１のテーブルにおける新規処理対象同士の組合せのパターン、つまり、
・受金＋送金リクエストを受信
のパターンの処理を行うようにすることも可能である。
このパターンの処理は、パターン（ａ）の処理と同様となる。つまり、「受金＋送金」の処理を行うことができる。
＜第２３実施例の効果＞
本実施例は、第１情報は、相手のユーザからの送金結果情報（限定ではなく、第１ユーザからの端末のユーザへの送金に関する情報の一例）であり、提案者のユーザの端末２０は、相手のユーザから提案者のユーザへ送信された送金リクエストに関する送金リクエスト情報を通信Ｉ／Ｆ２２によって受信し、受信した送金リクエスト情報に基づく第３表示を表示部２４に表示する。そして、提案者のユーザの端末２０は、提案者のユーザによる、第３表示を表示する端末２０に対する入力に基づいて、送金処理（限定ではなく、第２処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる、第３表示を表示する端末に対する入力に基づいて、送金に関する第２処理を行うことができる。
＜第２４実施例＞
第２４実施例は、前述したパターンとは異なるパターンの処理に関する実施例である。
第２４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
前述したパターンの他にも、限定ではなく例として、図１６－１のテーブルにおける未処理リクエスト同士の組合せのパターン、つまり、
・受信済み送金リクエスト＋送信済み送金リクエスト
のパターンの処理を行うようにすることも可能である。
このパターンの処理は、パターン（ｅ）の処理と同様となる。つまり、「送金＋送金リマインド」、「［送金＋受金］（金額差し引き可）」、のいずれかの処理を行うことができる。
なお、「［送金＋受金］（金額差し引き可）」の処理を行う場合に、相手のユーザの承認を必要とすることとし、相手のユーザの承認を得るようにしてもよいし、しなくてもよい。
＜第２４実施例の効果＞
本実施例は、第２情報は、相手のユーザから受信済みの送金リクエストに関する受信済み送金リクエスト情報であり、相手のユーザから送金リクエストを受信したことに基づいて、提案者のユーザから相手のユーザに送信済みの送金リクエストに関する送信済み送金リクエスト情報に基づく第４表示を表示部２４に表示する。そして、提案者のユーザによる、第２表示と第４表示とが表示された端末２０に対する入力に基づいて、送金、または受金、または送金リクエスト（送金リマインド）に関する第３処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによる、第２表示と第４表示とが表示された端末に対する入力に基づいて、送金に関する、または送金の受け取りに関する、または送金の依頼に関する第３処理を制御部によって行うことができる。
また、この場合、第３処理は、第２表示と第４表示とに対する入力に基づいて、相手のユーザに送金し、相手のユーザに送金リクエストまたは送金リマインドを送信する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２ユーザへの送金と、第２ユーザへの送金依頼とを併せて行うことができる。
また、本実施例は、相手のユーザは一人のユーザであり、第３処理は、受信済み送金リクエスト情報と送信済み送金リクエスト情報とに基づく金額を相手のユーザに送金する、または相手のユーザから送金される処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報と第４情報とに基づく金額を第２ユーザに送金する、または第２ユーザから送金してもらって受け取ることができる。
また、この場合、第３処理は、受信済み送金リクエスト情報に含まれる送金リクエスト金額から、送信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザに送金する、または送信済み送金リクエスト情報に含まれる送金リクエスト金額から、受信済み送金リクエスト情報に含まれる送金リクエスト金額を差し引いた金額を相手のユーザから送金される処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、差額分の金額を第２ユーザに送金する、または第２ユーザから送金してもらって受け取ることができる。
また、この場合、第３処理は、相手のユーザの端末２０に対する入力に基づく、相手のユーザによる承認に基づいて実行されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第２ユーザの端末に対する入力に基づく、第２ユーザによる承認に基づいて、第３処理が実行されるようにすることができる。これにより、限定ではなく例として、第２ユーザの意に沿わずに第３処理が実行されることを防止することができる。
＜第２５実施例＞
第２５実施例は、前述したパターンとは異なるパターンの処理に関する実施例である。
第２５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
限定ではなく例として、図１６－１のテーブルにおける新規処理対象のうちの「受金」を「受金拒否」とすることもできる。
「受金拒否」とは、送金先ユーザが、送金された金額を受け取らないようにすることである。
この場合、
・受金拒否＋受信済み送金リクエスト
・受金拒否＋送信済み送金リクエスト
・受金拒否＋受信済み送金リクエスト＋送信済み送金リクエスト
のいずれかのパターンの処理を行うようにすることができる。
受金拒否＋受信済み送金リクエスト、のパターンでは、送金の処理のみを行うことができる。
受金拒否＋送信済み送金リクエスト、のパターンでは、送金リマインド（または新規の送金リクエスト）の送信の処理のみを行うことができる。
受金拒否＋受信済み送金リクエスト＋送信済み送金リクエスト、のパターンでは、［送金＋受金］（金額差し引き可）の処理を行うことができる。
＜第２６実施例＞
第２６実施例は、送金リクエスト情報の表示手法に関する実施例である。
第２６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
図２１－１は、本実施例において端末２０の表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのおしらせ画面である。
おしらせ画面のおしらせ情報表示領域ＮＴＲ２には、送金の受け取り（受金）に関する内容として、送金結果情報ＮＣ１６が表示されている。
送金結果情報ＮＣ１６には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから送金された（受金した）送金金額「１，０００円」の受け取りに対応する内容が表示されている。
その下には、送金を受け取った時点で送金されたユーザ（この例ではユーザＡ．Ａ）が未処理である送金リクエストが一覧表示されている。送金リクエストの一覧表示の右上方には、未処理の送金リクエストの表示順を変更させるための送金リクエスト履歴ソートボタンＳＴＢ２が表示されている。他の表示態様は送金結果情報ＮＣ１と同様である。
送金リクエスト履歴ソートボタンＳＴＢ２がタッチされると、限定ではなく例として、画面下部からソート順を選択するためのソート選択領域がせり上がり表示される。
ソート選択領域に対するユーザ操作に基づいて、未処理の送金リクエストの表示順を、限定ではなく例として、送金リクエストを送信／受信した日付順や、送金リクエストの送金リクエスト金額等によって、昇／降順に並び変え、表示させることができる。
なお、送金リクエストを送信／受信した日付順に代えて、送金リクエストを送信／受信した日時順で、未処理の送金リクエストの表示順を並び替え、表示させるようにすることもできる。
図２１－２は、限定ではなく例として、ソート選択領域に対するユーザ操作に基づいて、送金結果情報ＮＣ１６の未処理の送金リクエストを、送金リクエスト金額で降順に並び替えた場合における表示画面の一例を示す図である。
図２１－１では、送金結果情報ＮＣ１６の未処理の送金リクエストは、日付に関する昇順で並んでいるが、図２１－２では、送金リクエスト金額に関する降順に並び替えられている。
なお、送金リクエストに対して支払い期限が設定される場合、限定ではなく例として、その支払い期限が迫る順に送金リクエストを表示させるようにしてもよいし、そうしなくてもよい。支払い期限を設定するのは、個人間（ＣｔｏＣ）での支払いの他、限定ではなく例として、金融機関からの融資・ローン（ＣｔｏＢ）の返済期限を設定することも含まれる。
また、送金リクエストしたユーザおよび送金リクエストされたユーザ以外の他のユーザが送金リクエスト金額や事由に関わっている送金リクエストを、優先的に表示させるようにしてもよい。限定ではなく例として、他のユーザが割り勘のメンバーとして含まれているような場合である。
また、送金結果情報や送金リクエスト情報には、未処理の送金リクエストが表示されるとしてきたが、これに限定されない。限定ではなく例として、処理済みの送金リクエストについても、グレーアウト等、異なる表示態様で、未処理の送金リクエストと混在させて表示させるようにしてもよいし、そうしなくてもよい。
＜第２６実施例の効果＞
本実施例は、提案者のユーザの端末２０は、提案者のユーザが相手のユーザから受信済みの受信済み送金リクエストに関する送金リクエスト情報（限定ではなく、第２ユーザから端末のユーザに送信された送金依頼に関する第４情報の一例）、または提案者のユーザが相手のユーザに送信済みの送信済み送金リクエストに関する送金リクエスト情報（限定ではなく、端末のユーザから第２ユーザへ送信された送金依頼に関する第４情報の一例）に基づく第４表示を表示部２４に表示する。そして、提案者のユーザの端末２０は、前述した第２情報と上記の第４情報とに基づく順序で、第２表示と第４表示とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報と第４情報とに基づく適切な順序で、第２表示と第４表示とを表示することができる。
また、本実施例は、上記の第２情報と第４情報とは、送金リクエストを送信／受信した日付に関する情報（限定ではなく、日付に関する情報の一例）、または送金リクエストを送信／受信した日時に関する情報（限定ではなく、日時に関する情報の一例）を含み、第２表示と第４表示を表示する順序は、この日付または日時に関する情報に基づき決定される構成を示している。
このような構成により得られる実施例の効果の一例として、日時または日付に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
また、本実施例は、上記の第２情報と第４情報とは、送金依頼する金額に関する情報（限定ではなく、金額に関する情報の一例）を含み、第２表示と第４表示を表示する順序は、この金額に関する情報に基づき決定される構成を示している。
このような構成により得られる実施例の効果の一例として、金額に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
また、この場合、送金依頼する金額に関する情報には、送金リクエスト金額の他、限定ではなく例として、支払い期限に関する情報を含めることができる。
このような構成により得られる実施例の効果の一例として、支払い期限に関する情報に基づく順序で第２表示と第４表示とを表示させることで、ユーザにとって直感的に分かり易い表示を実現することができる。
＜第２７実施例＞
第２７実施例は、チャットサービス（チャットアプリケーション）を適用する場合の実施例である。
第２７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面＞
以下では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃとが、何れもグループＸに属しており、友だち登録されているものとする。
図２２－１は、本実施例において端末２０Ａ～端末２０Ｃの表示部２４に表示される画面の一例を示す図である。この画面は、限定ではなく例として、各ユーザの端末２０の表示部２４に表示されるメッセージングアプリケーションのグループチャット（この例では、「グループＸ」のチャット）画面である。
画面最上部中央には、メッセージングアプリケーションの名称として「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の文字が表示されている。また、画面最上部右には、端末２０のユーザのメッセージングアプリケーションにおけるアイコン画像およびユーザ名が表示されている。
また、その下には、メッセージングアプリケーションにおける現在位置を示す現在位置表示領域が構成されており、この例では、現在位置がメッセージングアプリケーションの「グループＸ」のグループチャットであることを示す「グループＸ」の文字が、現在位置表示領域内に表示されている。
現在位置表示領域の下には、グループチャットのメッセージ（コンテンツ）の表示領域である、メッセージ表示領域が表示されている。端末２０Ａ～端末２０Ｃの表示部２４におけるメッセージ表示領域を、それぞれメッセージ表示領域ＭＳＧ１～メッセージ表示領域ＭＳＧ３とする。
メッセージ表示領域において、自端末から送信されたメッセージは右側からの吹き出しで、自端末以外から送信されたメッセージは送信者のアイコンと共に左側からの吹き出しで、それぞれ表示される。
限定ではなく例として、ユーザＢ．Ｂが、ユーザＡ．Ａに対して、限定ではなく例として、メッセージングアプリケーション内の送金リクエスト送信機能によって、送金リクエスト金額「１，０００円」の送金リクエストを行う場合を考える。
すると、端末２０Ａのメッセージ表示領域ＭＳＧ１には、送金リクエスト情報ＭＣ１が表示される。
送金リクエスト情報ＭＣ１には、限定ではなく例として、ユーザＡ．ＡがユーザＢ．Ｂから受信した送金リクエスト金額「１，０００円」の送金リクエストに対応する内容が表示されている。また、その下には、送金リクエスト送金ボタンと、送金リクエスト拒否ボタンとが表示されている。
その下には、送金リクエストを受信した時点での、送金リクエストを送ったユーザ（この例ではユーザＢ．Ｂ）と送金リクエストを受け取ったユーザ（この例ではユーザＡ．Ａ）との間で未処理である送金リクエストが一覧表示されている。
また、送金リクエスト情報ＭＣ１の最下部には、この送金リクエストによる送金と全選択一括精算とを実行させるための、「すべての精算と送金」と示された送金リクエスト送金全選択一括精算ボタンが表示されている。
また、端末２０Ｂのメッセージ表示領域ＭＳＧ２には、送金リクエスト情報ＭＣ２が表示される。
送金リクエスト情報ＭＣ２には、限定ではなく例として、ユーザＢ．ＢがユーザＡ．Ａに送信した送金リクエスト金額「１，０００円」の送金リクエストに対応する内容が表示されている。また、その下には、送金リクエスト送金ボタンと、送金リクエスト拒否ボタンとはグレーアウトの表示態様で無効化され、表示されている。
その下には、送金リクエストを受信した時点での、送金リクエストを送ったユーザ（この例ではユーザＢ．Ｂ）と送金リクエストを受け取ったユーザ（この例ではユーザＡ．Ａ）との間で未処理である送金リクエストが一覧表示されている。
また、送金リクエスト情報ＭＣ２の最下部には、全選択一括精算を実行させるための、「すべて精算する」と示された全選択一括精算ボタンが表示されている。
端末２０Ｃのメッセージ表示領域ＭＳＧ３には、送金リクエスト情報ＭＣ３が表示される。
送金リクエスト情報ＭＣ３には、限定ではなく例として、ユーザＢ．ＢがユーザＡ．Ａに送信した送金リクエスト金額「１，０００円」の送金リクエストに対応する内容が表示されている。また、その下には、送金リクエスト送金ボタンと、送金リクエスト拒否ボタンとはグレーアウトの表示態様で無効化され、表示されている。
また、その下には、送金リクエストを送ったユーザ（この例ではユーザＢ．Ｂ）と送金リクエストを受け取ったユーザ（この例ではユーザＡ．Ａ）との間で未処理である送金リクエストの一覧表示は、これらの送金リクエストの当事者ではないため表示されない。
なお、当事者以外の未処理の送金リクエストについて、送金リクエスト情報に表示するようにしてもよいし、そのようにしなくてもよい。
図２２－２は、限定ではなく例として、ユーザ操作によって、送金リクエスト情報ＭＣ１が右から左にスワイプ（スワイプ操作）（画面に指を触れたまま、その指を滑らせる操作）されたことに基づいて端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図２２－２では、限定ではなく例として、図２２－１の端末２０Ａの表示部２４の下部から、精算内容確認領域ＡＣＲ９がせり上がり表示される。
精算内容確認領域ＡＣＲ９の上部には、ユーザＡ．Ａは、ユーザＢ．Ｂから送金リクエストを受信し、また、ユーザＢ．Ｂとの間で２件の未処理の送金リクエスト（未精算リクエスト）が残っていることを示す表示が表示されている。
また、精算内容確認領域ＡＣＲ９の下部には、ユーザＡ．Ａは、ユーザＢ．Ｂとの間で送金リクエスト送金全選択一括精算を行う場合、一括精算の金額として、今回受信した送金リクエスト金額「１，０００円」と、以前受信した送金リクエスト金額「３，５００円」と「５００円」とを加算した「５，０００円」を支払うことになる確認用表示が表示されている。また、その下には、送金リクエスト送金全選択一括精算を実行させるための「ＯＫ」と示された送金リクエスト送金全選択一括精算ボタンＢＴ２３と、送金リクエスト送金全選択一括精算をとりやめるための「キャンセル」と示された取り消しボタンとが表示されている。
なお、送金リクエスト情報ＭＣ１の送金リクエスト送金全選択一括精算ボタンがタップされる場合においても、精算内容確認領域ＡＣＲ９が表示されるようにしてもよいし、そのようにしなくてもよい。
図２２－３は、図２２－２の精算内容確認領域ＡＣＲ９において、送金リクエスト送金全選択一括精算ボタンＢＴ２３がタップされた場合における端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図２２－３では、メッセージ表示領域ＭＳＧ１には、送金リクエスト情報ＭＣ１の下に、送金リクエストによる送金処理と、全選択一括精算による送金処理との送金結果に基づいて、送金結果情報ＭＣ４が表示されている。
送金結果情報ＭＣ４の上部には、精算を行った内容として、ユーザＡ．ＡがユーザＢ．Ｂに送金リクエスト金額「１，０００円」を支払い（送金し）、未処理の送金リクエストの一括精算の金額として「４，０００円」を支払った（送金した）ことが表示されている。
送金結果情報ＭＣ４の下部には、ユーザＡ．Ａは、精算を行った金額として、送金リクエスト金額「１，０００円」と一括精算の金額「４，０００円」とを加算した「５，０００円」を送金したことが表示されている。
なお、送金結果情報ＭＣ４に相当する表示を、端末２０Ａと端末２０Ｂ以外の端末２０には表示させないようにしてもよいし、そのようにしなくてもよい。
また、当事者である端末２０Ａと端末２０Ｂ以外の端末２０には、送金結果情報ＭＣ４の下部にあたる送金結果のみを表示させるようにしてもよいし、そのようにしなくてもよい。
図２２－４は、送金リクエスト情報ＭＣ１において、未処理の送金リクエストを非表示にする場合の画面の一例を示す図である。
限定ではなく例として、送金リクエスト情報ＭＣ１内の×印で示される未処理リクエスト非表示ボタンＢＴ２４がユーザによってタップされると、メッセージ表示領域ＭＳＧ１の下部から、未処理リクエスト表示取消確認領域ＤＲＲ１がせり上がり表示される。
未処理リクエスト表示取消確認領域ＤＲＲ１には、送金や送金リクエストが行われた場合、送金リクエスト情報や送金結果情報に、送金リクエスト（送金）を行ったユーザ（例えばユーザＢ．Ｂ）との間の未処理の送金リクエストの一覧表示を行わないための「ＯＫ」で示される未処理リクエスト表示取消ボタンと、一覧表示を続けるための「キャンセル」で示される未処理リクエスト表示承認ボタンとが表示されている。
限定ではなく例として、未処理リクエスト表示取消確認領域ＤＲＲ１の未処理リクエスト表示取消ボタンがユーザによってタップされる場合、それ以降受信した送金リクエスト情報や送金結果情報には、このユーザ（例えばユーザＢ．Ｂ）との未処理の送金リクエストの一覧は表示されなくなる。
同様に、送金リクエスト情報ＭＣ２の未処理リクエスト非表示ボタンがユーザＢ．Ｂによってタップされ、未処理リクエスト表示取消確認領域の未処理リクエスト表示取消ボタンが続いてタップされる場合、それ以降受信した送金リクエスト情報や送金結果情報にはユーザＡ．Ａとの未処理の送金リクエストの一覧は表示されなくなる。
なお、未処理リクエスト表示取消確認領域の未処理リクエスト表示取消ボタンがタップされる場合、全てのユーザとの間で、それ以降受信した送金リクエスト情報や送金結果情報には未処理の送金リクエストの一覧は表示されなくなるようにしてもよいし、そのようにしなくてもよい。
つまり、本実施例では、未処理リクエストを、入力部に対する端末２０のユーザの入力に基づいて、非表示にすることができるように構成されている。
なお、上記のようにするのではなく、前述したように、未処理リクエストの表示／非表示の設定を、不図示の設定画面等において行うことができるようにしてもよいし、しなくてもよい。
＜第２７実施例の効果＞
本実施例は、提案者のユーザの端末２０は、提案者のユーザ（限定ではなく、端末のユーザの一例と、相手のユーザ（限定ではなく、第１ユーザの一例）とを少なくとも含むトークルーム（限定ではなく、チャットルームの一例）を表示部２４に表示する。そして、第１表示と第２表示とは、このトークルームに表示される構成を示している。
このような構成により得られる実施例の効果の一例として、チャットルームへの表示という分かり易い形で、第１情報と第２情報とを端末のユーザに知らせることができる。
また、この場合、トークルームに表示された第２表示を、提案者のユーザによる端末２０に対する入力に基づいて非表示とすることもできる。
このような構成により得られる実施例の効果の一例として、表示領域のスペースを広く確保することが可能となる。
また、この場合、トークルームは、当事者以外のユーザ（限定ではなく、第３ユーザの一例）を含み、第２表示は、当事者以外のユーザの端末２０に表示されるトークルームには表示されるようにすることもできる。
このような構成により得られる実施例の効果の一例として、第２ユーザから端末のユーザに送信された送金依頼に関する、または端末のユーザから第２ユーザへ送信された送金依頼に関する第２情報に基づく第２表示、つまり、送金の当事者のユーザに関する情報を、当事者以外のユーザである第３ユーザが閲覧できないようにすることができる。
また、この場合、当事者以外のユーザの端末２０に表示されるトークルームは、第２表示とは異なる、この当事者以外のユーザから送信された送金リクエストに関する送金リクエスト情報、またはこの当事者以外のユーザに送信された送金リクエストに関する送金リクエスト情報に基づく第５表示を含む。そして、第５表示は、提案者のユーザの端末２０に表示されるトークルームに表示されないようにすることができる。
このような構成により得られる実施例の効果の一例として、第２表示とは異なる、第３ユーザから送信された送金依頼に関する、または第３ユーザに送信された送金依頼に関する第５情報に基づく第５表示、つまり、第３ユーザが送金の当事者となる情報を、端末のユーザが閲覧できないようにすることができる。
また、この場合、第１表示は、当事者以外のユーザの端末２０に表示されるトークルームに表示されないようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザから端末のユーザへの送金に関する、または第１ユーザから端末のユーザへ送信された送金依頼に関する第１情報に基づく第１表示、つまり、送金の当事者のユーザに関する情報を、第３ユーザが閲覧できないようにすることができる。
また、本実施例は、第１表示と第２表示とは、提案者のユーザの端末２０にインストールされたメッセージングアプリケーションによって表示部２４に表示され、メッセージングアプリケーションは、本開示に係るプログラムに含まれる構成を示している。
このような構成により得られる実施例の効果の一例として、端末にインストールされたアプリケーションによって、第１表示と第２表示とが端末の表示部に表示されるようにすることができる。
＜その他＞
上記の実施例では、送金依頼に関する未処理の情報として、受信済み送金リクエスト情報と、送信済み送金リクエスト情報とを例示した。
しかし、これらの情報を送金リマインド情報に置き換えても、上記の実施例と同様の処理を適用可能である。つまり、送金リクエストと送金リマインドとを区別せず、送金依頼に関する未処理の情報として、受信済み送金リマインド情報と、送信済み送金リマインド情報とをそれぞれ適用することもできる。
送金リクエストと送金リマインドとは、同義として取り扱うこともできるためである。
また、送金リクエスト情報と送金リマインド情報とを任意に組み合わせることもできる。つまり、受信済みの情報と送信済みの情報との組合せとして、以下の４通りの組合せを適用可能である。
（１）第１の組合せ
・受信済み：送金リクエスト情報
・送信済み：送金リクエスト情報
この組合せは、上記の実施例で説明した組合せである。
（２）第２の組合せ
・受信済み：送金リクエスト情報
・送信済み：送金リマインド情報
（３）第３の組合せ
・受信済み：送金リマインド情報
・送信済み：送金リクエスト情報
（４）第４の組合せ
・受信済み：送金リマインド情報
・送信済み：送金リマインド情報
１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク

Claims (22)

  1. 端末によって実行されるプログラムであって、
    第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから第１ユーザへの送金依頼に関する第１情報に基づく第１表示と、前記第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから前記第１ユーザへの送金依頼に関する第２情報に基づく第２表示とを少なくとも前記端末の表示部に表示することと、
    前記第１表示と前記第２表示とが表示された前記端末に対する入力が行われた場合、前記第１情報と、前記第２情報とに基づく、前記端末のユーザの残高から前記第１ユーザに対して第１金額を送金することに関する、または前記第１ユーザに対して第２金額の送金を依頼することに関する第１処理を前記端末の制御部によって行うことと、
    前記第１処理に基づいて、前記端末のユーザの前記残高から前記第１ユーザに対して送金された前記第１金額の情報、または前記端末のユーザから前記第１ユーザに対して依頼された前記第２金額の情報を前記表示部に表示することとが前記端末によって実行される。
  2. 請求項１に記載のプログラムであって、
    前記第１情報は、前記第１ユーザから前記端末のユーザへの送金依頼に関する情報を含み、
    前記第２情報は、前記端末のユーザから前記第１ユーザへの送金依頼に関する情報を含む。
  3. 請求項２に記載のプログラムであって、
    前記第１情報は、送金依頼に関する第３金額の情報を含み、
    前記第２情報は、送金依頼に関する第４金額の情報を含む。
  4. 請求項３に記載のプログラムであって、
    前記第１処理は、前記第３金額と前記第４金額とに基づく処理を含む。
  5. 請求項２から請求項４のいずれか一項に記載のプログラムであって、
    前記第１処理の実行の承認に関する情報を前記端末の通信部によって前記第１ユーザの端末に送信することが前記端末によって実行され、
    前記第１処理は、前記承認に関する情報に基づく、前記第１ユーザによる前記第１処理の実行の承認に基づいて、前記制御部によって処理が実行される。
  6. 請求項３に記載のプログラムであって、
    前記第１情報は、前記端末のユーザから前記第１ユーザへの送金依頼に関する情報を含み、
    前記第２情報は、前記第１ユーザから前記端末のユーザへの送金依頼に関する情報を含み、
    前記第１処理は、前記第４金額が前記第３金額よりも大きい場合、前記第４金額から前記第３金額を差し引いた前記第１金額を前記第１ユーザに送金する処理を含む。
  7. 請求項１に記載のプログラムであって、
    前記第１情報は、送金依頼に関する第３金額の情報を含み、
    前記第２情報は、送金依頼に関する第４金額の情報を含み、
    前記第１処理は、前記第３金額と、前記第４金額と、前記端末のユーザの残高とに基づいて前記制御部によって行われる。
  8. 請求項７に記載のプログラムであって、
    前記第３金額と前記第４金額との合計が、前記残高を超え、前記端末のユーザから送金を行う場合、前記第１処理が実行できないことを示す第３表示を前記表示部に表示することが前記端末によって実行される。
  9. 請求項７に記載のプログラムであって、
    前記第３金額と前記第４金額との合計が、前記残高を超え、前記端末のユーザから送金を行う場合、前記残高にチャージすることを示す第４表示を前記表示部に表示することが前記端末によって実行される。
  10. 請求項７から請求項９のいずれか一項に記載のプログラムであって、
    前記第１表示と、前記第２表示と、前記残高のチャージに関する表示、またはローンを行うことに関する表示とを前記表示部に表示することが前記端末によって実行される。
  11. 請求項７に記載のプログラムであって、
    前記第１処理の実行に関する第５表示を前記表示部に表示することが前記端末によって実行され、
    前記第５表示は、前記第３金額と、前記第４金額と、前記残高とに基づいて、表示態様が変更される。
  12. 請求項１１に記載のプログラムであって、
    前記第５表示は、前記第３金額と前記第４金額との合計が、前記残高を超え、前記端末のユーザから送金を行う場合、前記第１処理が実行できないことを示す表示態様で前記表示部に表示される。
  13. 請求項１１または請求項１２に記載のプログラムであって、
    前記第１処理は、前記端末のユーザによる、前記第５表示に対する入力と、前記第１処理の実行に関する前記第１ユーザの承認に基づいて実行される。
  14. 請求項１１から請求項１３のいずれか一項に記載のプログラムであって、
    前記第１処理は、前記端末のユーザの残高と、前記第１ユーザの残高とに基づいて処理が実行される。
  15. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記第１処理は、前記第１情報と前記第２情報とを少なくとも含む、前記端末のユーザへの送金依頼、または前記端末のユーザによる送金依頼に関する複数の情報のうち、前記端末のユーザによる前記端末に対する入力に基づいて、前記第１情報と前記第２情報とに基づく処理が実行される。
  16. 請求項１５に記載のプログラムであって、
    前記第１処理は、前記端末のユーザの残高に基づいて、前記複数の情報のうち、少なくとも前記第１情報と前記第２情報とが選択され、前記第１情報と前記第２情報とに少なくとも基づく処理を含む。
  17. 請求項１５に記載のプログラムであって、
    前記第１処理は、前記第１情報と前記第２情報との金額が合計された、前記第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから前記第１ユーザへの送金依頼に関する第３情報に基づく第６表示を前記表示部に表示する処理を含む。
  18. 請求項１から請求項１４のいずれか一項に記載のプログラムであって、
    前記端末のユーザへの送金依頼、または前記端末のユーザによる送金依頼に関する複数の情報のうち、前記端末のユーザの残高に基づいて、少なくとも一つの情報を処理する第２処理を行うことが前記端末によって実行される。
  19. 請求項１８に記載のプログラムであって、
    前記第２処理は、前記複数の情報のうち、前記端末のユーザの残高で処理可能な情報を選択する処理を含み、前記選択された情報が処理される。
  20. 請求項１から請求項１９のいずれか一項に記載のプログラムであって、
    前記第１処理は、前記第１情報に基づく送金依頼の処理と、前記第２情報に基づく送金依頼の処理とが実行されたことを示す情報を前記表示部に表示することを含む。
  21. 端末の情報処理方法であって、
    第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから第１ユーザへの送金依頼に関する第１情報に基づく第１表示と、前記第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから前記第１ユーザへの送金依頼に関する第２情報に基づく第２表示とを少なくとも前記端末の表示部に表示することと、
    前記第１表示と前記第２表示とが表示された前記端末に対する入力が行われた場合、前記第１情報と、前記第２情報とに基づく、前記端末のユーザの残高から前記第１ユーザに対して第１金額を送金することに関する、または前記第１ユーザに対して第２金額の送金を依頼することに関する第１処理を前記端末の制御部によって行うことと、
    前記第１処理に基づいて、前記端末のユーザの前記残高から前記第１ユーザに対して送金された前記第１金額の情報、または前記端末のユーザから前記第１ユーザに対して依頼された前記第２金額の情報を前記表示部に表示することとを含む。
  22. 端末であって、
    第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから第１ユーザへの送金依頼に関する第１情報に基づく第１表示と、前記第１ユーザから前記端末のユーザへの送金依頼、または前記端末のユーザから前記第１ユーザへの送金依頼に関する第２情報に基づく第２表示とを少なくとも表示する表示部と、
    前記第１表示と前記第２表示とが表示された前記端末に対する入力が行われた場合、前記第１情報と、前記第２情報とに基づく、前記端末のユーザの残高から前記第１ユーザに対して第１金額を送金することに関する、または前記第１ユーザに対して第２金額の送金を依頼することに関する第１処理を行う制御部とを備え、
    前記制御部は、前記第１処理に基づいて、前記端末のユーザの前記残高から前記第１ユーザに対して送金された前記第１金額の情報、または前記端末のユーザから前記第１ユーザに対して依頼された前記第２金額の情報を前記表示部に表示する制御を行う。
JP2020113408A 2020-06-30 2020-06-30 プログラム、情報処理方法、端末 Active JP7183217B2 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2020113408A JP7183217B2 (ja) 2020-06-30 2020-06-30 プログラム、情報処理方法、端末
CN202180046235.2A CN115803766A (zh) 2020-06-30 2021-06-14 程序、信息处理方法、终端
KR1020227044389A KR20230031215A (ko) 2020-06-30 2021-06-14 프로그램, 정보 처리 방법 및 단말
PCT/JP2021/022487 WO2022004339A1 (ja) 2020-06-30 2021-06-14 プログラム、情報処理方法、端末
JP2022186509A JP2023015366A (ja) 2020-06-30 2022-11-22 プログラム、情報処理方法、端末
US18/090,888 US20230138065A1 (en) 2020-06-30 2022-12-29 Program, information processing method, and terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020113408A JP7183217B2 (ja) 2020-06-30 2020-06-30 プログラム、情報処理方法、端末

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022186509A Division JP2023015366A (ja) 2020-06-30 2022-11-22 プログラム、情報処理方法、端末

Publications (2)

Publication Number Publication Date
JP2022011963A JP2022011963A (ja) 2022-01-17
JP7183217B2 true JP7183217B2 (ja) 2022-12-05

Family

ID=80148443

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2020113408A Active JP7183217B2 (ja) 2020-06-30 2020-06-30 プログラム、情報処理方法、端末
JP2022186509A Pending JP2023015366A (ja) 2020-06-30 2022-11-22 プログラム、情報処理方法、端末

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022186509A Pending JP2023015366A (ja) 2020-06-30 2022-11-22 プログラム、情報処理方法、端末

Country Status (1)

Country Link
JP (2) JP7183217B2 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001155257A (ja) 1999-11-27 2001-06-08 Makoto Sarutani 代金決済システム
JP2002288567A (ja) 2001-01-16 2002-10-04 Otsuka Shokai Co Ltd リース与信調査依頼システム、方法及びプログラム
JP2017174419A (ja) 2016-03-22 2017-09-28 株式会社オービック 会計処理装置、会計処理方法、及び会計処理プログラム
JP2019194908A (ja) 2019-07-08 2019-11-07 楽天銀行株式会社 送金制御システム、送金制御方法、及びプログラム
JP6681968B1 (ja) 2018-12-21 2020-04-15 ＬＩＮＥ Ｐａｙ株式会社 プログラム、認証方法、端末

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001155257A (ja) 1999-11-27 2001-06-08 Makoto Sarutani 代金決済システム
JP2002288567A (ja) 2001-01-16 2002-10-04 Otsuka Shokai Co Ltd リース与信調査依頼システム、方法及びプログラム
JP2017174419A (ja) 2016-03-22 2017-09-28 株式会社オービック 会計処理装置、会計処理方法、及び会計処理プログラム
JP6681968B1 (ja) 2018-12-21 2020-04-15 ＬＩＮＥ Ｐａｙ株式会社 プログラム、認証方法、端末
JP2019194908A (ja) 2019-07-08 2019-11-07 楽天銀行株式会社 送金制御システム、送金制御方法、及びプログラム

Also Published As

Publication number Publication date
JP2023015366A (ja) 2023-01-31
JP2022011963A (ja) 2022-01-17

Similar Documents

Publication Publication Date Title
JP7354089B2 (ja) サーバ、プログラム、情報処理方法
JP7460686B2 (ja) プログラム、情報処理方法、サーバ
JP6977127B1 (ja) プログラム、情報処理方法、端末、サーバ
JP7266019B2 (ja) プログラム、情報処理方法、端末、サーバ
JP2021192260A (ja) プログラム、情報処理方法、端末
JP7175877B2 (ja) プログラム、表示方法、端末
JP7183217B2 (ja) プログラム、情報処理方法、端末
JP7456986B2 (ja) プログラム、情報処理方法、端末
JP7417482B2 (ja) プログラム、情報処理方法、端末
JP7357591B2 (ja) プログラム、情報処理方法、端末
WO2022004339A1 (ja) プログラム、情報処理方法、端末
JP2022001971A (ja) プログラム、情報処理方法、サーバ、端末
JP7250186B2 (ja) サーバ、プログラム、情報処理方法
JP7405930B2 (ja) プログラム、情報処理方法、端末
JP7146866B2 (ja) プログラム、情報処理方法、端末
JP7034226B1 (ja) プログラム、情報処理方法、端末
JP7149442B1 (ja) サーバ、情報処理方法、プログラム、システム
WO2022138448A1 (ja) プログラム、情報処理方法、端末、サーバ
WO2021255949A1 (ja) プログラム、情報処理方法、端末、サーバ
JP2023084657A (ja) サーバ、情報処理方法、プログラム、システム
JP2022001970A (ja) プログラム、情報処理方法、端末

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20210412

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211001

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20211001

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20211001

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211228

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220224

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220524

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220725

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221025

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221122

R150 Certificate of patent or registration of utility model

Ref document number: 7183217

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350