特開 2024-18778 プログラム、情報処理方法、端末、システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024018778

(43)【公開日】2024-02-08

(54)【発明の名称】プログラム、情報処理方法、端末、システム

(51)【国際特許分類】

   G06Q 20/06 20120101AFI20240201BHJP

   G06Q 20/32 20120101ALI20240201BHJP

【ＦＩ】

G06Q20/06

G06Q20/32 300

【審査請求】未請求

【請求項の数】19

【出願形態】ＯＬ

(21)【出願番号】P 2022122313

(22)【出願日】2022-07-29

(71)【出願人】

【識別番号】500257300

【氏名又は名称】ＬＩＮＥヤフー株式会社

(74)【代理人】

【識別番号】110001759

【氏名又は名称】弁理士法人よつ葉国際特許事務所

(74)【代理人】

【識別番号】100093687

【弁理士】

【氏名又は名称】富崎 元成

(74)【代理人】

【識別番号】100168468

【弁理士】

【氏名又は名称】富崎 曜

(74)【代理人】

【識別番号】100166176

【弁理士】

【氏名又は名称】加美山 豊

(72)【発明者】

【氏名】真崎 洋輔

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055AA12

5L055AA64

(57)【要約】

【課題】送金依頼に基づく送金等に関する利便性を向上させる。
【解決手段】端末によって実行されるプログラムは、第１端末から送信された送金依頼に基づく送金依頼情報を端末の通信部によって受信することと、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、送金依頼情報に基づき端末の表示部に表示することとが端末によって実行される。
【選択図】図１－１

【特許請求の範囲】

【請求項1】

端末によって実行されるプログラムであって、
第１端末から送信された送金依頼に基づく送金依頼情報を前記端末の通信部によって受信することと、
前記送金依頼された金額の情報を含む第１表示と、前記送金依頼された金額を増額させることに関する第２表示とを、前記送金依頼情報に基づき前記端末の表示部に表示することとが前記端末によって実行される。

【請求項2】

請求項１に記載のプログラムであって、
前記送金依頼は、前記端末のユーザを含む複数のユーザに送信される。

【請求項3】

請求項１または請求項２に記載のプログラムであって、
前記第２表示に対する前記端末のユーザの入力に基づいて、前記送金依頼された金額を増額させる処理を前記端末の制御部によって行うことが前記端末によって実行される。

【請求項4】

請求項３に記載のプログラムであって、
前記第２表示は、前記送金依頼された金額を増額させるための第１画像と、前記金額を減額させるための第２画像とを含む。

【請求項5】

請求項４に記載のプログラムであって、
前記送金依頼された金額以下の金額が入力された場合、前記第２画像の表示態様を変更する制御を前記制御部によって行うことが前記端末によって実行される。

【請求項6】

請求項３に記載のプログラムであって、
前記第２表示は、第１金額を増額させるための第３画像と、第２金額を増額させるための第４画像とを含む。

【請求項7】

請求項１から請求項６のいずれか一項に記載のプログラムであって、
前記第２表示は、前記端末のユーザによる入力によって、前記送金依頼された金額を減額させるための情報を含み、
前記端末のユーザによる、前記第２表示に対する入力によって、前記送金依頼された金額よりも低い金額が入力された場合、送金できないことを示す表示を前記表示部に表示することが前記端末によって実行される。

【請求項8】

請求項１から請求項７のいずれか一項に記載のプログラムであって、
前記送金依頼に基づく送金処理を前記端末の制御部によって行うことと、
前記送金処理に基づき、前記第１端末に送金することを示す第３表示を前記表示部に表示することとが前記端末によって実行される。

【請求項9】

請求項１から請求項８のいずれか一項に記載のプログラムであって、
前記送金依頼に基づき、送金の上限金額を設定する処理を前記端末の制御部によって行うことが前記端末によって実行される。

【請求項10】

請求項９に記載のプログラムであって、
前記上限金額は、前記第１端末のユーザによって設定される。

【請求項11】

請求項９に記載のプログラムであって、
前記送金依頼は、前記端末のユーザを含む複数のユーザに送信され、
前記上限金額は、前記複数のユーザによって支払われた金額、または支払われる予定の金額によって変更される。

【請求項12】

請求項１から請求項１１のいずれか一項に記載のプログラムであって、
前記送金依頼情報は、前記第１端末のユーザと、複数のユーザとを含むチャットルームに送信され、
前記チャットルームを前記表示部に表示することが前記端末によって実行される。

【請求項13】

請求項１２に記載のプログラムであって、
前記端末のユーザによって、前記第２表示に対する入力が行われ、前記送金依頼された金額よりも高い金額の送金が行われた場合、前記チャットルームの表示制御を前記端末の制御部によって行うことが前記端末によって実行される。

【請求項14】

請求項１２または請求項１３に記載のプログラムであって、
前記端末のユーザによって、前記第２表示に対する入力が行われ、前記送金依頼された前記金額よりも高い金額の送金が行われた場合、前記チャットルームに第４画像を表示する制御を前記端末の制御部によって行うことが前記端末によって実行される。

【請求項15】

請求項１４に記載のプログラムであって、
前記第１端末のユーザによって、前記第４画像に対する入力が行われた場合、前記第４画像に対するリアクションを示す第５画像を前記チャットルームに表示する制御を前記制御部によって行うことが前記端末によって実行される。

【請求項16】

請求項１から請求項１５のいずれか一項に記載のプログラムであって、
前記送金依頼情報は、前記第１端末と通信するサーバを介して前記端末に受信される。

【請求項17】

端末の情報処理方法であって、
第１端末から送信された送金依頼に基づく送金依頼情報を前記端末の通信部によって受信することと、
前記送金依頼された金額の情報を含む第１表示と、前記送金依頼された金額を増額させることに関する第２表示とを、前記送金依頼情報に基づき前記端末の表示部に表示することとを含む。

【請求項18】

端末であって、
第１端末から送信された送金依頼に基づく送金依頼情報を受信する通信部と、
前記送金依頼された金額の情報を含む第１表示と、前記送金依頼された金額を増額させることに関する第２表示とを、前記送金依頼情報に基づき表示する表示部とを備える。

【請求項19】

サーバと端末とを備えるシステムであって、
前記端末は、
サーバから送信されたアプリケーションを受信し、
前記アプリケーションを前記端末の記憶部に記憶し、
前記サーバは、
第１端末から送信された送金依頼に基づく送金依頼情報を前記端末に送信し、
前記端末は、
前記送金依頼された金額の情報を含む第１表示と、前記送金依頼された金額を増額させることに関する第２表示とを、受信された前記送金依頼情報に基づき、前記アプリケーションによって前記端末の表示部に表示することとを含む。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００２－１７６６７１号公報

【発明の概要】

【0004】

本発明の第１の態様によると、端末によって実行されるプログラムは、第１端末から送信された送金依頼に基づく送金依頼情報を端末の通信部によって受信することと、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、送金依頼情報に基づき端末の表示部に表示することとが端末によって実行される。
本発明の第２の態様によると、端末の情報処理方法は、第１端末から送信された送金依頼に基づく送金依頼情報を端末の通信部によって受信することと、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、送金依頼情報に基づき端末の表示部に表示することとを含む。
本発明の第３の態様によると、端末は、第１端末から送信された送金依頼に基づく送金依頼情報を受信する通信部と、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、送金依頼情報に基づき表示する表示部とを備える。
本発明の第４の態様によると、サーバと端末とを備えるシステムは、端末は、サーバから送信されたアプリケーションを受信し、アプリケーションを端末の記憶部に記憶し、サーバは、第１端末から送信された送金依頼に基づく送金依頼情報を端末に送信し、端末は、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、受信された送金依頼情報に基づき、アプリケーションによって端末の表示部に表示することとを含む。

【図面の簡単な説明】

【0005】

【図1-1】実施形態に係る通信システムの構成の一例を示す図。

【図1-2】第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。

【図1-3】第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。

【図1-4】第１実施例に係るアカウント登録データのデータ構成の一例を示す図。

【図1-5】第１実施例に係るアカウント管理データベースのデータ構成の一例を示す図。

【図1-6】第１実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図1-7】第１実施例に係る端末の制御部によって実現される機能の一例を示す図。

【図1-8】第１実施例に係る端末の記憶部に記憶される情報の一例を示す図。

【図1-9】第１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図1-10】第１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図1-11】第１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図1-12】第１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図1-13】第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図1-14】第１変形例に係る端末の表示部に表示される画面の一例を示す図。

【図1-15】第１変形例に係る端末の表示部に表示される画面の一例を示す図。

【図1-16】第１変形例に係る端末の表示部に表示される画面の一例を示す図。

【図1-17】第１変形例に係る端末の表示部に表示される画面の一例を示す図。

【図2-1】第２実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図2-2】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-3】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-4】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-5】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-6】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-7】第２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図2-8】第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図2-9】第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図3-1】第３実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図3-2】第３実施例に係る端末の表示部に表示される画面の一例を示す図。

【図3-3】第３実施例に係る端末の表示部に表示される画面の一例を示す図。

【図3-4】第３実施例に係る端末の表示部に表示される画面の一例を示す図。

【図3-5】第３変形例に係る端末の表示部に表示される画面の一例を示す図。

【図3-6】第３変形例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図3-7】第３変形例に係る端末の表示部に表示される画面の一例を示す図。

【図3-8】第３変形例に係る端末の表示部に表示される画面の一例を示す図。

【図4-1】第４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図4-2】第４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図4-3】第４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図4-4】第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図4-5】第４変形例に係る端末の表示部に表示される画面の一例を示す図。

【図5-1】第５実施例に係る端末の表示部に表示される画面の一例を示す図。

【図5-2】第５実施例に係る端末の表示部に表示される画面の一例を示す図。

【図6-1】第６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図6-2】第６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図6-3】第６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図6-4】第６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図7-1】第７実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図7-2】第７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図7-3】第７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図7-4】第７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図7-5】第７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図7-6】第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図7-7】第７変形例に係る端末の表示部に表示される画面の一例を示す図。

【図7-8】第７変形例に係る端末の表示部に表示される画面の一例を示す図。

【図7-9】第７変形例に係る端末の表示部に表示される画面の一例を示す図。

【図7-10】第７変形例に係る端末の表示部に表示される画面の一例を示す図。

【図8-1】第８実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図8-2】第８実施例に係る端末の表示部に表示される画面の一例を示す図。

【図8-3】第８実施例に係る端末の表示部に表示される画面の一例を示す図。

【図8-4】第８実施例に係る端末の表示部に表示される画面の一例を示す図。

【図8-5】第８変形例に係る端末の表示部に表示される画面の一例を示す図。

【図9-1】第９実施例に係る端末の表示部に表示される画面の一例を示す図。

【図9-2】第９実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図9-3】第９変形例に係る端末の表示部に表示される画面の一例を示す図。

【図9-4】第９変形例に係る端末の表示部に表示される画面の一例を示す図。

【図10-1】第１０実施例に係る端末の表示部に表示される画面の一例を示す図。

【図10-2】第１０実施例に係る端末の表示部に表示される画面の一例を示す図。

【図11-1】第１１実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図11-2】第１１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図11-3】第１１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図11-4】第１１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図11-5】第１１実施例に係る端末の表示部に表示される画面の一例を示す図。

【図11-6】第１１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図11-7】第１１変形例に係る端末の表示部に表示される画面の一例を示す図。

【図12-1】第１２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図12-2】第１２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図12-3】第１２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図12-4】第１２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図12-5】第１２実施例に係る端末の表示部に表示される画面の一例を示す図。

【図12-6】第１２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図12-7】第１２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。

【図12-8】第１２変形例に係る端末の表示部に表示される画面の一例を示す図。

【図13-1】第１３実施例に係る端末の表示部に表示される画面の一例を示す図。

【図13-2】第１３変形例に係る端末の表示部に表示される画面の一例を示す図。

【図13-3】第１３変形例に係る端末の表示部に表示される画面の一例を示す図。

【図14-1】第１４実施例に係るわりかんリクエスト管理データベースのデータ構成の一例を示す図。

【図14-2】第１４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図14-3】第１４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図14-4】第１４実施例に係る端末の表示部に表示される画面の一例を示す図。

【図15-1】第１５実施例に係る端末の表示部に表示される画面の一例を示す図。

【図15-2】第１５実施例に係る端末の表示部に表示される画面の一例を示す図。

【図16-1】第１６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図16-2】第１６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図16-3】第１６実施例に係る端末の表示部に表示される画面の一例を示す図。

【図17-1】第１７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図17-2】第１７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図17-3】第１７実施例に係る端末の表示部に表示される画面の一例を示す図。

【図17-4】第１７変形例に係る端末の表示部に表示される画面の一例を示す図。

【発明を実施するための形態】

【0006】

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

【0007】

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

【0008】

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

【0009】

本願請求項に係る発明の端末（本願発明の端末）の生産は、限定ではなく例として、ユーザが所有（所持）している端末で、本明細書に記載したプログラム（限定ではなく例として、アプリケーションプログラム）等が受信されることによって（または受信されて端末に記憶されることによって）、本端末において、本願請求項に係る発明の機能が実現可能となる状態が作り出される（本願請求項に係る発明が実行可能になる状態が作り出される）という概念を含んでもよい。

【0010】

また、本願請求項に係る発明のシステム（本願発明のシステム）の生産は、限定ではなく例として、本願システムに含まれるサーバから送信された本明細書に記載されたプログラム（限定ではなく例として、アプリケーションプログラム）等を、本願システムに含まれる端末で受信することによって（または受信されたプログラムが端末に記憶されることによって）、本願請求項に係るシステムの発明の機能が実現可能となる状態が作り出される（本願請求項に係る発明が実行可能になる状態が作り出される）という概念を含んでもよい。

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

また、トークルームには、１対１のユーザのトークルーム（以下、「１対１トークルーム」と称する。）、複数のユーザを含むグループのトークルーム（以下、「グループトークルーム」と称する。）、ＯＡ事業者（限定ではなく例として、メッセージングサービスの事業者と提携する事業者）とのトークルーム（以下、「ＯＡトークルーム」と称する。）等を含めることができる。

【0037】

また、メッセージングアプリケーションのアカウントであって、一般のユーザではない事業者のアカウントを「公式アカウント（ＯＡ（Official Account））」と称してもよく、この公式アカウントのユーザを「公式ユーザ」と称してもよい。なお、これを「公式アカウントユーザ」や「公式アカウント事業者」等のように称してもよい。
それに対し、メッセージングアプリケーションのアカウントであって、ＯＡ事業者ではないユーザのアカウントを「一般アカウント」と称し、一般アカウントのユーザを「一般ユーザ」と称する。なお、これを「一般アカウントユーザ」等のように称してもよい。
つまり、メッセージングアプリケーションのアカウントには、一般アカウントと公式アカウントとを含めてよいものとする。

【0038】

一般アカウントは、第１種別のアカウントの一例としてもよく、公式アカウントは、第２種別のアカウントの一例としてもよい。
また、一般アカウントは、メッセージングサービス（メッセージングアプリケーション）で、第１種別として一の端末２０、またはその端末２０のユーザと関連付けられたアカウントの一例としてもよく、公式アカウントは、メッセージングサービス（メッセージングアプリケーション）で、第２種別として一の端末２０、またはその端末２０のユーザと関連付けられたアカウントの一例としてもよい。

【0039】

また、ＯＡ事業者も、限定ではなく例として、一般アカウントのユーザの端末と同様の端末を利用して、サーバを介して、他の装置との間でメッセージの送受信を行うことができるようにしてもよい。

【0040】

また、メッセージ（メッセージ情報）とは、限定ではなく例として、メッセージングサービスで用いられる送信元と送信先とが定められる情報であって、メッセージを識別するための識別情報（メッセージＩＤ）とメッセージコンテンツとで構成される情報としてもよい。
また、メッセージコンテンツとは、限定ではなく例として、メッセージＩＤを除くメッセージの中身を意味するものとしてもよい。メッセージコンテンツは、１または２以上のコンテンツとしてもよい。

【0041】

また、メッセージを識別するための識別情報として設定される情報を「メッセージＩＤ」と称する。
同じメッセージＩＤのメッセージに含まれるメッセージコンテンツは、このメッセージＩＤによって識別されると考えることもできる。よって、メッセージを識別するための識別情報は、メッセージコンテンツを識別するための識別情報と実質的に同義と考えることもできる。
なお、これとは異なり、メッセージコンテンツごとに個別の識別情報（メッセージコンテンツＩＤ）を設定するようにしてもよいし、そのようにしなくてもよい。

【0042】

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

【0043】

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

【0044】

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

【0045】

なお、上記の定義とは異なり、メッセージの上位概念がコンテンツである、またはコンテンツとメッセージとは同義である、と定義してもよいし、そのように定義しなくてもよい。

【0046】

また、以下では、支払いサービス事業者またはメッセージングサービス事業者によって、サーバ１０が運用・管理されることとして説明する。また、以下では、支払いアプリケーションの名称を、適宜「Ｐａｙｍｅｎｔ Ａｐｐ」と称して図示・説明する。

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

また、以下では、端末２０Ａのユーザを「ユーザＡ．Ａ」、端末２０Ｂのユーザを「ユーザＢ．Ｂ」、端末２０Ｃのユーザを「ユーザＣ．Ｃ」、・・・、として説明する。

【0052】

＜実施例＞
以下、本発明を適用した実施例の一例について説明する。
一例であるが、例えば複数の人が集まって食事会や飲み会等をする場合に、その費用をわりかんするような場合がある。
この場合、均等割りでわりかんをすることに限らず、多めに金額を支払う人が出てくるような場合がある。限定ではなく例として、会社の食事会や飲み会等で、上司が多めに金額を支払うことを希望するような場合がある。この場合、全員で均等割りするのではないため、残りの人が、自分がいくら支払えばよいか分からなくなる場合があり得る。

【0053】

以下説明する実施例では、限定ではなく例として、大きく分けて以下の３つの手法によって、上記のようなケースに対応可能とする。
（１）わりかん金額を２段階で算出する手法
（２）返金を用いる手法（または支払い金額の変更を用いた手法）
（３）リアルタイム処理を用いる手法

【0054】

なお、「わりかん（割り勘）」という概念には、限定ではなく例として、複数のユーザで金額を等分することの他（均等割）、複数のユーザで金額を案分（按分）することを含めてもよいものとする（「等分」：同じ割合で分けること。「案分」：異なる割合で分けること。）。

【0055】

＜第１実施例＞
第１実施例は、「（１）わりかん金額を２段階で算出する手法」に関する基本的な実施例である。
第１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0056】

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

【0057】

サーバ１０は、限定ではなく例として、ネットワーク３０を介して、端末２０、または端末２０のユーザに対して所定のサービスを提供する。
サーバ１０のユーザは、限定ではなく例として、ＳＮＳの事業者（限定ではなく例として、メッセージングサービス事業者）や支払いサービスの事業者とすることができる。

【0058】

なお、電子マネー（電子貨幣）等による電子決済を可能とする支払いサービス（支払いアプリケーション）の事業者がサーバ１０のユーザとなって、メッセージングサービス等を運営するようにしてもよい。
また、支払いサービス事業者は、支払いアプリケーションの一機能としてメッセージングサービスを提供するようにしてもよいし、そのようにしなくてもよい。

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（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（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

なお、位置算出用情報検出部２９を設けることは必須ではなく、これを設けないようにしてもよい。

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

その他登録情報には、限定ではなく例として、端末２０を識別するための識別情報、端末２０の電話番号やメールアドレス等の連絡先情報、アプリケーションにおける各種の認証に利用されるパスワード（ログインパスワード、認証パスワード等）等の認証情報、メッセージングアプリケーションでこの一般ユーザによって登録される自己のアイコン画像（以下、「一般ユーザアイコン画像」と称する。）といった各種の情報を含めるようにしてもよい。

【0115】

端末２０を識別するための識別情報は、限定ではなく例として、端末ＩＤ（限定ではなく例として、ＩＭＥＩ（International Mobile Equipment Identity））とすることができる。

【0116】

アプリケーションＩＤは、端末２０のユーザを識別するための識別情報の一例としてもよく、この場合、アプリケーションＩＤに代えて「ユーザＩＤ」としてもよいし、しなくてもよい。
また、連絡先情報も、端末２０のユーザを識別するための識別情報の一例としてもよい。

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

わりかんリクエスト管理データベース１５７は、本実施例におけるわりかんのリクエストに関する管理用のデータが記憶されるデータベースであり、その一例であるわりかんリクエスト管理データベース１５７Ａのデータ構成例を図１－６に示す。
わりかんリクエスト管理データベース１５７Ａには、マスター（ホスト）である端末２０のユーザ（限定ではなく例として、幹事）ごとのデータとして、わりかんリクエスト管理データが記憶される。
マスターである端末２０のユーザのことを、単に「マスター」と称する場合がある。

【0123】

各々のわりかんリクエスト管理データには、限定ではなく例として、このマスターのアプリケーションＩＤと、わりかん総額と、わりかんリクエスト日時と、わりかんメンバー管理データとが記憶される。

【0124】

わりかん総額は、わりかんをする金額の総額であり、限定ではなく例として、マスターの端末２０から送信される情報に基づいてサーバ１０の制御部１１によって記憶される。

【0125】

わりかんリクエスト日時には、マスターがわりかんリクエスト（わりかん要求）をした日時（限定ではなく例として、わりかん要求情報をサーバ１０がマスターの端末２０から受信した日時など）が記憶される。

【0126】

わりかんメンバー管理データは、わりかんをするメンバーを管理するためのデータであり、限定ではなく例として、アプリケーションＩＤと、このアプリケーションＩＤに対応するユーザ名と、このユーザ名のユーザのわりかんメンバーの種別であるメンバー種別と、このユーザ名のユーザが支払った金額である支払い金額とが記憶される。

【0127】

メンバー種別には、限定ではなく例として、「幹事」、「第１種」、「第２種」を含めることができる。
なお、以下説明する実施例では、わりかんメンバーにマスターも含まれることとする。

【0128】

「幹事」は、例えばマスターとすることができる。

【0129】

「第１種」は、限定ではなく例として、わりかんメンバーのうち、お金をわりかんメンバー全員で均等にわりかんする金額よりも「多く払えるグループ」に分類されたユーザに設定されるようにすることができる。メンバー種別に「第１種」が設定されたわりかんメンバーを「第１種メンバー」と称する。

【0130】

「第２種」は、限定ではなく例として、わりかんメンバーのうち、お金をわりかんメンバー全員で均等にわりかんする金額より「多く払わないグループ」（「多く払えないグループ」と言ってもよい。）に分類されたユーザに設定されるようにすることができる。メンバー種別に「第２種」が設定されたわりかんメンバーを「第２種メンバー」と称する。

【0131】

支払い金額は、端末２０によって指定された金額（端末２０から送信される送金依頼情報に含まれる金額）を記憶するバッファである。

【0132】

このわりかんメンバー管理データは、限定ではなく例として、マスターの端末２０から送信された情報によって、サーバ１０によって生成されるようにすることができる。

【0133】

限定ではなく例として、マスターは第２種メンバーに含まれるようにすることができる。
しかし、これに限定されず、マスターが第１種メンバーに含まれるようにしてもよい。

【0134】

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

【0135】

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

【0136】

＜本発明を適用可能な実施例について＞
以下の実施例では、基本的には、飲み会等で、マスター（幹事）が支払いアプリケーション等によってわりかん総額の支払いを先に行い、その後、マスター以外のわりかんメンバーから金銭を徴収するケースを想定した場合の表示画面や処理を例示する。

【0137】

また、上記とは異なり、マスターが、先にわりかんメンバーから支払いアプリケーション等によって金銭を徴収し、その後、わりかん総額の支払いを行うようにしてもよい。
また、以下では、「マスター＝幹事」として説明する場合があるが、これはあくまでも一例に過ぎず、マスターは「幹事」という名目のユーザに限定されるものではない。

【0138】

なお、飲み会等としているが、限定ではなく例として、マスターがなんらかの支払いにおいて立て替え払いを行い、マスター以外のユーザから金銭を徴収するケース等についても、以下説明する手法を同様に適用可能である。つまり、本発明を適用可能な実施例は、わりかんの実施例に限定されるものではない。

【0139】

また、上記とは異なり、物品の販売者またはサービスの提供者（店舗）が、わりかんメンバー（複数の利用客）から支払いアプリケーション等によって金銭を徴収するようにしてもよい。この場合、「マスター＝店舗のユーザ」となり、マスターは支払いを負担しないユーザとしてもよい。

【0140】

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

【0141】

また、以下説明する表示画面で用いる用語と、その後に説明する処理で用いる用語とで、用語が異なる場合がある（一部の用語が統一されていない場合がある）が、これは、ユーザの視点で表示画面について分かり易く説明するなどの目的であり便宜上のものに過ぎない。
これは、他の実施例や変形例についても同様である。

【0142】

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

【0143】

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

【0144】

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

【0145】

なお、１つの図面内、または複数の図面を跨いで、異なる端末２０で表示される所定の画面（限定ではなく例として、お知らせ画面などの画面）を示して、画面の遷移の流れを説明する場合がある。この場合、限定ではなく例として、異なる端末２０では、以下のうちの少なくともいずれかに基づいて（少なくともいずれかを契機として）、所定の画面が表示されることとしてもよいものとする。
・自動的に表示される
・端末２０に対してなんらかの通知（プッシュ通知等を含む。以下同様。）が行われ、ユーザが通知に対する操作を行うと表示される
・端末２０に対して通知は行われないが、ユーザがアプリケーションに対して所定の操作を行うと表示される
・端末２０に対してなんらかの通知が行われ、ユーザが通知を行ったアプリケーションに対して所定の操作を行うと表示される

【0146】

図１－９～図１－１２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。以下では、わりかんに参加するメンバー（ユーザ）のメンバー種別として、「幹事」と、「第１種」と、「第２種」とがある例について説明する。
例えば、「第１種」は、「第２種」よりも（または総額を負担者数で均等割した金額よりも）多くの金額を支払うことが可能なメンバーのメンバー種別であり、「第２種」は、「第１種」よりも（または総額を負担者数で均等割した金額よりも）多くの金額を支払うことを要求されないメンバーのメンバー種別としてもよい。
また、「幹事」は、わりかんに参加するメンバーを設定することが可能なメンバーのメンバー種別としてもよく、「第１種」のメンバーと、「第２種」のメンバーとを設定することが可能なメンバーのメンバー種別としてもよい。

【0147】

ここでは、わりかんに参加する３名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ
・第２種＝ユーザＤ．Ｄ
とする場合の表示画面例を説明する。

【0148】

第１種メンバー種別のユーザを「第１種メンバー」や「第１種ユーザ（第１種のユーザ）」と称し、第２種メンバー種別のユーザを「第２種メンバー」や「第２種ユーザ（第２種のユーザ）」と称する。
また、第１種ユーザの端末２０を「第１種の端末」または「第１種端末」、第２種ユーザの端末２０を「第２種の端末」または「第２種端末」と称することがある。

【0149】

また、以下では、限定ではなく例として、幹事（マスター）のメンバー種別を「第２種」とする場合の例を示す。
ただし、これに限定されず、幹事のメンバー種別を「第１種」としてもよい。

【0150】

また、以下では、限定ではなく例として、幹事であるユーザはわりかん総額を店舗等に支払い済みである（または、わりかん総額をわりかん後に支払う）こととする。そのため、幹事であるユーザは、わりかんに参加する幹事以外のユーザから電子マネーを送金によって受けることとする。
なお、わりかんの幹事であるユーザと、店舗等に支払いを行うユーザとは異なってもよい。この場合、わりかん実行後、幹事であるユーザから店舗等に支払いを行うユーザにわりかん総額を送金するようにしてもよい。

【0151】

図１－９左側は、支払いアプリケーションのホーム画面であり、画面最上部中央には、支払いアプリケーションの名称として「Ｐａｙｍｅｎｔ Ａｐｐ」の文字が表示されている。また、画面最上部には、ユーザＡ．Ａの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。
また、その下には、ホーム画面であることを示す「メインメニュー」の文字が表示されている。

【0152】

ホーム画面には、ユーザＡ．Ａの電子マネー残高「１，５００円」が表示されている。その下には、支払いアプリケーションの各種機能を実行するためのメイン機能ボタンが並んで表示されている。

【0153】

限定ではなく例として、わりかん機能ボタンＭＢＴ１がユーザによってタップされると、限定ではなく例として、図１－９中央の画面に表示が遷移する。
このわりかん設定画面では、限定ではなく例として、わりかんメンバーでわりかんを行う金額（わりかん総額）を入力するためのわりかん総額入力領域ＳＡＲ１と、わりかんメンバーを指定するためのわりかんメンバー指定領域とが表示されるように構成されている。

【0154】

限定ではなく例として、ユーザがわりかん総額入力領域ＳＡＲ１をタップすると、限定ではなく例として、わりかん設定画面にテンキー入力領域が表示され、わりかん総額を指定するように構成することができる。
この画面では、わりかん総額入力領域ＳＡＲ１には、わりかん総額として「１２，０００円」が入力され表示されている。

【0155】

わりかんメンバー指定領域では、限定ではなく例として、「メンバー追加」ボタンをタップすることにより、わりかんメンバーを追加することができるように構成されている。
この画面では、わりかんメンバー指定領域に、３名のわりかんメンバー（ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＤ．Ｄ）が指定され表示されている。また、幹事であるユーザＡ．Ａのアイコンには、限定ではなく例として、幹事であることを示す電卓マークが付加され表示されている。

【0156】

限定ではなく例として、わりかん設定画面最下部の「選択」ボタンがユーザによってタップされると、図１－９右側のわりかんグループ設定画面に表示が遷移する。
このわりかんグループ設定画面では、限定ではなく例として、わりかんメンバー指定領域に入力された内容に基づいて、わりかんメンバーである各ユーザのメンバー種別を振り分けることができるように構成されている。
わりかんグループ設定画面では、わりかんメンバーを第１種として振り分けるための「多く払えるグループ」タブと、第２種として振り分けるための「多く払わないグループ」タブとが表示されるように構成されている。各々のタブの下には、第１種または第２種として振り分けられたユーザが表示されるように構成されている。
限定ではなく例として、各ユーザをドラッグ操作し、タブ間を移動させることで、メンバー種別を変更できるようにすることができる。

【0157】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報とが送信される。

【0158】

図１－１０左側には、この場合における第１種の端末２０Ｂのお知らせ画面の一例を示している。
このお知らせ画面では、仮均等額送金依頼情報ＴＳＲ１が表示されている。
仮均等額送金依頼情報ＴＳＲ１には、幹事であるユーザＡ．Ａに対して、仮均等額として「１２，０００円」÷「３人」＝「４，０００円」を支払うことに関する送金リクエストが含まれる。
限定ではなく例として、仮均等額送金依頼情報ＴＳＲ１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１－１０中央の送金画面に表示が遷移する。

【0159】

送金画面では、限定ではなく例として、送金金額を指定するための送金金額指定領域ＲＡＲ１と、送金先を示す送金先指定領域とが表示されるように構成されている。
この画面では、送金金額指定領域ＲＡＲ１には、仮均等額送金依頼情報ＴＳＲ１における送金リクエストに基づいて、仮均等額「４，０００円」が指定され表示されている。また、送金先指定領域には、仮均等額送金依頼情報ＴＳＲ１における送金リクエストに基づいて、ユーザＡ．Ａが指定され表示されている。
このように、仮均等額（総額÷メンバー数）が、自動的に当初の負担額（送金予定額）として設定され表示されるとともに、送金リクエストを行った幹事のユーザ名が表示されることにより、送金先と送金すべき額を容易に把握できる。

【0160】

限定ではなく例として、送金金額指定領域ＲＡＲ１と、送金先指定領域との間には、送金金額指定領域ＲＡＲ１において指定された送金金額を増額させるための、「多く支払う」の文字で示される送金額増額ボタンＡＩＢ１が表示されるように構成されている。
限定ではなく例として、第１種のユーザは、送金額増額ボタンＡＩＢ１を用いて仮均等額以上の金額を自らの負担額として設定し、設定した額を送金することができる。

【0161】

限定ではなく例として、送金額増額ボタンＡＩＢ１がユーザによってタップされると、限定ではなく例として、図１－１０右側の送金画面に表示が遷移する。
この画面では、送金画面下側からテンキー入力領域がせり上がり表示されている。限定ではなく例として、テンキー入力領域において指定された金額が送金金額指定領域ＲＡＲ１に入力され、送金金額指定領域ＲＡＲ１下部の「確定」ボタンがタップされると、限定ではなく例として、図１－１１左側の送金画面に表示が遷移する。
この画面では、送金金額指定領域ＲＡＲ１には、仮均等額「４，０００円」よりも多い「１０，０００円」が送金金額として指定されたことが表示されている。そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１－１１右側の送金結果画面に表示が遷移する。

【0162】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに仮均等額より増額した金額「１０，０００円」を送金したことが表示されている。
なお、限定ではなく例として、図１－１０中央の画面において、送金金額指定領域ＲＡＲ１に仮均等額「４，０００円」が表示されている状態で、「決定」ボタンを押すと、表示中の仮均等額が送金されるようになっている。すなわち、第１種のユーザであっても、仮均等額から増額させずに送金することも可能である。

【0163】

このような形態に限らず、第１種のユーザは、仮均等額よりも大きな金額を送金しなければならないようにしてもよく、例えば、図１－１０右側の画面において、送金金額指定領域ＲＡＲ１の金額が仮均等額以下の金額である場合には「決定」ボタンが有効にならず（表示されている金額の送金が制限され）、送金金額指定領域ＲＡＲ１の金額が仮均等額より大きな金額である場合に「決定」ボタンが有効となり、「決定ボタン」の操作に基づいて、表示されている金額の送金が可能となるようにしてもよい。

【0164】

第１種のユーザから「１０，０００円」が送金されたことにより、第２種のユーザがわりかんで負担する金額（「均等額」と称する。）は、仮均等額「４，０００円」から、（わりかん総額「１２，０００円」－第１種のユーザの送金総額「１０，０００円」）÷第２種ユーザの人数「２人」＝「１，０００円」へと減額される。これにより、限定ではなく例として、第１種のユーザ全員が送金を実行すると、限定ではなく例として、第２種の端末２０Ｄでは、図１－１２左側に示すようなお知らせ画面が表示される。

【0165】

このお知らせ画面では、仮均等額送金依頼情報ＴＳＲ１が表示されている。
均等額送金依頼情報ＳＲ１には、幹事であるユーザＡ．Ａに対して、均等額として「１，０００円」を支払うことに関する送金リクエストが表示されている。
限定ではなく例として、均等額送金依頼情報ＳＲ１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１－１２中央の送金画面に表示が遷移する。

【0166】

この画面では、送金金額指定領域ＲＡＲ２には、均等額送金依頼情報ＳＲ１における送金リクエストに基づいて、均等額「１，０００円」が指定され表示されている。また、送金先指定領域には、均等額送金依頼情報ＳＲ１における送金リクエストに基づいて、ユーザＡ．Ａが指定され表示されている。
また、この画面では、限定ではなく例として、送金額増額ボタンは表示されないように構成することができる。そのため、第２種のユーザは均等額（送金予定額）を増額させて送金することができない。
このように、第１種のユーザにより支払われる金額が決定された後の、第２種のユーザの負担額が、自動的に設定され表示されるとともに、送金リクエストを行った幹事のユーザ名が表示されることにより、送金先と送金すべき額を容易に把握できる。

【0167】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１－１２右側の送金結果画面に表示が遷移する。

【0168】

この送金結果画面では、ユーザＤ．ＤがユーザＡ．Ａに均等額「１，０００円」を送金したことが表示されている。

【0169】

＜処理＞
図１－１３は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この図では、左側から順に、ユーザＡ．Ａの端末２０Ａの制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理、端末２０Ｂの制御部２１が実行する処理、端末２０Ｄの制御部２１が実行する処理をそれぞれ示している。

【0170】

ここでは、限定ではなく例として、ユーザＡ．Ａがマスターである場合の処理を例示する。
また、限定ではなく例として、わりかんメンバーのうち、ユーザＢ．Ｂが第１種メンバーに設定され、ユーザＤ．Ｄが第２種メンバーに設定される場合を例示する。
なお、第１種メンバーにはユーザＢ．Ｂ以外のメンバー（ユーザＡ．Ａ、ユーザＤ．Ｄを除く。）が含まれてもよく、第２種メンバーにはユーザＤ．Ｄ以外のメンバー（ユーザＡ．Ａ、ユーザＢ．Ｂを除く。）が含まれてもよいが、ここでは図示を省略する。

【0171】

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

【0172】

最初に、端末２０Ａの制御部２１は、わりかん要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１１０）。わりかん要求情報には、限定ではなく例として、わりかんメンバーの情報（限定ではなく例として、アプリケーションＩＤ）と、わりかん総額の情報（または、わりかんメンバー１人あたりの金額×わりかんメンバーの人数の情報）とを含めることができる。
通信Ｉ／Ｆ１４によって端末２０Ａからわりかん要求情報を受信すると、サーバ１０の制御部１１は、受信したわりかん要求情報に基づいて、わりかんリクエスト管理データベース１５７にレコードを追加し、追加されたわりかんリクエスト管理データに、アプリケーションＩＤ（この例ではユーザＡ．ＡのアプリケーションＩＤ）と、わりかん総額と、わりかんリクエスト日時とを設定する。

【0173】

また、端末２０Ａの制御部２１は、わりかんメンバー情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１３０）。わりかんメンバー情報には、限定ではなく例として、各々のわりかんメンバーのメンバー種別の情報を含めることができる。そして、端末２０Ａの制御部２１は、処理を終了する。
通信Ｉ／Ｆ１４によって端末２０Ａからわりかんメンバー情報を受信すると、サーバ１０の制御部１１は、受信したわりかんメンバー情報に基づいて、追加したわりかんリクエスト管理データにおける、わりかんメンバー管理データを更新する。

【0174】

次いで、サーバ１０の制御部１１は、仮均等額送金依頼情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ１１０）。
ここで、仮均等額送金依頼情報には、限定ではなく例として、わりかんの仮均等額の情報を含めることができる。仮均等額は、限定ではなく例として、以下の式（１）によって算出することができる。
仮均等額＝わりかん総額÷わりかんメンバーの人数 ・・・（１）
サーバ１０の制御部１１は、算出した仮均等額を記憶部１５に記憶させるようにすることができる。

【0175】

限定ではなく例として、通信Ｉ／Ｆ２２によってサーバ１０から仮均等額送金依頼情報を受信すると、端末２０Ｂの制御部２１は、受信した仮均等額送金依頼情報を表示部２４に表示させる（Ｂ１１０）。

【0176】

次いで、端末２０Ｂの制御部２１は、送金金額入力処理を行う（Ｂ１３０）。具体的には、Ｂ１１０で表示した仮均等額送金依頼情報に含まれる仮均等額に基づき、入出力部２３を介したユーザＢ．Ｂによる自身が送金を依頼する金額の入力を受け付ける。
ユーザＢ．Ｂには、メンバー種別「第１種」（多く払えるグループ）が設定されている。このため、ユーザＢ．Ｂは、仮均等額よりも多い金額を送金金額として入力するようにすることができる。

【0177】

なお、送金依頼された金額のことを「送金依頼金額」と称する。「送金リクエスト金額と称してもよい。また、送金依頼のことを「送金リクエスト」と称する場合がある。

【0178】

その後、端末２０Ｂの制御部２１は、Ｂ１３０で受け付けた送金依頼金額の幹事への送金を依頼する送金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１５０）。送金依頼情報には、ユーザＢ．Ｂによって入力された送金依頼金額の情報を含めることができる。そして、端末２０Ｂの制御部２１は、処理を終了する。

【0179】

Ｓ１１０の後、通信Ｉ／Ｆ１４によって端末２０Ｂから送金依頼情報を受信すると、サーバ１０の制御部１１は、受信した送金依頼情報に含まれる送金依頼金額を、ユーザＡ．Ａのわりかんリクエスト管理データにおける、わりかんメンバー管理データのユーザＢ．ＢのアプリケーションＩＤと関連付けて支払い金額に記憶させる。

【0180】

その後、サーバ１０の制御部１１は、第１種メンバー全員から送金依頼情報を受信したか否か（メンバー種別に「第１種」が設定された全てのメンバーから送金依頼情報を受信したか否か）を判定し（Ｓ１３０）、受信していない第１種メンバーがいる場合は（Ｓ１３０：ＮＯ）、他の端末２０からの送金依頼情報の受信を待機する。

【0181】

一方、第１種メンバー全員から送金依頼情報を受信したと判定したならば（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、均等額算出処理を行う（Ｓ１５０）。具体的には、限定ではなく例として、以下の式（２）によって均等額を算出する。
均等額＝（わりかん総額－第１種メンバーの支払い金額の総和）÷第１種メンバーを除くわりかんメンバーの人数 ・・・（２）
サーバ１０の制御部１１は、算出した均等額を記憶部１５に記憶させるようにすることができる。

【0182】

次いで、サーバ１０の制御部１１は、算出した均等額を含む均等額送金依頼情報を、通信Ｉ／Ｆ１４によって第２種メンバーの端末２０Ｄに送信する（Ｓ１７０）。
そして、サーバ１０の制御部１１は、処理を終了する。

【0183】

通信Ｉ／Ｆ２２によってサーバ１０から均等額送金依頼情報を受信すると、端末２０Ｄの制御部２１は、受信した均等額送金依頼情報を表示部２４に表示させる（Ｄ１１０）。
そして、端末２０Ｄの制御部２１は、処理を終了する。

【0184】

なお、サーバ１０の制御部１１は、Ｓ１１０のステップの後、第１種メンバーの端末２０から送金依頼情報を受信した場合に、送金依頼情報に基づいて、ユーザＡ．Ａに対する送金処理を行ってもよい。具体的には、限定ではなく例として、その第１種メンバーのアカウントの電子マネー残高からその第１種メンバーの端末２０から受信した送金依頼情報に含まれる送金依頼金額を減算し、ユーザＡ．Ａのアカウントの電子マネー残高に送金依頼金額を加算してもよい。
また、サーバ１０の制御部１１が、Ｓ１３０で第１種メンバー全員から送金依頼情報を受信したと判定した場合に、ユーザＡ．Ａに対する送金処理をまとめて行ってもよい。具体的には、限定ではなく例として、各々の第１種メンバーの端末２０から受信した各々の送金依頼情報に含まれる送金依頼金額を合算した金額を、ユーザＡ．Ａのアカウントの電子マネー残高に加算し、各々の第１種メンバーの電子マネー残高をそれぞれの送金依頼金額分減算してもよい。

【0185】

また、サーバ１０の制御部１１が、Ｓ１１０において、仮均等額送金依頼情報を、第１種メンバーの端末２０ばかりでなく第２種メンバーの端末２０にも送信するようにしてもよい。

【0186】

また、ここでは、わりかん要求情報（限定ではなく、第１情報の一例）に、金額に関する情報として、わりかん総額の情報（みんなで支払う合計金額相当の情報と考えてもよい。）が含まれることとしたが、これに限定されない。
限定ではなく例として、一人あたりの支払い金額の情報や、わりかんをするユーザ数の情報等の情報を、わりかん要求情報（限定ではなく、第１情報の一例）に含めるようにしてもよい。限定ではなく例として、わりかん総額が「１０，０００円」である場合を考えると、一人あたりの支払い金額を「２，０００円」とすれば、わりかんをするユーザ数が「５人」で「２，０００円×５人＝１０，０００円」となる。
この場合、限定ではなく例として、一人あたりの支払い金額の情報をわりかん要求情報に含めて端末２０Ａがサーバ１０に送信するようにする。そして、わりかんをするユーザ数の情報が、他のわりかんメンバーの端末２０からサーバ１０に送信されるようにしてもよい。
同様に、限定ではなく例として、わりかんをするユーザ数の情報をわりかん要求情報に含めて端末２０Ａがサーバ１０に送信するようにする。そして、一人あたりの支払い金額の情報が、他のわりかんメンバーの端末２０からサーバ１０に送信されるようにしてもよい。

【0187】

＜第１実施例の効果＞
本実施例は、サーバ１０は、マスターの端末２０（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）と、わりかんメンバー情報（限定ではなく、第１情報に基づく支払い金額を優先的に入力するユーザを指定する指定情報の一例）とを通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、これらの情報に基づいて、第１種メンバー（限定ではなく、第１端末に指定されたユーザの一例）に、仮均等額の情報・仮均等額送金依頼情報（限定ではなく、支払いに関する第１金額情報の一例）を、通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、第１種メンバーによって入力された支払い金額に基づく均等額の情報・均等額送金依頼情報（限定ではなく、第２金額情報の一例）を、第２種メンバーに通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末から受信した支払い依頼に関する第１情報と、この第１情報に基づく支払い金額を優先的に入力するユーザを指定する指定情報とに基づいて、限定ではなく例として、複数のユーザの一人あたりの支払い金額の情報などの第１金額情報を、指定されたユーザに通知することができる。また、限定ではなく例として、指定されたユーザによって入力された支払い金額に基づく、指定されたユーザとは異なるユーザの一人あたりの支払い金額の情報などの情報を、異なるユーザに知らせることができる。

【0188】

本実施例は、端末２０とサーバ１０とを備える通信システム１において、端末２０は、サーバ１０から送信されたアプリケーションを受信し、受信したアプリケーションを記憶部２８に記憶する。
サーバ１０は、マスターの端末２０（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）と、わりかんメンバー情報（限定ではなく、第１情報に基づく支払い金額を優先的に入力するユーザを指定する指定情報の一例）とを通信Ｉ／Ｆ１４によって受信し、これらの情報に基づいて、第１種メンバー（限定ではなく、第１端末に指定されたユーザの一例）の端末２０に、仮均等額の情報・仮均等額送金依頼情報（限定ではなく、支払いに関する第１金額情報の一例）を、通信Ｉ／Ｆ１４によって送信する。
第１種メンバーの端末２０は、第１種メンバーによって入力された支払い金額の情報を、アプリケーションによってサーバ１０に送信する。
そして、サーバ１０は、第１種メンバーによって入力された支払い金額に基づく均等額の情報・均等額送金依頼情報（限定ではなく、第２金額情報の一例）を、第２種メンバーに通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、サーバから送信されたアプリケーションを受信し、受信したアプリケーションを記憶部に記憶することによって、本願請求項に係るシステムの発明の機能が実現可能となる状態を作り出すことができる（システムの生産）。その上で、サーバが、第１端末から支払い依頼に関する第１情報と、第１情報に基づく支払い金額を優先的に入力するユーザを指定する指定情報とを受信し、第１情報と指定情報とに基づいて、第１端末に指定されたユーザの端末に、支払いに関する第１金額情報を送信する。そして、その端末が、指定されたユーザによって入力された支払い金額を、アプリケーションによってサーバに送信し、サーバが、指定されたユーザによって入力された支払い金額に基づく第２金額情報を、指定されたユーザとは異なるユーザに送信するというシステムの発明の機能を実現することができる。また、上記と同様の効果を得ることができる。
なお、これは、本実施例に示したシステムの発明の機能に限らず、他の実施例等に示すシステムの発明の機能についても同様とすることができる。

【0189】

本実施例は、端末２０が、マスターの端末２０（限定ではなく、第１端末の一例）から送信された送金リクエストに基づく送金リクエスト情報（限定ではなく、送金依頼情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示（限定ではなく、多く支払うボタン等）とを、送金リクエスト情報に基づき表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0190】

また、この場合、端末２０は、送金依頼金額を増額させることに関する第２表示に対する自己の端末２０のユーザの入力に基づいて、送金依頼金額を増額させる処理を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザの入力に基づいて送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0191】

本実施例は、サーバ１０と端末２０とを備える通信システム１において、端末２０は、サーバ１０から送信されたアプリケーションを受信し、受信したアプリケーションを記憶部２８に記憶する。
サーバ１０は、マスターの端末２０（限定ではなく、第１端末の一例）から送信された送金リクエストに基づく送金リクエスト情報を端末２０に送信する。
そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示とを、受信された送金リクエスト情報に基づき、アプリケーションによって表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、サーバから送信されたアプリケーションを受信し、受信したアプリケーションを記憶部に記憶することによって、本願請求項に係るシステムの発明の機能が実現可能となる状態を作り出すことができる（システムの生産）。その上で、サーバが、第１端末から送信された送金依頼に基づく送金依頼情報を端末に送信し、端末が、送金依頼された金額の情報を含む第１表示と、送金依頼された金額を増額させることに関する第２表示とを、受信された送金依頼情報に基づき、アプリケーションによって表示部に表示するというシステムの発明の機能を実現することができる。また、上記と同様の効果を得ることができる。
なお、これは、本実施例に示したシステムの発明の機能に限らず、他の実施例等に示すシステムの発明の機能についても同様とすることができる。

【0192】

＜第１変形例（１）＞
上記の実施例では、幹事を除く第１種のユーザと第２種のユーザとが１名ずつの例を例示したが、これに限定されない。
次に、多く支払うグループにおける複数のユーザが支払う金額が決定された後に、多く支払わないグループにおけるユーザが支払うわりかん金額が決定される場合を例示する。

【0193】

図１－１４～図１－１７は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0194】

図１－１４左側の表示画面については、前述した図１－９左側と同様であるので説明を省略する。

【0195】

限定ではなく例として、わりかん機能ボタンＭＢＴ１がユーザによってタップされると、限定ではなく例として、図１－１４中央の画面に表示が遷移する。図１－１４中央の表示画面については、前述した図１－９中央と同様である部分についての説明を省略する。

【0196】

この例では、わりかん総額入力領域ＳＡＲ１には、わりかん総額として「２０，０００円」が入力され表示されている。

【0197】

また、わりかんメンバー指定領域に、４名のわりかんメンバー（ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ）が指定され表示されている。

【0198】

限定ではなく例として、わりかん設定画面最下部の「選択」ボタンがユーザによってタップされると、図１－１４右側のわりかんグループ設定画面に表示が遷移する。図１－１４右側の表示画面については、前述した図１－９右側と同様である部分についての説明を省略する。

【0199】

この例では、「多く払えるグループ」タブの下には、第１種ユーザとしてユーザＢ．ＢおよびユーザＣ．Ｃが表示されており、「多く払わないグループ」タブの下には、第２種ユーザとしてユーザＡ．ＡおよびユーザＤ．Ｄが表示されている。

【0200】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報とが送信される。

【0201】

図１－１５左側には、この場合における第１種の端末２０Ｂのお知らせ画面の一例を示している。図１－１５左側の表示画面については、前述した図１－１０左側と同様である部分についての説明を省略する。

【0202】

この例では、第１仮均等額送金依頼情報ＴＳＲ１１が表示されている。
第１仮均等額送金依頼情報ＴＳＲ１１には、幹事であるユーザＡ．Ａに対して、仮均等額として、わりかん総額「２０，０００円」÷「４人」＝「５，０００円」（第１均等額）を支払うことに関する送金リクエスト（わりかんリクエスト）が含まれる。

【0203】

限定ではなく例として、第１仮均等額送金依頼情報ＴＳＲ１１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１－１５中央の送金画面に表示が遷移する。図１－１５中央の表示画面については、前述した図１－１０中央と同様である部分についての説明を省略する。

【0204】

この例では、送金金額指定領域ＲＡＲ１には、第１仮均等額送金依頼情報ＴＳＲ１１における送金リクエストに基づいて、わりかん総額「２０，０００円」と、わりかん参加人数「４人」と、仮均等額「５，０００円」とが指定され表示されている。また、送金先指定領域には、第１仮均等額送金依頼情報ＴＳＲ１１における送金リクエストに基づいて、ユーザＡ．Ａが指定され表示されている。

【0205】

限定ではなく例として、送金額増額ボタンＡＩＢ１がユーザによってタップされると、図１－１０右側と同様の画面が表示され、テンキー入力領域における入力操作によって自らが負担する負担額を増額させることが可能である。負担額を決定することにより、限定ではなく例として、図１－１１左側と同様の送金画面に表示が遷移する。

【0206】

この例では、送金金額指定領域ＲＡＲ１に、仮均等額「５，０００円」よりも多い「８，０００円」が送金金額として指定される。そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１－１５右側の送金結果画面に表示が遷移する。図１－１５右側の表示画面については、前述した図１－１１右側と同様である部分についての説明を省略する。

【0207】

この例では、ユーザＢ．ＢがユーザＡ．Ａに仮均等額より増額した金額「８，０００円」を送金したことが表示されている。

【0208】

第１種のユーザ（ユーザＢ．Ｂ）から「８，０００円」が送金されたことにより、限定ではなく例として、ユーザＢ．Ｂとは異なる第１種のユーザ（ユーザＣ．Ｃ）の端末２０Ｃでは、図１－１６左側に示すようなお知らせ画面が表示される。図１－１６左側の表示画面については、前述した図１－１５左側と同様である部分についての説明を省略する。

【0209】

この例では、第１仮均等額送金依頼情報ＴＳＲ１１の下方に、他ユーザ送金完了情報ＴＳＲ２が表示されている。
他ユーザ送金完了情報ＴＳＲ２には、他ユーザ（ユーザＢ．Ｂ）による他ユーザ送金金額「８，０００円」と、残わりかん総額が、わりかん総額「２０，０００円」－他ユーザ送金金額「８，０００円」＝「１２，０００円」であることに関する情報が表示されている。
このように、第１種の一方のユーザが負担する金額が決定されたことに基づいて、残りのユーザ（第１種，第２種）が負担する予定の金額（総額）が、第１種の他方のユーザに通知される。

【0210】

限定ではなく例として、第１仮均等額送金依頼情報ＴＳＲ１１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１－１６中央の送金画面に表示が遷移する。
図１－１６中央の表示画面については、前述した図１－１５中央と同様である部分についての説明を省略する。

【0211】

限定ではなく例として、送金額増額ボタンＡＩＢ１がユーザによってタップされると、限定ではなく例として、図１－１０右側と同様の画面が表示され、テンキー入力領域における入力操作によって自らが負担する負担額を増額させることが可能である。負担額を決定することにより、図１－１１左側と同様の送金画面に表示が遷移する。

【0212】

この例では、送金金額指定領域ＲＡＲ１に、仮均等額「５，０００円」よりも多い「６，０００円」が送金金額として指定される。そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１－１６右側の送金結果画面に表示が遷移する。図１－１６右側の表示画面については、前述した図１－１５右側と同様である部分についての説明を省略する。

【0213】

この例では、ユーザＣ．ＣがユーザＡ．Ａに仮均等額より増額した金額「６，０００円」を送金したことが表示されている。

【0214】

第１種のユーザからそれぞれ「８，０００円」と「６，０００円」が送金されたことにより、第２種のユーザがわりかんで負担する均等額（第２均等額）は、第１仮均等額「５，０００円」から、（わりかん総額「２０，０００円」－第１種のユーザの送金総額「１４，０００円」）÷第２種ユーザの人数「２人」＝「３，０００円」へと減額される。これにより、限定ではなく例として、第１種のユーザ全員が送金を実行すると、限定ではなく例として、第２種の端末２０Ｄでは、図１－１７左側に示すようなお知らせ画面が表示される。図１－１７左側の表示画面については、前述した図１－１２左側と同様である部分についての説明を省略する。

【0215】

この例では、第２均等額送金依頼情報ＳＲ１２が表示されている。
第２均等額送金依頼情報ＳＲ１２には、第１種のユーザ（Ｂ．Ｂ，Ｃ．Ｃ）各々について決定された負担額が含まれるとともに、第２種のユーザ１人あたりの負担額が含まれる。また、第２均等額送金依頼情報ＳＲ１２には、幹事であるユーザＡ．Ａに対して、均等額として「３，０００円」を支払うことと、その内訳に関する送金リクエストが含まれる。
限定ではなく例として、第２均等額送金依頼情報ＳＲ１２の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１－１７中央の送金画面に表示が遷移する。図１－１７中央の表示画面については、前述した図１－１２中央と同様である部分についての説明を省略する。

【0216】

この例では、送金金額指定領域ＲＡＲ２には、第２均等額送金依頼情報ＳＲ１２における送金リクエストに基づいて、均等額「３，０００円」が指定され表示されている。

【0217】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１－１７右側の送金結果画面に表示が遷移する。すなわち、第１種のユーザの端末に表示される、図１－１０右側に相当する画面が表示されることなく、送金結果画面に移行する。

【0218】

この送金結果画面では、ユーザＤ．ＤがユーザＡ．Ａに均等額「３，０００円」を送金したことが表示されている。

【0219】

本変形例は、サーバ１０は、第１種メンバーが支払った金額に基づく通知を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる変形例の効果の一例として、指定されたユーザが支払いを行った金額等の情報を通知することができる。

【0220】

また、本変形例は、端末２０が、マスターの端末２０（限定ではなく、第１端末の一例）から送信された送金リクエストに基づく送金リクエスト情報（限定ではなく、送金依頼情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示とを、送金リクエスト情報に基づき表示部２４に表示する構成を示している。
この場合、送金リクエストは、自己の端末２０のユーザを含む複数のユーザに送信される構成を示している。
このような構成により得られる変形例の効果の一例として、より多くのユーザが、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0221】

＜第１変形例（２）＞
図１－１３のＢ１５０において、端末２０Ｂの制御部２１が、今すぐに送金依頼金額を送金するわけではないが、追って送金依頼金額を送金する予定であることを示す送金予定金額を含む送金予定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信するようにしてもよい。
他の第１種メンバーの端末２０についても同様としてもよい。

【0222】

＜第２実施例＞
第２実施例は、（１）の手法に関し、支払いを行う順位（順番）をわりかんメンバーに設定してわりかんを実現することに関する実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0223】

＜データ構成＞
図２－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかん管理データベース１５７Ｂのデータ構成の一例を示す図である。
各々のわりかんリクエスト管理データにおいて、わりかん管理データベース１５７Ａとは、わりかんメンバー管理データのデータ構成が一部異なっている。

【0224】

具体的には、割り勘メンバー管理データには、限定ではなく例として、わりかんメンバーのアプリケーションＩＤと、ユーザ名と、メンバー種別と、支払い金額とに加えて、限定ではなく例として、メンバー内順位が記憶される。

【0225】

メンバー内順位には、わりかんメンバーが支払いを行う順位（順番）が記憶される。優先順位と捉えてもよい。
本実施例では、第1種メンバーにメンバー内順位が設定されて記憶されることとし、第２種メンバーにはメンバー内順位が設定されない（データ上は、「Ｎ／Ａ（適用なし）」）場合を例示する。
ただし、これに限定されるわけではなく、第２種メンバーに対してもメンバー内順位が設定されて記憶されるようにしてもよい。

【0226】

メンバー内順位は、限定ではなく例として、マスターの端末２０から送信される情報に基づいてサーバ１０の制御部１１によって設定されるようにすることができる。

【0227】

＜表示画面＞
図２－２左側および中央の表示画面については、前述した図１－１４左側および中央と同様であるので説明を省略する。

【0228】

図２－２右側の表示画面については、前述した図１－１４右側と同様である部分についての説明を省略する。

【0229】

この例では、第１種ユーザの各アイコンには、限定ではなく例として、支払いを行う順番を示す順番マークが付加されて表示されている。第１種ユーザのうちユーザＣ．Ｃのアイコンには、限定ではなく例として、一番目に支払いを行うことを示す順番マークが付加されて表示されている。また、第１種ユーザのうちユーザＢ．Ｂのアイコンには、限定ではなく例として、二番目に支払いを行うことを示す順番マークが付加されて表示されている。

【0230】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報とが送信される。
すると、限定ではなく例として、サーバ１０から、第１種ユーザのうち一番目に支払いを行うこととなっているユーザＣ．Ｃの端末２０Ｃに対して、支払いに関するお知らせ情報が送信される。

【0231】

図２－３左側には、この場合における第１種の端末２０Ｃのお知らせ画面の一例を示している。図２－３左側の表示画面については、前述した図１－１６左側と同様である部分についての説明を省略する。

【0232】

この例では、第１仮均等額送金依頼情報ＴＳＲ１１の下方に、他ユーザ送金完了情報ＴＳＲ２が表示されていない。

【0233】

限定ではなく例として、第１仮均等額送金依頼情報ＴＳＲ１１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図２－３中央の送金画面に表示が遷移する。図２－３中央の表示画面については、前述した図１－１６中央と同様であるので説明を省略する。

【0234】

限定ではなく例として、送金額増額ボタンＡＩＢ１がユーザによってタップされると、限定ではなく例として、図２－３右側の送金画面に表示が遷移する。図２－３右側の表示画面については、前述した図１－１６中央と同様である部分についての説明を省略する。

【0235】

この例では、送金金額指定領域ＲＡＲ１に、仮均等額「５，０００円」よりも多い「１０，０００円」が送金金額として指定されたことが表示されている。このように、送金額増額ボタンＡＩＢ１のタップに基づいて、送金金額指定領域ＲＡＲ１に表示されている金額（負担額）が増額される。限定ではなく例として、送金額増額ボタンＡＩＢ１の１回のタップ毎に、送金金額指定領域ＲＡＲ１に表示されている金額が所定額（例えば１，０００円）増加するようにしてもよい。
そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図２－４左側の送金結果画面に表示が遷移する。図２－４左側の表示画面については、前述した図１－１６右側と同様である部分についての説明を省略する。

【0236】

この例では、ユーザＣ．ＣがユーザＡ．Ａに仮均等額より増額した金額「１０，０００円」を送金予定額として決定したことが表示されている。

【0237】

次いで、限定ではなく例として、サーバ１０から、第１種ユーザのうち二番目に支払いを行うこととなっているユーザＢ．Ｂの端末２０Ｂに対して、支払いに関するお知らせ情報が送信される。
そして、第１種の端末２０Ｂでは、図２－４中央のお知らせ画面～図２－５中央の送金結果画面のような表示がなされる。図２－４中央～図２－５中央の表示画面については、前述した図２－３左側～図２－４左側と同様であるので説明を省略する。ただし、図２－５中央では、送金は行われず、送金予定額の決定が行われている。

【0238】

この例では、ユーザＢ．ＢがユーザＡ．Ａに仮均等額より増額した金額「８，０００円」を送金予定額として決定したことが表示されている。

【0239】

限定ではなく例として、第１種ユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ）によって支払い予定金額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、第１種ユーザによる支払い予定金額や、この支払い予定金額に基づく第２種ユーザのわりかん金額に関するお知らせ情報が送信される。

【0240】

図２－５右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図２－５右側の表示画面については、前述した図２－３左側と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＡ．Ａの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0241】

この例では、お知らせ情報ＮＴ０１～ＮＴ０３が上から順に表示されている。
お知らせ情報ＮＴ０１には、第１種ユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い予定額（「１０，０００円」）を支払う決定をしたことに関する情報が含まれる。
また、お知らせ情報ＮＴ０２には、第１種ユーザであるユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い予定額（「８，０００円」）を支払う決定をしたことに関する情報が含まれる。
また、お知らせ情報ＮＴ０３には、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うことに関する情報が含まれる。また、第２種ユーザであるユーザＡ．Ａの負担額は均等額（「１，０００円」）となる情報が含まれる。

【0242】

なお、第１種ユーザであるユーザＢ．Ｂが支払い予定額を決定するまでは、他の第１種ユーザ（この例ではユーザＣ．Ｃ）は、限定ではなく例として、図２－３に従って決定された支払い予定額を変更可能であるようにしてもよい。すなわち、第１種ユーザ全員が支払い予定額を決定し、第２種ユーザの負担額（均等額）が決定されるまでは、支払い予定額を決定済みの第１種ユーザが支払い予定額を変更できるようにしてもよい。

【0243】

次いで、限定ではなく例として、第１種ユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ）によって支払い予定金額（または支払い金額）が送信され、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、第１種ユーザによる支払い金額や、この支払い金額に基づく第２種ユーザのわりかん金額に関するお知らせ情報が送信されると、サーバ１０から、第２種ユーザのユーザＤ．Ｄの端末２０Ｄに対して、第２種ユーザの均等額に関するお知らせ情報が送信される。

【0244】

図２－６には、この場合における第２種の端末２０Ｄのお知らせ画面の一例を示しており、異なるパターンの表示例を示している。図２－６（ａ）、（ｂ）および（ｃ）の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＤ．Ｄの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0245】

（第１種ユーザ各々の支払い金額を示す表示例）
この例では、お知らせ情報ＮＴ０４が表示されている。
お知らせ情報ＮＴ０４には、第１種ユーザであるユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い予定額（「８，０００円」）を支払うことと、第１種ユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い予定額（「１０，０００円」）を支払うことと、これら第１種ユーザによる支払予定額の決定に基づいて、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うこととに関する送金リクエストが含まれる。お知らせ情報ＮＴ０４には、わりかん総額が「２０，０００円」が含まれていない。
本例は、第１種のユーザの各ユーザ名と、第１種のユーザ各々について設定された負担額とが、第２種のユーザの端末に表示される一例である。

【0246】

（第１種ユーザの支払う金額を示さない表示例）
この例では、お知らせ情報ＮＴ０５が表示されている。
お知らせ情報ＮＴ０５には、わりかん総額が「２０，０００円」であり、わりかん人数が「４人」であることと、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うこととに関する送金リクエストが含まれる。
本例は、第１種のユーザの各ユーザ名、及び、第１種のユーザ各々について設定された負担額の何れも第２種のユーザの端末に表示されない（表示が制限される）一例である。

【0247】

（第１種ユーザによる支払い金額の総額を示す表示例）
この例では、お知らせ情報ＮＴ０６が表示されている。
お知らせ情報ＮＴ０６には、第１種ユーザが、幹事であるユーザＡ．Ａに対して、支払い予定額の総額（「１８，０００円」）を支払うことと、これに基づいて、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うこととに関する送金リクエストが含まれる。お知らせ情報ＮＴ０６には、第１種ユーザの人数が含まれていない。
本例は、第１種のユーザの各ユーザ名、及び、第１種のユーザ各々について設定された負担額は、何れも第２種のユーザの端末に表示されない（表示が制限される）が、第１種のユーザの合計負担額は表示される一例である。

【0248】

限定ではなく例として、図２－６（ａ）、（ｂ）または（ｃ）のいずれかのお知らせ画面におけるお知らせ情報の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図２－７左側の送金画面に表示が遷移する。図２－７左側の表示画面については、前述した図１－１７中央と同様であるので説明を省略する。

【0249】

この例では、送金金額指定領域ＲＡＲ１に、均等額「１，０００円」が送金金額として指定されたことが表示されている。
そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図２－７中央の送金結果画面に表示が遷移する。図２－７中央の表示画面については、前述した図１－１７右側と同様である部分についての説明を省略する。

【0250】

この例では、ユーザＤ．ＤがユーザＡ．Ａに均等額「１，０００円」を送金したことが表示されている。

【0251】

次いで、限定ではなく例として、幹事以外のユーザによって支払い金額が送信されると、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、わりかんリクエストが完了したことに関するお知らせ情報が送信される。

【0252】

図２－７右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図２－７右側の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。

【0253】

この例では、お知らせ情報ＮＴ０７が表示されている。
お知らせ情報ＮＴ０７には、わりかんリクエストが完了したことを示す情報と、わりかん総額が「２０，０００円」であり、わりかん人数が「４人」であることを示す情報と、各ユーザ（第１種別，第２種別）から幹事であるユーザＡ．Ａに対する支払い金額と、幹事であるユーザＡ．Ａの支払い金額が「１，０００円」であること（幹事は第２種のユーザであること）を示す情報がと、が含まれる。

【0254】

＜処理＞
図２－８～図２－９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、図１－１３と同様である。
ここでは、ユーザＢ．ＢとユーザＣ．Ｃとが第１種メンバーに設定され、ユーザＤ．Ｄが第２種メンバーに設定される場合を例示する。また、メンバー内順位として、不図示の端末２０ＣのユーザＣ．Ｃに「１」（順位１番）が設定され、図示する端末２０ＢのユーザＢ．Ｂに「２」（順位２番）が設定される場合を例示する。

【0255】

Ａ１１０の後、端末２０Ａの制御部２１は、順位付きわりかんメンバー情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２１０）。順位付きわりかんメンバー情報には、限定ではなく例として、わりかんメンバーのメンバー種別とメンバー内順位の情報とを含めることができる。

【0256】

通信Ｉ／Ｆ１４によって端末２０Ａから順位付きわりかんメンバー情報を受信すると、サーバ１０の制御部１１は、受信した順位付きわりかんメンバー情報に基づいて、ユーザＡ．Ａのわりかんリクエスト管理データにおける、わりかんメンバー管理データを設定する。

【0257】

次いで、サーバ１０の制御部１１は、逐次仮均等額送金依頼情報を、メンバー内順位が高い順に第１種メンバーの端末２０に送信する。
この例では、まず、サーバ１０の制御部１１は、第１種メンバーの端末２０のうちメンバー内順位が「１」である端末２０Ｃに、通信Ｉ／Ｆ１４によって逐次仮均等額送金依頼情報を送信する。逐次仮均等額送金依頼情報には、前述した式（１）に従って算出される仮均等額の情報を含めることができる。

【0258】

通信Ｉ／Ｆ２２によってサーバ１０から逐次仮均等額送金依頼情報を受信すると、端末２０Ｃの制御部２１によって、Ｂ１１０～Ｂ１３０と同様の処理が行われる。

【0259】

Ｓ２１０の後、通信Ｉ／Ｆ１４によって端末２０Ｃから送金依頼情報を受信すると、サーバ１０の制御部１１は、受信した送金依頼情報に含まれる送金依頼金額を、ユーザＡ．Ａのわりかんリクエスト管理データにおける、わりかんメンバー管理データのユーザＣ．ＣのアプリケーションＩＤと関連付けて支払い金額に記憶させる。

【0260】

次いで、サーバ１０の制御部１１は、第１種送金金額情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２２０）。第１種送金金額情報には、限定ではなく例として、ユーザＣ．Ｃを識別可能である情報（ユーザ名）と、ユーザＣ．Ｃの支払い金額（ユーザＣ．Ｃの送金依頼金額）との情報を含めることができる。
なお、サーバ１０の制御部１１は、第１種送金金額情報にわりかん総額と支払い金額とに基づくわりかん残額（限定ではなく例として、わりかん総額－支払い金額の総和）を含めるようにしてもよい。

【0261】

Ａ２１０の後、通信Ｉ／Ｆ２２によってサーバ１０から第１種送金金額情報を受信すると、端末２０Ａの制御部２１は、受信した第１種送金金額情報を表示部２４に表示させる（Ａ２３０）。
なお、以下に示すが、このＡ２３０の処理は、各々の第１種メンバーについて第１種送金金額情報をサーバ１０から受信するごとに行われる（ループ）。

【0262】

その後、サーバ１０の制御部１１は、Ｓ１３０の判定を行い、この例ではユーザＢ．Ｂの端末２０Ｂに対する処理がまだであるため（Ｓ１３０：ＮＯ）、Ｓ２１０に処理を戻し、逐次仮均等額送金依頼情報を通信Ｉ／Ｆ１４によって次のメンバー内順位であるメンバー内順位「２」の端末２０Ｂに送信する。

【0263】

通信Ｉ／Ｆ２２によってサーバ１０から逐次仮均等額送金依頼情報を受信すると、端末２０Ｂの制御部２１は、Ｂ１１０～Ｂ１３０の処理を行う。

【0264】

Ｓ２１０の後、通信Ｉ／Ｆ１４によって端末２０Ｂから送金依頼情報を受信すると、サーバ１０の制御部１１は、受信した送金依頼情報に含まれる送金依頼金額を、ユーザＡ．Ａのわりかんリクエスト管理データにおける、わりかんメンバー管理データのユーザＢ．ＢのアプリケーションＩＤと関連付けて支払い金額に記憶させる。

【0265】

そして、サーバ１０の制御部１１は、上記と同様にＳ２２０の処理を行う。
これにより、ユーザＢ．Ｂの第１種送金金額情報が端末２０Ａに送信され、端末２０Ａでは、この第１種送金金額情報が表示部２４に表示される（Ａ２３０）。

【0266】

サーバ１０の制御部１１は、メンバー内順位に従って、仮均等額送金依頼情報を第１種メンバーの端末２０に送信するようにすることができる。
この場合、サーバ１０の制御部１１は、限定ではなく例として、ある順位の第１種メンバーの端末２０から送金依頼情報を受信した後に、その次の順位の第２種メンバーの端末２０に仮均等額送金依頼情報を送信するようにすることができる。

【0267】

次いで、サーバ１０の制御部１１は、Ｓ１３０の判定を行い、この例では第１種メンバー全員から送金依頼情報を受信したため（Ｓ１３０：ＹＥＳ）、Ｓ１５０に処理を進める。

【0268】

Ｓ１７０において、サーバ１０の制御部１１は、算出した均等額を含む均等額送金依頼情報を、通信Ｉ／Ｆ１４によって端末２０Ｄに送信する（Ｓ１７０）。このステップでは、均等額送金依頼情報を、限定ではなく例として、全ての第２種メンバーの端末２０に一斉送信するようにすることができる。

【0269】

通信Ｉ／Ｆ２２によってサーバ１０から均等額送金依頼情報を受信すると、端末２０Ｄの制御部２１は、Ｄ１１０の処理を行う。そして、端末２０Ｄの制御部２１は、均等額送金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｄ２１０）。
ここで、各々の第２種メンバーが支払うべき金額は、原則的には、Ｓ１５０のステップで算出された均等額であり、均等額の情報はサーバ１０が記憶している。このため、均等額送金依頼情報には、送金依頼金額の情報を含めなくてもよく、送金を依頼する情報（送金に承諾する情報）のみを含めるようにしてもよい。

【0270】

Ｓ１７０の後、通信Ｉ／Ｆ１４によって端末２０Ｄから均等額送金依頼情報を受信すると、サーバ１０の制御部１１は、算出して記憶済みの均等額を、ユーザＡ．Ａのわりかんリクエスト管理データにおける、わりかんメンバー管理データのユーザＤ．ＤのアプリケーションＩＤと関連付けて支払い金額に記憶させる。

【0271】

次いで、サーバ１０の制御部１１は、第２種送金金額情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２３０）。第２種送金金額情報には、限定ではなく例として、ユーザＤ．Ｄのユーザ名と、ユーザＤ．ＤがユーザＡ．Ａに送金する金額（均等額）の情報とを含めることができる。
なお、サーバ１０の制御部１１は、第２種送金金額情報にわりかん残額を含めるようにしてもよい。

【0272】

Ａ２３０の後、通信Ｉ／Ｆ２２によってサーバ１０から第２種送金金額情報を受信すると、端末２０Ａの制御部２１は、受信した第２種送金金額情報を表示部２４に表示させる（Ａ２５０）。
なお、以下に示すが、このＡ２５０の処理は、各々の第２種メンバーの第２送金金額情報をサーバ１０から受信するごとに行われる（ループ）。

【0273】

Ｓ２３０の後、サーバ１０の制御部１１は、第２種メンバー全員から送金依頼情報を受信したか否かを判定し（Ｓ２５０）、受信していない第２種メンバーがいる場合は（Ｓ２５０：ＮＯ）、その第２種メンバーの端末２０からの均等額送金依頼情報の受信を待機する。そして、受信したと判定したならば、上記と同様にＳ２３０の処理を行う。
これにより、ユーザＤ．Ｄ以外の第２種メンバーの第２種送金金額情報が端末２０Ａに送信され、端末２０Ａでは、この第２種送金金額情報が表示部２４に表示される（Ａ２５０）。

【0274】

Ｓ２５０において第２種メンバー全員から送金依頼情報を受信したと判定したならば（Ｓ２５０：ＹＥＳ）、サーバ１０の制御部１１は、わりかんの清算の結果の情報であるわりかん精算結果情報を、通信Ｉ／Ｆ１４によって各々の端末２０に送信する（Ｓ２７０）。
そして、サーバ１０の制御部１１は、処理の終了判定を行う（Ｓ２９０）。

【0275】

そして、各々の端末２０では、わりかん精算結果情報が表示される（Ａ２７０，Ｂ２１０，Ｄ２３０）。そして、各々の端末２０では、処理の終了判定が行われる（Ａ２９０，Ｂ２９０，Ｄ２９０）。

【0276】

なお、サーバ１０の制御部１１が、Ｓ２１０のステップの後、第１種メンバーの端末２０から送金依頼情報を受信した場合に、ユーザＡ．Ａに対する送金処理を行ってもよい。具体的には、限定ではなく例として、その第１種メンバーの端末２０から受信した送金依頼情報に含まれる送金依頼金額をその第１種メンバーのアカウントの電子マネー残高から減算し、ユーザＡ．Ａのアカウントの電子マネー残高に加算してもよい。
また、サーバ１０の制御部１１が、Ｓ１３０で第１種メンバー全員から送金依頼情報を受信したと判定した場合に、ユーザＡ．Ａに対する送金処理をまとめて行ってもよい。具体的には、限定ではなく例として、各々の第１種メンバーの端末２０から受信した各々の送金依頼情報に含まれる送金依頼金額を合算した金額を、ユーザＡ．Ａのアカウントの電子マネー残高に加算し、各々の第１種メンバーの電子マネー残高をそれぞれの送金依頼金額分減算してもよい。

【0277】

同様に、サーバ１０の制御部１１が、Ｓ１７０のステップの後、第２種メンバーの端末２０から均等額送金依頼情報を受信した場合に、ユーザＡ．Ａに対する送金処理を行ってもよい。具体的には、限定ではなく例として、均等額を、その第２種メンバーのアカウントの電子マネー残高から減算し、ユーザＡ．Ａのアカウントの電子マネー残高に加算してもよい。
また、サーバ１０の制御部１１が、Ｓ２５０で第２種メンバー全員から送金依頼情報を受信したと判定した場合に、ユーザＡ．Ａに対する送金処理をまとめて行ってもよい。具体的には、限定ではなく例として、均等額を第２メンバー全員分合算した金額を、ユーザＡ．Ａのアカウントの電子マネー残高に加算し、各々の第２種メンバーの電子マネー残高をそれぞれ均等額分減算してもよい。

【0278】

また、サーバ１０の制御部１１が、Ｓ２１０で第１種メンバーの端末２０に逐次仮均等額送金依頼情報を送信する場合に、わりかん総額から、その第１種メンバーよりも上位の第１種メンバーの送金依頼金額の総計を減算した金額（わりかん総額－上位の送金依頼金額の総計）を超えない範囲で、その第１種メンバーに送金を依頼する金額を設定した上で、設定した金額を含む逐次送金依頼情報を、その第１種メンバーの端末２０に送信するようにしてもよい。
このようにすることで、返金が生じないようにすることができる。

【0279】

また、サーバ１０の制御部１１が、逐次仮均等額送金依頼情報を第２種メンバーの端末２０にも送信するようにする。そして、サーバ１０の制御部１１が、第１種メンバーによる送金依頼金額の入力の前に、送信した逐次仮均等額送金依頼情報に基づき第２種メンバーによって入力された支払いの情報を、第２種メンバーの端末２０から通信Ｉ／Ｆ１４によって受信するようにしてもよい。つまり、サーバ１０が、第１種メンバーが送金依頼情報を入力する前に、逐次仮均等額送金依頼情報に基づいて第２種メンバーによって入力された自身が支払いを行う金額の情報を受信するようにしてもよい。なお、この例では返金が生じ得るが、この場合、サーバ１０の制御部１１は、返金処理を行って金額を調整するようにしてもよい。

【0280】

＜第２実施例の効果＞
本実施例は、わりかんメンバー情報（順位付きわりかんメンバー情報）（限定ではなく、指定情報の一例）は、第１種メンバーのうち、支払い金額を入力するユーザの順番に関する情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、指定されたユーザのうち、支払い金額を入力するユーザの順番に関する情報を含む指定情報を第１端末から受信した上で、指定されたユーザに、その順番で支払い金額を入力させるようにすることができる。

【0281】

また、この場合、第１種メンバーによって入力された送金依頼金額（限定ではなく、支払い金額の一例）は、均等額送金依頼情報（限定ではなく、第２金額情報の一例）に含まれる均等額が決定されるまで変更可能であるようにしてもよい。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、指定されたユーザが、一旦入力した支払い金額を、第２金額情報に含まれる金額が決定されるまで変更可能とすることができる。

【0282】

また、この場合、わりかん要求情報（限定ではなく、第１情報の一例）は、マスターの端末２０が支払いを行ったわりかん総額の情報（限定ではなく、第１端末が支払いを行った金額の総額情報の一例）を含み、わりかん総額の情報を第１種メンバーに送信し、第２種メンバーに送信しない制御を制御部１１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第１端末が先に総額の支払いを行った上で、その支払いを行った総額（総額情報に含まれる総額）を、指定されたユーザには知らせる一方、指定されたユーザとは異なるユーザには知らせない（秘匿する）ようにすることができる。

【0283】

また、この場合、サーバ１０は、第１種メンバーの各々が支払った金額の情報を、第２種メンバーに送信しない制御を制御部１１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、指定されたユーザの各々が支払った金額を、指定されたユーザとは異なるユーザに知らせない（秘匿する）ようにすることができる。

【0284】

また、この場合、サーバ１０は、第１種メンバーの人数の情報を、第２種メンバーに送信しない制御を制御部１１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、指定されたユーザの人数を、指定されたユーザとは異なるユーザに知らせない（秘匿する）ようにすることができる。

【0285】

また、サーバ１０の制御部１１が、逐次仮均等額送金依頼情報を第２種メンバーの端末２０にも送信するようにする。そして、サーバ１０の制御部１１が、第１種メンバーによる送金依頼金額の入力の前に、送信した逐次仮均等額送金依頼情報に基づき第２種メンバーによって入力された支払いの情報を、第２種メンバーの端末２０から通信Ｉ／Ｆ１４によって受信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、サーバが、指定されたユーザによる支払い金額の入力の前に、第１金額情報に基づく支払いの情報を異なるユーザから受信することができる。その結果、指定されたユーザによる支払い金額の入力が行われる前に、指定されていないユーザ（異なるユーザ）が自身の支払いを行うことができるようにすることができる。

【0286】

また、この場合、端末２０は、送金リクエストに基づき、送金の上限金額を設定する処理を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、送金の上限金額が設定されることによって、適切な金額内で任意の金額を送金することができる。

【0287】

また、この場合、上限金額は、マスター（限定ではなく、第１端末のユーザの一例）によって設定されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末のユーザが送金の上限金額を自由に設定できるようにすることができる。

【0288】

また、この場合、送金リクエストは、端末２０のユーザを含む複数のユーザに送信され、上限金額は、複数のユーザによって支払われた金額、または支払われる予定の金額によって変更されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザを含む複数のユーザに送信された送金リクエストに基づき、それら複数のユーザによって支払われた金額、または支払われる予定の金額によって、送金の上限金額が適切に変更されるようにすることができる。

【0289】

＜第３実施例＞
第３実施例は、（１）の手法に関し、わりかんメンバーのうちの特定のメンバーに対して支払い金額を指定してわりかんを実現することに関する実施例である。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0290】

＜データ構成＞
図３－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかん管理データベース１５７Ｃのデータ構成の一例を示す図である。

【0291】

各々のわりかんリクエスト管理データにおいて、わりかん管理データベース１５７Ａ，１５７Ｂとは、わりかんメンバー管理データのデータ構成が一部異なっている。
具体的には、わりかんメンバー管理データには、限定ではなく例として、わりかんメンバーのアプリケーションＩＤと、ユーザ名と、メンバー種別と、支払い金額とに加えて、限定ではなく例として、支払い指定金額が記憶される。

【0292】

支払い指定金額には、このわりかんメンバーに対して指定される支払い金額（以下、「支払い指定金額」と称する。）が記憶される。支払い金額が指定されたわりかんメンバーに対しては支払い指定金額が記憶され、支払い金額が指定されなかったわりかんメンバーに対しては「指定なし」が記憶される。
支払い金額を指定するわりかんメンバーやその支払い指定金額は、限定ではなく例として、マスターの端末２０から送信される情報に基づいてサーバ１０の制御部１１によって設定されるようにすることができる。

【0293】

＜表示画面＞
図３－２～図３－４は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0294】

図３－２左側の表示画面については、前述した図１－１４右側と同様である部分についての説明を省略する。

【0295】

この例では、各ユーザ（ユーザアイコン及びユーザ名）の右方に、わりかんメンバーの支払い金額を個別に設定するための金額指定ボタン（本例では、「金額指定」の文字を含むボタン）が表示されている。

【0296】

限定ではなく例として、ユーザＤ．Ｄに対応する金額指定ボタンがユーザによってタップされると、限定ではなく例として、図３－２中央の金額指定画面に表示が遷移する。

【0297】

金額指定画面では、限定ではなく例として、対応するユーザが支払うべき金額（メンバー別支払い指定金額）を指定するためのメンバー別金額指定領域ＭＭＲが表示されるように構成されている。
この画面では、メンバー別金額指定領域ＭＭＲに、限定ではなく例として、テンキー入力領域等を用いて指定された金額として「５００円」が表示されている。
限定ではなく例として、メンバー別金額指定領域ＭＭＲ下部の「指定」ボタンがタップされると、限定ではなく例として、図３－２右側のわりかんグループ設定画面に表示が遷移する。図３－２右側の表示画面については、前述した図３－２左側と同様である部分についての説明を省略する。

【0298】

この例では、ユーザＤ．Ｄに対応する金額指定ボタンの左方に、限定ではなく例として、金額指定画面において指定された金額である「５００円」が表示されており、幹事は、ユーザＤ．Ｄに依頼する送金額として５００円が設定されたことを確認できる。

【0299】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報（本例では、メンバー別支払い指定金額を含む情報）とが送信される。

【0300】

限定ではなく例として、第１種の端末２０Ｃにおいて、第１種ユーザのユーザＣ．Ｃによって支払い予定金額が決定されたことに基づき、端末２０Ｃでは、限定ではなく例として図３－３左側の表示画面が表示される。図３－３左側の表示画面については、前述した図２－４左側と同様であるので説明を省略する。

【0301】

限定ではなく例として、第１種の端末２０Ｂにおいて、第１種ユーザのユーザＢ．Ｂによって支払い予定金額が決定されたことに基づき、端末２０Ｂでは、限定ではなく例として図３－３中央の表示画面が表示される。図３－３中央の表示画面については、前述した図２－５中央と同様であるので説明を省略する。

【0302】

図３－３右側には、この場合における第２種の端末２０Ｄのお知らせ画面の一例を示している。図３－３右側の表示画面については、前述した図２－６（ａ）と同様である部分についての説明を省略する。

【0303】

この例では、お知らせ情報ＮＴ０８が表示されている。
お知らせ情報ＮＴ０８には、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、図３－２において指定された、メンバー別支払い指定金額（「５００円」）を支払うことに関する送金リクエストが含まれる。

【0304】

限定ではなく例として、図３－３右側のお知らせ画面におけるお知らせ情報ＮＴ０８の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図３－４左側の送金画面に表示が遷移する。図３－４左側の表示画面については、前述した図２－７左側と同様である部分についての説明を省略する。

【0305】

この例では、送金金額指定領域ＲＡＲ１に、メンバー別支払い指定金額「５００円」が送金金額として指定されたことが表示されている。
そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図３－４中央の送金結果画面に表示が遷移する。図３－４中央の表示画面については、前述した図２－７中央と同様である部分についての説明を省略する。

【0306】

この例では、ユーザＤ．ＤがユーザＡ．Ａにメンバー別支払い指定金額「５００円」を送金したことが表示されている。また、送金額増額ボタンＡＩＢ１は表示されておらず、金額を増額することができないようになっている。なお、限定ではなく例として、第１種のユーザにおいてメンバー別支払い指定金額が指定された場合、第１種のユーザの表示画面において送金額増額ボタンＡＩＢ１を表示させ、金額を変更することができるようにしてもよい。

【0307】

次いで、限定ではなく例として、幹事以外のユーザによって支払い金額が送信されると、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、わりかんリクエストが完了したことに関するお知らせ情報が送信される。

【0308】

図３－４右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図３－４右側の表示画面については、前述した図２－７右側と同様である部分についての説明を省略する。

【0309】

この例では、お知らせ情報ＮＴ０８１が表示されている。
お知らせ情報ＮＴ０８１には、わりかんリクエストが完了したこと（わりかんメンバーのうち、幹事を除いた第１種及び第２種全てのユーザの負担額が決定されたこと）と、わりかん総額が「２０，０００円」であり、わりかん人数が「４人」であることと、各ユーザの、幹事であるユーザＡ．Ａに対する支払い金額と、幹事であるユーザＡ．Ａの支払い金額が「１，５００円」であることとに関する情報とが含まれる。

【0310】

＜処理＞
本実施例では、限定ではなく例として図２－８～図２－９の処理において、Ａ２１０のステップで、端末２０Ａの制御部２１が、支払い指定金額を含む順位付きわりかんメンバー情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。なお、順位付きわりかん情報では、メンバー内順位を指定しないようにしてもよい。そして、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから受信したわりかんメンバー情報に含まれる支払い指定金額に基づいて、図３－１のわりかんリクエスト管理データの支払い指定金額を更新するようにすることができる。

【0311】

また、本実施例では、限定ではなく例として図２－８～図２－９の処理において、図３－１のわりかんリクエスト管理データにおいて支払い指定金額が指定されている場合、逐次仮均等額送金依頼情報または均等額送金依頼情報に含める金額として、支払い指定金額を使用するようにすることができる。
なお、逐次仮均等額送金依頼情報または均等額送金依頼情報で指定される金額が支払い指定金額である場合、金額の変更が不可能であることを示す情報を含めるようにしてもよい。そして、各端末２０の制御部２１は、金額の変更が不可能であることを示す情報が含まれる場合、限定ではなく例として、送金金額入力処理を省略し、支払い指定金額の送金に承諾するすることを含む送金依頼情報（均等額送金依頼情報）をサーバ１０に送信することとしてもよい。

【0312】

＜第３実施例の効果＞
本実施例は、サーバ１０は、マスター（限定ではなく、第１端末のユーザの一例）によって入力された支払い指定金額の情報（限定ではなく、第３金額情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、この支払い指定金額の情報を、第２種メンバーに通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第１端末のユーザによって入力された、複数のユーザの一人あたりの支払い金額の情報などの第３金額情報を受信した上で、その第３金額情報に含まれる金額を、指定されたユーザとは異なるユーザに知らせることができる。

【0313】

また、この場合、サーバ１０は、均等額の情報（限定ではなく、第２金額情報の一例）の代わりに支払い指定金額の情報（限定ではなく、第３金額情報の一例）を、第２種メンバーに通信Ｉ／Ｆ１４によって送信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第２金額情報に含まれる金額の代わりに、第１端末のユーザによって入力された第３金額情報に含まれる金額を、指定されたユーザとは異なるユーザに知らせることができる。

【0314】

＜第３変形例（１）＞
上記の実施例では、わりかん開始時に各わりかんメンバーの支払い指定金額を指定する例を示したが、これに限定されない。限定ではなく例として、送金依頼情報（均等額送金依頼情報）をサーバ１０で受信し、第１種または第２種送金金額情報をマスターの端末２０において受信後、支払い指定金額を指定するようにしてもよい。

【0315】

図３－５は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0316】

限定ではなく例として、第１種ユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ）によって支払い金額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、第１種ユーザによる支払い金額や、この支払い金額に基づく第２種ユーザのわりかん金額に関するお知らせ情報が送信される。

【0317】

図３－５左側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図３－５左側の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。

【0318】

この例では、お知らせ情報ＮＴ０３に、第２種ユーザであるユーザＡ．ＡおよびユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うことに関する情報と、わりかんメンバーの支払い金額を個別に設定するための金額指定ボタン（本例では、「金額指定」の文字を含むボタン）とが含まれる。

【0319】

限定ではなく例として、金額指定ボタンがユーザによってタップされると、限定ではなく例として、図３－５中央の金額指定画面に表示が遷移する。このようにして、第２種ユーザのそれぞれについて、負担額を個別に設定する（均等額から変更する）ことが可能である。図３－５中央の表示画面については、前述した図３－２中央と同様であるので説明を省略する。

【0320】

限定ではなく例として、メンバー別金額指定領域ＭＭＲ下部の「指定」ボタンがタップされ、限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報（本例では、メンバー別支払い指定金額を含む情報）とが送信される。

【0321】

図３－５右側には、この場合における第２種の端末２０Ｄのお知らせ画面の一例を示している。図３－５右側の表示画面については、前述した図３－３右側と同様である部分についての説明を省略する。

【0322】

この例では、お知らせ情報ＮＴ０９およびＮＴ０８が上から順に表示されている。
お知らせ情報ＮＴ０９には、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額（「１，０００円」）を支払うことに関する送金リクエストが含まれる。この送金リクエストは、均等額が決定されたことに基づいて表示されたものであり、均等額から変更された負担額に関するわりかんリクエストを第２種の端末２０Ｄが受信する前から（変更後の負担額が端末２０Ｄに表示される前から）端末２０Ｄに表示されていた情報である。

【0323】

このお知らせ情報ＮＴ０９における「詳細を確認」ボタンは、限定ではなく例として、変更後の負担額に関するわりかんリクエストを受信していない場合には（変更後の負担額が端末２０Ｄに表示されていない場合には）、操作を受け付けていることを示す第１態様（例えば、ハッチング処理されていない態様）で表示されており、第１態様の「詳細を確認」ボタンを操作することにより遷移する送金画面において、支払のための操作を行うことによって均等額の送金が可能である。

【0324】

このお知らせ情報ＮＴ０９における「詳細を確認」ボタンは、限定ではなく例として、変更後の負担額に関するわりかんリクエストを受信したことに基づいて（変更後の負担額が端末２０Ｄに表示された場合に）、第１態様から、操作を受け付けていないことを示す第２態様（本例では、ハッチング処理された態様）に変化する。第２態様の「詳細を確認」ボタンにユーザがタッチしたとしても、これに基づいて支払のための操作を行うことはできず、均等額の送金を行うことはできない。

【0325】

変更後の負担額に関するわりかんリクエストを端末２０Ｄが受信したことに基づいて、限定ではなく例として、お知らせ情報ＮＴ０８が端末２０Ｄに表示され、上述したように、既に表示されていたお知らせ情報ＮＴ０９における「詳細を確認」ボタンが第１態様から第２態様に変化する。

【0326】

お知らせ情報ＮＴ０８には、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、変更後の負担額（「５００円」）を支払うことに関する送金リクエストが含まれる。
このお知らせ情報ＮＴ０８における「詳細を確認」ボタンは、限定ではなく例として、操作を受け付けていることを示す第１態様（本例では、ハッチング処理されていない態様）で表示されている。第１態様の「詳細を確認」ボタンを操作することにより遷移する送金画面において、支払のための操作を行うことによって変更後の負担額の送金が可能である。

【0327】

このように、算出された均等額（「１，０００円」）に基づく送金リクエストが表示されたものの、その後、幹事によって負担額が変更された場合（「１，０００円」から「５００円」に変更された場合）には、均等額に基づく送金リクエストをタップすることによる送金が制限される。このような構成を採用することにより、負担額の変更（個別設定）が行われたにもかかわらず、第２種ユーザによって変更前の負担額が誤って送金されてしまうことを防止できる。

【0328】

＜第３変形例（２）＞
わりかんをするメンバー全員を対象に１つのわりかん総額に対するわりかんを行うのではなく、わりかんをするメンバーを２以上のグループ（限定ではなく例として、飲み会のわりかんであれば、「飲み会に初めから参加しているメンバーのグループ」と「途中から参加したメンバーのグループ」）に分け、それぞれのグループに対してわりかんを行うこととしてもよい。

【0329】

図３－６は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかんリクエスト管理データベース１５７Ｄのデータ構成の一例を示す図である。
わりかんリクエスト管理データベース１５７Ｄでは、各々のわりかんリクエスト管理データに、アプリケーションＩＤと、わりかん総額と、わりかんリクエスト日時と、わりかんメンバー管理データとに加えて、限定ではなく例として、わりかんグループ管理データが記憶される。

【0330】

わりかんグループ管理データは、わりかんをする複数のグループを管理するためのデータであり、限定ではなく例として、グループ名と、グループＩＤと、グループ内わりかん総額とが関連付けて記憶される。

【0331】

グループ名には、限定ではなく例として、マスターの端末２０から送信されたグループ名の情報に基づいてサーバ１０の制御部１１によって記憶される。

【0332】

グループＩＤには、限定ではなく例として、サーバ１０の制御部１１によってユニークなＩＤが設定されて記憶される。

【0333】

グループ内わりかん総額は、このグループ名（このグループＩＤ）のグループ内でわりかんをする金額の総額であり、限定ではなく例として、マスターの端末２０から送信された金額の情報に基づいてサーバ１０の制御部１１によって記憶される。

【0334】

限定ではなく例として、グループ内わりかん総額の総和がわりかん総額となるように各グループ内わりかん総額を設定することができる。

【0335】

また、わりかんメンバー管理データには、限定ではなく例として、わりかんメンバーのアプリケーションＩＤと、ユーザ名と、メンバー種別と、支払い金額とに加えて、限定ではなく例として、このわりかんメンバーが含まれるグループのグループＩＤが記憶される。
各々のわりかんメンバーのグループＩＤは、限定ではなく例として、マスターの端末２０から送信される情報に基づいてサーバ１０の制御部１１によって記憶される。

【0336】

図３－７～図３－８は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する６名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１わりかんグループ（「第１Ｇ」と称する。）＝ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ
・第１Ｇの第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第１Ｇの第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
・第２わりかんグループ（「第２Ｇ」と称する。）＝ユーザＥ．Ｅ、ユーザＦ．Ｆ
とする場合の表示画面例を説明する。

【0337】

以下では、第１Ｇメンバー種別のユーザを「第１Ｇのユーザ」、または「第１Ｇユーザ」、第２Ｇメンバー種別のユーザを「第２Ｇのユーザ」または「第２Ｇユーザ」と称することがある。また、第１Ｇを、適宜「第１グループ」や「第１のグループ」と称し、第２Ｇを、適宜「第２グループ」や「第２のグループ」と称することがある。また、第１Ｇユーザの端末を「第１Ｇの端末」または「第１Ｇ端末」、第２Ｇユーザの端末を「第２Ｇの端末」または「第２Ｇ端末」と称することがある。

【0338】

また、以下では、第１Ｇメンバー種別のユーザを、第１種メンバー種別のユーザと第２種メンバー種別のユーザとに分けることが可能である。同様に、第２Ｇメンバー種別のユーザを、第１種メンバー種別のユーザと第２種メンバー種別のユーザとに分けることが可能である。

【0339】

図３－７左側の表示画面については、前述した図１－１４左側と同様であるので説明を省略する。

【0340】

限定ではなく例として、わりかん機能ボタンＭＢＴ１がユーザによってタップされると、限定ではなく例として、図３－７中央の画面に表示が遷移する。図３－７中央の表示画面については、前述した図１－１４中央と同様である部分についての説明を省略する。

【0341】

この例では、わりかん総額入力領域ＳＡＲ１には、わりかん総額として「４０，０００円」が入力され表示されている。

【0342】

また、わりかんメンバー指定領域に、６名のわりかんメンバー（ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ、ユーザＦ．Ｆ）が指定され表示されている。

【0343】

限定ではなく例として、わりかん設定画面最下部の「選択」ボタンがユーザによってタップされると、図３－７右側のわりかんグループ設定画面に表示が遷移する。図３－７右側の表示画面については、前述した図１－１４右側と同様である部分についての説明を省略する。

【0344】

この例では、「第１わりかんグループ」タブの下には、「多く払えるグループ」タブの下に、第１種ユーザとしてユーザＢ．ＢおよびユーザＣ．Ｃが表示されており、「多く払わないグループ」タブの下に、第２種ユーザとしてユーザＡ．ＡおよびユーザＤ．Ｄが表示されている。
また、「第２わりかんグループ」タブの下には、ユーザＥ．ＥおよびユーザＦ．Ｆが表示されている。

【0345】

限定ではなく例として、幹事であるユーザＡ．Ａは、第１Ｇユーザであるが、第２Ｇユーザではないため、端末２０Ａには、第２Ｇユーザに属する各ユーザ（Ｅ．Ｅ，Ｆ．Ｆ）が、第１種ユーザ（多く払えるグループ）又は第２種ユーザ（多く払わないグループ）、の何れであるのかまでは表示されていない。
このような形態に限らず、他のグループの各ユーザが、第１種ユーザ又は第２種ユーザのいずれであるのかまで表示されるようにしてもよい。

【0346】

限定ではなく例として、わりかんグループ設定画面最下部の「グループ別金額設定」ボタンがユーザによってタップされると、図３－８左側のわりかんグループ別金額設定画面に表示が遷移する。
このわりかんグループ別金額設定画面では、限定ではなく例として、わりかんグループでわりかんを行う金額（グループ別わりかん総額）を設定するためのグループ別わりかん総額設定領域ＳＡＲ２が表示されるように構成されている。

【0347】

限定ではなく例として、ユーザがグループ別わりかん総額設定領域ＳＡＲ２には、各グループのグループ別わりかん総額を変更するための移動可能な境界バーが設けられており、この境界バーをユーザが左右にドラッグすると、限定ではなく例として、各グループのグループ別わりかん総額を変更することができる。このように、第１わりかんグループ及び第２わりかんグループの負担総額を示す領域において、第１わりかんグループと第２わりかんグループとの境界を変更することによって、負担総額を変更することなく（負担総額の範囲内で）第１わりかんグループと第２わりかんグループのそれぞれの負担額（グループとしての負担額）を設定することができる。
この画面では、グループ別わりかん総額設定領域ＳＡＲ２には、第１わりかんグループのグループ別わりかん総額として「３２，０００円」が、第２わりかんグループのグループ別わりかん総額として「８，０００円」が、設定され表示されている。

【0348】

限定ではなく例として、グループ別金額設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０にわりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報と、グループ別金額設定画面での設定内容に基づくグループ別わりかん総額情報とが送信される。

【0349】

図３－８中央には、この場合における第１Ｇの端末２０Ｃのお知らせ画面の一例を示している。図３－８中央の表示画面については、前述した図２－３左側と同様である部分についての説明を省略する。

【0350】

この例では、お知らせ情報ＮＴ１０が表示されている。
お知らせ情報ＮＴ１０には、第１Ｇのグループ別わりかん総額が「３２，０００円」であることと、わりかん人数が「４人」であることと、第１ＧユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、均等額（「８，０００円」）を支払うこととに関する送金リクエストが含まれる。
第１Ｇについて以降の処理は、限定ではなく例として、前述の実施例と同様に実行することができる。

【0351】

また、限定ではなく例として、第２Ｇの端末２０Ｅでは、図３－８右側のお知らせ画面が表示される。図３－８中央右側の表示画面については、前述した図３－８中央と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＥ．Ｅの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0352】

この例では、お知らせ情報ＮＴ１１が表示されている。
お知らせ情報ＮＴ１１に、第２Ｇのグループ別わりかん総額が「８，０００円」であることと、わりかん人数が「２人」であることと、第２ＧユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、均等額（「４，０００円」）を支払うこととに関する送金リクエストが含まれる。
第２Ｇについて以降の処理は、限定ではなく例として、通常のわりかんと同様に実行することができる。

【0353】

本変形例は、わりかんメンバー情報（限定ではなく、指定情報の一例）は、第１わりかんグループ（限定ではなく、第１グループの一例）と第２わりかんグループ（限定ではなく、第２グループの一例）とを指定する情報を含み、仮均等額の情報（限定ではなく、第１金額情報の一例）と、均等額の情報（限定ではなく、第２金額情報の一例）とは第１わりかんグループに送信され、残りの金額に基づく均等額の情報（限定ではなく、第４金額情報の一例）を第２わりかんグループに含まれるメンバーに通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、限定ではなく例として、第１グループと第２グループとのうち、第１金額情報と、第２金額情報との各々に含まれる金額を第１グループに知らせることができる一方、第４金額情報に含まれる金額を第２グループに含まれるユーザに知らせることができる。

【0354】

＜第４実施例＞
第４実施例は、支払い（限定ではなく例として、仮均等額に基づく第１種メンバーによる支払い）の順番を変える（変更する）ことに関する実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0355】

＜データ構成＞
本実施例では、限定ではなく例として、図２－１に示したわりかんリクエスト管理データベース１５７Ｂを用いることができる。
支払いの順番を変更することには、限定ではなく例として、支払いをスキップする（次の人に支払いを飛ばず）ことを含めてもよいものとする。

【0356】

＜表示画面＞
図４－１～図４－３は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する６名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0357】

限定ではなく例として、サーバ１０から、ユーザＣ．Ｃの端末２０Ｃに対して支払いに関するお知らせ情報が送信されたことに基づいて、第１種の端末２０Ｂでは、図４－１左側のお知らせ画面が表示される。
図４－１左側の表示画面については、前述した図２－３左側と同様であるので説明を省略する。

【0358】

限定ではなく例として、第１仮均等額送金依頼情報ＴＳＲ１１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図４－１中央の送金画面に表示が遷移する。
図４－１中央の表示画面については、前述した図２－３中央と同様である部分についての説明を省略する。

【0359】

この例では、画面最下部の「決定」ボタンの上に、この支払いをスキップするための「支払いスキップ」ボタンが表示されている。

【0360】

限定ではなく例として、「支払いスキップ」ボタンがユーザによってタップされると、限定ではなく例として、図４－１右側の送金結果画面に表示が遷移する。

【0361】

この送金結果画面では、ユーザＣ．ＣがユーザＡ．Ａに対する送金（支払）をスキップしたことが表示されている。ここで、「送金（支払）をスキップする」ことは、送金処理の実行を保留すること（例えば、送金処理を実行させるための操作を保留すること）であってもよく、送金額の決定を保留すること（例えば、自分が負担する金額を決定するための操作を保留すること）であってもよい。

【0362】

限定ではなく例として、サーバ１０から、ユーザＢ．Ｂの端末２０Ｂに対して、支払いに関するお知らせ情報が送信されると、第１種の端末２０Ｂにおいて、図４－２左側のお知らせ画面～図４－２中央の送金結果画面に示すような表示がなされる。

【0363】

図４－２左側および図４－２中央の表示画面については、前述した図２－４中央および図２－５中央と同様であるので説明を省略する。

【0364】

限定ではなく例として、ユーザＢ．Ｂによる支払い金額に関する情報や、ユーザＣ．Ｃによる支払いスキップに関する情報が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、これらの情報に関するお知らせ情報が送信される。

【0365】

図４－２右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図４－２右側の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。

【0366】

この例では、お知らせ情報ＮＴ１２～ＮＴ１４が上から順に表示されている。
お知らせ情報ＮＴ１２には、第１種ユーザであるユーザＣ．Ｃが幹事であるユーザＡ．Ａに対して支払いをスキップしたことに関する情報が含まれる。
お知らせ情報ＮＴ１２は、お知らせ情報ＮＴ１３、ＮＴ１４が表示される前から表示されていた情報（お知らせ情報ＮＴ１３、ＮＴ１４を表示させるための情報の受信前に受信した情報に基づいて表示される情報）であり、本例では、「受取済金額入力」と表示された第１ボタンが含まれる。
幹事であるユーザＡ．ＡがユーザＣ．Ｃから現金による支払を受けた場合には、第１ボタンをタップし、ユーザＣ．Ｃから支払われた金額を入力することにより、支払が完了していない他のユーザ（例えば、Ａ．Ａ、Ｂ．Ｂ、Ｄ．Ｄ）が支払うべき残りの金額が更新され、残りの金額に基づいて、各ユーザの負担額（例えば、均等額）が再計算され、各ユーザの端末に通知されることになる。

【0367】

お知らせ情報ＮＴ１３は、本例では、ユーザＣ．Ｃによる送金のスキップ後（スキップに基づく情報の受信後）、ユーザＢ．Ｂの負担額決定に基づいて表示される情報である。
お知らせ情報ＮＴ１３には、第１種ユーザであるユーザＢ．Ｂが幹事であるユーザＡ．Ａに対して支払い予定額（「８，０００円」）を支払うことに関する情報が含まれる。

【0368】

お知らせ情報ＮＴ１４は、限定ではなく例として、わりかんグループ内の、送金をスキップしたユーザ（Ｃ．Ｃ）とは異なる他のユーザ（Ｂ．Ｂ）の負担額が決定されたことに基づいて表示されている。
お知らせ情報ＮＴ１４には、第１種ユーザであるユーザＣ．Ｃが幹事であるユーザＡ．Ａに対する支払い（負担額の決定）をスキップしたことに関するリマインド情報が含まれる。
本例では、お知らせ情報ＮＴ１４には、「金額入力を督促」と表示された第２ボタンと、その下方の、「受取済金額入力」ボタンと表示された第１ボタンと、が含まれる。

【0369】

幹事であるユーザＡ．Ａが、第２ボタンをタップすることで、送金をスキップしたユーザ（Ｃ．Ｃ）の端末２０Ｃには、保留されている支払（負担額の決定）を支払いアプリケーションによって実行するように促すリマインド情報が表示される。
一方、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払いアプリケーションを用いずに現金で支払を行った場合、ユーザＡ．Ａは、第１ボタンをタップすることで、ユーザＣ．Ｃによる支払いが完了したことを履歴として残すことが可能であり、支払が完了していない残りのユーザ（例えば、Ａ．Ａ，Ｃ．Ｃ）の端末に、ユーザＣ．Ｃによる支払に基づく更新後の負担額（例えば、均等額）を通知することが可能である。

【0370】

このように、同じわりかんグループに属するユーザ（Ｂ．Ｂ）による負担額の決定に基づいて、送金を保留したユーザ（Ｃ．Ｃ）に支払（負担額の決定）を改めて要求するか、または、送金を保留したユーザ（Ｃ．Ｃ）から受け取った金額を入力して、支払履歴を残すとともに、残りのユーザ（Ａ．Ａ，Ｄ．Ｄ）の負担額を再計算して、各ユーザの端末に表示させることが可能である。

【0371】

そして、限定ではなく例として、お知らせ情報ＮＴ１４の第１ボタンがユーザによってタップされると、限定ではなく例として、図４－３左側の受取済金額入力画面に表示が遷移する。

【0372】

この画面では、限定ではなく例として、幹事であるユーザＡ．ＡがユーザＣ．Ｃから現金で受け取った金額を入力するための受取済金額指定領域ＲＡＲ３が表示されるように構成されている。

【0373】

限定ではなく例として、テンキー入力領域などにおいて指定された金額「１０，０００円」が受取済金額指定領域ＲＡＲ３に入力され、画面下部の「決定」ボタンがタップされると、サーバ１０から、第２種ユーザのユーザＤ．Ｄの端末２０Ｄに対して、第２種ユーザの均等額に関するお知らせ情報が送信される。

【0374】

図４－３右側には、この場合における第２種の端末２０Ｄのお知らせ画面の一例を示している。図４－３右側の表示画面については、前述した図２－６（ａ）と同様であるので説明を省略する。

【0375】

なお、上記の例において、第１種ユーザ（Ｃ．Ｃ）の端末に「支払いスキップ」ボタンが表示されているが、第２種ユーザ（例えば、Ｄ．Ｄ）の端末には、「支払いスキップ」ボタンが表示されないものとする。
すなわち、第２種ユーザ（Ｄ．Ｄ）の端末からは、送金をスキップすることができないようになっており、第２種ユーザ（Ｄ．Ｄ）が、支払いアプリケーションを用いて均等額を支払わない場合、幹事であるユーザＡ．Ａの端末には、図４－２右側の表示画面における、お知らせ情報ＮＴ１２（第２種ユーザの現金による支払履歴を残すための第１ボタンを含む）は表示されない。また、第１種ユーザ（例えば、Ｂ．Ｂ）の支払に基づくお知らせ情報ＮＴ１３は表示されるが、お知らせ情報ＮＴ１４（第１ボタン、リマインド情報を第２種ユーザの端末に表示させるための第２ボタンを含む）は表示されない。

【0376】

なお、このような形態に限らず、上記の例において、第１種ユーザ（Ｃ．Ｃ）の端末に「支払いスキップ」ボタンが表示されると同様に、第２種ユーザ（例えば、Ｄ．Ｄ）の端末にも、「支払いスキップ」ボタンが表示されるようにしてもよい。
すなわち、第２種ユーザ（Ｄ．Ｄ）の端末からも、送金をスキップすることが可能であり、第２種ユーザ（Ｄ．Ｄ）が、支払いアプリケーションを用いて均等額を支払わない場合、幹事であるユーザＡ．Ａの端末には、図４－２右側の表示画面における、お知らせ情報ＮＴ１２（第２種ユーザの現金による支払履歴を残すための第１ボタンを含む）が表示される。また、第１種ユーザ（例えば、Ｂ．Ｂ）の支払に基づくお知らせ情報ＮＴ１３が表示され、お知らせ情報ＮＴ１４（第１ボタン、リマインド情報を第２種ユーザの端末に表示させるための第２ボタンを含む）も表示される。

【0377】

＜処理＞
図４－４は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。図の見方は、図２－８と同様である。
限定ではなく例として、この処理では、メンバー内順位が「１」であるユーザＣ．Ｃはスキップをしなかったが、メンバー内順位が「２」であるユーザＢ．Ｂがスキップする場合を例示する。

【0378】

Ｂ１１０の後、端末２０Ｂの制御部２１は、Ｂ１１０で表示した仮均等額送金依頼情報に基づき、支払いをスキップするためのユーザ入力が入出力部２３を介してなされたことに基づき（Ｂ３１０）、スキップ依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ３２０）。
なお、これに先だって、ユーザＣ．Ｃの端末２０Ｃからは送金依頼情報がサーバ１０に送信されているものとする。

【0379】

通信Ｉ／Ｆ１４によって端末２０Ｂからスキップ情報を受信すると、サーバ１０の制御部１１は、限定ではなく例として、Ｓ２２０の処理を行い、ユーザＢ．Ｂの送金依頼金額を「０」とする第１種送金金額情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２２０）。

【0380】

端末２０Ａの制御部２１は、Ａ２３０の処理を行った後、受取済み金額入力処理を行う（Ａ３１０）。具体的には、スキップによって送金依頼金額が「０」である場合、入出力部２３を介した受取済みの金額を入力するユーザ入力を受け付ける。
そして、端末２０Ａの制御部２１は、受け付けた受取済み金額を含む第１種送金金額情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３２０）。
通信Ｉ／Ｆ１４によって端末２０Ａから受取済み金額を含む第１種送金金額情報を受信すると、受取済み金額をわりかんメンバー管理データにおけるそのユーザの支払い金額に更新して記憶させる。

【0381】

Ｓ２２０の後、サーバ１０の制御部１１は、第１種メンバー全員から送金依頼情報またはスキップ情報を受信したか否かを判定し（Ｓ３１０）、いずれも受信していない第１種メンバーがいる場合は（Ｓ３１０：ＮＯ）、Ｓ２１０に処理を戻す。

【0382】

一方、第１種メンバー全員から送金依頼情報またはスキップ情報を受信したと判定したならば（Ｓ３１０：ＹＥＳ）、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから送信される第１種送金金額情報の受信を待機し、受信したと判定したならば、Ｓ１５０の処理を行う。
そして、サーバ１０の制御部１１は、Ｓ１７０に処理を進める。

【0383】

＜第４実施例の効果＞
本実施例は、サーバ１０が、スキップ情報（限定ではなく、支払いの入力をスキップすることを示すスキップ情報の一例）の受信に基づいて、送金依頼金額を入力するユーザの順番を変更する処理を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、支払いの入力をスキップすることを示すスキップ情報の受信に基づいて、支払い金額を入力するユーザの順番を変更することができる。

【0384】

＜第４変形例（１）＞
上記の実施例では、逐次仮均等額送金依頼情報（均等額送金依頼情報）を受信した端末２０において、スキップ入力処理を実行することとしたが、これに限定されない。
限定ではなく例として、あるわりかんメンバーの端末２０において、限定ではなく例として、一定期間内に送金依頼情報（スキップ依頼情報）が送信されない場合、幹事の端末２０において、そのメンバーの端末２０をスキップさせることができるようにしてもよい。

【0385】

図４－５は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、前述した図２－２～図２－７と同様に、ユーザＣ．Ｃが一番目に支払いを行い、ユーザＢ．Ｂが二番目に支払いを行う順番が予め設定がされているものとする。

【0386】

図４－５左側の表示画面については、前述した図４－１左側と同様であるので説明を省略する。

【0387】

限定ではなく例として、ユーザＣ．Ｃによる支払い（送金額の決定）がなされないまま一定の期間が経過すると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、支払（送金額の決定）がされていないことに関するお知らせ情報が送信される。

【0388】

図４－５中央には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図４－５中央の表示画面については、前述した図４－２右側と同様である部分についての説明を省略する。

【0389】

この例では、お知らせ情報ＮＴ１５が表示されている。
お知らせ情報ＮＴ１５には、幹事であるユーザＡ．ＡがユーザＣ．Ｃがに対する支払い金額の決定をスキップさせることに関するリマインド情報が含まれる。このお知らせ情報ＮＴ１５には、限定ではなく例として、幹事であるユーザＡ．Ａが、支払いの済んでいない（負担額が決定されていない）ユーザの順番をスキップするための「順番スキップ」ボタンが含まれている。

【0390】

限定ではなく例として、「順番スキップ」ボタンがユーザによってタップされると、サーバ１０から、ユーザＣ．Ｃの次の支払い順番であるユーザＢ．Ｂの端末２０Ｂに対して、支払いに関するお知らせ情報が送信される。

【0391】

図４－５右側には、この場合における第１種の端末２０Ｂのお知らせ画面の一例を示している。図４－５右側の表示画面については、前述した図４－２左側と同様であるので説明を省略する。

【0392】

本変形例は、スキップ情報は、マスターの端末２０（限定ではなく、第１端末の一例）から送信された情報である構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末から送信されたスキップ情報の受信に基づいて、支払い金額を入力するユーザの順番を変更することができる。

【0393】

＜第５実施例＞
第５実施例は、メンバー種別として異なる定義を用いることに関する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0394】

本実施例では、「第１種」は、限定ではなく例として、わりかんメンバーのうち、お金をわりかんメンバー全員で均等にわりかんする金額よりも「少なく払えるグループ」に分類されたユーザに設定されるようにすることができる。
また、「第２種」は、限定ではなく例として、わりかんメンバーのうち、お金をわりかんメンバー全員で均等にわりかんする金額より「少なく払わないグループ」（「少なく払えないグループ」と言ってもよい。）に分類されたユーザに設定されるようにすることができる。

【0395】

＜表示画面＞
図５－１～図５－２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0396】

図５－１左側および中央の表示画面については、前述した図１－１４左側および中央と同様であるので説明を省略する。

【0397】

限定ではなく例として、わりかん設定画面最下部の「選択」ボタンがユーザによってタップされると、図５－１右側のわりかんグループ設定画面に表示が遷移する。図５－１右側の表示画面については、前述した図１－１４右側と同様である部分についての説明を省略する。

【0398】

この例では、「少なく払えるグループ」タブの下には、第２種ユーザとしてユーザＤ．ＤおよびユーザＡ．Ａが表示されており、「少なく払わないグループ」タブの下には、第１種ユーザとしてユーザＢ．ＢおよびユーザＣ．Ｃが表示されている。

【0399】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報とが送信される。

【0400】

図５－２左側には、この場合における第２種の端末２０Ｄのお知らせ画面の一例を示している。図５－２左側の表示画面については、前述した図１－１５左側と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＤ．Ｄの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0401】

限定ではなく例として、「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図５－２中央の送金画面に表示が遷移する。図５－２中央の表示画面については、前述した図１－１５中央と同様である部分についての説明を省略する。

【0402】

この例では、送金金額指定領域ＲＡＲ１と、送金先指定領域との間には、送金金額指定領域ＲＡＲ１において指定された送金金額を減額させるための、「少なく支払う」の文字で示される送金額減額ボタンＡＩＢ２が表示されるように構成されている。
限定ではなく例として、第２種のユーザは、送金額減額ボタンＡＩＢ２を用いて仮均等額以下の金額を自らの負担額として設定し、設定した額を送金することができる。

【0403】

限定ではなく例として、送金金額指定領域ＲＡＲ１に、仮均等額「５，０００円」よりも少ない「２，０００円」が送金金額として指定されたことが表示されている。
そして、限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされ、同様にして、第２種ユーザであるユーザＡ．Ａによって支払い金額が決定されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、これらの支払い金額に基づく第１種ユーザのわりかん金額に関するお知らせ情報が送信される。

【0404】

図５－２右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図５－２右側の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。

【0405】

この例では、お知らせ情報ＮＴ１６～ＮＴ１８が上から順に表示されている。
お知らせ情報ＮＴ１６には、第２種ユーザであるユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、支払い予定額（「２，０００円」）を支払うことに関する情報が含まれる。
また、お知らせ情報ＮＴ１７には、第２種ユーザであるユーザＡ．Ａが、幹事であるユーザＡ．Ａ（本人）に対して、支払い予定額（「３，０００円」）を支払うこと（すなわち、第２種ユーザである幹事本人の負担額）に関する情報が含まれる。
また、お知らせ情報ＮＴ１８には、第１種ユーザであるユーザＢ．ＢおよびユーザＣ．Ｃが、それぞれ、幹事であるユーザＡ．Ａに対して、均等額（「７，５００円」）を支払うことに関する情報が含まれる。

【0406】

＜第６実施例＞
第６実施例は、（１）の手法を、メッセージングアプリケーション（限定ではなく、チャットアプリケーションの一例）を用いて実現することに関する実施例である。限定ではなく例として、わりかんに関する情報（わりかんに関する通知）をメッセージングアプリケーションのトークルーム（限定ではなく、チャットルームの一例）に送信・表示することや、メッセージングアプリケーションと支払いアプリケーションとを連携させてわりかんを行う手法等に関する。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0407】

＜表示画面＞
図６－１～図６－４は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
とする場合の表示画面例を説明する。

【0408】

以下の例では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃと、ユーザＤ．Ｄが、何れも「開発グループ」のグループトークルームに属しており、友だち登録されているものとする。

【0409】

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

【0410】

また、その下には、メッセージングアプリケーションにおける現在位置を示す現在位置表示領域が構成されており、この例では、現在位置がメッセージングアプリケーションのグループトークルームであることを示す「開発グループ（４）」の文字が、現在位置表示領域内に表示されている。なお、「開発グループ（４）」の（４）とは、このグループトークルームに属するメンバーの人数を示している。

【0411】

また、現在位置表示領域の下には、このトークルームに送信（投稿）されるコンテンツ（メッセージ）を表示するためのコンテンツ表示領域が表示されるように構成されている。
また、コンテンツ表示領域の下には、このトークルームに送信するコンテンツを入力・選択するためのコンテンツ入力領域が表示されるように構成されている。

【0412】

コンテンツ表示領域では、限定ではなく例として、右側に自端末である端末２０ＡのユーザＡ．Ａの発言が、左側にそれ以外のユーザの発言が、それぞれコンテンツとして吹き出しで表示されるように構成されている。
この画面では、コンテンツ表示領域において、ユーザＤ．Ｄの歓迎会が執り行われ、幹事であるユーザＡ．Ａが会費を集める旨のコンテンツが表示されている。

【0413】

限定ではなく例として、コンテンツ入力領域の「＋」ボタンがユーザによってタップされると、限定ではなく例として、トークルーム画面下側からメッセージングアプリケーションの各種機能を実行するためのメイン機能ボタンが並んで表示されているメイン機能ボタン表示領域がせり上がり表示されている。

【0414】

限定ではなく例として、わりかん機能ボタンＭＢＴ１がユーザによってタップされると、限定ではなく例として、図６－１右側のわりかんグループ設定画面に表示が遷移する。

【0415】

図６－１右側の表示画面については、アプリケーションの名称および現在位置表示領域の文字を除いて、前述した図１－１４右側と同様であるので説明を省略する。

【0416】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかんグル－プ設定画面への入力内容に基づくわりかん要求情報と、わりかんグループ設定画面への入力内容に基づくわりかんメンバー情報とが送信される。

【0417】

図６－２左側には、この場合における第１種の端末２０Ｂの公式アカウント（ＯＡ）トークルーム画面の一例を示している。図６－２左側の表示画面については、前述した図６－１左側と同様である部分についての説明を省略する。

【0418】

この例では、現在位置表示領域には、公式ユーザ名「Ｐａｙｍｅｎｔ Ａｐｐ」とのＯＡトークルーム画面であることを示す「Ｐａｙｍｅｎｔ」の文字が表示されている。
また、コンテンツ表示領域には、コンテンツ情報ＣＴ０１が表示されている。
コンテンツ情報ＣＴ０１には、幹事であるユーザＡ．Ａに対して、仮均等額として、わりかん総額「２０，０００円」÷「４人」＝「５，０００円」（第１均等額）を支払うことに関する送金リクエスト（わりかんリクエスト）が含まれる。

【0419】

限定ではなく例として、コンテンツ情報ＣＴ０１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、支払いアプリケーションが起動し、図６－２中央の送金画面に表示が遷移する。

【0420】

この送金画面では、送金金額指定領域ＲＡＲ１には、コンテンツ情報ＣＴ０１における送金リクエストに基づいて、仮均等額「５，０００円」が指定され表示されている。また、送金先指定領域には、開発グループのメンバーであり、幹事であるユーザＡ．Ａが指定され表示されている。

【0421】

また、送金金額指定領域ＲＡＲ１と、送金先指定領域との間には、送金金額指定領域ＲＡＲ１において指定された送金金額を増額させるための、「多めに支払う」の文字で示される送金額増額ボタンＡＩＢ３が表示されるように構成されている。
限定ではなく例として、第１種のユーザは、送金額増額ボタンＡＩＢ３を用いて仮均等額以上の金額を自らの負担額として設定し、設定した額を送金することができる。

【0422】

また、送金額増額ボタンＡＩＢ３の下には、限定ではなく例として、第１種メンバーと幹事とがグループメンバーとして属するグループトークルームを一時的に作成し、そのグループトークルームに移動するための「チャットで相談」ボタンが表示されるように構成されている。

【0423】

限定ではなく例として、「チャットで相談」ボタンがユーザによってタップされると、限定ではなく例として、メッセージングアプリケーションに切り替わり、図６－２右側のトークルーム画面に表示が遷移する。図６－２右側の表示画面については、前述した図６－２左側と同様である部分についての説明を省略する。

【0424】

この例では、現在位置表示領域には、開発グループのメンバーのうち第１種メンバーと幹事とで構成されたグループであることに基づいて、「開発グループ（３）」の文字などが表示されている。
また、コンテンツ表示領域には、限定ではなく例として、第１種メンバーと幹事とがグループメンバーとして属する一時的トークルームに自動的に投稿（送信）されたわりかん内容に関するコンテンツが表示されている。その下には、ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃが送信した、ユーザＣ．Ｃが「１０，０００円」を負担する旨のコンテンツ情報が表示されている。

【0425】

コンテンツ表示領域の最下部には、支払いアプリケーションに戻るための「Ｐａｙｍｅｎｔ Ａｐｐに戻る」ボタンが表示されている。

【0426】

限定ではなく例として、ユーザによって「Ｐａｙｍｅｎｔ Ａｐｐに戻る」ボタンがタップされ、支払いアプリケーションに戻ると、限定ではなく例として、図６－３左側の送金画面に表示が遷移する。

【0427】

限定ではなく例として、送金額増額ボタンＡＩＢ３がユーザによってタップされると、限定ではなく例として、図６－３中央の送金画面に表示が遷移する。

【0428】

この例では、送金金額指定領域ＲＡＲ１には、送金額増額ボタンＡＩＢ３がユーザによってタップされたことに基づいて、仮均等額よりも増額した金額「８，０００円」が指定され表示されている。

【0429】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図６－３右側の送金結果画面に表示が遷移する。

【0430】

この例では、ユーザＢ．ＢがユーザＡ．Ａに仮均等額より増額した金額「８，０００円」を送金したことが表示されている。

【0431】

また、送金結果画面の下部には、さらに追加して送金を行うための「さらに多めに支払う」の文字で示される追加送金ボタンが表示されるように構成されている。

【0432】

限定ではなく例として、第１種ユーザであるユーザＢ．ＢとユーザＣ．Ｃとが支払い金額を定め、送金が実行された後の、第２種の端末２０Ｄの表示部２４に表示されるトークルーム画面の一例を図６－４左側に示す。

【0433】

この例では、コンテンツ表示領域には、コンテンツ情報ＣＴ０２およびＣＴ０３などが表示されている。
コンテンツ情報ＣＴ０２は、送信元がユーザＣ．Ｃであるコンテンツ情報であって、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い金額「５，０００円」を支払ったことに関する情報が含まれる。また、コンテンツ情報ＣＴ０２には、このユーザの支払い金額が仮均等額であったことに基づいて、挨拶をするクマのイラストが表示されている。
また、コンテンツ情報ＣＴ０３は、送信元がユーザＢ．Ｂであるコンテンツ情報であって、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額「８，０００円」を支払ったことに関する情報が含まれる。また、コンテンツ情報ＣＴ０３には、このユーザの支払い金額が仮均等額よりも大きい金額であったことに基づいて、紙吹雪をまき盛り上がるクマのイラストが表示されている。

【0434】

また、コンテンツ情報ＣＴ０３には、このユーザの支払い金額が仮均等額よりも大きい金額であったことに基づいて、端末のユーザがリアクションを行うための「リアクション」ボタンが表示されている。

【0435】

限定ではなく例として、コンテンツ情報ＣＴ０３の「リアクション」ボタンがユーザによってタップされ、ユーザＤ．Ｄがコンテンツ情報ＣＴ０３の内容に対してリアクションを行うと（本例では、ユーザＣ．Ｃもリアクションを行っている）、第１種の端末２０Ｂでは、限定ではなく例として、図６－４右側のようなトークルーム画面が表示される。

【0436】

この例では、コンテンツ表示領域には、コンテンツ情報ＣＴ０４およびＣＴ０５等が表示されている。
コンテンツ情報ＣＴ０４は、送信元がユーザＣ．Ｃであるコンテンツ情報であって、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い金額「５，０００円」を支払ったことに関する情報と、挨拶をするクマのイラストとが含まれる。
また、コンテンツ情報ＣＴ０５は、送信元がユーザＢ．Ｂであるコンテンツ情報であって、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額「８，０００円」を支払ったことに関する情報と、紙吹雪をまき盛り上がるクマのイラストと、他のユーザが行ったリアクションに関する情報とが含まれる。この例では、ユーザＣ．ＣとユーザＤ．Ｄとがリアクションを行ったことに基づいて、ユーザＣ．ＣとユーザＤ．Ｄとのアイコンがリアクションアイコン（限定ではなく例として、感謝を示すウサギのアイコン）と共に表示されている。

【0437】

また、コンテンツ情報ＣＴ０５では、自端末（端末２０Ｂ）のユーザの支払いに関する情報であることに基づいて、端末２０Ｂにおいては「リアクション」ボタンが表示されないように構成されている。なお、自端末においても「リアクション」ボタンが表示されるようにしてもよい。

【0438】

なお、「リアクション」ボタンがユーザによってタップされると、リアクションの種類（限定ではなく例として、リアクションを行ったときに表示されるリアクションアイコン）が選択できるようにしてもよい。

【0439】

また、ユーザの支払い金額が仮均等額であった場合においても、コンテンツ情報に「リアクション」ボタンが含まれ、リアクションが行えるようにしてもよい。

【0440】

＜第６実施例の効果＞
本実施例は、サーバ１０は、第１種メンバーが支払った金額に基づく通知を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、指定されたユーザが支払いを行った金額等の情報を通知することができる。

【0441】

また、この場合、サーバ１０は、送信した通知に対するリアクションの情報を通信Ｉ／Ｆ１４によって受信し、受信したリアクションの情報を、第１種メンバーと第２種メンバーとに通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、指定されたユーザが支払いを行った金額などの情報の通知に対するリアクションの情報を受信した上で、そのリアクションを、指定されたユーザと異なるユーザとに知らせることができる。

【0442】

また、この場合、送信した通知は、マスター（限定ではなく、第１端末のユーザの一例）と、第１種メンバー（限定ではなく、指定されたユーザの一例）とが少なくとも含まれるトークルーム（限定ではなく、チャットルームの一例）に送信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、指定されたユーザが支払いを行った金額などの情報の通知を、第１端末のユーザと、指定されたユーザとが少なくとも含まれるチャットルームに送信することによって、分かり易い形で、第１端末のユーザと指定されたユーザとに知らせることができる。

【0443】

また、この場合、仮均等額の情報（限定ではなく、第１金額情報の一例）は、マスター（限定ではなく、第１端末のユーザの一例）と、第１種メンバー（限定ではなく、指定されたユーザの一例）とが少なくとも含まれるトークルーム（限定ではなく、チャットルームの一例）に送信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１金額情報を、第１端末のユーザと、指定されたユーザとが少なくとも含まれるチャットルームに送信することによって、分かり易い形で、支払いに関する第１金額情報に含まれる金額を、第１端末のユーザと指定されたユーザとに知らせることができる。

【0444】

本実施例は、端末２０は、送金リクエストに基づく送金処理を制御部２１によって行う。そして、端末２０は、送金処理に基づき、マスターの端末２０（限定ではなく、第１端末の一例）に送金することを示す第３表示を表示部２４に表示するようにしてもよい。
このような構成により得られる実施例の効果の一例として、第３表示を用いて第１端末に容易に送金することができ、送金に関する利便性を向上できる。

【0445】

また、この場合、送金リクエスト情報は、マスターの端末２０（限定ではなく、第１端末のユーザ）と、複数のわりかんメンバー（限定ではなく、複数のユーザの一例）とを含むトークルーム（限定ではなく、チャットルームの一例）に送信される。そして、端末２０は、そのトークルームを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと、複数のユーザとに、送金依頼情報を報知することができる。特に、複数のユーザに送金依頼情報を効果的に報知することができる。

【0446】

また、この場合、端末２０は、自己の端末２０のユーザによって、第２表示に対する入力が行われ、送金依頼金額よりも高い金額の送金が行われた場合、トークルームを表示する制御を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、端末のユーザによって第２表示に対する入力が行われ、送金依頼された金額よりも高い金額の送金が行われた場合に、チャットルームを表示することができる。

【0447】

また、この場合、端末２０は、自己の端末２０のユーザによって、第２表示に対する入力が行われ、送金依頼された金額よりも高い金額の送金が行われた場合、トークルームに盛り上げ用の画像等の画像（限定ではなく、第４画像の一例）を表示する制御を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザによって第２表示に対する入力が行われ、送金依頼された金額よりも高い金額の送金が行われた場合に、チャットルームに第４画像を表示して、場を盛り上げるなどすることができる。

【0448】

また、この場合、端末２０は、マスター（限定ではなく、第１端末のユーザの一例）によって、盛り上げ用の画像等の画像に対する入力が行われた場合、それに対するリアクションを示す画像（限定ではなく、第５画像の一例）をトークルームに表示する制御を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末のユーザによって、第４画像に対する入力が行われた場合に、その第４画像に対するリアクションを示す第５画像をチャットルームに表示して、自分の反応を伝えることができる。

【0449】

また、この場合、送金リクエスト情報は、マスターの端末２０（限定ではなく、第１端末の一例）と通信するサーバ１０を介して端末２０に受信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、送金依頼情報を、第１端末と通信するサーバを介して適切に受信することができる。

【0450】

＜第７実施例＞
第７実施例は、前述した「（２）返金を用いる手法」に関する実施例である。限定ではなく例として、複数のわりかんメンバーの各々から送信された支払い金額の情報に基づいて、これら複数のわりかんメンバーに対する処理（限定ではなく例として、第２種メンバー等に対して返金する処理）を行うことによって、わりかんを実現する。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0451】

＜データ構成＞
図７－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかんリクエスト管理データベース１５７Ｅのデータ構成の一例を示す図である。
このわりかんリクエスト管理データベース１５７Ｅは、図１－６のわりかんリクエスト管理データベース１５７Ａとほぼ同様のデータ構成であるが、その一部が異なっている。

【0452】

具体的には、各々のわりかんリクエスト管理データには、アプリケーションＩＤと、わりかん総額と、わりかんリクエスト日時と、わりかんメンバー管理データとに加えて、限定ではなく例として、わりかん均等額が記憶される。
わりかん均等額は、メンバー種別を判定するための基準となる金額であり、限定ではなく例として、「わりかん総額÷幹事を含むわりかんメンバー人数」で算出される。

【0453】

また、このわりかんリクエスト管理データベース１５７Ｅの各々のわりかんリクエスト管理データにおいて、わりかんメンバー管理データには、限定ではなく例として、わりかんメンバーのアプリケーションＩＤと、そのユーザ名と、そのメンバー種別と、支払い金額とが記憶される。

【0454】

ここに示すわりかんメンバー管理データは、端末２０からの支払い金額の受付後のデータであって、返金処理を行う前のデータである。
本実施例において、わりかんメンバー管理データにおけるメンバー種別は、幹事による指定によって設定されるのではなく、幹事を除きわりかんメンバーからの支払い結果に基づいて動的に設定される。
限定ではなく例として、わりかん均等額よりも大きい金額の支払いを行ったメンバーには「第１種」が設定され、わりかん均等額の支払いを行ったメンバーには「第２種」が設定される。

【0455】

＜表示画面＞
図７－２～図７－５は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0456】

ここでは、わりかんに参加する３名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ
・第２種＝ユーザＤ．Ｄ
となる場合の表示画面例を説明する。

【0457】

また、ユーザＢ．Ｂと、ユーザＤ．Ｄとで、送金する順番はいずれの順番でもよい。本例では、限定ではなく例として、第１種ユーザとなるユーザＢ．Ｂの端末２０Ｂの表示画面例を示した後に、第２種ユーザとなるユーザＤ．Ｄの端末２０Ｄの表示画面例を示すが、この順番に限定されないものとする。

【0458】

図７－２左側～図７－３左側の表示画面については、前述した図１－９左側～右側と同様であるので説明を省略する。

【0459】

図７－３中央の送金画面では、ユーザＢ．Ｂによって送金金額指定領域ＲＡＲ１に「１０，０００円」が送金金額として入力された状態が示されている。この状態で「確定」ボタンがタップされると、限定ではなく例として、図７－３右側の送金結果画面に表示が遷移する。

【0460】

図７－４には、端末２０Ｄにおける画面の遷移の一例を示している。図７－４左側～右側の表示画面については、前述した図１－１２左側～右側と同様であるので説明を省略する。
なお、これらの表示画面では、均等額送金依頼情報ＳＲ１において、わりかん均等額「４，０００円」を支払うことに関する送金リクエストが表示されており、送金金額指定領域ＲＡＲ２において、均等額「４，０００円」が指定され表示されており、送金結果画面において、ユーザＤ．ＤがユーザＡ．Ａにわりかん均等額「４，０００円」を送金したことが表示されている。

【0461】

限定ではなく例として、ユーザＢ．Ｂ、ユーザＤ．Ｄによって支払い金額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、支払い金額や、この支払い金額に基づく返金金額に関するお知らせ情報が送信される。

【0462】

図７－５左側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図７－５左側の表示画面については、前述した図２－５右側と同様である部分についての説明を省略する。

【0463】

この例では、お知らせ情報ＮＴ２１が表示されている。
お知らせ情報ＮＴ２１には、わりかん総額（「１２，０００円」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、わりかん均等額より多い支払い金額（「１０，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、わりかん均等額（「４，０００円」）を支払うことと、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、余剰金額（「３，０００円」）を返金することとに関する情報が含まれる。

【0464】

限定ではなく例として、お知らせ情報ＮＴ２１の「返金する」ボタンがユーザによってタップされ、ユーザＤ．Ｄに対して余剰金の返金が行われる（不図示）と、限定ではなく例として、図７－５中央の表示画面に表示が遷移する。図７－５中央の表示画面については、前述した図７－５左側と同様である部分についての説明を省略する。

【0465】

この例では、お知らせ情報ＮＴ２２が表示されている。
お知らせ情報ＮＴ２２には、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、余剰金額（「３，０００円」）を返金したことに関する情報が含まれる。

【0466】

限定ではなく例として、幹事であるユーザＡ．Ａによって余剰金額が返金されると、限定ではなく例として、サーバ１０から、返金対象であるユーザＤ．Ｄの端末２０Ｄに対して、返金に関するお知らせ情報が送信される。

【0467】

図７－５右側には、この場合における端末２０Ｄのお知らせ画面の一例を示している。図７－５右側の表示画面については、前述した図７－４左側と同様である部分についての説明を省略する。

【0468】

この例では、均等額送金依頼情報ＳＲ１の下に、お知らせ情報ＮＴ２３～ＮＴ２５が上から順に表示されている。
お知らせ情報ＮＴ２３には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、支払い金額（「４，０００円」）の送金が完了したことに関する情報が含まれる。
また、お知らせ情報ＮＴ２４には、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、返金金額（「３，０００円」）を返金することに関する情報が含まれる。
また、お知らせ情報ＮＴ２５には、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、返金金額（「３，０００円」）の返金が完了したことに関する情報が含まれる。

【0469】

この均等額送金依頼情報ＳＲ１における「詳細を確認」ボタンは、限定ではなく例として、送金完了に関する情報を受信したことに基づいて、第１態様から、操作を受け付けていないことを示す第２態様（本例では、ハッチング処理された態様）に変化する。第２態様の「詳細を確認」ボタンにユーザがタッチしたとしても、これに基づいて支払のための操作を行うことはできず、均等額の送金を行うことはできない。

【0470】

＜処理＞
図７－６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
通信Ｉ／Ｆ１４によって端末２０Ａからわりかん要求情報を受信し、わりかんリクエスト管理データを更新した後、サーバ１０の制御部１１は、わりかん均等額以上の金額の送金を依頼する均等額以上送金依頼情報を、通信Ｉ／Ｆ１４によって各々のわりかんメンバーの端末２０（この図では、端末２０Ｂおよび端末２０Ｄ）に送信する（Ｓ４１０）。
全てのわりかんメンバーの端末２０に対して均等額以上送金依頼情報を送信する点が、前述した実施例とは異なる。

【0471】

通信Ｉ／Ｆ２２によってサーバ１０から均等額以上送金依頼情報を受信すると、端末２０Ｂの制御部２１は、受信した均等額以上送金依頼情報を表示部２４に表示させる（Ｂ４１０）。そして、端末２０Ｂの制御部２１は、Ｂ１３０，Ｂ１５０のステップを行う。
端末２０Ｄについても同様である（Ｄ４１０～Ｄ４５０）。

【0472】

Ｓ４１０の後、通信Ｉ／Ｆ１４によって端末２０Ｂから送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。具体的には、サーバ１０の制御部１１は、送金依頼情報に基づいて、端末２０Ｂのアカウントからマスターのアカウントに対する送金依頼金額の送金処理を実行すると、受信した送金依頼情報に含まれる送金依頼金額を、ユーザＢ．ＢのアプリケーションＩＤと関連付けて、わりかんメンバー管理データの支払い金額に記憶させる。
限定ではなく例として、Ｂ１３０でユーザＢ．Ｂによってわりかん均等額よりも大きい金額が入力された場合、サーバ１０の制御部１１は、ユーザＢ．ＢのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第１種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＢ．Ｂは第１種メンバーとなる。

【0473】

次いで、サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金依頼情報を受信したか否かを判定し（Ｓ４５０）、受信しなかったと判定したならば（Ｓ４５０：ＮＯ）、残りのわりかんメンバーからの送金依頼情報の受信を待機する。この例では、限定ではなく例として、端末２０Ｄからの送金依頼情報の受信がまだである場合、端末２０Ｄからの送金依頼情報の受信を待機する。

【0474】

通信Ｉ／Ｆ１４によって端末２０Ｄから送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。具体的には、サーバ１０の制御部１１は、送金依頼情報に基づいて、端末２０Ｄのアカウントからマスターのアカウントに対する送金依頼金額の送金処理を実行すると、受信した送金依頼情報に含まれる送金依頼金額を、ユーザＤ．ＤのアプリケーションＩＤと関連付けて、わりかんメンバー管理データの支払い金額に記憶させる。
限定ではなく例として、Ｄ４３０でユーザＤ．Ｄによってわりかん均等額が入力された場合、サーバ１０の制御部１１は、ユーザＤ．ＤのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第２種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＤ．Ｄは第２種メンバーとなる。

【0475】

マスターを除くわりかんメンバー全員から送金依頼情報を受信したと判定したならば（Ｓ４５０：ＹＥＳ）、サーバ１０の制御部１１は、返金額算出処理を行う（Ｓ４７０）。具体的には、わりかんリクエスト管理データのうち、わりかん総額と、わりかん均等額と、わりかんメンバー管理データに記憶された各々の支払い金額とに基づき、第２種メンバーに対していくら返金するかの返金額を算出する。そして、サーバ１０の制御部１１は、返金額を算出すると、マスターのアカウントから第２種メンバーのアカウントに対する返金処理を実行する。

【0476】

Ａ１１０の後、端末２０Ａの制御部２１は、Ａ４９０の終了判定に処理を移す。
Ｓ４９０の後、サーバ１０の制御部１１は、Ｓ４９０の終了判定に処理を移す。
Ｂ１５０の後、端末２０Ｂの制御部２１は、Ｂ４９０の終了判定に処理を移す。
Ｄ４５０の後、端末２０Ｄの制御部２１は、Ｄ４９０の終了判定に処理を移す。

【0477】

なお、Ｓ４７０のステップで、返金額を算出した場合、サーバ１０の制御部１１が、返金が生ずることに関する情報（返金する旨や返金額の情報）を返金対象のメンバーに通知するようにしてもよい。また、返金処理を行った後、返金したことに関する情報（返金した旨や返金額の情報）を返金したメンバーに通知するようにしてもよい。
つまり、サーバ１０が返金対象のメンバーに対して行う処理は、返金対象のメンバーへの返金額を算出する処理や、算出した返金額を返金する処理、返金に関する情報を送信（通知）する処理などを含む概念としてよい。

【0478】

また、これらの処理は、複数のわりかんメンバー（複数のユーザ）に対する処理の一種と捉えてもよく、複数のわりかんメンバーに対する処理には、各々のわりかんメンバーへの返金額を算出する処理（第１種メンバーへの返金額＝「０」）や、各々のわりかんメンバーに対して返金に関する情報を送信（通知）する処理などを含めてもよい。

【0479】

また、複数のわりかんメンバー（複数のユーザ）に対する処理は、複数のわりかんメンバーのうちの一部に対する処理としてもよいし全部に対する処理としてもよい。つまり、少なくとも一人に対する処理としてもよい。

【0480】

また、複数のわりかんメンバー（複数のユーザ）には、マスターを含めることとしてもよいし、含めないこととしてもよい。
そして、複数のわりかんメンバー（複数のユーザ）に対する処理は、マスターを含む複数のわりかんメンバーに対する処理としてもよいし、マスターを除く複数のわりかんメンバーに対する処理としてもよい。

【0481】

＜第７実施例の効果＞
本実施例は、サーバ１０が、マスターの端末２０（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）を通信Ｉ／Ｆ１４によって受信し、このわりかん要求情報に基づき、均等額以上送金依頼情報（限定ではなく、第１金額情報の一例）を通信Ｉ／Ｆ１４によって複数のわりかんメンバーの端末２０に送信する。そして、サーバ１０は、複数のわりかんメンバーの各々の端末２０から、均等額以上送金依頼情報に基づき入力された、支払い金額の情報を含む送金依頼情報を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、わりかん要求情報と、各々のわりかんメンバーから送信された送金依頼情報とに基づいて、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額情報と、複数のユーザの各々から送信された第２金額情報とに基づいて、複数のユーザに対する第１処理が実行されることによって、適確に第１処理を実行することができる。

【0482】

また、この場合、複数のわりかんメンバーに対する処理は、これら複数のわりかんメンバーのうちの少なくとも一人（限定ではなく例として、第２種メンバー）に対して返金する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１金額情報と、複数のユーザの各々から送信された第２金額情報とに基づいて、適確に返金することができる。

【0483】

また、この場合、返金する処理は、複数のわりかんメンバーのうち、第２種メンバー（限定ではなく、第１金額情報に含まれる金額の支払いを行ったユーザの一例）に対して返金する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１金額情報に含まれる金額の支払いを行ったユーザに対して、適確に返金することができる。

【0484】

本実施例は、複数のわりかんメンバーの端末２０とサーバ１０とを備える通信システム１において、端末２０は、サーバ１０から送信されたアプリケーションを受信し、受信したアプリケーションを記憶部２８に記憶する。
サーバ１０は、マスターの端末２０（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）を受信し、受信したわりかん要求情報に基づき、複数のわりかんメンバーの端末２０に対して、均等額の情報（限定ではなく、第１金額情報の一例）を送信する。
複数のわりかんメンバーの端末２０は、受信した均等額の情報に基づき入力された、複数のわりかんメンバーの各々が支払う支払い金額の情報（限定ではなく、第２金額情報の一例）を、アプリケーションによってサーバ１０に送信する。
そして、サーバ１０は、均等額の情報と、複数のわりかんメンバーの端末２０の各々から送信された支払い金額の情報とに基づいて、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）を行う構成を示している。
このような構成により得られる実施例の効果の一例として、複数の端末が、サーバから送信されたアプリケーションを受信し、受信したアプリケーションを記憶部に記憶することによって、本願請求項に係るシステムの発明の機能が実現可能となる状態を作り出すことができる（システムの生産）。その上で、サーバが、第１端末から支払い依頼に関する第１情報を受信し、第１情報に基づき、複数の端末に対して、第１金額情報を送信する。そして、複数の端末は、第１金額情報に基づき入力された、複数の端末の各々が支払う金額の情報である第２金額情報を、アプリケーションによってサーバに送信し、サーバは、第１金額情報と、複数の端末の各々から送信された第２金額情報とに基づいて、複数の端末のユーザに対する第１処理を行うというシステムの発明の機能を実現することができる。また、上記と同様の効果を得ることができる。
なお、これは、本実施例に示したシステムの発明の機能に限らず、他の実施例等に示すシステムの発明の機能についても同様とすることができる

【0485】

＜第７変形例（１）＞
上記の実施例では、マスターのアカウントに対する送金処理を行い、その後、返金額を精算する処理を行うことによって、マスターのアカウントからわりかんメンバーのアカウントに返金を行う例を示したが、これに限定されない。
限定ではなく例として、サーバ１０の制御部１１は、わりかん要求情報を受信すると、このわりかん専用の一時アカウント（「システムアカウント」と称する。）を作成する。そして、サーバ１０の制御部１１は、送金依頼情報の受信に基づく送金処理において、送金先をマスターのアカウントではなくシステムアカウントとするようにしてよい。
そして、サーバ１０の制御部１１は、返金額算出処理が実行されると、システムアカウントから各わりかんメンバーのアカウントに対する返金処理を実行し、その後、システムアカウントの電子マネー残高をマスターのアカウントに送金するようにしてもよい。

【0486】

図７－７左側には、本変形例において端末２０Ａの表示部２４に表示されるお知らせ画面の一例を示している。画面の遷移の一例を示す図である。図７－７左側の表示画面については、前述した図７－５左側と同様である部分についての説明を省略する。

【0487】

この例では、お知らせ情報ＮＴ２６が表示されている。
お知らせ情報ＮＴ２６には、わりかん総額（「１２，０００円」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、わりかん均等額より多い支払い金額（「１０，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、精算後の支払い金額（「１，０００円」）を支払うこととに関する情報が含まれる。

【0488】

このとき、ユーザＢ．Ｂが幹事であるユーザＡ．Ａに対して送金した支払い金額「１０，０００円」はシステムアカウントに送金され、全額「１０，０００円」が、システムアカウントから幹事であるユーザＡ．Ａに送金されている。一方で、ユーザＤ．Ｄが幹事であるユーザＡ．Ａに対して送金したわりかん均等額「４，０００円」はシステムアカウントに送金され、このうち「１，０００円」が、システムアカウントから幹事であるユーザＡ．Ａに送金されている。

【0489】

限定ではなく例として、支払いアプリケーションによってわりかんリクエストが完了されると、限定ではなく例として、システムアカウントから、返金対象であるユーザＤ．Ｄの端末２０Ｄに対して、返金に関するお知らせ情報が送信される。

【0490】

図７－７中央には、この場合における端末２０Ｄのお知らせ画面の一例を示している。図７－７中央の表示画面については、前述した図７－５右側と同様である部分についての説明を省略する。

【0491】

この例では、均等額送金依頼情報ＳＲ１の下に、お知らせ情報ＮＴ２６～ＮＴ２７が上から順に表示されている。
お知らせ情報ＮＴ２６には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａへの支払い金額（「４，０００円」）を、システムアカウントに対して、送金したことに関する情報が含まれる。
また、お知らせ情報ＮＴ２７には、システムアカウントが、ユーザＤ．Ｄに対して、返金金額（「３，０００円」）を返金することに関する情報が含まれる。

【0492】

限定ではなく例として、支払いアプリケーションによってわりかんリクエストが完了されると、限定ではなく例として、サーバ１０から、ユーザＢ．Ｂの端末２０Ｂに対して、わりかんリクエストの精算に関するお知らせ情報が送信される。

【0493】

図７－７右側には、この場合における端末２０Ｂのお知らせ画面の一例を示している。図７－７右側の表示画面については、前述した図７－７中央と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＢ．Ｂの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0494】

この例では、均等額送金依頼情報ＳＲ１の下に、お知らせ情報ＮＴ２８～ＮＴ２９が上から順に表示されている。
お知らせ情報ＮＴ２８には、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａへの支払い金額（「１０，０００円」）を、システムアカウントに対して、送金したことに関する情報が含まれる。
また、お知らせ情報ＮＴ２９には、わりかんリクエストが完了したことに関する情報が含まれる。

【0495】

本変形例は、サーバ１０は、複数のわりかんメンバーの各々から送信された送金依頼情報によって特定される支払い金額（限定ではなく、第２金額情報の一例）の少なくとも一部の金額を確保する処理（限定ではなく、第２処理の一例）を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２金額情報の少なくとも一部の金額を確保することができるので、返金する場合に残高が不足してしまうことを防止できる。

【0496】

また、この場合、金額を確保する処理（第２処理）は、複数のわりかんメンバーの各々から送信された送金依頼情報によって特定される支払い金額の情報と、均等額との差額を確保する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２金額情報と第１金額情報との差額を確保することによって、この支払いに関する金額を確保できるとともに、返金する場合に残高が不足してしまうことを防止できる。

【0497】

＜第７変形例（２）＞
上記の実施例では、返金額算出処理において、第１種および第２種のメンバー種別に基づいて自動的に返金額が算出されることとしたが、これに限定されない。
限定ではなく例として、マスターの端末２０において、各メンバーへの返金額が指定できるようにしてもよい。

【0498】

図７－８～図７－９は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。図７－８左側の表示画面については、前述した図７－７左側と同様である部分についての説明を省略する。

【0499】

この例では、お知らせ情報ＮＴ２６に、幹事であるユーザＡ．Ａが受取金額を手動で設定するための「受取金額設定」ボタンが含まれている。

【0500】

限定ではなく例として、お知らせ情報ＮＴ２６の「受取金額設定」ボタンがユーザによってタップされると、限定ではなく例として、図７－８右側の受取金額設定画面に表示が遷移する。

【0501】

この受取金額設定画面では、限定ではなく例として、わりかんメンバーから送金された受取金額と、その受取金額を設定するための「変更」ボタンと、余剰金額に関する情報（余剰金額が「６，０００円」であり、余剰金額を「０円」にする必要があることを示す情報）とが表示されるように構成されている。

【0502】

限定ではなく例として、ユーザが「変更」ボタンをタップすると、限定ではなく例として、図７－９左側の受取金額設定画面に表示が遷移する。図７－９左側の表示画面については、前述した図７－８右側と同様である部分についての説明を省略する。

【0503】

この例では、受取金額設定画面にテンキー入力領域などが表示されるなどして、ユーザＢ．Ｂの受取金額を「１０，０００円」から「９，０００円」に変更し、ユーザＣ．Ｃの受取金額を「４，０００円」から「２，０００円」に変更し、ユーザＡ．Ａの受取金額を「４，０００円」から「１，０００円」に変更しているものとする。
このとき、余剰金額に関する情報として、余剰金額が「０円」であり、精算可能であることを示す情報が表示されている。

【0504】

限定ではなく例として、受取金額設定画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、サーバ１０から、ユーザＡ．Ａの端末２０Ａに対して、返金に関するお知らせ情報が送信される。

【0505】

図７－９右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図７－９右側の表示画面については、前述した図７－８左側と同様である部分についての説明を省略する。

【0506】

この例では、お知らせ情報ＮＴ２６の下に、お知らせ情報ＮＴ２７～ＮＴ２８が表示されている。
お知らせ情報ＮＴ２７には、サーバ１０が、ユーザＢ．Ｂに対して、返金金額（「１，０００円」）を返金したことに関する情報が含まれる。
また、お知らせ情報ＮＴ２８には、サーバ１０が、ユーザＤ．Ｄに対して、返金金額（「２，０００円」）を返金したことに関する情報が含まれる。

【0507】

本変形例は、返金する処理（第１処理）は、マスター（限定ではなく、第１端末のユーザの一例）によって、複数のわりかんメンバーの各々に対して設定された金額が返金される処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、返金する金額を任意に設定することができるので、ユーザに応じて返金する金額を異ならせることができる。

【0508】

＜第７変形例（３）＞
限定ではなく例として、送金額記録処理に伴い送金が実行された後、返金額算出処理が実行される前に、マスターの端末２０において電子マネー残高が使用された場合、返金額算出処理に基づく返金処理がマスターのアカウントの電子マネー残高不足により実行不能となる可能性が生じる。本変形例は、この場合における処理の一例である。

【0509】

図７－１０は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。

【0510】

ここでは、幹事であるユーザＡ．Ａの電子マネー残高が不足していることによって、他のユーザ（１００人）に返金することができない場合の表示画面例を説明する。

【0511】

図７－１０左側の表示画面については、前述した図７－７左側と同様である部分についての説明を省略する。

【0512】

この例では、お知らせ情報ＮＴ２９～ＮＴ３０が表示されている。
お知らせ情報ＮＴ２９には、わりかん総額（「１０１，０００円」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、わりかん均等額より多い支払い金額（「１０，０００円」）を支払うことと、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、わりかん均等額（「１，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、わりかん均等額（「１，０００円」）を支払うこと等に関する情報が含まれる。他のユーザについても、幹事であるユーザＡ．Ａに対して、わりかん均等額（「１，０００円」）を支払うことが表示されている。

【0513】

限定ではなく例として、幹事であるユーザＡ．Ａが、わりかん均等額を支払う最後のユーザから送金を受け取る前に、他の支払い等で電子マネー残高を使ってしまった場合を考える。この画面では、わりかんメンバー１０１人のうち、幹事であるユーザを除く９９人から支払い金額を受け取り、その後、電子マネー残高が「０円」になるまで使ってしまったとする。すると、最後のわりかんメンバーから、限定ではなく例として、わりかん均等額（この例では「１，０００円」）を受け取った場合、返金額算出処理において算出された返金額を返金対象のメンバーに返金する残高（この例では、「９０円」×「９９人」＝「８，９１０円」）が残っていない場合が生じる。
このため、お知らせ情報ＮＴ３０には、わりかんリクエストの精算が行えなかったことに関する情報が含まれる。

【0514】

限定ではなく例として、お知らせ情報ＮＴ３０の「チャージ」ボタンがユーザによってタップされると、限定ではなく例として、支払いアプリケーションの電子マネー残高をチャージするためのチャージ画面に表示が遷移し（不図示）、限定ではなく例として、このチャージ画面において、電子マネー残高を「１１，０００円」チャージすると（不図示）、返金額算出処理において算出された返金額を返金対象のメンバーに返金する残高が確保される。
そして、サーバ１０の制御部１１は、残高が確保されると、限定ではなく例として、自動的に返金処理を実行する。

【0515】

図７－１０右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図７－１０右側の表示画面については、前述した図７－１０左側と同様である部分についての説明を省略する。

【0516】

この例では、お知らせ情報ＮＴ３０の下に、お知らせ情報ＮＴ３１～ＮＴ３３が表示されている。
お知らせ情報ＮＴ３１には、ユーザＡ．Ａの電子マネー残高に「１１，０００円」がチャージされたことに関する情報が含まれる。
また、お知らせ情報ＮＴ３２には、ユーザＡ．Ａが、ユーザＣ．Ｃに対して、返金金額（「９０円」）を返金したことに関する情報が含まれる。
また、お知らせ情報ＮＴ３３には、ユーザＡ．Ａが、ユーザＤ．Ｄに対して、返金金額（「９０円」）を返金したことに関する情報が含まれる。

【0517】

本変形例は、返金する処理（限定ではなく、第１処理の一例）は、複数のわりかんメンバーの各々から送信された送金依頼情報によって特定される支払い金額の情報（限定ではなく、第２金額情報の一例）と、均等額の情報（限定ではなく、第１金額情報の一例）との差額の金額がマスターの端末２０の残高にない場合、マスターの端末２０に通知を行う処理を含む構成を示している。
このような構成により得られる変形例の効果の一例として、複数のユーザの各々から送信された第２金額情報と第１金額情報との差額の金額が第１端末の残高にない場合、第１端末に通知をして、そのことを知らせることができる。

【0518】

また、この場合、返金する処理（限定ではなく、第１処理の一例）は、マスターの端末２０（限定ではなく、第１端末の一例）による、マスターの端末２０の残高への入金処理により、支払い金額の情報（限定ではなく、第２金額情報の一例）と、均等額の情報（限定ではなく、第１金額情報の一例）との差額以上の金額がマスターの端末２０の残高にある場合、返金する処理を行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末において返金するための残高が確保されている場合に、適確に返金することができる。

【0519】

＜第８実施例＞
第８実施例は、（２）の手法に関し、わりかんをするメンバーを２以上のグループに分け、それぞれのグループに対してわりかんを行うことに関する実施例である。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0520】

＜データ構成＞
図８－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかんリクエスト管理データベース１５７Ｆのデータ構成の一例を示す図である。
このわりかんリクエスト管理データベース１５７Ｆは、図３－６のわりかんリクエスト管理データベース１５７Ｄとほぼ同様のデータ構成であるが、その一部が異なっている。

【0521】

具体的には、各々のわりかん管理データのわりかんグループ管理データには、グループＩＤと、グループ内わりかん総額とに加えて、限定ではなく例として、グループ内わりかん均等額が記憶される。

【0522】

グループ内わりかん均等額は、このグループＩＤによって識別されるグループ内でのわりかん均等額であり、限定ではなく例として、「グループ内わりかん総額÷グループのメンバー数」によって算出される。

【0523】

また、わりかんメンバー管理データにおいて、メンバー種別には、マスター（幹事）以外のわりかんメンバーについて、送金を行う前であるためデータとして「－（なし）」が記憶されている。。

【0524】

＜表示画面＞
図８－２～図８－４は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0525】

ここでは、わりかんに参加する６名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１Ｇ＝ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ
・第２Ｇ＝ユーザＥ．Ｅ、ユーザＦ．Ｆ
とする場合の表示画面例を説明する。

【0526】

図８－２左側～右側の表示画面については、前述した図３－７左側～右側と同様の部分についての説明を省略する。

【0527】

図８－２右側の表示画面では、「多く払えるグループ」タブと、「多く払わないグループ」タブとで区別されていない。

【0528】

限定ではなく例として、わりかんグループ設定画面最下部の「グループ別金額設定」ボタンがユーザによってタップされると、端末２０Ａでは、図８－３左側のような画面が表示される。
図８－３左側～右側の表示画面については、前述した図３－８左側～右側と同様の部分についての説明を省略する。

【0529】

図８－３左側の表示画面では、グループ別わりかん総額設定領域ＳＡＲ２には、第１わりかんグループのグループ内わりかん総額として「３０，０００円」が、第２わりかんグループのグループ内わりかん総額として「１０，０００円」が、設定され表示されている。

【0530】

図８－３中央の表示画面では、お知らせ情報ＮＴ３４が表示されている。
お知らせ情報ＮＴ３４には、第１Ｇのグループ内わりかん総額が「３０，０００円」であることと、わりかん人数が「４人」であることと、第１ＧユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、グループ内わりかん均等額（「７，５００円」）を支払うこととに関する送金リクエストが含まれる。

【0531】

図８－３右側の表示画面では、お知らせ情報ＮＴ３５が表示されている。
お知らせ情報ＮＴ３５には、第２Ｇのグループ内わりかん総額が「１０，０００円」であることと、わりかん人数が「２人」であることと、第２ＧユーザであるユーザＥ．Ｅが、幹事であるユーザＡ．Ａに対して、グループ内わりかん均等額（「５，０００円」）を支払うこととに関する送金リクエストが含まれる。

【0532】

限定ではなく例として、第１Ｇのメンバーが幹事であるユーザＡ．Ａに対して支払い予定額を送金し（不図示）、幹事であるユーザＡ．Ａが第１Ｇのメンバーのうち第２種メンバー（本例では、ユーザＤ．Ｄ）に対して返金すると（不図示）、限定ではなく例として、サーバ１０から、ユーザＡ．Ａの端末２０Ａに対して、返金に関するお知らせ情報が送信される。

【0533】

図８－４左側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図８－４左側の表示画面については、前述した図７－１０左側と同様である部分についての説明を省略する。

【0534】

この例では、お知らせ情報ＮＴ３６～ＮＴ３７が表示されている。
お知らせ情報ＮＴ３６には、グループ内わりかん総額（「３０，０００円」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、第１Ｇのグループ内わりかん均等額よりも多い支払い金額（「９，０００円」）を支払うことと、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、第１Ｇのグループ内わりかん均等額よりも多い支払い金額（「８，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、第１Ｇのグループ内わりかん均等額（「７，５００円」）を支払うこと等に関する情報が含まれる。
また、お知らせ情報ＮＴ３７には、ユーザＡ．Ａが、第２種メンバーとなったユーザＤ．Ｄに対して、返金金額（「１，０００円」）を返金したことに関する情報が含まれる。

【0535】

限定ではなく例として、第２Ｇのメンバーが幹事であるユーザＡ．Ａに対して支払い予定額を送金し（不図示）、幹事であるユーザＡ．Ａが第２Ｇのメンバーのうち第２種メンバー（本例では、ユーザＦ．Ｆ）に対して返金すると（不図示）、限定ではなく例として、サーバ１０から、ユーザＡ．Ａの端末２０Ａに対して、返金に関するお知らせ情報が送信される。

【0536】

図８－４右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図８－４右側の表示画面については、前述した図７－１０左側と同様である部分についての説明を省略する。

【0537】

この例では、お知らせ情報ＮＴ３８～ＮＴ３９が表示されている。
お知らせ情報ＮＴ３８には、グループ内わりかん総額（「１０，０００円」）と、ユーザＥ．Ｅが、幹事であるユーザＡ．Ａに対して、第２Ｇのグループ内わりかん均等額よりも多い支払い金額（「５，５００円」）を支払うことと、ユーザＦ．Ｆが、幹事であるユーザＡ．Ａに対して、第１Ｇのグループ内わりかん均等額（「５，０００円」）を支払うこと等に関する情報が含まれる。
また、お知らせ情報ＮＴ３９には、ユーザＡ．Ａが、第２種メンバーとなったユーザＦ．Ｆに対して、返金金額（「５００円」）を返金したことに関する情報が含まれる。

【0538】

限定ではなく例として、本実施例では、グループごとに第１種と第２種とのメンバー種別判定が実行され、グループ内でそれぞれ返金額算出処理が実行される。

【0539】

＜第８実施例の効果＞
本実施例は、サーバ１０は、複数のわりかんメンバーを、第１わりかんグループと第２わりかんグループとに指定する情報をマスターの端末２０（限定ではなく、第１端末の一例）から通信Ｉ／Ｆ１４によって受信する。この場合、複数のわりかんメンバーに対して送信された均等額の情報（限定ではなく、第１金額情報の一例）は、第１わりかんグループに送信される均等額の情報（限定ではなく、第３金額情報の一例）と、第２わりかんグループに送信される均等額の情報（限定ではなく、第４金額情報の一例）とを含む構成を示している。
このような構成により得られる実施例の効果の一例として、複数のユーザを複数のグループに分けることができるとともに、グループに応じて異なる金額情報を設定することができる。

【0540】

また、この場合、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）は、第１わりかんグループのわりかんメンバーの各々から送信された支払い金額の情報（限定ではなく、第２金額情報の一例）と、第１わりかんグループに送信される均等額の情報（限定ではなく、第３金額情報の一例）とに基づいて、第１わりかんグループに含まれる少なくとも一人のわりかんメンバーに対して減金され、第２わりかんグループのわりかんメンバーの各々から送信された支払い金額の情報（限定ではなく、第２金額情報の一例）と、第２わりかんグループに送信される均等額の情報（限定ではなく、第４金額情報の一例）とに基づいて、第２わりかんグループに含まれる少なくとも一人のわりかんメンバーに対して返金される処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、各グループのユーザの各々に対して、適切な金額を返金することができる。

【0541】

＜第８変形例（１）＞
上記の実施例では、２つのグループにおいて、それぞれ返金を行うこととしたが、これに限定されない。限定ではなく例として、グループ内わりかん均等額を超える送金により発生した余剰金を、特定のグループに対するわりかんに回して返金するようにしてもよい。

【0542】

図８－５は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。図８－５左側の表示画面については、前述した図８－４左側と同様である部分についての説明を省略する。
この例では、お知らせ情報ＮＴ３６が表示されている一方で、お知らせ情報ＮＴ３７が表示されていない。

【0543】

限定ではなく例として、第１Ｇのグループ内わりかん総額が「３０，０００円」であり、第１Ｇメンバーのうち、ユーザＢ．Ｂの支払い金額が「９，０００円」、ユーザＤ．Ｄの支払い金額が「８，０００円」、ユーザＣ．Ｃの支払い金額が「７，５００円」、ユーザＡ．Ａの支払い金額（負担額）が「７，５００円」であるので、第１Ｇの支払い金額の余剰金は、（「９，０００円」＋「８，０００円」＋「７，５００円」＋「７，５００円」）－「３０，０００円」＝「２，０００円」となる。

【0544】

限定ではなく例として、第２Ｇのメンバーが幹事であるユーザＡ．Ａに対して支払い金額を送金し（不図示）、幹事であるユーザＡ．Ａが第２Ｇのメンバーのうち第２種メンバーとなったユーザ（本例では、ユーザＦ．Ｆ）に対して、前述した余剰金を加味した金額を返金すると（不図示）、限定ではなく例として、サーバ１０から、ユーザＡ．Ａの端末２０Ａに対して、返金に関するお知らせ情報が送信される。

【0545】

図８－５右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図８－５右側の表示画面については、前述した図８－４右側と同様である部分についての説明を省略する。

【0546】

この例では、お知らせ情報ＮＴ３８の下に、お知らせ情報ＮＴ４０が表示されている。
お知らせ情報ＮＴ４０には、ユーザＡ．Ａが、ユーザＦ．Ｆに対して、返金金額（「１０，０００円」－「２，０００円」－「５，５００円」＝「２，５００円」）を返金したことに関する情報が含まれる。

【0547】

本変形例は、第１わりかんグループに送信される均等額の情報（限定ではなく、第３金額情報の一例）は、第２わりかんグループに送信される均等額の情報（限定ではなく、第４金額情報の一例）と異なる金額の情報を含む。そして、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）は、第２わりかんグループのわりかんメンバーに対して返金する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、グループに応じて異なる金額の金額情報を設定することができ、特定の金額情報が送信されたグループに対して返金することができる。

【0548】

＜第９実施例＞
第９実施例は、（２）の手法に関し、逐次送金処理を実行せず、全てのわりかんメンバーの送金予定額が決定し、精算が行われた後、まとめて送金を行うことに関する実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0549】

＜表示画面＞
図９－１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0550】

ここでは、わりかんに参加する３名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ
・第２種＝ユーザＤ．Ｄ
となる場合の表示画面例を説明する。

【0551】

図９－１左側の表示画面では、前述した図７－３右側とは異なり、ユーザＢ．Ｂが送金予定額（支払い予定額）として「１０，０００円」を指定（決定）したことが表示されている。

【0552】

図９－１中央の表示画面では、前述した図７－４右側とは異なり、ユーザＤ．Ｄが送金予定額（支払い予定額）として「４，０００円」を指定（決定）したことが表示されている。

【0553】

限定ではなく例として、ユーザＢ．Ｂ、ユーザＤ．Ｄによって支払い予定額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、支払い予定額や、この支払い予定額に基づく返金金額を含む精算結果に関するお知らせ情報が送信される。

【0554】

図９－１右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。図９－１右側の表示画面については、前述した図７－５左側と同様である部分についての説明を省略する。

【0555】

この例では、お知らせ情報ＮＴ４１～ＮＴ４４が表示されている。
お知らせ情報ＮＴ４１には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、送金予定額を「４，０００円」に決定したことに関する情報を含む。
また、お知らせ情報ＮＴ４２には、わりかん総額（「１２，０００円」）と、わりかん人数（「３人」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、わりかん均等額よりも多い支払い予定額（「１０，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、わりかん均等額を支払い予定額としたことが含まれる。また、ユーザＤ．Ｄが第２種メンバーとなったことに基づいて、支払い金額が「４，０００円」から「１，０００円」に変更され、変更後の金額を支払うこととに関する情報が含まれる。
また、お知らせ情報ＮＴ４３には、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、送金予定額と同額の支払い金額「１０，０００円」を送金したことに関する情報を含む。
また、お知らせ情報ＮＴ４４には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、変更後の支払い金額「１，０００円」を送金したことに関する情報を含む。

【0556】

＜処理＞
図９－２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
Ｂ４１０の後、端末２０Ｂの制御部２１は、送金予定金額入力処理を行う（Ｂ５１０）。具体的には、入出力部２３を介した送金予定金額のユーザ入力を受け付ける。
そして、端末２０Ｂの制御部２１は、受け付けた送金予定金額の情報を含む送金予定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ５２０）。

【0557】

同様に、端末２０Ｄの制御部２１は、Ｄ４１０の後、送金予定金額入力処理（Ｄ５１０）と、送金予定情報の送信（Ｄ５２０）とを行う。

【0558】

Ｓ４１０の後、サーバ１０の制御部１１は、送金予定額記録処理を実行する（Ｓ５１０）。

【0559】

Ｓ４１０の後、通信Ｉ／Ｆ１４によってわりかんメンバーの端末２０から送金依頼情報を受信すると、サーバ１０の制御部１１は、送金予定額記録処理を行う（Ｓ５１０）。送金予定額記録処理では、サーバ１０の制御部１１は、送金額記録処理とは異なり、送金予定情報に基づく送金処理は実行せず、送金予定金額をわりかんメンバー管理データの支払い金額に記憶させる。

【0560】

そして、サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金予定情報を受信したか否かを判定し（Ｓ５２０）、受信しなかったと判定したならば（Ｓ５２０：ＮＯ）、残りのわりかんメンバーからの送金予定情報の受信を待機する。

【0561】

マスターを除くわりかんメンバー全員から送金予定情報を受信したと判定したならば（Ｓ５３０：ＹＥＳ）、サーバ１０の制御部１１は、送金額精算処理を行う（Ｓ５３０）。具体的には、わりかんリクエスト管理データのうち、わりかん総額と、わりかん均等額と、わりかんメンバー管理データに記憶された各々の支払い金額とに基づき、どのメンバーからいくらマスターのアカウントに対して送金するかの送金額を算出する。そして、サーバ１０の制御部１１は、送金額を算出すると、各わりかんメンバーのアカウントからマスターのアカウントに対する送金処理を実行する。

【0562】

なお、Ｓ５３０のステップで、送金額を算出した場合、サーバ１０の制御部１１が、送金が生ずることに関する情報（送金する旨や送金額の情報）をわりかんメンバーの端末２０に通知するようにしてもよい。また、送金処理を行った後、送金したことに関する情報（送金した旨や送金額の情報）を送金したわりかんメンバーの端末２０に通知するようにしてもよい。

【0563】

＜第９実施例の効果＞
本実施例は、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）は、複数のわりかんメンバーの各々から送信された支払い金額の情報（限定ではなく、第２金額情報の一例）と、均等額の情報（限定ではなく、第１金額情報の一例）とに基づいて、複数のわりかんメンバーのうちの少なくとも一人が支払う金額を変更する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザに応じて適切な金額を支払うように設定できる。

【0564】

また、この場合、複数のわりかんメンバーに対する処理（第１処理）は、複数のわりかんメンバーのうち、均等額を入力したわりかんメンバーが支払う金額を変更する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザが支払う金額を変更できるので、適切な金額を設定できる。

【0565】

＜第９変形例（１）＞
上記の実施例では、（２）の手法に関し、メンバー種別がわりかんメンバーからの支払い結果に基づいて動的に設定されることとしたが、これに限定されない。限定ではなく例として、マスターの端末２０によってメンバー種別が指定できるようにしてもよい。

【0566】

図９－３～図９－４は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0567】

図９－３左側の表示画面については、前述した図７－２右側と同様である部分についての説明を省略する。

【0568】

この例では、各ユーザ（ユーザアイコン及びユーザ名）の右方に、わりかんメンバーのメンバー種別（「多く払える」または「多く払わない」）を個別に設定するためのメンバー種別選択ボタンが表示されている。
このメンバー種別選択ボタンは、限定ではなく例として、ユーザがタップするごとに、メンバー種別を第１種に設定するための「多く払える」の文字を含む第１種態様と、メンバー種別を第２種に設定するための「多く払わない」の文字を含む第２種態様とで切り替わり表示される。

【0569】

限定ではなく例として、ユーザＡ．Ａに対応するメンバー種別選択ボタンが第２種態様となるようにユーザによってタップされ、限定ではなく例として、ユーザＤ．Ｄに対応するメンバー種別選択ボタンが第２種態様となるようにユーザによってタップされ、限定ではなく例として、画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、サーバ１０から、ユーザＤ．Ｄの端末２０Ｄに対して、支払い金額に関するお知らせ情報が送信される。

【0570】

この場合、端末２０Ｄで表示される不図示のお知らせ画面における「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図９－３中央に示すような送金画面が表示される。

【0571】

この例では、送金金額指定領域ＲＡＲ１には、送金リクエストに基づいて、均等額「４，０００円」が指定され表示されている。また、ユーザＤ．Ｄのメンバー種別が第２種に指定されたことに基づいて、送金金額指定領域ＲＡＲ１の下には、送金額増額ボタンＡＩＢ１が表示されない。

【0572】

限定ではなく例として、画面最下部の「決定」ボタンがユーザによってタップされると、図９－３右側の送金結果画面に表示が遷移する。

【0573】

この送金結果画面では、ユーザＤ．ＤがユーザＡ．Ａにわりかん均等額「４，０００円」を送金したことが表示されている。

【0574】

また、限定ではなく例として、ユーザＡ．Ａに対応するメンバー種別選択ボタンが第２種態様となるようにユーザによってタップされ、限定ではなく例として、ユーザＤ．Ｄに対応するメンバー種別選択ボタンが第２種態様となるようにユーザによってタップされ、限定ではなく例として、画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、サーバ１０から、ユーザＢ．Ｂの端末２０Ｂに対して、支払い金額に関するお知らせ情報が送信される。

【0575】

この場合、これに基づいて端末２０Ｂで表示される不図示のお知らせ画面における「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図９－４左側に示すような送金画面が表示される。

【0576】

図９－４左側の送金画面では、ユーザＢ．Ｂによって送金金額指定領域ＲＡＲ１に「１０，０００円」が入力された状態が示されている。この状態で、送金金額指定領域ＲＡＲ１下部の「確定」ボタンがタップされた後に、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図９－４中央の送金結果画面に表示が遷移する。

【0577】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに送金リクエストされた金額より増額した金額「１０，０００円」を送金したことが表示されている。

【0578】

限定ではなく例として、ユーザＢ．Ｂ、ユーザＤ．Ｄによって支払い予定額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、支払い予定額や、この支払い予定額に基づく返金金額を含む精算結果に関するお知らせ情報が送信される。

【0579】

図９－４右側には、この場合における端末２０Ａのお知らせ画面の一例を示している。
この例では、４つのお知らせ情報が表示されている。
最上部のお知らせ情報ＮＴ４５には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、送金予定額を「４，０００円」に決定したことに関する情報を含む。
また、その下のお知らせ情報ＮＴ４６には、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、送金予定額と同額の支払い金額「１０，０００円」を送金したことに関する情報を含む。ここでは、ユーザＢ．Ｂがわりかん均等額よりも多い金額を送金予定額に指定したため、ユーザＢ．Ｂへの返金は生じなくなる。そこで、送金が実行される。
その下のお知らせ情報ＮＴ４７には、わりかん総額（「１２，０００円」）と、わりかん人数（「３人」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、わりかん均等額よりも多い支払い予定額（「１０，０００円」）を支払ったことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、わりかん均等額を支払い予定額したことに基づいて、支払い金額が「１，０００円」に変更され、変更後の金額を支払うこととに関する情報が含まれる。
また、最下部のお知らせ情報ＮＴ４８には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、変更後の支払い金額「１，０００円」を送金したことに関する情報を含む。

【0580】

本変形例は、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）は、複数のわりかんメンバーの各々から送信された支払い金額の情報（限定ではなく、第２金額情報の一例）と、均等額の情報（限定ではなく、第１金額情報の一例）とに基づいて、複数のわりかんメンバーのうちの少なくとも一人が支払う金額を変更する処理を含む構成を示している。
このような構成により得られる実施例の効果の一例として、ユーザに応じて適切な金額を支払うように設定できる。

【0581】

また、この場合、複数のわりかんメンバーに対する処理（限定ではなく、第１処理の一例）は、複数のわりかんメンバーのうち、均等額を入力したわりかんメンバーが支払う金額を変更する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、ユーザが支払う金額を変更できるので、適切な金額を設定できる。

【0582】

また、この場合、複数のわりかんメンバーに対する処理（第１処理）は、複数のわりかんメンバーの各々から送信された支払い金額の情報（限定ではなく、第２金額情報の一例）と、均等額の情報（限定ではなく、第１金額情報の一例）と、マスターの設定（限定ではなく、第１端末のユーザの設定の一例）とに基づいて、支払う金額を変更する処理を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末のユーザが任意に支払う金額を変更することができ、支払う金額としてより一層適切な金額を設定できる。

【0583】

＜第１０実施例＞
第１０実施例は、（２）の手法を、メッセージングアプリケーションを用いて実現することに関する実施例である。限定ではなく例として、わりかんに関する情報をメッセージングアプリケーションのトークルームに送信・表示することや、メッセージングアプリケーションと支払いアプリケーションとを連携させてわりかんを行う手法等に関する。
第１０実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0584】

＜表示画面＞
図１０－１～図１０－２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
となる場合の表示画面例を説明する。

【0585】

図１０－１左側は、前述した図６－１左側と同様のメッセージングアプリケーショントークルーム画面である。この画面において、限定ではなく例として、わりかん機能ボタンＭＢＴ１がユーザによってタップされると、限定ではなく例として、図１０－１中央のわりかんグループ設定画面に表示が遷移する。

【0586】

このわりかんグループ設定画面では、前述した図６－１右側のわりかんグループ設定画面とは異なり、第１種と第２種とのメンバー種別を設定する項目が存在しない。

【0587】

限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、開発グループ内の各端末２０では、図１０－１右側に示すようなグループトークルーム画面が表示される。ここでは、限定ではなく例として、端末２０Ｄにおけるグループトークルーム画面の一例を示している。

【0588】

この例では、コンテンツ表示領域には、コンテンツ情報ＣＴ１０などが表示されている。
コンテンツ情報ＣＴ１０は、送信元が幹事のユーザＡ．Ａであるコンテンツ情報であって、わりかん総額「２０，０００円」、わりかん人数「４人」、現在の均等額（わりかん均等額）「５，０００円」であることに関する情報が含まれる。
すなわち、コンテンツ情報ＣＴ１０を参照することで、開発グループ内の各メンバーがわりかん開始時にわりかん均等額等を把握することができる。

【0589】

限定ではなく例として、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い金額「８，０００円」を送金すると、限定ではなく例として、図１０－２左側のトークルーム画面に表示が遷移する。

【0590】

このトークルーム画面では、コンテンツ表示領域のコンテンツ情報ＣＴ１０の下には、コンテンツ情報ＣＴ１１が表示されている。
コンテンツ情報ＣＴ１１は、限定ではなく例として、送信元がユーザＣ．Ｃであるコンテンツ情報であって、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い金額「８，０００円」を支払ったことに関する情報と、紙吹雪をまき盛り上がるクマのイラストと、リアクションを行うための「リアクション」ボタンとが含まれる。
限定ではなく例として、支払い金額がわりかん均等額より多いこと、または盛り上がるクマのイラストを確認することで、ユーザＣ．Ｃが第１種ユーザとなったことがわかる。

【0591】

次いで、コンテンツ情報ＣＴ１０の「支払う」ボタンがユーザによってタップされ、支払いアプリケーションにおいて、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、均等額である「５，０００円」を送金すると、限定ではなく例として、図１０－２中央のトークルーム画面に表示が遷移する。

【0592】

この例では、コンテンツ表示領域のコンテンツ情報ＣＴ１１の下には、コンテンツ情報ＣＴ１２が表示されている。
コンテンツ情報ＣＴ１２は、限定ではなく例として、送信元がユーザＤ．Ｄであるコンテンツ情報であって、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、支払い金額「５，０００円」を支払ったことに関する情報が含まれる。
限定ではなく例として、支払い金額がわりかん均等額であること、または挨拶するクマのイラストを確認することで、ユーザＤ．Ｄが第２種ユーザとなったことがわかる。

【0593】

その後、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額「１０，０００円」を送金すると、限定ではなく例として、図１０－２右側のトークルーム画面に表示が遷移する。

【0594】

この例では、コンテンツ表示領域のコンテンツ情報ＣＴ１２の下には、コンテンツ情報ＣＴ１３～ＮＴ１５が表示されている。
コンテンツ情報ＣＴ１３は、限定ではなく例として、送信元がユーザＢ．Ｂであるコンテンツ情報であって、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額「１０，０００円」を支払ったことに関する情報と、紙吹雪をまき盛り上がるクマのイラストと、リアクションを行うための「リアクション」ボタンとが含まれる。
限定ではなく例として、支払い金額がわりかん均等額より多いこと、または盛り上がるクマのイラストを確認することで、ユーザＢ．Ｂが第１種ユーザとなったことがわかる。

【0595】

また、コンテンツ情報ＣＴ１４は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、わりかんリクエストが完了したことに関する情報が含まれる。
また、コンテンツ情報ＣＴ１５は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、第２種ユーザとなったユーザＤ．Ｄに対して、返金金額「４，０００円」を返金したことに関する情報が含まれる。

【0596】

なお、返金したことに関する情報（この例では、コンテンツ情報ＣＴ１５）は、グループトークルーム内に表示されず、返金対象となったユーザ（この例では、ユーザＤ．Ｄ）と、Ｐａｙｍｅｎｔ ＡｐｐとのＯＡトークルーム内に表示されるようにしてもよい。

【0597】

＜第１０実施例の効果＞
本実施例は、均等額の情報（限定ではなく、第１金額情報の一例）は、マスター（限定ではなく、第１端末のユーザの一例）と、複数のわりかんメンバー（限定ではなく、複数のユーザの一例）とを含むチャットルームに表示される構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末のユーザや複数のユーザに対して効果的に第１金額情報を認識させることができる。

【0598】

また、この場合、返金に関する情報が、上記のチャットルームに表示されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、返金に関する情報を、第１端末のユーザや複数のユーザに対して効果的に認識させることができる。

【0599】

＜第１１実施例＞
第１１実施例は、前述した「（３）リアルタイム処理を用いる手法」に関する基本的な実施例である。
第１１実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0600】

（３）の手法では、わりかんメンバーの支払い状況（支払い金額決定状況）に応じて、均等額が変化するようにすることができる。以下では、（３）の手法で用いる均等額を「リアルタイム均等額」と称する。

【0601】

ここで、リアルタイム均等額は、限定ではなく例として、以下の式（３）を用いて算出することができる。
リアルタイム均等額＝（わりかん総額－その時点におけるメンバーの支払い金額の総和）÷（幹事を含むわりかんメンバーの人数－その時点における支払い済みメンバーの人数） ・・・（３）

【0602】

＜データ構成＞
図１１－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかんリクエスト管理データベース１５７Ｇのデータ構成の一例を示す図である。
このわりかんリクエスト管理データベース１５７Ｇは、図７－１のわりかんリクエスト管理データベース１５７Ｅとほぼ同様のデータ構成であるが、その一部が異なっている。

【0603】

具体的には、各々のわりかんリクエスト管理データには、限定ではなく例として、わりかん均等額に代えて、リアルタイム均等額が記憶される。
わりかん均等額がわりかん開始時点から終了まで変化しない値であったのに対して、リアルタイム均等額は、わりかんメンバー管理データの更新に応じて再計算される値である。

【0604】

本実施例において、わりかんメンバー管理データにおけるメンバー種別は、幹事による指定によって設定されるのではなく、幹事を除きわりかんメンバーからの支払い結果に基づいて動的に設定される。
限定ではなく例として、支払い時点におけるリアルタイム均等額よりも大きい金額の支払い金額指定を行ったメンバーには「第１種」が設定され、支払い時点におけるリアルタイム均等額と等しい支払い金額指定を行ったメンバーには「第２種」が設定される。なお、「第２種」が設定されるメンバーは、支払い金額指定を行わず、「均等額を支払う」意思があることを示す情報を送信したメンバーとしてもよい。

【0605】

＜表示画面＞
図１１－２～図１１－５は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0606】

ここでは、わりかんに参加する３名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ
・第２種＝ユーザＤ．Ｄ
となる場合の表示画面例を説明する。

【0607】

図１１－２左側および右側の表示画面については、前述した図７－２左側および中央と同様であるので説明を省略する。

【0608】

限定ではなく例として、わりかん設定画面最下部の「選択」ボタンがユーザによってタップされた後（不図示）に、限定ではなく例として、わりかんグループ設定画面最下部の「決定」ボタンがユーザによってタップされると、端末２０Ａからサーバ１０に、わりかん設定画面への入力内容に基づくわりかん要求情報が送信される。
すると、限定ではなく例として、幹事の端末２０Ａ以外の各端末２０では、図１１－３左側に示すようなお知らせ画面が表示される。ここでは、限定ではなく例として、端末２０Ｂにおけるお知らせ画面の一例を示している。

【0609】

この例では、お知らせ情報ＮＴ５０が表示されている。
お知らせ情報ＮＴ５０には、わりかん総額（「１２，０００円」）と、わりかん人数（「３人」）と、リアルタイム均等額（現在の均等額）（「４，０００円」）とに関する情報が含まれる。

【0610】

限定ではなく例として、お知らせ情報ＮＴ５０の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１１－３中央の送金画面に表示が遷移する。

【0611】

この例では、送金金額指定領域ＲＡＲ１の下には、現在の均等額を支払うための「均等額を支払う」ボタンと、現在の均等額（「４，０００円」）とが表示されている。
送金金額指定領域ＲＡＲ１には、現在の均等額よりも増額した「８，０００円」が送金金額として指定されたことが表示されている。

【0612】

限定ではなく例として、送金金額が送金金額指定領域ＲＡＲ１に入力され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１１－３右側の送金結果画面に表示が遷移する。

【0613】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに送金リクエストされた金額より増額した金額「８，０００円」を送金予定額として決定したことが表示されている。

【0614】

限定ではなく例として、ユーザＢ．Ｂが幹事であるユーザＡ．Ａに対する支払い予定額（「８，０００円」）を決定すると、限定ではなく例として、端末２０Ｄでは、図１１－４左側に示すようなお知らせ画面が表示される。

【0615】

この例では、お知らせ情報ＮＴ５０～ＮＴ５１が上から順に表示されている。
お知らせ情報ＮＴ５１には、ユーザＢ．Ｂの支払い予定額の決定に基づいて、更新されたリアルタイム均等額（現在の均等額）（「２，０００円」）に関する情報が含まれる。

【0616】

限定ではなく例として、お知らせ情報ＮＴ５０またはＮＴ５１の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１１－４中央の送金画面に表示が遷移する。

【0617】

図１１－４中央の表示画面については、前述した図１１－３中央と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＤ．Ｄの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0618】

この例では、現在の均等額「２，０００円」が送金金額として指定されて表示されている。

【0619】

限定ではなく例として、「均等額を支払う」ボタンがユーザによってタップされ、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１１－４右側の送金結果画面に表示が遷移する。

【0620】

この送金結果画面では、ユーザＤ．ＤがユーザＡ．Ａに対する送金予定額としてリアルタイム均等額（この時点では、現在の均等額である「２，０００円」）を決定したことが表示されている。

【0621】

限定ではなく例として、ユーザＢ．Ｂ、ユーザＤ．Ｄによって支払い金額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、支払い予定金額などに関するお知らせ情報が送信される。

【0622】

図１１－５左側には、この場合における端末２０Ａのお知らせ画面の一例を示している。
この例では、お知らせ情報ＮＴ５２が表示されている。
お知らせ情報ＮＴ５２には、わりかん総額（「１２，０００円」）と、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い予定額（「８，０００円」）を支払うことと、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、最終的なリアルタイム均等額（「２，０００円」）を支払うことと、幹事であるユーザＡ．Ａが、最終的なリアルタイム均等額（「２，０００円」）を負担することとに関する情報が含まれる。

【0623】

限定ではなく例として、お知らせ情報ＮＴ５２の「受取」ボタンがユーザによってタップされると、限定ではなく例として、図１１－５右側の表示画面に表示が遷移する。

【0624】

この例では、お知らせ情報ＮＴ５２の下には、お知らせ情報ＮＴ５３～ＮＴ５４が表示されている。
お知らせ情報ＮＴ５３には、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い予定額（「８，０００円」）の送金が完了したことに関する情報が含まれる。
また、お知らせ情報ＮＴ５４には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、最終的なリアルタイム均等額（「２，０００円」）の送金が完了したことに関する情報が含まれる。

【0625】

＜処理＞
図１１－６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
このフローチャートでは、限定ではなく例として、端末２０Ｂのユーザが先に支払い金額を決定し、その後、端末２０Ｄのユーザが支払い金額を決定する例を示す。

【0626】

通信Ｉ／Ｆ１４によって端末２０Ａからわりかん要求情報を受信し、わりかんリクエスト管理データを更新した後、サーバ１０の制御部１１は、この時点でのリアルタイム均等額（最初のリアルタイム均等額はわりかん均等額となる。）以上の金額の送金を依頼する均等額以上送金依頼情報を、通信Ｉ／Ｆ１４によって各々のわりかんメンバーの端末２０（この図では、端末２０Ｂおよび端末２０Ｄ）に送信する（Ｓ４１０）。

【0627】

通信Ｉ／Ｆ２２によってサーバ１０から均等額以上送金依頼情報を受信すると、端末２０Ｂと端末２０Ｄとの制御部２１は、Ｂ４１０，Ｄ４１０のステップを実行する。

【0628】

そして、端末２０Ｂの制御部２１は、Ｂ１３０，Ｂ１５０のステップを行う。

【0629】

Ｓ４１０の後、通信Ｉ／Ｆ１４によって端末２０Ｂから送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。
限定ではなく例として、Ｂ１３０でユーザＢ．Ｂによってこの時点でのリアルタイム均等額よりも大きい金額が入力された場合、サーバ１０の制御部１１は、ユーザＢ．ＢのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第１種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＢ．Ｂは第１種メンバーとなる。

【0630】

サーバ１０の制御部１１は、送金額記録処理を実行すると、均等額更新処理を行う（Ｓ６１０）。具体例には、サーバ１０の制御部１１は、更新されたわりかんメンバー管理データに基づいて、限定ではなく例として、式（３）に従いリアルタイム均等額を再計算する。

【0631】

すると、サーバ１０の制御部１１は、再計算されたリアルタイム均等額を含む均等額更新情報を通信Ｉ／Ｆ１４によって端末２０Ｄに送信する。

【0632】

なお、サーバ１０の制御部１１は、均等額更新情報の送信先を以下のように決定してもよい。
・直前に送金依頼情報を送信した端末２０（この場合、端末２０Ｂ）
・その時点で送金依頼情報を送信していない端末２０（この場合、端末２０Ｄ）
・マスターの端末２０（この場合、端末２０Ａ）
・上記の任意の組み合わせ

【0633】

また、サーバ１０の制御部１１は、再計算されたリアルタイム均等額が再計算前のリアルタイム均等額から変化していない場合、均等額更新情報を送信しないようにしてもよい。

【0634】

また、均等額更新情報には、限定ではなく例として、直前に送金依頼情報を送信したユーザの情報や、その時点でのわりかん残額（「わりかん総額－その時点におけるメンバーの支払い金額の総和」）を含めるようにしてもよい。

【0635】

次いで、サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金依頼情報を受信したか否かを判定し（Ｓ４５０）、受信しなかったと判定したならば（Ｓ４５０：ＮＯ）、残りのわりかんメンバーからの送金依頼情報の受信を待機する。この例では、限定ではなく例として、端末２０Ｄからの送金依頼情報の受信がまだである場合、端末２０Ｄからの送金依頼情報の受信を待機する。

【0636】

端末２０Ｄの制御部２１は、限定ではなく例として、Ｄ４１０のステップを実行すると、通信Ｉ／Ｆ２２によってサーバ１０から均等額更新情報を受信したか否かを判定し（Ｄ６１０）、受信したと判定したならば（Ｄ６１０：ＹＥＳ）、受信した均等額更新情報に基づいて、表示部２４にリアルタイム均等額を更新して表示させる（Ｄ６２０）。

【0637】

均等額更新情報を受信しないと判定したならば、端末２０Ｄの制御部２１は、Ｄ６２０のステップをスキップする。

【0638】

そして、端末２０Ｄの制御部２１は、Ｄ４３０～Ｄ４５０のステップを行う。

【0639】

通信Ｉ／Ｆ１４によって端末２０Ｄから送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。
限定ではなく例として、Ｄ４３０でユーザＤ．Ｄによってこの時点でのリアルタイム均等額が入力された場合、サーバ１０の制御部１１は、ユーザＤ．ＤのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第２種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＤ．Ｄは第２種メンバーとなる。

【0640】

そして、サーバ１０の制御部１１は、Ｓ６１０～Ｓ４５０のステップを行う。
マスターを除くわりかんメンバー全員から送金依頼情報を受信したと判定したならば（Ｓ４５０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ４９０の終了判定に処理を移す。

【0641】

なお、サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金依頼情報を受信したと判定したならば（Ｓ４５０：ＹＥＳ）、わりかんが終了したことを示す情報をマスターの端末２０、または、わりかんメンバーの各端末２０、あるいはその両方に送信するようにしてもよい。そして、各端末２０は、わりかんが終了したことを示す情報を受信すると、表示部２４に表示させるようにしてもよい。

【0642】

＜第１１実施例の効果＞
本実施例は、サーバ１０が、マスターの端末（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、受信したわりかん要求情報に基づき、均等額以上送金依頼情報（限定ではなく、第２端末と第３端末とが支払う金額に関する第１金額情報の一例）を通信Ｉ／Ｆ１４によって第２端末と第３端末とに送信する。そして、サーバ１０は、均等額以上送金依頼情報に基づき第２端末のメンバーによって入力された支払い金額を含む送金依頼情報を通信Ｉ／Ｆ１４によって第２端末から受信する。そして、サーバ１０は、受信した送金依頼情報に基づき、再計算されたリアルタイム均等額の情報・均等額更新情報（限定ではなく、第２金額情報の一例を通信Ｉ／Ｆ１４によって第３端末に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末から受信した支払い依頼に関する第１情報に基づいて、限定ではなく例として、第２端末や第３端末のユーザの一人あたりの支払い金額の情報などの第１金額情報をユーザに通知することができる。また、限定ではなく例として、第１金額情報に基づき第２端末のユーザによって入力された第２情報に基づき、第１金額情報から支払う金額が変更された第２金額情報を第３端末のユーザに知らせることができる。

【0643】

また、この場合、均等額以上送金依頼情報は、第２端末が少なくとも支払う金額の情報を含み、サーバ１０が第２端末から受信する送金依頼情報は、均等額以上送金依頼情報に含まれる金額よりも支払う金額が高いことを示す情報を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２情報は、第２端末が少なくとも支払う金額の情報を含む第１金額情報よりも支払う金額が高いことを示す情報であることによって、第１金額情報から支払う金額を変更可能とすることができる。

【0644】

また、この場合、サーバ１０は、サーバ１０が第２端末から受信する送金依頼情報に含まれる、第２端末が支払う金額の情報に基づいて、均等額更新情報のリアルタイム均等額を設定（算出）する処理を制御部１１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２情報に含まれる、第２端末が支払う金額の情報に基づいて、第２金額情報の第２金額を設定することによって、第２端末が支払う金額を設定した後に、第２金額情報の第２金額を設定することができる。

【0645】

本実施例は、マスターの端末２０（限定ではなく、第１端末の一例）とは異なる端末２０（限定ではなく、第２端末の一例）とサーバ１０とを備える通信システム１において、第２端末は、サーバ１０から送信されたアプリケーションを受信し、受信したアプリケーションを記憶部２８に記憶する。
サーバ１０は、マスターの端末２０からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）を受信し、受信したわりかん要求情報に基づき、均等額以上送金依頼情報（限定ではなく、第２端末と第３端末とが支払う金額に関する第１金額情報の一例）を第２端末と第３端末とに送信する。
第２端末は、受信した均等額以上送金依頼情報に基づき第２端末のユーザによって入力された支払い金額の情報（限定ではなく、第２情報の一例）を、アプリケーションによってサーバ１０に送信する。
そして、サーバ１０は、第２端末から受信された支払い金額の情報に基づき、再計算されたリアルタイム均等額の情報・均等額更新情報（限定ではなく、第２金額情報の一例）を通信Ｉ／Ｆ１４によって第３端末に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２端末が、サーバから送信されたアプリケーションを受信し、受信したアプリケーションを記憶部に記憶することによって、本願請求項に係るシステムの発明の機能が実現可能となる状態を作り出すことができる（システムの生産）。その上で、サーバが、第１端末から支払い依頼に関する第１情報を受信し、受信した第１情報に基づき、第２端末と第３端末とが支払う金額に関する第１金額情報を第２端末と第３端末とに送信する。そして、第２端末が、第１金額情報に基づき第２端末のユーザによって入力された、支払いに関する第２情報を、アプリケーションによってサーバに送信し、サーバが、第２端末から受信された第２情報に基づき、第１金額情報から支払う金額が変更された第２金額情報を第３端末に送信するというシステムの発明の機能を実現することができる。また、上記と同様の効果を得ることができる。
なお、これは、本実施例に示したシステムの発明の機能に限らず、他の実施例等に示すシステムの発明の機能についても同様とすることができる

【0646】

＜第１１変形例（１）＞
上記の実施例では、支払い時点におけるリアルタイム均等額よりも大きい金額の支払い金額指定を行ったメンバーには「第１種」が設定され、支払い時点におけるリアルタイム均等額と等しい支払い金額指定を行ったメンバーには「第２種」が設定されることとしたが、これに限定されない。限定ではなく例として、支払い時点におけるリアルタイム均等額よりも小さい金額の支払い金額指定を行ったメンバーには「第１種」が設定され、支払い時点におけるリアルタイム均等額と等しい支払い金額指定を行ったメンバーには「第２種」が設定されるようにしてもよい。

【0647】

図１１－７は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0648】

限定ではなく例として、図１１－７左側において、お知らせ情報ＮＴ５０の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１１－７中央の送金画面に表示が遷移する。

【0649】

この例では、送金金額指定領域ＲＡＲ１には、現在の均等額よりも減額した「２，０００円」が送金金額として指定されたことが表示されている。

【0650】

限定ではなく例として、送金金額が送金金額指定領域ＲＡＲ１に入力され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、サーバ１０から、ユーザＤ．Ｄの端末２０Ｄに対して、支払い金額などに関するお知らせ情報が送信される。

【0651】

図１１－７右側には、この場合における端末２０Ｄのお知らせ画面の一例を示している。
この例では、お知らせ情報ＮＴ５０およびＮＴ５５が上から順に表示されている。
お知らせ情報ＮＴ５５には、更新された現在の均等額（「５，０００円」）に関する情報が含まれる。この金額は、ユーザＢ．Ｂがリアルタイム均等額よりも少ない金額を支払うと決定したことに基づいて、わりかん開始時におけるリアルタイム均等額よりも大きい金額になっている。

【0652】

本変形例は、均等額以上送金依頼情報は、第２端末が少なくとも支払う金額の情報を含み、サーバ１０が第２端末から受信する送金依頼情報は、均等額以上送金依頼情報に含まれる金額よりも支払う金額が低いことを示す情報を含む構成を示している。
このような構成により得られる変形例の効果の一例として、第２情報は、第２端末が少なくとも支払う金額の情報を含む第１金額情報よりも支払う金額が低いことを示す情報であることによって、第１金額情報から支払う金額を変更可能とすることができる。

【0653】

＜第１２実施例＞
第１２実施例は、（３）の手法に関し、リアルタイム均等額が変化した場合、第２種メンバーに、支払い時点におけるリアルタイム均等額と現在のリアルタイム均等額との差額を返金することに関する実施例である。
第１２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0654】

＜表示画面＞
図１２－１～図１２－５は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0655】

ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
となる場合の表示画面例を説明する。

【0656】

限定ではなく例として、図１２－１右側の表示画面最下部の「決定」ボタンがタップされると、限定ではなく例として、サーバ１０から、ユーザＤ．Ｄの端末２０Ｄに対して、支払い金額などに関するお知らせ情報が送信される。
すると、限定ではなく例として、幹事の端末２０Ａ以外の各端末２０において、限定ではなく例として、図１２－２左側に示すようなお知らせ画面が表示される。ここでは、限定ではなく例として、端末２０Ｄにおけるお知らせ画面の一例を示している。

【0657】

この例では、お知らせ情報ＮＴ５６が表示されている。
お知らせ情報ＮＴ５６には、わりかん総額（「２０，０００円」）と、わりかん人数（「４人」）と、現在の均等額（「５，０００円」）とに関する情報が含まれる。

【0658】

限定ではなく例として、お知らせ情報ＮＴ５６の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１２－２中央の送金画面に表示が遷移する。

【0659】

この例では、現在の均等額として「５，０００円」が表示されている。
また、送金金額指定領域ＲＡＲ１には、現在の均等額である「５，０００円」が表示されている。

【0660】

限定ではなく例として、「均等額を支払う」ボタンがユーザによってタップされ、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１２－２右側の送金結果画面に表示が遷移する。

【0661】

この送金結果画面では、ユーザＤ．ＤがユーザＡ．Ａに現在の均等額である「５，０００円」を送金したことが表示されている。この結果、ユーザＤ．Ｄは第２種メンバーとなる。

【0662】

図１２－３左側には、限定ではなく例として、ユーザＤ．Ｄがリアルタイム均等額を送金した後の端末２０Ｂのお知らせ画面の一例を示している。

【0663】

限定ではなく例として、お知らせ情報ＮＴ５６の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１２－３中央の送金画面に表示が遷移する。
なお、お知らせ情報ＮＴ５６の下には、ユーザＤ．Ｄがリアルタイム均等額を送金したことを示すお知らせ情報を表示させるようにしてもよい。

【0664】

図１２－３中央の表示画面については、前述した図１２－２中央と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＢ．Ｂの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0665】

この例では、送金金額指定領域ＲＡＲ１には、現在の均等額よりも増額した金額「８，０００円」が送金金額として指定され、現在の均等額として「５，０００円」が表示されている。

【0666】

限定ではなく例として、送金金額が送金金額指定領域ＲＡＲ１に入力され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１２－３右側の送金結果画面に表示が遷移する。

【0667】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに現在の均等額よりも増額した金額である「８，０００円」を送金したことが表示されている。この結果、ユーザＢ．Ｂは第１種メンバーとなる。

【0668】

限定ではなく例として、ユーザＢ．Ｂ、ユーザＤ．Ｄによって支払い金額が送信されると、限定ではなく例として、サーバ１０から、ユーザＣ．Ｃの端末２０Ｃに対して、支払い金額に関するお知らせ情報が送信される。

【0669】

図１２－４左側には、この場合における端末２０Ｃのお知らせ画面の一例を示している。図１２－４左側の表示画面については、前述した図１２－３左側と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＣ．Ｃの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0670】

この例では、お知らせ情報ＮＴ５６の下には、お知らせ情報ＮＴ５７が表示されている。
お知らせ情報ＮＴ５７には、ユーザＢ．Ｂがリアルタイム均等額よりも大きい金額を支払うことを決定したことに基づいて、更新された現在の均等額（「３，５００円」）に関する情報が含まれる。

【0671】

限定ではなく例として、お知らせ情報ＮＴ５７の「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１２－４中央の送金画面に表示が遷移する。

【0672】

図１２－４中央の表示画面については、前述した図１２－３中央と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＣ．Ｃの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0673】

この例では、送金金額指定領域ＲＡＲ１には、現在の均等額よりも増額した金額「１０，０００円」が送金金額として指定され、現在の均等額として「３，５００円」が表示されている。

【0674】

限定ではなく例として、送金金額が送金金額指定領域ＲＡＲ１に入力され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１２－４右側の送金結果画面に表示が遷移する。

【0675】

この送金結果画面では、ユーザＣ．ＣがユーザＡ．Ａに現在の均等額よりも増額した金額である「１０，０００円」を送金したことが表示されている。この結果、ユーザＣ．Ｃは第１種メンバーとなる。

【0676】

図１２－５には、ユーザＤ．Ｄによって支払い金額が送信された後（図１２－２右側の後）の端末２０Ｄのお知らせ画面の遷移の一例を示している。

【0677】

図１２－５左側は、ユーザＤ．Ｄによって支払い金額が決定された直後のお知らせ画面の一例である。この例では、お知らせ情報ＮＴ５６の下には、お知らせ情報ＮＴ５８が表示されている。
お知らせ情報ＮＴ５８には、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、支払い予定額（「５，０００円」）の送金が完了したことに関する情報が含まれる。

【0678】

図１２－５中央は、ユーザＢ．Ｂによって支払い金額が送信された後（図１２－３右側の後）のお知らせ画面の一例である。

【0679】

この例では、お知らせ情報ＮＴ５８の下には、お知らせ情報ＮＴ５９～ＮＴ６０が表示されている。
お知らせ情報ＮＴ５９には、更新された現在の均等額（「３，５００円」）に関する情報が含まれる。
また、お知らせ情報ＮＴ６０には、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、支払い済みのリアルタイム均等額（「５，０００円」）から更新後のリアルタイム均等（３，５００円）に変更されたことに基づいて、リアルタイム均等額の過払い分である返金金額（「５，０００円」－「３，５００円」＝「１，５００円」）の返金が完了したことに関する情報が含まれる。

【0680】

図１２－５右側は、ユーザＣ．Ｃによって支払い金額が送信された後（図１２－４右側の後）のお知らせ画面の一例である。

【0681】

この例では、お知らせ情報ＮＴ６０の下には、お知らせ情報ＮＴ６１～ＮＴ６２が表示されている。
お知らせ情報ＮＴ６１には、最終的なリアルタイム均等額（「１，０００円」）に関する情報が含まれる。
また、お知らせ情報ＮＴ６２には、幹事であるユーザＡ．Ａが、ユーザＤ．Ｄに対して、リアルタイム均等額の過払い分である返金金額（「３，５００円」－「１，０００円」＝「２，５００円」）の返金が完了したことに関する情報が含まれる。

【0682】

＜処理＞
図１２－６～図１２－７は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。この図では、左側から順に、サーバ１０の制御部１１が実行する処理、端末２０Ｂの制御部２１が実行する処理、端末２０Ｃの制御部２１が実行する処理、端末２０Ｄの制御部２１が実行する処理をそれぞれ示している。なお、マスターであるユーザＡ．Ａの端末２０Ａの制御部２１が実行する処理については、本フローチャートでは省略して表記する。

【0683】

ここでは、限定ではなく例として、端末２０Ｂのユーザが最初に支払い金額を決定し、次に、端末２０Ｄのユーザが支払い金額を決定し、最後に端末２０Ｃのユーザが支払い金額を決定する例を示す。
なお、フローチャートにおいて、それぞれの支払い順におけるＳ４５０の判定結果に応じたループ処理を「Ｌｏｏｐ１」～「Ｌｏｏｐ３」と表記し区別することとする。

【0684】

通信Ｉ／Ｆ１４によって端末２０ＢからＬｏｏｐ１における送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。
限定ではなく例として、Ｂ１３０でユーザＢ．Ｂによってこの時点でのリアルタイム均等額よりも大きい金額が入力された場合、サーバ１０の制御部１１は、ユーザＢ．ＢのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第１種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＢ．Ｂは第１種メンバーとなる。

【0685】

そして、サーバ１０の制御部１１は、均等額更新処理を実行し、均等額更新処理を、限定ではなく例として、端末２０Ｃと端末２０Ｄとに送信すると、再計算されたリアルタイム均等額と、第２種のメンバー種別のユーザの支払い金額（「送金済み均等額」と称する。）とに差額が発生したか否かを判定する（Ｓ７１０）。

【0686】

差額が発生したと判定した場合（Ｓ７１０：ＹＥＳ）、サーバ１０の制御部１１は、均等額差額返金処理を行う（Ｓ７２０）。具体例には、限定ではなく例として、わりかんメンバー管理データにおいて、第２種のメンバー種別と関連付けられたユーザに対して、（支払い金額－リアルタイム均等額）で算出される均等額差額を、限定ではなく例として、マスターのアカウントからその第２種のアカウントに送金（返金）する処理を実行する。

【0687】

差額が発生していないと判定した場合（Ｓ７１０：ＮＯ）、サーバ１０の制御部１１は、均等額差額返金処理をスキップする。

【0688】

限定ではなく例として、Ｌｏｏｐ１においては、均等額更新処理においてリアルタイム均等額が変化しているが、第２種のメンバー種別であるユーザは存在しないため、均等額差額返金処理は実行されない。

【0689】

次いで、サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金依頼情報を受信したか否かを判定し（Ｓ４５０）、受信しなかったと判定したならば（Ｓ４５０：ＮＯ）、ループ処理Ｌｏｏｐ２において残りのわりかんメンバーからの送金依頼情報の受信を待機する。

【0690】

通信Ｉ／Ｆ１４によって端末２０ＤからＬｏｏｐ２における送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。
限定ではなく例として、端末２０Ｄにおいてリアルタイム均等額が更新表示され、Ｄ４３０でユーザＤ．Ｄによってこの時点でのリアルタイム均等額が入力された場合、サーバ１０の制御部１１は、ユーザＤ．ＤのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第２種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＤ．Ｄは第２種メンバーとなる。

【0691】

そして、サーバ１０の制御部１１は、Ｓ６１０～Ｓ４５０のステップを行う。
限定ではなく例として、Ｌｏｏｐ２においては、均等額更新処理においてリアルタイム均等額が変化していないため、均等額差額返金処理は実行されない。

【0692】

サーバ１０の制御部１１は、マスターを除くわりかんメンバー全員から送金依頼情報を受信したか否かを判定し（Ｓ４５０）、受信しなかったと判定したならば（Ｓ４５０：ＮＯ）、ループ処理Ｌｏｏｐ３において残りのわりかんメンバーからの送金依頼情報の受信を待機する。

【0693】

通信Ｉ／Ｆ２２によってサーバ１０から均等額以上送金依頼情報を受信すると、端末２０Ｃの制御部２１は、限定ではなく例として、Ｄ４１０～Ｄ４９０のステップと同様に、Ｃ７１０～Ｃ７６０のステップを実行する。

【0694】

Ｓ４１０の後、通信Ｉ／Ｆ１４によって端末２０ＣからＬｏｏｐ３における送金依頼情報を受信すると、サーバ１０の制御部１１は、送金額記録処理を行う（Ｓ４３０）。
限定ではなく例として、端末２０Ｃにおいてリアルタイム均等額が更新表示され、Ｃ７４０でユーザＣ．Ｃによってこの時点でのリアルタイム均等額よりも大きい金額が入力された場合、サーバ１０の制御部１１は、ユーザＣ．ＣのアプリケーションＩＤと関連付けて、わりかんメンバー管理データのメンバー種別に「第１種」を記憶させる。つまり、入力された支払いを行う金額に基づき、ユーザＣ．Ｃは第１種メンバーとなる。

【0695】

そして、サーバ１０の制御部１１は、Ｓ６１０～Ｓ７１０のステップを実行する。
限定ではなく例として、Ｌｏｏｐ３においては、均等額更新処理においてリアルタイム均等額が変化し、ユーザＤ．Ｄが第２種のメンバー種別と記憶されているため、均等額差額返金処理が実行される。そして、限定ではなく例として、マスターであるユーザＡ．ＡからユーザＤ．Ｄへの送金処理が実行される。

【0696】

マスターを除くわりかんメンバー全員から送金依頼情報を受信したと判定したならば（Ｓ４５０：ＹＥＳ）、サーバ１０の制御部１１は、ループ処理を抜け、Ｓ４９０の終了判定に処理を移す。

【0697】

なお、ユーザＤ．Ｄに対して返金する金額が、限定ではなく例として、マスターであるユーザＡ．Ａによって決定されるようにしてもよい。

【0698】

＜第１２実施例の効果＞
本実施例は、サーバ１０が、リアルタイム均等額の情報（限定ではなく、第２金額情報の一例）を、第４端末に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、リアルタイム均等額の情報に基づき第３端末のユーザによって入力された支払い金額に関する情報（限定ではなく、第３情報の一例）を通信Ｉ／Ｆ１４によって第３端末から受信する。また、サーバ１０は、リアルタイム均等額の情報に基づき第４端末のユーザによって入力された支払い金額に関する情報（限定ではなく、第４情報の一例）を通信Ｉ／Ｆ１４によって第４端末から受信する。そして、サーバ１０は、第４端末から受信した情報（第４情報）に基づき、第３端末に対して返金する処理を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２金額情報に基づき第４端末のユーザによって入力された、支払いに関する第４情報を第４端末から受信した上で、この第４情報に基づき、第３端末に対して返金することができる。

【0699】

また、この場合、サーバ１０は、第３端末に返金に関する返金通知を通信Ｉ／Ｆ１４によって送信するようにしてもよい。
このような構成により得られる実施例の効果の一例として、第３端末に返金に関する情報を通知することができる。

【0700】

また、本実施例は、リアルタイム均等額の情報に基づき第４端末のユーザによって入力された支払い金額に関する情報（限定ではなく、第４情報の一例）は、リアルタイム均等額の情報（限定ではなく、第２金額情報の一例）よりも支払う金額が高いことを示す情報を含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第４情報は、第２金額情報よりも支払う金額が高いことを示す情報であることによって、この第４情報に基づき、第３端末に対して返金することができる。

【0701】

また、この場合、返金の金額は、リアルタイム均等額の情報に基づき第４端末のユーザによって入力された支払い金額に関する情報（限定ではなく、第４情報の一例に含まれる支払い金額によって決定されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、返金の金額が、第４情報に含まれる第４端末が支払う金額によって決定されることによって、返金が必要な端末に対して適切な金額を返金することが可能となる。

【0702】

また、この場合、返金する処理は、リアルタイム均等額の情報に基づき第４端末のユーザによって入力された支払い金額に関する情報（限定ではなく、第４情報の一例）の受信に基づいて処理が実行されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第４端末が支払う金額が含まれる第４情報を受信した上で、返金の金額が決定され、適切な金額を返金することが可能となる。

【0703】

本実施例は、サーバ１０が、マスターの端末（限定ではなく、第１端末の一例）からわりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）を通信Ｉ／Ｆ１４によって受信する。そして、サーバ１０は、受信したわりかん要求情報に基づき、均等額以上送金依頼情報（限定ではなく、第２端末と第３端末とが支払う金額に関する第１金額情報の一例）を通信Ｉ／Ｆ１４によって第２端末と第３端末とに送信する。サーバ１０は、均等額以上送金依頼情報に基づき、支払い金額を含む送金依頼情報（限定ではなく、支払いに関する第２情報の一例）を通信Ｉ／Ｆ１４によって第２端末から受信する。サーバ１０は、この第２端末からの送金依頼情報の受信の後、均等額以上送金依頼情報に基づき、支払い金額を含む送金依頼情報（限定ではなく、支払いに関する第３情報の一例）を通信Ｉ／Ｆ１４によって第３端末から受信し、この第３端末から受信した送金依頼情報に基づき、第２端末に対して返金する処理を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１端末から受信した支払い依頼に関する第１情報に基づいて、限定ではなく例として、第２端末や第３端末のユーザの一人あたりの支払い金額の情報などの第１金額情報をユーザに通知することができる。また、第１金額情報に基づき、支払いに関する第２情報を第２端末から受信し、その後、第１金額情報に基づき、支払いに関する第３情報を第３端末から受信した場合に、この第３情報に基づき、第２端末に返金することができる。限定ではなく例として、第２端末によって第１金額情報の金額が支払われ、その後、第３端末によって第１金額情報の金額よりも多い金額が支払われるような場合であっても、第２端末に対する返金によって金額を調整することができる。

【0704】

＜第１２変形例（１）＞
上記の実施例では、リアルタイム均等額が更新されると、その都度第２種のユーザに対して返金を行ったが、これに限定されない。
具体例には、上記の実施例では、均等額更新処理が行われるごとに、リアルタイム均等額と第２種のメンバー種別のユーザの支払い金額とに差額が発生したか判定していたが、限定ではなく例として、図１２－６において、Ｓ７１０～Ｓ７２０のステップをＳ４５０のステップの後に実行するようにしてもよい。

【0705】

図１２－８は、本変形例において端末２０Ｄの表示部２４に表示される画面の遷移の一例を示す図である。図１２－８は、限定ではなく例として、図１２－５の別例である。

【0706】

図１２－８中央では、ユーザＢ．Ｂによって支払い金額が決定され、リアルタイム均等額が更新されているが、図１２－５中央とは異なり、ユーザＤ．Ｄに対して返金金額が返金されていないので、お知らせ情報ＮＴ６０が表示されていない。

【0707】

図１２－８右側では、ユーザＣ．Ｃによって支払い金額が決定され、最終的なリアルタイム均等額が決定されたことに基づいて、お知らせ情報ＮＴ６２には、支払い済みのリアルタイム均等額（「５，０００円」）から最終的なリアルタイム均等（１，０００円）の過払い分である返金金額（「５，０００円」－「１，０００円」＝「４，０００円」）の返金が完了したことに関する情報が含まれる。

【0708】

本変形例は、返金は、均等額以上送金依頼情報（限定ではなく、第２端末と第３端末とが支払う金額に関する第１金額情報の一例）を受け取ったメンバーの支払いの完了に基づいて実行される構成を示している。
このような構成により得られる実施例の効果の一例として、第１金額情報を受け取った上でユーザによって支払われた金額に基づき、返金されるので、適切な金額を返金することができる。

【0709】

＜第１２変形例（２）＞
上記の実施例では、均等額差額返金処理において、リアルタイム均等額と送金依頼情報における支払い金額（支払い予定額）とに基づいて決定された第１種および第２種のメンバー種別に基づいて自動的に返金額が算出されることとしたが、これに限定されない。
限定ではなく例として、第７変形例（２）を参酌し、マスターの端末２０において、各メンバーへの返金額が指定できるようにしてもよい。

【0710】

本変形例は、返金の金額は、マスター（限定ではなく、第１端末のユーザの一例）によって決定されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、返金の金額が、第１端末のユーザによって決定されることによって、返金の金額に関して、第１端末のユーザが任意に調整することが可能となる。

【0711】

＜第１３実施例＞
第１３実施例は、（３）の手法において、限定ではなく例として、サーバ１０が同時あるいはほぼ同時に複数の端末２０から送金依頼情報を受信した場合、リアルタイム均等額の更新が追いつかなくなることを防止することに関する実施例である。
第１３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0712】

＜表示画面＞
図１３－１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
限定ではなく例として、図１３－１では、図１２－３においてユーザＢ．Ｂが支払い金額を決定するのと同時にユーザＣ．Ｃが支払い金額を決定した場合の表示画面の一例を示す。

【0713】

限定ではなく例として、図１３－１左側において、端末２０ＢにおいてユーザＢ．Ｂが支払い金額を決定した直後（限定ではなく例として、ユーザＢ．Ｂが支払い金額を決定後５秒以内）に、図１３－１中央において、端末２０ＣにおいてユーザＣ．Ｃがリアルタイム均等額を支払うことを選択すると、端末２０Ｃでは、限定ではなく例として図１３－１右側の送金画面が表示される。この画面では、「処理に失敗しました」の文字と共に、しばらく経ってから再度送金額決定操作を行うことを促すメッセージが表示されるように構成されている。

【0714】

＜処理＞
本実施例では、限定ではなく例として図１１－６や図１２－６の処理において、サーバ１０の制御部１１は、一のわりかんメンバーの端末２０（限定ではなく例として、端末２０Ｂ）から送金依頼情報を受信した後、設定された期間内（設定された時間内）に、別のわりかんメンバーの端末２０（限定ではなく例として、端末２０Ｄ）から送金依頼情報を受信したか否かを判定する。そして、受信したと判定したならば、サーバ１０の制御部１１は、別のわりかんメンバーの端末２０に対してエラー情報を送信するようにすることができる。そして、サーバ１０からエラー情報を受信した端末２０の制御部２１は、受信したエラー情報を表示部２４に表示させるようにすることができる。

【0715】

＜第１３実施例の効果＞
本実施例は、サーバ１０が、第２端末のユーザによって入力された支払い金額を含む送金依頼情報（限定ではなく、第２情報の一例）を受信した後、設定された期間内に、わりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）に基づき第５端末のユーザによって入力された支払い金額を含む送金依頼情報を第５端末から受信した場合、第５端末に対してエラー情報（限定ではなく、処理が実行できなかったことを示す情報の一例）を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報を受信した後、設定された期間内に、他の端末のユーザによって入力された、支払いに関する情報に基づく処理が実行されなかったことを示す情報をこの端末に送信することによって、処理が実行できなかったことを適確に知らせることができる。

【0716】

＜第１３変形例（１）＞
上記の実施例では、サーバ１０が送金依頼情報受信後、設定期間内に再度送金依頼情報を受信する場合、送金額記録処理を実行せずにエラー情報を端末２０に送信する例を示したが、これに限定されない。
限定ではなく例として、サーバ１０は、送金額記録処理と均等額更新処理とにおいて、所定期間内に受信した１以上の送金依頼情報をまとめてバッチ処理するようにしてもよい。

【0717】

図１３－２～図１３－３は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。図１３－２～図１３－３は、限定ではなく例として、図１３－１の別例である。

【0718】

図１３－２は、端末２０Ｂにおける表示の遷移の一例である。
図１３－２左側において、送金金額指定領域ＲＡＲ１において、現在の均等額（「５，０００円」）よりも増額した金額「８，０００円」が送金金額として指定され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１３－２中央の送金結果画面に表示が遷移する。この画面では、送金を受け付けたことを示すメッセージと、送金を受け付けた日時が「２０ＸＸ／７／７ ２１：１５：１０」であることとが表示されている。

【0719】

その後、限定ではなく例として、図１３－２右側のお知らせ画面に表示が遷移する。
この例では、お知らせ情報ＮＴ５６の下に、お知らせ情報ＮＴ６３～ＮＴ６４が表示されている。
お知らせ情報ＮＴ６３には、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額（「８，０００円」）を送金したことに関する情報が含まれる。
また、お知らせ情報ＮＴ６４には、ユーザＢ．Ｂがリアルタイム均等額（「５，０００円」）よりも多い支払い金額を決定したことにより、更新された現在の均等額（「３，５００円」）に関する情報が含まれる。
お知らせ情報ＮＴ６３とお知らせ情報ＮＴ６４との処理日時は、「２０ＸＸ／７／７ ２１：１５：１５」であることとが表示されている。

【0720】

図１３－３は、端末２０Ｃにおける表示の遷移の一例である。
図１３－３左側において、送金金額指定領域ＲＡＲ１において、現在の均等額（「５，０００円」）送金金額として指定され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１３－３中央の送金結果画面に表示が遷移する。この画面では、送金を受け付けたことを示すメッセージと、送金金額がわりかん均等額（リアルタイム均等額：この時点では「５，０００円」）であることと、送金を受け付けた日時が「２０ＸＸ／７／７ ２１：１５：１０」であることとが表示されている。

【0721】

その後、限定ではなく例として、図１３－３右側のお知らせ画面に表示が遷移する。
この例では、お知らせ情報ＮＴ５６の下に、お知らせ情報ＮＴ６４～ＮＴ６５が表示されている。
また、お知らせ情報ＮＴ６４には、ユーザＢ．Ｂがリアルタイム均等額（「５，０００円」）よりも多い支払い金額を決定したことにより、更新された現在の均等額（「３，５００円」）に関する情報が含まれる。
お知らせ情報ＮＴ６５には、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、更新された現在の均等額（「３，５００円」）を送金したことに関する情報が含まれる。
お知らせ情報ＮＴ６４とお知らせ情報ＮＴ６５との処理日時は、「２０ＸＸ／７／７ ２１：１５：１５」であることとが表示されている。

【0722】

すなわち、図１３－２中央における送金依頼情報と、図１３－３中央における送金依頼情報とは、逐次処理されず、設定された期間（限定ではなく例として、５秒間）ごとに受け付けられた後、一括処理（バッチ処理）されたことが処理日時からわかる。

【0723】

この例では、サーバ１０が、端末２０Ｂから送金依頼情報を受信した後、設定された期間内に、端末２０Ｃから送金依頼情報を受信している。
当初のリアルタイム均等額は「５，０００円」であったため、ユーザＣ．Ｃは「５，０００円」を支払う意思を示したが、ユーザＢ．Ｂがリアルタイム均等額よりも多い「８，０００円」を支払う決定をしたことによってリアルタイム均等額が「５，０００円」から「３，５００円」に更新され、結果的に、ユーザＣ．Ｃは「５，０００円」ではなく「３，５００円」を支払ったことが示されている。

【0724】

本変形例は、サーバ１０が、第２端末のユーザによって入力された支払い金額を含む送金依頼情報（限定ではなく、第２情報の一例）を受信した後、設定された期間内に、わりかん要求情報（限定ではなく、支払い依頼に関する第１情報の一例）に基づき第５端末のユーザによって入力された支払い金額を含む送金依頼情報を第５端末から受信した場合に、第２端末からの送金依頼情報の受信に基づいて、第５端末が支払う金額が変更される場合、均等額以上送金依頼情報（限定ではなく、第１金額情報の一例）から支払う金額が変更された金額情報（限定ではなく、第３金額情報の一例）を通信Ｉ／Ｆ１４によって第５端末に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第２情報を受信した後、設定された期間内に、第１情報に基づき第５端末のユーザによって入力された、支払いに関する情報を第５端末から受信した場合に、第２情報の受信に基づいて、第５端末が支払う金額が変更される場合、第１金額情報から支払う金額が変更されたことを適確に報知することができる。

【0725】

＜第１４実施例＞
第１４実施例は、（３）の手法において、わりかんをするメンバーを２以上のグループに分割する実施例である。
第１４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0726】

図１４－１は、本実施例におけるわりかんリクエスト管理データベース１５７の一例であるわりかんリクエスト管理データベース１５７Ｈのデータ構成の一例を示す図である。
このわりかんリクエスト管理データベース１５７Ｈは、ＳＹＳ－１３のわりかんリクエスト管理データベース１５７Ｄとほぼ同様のデータ構成であるが、その一部が異なっている。

【0727】

具体的には、各々のわりかん管理データのわりかんグループ管理データには、グループＩＤと、グループ内わりかん総額とに加えて、限定ではなく例として、グループ内リアルタイム均等額と、支払い優先度とが記憶される。

【0728】

グループ内リアルタイム均等額は、このグループＩＤによって識別されるグループ内でのリアルタイム均等額である。

【0729】

支払い優先度は、グループ内で均等額差額が発生した場合、優先的に送金を行うグループを指定するための順位を示す情報であり、限定ではなく例として、マスターの端末２０によって設定される情報である。限定ではなく例として、支払い優先度の数字が大きいほど、優先的に送金を行うグループとするようにしてよい。

【0730】

＜表示画面＞
図１４－２～図１４－４は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0731】

ここでは、わりかんに参加する６名のわりかんメンバーのメンバー種別を、
・幹事＝ユーザＡ．Ａ
・第１Ｇ＝ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ
・第２Ｇ＝ユーザＥ．Ｅ、ユーザＦ．Ｆ
とする場合の表示画面例を説明する。

【0732】

図１４－２および図１４－３の表示画面については、前述した図８－２および図８－３と同様であるので説明を省略する。

【0733】

限定ではなく例として、図１４－３では、第２Ｇのグループ内リアルタイム均等額（「５，０００円」）は、第１Ｇのグループ内リアルタイム均等額（「７，５００円」）よりも低い金額となっている。

【0734】

図１４－４左側の表示画面については、前述した図１１－３中央と同様である部分についての説明を省略する。

【0735】

図１４－４左側において、第１Ｇの端末２０Ｂに表示される送金画面では、送金金額指定領域ＲＡＲ１には、現在の均等額よりも増額した「９，５００円」が送金金額として指定されており、現在の均等額として「７，５００円」が表示されている。

【0736】

限定ではなく例として、送金金額が送金金額指定領域ＲＡＲ１に入力され、画面最下部の「決定」ボタンがタップされると、限定ではなく例として、図１４－４中央の送金結果画面に表示が遷移する。

【0737】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに送金リクエストされた金額より増額した金額「９，５００円」を送金したことが表示されている。結果として、ユーザＢ．Ｂは第１種メンバーとなるが、この例では、第１Ｇのリアルタイム均等額は更新されない。

【0738】

限定ではなく例として、第１ＧのユーザＢ．Ｂによって支払い金額が送信されると、限定ではなく例として、サーバ１０から、第２ＧのユーザＥ．Ｅの端末２０Ｅに対して、均等額の更新に関するお知らせ情報が送信される。

【0739】

図１４－４右側には、この場合における端末２０Ｅのお知らせ画面の一例を示している。図１４－４右側の表示画面については、前述した図１４－３右側と同様である部分についての説明を省略する。

【0740】

この例では、お知らせ情報ＮＴ３５の下に、お知らせ情報ＮＴ７０が表示されている。
お知らせ情報ＮＴ７０には、更新された現在の均等額（「４，０００円」）に関する情報が含まれる。
すなわち、この例では、第１Ｇにおいてリアルタイム均等額よりも大きい金額が支払われた場合、その余剰分が第２Ｇにおけるリアルタイム均等額に対する均等額更新処理に使用される。

【0741】

なお、この例では、第１Ｇにおいてリアルタイム均等額よりも大きい金額が支払われたことに基づき余剰分の金額が発生する。この余剰分の金額に基づく均等額の差額が、低い金額を支払うグループ（この例では、第２Ｇ）に対して返金されるようにしてもよい。

【0742】

また、第１Ｇにおいてリアルタイム均等額よりも大きい金額が支払われたことに基づき余剰分の金額が発生する場合、この余剰分の金額に基づく均等額の差額が、第２Ｇにおける第２種メンバーとなった端末２０に対して送金されるようにしてもよい。

【0743】

＜第１４実施例の効果＞
本実施例は、サーバ１０が、通信Ｉ／Ｆ１４によって、第４金額情報を第６端末に送信し、この第４金額情報は、均等額以上送金依頼情報（限定ではなく、第１金額情報の一例）よりも低い金額の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第４金額情報は、第１金額情報よりも支払う金額が低いことを示す情報であることによって、第１金額情報から支払う金額を変更可能とすることができる。

【0744】

また、この場合、サーバ１０は、リアルタイム均等額情報（限定ではなく、第２金額情報の一例）を、第４端末に通信Ｉ／Ｆ１４によって送信し、このリアルタイム均等額情報に基づき第３端末のユーザによって入力された支払い金額を含む送金依頼情報を通信Ｉ／Ｆ１４によって第３端末から受信する。また、サーバ１０は、リアルタイム均等額情報（限定ではなく、第２金額情報の一例）に基づき第４端末によって入力された支払い金額を含む送金依頼情報を通信Ｉ／Ｆ１４によって第４端末から受信する。そして、サーバ１０は、第４端末から受信した送金依頼情報に基づく、第６端末に対して返金する処理を制御部１１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、第２金額情報に基づき第３端末のユーザによって入力された、支払いに関する第３情報を第３端末から受信し、また、第２金額情報に基づき第４端末のユーザによって入力された、支払いに関する第４情報を第４端末から受信し、その上で、第４端末から受信した第４情報に基づき、第６端末に対して適切に返金することができる。

【0745】

＜第１４変形例（１）＞
上記の実施例では、支払い優先度が大きいグループにおける第２種のユーザに対して、他のグループにおいて発生した均等額差額を送金（返金）することとしたが、これに限定されない。限定ではなく例として、支払い優先度が大きいグループに所属するわりかんメンバー全員に対して、他のグループにおいて発生した均等額差額を送金するようにしてもよい。

【0746】

この場合、均等額差額を支払い優先度が大きいグループに所属するわりかんメンバー全員に均一に送金してもよいし、第１種のユーザと第２種のユーザとに対して割合を変えて（限定ではなく例として、第２種のユーザへの送金額を第１種のユーザへの送金額よりも多くなるように）送金してもよい。

【0747】

＜第１４変形例（２）＞
上記の実施例では、支払い優先度が大きいグループに対して、他のグループにおいて発生した均等額差額を送金（返金）することとしたが、これに限定されない。限定ではなく例として、均等額差額返金処理において、それぞれのグループ内において均等額差額を送金するようにしてもよい。この場合、わりかんリクエスト管理データベース１５７Ｈにおいてわりかんグループ管理データには支払い優先度の項目は必要としない。

【0748】

＜第１５実施例＞
第１５実施例は、（３）の手法を、メッセージングアプリケーションを用いて実現することに関する実施例である。限定ではなく例として、わりかんに関する情報をメッセージングアプリケーションのトークルームに送信・表示することや、メッセージングアプリケーションと支払いアプリケーションとを連携させてわりかんを行う手法等に関する。
第１５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0749】

＜表示画面＞
図１５－１および図１５－２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
ここでは、わりかんに参加する４名のわりかんメンバーのメンバー種別が、結果的に
・幹事＝ユーザＡ．Ａ
・第１種＝ユーザＢ．Ｂ、ユーザＣ．Ｃ
・第２種＝ユーザＤ．Ｄ、ユーザＡ．Ａ
となる場合の表示画面例を説明する。

【0750】

図１５－１において、限定ではなく例として、図１０－１と同様に、幹事の端末２０Ａにおいて、わりかんが開始され、グループトークルーム内にリアルタイム均等額等の情報が表示される。

【0751】

限定ではなく例として、ユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い金額「８，０００円」を送金すると、端末２０Ｄでは、限定ではなく例として、図１５－２左側に示すようなトークルーム画面が表示される。

【0752】

このトークルーム画面では、限定ではなく例として、コンテンツ表示領域のコンテンツ情報ＣＴ１０の下には、コンテンツ情報ＣＴ１１とコンテンツ情報ＣＴ２０とが表示されている。
コンテンツ情報ＣＴ２０は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、限定ではなく例として、更新された現在の均等額（更新後のリアルタイム均等額）（「４，０００円」）に関する情報と、わりかん総額から現在の送金済み金額を減算したわりかん残額（「１２，０００円」）とが含まれる。

【0753】

限定ではなく例として、コンテンツ情報ＣＴ２０の「支払う」ボタンがユーザによってタップされ、支払いアプリケーションにおいて、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、現在の均等額である「４，０００円」を送金すると、限定ではなく例として、図１５－２中央のトークルーム画面に表示が遷移する。

【0754】

この例では、コンテンツ表示領域のコンテンツ情報ＣＴ２０の下には、コンテンツ情報ＣＴ２１およびコンテンツ情報ＣＴ２２が表示されている。
コンテンツ情報ＣＴ２１は、送信元がユーザＤ．Ｄであるコンテンツ情報であって、ユーザＤ．Ｄが、幹事であるユーザＡ．Ａに対して、リアルタイム均等額「４，０００円」を支払ったことに関する情報が含まれる。
また、コンテンツ情報ＣＴ２２は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、更新された現在の均等額（「４，０００円」）と、わりかん残額（「８，０００円」）とに関する情報が含まれる。

【0755】

なお、リアルタイム均等額が更新後に変化していない場合、限定ではなく例として、コンテンツ情報ＣＴ２２が表示されないようにしてもよい。

【0756】

その後、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い金額「６，０００円」を送金すると、限定ではなく例として、図１５－２右側のトークルーム画面に表示が遷移する。

【0757】

この例では、コンテンツ表示領域のコンテンツ情報ＣＴ２２の下には、コンテンツ情報ＣＴ２３～コンテンツ情報ＣＴ２５などが表示されている。
コンテンツ情報ＣＴ２３は、送信元がユーザＢ．Ｂであるコンテンツ情報であって、ユーザＢ．Ｂが、幹事であるユーザＡ．Ａに対して、支払い予定額「６，０００円」を支払うことに関する情報等が含まれる。
また、コンテンツ情報ＣＴ２４は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、最終的なリアルタイム均等額（「３，０００円」）と、わりかんリクエストが完了したこととに関する情報が含まれる。
また、コンテンツ情報ＣＴ２５は、送信元が支払いアプリケーション（ＯＡ）であるコンテンツ情報であって、第２種ユーザとなったユーザＤ．Ｄに対して、返金金額「１，０００円」を返金したことに関する情報が含まれる。

【0758】

なお、返金したことに関する情報（この例では、コンテンツ情報ＣＴ２５）は、グループトークルーム内に表示されず、返金対象となったユーザ（この例では、ユーザＤ．Ｄ）と、Ｐａｙｍｅｎｔ ＡｐｐとのＯＡトークルーム内に表示されるようにしてもよい。

【0759】

本実施例は、サーバ１０は、第３端末に返金に関する返金通知を通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第３端末に返金に関する情報を通知することができる。

【0760】

また、この場合、返金通知は、第３端末のメンバーを含むトークルーム（限定ではなく、チャットルームの一例）に送信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、チャットルームを用いて返金に関する情報を通知することによって、返金に関する情報を第３端末のユーザにより一層認知させることができる。

【0761】

また、この場合、トークルームは、マスター（限定ではなく、第１端末のユーザの一例）と、第２端末のメンバーと、第４端末のメンバーとを含むようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末のユーザと、第２端末のユーザと、第４端末のユーザとに、返金に関する情報を通知することができる。

【0762】

＜第１６実施例＞
第１６実施例は、端末２０における送金依頼に基づく送金に際した、端末２０の表示画面のユーザインタフェース（ＵＩ）に関する実施例である。

【0763】

本実施例で説明するＵＩは、前述したわりかんを行う場合における端末２０の表示画面に適用可能であるが、必ずしもこれに限定されず、これら以外のケースの送金に対しても同様に適用可能である。つまり、わりかん以外のケースで送金依頼主（限定ではなく、第１端末のユーザの一例）から送金を依頼されたユーザが送金を行う場合等に対しても、これらのＵＩを同様に適用可能である。
第１６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0764】

＜表示画面＞
図１６－１～図１６－３は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。

【0765】

図１６－１左側の表示画面については、前述した図１－９左側と同様であるので説明を省略する。

【0766】

限定ではなく例として、送金機能ボタンＭＢＴ２がユーザによってタップされると、限定ではなく例として、図１６－１右側の画面に表示が遷移する。
この送金設定画面では、限定ではなく例として、本端末から別の端末に送金するため送金画面、または別の端末から本端末に送金してもらうために送金リクエストを行うための送金リクエスト画面を切り替えるための送金種別切替領域と、送金金額を入力するための送金金額入力領域ＳＡＲ３とが表示されるように構成されている。

【0767】

限定ではなく例として、ユーザが送金種別切替領域の「送金リクエスト」ボタンをタップした後に、送金金額入力領域ＳＡＲ３をタップすると、限定ではなく例として、送金設定画面にテンキー入力領域が表示され、送金依頼金額を指定するように構成することができる。この画面では、送金金額入力領域ＳＡＲ３には、送金依頼金額として「４，０００円」が入力された状態が示されている。

【0768】

限定ではなく例として、画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、端末２０Ａからサーバ１０に送金リクエストの入力内容に基づく送金要求情報が送信される。

【0769】

図１６－２左側には、この場合における端末２０Ｂのお知らせ画面の一例を示している。図１６－２左側の表示画面については、前述した図１－１０左側と同様であるので説明を省略する。

【0770】

限定ではなく例として、「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１６－２中央の送金画面に表示が遷移する。図１６－２中央の表示画面については、前述した図１－１０中央と同様であるので説明を省略する。

【0771】

限定ではなく例として、送金額増額ボタンＡＩＢ１がユーザによってタップされると、限定ではなく例として、図１６－２右側の送金画面に表示が遷移する。
この画面では、送金金額指定領域ＲＡＲ１右部に、送金金額を増額させるための「増額」ボタン（本例では、上向き三角形のオブジェクト）ＩＢＴと、送金金額を減額させるための「減額」ボタン（本例では、下向き三角形のオブジェクト）ＲＢＴとが表示されている。

【0772】

また、この画面では、送金金額指定領域ＲＡＲ１に増額前の「４，０００」円が入力されていることに基づいて、「減額」ボタンＲＢＴはグレーアウトの表示態様で表示され、機能が無効化されている。つまり、この例では、ユーザＡ．Ａから送金依頼された金額が「４，０００円」であることに基づき、送金金額をこれよりも低い金額とすることができないようになっている。「増額」ボタンＩＢＴの画像は、送金依頼された金額を増額させるための画像の一例としてよく、「減額」ボタンＲＢＴの画像は、送金依頼された金額を減額させるための第２画像の一例としてよい。

【0773】

なお、概念としては、端末２０は、送金依頼された金額以下の金額が入力された場合、第２画像の表示態様を変更する制御を行うこととしてもよく、必ずしも第２画像は「減額」ボタンＲＢＴの画像とすることに限定されない。

【0774】

限定ではなく例として、送金金額指定領域ＲＡＲ１右部の「増額」ボタンＩＢＴがユーザによってタップされると、限定ではなく例として、図１６－３左側の送金画面に表示が遷移する。この画面では、送金金額指定領域ＲＡＲ１には、「１０，０００円」が送金金額として指定されたことが表示されている。つまり、この例では、「増額」ボタンＩＢＴの操作によって、ユーザＢ．Ｂによって送金依頼金額よりも多い金額が指定された状態が示されている。この状態で、送金金額指定領域ＲＡＲ１下部の「確定」ボタンがタップされると、限定ではなく例として、図１６－３右側の送金結果画面に表示が遷移する。

【0775】

この送金結果画面では、ユーザＢ．ＢがユーザＡ．Ａに送金リクエストされた金額より増額した金額「１０，０００円」を送金したことが表示されている。

【0776】

本実施例では、このように、送金依頼主のユーザ（限定ではなく例として、ユーザＡ．Ａ）からの送金リクエストに基づき、送金を依頼されたユーザ（限定ではなく例として、ユーザＢ．Ｂ）が、送金リクエストの送金依頼金額よりも多い金額を送金依頼主に送金することができるように構成されている。

【0777】

このような構成は、限定ではなく例として、前述したわりかんの実施例において、限定ではなく例として、ユーザが均等額より多い金額を指定する場合等に適用可能である。
限定ではなく例として、図７－３中央の画面、図９－４左側の画面、図１１－３中央の画面、図１１－４中央の画面、図１１－７中央の画面、図１２－２中央の画面、図１２－３中央の画面、図１２－４中央の画面、図１３－１中央の画面、図１３－２左側の画面、図１３－３左側の画面、図１４－４左側の画面等の画面において、限定ではなく例として、送金金額指定領域ＲＡＲ１に、上記の「増額」ボタンＩＢＴや「減額」ボタンＲＢＴ等を表示させるようにしてもよい。

【0778】

なお、図１６－２右側の画面に示したような、「減額」ボタンＲＢＴの画像等の第２画像の表示態様を変更する内容は、前述したわりかんの例において、限定ではなく例として、均等額よりも低い金額をユーザに入力させないようにするケース（均等額以上や均等額よりも多い金額を支払うわりかんメンバーを指定するケースなどを含む。）に適用可能である。
限定ではなく例として、サーバ１０から送信された均等額以上送金依頼情報を受信した端末２０の制御部２１が、第２画像の表示態様を変更する制御を行うようにするなどしてもよい。

【0779】

なお、これとは逆に、均等額よりも多い金額をユーザに入力させないようにするケースにおいて、端末２０の制御部２１が、「増額」ボタンＩＢＴの画像等の第１画像の表示態様を変更するようにしてもよい。

【0780】

＜第１６実施例の効果＞
本実施例は、端末２０が、送金依頼主の端末２０（限定ではなく、第１端末の一例）から送信された送金リクエストに基づく送金リクエスト情報（限定ではなく、送金依頼情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示（限定ではなく、多く支払うボタンや「増額」ボタン等）とを、送金リクエスト情報に基づき表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0781】

なお、送金リクエスト情報の受信には、送金依頼主の端末２０からサーバ１０を介して受信される場合の他、送金依頼主の端末２０から直接的に受信されることを含めてもよい。
また、送金依頼主の端末２０から送信された送金リクエスト情報が、別の端末２０を介して、自己の端末２０で受信されることを含めてもよい。

【0782】

また、この場合、送金リクエストは、自己の端末２０のユーザを含む複数のユーザに送信されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、より多くのユーザが、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0783】

また、この場合、端末２０は、送金依頼金額を増額させることに関する第２表示に対する自己の端末２０のユーザの入力に基づいて、送金依頼金額を増額させる処理を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザの入力に基づいて送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0784】

本実施例は、端末２０が、送金依頼主の端末２０（限定ではなく、第１端末の一例）から送信された送金リクエストに基づく送金リクエスト情報（限定ではなく、送金依頼情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示とを、送金リクエスト情報に基づき表示部２４に表示する。この場合、第２表示は、送金依頼金額を増額させるための第１画像（限定ではなく、上向き三角形のオブジェクトで示される「増額」ボタンＩＢＴの画像等）と、送金依頼金額を減額させるための第２画像（限定ではなく、下向き三角形のオブジェクトで示される「減額」ボタンＲＢＴの画像等）とを含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１画像や第２画像を用いることによって、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0785】

また、この場合、端末２０は、送金依頼金額以下の金額が入力された場合、第２画像の表示態様を変更する制御を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、送金依頼された金額以下の金額が入力されていることをユーザに明確に示すことができる。

【0786】

＜第１６変形例（１）＞
上記の実施例では、送金金額指定領域ＲＡＲ１の金額が送金依頼金額以下である場合、「減額」ボタンが無効化されることとしたが、これに限定されない。
限定ではなく例として、送金金額指定領域ＲＡＲ１に送金依頼金額より少ない金額が入力（設定）され、送金金額指定領域ＲＡＲ１下部の「確定」ボタンがタップされると、限定ではなく例として、「金額を上げてください」というメッセージやエラー表示が表示され、再度送金金額の指定画面に表示が遷移するようにしてもよい。

【0787】

本変形例は、送金依頼金額を増額させることに関する第２表示は、自己の端末２０のユーザの入力によって、送金依頼金額を減額させるための情報を含む。そして、端末２０は、自己の端末２０のユーザによる、第２表示に対する入力によって、送金依頼金額よりも低い金額が入力された場合、金額を上げさせるメッセージやエラー表示等の表示を表示部２４に表示する構成を示している。
このような構成により得られる変形例の効果の一例として、送金依頼された金額よりも低い金額が入力された場合、送金できないことをユーザにより一層明確に示すことができる。

【0788】

＜第１７実施例＞
第１７実施例は、第１６実施例に関連し、端末２０において送金依頼金額を増加させるＵＩに関する実施例である。
本実施例で説明するＵＩは、第１６実施例と同様に、前述したわりかんを行う場合における端末２０の表示画面に適用可能であるが、必ずしもこれに限定されず、これら以外のケースの送金に対しても同様に適用可能である。つまり、わりかん以外のケースで送金依頼主（限定ではなく、第１端末のユーザの一例）から送金を依頼されたユーザが送金を行う場合等に対しても、これらのＵＩを同様に適用可能である。
第１７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。

【0789】

＜表示画面＞
図１７－１～図１７－３は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。ここでは、前述したわりかんを行う場合の端末２０の表示部２４に表示される表示画面を例示して説明する。

【0790】

図１７－１左側の表示画面については、前述した図２－３左側と同様であるので説明を省略する。

【0791】

限定ではなく例として、「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１７－１中央の送金画面に表示が遷移する。図１７－１中央の表示画面については、前述した図２－３中央と同様である部分についての説明を省略する。

【0792】

この例では、送金金額指定領域ＲＡＲ１の下には、送金予定金額を「１００円」増額するための「＋１００」ボタンＰＢＴ１と、送金予定金額を「１，０００円」増額するための「＋１，０００」ボタンＰＢＴ２と、送金予定金額を「１０，０００円」増額するための「＋１０，０００」ボタンＰＢＴ３とが表示されている。以下では、これらのボタンを、適宜「金額別増額ボタン」と称する。

【0793】

その下には、送金予定金額を最初に指定されていた金額に戻すための「元に戻す」ボタンが表示されている。
この「元に戻す」ボタンは、送金金額指定領域ＲＡＲ１に送金依頼金額である「５，０００円」が入力されていることに基づいて、限定ではなく例として、操作を受け付けていないことを示す第２態様（本例では、ハッチング処理されている態様）で表示されている。つまり、この例では、ユーザＡ．Ａから送金依頼された金額（画面図では、わりかんリクエストとして送金依頼された金額）が「５，０００円」であることに基づき、送金金額をこれよりも低い金額とすることができないようになっている。「＋１００」ボタンＰＢＴ１、「＋１，０００」ボタンＰＢＴ２、「＋１０，０００」ボタンＰＢＴ３のうち、一のボタンの画像は第１金額を増額させるための第３画像の一例としてよく、他のボタンの画像は第２金額を増額させるための第４画像の一例としてよい。

【0794】

限定ではなく例として、「＋１，０００」ボタンＰＢＴ２がユーザによって５回タップされると、限定ではなく例として、図１７－１右側のような表示となる。図１７－１右側の表示画面については、前述した図１７－１中央と同様である部分についての説明を省略する。

【0795】

この例では、送金金額指定領域ＲＡＲ１に、「５，０００円」＋「１，０００円」×５＝「１０，０００円」が送金予定金額として入力（指定）されたことが表示されている。

【0796】

このとき、限定ではなく例として、送金予定金額がわりかん総額「２０，０００円」の５０％以上となったことに基づいて、送金予定金額をこれ以上増額できないことをユーザに示すために、この例では、金額別増額ボタンが、限定ではなく例として、操作を受け付けていないことを示す第２態様（本例では、ハッチング処理されている態様）で表示されている。
また、「元に戻す」ボタンは、限定ではなく例として、操作を受け付けていることを示す第１態様（本例では、ハッチング処理されていない態様）で表示されている。

【0797】

なお、金額別増額ボタンが無効化される送金予定金額または第１種の各ユーザがわりかん総額に対して負担可能な割合は、限定ではなく例として、わりかん要求情報送信時に幹事の端末２０Ａによって指定可能であるようにしてもよい。

【0798】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１７－２左側の送金結果画面に表示が遷移する。図１７－２左側の表示画面については、前述した図２－４左側と同様であるので説明を省略する。

【0799】

次いで、限定ではなく例として、サーバ１０から、第１種ユーザのうち二番目に支払いを行うこととなっているユーザＢ．Ｂの端末２０Ｂに対して、支払いに関するお知らせ情報が送信される。

【0800】

図１７－２中央には、端末２０Ｂの表示部２４に表示されるお知らせ画面の一例を示している。この表示画面については、前述した図２－４中央と同様であるので説明を省略する。

【0801】

限定ではなく例として、「詳細を確認」ボタンがユーザによってタップされると、限定ではなく例として、図１７－２右側の送金画面に表示が遷移する。図１７－２右側の表示画面については、前述した図１７－１中央と同様であるので説明を省略する。なお、この表示画面では、画面最上部に、ユーザＢ．Ｂの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0802】

限定ではなく例として、「＋１，０００」ボタンＰＢＴ２がユーザによって３回タップされると、限定ではなく例として、図１７－３左側のような表示となる。図１７－３左側の表示画面については、前述した図１７－１中央と同様である部分についての説明を省略する。

【0803】

この例では、送金金額指定領域ＲＡＲ１に、「５，０００円」＋「１，０００円」×３＝「８，０００円」が送金予定金額として入力（指定）されたことが表示されている。

【0804】

このとき、限定ではなく例として、第１種メンバーの送金予定金額の合計がわりかん総額「２０，０００円」の９０％以上となったことに基づいて、送金予定金額をこれ以上増額できないことをユーザに示すために、この例では、金額別増額ボタンが、限定ではなく例として、操作を受け付けていないことを示す第２態様（本例では、ハッチング処理されている態様）で表示されている。
また、「元に戻す」ボタンは、限定ではなく例として、操作を受け付けていることを示す第１態様（本例では、ハッチング処理されていない態様）で表示されている。

【0805】

なお、金額別増額ボタンが無効化される、第１種のユーザが合計で支払い可能な金額（わりかん総額に対する割合）は、限定ではなく例として、わりかん要求情報送信時に幹事の端末２０Ａによって指定可能であるようにしてもよい。

【0806】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされると、限定ではなく例として、図１７－３中央の送金結果画面に表示が遷移する。図１７－３中央の表示画面については、前述した図２－５中央と同様であるので説明を省略する。

【0807】

限定ではなく例として、第１種ユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ）によって支払い予定金額が送信されると、限定ではなく例として、サーバ１０から、幹事であるユーザＡ．Ａの端末２０Ａに対して、第１種ユーザによる支払い金額や、この支払い金額に基づく第２種ユーザのわりかん金額に関するお知らせ情報が送信される。

【0808】

図１７－３右側には、この場合における第２種の端末２０Ａのお知らせ画面の一例を示している。図１７－３右側の表示画面については、前述した図２－５右側と同様であるので説明を省略する。

【0809】

本実施例では、第１６実施例と同様に、送金依頼主のユーザ（限定ではなく例として、ユーザＡ．Ａ）からの送金リクエストに基づき、送金を依頼されたユーザ（限定ではなく例として、ユーザＢ．Ｂ）が、送金依頼金額よりも多い金額を送金依頼主に送金することができるように構成されている。

【0810】

限定ではなく例として、図７－３中央の画面、図９－４左側の画面、図１１－３中央の画面、図１１－４中央の画面、図１１－７中央の画面、図１２－２中央の画面、図１２－３中央の画面、図１２－４中央の画面、図１３－１中央の画面、図１３－２左側の画面、図１３－３左側の画面、図１４－４左側の画面等の画面において、限定ではなく例として、送金金額指定領域の下などの位置に、「＋１００」ボタンＰＢＴ１、「＋１，０００」ボタンＰＢＴ２、「＋１０，０００」ボタンＰＢＴ３等を表示させるようにしてもよい。

【0811】

なお、これらのボタン等の画像は、第１６実施例と同様に、前述したわりかんの例において、限定ではなく例として、均等額よりも低い金額をユーザに入力させないようにするケースに適用可能である。

【0812】

なお、これとは逆に、均等額よりも多い金額をユーザに入力させないようにするケースにおいて、端末２０の制御部２１が、「－１００」ボタン、「－１０００」ボタン、「－１００００」ボタン等の画像を表示する制御を行うようにしてもよい。

【0813】

＜第１７実施例の効果＞
本実施例は、端末２０が、第１端末から送信された送金リクエストに基づく送金リクエスト情報（限定ではなく、送金依頼情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、送金依頼金額の情報を含む第１表示と、送金依頼金額を増額させることに関する第２表示とを、送金リクエスト情報に基づき表示部２４に表示する。
また、端末２０は、送金依頼金額を増額させることに関する第２表示に対する自己の端末２０のユーザの入力に基づいて、送金依頼金額を増額させる処理を制御部２１によって行う。
そして、送金依頼金額を増額させることに関する第２表示は、第１金額（限定ではなく例として、１，０００円）を増額させるための「＋１，０００」ボタンＰＢＴ２の画像等の画像（限定ではなく、第３画像の一例）と、第２金額（限定ではなく例として、１０，０００円）を増額させるための「＋１０，０００」ボタンＰＢＴ３の画像等の画像（限定ではなく、第４画像の一例）とを含む構成を示している。
このような構成により得られる実施例の効果の一例として、第３画像や第４画像を用いることによって、送金依頼された金額を容易に増減させることができ、送金に関する利便性を向上できる。

【0814】

また、この場合、端末２０は、送金リクエストに基づき、送金の上限金額を設定する処理を制御部２１によって行うようにしてもよい。
このような構成により得られる実施例の効果の一例として、送金の上限金額が設定されることによって、適切な金額内で任意の金額を送金することができる。

【0815】

また、この場合、上限金額は、マスター（限定ではなく、第１端末のユーザの一例）によって設定されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１端末のユーザが送金の上限金額を自由に設定できるようにすることができる。

【0816】

また、この場合、送金リクエストは、端末２０のユーザを含む複数のユーザに送信され、上限金額は、複数のユーザによって支払われた金額、または支払われる予定の金額によって変更されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、端末のユーザを含む複数のユーザに送信された送金リクエストに基づき、それら複数のユーザによって支払われた金額、または支払われる予定の金額によって、送金の上限金額が適切に変更されるようにすることができる。

【0817】

＜第１７変形例（１）＞
端末２０において、送金依頼情報の送信後、追加して送金が可能であるようにしてもよい。

【0818】

図１７－４は、本変形例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。図１７－１～図１７－３と同様に、前述したわりかんを行う場合の端末２０の表示部２４に表示される表示画面例として図示・説明する。

【0819】

図１７－４左側の表示画面については、前述した図１７－２左側と同様である部分についての説明を省略する。

【0820】

この例では、送金結果画面の画面中央下部には、追加で送金するための「追加送金」ボタンＡＲＢＴが表示されている。「追加送金」ボタンＡＲＢＴがユーザによってタップされると、限定ではなく例として、図１７－４中央の送金画面に表示が遷移する。

【0821】

図１７－４中央の表示画面については、前述した図１６－２右側と同様である部分についての説明を省略する。なお、この表示画面では、画面最上部に、ユーザＣ．Ｃの支払いアプリケーションにおけるアイコン画像およびユーザ名が表示されている。

【0822】

この例では、送金金額指定領域ＲＡＲ１右部の「増額」ボタンＩＢＴがユーザによってタップされたことに基づいて、送金金額指定領域ＲＡＲ１には、「２，０００円」が追加の送金金額として指定されたことが表示されている。
また、送金先指定領域の下には、わりかん総額「２０，０００円」とわりかん人数「４人」に加えて、送金済み金額「１０，０００円」が表示されている。

【0823】

限定ではなく例として、送金画面最下部の「決定」ボタンがユーザによってタップされ、限定ではなく例として、第１種ユーザのうち一番目に支払いを行うこととなっているユーザＣ．Ｃによって追加の支払い予定金額が送信されると、限定ではなく例として、サーバ１０から、第１種ユーザのうち二番目に支払いを行うこととなっているユーザＢ．Ｂの端末２０Ｂに対して、支払いに関するお知らせ情報が送信される。

【0824】

図１７－４右側には、この場合における第１種の端末２０Ｂのお知らせ画面の一例を示している。図１７－４右側の表示画面については、前述した図１７－２中央と同様である部分についての説明を省略する。

【0825】

この例では、お知らせ情報ＮＴ１９～ＮＴ２０が上から順に表示されている。
お知らせ情報ＮＴ１９には、第１種ユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い額（「１０，０００円」）を支払うことに関する情報が含まれる。
また、お知らせ情報ＮＴ２０には、第１種ユーザであるユーザＣ．Ｃが、幹事であるユーザＡ．Ａに対して、支払い額（「２，０００円」）を追加で支払うことに関する情報が含まれる。

【0826】

本変形例は、端末２０が、送金リクエストに基づく送金処理を制御部２１によって行う。そして、端末２０は、送金処理に基づき、マスターの端末２０に送金することを示す第３表示（限定ではなく例として、追加で送金することを示す表示）を表示部２４に表示するようにしてもよい。
このような構成により得られる変形例の効果の一例として、第３表示を用いて、限定ではなく例として、第１端末に追加で送金するなどすることができ、送金に関する利便性を向上できる。

【0827】

＜その他＞
第１６実施例や第１７実施例で説明したＵＩに関する内容と、第１実施例～第１５実施例で説明した内容とは、適宜組み合わせることが可能である。以下、その一例について説明する。

【0828】

限定ではなく例として、第２実施例等と同様に、端末２０が、送金リクエストに基づき、送金の上限金額を設定する処理を制御部２１によって行うとする内容を適用してもよい。

【0829】

また、第２実施例等と同様に、送金の上限金額が、送金依頼主（限定ではなく、第１端末のユーザの一例）によって設定されるとする内容を適用してもよい。

【0830】

また、第２実施例等と同様に、送金リクエストは、一のユーザを含む複数のユーザに送信され、送金の上限金額は、複数のユーザによって支払われた金額、または支払われる予定の金額によって変更されるとする内容を適用してもよい。

【0831】

また、第６実施例等と同様に、送金リクエスト情報は、送金依頼主（限定ではなく、第１端末のユーザの一例）と、複数のユーザとを含むメッセージングアプリケーション（限定ではなく、チャットアプリケーションの一例）のトークルーム（限定ではなく、チャットルームの一例）に送信され、このトークルームが端末２０の表示部２４に表示されるとする内容を適用してもよい。

【0832】

また、第６実施例等と同様に、端末２０が、自己の端末２０のユーザによって、第２表示に対する入力が行われ、送金依頼金額よりも高い金額の送金が行われた場合、トークルームを表示する制御を制御部２１によって行うとする内容を適用してもよい。

【0833】

また、第６実施例等と同様に、端末２０が、端末２０のユーザによって、第２表示に対する入力が行われ、送金依頼金額よりも高い金額の送金が行われた場合、トークルームに第４画像（限定ではなく例として、盛り上げ機能の画像等）を表示する制御を制御部２１によって行うとする内容を適用してもよい。

【0834】

また、第６実施例等と同様に、端末２０が、送金依頼主（限定ではなく、第１端末のユーザの一例）によって、第４画像に対する入力が行われた場合、この第４画像に対するリアクションを示す第５画像（限定ではなく例として、送金依頼主による盛り上げに対する自分のリアクションを示す画像等）をトークルームに表示する制御を制御部２１によって行うとする内容を適用してもよい。

【0835】

また、第６実施例等と同様に、送金リクエスト情報は、送金依頼主の端末２０と通信するサーバ１０を介して端末２０に受信されるとする内容を適用してもよい。

【0836】

また、上記の実施例において、各種のアプリケーションを配信する用のサーバ（端末２０がアプリケーションをダウンロードするサーバ）を、サーバ１０等とは異なるサーバとして構成してもよい。つまり、アプリケーションを配信する用のサーバと、上記の実施例等で説明したアプリケーション管理処理等を行うサーバ等とを物理的に分離されたサーバとして構成してもよいし、１つのサーバとして構成してもよい。

【0837】

また、アプリケーションには、各種のアプリケーションのプログラムに限らず、限定ではなく例として、おおもととなるアプリケーションの一機能として他のサービスの機能を持たせるためのプログラム（限定ではなく例として、メッセージングアプリケーションの一機能として支払いサービスの機能を持たせるためのプログラム、またはその逆）や、おおもととなるアプリケーションのアップデート用のプログラム等を含めてもよい。また、アプリケーションプログラムで活用されるデータ（アプリケーションのアップデート用のデータ等も含めてもよい。）を含めてもよい。

【0838】

また、上記の実施例では、限定ではなく例として、本発明をクライアントサーバシステムによって実現する手法を説明したが、これに限定されない。前述したように、分散システムなど、サーバやサーバシステムの機能を端末２０に持たせるシステムによって実現してもよい。限定ではなく例として、上記の実施例で説明したフローチャートで、サーバやサーバシステムが行うこととして説明した処理を、端末が行うようにしてもよい。

【符号の説明】

【0839】

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

【図1-1】

【図1-2】

【図1-3】

【図1-4】

【図1-5】

【図1-6】

【図1-7】

【図1-8】

【図1-9】

【図1-10】

【図1-11】

【図1-12】

【図1-13】

【図1-14】

【図1-15】

【図1-16】

【図1-17】

【図2-1】

【図2-2】

【図2-3】

【図2-4】

【図2-5】

【図2-6】

【図2-7】

【図2-8】

【図2-9】

【図3-1】

【図3-2】

【図3-3】

【図3-4】

【図3-5】

【図3-6】

【図3-7】

【図3-8】

【図4-1】

【図4-2】

【図4-3】

【図4-4】

【図4-5】

【図5-1】

【図5-2】

【図6-1】

【図6-2】

【図6-3】

【図6-4】

【図7-1】

【図7-2】

【図7-3】

【図7-4】

【図7-5】

【図7-6】

【図7-7】

【図7-8】

【図7-9】

【図7-10】

【図8-1】

【図8-2】

【図8-3】

【図8-4】

【図8-5】

【図9-1】

【図9-2】

【図9-3】

【図9-4】

【図10-1】

【図10-2】

【図11-1】

【図11-2】

【図11-3】

【図11-4】

【図11-5】

【図11-6】

【図11-7】

【図12-1】

【図12-2】

【図12-3】

【図12-4】

【図12-5】

【図12-6】

【図12-7】

【図12-8】

【図13-1】

【図13-2】

【図13-3】

【図14-1】

【図14-2】

【図14-3】

【図14-4】

【図15-1】

【図15-2】

【図16-1】

【図16-2】

【図16-3】

【図17-1】

【図17-2】

【図17-3】

【図17-4】