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

Description

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

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

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

本発明の第１の態様によると、決済に関する処理を実行する端末に実行させるためのプログラムは、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済に関する第１決済情報を端末の通信部によって送信することと、第１決済情報と、端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、端末のユーザが送金、または受け取る第１金額と、異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理を端末の制御部によって行うこととが端末によって実行される。
本発明の第２の態様によると、決済に関する処理を実行する端末の情報処理方法は、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済に関する第１決済情報を端末の通信部によって送信することと、第１決済情報と、端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、端末のユーザが送金、または受け取る第１金額と、異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理を端末の制御部によって行うこととを含む。
本発明の第３の態様によると、決済に関する処理を実行する端末は、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済に関する第１決済情報を送信し、第１決済情報と、端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、端末のユーザが送金、または受け取る第１金額と、異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を受信する通信部と、第１金額に基づく送金処理、または受取処理を行う制御部とを備える。
本発明の第４の態様によると、決済に関する処理を実行する端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済に関する第１決済情報を端末の通信部によって送信することと、第１決済情報と、端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、端末のユーザが送金、または受け取る第１金額と、異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理とを実行する。
本発明の第５の態様によると、決済に関する処理を実行する端末に実行させるためのプログラムは、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済の決済履歴である第１決済情報を端末の通信部によって送信することと、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理を端末の制御部によって行うこととが端末によって実行される。
本発明の第６の態様によると、決済に関する処理を実行する端末の情報処理方法は、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済の決済履歴である第１決済情報を端末の通信部によって送信することと、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理を端末の制御部によって行うこととを含む。
本発明の第７の態様によると、決済に関する処理を実行する端末は、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済の決済履歴である第１決済情報を送信し、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を受信する通信部と、第１金額に基づく送金処理、または受取処理を行う制御部とを備える。
本発明の第８の態様によると、決済に関する処理を実行する端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、端末のユーザによる端末に対する入力に基づいて、端末のユーザによる第１決済の決済履歴である第１決済情報を端末の通信部によって送信することと、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の情報を通信部によって受信することと、第１金額に基づく送金処理、または受取処理とを実行する。

第１実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例における通信システムの構成の一例を示す図。 第２実施例におけるサーバの制御部によって実現される機能の一例を示す図。 第２実施例におけるサーバの記憶部に記憶される情報の一例を示す図。 第２実施例における支払いアプリケーションユーザ登録データの一例を示す図。 第２実施例におけるユーザ管理データベースの一例を示す図。 第２実施例における端末の制御部によって実現される機能の一例を示す図。 第２実施例における端末の記憶部に記憶される情報の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における端末の表示部に表示される画面の一例を示す図。 第２実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例における第１の割り勘承認管理処理の流れの一例を示すフローチャート。 第２変形例におけるユーザ管理データベースの一例を示す図。 第２変形例における端末の表示部に表示される画面の一例を示す図。 第２変形例における端末の表示部に表示される画面の一例を示す図。 第２変形例における各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３実施例における端末の表示部に表示される画面の一例を示す図。 第３変形例における各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例における端末の表示部に表示される画面の一例を示す図。 第４実施例における端末の表示部に表示される画面の一例を示す図。 第４実施例における端末の表示部に表示される画面の一例を示す図。 第４実施例における端末の表示部に表示される画面の一例を示す図。 第４実施例における端末の表示部に表示される画面の一例を示す図。 第４実施例におけるサーバの記憶部に記憶される情報の一例を示す図。 第４実施例における割り勘管理データベースの一例を示す図。 第４実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例における割り勘追加登録処理の流れの一例を示すフローチャート。 第４実施例における第２の割り勘承認管理処理の流れの一例を示すフローチャート。 第４変形例における端末の表示部に表示される画面の一例を示す図。 第４変形例における端末の表示部に表示される画面の一例を示す図。 第５実施例における通信システムの構成の一例を示す図。 第５実施例における端末の表示部に表示される画面の一例を示す図。 第５実施例における端末の表示部に表示される画面の一例を示す図。 第５実施例における端末の表示部に表示される画面の一例を示す図。 第５実施例における端末の表示部に表示される画面の一例を示す図。 第５実施例におけるメッセージングサーバの制御部によって実現される機能の一例を示す図。 第５実施例におけるメッセージングサーバの記憶部に記憶される情報の一例を示す図。 第５実施例におけるメッセージングアプリケーションユーザ登録データの一例を示す図。 第５実施例における割り勘管理データベースの一例を示す図。 第５実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例におけるＭＳＧ割り勘承認管理処理の流れの一例を示すフローチャート。 第５変形例における端末の表示部に表示される画面の一例を示す図。 第５変形例における端末の表示部に表示される画面の一例を示す図。 第５変形例における端末の表示部に表示される画面の一例を示す図。 第５変形例における端末の表示部に表示される画面の一例を示す図。 第６実施例における端末の表示部に表示される画面の一例を示す図。 第６実施例における端末の表示部に表示される画面の一例を示す図。 第６実施例における端末の表示部に表示される画面の一例を示す図。 第６実施例におけるメッセージングサーバの記憶部に記憶される情報の一例を示す図。 第６実施例における割り勘管理データベースの一例を示す図。 第６実施例におけるグループ管理データベースの一例を示す図。 第６実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第６変形例における端末の表示部に表示される画面の一例を示す図。 第７実施例における端末の表示部に表示される画面の一例を示す図。 第７実施例における端末の表示部に表示される画面の一例を示す図。 第７実施例における端末の表示部に表示される画面の一例を示す図。 第８実施例における端末の表示部に表示される画面の一例を示す図。 第８実施例における端末の表示部に表示される画面の一例を示す図。 第８実施例におけるユーザ管理データベースの一例を示す図。 第８実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第８変形例における端末の表示部に表示される画面の一例を示す図。 第８変形例における端末の表示部に表示される画面の一例を示す図。 第８変形例における各装置が実行する処理の流れの一例を示すフローチャート。 第９実施例における端末の表示部に表示される画面の一例を示す図。 第９実施例における端末の表示部に表示される画面の一例を示す図。 第１０実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１１実施例における端末の表示部に表示される画面の一例を示す図。 第１１実施例における端末の表示部に表示される画面の一例を示す図。 第１２実施例における端末の表示部に表示される画面の一例を示す図。 第１２実施例における端末の表示部に表示される画面の一例を示す図。 第１２実施例における端末の表示部に表示される画面の一例を示す図。 第１２実施例における端末の表示部に表示される画面の一例を示す図。 第１３実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１３実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１４実施例における端末の表示部に表示される画面の一例を示す図。 第１４実施例における端末の表示部に表示される画面の一例を示す図。 第１４実施例における端末の表示部に表示される画面の一例を示す図。 第１４実施例におけるサーバの記憶部に記憶される情報の一例を示す図。 第１４実施例における割り勘管理データベースの一例を示す図。 第１４実施例における買い物細目管理データベースの一例を示す図。 第１４実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１４変形例における端末の表示部に表示される画面の一例を示す図。 第１４変形例における端末の表示部に表示される画面の一例を示す図。 第１４変形例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における端末の表示部に表示される画面の一例を示す図。 第１５実施例における割り勘管理データベースの一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１６実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における端末の表示部に表示される画面の一例を示す図。 第１７実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１７実施例における割り勘修正処理の流れの一例を示すフローチャート。 第１７実施例における第３の割り勘承認管理処理の流れの一例を示すフローチャート。 第１７変形例における過不足金額変動を説明するための図。 第１７変形例における割り勘修正確認通知送信要否を説明するための図。 第１８実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１８実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第１９実施例における各装置が実行する処理の流れの一例を示すフローチャート。 第２０実施例における端末からサーバに送信する割り勘精算通知を説明するための図。 第２１実施例における端末の表示部に表示される画面の一例を示す図。 第２１実施例における端末の表示部に表示される画面の一例を示す図。 第２１実施例における端末の表示部に表示される画面の一例を示す図。 第２１実施例における端末の表示部に表示される画面の一例を示す図。 第２１実施例における端末の表示部に表示される画面の一例を示す図。 第２２実施例における端末の表示部に表示される画面の一例を示す図。 第２２実施例における端末の表示部に表示される画面の一例を示す図。 第２２実施例における端末の表示部に表示される画面の一例を示す図。 第２２実施例における端末の表示部に表示される画面の一例を示す図。 第２２実施例における端末の表示部に表示される画面の一例を示す図。

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

本開示に係るプログラム、情報処理方法、端末、サーバ等を実施するための実施形態について、図面を参照して説明する。

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

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

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

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

また、本明細書において、「決済」とは、電子的な決済（電子決済）のことを意味する。この一例は、上記の電子貨幣を用いた電子決済である。
以下の実施例では、この決済の一種として「買い物決済」を例示する。買い物決済は、商品の購入やサービスの提供等の対価としての支払いを行うための決済であり、端末２０のユーザによる決済（端末２０のユーザによって行われた決済）の一例である。
また、買い物決済履歴は、端末２０のユーザによる決済に関する処理（上記の端末２０のユーザによる決済について端末２０によって実行された処理）に基づく決済情報の一例である。

「決済に関する処理」とは、限定ではなく例として、端末２０が実行する買い物決済に関する処理であって、買い物決済を行うためのコード情報をサーバ等から取得する処理（コード情報の生成をサーバ等に依頼する処理や、生成されたコード情報をサーバ等から受信する処理を含む。）、取得したコード情報を表示する処理、買い物決済の決済結果（決済通知を含む。）をサーバ等から取得する処理などの、買い物決済を行う上で何らかの関連のある処理、より具体的には、買い物決済を行う上で関連のある処理として端末２０で実行される処理全般を含むものである。
「コード情報」とは、コード画像や、コード画像に格納される情報（格納情報、エンコード情報）を含むものである。

また、本明細書において、「割り勘」とは、１または複数の買い物決済履歴に基づく支払い済み金額を、複数の端末２０のユーザで負担することを意味する。
また、本明細書における割り勘は、必ずしも複数の端末２０のユーザで金額を等分することに限らず、複数の端末２０のユーザで金額を案分（按分）する場合も含むものとする。「等分」を同じ割合で分けることを意味するものとし、「案分」を異なる割合で分けることを意味するものとする。

また、割り勘の金銭を精算することを「割り勘精算」と称し、この割り勘精算を実現するための処理のことを「割り勘精算処理」と称する。
なお、割り勘精算は、割り勘の決済という意味で「割り勘決済」と表現してもよく、割り勘精算処理は「割り勘決済処理」と表現してもよいし、そのようにしなくてもよい。

また、本明細書において、端末２０が情報を送信することには、異なる端末２０に情報を送信することの他、サーバ１０やメッセージングサーバ４０等のサーバに情報を送信することも含まれるものとする。

＜第１実施例＞
第１実施例は、２人のユーザの端末２０間で、いずれか一方の端末２０のユーザによる買い物決済の決済金額の割り勘を実現するための実施例である。

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

［システム構成］
本実施例に係る通信システムでは、限定ではなく例として、ネットワーク（インターネット等）を介して、少なくとも複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）が接続される。

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

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明では端末２０について説明する。
また、第２実施例以降で図示・詳細に説明するが、端末２０の制御部を制御部２１とし、端末２０の通信部を通信Ｉ／Ｆ（インタフェース）２２として説明する。

図１は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する割り勘処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する割り勘処理の一例をそれぞれ示している。以下では、端末Ａのユーザを「ユーザＡ．Ａ」と称し、端末Ｂのユーザを「ユーザＢ．Ｂ」と称して説明する。

この例では、ユーザＡ．Ａによる買い物決済履歴（より具体的には買い物決済金額）を、ユーザＢ．Ｂとの間で割り勘する場合を例に挙げて説明する。

買い物決済履歴には、買い物決済金額の他、限定ではなく例として、商品を購入した店舗やサービスの提供を受けた店舗の名称（店舗名）、購入した商品や提供されたサービスの名称や種類、決済を行った日時（買い物決済日時）、決済を行った金額（買い物決済金額）といった複数の情報を含めることができる。
また、買い物決済履歴は、買い物決済履歴情報と表現することもできる。

まず、端末Ａの制御部２１は、第１の買い物決済履歴選択処理を実行する（Ａ１０）。具体的には、端末Ａの制御部２１は、限定ではなく例として、端末Ａの記憶部２８に記憶された、ユーザＡ．Ａによる複数の買い物決済履歴の中から、入出力部２３に対する買い物決済履歴を選択する操作入力に基づいて、少なくとも１つの買い物決済履歴を選択する。本実施例における買い物決済履歴は、端末のユーザによる第１決済に関する処理に基づく第１決済情報の一例である。

その後、端末Ａの制御部２１は、Ａ１０で選択された買い物決済履歴を、通信Ｉ／Ｆ２２によって端末Ｂに送信する（Ａ２０）。具体的には、限定ではなく例として、入出力部２３に対する買い物決済履歴を送信する操作入力に基づいて、Ａ１０で選択された買い物決済履歴を送信する。
この場合、送信する買い物決済履歴には、限定ではなく例として、少なくとも買い物決済金額の情報を含めるようにすることができる。買い物決済金額とは、買い物決済で実際に決済された金額（買い物決済でユーザが実際に支払った金額）である。

端末Ａから買い物決済履歴を受信すると（Ｂ２０）、端末Ｂの制御部２１は、割り勘における過不足の金額（以下、「過不足金額」と称する。）を計算する（Ｂ３０）。具体的には、端末Ａから受信した買い物決済履歴の買い物決済金額に基づいて、限定ではなく例として、ユーザＢ．Ｂの過不足金額（この例ではユーザＢ．ＢがユーザＡ．Ａに送金する金額）を計算する。

ここで、ユーザが買い物決済で支払い済みの金額を、そのユーザの「支払い済み金額」と称する。割り勘対象とされた買い物決済履歴の決済を行ったユーザについては、その買い物決済履歴の買い物決済金額が支払い済み金額となる。複数の買い物決済履歴が割り勘対象とされた場合は、それらの買い物決済履歴の買い物決済金額を合計した金額が支払い済み金額となる。
一方、その買い物決済履歴の決済を行っていないユーザについては、支払い済み金額は「０円」となる。

本実施例では、ユーザＢ．Ｂは買い物決済履歴を割り勘対象として登録せず、ユーザＡ．Ａのみが買い物決済履歴を割り勘対象として登録する場合を考え、ユーザＡ．Ａの支払い済み金額を、ユーザＢ．Ｂと均等割で割り勘する場合を考える。
この場合、１人あたりの負担額（以下、「１人あたり金額」と称する。）を「割り勘対象とされた支払い済み金額（この例ではユーザＡ．Ａの支払い済み金額）÷割り勘を行う人数（この例では２人）」として計算する。

この場合、Ｂ３０では、ユーザの過不足金額を、限定ではなく例として、「そのユーザの過不足金額＝そのユーザの支払い済み金額−１人あたり金額」として計算する。計算された過不足金額が正の値である場合は、そのユーザは金銭を受け取る側（受取）であることを意味し、計算された過不足金額が負の値である場合は、そのユーザは金銭を支払う側（支払い）であることを意味する。

限定ではなく例として、ユーザＡ．Ａが買い物決済によって支払った支払い済み金額（＝買い物決済金額）を「１，０００円」とし、これをユーザＢ．Ｂと均等割で割り勘する場合を考える。ユーザＢ．Ｂの支払い済み金額は「０円」であり、１人あたり金額は「１，０００円÷２人＝５００円」となるため、ユーザＢ．Ｂの過不足金額は「０円−５００円＝−５００円」、つまり「５００円 支払い」として計算される。

なお、これはあくまでも一例であり、これに限定されない。
Ｂ３０において、ユーザＢ．Ｂの過不足金額ではなく、ユーザＡ．Ａの過不足金額を計算するようにしてもよいし、そのようにしなくてもよい。この場合、上記の例では、ユーザＡ．Ａの支払い済み金額は「１，０００円」であり、１人あたり金額は「５００円」であるため、ユーザＡ．Ａの過不足金額は「１，０００円−５００円＝＋５００円」、つまり「５００円 受取」として算出される。

また、Ｂ３０において、ユーザＡ．Ａの過不足金額とユーザＢ．Ｂの過不足金額との両方の金額を計算するようにしてもよいし、そのようにしなくてもよい。

また、割り勘の割合は、上記のように均等割（等分）としてもよいし、異なる割合（案分）としてもよい。

その後、端末Ｂの制御部２１は、Ｂ３０で計算された過不足金額の情報（以下、「過不足金額情報」と称する。）を通信Ｉ／Ｆ２２によって端末Ａに送信する（Ｂ４０）。

ここで、端末Ａに送信する過不足金額情報は、ユーザＢ．Ｂの過不足金額の情報としてもよいし、ユーザＡ．Ａの過不足金額の情報としてもよいし、ユーザＡ．ＡとユーザＢ．Ｂとの両方の過不足金額の情報としてもよい。

割り勘精算を行う場合、金額を支払う側のユーザの端末２０は、そのユーザの過不足金額を電子貨幣によって相手方のユーザの端末２０に送金する送金処理を行う。一方、金銭を受け取る側のユーザの端末２０は、相手方のユーザの端末２０からそのユーザの過不足金額分の金銭を電子貨幣によって受け取る受取処理を行う。

端末２０のユーザが異なる端末２０のユーザに金銭を送ること（または端末２０が異なる端末２０に金銭を送ること）を「送金」と称し、この送金を実現するための処理を「送金処理」と称する。
それに対し、端末２０のユーザが異なる端末２０のユーザから送金された金銭を受け取ること（または端末２０が異なる端末２０から送金された金銭を受け取ること）を「受取」と称し、この受取を実現するための処理を「受取処理」と称する。

なお、「受取」、「受取処理」は、金銭を受け取るという意味で、それぞれ「受金」、「受金処理」のように表現することもできる。

端末Ｂから過不足金額情報を受信すると（Ａ４０）、端末Ａの制御部２１は、端末Ｂの制御部２１との間で、割り勘精算処理を行う（Ａ５０、Ｂ５０）。具体的には、限定ではなく例として、端末Ｂの制御部２１は、ユーザＢ．Ｂの過不足金額を通信Ｉ／Ｆ２２によって端末Ａに送金する。一方、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によって端末ＢからユーザＢ．Ｂの過不足金額に相当する金銭を受け取る。
本実施例における割り勘精算処理は、端末２０の制御部２１によって実行される送金処理／受取処理の一例である。

１つの手法として、割り勘精算処理は、端末Ａと端末Ｂとの間で、限定ではなく例として、インターネットバンキング（オンラインバンキング）等を利用して行うようにすることができる。
また、他の手法として、割り勘精算処理は、後述する支払いサービス（支払いアプリケーション）等の電子貨幣に関するサービスを利用して行うようにすることもできる。

その後、端末Ａの制御部２１は、割り勘精算の結果（以下、「割り勘精算結果」と称する。）を表示部２４に表示させる（Ａ６０）。具体的には、限定ではなく例として、受取処理で受け取った受取金額（または送金処理で相手方から送金された送金金額）を表示部２４に表示させる。

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

同様に、端末Ｂの制御部２１は、割り勘精算結果を表示部２４に表示させる（Ｂ６０）。具体的には、限定ではなく例として、送金処理で送金した送金金額（または受取処理で相手方が受け取る金額）を表示部２４に表示させる。

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

＜送金処理／受取処理の関係＞
基本的には、上記のように、買い物決済履歴を送信する端末２０のユーザ（第１のユーザ）が、買い物決済によって金額を支払い済みのユーザであり、割り勘を依頼する側であるため、第１のユーザの端末２０は受取処理を実行することになる。それに対し、買い物決済履歴を受信する端末２０のユーザ（第２のユーザ）は、割り勘を依頼される側であるため、第２のユーザの端末２０は送金処理を実行することになる。

しかし、詳細は後述するが、限定ではなく例として、本開示の手法では、第１のユーザによる買い物決済履歴ばかりでなく第２のユーザによる買い物決済履歴も、一緒に割り勘対象にするといったことも可能である。このような場合、第１のユーザの端末２０が送金処理を実行し、第２のユーザの端末２０が受取処理を実行することとなる場合もあり得る。このため、端末２０は、送金処理と受取処理とのうちのいずれかの処理を実行することになる。

＜第１実施例の効果＞
第１実施例は、端末２０が、端末２０のユーザによる端末２０に対する操作入力（限定ではなく、端末のユーザによる端末に対する入力の一例）に基づいて、買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によって異なる端末２０に送信する。また、端末２０は、送信した買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によって異なる端末２０から受信する。そして、端末２０は、過不足金額に基づき、割り勘精算処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を制御部２１（限定ではなく、端末の制御部の一例）によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第１決済に関する処理に基づく第１決済情報を送信したことに基づいて、第１金額に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。

また、第１実施例は、端末２０の制御部２１は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、端末２０のユーザによる端末２０に対する操作入力（限定ではなく、端末のユーザによる端末に対する入力の一例）に基づいて、買い物決済履歴（限定ではなく、端末のユーザによる第１決済に関する処理に基づく第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によって異なる端末２０に送信する。また、プロセッサは、送信した買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によって異なる端末２０から受信する。そして、プロセッサは、過不足金額に基づき、割り勘精算処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。

また、第１実施例は、上記の送金処理、または受取処理は、異なる端末２０のユーザ（限定ではなく、異なる端末のユーザの一例）への送金、または受け取りを含む処理である構成を示している。
このような構成により、異なる端末のユーザへの送金、または異なる端末のユーザからの金銭の受け取りを簡単に実現することができる。

また、第１実施例は、買い物決済履歴は、買い物決済金額の情報（限定ではなく、端末のユーザによる第１決済の金額の情報の一例）を含む構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第１決済の金額の情報を含む第１決済情報を送信することによって、少なくとも第１金額の情報を受信して取得することができる。

また、第１実施例は、買い物決済履歴は、買い物決済の決済履歴（限定ではなく、第１決済の決済履歴の一例）である構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済の決済履歴を送信することによって、少なくとも第１金額の情報を受信して取得することができる。

また、第１実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴（限定ではなく、複数の決済情報の一例）のうち、自己の端末２０のユーザによって選択された買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によって異なる端末２０に送信する。また、端末２０は、送信された買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によって端末２０から受信する。そして、端末２０は、過不足金額に基づき、割り勘精算処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を制御部２１（限定ではなく、端末の制御部の一例）によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第１決済情報を通信部によって送信したことに基づいて、その第１決済情報に基づく第１金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることができる。

また、第１実施例は、端末２０は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末２０のユーザによる複数の買い物決済履歴（限定ではなく、複数の決済情報の一例）のうち、自己の端末２０のユーザによって選択された買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によって異なる端末２０に送信することと、送信された買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によって異なる端末２０から受信することと、過不足金額に基づき、割り勘精算処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）とを実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。

＜第１変形例（１）＞
第１実施例において、一の端末２０が他の端末２０に割り勘対象とする買い物決済履歴を送信する場合に（図１の処理のＡ２０）、買い物決済金額に加えて、その買い物決済履歴に対応する買い物決済で購入された商品に関する情報や、その買い物決済履歴に対応する買い物決済で提供されたサービスに関する情報を含めて送信するようにしてもよいし、そのようにしなくてもよい。

この場合、買い物決済で購入された商品に関する情報には、限定ではなく例として、購入された商品そのものを識別するための商品ＩＤや、購入された商品の種別を識別するための商品種別ＩＤ、購入された商品の数等の情報を含めることができる。
また、買い物決済で提供されたサービスに関する情報には、限定ではなく例として、提供されたサービスそのものを識別するためのサービスＩＤや、提供されたサービスの種別を識別するためのサービス種別ＩＤ、そのサービスが提供された人数等の情報を含めることができる。

この場合、他の端末２０は、一の端末２０から受信された買い物決済履歴に含まれる商品に関する情報やサービスに関する情報を表示部２４に表示することで、その他の端末２０のユーザに、一の端末２０のユーザから要求された割り勘の詳細な内容を報知することができる。

本変形例は、買い物決済履歴は、買い物決済で購入された商品に関する情報（限定ではなく、第１決済で購入された商品に関する情報の一例）、または買い物決済で提供されたサービスに関する情報（限定ではなく、第１決済で提供されたサービスに関する情報の一例）を含む構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済で購入された商品、または第１決済で提供されたサービスに関する情報を含む第１決済情報を送信することによって、端末と、異なる端末を含む複数の端末とのうち、各々が送金、または受け取る金額の情報を受信して取得することができる。

＜第１変形例（２）＞
第１実施例では、端末のユーザによる端末に対する入力を、端末のユーザによる端末に対する操作入力としたが、これに限定されない。
限定ではなく例として、端末のユーザによる端末に対する入力を、端末のユーザによる端末に対する音声入力を含む音入力としてもよいし、そのようにしなくてもよい。限定ではなく例として、端末のユーザによる音声入力に従って、買い物決済履歴の選択や、買い物決済履歴の送信等の処理を行うようにしてもよいし、そのようにしなくてもよい。
これは、以下説明する実施例においても同様である。

このような構成により得られる効果の一例として、端末に対する入力を、音入力という簡単な方法によって実現することができる。

＜第２実施例＞
第２実施例は、端末２０が、支払いアプリケーションを利用して、サーバ１０を介して送金処理／受取処理を行う実施例である。第１実施例とは、サーバ１０が構成要件として追加された点が異なる。

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

以下では、支払いアプリケーションによる支払いサービスを提供する事業者のことを「支払いサービスの事業者」と称する。

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

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

また、支払いアプリケーションは、いわゆるメッセージングサービス（ＭＳ：Messaging Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＭＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。

また、支払いアプリケーションは、いわゆるソーシャルネットワーキングサービス（ＳＮＳ：Social Networking Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＳＮＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。

なお、ＭＳ（ＩＭＳを含む。）は、ＳＮＳの１つの形態（一形態）と考えることもできる。このため、ＭＳとＳＮＳとは区別してもよいし、区別しなくてもよい。

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

サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に支払いサービスを提供する機能を有する。サーバ１０は、支払いサービスサーバや、支払い管理サーバ、決済サービスサーバ、決済管理サーバ等のように表現することもできる。
なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マイク２５は、音声データの入力に利用される。スピーカ２６は、音声データの出力に利用される。カメラ２７は、動画像データの取得に利用される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜機能構成＞
（１）サーバの機能構成
図２−２は、本実施例におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。

サーバ１０は、制御部１１により実現される機能として、限定ではなく例として、支払いアプリケーション管理処理部１１１を有する。

支払いアプリケーション管理処理部１１１は、記憶部１５に記憶されている支払いアプリケーション管理処理プログラム１５１に従って、端末２０で実行される支払いアプリケーションに関する各種の情報・データの管理や、端末２０または端末２０のユーザの電子貨幣による決済を管理するための処理を実行する機能を有している。

図２−３は、本実施例におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、プログラムとして、限定ではなく例として、制御部１１により読み出され、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム１５１が記憶される。

また、記憶部１５には、データとして、限定ではなく例として、支払いアプリケーションユーザ登録データ１５３と、ユーザ管理データベース１５５とが記憶される。

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

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

支払いアプリケーションＩＤは、支払いアプリケーションのアカウント（アカウント情報）であって、端末２０、または端末２０のユーザを識別可能とするＩＤである。この支払いアプリケーションＩＤは、限定ではなく例として、サーバ１０によって固有のＩＤが設定されて記憶される。

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

その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末２０のメールアドレス（端末メールアドレス）、支払いアプリケーションにおける各種の認証に利用される認証パスワード等の認証情報、このユーザが使用するアイコンの画像データ（アイコン画像）、ユーザのプロフィール（ユーザプロフィール）等を含めるようにすることができる。
ただし、これらの情報は必須ではない。

ユーザ管理データベース１５５は、支払いアプリケーションユーザ登録データ１５３に記憶されたアカウント（アカウント情報）に基づくユーザの管理用のデータベースであり、その一例である第１のユーザ管理データベース１５５Ａの構成例を図２−５に示す。
第１のユーザ管理データベース１５５Ａには、支払いアプリケーションユーザ登録データ１５３に記憶された支払いアプリケーションＩＤごとの管理データとして、ユーザ管理データが記憶される。

各ユーザ管理データには、限定ではなく例として、支払いアプリケーションＩＤと、電子マネー口座残高と、買い物決済履歴データとが記憶される。

電子マネー口座残高は、この支払いアプリケーションＩＤに関連付けられた、支払いサービスで利用可能な電子貨幣の口座の残高である。電子マネー口座残高は、電子マネー口座残高と表現することもできる。

買い物決済履歴データは、この支払いアプリケーションＩＤに関連付けられた買い物決済履歴（買い物決済履歴情報）のデータであり、限定ではなく例として、買い物決済履歴をユニークに識別するためのＩＤである買い物決済ＩＤと、買い物決済がされた店舗をユニークに識別するためのＩＤである店舗ＩＤと、その店舗ＩＤの店舗の店舗名と、買い物決済日時と、買い物決済金額とが関連付けて記憶される。

（２）端末の機能構成
図２−６は、本実施例における端末２０の制御部２１により実現される機能の一例を示す図である。

端末２０は、制御部２１により実現される機能として、限定ではなく例として、支払いアプリケーション処理部２１１を有する。

支払いアプリケーション処理部２１１は、記憶部２８に記憶されている支払いアプリケーションプログラム２８１に従って、支払いアプリケーション処理を実行する機能を有している。

図２−７は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、プログラムとして、限定ではなく例として、制御部２１により読み出され、支払いアプリケーション処理として実行される支払いアプリケーションプログラム２８１が記憶される。

また、記憶部２８には、データとして、限定ではなく例として、支払いアプリケーションのアカウントのデータである支払いアプリケーションアカウントデータ２８３が記憶される。

＜表示画面例＞

以下の例では、ユーザＡ．Ａが「割り勘マスター（割り勘依頼主）」となって、他のユーザとの間で割り勘を行う場合を例示する。
なお、割り勘マスターとは、限定ではなく例として、最初に割り勘を行うことを提案したユーザを意味するものとする。

図２−８は、本実施例における支払いアプリケーションのメニュー画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
このメニュー画面には、画面上部に「Ｐａｙｍｅｎｔ Ａｐｐ」の文字が表示され、その横に、自己の端末２０のユーザのユーザ名（この例では「ユーザＡ．Ａ」）が表示されている。

また、その下には、このユーザ名のアカウントに関連付けてサーバ１０で記憶・管理されている電子マネー口座残高と、電子マネー口座に電子貨幣をチャージするためのチャージボタンとを含む電子マネー口座表示領域が設けられている。

また、電子マネー口座表示領域の下には、支払いアプリケーションの機能として設けられた複数の機能に基づく処理を実行させるための、複数の機能それぞれに対応する機能アイコンを含む機能アイコン表示領域が設けられている。

機能アイコン表示領域には、限定ではなく例として、入金を行うための「入金アイコン」、端末２０の表示部２４に表示されるコード（一次元コードや二次元コード等）を用いて支払いを行うための「コード支払いアイコン」、商品の購入やサービスの提供を受けるために店舗に設置されるコード（一次元コードや二次元コード等）を読み取って支払いを行うための「コードリーダアイコン」、他の端末２０のユーザ（他のアカウント）に送金を行うための「送金アイコン」、他の端末２０のユーザ（他のアカウント）との間で割り勘を行うための「割り勘アイコン」等の複数の機能アイコンが含まれる。

図２−９は、上記のメニュー画面において割り勘アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される割り勘メンバー選択画面の一例を示す図である。

割り勘メンバー選択画面は、割り勘メンバーを選択するための画面である。
割り勘メンバーとは、割り勘に参加するユーザのことであり、本明細書では、割り勘マスターも割り勘メンバーに含まれることとして説明する。

図２−９の割り勘メンバー選択画面は、割り勘マスター（この例ではユーザＡ．Ａ）が、自分以外の割り勘メンバーを選択するための画面である。
初期状態では、自分以外の割り勘メンバーが選択されていないため、限定ではなく例として、「割り勘をするメンバーがいません」の文字が画面に表示されている。
画面下部には、割り勘メンバーを検索するための「検索アイコン」が表示されており、この検索アイコンを操作することで、割り勘メンバーを検索することが可能に構成されている。

図２−１０は、上記の割り勘メンバー選択画面において検索アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される割り勘メンバー検索画面の一例を示す図である。
この割り勘メンバー検索画面は、割り勘マスターが自分以外の割り勘メンバーを検索するための画面であり、限定ではなく例として、「電話番号を入力して検索してください」の文字が表示されている。また、その下には、電話番号を入力するための電話番号入力欄とともに、入力された電話番号の端末２０（その端末２０のユーザ）を検索するための検索実行ボタンが表示されている。

この例では、「０８０ＸＸＸＸＸＸＸＸ」という電話番号が電話番号入力欄に入力されて表示されている。そして、検索実行ボタンが実行されることにより、サーバ１０によって検索が行われ、検索結果として「ユーザＢ．Ｂ」が得られた状態が示されている。
また、検索結果の下には、検索結果として得られたユーザを割り勘メンバーに追加するための「追加アイコン」が表示されており、この追加アイコンが操作されることで、検索結果として得られたユーザが、サーバ１０によって割り勘メンバーに追加される。

図２−１１は、上記の割り勘メンバー検索画面での検索によって割り勘メンバーが追加されたことに基づいて表示される割り勘メンバー選択画面の一例を示す図である。
この割り勘メンバー選択画面は図２−９の画面に対応しており、上記の検索結果に基づいて、割り勘メンバーの候補（以下、「割り勘メンバー候補」と称する。）として追加されたユーザの一覧が表示されている。この例では、「ユーザＢ．Ｂ」、「ユーザＣ．Ｃ」、「ユーザＤ．Ｄ」、「ユーザＥ．Ｅ」が割り勘メンバー候補として追加された状態が示されている。

また、それぞれの割り勘メンバー候補にはチェックボックスが関連付けて表示されており、初期状態では、全ての割り勘メンバー候補のチェックが「ＯＮ」とされている。
対応するチェックボックスを操作することで、チェックの「ＯＮ／ＯＦＦ」を切り替えることが可能に構成されており、チェックを「ＯＦＦ」とすることで、その割り勘メンバー候補を割り勘メンバーから除外することが可能に構成されている。

また、この例では、図２−９に示した検索アイコンに加えて、ユーザＡ．Ａが自分の買い物決済履歴を割り勘対象として登録するための、限定ではなく例として「支払い分を登録」と示された買い物決済履歴登録アイコンが表示されている。

図２−１２は、図２−１１の割り勘メンバー選択画面において買い物決済履歴登録アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、この端末２０のユーザについての複数の買い物決済履歴が表示されている。具体的には、限定ではなく例として、買い物決済履歴として、買い物決済日時と、店舗名と、買い物決済金額とが表示されている。この例では、「ＡＡレンタサイクル」、「ＢＢスーパー」、「ＣＣ弁当」等の、複数の店舗の買い物決済履歴が表示されている。

また、それぞれの買い物決済履歴にはチェックボックスが関連付けて設けられており、対応するチェックボックスを操作することで、チェックの「ＯＮ／ＯＦＦ」を切り替えることが可能に構成されている。１つの買い物決済履歴に限らず、複数の買い物決済履歴のチェックを「ＯＮ」とすることが可能であり、チェックが「ＯＮ」とされている買い物決済履歴を割り勘対象として、割り勘の依頼・リクエスト（以下、「割り勘リクエスト」と称する。）を行うことが可能に構成されている。

より具体的には、チェックが「ＯＮ」とされた買い物決済履歴を割り勘対象として割り勘リクエストを行うための、限定ではなく例として「割り勘依頼を送る」と示された割り勘リクエストアイコンが画面下部に表示されている。そして、この割り勘リクエストアイコンが操作されると、先に選択された割り勘メンバーの端末２０に、サーバ１０を介して、自己の端末２０から割り勘リクエストを送信することが可能に構成されている。

この例では、「ＡＡレンタサイクル」と「ＢＢスーパー」の２つの買い物決済履歴のチェックが「ＯＮ」とされ、この２つの買い物決済履歴を割り勘対象とすることがユーザＡ．Ａによって選択された状態が示されている。この場合、ユーザＡ．Ａの支払い済み金額は、「ＡＡレンタサイクル」の買い物決済金額「１，５００円」と、「ＢＢスーパー」の買い物決済金額「３，０００円」とを合計した金額である「４，５００円」となり、このユーザＡ．Ａの支払い済み金額「４，５００円」を割り勘することになる。

図２−１３は、図２−１２の買い物決済履歴選択画面において割り勘リクエストアイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて、ユーザＡ．Ａ以外の割り勘メンバーの端末２０の表示部２４に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面は、ユーザＡ．Ａが割り勘メンバーとして選択したユーザＢ．Ｂの端末２０の表示部２４に表示される画面であって、この端末２０で実行される支払いアプリケーション内の画面の一例である。

この例では、限定ではなく例として、「Ａ．Ａさんから割り勘の依頼が届きました」の文字が表示され、その下に、ユーザＢ．Ｂの過不足金額が表示される過不足金額表示領域が設けられている。本実施例において、各々の割り勘メンバーの過不足金額は、後述するようにサーバ１０によって計算される。

過不足金額表示領域には、限定ではなく例として、ユーザＢ．Ｂの過不足金額とともに、その過不足金額の種別（受取／支払い）を識別可能とするためのマークが表示されている。この例では、「￥９００ 支払い」と表示されており、ユーザＢ．ＢはユーザＡ．Ａに対して「９００円」を支払う必要があることが示されている。

過不足金額の種別（受取／支払い）は、前述したように、計算される過不足金額の正負の符号によって決定される。
「支払い」と表現しているのは、過不足金額を電子貨幣で支払う場合の他、詳細は後述するが、過不足金額を現金で支払う場合も想定されるためである。つまり、「支払い」には、電子貨幣での支払い（＝送金）と、現金での支払い（＝現金払い）とが含まれる。
なお、現金払いを考えず、「支払い」に代えて「送金」としてもよいし、そのようにしなくてもよい。

画面下部には、上記の過不足金額に基づき割り勘精算を行うための、限定ではなく例として「精算」と示された「精算アイコン」と、割り勘リクエストを拒否するための、限定ではなく例として「割り勘を断る」と示された「拒否アイコン」とが表示されている。

精算アイコンが操作された場合、そのユーザの過不足金額の種別が「支払い」である場合は、その過不足金額が、そのユーザの端末２０から送金先のユーザの端末２０に送金される。
一方、そのユーザの過不足金額の種別が「受取」である場合は、その過不足金額が、そのユーザの端末２０で受け取られる。

ただし、本実施例における送金／受取は、サーバ１０によって、そのユーザの支払いアプリケーションＩＤに関連付けられた電子マネー口座残高が更新されることによって実現される。つまり、そのユーザの過不足金額の種別が「支払い」である場合は、そのユーザの支払いアプリケーションＩＤに関連付けられた電子マネー口座残高から過不足金額に相当する金額が減算・更新される。一方、そのユーザの過不足金額の種別が「受取」である場合は、そのユーザの支払いアプリケーションＩＤに関連付けられた電子マネー口座残高に過不足金額に相当する金額が加算・更新される。

この例では、ユーザＢ．Ｂは金額を支払う側であるため、精算アイコンが操作されると、９００円が電子貨幣によってユーザＡ．Ａの端末２０に送金される。より具体的には、サーバ１０によって、ユーザＢ．Ｂの支払いアプリケーションＩＤの電子マネー口座残高から９００円が減算・更新される。

なお、実際には、サーバ１０によって、減算された９００円の金額がユーザＡ．Ａの支払いアプリケーションＩＤの電子マネー口座残高に加算・更新されるのであるが、本実施例において、このユーザＡ．Ａの電子マネー口座残高の更新は、ユーザＡ．Ａの端末２０において精算アイコンが操作されたことに基づいて、サーバ１０によって実行されるものとする。

図２−１４は、図２−１２の買い物決済履歴選択画面において割り勘リクエストアイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示される過不足金額表示画面の一例を示す図である。
この例では、限定ではなく例として、「過不足金額の計算が行われました」の文字が表示され、その下に、ユーザＡ．Ａの過不足金額が表示される過不足金額表示領域が設けられている。この例では、ユーザＡ．Ａの過不足金額として「３，６００円 受取」が表示されている。つまり、ユーザＡ．Ａは、他の割り勘メンバーから総額として「３，６００円」を受け取ることが表示されている。

この例では、ユーザＡ．Ａは金銭を受け取る側であるため、精算アイコンが操作されると、「３，６００円」の金額がユーザＡ．Ａの端末２０で受け取られる。具体的には、他の各々の割り勘メンバーの電子マネー口座残高から減額された金額の合計である３，６００円が、サーバ１０によって、ユーザＡ．Ａの支払いアプリケーションＩＤに関連付けられた電子マネー口座残高に加算・更新されることになる。

図２−１５は、ユーザＡ．Ａの端末２０の表示部２４に表示される受取通知画面の一例を示す図である。
この受取通知画面には、自分以外の割り勘メンバー（この例では「ユーザＢ．Ｂ」、「ユーザＣ．Ｃ」、「ユーザＤ．Ｄ」、「ユーザＥ．Ｅ」の４名）ごとに、そのメンバーからの送金金額と、送金が行われた日時（送金日時）とが関連付けられた受取完了通知が表示されている。

図２−１６は、図２−１５の受取通知画面に表示される割り勘完了通知の一例を示す図である。
限定ではなく例として、図２−１５の受取通知画面の表示領域がユーザの指でタッチされた後、上方向にスクロールする操作が行われると、画面下部に表示されていた割り勘完了通知が表示領域に現れる。この例では、「割り勘完了」の文字とともに、精算結果（この例では「３，６００円」 受取 自分の支払い済み金額「４，５００円」、全員の支払い合計額「４，５００円」、１人あたりの金額「９００円」）を含む割り勘完了通知が表示されている。

＜処理＞
図２−１７〜図２−１９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する割り勘処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する割り勘処理、サーバ１０の制御部１１が実行する割り勘管理処理の一例をそれぞれ示している。

一例として、割り勘マスターの端末２０をユーザＡ．Ａの端末２０（端末Ａ）とし、割り勘マスターから割り勘を依頼されるユーザの端末２０をユーザＢ．Ｂの端末２０（端末Ｂ）として説明する。実際には、割り勘マスターから割り勘を依頼されるユーザの端末２０は１つとは限らないが、端末Ｂと同様の処理となるため、図示を省略する。

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

まず、端末Ａの制御部２１は、割り勘メンバーの情報（割り勘メンバー情報）を要求するメンバー要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１１０）。通信Ｉ／Ｆ１４によって端末Ａからメンバー要求情報を受信すると（Ｓ１１０）、サーバ１０の制御部１１は、要求を受けたメンバー情報を検索して、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１２０）。

通信Ｉ／Ｆ２２によってサーバ１０からメンバー情報を受信すると（Ａ１２０）、端末Ａの制御部２１は、受信されたメンバー情報に基づき、割り勘メンバー候補を表示部２４に表示させる。そして、端末Ａの制御部２１は、入出力部２３に対する割り勘メンバーの選択操作に基づき、割り勘メンバーを選択する第１のメンバー選択処理を実行する（Ａ１３０）。そして、端末Ａの制御部２１は、割り勘メンバーの選択結果を含むメンバー選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１４０）。サーバ１０は、通信Ｉ／Ｆ１４によって端末Ａからメンバー選択情報を受信する（Ｓ１４０）。

その後、端末Ａの制御部２１は、入出力部２３に対する操作に従って、自己の端末２０のユーザによる買い物決済に対応する買い物決済履歴を要求する買い物決済履歴要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５０）。

ここで、本実施例において、各々の端末２０のユーザの買い物決済履歴は、前述したようにサーバ１０の記憶部１５で記憶・管理されており、端末２０の記憶部２８には記憶されていない。これは、端末２０側で買い物決済履歴が改ざん等されることを防止するためである。このため、Ａ１５０では、端末２０で買い物決済履歴を表示するために、端末２０からサーバ１０に対して買い物決済履歴を要求する。

端末Ａから買い物決済履歴要求情報を受信すると（Ｓ１５０）、制御部１１は、ユーザ管理データベース１５５に含まれるユーザ管理データのうち、ユーザＡ．Ａの支払いアプリケーションＩＤのユーザ管理データの買い物決済履歴データに含まれる複数の買い物決済履歴を、通信Ｉ／Ｆ２２によって端末Ａに送信する（Ｓ１６０）。

サーバ１０から買い物決済履歴を受信すると（Ａ１６０）、端末Ａの制御部２１は、第２の買い物決済履歴選択処理を行う（Ａ１７０）。具体的には、限定ではなく例として、受信された複数の買い物決済履歴を表示部２４に一覧表示する。そして、入出力部２３に対する選択操作に従って、少なくとも１つの買い物決済履歴を選択する。

その後、端末Ａの制御部２１は、限定ではなく例として、買い物決済履歴選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８０）。
ここで、端末２０からサーバ１０に送信する買い物決済履歴選択情報は、選択した買い物決済履歴をサーバ１０側で特定可能な情報とすればよい。具体的には、一例として、選択した買い物決済履歴に対応する買い物決済ＩＤを送信するようにすることができる。また、別例として、選択した買い物決済履歴そのものを送信するようにすることもできる。

端末Ａから買い物決済履歴選択情報を受信すると（Ｓ１８０）、制御部１１は、Ｓ１４０で受信されたメンバー選択情報と、Ｓ１８０で受信された買い物決済履歴選択情報とに基づいて、各々の割り勘メンバーの過不足金額を計算する（Ｓ１９０）。

その後、制御部１１は、Ｓ１９０で計算した過不足金額を含む割り勘精算依頼通知を、通信Ｉ／Ｆ１４によって端末Ａおよび端末Ｂそれぞれに送信する（Ｓ２１０）。

サーバ１０から割り勘精算依頼通知を受信すると（Ａ２１０）、端末Ａの制御部２１は、限定ではなく例として、割り勘精算依頼通知に含まれる過不足金額を表示部２４に表示させる。そして、端末Ａの制御部２１は、入出力部２３に対する操作に従って、割り勘精算を承認することを通知するための割り勘精算承認通知を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２３０）。

一方、サーバ１０から割り勘精算依頼通知を受信すると（Ｂ２１０）、端末Ｂの制御部２１は、限定ではなく例として、割り勘精算依頼通知に含まれる過不足金額を表示部２４に表示させる。そして、端末Ａの制御部２１は、ユーザＢ．Ｂが割り勘に同意したか否かを判定する（Ｂ２２０）。具体的には、限定ではなく例として、割り勘に同意する意思を示す操作（限定ではなく例として、前述した「精算アイコン」に対する操作）がなされたか否かを判定する。割り勘を拒否する意思を示す操作（限定ではなく例として、前述した「拒否アイコン」に対する操作）がなされた場合は、割り勘に同意しないと判定する。

割り勘に同意すると判定したならば（Ｂ２２０：ＹＥＳ）、端末Ｂの制御部２１は、割り勘精算を承認することを通知するための割り勘精算承認通知を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ２３０）。一方、割り勘に同意しないと判定したならば（Ｂ２２０：ＮＯ）、端末Ｂの制御部２１は、割り勘精算を承認しないこと（割り勘精算を拒否すること）を通知するための割り勘精算拒否通知を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ２４０）。

Ｓ２１０の後、制御部１１は、第１の割り勘承認管理処理を実行する（Ｓ２３０）。

図２−２０は、第１の割り勘承認管理処理の流れの一例を示すフローチャートである。
本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」とのうちのいずれかの通知である。

制御部１１は、端末２０から割り勘精算通知を受信すると（Ｓ２３１０）、受信された割り勘精算通知が「割り勘精算拒否通知」であるか否かを判定する（Ｓ２３２０）。割り勘精算拒否通知であると判定したならば（Ｓ２３２０：ＹＥＳ）、制御部１１は、割り勘不成立と判定して（Ｓ２３３０）、第１の割り勘承認管理処理を終了する。

一方、受信された割り勘精算通知が「割り勘精算拒否通知」ではない（「割り勘精算承認通知」である）と判定したならば（Ｓ２３２０：ＮＯ）、制御部１１は、全ての対象端末から割り勘精算承認通知を受信したか否かを判定する（Ｓ２３４０）。

ここで、「対象端末」は、サーバ１０が割り勘精算通知を受信することが予定されている端末２０である。この例では、端末Ａおよび端末Ｂの両方が対象端末となる。
基本的には、全ての割り勘メンバーの端末２０が対象端末となるが、割り勘メンバーであっても対象端末から除外される場合がある。これについては、後述する実施例で詳細に説明する。

少なくとも１つの対象端末から割り勘精算承認通知を受信していないと判定したならば（Ｓ２３４０：ＮＯ）、制御部１１は、Ｓ２３１０に処理を戻す。

一方、全ての対象端末から割り勘精算承認通知を受信したと判定したならば（Ｓ２３４０：ＹＥＳ）、制御部１１は、各々の対象端末について、その対象端末のユーザが割り勘で支払う金額が、そのユーザの支払いアプリケーションＩＤに関連付けて記憶された電子マネー口座残高以上であるか否かを判定する（Ｓ２３５０）。この条件を満たさない場合（Ｓ２３５０：ＮＯ）、制御部１１は、Ｓ２３３０に処理を移す。

一方、Ｓ２３５０の条件を満たすと判定した場合（Ｓ２３５０：ＹＥＳ）、制御部１１は、割り勘成立と判定する（Ｓ２３６０）。つまり、全ての対象端末のユーザの電子マネー口座残高がマイナスとならない場合に、割り勘成立と判定する。そして、制御部１１は、第１の割り勘承認管理処理を終了する。

図２−１８の処理に戻り、第１の割り勘承認管理処理で割り勘成立と判定したならば（Ｓ３１０：ＹＥＳ）、制御部１１は、通信Ｉ／Ｆ２２によって割り勘成立通知を端末Ａ及び端末Ｂそれぞれに送信する（Ｓ３１０）。

一方、第１の割り勘承認管理処理で割り勘不成立と判定したならば（Ｓ３１０：ＮＯ）、制御部１１は、通信Ｉ／Ｆ２２によって割り勘不成立通知を端末Ａ及び端末Ｂそれぞれに送信する（Ｓ２５０）。

Ａ２３０の後、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘不成立通知を受信したか否かを判定する（Ａ２５０）。
同様に、Ｂ２４０の後、端末Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘不成立通知を受信したか否かを判定する（Ｂ２５０）。

Ａ２５０でサーバ１０から割り勘不成立通知を受信しなかった場合（Ａ２５０：ＮＯ）、端末Ａは、サーバ１０から割り勘成立通知を受信することになる（Ａ３１０）。この場合、端末Ａの制御部２１は、割り勘精算を要求する情報（以下、「割り勘精算要求情報」と称する。）を通信Ｉ／Ｆ２２によってサーバ１０に送信する割り勘精算要求処理を実行する（Ａ３２０）。

同様に、Ｂ２５０においてサーバ１０から割り勘不成立通知を受信しなかった場合（Ａ２５０：ＮＯ）、端末Ｂは、サーバ１０から割り勘成立通知を受信することになる（Ｂ３１０）。この場合、端末Ｂの制御部２１は、割り勘精算要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ３２０）。

端末Ａおよび端末Ｂからそれぞれ割り勘精算要求情報を受信すると（Ｓ３２０）、制御部１１は、割り勘精算処理を実行する（Ｓ３３０）。具体的には、限定ではなく例として、そのユーザに関連付けられた支払いアプリケーションＩＤの電子マネー口座残高に、そのユーザの過不足金額に相当する金額を加算（金銭を受け取る場合）／減算（金銭を支払う場合）する。

本実施例における割り勘精算処理は、サーバ１０の制御部１１によって実行される送金処理／受取処理の一例である。

その後、制御部１１は、割り勘精算結果を通信Ｉ／Ｆ１４によって端末Ａおよび端末Ｂそれぞれに送信する（Ｓ３４０）。

端末２０は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘精算結果を受信する割り勘精算結果受信処理を実行する。

具体的には、通信Ｉ／Ｆ２２によってサーバ１０から割り勘精算結果を受信すると（Ａ３４０）、端末Ａの制御部２１は、受信された割り勘精算結果を表示部２４に表示させる（Ａ３５０）。
同様に、通信Ｉ／Ｆ２２によってサーバ１０から割り勘精算結果を受信すると（Ｂ３４０）、端末Ｂの制御部２１は、受信された割り勘精算結果を表示部２４に表示させる（Ｂ３５０）。

ここで、割り勘精算結果には、限定ではなく例として、前述した受取完了通知と、割り勘完了通知とのうちの少なくともいずれかが含まれる。
受取完了通知と割り勘完了通知との両方を割り勘精算結果としてもよいし、いずれか一方のみを割り勘完了通知としてもよい。

本実施例において、割り勘精算要求処理や割り勘精算結果受信処理は、端末２０の制御部２１によって実行される送金処理／受取処理の一例である。

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

同様に、端末Ｂの制御部２１は、処理を終了するか否かを判定し（Ｂ３９０）、処理を継続すると判定したならば（Ｂ３９０：ＮＯ）、Ｂ１１０に処理を戻す。また、処理を終了すると判定したならば（Ｂ３９０：ＹＥＳ）、端末Ｂの制御部２１は、割り勘処理を終了する。

同様に、制御部１１は、処理を終了するか否かを判定し（Ｓ３９０）、処理を継続すると判定したならば（Ｓ３９０：ＮＯ）、Ｓ１１０に処理を戻す。また、処理を終了すると判定したならば（Ｓ３９０：ＹＥＳ）、制御部１１は、割り勘管理処理を終了する。

なお、本実施例では、サーバ１０によって割り勘精算処理が実行されるため、端末２０が直接的に金銭の送金／受取を行っているわけではないが、端末２０が割り勘精算要求処理を実行したことに基づいてサーバ１０によって割り勘精算処理が実行されるため、端末２０が金銭の送金処理／受取処理を実行していると言うこともできる。

＜第２実施例の効果＞
第２実施例は、端末２０は、自己の端末２０のユーザによる自己の端末２０に対する入力（限定ではなく、端末に対する入力の一例）に基づいて、買い物決済履歴（買い物決済履歴選択情報）（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によってサーバ１０に送信する。また、端末２０は、送信した買い物決済履歴に基づく各々のユーザの過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を制御部２１（限定ではなく、端末の制御部の一例）によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第１決済に関する処理に基づく第１決済情報を送信したことに基づいて、第１金額に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。

また、第２実施例は、上記の第１金額に基づく送金処理、または受取処理は、異なる端末２０のユーザ（支払いアプリケーションにおける異なるアカウント）（限定ではなく、異なる端末のユーザの一例）への送金、または異なる端末２０のユーザ（支払いアプリケーションにおける異なるアカウント）からの受け取りを含む処理である構成を示している。
このような構成により、異なる端末のユーザへの送金、または異なる端末のユーザからの金銭の受け取りを実現することができる。

また、第２実施例は、過不足金額（限定ではなく、第１金額、第２金額の一例）は、端末２０のユーザによって選択された買い物決済履歴（限定ではなく、第１決済情報の一例）に基づいて、サーバ１０（限定ではなく、第１決済に関する決済処理を実行するサーバの一例）によって決定される構成を示している。
このような構成により得られる効果の一例として、第１金額と第２金額とを端末で決定せずに済むため、端末の処理負荷を軽減することができる。

また、第２実施例は、サーバ１０は、受信された買い物決済履歴に基づいて、その送信元のユーザである割り勘マスターの端末２０（限定ではなく、端末の一例）と、他の割り勘メンバーの端末２０（限定ではなく、異なる端末の一例）を含む複数の端末２０とのうち、各々が送金、または受け取る金額を決定する構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済情報を送信することによって、端末と、異なる端末を含む複数の端末とのうち、各々が送金、または受け取る金額をサーバに決定させることができる。

また、第２実施例は、サーバ１０は、端末２０のユーザによる端末２０に対する入力（限定ではなく、端末に対する入力の一例）に基づいて、買い物決済履歴（買い物決済履歴選択情報）を通信Ｉ／Ｆ１４によって端末２０から受信する。また、サーバ１０は、受信された買い物決済履歴に基づき、少なくとも第１過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額の一例）の情報を端末２０に通信Ｉ／Ｆ１４によって送信し、少なくとも第２過不足金額（限定ではなく、第１決済情報に基づく、端末とは異なる端末のユーザが送金、または受け取る第２金額の一例）の情報を異なる端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、第１の過不足金額および第２の過不足金額に基づく割り勘精算処理（限定ではなく、第１金額に基づく送金処理、または受取処理と、第２金額に基づく送金処理、または受取処理との一例）を実行する構成を示している。
このような構成により得られる効果の一例として、サーバは、端末のユーザによる第１決済に関する処理に基づく第１決済情報を受信したことに基づいて、第１金額に基づく送金処理、または受取処理と、第２金額に基づく送金処理、または受取処理とを制御部によって実行して、端末に金銭を簡単に送金する、または受け取らせることが可能となる。

また、第２実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴（限定ではなく、複数の決済情報の一例）のうち、自己の端末２０のユーザによって選択された買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によってサーバ１０に送信する。また、端末２０は、送信された買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を制御部２１（限定ではなく、端末の制御部の一例）によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第１決済情報を通信部によって送信したことに基づいて、その第１決済情報に基づく第１金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることができる。

＜第２変形例（１）＞
第２実施例では、買い物決済履歴がサーバ１０の記憶部１５に記憶・管理されていることとしたが、これに限定されない。第１実施例と同様に、端末２０の記憶部２８に買い物決済履歴を記憶させておくようにすることもできる。

限定ではなく例として、サーバ１０によって買い物決済処理が行われた場合、その買い物決済情報を端末２０に送信するようにする。そして、端末２０は、サーバ１０から受信した買い物決済情報を買い物決済履歴として記憶部２８に記憶させる。

この場合、端末２０は、記憶部２８に記憶された買い物決済履歴の中から選択された買い物決済履歴をサーバ１０に送信するようにすることができる。
これは、サーバ１０を構成要件として含む各実施例について同様である。

＜第２変形例（２）＞
第２実施例では、サーバ１０の制御部１１によって割り勘精算処理が行われることとしたが、これに限定されない。
具体的には、限定ではなく例として、第１実施例と同様に、割り勘精算処理が端末２０の制御部２１によって実行されるようにしてもよいし、そのようにしなくてもよい。
これは、サーバ１０を構成要件として含む各実施例について同様である。

＜第２変形例（３）＞
サーバ１０において、各々のユーザ管理データに含まれる買い物決済履歴データに、その買い物決済の具体的な内容（以下、「買い物決済内容」と称する。）を含めて管理するようにしてもよいし、そのようにしなくてもよい。

図２−２１は、本変形例におけるユーザ管理データベース１５５の別例である第２のユーザ管理データベース１５５Ｂのデータ構成例を示す図である。
この例では、買い物決済履歴データには、買い物決済ＩＤと、店舗ＩＤと、買い物決済日時とに加えて、買い物決済内容が関連付けて記憶されている。

買い物決済内容には、限定ではなく例として、その店舗ＩＤの店舗で購入された商品に関する情報や、その店舗ＩＤの店舗で提供されたサービスに関する情報が含まれる。

この場合、購入された商品に関する情報には、限定ではなく例として、購入された商品そのものを識別するための商品ＩＤや、購入された商品の種別を識別するための商品種別ＩＤ、購入された商品の数等の情報を含めることができる。
また、提供されたサービスに関する情報には、限定ではなく例として、提供されたサービスそのものを識別するためのサービスＩＤや、提供されたサービスの種別を識別するためのサービス種別ＩＤ、そのサービスが提供された人数等の情報を含めることができる。

このようにすることで、限定ではなく例として、端末２０から受信した買い物決済内容の照会要求に従って、サーバ１０の制御部１１は、買い物決済内容を端末２０に開示することができる。

＜第２変形例（４）＞
第２実施例に示した表示画面やユーザインタフェース（ＵＩ）は、あくまでも一例に過ぎず、これらに限定されない。

図２−２２は、図２−１３の割り勘リクエスト通知画面の別例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘リクエスト通知画面は、図２−１５の割り勘リクエスト通知画面に対応するが、過不足金額表示領域が操作（限定ではなく例としてタッチ操作）されることで、割り勘マスターによって依頼された割り勘の内訳が表示されるように構成されている。
この例では、割り勘の内訳として、「ＡＡレンタサイクル １，５００円」と、「ＢＢスーパー ３，０００円」とが表示されるとともに、それらの合計金額「４，５００円」と、１人あたり金額として「４，５００円÷５人＝９００円」が表示されている。

この例では、ユーザＡ．Ａが買い物決済によって支払った支払い済み金額を、５人のユーザで割り勘する場合を示している。ユーザＡ．Ａの支払い済み金額は「４，５００円」であり、割り勘する人数は「５人」であるため、１人あたり金額は「４，５００円÷５人＝９００円」となる。

具体的には、端末２０の制御部２１は、過不足金額表示領域が操作されたことに基づいて、割り勘の内訳の照会要求をサーバ１０に送信する。サーバ１０は、第１のユーザ管理データベース１５５Ａ（図２−５参照）のうち、割り勘マスターの支払いアプリケーションＩＤが記憶されたユーザ管理データに含まれる買い物決済履歴データに基づき、店舗名、買い物決済日時、買い物決済金額の情報を端末２０に送信する。そして、端末２０の制御部２１は、受信された情報に基づき、割り勘の内訳を表示させる。

なお、端末２０の制御部２１が、過不足金額表示領域が操作されたことに基づいて、前述した買い物決済内容の照会要求を端末２０からサーバ１０に送信するようにすることもできる。この場合、サーバ１０は、第２のユーザ管理データベース１５５Ｂ（図２−２１参照）のうち、割り勘マスターの支払いアプリケーションＩＤが記憶されたユーザ管理データに含まれる買い物決済履歴データに基づき、店舗名、買い物決済日時、買い物決済金額に加えて、買い物決済内容を端末２０に送信する。そして、端末２０の制御部２１は、受信された情報に基づき、買い物決済内容を含む割り勘の内訳を表示させる。

図２−２３は、図２−１５に示した受取通知画面の別例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面を一例として示している。
この受取通知画面では、図２−１５の受取通知画面とは異なり、ユーザＡ．Ａが受け取った電子マネーの金額の総額（この例では「３６００円」）とともに、「割り勘メンバーから送金がありました。」の文字と、自分以外の割り勘メンバーのアイコン画像（この例では「ユーザＢ．Ｂ」、「ユーザＣ．Ｃ」、「ユーザＤ．Ｄ」、「ユーザＥ．Ｅ」の４名のアイコン画像）を含む受取通知が表示されている。また、受取通知の下には、図２−１６に示した割り勘完了通知と同様の割り勘完了通知が表示されている。

このような表示を行うことで、割り勘マスターのユーザは、自身に送金された金額の総額と、自身に送金を行った割り勘メンバーとを一見して把握することが可能となる。

＜第２変形例（５）＞
割り勘リクエストを行ったにも関わらず送金を行わないユーザの端末２０に対して、割り勘マスターの端末２０からサーバ１０を介して催促を行うようにしてもよいし、そのようにしなくてもよい。

図２−２４は、本実施例における割り勘催促通知画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘催促通知画面には、「Ａ．Ａさんから割り勘の催促が届きました」という文字が表示され、その下に、割り勘リクエスト通知画面と同様に、ユーザＢ．Ｂの過不足金額を含む過不足金額表示領域が表示されている。

このような表示を行うことで、割り勘を依頼されたユーザが精算を忘れた（または忘れている）場合であっても、確実に精算を行わせることが可能となる。

＜第２変形例（６）＞
第２実施例では、全ての対象端末のユーザの電子マネー口座残高がマイナスとならない場合に、割り勘成立と判定することとして説明した。
これに関して、限定ではなく例として、電子マネー口座残高がマイナスとなる対象端末のユーザが存在する場合に、サーバ１０によって（支払いアプリケーションの事業者によって）、不足分の金額を立て替えるなどして電子マネー口座に補充して、割り勘成立と判定するようにしてもよい。この場合、立て替えた金額は、ユーザに後で精算してもらうようにすればよい。

＜第３実施例＞
第３実施例は、各々の割り勘メンバーが、自分の過不足金額ばかりでなく、他の割り勘メンバーの過不足金額を自分の端末２０で確認することを可能とする実施例である。
第３実施例は、第２実施例の処理に、端末２０が、サーバ１０から少なくとも割り勘メンバー各々の過不足金額の情報を受信して表示部２４に表示させる処理を追加した実施例である。

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

＜表示画面例＞
図３−１は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面では、図２−１２の買い物決済履歴選択画面と同様に、自己の端末２０のユーザについての複数の買い物決済履歴が表示されている。この例では、「ＡＡレンタサイクル」と「ＢＢスーパー」の買い物決済履歴のチェックが「ＯＮ」とされた状態が示されている。

また、図３−１の買い物決済履歴選択画面は、図２−１２の買い物決済履歴選択画面とは、画面下部に表示されるアイコンが異なっている。具体的には、図２−１２の買い物決済履歴選択画面では、割り勘リクエストアイコンが画面下部に表示されていたが、図３−１の買い物決済履歴選択画面では、割り勘リクエストアイコンに代えて、割り勘の内容を確認するための、限定ではなく例として「割り勘内容を確認」と示された割り勘内容確認アイコンが表示されている。

図３−２は、図３−１の買い物決済履歴選択画面において割り勘内容確認アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面には、自己の端末２０のユーザを含む各々の割り勘メンバーについて、支払い済み金額を表示するための支払い済み金額一覧表示領域と、過不足金額を表示するための過不足金額一覧表示領域とが設けられている。

この例では、支払い済み金額一覧表示領域には、自己の端末２０のユーザ（ユーザＡ．Ａ）は「４，５００円」が支払い済み金額として表示され、それ以外の割り勘メンバーのユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ）は「０円」が支払い済み金額として表示されている。

また、この例では、１人あたり金額が「９００円」であることから、過不足金額一覧表示領域には、自己の端末２０のユーザ（ユーザＡ．Ａ）は「３６００円 受取」が過不足金額として表示され、それ以外の割り勘メンバーのユーザ（ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ）は「９００円 支払い」が過不足金額として表示されている。

また、支払い済み金額一覧表示領域および過不足金額一覧表示領域の下には、１人あたり金額が表示される１人あたり金額表示領域が設けられており、この例では、「９００円」が１人あたり金額として表示されている。

また、１人あたり金額表示領域の下には、コメントを入力するためのコメント入力領域が設けられている。この例では、割り勘マスターであるユーザＡ．Ａによって、「先日の旅行での支払いの割り勘です。」という内容のコメントが入力されて表示された状態が示されている。

また、この割り勘内容確認画面には、図２−１２の買い物決済履歴選択画面に表示されていた「割り勘リクエストアイコン」が画面下部に表示されている。この割り勘リクエストアイコンが操作されることで、割り勘リクエストが他の割り勘メンバーの端末２０に送信される。

上記の各種の情報は、限定ではなく例として、割り勘確認情報がサーバ１０から端末２０に送信されることで表示される。この例において、割り勘確認情報には、登録された買い物決済履歴に基づく支払い済み金額の情報と、各々の割り勘メンバーの過不足金額の情報と、登録されたコメントの情報とを含めることができる。

なお、必ずしも上記の全ての情報を割り勘確認情報に含めなければならないわけではなく、その一部の情報を割り勘確認情報に含めるようにしてもよい。限定ではなく例として、各々の割り勘メンバーの過不足金額の情報を割り勘確認情報に含めるようにし、各々の割り勘メンバーの過不足金額の情報を端末２０で確認できるようにしてもよい。

図３−３は、図３−２の割り勘内容確認画面において割り勘リクエストアイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、図２−１３の割り勘リクエスト通知画面とは異なり、過不足金額表示領域の下に、割り勘マスターであるユーザＡ．Ａによって入力されたコメントが表示されている。この例では、ユーザＡ．Ａのアイコン画像およびユーザ名と関連付けて、「先日の旅行での支払いの割り勘です。」のコメントが吹き出しで表示されている。

また、図３−３の割り勘リクエスト通知画面では、図２−１３の割り勘リクエスト通知画面とは異なり、精算内容の詳細を確認するための、限定ではなく例として「精算内容を確認する」と示された精算内容確認アイコンが表示されている。

図３−４は、図３−３の割り勘リクエスト通知画面において精算内容確認アイコンが操作（限定ではなく例としてタッチ操作）された場合に表示される精算内容確認画面の一例を示す図である。
この精算内容確認画面では、上から順に、自己の端末２０のユーザであるユーザＢ．Ｂと、割り勘マスターであるユーザＡ．Ａと、それ以外の割り勘メンバー（ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ）とのアイコン画像およびユーザ名が表示されている。また、各々の割り勘メンバーと関連付けて、支払い済み金額一覧表示領域にはその割り勘メンバーの支払い済み金額が表示され、過不足金額一覧表示領域にはその割り勘メンバーの過不足金額が表示されている。

図３−５は、図３−４の精算内容確認画面において支払い済み金額一覧表示領域が操作（限定ではなく例としてタッチ操作）された場合の表示の一例を示す図である。
支払い済み金額一覧表示領域のうち、一のユーザの支払い済み金額の表示領域が操作されると、その支払い済み金額に対応する支払い内容、つまり、割り勘の内訳が確認可能に構成されている。この例では、支払い済み金額一覧表示領域のうち、割り勘マスターであるユーザＡ．Ａに関連付けられた支払い済み金額（この例では「４，５００円」）の表示領域がユーザＢ．Ｂによってタッチ操作されたことに基づいて、その支払い済み金額に対応する支払い内容がポップアップ形式で表示されている。

＜処理＞
図３−６は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図２−１７〜図２−１９の処理のうちの図２−１７の処理部分に、端末Ａの処理としてＡ４１０、Ａ４２０のステップを追加し、サーバ１０の処理としてＳ４１０のステップを追加した処理である。

Ｓ１８０、Ｓ１９０の後、サーバ１０の制御部１１は、前述した割り勘確認情報を通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ４１０）。そして、制御部１１は、図２−１８のＳ２１０に処理を移す。

通信Ｉ／Ｆ２２によってサーバ１０から割り勘確認情報を受信すると（Ａ４１０）、端末Ａの制御部２１は、受信された割り勘確認情報を表示部２４に表示させる（Ａ４２０）。これにより、前述した過不足金額の情報等を含む各種の情報が表示部２４に表示される。そして、端末Ａの制御部２１は、図２−１８のＡ２１０に処理を移す。

＜第３実施例の効果＞
第３実施例は、端末２０が、自己の端末２０のユーザによる買い物決済履歴に基づく、少なくとも、自己の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）の情報と、異なる端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）の情報とを含む割り勘確認情報（限定ではなく、金額情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信された割り勘確認情報を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも第１金額の情報と第２金額の情報とを含む金額情報を、端末のユーザが確認できるようにすることができる。

＜第３変形例（１）＞
第３実施例において、各々の割り勘メンバーの過不足金額に基づく割り勘精算の状況（以下、「割り勘精算状況」と称する。）を端末２０のユーザが確認できるようにすることも可能である。

図３−７は、本変形例における割り勘内容確認画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘内容確認画面には、限定ではなく例として、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーの過不足金額と、その割り勘メンバーの割り勘精算状況とが表示されている。

割り勘マスター（ユーザＡ．Ａ）の欄には、割り勘精算状況として、限定ではなく例として、割り勘マスターの過不足金額（受け取るべき金額）と、他の割り勘メンバーからの金銭の受け取りの状況（受取済／未受取）とが表示される。他の割り勘メンバーのうちの一部の割り勘メンバーから金銭を受け取り済みである場合は、受け取った金額とともに、「受取済」が表示される。

また、割り勘マスター以外の割り勘メンバー（この例では自分（ユーザＢ．Ｂ）、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅ）の欄には、割り勘精算状況として、限定ではなく例として、その割り勘メンバーの過不足金額（支払うべき金額）と、その割り勘メンバーの金額の支払いの状況（精算済み／未精算）とが表示される。

また、割り勘精算状況の表示領域の下には、限定ではなく例として、この割り勘精算状況を最新の状態に更新するための、限定ではなく例として、更新マークと、「更新する」の文字とを含む割り勘精算状況更新アイコンが設けられている。この割り勘精算状況更新アイコンが操作されると、最新の割り勘精算状況がサーバ１０から端末２０に送信されて、表示が更新される。

この例では、自分（ユーザＢ．Ｂ）の割り勘精算状況として、「９００円 支払い」および「未精算」が表示されている。
また、割り勘マスター（ユーザＡ．Ａ）および自分（ユーザＢ．Ｂ）以外の割り勘メンバーの割り勘精算状況として、ユーザＣ．Ｃには「９００円 支払い」および「未精算」が、ユーザＤ．Ｄには「９００円 支払い」および「精算済み」が、ユーザＥ．Ｅには「９００円 支払い」、「未精算」がそれぞれ表示されている。
また、ユーザＤ．Ｄが精算済みであり、割り勘マスター（ユーザＡ．Ａ）はユーザＤ．Ｄから「９００円」を受け取り済みであることから、割り勘マスター（ユーザＡ．Ａ）の割り勘精算状況として、「３，６００円 受取」および「９００円 受取済」が表示されている。

このような表示を行うことで、各々の端末２０のユーザは、自分以外のユーザの精算状況を確認することができるため、ユーザの利便性を向上させることができる。

＜第３変形例（２）＞
各々の割り勘メンバーが割り勘で負担する金額、または金額を負担する割合を、端末２０のユーザによる入力に基づいて変更することを可能としてもよい。

図３−８は、割り勘内容確認画面の別例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘内容確認画面では、限定ではなく例として、図３−５の割り勘内容確認画面における１人あたり金額表示領域の横に、各々の割り勘メンバーの割り勘での金額の負担の割合（以下、「割り勘割合」と称する。）を表示するための、限定ではなく例として「分担割合を確認」と示された割り勘割合確認アイコンが設けられている。
なお、この表示画面例では、割り勘割合を「分担割合」として表示している。

図３−９は、図３−８の割り勘内容確認画面において割り勘割合確認アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される割り勘割合確認画面の一例を示す図である。
この割り勘割合確認画面には、「割り勘の分担割合を確認してください」の文字が表示され、その下に、買い物決済による支払い金額の総額（支払総額）が表示される支払総額表示領域が設けられている。

ここで、「支払総額」とは、各々の割り勘メンバーが登録した買い物決済履歴に基づく支払い済み金額を総計した金額である。
本実施例では、ユーザＡ．Ａのみが買い物決済履歴を登録することにしているため、「ユーザＡ．Ａの支払い済み金額＝支払総額」となる。その結果、この例では、支払総額として「４，５００円」が表示されている。
なお、この例のように一人のユーザのみが買い物決済履歴を登録する場合、支払総額の表示は、そのユーザの支払い済み金額の表示としてもよい。

また、その下には、各々の割り勘メンバーのアイコン画像と関連付けて、過不足金額のうちの精算済みの金額をグラフで表示するためのグラフ表示領域が設けられている。この例では、グラフ表示領域には、精算済みの金額に応じて長さが変化する横方向の棒グラフが表示されている。

具体的には、この例では、割り勘マスター（ユーザＡ．Ａ）が買い物決済で「４，５００円」を支払い済みであり、他のいずれの割り勘メンバーからも未だ金銭を受け取っていないため、ユーザＡ．Ａのアイコン画像の横には「４，５００円」に相当する長さの棒グラフが表示されている。また、他の割り勘メンバーは、いずれも未だユーザＡ．Ａに金額を支払っておらず、棒グラフの長さが“０”であるため、ユーザＡ．Ａ以外の割り勘メンバーのアイコン画像と関連付けて、破線で囲われた「０円」が表示されている。

この状態において、割り勘メンバーの誰かがユーザＡ．Ａに金銭を送金すると、その割り勘メンバーに関連付けられた棒グラフの長さが、ユーザＡ．Ａに送金した金額に相当する長さに更新されて表示される。

また、グラフ表示領域の横には、各々の割り勘メンバーの過不足金額が表示されている。この例では、割り勘マスター（ユーザＡ．Ａ）には過不足金額として「３，６００円、受取」が表示され、他の割り勘メンバーには過不足金額として「９００円 支払い」が表示されている。

また、画面下部には、割り勘割合を変更するための、限定ではなく例として「分担割合を変更する」と示された割り勘割合変更アイコンが表示されている。

図３−１０は、図３−９の割り勘割合確認画面において割り勘割合変更アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される割り勘割合変更画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘割合変更画面には、各々の割り勘メンバーの割り勘割合を変更するための割り勘割合変更用グラフが表示されている。この例では、割り勘割合変更用グラフとして、ドーナツ形状のグラフ（以下、「ドーナツグラフ」と称する。）で表されるグラフが表示されている。このドーナツグラフは、円グラフの中心部に穴が開いた形状のグラフであり、この例では、中心部の穴が開いた領域に支払総額が表示されている。

また、ドーナツグラフは、各々の割り勘メンバーに対応する複数の領域を有しており、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーの割り勘割合と、その割り勘割合と支払総額とに基づき計算される過不足金額（＝支払総額×割り勘割合）とが表示されている。

各々の割り勘メンバーの割り勘割合は、ドーナツグラフのうちのその割り勘メンバーに対応する表示領域とそれに隣接する割り勘メンバーに対応する表示領域との境界部分をいずれかの方向にスワイプ操作することで変更可能に構成されている。

限定ではなく例として、ドーナツグラフのうち、ユーザＢ．Ｂの表示領域とユーザＣ．Ｃの表示領域との境界部分が指でタッチされ、その後、ユーザＢ．Ｂ側、またはユーザＣ．Ｃ側に指を移動させる操作が行われることで、ユーザＢ．ＢおよびユーザＣ．Ｃの割り勘割合が変更される。

具体的には、限定ではなく例として、ユーザＢ．Ｂ側に指を移動させると、ドーナツグラフのうちのユーザＢ．Ｂの表示領域が占める割合が減少し、ユーザＢ．Ｂの割り勘割合が減少してユーザＣ．Ｃの割り勘割合が増加する。一方、ユーザＣ．Ｃ側に指を移動させると、ドーナツグラフのうちのユーザＢ．Ｂの表示領域が占める割合が増加し、ユーザＢ．Ｂの割り勘割合が増加してユーザＣ．Ｃの割り勘割合が減少する。この場合、他の割り勘メンバーの割り勘割合は変わらない。

なお、この例では、ドーナツグラフを用いて割り勘割合を変更する場合を例示したが、棒グラフ、円グラフ、帯グラフといったドーナツグラフ以外のグラフを用いて割り勘割合を変更するようにしてもよいし、そのようにしなくてもよい。また、割り勘割合を数値で入力して変更するようにしてもよいし、そのようにしなくてもよい。
また、割り勘割合に代えて、同様の手法に従って、過不足金額を変更するようにしてもよいし、そのようにしなくてもよい。

図３−１１は、本変形例における各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図３−６の処理に、端末Ａの処理としてＡ４３０、Ａ４４０のステップを、サーバ１０の処理としてＳ４４０のステップを追加した処理である。

Ａ４２０の後、端末Ａの制御部２１は、限定ではなく例として、入出力部２３に対して割り勘割合変更操作が入力されたか否かに基づいて、割り勘割合を変更するか否かを判定する（Ａ４３０）。

割り勘割合を変更すると判定したならば（Ａ４３０：ＹＥＳ）、端末Ａの制御部２１は、限定ではなく例として、割り勘割合変更操作によって指定された割り勘割合を含む割り勘変更依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信した後（Ａ４４０）、Ａ４１０に処理を戻す。

一方、割り勘割合を変更しないと判定したならば（Ａ４３０：ＮＯ）、端末Ａの制御部２１は、図２−１８のＡ２１０に処理を移す。

Ｓ４１０の後、制御部１１は、通信Ｉ／Ｆ１４によって端末Ａから割り勘変更依頼情報を受信したか否かを判定し（Ｓ４４０）、受信したと判定したならば（Ｓ４４０：ＹＥＳ）、Ｓ１９０に処理を戻す。つまり、端末Ａから受信された割り勘変更依頼情報に含まれる割り勘割合に基づいて、過不足金額を再計算する。

制御部１１は、端末２０から割り勘変更依頼情報を受信しなくなるまで（Ｓ４４０：ＮＯ）、Ｓ１９０、Ｓ４１０の処理を繰り返す。そして、端末２０から割り勘変更依頼情報を受信しなくなったと判定したならば（Ｓ４４０：ＮＯ）、制御部１１は、図２−１８のＳ２１０に処理を移す。

本変形例によれば、端末は、第１金額の情報と第２金額の情報とのうちの少なくともいずれかを変更するための情報を送信することで、第１金額の情報と第２金額の情報とのうちの少なくともいずれかを簡単に変更させることができる。

＜第４実施例＞
第４実施例は、自己の端末２０のユーザによる買い物決済履歴と、異なる端末２０のユーザによる買い物決済履歴とに基づいて、過不足金額を計算する実施例である。
第１実施例〜第３実施例とは、端末２０のユーザ、または異なる端末２０のユーザにより、買い物決済履歴を追加して登録することが可能に構成されている点が異なる。

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

＜表示画面例＞
図４−１は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
本実施例では、第１のユーザが割り勘対象とする買い物決済履歴を登録済みの状態で、さらに、第１のユーザとは異なる第２のユーザが割り勘対象とする買い物決済履歴を追加して登録することが可能に構成されている。ここでは、先に例示したように、ユーザＡ．Ａによって自身の買い物決済履歴が登録された状態で、ユーザＢ．Ｂが自身の買い物決済履歴を追加して登録する場合を例示する。

この割り勘内容確認画面は、図３−４の割り勘内容確認画面とほぼ同様であるが、画面下部に表示されるアイコンが異なっている。具体的には、限定ではなく例として「精算する」と示された精算アイコンに加えて、自分（ユーザＢ．Ｂ）の買い物決済履歴を追加登録するための、限定ではなく例として「支払い分を追加」と示された買い物決済履歴追加アイコンが表示されている。

図４−２は、図４−１の割り勘内容確認画面において買い物決済履歴追加アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、ユーザＢ．Ｂによる複数の買い物決済履歴が表示されている。この例では、「ＤＤカフェ」、「ＥＥレストラン」、「ＦＦコンビニエンス」等の、複数の店舗での買い物決済履歴が表示されている。画面下部には、選択された買い物決済履歴を登録するための、限定ではなく例として「登録」と示された買い物決済履歴登録アイコンが表示されている。

図４−３は、図４−２の買い物決済履歴選択画面において買い物決済履歴登録アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される割り勘内容確認画面の一例を示す図である。
この例では、ユーザＡ．Ａによって先に登録されていた「４，５００円」分の買い物決済履歴に加えて、ユーザＢ．Ｂによって「５，５００円」分の買い物決済履歴が追加登録された状態が示されている。また、その結果、支払い済み金額一覧表示領域には、自分（ユーザＢ．Ｂ）のアイコン画像と関連付けて支払い済み金額「５，５００円」が表示され、ユーザＡ．Ａのアイコン画像と関連付けて支払い済み金額「４，５００円」が表示されている。

ここで、前述したように、各々の割り勘メンバーが登録した買い物決済履歴に基づく支払い済み金額を総計した金額を「支払総額」とする。そして、本実施例では、「１人あたり金額＝支払総額÷割り勘を行う人数」として計算する。

この例では、ユーザＡ．ＡとユーザＢ．Ｂとがそれぞれ買い物決済履歴を登録しているため、「ユーザＡ．Ａの支払い済み金額＋ユーザＢ．Ｂの支払い済み金額＝支払総額」となる。ユーザＡ．Ａの支払い済み金額は「４，５００円」であり、ユーザＢ．Ｂの支払い済み金額は「５，５００円」であるため、支払総額は「４，５００円＋５，５００円＝１０，０００円」となる。割り勘を行う人数は「５人」であるため、「１人あたり金額＝１０，０００÷５人＝２，０００円」となる。その結果、１人あたり金額として「２，０００円」が表示されている。

また、過不足金額一覧表示領域には、各々のユーザの支払い済み金額と、１人あたり金額とに基づき計算された過不足金額が表示されている。具体的には、自分（ユーザＢ．Ｂ）の過不足金額として「５，５００円−２，０００円＝＋３，５００円（３，５００円 受取）」が表示され、ユーザＡ．Ａの過不足金額として「４，５００円−２，０００円＝＋２，５００円（２，５００円 受取）」が表示され、それ以外の割り勘メンバーの過不足金額として「０円−２，０００円＝−２，０００円（２，０００円 支払い）」が表示されている。

図４−４は、図４−３の割り勘内容確認画面において精算アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、ユーザＢ．Ｂの過不足金額として「３，５００円 受取」が過不足金額表示領域に表示されている。

また、過不足金額表示領域が操作されると、その下に。ユーザＡ．Ａのコメントと、割り勘の内訳とが表示される。この例では、割り勘の内訳として、ユーザＡ．Ａによって登録された買い物決済履歴と、ユーザＢ．Ｂによって登録された買い物決済履歴とが表示されており、合計金額として「１０，０００円」が、１人あたり金額として「２，０００円」が表示されている。また、この例では、「ＥＥレストラン」の買い物決済履歴がユーザＢ．Ｂによって新しく登録された買い物決済履歴であることを示すため表示として、「ＥＥレストラン」の買い物決済履歴に関連付けられたユーザＢ．Ｂのアイコン画像の左上に「Ｎ（Ｎｅｗ）」のマークが付されて表示されている。

図４−５は、図４−３の割り勘内容確認画面において精算アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、ユーザＡ．Ａの過不足金額として「２，５００円 受取」が過不足金額表示領域に表示されている。

また、過不足金額表示領域が操作されると、その下に、自分（ユーザＡ．Ａ）のコメントと、割り勘の内訳とが表示される。表示されるコメントおよび割り勘の内訳は、図４−４と同様である。

＜機能構成＞
図４−６は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、支払いアプリケーション管理処理プログラム１５１と、支払いアプリケーションユーザ登録データ１５３と、ユーザ管理データベース１５５とに加えて、限定ではなく例として、割り勘管理データベース１５７が記憶される。

割り勘管理データベース１５７は、サーバ１０が端末２０のユーザによる割り勘を管理するためのデータベースであり、その一例である第１の割り勘管理データベース１５７Ａの構成例を図４−７に示す。
第１の割り勘管理データベース１５７Ａには、割り勘ごとの管理データとして、割り勘管理データが記憶される。

各割り勘管理データには、限定ではなく例として、割り勘管理ＩＤと、割り勘マスターＩＤと、割り勘メンバーＩＤと、買い物決済履歴管理データとが記憶される。

割り勘管理ＩＤには、その割り勘を固有に識別するためのＩＤ（識別情報）が記憶される。限定ではなく例として、複数のユーザのグループで割り勘を行うことが決定された場合、そのグループ内での割り勘を１つの単位として、固有のＩＤがサーバ１０によって設定されて記憶される。

割り勘マスターＩＤには、限定ではなく例として、割り勘マスターの支払いアプリケーションＩＤが記憶される。

割り勘メンバーＩＤには、各々の割り勘メンバーの支払いアプリケーションＩＤが記憶される。

買い物決済履歴管理データは、割り勘対象とされた１以上の買い物決済履歴を管理するためのデータであり、限定ではなく例として、決済者ＩＤと、買い物決済ＩＤと、割り勘対象金額とが関連付けて記憶される。

決済者ＩＤには、その買い物決済履歴について決済を行ったユーザの支払いアプリケーションＩＤが記憶される。この決済者ＩＤには、割り勘マスターＩＤに限らず、割り勘メンバーＩＤに含まれる各々のユーザのＩＤも記憶され得る。つまり、割り勘マスターが登録した買い物決済履歴に限らず、割り勘マスター以外の割り勘メンバーが登録した買い物決済履歴も、買い物決済履歴管理データに記憶される。

買い物決済ＩＤには、ユーザ管理データベース１５５に含まれる、その決済者ＩＤのユーザの支払いアプリケーションＩＤに対応するユーザ管理データにおいて、買い物決済履歴データに含まれる買い物決済履歴の買い物決済ＩＤのうち、その決済者ＩＤのユーザによって登録された買い物決済履歴に対応する買い物決済ＩＤが記憶される。

割り勘対象金額には、その買い物決済ＩＤに対応する買い物決済履歴の買い物決済金額を上限とする金額であって、割り勘対象とする金額として、その決済者ＩＤのユーザによって指定された金額が記憶される。

なお、割り勘メンバーＩＤについて、割り勘マスター以外の割り勘メンバーの支払いアプリケーションＩＤを記憶させるようにしてもよいし、そのようにしなくてもよい。つまり、割り勘マスターＩＤを割り勘メンバーＩＤの欄から除外するようにしてもよいし、そのようにしなくてもよい。

＜処理＞
図４−８は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
図４−８の処理は、図２−１６〜図２−１８の処理のうちの図２−１８の処理部分において、端末Ａの処理としてＡ５３０のステップを追加し、端末Ｂの処理としてＡ５３０のステップを追加し、サーバ１０の処理としてＳ５３０〜Ｓ５７０のステップを追加した処理である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。

Ａ２１０の後、端末Ａの制御部２１は、割り勘追加登録処理を実行する（Ａ５３０）。同様に、Ｂ２１０の後、端末Ｂの制御部２１は、割り勘追加登録処理を実行する（Ａ５３０）。

図４−９は、割り勘追加登録処理の流れの一例を示すフローチャートである。
制御部２１は、自己の端末２０のユーザが割り勘に同意したか否かを判定する（Ａ５３１０）。具体的には、限定ではなく例として、割り勘に同意する意思を示すための操作が入出力部２３に入力されたか否かを判定する。

割り勘に同意しないと判定した場合（Ａ５３１０：ＮＯ）、制御部２１は、買い物決済履歴を追加するか否かを判定する（Ａ５３２０）。具体的には、限定ではなく例として、買い物決済履歴を追加するための操作が入出力部２３に入力されたか否かを判定する。

買い物決済履歴を追加すると判定したならば（Ａ５３２０：ＹＥＳ）、制御部２１は、割り勘精算追加処理を実行する（Ａ５３３０）。そして、制御部２１は、限定ではなく例として、追加する買い物決済履歴の買い物決済ＩＤを含む割り勘精算追加通知を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５３４０）。

一方、買い物決済履歴を追加しないと判定したならば（Ａ５３２０：ＮＯ）、制御部２１は、割り勘精算拒否通知を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５３５０）。
また、割り勘に同意すると判定したならば（Ａ５３１０：ＹＥＳ）、制御部２１は、割り勘精算承認通知を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５３６０）。

Ａ５３４０、Ａ５３５０またはＡ５３６０の後、制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘変更通知を受信したか否かを判定し（Ａ５３７０）、受信したと判定したならば（Ａ５３７０：ＹＥＳ）、受信された割り勘変更通知を表示部２４に表示させる（Ａ５３８０）。そして、制御部２１は、Ａ５３１０に処理を戻す。

一方、割り勘変更通知を受信しなかったと判定したならば（Ａ５３７０：ＮＯ）、制御部２１は、割り勘追加登録処理を終了する。

Ｓ２１０の後、サーバ１０の制御部１１は、第２の割り勘承認管理処理を実行する（Ｓ５３０）。

図４−１０は、第２の割り勘承認管理処理の流れの一例を示すフローチャートである。
この処理は、第１の割り勘承認管理処理（図２−２０参照）におけるＳ２３１０のステップをＳ５３１０に置き換えるとともに、Ｓ５３２０〜Ｓ５３４０のステップを追加した処理である。本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」と、「割り勘精算追加通知」とのうちのいずれかの通知である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。

制御部１１は、端末２０から割り勘精算通知を受信すると（Ｓ５３１０）、受信された割り勘精算通知が「割り勘精算追加通知」であるか否かを判定する（Ｓ５３２０）。受信された割り勘精算通知が割り勘精算追加通知ではないと判定したならば（５３２０：ＮＯ）、制御部１１は、Ｓ２３２０に処理を移す。

一方、受信された割り勘精算通知が割り勘精算追加通知であると判定したならば（Ｓ５３２０：ＹＥＳ）、制御部１１は、第１の割り勘管理データベース１５７Ａのうちの、対応する割り勘管理データにおける買い物決済履歴管理データを更新する。そして、制御部１１は、受信された割り勘精算追加通知に含まれる買い物決済ＩＤによって識別される買い物決済履歴に基づいて、過不足金額を計算する（Ｓ５３３０）。

その後、制御部１１は、計算した過不足金額に基づいて、割り勘内容を変更する（Ｓ５３４０）。そして、制御部１１は、第２の割り勘承認管理処理を終了する。

図４−８に戻り、制御部１１は、第２の割り勘承認管理処理で割り勘内容が変更されたか否かを判定し（Ｓ５５０）、変更されたと判定したならば（Ｓ５５０：ＹＥＳ）、割り勘変更通知を、通信Ｉ／Ｆ１４によって端末Ａおよび端末Ｂそれぞれに送信する（Ｓ５７０）。そして、制御部１１は、Ｓ５３０に処理を戻す。

一方、第２の割り勘承認管理処理で割り勘内容が変更されなかったと判定したならば（Ｓ５５０：ＮＯ）、制御部１１は、Ｓ２４０に処理を移す。

Ａ５３０の後、端末Ａの制御部２１は、Ａ２５０に処理を移す。同様に、Ａ５３０の後、端末Ｂの制御部２１は、Ｂ２５０に処理を移す。

＜第４実施例の効果＞
第４実施例は、各々の割り勘メンバーの過不足金額（限定ではなく、第１金額、第２金額の一例）は、一の端末２０のユーザとは異なる割り勘メンバーによる買い物決済履歴（限定ではなく、異なる端末のユーザによる第２決済に関する第２決済情報の一例）と、一のユーザによる買い物決済履歴（限定ではなく、第１決済情報の一例）とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第１決済情報ばかりでなく、異なる端末のユーザによる第２決済に関する第２決済情報も考慮して、第１金額と第２金額とを決定させることができるため、ユーザの利便性を向上させることができる。

＜第４変形例（１）＞
第４実施例において、割り勘マスターのユーザが、他の割り勘メンバーによる買い物決済履歴の追加の許可／禁止の設定を行うことができるようにしてもよいし、そのようにしなくてもよい。

図４−１１は、本変形例において、図３−１の買い物決済履歴選択画面において割り勘内容確認アイコンが操作されたことに基づいて、割り勘マスターであるユーザＡ．Ａの端末２０の表示部２４に表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面では、支払い済み金額表示領域において、自分（ユーザＡ．Ａ）以外の割り勘メンバーのアイコン画像およびユーザ名と関連付けて、その割り勘メンバーが自身の買い物決済履歴を追加するための、限定ではなく例として「追加依頼」と示された買い物決済履歴追加依頼アイコンが表示されている。割り勘マスターであるユーザＡ．Ａは、限定ではなく例として、各々の割り勘メンバーに関連付けられた買い物決済履歴追加依頼アイコンをタッチ操作することで、その割り勘メンバーによる買い物決済履歴の追加の許可／禁止の設定を行うことが可能に構成されている。

、
買い物決済履歴追加依頼アイコンは、限定ではなく例として、買い物決済履歴の追加が許可された割り勘メンバーについてはアクティブ状態で表示され、買い物決済履歴の追加が禁止された割り勘メンバーについては非アクティブ状態で表示される。この例では、割り勘マスターであるユーザＡ．Ａによって、ユーザＥ．Ｅによる買い物決済履歴の追加を禁止する設定が行われ、これにより、ユーザＥ．Ｅに関連付けられた追加依頼アイコンが非アクティブ状態で表示されている。

これは、ユーザＡ．Ａ〜ユーザＥ．Ｅのグループで旅行に行った際の買い物決済履歴を割り勘することをユーザＡ．Ａが提案した場合、限定ではなく例として、この旅行に関して、ユーザＥ．Ｅが「１円」も金銭を支払っていないことをユーザＡ．Ａが覚えており、ユーザＥ．Ｅが買い物決済履歴を追加することはあり得ない（またはユーザＥ．Ｅが買い物決済履歴を追加することを認めない）とユーザＡ．Ａが判断したような場合である。

これはあくまでも一例であるが、割り勘マスターが、特定の割り勘メンバーについて、買い物決済履歴が追加されることはないと判断した場合や、買い物決済履歴を追加することを認めないと判断したような場合に、その割り勘メンバーによる買い物決済履歴の追加を禁止するようにすることができる。

図４−１２は、この例においてユーザＥ．Ｅの端末２０の表示部２４に表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面では、買い物決済履歴を追加登録するための買い物決済履歴追加アイコンが画面下部に設けられている。しかし、上記のように、ユーザＥ．Ｅによる買い物決済履歴の追加が禁止されたことで、買い物決済履歴追加アイコンが非アクティブ状態で表示されており、この買い物決済履歴追加アイコンに対する操作が無効化される（操作が行われても買い物決済履歴の追加に関する処理を実行しない）ようになっている。

この場合は、割り勘マスターの端末２０から、サーバ１０を介して、少なくとも買い物決済履歴の追加を禁止した割り勘メンバーの端末２０に、買い物決済履歴の追加を禁止するための買い物決済履歴追加禁止情報を送信する。そして、買い物決済履歴追加禁止情報を受信した端末２０は、買い物決済履歴追加禁止の設定を行い、買い物決済履歴の追加操作を無効化するようにすればよい。

なお、上記の例では、買い物決済履歴の追加登録の許可／禁止の設定を行う主体を割り勘マスターとしたが、これに限定されず、割り勘マスターに加えて、または割り勘マスターに代えて、割り勘マスター以外の割り勘メンバーが、買い物決済履歴の追加登録の許可／禁止の設定を行うことができるようにしてもよいし、そのようにしなくてもよい。

＜第５実施例＞
第５実施例は、メッセージングサービスを利用して、複数の端末２０のユーザ間で割り勘を行う実施例である。
第５実施例は、第１実施例〜第４実施例の構成に、メッセージングサービスに関する構成が追加された実施例である。

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

＜システム構成＞
図５−１は、本実施例における通信システム１Ｂのシステム構成の一例を示す図である。なお、通信システム１Ａと同様の構成については同一の符号を付して、再度の説明を省略する。

通信システム１Ｂでは、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、メッセージングサーバ４０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）とが接続される。

メッセージングサーバ４０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、メッセージングサービスを提供する機能を有する。

メッセージングサーバ４０は、メッセージングサービスに関する機能を実現できる情報処理装置であればどのような装置であってもよい。メッセージングサーバ４０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。

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

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

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

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

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

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

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

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

＜表示画面例＞
図５−２は、本実施例におけるトークルーム画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
このトークルーム画面は、端末２０で実行されるメッセージングアプリケーションを利用して、ユーザＡ．ＡがユーザＢ．Ｂとトークを行うための画面の一例である。トークはチャットの一例であり、トークルームはチャットルームの一例である。

ここで、「チャット」とは、コンピュータネットワーク上のデータ通信回線を用いて端末２０のユーザ同士がコミュニケーションを行うための手段であり、「チャットルーム」は、このチャットを行うための仮想的な部屋である。チャットには、メッセージングサービスＭＳ（インスタントメッセージングサービス（ＩＭＳ）を含む。）、ソーシャルネットワーキングサービスＳＮＳを利用するものを含む。また、限定ではなく例として、いわゆるショートメッセージサービスを利用するものを含めてもよい。

本実施例において、チャットには、メッセージングサービスを利用したトークが含まれ、チャットルームには、トークを行うためのトークルームが含まれる。トークルームには、本実施例のように、一対一でユーザがトークを行うためのトークルームの他、後述するように、メッセージングサービスにおいて形成された複数のユーザを含むグループでトークを行うためのグループトークルームが含まれる。

限定ではなく例として、画面向かって右側には、ユーザＡ．Ａから発信されたメッセージが吹き出しで表示される。
一方、画面向かって左側には、トーク相手であるユーザＢ．Ｂのアイコン画像と関連付けて、ユーザＢ．Ｂから発信されたメッセージ（限定ではなく、コンテンツの一例）が吹き出しで表示される。

メッセージを送信した後、送信先の端末２０でメッセージングアプリケーションのトークルーム画面が開かれると、送信したメッセージが相手方のユーザによって読まれたことになる。そして、送信元の端末２０のトークルーム画面では、サーバ１０の制御に基づき、送信したメッセージと関連付けて「既読」の文字が表示される。

なお、送信先の端末２０でメッセージングアプリケーションのトークルーム画面が開かれるまでの間は「既読」の文字が表示されないようにすることができる。このようにすることで、「未読」の状態であることを送信元の端末２０のユーザが認識できるようにすることができる。

この例では、ユーザＡ．ＡからユーザＢ．Ｂに対して、先の旅行で使った金額の割り勘をリクエストするメッセージが表示されており、ユーザＢ．Ｂからの返信のメッセージとして、割り勘の依頼に承認するメッセージが表示されている。

また、画面下部には、メッセージングアプリケーションの機能として備えられた複数の機能に対応する機能アイコンが表示されている。この機能アイコンには、割り勘を行うための割り勘アイコンが含まれる。

図５−３は、図５−２のトークルーム画面において割り勘アイコンが操作（限定ではなく例としてタッチ操作）されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面の構成は、先の実施例で示した買い物決済履歴選択画面とほぼ同様であるが、メッセージングアプリケーションの機能として表示される画面である点が異なる。この買い物決済履歴選択画面には、先の実施例で示した例と同様に、「ＡＡレンタサイクル」、「ＢＢスーパー」、「ＣＣ弁当」等の、複数の店舗での買い物決済履歴が表示されるとともに、各々の買い物決済履歴と関連付けて、その買い物決済履歴を割り勘対象とするためのチェックボックスが設けられている。

また、画面下部には、ユーザＡ．Ａの端末２０からユーザＢ．Ｂの端末２０に割り勘リクエストを送信するための、限定ではなく例として「割り勘リクエストを送る」と示された割り勘リクエストアイコンが表示されている。

図５−４は、図５−３の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、図５−３のトークルーム画面におけるユーザＢ．ＢからユーザＡ．Ａに対する割り勘の依頼に承認するメッセージの下に、メッセージングアプリケーションを利用して端末２０間で送受信されるコンテンツの一例であって、割り勘リクエスト通知に相当するメッセージである「割り勘リクエストメッセージ」が、ユーザＡ．Ａのアイコン画像と関連付けて吹き出しで表示されている。

ここで、割り勘リクエストメッセージは、単純なテキストばかりでなく、画像（静止画像、動画像等を含む。）、操作用情報（ボタン、アイコン等を含む。）、通信用情報やアクセス用情報（ＵＲＩ、ＵＲＬ等を含む。）など、送受信可能な各種の情報を含む広義の意味でのメッセージである。

なお、通常のテキストのメッセージと区別するために、割り勘リクエストメッセージではなく、割り勘リクエストコンテンツ等のように表現してもよいし、そのようにしなくてもよい。

この割り勘リクエストメッセージには、限定ではなく例として、支払いアプリケーションの名称（この例では「Ｐａｙｍｅｎｔ Ａｐｐ」）とともに、割り勘がリクエストされた旨と、ユーザＢ．Ｂの過不足金額と、割り勘の対象とされた買い物決済履歴の詳細とが含まれる。この例では、ユーザＢ．Ｂの過不足金額として「２，２５０円 支払い」が表示されている。

また、割り勘リクエストメッセージには、限定ではなく例として、ユーザＢ．ＢがユーザＡ．Ａに対して過不足金額分の金銭を送金して精算を行うための精算アイコンと、割り勘を拒否するための拒否アイコンとが含まれる。

図５−５は、図５−４のトークルーム画面において精算アイコンが操作されたことに基づいて表示されるトークルーム画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
このトークルーム画面では、限定ではなく例として、精算アイコンが操作されたことに基づいて、ユーザＢ．ＢからユーザＡ．Ａに対するメッセージとして「精算する」というメッセージが吹き出しで表示されるとともに、支払いアプリケーションを利用してユーザＢ．ＢからユーザＡ．Ａに対して過不足金額（この例では「２，２５０円」）を送金したことを示す送金完了メッセージが表示されている。

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

図５−７は、本実施例においてメッセージングサーバ４０の記憶部４５に記憶される情報の一例を示す図である。
記憶部４５には、プログラムとして、限定ではなく例として、メッセージングアプリケーション管理処理プログラム４５１が記憶される。

また、記憶部４５には、データとして、限定ではなく例として、メッセージングアプリケーションユーザ登録データ４５３と、割り勘管理データベース４５７とが記憶される。

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

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

メッセージングアプリケーションＩＤは、メッセージングアプリケーションのアカウント（アカウント情報）であって、端末２０、または端末２０のユーザを識別可能とするＩＤである。このメッセージングアプリケーションＩＤは、限定ではなく例として、メッセージングサーバ４０によって固有のＩＤが設定されて記憶される。

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

その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末２０のメールアドレス（端末メールアドレス）や、メッセージングアプリケーションにおける各種の認証に利用される認証パスワード、このユーザが使用するアイコンの画像データ（ユーザアイコン画像）、ユーザのプロフィール（ユーザプロフィール）等を含めるようにすることができる。
ただし、これらの情報は必須ではない。

割り勘管理データベース４５７は、メッセージングサーバ４０が端末２０のユーザ間での割り勘を管理するためのデータベースであり、その一例である第３の割り勘管理データベース４５７Ａの構成例を図５−９に示す。
第３の割り勘管理データベース４５７Ａには、割り勘ごとの管理データとして、割り勘管理データが記憶される。

各割り勘管理データには、限定ではなく例として、割り勘管理ＩＤと、割り勘マスターＩＤと、割り勘メンバーＩＤと、買い物決済履歴管理データとが記憶される。
割り勘管理ＩＤ、割り勘マスターＩＤ、割り勘メンバーＩＤは、前述した割り勘管理データベース１５７と同様である。

買い物決済履歴管理データには、限定ではなく例として、決済者ＩＤと、割り勘対象金額と、店舗名と、買い物決済日時と、その他情報とが関連付けて記憶される。

＜処理＞
図５−１０〜図５−１２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末Ａの制御部２１が実行するメッセージング割り勘処理（以下、「ＭＳＧ割り勘処理」と称する。）、端末Ｂの制御部２１が実行するＭＳＧ割り勘処理、メッセージングサーバ４０の制御部４１が実行するメッセージング割り勘管理処理（以下、「ＭＳＧ割り勘管理処理」と称する。）、サーバ１０の制御部１１が実行する割り勘精算管理処理をそれぞれ示している。

最初に、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によって割り勘開始通知をメッセージングサーバ４０に送信する（Ａ６１０）。通信Ｉ／Ｆ４４によって端末Ａから割り勘開始通知を受信すると（Ｍ６１０）、メッセージングサーバ４０の制御部４１は、端末Ａのユーザによる買い物決済履歴を要求する買い物決済履歴要求情報を通信Ｉ／Ｆ４４によってサーバ１０に送信する（Ｍ６２０）。

通信Ｉ／Ｆ１４によってメッセージングサーバ４０から買い物決済履歴要求情報を受信すると（Ｓ６２０）、サーバ１０の制御部１１は、端末Ａのユーザの支払いアプリケーションＩＤに関連付けられた買い物決済履歴を、通信Ｉ／Ｆ１４によってメッセージングサーバ４０に送信する（Ｓ６３０）。

通信Ｉ／Ｆ４４によってサーバ１０から買い物決済履歴を受信すると（Ｍ６３０）、制御部４１は、受信された買い物決済履歴を、通信Ｉ／Ｆ４４によって端末Ａに送信する（Ｍ６４０）。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０から買い物決済履歴を受信すると（Ａ６４０）、端末Ａの制御部２１は、第２の買い物決済履歴選択処理を実行する（Ａ６５０）。具体的には、端末Ａの制御部２１は、限定ではなく例として、端末Ａの記憶部２８に記憶された、ユーザＡ．Ａによる複数の買い物決済履歴の中から、入出力部２３に対する選択操作に基づいて、少なくとも１つの買い物決済履歴を選択する。

次いで、端末Ａの制御部２１は、Ａ６５０の処理結果に基づき、買い物決済履歴選択情報を通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ａ６６０）。

通信Ｉ／Ｆ４４によって端末Ａから買い物決済履歴選択情報を受信すると（Ｍ６６０）、制御部４１は、受信された買い物決済履歴選択情報に基づいて、第３の割り勘管理データベース４５７Ａのうちの、対応する割り勘管理データにおける買い物決済履歴管理データを更新する。そして、制御部４１は、受信された買い物決済履歴選択情報に基づいて過不足金額を計算する（Ｍ６７０）。

その後、制御部４１は、計算した過不足金額に基づき、割り勘精算依頼通知を通信Ｉ／Ｆ４４によって端末Ａおよび端末Ｂにそれぞれ送信する（Ｍ７１０）。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘精算依頼通知を受信すると（Ａ７１０）、端末Ａの制御部２１は、入出力部２３に対する操作入力に基づいて、割り勘に同意するか否かを判定する（Ａ７２０）。

割り勘に同意すると判定したならば（Ａ７２０：ＹＥＳ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によって割り勘精算承認通知をメッセージングサーバ４０に送信する（Ａ７３０）。

それに対し、割り勘に同意しないと判定したならば（Ａ７２０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によって割り勘精算拒否通知をメッセージングサーバ４０に送信する（Ａ７４０）。

端末Ｂの制御部２１は、端末ＡのＡ７１０〜Ａ７４０と同様の処理を行う（Ｂ７１０〜Ｂ７４０）。

Ｍ７１０の後、制御部４１は、メッセージング割り勘承認管理処理（以下、「ＭＳＧ割り勘承認管理処理」と称する。）を実行する（Ｓ）。

図５−１３は、ＭＳＧ割り勘承認管理処理の流れの一例を示すフローチャートである。
このＭＳＧ割り勘承認管理処理は、第１の割り勘承認管理処理（図２−２０参照）と同様である。つまり、制御部４１は、第１の割り勘承認管理処理のＳ２３１０〜Ｓ２３６０と同様の処理を行う（Ｍ７３１０〜Ｍ７３６０）。

図５−１１に戻り、ＭＧＳ割り勘承認管理処理で割り勘不成立と判定したならば（Ｍ７４０：ＮＯ）、制御部４１は、通信Ｉ／Ｆ４４によって割り勘不成立通知を端末Ａおよび端末Ｂにそれぞれ送信する（Ｍ７５０）。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘不成立通知を受信すると（Ａ７５０）、端末Ａの制御部２１は、受信された割り勘不成立通知を表示部２４に表示させる（Ａ７６０）。そして、端末Ａの制御部２１は、Ａ８９０に処理を移す。

同様に、通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘不成立通知を受信すると（Ｂ７５０）、端末Ｂの制御部２１は、受信された割り勘不成立通知を表示部２４に表示させる（Ｂ７６０）。そして、端末Ｂの制御部２１は、Ｂ８９０に処理を移す。

一方、ＭＧＳ割り勘承認管理処理で割り勘成立と判定したならば（Ｍ７４０：ＹＥＳ）、制御部４１は、通信Ｉ／Ｆ４４によって割り勘成立通知を端末Ａおよび端末Ｂにそれぞれ送信する（Ｍ８１０）。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘成立通知を受信すると（Ａ８１０）、端末Ａの制御部２１は、割り勘精算要求情報を通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ａ８２０）。

同様に、通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘成立通知を受信すると（Ｂ８１０）、端末Ｂの制御部２１は、割り勘精算要求情報を通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ｂ８２０）。

通信Ｉ／Ｆ４４によって端末Ａおよび端末Ｂからそれぞれ割り勘精算要求情報を受信すると（Ｍ８２０）、制御部４１は、割り勘精算要求情報を通信Ｉ／Ｆ４４によってサーバ１０に送信する（Ｍ８３０）。

通信Ｉ／Ｆ１４によってメッセージングサーバ４０から割り勘精算要求情報を受信すると（Ｓ８３０）、サーバ１０の制御部１１は、割り勘精算処理を行う（Ｓ８４０）。

次いで、制御部１１は、通信Ｉ／Ｆ１４によって割り勘精算結果をメッセージングサーバ４０に送信する（Ｂ８５０）。

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

通信Ｉ／Ｆ４４によってサーバ１０から割り勘精算結果を受信すると（Ｍ８５０）、制御部４１は、受信された割り勘精算結果を通信Ｉ／Ｆ４４によって端末Ａおよび端末Ｂにそれぞれ送信する（Ｍ８６０）。

その後、制御部４１は、処理を終了するか否かを判定し（Ｍ８９０）、処理を継続すると判定したならば（Ｍ８９０：ＮＯ）、Ｍ６１０に処理を戻す。一方、処理を終了すると判定したならば（Ｍ８９０：ＹＥＳ）、制御部４１は、ＭＳＧ割り勘管理処理を終了する。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘精算結果を受信すると（Ａ８６０）、端末Ａの制御部２１は、受信された割り勘精算結果を表示部２４に表示させる（Ａ８７０）。

同様に、通信Ｉ／Ｆ２２によってメッセージングサーバ４０から割り勘精算結果を受信すると（Ｂ８６０）、端末Ｂの制御部２１は、受信された割り勘精算結果を表示部２４に表示させる（Ｂ８７０）。

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

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

＜第５実施例の効果＞
第５実施例は、端末２０が、自己の端末２０のユーザと、異なる端末２０のユーザとを含み、自己の端末２０から異なる端末２０に送信されたメッセージ等（限定ではなく、コンテンツの一例）と、異なる端末２０から自己の端末２０に送信されたメッセージ等とを含むトークルーム（限定ではなく、チャットルームの一例）をメッセージングアプリケーションの画面に表示する。この場合、少なくとも自己の端末２０のユーザの過不足金額の情報（限定ではなく、第１金額の情報の一例）が、トークルームに表示される構成を示している。
このような構成により得られる効果の一例として、第１金額の情報をチャットルームでユーザに確認させることができる。

また、第５実施例は、異なる端末２０のユーザは、端末２０のユーザによって選択されたトークルームに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによって選択されたチャットルームに基づいて、異なる端末のユーザを簡単に選択することができる。

また、第５実施例は、端末２０が、自己の端末２０のユーザと、異なる端末２０のユーザとを含み、自己の端末２０から異なる端末２０に送信されたメッセージ（限定ではなく、コンテンツの一例）と、異なる端末２０から自己の端末２０に送信されたメッセージ（限定ではなく、コンテンツの一例）とを含むトークルーム（限定ではなく、チャットルームの一例）を表示部２４に表示する。そして、端末２０は、割り勘リクエストメッセージ（限定ではなく、第１決済情報に基づく、少なくとも端末と異なる端末との送金処理、または受取処理のリクエストに関する通知の一例）をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末と異なる端末との送金処理、または受取処理のリクエストに関する通知を、チャットルームへの表示という分かり易い形で、ユーザに報知することができる。

また、第５実施例は、端末２０が、自己の端末２０のユーザを少なくとも含み、自己の端末２０から送信されたメッセージ（限定ではなく、コンテンツの一例）を含むトークルーム（限定ではなく、チャットルームの一例）を表示部２４に表示する。そして、端末２０は、割り勘リクエストメッセージ（限定ではなく、第１決済情報の送信に関する通知の一例）をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、第１決済情報の送信に関する通知を、チャットルームへの表示という分かり易い形で、ユーザに報知することができる。

＜第５変形例（１）＞
第５実施例において、メッセージングアプリケーションにおいて、端末２０が、送金処理、または受取処理に関するサービスを提供する企業のアカウントから発信されるメッセージ等のコンテンツをトークルームに表示するようにすることもできる。

図５−１４は、本変形例におけるトークルーム画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
このトークルーム画面は、図５−５のトークルーム画面とほぼ同様であるが、トークルームに表示されるユーザＢ．Ｂのトーク相手が、ユーザＡ．Ａではなく、支払いアプリケーションの公式アカウント（限定ではなく、送金処理、または受取処理に関するサービスを提供する企業のアカウントの一例）である点が異なる。この例において、ユーザＢ．Ｂは、メッセージングアプリケーションにおいて、あらかじめ支払いアプリケーションの公式アカウントを友だち登録しておく。

この場合、ユーザＢ．ＢからユーザＡ．Ａへの送金が完了すると、ユーザＢ．Ｂの端末２０のメッセージングアプリケーションのトークルーム画面に、限定ではなく例として、支払いアプリケーションの公式アカウントのアイコン画像（この例では「Ｐａｙ」）と関連付けて、支払いアプリケーションの公式アカウント（より具体的にはサーバ１０）から発信されたメッセージとして、ユーザＡ．Ａのユーザへの送金を完了したことを示す送金完了メッセージが表示されている。この送金完了メッセージは、送金完了通知に相当するメッセージであり、限定ではなく例として、支払いアプリケーションの名称（この例では「Ｐａｙｍｅｎｔ Ａｐｐ」）とともに、支払いアプリケーションを利用してユーザＢ．ＢからユーザＡ．Ａに対して過不足金額（この例では「２，２５０円」）を送金したことを示す内容が含まれる。

また、送金完了メッセージの下には、同じく支払いアプリケーションの公式アカウントから発信されたメッセージとして、割り勘完了メッセージが表示されている。

本変形例は、メッセージングアプリケーションのトークルーム画面は、端末２０のユーザと、支払いサービスの公式アカウント（限定ではなく、送金処理、または受取処理に関するサービスを提供する企業のアカウントの一例）とを含む構成を示している。
このような構成により得られる効果の一例として、送金処理、または受取処理に関するサービスを提供する企業のアカウントから配信される情報を、チャットルームへの表示という分かり易い形でユーザに報知することができる。

＜第５変形例（２）＞
第５実施例において、限定ではなく例として、割り勘リクエストが行われた後、割り勘メンバーが割り勘の精算をしばらくの間行わなかったような場合に、割り勘マスターの端末２０から、メッセージングサーバ４０を介して割り勘の催促やリマインドを行うようにすることもできる。

図５−１５は、図５−４においてユーザＢ．ＢがユーザＡ．Ａに対する返信を行わずに一定時間が経過した場合にユーザＢ．Ｂの端末２０の表示部２４に表示される割り勘リクエストリマインド通知の一例を示す図である。
この例では、端末２０のＯＳ標準の待機画面に、限定ではなく例として、メッセージングサーバ４０からのプッシュ通知であって、ユーザＡ．Ａから割り勘リクエストのリマインドがあったことを通知するための割り勘リクエストリマインド通知として、「Ｍｅｓｓａｇｉｎｇ Ａｐｐ Ａ．Ａ：割り勘のリクエストがあります」の文字とともに、メッセージングアプリケーションを起動するための、限定ではなく例として「開く」と示された起動アイコンが表示されている。

図５−１６は、図５−１５において起動アイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、図５−４のトークルーム画面における割り勘リクエストメッセージの下に、メッセージングアプリケーションを利用して端末２０間で送受信されるコンテンツの一例であって、割り勘の再確認（リマインド）をユーザに促すための割り勘リマインド通知の一種である割り勘リマインドメッセージが表示されている。

この割り勘リマインドメッセージには、限定ではなく例として、「リマインド」の文字および支払いアプリケーションの名称「Ｐａｙｍｅｎｔ Ａｐｐ」とともに、図５−４のトークルーム画面における割り勘リクエストメッセージと同様の内容が表示されている。この割り勘リマインドメッセージを確認することで、ユーザＢ．Ｂは、忘れずに割り勘の精算を行うことができる。

図５−１７は、この場合におけるトークルーム画面の別例を示す図である。
このトークルーム画面は、図５−１４と同様に、ユーザＢ．Ｂと支払いアプリケーションの公式アカウントとの間で行われるトークの画面の一例を示す図である。
この例では、支払いアプリケーションの公式アカウントから発信されたメッセージとして、図５−１６と同様の割り勘リマインドメッセージが、公式アカウントのアイコン画像と関連付けて表示されている。

＜第６実施例＞
第６実施例は、メッセージングアプリケーション内で形成される複数の端末２０のユーザ（複数のアカウント）を含むグループ内で割り勘を行うための実施例である。
第６実施例は、第５実施例にグループの概念が追加された実施例である。

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

＜表示画面例＞
図６−１は、本実施例におけるメッセージングアプリケーションによるグループトークルーム画面の一例を示す図である。
このグループトークルーム画面は、限定ではなく例として、５人のユーザ（ユーザＡ．Ａ〜ユーザＥ．Ｅ）を含むグループ（この例では「旅行サークル」のグループ）でグループトークを行うためのトークルーム画面を示しており、ユーザＡ．Ａの端末２０の表示部２４に表示されるグループトークルーム画面の一例を示している。グループトークはチャットの一例であり、グループトークルームはチャットルームの一例である。

このグループトークルーム画面では、限定ではなく例として、画面向かって右側に、自分（ユーザＡ．Ａ）から発信されたメッセージが表示され、画面向かって左側に、他のユーザ（ユーザＢ．Ｂ〜ユーザＥ．Ｅ）から発信されたメッセージが表示される。

この例では、ユーザＡ．Ａから発信された、先の旅行で使った金銭の割り勘をリクエストするメッセージが表示されており、ユーザＢ．Ｂから発信されたユーザＡ．Ａのリクエストを承認するメッセージとともに、ユーザＤ．Ｄから発信された、また旅行に行くことを提案するメッセージが表示されている。

画面下部には、メッセージングアプリケーションの複数の機能それぞれに対応する機能アイコンが表示されており、この例では、右下に表示された「割り勘アイコン」がユーザＡ．Ａによってタッチ操作された状態が示されている。

図６−２は、図６−１のグループトークルーム画面において割り勘アイコンが操作されたことに基づいて端末２０の表示部２４に表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、自分（ユーザＡ．Ａ）による複数の買い物決済履歴が表示されている。この例では、「ＡＡレンタサイクル」、「ＢＢスーパー」、「ＣＣ弁当」等の、複数の買い物決済履歴が表示されている。

図６−３は、図６−２の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいて端末２０の表示部２４に表示されるグループトークルーム画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
このグループトークルーム画面では、ユーザＡ．Ａからの割り勘リクエストメッセージとして、支払いアプリケーションの名称（この例では「Ｐａｙｍｅｎｔ Ａｐｐ」）と、ユーザＢ．Ｂの過不足金額（この例では「９００円 支払い」）と、各割り勘メンバーの割り勘の内容（割り勘の内訳）とを含むメッセージが表示されている。また、割り勘リクエストメッセージには、限定ではなく例として、精算を行うための精算アイコンと、自分の買い物決済履歴による支払い分を登録するための買い物決済履歴登録アイコンと、割り勘リクエストを断るための拒否アイコンとが含まれる。

＜データ構成＞
図６−４は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、メッセージングアプリケーション管理処理プログラム４５１と、メッセージングアプリケーションユーザ登録データ４５３と、割り勘管理データベース４５７とに加えて、グループ管理データベース４５９が記憶される。

図６−５は、本実施例における割り勘管理データベース４５７の一例である第４の割り勘管理データベース４５７Ｂのデータ構成例を示す図である。
第４の割り勘管理データベース４５７Ｂでは、各割り勘管理データにおいて、第３の割り勘管理データベース４５７Ａ（図５−９参照）の各割り勘管理データにおける割り勘メンバーＩＤに代えて割り勘グループＩＤが記憶される。

割り勘グループＩＤには、このグループについて、グループ管理データベース４５９に記憶されているグループＩＤが記憶される。

また、各々の割り勘管理データには、割り勘メンバーＩＤが記憶される。割り勘メンバーＩＤには、割り勘グループＩＤによって識別されるグループに含まれるユーザのメッセージングアプリケーションＩＤが記憶される。

なお、本実施例では、割り勘グループＩＤによって識別されるグループに含まれる全てのユーザのメッセージングアプリケーションＩＤが割り勘メンバーＩＤに含まれることとするが、これに限定されない。
限定ではなく例として、グループに含まれる全てのユーザではなく、グループに含まれる一部のユーザを割り勘メンバーとすることもできる。この場合は、グループに含まれるユーザのうち、割り勘メンバーとして選択されたユーザのメッセージングアプリケーションＩＤを、割り勘メンバーＩＤの欄に記憶させるようにすればよい。

図６−６は、グループ管理データベース４５９のデータ構成の一例を示す図である。
グループ管理データベース４５９には、グループごとに生成されるグループ管理データが記憶される。
各グループ管理データには、限定ではなく例として、グループＩＤと、グループ名と、グループメンバーデータとが記憶される。

グループメンバーデータには、限定ではなく例として、このグループに含まれるユーザのユーザ名と、このユーザのメッセージングアプリケーションＩＤとが関連付けて記憶される。

＜処理＞
図６−７は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図５−１０〜図５−１２の処理のうちの図５−１０の処理部分に、端末Ａの処理としてＡ９１０のステップ、メッセージングサーバ４０の処理としてＭＳＧ割り勘管理処理９１０のステップ、サーバ１０の処理としてＳ６２０、Ｓ６３０のステップを追加した処理である。

最初に、端末Ａの制御部２１は、グループでの割り勘の開始を要求するためのグループ割り勘開始通知を、通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ａ９１０）。そして、端末Ａの制御部２１は、Ａ６４０に処理を移す。

通信Ｉ／Ｆ４４によって端末Ａからグループ割り勘開始通知を受信すると（Ｍ９１０）、メッセージングサーバ４０の制御部４１は、Ｍ６２０に処理を移す。

＜第６実施例の効果＞
第６実施例は、端末２０は、グループトークルーム（限定ではなく、チャットルームの一例）は、割り勘マスター以外の複数の割り勘メンバーを含み、割り勘マスターの過不足金額の情報（限定ではなく、第１金額の情報の一例）と、割り勘マスター以外の各々の割り勘メンバーの過不足金額の情報（限定ではなく、第１決済情報に基づく、複数のユーザの各々が送金、または受け取る金額の情報の一例）とを含む過不足金額情報をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが送金、または受け取る第１金額と、異なる端末のユーザを含む複数のユーザの各々が送金、または受け取る金額とを、チャットルームへの表示という分かりやすい形でユーザに報知することができる。

＜第６変形例（１）＞
第６実施例において、グループに含まれる複数のユーザのうちの少なくとも一人のユーザを割り勘メンバーから除外する処理を行うようにしてもよいし、そのようにしなくてもよい。

図６−８は、端末２０の表示部２４に表示される割り勘対象メンバーを選択（設定）するための割り勘対象メンバー選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘対象メンバー選択画面では、割り勘を行うグループ（この例では「旅行サークル」のグループ）（以下、「対象グループ」と称する。）に含まれる自分以外のメンバー（ユーザＢ．Ｂ〜ユーザＥ．Ｅ）のアイコン画像およびユーザ名と関連付けて、チェックボックスが設けられている。

限定ではなく例として、初期状態では、全員のチェックボックスにチェックが入れられているが、チェックを外す操作を行うことにより、そのチェックを外したユーザを割り勘メンバーから除外することができるように構成されている。この例では、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅにはチェックが入れられているが、ユーザＣ．Ｃのチェックは外された状態が示されている。

また、画面下部には、割り勘対象メンバーとして現在設定されているユーザ（チェックボックスにチェックが入れられているユーザ）が表示される割り勘対象メンバー表示領域が設けられている。割り勘対象メンバー表示領域には、限定ではなく例として、割り勘対象メンバーとして現在設定されているユーザのアイコン画像およびユーザ名が表示されている。また、アイコン画像の右上には「×マーク」が表示されており、この「×マーク」を操作することで、そのユーザを割り勘対象メンバーから除外することができるように構成されている。この例では、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅが割り勘対象メンバーとして設定された状態が示されている。

図６−９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図６−７の処理に、端末Ａの処理としてＡ９２０〜Ａ９４０のステップを追加し、メッセージングサーバ４０の処理としてＭ９２０、Ｍ９４０のステップを追加した処理である。

Ｍ９１０の後、メッセージングサーバ４０の制御部４１は、そのグループに含まれるメンバーの情報（以下、「グループメンバー情報」と称する。）を、通信Ｉ／Ｆ４４によって端末Ａに送信する（Ｍ９２０）。

通信Ｉ／Ｆ２２によってメッセージングサーバ４０からグループメンバー情報を受信すると（Ａ９２０）、端末Ａの制御部２１は、第２のメンバー選択処理を実行する（Ａ９３０）。具体的には、限定ではなく例として、図６−８のような割り勘メンバー選択画面を表示部２４に表示させ、入出力部２３に対する選択操作に基づいて、割り勘をリクエストするメンバーを選択する。

その後、端末Ａの制御部２１は、Ａ９３０で選択したメンバーに関するメンバー選択情報を、通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ａ９４０）。そして、端末Ａの制御部２１は、Ａ６４０に処理を移す。

通信Ｉ／Ｆ４４によって端末Ａからメンバー選択情報を受信すると（Ｍ９４０）、制御部４１は、受信されたメンバー選択情報に基づくユーザを割り勘メンバーに追加／割り勘メンバーから削除した後、Ｍ６２０に処理を移す。

本変形例は、一の端末２０が、グループトークルーム（限定ではなく、チャットルームの一例）に含まれる、複数のユーザの中から少なくとも一人のユーザを割り勘メンバーから削除する処理を実行する構成を示している。
このような構成により得られる効果の一例として、チャットルームに含まれる、異なる端末のユーザを含む複数のユーザから、少なくとも一人のユーザを削除する処理を実行することで、限定ではなく例として、任意のユーザを割り勘の対象から除外することができる。

＜第６変形例（２）＞
第６実施例において、限定ではなく例として、割り勘マスターの端末２０で、グループトークルームに含まれないユーザ（以下、「グループ外メンバー」と称する。）を割り勘メンバーに追加する処理を行うようにしてもよいし、そのようにしなくてもよい。

図６−１０は、本変形例における割り勘対象メンバー選択画面の一例を示す図である。
この割り勘対象メンバー選択画面では、図６−８の割り勘対象メンバー選択画面とは異なり、対象グループに含まれるユーザ以外のユーザの中から割り勘メンバー候補を追加するための、限定ではなく例として「グループ以外の友だちを追加」と示された追加アイコンが設けられている。

図６−１１は、図６−１０の割り勘対象メンバー選択画面において追加アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
この画面では、画面中央部に、友だち登録されているユーザの中から割り勘対象メンバー候補を選択・設定するための友だち一覧表示領域が設けられている。友だち一覧表示領域には、対象グループに含まれる割り勘メンバーとは異なるユーザであって、ユーザＡ．Ａが友だち登録しているユーザのアイコン画像とユーザ名とが一覧表示されている。この例では、ユーザＸ．Ｘ、ユーザＹ．Ｙ、ユーザＺ．Ｚ等が一覧表示されており、ユーザＺ．Ｚのチェックが「ＯＮ」とされた状態が示されている。

また、図６−８、図６−９と同様に、画面下部には、割り勘対象メンバー表示領域が設けられている。この例では、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅに加えて、ユーザＺ．Ｚが割り勘対象メンバー候補として設定された状態が示されている。

また、画面下部には「ＯＫアイコン」が表示されており、このＯＫアイコンが操作されることで、現在設定されているユーザで割り勘対象メンバーを確定させることができるように構成されている。

図６−１２は、図６−１１の割り勘対象メンバー選択画面においてＯＫアイコンが操作されたことに基づいて表示される割り勘対象メンバー選択画面の一例を示す図である。
この割り勘対象メンバー選択画面では、グループメンバーとして、対象グループに含まれるユーザの一覧が表示されており、その下に、友だちとして、図６−１１の画面において割り勘対象メンバーとして加えたグループ外メンバーであるユーザＺ．Ｚのアイコン画像およびユーザ名が表示されている。この例では、対象グループに含まれるユーザのうち、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅの３人のチェックが「ＯＮ」とされるとともに、追加されたユーザＺ．Ｚのチェックが「ＯＮ」とされた状態が示されている。

また、画面下部の割り勘対象メンバー表示領域には、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅに加えて、ユーザＺ．Ｚが割り勘対象メンバー候補として設定された状態が示されている。

図６−１３は、図６−６の割り勘対象メンバー選択画面において買い物決済履歴登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面は、図６−２の買い物決済履歴選択画面に対応しており、この例では、画面下部の割り勘リクエストアイコンがユーザＡ．Ａによって操作された状態が示されている。

図６−１４は、図６−１３の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいて端末２０の表示部２４に表示されるグループトークルーム画面の一例を示す図であり、ユーザＺ．Ｚの端末２０の表示部２４に表示される画面の一例を示している。
このグループトークルーム画面では、図６−３と同様に、ユーザＡ．Ａからの割り勘リクエストメッセージが表示されている。そして、この例では、割り勘リクエストメッセージに含まれる買い物決済履歴登録アイコンがユーザＺ．Ｚによって操作された状態が示されている。

図６−１５は、図６−１４のグループトークルーム画面において買い物決済履歴登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図であり、ユーザＺ．Ｚの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面には、限定ではなく例として、ユーザＺ．Ｚによる買い物決済履歴として、「ＨＨスーパー」、「ＩＩカフェ」、「ＪＪ電器」等の、複数の買い物決済履歴が表示されている。そして、この例では、「ＩＩカフェ」の買い物決済履歴にチェックが入れられた状態が示されている。

図６−１６は、図６−１５の買い物決済履歴選択画面において登録アイコンが操作されたことに基づいて表示されるグループトークルーム画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
このグループトークルーム画面には、限定ではなく例として、ユーザＺ．Ｚに関連付けられた割り勘リクエストメッセージとして、ユーザＡ．Ａによって登録された買い物決済履歴に基づく割り勘内容と、ユーザＺ．Ｚによって登録された買い物決済履歴に基づく割り勘内容とを含む割り勘リクエストメッセージが表示されている。

図６−１７は、端末２０の表示部２４に表示される割り勘メンバー選択画面の別例を示す図である。
この割り勘メンバー選択画面では、図６−１０の割り勘メンバー選択画面とは異なり、対象グループに含まれるユーザ以外のユーザを割り勘メンバー候補として追加するための、限定ではなく例として「グループ以外の友だちを追加」と示された領域に、メッセージングアプリケーションにおいて友だち登録されているユーザの中から割り勘メンバー候補とするユーザを選択するための、限定ではなく例として「友だちから追加」と示された第１追加アイコンと、電話番号を入力して割り勘メンバー候補とするユーザを選択するための、限定ではなく例として「電話番号で検索」と示された第２追加アイコンとが表示されている。

図６−１８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図６−９の処理に、端末Ａの処理としてＡ９５０のステップを追加し、メッセージングサーバ４０の処理としてＭ９５０のステップを追加した処理である。

Ｍ９４０の後、端末Ａの制御部２１は、限定ではなく例として、図６−１０、図６−１１のような割り勘メンバー選択画面を表示部２４に表示させ、入出力部２３に対する選択操作に基づいて、グループ外メンバーを選択する。そして、端末Ａの制御部２１は、選択したグループ外メンバーに関するグループ外メンバー選択情報を、通信Ｉ／Ｆ２２によってメッセージングサーバ４０に送信する（Ａ９５０）。そして、端末Ａの制御部２１は、Ａ６４０に処理を移す。

通信Ｉ／Ｆ４４によって端末Ａからグループ外メンバー選択情報を受信すると（Ｍ９５０）、制御部４１は、受信されたグループ外メンバー選択情報に基づくグループ外メンバーを割り勘メンバーに追加した後、Ｍ６２０に処理を移す。

本変形例は、一の端末２０が、グループトークルーム（限定ではなく、チャットルームの一例）に含まれないユーザを割り勘メンバーとして追加する処理を実行する。そして、端末２０は、グループトークルームに追加されたユーザの過不足金額（限定ではなく、チャットルームに含まれない追加されたユーザが送金、または受け取る第３金額の一例）の情報と、一の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）の情報と、グループに含まれる他の端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）の情報とを含む過不足金額情報をサーバ１０から通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信された過不足金額情報をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、チャットルームに含まれないユーザを追加した上で、第１金額および第２金額ばかりでなく、追加されたユーザが送金、または受け取る第３金額も考慮した金額情報を、チャットルームへの表示という分かりやすい形でユーザに報知することができる。

また、本変形例は、上記の第１金額と、第２金額と、第３金額とは、グループトークルームに含まれない追加されたユーザによる買い物決済履歴と、割り勘マスターによる買い物決済履歴とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第１金額と、第２金額と、第３金額とが、チャットルームに含まれない追加されたユーザによる第３決済に関する処理に基づく第３決済情報と、第１決済情報とに基づいて、適切に決定されるようにすることができる。

＜第６変形例（３）＞
第６実施例において、ユーザによっては、他のユーザに割り勘をリクエストすることに気まずさを感じ、割り勘をリクエストすることを躊躇する場合もあると考えられる。
そこで、限定ではなく例として、グループ名に基づいて、割り勘リクエスト通知を端末２０の表示部２４に表示させるようにしてもよいし、そのようにしなくてもよい。

図６−１９は、本変形例において端末２０の表示部２４の待機画面に表示される割り勘リクエスト通知の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この待機画面には、限定ではなく例として、メッセージングアプリケーションと関連付けられたプッシュ通知であって、割り勘リクエストがあったことを通知するための割り勘リクエスト通知として、「Ｍｅｓｓａｇｉｎｇ Ａｐｐ 旅行サークル 割り勘のリクエストがあります」の文字とともに、メッセージングアプリケーションを起動するための、限定ではなく例として「開く」と示された起動アイコンが表示されている。

図５−１５に示した待機画面における割り勘リクエスト通知のように、割り勘マスターのユーザからの割り勘リクエストとするのではなく、割り勘マスターが割り勘をリクエストしたグループ（この例では、グループ名「旅行サークル」のグループ）からの割り勘リクエストとして表示している点が、図５−１５の割り勘リクエスト通知とは異なる。

図６−２０は、図６−１９の待機画面において起動アイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、「旅行サークル」のグループからの割り勘リクエストとして、このグループのアイコン画像およびグループ名と関連付けて、割り勘リクエストメッセージが表示されている。

本変形例は、端末２０が、自己の端末２０のユーザと、異なる端末２０のユーザとを含み、自己の端末２０から異なる端末２０に送信されたメッセージと、異なる端末２０から自己の端末２０に送信されたメッセージとを含むグループトークルームを表示部２４に表示する。そして、端末２０は、異なる端末２０から割り勘リクエスト通知を通信Ｉ／Ｆ２２によって受信した場合、このグループトークルームのグループ名に基づき、割り勘リクエスト通知をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、異なる端末から、決済に関する決済情報に基づく、送金処理、または受取処理のリスクエストの通知を通信部によって受信した場合、チャットルームのグループ名に基づき、リクエストの通知をチャットルームに表示するため、異なる端末からのリクエストの通知であることを秘匿することができる。その結果、他のユーザにリクエストを行う心理的な負担を軽減することができる。

＜第７実施例＞
第７実施例は、異なる端末２０のユーザが割り勘メンバーを追加する実施例である。
第７実施例は、上記の実施例に、異なる端末２０のユーザが割り勘メンバーを追加する構成を追加した実施例である。

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

＜表示画面例＞
図７−１は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘内容確認画面の構成は、限定ではなく例として、図３−２とほぼ同様であるが、表示が一部異なっている。具体的には、この割り勘内容確認画面には、限定ではなく例として、精算を実行させるための精算アイコンと、買い物決済履歴を追加するための買い物決済履歴追加アイコンと、割り勘メンバーを追加するための割り勘メンバー追加アイコンとが画面下部に表示されている。

図７−２は、図７−１の割り勘内容確認画面において割り勘メンバー追加アイコンが操作されたことに基づいて表示される割り勘メンバー検索画面の一例を示す図である。
この割り勘メンバー検索画面には、「電話番号を入力して検索してください」の文字とともに、入力された電話番号が表示される電話番号表示欄が設けられている。電話番号表示欄の右には、入力された電話番号のユーザを検索するための検索ボタンが設けられており、この検索ボタンが操作されたことに基づいて、入力された電話番号のユーザが検索される。この例では、検索結果として「ユーザＦ．Ｆ」が得られ、ユーザＦ．Ｆのアイコン画像とユーザ名とが表示された状態が示されている。

また、検索結果の下には、検索結果として得られたユーザを割り勘メンバーに追加するための、限定ではなく例として「メンバーに追加」と示された割り勘メンバー追加アイコンが表示されている。

図７−３は、図７−２の割り勘メンバー検索画面において割り勘メンバー追加アイコンが操作されたことに基づいて表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面には、図７−２において検索結果として得られたユーザＦ．Ｆが割り勘メンバーとして追加された結果、自分（ユーザＢ．Ｂ）、ユーザＡ．Ａ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅに加えて、ユーザＦ．Ｆのアイコン画像およびユーザ名が関連付けられた支払い済み金額一覧表示領域および過不足金額一覧表示領域が表示されている。

＜第７実施例の効果＞
第７実施例は、割り勘マスターとは異なる割り勘メンバーの端末２０（限定ではなく、第１端末の一例）によって、当初設定された割り勘メンバーとは異なる端末２０（限定ではなく、第２端末の一例）のユーザを追加する処理が実行される。そして、この場合における過不足金額情報には、追加されたユーザの過不足金額（限定ではなく、第４金額）の情報が含まれる構成を示している。
このような構成により得られる効果の一例として、第１端末とは異なる第２端末のユーザを追加した上で、追加された第２端末のユーザが送金、または受け取る第４金額の情報を取得することができる。

＜第８実施例＞
第８実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
端末２０のユーザによっては、割り勘対象とする買い物決済履歴を自分で検索して選択するのが面倒な場合がある。これは、買い物決済履歴の数が多い場合に顕著である。

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

本実施例では、端末２０の制御部２１が、自己の端末２０のユーザのユーザ情報に基づいて、買い物決済履歴を自動選択する。本実施例では、自己の端末２０のユーザのユーザ情報を、限定ではなく例として、自己の端末２０、または自己の端末２０のユーザに関する位置の情報とする場合を例示する。

買い物決済履歴の自動選択とは、自動的に選択した買い物決済履歴を割り勘対象として最終決定すること（最終決定して登録すること）を含む他、自動的に選択した買い物決済履歴を割り勘対象の候補として提案（サジェストとも言う。）することも含まれる。後者の場合は、制御部２１によって自動選択されて提案された買い物決済履歴の中から、ユーザが手動で買い物決済履歴を選択して最終決定することになる。
これは、後述する実施例においても同様である。

＜表示画面例＞
図８−１は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面では、割り勘対象とする買い物決済履歴を自動的に選択するための、限定ではなく例として「支払い候補を検索」と示された検索アイコンが表示されている。

図８−２は、図８−１の買い物決済履歴選択画面において検索アイコンが操作されたことに基づいて表示される表示例を示す図である。
この画面では、図８−１の買い物決済履歴選択画面における複数の買い物決済履歴のうち、「ＡＡレンタサイクル」の買い物決済履歴と、「ＢＢスーパー」の買い物決済履歴とが選択された状態の表示（以下、「選択表示」と称する。）として、他の買い物決済履歴（限定ではなく例として「ＣＣ弁当」の買い物決済履歴）とは異なる態様で表示されている。この選択表示された買い物決済履歴は、端末２０の制御部２１によって自動選択されて提案（サジェスト）された買い物決済履歴である。

なお、選択表示は、非選択の買い物決済履歴と異なる態様の表示とすることができる。
限定ではなく例として、選択された買い物決済履歴の表示領域に特定の色（青色、緑色、赤色等）やハッチング（網掛け等）を施した態様、選択された買い物決済履歴の表示領域の枠（外枠）に特定の色を施す態様、選択された買い物決済履歴の表示領域の枠（外枠）を点滅させた態様、選択された買い物決済履歴の文字のフォントを特殊なフォントで表した態様、といった複数の態様のうちのいずれかの態様を、選択表示の態様として適用することができる。

このように、少なくとも１つの買い物決済履歴が選択表示された状態で、画面下部の割り勘リクエストアイコンが操作されると、選択表示された買い物決済履歴を割り勘対象として登録することが可能となる。

＜データ構成＞
図８−３は、本実施例においてサーバ１０の記憶部１５に記憶されるユーザ管理データベース１５５の一例である第３のユーザ管理データベース１５５Ｃの一例を示す図である。
この第３のユーザ管理データベース１５５Ｃの各ユーザ管理データには、限定ではなく例として、支払いアプリケーションＩＤと、電子マネー口座残高と、買い物決済履歴データとが記憶される。

買い物決済履歴データには、限定ではなく例として、買い物決済ＩＤと、店舗ＩＤと、店舗名と、買い物決済日時と、買い物決済金額と、買い物決済内容と、買い物決済位置情報とが関連付けて記憶される。
買い物決済ＩＤ〜買い物決済内容は、前述した通りである。

買い物決済位置情報には、限定ではなく例として、買い物決済が行われた際の端末２０、または端末２０のユーザの位置情報が記憶される。
なお、買い物決済位置情報には、２次元の位置情報を記憶させるようにしてもよいし、３次元の位置情報を記憶させるようにしてもよい。

この場合、１つの手法として、定期的なタイミングや、端末２０に決済を行う操作がなされたタイミングで、端末２０からサーバ１０に対して、算出端末位置の情報を送信するようにすることができる。そして、サーバ１０は、買い物決済処理において、端末２０から受信した最新の算出端末位置の情報を買い物決済位置情報として、他の情報と関連付けてユーザ管理データに記憶させるようにすることができる。

なお、ユーザが忘れずに端末２０を所持しているのであれば、端末２０の位置は、その端末２０のユーザの位置と同じとなる。このため、算出端末位置は、算出された端末２０の位置であるとともに、算出された端末２０のユーザの位置とも言える。

本実施例では、限定ではなく例として、端末２０のユーザによる登録操作に従って、端末２０のユーザの居住地（またはその周辺エリア）、端末２０のユーザの勤務地（またはその周辺エリア）、端末２０のユーザの親族や友人の居住地（またはその周辺エリア）、端末２０のユーザが頻繁に訪れる場所等の、端末２０のユーザの日常の生活範囲や活動範囲として想定される位置情報を、特定位置情報としてあらかじめ支払いアプリケーション等において登録しておくこととする。

なお、特定位置情報は、サーバ１０の記憶部１５に記憶されて管理されるようにしてもよいし、端末２０の記憶部２８に記憶されて管理されるようにしてもよい。または、サーバ１０と端末２０との両方に記憶されて管理されるようにしてもよい。

＜処理＞
図８−４は、本実施例において各々の装置が実行する処理の流れの一例を示す図である。
この処理は、図２−１７〜図２−１９の処理のうちの図２−１７の処理部分について、端末Ａの処理として、Ａ１７０のステップをＡ１７５のステップに置き換えた処理である。

Ｓ１５０の後、サーバ１０の制御部１１は、端末Ａのユーザに関連付けられた複数の買い物決済履歴（買い物決済位置情報を含む。）を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｓ１６０）。

通信Ｉ／Ｆ２２によってサーバ１０から買い物決済履歴（買い物決済位置情報を含む。）を受信すると（Ａ１６０）、端末Ａの制御部２１は、買い物決済履歴自動選択処理を実行する（Ａ１７５）。具体的には、限定ではなく例として、複数の買い物決済履歴のうち、その買い物決済位置が、あらかじめ登録された特定位置情報に対応する特定位置から設定距離以上（または設定距離超）、距離が離れている買い物決済履歴を特定する。そして、特定した買い物決済履歴を、割り勘対象とする買い物決済履歴として選択する。

このようにして買い物決済履歴を自動選択したならば、端末Ａの制御部２１は、限定ではなく例として、自動選択した買い物決済履歴を割り勘対象の候補としてピックアップ表示するなどして、端末２０のユーザに提案（サジェスト）する。そして、端末Ａの制御部２１は、Ａ１８０に処理を移す。

このようにすることで、端末２０のユーザの日常の生活範囲や活動範囲として登録された位置から大きく離れた位置で行われた買い物決済に対応する買い物決済履歴を自動選択することができる。

なお、選択した買い物決済履歴を端末２０のユーザに提案する処理は必須ではなく、この処理は省略してもよい。

また、ここでは、端末２０の制御部２１が、図２−１７の処理における第２の買い物決済履歴選択処理に代えて、買い物決済履歴自動選択処理を実行する場合を例示したが、これに限定されない。限定ではなく例として、端末２０の制御部２１が、図１の処理における第１の買い物決済履歴選択処理に代えて、買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。

＜第８実施例の効果＞
第８実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴（限定ではなく、複数の決済情報の一例）のうち、自動選択した買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によってサーバ１０に送信する。また、端末２０は、送信された買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）を制御部２１（限定ではなく、端末の制御部の一例）によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第１決済情報を通信部によって送信したことに基づいて、その第１決済情報に基づく第１金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。

また、第８実施例は、端末２０は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末２０のユーザによる複数の買い物決済履歴（限定ではなく、複数の決済情報の一例）のうち、自動選択した買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）によってサーバ１０に送信することと、送信された買い物決済履歴に基づく過不足金額（限定ではなく、第１決済情報に基づく、端末のユーザが送金、または受け取る第１金額と、端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも第１金額の一例）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信することと、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第１金額に基づく送金処理、または受取処理の一例）とを実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。

また、第８実施例は、端末２０は、買い物決済履歴を、端末２０のユーザのユーザ情報に基づいて選択する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザに則した第１決済情報を選択することができる。

また、第８実施例は、上記のユーザ情報は、算出端末位置（限定ではなく、端末、または端末のユーザに関する位置の一例）の情報を含む構成を示している。
このような構成により得られる効果の一例として、端末は、端末、または端末のユーザに関する位置を考慮して、第１決済情報を適切に選択することができる。

＜第８変形例（１）＞
第８実施例で説明した買い物決済履歴自動選択処理における買い物決済履歴の選択方法はあくまでも一例であり、これに限定されない。

限定ではなく例として、端末２０のユーザの居住地等がある都道府県や市町村をあらかじめ登録しておくようにし、登録された都道府県とは異なる都道府県で決済された買い物決済履歴を選択したり、登録された市町村とは異なる市町村で決済された買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

また、あらかじめ有名な観光地の位置情報を地図データと関連付けて記憶部２８に記憶しておく。そして、制御部２１は、記憶部２８に記憶されている観光地に対応する位置で決済された買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

＜第８変形例（２）＞
第８実施例では、自己の端末２０のユーザ情報を位置に関する情報として説明したが、これに限定されない。
限定ではなく例として、端末２０のユーザのスケジュール情報をユーザ情報に含めるようにし、端末２０の制御部２１が、端末２０のユーザのスケジュール情報に基づいて買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

図８−５は、本変形例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面では、買い物決済履歴検索アイコンが操作されたことに基づいて、「“Ｐａｙｍｅｎｔ Ａｐｐ”がカレンダーへのアクセスを求めています アクセスを許可すると、カレンダーから候補日を検索することができます。」の文字とともに、「許可しない」のボタンと、「ＯＫ」のボタンとが、画面中央部にポップアップ形式で表示されている。

この場合、「ＯＫ」のボタンが操作されると、限定ではなく例として、端末２０のＯＳ標準の機能として備えられたカレンダー機能によって登録されたユーザのスケジュール情報が、制御部２１によって参照される。そして、制御部２１によって、参照されたスケジュール情報に含まれるイベント情報に基づいて、買い物決済履歴が選択される。

なお、端末２０のＯＳ標準のカレンダー機能によって登録されたユーザのスケジュール情報に代えて、またはこれに加えて、支払いアプリケーションやメッセージングアプリケーションのカレンダー機能によって登録されたユーザのスケジュール情報を参照するようにしてもよいし、そのようにしなくてもよい。

カレンダー機能によって登録されたユーザのスケジュール情報には、限定ではなく例として、端末２０のユーザによって入力されたイベント情報を含めることができる。

１つの手法として、制御部２１は、ユーザのスケジュール情報の中から、旅行、バーベキュー、飲み会といった、複数のユーザの参加が想定されるイベント情報を特定する。そして、複数の買い物決済履歴の中から、特定したイベント情報に関連付けられた日時（イベントの開催日時）に近い日付（限定ではなく例として、過去１週間以内の日付）に決済された買い物決済履歴を選択する。

また、他の手法として、制御部２１は、ユーザのスケジュール情報の中から、旅行、バーベキュー、飲み会といった、複数のユーザの参加が想定されるイベント情報を特定する。そして、複数の買い物決済履歴の中から、特定したイベント情報に関連する商品が購入された買い物決済履歴を選択する。限定ではなく例として、「バーベキュー」のイベントを特定した場合、バーベキューに関連する商品を買い物決済内容に含む買い物決済履歴を選択する。

この場合、制御部２１は、限定ではなく例として、炭や着火剤、軍手といった着火に必要な商品を買い物決済内容に含む買い物決済履歴、包丁、ナイフ、まな板といった調理に必要な商品を買い物決済内容に含む買い物決済履歴、肉（牛肉、豚肉、鶏肉等）、野菜、魚介類、調味料といった食材となる商品を買い物決済内容に含む買い物決済履歴、等の買い物決済履歴を、手動選択買い物決済履歴と関連する買い物決済履歴として選択する。

また、これらを組み合わせて、制御部２１が、特定したイベント情報の開催日時に近い日付（限定ではなく例として、過去１週間以内の日付）に決済された買い物決済履歴であり、かつ、特定したイベント情報に関連する商品を買い物決済内容に含む買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

また、上記の他にも、限定ではなく例として、端末２０のユーザがメッセージングアプリケーション等を利用して送信したメッセージに関する情報をユーザ情報に含めるようにし、端末２０の制御部２１が、このメッセージに関する情報に基づいて買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

図８−６は、本変形例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面では、買い物決済履歴検索アイコンが操作されたことに基づいて、「チャット履歴から支払い候補を検索しますか？ 以前のチャット履歴から支払い候補の提案をおこないます。」の文字とともに、「検索する」のボタンと、「今はしない」のボタンとが、画面中央部にポップアップ形式で表示されている。

この場合、「検索する」のボタンが操作されると、限定ではなく例として、メッセージングアプリケーションのトークルームのメッセージの履歴が、制御部２１によって参照される。そして、制御部２１によって、参照されたメッセージの内容に基づいて、買い物決済履歴が選択される。

１つの手法として、制御部２１は、限定ではなく例として、端末２０のユーザが送信した過去のメッセージの中から、限定ではなく例として、割り勘を提案する内容のメッセージや、割り勘を示唆する内容のメッセージを検索する。限定ではなく例として、制御部２１は、相手に割り勘を求めるメッセージ（限定ではなく例として「割り勘をしませんか」、「割り勘をお願いします」等のメッセージ）を検索する。そして、その検索結果として得られたメッセージ中に、またはそのメッセージとは別のメッセージ中に、割り勘対象とする買い物決済履歴を推定可能な情報があるか否かを判定する。限定ではなく例として、日付や日時の情報が含まれるのであれば、その日付や日時に対応する買い物決済日時が含まれる買い物決済履歴を、提案する買い物決済履歴として選択することができる。

また、他の手法として、制御部２１は、メッセージングアプリケーション内で形成されたグループの中から、そのグループ名に、割り勘を示唆する名称が付けられたグループを特定する。限定ではなく例として、「割り勘」、「わりかん」、「精算」、「せいさん」、「決済」、「けっさい」、「支払い」、「しはらい」、「送金」、「そうきん」等の用語をグループ名に含むグループを特定する。そして、特定したグループについて、そのグループトークルームに含まれるメッセージの内容に基づいて、上記と同様にして、提案する買い物決済履歴として選択する。

本変形例は、ユーザ情報は、端末２０のユーザのスケジュール情報を含み、買い物決済履歴は、スケジュール情報に含まれるイベント情報に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザのスケジュール情報に含まれるイベント情報に基づき、端末のユーザが参加したイベントを考慮して、第１決済情報を適切に選択することができる。

また、本変形例は、ユーザ情報は、端末２０のユーザから発信されたメッセージに関する情報を含み、買い物決済履歴は、このメッセージに関する情報に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザに基づいて送信されたメッセージに関する情報に基づいて、第１決済情報を適切に選択することができる。

なお、上記の他にも、限定ではなく例として、自己の端末２０のユーザの性別、年齢、職業等の属性情報をユーザ情報に含めるようにし、端末２０の制御部２１が、これらの属性情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、限定ではなく例として、自己の端末２０のユーザの性別、年齢、職業等の属性情報のうちの少なくとも１つの情報に基づいて、自己の端末２０のユーザの参加が想定されるイベントを推定する。そして、その推定結果に基づいて、自己の端末２０のユーザの買い物決済履歴の中から、推定したイベントに関連する買い物決済履歴を選択する。

＜第８変形例（３）＞
第８実施例では、端末２０の制御部２１が買い物決済履歴自動選択処理を実行することとしたが、これに限定されない。

各々の端末２０のユーザの買い物決済履歴のデータは、サーバ１０の記憶部１５に記憶・管理されている。このため、端末２０の制御部２１に代えて、サーバ１０の制御部１１が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。
これは、以下説明する実施例においても同様である。

図８−７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図２−１７〜図２−１９の処理のうちの図２−１７の処理部分について、端末Ａの処理として、Ａ１５０のステップをＡ１５１のステップに置き換え、Ａ１６０のステップをＡ１６３のステップに置き換え、Ａ１７０のステップを削除した処理である。また、サーバ１０の処理として、Ｓ１５０のステップをＳ１５１のステップに置き換え、Ｓ１６１のステップを追加し、Ｓ１６０のステップをＳ１６３のステップに置き換えた処理である。

Ａ１３０の後、端末Ａの制御部２１は、限定ではなく例として、買い物決済履歴の選択を要求する買い物決済履歴選択要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５１）。

通信Ｉ／Ｆ１４によって端末Ａから買い物決済履歴選択要求情報を受信すると（Ｓ１５１）、サーバ１０の制御部１１は、買い物決済履歴自動選択処理を実行する（Ｓ１６１）。
この処理における買い物決済履歴の選択方法としては、前述した端末２０の制御部２１による選択方法と同様の方法を適用することが可能である。

その後、制御部１１は、買い物決済履歴の選択結果を含む買い物決済履歴自動選択情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１６３）。

通信Ｉ／Ｆ２２によってサーバ１０から買い物決済履歴自動選択情報を受信したならば（Ａ１６３）、端末Ａの制御部２１は、限定ではなく例として、サーバ１０によって選択された買い物決済履歴を割り勘対象の候補としてピックアップ表示するなどして、端末２０のユーザに提案（サジェスト）する。そして、端末Ａの制御部２１は、Ａ１８０に処理を移す。

なお、サーバ１０によって選択された買い物決済履歴を端末２０のユーザに提案する処理は必須ではなく、この処理は省略してもよい。

本変形例によれば、サーバ１０が、端末２０のユーザによる決済に関する複数の買い物決済履歴のうち、一の買い物決済履歴を選択する処理を制御部１１によって実行する。サーバ１０は、選択した位置の買い物決済履歴に基づく、少なくとも一の端末２０のユーザの過不足金額（限定ではなく、第１金額）の情報を一の端末２０に送信し、少なくとも他の端末２０のユーザの過不足金額（限定ではなく、第２金額）の情報を他の端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、割り勘精算処理（限定ではなく、第１金額に基づく、端末に対する送金処理、または受取処理と、第２金額に基づく、異なる端末に対する送金処理、または受取処理との一例）を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、サーバによって、端末のユーザによる決済に関する複数の決済情報のうち、第１決済情報を選択する処理が実行され、その結果に基づいて、第１金額に基づく、端末に対する送金処理、または受取処理と、第２金額に基づく、異なる端末に対する送金処理、または受取処理とがサーバの制御部によって実行されるため、端末の処理負荷を軽減しつつ、端末に対する金額の送金、または受取と、異なる端末に対する送金、または受取とを実現することができ、ユーザの利便性を向上させることができる。

＜第９実施例＞
第９実施例は、第８実施例と同様に、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
第９実施例は、第８実施例とは異なり、端末２０が、自己の端末２０のユーザによる買い物決済履歴に関連する情報に基づいて買い物決済履歴を選択する点が異なる。

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

本実施例において、端末２０の制御部２１は、買い物決済履歴に関連する情報に基づいて、買い物決済履歴を自動的に選択する。
この買い物決済履歴に関連する情報には、限定ではなく例として、端末２０のユーザによって手動で選択された買い物決済履歴（以下、「手動選択買い物決済履歴」と称する。）とは異なる買い物決済履歴の日付、時刻、日時等の時間に関する情報が含まれる。

具体的には、制御部２１は、限定ではなく例として、手動選択買い物決済履歴と決済された日付が同じである買い物決済履歴を特定する。そして、特定した買い物決済履歴を、提案する買い物決済履歴として選択する。これは、手動選択買い物決済履歴と決済された日付が同じである買い物決済履歴も、手動選択買い物決済履歴と同様に、割り勘の対象とされる可能性が高いと考えられるためである。

＜表示画面例＞
図９−１は、本実施例における買い物決済履歴選択画面の一例を示す図である、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面では、「ＡＡレンタサイクル」、「ＢＢスーパー」、「ＣＣ弁当」等の複数の買い物決済履歴のうち、ユーザＡ．Ａの操作に従って、「ＢＢスーパー」の買い物決済履歴のチェックが「ＯＮ」とされた状態が示されている。

図９−２は、図９−１の買い物決済履歴選択画面において検索アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
この買い物決済履歴選択画面では、図９−１でチェックが「ＯＮ」とされた「ＢＢスーパー」の買い物決済履歴と同じ日付に決済が行われた買い物決済履歴である「ＡＡレンタサイクル」が、他の買い物決済履歴とは異なる態様で表示されている。

なお、上記とは異なり、限定ではなく例として、制御部２１が、手動選択買い物決済履歴と決済された曜日が同じである買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、制御部２１が、手動選択買い物決済履歴と決済された時刻や時間帯が同じである買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

＜第９実施例の効果＞
第９実施例は、端末２０が、買い物決済履歴に関連する情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、決済情報に関連する情報に基づいて、第１決済情報を適切に選択することができる。

また、第９実施例は、上記の買い物決済履歴に関連する情報は、手動選択買い物決済履歴とは異なる買い物決済履歴の日付、または時刻に関する情報を含む構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済情報とは異なる第２決済情報の日付、または時刻に関する情報に基づいて、第１決済情報を適切に選択することができる。

＜第９変形例（１）＞
第９実施例において、端末２０の制御部２１が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる商品情報やサービス情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、制御部２１は、限定ではなく例として、手動選択買い物決済履歴の買い物決済内容に基づいて、購入された商品や提供されたサービスを特定する。そして、特定した商品やサービスの内容に基づき、その手動選択買い物決済履歴に対応する買い物決済に関連するイベント（その買い物決済を行う必要が生じたイベント）を推定する。そして、制御部２１は、推定したイベントと、他の買い物決済履歴の買い物決済内容とに基づいて、買い物決済履歴を選択する。

限定ではなく例として、手動選択買い物決済履歴の買い物決済内容にグリル・コンロや鉄板・プレート・網、トング等の機材の商品が含まれる場合は、制御部２１は、これらの商品の内容に基づいて、その決済を行う必要が生じたイベントを「バーベキュー」と推定する。そして、その推定結果に基づいて、限定ではなく例として、その手動選択買い物決済履歴と決済が行われた日付が近い買い物決済履歴のうち、バーベキューに関連する商品を買い物決済内容に含む買い物決済履歴を選択する。

この場合、制御部２１は、限定ではなく例として、炭や着火剤、軍手といった着火に必要な商品を買い物決済内容に含む買い物決済履歴、包丁、ナイフ、まな板といった調理に必要な商品を買い物決済内容に含む買い物決済履歴、肉（牛肉、豚肉、鶏肉等）、野菜、魚介類、調味料といった食材となる商品を買い物決済内容に含む買い物決済履歴、等の買い物決済履歴を、手動選択買い物決済履歴と関連する買い物決済履歴として選択する。

また、第９実施例において、端末２０の制御部２１が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる店舗情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、制御部２１は、限定ではなく例として、手動選択買い物決済履歴に含まれる店舗名に基づいて、その手動選択買い物決済履歴に対応する買い物決済履歴に関連するイベント（その買い物決済を行う必要が生じたイベント）を推定する。そして、推定したイベントと、他の買い物決済履歴に含まれる店舗名とに基づいて、買い物決済履歴を選択する。

限定ではなく例として、手動選択買い物決済履歴に含まれる店舗名が、観光地に存在する店舗の名称（限定ではなく例として、「お土産屋」の店舗名）である場合、制御部２１は、その店舗名に基づいて、その決済を行う必要が生じたイベントを「旅行」と推定する。そして、その推定結果に基づいて、限定ではなく例として、その手動選択買い物決済履歴と決済が行われた日付が近い買い物決済履歴のうち、旅行に関連する商品やサービスを取り扱う店舗の店舗名を含む買い物決済履歴を選択する。

本変形例は、端末２０が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる商品情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済情報とは異なる第２決済情報に含まれる商品情報に基づいて、第１決済情報を適切に選択することができる。

また、本変形例は、端末２０が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる店舗情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済情報とは異なる第２決済情報に含まれる店舗情報に基づいて、第１決済情報を適切に選択することができる。

＜第９変形例（２）＞
第９実施例において、第８変形例（３）と同様に、端末２０の制御部２１が買い物決済履歴自動選択処理を実行するようにするのではなく、サーバ１０の制御部１１が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。

＜第１０実施例＞
第１０実施例は、第８実施例や第９実施例と同様に、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
第１０実施例は、第８実施例、第９実施例とは異なり、端末２０が、自己の端末２０とは異なる端末２０のユーザの情報に基づいて、買い物決済履歴を選択する。

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

本実施例において、端末２０の制御部２１は、自己の端末２０のユーザによって割り勘メンバーとして選択されたユーザの情報（他の割り勘メンバーの情報）に基づいて、買い物決済履歴を選択する。

この場合における他の割り勘メンバーの情報には、限定ではなく例として、他の割り勘メンバーのユーザにより決済された買い物決済履歴の情報を含めることができる。
本実施例では、制御部２１が、他の割り勘メンバーにより決済された買い物決済履歴の情報に基づいて、自己の端末２０の買い物決済履歴を選択する場合を例示する。

図１０は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図８−４の処理において、端末Ａの処理におけるＡ１５０のステップをＡ１５３のステップに置き換え、Ａ１６０のステップをＡ１６５のステップに置き換え、サーバ１０の処理におけるＳ１５０のステップをＳ１５３のステップに置き換え、Ｓ１６０のステップをＳ１６５のステップに置き換えた処理である。

Ａ１４０の後、端末Ａの制御部２１は、第２の買い物決済履歴要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５３）。具体的には、限定ではなく例として、自己の端末２０のユーザの買い物決済履歴と、Ａ１３０で選択した割り勘メンバーの買い物決済履歴とをサーバ１０に要求する処理を実行する。

通信Ｉ／Ｆ１４によって端末Ａから第２の買い物決済履歴要求情報を受信すると（Ｓ１５３）、サーバ１０の制御部１１は、受信された買い物決済履歴要求情報の送信元の端末２０のユーザの買い物決済履歴と、端末Ａによって選択された割り勘メンバーの買い物決済履歴とをユーザ管理データベース１５５から読み出して、第２の買い物決済履歴として通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１６５）。

通信Ｉ／Ｆ２２によってサーバ１０から第２の買い物決済履歴を受信すると（Ａ１６５）、端末Ａの制御部２１は、Ａ１７５へと処理を移す。

この場合、Ａ１７５の買い物決済履歴自動選択処理では、端末Ａの制御部２１は、自己の端末２０のユーザの買い物決済履歴の買い物決済日時と、選択された割り勘メンバーの買い物決済履歴の買い物決済日時とを参照し、限定ではなく例として、同時期に行われた買い物決済履歴を選択する。これは、同時期に買い物決済が行われた場合、自己の端末２０のユーザと選択された割り勘メンバーとが行動を共にしていた可能性があるためである。

なお、これに限らず、自己の端末２０のユーザの買い物決済履歴と、選択された割り勘メンバーの買い物決済履歴とで、限定ではなく例として、同じ種類の商品やサービス、相互に関連する商品やサービスが買い物決済内容に含まれる買い物決済履歴を選択するようにしてもよい。

第１０実施例は、端末２０が、自己の端末２０のユーザとは異なる端末２０のユーザの情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、異なる端末のユーザの情報に基づいて、第１決済情報を適切に選択することができる。

また、第１０実施例は、端末２０が、自己の端末２０のユーザとは異なる端末２０のユーザによる買い物決済履歴（限定ではなく、第３決済情報の一例）に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、異なる端末のユーザによる決済に関する第３決済情報に基づいて、第１決済情報を適切に選択することができる。

＜第１０変形例（１）＞
第１０実施例において、端末２０の制御部２１が、自己の端末２０のユーザによる複数の買い物決済履歴のうち、それらの複数の買い物決済履歴の各々に関連付けられた、自己の端末２０のユーザによって入力された情報に基づいて、割り勘対象とする買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、端末２０の制御部２１は、複数の買い物決済履歴のそれぞれについて、入出力部２３に対する操作に従って、メモやタグを設定する。メモは、その買い物決済履歴がどのような買い物の決済履歴であるかをユーザが後で確認できるようにするためのものであり、限定ではなく例として、決済で購入した商品の用途等をメモとして入力・設定しておくようにすることができる。

また、タグは、買い物決済履歴を種類や目的ごとに分類するためのもの（情報を分類するための札、ラベル）である。
タグとしては、限定ではなく例として、「買い物」、「仕事」、「デート」、「旅行」、「贈り物」、「その他」といった複数の種類を用意しておくことができ、端末２０のユーザが、各々の買い物決済履歴について、その種類や目的に応じたタグを選択・設定しておくようにすることができる。

この場合、制御部２１は、複数の買い物決済履歴の各々に関連付けられたメモの内容を参照し、割り勘が発生し得るイベントに関連する内容を直接的に示すメモ、または示唆するメモが関連付けられた買い物決済履歴を特定して選択する。

また、制御部２１は、限定ではなく例として、複数の買い物決済履歴の各々に関連付けられたタグを参照し、割り勘が発生し得るイベントに関連するタグ、限定ではなく例として、買い物、旅行等のタグが関連付けられた買い物決済履歴を特定して選択する。
なお、メモやタグについては、後述する実施例でより詳細に説明する。

＜第１０変形例（２）＞
他の割り勘メンバーのユーザの情報には、限定ではなく例として、端末２０のユーザのユーザ情報と同様に、他の割り勘メンバーのユーザの性別、年齢、職業等の属性情報を含めるようにすることができる。そして、これらの割り勘メンバーの属性情報に基づいて、買い物決済履歴を自動選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、限定ではなく例として、他の割り勘メンバーの性別、年齢、職業等の属性情報のうちの少なくとも１つの情報に基づいて、他の割り勘メンバーの参加が想定されるイベントを推定する。そして、その推定結果に基づいて、自己の端末２０のユーザの買い物決済履歴の中から、推定したイベントに関連する買い物決済履歴を選択する。

＜第１０変形例（３）＞
第１０実施例において、第８変形例（３）と同様に、端末２０の制御部２１が買い物決済履歴自動選択処理を実行するようにするのではなく、サーバ１０の制御部１１が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。

また、この場合、サーバ１０の制御部１１は、限定ではなく例として、端末２０の位置情報と、この端末２０のユーザによって割り勘メンバーとして選択されたユーザの端末２０の位置情報とを参照する。そして、端末２０のユーザと他の割り勘メンバーとで、相互に近い位置で決済が行われた買い物決済履歴を検索し、その検索結果として得られた買い物決済履歴を選択するなどすることができる。

＜第１１実施例＞
第１１実施例は、端末２０が、自己の端末２０以外の割り勘メンバーを自動的に選択する実施例である。
端末２０のユーザによっては、割り勘メンバーを自分で調べて選択するのは面倒な場合がある。これは、割り勘を希望するユーザの数が多い場合に顕著である。
第１１実施例は、第８実施例〜第１０実施例とは、端末２０が選択する対象が買い物決済履歴ではなく割り勘メンバーである。

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

本実施例では、端末２０の制御部２１は、限定ではなく例として、サーバ１０を介さない、端末２０同士の通知（いわゆるピアツーピア方式による通信）を行って、自己の端末２０の近くに位置する端末２０を検索する。そして、検索結果として得られた端末２０のユーザを、割り勘メンバー候補として選択する。

＜表示画面例＞
図１１−１は、本実施例における割り勘メンバー選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘メンバー選択画面では、未だ割り勘メンバーは選択されておらず、割り勘メンバーが１人もいない状態である。
画面下部には、割り勘メンバーを電話番号で検索するための、限定ではなく例として「電話番号で検索」と示された第１検索アイコンと、割り勘メンバーを位置情報に基づいて検索するための、限定ではなく例として「ちかくの人を検索」と示された第２検索アイコンとが表示されている。

図１１−２は、図１１−１の割り勘メンバー選択画面において第２検索アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
第２検索アイコンが表示されたことに基づいて、限定ではなく例として、自己の端末２０が近くに位置する端末２０との通信（ピアツーピア通信）を試行し、通信に成功した端末２０から取得した情報に基づいて、その端末２０のユーザを割り勘メンバー候補として提案（サジェスト）する。この例では、近くにいる人（ユーザ）として、ユーザＢ．Ｂ、ユーザＢ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅの４人が検索結果として得られ、限定ではなく例として、色が付された状態で表示されている。

また、検索結果として得られた各々のユーザには、そのアイコン画像およびユーザ名と関連付けて、チェックボックスが設けられている。自己の端末２０のユーザは、チェックボックスのチェックを「ＯＦＦ」とすることで、そのユーザを割り勘メンバーから除外することができる。この例では、ユーザＢ．Ｃに関連付けられたチェックボックスのチェックが「ＯＦＦ」とされ、ユーザＢ．Ｃが割り勘メンバーから除外された状態が示されている。

＜第１１実施例の効果＞
第１１実施例は、割り勘マスター以外の割り勘メンバー候補（限定ではなく、異なる端末のユーザの一例）は、割り勘マスターの端末２０の位置情報と、異なる端末２０の位置情報とに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザを、端末の位置情報と、異なる端末の位置情報とに基づいて簡単に選択することができる。

＜第１１変形例（１）＞
第１１実施例において、割り勘メンバー候補とするユーザの検索を、端末２０ではなくサーバ１０が実行するようにしてもよいし、そのようにしなくてもよい。

具体的には、限定ではなく例として、端末２０において割り勘メンバーの検索操作がなされたことを検知した場合、端末２０の制御部２１は、通信Ｉ／Ｆ２２によってユーザ検索要求をサーバ１０に送信する。

端末２０からユーザ検索要求を受信すると、サーバ１０の制御部１１は、限定ではなく例として、ユーザ検索要求の送信元の端末２０の最新の算出端末位置と、データベースで記憶・管理している各々の端末２０の最新の算出端末位置とに基づいて、ユーザ検索要求の送信元の端末２０の最新の算出端末位置との間の距離が設定距離以下（または設定距離未満）である端末２０を検索する。設定距離は、限定ではなく例として「１０メートル」程度の距離とすることができる。そして、検索結果として得られた端末２０のユーザを、割り勘メンバー候補として提案（サジェスト）する。

なお、この場合に、支払いアプリケーションを利用する全ての端末２０を対象として割り勘メンバー候補を検索しようとすると、サーバ１０の処理量が増大するという問題がある。そこで、サーバ１０が、検索範囲を設定して割り勘メンバー候補を検索するようにすることもできる。

この場合、端末２０のユーザがメッセージングアプリケーションを登録しているのであれば、サーバ１０は、メッセージングサーバ４０と通信を行い、ユーザ検索要求の送信元の端末２０のユーザが友だち登録しているユーザの情報を取得する。そして、取得されたユーザの情報に基づき、ユーザ検索要求の送信元の端末２０のユーザが友だち登録しているユーザを検索対象として、前述したように端末２０の位置情報に基づいて、割り勘メンバー候補とするユーザを検索する。

＜第１１変形例（２）＞
第１１変形例（１）において、サーバ１０が、限定ではなく例として、端末２０のユーザによって入力された日付の情報と、入力された日付の自己の端末２０の位置情報と、入力された日付の異なる端末２０の位置情報とに基づいて、割り勘メンバー候補とするユーザを検索するようにしてもよいし、そのようにしなくてもよい。

具体的には、限定ではなく例として、端末２０の制御部２１は、割り勘メンバーを検索する際に、日付を入力するようにユーザに促す。そして、制御部２１は、入力された日付の情報を含むユーザ検索要求を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。

端末２０からユーザ検索要求を受信すると、サーバ１０の制御部１１は、限定ではなく例として、受信されたユーザ検索要求に含まれる日付に基づき、そのユーザ検索要求の送信元の端末２０のその日付における算出端末位置の履歴と、データベースで記憶・管理している各々の端末２０のその日付における算出端末位置の履歴とに基づいて、割り勘メンバー候補を検索する。具体的には、限定ではなく例として、異なる端末２０のうち、その日付における同じ時間帯に、ユーザ検索要求の送信元の端末２０の近くに位置していた端末２０のユーザを、割り勘メンバー候補とするユーザとして選択する。

本変形例は、割り勘マスター以外の割り勘メンバー候補（限定ではなく、異なる端末のユーザの一例）は、入力された日付の割り勘マスターの端末２０の位置情報と、入力された日付の割り勘マスターの端末２０とは異なる端末２０の位置情報とに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによって入力された日付の情報を考慮して、異なる端末のユーザを、端末の位置情報と、異なる端末の位置情報とに基づいて簡単に選択することができる。

＜第１１変形例（３）＞
第１１実施例において、端末２０の制御部２１が、自己の端末２０のユーザと、異なる端末２０のユーザとの通話履歴に基づいて、割り勘メンバー候補を選択するようにしてもよいし、そのようにしなくてもよい。

具体的には、制御部２１は、限定ではなく例として、自己の端末２０の通話機能（電話機能）によって通話された他の端末２０のユーザとの通話履歴の情報を参照する。そして、制御部２１は、限定ではなく例として、手動選択買い物決済履歴の買い物決済日時と同じ日付や同じ時間帯に自己の端末２０のユーザと通話した端末２０のユーザを特定して、割り勘メンバー候補として選択する。

本変形例は、割り勘メンバー候補は、自己の端末２０のユーザとの通話履歴に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザとの通話履歴に基づいて、異なる端末のユーザを適切に選択することができる。

＜第１１変形例（４）＞
第１１実施例において、端末２０の制御部２１が、メッセージングアプリケーションを利用して送受信されたコンテンツ（メッセージや画像情報を含む。）に基づいて、割り勘メンバー候補を選択するようにしてもよいし、そのようにしなくてもよい。

限定ではなく例として、自己の端末２０のメッセージングアプリケーションを利用して送受信されたコンテンツを参照し、限定ではなく例として、手動選択買い物決済履歴の買い物決済日時と同じ日付や同じ時間帯にコンテンツを送受信したユーザを特定して、割り勘メンバー候補として選択する。

また、端末２０のカメラ２７によって撮像された撮像画像や、いわゆるライブビュー機能によって画面に映し出されたライブビュー画像を対象として、画像認識処理を実行する。そして、画像認識処理によって認識されたユーザを、割り勘メンバー候補として選択するようにしてもよいし、そのようにしなくてもよい。

＜第１２実施例＞
第１２実施例は、割り勘メンバーに含まれる少なくとも一人のユーザについて、電子マネーによる割り勘ではなく、現金での割り勘を実現する実施例である。
ユーザによっては、電子マネーによる送金を希望せず、現金で渡す（現金で支払う）ことを希望する場合がある。
第１２実施例は、上記の実施例とは、現金での割り勘を実現するための処理が追加されている点が異なる。

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

本実施例において、端末２０の制御部２１は、割り勘メンバーを選択する際に、ユーザ操作に従って、割り勘メンバーと関連付けて、電子マネーによる割り勘と、現金での割り勘とのいずれを要求するかの割り勘種別を選択する。そして、選択した買い物決済履歴と、選択した割り勘メンバーと、選択した割り勘種別とを含む買い物決済履歴選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。

通信Ｉ／Ｆ１４によって端末２０から買い物決済履歴選択情報を受信すると、サーバ１０の制御部１１は、受信された買い物決済履歴選択情報に基づいて、各々の割り勘メンバーについて、その割り勘メンバーに関連付けられた割り勘種別と、選択された買い物決済履歴とに基づいて、過不足金額を計算する。

＜表示画面例＞
図１２−１は、本実施例における割り勘メンバー選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示されるメッセージングアプリケーションの画面の一例を示している。この例では、メッセージングアプリケーションにおいて形成された、ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ、ユーザＤ．Ｄ、ユーザＥ．Ｅの５名のユーザで構成される旅行サークルのグループで割り勘を行う場合を例示する。

この割り勘メンバー選択画面では、割り勘メンバー候補とする各々のユーザのアイコン画像およびユーザ名と関連付けて、チェックボックスに加えて、割り勘種別を「現金」とするための、いわゆるラジオボタンに類する円形の割り勘種別選択ボタンが設けられている。割り勘種別選択ボタンは、各々の割り勘メンバー候補について「ＯＮ／ＯＦＦ」を切り替えることが可能に構成されている。

限定ではなく例として、初期状態において、割り勘種別選択ボタンは「ＯＦＦ」の状態（割り勘種別が「電子マネー」）となっており、割り勘種別選択ボタンがタッチ操作されると、割り勘種別選択ボタンの円の内部に黒丸が付されて「ＯＮ」の状態とされ、割り勘種別が「現金」に変更される。この例では、割り勘メンバー候補のうちのユーザＣ．Ｃに関連付けられた割り勘種別選択ボタンのチェックが「ＯＮ」とされた状態が示されている。

図１２−２は、図１２−１の割り勘メンバー選択画面において登録アイコンが操作されたことに基づいて表示される割り勘リクエスト通知画面の一例を示す図であり、割り勘メンバーの１人であるユーザＣ．Ｃの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘リクエスト通知画面は、上記の旅行サークルのグループにおけるグループトークルーム画面であり、割り勘マスターであるユーザＡ．Ａから発信された割り勘リクエストメッセージが表示されている。

割り勘リクエストメッセージには、ユーザＣ．Ｃの過不足金額として、その金額の値（この例では「９００円」）とともに、ユーザＣ．Ｃの割り勘種別を示す「現金支払い」が表示されている。

また、その下に表示される割り勘の内容の表示欄において、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅの３名については、割り勘種別として「電子マネー」が選択されたため、過不足金額の欄に「９００円 支払い」と表示されている。それに対し、ユーザＣ．Ｃについては、割り勘種別として「現金」が選択されたため、過不足金額の欄に「９００円 支払い」の表示とともに、過不足金額を現金で支払う（過不足金額を現金で渡す）ことを示す「紙幣のマーク」と関連付けて、現金で支払う金額（この例では「９００円」）が表示されている。

本実施例において、端末２０の制御部２１は、限定ではなく例として、選択した割り勘メンバーを識別するための情報と、各々の割り勘メンバーについて選択した割り勘種別を識別するための情報とを含むメンバー選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、サーバ１０は、メンバー選択情報に含まれる割り勘メンバーの情報と、それに関連付けられた割り勘種別の情報とに基づいて、過不足金額を計算する。

なお、本実施例では、割り勘メンバーのうちの少なくとも一人のユーザについて、割り勘種別を「現金」として設定することができればよいのであって、割り勘対象とする買い物決済履歴として選択される買い物決済履歴は、１つであってもよいし、複数（２以上）であってもよい。
また、前述したように、一の買い物決済履歴を選択して登録した後に、他の買い物決済履歴を選択して追加で登録するようにしてもよいし、そのようにしなくてもよい。

＜第１２実施例の効果＞
第１２実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴のうち、選択された一の買い物決済履歴（限定ではなく、第１決済情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、サーバ１０は、この一の買い物決済履歴に基づく、少なくとも、割り勘種別として現金が選択された端末２０の割り勘メンバー（限定ではなく、第２端末のユーザの一例）が自己の端末２０のユーザに現金で渡す金額（限定ではなく、第４金額）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信された金額（第４金額）と、割り勘種別として現金が選択された割り勘メンバーが自己の端末２０のユーザに渡す金額を紙幣のマークとともに示した情報（限定ではなく、第２端末のユーザが現金で渡す、または現金で貰う金額に関する情報の一例）を、表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、複数の決済情報のうち、第１決済情報を送信することによって、端末および第１端末（端末とは異なる端末）とは異なる第２端末のユーザが現金で渡す、または現金で貰う金額である第４金額の情報を受信することができる。そして、この第４金額と、第２端末のユーザが現金で渡す、または現金で貰う金額に関する情報とを端末の表示領域に表示することによって、ユーザに報知することができる。

また、第１２実施例は、端末２０が、自己の端末２０のユーザによる複数の買い物決済履歴のうち、選択された一の買い物決済履歴（限定ではなく、第１決済情報の一例）と、選択された他の買い物決済履歴（限定ではなく、第５決済情報の一例）とを通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、サーバ１０は、一の買い物決済履歴と他の買い物決済履歴とに基づく、少なくとも、割り勘種別として現金が選択された端末２０の割り勘メンバー（限定ではなく、第２端末のユーザの一例）が自己の端末２０のユーザに現金で渡す金額（限定ではなく、第４金額）の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信された金額（第４金額）と、割り勘種別として現金が選択された割り勘メンバーが自己の端末２０のユーザに渡す金額を紙幣のマークとともに示した情報（限定ではなく、第２端末のユーザが現金で渡す、または現金で貰う金額に関する情報の一例）を、表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、複数の決済情報のうち、第１決済情報と、第１決済情報とは異なる第５決済情報とを送信することによって、端末および第１端末とは異なる第２端末のユーザが現金で渡す、または現金で貰う金額である第４金額の情報を受信することができる。そして、この第４金額と、第２端末のユーザが現金で渡す、または現金で貰う金額に関する情報とを、端末の表示領域に表示することによって、ユーザに報知することができる。

また、第１２実施例は、端末２０が、自己の端末２０に対する自己の端末２０のユーザによる操作に基づいて、選択した買い物決済履歴と、選択した割り勘メンバーと、選択した割り勘種別とを含む買い物決済履歴選択情報（限定ではなく、第２端末のユーザが現金で渡す、または現金で貰うことを示す情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる入力に基づいて、第２端末のユーザが現金で渡す、または現金で貰うことを外部に通知することができる。

＜第１２変形例＞
第１２実施例において、割り勘種別が「現金」であるユーザについて、割り勘マスターがそのユーザから現金を受け取った場合に、現金の受取確認を行うようにすることもできる。

図１２−３は、本変形例におけるグループトークルーム画面の一例を示す図であり、割り勘マスターであるユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
このグループトークルーム画面では、ユーザＡ．Ａから発信されたメッセージとして、割り勘リクエストメッセージが、画面向かって右側に表示されている。この例では、ユーザＡ．Ａが割り勘をリクエストしたユーザであり、他の割り勘メンバーから金銭を受け取る側であるため、割り勘リクエストメッセージには、ユーザＡ．Ａの過不足金額として「３，６００円 受取」が表示されている。

また、その下には、図１２−２における割り勘リクエスト通知と同様に、自分を含む各割り勘メンバーの支払い済み金額および過不足金額が一覧表示されている。図１２−２と同様に、ユーザＢ．Ｂ、ユーザＤ．Ｄ、ユーザＥ．Ｅの３名については、割り勘種別として「電子マネー」が選択されたため、過不足金額の欄に「９００円 支払い」と表示されている。それに対し、ユーザＣ．Ｃについては、割り勘種別として「現金」が選択されたため、過不足金額の欄に「９００円 支払い」の表示とともに、過不足金額を現金で支払う（過不足金額を現金で渡す）ことを示す「紙幣マーク」と関連付けて、現金で支払う金額（この例では「９００円」）が表示されている。

また、割り勘種別が「現金」であるユーザ（この例ではユーザＣ．Ｃ）の欄には、ユーザＣ．Ｃからの現金の受け取り確認を行うための、限定ではなく例として「現金受取確認」と示された現金受取確認アイコンが設けられている。この現金受取確認アイコンが操作されると、そのユーザから現金を受け取ったことがサーバ１０に通知され、過不足金額がサーバ１０によって再計算される。

図１２−４は、図１２−３のグループトークルーム画面において現金受取確認アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
ユーザＡ．Ａによって、ユーザＣ．Ｃに関連付けられた現金受取確認アイコンが操作されたことに基づいて、ユーザＡ．ＡがユーザＣ．Ｃから現金を受け取ったことがサーバ１０に通知され、過不足金額がサーバ１０によって再計算される。その結果、ユーザＡ．Ａの過不足金額には、ユーザＣ．ＣからユーザＡ．Ａに現金で支払われた「９００円」が「３，６００円」から減算され、「２，７００円 受取」と表示されている。

また、ユーザＣ．Ｃに関連付けられた現金受取確認アイコンの表示について、その文字が「現金受取確認」から「確認済み」に変更され、その色が反転して表示（反転表示）されている。また、ユーザＣ．Ｃに関連付けられた紙幣マークとともに表示される現金の支払い金額（この例では「９００円」）の右側にチェックが付されて表示されている。

＜第１３実施例＞
第１３実施例は、端末２０で買い物決済履歴を修正し、修正した買い物決済履歴を割り勘対象として割り勘を行う実施例である。
買い物決済履歴のうちの一部の商品を割り勘対象から除外したい場合など、買い物決済履歴の修正をユーザが希望する場合がある。

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

本実施例において、端末２０の制御部２１は、自己の端末２０のユーザによって選択された買い物決済履歴を修正する処理を実行する。
修正対象とする買い物決済履歴は、
（１）自己の端末２０のユーザによる買い物決済履歴
（２）他の端末２０のユーザによる買い物決済履歴
のいずれかとすることができる。

以下では、修正対象とされた買い物決済履歴を「元買い物決済履歴」（修正対象買い物決済履歴と言ってもよい。）と称し、修正された買い物決済履歴を「修正買い物決済履歴」と称する。元買い物決済履歴は、第１決済情報の一例であり、修正買い物決済履歴は、第２決済情報の一例である。

なお、おおもとの買い物決済履歴に限らず、少なくとも１回修正された後の買い物決済履歴（修正買い物決済履歴）を元買い物決済履歴として、買い物決済履歴を修正する処理を実行するようにすることも可能である。

＜処理＞
（１）自己の端末２０のユーザによる買い物決済履歴の修正
図１３−１は、本実施例において端末Ａと端末Ｂとの間で行われる割り勘処理の流れの一例を示すフローチャートである。
この処理は、図１の処理に、端末Ａの処理として、Ａ１５のステップを追加し、Ａ２０のステップをＡ２２に置き換えるとともに、端末Ｂの処理として、Ｂ２０のステップをＢ２２に置き換えた処理である。

Ａ１０の後、端末Ａの制御部２１は、Ａ１０で選択した買い物決済履歴を修正する買い物決済履歴修正処理を行う（Ａ１５）。具体的には、制御部２１は、限定ではなく例として、入出力部２３に対する修正操作に従って、Ａ１０で選択した買い物決済履歴に含まれる決済内容を修正して、記憶部２８に更新記憶させる。

その後、端末Ａの制御部２１は、修正された買い物決済履歴（以下、「修正買い物決済履歴」と称する。）を、通信Ｉ／Ｆ２２によって端末Ｂに送信する（Ａ２２）。そして、端末Ａの制御部２１は、Ａ４０に処理を移す。

端末Ｂは、通信Ｉ／Ｆ２２によって端末Ａから修正買い物決済履歴を受信する（Ａ２２）。そして、端末Ｂの制御部２１は、Ｂ３０に処理を移す。

（２）他の端末２０のユーザによる買い物決済履歴の修正
図１３−２は、本変形例において端末Ａと端末Ｂとの間で行われる割り勘処理の流れの一例を示すフローチャートである。
この処理は、図１の処理に、端末Ａの処理として、Ａ１２、Ａ１５、Ａ２４のステップを追加し、端末Ｂの処理として、Ｂ１０、Ｂ１２、Ｂ２４のステップを追加した処理である。

端末Ｂの制御部２１は、第１の買い物決済履歴選択処理を実行する（Ｂ１０）。具体的には、端末Ｂの制御部２１は、限定ではなく例として、端末Ｂの記憶部２８に記憶された、ユーザＢ．Ｂによる複数の買い物決済履歴の中から、入出力部２３に対する選択操作に基づいて、少なくとも１つの買い物決済履歴を選択する。

その後。端末Ｂの制御部２１は、Ｂ１０で選択した買い物決済履歴を、通信Ｉ／Ｆ２２によって端末Ａに送信する（Ｂ１２）。通信Ｉ／Ｆ２２によって端末Ｂから買い物決済履歴を受信すると（Ａ１２）、端末Ａの制御部２１は、買い物決済履歴修正処理を実行する（Ａ１５）。この買い物決済履歴修正処理における修正の手法は、図１３−１の処理と同様であるが、修正の対象が、自身による買い物決済履歴ではなく、他の端末２０のユーザによる買い物決済履歴である点が異なる。

次いで、端末Ａの制御部２１は、Ａ１５での買い物決済履歴の修正の内容を含む買い物決済履歴修正情報を、通信Ｉ／Ｆ２２によって端末Ｂに送信する（Ａ２４）。そして、端末Ａの制御部２１は、Ａ４０に処理を移す。

Ｂ１２の後、端末Ｂは、通信Ｉ／Ｆ２２によって端末Ａから買い物決済履歴修正情報を受信する（Ｂ２４）。そして、端末Ｂの制御部２１は、Ｂ３０に処理を移す。

＜第１３実施例の効果＞
第１３実施例は、端末２０が、自己の端末２０のユーザによる修正操作（限定ではなく、端末のユーザによる端末に対する入力の一例）に基づいて、元買い物決済履歴（限定ではなく、第１決済に関する処理に基づく第１決済情報の一例）を修正買い物決済履歴（限定ではなく、第２決済情報の一例）に修正する買い物決済履歴修正処理を制御部２１によって実行する。端末２０は、修正買い物決済履歴に基づく、自己の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）と、他の端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）とのうち、少なくとも自己の端末２０のユーザの過不足金額の情報を通信Ｉ／Ｆ２２によって他の端末２０から受信する。そして、端末２０は、自己の端末２０のユーザの過不足金額に基づく送金処理、または受取処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、第１決済に関する処理に基づく第１決済情報を第２決済情報に修正した上で、この第２決済情報に基づいて、送金処理、または受取処理を実行することができる。また、第１決済情報を修正することができるため、ユーザの利便性を向上させることができる。

また、第１３実施例は、端末２０は、メモリに記憶されたプログラムを読み出し、読み出したプログラムに基づく処理を実行するプロセッサを備える。このプロセッサは、自己の端末２０のユーザによる修正操作（限定ではなく、端末のユーザによる端末に対する入力の一例）に基づいて、元買い物決済履歴（限定ではなく、第１決済に関する処理に基づく第１決済情報の一例）を修正買い物決済履歴（限定ではなく、第２決済情報の一例）に修正する買い物決済履歴修正処理を実行し、修正買い物決済履歴に基づく、自己の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）と、他の端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）とのうち、少なくとも自己の端末２０のユーザの過不足金額の情報を通信Ｉ／Ｆ２２によって他の端末２０から受信し、自己の端末２０のユーザの過不足金額に基づく送金処理、または受取処理を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。

また、第１３実施例は、元買い物決済履歴は、自己の端末２０のユーザによる買い物決済の履歴である構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる決済に関する処理に基づく第１決済情報を第２決済情報に修正することができる。

また、第１３実施例は、修正買い物決済履歴を、通信Ｉ／Ｆ２２によって異なる端末に送信する構成を示している。
このような構成により得られる効果の一例として、修正結果として得られた第２決済情報を外部に送信することができる。

また、第１３実施例は、元買い物決済履歴は、異なる端末２０のユーザによる買い物決済の履歴である構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる決済に関する処理に基づく第１決済情報を第２決済情報に修正することができる。

＜第１３変形例（１）＞
第１３実施例では、端末２０が、修正された買い物決済履歴（修正買い物決済履歴）を異なる端末２０に送信することとしたが、これに限定されない。

この場合、限定ではなく例として、一の端末２０と、異なる端末２０とで、各々の端末２０のユーザの買い物決済履歴のデータを共有しておく。そして、買い物決済履歴を修正した場合に、修正された買い物決済履歴そのものを異なる端末２０に送信するのではなく、修正した箇所や修正した内容の情報、つまり、元買い物決済履歴と修正買い物決済履歴との差分の情報を、異なる端末２０に送信するようにしてもよいし、そのようにしなくてもよい。

また、元買い物決済履歴が選択された場合に、この選択された買い物決済履歴を通信Ｉ／Ｆ２２によって異なる端末２０に送信する。そして、その後に、端末２０が、自己の端末２０のユーザによる修正操作に基づいて、送信した買い物決済履歴を修正する買い物決済履歴修正処理を実行するようにしてもよいし、そのようにしなくてもよい。この場合、買い物決済履歴修正処理を実行した後は、修正買い物決済履歴そのものを異なる端末２０に送信するようにしてもよいし、先に送信した元買い物決済履歴と修正買い物決済履歴との差分の情報を異なる端末２０に送信するようにしてもよい。

本変形例は、端末２０が、元買い物決済履歴と修正買い物決済履歴との差分の情報を、通信Ｉ／Ｆ２２によって異なる端末２０に送信する構成を示している。
このような構成により得られる効果の一例として、第２決済情報を送信する場合と比べて、端末の通信量を削減することができる。

また、本変形例は、端末２０が、元買い物決済履歴を通信Ｉ／Ｆ２２によって異なる端末２０に送信する。そして、元買い物決済履歴が送信された後、自己の端末２０のユーザによる修正操作に基づいて、送信した元買い物決済履歴が修正買い物決済履歴に修正される構成を示している。
このような構成により得られる効果の一例として、第１決済情報を送信した後に、第１決済情報を第２決済情報に修正することで、修正対象とする第１決済情報をあらかじめ外部に送信しておくことができる。

＜第１３変形例（２）＞
第１３実施例において、端末２０の制御部２１が買い物決済履歴修正処理を実行するのではなく、サーバ１０の制御部１１が買い物決済履歴修正処理を実行するようにすることもできる。つまり、買い物決済履歴を修正する処理（第１決済情報を第２決済情報に修正する処理）の実行主体は、端末２０の制御部２１であってもよいし、サーバ１０の制御部１１であってもよい。この詳細については、以降の実施例で説明する。

＜第１４実施例＞
第１４実施例は、端末２０がサーバ１０と通信を行って、買い物決済履歴を修正する実施例である。第１３実施例と同様に、買い物決済履歴の修正をユーザが希望する場合がある。

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

＜表示画面例＞
図１４−１は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面には、ユーザＡ．Ａによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されている。また、前述したように、各々の買い物決済履歴と関連付けてチェックボックスが設けられており、チェックボックスのチェックマークがＯＮとされた買い物決済履歴を割り勘対象とすることができるように構成されている。
これに加えて、本実施例では、各々の買い物決済履歴と関連付けて、その詳細を入力するための、限定ではなく例として「詳細」と示された詳細アイコンが設けられている。

図１４−２は、図１４−１の買い物決済履歴選択画面において詳細アイコンが操作されたことに基づいて表示される詳細入力画面の一例を示す図である。
この詳細入力画面では、「割り勘をする支払いの詳細を入力してください」の文字とともに、図１４−１の買い物決済履歴選択画面で選択された「ＢＢスーパー」での買い物決済履歴の買い物決済日時、店舗名、買い物決済金額等の情報が表示されている。

また、その下には、この買い物決済履歴の支払い明細として、購入された商品の名称およびその商品の単価が一覧表示される商品一覧表示領域と、商品の購入数が一覧表示される購入数一覧表示領域とが設けられている。購入数一覧表示領域には、デフォルトとして、この買い物決済履歴に対応する商品の購入数が入力されている。

商品一覧表示領域に含まれる一の商品に対応する表示領域を操作（限定ではなく例としてタッチ操作）すると、この商品に関連付けられた第２商品表示領域に表示されている購入数を０個にリセットすることができるように構成されている。

また、購入数一覧表示領域には、各々の商品と関連付けて、その購入数を増加修正するための上ボタンと、その購入数を減少修正するための下ボタンとが表示されており、これらのボタンを操作することで、その購入数を修正することが可能に構成されている。
この例では、商品一覧表示領域のうちの商品名「温泉まんじゅう」に対応する表示領域が操作されたことに基づいて、この表示領域に色が付されて表示されるとともに、その購入数が１個から０個にリセットされている。

図１４−３は、図１４−２の詳細入力画面において登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、図１４−２の詳細入力画面において商品名「温泉まんじゅう」の購入数が１個から０個に修正されたことで、「単価６００円×１個＝６００円」の金額が買い物決済金額から減額され、その結果、「ＢＢスーパー」の買い物決済履歴における買い物決済金額が「２，４００円」に修正されている。また、買い物決済金額と関連付けて、その買い物決済金額が修正されたことを示す修正マークが表示されている。

＜データ構成＞
図１４−４は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、支払いアプリケーション管理処理プログラム１５１と、支払いアプリケーションユーザ登録データ１５３と、ユーザ管理データベース１５５と、割り勘管理データベース１５７とに加えて、買い物細目管理データベース１５９が記憶されている。

図１４−５は、本実施例における割り勘管理データベース１５７の一例である第２の割り勘管理データベース１５７Ｂの一例を示す図である。
第２の割り勘管理データベース１５７Ｂに含まれる各割り勘管理データには、限定ではなく例として、割り勘管理ＩＤと、割り勘マスターＩＤと、割り勘メンバーＩＤと、買い物決済履歴管理データとが記憶される。

また、買い物決済履歴データには、限定ではなく例として、決済者ＩＤと、買い物決済ＩＤと、割り勘対象金額と、割り勘対象の細目（以下、「割り勘細目」と称する。）とが関連付けて記憶される。

割り勘細目には、その買い物決済ＩＤによって識別される買い物決済履歴について、割り勘細目として、購入された商品の名称や数等の基本的な情報が記憶される。

買い物細目管理データベース１５９は、買い物の細目（以下、「買い物細目」と称する。）を管理するためのデータベースであり、そのデータ構成の一例を図１４−６に示す。
買い物細目管理データベース１５９には、買い物決済ＩＤごとのデータとして、買い物細目管理データが記憶される。

各買い物細目管理データには、限定ではなく例として、買い物決済ＩＤと、買い物細目データとが記憶される。
買い物細目データには、買い物細目として、限定ではなく例として、商品名と、購入数と、単価と、購入金額（＝単価×購入数）とが関連付けて記憶される。

＜処理＞
図１４−７は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図２−１７の処理において、端末Ａの処理としてＡ１７０のステップを追加し、Ａ１８０のステップをＡ１８５に置き換えた処理である。また、サーバ１０の処理としてＳ１８０のステップをＳ１８５に置き換えた処理である。

Ａ１７０の後、端末Ａの制御部２１は、買い物決済履歴修正処理を実行する（Ａ１７５）。具体的には、入出力部２３に対する修正操作に従って、買い物決済履歴のうち、商品名、購入数の少なくともいずれかを修正する。

その後、端末Ａの制御部２１は、ユーザＡ．Ａの支払いアプリケーションＩＤと、修正した買い物決済履歴の買い物決済ＩＤと、その修正内容とを含む修正済み買い物決済履歴選択情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８５）。

Ｓ１６０の後、通信Ｉ／Ｆ１４によって端末Ａから修正済み買い物決済履歴選択情報を受信すると（Ｓ１８５）、サーバ１０の制御部１１は、受信された修正済み買い物決済履歴選択情報に含まれる支払いアプリケーションＩＤと、買い物決済ＩＤと、修正内容とに基づいて、第２の割り勘管理データベース１５７Ｂのうちの、対応する割り勘管理データを更新する。具体的には、商品名が修正された場合は、買い物決済履歴管理データのうちの対応する割り勘細目の欄を更新する。また、購入数が修正された場合は、買い物決済履歴管理データのうちの割り勘細目および割り勘対象金額の欄を更新する。

また、制御部１１は、同様にして、買い物細目管理データベース１５９のうちの、対応する買い物細目管理データを更新する。具体的には、商品名が修正された場合は、買い物細目データのうちの商品名の欄を更新する。また、購入数が修正された場合は、買い物細目データのうちの購入数の欄を更新する。
これらの処理は、サーバ１０の制御部１１によって実行される第１決済情報を第２決済情報に修正する処理の一例とも言える。
その後、制御部１１は、Ｓ１９０に処理を移す。

＜第１４実施例の効果＞
第１４実施例は、端末２０が、買い物決済履歴修正処理において、元買い物決済履歴のうちの購入された商品の情報を修正する構成を示している。
このような構成により得られる効果の一例として、第１決済情報のうち購入された商品の情報を修正することができる。

また、第１４実施例は、買い物決済履歴修正処理において購入された商品の情報が削除され、その結果、買い物決済金額が減額される構成を示している。
このような構成により得られる効果の一例として、第１決済情報のうち購入された商品の情報が削除され、決済金額が減額されるため、限定ではなく例として、割り勘対象とする商品を除外して、決済金額を所望の金額に修正することができる。

また、第１４実施例は、サーバ１０が、端末２０のユーザによる修正操作（限定ではなく、端末のユーザによる端末に対する入力の一例）に基づいて、元買い物決済履歴（限定ではなく、第１決済に関する処理に基づく第１決済情報の一例）を修正買い物決済履歴（限定ではなく、第２決済情報の一例）に修正する買い物決済履歴修正処理を制御部１１によって実行する。サーバ１０は、少なくとも一の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）の情報を一の端末２０に通信Ｉ／Ｆ１４によって送信し、少なくとも他の端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）の情報を他の端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、割り勘精算処理（限定ではなく、第１金額に基づく、端末に対する送金処理、または受取処理と、第２金額に基づく、異なる端末に対する送金処理、または受取処理との一例）を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、サーバは、第１決済に関する処理に基づく第１決済情報を第２決済情報に修正した上で、この第２決済情報に基づいて、端末に対する送金処理、または受取処理と、異なる端末に対する送金処理、または受取処理とを実現することができる。また、これらの処理を端末側で行わずに済むため、端末の処理負荷を軽減することができる。

＜第１４変形例（１）＞
買い物決済を行ったことに基づいて、商品等を購入した店舗から特典として付与されるポイント（限定ではなく、還元情報の一例）に基づいて、買い物決済履歴を修正するようにしてもよいし、そのようにしなくてもよい。

図１４−８は、本変形例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、「ＢＢスーパー」の買い物決済履歴と関連付けて、「ＢＢスーパー」から特典として付与されたポイントがあることを示すポイントアイコンが表示されている。ポイントアイコンが操作されることで、付与されたポイントを確認することが可能となる。

図１４−９は、図１４−８の買い物決済履歴選択画面においてポイントアイコンが操作されたことに基づいて表示されるポイント確認画面の一例を示す図である。
このポイント確認画面では、「利用可能なポイントがあります」の文字が表示され、その下に、「ＢＢスーパー」の買い物決済履歴の情報が表示されている。また、その下には、ポイント発生額を買い物決済金額から差し引くか否かを選択するための「ＯＮ／ＯＦＦ」を切替可能なポイント利用設定ボタンが表示されている。

また、その下には、付与されたポイントが表示されており、この例では、「１０％還元 ３００ｐｔ（３００円相当）発生」の文字を含むポイント情報が表示されている。この例では、ポイント利用設定ボタンが「ＯＮ」に設定されたことで、ポイント情報の下に、買い物決済金額からポイント発生額を差し引いた金額（この例では３，０００円−３００円＝２，７００円）が修正された金額として表示されている。

なお、還元情報には、ポイントに限らず、いわゆる電子クーポン（モバイルクーポン）等を含めることもできる。

本変形例は、買い物決済履歴は、買い物決済を行った店舗から付与されるポイント等（限定ではなく、還元情報の一例）に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザが第１決済を行った店舗の還元情報に基づいて、第１決済情報を第２決済情報に修正することができる。

また、本変形例は、端末２０は、ポイント利用設定ボタン（限定ではなく、還元情報に基づく修正を行うための第１表示の一例）を表示部２４に表示し、買い物決済履歴は、ポイント利用設定ボタンに対するユーザの切替操作（限定ではなく、第１表示に対する端末のユーザの入力の一例）に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、還元情報に基づく修正を行うための、端末のユーザが入力可能な第１表示が端末の表示領域に表示されるため、ユーザの利便性を向上させることができる。

＜第１４変形例（２）＞
第１４実施例において、前述したメモやタグを、買い物決済履歴に関連付けて設定するようにしてもよいし、そのようにしなくてもよい。

図１４−１０は、本変形例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面は、図１４−２の買い物決済履歴選択画面とほぼ同様であるが、画面下部にメモが関連付けて設定されている点が異なる。具体的には、自己の端末２０のユーザ（ユーザＡ．Ａ）によって入力されたメモとして、「自分のお土産に買った温泉まんじゅう代（６００円）を引いてあります」という内容のメモが入力されて表示されている。このようにすることで、他の割り勘メンバーは、温泉まんじゅうの購入数が“０”に修正されたこと、および、その結果として割り勘対象とする金額が減額されたことを簡単に知ることができる。

＜第１５実施例＞
第１５実施例は、端末２０がサーバ１０と通信を行って、買い物決済履歴を修正する実施例である。第１５実施例は、第１４実施例とは異なり、端末２０のユーザによる修正操作に基づいて、買い物決済金額を修正する。
また、第１５実施例では、買い物決済履歴ごとに、割り勘メンバーを変更することを可能とする。

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

＜表示画面例＞
図１５−１は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この買い物決済履歴選択画面には、ユーザＡ．Ａによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されている。また、前述したように、各々の買い物決済履歴と関連付けてチェックボックスが設けられており、チェックボックスのチェックマークがＯＮとされた買い物決済履歴を割り勘対象とすることができるように構成されている。
これに加えて、本実施例では、各々の買い物決済履歴と関連付けて、その詳細を入力するための、限定ではなく例として「詳細」と示された詳細アイコンが設けられている。

図１５−２は、図１５−１の買い物決済履歴選択画面において詳細アイコンが操作（限定ではなくタッチ操作）されたことに基づいて表示される詳細入力画面の一例を示す図であり、図１５−１の買い物決済履歴選択画面における「ＢＢスーパー」の買い物決済履歴に関連付けられた詳細アイコンが操作された場合の画面の一例を示している。
この詳細入力画面では、「割り勘をする支払いの詳細を入力してください」の文字とともに、図１５−１の買い物決済履歴選択画面で選択された「ＢＢスーパー」での買い物決済履歴における買い物決済金額が表示されている。

また、その下には、この買い物決済金額を上限金額として、割り勘対象とする金額を修正するための金額修正欄が設けられている。金額修正欄には、割り勘対象とする金額を増額修正するための上ボタンと、割り勘対象とする金額を減額修正するための下ボタンとが関連付けて設けられており、この上ボタン／下ボタンが操作されることで、金額を増額／減額させるように修正することが可能に構成されている。この金額の修正は、買い物決済履歴の買い物決済金額の修正と言うこともできる。

金額修正欄の下には、割り勘メンバーの一覧が表示される割り勘メンバー一覧表示領域が設けられており、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーが割り勘メンバー候補として設定されていか否かを示すチェックが表示されている。限定ではなく例として、割り勘メンバーのアイコン画像を操作することで、チェックのＯＮ／ＯＦＦを切り替えることができ、チェックがＯＦＦとされたユーザは、割り勘メンバー候補から除外される。この例では、ユーザＣ．ＣのチェックがＯＦＦとされており、ユーザＣ．Ｃが割り勘メンバー候補から除外された状態が示されている。

また、割り勘メンバー一覧表示領域の下には、選択されている買い物決済履歴にタグを設定するためのタグ表示領域が設けられており、複数種類のタグの候補が表示されている。タグの候補には、限定ではなく例として、「買い物」、「仕事」、「デート」、「旅行」、「贈り物」、「その他」等の複数の候補が含まれる。この複数種類のタグの候補のうちのいずれかのタグに対する操作を行うことで、そのタグを、この買い物決済履歴に関連付けて設定することができる。この例では、「旅行」のタグが操作されたことによって、「旅行」のタグが「ＢＢスーパー」での買い物決済履歴に関連付けて設定された状態が示されている。

また、タグ表示領域の下には、端末２０のユーザがメモを記載するためのメモ欄が設けられている。この例では、「Ｃ．Ｃさんはスーパーで買い物をしなかった 個人的に購入した飲み物代（４００円）を引いておきます」というメモが記載されている。このメモの内容から、上記のように、ユーザＣ．Ｃが割り勘メンバーから除外された理由、および、金額が「３，０００円」から「２，６００円」に修正された理由が分かる。

また、画面下部には、この買い物決済履歴の修正内容を登録するための、限定ではなく例として「登録」と示された登録アイコンが表示されている。

図１５−３は、詳細入力画面の別例を示す図である。
この詳細入力画面の構成は、図１５−２の詳細入力画面とほぼ同様であるが、「割り勘をする支払いの詳細を入力してください」の文字とともに、買い物決済が行われたイベントの名称（イベント名）が表示されている。この例では、イベント名として「ＧＧ公園の入場料」が表示されている。

図１５−４は、図１５−２、図１５−３の詳細入力画面での入力の結果として表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、図１５−１の買い物決済履歴選択画面と同様に、ユーザＡ．Ａによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されているが、その表示が一部異なっている。

具体的には、限定ではなく例として、図１５−２の「ＢＢスーパー」での買い物決済履歴に関する修正に伴い、「ＢＢスーパー」の買い物決済履歴の表示欄に、修正された割り勘メンバーのアイコン画像（上記の例ではユーザＣ．Ｃが除外されたため他の４人のユーザのアイコン画像）と、設定されたタグ（上記の例では「旅行」のタグ）の画像とが表示されている。また、割り勘対象とする金額として、金額が修正されたことを示す「修正」のマークとともに、修正後の金額である「２，６００円」が表示されている。

また、その横には、この買い物決済履歴と関連付けて設定されたメモを確認するためのメモアイコンが表示されている。このメモアイコンが操作されると、この買い物決済履歴と関連付けて設定されたメモが、限定ではなく例として、ポップアップ形式や、別のページに表示される。

また、限定ではなく例として、図１５−３のイベント名「ＧＧ公園の入場料」での買い物決済履歴に関する修正に伴い、「ＧＧ公園の入場料」の買い物決済履歴の表示欄に、設定されたタグ（上記の例では「旅行」のタグ）の画像が表示されている。

図１５−５は、コード画像に基づく決済を行うためのコード画面の一例を示す図である。
このコード画面は、買い物決済に利用されるコード支払い用のコード画像であって端末２０の表示部２４に表示されるコード画像（以下、「支払いコード画像」と称する。）を含む画面の一例であり、決済方法（電子マネー口座残高を含む。）と、この端末２０のユーザが所有しているポイント（決済時におけるポイントの優先使用の有無（ＯＮ／ＯＦＦ））とともに、限定ではなく例としてバーコードで表される一次元の支払いコード画像と、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコード画像とが表示されている。

また、このコード画面の下部には、前述したタグ表示領域が設けられている。このタグ表示領域には、前述したように、複数種類のタグの候補が表示されている。そして、支払いコード画像を店舗のコードリーダ、または店舗のコードリーダ装置（以下、包括的に「店舗コードリーダ装置」と称する。）に読み取らせて買い物決済を行う際、あらかじめ指定しておいたタグを、その買い物決済の買い物決済履歴に関連付けて設定することが可能となる。この例では、「旅行」のタグが指定された状態が示されており、この状態で支払いコード画像を用いて買い物決済を行うと、その買い物決済の買い物決済履歴に「旅行」のタグが関連付けられることになる。

より具体的には、端末２０から送信されるコード生成依頼情報に基づいて、サーバ１０はコード生成処理を実行する。具体的には、限定ではなく例として、ランダムなトークン情報（ランダムな番号を含む。）を発生させ、発生させたトークン情報を、この端末２０のユーザの支払いアプリケーションＩＤに関連付けて記憶させる。そして、発生させたトークン情報をエンコードした支払いコード画像を生成して端末２０に送信する。端末２０は、サーバ１０から受信したコード画像と、複数種類のタグの候補とを含むコード画面を表示部２４に表示させる。

ユーザ操作に従って複数種類のタグの候補の中から少なくとも１つのタグを選択すると、端末２０は、そのタグの選択情報をサーバ１０に送信する。
一方、店舗コードリーダ装置によって支払いコード画像が読み取られると、この支払いコード画像に格納されているトークン情報が店舗コードリーダ装置によってデコードによって取得され、決済予定金額とともに店舗コードリーダ装置からサーバ１０に送信される。

サーバ１０は、店舗コードリーダ装置から受信したトークン情報が、いずれの支払いアプリケーションＩＤに関連付けられているかを判定する。そして、判定した支払いアプリケーションＩＤの電子マネー口座から決済予定金額を決済する。そして、端末２０から別途受信したタグの選択情報に基づき、その買い物決済履歴にタグを関連付けて設定する。

なお、同様の手法によって、タグに代えて、またはこれに加えて、買い物決済履歴にメモを関連付けるようにしてもよいし、そのようにしなくてもよい。

＜データ構成＞
図１５−６は、本実施例においてサーバ１０の記憶部１５に記憶される割り勘管理データベース１５７の一例である第３の割り勘管理データベース１５７Ｃのデータ構成例を示す図である。
第３の割り勘管理データベース１５７Ｃの各割り勘管理データには、限定ではなく例として、割り勘管理ＩＤと、割り勘マスターＩＤと、割り勘メンバーＩＤと、買い物決済履歴管理データとが記憶される。

買い物決済履歴管理データには、限定ではなく例として、決済者ＩＤと、買い物決済ＩＤと、割り勘対象金額と、割り勘対象メンバーと、メモと、タグとが関連付けて記憶される。

決済者ＩＤ〜割り勘対象金額は、第１の割り勘管理データベース１５７Ａと同様である。

割り勘対象メンバーには、割り勘メンバーＩＤにＩＤが記憶された割り勘メンバーのうち、その買い物決済ＩＤによって識別される買い物決済履歴（その割り勘対象金額）を割り勘するメンバーとして、その決済者ＩＤのユーザによって選択・登録された割り勘メンバー（以下、「割り勘対象メンバー」と称する。）の支払いアプリケーションＩＤが記憶される。

割り勘メンバーは、割り勘管理ＩＤによって識別される１つの単位としての割り勘を行うメンバーとして設定される固定的なメンバーであるのに対し、割り勘対象メンバーは、割り勘を行う対象として選択・登録された買い物決済履歴ごとに設定されるメンバーである点が異なる。

メモには、その買い物決済ＩＤによって識別される買い物決済履歴に関連付けるメモとして、限定ではなく例として、その決済者ＩＤのユーザの端末２０で入力されたメモが記憶される。

タグには、その買い物決済ＩＤによって識別される買い物決済履歴に関連付けるタグとして、限定ではなく例として、その決済者ＩＤのユーザの端末２０で入力されたタグが記憶される。

＜処理＞
本実施例において、端末２０の制御部２１は、図１４−７の処理における買い物決済履歴修正処理において（Ａ１７５）、自己の端末２０のユーザによる買い物決済金額の修正操作に従って、買い物決済金額、割り勘メンバー候補、メモ、タグのうちの少なくともいずれか１つを修正する。そして、制御部２１は、自己のユーザの支払いアプリケーションＩＤと、修正した買い物決済履歴の買い物決済ＩＤと、修正内容とを含む修正済み買い物決済履歴選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１８５）。

通信Ｉ／Ｆ１４によって端末２０から修正済み買い物決済履歴選択情報を受信すると（Ｓ１８５）、サーバ１０の制御部１１は、受信された修正済み買い物決済履歴選択情報に含まれる支払いアプリケーションＩＤと、買い物決済ＩＤと、修正内容とに基づいて、第３の割り勘管理データベース１５７Ｃのうちの対応する割り勘管理データを更新する。具体的には、買い物決済金額が修正された場合は、買い物決済履歴管理データのうちの対応する割り勘対象金額の欄を更新する。割り勘メンバー候補が修正された場合は、買い物決済管理データのうちの対応する割り勘対象メンバーの欄を更新する。メモが追加・修正された場合は、買い物決済履歴管理データのうちの対応するメモの欄を更新する。また、タグが追加・修正された場合は、買い物決済履歴管理データのうちの対応するタグの欄を更新する。

＜第１５実施例の効果＞
第１５実施例は、端末２０は、買い物決済履歴修正処理において、自己の端末２０のユーザの修正操作に基づいて、買い物決済金額を修正する構成を示している。
このような構成により得られる効果の一例として、端末のユーザの入力に従って、第１決済情報の決済金額を所望の金額に修正することができる。

また、第１５実施例は、端末２０が、自己の端末２０のユーザによる選択操作に基づいて、元買い物決済履歴（限定ではなく、第１決済情報の一例）および修正買い物決済履歴（限定ではなく、第２決済情報の一例）とは異なる買い物決済履歴（限定ではなく、第３決済情報の一例）を入力する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１決済情報および第２決済情報とは異なる第３決済情報を入力する処理を制御部によって実行することで、限定ではなく例として、割り勘対象とする決済情報を追加することができる。

また、第１５実施例は、買い物決済履歴は、複数の決済情報の各々に関連付けられたタグ等（限定ではなく、端末のユーザによって入力された情報の一例）に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、複数の決済情報の各々に関連付けられた、端末のユーザによって入力された情報に基づいて、第１決済情報を適切に選択することができる。

また、第１５実施例は、端末２０が、複数の買い物決済履歴のうち、一の買い物決済履歴（限定ではなく、第１決済情報の一例）と、他の買い物決済履歴（限定ではなく、第４決済情報の一例）とを通信Ｉ／Ｆ２２によってサーバ１０に送信する。端末２０は、自己の端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）と、第１の端末２０の割り勘メンバーの過不足金額（限定ではなく、第２金額の一例）と、第２の端末２０の割り勘メンバーの過不足金額（限定ではなく、第３金額の一例）とを通信Ｉ／Ｆ２２によってサーバ１０から受信する。この場合、自己の端末２０のユーザの過不足金額は、一の買い物決済履歴と他の買い物決済履歴とに基づいて決定されるが、第１の端末２０の割り勘メンバーの過不足金額は、一の買い物決済履歴に基づいて決定され、第２の端末２０の割り勘メンバーの過不足金額は、他の買い物決済履歴に基づいて決定される構成を示している。
このような構成により得られる効果の一例として、端末は、異なる決済情報に基づいて決定された、端末のユーザが送金、または受け取る第１金額と、第１端末のユーザが送金、または受け取る第２金額と、端末および第１端末とは異なる第２端末のユーザが送金、または受け取る第３金額とを、受信することができる。

＜第１６実施例＞
第１６実施例は、元買い物決済履歴と、修正買い物決済履歴とを、表示態様を変えて（表示態様を異ならせて）表示する実施例である。第１３実施例〜第１５実施例に示したように買い物決済履歴を修正した場合、その修正箇所が分かりづらい場合がある。

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

＜表示画面例＞
図１６−１は、本実施例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、「ＢＢスーパー」の買い物決済履歴と関連付けて、この買い物決済履歴が修正されたことを示す修正マークに加えて、買い物決済金額が減額修正されたことを示す下三角形のマークが表示されている。

図１６−２は、本実施例における割り勘リクエスト通知画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘リクエスト通知画面において、ユーザＢ．Ｂの過不足金額を示す過不足金額表示領域がユーザＢ．Ｂによって操作されると、その割り勘の内訳が表示される。この割り勘の内訳における「ＢＢスーパー」の買い物決済履歴には、図１６−１と同様に、買い物決済金額が減額修正されたことを示す下三角形のマークが表示されている。

図１６−３は、本実施例における買い物決済履歴選択画面の別例を示す図であり、図１６−１と同様の画面であるが、その内容が一部異なっている。
この買い物決済履歴選択画面では、「ＢＢスーパー」の買い物決済履歴と関連付けて、この買い物決済履歴が修正されたことを示す修正マークに加えて、買い物決済金額が増額修正されたことを示す上三角形のマークが表示されている。

図１６−４は、本実施例における割り勘リクエスト通知画面の別例を示す図であり、図１６−２と同様の画面であるが、その内容が一部異なっている。
この割り勘リクエスト通知画面では、割り勘の内訳における「ＢＢスーパー」の買い物決済履歴には、図１６−３と同様に、買い物決済金額が増額修正されたことを示す上三角形のマークが表示されている。

＜第１６実施例の効果＞
第１６実施例は、端末２０が、修正買い物決済履歴（限定ではなく、修正された第２決済情報の一例）と、元買い物決済履歴（限定ではなく、修正されていない決済情報の一例）とで表示態様を異ならせて表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、決済情報が修正されたことや、決済情報のうちの修正された情報を、端末のユーザが容易に把握可能とすることができる。

また、第１６実施例は、端末２０が、買い物決済履歴の買い物決済金額が減額修正された場合、第１表示態様で表示部２４に表示し、買い物決済履歴の買い物決済金額が増額修正された場合、第２態様で表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、第２決済情報の決済金額が増額と減額のいずれに修正されたかを、端末のユーザが容易に把握可能とすることができる。

＜第１６変形例＞
第１６実施例において、端末２０が、修正買い物決済履歴に対する自己の端末２０のユーザによる入力に基づいて、修正買い物決済履歴の修正内容を表示するようにすることもできる。

図１６−５は、本変形例における詳細入力画面の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
この詳細入力画面では、「ＢＢスーパー」の買い物決済履歴の詳細が表示されており、画面中央部の支払い明細の欄において、商品名およびその商品名の商品の単価と関連付けて、変更前の購入数と、変更後の購入数とが表示されている。

図１６−６は、本変形例における割り勘リクエスト通知画面を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘リクエスト通知画面において、過不足金額表示領域の下には、割り勘マスターであるユーザＡ．Ａのアイコン画像およびユーザ名と関連付けて、ユーザＡ．Ａによって入力されたメモが表示されている。また、その下には、割り勘の内訳が表示されている。割り勘の内訳には、登録されている各々の買い物決済履歴が含まれている。この例では、「ＡＡレンタサイクル」、「ＢＢスーパー」等の複数の買い物決済履歴が含まれ、「ＢＢスーパー」の買い物決済履歴には、買い物決済金額が減額修正されたことを示す減額マークが関連付けて表示されている。

限定ではなく例として、この「ＢＢスーパー」の買い物決済履歴の表示領域が操作されると、その修正内容がポップアップ形式で表示される。この例では、買い物決済金額が修正されたことを示す「金額修正」の文字と、買い物決済金額が「３，０００円」から「２，６００円」に減額修正されたことを示す情報と、修正を行ったユーザのアイコン画像（この例ではユーザＡ．Ａのアイコン画像）とを含む内容がポップアップ形式で表示されている。

本変形例は、端末２０は、自己の端末２０の表示部２４に表示された修正買い物決済履歴に対する端末２０のユーザの操作（限定ではなく、端末のユーザによる入力の一例）に基づいて、修正買い物決済履歴の修正内容を表示する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが自己の端末に対する入力を行うことで、第２決済情報の修正内容を確認できるようにすることができる。

＜第１７実施例＞
第１７実施例は、端末２０で修正された修正買い物決済履歴に対して、異なる端末２０のユーザが修正提案を行うことを可能とする実施例である。修正された買い物決済履歴に対して、割り勘メンバーが異議を申し立てることを希望する場合がある。

以下の実施例では、端末２０のユーザが、割り勘対象として登録した自分の買い物決済履歴を修正することを「修正」と称し、端末２０のユーザが、割り勘対象として登録された異なる端末２０のユーザの買い物決済履歴を修正するように提案することを「修正提案」と称する。

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

＜表示画面例＞
図１７−１は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
この割り勘内容確認画面には、限定ではなく例として、支払い済み金額一覧表示領域について、自分（この例ではユーザＢ．Ｂ）のアイコン画像およびユーザ名と関連付けて自身が登録した買い物決済履歴を修正するための「修正」と示された修正マークが表示されている。また、自分以外の割り勘メンバーのアイコン画像およびユーザ名と関連付けて、その割り勘メンバーが登録した買い物決済履歴の修正を提案するための「修正提案」と示された修正提案マークが表示されている。

図１７−２は、図１７−１の割り勘内容確認画面においてユーザＡ．Ａに関連付けられた修正提案マークがユーザＢ．Ｂによって操作されたことに基づいて表示される買い物決済履歴修正提案画面の一例を示す図である。
この買い物決済履歴修正提案画面には、「修正提案したい支払い履歴を選んでください」の文字とともに、ユーザＡ．Ａが登録した買い物決済履歴が一覧表示されている。この例では、ユーザＡ．Ａが登録した買い物決済履歴として「ＡＡレンタサイクル」の買い物決済履歴と「ＢＢスーパー」の買い物決済履歴とが表示され、各々の買い物決済履歴と関連付けて、その買い物決済履歴の修正提案を行うためのチェックボックスが設けられている。この例では、「ＢＢスーパー」の買い物決済履歴に関連付けられたチェックボックスのチェックがＯＮとされた状態が示されている。

また、画面下部には、チェックボックスのチェックがＯＮとされた買い物決済履歴について、その買い物決済金額の修正を提案するための、限定ではなく例として「金額修正提案」と示された金額修正提案アイコンと、その買い物決済履歴の取り下げを提案するための、限定ではなく例として「取り下げ提案」と示された取り下げ提案アイコンとが表示されている。

図１７−３は、図１７−２の買い物決済履歴修正提案画面において金額修正提案アイコンが操作されたことに基づいて表示される修正提案内容入力画面の一例を示す図である。
この修正提案内容入力画面には、「修正提案の内容を入力してください」の文字とともに、チェックボックスのチェックがＯＮとされた「ＢＢスーパー」の買い物決済履歴と、修正を提案する金額（以下、「修正提案金額」と称する。）を入力するための修正提案金額入力欄とが設けられている。修正提案金額入力欄には、上ボタンとした下ボタンとが関連付けて設けられており、上ボタンが操作されることで修正提案金額が増額され、下ボタンが操作されることで修正提案金額が減額されるように構成されている。

この例では、「ＢＢスーパー」の買い物決済金額（修正買い物決済履歴）として、ユーザＡ．Ａによって修正されたことを示す修正マークと、減額修正されたことを示す下三角形のマークと、修正された買い物決済金額である「２，４００円」とが表示されている。また、ユーザＢ．Ｂによって入力された修正提案金額として「３，０００円」が表示されている。

また、修正提案金額入力欄の下には、修正買い物決済履歴に対する修正提案コメントを入力するための修正提案コメント入力欄が設けられており、ユーザＢ．Ｂが修正提案コメントを入力することが可能に構成されている。この例では、「スーパーでの買い物代は３，０００円だったと思います」という修正提案コメントが入力されている。つまり、ユーザＢ．Ｂによって、ユーザＡ．Ａによって修正された買い物決済金額の「２，４００円」は誤りで、本当は「３，０００円」ではないかと異議を申し立てる修正提案コメントが入力された状態が示されている。

また、画面下部には、入力した内容で修正提案を行うための、限定ではなく例として「修正を提案」と示された修正提案実行アイコンが設けられている。

図１７−４は、図１７−３の修正提案内容入力画面において修正提案実行アイコンが操作されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示す図である。
この修正提案画面には、「Ｂ．Ｂさんから割り勘の修正提案がありました」の文字とともに、ユーザＡ．Ａが登録した「Ｂ．Ｂスーパー」の修正買い物決済履歴の詳細とともに、ユーザＢ．Ｂによって修正提案された内容の詳細が表示されている。具体的には、ユーザＢ．Ｂのアイコン画像と関連付けて、修正提案があったことを示す「修正提案」の文字と、修正提案金額（この例では「３，０００円」）とが表示されている。また、その下には、ユーザＢ．Ｂのアイコン画像およびユーザ名と関連付けて、ユーザＢ．Ｂによって入力された修正提案コメント（この例では「スーパーでの買い物代は３，０００円だったと思います」）が表示されている。

また、画面下部には、上記の修正提案内容に対する回答のコメントを入力するための回答コメント入力欄が設けられており、この例では、ユーザＡ．Ａによって「お土産の温泉まんじゅう代を引きました。」という回答コメントが入力された状態が示されている。この回答コメント入力欄の横には、入力された回答コメントをユーザＢ．Ｂの端末２０に送信するための送信ボタンが設けられている。

図１７−５は、図１７−４の修正提案画面において送信ボタンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される修正提案画面の一例を示す図である。
この修正提案画面には、自分が発信した修正提案コメントと、ユーザＡ．Ａから発信された回答コメントとが表示されている。

また、図１７−４の修正提案画面と同様に、画面下部には、回答コメント入力欄が設けられており、この例では、ユーザＢ．Ｂによって「みんなでシェアしたので、温泉まんじゅう代も割り勘にしましょう！」という回答コメントが入力された状態が示されている。この回答コメント入力欄の横には、入力された回答コメントをユーザＡ．Ａの端末２０に送信するための送信ボタンが設けられている。

図１７−６は、図１７−５の修正提案画面において送信ボタンが操作されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示される修正提案画面の一例を示す図である。
この修正提案画面には、ユーザＢ．Ｂから発信された回答コメントが表示されている。また、回答コメント入力欄には、ユーザＡ．Ａによって「では、そうさせてもらいますね。」という回答コメントが入力された状態が示されている。

図１７−７は、図１７−６の修正提案画面において送信ボタンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される修正提案画面の一例を示す図である。
この修正提案画面には、「Ｂ.Ｂスーパー」の買い物決済履歴と関連付けて、ユーザＢ．Ｂによって修正提案された内容の詳細の下に、ユーザＡ．Ａによって修正提案が承諾されたことを示す「提案承諾」の文字と、買い物決済金額が増額修正されたことを示す上三角形のマークと、修正結果の金額（この例では「３，０００円」）とが表示されている。
また、自分（ユーザＢ．Ｂ）が発信した回答コメントの下に、ユーザＡ．Ａから発信された回答コメント（この例では「では、そうさせてもらいますね。」）が表示されている。

また、画面下部には、割り勘精算処理の結果として精算された金額（精算金額）を確認するための、限定ではなく例として「精算金額を確認する」と示された精算金額確認アイコンが表示されている。

図１７−８は、図１７−７の修正提案画面において精算金額確認アイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、過不足金額表示領域に、ユーザＢ．Ｂの過不足金額（この例では「３，５００円 受取」）が表示されている。

図１７−９は、図１７−８の割り勘リクエスト通知画面において過不足金額表示領域が操作されたことに基づいて表示される画面の一例を示す図である。
図１７−８の割り勘リクエスト通知画面において過不足金額表示領域が操作されると、ユーザＢ．Ｂが修正提案を行ったことに基づいて、ユーザＢ．Ｂの過不足金額が、当初の過不足金額に対して増加／減少のいずれに変化したかを示す情報が表示される。この例では、過不足金額表示領域において、過不足金額「３，５００円 受取」の横に、ユーザＢ．Ｂが受け取る金額が減少したことを示す下三角形のマークが表示されている。

図１７−１０は、ユーザＢ．Ｂの端末２０の表示部２４に表示される買い物決済履歴選択画面の一例を示している。
この例では、ユーザＢ．Ｂが登録した買い物決済履歴として、「ＥＥレストラン」の買い物決済履歴が表示されており、チェックボックスのチェックがＯＮとされた状態が示されている。画面下部には、この買い物決済履歴の金額を修正するための金額修正アイコンと、この買い物決済履歴を割り勘対象から取り下げるための（この買い物決済履歴の登録を解除するための）取り下げアイコンとが表示されている。

図１７−１１は、図１７−１０の買い物決済履歴選択画面において取り下げアイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される修正提案画面の一例を示す図である。
この修正提案画面では、ユーザＢ．Ｂが取り下げを希望する「ＥＥレストラン」の買い物決済履歴とともに、ユーザＢ．Ｂによって入力されたコメントが表示されている。この例では、「旅行の日程を私に合わせてもらったので、レストランでの食事はおごります！」というコメントが表示されている。

＜処理＞
図１７−１２は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
図１７−１２の処理は、図２−１６〜図２−１８の処理のうちの図２−１８の処理部分において、端末Ａの処理としてＡ５４０のステップを追加し、端末Ｂの処理としてＡ５４０のステップを追加し、サーバ１０の処理としてＳ５４０〜Ｓ５８０のステップを追加した処理である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。

Ａ２１０の後、端末Ａの制御部２１は、割り勘修正処理を実行する（Ａ５４０）。同様に、Ｂ２１０の後、端末Ｂの制御部２１は、割り勘修正処理を実行する（Ａ５４０）。

図１７−１３は、割り勘修正処理の流れの一例を示すフローチャートである。
この処理は、図４−９の割り勘追加登録処理のＡ５３２０〜Ａ５３４０のステップをＡ５４２０〜Ａ５４４０にそれぞれ置き換えるとともに、Ａ５３７０、Ａ５３８０のステップをＡ５４７０、Ａ５４８０のステップにそれぞれ置き換えた処理である。

Ａ５３１０において割り勘に同意しないと判定した場合（Ａ５３１０：ＮＯ）、制御部２１は、割り勘内容を修正するための操作が入出力部２３に対して入力されたか否かに基づいて、割り勘内容を修正するか否かを判定する（Ａ５４２０）。割り勘内容を修正しないと判定したならば（Ａ５４２０：ＮＯ）、制御部２１は、Ａ５３５０に処理を移す。

一方、割り勘内容を修正すると判定したならば（Ａ５４２０：ＹＥＳ）、制御部２１は、割り勘精算修正処理を実行する（Ａ５４３０）。具体的には、入出力部２３に対する修正操作に従って買い物決済履歴を修正する。この「修正」には、限定ではなく例として、買い物決済履歴の修正（または修正提案）をサーバ１０に依頼するために、端末２０側で修正対象・修正内容（または修正提案対象・修正提案内容）を決定することが含まれる。

その後、制御部２１は、限定ではなく例として、修正対象（または修正提案対象）の買い物決済履歴の買い物決済ＩＤと、修正内容（または修正提案内容）とを含む割り勘精算修正依頼通知を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５４４０）。

次いで、制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘修正確認通知を受信したか否かを判定し（Ａ５４７０）、受信したと判定したならば（Ａ５４７０：ＹＥＳ）、受信された割り勘精算確認通知を表示部２４に表示した後（Ａ５４８０）、Ａ５３１０に処理を戻す。

一方、割り勘修正確認通知を受信しなかったと判定したならば（Ａ５４７０：ＮＯ）、制御部２１は、割り勘修正処理を終了する。

ここで、修正対象の買い物決済履歴が自己の端末２０のユーザによる買い物決済履歴である場合は「修正」となるが、修正対象の買い物決済履歴が異なる端末２０のユーザによる買い物決済履歴である場合は「修正提案」となる。

修正提案を行うユーザの端末２０の制御部２１は、Ａ５４３０において、ユーザによって入力された修正提案内容を判定し、Ａ５４４０において、修正提案対象の買い物決済履歴の買い物決済ＩＤと、修正提案内容とを含む割り勘精算修正依頼通知をサーバ１０に送信する。つまり、修正提案を行うユーザの端末２０では、買い物決済履歴は修正されない。
割り勘精算修正依頼通知がサーバ１０に送信されたことに基づき、サーバ１０から割り勘修正確認通知が対象端末に送信されるが、この割り勘修正確認通知に基づいて、修正提案された端末２０で、買い物決済履歴が修正される（Ａ５４７０：ＹＥＳ→Ａ５４８０→Ａ５３１０：ＮＯ→Ａ５４２０：ＹＥＳ、Ａ５４３０）。

なお、これとは異なり、修正提案を行うユーザの端末２０で、買い物決済履歴を修正できるようにしてもよいし、そのようにしなくてもよい。

図１７−１２に戻り、Ｓ２１０の後、サーバ１０の制御部１１は、第３の割り勘承認管理処理を実行する（Ｓ５４０）。

図１７−１４は、第３の割り勘承認管理処理の流れの一例を示すフローチャートである。
この処理は、第１の割り勘承認管理処理（図２−２０参照）におけるＳ２３１０のステップをＳ５４１０に置き換えるとともに、Ｓ５４２０〜Ｓ５４４０のステップを追加した処理である。本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」と、「割り勘精算修正依頼通知」とのうちのいずれかの通知である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。

制御部１１は、端末２０から割り勘精算通知を受信すると（Ｓ５４１０）、受信された割り勘精算通知が「割り勘精算修正依頼通知」であるか否かを判定する（Ｓ５４２０）。受信された割り勘精算通知が割り勘精算修正依頼通知ではないと判定したならば（５４２０：ＮＯ）、制御部１１は、Ｓ２３２０に処理を移す。

一方、受信された割り勘精算通知が割り勘精算修正依頼通知であると判定したならば（Ｓ５４２０：ＹＥＳ）、制御部１１は、受信された割り勘精算修正依頼通知に含まれる買い物決済ＩＤによって識別される買い物決済履歴について、同じく受信された割り勘精算修正依頼通知に含まれる修正内容に基づいて、過不足金額を計算（再計算）する（Ｓ５４３０）。

その後、制御部１１は、計算した過不足金額に基づいて、割り勘内容を変更する（Ｓ５４４０）。この割り勘内容の変更の処理は、サーバ１０の制御部１１によって実行される第１決済情報を第２決済情報に修正する処理の一例とも言える。
そして、制御部１１は、第３の割り勘承認管理処理を終了する。

図１７−１２に戻り、制御部１１は、第３の割り勘承認管理処理で割り勘内容が変更されたか否かを判定し（Ｓ５５０）、変更されたと判定したならば（Ｓ５５０：ＹＥＳ）、割り勘修正確認通知を、通信Ｉ／Ｆ１４によって端末Ａおよび端末Ｂそれぞれに送信する（Ｓ５８０）。そして、制御部１１は、Ｓ５４０に処理を戻す。

一方、第３の割り勘承認管理処理で割り勘内容が変更されなかったと判定したならば（Ｓ５５０：ＮＯ）、制御部１１は、Ｓ２４０に処理を移す。

Ａ５４０の後、端末Ａの制御部２１は、Ａ２５０に処理を移す。同様に、Ａ５４０の後、端末Ｂの制御部２１は、Ｂ２５０に処理を移す。

＜第１７実施例の効果＞
第１７実施例は、一のユーザの端末２０で修正された修正買い物決済履歴は、異なる端末２０のユーザによる、この修正買い物決済履歴に対するコメントを含む構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザが、一の端末で修正された第２決済情報に対してコメントを付すことを可能とすることができる。

また、第１７実施例は、一のユーザの端末２０で修正された修正買い物決済履歴は、この修正買い物決済履歴を通信Ｉ／Ｆ２２によってサーバ１０に送信した後、異なる端末２０のユーザの修正提案に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザが、一の端末で修正された第２決済情報を、この第２決済情報とは異なる第４決済情報にさらに修正することを可能とすることができる。

＜第１７変形例＞
第１７実施例では、修正提案があった場合に、各々の割り勘メンバーの端末２０に、サーバ１０から割り勘修正確認通知が送信されることとしたが、これに限定されない。具体的には、修正提案されたユーザの端末２０に対してのみ、サーバ１０から割り勘修正確認通知が送信されるようにしてもよいし、そのようにしなくてもよい。

また、修正／修正提案による買い物決済履歴の修正に伴い、損失が生ずる（損をする）ユーザの端末２０に対して、サーバ１０から割り勘修正確認通知が送信されるようにしてもよいし、そのようにしなくてもよい。

図１７−１５は、本変形例における過不足金額の変動を説明するための図であり、限定ではなく例として、操作種別と、操作内容と、過不足金額変動とを関連付けたテーブルを一例として示している。

操作種別は、買い物決済履歴の修正に関して操作者によって行われる操作であり、行われた操作が修正操作であることを示す「修正」と、行われた操作が修正提案操作であることを示す「修正提案」とがこれに含まれる。

操作内容は、その操作種別に従って、買い物決済履歴をどのように修正する操作が行われたかの内容である。

過不足金額変動は、各々の割り勘メンバーの過不足金額の変動であり、操作者の欄と、被操作者の欄と、その他割り勘メンバーの欄とがこれに含まれる。

操作者は、対応する操作種別の操作を行ったユーザである。

被操作者は、買い物決済履歴を登録したユーザである。操作種別「修正」は、操作者が自分の買い物決済履歴を修正する場合であるため、被操作者は存在しない。つまり、被操作者は、操作種別「修正提案」について、買い物決済履歴を登録したユーザであって、操作者によってその買い物決済履歴の修正提案を受けるユーザである。

その他割り勘メンバーは、割り勘メンバーのうち、操作者および被操作者を除外したユーザである。

過不足金額変動に含まれる各々の欄には、「増額」と、「減額」と、「増減なし（−）」とのうちのいずれかが定められている。
「増額」は、過不足金額の種別が「受取」である場合は、そのユーザが受け取る金額が増え、過不足金額の種別が「支払い」である場合は、そのユーザが支払う金額が減ることを意味している。
「減額」は、過不足金額の種別が「受取」である場合は、そのユーザが受け取る金額が減り、過不足金額の種別が「支払い」である場合は、そのユーザが支払う金額が増えることを意味している。

（１）操作種別「修正」
操作種別「修正」には、２種類の操作内容が定められている。
１つ目の操作内容は「買い物決済履歴追加／買い物決済金額上方修正」であり、これは、買い物決済履歴を追加する操作、または、買い物決済金額を上方修正する操作を意味する。
この場合、過不足金額変動として、操作者には「増額」が、その他割り勘メンバーには「減額」がそれぞれ定められている。

２つ目の操作内容は「買い物決済履歴取り下げ／買い物決済金額下方修正」であり、これは、買い物決済履歴を取り下げる操作、または、買い物決済金額を下方修正する操作を意味する。
この場合、過不足金額変動として、操作者には「減額」が、その他割り勘メンバーには「増額」がそれぞれ定められている。

（２）操作種別「修正提案」
操作種別「修正提案」にも、２種類の操作内容が定められている。
１つ目の操作内容は「買い物決済履歴追加提案／買い物決済金額上方修正提案」であり、これは、買い物決済履歴を追加する提案操作、または、買い物決済金額を上方修正する提案操作を意味する。
この場合、過不足金額変動として、操作者には「減額」が、被操作者には「増額」が、その他割り勘メンバーには「減額」がそれぞれ定められている。

２つ目の操作内容は「買い物決済履歴取り下げ提案／買い物決済金額下方修正提案」であり、これは、買い物決済履歴を取り下げる提案操作、または、買い物決済金額を下方修正する提案操作を意味する。
この場合、過不足金額変動として、操作者には「増額」が、被操作者には「減額」が、その他割り勘メンバーには「増額」がそれぞれ定められている。

図１７−１６は、本変形例における割り勘修正確認通知の送信の要否を説明するための図であり、限定ではなく例として、操作種別と、操作内容と、割り勘修正確認通知送信要否とを関連付けたテーブルを一例として示している。
操作種別および操作内容は、図１７−１５のテーブルにそれぞれ対応している。

割り勘修正確認通知送信要否は、割り勘修正確認通知のサーバ１０からの送信の要否であり、被操作者と、その他割り勘メンバーとがこれに含まれる。割り勘修正確認通知の送信が必要であるユーザ（そのユーザの端末２０）には「要」が、割り勘修正確認通知の送信が不要であるユーザ（そのユーザの端末２０）には「不要」がそれぞれ定められている。

（１）操作種別「修正」
操作内容「買い物決済履歴追加／買い物決済金額上方修正」において、割り勘修正確認通知送信要否のうち、その他割り勘メンバーには「要」が定められている。これは、図１７−１５のテーブルに示したように、この操作内容では、その他割り勘メンバーの過不足金額変動は「減額」であり、修正によって、その他割り勘メンバーが受け取る金額が減る、またはその他割り勘メンバーが支払う金額が増えることになる。これは、言うなれば、修正によって、その他割り勘メンバーは損をする（損失がある）ことになる。このため、割り勘修正確認通知の送信を「要」とし、修正を行うためには、その他割り勘メンバーの許可が必要となるようにしている。

操作内容「買い物決済履歴取り下げ／買い物決済金額下方修正」において、割り勘修正確認通知送信要否のうち、その他割り勘メンバーには「不要」が定められている。これは、図１７−１５のテーブルに示したように、この操作内容では、その他割り勘メンバーの過不足金額変動は「増額」であり、修正によって、その他割り勘メンバーが受け取る金額が増える、またはその他割り勘メンバーが支払う金額が減ることになる。これは、言うなれば、修正によって、その他割り勘メンバーは得をすることになる。このため、割り勘修正確認通知の送信を「不要」とし、修正を行うために、その他割り勘メンバーの許可が不要となるようにしている。

（２）操作種別「修正提案」
操作内容「買い物決済履歴追加提案／買い物決済金額上方修正提案」において、割り勘修正確認通知送信要否のうち、被操作者には「不要」が、その他割り勘メンバーには「要」がそれぞれ定められている。これは、図１７−１５のテーブルに示したように、この操作内容では、被操作者の過不足金額変動は「増額」であり、修正によって得をすることになるが、その他割り勘メンバーの過不足金額変動は「減額」であり、修正によって損をすることになるためである。

操作内容「買い物決済履歴取り下げ提案／買い物決済金額下方修正提案」において、割り勘修正確認通知送信要否のうち、被操作者には「要」が、その他割り勘メンバーには「不要」がそれぞれ定められている。これは、図１７−１５のテーブルに示したように、この操作内容では、被操作者の過不足金額変動は「減額」であり、修正によって損をすることになるが、その他割り勘メンバーの過不足金額変動は「増額」であり、修正によって得をすることになるためである。

この場合、サーバ１０の制御部１１は、図１７−１２の処理のＳ５８０において、割り勘修正確認通知を送信する必要あり（「要」）と判定された端末２０を対象端末として、対象端末にのみ割り勘修正確認通知を送信する。つまり、割り勘修正確認通知を送信する必要なし（「不要」）と判定された端末２０は、対象端末から除外され、この端末２０には割り勘修正確認通知が送信されない。

このようにすることで、割り勘修正確認通知を送信する必要あり（「要」）と判定された端末２０には、サーバ１０から割り勘修正確認通知が送信され、その端末２０において割り勘修正処理が実行される（図１７−１２のＳ５８０→Ａ５４０）。この場合、割り勘修正処理（図１７−１３参照）において、その端末２０のユーザが修正内容に同意し、結果的に割り勘に同意すると判定された場合は（図１７−１３のＡ５３１０：ＹＥＳ）、割り勘精算承認通知が端末２０からサーバ１０に送信されることになる（図１７−１３のＡ５３６０）。一方、その端末２０のユーザが修正内容に同意せず、結果的に割り勘に同意しないと判定された場合は（図１７−１３のＡ５３１０：ＮＯ、Ａ５４２０：ＮＯ）、割り勘精算拒否通知が端末２０からサーバ１０に送信されることになる（図１７−１３のＡ５３５０）。

その一方、割り勘修正確認通知を送信する必要なし（「不要」）と判定された端末２０には、サーバ１０から割り勘修正確認通知が送信されないため、その端末２０において割り勘修正処理は実行されない。このため、その端末２０において、修正内容に同意するか否かの確認は行われない。

本変形例は、修正買い物決済履歴は、異なる端末２０のユーザによる修正の許可に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる修正の許可がなければ、第１決済情報が第２決済情報に修正されないため、異なる端末のユーザに不利益が生ずることを防止できる。

また、本変形例は、異なる端末２０のユーザによって修正された修正買い物決済履歴は、自己の端末２０のユーザによる修正の許可に基づいて、さらに修正される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる修正の許可がなければ、第２決済情報が第４決済情報に修正されないため、端末のユーザに不利益が生ずることを防止できる。

＜第１８実施例＞
第１８実施例は、端末２０が、選択した買い物決済履歴に基づいて第１送金処理／第１受取処理を行った後に、その買い物決済履歴が修正され、この修正された買い物決済履歴に基づいて、第２送金処理／第２受取処理を実行する実施例である。選択した買い物決済履歴に基づいて一旦割り勘を行ったものの、ユーザが後から間違いに気づくような場合がある。

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

＜処理＞
図１８−１は、本実施例において端末２０が実行する割り勘処理の流れの一例を示すフローチャートである。
この処理は、図１の処理に、端末Ａの処理としてＡ６５〜Ａ７５のステップを追加し、端末Ｂの処理としてＢ７５のステップを追加した処理である。

Ａ６０の後、端末Ａの制御部２１は、入出力部２３に対して買い物決済履歴の修正を要求する操作が入力されたか否かに基づいて、Ａ１０で選択した買い物決済履歴について修正を行うか否かを判定する（Ａ６５）。修正を行うと判定したならば（Ａ６５：ＹＥＳ）、端末Ａの制御部２１は、買い物決済履歴修正処理を実行する（Ａ７０）。具体的には、限定ではなく例として、入出力部２３に対する修正操作に基づいて、Ａ１０で選択した買い物決済履歴を修正する。

その後、端末Ａの制御部２１は、買い物決済履歴の修正内容を含む買い物決済履歴修正情報を、通信Ｉ／Ｆ２２によって端末Ｂに送信する（Ａ７５）。そして、端末Ａの制御部２１は、Ａ４０に処理を戻す。

この場合、買い物決済履歴修正情報には、限定ではなく例として、修正前の買い物決済金額と修正後の買い物決済金額との差額の情報を含めるようにすることができる。
そして、この場合、端末Ｂの制御部２１は、端末Ａから受信された買い物決済履歴修正情報に基づいて、修正前の買い物決済金額と修正後の買い物決済金額との差額から、端末２０のユーザが追加で送金すべき金額、または端末２０のユーザが追加で受け取るべき金額を計算するようにすることができる。

なお、これとは異なり、限定ではなく例として、修正後の買い物決済金額の情報を買い物決済履歴修正情報に含めるようにし、修正後の買い物決済金額に基づいて割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、修正前の買い物決済金額に基づく割り勘精算処理で金額を受け取ったユーザから金額を回収し、金額を支払ったユーザに返金するなどして、割り勘精算を行う前の状態に戻す処理（ロールバック処理、リセット処理）を実行する。そして、修正後の買い物決済金額に基づく割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。

Ｂ６０の後、端末Ｂの制御部２１は、通信Ｉ／Ｆ２２によって端末Ａから買い物決済履歴修正情報を受信したか否かを判定し（Ｂ７５）、受信したと判定したならば（Ｂ７５：ＹＥＳ）、Ｂ３０に処理を戻す。

Ａ６５において修正を行わないと判定したならば（Ａ６５：ＮＯ）、端末Ａの制御部２１は、割り勘処理を終了する。
また、Ｂ７５において買い物決済履歴修正情報を受信しなかったと判定したならば（Ｂ７５：ＮＯ）、端末Ｂの制御部２１は、割り勘処理を終了する。

＜第１８実施例の効果＞
第１８実施例は、端末２０は、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザによる買い物決済情報を通信Ｉ／Ｆ２２によって異なる端末２０に送信する。端末２０は、少なくとも自己の端末２０の過不足金額の情報を通信Ｉ／Ｆ２２によって異なる端末２０から受信する。端末２０は、受信された過不足金額に基づく割り勘精算処理（割り勘精算処理）（限定ではなく、第１送金処理、または第１受取処理の一例）を制御部２１によって実行する。そして、上記の買い物決済情報が修正された場合、端末２０は、修正買い物決済履歴に基づいて、割り勘精算処理（限定ではなく、第２送金処理、または第２受取処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１金額に基づく第１送金処理、または第１受取処理を実行した後、第１決済情報から第２決済情報に修正された場合であっても、第２送金処理、または第２受取処理を実行して、精算した金額を事後的に調整することができる。

また、第１８実施例は、端末２０は、メモリに記憶されたプログラムを読み出し、読み出したプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザによる買い物決済情報を通信Ｉ／Ｆ２２によって異なる端末２０に送信することと、少なくとも自己の端末２０の過不足金額の情報を通信Ｉ／Ｆ２２によって異なる端末２０から受信することと、受信された過不足金額に基づく割り勘精算処理（割り勘精算処理）（限定ではなく、第１送金処理、または第１受取処理の一例）を実行することと、上記の買い物決済情報が修正された場合、修正買い物決済履歴に基づいて、割り勘精算処理（限定ではなく、第２送金処理、または第２受取処理の一例）を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。

また、第１８実施例は、買い物決済履歴を修正した後の割り勘精算処理（限定ではなく、第２送金処理、または第２受取処理の一例）は、修正買い物決済履歴の買い物決済金額と元買い物決済履歴の買い物決済金額との差額に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第２決済情報と第１決済情報との差額に基づき、精算した金額を事後的に正しく調整することができる。

＜第１８変形例＞
第１８実施例において割り勘精算を行う際に、異なる端末２０、または異なる端末２０のユーザの許可を必要としてもよいし、そのようにしなくてもよい。

図１８−２は、本変形例において端末２０が実行する割り勘処理の流れの別例を示すフローチャートである。
この処理は、図１の処理に、端末Ａの処理としてＡ８０〜Ａ８６のステップを追加し、端末Ｂの処理としてＢ８０〜Ｂ８６のステップを追加した処理である。

Ａ６０の後、端末Ａの制御部２１は、買い物決済履歴の事後修正を行うか否かを判定する（Ａ８０）。事後修正を行わないと判定したならば（Ａ８０：ＮＯ）、端末Ａの制御部２１は、Ａ９０に処理を移す。

一方、事後修正を行うと判定したならば（Ａ８０：ＹＥＳ）、端末Ａの制御部２１は、買い物決済履歴修正処理を実行する（Ａ８２）。そして、端末Ａの制御部２１は、買い物決済履歴修正情報を、通信Ｉ／Ｆ２２によって端末Ｂに送信する。

Ｂ６０の後、端末Ｂの制御部２１は、通信Ｉ／Ｆ２２によって端末Ａから買い物決済履歴修正情報を受信したか否かを判定する（Ｂ８０）。受信しなかったと判定したならば（Ｂ８０：ＮＯ）、端末Ｂの制御部２１は、Ｂ９０に処理を移す。

一方、買い物決済履歴修正情報を受信したと判定したならば（Ｂ８０：ＹＥＳ）、端末Ｂの制御部２１は、その買い物決済履歴修正情報に基づき、自己の端末２０のユーザが修正に同意したか否かを判定する（Ｂ８２）。

修正に同意したと判定したならば（Ｂ８２：ＹＥＳ）、端末Ｂの制御部２１は、Ｂ４０に処理を戻す。一方、修正に同意しなかったと判定したならば（Ｂ８２：ＮＯ）、端末Ｂの制御部２１は、修正拒否通知を通信Ｉ／Ｆ２２によって端末Ａに送信する（Ｂ８６）。そして、端末Ｂの制御部２１は、Ｂ９０に処理を移す。

Ａ８４の後、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によって端末Ｂから修正拒否通知を受信したか否かを判定する（Ａ８６）。受信しなかったと判定したならば（Ａ８６：ＮＯ）、端末Ａの制御部２１は、Ａ４０に処理を戻す。

一方、修正拒否通知を受信したと判定したならば（Ａ８６：ＹＥＳ）、端末Ａの制御部２１は、Ａ９０に処理を移す。

本変形例は、買い物決済履歴の修正後の割り勘精算処理は、異なる端末２０から修正拒否通知を受信しない場合に実行される構成を示している。
このような構成により得られる効果の一例として、異なる端末、または異なる端末のユーザの許可に基づいて、精算金額を事後的に調整することができる。

なお、上記の処理において、修正買い物決済履歴が、元買い物決済履歴よりも買い物決済金額が減額されるように修正されたものである場合、異なる端末２０、または異なる端末２０のユーザによる許可なく、端末２０の制御部２１が、割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。

限定ではなく例として、割り勘マスターによって、元買い物決済履歴よりも買い物決済金額が減額されるように修正された場合、他の割り勘メンバーには、その割り勘メンバーが最初に送金した金額のうちの一部の金額が返金されることになる。言うなれば、他の割り勘メンバーは得をすることになるため、割り勘精算に許可は不要と考えられる。

一方、限定ではなく例として、割り勘マスター以外の割り勘メンバーによって、元買い物決済履歴よりも買い物決済金額が減額されるように修正された場合は、その割り勘メンバーの意思で買い物決済履歴が修正されたことになる。このため、この場合も、割り勘精算に許可は不要と考えられる。

本変形例は、買い物決済履歴の修正後の割り勘精算処理は、修正買い物決済履歴が元買い物決済履歴よりも決済金額が減額された場合、異なる端末２０、または異なる端末２０のユーザの許可なく実行される構成を示している。
このような構成により得られる効果の一例として、第１決済情報の修正によって異なる端末のユーザが金額的に得をする場合や、異なる端末のユーザに金額的な損失がない場合に、異なる端末、または異なる端末のユーザの許可を不要として第２送金処理、または第２受取処理を行うことができる。

＜第１９実施例＞
第１９実施例は、端末２０がサーバ１０と通信を行って、修正した買い物決済履歴に基づく精算金額の事後的な調整を行う実施例である。

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

＜処理＞
図１９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図２−１９の処理部分におけるＡ３５０、Ｂ３５０、Ｓ３４０から開始される処理であり、割り勘精算が実行された後に、割り勘修正処理を実行する処理である。

この処理では、Ａ３５０の後、端末Ａの制御部２１は、割り勘修正処理を実行する（Ａ５４０）。この割り勘修正処理は、図１７−１３と同じである。
同様に、Ｂ３５０の後、端末Ｂの制御部２１は、割り勘修正処理を実行する（Ａ５４０）。

一方、Ｓ３４０の後、サーバ１０の制御部１１は、第３の割り勘承認管理処理を実行する（Ｓ５４０）。この第３の割り勘承認管理処理は、図１７−１４と同じである。

割り勘内容が変更されなかったと判定したならば（Ｓ５５０：ＮＯ）、制御部１１は、割り勘修正が成立したか否かを判定する（Ｓ９６０）。割り勘修正が成立したと判定したならば（Ｓ９６０：ＹＥＳ）、制御部１１は、図２−１９のＳ３１０に処理を移す。

一方、割り勘修正が成立しなかったと判定したならば（Ｓ９６０：ＮＯ）、制御部１１は、割り勘修正が成立しなかったことを通知するための割り勘修正不成立通知を、通信Ｉ／Ｆ１４によって対象端末（この例では端末Ａおよび端末Ｂ）それぞれに送信する（Ｓ９７０）。そして、制御部１１は、Ｓ３９０に処理を移す。

Ａ５４０の後、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から割り勘修正不成立通知を受信したか否かを判定し（Ａ９７０）、受信しなかったと判定したならば（Ａ９７０：ＮＯ）、図２−１９のＡ３１０に処理を移す。

一方、割り勘修正不成立通知を受信したと判定したならば（Ａ９７０：ＹＥＳ）、端末Ａの制御部２１は、受信された割り勘修正不成立通知を表示部２４に表示させる（Ａ９８０）。そして、端末Ａの制御部２１は、Ａ３９０に処理を移す。
Ａ５４０の後、端末Ｂも、同様の処理を行う（Ｂ９７０、Ｂ９８０）。

＜第１９実施例の効果＞
第１９実施例は、端末２０が、元買い物決済履歴に基づく、自己の端末２０のユーザの過不足金額（限定ではなく、第３金額の一例）と、自己の端末２０とは異なる端末２０のユーザを含む複数の端末２０の各々のユーザの過不足金額とのうち、少なくとも自己の端末２０のユーザの過不足金額の情報を通信Ｉ／Ｆ２２によってサーバ１０から受信する。端末２０は、受信された過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第３金額に基づく第３送金処理、または第３受取処理の一例）を制御部２１によって実行する。元買い物決済履歴が修正された場合、端末２０は、修正買い物決済履歴に基づいて、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第４送金処理、または第４受取処理の一例）を制御部２１によって実行する。そして、修正買い物決済履歴に基づく割り勘精算要求処理は、複数の端末２０の各々のユーザの許可に基づいて実行される。
このような構成により得られる効果の一例として、異なる端末のユーザを含む複数の端末の各々のユーザの許可に基づいて、精算金額を事後的に調整することができる。

また、第１９実施例は、端末２０のユーザによる買い物決済履歴は、異なる端末２０のユーザによって修正提案（限定ではなく、修正依頼の一例）される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる修正依頼に基づいて、第１決済情報を第２決済情報に修正することができる。

また、第１９実施例は、割り勘精算処理は、端末２０から送信される割り勘精算承認通知（限定ではなく、端末のユーザの許可の一例）と、異なる端末２０から送信される割り勘精算承認通知（限定ではなく、異なる端末のユーザの許可の一例）とに少なくとも基づいて、サーバ１０によって実行される構成を示している。
このような構成により得られる効果の一例として、端末のユーザの許可と、異なる端末のユーザの許可とに少なくとも基づいて、第１送金処理、または第１受取処理が実行されるため、少なくとも端末のユーザと異なる端末のユーザとの同意なく、第１送金処理、または第１受取処理が実行されないようにすることができる。

また、第１９実施例は、サーバ１０が、端末２０のユーザによる端末２０に対する入力に基づいて、端末２０のユーザによる買い物決済履歴を通信Ｉ／Ｆ１４によって端末２０から受信する。サーバ１０は、受信された買い物決済履歴に基づく、少なくとも端末２０のユーザの過不足金額（限定ではなく、第１金額の一例）の情報を端末２０に通信Ｉ／Ｆ１４によって送信し、少なくとも異なる端末２０のユーザの過不足金額（限定ではなく、第２金額の一例）の情報を異なる端末２０に通信Ｉ／Ｆ１４によって送信する。サーバ１０は、割り勘精算処理（限定ではなく、第１金額に基づく、端末に対する第１送金処理、または第１受取処理と、第２金額に基づく、異なる端末に対する第２送金処理、または第２受取処理との一例）を制御部１１によって実行する。また、サーバ１０は、割り勘精算修正依頼通知（限定ではなく、第１決済情報から第２決済情報に修正することに関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０から受信する。そして、サーバ１０は、買い物決済履歴（限定ではなく、第１決済情報の一例）が修正された場合、修正買い物決済履歴（限定ではなく、第２決済情報の一例）に基づいて、割り勘精算処理（限定ではなく、端末に対する第３送金処理、または第３受取処理と、異なる端末に対する第４送金処理、または第４受取処理との一例）を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１金額に基づく第１送金処理、または第１受取処理を実行した後、第１決済情報から第２決済情報に修正された場合であっても、第２送金処理、または第２受取処理を実行して、精算した金額を事後的に調整することができる。また、端末でこれらの処理を実行せずに済むため、端末の処理負荷を軽減することができる。

＜第１９変形例＞
第１９実施例において、各々の割り勘メンバーのうち、買い物決済履歴が修正されることで損失があるユーザの許可を必要として、精算金額を事後的に調整するようにしてもよいし、そのようにしなくてもよい。

この場合は、図１７−１５および図１７−１６で説明した手法を同様の手法によって、割り勘修正確認通知送信要否を判定する。そして、サーバ１０の制御部１１は、図１９の処理のＳ５８０において、割り勘修正確認通知を送信する必要あり（「要」）と判定された端末２０を対象端末とし、対象端末にのみ割り勘修正確認通知を送信する。これは、前述した通りである。

本変形例は、割り勘精算要求処理は、自己の端末２０とは異なる端末２０のユーザを含む複数の端末２０の各々のユーザのうち、元買い物決済履歴が修正されることで損失があるユーザの許可に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第４送金処理、または第４受取処理が、端末とは異なる端末のユーザを含む複数の端末の各々のユーザのうち、第１決済情報から第２決済情報に修正されることで損失があるユーザの許可に基づいて実行されるようにすることで、損失があるユーザの確認を求めることができる。

＜第２０実施例＞
第２０実施例は、自己の端末２０のユーザによる買い物決済履歴と、異なる端末２０のユーザによる買い物決済履歴とに基づく割り勘精算が行われた後、異なる端末２０のユーザによる買い物決済履歴を修正提案によって修正する実施例である。

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

先の実施例で説明したように、本開示の手法によれば、一の端末２０のユーザによる買い物決済履歴に加えて、異なる端末２０のユーザの買い物決済履歴も、一緒に割り勘対象に含めることができる。この場合、一の端末２０のユーザによって登録された買い物決済履歴の買い物決済金額と、異なる端末２０のユーザによって登録された買い物決済履歴の買い物決済金額とに基づいて、サーバ１０によって過不足金額が計算されることになる。

図２０は、本実施例において端末２０からサーバ１０に送信される割り勘精算通知種別を説明するための図であり、操作種別と、精算種別と、割り勘精算通知種別とが関連付けられたテーブルを示している。

操作種別には、「修正」と「修正提案」とが含まれる。

精算種別には、「元精算」と「事後精算」とが含まれる。
「元精算」は、おおもとの割り勘精算（１回目の割り勘精算）である。第１送金処理、または第１受取処理を実行することが、これに相当する。
「事後精算」は、先の割り勘精算で精算された金額を事後的に調整する精算（２回目以降の精算）である。前述したように、第１送金処理、または第１受取処理を実行した後、第１決済情報から第２決済情報に修正されたことに基づき、第２送金処理、または第２受取処理を実行することが、これに相当する。

割り勘精算通知種別には、図１７−１３の割り勘修正処理で端末２０がサーバ１０に送信する割り勘精算通知の種別が定められている。

このテーブルによれば、操作種別「修正」、「修正提案」のいずれであるかに依らず、また、精算種別「元精算」、「事後精算」のいずれであるかに依らず、割り勘精算通知種別として「割り勘精算修正依頼通知」が定められている。つまり、修正と修正提案とのいずれを行う場合であっても、また、元精算と事後精算とのいずれを行う場合であっても、割り勘精算通知として割り勘精算修正依頼通知を端末２０からサーバ１０に送信することが定められている。

本実施例では、上記のようにして計算された過不足金額に基づき、サーバ１０によって割り勘精算処理が実行される。その後、限定ではなく例として、端末２０の制御部２１は、自己の端末２０のユーザによって、異なる端末２０のユーザによって登録された買い物決済履歴の「修正提案」を行う操作がなされた場合、図１７−１３の割り勘修正処理において、上記のように割り勘精算修正依頼通知を通信Ｉ／Ｆ２２によってサーバ１０に送信する。

なお、上記とは異なり、操作種別「修正」と、操作種別「修正提案」とで、異なる種別の割り勘精算通知を端末２０からサーバ１０に送信するようにしてもよいし、そのようにしなくてもよい。
同様に、精算種別「元精算」と、精算種別「事後精算」とで、異なる種別の割り勘精算通知を端末２０からサーバ１０に送信するようにしてもよいし、そのようにしなくてもよい。

＜第２０実施例の効果＞
第２０実施例は、端末２０は、自己の端末２０のユーザによる買い物決済履歴（限定ではなく、第１決済情報の一例）と、異なる端末２０のユーザによる買い物決済履歴（限定ではなく、異なる端末のユーザによる第２決済に関する処理に基づく第３決済情報の一例）とに基づく、自己の端末２０のユーザの過不足金額（限定ではなく、第５金額の一例）と、異なる端末２０のユーザの過不足金額（限定ではなく、第６金額の一例）とのうち、少なくとも自己の端末２０のユーザの過不足金額の情報を通信Ｉ／Ｆ２２によって受信する。端末２０は、受信された自己の端末２０のユーザの過不足金額に基づく割り勘精算要求処理や割り勘精算結果受信処理を制御部２１によって実行する。そして、端末２０は、異なる端末２０のユーザによる買い物決済履歴の修正依頼を求める割り勘精算修正依頼通知（限定ではなく、第３決済情報から第４決済情報に修正することに関する情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０に送信する構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる第１決済に関する処理に基づく第１決済情報と、異なる端末のユーザによる第２決済に関する処理に基づく第３決済情報とに基づき、第５送金処理、または第５受取処理を実行した後、限定ではなく例として、第３決済情報から第４決済情報に修正することを、異なる端末のユーザに提案することができる。

また、第２０実施例は、端末２０が、異なる端末２０のユーザによる買い物決済履歴（限定ではなく、第３決済情報の一例）が修正された場合、この修正された買い物決済履歴（限定ではなく、第４決済情報の一例）に基づいて、割り勘精算要求処理や割り勘精算結果受信処理（限定ではなく、第６送金処理、または第６受取処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第３決済情報から第４決済情報に修正された場合、第４決済情報に基づいて、第６送金処理、または第６受取処理を制御部によって実行することで、一旦精算を行った後に異なる端末のユーザによる決済情報が修正された場合であっても、精算金額を事後的に調整することができる。

＜第２１実施例＞
第２１実施例は、端末２０が、自己の端末２０のユーザによる買い物決済履歴について割り勘精算が行われた後、自己の端末２０のユーザによる買い物決済履歴を修正し、その修正内容に基づいて、精算金額を事後的に調整する実施例である。

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

＜表示画面例＞
図２１−１は、本実施例におけるメッセージングアプリケーションのトークルーム画面に表示される割り勘完了通知の一例を示す図であり、ユーザＡ．Ａの端末２０の表示部２４に表示される画面の一例を示している。
このトークルーム画面には、ユーザＢ．Ｂが割り勘精算を行うことに同意したことに基づいて、ユーザＢ．ＢからユーザＡ．Ａに過不足金額（この例では「２，２５０円）が送金され、その結果として、割り勘が完了したことを示す割り勘完了通知のメッセージが表示されている。

割り勘完了通知のメッセージには、限定ではなく例として、精算結果とともに、精算内容を修正するための、限定ではなく例として「精算内容の修正」と示された精算内容修正アイコンが含まれる。

図２１−２は、図２１−１において精算内容修正アイコンが操作されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示される精算内容修正画面の一例を示す図である。
この精算内容修正画面には、限定ではなく例として、「割り勘の精算内容を確認してください」の文字が表示され、その下に、ユーザＡ．ＡおよびユーザＢ．Ｂそれぞれの支払い済み金額が表示される支払い済み金額一覧表示領域と、ユーザＡ．ＡおよびユーザＢ．Ｂそれぞれの精算金額が表示される精算金額一覧表示領域とが設けられている。

この例では、ユーザＡ．Ａの支払い済み金額として「４，５００円」が、ユーザＢ．Ｂの支払い済み金額として「０円」がそれぞれ表示されている。また、ユーザＡ．ＡおよびユーザＢ．Ｂの精算金額として、それぞれ「２，２５０円」が表示されている。

支払い済み金額表示領域において、ユーザＡ．Ａの欄には、ユーザＡ．Ａの支払い済み金額に対してユーザＡ．Ａが修正を行うための「修正」と示された修正アイコンが表示されている。また、ユーザＢ．Ｂの欄には、ユーザＢ．Ｂの支払い済み金額に対してユーザＡ．Ａが修正提案を行うための「修正提案」と示された修正提案アイコンが表示されている。

図２１−３は、図２１−２においてユーザＡ．Ａが修正アイコンを操作したことに基づいて表示される修正対象買い物決済履歴選択画面の一例を示す図である。
この修正対象買い物決済履歴選択画面は、ユーザＡ．Ａが修正対象とする買い物決済履歴を選択するための画面であり、ユーザＡ．Ａが登録済みの買い物決済履歴として、「ＡＡレンタサイクル」の買い物決済履歴と、「ＢＢスーパー」の買い物決済履歴とが表示されている。また、この例では、ユーザＡ．Ａによって、「ＢＢスーパー」に関連付けられたチェックボックスのチェックが「ＯＮ」とされた状態が示されている。

画面下部には、買い物決済履歴を追加して登録するため「支払い分を追加」と示された買い物決済履歴追加アイコンと、修正対象として選択された買い物決済履歴の買い物決済金額を修正するための「金額修正」と示された金額修正アイコンと、登録済みの買い物決済履歴を取り下げるための「取り下げ」と示された取り下げアイコンとが表示されている。この例では、ユーザＡ．Ａによって金額修正アイコンが操作された状態が示されている。

図２１−４は、この例においてユーザＢ．Ｂの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面では、画面向かって左側に、ユーザＡ．Ａからのメッセージとして、精算済みの買い物決済履歴を事後的に修正したことを示すメッセージが表示されている。この例では、ユーザＡ．Ａによる「ＢＢスーパー」の買い物決済履歴のうち、購入された商品である温泉まんじゅうの代金を減額する修正が行われたことが示されている。

具体的には、「ＢＢスーパー」の買い物決済履歴における買い物決済金額が「３，０００円→２，４００円」に減額され、これにより、「ＡＡレンタサイクル」の買い物決済履歴の買い物決済金額「１，５００円」との合計金額が、「４，５００円→３，９００円」に減額されている。そして、その結果、１人あたり金額が「２，２５０円→１，９５０円」に減額されたことが示されている。ユーザＢ．Ｂは、ユーザＡ．Ａに「２，２５０円」を送金済みであるが、この修正にユーザＢ．Ｂが承諾すると、差額である「３００円」がユーザＡ．ＡからユーザＢ．Ｂに返金されることになる。このため、ユーザＢ．Ｂの過不足金額として「３００円 受取」が表示されている。

また、メッセージの下部には、上記の修正を承諾するための、限定ではなく例として「承諾する」と示された承諾アイコンと、上記の修正を却下するための、限定ではなく例として「却下する」と示された却下アイコンとが表示されている。

図２１−５は、図２１−４のトークルーム画面においてユーザＢ．Ｂによって承諾アイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
承諾アイコンが操作されたことに基づいて、「承諾する」というメッセージがユーザＡ．Ａの端末２０に送信される。そして、ユーザＡ．Ａが自分の端末２０で精算を実行する操作を行ったことに基づき、ユーザＡ．Ａの端末２０から「精算する」というメッセージがユーザＢ．Ｂの端末２０に送信されて表示される。その後、ユーザＡ．Ａの端末２０からユーザＢ．Ｂの端末２０に、修正に伴うユーザＢ．Ｂの過不足金額（この例では「３００円」）が送金され、その結果、「Ａ．Ａさんから３００円を受け取りました」という文字を含む受取完了通知が表示される。また、その下には、買い物決済履歴の修正に伴う、割り勘精算結果が表示される。

＜処理＞
この場合の処理の流れについて、図１９の処理等を参照して説明する。本処理は、限定ではなく例として、図１９の処理に、メッセージングサーバ４０の処理を追加することによって実現される。

割り勘の精算が完了した後、サーバ１０が、割り勘精算結果をメッセージングサーバ４０に送信する（図１９のＳ３４０に相当）。そして、メッセージングサーバ４０が、サーバ１０から受信された割り勘精算結果を端末Ａおよび端末Ｂに送信する。

買い物決済履歴を登録した端末Ａの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図１９のＡ３５０に相当）。

その後、端末Ａの制御部２１は、限定ではなく例として、ユーザＡ．Ａによって精算内容を修正する操作が入出力部２３に対して入力されたことに基づいて、割り勘修正処理を実行する（図１９のＡ５４０に相当）。そして、制御部２１は、割り勘精算修正依頼通知を、メッセージングサーバ４０を介してサーバ１０に送信する（図１７−１３のＡ５４４０に相当）。

この場合、サーバ１０は、第３の割り勘承認管理処理を実行する（図１９のＳ５４０に相当）。この例では、ユーザＡ．Ａによって精算内容が修正されたため（図１９のＳ５５０：ＹＥＳに相当）、サーバ１０は、割り勘修正確認通知を、メッセージングサーバ４０を介して端末Ａおよび端末Ｂに送信する（図１９のＳ５８０に相当）。

端末Ｂの制御部２１は、メッセージングサーバ４０から受信された割り勘修正確認通知を、メッセージングアプリケーションのトークルームに表示させる。そして、端末Ｂの制御部２１は、ユーザＢ．Ｂによって、ユーザＡ．Ａによる修正を承認してその内容で割り勘に同意する操作が入出力部２３に入力されたことに基づいて、割り勘精算承認通知を、メッセージングサーバ４０を介してサーバ１０に送信する（図１７−１３のＡ５３６０）。

これにより、サーバ１０の制御部１１は、ユーザＢ．Ｂによって割り勘に同意されたと判定し、割り勘精算処理を実行する（図２−１９のＳ３３０に相当）。そして、制御部１１は、割り勘精算結果を、メッセージングサーバ４０を介して端末Ａおよび端末Ｂに送信する（図２−１９のＳ３４０に相当）。

端末Ａの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図２−１９のＡ３４０、Ａ３５０に相当）。
同様に、端末Ｂの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図２−１９のＢ３４０、Ｂ３５０に相当）。

なお、上記では、メッセージングアプリケーションを利用して、端末２０が、自己の端末２０のユーザによる買い物決済履歴を修正し、その修正に基づいて、精算金額を事後的に調整することとしたが、メッセージングアプリケーションは必須ではなく、メッセージングアプリケーションおよびメッセージングサーバ４０を構成要件から除外してもよいし、除外しなくてもよい。

＜第２１実施例の効果＞
第２１実施例は、端末２０が、割り勘完了通知（限定ではなく、第１送金処理、または第１受取処理の完了に関する通知の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、第１送金処理、または第１受取処理が完了したことを端末のユーザに報知することができる。

また、第２１実施例は、端末２０は、表示した割り勘完了通知に対する自己の端末２０のユーザの操作に基づいて、元買い物決済履歴を修正することに関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１送金処理、または第１受取処理の完了に関する通知に対する入力を行うことで、端末のユーザは、第１決済情報から第２決済情報に決済情報を修正させることができる。

また、第２１実施例は、割り勘完了通知は、端末２０のユーザと、異なる端末２０のユーザとを含むトークルーム（限定ではなく、チャットルームの一例）に表示される構成を示している。
このような構成により得られる効果の一例として、端末のユーザと、異なる端末のユーザとを含み、端末から異なる端末に送信されたコンテンツと、異なる端末から端末に送信されたコンテンツとを含むチャットルームへの表示という分かり易い形で、第１送金処理、または第１受取処理の完了をユーザに報知することができる。

＜第２２実施例＞
第２２実施例は、端末２０が、異なる端末２０のユーザによる買い物決済履歴について割り勘精算が行われた後、その異なる端末２０のユーザによる買い物決済履歴に対して修正提案を行い、その修正提案による修正内容に基づいて、精算金額を事後的に調整する実施例である。
第２２実施例は、異なる端末２０のユーザによる買い物決済履歴に対して修正提案を行って、精算金額を事後的に調整する点が第２１実施例とは異なる。

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

＜表示画面例＞
図２２−１は、本実施例におけるメッセージングアプリケーションのトークルーム画面に表示される割り勘完了通知の一例を示す図であり、ユーザＢ．Ｂの端末２０の表示部２４に表示される画面の一例を示している。
このトークルーム画面には、ユーザＢ．Ｂが割り勘精算を行うことに同意したことに基づいて、ユーザＢ．ＢからユーザＡ．Ａに過不足金額（この例では「２，２５０円）が送金され、その結果として、割り勘が完了したことを示す割り勘完了通知のメッセージが表示されている。

割り勘完了通知のメッセージには、限定ではなく例として、精算結果とともに、精算内容を修正するための、限定ではなく例として「精算内容の修正」と示された精算内容修正アイコンが含まれる。

図２２−２は、図２１−１において精算内容修正アイコンが操作されたことに基づいてユーザＢ．Ｂの端末２０の表示部２４に表示される精算内容修正画面の一例を示す図である。
この精算内容修正画面には、限定ではなく例として、「割り勘の精算内容を確認してください」の文字が表示され、その下に、ユーザＡ．ＡおよびユーザＢ．Ｂそれぞれの支払い済み金額が表示される支払い済み金額一覧表示領域と、ユーザＡ．ＡおよびユーザＢ．Ｂそれぞれの精算金額が表示される精算金額一覧表示領域とが設けられている。

この例では、ユーザＡ．Ａの支払い済み金額として「４，５００円」が、ユーザＢ．Ｂの支払い済み金額として「０円」がそれぞれ表示されている。また、ユーザＡ．ＡおよびユーザＢ．Ｂの精算金額として、それぞれ「２，２５０円」が表示されている。

支払い済み金額表示領域において、ユーザＡ．Ａの欄には、ユーザＡ．Ａの支払い済み金額に対してユーザＢ．Ｂが修正提案を行うための「修正提案」と示された修正提案アイコンが表示されている。また、ユーザＢ．Ｂの欄には、ユーザＢ．Ｂの支払い済み金額に対してユーザＢ．Ｂが修正を行うための「修正」と示された修正アイコンが表示されている。

図２２−３は、図２２−２においてユーザＢ．Ｂが修正提案アイコンを操作したことに基づいて表示される修正対象買い物決済履歴選択画面の一例を示す図である。
この修正対象買い物決済履歴選択画面は、ユーザＢ．Ｂが修正提案対象とする買い物決済履歴を選択するための画面であり、ユーザＡ．Ａが登録済みの買い物決済履歴として、「ＡＡレンタサイクル」の買い物決済履歴と、「ＢＢスーパー」の買い物決済履歴とが表示されている。また、この例では、ユーザＢ．Ｂによって、「ＢＢスーパー」に関連付けられたチェックボックスのチェックが「ＯＮ」とされた状態が示されている。

画面下部には、買い物決済履歴の追加を提案するための「支払い分の追加提案」と示された買い物決済履歴追加提案アイコンと、修正提案対象として選択された買い物決済履歴の買い物決済金額の修正提案を行うための「金額修正提案」と示された金額修正提案アイコンと、登録済みの買い物決済履歴を取り下げる提案を行うための「取り下げ提案」と示された取り下げ提案アイコンとが表示されている。この例では、ユーザＢ．Ｂによって金額修正提案アイコンが操作された状態が示されている。

図２２−４は、この例においてユーザＡ．Ａの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面では、画面向かって左側に、ユーザＢ．Ｂからのメッセージとして、ユーザＡ．Ａが登録した買い物決済履歴の修正を提案するメッセージが表示されている。この例では、ユーザＡ．Ａによる「ＢＢスーパー」の買い物決済履歴について、ユーザＡ．ＡがＢＢスーパーで自分用のお土産を購入しており、その分の金額を減額すべきではないかとの提案がユーザＢ．Ｂによってなされた状態が示されている。

具体的には、「ＢＢスーパー」の買い物決済履歴における買い物決済金額が「３，０００円→２，４００円」に減額され、その結果、「ＡＡレンタサイクル」の買い物決済履歴の買い物決済金額「１，５００円」との合計金額が、「４，５００円→３，９００円」に減額される。そして、その結果、１人あたり金額が「２，２５０円→１，９５０円」に減額されることが示されている。ユーザＢ．Ｂは、既に「２，２５０円」を送金済みであるが、ユーザＡ．Ａによって修正提案が承諾されると、差額である「３００円」がユーザＡ．ＡからユーザＢ．Ｂに返金されることになる。このため、ユーザＡ．Ａの過不足金額として「３００円 支払い」が表示されている。

また、メッセージの下部には、上記の修正提案を承諾するための、限定ではなく例として「承諾する」と示された承諾アイコンと、上記の修正提案を却下するための、限定ではなく例として「却下する」と示された却下アイコンとが表示されている。

図２２−５は、図２２−４のトークルーム画面においてユーザＡ．Ａによって承諾アイコンが操作されたことに基づいてユーザＡ．Ａの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
承諾アイコンが操作されたことに基づいて、「承諾する」というメッセージがユーザＢ．Ｂの端末２０に送信される。その後、ユーザＡ．Ａの端末２０からユーザＢ．Ｂの端末２０に、修正に伴う過不足金額（この例では「３００円」）が送金され、その結果、「Ｂ．Ｂさんに３００円を送金しました」という文字を含む送金完了通知が表示される。

＜処理＞
この場合の処理の流れについて、図１９の処理等を参照して説明する。
本処理は、限定ではなく例として、図１９の処理に、メッセージングサーバ４０の処理を追加することによって実現される。

割り勘の精算が完了した後、サーバ１０が、割り勘精算結果をメッセージングサーバ４０に送信する（図１９のＳ３４０に相当）。そして、メッセージングサーバ４０が、サーバ１０から受信された割り勘精算結果を端末Ａおよび端末Ｂに送信する。

買い物決済履歴を登録した端末Ｂの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図１９のＢ３５０に相当）。

その後、端末Ｂの制御部２１は、限定ではなく例として、ユーザＢ．Ｂによって精算内容の修正提案を行う操作が入出力部２３に対して入力されたことに基づいて、割り勘修正処理を実行する（図１９のＢ５４０に相当）。そして、端末Ｂの制御部２１は、割り勘精算修正依頼通知を、メッセージングサーバ４０を介してサーバ１０に送信する（図１７−１３のＡ５４４０に相当）。

この場合、サーバ１０は、第３の割り勘承認管理処理を実行する（図１９のＳ５４０に相当）。この例では、ユーザＢ．Ｂによって精算内容の修正提案が行われたため（図１９のＳ５５０：ＹＥＳに相当）、サーバ１０は、割り勘修正確認通知を、メッセージングサーバ４０を介して端末Ａおよび端末Ｂに送信する（図１９のＳ５８０に相当）。

端末Ａの制御部２１は、メッセージングサーバ４０から受信された割り勘修正確認通知を、メッセージングアプリケーションのトークルームに表示させる。そして、端末Ａの制御部２１は、ユーザＡ．Ａによって、ユーザＢ．Ｂからの修正提案を承認してその内容で割り勘に同意する操作が入出力部２３に入力されたことに基づいて、割り勘精算承認通知を、メッセージングサーバ４０を介してサーバ１０に送信する（図１７−１３のＡ５３６０に相当）。

これにより、サーバ１０の制御部１１は、ユーザＡ．Ａによって割り勘が同意されたと判定し、割り勘精算処理を実行する（図２−１９のＳ３３０に相当）。そして、制御部１１は、割り勘精算結果を、メッセージングサーバ４０を介して端末Ａおよび端末Ｂに送信する（図２−１９のＳ３４０に相当）。

端末Ａの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図２−１９のＡ３４０、Ａ３５０に相当）。
同様に、端末Ｂの制御部２１は、メッセージングサーバ４０から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる（図２−１９のＢ３４０、Ｂ３５０に相当）。

なお、上記では、メッセージングアプリケーションを利用して、端末２０が、自己の端末２０のユーザによる買い物決済履歴を修正し、その修正に基づいて、精算金額を事後的に調整することとしたが、メッセージングアプリケーションは必須ではなく、メッセージングアプリケーションおよびメッセージングサーバ４０を構成要件から除外してもよい。

＜第２２実施例の効果＞
第２２実施例は、端末２０が、自己の端末２０のユーザと、異なる端末２０のユーザとを含むトークルーム（限定ではなく、チャットルームの一例）を表示部２４に表示する。そして、端末２０は、異なる端末２０のユーザによる買い物決済履歴（限定ではなく、第２決済情報の一例）の修正提案（限定ではなく、修正提案の一例）をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、第２決済情報の修正依頼をチャットルームへの表示という分かり易い形で異なる端末のユーザに報知することができる。

また、第２２実施例は、買い物決済履歴の修正提案は、異なる端末２０から自己の端末２０に送信される。そして、修正買い物決済履歴に基づく割り勘精算要求処理は、修正提案に対するユーザの操作に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、異なる端末から送信される修正依頼に対する端末のユーザによる入力に基づいて、第２送金処理、または第２受取処理を行って、精算した金額を事後的に調整することができる。

１（１Ａ、１Ｂ） 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
４０ メッセージングサーバ

Claims (24)

1. 決済に関する処理を実行する端末に実行させるためのプログラムであって、
   前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済に関する第１決済情報を前記端末の通信部によって送信することと、
   前記第１決済情報と、前記端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、前記端末のユーザが送金、または受け取る第１金額と、前記異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
   前記第１金額に基づく送金処理、または受取処理を前記端末の制御部によって行うこととが前記端末によって実行される。
2. 決済に関する処理を実行する端末に実行させるためのプログラムであって、
   前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済の決済履歴である第１決済情報を前記端末の通信部によって送信することと、
   前記第１決済情報に基づく、前記端末のユーザが送金、または受け取る第１金額と、前記端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
   前記第１金額に基づく送金処理、または受取処理を前記端末の制御部によって行うこととが前記端末によって実行される。
3. 請求項１または請求項２に記載のプログラムであって、
   少なくとも前記第１金額の情報と前記第２金額の情報とを含む金額情報を前記通信部によって受信することと、
   前記金額情報を前記端末の表示領域に表示することとが前記端末によって実行される。
4. 請求項１から請求項３のいずれか一項に記載のプログラムであって、
   前記送金処理、または前記受取処理は、前記異なる端末のユーザへの送金、または前記異なる端末のユーザからの金額の受け取りを含む処理である。
5. 請求項１から請求項４のいずれか一項に記載のプログラムであって、
   前記第１金額と前記第２金額とは、前記第１決済に関する決済処理を実行するサーバによって決定される。
6. 請求項５に記載のプログラムであって、
   前記サーバは、前記端末と、前記異なる端末を含む複数の端末とのうち、各々が送金、または受け取る金額を決定する。
7. 請求項１から請求項６のいずれか一項に記載のプログラムであって、
   前記第１決済情報は、前記端末のユーザによる前記第１決済の金額の情報を含む。
8. 請求項７に記載のプログラムであって、
   前記第１決済情報は、前記第１決済で購入された商品、または前記第１決済で提供されたサービスに関する情報を含む。
9. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
   前記端末のユーザと、前記異なる端末のユーザとを含み、前記端末から前記異なる端末に送信されたコンテンツと、前記異なる端末から前記端末に送信されたコンテンツとを含むチャットルームを前記端末の表示領域に表示することが前記端末によって実行され、
   前記第１金額の情報は、前記チャットルームに表示される。
10. 請求項９に記載のプログラムであって、
    前記異なる端末のユーザは、前記端末のユーザによって選択された前記チャットルームに基づいて選択される。
11. 請求項１０に記載のプログラムであって、
    前記チャットルームは、前記異なる端末のユーザを含む複数のユーザを含み、
    前記第１金額の情報と、前記複数のユーザの各々が送金、または受け取る金額の情報とを含む金額情報を前記チャットルームに表示することが前記端末によって実行される。
12. 請求項１１に記載のプログラムであって、
    前記チャットルームに含まれる、前記異なる端末のユーザを含む複数のユーザから、少なくとも一人のユーザを削除する処理を前記制御部によって行うことが前記端末によって実行される。
13. 請求項９から請求項１２のいずれか一項に記載のプログラムであって、
    前記チャットルームに含まれないユーザを追加する処理を前記制御部によって行うことと、
    前記チャットルームに含まれない追加されたユーザが送金、または受け取る第３金額の情報と、前記第１金額の情報と、前記第２金額の情報とを含む金額情報を前記通信部によって受信することと、
    前記金額情報を前記チャットルームに表示することとが前記端末によって実行される。
14. 請求項１３に記載のプログラムであって、
    前記第１金額と、前記第２金額と、前記第３金額とは、前記チャットルームに含まれない追加されたユーザによる第３決済に関する第３決済情報に基づいて決定される。
15. 請求項３に記載のプログラムであって、
    前記異なる端末のユーザは、第１端末のユーザであり、
    前記金額情報は、前記第１端末とは異なる第２端末のユーザを追加する処理が前記第１端末によって実行された場合、前記第２端末のユーザが送金、または受け取る第４金額の情報を含む。
16. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記端末のユーザと、前記異なる端末のユーザとを含み、前記端末から前記異なる端末に送信されたコンテンツと、前記異なる端末から前記端末に送信されたコンテンツとを含むチャットルームを前記端末の表示領域に表示することと、
    少なくとも前記端末と前記異なる端末との送金処理、または受取処理のリクエストに関する通知を前記チャットルームに表示することとが前記端末によって実行される。
17. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記端末のユーザを少なくとも含み、前記端末から送信されたコンテンツを含むチャットルームを前記端末の表示領域に表示することと、
    前記第１決済情報の送信に関する通知を前記チャットルームに表示することとが前記端末によって実行される。
18. 請求項１７に記載のプログラムであって、
    前記チャットルームは、前記端末のユーザと、前記送金処理、または前記受取処理に関するサービスを提供する企業のアカウントとを含む。
19. 決済に関する処理を実行する端末の情報処理方法であって、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済に関する第１決済情報を前記端末の通信部によって送信することと、
    前記第１決済情報と、前記端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、前記端末のユーザが送金、または受け取る第１金額と、前記異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
    前記第１金額に基づく送金処理、または受取処理を前記端末の制御部によって行うこととを含む。
20. 決済に関する処理を実行する端末の情報処理方法であって、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済の決済履歴である第１決済情報を前記端末の通信部によって送信することと、
    前記第１決済情報に基づく、前記端末のユーザが送金、または受け取る第１金額と、前記端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
    前記第１金額に基づく送金処理、または受取処理を前記端末の制御部によって行うこととを含む。
21. 決済に関する処理を実行する端末であって、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済に関する第１決済情報を送信し、前記第１決済情報と、前記端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、前記端末のユーザが送金、または受け取る第１金額と、前記異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を受信する通信部と、
    前記第１金額に基づく送金処理、または受取処理を行う制御部とを備える。
22. 決済に関する処理を実行する端末であって、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済の決済履歴である第１決済情報を送信し、前記第１決済情報に基づく、前記端末のユーザが送金、または受け取る第１金額と、前記端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を受信する通信部と、
    前記第１金額に基づく送金処理、または受取処理を行う制御部とを備える。
23. 決済に関する処理を実行する端末であって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
    前記プロセッサは、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済に関する第１決済情報を前記端末の通信部によって送信することと、
    前記第１決済情報と、前記端末とは異なる端末のユーザによる第２決済に関する第２決済情報とに基づく、前記端末のユーザが送金、または受け取る第１金額と、前記異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
    前記第１金額に基づく送金処理、または受取処理とを実行する。
24. 決済に関する処理を実行する端末であって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
    前記プロセッサは、
    前記端末のユーザによる前記端末に対する入力に基づいて、前記端末のユーザによる第１決済の決済履歴である第１決済情報を前記端末の通信部によって送信することと、
    前記第１決済情報に基づく、前記端末のユーザが送金、または受け取る第１金額と、前記端末とは異なる端末のユーザが送金、または受け取る第２金額とのうち、少なくとも前記第１金額の情報を前記通信部によって受信することと、
    前記第１金額に基づく送金処理、または受取処理とを実行する。

Images