JP7460686B2 - プログラム、情報処理方法、サーバ - Google Patents

プログラム、情報処理方法、サーバ Download PDF

Info

Publication number
JP7460686B2
JP7460686B2 JP2022093045A JP2022093045A JP7460686B2 JP 7460686 B2 JP7460686 B2 JP 7460686B2 JP 2022093045 A JP2022093045 A JP 2022093045A JP 2022093045 A JP2022093045 A JP 2022093045A JP 7460686 B2 JP7460686 B2 JP 7460686B2
Authority
JP
Japan
Prior art keywords
payment
terminal
account
user
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2022093045A
Other languages
English (en)
Other versions
JP2022111282A5 (ja
JP2022111282A (ja
Inventor
泰東 金
世栄 千
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to JP2022093045A priority Critical patent/JP7460686B2/ja
Publication of JP2022111282A publication Critical patent/JP2022111282A/ja
Publication of JP2022111282A5 publication Critical patent/JP2022111282A5/ja
Application granted granted Critical
Publication of JP7460686B2 publication Critical patent/JP7460686B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本開示は、プログラム、情報処理方法、端末に関する。
昨今、スマートフォン等の端末で実行可能なアプリケーションによって、端末、または端末のユーザの電子決済を実現するサービスが普及しつつある。例えば特許文献１には、商品の購買金額の決済を行う技術が開示されている。
特開２００２－１７６６７１号公報
本発明の第１の態様によると、決済に関する処理を実行する端末に実行させるためのプログラムは、端末のユーザが決済可能な第１アカウントに基づいて第１決済に関する処理を端末の制御部によって実行することと、第１決済の金額と、第１アカウントの残高とに基づく、第１アカウントの残高が不足していることに関する第１情報を端末の表示領域に表示することと、第１情報が表示された表示領域に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を制御部によって実行することとが端末によって実行される。
本発明の第２の態様によると、決済に関する処理を実行する端末の情報処理方法は、端末のユーザが決済可能な第１アカウントに基づいて第１決済に関する処理を端末の制御部によって実行することと、第１決済の金額と、第１アカウントの残高とに基づき、第１アカウントの残高が不足していることに関する第１情報を端末の表示領域に表示することと、第１情報が表示された表示領域に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を制御部によって実行することとを含む。
本発明の第３の態様によると、決済に関する処理を実行する端末は、端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理を実行する制御部と、第１決済の金額と、第１アカウントの残高とに基づき、第１アカウントの残高が不足していることに関する第１情報を表示する表示部とを備え、制御部は、端末のユーザによる第１情報が表示された表示部に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を実行する。
本発明の第４の態様によると、決済に関する処理を実行する端末は、メモリに記憶されたプログラムを読み出し、プログラムに基づく処理を実行するプロセッサを備え、プロセッサは、端末のユーザが決済可能な第１アカウントに基づいて第１決済に関する処理を端末の制御部によって実行することと、第１決済の金額と、第１アカウントの残高とに基づき、第１アカウントの残高が不足していることに関する第１情報を端末の表示領域に表示することと、第１情報が表示された表示領域に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を制御部によって実行することとを実行する。
本発明の第５の態様によると、端末と通信し、決済に関する処理を実行するサーバに実行させるためのプログラムは、端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理をサーバの制御部によって実行することと、第１決済の金額と、第１アカウントの残高とに基づき、第１アカウントの残高が不足していることに関する第１情報を端末にサーバの通信部によって送信することと、端末のユーザによる、端末の表示領域に表示された第１情報に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を制御部によって実行することとがサーバによって実行される。
実施形態の一態様における通信システムのシステム構成の一例を示す図。 実施形態の一態様に係る店舗ＰＯＳシステムのシステム構成の一例を示す図。 第１実施例に係るサーバの制御部によって実現される機能の一例を示す図。 第１実施例に係るサーバの記憶部に記憶される情報の一例を示す図。 第１実施例に係る支払いアプリケーションユーザ登録データの一例を示す図。 第１実施例に係るユーザ管理データベースのデータ構成の一例を示す図。 第１実施例に係る共通ウォレット管理データベースの一例である第１の共通ウォレット管理データベースのデータ構成例を示す図。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第１実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る端末の表示部に表示される画面の一例を示す図。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第２変形例に係る端末の表示部に表示される画面の一例を示す図。 第２変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第２変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係る端末の表示部に表示されるアプリケーション画面の一例を示す図。 第３実施例に係る端末の表示部に表示される共通ウォレット選択画面の一例を示す図。 第３実施例に係る端末の表示部に表示されるキャンプ資金支払い画面の一例を示す図。 第３実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第３実施例に係る端末の表示部に表示される送金用画面の一例を示す図。 第３実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第３実施例に係る端末の表示部に表示されるコード支払い完了画面の一例を示す図。 第３実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３実施例に係る端末の表示部に表示されるコードリーダ画面の一例を示す図。 第３変形例に係る端末の表示部に表示される読み取り完了画面の一例を示す図。 第３変形例に係る端末の表示部に表示される支払い金額入力画面の一例を示す図。 第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第３変形例に係る端末の表示部に表示されるチャージ画面の一例を示す図。 第３変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第３変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第３変形例に係る端末の表示部に表示されるメンバー選択画面の一例を示す図。 第３変形例に係るサーバの構成の一例を示す図。 第３変形例に係る端末の表示部に表示されるメンバー選択画面（トークルーム選択画面）の一例を示す図。 第４実施例に係る端末の表示部に表示される共通ウォレット残高不足画面の一例を示す図。 第４実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第４実施例に係る端末の表示部に表示されるコード支払い完了画面の一例を示す図。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る端末の表示部に表示される共通ウォレット残高不足画面の一例を示す図。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第４変形例に係る端末の表示部に表示される共通ウォレット残高不足画面の一例を示す図。 第４変形例に係る端末の表示部に表示される自分のウォレット残高不足画面の一例を示す図。 第４変形例に係る端末の表示部に表示されるコード支払い完了画面の一例を示す図。 第４変形例に係る端末の表示部に表示されるおしらせ画面の一例を示す図。 第４変形例に係る端末の表示部に表示される支払い履歴画面の一例を示す図。 第４変形例に係る端末の表示部に表示されるトークルーム画面の一例を示す図。 第４変形例に係る端末の表示部に表示されるトークルーム画面の一例を示す図。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第４変形例に係る店舗コードリーダ装置の構成の一例を示す図。 第５実施例に係るサーバの記憶部に記憶される情報の一例を示す図。 第５実施例に係る統合アカウント管理データベースのデータ構成の一例を示す図。 第５実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５実施例に係る端末の表示部に表示されるコード情報更新中画面の一例を示す図。 第５実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る端末の表示部に表示されるコードリーダ画面の一例を示す図。 第５変形例に係る端末の表示部に表示される支払いコード情報更新中画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコードリーダ画面の一例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る端末の表示部に表示されるコード支払い画面の別例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるおしらせ画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード情報更新画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の別例を示す図。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード情報更新画面の一例を示す図。 第５変形例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第６実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第６変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第７変形例に係る各装置が実行する処理の流れの一例を示すフローチャート。 第８実施例に係る共通ウォレット管理データベースの一例である第２の共通ウォレット管理データベースのデータ構成例を示す図。 第８変形例に係る共通ウォレット管理データベースの一例である第３の共通ウォレット管理データベースのデータ構成例を示す図。 第８変形例に係る端末の表示部に表示されるサマリー表示画面の一例を示す図。 第８変形例に係る端末の表示部に表示されるサマリー表示画面の一例を示す図。 第８変形例に係る端末の表示部に表示されるサマリー表示画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるトークルーム選択画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるコード支払い画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるコード支払い完了画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるトークルーム画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるトークルーム画面の一例を示す図。 第９実施例に係る端末の表示部に表示されるトークルーム画面の一例を示す図。 第１０実施例に係る第１アカウントと第２アカウントとの組み合わせを説明するためのテーブルの一例を示す図。
＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係るプログラム、情報処理方法、表示方法、端末、サーバ等を実施するための実施形態について、図面を参照して説明する。
＜概要＞
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子貨幣による支払い・決済を行うためのアプリケーション（支払いアプリケーション・決済アプリケーション）、電子貨幣による送金／受取を行うためのアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末２０、または端末２０のユーザが所有する電子的な貨幣を意味する。
なお、電子貨幣は、「電子マネー」や「デジタル通貨（デジタル貨幣）」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣（電子マネー）」や「デジタル通貨（デジタル貨幣）」には、暗号通貨（暗号資産）を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
本明細書では、適宜「通信Ｉ／Ｆによって」という表現を使用する。これは、装置が、限定ではなく例として、制御部（プロセッサー等）の制御に基づいて、通信Ｉ／Ｆを介して（通信部を介して）、各種の情報やデータを送受信することを示す。
また、本明細書において、「決済」とは電子的な決済（電子決済）のことを意味する。この一例は、電子貨幣を利用した電子決済である。
また、本明細書において、「決済に関する処理」とは、限定ではなく例として、端末２０が実行する決済に関する処理であって、決済を行うためのコード情報をサーバ等から取得する処理（コード情報の生成をサーバ等に依頼する処理や、生成されたコード情報をサーバ等から受信する処理を含む。）、取得したコード情報を表示する処理、決済結果（決済通知を含む。）をサーバ等から取得する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理として端末２０で実行される処理全般を含むものである。
また、本明細書において、「コード情報」とは、コード画像や、エンコード等によってコード画像に格納されている情報（格納情報）、または格納される対象となる情報（格納対象情報）を含むものである。格納情報や格納対象情報には、限定ではなく例として、詳細後述するトークンが含まれる。
また、本明細書では、コード（コード情報）を利用した支払い方法・決済方法であるコード決済として、限定ではなく例として、
（１）利用者提示型
（２）店舗提示型
の２種類を例示する。
利用者提示型とは、限定ではなく例として、端末２０の表示部２４に表示される支払いコードを利用者（端末２０のユーザ）が店舗（限定ではなく例として加盟店）の店員等に提示し、店舗コードリーダ装置５０のコードリーダ５８で読み取ってもらうことで決済を行う方法である。
店舗提示型とは、限定ではなく例として、店舗（限定ではなく例として加盟店）で提示または掲示される支払い店舗コードを利用者が端末２０のカメラ２７やコードリーダ（支払いアプリケーションのコードリーダを含む。）で読み取って決済を行う方法である。
なお、以下では、利用者提示型で端末２０の表示部２４に表示されるコードを「支払いコード」と称するが、これに代えて「利用者提示型コード」等のように称してもよい。
また、以下では、店舗提示型で端末２０が読み取るコードを「支払い店舗コード」と称するが、これに代えて「店舗提示型コード」等のように称してもよい。
また、本明細書では、アカウントに基づく決済として、限定ではなく例として、
（Ａ）共通アカウント決済
（Ｂ）アカウント連携決済
の２種類を例示する。
「アカウント」とは、限定ではなく例として、電子貨幣による支払い・決済を行うためのアプリケーション（支払いアプリケーション・決済アプリケーション）のアカウントである。
共通アカウント決済は、複数のユーザが共通に使用可能なアカウント（以下、「共通アカウント」と称する。）に基づいて決済を行う手法である。この決済を「共通アカウント決済」と称する。共通アカウント決済は、共通ウォレットを利用することによって実現される。「共通ウォレット」は、複数のユーザによって設定される電子マネー口座の一形態であり、仮想的な１つのウォレットが構成されるものである。
共通アカウント決済は、ユーザが、複数のユーザに共通のアカウント（１つの共通のアカウント）を用いる決済と捉えることもできる。
なお、共通アカウント決済は、共通ウォレット決済と表現してもよい。
アカウント連携決済は、複数のアカウントを連携させて決済を行う手法である。アカウントの連携とは、複数のアカウントが決済に用いられるように関連付けることであり、アカウントを連携させることを「アカウント連携」と称し、アカウント連携を利用した決済を「アカウント連携決済」と称する。
この場合、１人のユーザの複数のアカウントを連携させてもよいし、複数のユーザのアカウントを連携させてもよい。つまり、必ずしも他人のアカウントが連携に必須なわけではなく、限定ではなく例として、自分の複数のアカウントを連携させることも可能である。
アカウント連携決済を実現するために、限定ではなく例として、複数のアカウントを関連付けた上で、限定ではなく例として、関連付けられた各々のアカウントから均等割りで決済が行われるように設定する処理（アカウント連携処理）を実行する。
アカウント連携決済は、ユーザが、自分のアカウントの他、異なるアカウント（自分の別のアカウントまたは他人のアカウント）を用いる決済と捉えることもできる。
なお、アカウント連携は、ウォレット連携と表現してもよい。また、アカウント連携決済は、ウォレット連携決済と表現してもよい。
以下では、あくまでも一例として、友達同士や仲間同士など、複数のユーザがみんなで買い物などの支払いの決済を行う場合を想定した実施例について説明する。
共通アカウント決済は、基本的には複数のユーザで共通に使用することを想定した１つのアカウントから決済を行うものであるが、以下説明する実施例では、共通アカウントと、共通アカウントとは異なるアカウントとに基づいて決済を行う手法についても説明する。
また、アカウント連携は、限定ではなく例として、（Ｂ－１）支払いを行う前、（Ｂ－２）支払いを行う際のいずれかに行うようにすることができる。
（Ｂ－１）支払いを行う前は、限定ではなく例として、事後的な精算（限定ではなく例として割り勘による精算）が面倒な場合に適用することができる。
（Ｂ－２）支払いを行う際は、限定ではなく例として、支払いの際に決済を行うアカウントして設定されているアカウント（限定ではなく例として自分のアカウント）の残高が不足している場合に適用することができる。この場合、限定ではなく例として、他のユーザのアカウントとアカウント連携して決済を行うようにすることができる。
共通アカウント決済では、複数のユーザに共通のアカウントを用いるため、詳細は後述するが、一のユーザが他のユーザの支払い分を立て替えて決済を行ったような場合に、事後的な精算（清算）の処理が必要となる場合がある。つまり、決済が完了した後の何らかのタイミングで、送金処理／受金処理等の各々のユーザの金額を調整する処理が必要となる場合がある。
それに対し、アカウント連携決済では、連携するアカウントのユーザの許可を得ておく、またはその場で許可を得た上で、各々のアカウントから金額が消費されるようにすることで、事後的な精算の処理は基本的に不要となる。
以上を踏まえた上で、「共通アカウント決済」と「アカウント連携決済」とのそれぞれの実施例について説明する。
なお、「連携」は、１つの目的のために一緒に物事を行うという意味を含む。このため、複数のユーザが一緒に決済を行うという意味において、共通アカウント決済もアカウント連携決済も、目的は同じであるとも言える。
＜システム構成＞
図１－１は、本実施例における通信システム１のシステム構成の一例を示す図である。
通信システム１では、限定ではなく例として、ネットワーク３０を介して、サーバ１０と、複数の端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、複数の店舗ＰＯＳシステム４０（店舗ＰＯＳシステム４０Ａ，店舗ＰＯＳシステム４０Ｂ，店舗ＰＯＳシステム４０Ｃ，・・・）とが接続される。
サーバ１０は、ネットワーク３０を介して、ユーザが所有する端末２０に支払いサービスを提供する機能を有する。サーバ１０は、支払いサービスサーバや、支払い管理サーバ、決済サービスサーバ、決済管理サーバ等のように表現することもできる。
なお、ネットワーク３０に接続されるサーバ１０の数や端末２０の数は限定されない。
ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０と、１以上の店舗ＰＯＳシステム４０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定ではなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
サーバ１０（限定ではなく、サーバ、情報処理装置、情報管理装置の一例）は、端末２０に対して、所定のサービス（本実施例では支払いサービス）を提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定ではなく例として、サーバ装置、コンピュータ（限定ではなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定ではなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
図１－１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７、時計部２９Ａ、位置算出用情報検出部２９Ｂを備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部２９Ａは、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９Ａは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９Ａは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部２９Ａは、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部２９Ｂは、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置算出用情報検出部２９Ｂは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部２９Ｂは、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
制御部２１は、限定ではなく例として、位置算出用情報検出部２９Ｂによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末２０の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。そして、制御部２１は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部２８に記憶させる。
制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク２５は、音声データの入力に利用される。スピーカ２６は、音声データの出力に利用される。カメラ２７は、動画像データの取得に利用される。
（２）サーバのＨＷ構成
図１－１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３、時計部１９を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。
制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定ではなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。
ディスプレイ１３は、代表的にはモニタ（限定ではなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイ１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ１３は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ１３は、これらに限定されない。
時計部１９は、サーバ１０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部１９は、限定ではなく例として、ハードウェアクロックとしてのＲＴＣ（Real Time Clock）やシステムクロック等を有して構成される。時計部１９は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
（３）店舗ＰＯＳのシステム構成
図１－２には、店舗ＰＯＳシステム４０のシステム構成の一例を示している。
店舗ＰＯＳシステム４０は、サーバ１０を運用する事業者と提携している店舗に導入されて使用されるＰＯＳシステムであり、限定ではなく例として、店舗コードリーダ装置５０と、コードレジ６０と、店舗サーバ７０とを含む。
店舗コードリーダ装置５０は、ＰＯＳ通信Ｉ／Ｆ５７（限定ではなく例として、店舗内の有線通信Ｉ／Ｆや無線通信Ｉ／Ｆ）によってコードレジ６０や店舗サーバ７０と通信接続され、コードレジ６０での会計の際に、端末２０の表示部２４に表示されるコード情報を読み取る。そして、読み取ったコード情報に基づいて、決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信し、サーバ１０で決済が行われた後、決済結果に関する情報を通信Ｉ／Ｆ５４によってサーバ１０から受信する。
店舗コードリーダ装置５０は、限定ではなく例として、制御部５１と、入出力部５２と、表示部５３と、通信Ｉ／Ｆ５４と、記憶部５５と、音出力部５６と、ＰＯＳ通信Ｉ／Ｆ５７と、コードリーダ５８、時計部５９とを有する。
コードリーダ５８は、一次元コード（一次元コード画像）や二次元コード（二次元コード画像）、限定ではなく例として、後述する支払いコード（支払いコード画像）を読み取るためのコードリーダである。
コードレジ６０は、限定ではなく例として、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０や店舗サーバ７０と通信接続され、店舗コードリーダ装置５０がサーバ１０から受信した決済完了通知等に基づいて、販売した商品の総額や、端末２０のユーザの電子貨幣の残高等の情報を印字したレシートを発行する。
また、限定ではなく例として、コードレジ６０と一体として、またはコードレジ６０と別体として設けられ、客側に表示面が向けられたディスプレイを構成することもできる。
コードレジ６０は、支払いアプリケーションに対応可能に構成されたレジであり、支払いアプリケーション対応の据置端末と言うこともできる。
店舗サーバ７０は、限定ではなく例として、自店舗に関する店舗情報や、自店舗で販売される商品に関する情報や自店舗で提供されるサービスに関する情報、自店舗での商品の販売やサービスの提供に伴う売上げに関する情報等の各種の情報を管理する。店舗サーバ７０は、ＰＯＳ通信Ｉ／Ｆ５７によって店舗コードリーダ装置５０やコードレジ６０と通信可能に構成されているとともに、ネットワーク３０を介してサーバ１０等の外部装置と通信可能に構成されている。
なお、店舗サーバ７０は、必ずしも店舗コードリーダ装置５０と直接的に通信可能に構成されている必要はなく、コードレジ６０を介して店舗コードリーダ装置５０と通信可能に構成されていてもよい。限定ではなく例として、店舗コードリーダ装置５０がサーバ１０から受信した決済完了通知等はコードレジ６０に送られ、その後、コードレジ６０から店舗サーバ７０に送られるようにするなどすることもできる。
（４）その他
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
他の装置についても同様である。
なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
他の装置についても同様である。
また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
他の装置についても同様である。
また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。
＜第１実施例＞
最初に、前述した「（Ａ）共通アカウント決済」の実施例について説明する。
まず、共通アカウント決済の基本的な実施例（第１実施例）として、端末２０が、支払いアプリケーションを利用して、サーバ１０を介して支払いアプリケーションによる支払いが可能な店舗での支払いを、共通ウォレットの残高（共通ウォレットの電子マネーの残高、以下、「共通ウォレット残高」と称する。）から行う実施例について説明する。
以下では、支払いアプリケーションによる支払いサービスを提供する事業者のことを「支払いサービスの事業者」と称する。
なお、支払いサービスの事業者は、支払いアプリケーションを提供する事業者や、サーバ１０の事業者と表現することもできる。
また、決済サービスを提供する事業者という意味で、決済サービスの事業者と表現することもできる。
また、以下では、支払いサービスの事業者と提携し、店舗で提供される物販・サービスに対する支払いにおいて支払いアプリケーションを用いる支払いサービスが利用可能な店舗を「加盟店」と称する。
また、以下では、支払いサービスの事業者によって、サーバ１０が運用・管理されることとして説明する。また、以下では、支払いアプリケーションの名称を、適宜「Ｐａｙｍｅｎｔ Ａｐｐ」と称して図示・説明する。
また、支払いアプリケーションは、いわゆるメッセージングサービス（ＭＳ：Messaging Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＭＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。
コンテンツには、単純なテキストや絵文字等を含むメッセージの他、限定ではなく例として、画像情報（静止画像、動画像等を含む。）、操作用情報（ボタン、アイコン等を含む。）、通信用情報・リンク情報（ＵＲＩ、ＵＲＬ等を含む。）など、端末２０間で送受信可能な各種の情報を含めることができる。
また、支払いアプリケーションは、いわゆるソーシャルネットワーキングサービス（ＳＮＳ：Social Networking Service）の機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、ＳＮＳの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。
なお、メッセージングサービス：ＭＳ（ＩＭＳを含む。）は、ソーシャルネットワーキングサービス：ＳＮＳの１つの形態（一形態）と考えることもできる。
このため、ＭＳとＳＮＳとは区別してもよいし、区別しなくてもよい。
＜機能構成＞
図１－３は、本実施例においてサーバ１０の制御部１１によって実現される機能の一例を示す図である。
制御部１１は、限定ではなく例として、記憶部１５に記憶された支払いアプリケーション管理処理プログラム１５１に従って支払いアプリケーション管理処理を実行するための支払いアプリケーション管理処理部１１１を機能部として含む。
図１－４は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム１５１と、支払いアプリケーションユーザ登録データ１５３と、ユーザ管理データベース１５５と、共通ウォレット管理データベース１５７とが記憶される。
支払いアプリケーションユーザ登録データ１５３は、支払いアプリケーションを利用する端末２０、またはその端末２０のユーザに関する登録データであり、そのデータ構成の一例を図１－５に示す。
支払いアプリケーションユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、支払いアプリケーションＩＤと、端末電話番号と、その他登録情報とが関連付けて記憶される。
ユーザ名は、支払いアプリケーションを利用する端末２０のユーザの名称であり、限定ではなく例として、端末２０のユーザが支払いアプリケーションを利用する際に登録する名称が記憶される。
支払いアプリケーションＩＤは、支払いアプリケーションのアカウント（アカウント情報）であって、端末２０、または端末２０のユーザを識別可能とするＩＤである。この支払いアプリケーションＩＤは、限定ではなく例として、サーバ１０によって固有のＩＤが設定されて記憶される。
端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、限定ではなく例として、端末２０のユーザが支払いアプリケーションを利用する際に登録する端末２０の電話番号が記憶される。
その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末２０のメールアドレス（端末メールアドレス）、支払いアプリケーションにおける各種の認証に利用される認証パスワード等の認証情報、このユーザが使用するアイコンの画像データ（アイコン画像）、ユーザのプロフィール（ユーザプロフィール）等を含めるようにすることができる。
ただし、これらの情報は必須ではない。
ユーザ管理データベース１５５は、支払いアプリケーションユーザ登録データ１５３に記憶されたアカウント（アカウント情報）に基づくユーザの管理用のデータベースであり、そのデータ構成の一例を図１－６に示す。
ユーザ管理データベース１５５には、支払いアプリケーションユーザ登録データ１５３に記憶された支払いアプリケーションＩＤごとの管理データとして、ユーザ管理データが記憶される。
各々のユーザ管理データには、限定ではなく例として、支払いアプリケーションＩＤと、電子マネー口座残高とが記憶される。
ここで、共通ウォレット管理データベース１５７を参照しながら共通ウォレットについて詳細に説明する。
共通ウォレットとは、支払いアプリケーションを利用する複数のユーザによって、支払いを行う前にあらかじめ設定される電子マネー口座の一形態である。
共通ウォレットでは、設定される複数のユーザがその残高を利用して支払いを行うことが可能である。以下では、共通ウォレットを利用可能なユーザを「共通ウォレットメンバー」と称する。
共通ウォレットを利用するためには、まずユーザが共通ウォレットを生成するための操作を行う。この生成においては、限定ではなく例として、共通ウォレットメンバーの電子マネー口座を特定する情報（限定ではなく例として、支払いアプリケーションＩＤ）を必要とする。
共通ウォレット管理データベース１５７は、サーバ１０が共通ウォレットを管理するためのデータベースであり、その一例である第１の共通ウォレット管理データベース１５７Ａのデータ構成例を図１－７に示す。
第１の共通ウォレット管理データベース１５７Ａには、共通ウォレットをユニークに識別するための共通ウォレットＩＤごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤとが関連付けて記憶される。
共通ウォレットＩＤは、支払いアプリケーションにおける共通ウォレットのアカウント（以下、適宜「共通アカウント」と称する。）である。
共通ウォレット名は、共通ウォレットＩＤで識別される共通ウォレットの名称である。
共通ウォレット残高は、共通ウォレットＩＤで識別される共通ウォレットを利用して支払いを行う際に用いられる電子マネーの残高である。
共通ウォレットメンバーＩＤは、共通ウォレットの生成時に指定される、共通ウォレットメンバーの支払いアプリケーションＩＤである。
なお、共通ウォレットの生成後に共通ウォレットメンバーＩＤに支払いアプリケーションＩＤを追加することで、新たな共通ウォレットメンバーを追加することも可能である。また、同一のユーザが保有する複数の支払いアプリケーションＩＤを共通ウォレットメンバーＩＤに記憶してもよいし、そうしなくてもよい。
共通ウォレットが生成される場合、その共通ウォレット残高は「０」である。支払いを行う前に、共通ウォレットメンバーは、各々の電子マネー口座から電子マネーを共通ウォレットに送金し、共通ウォレット残高を増加させる。
なお、共通ウォレットメンバーは、支払いサービスに登録する外部金融機関の口座（限定ではなく例として、銀行口座）から、共通ウォレットへチャージする（電子マネーへ変換して送金する）ことも可能である。
共通ウォレットが不要となる場合には、存在する共通ウォレットを取り消すための共通ウォレット破棄操作を行う。共通ウォレット破棄操作が実行されると、共通ウォレット残高を共通ウォレットメンバーの人数で割り勘（均等割り）した額が、共通ウォレットメンバーの各々の電子マネー口座へと送金される。そして、共通ウォレット残高が「０」となった後、第１の共通ウォレット管理データベース１５７Ａからその共通ウォレット管理データのレコードが削除される。
＜処理＞
（１）利用者提示型のコード決済
図１－８～図１－９は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
一例として、ユーザＡ．Ａの端末２０（端末Ａ）と、ユーザＢ．Ｂの端末２０（端末Ｂ）とにより利用可能な電子マネー口座を共通ウォレットとして説明する。実際には、共通ウォレットを用いて支払い可能な端末は２つとは限らないが、端末Ｂと同様の処理となるため、本明細書では図示を省略する。
なお、この処理は、本開示の手法を実現するための処理の一例に過ぎず、この処理に限定されるものではない。この処理に、別のステップを追加してもよいし、一部のステップを省略（削除）してもよい。
これは、以下説明する各フローチャート（処理）について同様である。
また、各装置が実行する処理の通し番号については、図面には記載するが、明細書では記載を省略する。以降の実施例についても同様である。
まず、端末Ａの制御部２１は、共通ウォレット作成／選択情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１００）。
具体的には、端末Ａから利用可能な共通ウォレットを選択する情報（限定ではなく例として、共通ウォレットＩＤ）を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。選択可能な共通ウォレットＩＤは、本ステップにおいて、通信Ｉ／Ｆ２２によってサーバ１０から受信してもよいし、記憶部２８にあらかじめ記憶されたものを呼び出してもよい。
また、端末Ａから利用可能な共通ウォレットが存在しない場合には、共通ウォレットを新規に作成するための情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。ここで、共通ウォレットを新規に作成するための情報には、限定ではなく例として、共通ウォレットを構成するメンバーのアカウント情報（限定ではなく例として、ユーザＡ．ＡとユーザＢ．Ｂの支払いアプリケーションＩＤ）や、共通ウォレットの名称、共通ウォレットへの初期送金額を含む。
通信Ｉ／Ｆ１４によって端末Ａから共通ウォレットを選択する情報、もしくは共通ウォレットを新規に作成するための情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレットＩＤ、もしくは新規に作成され、制御部１１によってユニークに（重複がないように）割り当てられる共通ウォレットＩＤに基づいて、ウォレットからの支払いを認可する支払いトークンを生成する。
以下では、共通ウォレットＩＤに紐付けられる共通ウォレット残高から支払いを認可する支払いトークンを「共通ウォレット支払いトークン」と称する。ここで、共通ウォレット支払いトークンは、限定ではなく例として、所定の桁数（限定ではなく例として１２桁）の整数値によって識別される。また、共通ウォレット支払いトークンは生成から所定の時間内（限定ではなく例として「５分」）に限り認可を行う、有効期限を持つトークンとしてもよいし、そうしなくてもよい。
共通ウォレット支払いトークンが生成されると、サーバ１０の制御部１１は、共通ウォレット支払いトークンを含むコード情報である共通ウォレットコード情報を生成する。共通ウォレットコード情報は、限定ではなく例として、共通ウォレット支払いトークンの識別子を一次元コード（バーコード等）や二次元コード（ＱＲコード等）としてエンコードした支払いコード（画像情報）を含む。
なお、共通ウォレット支払いトークンが有効期限を持つ場合、共通ウォレットコード情報は、その有効期限を含んでもよい。また、共通ウォレット支払いトークンが生成された共通ウォレットの名称を含んでもよい。
その後、サーバ１０の制御部１１は、共通ウォレットコード情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１００ａ）。
通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレットコード情報を受信すると、端末Ａの制御部２１は、受信した共通ウォレットコード情報を表示部２４に表示させる（Ａ１１０ａ）。具体的には、共通ウォレットコード情報として、限定ではなく例として、支払いコードを表示部２４に表示させる。
なお、共通ウォレットコード情報に共通ウォレット支払いトークンの識別子や有効期限を含む場合、端末Ａの制御部２１は、識別子や有効期限を表示させてもよいし、表示させなくてもよい。
また、支払いコードの表示中に共通ウォレット支払いトークンの有効期限が切れる場合、端末Ａの制御部２１は、共通ウォレット支払いトークンの再生成を要請する情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信してもよいし、そのようにしなくてもよい。
この場合、サーバ１０の制御部２１は、共通ウォレット支払いトークンと、共通ウォレットコード情報とを再生成し、共通ウォレットコード情報を通信Ｉ／Ｆ１４によって端末Ａに送信する。そして、通信Ｉ／Ｆ２２によってサーバ１０から再生成された共通ウォレットコード情報を受信すると、端末Ａの制御部２１は、支払いコードと、有効期限とを表示部２４に再表示させるようにすることができる。
次いで、サーバ１０の制御部１１は、共通ウォレット支払いトークンが生成された共通ウォレットに関する情報である共通ウォレット情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１１０）。共通ウォレット情報は、限定ではなく例として、共通ウォレット残高を含む。
通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレット情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレット情報を表示部２４に表示させる（Ａ１２０）。具体的には、共通ウォレット情報として、限定ではなく例として、共通ウォレット残高を表示部２４に加えて表示させる。
店舗コードリーダ装置５０の制御部５１は店舗決済処理を実行し、店舗コードリーダ装置５０の入出力部５２に対する操作に基づいて、所定の決済予定金額（限定ではなく例として「３，０００円」）が制御部５１へ入力される。そして、店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示される支払いコードを読み取る（Ｐ１４０）。この場合、表示部２４に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ５８の読み取り結果には、支払いトークンとして共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、支払いトークン（この場合には共通ウォレット支払いトークン）とを含む決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１５０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する（Ｓ１７０ａ）。
サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否と、決済処理後の共通ウォレット残高とを含む決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａと店舗コードリーダ装置５０とに送信し（Ｓ１８０ａ）、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信すると、端末Ａの制御部２１は、決済結果情報を表示部２４に表示させ（Ａ１８０）、処理を終了する。
また、通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信すると、店舗コードリーダ装置５０の制御部５１は、決済結果情報を表示部５３に表示させ（Ｐ１６０）、処理を終了する。
（２）店舗提示型のコード決済
以下では、「支払い店舗コード」を、限定ではなく例として、加盟店を識別するための加盟店識別情報（限定ではなく例として加盟店に固有に割り振られる店舗ＩＤ）を含むコード（一次元コードや二次元コード）として説明する。
なお、支払い店舗コードに、特定の決済予定金額（限定ではなく例として「５００円」）の情報を含ませてもよいし、そのようにしなくてもよい。
図１－１０～図１－１１は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
なお、既出のフローチャート（処理）と同一のステップについては同一の符号を付して再度の説明を省略する。
これは、以下説明する各々のフローチャート（処理）について同様である。
前述した処理と同様に、サーバ１０の制御部１１によって共通ウォレット支払いトークンが生成されると、サーバ１０の制御部１１は、共通ウォレット支払いトークンを含むコード読み取り用情報である共通ウォレットコードリーダ情報を生成する。そして、サーバ１０の制御部１１は、共通ウォレットコードリーダ情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１００ｂ）。
Ａ１００の後、通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレットコードリーダ情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレットコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示させる。また、端末Ａの制御部２１は、コードを読み取るためにカメラ２７を起動させる（Ａ１１０ｂ）。そして、端末Ａの制御部２１は、Ａ１２０に処理を移す。
Ａ１２０の後、端末Ａの制御部２１は、カメラ２７等を用いて支払い店舗コードを読み取るコード読み取り処理を実行する（Ａ１９０）。これにより、読み取った支払い店舗コードから店舗ＩＤが取得される。
その後、端末Ａの制御部２１は、限定ではなく例として、決済予定金額を入力させるための表示画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて決済予定金額が入力されると、制御部２１は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗ＩＤと、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２００）。そして、端末Ａの制御部２１は、Ａ１８０に処理を移す。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Ａにおける決済予定金額の入力は省略することが可能である。
Ｓ１１０の後、通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う店舗提示型の決済処理を実行する（Ｓ１７０ｂ）。
その後、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否および決済処理後の共通ウォレット残高を含む決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１８０ｂ）。そして、制御部１１は、処理を終了する。
＜第２実施例＞
第２実施例は、端末２０が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、共通ウォレット残高が不足していることに関する情報を表示する実施例である。
また、第２実施例は、共通ウォレット残高が不足している場合に、共通ウォレット（共通アカウント）に代えて、自己のウォレット（自分のユーザアカウント）から決済を行う実施例である。
第２実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面例＞
以下では、端末２０が、縦長のディスプレイの表示部２４を備えるスマートフォンである場合を例示する。
スマートフォンには、限定ではなく例として、入力部として機能するタッチパネルが、そのディスプレイと対向して配置される。アイコン、ボタン、アイテムまたは入力領域などの要素がディスプレイに表示された場合において、タッチパネルの一部の領域であって、その要素が表示された領域と対向する領域がユーザによってタッチされた場合、その要素と関連付けられたプログラムまたはそのプログラムのサブルーチンが実行される。以下では、ディスプレイにその要素が表示された領域と対向するタッチパネルの領域のことを、対向領域とも称する。つまり、対向領域は、受け付け手段として機能する。
図２－１は、端末２０で実行される支払いアプリケーションにおいて表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、支払いアプリケーションを起動する操作がユーザによってなされ、支払いアプリケーションが起動した場合に表示される画面の一例である。
このアプリケーション画面には、限定ではなく例として、支払いアプリケーションのアプリケーション名である「Ｐａｙｍｅｎｔ Ａｐｐ」が最上段のタイトルバーに表示され、その横に、ユーザＡ．Ａのアイコン画像と、ユーザ名「Ａ．Ａ」の文字とが表示されている。タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置が表示される。具体的には、限定ではなく例として、現在実行中の最上位のメニューである「ウォレット メインメニュー」が表示されている。その下には、自分（ユーザＡ．Ａ）の電子マネー口座残高を表示するための電子マネー口座残高表示領域（以下、単に「残高表示領域」と称する。）２４１が設けられている。
この例では、残高表示領域２４１には、「Ｐａｙｍｅｎｔ Ａｐｐ」で管理されるユーザＡ．Ａの電子マネー口座残高として「２５，０００円」が表示され、その横に、金額をチャージするためのチャージボタン２４１Ａが表示されている。また、その下には、「ウォレット メインメニュー」から選択可能なサブメニューとして、支払いアプリケーションの各種の機能に対応する複数のアイコンが表示されるアイコン表示領域が設けられている。この例では、アイコン表示領域には、「送金」、「コード支払い」、「コードリーダ」、「クーポン」、「ポイント」および「共通ウォレット」にそれぞれ対応する６つのアイコンが表示されている。以下では、「共通ウォレット」に対応するアイコンを、共通ウォレットアイコンＣＮ１として説明する。
図２－２は、図２－１のアプリケーション画面において共通ウォレットアイコンＣＮ１がタッチ操作された場合に表示される共通ウォレット選択画面の一例を示す図である。
この例では、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「共通ウォレット」が表示されている。
その下には、ユーザに対する操作案内として「共通ウォレットを選択してください」の説明文が表示され、その説明文の下には、複数の共通ウォレットの表示領域が設けられている。この例では、キャンプ資金用の共通ウォレット表示領域であるキャンプ資金表示領域２４２と、韓国旅行用の共通ウォレット表示領域である韓国旅行表示領域２４３とが表示されている。また、その下には、共通ウォレットを新規追加・登録するためのユーザ操作可能な新規登録操作領域２４４が設けられている。
キャンプ資金表示領域２４２には、上段に、共通ウォレットであることを示す「角財布」の画像とともに、その共通ウォレットの名称（この例では「キャンプ資金」）が表示されている。また、その横には、各種設定アイコンが表示されている。
また、下段には、このキャンプ資金の共通ウォレット残高（ここでは「１，０００円」）が表示され、その横には、この共通ウォレットを共同で使用するユーザのアイコン画像およびユーザ名が表示される。この例では、ユーザＡ．ＡおよびユーザＢ．Ｂのアイコン画像およびユーザ名が表示されている。つまり、このキャンプ資金用の共通ウォレットは、ユーザＡ．ＡおよびユーザＢ．Ｂの２名からなる共通ウォレットと言える。
同様に、韓国旅行表示領域２４３には、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称（この例では「キャンプ資金」）が表示されている。また、その横には、各種設定アイコンが表示されている。
また下段には、残高（この例では「９０，０００円」）が表示され、その横には、この共通ウォレットを共同で使用するユーザのアイコン画像およびユーザ名が表示される。この例では、ユーザＡ．Ａ、ユーザＤ．ＤおよびユーザＥ．Ｅのアイコンが表示されている。つまり、この韓国旅行用の共通ウォレットは、ユーザＡ．Ａ、ユーザＤ．ＤおよびユーザＥ．Ｅの３名からなる共通ウォレットと言える。
新規登録操作領域２４４には、「＋」マークが中央部に表示されており、共通ウォレットを新たに追加・登録するための操作領域であることをユーザが容易に認識できるように構成されている。この「＋」マークがタッチ操作されるに限らず、新規登録操作領域２４４内のいずれかの位置がタッチ操作されることで、共通ウォレットの新規作成・登録が可能となる。
図２－３は、図２－２の共通ウォレット選択画面においてキャンプ資金表示領域２４２内がタッチ操作された場合に表示されるキャンプ資金支払い画面の一例を示す図である。
この例では、タイトルバーの下に、上記階層メニューにおける現在位置として、現在実行中のサブメニューである「共通ウォレット：キャンプ資金」が表示されている。また、その下には、ユーザに対する操作案内として「メインメニュー」が表示され、その下には、キャンプ資金表示領域２４２が表示されている。キャンプ資金表示領域２４２の下には、「メインメニュー」から選択可能なサブメニューである「入金」、「コード支払い」、「コードリーダ」、「おしらせ」、「送金」および「ウォレット破棄」にそれぞれ対応する６つのアイコンが表示されている。
これらのアイコンのうち、「コード支払い」と示されたアイコンは、「利用者提示型」のコード決済を行う際に、サーバ１０から支払いコードを取得するための「コード支払いアイコン」である。また、「コードリーダ」と示されたアイコンは、「店舗提示型」のコード決済を行う際に、端末２０で端末読み取り用コードを読み取るために、コード支払いアプリケーションの機能として備えられたコードリーダ（以下、「アプリケーションコードリーダ」と称す。）を起動させるためのコードリーダアイコンである。
図２－４は、図２－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面の一例を示す図である。
この例では、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「コード支払い」が表示され、その下には、キャンプ資金コード支払い領域２４２１が表示されている。
キャンプ資金コード支払い領域２４２１には、上記と同様に角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。
その下には、端末２０のユーザのウォレット（電子マネー口座）であることを示す、がま口財布の画像とともに「自分のウォレット」の文字が表示され、その横に、その残高（電子マネー口座残高）（この例では「２５，０００円」）が表示されている。
また、その下には、サーバ１０から送信されて端末２０が受信したコード（コード画像）であって、共通ウォレットで決済を行うために用いられるコードである支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコードとが表示されている。
また、これらの支払いコードには、これらの支払いコードを利用して決済を行うことのできる期間（以下、「コード使用可能期間」と称する。）が定められており、この例では、支払いコードと関連付けて、コード使用可能期間の残り時間がカウントダウン形式で表示されている。コード使用可能期間は任意の期間とすることができるが、限定ではなく例として「５分間」の期間として定めておくことができる。
なお、コード使用可能期間を、端末２０において支払いコードが表示される期間（以下、「コード表示期間」と称する。）とし、コード表示期間が終了した場合に、表示中の支払いコードを非表示とするようにしてもよいし、そのようにしなくてもよい。
端末２０のユーザは、コード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置５０で支払いコードを読み取ってもらうことでコード支払いを行う。
図２－５は、図２－４のコード支払い画面の支払いコードが店舗コードリーダ装置５０で読み取られた結果、共通ウォレット残高が不足している場合に端末２０の表示部２４に表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下には、共通ウォレット残高不足情報表示・操作領域２４２７が、ポップアップ形式で表示されている。この例では、残高が不足していることを表す画像として「困った顔のロボット」の画像が表示され、その下に、残高不足メッセージとして「共通ウォレット残高不足です」が表示されている。
また、その下には、「支払いしようとする買い物」が文字で表示されており、この例では、ＡＡスポーツ株式会社のロゴ画像とともに、その会社名である「ＡＡスポーツ株式会社」の文字が表示されている。その横には、支払い金額として「３，０００円」の文字が表示され、その下には、内訳として、角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。
また、その下には、がま口財布の画像および自分のウォレットとともに、自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。さらに、その下には、決済残高不足額（＝決済予定金額－共通ウォレット残高）を自分のウォレットから支払うか否かをユーザに意思確認するための情報として「自分のウォレット残高から２，０００円を支払いますか？」という案内文が表示されている。この例では、支払い金額が「３，０００円」であるのに対し、共通ウォレット残高が「１，０００円」であるため、「２，０００円」不足していることになり、不足分の金額は「２，０００円」となる。
また、この例では、共通ウォレット残高不足情報表示・操作領域２４２７の下部に、自分のウォレット残高からの支払いを実行するための、限定ではなく例として「支払う」と示された支払い実行ボタン２４２Ｗと、自分のウォレット残高からの支払いを実行しないための、限定ではなく例として「支払わない」と示された支払い非実行ボタン２４２Ｘとが表示されている。
図２－６は、図２－５の共通ウォレット残高不足画面において支払い実行ボタン２４２Ｗがタッチ操作された後、サーバ１０による決済処理が完了した場合に端末２０の表示部２４に表示されるコード支払い完了画面の一例を示す図である。
このコード支払い完了画面では、現在位置として「キャンプ資金」が表示され、その下に、決済結果に関する情報が表示されている。具体的には、「コード支払い」の文字とともに、支払い完了メッセージとして「ＴＨａｎＫ ＹＯＵ！」の文字が表示され、その下に、感謝の気持ちを示す「笑顔で万歳するロボットの画像」が表示されている。さらに、その下には、支払い金額「３，０００円」とともに、「支払いが完了しました。」の文字が表示されている。
また、その下には、支払いの詳細情報として、支払い日は「２０２０年４月１１日」であり、その時刻は「１６時３０分」であることが表示されている。また、その下には、支払い先が「ＡＡスポーツ株式会社」であることが表示されている。
また、その下には、横線を介して、支払いの内訳が表示されている。この例では、キャンプ資金の共通ウォレットからの支払い金額が「１，０００円」であり、自分のウォレットからの支払い金額が「２，０００円」であることを示す情報が表示されている。
＜処理＞
図２－７～図２－８は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
Ｓ１１０の後、サーバ１０の制御部１１は、端末ＡのユーザであるユーザＡ．Ａの支払いアプリケーションＩＤに紐づけられるユーザアカウント情報（限定ではなく例として、電子マネー口座残高）を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１２０）。
Ａ１２０の後、通信Ｉ／Ｆ２２によってサーバ１０からユーザアカウント情報を受信すると、端末Ａの制御部２１は、受信されたユーザアカウント情報を表示部２４に表示させる（Ａ１３０）。具体的には、限定ではなく例として、端末ＡのユーザＡ．Ａの電子マネー口座残高を表示部２４に加えて表示させる。
店舗コードリーダ装置５０の制御部５１は店舗決済処理を実行し、店舗コードリーダ装置５０の入出力部５２に対する操作に基づいて、所定の決済予定金額（限定ではなく例として「３，０００円」）が制御部５１へ入力される。そして、店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示される支払いコードを読み取る（Ｐ１００）。この場合、表示部２４に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ５８の読み取り結果には、共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、共通ウォレット支払いトークンとを含む決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１１０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する（Ｓ２５０ａ）。
決済処理で決済が成功した場合（Ｓ２６０ａ：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１８０ｃに処理を進める。
一方、決済処理で決済が失敗した場合（Ｓ２６０ａ：ＮＯ）、サーバ１０の制御部１１は、限定ではなく例として、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信Ｉ／Ｆ１４によって端末Ａと店舗コードリーダ装置５０とに送信する（Ｓ２７０ａ）。
Ａ１３０の後、通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると（Ａ２７０ａ：ＹＥＳ）、端末Ａの制御部２１は、受信された決済残高不足情報を表示部２４に加えて表示させる（Ａ２８０）。また、端末Ａの制御部２１は、受信した決済残高不足情報に含まれる決済残高不足額を、記憶部２８に記憶させる（Ａ２９０）。
その後、限定ではなく例として、表示部２４に決済残高不足情報とともに表示されているユーザアカウント情報に対する操作入力（入出力部２３に対する操作入力）がなされたことに基づいて、端末Ａの制御部２１は、自分（ユーザＡ．Ａ）の電子マネー口座残高から不足分を支払って、共通ウォレット残高と自分の電子マネー口座残高とから決済を行うようにサーバ１０に要求する決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２９５）。
通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、決済処理を実行する（Ｓ１７０ｃ）。具体的には、限定ではなく例として、共通ウォレット残高を「０」まで減少させ、不足分をユーザＡ．Ａの電子マネー口座残高から差し引く。
その後、サーバ１０の制御部１１は、限定ではなく例として、図２－６の支払い完了画面に含まれる各種の情報を含む決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａと店舗コードリーダ装置５０とに送信し（Ｓ１８０ｃ）、処理を終了する。
一方、サーバ１０から決済残高不足情報を受信しなかった場合（Ａ２７０ａ：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０に処理を移す。
Ｐ１１０の後、通信Ｉ／Ｆ５４によってサーバ１０から決済残高不足情報を受信すると（Ｐ１２０：ＹＥＳ）、店舗コードリーダ装置５０の制御部５１は、決済残高不足情報を表示部５３に表示させる（Ｐ１３０）。そして、店舗コードリーダ装置５０の制御部５１は、サーバ１０から決済結果情報を受信した後、Ｐ１６０に処理を移す。
＜決済残高不足情報の表示＞
「決済残高不足情報が表示された」とは、「決済残高不足情報が表示された後」や「決済残高不足情報が一旦表示された場合」を意味し、必ずしも決済残高不足情報が現在も表示されていることを要するわけではない。
つまり、「決済残高不足情報が表示された表示部２４に対する入力」とは、
（１）決済残高不足情報が表示された後、決済残高不足情報が表示されている状態で表示部２４に対する入力がなされた場合
（２）決済残高不足情報が表示された後、決済残高不足情報が非表示とされ、その後に表示部２４に対する入力がなされた場合
を含む概念である。
これは、以下説明する実施例においても同様である。
＜端末に対する入力＞
上記の処理では、端末２０のユーザのユーザアカウント（電子マネー口座）から不足分を支払うか否かの選択を、端末２０の入出力部２３に対する操作入力に基づいて実現する例を示したが、これに限定されない。これを、端末２０のマイク２５に対する音入力（音声入力を含む。）等によって実現してもよいし、そのようにしなくてもよい。
これは、端末２０に対する各種の入力について同様である。
＜第２実施例の効果＞
第２実施例は、端末２０が、自己の端末２０のユーザが決済可能なアカウント（限定ではなく、第１アカウントの一例）に基づいて決済に関する処理を制御部２１によって実行する。また、端末２０は、決済残高不足情報（限定ではなく、第１決済の金額と、第１アカウントの残高とに基づく、第１アカウントの残高が不足していることに関する第１情報の一例）を表示部２４に表示する。そして、端末２０は、決済残高不足情報が表示された表示部２４に対する入力に基づいて、自己の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントとは異なる第２アカウントの一例）から不足分を支払って決済を行う処理（限定ではなく、第１決済に関する処理の一例）を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントの残高が不足していることを端末のユーザに知らせることができる。また、第１アカウントに基づいて決済を実現することができる他、第１アカウントとは異なる第２アカウントに少なくとも基づいて決済を実現することができる。
また、第２実施例は、自己の端末２０のユーザが決済可能なアカウントは、共通アカウント（限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントに基づいて決済を実現することができる。
＜第２変形例（１）＞
第２実施例では、利用者提示型のコード決済について説明したが、これに限定されない。
具体的には、限定ではなく例として、店舗提示型のコード決済を適用することもできる。
＜表示画面例＞
図２－９は、端末２０の表示部２４に表示されるコードリーダ画面の一例を示す図である。
図２－３のキャンプ資金支払い画面において「コード支払い」のアイコンではなく「コードリーダ」のアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合、限定ではなく例としてアプリケーションコードリーダが起動され、図２－９に示すような支払い店舗コードを読み取るためのコードリーダ画面が表示部２４に表示される。
このコードリーダ画面では、タイトルバーの下に「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。
また、その下には、コード読み取り領域ＣＲ１が表示され、その下にはユーザに対する操作案内として「コードリーダ」が表示され、その下にはキャンプ資金コード支払い領域２４２３が表示されている。
キャンプ資金コード支払い領域２４２３には、上部に、角財布の画像とともに「キャンプ資金」の文字が表示され、その横に、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。また、その下には、がま口財布の画像とともに「自分のウォレット」の文字が表示され、その横に、自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。
図２－１０は、図２－９のコードリーダ画面で支払い店舗コードが読み取られた場合に表示される読み取り完了画面の一例を示す図である。
コード読み取り領域ＣＲ１内には、読み取られた支払い店舗コードが表示されている。また、画面下部のキャンプ資金コード支払い領域２４２３には、図２－９と同様の情報が表示されている。
図２－１１は、図２－１０に続けて表示される支払い金額入力画面の一例を示す図である。読み取られた支払い店舗コードからデコードによって情報が取得されると、支払い金額を入力するための支払い金額入力画面が表示される。
この支払い金額入力画面には、ユーザに対する操作案内として「支払い金額の入力」が表示され、その下に、支払い金額の送金先である「ＡＡスポーツ株式会社」のアイコン画像とともに、その名称「ＡＡスポーツ株式会社」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域２４２４が表示されている。また、その下には、「お支払い金額（税込）を入力してください」の文字が表示され、その下に、支払いボタン２４２Ｃが表示されている。
また、画面下部には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額を消去するための消去ボタンＣＮ４が表示されている。
この例では、支払い金額として「３，０００円」が入力されて支払い金額表示領域２４２４に表示された状態が示されている。
図２－１２は、図２－１０の支払い金額入力画面において支払いボタン２４２Ｃがタッチ操作された後、共通ウォレット残高が不足していたことに基づいて表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面の構成は、図２－５と同様である。図２－５と異なるのは、共通ウォレット残高不足情報表示・操作領域２４２７の背景がコードリーダ画面である点である。
図２－１２の共通ウォレット残高不足画面で支払い実行ボタン２４２Ｗがタッチ操作され、サーバ１０による決済処理が完了すると、図２－６と同様のコード支払い完了画面が表示される。
＜処理＞
図２－１３～図２－１４は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
Ａ３００の後、端末Ａの制御部２１は、限定ではなく例として、決済予定金額を入力させるための表示画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて、決済予定金額が入力されると、端末Ａの制御部２１は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗ＩＤと、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３１０）。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Ａにおける決済予定金額の入力は省略することが可能である。
通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う店舗提示型の決済処理を実行する（Ｓ２５０ｂ）。
Ｓ２５０ｂにおいて決済が成功した場合には（Ｓ２６０ｂ：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１８０ｄに処理を移す。
Ｓ２５０ｂにおいて決済が失敗した場合（Ｓ２６０ｂ：ＮＯ）、サーバ１０の制御部１１は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ２７０ｂ）。
通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると（Ａ２７０ｂ：ＹＥＳ）、端末Ａの制御部２１は、決済残高不足情報を表示部２４に表示させ（Ａ２８０）、決済残高不足額を記憶部２８に記憶させる（Ａ２９０）。そして、端末Ａの制御部２１は、Ａ２９５に処理を移す。具体的には、端末Ａの制御部２１は、図２－８のＡ２９５と同様の趣旨の決済要求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。そして、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０に処理を移す。
通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、図２－８のＳ１７０ｃと同様の趣旨の店舗提示型の決済処理を実行する（Ｓ１７０ｄ）。そして、サーバ１０の制御部１１は、決済結果情報を通信Ｉ／Ｆ１４によって端末Ａに送信して（Ｓ１８０ｄ）、処理を終了する。
一方、サーバ１０から決済残高不足情報を受信しなかった場合（Ａ２７０ｂ：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０に処理を移す。
＜第２変形例（２）＞
第２実施例では、共通ウォレット残高が不足している場合に、端末２０のユーザのユーザアカウントから不足分を支払うこととしたが、これに限定されない。
具体的には、共通ウォレット残高が不足している場合に、共通ウォレット残高を使用せず、端末２０のユーザのユーザアカウントから全額を支払うようにしてもよいし、そのようにしなくてもよい。つまり、決済を行うアカウントを、共通アカウント（共通ウォレット）から端末２０のユーザのユーザアカウント（ユーザの電子マネー口座残高）に変更する（切り替える）ようにしてもよいし、そのようにしなくてもよい。
＜第３実施例＞
第３実施例は、自分のウォレットから共通ウォレットへの送金を実現する実施例である。
自分のウォレットから共通ウォレットへの送金を可能とすることで、限定ではなく例として、あらかじめ共通ウォレット残高を補充したり、支払いの際に共通ウォレット残高が不足している場合に共通ウォレット残高を補充したりすることが可能となる。
第３実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面例＞
端末２０の表示部２４に表示される表示画面例について説明する。
図３－１～図３－３の表示画面は、図２－１～図２－３の表示画面とそれぞれ同様である。
図３－４は、図３－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面（送金前）の一例を示す図である。
この例では、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「コード支払い」が表示され、その下には、キャンプ資金コード支払い領域２４２１が表示されている。
キャンプ資金コード支払い領域２４２１には、上記と同様に角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。
その下には、丸内にチェックマークを含むチェックマークボタンＣＮ２とともに、「自分のウォレットから送金」の文字が表示され、その横に残高（この例では、２５，０００円）が表示されている。チェックマークボタンＣＮ２がタッチ操作されると、自分のウォレットから共通ウォレットに送金するための送金用画面が表示される。
また、その下には、サーバ１０から送信されて端末２０が受信したコード（コード画像）であって、「利用者提示型」で決済を行うために用いられるコードである支払いコードとして、限定ではなく例としてバーコードで表される一次元の支払いコードと、限定ではなく例としてＱＲコード（登録商標）で表される二次元の支払いコードとが表示されている。
また、これらの支払いコードには、これらの支払いコードを利用して決済を行うことのできる期間（以下、「コード使用可能期間」と称する。）が定められており、この例では、支払いコードと関連付けて、コード使用可能期間の残り時間がカウントダウン形式で表示されている。コード使用可能期間は任意の期間とすることができるが、限定ではなく例として「５分間」の期間として定めておくことができる。
なお、コード使用可能期間を、端末２０において支払いコードが表示される期間（以下、「コード表示期間」と称する。）とし、コード表示期間が終了した場合に、表示中の支払いコードを非表示とするようにしてもよいし、そのようにしなくてもよい。
図３－５は、図３－４のコード支払い画面においてチェックマークボタンＣＮ２が端末２０のユーザＡ．Ａによってタッチ操作された場合に表示される送金用画面の一例を示す図である。
この例では、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「送金」が表示され、その下には、送金予定相手であるユーザＡ．Ａのアイコン画像およびユーザ名「Ａ．Ａ」が表示されている。
また、その下には、「送金額」の表示とともに、入力された送金予定金額を表示するための送金予定金額入力領域２４２２が表示されている。ここでは、送金予定金額として「５，０００円」が入力された状態が示されている。また、その下には、送金予定金額入力領域２４２２への加算金額入力用であり、ここでは、「１００円」を加算するための第１加算ボタンＢＴ１と、「１，０００円」を加算するための第２加算ボタンＢＴ２と、「１０，０００円」を加算するための第３加算ボタンＢＴ３とが横方向に並んで表示されている。
限定ではなく例として、送金予定金額として「５，０００円」が入力された状態で、第１加算ボタンＢＴ１が１回タッチ操作されると、送金予定金額入力領域２４２２内は「５，１００円」と表示され、続けて第２加算ボタンＢＴ２が１回タッチ操作されると「６，１００円」と表示され、続けて第３加算ボタンＢＴ３が１回タッチ操作されると「１６，１００円」と表示される。
また、この例では、送金予定金額入力領域２４２２内の左部には消去ボタンＣＮ３が表示されており、消去ボタンＣＮ３がタッチ操作されると、送金予定金額入力領域２４２２内の金額は消去され、送金予定金額入力領域２４２２内は「０円」と表示される。
また、この例では、第１加算ボタンＢＴ１の下には、ユーザＡ．Ａ自身のウォレット内での残高（ここでは「２５，０００円」）が表示される。
また、この例では、送金用画面下部には、送金予定金額入力領域２４２２内に入力された金額の送金を実行するための送金ボタン２４２Ａが表示されている。
なお、送金予定金額入力領域２４２２がタッチされると、表示部２４の下部に送金予定額を入力するためのテンキー領域が表示され、テンキー領域への入力に基づいて、送金予定額を細かく入力することも可能である。
図３－６は、図３－５の送金用画面において、送金ボタン２４２Ａがタッチ操作された場合に表示されるコード支払い画面（送金後）の一例を示す図である。
キャンプ資金コード支払い領域２４２１内は、図３－４と同様であるが、送金後であることから、各々残高の金額が異なるものとなっている。つまり、キャンプ資金の共通ウォレット残高として、送金額が加算された「６，０００円」が表示され、自分の電子マネー口座残高として、送金額が減算された「２０，０００円」が表示されている。また、送金が行われたことを示すチェックマークボタンＣＮ２が反転表示されている。
なお、この例では、支払いコードは、何れも図３－４のものと同じコードとなっている。
端末２０のユーザＡ．Ａは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。
図３－７は、サーバ１０によるコード支払いが完了した場合に端末２０に表示されるコード支払い完了画面の一例を示す図である。
このコード支払い完了画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下中央には、「コード支払い」が表示されている。
また、この例では、その下に、支払い完了メッセージとして「ＴＨａｎＫ ＹＯＵ！」の文字が表示され、その下に感謝の気持ちを示す「笑顔で万歳するロボットの画像」が表示され、さらにその下に支払い金額として「３，０００円」が大文字で表示され、その下に完了通知として「支払いが完了しました。」の文字が表示されている。
また、その下には、支払い完了情報として、支払い日は「２０２０年４月１１日」であり、その時刻は「１６時３０分」であることが示されている。また、その下に、支払い先は、ＡＡスポーツ株式会社であることが示されている。
また、コード支払い完了画面下部には、確認ボタン２４２Ｂが表示される。
＜処理＞
図３－８は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
なお、処理の後半については、限定ではなく例として図１－９と同一とすることができるため、ここでは説明を省略する。
Ａ１３０の後、端末Ａの制御部２１は、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金するか否かを選択させるための情報（限定ではなく例として、選択機能を持つボタン）を表示部２４に加えて表示させる。そして、端末Ａの制御部２１は、入出力部２３に対するユーザ操作に基づいて、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択されたか否かを判定する（Ａ１４０）。
共通ウォレットへ送金することが選択された場合（Ａ１４０：ＹＥＳ）、端末Ａの制御部２１は、限定ではなく例として、送金額の入力を促す画面（送金用画面）を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて送金額が入力されると、端末Ａの制御部２１は、送金額を含む送金依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ１５０）。
Ｓ１２０の後、通信Ｉ／Ｆ１４によって端末Ａから送金依頼情報を受信すると（Ｓ１３０：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金額を送金する送金処理を実行する（Ｓ１４０）。
そして、サーバ１０の制御部１１は、送金後の共通ウォレット残高を含む共通ウォレット情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１５０）。
通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレット情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を表示部２４に更新して表示させる（Ａ１６０）。
また、サーバ１０の制御部１１は、送金後のユーザＡ．Ａの電子マネー口座残高を含むユーザアカウント情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１６０）。そして、サーバ１０の制御部１１は、図１－９のＳ１７０ａに処理を移す。
通信Ｉ／Ｆ２２によってサーバ１０からユーザアカウント情報を受信すると、端末Ａの制御部２１は、受信されたユーザアカウント情報に基づき、限定ではなく例として、ユーザＡ．Ａの電子マネー口座残高を表示部２４に更新して表示させる（Ａ１７０）。そして、端末Ａの制御部２１は、図１－９のＡ１８０に処理を移す。
なお、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択されなかった場合（Ａ１４０：ＮＯ）、Ａ１５０～Ａ１７０のステップは実行されない。従って、サーバ１０の制御部１１は、送金依頼情報を受信せず（Ｓ１３０：ＮＯ）、Ｓ１４０～Ｓ１６０のステップも実行されない。
なお、前述したように、端末２０に対する入力は操作入力に限定されない。
上記の処理では、端末２０のユーザのユーザアカウント（電子マネー口座）から共通ウォレットへ送金するか否かの選択を、端末２０の入出力部２３に対する操作入力に基づいて実現する例を示したが、これに限定されない。これを、端末２０のマイク２５に対する音入力（音声入力を含む。）等によって実現してもよいし、そのようにしなくてもよい。
＜第３実施例の効果＞
第３実施例は、端末２０が、自己の端末２０のユーザが決済可能なアカウント（限定ではなく、第１アカウントの一例）が関連付けられた共通ウォレットコード情報（限定ではなく、第１コード情報の一例）と、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）に関するユーザアカウント情報（限定ではなく、第２アカウント情報の一例）とを表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる、そのユーザのユーザアカウントの電子マネー口座から共通ウォレットへ送金することを選択するための入力（操作入力、音入力等）（限定ではなく、第２アカウント情報に対する入力の一例）に基づいて、送金用画面を表示部２４に表示する処理、送金依頼情報をサーバ１０に送信する処理、更新された共通ウォレット残高をサーバ１０から受信する処理、受信された共通ウォレット残高を表示部２４に更新して表示させる処理、ユーザアカウントの電子マネー口座残高をサーバ１０から受信する処理、受信されたユーザアカウントの電子マネー口座残高を表示部２４に更新して表示させる処理、支払いコードを表示部２４に表示する処理、決済結果情報をサーバ１０から受信する処理、受信された決済結果情報を表示部２４に表示する処理等の、決済に関連する処理として端末２０で実行される処理（限定ではなく、第１アカウントと、第２アカウントとに基づく第１決済に関する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントが関連付けられた第１コード情報を端末の表示領域に表示して決済に利用させることができるとともに、第１アカウントとは異なる第２アカウントに関する第２アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する入力に基づいて、第１アカウントと第２アカウントとに基づく決済を実現することができる。
また、第３実施例は、上記の自己の端末２０のユーザが決済可能なアカウントは、少なくとも自己の端末２０のユーザ（一例としてユーザＡ．Ａ）（限定ではなく、端末のユーザの一例）と、異なる端末２０のユーザ（一例としてユーザＢ．Ｂ）（限定ではなく、端末のユーザとは異なる第１ユーザの一例）とが決済可能な共通アカウントである構成を示している。
このような構成により得られる効果の一例として、第１コード情報を端末の表示領域に表示して決済に利用させることができるとともに、共通アカウントとは異なる第２アカウントに関する第２アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する入力に基づいて、共通アカウントと第２アカウントとに基づく決済を実現することができる。
また、第３実施例は、端末２０が、共通ウォレット残高（限定ではなく、共通アカウントに関連付けられた第１電子貨幣の金額）の情報と、送金用画面（限定ではなく、第２アカウントから共通アカウントへ送金を行うための第１表示の一例）とを表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる、送金用画面に対する入力（操作入力、音入力等）に基づいて、自己の端末２０のユーザのユーザアカウントから共通アカウントへの送金が実行され、共通アカウントへの送金に基づいて、送金後の共通ウォレット残高（限定ではなく、共通アカウントに関連付けられた第２電子貨幣の金額）の情報を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第１電子貨幣の金額を端末のユーザに知らせることができる。また、第１表示に対する入力に基づいて、第２アカウントから共通アカウントへの送金を簡単に実現することができるとともに、共通アカウントへの送金に基づいて、共通アカウントに関連付けられた第２電子貨幣の金額を端末のユーザに知らせることができる。
また、第３実施例は、第１決済に関する処理は、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）から送金された共通アカウントに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第２アカウントから送金された共通アカウントに基づいて決済を実現することができる。
また、第３実施例は、送金用画面に対する入力（限定ではなく、第１表示に対する入力の一例）は、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）から共通アカウントへ送金する金額の入力を含む構成を示している。
このような構成により得られる効果の一例として、第２アカウントから共通アカウントへ送金する金額の入力に基づいて、第２アカウントから共通アカウントへの送金を実現することができる。
また、第３実施例は、第２アカウントは、自己の端末２０のユーザのユーザアカウント（限定ではなく、端末のユーザのアカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、端末のユーザのアカウントを第２アカウントとして決済を実現することができる。
＜第３変形例（１）＞
第３実施例では、利用者提示型のコード決済について説明したが、これに限定されない。
具体的には、限定ではなく例として、店舗提示型のコード決済を適用することもできる。
＜表示画面例＞
図３－９は、端末２０の表示部２４に表示されるコードリーダ画面の一例を示す図である。
図３－３のキャンプ資金支払い画面において「コード支払い」のアイコンではなく「コードリーダ」のアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合、限定ではなく例としてアプリケーションコードリーダが起動され、図３－９に示すような支払い店舗コードを読み取るためのコードリーダ画面が表示部２４に表示される。
このコードリーダ画面では、タイトルバーの下に「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。
また、「キャンプ資金」の下には、コード読み取り領域ＣＲ１が表示され、その下にはユーザに対する操作案内として「コードリーダ」が表示され、その下にはキャンプ資金コード支払い領域２４２３が表示されている。
キャンプ資金コード支払い領域２４２３には、上部に共通ウォレットであることを示す角財布の画像とともに「キャンプ資金」の文字が表示され、その横に、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。また、その下には、チェックマークボタンＣＮ２および自分のウォレットから送金の文字とともに、自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。
ここで、図３－９のコードリーダ画面においてチェックマークボタンＣＮ２が端末２０のユーザＡ．Ａによってタッチ操作されると、図３－５と同様の送金用画面が表示される。この例では、送金用画面においてユーザＡ．Ａが自分のウォレットから共通ウォレットに「５，０００円」を送金する場合を例示する。
図３－１０は、図３－５の送金用画面において、送金ボタン２４２Ａがタッチ操作されて自分のウォレットからキャンプ資金へ送金が完了し、その後、支払い店舗コードの読み取りが完了した場合に表示される読み取り完了画面の一例を示す図である。
このコード読み取り領域ＣＲ１内には、読み取られた支払い店舗コードが表示されている。また、キャンプ資金コード支払い領域２４２３には、上記のようにユーザＡ．Ａが自分のウォレットから共通ウォレットに「５，０００円」を送金したことに基づき、キャンプ資金の共通ウォレット残高として「６，０００円」が表示され、自分の電子マネー口座残高として「２０，０００円」が表示されている。また、送金が行われたことを示すチェックマークボタンＣＮ２が反転表示されている。
図３－１１は、図３－１０の読み取り完了画面で読み取られた支払い店舗コードからデコードによって情報が取得された場合に表示される支払い金額入力画面の一例を示す図である。
この支払い金額入力画面には、ユーザに対する操作案内として「支払い金額の入力」が表示され、その下に、支払い金額の送金先である「ＡＡスポーツ株式会社」のアイコン画像とともに、その名称「ＡＡスポーツ株式会社」が表示されている。また、その下には、入力された支払い金額を表示するための支払い金額表示領域２４２４が表示され、ここでは、支払い金額として「３，０００円」が入力されて表示されている。また、その下には、「お支払い金額（税込）を入力してください」の文字が表示され、その下に、支払いボタン２４２Ｃが表示されている。
また、画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額を消去するための消去ボタンＣＮ４が表示されている。
図３－１１に示される支払い金額入力画面において、支払いを実行するための支払いボタン２４２Ｃがタッチ操作されてコード支払いが完了すると、図３－７と同様にコード支払い完了画面が表示される。
＜処理＞
図３－１２は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図１－１１と同一とすることができるため、ここでは説明を省略する。
図３－８のＳ１００ａと同様に共通ウォレット支払いトークンが生成され、サーバ１０の制御部１１は、共通ウォレット支払いトークンを含むコード読み取り用情報である共通ウォレットコードリーダ情報を生成する。そして、サーバ１０の制御部１１は、共通ウォレットコードリーダ情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１００ｂ）。そして、サーバ１０の制御部１１は、Ｓ１１０に処理を移す。
Ａ１００の後、通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレットコードリーダ情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレットコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示させる。また、端末Ａの制御部２１は、コードを読み取るためにカメラ２７を起動させる（Ａ１１０ｂ）。そして、端末Ａの制御部２１は、Ａ１２０に処理を移す。
Ａ１７０の後、加盟店に提示される支払い店舗コードを、カメラ２７等を用いて読み取ると、端末Ａの制御部２１は、読み取った支払い店舗コードから店舗ＩＤを取得する（Ａ１９０）。
その後、端末Ａの制御部２１は、決済予定金額を入力させるための表示画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて、決済予定金額が入力されると、制御部２１は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗ＩＤと、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２００）。そして、端末Ａの制御部２１は、Ａ１８０に処理を移す。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Ａにおける決済予定金額の入力は省略することが可能である。
Ｓ１６０の後、通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する（Ｓ１７０ｂ）。
その後、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否および決済処理後の共通ウォレット残高を含む決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ１８０ｂ）。そして、制御部１１は、処理を終了する。
本変形例は、端末２０が、共通ウォレットコードリーダ情報に基づく、支払い店舗コード（限定ではなく、コード情報の一例）を読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）と、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）に関するユーザアカウント情報（限定ではなく、第２アカウント情報の一例）とを表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる、そのユーザのユーザアカウントの電子マネー口座から共通ウォレットへ送金することを選択するための入力（操作入力、音入力等）（限定ではなく、第２アカウント情報に対する入力の一例）に基づいて、送金用画面を表示部２４に表示する処理、送金依頼情報をサーバ１０に送信する処理、共通ウォレット残高をサーバ１０から受信する処理、受信された共通ウォレット残高を表示部２４に更新して表示させる処理、ユーザアカウントの電子マネー口座残高をサーバ１０から受信する処理、受信されたユーザアカウントの電子マネー口座残高を表示部２４に更新して表示させる処理、支払い店舗コードを読み取る処理、決済要求情報をサーバ１０に送信する処理、決済結果情報をサーバ１０から受信する処理、受信された決済結果情報を表示部２４に表示する処理といった、決済に関連する処理として端末２０で実行される処理（限定ではなく、第１アカウントと、第２アカウントとに基づく第１決済に関する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、コード情報の読み取りに関する表示である第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができるとともに、第１アカウントとは異なる第２アカウントに関する第２アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する入力に基づいて、第１アカウントと第２アカウントとに基づく決済を実現することができる。
＜第３変形例（２）＞
第３実施例では、支払い開始時におけるユーザＡ．Ａの電子マネー口座残高内から共通ウォレットへ送金する例を示したが、それに限定されない。
限定ではなく例として、共通ウォレットへの送金前に、ユーザＡ．Ａによってあらかじめ登録される外部金融機関の口座から、ユーザＡ．Ａの電子マネー口座へチャージ（送金）を行ってもよい。
＜表示画面例＞
図３－１３は、図３－３のキャンプ資金支払い画面において「コード支払い」のアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面（送金前）の一例を示す図である。
キャンプ資金コード支払い領域２４２１内の表示は、図３－４とほぼ同様であるが、一部が異なっている。具体的には、限定ではなく例として、「自分のウォレットから送金」に関連付けられた自分の電子マネー口座残高の金額の横に、自分の電子マネー口座にチャージするためのチャージボタンＣＮ５が表示されている。また、この例では、自分の電子マネー口座残高として「１，０００円」が表示されている。
また、その下には、共通ウォレットにチャージするための表示として、チェックマークボタンＣＮ２とともに「共通ウォレットへチャージ」の文字が表示されている。
図３－１４は、図３－１３のコード支払い画面（チャージ前）において、チャージボタンＣＮ５がタッチ操作された場合に表示されるチャージ画面の一例を示す図である。
タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「自分のウォレット」が表示されている。また、「自分のウォレット」の下には、ユーザに対する操作案内として「チャージ」が表示され、その下に、銀行口座表示領域２４２５が設けられている。
この例では、銀行口座表示領域２４２５内には、「〇×銀行」のロゴ（〇×ＢＡＮＫ）とともに、その銀行名「〇×銀行」が表示されている。また、その下には、預金種類および口座番号として「普通預金口座 ＊＊＊＊＊＊＊」が表示され、その下には、口座名義人である「Ａ．Ａ」が表示されている。
銀行口座表示領域２４２５の下には、「チャージ金額」の表示とともに、入力されたチャージ予定金額を表示するためのチャージ予定金額入力領域２４２６が設けられている。ここでは、チャージ予定金額として「２４，０００円」が入力されて表示されている。
また、その下には、チャージ予定金額入力領域２４２６へのチャージ金額入力用であり、この例では「１００円」をチャージするための第１チャージボタンＢＴ５と、「１，０００円」をチャージするための第２チャージボタンＢＴ６と、「１０，０００円」をチャージするための第３チャージボタンＢＴ７とが横方向に並んで表示されている。
この例において、第１チャージボタンＢＴ５がタッチ操作されると、チャージ予定金額入力領域２４２６内は「２４，１００円」と表示され、続けて第２チャージボタンＢＴ６がタッチ操作されると、「２５，１００円」と表示され、続けて第３チャージボタンＢＴ７がタッチ操作されると、「３５，１００円」と表示される。
なお、チャージ予定金額入力領域２４２６内の左部には、消去ボタンＢＴ８が表示され、消去ボタンＢＴ８がタッチ操作されると、チャージ予定金額入力領域２４２６内の金額は消去され、チャージ予定金額入力領域２４２６内は「０円」と表示される。
また、チャージ用画面下部には、チャージ予定金額入力領域２４２６内に入力された金額のチャージを実行するためのチャージボタン２４２Ｄが表示されている。チャージボタン２４２Ｄがタッチ操作された場合、自分のウォレットに「２４，０００円」がチャージされる。
なお、チャージ予定金額入力領域２４２６がタッチ操作されると、表示部２４の下部には送金予定額を入力するためのテンキー領域が表示され、テンキー領域への入力に基づいて、送金予定額を細かく入力することも可能である。
図３－１５は、図３－１４のチャージ画面において、チャージボタン２４２Ｄがタッチ操作された場合に表示されるコード支払い画面の一例を示す図である。
キャンプ資金コード支払い領域２４２１内は、図３－１３と同様であるが、チャージされたことから「自分のウォレットから送金」の文字の横に表示される残高（この例では「２５，０００円」）の金額が異なっている。
なお、この例では、支払いコードは、何れも図３－１３のものと同じコードとなっている。
前述のように、「自分のウォレットから送金」に対応するチェックマークボタンＣＮ２がタッチされ、キャンプ資金に対して送金が実行された後、端末２０のユーザＡ．Ａは、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。サーバ１０による決済処理が完了すると、図３－７と同様のコード支払い完了画面が表示される。
＜処理＞
図３－１６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
Ａ１３０の後、端末Ａの制御部２１は、限定ではなく例として、ユーザＡ．Ａの電子マネー口座へチャージを行うか否かの選択用画面を表示部２４に表示させる。そして、端末Ａの制御部２１は、端末Ａの入出力部２３に対するユーザ操作に基づいて、ユーザＡ．Ａの電子マネー口座へチャージすることが選択されたか否かを判定する（Ａ２１０）。
ユーザＡ．Ａの電子マネー口座へチャージすることが選択された場合（Ａ２１０：ＹＥＳ）、端末Ａの制御部２１は、チャージ金額の入力を促す画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて、チャージ金額が入力されると、端末Ａの制御部２１は、チャージ金額を含むチャージ依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２２０）。
Ｓ１２０の後、通信Ｉ／Ｆ１４によって端末Ａからチャージ依頼情報を受信すると（Ｓ１９０：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＡ．Ａの外部金融機関の口座残高からチャージ金額を減額させ、ユーザＡ．Ａの電子マネー口座残高をチャージ金額だけ増加させるチャージ処理を実行する（Ｓ２００）。
その後、サーバ１０の制御部１１は、チャージ処理後のユーザＡ．Ａの電子マネー口座残高を含むユーザアカウント情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ２１０）。
なお、Ｓ２００の処理において、ユーザＡ．Ａの外部金融機関の口座残高がチャージ金額を下回る等の理由でチャージが正常に行われない場合には、チャージが失敗した旨を含むユーザアカウント情報を送信してもよいし、送信しなくてもよい。
通信Ｉ／Ｆ２２によってサーバ１０からユーザアカウント情報を受信すると、端末Ａの制御部２１は、受信されたユーザアカウント情報に基づき、限定ではなく例として、端末ＡのユーザＡ．Ａの電子マネー口座残高を、表示部２４に更新して表示させる（Ａ２３０）。
一方、ユーザＡ．Ａの電子マネーへチャージすることが選択されない場合（Ａ２１０：ＮＯ）、Ａ２２０～Ａ２３０のステップは実行されない。従って、サーバ１０の制御部１１は、チャージ依頼情報を受信せず（Ｓ１９０：ＮＯ）、Ｓ２００～Ｓ２１０のステップも実行されない。
なお、共通ウォレットへの送金処理（図３－１６のＡ１７０およびＳ１６０）の後に、Ａ２１０～Ａ２３０のステップおよびＳ１９０～Ｓ２１０のステップを実行することで、ユーザＡ．Ａの電子マネー口座へ電子マネーをチャージしてもよいし、しなくてもよい。
＜第３変形例（３）＞
第３実施例では、決済処理を行う時点におけるユーザＡ．Ａの電子マネー口座残高内から共通ウォレットへ送金する例を示したが、それに限定されない。
限定ではなく例として、共通ウォレットへの送金前に、ユーザＡ．Ａによってあらかじめ登録される外部金融機関の口座から、共通ウォレットへ電子マネーとしてチャージ（送金）を行ってもよい。
図３－１７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
Ａ１３０の後、端末Ａの制御部２１は、限定ではなく例として、共通ウォレットへチャージを行うか否かの選択用画面を表示部２４に表示させる。そして、端末Ａの制御部２１は、端末Ａの入出力部２３に対するユーザ操作に基づいて、共通ウォレットへチャージすることが選択されたか否かを判定する（Ａ２４０）。
共通ウォレットへチャージすることが選択された場合（Ａ２４０：ＹＥＳ）、端末Ａの制御部２１は、共通ウォレットへのチャージ金額の入力を促す画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて、共通ウォレットへのチャージ金額が入力されると、端末Ａの制御部２１は、共通ウォレットへのチャージ金額を含む共通ウォレットチャージ依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ２５０）。
Ｓ１２０の後、通信Ｉ／Ｆ１４によって端末Ａから共通ウォレットチャージ依頼情報を受信すると（Ｓ２２０：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＡ．Ａの外部金融機関の口座残高から共通ウォレットへのチャージ金額を減額させ、共通ウォレット残高を共通ウォレットへのチャージ金額だけ増加させる共通ウォレットチャージ処理を実行する（Ｓ２３０）。
その後、サーバ１０の制御部１１は、共通ウォレットチャージ処理後の共通ウォレット残高を含む共通ウォレット情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ２４０）。
なお、Ｓ２３０の処理において、ユーザＡ．Ａの外部金融機関の口座残高が共通ウォレットへのチャージ金額を下回る等の理由でチャージが正常に行われない場合には、チャージが失敗した旨を含む共通ウォレット情報を送信してもよいし、送信しなくてもよい。
通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレット情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を、表示部２４に更新して表示させる（Ａ２６０）。
一方、共通ウォレットへ電子マネーをチャージすることが選択されない場合（Ａ２４０：ＮＯ）、Ａ２５０～Ａ２６０のステップは実行されない。従って、サーバ１０の制御部１１は、共通ウォレットチャージ依頼情報を受信せず（Ｓ２２０：ＮＯ）、Ｓ２３０～Ｓ２４０のステップも実行されない。
なお、共通ウォレットへの送金処理（図３－１７のＡ１７０およびＳ１６０）の後に、Ａ２４０～Ａ２６０のステップおよびＳ２２０～Ｓ２４０のステップを実行することで、共通ウォレットへ電子マネーをチャージしてもよいし、しなくてもよい。
＜第３変形例（４）＞
第３実施例において、端末２０が、自己の端末２０のユーザとは異なる他の共通ウォレットメンバーの端末２０に共通ウォレットへの送金を依頼する情報を送信するなどして、共通ウォレットへ送金を行ってもらうようにしてもよいし、そのようにしなくてもよい。
図３－１８は、本変形例において端末２０の表示部２４に表示されるコード支払い画面の一例を示す図であり、ユーザＡ．Ａの端末２０（端末Ａ）の表示部２４に表示される画面の一例を示している。
このコード支払い画面は、韓国旅行用の共通ウォレットに対応するコード支払い画面であり、韓国旅行用の共通ウォレットの表示領域である韓国旅行表示領域２４３１内に、前述した自分のウォレットから共通ウォレットに送金するための「自分のウォレットから送金」の項目および共通ウォレットへチャージするための「共通ウォレットへチャージ」の項目に加えて、共通ウォレットへの送金を他の共通ウォレットメンバーに依頼するための「ほかのメンバーへ送金依頼」の項目が設けられている。また、これら各々の項目と関連付けて、その項目に対応する処理を実行させるためのチェックマークボタンＣＮ２が設けられている。
図３－１９は、図３－１８のコード支払い画面において他のメンバーへ送金依頼の項目に関連付けられたチェックマークボタンＣＮ２がタッチ操作された場合に表示部２４に表示されるメンバー選択画面の一例を示す図である。
このメンバー選択画面は、送金を依頼する共通ウォレットメンバー（送金依頼先）を選択するための画面であり、画面中央部に、共通ウォレットメンバーの候補が一覧表示されている。この例では、韓国旅行用の共通ウォレットの共通ウォレットメンバーであって、自己の端末２０のユーザ（ユーザＡ．Ａ）以外の共通ウォレットメンバーとして、ユーザＤ．Ｄと、ユーザＥ．Ｅとの２名が、アイコン画像およびユーザ名とともに表示されている。
各々の共通ウォレットメンバーには、チェックマークボタンＣＮ２が関連付けて表示されており、チェックマークボタンＣＮ２を「ＯＮ」の状態とすることで、その共通ウォレットメンバーを送金依頼先として選択することができるように構成されている。
この場合、１人に限らず、２人以上（全員を含む。）の共通ウォレットメンバーを送金依頼先として選択することも可能である。
また、画面下部には、送金の依頼を実行するための「送金依頼」と示された送金依頼ボタン２４２Ｕと、前の画面に戻るための「戻る」と示された戻るボタン２４２Ｖとが表示されている。
送金依頼ボタン２４２Ｕは、全てのチェックマークボタンＣＮ２が「ＯＦＦ」の状態では、限定ではなく例としてグレーアウトしており、操作を受付不可の状態となっている。少なくとも１つのチェックマークボタンＣＮ２が「ＯＮ」の状態となると、グレーアウトが解除され、操作を受付可能な状態となる。
なお、この例とは異なり、送金依頼先のユーザを、少なくとも自己の端末２０のユーザと他の共通ウォレットメンバーとを含むチャットルームの選択に基づいて選択するようにすることも可能である。
以下では、メッセージングアプリケーションにおけるトークルームを例に挙げて説明する。メッセージングアプリケーションを利用したトークは「チャット」の一例であり、トークルームは「チャットルーム」の一例である。
「チャット」とは、コンピュータネットワーク上のデータ通信回線を用いて端末２０のユーザ同士がコミュニケーションを行うための手段であり、「チャットルーム」は、このチャットを行うための仮想的な部屋である。チャットには、メッセージングサービス：ＭＳ（インスタントメッセージングサービス（ＩＭＳ）を含む。）、ソーシャルネットワーキングサービス：ＳＮＳを利用するものを含む。また、限定ではなく例として、いわゆるショートメッセージサービスを利用するものを含めてもよい。
本明細書において、チャットには、メッセージングサービスを利用したトークが含まれ、チャットルームには、トークを行うためのトークルームが含まれる。トークルームには、一対一でユーザがトークを行うためのトークルームの他、メッセージングサービスにおいて形成された複数のユーザを含むグループでトークを行うためのグループトークルームが含まれる。
図３－２０は、本変形例におけるサーバ１０の構成の一例を示す図である。
サーバ１０は、限定ではなく例として、支払い管理サーバ１０Ａと、メッセージング管理サーバ１０Ｂとを備える。
支払い管理サーバ１０Ａは、支払いサービスを提供するサーバ（支払いアプリケーションのアプリケーションサーバ）である。
メッセージング管理サーバ１０Ｂは、メッセージングサービス（ＭＳ：Messaging Service）を提供するサーバ（メッセージングアプリケーションのアプリケーションサーバ）である。
なお、支払いアプリケーションは、上記の実施例のように、メッセージングサービスの機能を有さない単体のアプリケーションとしてサーバ１０によって提供されるようにしてもよいし、本変形例のように、メッセージングサービスの機能を有する複合的なアプリケーションとしてサーバ１０によって提供されるようにしてもよい。
また、メッセージングサービスには、端末２０間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス（ＩＭＳ：Instant Messaging Service）を含めてもよいし、含めなくてもよい。
本変形例において、メッセージング管理サーバ１０Ｂは、メッセージングサービスとして、限定ではなく例として、ＩＭＳを提供することとして説明する。
また、以下では、メッセージングアプリケーションと支払いアプリケーションとが複合的なアプリケーションとして構成されており、メッセージングアプリケーションのユーザの情報と、支払いアプリケーションのユーザの情報とが、共通の情報としてサーバ１０で管理されていることとして説明する。
また、以下では、メッセージングアプリケーションの名称を、適宜「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」として図示・説明する。
図３－２１は、この場合にユーザＡ．Ａの端末Ａで実行されるメッセージングアプリケーションにおけるメンバー選択画面（トークルーム選択画面）の一例を示す図である。
限定ではなく例として、図３－１８のコード支払い画面において他のメンバーへ送金依頼の項目に関連付けられたチェックマークボタンＣＮ２がタッチ操作されると、支払いアプリケーションの画面からメッセージングアプリケーションの画面に遷移し、このメンバー選択画面が表示される。
このメンバー選択画面では、画面上部に「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の文字が表示され、その横に、自己の端末２０のユーザ（この例ではユーザＡ．Ａ）のアイコン画像およびユーザ名が表示されている。
また、「トークルームから選択」の文字とともに、「送金依頼するトークルームを選んでください」の文字が表示され、その下に、送金依頼先として選択するトークルームの候補が表示されている。
具体的には、限定ではなく例として、メッセージングアプリケーションにおいてユーザＡ．Ａと友だち登録されているユーザであって韓国旅行用の共通ウォレットと関連のあるユーザとの間でユーザＡ．Ａがトークを行うためのトークルームとして、共通ウォレットメンバーであるユーザＤ．Ｄのトークルームと、同じく共通ウォレットメンバーであるユーザＥ．Ｅのトークルームとが表示されている。
また、この例では、限定ではなく例として、メッセージングアプリケーションにおいてユーザＡ．Ａと友だち登録されているユーザであって韓国旅行用の共通ウォレットと関連のあるユーザとの間でユーザＡ．Ａがグループトークを行うためのグループトークルームとして、限定ではなく例として、ユーザＡ．ＡとユーザＤ．ＤとユーザＥ．Ｅとの３名で構成される「韓国グルメ連合（３）」のグループトークルームが表示されている。
各々のトークルームには、チェックマークボタンＣＮ２が関連付けて表示されており、チェックマークボタンＣＮ２を「ＯＮ」の状態とすることで、そのトークルーム（そのトークルームのユーザ）を送金依頼先として選択することができるように構成されている。
この場合、限定ではなく例として、１人に限らず、２人以上（全員を含む。）のユーザを送金依頼先として選択することも可能である。
なお、上記のメッセージングアプリケーションにおけるメンバー選択画面において、グループトークルームは送金依頼先の候補として表示しないようにしてもよい。また。メッセージングアプリケーションにおいてユーザＡ．Ａと友だち登録されている全てのユーザ、支払いアプリケーションにおいてユーザＡ．Ａと共通ウォレットメンバーとなっているユーザ、あらかじめユーザＡ．Ａが選択・設定しておいたユーザ等のトークルームを送金依頼先の候補として表示するようにしてもよいし、そのようにしなくてもよい。
本変形例は、第２アカウントは、自己の端末２０のユーザとは異なる他の共通ウォレットメンバー（限定ではなく、第１ユーザの一例）のユーザアカウント（限定ではなく、第１ユーザのアカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、第１ユーザのアカウントを第２アカウントとして、共通アカウントと、第２アカウントとに基づく決済を実現することができる。
また、本変形例は、他の共通ウォレットメンバーのユーザアカウントは、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる端末に対する入力に基づいて、第２アカウントを簡単に選択することができる。
また、本変形例は、他の共通ウォレットメンバーのユーザアカウントは、自己の端末２０のユーザと他の共通ウォレットメンバーとを含むトークルーム（限定ではなく、チャットルームの一例）の選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる、端末のユーザと第１ユーザとを含むチャットルームの選択に基づいて、第２アカウントを簡単に選択することができる。
＜第４実施例＞
第４実施例は、端末２０が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、共通ウォレット残高が不足していることに関する情報を表示する実施例である。
また、第４実施例は、共通ウォレット残高が不足している場合に、共通ウォレットに代えて、第３実施例で説明した手法に基づき、自己の端末２０のユーザの電子マネー口座から共通ウォレットへ送金を行うことで、共通ウォレットの残高不足を補う実施例である。
第４実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜表示画面例＞
図４－１は、図３－４のコード支払い画面においてチェックマークボタンＣＮ２をタッチ操作せずに、支払いコードでコード支払いした場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
この共通ウォレット残高不足画面では、現在位置として「キャンプ資金」が表示され、「キャンプ資金」の下には、共通ウォレット残高不足情報表示・操作領域２４２７が、ポップアップ形式で表示されている。この例では、残高が不足していることを表す画像として「困った顔のロボット」の画像が表示され、その下に残高不足メッセージとして「共通ウォレット残高不足です」が表示されている。
また、その下には、「支払いしようとする買い物」が文字で表示され、その下に、ＡＡスポーツ株式会社のロゴ画像とともに、その会社名である「ＡＡスポーツ株式会社」の文字が表示されている。その横には、支払い金額として「３，０００円」の文字が表示され、その下には、内訳として、角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。
また、その下には、端末２０のユーザのウォレット（電子マネー口座）であることを示すがま口財布の画像および自分のウォレットとともに、自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。さらに、その下には、共通ウォレット残高不足を自分のウォレットから送金するために、「自分のウォレット残高から２，０００円を送金しますか？」の案内文が表示されている。
また、この例では、共通ウォレット残高不足情報表示・操作領域２４２７の下部には、残高不足を補うために、不足金額の送金を実行するための、限定ではなく例として「送金する」と示された送金ボタン２４２Ｅが表示されている。また、その下には、不足金額の送金を実行しないための、限定ではなく例として「今はしない」と示されたキャンセルボタン２４２Ｆが表示されている。
図４－２は、図４－１の共通ウォレット残高不足画面において、送金ボタン２４２Ｅがタッチ操作された場合に表示されるコード支払い画面（送金後）の一例を示す図である。
キャンプ資金コード支払い領域２４２１内は、図３－４と同様であるが、自分のウォレットから送金後であることから、各々残高の金額が異なるものとなっている。つまり、キャンプ資金の共通ウォレット残高として、送金額が加算された「３，０００円」が表示され、自分の電子マネー口座残高として、送金額が減算された「２３，０００円」が表示されている。
図４－３は、図３－７と同様にサーバ１０によるコード支払いが完了した場合に端末２０に表示されるコード支払い完了画面の一例を示す図である。
図４－３に示すコード支払い完了画面は、図３－７に示すコード支払い完了画面とは、支払先の下に、下線を介して支払い内訳が追加されている点が異なっている。具体的には、支払い内訳として、角財布の画像およびキャンプ資金の文字とともに、この「キャンプ資金」の共通ウォレット残高（この例では「１，０００円」）が表示されている。また、その下に、がま口財布の画像および自分のウォレットの文字とともに、自分の電子マネー口座残高（この例では「２，０００円」）が表示されている。
＜処理＞
図４－４～図４－５は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
店舗コードリーダ装置５０の制御部５１は店舗決済処理を実行し、店舗コードリーダ装置５０の入出力部５２に対する操作に基づいて、所定の決済予定金額（限定ではなく例として「３，０００円」）が制御部５１へ入力される。そして、店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示される支払いコードを読み取る（Ｐ１００）。この場合、表示部２４に表示される支払いコードは、共通ウォレット支払いトークンと関連付けられているため、コードリーダ５８の読み取り結果には、共通ウォレット支払いトークンが含まれる。
店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、共通ウォレット支払いトークンとを含む決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１１０）。
Ｓ１２０の後、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する（Ｓ２５０ａ）。
決済処理で決済が成功した場合（Ｓ２６０ａ：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１８０ａに処理を進める。
一方、決済処理で決済が失敗した場合（Ｓ２６０ａ：ＮＯ）、サーバ１０の制御部１１は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信Ｉ／Ｆ１４によって端末Ａと店舗コードリーダ装置５０とに送信する（Ｓ２７０ａ）。そして、サーバ１０の制御部１１は、Ｓ１３０に処理を移す。Ｓ１３０～Ｓ１６０の各ステップは、図３－８と同様である。そして、サーバ１０の制御部１１は、Ｓ１７０ａに処理を進める。
Ａ１３０の後、通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると（Ａ２７０ａ：ＹＥＳ）、端末Ａの制御部２１は、受信された決済残高不足情報を表示部２４に表示させる（Ａ２８０）。
また、端末Ａの制御部２１は、受信した決済残高不足情報に含まれる決済残高不足額を、記憶部２８に記憶させる（Ａ２９０）。そして、端末Ａの制御部２１は、Ａ１４０に処理を移す。Ａ１４０～Ａ１７０の各ステップは、図３－８と同様である。そして、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０に処理を進める。
一方、サーバ１０から決済残高不足情報を受信しなかった場合（Ａ２７０ａ：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０に処理を進める。
Ｐ１１０の後、通信Ｉ／Ｆ５４によってサーバ１０から決済残高不足を受信すると（Ｐ１２０：ＹＥＳ）、店舗コードリーダ装置５０の制御部５１は、決済残高不足情報を表示部５３に表示させる（Ｐ１３０）。そして、店舗コードリーダ装置５０の制御部５１は、再度コード読み取り処理を実行する（Ｐ１４０）。そして、店舗コードリーダ装置５０の制御部５１は、Ｐ１５０に処理を進める。
一方、サーバ１０から決済残高不足情報を受信しなかった場合（Ｐ１２０：ＮＯ）、店舗コードリーダ装置５０の制御部５１は、通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信し、Ｐ１６０に処理を進める。
なお、本実施例における「決済残高不足情報が表示された」の意味は、第２実施例と同様である。
＜第４実施例の効果＞
第４実施例は、端末２０が、自己の端末２０のユーザが決済可能なアカウント（限定ではなく、第１アカウントの一例）に基づいて決済に関する処理を制御部２１によって実行する。また、端末２０は、決済残高不足情報（限定ではなく、第１決済の金額と、第１アカウントの残高とに基づく、第１アカウントの残高が不足していることに関する第１情報の一例）を表示部２４に表示する。そして、端末２０は、決済残高不足情報が表示された表示部２４に対する入力に基づいて、自己の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントとは異なる第２アカウントの一例）から共通アカウントに送金する処理（限定ではなく、第１決済に関する処理の一例）を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントの残高が不足していることを端末のユーザに知らせることができる。また、第１アカウントに基づいて決済を実現することができる他、第１アカウントとは異なる第２アカウントに少なくとも基づいて決済を実現することができる。
また、第４実施例は、自己の端末２０のユーザが決済可能なアカウントは、共通アカウント（限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントに基づいて決済を実現することができる。
また、第４実施例は、決済に関する処理は、決済残高不足情報が表示された表示部２４に対する入力に基づいて、共通アカウントと、自己の端末２０のユーザのユーザアカウントとに基づいて、実行される構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、第２アカウントとに少なくとも基づいて決済を実現することができる。
また、第４実施例は、決済（限定ではなく、第１決済の一例）は、共通ウォレット残高と、自己の端末２０のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、第２アカウントを付随的なアカウントとすることができる。
また、第４実施例は、決済は、自己の端末２０のユーザのユーザアカウントから共通アカウントに送金され、共通アカウントの残高に基づいて行われる構成を示している。
このような構成により得られる効果の一例として、第２アカウントから共通アカウントに送金して金額を補充することができるとともに、共通アカウントの残高に基づいて決済を行わせることができる。
また、第４実施例は、決済に関する処理は、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて、自己の端末２０のユーザのユーザアカウントから共通アカウントに送金される構成を示している。
このような構成により得られる効果の一例として、端末のユーザが端末に対する入力を行って、第２アカウントから共通アカウントに送金させるようにすることができる。
また、第４実施例は、端末２０が、自己の端末２０のユーザによる決済残高不足情報が表示された表示部２４に対する入力に基づいて、自己の端末２０のユーザのユーザアカウントが関連付けられた支払いコード（限定ではなく、第２アカウントと関連づけられた第１コード情報の一例）、または共通ウォレットコードリーダ情報に基づく、支払い店舗コード（限定ではなく、コード情報の一例）を読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０は、支払いコードが読み取られることに基づいて、またはコードリーダ画面が表示部２４に表示された端末２０によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる第１情報が表示された表示領域に対する入力に基づいて、第２アカウントと関連づけられた第１コード情報、またはコード情報の読み取りに関する表示であるコードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第１コード情報が読み取られることに基づいて、またはコードリーダ情報が表示領域に表示された端末によってコード情報を読み取ることに基づいて、簡単に決済を実現することができる。
また、第４実施例は、第２アカウントは、自己の端末２０のユーザのユーザアカウント（限定ではなく、端末のユーザのアカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、第１アカウントとは異なる端末のユーザのアカウントに少なくとも基づいて決済を実現することができる。
また、第４実施例は、決済に関する処理は、表示部２４に表示された支払いコードが店舗コードリーダ装置５０によって読み取られることに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、表示領域に表示されたコード情報が読み取られることに基づいて、簡単に決済を実現することができる。
また、第４実施例は、決済残高不足情報（限定ではなく、第１情報の一例）は、決済予定金額（限定ではなく、第１決済の金額の一例）と、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）とに基づき、共通ウォレット残高が不足している場合、サーバ１０（限定ではなく、第１決済の処理を実行するサーバの一例）から端末２０の通信Ｉ／Ｆ２２によって受信される構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高が不足している場合、第１決済の処理を実行するサーバから第１情報を簡単に取得することができる。
また、第４実施例は、サーバ１０が、一の端末２０のユーザが決済可能なアカウント（限定ではなく、端末のユーザが決済可能な第１アカウントの一例）に基づいて、決済処理（限定ではなく、第１決済に関する処理の一例）を制御部１１によって実行する。また、サーバ１０は、決済残高不足情報（限定ではなく、第１決済の金額と、第１アカウントの残高とに基づく、第１アカウントの残高が不足していることに関する第１情報の一例）を、一の端末２０に通信Ｉ／Ｆ１４によって送信する。そして、サーバ１０は、一の端末２０のユーザによる、この端末２０の表示部２４に表示された決済残高不足情報に対する入力に基づいて、この端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントとは異なる第２アカウントの一例）に少なくとも基づいて、決済処理を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントの残高が不足していることを端末に通知することができる。また、第１アカウントに基づいて決済を行うことができる他、第１アカウントとは異なる第２アカウントに少なくとも基づいて決済を行うことができる。
なお、一の端末２０のユーザが決済可能なアカウントは、上記と同様に、限定ではなく例として、共通アカウント（限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントの一例）とすることができる。
＜第４変形例（１）＞
第４実施例では、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択された場合（図４－４のＡ１４０：ＹＥＳ）、端末Ａの制御部２１は、送金額の入力を促す画面を表示部２４に表示させることとしたが、これに限定されない。
限定ではなく例として、端末Ａの制御部２１は、図４－４のＡ２９０で記憶する決済残高不足額を送金額として設定し、送金依頼情報をサーバ１０に送信することとしてもよいし、そのようにしなくてもよい。
＜第４変形例（２）＞
第４実施例では、店舗コードリーダ装置５０の制御部５１は、決済結果情報を表示部５３に表示させると（図４－４のＰ１３０）、再度コード読み取り処理を実行し、決済要求情報をサーバ１０に送信することとしたが、これに限定されない。
限定ではなく例として、サーバ１０の制御部１１は、図４－４のＳ１３０で送金依頼情報を受信する場合（Ｓ１３０：ＹＥＳ）、ユーザアカウント情報を端末２０に送信すると（図４－４のＳ１６０）、店舗コードリーダ装置５０から決済要求情報を受信せずとも、図４－４のＳ２５０ａの決済処理で使用した決済要求情報に基づいて、図４－５のＳ１７０ａの決済処理を実行してもよいし、実行しなくてもよい。
この場合、店舗コードリーダ装置５０の制御部５１は、図４－４のＰ１３０のステップの後に通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信し、図４－５のＰ１６０のステップを実行する。
＜第４変形例（３）＞
第４実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
＜表示画面例＞
図４－６は、図３－９のコードリーダ画面からコード支払いを行った場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
図４－６が図４－１と異なるのは、共通ウォレット残高不足情報表示・操作領域２４２７の背景がコードリーダ画面である点である。
図４－６において、自分のウォレット残高から「２，０００円」を送金するために送金ボタン２４２Ｅがタッチ操作されると、図３－１１と同様に、支払い金額入力画面が表示される。ここで、図３－１１と同様に「３，０００円」が入力されて支払いボタン２４２Ｃがタッチ操作されると、図４－３と同様に、コード支払い完了画面が表示される。
＜処理＞
図４－７～図４－８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
Ａ１３０の後、端末Ａの制御部２１は、カメラ２７を用いて加盟店に提示される支払い店舗コードを読み取り、支払い店舗コードから店舗ＩＤを取得する（Ａ３００）。
その後、端末Ａの制御部２１は、決済予定金額を入力させるための表示画面を表示部２４に表示させる。端末Ａの入出力部２３に対するユーザ操作に基づいて、決済予定金額が入力されると、制御部２１は、限定ではなく例として、共通ウォレットコードリーダ情報に含まれる共通ウォレット支払いトークンと、店舗ＩＤと、決済予定金額とを含む決済要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３１０）。
なお、支払い店舗コードに決済予定金額が含まれている場合には、端末Ａにおける決済予定金額の入力は省略することが可能である。
通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、要求を受けた共通ウォレット支払いトークンから共通ウォレットＩＤを検索し、その共通ウォレットに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する（Ｓ２５０ｂ）。
Ｓ２５０ｂにおいて決済が成功した場合には（Ｓ２６０ｂ：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ１８０ｂに処理を移す。
Ｓ２５０ｂにおいて決済が失敗した場合（Ｓ２６０ｂ：ＮＯ）、サーバ１０の制御部１１は、決済が失敗した旨と、その場合の共通ウォレットでの決済残高不足額とを含む決済残高不足情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ２７０ｂ）。そして、サーバ１０の制御部１１は、Ｓ１３０に処理を移す。また、サーバ１０の制御部１１は、Ｓ１６０の後、端末Ａから決済要求情報を受信して、Ｓ１７０ｂに処理を移す。
端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると（Ａ２７０ｂ：ＹＥＳ）、決済残高不足情報を表示部２４に表示させ（Ａ２８０）、決済残高不足額を記憶部２８に記憶させる（Ａ２９０）。そして、端末Ａの制御部２１は、Ａ１４０に処理を移す。また、端末Ａの制御部２１は、Ａ１７０の後、Ａ１９０に処理を移す。
なお、第４変形例（１）と同様に、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択された場合（図４－７のＡ１４０：ＹＥＳ）、端末Ａの制御部２１は、図４－７のＡ２９０で記憶する決済残高不足額を送金額として設定し、送金依頼情報をサーバ１０に送信することとしてもよいし、そのようにしなくてもよい。
本変形例は、決済に関する処理は、端末２０による支払い店舗コードの読み取りに基づいて実行される構成を示している。
このような構成により得られる効果の一例として、端末によるコード情報の読み取りに基づいて、簡単に決済を実現することができる。
＜第４変形例（４）＞
第４変形例（３）では、端末Ａの制御部２１は、決済残高不足情報を表示部５３に表示させると（図４－７のＡ２８０）、再度コード読み取り処理を実行し（図４－８のＡ１９０）、決済要求情報をサーバ１０に送信することとしたが、これに限定されない。
限定ではなく例として、端末Ａの制御部２１は、ユーザアカウント情報を更新すると（図４－７のＡ１７０）、図４－７のＡ３１０で送信した決済要求情報に基づいて、図４－８のＡ２００の決済要求情報をサーバ１０に送信してもよい。
＜第４変形例（５）＞
第４実施例では、加盟店での支払いにおいて、共通ウォレットの残高不足を端末ＡのユーザＡ．Ａの電子マネー口座から送金することで立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ請求しないこととしたが、これを請求するようにしてもよいし、そのようにしなくてもよい。
図４－９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図４－４、図４－５と同一の処理で実現可能であるため、ここでは説明を省略する。
端末Ａの制御部２１は、決済結果情報を表示させると（Ａ１８０）、立て替え分の精算（清算）を行うか否かの選択用画面を表示部２４に表示させる（Ａ３２０）。
なお、端末Ａの記憶部２８に記憶された決済残高不足額が「０」の場合、または決済が失敗している場合には、精算を行う必要がない（Ａ３２０：ＮＯ）ため、選択用画面を表示部２４に表示させず、処理を終了してもよいし、しなくてもよい。
また、端末Ａの記憶部２８に記憶された決済残高不足額が「０」より大きく、かつ決済が成功している場合には、選択用画面を表示部２４に表示させず、自動的に精算を行う（Ａ３２０：ＹＥＳ）ようにしてもよいし、しなくてもよい。
端末Ａの入出力部２３に対するユーザ操作に基づいて、精算を行うことが選択された場合（Ａ３２０：ＹＥＳ）、端末Ａの制御部２１は、端末Ａの記憶部２８に記憶された決済残高不足額を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３３０）。
一方、精算を行わないことが選択された場合（Ａ３２０：ＮＯ）、端末Ａの制御部２１は、処理を終了する。
サーバ１０の制御部１１は、決済結果情報を送信し（Ｓ１８０ａ）、通信Ｉ／Ｆ１４によって端末Ａから決済残高不足額を受信すると、決済残高不足額が「０」より大きいか否かを判定する（Ｓ２８０）。
受信した決済残高不足額が「０」、もしくは決済残高不足額を受信しない場合（Ｓ２８０：ＮＯ）、決済残高不足に陥っていない、もしくは精算は不要と判断され、サーバ１０の制御部１１は、処理を終了する。
受信した決済残高不足額が「０」より大きい場合には（Ｓ２８０：ＹＥＳ）、サーバ１０の制御部１１は、限定ではなく例として、決済残高不足額を「Ｍ」、共通ウォレットメンバーのユーザ数（共通ウォレットの構成ユーザ数）を「Ｎ」としたとき、「Ｍ÷Ｎ」を共通ウォレットの各構成ユーザへの支払い立替額として算出する。そして、サーバ１０の制御部１１は、支払い立替額を含む支払い立替額請求情報を、通信Ｉ／Ｆ１４によって共通ウォレットの立替者を除く各構成ユーザの端末（ここでは端末Ｂ）に送信する（Ｓ２９０）。
端末Ｂの制御部２１は、支払い立替額請求情報を通信Ｉ／Ｆ２２によってサーバ１０から受信すると（Ｂ１００：ＹＥＳ）、受信した支払い立替額と、支払い立替額の請求に応じるか否かの選択用画面を表示部２４に表示させる（Ｂ１１０）。なお、端末Ｂの制御部２１は、支払い立替額請求情報を受信しない場合には（Ｂ１００：ＮＯ）、処理を終了する。
端末Ｂの入出力部２３に対するユーザ操作に基づいて、支払い立替額の請求に応じることが選択された場合（Ｂ１１０：ＹＥＳ）、端末Ｂの制御部２１は、支払い立替額の精算を依頼するための精算依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１２０）。
端末Ｂの入出力部２３に対するユーザ操作に基づいて、支払い立替額の請求に応じないことが選択された場合（Ｂ１１０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
通信Ｉ／Ｆ１４によって端末Ｂから精算依頼情報を受信した場合（Ｓ３００：ＹＥＳ）、サーバ１０の制御部１１は、精算送金処理を実行する（Ｓ３１０）。
一方、精算依頼情報を受信しない場合（Ｓ３００：ＮＯ）、サーバ１０の制御部１１は、Ｓ３３０に処理を移す。
精算送金処理では、まず端末ＢのユーザＢ．Ｂの電子マネー口座から、共通ウォレットに支払い立替額を送金する。立替者を除く各構成ユーザの送金が完了すると、共通ウォレットから端末ＡのユーザＡ．Ａの電子マネー口座へ「（Ｎ－１）×支払い立替額」で算出される支払い者負担額を送金する。そして、サーバ１０の制御部１１は、送金結果を含む精算依頼結果情報を、通信Ｉ／Ｆ１４によって共通ウォレットの各構成ユーザの端末（ここでは端末Ｂ）に送信する（Ｓ３２０）。
なお、Ｓ２９０において２以上の端末に対して支払い立替額請求情報を送信する場合、サーバ１０の制御部１１は、送信した全ての端末から精算依頼情報を受信しない限り精算送金処理を実行しなくてもよいし、そうしなくてもよい。
また、精算送金処理において、共通ウォレットを介せず、ユーザの電子マネー口座間で送金を行ってもよいし、そうしなくてもよい。
最後にサーバ１０の制御部１１は、送金結果を含む精算結果情報を、通信Ｉ／Ｆ１４によって立替者であるユーザＡ．Ａの端末Ａに送信して（Ｓ３３０）、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から精算依頼結果情報を受信すると、端末Ｂの制御部２１は、精算依頼結果情報を表示部２４に表示させ（Ｂ１３０）、処理を終了する。
また、通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信すると、端末Ａの制御部２１は、精算結果情報を表示部２４に表示させ（Ａ３４０）、処理を終了する。
本変形例は、端末２０のユーザＢ．Ｂの入力に基づいて、支払い立替額請求情報に基づく共通ウォレットへの送金処理が実行される。ユーザＡ．Ａのアカウント（限定ではなく、第１アカウントの一例）は、ユーザＡ．Ａによる決済（限定ではなく、第１決済の一例）によってユーザＡ．Ａの端末２０のユーザアカウントから支払われた金額以上、またはそれよりも多くの金額が共通ウォレットに含まれている場合、ユーザＡ．Ａによる決済によってユーザＡ．Ａのユーザアカウントから支払われた金額が共通ウォレットから送金される構成を示している。
このような構成により得られる効果の一例として、第１アカウントは、第１決済によって第１アカウントから支払われた金額以上、またはそれよりも多くの金額が共通アカウントに含まれている場合、第１決済によって第１アカウントから支払われた金額が共通アカウントから送金されるようにすることができる。
＜第４変形例（６）＞
第４実施例では、端末Ａの制御部２１は、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択された場合、選択された時点におけるユーザＡ．Ａの電子マネー口座に基づいて送金依頼情報をサーバ１０に送信したが、これに限定されない。
＜表示画面例＞
図４－１０は、図３－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面（送金前）の一例を示す図である。
図４－１０が図３－４と異なるのは、キャンプ資金コード支払い領域２４２１内において「自分のウォレットから送金」の文字の横に表示される自分の電子マネー口座残高（この例では「１，０００円」）の金額である。
図４－１１は、図４－１０に示すコード支払い画面において支払いコードでコード支払いした場合であって、共通ウォレット残高が不足した場合に表示される共通ウォレット残高不足画面の一例を示す図である。
図４－１１が図４－１と異なるのは、共通ウォレット残高不足情報表示・操作領域２４２７において「自分のウォレットから送金」の文字の横に表示される自分の電子マネー口座残高（この例では「１，０００円」）の金額である。この例では、決済予定金額が「３，０００円」であるのに対し、キャンプ資金の共通ウォレット残高が「１，０００円」であり、「２，０００円」足りないことになる。このため、自分のウォレット残高から不足分の「２，０００円」を送金するか否かが選択される。
図４－１２は、図４－１１に示す共通ウォレット残高不足画面において、送金ボタン２４２Ｅがタッチ操作された場合に表示される自分のウォレット残高不足画面の一例を示す図である。
図４－１２は図４－１１における共通ウォレット残高不足情報表示・操作領域２４２７と同様であるが、ロボットの下に表示される「自分のウォレットの残高不足です」の文字が表示されることと、「自分のウォレットへチャージしますか？」の案内文が表示されていることとが異なっている。また、共通ウォレット残高不足情報表示・操作領域２４２７下部には、残高不足を補うために、不足金額のチャージを実行するためのチャージボタン２４２Ｇが表示されていることが異なっている。また、その下には、チャージを実行しないための、限定ではなく例として「今はしない」と示されたキャンセルボタン２４２Ｈが表示されている。
図４－１２において、自分のウォレットへチャージするためにチャージボタン２４２Ｇがタッチ操作されると、限定ではなく例として図３－１４と同様のチャージ画面が表示される。そして、このチャージ画面において所望の金額をチャージすることができる。
この例では、自分のウォレットへ「１，０００円」をチャージすることで、自分のウォレット残高が「２，０００円」となり、上記の不足分を補うことが可能となる。
なお、この場合に、第４変形例（５）で説明したように、ユーザＡ．Ａが支払いで立て替えた分の金額を、他のユーザ（限定ではなく例としてユーザＢ．Ｂ）に請求するようにすることも可能である。
図４－１３は、図４－２と同様に、サーバ１０によるコード支払いが完了した場合に端末２０に表示されるコード支払い完了画面の一例を示す図である。
図４－１３が図３－７と異なるのは、コード支払い完了画面下部に、支払い履歴確認ボタン２４２Ｊと、立替分請求ボタン２４２Ｋとが表示されていることである。
図４－１４は、図４－１３のコード支払い完了画面において立替分請求ボタン２４２Ｋがタッチ操作された場合に、立替分の請求先として共通ウォレットのキャンプ資金のメンバーであるユーザＢ．Ｂに対して立替分の請求をするために表示するおしらせ画面の一例を示す図である。
図４－１４において、このアプリケーション画面には、限定ではなく例として、支払いアプリケーションのアプリケーション名である「Ｐａｙｍｅｎｔ Ａｐｐ」が最上段のタイトルバーに表示され、その横に、ユーザＢ．Ｂのアイコン画像と、ユーザ名「Ｂ．Ｂ」の文字とが表示されている。タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として「おしらせ」文字が表示されている。
「おしらせ」の文字の下には、おしらせを意味するベルのアイコン画像が表示され、その横の上下段の内、上段には件名として「共通ウォレット：キャンプ資金」の文字が表示されるとともに、下段にはその内容として「Ａ．Ａさんから立替分の請求がとどきました」の文字が表示される。その下には、おしらせ日を示す「今日」の文字が表示され、その下には、キャンプ資金おしらせ表示領域２４２９が表示されている。
キャンプ資金おしらせ表示領域２４２９には、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称（この例では「キャンプ資金」）が表示されている。また、その横には、おしらせ日時として、「２０２０年４月１１日１６時３５分」が表示され、その下には、この共通ウォレットを共同で使用するユーザＡ．ＡおよびユーザＢ．Ｂのアイコン画像が表示されている。
また、キャンプ資金の下には、立替分の請求金額（以下、「立替分請求金額」と称する。）として「立替分請求金額」の文字が表示され、その下に、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。その下段には、「詳細を閉じる」の文字が表示され、その下には、立替分請求金額の詳細情報として、支払い金額の送金先であるＡＡスポーツ株式会社のロゴ画像とともに、その会社名「ＡＡスポーツ株式会社」の文字が表示されている。また、横には、送金日時として「２０２０年４月１１日１６時３０分」が表示され、その下には、支払い金額として「３，０００円」が表示されている。
また、その下には、「支払い内訳」が文字で表示され、その下に、角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。その下には、がま口財布の画像および「Ａ．Ａさんの立替」の文字が表示されるとともに、立替額（この例では「２，０００円」）が表示されている。また、その下には、共通ウォレットメンバーのアイコン画像とともに、「共通ウォレットのメンバー」の文字が表示され、人数として（この例では「２人」）が表示されている。
また、この例では、キャンプ資金おしらせ表示領域２４２９下部に、残高不足を補填するための金額の送金を実行するための送金ボタン２４２Ｌと、送金を後で行うためのあとでボタン２４２Ｍとが並んで表示されている。また、その下には、メニューに戻るためのメニューボタン２４２Ｎが表示されている。
図４－１５は、図４－１３のコード支払い完了画面において、支払い履歴確認ボタン２４２Ｊがタッチ操作された場合に表示される支払い履歴画面の一例を示す図である。
図４－１５では、支払い履歴が時系列の若い順に段表示されている。
支払い履歴の１段目には、支払い日時として、「２０２０年４月５日１１時１２分」と表示され、その下に、支払い先として、「ＥＥスーパー」の文字が表示され、支払い金額として、この例では「５，０００円」が表示されている。
支払い履歴の２段目には、支払い日時として「２０２０年４月１１日１６時３０分」と表示され、その横に、立替分として「立替分請求（２，０００円）」が反転表示された立替分請求アイコン２４２ｋが表示されている。立替分請求アイコン２４２ｋは、立替分請求ボタン２４２Ｋと同様の機能をもつアイコンであり、タッチ操作されると図４－１４へ遷移する。また、その下には、支払い先として「ＡＡスポーツ株式会社」が表示され、支払い金額として「３，０００円」が表示されている。
なお、上記の例において、立替分を請求したことを示す情報を請求元のユーザの端末２０の表示部２４に表示させたり、立替分が請求されたことを示す情報を請求先のユーザの端末２０の表示部２４に表示させるようにすることが可能である。
この場合、これらの情報は、支払いアプリケーションのアプリケーション画面に表示させてもよいが、これに代えて、前述したメッセージングアプリケーションのトークルーム画面に表示させるようにすることも可能である。
図４－１６は、図４－１３のコード支払い完了画面において立替分請求ボタン２４２Ｋが操作されたことに基づいてユーザＡ．Ａの端末２０（端末Ａ）の表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
端末Ａのユーザ（ユーザＡ．Ａ）が端末Ｂのユーザ（ユーザＢ．Ｂ）に対して立替分の請求を行ったことで、その旨を示すメッセージがメッセージング管理サーバ１０Ｂから端末Ａに送信されて、ユーザＡ．ＡがユーザＢ．Ｂとトークを行うためのトークルーム（ユーザＢ．Ｂをトーク相手とするトークルーム）に表示される。この例では、画面向かって右側に、ユーザＡ．Ａを発信元とするメッセージとして、ユーザＢ．Ｂに対して立替分を請求したこと、および、その詳細情報を含む第１の立替分請求メッセージ２４３３が吹き出しで表示されている。
図４－１７は、図４－１３のコード支払い完了画面において立替分請求ボタン２４２Ｋが操作されたことに基づいてユーザＢ．Ｂの端末２０（端末Ｂ）の表示部２４に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
端末Ａのユーザ（ユーザＡ．Ａ）から端末Ｂのユーザ（ユーザＢ．Ｂ）に対して立替分の請求が行われたことで、その旨を示すメッセージがメッセージング管理サーバ１０Ｂから端末Ｂに送信されて、ユーザＡ．Ａとトークを行うためのトークルームに表示される。この例では、画面向かって左側に、ユーザＡ．Ａを発信元とするメッセージとして、ユーザＡ．ＡからユーザＢ．Ｂに立替分が請求されたこと、および、その詳細情報を含む第２の立替分請求メッセージ２４３４が吹き出しで表示されている。
＜処理＞
図４－１８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
端末Ａの制御部２１は、ユーザＡ．Ａの電子マネー口座から共通ウォレットへ送金することが選択されると（Ａ１４０：ＹＥＳ）、Ａ２９０で記憶した決済残高不足額と、Ａ１３０で表示したユーザアカウント情報とに基づいて、ユーザＡ．Ａの電子マネー口座残高が決済残高不足額より少ないか否かを判定する（Ａ３５０）。
ユーザＡ．Ａの電子マネー口座残高が決済残高不足額以上である場合には（Ａ３５０：ＮＯ）、端末Ａの制御部２１は、Ａ１５０に処理を移す。
電子マネー口座残高不足の場合（Ａ３５０：ＹＥＳ）、端末Ａの制御部２１は、Ａ２１０～Ａ２３０のステップを実行する。従って、この場合、サーバ１０の制御部１１は、Ｓ２７０ａのステップを実行すると、Ｓ１９０～Ｓ２１０のステップを実行する。
なお、Ａ２１０のステップにおいて、アカウントにチャージすることが選択されない場合には（Ａ２１０：ＮＯ）、端末Ａの制御部２１は、Ａ１４０に戻って処理を実行してもよいし、しなくてもよい。
本変形例は、端末２０が、決済予定金額（限定ではなく、第１決済の金額の一例）と、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）と、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とに基づき、決済残高不足情報（限定ではなく、第１決済の金額と、共通アカウントの残高と、第２アカウントとに基づく、共通アカウントの残高が不足していることに関する第２情報の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる決済残高不足情報が表示された表示部２４に対する入力に基づいて、自己の端末２０のユーザのユーザアカウントの電子マネー口座にチャージする処理（限定ではなく、第２アカウントに対して送金する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる入力に基づいて、第２アカウントに対して送金することができる。
また、本変形例は、端末２０が、決済予定金額（限定ではなく、第１決済の金額の一例）と、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）と、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とに基づき、決済残高不足情報（限定ではなく、共通アカウントの残高と、第２アカウントの残高とに基づき、共通アカウントと第２アカウントとの残高が不足していることに関する第１情報の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる決済残高不足情報が表示された表示部２４に対する入力に基づいて、自己の端末２０のユーザのユーザアカウントの電子マネー口座にチャージする処理（限定ではなく、第２アカウントに対して送金する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと第２アカウントとの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる第１情報に対する入力に基づいて、第２アカウントに対して送金することができる。
＜第４変形例（７）＞
第４実施例では、決済処理を実行する端末（限定ではなく例として端末Ａ）のユーザ（限定ではなく例としてユーザＡ．Ａ）の電子マネー口座から共通ウォレットへ送金するか否かを選択するが、送金元の電子マネー口座はこれに限定されない。
限定ではなく例として、共通ウォレットを構成する他のメンバー（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座から送金を行えるようにしてもよい。
図４－１９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図４－５と同一とすることができるため、ここでは説明を省略する。
Ａ２９０の後、端末Ａの制御部２１は、限定ではなく例として、共通ウォレットメンバーである他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座から共通ウォレットへ送金を依頼するか否かの選択機能を持つボタンを表示部２４に加えて表示させる。そして、端末Ａの制御部２１は、端末Ａの入出力部２３に対するユーザ操作に基づいて、他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座から共通ウォレットへ送金を依頼することが選択されたか否かを判定する（Ａ３６０）。
ユーザＢ．Ｂの電子マネー口座から共通ウォレットへ送金を依頼することが選択された場合（Ａ３６０：ＹＥＳ）、端末Ａの制御部２１は、送金を依頼することと、限定ではなく例として決済残高不足額と等しい金額の送金要請額とを含む送金要請情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ３７０）。
ユーザＢ．Ｂの電子マネー口座から共通ウォレットへ送金を依頼することが選択されない場合（Ａ３６０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、図４－５のＡ１８０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａから送金要請情報を受信する場合（Ｓ３４０：ＹＥＳ）、サーバ１０の制御部１１は、送金要請額を含む送金確認情報を、通信Ｉ／Ｆ１４によって端末Ｂに送信する（Ｓ３５０）。
送金要請情報を受信しない場合（Ｓ３４０：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信し、図４－５のＳ１７０ａのステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から送金確認情報を受信する場合（Ｂ１４０：ＹＥＳ）、端末Ｂの制御部２１は、送金確認情報に基づいて、ユーザＢ．Ｂの電子マネー口座から共通ウォレットへ送金することを認可するか否かの選択用画面を表示部２４に表示させる（Ｂ１５０）。
一方、送金確認情報を受信しない場合（Ｂ１４０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
端末Ｂの入出力部２３に対するユーザ操作に基づいて、共通ウォレットへ送金することを認可することが選択された場合（Ｂ１５０：ＹＥＳ）、端末Ｂの制御部２１は、送金依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ１６０）。
一方、共通ウォレットへ送金することを認可しないことが選択された場合（Ｂ１５０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
通信Ｉ／Ｆ１４によって端末Ｂから送金依頼情報を受信する場合（Ｓ３６０：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＢ．Ｂの電子マネー口座から共通ウォレットへ、送金要請額を送金する送金処理を実行する（Ｓ３７０）。そして、サーバ１０の制御部１１は、限定ではなく例として、送金処理の成否と、送金後のユーザＢ．Ｂの電子マネー口座残高とを含む送金依頼結果情報を、通信Ｉ／Ｆ１４によって端末Ｂに送信する（Ｓ３８０）。
次いで、サーバ１０の制御部２１は、送金後の共通ウォレット残高を含む共通ウォレット情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ３９０）。
端末Ｂから送金依頼情報を受信しない場合（Ｓ３６０：ＮＯ）、サーバ１０の制御部１１は、共通ウォレット残高を含む共通ウォレット情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ３９０）。
なお、この場合、送金要請が端末Ｂによって断られたことを示す情報を共通ウォレット情報に組み入れて送信するようにしてもよいし、そのようにしなくてもよい。
次いで、サーバ１０の制御部１１は、決済要求情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信し、Ｓ１７０ａのステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から送金依頼結果情報を受信すると、端末Ｂの制御部２１は、送金依頼結果情報を表示部２４に表示させ（Ｂ１７０）、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から共通ウォレット情報を受信すると、端末Ａの制御部２１は、受信された共通ウォレット情報に基づき、限定ではなく例として、共通ウォレット残高を表示部２４に更新して表示させる（Ａ３８０）。
なお、送金要請が端末Ｂによって断られたことを示す情報が共通ウォレット情報に含まれる場合には、限定ではなく例として、その旨を表示部２４にポップアップ表示等させるようにしてもよいし、そのようにしなくてもよい。
次いで、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、Ａ１８０のステップを実行する。
なお、上記の処理において、端末２０の制御部２１が、限定ではなく例として、自己の端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）による、自己の端末２０のユーザと他のユーザ（限定ではなく例としてユーザＢ．Ｂ）とを少なくとも含むトークルーム（限定ではなく、チャットルームの一例）の選択に基づいて、他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座から共通ウォレットへ送金を依頼することが選択されるようにしてもよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、図３－２１で説明したメッセージングアプリケーションにおけるメンバー選択画面（トークルーム選択画面）と同様の画面を端末２０の表示部２４に表示させて、送金を依頼するトークルームをユーザに選択させるようにすることができる。
本変形例は、第２アカウントは、自己の端末２０のユーザとは異なるユーザ（限定ではなく、第１ユーザの一例）のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、端末のユーザとは異なる第１ユーザのアカウントに少なくとも基づいて決済を実現することができる。
また、本変形例は、自己の端末２０のユーザとは異なるユーザのユーザアカウント（限定ではなく、第２アカウントの一例）は、自己の端末２０のユーザによる自己の端末２０に対する入力に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる端末に対する入力に基づいて第２アカウントを簡単に選択することができる。
また、本変形例は、自己の端末２０のユーザとは異なるユーザのユーザアカウント（限定ではなく、第２アカウントの一例）は、自己の端末２０のユーザによる、自己の端末２０のユーザと他のユーザ（限定ではなく、第１ユーザの一例）とを含むチャットルームの選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザと第１ユーザとを含むチャットルームの選択に基づいて第２アカウントを簡単に選択することができる。
また、本変形例は、端末２０が、送金要請情報（限定ではなく、第２アカウントに基づく決済の許可の依頼に関する情報の一例）を自己の端末２０とは異なる端末２０に通信Ｉ／Ｆ２２によって送信する。そして、決済に関する処理は、自己の端末２０のユーザとは異なるユーザ（限定ではなく、第１ユーザの一例）による、そのユーザのアカウント（限定ではなく、第２アカウントの一例）による決済の許可に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第１ユーザによる第２アカウントによる決済の許可がなされたことに基づいて決済を可能とすることができる。逆に、第１ユーザによる第２アカウントによる決済の許可がなされない場合は決済を不可とすることができる。
＜第４変形例（８）＞
第４変形例（７）では、加盟店での支払いにおいて、共通ウォレットの残高不足を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座から送金するよう依頼することで立て替えられた場合でも、立て替え分を自身が請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図４－２０～図４－２１は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図４－１９と同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、決済結果情報を表示させると（Ａ１８０）、立て替え分の精算を行うか否かの選択用画面を表示部２４に表示させる（Ａ３２０）。
精算を行うことが選択された場合（Ａ３２０：ＹＥＳ）、端末Ａの制御部２１は、端末Ａの記憶部２８に記憶された決済残高不足額を、通信Ｉ／Ｆ２２によってサーバ１０に送信した後（Ａ３３０）、Ａ４００に処理を移す。
一方、精算を行わないことが選択された場合（Ａ３２０：ＮＯ）、端末Ａの制御部２１は処理を終了する。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末Ａから受信した決済残高不足額が「０」より大きい場合（Ｓ２８０：ＹＥＳ）、決済残高不足額を立替者の端末２０（ここでは端末Ｂ）に送信する（Ｓ４００）。
通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足額を受信する場合（Ｂ１８０：ＹＥＳ）、端末Ｂの制御部２１は、端末ＢのユーザＢ．Ｂが立て替えた決済残高不足額分の電子マネーを、共通ウォレットの他のメンバーに請求するか否かの選択用画面を表示部２４に表示させる（Ｂ１９０）。
一方、決済残高不足額を受信しない場合（Ｂ１８０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
端末Ｂの入出力部２３に対するユーザ操作に基づいて、立替分を請求することが選択された場合（Ｂ１９０：ＹＥＳ）、端末Ｂの制御部２１は、精算請求情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ｂ２００）。
一方、立替分を請求しないことが選択された場合（Ｂ１９０：ＮＯ）、端末Ｂの制御部２１は、Ｂ２００をスキップして処理を進める。
通信Ｉ／Ｆ１４によって端末Ｂから精算請求情報を受信する場合（Ｓ４１０：ＹＥＳ）、サーバ１０の制御部１１は、Ｓ４２０～Ｓ４５０のステップを実行する。
なお、これらのステップは、送信先・受信元を端末Ａとし、図４－９のＳ２９０～Ｓ３２０と同様にして実行することが可能であるため、詳細については説明を省略する。
精算請求情報を受信しない場合（Ｓ４１０：ＮＯ）、サーバ１０の制御部１１は、Ｓ４６０のステップに処理を移す。
端末Ａの制御部２１は、支払い立替額請求情報を通信Ｉ／Ｆ２２によってサーバ１０から受信すると（Ａ４００：ＹＥＳ）、Ａ４１０～Ａ４４０のステップを実行する。
なお、これらのステップは、図４－９のＢ１１０～Ｂ１３０のステップと同様にして実行することが可能であるため、詳細については説明を省略する。
支払い立替額請求情報を受信しない場合（Ａ４００：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信し、Ａ３４０のステップを実行する。
最後にサーバ１０の制御部１１は、送金結果を含む精算結果情報を、通信Ｉ／Ｆ１４によって立替者であるユーザＢ．Ｂの端末Ｂと、精算を発案したユーザＡ．Ａの端末Ａとに送信し（Ｓ４６０）、処理を終了する。
また、通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信すると、端末Ｂの制御部２１は、精算結果情報を表示部２４に表示させ（Ｂ２１０）、処理を終了する。
端末Ａについても同様である（Ａ３４０）。
なお、上記の処理では、端末Ｂが、自己の端末２０のユーザ（ユーザＢ．Ｂ）のユーザアカウントから決済残高不足額分の電子マネーを立て替えることとしたが、これに限定されない。
限定ではなく例として、端末Ｂが、共通ウォレットメンバーであって、ユーザＡ．ＡおよびユーザＢ．Ｂ以外のユーザ（限定ではなく例として、端末ＣのユーザＣ．Ｃ）のユーザアカウントから決済残高不足額分の電子マネーを使用（消費）して決済を行うようにしてもよい。この場合、ユーザＢ．Ｂは、あらかじめユーザＣ．Ｃから許可を得ておくようにすればよい。
また、精算請求情報を送信した場合（Ｂ２００）、端末Ｂの制御部２１は、限定ではなく例として、立替分を請求したことを示す情報を端末Ｂの表示部２４に表示させるようにすることができる。
また、支払い立替額請求情報を受信した場合（Ａ４００：ＹＥＳ）、端末Ａの制御部２１は、立替分が請求されたことを示す情報を端末Ａの表示部２４に表示させるようにすることができる。
この場合、これらの情報は、支払いアプリケーションのアプリケーション画面に表示させてもよいが、これに代えて、前述したメッセージングアプリケーションのトークルーム画面に表示させるようにすることも可能である。これは、限定ではなく例として、図４－１６や図４－１７に示した画面に倣って同様に構成可能である。
本変形例は、第２の端末２０（請求先の端末２０）は、支払い立替額請求情報（限定ではなく、第２アカウントによる支払いに基づく金額の請求に関する請求情報の一例）を、サーバ１０を介して第１の端末２０（請求元の端末２０）から通信Ｉ／Ｆ２２によって受信する。そして、第２の端末２０は、受信された支払い立替額請求情報に基づく表示（限定ではなく、請求情報に基づく第１表示、第３表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、第２アカウントによる支払いに基づく金額の請求があったことやその内容を端末のユーザに知らせることができる。
また、本変形例は、第１の端末２０は、支払い立替額請求情報（限定ではなく、第２アカウントによる支払いに基づく金額の請求に関する請求情報の一例）を、サーバ１０を介して第２の端末２０に通信Ｉ／Ｆ２２によって送信する。そして、第１の端末２０は、送信された支払い立替額請求情報に基づく表示（限定ではなく、請求情報に基づく第２表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、第２アカウントによる支払いに基づく金額を請求した上で、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、第２の端末２０は、少なくとも第２の端末２０のユーザと、第１の端末２０のユーザ（限定ではなく、第１ユーザの一例）とが決済可能な共通アカウントと、第１の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントの一例）とに基づき、第１の端末２０（限定ではなく、第１端末の一例）によって決済に関する処理（限定ではなく、第１決済に関する処理の一例）が実行され、第１の端末２０のユーザによる決済（限定ではなく、第１決済の一例）に基づいて、支払い立替額請求情報（限定ではなく、第１決済に基づく金額の請求に関する請求情報の一例）を、サーバ１０を介して第１の端末２０から通信Ｉ／Ｆ２２によって受信する。そして、第２の端末２０は、受信された支払い立替額請求情報に基づく表示（限定ではなく、請求情報に基づく第１表示の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントと、共通アカウントとは異なる第１アカウントとに基づき、第１ユーザの第１端末によって第１決済に関する処理が実行されたことに基づき、第１決済に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、第１アカウントは、第１の端末２０のユーザ（限定ではなく、第１ユーザの一例）のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントと、第１ユーザのアカウントとに基づき、第１ユーザの第１端末によって第１決済に関する処理が実行されるようにすることができる。
また、本変形例は、支払い立替額請求情報は、第１の端末２０のユーザのユーザアカウントによって立て替えられた金額（限定ではなく、第１アカウントによって支払われた金額の一例）に基づき決定される。そして、第２の端末２０は、自己の端末２０のユーザのユーザアカウントから第１の端末２０のユーザのユーザアカウントに対する送金処理（限定ではなく、請求情報に基づく金額の送金に関する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１アカウントによって支払われた金額に基づき決定された請求情報に基づく金額を、端末のユーザのアカウントから第１アカウントに対して送金することができる。
また、本変形例は、支払い立替額請求情報は、共通ウォレットメンバー（限定ではなく、共通アカウントによって決済可能なユーザの一例）に基づいて金額が決定される構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザに基づいて決定された請求情報に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、端末２０が、共通ウォレットメンバーとメッセージ等（限定ではなく、コンテンツの一例）の送受信が可能なトークルーム（限定ではなく、チャットルームの一例）に支払い立替額請求情報を表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザとコンテンツの送受信が可能なチャットルームへの表示という分かり易い形で、請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、送金ボタン等（限定ではなく、送金情報の一例）に対する操作（限定ではなく、送金情報に対するユーザの入力の一例）に基づいて、支払い立替額請求情報に基づく送金処理が実行される構成を示している。
このような構成により得られる効果の一例として、請求情報に基づく送金を行うための送金情報に対するユーザの入力に基づいて、簡単に送金を実現することができる。
また、本変形例は、支払い立替額請求情報に基づく表示は、第１の端末２０のユーザの情報を含む構成を示している。
このような構成により得られる効果の一例として、第１アカウントのユーザの情報を端末のユーザに知らせることができる。
また、本変形例は、共通アカウントと、第２の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とに基づき、決済に関する処理（限定ではなく、第２決済に関する処理の一例）が実行される。そして、第２の端末２０は、第１の端末２０のユーザによる決済（限定ではなく、第１決済の一例）と、第２の端末２０のユーザによる決済（限定ではなく、第２決済の一例）とに基づく支払い立替額請求情報を、サーバ１０を介して通信Ｉ／Ｆ２２によって第１の端末２０から受信する。そして、第２の端末２０は、自己の端末２０のユーザのユーザアカウントから第１の端末２０のユーザのユーザアカウントに対する送金処理（限定ではなく、請求情報に基づく金額の送金に関する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、共通アカウントとは異なる第２アカウントとに基づき、第２決済に関する処理が実行され、第１決済と第２決済とに基づく請求を受けて、端末のユーザのアカウントから第１アカウントに対して送金することができる。
また、本変形例は、支払い立替額請求情報（限定ではなく、第１決済に基づく金額の請求に関する請求情報の一例）は、サーバ１０（限定ではなく、第１決済に関する処理を実行するサーバの一例）から送信される構成を示している。
このような構成により得られる効果の一例として、第１決済に関する処理を実行するサーバから請求情報を簡単に取得することができる。
また、本変形例は、第１アカウントは、共通アカウントによって決済可能な、第２の端末２０のユーザ（限定ではなく、第１ユーザの一例）とは異なるユーザのユーザアカウント（限定ではなく、第１ユーザとは異なるユーザの一例）のユーザアカウントである構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントと、共通アカウントによって決済可能な、第１ユーザとは異なるユーザのアカウントとに基づき、第１ユーザの第１端末によって第１決済に関する処理が実行されたことに基づき、第１決済に基づく金額の請求を受けて、その請求に関する情報を端末のユーザに知らせることができる。
また、本変形例は、サーバ１０が、少なくとも第２の端末２０のユーザ（限定ではなく、端末のユーザの一例）と、第１の端末２０のユーザ（限定ではなく、第１ユーザの一例）とが決済可能な共通アカウントと、第１の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントの一例）とに基づき、決済処理（限定ではなく、第１決済に関する処理の一例）を制御部１１によって実行する。そして、サーバ１０は、この決済（限定ではなく、第１決済の一例）に基づいて、支払い立替額請求情報（限定ではなく、第１決済に基づく金額の請求に関する請求情報の一例）を第２の端末２０に通信Ｉ／Ｆ１４によって送信する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントと、共通アカウントとは異なる第１アカウントとに基づき、第１決済に関する処理を実行して決済を実現することができる。また、第１決済に基づく金額を端末のユーザに請求することができる。
＜第４変形例（９）＞
上記の実施例では、端末２０の表示部２４に表示された支払いコードが店舗コードリーダ装置５０によって読み取られることに基づき、または支払い店舗コードが端末２０で読み取られることに基づいて決済が実現された。つまり、上記の実施例では、コード決済を行う手法を示したが、これに限定されない。コード決済に代えて、無線通信（近距離無線通信を含む。）によって決済を行うようにすることもできる。
図４－２２は、本変形例における店舗コードリーダ装置５０の構成例を示す図である。
店舗コードリーダ装置５０は、図１－２の構成の他に、限定ではなく例として、近距離無線通信Ｉ／Ｆ５８１を備える。
近距離無線通信Ｉ／Ｆ５８１は、端末２０との間で近距離無線通信を行うためのインタフェースである。
ここで、近距離無線通信には、限定ではなく例として、いわゆる非接触式の近距離通信（以下、「非接触式通信」と称する。）や、ブルートゥースを利用した近距離通信（以下、「ブルートゥース通信」と称する。）等が含まれる。
非接触式通信を適用する場合、近距離無線通信Ｉ／Ｆ５８１には、限定ではなく例として、端末２０に備えられるＮＦＣチップ等の非接触型ＩＣカードに記憶された情報を読み取るためのカードリーダや、情報を読み取る／情報を書き込むためのカードリーダライタを含めることができる。この場合、上記の実施例におけるコード決済（利用者提示型または店舗提示型）に代えて、端末２０のユーザが、自己の端末２０を店舗のカードリーダやカードリーダライタにかざすことによって、上記の実施例と同様に決済を行うようにすることができる。
この場合、カードリーダで情報を読み取った結果、共通ウォレット残高（第１アカウントの残高）が不足している場合、サーバ１０の制御部１１は、限定ではなく例として、共通ウォレット残高が不足していることを示す情報（決済残高不足情報）を、通信Ｉ／Ｆ１４によって端末２０に送信する。通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると、端末２０の制御部２１は、決済残高不足情報を表示部２４に表示させる。そして、表示した決済残高不足情報に対する自己の端末２０のユーザの入力に基づいて、限定ではなく例として、決済を行うアカウントを、共通アカウントから自己の端末２０のユーザのユーザアカウント（第２アカウント）に変更・設定する。そして、端末２０のユーザが、自己の端末２０を店舗のカードリーダに再度かざすことによって、決済を行うようにすることができる。
なお、カードリーダで情報を読み取った結果、共通ウォレット残高（第１アカウントの残高）が不足している場合は、限定ではなく例として、共通ウォレット残高が不足していることを示す情報をカードリーダライタによって端末２０の非接触型ＩＣカードに書き込むようにしてもよいし、そうしなくてもよい。これを受けて、端末２０の制御部２１は、決済残高不足情報を表示部２４に表示させ、表示した決済残高不足情報に対する自己の端末２０のユーザの入力に基づいて、限定ではなく例として、決済を行うアカウントを、共通アカウントから自己の端末２０のユーザのユーザアカウント（第２アカウント）に変更・設定するようにしてもよいし、そうしなくてもよい。そして、端末２０のユーザが、自己の端末２０を店舗のカードリーダに再度かざすことによって、決済を行うようにすることができるようにしてもよいし、そうしなくてもよい。
また、ブルートゥース通信を適用する場合、近距離無線通信Ｉ／Ｆ５８１は、端末２０との間でブルートゥース通信を行うためのブルートゥース通信用のモジュール等が含まれる。この場合も、通信方式を非接触式通信に代えてブルートゥース通信とすることによって、上記と同様の手法で決済を行うようにすることができる。
本変形例は、決済に関する処理は、通信Ｉ／Ｆ２２（限定ではなく、端末の通信部の一例）による、店舗コードリーダ装置５０（限定ではなく、第１決済によって購入する商品を販売するまたはサービスを提供する店舗の端末の一例）との無線通信により実行される構成を示している。
このような構成により得られる効果の一例として、端末の通信部によって、第１決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を行うことによって、簡単に決済を実現することができる。
また、本変形例は、上記の無線通信は、非接触式通信やブルートゥース通信（限定ではなく、近距離通信の一例）である構成を示している。
このような構成により得られる効果の一例として、第１決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を近距離通信によって実現することができる。
＜第５実施例＞
第５実施例は、端末２０（限定ではなく例として端末Ａ）が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行する、または共通ウォレット残高と端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）の電子マネー口座残高とを合算する一時的な支払い用アカウント（以下、「統合アカウント」と称する。）の電子マネー残高から実行する実施例である。
第５実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜データ構成＞
図５－１は、本実施例においてサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、支払いアプリケーション管理処理プログラム１５１と、支払いアプリケーションユーザ登録データ１５３と、ユーザ管理データベース１５５と、共通ウォレット管理データベース１５７との他に、限定ではなく例として、統合アカウント管理データベース１５９が記憶される。
統合アカウント管理データベース１５９は、サーバ１０が統合アカウントを管理するためのデータベースであり、そのデータ構成の一例を図５－２に示す。
統合アカウント管理データベース１５９には、統合アカウントごとの管理データとして、統合アカウント管理データが記憶される。
各々の統合アカウント管理データには、限定ではなく例として、その統合アカウントを識別するための識別情報の一例である統合アカウントＩＤと、その統合アカウントに含まれるユーザのアカウントを示す統合アカウントメンバーＩＤとが記憶される。統合アカウントメンバーＩＤには、統合アカウントに統合されている支払いアプリケーションのアカウント（ユーザの支払いアプリケーションＩＤや共通ウォレットＩＤ等を含む。）が記憶される。
図５－２では、限定ではなく例として、「ＵＮ０００１」で識別される統合アカウントは、「Ｕ０００１」（すなわちユーザＡ．Ａ）と、「Ｓ０００１」（すなわち共通ウォレット「キャンプ資金」）とで構成されることが示されている。
＜表示画面例＞
図５－３は、図３－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されているコード支払い画面（統合前）の一例を示す図である。
図５－３の画面は、図３－４の画面とほぼ同様であるが、キャンプ資金コード支払い領域２４２１内の一部の表示が異なっている。
図３－４のキャンプ資金コード支払い領域２４２１内では、チェックマークボタンＣＮ２とともに「自分のウォレットから送金」の文字が表示され、その横に残高（この例では「２５，０００円」）が表示されていたが、図５－３のキャンプ資金コード支払い領域２４２１内では、キャンプ資金の共通ウォレットを自分のウォレットと統合するための情報として、「自分のウォレットと統合」の文字とともに、統合を実行するか否かを選択するための（切り替えるための）スライドボタンＣＮ７が配置されている。また、その下には、新たに「自分のウォレット」という文字が表示されおり、その横に自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。
スライドボタンＣＮ７は、長円とこの長円内に丸を有する画像となっており、長円内左端に丸が位置する状態（この例では「ＯＦＦ」）がデフォルトとなっており、限定ではなく例として、丸をタッチ操作またはスライド操作することで、長円内右端に丸が位置する状態（この例では「ＯＮ」）に変化するとともに、長円内の色が反転表示される。
図５－４は、図５－３のコード支払い画面（統合前）において、スライドボタンＣＮ７が操作された場合に表示されるコード情報更新中画面の一例を示す図である。
図５－４が図５－３と異なるのは、キャンプ資金コード支払い領域２４２１内のスライドボタンＣＮ７が「ＯＮ」の状態となっており、キャンプ資金コード支払い領域２４２１に、コード情報を更新中であることを示す更新中情報ＣＪＫが重畳表示されていることである。更新中情報ＣＪＫには、中央にコード情報更新中を示す２つの回転する矢印が表示されているとともに、その下に「コード情報更新中…」の文字が表示されている。
図５－５は、図５－４の支払いコード情報更新中画面が更新された場合に表示されるコード支払い画面（統合後）の一例を示す図である。
つまり、キャンプ資金コード支払い領域２４２１内の上部には、財布の画像および共通ウォレットの名称（キャンプ資金）と、加算を示す「＋」と、財布の画像および自分のウォレットとの文字が表示されるとともに、共通ウォレット（キャンプ資金）と自分のウォレットとが加算されて統合された統合後の残高（この例では「２６，０００円」）が表示されている。
また、図５－５のキャンプ資金コード支払い領域２４２１内に表示される支払いコードは、アカウントが統合されたことによって、図５－３の支払いコードとは異なるコードとなっている。
端末２０のユーザＡ．Ａは、前述したように、上記のコード支払い画面をコードレジで店舗の店員に提示し、店舗コードリーダ装置で支払いコードを読み取ってもらうことでコード支払いを行う。サーバ１０による決済処理が完了すると、図３－７と同様のコード支払い完了画面が表示される。
＜処理＞
図５－６～図５－７は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
端末Ａの制御部２１は、限定ではなく例として、端末ＡのユーザＡ．Ａの電子マネー口座残高を、表示部２４に加えて表示させると（Ａ１３０）、ユーザＡ．Ａの電子マネー口座残高と、共通ウォレット残高を合算する統合アカウントによる支払いを実行するか否かの選択機能を持つボタンを表示部２４に加えて表示させる（Ａ４５０ａ）。
端末Ａの入出力部２３に対するユーザ操作に基づいて、統合アカウントによる支払いを実行することが選択された場合（Ａ４５０ａ：ＹＥＳ）、端末Ａの制御部２１は、アカウント統合依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ４６０）。
統合アカウントによる支払いを実行することが選択されない場合（Ａ４５０ａ：ＮＯ）、端末Ａの制御部２１は、決済結果情報を通信Ｉ／Ｆ２２によってサーバ１０から受信し、図１－９のＡ１８０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａからアカウント統合依頼情報を受信する場合（Ｓ４７０ａ：ＹＥＳ）、サーバ１０の制御部１１は、アカウント統合処理を実行する（Ｓ４８０）。
アカウント統合依頼情報を受信しない場合には（Ｓ４７０ａ：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を店舗コードリーダ装置５０から受信し、図１－９のＳ１７０ａのステップを実行する。
アカウント統合処理では、サーバ１０の制御部１１は、統合アカウント管理データベース１５９に、ユニークな統合アカウントＩＤを持つ統合アカウント管理データのレコードを追加し、そのレコードの統合アカウントメンバーＩＤに、ユーザＡ．Ａの支払いアプリケーションＩＤと、共通ウォレットの共通ウォレットＩＤを記憶させる。
そして、サーバ１０の制御部１１は、統合アカウントＩＤに紐づけられる統合アカウントの残高から支払いを認可する支払いトークンを生成する。以下では、このトークンを「統合アカウント支払いトークン」と称する。
ここで、統合アカウントの残高とは、統合アカウントメンバーＩＤに記憶されている支払いアプリケーションＩＤおよび共通ウォレットＩＤと関連する電子マネーの残高の合計額となる。
また、統合アカウント支払いトークンは、共通ウォレット支払いトークンと同様に、限定ではなく例として、所定桁数（限定ではなく例として１２桁）の整数値によって識別される。統合アカウント支払いトークンは有効期限を持つトークンとしてもよいし、そうしなくてもよい。
アカウント統合処理によって統合アカウント支払いトークンが生成されると、サーバ１０の制御部１１は、統合アカウント支払いトークンを含むコード情報である統合アカウントコード情報を生成する。統合アカウントコード情報には、限定ではなく例として、統合アカウント支払いトークンの識別子を一次元コード（バーコード）や二次元コード（ＱＲコード）としてエンコードした支払いコード（画像情報）を含む。
なお、統合アカウント支払いトークンが有効期限を持つ場合、統合アカウントコード情報には、その有効期限を含んでもよい。
そして、サーバ１０の制御部１１は、統合アカウントコード情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ４９０ａ）。
なお、通信Ｉ／Ｆ１４によって端末Ａからアカウント統合依頼情報を受信しない場合（Ｓ４７０ａ：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信し、図１－９のＳ１７０ａのステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から統合アカウントコード情報を受信すると、端末Ａの制御部２１は、受信した統合アカウントコード情報に基づいて、支払いコードを表示部２４に更新して表示させる（Ａ４７０ａ）。
なお、統合アカウントコード情報に統合アカウント支払いトークンの識別子や有効期限を含む場合、端末Ａの制御部２１は、識別子や有効期限を更新して表示させてもよい。
店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示される支払いコードを読み取る（Ｐ１４０）。この場合、表示部２４に表示される支払いコードは、統合アカウント支払いトークンと関連付けられているため、コードリーダ５８の読み取り結果には、支払いトークンとして統合アカウント支払いトークンが含まれる。
店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、支払いトークン（この場合には統合アカウント支払いトークン）とを含む決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１５０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、統合アカウント決済処理を実行する（Ｓ５００ａ）。
統合アカウント決済処理では、サーバ１０の制御部１１は、要求を受けた統合アカウント支払いトークンから統合アカウントＩＤを検索する。サーバ１０の制御部１１は、さらに統合アカウントＩＤに紐づけられる統合アカウントメンバーＩＤ（ここではユーザＡ．Ａの支払いアプリケーションＩＤと、共通ウォレットの共通ウォレットＩＤ）に基づいて、統合アカウントメンバーＩＤで指し示されるユーザＡ．Ａの電子マネー口座残高と共通ウォレット残高との合計額を用いて、統合アカウントに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する。
統合アカウントでの決済が成功する場合には、サーバ１０の制御部１１は、共通ウォレット残高を決済予定金額だけ減少させる。もし共通ウォレット残高が決済予定金額に満たない場合には、共通ウォレット残高を「０」まで減少させ、不足分をユーザＡ．Ａの電子マネー口座残高から差し引く。
なお、統合アカウントでの決済が成功する場合には、サーバ１０の制御部１１は、ユーザＡ．Ａの電子マネー口座残高を決済予定金額だけ減少させ、もしユーザＡ．Ａの電子マネー口座残高が決済予定金額に満たない場合には、ユーザＡ．Ａの電子マネー口座残高を「０」まで減少させ、不足分を共通ウォレット残高から差し引くようにしてもよいし、しなくてもよい。
次いで、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウント残高とを含む決済結果情報を、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信する（Ｓ５１０）。
また、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウントを構成する電子マネー口座・共通ウォレット残高と、電子マネー口座・共通ウォレットでの支払い額とを含む統合アカウント決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａに送信し（Ｓ５２０）、処理を終了する。
通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信すると、店舗コードリーダ装置５０の制御部５１は、決済結果情報を表示部５３に表示させ（Ｐ１６０）、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信すると、端末Ａの制御部２１は、統合アカウント決済結果情報を表示部２４に表示させ（Ａ４８０）、処理を終了する。
＜統合アカウント支払いトークンとコード情報との関係＞
前述したように、統合アカウント支払いトークンは、限定ではなく例として、統合アカウントＩＤに関連付けられる（紐付けられる）統合アカウントの残高から支払いを認可する支払いトークンである。つまり、統合アカウント支払いトークンには、統合アカウントＩＤが関連付けられている。そして、この統合アカウント支払いトークンがエンコードされたコード情報が統合アカウントコード情報である。
また、統合アカウントＩＤには、統合アカウントメンバーＩＤとして、限定ではなく例として、統合対象の支払いアプリケーションＩＤと、共通ウォレットの共通ウォレットＩＤとが関連付けられている。
これらのことから、統合アカウントコード情報（限定ではなく、第１コード情報の一例）には、統合対象の支払いアプリケーションＩＤ（限定ではなく、第２アカウントに関する情報の一例）と、共通ウォレットＩＤ（限定ではなく、共通アカウントに関する情報の一例）とが含まれる、または関連付けられていると言える。
＜第５実施例の効果＞
第５実施例は、端末２０が、共通ウォレット残高に基づいて決済に関する処理を実行する。また、共通ウォレット残高には、自己の端末２０のユーザのユーザアカウントから送金可能である構成を示している。
このような構成により、限定ではなく例として、第３実施例や第４実施例と同様の効果を得ることができる。
また、第５実施例は、端末２０が、自己の端末２０のユーザのユーザアカウント情報（限定ではなく、第２アカウント情報の一例）に対する入力に基づいて、このユーザアカウント情報と、共通アカウントとが関連付けられた統合アカウントコード情報（限定ではなく、第１コード情報の一例）を表示部２４に表示する。そして、端末２０は、統合アカウントコード情報が読み取られることに基づいて、決済に関する処理を実行する構成を示している。
このような構成により得られる効果の一例として、第２アカウント情報に対する入力に基づいて、第２アカウントと、共通アカウントとが関連付けられた第１コード情報を端末の表示領域に表示して決済に利用させることができる。また、第１コード情報が読み取られることに基づいて、簡単に決済を実現することができる。
また、第５実施例は、端末２０が、共通アカウントが関連付けられた共通ウォレットコード情報（限定ではなく、第１コード情報の一例）と、自己の端末２０のユーザのユーザアカウント情報（限定ではなく、第２アカウント情報の一例）とを表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザのユーザアカウント情報に対する入力に基づいて、このユーザアカウント情報と、共通アカウントとが関連付けられた統合アカウントコード情報（限定ではなく、第２コード情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントが関連付けられた第１コード情報を端末の表示領域に表示して決済に利用させることができるとともに、第２アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する入力に基づいて、第２アカウントと、共通アカウントとが関連付けられた第２コード情報を端末の表示領域に表示して決済に利用させることができる。
また、第５実施例は、共通ウォレットコード情報（限定ではなく、第１コード情報の一例）と、統合アカウントコード情報（限定ではなく、第２コード情報の一例）とは、サーバ１０（限定ではなく、第１決済に関する処理を実行するサーバの一例）から端末２０に送信される構成を示している。
このような構成により得られる効果の一例として、第１コード情報と第２コード情報とを外部から簡単に取得することができる。
また、第５実施例は、端末２０が、共通ウォレット残高（限定ではなく、共通アカウントに関連付けられた第１電子貨幣の金額の一例）の情報と、ユーザアカウントの電子マネー口座残高（限定ではなく、第２アカウントに関連付けられた第２電子貨幣の金額）とが加算された統合アカウントの残高の情報と、統合アカウントコード情報（限定ではなく、第２コード情報の一例）とを表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第１電子貨幣の金額と、第２アカウントに関連づけられた第２電子貨幣の金額との加算金額を端末のユーザに知らせることできる。また、第２コード情報を端末の表示領域に表示して決済に利用させることができる。
＜第５変形例（１）＞
第５実施例では、統合アカウントコード情報を受信すると、端末Ａの制御部２１は、統合アカウントコード情報を表示部２４に更新して表示させることとしたが、支払いコードを更新しなくてもよい。
この場合には、限定ではなく例として、サーバ１０の制御部１１は、図５－６のＳ４８０において、図５－６のＳ１００ａで生成した共通ウォレット支払いトークンを削除（無効化）する。そして、図５－６のＳ１００ａで生成した共通ウォレット支払いトークンと同一の識別子を持つ統合アカウント支払いトークンを生成すればよい。
＜第５変形例（２）＞
第５実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
＜表示画面例＞
図５－８は、図３－３のキャンプ資金支払い画面において「コードリーダ」のアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコードリーダ画面（統合前）の一例を示す図である。
図５－８では、タイトルバーの下に、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、コード読み取り領域ＣＲ１が表示され、ユーザに対する操作案内として「コードリーダ」が表示され、その下には、キャンプ資金コード支払い領域２４２３が表示されている。
キャンプ資金コード支払い領域２４２３の上部には、図３－４と同様に、角財布の画像および共通ウォレットの名称（キャンプ資金）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。その下には、「自分のウォレットと統合」の文字が表示され、その横にスライドボタンＣＮ７が配置されている。また、その下に、「自分のウォレット」の文字が表示されているとともに、その横に残高（この例では「２５，０００円」）が表示されている。
図５－９は、図５－８のコードリーダ画面（統合前）においてスライドボタンＣＮ７がタッチ操作された場合に表示される支払いコード情報更新中画面の一例を示す図である。
この例では、スライドボタンＣＮ７がタッチ操作等されて「ＯＮ」の状態（長円内を丸が右端に移動して反転表示された状態）となっている。また、図５－４と同様に、更新中情報ＣＪＫがポップアップ形式で表示されている。
図５－１０は、図５－９の支払いコード情報更新中画面が更新された場合に表示されるコードリーダ画面（統合後）の一例を示す図である。
この画面では、図５－９の画面においてポップアップ形式で表示されていた更新中情報ＣＪＫが、アカウントの統合（コード情報の更新）が完了することで消去されている。また、キャンプ資金コード支払い領域２４２３内の上部には、共通ウォレットと自分のウォレットとが統合されたことを示す情報として、角財布の画像およびキャンプ資金の文字と、がま口財布の画像および自分のウォレットの文字とを「＋」で結合した情報が表示されている。また、この情報と関連付けて、ウォレットの統合によって合算された残高（この例では「２６，０００円」）が表示されている。
図５－１０に示すコードリーダ画面で支払い店舗コードの読み取りが完了し、図３－１１に示す支払い金額の入力が完了してサーバ１０による決済処理が完了すると、図３－７と同様のコード支払い完了画面が表示される。
＜処理＞
図５－１１～図５－１２は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
端末Ａの制御部２１は、ユーザアカウント情報を表示部２４に表示させると（Ａ１３０）、ユーザＡ．Ａの電子マネー口座残高と、共通ウォレット残高を合算する統合アカウントによる支払いを実行するか否かの選択機能を持つボタンを表示部２４に加えて表示させる（Ａ４５０ｂ）。
端末Ａの入出力部２３に対するユーザ操作に基づいて、統合アカウントによる支払いを実行することが選択された場合（Ａ４５０ｂ：ＹＥＳ）、端末Ａの制御部２１は、Ａ４６０のステップを実行する。
統合アカウントによる支払いを実行することが選択されない場合（Ａ４５０ｂ：ＮＯ）、端末Ａの制御部２１は、図１－１１のＡ１９０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａからアカウント統合依頼情報を受信する場合（Ｓ４７０ｂ：ＹＥＳ）、サーバ１０の制御部１１は、アカウント統合処理を実行する（Ｓ４８０）。
アカウント統合依頼情報を受信しない場合には（Ｓ４７０ｂ：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を端末Ａから受信し、図１－１１のＳ１７０ｂのステップを実行する。
サーバ１０の制御部１１は、Ｓ４８０のステップを実行すると、生成された統合アカウント支払いトークンを含むコード読み取り用情報である統合アカウントコードリーダ情報を生成する。そして、サーバ１０の制御部１１は、統合アカウントコードリーダ情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ４９０ｂ）。
通信Ｉ／Ｆ２２によってサーバ１０から統合アカウントコードリーダ情報を受信すると、端末Ａの制御部２１は、受信された統合アカウントコードリーダ情報に基づいて、支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示させ、コードを読み取るためにカメラ２７を起動させる（Ａ４７０ｂ）。そして端末Ａの制御部２１は、Ａ１９０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、サーバ１０の制御部１１は、統合アカウント店舗提示型決済処理を実行する（Ｓ５００ｂ）。
統合アカウント店舗提示型決済処理は、統合アカウント決済処理と同様に実行することが可能であるため、詳細な説明は省略する。
そしてサーバ１０の制御部１１は、Ｓ５２０のステップを実行し、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信すると、端末Ａの制御部２１は、Ａ４８０のステップを実行し、処理を終了する。
本変形例は、端末２０は、自己の端末２０のユーザのユーザアカウント情報（限定ではなく、第２アカウント情報の一例）に対する入力に基づいて、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０は、コードリーダ画面が表示部２４に表示された端末２０によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第２アカウント情報に対する入力に基づいて、第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第１コードリーダ情報が表示領域に表示された端末によってコード情報を読み取ることに基づいて、簡単に決済を実現することができる。
また、本変形例は、端末２０が、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザのユーザアカウント情報（限定ではなく、第２アカウント情報の一例）に対する入力に基づいて、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第２コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０は、コードリーダ画面が表示部２４に表示された端末２０によって支払い店舗コードを読み取ることに基づいて、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができるとともに、第２アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する入力に基づいて、第２コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、本変形例は、端末２０が、共通ウォレット残高（限定ではなく、共通アカウントに関連付けられた第１電子貨幣の金額の一例）の情報と、ユーザアカウントの電子マネー口座残高（限定ではなく、第２アカウントに関連付けられた第２電子貨幣の金額）とが加算された統合アカウントの残高の情報と、統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第２コードリーダ情報の一例）とを表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに関連づけられた第１電子貨幣の金額と、第２アカウントに関連づけられた第２電子貨幣の金額との加算金額を端末のユーザに知らせることできる。また、第２コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
＜第５変形例（３）＞
第５実施例では、アカウント統合処理において複数のアカウントは単一のコードに紐づけられるとしていたが、そのようにしなくてもよい。限定ではなく例として、複数の支払いコードを端末に表示させ、それらのコードを用いて決済を行ってもよい。
なお、複数のコードを用いて決済を行う場合には、決済可能な最大金額は複数のコードに紐づけられる複数のアカウントの電子マネー口座残高の合計額とする。
以下では、このような支払い方法を「アカウント並列使用」と称する。
＜表示画面例＞
図５－１３は、コード支払い画面の別例を示す図である。
図５－１３では、図５－５とは異なり、バーコードで表される一次元の支払いコードと、同じくバーコードで表される一次元の支払いコードとの２つの支払いコードが上下に並べて表示されている。
上の支払いコードは、限定ではなく例として、ユーザＡ．Ａの支払いアプリケーションＩＤに紐づけられる電子マネー口座残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークン（後述する第１並列支払いトークン）が格納された第１並列コード情報である。
それに対し、下の支払いコードは、限定ではなく例として、共通ウォレットＩＤに紐づけられる共通ウォレット残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークン（後述する第２並列支払いトークン）が格納された第２並列コード情報である。
なお、第１並列コード情報および第２並列コード情報の表示位置やその並びは、自由に設定変更することが可能である。
また、第１並列コード情報および第２並列コード情報を、上記のように一次元の支払いコードとするのではなく、ＱＲコード等で表される二次元の支払いコードとすることもできる。
＜処理＞
図５－１４～図５－１５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、ユーザＡ．Ａの電子マネー口座と、共通ウォレットとを用いるアカウント並列使用による支払いを実行するか否かの選択機能を持つボタンを表示部２４に加えて表示させる（Ａ４９０）。
端末Ａの入出力部２３に対するユーザ操作に基づいて、アカウント並列使用による支払いを実行することが選択された場合（Ａ４９０：ＹＥＳ）、端末Ａの制御部２１は、アカウント並列使用依頼情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５００）。
アカウント並列使用による支払いを実行することが選択されない場合（Ａ４９０：ＮＯ）、端末Ａの制御部２１は、決済結果情報を通信Ｉ／Ｆ２２によってサーバ１０から受信し、図１－９のＡ１８０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａからアカウント並列使用依頼情報を受信する場合（Ｓ５３０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント並列使用処理を実行する（Ｓ５４０）。
アカウント並列使用依頼情報を受信しない場合には（Ｓ５３０：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を店舗コードリーダ装置５０から受信し、図１－９のＳ１７０ａのステップを実行する。
アカウント並列使用処理では、サーバ１０の制御部１１は、まずユーザＡ．Ａの支払いアプリケーションＩＤに紐づけられる電子マネー口座残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークンを生成する。以下では、この支払いトークンを「第１並列支払いトークン」とする。
また、サーバ１０の制御部１１は、共通ウォレットＩＤに紐づけられる共通ウォレット残高から支払いを認可し、アカウント並列使用を選択するフラグを含む支払いトークンを生成する。以下では、この支払いトークンを「第２並列支払いトークン」とする。
第１並列支払いトークン・第２並列支払いトークンは、限定ではなく例として、所定桁数（限定ではなく例として１２桁）の整数値によって識別される。これらのトークンは有効期限を持つトークンとしてもよいし、そうしなくてもよい。
そして、サーバ１０の制御部１１は、第１並列支払いトークンを含むコード情報である第１並列コード情報と、第２並列支払いトークンを含むコード情報である第２並列コード情報とを生成する。
第１並列コード情報・第２並列コード情報には、限定ではなく例として、各々のトークンの識別子を一次元コード（バーコード）や二次元コード（ＱＲコード）としてエンコードした支払いコード（画像情報）を含む。
なお、第１並列支払いトークン・第２並列支払いトークンが有効期限を持つ場合、これらのコード情報には、その有効期限を含んでもよい。
サーバ１０の制御部１１は、第１並列コード情報を通信Ｉ／Ｆ１４によって端末Ａに送信すると（Ｓ５５０）、第２並列コード情報を通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ５６０）。
通信Ｉ／Ｆ２２によって第１並列コード情報と第２並列コード情報とを受信すると、端末Ａの制御部２１は、第１並列コード情報と第２並列コード情報とを表示部２４に並べて表示させる（Ａ５１０）。
店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示される支払いコードをひとつ読み取る（Ｐ１４０）。そして、店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、支払いトークン（この場合には第１並列支払いトークンまたは第２並列支払いトークン）とを含む決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１５０）。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、受信した第１並列支払いトークンまたは第２並列支払いトークンからアカウント並列使用を選択するフラグを検出する。すると、サーバ１０の制御部１１は、アカウント並列使用処理で生成されたもう一方の支払いトークンを要求するために、他コード読み込み依頼情報を、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信する（Ｓ５７０）。
通信Ｉ／Ｆ５４によってサーバ１０から他コード読み込み依頼情報を受信すると、店舗コードリーダ装置５０の制御部５１は、もう一方の支払いコードを読み取ることを促す画面を表示部５３に表示させる（Ｐ１７０）。
店舗コードリーダ装置５０の制御部５１は、コードリーダ５８を用いて、端末Ａの表示部２４に表示されるもう一方の支払いコードを読み取る（Ｐ１８０）。そして、店舗コードリーダ装置５０の制御部５１は、限定ではなく例として、店舗ＩＤと、決済予定金額と、支払いトークン（この場合には第１並列支払いトークンまたは第２並列支払いトークンのうちＰ１５０で送信していないトークン）とを含む第２決済要求情報を通信Ｉ／Ｆ５４によってサーバ１０に送信する（Ｐ１９０）。
通信Ｉ／Ｆ１４によって端末Ａから第２決済要求情報を受信すると、サーバ１０の制御部１１は、アカウント並列決済処理を実行する（Ｓ５８０）。
アカウント並列決済処理は、第１並列支払いトークンに紐づけられるユーザＡ．Ａの電子マネー口座と、第２並列支払いトークンに紐づけられる共通ウォレットとによる統合アカウントによる支払いとみなすことで、統合アカウント決済処理と同様に実行することが可能であるため、詳細な説明は省略する。
そして、サーバ１０の制御部１１は、Ｓ５９０、Ｓ６００のステップを実行し、処理を終了する。また、通信Ｉ／Ｆ２２によってサーバ１０からアカウント並列決済結果情報を受信すると、端末Ａの制御部２１は、Ａ５２０のステップを実行し、処理を終了する。
なお、Ｓ５９０、Ｓ６００、Ａ５２０の各ステップについては、アカウント並列決済処理と同様の統合アカウントによる支払いとみなすことで、Ｓ５１０、Ｓ５２０、Ａ４８０の各ステップと同様に実行することが可能であるため、再度の説明は省略する。
＜第５変形例（４）＞
第５実施例では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
図５－１６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図５－６、図５－７と同一の処理で実現可能であるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ４８０のステップを実行すると、立て替え分の精算を行うか否かの選択用画面を表示部２４に表示させる（Ａ５３０）
なお、Ａ４８０のステップで用いられる統合アカウント決済結果情報において、ユーザＡ．Ａの電子マネー口座からの支払い額が「０」である、または決済が失敗している場合には、精算を行う必要がない（Ａ５３０：ＮＯ）ため、選択用画面を表示部２４に表示させず、処理を終了してもよいし、しなくてもよい。また、ユーザＡ．Ａの電子マネー口座からの支払い額が「０」より大きく、かつ決済が成功している場合には、選択用画面を表示部２４に表示させず、自動的に精算を行う（Ａ５３０：ＹＥＳ）ようにしてもよいし、しなくてもよい。
端末Ａの入出力部２３に対するユーザ操作に基づいて、精算を行うことが選択された場合（Ａ５３０：ＹＥＳ）、端末Ａの制御部２１は、統合アカウント決済結果情報に含まれるユーザＡ．Ａの電子マネー口座からの支払い額を含むユーザアカウント決済額請求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５４０）。
そして、通信Ｉ／Ｆ２２によってサーバ１０から精算結果情報を受信すると、端末Ａの制御部２１は、Ａ３４０のステップを実行して、処理を終了する。
なお、精算を行わないことが選択された場合（Ａ５３０：ＮＯ）、端末Ａの制御部２１は処理を終了する。
サーバ１０の制御部１１は、統合アカウント決済結果情報を送信し（Ｓ５２０）、通信Ｉ／Ｆ１４によって端末Ａからユーザアカウント決済額請求情報を受信すると（Ｓ６１０：ＹＥＳ）、ユーザアカウント決済額請求情報に含まれるユーザＡ．Ａの電子マネー口座からの支払い額を決済残高不足額として、Ｓ２９０～Ｓ３３０までのステップを実行する。
ユーザアカウント決済額請求情報を受信しない場合には（Ｓ６１０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
端末Ｂの制御部２１は、支払い立替額請求情報を通信Ｉ／Ｆ２２によってサーバ１０から受信すると（Ｂ１００：ＹＥＳ）、Ｂ１１０～Ｂ１３０のステップを実行する。支払い立替額請求情報を受信しない場合には（Ｂ１００：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
＜第５変形例（５）＞
第５実施例では、支払い開始時におけるユーザＡ．Ａの電子マネー口座の残高と、共通ウォレット残高とを加算する金額を統合アカウントの残高（統合アカウントによる支払いが可能な金額）としていたが、それに限定されない。
限定ではなく例として、共通ウォレットとユーザＡ．Ａの電子マネー口座とを統合する前に、ユーザＡ．Ａによってあらかじめ登録される外部金融機関の口座から、ユーザＡ．Ａの電子マネー口座へチャージ（送金）を行ってもよい。
＜表示画面例＞
図５－１７は、図３－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されているコード支払い画面（統合前）の一例を示す図である。
図５－１７は、図５－３とは異なり、キャンプ資金コード支払い領域２４２１内の「自分のウォレット」の横に表示されている残高（この例では「１０００円」）の金額が異なるとともに、その横にチャージボタンＣＮ５が表示されている。チャージボタンＣＮ５がタッチ操作されると、図３－１４に示すチャージ画面でチャージが行われる。
図５－１８は、図３－１４のチャージ画面においてチャージが完了した場合に表示されるコード支払い画面（チャージ後）の一例を示す図である。この例では、チャージが行われたことで、残高が「２５，０００円」となっている。
図５－１９は、図５－１８のコード支払い画面（統合前）においてスライドボタンＣＮ７がタッチ操作され、アカウントが統合されたことに基づいて表示されるコード支払い画面（統合後）の一例を示す図である。
この例では、図５－１９のキャンプ資金コード支払い領域２４２１の上部に、角財布の画像および共通ウォレットの名称（キャンプ資金）と、加算を示す「＋」と、がま口財布の画像および自分のウォレットとの文字が表示されるとともに、共通アカウントと自分のアカウントとが統合されたことに基づく統合後の残高（この例では「２６，０００円」）が表示されている。
また、図５－１９のキャンプ資金コード支払い領域２４２１内に表示される支払いコードは、共通アカウントと自分のアカウントとが統合されたことによって、図５－１８の支払いコードとは異なるコードとなっている。
＜処理＞
図５－２０は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、Ａ２１０～Ａ２３０のステップを実行する。次いで、端末Ａの制御部２１は、Ａ４５０ａのステップを実行する。
従って、この場合、サーバ１０の制御部１１は、Ｓ１２０のステップを実行すると、Ｓ１９０～Ｓ２１０のステップを実行する。次いで、サーバ１０の制御部１１は、Ａ４７０ａのステップを実行する。
なお、共通ウォレットとユーザＡ．Ａの電子マネー口座とを統合した後に、ユーザＡ．Ａの電子マネー口座へチャージを行ってもよい。この場合には、端末Ａの制御部２１は、Ａ４７０ａのステップを実行すると、Ａ２１０～Ａ２３０のステップを実行し、サーバ１０から統合アカウント決済結果情報を受信すると、Ａ４８０のステップを実行すればよい。また、サーバ１０の制御部１１は、Ｓ４９０ａのステップを実行すると、Ｓ１９０～Ｓ２１０のステップを実行し、店舗コードリーダ装置５０から決済要求情報を受信すると、Ｓ５００ａの処理を実行すればよい。
＜第５変形例（６）＞
第５実施例では、決済処理を実行する端末（限定ではなく例として端末Ａ）のユーザ（限定ではなく例としてユーザＡ．Ａ）の電子マネー口座と共通ウォレットを統合するか否かを選択するが、統合する電子マネー口座はこれに限定されない。限定ではなく例として、共通ウォレットを構成する他のメンバー（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座と統合を行えるようにしてもよい。
＜表示画面例＞
図５－２１は、図３－３のキャンプ資金支払い画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面（統合前）の一例を示す図である。
図５－２１は、図５－３とは異なり、キャンプ資金コード支払い領域２４２１内に「ウォレット統合」の文字が表示されているが、図５－３のように自分のウォレットの統合に関する表示はなされていない。
図５－２２は、図５－２１のコード支払い画面（統合前）においてスライドボタンＣＮ７が操作された場合に表示されるコード支払い画面（メンバー統合前）の一例を示す図である。
この例では、図５－１８のキャンプ資金コード支払い領域２４２１内のスライドボタンＣＮ７が「ＯＮ」とされた状態が示されている。また、その下には、ユーザに対する操作案内として、「ウォレット統合」の文字を含むウォレット統合案内領域ＷＴ１がコード支払い画面に重畳表示されている。
その下には、さらに、統合するユーザ（メンバー）を選択するためのウォレット統合メンバー選択領域ＷＴＭ１がウォレット統合案内領域ＷＴ１に重畳表示されている。
ウォレット統合メンバー選択領域ＷＴＭ１には、「どのメンバーのウォレットと統合しますか？」の説明文が上部に表示されており、その下には、チェックマークボタンＣＮ２と関連付けて、アカウントの統合対象とするユーザの候補が表示されている。
具体的には、限定ではなく例として、ユーザの候補として、自分に関する情報（自分のアイコン画像、自分であることを示す「自分」、自分の電子マネー口座残高（この例では「２５，０００円」））が表示されている。また、その下には、他のユーザの候補として、ユーザＢ．Ｂに関する情報（ユーザＢ．Ｂのアイコン画像、ユーザ名「ユーザＢ．Ｂ」）が表示されている。
限定ではなく例として、ユーザＢ．Ｂに関連付けられたチェックマークボタンＣＮ２がタッチ操作されると、ユーザＢ．Ｂのユーザアカウント（電子マネー口座）と共通ウォレットとが統合される。
図５－２３は、図５－２２のコード支払い画面（メンバー統合前）において、ユーザＢ．Ｂを選択するためのチェックマークボタンＣＮ２がタッチ操作された場合にユーザＢ．Ｂの端末２０の表示部２４に表示されるおしらせ画面の一例を示す図である。
図５－２３では、タイトルバーに、ユーザＢ．Ｂのアイコン画像およびそのユーザ名「Ｂ．Ｂ」が表示されている。また、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として「おしらせ」文字が表示されている。
「おしらせ」の文字の下には、おしらせを意味する「ベル」のアイコン画像が表示され、その横には、上段に「共通ウォレット：キャンプ資金」の文字が表示され、下段におしらせの概要（この例では「Ａ．Ａさんからウォレット統合依頼が届きました」）が表示されている。また、その下には、おしらせ日を示す「今日」の文字が表示されている。
おしらせ日の下には、キャンプ資金おしらせ表示領域２４２９が設けられている。
キャンプ資金おしらせ表示領域２４２９には、限定ではなく例として、上段に、共通ウォレットであることを示す角財布の画像とともに、その共通ウォレットの名称（この例では「キャンプ資金」）が表示されている。また、その横には、おしらせ日時として「２０２０年４月１１日１６時１８分」が表示され、その下には、この共通ウォレットを共同で使用するユーザ（この例では「ユーザＡ．Ａ」および「ユーザＢ．Ｂ」）のアイコン画像が表示されている。
また、キャンプ資金おしらせ表示領域２４２９には、限定ではなく例として、ユーザＡ．Ａからの依頼項目として「ウォレット統合依頼」が表示され、その下に、依頼内容として「Ａ．Ａさんからウォレット統合依頼が届きました」の文が表示されている。
また、その下には、ウォレット統合依頼の詳細情報として、角財布の画像および共通ウォレットの名称（この例では「キャンプ資金」）とともに、このキャンプ資金の共通ウォレット残高（この例では「１，０００円」）が表示されている。また、その下には、がま口財布の画像および「自分のウォレット」（この例ではユーザＢ．Ｂのウォレット）の文字とともに、自分のウォレットの残高（この例では「２０，０００円」）が表示されている。また、その下には、共通ウォレットメンバーを示すアイコン画像とともに「共通ウォレットのメンバー」の文字が表示され、その横に共通ウォレットメンバーの人数（この例では「２人」）が表示されている。
また、キャンプ資金おしらせ表示領域２４２９の下部には、ウォレット統合を許可するための許可ボタン２４２Ｐと、ウォレット統合を断るための拒否ボタン２４２Ｑとが表示されている。
図５－２４は、図５－２３のおしらせ画面において許可ボタン２４２Ｐがタッチ操作された場合にユーザＡ．Ａの端末２０の表示部２４に表示されるコード情報更新画面の一例を示す図である。
このコード情報更新画面では、図５－２２とは異なり、キャンプ資金コード支払い領域２４２１内の「ウォレット統合」の文字の下に、新たに、反転表示されたチェックマークボタンＣＮ２とともに、ユーザＢ．Ｂのアイコン画像、そのユーザ名「Ｂ．Ｂ」、および、ユーザＢ．Ｂの電子マネー口座残高（この例では「２０，０００円」）が表示されている。また、キャンプ資金コード支払い領域２４２１には、コード情報を更新中であることを示す更新中情報ＣＪＫが重畳表示されている。
図５－２５は、図５－２４のコード情報更新画面の後に、ユーザＡ．Ａの端末２０の表示部２４に表示されるコード支払い画面（メンバー統合後）の一例を示す図である。
このコード支払い画面では、共通アカウントにユーザＢ．Ｂのユーザアカウントが統合された結果が表示されている。具体的には、キャンプ資金コード支払い領域２４２１内の上部には、角財布の画像および共通ウォレットの名称（キャンプ資金）と、加算を示す「＋」と、がま口財布の画像および「Ｂ．Ｂさんのウォレット」とが表示されている。また、アカウント統合後の残高として、共通ウォレット残高とユーザＢ．Ｂの電子マネー口座残高とを加算した金額（この例では「２１，０００円」）が表示されている。
また、アカウントの統合によって、図５－２５のキャンプ資金コード支払い領域２４２１内に表示される支払いコードは、図５－２１に示される支払いコードとは異なるコードとなっている。
図５－２６は、図５－２３のおしらせ画面においてユーザＢ．Ｂによって許可ボタン２４２Ｐと拒否ボタン２４２Ｑとのうちのいずれかが操作されるまでの間にユーザＡ．Ａの端末２０の表示部２４に表示されるコード支払い画面（統合申請中）の一例を示す図である。
この例では、キャンプ資金コード支払い領域２４２１において、「ウォレット統合」の文字と関連付けられたスライドボタンＣＮ７が「ＯＮ」の状態とされている。
また、その下には、灰色で反転表示されたチェックマークボタンＣＮ２とともに、ユーザＢ．Ｂのアイコン画像およびユーザ名「Ｂ．Ｂ」が表示されている。また、その横には、「申請中」の文字を含む矩形の枠が表示されている。このような表示を行うことで、ユーザＡ．Ａは、アカウントの統合をユーザＢ．Ｂに申請中であり、ユーザＢ．Ｂによって未だ申請が許可されていないこと（または申請が拒否されていないこと）を知ることができる。
図５－２７は、図５－２１のコード支払い画面の別例を示す図である。
図５－２７が図５－２１と異なるのは、「ウォレット統合」の文字の下に、新たにチェックマークボタンＣＮ２とともに、「共通ウォレットへチャージ」の文字が表示されていることである。この例では、チェックマークボタンＣＮ２をタッチ操作することで、ユーザＡ．Ａが共通ウォレットへチャージすることが可能となる。
＜処理＞
図５－２８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、限定ではなく例として、共通ウォレットメンバーである他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座と、共通アカウントとを統合し、支払いを可能にすることを他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ依頼するか否かの選択機能を持つボタンを表示部２４に加えて表示させる（Ａ５５０）。
端末Ａの入出力部２３に対するユーザ操作に基づいて、ユーザＢ．Ｂの電子マネー口座と共通ウォレットとを統合することを依頼することが選択された場合（Ａ５５０：ＹＥＳ）、端末Ａの制御部２１は、アカウント統合要請情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５６０）。
ユーザＢ．Ｂの電子マネー口座と共通ウォレットとを統合することを依頼することが選択されない場合には（Ａ５５０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信し、図１－９のＡ１８０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａからアカウント統合要請情報を受信する場合（Ｓ６２０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント統合確認情報を、通信Ｉ／Ｆ１４によって端末Ｂに送信する（Ｓ６３０）。
アカウント統合要請情報を受信しない場合には（Ｓ６２０：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信し、図１－９のＳ１７０ａのステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０からアカウント統合確認情報を受信する場合（Ｂ２２０：ＹＥＳ）、端末Ｂの制御部２１は、アカウント統合確認情報に基づいて、ユーザＢ．Ｂの電子マネー口座と共通ウォレットとを統合することを認可するか否かの選択用画面を表示部２４に表示させる（Ｂ２３０）。アカウント統合確認情報を受信しない場合には（Ｂ２２０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
端末Ｂの入出力部２３に対するユーザ操作に基づいて、アカウントの統合を認可することが選択された場合（Ｂ２３０：ＹＥＳ）、端末Ｂの制御部２１は、アカウント統合認可情報を通信Ｉ／Ｆ２２によってサーバ１０に送信し（Ｂ２４０）、処理を終了する。認可しないことが選択された場合（Ｂ２３０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
通信Ｉ／Ｆ１４によって端末Ｂからアカウント統合認可情報を受信する場合（Ｓ６４０：ＹＥＳ）、サーバ１０の制御部１１は、ユーザＢ．Ｂの電子マネー口座と、共通ウォレットとを統合するアカウント統合処理を実行し（Ｓ６５０）、Ｓ４９０ａのステップを実行する。
なお、アカウント統合処理については、図５－６のＳ４８０のステップと同様に処理を行うことが可能であるため、処理の詳細については説明を省略する。
アカウント統合認可情報を受信しない場合には（Ｓ６４０：ＮＯ）、サーバ１０の制御部１１は、決済要求情報を通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信し、図１－９のＳ１７０ａのステップを実行する。
次いで、サーバ１０の制御部１１は、ユーザＢ．Ｂの電子マネー口座残高を含むユーザアカウント情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ６６０）。そして、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、図５－７のＳ５００ａのステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から統合アカウントコード情報を受信する場合（Ａ５７０）、端末Ａの制御部２１は、Ａ４７０ａのステップを実行する。次いで、通信Ｉ／Ｆ２２によってサーバ１０からユーザアカウント情報を受信すると、端末Ａの制御部２１は、受信されたユーザアカウント情報に基づき、限定ではなく例として、ユーザＢ．Ｂの電子マネー口座残高を表示部２４に加えて表示させる（Ａ５８０）。そして、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信すると、図５－７のＡ４８０のステップを実行する。
統合アカウントコード情報を受信しない場合には（Ａ５７０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済結果情報を受信すると、図１－９のＡ１８０のステップを実行する。
＜第５変形例（７）＞
第５変形例（６）では、共通ウォレットと、共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座との統合アカウントによる支払い時に、共通ウォレット残高では足りず、他のユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分が支払いを行った端末ＡのユーザＡ．Ａへ請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図５－２９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については限定ではなく例として図５－２８と、処理の後半については限定ではなく例として図４－２１と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、図５－２８のＡ５８０のステップを実行すると、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信し、Ａ４８０のステップを実行する。
次いで、端末Ａの制御部２１は、立て替え分の精算を行うか否かの選択用画面を表示部２４に表示させる（Ａ５９０）
なお、Ａ４８０のステップで用いられる統合アカウント決済結果情報において、統合を依頼したユーザＢ．Ｂの電子マネー口座からの支払い額が「０」である、または決済が失敗している場合には、精算を行う必要がない（Ａ５９０：ＮＯ）ため、選択用画面を表示部２４に表示させず、処理を終了してもよいし、しなくてもよい。また、ユーザＢ．Ｂの電子マネー口座からの支払い額が「０」より大きく、かつ決済が成功している場合には、選択用画面を表示部２４に表示させず、自動的に精算を行う（Ａ５９０：ＹＥＳ）ようにしてもよいし、しなくてもよい。
端末Ａの入出力部２３に対するユーザ操作に基づいて、精算を行うことが選択された場合（Ａ５９０：ＹＥＳ）、端末Ａの制御部２１は、統合アカウント決済結果情報に含まれるユーザＢ．Ｂの電子マネー口座からの支払い額を含むユーザアカウント決済額請求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６００）。
そして、端末Ａの制御部２１は、図４－２１のＡ４００以降のステップを実行する。
一方、精算を行わないことが選択された場合（Ａ５９０：ＮＯ）、端末Ａの制御部２１は処理を終了する。
サーバ１０の制御部１１は、統合アカウント決済結果情報を送信し（Ｓ５２０）、通信Ｉ／Ｆ１４によって端末Ａからユーザアカウント決済額請求情報を受信すると（Ｓ６７０：ＹＥＳ）、ユーザアカウント決済額請求情報に含まれるユーザＢ．Ｂの電子マネー口座からの支払い額を決済残高不足額として、Ｓ４００以降のステップを実行する。
ユーザアカウント決済額請求情報を受信しない場合には（Ｓ６７０：ＮＯ）、サーバ１０の制御部１１は、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足額を受信すると（Ｂ１８０：ＹＥＳ）、端末Ｂの制御部２１は、図４－２１のＢ１９０以降のステップを実行する。決済残高不足額を受信しない場合には（Ｂ１８０：ＮＯ）、端末Ｂの制御部２１は、処理を終了する。
＜第５変形例（８）＞
端末２０が、共通ウォレットコード情報、または共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示する。そして、端末２０が、自己の端末２０のユーザのユーザアカウント情報に対する入力に基づいて、このユーザアカウント情報と関連付けられた支払いコード、または支払い店舗コードを読み取るためのコードリーダ画面を表示部２４に表示するようにすることができる。
また、この場合、共通ウォレット残高と、自己の端末２０のユーザのユーザアカウントの電子マネー口座残高とのうち、限定ではなく例として、共通ウォレット残高から優先的に決済が行われるようにすることができる。
本変形例は、端末２０が、共通ウォレットコード情報（限定ではなく、共通アカウントと関連付けられた第１コード情報の一例）、または共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０が、自己の端末２０のユーザのユーザアカウント情報（限定ではなく、第２アカウント情報の一例）に対する入力に基づいて、ユーザアカウント情報が関連付けられた支払いコード（限定ではなく、第２アカウントと関連付けられた第３コード情報の一例）、またはユーザアカウント情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第３コードリーダ情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと関連付けられた第１コード情報、または第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第２アカウント情報に対する入力に基づいて、第２アカウントと関連付けられた第３コード情報、または第３コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、本変形例は、決済は、共通ウォレット残高と、自己の端末２０のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、第２アカウントを付随的なアカウントとすることができる。
＜第５変形例（９）＞
上記の示した各種の表示画面やユーザインタフェース（ＵＩ）はあくまでも一例に過ぎず、これらに限定されない。
＜表示画面例＞
図５－３０は、図３－１のサブメニューにおいて「自分のウォレット」（図示せず）がタッチ操作され、自分のウォレット画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるコード支払い画面（統合前）の一例を示す図である。このコード支払い画面は、自分のアカウントをベースとして、共通アカウントを統合先として選択するための画面の一例である。
図５－３０では、タイトルバーの下に、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「コード支払い」が表示されている。また、その下に設けられたコード支払い領域２４５１には、がま口財布の画像および「自分のウォレット」の文字とともに、自分の電子マネー口座残高（この例では「２５，０００円」）が表示されている。
その下には、「ウォレット統合」の文字が表示されるとともに、その横に、スライドボタンＣＮ７が配置されている。このスライドボタンＣＮ７を操作することで、自分のユーザアカウントに統合する共通アカウントを選択することが可能となる。
図５－３１は、図５－３０のコード支払い画面（統合前）においてスライドボタンＣＮ７がタッチ操作された場合に表示されるコード支払い画面（共通ウォレット統合前）の一例を示す図である。
図５－３１では、図５－３０のコード支払い領域２４５１内のスライドボタンＣＮ７が「ＯＮ」の状態とされている。また、その下には、ユーザに対する操作案内として、「ウォレット統合」の文字を含むウォレット統合案内領域ＷＴ２がコード支払い画面に重畳表示されている。その下には、さらに、統合する共通ウォレットを選択するための共通ウォレット統合選択領域ＷＴＭ２がウォレット統合案内領域ＷＴ２に重畳表示されている。
共通ウォレット統合選択領域ＷＴＭ２では、上部に「統合する共通ウォレットを選んでください」の説明文が表示されており、その下には、チェックマークボタンＣＮ２とともに、キャンプ資金用の共通ウォレットであることを示す「キャンプ資金」の文字が表示され、その横に、その共通ウォレット残高（この例では「１，０００円」）が表示されている。
また、その下には、チェックマークボタンＣＮ２とともに、韓国旅行用の共通ウォレットであることを示す「韓国旅行」の文字が表示され、その横に、その共通ウォレット残高
（この例では「９０，０００円」）が表示されている。
図５－３２は、図５－３１のコード支払い画面（共通ウォレット統合前）において韓国旅行用の共通ウォレットに関連付けられたチェックマークボタンＣＮ２がタッチ操作された場合に表示されるコード情報更新画面の一例を示す図である。
図５－３２が図５－３１と異なるのは、コード支払い領域２４５１内の「ウォレット統合」の文字の下に、新たに、反転表示されたチェックマークボタンＣＮ２とともに、「韓国旅行」の文字が表示されていることと、その横に、残高（この例では「９０，０００円」）が表示されていることと、キャンプ資金コード支払い領域２４２１に、コード情報を更新中であることを示す更新中情報ＣＪＫが重畳表示されていることである。
図５－３３は、図５－３２のコード情報更新画面の後に表示されるコード支払い画面（共通ウォレット統合後）の一例を示す図である。
このコード支払い画面では、コード支払い領域２４５１内の上部に、がま口財布の画像および自分のウォレットと、加算を示す「＋」と、角財布の画像および「韓国旅行」との文字が表示されるとともに、自分のユーザアカウントと共通アカウント（韓国旅行）とが統合された結果としての残高（この例では「１１５，０００円」）が表示されている。また、アカウントが統合されたことにより、コード支払い領域２４５１内に表示される支払いコードは、図５－３０の支払いコードとは異なるコードとなっている。
＜第６実施例＞
第６実施例は、端末２０（限定ではなく例として端末Ａ）が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高から実行するが、支払い時に共通ウォレット残高が不足している場合に、ユーザＡ．Ａの電子マネー口座と共通ウォレットとの統合アカウントに基づいて支払いを実行することで、共通ウォレットの残高不足を補う実施例である。
第６実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜処理＞
図６－１～図６－２は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
店舗コードリーダ装置５０の制御部５１は、店舗決済処理としてＰ１００～Ｐ１６０のステップを実行する。
サーバ１０の制御部１１は、Ｓ１２０のステップを実行すると、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信し、Ｓ２５０ａのステップを実行する。また、Ｓ２７０ａのステップを実行すると、Ｓ４７０ａのステップを実行する。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、Ａ２７０ａのステップを実行する。また、Ａ２９０のステップを実行すると、Ａ４５０ａのステップを実行する。
図６－２は、以後の説明に要するため便宜上記述するフローであり、各装置のステップは図５－７と同一であるため説明を省略する。
なお、店舗コードリーダ装置５０がＰ１３０を実行後、図６－２のフローに処理を移すか、図４－５のフローに処理を移すかについて、Ｐ１３０の実行時には店舗コードリーダ装置５０は判断を行うことができないため、サーバ１０の制御部１１の処理によって分岐を行う。図６－２と図４－５とにおいては、店舗コードリーダ装置５０の制御部５１が実行する処理は同一であるため、サーバ１０の分岐結果から直接的な影響は受けない。
＜第６実施例の効果＞
第６実施例は、端末２０は、決済予定金額（限定ではなく、第１決済の金額の一例）と、共通ウォレット残高（限定ではなく、第１アカウントの残高）とに基づき、共通ウォレット残高が不足している場合に、共通アカウント（限定ではなく、第１アカウントの一例）と、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とに基づいて、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第１アカウントの残高が不足している場合であっても、第１アカウントと第２アカウントとに基づいて、適切に決済を行うことができる。
＜第６変形例（１）＞
第６実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
図６－３は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、Ａ３００のステップを実行する。また、Ａ２９０のステップを実行すると、Ａ４５０ｂのステップを実行する。
サーバ１０の制御部１１は、Ｓ１２０のステップを実行し、通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信すると、Ｓ２５０ｂのステップを実行する。また、Ｓ２７０ｂのステップを実行すると、Ｓ４７０ｂのステップを実行する。
＜第６変形例（２）＞
第６実施例では、アカウント統合処理を用いて複数のアカウントを単一のコードに紐づけていたが、そのようにしなくてもよい。限定ではなく例として、複数のアカウントをアカウント並列使用することにより支払いを行ってもよい。
図６－４～図６－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
店舗コードリーダ装置５０の制御部５１は店舗決済処理としてＰ１００～Ｐ１６０のステップを実行する。
サーバ１０の制御部１１は、Ｓ１２０のステップを実行すると、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信し、Ｓ２５０ａのステップを実行する。また、Ｓ２７０ａのステップを実行すると、Ｓ５３０のステップを実行する。
端末Ａの制御部２１は、Ａ１３０のステップを実行すると、Ａ２７０ａのステップを実行する。また、Ａ２９０のステップを実行すると、Ａ４９０のステップを実行する。
図６－５における各装置のステップは、図５－１５と同一であるため説明を省略する。
なお、店舗コードリーダ装置５０がＰ１３０を実行後、図６－５のフローに処理を移すか、図４－５のフローに処理を移すかについて、Ｐ１３０の実行時には店舗コードリーダ装置５０は判断を行うことができないため、サーバ１０の制御部１１の処理によって分岐を行う。
＜第６変形例（３）＞
第６実施例では、支払い開始時におけるユーザＡ．Ａの電子マネー口座の残高と、共通ウォレット残高とを加算する金額を統合アカウントの残高（統合アカウントによる支払いが可能な金額）としていたが、それに限定されない。
限定ではなく例として、ユーザＡ．Ａの電子マネー口座の残高と、共通ウォレット残高とを合算しても支払い額に満たない場合には、共通ウォレットとユーザＡ．Ａの電子マネー口座とを統合する前に、ユーザＡ．Ａによってあらかじめ登録される外部金融機関の口座から、ユーザＡ．Ａの電子マネー口座へチャージ（送金）を行ってもよい。
図６－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図６－２もしくは図４－５と同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ２９０のステップを実行すると、Ａ３５０のステップを実行し、必要に応じてＡ２１０～Ａ２３０のステップを実行する。その後、端末Ａの制御部２１は、Ａ４５０ａ以降のステップを実行する。
なお、端末Ａの制御部２１は、Ａ３５０のステップを実行せずに、必ずＡ２１０～Ａ２３０のステップを実行するようにしてもよいし、そのようにしなくてもよい。
サーバ１０の制御部１１は、Ｓ２７０ａのステップを実行すると、Ｓ１９０～Ｓ２１０のステップを実行し、Ｓ４７０ａ以降のステップを実行する。
店舗コードリーダ装置５０の制御部５１は、Ｐ１３０のステップを実行すると、Ｐ１４０以降のステップを実行する。
＜第６変形例（４）＞
第６実施例では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
図６－７は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
端末Ａの制御部２１は、Ａ４８０のステップを実行すると、Ａ５３０～Ａ３４０のステップを実行し、処理を終了する。
端末Ｂの制御部２１は、Ｂ１００～Ｂ１３０のステップを実行し、処理を終了する。
サーバ１０の制御部１１は、Ｓ５２０のステップを実行すると、Ｓ６１０～Ｓ３３０のステップを実行し、処理を終了する。
店舗コードリーダ装置５０の制御部５１は、Ｐ１６０のステップを実行すると、処理を終了する。
各ステップについては、図５－１６と同様に実現することが可能であるため、詳細については説明を省略する。
なお、図６－６の処理の後半から、図６－７のフローへ繋げることで、ユーザＡ．Ａの立て替え分を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ請求するようにしてもよいし、そうしなくてもよい。
＜第６変形例（５）＞
第６実施例では、共通ウォレットでの残高不足により支払いが行われなかった場合には、決済処理を実行する端末（限定ではなく例として端末Ａ）のユーザ（限定ではなく例としてユーザＡ．Ａ）の電子マネー口座と共通ウォレットを統合するか否かを選択するが、統合する電子マネー口座はこれに限定されない。限定ではなく例として、共通ウォレットを構成する他のメンバー（限定ではなく例としてユーザＢ．Ｂ）の電子マネー口座と統合を行えるようにしてもよい。
図６－８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図６－２と同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ２９０のステップを実行すると、Ａ５５０～Ａ５８０のステップを実行する。通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信すると、端末Ａの制御部１１は、Ａ４８０以降のステップを実行する。
端末Ｂの制御部２１は、Ｂ２２０～Ｂ２４０のステップを実行し、処理を終了する。
サーバ１０の制御部１１は、Ｓ２７０ａのステップを実行すると、Ｓ６２０～Ｓ６６０のステップを実行する。通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、Ｓ５００ａ以降のステップを実行する。
店舗コードリーダ装置５０の制御部５１は、Ｐ１３０のステップを実行すると、Ｐ１４０以降のステップを実行する。
各ステップについては、図５－２８と同様に実現することが可能であるため、詳細については説明を省略する。
＜第６変形例（６）＞
第６変形例（５）では、他のユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分が支払いを行った端末ＡのユーザＡ．Ａへ請求されることはなかったが、請求されるようにしてもよいし、そのようにしなくてもよい。
図６－９は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図６－８と、処理の後半については、限定ではなく例として図４－２１と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ５８０のステップを実行すると、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信し、Ａ４８０～Ａ６００のステップを実行する。Ａ６００：ＹＥＳの場合には、端末Ａの制御部２１は、Ａ４００以降のステップを実行する。
端末Ｂの制御部２１は、Ｂ１８０のステップを実行する。Ｂ１８０：ＹＥＳの場合には、Ｂ１９０以降のステップを実行する。
サーバ１０の制御部１１は、Ｓ６６０のステップを実行すると、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信し、Ｓ５００ａ～Ｓ４００のステップを実行する。Ｓ４００のステップが実行される場合、サーバ１０の制御部１１は、Ｓ４１０以降のステップを実行する。
店舗コードリーダ装置５０の制御部５１は、Ｐ１３０のステップを実行すると、Ｐ１４０～Ｐ１６０の処理を実行する。
各ステップについては、図５－２９と同様に実現することが可能であるため、詳細については説明を省略する。
＜第７実施例＞
第７実施例は、端末２０（限定ではなく例として端末Ａ）が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレット残高と端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）の電子マネー口座残高とを合算する統合アカウントの電子マネー残高から実行する実施例である。第５実施例とは異なり、本実施例では、統合アカウントを用いる支払いから処理を開始する。
第７実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
＜処理＞
図７－１は、実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。本処理は、利用者提示型のコード決済に関する処理の一例である。
なお、処理の後半については、限定ではなく例として図５－７と同様に実行することが可能であるため、詳細については説明を省略する。
まず、端末Ａの制御部２１は、限定ではなく例として、端末Ａから利用可能な共通ウォレットと、自身の電子マネー口座とを統合した統合アカウントを選択する情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６１０）。
統合アカウントを選択する情報は、限定ではなく例として、共通ウォレットＩＤと、ユーザＡ．Ａの支払いアプリケーションＩＤとを含む。端末Ａの制御部２１は、選択可能な共通ウォレットＩＤを、本ステップにおいて通信Ｉ／Ｆ２２によってサーバ１０から受信してもよいし、記憶部２８にあらかじめ記憶されたものを呼び出してもよい。また、端末Ａの制御部２１は、支払いアプリケーションＩＤではなく、サーバ１０の制御部１１において支払いアプリケーションＩＤを特定可能な端末電話番号を送信してもよい。
通信Ｉ／Ｆ１４によって端末Ａから統合アカウントを選択する情報を受信すると、サーバ１０の制御部１１は、統合アカウントを選択する情報に基づいて、Ｓ４８０のステップを実行する。
なお、既に統合アカウントが作成されている場合、端末Ａの制御部２１は、統合アカウントを選択する情報として、その統合アカウントＩＤを含む統合アカウントを選択する情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信してもよい。端末Ａの制御部２１は、選択可能な統合アカウントＩＤを、本ステップにおいて通信Ｉ／Ｆ２２によってサーバ１０から受信してもよいし、記憶部２８にあらかじめ記憶されたものを呼び出してもよい。この場合、サーバ１０の制御部１１は、Ｓ４８０のステップにおいて、アカウント統合処理において、統合アカウント管理データのレコード追加を実行しなくてもよい。
そして、サーバ１０の制御部１１は、Ｓ４９０ａ～Ｓ１２０の各ステップを実行し、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、Ｓ５００ａ以降のステップを実行する。
端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウントコード情報を受信すると、Ａ４７０ａ～Ａ１３０の各ステップを実行し、通信Ｉ／Ｆ１４によって統合アカウント決済結果情報を受信すると、Ａ４８０以降のステップを実行する。
なお、Ａ６１０のステップにおいて、端末Ａの制御部２１は、限定ではなく例として、端末Ａから利用可能な共通ウォレットと、自身以外の共通ウォレットメンバーの電子マネー口座とを統合した統合アカウントを選択する情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信するようにしてもよいし、そのようにしなくてもよい。この場合、統合アカウントを選択する情報は、限定ではなく例として、共通ウォレットＩＤと、ユーザＢ．Ｂの支払いアプリケーションＩＤとを含む。
＜第７実施例の効果＞
第７実施例は、端末２０が、自己の端末２０のユーザが決済可能な第１アカウントと、自己の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントとは異なる第２アカウントの一例）とが関連付けられた統合アカウントコード情報（限定ではなく、第１コード情報の一例）を表示部２４に表示する。そして、端末２０は、統合アカウントコード情報が読み取られることに基づいて、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとが関連付けられた第１コード情報、を端末の表示領域に表示して決済に利用させることができる。また、第１コード情報が読み取られることに基づいて、決済を簡単に実現することができる。
また、第７実施例は、第１アカウントは、共通アカウント（限定ではなく、少なくとも端末のユーザと、端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、共通アカウントと、共通アカウントとは異なる第２アカウントとが関連付けられた第１コード情報を端末の表示領域に表示して決済に利用させることができる。また、第１コード情報が読み取られることに基づいて、決済を簡単に実現することができる。
また、第７実施例は、統合アカウントコード情報（限定ではなく、第１コード情報の一例）は、一つのコード（限定ではなく、一つのコード情報の一例）である構成を示している。
このような構成により得られる効果の一例として、複数のコード情報ではなく、一つのコード情報によって簡単に決済を実現することができる。
また、第７実施例は、統合アカウントコード情報（限定ではなく、第１コード情報の一例）は、自己の端末２０のユーザの支払いアプリケーションＩＤ、または異なる端末２０のユーザの支払いアプリケーションＩＤ（限定ではなく、第２アカウントに関する情報の一例）と、共通ウォレットＩＤ（限定ではなく、共通アカウントに関する情報の一例）とを含む構成を示している。
このような構成により得られる効果の一例として、上記と相まって、第２アカウントに関する情報と、共通アカウントに関する情報とを一つのコード情報に含めることができるため、効率的である。
また、第７実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）とは異なる端末２０のユーザ（限定ではなく例としてユーザＢ．Ｂ）の支払いアプリケーションＩＤ（限定ではなく、第３アカウントの一例）を含む統合アカウントを選択する情報（限定ではなく、第３アカウントに関する第３アカウント情報の一例）と、自己の端末２０のユーザの支払いアプリケーションＩＤ（限定ではなく、第２アカウントの一例）を含む統合アカウントを選択する情報（限定ではなく、第２アカウントに関する第２アカウント情報の一例）とを表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、第２アカウント情報に加えて、第２アカウントとは異なる第３アカウントに関する第３アカウント情報を端末のユーザに知らせることができる。
また、第７実施例は、端末２０が、自己の端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）の支払いアプリケーションＩＤ（限定ではなく、第２アカウントの一例）を含む統合アカウントを選択する情報（限定ではなく、第２アカウントに関する第２アカウント情報の一例）と、異なる端末２０のユーザ（限定ではなく例としてユーザＢ．Ｂ）の支払いアプリケーションＩＤ（限定ではなく、第３アカウントの一例）を含む統合アカウントを選択する情報（限定ではなく、第３アカウントに関する第３アカウント情報の一例）とを表示部２４に表示する。そして、端末２０は、表示された、自己の端末２０のユーザ（限定ではなく例としてユーザＡ．Ａ）の支払いアプリケーションＩＤ（限定ではなく、第２アカウントの一例）を含む統合アカウントを選択する情報に対する入力に基づいて、共通アカウントと、自己の端末２０のユーザのユーザアカウントとが統合された統合アカウントコード情報（限定ではなく、第１コード情報の一例）を表示部２４に表示する構成を示している。
このような構成により得られる効果の一例として、第２アカウントに関する第２アカウント情報とともに、第２アカウントとは異なる第３アカウントに関する第３アカウント情報を端末のユーザに認識させることができる。また、第２アカウント情報に対する端末のユーザによる入力に基づいて、第１コード情報、または第１コードリーダ情報を表示領域に表示して決済に利用させることができる。
また、第７実施例は、第２アカウントは、自己の端末２０のユーザのアカウント（限定ではなく、端末のユーザのアカウントの一例）である構成を示している。
このような構成により得られる効果の一例として、端末のユーザのアカウントを第２アカウントとして決済を実現することができる。
また、第７実施例は、サーバ１０が、一の端末２０のユーザが決済可能な第１アカウントと、この端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントとは異なる第２アカウントの一例）とが関連付けられた統合アカウントコード情報（限定ではなく、第１コード情報の一例）をこの端末２０に通信Ｉ／Ｆ１４によって送信する。また、サーバ１０は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報（限定ではなく、第１コード情報と、商品情報との一例）を受信する。そして、サーバ１０は、受信された決済要求情報に基づいて、決済処理（限定ではなく、第１決済に関する処理の一例）を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとが関連付けられた第１コード情報を端末のユーザに取得させることができる。
＜第７変形例（１）＞
第７実施例では、利用者提示型のコード決済に関して説明したが、これに限定されない。具体的には、店舗提示型のコード決済としてもよい。
図７－２は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図５－１２と同様に実行することが可能であるため、詳細については説明を省略する。
端末Ａの制御部２１は、Ａ６１０～Ａ１３０の各ステップを実行すると、Ａ１９０以降のステップを実行する。
サーバ１０の制御部１１は、Ｓ４８０～Ｓ１２０の各ステップを実行すると、通信Ｉ／Ｆ１４によって端末Ａから決済要求情報を受信し、Ｓ５００ｂ以降のステップを実行する。
本変形例は、端末２０が、自己の端末２０のユーザが決済可能な第１アカウントと、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とが関連付けられた統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ情報の一例）を表示部２４に表示する。そして、端末２０は、統合アカウントコードリーダ情報に基づくコードリーダ画面が表示部２４に表示された端末２０によって支払い店舗コードが読み取られることに基づいて、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとが関連付けられた第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、第１コードリーダ情報が表示された端末によってコード情報が読み取られることに基づいて、決済を簡単に実現することができる。
＜第７変形例（２）＞
アカウント統合処理を用いて複数のアカウントを単一のコードに紐づけていたが、そのようにしなくてもよい。限定ではなく例として、複数のアカウントをアカウント並列使用することにより支払いを行ってもよい。
図７－３は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図５－１５と同様に実行することが可能であるため、詳細については説明を省略する。
まず、端末Ａの制御部２１は、限定ではなく例として、端末Ａから利用可能な共通ウォレットと、自身の電子マネー口座とをアカウント並列使用することを選択する情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ６２０）。
アカウント並列使用することを選択する情報には、限定ではなく例として、共通ウォレットＩＤと、ユーザＡ．Ａの支払いアプリケーションＩＤとを含む。
通信Ｉ／Ｆ１４によって端末Ａからアカウント並列使用することを選択する情報を受信すると、サーバ１０の制御部１１は、アカウント並列使用することを選択する情報に基づいて、Ｓ５４０のステップを実行する。そして、サーバ１０の制御部１１は、Ｓ５５０～Ｓ１２０の各ステップを実行し、店舗コードリーダ装置５０から決済要求情報を受信すると、Ｓ５７０以降のステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から第１並列コード情報と第２並列コード情報とを受信すると、端末Ａの制御部２１は、Ａ５１０～Ａ１３０の各ステップを実行し、通信Ｉ／Ｆ２２によってサーバ１０からアカウント並列決済結果情報を受信すると、Ａ５２０以降のステップを実行する。
なお、前述したように、統合アカウントコード情報（限定ではなく、第１コード情報の一例）には、統合対象の支払いアプリケーションＩＤ（限定ではなく、第２アカウントに関する情報の一例）と、共通ウォレットＩＤ（限定ではなく、共通アカウントに関する情報の一例）とが含まれる、または関連付けられていると言える。
本変形例は、統合アカウントコード情報（限定ではなく、第１コード情報の一例）は、第２コード情報と、第３コード情報とを含み、第２コード情報は、共通ウォレットＩＤ（限定ではなく、共通アカウントの一例）に関連付けられ、第３コード情報は、統合対象の支払いアプリケーションＩＤ（限定ではなく、第２アカウントの一例）に関連付けられ、第２コード情報は、第３コード情報とは異なる領域に表示される構成を示している。
このような構成により得られる効果の一例として、異なる領域に表示される個別のコード情報に基づいて決済を実現することができる。
＜第７変形例（３）＞
第７実施例では、初めにコードを提示する統合アカウントでの支払いが失敗すると、処理を終了するが、そのようにしなくてもよい。
限定ではなく例として、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補い、再度支払いを行ってもよい。
図７－４～図７－５は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の後半については、限定ではなく例として図６－２と同様に実行することが可能であるため、詳細については説明を省略する。
端末Ａの制御部２１は、Ａ６１０～Ａ１３０の各ステップを実行する。そして、サーバ１０の制御部１１は、Ｓ４８０～Ｓ１２０の各ステップを実行する。店舗コードリーダ装置５０の制御部５１は、Ｐ１００～Ｐ１１０の処理を実行する。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信する。この場合、決済要求情報には、Ｓ４９０ａのステップで送信した統合アカウントコード情報に基づく、統合アカウント支払いトークンが含まれる。そのため、サーバ１０の制御部１１は、統合アカウント決済処理を実行する（Ｓ６８０）。統合アカウント決済処理は、図５－７のＳ５００ａのステップと同様に実行することが可能であるため、詳細については説明を省略する。
Ｓ６８０において決済が成功した場合には（Ｓ６９０：ＹＥＳ）、サーバ１０の制御部１１は、図６－２のＳ５１０のステップへ処理を進ませる。
Ｓ６８０において決済が失敗した場合には（Ｓ６９０：ＮＯ）、サーバ１０の制御部１１は、決済が失敗した旨と、その場合の統合アカウントでの決済残高不足額とを含む決済残高不足情報を、通信Ｉ／Ｆ１４によって端末Ａと店舗コードリーダ装置５０とに送信する（Ｓ７００）。
ここで、本変形例における決済残高不足情報は、統合アカウントの残高が不足していることを示す情報であるが、統合アカウントは、共通アカウントと、ユーザＡ．Ａのユーザアカウントとを統合したアカウントである。このため、本変形例における決済残高不足情報は、共通ウォレット残高と、ユーザＡ．Ａの電子マネー口座残高とが不足していることを示す情報である。
そして、サーバ１０の制御部１１は、さらにＳ１９０～Ｓ２１０のステップを実行し、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、Ｓ５００ａ以降のステップを実行する。
通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると（Ａ６１０：ＹＥＳ）、端末Ａの制御部２１は、Ａ２８０～Ａ２９０のステップを実行する。端末Ａの制御部２１は、さらにＡ２１０～Ａ２３０のステップを実行すると、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信し、Ａ４８０のステップを実行する。
決済残高不足情報を受信しない場合には（Ａ６１０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信し、Ａ４８０以降のステップを実行する。
通信Ｉ／Ｆ５４によってサーバ１０から決済残高不足額を受信すると（Ｐ２００：ＹＥＳ）、店舗コードリーダ装置５０の制御部５１は、Ｐ１３０以降のステップを実行する。決済残高不足額を受信しない場合には（Ｐ２００：ＮＯ）、店舗コードリーダ装置５０の制御部５１は、通信Ｉ／Ｆ５４によってサーバ１０から決済結果情報を受信し、Ｐ１６０以降のステップを実行する。
本変形例は、端末２０が、決済予定金額（限定ではなく、第１決済の金額の一例）と、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）と、自己の端末２０のユーザの電子マネー口座残高（限定ではなく、第２アカウントの残高の一例）とに基づき、共通ウォレット残高と、自己の端末２０のユーザの電子マネー口座残高との残高が不足していることを示す決済残高不足情報（限定ではなく、共通アカウントと第２アカウントとの残高が不足していることに関する第１情報の一例）を表示部２４に表示する。そして、端末２０は、自己の端末２０のユーザによる決済残高不足情報に対する入力に基づいて、自己の端末２０のユーザの電子マネー口座にチャージする処理（限定ではなく、第２アカウントに対して送金する処理の一例）を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントと第２アカウントとの残高が不足していることを端末のユーザに知らせることができる。また、端末のユーザによる第１情報に対する入力に基づいて、第２アカウントに対して送金することができる。
＜第７変形例（４）＞
第７実施例ならびに第７変形例（３）では、統合アカウントによる支払い時に、共通ウォレット残高では足りず、ユーザの電子マネー口座の残高を使用して立て替えた場合でも、立て替え分を共通ウォレットの他のユーザ（限定ではなく例としてユーザＢ．Ｂ）へ請求することはなかったが、請求するようにしてもよいし、そのようにしなくてもよい。
この場合には、処理の後半において、図６－２のフローの代わりに図６－７のフローを実行すればよい。
＜第７変形例（５）＞
第７変形例（３）では、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補うが、そのようにしなくてもよい。
限定ではなく例として、他の共通ウォレットメンバーに、共通ウォレットへの送金を依頼することで残高不足を補ってもよい。
図７－６は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、端末Ｂ（限定ではなく例として、ユーザＢ．Ｂの端末２０）の制御部２１が実行する決済連携処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図７－４と、処理の後半については、限定ではなく例として図６－２と、それぞれ同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ２９０のステップを実行すると、Ａ３６０～Ａ３８０のステップを実行し、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信すると、Ａ４８０以降のステップを実行する。
端末Ｂの制御部２１は、Ｂ１４０～Ｂ１７０のステップを実行し、処理を終了する。
サーバ１０の制御部１１は、Ｓ３４０～Ｓ３９０のステップを実行すると、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信し、Ｓ５００ａ以降のステップを実行する。
なお、処理の各ステップについては、図４－１９と同様に実行することが可能であるため、詳細については説明を省略する。
また、処理の後半として、図６－２のフローの代わりに図６－９、図４－２１のフローを実行することで、他のユーザの電子マネー口座の残高を使用して立て替えた場合には、立て替え分が支払いを行った端末ＡのユーザＡ．Ａへ請求されるようにしてもよいし、そのようにしなくてもよい。
また、他の共通ウォレットメンバーに共通ウォレットへの送金を依頼したが、その共通ウォレットメンバーによって共通ウォレットへの送金が認可されなかった場合、送金を依頼した端末２０において、統合アカウントコード情報が表示部２４に表示されないようにするか、またはそれ以降の決済に関する処理が実行されないようにしてもよい。
＜第７変形例（６）＞
第７変形例（３）では、統合アカウントでの支払いが失敗すると、自身のアカウントにチャージを実行し、統合アカウントの残高を増加させることで残高不足を補うが、そのようにしなくてもよい。
限定ではなく例として、共通ウォレットと自身の電子マネー口座とで構成される統合アカウントに、さらに他の共通ウォレットメンバーの電子マネー口座を加えてもよい。
図７－７～図７－８は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末Ａ（限定ではなく例として、ユーザＡ．Ａの端末２０）の制御部２１が実行する決済処理、サーバ１０の制御部１１が実行する決済管理処理、店舗ＰＯＳシステム（限定ではなく例として、加盟店Ｓ１の店舗ＰＯＳシステム４０）の構成要素である店舗コードリーダ装置５０の制御部５１が実行する店舗決済処理の一例をそれぞれ示している。
なお、処理の前半については、限定ではなく例として図７－４と同一とすることができるため、ここでは説明を省略する。
端末Ａの制御部２１は、Ａ２９０のステップを実行すると、統合アカウントへ他の電子マネー口座（限定ではなく例としてユーザＢ．Ｂの電子マネー口座）をさらに統合するか否かの選択用画面を、表示部２４に表示させる（Ａ６２０）。以下では、統合アカウントへのさらなる電子マネー口座の追加を「アカウント再統合」と称する。
端末Ａの入出力部２３に対するユーザ操作に基づいて、アカウントを再統合することが選択される場合（Ａ６２０：ＹＥＳ）、端末Ａの制御部２１は、統合元の統合アカウントＩＤと、追加するユーザの支払いアプリケーションＩＤとを含むアカウント再統合依頼情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する。
端末Ａの入出力部２３に対するユーザ操作に基づいて、アカウントを再統合することが選択されない場合には（Ａ６２０：ＮＯ）、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウント決済結果情報を受信し、図６－２のＡ４８０のステップを実行する。
通信Ｉ／Ｆ１４によって端末Ａからアカウント再統合依頼情報を受信する場合（Ｓ７１０：ＹＥＳ）、サーバ１０の制御部１１は、アカウント再統合処理を実行する（Ｓ７２０）。
アカウント再統合依頼情報を受信しない場合には（Ｓ７１０：ＮＯ）、サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信し、Ｓ５００ａ以降のステップを実行する。
アカウント再統合処理では、サーバ１０の制御部１１は、統合アカウント管理データベース１５９から統合元の統合アカウントＩＤを持つ統合アカウント管理データのレコードを検索し、そのレコードの統合アカウントメンバーＩＤに、ユーザＢ．Ｂの支払いアプリケーションＩＤを加えて記憶させる。統合アカウントの残高は、統合アカウントメンバーＩＤに追加した支払いアプリケーションＩＤの電子マネー残高をさらに加えた金額となる。
そして、サーバ１０の制御部１１は、再統合した統合アカウントの電子マネー残高を含む再統合アカウント情報を、通信Ｉ／Ｆ１４によって端末Ａに送信する（Ｓ７３０）。
端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から再統合アカウント情報を受信すると、再統合した統合アカウントの電子マネー残高を表示部２４に更新して表示させる（Ａ６４０）。そして店舗コードリーダ装置５０の制御部１１は、Ｐ１４０～Ｐ１６０のステップを実行し、処理を終了する。
なお、サーバ１０の制御部１１は、アカウント再統合処理を実行すると、統合アカウント支払いトークンと、新たな統合アカウント支払いトークンを含む統合アカウントコード情報とを再生成し、通信Ｉ／Ｆ１４によって端末Ａに送信してもよい。この場合、端末Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から統合アカウントコード情報を受信すると、統合アカウントコード情報を表示部２４に更新して表示させる。
通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から決済要求情報を受信すると、サーバ１０の制御部１１は、再統合アカウント決済処理を実行する（Ｓ７４０）。
統合アカウント決済処理では、サーバ１０の制御部１１は、要求を受けた統合アカウント支払いトークンから統合アカウントＩＤを検索する。サーバ１０の制御部１１は、さらに統合アカウントＩＤに紐づけられる統合アカウントメンバーＩＤ（ここではユーザＡ．Ａの支払いアプリケーションＩＤと、ユーザＢ．Ｂの支払いアプリケーションＩＤと、共通ウォレットの共通ウォレットＩＤ）に基づいて、統合アカウントメンバーＩＤで指し示されるユーザＡ．Ａの電子マネー口座残高とユーザＢ．Ｂの電子マネー口座残高と共通ウォレット残高との合計額を用いて、統合アカウントに対して、店舗ＩＤで定められる加盟店との間で決済予定金額の支払いを行う決済処理を実行する。
統合アカウントでの決済が成功する場合には、サーバ１０の制御部１１は、共通ウォレット残高を決済予定金額だけ減少させる。
一方、共通ウォレット残高が決済予定金額に満たない場合には、サーバ１０の制御部１１は、限定ではなく例として、共通ウォレット残高を優先的に支払いに使用して「０」とした後、不足分（＝決済予定金額－共通ウォレット残高）を、ユーザＡ．Ａの電子マネー口座残高とユーザＢ．Ｂの電子マネー口座残高とから割り勘（均等割り）して差し引く。
次いで、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否と、決済処理後の再統合した統合アカウント残高とを含む決済結果情報を、通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０に送信する（Ｓ７５０）。
また、サーバ１０の制御部１１は、限定ではなく例として、決済処理の成否と、決済処理後の統合アカウントを構成する各ユーザの電子マネー口座・共通ウォレット残高と、それぞれの電子マネー口座・共通ウォレットでの支払い額とを含む再統合アカウント決済結果情報を、通信Ｉ／Ｆ１４によって端末Ａに送信し（Ｓ７６０）、処理を終了する。
通信Ｉ／Ｆ２２によってサーバ１０から再統合アカウント決済結果情報を受信すると、端末Ａの制御部２１は、再統合アカウント決済結果情報を表示部２４に表示させ（Ａ６５０）、処理を終了する。
なお、アカウント再統合においては、統合アカウントに追加可能な電子マネー口座はユーザアカウントに限定されない。別な共通ウォレットを追加してもよいし、そうしなくてもよい。
本変形例は、決済は、共通ウォレット残高と、自己の端末２０のユーザのユーザアカウントの電子マネー口座残高と、異なる端末２０のユーザのユーザアカウントの電子マネー口座残高とのうち、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）から優先的に支払いが行われる構成を示している。
このような構成により得られる効果の一例として、共通アカウントの残高から優先的に支払いが行われるため、他のアカウントを付随的なアカウントとすることができる。
また、本変形例は、端末２０が、自己の端末２０のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）および他の共通ウォレットメンバーのユーザアカウントを含む、共通ウォレットメンバーの各々のユーザアカウントと、共通アカウントとに基づいて決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、第２アカウントを含む、共通アカウントによって決済可能なユーザの各々のアカウントと、共通アカウントとに基づいて決済を実現することができる。
また、本変形例は、統合アカウントコード情報（限定ではなく、第１コード情報の一例）は、共通ウォレットメンバーの各々のユーザアカウントが関連付いている構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの各々のアカウントと関連付いた第１コード情報を決済に利用させることができる。
また、本変形例は、共通ウォレットメンバーの各々のユーザアカウントは、共通ウォレット残高の不足分が割り勘（均等割り）して差し引かれ、決済に基づく支払いが実行される構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの各々のアカウントに共通アカウントの残高の不足分が均等に割り振られるため、公平な決済を実現することができる。
＜第７変形例（７）＞
第７変形例（６）では、共通ウォレットと、２以上のユーザの電子マネー口座とを統合するアカウント再統合処理および再統合アカウントを用いる支払いは、一度統合アカウントを用いて支払いを試み、失敗した後に行うこととしたが、それに限定されない。
限定ではなく例として、アカウントの再統合は図６－１の後に行ってもよい。
＜第７変形例（８）＞
利用者提示型のコード決済を適用する場合、端末２０が、自己の端末２０のユーザのユーザアカウントが関連付けられたコード情報（支払いコード等）（限定ではなく、第２アカウントに関連付けられた第３コード情報の一例）を表示部２４に表示する。また、端末２０が、これと同じ画面に、限定ではなく例として、共通ウォレットに関する情報（共通ウォレットＩＤ等）（限定ではなく、共通アカウント情報の一例）を表示する。そして、端末２０が、表示した共通ウォレットに関する情報に対する自己の端末２０のユーザによる入力に基づいて、限定ではなく例として、共通アカウントと、自己の端末２０のユーザのユーザアカウントとが関連付けられた統合アカウントコード情報（限定ではなく、第１コード情報の一例）を表示部２４に表示するようにしてもよいし、そのようにしなくてもよい。
同様に、店舗提示型のコード決済を適用する場合、端末２０が、自己の端末２０のユーザのユーザアカウントが関連付けられたコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第２アカウントに関連付けられた第３コードリーダ画面の一例）を表示部２４に表示する。また、端末２０が、これと同じ画面に、限定ではなく例として、共通ウォレットに関する情報（共通ウォレットＩＤ等）を表示する。そして、端末２０が、表示した共通ウォレットに関する情報に対する自己の端末２０のユーザによる入力に基づいて、限定ではなく例として、共通アカウントと、自己の端末２０のユーザのユーザアカウントとが関連付けられた統合アカウントコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１コードリーダ画面の一例）を表示部２４に表示するようにしてもよいし、そのようにしなくてもよい。
このような構成により得られる効果の一例として、第２アカウントに関連付けられた第３コード情報、または第３コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、共通アカウント情報に対する端末のユーザによる入力に基づいて、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとが関連付けられた第１コード情報、またはコード情報の読み取りに関する表示である第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
また、上記において、利用者提示型のコード決済を適用する場合、端末２０が、自己の端末２０のユーザのユーザアカウントが関連付けられたコード情報（支払いコード等）に代えて、限定ではなく例として、共通アカウントが関連付けられた共通ウォレットコード情報（限定ではなく、第１アカウントに関連付けられた第３コード情報の一例）を表示するようにしてもよいし、そのようにしなくてもよい。
また、上記において、店舗提示型のコード決済を適用する場合、端末２０が、自己の端末２０のユーザのユーザアカウントが関連付けられたコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面に代えて、限定ではなく例として、共通ウォレットコードリーダ情報に基づく、支払い店舗コードを読み取るためのコードリーダ画面（限定ではなく、第１アカウントに関連付けられた第３コード情報の一例）を表示するようにしてもよいし、そのようにしなくてもよい。
このような構成により得られる効果の一例として、第１アカウントに関連付けられた第３コード情報、または第３コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。また、共通アカウント情報に対する端末のユーザによる入力に基づいて、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとが関連付けられた第１コード情報、またはコード情報の読み取りに関する表示である第１コードリーダ情報を端末の表示領域に表示して決済に利用させることができる。
＜第７変形例（９）＞
第７実施例において、第４変形例（９）と同様に、コード決済に代えて、無線通信（近距離無線通信を含む。）によって決済を行うようにすることもできる。
これは、第４変形例（９）で説明した処理を、第７実施例で説明したアカウント統合に適用することで同様に実現可能である。
＜第８実施例＞
第８実施例は、前述した立替金額の請求・送金に関連する実施例である。立替金額の請求・送金は、前述した第２実施例～第７実施例のいずれにも適用可能である。
第８実施例では、共通ウォレットメンバーの端末２０が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレットの電子マネー残高から実行する。支払い時に共通ウォレットの電子マネー残高が不足している場合には、ユーザの電子マネー口座から共通ウォレットへ送金を行うことで、共通ウォレットの残高不足を補う。
その上で、第８実施例では、共通ウォレットを破棄する場合に、ユーザの電子マネー口座残高から立て替えられた金額を請求する。
第８実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
「共通ウォレットの破棄」とは、共通ウォレットを終了させること、より具体的には、限定ではなく例として、以後共通ウォレットを使用しないために削除することを意味する。
限定でなく例として、共通ウォレットメンバーの代表者の端末２０や、他の共通ウォレットメンバーの端末２０からの破棄依頼によって、サーバ１０で記憶・管理されている共通ウォレットのデータを削除する共通ウォレット破棄処理が実行される。
１回ごとの共通ウォレットメンバーの端末における支払い処理については、限定ではなく例として、第４実施例の図４－４～図４－５と同様に実行することが可能であるため、ここでは詳細な説明を省略する。
＜データ構成＞
図８－１は、本実施例においてサーバ１０の記憶部１５に記憶される共通ウォレット管理データベース１５７の一例である第２の共通ウォレット管理データベース１５７Ｂのデータ構成例を示す図である。
第２の共通ウォレット管理データベース１５７Ｂには、共通ウォレットＩＤごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤと、立替履歴データとが関連付けて記憶される。
共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤとは、第１の共通ウォレット管理データベース１５７Ａと同様である。
立替履歴データは、この共通ウォレットを用いて支払いを行い、共通ウォレット残高不足によって決済予定金額の一部または全部がユーザの電子マネー口座残高から立て替えられた場合に、この共通ウォレットに対して実行される立て替え払いの履歴を記録するためのデータであり、限定ではなく例として、立替者ＩＤと、立替者名と、立替日時と、立替金額とが関連付けて記憶される。
立替者ＩＤは、この共通ウォレットの残高不足に対して、自身の電子マネー口座残高を用いて立て替え払いを実行する実行者（立替者）を識別するための識別子であり、限定ではなく例として、立て替え払いを行うユーザの支払いアプリケーションＩＤが記憶される。
立替者名は、立替者の名称であり、限定ではなく例として、立替者ＩＤに対応するユーザ名が記憶される。
立替日時は、立て替え払いが行われる日時を記録する項目であり、限定ではなく例として、サーバ１０の制御部１１が、図４－５のＳ１７０ａのステップを実行した日時が記憶される。
立替金額は、共通ウォレット残高不足が発生して、ユーザの電子マネー口座残高から立て替えられた金額であり、限定ではなく例として、図４－４のＳ２５０ａのステップで算出される決済残高不足額が記憶される。
共通ウォレットメンバーの端末（限定ではなく例としてユーザＡ．Ａの端末Ａ）において、図４－４～図４－５に従い、決済処理（第1決済処理）が実行されるとする。そして、限定ではなく例として、図４－４のＳ２５０ａのステップで決済処理が失敗し、決済残高不足額が「１，０００円」であったとする。
サーバ１０の制御部１１は、図４－５のＳ１７０ａのステップにおいて、決済処理が成功すると、決済処理を実行中の支払いアプリケーションＩＤ（この例ではユーザＡ．Ａの支払いアプリケーションＩＤである「Ｕ０００１」）と、そのユーザ名（この例では「Ａ．Ａ」）と、決済処理を実行した日時（この例では「２０２０／５／１／＊＊：＊＊：＊＊」）と、図４－４のＳ２７０ａのステップで送信した決済残高不足額（＝立替金額）（この例では「１，０００円」）とを、立替履歴データに関連付けて追記させる。
なお、決済残高不足額が「０」、もしくは、図４－５のＳ１７０ａのステップにおいて、決済処理が失敗した場合には、立替履歴データへの追記処理は実行されない。
また、端末Ｂにおいて、図４－４～図４－５に従い、別の決済処理（第２決済処理）が実行されるとする。この場合、限定ではなく例として、決済残高不足額を「３，０００円」とし、ユーザＢ．Ｂの電子マネー口座から共通ウォレットに送金することで決済処理が成功する場合、サーバ１０の制御部１１は、決済処理を実行中の支払いアプリケーションＩＤ（この例ではユーザＢ．Ｂの支払いアプリケーションＩＤである「Ｕ０００２」）と、そのユーザ名（この例では「Ｂ．Ｂ」）と、決済処理を実行した日時（この例では「２０２０／５／５／＊＊：＊＊：＊＊」）と、決済残高不足額（＝立替金額）（この例では「３，０００円」）とを、立替履歴データに関連付けて追記させる。
共通ウォレットメンバーのいずれかの端末２０（限定ではなく例としてユーザＡ．Ａの端末Ａ）において、共通ウォレットを破棄することが選択されると、端末Ａの制御部２１は、共通ウォレット破棄要請情報を通信Ｉ／Ｆ２２によってサーバ１０に送信する。
通信Ｉ／Ｆ１４によって端末Ａから共通ウォレット破棄要請情報を受信すると、サーバ１０の制御部１１は、立替履歴データに記憶されるそれぞれの立替金額について、立替金額の請求処理を実行する。
限定ではなく例として、図８－１に例示する第２の共通ウォレット管理データベース１５７Ｂでは、立替履歴データに基づいて、まず端末Ｂに対して、「２０２０／５／１／＊＊：＊＊：＊＊」の支払い立替額である「５００円」（＝１，０００円÷２名）が請求される。次いで、端末Ａに対して、「２０２０／５／５／＊＊：＊＊：＊＊」の支払い立替額である「１，５００円」（＝３，０００円÷２名）が請求される。
個別の請求処理については、限定ではなく例として、図４－９と同様に実行することが可能であるため、詳細については説明を省略する。
なお、限定ではなく例として、端末Ａにおいて、共通ウォレットを破棄することが選択される際、自身の立替金額の請求を行わないことが選択される場合、サーバ１０の制御部１１は、端末Ｂに対して「２０２０／５／１／＊＊：＊＊：＊＊」の支払い立替額を請求しない旨を含む情報を送信するなどして、請求処理を実行しないようにしてもよい。
立替履歴データに記憶された全ての立替金額について、立替金額の請求処理が実行されると、サーバ１０の制御部１１は、共通ウォレット破棄処理を実行する。
なお、端末が実行する支払い処理は、第４実施例に限定されず、第２実施例～第７実施例のいずれにも適用可能である。
アカウント統合処理を伴う場合には、立替金額として、ユーザの電子マネー口座残高によって立て替えられる金額を用いればよい。
＜第８実施例の効果＞
第８実施例は、支払い立替額請求情報が、共通ウォレットの破棄（限定ではなく、共通アカウントの破棄の一例）に基づいて、第２の端末２０（請求を受ける端末２０）に送信される構成を示している。
このような構成により得られる効果の一例として、共通アカウントの破棄に基づいて、決済に基づく請求情報が端末に送信されるようにすることができる。
また、第８実施例は、上記の支払い立替額請求情報は、第２の端末２０のユーザに対する支払い立替額請求情報（限定ではなく、第１請求情報の一例）であり、共通アカウントと、第２の端末２０（請求元の端末２０）のユーザのユーザアカウント（限定ではなく、第２アカウントの一例）とに基づき、決済に関する処理（限定ではなく、第２決済に関する処理の一例）が実行され、第２の端末２０のユーザによる決済（限定ではなく、第２決済の一例）に基づく、第１の端末２０のユーザに対する支払い立替額請求情報（限定ではなく、第１請求情報とは異なる第２請求情報の一例）は、共通ウォレットの破棄に基づいて、第１の端末２０（限定ではなく、第１端末の一例）に送信される構成を示している。
このような構成により得られる効果の一例として、第２決済に基づく、第１請求情報とは異なる第２請求情報が、共通アカウントの破棄に基づいて、第１端末に送信されるようにすることができる。
また、本実施例は、端末２０が、支払い立替額を請求しない旨を含む情報（限定ではなく、請求情報を変更することに関する情報の一例）を、共通ウォレットメンバーの端末２０の少なくとも一つに通信Ｉ／Ｆ２２によって送信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの端末の少なくとも一つに請求情報を変更することに関する情報を送信することによって、請求情報を変更することを通知することができる。
＜第８変形例（１）＞
第８実施例では、共通ウォレットを破棄する場合に、共通ウォレットを用いてそれまでに実行された立替金額の請求を実行したが、これに限定されない。
本変形例では、共通ウォレットメンバーの端末２０が、支払いアプリケーションを利用して、加盟店での支払いを共通ウォレットの電子マネー残高から、もしくは共通ウォレットとユーザの電子マネー口座との統合アカウントの電子マネー残高から実行する。そして、共通ウォレット破棄操作を行う際、ユーザアカウントから共通ウォレットへの送金額と、ユーザアカウントによって立て替えられる立替金額とに基づいて、共通ウォレット残高をユーザアカウントに配分して送金（返金）する。
以下では、ユーザアカウントから共通ウォレットへ送金することを「共通ウォレットへの出資」と称し、その送金額を「出資金額」と称する。
１回ごとの共通ウォレットメンバーの端末における支払い処理については、限定ではなく例として、第６実施例の図６－１、図６－２、図４－５と同様に実行することが可能であるため、ここでは詳細については説明を省略する。
図８－２は、サーバ１０の記憶部１５に記憶される、共通ウォレット管理データベース１５７の一例である第３の共通ウォレット管理データベース１５７Ｃのデータ構成例を示す図である。
第３の共通ウォレット管理データベース１５７Ｃには、共通ウォレットＩＤごとの管理データとして、共通ウォレット管理データが記憶される。
各々の共通ウォレット管理データには、限定ではなく例として、共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤと、共通ウォレット生成日時と、出資履歴データと、支払い履歴データとが関連付けて記憶される。
共通ウォレットＩＤと、共通ウォレット名と、共通ウォレット残高と、共通ウォレットメンバーＩＤとは、第１の共通ウォレット管理データベース１５７Ａと同様である。
共通ウォレット生成日時には、共通ウォレットが生成された日時が記憶される。
出資履歴データは、この共通ウォレットに対して実行される出資の履歴データであり、限定ではなく例として、出資者ＩＤと、出資者名と、出資日時と、出資金額とが関連付けて記憶される。
出資者ＩＤは、この共通ウォレットに対して出資を実行する実行者（出資者）を識別するための識別子であり、限定ではなく例として、出資を行うユーザの支払いアプリケーションＩＤが記憶される。
出資者名は、出資者の名称であり、限定ではなく例として、出資者ＩＤに対応するユーザ名が記憶される。
出資日時は、出資が行われる日時であり、限定ではなく例として、出資者が共通ウォレットへの出資を実行した日時が記憶される。
出資金額は、出資者が実行したこの共通ウォレットへの出資あたりの出資金額である。
図８－２では、限定ではなく例として、共通ウォレット「キャンプ資金」に対して、ユーザＡ．Ａが「２０２０／３／１１／＊＊：＊＊：＊＊」に「３，０００円」を、「２０２０／４／１４／＊＊：＊＊：＊＊」に「３，０００円」を出資したことが示されている。また、限定ではなく例として、ユーザＢ．Ｂが「２０２０／３／１２／＊＊：＊＊：＊＊」に「３，０００円」を、「２０２０／４／１４／＊＊：＊＊：＊＊」に「３，０００円」を出資したことが示されている。
支払い履歴データは、この共通ウォレットを用いて実行され、成立した支払いの履歴データであり、限定ではなく例として、支払い者ＩＤと、店舗名と、支払い日時と、支払い金額と、立替金額と、回収フラグとが関連付けて記憶される。
支払い者ＩＤは、加盟店において、この共通ウォレットを用いて支払いを実行する実行者（支払い者）を識別するための識別子であり、限定ではなく例として、支払いを行うユーザの支払いアプリケーションＩＤが記憶される。
店舗名は、支払いが行われる加盟店を識別するための名称であり、限定ではなく例として、加盟店が支払いアプリケーション利用登録の際に登録を行うその店舗もしくはサービスの名称が記憶される。
支払い日時は、その店舗名の加盟店において、支払いアプリケーションによって支払い者が支払いを実行する日時であり、限定ではなく例として、サーバ１０の制御部１１において決済処理や統合アカウント決済処理が実行され、成功した日時が記憶される。
支払い金額は、その店舗名の加盟店において、支払いアプリケーションによって支払いが実行される決済予定金額であり、限定ではなく例として、サーバ１０の制御部１１が通信Ｉ／Ｆ１４によって店舗コードリーダ装置５０から受信する決済要求情報に基づく決済予定金額が記憶される。
立替金額は、支払いが共通ウォレットとユーザの電子マネー口座との統合アカウントの電子マネー残高から実行される場合、共通ウォレット残高不足によってユーザの電子マネー口座残高から立て替えられた金額であり、限定ではなく例として、統合アカウント決済処理の結果に基づく支払い者の電子マネー口座からの支払い額が記憶される。なお、統合アカウント決済処理が実行されない場合には、立替金額は「０」とする。
回収フラグは、立替金額が「０」より大きい場合、支払い都度ごとに立替金額の請求が行われ、精算が完了しているか否かを記録するためのフラグ情報であり、限定ではなく例として、サーバ１０の制御部１１において精算送金処理が実行され、成功した場合には、限定ではなく例として「済」が記憶される。サーバ１０の制御部１１において精算送金処理が実行されていない、もしくは精算請求処理が失敗した場合には、限定ではなく例として「未」が記憶される。また、立替金額が「０」の場合には、精算を実行する必要がないため、限定ではなく例として「－」が記憶される。
支払い都度ごとの立替金額の請求処理については、限定ではなく例として、図６－７と同様に実行することが可能であるため、詳細については説明を省略する。
限定ではなく例として、図８－２では、支払い履歴データには、共通ウォレット「キャンプ資金」を用いて、支払い者「Ｕ０００１」（すなわちユーザＡ．Ａ）が、「２０２０／４／５／＊＊：＊＊：＊＊」に、店舗「ＥＥスーパー」で、「５，０００円」の支払いを行ったことが示されている。また、支払い者「Ｕ０００１」（すなわちユーザＡ．Ａ）が、「２０２０／４／１１／＊＊：＊＊：＊＊」に、店舗「ＡＡスポーツ」で、「３，０００円」の支払いを行い、ユーザＡ．Ａの電子マネー口座で「２，０００円」を立て替え、立替分の精算がまだ完了していない「未」であることが示されている。
通信Ｉ／Ｆ１４によって、限定ではなく例として、端末Ａから共通ウォレット破棄要請情報を受信すると、サーバ１０の制御部１１は、第３の共通ウォレット管理データベース１５７Ｃの共通ウォレット管理データに基づいて、共通ウォレット精算破棄処理を実行する。
共通ウォレット精算破棄処理では、まず出資履歴データの出資者ＩＤごとに、出資者ごとの合計出資金額を算出する。次いで、支払い履歴データの支払い者ＩＤごとに、支払い者ごとの合計立替金額を算出する。なお、合計立替金額の算出では、回収フラグ「未」となっている立替金額のみを合算対象とする。
限定ではなく例として、図８－２では、ユーザＡ．Ａの合計出資金額は「６，０００円」（＝３，０００円＋３，０００円）となり、ユーザＢ．Ｂの合計出資金額は「６，０００円」（＝３，０００円＋３，０００円）となる。また、ユーザＡ．Ａの合計立替金額は「２，０００円」となり、ユーザＢ．Ｂの合計立替金額は「６，０００円」となる。
次に、全ての共通ウォレットメンバーの合計出資金額と、合計立替金額とを合わせた金額を共通ウォレット「キャンプ資金」の総出資金額として算出する。限定ではなく例として、図８－２では、総出資金額は「２０，０００円」（＝６，０００円＋６，０００円＋２，０００円＋６，０００円）である。
その後、共通ウォレット精算破棄処理を実行する時点で共通ウォレットから支出した共通ウォレットメンバー１人あたりの平均支払い額を「（総出資金額―共通ウォレット残高）÷共通ウォレットメンバー人数」によって算出する。
限定ではなく例として、図８－２では、平均支払い額は「（２０，０００円－６，０００円）÷２＝７，０００円」となる。
次いで、共通ウォレットメンバーＩＤに記憶される支払いアプリケーションＩＤごとに、共通ウォレット残高を出資額の割合に基づいて返金するための返金予定額を算出する。返金予定額は「（合計出資金額＋合計立替金額）－平均支払い額」で算出される。
返金予定額は、それぞれのユーザが共通ウォレットに対して直接的に出資した金額（合計出資金額）と、立て替えることで間接的に出資した金額（合計立替金額）との合計から、共通ウォレットにおける支払い金額を均等割りした金額を減算した金額となる。
限定ではなく例として、図８－２では、ユーザＡ．Ａへの返金予定額は「６，０００円＋２，０００円－７，０００円＝１，０００円」となり、ユーザＢ．Ｂへの返金予定額は「６，０００円＋６，０００円－７，０００円＝５，０００円」となる。
最後に、サーバ１０の制御部１１は、共通ウォレットメンバーのそれぞれの電子マネー口座に対して、共通ウォレット残高を用いて返金予定額を送金する返金処理を実行する。
なお、返金予定額が負になる場合には、返金予定額の絶対値を送金金額として、そのユーザの電子マネー口座から共通ウォレットへ送金することで精算を行う。
共通ウォレット精算破棄処理が実行され、共通ウォレット残高が「０」になると、サーバ１０の制御部１１は、共通ウォレット破棄処理を実行する。
なお、端末が実行する支払い処理は、第６実施例に限定されず、第２実施例～第７実施例のいずれにも適用可能である。
共通ウォレットへの送金処理を実行する場合には、立替金額として、共通ウォレットでの支払いを成立させるにあたり共通ウォレットへの送金が少なくとも必要となる金額である、決済残高不足額を記憶させればよい。
＜表示画面例＞
図８－３は、図３－３のキャンプ資金支払い画面において「ウォレット破棄」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合に表示されるキャンプ資金のサマリー表示画面の一例を示す図である。以下説明する表示画面例は、図８－２の例を適用した画面図である。
この例では、タイトルバーの下には、「Ｐａｙｍｅｎｔ Ａｐｐ」の階層メニューにおける現在位置として、現在実行中のサブメニューである「キャンプ資金」が表示されている。また、「キャンプ資金」の下には、ユーザに対する操作案内として「ウォレット破棄」が表示され、その下には、キャンプ資金のサマリー表示領域２４５２が表示されている。
キャンプ資金のサマリー表示領域２４５２は、３段に分けて表示されており、上段には、現在の日付として「２０２０年４月１５日」が表示され、その下には、角財布の画像および共通ウォレットの名称（キャンプ資金）のサマリーが表示されている。
中段には、キャンプ資金の共通ウォレット残高として、「残高」の文字とともに「６，０００円」が表示されている。また、それらの横には、作成日として「２０２０年３月１１日」が表示されており、その下には、キャンプ資金の共通ウォレットメンバーの人数として「２人」が表示されている。そして、その下には、共通ウォレットメンバーである、ユーザＡ．Ａのアイコン画像とユーザＢ．Ｂのアイコン画像とが表示されている。
また、下段には、総出資金額として「２０，０００円」が、総支払い金額として「１４，０００円」がそれぞれ表示されている。総支払い金額は、限定ではなく例として「総出資金額―共通ウォレット残高」で算出される金額である。
また、キャンプ資金のサマリー表示領域２４５２の下には、各々のメンバーへの返金予定額がリスト形式で表示されている。
返金予定額の１行目には、ユーザＡ．Ａのアイコン画像とともに、ユーザ名「自分」の文字が表示され、その横に、返金予定額として、この例では「１，０００円」が表示されている。また、その横には、自分の返金予定額の修正するための修正ボタンＢＴ９と、自分の返済予定額の詳細を確認するための詳細ボタンＢＴ１０とが並べて表示されている。
また、返金予定額の２行目には、ユーザＢ．Ｂのアイコン画像とともに、ユーザ名「Ｂ．Ｂ」の文字が表示され、その横に、返金予定額として、この例では「５，０００円」が表示されている。また、その横には、ユーザＡ．Ａと同様に、修正ボタンＢＴ９と、詳細ボタンＢＴ１０とが並べて表示されている。
また、画面下部には、共通ウォレットの破棄をキャンセルするためのキャンセルボタン２４２Ｒと、共通ウォレットの破棄を実行するための破棄ボタン２４２Ｓとが並べて表示されている。
図８－４は、図８－３のキャンプ資金のサマリー表示画面において、自分の行における詳細ボタンＢＴ１０がタッチ操作された場合に表示される自分のサマリー表示画面の一例を示す図である。
この例では、自分のサマリー表示領域２４５３は、２段に分けて表示されており、上段には、現在の日付として「２０２０年４月１５日」が表示され、その下に、ユーザＡ．Ａのアイコン画像とともに、ユーザ名「自分」の文字が表示されている。下段には、出資金額として「出資の金額」の文字が表示されるとともに、その横にユーザＡ．Ａの合計出資金額である「６，０００円」が表示されている。
また、その下には、支払い金額として「支払い金額」の文字が表示されるとともに、その横に共通ウォレット「キャンプ資金」を用いたユーザＡ．Ａの支払い金額の合計額である「８，０００円」が表示されている。その下には、立替金額として「立替金額」の文字が表示されるとともに、その横にユーザＡ．Ａの合計立替金額である「２，０００円」が表示されている。
また、自分のサマリー表示領域２４５３の下には、自分の利用履歴が、リスト形式にて時系列順に表示されている。１行目には、利用日の日時として「２０２０年３月１１日２０時５５分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「３，０００円」が表示されている。
２行目には、利用日の日時として「２０２０年４月５日１１時１２分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として、「ＥＥスーパー」が表示されている。また、その横に、支払い金額として「５，０００円」が表示されている。
３行目には、利用日の日時として「２０２０年４月１１日１６時３０分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として「ＡＡスポーツ」が表示されている。その横には、支払い金額として「３，０００円」が表示されている。また、その下には、利用項目として「立替」の文字が表示されるとともに、立替金額として「２，０００円」が表示されている。
４行目には、利用日の日時として「２０２０年４月１４日１２時２１分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「３，０００円」が表示されている。
また、自分のサマリー表示領域２４５３の最下部には、戻るアイコン２４２Ｔが表示されている。
図８－５は、図８－３のキャンプ資金のサマリー表示画面において、ユーザＢ．Ｂの行における詳細ボタンＢＴ１０がタッチ操作された場合に表示されるユーザＢ．Ｂのサマリー表示画面の一例を示す図である。
この例では、ユーザＢ．Ｂのサマリー表示画面について説明するが、上記の自分のサマリー表示画面と表示形式は同一となっている。
ユーザＢ．Ｂのサマリー表示画面では、ユーザＢ．Ｂのサマリー表示領域２４５４は、２段に分けて表示されており、上段には、現在の日付として「２０２０年４月１５日」が表示され、その下に、ユーザＢ．Ｂのアイコン画像とともに、ユーザ名「Ｂ．Ｂ」の文字が表示されている。下段には、出資金額として「出資の金額」の文字が表示されるとともに、その横にユーザＢ．Ｂの合計出資金額である「６，０００円」が表示されている。
また、その下には、支払い金額として「支払い金額」の文字が表示されるとともに、その横に共通ウォレット「キャンプ資金」を用いたユーザＢ．Ｂの支払い金額の合計額である「６，０００円」が表示されている。その下には、立替金額として「立替金額」の文字が表示されるとともに、その横にユーザＢ．Ｂの合計立替金額である「６，０００円」が表示されている。
また、ユーザＢ．Ｂのサマリー表示領域２４５４の下には、ユーザＢ．Ｂの利用履歴が、リスト形式にて時系列順に表示されている。１行目には、利用日の日時として「２０２０年３月１２日８時２４分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「３，０００円」が表示されている。
２行目には、利用日の日時として「２０２０年４月１２日１２時５分」が表示されており、その下に、利用項目として「支払い」の文字が表示されるとともに、支払い先として「ＢＢホームセンター」が表示されている。また、その横に、支払い金額として「６，０００円」が表示されている。また、その下には、利用項目として「立替」の文字が表示されるとともに、立替金額として「６，０００円」が表示されている。
３行目には、利用日の日時として「２０２０年４月１４日１５時３８分」が表示されており、その下に、利用項目として「出資」の文字が表示されるとともに、出資金額として「３，０００円」が表示されている。
また、ユーザＢ．Ｂのサマリー表示領域２４５４の最下部には、戻るアイコン２４２Ｔが表示されている。
本変形例は、端末２０のユーザの入力に基づいて、支払い立替額請求情報に基づく共通ウォレットへの送金処理が実行される。第１の端末２０のユーザアカウント（限定ではなく、第１アカウントの一例）は、第１の端末２０のユーザによる決済（限定ではなく、第１決済の一例）によって第１の端末２０のユーザアカウントから支払われた金額以上、またはそれよりも多くの金額が共通ウォレットに含まれている場合、第１の端末２０のユーザによる決済によって第１の端末２０のユーザのユーザアカウントから支払われた金額が共通ウォレットから送金される構成を示している。
このような構成により得られる効果の一例として、第１アカウントは、第１決済によって第１アカウントから支払われた金額以上、またはそれよりも多くの金額が共通アカウントに含まれている場合、第１決済によって第１アカウントから支払われた金額が共通アカウントから送金されるようにすることができる。
また、本変形例は、端末２０が、自己の端末２０のユーザへの返金予定額の修正するための情報（限定ではなく、返金に関する情報を変更することに関する情報の一例）を、サーバ１０を介して他の端末２０に通信Ｉ／Ｆ２２によって送信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントによって決済可能なユーザの端末の少なくとも一つに返金情報を変更することに関する情報を送信することによって、返金情報を変更することを通知することができる。
＜第８変形例（２）＞
第８変形例（１）では、サーバ１０の制御部１１が、共通ウォレットメンバーのそれぞれの電子マネー口座に対して、共通ウォレット残高を用いて返金予定額を送金する返金処理を実行することとしたが、これに限定されない。限定ではなく例として、以下のような処理を実行するようにしてもよい。
共通ウォレットを破棄する場合、サーバ１０の制御部１１は、共通ウォレット残高を均等割りした金額（以下、「１人あたり仮返金額」と称する。）を、各々のユーザに仮返金する仮返金処理を実行する。そして、制御部１１は、この１人あたり仮返金額と、第８変形例（１）で説明した返金予定額（＝（合計出資金額＋合計立替金額）－平均支払い額）とに基づいて、各々のユーザの送金額／受金額を算出・決定する。そして、算出・決定した送金額／受金額に基づく送金処理／受金処理を端末２０に実行させることで、最終的な金額を調整する。
図８－２に示した金額の例で説明する。
共通ウォレットを破棄する場合の共通ウォレット残高は「６，０００円」であるため、サーバ１０の制御部１１は、１人あたり仮返金額を「６０００円÷２名＝３０００円」として、ユーザＡ．ＡとユーザＢ．Ｂとに仮返金する。
その一方、図８－２の例では、ユーザＡ．Ａへの返金予定額は「６，０００円＋２，０００円－７，０００円＝１，０００円」であり、ユーザＢ．Ｂへの返金予定額は「６，０００円＋６，０００円－７，０００円＝５，０００円」である。このため、ユーザＡ．Ａは２，０００円もらい過ぎである一方、ユーザＢ．Ｂは２，０００円足りないことになる。そこで、制御部１１は、ユーザＡ．ＡのユーザアカウントからユーザＢ．Ｂのユーザアカウントに対して「２，０００円」を送金することを通知する情報を、ユーザＡ．Ａの端末２０と、ユーザＢ．Ｂの端末２０とに通信Ｉ／Ｆ１４によってそれぞれ送信する。そして、制御部１１は、ユーザＡ．Ａの電子マネー口座残高から「２，０００円」を減算するとともに、ユーザＢ．Ｂの電子マネー口座残高に「２，０００円」を加算する。そして、制御部１１は、共通ウォレット破棄処理を実行する。
本変形例は、共通ウォレットを破棄する場合、第２の端末２０は、第１の端末２０（限定ではなく、第１端末の一例）から共通ウォレットに対して送金された金額（限定ではなく、第２金額の一例）の情報と、第２の端末２０から共通ウォレットに対して送金された金額（限定ではなく、第１金額の一例）の情報とに少なくとも基づき、第２の端末２０のユーザのユーザアカウントから第１の端末２０のユーザのユーザアカウントへ送金することを通知する情報（限定ではなく、端末のユーザから第１端末の第１ユーザへ送金することに関する情報の一例）、または第１の端末２０のユーザのユーザアカウントから第２の端末２０のユーザのユーザアカウントへ送金することを通知する情報（限定ではなく、第１端末の第１ユーザから端末のユーザへ送金することに関する情報の一例）を通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる効果の一例として、共通アカウントに対する送金を実現することができる。また、共通アカウントを破棄する場合、第１端末から共通アカウントに対して送金された第２金額の情報と、第１金額の情報とに少なくとも基づき、ユーザから第１ユーザへ送金することに関する情報、または第１ユーザからユーザへ送金することに関する情報を受信して、端末のユーザに報知することができる。
また、本変形例は、上記の第２の端末２０のユーザのユーザアカウントから第１の端末２０のユーザのユーザアカウントへ送金することを通知する情報、または第１の端末２０のユーザのユーザアカウントから第２の端末２０のユーザのユーザアカウントへ送金することを通知する情報は、第２の端末２０から共通ウォレットに送金された金額（限定ではなく、第１金額の一例）と、第１の端末２０から共通ウォレットに送金された金額（限定ではなく、第２金額の一例）と、共通ウォレット残高（限定ではなく、共通アカウントの残高の一例）とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第１金額と、第２金額と、共通アカウントの残高とに基づいて、ユーザから第１ユーザへ送金することに関する情報、または第１ユーザからユーザへ送金することに関する情報を適切に決定することができる。
また、本変形例は、第１の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントの一例）と、共通アカウントとに基づき、第１の端末２０（限定ではなく、第１ユーザの第１端末の一例）によって決済に関する処理が実行され、第２の端末２０は、第１の端末２０のユーザによる決済に基づく支払い立替額請求情報（限定ではなく、第１決済に基づく金額の請求に関する請求情報の一例）を、共通ウォレットの破棄に基づいて、通信Ｉ／Ｆ２２によって受信する構成を示している。
このような構成により得られる効果の一例として、第１決済に基づく金額の請求に関する請求情報を、共通アカウントの破棄に基づいて受信することができる。
また、本変形例は、サーバ１０が、少なくとも第２の端末２０のユーザ（限定ではなく、端末のユーザの一例）と、第１の端末２０のユーザ（限定ではなく、第１ユーザの一例）とが決済可能な共通アカウントに対して第２の端末２０から送金する金額（限定ではなく、第１金額の一例）の情報と、共通アカウントに対して第１の端末２０から送金する金額（限定ではなく、第２金額の一例）の情報とを通信Ｉ／Ｆ２２によって受信する。そして、サーバ１０は、共通ウォレットの破棄に基づいて、上記の送金する金額の情報に基づき、第２の端末２０のユーザのユーザアカウントから第１の端末２０のユーザアカウントへの送金処理（限定ではなく、端末のユーザのアカウントから第１端末の第１ユーザのアカウントへ送金することに関する処理の一例）、または第１の端末２０のユーザのユーザアカウントから第２の端末２０のユーザのユーザアカウントへの送金処理（限定ではなく、第１端末の第１ユーザのアカウントから端末のユーザのアカウントへ送金することに関する処理の一例）を制御部１１によって実行する構成を示している。
このような構成により得られる効果の一例として、共通アカウントの破棄に基づいて、第１金額の情報と、第２金額の情報とに少なくとも基づき、ユーザのアカウントから第１ユーザのアカウントへ送金することに関する処理、または第１ユーザのアカウントからユーザのアカウントへ送金することに関する処理をサーバの制御部によって実行して、適切に金額を精算することができる。
＜第９実施例＞
次に、前述した「（Ｂ）アカウント連携決済」の実施例について説明する。第９実施例は、アカウント連携決済を実現する実施例である。
第９実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、アカウント連携の一例として、メッセージングアプリケーションで形成されたグループに含まれるユーザ（以下、「グループメンバー」と称する。）のユーザアカウントを連携する実施例について説明する。これを実現するサーバ１０の構成は、図３－２０と同様である。
本実施例では、サーバ１０がアカウント連携処理を実行することとして説明する。
なお、これに限らず、アカウント連携処理を端末２０で実行するようにしてもよいし、そのようにしなくてもよい。
＜表示画面例＞
以下では、前述したメッセージングアプリケーションにおけるトークルームを例に挙げて表示画面例について説明する。前述したようにメッセージングアプリケーションを利用したトークは「チャット」の一例であり、トークルームは「チャットルーム」の一例である。
以下では、メッセージングアプリケーションにおいて形成されたグループに含まれる複数のグループメンバーのユーザアカウントを連携して、アカウント連携決済を行う場合を例示する。
図９－１は、図５－３０と同様に、図３－１のサブメニューにおいて「自分のウォレット」（図示せず）がタッチ操作され、自分のウォレット画面において「コード支払い」と示されたアイコンが端末２０のユーザＡ．Ａによってタッチ操作された場合にユーザＡ．Ａの端末２０の表示部２４に表示されるコード支払い画面（連携前）の一例を示す図である。
自分のウォレットからのコード支払い領域２４５１内の上部において、がま口財布のアイコン画像ともに「自分のウォレット」の文字が表示されている下に、図５－３では「ウォレット統合」の文字が表示されているのに対し、図９－１では鎖のマークとともに「ウォレット連携」の文字が表示され、その横に、ウォレット連携の「ＯＮ／ＯＦＦ」を切り替えるためのスライドボタンＣＮ７が表示されている。ウォレット連携は、アカウント連携と実質的に同義である。
図９－２は、図９－１においてスライドボタンＣＮ７がタッチ操作された場合に表示されるトークルーム選択画面の一例を示す図である。
この画面には、限定ではなく例として、メッセージアプリケーションのアプリケーション名である「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」が最上段のタイトルバーに表示され、その横に、ユーザＡ．Ａのアイコン画像と、ユーザ名「Ａ．Ａ」の文字とが表示されている。タイトルバーの下には、「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の階層メニューにおける現在位置が表示されている。
具体的には、限定ではなく例として、現在実行中の最上位のメニューである「ウォレット連携」が表示されている。その下には、「トークルームを選択」の文字が表示され、その横に、この画面を閉じるための「×アイコン」が表示されている。また、その下には、ユーザに対する操作案内として「ウォレット連携するトークルームを選んでください」の説明文が表示され、その下には、複数のトークルーム（より具体的にはグループトークルーム）がリスト形式で表示されている。
このリストには、ユーザが選択可能に縦方向に並べられた複数の行アイテムが含まれ、行アイテムには、トークルームのトークルームアイコン画像と関連付けて、そのトークルームの名称が表示されている。
この例では、そのリストにおいて、木のアイコン画像と関連付けて「春の摩周湖キャンプ（２）」の文字が表示された行アイテムと、皿上のナイフおよびフォークのアイコン画像と関連付けて「韓国グルメ連合（３）」の文字が表示された行アイテムと、ボールをキャッチしているグローブのアイコン画像と関連付けて「草野球チーム（１０）」の文字が表示された行アイテムとが含まれる。「（）内の数字」は、そのグループに含まれるユーザ（グループメンバー）の人数を示している。
図９－３は、図９－２に示すトークルーム選択画面において「草野球チーム（１０）」の文字が表示されている行アイテムがタッチ操作された場合に表示されるコード支払い画面（連携後）の一例を示す図である。
図９－３が図９－１と異なるのは、コード支払い領域２４５１内において、スライドボタンＣＮ７が「ＯＮ」の状態とされており、その下に、新たにボールをキャッチしているグローブのアイコン画像とともに「草野球チーム（１０）」の文字が表示されていることである。
また、アカウント（ウォレット）が連携されたことで、表示されている支払いコードは図９－１のものとは異なるコードとなっている。
図９－４は、図３－７と同様にサーバ１０による決済処理が完了した場合に端末２０に表示されるコード支払い完了画面の一例を示す図である。
図９－４のコード支払い完了画面が図３－７のコード支払い完了画面と異なるのは、この画面下部において、支払い先が「ＡＡスポーツ株式会社」であることが示されている部分より下の部分である。具体的には、支払い先の表示の下には、下線を介して、新たに「草野球チーム」のグループに関する情報が表示されている。より具体的には、「草野球チーム」のメンバーの人数として「１０人」が表示され、１人あたりの金額として「５００円」が表示されている。
また、画面下部には、コード支払いの完了をユーザが確認したことを通知するための確認ボタン２４２Ｂが表示されている。
図９－５は、端末２０で実行されるメッセージングアプリケーションにおいて表示部２４に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、限定ではなく例として、メッセージングアプリケーションのアプリケーション名である「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」が最上段のタイトルバーに表示されている。タイトルバーの下には、「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」の階層メニューにおける現在位置が表示される。具体的には、限定ではなく例として、現在実行中の最上位のメニューである「草野球チーム（１０）」が表示されている。その下には、トークルーム領域２４６１が設けられており、さらにその下には、アイコン表示領域２４７１が設けられている。
この例では、トークルーム領域２４６１において、上部中央に、日付として「今日」の文字が表示されている。その下には、ユーザＸ．Ｘのアイコン画像とともに、ユーザ名「Ｘ．Ｘ」が表示されており、ユーザＸ．Ｘから「１２時１０分」に発信されたメッセージとして「次の試合で使うボールが足りません…」というメッセージが、画面向かって左側に吹き出しで表示されている。
また、その下には、自己の端末２０のユーザであるユーザＡ．Ａが「１２時３３分」に返信したメッセージとして「ちょうどＡＡスポーツで買い物しているので、購入しておきますね」というメッセージが、画面向かって右側に吹き出しで表示されている。
また、その下には、ユーザＹ．Ｙのアイコン画像とともに、ユーザ名「Ｙ．Ｙ」が表示されており、ユーザＹ．Ｙから「１２時４８分」に発信されたメッセージとして「お願いします！」というメッセージが、画面向かって左側に吹き出しで表示されている。
また、アイコン表示領域２４７１には、限定ではなく例として、「ファイル」、「連絡先」、「位置情報」、「ギフト」、「送金」、「ウォレット連携」にそれぞれ対応する６つのアイコンが表示されている。以下では、「ウォレット連携」に対応するアイコンをウォレット連携アイコンＣＮ８として説明する。
図９－６は、図９－５のトークルーム画面においてウォレット連携アイコンＣＮ８がタッチ操作された場合に表示されるトークルーム画面の一例を示す図である。
図９－６では、図９－５のトークルーム領域２４６１に表示されていたユーザＹ．Ｙから発信された「お願いします！」のメッセージの下に、ユーザＡ．Ａから発信されたメッセージとして、アカウントが連携され、連携されたアカウントから支払いが行われたことを通知するための連携通知メッセージ２４６２が表示されている。
限定ではなく例としてユーザＡ．Ａの端末２０の表示部２４に図９－４が表示されると、支払い管理サーバ１０Ａからメッセージング管理サーバ１０Ｂへ、限定ではなく例としてＡＰＩを介して支払いに関する情報が送信される。すると、限定ではなく例としてメッセージング管理サーバ１０Ｂの制御部によって、連携通知メッセージ２４６２が生成され、アカウントが連携された各端末に自動的にメッセージが送信される。
この連携通知メッセージ２４６２では、上段に［Ｐａｙｍｅｎｔ Ａｐｐ］の文字が表示されており、その下に、鎖のマークとともに、「ウォレット連携支払い」の文字が表示されている。また、その下には、１人あたりの支払い金額が「５００円」であることが表示されている。
また、下段には、支払い先は「ＡＡスポーツ株式会社」であり、支払い金額は「５，０００円」であり、グループメンバーの人数は「１０人」であることが表示されている。また、その下には、詳細内容を確認するための詳細確認アイコンが表示されている。
図９－７は、図９－６に対応するユーザＸ．Ｘの端末２０の表示部２４に表示されるトークルーム画面の一例を示す図であり、ユーザＹ．Ｙから発信された「お願いします！」のメッセージの下に、上記の連携通知メッセージ２４６２が表示されている。
＜第９実施例の効果＞
第９実施例は、端末２０が、自己の端末２０のユーザのユーザアカウント（限定ではなく、第１アカウントの一例）と、他のグループメンバーのユーザアカウント（限定ではなく、第２アカウントの一例）とを連携するための処理（限定ではなく、第１アカウントと第２アカウントとを関連付ける処理の一例）を制御部２１によって実行する。そして、端末２０は、連携された自己の端末２０のユーザのユーザアカウントと他のグループメンバーのユーザアカウントとに基づき、決済に関する処理を制御部２１によって実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが決済可能な第１アカウントと、第１アカウントとは異なる第２アカウントとを関連付けることができる。そして、関連付けられた第１アカウントと、第２アカウントとに基づく決済を実現することができる。
また、第９実施例は、連携する他のグループメンバーのユーザアカウント（限定ではなく、第２アカウントの一例）は、グループトークルーム（限定ではなく、チャットルームの一例）の選択に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、チャットルームの選択という簡単な方法によって、第２アカウントを選択することができる。
＜第９変形例（１）＞
第９実施例では、グループトークルームを選択することでアカウント連携を行ったが、これに限定されない。当然ではあるが、２人のユーザ間でユーザアカウントを連携するといったことも可能である。
限定ではなく例として、ユーザＡ．ＡとユーザＢ．Ｂとの２名のユーザアカウントを連携させて決済を行う場合、ユーザＡ．Ａが、自己の端末２０で実行される支払いアプリケーション、またはメッセージングアプリケーションにおいて、ユーザＢ．Ｂを直接的に選択して、自分のユーザアカウントとユーザＢ．Ｂのユーザアカウントとを連携させるようにしてもよい。この場合、ユーザＡ．ＡのユーザアカウントとユーザＢ．Ｂのユーザアカウントとが連携されて、アカウント連携決済が行われることになる。
なお、ユーザＡ．Ａが勝手にアカウント連携を行うと、ユーザＢ．Ｂに不利益を生ずる可能性がある。このため、ユーザＡ．Ａは、ユーザＢ．Ｂにアカウント連携の許可を取るようにするとよい。
＜第９変形例（２）＞
第９実施例において、第４変形例（９）と同様に、コード決済に代えて、無線通信（近距離無線通信を含む。）によって決済を行うようにすることもできる。
前述した非接触式通信を適用する場合、端末２０のユーザは、自己の端末２０を店舗のカードリーダやカードリーダライタにかざすことによって、上記の実施例と同様に決済を行う。この場合、カードリーダで情報を読み取った結果、自己の端末２０のユーザのユーザアカウントの電子マネー口座残高が不足している場合は、限定ではなく例として、サーバ１０の制御部１１は、その残高が不足していることを示す情報（決済残高不足情報）を通信Ｉ／Ｆ１４によって端末２０に送信する。通信Ｉ／Ｆ２２によってサーバ１０から決済残高不足情報を受信すると、端末２０の制御部２１は、決済残高不足情報を表示部２４に表示させる。そして、端末２０の制御部２１は、表示させた決済残高不足情報に対する自己の端末２０のユーザの入力に基づいて、アカウント連携処理を実行する。そして、端末２０のユーザが、自己の端末２０を店舗のカードリーダに再度かざすことによって、アカウント連携決済を行うようにすることができる。
なお、前述したように、あらかじめアカウントを連携しておくようにすることもできる。
これらは、ブルートゥース通信を適用する場合も同様である。
本変形例は、決済に関する処理は、端末２０の通信Ｉ／Ｆ２２による、店舗コードリーダ装置５０（限定ではなく、決済によって購入する商品を販売するまたはサービスを提供する店舗の端末の一例）との無線通信により実行される構成を示している。
このような構成により得られる効果の一例として、第１決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信によって決済を実現することができる。
また、本変形例は、上記の無線通信は、近距離通信である構成を示している。
このような構成により得られる効果の一例として、第１決済によって購入する商品を販売するまたはサービスを提供する店舗の端末との無線通信を近距離通信によって実現することができる。
＜第９変形例（３）＞
第９実施例で説明したアカウント連携決済を、一時的に共通ウォレットを作成し、その共通ウォレットを用いて決済する共通アカウント決済とすることもできる。
具体的には、限定ではなく例として、図９－２のトークルーム選択画面においてアカウント連携決済を行うグループトークルームが選択された場合、サーバ１０は、選択されたグループトークルームのメンバーを共通ウォレットメンバーとする一時的な共通ウォレット（共通ウォレット残高＝０）を作成する。
作成された共通ウォレットから決済を行おうとすると、共通ウォレット残高が「０」であるため、決済は失敗することになる。この場合、限定ではなく例として、前述した第２実施例～第７実施例で説明した手法を適用して決済を行うようにすることができる。
つまり、この場合、前述した第２実施例～第７実施例で説明した内容を同様に適用することができる。
また、共通ウォレットを破棄する場合は、第８実施例で説明した内容を同様に適用することができる。
＜第１０実施例＞
第１０実施例は、前述した各種の実施例における２つのアカウント（第１アカウントと第２アカウント）の組み合わせ（バリエーション）に関する実施例である。
図１０は、第１アカウントと第２アカウントとの組み合わせを説明するためのテーブルの一例を示す図である。
このテーブルには、限定ではなく例として、パターンと、第１アカウントと、第２アカウントとが関連付けて定められている。以下、それぞれのパターンについて説明する。
（１）パターンＡ
パターンＡは、第１アカウントを「第１共通アカウント（第１共通ウォレット）」とするパターンであり、第２アカウントを４種類とする、パターンＡ１～パターンＡ４の４通りのパターンが定められている。
第１共通アカウントは、自己の端末２０のユーザを含む複数の端末２０のユーザが使用可能な共通ウォレットのアカウント（１つ目のアカウント）である。
パターンＡ１は、第２アカウントを「自分のユーザアカウント（電子マネー口座）」とするパターンである。
パターンＡ２は、第２アカウントを「他人のユーザアカウント（電子マネー口座）」とするパターンである。
パターンＡ３は、第２アカウントを「事業者アカウント（事業者ローン口座）」とするパターンである。
事業者は、限定ではなく例として、支払いサービス（支払いアプリケーション）を提供する事業者を含む、金銭の融資・貸与を業とする認可を受けた事業者である。
事業者アカウントは、この事業者の支払いアプリケーションのアカウントである。
事業者ローン口座は、この事業者が利用者（端末２０のユーザ）に対して金銭を融資・貸与するための口座である。
パターンＡ４は、第２アカウントを「第２共通アカウント（第２共通ウォレット）」とするパターンである。
第２共通アカウントは、自己の端末２０のユーザを含む複数の端末２０のユーザが使用可能な第１共通アカウントとは異なる共通アカウント（２つ目の共通アカウント）である。
（２）パターンＢ
パターンＢは、第１アカウントを「自分の第１ユーザアカウント」とするパターンであり、第２アカウントを４種類とするパターンＢ１～パターンＢ４の４通りのパターンが定められている。
自分の第１ユーザアカウントは、自分の支払いアプリケーションのアカウント（１つ目のユーザアカウント）である。
パターンＢ１は、第２アカウントを「共通アカウント」とするパターンである。
パターンＢ２は、第２アカウントを「他人のユーザアカウント」とするパターンである。
パターンＢ３は、第２アカウントを「事業者アカウント」とするパターンである。
パターンＢ４は、第２アカウントを「自分の第２ユーザアカウント」とするパターンである。
自分の第２ユーザアカウントは、自分の第１ユーザアカウントとは異なる自分の支払いアプリケーションのアカウント（自分の２つ目のユーザアカウント）である。
（３）パターンＣ
パターンＣは、第１アカウントを「第１ユーザアカウント（他人Ａ）」とするパターンであり、第２アカウントを４種類とするパターンＣ１～パターンＣ４の４通りのパターンが定められている。
第１ユーザアカウント（他人Ａ）は、他人Ａの支払いアプリケーションのアカウントである。
パターンＣ１は、第２アカウントを「共通アカウント」とするパターンである。
パターンＣ２は、第２アカウントを「自分のユーザアカウント」とするパターンである。
パターンＣ３は、第２アカウントを「事業者アカウント」とするパターンである。
パターンＣ４は、第２アカウントを「第２ユーザアカウント（他人Ａまたは他人Ｂ）」とするパターンである。
第２ユーザアカウント（他人Ａまたは他人Ｂ）は、他人Ａの第１ユーザアカウントとは異なる他人Ａの支払いアプリケーションのアカウント（他人Ａの２つ目のユーザアカウント）、または他人Ｂの支払いアプリケーションのアカウント（他人Ｂの１つ目のユーザアカウント）である。
（４）パターンＤ
パターンＤは、第１アカウントを「第１事業者アカウント」とするパターンであり、第２アカウントを４種類とするパターンＤ１～パターンＤ４の４通りのパターンが定められている。
第１事業者アカウントは、第１事業者の支払いアプリケーションのアカウント（第１事業者の１つ目のアカウント）である。
パターンＤ１は、第２アカウントを「自分のユーザアカウント」とするパターンである。
パターンＤ２は、第２アカウントを「他人のユーザアカウント」とするパターンである。
パターンＤ３は、第２アカウントを「共通アカウント」とするパターンである。
パターンＤ４は、第２アカウントを「第２事業者アカウント」とするパターンである。
第２事業者アカウントは、第１事業者アカウントとは異なる第１事業者の支払いアプリケーションのアカウント（第１事業者の２つ目のアカウント）、または第２事業者の支払いアプリケーションのアカウント（第２事業者の１つ目のアカウント）である。
共通アカウント決済では、上記のパターンのうち、共通アカウントを含むパターンであるパターンＡ（パターンＡ１～パターンＡ４）、パターンＢ１、パターンＣ１、パターンＤ３のうちのいずれかのパターンを適用可能である。この場合、第２実施例～第８実施例の手法を同様に適用して、共通アカウント決済を行うようにすることができる。
アカウント連携決済では、上記のパターンのうち、共通アカウントを含まないパターンであるパターンＢ２～パターンＢ４、パターンＣ２～パターンＣ４、パターンＤ１，Ｄ２，Ｄ４のうちのいずれかのパターンを適用可能である。この場合、第９実施例の手法を同様に適用して、アカウント連携決済を行うようにすることができる。
また、アカウント連携決済を複数のユーザが一緒に決済を行う手法と捉えるのであれば、共通アカウントを使用しないパターンを第２実施例～第８実施例の手法に適用することも可能である。つまり、上記のパターンのうち、共通アカウントを含まないパターンであるパターンＢ２～パターンＢ４、パターンＣ２～パターンＣ４、パターンＤ１，Ｄ２，Ｄ４のうちのいずれかのパターンを第２実施例～第８実施例に適用することも可能である。
＜第１０実施例の効果＞
第１０実施例によれば、第１アカウントと第２アカウントとを種々のアカウントとして設定して決済を実現することができるため、端末のユーザの利便性を向上させることができる。
限定ではなく例として、第２アカウントが事業者アカウント（限定ではなく、事業者のアカウントの一例）であり、決済に関する処理が、この事業者アカウントから残高の不足分を貸与することにより実行されるようにすることで、事業者のアカウントに少なくとも基づいて決済を実現することができる。また、事業者のアカウントから残高の不足分を貸与してもらうことで、残高が不足している場合であっても適切に決済を行うことができる。
１ 通信システム
１０ サーバ
１０Ａ 支払い管理サーバ
１０Ｂ メッセージング管理サーバ
２０ 端末
３０ ネットワーク
４０ 店舗ＰＯＳシステム
５０ 店舗コードリーダ装置

Claims (23)

  1. 端末と通信し、決済に関する処理を行うサーバに実行させるためのプログラムであって、
    前記端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理を前記サーバの制御部によって行うことと、
    前記第１決済の金額と、前記第１アカウントの残高とに基づき、前記第１アカウントの残高が不足していることに関する第１情報を前記端末に前記サーバの通信部によって送信することと、
    前記端末の表示領域に表示された前記第１情報と、前記表示領域に表示された、前記第１アカウントとは異なる第２アカウントを利用して前記第１決済を行うことに関する第２情報とのうち、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第１決済に関する処理を、前記第２アカウントに少なくとも基づいて前記制御部によって行うこととが前記サーバによって実行される。
  2. 請求項１に記載のプログラムであって、
    前記第１アカウントは、少なくとも前記端末のユーザと、前記端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントである。
  3. 請求項２に記載のプログラムであって、
    前記第１決済に関する処理は、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記共通アカウントと、前記第２アカウントとに少なくとも基づいて、実行される。
  4. 請求項３に記載のプログラムであって、
    前記共通アカウントと、前記第２アカウントとのうち、前記共通アカウントの残高から優先的に支払いを行う処理を前記制御部によって行うことが前記サーバによって実行される。
  5. 請求項３に記載のプログラムであって、
    前記第２アカウントから前記共通アカウントに送金する処理を行い、前記共通アカウントの残高に基づいて前記第１決済に関する処理を前記制御部によって行うことが前記サーバによって実行される。
  6. 請求項５に記載のプログラムであって、
    前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第２アカウントから前記共通アカウントに送金する処理を前記制御部によって行うことが前記サーバによって実行される。
  7. 請求項１に記載のプログラムであって、
    前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第２アカウントと関連付けられた第１コード情報を前記端末に前記通信部によって送信することと、
    前記第１コード情報が読み取られることに基づいて、前記第１決済に関する処理を前記制御部によって行うこととが前記サーバによって実行される。
  8. 請求項２から請求項７のいずれか一項に記載のプログラムであって、
    前記第２アカウントは、前記端末のユーザのアカウントである。
  9. 請求項８に記載のプログラムであって、
    前記第１アカウントは、少なくとも前記端末のユーザと、前記端末のユーザとは異なる第１ユーザとが決済可能な共通アカウントであり、
    前記第１決済の金額と、前記共通アカウントの残高と、前記第２アカウントとに基づき、前記共通アカウントの残高が不足していることに関する前記第１情報を前記端末に前記通信部によって送信することと、
    前記表示領域に表示された前記第１情報と前記第２情報とのうち、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第２アカウントに対して送金する処理を前記制御部によって行うこととが前記サーバによって実行される。
  10. 請求項２から請求項６のいずれか一項に記載のプログラムであって、
    前記第２アカウントは、前記第１ユーザのアカウントである。
  11. 請求項１０に記載のプログラムであって、
    前記第２アカウントに基づく決済の許可の依頼に関する情報を前記第１ユーザの端末に前記通信部によって送信することと、
    前記第１ユーザによる前記第２アカウントによる決済の許可に基づいて、前記第１決済に関する処理を前記制御部によって行うこととが前記サーバによって実行される。
  12. 請求項１０または請求項１１に記載のプログラムであって、
    前記第２アカウントによる支払いに基づく金額の請求に関する請求情報を前記端末に前記通信部によって送信することが前記サーバによって実行される。
  13. 請求項２に記載のプログラムであって、
    前記第１決済に関する処理は、前記第２アカウントを含む、前記共通アカウントによって決済可能なユーザの各々のアカウントと、前記共通アカウントとに基づいて実行される。
  14. 請求項１３に記載のプログラムであって、
    前記各々のアカウントは、前記共通アカウントの残高の不足分が均等に割り振られ、前記第１決済に基づく支払いが実行される。
  15. 請求項２に記載のプログラムであって、
    前記第２アカウントは、事業者のアカウントであり、
    前記第１決済に関する処理は、前記第２アカウントから前記共通アカウントの残高の不足分を貸与することにより実行される。
  16. 請求項２から請求項１５のいずれか一項に記載のプログラムであって、
    前記第１決済に関する処理は、前記表示領域に表示されたコード情報が読み取られることに基づいて、または前記端末によるコード情報の読み取りに基づいて実行される。
  17. 請求項１に記載のプログラムであって、
    前記第２アカウントは、前記端末のユーザとは異なる第１ユーザのアカウントである。
  18. 請求項１７に記載のプログラムであって、
    前記第２アカウントは、前記端末のユーザによる前記端末に対する入力に基づいて選択される。
  19. 請求項１８に記載のプログラムであって、
    前記第２アカウントは、前記端末のユーザによる、前記端末のユーザと前記第１ユーザとを含むチャットルームの選択に基づいて選択される。
  20. 請求項１７から請求項１９のいずれか一項に記載のプログラムであって、
    前記第２アカウントに基づく決済の許可の依頼に関する情報を前記第１ユーザの端末に前記通信部によって送信することと、
    前記第１ユーザによる前記第２アカウントによる決済の許可に基づいて、前記第１決済に関する処理を前記制御部によって行うこととが前記サーバによって実行される。
  21. 端末と通信し、決済に関する処理を行うサーバの情報処理方法であって、
    前記端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理を前記サーバの制御部によって行うことと、
    前記第１決済の金額と、前記第１アカウントの残高とに基づき、前記第１アカウントの残高が不足していることに関する第１情報を前記端末に前記サーバの通信部によって送信することと、
    前記端末の表示領域に表示された前記第１情報と、前記表示領域に表示された、前記第１アカウントとは異なる第２アカウントを利用して前記第１決済を行うことに関する第２情報とのうち、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第１決済に関する処理を、前記第２アカウントに少なくとも基づいて前記制御部によって行うこととを含む。
  22. 端末と通信し、決済に関する処理を行うサーバであって、
    前記端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理を行う制御部と、
    前記第１決済の金額と、前記第１アカウントの残高とに基づき、前記第１アカウントの残高が不足していることに関する第１情報を前記端末に送信する通信部とを備え、
    前記制御部は、前記端末の表示領域に表示された前記第１情報と、前記表示領域に表示された、前記第１アカウントとは異なる第２アカウントを利用して前記第１決済を行うことに関する第２情報とのうち、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第１決済に関する処理を、前記第２アカウントに少なくとも基づいて行う。
  23. 端末と通信し、決済に関する処理を行うサーバであって、
    メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサを備え、
    前記プロセッサは、
    前記端末のユーザが決済可能な第１アカウントに基づいて、第１決済に関する処理を行うことと、
    前記第１決済の金額と、前記第１アカウントの残高とに基づき、前記第１アカウントの残高が不足していることに関する第１情報を前記端末に前記サーバの通信部によって送信することと、
    前記端末の表示領域に表示された前記第１情報と、前記表示領域に表示された、前記第１アカウントとは異なる第２アカウントを利用して前記第１決済を行うことに関する第２情報とのうち、前記端末のユーザによる前記第２情報に対する入力に基づいて、前記第１決済に関する処理を、前記第２アカウントに少なくとも基づいて行うこととを実行する。
JP2022093045A 2019-12-30 2022-06-08 プログラム、情報処理方法、サーバ Active JP7460686B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022093045A JP7460686B2 (ja) 2019-12-30 2022-06-08 プログラム、情報処理方法、サーバ

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019240073A JP7086923B2 (ja) 2019-12-30 2019-12-30 プログラム、情報処理方法、端末
JP2022093045A JP7460686B2 (ja) 2019-12-30 2022-06-08 プログラム、情報処理方法、サーバ

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2019240073A Division JP7086923B2 (ja) 2019-12-30 2019-12-30 プログラム、情報処理方法、端末

Publications (3)

Publication Number Publication Date
JP2022111282A JP2022111282A (ja) 2022-07-29
JP2022111282A5 JP2022111282A5 (ja) 2023-04-05
JP7460686B2 true JP7460686B2 (ja) 2024-04-02

Family

ID=76687467

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2019240073A Active JP7086923B2 (ja) 2019-12-30 2019-12-30 プログラム、情報処理方法、端末
JP2022093045A Active JP7460686B2 (ja) 2019-12-30 2022-06-08 プログラム、情報処理方法、サーバ

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2019240073A Active JP7086923B2 (ja) 2019-12-30 2019-12-30 プログラム、情報処理方法、端末

Country Status (5)

Country Link
US (1) US20220207516A1 (ja)
JP (2) JP7086923B2 (ja)
KR (1) KR20220122967A (ja)
CN (1) CN114402347A (ja)
WO (1) WO2021137267A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11562191B1 (en) * 2021-07-27 2023-01-24 Paypal, Inc. Tracking, monitoring, and consolidating transactions using quick response codes
WO2024025532A1 (en) * 2022-07-28 2024-02-01 Rakuten Symphony Singapore Pte. Ltd. Secure token for screen sharing
WO2024043126A1 (ja) * 2022-08-24 2024-02-29 フェリカネットワークス株式会社 情報処理装置、情報処理方法および情報処理プログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004078474A (ja) 2002-08-14 2004-03-11 Interpress:Kk 与信機能付きのプリペイド方式での決済システム
JP2016532979A (ja) 2013-09-09 2016-10-20 ヨードリー，インコーポレーテッド 共同金融管理
JP2017515248A (ja) 2014-04-16 2017-06-08 ニュークリアス ソフトウェア エクスポーツ リミテッド 無線デジタルウォレット実装の方法とシステム
JP2018205979A (ja) 2017-06-01 2018-12-27 株式会社野村総合研究所 端数資金振替蓄積システム
JP2019117455A (ja) 2017-12-26 2019-07-18 株式会社 ゆうちょ銀行 情報処理装置、情報処理システム、情報処理方法、及び情報処理プログラム
JP6585808B1 (ja) 2018-12-21 2019-10-02 ＬＩＮＥ Ｐａｙ株式会社 生成方法、プログラム、情報処理装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002176671A (ja) 2000-09-28 2002-06-21 Takashi Fujimoto 移動体電話機
US7641113B1 (en) * 2003-10-17 2010-01-05 Nexxo Financial, Inc. Systems and methods for generating revenue from banking transactions using a stored-value card
US7856384B1 (en) * 2004-07-14 2010-12-21 Yahoo! Inc. Systems and methods for providing security in international money exchanges
US7873573B2 (en) * 2006-03-30 2011-01-18 Obopay, Inc. Virtual pooled account for mobile banking
US9589266B2 (en) * 2011-04-01 2017-03-07 Visa International Service Association Restricted-use account payment administration apparatuses, methods and systems
US20120310774A1 (en) * 2011-05-31 2012-12-06 Chassin Christophe Electronic payment system
US8635156B2 (en) * 2011-09-06 2014-01-21 Rawllin International Inc. Converting paper invoice to electronic form for processing of electronic payment thereof
US9489670B2 (en) * 2015-01-15 2016-11-08 Conversant Ip Management Inc. Hybrid wireless short range payment system and method
US11354651B2 (en) * 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
JP2016218861A (ja) * 2015-05-22 2016-12-22 大日本印刷株式会社 支払可否決定システム、携帯端末、装置およびそれらのプログラム
US10956888B2 (en) * 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) * 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10445845B2 (en) * 2016-06-30 2019-10-15 Paypal, Inc. Communicating in chat sessions using chat bots to provide real-time recommendations for negotiations
US9886689B1 (en) * 2016-09-12 2018-02-06 Square, Inc. Processing a mobile payload
US10902513B1 (en) * 2017-05-02 2021-01-26 Sunbit, Inc. Debit-based microloan financing
CN118264635A (zh) * 2017-05-16 2024-06-28 苹果公司 用于对等传输的用户界面
US11574359B1 (en) * 2017-07-25 2023-02-07 Wells Fargo Bank, N.A. Interactive banking using multiple checking accounts
CN114663086A (zh) * 2017-08-16 2022-06-24 创新先进技术有限公司 一种账户创建、账户充值、数据同步方法及设备
US20200013028A1 (en) * 2018-07-09 2020-01-09 American Express Travel Related Services Company, Inc. Peer-to-peer money transfers
US11100504B2 (en) * 2018-12-31 2021-08-24 Paypal, Inc. Systems and methods facilitating account access delegation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004078474A (ja) 2002-08-14 2004-03-11 Interpress:Kk 与信機能付きのプリペイド方式での決済システム
JP2016532979A (ja) 2013-09-09 2016-10-20 ヨードリー，インコーポレーテッド 共同金融管理
JP2017515248A (ja) 2014-04-16 2017-06-08 ニュークリアス ソフトウェア エクスポーツ リミテッド 無線デジタルウォレット実装の方法とシステム
JP2018205979A (ja) 2017-06-01 2018-12-27 株式会社野村総合研究所 端数資金振替蓄積システム
JP2019117455A (ja) 2017-12-26 2019-07-18 株式会社 ゆうちょ銀行 情報処理装置、情報処理システム、情報処理方法、及び情報処理プログラム
JP6585808B1 (ja) 2018-12-21 2019-10-02 ＬＩＮＥ Ｐａｙ株式会社 生成方法、プログラム、情報処理装置

Also Published As

Publication number Publication date
US20220207516A1 (en) 2022-06-30
JP7086923B2 (ja) 2022-06-20
CN114402347A (zh) 2022-04-26
WO2021137267A1 (ja) 2021-07-08
KR20220122967A (ko) 2022-09-05
JP2021110958A (ja) 2021-08-02
JP2022111282A (ja) 2022-07-29

Similar Documents

Publication Publication Date Title
JP7460686B2 (ja) プログラム、情報処理方法、サーバ
JP7531463B2 (ja) プログラム、情報処理方法、端末
JP6977127B1 (ja) プログラム、情報処理方法、端末、サーバ
JP7175877B2 (ja) プログラム、表示方法、端末
WO2022085579A1 (ja) プログラム、情報処理方法、端末、サーバ
JP7456986B2 (ja) プログラム、情報処理方法、端末
JP7405930B2 (ja) プログラム、情報処理方法、端末
JP7250186B2 (ja) サーバ、プログラム、情報処理方法
JP7492942B2 (ja) プログラム、情報処理方法、情報処理装置
JP7566848B2 (ja) プログラム、情報処理方法、サーバ、システム
JP7357591B2 (ja) プログラム、情報処理方法、端末
JP7417482B2 (ja) プログラム、情報処理方法、端末
JP7417796B2 (ja) プログラム、情報処理方法、サーバ
JP7146866B2 (ja) プログラム、情報処理方法、端末
JP7306772B2 (ja) プログラム、情報処理方法、サーバ
JP7034226B1 (ja) プログラム、情報処理方法、端末
WO2022004339A1 (ja) プログラム、情報処理方法、端末
WO2023277001A1 (ja) プログラム、情報処理方法、サーバ、情報処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221220

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230324

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20231027

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20231107

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240305

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240321

R150 Certificate of patent or registration of utility model

Ref document number: 7460686

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150