JP6977127B1

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

Info

Publication number: JP6977127B1
Application number: JP2020163972A
Authority: JP
Inventors: 泰東金; 世栄千
Original assignee: Line Corp
Current assignee: Line Corp
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2021-12-08
Anticipated expiration: 2040-09-29
Also published as: JP2022056137A

Abstract

【課題】複数のアカウントに基づく決済を可能とする。【解決手段】第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末に実行させるためのプログラムは、第２アカウントに設定された第２金額に基づく第２アカウントの残高を端末の表示部に表示することと、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を端末の制御部によって行うこととが端末によって実行される。【選択図】図１−１

Description

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

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

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

本発明の第１の態様によると、第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末に実行させるためのプログラムは、第２アカウントに設定された第２金額に基づく第２アカウントの残高を端末の表示部に表示することと、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を端末の制御部によって行うこととが端末によって実行される。
本発明の第２の態様によると、第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末の情報処理方法は、第２アカウントに設定された第２金額に基づく第２アカウントの残高を端末の表示部に表示することと、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を端末の制御部によって行うこととを含む。
本発明の第３の態様によると、第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末は、第２アカウントに設定された第２金額に基づく第２アカウントの残高を表示する表示部と、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を行う制御部とを備える。
本発明の第４の態様によると、第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末は、メモリからプログラムを読み出し、プログラムに基づく処理を実行するプロセッサーを備え、プロセッサーは、第２アカウントに設定された第２金額に基づく第２アカウントの残高を端末の表示部に表示することと、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を行うこととを実行する。
本発明の第５の態様によると、第１ユーザの第１アカウントと、第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行うサーバは、第２アカウントに設定された第２金額に基づく第２アカウントの残高に関する情報を第１ユーザの端末に送信する通信部と、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１アカウントによる第１決済に関する処理を行う制御部とを備える。

第１実施例に係る通信システムのシステム構成の一例を示す図。第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。第１実施例に係るアカウント登録データの一例を示す図。第１実施例に係るアカウント管理データベースのデータ構成例を示す図。第１実施例に係る連携ウォレット管理データベースの一例である第１の連携ウォレット管理データベースのデータ構成例を示す図。第１実施例に係る端末の制御部によって実現される機能の一例を示す図。第１実施例に係る端末の記憶部に記憶される情報の一例を示す図。第１実施例に係る端末の表示部に表示される画面の一例を示す図。第１実施例に係る端末の表示部に表示される画面の一例を示す図。第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１変形例に係る端末の表示部に表示される画面の一例を示す図。第１変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２実施例に係る端末の表示部に表示される画面の一例を示す図。第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３実施例に係る端末の表示部に表示される画面の一例を示す図。第３実施例に係る端末の表示部に表示される画面の一例を示す図。第３実施例に係る端末の表示部に表示される画面の一例を示す図。第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３変形例に係る端末の表示部に表示される画面の一例を示す図。第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第３変形例に係る端末の表示部に表示される画面の一例を示す図。第３変形例に係る端末の表示部に表示される画面の一例を示す図。第３変形例に係る端末の表示部に表示される画面の一例を示す図。第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第４実施例に係るサーバの記憶部に記憶される情報の一例を示す図。第４実施例に係るグループ管理データベースのデータ構成例を示す図。第４実施例に係る連携ウォレット管理データベースの一例である第２の連携ウォレット管理データベースのデータ構成例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４実施例に係る端末の表示部に表示される画面の一例を示す図。第４変形例に係る端末の表示部に表示される画面の一例を示す図。第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第５実施例に係る端末の表示部に表示される画面の一例を示す図。第５実施例に係る端末の表示部に表示される画面の一例を示す図。第５実施例に係る端末の表示部に表示される画面の一例を示す図。第６実施例に係る通信システムのシステム構成の一例を示す図。第６実施例に係る店舗ＰＯＳシステムの機能構成の一例を示す図。第６実施例に係る端末の表示部に表示される画面の一例を示す図。第６実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第７実施例に係る連携ウォレット管理データベースの一例である第３の連携ウォレット管理データベースのデータ構成例を示す図。第７実施例に係る端末の表示部に表示される画面の一例を示す図。第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第７実施例に係る連携ウォレット精算処理の流れの一例を示すフローチャート。第８実施例に係るサーバの記憶部に記憶される情報の一例を示す図。第８実施例に係る共通ウォレット管理データベースのデータ構成例を示す図。第８実施例に係る連携ウォレット管理データベースの一例である第４の連携ウォレット管理データベースのデータ構成例を示す図。第９実施例に係る連携メンバーの負担割合に関する表の一例を示す図。第１０実施例に係る連携ウォレット管理データベースの一例である第５の連携ウォレット管理データベースのデータ構成例を示す図。第１０実施例に係る端末の表示部に表示される画面の一例を示す図。第１０実施例に係る端末の表示部に表示される画面の一例を示す図。第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１実施例に係る端末の表示部に表示される画面の一例を示す図。第１１変形例に係る端末の表示部に表示される画面の一例を示す図。第１２実施例に係る連携ウォレット管理データベースの一例である第６の連携ウォレット管理データベースのデータ構成例を示す図。第１２実施例に係る端末の表示部に表示される画面の一例を示す図。第１２実施例に係る端末の表示部に表示される画面の一例を示す図。第１２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１３実施例に係る連携ウォレット管理データベースの一例である第７の連携ウォレット管理データベースのデータ構成例を示す図。第１３実施例に係る端末の表示部に表示される画面の一例を示す図。第１３実施例に係る端末の表示部に表示される画面の一例を示す図。第１３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４実施例に係る連携ウォレット管理データベースの一例である第８の連携ウォレット管理データベースのデータ構成例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る端末の表示部に表示される画面の一例を示す図。第１４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１４変形例に係る端末の表示部に表示される画面の一例を示す図。第１４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１５実施例に係る連携ウォレット管理データベースの一例である第９の連携ウォレット管理データベースのデータ構成例を示す図。第１５実施例に係る端末の表示部に表示される画面の一例を示す図。第１５実施例に係る端末の表示部に表示される画面の一例を示す図。第１５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１６実施例に係る端末の表示部に表示される画面の一例を示す図。第１７実施例に係るアカウント管理データベースの一例を示す図。第１７実施例に係る連携ウォレット管理データベースの一例を示す図。第１７実施例に係る端末の表示部に表示される画面の一例を示す図。第１７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１７変形例に係る端末の表示部に表示される画面の一例を示す図。第１８実施例に係る連携ウォレット管理データベースの一例を示す図。第１８実施例に係る端末の表示部に表示される画面の一例を示す図。第１８実施例に係る端末の表示部に表示される画面の一例を示す図。第１８実施例に係る端末の表示部に表示される画面の一例を示す図。第１８実施例に係る端末の表示部に表示される画面の一例を示す図。第１８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１８実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第１８実施例に係るタイミングチャートの一例を示す図。第１８変形例に係る端末の表示部に表示される画面の一例を示す図。第１９実施例に係る端末の表示部に表示される画面の一例を示す図。第１９実施例に係る端末の表示部に表示される画面の一例を示す図。第１９実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２０実施例に係る端末の表示部に表示される画面の一例を示す図。第２０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２０実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。第２０実施例に係るタイミングチャートの一例を示す図。第２０変形例に係る端末の表示部に表示される画面の一例を示す図。

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

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

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

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

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

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

また、本明細書において、「決済」とは電子的な決済（電子決済）のことを意味する。この一例は、電子貨幣を利用した電子決済である。

また、本明細書において、「コード情報」とは、コード画像や、エンコード等によってコード画像に格納されている情報（格納情報）、または格納される対象となる情報（格納対象情報）を含むものである。格納情報や格納対象情報には、限定ではなく例として、詳細後述するトークンが含まれる。

また、本明細書では、コード（コード情報）を利用した支払い方法・決済方法であるコード決済として、限定ではなく例として、
（１）利用者提示型
（２）店舗提示型
の２種類を例示する。

利用者提示型とは、限定ではなく例として、端末の表示部に表示される支払いコードを利用者（端末のユーザ）が店舗（限定ではなく例として加盟店）の店員等に提示し、店舗コードリーダ装置のコードリーダで読み取ってもらうことで決済を行う方法である。
店舗提示型とは、限定ではなく例として、店舗（限定ではなく例として加盟店）で提示または掲示される支払い店舗コードを利用者が端末のカメラやコードリーダ（支払いアプリケーションのコードリーダを含む。）で読み取って決済を行う方法である。

なお、以下では、利用者提示型で端末の表示部に表示されるコードを「支払いコード」と称するが、これに代えて「利用者提示型コード」等のように称してもよい。
また、以下では、店舗提示型で端末が読み取るコードを「支払い店舗コード」と称するが、これに代えて「店舗提示型コード」等のように称してもよい。

本明細書では、限定ではなく例として、主に店舗提示型について説明する。
しかし、利用者提示型についても本発明を同様に適用可能であり、利用者提示型の実施例についても後述する。

また、本明細書では、アカウントに基づく決済として、限定ではなく例として、
（Ａ）アカウント連携決済
（Ｂ）共通アカウント決済
の２種類を例示する。

「アカウント」とは、限定ではなく例として、電子貨幣による支払い・決済等を行うためにユーザにより利用されるアプリケーション（支払いアプリケーション・決済アプリケーション、メッセージングアプリケーション等）のアカウントである。

（Ａ）アカウント連携決済
アカウント連携決済は、複数のアカウントを連携させて決済を行う手法である。アカウントの連携とは、複数のアカウントが決済に用いられるように関連付けることである。
この関連付けは、データ上（端末やサーバで管理されるデータ上）で、アカウント連携決済を行うことができるように複数のアカウントが関連付けられたものであればよい。

アカウントを連携させることを「アカウント連携」と称し、アカウント連携を利用した決済を「アカウント連携決済」と称する。
この場合、１人のユーザの複数のアカウントを連携させてもよいし、複数のユーザのアカウントを連携させてもよい。つまり、必ずしも他人のアカウントが連携に必須なわけではなく、限定ではなく例として、自分の複数のアカウントを連携させることも可能である。

アカウント連携決済を実現するために、限定ではなく例として、複数のアカウントを関連付けた上で、限定ではなく例として、関連付けられた各々のアカウントから均等割り（割り勘とも言える。）で決済が行われるように設定する処理（アカウント連携処理）を実行する。
アカウント連携決済は、ユーザが、自分のアカウントの他、異なるアカウント（自分の別のアカウントまたは他人のアカウント）を用いる決済と捉えることもできる。
なお、アカウント連携は、ウォレット連携と表現してもよい。また、アカウント連携決済は、ウォレット連携決済と表現してもよい。

以下では、あくまでも一例であるが、友達同士や仲間同士など、複数のユーザがみんなで買い物などの支払いの決済を行う場合を想定した実施例について説明する。

アカウント連携は、限定ではなく例として、（Ａ−１）支払いを行う前、（Ａ−２）支払いを行う際のいずれかに行うようにすることができる。
（Ａ−１）支払いを行う前は、限定ではなく例として、事後的な精算が面倒な場合に適用することができる。
（Ａ−２）支払いを行う際は、限定ではなく例として、支払いの際に決済を行うアカウントして設定されているアカウント（限定ではなく例として自分のアカウント）の残高が不足している場合に適用することができる。この場合、限定ではなく例として、他のユーザのアカウントとアカウント連携して決済を行うようにすることができる。

（Ｂ）共通アカウント決済
共通アカウント決済は、複数のユーザが共通に使用可能なアカウント（以下、「共通アカウント」と称する。）に基づいて決済を行う手法である。この決済を「共通アカウント決済」と称する。共通アカウント決済は、共通ウォレットを利用することによって実現される。「共通ウォレット」は、複数のユーザによって設定される電子マネー口座の一形態であり、仮想的な１つのウォレットが構成されるものである。
共通アカウント決済は、ユーザが、複数のユーザに共通のアカウント（１つの共通のアカウント）を用いる決済と捉えることもできる。
なお、共通アカウント決済は、共通ウォレット決済と表現してもよい。

共通アカウント決済は、限定ではなく例として、複数のユーザで共通に使用することを想定した１つのアカウントから決済を行うものである。

第１の形態として、共通アカウントは、共通ウォレットを利用するユーザ（メンバー）の各々に紐づけられたアカウントとすることができる。
第２の形態として、共通アカウントは、共通ウォレットを利用するユーザのうち特定のユーザに紐づけられたアカウントとすることができる。特定のユーザは、限定ではなく例として、共通ウォレットの代表者やマスターとなるユーザ（以下、包括的に「共通アカウントマスターユーザ」と称する。）とすることができる。共通アカウントマスターユーザは、限定ではなく例として、共通アカウントを作成したユーザ等とすることができる。

第１の形態と第２の形態とのいずれの形態を適用する場合であっても、限定ではなく例として、各々の共通アカウントのユーザは、共通ウォレットを自由に利用できるようにすることができる。限定ではなく例として、共通ウォレットの残高等の情報を確認したり、共通ウォレットへの入金／共通ウォレットからの出金等を自由に行うことができるようにすることができる。

なお、第２の形態を適用する場合、限定ではなく例として、共通アカウントマスターユーザ以外のユーザによる共通ウォレットの利用を制限するようにすることもできる。
具体的には、共通ウォレットの機能のうちの一部または全部の機能を利用できないようにしたり、共通ウォレットの機能のうちの一部または全部の機能を利用する場合に共通アカウントマスターユーザの承認を必要としてもよいし、そのようにしなくてもよい。

共通アカウント決済では、複数のユーザに共通のアカウントを用いるため、一のユーザが他のユーザの支払い分を立て替えて決済を行ったような場合に、事後的な精算（清算）の処理が必要となる場合がある。つまり、決済が完了した後の何らかのタイミングで、送金処理／受金処理等の各々のユーザの金額を調整する処理が必要となる場合がある。

それに対し、アカウント連携決済では、連携するアカウントのユーザの許可を得ておく、またはその場で許可を得た上で、各々のアカウントから金額が消費されるようにすることで、事後的な精算の処理は基本的に不要となる。
ただし、アカウント連携決済でも事後的な精算を行う場合があり、これについては実施例で後述する。

以上を踏まえた上で、本明細書では、限定ではなく例として、（Ａ）「アカウント連携決済」を適用する場合の実施例をメインに説明する。

なお、「連携」は、１つの目的のために一緒に物事を行うという意味を含む。このため、複数のユーザが一緒に決済を行うという意味において、限定ではなく例として、アカウント連携決済も共通アカウント決済も、目的は同じであるとも捉えることもできる。

また、以下では、端末にインストールされたアプリケーション（支払いアプリケーションやメッセージングアプリケーション）によって、本発明に係る各種の処理が実行されることとして説明する。

なお、支払いアプリケーションの一機能としてチャットサービス（限定ではなく例として、メッセージングサービス）の機能を持たせる、またはチャットアプリケーション（限定ではなく例として、メッセージングアプリケーション）の一機能として支払いサービスの機能を持たせるようにすることもできる。

メッセージングサービスでは、ユーザが、チャットルームを利用してチャットを行うことができるように構成されている。
以下の説明では、適宜、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるＵＩ（User Interface）やＧＵＩ（Graphical User Interface）を「トークルーム」と称する。また、トークルームをチャットルームと称してもよい。

コンテンツには、単純なテキストや絵文字等を含むメッセージの他、限定ではなく例として、画像情報（静止画像、動画像等の情報を含む。）、操作用情報（ボタン、アイコン等を含む。）、通信用情報・リンク情報（ＵＲＩ、ＵＲＬ等を含む。）など、端末間で送受信可能な各種の情報を含めることができる。

なお、トークルームには、限定ではなく例として、一対一のユーザのトークルームの他、複数のユーザを含むグループのトークルーム（グループトークルーム）を含めることができる。この場合におけるトークルームは、複数のユーザを含むグループの各端末間で送受信されるコンテンツをグループに含まれるユーザが閲覧できるＵＩやＧＵＩのことを意味する。

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

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

また、以下では、端末に対する入力として、主として端末のユーザによる操作入力（限定ではなく例として、タップ（タップ操作）による入力）を例示するが、これに限定されない。
操作入力に代えて、または操作入力に加えて、音入力（音声入力を含む。）を端末に対する入力としてもよいし、しなくてもよい。

本明細書において、端末が行う「決済に関する処理」とは、決済に直接的または間接的に関連する処理、限定ではなく例として、上記の（Ａ）アカウント連携決済や（Ｂ）共通アカウント決済に直接的または間接的に関連する処理を意味する。
具体的には、限定ではなく例として、決済を行うためのコード情報をサーバから取得する処理（コード情報の生成をサーバに依頼する処理や、生成されたコード情報をサーバから受信する処理を含む。）、取得したコード情報を表示する処理、決済するようにサーバに依頼する処理、決済結果（決済完了通知等を含む。）をサーバから取得する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理として端末で実行される処理全般を含むものである。

また、本明細書において、サーバが行う「決済に関する処理」も、決済に直接的または間接的に関連する処理、限定ではなく例として、上記の（Ａ）アカウント連携決済や（Ｂ）共通アカウント決済に直接的または間接的に関連する処理を意味する。
具体的には、限定ではなく例として、決済を行うためのコード情報を生成する処理、生成したコード情報を端末に送信する処理、決済処理（決済する処理）、決済結果（決済完了通知等を含む。）を端末に送信する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理としてサーバで実行される処理全般を含むものである。

なお、「関する」と記載された他の用語についても同様である。つまり、「関する」とは、直接的または間接的に関連のあるものを含む概念である。

以下では、少なくとも端末とサーバとを含むシステム（限定ではなく例として、通信システム１Ａ、通信システム１Ｂ）を例示する。
ただし、システムは、以下説明するシステムに限定されるわけではない。限定ではなく例として、以下のいずれかのパターンのシステムを構成することができる。
（１）端末＆サーバ
（２）サーバ
（３）端末

（１）は、限定ではなく例として、少なくとも１つの端末と、少なくとも１つのサーバとを含むシステムである。この典型例は、サーバクライアントシステムである。
この場合、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、（１Ａ）端末の制御部のみ、（１Ｂ）サーバの制御部のみ、（１Ｃ）端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。

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

（２）は、限定ではなく例として、複数のサーバによって構成されるシステムとすることができる。複数のサーバによって構成されるシステムであるため「サーバシステム」と称してもよい。

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

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

＜第１実施例＞
第１実施例は、前述した（Ａ）アカウント連携決済を実現するための基本的な実施例である。
アカウント連携決済を行う場合、アカウント連携決済に参加するアカウントの一部または全部のアカウントに、金額を負担させることが考えられる。
しかし、この場合、限定ではなく例として、連携されたアカウントのうちのいずれかのアカウントの残高が不足するなどして、アカウント連携決済を行うことができない場合があり得る。

以下では、アカウント連携決済を実現するためのデータであって、サーバ１０で管理されるデータとして「連携ウォレット」という概念を導入する。端末２０のユーザ（ユーザアカウント）によって連携ウォレットを作成（生成）する要求がなされ、連携ウォレットのデータがサーバ１０によって生成されることで、アカウント連携決済を行うことが可能となる。
また、アカウント連携決済を実現するために、複数のアカウントを連携させることを「アカウント連携」や「ウォレット連携」と称する。

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

まず、アカウント連携の一例として、一のユーザの複数のアカウントを連携する場合について説明する。本実施例では、限定ではなく例として、ユーザＡ．Ａの２つのアカウントを連携する場合を説明する。
また、一例として、サーバ１０がアカウント連携処理を実行する場合について説明する。

なお、詳細は後述するが、複数のユーザのアカウントを連携することも可能である。
また、詳細は後述するが、アカウント連携処理を端末２０が実行するようにすることも可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、電子マネー口座残高とが記憶される。
電子マネー口座残高は、そのアプリケーションＩＤ（そのアカウント）の電子マネー口座の残高であって、限定ではなく例として、サーバ１０によって記憶・管理される残高である。単に「残高」と称する場合もある。

連携ウォレット管理データベース１５７は、前述した連携ウォレットを管理するためのデータベースであり、その一例である第１の連携ウォレット管理データベース１５７Ａのデータ構成例を図１−６に示す。
第１の連携ウォレット管理データベース１５７Ａには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、連携ウォレットＩＤと、連携アカウントデータと、決済履歴データとが記憶される。

連携ウォレットＩＤは、限定ではなく例として、アカウント連携決済で用いられる連携ウォレットを識別するための情報である。

連携ウォレットＩＤは、好ましくは連携ウォレットごとに一意な値であり、限定ではなく例として、サーバ１０によって連携ウォレットごとに一意な値（固有の値）が設定されて記憶される。

連携アカウントデータは、アカウント連携決済を行うために連携するユーザアカウント（以下、「連携アカウント」と称する。）に関するデータであり、限定ではなく例として、この連携アカウントに対応するアプリケーションＩＤと、このアプリケーションＩＤに対応するユーザ名とが関連付けて記憶される。

以下では、アカウント連携決済に参加するユーザを「連携メンバー」と称する一方、上記のように、アカウント連携決済を行うために連携するユーザアカウントのことを「連携アカウント」と称する。

なお、一人のユーザが複数のユーザアカウントを所有しており、この一人のユーザが自身の複数のユーザアカウントを連携させることも可能である。このため、連携メンバーと連携アカウントとは、必ずしも一対一の対応関係であるとは限らない。

図１−６の例では、最も手前に示す連携ウォレット管理データでは、連携アカウントデータに、「Ｕ０００１」、「Ｕ０００５」の２つのアプリケーションＩＤが記憶されているが、これらのアプリケーションＩＤに対応するユーザ名は「Ａ．Ａ」である。つまり、この例では、ユーザＡ．Ａが所有する２つのアカウントが、連携アカウントとして関連付けられている。

決済履歴データは、アカウント連携決済による決済（支払い）の履歴のデータであり、限定ではなく例として、取引ＩＤと、店舗ＩＤと、店舗名と、支払い日時と、支払い金額とが関連付けて、時系列に記憶される。

取引ＩＤは、その決済が行われた取引を識別するための識別情報としてのＩＤである。
この取引ＩＤは、好ましくは取引ごとに一意な値であり、限定ではなく例として、サーバ１０によって取引ごとに一意な値（固有の値）が設定されて記憶される。

店舗ＩＤは、その取引が行われた店舗を識別するための識別情報としてのＩＤである。
この店舗ＩＤは、好ましくは店舗ごとに一意な値であり、限定ではなく例として、サーバ１０によって加盟店ごとに一意な値（固有の値）が設定されて記憶される。

店舗名には、その取引が行われた店舗の名称が記憶される。なお、店舗名の情報は、不図示のデータによってサーバ１０により店舗ＩＤと関連付けて記憶・管理されるようにすることができる。

支払い日時には、限定ではなく例として、その取引についてサーバ１０が決済処理を行った日時が、支払い日時として記憶される。

支払い金額には、限定ではなく例として、その取引についてサーバ１０が決済した金額が記憶される。この支払い金額は、サーバ１０によって決済された金額（決済済みの金額）を意味する。

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

図１−８は、本実施例において端末２０の記憶部２８に記憶される情報等の一例を示す図である。
記憶部２８には、限定ではなく例として、支払いアプリケーション処理として実行される支払いアプリケーション処理プログラム２８１と、自己の端末２０、または自己の端末２０のユーザのアプリケーションＩＤ２８３とが記憶される。
なお、アプリケーションＩＤ２８３は、複数のアプリケーションＩＤを記憶できるようにしてもよいし、そうしなくてもよい。

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

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

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

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

図１−９，図１−１０は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図１−９左側は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面である。

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

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

メインメニュー画面の下部に表示された連携ウォレットの文字および画像を含む連携ウォレットアイコンＩＣ１がタップされると、限定ではなく例として、ユーザＡ．Ａの複数のユーザアカウントを連携させたアカウントについての連携ウォレット情報が表示される。

図１−９中央に、連携ウォレット情報の表示画面の一例を示す。
この画面では、現在位置表示領域ＣＬＲ１には、連携ウォレットの機能を利用中であることを示す「連携ウォレット」の文字が表示されている。また、現在位置表示領域ＣＬＲ１の下に、連携ウォレットを用いて「店舗提示型」のコード支払いを行うための「コードリーダ」の文字で示されるコードリーダアイコンＩＣ２と、「利用者提示型」のコード支払いを行うための「コード支払い」の文字で示されるコード支払いアイコンＩＣ３とが横に並んで表示されている。

これらのアイコンの下には、連携ウォレットの対象となるユーザ名を含む「Ａ．Ａの連携ウォレット」が表示され、さらにその下には、この連携ウォレットの連携アカウントの状況を表示するための連携メンバー情報表示領域ＭＩＲ１が表示されている。

連携メンバー情報表示領域ＭＩＲ１には、各連携アカウントと、連携状況とが行ごとに関連付けて表示されている。限定ではなく例として、「Ａ．Ａメインアカウント」は、ユーザＡ．Ａのメインのユーザアカウント（以下、適宜「メインアカウント」と称する。）である。メインアカウントは、限定ではなく例として、図１−９左側のメインメニュー画面で連携ウォレット以外の操作を行った場合に用いられるユーザアカウントである。この例では、メインアカウントの電子マネー口座残高は「５，０００円」であることが示されている。

また、限定ではなく例として、「Ａ．Ａサブアカウント」は、ユーザＡ．Ａのサブのユーザアカウント（以下、適宜「サブアカウント」と称する。）である。サブアカウントは、ユーザＡ．Ａが所有するメインアカウント以外のユーザアカウントである。この例では、サブアカウントの電子マネー口座残高は「３，０００円」であることが示されている。

限定ではなく例として、この画面において、コードリーダアイコンＩＣ２がタップ（タッチ）されると、サーバ１０から端末２０Ａへ、この連携ウォレットを用いて支払いを行うための連携ウォレットコードリーダ情報が送信される。すると、端末２０Ａの制御部２１は、端末２０Ａで店舗に提示された端末読み取り用コードを読み取るために、コード支払いアプリケーションの機能として備えられたコードリーダ（以下、「アプリケーションコードリーダ」と称す。）を起動する。

図１−９右側に、アプリケーションコードリーダ画面の一例を示す。
この画面では、現在位置表示領域ＣＬＲ１の下に、現在実行中の機能である「コードリーダ」の文字が表示されている。また、画面中央には、支払い店舗コードを読み取るためのコード読み取り領域ＣＲ１が表示されている。

図１−１０左側は、図１−９右側において読み取られた支払い店舗コードからデコードによって情報が取得された場合に表示される支払い金額入力画面の一例を示す図である。

この支払い金額入力画面には、支払い金額の送金先である「ＸＸ楽器」のアイコン画像とともに、その名称「ＸＸ楽器」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域ＰＲ１が表示され、ここでは、支払い金額として「４，５００円」が入力されて表示されている。また、支払い金額表示領域ＰＲ１の左端には、支払い金額を消去するための丸で囲まれた×印で示される消去ボタンが表示されている。
画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額表示領域ＰＲ１に入力されている支払い金額で支払いを実行するための「支払い」の文字で示された支払いボタンＢＴ１が表示されている。

図１−１０左側に示される支払い金額入力画面において支払いを実行するための支払いボタンＢＴ１がタップされると、連携ウォレットを用いたコード支払いが実行される。

なお、図１−９中央の画面において、コード支払いアイコンＩＣ３がタップされると、端末２０Ａの表示部２４には、コード支払い画面が表示される。コード支払い画面には、サーバ１０から送信されて端末２０が受信したコード（コード画像）であって、「利用者提示型」で決済を行うために用いられるコードである連携ウォレット支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコードとが表示される。端末２０ＡのユーザＡ．Ａは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことで連携ウォレットを用いたコード支払いを行うことも可能である。

図１−１０中央には、連携ウォレットを用いた支払い結果を確認するための、連携支払い結果表示画面が表示されている。

連携支払い結果表示画面の上部には、連携ウォレットを用いた支払いが完了したことを示す「支払い完了」の文字とともに、支払い金額の送金先である「ＸＸ楽器」のアイコン画像と、その名称「ＸＸ楽器」と、支払い日時「２０２０−０７−２４／１２：１７：０８」とが表示されている。

また、連携支払い結果表示画面の下部には、この支払いに関する連携アカウントごとの内訳を表すメンバー支払い結果表示領域ＭＲＲ１が表示されている。
メンバー支払い結果表示領域ＭＲＲ１には、連携アカウントごとに、支払ったユーザアカウントと、それぞれのユーザアカウントで支払った金額と、支払い後の電子マネー口座残高とが表示されている。

限定ではなく例として、本実施例では、各々の連携アカウントが、総支払い金額を連携アカウントで等分した金額（割り勘した金額）を支払い金額として支払うこととする。

なお、これとは異なり、連携アカウントごとに支払い金額の割合を変えてもよいし、そのようにしなくてもよい。限定ではなく例として、「メインアカウント：サブアカウント」＝「２：１」等のようにしてもよいし、しなくてもよい。

図１−１０右側は、図１−１０中央の画面が表示された後、端末２０Ａの表示部２４に表示される画面の一例である。この画面では、連携支払い結果表示画面の下部から、メインアカウントからサブアカウントへの送金を促すための表示を行う送金促進通知領域ＲＥＲ１がせり上がり表示されている。これは、連携支払いを行った結果、メインメニュー画面で選択されていないサブアカウントでの支払いが生じているため、メインメニュー画面として選択されたメインアカウントからサブアカウントへの送金をユーザＡ．Ａに促すための通知を表示する領域である。

＜処理＞
以下では、店舗提示型のコード決済で用いられる「支払い店舗コード」を、限定ではなく例として、加盟店を識別するための加盟店識別情報（限定ではなく例として加盟店に固有に割り振られる店舗ＩＤ）を含むコード（一次元コードや二次元コード）として説明する。

なお、支払い店舗コードに、特定の決済予定金額（限定ではなく例として「５００円」）の情報を含ませてもよいし、そのようにしなくてもよい。

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

ここでは一例として、連携アカウントとして、ユーザＡ．Ａの第１ユーザアカウント（限定ではなく例として、アプリケーションＩＤが「Ｕ０００１」で示されるアカウント）と、ユーザＡ．Ａの第２ユーザアカウント（限定ではなく例として、アプリケーションＩＤが「Ｕ０００５」で示されるアカウント）とでアカウント連携決済を行う場合の処理について説明する。
なお、実際には、アカウント連携決済で連携するユーザアカウントは２つとは限らないが、３つ以上とする場合も同様であるため、ここでは図示・説明を省略する。

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

まず、サーバ１０の制御部１１は、限定ではなく例として、端末２０Ａのユーザ操作に基づいて予め指定された、連携ウォレットＩＤで識別される連携ウォレットに紐づけられた連携メンバーの各アカウント残高を利用した支払いを認可する支払いトークン（以下、「連携ウォレット支払いトークン」と称する。）を生成する。
連携ウォレット支払いトークンは、限定ではなく例として、所定の桁数（限定ではなく例として１２桁）の整数値によって識別される。
なお、連携ウォレット支払いトークンは、生成から所定の時間内（限定ではなく例として「５分」）に限り認可を行う、有効期限を持つトークンとしてもよいし、そうしなくてもよい。

すると、サーバ１０の制御部１１は、連携ウォレット支払いトークンを含むコード読み取り用情報である連携ウォレットコードリーダ情報を生成する。そして、サーバ１０の制御部１１は、生成した連携ウォレットコードリーダ情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１００）。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレットコードリーダ情報を受信すると、端末２０Ａの制御部２１は、受信された連携ウォレットコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示させる。また、端末２０Ａの制御部２１は、コードを読み取るために撮像部２７を起動させる。そして、端末２０Ａの制御部２１は、起動させた撮像部２７等を用いて支払い店舗コードを読み取るコード読み取り処理を実行する（Ａ１００）。

Ａ１００の処理で読み取った支払い店舗コードから店舗ＩＤが取得されると、端末２０Ａの制御部２１は、限定ではなく例として、決済予定金額を入力させるための表示画面を表示部２４に表示させる。端末２０Ａの入出力部２３に対するユーザ操作に基づいて決済予定金額が入力されると、制御部２１は、限定ではなく例として、連携ウォレットコードリーダ情報に含まれる連携ウォレット支払いトークンと、店舗ＩＤと、決済予定金額とを含む連携決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１１０）。

通信Ｉ／Ｆ１４によって端末２０Ａから連携決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた連携ウォレット支払いトークンから連携ウォレットＩＤを検索し、その連携ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う、店舗提示型のアカウント連携決済処理の一例である店舗提示型連携決済処理を実行する（Ｓ１１０）。

店舗提示型連携決済処理では、まず、サーバ１０の制御部１１は、限定ではなく例として、決済予定金額を連携アカウント数で割り勘（等分）した金額（以下、「等分支払い金額」と称する。）を算出する。そして、サーバ１０の制御部１１は、連携ウォレットデータの連携アカウントデータに記憶されている各連携アカウントに対して、等分支払い金額を支払い金額とした決済処理を行う。

全ての連携アカウントにおいて「電子マネー口座残高−等分支払い金額」の値が０以上となる場合、各連携アカウントに対して等分支払い金額の決済処理が実行され、店舗提示型連携決済処理は成功となる。
一方、いずれかのアカウントにおいて「電子マネー口座残高−等分支払い金額」の値がマイナスとなる場合、連携アカウントへの決済処理は行われず、店舗提示型連携決済処理は失敗となる。

なお、店舗提示型連携決済処理において、各連携アカウントから等分支払い金額の決済を実行するのではなく、一度、連携アカウントの所定のアカウント（限定ではなく例として、ユーザＡ．Ａの第１ユーザアカウント）に他のアカウントから等分支払い金額を送金し、その後、所定のアカウントから決済予定金額の決済を実行するようにしてもよいし、そのようにしなくてもよい。

店舗提示型連携決済処理が成功した場合、サーバ１０の制御部１１は、限定ではなく例として、第１ユーザアカウントから第２ユーザアカウントへの送金を促す送金依頼情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１２０）。

あくまでも一例であるが、限定ではなく例として、表示画面例で説明したように、ユーザＡ．Ａが、第１ユーザアカウントをメインアカウントとして使用しており、第２ユーザアカウントをサブアカウントとして使用しているような場合を想定することができる。
店舗提示型連携決済処理が成功した場合、ユーザＡ．Ａのサブアカウントの電子マネー口座残高からも等分支払い金額が差し引かれて残高が減少する。このような場合に、サーバ１０は、第１ユーザアカウント（メインアカウント）から第２ユーザアカウント（サブアカウント）に送金を行って第２ユーザアカウントの残高を補充するように、ユーザＡ．Ａに促すことができる。

なお、第１ユーザアカウントあるいは第２ユーザアカウント、もしくはその両方において等分支払い金額の決済が失敗する場合（すなわち、店舗提示型連携決済処理が失敗した場合）に、ユーザＡ．Ａによってあらかじめ登録される外部金融機関の口座から、決済が失敗したアカウントに対するチャージ（送金）を促す情報を送金依頼情報として送信するようにしてもよいし、そうしなくてもよい。
また、決済が失敗したアカウントに対して、限定ではなく例として、外部金融機関等からローンや借り入れを行うように促す情報を送金依頼情報として送信するようにしてもよいし、そうしなくてもよい。

サーバ１０の制御部１１は、送金依頼情報を送信すると、処理を終了させる。

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

＜第１実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、端末の第１ユーザの一例）の第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、第１ユーザアカウントと連携された第２ユーザアカウント（限定ではなく、第１アカウントと関連付けられた第２アカウントの一例）とに基づき、アカウント連携決済に関する処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う。
また、端末２０は、アカウント連携決済に基づいて、第１ユーザアカウントから第２ユーザアカウントへの送金依頼情報（限定ではなく、第２アカウントに送金することに関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。
そして、端末２０は、受信した送金依頼情報の表示（限定ではなく、第１情報に基づく第１表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第１ユーザの第１アカウントと、第１アカウントと関連付けられた第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも２つのアカウントによる第１決済を可能とすることができる。
また、第１決済により第２アカウントに送金することに関する第１情報を、端末の第１ユーザに知らせることができる。その結果、限定ではなく例として、第２アカウントに送金するように、第１ユーザに促すことができる。

なお、第２アカウントに送金することは、第２アカウントに送金することのみならず、複数のアカウント（第２アカウントを含む。）に送金することも含む概念である。よって、第２アカウントに送金することに関する第１情報は、複数のアカウントに送金することに関する情報も含む概念である。

また、この場合、限定ではなく例として、第１アカウントばかりでなく、第２アカウントも第１ユーザのアカウントとすることで、一人のユーザの複数のアカウントに基づいて決済を行うことができる。また、限定ではなく例として、第１ユーザの別のアカウント（第２アカウント）に送金するように、第１ユーザに促すことができる。

また、本実施例は、サーバ１０（限定ではなく、端末と通信する、決済に関する処理を行うサーバの一例）が、端末２０のユーザの第１ユーザアカウントと、第１ユーザアカウントと連携した第２ユーザアカウントとに基づき、店舗提示型のアカウント連携決済処理（限定ではなく、第１決済に関する処理の一例）を制御部１１によって実行する。また、サーバ１０は、このアカウント連携決済に基づいて、通信Ｉ／Ｆ１４によって送金依頼情報を端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第１ユーザの第１アカウントと、第１アカウントと関連付けられた第２アカウントとに基づき、サーバによって第１決済に関する処理をサーバの制御部によって行うことで、関連付けられた少なくとも２つのアカウントによる第１決済を行うことができる。
また、第１決済に基づいて、第２アカウントに送金することに関する第１情報を、端末の第１ユーザに知らせることができる。その結果、限定ではなく例として、第２アカウントに送金するように、第１ユーザに促すことができる。

＜第１変形例（１）＞
第１実施例では、送金依頼情報は、第１ユーザアカウントから第２ユーザアカウントへの送金を促す情報、あるいは第１ユーザアカウントあるいは第２ユーザアカウント、もしくはその両方へのチャージを促す情報、ローンや借り入れを行うように促す情報等であったがこれに限定されない。限定ではなく例として、送金依頼情報は、これらの具体的金額を含む情報であってもよい。

＜表示画面＞
図１−１２は、図１−１０の別例を示す画面図である。
図１−１２左側および図１−１２中央は、それぞれ図１−１０と同様である。

図１−１２右側において、送金促進通知領域ＲＥＲ２には、メインアカウントからサブアカウントへの送金をユーザＡ．Ａに促すための通知に加えて、メインアカウントからサブアカウントへ送金推奨額である「￥２，２５０」が表示されている。この金額は、連携支払い結果表示画面で表示されている支払いの際に、サブアカウントから支払いが行われた金額となっている。

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

Ｓ１２０の後、サーバ１０の制御部１１は、Ｓ１１０の店舗提示型連携決済処理が成功であった場合には、等分支払い金額を第１ユーザアカウントから第２ユーザアカウントへの送金またはチャージを推奨する金額（以下、包括的に「送金推奨額」と称する。）とし、その情報である送金推奨額情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１３０）。

なお、店舗提示型連携決済処理が失敗した場合には、等分支払い金額の決済が失敗する連携アカウントにおいて、「等分支払い金額−電子マネー口座残高」で求められる金額をそのアカウントへのチャージを推奨する金額として、通信Ｉ／Ｆ１４によって端末２０Ａに送信するようにしてもよいし、そのようにしなくてもよい。
そして、サーバ１０の制御部１１は、処理を終了させる。

端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金推奨額情報（送金額あるいはチャージ額の情報）を受信すると、受信した送金推奨額情報を表示部２４に表示させる（Ａ１３０）。そして、端末２０Ａの制御部２１は、処理を終了させる。

本変形例は、第１情報は、送金推奨額情報（限定ではなく、第２アカウントによって、第１決済で支払われた金額に基づく情報の一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、第２アカウントによって、第１決済で支払われた金額に基づく第１情報を、端末の第１ユーザに知らせることができる。限定ではなく例として、送金やチャージを推奨する金額を、端末の第１ユーザに知らせることができる。

＜第２実施例＞
第１実施例では、端末２０Ａは、送金依頼情報を表示部２４に表示すると、そのまま処理を終了した。
第２実施例は、これに加えて、送金依頼情報に基づいて、アカウント間での送金を実行する実施例である。

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

＜表示画面＞
図２−１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図２−１左側は、連携支払い結果表示画面に続いて送金促進通知領域ＲＥＲ３が表示された場合の表示画面の一例である。

送金促進通知領域ＲＥＲ３には、送金促進通知領域ＲＥＲ２の内容に加えて、下部に、送金促進通知領域の通知内容に基づいて、送金処理を実行させるための送金ボタンＢＴ２が表示されている。

限定ではなく例として、送金ボタンＢＴ２がタップされると、メインアカウントからサブアカウントへの送金画面が表示され、その送金金額の初期値として「２，２５０円」が設定される。

図２−１右側は、送金が実行された後に端末２０Ａの表示部２４に表示されるおしらせ画面の一例である。
送金ボタンＢＴ２がタップされたことに基づいて、支払いアプリケーションのおしらせ画面には、ユーザＡ．Ａのメインアカウントからサブアカウントへの送金を行ったことを示す情報が表示されている。

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

端末２０Ａの制御部２１は、Ａ１３０のステップを実行すると、限定ではなく例として、送金推奨額を第１ユーザアカウントから第２ユーザアカウントへ送金するか否かの選択用画面を表示部２４に表示させる（Ａ１４０）。

なお、送金推奨額ではなく、所定の金額あるいはユーザの入力に基づく金額を送金するか否かの選択用画面としてもよいし、そのようにしなくてもよい。この場合、Ｓ１３０とＡ１３０とのステップは省略してもよいし、そのようにしなくてもよい。

端末２０Ａの入出力部２３に対するユーザ操作に基づいて、送金することが選択される場合（Ａ１４０：ＹＥＳ）、端末２０Ａの制御部２１は、限定ではなく例として、送金推奨額を第１ユーザアカウントから第２ユーザアカウントへ送金するための送金命令情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する（Ａ１５０）。

一方、送金しないことが選択される場合（Ａ１４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ１４によって端末２０Ａから送金命令情報を受信すると（Ｓ１４０：ＹＥＳ）、サーバ１０の制御部１１は、送金命令情報に基づいて、限定ではなく例として、第１ユーザアカウントから第２ユーザアカウントへ送金推奨額を送金する送金処理を実行する（Ｓ１５０）。そして、サーバ１０の制御部１１は、送金処理の結果を送金結果情報として、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１６０）。その後、サーバ１０の制御部１１は、処理を終了させる。

なお、端末２０Ａから送金命令情報を受信しない場合（Ｓ１４０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

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

＜第２実施例の効果＞
本実施例は、端末２０が、表示部２４に表示した送金推奨額を第１ユーザアカウントから第２ユーザアカウントへ送金するか否かの選択用画面の表示（限定ではなく、第１表示の一例）に対する端末２０のユーザによる入力に基づいて、第１ユーザアカウントから第２ユーザアカウントに送金するための処理を実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、第１情報に基づく第１表示に対する第１ユーザによる入力という簡単な方法で、第１情報に基づく金額を、第１アカウントから第２アカウントに送金することができる。

また、本実施例は、サーバ１０（限定ではなく、端末と通信する、決済に関する処理を行うサーバの一例）が、端末２０のユーザの第１ユーザアカウントと、第１ユーザアカウントと連携した第２ユーザアカウントとに基づき、アカウント連携決済処理（限定ではなく、第１決済に関する処理の一例）を制御部１１によって実行する。また、サーバ１０は、このアカウント連携決済に基づいて、通信Ｉ／Ｆ１４によって送金依頼情報を端末２０に送信する。そして、サーバ１０は、端末２０に表示された、送金推奨額を第１ユーザアカウントから第２ユーザアカウントへ送金するか否かの選択用画面の表示に対する端末２０のユーザによる入力に基づいて、第１ユーザアカウントから第２ユーザアカウントへの送金処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、サーバが、端末に表示された、第１情報に基づく第１表示に対する第１ユーザによる入力に基づいて、第１情報に基づく金額を、第１アカウントから第２アカウントに送金することができる。

＜第３実施例＞
第１実施例、第２実施例では、連携アカウントを一人のユーザの異なるユーザアカウントとして説明したが、これに限定されない。
以下では、異なるユーザのユーザアカウントを連携する場合（連携アカウントを異なるユーザのアカウントとする場合）について説明する。

連携ウォレットを用いた支払いを行う場合、限定ではなく例として、連携されたいずれかのユーザアカウント（いずれかの連携アカウント）の電子マネー口座残高が少なく、等分支払い金額に満たないような場合、一時的に、連携された他のユーザアカウントに不足分を負担してもらい、支払いを実行する方法が考えられる。
この場合、負担額（立替金額）を支払い後に返却する必要が生じるが、限定ではなく例として、返却する処理を手動で実行する必要があり、利便性に欠ける。

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

本実地例では、第１の連携ウォレット管理データベース１５７Ａの連携アカウントデータには、アプリケーションＩＤとして、異なるユーザのアプリケーションＩＤが記憶される。

以下では、限定ではなく例として、連携アカウントデータに、ユーザＡ．Ａのユーザアカウント（限定ではなく例として、アプリケーションＩＤ「Ｕ０００１」）と、ユーザＢ．Ｂのユーザアカウント（限定ではなく例として、アプリケーションＩＤ「Ｕ０００２」）とが記憶されている場合を例示する。
すなわち、ユーザＡ．ＡとユーザＢ．Ｂとを連携メンバーとする場合を例示する。

また、本実施例では、コード決済を実行するユーザＡ．Ａのユーザアカウントの電子マネー口座残高が少なく、等分支払い金額に満たない場合を例示する。

＜表示画面＞
以下では、ユーザＡ．Ａのユーザアカウントと、ユーザＢ．Ｂのユーザアカウントとが連携アカウントとして連携されており、これらの連携アカウントを用いてアカウント連携決済を行う例について説明する。この例では、複数のユーザの各々の１つのユーザアカウントが連携されているため、連携メンバーと連携アカウントとは一対一の対応関係となる。

図３−１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図であり、端末２０Ａの表示部２４に表示される画面の一例を示している。
図３−１左側は、前述した支払いアプリケーションのメインメニュー画面であり、連携ウォレットアイコンＩＣ１がタップされた状態が示されている。

図３−１中央は、連携ウォレットアイコンＩＣ１がタップされたことに基づいて表示される連携ウォレット情報の表示画面の一例であり、図１−９に対応する画面である。
本実施例では、ユーザＡ．Ａのユーザアカウントと、ユーザＢ．Ｂのユーザアカウントとが連携されているため、連携ウォレットの対象となるユーザ名を含む「Ａ．ＡとＢ．Ｂの連携ウォレット」の文字が表示されている。

また、これに伴い、連携メンバー情報表示領域ＭＩＲ１には、各々のユーザのアイコン画像と関連付けて、ユーザＡ．Ａのユーザアカウントであることを示す「Ａ．Ａ」の文字と、ユーザＢ．Ｂのユーザアカウントであることを示す「Ｂ．Ｂ」の文字とが表示されている。この例では、ユーザＡ．Ａのユーザアカウントの電子マネー口座残高は「１，０００円」であることが示され、ユーザＢ．Ｂのユーザアカウントの電子マネー口座残高は「６，０００円」であることが示されている。

限定ではなく例として、この画面においてコードリーダアイコンＩＣ２がタップされると、サーバ１０から端末２０Ａへ、この連携ウォレットを用いて支払いを行うための連携ウォレットコードリーダ情報が送信される。すると、端末２０Ａの制御部２１は、アプリケーションコードリーダを起動する。その結果、図３−１右側に示すようなアプリケーションコードリーダ画面が表示される。

図３−２左側は、図１−１０左側と同様の支払い金額入力画面であり、支払いボタンＢＴ１がタップされると、連携ウォレットを用いたコード支払いが実行される。
しかし、この例では、ユーザＡ．Ａのユーザアカウントの電子マネー口座残高が不足していることに基づいて、限定ではなく例として、図３−２中央に示すような連携支払い確認画面が表示される。

この連携支払い確認画面には、限定ではなく例として、現在位置表示領域ＣＬＲ１の下に、支払い金額確認領域ＰＩＲ１が表示されている。支払い金額確認領域ＰＩＲ１には、限定ではなく例として、支払い金額の送金先である「ＸＸ楽器」のアイコン画像とともに、その名称「ＸＸ楽器」と、支払い金額「４，５００円」とが表示されている。支払い金額の下には、現在の連携支払い可能額である「３，２５０円」が表示されている。

また、支払い金額確認領域ＰＩＲ１には、現在の連携支払い可能額が支払い金額を下回ることに基づいて、警告マークと「残高不足です」の文字とが表示されている。

また、支払い金額確認領域ＰＩＲ１の下には、連携メンバーの名称がアイコンと共に表示されている。その下には、連携メンバーそれぞれの支払い負担状況を確認するための、支払いメンバー確認領域ＰＭＲ１が表示されている。

ここで、連携支払い可能額とは、支払い金額を連携アカウントで等分して割り勘すると仮定し、以下の式で定義される金額である。
・連携支払い可能額＝全ての連携アカウントについての支払い余力の総和

ここで、一の連携アカウントの支払い余力は、以下の式で定義される。
・一の連携アカウントの支払い余力＝その連携アカウントの電子マネー口座残高（その連携アカウントの電子マネー口座残高−等分支払い金額＜０の場合）
・一の連携アカウントの支払い余力＝等分支払い金額（その連携アカウントの電子マネー口座残高−等分支払い金額≧０の場合）
ただし、「等分支払い金額＝支払い金額÷連携アカウント数」として算出される。

なお、これらの式を、限定ではなく例として、第１実施例や第２実施例に適用して、連携支払い可能額を同様に算出するようにしてもよいし、しなくてもよい。
つまり、上記の連携アカウントを、一人のユーザの複数のユーザアカウント、限定ではなく例として、前述した第１ユーザアカウント（メインアカウント）と第２ユーザアカウント（サブアカウント）との２つのユーザアカウント等として、連携支払い可能額を算出するようにしてもよいし、しなくてもよい。

本実施例では、連携メンバーと連携アカウントとは一対一の対応関係であるため、上記の式を、連携メンバーによって定義することもできる。つまり、上記の式は、以下のように表現することもできる。
・連携支払い可能額＝全ての連携メンバーについての支払い余力の総和
・一の連携メンバーの支払い余力＝その連携メンバーの電子マネー口座残高（その連携メンバーの電子マネー口座残高−等分支払い金額＜０の場合）
・一の連携メンバーの支払い余力＝等分支払い金額（その連携メンバーの電子マネー口座残高−等分支払い金額≧０の場合）
ただし、「等分支払い金額＝支払い金額÷連携メンバー人数」として算出される。

支払いメンバー確認領域ＰＭＲ１には、限定ではなく例として、それぞれの連携メンバー（連携アカウント）について、行ごとに、アイコンと、ユーザ名と、支払い余力と、電子マネー口座残高とが関連付けて表示されている。また、支払い余力が等分支払い金額を下回るユーザについては、アイコンの左上に警告マークが重ねて表示されている。

この例では、等分支払い金額は「４，５００円÷２＝２，２５０円」である。
ユーザＡ．Ａについては、支払い余力が等分支払い金額を下回るため、ユーザＡ．Ａのアイコンの左上に警告マークが表示され、支払い余力が「１，０００円」であることが示されている。
一方、ユーザＢ．Ｂについては、支払い余力が等分支払い金額を下回らないため、警告マークは表示されず、支払い余力が「２，２５０円」であることが示されている。

この例では、連携支払い可能額が支払い金額に満たないため、このままでは支払いを行うことができない。そのため、連携支払い確認画面の最下部には、等分支払い金額「２，２５０円」のうち、ユーザＡ．Ａの支払い余力「１，０００円」では不足する立て替え必要額「２，２５０円−１，０００円＝１，２５０円」をユーザＢ．Ｂに立て替えてもらい、支払いを実行するための「他のメンバーに立て替えてもらう」の文字で示される立て替え依頼ボタンＢＴ４が表示されている。

図３−２右側は、立て替え依頼ボタンＢＴ４がタップされた場合の、連携支払い確認画面の一例である。
この連携支払い確認画面では、支払いメンバー確認領域ＰＭＲ１において、ユーザＢ．Ｂの支払い余力が、等分支払い金額「２，２５０円」に立て替え必要額「１，２５０円」を加算した「３，５００円」に増加している。それに伴い、支払い金額確認領域ＰＩＲ１の連携支払い可能額が「４，５００円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。

また、連携支払い確認画面の最下部には、現在の支払い余力に応じて支払いを実行するための「支払い」の文字で示される連携支払い実行ボタンＢＴ５が表示されている。

図３−３は、図３−２右側の連携支払い確認画面において、連携支払い実行ボタンＢＴ５がタップされた場合の、画面の遷移の一例である。
図３−３左側には、連携ウォレットを用いた支払い結果を確認するための、連携支払い結果表示画面が表示されている。

また、連携支払い結果表示画面の下部には、この支払いに関する連携メンバーごとの内訳を表すメンバー支払い結果表示領域ＭＲＲ１が表示されている。
メンバー支払い結果表示領域ＭＲＲ１には、連携メンバーごとに、支払ったユーザ名と、支払い余力として支払った金額と、支払い後の電子マネー口座残高とが表示されている。

メンバー支払い結果表示領域ＭＲＲ１には、限定ではなく例として、ユーザＡ．Ａは、支払い余力「１，０００円」分を支払い、その結果、電子マネー口座残高が「０円」となったことが示されている。また、ユーザＢ．Ｂは、支払い余力「３，５００円」分を支払い、その結果、電子マネー口座残高が「２，５００円」となったことが示されている。

また、ユーザＢ．Ｂの項目には、ユーザＡ．Ａが、ユーザＢ．Ｂに立て替えてもらった「１，２５０円」をユーザＢ．Ｂに返却するための立て替え金額返金ボタンＢＴ６が加えて表示されている。

図３−３右側は、限定ではなく例として、支払いアプリケーションのメインメニューから「おしらせ」アイコンをタップすることで遷移するおしらせ画面の一例である。
なお、おしらせ画面へは、連携支払い結果表示画面に重ねて表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。

このおしらせ画面のおしらせ情報表示領域ＮＴＲ２には、連携支払いが実行されたことに基づく連携決済結果情報ＣＴ２と、連携支払いで立て替えが発生したことに基づく立て替え情報ＣＴ３とが表示されている。

連携決済結果情報ＣＴ２には、ユーザＡ．Ａが支払った金額である「１，０００円」と、支払い日時と、連携ウォレットを用いて支払いが完了したことと、支払い先が「ＸＸ楽器」であることとが表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
連携決済結果情報ＣＴ２の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−３左側の連携支払い結果表示画面が表示される。

なお、連携決済結果情報ＣＴ２には、ユーザＡ．Ａが支払った金額である「１，０００円」ではなく、「ＸＸ楽器」に支払った総支払い金額である「４，５００円」を表示するようにしてもよいし、そのようにしなくてもよい。
または、ユーザＡ．Ａが支払った金額と、総支払い金額の両方を表示するようにしてもよいし、そのようにしなくてもよい。
または、他のユーザが支払った金額を加えて表示するようにしてもよいし、そのようにしなくてもよい。

立て替え情報ＣＴ３には、連携ウォレットを用いた支払いでユーザＢ．Ｂに「１，２５０円」を立て替えてもらったことを示す情報が表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−３左側の連携支払い結果表示画面が表示される。
立て替え情報ＣＴ３の下部には、立て替え金額返金ボタンＢＴ６が表示されている。

立て替え金額返金ボタンＢＴ６がタップされると、ユーザＡ．Ａの電子マネー口座からユーザＢ．Ｂの電子マネー口座へ、立替分「１，２５０円」の送金が実行される。

なお、ユーザＡ．Ａの電子マネー口座残高が立替分に満たず、送金が実行できない場合、立て替え金額返金ボタンＢＴ６の表示態様をグレーアウトさせるなどしてボタン操作を無効化させてもよいし、そのようにしなくてもよい。
また、ユーザＡ．Ａの電子マネー口座残高が立替分に満たない状態で立て替え金額返金ボタンＢＴ６がタップされると、銀行口座からのチャージを促す画面へ遷移してもよいし、そのようにしなくてもよい。

立て替え金額返金ボタンＢＴ６を用いて立替分の返金が完了した場合、その後の表示において立て替え金額返金ボタンＢＴ６の表示態様をグレーアウトさせるなどしてボタン操作を無効化させてもよいし、そのようにしなくてもよい。

なお、おしらせ情報表示領域ＮＴＲ２において、連携決済結果情報ＣＴ２と立て替え情報ＣＴ３とをまとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。

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

通信Ｉ／Ｆ１４によって端末２０Ａから連携決済要求情報を受信すると、サーバ１０の制御部１１は、連携支払い可能額を算出し、算出された連携支払い可能額が決済予定金額を下回っているか否か（連携支払い可能額−決済予定金額＜０であるか否か）を判定する（Ｓ２１０）。連携支払い可能額が決済予定金額を下回っている場合（Ｓ２１０：ＹＥＳ）、サーバ１０の制御部１１は、連携支払い可能額が不足し、支払いが実行できないため、他の連携アカウントからコード決済実行者のアカウントに送金が必要であることを示す連携残高不足情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ２２０）。

連携支払い可能額が決済予定金額を下回っていない場合（連携支払い可能額−決済予定金額が０以上となる場合）には（Ｓ２１０：ＮＯ）、連携ウォレットを用いた支払いが可能であるため、サーバ１０の制御部１１は、Ｓ１１０のステップに処理を移す。

通信Ｉ／Ｆ２２によってサーバ１０から連携残高不足情報を受信する場合（Ａ２００：ＹＥＳ）、端末２０Ａの制御部２１は、連携ウォレットの他の連携メンバー（この場合にはユーザＢ．Ｂ）のアカウントにユーザＡ．Ａの支払い余力の不足分（すなわち等分支払い金額−ユーザＡ．Ａの支払い余力）を負担してもらい、支払いを継続するための残高補充要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２１０）。

なお、ユーザＢ．Ｂのアカウントの電子マネー口座残高が決済予定金額以上である場合、残高補充要求情報として、ユーザＢ．Ｂのアカウントから決済予定金額の全額を負担してもらうための情報を送信するようにしてもよいし、そのようにしなくてもよい。

また、通信Ｉ／Ｆ２２によってサーバ１０から連携残高不足情報を受信しない場合（Ａ２００：ＮＯ）、Ａ２１０のステップは実行されない。

通信Ｉ／Ｆ１４によって端末２０Ａから残高補充要求情報を受信すると、サーバ１０の制御部１１は、受信した残高補充要求情報に基づいて、連携残高補充処理を実行する（Ｓ２３０）。
連携残高補充処理において、サーバ１０の制御部１１は、ユーザＡ．Ａの支払い余力の不足分（立て替え必要額）を、ユーザＢ．Ｂの支払い余力に加算した金額を新たなユーザＢ．Ｂの支払い余力として更新させる。そして、サーバ１０の制御部１１は、立て替え必要額をユーザＡ．ＡからユーザＢ．Ｂへの返却必要額として記憶部１５に記憶させる。

なお、サーバ１０の制御部１１は、連携残高補充処理の処理結果を通信Ｉ／Ｆ１４によって端末２０Ａに送信し、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によって受信した連携残高補充処理の処理結果を表示部２４に表示させるようにしてもよいし、そのようにしなくてもよい。

また、連携残高補充処理において、ユーザＢ．Ｂの支払い余力を増加させるのではなく、ユーザＢ．ＢのアカウントからユーザＡ．Ａのアカウントへ立て替え必要額の送金処理を実行することで、ユーザＡ．Ａの支払い余力を増加させるようにしてもよいし、そのようにしなくてもよい。

サーバ１０の制御部１１は、店舗提示型連携決済処理を実行すると（Ｓ１１０）、連携決済処理の実行結果である連携決済結果情報を、通信Ｉ／Ｆ１４によって連携メンバーの各々の端末２０に送信する（Ｓ２４０）。

通信Ｉ／Ｆ２２によってサーバ１０から連携決済結果情報を受信すると、端末２０Ａの制御部２１は、連携決済結果情報を表示部２４に表示させる（Ａ２３０）。

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

連携決済処理に先んじて、連携残高補充処理が実行された場合（Ｓ２５０：ＹＥＳ）、サーバ１０の制御部１１は、記憶部１５に記憶された返却必要額を含む貸し借り情報を、通信Ｉ／Ｆ１４によって連携メンバーの各々の端末２０に送信する（Ｓ２６０）。
一方、連携残高補充処理が実行されなかった場合（Ｓ２５０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から貸し借り情報を受信する場合（Ａ２４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した貸し借り情報を表示部２４に表示させる（Ａ２５０）。
一方、貸し借り情報を受信しない場合（Ａ２４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

Ａ２５０のステップの後、端末２０Ａの制御部２１は、返却必要額をユーザＢ．Ｂに返却するか否かの選択用画面を表示部２４に表示させる（Ａ２６０）。
なお、Ａ２５０のステップとＡ２６０のステップとの間に、外部金融機関の口座からユーザＡ．Ａのアカウントに対するチャージ、あるいは、他のアカウントからユーザＡ．Ａのアカウントに対する送金等の処理を挟んでもよい。

端末２０Ａの入出力部２３に対するユーザ操作に基づいて、返却必要額をユーザＢ．Ｂに返却することが選択される場合（Ａ２６０：ＹＥＳ）、端末２０Ａの制御部２１は、ユーザＡ．ＡのアカウントからユーザＢ．Ｂのアカウントへ返却必要額に相当する金額の送金を実行するための返却必要額返却情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２７０）。
一方、返却必要額をユーザＢ．Ｂに返却することが選択されない場合（Ａ２６０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ１４によって端末２０Ａから返却必要額返却情報を受信する場合（Ｓ２７０：ＹＥＳ）、サーバ１０の制御部１１は、返却必要額返却情報に基づいて、ユーザＡ．ＡのアカウントからユーザＢ．Ｂのアカウントへ返却必要額に記載の金額の送金を実行する貸し借り返却処理を実行する（Ｓ２８０）。また、貸し借り返却処理が成功すると、サーバ１０の制御部１１は、記憶部１５に記憶させた返却必要額を消去する。

その後、サーバ１０の制御部１１は、貸し借り返却処理によって実行された送金処理の実行結果を含む貸し借り返却情報を、通信Ｉ／Ｆ１４によって、返却必要額返却情報の送金元と、送金先とのアカウントに対応する各々の端末２０に送信する（Ｓ２９０）。そして、サーバ１０の制御部１１は、処理を終了させる。

端末２０Ａから返却必要額返却情報を受信しない場合（Ｓ２７０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から貸し借り返却情報を受信すると、端末２０Ａの制御部２１は、貸し借り返却情報を表示部２４に表示させる（Ａ２８０）。そして、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から貸し借り情報を受信する場合（Ｂ２１０：ＹＥＳ）、端末２０Ｂの制御部２１は、受信した貸し借り情報を表示部２４に表示させる（Ｂ２２０）。
貸し借り情報を受信しない場合（Ｂ２１０：ＮＯ）、端末２０Ｂの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から貸し借り返却情報を受信する場合（Ｂ２３０：ＹＥＳ）、端末２０Ｂの制御部２１は、貸し借り返却情報を表示部２４に表示させる（Ｂ２４０）。そして、端末２０Ｂの制御部２１は、処理を終了させる。

＜第３実施例の効果＞
本実施例によれば、第１ユーザの第１ユーザアカウントと、この第１ユーザアカウントと連携された第２ユーザの第２ユーザアカウントとに基づき、決済を行うことができる。また、この決済に基づき、第１ユーザアカウントから第２ユーザアカウントに送金することができる。第２ユーザアカウントは第２ユーザのアカウントであるため、第１ユーザの第１アカウントと、この第１アカウントと関連付けられた第２ユーザの第２アカウントとに基づく決済を実現することができる。

なお、第２ユーザアカウントは、第２ユーザのアカウントである。
このため、第２ユーザアカウントへの送金は、第２ユーザへの送金と捉えてもよいし、第２ユーザの端末への送金と捉えてもよい。

また、本実施例は、アカウント連携決済は、少なくとも第２ユーザアカウントによって第１ユーザアカウントの不足分の支払いが行われる。また、貸し借り情報（限定ではなく、第１情報の一例）は、返却必要額（限定ではなく、第２アカウントによって第１アカウントの代わりに支払った金額の一例）の情報を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１決済において、少なくとも第２アカウントによって第１アカウントの不足分の支払いが行われるようにすることができる。これにより、第１アカウントの残高が不足していて、支払うべき金額の全部を支払うことができないような場合に、この不足分の金額を、第２アカウントに支払ってもらうことができる。また、第２アカウントによって第１アカウントの代わりに支払った金額を、第１アカウントから第２アカウントに送金するように、第１ユーザに促すことができる。

また、上記において、第１ユーザアカウントによる支払いは行われないようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１決済において、第２アカウントから全ての支払いが行われるようにすることができる。

また、上記において、アカウント連携決済は、第１ユーザアカウントによる支払いと、少なくとも第２ユーザアカウントによって第１ユーザアカウントの不足分の支払いとが行われるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１決済において、第１アカウントによる支払いも行うが、少なくとも第２アカウントによって、第１アカウントの不足分の支払いが行われるようにすることができる。

また、上記において、連携残高不足情報（限定ではなく、第１情報の一例）は、サーバ１０を介して端末２０の通信Ｉ／Ｆ２２によって受信される構成を示している。
このような構成により得られる実施例の効果の一例として、サーバを介して第１情報を簡単に取得することができる。

＜第３変形例（１）＞
第３実施例では、不足額を立て替えてもらったユーザＡ．Ａが能動的に返却必要額をユーザＢ．Ｂに返却する場合を示したが、これに限定されない。限定ではなく例として、返却必要額を立て替えた（貸し出した）連携メンバーであるユーザＢ．Ｂが、立て替えてもらったユーザＡ．Ａに対して必要返却額の請求を行えるようにしてもよいし、そのようにしなくてもよい。

＜表示画面＞
図３−６は、図３−３右側の端末２０Ａの連携支払い確認画面において、連携支払い実行ボタンＢＴ５がタップされた場合の、端末２０Ｂにおける画面の遷移の一例を示す図である。

図３−６左側は、限定ではなく例として、支払いアプリケーションのメインメニューから「おしらせ」アイコンをタップすることで遷移するおしらせ画面の一例である。なお、おしらせ画面へは、端末２０Ｂに送信されて表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。

このおしらせ画面のおしらせ情報表示領域ＮＴＲ３には、連携支払いが実行されたことに基づく連携決済結果情報ＣＴ４と、連携支払いで立て替えが発生したことに基づく立て替え情報ＣＴ５とが表示されている。

連携決済結果情報ＣＴ４には、ユーザＢ．Ｂが支払った金額である「３，５００円」と、支払い日時と、連携ウォレットを用いて支払いが完了したことと、支払い先が「ＸＸ楽器」であることとが表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
連携決済結果情報ＣＴ４の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−６右側の連携支払い結果表示画面が表示される。

立て替え情報ＣＴ５には、連携ウォレットを用いた支払いでユーザＡ．Ａに「１，２５０円」を立て替えたことを示す表示が表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−６右側の連携支払い結果表示画面が表示される。
立て替え情報ＣＴ５の下部には、ユーザＢ．ＢがユーザＡ．Ａに立て替えた「１，２５０円」の返金を請求するための立て替え金額請求ボタンＢＴ７が表示されている。

図３−６右側は、端末２０Ｂの表示部２４に表示される連携支払い結果表示画面の一例である。
この画面では、メンバー支払い結果表示領域ＭＲＲ２において、立て替え金額返金ボタンＢＴ６の代わりに、ユーザＡ．Ａの項目に、ユーザＢ．Ｂが立て替えた「１，２５０円」の返却を促すための立て替え金額請求ボタンＢＴ７が加えて表示されている。

立て替え金額請求ボタンＢＴ７がタップされると、端末２０Ａに対して、ユーザＡ．Ａの電子マネー口座からユーザＢ．Ｂの電子マネー口座へ立替分「１，２５０円」の送金を促す情報が送信され、端末２０Ａの表示部２４に表示される。
なお、ユーザＡ．Ａの電子マネー口座残高が立替分より大きい場合、自動的にユーザＡ．Ａの電子マネー口座からユーザＢ．Ｂの電子マネー口座への立替分の送金が実行されるようにしてもよいし、そのようにしなくてもよい。

また、立替分の返金が完了している場合、その後の表示において立て替え金額請求ボタンＢＴ７の表示態様をグレーアウトさせるなどしてボタン操作を無効化させてもよいし、そのようにしなくてもよい。

＜処理＞
図３−７〜図３−８に、図３−４から続く本変形例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

端末２０Ｂの制御部２１は、Ｂ２２０のステップを実行すると、返却必要額をユーザＡ．Ａから返却させることを要請（催促）するか否かの選択用画面を表示部２４に表示させる（Ｂ２２３）。

端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、ユーザＡ．Ａに返却必要額を返却させることを催促することが選択される場合（Ｂ２２３：ＹＥＳ）、端末２０Ｂの制御部２１は、ユーザＡ．ＡのアカウントからユーザＢ．Ｂのアカウントへ返却必要額に相当する金額の送金を要請するための返却必要額請求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ２２６）。

ユーザＡ．Ａに返却必要額を返却させることを催促することが選択されない場合には（Ｂ２２３：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ２３０のステップへ処理を進める。

サーバ１０の制御部１１は、Ｓ２６０のステップを実行後、通信Ｉ／Ｆ１４によって端末２０Ｂから返却必要額請求情報を受信する場合（Ｓ２６３：ＹＥＳ）、通信Ｉ／Ｆ１４によって、催促先であるユーザＡ．Ａの端末２０Ａに、返却必要額を返却させることを催促する返却必要額督促情報を送信する（Ｓ２６６）。その後、Ｓ２７０以降のステップを実行する。

返却必要額請求情報を受信しない場合には（Ｓ２６３：ＮＯ）、サーバ１０の制御部１１は、Ｓ２６６のステップを実行せず、Ｓ２７０以降のステップを実行する。

端末２０Ａの制御部２１は、Ａ２５０のステップを実行後、通信Ｉ／Ｆ２２によってサーバ１０から返却必要額督促情報を受信する場合（Ａ２５３：ＹＥＳ）、返却必要額督促情報を表示部２４に表示させる（Ａ２５６）。その後、端末２０Ａの制御部２１は、Ａ２６０のステップへ処理を進める。

返却必要額督促情報を受信しない場合には（Ａ２５３：ＮＯ）、端末２０Ａの制御部２１は、Ａ２６０のステップへ処理を進める。

なお、Ａ２５６のステップを実行後、「Ａ２６０：ＮＯ」となった場合には再度Ａ２５６のステップに戻り、端末２０ＡのユーザＡ．Ａに繰り返し報知させるようにしてもよいし、そのようにしなくてもよい。また、一定期間ごとにＡ２５６のステップを実行し、リマインドし続けるようにしてもよいし、そのようにしなくてもよい。

＜第３変形例（２）＞
第３実施例では、コード決済を実行するユーザＡ．Ａのアカウントの電子マネー口座残高が等分支払い金額に満たない場合を示したが、これに限定されない。限定ではなく例として、連携メンバーのアカウントであるユーザＢ．Ｂの電子マネー口座残高が等分支払い金額に満たない場合に、ユーザＡ．ＡのアカウントによってユーザＢ．Ｂの支払い余力の不足分（すなわち等分支払い金額−ユーザＢ．Ｂの支払い余力）を負担し、連携ウォレットを用いた支払いを実行するようにしてもよいし、そのようにしなくてもよい。

＜表示画面＞
図３−９は、端末２０Ｂで表示されるアカウント連携決済を完了するまでの画面の遷移の一例である。この図は、図３−２の端末２０Ａで表示されるアカウント連携決済を完了するまでの画面の遷移を、端末２０Ｂ側で見た場合の遷移を示す図である。
図３−９左側には、図３−２中央と同様に、警告マークと「残高不足です」の文字とを含む連携支払い確認画面を示している。

また、連携支払い確認画面の最下部には、等分支払い金額「２，２５０円」のうち、ユーザＡ．Ａの支払い余力「１，０００円」では不足する立て替え必要額「２，２５０円−１，２５０円＝１，２５０円」をユーザＢ．Ｂが立て替え、支払いを実行するための「不足分を立て替える」の文字で示される立て替えボタンＢＴ１０が表示されている。

立て替えボタンＢＴ１０がタップされると、図３−９中央の連携支払い確認画面に表示が遷移する。
この画面では、支払いメンバー確認領域ＰＭＲ２において、ユーザＢ．Ｂの支払い余力が等分支払い金額「２，２５０円」に立て替え必要額「１，２５０円」を加算した「３，５００円」に増加している。それに伴い、支払い金額確認領域ＰＩＲ２の連携支払い可能額は「４，５００円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。

また、連携支払い確認画面の最下部には、現在の支払い余力に応じて支払いを実行するための「支払い」の文字で示される連携支払い実行ボタンＢＴ１１が表示されている。

連携支払い実行ボタンＢＴ１１がタップされると、図３−９右側の連携支払い結果表示画面に表示が遷移する。
この画面には、連携ウォレットを用いた支払いが完了したことを示す「支払い完了」の文字とともに、支払い金額の送金先である「ＸＸ楽器」のアイコン画像と、その名称と、支払い日時とが表示されている。連携支払い結果表示画面の下部には、メンバー支払い結果表示領域ＭＲＲ３が表示されている。

メンバー支払い結果表示領域ＭＲＲ３には、限定ではなく例として、ユーザＡ．Ａは、支払い余力「１，０００円」分を支払い、その結果、電子マネー口座残高が「０円」となったことが表示されている。また、ユーザＢ．Ｂは、支払い余力「３，５００円」分を支払い、その結果、電子マネー口座残高が「２，５００円」となったことが表示されている。

また、ユーザＡ．Ａの項目には、ユーザＢ．ＢがユーザＡ．Ａに立て替えた「１，２５０円」を請求するための立て替え金額請求ボタンＢＴ１２が加えて表示されている。
立て替え金額請求ボタンＢＴ１２がタップされた場合の挙動については、図３−６において立て替え金額請求ボタンＢＴ７がタップされた場合と同様に構成可能である。

図３−１０は、図３−９中央の端末２０Ｂの連携支払い確認画面において、連携支払い実行ボタンＢＴ５がタップされた場合の、端末２０Ａにおける画面の遷移の一例である。

図３−１０左側は、限定ではなく例として、支払いアプリケーションのメインメニューから「おしらせ」アイコンをタップすることで遷移するおしらせ画面の一例である。なお、おしらせ画面へは、端末２０Ａに送信されて表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。

連携決済結果情報ＣＴ４には、ユーザＡ．Ａが支払った金額である「１，０００円」と、支払い日時と、連携ウォレットを用いて支払いが完了したことと、支払い先が「ＸＸ楽器」であることとが表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
連携決済結果情報ＣＴ４の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−１０右側の連携支払い結果表示画面が表示される。

立て替え情報ＣＴ５には、連携ウォレットを用いた支払いでユーザＢ．Ｂに「１，２５０円」を立て替えてもらったことを示す表示が表示されている。また、右上には、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットで支払いを行ったことを示すアイコンが表示されている。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図３−１０右側の連携支払い結果表示画面が表示される。
立て替え情報ＣＴ５の下部には、ユーザＡ．Ａが、ユーザＢ．Ｂに立て替えてもらった「１，２５０円」を返却するための立て替え金額返金ボタンＢＴ６が表示されている。

図３−１０右側は、端末２０Ａの表示部２４に表示される連携支払い結果表示画面の一例である。
この画面では、メンバー支払い結果表示領域ＭＲＲ２において、ユーザＢ．Ｂの項目に、ユーザＢ．Ｂに立て替えてもらった「１，２５０円」を返却するための立て替え金額返金ボタンＢＴ６が加えて表示されている。

＜処理＞
この場合の処理については、限定ではなく例として、図３−４のＡ２１０のステップにおいて、残高補充要求情報を、連携ウォレットの他の連携メンバー（この場合にはユーザＢ．Ｂ）の支払い余力の不足分（すなわち等分支払い金額−ユーザＢ．Ｂの支払い余力）をユーザＡ．Ａが負担するための情報とし、図３−５の端末２０Ａおよび端末２０Ｂの各ステップを端末間で入れ替えて実行することで、図３−４〜図３−５と同様に実行することが可能である。

＜第３変形例（３）＞
第３実施例では、コード決済を実行するユーザＡ．Ａのアカウントの電子マネー口座残高が等分支払い金額に満たない場合、他の連携アカウントによって不足分を立て替えてもらう例を示したが、これに限定されない。限定ではなく例として、コード決済の実行時に不足分を外部金融機関の口座からユーザＡ．Ａのアカウントに対してチャージするようにしてもよいし、そのようにしなくてもよい。

＜表示画面＞
図３−１１は、連携ウォレットを用いたコード支払いが実行された場合における連携支払い確認画面の画面の遷移の一例を示す図である。

図３−１１左側には、連携支払い確認画面が表示されている。この画面では、支払いメンバー確認領域ＰＭＲ１において、電子マネー口座残高のチャージを行うための「＋」マークで示されるチャージボタンＢＴ８が加えて表示されている。

立て替え依頼ボタンＢＴ４の代わりに、チャージボタンＢＴ８がタップされると、限定ではなく例として、図３−１１中央に示す画面が表示される。
この画面では、連携支払い確認画面の下側からチャージ表示領域ＣＧＲ１がせり上がり、重ねて表示されている。

チャージ表示領域ＣＧＲ１には、ユーザに対する操作案内として「チャージ」が表示され、その下に、銀行口座表示領域が設けられている。

この例では、銀行口座表示領域内には、「〇×銀行」のロゴ（〇×ＢＡＮＫ）とともに、その銀行名「〇×銀行」が表示されている。また、その下には、預金種類および口座番号として「普通預金口座＊＊＊＊＊＊＊」が表示され、その下には、口座名義人である「Ａ．Ａ」が表示されている。

銀行口座表示領域の下には、「チャージ金額」の表示とともに、入力されたチャージ予定金額を表示するためのチャージ予定金額入力領域が設けられている。ここでは、チャージ予定金額として「２，０００円」が入力されて表示されている。また、その下には、チャージ予定金額入力領域へのチャージ金額入力用であり、この例では「１００円」をチャージ予定金額に加算するための第１チャージボタンと、「１，０００円」をチャージ予定金額に加算するための第２チャージボタンと、「１０，０００円」をチャージ予定金額に加算するための第３チャージボタンとが横方向に並んで表示されている。

なお、チャージ予定金額入力領域内の左部には、チャージ予定金額消去ボタンが表示され、チャージ予定金額消去ボタンがタップされると、チャージ予定金額入力領域内の金額は消去され、チャージ予定金額入力領域内は「０円」と表示される。

また、チャージ表示領域ＣＧＲ１の最下部には、チャージ予定金額入力領域内に入力された金額のチャージを実行するためのチャージ実行ボタンＢＴ９が表示されている。この例において、チャージ実行ボタンＢＴ９がタップされると、自分の電子マネー口座残高に「２，０００円」がチャージされる。

なお、チャージ予定金額入力領域がタップされると、表示部２４の下部には送金予定額を入力するためのテンキー領域が表示され、テンキー領域への入力に基づいて、送金予定額を細かく入力することも可能である。

図３−１１右側は、チャージ実行ボタンＢＴ９がタップされた場合の連携支払い確認画面の一例である。
この画面では、ユーザＡ．Ａの電子マネー口座残高が「２，０００円」増加したことに伴って、支払いメンバー確認領域ＰＭＲ１において、ユーザＡ．Ａの支払い余力が「２，２５０円」に増加している。それに伴い、支払い金額確認領域ＰＩＲ１の連携支払い可能額は「４，５００円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。

＜処理＞
この場合の処理については、限定ではなく例として、図３−４のＡ２１０のステップにおいて、端末２０Ａの制御部２１は、残高補充要求情報の代わりに、予めユーザＡ．Ａによって登録された外部金融機関の口座からユーザＡ．Ａのアカウントに対して、支払い余力の不足分のチャージを行うためのチャージ要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、図３−４のＳ２３０のステップにおいて、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって受信したチャージ要求情報に従って、支払い余力の不足分を外部金融機関の口座からユーザＡ．Ａのアカウントにチャージすればよい。

＜第３変形例（４）＞
第３実施例では、端末２０Ａは、連携残高不足情報（限定ではなく例として、第１情報の一例）をサーバ１０から受信することとしたが、これに限定されない。限定ではなく例として、他メンバーの端末２０（限定ではなく例として、端末２０Ｂ）から連携残高不足情報を受信するようにしてもよいし、そのようにしなくてもよい。

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

サーバ１０の制御部１１は、連携支払い可能額が決済予定金額を下回っている場合（Ｓ２１０：ＹＥＳ）、連携支払い可能額が不足し、このままでは支払いが失敗することを示す連携支払い可能額不足情報を、通信Ｉ／Ｆ１４によって連携メンバーの各々の端末２０に送信する（Ｓ２２２）。

通信Ｉ／Ｆ２２によってサーバ１０から連携支払い可能額不足情報を受信する場合（Ｂ１８０：ＹＥＳ）、端末２０Ｂの制御部２１は、ユーザＡ．Ａの支払い余力の不足分をユーザＢ．Ｂのアカウントで負担可能か判定し、負担可能な場合には連携残高不足情報を通信Ｉ／Ｆ２２によって端末２０Ａに送信する（Ｂ１９０）。

連携支払い可能額不足情報を受信しない場合には（Ｂ１８０：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ１９０のステップを実行しない。

なお、Ｂ１８０とＢ１９０とのステップ実行時に、端末２０Ｂの制御部２１は、連携ウォレットの支払いで立て替えが必要な状況が生じた旨を表示部２４に表示させるようにしてもよいし、ユーザＢ．Ｂに報知させることなく処理を進めてもよい。

通信Ｉ／Ｆ２２によって端末２０Ｂから連携残高不足情報を受信する場合（Ａ２０５：ＹＥＳ）、端末２０Ａの制御部２１は、Ａ２１０のステップを実行する。

なお、通信Ｉ／Ｆ２２によって端末２０Ｂから連携残高不足情報を受信しない場合（Ａ２０５：ＮＯ）、Ａ２１０のステップは実行されない。

図３−１２のステップが実行されると、図３−５の各ステップの処理が続いて実行される。

＜第４実施例＞
第３実施例では、連携メンバーが二人の場合について説明したが、これに限定されない。
本実施例では、連携メンバーが三人以上の場合について説明する。

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

三人以上の連携メンバーで運用する場合、処理方法は、限定ではなく例として、２つの方法が考えられる。
（１）連携アカウントデータに登録される連携アカウント数を単純に増やす方法
（２）複数の連携メンバーで予め構成されるグループを導入する方法

（１）の方法では、限定ではなく例として、第１の連携ウォレット管理データベース１５７Ａの連携アカウントデータに、三人以上の連携メンバーの各々のユーザアカウントを記憶させるようにすることができる。
なお、三人以上の連携メンバーの各々のユーザアカウントではなく、任意の連携メンバーの３以上のユーザアカウントを用いる場合でも同様である。

以下、（２）の方法について詳細に説明する。
ここでは、限定ではなく例として、支払いアプリケーションにおいて複数のユーザを含むグループが形成され、このグループに含まれるユーザ（以下、「グループメンバー」と称する。）の各々のユーザアカウントを連携させてアカウント連携決済を行う場合について説明する。
また、ここでは、同じグループに含まれる全てのグループメンバーを連携メンバーとする場合を例示する。

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

グループ管理データベース１５９は、支払いアプリケーション（またはメッセージングアプリケーション）において形成されるグループの管理用のデータベースであり、そのデータ構成の一例を図４−２に示す。
グループ管理データベース１５９には、グループごとの管理データとして、グループ管理データが記憶される。

各々のグループ管理データには、限定ではなく例として、グループＩＤと、グループ名と、グループメンバーデータとが記憶される。
グループＩＤは、グループを識別するために用いられる情報（グループを識別するための識別情報）である。
このグループＩＤは、好ましくはグループごとに一意な値であり、限定ではなく例として、サーバ１０によってグループごとに一意な値（固有の値）が設定されて記憶される。

グループ名は、このグループの名称であり、限定ではなく例として、グループを作成するユーザ等によって端末２０で入力された名称が、サーバ１０によって登録される。

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

なお、グループメンバーデータに、同じグループメンバーに属する複数のアカウントを記憶させるようにしてもよいし、そのようにしなくてもよい。また、グループメンバーデータに記憶されるアカウントの数は、３以上に限定されない。１以上のアカウントがグループメンバーデータに登録されていればグループとして扱うようにしてもよいし、そのようにしなくてもよい。

図４−３は、連携ウォレット管理データベース１５７の一例である第２の連携ウォレット管理データベース１５７Ｂのデータ構成例を示す図である。
第２の連携ウォレット管理データベース１５７Ｂには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、決済履歴データとが記憶される。

グループＩＤは、この連携ウォレットを使用するグループを識別するための情報であり、グループ管理データベース１５９に記憶されるグループを単位としてアカウント連携決済で用いられる連携ウォレットを識別するための情報である。すなわち、グループＩＤによって、一意的に使用される連携ウォレットを定めることができる。

グループ名は、この連携ウォレットを使用するグループの名称であり、限定ではなく例として、グループ管理データに記憶されたグループＩＤに対応するグループ名が紐づいて記憶される。

決済履歴データは、第１の連携ウォレット管理データベース１５７Ａと同様である。

すなわち、（２）の方法は、（１）の方法において、第１の連携ウォレット管理データベース１５７Ａの連携ウォレット管理データにおける連携ウォレットＩＤをグループＩＤに、グループ管理データベース１５９の連携アカウントデータをグループメンバーデータに、それぞれ置き換えたものとも言える。

＜表示画面＞
ここでは、限定ではなく例として、（２）の方法を適用する場合の表示画面例について説明する。

図４−４は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図４−４左側は、限定ではなく例として、ユーザＡ．Ａの端末２０Ａの表示部２４に表示される支払いアプリケーションのメインメニュー画面である。
このメインメニュー画面において連携ウォレットアイコンＩＣ１がタップされると、端末２０Ａからサーバ１０に対して、ウォレット連携を行うグループを選択するためのグループ一覧情報を要求する情報が送信され、サーバ１０から端末２０Ａに対して、グループ一覧情報が送信される。その結果、限定ではなく例として、図４−４右側に示すようなグループ選択画面が表示される。

この画面において、現在位置表示領域ＣＬＲ１には、連携ウォレットの機能を利用中であることを示す「連携ウォレット」の文字が表示され、その下に、ウォレット連携を行うグループを選択することをユーザに促す「グループを選択してください」の文字が表示されている。

また、その下には、この端末のユーザ（この場合にはユーザＡ．Ａ）が所属するグループが行ごとにまとまって一覧表示されている。それぞれのグループの項目には、限定ではなく例として、グループのアイコンと、グループ名と、グループを構成するメンバーの人数とが示されている。

限定ではなく例として、ウォレット連携を行うグループとして、グループ名「バンド仲間」のグループ（以下、グループ「バンド仲間」と称する。）がタップされると、限定ではなく例として、図４−５に示すような画面に移行する。
図４−５左側は、連携ウォレットのメイン画面の一例であり、この画面では、連携メンバー情報表示領域ＭＩＲ１に、グループ「バンド仲間」の各ユーザの電子マネー口座残高が表示されている。

限定ではなく例として、この画面において、コードリーダアイコンＩＣ２がタッチされると、端末２０Ａの制御部２１は、「店舗提示型」のコード決済を行う際に、端末２０Ａで端末読み取り用コードを読み取るために、アプリケーションコードリーダを起動する。

図４−５中央に、アプリケーションコードリーダ画面の一例を示す。
この画面では、現在位置表示領域ＣＬＲ１の下に、現在実行中の機能である「コードリーダ」の文字が表示されている。また、画面中央には、支払い店舗コードを読み取るためのコード読み取り領域ＣＲ１が表示されている。

図４−５右側は、図４−５中央において読み取られた支払い店舗コードからデコードによって情報が取得された場合に表示される支払い金額入力画面の一例を示す図である。

この支払い金額入力画面には、支払い金額の送金先である「ＸＸ楽器」のアイコン画像とともに、その名称「ＸＸ楽器」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域ＰＲ１が表示され、ここでは、支払い金額として「４，５００円」が入力されて表示されている。また、支払い金額表示領域ＰＲ１の左端には、支払い金額を消去するための丸で囲まれた×印で示される消去ボタンが表示されている。
画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額表示領域ＰＲ１に入力されている支払い金額で支払いを実行するための「支払い」の文字で示された支払いボタンＢＴ１が表示されている。
図４−５右側に示される支払い金額入力画面において支払いボタンＢＴ１がタップされると、連携ウォレットを用いたコード支払いが実行される。

なお、図４−５左側の画面において、コード支払いアイコンＩＣ３がタップされると、端末２０Ａの表示部２４には、コード支払い画面が表示される。コード支払い画面には、サーバ１０から送信されて端末２０が受信したコード（コード画像）であって、「利用者提示型」で決済を行うために用いられるコードである連携ウォレット支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコードとが表示される。端末２０ＡのユーザＡ．Ａは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことで連携ウォレットを用いたコード支払いを行うことも可能である。

図４−６は、連携ウォレットを用いたコード支払いが実行された場合における連携支払い確認画面の画面の遷移の一例を示す図である。
図４−６左側には、連携支払い確認画面として、限定ではなく例として、現在位置表示領域ＣＬＲ１の下に、支払い金額確認領域ＰＩＲ１が表示されている。支払い金額確認領域ＰＩＲ１には、限定ではなく例として、支払い金額の送金先である「ＸＸ楽器」のアイコン画像とともに、その名称「ＸＸ楽器」と、支払い金額「４，５００円」とが表示されている。支払い金額の下には、現在の連携支払い可能額である「４，０００円」が表示されている。また、支払い金額確認領域ＰＩＲ１には、現在の連携支払い可能額が支払い金額を下回ることに基づいて、警告マークと「残高不足です」の文字とが表示されている。

また、支払い金額確認領域ＰＩＲ１の下には、支払いに用いている連携ウォレットのグループである「バンド仲間」の名称がアイコンと共に表示されている。その下には、グループ「バンド仲間」のメンバーそれぞれの支払い負担状況を確認するための、支払いメンバー確認領域ＰＭＲ１が表示されている。

支払いメンバー確認領域ＰＭＲ１には、限定ではなく例として、それぞれのメンバーについて行ごとに、アイコンと、ユーザ名と、支払い負担分の金額（支払い余力）と、電子マネー口座残高とが関連付けて表示されている。また、支払い余力が等分支払い金額を下回るユーザについては、アイコンの左上に警告マークが重ねて表示されている。

この例では、等分支払い金額は「４，５００円÷３＝１，５００円」である。
ユーザＡ．Ａのアイコンの左上に警告マークが表示され、支払い余力が「１，０００円」であることが示されている。この場合、連携支払い可能額が支払い金額に満たず、このままでは支払いを行うことができない。
そのため、連携支払い確認画面の最下部には、等分支払い金額「１，５００円」のうち、支払い余力「１，０００円」では不足する立て替え必要額「１，５００円−１，０００円＝５００円」をユーザＡ．Ａ以外の他のメンバーに立て替えてもらい、支払いを実行するための「他のメンバーに立て替えてもらう」の文字で示される立て替え依頼ボタンＢＴ４が表示されている。

図４−６中央は、立て替え依頼ボタンＢＴ４がタップされた場合の、連携支払い確認画面の一例である。
この画面では、支払いメンバー確認領域ＰＭＲ１の代わりに、立て替えてもらうことが可能なメンバーの一覧を表示し、選択させるための立替メンバー選択領域ＰＳＲ１が表示されている。

立替メンバー選択領域ＰＳＲ１には、立替者の選択をユーザに促す「立て替えてもらうメンバーを選んでください」の文字の下に、立て替え可能なメンバーの名前と、電子マネー口座残高とが行ごとに表示されている。この例では、等分支払い金額「１，５００円」に立て替え必要額「５００円」を加算した「２，０００円」を負担可能なメンバーとして、ユーザＢ．ＢとユーザＣ．Ｃとが表示されている。この例において、ユーザＢ．Ｂの電子マネー口座残高は「３，０００円」であり、ユーザＣ．Ｃの電子マネー口座残高は「６，０００円」である。

限定ではなく例として、ユーザＣ．Ｃがタップされ、立替者として選択されると、図４−６右側の連携支払い確認画面に表示が遷移する。
この画面では、支払いメンバー確認領域ＰＭＲ１において、ユーザＣ．Ｃの支払い余力が等分支払い金額「１，５００円」に立て替え必要額「５００円」を加算した「２，０００円」に増加している。それに伴い、支払い金額確認領域ＰＩＲ１の連携支払い可能額は「４，５００円」に増加し、「残高不足です」の文字が消え、代わりに「支払い可能です」の文字が表示されている。

なお、図４−６中央において、立替者を一人ではなく複数選ぶことが可能にしてもよいし、そのようにしなくてもよい。複数の立替者を選ぶ場合には、立て替え必要額を等分するようにしてもよいし、限定ではなく例として、電子マネー口座残高に応じて按分して負担させるようにしてもよい。

図４−７は、図４−６右側の連携支払い確認画面において、連携支払い実行ボタンＢＴ５がタップされた場合の、画面の遷移の一例である。
図４−７左側には、連携ウォレットを用いた支払い結果を確認するための、連携支払い結果表示画面が表示されている。

また、連携支払い結果表示画面の下部には、この支払いに関する連携ウォレットのメンバーごとの内訳を表すメンバー支払い結果表示領域ＭＲＲ１が表示されている。
メンバー支払い結果表示領域ＭＲＲ１には、メンバーごとに、支払ったユーザ名と、支払い余力として支払った金額と、支払い後の電子マネー口座残高とが表示されている。

メンバー支払い結果表示領域ＭＲＲ１には、限定ではなく例として、ユーザＡ．Ａは、支払い余力「１，０００円」分を支払い、その結果、電子マネー口座残高が「０円」となったことが表示されている。また、ユーザＢ．Ｂは、支払い余力「１，５００円」分を支払い、その結果、電子マネー口座残高が「１，５００円」となったことが表示されている。また、ユーザＣ．Ｃは、支払い余力「２，０００円」分を支払い、その結果、電子マネー口座残高が「４，０００円」となったことが表示されている。

また、ユーザＣ．Ｃの項目には、ユーザＡ．ＡがユーザＣ．Ｃに立て替えてもらった「５００円」を返却するための立て替え金額返金ボタンＢＴ６が加えて表示されている。

図４−７右側は、限定ではなく例として、支払いアプリケーションのメインメニューから「おしらせ」アイコンをタップすることで遷移するおしらせ画面の一例である。なお、おしらせ画面へは、連携支払い結果表示画面に重ねて表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。

連携決済結果情報ＣＴ２には、ユーザＡ．Ａが支払った金額である「１，０００円」と、支払い日時と、連携ウォレットを用いて支払いが完了したことと、支払い先が「ＸＸ楽器」であることとが表示されている。また、右上には、連携ウォレットを適用したグループ「バンド仲間」のアイコンが表示されている。
連携決済結果情報ＣＴ２の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図４−７左側の連携支払い結果表示画面が表示される。

なお、連携決済結果情報ＣＴ２には、ユーザＡ．Ａが支払った金額である「１，０００円」ではなく、「ＸＸ楽器」に支払った総支払い金額である「４，５００円」を表示するようにしてもよいし、そのようにしなくてもよい。もしくは、ユーザＡ．Ａが支払った金額と、総支払い金額の両方を表示するようにしてもよいし、そのようにしなくてもよい。他のユーザが支払った金額を加えて表示するようにしてもよいし、そのようにしなくてもよい。

立て替え情報ＣＴ３には、連携ウォレットを用いた支払いでユーザＣ．Ｃに「５００円」を立て替えてもらったことを示す表示が表示されている。また、右上には、連携ウォレットを適用したグループ「バンド仲間」のアイコンが表示されている。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図４−７左側の連携支払い結果表示画面が表示される。
立て替え情報ＣＴ３の下部には、ユーザＡ．ＡがユーザＣ．Ｃに立て替えてもらった「５００円」を返却するための立て替え金額返金ボタンＢＴ６が表示されている。

立て替え金額返金ボタンＢＴ６がタップされると、ユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座へ立替分「５００円」の送金が実行される。なお、ユーザＡ．Ａの電子マネー口座残高が立替分に満たず、送金が実行できない場合、立て替え金額返金ボタンＢＴ６の表示態様をグレーアウトさせるなどしてボタン操作を無効化させてもよいし、そのようにしなくてもよい。また、ユーザＡ．Ａの電子マネー口座残高が立替分に満たない状態で立て替え金額返金ボタンＢＴ６がタップされると、銀行口座からのチャージを促す画面へ遷移してもよいし、そのようにしなくてもよい。

図４−８は、図４−６右側の連携支払い確認画面において、連携支払い実行ボタンＢＴ５がタップされた場合の、端末２０Ｃにおける画面の遷移の一例である。

図４−８左側は、限定ではなく例として、支払いアプリケーションのメインメニューから「おしらせ」アイコンをタップすることで遷移するおしらせ画面の一例である。なお、おしらせ画面へは、端末２０Ｃに送信され、表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。

このおしらせ画面のおしらせ情報表示領域ＮＴＲ４には、連携支払いが実行されたことに基づく連携決済結果情報ＣＴ４と、連携支払いで立て替えが発生したことに基づく立て替え情報ＣＴ５とが表示されている。

連携決済結果情報ＣＴ４には、ユーザＣ．Ｃが支払った金額である「２，０００円」と、支払い日時と、連携ウォレットを用いて支払いが完了したことと、支払い先が「ＸＸ楽器」であることとが表示されている。また、右上には、連携ウォレットを適用したグループ「バンド仲間」のアイコンが表示されている。
連携決済結果情報ＣＴ４の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図４−８右側の連携支払い結果表示画面が表示される。

立て替え情報ＣＴ５には、連携ウォレットを用いた支払いでユーザＡ．Ａに「５００円」を立て替えたことを示す表示が表示されている。また、右上には、連携ウォレットを適用したグループ「バンド仲間」のアイコンが表示されている。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図４−８右側の連携支払い結果表示画面が表示される。
立て替え情報ＣＴ５の下部には、ユーザＣ．ＣがユーザＡ．Ａに立て替えた「５００円」の返金を請求するための立て替え金額請求ボタンＢＴ７が表示されている。

図４−８右側は、端末２０Ｃに表示される連携支払い結果表示画面の一例である。
この画面では、メンバー支払い結果表示領域ＭＲＲ２において、立て替え金額返金ボタンＢＴ６の代わりに、ユーザＡ．Ａの項目にユーザＣ．Ｃが立て替えた「５００円」の返却を促すための立て替え金額請求ボタンＢＴ７が加えて表示されている。

立て替え金額請求ボタンＢＴ７がタップされると、端末２０Ａに対して、ユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座へ立替分「５００円」の送金を促す情報が送信され、端末２０Ａの表示部２４に表示される。
なお、ユーザＡ．Ａの電子マネー口座残高が立替分より大きい場合、自動的にユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座への立替分の送金が実行されるようにしてもよいし、そのようにしなくてもよい。

＜処理＞
本実施例における処理については、限定ではなく例として、連携ウォレットを用いて支払いを行うグループメンバーの端末２０を端末２０Ａの処理に、それ以外のグループメンバーの端末２０を端末２０Ｂの処理にそれぞれ当てはめて、図３−４〜図３−５と同様に実現可能であるため、再度の説明は省略する。

＜第４実施例の効果＞
本実施例は、アカウント連携決済は、支払いを行うグループメンバーの第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、他のグループメンバーの第２ユーザアカウント（限定ではなく、第２アカウントの一例）と、これら以外のグループメンバーの第４ユーザアカウント（限定ではなく、第１アカウントおよび第２アカウントと連携した第４アカウントの一例）とによって行われる構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントばかりでなく、第１アカウントと第２アカウントとが関連付けられた第４アカウントによっても支払いが行われるようにすることができる。

また、上記において、第１ユーザアカウントの不足分の支払いは、少なくとも第２ユーザアカウントと、第４ユーザアカウントとによって行われるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１アカウントの不足分の支払いが、複数のアカウントによって行われるようにすることができる。

また、上記において、第１ユーザアカウントの不足分の支払いは、第２ユーザアカウントのみによって行われるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１アカウントの不足分の支払いが、第４アカウントは用いずに、第２アカウントのみによって行われるようにすることができる。

また、上記において、第１ユーザアカウントの不足分を支払う第２ユーザアカウントは、第２ユーザアカウントの電子マネー口座残高に基づいて決定されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１アカウントの不足分を支払う第２アカウントを、第２アカウントの残高に基づいて決定することができる。限定ではなく例として、残高が最も多い第２アカウントを、第１アカウントの不足分を支払い第２アカウントに決定することができる。

また、上記において、第１ユーザアカウントの不足分を支払う第２ユーザアカウントは、第１ユーザによる端末に対する入力に基づき選択されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、第１アカウントの不足分を支払う第２アカウントを、第１ユーザによる端末に対する入力という簡単な方法で選択することができる。

＜第４変形例（１）＞
第４実施例では、他の連携アカウントによって不足分を立て替えてもらう場合、立て替えを行うアカウントのユーザに承認を求めることなく連携残高補充処理が実行されることとしたが、これに限定されない。限定ではなく例として、不足分の立て替えが必要な場合には、立て替えを行うアカウントのユーザの承認が必要であるようにしてもよいし、そのようにしなくてもよい。

＜表示画面＞
図４−９は、上記の例において、立て替えに相手の承認を必要とする場合の端末２０における表示画面の遷移の一例を示す図である。
この図は、図４−６中央→図４−６右側に遷移する過程で、立て替えを行うユーザＣ．Ｃの承認を得ることを要している。具体的には、図４−９左側の端末２０Ａの表示部２４に表示される画面において、立て替えを依頼するメンバーとしてユーザＣ．Ｃが選択されると、端末２０Ｃの表示部２４には、図４−９中央に示すようなお知らせ画面が表示される。このお知らせ画面には、ユーザＡ．Ａから立て替えの依頼があったことを示す立て替え依頼情報が表示されている。

立て替え依頼情報には、立て替えの詳細に関する情報に加えて、限定ではなく例として、立て替えを承認するための承認ボタンＢＴａと、立て替えを拒否するための拒否ボタンＢＴｂとが含まれる。承認ボタンＢＴａがタップされると、承認されたことを示す情報が端末２０Ｃからサーバ１０に送信され、立て替えに関する処理が実行される。その結果、端末２０Ａの表示部２４には、図４−６右側と同様の画面として、図４−９右側に示す画面が表示される。

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

通信Ｉ／Ｆ１４によって端末２０Ａから残高補充要求情報を受信すると、サーバ１０の制御部１１は、ユーザＡ．Ａの支払い余力の不足分を負担するユーザ（限定ではなく例として、ユーザＢ．Ｂ）の端末（限定ではなく例として、端末２０Ｂ）に、支払い余力の不足分の補充を依頼するための残高補充依頼情報を、通信Ｉ／Ｆ１４によって送信する（Ｓ２２４）。

通信Ｉ／Ｆ２２によってサーバ１０から残高補充依頼情報を受信する場合（Ｂ１５０：ＹＥＳ）、端末２０Ｂの制御部２１は、ユーザＡ．Ａの支払い余力の不足分を負担するか否かの選択用画面を表示部２４に表示させる（Ｂ１６０）。

端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、不足分を負担することが選択される場合（Ｂ１６０：ＹＥＳ）、端末２０Ｂの制御部２１は、不足分の負担を認可する残高補充認可情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１７０）。

残高補充依頼情報を受信しない場合には（Ｂ１５０：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ１６０のステップとＢ１７０のステップとをスキップする。また、不足分を負担しないことが選択される場合（Ｂ１６０：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ１７０のステップをスキップする。

通信Ｉ／Ｆ１４によって端末２０Ｂから残高補充認可情報を受信する場合（Ｓ２２６：ＹＥＳ）、サーバ１０の制御部１１は、受信した残高補充要求情報に基づいて、連携残高補充処理を実行する（Ｓ２３０）。残高補充認可情報を受信しない場合には、サーバ１０の制御部１１は、Ｓ２３０のステップを実行しない。

図４−１１のステップが実行されると、図３−５の各ステップの処理が続いて実行される。

本変形例は、第１ユーザアカウントの不足分を支払う第２ユーザアカウントは、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）による自己の端末２０に対する入力に基づき第２ユーザアカウントが選択された後、第２ユーザアカウントの第２ユーザの許可に基づいて決定される構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザによる端末に対する入力に基づいて第２アカウントが選択された場合であっても、限定ではなく例として、第２アカウントの第２ユーザの許可がなければ、その第２アカウントが第１アカウントの不足分を支払う第２アカウントに決定されないようにすることができる。その結果、第２ユーザの意に反して、第２アカウントから第１アカウントの不足分が支払われることを防止することができる。

＜第４変形例（２）＞
第４実施例で説明したように、グループに含まれる全てのグループメンバーを連携メンバーとしてもよいが、グループに含まれる一部のグループメンバーを連携メンバーとすることもできる。つまり、同じグループ内で、アカウント連携決済に参加するグループメンバーと、アカウント連携決済に参加しないグループメンバーとを分けることもできる。
これは、同じグループに属していても、ユーザによっては、アカウント連携決済への参加を希望しない場合も想定されるためである。

このような構成により得られる変形例の効果の一例として、複数のアカウントを連携させて決済を行うユーザを選別することが可能となるため、ユーザの利便性を向上させることができる。

＜第５実施例＞
第４実施例では、アカウント連携決済の際に、支払い余力が不足する連携メンバーが一人（または支払い余力が不足する連携アカウントが１つ）として説明した。しかし、これは一例に過ぎない。
本実施例では、アカウント連携決済の実行時に、複数の連携メンバー（または複数の連携アカウント）の支払い余力が不足する場合について説明する。

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

＜表示画面＞
図５−１は、本実施例において端末２０Ａの表示部２４に表示される表示画面の遷移の一例を示す図である。連携ウォレットを用いたコード支払いが実行された場合における連携支払い確認画面の画面の遷移の一例を示している。

図５−１は、図４−５右側の画面において支払いボタンＢＴ１がタップされた場合の画面図である。ただし、この例では、ユーザＢ．Ｂの電子マネー口座残高を「５００円」として説明する。

図５−１左側には、連携支払い確認画面として、限定ではなく例として、現在位置表示領域ＣＬＲ１の下に、支払い金額確認領域ＰＩＲ３が表示されている。支払い金額確認領域ＰＩＲ３の支払い金額の下には、現在の連携支払い可能額である「３，０００円」が表示されている。また、支払い金額確認領域ＰＩＲ３には、現在の連携支払い可能額が支払い金額を下回ることに基づいて、警告マークと「残高不足です」の文字とが表示されている。

支払いメンバー確認領域ＰＭＲ３には、ユーザＡ．ＡおよびユーザＢ．Ｂのアイコンの左上に警告マークが表示され、支払い余力がそれぞれ「１，０００円」と「５００円」であることが示されている。

連携支払い確認画面の最下部には、等分支払い金額「１，５００円」のうち、ユーザＡ．Ａの支払い余力「１，０００円」では不足する立て替え必要額「１，５００円−１，０００円＝５００円」と、ユーザＢ．Ｂの支払い余力「５００円」では不足する立て替え必要額「１，５００円−５００円＝１，０００円」とをユーザＡ．ＡおよびユーザＢ．Ｂ以外の他のメンバーに立て替えてもらい、支払いを実行するための立て替え依頼ボタンＢＴ４が表示されている。

図５−１中央は、立て替え依頼ボタンＢＴ４がタップされた場合の、連携支払い確認画面の一例である。
この画面では、支払いメンバー確認領域ＰＭＲ３の代わりに、立替メンバー選択領域ＰＳＲ３が表示されている。

立替メンバー選択領域ＰＳＲ３には、立替者の選択をユーザに促す「立て替えてもらうメンバーを選んでください」の文字の下に、等分支払い金額「１，５００円」に立て替え必要額「５００円」および「１，０００円」を加算した「３，０００円」を負担可能なメンバーとして、ユーザＣ．Ｃが表示されている。

ユーザＣ．Ｃがタップされ、立替者として選択されると、図５−１右側の連携支払い確認画面に表示が遷移する。
この画面では、支払いメンバー確認領域ＰＭＲ３において、ユーザＣ．Ｃの支払い余力が等分支払い金額「１，５００円」に立て替え必要額の合計額「１，５００円」を加算した「３，０００円」に増加している。それに伴い、支払い金額確認領域ＰＩＲ３の連携支払い可能額は「４，５００円」に増加し、「残高不足です」の文字が消え、代わりに「支払い可能です」の文字が表示されている。
また、連携支払い確認画面の最下部には、連携支払い実行ボタンＢＴ１４が表示されている。

図５−２に、図５−１右側の連携支払い確認画面において、連携支払い実行ボタンＢＴ１４がタップされた場合の各端末における連携支払い結果表示画面の一例を示す。

これらの連携支払い結果表示画面のメンバー支払い結果表示領域には、限定ではなく例として、ユーザＡ．Ａは、支払い余力「１，０００円」分を支払い、その結果、電子マネー口座残高が「０円」となっていることが表示されている。そして、ユーザＢ．Ｂは、支払い余力「５００円」分を支払い、その結果、電子マネー口座残高が「０円」となっていることが表示されている。また、ユーザＣ．Ｃは、支払い余力「３，０００円」分を支払い、その結果、電子マネー口座残高が「３，０００円」となっていることが表示されている。

端末２０Ａのメンバー支払い結果表示領域ＭＲＲ５には、ユーザＣ．Ｃの項目に、ユーザＡ．ＡがユーザＣ．Ｃに立て替えてもらった「５００円」を返却するための立て替え金額返金ボタンＢＴ１５が表示されている。
端末２０Ｂのメンバー支払い結果表示領域ＭＲＲ６には、ユーザＣ．Ｃの項目に、ユーザＢ．ＢがユーザＣ．Ｃに立て替えてもらった「１，０００円」を返却するための立て替え金額返金ボタンＢＴ１６が表示されている。
端末２０Ｃのメンバー支払い結果表示領域ＭＲＲ７には、ユーザＡ．Ａの項目にユーザＣ．ＣがユーザＡ．Ａに立て替えた「５００円」の返却を請求するための立て替え金額請求ボタンＢＴ１７が、ユーザＢ．Ｂの項目にユーザＣ．ＣがユーザＢ．Ｂに立て替えた「１，０００円」の返却を請求するための立て替え金額請求ボタンＢＴ１８が、それぞれ表示されている。

各立て替え金額返金ボタンと、立て替え金額請求ボタンとの機能は、立て替え金額返金ボタンＢＴ６および立て替え金額請求ボタンＢＴ７と同様に構成可能である。

図５−３は、図５−１右側の連携支払い確認画面において、連携支払い実行ボタンＢＴ１４がタップされた場合の各端末における連携支払い結果表示画面の別例である。

図５−３では、端末２０Ａのメンバー支払い結果表示領域ＭＲＲ５には、ユーザＣ．Ｃの項目に、ユーザＡ．ＡとユーザＢ．ＢとがユーザＣ．Ｃに立て替えてもらった「１，５００円」を返却するための立て替え金額返金ボタンＢＴ２０が表示されている。また、ユーザＢ．Ｂの項目に、ユーザＡ．ＡがユーザＢ．Ｂに立て替えた「１，０００円」の返却を請求するための立て替え金額請求ボタンＢＴ１９が表示されている。

また、端末２０Ｂのメンバー支払い結果表示領域ＭＲＲ６には、ユーザＡ．Ａの項目に、ユーザＢ．ＢがユーザＡ．Ａに立て替えてもらった「１，０００円」を返却するための立て替え金額返金ボタンＢＴ２１が表示されている。

端末２０Ｃのメンバー支払い結果表示領域ＭＲＲ７には、ユーザＡ．Ａの項目に、ユーザＣ．ＣがユーザＡ．Ａに立て替えた「１，５００円」の返却を請求するための立て替え金額請求ボタンＢＴ２２が表示されている。

＜処理＞
本実施例における処理については、限定ではなく例として、残高補充要求情報を、複数のアカウントの支払い余力の不足分を立て替える場合の情報として、図３−４〜図３−５の処理を適用することによって同様に実現可能であるため、再度の説明は省略する。

＜第５変形例（１）＞
第５実施例では、連携メンバーの一人が、他の複数の連携メンバーで発生した支払い余力の不足分を立て替えることとしたが、これに限定されない。
限定ではなく例として、複数の連携メンバーで発生した支払い余力の不足分を、複数の連携メンバーで分散して立て替えることとしてもよいし、そのようにしなくてもよい。
また、複数の連携アカウントで発生した支払い余力の不足分を複数の連携アカウントで立て替えることとしてもよいし、そのようにしなくてもよい。

＜第６実施例＞
第１実施例〜第５実施例では、アカウント連携決済を店舗提示型のコード決済によって実現する手法について説明した。しかし、これは一例に過ぎない。
第６実施例では、アカウント連携決済を利用者提示型のコード決済によって実現する手法について説明する。

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

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

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

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

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

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

コードリーダ５８は、一次元コード（一次元コード画像）や二次元コード（二次元コード画像）、限定ではなく例として、後述する支払いコード（支払いコード画像）を読み取るためのコードリーダである。

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

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

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

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

＜表示画面＞
図６−３は、アカウント連携決済を「利用者提示型」の決済によって実現する場合の端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図６−３左側は、図４−５左側の画面に対応している。この画面においてコード支払いアイコンＩＣ３がタップされると、端末２０Ａの表示部２４には、図６−３中央に示すようなコード支払い画面が表示される。

このコード支払い画面には、グループ「バンド仲間」でアカウント連携決済を行うためのコード（コード情報）として、サーバ１０から送信されて端末２０Ａが受信したコードであって、「利用者提示型」で決済を行うために用いられるコードである連携ウォレット支払いコードが表示されている。具体的には、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコードとが表示されている。端末２０ＡのユーザＡ．Ａは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことで連携ウォレットを用いたコード支払いを行うことが可能である。

図６−３右側は、上記において、ユーザＡ．Ａの支払い余力が不足していることに基づいて端末２０Ａの表示部２４に表示される画面であり、限定ではなく例として、図４−６左側の画面と同様である。

＜処理＞
図６−４に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理、店舗コードリーダ装置５０の制御部５１が実行する処理の一例を示している。

サーバ１０の制御部１１は、連携ウォレット支払いトークンを生成する。そして、サーバ１０の制御部１１は、この連携ウォレット支払いトークンを含むコード情報である連携ウォレットコード情報を生成する。連携ウォレットコード情報は、限定ではなく例として、連携ウォレット支払いトークンの識別子を一次元コード（バーコード等）や二次元コード（ＱＲコード等）としてエンコードした支払いコード（画像情報）を含む。

その後、サーバ１０の制御部１１は、生成した連携ウォレットコード情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ１０５）。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレットコード情報を受信すると、端末２０Ａの制御部２１は、受信した連携ウォレットコード情報を表示部２４に表示させる（Ａ１０５）。具体的には、連携ウォレットコード情報として、限定ではなく例として、支払いコードを表示部２４に表示させる。

なお、連携ウォレット支払いトークンの識別子や有効期限を連携ウォレットコード情報に含める場合、端末２０Ａの制御部２１は、識別子や有効期限を表示させてもよいし、表示させなくてもよい。

また、支払いコードの表示中に連携ウォレット支払いトークンの有効期限が切れる場合、端末２０Ａの制御部２１は、連携ウォレット支払いトークンの再生成を要請する情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信してもよいし、そのようにしなくてもよい。
この場合、サーバ１０の制御部２１は、連携ウォレット支払いトークンと、連携ウォレットコード情報とを再生成し、連携ウォレットコード情報を通信Ｉ／Ｆ１４によって端末２０Ａに送信する。そして、通信Ｉ／Ｆ２２によってサーバ１０から再生成された連携ウォレットコード情報を受信すると、端末２０Ａの制御部２１は、支払いコードと、有効期限とを表示部２４に再表示させるようにすることができる。

店舗コードリーダ装置５０の制御部５１は店舗決済処理を実行し、店舗コードリーダ装置５０の入出力部５２に対する操作に基づいて、所定の決済予定金額（限定ではなく例として「４，５００円」）が制御部５１へ入力される。そして、店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末２０Ａの表示部２４に表示される支払いコードを読み取る（Ｐ１００）。この場合、表示部２４に表示される支払いコードは、連携ウォレット支払いトークンと関連付けられているため、コードリーダ５８の読み取り結果には、支払いトークンとして連携ウォレット支払いトークンが含まれる。

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

通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から連携決済要求情報を受信すると、サーバ１０の制御部１１は、連携支払い可能額を算出し、算出された連携支払い可能額が決済予定金額を下回っているか否か（連携支払い可能額−決済予定金額＜０であるか否か）を判定する（Ｓ２１５）。

連携支払い可能額−決済予定金額≧０である場合（Ｓ２１５：ＮＯ）、サーバ１０の制御部１１は、要求を受けた連携ウォレット支払いトークンから連携ウォレットＩＤを検索し、その連携ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う、利用者提示型のアカウント連携決済処理の一例である利用者提示型連携決済処理を実行する（Ｓ１１５）。

利用者提示型連携決済処理は、店舗提示型連携決済処理と同様の処理である。
ただし、利用者提示型連携決済処理では、サーバ１０の制御部１１は、連携ウォレットによる決済予定金額の支払いが成功したか否かの決済結果についての決済結果情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信する点が異なる。

連携支払い可能額−決済予定金額＜０である場合（Ｓ２１５：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ２２０のステップとＳ２３０のステップとを実行した後、Ｓ１１５のステップを実行する。

Ｓ１１５のステップを実行すると、サーバ１０の制御部１１は、Ｓ２４０のステップを実行する。

通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信すると、店舗コードリーダ装置５０の制御部５１は、表示部５３に決済結果情報を表示させ、処理を終了させる。

本実施例は、端末２０は、第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、第１ユーザアカウントと連携した第２ユーザアカウント（限定ではなく、第１アカウントと関連付けられた第２アカウントの一例）とに基づき、アカウント連携決済に関する処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う。
また、アカウント連携決済に基づいて、端末２０は、送金依頼情報（限定ではなく、第２アカウントに送金することに関する第１情報の一例）を通信Ｉ／Ｆ２２によって受信する。
そして、端末２０は、受信した送金依頼情報の表示（限定ではなく、第１情報に基づく第１表示の一例）を表示部２４に表示する。
この場合、端末２０は、第１ユーザアカウントと第２ユーザアカウントとに基づきアカウント連携決済を行うための連携ウォレットコード情報（限定ではなく、コード情報の一例）を通信Ｉ／Ｆ２２によってサーバ１０から受信し、受信した連携ウォレットコード情報を表示部２４に表示する。そして、表示部２４に表示された連携ウォレットコード情報が店舗コードリーダ装置に読み取られることに基づいて、サーバ１０によってアカウント連携決済が行われる構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第１ユーザの第１アカウントと、第１アカウントと関連付けられた第２アカウントとに基づき、第１ユーザの端末によって第１決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも２つのアカウントによる第１決済を実現することができる。また、第１決済により第２アカウントに送金することに関する第１情報を、端末の第１ユーザに知らせることができる。その結果、限定ではなく例として、第２アカウントに送金するように、第１ユーザに促すことができる。また、第１アカウントと第２アカウントとに基づき第１決済を行うためのコード情報を店舗のコードリーダに読み取らせるといった簡単な方法によって、第１決済を実現することができる。

＜第７実施例＞
第１実施例〜第６実施例では、アカウント連携決済に基づいて、都度送金を促す手法について説明したが、これに限定されない。
第７実施例では、複数のアカウント連携決済に基づいて、発生した立て替えをまとめて精算する手法について説明する。また、これに関連して、連携ウォレットを破棄する手法について説明する。

「連携ウォレットの破棄」とは、連携ウォレットを以後使用できないようにすること、全ての連携アカウントについて一括して連携ウォレットを無効化することを意味する。

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

図７−１は、本実施例において用いられる連携ウォレット管理データベース１５７の一例である第３の連携ウォレット管理データベース１５７Ｃのデータ構成例を示す図である。
第３の連携ウォレット管理データベース１５７Ｃには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、決済履歴データと、立替履歴データとが記憶される。

グループＩＤと、グループ名と、決済履歴データとについては、第２の連携ウォレット管理データベース１５７Ｂと同様である。

立替履歴データは、決済履歴データに記憶された各々の取引において生じた金銭の立替に関するデータであり、限定ではなく例として、取引ＩＤと、被立替者ＩＤと、立替者ＩＤと、立替金額とが関連付けて記憶される。

取引ＩＤには、決済履歴データに含まれる取引ＩＤのうち、その取引に際して金銭の立替が行われた取引ＩＤが記憶される。

被立替者ＩＤには、金銭を立て替えてもらったユーザアカウント（以下、「被立替者」と称する。）のアプリケーションＩＤが記憶される。

立替者ＩＤには、金銭を立て替えたユーザアカウント（以下、「立替者」と称する。）のアプリケーションＩＤが記憶される。

立替金額には、立替者が立て替えた金銭の額（以下、「立替金額」と称する。）が記憶される。

＜表示画面＞
図７−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図７−２左側は、図４−５左側と同様の連携ウォレットのメイン画面であるが、その表示が一部異なっている。具体的には、グループ「バンド仲間」の連携ウォレットであることを表示する領域内に、グループ「バンド仲間」の連携ウォレットで行った決済の履歴を表示するための履歴ボタンＢＴ２５が表示されている。

履歴ボタンＢＴ２５がタップされると、図７−２中央の画面に遷移する。
この画面には、グループ「バンド仲間」の連携ウォレットで行った決済に関する情報として、商品やサービスの購入履歴に関する情報が表示されている。この例では、「ＸＸ楽器」と「ＹＹスタジオ」との２つの購入履歴に関する情報が表示されており、各々の購入履歴には、チェックボックスが関連付けて設けられている。精算を希望する購入履歴のチェックボックスにチェックを入れた状態で、画面下部の一括精算ボタンＢＴ２６がタップされると、チェックが入れられた購入履歴を、まとめて精算することが可能である。

また、画面最下部には、連携ウォレットを破棄するための「連携ウォレット破棄」の文字を含む連携ウォレット破棄ボタンＢＴ３０が設けられている。この連携ウォレット破棄ボタンＢＴ３０がタップされると、サーバ１０によって、連携ウォレット破棄処理が行われる。

なお、連携ウォレット破棄処理において、連携ウォレット管理データベース１５７から連携ウォレットのデータを削除しないが、破棄された連携ウォレットに基づくアカウント連携決済の実行を、端末２０側またはサーバ１０側で禁止するようにしてもよいし、しなくてもよい。

図７−２右側は、図７−２中央において、２つの購入履歴にチェックを入れた状態で一括精算ボタンＢＴ２６がタップされたことに基づいて表示される画面の一例を示す図である。
この画面では、図７−２中央の画面の中央部に、一括精算を実行するための一括精算情報がポップアップ形式で表示されている。この例では、一括精算情報には、ユーザＡ．ＡからユーザＢ．Ｂに対して「５００円」を送金し、ユーザＡ．ＡからユーザＣ．Ｃに対して「１，０００円」を送金する必要があることを示すメッセージとともに、この内容を承認して一括精算するための「はい」のボタンと、一括精算をやめるための「いいえ」のボタンとが表示されている。

「はい」のボタンがタップされると、サーバ１０を介して、ユーザＡ．ＡからユーザＢ．Ｂに対する「５００円」の送金と、ユーザＡ．ＡからユーザＣ．Ｃに対する「１，０００円」の送金とが実行される。

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

サーバ１０の制御部１１は、連携残高補充処理を実行すると（Ｓ２３０）、連携残高補充処理において発生した立て替え必要額の立て替えを、立替履歴データに追加して記憶させる（Ｓ２３５）。

Ａ２３０、Ｂ２００、Ｓ２４０の各ステップが実行されると、端末２０Ａと、端末２０Ｂと、サーバ１０とは、連携ウォレット精算処理を実行する。

図７−５は、連携ウォレット精算処理の処理の流れの一例を示すフローチャートである。
連携ウォレット精算処理において、まず、サーバ１０の制御部１１は、第３の連携ウォレット管理データベース１５７Ｃを参照し、連携ウォレット管理データの立替履歴データに、立替履歴が記録されているか否かを判定する（Ｓ４００）。
立替履歴データに立替履歴が記録されていない場合（Ｓ４００：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

一方、立替履歴が記録されている場合（Ｓ４００：ＹＥＳ）、サーバ１０の制御部１１は、立替履歴データの内容を含む立替履歴情報を、通信Ｉ／Ｆ１４によって連携メンバーの端末である端末２０Ａと端末２０Ｂとにそれぞれ送信する（Ｓ４１０）。

通信Ｉ／Ｆ２２によってサーバ１０から立替履歴情報を受信する場合（Ａ４００：ＹＥＳ）、端末２０Ａの制御部２１は、受信した立替履歴情報を表示部２４に表示させる（Ａ４１０）。立替履歴情報を受信しない場合（Ａ４００：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

端末２０Ａの入出力部２３に対するユーザ操作に基づいて、立替履歴情報の披立替者ＩＤが自端末のユーザアカウントとなる立替履歴の中から、１以上の取引履歴が選択され、立替金額を立替者ＩＤのユーザアカウントへ返却することが選択される場合（Ａ４２０：ＹＥＳ）、端末２０Ａの制御部２１は、それらの立替履歴の取引ＩＤを含む連携ウォレット精算依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ４３０）。

なお、Ａ４２０，Ａ４３０のステップにおいて、立替履歴情報の立替者ＩＤが自端末のユーザアカウントとなる立替履歴の中から、１以上の取引履歴が選択され、立替金額の返還請求を披立替者ＩＤのユーザアカウントのユーザへ請求することを含む連携ウォレット精算依頼情報を生成して送信するようにしてもよいし、そのようにしなくてもよい。
また、連携ウォレット精算依頼情報として、立替者ＩＤのユーザアカウントへの立替金額の返却と、披立替者ＩＤのユーザアカウントへの立替金額の請求とを含ませるようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ１４によって端末２０Ａから連携ウォレット精算依頼情報を受信する場合（Ｓ４２０：ＹＥＳ）、サーバ１０の制御部１１は、連携ウォレット精算処理を実行する（Ｓ４３０）。

連携ウォレット精算処理では、受信した連携ウォレット精算依頼情報に基づいて、選択された各取引ＩＤの立替金額について、披立替者ＩＤのアカウントから立替者ＩＤのアカウントへの送金を実行する。
なお、立替金額の請求については、披立替者ＩＤのアカウントの端末に対して、送金を促す旨のメッセージを含む情報を送信するようにすればよい。

連携ウォレット精算処理を実行すると、サーバ１０の制御部１１は、連携ウォレット精算の処理結果である連携ウォレット精算結果情報を、限定ではなく例として、精算を行った立替履歴の披立替者ＩＤ・立替者ＩＤのアカウントの端末に送信する（Ｓ４４０）。
なお、連携メンバーの全ての端末に対して、精算を行った立替履歴に関する送金結果等を送信するようにしてもよいし、そのようにしなくてもよい。

そして、サーバ１０の制御部１１は、処理を終了させる。
連携ウォレット精算依頼情報を受信しない場合には（Ｓ４２０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット精算結果情報を受信する場合（Ａ４４０：ＹＥＳ）、端末２０Ａの制御部２１は、受信した連携ウォレット精算結果情報を表示部２４に表示させ（Ａ４５０）、処理を終了させる。
連携ウォレット精算結果情報を受信しない場合には（Ａ４４０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

端末２０Ｂおよび、他の連携メンバーの端末についての処理は、端末２０Ａと同様である。

連携ウォレット精算処理を実行後、端末２０Ａの制御部２１は、この連携ウォレットを破棄するか否かの選択用画面を表示させる（Ａ３１０）。端末２０Ａの入出力部２３に対するユーザ操作に基づいて、連携ウォレットを破棄することが選択される場合（Ａ３１０：ＹＥＳ）、端末２０Ａの制御部２１は、連携ウォレットの破棄を要求する連携ウォレット破棄要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信し（Ａ３２０）、連携ウォレット精算処理を実行する（Ａ３３０）。

連携ウォレットを破棄しないことが選択される場合（Ａ３１０：ＮＯ）、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット精算要求情報を受信するか否かを判定し（Ａ３４０）、受信する場合（Ａ３４０：ＹＥＳ）、連携ウォレット精算処理を実行する（Ａ３３０）。受信しない場合には（Ａ３４０：ＮＯ）、Ａ１００のステップへ処理を移す。

連携ウォレット精算処理を実行後、通信Ｉ／Ｆ１４によって連携メンバーの端末から連携ウォレット破棄要求情報を受信する場合（Ｓ３１０：ＹＥＳ）、サーバ１０の制御部１１は、連携ウォレット精算要求情報を通信Ｉ／Ｆ１４によって連携メンバーの各端末に送信し（Ｓ３２０）、連携ウォレット精算処理を実行する（Ｓ３３０）。

なお、連携ウォレット破棄要求情報を受信しない場合には（Ｓ３１０：ＮＯ）、サーバ１０の制御部１１は、Ｓ１００のステップへ処理を移す。

連携ウォレット精算処理を実行した後、サーバ１０の制御部１１は、連携ウォレット破棄処理を実行する（Ｓ３４０）。
連携ウォレット破棄処理では、第３の連携ウォレット管理データベース１５７Ｃから、この連携ウォレットの連携ウォレット管理データの各レコードを消去する。なお、連携ウォレット管理データがグループＩＤで識別される場合、グループ管理データベース１５９のグループ管理データのうち、連携ウォレット破棄が選択されたグループＩＤのグループ管理データも消去するようにしてもよいし、そうしなくてもよい。

なお、連携ウォレット破棄処理は、連携ウォレット精算処理後、立替履歴データに未精算の立替履歴が残っている場合には実行されないようにしてもよいし、立替履歴が残っていても実行できるようにしてもよい。

連携ウォレット廃棄処理が実行されると、サーバ１０の制御部１１は、連携ウォレットが廃棄され、使用ができなくなった旨を含む連携ウォレット破棄情報を、通信Ｉ／Ｆ１４によって連携メンバーの各端末に送信し（Ｓ３５０）、処理を終了させる。

連携ウォレット精算処理を実行した後、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット破棄情報を受信すると、受信した連携ウォレット破棄情報を表示部２４に表示させる（Ａ３５０）。その後、端末２０Ａの制御部２１は、処理を終了させる。

端末２０Ｂの処理については、Ｂ３００のステップ以降、端末２０Ａと同様であるため、再度の説明を省略する。

＜第７実施例の効果＞
本実施例は、端末２０は、第１ユーザアカウントと、第２ユーザアカウントとは異なる、第１ユーザアカウントに関連付けられた第３ユーザアカウントとに基づき、決済（限定ではなく、第３決済の一例）に関する処理を制御部２１によって行う。また、端末２０は、この決済に基づいて、第３ユーザアカウントに送金することに関する第３情報を通信Ｉ／Ｆ２２によって受信し、受信した第３情報に基づく第３表示を表示部２４に表示する。
そして、端末２０は、第１表示と第３表示とに対する端末２０のユーザによる入力に基づいて、第１情報に基づく金額を、第１ユーザアカウントから第２ユーザアカウントに送金することに関する処理を制御部２１によって行い、第３情報に基づく金額を、第１ユーザアカウントから第３ユーザアカウントに送金することに関する処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第３表示とに対する第１ユーザによる入力という簡単な方法で、第１アカウントから複数のアカウントへの送金を実現することができる。

＜第８実施例＞
第１実施例〜第７実施例では、アカウント連携決済において、ユーザアカウントを連携させる手法について説明したが、これに限定されない。
第８実施例では、共通ウォレットの概念を導入する。そして、この共通ウォレット（共通アカウント）とユーザアカウントとを連携した連携ウォレットで決済を行う。

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

図８−１は、本実施例においてサーバ１０の記憶部１５に記憶される情報等の一例を示す図である。
記憶部１５には、支払いアプリケーション管理処理プログラム１５１と、アカウント登録データ１５３と、アカウント管理データベース１５５と、連携ウォレット管理データベース１５７とに加えて、限定ではなく例として、共通ウォレット管理データベース１６１が記憶される。

ここで、共通ウォレット管理データベース１６１を参照しながら、共通ウォレットについて詳細に説明する。

共通ウォレットとは、支払いアプリケーションを利用する複数のユーザによって、支払いを行う前にあらかじめ設定される電子マネー口座の一形態である。

共通ウォレットでは、設定される複数のユーザがその残高を利用して支払いを行うことが可能である。以下では、共通ウォレットを利用可能なユーザを「共通ウォレットメンバー」と称する。

共通ウォレットを利用するためには、まずユーザが共通ウォレットを生成するための操作を行う。この生成においては、限定ではなく例として、共通ウォレットメンバーの電子マネー口座を特定する情報（限定ではなく例として、アプリケーションＩＤ）を必要とする。

共通ウォレット管理データベース１６１は、サーバ１０が共通ウォレットを管理するためのデータベースであり、その一例のデータ構成例を図８−２に示す。
共通ウォレット管理データベース１６１には、共通ウォレットをユニークに識別するための共通ウォレットＩＤごとの管理データとして、共通ウォレット管理データが記憶される。

各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤとが関連付けて記憶される。

共通ウォレットＩＤは、支払いアプリケーションにおける共通ウォレットのアカウント（以下、適宜「共通アカウント」と称する。）である。
共通ウォレット名は、共通ウォレットＩＤで識別される共通ウォレットの名称である。
共通ウォレット残高は、共通ウォレットＩＤで識別される共通ウォレットを利用して支払いを行う際に用いられる電子マネーの残高である。
共通ウォレットメンバーＩＤは、共通ウォレットの生成時に指定される、共通ウォレットメンバーのアプリケーションＩＤである。

なお、共通ウォレットの生成後に共通ウォレットメンバーＩＤにアプリケーションＩＤを追加することで、新たな共通ウォレットメンバーを追加することも可能である。また、同一のユーザが保有する複数のアプリケーションＩＤを共通ウォレットメンバーＩＤに記憶してもよいし、そうしなくてもよい。

共通ウォレットが生成される場合、その共通ウォレット残高は「０」である。支払いを行う前に、共通ウォレットメンバーは、各々の電子マネー口座から電子マネーを共通ウォレットに送金し、共通ウォレット残高を増加させる。

なお、共通ウォレットメンバーは、支払いサービスに登録する外部金融機関の口座（限定ではなく例として、銀行口座）から、共通ウォレットへチャージする（電子マネーへ変換して送金する）ことも可能である。

共通ウォレットが不要となる場合には、存在する共通ウォレットを取り消すための共通ウォレット破棄操作を行う。共通ウォレット破棄操作が実行されると、共通ウォレット残高を共通ウォレットメンバーの人数で割り勘（均等割り）した額が、共通ウォレットメンバーの各々の電子マネー口座へと送金される。そして、共通ウォレット残高が「０」となった後、共通ウォレット管理データベース１６１からその共通ウォレット管理データのレコードが削除される。

図８−３は、本実施例において用いられる連携ウォレット管理データベース１５７の一例である第４の連携ウォレット管理データベース１５７Ｄのデータ構成例を示す図である。
第４の連携ウォレット管理データベース１５７Ｄには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、連携ウォレットＩＤと、連携アカウントデータと、決済履歴データとが記憶される。
連携ウォレットＩＤと、決済履歴データとは、限定ではなく例として、第１の連携ウォレット管理データベース１５７Ａと同様である。

連携アカウントデータは、アカウント連携決済を行うために連携するアカウントに関するデータであり、限定ではなく例として、ウォレットＩＤと、名称とが記憶される。

ウォレットＩＤは、この連携ウォレットで連携されるユーザアカウントまたは共通ウォレットの識別子であり、ユーザアカウントの場合にはアプリケーションＩＤが、共通ウォレットの場合には共通ウォレットＩＤが、それぞれ記憶される。

名称は、アプリケーションＩＤまたは共通ウォレットＩＤと紐づけられた名称であり、ユーザアカウントの場合にはユーザ名が、共通ウォレットの場合には共通ウォレット名が、それぞれウォレットＩＤと関連付けて記憶される。

なお、連携アカウントデータに記憶されるアカウントの数は、２つに限定されない。３つ以上のアカウントを紐づけてもよいし、そうしなくてもよい。また、共通ウォレットのみを連携させるようにしてもよいし、そのようにしなくてもよい。

すなわち、本実施例では、連携アカウントには、ユーザアカウントと、共通ウォレットのアカウントとが含まれる。

なお、第４実施例で説明したグループを導入し、グループ管理データベース１５９のグループメンバーデータに、共通ウォレットのアカウント情報（共通ウォレットＩＤと共通ウォレット名）を追加できるようにしてもよいし、そのようにしなくてもよい。

＜処理＞
本実施例における処理については、限定ではなく例として、連携アカウントを共通ウォレットとし、共通ウォレットＩＤをアプリケーションＩＤとみなして、図３−４〜図３−５と同様に実現可能であるため、再度の説明は省略する。

ここで、図３−５のＳ２８０のステップにおいて、貸し借り返却処理が実行され、共通ウォレットに対して送金された場合についてより詳しく説明する。

限定ではなく例として、共通ウォレットがユーザＢ．Ｂのアカウントと、ユーザＣ．Ｃのアカウントとで構成されているとする。この場合、共通ウォレットに所定の金額（限定ではなく例として、共通ウォレットが立て替えた返却必要額の全額）が送金されると、共通ウォレットの電子マネーの残高（共通ウォレット残高）から、共通ウォレットメンバーであるユーザＢ．Ｂのアカウントと、ユーザＣ．Ｃのアカウントとに対して、限定ではなく例として、所定の金額の半額ずつが送金されるようにしてもよいし、そうしなくてもよい。

すなわち、共通ウォレットに対して立て替えた必要返却額の返金が実行されると、共通ウォレットメンバーのアカウントに対して、共通ウォレットを経由して返金が行われるようにしてもよいし、そのようにしなくてもよい。

＜第８実施例の効果＞
本実施例は、第２アカウントは、共通ウォレットのアカウント（限定ではなく、複数のユーザが決済可能な共通アカウントの一例）であり、端末２０は、表示部２４に表示した送金推奨額を第１ユーザアカウントから共通ウォレットのアカウントへ送金するか否かの選択用画面の表示（限定ではなく、第１表示の一例）に対する端末２０のユーザによる入力に基づいて、第１ユーザアカウントから共通ウォレットのアカウントに送金するための処理を実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザのアカウントと、複数のユーザが決済可能な共通アカウントとに基づいて決済を行うことができる。
また、第１表示に対する第１ユーザによる入力という簡単な方法で、第１情報に基づく金額を、第１アカウントから共通アカウントに送金することができる。

また、この場合、共通ウォレットのアカウントには、複数のユーザの各々のユーザアカウントが共通ウォレットメンバーのアカウントとして関連付けられており、返金に際して、共通ウォレットのアカウントから、共通ウォレットメンバーの各々のユーザアカウントに対して返却必要額（限定ではなく、第１金額の少なくとも一部である第２金額の一例）が送金されるようにしてもよい。
このような構成により得られる実施例の効果の一例として、共通アカウントとして関連付けられた複数のユーザの各々のアカウントに、共通アカウントから第１金額の少なくとも一部である第２金額が送金されるようにすることができる。
限定ではなく例として、共通アカウントに一定以上の金額が溜まったような場合に、返金可能な金額が第２金額として、共通アカウントから複数のユーザの各々のアカウントに返金されるようにすることができる。

＜第９実施例＞
上記の実施例では、アカウント連携決済において、連携アカウントが、決済予定金額を連携アカウント数で等分した等分支払い金額をそれぞれ負担する（割り勘する）こととして説明したが、これに限定されない。
第９実施例では、割り勘以外の負担分担方法について説明する。

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

限定ではなく例として、連携アカウントとして、ユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃとの３名のアカウントが連携され、連携アカウントを用いて「３，０００円」の支払いを行う場合を考える。また、ユーザＡ．Ａのアカウントの電子マネー口座残高を「４，０００円」、ユーザＡ．Ａのアカウントの電子マネー口座残高を「５００円」、ユーザＡ．Ａのアカウントの電子マネー口座残高を「２，０００円」とする。

図９−１に、この場合に、各連携メンバーの負担額を示した表を図示する。

パターン1は、今までと同じ割り勘の場合である。
この場合、全ての連携メンバーは等しく支払いを負担し、それぞれの負担額は「１，０００円」となる。このとき、ユーザＢ．Ｂは支払い余力が不足するため、支払いが実行できない。

パターン２は、連携アカウントのうち一部のアカウントで負担を行わず、残りの連携アカウントで均等割りを行う場合の例である。
この場合、限定ではなく例として、ユーザＢ．Ｂの負担額を「０」とし、ユーザＡ．ＡとユーザＣ．Ｃとが「３，０００円」を等分して「１，５００円」ずつ支払う。

パターン３は、連携アカウントのうち一部のアカウントで負担を行わず、残りの連携アカウントで傾斜をつけて負担する場合の例である。
限定ではなく例として、ユーザＢ．Ｂの負担額を「０」とし、ユーザＡ．ＡとユーザＣ．Ｃとが「３，０００円」をそれぞれの電子マネー口座残高の割合（ユーザＡ．Ａ：ユーザＣ．Ｃ＝２：１）で負担する。

パターン４は、連携アカウントのうち一部のアカウントで等分支払い金額を負担できない場合、そのアカウントでは電子マネー口座残高全てを支払い、残額を残りの連携アカウントで均等に負担する場合の例である。
限定ではなく例として、ユーザＢ．Ｂは、均等支払い金額「１，０００円」のうち、払える限界である「５００円」を負担し、残りの「２，５００円」をユーザＡ．ＡとユーザＣ．Ｃとで均等割りし負担する。

パターン５は、連携アカウントのうち一部のアカウントで等分支払い金額を負担できない場合、そのアカウントでは電子マネー口座残高全てを支払い、残額を残りの連携アカウントで傾斜をつけて負担する場合の例である。
限定ではなく例として、ユーザＢ．Ｂは、均等支払い金額「１，０００円」のうち、払える限界である「５００円」を負担し、残りの「２，５００円」のうち、電子マネー口座残高の多いユーザＡ．Ａが均等支払い金額「１，０００円」とユーザＢ．Ｂのアカウント不足分に相当する「５００円」との合計額（「１，５００円」）を負担し、ユーザＣ．Ｃは均等支払い金額「１，０００円」を負担する。

これまでの実施例では、支払い金額を均等割りし、その不足分が発生する場合には不足分を立て替えて、返却することについて説明した。
しかし、限定ではなく例として、上記のパターン２〜パターン５のように、支払い金額を連携アカウントで均等に負担するのではなく、負担する割合を変化させて支払いを行うようにすることも可能である。

＜第１０実施例＞
上記の実施例では、アカウント連携決済において、予めアカウント連携が行われている、つまり、アカウント連携済みであるものとして説明したが、これに限定されない。
第１０実施例では、アカウント連携の手法について説明する。

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

図１０−１は、本実施例において用いられる連携ウォレット管理データベース１５７の一例である第５の連携ウォレット管理データベース１５７Ｅのデータ構成例を示す図である。
第５の連携ウォレット管理データベース１５７Ｅには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、連携状況管理データと、決済履歴データと、立替履歴データとが記憶される。グループＩＤと、グループ名と、決済履歴データと、立替履歴データとは、限定ではなく例として、第３の連携ウォレット管理データベース１５７Ｃと同様である。

連携状況管理データは、この連携ウォレットにおけるグループメンバーの各アカウントの連携状況を示すデータである。
連携状況管理データには、限定ではなく例として、アプリケーションＩＤと、ユーザ名と、連携承認とが関連付けて記憶される。

アプリケーションＩＤと、ユーザ名とは、この連携ウォレットに対応するグループメンバーの情報である。

連携承認は、各ユーザ（ユーザアカウント）が、この連携ウォレットを用いて支払いを行うことを承認しているか否かを判別するためのフラグであり、限定ではなく例として、承認している場合には「済」が、承認をしていない場合には「未」が記憶される。
以下では、ユーザ（ユーザアカウント）が、連携ウォレットを用いて支払いを行うことを承認することを「連携承認する」と表現する場合がある。

「連携アカウント」は、限定ではなく例として、連携承認の有無に関わらず、連携ウォレットの連携候補となっているアカウントとすることができる。
同様に、「連携メンバー」は、限定ではなく例として、連携承認の有無に関わらず、連携ウォレットの連携候補となっているユーザとすることができる。

なお、これに限定されず、連携承認されて連携承認済みとなったアカウントのことを「連携アカウント」と定義してもよいし、そのようにしなくてもよい。
同様に、連携承認されて連携承認済みとなったユーザのことを「連携メンバー」と定義してもよいし、そのようにしなくてもよい。

＜表示画面＞
図１０−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１０−２左側は、グループ選択画面の一例であり、現在位置表示領域ＣＬＲ１には、連携ウォレットの機能を利用中であることを示す「連携ウォレット」の文字が表示され、その下に、ウォレット連携を行うグループを選択することをユーザに促す「グループを選択してください」の文字が表示されている。

限定ではなく例として、ウォレット連携を行うグループとして、グループ「バンド仲間」がタップされると、限定ではなく例として、図１０−２中央に示すようなグループ情報表示画面が表示される。
この画面では、現在位置表示領域ＣＬＲ１の下には、連携ウォレット情報表示領域ＷＩＲ１が表示されている。連携ウォレット情報表示領域ＷＩＲ１には、「ウォレット連携を依頼しますか？」の文字が表示され、その下には、ウォレット連携を行うグループ「バンド仲間」に所属するメンバーが一覧表示されている。限定ではなく例として、この画面では、グループ「バンド仲間」は、ユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃとの３名を含むグループであることが示されている。

また、画面最下部には、「ウォレット連携を依頼」という文字で示されるウォレット連携依頼ボタンＢＴ３５が設けられており、このウォレット連携依頼ボタンＢＴ３５がタップされると、端末２０Ａからサーバ１０に対して、グループ内の他のメンバーにウォレット連携を要求するための連携グループ選択情報が送信される。

ウォレット連携依頼ボタンＢＴ３５がタップされると、図１０−２右側に示すように、グループ「バンド仲間」の他のメンバーがウォレット連携を行う前の連携ウォレットのメイン画面が表示される。

この画面では、現在位置表示領域ＣＬＲ１の下に、連携ウォレットを用いて「店舗提示型」のコード支払いを行うための「コードリーダ」の文字で示されるコードリーダアイコンＩＣ２と、「利用者提示型」のコード支払いを行うための「コード支払い」の文字で示されるコード支払いアイコンＩＣ３とが横に並んで表示されている。
なお、この画面では、まだ連携ウォレットが有効化されていないため、コードリーダアイコンＩＣ２と、コード支払いアイコンＩＣ３とは、タップされても機能せず、グレーアウトされて表示されている。

これらのアイコンの下には、連携ウォレットの対象となるグループ名「バンド仲間」が表示され、さらにその下には、グループ「バンド仲間」の各メンバーの連携状況を表示するための連携メンバー情報表示領域ＭＩＲ１が表示されている。

連携メンバー情報表示領域ＭＩＲ１には、ウォレット連携対象となった各メンバーの名称と、連携状況とが行ごとに関連付けて表示されている。限定ではなく例として、ユーザＡ．Ａは、ウォレット連携中であり、ユーザＡ．Ａの電子マネー口座残高は「１，０００円」であることが示されている。
また、ユーザＢ．Ｂと、ユーザＣ．Ｃとは、ウォレット連携の依頼中であり、連携の承認が取れていないことが示されている。

図１０−３左側は、図１０−２においてウォレット連携依頼ボタンＢＴ３５がタップされたことに基づいて、ウォレット連携を依頼されたユーザＢ．Ｂの端末２０Ｂにおけるおしらせ画面の一例である。
このおしらせ画面では、現在位置表示領域ＣＬＲ２には、支払いアプリケーションのおしらせ機能であることを示す「おしらせ」の文字が表示されている。

現在位置表示領域ＣＬＲ２の下には、ユーザＡ．Ａからウォレット連携の依頼が行われたことをユーザＢ．Ｂに報知する通知ＮＴ１が表示されている。また、通知ＮＴ１の下には、おしらせ情報を表示するためのおしらせ情報表示領域ＮＴＲ１が構成されており、このおしらせ情報表示領域ＮＴＲ１に、上記の通知ＮＴ１に対応する情報が表示される。

この例では、おしらせ情報表示領域ＮＴＲ１に、「Ａ．Ａさんからウォレット連携の依頼が届きました」の文字と共に、ウォレット連携を行うグループ「バンド仲間」の文字とアイコンとが表示されたウォレット連携承認確認情報ＣＴ１が表示されている。
ウォレット連携承認確認情報ＣＴ１の下部には、グループ「バンド仲間」のメンバーとウォレット連携を行うことを承認するための「連携する」の文字で示されるウォレット連携承認ボタンと、ウォレット連携を承認しないための「断る」の文字で示されるウォレット連携拒否ボタンとが表示されている。

限定ではなく例として、ウォレット連携拒否ボタンがタップされる場合、連携ウォレットと連携中のメンバー（この例ではユーザＡ．Ａ）の端末に、ウォレット連携に失敗したことを示す通知が送信され、表示される。その後、グループ「バンド仲間」における連携ウォレットは破棄され、処理を終了する。

図１０−３中央は、ウォレット連携承認確認情報ＣＴ１のウォレット連携承認ボタンがタップされた場合における、連携ウォレットのメイン画面の一例である。この画面では、連携メンバー情報表示領域ＭＩＲ１において、ユーザＢ．Ｂがウォレット連携中となり、ユーザＢ．Ｂの電子マネー口座残高は「３，０００円」であることが示されている。

なお、図１０−３中央において、ユーザＢ．Ｂがウォレット連携を行った旨を示す通知を表示するようにしてもよいし、そうしなくてもよい。

図１０−３右側は、グループのメンバー全員が連携ウォレット連携を行ったことに基づいて表示される連携ウォレットのメイン画面の一例であり、この画面では、連携メンバー情報表示領域ＭＩＲ１に、各ユーザの電子マネー口座残高が表示されている。また、コードリーダアイコンＩＣ２とコード支払いアイコンＩＣ３とは、グレーアウト表示が解除され、タッチ操作が有効化されている。

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

まず、端末２０Ａの制御部２１は、連携ウォレットを適用するグループを選択するための、グループの一覧に関する情報を要求するための、グループ一覧要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５００）。

通信Ｉ／Ｆ１４によって端末２０Ａからグループ一覧要求情報を受信すると、サーバ１０の制御部１１は、グループ管理データベース１５９を参照し、限定ではなく例として、グループＩＤと、グループ名との一覧で構成されるグループ一覧情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ５００）。

端末２０Ａの入出力部２３に対するユーザ操作に基づいて、グループ一覧情報から、連携ウォレットを適用するグループが選択されると、端末２０Ａの制御部２１は、そのグループＩＤを少なくとも含む連携グループ選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５１０）。

通信Ｉ／Ｆ１４によって端末２０Ａから連携グループ選択情報を受信すると、サーバ１０の制御部１１は、第５の連携ウォレット管理データベース１５７Ｅの連携ウォレット管理データに、そのグループＩＤと、紐づけられるグループ名との管理データを新たなレコードとして追加する。また、サーバ１０の制御部１１は、グループ管理データベース１５９を参照し、追加された連携ウォレット管理データの連携状況管理データに、そのグループのユーザ情報（限定ではなく例として、アプリケーションＩＤとユーザ名）を書き込む。そして、サーバ１０の制御部１１は、連携状況管理データの各ユーザの項目に連携承認として「未」を設定し、連携グループ選択情報を送信した端末のユーザの連携承認を「済」に設定する（Ｓ５０５）。

すると、サーバ１０の制御部１１は、ウォレット連携を承認するか否かの承認確認用情報であるウォレット連携承認確認情報を、通信Ｉ／Ｆ１４によって連携承認が「未」であるユーザの端末（限定ではなく例として、端末２０Ｂ）に送信する（Ｓ５１０）。

通信Ｉ／Ｆ２２によってサーバ１０からウォレット連携承認確認情報を受信すると、端末２０Ｂの制御部２１は、ウォレット連携承認確認情報を表示部２４に表示させる（Ｂ５００）。端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、ウォレット連携を承認することが選択される場合（Ｂ５００：ＹＥＳ）、端末２０Ｂの制御部２１は、ウォレット連携承認情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ５１０）。

ウォレット連携を承認しないことが選択される場合には（Ｂ５００：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ５１０のステップをスキップする。

通信Ｉ／Ｆ１４によってウォレット連携承認確認情報を送信した端末からウォレット連携承認情報を受信すると（Ｓ５２０：ＹＥＳ）、サーバ１０の制御部１１は、受信した端末のアプリケーションＩＤにおける連携状況管理データの連携承認を、「済」に変更する。そして、限定ではなく例として、連携したメンバーのアプリケーションＩＤと電子マネー口座残高を含む連携メンバー情報を、グループの各メンバーの端末に送信する（Ｓ５３０）。

ウォレット連携承認情報を受信しない場合には（Ｓ５２０：ＮＯ）、サーバ１０の制御部１１は、ウォレット連携承認情報の受信を待機する。なお、一定期間が過ぎてもなおウォレット連携承認情報を受信しない場合、サーバ１０の制御部１１は、各端末にウォレット連携が失敗したことを示す情報を送信した後、処理を終了させるようにしてもよいし、そのようにしなくてもよい。

Ｓ５３０のステップを実行後、サーバ１０の制御部１１は、連携状況管理データの連携承認が、全てのユーザにおいて「済」になっているか否かを判定する（Ｓ５４０）。グループメンバー全員がウォレット連携に同意している場合（Ｓ５４０：ＹＥＳ）、サーバ１０の制御部１１は、このグループ（連携ウォレット）の連携ウォレット支払いトークンが生成可能になり、連携ウォレットが使用可能になったことを示す連携ウォレット情報を、通信Ｉ／Ｆ１４によってグループの各メンバーの端末に送信する（Ｓ５５０）。そして、サーバ１０の制御部１１は、限定ではなく例として、図７−３のＳ１００のステップに処理を移す。

グループメンバー全員がまだウォレット連携に同意していない場合には（Ｓ５４０：ＮＯ）、サーバ１０の制御部１１は、ウォレット連携承認情報の受信待機に処理を戻す。

通信Ｉ／Ｆ２２によってサーバ１０から連携メンバー情報を受信すると（Ａ５１５：ＹＥＳ）、端末２０Ａの制御部２１は、連携メンバー情報を表示部２４に表示させる（Ａ５２０）。そして、端末２０Ａの制御部２１は、連携ウォレット情報の受信を待機する。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット情報を受信する場合（Ａ５３０：ＹＥＳ）、端末２０Ａの制御部２１は、連携ウォレット情報に基づいて、連携ウォレットが有効化されたことを示す表示を表示部２４に表示させ、ユーザに選択したグループでの連携ウォレットが使用可能であることを報知する（Ａ５４０）。そして、端末２０Ａの制御部２１は、限定ではなく例として、サーバ１０から連携ウォレットコードリーダ情報を受信し、図７−３のＡ１００のステップに処理を移す。

連携ウォレット情報を受信しない場合には（Ａ５３０：ＮＯ）、端末２０Ａの制御部２１は、再度連携メンバー情報の受信を待機する。
なお、ウォレット連携が失敗したことを示す情報をサーバ１０から受信する場合には、端末２０Ａの制御部２１は、処理を終了させるようにしてもよいし、そのようにしなくてもよい。

端末２０Ｂにおいて、Ｂ５１５〜Ｂ５４０のステップがＡ５１５〜Ａ５４０のステップと同様に実行される。そして、端末２０Ｂの制御部２１は、限定ではなく例として、サーバ１０から連携ウォレット情報を受信すると、図７−３のＢ２００のステップに処理を移す。

ただし、連携ウォレット情報を受信しない場合には（Ｂ５３０：ＮＯ）、自端末のアカウントが既にウォレット連携を行ったか否かを判定する（Ｂ５５０）。

自端末が連携済みの場合（Ｂ５５０：ＹＥＳ）、端末２０Ｂの制御部２１は、再度連携メンバー情報の受信を待機する。
自端末の連携がまだ行われていない場合には（Ｂ５５０：ＮＯ）、端末２０Ｂの制御部２１は、Ｂ５００のステップへ処理を戻す。

＜第１０変形例（１）＞
第１０実施例では、複数のメンバーで予め構成されるグループにおいて連携ウォレットを導入する方法についての場合を例示したが、これに限定されない。限定ではなく例として、第４実施例の（１）の方法（連携アカウントデータに複数の連携アカウントを登録する方法）で構成される連携ウォレットにおいて、連携メンバーの認可に基づいて、連携ウォレットを使用可能にするようにしてもよいし、そのようにしなくてもよい。

この場合、限定ではなく例として、第５の連携ウォレット管理データベース１５７Ｅにおいて、グループＩＤと、グループ名との代わりに連携ウォレットＩＤを用いて連携ウォレットを識別できるようにする。そして、連携アカウントデータに連携承認を加えたデータが連携状況管理データであるとみなして処理を実行すればよい。

このためには、処理の冒頭（図１０−４のＡ５００〜Ａ５１０のステップ）において、端末２０Ａの制御部２１は、グループを選択させる代わりに、任意のユーザ（ユーザアカウント）のアプリケーションＩＤを選択し、サーバ１０に送信すればよい。そして、サーバ１０は、選択されたアプリケーションＩＤを連携状況管理データに追加するようにすればよい。

＜第１０変形例（２）＞
上記の実施例において、連携承認を必要とせず、連携ウォレットが作成されたことを以ってアカウント連携が行われるようにしてもよいし、そのようにしなくてもよい。
つまり、連携承認に関する処理を省略し、連携ウォレットが作成される場合に、連携候補とされた複数のアカウントが連携ウォレット管理データにおいて自動的に関連付けられるようにしてもよいし、そのようにしなくてもよい。
この場合は、連携ウォレットが生成されることが「アカウント連携」となる。

＜第１１実施例＞
第１実施例〜第１０実施例では、限定ではなく例として、アプリケーションとして支払いアプリケーションを適用した実施例について説明したが、これに限定されない。
第１１実施例は、チャットアプリケーションのグループにおいて連携ウォレットを用いて支払いを行い、チャットルームにその表示を行う実施例である。

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

本実施例では、チャットサービスをメッセージングサービスとし、端末２０にインストールされたメッセージングアプリケーションによって、連携決済結果情報に基づく表示や、立替履歴情報に基づく表示を行う場合を例示する。
また、メッセージンサービス（メッセージングアプリケーション）を適用する場合のチャットルームとして、以下ではトークルームを例示する。

本実施例では、メッセージングサービスで用いられるグループに対して、メッセージングサービスと連携する支払いアプリケーションサービスにおいて、ウォレット連携を行う場合を例示する。

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

図１１−１は、本実施例において端末２０の表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面である。トークルーム画面では、限定ではなく例として、自分（この例ではユーザＡ．Ａ）が発信したメッセージが表示領域の右側に吹き出しとして表示され、他のユーザから発信されたメッセージが表示領域の左側に吹き出しとして表示される。

図１１−１左側には、ユーザＡ．Ａが、他のグループメンバーであるユーザＢ．Ｂ、ユーザＣ．Ｃと、メッセージをやり取りしている状態が示されている。この状態で、画面下部の連携ウォレットアイコンＩＣ１がタップされると、限定ではなく例として、図１１−１右側の画面が表示される。

具体的には、画面下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がり表示されている。連携ウォレット情報表示領域ＷＩＲ１には、「ウォレット連携を依頼しますか？」の文字とともに、グループ「バンド仲間」に含まれる各グループメンバーのアイコンおよびユーザ名が表示されている。この状態で、連携ウォレット情報表示領域ＷＩＲ１の下部に表示されたウォレット連携依頼ボタンＢＴ３５がタップされると、サーバ１０を介して、ウォレット連携の依頼が、端末２０Ａから他のグループメンバーの端末２０に送信される。

図１１−２は、この場合に端末２０Ｂの表示部２４に表示されるグループトークルーム画面の一例を示す図である。
グループトークルームには、ユーザＡ．Ａから発信されたメッセージとして、ウォレット連携を依頼することを示すウォレット連携依頼メッセージＭＳ１が、表示領域の左側に表示されている。このウォレット連携依頼メッセージＭＳ１には、ウォレット連携を依頼することを示すテキストとともに、ウォレット連携の依頼を承認することを示す「連携する」の文字を含む連携ボタンと、ウォレット連携の依頼を拒否することを示す「断る」の文字を含む拒否ボタンとが表示されている。連携ボタンがタップされると、ウォレット連携に同意したことを示す情報がサーバ１０に送信されて、ユーザＢ．Ｂのユーザアカウントが連携される。その結果、端末２０Ａの表示部２４には、限定ではなく例として、図１１−２右側の画面が表示される。

この画面では、図１１−１左側のグループトークルーム画面の下部から、連携メンバー情報表示領域ＭＩＲ１がせり上がって表示されている。ユーザＡ．Ａはウォレット連携中であり、ユーザＡ．Ａの電子マネー口座残高は「１，０００円」であることが示されている。これに加えて、ユーザＢ．Ｂがウォレット連携を承認したことで、ユーザＢ．Ｂもウォレット連携中であり、ユーザＢ．Ｂの電子マネー口座残高は「３，０００円」であることが示されている。
また、ユーザＣ．Ｃは、ウォレット連携の依頼中であり、連携の承認が取れていないことが示されている。

図１１−３は、上記において、ユーザＣ．Ｃによる連携の承認が取れた後、グループ「バンド仲間」の連携ウォレットによってアカウント連携決済が行われた場合に、端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図１１−３左側では、連携ウォレットによる支払いが完了したことを示す情報を含むメンバー支払い結果表示領域ＭＲＲ８を含む連携ウォレット支払い完了通知が、画面下部からせり上がって、グループ「バンド仲間」のグループトークルームに重畳して表示されている。
この例では、ユーザＡ．Ａのユーザアカウントの電子マネー口座残高が「１，０００円」であり、等分支払い金額である「１，５００円」に対して「５００円」が不足していたことに基づき、「５００円」をユーザＣ．Ｃに立て替えてもらった場合の例を示している。

ユーザＡ．Ａについては、等分支払い金額「１，５００円」のうちの不足分の金額「５００円」をユーザＣ．Ｃに立て替えてもらい、支払い余力である「１，０００円」を支払い、その結果、電子マネー口座残高が「０円」になったことが示されている。
ユーザＢ．Ｂについては、等分支払い金額「１，５００円」を支払い、その結果、電子マネー口座残高が「１，５００円」になったことが示されている。
ユーザＣ．Ｃについては、等分支払い金額「１，５００円」のうちのユーザＡ．Ａの不足分の金額「５００円」を立て替え、「１，５００円＋５００円＝２，０００円」を支払い、その結果、電子マネー口座残高が「４，０００円」になったことが示されている。

また、メンバー支払い結果表示領域ＭＲＲ８において、ユーザＣ．Ｃの項目には、ユーザＡ．Ａが、立て替えてもらった「５００円」をユーザＣ．Ｃに返却するための立て替え金額返金ボタンＢＴ６が表示されている。
立て替え金額返金ボタンＢＴ６がタップされると、ユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座へ、立替分「５００円」の送金が実行される。

メンバー支払い結果表示領域ＭＲＲ２の右上の閉じるボタン（×マークのボタン）がタップされると、メンバー支払い結果表示領域ＭＲＲ２が非表示となり、その結果、グループトークルームが視認可能な状態となる。このグループトークルームには、連携ウォレットによってユーザＡ．Ａが「１，０００円」を支払ったことを示す連携決済結果メッセージＭＳ２（連携決済結果情報）と、ユーザＣ．Ｃに「５００円」を立て替えてもらったことを示す立て替えメッセージＭＳ３（立て替え情報）とが表示されている。
なお、連携決済結果メッセージＭＳ２と、立て替えメッセージＭＳ３とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。

立て替えメッセージには、立て替え金額返金ボタンＢＴ６が表示されている。
立て替え金額返金ボタンＢＴ６がタップされると、ユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座へ、立替分「５００円」の送金が実行される。

図１１−４は、この例において端末２０Ｃの表示部２４に表示される画面の一例を示す図である。
図１１−４左側には、グループトークルームが表示されており、連携ウォレットによってユーザＣ．Ｃが「２，０００円」を支払ったことを示す連携決済結果メッセージＭＳ４（連携決済結果情報）と、ユーザＣ．ＣがユーザＡ．Ａの支払い分の「５００円」を立て替えたことを示す立て替えメッセージＭＳ５（立て替え情報）とが表示されている。
なお、連携決済結果メッセージＭＳ４と、立て替えメッセージＭＳ５とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。

立て替えメッセージＭＳ５には、ユーザＣ．Ｃが、立て替えた「５００円」をユーザＡ．Ａに請求するための立て替え金額請求ボタンＢＴ７が表示されている。
立て替え金額請求ボタンＢＴ７がタップされると、サーバ１０を介して、端末２０Ｃから端末２０Ａに対して、立て替え金額を請求する情報が送信される。

限定ではなく例として、立て替えメッセージＭＳ５に含まれる「＞ＰａｙｍｅｎｔＡｐｐ」のボタンがタップされると、図１１−４右側に示すように、メンバー支払い結果表示領域ＭＲＲ９を含む連携ウォレット支払い完了通知が、画面下部からせり上がって、グループトークルームに重畳して表示される。
メンバー支払い結果表示領域ＭＲＲ９において、ユーザＡ．Ａの項目には、立て替え金額請求ボタンＢＴ７が表示されている。

図１１−５は、図１１−１〜図１１−４で説明した連携ウォレットによる支払いに引き続いて、別のアカウント連携決済（次のアカウント連携決済）が行われる場合に端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１１−５左側には、図１１−３右側に示したグループトークルームにおいて、チャットが進行した状態が示されている。この例では、ユーザＡ．Ａからグループに対して、別の商品（この例では、スティック）を購入することを希望するメッセージが発信され、これを承認する旨のメッセージが、ユーザＣ．Ｃから発信された状態が示されている。

アカウント連携決済によって上記の商品（スティック）が購入されて決済が完了すると、限定ではなく例として、図１１−５中央に示すように、メンバー支払い結果表示領域ＭＲＲ１０を含む連携ウォレット支払い完了通知が、画面下部からせり上がって、図１１−５左側のグループトークルームに重畳して表示される。

この例では、商品（スティック）の価格は「９００円」であり、等分支払い金額は「９００円÷３＝３００円」である。しかし、上記のように、ユーザＡ．Ａの電子マネー口座残高は「０円」となったため、ユーザＡ．Ａは支払いを行うことができない。このため、この例では、ユーザＡ．Ａが、上記と同様にユーザＣ．Ｃに不足分の金額を立て替えてもらった結果を示している。

具体的には、ユーザＡ．Ａについては、支払い金額が「０円」であり、電子マネー口座残高も「０円」であることが示されている。
ユーザＢ．Ｂについては、等分支払い金額「３００円」を支払い、その結果、電子マネー口座残高が「１，２００円」になったことが示されている。
ユーザＣ．Ｃについては、等分支払い金額「３００円」のうちのユーザＡ．Ａの不足分の金額「３００円」を立て替え、「３００円＋３００円＝６００円」を支払い、その結果、電子マネー口座残高が「３，４００円」になったことが示されている。

図１１−５右側には、この場合に端末２０Ａに表示されるグループトークルームの一例を示している。このグループトークルームには、連携ウォレットによるユーザＡ．Ａの支払いが「０円」であることを示す連携決済結果メッセージＭＳ６（連携決済結果情報）と、ユーザＣ．Ｃに「３００円」を立て替えてもらったことを示す立て替えメッセージＭＳ７（立て替え情報）とが表示されている。
なお、連携決済結果メッセージＭＳ６と、立て替えメッセージＭＳ７とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。

立て替えメッセージには、立て替え金額返金ボタンＢＴ６が表示されている。
立て替え金額返金ボタンＢＴ６がタップされると、ユーザＡ．Ａの電子マネー口座からユーザＣ．Ｃの電子マネー口座へ、立替分「３００円」の送金が実行される。

図１１−６は、連携ウォレットの一括精算を行う場合の表示画面例を示す図であり、端末２０Ａの表示部２４に表示されるグループトークルーム画面の一例を示している。
この例では、図１１−６左側に示すように、現在位置表示領域内のグループ名「バンド仲間（３）」から下方にぶら下がる形式で「連携ウォレットの精算が必要です」の文字を含む、連携ウォレットの精算を促すための通知が表示されている。この吹き出しがタップされると、図１１−６右側に示すように、グループトークルームの画面下部から、連携ウォレットの一括精算に関する情報を表示する表示領域がせり上がって表示される。

この表示領域には、「連携ウォレットの精算をしますか？」の文字とともに、ユーザＡ．ＡからユーザＣ．Ｃに対して、前述した「５００円」の立て替えと、前述した「３００円」の立て替えとの２件分の立て替えに相当する、合計「８００円」の返却（送金）を行うことを確認するためのメッセージとともに、これを承認するための「はい」のボタンと、これを拒否するための「いいえ」のボタンとが表示されている。「はい」のボタンがタップされると、ユーザＡ．ＡからユーザＣ．Ｃへの「８００円」の送金が実行される。

なお、図１１−６左側の画面において、連携ウォレットの精算を促すための通知が、現在位置表示領域内のグループ名の表示領域や他の領域がタップされたことに基づいて表示されるようにしてもよいし、そのようにしなくてもよい。

＜処理＞
本実施例における処理については、限定ではなく例として、支払いアプリケーションを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバとの処理をサーバ１０における処理として、図１０−４〜図１０−５および図７−３〜図７−５に従って同様に実現することが可能であるため、再度の説明は省略する。

＜第１１実施例の効果＞
本実施例は、送金依頼情報の表示（限定ではなく、第１表示の一例）は、第１ユーザアカウントと第２ユーザアカウントとが関連付けられたトークルーム（限定ではなく、第１アカウントと第２アカウントとが関連付けられたチャットルームの一例）に含まれ、端末２０は、送金依頼情報の表示を含むトークルームを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとが関連付けられたチャットルームへの表示という分かり易い形で、第２アカウントに送金することに関する第１情報を、端末の第１ユーザに知らせることができる。

また、本実施例は、端末２０が、第１ユーザアカウントと第２ユーザアカウントとに基づき、サーバ１０にアカウント連携決済を行わせるための処理（限定ではなく、第２決済に関する処理の一例）を制御部２１によって行う。また、端末２０は、アカウント連携決済に基づいて、送金依頼情報（限定ではなく、第２情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信した送金依頼情報の表示（限定ではなく、第２表示の一例）と、他の送金依頼情報の表示（限定ではなく、第１表示の一例）とを含むトークルームを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第１ユーザの第１アカウントと、第１アカウントと関連付けられた第２アカウントとに基づき、第１ユーザの端末によって第２決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも２つのアカウントによる第２決済を実現することができる。また、第１決済により第２アカウントに送金することに関する第１情報に加えて、第２決済により第２アカウントに送金することに関する第２情報を、チャットルームへの表示という分かり易い形で、端末の第１ユーザに知らせることができる。

また、本実施例は、一の送金依頼情報の表示（限定ではなく、第２表示の一例）と、他の送金依頼情報の表示（限定ではなく、第１表示の一例）とに対する端末２０のユーザによる入力に基づいて、一の送金依頼情報に基づく送金推奨額と、他の送金依頼情報に基づく送金推奨額とを、第１ユーザアカウントから第２ユーザアカウントに送金するための処理を実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第１表示と第２表示とに対する第１ユーザによる入力という簡単な方法で、第１情報に基づく金額と第２情報に基づく金額とを、第１アカウントから第２アカウントに送金することができる。

＜第１１変形例（１）＞
第１１実施例において、複数の連携アカウントのトークルーム（チャットルーム）におけるアカウント連携を解除することに基づいて、それまでに行われたアカウント連携決済について、未処理の返金を行うようにしてもよいし、しなくてもよい。

「アカウント連携の解除」とは、アカウント同士の関連付けを無くすことを意味する。限定ではなく例として、連携ウォレットを破棄することがこれに含まれる。

また、チャットルームと紐付けて連携ウォレットを作成した場合、「チャットルームにおけるアカウント連携の解除」には、限定ではなく例として、以下のいずれかが含まれる。
（Ａ）チャットルームは破棄せずアカウント同士の関連付けを無くすこと
（Ｂ）チャットルームを破棄すること

（Ａ）は、限定ではなく例として、チャットルームは破棄せずに、そのチャットルームと紐付いた連携ウォレットにおけるアカウント同士の関連付けを無くすことを意味する。限定ではなく例として、チャットルーム上でユーザが連携ウォレットを破棄するための入力を行って、連携ウォレットを破棄することがこれに含まれる。

（Ｂ）は、チャットルームを破棄することによって、結果的に、そのチャットルームと紐付いた連携ウォレットにおけるアカウント同士の関連付けが無くなることを意味する。限定ではなく例として、ユーザがチャットルームを破棄するための入力を行って、チャットルームを破棄することがこれに含まれる。

なお、メンバーがチャットルームから退出することしかできず、チャットルームの存在を無くすことができない設計・仕様であれば、限定ではなく例として、退出によってメンバーの残り人数が「１」または「０」となった場合に、アカウント連携を解除するようにしてもよいし、そのようにしなくてもよい。

図１１−７は、本変形例において端末２０Ａの表示部２４に表示される画面の一例を示す図である。
図１１−７左側には、グループ「バンド仲間」の連携ウォレットに関する、連携メンバー情報表示領域ＭＩＲ１が、グループトークルームの画面下部からせり上がって表示されている。連携メンバー情報表示領域ＭＩＲ１の下部には、連携ウォレット破棄ボタンＢＴ３０が表示されている。

本変形例では、連携ウォレット破棄ボタンＢＴ３０がタップされると、一括精算を行った上で、連携ウォレットを破棄することが可能に構成されている。具体的には、限定ではなく例として、図１１−７右側に示すように、連携ウォレット情報に重畳するように、連携ウォレットを破棄することを示す情報と、一括精算に関する情報とが、ポップアップ形式で表示される。

この例では、ユーザＡ．ＡからユーザＣ．Ｃに対して、前述した「５００円」の立て替えと、前述した「３００円」の立て替えとの２件の立て替えに相当する、合計「８００円」の返却（送金）を行うことを確認するためのメッセージとともに、これを承認するための「はい」のボタンと、これを拒否するための「いいえ」のボタンとが表示されている。「はい」のボタンがタップされると、ユーザＡ．ＡからユーザＣ．Ｃへの「８００円」の送金が実行される。

本変形例は、端末２０が、第１ユーザアカウントと、第２ユーザアカウントとのトークルームにおける関連付けを解除（限定ではなく、チャットルームにおける関連付けの解除の一例）することに基づいて、一括精算の金額（限定ではなく、第１情報に基づく金額と第２情報に基づく金額との一例）を、第１ユーザアカウントから第２アカウントに送金する処理を行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと、第２アカウントとのチャットルームにおける関連付けを解除する場合、第１情報に基づく金額と第２情報に基づく金額とを、第１アカウントから第２アカウントに送金することができる。限定ではなく例として、チャットルーム上で第１アカウントと第２アカウントとの関連付けを破棄したり、チャットルームそれ自体を破棄するような場合に、未処理分の金額を返金するといったことが可能となる。

＜第１２実施例＞
上記の実施例では、連携メンバーの各々の端末２０において、各連携アカウントの電子マネー口座残高を確認可能に構成されていた。この各連携アカウントにおける電子マネー口座残高の情報は、限定ではなく例として、サーバ１０から連携メンバーの端末２０に送信され、端末２０で受信して表示部２４に表示させることが可能である。なお、これとは異なり、電子マネー口座残高の情報を、端末２０間で送受信するようにすることも可能である。
つまり、上記の実施例では、各連携アカウントにおいて、真の電子マネー口座残高が連携メンバーに共有されていた。
しかし、ユーザによっては、他の連携メンバーに対して、自分の真の電子マネー口座残高を開示することが憚られることが想定される。

以下説明する実施例は、予め設定される制限に従って、真の電子マネー口座残高とは異なる残高を表示可能とする実施例である。
以下では、連携ウォレットにおいて表示される、連携アカウントの表示上の残高のことを「表示残高」と称する。

ただし、前述したように、必ずしも異なるユーザのユーザアカウントを連携アカウントとしなければならないわけではなく、同じユーザの複数のユーザアカウントを連携アカウントとすることも可能である。
そこで、まず本実施例では、同じユーザの複数のユーザアカウントを連携アカウントとする場合について説明する。

また、本実施例では、表示残高を制限させるために設定される金額の一例として「表示下限金額」を例示するが、これに限定されない。
詳細後述する「表示上限金額」や、連携アカウントのユーザによって任意に入力・設定される金額を、表示残高を制限させるために設定される金額とすることもできる。

なお、表示残高は、真の電子マネー口座残高とは異なる残高を表示可能とする概念であり、アカウント連携決済以外にも同様に適用可能である。
限定ではなく例として、ユーザアカウントを用いた通常の決済や、共通アカウント決済等に対しても同様に適用可能である。

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

図１２−１は、この場合において連携ウォレットを管理するためのデータベースの一例である第６の連携ウォレット管理データベース１５７Ｆのデータ構成例を示す図である。
第６の連携ウォレット管理データベース１５７Ｆには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、連携ウォレットＩＤと、連携アカウントデータと、決済履歴データとが記憶される。連携ウォレットＩＤと、決済履歴データとは、限定ではなく例として、第１の連携ウォレット管理データベース１５７Ａと同様である。

連携アカウントデータには、この連携アカウントに対応するアプリケーションＩＤと、このアプリケーションＩＤに対応するユーザ名との他に、限定ではなく例として、表示下限金額が関連付けて記憶される。

表示下限金額とは、表示残高を制限させるために設定される金額の一例であり、表示残高として表示され得る下限額として設定される金額である。
限定ではなく例として、図１２−１では、連携アカウントとして、ユーザＡ．ＡのメインアカウントであるアプリケーションＩＤ「Ｕ０００１」のユーザアカウントと、ユーザＡ．ＡのサブアカウントであるアプリケーションＩＤ「Ｕ０００５」のユーザアカウントとが関連付けられている。

また、アプリケーションＩＤ「Ｕ０００１」に対して表示下限金額は設定されていないが、アプリケーションＩＤ「Ｕ０００５」に対しては表示下限金額として「５，０００円」が設定されている。
この場合、アプリケーションＩＤ「Ｕ０００５」の電子マネー口座残高が「５，０００円」を下回っていても、表示残高は「５，０００円」と表示される。一方、電子マネー口座残高が「５，０００円」以上の場合には、電子マネー口座残高がそのまま表示残高として用いられる。

＜表示画面＞
ここでは、ユーザＡ．Ａのメインアカウントとサブアカウントとを連携アカウントとして連携させた連携ウォレットについて表示画面例を用いて説明する。ここで、サブアカウントの電子マネー口座残高は、「１，０００円」であり、サブアカウントの表示下限金額が「５，０００円」であるとする。

図１２−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１２−２左側の支払いアプリケーションのメインメニュー画面において、連携ウォレットアイコンＩＣ１がタップされると、図１２−２中央の画面が表示される。この画面では、ユーザＡ．Ａの連携ウォレットであることを示す情報とともに、その下の連携メンバー情報表示領域ＭＩＲ１には、ユーザＡ．Ａのメインアカウントの電子マネー口座残高（この例では「１０，０００円」）と、ユーザＡ．Ａのサブアカウントに設定された表示残高（この例では「５，０００円」）とが表示されている。ユーザＡ．Ａのサブアカウントの残高表示欄には、メインアカウントとは異なり、設定された表示残高が表示されている。

この画面において、コードリーダアイコンＩＣ２がタップされると、図１２−２右側のコードリーダ画面が表示される。コード読み取り領域ＣＲ１内に支払い店舗コードが収まり、連携ウォレットコードリーダ情報が読み取られると、図１２−３左側に示す画面が表示される。この画面では、連携ウォレットでの支払い金額として「６，０００円」が入力された状態が示されている。この状態で画面下部の支払いボタンＢＴ１がタップされると、図１２−３右側の画面が表示される。

この例では、等分支払い金額は「３,０００円」である。
連携メンバー情報表示領域ＭＩＲ１には、ユーザＡ．Ａのメインアカウントの支払い金額（この例では「３，０００円」）と、ユーザＡ．Ａのサブアカウントの支払い金額（この例では「３，０００円」）とが表示されている。

ユーザＡ．Ａのメインアカウントについては、電子マネー口座残高が「１０，０００円」であり、等分支払い金額を上回っている。
しかし、ユーザＡ．Ａのサブアカウントについては、表示残高は「５，０００円」であるものの、実際の電子マネー口座残高は「１，０００円」であり、電子マネー口座残高が等分支払い金額を下回っている。
その結果、連携支払い可能額が支払い金額を下回ることに基づいて、支払い金額確認領域ＰＩＲ１には、警告マークと「残高不足です」の文字とが表示されている。

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

まず、サーバ１０の制御部１１は、第６の連携ウォレット管理データベース１５７Ｆに記憶された表示下限金額に従い、各連携アカウントにおける表示残高を算出する。そして、サーバ１０の制御部１１は、算出された表示残高を含む下限制限付き連携アカウント残高情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ６００）。

なお、表示下限金額が未設定の場合には、表示残高と区別可能な態様で、連携アカウントの電子マネー口座残高を下限制限付き連携アカウント残高情報として送信するようにしてもよい。もしくは、表示残高の形で電子マネー口座残高を送信するようにしてもよい（すなわち「表示残高」＝「電子マネー口座残高」）。

通信Ｉ／Ｆ２２によってサーバ１０から下限制限付き連携アカウント残高情報を受信すると、端末２０Ａの制御部２１は、各連携アカウントの表示残高を表示部２４に表示させる（Ａ６００）。

表示残高として表示下限金額の制限を受ける場合であっても、連携決済処理では、真の電子マネー口座残高を用いて決済の処理が実行される（Ｓ１１０）。すなわち、表示残高は、ただ単に端末２０のユーザが確認可能な値に過ぎない。

なお、限定ではなく例として、Ｓ６００のステップにおいて、サーバ１０が、真の電子マネー口座残高と表示下限金額とを端末２０Ａに送信するようにしてもよいし、そのようにしなくてもよい。
この場合、端末２０Ａの制御部２１は、受信した真の電子マネー口座残高と表示下限金額とを用いて表示残高を算出し、表示部２４に表示させるようにすることができる。

また、連携アカウントに対応する端末２０が複数である場合、サーバ１０から各連携アカウントの電子マネー口座残高を受信し、端末２０間で表示下限金額を送受信することで、各端末２０において表示残高を算出するようにしてもよいし、そのようにしなくてもよい。

連携アカウントに対応する端末２０が１つ（すなわち連携メンバーが１人）の場合には、限定ではなく例として、表示下限金額を端末２０Ａの記憶部２８に記憶させ、サーバ１０から各連携アカウントの電子マネー口座残高を受信し、自端末において表示残高を算出するようにしてもよいし、そのようにしなくてもよい。この場合には、表示下限金額に関する情報の送受信は不要である。

＜第１２実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）の第２ユーザアカウント（限定ではなく、第２アカウントの一例）に設定された表示下限金額（限定ではなく、第２金額の一例）に基づく表示残高（限定ではなく、第２金額に基づく第２アカウントの残高の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザの第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、表示下限金額が設定された第２ユーザアカウントとに基づき、連携アカウント決済に関する処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの第１アカウントに関連付けられた第２アカウントに設定された第２金額に基づく第２アカウントの残高を、第１ユーザに確認させることができる。
また、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済を行わせることができる。

また、この場合、端末２０が、表示下限金額（限定ではなく、第２金額の一例）に基づく表示残高の情報（限定ではなく、第２金額に基づく第２アカウントの残高情報の一例）を通信Ｉ／Ｆ２２によって受信する。そして、端末２０は、受信した表示残高の情報に基づく表示残高を表示部２４に表示するようにすることができる。
このような構成により得られる実施例の効果の一例として、第２金額に基づく第２アカウントの残高情報を他の装置から受信して取得したことに基づいて、第２金額に基づく第２アカウントの残高を、第１ユーザに確認させることができる。

また、本実施例は、サーバ１０が、第２ユーザアカウントに設定された表示下限金額に基づく表示残高の情報（限定ではなく、第２金額に基づく第２アカウントの残高に関する情報の一例）を通信Ｉ／Ｆ２２によって第１ユーザの端末２０に送信する。そして、サーバ１０は、第１ユーザアカウントと、表示下限残高が設定された第２ユーザアカウントとに基づき、アカウント連携決済の処理を制御部１１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第２アカウントに設定された第２金額に基づく第２アカウントの残高に関する情報を第１ユーザの端末に送信して、第１ユーザに確認させることができる。
また、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１決済を行うことができる。

＜第１３実施例＞
第１２実施例では、表示残高の概念を新たに導入した。
第１２実施例で説明した表示残高は、設定された表示上の残高を表示させるものに過ぎなかったが、本実施例では、表示残高が決済処理に影響を及ぼし得る実施例について説明する。

第１２実施例と同様に、本実施例でも、同じユーザ（第１ユーザ）の２つのユーザアカウント（メインアカウント、サブアカウント）を連携アカウントとする場合について説明する。

ユーザによっては、連携ウォレットにおいて１回の決済に使用可能な電子マネー口座残高を制限したいと考えることもあり得る。
また、限定ではなく例として、ユーザが端末２０の紛失・盗難にあうなどして、自身の真の電子マネー口座残高を他人に見られてしまうような場合も想定される。

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

図１３−１は、本実施例において連携ウォレットを管理するためのデータベースの一例である第７の連携ウォレット管理データベース１５７Ｇのデータ構成例を示す図である。
第７の連携ウォレット管理データベース１５７Ｇには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、連携ウォレットＩＤと、連携アカウントデータと、決済履歴データとが記憶される。連携ウォレットＩＤと、決済履歴データとは、限定ではなく例として、第６の連携ウォレット管理データベース１５７Ｆと同様である。

連携アカウントデータには、この連携アカウントに対応するアプリケーションＩＤと、このアプリケーションＩＤに対応するユーザ名との他に、限定ではなく例として、表示上限金額が関連付けて記憶される。

表示上限金額とは、限定ではなく例として、表示残高を制限させるために設定される金額の一例であり、表示残高として表示され得る上限額として設定される金額である。
限定ではなく例として、図１３−１では、連携アカウントとして、ユーザＡ．ＡのメインアカウントであるアプリケーションＩＤ「Ｕ０００１」のユーザアカウントと、ユーザＡ．ＡのサブアカウントであるアプリケーションＩＤ「Ｕ０００５」のユーザアカウントとが関連付けられている。

また、アプリケーションＩＤ「Ｕ０００１」に対して表示上限金額は設定されていないが、アプリケーションＩＤ「Ｕ０００５」に対しては表示上限金額として「５，０００円」が設定されている。この場合、アプリケーションＩＤ「Ｕ０００５」の電子マネー口座残高が「５，０００円」を上回る場合、表示残高は「５，０００円」と表示される。
一方、電子マネー口座残高が「５，０００円」以下の場合には、電子マネー口座残高がそのまま表示残高として用いられる。

＜表示画面＞
ここでは、ユーザＡ．Ａのメインアカウントとサブアカウントとを連携アカウントとして連携させた連携ウォレットについて表示画面例を用いて説明する。ここで、サブアカウントの電子マネー口座残高は、「５，０００円」であり、表示上限金額が「５，０００円」に設定されていたとする。

図１３−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１３−２左側は、連携ウォレットのメイン画面であり、連携メンバー情報表示領域ＭＩＲ１に、ユーザＡ．Ａのメインアカウントの電子マネー口座残高（１０，０００円）と、ユーザＡ．Ａのサブアカウントについて設定された表示上限金額（５，０００円）に基づく表示残高（５，０００円）とが表示されている。

メインアカウントの表示欄には、電子マネー口座残高の情報とともに、表示上限金額を設定するための上限制限ボタンＢＴ４０が表示されている。
なお、サブアカウントについては表示上限金額が設定済みであるため、サブアカウントの表示欄には上限制限ボタンＢＴ４０は表示されていない。

メインアカウントの表示欄の上限制限ボタンＢＴ４０がタップされると、図１３−２中央に示す画面が表示される。この画面は、表示上限金額を入力するための画面であり、この例では、メインアカウントの表示上限金額として「３，０００円」が入力された状態が示されている。この状態で、画面下部の設定ボタンＢＴ４１がタップされると、連携ウォレットのメイン画面に戻り、図１３−２右側のような表示がなされる。
このメイン画面では、図１３−２左側のメイン画面とは異なり、ユーザＡ．Ａのメインアカウントの表示欄に、表示残高として「３，０００円」が表示されている。
また、表示上限金額が設定されたことに基づき、図１３−２左側の画面のメインアカウントの表示欄に表示されていた上限制限ボタンＢＴ４０は非表示とされている。

図１３−３左側は、図１３−２右側の画面でコードリーダアイコンＩＣ２がタップされたことに基づいて表示されるコードリーダ画面の一例を示す図である。
コード読み取り領域ＣＲ１内に支払い店舗コードが収まり、連携ウォレットコードリーダ情報が読み取られると、図１３−３中央に示す画面が表示される。この画面では、連携ウォレットでの支払い金額として「６，０００円」が入力された状態が示されている。

この例では、等分支払い金額は「３,０００円」である。
ユーザＡ．Ａのメインアカウントについては、電子マネー口座残高が「１０，０００円」であり、等分支払い金額を上回っている。
また、ユーザＢ．Ｂのサブアカウントについては、電子マネー口座残高は、「５，０００円」であり、等分支払い金額を上回っている。
このため、連携ウォレットによる決済は可能であり、この状態で画面下部の支払いボタンＢＴ１がタップされると、図１３−３右側の画面が表示される。

この画面には、連携ウォレットによる支払いが完了したことを示す情報が表示されている。
等分支払い金額が「３，０００円」であるため、メインアカウントについては、支払いによって電子マネー口座残高が「１０，０００円」→「７，０００円」となったが、表示残高「３，０００円」を上回っているため、表示残高として「３，０００円」が表示されている。
一方、サブアカウントについては、支払いによって電子マネー口座残高が「５，０００円」→「２，０００円」となったが、表示残高「３，０００円」を下回るため、表示残高として「２，０００円」が表示されている。

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

端末２０Ａの制御部２１は、限定ではなく例として、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、表示上限金額を受け付ける。すると、端末２０Ａの制御部２１は、表示上限金額を含む表示上限金額設定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６１０）。

通信Ｉ／Ｆ１４によって表示上限金額設定情報を受信すると、サーバ１０の制御部１１は、第７の連携ウォレット管理データベース１５７Ｇに表示上限金額を記憶させる。そして、サーバ１０の制御部１１は、記憶された表示上限金額に従い、各連携アカウントにおける表示残高を算出する。そして、サーバ１０の制御部１１は、算出された表示残高を含む上限制限付き連携アカウント残高情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ６１０）。

通信Ｉ／Ｆ２２によってサーバ１０から上限制限付き連携アカウント残高情報を受信すると、端末２０Ａの制御部２１は、各連携アカウントの表示残高を表示部２４に表示させる（Ａ６２０）。

なお、限定ではなく例として、Ｓ６１０のステップにおいて、サーバ１０が、真の電子マネー口座残高と表示上限金額とを端末２０Ａに送信するようにしてもよいし、そのようにしなくてもよい。
この場合、端末２０Ａの制御部２１は、受信した真の電子マネー口座残高と表示上限金額とを用いて表示残高を算出し、表示部２４に表示させるようにすることができる。

また、連携アカウントに対応する端末２０が複数である場合、サーバ１０から各連携アカウントの電子マネー口座残高を受信し、端末２０間で表示上限金額を送受信することで、各端末２０において表示残高を算出するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ１４によって連携決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた連携ウォレット支払いトークンから連携ウォレットＩＤを検索し、その連携ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う店舗提示型上限制限連携決済処理を実行する（Ｓ６９０）。

店舗提示型上限制限連携決済処理では、店舗提示型連携決済処理における各判定において、電子マネー口座残高の代わりに表示残高を使用する。すなわち、全ての連携アカウントにおいて「表示残高−等分支払い金額」の値が「０」以上となる場合、各連携アカウントに対して等分支払い金額の決済処理が実行され、店舗提示型上限制限連携決済処理は成功となる。
一方、いずれかのアカウントにおいて「表示残高−等分支払い金額」の値がマイナスとなる場合、連携アカウントへの決済処理は行われず、店舗提示型上限制限連携決済処理は失敗となる。

また、Ｓ２４０のステップで送信される連携決済結果情報においても、電子マネー口座残高の代わりに、決済処理後再計算された表示残高が送信される。

＜第１３実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）の第２ユーザアカウント（限定ではなく、第２アカウントの一例）に設定された表示上限金額（限定ではなく、第２金額の一例）に基づく表示残高（限定ではなく、第２金額に基づく第２アカウントの残高の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザの第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、表示上限金額が設定された第２ユーザアカウントとに基づき、連携アカウント決済に関する処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの第１アカウントに関連付けられた第２アカウントに設定された第２金額に基づく第２アカウントの残高を、第１ユーザに確認させることができる。
また、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済を行わせることができる。

また、本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）による自己の端末２０に対する入力に基づいて、第１ユーザアカウントに対して表示上限金額を設定する制御を制御部２１によって行う。そして、端末２０は、設定された表示上限金額に基づく第１ユーザアカウントの表示残高と、設定された表示上限金額に基づく第２ユーザアカウントの表示残高とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントに対しても表示上の金額（第１金額）を設定することができる。
また、設定された第１金額に基づく第１アカウントの残高と、設定された第２金額に基づく第２アカウントの残高との両方を、第１ユーザが確認できるようにすることができる。

また、この場合、第２ユーザアカウントに設定された表示上限金額の情報は、第２ユーザアカウントの電子マネー口座残高（限定ではなく、第２アカウントの残高の一例）のうち、第１ユーザの端末２０に表示される最大金額の情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントに設定された最大金額の情報を第１ユーザに確認させることができる。

また、この場合、第２ユーザアカウントに設定された表示上限金額の情報は、一回の連携アカウント決済に利用可能な最大金額の情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントに設定された一回の決済に利用可能な最大金額を第１ユーザに確認させることができる。

また、この場合、端末２０の表示部２４に表示される第２ユーザアカウントの表示残高は、第２ユーザアカウントの電子マネー口座残高が表示上限金額よりも大きい場合、表示上限金額が表示部２４に表示され、第２ユーザアカウントの電子マネー口座残高が表示上限金額よりも小さい場合、第２ユーザアカウントの電子マネー口座残高が表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントの残高と、第２アカウントに設定された第２金額との関係に基づいて、金額を適切に表示することができる。

＜第１３変形例（１）＞
上記の実施例では、決済処理として店舗提示型上限制限連携決済処理を実行したが、これに限定されない。限定ではなく例として、図１３−４のＳ６９０のステップにおいて、図１−１１のＳ１１０のステップで示した店舗提示型連携決済処理を実行するようにしてもよいし、そのようにしなくてもよい。

この場合、表示残高を上回る電子マネー口座残高を保有する場合、その電子マネー口座残高を用いて支払いを実行することができる。すなわち、表示残高は、表示上の値であり、決済処理に影響を及ぼすことはない。

＜第１３変形例（２）＞
上記の実施例では、各連携アカウントにおいて異なる表示上限金額が用いられる例を示したが、これに限定されない。
限定ではなく例として、連携ウォレットごとに所定の表示上限金額が定められている、または連携ウォレットごとに表示上限金額が設定されるようにしてもよいし、そのようにしなくてもよい。
この場合、ある連携アカウントの電子マネー口座残高が連携ウォレットの表示上限金額を上回る場合には、この連携アカウントの表示残高は、連携ウォレットの表示上限金額となる。

また、連携ウォレットの表示上限金額と、各連携アカウントの表示上限金額とがそれぞれ定められている、または設定されるようにしてもよいし、そのようにしなくてもよい。
この場合、連携ウォレットの表示上限金額より少ない金額のみを各連携アカウントにおいて表示上限金額として設定できるようにしてもよいし、そのようにしなくてもよい。
連携ウォレットの表示上限金額を上回る表示上限金額がある連携アカウントで設定される場合、この連携アカウントの表示残高では、アカウントごとに設定された表示上限金額が反映されることとしてもよいし、そのようにしなくてもよい。

＜第１３変形例（３）＞
上記の実施例では、連携アカウントとしてユーザアカウントを連携させた例を示したが、これに限定されない。限定ではなく例として、第８実施例で述べた共通ウォレットを連携アカウントとする連携ウォレットとしてもよいし、そのようにしなくてもよい。

この場合、第６の連携ウォレット管理データベース１５７Ｆの連携アカウントデータは、限定ではなく例として、第４の連携ウォレット管理データベース１５７Ｄと同様のウォレットＩＤと、名称との他、上記の表示上限金額を関連付けて記憶させるようにすればよい。

そして、共通ウォレットの共通ウォレット残高が表示上限金額を上回る場合には表示上限金額を、共通ウォレット残高が表示上限金額以下の場合には共通ウォレット残高を、共通ウォレットの表示残高として算出するようにすればよい。

本変形例は、第２アカウントは、共通ウォレットのアカウント（限定ではなく、共通アカウントの一例）である構成を示している。
このような構成により得られる変形例の効果の一例として、共通アカウントの真の残高を秘匿することができる。

＜第１３変形例（４）＞
表示上限金額が設定されたユーザアカウントについて、電子マネー口座残高の照会・表示に認証を必要としてもよいし、そのようにしなくてもよい。つまり、認証を行って認証結果がＯＫ（認証ＯＫ）とならない限り、電子マネー口座残高が端末２０の表示部２４に表示されないようにしてもよいし、そのようにしなくてもよい。
この場合、端末２０は、自己の端末２０のユーザによる入力に基づいて認証処理を制御部２１によって行い、認証ＯＫである場合に、電子マネー口座残高を表示部２４に表示させるようにすることができる。

限定ではなく例として、電子マネー口座残高が、設定された表示上限金額を上回っている場合は、表示残高として表示上限金額が表示されるため、真の電子マネー口座残高は秘匿される。この場合、認証ＯＫとならない限り、真の電子マネー口座残高は表示部２４に表示されないことになる。

なお、これは表示下限金額等の金額を設定する場合についても同様である。
限定ではなく例として、電子マネー口座残高が、設定された表示下限金額を下回っている場合は、表示残高として表示下限金額が表示されるため、真の電子マネー口座残高は秘匿される。この場合も、認証ＯＫとならない限り、真の電子マネー口座残高は表示部２４に表示されないことになる。

このようにすることで、前述したように、ユーザが端末２０の紛失・盗難にあうなどした場合であっても、自分の真の電子マネー口座残高を他人に知られてしまうことを防止できる。

また、端末２０のユーザが、上記の認証に関する設定（認証ＯＮ／ＯＦＦ）を行うことができるようにしてもよい。
この場合、自身が所有するユーザアカウントごとに、または自身が所有する全てのユーザアカウントについて一括的に、認証に関する設定を行うことができるようにしてもよい。
また、限定ではなく例として、表示残高を制限させるための金額（上記の表示上限金額や表示下限金額等）が設定されたユーザアカウントに対してのみ、認証ＯＮに設定するようにしてもよい。

＜第１４実施例＞
第１３実施例では、表示残高が決済処理に影響を及ぼし得る場合について説明した。
本実施例では、第１３実施例を前述の第１０実施例と組み合わせ、複数の連携メンバーにおける連携ウォレットにおいて、表示上限金額で制限を行った表示残高を導入する場合について説明する。
つまり、本実施例では、第１アカウントを第１ユーザのユーザアカウントとし、第２アカウントを第１ユーザとは異なる第２ユーザのユーザアカウントとして説明する。

前述したように、ユーザによっては、他の連携メンバーに対して、自分の真の電子マネー口座残高を開示することが憚られることが想定される。限定ではなく例として、電子マネー口座残高に多額の残高が存在するような場合、ユーザは、自分の真の電子マネー口座残高を秘匿したいと考えることが想定される。
また、前述したように、ユーザによっては、連携ウォレットにおいて１回の決済に使用可能な電子マネー口座残高を制限したいと考えることもあり得る。

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

図１４−１は、この場合において連携ウォレットを管理するためのデータベースの一例である第８の連携ウォレット管理データベース１５７Ｈのデータ構成例を示す図である。
第８の連携ウォレット管理データベース１５７Ｈには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、連携状況管理データと、決済履歴データと、立替履歴データとが記憶される。グループＩＤと、グループ名と、決済履歴データと、立替履歴データとは、限定ではなく例として、第５の連携ウォレット管理データベース１５７Ｅと同様である。

連携状況管理データには、アプリケーションＩＤと、ユーザ名と、連携承認との他、限定ではなく例として、表示上限金額が関連付けて記憶される。

本実施例では、限定ではなく例として、連携ウォレットへの参加を同意する際に、各連携メンバーが各自許容する表示上限金額を設定することができるように構成されている。

＜表示画面＞
図１４−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１４−２左側には、グループ「バンド仲間」のメンバーに対して、ウォレット連携を依頼するための画面が表示されている。画面下部のウォレット連携依頼ボタンＢＴ３５がタップされると、図１４−２中央の画面が表示される。

この画面は、ユーザＡ．Ａが自身の表示上限金額を設定するための画面であり、この例では、表示上限金額として「３，０００円」が入力された状態が示されている。この状態で、画面下部の設定ボタンＢＴ４１がタップされると、図１４−２右側の画面が表示される。

この例では、連携メンバー情報表示領域ＭＩＲ１において、ユーザＡ．Ａの欄に、電子マネー口座残高として「１０，０００円」が、表示残高として「３，０００円」がそれぞれ表示されている。

また、ユーザＢ．ＢおよびユーザＣ．Ｃについては、ユーザＡ．Ａからのウォレット連携の依頼に対する承認が未だなされていない状態であるため、それぞれ「依頼中」のマークが表示されている。

図１４−３は、ユーザＡ．Ａからのウォレット連携の依頼に基づいて、端末２０Ｂの表示部２４に表示される画面の遷移の一例を示す図である。
図１４−３左側には、支払いアプリケーションのおしらせ画面が表示されており、現在位置表示領域ＣＬＲ２の下には、ユーザＡ．Ａからウォレット連携の依頼があった旨の通知が表示されている。

また、その下のおしらせの内容が表示される表示領域には、ユーザＡ．Ａからのウォレット連携の依頼に関するウォレット連携依頼情報が表示されている。ウォレット連携依頼情報には、ユーザＡ．Ａからウォレット連携の依頼があったことを示す文字に加えて、その詳細を確認するための確認ボタンが表示されている。この確認ボタンがタップされると、図１４−３中央の画面が表示される。

この画面は、支払いアプリケーションの連携ウォレットのメイン画面であり、連携メンバー情報表示領域ＭＩＲ２には、グループ「バンド仲間」の各メンバーに関する情報が表示されている。ユーザＢ．Ｂの欄には、ウォレット連携を行うためのウォレット連携ボタンが表示されている。

ユーザＡ．Ａについては、ウォレット連携の依頼主であり、既に連携メンバーとなっているため、表示残高（この例では「３，０００円」）が表示されている。
また、ユーザＣ．Ｃについては、ユーザＡ．Ａからのウォレット連携の依頼に対する承認が未だなされていない状態であるため、「依頼中」のマークが表示されている。

ウォレット連携ボタンがタップされると、図１４−３右側の画面が表示される。
この画面は、ユーザＢ．Ｂが自身の表示上限金額を設定するための画面であり、この例では、表示上限金額として「４，０００円」が入力された状態が示されている。この状態で、画面下部の設定ボタンＢＴ４１がタップされると、図１４−４左側の画面が表示される。
この画面では、連携メンバー情報表示領域ＭＩＲ２において、ユーザＢ．Ｂの欄に、電子マネー口座残高として「６，０００円」が、表示残高として「４，０００円」がそれぞれ表示されている。

一方、ユーザＢ．Ｂによるウォレット連携の承認に伴い、端末２０Ａ側では、図１４−４右側に示すような画面が表示される。
端末２０Ａ側では、連携メンバー情報表示領域ＭＩＲ１において、ユーザＢ．Ｂの欄に表示されていた「依頼中」のマークが消え、その代わりに、表示残高として「４，０００円」が表示されている。
なお、ユーザＣ．Ｃについては、ユーザＡ．Ａからのウォレット連携の依頼に対する承認が未だなされていない状態であるため、「依頼中」のマークが表示されたままである。

図１４−５は、ユーザＡ．Ａからのウォレット連携の依頼に基づいて、端末２０Ｃの表示部２４に表示される画面の遷移の一例を示す図である。
図１４−５左側には、支払いアプリケーションのおしらせ画面が表示されており、現在位置表示領域ＣＬＲ３の下には、ユーザＡ．Ａからウォレット連携の依頼があった旨の通知が表示されている。

また、その下のおしらせの内容が表示される表示領域には、ユーザＡ．Ａからのウォレット連携の依頼に関するウォレット連携依頼情報が表示されている。ウォレット連携依頼情報には、ユーザＡ．Ａからウォレット連携の依頼があったことを示す文字に加えて、その詳細を確認するための確認ボタンが表示されている。

確認ボタンがタップされ、端末２０Ｂでの図１４−３中央→図１４−３右側の流れによって、ユーザＣ．Ｃによってウォレット連携の承認、表示上限金額の設定がなされると、図１４−５中央の画面が表示される。

この画面では、連携メンバー情報表示領域ＭＩＲ３において、ユーザＣ．Ｃの欄に、電子マネー口座残高として「２，００００円」が、表示残高として「１０，０００円」がそれぞれ表示されている。

一方、ユーザＣ．Ｃによるウォレット連携の承認に伴い、端末２０Ａ側では、図１４−５右側に示すような画面が表示される。
端末２０Ａ側では、連携メンバー情報表示領域ＭＩＲ１において、ユーザＣ．Ｃの欄に表示されていた「依頼中」のマークが消え、その代わりに、表示残高として「１０，０００円」が表示されている。

また、グループ「バンド仲間」の全てのメンバーのウォレット連携が完了したことに伴い、コードリーダアイコンＩＣ２およびコード支払いアイコンＩＣ３のグレーアウトが解除され、アクティブな状態に変化して表示されている。

この状態で、図１４−６左側に示すように、ユーザＡ．Ａによってコード支払いアイコンＩＣ３がタップされると、図１４−６中央に示す画面が表示される。この画面は、前述したコード支払い画面である。

コード支払い画面に表示された支払いコードが店舗コードリーダ装置によって読み取られ、サーバ１０によって利用者提示型の連携ウォレットの決済処理が行われると、図１４−６右側に示す連携支払い確認画面が表示される。
この連携支払い確認画面では、現在位置表示領域ＣＬＲ１の下に、支払い金額確認領域ＰＩＲ３が表示されている。支払い金額確認領域ＰＩＲ３には、支払い金額として「１２，０００円」が表示されている。

ここで、本実施例における連携支払い可能額は、支払い金額を連携アカウントで等分して割り勘すると仮定し、以下の式で定義される金額である。
・連携支払い可能額＝全ての連携アカウントについての支払い余力の総和

ここで、一の連携アカウントの支払い余力は、以下の式で定義される。
・一の連携アカウントの支払い余力＝その連携アカウントの表示残高（その連携アカウントの表示残高−等分支払い金額＜０の場合）
・一の連携アカウントの支払い余力＝等分支払い金額（その連携アカウントの表示残高−等分支払い金額≧０の場合）
ただし、「等分支払い金額＝支払い金額÷連携アカウント数」として算出される。

なお、本実施例では、連携メンバーと連携アカウントとは一対一の対応関係であるため、上記の式における連携アカウントは、連携メンバーと実質的に同義である。

この例では、等分支払い金額は「１２，０００円÷３＝４，０００円」である。
ユーザＡ．Ａのユーザアカウントについては、その表示残高が「３，０００円」であり、等分支払い金額「４，０００円」を下回るため、その支払い余力は「３，０００円」となる。
ユーザＢ．Ｂのユーザアカウントについては、その表示残高が「４，０００円」であり、等分支払い金額「４，０００円」と同額であるため、その支払い余力は「４,０００円」となる。
ユーザＣ．Ｃのユーザアカウントについては、その表示残高が「１０，０００円」であり、等分支払い金額「４，０００円」を上回るため、その支払い余力は「４,０００円」となる。
よって、連携支払い可能額は、「３，０００円＋４，０００円＋４，０００円＝１１，０００円」となる。

この例では、支払い金額は「１２，０００円」であるのに対し、連携支払い可能額は「１１，０００円」であるため、「１，０００円」不足することになる。
その結果、支払い金額確認領域ＰＩＲ３には、警告マークと「残高不足です」の文字とが表示されている。

また、この例では、支払い余力が不足するのはユーザＡ．Ａのユーザアカウントであるため、支払いメンバー確認領域ＰＭＲ３には、ユーザＡ．Ａのアイコンの左上に警告マークが表示されている。

この場合、ユーザＡ．Ａは、連携ウォレットによる支払いを可能とするために、先に設定した自身のユーザアカウントに対する表示上限金額を変更することができる。

図１４−７は、この場合における端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１４−７左側では、図１４−６右側の画面の中央部に、表示上限金額を変更するための情報がポップアップ形式で表示されている。具体的には、「この支払いに関して表示上限金額を変更しますか？」の文字とともに、表示上限金額を、現在設定されている「３，０００円」から「４，０００円」に変更するように促す情報が表示されている。また、この変更に同意する場合に操作する「はい」のボタンと、この変更に同意しない場合に操作する「いいえ」のボタンとが表示されている。

「はい」のボタンがタップされると、図１４−７中央の画面が表示される。この画面では、図１４−６右側の画面において支払い金額確認領域ＰＩＲ３に表示されていた警告マークと「残高不足です」の文字とが消え、「支払い可能です」の文字が表示されている。
この状態で、画面下部の連携支払い実行ボタンＢＴ５がタップされると、図１４−７右側の連携支払い結果表示画面が表示される。

また、連携支払い結果表示画面の下部には、この支払いに関する連携アカウントごとの内訳を表すメンバー支払い結果表示領域ＭＲＲ１が表示されている。
メンバー支払い結果表示領域ＭＲＲ１には、連携アカウントごとに、支払ったユーザアカウントと、それぞれのユーザアカウントで支払った金額と、支払い後の表示残高とが表示されている。
この画面では、ユーザＡ．Ａの表示残高は変更前の「３，０００円」に戻っている。また、ユーザＢ．Ｂの表示残高は、電子マネー口座残高が「６，０００円−４，０００円＝２，０００円」となったことに基づいて、「２，０００円」に更新される。

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

端末２０Ａの制御部２１は、Ａ５１０のステップを実行すると、Ａ６１０のステップを実行する。また、端末２０Ｂの制御部２１は、Ｂ５１０のステップを実行すると、Ｂ６１０のステップを実行する。Ｂ６１０のステップについては、Ａ６１０のステップと同様に処理を実行することができるため、詳細な説明を省略する。

通信Ｉ／Ｆ１４によって連携メンバーの端末２０から表示上限金額設定情報を受信すると、サーバ１０の制御部１１は、受信した端末のアプリケーションＩＤにおける連携状況管理データの連携承認を「済」に変更する。

次いで、サーバ１０の制御部１１は、受信した表示上限金額設定情報に基づく表示上限金額と、連携したメンバーの電子マネー口座残高とに基づいて、表示残高を算出する。そして、サーバ１０の制御部１１は、限定ではなく例として、連携したメンバーのアプリケーションＩＤと表示残高とを含む制限付き連携メンバー情報を、通信Ｉ／Ｆ１４によってグループの各メンバーの端末２０に送信する（Ｓ６３０）。

端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によって制限付き連携メンバー情報を受信すると、受信した制限付き連携メンバー情報を表示部２４に表示させる（Ａ６３０）。
端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によって制限付き連携メンバー情報を受信すると、受信した制限付き連携メンバー情報を表示部２４に表示させる（Ｂ６３０）。

通信Ｉ／Ｆ１４によって連携決済要求情報を受信すると、サーバ１０の制御部１１は、表示残高に基づいて連携支払い可能額を算出し、算出された連携支払い可能額が決済予定金額を下回っているか否か（連携支払い可能額−決済予定金額＜０であるか否か）を判定する（Ｓ６４０）。

連携支払い可能額が決済予定金額を下回っていない場合（連携支払い可能額−決済予定金額が０以上となる場合）には（Ｓ６４０：ＮＯ）、表示残高内で連携ウォレットを用いた支払いが可能であるため、サーバ１０の制御部１１は、Ｓ６９０のステップに処理を移す。

連携支払い可能額が決済予定金額を下回る場合には（Ｓ６４０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ２２０のステップを実行する。

通信Ｉ／Ｆ２２によってサーバ１０から連携残高不足情報を受信する場合（Ａ２００：ＹＥＳ）、端末２０Ａの制御部２１は、自端末のユーザ（この場合にはユーザＡ．Ａ）の表示残高を、限定ではなく例として、ユーザＡ．Ａの支払い余力の不足分（すなわち等分支払い金額−ユーザＡ．Ａの支払い余力）以上に上昇させるための表示上限金額加算額を含む表示上限金額変更情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６４０）。

なお、表示上限金額加算額は、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、設定されるようにしてもよいし、ユーザＡ．Ａの支払い余力の不足分に応じて自動的に決定されるようにしてもよい。

連携残高不足情報を受信しない場合には（Ａ２００：ＮＯ）、端末２０Ａの制御部２１は、Ａ６４０のステップをスキップする。

通信Ｉ／Ｆ１４によって端末２０Ａから表示上限金額変更情報を受信すると、サーバ１０の制御部１１は、受信した表示上限金額変更情報の表示上限金額加算額を、ユーザＡ．Ａの表示上限金額に加算し、再度表示金額を算出する（Ｓ６８０）。

なお、サーバ１０の制御部１１は、Ｓ６８０のステップで表示金額が更新された後、更新された表示金額を通信Ｉ／Ｆ１４によって連携メンバーの端末へ送信し、各端末で表示残高を更新して表示させるようにしてもよいし、そのようにしなくてもよい。

そして、サーバ１０の制御部１１は、Ｓ６９０のステップを実行する。

なお、Ｓ６９０のステップを実行後、サーバ１０の制御部１１は、表示上限金額加算額をユーザＡ．Ａの表示上限金額から減算し、元の表示上限金額に戻すようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、Ａ６４０のステップにおいて、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、表示上限金額加算額の加算を一時的なものにするか恒久的なものにするかを設定可能なようにしてもよいし、そのようにしなくてもよい。

なお、図１４−８〜図１４−１０では、一度の決済処理についてのフローを示したが、図１４−１０の後に、限定ではなく例として、図７−４の処理を実行することで、複数回の決済処理を実行するようにしてもよいし、そのようにしなくてもよい。

また、表示上限金額の設定は、連携ウォレットの参加時に設定することとしたが、これに限定されない。限定ではなく例として、任意のタイミングで表示上限金額を再設定できるようにしてもよいし、そのようにしなくてもよい。限定ではなく例として、支払いの目安となる金額が分かる場合、連携支払い可能額が目安となる金額を上回るように、連携メンバーが表示上限金額を設定するようにしてもよいし、そのようにしなくてもよい。

＜第１４実施例の効果＞
本実施例は、端末２０が、異なる端末２０のユーザ（限定ではなく、第２ユーザの一例）の第２ユーザアカウント（限定ではなく、第２アカウントの一例）に設定された表示上限金額（限定ではなく、第２金額の一例）に基づく表示残高（限定ではなく、第２金額に基づく第２アカウントの残高の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザの第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、表示上限金額が設定された第２ユーザアカウントとに基づき、第１ユーザの端末２０によって連携アカウント決済に関する処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの第１アカウントに関連付けられた第２アカウントに設定された第２金額に基づく第２アカウントの残高を、第１ユーザに視認させることができる。この場合、限定ではなく例として、第２アカウントの真の残高に対応する金額とは異なる金額が第２金額として設定されることで、第２アカウントの真の残高を第１ユーザに秘匿することができる。
また、第１アカウントと、第２金額が設定された第２アカウントとに基づき、第１ユーザの端末によって第１決済を行わせることができる。

また、本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）による自己の端末２０に対する入力に基づいて、第１ユーザアカウントに対して表示上限金額を設定する制御を制御部２１によって行う。そして、端末２０は、設定された表示上限金額に基づく第１ユーザアカウントの表示残高と、設定された表示上限金額に基づく第２ユーザアカウントの表示残高とを表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントに対しても表示上の金額（第１金額）を設定することができる。この場合、限定ではなく例として、第１アカウントの真の残高に対応する金額とは異なる金額を第１金額として設定することで、第１アカウントの真の残高を他のユーザに秘匿することができる。
また、設定された第１金額に基づく第１アカウントの残高と、設定された第２金額に基づく第２アカウントの残高との両方を、第１ユーザが確認できるようにすることができる。

また、この場合、第２ユーザアカウントに設定された表示上限金額の情報は、第２ユーザアカウントの電子マネー口座残高（限定ではなく、第２アカウントの残高の一例）のうち、第１ユーザの端末２０に表示される最大金額の情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントの真の残高を秘匿した上で、設定された最大金額を第１ユーザに視認させることができる。

また、この場合、第２ユーザアカウントに設定された表示上限金額の情報は、一回の連携アカウント決済に利用可能な最大金額の情報を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントに設定された一回の決済に利用可能な最大金額を第１ユーザに視認させることができる。

また、この場合、端末２０の表示部２４に表示される第２ユーザアカウントの表示残高は、第２ユーザアカウントの電子マネー口座残高が表示上限金額よりも大きい場合、表示上限金額が表示部２４に表示され、第２ユーザアカウントの電子マネー口座残高が表示上限金額よりも小さい場合、第２ユーザアカウントの電子マネー口座残高が表示されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントの残高が第２金額よりも大きい場合は、第２アカウントの真の残高が第１ユーザに秘匿されるようにすることができる。他方、第２アカウントの残高が第２金額よりも小さい場合は、第２アカウントの真の残高を第１ユーザに開示することができる。

また、本実施例は、端末２０は、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）による自己の端末２０に対する入力に基づいて、第１ユーザアカウントに設定された表示上限金額を変更する制御を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントに一旦設定された第１金額を変更することができる。

また、本実施例は、第２ユーザアカウントは、第２ユーザのユーザアカウントである構成を示している。
このような構成により得られる実施例の効果の一例として、第１ユーザの第１アカウントと、第１アカウントと関連付けられた第２ユーザの第２アカウントとに基づき、決済を実現することができる。

＜第１４変形例（１）＞
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。

限定ではなく例として、支払いを実行するユーザＡ．Ａ以外の支払い余力が足りない場合、図１４−１０のＡ６４０のステップにおいて、端末２０Ａの制御部２１は、他の連携メンバーの支払い余力の不足分を上回るように表示上限金額加算額を設定するようにしてもよいし、そのようにしなくてもよい。

＜第１４変形例（２）＞
上記の実施例では、支払いの実行者（この例ではユーザＡ．Ａ）の表示上限金額を引き上げることで、支払い余力の不足を解決する例を示したが、これに限定されない。
限定ではなく例として、他の連携メンバーに対して、表示上限金額の引き上げを要求するようにしてもよいし、そのようにしなくてもよい。

図１４−１１〜図１４−１２は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
限定ではなく例として、図１４−８〜図１４−９の各ステップの実行後、図１４−１１〜図１４−１２の処理が実行される。

通信Ｉ／Ｆ２２によってサーバ１０から連携残高不足情報を受信する場合（Ａ２００：ＹＥＳ）、端末２０Ａの制御部２１は、他の連携メンバー（例えばユーザＢ．Ｂ）の表示残高を、限定ではなく例として、ユーザＡ．Ａの支払い余力の不足分以上に上昇させることを要求するための表示上限金額変更要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６５０）。

なお、端末２０Ａの制御部２１は、限定ではなく例として、ユーザ操作に基づいて、表示上限金額加算額についての設定を行い、表示上限金額加算額を含む表示上限金額変更要求情報を送信するようにしてもよいし、そのようにしなくてもよい。

また、表示残高の引き上げを依頼する連携メンバーは、限定ではなく例として、表示残高の多いメンバーが自動的に選択されるようにしてもよいし、ユーザに選択させるようにしてもよい。

通信Ｉ／Ｆ１４によって端末２０Ａから表示上限金額変更要求情報を受信すると、サーバ１０の制御部１１は、表示上限金額変更要求情報に基づいて、表示残高の引き上げを依頼するための表示上限金額変更依頼情報を通信Ｉ／Ｆ１４によって表示残高の引き上げを依頼する連携メンバー（例えばユーザＢ．Ｂ）の端末に送信する。

なお、サーバ１０の制御部１１は、支払い余力の不足分に基づいて、表示上限金額加算額を算出し、表示上限金額変更依頼情報に算出した表示上限金額加算額を含み送信するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から表示上限金額変更依頼情報を受信する場合（Ｂ６４０：ＹＥＳ）、端末２０Ｂの制御部２１は、表示上限金額変更情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ６５０）。処理の詳細については図１４−１０のＡ６４０のステップと同様である。

なお、限定ではなく例として、端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、表示上限金額の引き上げを拒否する場合、端末２０Ｂの制御部２１は、Ｂ６５０のステップを実行しないようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ１４によって端末２０Ｂから表示上限金額変更情報を受信する場合、サーバ１０の制御部１１は、Ｓ６８０のステップを実行し、Ｓ６９０のステップを実行する。

なお、Ａ６５０のステップにおいて、端末２０Ａの制御部２１は、表示上限金額変更依頼情報を通信Ｉ／Ｆ２２によって直に端末２０Ｂに送信するようにしてもよいし、そのようにしなくてもよい。

本変形例は、端末２０が、アカウント連携決済の決済金額（限定ではなく、第１決済の金額の一例）が、連携アカウントの表示上限金額の合計を超える場合、第２ユーザアカウントに対して表示上限金額変更要求情報（限定ではなく、第２金額の変更に関する情報の一例）を通信Ｉ／Ｆ２２によって送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１決済の金額が第１金額と第２金額の合計を超えていて第１決済を行うことができないような場合に、設定された第２金額を変更するように第２アカウントに要請することができる。

＜第１４変形例（３）＞
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。
限定ではなく例として、第３実施例で述べたように、他の連携メンバーに支払い余力の立て替えを依頼するようにしてもよいし、そのようにしなくてもよい。

＜表示画面＞
図１４−１３は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１４−１３左側は、図１４−６右側の連携支払い確認画面と同様の画面であるが、その表示が一部異なっている。具体的には、画面下部に、ユーザＡ．Ａが、不足分の金額を他のユーザに立て替えてもらうための立て替え依頼ボタンＢＴ４が表示されている。

支払いメンバー確認領域ＰＭＲ３のユーザＡ．Ａの項目には、表示上限金額を変更するための「上限変更」と記載された上限金額変更ボタンが配置されている。上限金額変更ボタンがタップされる場合には、限定ではなく例として、図１４−７左側の画面に遷移する。

立て替え依頼ボタンＢＴ４がタップされると、図１４−１３中央の画面が表示される。
この画面では、グループ「バンド仲間」の連携ウォレットであることを示す情報の下に、立て替えを依頼する連携メンバーの候補を選択するための領域が表示されている。この例では、立て替えを依頼する連携メンバーの候補としてユーザＣ．Ｃが表示されている。
なお、この例では、ユーザＢ．Ｂは表示残高が「４，０００円」であり、ユーザＡ．Ａの不足分の金額を立て替える余力がないため、立て替えを依頼する連携メンバーの候補として表示されていない。

立て替えを依頼する連携メンバーの候補（この例ではユーザＣ．Ｃ）には、ラジオボタンが関連付けて表示されており、ラジオボタンがタップされて「ＯＮ」とされると、その連携メンバーが、立て替えを依頼する連携メンバーとして選択される。すると、図１４−１３右側に示す画面が表示される。

この画面では、図１４−１３左側の画面において支払い金額確認領域ＰＩＲ３に表示されていた警告マークと「残高不足です」の文字とが消え、「支払い可能です」の文字が表示されている。
この状態で、画面下部の連携支払い実行ボタンＢＴ５がタップされると、支払いが実行される。

なお、複数の連携メンバーが立て替え可能な場合には、限定ではなく例として、端末２０Ａの制御部２１は、立て替えてもらうメンバー候補として表示残高の多い順に並べて表示させるようにしてもよいし、そのようにしなくてもよい。
また、最も表示残高の多い連携メンバーを立て替え者として提案させるようにしてもよいし、そのようにしなくてもよい。

＜処理＞
図１４−１４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
限定ではなく例として、図１４−８〜図１４−９の各ステップの実行後、図１４−１４の処理が実行される。

通信Ｉ／Ｆ１４によって端末２０Ａから連携決済要求情報を受信すると、サーバ１０の制御部１１は、Ｓ６４０のステップを実行する。連携支払い可能額が決済予定金額を下回る場合には（Ｓ６４０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ２２０のステップを実行する。

サーバ１０の制御部１１は、Ｓ２３５のステップを実行すると、Ｓ６９０のステップを実行する。その後、Ｓ２４０のステップを実行する。

なお、図１４−１４の処理を実行後、限定ではなく例として、図７−４の処理を実行することで、連携残高補充処理で発生した立て替えを精算する処理を実行するようにしてもよいし、そのようにしなくてもよい。

本変形例は、アカウント連携決済（限定ではなく、第１決済の一例）は、第１ユーザアカウントと、第２ユーザアカウントと、これらのユーザアカウントと連携した第３ユーザアカウントとによって行われ、第１ユーザアカウントの不足分を支払うユーザアカウントは、第２ユーザアカウントに設定された表示上限金額と、第３ユーザアカウントに設定された表示上限金額とに基づいて、第２ユーザアカウントと第３ユーザアカウントのいずれかのうち一方が設定される構成を示している。
このような構成により得られる実施例の効果の一例として、第２アカウントに設定された第２金額と、第３アカウントに設定された第３金額とに基づいて、第１アカウントの不足分を支払うアカウントを適切に設定することができる。限定ではなく例として、第２アカウントと第３アカウントのうち、設定された金額が高い方のアカウントを、第１アカウントの不足分を支払うアカウントに設定することができる。

＜第１４変形例（４）＞
第１４実施例では、サーバ１０が、連携メンバーの端末２０から取得した表示上限金額と、その連携メンバーの電子マネー口座残高とに基づいて、表示残高を算出した上で、各々の連携メンバーの端末２０に送信することとしたが、これに限定されない。

限定ではなく例として、サーバ１０を介さずに、端末２０間の通信によって、上記の実施例と同様の処理を行うようにしてもよいし、そのようにしなくてもよい。

また、限定ではなく例として、サーバ１０が、連携メンバーの端末２０の表示残高に代えて、その連携メンバーの端末２０の電子マネー口座残高を、各々の連携メンバーの端末２０に送信する。そして、連携メンバーの端末２０が、サーバ１０から取得する以外の方法で取得した表示上限金額（限定ではなく例として、連携メンバー同士で予め取り決めておいた表示上限金額、表示上限金額を設定した連携メンバーに教えてもらった表示上限金額、表示上限金額を設定した連携メンバーの端末２０から受信した表示上限金額等）に基づいて、表示残高を算出するようにしてもよい。
つまり、端末２０側で、表示する第２アカウントの残高の金額を制御するようにしてもよい。

＜第１５実施例＞
第１４実施例では、表示残高は表示上限金額による制限を受けることとした。表示上限金額は、個々の支払いにおいて連携支払い可能額に影響を及ぼす制限であった。
本実施例では、表示上限金額以外に、連携ウォレットにおいて複数回の支払いが生じる場合に影響を及ぼす制限として、限定ではなく例として、連続決済回数と、合計制限金額との２つの制限を導入する。

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

図１５−１は、この場合において連携ウォレットを管理するためのデータベースの一例である第９の連携ウォレット管理データベース１５７Ｉのデータ構成例を示す図である。
第９の連携ウォレット管理データベース１５７Ｉには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、連携状況管理データと、決済履歴データと、立替履歴データとが記憶される。グループＩＤと、グループ名と、決済履歴データと、立替履歴データとは、限定ではなく例として、第８の連携ウォレット管理データベース１５７Ｈと同様である。

連携状況管理データには、アプリケーションＩＤと、ユーザ名と、連携承認と、表示上限金額との他に、限定ではなく例として、連続決済回数と、合計制限金額とが関連付けて記憶される。

連続決済回数は、この連携ウォレットを用いて支払いを行うことが可能な回数である。限定ではなく例として、ユーザＢ．Ｂの連続決済回数が５回に設定されている場合、５回までは、ユーザＢ．Ｂの電子マネー口座残高から、表示残高内での支払いを実行することができる。

合計制限金額は、この連携ウォレットを用いて支払いを行う場合、個々の連携アカウントが負担可能な合計金額である。限定ではなく例として、ユーザＡ．Ａの合計制限金額が「１０，０００円」に設定されている場合、支払いの回数によらず、この連携ウォレットによる支払いでユーザＡ．Ａは合計「１０，０００円」までの支払い分を負担する。そして、合計制限金額を超えると、ユーザＡ．Ａのアカウントからは支払いが行われなくなる。

合計制限金額を導入すると、各連携アカウントの表示残高は、以下のようになる。
・表示残高＝ＭＩＮ（ＭＩＮ（表示上限金額，合計制限金額），電子マネー口座残高）
ただし、ＭＩＮ（ｘ，ｙ）は、（ｘ，ｙ）のうち最小値を取る関数である。
すなわち、合計制限金額は、当初の定義から逸脱しないためには、表示上限金額以上の金額に設定する必要がある。

なお、表示上限金額・合計制限金額・連続決済回数が設定されていない場合には、それらの値は十分大きい任意の数（限定ではなく例として、無量大数）として取り扱うことができる。

＜表示画面＞
図１５−２は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１５−２左側の画面において、画面下部のウォレット連携依頼ボタンＢＴ３５がタップされると、図１５−２中央の利用制限設定画面が表示される。

この利用制限設定画面には、ユーザＡ．Ａのユーザアカウントに関する情報の表示欄の下に、表示上限金額の設定に関する情報（この例では設定済み／未設定）と、連続決済回数の設定に関する情報（この例では設定済み／未設定）と、合計制限金額の設定に関する情報（この例では設定済み／未設定）とが表示されている。各々の設定に関する情報には、設定内容を変更するための変更ボタンが関連付けて表示されている。

また、画面下部には、現在表示されている設定内容で設定を完了させて確定させるための設定完了ボタンＢＴ４３が表示されている。

限定ではなく例として、表示上限金額の欄の変更ボタンがタップされると、図１５−２右側の画面が表示される。
この画面は、表示上限金額を変更するための画面であり、この例では、変更する表示上限金額として「３，０００円」が入力された状態が示されている。この状態で、画面下部の設定ボタンＢＴ４１がタップされると、入力された金額に表示上限金額が設定される。

図１５−３左側は、図１５−２中央の利用制限設定画面において、表示上限金額と、連続決済回数と、合計制限金額とが設定された状態が示されている。この例では、表示上限金額として「３，０００円」が、連続決済回数として「１０回」が、合計制限金額として「１０，０００円」がそれぞれ設定された状態が示されている。この状態で、画面下部の設定完了ボタンＢＴ４３がタップされると、図１５−３中央の画面が表示される。

この画面は、連携ウォレットのメイン画面であり、連携メンバー情報表示領域ＭＩＲ４のユーザＡ．Ａの欄には、表示残高「３，０００円」と電子マネー口座残高「１０，０００円」とが表示されている。また、その下には、表示上限金額「３，０００円」と、連携決済回数「１０回」と、合計制限金額「１０，０００円」とが表示されている。

図１５−３右側は、上記において、ユーザＢ．Ｂ、ユーザＣ．Ｃによる連携の承認が取れた場合における連携ウォレットのメイン画面である。
この画面では、連携メンバー情報表示領域ＭＩＲ４のユーザＢ．Ｂ、ユーザＣ．Ｃの欄の「依頼中」の文字が消え、それぞれの表示残高が表示されている。
また、連携メンバー情報表示領域ＭＩＲ４のユーザＡ．Ａの欄には、表示残高「３，０００円」と電子マネー口座残高「１０，０００円」とが表示されている。また、その下には、表示上限金額「３，０００円」と、連携決済回数「１０回」と、合計制限金額「１０，０００円」とが表示されている。
また、グループ「バンド仲間」の全てのメンバーのウォレット連携が完了したことに伴い、コードリーダアイコンＩＣ２およびコード支払いアイコンＩＣ３のグレーアウトが解除され、アクティブな状態に変化して表示されている。

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

端末２０Ａの制御部２１は、Ａ５１０のステップを実行すると、限定ではなく例として、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、表示上限金額と、合計制限金額と、連続決済回数とを受け付ける。すると、端末２０Ａの制御部２１は、設定された表示上限金額と、合計制限金額と、連続決済回数とを含むアカウント制限設定情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６１５）。

端末２０Ｂの制御部２１は、Ｂ５１０のステップを実行すると、Ａ６１５のステップと同様なＢ６１５のステップを実行する。

通信Ｉ／Ｆ１４によって端末２０Ｂからアカウント制限設定情報を受信すると、サーバ１０の制御部１１は、受信した端末のアプリケーションＩＤにおける連携状況管理データの連携承認を、「済」に変更する。次いで、サーバ１０の制御部１１は、受信した表示上限金額と合計制限金額と、連携したメンバーの電子マネー口座残高とに基づいて、表示残高を算出する。そして、限定ではなく例として、連携したメンバーのアプリケーションＩＤと表示残高とを含む制限付き連携メンバー情報を、通信Ｉ／Ｆ１４によってグループの各メンバーの端末に送信する（Ｓ６３５）。

なお、制限付き連携メンバー情報に、各連携アカウントの連続決済回数を含めるようにしてもよいし、そうしなくてもよい。

通信Ｉ／Ｆ１４によって連携決済要求情報を受信すると、サーバ１０の制御部１１は、連続決済回数が０より大きい連携アカウントについて、表示残高に基づいて支払い余力を算出し、連携支払い可能額を算出する。連続決済回数が０であるアカウントについては、支払い余力を０とする。すなわち、連続決済回数が０である連携アカウントは、支払いの分担対象から外される。
そして、サーバ１０の制御部１１は、算出された連携支払い可能額が決済予定金額を下回っているか否かを判定する（Ｓ６４５）。

通信Ｉ／Ｆ１４によって連携決済要求情報を受信すると、サーバ１０の制御部１１は、店舗提示型制限連携決済処理を実行する（Ｓ６９５）。

店舗提示型制限連携決済処理では、Ｓ６９０のステップでの処理を実行後、決済処理が成功した場合には、各連携アカウントの合計制限金額と、連続決済回数とを更新する。
すなわち、連続決済回数をデクリメントし、合計制限金額からその連携アカウントの支払い余力を減算する。

なお、連続決済回数と合計制限金額との設定は変化させず、連続決済回数と合計制限金額とに紐づけられる一時記憶域の値を書き換えるようにしてもよいし、そのようにしなくてもよい。この場合には、この一時記憶域に記憶され、更新された連続決済回数と合計制限金額とが上記のステップでの表示金額の算出や支払い余力の決定等に使用される。

Ｓ６９５のステップを実行すると、サーバ１０の制御部１１は、連携決済結果情報を連携メンバーの端末に送信し（Ｓ２４０）、処理を終了するか否かの判定を行う（Ｓ６９９）。限定ではなく例として、連携メンバーの端末２０において処理が継続している場合には、サーバ１０の制御部１１は、処理を継続させ（Ｓ６９９：ＮＯ）、再度Ｓ１００のステップを実行する。

通信Ｉ／Ｆ２２によってサーバ１０から連携決済結果情報を受信すると、端末２０Ａの制御部２１は、限定ではなく例として、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、処理を継続するか否かを判定する（Ａ６９９）。処理を継続する場合（Ａ６９９：ＮＯ）、端末２０Ａの制御部２１は、再度連携ウォレットコードリーダ情報を受信し、Ａ１００のステップを実行する。

端末２０Ｂについても同様である。

なお、図１５−４〜図１５−６の処理と図７−４の処理とを組み合わせ、連携ウォレットの破棄まで処理を継続するようにしてもよいし、そのようにしなくてもよい。

＜第１５実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）による自己の端末２０に対する入力に基づいて、第１ユーザアカウントに対して、連続決済回数等の設定（限定ではなく、決済を複数回行うことに関する第１設定の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、決済を複数回行うことに関する設定を、第１アカウントに対して簡易かつ適切に行うことができる。

また、この場合、上記の設定は、連続決済回数の設定（限定ではなく、第１ユーザアカウントによって決済が可能な回数に関する設定の一例）を含む構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントによって決済が可能な回数に関する設定を、簡易かつ適切に行うことができる。

また、この場合、上記の連続決済回数は、第１ユーザアカウントの第１ユーザの認証を行わずに決済を行うことが可能な回数を含む構成を示している。
このような構成により得られる実施例の効果の一例として、決済の回数が、第１設定によって設定された決済が可能な回数に達していない間は、第１ユーザの認証を不要として、第２アカウントと、第１ユーザの第１アカウントとに基づく決済を可能とすることができる。その一方で、決済の回数が、第１設定によって設定された決済が可能な回数に達している場合は、第１ユーザによる認証を必要とし、第１ユーザによって認証されなければ、第２アカウントと、第１ユーザの第１アカウントとに基づき決済が行われないようにすることができる。

＜第１５変形例（１）＞
上記の実施例では、支払いが繰り返し実行され、連携メンバーの連続決済回数が「０」以下になるか、合計制限金額が「０」以下になる場合、そのメンバーのアカウントからの支払いが実行されなくなる例を示したが、これに限定されない。

限定ではなく例として、支払いが繰り返し実行され、連携メンバーの連続決済回数が「０」以下になるか、合計制限金額が「０」以下になる場合（連携アカウントにおいて設定された連続決済回数や合計制限金額を超える場合）、この連携ウォレットでの支払いが実行できなくなる（限定ではなく例として、連携ウォレット支払いトークンの生成を止める）ようにしてもよいし、そのようにしなくてもよい。
この場合、限定ではなく例として、自動的に連携ウォレットの破棄が実行されるようにしてもよいし、そうしなくてもよい。

＜第１５変形例（２）＞
上記の実施例では、連携ウォレットの支払い回数に対して連続決済回数による制限をかけていたが、これに限定されない。
限定ではなく例として、支払いを実行する各連携メンバーに対してそれぞれ連続決済回数を定めるようにしてもよいし、そうしなくてもよい。

限定ではなく例として、ユーザＡ．Ａの設定として、ユーザＢ．Ｂが「３回」、「ユーザＣ．Ｃ」が「５回」、支払いを実行することができるように連続決済回数をそれぞれ定める。すると、端末２０Ｂを用いて支払いを実行する際には３回まで、端末２０Ｃを用いて支払いを実行する際には５回まで、ユーザＡ．Ａのアカウントでの支払いの負担が行われる。

合計制限金額においても同様に、ユーザごとにそれぞれ合計制限金額を定めるようにしてもよいし、そのようにしなくてもよい。

＜第１５変形例（３）＞
上記の実施例では、連携メンバーの連続決済回数あるいは合計制限金額が「０」以下になる場合、そのメンバーのアカウントからの支払いが実行されなくなる例を示したが、これに限定されない。
限定ではなく例として、制限が発動し支払いの負担が行われないユーザについても、限定ではなく例として、支払い実行時に承諾を得ることで、支払いの負担が可能であるようにしてもよいし、そのようにしなくてもよい。

この場合、限定ではなく例として、制限が発動したメンバーの許諾に従い、連続決済回数あるいは合計制限金額を引き上げることで、再度支払いの負担が行われるようにすることができる。

＜第１５変形例（４）＞
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。
限定ではなく例として、第１４変形例で述べたように他の連携メンバーに支払い余力の立て替えを依頼するようにしてもよいし、そのようにしなくてもよい。

図１５−７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。
限定ではなく例として、図１５−４〜図１５−５の各ステップの実行後、図１５−７の処理が実行される。

通信Ｉ／Ｆ１４によって端末２０Ａから連携決済要求情報を受信すると、サーバ１０の制御部１１は、Ｓ６４５のステップを実行する。連携支払い可能額が決済予定金額を下回る場合には（Ｓ６４５：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ２２０〜Ｓ２３５のステップを実行する。

サーバ１０の制御部１１は、Ｓ２３５のステップを実行すると、Ｓ６９５のステップを実行する。その後、Ｓ２４０のステップを実行し、Ｓ６９９のステップを実行する。

図１５−７の処理に引き続き、限定ではなく例として、図７−４の処理を実行することで、連携残高補充処理で発生した立て替えを精算する処理を実行するようにしてもよいし、そのようにしなくてもよい。

なお、Ａ２００のステップにおいて、支払い余力の不足分を負担してもらう連携メンバーを選択するとき、複数の連携メンバーが立て替え可能な場合には、端末２０Ａの制御部２１は、立て替えてもらうメンバー候補として連続決済回数の多い順に並べて表示させるようにしてもよいし、そのようにしなくてもよい。また、最も連続決済回数の多い連携メンバーを立て替え者として提案させるようにしてもよいし、そのようにしなくてもよい。

＜第１６実施例＞
第１２実施例〜第１５実施例では、アプリケーションとして支払いアプリケーションを適用する実施例について説明したが、これに限定されない。
第１６実施例は、チャットアプリケーション（限定ではなく例として、メッセージングアプリケーション）において形成されるグループにおいて連携ウォレットを用いて支払いを行い、チャットルーム（限定ではなく例として、トークルーム）にその表示を行う実施例である。

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

図１６−１は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１６−１左側は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザＡ．Ａが、ユーザＢ．Ｂ、ユーザＣ．Ｃとグループトークを行っている状態が示されている。具体的には、ユーザＡ．Ａから商品を購入しておく旨のメッセージが発信され、ユーザＢ．Ｂからそれに同意するメッセージが発信され、ユーザＣ．Ｃから代金をグループのメンバーみんなで支払うことを提案するメッセージが発信されている。
この状態で、画面下部の連携ウォレットアイコンＩＣ１がタップされると、図１６−１中央の画面が表示される。

この画面では、図１６−１左側のグループトークルームの画面下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がって表示されている。連携ウォレット情報表示領域ＷＩＲ１には、「ウォレット連携を依頼しますか？」の文字とともに、連携メンバーの候補のユーザ（この例では、ユーザＡ．Ａ、ユーザＢ．Ｂ、ユーザＣ．Ｃ）が一覧表示されている。画面下部のウォレット連携依頼ボタンＢＴ３５がタップされると、図１６−１右側の画面が表示される。

この画面では、連携ウォレット情報表示領域ＷＩＲ１において、コードリーダアイコンＩＣ２と、コード支払いアイコンＩＣ３とが、それぞれアクティブ状態で表示されている。
また、その下の連携メンバー情報表示領域ＭＩＲ４には、ユーザＡ．Ａのユーザアカウントに関する情報と、ユーザＢ．Ｂのユーザアカウントに関する情報と、ユーザＣ．Ｃのユーザアカウントに関する情報とが表示されている。

この例では、自身であるユーザＡ．Ａについては、表示残高および電子マネー口座残高の他、設定された表示上限金額、設定された連続決済回数、設定された合計制限金額がそれぞれ表示されている。
また、この例では、他の連携メンバーであるユーザＢ．Ｂ、ユーザＣ．Ｃについては、表示残高が表示されている。

＜処理＞
本実施例における処理については、限定ではなく例として、支払いアプリケーションを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバとでの処理をサーバ１０における処理として、図１５−４〜図１５−６に従って同様に実行することが可能であるため、再度の説明は省略する。

＜第１７実施例＞
第１実施例〜第１６実施例では、連携承認後に行われた支払いを対象として、連携アカウント間で精算（立替精算）を行う実施例について説明した。
第１７実施例は、連携承認前に行われた支払いを対象とする場合の処理に関する実施例である。
上記の実施例では、未連携承認のアカウントが存在する場合、支払いを行うことができなかった。限定ではなく例として、アカウント連携の承認を得るまでに時間がかかることも想定され、この場合、連携承認されるまで支払いを行うことができなくなってしまう。

以下説明する実施例では、連携アカウントが連携承認する前に行われた支払いを対象として精算することを、言うなれば遡及して精算するという意味で「遡及精算」と称し、先の実施例で説明した「立替精算」と区別する。
なお、遡及精算も精算の一種である。つまり、精算には「立替精算」と「遡及精算」とが含まれる。

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

第１に、本実施例では、第１ユーザアカウントと第２ユーザアカウントとの連携（限定ではなく、第１アカウントと第２アカウントとの関連付けの一例）に基づき、少なくとも第２アカウントによって行われた決済に関する情報を、第１ユーザアカウントの第１ユーザの端末２０の表示部２４に表示する。
本実施例では、この場合における第１ユーザアカウントと第２ユーザアカウントとの連携（第１アカウントと第２アカウントとの関連付け）を、連携ウォレットが生成された後、第１ユーザアカウントが連携承認したこと（連携承認済みとなったこと）として説明する。
また、本実施例では、第１ユーザアカウントが連携承認したことに基づいて、連携ウォレットが生成される前（連携ウォレット生成要求情報がサーバに送信される前）に少なくとも第２ユーザアカウントによって行われた決済に関する情報を、第１ユーザアカウントの第１ユーザの端末２０の表示部２４に表示することとして説明する。

第２に、本実施例では、第１ユーザアカウントの第１ユーザの端末２０で上記の決済に関する情報が表示された後、その決済での支払いについて、第１ユーザアカウントが第２ユーザアカウントに遡及精算することを可能とする。

先の実施例と同様に、１つのパターンとして、同じユーザの複数のユーザアカウント（限定ではなく例として、ユーザＡ．ＡのメインアカウントとユーザＡ．Ａのサブアカウント）とを連携させるようにすることも可能である。つまり、第１ユーザの第１ユーザアカウントと、第１ユーザの第２ユーザアカウントとを連携させることも可能である。

限定ではなく例として、第１ユーザが第２ユーザアカウントを用いて支払いを行い、その後に、第１ユーザの第１ユーザアカウントと連携させることが考えられる。
この場合、アカウントが連携されると、第１ユーザは、第２ユーザアカウントによる支払い履歴を確認する。
その後、第１ユーザは、限定ではなく例として、第２ユーザアカウントの電子マネー口座残高が少なくなっていることを確認した上で、第１ユーザアカウントから第２ユーザアカウントに対して送金するようにすることができる。
これは、限定ではなく例として、一のユーザが、自分の複数のユーザアカウントの電子マネー口座間で資金の移動を行う手法の１つと捉えることもできる。

以下では、上記とは異なるパターンとして、異なるユーザのユーザアカウント同士を連携させる場合について説明する。

本実施例では、サーバ１０の記憶部１５には、限定ではなく例として、図１−３で示した情報が記憶される。

図１７−１は、本実施例において用いられるアカウント管理データベース１５５の一例である第２のアカウント管理データベース１５５Ｂのデータ構成例を示す図である。
第２のアカウント管理データベース１５５Ｂには、アカウント登録データ１５３に記憶されたアプリケーションＩＤごとの管理データとして、アカウント管理データが記憶される。

各々のアカウント管理データには、限定ではなく例として、アプリケーションＩＤと、電子マネー口座残高と、決済履歴データとが記憶される。アプリケーションＩＤと、電子マネー口座残高とは、限定ではなく例として、第１のアカウント管理データベース１５５Ａと同様である。

決済履歴データには、このユーザアカウントによる決済（支払い）の履歴のデータであり、限定ではなく例として、取引ＩＤと、店舗ＩＤと、店舗名と、支払い日時と、支払い金額とが関連付けて、時系列に記憶される。
個々の要素については、限定ではなく例として、第１の連携ウォレット管理データベース１５７Ａの連携ウォレット管理データにおける決済履歴データと同様に構成することが可能である。

図１７−２は、本実施例において用いられる連携ウォレットを管理するためのデータベースの一例である第１０の連携ウォレット管理データベース１５７Ｊのデータ構成例を示す図である。
第１０の連携ウォレット管理データベース１５７Ｊには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

連携アカウントデータには、アプリケーションＩＤと、ユーザ名とに加えて、連携承認が関連付けて記憶される。連携承認は、限定ではなく例として、第５の連携ウォレット管理データベース１５７Ｅの連携状況管理データにおける連携承認と同様である。

＜表示画面＞
以下、ユーザＢ．Ｂが、連携ウォレットを生成する前にユーザＢ．Ｂのユーザアカウントを用いてＰＰスーパーで「２，０００円」の支払いを行った場合の表示画面例について説明する。

図１７−３は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１７−３左側の画面は、支払いアプリケーションのおしらせ画面であり、この例では、ユーザＢ．Ｂからのウォレット連携の依頼に関する情報が表示されている。この情報には、限定ではなく例として、ユーザＢ．Ｂからウォレット連携の依頼があったことを示す文字と、ユーザＢ．Ｂによって生成されたユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットであることを示すアイコンおよび文字とが含まれる。

また、その下には、連携承認するための「連携する」の文字を含む連携承認ボタンと、連携を拒否するための「断る」の文字を含む連携拒否ボタンとが表示されている。連携承認ボタンがタップされると、図１７−３中央の画面が表示される。

この画面は、連携ウォレットのメイン画面であり、連携メンバー情報表示領域ＭＩＲ１のユーザＢ．Ｂの欄には、ユーザＢ．Ｂのユーザアカウントの電子マネー口座残高の情報の他、連携ウォレットが生成される前におけるユーザＢ．Ｂのユーザアカウント単独による支払い履歴（以下、「単独支払い履歴」と称する。）を表示するための単独支払い履歴ボタンＢＴ５０が表示されている。
なお、支払い履歴は決済履歴と表現してもよいし、しなくてもよい。

この単独支払い履歴ボタンＢＴ５０がタップされると、図１７−３右側の画面が表示される。
この画面には、現在位置表示領域ＣＬＲ１の下に、ユーザＢ．Ｂのユーザアカウントによる単独支払い履歴（画面上は「購入履歴」）であることを示すアイコンおよび文字が表示され、その下には、その単独支払い履歴が表示されている。この例では、ユーザＢ．Ｂのユーザアカウントによって「ＰＰスーパー」で「２０２０年８月２日１９時１０分３３秒」に行われた、「２，０００円」分の商品の購入に関する単独支払い履歴が表示されている。

つまり、この例では、ユーザＢ．Ｂが支払いを行った時点では、まだユーザＢ．Ｂによって連携ウォレットは生成されておらず、当然ユーザＢ．ＢからユーザＡ．Ａに対してウォレット連携も依頼されていなかったが、ユーザＡ．ＡがユーザＢ．Ｂからのウォレット連携の依頼に応じて連携承認を行ったことで、ユーザＢ．Ｂのユーザアカウントによる単独支払い履歴を、ユーザＡ．Ａが自己の端末２０Ａで閲覧して確認できるように構成されている。

次に、このようにして表示された単独支払い履歴に基づいて遡及精算を行う例について説明する。
図１７−３右側の画面において、単独支払い履歴の表示欄には、ユーザＢ．Ｂのユーザアカウントが行った支払いを対象として、連携承認を行ったユーザＡ．ＡからユーザＢ．Ｂに対して遡及精算として送金を行うための送金ボタンＢＴ５２が表示されている。この例では、「２，０００円」をユーザＡ．ＡとユーザＢ．Ｂとの２名で割り勘した金額として「１，０００円」を送金するための送金ボタンＢＴ５２が表示されている。

このように、本実施例では、ユーザＡ．Ａが、ユーザＢ．Ｂの単独支払い履歴を確認した上で、支払い金額の一部または全部の金額を負担することとして、ユーザＢ．Ｂに対して送金を行うことができるように構成されている。

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

まず、サーバ１０の制御部１１は、ユーザＢ．Ｂのアカウントの支払いトークンを生成し、支払いトークンを含むコード読み取り用情報であるコードリーダ情報を生成する。そして、サーバ１０の制御部１１は、生成したコードリーダ情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ７１０）。

通信Ｉ／Ｆ２２によってサーバ１０からコードリーダ情報を受信すると、端末２０Ｂの制御部２１は、受信したコードリーダ情報に基づいて、限定ではなく例として、コードを読み取るために撮像部２７を起動させる。そして、端末２０Ｂの制御部２１は、起動させた撮像部２７等を用いて支払い店舗コードを読み取るコード読み取りる。すると、端末２０Ｂの制御部２１は、支払い店舗コードから店舗ＩＤを取得し、限定ではなく例として、支払いトークンと、店舗ＩＤと、決済予定金額とを含むユーザアカウント決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ７１０）。

通信Ｉ／Ｆ１４によって端末２０Ｂからユーザアカウント決済要求情報を受信すると、サーバ１０の制御部１１は、受信した支払いトークンに基づいて、ユーザＢ．Ｂのアカウントに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行うユーザアカウント決済処理を実行する（Ｓ７２０）。決済処理が成功すると、サーバ１０の制御部１１は、第２のアカウント管理データベース１５５Ｂに、決済履歴を記憶させる。

限定ではなく例として、端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、ユーザＢ．ＢのアカウントとユーザＡ．Ａのアカウントとの連携ウォレットを生成することが選択されると、端末２０Ｂの制御部２１は、限定ではなく例として、連携ウォレットに連携させるアカウントのアプリケーションＩＤを含む連携ウォレット生成要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ７２０）。

通信Ｉ／Ｆ１４によって端末２０Ｂから連携ウォレット生成要求情報を受信すると、サーバ１０の制御部１１は、連携ウォレット生成要求情報のアプリケーションＩＤを連携アカウントデータとする連携ウォレット管理データのレコードを生成し、連携承認を「未」とする。そして、端末２０ＢのユーザのアプリケーションＩＤについて、連携承認を「済」にする（Ｓ７３０）。
そして、サーバ１０の制御部１１は、ウォレット連携承認確認情報を端末２０Ａに送信する（Ｓ５１０）。

通信Ｉ／Ｆ２２によってサーバ１０からウォレット連携承認確認情報を受信すると、端末２０Ａの制御部２１は、連携承認するかを判定し（Ａ７１０）、連携承認する場合（Ａ７１０：ＹＥＳ）、ウォレット連携承認情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ７２０）。Ａ７１０〜Ａ７２０のステップの詳細については、限定ではなく例として、図１０−４のＢ５００〜Ｂ５１０のステップと同様に実行することができる。連携承認しない場合には（Ａ７１０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ１４によって端末２０Ａからウォレット連携承認情報を受信すると（Ｓ５２０：ＹＥＳ）、サーバ１０の制御部１１は、端末２０ＡのユーザのアプリケーションＩＤについて、連携承認を「済」とする。
一方、ウォレット連携承認情報を受信しない場合には（Ｓ５２０：ＮＯ）、サーバ１０の制御部１１は、処理を終了させる。

なお、サーバ１０の制御部１１は、限定ではなく例として、端末２０Ａからウォレット連携承認情報を受信した場合に、そのウォレット連携承認情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信するなどして、連携承認されたことを端末２０Ｂ（ユーザＢ．Ｂ）に通知するようにすることもできる。

次いで、サーバ１０の制御部１１は、ユーザＢ．Ｂのユーザアカウントで実行された支払いの履歴であるユーザアカウント決済履歴情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ７４０）。

なお、送信する決済履歴について、限定ではなく例として、連携ウォレット生成処理が行われる以前における所定の期間の履歴に限定して送信するようにしてもよいし、そのようにしなくてもよい。
また、連携ウォレット生成要求情報に、Ｓ７４０のステップで送信する決済履歴を選択する情報を含むようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０からユーザアカウント決済履歴情報を受信すると、端末２０Ａの制御部２１は、ユーザアカウント決済履歴情報を表示部２４に表示させる（Ａ７３０）。

そして、端末２０Ａの制御部２１は、限定ではなく例として、決済履歴の総支払い額を割り勘した金額を送金推奨額として、図２−２のＡ１４０〜Ａ１６０のステップを実行する。なお、端末２０Ａの入出力部２３に対するユーザ操作に基づいて、端末２０Ａの制御部２１は、送金推奨額を取得するようにしてもよいし、そのようにしなくてもよい。

サーバ１０の制御部１１は、図２−２のＳ１４０〜Ｓ１６０のステップを実行する。

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

なお、上記の処理では、異なるユーザのアカウントを連携させる例について説明したが、前述したように、同じユーザの複数のアカウントを連携させるようにしてもよいし、そのようにしなくてもよい。

＜第１７実施例の効果＞
本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）の第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、第２ユーザアカウントとに基づくアカウント連携決済を行うためのウォレット連携承認確認情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によって受信し、受信したウォレット連携承認確認情報の表示（限定ではなく、第１表示の一例）を表示部２４に表示する。
また、端末２０は、自己の端末２０のユーザによるウォレット連携承認確認情報の表示に対する入力に基づいて、アカウント連携・連携承認に関する処理（限定ではなく、第１アカウントと第２アカウントとの関連付けに関する処理の一例）を制御部２１によって行う。
そして、端末２０は、アカウント連携・連携承認（限定ではなく、第１アカウントと第２アカウントとの関連付けの一例）に基づき、少なくとも第２ユーザアカウントによって行われた支払い履歴の情報（限定ではなく、少なくとも第２アカウントによって行われた第１決済に関する情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けに基づき、少なくとも第２アカウントによって行われた第１決済に関する情報が端末の表示部に表示されるため、第１ユーザは、限定ではなく例として、第１アカウントと第２アカウントとが関連付けられる以前に少なくとも第２アカウントによって行われた第１決済の内容を確認して把握することができる。

また、この場合、端末２０は、自己の端末２０のユーザによる、表示された支払い履歴の情報に対する入力に基づいて、決済金額の一部または全部の金額（限定ではなく、第１決済のうちの少なくとも一部である第１金額の一例）を、第１ユーザの第１ユーザアカウントから第２アカウントへ送金させるための処理（限定ではなく、第１アカウントから第２アカウントへ送金することに関する処理の一例）を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザによる第１決済に関する情報に対する入力という簡単な方法によって、第１決済のうちの少なくとも一部である第１金額を、第１アカウントから第２アカウントへ送金させることができる。

また、本実施例は、サーバ１０が、端末２０のユーザ（限定ではなく、第１ユーザの一例）の第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、第２ユーザアカウントとに基づくアカウント連携決済を行うためのウォレット連携承認確認情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する。
また、サーバ１０は、端末２０に表示されたウォレット連携承認確認情報の表示（限定ではなく、第１表示の一例）に対する端末２０のユーザによる入力に基づいて、アカウント連携・連携承認に関する処理（限定ではなく、第１アカウントと第２アカウントとの関連付けに関する処理の一例）を制御部１１によって行う。
そして、サーバ１０は、アカウント連携・連携承認（限定ではなく、第１アカウントと第２アカウントとの関連付けの一例）に基づき、少なくとも第２ユーザアカウントによって行われた支払い履歴の情報（限定ではなく、少なくとも第２アカウントによって行われた第１決済に関する情報の一例）を通信Ｉ／Ｆ１４によって端末２０に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けに基づき、少なくとも第２アカウントによって行われた第１決済に関する情報を第１ユーザの端末に送信することで、限定ではなく例として、第１アカウントと第２アカウントとが関連付けられる以前に少なくとも第２アカウントによって行われた第１決済の内容を第１ユーザに確認させることができる。

ここで、アカウント連携に関する処理（限定ではなく、第１アカウントと第２アカウントとの関連付けに関する処理の一例）は、限定ではなく例として、端末２０がサーバ１０に対してアカウント連携を依頼する処理や、端末２０側でアカウント連携を行う処理等を含む概念である。

また、この場合、サーバ１０は、端末２０のユーザによる、端末２０に表示された支払い履歴の情報に対する入力に基づいて、決済金額の一部または全部の金額（限定ではなく、第１決済のうちの少なくとも一部である第１金額の一例）を、第１ユーザの第１ユーザアカウントから、第２アカウントへ送金する処理（限定ではなく、第１アカウントから第２アカウントへ送金することに関する処理の一例）を制御部１１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザによる、端末に表示された第１決済に関する情報に対する入力がなされたことに基づいて、第１決済のうちの少なくとも一部である第１金額を、第１アカウントから第２アカウントへ送金することができる。

また、本実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく、第１ユーザの一例）の第１ユーザアカウント（限定ではなく、第１アカウントの一例）と、第２ユーザアカウントとに基づくアカウント連携決済を行うための、ウォレット連携承認確認情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によって第２ユーザアカウントに対して送信する。
また、端末２０は、ウォレット連携承認確認情報を第２ユーザアカウントに対して送信してから、ウォレット連携承認確認情報に基づく、ウォレット連携承認情報（限定ではなく、第１アカウントと第２アカウントとの関連付けの承認に関する情報の一例）を第２アカウントから通信Ｉ／Ｆ２２によって受信するまでの間に、少なくとも第１ユーザアカウントに基づくアカウント連携決済を行わせるための処理（限定ではなく、第１決済に関する処理の一例）を制御部２１によって行う。
そして、端末２０は、アカウント連携・連携承認（限定ではなく、第１アカウントと第２アカウントとの関連付けの一例）に基づき、第２ユーザアカウントから送金された第１金額（限定ではなく、第１決済に基づく金額の一例）を受け取る処理を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けに関する第１情報を第２アカウントに対して送信してから、第１情報に基づく第１アカウントと第２アカウントとの関連付けの承認に関する情報を第２アカウントから受信するまでの間に、少なくとも第１アカウントに基づく第１決済を行った上で、第１アカウントと第２アカウントとの関連付けに基づき、第２アカウントから送金された第１決済に基づく金額を受け取ることができる。

＜第１７変形例（１）＞
上記の実施例では、連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信される前に行われた支払いについて、連携アカウント間で遡及精算を行うこととしたが、これに限定されない。
限定ではなく例として、連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信されてから、ウォレット連携承認を依頼された第１ユーザアカウントが連携承認するまでの間に行われた支払いについて、遡及精算を行うようにしてもよいし、そのようにしなくてもよい。

なお、連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信されてから、ウォレット連携承認を依頼された端末２０Ａの第１ユーザアカウントが連携承認するまでの期間には、端末２０Ａがサーバ１０からウォレット連携承認確認情報を受信してから、第１ユーザアカウントが連携承認するまでの期間が含まれる。
このため、端末２０Ａがウォレット連携承認確認情報（限定ではなく、第１情報の一例）を受信してから、第１ユーザアカウントが連携承認するまでの間に行われた支払いについて遡及精算を行うこともこれに含まれる。

また、連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信されてから、ウォレット連携承認を依頼された端末２０Ａの第１ユーザアカウントが連携承認するまでの期間には、サーバ１０が端末２０Ａにウォレット連携承認確認情報を送信してから、第１ユーザアカウントが連携承認するまでの期間が含まれる。
このため、サーバ１０によってウォレット連携承認確認情報（限定ではなく、第１情報の一例）が送信されてから、第１ユーザアカウントが連携承認するまでの間に行われた支払いについて遡及精算を行うこともこれに含まれる。

図１７−６は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

端末２０Ｂの制御部２１は、Ｂ７２０のステップを実行後、Ｂ７１０のステップを実行する。そして、サーバ１０の制御部１１は、Ｓ７３０のステップを実行後、Ｓ５１０のステップを実行し、Ｓ７１０〜７２０のステップを実行後、Ｓ５２０のステップを実行する。

これにより、Ｓ７４０のステップにおいて送信されるユーザアカウント決済履歴情報には、連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信されてから、ユーザＡ．Ａが連携承認するまでの間に行われた決済の履歴の情報が含まれる。

本変形例は、アカウント連携決済（限定ではなく、第１決済の一例）は、端末２０がウォレット連携承認確認情報（限定ではなく、第１情報の一例）を受信してから、連携承認されるまでの間に行われたアカウント連携決済である構成を示している。
このような構成により得られる変形例の効果の一例として、端末が第１情報を受信してから第１アカウントと第２アカウントとの関連付けが行われるまでの間に行われた第１決済を対象として、その第１決済に関する情報を端末の表示部に表示して、第１ユーザがその内容を確認して把握できるようにすることができる。
また、端末が第１情報を受信してから第１アカウントと第２アカウントとの関連付けが行われるまでの間に行われた第１決済を対象として、その第１決済のうちの少なくとも一部である第１金額を第１アカウントから第２アカウントへ送金することができる。

＜第１７変形例（２）＞
上記の変形例では、図１７−６のＳ７４０のステップにおいて送信される決済履歴情報を、ユーザアカウントでの決済の履歴の情報であることとしたが、これに限定されない。
限定ではなく例として、上記の決済履歴情報を、連携ウォレット生成後、連携アカウントが連携承認するまでの間に行われた連携ウォレットでの決済の履歴の情報とすることもできる。つまり、連携ウォレット生成後、連携アカウントが連携承認するまでの間に行われた連携ウォレットでの決済を対象として、決済履歴の表示や遡及精算を行うようにすることもできる。

図１７−７は、本変形例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１７−７左側は、支払いアプリケーションのメイン画面であり、ユーザＡ．Ａが連携承認した状態が示されている。
この例では、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットであることを示す情報の表示欄に、連携ウォレット生成後、ユーザＡ．Ａが連携承認するまでの間に行われた連携ウォレットでの支払い履歴（以下、「連携ウォレット支払い履歴」と称する。）を表示するための連携ウォレット支払い履歴ボタンＢＴ５４が表示されている。この連携ウォレット支払い履歴ボタンＢＴ５４がタップされると、図１７−７右側の画面が表示される。

この画面には、現在位置表示領域ＣＬＲ１の下に、ユーザＡ．ＡとユーザＢ．Ｂの連携ウォレットによる連携ウォレット支払い履歴（画面上は「購入履歴」）であることを示すアイコンおよび文字が表示され、その下には、連携ウォレット支払い履歴が表示されている。この例では、連携ウォレットによって「ＰＰスーパー」で「２０２０年８月２日１９時１０分３３秒」に行われた、「２，０００円」分の商品の購入に関する連携ウォレット支払い履歴が表示されている。

また、この表示欄には、連携ウォレットによって行われた決済について、ユーザＡ．ＡがユーザＢ．Ｂに対して、立て替えてもらった金額を送金（返却）するための送金ボタンＢＴ５６が表示されている。この例では、「２，０００円」をユーザＡ．ＡとユーザＢ．Ｂとの２名で割り勘した金額として「１，０００円」を送金するための送金ボタンＢＴ５６が表示されている。

つまり、この例では、ユーザＡ．Ａが連携承認したことに基づいて、ユーザＢ．Ｂによる連携ウォレット生成後、ユーザＡ．Ａが連携承認するまでの間に行われた連携ウォレットによる支払い履歴を、ユーザＡ．Ａが自己の端末２０Ａで閲覧して確認できるように構成されている。
さらに、この連携ウォレットによる支払い履歴を確認した上で、ユーザＡ．Ａが、連携ウォレットによる支払い金額の一部または全部の金額を負担して、立替者であるユーザＢ．Ｂへの送金（立て替えてもらった金額の返却）を行うことができるように構成されている。

この場合には、限定ではなく例として、連携ウォレットにおいて未だ連携承認していないアカウントが存在する場合（連携承認が「未」のアカウントが存在する場合）でも連携ウォレットでの支払いを可能とする。そして、支払いの履歴を第１０の連携ウォレット管理データベース１５７Ｊに記憶させ、図１７−６のＳ７４０のステップにおいて、限定ではなく例として、連携ウォレットでの決済履歴を送信するようにすればよい。

なお、連携ウォレットの連携メンバーは２人（あるいは、連携アカウントが２）に限定されない。連携メンバーが３人以上（あるいは、連携アカウントが３以上）の場合も同様に適用可能である。

限定ではなく例として、ユーザＡ．Ａと、ユーザＢ．Ｂと、ユーザＣ．Ｃとの連携ウォレットが生成され、ユーザＡ．ＡとユーザＣ．Ｃとが連携承認している段階において、連携ウォレットにおいて「９００円」の支払いが実行され、ユーザＡ．ＡとユーザＣ．Ｃとが２人での等分支払い額「４５０円」を負担したとする。その後、ユーザＢ．Ｂが連携承認する場合、ユーザＢ．Ｂは、限定ではなく例として、２人での等分支払い額「４５０円」と、３人での等分支払い額「３００円」である「１５０円」を、ユーザＡ．ＡとユーザＣ．Ｃとにそれぞれ送金するようにすればよい。

なお、連携ウォレットにおける連携アカウントは、ユーザアカウントに限定されない。限定ではなく例として、第８実施例を参酌することで、共通ウォレットとユーザアカウントとの連携ウォレットや、複数の共通ウォレットでの連携ウォレットにおいて上記の手法を適用するようにしてもよいし、そのようにしなくてもよい。

本変形例は、アカウント連携決済は、第２ユーザアカウント（限定ではなく、第２アカウントの一例）と、第２ユーザアカウントと連携された第３ユーザアカウント（限定ではなく、第２アカウントと関連付けられた第３アカウントの一例）とによって行われたアカウント連携決済である構成を示している。
このような構成により得られる変形例の効果の一例として、第２アカウントと、第２アカウントと関連付けられた第３アカウントとに行われた第１決済を対象として、その第１決済に関する情報を端末の表示部に表示して、第１ユーザがその内容を確認して把握できるようにすることができる。
また、第２アカウントと、第２アカウントと関連付けられた第３アカウントとに行われた第１決済を対象として、その第１決済のうちの少なくとも一部である第１金額を第１アカウントから第２アカウントへ送金することができる。

また、本変形例は、連携される第２アカウントは、共通ウォレットのアカウント（限定ではなく、複数のユーザが決済可能な共通アカウントの一例）である構成を示している。
このような構成により得られる実施例の効果の一例として、複数のユーザが決済可能な共通アカウントを第２アカウントとして、第１アカウントと関連付けることができるため、ユーザの利便性を向上させることができる。

＜第１７変形例（３）＞
上記の実施例において、第１ユーザアカウントが未連携承認の状態であっても、第１ユーザアカウントが、少なくとも第２ユーザアカウントによる決済履歴（前述した単独支払い履歴や連携ウォレット履歴）を閲覧したり、第２ユーザアカウントに対する送金（遡及精算）を行うことができるようにしてもよい。

この場合、限定ではなく例として、端末２０は、ウォレット連携承認確認情報（限定ではなく、第１情報の一例）を通信Ｉ／Ｆ２２によって受信し、受信したウォレット連携承認確認情報の表示（限定ではなく、第１表示の一例）を表示部２４に表示する。
この場合、第１ユーザアカウントが未だ連携承認を行っていない状態であっても、自己の端末２０のユーザ（第１ユーザ）によって決済履歴（単独支払い履歴や連携ウォレット支払い履歴）を表示するための入力がなされると、端末２０は、その決済履歴をサーバ１０に要求し、サーバ１０から送信された決済履歴を受信したことに基づいて、決済履歴を表示部２４に表示するようにすることができる。

また、この場合、第１ユーザアカウントが未だ連携承認を行っていない状態であっても、端末２０は、表示された決済履歴に対する入力に基づいて、決済金額の一部または全部の金額を、自己の端末２０のユーザ（第１ユーザ）の第１ユーザアカウントから、第２アカウントへ送金するための処理を制御部２１によって行うようにすることもできる。

＜第１７変形例（４）＞
前述したように、遡及精算の対象とする期間として、限定ではなく例として、
（ａ）連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信される前の期間
（ｂ）連携ウォレット生成要求情報が端末２０Ｂからサーバ１０に送信されてから、ウォレット連携承認を依頼されたユーザアカウントが連携承認するまでの期間
のいずれかを適用することができる。

しかし、限定ではなく例として、（ａ）＋（ｂ）の期間を、遡及精算の対象とする期間としてもよいし、そのようにしなくてもよい。

また、支払い履歴（決済履歴）の表示の対象とする期間と、遡及精算の対象とする期間とを異ならせてもよいし、そのようにしなくてもよい。
限定ではなく例として、支払い履歴の表示対象とする期間は（ａ）＋（ｂ）の期間とするが、遡及精算の対象とする期間は（ａ）の期間とする。または、限定ではなく例として、支払い履歴の表示対象とする期間は（ａ）＋（ｂ）の期間とするが、遡及精算の対象とする期間は（ｂ）の期間とするなどしてもよい。

＜第１８実施例＞
第１７実施例では、連携ウォレットの連携メンバー全員が連携承認していない場合でも、連携ウォレットに関する支払いが可能であることについて説明した。
これに関連して、第１８実施例は、メッセージングアプリケーション（メッセージングサービス）のグループを単位として連携ウォレットを生成し、グループメンバー全員が連携承認していない場合でも、このグループの連携ウォレットを用いて支払いを実行可能とする実施例である。

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

本実施例では、サーバ１０の記憶部１５には、限定ではなく例として、図４−１で示した情報が記憶される。
図１８−１は、本実施例において用いられる連携ウォレットを管理するためのデータベースの一例である第１１の連携ウォレット管理データベース１５７Ｋのデータ構成例を示す図である。
第１１の連携ウォレット管理データベース１５７Ｋには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。

各々の連携ウォレット管理データには、限定ではなく例として、グループＩＤと、グループ名と、連携状況管理データと、決済履歴データと、立替履歴データと、決済参加アカウントデータとが記憶される。グループＩＤと、グループ名と、連携状況管理データと、決済履歴データと、立替履歴データとは、限定ではなく例として、第５の連携ウォレット管理データベース１５７Ｅと同様である。

決済参加アカウントデータは、決済履歴データに記憶される各々の決済（支払い）について、決済時に連携していたアカウントを記憶するためのデータであり、限定ではなく例として、取引ＩＤと、決済参加アカウントＩＤとが関連付けて記憶される。

取引ＩＤは、決済履歴データの決済（支払い）を識別するための識別情報である。また、決済参加アカウントＩＤは、取引ＩＤで識別される決済が実行されたときに、この連携ウォレットにおいて、連携承認が「済」となっていた連携アカウントのアプリケーションＩＤである。

図１８−１では、限定ではなく例として、「ＸＸ楽器」での支払い時には、ユーザＡ．ＡとユーザＢ．Ｂとが連携ウォレットでの支払いに同意していたことが示されている。すなわち、グループ「バンド仲間」の連携ウォレットにおける「ＸＸ楽器」での支払いは、ユーザＡ．ＡとユーザＢ．Ｂとが関与し（負担し）、ユーザＣ．Ｃは支払いに関与していない（負担していない）ことが示されている。

また、ユーザＡ．Ａが「バンド仲間」の連携ウォレットを生成し、ユーザＢ．ＢとユーザＣ．Ｃとが連携承認する前に、「バンド仲間」の連携ウォレットを用いて「ＸＸ楽器」で「４，５００円」を支払うこととする。

図１８−２は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図１８−２左側は、端末２０Ａの表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザＡ．Ａが、ユーザＢ．ＢおよびユーザＣ．Ｃとトーク（チャット）を行っている状態が示されている。

この例では、商品（この例では、ライブ用のスコア）を購入しておく旨のメッセージがユーザＡ．Ａから発信され、その支払いをグループのメンバー全員で行うことがユーザＢ．Ｂによって提案されている。しかし、ユーザＣ．Ｃが金欠であるため、後から支払いを行う旨のメッセージがユーザＣ．Ｃから発信され、これをユーザＡ．Ａが了承した状態が示されている。この状態で、画面下部の連携ウォレットアイコンＩＣ１がタップされると、図１８−２中央の画面が表示される。

この画面では、図１８−２左側のグループトークルームの画面下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がって表示されている。この連携ウォレット情報表示領域ＷＩＲ１には、「ウォレット連携を依頼しますか？」のメッセージとともに、グループ「バンド仲間」のグループメンバー（ユーザＡ．Ａ、ユーザＢ．Ｂ．ユーザＣ．Ｃ）が連携メンバーとなることが示されている。この状態で、ウォレット連携依頼ボタンＢＴ３５がタップされると、サーバ１０を介して、端末２０Ａから端末２０Ｂおよび端末２０Ｃに対して、ウォレット連携依頼情報が送信される。

図１８−２右側は、この場合に端末２０Ｂの表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザＡ．ＡがユーザＣ．Ｃの後払いを了承したメッセージの下に、ユーザＡ．Ａからのウォレット連携依頼メッセージが表示されている。また、その下には、ユーザＡ．Ａが商品を購入したことを報告するメッセージが表示されている。

ウォレット連携依頼メッセージには、ユーザＡ．Ａからウォレット連携の依頼があったことを示す文字や画像の他、限定ではなく例として、連携承認ボタンと、連携拒否ボタンとが含まれる。
連携承認ボタンがタップされると、端末２０Ｂの表示部２４には、図１８−３左側の画面が表示される。

この画面では、グループ「バンド仲間」のトークルーム画面の下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がって表示されている。
連携ウォレット情報表示領域ＷＩＲ１には、グループ「バンド仲間」の連携ウォレットであることを示す情報の表示欄に、連携ウォレット支払い履歴ボタンＢＴ５４が表示されている。

また、連携メンバー情報表示領域ＭＩＲ１には、ユーザＡ．ＡとユーザＢ．Ｂとについては電子マネー口座残高が表示されているが、ユーザＣ．Ｃは未連携承認の状態であるため「依頼中」のマークが表示されている。

連携ウォレット支払い履歴ボタンＢＴ５４がタップされると、図１８−３中央の画面が表示される。
この画面では、連携ウォレット情報表示領域ＷＩＲ１に、グループ「バンド仲間」の連携ウォレットの支払い履歴として、「ＸＸ楽器」での「４，５００円」の支払いに関する情報が表示されている。また、この表示欄には、この支払いに対する遡及精算を行うための精算ボタンＢＴ５８が表示されている。精算ボタンＢＴ５８がタップされると、図１８−３右側の画面が表示される。

この画面では、連携ウォレット情報表示領域ＷＩＲ１の中央部に、精算内容に関する情報がポップアップ形式で表示されている。この例では、ユーザＣ．Ｃは未連携承認の状態であるため、ユーザＡ．ＡとユーザＢ．Ｂとの２名で支払いを負担することになる。

上記の支払いは、ユーザＡ．Ａによる連携ウォレットの生成後、ユーザＢ．Ｂが連携承認するまでの間に行われた連携ウォレットの支払いである。このため、ユーザＢ．Ｂは、自己の負担分の金額を遡及精算する必要がある。この例では、「過去の支払いを精算しますか？」の文字とともに、ユーザＢ．ＢからユーザＡ．Ａに対して「２，２５０円」を送金する内容が表示されている。その下に設けられた「はい」のボタンがタップされると、ユーザＢ．ＢからユーザＡ．Ａに対する送金が行われる。

図１８−４は、上記の例において、グループ「バンド仲間」の各々のメンバーの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図である。
左から順に、端末２０Ａ、端末２０Ｂ、端末２０Ｃで表示されるグループトークルーム画面の一例を示している。

端末２０Ａに表示されるグループトークルーム画面では、時系列で古い順に、連携ウォレットによる決済完了通知メッセージ→ユーザＡ．Ａからの連携ウォレットによる商品購入報告メッセージ→ユーザＢ．Ｂによるウォレット連携メッセージ→精算完了通知メッセージ、の順でメッセージが表示されている。

端末２０Ｂに表示されるグループトークルーム画面では、時系列で古い順に、ユーザＡ．Ａからの連携ウォレットによる商品購入報告メッセージ→ユーザＢ．Ｂによるウォレット連携メッセージ→連携ウォレットによる決済完了通知メッセージ→精算完了通知メッセージ、の順でメッセージが表示されている。

端末２０Ｃに表示されるグループトークルーム画面では、時系列で古い順に、ユーザＡ．Ａからのウォレット連携依頼メッセージ→ユーザＡ．Ａからの連携ウォレットによる商品購入報告メッセージ→ユーザＢ．Ｂによるウォレット連携メッセージ、の順でメッセージが表示されている。

この例では、決済完了通知メッセージと、精算完了通知メッセージとは、端末２０Ｃに表示されるグループトークルーム画面には表示されていない。これは、ユーザＣ．Ｃは、未連携承認の状態であり、現時点では支払いに関与しないためである。

図１８−５は、端末２０Ｃの表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、図１８−５左側の画面では、グループ「バンド仲間」のトークルーム画面の下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がって表示されている。

連携ウォレット情報表示領域ＷＩＲ１では、ユーザＣ．Ｃは未連携承認の状態であるため、連携ウォレットの使用が制限されている。
具体的には、コードリーダアイコンＩＣ２とコード支払いアイコンＩＣ３とはグレーアウトしており、タップしても、その操作を受け付けないように構成されている。
また、連携ウォレット支払い履歴ボタンＢＴ５４もグレーアウトしており、タップしても、その操作を受け付けないように構成されている。
また、連携ウォレット破棄ボタンＢＴ３０もグレーアウトしており、タップしても、その操作を受け付けないように構成されている。

限定ではなく例として、グレーアウトしているコード支払いアイコンＩＣ３がタップされると、図１８−５右側の画面が表示される。
この画面では、連携ウォレット情報表示領域ＷＩＲ１の中央部に、ウォレット連携を行わないと支払いを行うことができないことを示す情報が、ポップアップ形式で表示されている。具体的には、「連携しないと支払いできません」の文字が表示されている。「
その下には、「ウォレット連携する」と示された連携承認ボタンが表示されており、連携承認ボタンがタップされると、連携ウォレットの使用の制限も解除される。

＜処理＞
図１８−６は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、端末２０およびサーバ１０で構成されるシステムが実行する処理の一例を示している。なお、サーバ１０を、支払いサービスを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバに分けて構成するようにしてもよいし、そのようにしなくてもよい。

まず、限定ではなく例として、端末２０に対するユーザ操作に基づいて、新たな連携ウォレットを生成するための連携ウォレット生成処理が実行される（Ｌ１００）。

なお、連携ウォレット生成処理が実行される契機・条件は、表示画面例で述べたグループトークルームにおける操作に限定されない。限定ではなく例として、新たなグループが作成されると、自動的にそのグループに対する連携ウォレット生成処理が実行されるようにしてもよいし、そのようにしなくてもよい。
また、２人のユーザ間のトークルームにおいて、そのトークルームが生成されると、自動的にそのトークルームにおける連携ウォレットが生成されるようにしてもよいし、そのようにしなくてもよい。この場合には、トークルームを２人のメンバーのグループとして取り扱えばよい。

図１８−７は、連携ウォレット生成処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、あるグループにおいて連携ウォレットの生成を指示するユーザの端末である端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、このグループメンバーの端末である端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

端末２０Ａの制御部２１は、Ａ５００〜Ａ５１０のステップを実行する。サーバ１０の制御部１１は、Ｓ５００〜Ｓ５０５のステップを実行すると、このグループにおける連携ウォレットの連携ウォレット支払いトークンが生成可能になり、連携ウォレットが使用可能になったことを示す連携ウォレット情報を、通信Ｉ／Ｆ１４によって、第５の連携ウォレット管理データベース１５７Ｅにおいて連携承認が「済」である端末２０（この場合には、端末２０Ａ）に送信する（Ｓ７５０）。そして、サーバ１０の制御部１１は、ウォレット連携承認確認情報を、通信Ｉ／Ｆ１４によって、第５の連携ウォレット管理データベース１５７Ｅにおいて連携承認が「未」である端末２０（この場合には、限定ではなく例として、端末２０Ｂ）に送信する（Ｓ７６０）。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット情報を受信すると、端末２０Ａの制御部２１は、Ａ５４０のステップを実行し、処理を終了させる。また、通信Ｉ／Ｆ２２によってサーバ１０からウォレット連携承認確認情報を受信すると、端末２０Ｂの制御部２１は、ウォレット連携承認確認情報を表示部２４に表示させ（Ｂ７５０）、処理を終了させる。

図１８−６に戻り、連携承認が「未」である端末２０に対するユーザ操作に基づいて、連携承認することが選択される場合（Ｌ１１０：連携承認）、アカウント追加連携処理が実行される（Ｌ１２０）。

図１８−８は、アカウント追加連携処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、連携済みユーザの端末である端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、未連携ユーザの端末である端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

通信Ｉ／Ｆ１４によって端末２０Ｂからウォレット連携承認情報を受信する場合（Ｓ５２０：ＹＥＳ）、サーバ１０の制御部１１は、受信した端末のアプリケーションＩＤにおける連携状況管理データの連携承認を、「済」に変更し、Ｓ５３０のステップを実行する。ウォレット連携承認情報を受信しない場合（Ｓ５２０：ＮＯ）、サーバ１０の制御部１１は、Ｓ５３０のステップをスキップする。そして、サーバ１０の制御部１１は、Ｓ７５０〜Ｓ７６０のステップを実行し、処理を終了させる。

端末２０Ａの制御部２１は、Ａ５２０のステップを実行後、Ａ５４０のステップを実行し、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット情報を受信する場合（Ｂ５３０：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ５４０のステップを実行し、処理を終了させる。連携ウォレット情報を受信しない場合（Ｂ５３０：ＮＯ）、端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からウォレット連携承認確認情報すると、ウォレット連携承認確認情報を表示部２４に表示させ（Ｂ７６０）、処理を終了させる。

図１８−６に戻り、アカウント追加連携処理において、連携ウォレットに新たにアカウントの連携承認が行われた場合（Ｌ１３０：ＹＥＳ）、連携ウォレット遡及精算処理が実行される（Ｌ１４０）。連携ウォレットに連携承認がされなかった場合には（Ｌ１３０：ＮＯ）、Ｌ１１０のステップに処理を戻す。

なお、新たにアカウントの連携承認が行われた場合においても（Ｌ１３０：ＹＥＳ）、限定ではなく例として、新たに連携承認した端末２０における遡及精算の承認がない場合には、連携ウォレット遡及精算処理は実行されないようにしてもよいし、そのようにしなくてもよい。

図１８−９は、連携ウォレット遡及精算処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、アカウント連携済みユーザの端末である端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、新たにアカウント連携したユーザの端末である端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

サーバ１０の制御部１１は、第１１の連携ウォレット管理データベース１５７Ｋにおける決済参加アカウントデータを参照し、連携ウォレットによる支払いのうち、新たに連携承認したアカウントが参加していない取引ＩＤを探索する。そして、探索された取引ＩＤと、決済履歴データと、立替履歴データとに基づいて、各取引ＩＤにおける遡及精算必要額と、それぞれのアカウントへの送金額とを算出し、決済履歴データと紐づけて連携ウォレット遡及精算候補情報を生成する。そして、サーバ１０の制御部１１は、連携ウォレット遡及精算候補情報を、通信Ｉ／Ｆ１４によって端末２０Ｂに送信する（Ｓ７６５）。

限定ではなく例として、連携ウォレットにおける支払いが割り勘の場合、遡及精算必要額と、それぞれのアカウントへの送金額とは、限定ではなく例として、以下のように算出できる。
・遡及精算必要額＝決済での支払い額÷（決済参加アカウントデータに記録されたアカウント数＋１）
・決済参加アカウントデータに記録された各アカウントへの送金額＝遡及精算必要額÷決済参加アカウントデータに記録されたアカウント数

なお、立替履歴データが存在するアカウントへの送金額を決定する場合、立替金額を参照し、立替者に対して最大で立替金額まで送金額を増加させ、その分、被立替者への送金額を減少させるようにしてもよいし、そのようにしなくてもよい。この場合、サーバ１０の制御部１１は、遡及精算が実行されると立替金額を更新する。立替金額が「０」となる場合には、サーバ１０の制御部１１は、その取引における立替履歴を、立替履歴データから消去する。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット遡及精算候補情報を受信すると、端末２０Ｂの制御部２１は、連携ウォレット遡及精算候補情報の各取引について、限定ではなく例として、ユーザ操作に基づいて、遡及精算必要額を送金するか否かを判定し、遡及精算を実行する取引についての情報である遡及精算情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ７８０）。

なお、遡及精算必要額と、それぞれのアカウントへの送金額とは、決済履歴データと、立替履歴データとに基づいて、端末２０Ｂで算出するようにしてもよいし、そのようにしなくてもよい。また、遡及精算必要額やそれぞれのアカウントへの送金額を、端末２０Ｂに対するユーザ操作に基づいて決定するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ１４によって端末２０Ｂから遡及精算情報を受信すると、サーバ１０の制御部１１は、選択された取引について、ユーザＢ．Ｂのアカウントから決済参加アカウントデータに記録された各アカウントへの送金を実行する。そして、サーバ１０の制御部１１は、遡及精算必要額が送金されると、決済参加アカウントデータに、遡及精算を行ったユーザアカウントを追加して記憶させる（Ｓ７８０）。

その後、サーバ１０の制御部１１は、遡及精算処理における送金の結果である遡及精算結果情報を、通信Ｉ／Ｆ１４によって各端末に送信する（Ｓ７９０）。そして、サーバ１０の制御部１１は、処理を終了させる。

なお、遡及精算結果情報には、遡及精算結果情報を受信する端末のアカウントと関連しない送金の情報を含まないようにしてもよいし、そのようにしなくてもよい。また、遡及精算結果情報は、グループメンバー全員に送信するようにしてもよいし、連携承認が「済」のメンバーの端末のみに送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から遡及精算結果情報を受信すると、端末２０Ａの制御部２１は、遡及精算結果情報を表示部２４に表示させ（Ａ７６０）、処理を終了させる。
通信Ｉ／Ｆ２２によってサーバ１０から遡及精算結果情報を受信すると、端末２０Ａの制御部２１は、遡及精算結果情報を表示部２４に表示させ（Ｂ７９０）、処理を終了させる。

図１８−６に戻り、連携ウォレット遡及精算処理が実行されると、Ｌ１１０のステップに処理を戻す。

限定ではなく例として、端末２０に対するユーザ操作に基づいて、連携ウォレットによる支払いを実行することが選択される場合（Ｌ１１０：支払い）、サーバ１０の制御部１１は、支払いを実行しようとする端末２０のアカウントが連携承認「済」であるか否かを判定する（Ｌ１５０）。

支払いを実行しようとする端末２０のアカウントが連携承認済みである場合（Ｌ１５０：ＹＥＳ）、連携ウォレット支払い処理が実行される（Ｌ１６０）。連携ウォレット支払い処理については、限定ではなく例として、図７−３に従って実行することが可能である。

連携ウォレット支払い処理において、連携支払い可能額が不足し、連携残高補充処理が実行された場合（Ｌ１７０：ＹＥＳ）、連携ウォレット精算処理が実行される（Ｌ１８０）。連携ウォレット精算処理を実行後、Ｌ１１０のステップに処理を戻す。
なお、連携ウォレット精算処理については、限定ではなく例として、図７−５に従って実行することが可能である。

連携ウォレット支払い処理において連携支払い可能額に関する立て替えが発生しなかった場合には（Ｌ１７０：ＮＯ）、連携ウォレット精算処理は実行されない。

なお、直前の連携ウォレット支払い処理において連携支払い可能額に関する立て替えが発生しなかった場合でも、それ以前の連携ウォレット支払い処理における立替履歴データが存在し、立替が解消していない場合には、連携ウォレット精算処理を実行するようにしてもよいし、そのようにしなくてもよい。

支払いを実行しようとする端末２０のアカウントが連携承認済みでない場合（Ｌ１５０：ＮＯ）、連携ウォレット支払い処理は実行されず、Ｌ１１０のステップに処理を戻す。
なお、この場合、支払いを実行しようとする端末２０の表示部２４に、再度ウォレット連携承認確認情報を表示させ、連携承認を促すようにしてもよいし、そのようにしなくてもよい。

限定ではなく例として、端末２０に対するユーザ操作に基づいて、連携ウォレットによる支払い履歴の確認を実行することが選択される場合（Ｌ１１０：履歴確認）、サーバ１０の制御部１１は、支払いを実行しようとする端末２０のアカウントが連携承認「済」であるか否かを判定する（Ｌ１８５）。支払いを実行しようとする端末２０のアカウントが連携承認済みである場合（Ｌ１８５：ＹＥＳ）、連携ウォレット支払い履歴確認処理が実行される（Ｌ１９０）。

連携ウォレット支払い履歴確認処理では、サーバ１０の制御部１１は、第１１の連携ウォレット管理データベース１５７Ｋを参照し、この連携ウォレットの決済履歴データと立替履歴データとを、通信Ｉ／Ｆ１４によって履歴確認を要求した端末２０（限定ではなく例として、端末２０Ａ）に送信する。なお、加えて決済参加アカウントデータを送信するようにしてもよいし、そのようにしなくてもよい。

なお、サーバ１０の制御部１１は、決済履歴データと立替履歴データとのうち、端末２０Ａが連携承認を行った後の取引に関する履歴のみを送信するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から決済履歴データと立替履歴データとを受信すると、端末２０Ａの制御部２１は、決済履歴データと立替履歴データとを表示部２４に表示させる。
なお、端末２０Ａの制御部２１は、加えて決済参加アカウントデータを受信し、決済履歴データと立替履歴データとのうち、端末２０Ａが連携承認を行った後の取引に関する履歴のみを表示するようにしてもよいし、そのようにしなくてもよい。

端末２０Ａの入出力部２３に対するユーザ操作に基づいて、表示された決済履歴データから、立替精算または連携承認前の支払いに関する遡及精算が選択される場合（Ｌ２００：ＹＥＳ）、サーバ１０の制御部１１は、精算の内容を判定する（Ｌ２１０）。
そして、精算内容が立替精算の場合は（Ｌ２１０：立替精算）、連携ウォレット精算処理を実行する（Ｌ１８０）。一方、精算内容が連携承認前の支払いに関する遡及精算の場合は（Ｌ２１０：遡及精算）、連携ウォレット遡及精算処理を実行する（Ｌ１４０）。
なお、複数の取引の立替精算や遡及精算をまとめて行うようにしてもよいし、そのようにしなくてもよい。

限定ではなく例として、端末２０に対するユーザ操作に基づいて、連携ウォレットの破棄を実行することが選択される場合（Ｌ１１０：破棄）、連携ウォレット破棄処理が実行される（Ｌ２２０）。連携ウォレット破棄処理については、限定ではなく例として、図７−４のＳ３４０以下のステップに従って実行することが可能である。そして、システムは処理を終了する。

なお、連携ウォレット破棄処理を実行する前に、連携ウォレット遡及精算処理あるいは連携ウォレット精算処理、あるいはその両方を実行するようにしてもよいし、そのようにしなくてもよい。また、立替履歴データに取引が残っている場合には、連携ウォレット破棄処理を実行しないようにしてもよいし、そのようにしなくてもよい。遡及精算が完了していない場合には、連携ウォレット破棄処理を実行しないようにしてもよいし、そのようにしなくてもよい。

図１８−１０は、本実施例における各処理が実行されるタイミングを説明するためのタイミングチャートの一例を示す図である。
ここでは、上記のフローで説明したアカウント追加連携処理と、連携ウォレット支払い処理と、連携ウォレット遡及精算処理とが各端末において実行指示されるタイミングについて説明する。説明を簡略化するため、連携ウォレット支払い処理において、立て替えは発生しない場合を考える。

連携ウォレット生成を実行する端末を端末２０Ａとする。そして、連携ウォレットの他の連携メンバーの端末を端末２０Ｂ・端末２０Ｃとする。
このタイミングチャートでは、横軸を時間軸とし、各端末２０が、アカウント追加連携処理を行うタイミングを白の六角形で、連携ウォレット支払い処理を行うタイミングを白の丸で、連携ウォレット遡及精算処理を行うタイミングを白の四角形で示している。

連携ウォレット生成処理後、端末２０Ａにおいて、支払い１が実行される。支払い１にはユーザＡ．Ａのみが参加している。
その後、端末２０Ｂにおいて、アカウント追加連携処理が実行される。そして、端末２０Ｂにおいて、支払い１に関する連携ウォレット遡及精算処理が実行される。

次いで、端末２０Ｂにおいて、支払い２が実行される。支払い２は、ユーザＡ．ＡとユーザＢ．Ｂとが参加している。
その後、端末２０Ｃにおいて、アカウント追加連携処理が実行される。そして、端末２０Ｃにおいて、支払い１と支払い２とに関する連携ウォレット遡及精算処理が実行される。
そして、端末２０Ｃにおいて、支払い３が実行される。支払い３には、ユーザＡ．ＡとユーザＢ．ＢとユーザＣ．Ｃとが参加している。

最後に、連携ウォレット破棄処理がいずれかの端末２０によって実行され、処理は終了される。

＜第１８実施例の効果＞
本実施例は、ウォレット連携承認確認情報（限定ではなく、第１情報の一例）は、第２ユーザアカウントの第２ユーザによる、第１ユーザアカウントの第１ユーザと、第２ユーザとを含むトークルーム（限定ではなく、チャットルームの一例）に対する入力に基づいて、第１ユーザの端末２０に送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第２アカウントの第２ユーザによる、第１ユーザと、第２ユーザとを含むチャットルームに対する入力に基づいて、第１情報が第１ユーザの端末に簡単に送信されるようにすることができる。

また、本実施例は、ウォレット連携承認確認情報（限定ではなく、第１情報の一例）は、第２ユーザアカウントの第２ユーザによる、第１ユーザアカウントの第１ユーザと、第２ユーザとを含むトークルーム（限定ではなく、チャットルームの一例）の作成に基づき、第１ユーザの端末２０に送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第２アカウントの第２ユーザによる、第１ユーザと、第２ユーザとを含むチャットルームの作成に基づいて、第１情報が第１ユーザの端末に簡単に送信されるようにすることができる。

また、これらの場合、端末２０は、第１ユーザアカウントから第２ユーザアカウントに決済金額のうちの一部または全部の金額を送信するための処理に基づき、その金額を第２ユーザアカウントに送金したことを示す情報をトークルームに表示するようにすることができる。
このような構成により得られる実施例の効果の一例として、チャットルームへの表示という分かり易い形で、第１金額を第２アカウントに送金したことを、第１アカウントの第１ユーザに知らせることができる。

また、これらの場合、端末２０は、第１ユーザアカウントと第２ユーザアカウントとの連携が行われていない場合、第１ユーザアカウントと、第２ユーザアカウントとに基づく支払いコード（限定ではなく、第１コード情報の一例）、または第１ユーザアカウントと、第２ユーザアカウントとに基づく支払い店舗コード（限定ではなく、第２コード情報の一例）を読み取るためのコードリーダ画面（限定ではなく、第２コード情報を読み取るための表示の一例）を表示部２４に表示しない制御を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けが行われていない場合、第１アカウントと、第２アカウントとに基づく決済を行うことができないようにすることができる。

＜第１８変形例（１）＞
上記の実施例では、連携承認後、連携ウォレットでの支払い履歴が確認可能となるとして説明したが、これに限定されない。
第１７変形例（３）と同様に、連携ウォレット生成後、連携承認が「未」であるアカウントの端末２０においても、連携ウォレットでの支払い履歴の確認ができるようにしてもよいし、そのようにしなくてもよい。

図１８−１１は、この場合の端末２０の表示部２４に表示される画面の一例を示す図である。
図１８−１１左側および中央の端末２０Ａの表示部２４に表示される画面は、図１８−２左側および中央とそれぞれ同様である。
図１８−１１右側の端末２０Ｂの表示部２４に表示される画面は、図１８−２右側と同様であるが、この例では、グループトークルームに表示されるメッセージの時系列が一部異なっている。

具体的には、時系列で古い順に、ユーザＡ．Ａからのウォレット連携依頼メッセージ→連携ウォレットによる決済完了通知メッセージ→ユーザＡ．Ａからの連携ウォレットによる商品購入報告メッセージ、の順でメッセージが表示されている。
つまり、この表示画面例では、ユーザＢ．Ｂが連携承認する前に、連携ウォレットによる決済履歴を、自身の端末２０Ｂに表示されるグループトークルーム画面で確認できるように構成されている。

この場合における処理は、限定ではなく例として、図１８−６においてＬ１８５のステップを実行せず、Ｌ１１０：履歴確認となった場合Ｌ１９０のステップを実行するようにすればよい。そして、Ｌ１９０のステップを実行後、Ｌ１１０に処理を戻す。

＜第１８変形例（２）＞
上記の実施例では、連携ウォレットの支払い履歴確認後、立替精算や遡及精算が実行されるとしたが、これに限定されない。
限定ではなく例として、図１８−６においてＬ１１０のステップで一括立替精算が選択されると、その時点までの取引（支払い）の立て替えを一括で精算するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、図１８−６においてＬ１１０のステップで一括遡及精算が選択されると、その時点までの取引（支払い）の遡及精算を一括で実行するようにしてもよいし、そのようにしなくてもよい。
もしくは、一括立替精算と一括遡及精算とを一括して実行するようにしてもよいし、そのようにしなくてもよい。

＜第１９実施例＞
第１８実施例では、連携ウォレット遡及精算処理は、新たに連携承認したアカウントのユーザが能動的に連携承認前の支払いについての精算を実行する処理として説明したが、これに限定されない。
第１９実施例は、新たに連携承認したユーザに対して、連携承認前の支払いを催促する実施例である。

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

＜表示画面＞
図１９−１は、本実施例において端末２０Ａの表示部２４に表示される画面の遷移の一例を示す図である。
図１９−１左側では、グループ「バンド仲間」のグループトークルームの画面下部から、連携ウォレット情報表示領域ＷＩＲ１がせり上がって表示されている。また、グループ「バンド仲間」の連携ウォレットであることを示す情報の表示欄には、連携ウォレット支払い履歴ボタンＢＴ５４が表示されている。この連携ウォレット支払い履歴ボタンＢＴ５４がタップされると、図１９−１中央の画面が表示される。

この画面では、連携ウォレット情報表示領域ＷＩＲ１における連携ウォレット支払い履歴の表示欄に、ユーザＡ．Ａが商品購入で支払った「４，５００円」の支払い金額のうちの少なくとも一部の金額の支払いを、他の連携メンバー（この例ではユーザＢ．Ｂ）に催促するための「おねだり」の文字を含む支払い催促ボタンＢＴ６０が表示されている。この支払い催促ボタンＢＴ６０がタップされると、図１９−１右側の画面が表示される。

この画面では、連携ウォレット情報表示領域ＷＩＲ１の中央部に、連携ウォレットでの過去の支払いに対する催促を行うことを確認するための情報がポップアップ形式で表示されている。具体的には、「過去の支払いをおねだりしますか？」の文字と、ユーザＡ．Ａに「２，２５０円」支払うようにユーザＢ．Ｂに催促することを示す情報とが表示されている。また、その下には、「はい」のボタンと、「いいえ」のボタンとが表示されており、「はい」のボタンがタップされると、ユーザＡ．ＡからユーザＢ．Ｂに対して、支払いの催促が行われる。

図１９−２は、この場合に各々の連携メンバーの端末２０の表示部２４に表示される画面の一例を示す図である。
図１９−２左側は、端末２０Ａに表示されるグループトークルーム画面であり、限定ではなく例として、連携ウォレットでの支払い完了通知メッセージ→ユーザＡ．Ａからの商品購入報告メッセージ→ユーザＢ．Ｂによる連携承認メッセージ、の順でメッセージが表示されている。

図１９−２中央は、端末２０Ｂに表示されるグループトークルーム画面であり、限定ではなく例として、ユーザＡ．Ａからの商品購入報告メッセージ→ユーザＢ．Ｂによる連携承認メッセージ→連携ウォレットでの支払い完了通知メッセージ→ユーザＡ．Ａからの支払い催促メッセージ、の順でメッセージが表示されている。

支払い催促メッセージが、ユーザＡ．ＡからユーザＢ．Ｂに対する支払いの催促に対応するメッセージである。
この支払い催促メッセージには、支払いアプリケーション［ＰａｙｍｅｎｔＡｐｐ］の文字および「おねだり」の文字とともに、支払いの催促の詳細に関する情報が表示されている。
また、支払い催促メッセージには精算ボタンが設けられており、精算ボタンをタップすることで、ユーザＡ．Ａからの支払いの催促に対する精算、つまり、ユーザＢ．ＢからユーザＡ．Ａへの送金を行うことが可能に構成されている。

図１９−２右側は、端末２０Ｃに表示されるグループトークルーム画面であり、限定ではなく例として、ユーザＡ．Ａからのウォレット連携依頼メッセージ→ユーザＡ．Ａからの商品購入報告メッセージ→ユーザＢ．Ｂによる連携承認メッセージ、の順でメッセージが表示されている。

この例では、支払い催促メッセージは、端末２０Ａに表示されるグループトークルームには表示されていない。これは、ユーザＡ．Ａは支払いの催促を行った当人であるためである。
なお、これに限定されず、端末２０Ａに表示されるグループトークルームにも、支払い催促メッセージを表示させるようにしてもよい。

また、支払い催促メッセージは、端末２０Ｃに表示されるグループトークルームには表示されていない。これは、ユーザＣ．Ｃは、未連携承認の状態であり、現状は支払いに関与しないためである。

＜処理＞
図１９−３は、本実施例における連携ウォレット遡及精算処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、連携済みユーザの端末である端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、新たに連携したユーザの端末である端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

通信Ｉ／Ｆ２２によってサーバ１０から連携ウォレット遡及精算候補情報を受信すると、端末２０Ａの制御部２１は、連携ウォレット遡及精算候補情報の各取引について、限定ではなく例として、ユーザ操作に基づいて、遡及精算必要額の送金を催促するか否かを判定し、催促を実行する取引についての情報である遡及精算要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ７４０）。

なお、遡及精算必要額と、それぞれのアカウントへの送金額とは、決済履歴データと、立替履歴データとに基づいて、端末２０Ａで算出するようにしてもよいし、そのようにしなくてもよい。また、遡及精算必要額やそれぞれのアカウントへの送金額を、端末２０Ａに対するユーザ操作に基づいて決定するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ１４によって端末２０Ａから遡及精算要求情報を受信すると、サーバ１０の制御部１１は、遡及精算要求情報に基づいて、限定ではなく例として、取引ごとの遡及精算必要額を含む遡及精算依頼情報を通信Ｉ／Ｆ１４によって取引の後に連携承認を行った端末２０（この場合には端末２０Ｂ）に送信する（Ｓ７７０）。

なお、サーバ１０が、支払いアプリケーション管理サーバとメッセージングアプリケーション管理サーバとで構成される場合、限定ではなく例として、支払いアプリケーション管理サーバが遡及精算要求情報を受信し、支払いアプリケーション管理サーバから要求を受けたメッセージングアプリケーション管理サーバが、遡及精算依頼情報を端末２０Ｂに送信するようにしてもよいし、そのようにしなくてもよい。また、支払いアプリケーション管理サーバを介さず、遡及精算要求情報をメッセージングアプリケーション管理サーバが受信し、遡及精算依頼情報をメッセージングアプリケーション管理サーバが送信するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０から遡及精算依頼情報を受信すると、端末２０Ｂの制御部２１は、遡及精算依頼情報を表示部２４に表示させる（Ｂ７７０）。

なお、端末２０Ａにおいて遡及精算要求情報が送信された確認が取れるように、サーバ１０の制御部１１は、遡及精算依頼情報を端末２０Ａに送信するようにしてもよいし、そうしなくてもよい。そして、端末２０Ａの制御部２１は、受信した遡及精算依頼情報を表示部２４に表示させるようにしてもよいし、そうしなくてもよい。

端末２０Ｂの入出力部２３に対するユーザ操作に基づいて、遡及精算を依頼された取引（支払い）の遡及精算を実行する場合（Ｂ７７５：ＹＥＳ）、端末２０Ｂの制御部２１は、Ｂ７８０〜Ｂ７９０のステップを実行する。
通信Ｉ／Ｆ１４によって端末２０Ｂから遡及精算情報を受信する場合（Ｓ７７５：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ７８０〜Ｓ７９０のステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から遡及精算結果情報を受信する場合（Ａ７５０：ＹＥＳ）、端末２０Ａの制御部２１は、Ａ７６０のステップを実行する。

＜第１９実施例の効果＞
本実施例は、端末２０は、第１ユーザアカウントと第２ユーザアカウントとの連携に基づき、少なくとも第２ユーザアカウントによって行われた支払い履歴の情報（限定ではなく、第２決済に関する情報の一例）を表示部２４に表示する。また、端末２０は、この支払い履歴に基づく支払いを催促する情報（限定ではなく、第２決済の支払いの依頼に関する第２情報の一例）を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けに基づき、少なくとも第２アカウントによって行われた第２決済に関する情報が端末の表示部に表示されるため、第１ユーザは、限定ではなく例として、第１アカウントと第２アカウントとが関連付けられる以前に少なくとも第２アカウントによって行われた第２決済に関する情報を確認して把握することができる。

また、この場合、端末２０は、自己の端末２０のユーザと、第２ユーザアカウントの第２ユーザとを含むトークルーム（限定ではなく、チャットルームの一例）に、支払いを催促する情報の表示（限定ではなく、第２情報に基づく第２表示の一例）を表示する制御を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、受信した第２決済の支払いの依頼に関する第２情報を確認した上で、第１ユーザが、第２決済の支払いを行うことができる。

また、この場合、支払いを催促する情報は、トークルームに含まれる第１ユーザと第２ユーザとで送受信されるメッセージを中継するサーバ１０によって送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、チャットルームに含まれる第１ユーザと第２ユーザとで送受信されるメッセージを中継するサーバから、第２情報を簡単に取得することができる。

また、この場合、支払いを催促する情報の表示は、第１ユーザのトークルームには表示されるが、第２ユーザのトークルームには表示されないようにすることができる。
このような構成により得られる実施例の効果の一例として、支払いの依頼先のユーザ（第１ユーザ）に第２決済の支払いの依頼があったことを確実に知らせることができる。一方、支払いの依頼元のユーザ（第２ユーザ）に対しては支払いを依頼したことを確認不要とすることができる。

また、この場合、端末２０は、トークルームに表示された支払いを催促する情報の表示に対する第１ユーザによる入力に基づいて、決済金額のうちの一部または全部の金額（限定ではなく、第２金額の一例）を第１ユーザアカウントから第２ユーザアカウントへ送金するための処理（限定ではなく、第１アカウントから第２アカウントへ送金することに関する処理の一例）を制御部２１によって行うようにすることができる。
このような構成により得られる実施例の効果の一例として、チャットルームに表示された第２表示に対する第１ユーザによる入力という簡単な方法で、第２決済のうちの少なくとも一部である第２金額を第１アカウントから第２アカウントへ送金することができる。

＜第１９変形例（１）＞
上記の実施例では、遡及精算依頼情報は、サーバ１０から送信されるとしたが、これに限定されない。限定ではなく例として、図１９−３のＡ７４０のステップにおいて、端末２０Ａの制御部２１は、遡及精算要求情報を通信Ｉ／Ｆ２２によって端末２０Ｂに直接送信するようにしてもよいし、そのようにしなくてもよい。

そして、端末２０Ｂの制御部２１は、受信した遡及精算要求情報を表示部２４に表示させ、遡及精算するか否かの選択を受け付ける（Ｂ７７５）ようにしてもよいし、そのようにしなくてもよい。

＜第２０実施例＞
上記の実施例では、連携ウォレットの破棄（全ての連携アカウントについて一括して連携ウォレットを無効化）について説明したが、これに限定されない。
第２０実施例は、各々の連携アカウントがアカウント連携を解除する手法に関する実施例である。

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

本実施例における「アカウント連携の解除」には、限定ではなく例として、以下のいずれかが含まれる。
（ａ）連携承認の解除
（ｂ）連携アカウントの削除

（ａ）は、連携承認「済」とされた連携承認を「未」に戻すことを意味する。この場合、連携ウォレット管理データにおいて、その連携アカウントのデータは削除されずに残ったままであるが、その連携アカウントは使用できなくなる。

（ｂ）は、連携ウォレット管理データにおいて、その連携アカウントのデータを削除することを意味する。この場合も、その連携アカウントは使用できなくなる。

限定ではなく例として、連携アカウント（その連携アカウントのユーザ）が連携ウォレットから脱退することを希望する場合に、上記のアカウント連携の解除が行われる。

なお、上記（ａ）連携承認の解除では、連携ウォレット管理データにおいて連携アカウントのデータが削除されずに残るため、厳密には、連携ウォレットからの脱退ではないと捉えることもできなくはない。しかし、ユーザにとっては、「連携ウォレットからの脱退」が直感的に分かり易い可能性があるため、このように表現するものとする。

また、ユーザにとっては、アカウント連携を自分の意思で自由に解除できる方が望ましい可能性がある。そこで、限定ではなく例として、アカウント連携の解除には、他の連携アカウントの承認は不要とすることができる。
なお、これとは異なり、アカウント連携の解除に、他の連携アカウントの承認を必要としてもよい。

＜表示画面＞
図２０−１は、本実施例において端末２０の表示部２４に表示される画面の遷移の一例を示す図である。
図２０−１左側は、端末２０Ｂの表示部２４に表示される画面の一例を示す図である。この画面は、グループ「バンド仲間」のグループトークルーム画面であり、連携ウォレット情報表示領域ＷＩＲ１が、画面下部からせり上がって表示されている。

連携ウォレット情報表示領域ＷＩＲ１の下部には、連携ウォレットから脱退するための連携ウォレット脱退ボタンＢＴ７０と、前述した連携ウォレット破棄ボタンＢＴ３０とが表示されている。
なお、連携ウォレット破棄ボタンＢＴ３０の表示は必須ではなく、これを表示させないようにしてもよい。

連携ウォレット脱退ボタンＢＴ７０がタップされると、サーバ１０を介して、アカウント連携解除確認情報が端末２０Ａに送信される。その結果、端末２０Ａの表示部２４には、図２０−１中央の画面が表示される。

この画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザＡ．Ａからの連携ウォレットの脱退を希望するメッセージである連携ウォレット脱退希望メッセージが表示されている。この連携ウォレット脱退希望メッセージには、連携ウォレットの脱退を希望する内容が表示され、その下には、脱退を拒否するための拒否ボタンと、脱退を認可（許可）するための認可ボタンとが設けられている。

認可ボタンがタップされると、アカウント連携解除認可情報が端末２０Ａからサーバ１０に送信される。そして、サーバ１０によって、アカウント連携解除処理が行われ、ユーザＢ．Ｂのアカウント連携が解除される。その結果、端末２０Ｂの表示部２４には、図２０−１右側の画面が表示される。

この画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザＢ．Ｂが連携ウォレットの脱退を希望したことを示すメッセージ→ユーザＡ．Ａによる連携ウォレットの脱退を許可するメッセージ→ユーザＢ．Ｂが連携ウォレットから脱退したことを示すメッセージ、の順でメッセージが表示されている。

＜処理＞
図２０−２は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、端末２０およびサーバ１０で構成されるシステムが実行する処理の一例を示している。
なお、サーバ１０を、支払いサービスを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバに分けて構成するようにしてもよいし、そのようにしなくてもよい。

限定ではなく例として、端末２０に対するユーザ操作に基づいて、ユーザＢ．Ｂのアカウント連携を解除することが選択される場合（Ｌ１１０：脱退）、連携ウォレット脱退処理が実行される（Ｌ２３０）。

なお、これとは異なり、限定ではなく例として、連携ウォレットが生成されたメッセージングサービスのグループからユーザが退出する場合に、連携ウォレット脱退処理が実行されるようにしてもよいし、そのようにしなくてもよい。

また、連携アカウントに設定される、前述した合計制限金額や連続決済回数が「０」となった場合に、連携ウォレット脱退処理が実行されるようにしてもよいし、そのようにしなくてもよい。

図２０−３は、連携ウォレット脱退処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、連携承認済みユーザの端末である端末２０Ａ（ユーザＡ．Ａの端末２０）の制御部２１が実行する処理、アカウント連携の解除を選択したユーザの端末である端末２０Ｂ（ユーザＢ．Ｂの端末２０）の制御部２１が実行する処理、サーバ１０の制御部１１が実行する処理の一例を示している。

端末２０Ｂの制御部２１は、アカウント連携の解除を要求するアカウント連携解除要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ８１０）。

通信Ｉ／Ｆ１４によって端末２０Ｂからアカウント連携解除確認情報を受信すると、サーバ１０の制御部１１は、アカウント連携の解除を認めるか否かを確認するアカウント連携解除確認情報を、通信Ｉ／Ｆ１４によって端末２０Ａに送信する（Ｓ８１０）。

なお、アカウント連携解除確認情報は、連携ウォレットを生成した端末２０に対して送信するようにしてもよいし、連携ウォレットの連携承認済みである連携アカウントの全ての端末２０に対して送信するようにしてもよい。また、連携ウォレットあるいはグループに代表者が設定されている場合、その代表者に対して送信するようにしてもよいし、そのようにしなくてもよい。

通信Ｉ／Ｆ２２によってサーバ１０からアカウント連携解除確認情報を受信すると、端末２０Ａの制御部２１は、アカウント連携解除確認情報を表示部２４に表示させる（Ａ８１０）。
端末２０Ａの入出力部２３に対するユーザ操作に基づいて、アカウント連携の解除を実行することを認可することが選択される場合（Ａ８１０：ＹＥＳ）、端末２０Ａの制御部２１は、アカウント連携解除認可情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。
認可しないことが選択される場合には（Ａ８１０：ＮＯ）、端末２０Ａの制御部２１は、処理を終了させる。

通信Ｉ／Ｆ１４によってアカウント連携解除確認情報を送信した端末２０からアカウント連携解除認可情報を受信する場合（Ｓ８２０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント連携解除要求情報に基づいて、アカウント連携解除処理を実行する（Ｓ８３０）。

アカウント連携解除処理では、サーバ１０の制御部１１は、限定ではなく例として、ユーザＢ．Ｂのユーザアカウントにおける、連携状況管理データの連携承認を「済」から「未」に変更する。これは、前述した（ａ）連携承認の解除、に相当する。

なお、このようにするのではなく、連携状況管理データからユーザＢ．Ｂのユーザアカウントそれ自体を削除するようにしてもよい。これは、前述した（ｂ）連携アカウントの削除、に相当する。

そして、サーバ１０の制御部１１は、ユーザＢ．Ｂのアカウント連携が解除されたことを示すアカウント連携解除情報を、通信Ｉ／Ｆ２２によってグループ内の端末２０に送信する（Ｓ８４０）。
なお、アカウント連携解除情報は、アカウント連携解除を要求（申請）した端末２０と、アカウント連携解除確認情報を送信した端末２０とに対してのみ送信するようにしてもよいし、そのようにしなくてもよい。
また、アカウント連携解除情報は、アカウント連携解除を要求（申請）した端末２０と、連携ウォレットを生成した端末２０とに対して送信するようにしてもよいし、そのようにしなくてもよい。
また、連携ウォレットの代表者、またはグループの代表者の端末２０も含めて送信するようにしてもよい。

通信Ｉ／Ｆ２２によってサーバ１０からアカウント連携解除情報を受信すると、端末２０Ａの制御部２１は、受信したアカウント連携解除情報を表示部２４に表示させ（Ａ８３０）、処理を終了させる。

通信Ｉ／Ｆ２２によってサーバ１０からアカウント連携解除情報を受信する場合（Ｂ８２０：ＹＥＳ）、端末２０Ｂの制御部２１は、受信したアカウント連携解除情報を表示部２４に表示させる（Ｂ８３０）。そして、端末２０Ｂの制御部２１は、ユーザＢ．Ｂのユーザアカウントでの連携ウォレットによる支払いが実行不能になったことを示す表示を表示部２４に表示させるなどして、連携ウォレットが使用不可となったことを報知する（Ｂ８４０）。
アカウント連携解除情報を受信しない場合（Ｂ８２０：ＮＯ）、端末２０Ｂの制御部２１は、処理を終了させる。

アカウント連携解除処理が実行される条件としては、以下のような場合が考えられる。
・グループ全員からアカウント連携解除の認可を得た場合
・連携承認済みメンバー全員からアカウント連携解除の認可を得た場合
・設定人数を超えるメンバー（限定ではなく例として、連携承認済みメンバーの過半数）からアカウント連携解除の認可を得た場合
・連携ウォレットを生成したメンバーからアカウント連携解除の認可を得た場合
・連携ウォレットの代表者、またはグループの代表者からアカウント連携解除の認可を得た場合
・他のメンバーのアカウント連携解除の認可なしに無条件でアカウント連携解除が実行される場合

連携ウォレット脱退処理の実行後、サーバ１０の制御部１１は、連携ウォレットの連携メンバー全員のアカウント連携が解除されたか否かを判定する（Ｌ２４０）。全員のアカウント連携が解除された場合（Ｌ２４０：ＹＥＳ）、連携ウォレット破棄処理が実行される（Ｌ２２０）。
一方、アカウント連携が解除されていないメンバーが残っている場合は（Ｌ２４０：ＮＯ）、Ｌ１１０のステップに処理を戻す。

なお、連携ウォレットの連携メンバー全員のアカウント連携が解除された場合であっても（Ｌ２４０：ＹＥＳ）、連携ウォレット破棄処理を実行せず、この連携ウォレットにおける支払い履歴や立替履歴等を保持するようにしてもよいし、そのようにしなくてもよい。
この場合は、連携ウォレット生成処理を実行せずとも、グループ内のメンバーが連携承認を行えば、再び連携ウォレットによる支払いを行うことが可能となる。

図２０−４は、本実施例における各処理が実行されるタイミングを説明するためのタイミングチャートの一例を示す図である。
ここでは、上記のフローで説明したアカウント追加連携処理と、連携ウォレット支払い処理と、連携ウォレット遡及精算処理と、連携ウォレット脱退処理とが各端末において実行指示されるタイミングについて説明する。説明を簡略化するため、連携ウォレット支払い処理において、立て替えは発生しない場合を考える。

連携ウォレット生成を実行する端末を端末２０Ａとする。そして、連携ウォレットの他の連携メンバーの端末を端末２０Ｂ・端末２０Ｃとする。
このタイミングチャートでは、横軸を時間軸とし、各端末２０が、アカウント追加連携処理を行うタイミングを白の六角形で、連携ウォレット支払い処理を行うタイミングを白の丸で、連携ウォレット遡及精算処理を行うタイミングを白の四角形で、連携ウォレット脱退処理を行うタイミングを白の三角で示している。

連携ウォレット生成処理後、端末２０Ｂにおいて、アカウント追加連携処理が実行される。その後、端末２０Ａにおいて、支払い１が実行される。支払い１には、ユーザＡ．ＡとユーザＢ．Ｂとが参加している。

次いで、端末２０Ｃにおいて、アカウント追加連携処理が実行される。そして、端末２０Ｃにおいて、支払い１に関する連携ウォレット遡及精算処理が実行される。
その後、端末２０Ｂにおいて、連携ウォレット脱退処理が実行される。
そして、端末２０Ｃにおいて、支払い２が実行される。支払い３には、ユーザＡ．ＡとユーザＣ．Ｃとが参加している。

その後、端末２０Ｂにおいて、アカウント追加連携処理が再び実行される。そして、端末２０Ｂにおいて、支払い２に関する連携ウォレット遡及精算処理が実行される。
端末２０Ｂにおいて、支払い３が実行される。支払い３には、ユーザＡ．ＡとユーザＢ．ＢとユーザＣ．Ｃとが参加している。

支払い３の後、端末２０Ｃにおいて、連携ウォレット脱退処理が実行される。また、端末２０Ａにおいて、連携ウォレット脱退処理が実行される。
最後に、端末２０Ｂにおいて、連携ウォレット脱退処理が実行され、その後、連携ウォレット破棄処理が実行される。

＜第２０実施例の効果＞
本実施例は、端末２０が、第１ユーザアカウントのアカウント連携を解除するための処理、つまり、第１ユーザアカウントと第２ユーザアカウントとの連携を解除するための処理（限定ではなく、第１アカウントと第２アカウントとの関連付けの解除に関する処理の一例）を制御部２１によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、一旦関連付けた第１アカウントと第２アカウントとの関連付けを解除することができる。

また、この場合、第１ユーザアカウントのアカウント連携を解除するための処理は、第２ユーザアカウントに対してアカウント連携解除要求情報（限定ではなく、関連付けの解除の依頼に関する情報の一例）を送信する処理を含むようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントに対して関連付けを解除することを確認することができる。

また、この場合、第１ユーザアカウントのアカウント連携は、第２ユーザアカウントの第２ユーザの許可に基づいて解除されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第２アカウントの第２ユーザの許可がなければ、第１アカウントと第２アカウントとの関連付けが解除されないようにすることができる。つまり、第２ユーザの意に沿わずに第１アカウントと第２アカウントとが解除されてしまうことを防止できる。

また、この場合、第１ユーザアカウントのアカウント連携は、第１ユーザが、第１ユーザと、第２アカウントの第２ユーザとを含むトークルームから退出することに基づいて行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第１ユーザが、第１ユーザと、第２アカウントの第２ユーザとを含むチャットルームから退出する場合に、第１アカウントと第２アカウントとの関連付けを併せて解除することができる。

＜第２０変形例（１）＞
上記の実施例では、連携ウォレット脱退処理が実行されると、アカウント連携が解除されることとしたが、これに限定されない。
限定ではなく例として、連携ウォレット脱退処理が実行されると、連携ウォレット精算処理または連携ウォレット遡及精算処理、あるいはその両方が実行され、その後、アカウント連携が解除されるようにしてもよいし、そのようにしなくてもよい。

図２０−５は、本変形例において端末２０Ｂの表示部２４に表示される画面の遷移の一例を示す図である。
図２０−５左側には、図２０−１左側と同様の画面が表示されている。連携ウォレット脱退ボタンＢＴ７０がタップされると、限定ではなく例として、図２０−５右側の画面が表示される。

この画面では、連携ウォレット情報表示領域ＷＩＲ１の中央部に、連携ウォレットの精算を行うか否かを確認するための情報が表示されている。具体的には、「未精算の購入履歴があります」の文字とともに、未精算の購入履歴に関する詳細な情報が表示されている。この例では、支払い先を「ＸＸ楽器」とする「４，５００円」の支払いについて、ユーザＢ．ＢからユーザＡ．Ａへの「２，２５０円」の送金が未だ行われていない状態であることが示されている。

その下には、「精算しますか？」の文字とともに、「はい」のボタンと、「いいえ」のボタンとが表示されている。「はい」のボタンがタップされると、上記の精算が実行される。つまり、この例では、ユーザＢ．ＢからユーザＡ．Ａに対して「２，２５０円」が送金される。

この場合には、限定ではなく例として、図２０−３のＢ８１０のステップを実行後、連携ウォレット精算処理または連携ウォレット遡及精算処理、あるいはその両方を実行し、再び図２０−３の処理を続けて実行するようにすればよい。

なお、連携ウォレット精算処理または連携ウォレット遡及精算処理、あるいはその両方を実行後、連携アカウントの連携解除を要求する連携アカウントにおいて、未精算である立替精算や遡及精算が残っている場合、サーバ１０の制御部１１は、図２０−３のＳ８１０のステップを実行しないようにしてもよい。
この場合、アカウント連携を解除しようとする連携アカウントに未精算である立替精算や遡及精算が残っている場合には、アカウント連携解除は行われないことになる。

また、連携ウォレット精算処理または連携ウォレット遡及精算処理、あるいはその両方を実行後、連携アカウントの連携解除を要求する連携アカウントにおいて、未精算である立替精算や遡及精算が残っていない場合、サーバ１０の制御部１１は、アカウント連携解除認可情報の受信の有無にかかわらず、アカウント連携解除処理を実行するようにしてもよいし、そのようにしなくてもよい。
すなわち、アカウント連携解除しようとする連携アカウントに連携ウォレット内での貸し借りが存在しない場合には、他のメンバーの認可不要で、アカウント連携を解除するようにすることも可能である。

本変形例は、端末２０は、第１アカウントのアカウント連携に基づき、少なくとも第２ユーザアカウントによって行われた決済（限定ではなく、第３決済の一例）に関する情報を表示部２４に表示する。そして、端末２０は、第１アカウントのアカウント連携を解除したことに基づいて、この決済の支払いに関する情報の表示（限定ではなく、第３表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第１アカウントと第２アカウントとの関連付けに基づき、少なくとも第２アカウントによって行われた第３決済に関する情報を第１ユーザが閲覧して確認できるようにすることができる。また、第１アカウントと第２アカウントとが解除された場合に、第３決済の支払いに関する情報を第１ユーザが閲覧して確認できるようにすることができる。

１通信システム
１０サーバ
２０端末
３０ネットワーク
４０店舗ＰＯＳシステム
５０店舗コードリーダ装置

Claims

第１ユーザの第１アカウントと、前記第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末に実行させるためのプログラムであって、
前記第２アカウントに設定された第２金額に基づく前記第２アカウントの残高を前記端末の表示部に表示することと、
前記第１アカウントと、前記第２金額が設定された前記第２アカウントとに基づき、前記第１ユーザの前記端末によって第１決済に関する処理を前記端末の制御部によって行うこととが前記端末によって実行される。
請求項１に記載のプログラムであって、
前記第１ユーザによる前記端末に対する入力に基づいて、前記第１アカウントに対して第１金額を設定する制御を前記制御部によって行うことと、
設定された前記第１金額に基づく前記第１アカウントの残高と、前記第２金額に基づく前記第２アカウントの残高とを前記表示部に表示することとが前記端末によって実行される。
請求項２に記載のプログラムであって、
前記第２金額の情報は、前記第２アカウントの残高のうち、前記第１ユーザの前記端末に表示される最大金額の情報を含む。
請求項１から請求項３のいずれか一項に記載のプログラムであって、
前記第２金額の情報は、一回の前記決済に利用可能な最大金額の情報を含む。
請求項４に記載のプログラムであって、
前記表示部に表示される前記第２金額に基づく前記第２アカウントの残高は、前記第２アカウントの残高が前記第２金額よりも大きい場合、前記第２金額が前記表示部に表示され、前記第２アカウントの残高が前記第２金額よりも小さい場合、前記第２アカウントの残高が表示される。
請求項２に記載のプログラムであって、
前記第１ユーザによる前記端末に対する入力に基づいて、前記第１アカウントに設定された前記第１金額を変更する制御を前記制御部によって行うことが前記端末によって実行される。
請求項２に記載のプログラムであって、
前記第１決済の金額が、前記第１金額と前記第２金額の合計を超える場合、前記第２アカウントに対して前記第２金額の変更に関する情報を前記端末の通信部によって送信することが前記端末によって実行される。
請求項１から請求項７のいずれか一項に記載のプログラムであって、
前記第１ユーザによる前記端末に対する入力に基づいて、前記第１アカウントに対して、前記決済を複数回行うことに関する第１設定を前記制御部によって行うことが前記端末によって実行される。
請求項８に記載のプログラムであって、
前記第１設定は、前記第１アカウントによって前記決済が可能な回数に関する設定を含む。
請求項９に記載のプログラムであって、
前記決済が可能な回数は、前記第１アカウントの前記第１ユーザの認証を行わずに前記決済を行うことが可能な回数を含む。
請求項８から請求項１０のいずれか一項に記載のプログラムであって、
前記第１ユーザによる前記端末に対する入力に基づいて、前記第１アカウントに対して第１金額を設定する制御を前記制御部によって行うことが前記端末によって実行され、
前記第１設定は、前記第１アカウントによって、前記決済を複数回行った場合に利用可能な最大金額の情報を含み、
前記最大金額は、前記第１金額以上の金額である。
請求項１から請求項１１のいずれか一項に記載のプログラムであって、
前記第１決済は、前記第１アカウントと、前記第２アカウントと、前記第１アカウントおよび前記第２アカウントが関連付けられた第３アカウントとによって行われ、
前記第１アカウントの不足分を支払うアカウントは、前記第２アカウントに設定された前記第２金額と、前記第３アカウントに設定された第３金額とに基づいて、前記第２アカウントと前記第３アカウントのいずれかのうち一方が設定される。
請求項８に記載のプログラムであって、
前記第１決済は、前記第１アカウントと、前記第２アカウントと、前記第１アカウントおよび前記第２アカウントが関連付けられた第３アカウントとによって行われ、
前記第１アカウントの不足分を支払うアカウントは、前記第２アカウントに設定された前記決済を複数回行うことに関する第２設定と、前記第３アカウントに設定された前記決済を複数回行うことに関する第３設定とに基づいて、前記第２アカウントと前記第３アカウントのいずれかのうち一方が設定される。
請求項１から請求項１３のいずれか一項に記載のプログラムであって、
前記第２アカウントは、第２ユーザのアカウントである。
請求項１から請求項１４のいずれか一項に記載のプログラムであって、
前記第２アカウントは、複数のユーザが決済可能な共通アカウントである。
請求項１から請求項１５のいずれか一項に記載のプログラムであって、
前記第１アカウントと前記第２アカウントとは、前記第１ユーザと、前記第２アカウントの第２ユーザとを含むチャットルームと関連付けられており、
前記表示部に表示された前記チャットルームに対する、前記第１ユーザの入力に基づいて、前記第２金額に基づく前記第２アカウントの残高を前記表示部に表示することが前記端末によって実行される。
請求項１から請求項１５のいずれか一項に記載のプログラムであって、
前記第１アカウントと前記第２アカウントとは、前記第１ユーザと、前記第２アカウントの第２ユーザとを含むチャットルームと関連付けられており、
前記表示部に表示された前記チャットルームに対する、前記第１ユーザの入力に基づいて、前記第１決済に関する処理を前記制御部によって行うことが前記端末によって実行される。
請求項１から請求項１７のいずれか一項に記載のプログラムであって、
前記第２金額に基づく前記第２アカウントの残高情報を前記端末の通信部によって受信することと、
前記残高情報に基づく、前記第２アカウントの残高を前記表示部に表示することとが前記端末によって実行される。
第１ユーザの第１アカウントと、前記第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末の情報処理方法であって、
前記第２アカウントに設定された第２金額に基づく前記第２アカウントの残高を前記端末の表示部に表示することと、
前記第１アカウントと、前記第２金額が設定された前記第２アカウントとに基づき、前記第１ユーザの前記端末によって第１決済に関する処理を前記端末の制御部によって行うこととを含む。
第１ユーザの第１アカウントと、前記第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末であって、
前記第２アカウントに設定された第２金額に基づく前記第２アカウントの残高を表示する表示部と、
前記第１アカウントと、前記第２金額が設定された前記第２アカウントとに基づき、前記第１ユーザの前記端末によって第１決済に関する処理を行う制御部とを備える。
第１ユーザの第１アカウントと、前記第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行う端末であって、
メモリからプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、
前記プロセッサーは、
前記第２アカウントに設定された第２金額に基づく前記第２アカウントの残高を前記端末の表示部に表示することと、
前記第１アカウントと、前記第２金額が設定された前記第２アカウントとに基づき、前記第１ユーザの前記端末によって第１決済に関する処理を行うこととを実行する。
第１ユーザの第１アカウントと、前記第１アカウントに関連付けられた第２アカウントとに基づき決済に関する処理を行うサーバであって、
前記第２アカウントに設定された第２金額に基づく前記第２アカウントの残高に関する情報を前記第１ユーザの端末に送信する通信部と、
前記第１アカウントと、前記第２金額が設定された前記第２アカウントとに基づき、前記第１アカウントによる第１決済に関する処理を行う制御部とを備える。