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

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

Info

Publication number
WO2021137267A1
WO2021137267A1 PCT/JP2019/051639 JP2019051639W WO2021137267A1 WO 2021137267 A1 WO2021137267 A1 WO 2021137267A1 JP 2019051639 W JP2019051639 W JP 2019051639W WO 2021137267 A1 WO2021137267 A1 WO 2021137267A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
payment
account
user
displayed
Prior art date
Application number
PCT/JP2019/051639
Other languages
English (en)
French (fr)
Inventor
泰東 金
世栄 千
Original Assignee
Ｌｉｎｅ株式会社
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 Ｌｉｎｅ株式会社 filed Critical Ｌｉｎｅ株式会社
Priority to KR1020227008972A priority Critical patent/KR20220122967A/ko
Priority to CN201980100429.9A priority patent/CN114402347A/zh
Publication of WO2021137267A1 publication Critical patent/WO2021137267A1/ja
Priority to US17/698,674 priority patent/US20220207516A1/en

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/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/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/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

Definitions

  • This disclosure relates to programs, information processing methods, and terminals.
  • Patent Document 1 discloses a technique for settling the purchase price of a product.
  • the program for causing the terminal to execute the processing related to payment executes the processing related to the first payment by the control unit of the terminal based on the first account that can be settled by the user of the terminal.
  • the control unit executes the process related to the first settlement based on at least the second account different from the first account.
  • the information processing method of the terminal that executes the processing related to the payment is to execute the processing related to the first payment by the control unit of the terminal based on the first account that the user of the terminal can settle. And, based on the amount of the first settlement and the balance of the first account, the first information regarding the insufficient balance of the first account is displayed in the display area of the terminal, and the first information is displayed.
  • the control unit executes a process related to the first settlement based on at least a second account different from the first account based on the input to the display area.
  • the terminal that executes the processing related to the payment is a control unit that executes the processing related to the first payment based on the first account that the user of the terminal can settle, and the amount of the first payment.
  • the process related to the first settlement is executed based on at least a second account different from the first account.
  • the terminal that executes the processing related to the payment includes a processor that reads the program stored in the memory and executes the processing based on the program, and the processor can be settled by the user of the terminal.
  • the control unit Based on displaying 1 information in the display area of the terminal and inputting to the display area where the 1st information is displayed, the control unit performs processing related to the 1st settlement based on at least a 2nd account different from the 1st account. Do and do what you do with.
  • the program for causing the server that communicates with the terminal and executes the processing related to the payment executes the processing related to the first payment based on the first account that the user of the terminal can settle.
  • the control unit of the server Based on the execution by the control unit of the server, the amount of the first settlement, and the balance of the first account, the first information regarding the insufficient balance of the first account is transmitted to the terminal by the communication unit of the server.
  • the control unit executes the process related to the first settlement based on at least the second account different from the first account based on the input by the terminal user for the first information displayed in the display area of the terminal. What you do is done by the server.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 1st Embodiment The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Embodiment The flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 2nd Example.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 2nd Example The flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 2nd Example.
  • the figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd modification The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd modification.
  • the flowchart which shows an example of the flow of processing executed by each apparatus which concerns on 2nd modification The flowchart which shows an example of the flow of processing executed by each apparatus which concerns on 2nd modification.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 3rd Example.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fourth embodiment.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fourth embodiment.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 4th modification.
  • FIG 5 is a flowchart showing an example of a flow of processing executed by each device according to the fourth embodiment.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 4th modification.
  • the figure which shows an example of the code payment screen displayed on the display part of the terminal which concerns on 4th modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth embodiment.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth embodiment.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • the figure which shows an example of the code payment screen displayed on the display part of the terminal which concerns on 5th modification The figure which shows an example of the code payment screen displayed on the display part of the terminal which concerns on 5th modification.
  • the figure which shows an example of the code payment screen displayed on the display part of the terminal which concerns on 5th modification The figure which shows an example of the code payment screen displayed on the display part of the terminal which concerns on 5th modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the fifth modification.
  • the flowchart which shows an example of the flow of the process executed by each apparatus which concerns on 6th Embodiment.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh embodiment.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • FIG. 5 is a flowchart showing an example of a flow of processing executed by each device according to the seventh modification.
  • Electronic money is electronic money that is distinguished from physical money, and means the terminal 20 managed in the above-mentioned various applications or the electronic money owned by the user of the terminal 20.
  • electronic money may or may not be expressed as “electronic money” or “digital currency (digital currency)”.
  • legal tender or virtual currency may be used as “electronic money (electronic money)” or “digital currency (digital currency)”.
  • cryptocurrency cryptocurrency
  • the virtual currency may include physical money such as coupons.
  • the expression "by communication I / F" is used as appropriate. This indicates that the device transmits and receives various information and data via the communication I / F (via the communication unit) based on the control of the control unit (processor or the like), for example, without limitation. ..
  • payment means electronic payment (electronic payment). An example of this is electronic payment using electronic money.
  • processing related to payment is not limited to, but as an example, a process related to payment executed by the terminal 20, and a process of acquiring code information for performing payment from a server or the like (code information). Includes the process of requesting the server etc. to generate the generated code information, the process of receiving the generated code information from the server etc.), the process of displaying the acquired code information, and the payment result (including the payment notification) from the server etc. It includes some processes related to the settlement such as the process of acquisition, and more specifically, all the processes executed by the terminal 20 as the processes related to the settlement.
  • the "code information" includes a code image, information stored in the code image by encoding or the like (storage information), or information to be stored (storage target information). ..
  • the storage information and the storage target information are not limited, but include tokens described in detail later as an example.
  • code payment which is a payment method / payment method using a code (code information)
  • code information it is not limited but as an example. Two types are illustrated: (1) user presentation type (2) store presentation type.
  • the user presentation type is not limited, but as an example, the user (user of the terminal 20) presents the payment code displayed on the display unit 24 of the terminal 20 to the clerk of the store (not limited but a member store as an example). Then, the payment is made by having the code reader 58 of the store code reader device 50 read the payment.
  • the store presentation type is not limited, but as an example, the user presents or posts a payment store code presented or posted at a store (a member store as an example, not limited), and the user uses the camera 27 of the terminal 20 or the code reader (code reader of the payment application). It is a method of reading with (including.) And making a payment.
  • the code displayed on the display unit 24 of the terminal 20 in the user-presented type is referred to as a "payment code”, but instead of this, it may be referred to as a "user-presented code” or the like.
  • the code read by the terminal 20 in the store presentation type is referred to as a "payment store code”, but instead of this, it may be referred to as a "store presentation type code” or the like.
  • an account-based payment as an example, not a limitation.
  • Two types of (A) common account payment (B) account-linked payment will be illustrated.
  • the "account” is not limited, but is, for example, an account of an application (payment application / payment application) for making payment / payment by electronic money.
  • the common account payment is a method of making a payment based on an account that can be commonly used by a plurality of users (hereinafter, referred to as a "common account”). This payment is called “common account payment”.
  • Common account payment is realized by using a common wallet.
  • a "common wallet” is a form of an electronic money account set by a plurality of users, and constitutes one virtual wallet.
  • Common account payment can also be regarded as payment in which a user uses a common account (one common account) for a plurality of users.
  • the common account payment may be expressed as a common wallet payment.
  • Account-linked payment is a method of making payments by linking multiple accounts.
  • Account linkage means associating a plurality of accounts so that they can be used for payment. Linking accounts is called “account linkage”, and payment using account linkage is called “account linkage payment”.
  • a plurality of accounts of one user may be linked, or accounts of a plurality of users may be linked.
  • the accounts of other people are not always essential for cooperation, and it is possible to link multiple accounts of oneself as an example, not limited.
  • account-linked payment As an example, not limited, after associating multiple accounts, as an example, not limited, the process of setting so that payment is made evenly from each associated account ( Account linkage process) is executed.
  • Account-linked payment can also be regarded as payment using a different account (another account of oneself or another person's account) in addition to one's own account.
  • account linkage may be expressed as wallet linkage.
  • account-linked payment may be expressed as wallet-linked payment.
  • Common account payment is basically payment from one account that is supposed to be used by multiple users in common, but in the examples described below, the common account and an account different from the common account A method of making a payment based on the above will also be described.
  • the account linkage is not limited, but as an example, it can be performed either before (B-1) payment or when (B-2) payment is made.
  • B-1) Before making a payment, it can be applied when it is troublesome to settle after the fact (payment by splitting the bill as an example, not the limitation) as an example rather than a limitation.
  • B-2) When making a payment, as an example, not limited, when the balance of the account set as the account that makes the payment at the time of payment (not limited, but your own account as an example) is insufficient Can be applied to. In this case, as an example, not limited to the account, it is possible to perform payment in cooperation with another user's account.
  • common account payment since a common account is used for multiple users, details will be described later, but when one user pays for another user's payment, the payment will be made after the fact (clearing). ) May be required. That is, at some timing after the settlement is completed, it may be necessary to adjust the amount of money of each user such as remittance processing / receipt processing. On the other hand, in account-linked payment, the amount of money is consumed from each account after obtaining the permission of the user of the linked account or obtaining the permission on the spot, so that the payment is made after the fact. Processing is basically unnecessary.
  • FIG. 1-1 is a diagram showing an example of the system configuration of the communication system 1 in this embodiment.
  • a server 10 a plurality of terminals 20 (terminals 20A, terminals 20B, terminals 20C, ...), And a plurality of store POS systems 40 (store POS) are provided via a network 30.
  • System 40A, store POS system 40B, store POS system 40C, ...) Are connected.
  • the server 10 has a function of providing a payment service to a terminal 20 owned by a user via a network 30.
  • the server 10 can also be expressed as a payment service server, a payment management server, a payment service server, a payment management server, or the like.
  • the number of servers 10 and the number of terminals 20 connected to the network 30 are not limited.
  • the network 30 plays a role of connecting one or more terminals 20, one or more servers 10, and one or more store POS systems 40. That is, the network 30 means a communication network that provides a connection route so that data can be transmitted and received after the above-mentioned various devices are connected.
  • the network 30 may or may not be a wired network or a wireless network.
  • the network 30 is not limited, but is, for example, an ad hoc network, an intranet, an extra net, a virtual private network (VPN), a local area network (LAN), and a wireless network.
  • VPN virtual private network
  • LAN local area network
  • the network 30 may include one or more networks 30.
  • the server 10 (not limited to an example of a server, an information processing device, and an information management device) has a function of providing a predetermined service (payment service in this embodiment) to the terminal 20.
  • the server 10 may be any device as long as it is an information processing device capable of realizing the functions described in each embodiment.
  • the server 10 is not limited, but by example, a server device, a computer (not limited, by example, a desktop, a laptop, a tablet, etc.), a media computer platform (not limited, by example, a cable, a satellite set-top box, a digital video recorder). ), Handheld computer devices (for example, but not limited to, PDA, email client, etc.), or other types of computers, or communication platforms.
  • the server 10 may be expressed as an information processing device. When it is not necessary to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be expressed as information processing devices, respectively.
  • FIG. 1-1 shows an example of the HW configuration of the terminal 20.
  • the terminal 20 includes a control unit 21 (CPU: central processing unit), a storage unit 28, a communication I / F 22 (interface), an input / output unit 23, a display unit 24, a microphone 25, a speaker 26, a camera 27, and the like. It includes a clock unit 29A and a position calculation information detection unit 29B.
  • Each component of the HW of the terminal 20 is connected to each other via bus B as an example, but not a limitation. It is not essential that the HW configuration of the terminal 20 includes all the components.
  • the terminal 20 may or may not have a configuration in which individual components such as a microphone 25, a camera 27, or the like, or a plurality of components are removed.
  • the communication I / F 22 transmits and receives various data via the network 30. Communication may be executed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be executed.
  • the communication I / F 22 has a function of executing communication with various devices such as the server 10 via the network 30.
  • the communication I / F 22 transmits various data to various devices such as the server 10 according to an instruction from the control unit 21. Further, the communication I / F 22 receives various data transmitted from various devices such as the server 10 and transmits the various data to the control unit 21. Further, the communication I / F 22 may be simply expressed as a communication unit. Further, when the communication I / F 22 is composed of a physically structured circuit, it may be expressed as a communication circuit.
  • the input / output unit 23 includes a device for inputting various operations to the terminal 20 and a device for outputting the processing result processed by the terminal 20.
  • the input / output unit 23 may or may not be integrated with the input unit and the output unit, or may be separated into the input unit and the output unit.
  • the input unit is realized by any or a combination of all kinds of devices capable of receiving input from the user and transmitting information related to the input to the control unit 21.
  • the input unit includes, but is not limited to, hardware keys such as a touch panel, a touch display, and a keyboard, a pointing device such as a mouse, a camera (operation input via a moving image), and a microphone (operation input by voice).
  • the output unit is realized by any one or a combination of all kinds of devices capable of outputting the processing result processed by the control unit 21.
  • the output unit includes, as an example, not limited, a touch panel, a touch display, a speaker (audio output), a lens (not limited, as an example, 3D (three dimensions) output, hologram output), a printer, and the like.
  • the display unit 24 is realized by any or a combination of all kinds of devices that can display according to the display data written in the frame buffer.
  • the display unit 24 is not limited but is an example of a touch panel, a touch display, a monitor (not limited but an example of a liquid crystal display or OELD (organic electroluminescence display)), a head mounted display (HDM: Head Mounted Display), projection mapping, and a hologram. , Includes a device capable of displaying images, text information, etc. in the air (which may or may not be vacuum). It should be noted that these display units 24 may or may not be able to display display data in 3D.
  • the input / output unit 23 is a touch panel
  • the input / output unit 23 and the display unit 24 may be arranged so as to face each other with substantially the same size and shape.
  • the clock unit 29A is a built-in clock of the terminal 20 and outputs time information (timekeeping information).
  • the clock unit 29A is configured to include, for example, a clock using a crystal oscillator, and the like, without limitation.
  • the clock unit 29A can be expressed as a time measuring unit or a time information detecting unit as an example without limitation.
  • the clock unit 29A may or may not have a clock to which the NITZ (Network Identity and Time Zone) standard or the like is applied.
  • NITZ Network Identity and Time Zone
  • the position calculation information detection unit 29B has a function of detecting (measuring) information necessary for the control unit 21 to calculate (measure) the position of its own terminal 20 (hereinafter, referred to as "position calculation information"). It is a department.
  • the position calculation information detection unit 29B can be expressed as a position calculation sensor unit as an example without limitation.
  • the position calculation information detection unit 29B is not limited, but as an example, a satellite positioning sensor (satellite positioning) which is a sensor or a unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System). A unit), a sensor for calculating the position of the terminal 20 using an inertial navigation system, an inertial measurement sensor (inertial measurement unit (IMU)), and the like.
  • satellite positioning sensor satellite positioning
  • GPS Global Positioning System
  • IMU inertial measurement unit
  • the satellite positioning unit is not limited to, for example, an RF receiving circuit that converts an RF (Radio Frequency) signal including a positioning satellite signal transmitted from a positioning satellite received by an antenna (not shown) into a digital signal. Correlation calculation processing is performed on the digital signal output from the RF reception circuit to capture the positioning satellite signal, and information such as satellite orbit data and time data extracted from the positioning satellite signal is used as position calculation information. It has a baseband processing circuit to output.
  • RF Radio Frequency
  • the inertial measurement unit has an inertial sensor which is a sensor that detects information necessary for calculating the position of the terminal 20 by inertial navigation calculation.
  • the inertial sensor includes, for example, a three-axis acceleration sensor and a three-axis gyro sensor, and the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor are used as position calculation information. Output.
  • the control unit 21 calculates the position of its own terminal 20 at a periodic timing or a specific timing based on the position calculation information detected by the position calculation information detection unit 29B, as an example but not a limitation.
  • the position of the terminal is referred to as "terminal position”
  • the calculated terminal position is referred to as "calculated terminal position”. Then, the control unit 21 associates the calculated terminal position with the calculated date and time and stores the calculated terminal position in the storage unit 28 as the calculated terminal position history data.
  • the control unit 21 has a physically structured circuit for executing a function realized by a code or an instruction contained in the program, and is not limited, but as an example, a data processing device built in hardware. Is realized by. Therefore, the control unit 21 may or may not be expressed as a control circuit.
  • the control unit 21 is not limited, but as an example, a central processing unit (CPU), a microprocessor (microprocessor), a processor core (processor core), a multiprocessor (multiprocessor), an ASIC (application-specific integrated circuit), and an FPGA (field programmable). gate array) is included.
  • CPU central processing unit
  • microprocessor microprocessor
  • processor core processor core
  • multiprocessor multiprocessor
  • ASIC application-specific integrated circuit
  • FPGA field programmable gate array
  • the storage unit 28 has a function of storing various programs and various data required for the terminal 20 to operate.
  • the storage unit 28 includes various storage media such as HDD (hard disk drive), SSD (solid state drive), flash memory, RAM (random access memory), and ROM (read only memory) as examples without limitation. Further, the storage unit 28 may or may not be expressed as a memory.
  • the terminal 20 stores the program P in the storage unit 28, and by executing this program P, the control unit 21 executes the processing as each unit included in the control unit 21. That is, the program P stored in the storage unit 28 causes the terminal 20 to realize each function executed by the control unit 21. Further, this program P may or may not be expressed as a program module.
  • the microphone 25 is used for inputting voice data.
  • the speaker 26 is used for outputting audio data.
  • the camera 27 is used for acquiring moving image data.
  • FIG. 1-1 shows an example of the HW configuration of the server 10.
  • the server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I / F 14 (interface), an input / output unit 12, a display 13, and a clock unit 19.
  • the components of the HW of the server 10 are connected to each other via the bus B as an example, but not a limitation. It is not essential that the HW of the server 10 includes all the components as the configuration of the HW of the server 10. As an example, but not limited to, the HW of the server 10 may or may not be configured to remove the display 13.
  • the control unit 11 has a physically structured circuit for executing a function realized by a code or an instruction contained in the program, and is not limited, but as an example, a data processing device built in hardware. Is realized by.
  • the control unit 11 is typically a central processing unit (CPU), and may or may not be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA. In the present disclosure, the control unit 11 is not limited to these.
  • the storage unit 15 has a function of storing various programs and various data required for the server 10 to operate.
  • the storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Further, the storage unit 15 may or may not be expressed as a memory.
  • Communication I / F14 transmits and receives various data via the network 30. Communication may be executed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be executed.
  • the communication I / F 14 has a function of executing communication with various devices such as a terminal 20 via the network 30.
  • the communication I / F 14 transmits various data to various devices such as a terminal 20 according to an instruction from the control unit 11. Further, the communication I / F 14 receives various data transmitted from various devices such as the terminal 20 and transmits the various data to the control unit 11. Further, the communication I / F 14 may be simply expressed as a communication unit. Further, when the communication I / F 14 is composed of a physically structured circuit, it may be expressed as a communication circuit.
  • the input / output unit 12 is realized by a device that inputs various operations to the server 10.
  • the input / output unit 12 is realized by any or a combination of all kinds of devices capable of receiving an input from a user and transmitting information related to the input to the control unit 11.
  • the input / output unit 12 is typically realized by a hardware key typified by a keyboard or the like, or a pointing device such as a mouse.
  • the input / output unit 12 may or may not include a touch panel, a camera (operation input via a moving image), and a microphone (operation input by voice) as an example, not limited to the input / output unit 12. However, in the present disclosure, the input / output unit 12 is not limited to these.
  • the display 13 is typically realized by a monitor (not limited, but as an example, a liquid crystal display or an OELD (organic electroluminescence display)).
  • the display 13 may or may not be a head-mounted display (HDM) or the like. It should be noted that these displays 13 may or may not be capable of displaying display data in 3D. In the present disclosure, the display 13 is not limited to these.
  • the clock unit 19 is a built-in clock of the server 10 and outputs time information (timekeeping information).
  • the clock unit 19 is configured to include, for example, an RTC (Real Time Clock) as a hardware clock, a system clock, or the like, which is not limited.
  • the clock unit 19 is not limited, but may be expressed as a time measuring unit or a time information detecting unit as an example.
  • the store POS system 40 is a POS system that is introduced and used in a store that is affiliated with a business operator that operates the server 10, and is not limited, but as an example, a store code reader device 50, a code cash register 60, and a store. Includes server 70.
  • the store code reader device 50 is connected to the code cash register 60 and the store server 70 by POS communication I / F 57 (not limited to, for example, a wired communication I / F or a wireless communication I / F in the store), and the code cash register 60 is connected.
  • the code information displayed on the display unit 24 of the terminal 20 is read at the time of accounting at. Then, based on the read code information, the payment request information is transmitted to the server 10 by the communication I / F 54, and after the payment is made by the server 10, the information regarding the payment result is received from the server 10 by the communication I / F 54. ..
  • the store code reader device 50 is not limited, but as an example, the control unit 51, the input / output unit 52, the display unit 53, the communication I / F 54, the storage unit 55, the sound output unit 56, and the POS communication I / It has an F57, a code reader 58, and a clock unit 59.
  • the code reader 58 is a code reader for reading a one-dimensional code (one-dimensional code image), a two-dimensional code (two-dimensional code image), and not a limitation but a payment code (payment code image) described later as an example.
  • the code cash register 60 is not limited, but as an example, is connected to the store code reader device 50 and the store server 70 by POS communication I / F 57, and is based on a payment completion notification or the like received by the store code reader device 50 from the server 10.
  • a receipt is issued with information such as the total amount of the sold products and the balance of electronic money of the user of the terminal 20 printed.
  • a display provided as an integral part of the code cash register 60 or as a separate body from the code cash register 60 and having a display surface facing the customer side can be configured.
  • the code cash register 60 is a cash register configured to support payment applications, and can be said to be a stationary terminal compatible with payment applications.
  • the store server 70 is not limited, but as an example, for store information about its own store, information about products sold at its own store, information about services provided at its own store, sales of products at its own store, and provision of services. Manage various information such as information on the accompanying sales.
  • the store server 70 is configured to be able to communicate with the store code reader device 50 and the code register 60 by POS communication I / F 57, and is also configured to be able to communicate with an external device such as the server 10 via the network 30.
  • the store server 70 does not necessarily have to be configured to be able to communicate directly with the store code reader device 50, and may be configured to be able to communicate with the store code reader device 50 via the code register 60.
  • the payment completion notification or the like received by the store code reader device 50 from the server 10 may be sent to the code cash register 60, and then sent from the code cash register 60 to the store server 70.
  • the server 10 stores the program P in the storage unit 15, and by executing the program P, the control unit 11 executes the processing as each unit included in the control unit 11. That is, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11.
  • This program P may or may not be expressed as a program module. The same applies to other devices.
  • the control unit 21 of the terminal 20 and / or the control unit 11 of the server 10 is formed not only in a CPU having a control circuit but also in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or the like. Each process may or may not be realized by a logic circuit (hardware) or a dedicated circuit. Further, these circuits may be realized by one or a plurality of integrated circuits, and the plurality of processes shown in each embodiment may or may not be realized by one integrated circuit. Further, the LSI may be referred to as a VLSI, a super LSI, an ultra LSI, or the like due to the difference in the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit. The same applies to other devices.
  • IC Integrated Circuit
  • LSI Large Scale Integration
  • the program P (for example, a software program, a computer program, or a program module) of each embodiment of the present disclosure may be provided in a state of being stored in a computer-readable storage medium. It does not have to be done.
  • the storage medium can store the program P in a “non-temporary tangible medium”.
  • the program P may or may not be for realizing a part of the functions of each embodiment of the present disclosure. Further, it may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with the program P already recorded on the storage medium.
  • the storage medium is one or more semiconductor-based or other integrated circuits (ICs) (such as, but not limited to, field programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disks.
  • the storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.
  • the storage medium is not limited to these examples, and any device or medium may be used as long as the program P can be stored. Further, the storage medium may or may not be expressed as a memory.
  • the server 10 and / or the terminal 20 can read the program P stored in the storage medium and execute the read program P to realize the functions of the plurality of functional units shown in each embodiment. The same applies to other devices.
  • the program P of the present disclosure may or may not be provided to the server 10 and / or the terminal 20 via an arbitrary transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. ..
  • the server 10 and / or the terminal 20 realizes the functions of the plurality of functional units shown in each embodiment by executing the program P downloaded via the Internet or the like, as an example without limitation. The same applies to other devices.
  • each embodiment of the present disclosure can also be realized in the form of a data signal in which the program P is embodied by electronic transmission.
  • At least part of the processing in the server 10 and / or the terminal 20 may or may not be realized by cloud computing composed of one or more computers.
  • At least a part of the processing in the terminal 20 may or may not be performed by the server 10.
  • At least a part of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be performed by the server 10.
  • At least a part of the processing in the server 10 may or may not be performed by the terminal 20.
  • at least a part of the processing of each functional unit of the control unit 11 of the server 10 may or may not be performed by the terminal 20.
  • the configuration of the determination in the embodiment of the present disclosure is not essential, and a predetermined process is operated when the determination condition is satisfied, or a predetermined process is performed when the determination condition is not satisfied. It may or may not be.
  • the program disclosed in this disclosure is not limited to the use of script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), and markup languages such as HTML5. Will be implemented.
  • script languages such as ActionScript and JavaScript (registered trademark)
  • compiler languages such as Objective-C and Java (registered trademark)
  • markup languages such as HTML5. Will be implemented.
  • a business operator that provides a payment service using a payment application will be referred to as a "payment service business operator”.
  • the payment service business operator can also be expressed as a business operator that provides a payment application or a business operator of the server 10. It can also be expressed as a payment service provider in the sense of a payment service provider.
  • a store that can use a payment service that uses a payment application to pay for goods and services provided at the store in partnership with a payment service provider is referred to as a "member store”.
  • the server 10 is operated and managed by the payment service provider. Further, in the following, the name of the payment application will be illustrated and described as "Payment App" as appropriate.
  • the payment application may be provided by the server 10 as a single application having no so-called messaging service (MS) function, or may be provided by the server 10 as a complex application having the MS function. May be provided by.
  • the messaging service may or may not include an instant messaging service (IMS: Instant Messaging Service) that enables transmission and reception of contents such as simple messages between terminals 20.
  • IMS Instant Messaging Service
  • the content includes messages including simple texts and pictograms, as well as image information (including still images, moving images, etc.), operation information (including buttons, icons, etc.), communication, and not limited examples.
  • image information including still images, moving images, etc.
  • operation information including buttons, icons, etc.
  • communication and not limited examples.
  • Various information that can be transmitted and received between the terminals 20 can be included, such as information for use and link information (including URI, URL, etc.).
  • the payment application may be provided by the server 10 as a single application having no so-called social networking service (SNS) function, or as a complex application having an SNS function. It may be provided by the server 10.
  • SNS social networking service
  • MS including IMS
  • SNS social networking service
  • FIG. 1-3 is a diagram showing an example of a function realized by the control unit 11 of the server 10 in this embodiment.
  • the control unit 11 includes, as an example, not limited to, a payment application management processing unit 111 for executing payment application management processing according to the payment application management processing program 151 stored in the storage unit 15 as a functional unit.
  • FIG. 1-4 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
  • the storage unit 15 stores, as an example, not limited to, a payment application management processing program 151 executed as a payment application management process, payment application user registration data 153, a user management database 155, and a common wallet management database 157. Will be done.
  • the payment application user registration data 153 is registration data relating to the terminal 20 that uses the payment application or the user of the terminal 20, and an example of the data structure is shown in FIG. 1-5.
  • the payment application user registration data 153 as an example, the user name, the payment application ID, the terminal telephone number, and other registration information are stored in association with each other.
  • the user name is the name of the user of the terminal 20 who uses the payment application, and is not limited, but as an example, the name registered when the user of the terminal 20 uses the payment application is stored.
  • the payment application ID is an account (account information) of the payment application, and is an ID that can identify the terminal 20 or the user of the terminal 20.
  • the payment application ID is not limited, but as an example, a unique ID is set and stored by the server 10.
  • the terminal telephone number is the telephone number of the terminal 20 of the user with this user name, and is not limited, but as an example, the telephone number of the terminal 20 registered when the user of the terminal 20 uses the payment application is stored.
  • Other registration information is not limited, but as an example, authentication information such as the email address (terminal email address) of the terminal 20 of the user with this user name, the authentication password used for various authentications in the payment application, and the authentication information used by this user.
  • Image data (icon image) of the icon to be authenticated, user profile (user profile), and the like can be included. However, this information is not essential.
  • the user management database 155 is a database for managing users based on the account (account information) stored in the payment application user registration data 153, and an example of the data structure is shown in FIG. 1-6.
  • the user management database 155 stores user management data as management data for each payment application ID stored in the payment application user registration data 153.
  • Each user management data stores a payment application ID and an electronic money account balance as an example, not limited to each other.
  • a common wallet is a form of electronic money account that is set in advance before payment is made by multiple users who use the payment application.
  • the user In order to use the common wallet, the user first performs an operation to generate the common wallet. This generation requires information that identifies the electronic money account of the common wallet member as an example, not a limitation (payment application ID, as an example, not a limitation).
  • the common wallet management database 157 is a database for the server 10 to manage the common wallet, and FIG. 1-7 shows a data configuration example of the first common wallet management database 157A, which is an example thereof.
  • common wallet management data is stored as management data for each common wallet ID for uniquely identifying the common wallet.
  • the common wallet ID, the common wallet name, the common wallet balance, and the common wallet member ID are stored in association with each other as an example, not limited.
  • the common wallet ID is a common wallet account (hereinafter, appropriately referred to as "common account") in the payment application.
  • the common wallet name is the name of the common wallet identified by the common wallet ID.
  • the common wallet balance is the balance of electronic money used when making a payment using the common wallet identified by the common wallet ID.
  • the common wallet member ID is a payment application ID of the common wallet member specified when the common wallet is generated.
  • the common wallet balance is "0".
  • the common wallet member transfers electronic money from each electronic money account to the common wallet to increase the common wallet balance.
  • the common wallet member can also charge the common wallet (convert to electronic money and remit) from the account of an external financial institution registered for the payment service (not limited, but as an example, a bank account).
  • FIGS. 1-8 to 1-9 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown. This process is an example of a process related to user-presented code payment.
  • terminal 20 of A terminal A
  • terminal B terminal B
  • the electronic money account that can be used by the terminal 20 (terminal B) of B will be described as a common wallet.
  • the number of terminals that can pay using the common wallet is not limited to two, but the processing is the same as that of the terminal B, so the illustration is omitted in this specification.
  • this process is merely an example of a process for realizing the method of the present disclosure, and is not limited to this process. Another step may be added to this process, or some steps may be omitted (deleted). This is the same for each flowchart (process) described below.
  • control unit 21 of the terminal A transmits the common wallet creation / selection information to the server 10 by the communication I / F22 (A100).
  • the information for selecting the common wallet that can be used from the terminal A (not limited, but as an example, the common wallet ID) is transmitted to the server 10 by the communication I / F22.
  • the selectable common wallet ID may be received from the server 10 by the communication I / F 22 in this step, or may be recalled in advance stored in the storage unit 28.
  • information for creating a new common wallet is transmitted to the server 10 by communication I / F22.
  • the information for creating a new common wallet is not limited, but as an example, the account information of the members constituting the common wallet (as an example, not limited, the payment application of users AA and user BB). ID), the name of the common wallet, and the initial transfer amount to the common wallet.
  • the control unit 11 of the server 10 Upon receiving the information for selecting the common wallet from the terminal A or the information for creating a new common wallet by the communication I / F 14, the control unit 11 of the server 10 receives the requested common wallet ID or newly creates the common wallet. It generates a payment token that authorizes payment from the wallet based on a common wallet ID that is uniquely (without duplication) assigned by the control unit 11.
  • a payment token that approves payment from the common wallet balance linked to the common wallet ID will be referred to as a "common wallet payment token".
  • the common wallet payment token is identified by an integer value of a predetermined number of digits (12 digits as an example, not a limitation) as an example, not a limitation.
  • the common wallet payment token may or may not be a token having an expiration date, which is approved only within a predetermined time (not limited, but "5 minutes” as an example) from the generation.
  • the control unit 11 of the server 10 When the common wallet payment token is generated, the control unit 11 of the server 10 generates the common wallet code information which is the code information including the common wallet payment token.
  • the common wallet code information includes, as an example, not limited to, a payment code (image information) in which the identifier of the common wallet payment token is encoded as a one-dimensional code (bar code or the like) or a two-dimensional code (QR code or the like).
  • the common wallet code information may include the expiration date. It may also include the name of the common wallet from which the common wallet payment token was generated.
  • control unit 11 of the server 10 transmits the common wallet code information to the terminal A by the communication I / F 14 (S100a).
  • the control unit 21 of the terminal A causes the display unit 24 to display the received common wallet code information (A110a).
  • the common wallet code information the payment code is displayed on the display unit 24 as an example, not a limitation.
  • the control unit 21 of the terminal A may or may not display the identifier and expiration date.
  • the control unit 21 of the terminal A transmits information requesting the regeneration of the common wallet payment token to the server 10 by the communication I / F 22. It may or may not be. In this case, the control unit 21 of the server 10 regenerates the common wallet payment token and the common wallet code information, and transmits the common wallet code information to the terminal A by the communication I / F 14. Then, when the common wallet code information regenerated from the server 10 by the communication I / F 22 is received, the control unit 21 of the terminal A may cause the display unit 24 to redisplay the payment code and the expiration date. it can.
  • the control unit 11 of the server 10 transmits the common wallet information, which is the information about the common wallet for which the common wallet payment token is generated, to the terminal A by the communication I / F 14 (S110).
  • the common wallet information includes, but is not limited to, the common wallet balance as an example.
  • the control unit 21 of the terminal A displays the received common wallet information on the display unit 24 (A120).
  • the common wallet balance is displayed in addition to the display unit 24 as an example, not limited.
  • the control unit 51 of the store code reader device 50 executes the store payment process, and based on the operation of the store code reader device 50 for the input / output unit 52, a predetermined payment scheduled amount (not limited, but as an example, "3,000 yen"". ) Is input to the control unit 51. Then, the control unit 51 of the store code reader device 50 uses the code reader 58 to read the payment code displayed on the display unit 24 of the terminal A (P140). In this case, since the payment code displayed on the display unit 24 is associated with the common wallet payment token, the reading result of the code reader 58 includes the common wallet payment token as the payment token.
  • the control unit 51 of the store code reader device 50 uses the communication I / F 54 to transmit payment request information including a store ID, a planned payment amount, and a payment token (in this case, a common wallet payment token), not by limitation. It is transmitted to the server 10 (P150).
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and the store is used for the common wallet.
  • a payment process for paying the planned payment amount with the member store defined by the ID is executed (S170a).
  • the control unit 11 of the server 10 transfers the payment result information including the success / failure of the payment processing and the common wallet balance after the payment processing to the terminal A and the store code reader device 50 by the communication I / F 14 as an example, not limited to the control unit 11.
  • the transmission (S180a) is performed, and the process is terminated.
  • the control unit 21 of the terminal A displays the payment result information on the display unit 24 (A180), and ends the process.
  • the control unit 51 of the store code reader device 50 displays the payment result information on the display unit 53 (P160), and ends the process.
  • the "payment store code” is used as an example, not a limitation, and member store identification information for identifying a member store (a store that is uniquely assigned to a member store as an example, not a limitation). It will be described as a code (one-dimensional code or two-dimensional code) including an ID).
  • the payment store code may or may not include information on a specific planned settlement amount (not limited, but "500 yen” as an example).
  • 1-10 to 1-11 are flowcharts showing an example of the flow of processing executed by each device in this case.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • the control unit 11 of the server 10 when the common wallet payment token is generated by the control unit 11 of the server 10, the control unit 11 of the server 10 generates the common wallet code reader information which is the code reading information including the common wallet payment token. Generate. Then, the control unit 11 of the server 10 transmits the common wallet code reader information to the terminal A by the communication I / F 14 (S100b).
  • the control unit 21 of the terminal A reads the payment store code based on the received common wallet code reader information.
  • the screen is displayed on the display unit 24. Further, the control unit 21 of the terminal A activates the camera 27 to read the code (A110b). Then, the control unit 21 of the terminal A shifts the processing to the A120.
  • control unit 21 of the terminal A executes a code reading process for reading the payment store code using the camera 27 or the like (A190). As a result, the store ID is acquired from the read payment store code.
  • the control unit 21 of the terminal A causes the display unit 24 to display a display screen for inputting the planned settlement amount, not as a limitation but as an example.
  • the control unit 21 is not limited to, but as an example, the common wallet payment token included in the common wallet code reader information and the store ID.
  • the payment request information including the planned payment amount is transmitted to the server 10 by the communication I / F 22 (A200). Then, the control unit 21 of the terminal A shifts the processing to the A180.
  • the payment store code includes the planned payment amount, it is possible to omit the input of the planned payment amount on the terminal A.
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and the common wallet is subjected to the request.
  • a store presentation type payment process for paying the planned payment amount with the member store defined by the store ID is executed (S170b).
  • control unit 11 of the server 10 transmits the settlement result information including the success / failure of the settlement process and the common wallet balance after the settlement process to the terminal A by the communication I / F14 (S180b). Then, the control unit 11 ends the process.
  • the terminal 20 uses the payment application to execute payment at the member store from the common wallet balance, but when the common wallet balance is insufficient at the time of payment, the common wallet balance is insufficient.
  • the second embodiment is an example in which when the common wallet balance is insufficient, payment is made from one's own wallet (own user account) instead of the common wallet (common account).
  • a touch panel that functions as an input unit is arranged so as to face the display.
  • an element such as an icon, button, item, or input area
  • the user touches an area that is a part of the touch panel and faces the area where the element is displayed, the area is touched.
  • the program associated with the element or the subroutine of that program is executed.
  • the area of the touch panel facing the area where the element is displayed on the display is also referred to as a facing area. That is, the facing region functions as a receiving means.
  • FIG. 2-1 is a diagram showing an example of an application screen displayed on the display unit 24 in the payment application executed on the terminal 20.
  • This application screen is an example of a screen displayed when the operation to start the payment application is performed by the user and the payment application is started.
  • the balance display area 241 is filled with the user A. "25,000 yen” is displayed as the balance of the electronic money account of A, and a charge button 241A for charging the amount is displayed next to it.
  • an icon display area is provided in which a plurality of icons corresponding to various functions of the payment application are displayed.
  • six icons corresponding to "remittance”, "code payment”, “code reader”, “coupon”, “points”, and "common wallet” are displayed in the icon display area.
  • the icon corresponding to the “common wallet” will be described as the common wallet icon CN1.
  • FIG. 2-2 is a diagram showing an example of a common wallet selection screen displayed when the common wallet icon CN1 is touch-operated on the application screen of FIG. 2-1.
  • the "common wallet” which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”.
  • a description of "Please select a common wallet” is displayed as an operation guide for the user, and below that description, a display area for multiple common wallets is provided.
  • the camp fund display area 242 which is a common wallet display area for camp funds
  • the Korean travel display area 243 which is a common wallet display area for Korean travel
  • a new registration operation area 244 that can be operated by the user for newly adding / registering a common wallet is provided.
  • camp fund display area 242 the name of the common wallet ("camp fund” in this example) is displayed along with an image of a "square wallet” indicating that it is a common wallet.
  • various setting icons are displayed next to it.
  • the common wallet balance of this camp fund (here, "1,000 yen") is displayed in the lower row, and the icon image and user name of the user who jointly uses this common wallet are displayed next to it.
  • the icon image of B and the user name are displayed. That is, the common wallet for this camp fund is User A. A and user B. It can be said that it is a common wallet consisting of two people, B.
  • the name of the common wallet (“camping funds” in this example) is displayed along with an image of a square wallet indicating that it is a common wallet.
  • various setting icons are displayed next to it.
  • the balance (“90,000 yen" in this example) is displayed in the lower row, and the icon image and user name of the user who jointly uses this common wallet are displayed next to it.
  • the E icon is displayed.
  • this common wallet for traveling to South Korea is the user A.
  • a "+” mark is displayed in the center of the new registration operation area 244 so that the user can easily recognize that it is an operation area for newly adding / registering a common wallet. .. Not only this "+” mark is touch-operated, but also any position in the new registration operation area 244 is touch-operated, so that a new common wallet can be newly created / registered.
  • FIG. 2-3 is a diagram showing an example of a camp fund payment screen displayed when the inside of the camp fund display area 242 is touch-operated on the common wallet selection screen of FIG. 2-2.
  • "Common Wallet: Camp Fund” which is a submenu currently being executed, is displayed as the current position in the above hierarchical menu.
  • a "main menu” is displayed as an operation guide for the user, and below that, a camp fund display area 242 is displayed.
  • the corresponding six icons are displayed.
  • the icon indicated as “code payment” is a “code payment icon” for obtaining a payment code from the server 10 when performing "user-presented” code payment.
  • the icon indicated as “code reader” is a code reader provided as a function of the code payment application in order to read the terminal reading code on the terminal 20 when performing "store presentation type” code payment.
  • an application code reader which is a code reader icon for starting.
  • the icon indicated as “code payment” on the camp fund payment screen of FIG. 2-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen which is displayed when the touch operation is performed by A. In this example, under the title bar, "Camp Fund”, which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”. Further, under “camp fund”, “code payment” is displayed as an operation guide for the user, and below that, the camp fund code payment area 2421 is displayed.
  • camp fund code payment area 2421 the image of the square wallet, the name of the common wallet (camp fund), and the common wallet balance of this camp fund (“1,000 yen” in this example) are displayed in the same manner as above. There is.
  • My wallet are displayed along with an image of a purse that indicates that it is the wallet (electronic money account) of the user of the terminal 20, and the balance (electronic money account balance) is displayed next to it. (In this example, "25,000 yen”) is displayed.
  • code image transmitted from the server 10 and received by the terminal 20, which is a code used for making payments in a common wallet, and is not limited but a bar as an example.
  • a one-dimensional payment code represented by a code and a two-dimensional payment code represented by a QR code (registered trademark) are displayed as an example, not limited.
  • these payment codes define a period during which payment can be made using these payment codes (hereinafter referred to as "code usable period").
  • the payment code is used as the payment code.
  • the remaining time of the code usable period is displayed in a countdown format.
  • the code usable period can be any period, but it is not limited and can be set as a period of "5 minutes" as an example.
  • the code usable period is defined as the period during which the payment code is displayed on the terminal 20 (hereinafter referred to as "code display period"), and when the code display period ends, the displayed payment code is hidden. You may or may not do so.
  • the user of the terminal 20 presents the code payment screen to the store clerk at the code cash register and has the store code reader device 50 read the payment code to make the code payment.
  • FIG. 2-5 shows the common displayed on the display unit 24 of the terminal 20 when the common wallet balance is insufficient as a result of reading the payment code on the code payment screen of FIG. 2-4 by the store code reader device 50.
  • On this common wallet balance shortage screen "camping funds” are displayed as the current position, and under “camping funds", the common wallet balance shortage information display / operation area 2427 is displayed in a pop-up format.
  • an image of "robot with a troubled face” is displayed as an image indicating that the balance is insufficient
  • “common wallet balance is insufficient” is displayed as an image of insufficient balance below it.
  • a payment execution button 242W indicating "pay” as an example, not a limitation, for executing payment from one's wallet balance.
  • a payment non-execution button 242X indicating "do not pay” is displayed as an example, not a limitation, for not executing payment from one's wallet balance.
  • FIG. 2-6 shows the code payment displayed on the display unit 24 of the terminal 20 when the payment process by the server 10 is completed after the payment execution button 242W is touch-operated on the common wallet balance shortage screen of FIG. 2-5.
  • This code payment completion screen On this code payment completion screen, "camping funds” is displayed as the current position, and information on the payment result is displayed below it. Specifically, along with the characters "code payment”, the characters "THanK YOU! Are displayed as a payment completion message, and below that, "an image of a robot hurraying with a smile” is displayed to show gratitude. There is. Further, below that, the characters “Payment completed” are displayed together with the payment amount "3,000 yen”.
  • the breakdown of payments is displayed via the horizontal line.
  • information indicating that the payment amount from the common wallet of the camp fund is "1,000 yen" and the payment amount from the own wallet is "2,000 yen” is displayed.
  • ⁇ Processing> 2-7 to 2-8 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
  • the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case).
  • the store POS system (in the limited case).
  • each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1 is shown.
  • This process is an example of a process related to user-presented code payment.
  • the control unit 11 of the server 10 is the user A. who is the user of the terminal A.
  • the user account information (not limited, but as an example, the electronic money account balance) associated with the payment application ID of A is transmitted to the terminal A by the communication I / F14 (S120).
  • the control unit 21 of the terminal A displays the received user account information on the display unit 24 (A130). Specifically, as an example, not limited to the user A. of the terminal A.
  • the electronic money account balance of A is displayed in addition to the display unit 24.
  • the control unit 51 of the store code reader device 50 executes the store payment process, and based on the operation of the store code reader device 50 for the input / output unit 52, a predetermined payment scheduled amount (not limited, but as an example, "3,000 yen"". ) Is input to the control unit 51. Then, the control unit 51 of the store code reader device 50 uses the code reader 58 to read the payment code displayed on the display unit 24 of the terminal A (P100). In this case, since the payment code displayed on the display unit 24 is associated with the common wallet payment token, the reading result of the code reader 58 includes the common wallet payment token.
  • the control unit 51 of the store code reader device 50 transmits, as an example, not limited to, payment request information including a store ID, a payment schedule amount, and a common wallet payment token to the server 10 by communication I / F 54 (P110). ..
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and the store is used for the common wallet.
  • a payment process for paying the planned payment amount with the member store defined by the ID is executed (S250a).
  • the control unit 11 of the server 10 proceeds to the process in S180c.
  • the control unit 11 of the server 10 is not limited, but as an example, the fact that the settlement has failed and the insufficient amount of the settlement balance in the common wallet in that case.
  • the payment balance shortage information including the payment balance is transmitted to the terminal A and the store code reader device 50 by the communication I / F 14 (S270a).
  • the control unit 21 of the terminal A displays the received payment balance shortage information in addition to the display unit 24 (A). A280). Further, the control unit 21 of the terminal A stores the payment balance shortage amount included in the received payment balance shortage information in the storage unit 28 (A290).
  • the control unit 21 of the terminal A is based on the operation input (operation input to the input / output unit 23) for the user account information displayed on the display unit 24 together with the payment balance shortage information.
  • the control unit 11 of the server 10 executes the payment process (S170c). Specifically, as an example, not a limitation, the common wallet balance is reduced to "0", and the shortfall is reduced to the user A. Deduct from A's electronic money account balance.
  • control unit 11 of the server 10 uses the communication I / F 14 to send the payment result information including various information included in the payment completion screen of FIG. 2-6 to the terminal A and the store code reader device 50 as an example, not limited to the terminal A. And (S180c) to end the process.
  • the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22 and transfers the processing to the A180.
  • the control unit 51 of the store code reader device 50 displays the payment balance shortage information on the display unit 53 (P130). .. Then, the control unit 51 of the store code reader device 50 receives the payment result information from the server 10 and then shifts the process to P160.
  • the payment balance shortage information is displayed means "after the payment balance shortage information is displayed” or "when the payment balance shortage information is once displayed", and the payment balance shortage information is not necessarily displayed even now. It does not have to be done. That is, "input to the display unit 24 on which the payment balance shortage information is displayed” is (1) When the input is made to the display unit 24 while the payment balance shortage information is displayed after the payment balance shortage information is displayed. (2) The payment balance shortage information is displayed after the payment balance shortage information is displayed. Is a concept including the case where is hidden and then an input is made to the display unit 24. This also applies to the examples described below.
  • ⁇ Input to terminal> an example is shown in which the selection of whether or not to pay the shortfall from the user account (electronic money account) of the user of the terminal 20 is realized based on the operation input to the input / output unit 23 of the terminal 20. Not limited to this. This may or may not be realized by sound input (including voice input) to the microphone 25 of the terminal 20 or the like. This is the same for various inputs to the terminal 20.
  • the terminal 20 executes the processing related to the payment by the control unit 21 based on the account (not limited, but an example of the first account) that the user of the terminal 20 can settle.
  • the terminal 20 provides payment balance shortage information (not limited, but an example of first information regarding the fact that the balance of the first account is insufficient based on the amount of the first payment and the balance of the first account). It is displayed on the display unit 24. Then, the terminal 20 is based on the input to the display unit 24 on which the payment balance shortage information is displayed, from the user account of the user of the terminal 20 (not limited, but an example of a second account different from the first account).
  • It shows a configuration for executing a process of paying a shortfall and performing a settlement (not a limitation, but an example of a process related to the first settlement).
  • a settlement not a limitation, but an example of a process related to the first settlement.
  • the account that can be settled by the user of the own terminal 20 is a common account (not limited, but at least a common account that can be settled by at least the terminal user and the first user different from the terminal user).
  • a common account not limited, but at least a common account that can be settled by at least the terminal user and the first user different from the terminal user.
  • An example is shown.
  • payment can be realized based on a common account in which at least the terminal user and the first user different from the terminal user can settle.
  • FIG. 2-9 is a diagram showing an example of a code reader screen displayed on the display unit 24 of the terminal 20.
  • the "code reader” icon instead of the "code payment” icon is displayed by the user A. of the terminal 20.
  • the application code reader is activated as an example, not limited to the case, and the code reader screen for reading the payment store code as shown in FIG. 2-9 is displayed on the display unit 24.
  • "Camp Fund" which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App” under the title bar.
  • a code reading area CR1 is displayed below it
  • a "code reader” is displayed below it as an operation guide for the user
  • a camp fund code payment area 2423 is displayed below it.
  • camp fund code payment area 2423 the characters "camp fund” are displayed at the top along with the image of the square wallet, and next to it, the common wallet balance of this camp fund ("1,000 yen” in this example) is displayed. It is displayed. Below that, the characters “my wallet” are displayed along with an image of a purse, and next to it, my electronic money account balance ("25,000 yen” in this example) is displayed.
  • FIG. 2-10 is a diagram showing an example of a reading completion screen displayed when the payment store code is read on the code reader screen of FIG. 2-9.
  • the read payment store code is displayed in the code reading area CR1. Further, the same information as in FIG. 2-9 is displayed in the camp fund code payment area 2423 at the bottom of the screen.
  • FIG. 2-11 is a diagram showing an example of a payment amount input screen displayed following FIG. 2-10.
  • the payment amount input screen for inputting the payment amount is displayed.
  • "Enter payment amount” is displayed as an operation guide for the user, and below that, along with an icon image of "AA Sports Co., Ltd.”, which is the remittance destination of the payment amount, the name "AA Sports""Co.,Ltd.” is displayed.
  • a payment amount display area 2424 for displaying the input payment amount is displayed.
  • the text “Please enter the payment amount (tax included)” is displayed below it, and the payment button 242C is displayed below it.
  • a keyboard for inputting the payment amount is displayed, and an erase button CN4 for erasing the payment amount is displayed.
  • an erase button CN4 for erasing the payment amount is displayed.
  • a state in which "3,000 yen" is input as the payment amount and displayed in the payment amount display area 2424 is shown.
  • FIG. 2-12 shows an example of a common wallet balance shortage screen displayed based on the fact that the common wallet balance was insufficient after the payment button 242C was touch-operated on the payment amount input screen of FIG. 2-10. It is a figure.
  • the configuration of this common wallet balance shortage screen is the same as in FIG. 2-5.
  • the difference from FIG. 2-5 is that the background of the common wallet balance shortage information display / operation area 2427 is the code reader screen.
  • ⁇ Processing> 2-13 to 2-14 are flowcharts showing an example of the flow of processing executed by each device in this modification.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • the control unit 21 of the terminal A causes the display unit 24 to display a display screen for inputting the planned settlement amount, as an example, not a limitation.
  • the control unit 21 of the terminal A is not limited to, but as an example, the common wallet payment token included in the common wallet code reader information.
  • the payment request information including the store ID and the scheduled payment amount is transmitted to the server 10 by the communication I / F 22 (A310). If the payment store code includes the planned payment amount, it is possible to omit the input of the planned payment amount on the terminal A.
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and determines the common wallet by the store ID.
  • a store-presented payment process for paying the planned payment amount with the member store is executed (S250b). If the settlement is successful in S250b (S260b: YES), the control unit 11 of the server 10 shifts the processing to S180d.
  • the control unit 11 of the server 10 communicates the settlement balance shortage information including the settlement failure and the settlement balance shortage amount in the common wallet in that case. It is transmitted to the terminal A by / F14 (S270b).
  • the control unit 21 of the terminal A displays the payment balance shortage information on the display unit 24 (A280) and stores the payment balance shortage amount. It is stored in the part 28 (A290). Then, the control unit 21 of the terminal A shifts the processing to A295. Specifically, the control unit 21 of the terminal A transmits the settlement request information to the same effect as the A295 of FIG. 2-8 to the server 10 by the communication I / F22. Then, the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F 22, and shifts the processing to the A180.
  • the control unit 11 of the server 10 executes a store presentation type payment process to the same effect as S170c in FIG. 2-8 (S170d). Then, the control unit 11 of the server 10 transmits the payment result information to the terminal A by the communication I / F 14 (S180d), and ends the process.
  • the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22 and transfers the processing to the A180.
  • ⁇ Second modification (2)> when the common wallet balance is insufficient, the shortage is paid from the user account of the user of the terminal 20, but the present invention is not limited to this. Specifically, when the common wallet balance is insufficient, the common wallet balance may not be used and the full amount may or may not be paid from the user account of the user of the terminal 20. That is, the account for making payment may or may not be changed (switched) from the common account (common wallet) to the user account of the user of the terminal 20 (user's electronic money account balance). ..
  • the third embodiment is an embodiment in which remittance from one's own wallet to a common wallet is realized. By allowing you to transfer money from your wallet to the common wallet, you can replenish the common wallet balance in advance, or if the common wallet balance is insufficient at the time of payment, the common wallet balance will be replenished. It becomes possible to do.
  • FIGS. 3-1 to 3-3 are the same as the display screens of FIGS. 2-1 to 2-3, respectively.
  • the icon indicated as “code payment” on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen (before remittance) displayed when the touch operation is performed by A.
  • "Camp Fund” which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”.
  • camp fund "code payment” is displayed as an operation guide for the user, and below that, the camp fund code payment area 2421 is displayed.
  • camp fund code payment area 2421 the image of the square wallet, the name of the common wallet (camp fund), and the common wallet balance of this camp fund (“1,000 yen” in this example) are displayed in the same manner as above. There is.
  • a code (code image) transmitted from the server 10 and received by the terminal 20, which is a code used for making a payment in a "user presentation type", and is limited as a payment code.
  • a one-dimensional payment code represented by a barcode is displayed as an example, and a two-dimensional payment code represented by a QR code (registered trademark) is displayed as an example rather than a limitation.
  • these payment codes define a period during which payment can be made using these payment codes (hereinafter referred to as "code usable period").
  • the payment code is used as the payment code.
  • the remaining time of the code usable period is displayed in a countdown format.
  • the code usable period can be any period, but it is not limited and can be set as a period of "5 minutes" as an example.
  • the code usable period is defined as the period during which the payment code is displayed on the terminal 20 (hereinafter referred to as "code display period"), and when the code display period ends, the displayed payment code is hidden. You may or may not do so.
  • the check mark button CN2 is the user A. of the terminal 20. It is a figure which shows an example of the remittance screen which is displayed when the touch operation is performed by A.
  • "Camp Fund” which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”.
  • "Remittance” is displayed as an operation guide for the user, and below that, the user A.
  • the icon image of A and the user name "AA" are displayed.
  • the remittance schedule amount input area 2422 for displaying the input remittance schedule amount is displayed.
  • a state in which "5,000 yen” is entered as the planned remittance amount is shown.
  • the amount to be added to the planned remittance amount input area 2422 is input.
  • the first addition button BT1 for adding "100 yen” and “1,000 yen” are added.
  • the second addition button BT2 for adding "10,000 yen” and the third addition button BT3 for adding "10,000 yen” are displayed side by side in the horizontal direction.
  • the inside of the planned remittance amount input area 2422 is "5,100 yen”. Is displayed, and if the second addition button BT2 is touch-operated once, "6,100 yen” is displayed, and if the third addition button BT3 is touch-operated once, "16,100 yen” is displayed. Is displayed.
  • the erase button CN3 is displayed on the left side of the remittance scheduled amount input area 2422, and when the erase button CN3 is touch-operated, the amount in the remittance scheduled amount input area 2422 is erased. "0 yen” is displayed in the remittance scheduled amount input area 2422.
  • the user A under the first addition button BT1, the user A.
  • the balance in A's own wallet here, "25,000 yen" is displayed.
  • the remittance button 242A for executing the remittance of the amount input in the remittance scheduled amount input area 2422 is displayed at the lower part of the remittance screen.
  • a ten-key area for inputting the planned remittance amount is displayed at the bottom of the display unit 24, and the planned remittance amount is input in detail based on the input to the ten-key area. It is also possible.
  • FIG. 3-6 is a diagram showing an example of a code payment screen (after remittance) displayed when the remittance button 242A is touch-operated on the remittance screen of FIG. 3-5.
  • the camp fund code payment area 2421 is the same as in FIG. 3-4, but the amount of the balance is different because it is after the remittance. In other words, "6,000 yen" with the remittance amount added is displayed as the common wallet balance of the camp funds, and "20,000 yen” with the remittance amount subtracted is displayed as the balance of your electronic money account. There is.
  • the check mark button CN2 indicating that the remittance has been performed is highlighted.
  • the payment codes are the same as those in FIG. 3-4.
  • Terminal 20 user A presents the above code payment screen to the store clerk at the code cash register, and has the store code reader read the payment code to make the code payment.
  • FIG. 3-7 is a diagram showing an example of a code payment completion screen displayed on the terminal 20 when the code payment by the server 10 is completed.
  • “Camping Fund” is displayed as the current position
  • “Code Payment” is displayed in the lower center of "Camping Fund”.
  • FIG. 3-8 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
  • the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case).
  • the store POS system (in the limited case).
  • each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1 is shown.
  • This process is an example of a process related to user-presented code payment.
  • the latter half of the process is not limited and can be the same as that shown in FIG. 1-9 as an example, and thus the description thereof will be omitted here.
  • the control unit 21 of the terminal A is the user A.
  • Information for selecting whether or not to transfer money from the electronic money account of A to the common wallet (not limited, but as an example, a button having a selection function) is displayed in addition to the display unit 24.
  • the control unit 21 of the terminal A uses the user A.I. It is determined whether or not it is selected to transfer money from A's electronic money account to the common wallet (A140).
  • the control unit 21 of the terminal A displays a screen (remittance screen) prompting the input of the remittance amount on the display unit 24 as an example, not limited. ..
  • the control unit 21 of the terminal A transmits the remittance request information including the remittance amount to the server 10 by the communication I / F 22 (A150). ).
  • control unit 11 of the server 10 transmits the common wallet information including the common wallet balance after the remittance to the terminal A by the communication I / F14 (S150).
  • the control unit 21 of the terminal A updates and displays the common wallet balance on the display unit 24 as an example, not limited, based on the received common wallet information. Let (A160).
  • control unit 11 of the server 10 is the user A.
  • the user account information including the electronic money account balance of A is transmitted to the terminal A by the communication I / F14 (S160). Then, the control unit 11 of the server 10 shifts the processing to S170a of FIG. 1-9.
  • the control unit 21 of the terminal A is based on the received user account information, and the user A.
  • the electronic money account balance of A is updated and displayed on the display unit 24 (A170). Then, the control unit 21 of the terminal A shifts the processing to A180 of FIG. 1-9.
  • control unit 11 of the server 10 does not receive the remittance request information (S130: NO), and the steps S140 to S160 are not executed.
  • the input to the terminal 20 is not limited to the operation input.
  • an example is shown in which the selection of whether or not to transfer money from the user account (electronic money account) of the user of the terminal 20 to the common wallet is realized based on the operation input to the input / output unit 23 of the terminal 20. , Not limited to this. This may or may not be realized by sound input (including voice input) to the microphone 25 of the terminal 20 or the like.
  • the terminal 20 has common wallet code information (not limited, but an example of the first code) associated with an account (not limited, but an example of the first account) that can be settled by the user of the terminal 20.
  • An example) and user account information (an example of a second account information, not a limitation) relating to a user account (an example of a second account, not a limitation) of a user of the own terminal 20 are displayed on the display unit 24.
  • the terminal 20 is an input (operation input, sound input, etc.) (not limited, but not limited) by the user of the terminal 20 for selecting to transfer money from the electronic money account of the user account of the user account to the common wallet.
  • Terminal as processing related to payment such as processing to display, processing to display payment code on display unit 24, processing to receive payment result information from server 10, processing to display received payment result information on display unit 24, etc.
  • the configuration in which the control unit 21 executes the process executed in 20 (not limited to the process related to the first settlement based on the first account and the second account) is shown.
  • the first code information associated with the first account that can be settled by the user of the terminal can be displayed in the display area of the terminal and used for payment, and the first It is possible to make the terminal user recognize the second account information regarding the second account different from the account.
  • payment based on the first account and the second account can be realized based on the input to the second account information.
  • the account that can be settled by the user of the own terminal 20 is at least the user of the own terminal 20 (user AA as an example) (not limited, but an example of the user of the terminal).
  • a configuration is shown in which users of different terminals 20 (user BB as an example) (not limited, but an example of a first user different from the user of the terminal) can settle a common account.
  • the first code information can be displayed in the display area of the terminal and used for payment
  • the second account information regarding the second account different from the common account can be displayed on the terminal. It can be recognized by the user.
  • payment based on the common account and the second account can be realized based on the input to the second account information.
  • the terminal 20 uses the information of the common wallet balance (not limited, but the amount of the first electronic money associated with the common account) and the remittance screen (not limited, but common from the second account).
  • An example of the first display for sending money to the account) is displayed on the display unit 24.
  • the terminal 20 executes the transfer from the user account of the user of the own terminal 20 to the common account based on the input (operation input, sound input, etc.) to the money transfer screen by the user of the own terminal 20.
  • the display unit 24 shows the information of the common wallet balance (not limited, but the amount of the second electronic currency associated with the common account) after the remittance.
  • the amount of the first electronic money associated with the common account can be notified to the user of the terminal.
  • remittance from the second account to the common account can be easily realized based on the input to the first display, and the second electronic money associated with the common account can be easily realized based on the remittance to the common account.
  • the amount can be notified to the user of the terminal.
  • the third embodiment shows a configuration in which the process related to the first payment is executed based on the common account sent from the user account (not limited, but an example of the second account) of the user of the own terminal 20. ing.
  • the process related to the first payment is executed based on the common account sent from the user account (not limited, but an example of the second account) of the user of the own terminal 20. ing.
  • payment can be realized based on the common account remitted from the second account.
  • the input to the remittance screen (an example of the input to the first display, not the limitation) is common from the user account of the user of the own terminal 20 (an example of the second account, not the limitation). It shows the configuration including the input of the amount to be transferred to the account.
  • remittance from the second account to the common account can be realized based on the input of the amount of money to be remitted from the second account to the common account.
  • the third embodiment shows a configuration in which the second account is a user account of the user of the terminal 20 (not limited, but an example of the account of the user of the terminal).
  • the settlement can be realized by using the account of the user of the terminal as the second account.
  • the user-presented code payment has been described, but the present invention is not limited to this. Specifically, instead of limiting, a store-presented code payment can be applied as an example.
  • FIG. 3-9 is a diagram showing an example of a code reader screen displayed on the display unit 24 of the terminal 20.
  • the icon of "code reader” instead of the icon of "code payment” is the user A. of the terminal 20.
  • the application code reader is activated as an example, not limited to the case, and the code reader screen for reading the payment store code as shown in FIG. 3-9 is displayed on the display unit 24.
  • "Camp Fund” which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App” under the title bar.
  • the code reading area CR1 is displayed under the "camp fund”
  • the "code reader” is displayed below it as an operation guide for the user
  • the camp fund code payment area 2423 is displayed below it. There is.
  • camp fund code payment area 2423 the word "camp fund” is displayed along with an image of a square wallet indicating that it is a common wallet at the top, and next to it, the common wallet balance of this camp fund ("1 in this example”). 000 yen ”) is displayed. Below that, the balance of your electronic money account (“25,000 yen” in this example) is displayed along with the check mark button CN2 and the characters of the remittance from your wallet.
  • the check mark button CN2 is the user A. of the terminal 20.
  • the touch operation is performed by A, the same remittance screen as in FIG. 3-5 is displayed.
  • the user A is an example in which A sends "5,000 yen" from his wallet to a common wallet.
  • FIG. 3-10 is displayed when the remittance button 242A is touch-operated on the remittance screen of FIG. 3-5 to complete the remittance from the wallet to the camp fund, and then the reading of the payment store code is completed.
  • the read payment store code is displayed in the code reading area CR1.
  • the camp fund code payment area 2423 as described above, the user A. Based on A's remittance of "5,000 yen" from his wallet to the common wallet, "6,000 yen” is displayed as the common wallet balance of the camp funds, and "20,000 yen” as his electronic money account balance. "Circle” is displayed.
  • the check mark button CN2 indicating that the remittance has been performed is highlighted.
  • FIG. 3-11 is a diagram showing an example of a payment amount input screen displayed when information is acquired by decoding from the payment store code read on the reading completion screen of FIG. 3-10.
  • “Enter payment amount” is displayed as an operation guide for the user, and below that, the icon image of "AA Sports Co., Ltd.”, which is the remittance destination of the payment amount, and the name "AA Sports Co., Ltd.” are displayed.
  • “Co., Ltd.” is displayed.
  • a payment amount display area 2424 for displaying the input payment amount is displayed, and here, "3,000 yen” is input and displayed as the payment amount.
  • the text "Please enter the payment amount (tax included)" is displayed below it, and the payment button 242C is displayed below it. Further, at the lower part of the screen, a keyboard for inputting the payment amount is displayed, and an erase button CN4 for erasing the payment amount is displayed.
  • the code payment completion screen is displayed as in FIG. 3-7.
  • FIG. 3-12 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • the latter half of the process is not limited and can be the same as that of FIG. 1-11 as an example, and thus the description thereof will be omitted here.
  • a common wallet payment token is generated in the same manner as in S100a of FIG. 3-8, and the control unit 11 of the server 10 generates common wallet code reader information which is code reading information including the common wallet payment token. Then, the control unit 11 of the server 10 transmits the common wallet code reader information to the terminal A by the communication I / F 14 (S100b). Then, the control unit 11 of the server 10 shifts the processing to S110.
  • the control unit 21 of the terminal A reads the payment store code based on the received common wallet code reader information.
  • the screen is displayed on the display unit 24. Further, the control unit 21 of the terminal A activates the camera 27 to read the code (A110b). Then, the control unit 21 of the terminal A shifts the processing to the A120.
  • the control unit 21 of the terminal A acquires the store ID from the read payment store code (A190).
  • the control unit 21 of the terminal A causes the display unit 24 to display a display screen for inputting the planned settlement amount.
  • the control unit 21 is not limited, but as an example, the common wallet payment token included in the common wallet code reader information and the store ID.
  • the payment request information including the payment schedule amount and the payment schedule amount is transmitted to the server 10 by the communication I / F 22 (A200). Then, the control unit 21 of the terminal A shifts the processing to the A180.
  • the payment store code includes the planned payment amount, it is possible to omit the input of the planned payment amount on the terminal A.
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and the common wallet is subjected to the request.
  • a payment process for paying the planned payment amount with the member store defined by the store ID is executed (S170b).
  • control unit 11 of the server 10 transmits the settlement result information including the success / failure of the settlement process and the common wallet balance after the settlement process to the terminal A by the communication I / F14 (S180b). Then, the control unit 11 ends the process.
  • the terminal 20 uses a code reader screen for reading the payment store code (an example of code information, not limited) based on the common wallet code reader information (an example of first code reader information, not limited). And the user account information (an example of the second account information, not the limitation) regarding the user account (an example of the second account, not the limitation) of the user of the own terminal 20 is displayed on the display unit 24. Then, the terminal 20 is an input (operation input, sound input, etc.) (not limited, but a first) for the user of the own terminal 20 to select to transfer money from the electronic money account of the user account of the user account to the common wallet.
  • code reader screen for reading the payment store code (an example of code information, not limited) based on the common wallet code reader information (an example of first code reader information, not limited).
  • the user account information an example of the second account information, not the limitation
  • the terminal 20 is an input (operation input, sound input, etc.) (not limited, but a first) for the user of the own terminal 20 to select to transfer money
  • a configuration is shown in which the control unit 21 executes a process executed on the terminal 20 as a process (not limited to an example of a process related to the first settlement based on the first account and the second account).
  • the first code reader information which is a display related to reading the code information, can be displayed in the display area of the terminal and used for payment, and is different from the first account. It is possible to make the user of the terminal recognize the second account information regarding the two accounts. In addition, payment based on the first account and the second account can be realized based on the input to the second account information.
  • ⁇ Third modification (2)> the user A. at the start of payment.
  • An example of remittance from the balance of A's electronic money account to a common wallet is shown, but the present invention is not limited to this.
  • User A Before sending money to a common wallet, User A. From an external financial institution account pre-registered by A, user A. You may charge (remittance) to A's electronic money account.
  • the display in the camp fund code payment area 2421 is almost the same as in Figure 3-4, but with some differences. Specifically, as an example, not a limitation, a charge button CN5 for charging your e-money account is displayed next to the amount of your e-money account balance associated with "transfer from your wallet". ing. Further, in this example, "1,000 yen” is displayed as the balance of one's own electronic money account. Further, below that, as a display for charging the common wallet, the characters "charge to the common wallet" are displayed together with the check mark button CN2.
  • FIG. 3-14 is a diagram showing an example of a charge screen displayed when the charge button CN5 is touch-operated on the code payment screen (before charging) of FIG. 3-13.
  • My wallet which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”. Further, under “my wallet”, “charge” is displayed as an operation guide for the user, and below that, a bank account display area 2425 is provided.
  • the bank name " ⁇ ⁇ Bank” is displayed together with the " ⁇ ⁇ Bank” logo ( ⁇ ⁇ BANK) in the bank account display area 2425.
  • “Savings account******” is displayed as the deposit type and account number, and below that, "AA”, which is the account holder, is displayed.
  • a charge schedule amount input area 2426 for displaying the input scheduled charge amount is provided together with the display of the "charge amount”.
  • “24,000 yen” is input and displayed as the planned charge amount.
  • the charge amount is input to the scheduled charge amount input area 2426.
  • the first charge button BT5 for charging "100 yen” and “1,000 yen” are charged.
  • the second charge button BT6 for charging and the third charge button BT7 for charging "10,000 yen” are displayed side by side in the horizontal direction.
  • the erase button BT8 is displayed on the left side of the scheduled charge amount input area 2426, and when the erase button BT8 is touch-operated, the amount in the scheduled charge amount input area 2426 is erased and the scheduled charge amount input area is deleted.
  • the inside of 2426 is displayed as "0 yen”.
  • a charge button 242D for executing charging of the amount input in the scheduled charge amount input area 2426 is displayed.
  • the charge button 242D is touch-operated, "24,000 yen" is charged to one's wallet.
  • a ten-key area for inputting the planned remittance amount is displayed at the bottom of the display unit 24, and the planned remittance amount is finely divided based on the input to the ten-key area. You can also enter it.
  • FIG. 3-15 is a diagram showing an example of a code payment screen displayed when the charge button 242D is touch-operated on the charge screen of FIG. 3-14.
  • the inside of the camp fund code payment area 2421 is the same as in Fig. 3-13, but the balance displayed next to the word "Remittance from your wallet” because it was charged ("25,000 yen” in this example). ) Is different.
  • the payment codes are the same as those in FIG. 3-13.
  • the user A As described above, after the check mark button CN2 corresponding to "Remittance from my wallet" is touched and the remittance is executed for the camp fund, the user A. of the terminal 20. A presents the above code payment screen to the store clerk at the code cash register, and has the store code reader read the payment code to make the code payment. When the payment process by the server 10 is completed, the same code payment completion screen as in FIG. 3-7 is displayed.
  • FIG. 3-16 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • the control unit 21 of the terminal A is not limited, but as an example, the user A.
  • the display unit 24 displays a screen for selecting whether or not to charge the electronic money account of A.
  • the control unit 21 of the terminal A determines that the user A. is based on the user operation on the input / output unit 23 of the terminal A. It is determined whether or not it is selected to charge the electronic money account of A (A210).
  • the control unit 21 of the terminal A When it is selected to charge the electronic money account of A (A210: YES), the control unit 21 of the terminal A causes the display unit 24 to display a screen prompting the input of the charge amount. When the charge amount is input based on the user operation on the input / output unit 23 of the terminal A, the control unit 21 of the terminal A transmits the charge request information including the charge amount to the server 10 by the communication I / F 22 ( A220).
  • the control unit 11 of the server 10 receives the user A.
  • the charge amount is reduced from the account balance of the external financial institution of A, and the user A.
  • a charge process for increasing the electronic money account balance of A by the charge amount is executed (S200).
  • the control unit 11 of the server 10 uses the user A.
  • the user account information including the electronic money account balance of A is transmitted to the terminal A by the communication I / F14 (S210).
  • the user A In the processing of S200, the user A. If the charge is not performed normally because the account balance of A's external financial institution is less than the charge amount, user account information including the fact that the charge has failed may or may not be sent. May be good.
  • the control unit 21 of the terminal A is based on the received user account information, and is not limited, but as an example, the user A. of the terminal A.
  • the electronic money account balance of A is updated and displayed on the display unit 24 (A230).
  • the user A By executing the steps A210 to A230 and the steps S190 to S210 after the remittance process to the common wallet (A170 and S160 in FIG. 3-16), the user A.
  • Electronic money may or may not be charged to A's electronic money account.
  • the user A An example of remittance from the balance of A's electronic money account to a common wallet is shown, but the present invention is not limited to this.
  • User A You may charge (remittance) as electronic money from the account of an external financial institution registered in advance by A to the common wallet.
  • FIG. 3-17 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • control unit 21 of the terminal A causes the display unit 24 to display a screen for selecting whether or not to charge the common wallet, as an example, not a limitation. Then, the control unit 21 of the terminal A determines whether or not it is selected to charge the common wallet based on the user operation on the input / output unit 23 of the terminal A (A240).
  • the control unit 21 of the terminal A When charging to the common wallet is selected (A240: YES), the control unit 21 of the terminal A causes the display unit 24 to display a screen prompting the input of the charge amount to the common wallet.
  • the control unit 21 of the terminal A communicates the common wallet charge request information including the charge amount to the common wallet. It is transmitted to the server 10 by the I / F 22 (A250).
  • control unit 11 of the server 10 transmits the common wallet information including the common wallet balance after the common wallet charge process to the terminal A by the communication I / F14 (S240).
  • the user A In the process of S230, the user A. If the charge is not performed normally because the account balance of the external financial institution A is less than the charge amount to the common wallet, the common wallet information including the fact that the charge has failed may be sent. You do not have to send it.
  • the control unit 21 of the terminal A updates the common wallet balance to the display unit 24 based on the received common wallet information, not as a limitation but as an example. Display (A260).
  • the electronic money may be charged to the common wallet by executing the steps A240 to A260 and the steps S220 to S240 after the remittance process to the common wallet (A170 and S160 in FIG. 3-17). , You don't have to.
  • the terminal 20 transfers money to the common wallet by transmitting information requesting remittance to the common wallet to the terminal 20 of another common wallet member different from the user of the own terminal 20. You may or may not have it.
  • FIG. 3-18 is a diagram showing an example of a code payment screen displayed on the display unit 24 of the terminal 20 in this modified example.
  • An example of a screen displayed on the display unit 24 of the terminal 20 (terminal A) of A is shown.
  • This code payment screen is a code payment screen corresponding to the common wallet for Korean travel, and remittance from your own wallet to the common wallet in the Korean travel display area 2431 which is the display area of the common wallet for Korean travel.
  • "Remittance from your wallet” item and the "Charge to common wallet” item to charge the common wallet "Other” to request other common wallet members to transfer money to the common wallet.
  • a check mark button CN2 is provided in association with each of these items to execute the process corresponding to the item.
  • FIG. 3-19 is an example of a member selection screen displayed on the display unit 24 when the check mark button CN2 associated with the item of the remittance request to another member is touch-operated on the code payment screen of FIG. 3-18. It is a figure which shows.
  • This member selection screen is a screen for selecting a common wallet member (remittance request destination) for which remittance is requested, and a list of common wallet member candidates is displayed in the center of the screen.
  • the user D. is a common wallet member of the common wallet for traveling to South Korea, and is a common wallet member other than the user (user AA) of his / her terminal 20.
  • D and user E Two people with E are displayed together with the icon image and the user name.
  • a check mark button CN2 is displayed in association with each common wallet member, and by setting the check mark button CN2 to the "ON" state, the common wallet member can be selected as a remittance request destination. It is configured in. In this case, not only one person but also two or more (including all) common wallet members can be selected as the remittance request destination.
  • a remittance request button 242U indicating "remittance request” for executing a remittance request and a back button 242V indicating "back” for returning to the previous screen are displayed. ing.
  • the remittance request button 242U is grayed out as an example, not limited to the state where all the check mark buttons CN2 are "OFF", and the operation cannot be accepted.
  • the grayout is canceled and the operation can be accepted.
  • Talk using a messaging application is an example of "chat”
  • a talk room is an example of "chat room”.
  • Chat is a means for users of terminals 20 to communicate with each other using a data communication line on a computer network
  • chat room is a virtual room for performing this chat.
  • Chat includes messaging services: MS (including instant messaging services (IMS)) and social networking services: those that use SNS. Further, as an example, not limited to, those using a so-called short message service may be included.
  • the chat includes a talk using a messaging service
  • the chat room includes a talk room for conducting a talk.
  • the talk room includes a talk room for users to talk one-on-one, and a group talk room for talking with a group including a plurality of users formed in a messaging service.
  • FIG. 3-20 is a diagram showing an example of the configuration of the server 10 in this modified example.
  • the server 10 includes, but is not limited to, a payment management server 10A and a messaging management server 10B as an example.
  • the payment management server 10A is a server (application server of a payment application) that provides a payment service.
  • the messaging management server 10B is a server (application server for a messaging application) that provides a messaging service (MS: Messenger Service).
  • MS Messenger Service
  • the payment application may be provided by the server 10 as a single application having no messaging service function as in the above embodiment, or may be provided by the server 10 as a modified example of the messaging service function. It may be provided by the server 10 as a complex application having the above.
  • the messaging service may or may not include an instant messaging service (IMS: Instant Messaging Service) that enables transmission and reception of contents such as simple messages between terminals 20.
  • IMS Instant Messaging Service
  • the messaging management server 10B will be described as providing IMS as an example, not a limitation, as a messaging service.
  • the messaging application and the payment application are configured as a complex application, and the information of the user of the messaging application and the information of the user of the payment application are managed by the server 10 as common information. I will explain it as a thing. Further, in the following, the name of the messaging application will be illustrated and described as "Messing App" as appropriate.
  • FIG. 3-21 shows the user A. It is a figure which shows an example of the member selection screen (talk room selection screen) in the messaging application executed by the terminal A of A.
  • the member selection screen (talk room selection screen) in the messaging application executed by the terminal A of A.
  • the check mark button CN2 associated with the item of the remittance request to another member is touch-operated on the code payment screen of FIG. 3-18, the screen of the payment application is changed to the screen of the messaging application. , This member selection screen is displayed.
  • this member selection screen the characters "Messageing App” are displayed at the upper part of the screen, and the icon image and the user name of the user (user AA in this example) of the own terminal 20 are displayed next to the characters.
  • the text "Select from talk room” the text "Please select a talk room to request remittance” is displayed, and below that, candidates for the talk room to be selected as the remittance request destination are displayed.
  • A. A user who is registered as a friend and is a user who is related to the common wallet for traveling to Korea.
  • a talk room for A to talk user D. who is a common wallet member.
  • the talk room of E is displayed.
  • A A user who is registered as a friend and is a user who is related to the common wallet for traveling to Korea.
  • a group talk room for A to perform a group talk as an example, not limited to the user A.
  • D and user E The group talk room of "Korean Gourmet Union (3)" consisting of three people with E is displayed.
  • a check mark button CN2 is displayed in association with each talk room, and by setting the check mark button CN2 to the "ON" state, the talk room (user of the talk room) is selected as the remittance request destination. It is configured to be able to. In this case, as an example, not limited to one person, it is possible to select not only one user but also two or more (including all) users as the remittance request destination.
  • the group talk room may not be displayed as a candidate for the remittance request destination on the member selection screen in the above messaging application.
  • User A All users registered as friends with A, user A. in the payment application.
  • the talk room of the user or the like selected and set by A may or may not be displayed as a candidate for the remittance request destination.
  • the second account is an example of a user account (not limited, but an example of the first user) of another common wallet member (not limited, but an example of the first user) different from the user of the own terminal 20. ) Is shown.
  • the effect obtained by such a configuration it is possible to realize the payment based on the common account and the second account by using the account of the first user as the second account.
  • this modification shows a configuration in which the user accounts of other common wallet members are selected based on the input to the own terminal 20 by the user of the own terminal 20.
  • the second account can be easily selected based on the input to the terminal by the user of the terminal.
  • the user accounts of other common wallet members are selected based on the selection of a talk room (not limited, but an example of a chat room) including the user of the own terminal 20 and other common wallet members. It shows the configuration to be done. As an example of the effect obtained by such a configuration, the second account can be easily selected based on the selection of the chat room including the terminal user and the first user by the terminal user.
  • the terminal 20 uses the payment application to execute payment at the member store from the common wallet balance, but when the common wallet balance is insufficient at the time of payment, the common wallet balance is insufficient. This is an embodiment of displaying information about what is being done. Further, in the fourth embodiment, when the common wallet balance is insufficient, instead of the common wallet, from the electronic money account of the user of the own terminal 20 to the common wallet based on the method described in the third embodiment. This is an example of compensating for the insufficient balance of the common wallet by remittance.
  • FIG. 4-1 shows a common wallet displayed when the code payment is made with the payment code without touching the check mark button CN2 on the code payment screen of FIG. 3-4, and the common wallet balance is insufficient.
  • FIG. 4-1 shows an example of the balance shortage screen.
  • “camping funds” are displayed as the current position, and under “camping funds”, the common wallet balance shortage information display / operation area 2427 is displayed in a pop-up format.
  • the image of "robot with troubled face” is displayed as an image indicating that the balance is insufficient, and "common wallet balance is insufficient” is displayed below it as the balance shortage message.
  • remittance is shown as an example, not a limitation, for executing remittance of the shortage amount in order to make up for the balance shortage.
  • the remittance button 242E is displayed.
  • a cancel button 242F indicating "I will not do it now” is displayed as an example, not a limitation, in order not to execute the remittance of the insufficient amount.
  • FIG. 4-2 is a diagram showing an example of a code payment screen (after remittance) displayed when the remittance button 242E is touch-operated on the common wallet balance shortage screen of FIG. 4-1.
  • the camp fund code payment area 2421 is the same as in Fig. 3-4, but the amount of the balance is different because it is after remittance from your wallet. In other words, "3,000 yen" with the remittance amount added is displayed as the common wallet balance of the camp funds, and "23,000 yen” with the remittance amount subtracted is displayed as the balance of your electronic money account. There is.
  • FIG. 4-3 is a diagram showing an example of a code payment completion screen displayed on the terminal 20 when the code payment by the server 10 is completed as in FIG. 3-7.
  • the code payment completion screen shown in FIG. 4-3 is different from the code payment completion screen shown in FIG. 3-7 in that the payment breakdown is added under the payee under the payee.
  • the image of the square wallet and the characters of the camp fund, as well as the common wallet balance of this "camp fund"("1,000yen” in this example) are displayed.
  • the balance of your electronic money account (“2,000 yen” in this example) is displayed along with the image of your purse and the characters of your wallet.
  • ⁇ Processing> 4-4 to 4-5 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown. This process is an example of a process related to user-presented code payment.
  • the control unit 51 of the store code reader device 50 executes the store payment process, and based on the operation of the store code reader device 50 for the input / output unit 52, a predetermined payment scheduled amount (not limited, but as an example, "3,000 yen"". ) Is input to the control unit 51. Then, the control unit 51 of the store code reader device 50 uses the code reader 58 to read the payment code displayed on the display unit 24 of the terminal A (P100). In this case, since the payment code displayed on the display unit 24 is associated with the common wallet payment token, the reading result of the code reader 58 includes the common wallet payment token.
  • the control unit 51 of the store code reader device 50 transmits, as an example, not limited to, payment request information including a store ID, a payment schedule amount, and a common wallet payment token to the server 10 by communication I / F 54 (P110). ..
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token and puts it in the common wallet.
  • a settlement process for paying the planned settlement amount with the member store defined by the store ID is executed (S250a).
  • the control unit 11 of the server 10 proceeds to S180a.
  • the control unit 11 of the server 10 provides the settlement balance shortage information including the fact that the settlement has failed and the settlement balance shortage amount in the common wallet in that case.
  • the communication I / F 14 transmits to the terminal A and the store code reader device 50 (S270a).
  • the control unit 11 of the server 10 shifts the processing to S130.
  • Each step of S130 to S160 is the same as in FIG. 3-8.
  • the control unit 11 of the server 10 advances the process to S170a.
  • the control unit 21 of the terminal A displays the received payment balance shortage information on the display unit 24 (A280). ..
  • control unit 21 of the terminal A stores the payment balance shortage amount included in the received payment balance shortage information in the storage unit 28 (A290). Then, the control unit 21 of the terminal A shifts the processing to the A140. Each step of A140 to A170 is the same as in FIG. 3-8. Then, the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F 22, and proceeds to the processing to the A180.
  • the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22 and proceeds to the processing to the A180.
  • the control unit 51 of the store code reader device 50 displays the payment balance shortage information on the display unit 53 (P130). Then, the control unit 51 of the store code reader device 50 executes the code reading process again (P140). Then, the control unit 51 of the store code reader device 50 proceeds to P150 for processing.
  • the control unit 51 of the store code reader device 50 receives the payment result information from the server 10 by the communication I / F 54 and processes it in P160. To proceed.
  • the terminal 20 executes the processing related to the payment by the control unit 21 based on the account (not limited, but an example of the first account) that the user of the terminal 20 can settle.
  • the terminal 20 provides payment balance shortage information (not limited, but an example of first information regarding the fact that the balance of the first account is insufficient based on the amount of the first payment and the balance of the first account). It is displayed on the display unit 24. Then, the terminal 20 is based on the input to the display unit 24 on which the payment balance shortage information is displayed, from the user account of the user of the terminal 20 (not limited, but an example of a second account different from the first account).
  • It shows a configuration for executing a process of sending money to a common account (not limited, but an example of a process related to the first settlement).
  • a common account not limited, but an example of a process related to the first settlement.
  • it is possible to notify the terminal user that the balance of the first account that can be settled by the terminal user is insufficient.
  • the account that can be settled by the user of the own terminal 20 is a common account (not limited, but at least a common account that can be settled by at least the terminal user and the first user different from the terminal user).
  • a common account not limited, but at least a common account that can be settled by at least the terminal user and the first user different from the terminal user.
  • An example is shown.
  • payment can be realized based on a common account in which at least the terminal user and the first user different from the terminal user can settle.
  • the processing related to payment is executed based on the input to the display unit 24 on which the payment balance shortage information is displayed, and based on the common account and the user account of the user of the own terminal 20.
  • the configuration is shown. As an example of the effect obtained by such a configuration, payment can be realized based on at least a common account and a second account.
  • the payment (not limited, but an example of the first payment) is the common wallet balance (limited) among the common wallet balance and the electronic money account balance of the user account of the user of the own terminal 20. Instead, it shows a configuration in which payment is given priority from the balance of the common account).
  • the second account can be an ancillary account.
  • the fourth embodiment shows a configuration in which the payment is transferred from the user account of the user of the own terminal 20 to the common account and is performed based on the balance of the common account.
  • remittance can be made from the second account to the common account to replenish the amount, and payment can be made based on the balance of the common account.
  • the fourth embodiment shows a configuration in which the payment processing is remitted from the user account of the user of the own terminal 20 to the common account based on the input to the own terminal 20 by the user of the own terminal 20.
  • the user of the terminal can input to the terminal and transfer money from the second account to the common account.
  • the terminal 20 makes a payment associated with the user account of the user of the own terminal 20 based on the input to the display unit 24 on which the payment balance shortage information is displayed by the user of the own terminal 20.
  • Code reader screen for reading the payment store code (an example of code information, not limited) based on the code (an example of the first code information associated with the second account, not limited) or the common wallet code reader information (Not limited, but an example of the first code reader information) is displayed on the display unit 24.
  • the terminal 20 shows a configuration for executing a payment-related process based on the payment code being read or the code reader screen reading the payment store code by the terminal 20 displayed on the display unit 24. ing.
  • the first code information associated with the second account or the display related to the reading of the code information is based on the input by the terminal user to the display area where the first information is displayed.
  • the code reader information is displayed in the display area of the terminal and can be used for payment. Further, the settlement can be easily realized based on the fact that the first code information is read or the code information is read by the terminal in which the code reader information is displayed in the display area.
  • the fourth embodiment shows a configuration in which the second account is a user account of the user of the terminal 20 (not limited, but an example of the account of the user of the terminal).
  • the second account is a user account of the user of the terminal 20 (not limited, but an example of the account of the user of the terminal).
  • payment can be realized based on at least the account of the user of the terminal different from the first account.
  • the fourth embodiment shows a configuration in which the payment processing is executed based on the payment code displayed on the display unit 24 being read by the store code reader device 50.
  • the payment processing is executed based on the payment code displayed on the display unit 24 being read by the store code reader device 50.
  • the effect obtained by such a configuration payment can be easily realized based on the code information displayed in the display area being read.
  • the settlement balance shortage information (not limited, but an example of the first information) is the planned settlement amount (not limited, but an example of the first settlement amount) and the common wallet balance (not limited, not limited).
  • An example of the balance of the common account and if the common wallet balance is insufficient, the communication I / F22 of the terminal 20 from the server 10 (an example of a server that executes the first settlement process, not the limitation) Shows the configuration to be received.
  • the first information can be easily obtained from the server that executes the first settlement process.
  • the server 10 performs payment processing (not limited, but an example of the first account that can be settled by the user of the terminal) based on the account that can be settled by the user of one terminal 20 (in the limited case). Instead, the control unit 11 executes an example of processing related to the first settlement). In addition, the server 10 provides payment balance shortage information (not limited, but an example of first information regarding the fact that the balance of the first account is insufficient based on the amount of the first payment and the balance of the first account). , Is transmitted to one terminal 20 by communication I / F14.
  • the server 10 is based on the input by the user of one terminal 20 for the payment balance shortage information displayed on the display unit 24 of the terminal 20, and the user account of the user of the terminal 20 (not limited, but the first one).
  • the configuration in which the settlement process is executed by the control unit 11 is shown based on at least an example of a second account different from the account).
  • the user of the terminal can notify the terminal that the balance of the first account that can be settled is insufficient.
  • payments can be made based on at least a second account that is different from the first account.
  • the account that can be settled by the user of one terminal 20 is not limited, but as an example, a common account (not limited, at least a terminal user and a first user different from the terminal user) It can be an example of a common account that can be settled).
  • the control unit 21 of the terminal A causes the display unit 24 to display a screen prompting the input of the remittance amount.
  • the control unit 21 of the terminal A causes the display unit 24 to display a screen prompting the input of the remittance amount.
  • it is not limited to this.
  • control unit 21 of the terminal A may set the insufficient amount of the settlement balance stored in A290 of FIG. 4-4 as the remittance amount and transmit the remittance request information to the server 10. You don't have to.
  • control unit 11 of the server 10 when the control unit 11 of the server 10 receives the remittance request information in S130 of FIG. 4-4 (S130: YES), the control unit 11 transmits the user account information to the terminal 20 (S160 of FIG. 4-4). ), Even if the payment request information of S170a of FIG. 4-5 is executed based on the payment request information used in the payment process of S250a of FIG. 4-4 without receiving the payment request information from the store code reader device 50. You don't have to do it.
  • control unit 51 of the store code reader device 50 receives the payment result information from the server 10 by the communication I / F 54 after the step of P130 in FIG. 4-4, and executes the step of P160 in FIG. 4-5. ..
  • the user-presented code payment has been described, but the present invention is not limited to this. Specifically, it may be a store presentation type code payment.
  • FIG. 4-6 is a diagram showing an example of a common wallet balance shortage screen displayed when a code payment is made from the code reader screen of FIG. 3-9 and the common wallet balance is insufficient.
  • FIG. 4-6 differs from FIG. 4-1 in that the background of the common wallet balance shortage information display / operation area 2427 is the code reader screen.
  • FIG. 4-6 when the remittance button 242E is touch-operated to transfer "2,000 yen" from the balance of one's wallet, the payment amount input screen is displayed as in FIG. 3-11.
  • the payment button 242C is touch-operated as in FIG. 3-11
  • the code payment completion screen is displayed as in FIG. 4-3.
  • ⁇ Processing> 4-7 to 4-8 are flowcharts showing an example of the flow of processing executed by each device in this modification.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • control unit 21 of the terminal A reads the payment store code presented to the member store using the camera 27, and acquires the store ID from the payment store code (A300).
  • the control unit 21 of the terminal A causes the display unit 24 to display a display screen for inputting the planned settlement amount.
  • the control unit 21 is not limited, but as an example, the common wallet payment token included in the common wallet code reader information and the store ID.
  • the payment request information including the payment schedule amount and the payment schedule amount is transmitted to the server 10 by the communication I / F 22 (A310). If the payment store code includes the planned payment amount, it is possible to omit the input of the planned payment amount on the terminal A.
  • the control unit 11 of the server 10 searches for the common wallet ID from the requested common wallet payment token, and determines the common wallet by the store ID. A payment process for paying the planned payment amount with the member store is executed (S250b). If the settlement is successful in S250b (S260b: YES), the control unit 11 of the server 10 shifts the processing to S180b.
  • the control unit 11 of the server 10 communicates the settlement balance shortage information including the settlement failure and the settlement balance shortage amount in the common wallet in that case. It is transmitted to the terminal A by / F14 (S270b). Then, the control unit 11 of the server 10 shifts the processing to S130. Further, the control unit 11 of the server 10 receives the payment request information from the terminal A after S160, and shifts the processing to S170b.
  • control unit 21 of the terminal A When the control unit 21 of the terminal A receives the payment balance shortage information from the server 10 by the communication I / F 22 (A270b: YES), the control unit 21 displays the payment balance shortage information on the display unit 24 (A280) and stores the payment balance shortage amount. It is stored in the part 28 (A290). Then, the control unit 21 of the terminal A shifts the processing to the A140. Further, the control unit 21 of the terminal A shifts the processing to the A190 after the A170.
  • the control unit 21 of the terminal A sets the insufficient payment balance stored in A290 of FIG. 4-7. It may or may not be set as the remittance amount and the remittance request information may be transmitted to the server 10.
  • This modification shows a configuration in which the processing related to payment is executed based on the reading of the payment store code by the terminal 20.
  • the processing related to payment is executed based on the reading of the payment store code by the terminal 20.
  • payment can be easily realized based on the reading of the code information by the terminal.
  • control unit 21 of the terminal A updates the user account information (A170 in FIG. 4-7)
  • the control unit 21 in FIG. 4-8 is based on the payment request information transmitted in A310 in FIG. 4-7.
  • the payment request information of A200 may be transmitted to the server 10.
  • FIG. 4-9 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the first half of the process is not limited and can be realized by the same process as in FIGS. 4-4 and 4-5 as an example, and thus the description thereof will be omitted here.
  • control unit 21 of the terminal A displays the payment result information (A180)
  • the control unit 21 causes the display unit 24 to display a screen for selecting whether or not to settle (clear) the replacement amount (A320).
  • the selection screen May or may not be displayed on the display unit 24 and the process may be terminated. Further, when the payment balance shortage amount stored in the storage unit 28 of the terminal A is larger than "0" and the payment is successful, the selection screen is not displayed on the display unit 24 and the payment is automatically made. (A320: YES) may or may not be performed.
  • the control unit 21 of the terminal A When it is selected to perform settlement based on the user operation on the input / output unit 23 of the terminal A (A320: YES), the control unit 21 of the terminal A has insufficient payment balance stored in the storage unit 28 of the terminal A. The amount is transmitted to the server 10 by the communication I / F 22 (A330). On the other hand, when it is selected not to perform the settlement (A320: NO), the control unit 21 of the terminal A ends the process.
  • control unit 11 of the server 10 transmits the payment result information (S180a) and receives the payment balance shortage amount from the terminal A by the communication I / F 14, it determines whether or not the payment balance shortage amount is larger than "0". (S280). When the received payment balance shortage amount is "0" or the payment balance shortage amount is not received (S280: NO), it is determined that the payment balance is not insufficient or settlement is unnecessary, and the control unit 11 of the server 10 determines. End the process.
  • the control unit 11 of the server 10 sets the payment balance shortage amount to "M" and the number of users of the common wallet member.
  • M the number of constituent users of the common wallet
  • N the number of users of the common wallet
  • M ⁇ N the number of users of the common wallet
  • the control unit 11 of the server 10 transmits the payment advance amount request information including the payment advance amount to the terminals (here, terminal B) of each constituent user excluding the changer of the common wallet by the communication I / F14 (S290). ).
  • control unit 21 of the terminal B When the control unit 21 of the terminal B receives the payment advance payment billing information from the server 10 by the communication I / F 22 (B100: YES), the control unit 21 is for selecting the received payment advance payment amount and whether or not to accept the payment advance payment request. The screen is displayed on the display unit 24 (B110). If the control unit 21 of the terminal B does not receive the payment advance payment request information (B100: NO), the process ends.
  • the control unit 21 of the terminal B When it is selected to respond to the request for the payment advance amount based on the user operation on the input / output unit 23 of the terminal B (B110: YES), the control unit 21 of the terminal B requests the settlement of the payment advance amount.
  • the settlement request information is transmitted to the server 10 by the communication I / F 22 (B120).
  • the control unit 21 of the terminal B ends the process.
  • the control unit 11 of the server 10 executes the settlement remittance process (S310). On the other hand, when the settlement request information is not received (S300: NO), the control unit 11 of the server 10 shifts the processing to S330.
  • the control unit 11 of the server 10 transmits the settlement request result information including the remittance result to the terminals (here, terminal B) of each constituent user of the common wallet by the communication I / F 14 (S320).
  • the control unit 11 of the server 10 When transmitting payment advance payment billing information to two or more terminals in S290, the control unit 11 of the server 10 does not execute the settlement remittance process unless the settlement request information is received from all the transmitted terminals. It may or may not be. Further, in the settlement remittance process, the remittance may or may not be performed between the user's electronic money accounts without going through the common wallet.
  • control unit 11 of the server 10 sends the settlement result information including the remittance result to the user A. It is transmitted to the terminal A of A (S330), and the process is terminated.
  • the control unit 21 of the terminal B displays the settlement request result information on the display unit 24 (B130), and ends the process. Further, when the settlement result information is received from the server 10 by the communication I / F 22, the control unit 21 of the terminal A displays the settlement result information on the display unit 24 (A340), and ends the process.
  • the user B Based on the input of B, the remittance process to the common wallet based on the payment advance billing information is executed.
  • the account of A (not limited, but an example of the first account) is the user A.
  • A By payment by A (not limited, but an example of first payment), user A.
  • the user A When the amount paid from the user account of the terminal 20 of A or more is included in the common wallet, the user A.
  • the first account is the first when the common account contains an amount equal to or greater than the amount paid from the first account by the first settlement. The amount paid from the first account by the settlement can be remitted from the common account.
  • the control unit 21 of the terminal A is the user A. If it is selected to transfer money from A's electronic money account to the common wallet, User A.
  • the remittance request information was transmitted to the server 10 based on A's electronic money account, but the present invention is not limited to this.
  • FIG. 4-10 the icon indicated as “code payment” on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen (before remittance) displayed when the touch operation is performed by A.
  • Figure 4-10 differs from Figure 3-4 in the balance of your electronic money account displayed next to the words "Transfer from your wallet” in the camp fund code payment area 2421 (in this example, "1,". It is the amount of "000 yen").
  • FIG. 4-11 is a diagram showing an example of a common wallet balance shortage screen displayed when a code payment is made with a payment code on the code payment screen shown in FIG. 4-10 and the common wallet balance is insufficient. .. Fig. 4-11 differs from Fig. 4-1 in that the balance of your electronic money account displayed next to the characters "Transfer from your wallet” in the common wallet balance shortage information display / operation area 2427 (in this example). The amount is "1,000 yen”). In this example, the planned settlement amount is "3,000 yen", while the common wallet balance of the camp fund is "1,000 yen", which is "2,000 yen” short. Therefore, it is selected whether or not to remit the shortage of "2,000 yen” from the balance of one's wallet.
  • FIG. 4-12 is a diagram showing an example of one's own wallet balance shortage screen displayed when the remittance button 242E is touch-operated in the common wallet balance shortage screen shown in FIG. 4-11.
  • FIG. 4-12 is the same as the common wallet balance shortage information display / operation area 2427 in FIG. 4-11, but the characters "Insufficient balance in my wallet” displayed below the robot are displayed. , It is different from the guidance text "Do you want to charge your wallet?" Further, it is different that the charge button 242G for executing the charge of the insufficient amount is displayed at the lower part of the common wallet balance insufficient information display / operation area 2427 in order to make up for the insufficient balance. Further, below that, a cancel button 242H indicating "I do not do it now" is displayed as an example, not a limitation, for not executing the charge.
  • FIG. 4-12 when the charge button 242G is touch-operated to charge one's wallet, a charge screen similar to that in FIG. 3-14 is displayed as an example, not limited. Then, a desired amount of money can be charged on this charge screen. In this example, by charging "1,000 yen" to your wallet, your wallet balance becomes "2,000 yen", and it is possible to make up for the above shortfall.
  • the user A As described in the fourth modification (5), the user A. It is also possible to charge another user (user BB as an example, not a limitation) for the amount of money that A has reimbursed for payment.
  • FIG. 4-13 is a diagram showing an example of a code payment completion screen displayed on the terminal 20 when the code payment by the server 10 is completed, as in FIG. 4-2.
  • FIG. 4-13 is different from FIG. 3-7 in that the payment history confirmation button 242J and the advance payment request button 242K are displayed at the bottom of the code payment completion screen.
  • FIG. 4-14 shows the user B. who is a member of the camp fund of the common wallet as the billing destination for the replacement when the advance billing button 242K is touch-operated on the code payment completion screen of FIG. 4-13. It is a figure which shows an example of the notice screen which is displayed in order to request B for advance payment.
  • this application screen as an example, not limited to, "Payment App", which is an application name of a payment application, is displayed in the title bar at the top, and next to it, the user B.I. The icon image of B and the characters of the user name "BB" are displayed. Below the title bar, the "Notice” character is displayed as the current position in the hierarchical menu of "Payment App".
  • camp fund notification display area 2429 the name of the common wallet (“camp fund” in this example) is displayed along with an image of a square wallet indicating that it is a common wallet.
  • "April 11, 2020 16:35" is displayed as the date and time of the announcement, and below that, the user A. who jointly uses this common wallet.
  • a and user B The icon image of B is displayed.
  • the characters "advance billing amount” are displayed as the billing amount for the advance payment (hereinafter referred to as "advance billing amount"), and below that, the common wallet of this camp fund.
  • the balance (“1,000 yen” in this example) is displayed.
  • the words “Close details” are displayed, and below that, as detailed information on the amount billed for the advance payment, along with the logo image of AA Sports Co., Ltd., to which the payment amount is sent, the company name " The characters "AA Sports Co., Ltd.” are displayed.
  • “16:30 on April 11, 2020” is displayed next to it as the remittance date and time, and "3,000 yen” is displayed below it as the payment amount.
  • a remittance button 242L for executing the remittance of the amount for compensating for the insufficient balance and a button 242M for performing the remittance later are arranged side by side. It is displayed. Below that, a menu button 242N for returning to the menu is displayed.
  • FIG. 4-15 is a diagram showing an example of a payment history screen displayed when the payment history confirmation button 242J is touch-operated on the code payment completion screen of FIG. 4-13.
  • the payment history is displayed in chronological order in ascending order.
  • the information indicating that the advance payment has been requested is displayed on the display unit 24 of the terminal 20 of the billing source user, and the information indicating that the advance payment has been requested is displayed on the terminal of the billing destination user. It is possible to display on the display unit 24 of 20.
  • these information may be displayed on the application screen of the payment application, but instead, it can be displayed on the talk room screen of the messaging application described above.
  • FIG. 4-16 shows the user A.A. based on the operation of the advance payment request button 242K on the code payment completion screen of FIG. 4-13. It is a figure which shows an example of the talk room screen of the messaging application displayed on the display part 24 of the terminal 20 (terminal A) of A.
  • terminal A When the user of terminal A (user A.A) requests the user of terminal B (user BB) for the advance payment, a message to that effect is transmitted from the messaging management server 10B to terminal A.
  • user A. A is user B. It is displayed in the talk room for talking with B (the talk room with user BB as the talk partner).
  • B the talk room with user BB as the talk partner
  • User A As a message originating from A, user B.
  • the request for the advance payment to B and the first advance payment request message 2433 including the detailed information thereof are displayed in a balloon.
  • FIG. 4-17 shows the user B.I., based on the operation of the advance payment request button 242K on the code payment completion screen of FIG. 4-13. It is a figure which shows an example of the talk room screen of the messaging application displayed on the display part 24 of the terminal 20 (terminal B) of B.
  • terminal B When the user of terminal A (user AA) requests the user of terminal B (user BB) for the advance payment, a message to that effect is transmitted from the messaging management server 10B to terminal B.
  • the user A It is displayed in the talk room for talking with A.
  • User A As a message originating from A, the user A. From A to user B.
  • a second advance request message 2434 containing the fact that the advance amount has been requested to B and the detailed information thereof is displayed in a balloon.
  • FIG. 4-18 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown.
  • the control unit 21 of the terminal A is the user A.
  • the user A.A. is based on the payment balance shortage amount stored in A290 and the user account information displayed in A130. It is determined whether or not the electronic money account balance of A is less than the settlement balance shortage amount (A350).
  • the control unit 21 of the terminal A executes the steps A210 to A230. Therefore, in this case, when the control unit 11 of the server 10 executes the step of S270a, the control unit 11 of the server 10 executes the steps of S190 to S210.
  • control unit 21 of the terminal A may or may not return to the A140 to execute the process. ..
  • the terminal 20 has the planned settlement amount (an example of the amount of the first settlement, not the limitation), the common wallet balance (an example of the balance of the common account, not the limitation), and the user of the own terminal 20.
  • the payment balance shortage information (not the limitation, the amount of the first settlement, the balance of the common account, and the common account based on the second account)
  • An example of the second information regarding the insufficient balance is displayed on the display unit 24.
  • the terminal 20 charges the electronic money account of the user account of the user of the own terminal 20 based on the input to the display unit 24 on which the payment balance shortage information is displayed by the user of the own terminal 20 (limited).
  • It shows a configuration in which the control unit 21 executes an example of a process of sending money to a second account.
  • the control unit 21 executes an example of a process of sending money to a second account.
  • it is possible to notify the user of the terminal that the balance of the common account is insufficient.
  • remittance can be made to the second account based on the input by the user of the terminal.
  • the terminal 20 has the planned settlement amount (an example of the amount of the first settlement, not the limitation), the common wallet balance (an example of the balance of the common account, not the limitation), and the own terminal 20.
  • the payment balance shortage information (not limited, based on the balance of the common account and the balance of the second account), the common account and the second account
  • An example of the first information regarding the insufficient balance of the above) is displayed on the display unit 24.
  • the terminal 20 charges the electronic money account of the user account of the user of the own terminal 20 based on the input to the display unit 24 on which the payment balance shortage information is displayed by the user of the own terminal 20 (limited).
  • It shows a configuration in which the control unit 21 executes an example of a process of sending money to a second account.
  • the control unit 21 executes an example of a process of sending money to a second account.
  • it is possible to notify the user of the terminal that the balance between the common account and the second account is insufficient.
  • remittance can be made to the second account based on the input of the first information by the user of the terminal.
  • ⁇ Fourth modification (7)> it is selected whether or not to transfer money from the electronic money account of the user (user AA as an example, not limited) of the terminal (terminal A as an example, not limited) that executes the payment process to the common wallet.
  • the electronic money account of the remittance source is not limited to this.
  • remittance may be performed from the electronic money account of another member (user BB as an example, not the limitation) constituting the common wallet.
  • FIG. 4-19 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the latter half of the process is not limited and can be the same as that shown in FIG. 4-5 as an example, and thus the description thereof will be omitted here.
  • the control unit 21 of the terminal A requests remittance from the electronic money account of another user who is a common wallet member (user BB as an example, not limited) to the common wallet as an example, not limited.
  • a button having a function of selecting whether or not to use is displayed in addition to the display unit 24.
  • the control unit 21 of the terminal A requests remittance from the electronic money account of another user (user BB as an example, not limited) to the common wallet based on the user operation on the input / output unit 23 of the terminal A. It is determined whether or not is selected (A360).
  • the control unit 21 of terminal A requests remittance and, for example, the amount of insufficient settlement balance, not limited to it.
  • the remittance request information including the remittance request amount of the same amount is transmitted to the server 10 by the communication I / F22 (A370).
  • control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22, and FIG. Perform step 5 of A180.
  • the control unit 11 of the server 10 transmits the remittance confirmation information including the remittance request amount to the terminal B by the communication I / F14 (S340: YES). S350).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F14, and executes the step S170a in FIG. 4-5. ..
  • the control unit 21 of the terminal B determines the remittance confirmation information by the user B.
  • a screen for selecting whether or not to authorize remittance from the electronic money account of B to the common wallet is displayed on the display unit 24 (B150).
  • the control unit 21 of the terminal B ends the process.
  • the control unit 21 of the terminal B When it is selected to authorize the remittance to the common wallet based on the user operation on the input / output unit 23 of the terminal B (B150: YES), the control unit 21 of the terminal B transmits the remittance request information to the communication I / It is transmitted to the server 10 by F22 (B160). On the other hand, when it is selected not to approve the remittance to the common wallet (B150: NO), the control unit 21 of the terminal B ends the process.
  • the control unit 11 of the server 10 uses the user B.
  • the remittance process of transferring the remittance request amount from the electronic money account of B to the common wallet is executed (S370).
  • the control unit 11 of the server 10 is not limited, but as an example, the success or failure of the remittance process and the user B.
  • the remittance request result information including the balance of the electronic money account of B is transmitted to the terminal B by the communication I / F14 (S380).
  • the control unit 21 of the server 10 transmits the common wallet information including the common wallet balance after the remittance to the terminal A by the communication I / F 14 (S390).
  • the control unit 11 of the server 10 transmits the common wallet information including the common wallet balance to the terminal A by the communication I / F 14 (S390).
  • the information indicating that the remittance request has been refused by the terminal B may or may not be incorporated into the common wallet information and transmitted.
  • control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F 14, and executes the step of S170a.
  • the control unit 21 of the terminal B displays the remittance request result information on the display unit 24 (B170), and ends the process.
  • the control unit 21 of the terminal A updates and displays the common wallet balance on the display unit 24 as an example, not limited, based on the received common wallet information. Let (A380).
  • the display unit 24 may display a pop-up display or the like to that effect as an example, not limited to the information. You don't have to do that.
  • control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F 22, and executes the step of A180.
  • the control unit 21 of the terminal 20 is not limited, but as an example, the user of the own terminal 20 (user AA as an example, not limited) uses the user of the terminal 20 and other users.
  • Electronic money of another user (user BB as an example, not limited) based on the selection of a talk room (an example of a chat room, not limited) that includes at least (user BB as an example, not limited). You may or may not choose to request a transfer from your device to a common wallet.
  • a screen similar to the member selection screen (talk room selection screen) in the messaging application described with reference to FIG. 3-21 is displayed on the display unit 24 of the terminal 20 to request remittance. You can let the user select a room.
  • This modification shows a configuration in which the second account is a user account of a user (not limited, but an example of the first user) different from the user of the own terminal 20.
  • the second account is a user account of a user (not limited, but an example of the first user) different from the user of the own terminal 20.
  • payment can be realized based on at least an account of a first user different from the user of the terminal.
  • a user account (not limited, but an example of a second account) of a user different from the user of the own terminal 20 is selected based on the input to the own terminal 20 by the user of the own terminal 20. It shows the configuration to be done. As an example of the effect obtained by such a configuration, the second account can be easily selected based on the input to the terminal by the user of the terminal.
  • the user account of a user different from the user of the own terminal 20 (not limited, but an example of the second account) is the user of the own terminal 20 and another user of the own terminal 20. It shows a configuration that is selected based on the selection of a chat room that includes a user (not a limitation, but an example of a first user). As an example of the effect obtained by such a configuration, the second account can be easily selected based on the selection of the chat room including the terminal user and the first user.
  • the terminal 20 transmits the remittance request information (not limited, but an example of the information regarding the request for permission of payment based on the second account) to the terminal 20 different from the own terminal 20 by the communication I / F22.
  • the processing related to the payment is to allow a user different from the user of the terminal 20 (an example of the first user, not the limitation) to make a payment by the user's account (an example of the second account, not the limitation).
  • the payment can be disabled.
  • FIG. 4-20 to 4-21 are flowcharts showing an example of the flow of processing executed by each device in this modification. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the first half of the process is not limited and can be the same as that shown in FIG. 4-19 as an example, and thus the description thereof will be omitted here.
  • control unit 21 of the terminal A displays the payment result information (A180)
  • the control unit 21 causes the display unit 24 to display a screen for selecting whether or not to settle the replacement amount (A320).
  • the control unit 21 of the terminal A transmits the insufficient payment balance stored in the storage unit 28 of the terminal A to the server 10 by the communication I / F 22. (A330), transfer processing to A400.
  • the control unit 21 of the terminal A ends the process.
  • the control unit 11 of the server 10 sets the payment balance shortage amount to the replacement terminal 20 (here, terminal B). ) (S400).
  • the control unit 21 of the terminal B uses the user B. of the terminal B.
  • the display unit 24 displays a screen for selecting whether or not to charge other members of the common wallet for the electronic money corresponding to the shortage of the settlement balance reimbursed by B (B190).
  • the control unit 21 of the terminal B ends the process.
  • the control unit 21 of the terminal B transmits the settlement request information to the server 10 by the communication I / F 22. (B200).
  • control unit 21 of the terminal B skips the B200 and proceeds with the process.
  • the control unit 11 of the server 10 executes the steps S420 to S450. Since these steps can be executed in the same manner as in S290 to S320 of FIG. 4-9 with the transmission destination / receiver as the terminal A, the details thereof will be omitted.
  • the settlement request information is not received (S410: NO)
  • the control unit 11 of the server 10 shifts the process to the step of S460.
  • control unit 21 of the terminal A When the control unit 21 of the terminal A receives the payment advance billing information from the server 10 by the communication I / F 22 (A400: YES), the control unit 21 executes the steps A410 to A440. Since these steps can be executed in the same manner as the steps B110 to B130 of FIG. 4-9, the details thereof will be omitted.
  • the control unit 21 of the terminal A receives the settlement result information from the server 10 by the communication I / F22 and executes the step of A340.
  • the control unit 11 of the server 10 transmits the settlement result information including the remittance result to the user B.
  • Terminal B of B and user A It is transmitted to the terminal A of A (S460), and the process is terminated.
  • the control unit 21 of the terminal B displays the settlement result information on the display unit 24 (B210), and ends the process. The same applies to the terminal A (A340).
  • the terminal B repays the electronic money for the insufficient payment balance from the user account of the user (user BB) of the terminal 20 itself, but the present invention is not limited to this.
  • terminal B is a common wallet member and user A. A and user B.
  • the payment may be made by using (consuming) the electronic money corresponding to the shortage of the payment balance from the user account of the user other than B (not limited, but as an example, the user CC of the terminal C).
  • user B. B is a user C.I. You should get permission from C.
  • the control unit 21 of the terminal B is not limited to, but as an example, displays the information indicating that the advance payment has been requested on the display unit 24 of the terminal B. Can be done.
  • control unit 21 of the terminal A may display the information indicating that the advance payment has been requested on the display unit 24 of the terminal A. it can.
  • these information may be displayed on the application screen of the payment application, but instead, it can be displayed on the talk room screen of the messaging application described above.
  • This is not limited, but can be similarly configured by following the screens shown in FIGS. 4-16 and 4-17 as an example.
  • the second terminal 20 uses the server 10 for payment advance billing information (not limited, but an example of billing information regarding billing of the amount based on payment by the second account). It is received by the communication I / F 22 from the first terminal 20 (terminal 20 of the billing source) via the communication I / F22. Then, the second terminal 20 shows a configuration for displaying the display based on the received payment advance payment billing information (not limited, but an example of the first display and the third display based on the billing information) on the display unit 24. There is. As an example of the effect obtained by such a configuration, it is possible to notify the user of the terminal that the amount of money has been charged based on the payment by the second account and the content thereof.
  • the payment advance amount billing information (not limited, but an example of billing information regarding the billing of the amount based on the payment by the second account) is transmitted to the second terminal 20 via the server 10. It is transmitted to the terminal 20 by the communication I / F22. Then, the first terminal 20 shows a configuration in which a display based on the transmitted payment advance payment billing information (not a limitation, but an example of a second display based on the billing information) is displayed on the display unit 24. As an example of the effect obtained by such a configuration, after billing the amount based on the payment by the second account, the information regarding the billing can be notified to the user of the terminal.
  • the second terminal 20 is a common account that can be settled by at least the user of the second terminal 20 and the user of the first terminal 20 (not limited, but an example of the first user).
  • Processing related to payment by the first terminal 20 (not limited, but an example of the first terminal) based on the user account of the user of the first terminal 20 (not limited, but an example of the first account) An example of processing related to the first settlement) is executed, and based on the settlement by the user of the first terminal 20 (an example of the first settlement, not the limitation), the payment advance amount billing information (the first settlement, not the limitation). (Example of billing information regarding billing of the amount based on the above) is received from the first terminal 20 via the server 10 by the communication I / F 22.
  • the second terminal 20 shows a configuration in which a display based on the received payment advance payment billing information (not limited, but an example of the first display based on the billing information) is displayed on the display unit 24.
  • a display based on the received payment advance payment billing information (not limited, but an example of the first display based on the billing information) is displayed on the display unit 24.
  • the first Based on the fact that the process related to the first payment is executed by the user's first terminal, it is possible to receive a charge for the amount based on the first payment and notify the user of the terminal of the information regarding the charge.
  • this modification shows a configuration in which the first account is a user account of the user of the first terminal 20 (not limited, but an example of the first user).
  • the first account is a user account of the user of the first terminal 20 (not limited, but an example of the first user).
  • the first account is a user account of the user of the first terminal 20 (not limited, but an example of the first user).
  • at least a common account that can be settled by a terminal user and a first user different from the terminal user, and a first user's account based on the first user's account.
  • the process related to the first settlement can be executed by one terminal.
  • the payment advance amount billing information is determined based on the amount of money reimbursed by the user account of the user of the first terminal 20 (not limited, but an example of the amount paid by the first account). .. Then, the second terminal 20 performs a remittance process (not limited, but an example of a process related to remittance of an amount based on billing information) from the user account of the user of the own terminal 20 to the user account of the user of the first terminal 20.
  • the configuration executed by the control unit 21 is shown. As an example of the effect obtained by such a configuration, an amount based on billing information determined based on the amount paid by the first account can be remitted from the terminal user's account to the first account.
  • this modification shows a configuration in which the payment advance amount billing information is determined based on a common wallet member (not limited, but an example of a user who can settle by a common account).
  • a common wallet member not limited, but an example of a user who can settle by a common account.
  • the terminal 20 sends payment advance billing information to a talk room (an example of a chat room, not a limitation) in which a terminal 20 can send and receive messages and the like (an example of content, not a limitation) with a common wallet member. Shows the configuration to be displayed. As an example of the effect obtained by such a configuration, it is possible to inform the user of the terminal of billing information in an easy-to-understand form of displaying in a chat room where payment can be made by a common account and contents can be sent and received.
  • the remittance process based on the payment advance payment request information is performed based on the operation (not the limitation, but an example of the user's input to the remittance information) for the remittance button or the like (not the limitation, but an example of the remittance information).
  • remittance can be easily realized based on the input of the user for the remittance information for performing the remittance based on the billing information.
  • the display based on the payment advance payment billing information shows a configuration including the information of the user of the first terminal 20.
  • the information of the user of the first account can be notified to the user of the terminal.
  • the processing related to the payment (the processing related to the second payment, not the limitation). An example) is executed. Then, the second terminal 20 is a payment by the user of the first terminal 20 (an example of a first payment, not a limitation) and a payment by a user of the second terminal 20 (an example of a second payment, not a limitation). ) And the payment advance amount billing information is received from the first terminal 20 by the communication I / F 22 via the server 10.
  • the second terminal 20 performs a remittance process (not limited, but an example of a process related to remittance of an amount based on billing information) from the user account of the user of the own terminal 20 to the user account of the user of the first terminal 20.
  • the configuration executed by the control unit 21 is shown.
  • the process related to the second settlement is executed based on the common account and the second account different from the common account, and the billing based on the first settlement and the second settlement is received. Then, money can be sent from the user's account of the terminal to the first account.
  • the payment advance amount billing information (not limited, but an example of billing information related to billing of the amount based on the first settlement) is the server 10 (not limited, but the server that executes the process related to the first settlement).
  • An example shows the configuration transmitted from.
  • billing information can be easily obtained from a server that executes a process related to the first settlement.
  • the first account is a user account (not limited, but not limited) of a user different from the user of the second terminal 20 (not limited, but an example of the first user), which can be settled by a common account.
  • An example of a user different from one user) is shown as a user account.
  • the amount of money based on the first payment is charged, and the information related to the billing is notified to the user of the terminal. Can be done.
  • the server 10 has at least a user of the second terminal 20 (an example of a user of the terminal, not a limitation) and a user of the first terminal 20 (an example of a first user, not a limitation).
  • the payment processing an example of the processing related to the first settlement, not the limitation
  • the server 10 secondly charges the payment advance amount billing information (an example of the billing information regarding the billing of the amount based on the first settlement, not the limitation).
  • the configuration of transmitting to the terminal 20 of the above by communication I / F14 is shown.
  • the first It is possible to realize the settlement by executing the processing related to the settlement.
  • the amount based on the first settlement can be charged to the terminal user.
  • ⁇ Fourth modification (9)> payment is realized based on the payment code displayed on the display unit 24 of the terminal 20 being read by the store code reader device 50, or based on the payment store code being read by the terminal 20. .. That is, in the above embodiment, the method of performing the code payment is shown, but the method is not limited to this. Instead of code payment, payment can be made by wireless communication (including short-range wireless communication).
  • FIG. 4-22 is a diagram showing a configuration example of the store code reader device 50 in this modified example.
  • the store code reader device 50 includes a short-range wireless communication I / F 581 as an example but not a limitation.
  • the short-range wireless communication I / F 581 is an interface for performing short-range wireless communication with the terminal 20.
  • the short-range wireless communication is not limited, but as an example, so-called non-contact type short-range communication (hereinafter referred to as “contactless communication”) and short-range communication using Bluetooth (hereinafter, “" It is called “Bluetooth communication”) and the like.
  • the short-range wireless communication I / F 581 is not limited, but as an example, a card reader for reading information stored in a non-contact IC card such as an NFC chip provided in the terminal 20. Or, a card reader / writer for reading / writing information can be included. In this case, instead of the code payment (user presentation type or store presentation type) in the above embodiment, the user of the terminal 20 holds his / her terminal 20 over the card reader or card reader / writer of the store. The settlement can be made in the same manner as in the embodiment.
  • the control unit 11 of the server 10 is not limited, but as an example, the common wallet balance is insufficient.
  • Information indicating the presence is transmitted to the terminal 20 by the communication I / F14.
  • the control unit 21 of the terminal 20 causes the display unit 24 to display the payment balance shortage information.
  • the account for making the payment is changed from the common account to the user account (second account) of the user of the own terminal 20. Change / set to. Then, the user of the terminal 20 can make a payment by holding his / her terminal 20 over the card reader of the store again.
  • the card reader provides information indicating that the common wallet balance is insufficient, not as a limitation but as an example.
  • the writer may or may not write to the contactless IC card of the terminal 20.
  • the control unit 21 of the terminal 20 displays the payment balance shortage information on the display unit 24, and based on the input of the user of the terminal 20 for the displayed payment balance shortage information, the control unit 21 is not limited, but as an example.
  • the account for making payment may or may not be changed / set from the common account to the user account (second account) of the user of the own terminal 20. Then, the user of the terminal 20 may or may not be able to make a payment by holding his / her terminal 20 over the card reader of the store again.
  • the short-range wireless communication I / F 581 includes a module for Bluetooth communication for performing Bluetooth communication with the terminal 20 and the like. Also in this case, by replacing the non-contact communication with the Bluetooth communication, the payment can be made by the same method as described above.
  • the processing related to payment is the store code reader device 50 (not limited, but an example of the communication unit of the terminal) by the communication I / F22 (not limited, selling or service of the product purchased by the first payment). It shows a configuration executed by wireless communication with an example of a terminal of a store that provides. As an example of the effect obtained by such a configuration, payment can be easily realized by wireless communication with the terminal of the store that sells the product purchased by the first payment or provides the service by the communication unit of the terminal. can do.
  • this modification shows a configuration in which the above wireless communication is a non-contact communication or a Bluetooth communication (not limited, but an example of short-range communication).
  • wireless communication with a terminal of a store that sells a product or provides a service purchased by the first settlement can be realized by short-range communication.
  • the terminal 20 uses the payment application to execute payment at the member store from the common wallet balance, or the common wallet balance and the user of the terminal 20 (limited). Instead, as an example, it is an example of executing from the electronic money balance of the temporary payment account (hereinafter, referred to as "integrated account") that adds up the electronic money account balance of the user AA).
  • integrated account the electronic money balance of the temporary payment account
  • FIG. 5-1 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
  • an integrated account management database 159 is provided as an example, not limited to the above. Be remembered.
  • the integrated account management database 159 is a database for the server 10 to manage the integrated account, and an example of its data structure is shown in FIG. 5-2.
  • the integrated account management database 159 stores integrated account management data as management data for each integrated account.
  • Each integrated account management data includes, as an example, not limited to, an integrated account ID which is an example of identification information for identifying the integrated account, and an integrated account member ID indicating a user's account included in the integrated account. Is remembered.
  • the integrated account member ID stores the account of the payment application integrated in the integrated account (including the user's payment application ID, common wallet ID, and the like).
  • the integrated account identified by "UN0001” is composed of "U0001” (ie, User AA) and "S0001” (ie, the common wallet “camping funds”). It has been shown to be done.
  • FIG. 5-3 the icon indicated as “code payment” on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen (before integration) displayed when the touch operation is performed by A.
  • the screen of FIG. 5-3 is almost the same as the screen of FIG. 3-4, but a part of the display in the camp fund code payment area 2421 is different.
  • camp fund code payment area 2421 in Fig. 3-4 the characters “Transfer from your wallet” are displayed together with the check mark button CN2, and the balance ("25,000 yen” in this example) is displayed next to it.
  • the integration is executed with the words "Integrate with your wallet” as information for integrating the common wallet of camp funds with your own wallet.
  • the characters "my wallet” are newly displayed below it, and my electronic money account balance ("25,000 yen” in this example) is displayed next to it.
  • the slide button CN7 is an image with an oval and a circle inside this oval, and the default state is that the circle is located at the left end of the oval (“OFF” in this example), and it is not limited. As an example, by touching or sliding the circle, the circle is positioned at the right end of the oval (“ON” in this example), and the color inside the oval is highlighted.
  • FIG. 5-4 is a diagram showing an example of a code information updating screen displayed when the slide button CN7 is operated on the code payment screen (before integration) of FIG. 5-3.
  • the difference between FIG. 5-4 and FIG. 5-3 is that the slide button CN7 in the camp fund code payment area 2421 is in the “ON” state, and the code information is being updated in the camp fund code payment area 2421.
  • the updating information CJK indicating that there is is superimposed and displayed.
  • two rotating arrows indicating that the code information is being updated are displayed in the center, and the characters "Code information is being updated " are displayed below the two rotating arrows.
  • FIG. 5-5 is a diagram showing an example of a code payment screen (after integration) displayed when the payment code information updating screen of FIG. 5-4 is updated. That is, in the upper part of the camp fund code payment area 2421, the image of the wallet and the name of the common wallet (camp fund), the "+” indicating the addition, and the image of the wallet and the characters of the wallet are displayed. At the same time, the integrated balance (“26,000 yen” in this example), which is the sum of the common wallet (camping fund) and your own wallet, is displayed.
  • the payment code displayed in the camp fund code payment area 2421 in Fig. 5-5 is different from the payment code in Fig. 5-3 due to the integration of accounts.
  • Terminal 20 user A presents the above code payment screen to the store clerk at the code cash register and has the store code reader read the payment code to make the code payment.
  • the same code payment completion screen as in FIG. 3-7 is displayed.
  • ⁇ Processing> 5-6 to 5-7 are flowcharts showing an example of the flow of processing executed by each device in the embodiment. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown. This process is an example of a process related to user-presented code payment.
  • the control unit 21 of the terminal A is not limited, but as an example, the user A. of the terminal A.
  • the electronic money account balance of A is displayed in addition to the display unit 24 (A130), the user A.
  • a button having a function of selecting whether or not to execute payment by the integrated account that totals the electronic money account balance of A and the common wallet balance is displayed in addition to the display unit 24 (A450a).
  • the control unit 21 of the terminal A When it is selected to execute payment by the integrated account based on the user operation to the input / output unit 23 of the terminal A (A450a: YES), the control unit 21 of the terminal A communicates the account integration request information with the communication I / F 22. To the server 10 (A460). When it is not selected to execute payment by the integrated account (A450a: NO), the control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22, and steps A180 in FIG. 1-9. Execute.
  • the control unit 11 of the server 10 executes the account integration process (S480).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 and executes the step S170a of FIG. 1-9.
  • control unit 11 of the server 10 adds a record of integrated account management data having a unique integrated account ID to the integrated account management database 159, and the user A.
  • the payment application ID of A and the common wallet ID of the common wallet are stored.
  • the control unit 11 of the server 10 generates a payment token that authorizes payment from the balance of the integrated account associated with the integrated account ID.
  • this token will be referred to as an "integrated account payment token".
  • the balance of the integrated account is the total amount of the balance of the electronic money associated with the payment application ID and the common wallet ID stored in the integrated account member ID.
  • the integrated account payment token like the common wallet payment token, is identified by an integer value of a predetermined number of digits (12 digits as an example, not a limitation) as an example, not a limitation.
  • the integrated account payment token may or may not be a token with an expiration date.
  • the control unit 11 of the server 10 When the integrated account payment token is generated by the account integration process, the control unit 11 of the server 10 generates the integrated account code information which is the code information including the integrated account payment token.
  • the integrated account code information includes, as an example, not limited to, a payment code (image information) in which the identifier of the integrated account payment token is encoded as a one-dimensional code (bar code) or a two-dimensional code (QR code). If the integrated account payment token has an expiration date, the integrated account code information may include the expiration date.
  • control unit 11 of the server 10 transmits the integrated account code information to the terminal A by the communication I / F 14 (S490a).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F14.
  • the step S170a of FIG. 1-9 is executed.
  • the control unit 21 of the terminal A updates and displays the payment code on the display unit 24 based on the received integrated account code information (A470a). If the integrated account code information includes the identifier and expiration date of the integrated account payment token, the control unit 21 of the terminal A may update and display the identifier and expiration date.
  • the control unit 51 of the store code reader device 50 uses the code reader 58 to read the payment code displayed on the display unit 24 of the terminal A (P140). In this case, since the payment code displayed on the display unit 24 is associated with the integrated account payment token, the reading result of the code reader 58 includes the integrated account payment token as the payment token.
  • the control unit 51 of the store code reader device 50 uses the communication I / F 54 to transmit payment request information including the store ID, the planned payment amount, and the payment token (in this case, the integrated account payment token), as an example but not limited. It is transmitted to the server 10 (P150).
  • the control unit 11 of the server 10 executes the integrated account payment process (S500a).
  • the control unit 11 of the server 10 searches for the integrated account ID from the requested integrated account payment token.
  • the control unit 11 of the server 10 further points to the integrated account member ID based on the integrated account member ID (here, the payment application ID of the user AA and the common wallet ID of the common wallet) associated with the integrated account ID.
  • the indicated user A Using the total amount of the electronic money account balance and the common wallet balance of A, a payment process for paying the planned settlement amount with the member store defined by the store ID is executed for the integrated account.
  • the control unit 11 of the server 10 reduces the common wallet balance by the planned settlement amount. If the common wallet balance is less than the planned settlement amount, the common wallet balance is reduced to "0" and the shortfall is reduced to the user A. Deduct from A's electronic money account balance.
  • the control unit 11 of the server 10 may use the user A. Decrease the balance of A's electronic money account by the amount to be settled, and if user A. If the balance of A's electronic money account is less than the planned settlement amount, user A. A's electronic money account balance may or may not be reduced to "0" and the shortfall may or may not be deducted from the common wallet balance.
  • control unit 11 of the server 10 transmits the payment result information including the success / failure of the payment processing and the integrated account balance after the payment processing to the store code reader device 50 by the communication I / F 14, as an example but not limited. (S510).
  • control unit 11 of the server 10 is not limited, but as an example, the success or failure of the payment processing, the balance of the electronic money account / common wallet constituting the integrated account after the payment processing, and the payment amount in the electronic money account / common wallet.
  • the integrated account payment result information including the above is transmitted to the terminal A by the communication I / F14 (S520), and the process is terminated.
  • the control unit 51 of the store code reader device 50 displays the payment result information on the display unit 53 (P160), and ends the process.
  • the control unit 21 of the terminal A displays the integrated account settlement result information on the display unit 24 (A480), and ends the process.
  • the integrated account payment token is, by example, a payment token that authorizes payment from the balance of the integrated account associated with (linked to) the integrated account ID. That is, the integrated account payment token is associated with the integrated account ID.
  • the code information in which this integrated account payment token is encoded is the integrated account code information.
  • the integrated account ID is associated with the payment application ID to be integrated and the common wallet ID of the common wallet as an example, not limited to, as the integrated account member ID.
  • the integrated account code information (an example of the first code information, not the limitation) includes the payment application ID to be integrated (an example of the information about the second account, not the limitation) and the common wallet ID (the limitation). It can be said that it contains or is associated with (an example of information about a common account).
  • the terminal 20 executes a process related to payment based on the common wallet balance.
  • the common wallet balance shows a configuration in which remittance is possible from the user account of the user of the own terminal 20. With such a configuration, the same effects as those of the third embodiment and the fourth embodiment can be obtained as an example, not the limitation.
  • the terminal 20 uses the user account information and the common account based on the input to the user account information (not limited, but an example of the second account information) of the user of the terminal 20.
  • the associated integrated account code information (not limited, but an example of the first code information) is displayed on the display unit 24.
  • the terminal 20 shows a configuration for executing a process related to payment based on the integrated account code information being read.
  • the first code information associated with the second account and the common account is displayed in the display area of the terminal based on the input for the second account information and used for payment. Can be made to. Further, the settlement can be easily realized based on the reading of the first code information.
  • the terminal 20 has the common wallet code information (not limited, but an example of the first code information) associated with the common account, and the user account information of the user of the own terminal 20 (not limited).
  • An example of the second account information is displayed on the display unit 24.
  • the terminal 20 is an example of the integrated account code information (not limited, but the second code information) in which the user account information and the common account are associated with each other based on the input to the user account information of the user of the terminal 20. ) Is displayed on the display unit 24.
  • the first code information associated with the common account can be displayed in the display area of the terminal and used for payment
  • the second account information is recognized by the user of the terminal. Can be made to.
  • the second code information associated with the second account and the common account can be displayed in the display area of the terminal and used for payment.
  • the common wallet code information (an example of the first code information, not the limitation) and the integrated account code information (an example of the second code information, not the limitation) are combined with the server 10 (not the limitation, but an example of the second code information). It shows a configuration in which information is transmitted from (an example of a server) that executes a process related to the first settlement to the terminal 20. As an example of the effect obtained by such a configuration, the first code information and the second code information can be easily obtained from the outside.
  • the terminal 20 uses the information of the common wallet balance (not limited, but an example of the amount of the first electronic money associated with the common account) and the electronic money account balance of the user account (not limited).
  • the information of the balance of the integrated account to which the amount of the second electronic money associated with the second account) is added, and the integrated account code information (not limited, but an example of the second code information) are displayed on the display unit 24. Shows the configuration to be displayed. As an example of the effect obtained by such a configuration, the terminal user is notified of the amount of the first electronic money associated with the common account and the amount of the second electronic money associated with the second account. it can. Further, the second code information can be displayed in the display area of the terminal and used for payment.
  • the control unit 21 of the terminal A updates the integrated account code information on the display unit 24 to display it, but the payment code does not have to be updated. ..
  • the control unit 11 of the server 10 deletes (invalidates) the common wallet payment token generated in S100a of FIG. 5-6 in S480 of FIG. 5-6. Then, an integrated account payment token having the same identifier as the common wallet payment token generated in S100a of FIG. 5-6 may be generated.
  • the user-presented code payment has been described, but the present invention is not limited to this. Specifically, it may be a store presentation type code payment.
  • FIG. 5-8 on the camp fund payment screen of FIG. 3-3, the icon of the "code reader” is the user A. of the terminal 20. It is a figure which shows an example of the code reader screen (before integration) which is displayed when touch operation is performed by A.
  • "Camp Fund” which is a submenu currently being executed, is displayed as the current position in the hierarchical menu of "Payment App”.
  • the code reading area CR1 is displayed under the "camp fund”
  • the "code reader” is displayed as an operation guide for the user
  • the camp fund code payment area 2423 is displayed below the code reader.
  • camp fund code payment area 2423 As in Fig. 3-4, along with the image of the square wallet and the name of the common wallet (camp fund), the common wallet balance of this camp fund ("1,000 yen” in this example. ") Is displayed. Below that, the words “Integrate with my wallet” are displayed, and a slide button CN7 is placed next to it. In addition, the characters “my wallet” are displayed below it, and the balance ("25,000 yen” in this example) is displayed next to it.
  • FIG. 5-9 is a diagram showing an example of a payment code information updating screen displayed when the slide button CN7 is touch-operated on the code reader screen (before integration) of FIG. 5-8.
  • the slide button CN7 is touch-operated and is in the “ON” state (the circle is moved to the right end in the oval and is highlighted).
  • the updating information CJK is displayed in a pop-up format.
  • FIG. 5-10 is a diagram showing an example of a code reader screen (after integration) displayed when the payment code information updating screen of FIG. 5-9 is updated.
  • the updating information CJK displayed in the pop-up format on the screen of FIG. 5-9 is deleted when the account integration (update of code information) is completed.
  • an image of a square wallet and characters of the camp fund an image of a purse and your wallet The information that is combined with the character of "+” is displayed.
  • the balance (“26,000 yen” in this example) added up by the wallet integration is displayed in association with this information.
  • ⁇ Processing> 5-11 to 5-12 are flowcharts showing an example of the flow of processing executed by each device in this modification.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • control unit 21 of the terminal A displays the user account information on the display unit 24 (A130), the user A.
  • a button having a function of selecting whether or not to execute payment by the integrated account that totals the electronic money account balance of A and the common wallet balance is displayed in addition to the display unit 24 (A450b).
  • the control unit 21 of the terminal A executes the step of A460. If it is not selected to perform the payment by the integrated account (A450b: NO), the control unit 21 of the terminal A executes the step A190 of FIG. 1-11.
  • the control unit 11 of the server 10 executes the account integration process (S480).
  • the control unit 11 of the server 10 receives the payment request information from the terminal A and executes the step S170b of FIG. 1-11.
  • control unit 11 of the server 10 executes the step of S480, the control unit 11 generates the integrated account code reader information which is the code reading information including the generated integrated account payment token. Then, the control unit 11 of the server 10 transmits the integrated account code reader information to the terminal A by the communication I / F 14 (S490b).
  • the control unit 21 of the terminal A displays a code reader screen for reading the payment store code based on the received integrated account code reader information. Display on 24 and activate camera 27 to read the code (A470b). Then, the control unit 21 of the terminal A executes the step of A190.
  • the control unit 11 of the server 10 executes the integrated account store presentation type payment process (S500b). Since the integrated account store presentation type payment process can be executed in the same manner as the integrated account payment process, detailed description thereof will be omitted. Then, the control unit 11 of the server 10 executes the step of S520 and ends the process.
  • the control unit 21 of the terminal A executes the step of A480 and ends the process.
  • the terminal 20 reads the payment store code based on the integrated account code reader information based on the input to the user account information (not limited, but an example of the second account information) of the user of the terminal 20.
  • a code reader screen for this purpose (not limited, but an example of first code reader information) is displayed on the display unit 24.
  • the terminal 20 shows a configuration in which the control unit 21 executes a process related to payment based on the code reader screen reading the payment store code by the terminal 20 displayed on the display unit 24.
  • the first code reader information can be displayed in the display area of the terminal and used for payment based on the input to the second account information.
  • payment can be easily realized based on reading the code information by the terminal in which the first code reader information is displayed in the display area.
  • the terminal 20 displays a code reader screen (not limited, but an example of the first code reader information) for reading the payment store code on the display unit 24. Then, the terminal 20 is a code for reading the payment store code based on the integrated account code reader information based on the input to the user account information (not limited, but an example of the second account information) of the user of the own terminal 20.
  • the reader screen (not limited, but an example of the second code reader information) is displayed on the display unit 24. Then, the terminal 20 shows a configuration in which the control unit 21 executes a process related to payment based on the code reader screen reading the payment store code by the terminal 20 displayed on the display unit 24.
  • the first code reader information can be displayed in the display area of the terminal and used for payment, and the second account information can be recognized by the user of the terminal. Further, based on the input for the second account information, the second code reader information can be displayed in the display area of the terminal and used for payment.
  • the terminal 20 uses the information of the common wallet balance (not limited, but an example of the amount of the first electronic money associated with the common account) and the electronic money account balance of the user account (not limited, but not limited).
  • a code reader screen (not limited) for reading the payment store code based on the balance information of the integrated account to which the amount of the second electronic money associated with the second account is added and the integrated account code reader information.
  • a configuration is shown in which the second code reader information (an example) is displayed on the display unit 24. As an example of the effect obtained by such a configuration, the terminal user is notified of the amount of the first electronic money associated with the common account and the amount of the second electronic money associated with the second account. it can. Further, the second code reader information can be displayed in the display area of the terminal and used for payment.
  • a plurality of accounts are associated with a single code in the account integration process, but it is not necessary to do so.
  • a plurality of payment codes may be displayed on the terminal and payment may be made using those codes.
  • the maximum amount that can be settled is the total amount of the electronic money account balances of the plurality of accounts linked to the plurality of codes.
  • account parallel use such a payment method will be referred to as "account parallel use”.
  • FIG. 5-13 is a diagram showing another example of the code payment screen.
  • two payment codes a one-dimensional payment code represented by a barcode and a one-dimensional payment code also represented by a barcode, are displayed side by side. Has been done.
  • the payment code above is not limited, but as an example, User A.
  • This is the first parallel code information in which a payment token (first parallel payment token described later) including a flag for approving payment from the electronic money account balance associated with the payment application ID of A and selecting account parallel use is stored.
  • the payment code below is not limited, but as an example, a payment token that authorizes payment from the common wallet balance associated with the common wallet ID and includes a flag that selects account parallel use (second parallel payment token described later). ) Is the second parallel code information stored.
  • first parallel code information and the second parallel code information can be freely set and changed.
  • first parallel code information and the second parallel code information may be a two-dimensional payment code represented by a QR code or the like, instead of being a one-dimensional payment code as described above.
  • ⁇ Processing> 5-14 to 5-15 are flowcharts showing an example of the flow of processing executed by each device in this modified example. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown.
  • a button having a function of selecting whether or not to execute payment by using the electronic money account of A and the account parallel use using the common wallet is displayed in addition to the display unit 24 (A490).
  • the control unit 21 of the terminal A communicates the account parallel use request information I. It is transmitted to the server 10 by / F22 (A500).
  • control unit 21 of the terminal A receives the payment result information from the server 10 by the communication I / F22, and steps A180 in FIG. 1-9. To execute.
  • the control unit 11 of the server 10 executes the account parallel use process (S540).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 and executes the step S170a of FIG. 1-9.
  • the control unit 11 of the server 10 first receives the user A. Approve payment from the electronic money account balance associated with A's payment application ID, and generate a payment token containing a flag to select parallel use of accounts. In the following, this payment token will be referred to as a "first parallel payment token”. Further, the control unit 11 of the server 10 approves payment from the common wallet balance associated with the common wallet ID, and generates a payment token including a flag for selecting account parallel use. In the following, this payment token will be referred to as a "second parallel payment token”.
  • the first parallel payment token and the second parallel payment token are identified by an integer value of a predetermined number of digits (12 digits as an example, not a limitation) as an example, not a limitation. These tokens may or may not have an expiration date.
  • the control unit 11 of the server 10 generates the first parallel code information which is the code information including the first parallel payment token and the second parallel code information which is the code information including the second parallel payment token.
  • the first parallel code information and the second parallel code information are not limited, but as an example, a payment code (image information) in which the identifier of each token is encoded as a one-dimensional code (bar code) or a two-dimensional code (QR code). including. If the first parallel payment token and the second parallel payment token have an expiration date, the code information may include the expiration date.
  • control unit 11 of the server 10 transmits the first parallel code information to the terminal A by the communication I / F 14 (S550)
  • control unit 11 transmits the second parallel code information to the terminal A by the communication I / F 14 (S560).
  • the control unit 21 of the terminal A displays the first parallel code information and the second parallel code information side by side on the display unit 24 ( A510).
  • the control unit 51 of the store code reader device 50 uses the code reader 58 to read one payment code displayed on the display unit 24 of the terminal A (P140).
  • the control unit 51 of the store code reader device 50 includes, for example, a store ID, a planned payment amount, and a payment token (in this case, a first parallel payment token or a second parallel payment token).
  • the payment request information is transmitted to the server 10 by the communication I / F 54 (P150).
  • the control unit 11 of the server 10 detects a flag for selecting account parallel use from the received first parallel payment token or second parallel payment token. .. Then, the control unit 11 of the server 10 transmits the other code read request information to the store code reader device 50 by the communication I / F 14 in order to request the other payment token generated by the account parallel use process ( S570).
  • the control unit 51 of the store code reader device 50 causes the display unit 53 to display a screen prompting to read the other payment code (P170).
  • the control unit 51 of the store code reader device 50 uses the code reader 58 to read the other payment code displayed on the display unit 24 of the terminal A (P180). Then, the control unit 51 of the store code reader device 50 is not limited, but as an example, the store ID, the scheduled payment amount, and the payment token (in this case, P150 of the first parallel payment token or the second parallel payment token).
  • the second payment request information including the not transmitted token is transmitted to the server 10 by the communication I / F 54 (P190).
  • the control unit 11 of the server 10 executes the account parallel payment process (S580).
  • the account parallel payment process is performed by the user A.
  • control unit 11 of the server 10 executes the steps of S590 and S600, and ends the process. Further, when the account parallel payment result information is received from the server 10 by the communication I / F 22, the control unit 21 of the terminal A executes the step of A520 and ends the process.
  • each step of S590, S600, and A520 can be executed in the same manner as each step of S510, S520, and A480 by regarding the payment by the integrated account as in the account parallel payment process. The description of is omitted.
  • the common wallet balance is not enough, and even if the balance of the user's electronic money account is used for reimbursement, the reimbursed amount is used by other users of the common wallet (as an example, not limited). Although the user BB) was not charged, it may or may not be charged.
  • FIG. 5-16 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the first half of the process is not limited and can be realized by the same process as in FIGS. 5-6 and 5-7 as an example, and thus the description thereof will be omitted here.
  • the control unit 21 of the terminal A executes the step of A480, the control unit 21 causes the display unit 24 to display a screen for selecting whether or not to settle the replacement amount (A530).
  • the user A If the payment amount from A's electronic money account is "0" or the payment has failed, there is no need to make a payment (A530: NO), so the selection screen is displayed on the display unit 24. It may or may not end the process.
  • the selection screen is not displayed on the display unit 24 and the payment is automatically made (A530: YES). It may or may not be.
  • the control unit 21 of the terminal A uses the user A.
  • the user account payment amount billing information including the payment amount from the electronic money account of A is transmitted to the server 10 by the communication I / F22 (A540).
  • the control unit 21 of the terminal A executes the step of A340 and ends the process.
  • the control unit 11 of the server 10 transmits the integrated account payment result information (S520) and receives the user account payment amount billing information from the terminal A by the communication I / F 14 (S610: YES), the user account payment amount billing information is used. Included users A. The steps from S290 to S330 are executed with the payment amount from the electronic money account of A as the settlement balance shortage amount. If the user account payment amount billing information is not received (S610: NO), the control unit 11 of the server 10 ends the process.
  • control unit 21 of the terminal B When the control unit 21 of the terminal B receives the payment advance billing information from the server 10 by the communication I / F 22 (B100: YES), the control unit 21 executes the steps B110 to B130. When the payment advance payment billing information is not received (B100: NO), the control unit 21 of the terminal B ends the process.
  • the user A In the fifth embodiment, the user A.
  • the amount obtained by adding the balance of A's electronic money account and the balance of the common wallet was defined as the balance of the integrated account (the amount that can be paid by the integrated account), but it is not limited to this.
  • common wallet and user A Before integrating with A's electronic money account, user A. From an external financial institution account pre-registered by A, user A. You may charge (remittance) to A's electronic money account.
  • FIG. 5-17 the icon indicated as “code payment” on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen (before integration) displayed when the touch operation is performed by A.
  • the amount of the balance (“1000 yen” in this example) displayed next to “My wallet” in the camp fund code payment area 2421 is different, and The charge button CN5 is displayed next to it. When the charge button CN5 is touch-operated, charging is performed on the charge screen shown in FIG. 3-14.
  • FIG. 5-18 is a diagram showing an example of a code payment screen (after charging) displayed when charging is completed on the charging screen of FIG. 3-14.
  • the balance is "25,000 yen" due to the charging.
  • FIG. 5-19 shows an example of the code payment screen (after integration) displayed based on the fact that the slide button CN7 is touch-operated on the code payment screen (before integration) of FIG. 5-18 and the accounts are integrated. It is a figure.
  • the image of the square wallet, the name of the common wallet (camp fund), the "+” indicating the addition, the image of the purse and your wallet. Is displayed, and the balance after integration (“26,000 yen” in this example) based on the integration of the common account and one's own account is displayed.
  • the payment code displayed in the camp fund code payment area 2421 in FIG. 5-19 is different from the payment code in FIG. 5-18 due to the integration of the common account and one's own account. There is.
  • FIG. 5-20 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown.
  • control unit 21 of the terminal A executes the step of A130
  • the control unit 21 of the terminal A executes the steps of A210 to A230.
  • the control unit 21 of the terminal A executes the step of the A450a. Therefore, in this case, when the control unit 11 of the server 10 executes the step of S120, the control unit 11 of the server 10 executes the steps of S190 to S210. Next, the control unit 11 of the server 10 executes the step of A470a.
  • the common wallet and user A After integrating with A's electronic money account, user A. You may charge the electronic money account of A.
  • the control unit 21 of the terminal A executes the step of A470a
  • the steps of A210 to A230 may be executed, and when the integrated account payment result information is received from the server 10, the step of A480 may be executed.
  • the control unit 11 of the server 10 executes the step of S490a
  • the steps of S190 to S210 may be executed, and when the payment request information is received from the store code reader device 50, the process of S500a may be executed.
  • ⁇ Fifth modification (6)> it is selected whether or not to integrate the electronic money account of the user (user AA as an example, not limited) of the terminal (terminal A as an example, not limited) that executes the payment process and the common wallet.
  • the electronic money account to be integrated is not limited to this.
  • FIG. 5-21 the icon indicating "code payment” on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the code payment screen (before integration) which is displayed when touch operation is performed by A.
  • Fig. 5-21 unlike Fig. 5-3, the characters "Wallet integration" are displayed in the camp fund code payment area 2421, but as shown in Fig. 5-3, the display regarding the integration of one's wallet is displayed. Not done.
  • FIG. 5-22 is a diagram showing an example of a code payment screen (before member integration) displayed when the slide button CN7 is operated on the code payment screen (before integration) of FIG. 5-21.
  • the slide button CN7 in the camp fund code payment area 2421 in FIG. 5-18 is shown to be “ON”.
  • the wallet integration guidance area WT1 including the characters "wallet integration” is superimposed and displayed on the code payment screen as an operation guidance for the user.
  • the wallet integration member selection area WTM1 for selecting the user (member) to be integrated is superimposed and displayed on the wallet integration guidance area WT1.
  • the explanation "Which member's wallet do you want to integrate with?” Is displayed at the top, and below that, the account integration target is associated with the check mark button CN2. Candidates for users are displayed.
  • information about yourself (your icon image, "yourself” indicating yourself, your electronic money account balance ("25,000 yen” in this example) ”)) Is displayed.
  • user B Information about B (icon image of user BB, user name "user BB") is displayed.
  • FIG. 5-23 shows the user B.I.
  • the check mark button CN2 for selecting B is touch-operated, the user B. It is a figure which shows an example of the notice screen displayed on the display part 24 of the terminal 20 of B.
  • the title bar shows the user B.
  • the icon image of B and its user name "BB" are displayed. Further, below the title bar, the character “Notice” is displayed as the current position in the hierarchical menu of "Payment App".
  • camp fund notice display area 2429 below the notice day, there is a camp fund notice display area 2429.
  • camp fund notification display area 2429 as an example, not limited to, the name of the common wallet (“camp fund” in this example) is displayed along with an image of a square wallet indicating that it is a common wallet. ..
  • "April 11, 2020 16:18” is displayed as the date and time of the announcement, and below that, the user who jointly uses this common wallet (in this example, "User A.A.”” And the icon image of "User BB”) is displayed.
  • camp fund notification display area 2429 is not limited to the user A.
  • “Wallet integration request” is displayed as a request item from A, and the sentence "Wallet integration request has arrived from Mr. A.” is displayed below it.
  • the common wallet balance of this camp fund ("1,000" in this example).
  • “Circle" is displayed.
  • the balance of your wallet (“20,000 yen” in this example) is displayed along with the image of your wallet and the characters “your wallet” (user BB's wallet in this example). Has been done.
  • the characters “members of the common wallet” are displayed together with an icon image showing the common wallet members, and the number of common wallet members ("2 people” in this example) is displayed next to the characters.
  • a permission button 242P for permitting wallet integration and a refusal button 242Q for refusing wallet integration are displayed.
  • FIG. 5-24 when the permission button 242P is touch-operated on the notification screen of FIG. 5-23, the user A.
  • FIG. 5-24 shows an example of the code information update screen displayed on the display part 24 of the terminal 20 of A.
  • the user B. is newly highlighted with the check mark button CN2 under the word "wallet integration" in the camp fund code payment area 2421.
  • the balance of B's electronic money account (“20,000 yen” in this example) is displayed.
  • the updating information CJK indicating that the code information is being updated is superimposed and displayed.
  • FIG. 5-25 after the code information update screen of FIG. 5-24, the user A. It is a figure which shows an example of the code payment screen (after member integration) displayed on the display part 24 of the terminal 20 of A. On this code payment screen, user B. The result of integrating B's user accounts is displayed. Specifically, in the upper part of the camp fund code payment area 2421, the image of the square wallet, the name of the common wallet (camp fund), the "+” indicating the addition, the image of the purse, and "Mr. BB" Wallet “is displayed. In addition, as the balance after account integration, the common wallet balance and the user B. The amount obtained by adding the balance of B's electronic money account (“21,000 yen” in this example) is displayed.
  • the payment code displayed in the camp fund code payment area 2421 in Fig. 5-25 is different from the payment code shown in Fig. 5-21.
  • FIG. 5-26 shows the user B.
  • the user A Before either the allow button 242P or the deny button 242Q is operated by B, the user A. It is a figure which shows an example of the code payment screen (integration application pending) displayed on the display part 24 of the terminal 20 of A.
  • the slide button CN7 associated with the word "wallet integration" is in the "ON" state.
  • the checkmark button CN2 highlighted in gray, the user B.I.
  • the icon image of B and the user name "BB" are displayed.
  • a rectangular frame containing the characters "pending" is displayed next to it.
  • FIG. 5-27 is a diagram showing another example of the code payment screen of FIG. 5-21.
  • FIG. 5-27 is different from FIG. 5-21 in that the characters "Charge to common wallet" are newly displayed together with the check mark button CN2 under the characters "Wallet integration".
  • the check mark button CN2 By touching the check mark button CN2, the user A. A can charge the common wallet.
  • FIG. 5-28 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the electronic money account and the common account of another user who is a common wallet member are set as an example, not limited.
  • a button having a function of selecting whether or not to request another user (user BB as an example, not limited) to integrate and enable payment is displayed in addition to the display unit 24 (A550).
  • the control unit 21 of the terminal A Based on the user operation on the input / output unit 23 of the terminal A, the user B.
  • the control unit 21 of the terminal A sends the account integration request information to the server 10 by the communication I / F22. Send (A560).
  • the control unit 21 of terminal A receives the payment result information from the server 10 by the communication I / F 22. Then, the step A180 of FIG. 1-9 is executed.
  • the control unit 11 of the server 10 transmits the account integration confirmation information to the terminal B by the communication I / F 14 (S630).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F14, and steps S170a in FIG. 1-9. To execute.
  • the control unit 21 of the terminal B determines the user B.
  • the display unit 24 displays a screen for selecting whether or not to approve the integration of the electronic money account of B and the common wallet (B230). If the account integration confirmation information is not received (B220: NO), the control unit 21 of the terminal B ends the process.
  • the control unit 21 of the terminal B transmits the account integration authorization information by the communication I / F 22. It is transmitted to the server 10 (B240), and the process is terminated.
  • the control unit 21 of the terminal B ends the process.
  • the control unit 11 of the server 10 uses the user B.
  • the account integration process for integrating the electronic money account of B and the common wallet is executed (S650), and the step of S490a is executed. Since the account integration process can be performed in the same manner as in step S480 of FIG. 5-6, the details of the process will be omitted.
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F 14, and steps S170a in FIG. 1-9. To execute.
  • control unit 11 of the server 10 is set to the user B.
  • the user account information including the balance of the electronic money account of B is transmitted to the terminal A by the communication I / F14 (S660).
  • control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F 14, the control unit 11 executes the step S500a of FIG. 5-7.
  • the control unit 21 of the terminal A executes the step of A470a.
  • the control unit 21 of the terminal A executes the step A470a.
  • the control unit 21 of the terminal A executes the step A470a.
  • the control unit 21 of the terminal A executes the step A470a.
  • the control unit 21 of the terminal A executes the step A180 in FIG. 1-9 when the payment result information is received from the server 10 by the communication I / F22. ..
  • FIG. 5-29 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown. Since the first half of the process can be the same as FIG. 5-28 as an example without limitation, and the latter half of the process can be the same as FIG. 4-21 as an example without limitation, the description thereof will be omitted here.
  • the control unit 21 of the terminal A executes the step A580 of FIG. 5-28
  • the control unit 21 receives the integrated account settlement result information from the server 10 by the communication I / F22 and executes the step A480.
  • the control unit 21 of the terminal A causes the display unit 24 to display a screen for selecting whether or not to settle the replacement amount (A590).
  • the user B If the payment amount from B's electronic money account is "0" or the payment has failed, there is no need to make a payment (A590: NO), so the selection screen is displayed on the display unit 24. It may or may not end the process.
  • user B If the payment amount from B's electronic money account is larger than "0" and the payment is successful, the selection screen is not displayed on the display unit 24 and the payment is automatically made (A590: YES). It may or may not be.
  • the control unit 21 of the terminal A uses the user B.
  • the user account payment amount billing information including the payment amount from the electronic money account of B is transmitted to the server 10 by the communication I / F22 (A600).
  • the control unit 21 of the terminal A executes the steps after A400 in FIG. 4-21.
  • the control unit 21 of the terminal A ends the process.
  • the control unit 11 of the server 10 transmits the integrated account payment result information (S520) and receives the user account payment amount billing information from the terminal A by the communication I / F 14 (S670: YES), the user account payment amount billing information is used. Included users B. The payment amount from the electronic money account of B is set as the settlement balance shortage amount, and the steps after S400 are executed. If the user account payment amount billing information is not received (S670: NO), the control unit 11 of the server 10 ends the process.
  • the control unit 21 of the terminal B executes the steps after B190 in FIG. 4-21. If the payment balance shortage amount is not received (B180: NO), the control unit 21 of the terminal B ends the process.
  • the terminal 20 displays a code reader screen for reading the payment store code based on the common wallet code information or the common wallet code reader information on the display unit 24. Then, the terminal 20 displays a code reader screen for reading the payment code associated with the user account information or the payment store code on the display unit 24 based on the input to the user account information of the user of the terminal 20. Can be done.
  • the common wallet balance can be preferentially settled. it can.
  • the terminal 20 is a code reader for reading the payment store code based on the common wallet code information (not limited, but an example of the first code information associated with the common account) or the common wallet code reader information.
  • a screen (not limited, but an example of first code reader information) is displayed on the display unit 24.
  • the terminal 20 uses a payment code (not limited, but a second) associated with the user account information based on the input to the user account information (not limited, but an example of the second account information) of the user of the terminal 20.
  • Display the code reader screen (not limited, but an example of the third code reader information) for reading the payment store code based on the user account information (an example of the third code information associated with the account) on the display unit 24.
  • the configuration is shown.
  • the first code information associated with the common account or the first code reader information can be displayed in the display area of the terminal and used for payment. Further, based on the input to the second account information, the third code information associated with the second account or the third code reader information can be displayed in the display area of the terminal and used for payment.
  • the payment is prioritized from the common wallet balance (not limited, but an example of the balance of the common account) among the common wallet balance and the electronic money account balance of the user account of the user of the own terminal 20. It shows the configuration in which payment is made.
  • the second account can be an ancillary account.
  • FIG. 5-30 "my wallet” (not shown) is touch-operated in the submenu of FIG. 3-1 and the icon indicating "code payment” on the wallet screen of the user A. It is a figure which shows an example of the code payment screen (before integration) which is displayed when touch operation is performed by A.
  • This code payment screen is an example of a screen for selecting a common account as an integration destination based on your own account.
  • the slide button CN7 is placed. By operating this slide button CN7, it is possible to select a common account to be integrated into one's own user account.
  • FIG. 5-31 is a diagram showing an example of a code payment screen (before integration of the common wallet) displayed when the slide button CN7 is touch-operated on the code payment screen (before integration) of FIG. 5-30.
  • the slide button CN7 in the code payment area 2451 of FIG. 5-30 is in the “ON” state.
  • the wallet integration guidance area WT2 including the characters "wallet integration” is superimposed and displayed on the code payment screen as an operation guidance for the user.
  • a common wallet integration selection area WTM2 for selecting a common wallet to be integrated is superimposed and displayed on the wallet integration guidance area WT2.
  • the explanation "Please select the common wallet to be integrated” is displayed at the top, and below that, along with the check mark button CN2, it is a common wallet for camp funds.
  • the characters “camping funds” are displayed, and the common wallet balance ("1,000 yen” in this example) is displayed next to it.
  • FIG. 5-32 shows the code information update screen displayed when the check mark button CN2 associated with the common wallet for Korean travel is touch-operated on the code payment screen of FIG. 5-31 (before the integration of the common wallet). It is a figure which shows an example.
  • Fig. 5-32 differs from Fig. 5-31 in that the characters "Travel to Korea” are displayed under the characters "Wallet integration" in the code payment area 2451, along with the newly highlighted check mark button CN2.
  • Update indicating that it is displayed, that the balance ("90,000 yen” in this example) is displayed next to it, and that the code information is being updated in the camp fund code payment area 2421.
  • the middle information CJK is superimposed and displayed.
  • FIG. 5-33 is a diagram showing an example of a code payment screen (after common wallet integration) displayed after the code information update screen of FIG. 5-32.
  • the image of the purse and your wallet, the "+” indicating the addition, the image of the square wallet and the characters "Travel to Korea” are displayed at the top of the code payment area 2451.
  • the balance (“115,000 yen” in this example) as a result of integrating my user account and common account (Korean travel) is displayed. Further, due to the integration of the accounts, the payment code displayed in the code payment area 2451 is different from the payment code shown in FIG. 5-30.
  • the terminal 20 uses the payment application to execute payment at the member store from the common wallet balance, but the common wallet balance is insufficient at the time of payment.
  • the terminal 20 uses the payment application to execute payment at the member store from the common wallet balance, but the common wallet balance is insufficient at the time of payment.
  • User A This is an example of compensating for the insufficient balance of the common wallet by executing payment based on the integrated account of the electronic money account of A and the common wallet.
  • ⁇ Processing> 6-1 to 6-2 are flowcharts showing an example of the flow of processing executed by each device in the embodiment. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown. This process is an example of a process related to user-presented code payment.
  • the control unit 51 of the store code reader device 50 executes the steps P100 to P160 as the store settlement process.
  • the control unit 11 of the server 10 executes the step of S120
  • the control unit 11 receives the payment request information from the store code reader device 50 by the communication I / F 14 and executes the step of S250a.
  • the step of S270a is executed
  • the step of S470a is executed.
  • the control unit 21 of the terminal A executes the step of A130
  • the control unit 21 of the terminal A executes the step of A270a.
  • the step of A450a is executed.
  • FIG. 6-2 is a flow described for convenience because it is necessary for the following description, and since the steps of each device are the same as those in FIG. 5-7, the description will be omitted.
  • the store code reader device 50 determines whether to transfer the processing to the flow shown in FIG. 6-2 or the flow shown in FIG. 4-5 when the store code reader device 50 executes P130. Since this cannot be performed, branching is performed by the processing of the control unit 11 of the server 10. In FIGS. 6-2 and 4-5, the processes executed by the control unit 51 of the store code reader device 50 are the same, so that the branch result of the server 10 is not directly affected.
  • the terminal 20 has a common wallet balance based on the planned settlement amount (an example of the first settlement amount, not the limitation) and the common wallet balance (the balance of the first account, not the limitation). If there is a shortage, processing related to payment based on the common account (an example of the first account, not the limitation) and the user account of the user of the own terminal 20 (an example of the second account, not the limitation) Is executed by the control unit 21. As an example of the effect obtained by such a configuration, even when the balance of the first account is insufficient, payment can be appropriately performed based on the first account and the second account.
  • the user-presented code payment has been described, but the present invention is not limited to this. Specifically, it may be a store presentation type code payment.
  • FIG. 6-3 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. ..
  • control unit 21 of the terminal A executes the step of A130
  • the control unit 21 of the terminal A executes the step of A300.
  • step of A450b is executed.
  • the control unit 11 of the server 10 executes the step of S120, and when receiving the payment request information from the terminal A by the communication I / F 14, executes the step of S250b. Further, when the step of S270b is executed, the step of S470b is executed.
  • ⁇ Sixth variant (2)> a plurality of accounts are linked to a single code by using the account integration process, but it is not necessary to do so. As an example, but not limited, payment may be made by using multiple accounts in parallel.
  • the control unit 51 of the store code reader device 50 executes the steps P100 to P160 as the store settlement process.
  • the control unit 11 of the server 10 executes the step of S120
  • the control unit 11 receives the payment request information from the store code reader device 50 by the communication I / F 14 and executes the step of S250a.
  • the step of S270a is executed, the step of S530 is executed.
  • the control unit 21 of the terminal A executes the step of A130
  • the control unit 21 of the terminal A executes the step of A270a.
  • the step of A490 is executed. Since the steps of each device in FIG. 6-5 are the same as those in FIG. 5-15, the description thereof will be omitted.
  • the store code reader device 50 determines whether to transfer the processing to the flow shown in FIG. 6-5 or the flow shown in FIG. 4-5 when the store code reader device 50 executes P130. Since this cannot be performed, branching is performed by the processing of the control unit 11 of the server 10.
  • ⁇ Sixth variant (3)> the user A.
  • the amount obtained by adding the balance of A's electronic money account and the balance of the common wallet was defined as the balance of the integrated account (the amount that can be paid by the integrated account), but it is not limited to this.
  • User A If the total balance of the electronic money account of A and the balance of the common wallet is less than the payment amount, the common wallet and the user A.
  • user A Before integrating with A's electronic money account, user A. From an external financial institution account pre-registered by A, user A. You may charge (remittance) to A's electronic money account.
  • FIG. 6-6 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case).
  • the store POS system (in the limited case).
  • each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1 is shown.
  • the latter half of the process is not limited and can be the same as that shown in FIG. 6-2 or FIG. 4-5 as an example, and thus the description thereof will be omitted here.
  • control unit 21 of the terminal A executes the step of A290, the step of A350 is executed, and the steps of A210 to A230 are executed as needed. After that, the control unit 21 of the terminal A executes the steps after A450a.
  • control unit 21 of the terminal A may or may not always execute the steps A210 to A230 without executing the step A350.
  • control unit 11 of the server 10 executes the step of S270a
  • the control unit 11 executes the steps of S190 to S210, and executes the steps of S470a and subsequent steps.
  • control unit 51 of the store code reader device 50 executes the step of P130
  • the control unit 51 executes the steps after P140.
  • FIG. 6-7 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • control unit 21 of the terminal A executes the step of A480
  • the control unit 21 executes the steps of A530 to A340 and ends the process.
  • the control unit 21 of the terminal B executes the steps B100 to B130 and ends the process.
  • the control unit 11 of the server 10 executes the step of S520
  • the control unit 11 executes the steps of S610 to S330 and ends the process.
  • the control unit 51 of the store code reader device 50 executes the step of P160, the process ends. Since each step can be realized in the same manner as in FIG. 5-16, the details thereof will be omitted.
  • the replacement amount of A may or may not be charged to another user of the common wallet (user BB as an example, not limited).
  • FIG. 6-8 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown. The latter half of the process is not limited and can be the same as that shown in FIG. 6-2 as an example, and thus the description thereof will be omitted here.
  • control unit 21 of the terminal A executes the step of A290
  • the control unit 21 executes the steps of A550 to A580.
  • the control unit 11 of the terminal A executes the steps after A480.
  • the control unit 21 of the terminal B executes the steps B220 to B240 and ends the process.
  • the control unit 11 of the server 10 executes the step of S270a
  • the control unit 11 executes the steps of S620 to S660.
  • the control unit 11 of the server 10 executes the steps after S500a.
  • the control unit 51 of the store code reader device 50 executes the step of P130
  • the control unit 51 executes the steps after P140. Since each step can be realized in the same manner as in FIG. 5-28, the details thereof will be omitted.
  • FIG. 6-9 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the first half of the process can be the same as FIG. 6-8 as an example without limitation, and the latter half of the process can be the same as FIG. 4-21 as an example without limitation, so the description is omitted here. To do.
  • control unit 21 of the terminal A executes the step of A580
  • the control unit 21 receives the integrated account settlement result information from the server 10 by the communication I / F22, and executes the steps of A480 to A600.
  • A600 If YES
  • the control unit 21 of the terminal A executes the steps after A400.
  • the control unit 21 of the terminal B executes the step of B180.
  • B180 If YES, the steps after B190 are executed.
  • the control unit 11 of the server 10 executes the step of S660
  • the control unit 11 receives the payment request information from the store code reader device 50 by the communication I / F 14, and executes the steps of S500a to S400.
  • the control unit 11 of the server 10 executes the steps after S410.
  • the control unit 51 of the store code reader device 50 executes the step of P130
  • the process of P140 to P160 is executed. Since each step can be realized in the same manner as in FIG. 5-29, the details thereof will be omitted.
  • the terminal 20 uses the payment application to pay at the member store with the common wallet balance and the user of the terminal 20 (user AA as an example, not limited).
  • the processing is started from the payment using the integrated account.
  • FIG. 7-1 is a flowchart showing an example of the flow of processing executed by each device in the embodiment. From the left side, the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case). As an example, each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1, is shown. This process is an example of a process related to user-presented code payment. Since the latter half of the process can be executed in the same manner as in FIG. 5-7 as an example without limitation, the details thereof will be omitted.
  • control unit 21 of the terminal A uses the communication I / F 22 to provide information for selecting an integrated account that integrates a common wallet that can be used from the terminal A and its own electronic money account, but is not limited to the server 10. (A610).
  • the information for selecting the integrated account is not limited, but as an example, the common wallet ID and the user A. Includes A's payment application ID.
  • the control unit 21 of the terminal A may receive the selectable common wallet ID from the server 10 by the communication I / F 22 in this step, or may call the one stored in advance in the storage unit 28. Further, the control unit 21 of the terminal A may transmit a terminal telephone number capable of specifying the payment application ID in the control unit 11 of the server 10 instead of the payment application ID.
  • the control unit 11 of the server 10 executes the step S480 based on the information for selecting the integrated account.
  • the control unit 21 of the terminal A sends the information for selecting the integrated account including the integrated account ID to the server 10 by the communication I / F 22 as the information for selecting the integrated account. You may send it.
  • the control unit 21 of the terminal A may receive the selectable integrated account ID from the server 10 by the communication I / F 22 in this step, or may call the one stored in advance in the storage unit 28. In this case, the control unit 11 of the server 10 does not have to execute the record addition of the integrated account management data in the account integration process in the step of S480.
  • control unit 11 of the server 10 executes each step of S490a to S120, and when receiving the payment request information from the store code reader device 50 by the communication I / F14, executes the steps after S500a.
  • control unit 21 of the terminal A When the control unit 21 of the terminal A receives the integrated account code information from the server 10 by the communication I / F22, it executes each step of A470a to A130, and when it receives the integrated account payment result information by the communication I / F14, it is A480 or later. Perform the steps in.
  • the control unit 21 of the terminal A selects, as an example, not a limitation, an integrated account that integrates a common wallet that can be used from the terminal A and an electronic money account of a common wallet member other than itself.
  • the information may or may not be transmitted to the server 10 by communication I / F22.
  • the information for selecting the integrated account is not limited, but as an example, the common wallet ID and the user B. Includes B's payment application ID.
  • the terminal 20 is an example of a first account in which the user of the own terminal 20 can make a payment and a user account of the user of the own terminal 20 (not limited, but a second account different from the first account). ) Is associated with the integrated account code information (not limited, but an example of the first code information) is displayed on the display unit 24. Then, the terminal 20 shows a configuration in which the control unit 21 executes a process related to payment based on the integrated account code information being read. As an example of the effect obtained by such a configuration, the first code information associated with the first account that can be settled by the user of the terminal and the second account different from the first account is displayed in the display area of the terminal. Can be used for payment. Further, the settlement can be easily realized based on the reading of the first code information.
  • the seventh embodiment shows a configuration in which the first account is a common account (not limited, but at least an example of a common account in which a terminal user and a first user different from the terminal user can make a payment). ing.
  • the first code information in which the common account and the second account different from the common account are associated can be displayed in the display area of the terminal and used for payment. Further, the settlement can be easily realized based on the reading of the first code information.
  • the seventh embodiment shows a configuration in which the integrated account code information (an example of the first code information, not the limitation) is one code (an example of one code information, not the limitation).
  • the integrated account code information an example of the first code information, not the limitation
  • the integrated account code information is one code (an example of one code information, not the limitation).
  • the integrated account code information (not limited, but an example of the first code information) is the payment application ID of the user of the own terminal 20 or the payment application ID of the user of a different terminal 20 (not limited). It shows a configuration including (an example of information about a second account) and a common wallet ID (an example of information about a common account, not a limitation).
  • a common wallet ID an example of information about a common account, not a limitation.
  • the payment application of the user of the terminal 20 (user BB as an example, not limited) in which the terminal 20 is different from the user of the own terminal 20 (user AA as an example, not limited).
  • Information for selecting an integrated account including an ID (an example of a third account, not a limitation) (an example of third account information regarding a third account, not a limitation) and a payment application ID (limited) of a user of his / her terminal 20 the display unit 24 displays information (not limited, but an example of the second account information regarding the second account) for selecting the integrated account including the second account (an example of the second account).
  • the user of the terminal in addition to the second account information, the user of the terminal can be notified of the third account information regarding the third account different from the second account.
  • the terminal 20 selects an integrated account including the payment application ID (not limited, but an example of the second account) of the user of the own terminal 20 (user AA as an example, not limited).
  • Information to be used an example of second account information related to a second account, not limited
  • a payment application ID an example of a third account, not limited
  • Is displayed on the display unit 24 with information for selecting an integrated account (not limited, but an example of third account information regarding the third account).
  • the terminal 20 is displayed, and information for selecting an integrated account including the payment application ID (not limited, but an example of the second account) of the user of the own terminal 20 (user AA as an example, not limited).
  • the user of the terminal can be made to recognize the second account information regarding the second account and the third account information regarding the third account different from the second account.
  • the first code information or the first code reader information can be displayed in the display area and used for payment.
  • the seventh embodiment shows a configuration in which the second account is an account of the user of the terminal 20 (not limited, but an example of the account of the user of the terminal).
  • the settlement can be realized by using the account of the user of the terminal as the second account.
  • the server 10 has a first account in which the user of one terminal 20 can make a payment and a user account of the user of the terminal 20 (not limited, but a second account different from the first account).
  • the integrated account code information (not limited, but an example of the first code information) associated with (one example) is transmitted to the terminal 20 by the communication I / F14.
  • the server 10 receives payment request information (not limited, but an example of first code information and product information) from the store code reader device 50 by communication I / F14.
  • the server 10 shows a configuration in which the control unit 11 executes a payment process (not a limitation, but an example of a process related to the first payment) based on the received payment request information.
  • the terminal user is made to acquire the first code information in which the first account that can be settled by the terminal user and the second account different from the first account are associated with each other. Can be done.
  • the user-presented code payment has been described, but the present invention is not limited to this. Specifically, it may be a store presentation type code payment.
  • FIG. 7-2 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • an example of a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. .. Since the latter half of the process can be executed in the same manner as in FIG. 5-12 as an example without limitation, the details thereof will be omitted.
  • control unit 21 of the terminal A executes each step of A610 to A130
  • the control unit 21 of the terminal A executes the steps after A190.
  • control unit 11 of the server 10 executes each step of S480 to S120
  • the control unit 11 receives the payment request information from the terminal A by the communication I / F14, and executes the steps after S500b.
  • the terminal 20 integrates a first account that can be settled by the user of the terminal 20 and a user account (not limited, but an example of the second account) of the user of the terminal 20.
  • a code reader screen (not limited, but an example of the first code reader information) for reading the payment store code based on the account code reader information is displayed on the display unit 24.
  • the terminal 20 is configured such that the control unit 21 executes the processing related to the payment based on the payment store code being read by the terminal 20 whose code reader screen based on the integrated account code reader information is displayed on the display unit 24. Shown.
  • the first code reader information in which the first account that can be settled by the user of the terminal and the second account different from the first account are associated with each other is displayed in the display area of the terminal. Can be used for payment. In addition, payment can be easily realized based on the code information being read by the terminal on which the first code reader information is displayed.
  • ⁇ 7th modification (2)> I used to link multiple accounts to a single code using the account integration process, but I don't have to do that. As an example, but not limited, payment may be made by using multiple accounts in parallel.
  • FIG. 7-3 is a flowchart showing an example of the flow of processing executed by each device in this modified example.
  • a payment process executed by the control unit 21 of the terminal A (not limited to the terminal 20 of the user AA) and an example of the payment management process executed by the control unit 11 of the server 10 are shown. .. Since the latter half of the process can be executed in the same manner as in FIG. 5-15 as an example without limitation, the details thereof will be omitted.
  • the control unit 21 of the terminal A uses the communication I / F 22 to send information that selects to use the common wallet that can be used from the terminal A and its own electronic money account in parallel, as an example but not a limitation. It is transmitted to 10 (A620).
  • the information that selects to use the accounts in parallel includes, but is not limited to, the common wallet ID and the user A. Includes A's payment application ID.
  • the control unit 11 of the server 10 executes the step S540 based on the information to select to use the accounts in parallel. Then, the control unit 11 of the server 10 executes each step of S550 to S120, and when receiving the payment request information from the store code reader device 50, executes the steps of S570 and subsequent steps.
  • the control unit 21 of the terminal A executes each step of A510 to A130, and the communication I / F22 from the server 10
  • the steps after A520 are executed.
  • the integrated account code information (an example of the first code information, not the limitation) includes the payment application ID to be integrated (an example of the information about the second account, not the limitation) and the common wallet ID. (Not limited, but an example of information about a common account) can be said to be included or associated.
  • the integrated account code information (not limited, but an example of the first code information) includes the second code information and the third code information, and the second code information is the common wallet ID (not limited).
  • the third code information is associated with the payment application ID to be integrated (an example of a second account, not limited), and the second code information is different from the third code information. Shows the configuration displayed in the area. As an example of the effect obtained by such a configuration, payment can be realized based on individual code information displayed in different areas.
  • the process ends, but it is not necessary to do so.
  • FIG. 7-4 to 7-5 are flowcharts showing an example of the flow of processing executed by each device in this modified example.
  • the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case).
  • the store POS system (in the limited case).
  • each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1 is shown. Since the latter half of the process can be executed in the same manner as in FIG. 6-2 as an example without limitation, the details thereof will be omitted.
  • the control unit 21 of the terminal A executes each step of A610 to A130. Then, the control unit 11 of the server 10 executes each step of S480 to S120. The control unit 51 of the store code reader device 50 executes the processes of P100 to P110.
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F 14.
  • the payment request information includes an integrated account payment token based on the integrated account code information transmitted in step S490a. Therefore, the control unit 11 of the server 10 executes the integrated account settlement process (S680). Since the integrated account settlement process can be executed in the same manner as the step of S500a of FIG. 5-7, the description thereof will be omitted in detail.
  • the control unit 11 of the server 10 proceeds to the step of S510 in FIG. 6-2.
  • the control unit 11 of the server 10 provides the payment balance shortage information including the payment failure and the payment balance shortage amount in the integrated account in that case. It is transmitted to the terminal A and the store code reader device 50 by the communication I / F 14 (S700).
  • the settlement balance shortage information in this modification is information indicating that the balance of the integrated account is insufficient, but the integrated account is the common account and the user A. It is an account integrated with A's user account. Therefore, the settlement balance shortage information in this modification includes the common wallet balance and the user A. This is information indicating that the balance of the electronic money account of A is insufficient.
  • control unit 11 of the server 10 further executes the steps S190 to S210, and when the payment request information is received from the store code reader device 50 by the communication I / F 14, the steps after S500a are executed.
  • the control unit 21 of the terminal A executes the steps A280 to A290.
  • the control unit 21 of the terminal A further executes the steps A210 to A230, the control unit 21 receives the integrated account settlement result information from the server 10 by the communication I / F22 and executes the step A480.
  • the control unit 21 of the terminal A receives the integrated account payment result information from the server 10 by the communication I / F22, and executes the steps after A480.
  • the control unit 51 of the store code reader device 50 executes the steps after P130.
  • the control unit 51 of the store code reader device 50 receives the payment result information from the server 10 by the communication I / F 54, and executes the steps after P160.
  • the terminal 20 has the planned settlement amount (an example of the first settlement amount, not the limitation), the common wallet balance (an example of the balance of the common account, not the limitation), and the user of the own terminal 20. Settlement indicating that the balance between the common wallet balance and the electronic money account balance of the user of the own terminal 20 is insufficient based on the electronic money account balance (not limited, but an example of the balance of the second account).
  • the balance shortage information (not limited, but an example of the first information regarding the shortage of the balance between the common account and the second account) is displayed on the display unit 24.
  • the terminal 20 charges the electronic money account of the user of the own terminal 20 based on the input for the payment balance shortage information by the user of the own terminal 20 (not limited, but remittance to the second account).
  • An example of processing is shown in a configuration in which the control unit 21 executes the process. As an example of the effect obtained by such a configuration, it is possible to notify the user of the terminal that the balance between the common account and the second account is insufficient. In addition, remittance can be made to the second account based on the input of the first information by the user of the terminal.
  • the common wallet balance is not enough at the time of payment by the integrated account, and even if the balance of the user's electronic money account is used for reimbursement, the reimbursed amount is other than the common wallet.
  • the user (user BB as an example, not limited) was not charged, but may or may not be charged.
  • FIG. 7-6 is a flowchart showing an example of the flow of processing executed by each device in this modified example. From the left side, payment processing executed by the control unit 21 of terminal A (terminal 20 of user A.A as an example, not limited), control of terminal B (terminal 20 of user BB as an example, not limited).
  • a store code reader device that is a component of a payment cooperation process executed by the unit 21, a payment management process executed by the control unit 11 of the server 10, and a store POS system (not limited to, for example, the store POS system 40 of the member store S1).
  • An example of the store settlement process executed by the control unit 51 of the 50 is shown.
  • the first half of the process can be the same as FIG. 7-4 as an example without limitation, and the latter half of the process can be the same as FIG. 6-2 as an example without limitation, so the description is omitted here. To do.
  • control unit 21 of the terminal A executes the step of A290, it executes the steps of A360 to A380, and when it receives the integrated account payment result information from the server 10 by the communication I / F22, it executes the steps of A480 and subsequent steps.
  • the control unit 21 of the terminal B executes the steps B140 to B170 and ends the process.
  • the control unit 11 of the server 10 executes the steps S340 to S390, the control unit 11 receives the payment request information from the store code reader device 50 by the communication I / F14, and executes the steps after S500a. Since each step of the process can be executed in the same manner as in FIG. 4-19, the details thereof will be omitted.
  • the integrated account code information will be displayed on the terminal 20 that requested the transfer. It may be hidden from 24, or the subsequent processing related to payment may not be executed.
  • the balance is compensated by charging the own account and increasing the balance of the integrated account, but it is not necessary to do so.
  • the electronic money account of another common wallet member may be added to the integrated account composed of the common wallet and its own electronic money account.
  • FIG. 7-7 to 7-8 are flowcharts showing an example of the flow of processing executed by each device in this modification.
  • the payment process executed by the control unit 21 of the terminal A (not limited, but as an example, the terminal 20 of the user AA), the payment management process executed by the control unit 11 of the server 10, and the store POS system (in the limited case).
  • the store POS system (in the limited case).
  • each example of the store settlement process executed by the control unit 51 of the store code reader device 50, which is a component of the store POS system 40) of the member store S1 is shown.
  • the first half of the process is not limited and can be the same as that shown in FIG. 7-4 as an example, and thus the description thereof will be omitted here.
  • the control unit 21 of the terminal A executes the step of A290, the screen for selecting whether or not to further integrate another electronic money account (not limited to the electronic money account of user BB as an example) into the integrated account is displayed. , Displayed on the display unit 24 (A620).
  • the addition of an additional electronic money account to the integrated account will be referred to as "account reintegration".
  • the control unit 21 of the terminal A When it is selected to reintegrate the account based on the user operation on the input / output unit 23 of the terminal A (A620: YES), the control unit 21 of the terminal A has the integrated account ID of the integration source and the user to be added.
  • the account reintegration request information including the payment application ID of is transmitted to the server 10 by the communication I / F22. If reintegration of accounts is not selected based on user operations on the input / output unit 23 of terminal A (A620: NO), the control unit 21 of terminal A will be integrated account from server 10 by communication I / F 22.
  • the payment result information is received, and the step A480 in FIG. 6-2 is executed.
  • the control unit 11 of the server 10 executes the account reintegration process (S720).
  • the control unit 11 of the server 10 receives the payment request information from the store code reader device 50 by the communication I / F14, and executes the steps after S500a. ..
  • the control unit 11 of the server 10 searches the integrated account management database 159 for a record of integrated account management data having the integrated account ID of the integration source, and sets the user B. Add the payment application ID of B and store it.
  • the balance of the integrated account is the amount obtained by adding the electronic money balance of the payment application ID added to the integrated account member ID.
  • control unit 11 of the server 10 transmits the reintegrated account information including the electronic money balance of the reintegrated integrated account to the terminal A by the communication I / F14 (S730).
  • control unit 21 of the terminal A receives the reintegrated account information from the server 10 by the communication I / F 22, the electronic money balance of the reintegrated integrated account is updated and displayed on the display unit 24 (A640). Then, the control unit 11 of the store code reader device 50 executes the steps P140 to P160 and ends the process.
  • the control unit 11 of the server 10 regenerates the integrated account payment token and the integrated account code information including the new integrated account payment token, and connects to the terminal A by the communication I / F14. You may send it.
  • the control unit 21 of the terminal A receives the integrated account code information from the server 10 by the communication I / F 22, the integrated account code information is updated and displayed on the display unit 24.
  • the control unit 11 of the server 10 executes the reintegrated account payment process (S740).
  • the control unit 11 of the server 10 searches for the integrated account ID from the requested integrated account payment token.
  • the control unit 11 of the server 10 further has an integrated account member ID associated with the integrated account ID (here, the payment application ID of user AA, the payment application ID of user BB, and the common wallet ID of the common wallet).
  • User A Pointed to by the integrated account member ID based on.
  • A's electronic money account balance and user B Using the total amount of the electronic money account balance and the common wallet balance of B, a payment process for paying the planned settlement amount with the member store defined by the store ID is executed for the integrated account.
  • the control unit 11 of the server 10 reduces the common wallet balance by the planned settlement amount.
  • control unit 11 of the server 10 uses the communication I / F 14 to send the payment result information including the success or failure of the payment processing and the reintegrated integrated account balance after the payment processing to the store code reader device 50, not by limitation. (S750).
  • control unit 11 of the server 10 is not limited, but as an example, the success or failure of the payment process, the electronic money account / common wallet balance of each user constituting the integrated account after the payment process, and each electronic money account / common.
  • the reintegrated account payment result information including the payment amount in the wallet is transmitted to the terminal A by the communication I / F14 (S760), and the process is completed.
  • the control unit 21 of the terminal A displays the reintegrated account settlement result information on the display unit 24 (A650), and ends the process.
  • the electronic money account that can be added to the integrated account is not limited to the user account. You may or may not add another common wallet.
  • the payment is performed by the common wallet balance, the electronic money account balance of the user account of the user of the own terminal 20, and the electronic money account balance of the user account of the user of the different terminal 20. It is not limited, but shows a configuration in which payment is given priority from the balance of the common account). As an example of the effect obtained by such a configuration, payment is preferentially performed from the balance of the common account, so that another account can be used as an ancillary account.
  • the terminal 20 is a user of a common wallet member, including a user account of a user of the terminal 20 (not limited to an example of a second account) and a user account of another common wallet member.
  • the configuration in which the control unit 21 executes the processing related to the settlement based on the account and the common account is shown.
  • payment can be realized based on each account of the user who can settle by the common account including the second account and the common account.
  • the integrated account code information (not limited, but an example of the first code information) shows a configuration in which each user account of the common wallet member is associated.
  • the first code information associated with each account of the user who can settle by the common account can be used for the settlement.
  • this modification shows a configuration in which each user account of the common wallet member is deducted by splitting the shortfall of the common wallet balance (equal division), and payment based on the settlement is executed.
  • each user account of the common wallet member is deducted by splitting the shortfall of the common wallet balance (equal division), and payment based on the settlement is executed.
  • the account reintegration process that integrates the common wallet and the electronic money accounts of two or more users and the payment using the reintegration account once attempted payment using the integrated account and failed. I decided to do it later, but it is not limited to that. As an example, but not a limitation, account reintegration may occur after Figure 6-1.
  • the terminal 20 uses the code information (payment code, etc.) associated with the user account of the user of the terminal 20 (not limited, but the third associated with the second account).
  • An example of code information) is displayed on the display unit 24.
  • the terminal 20 displays information on the common wallet (common wallet ID, etc.) (not limited, but an example of common account information) on the same screen as an example, not limited.
  • the terminal 20 integrates the common account and the user account of the user of the own terminal 20 as an example, not by limitation.
  • the account code information (not limited, but an example of the first code information) may or may not be displayed on the display unit 24.
  • the terminal 20 has a code reader screen (limited to reading) for reading the payment store code based on the code reader information associated with the user account of the user of the terminal 20. (An example of the third code reader screen associated with the second account) is displayed on the display unit 24. Further, the terminal 20 displays information on the common wallet (common wallet ID, etc.) on the same screen as an example, not limited to this. Then, based on the input by the user of the own terminal 20 to the information about the displayed common wallet, the terminal 20 integrates the common account and the user account of the user of the own terminal 20 as an example, not by limitation. A code reader screen for reading the payment store code based on the account code reader information (not limited, but an example of the first code reader screen) may or may not be displayed on the display unit 24. Good.
  • the third code information associated with the second account or the third code reader information can be displayed in the display area of the terminal and used for payment.
  • the first code information or code information in which the first account that can be settled by the terminal user and the second account different from the first account are associated with each other based on the input by the terminal user for the common account information.
  • the first code reader information which is a display related to reading, can be displayed in the display area of the terminal and used for payment.
  • the terminal 20 when the user-presented code payment is applied, the terminal 20 is not limited, but as an example, instead of the code information (payment code, etc.) associated with the user account of the user of the own terminal 20.
  • the common wallet code information associated with the common account (not limited, but an example of the third code information associated with the first account) may or may not be displayed.
  • the terminal 20 when the store presentation type code payment is applied, the terminal 20 is displayed on the code reader screen for reading the payment store code based on the code reader information associated with the user account of the user of the terminal 20. Instead, as an example rather than a limitation, display a code reader screen for reading the payment store code based on the common wallet code reader information (not a limitation, but an example of the third code information associated with the first account). It may or may not be.
  • the third code information associated with the first account or the third code reader information can be displayed in the display area of the terminal and used for payment.
  • the first code information or code information in which the first account that can be settled by the terminal user and the second account different from the first account are associated with each other based on the input by the terminal user for the common account information.
  • the first code reader information which is a display related to reading, can be displayed in the display area of the terminal and used for payment.
  • the payment may be made by wireless communication (including short-range wireless communication) instead of the code payment. This can be similarly realized by applying the process described in the fourth modification (9) to the account integration described in the seventh embodiment.
  • the eighth embodiment is an embodiment related to the above-mentioned billing / remittance of the advance amount.
  • the request / remittance of the advance amount can be applied to any of the above-mentioned second to seventh embodiments.
  • the terminal 20 of the common wallet member uses the payment application to execute payment at the member store from the electronic money balance of the common wallet. If the electronic money balance of the common wallet is insufficient at the time of payment, the insufficient balance of the common wallet is compensated by sending money from the user's electronic money account to the common wallet. Then, in the eighth embodiment, when the common wallet is destroyed, the amount reimbursed from the balance of the user's electronic money account is charged.
  • “Destroy the common wallet” means terminating the common wallet, and more specifically, deleting the common wallet so that it will no longer be used, as an example, not a limitation.
  • common wallet destruction that deletes the data of the common wallet stored and managed by the server 10 by the destruction request from the terminal 20 of the representative of the common wallet member or the terminal 20 of another common wallet member. The process is executed.
  • the payment processing on the terminal of the common wallet member for each time is not limited, but can be executed in the same manner as in FIGS. 4-4 to 4-5 of the fourth embodiment. Explanation is omitted.
  • FIG. 8-1 is a diagram showing a data configuration example of the second common wallet management database 157B, which is an example of the common wallet management database 157 stored in the storage unit 15 of the server 10 in this embodiment.
  • common wallet management data is stored as management data for each common wallet ID.
  • each common wallet management data as an example, the common wallet ID, the common wallet name, the common wallet balance, the common wallet member ID, and the advance history data are stored in association with each other.
  • the common wallet ID, the common wallet name, the common wallet balance, and the common wallet member ID are the same as those of the first common wallet management database 157A.
  • the advance history data is executed for this common wallet when payment is made using this common wallet and part or all of the planned settlement amount is reimbursed from the user's electronic money account balance due to insufficient common wallet balance. It is data for recording the history of the advance payment, and is not limited but is stored as an example in association with the advance person ID, the advance person name, the advance date and time, and the advance amount.
  • the replacement ID is an identifier for identifying the performer (replacement person) who executes the replacement payment using his / her own electronic money account balance against the insufficient balance of this common wallet, and is not a limitation but as an example.
  • the payment application ID of the user who makes the advance payment is stored.
  • the replacement person name is the name of the replacement person, and the user name corresponding to the replacement person ID is stored as an example, not limited.
  • the advance payment date and time is an item for recording the date and time when the advance payment is made, and the date and time when the control unit 11 of the server 10 executes the step S170a in FIG. 4-5 is stored as an example, not limited.
  • the advance amount is the amount that was reimbursed from the user's electronic money account balance due to the common wallet balance shortage, and is not limited, but as an example, the settlement balance shortage amount calculated in step S250a in FIG. 4-4 is It will be remembered.
  • the settlement process (first settlement process) is executed in accordance with FIGS. 4-4 to 4-5 on the terminal of the common wallet member (the terminal A of the user AA as an example, not limited). Then, as an example, not limited, it is assumed that the settlement process fails in the step of S250a in FIG. 4-4, and the settlement balance shortage amount is "1,000 yen".
  • the control unit 11 of the server 10 determines the payment application ID (in this example, the payment application ID of the user AA, "U0001") that is executing the payment process. ), Its user name (“AA” in this example), the date and time when the payment process was executed (“2020/5/1 / **: **: **” in this example), and Fig. 4-.
  • the control unit 11 of the server 10 uses the payment application ID during the payment process (in this example, the payment application ID of user BB). A certain "U0002"), its user name ("BB” in this example), and the date and time when the payment process was executed ("2020/5/5 / **: **: **" in this example).
  • the control unit 21 of the terminal A receives the common wallet destruction request information. Is transmitted to the server 10 by the communication I / F22.
  • the control unit 11 of the server 10 executes a billing process for the advance amount for each advance amount stored in the advance history data.
  • the individual billing process can be executed in the same manner as in FIG. 4-9 as an example without limitation, and thus the details thereof will be omitted.
  • the control unit 11 of the server 10 may use the terminal B.
  • the billing process may not be executed by sending information including the fact that the payment advance amount of "2020/5/1 / **: **: **" will not be billed.
  • the control unit 11 of the server 10 executes the common wallet discard process.
  • the payment process executed by the terminal is not limited to the fourth embodiment, and can be applied to any of the second to seventh embodiments.
  • the amount to be reimbursed according to the user's electronic money account balance may be used as the reimbursement amount.
  • the payment advance billing information is transmitted to the second terminal 20 (terminal 20 receiving the bill) based on the destruction of the common wallet (an example of the destruction of the common account, not the limitation). Is shown. As an example of the effect obtained by such a configuration, billing information based on payment can be transmitted to the terminal based on the destruction of the common account.
  • the above-mentioned payment advance amount billing information is payment advance amount request information (not limited, but an example of the first billing information) for the user of the second terminal 20, and is a common account and the first.
  • the processing related to the payment is executed.
  • Payment advance billing information for the user of the first terminal 20 based on the payment by the user of the second terminal 20 shows a configuration in which the information is transmitted to the first terminal 20 (not limited, but an example of the first terminal) based on the destruction of the common wallet.
  • the second billing information different from the first billing information based on the second settlement is transmitted to the first terminal based on the destruction of the common account. Can be done.
  • information including the fact that the terminal 20 does not charge the payment advance amount (not limited, but an example of information regarding changing the billing information) is applied to at least one of the terminals 20 of the common wallet member.
  • the configuration of transmitting by communication I / F22 is shown.
  • notifying that the billing information is changed by sending information about changing the billing information to at least one of the terminals of the user who can settle by the common account. Can be done.
  • the terminal 20 of the common wallet member uses the payment application to make payment at the member store from the electronic money balance of the common wallet, or the electronic money of the integrated account of the common wallet and the user's electronic money account. Execute from the balance. Then, when performing the common wallet destruction operation, the common wallet balance is distributed to the user account and remitted (refunded) based on the amount of money transferred from the user account to the common wallet and the amount of remittance reimbursed by the user account.
  • remittance from a user account to a common wallet will be referred to as "investment in a common wallet", and the remittance amount will be referred to as "investment amount”.
  • the payment processing at the terminal of the common wallet member for each time is not limited, but can be executed in the same manner as in FIGS. 6-1, 6-2, and 4-5 of the sixth embodiment as an example. Therefore, the details thereof will be omitted here.
  • FIG. 8-2 is a diagram showing a data configuration example of the third common wallet management database 157C, which is an example of the common wallet management database 157 stored in the storage unit 15 of the server 10.
  • the common wallet management database 157C stores common wallet management data as management data for each common wallet ID.
  • Each common wallet management data is not limited, but as an example, common wallet ID, common wallet name, common wallet balance, common wallet member ID, common wallet generation date and time, investment history data, and payment history data. Is stored in association with.
  • the common wallet ID, the common wallet name, the common wallet balance, and the common wallet member ID are the same as those of the first common wallet management database 157A.
  • the date and time when the common wallet was generated is stored in the common wallet generation date and time.
  • the investment history data is the history data of the investment executed in this common wallet, and is not limited but is stored as an example in which the investor ID, the investor name, the investment date and time, and the investment amount are associated with each other. ..
  • the investor ID is an identifier for identifying the executor (investor) who executes the investment in this common wallet, and the payment application ID of the user who makes the investment is stored as an example without limitation.
  • the investor name is the name of the investor, and the user name corresponding to the investor ID is stored as an example, not limited.
  • the investment date and time is the date and time when the investment is made, and the date and time when the investor made the investment in the common wallet is stored as an example, not limited.
  • the investment amount is the investment amount per investment made by the investor in this common wallet.
  • Fig. 8-2 as an example, not limited to the common wallet "camping funds", the user A.
  • A is "3,000 yen” for "2020/3/11 / **: **: **” and "3,000 yen” for "2020/4/14 / **: **: **” It is shown that it has invested.
  • the user B. B is "3,000 yen” for "2020/3/12 / **: **: **” and "3,000 yen” for "2020/4/14 / **: **: **” It is shown that it has invested.
  • the payment history data is the history data of payments executed and completed using this common wallet, and is not limited, but as an example, the payer ID, the store name, the payment date and time, the payment amount, the advance payment amount, and the like. It is stored in association with the recovery flag.
  • the payer ID is an identifier for identifying the performer (payer) who executes payment using this common wallet in the member store, and is not limited but is stored as an example of the payment application ID of the user who makes the payment. Will be done.
  • the store name is a name for identifying a member store to which payment is made, and is not limited, but as an example, the name of the store or service that the member store registers when registering to use the payment application is stored.
  • the payment date and time is the date and time when the payer executes payment by the payment application at the member store of the store name, and is not limited, but as an example, the control unit 11 of the server 10 executes the payment process or the integrated account payment process. The date and time of success is remembered.
  • the payment amount is the scheduled payment amount for which payment is executed by the payment application at the member store of the store name, and is not limited, but as an example, the control unit 11 of the server 10 uses the communication I / F 14 from the store code reader device 50.
  • the estimated payment amount based on the received payment request information is stored.
  • the advance amount is the amount that is reimbursed from the user's electronic money account balance due to insufficient common wallet balance when payment is made from the electronic money balance of the integrated account of the common wallet and the user's electronic money account, and is not limited.
  • the payment amount from the payer's electronic money account based on the result of the integrated account payment process is stored. If the integrated account settlement process is not executed, the advance amount is set to "0".
  • the collection flag is flag information for recording whether or not the remittance amount is completed and the remittance amount is charged for each payment when the remittance amount is larger than "0".
  • "done" is stored as an example, not limited.
  • the settlement remittance process is not executed in the control unit 11 of the server 10 or the settlement request process fails, "not yet” is stored as an example, not a limitation.
  • the advance amount is "0"
  • it is not necessary to execute the settlement so "-” is stored as an example, not a limitation.
  • the billing process for the advance amount for each payment is not limited, and can be executed in the same manner as in FIG. 6-7 as an example, and thus the details thereof will be omitted.
  • the payer “U0001” (that is, user AA) uses the common wallet “camping funds” for the payment history data, and “2020/4/5 / *”.
  • the payer “U0001” (that is, user A.A.) pays "3,000 yen” to "2020/4/11 / **: **: **" at the store "AA Sports”. Do, user A. It is shown that "2,000 yen” has been repaid in A's electronic money account and that the reimbursement amount has not yet been settled.
  • the control unit 11 of the server 10 is common based on the common wallet management data of the third common wallet management database 157C. Execute wallet settlement discard processing.
  • the total investment amount for each investor is calculated for each investor ID in the investment history data.
  • the total advance amount for each payer is calculated for each payer ID of the payment history data. In the calculation of the total advance amount, only the advance amount for which the collection flag is "not yet" is included in the total.
  • the user A As an example, not a limitation, in FIG. 8-2, the user A.
  • the total advance amount of A is "2,000 yen”
  • the total advance amount of B is "6,000 yen”.
  • the total investment amount of all common wallet members and the total advance amount are calculated as the total investment amount of the common wallet "camping funds".
  • the average payment amount per common wallet member paid from the common wallet at the time of executing the common wallet settlement cancellation process is calculated by "(total investment amount-common wallet balance) / number of common wallet members".
  • the estimated refund amount for refunding the common wallet balance based on the ratio of the investment amount is calculated.
  • the estimated refund amount is calculated by "(total investment amount + total advance amount) -average payment amount".
  • the estimated refund amount is the sum of the amount directly invested by each user in the common wallet (total investment amount) and the amount indirectly invested by reimbursement (total advance amount) in the common wallet. It is the amount obtained by subtracting the amount obtained by dividing the payment amount evenly.
  • control unit 11 of the server 10 executes a refund process of remittance of the planned refund amount using the common wallet balance to each electronic money account of the common wallet member. If the estimated refund amount is negative, the absolute value of the estimated refund amount will be used as the remittance amount, and the payment will be made by remittance from the user's electronic money account to the common wallet.
  • the payment process executed by the terminal is not limited to the sixth embodiment, and can be applied to any of the second to seventh embodiments.
  • it is sufficient to store as the advance amount the amount of insufficient settlement balance, which is the amount that at least the remittance to the common wallet is required to complete the payment with the common wallet. ..
  • FIG. 8-3 the icon indicating "destroy wallet" on the camp fund payment screen of FIG. 3-3 is the user A. of the terminal 20. It is a figure which shows an example of the summary display screen of the camp fund which is displayed when touch-operated by A.
  • the display screen example described below is a screen view to which the example of FIG. 8-2 is applied.
  • camp Fund which is a submenu currently being executed
  • Wallet Discard is displayed as an operation guide for the user, and below that, a summary display area 2452 of the camping Funds is displayed.
  • the camp fund summary display area 2452 is displayed in three stages, with "April 15, 2020" displayed as the current date in the upper row, and below that is the image of the square wallet and the common. A summary of the wallet name (camping funds) is displayed.
  • the total payment amount is not limited, but is an amount calculated by "total investment amount-common wallet balance" as an example.
  • the amount of refund to each member is displayed in a list format.
  • User A the characters of the user name "myself” are displayed, and next to it, "1,000 yen” is displayed as the estimated refund amount in this example.
  • a correction button BT9 for correcting the estimated refund amount of oneself and a detail button BT10 for confirming the details of the estimated repayment amount of oneself are displayed side by side.
  • the second line of the estimated refund amount is User B.
  • the characters of the user name "BB” are displayed, and next to it, "5,000 yen” is displayed as the estimated refund amount in this example.
  • User A Similar to A, the correction button BT9 and the detail button BT10 are displayed side by side.
  • a cancel button 242R for canceling the destruction of the common wallet and a discard button 242S for executing the destruction of the common wallet are displayed side by side.
  • FIG. 8-4 is a diagram showing an example of one's own summary display screen displayed when the detail button BT10 in one's line is touch-operated on the camp fund summary display screen of FIG. 8-3.
  • the own summary display area 2453 is displayed in two columns, and "April 15, 2020" is displayed as the current date in the upper column, and the user A.A.
  • the characters of the user name "self” are displayed.
  • the characters “Investment amount” are displayed as the investment amount, and the user A.
  • the total investment amount of A, "6,000 yen" is displayed.
  • my usage history is displayed in chronological order in a list format.
  • "20:55 on March 11, 2020” is displayed as the date and time of the usage date, and below that, the characters “Investment” are displayed as the usage item and the investment amount is displayed.
  • "3,000 yen” is displayed.
  • FIG. 8-5 shows the user B.
  • user B. The summary display screen of B will be described, but the display format is the same as that of the above-mentioned own summary display screen.
  • B Below B's summary display area 2454, user B.
  • the usage history of B is displayed in chronological order in a list format. On the first line, “8:24 on March 12, 2020” is displayed as the date and time of the usage date, and below that, the characters “Investment” are displayed as the usage item and the investment amount is displayed. "3,000 yen” is displayed.
  • the remittance process to the common wallet based on the payment advance payment billing information is executed based on the input of the user of the terminal 20.
  • the user account of the first terminal 20 (not limited, but an example of the first account) is the user account of the first terminal 20 by the payment by the user of the first terminal 20 (not limited, an example of the first payment). If the common wallet contains more than or more than the amount paid from, the amount paid by the user of the first terminal 20 from the user account of the user of the first terminal 20 will be the amount paid by the user of the first terminal 20. It shows the configuration in which money is sent from the common wallet.
  • the first account is the first when the common account contains an amount equal to or greater than the amount paid from the first account by the first settlement. The amount paid from the first account by the settlement can be remitted from the common account.
  • the terminal 20 provides the server 10 with information for correcting the estimated refund amount to the user of the terminal 20 (not limited, but an example of information regarding changing the information related to the refund).
  • the configuration of transmitting to another terminal 20 via the communication I / F 22 is shown. As an example of the effect obtained by such a configuration, notifying that the refund information is changed by sending information about changing the refund information to at least one of the user's terminals that can be settled by the common account. Can be done.
  • the control unit 11 of the server 10 executes a refund process of remittance of the planned refund amount using the common wallet balance to each electronic money account of the common wallet member.
  • the following processing may be executed.
  • the control unit 11 uses the user A. From A's user account to user B. The information notifying the user account of B that "2,000 yen" will be remitted is provided by the user A. Terminal 20 of A and user B. It is transmitted to the terminal 20 of B by communication I / F14, respectively. Then, the control unit 11 uses the user A. While subtracting "2,000 yen" from the electronic money account balance of A, user B. Add "2,000 yen" to B's electronic money account balance. Then, the control unit 11 executes the common wallet discard process.
  • the second terminal 20 when the common wallet is destroyed, the second terminal 20 remits money from the first terminal 20 (not limited, but an example of the first terminal) to the common wallet (not limited, but not limited).
  • the user of the second terminal 20 based at least based on the information of the second amount (an example of the second amount) and the information of the amount of money (not limited, but an example of the first amount) remitted from the second terminal 20 to the common wallet.
  • Information notifying that remittance is sent from the user account of the user to the user account of the user of the first terminal 20 (not limited, but an example of information regarding remittance from the user of the terminal to the first user of the first terminal), or the first Information notifying that remittance is sent from the user account of the user of the first terminal 20 to the user account of the user of the second terminal 20 (not limited to information regarding remittance from the first user of the first terminal to the user of the terminal).
  • An example) is shown in the configuration of receiving the communication I / F22. As an example of the effect obtained by such a configuration, remittance to a common account can be realized.
  • the information notifying the transfer of money from the user account of the user of the second terminal 20 to the user account of the user of the first terminal 20, or the user account of the user of the first terminal 20 is used.
  • the information notifying the user account of the user of the second terminal 20 that the money is to be transferred from the second terminal 20 to the common wallet includes the amount of money transferred from the second terminal 20 to the common wallet (not limited, but an example of the first amount) and the first.
  • the configuration is determined based on the amount of money transferred from the terminal 20 to the common wallet (an example of the second amount, not the limitation) and the common wallet balance (an example of the balance of the common account, not the limitation). ..
  • information on remittance from the user to the first user based on the first amount, the second amount, and the balance of the common account, or from the first user to the user. can properly determine information about remittances.
  • this modification is based on the user account of the user of the first terminal 20 (an example of the first account, not the limitation) and the common account, and the first terminal 20 (not the limitation, but an example of the first user).
  • a process related to payment is executed by an example of the first terminal), and the second terminal 20 charges the payment advance amount billing information (not limited, but the amount based on the first payment) based on the payment by the user of the first terminal 20.
  • An example of billing information regarding the above) is received by communication I / F22 based on the destruction of the common wallet.
  • the billing information regarding the billing of the amount based on the first settlement can be received based on the destruction of the common account.
  • the server 10 has at least a user of the second terminal 20 (an example of a terminal user, not a limitation) and a user of the first terminal 20 (an example of a first user, not a limitation).
  • Information on the amount of money to be sent from the second terminal 20 to the common account that can be settled (not limited, but an example of the first amount) and the amount of money to be sent from the first terminal 20 to the common account (limited)
  • the information of (an example of the second amount) is received by the communication I / F22.
  • the server 10 transfers money from the user account of the user of the second terminal 20 to the user account of the first terminal 20 (limitedly) based on the information of the amount of money to be transferred based on the destruction of the common wallet.
  • the ninth embodiment is an embodiment that realizes account-linked payment.
  • the server 10 will be described as executing the account linkage process. Not limited to this, the account linkage process may or may not be executed on the terminal 20.
  • ⁇ Display screen example> an example of a display screen will be described by taking a talk room in the above-mentioned messaging application as an example.
  • the talk using the messaging application is an example of "chat”
  • the talk room is an example of "chat room”.
  • the following is an example of a case where user accounts of a plurality of group members included in a group formed in a messaging application are linked to perform account linked payment.
  • FIG. 9-1 similarly to FIG. 5-30, "my wallet” (not shown) was touch-operated in the submenu of FIG. 3-1 and "code payment” was shown on my wallet screen.
  • the icon is the user A. of the terminal 20. When touch-operated by A, user A. It is a figure which shows an example of the code payment screen (before cooperation) displayed on the display part 24 of the terminal 20 of A.
  • FIG. 9-2 is a diagram showing an example of a talk room selection screen displayed when the slide button CN7 is touch-operated in FIG. 9-1.
  • Messageing App which is the application name of the message application
  • the title bar at the top, and next to it, the user A.
  • the icon image of A and the characters of the user name "AA” are displayed.
  • Below the title bar the current position in the hierarchical menu of "Messing App" is displayed.
  • This list contains multiple row items that are vertically arranged for the user to select, and the row item shows the name of the talk room in association with the talk room icon image of the talk room. ..
  • FIG. 9-3 shows a code payment screen (after cooperation) displayed when a line item displaying the characters “grass baseball team (10)” is touch-operated on the talk room selection screen shown in FIG. 9-2. ) Is shown in the figure.
  • the difference between FIG. 9-3 and FIG. 9-1 is that the slide button CN7 is in the "ON" state in the code payment area 2451, and the icon of the glove newly catching the ball is under the slide button CN7.
  • the characters "grass baseball team (10)” are displayed along with the image.
  • the account (wallet) is linked, the displayed payment code is different from that in FIG. 9-1.
  • FIG. 9-4 is a diagram showing an example of a code payment completion screen displayed on the terminal 20 when the payment process by the server 10 is completed as in FIG. 3-7.
  • the code payment completion screen in Fig. 9-4 differs from the code payment completion screen in Fig. 3-7 at the bottom of this screen, below the part where the payment destination is "AA Sports Co., Ltd.” It is a part. Specifically, below the payee display, information about a new "grass baseball team” group is displayed via an underline. More specifically, “10 people” is displayed as the number of members of the "grass baseball team", and "500 yen” is displayed as the amount of money per person. Further, at the bottom of the screen, a confirmation button 242B for notifying that the user has confirmed the completion of the code payment is displayed.
  • FIG. 9-5 is a diagram showing an example of a talk room screen displayed on the display unit 24 in the messaging application executed by the terminal 20.
  • On this talk room screen as an example, not limited to, "Messing App", which is an application name of a messaging application, is displayed in the title bar at the top. Below the title bar, the current position in the hierarchical menu of "Messing App” is displayed. Specifically, “Kusa Baseball Team (10)", which is the highest-level menu currently being executed, is displayed as an example, not a limitation. Below that, a talk room area 2461 is provided, and further below, an icon display area 2471 is provided.
  • the characters "today” are displayed as the date in the upper center.
  • User X Below that is User X.
  • the user name "XX” is displayed together with the icon image of X, and the user X.
  • the message "There are not enough balls to use in the next game " is displayed in a balloon on the left side of the screen.
  • the user A who is the user of his / her own terminal 20.
  • the message “I'm just shopping at AA sports, so I'll buy it” is displayed in a balloon on the right side of the screen.
  • FIG. 9-6 is a diagram showing an example of a talk room screen displayed when the wallet cooperation icon CN8 is touch-operated on the talk room screen of FIG. 9-5.
  • the user Y. displayed in the talk room area 2461 of FIG. 9-5.
  • Sent from Y User A.
  • a link notification message 2462 for notifying that the accounts are linked and payment has been made from the linked account is displayed.
  • FIG. 9-4 is displayed on the display unit 24 of the terminal 20 of A, information regarding payment is transmitted from the payment management server 10A to the messaging management server 10B, not by limitation, but via API as an example. Then, as an example, not limited to, the control unit of the messaging management server 10B generates a cooperation notification message 2462, and the message is automatically transmitted to each terminal to which the account is linked.
  • this cooperation notification message 2462 the characters [Payment App] are displayed in the upper row, and the characters “Wallet cooperation payment” are displayed below the chain mark. Below that, it is displayed that the payment amount per person is "500 yen”. Further, in the lower row, it is displayed that the payment destination is "AA Sports Co., Ltd.”, the payment amount is "5,000 yen", and the number of group members is "10". Below that, a detailed confirmation icon for confirming the detailed contents is displayed.
  • FIG. 9-7 shows the user X. Corresponding to FIG. 9-6. It is a figure which shows an example of the talk room screen displayed on the display part 24 of the terminal 20 of X, and is the figure which shows the user Y. The above cooperation notification message 2462 is displayed below the "Please! Message sent from Y.
  • the terminal 20 has a user account of a user of its own terminal 20 (an example of a first account, not a limitation) and a user account of another group member (an example of a second account, not a limitation).
  • the control unit 21 executes a process for associating the first account with the second account (not limited to the process of associating the first account with the second account).
  • the terminal 20 shows a configuration in which the control unit 21 executes a process related to payment based on the user account of the user of the linked own terminal 20 and the user account of another group member.
  • a first account that can be settled by the user of the terminal can be associated with a second account that is different from the first account. Then, payment based on the associated first account and the second account can be realized.
  • the user accounts of other group members to be linked are selected based on the selection of a group talk room (an example of a chat room, not limited).
  • the configuration is shown.
  • the second account can be selected by a simple method of selecting a chat room.
  • account linkage is performed by selecting a group talk room, but the present invention is not limited to this. As a matter of course, it is also possible to link user accounts between two users.
  • a and user B When making a payment by linking two user accounts with B, user A. In a payment application or a messaging application executed by A's own terminal 20, user B. Select B directly, your user account and user B. It may be linked with the user account of B. In this case, User A. User account of A and user B. The account-linked payment will be performed in cooperation with the user account of B.
  • the payment may be made by wireless communication (including short-range wireless communication) instead of the code payment.
  • the control unit 11 of the server 10 is not limited to the balance, but as an example.
  • Information indicating that there is a shortage is transmitted to the terminal 20 by communication I / F14.
  • the control unit 21 of the terminal 20 causes the display unit 24 to display the payment balance shortage information.
  • control unit 21 of the terminal 20 executes the account linkage process based on the input of the user of the terminal 20 for the displayed payment balance shortage information. Then, the user of the terminal 20 can make the account-linked payment by holding his / her terminal 20 over the card reader of the store again. As described above, it is also possible to link the accounts in advance. These are the same when applying Bluetooth communication.
  • the processing related to payment is performed by the communication I / F 22 of the terminal 20 with the store code reader device 50 (not limited, but an example of a terminal of a store that sells products or provides services to be purchased by payment). It shows the configuration executed by wireless communication. As an example of the effect obtained by such a configuration, the payment can be realized by wireless communication with the terminal of the store that sells the product or provides the service purchased by the first payment.
  • this modification shows a configuration in which the above wireless communication is short-range communication.
  • wireless communication with a terminal of a store that sells a product or provides a service purchased by the first settlement can be realized by short-range communication.
  • the account-linked payment described in the ninth embodiment can be set as a common account payment in which a common wallet is temporarily created and payment is made using the common wallet.
  • the methods described in the second to seventh embodiments may be applied to perform the settlement. That is, in this case, the contents described in the second to seventh embodiments described above can be applied in the same manner. Further, when discarding the common wallet, the contents described in the eighth embodiment can be applied in the same manner.
  • the tenth embodiment is an example relating to a combination (variation) of two accounts (first account and second account) in the various examples described above.
  • FIG. 10 is a diagram showing an example of a table for explaining a combination of the first account and the second account.
  • a pattern, a first account, and a second account are defined in association with each other. Each pattern will be described below.
  • Pattern A Pattern A is a pattern in which the first account is the "first common account (first common wallet)", and four patterns A1 to A4 are defined in which the second account is four types. ..
  • the first common account is a common wallet account (first account) that can be used by a plurality of users of the terminal 20 including the user of the own terminal 20.
  • Pattern A1 is a pattern in which the second account is "my user account (electronic money account)".
  • Pattern A2 is a pattern in which the second account is "another person's user account (electronic money account)”.
  • Pattern A3 is a pattern in which the second account is a “business account (business loan account)”. Businesses are, for example, not limited to businesses that are licensed to lend or lend money, including businesses that provide payment services (payment applications).
  • the operator account is the account of this operator's payment application.
  • the business loan account is an account for the business to lend and lend money to the user (user of the terminal 20).
  • the pattern A4 is a pattern in which the second account is a "second common account (second common wallet)".
  • the second common account is a common account (second common account) different from the first common account that can be used by users of a plurality of terminals 20 including the user of the own terminal 20.
  • Pattern B is a pattern in which the first account is "my first user account”, and four patterns, patterns B1 to pattern B4, in which the second account is four types are defined. Your first user account is your payment application account (first user account).
  • Pattern B1 is a pattern in which the second account is a "common account”.
  • Pattern B2 is a pattern in which the second account is a "user account of another person".
  • Pattern B3 is a pattern in which the second account is a "business account”.
  • Pattern B4 is a pattern in which the second account is set as "my second user account”. Your second user account is your payment application account (your second user account) that is different from your first user account.
  • Pattern C is a pattern in which the first account is the "first user account (other person A)", and four patterns of patterns C1 to C4 in which the second account is four types are defined.
  • the first user account (other person A) is an account of the payment application of another person A.
  • Pattern C1 is a pattern in which the second account is a "common account”.
  • Pattern C2 is a pattern in which the second account is "my user account”.
  • Pattern C3 is a pattern in which the second account is a "business account”.
  • the pattern C4 is a pattern in which the second account is a "second user account (another person A or another person B)".
  • the second user account (other person A or other person B) is an account of another person A's payment application (the second user account of another person A) different from the first user account of another person A, or an account of another person B's payment application. (The first user account of another person B).
  • Pattern D is a pattern in which the first account is the “first business account”, and four patterns D1 to D4 in which the second account is four types are defined.
  • the first business account is an account of the payment application of the first business (the first account of the first business).
  • Pattern D1 is a pattern in which the second account is "my user account”.
  • Pattern D2 is a pattern in which the second account is a "user account of another person".
  • Pattern D3 is a pattern in which the second account is a "common account”.
  • Pattern D4 is a pattern in which the second account is a "second business account".
  • the second business account is an account of the payment application of the first business (second account of the first business) different from the account of the first business, or an account of the payment application of the second business (second).
  • the first account of the business operator is a pattern in which the second account is a "second business account".
  • the second business account is an account of the payment application of the first business (second account of the first business) different from the account of the first business, or an account of the payment application of the second business (second).
  • the first account of the business operator is a pattern in which the second account is a "second business account”.
  • any one of the above patterns, pattern A (pattern A1 to pattern A4), pattern B1, pattern C1, and pattern D3, which are patterns including the common account, can be applied.
  • the methods of the second to eighth embodiments can be applied in the same manner to perform common account settlement.
  • any one of the above patterns which is a pattern that does not include a common account, pattern B2 to pattern B4, pattern C2 to pattern C4, and pattern D1, D2, D4 can be applied.
  • the method of the ninth embodiment can be similarly applied to perform account-linked payment.
  • any one of the patterns B2 to B4, the pattern C2 to the pattern C4, and the patterns D1, D2, and D4, which are patterns that do not include the common account, is carried out from the second embodiment to the eighth embodiment. It can also be applied to the example.
  • the second account is a business account (not a limitation, but an example of a business account), and the processing related to payment is executed by lending the shortage of the balance from this business account. By doing so, payment can be realized based on at least the account of the business operator. In addition, by having the account of the business operator lend the shortage of the balance, even if the balance is insufficient, it is possible to make an appropriate settlement.

Abstract

決済に関する処理を実行する端末に実行させるためのプログラムは、端末のユーザが決済可能な第１アカウントに基づいて第１決済に関する処理を端末の制御部によって実行することと、第１決済の金額と、第１アカウントの残高とに基づく、第１アカウントの残高が不足していることに関する第１情報を端末の表示領域に表示することと、第１情報が表示された表示領域に対する入力に基づいて、第１アカウントとは異なる第２アカウントに少なくとも基づいて、第１決済に関する処理を制御部によって実行することとが端末によって実行される。

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 (27)

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

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020227008972A KR20220122967A (ko) 2019-12-30 2019-12-30 프로그램, 정보 처리 방법 및 단말
CN201980100429.9A CN114402347A (zh) 2019-12-30 2019-12-30 程序、信息处理方法、终端
US17/698,674 US20220207516A1 (en) 2019-12-30 2022-03-18 Program, information processing method, and terminal

Applications Claiming Priority (2)

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

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/698,674 Continuation US20220207516A1 (en) 2019-12-30 2022-03-18 Program, information processing method, and terminal

Publications (1)

Publication Number Publication Date
WO2021137267A1 true WO2021137267A1 (ja) 2021-07-08

Family

ID=76687467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/051639 WO2021137267A1 (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 (4)

* 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 与信機能付きのプリペイド方式での決済システム
JP2016218861A (ja) * 2015-05-22 2016-12-22 大日本印刷株式会社 支払可否決定システム、携帯端末、装置およびそれらのプログラム
JP2018205979A (ja) * 2017-06-01 2018-12-27 株式会社野村総合研究所 端数資金振替蓄積システム
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 移動体電話機
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
WO2012135796A1 (en) * 2011-04-01 2012-10-04 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
SG11201601780UA (en) 2013-09-09 2016-04-28 Yodlee Inc Collaborative financial management
JP2017515248A (ja) 2014-04-16 2017-06-08 ニュークリアス ソフトウェア エクスポーツ リミテッド 無線デジタルウォレット実装の方法とシステム
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
US10970695B2 (en) * 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10956888B2 (en) * 2015-07-21 2021-03-23 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
JP6983261B2 (ja) * 2017-05-16 2021-12-17 アップル インコーポレイテッドApple Inc. ピアツーピア転送用ユーザインタフェース
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 创新先进技术有限公司 一种账户创建、账户充值、数据同步方法及设备
JP6919150B2 (ja) 2017-12-26 2021-08-18 株式会社 ゆうちょ銀行 情報処理装置、情報処理システム、情報処理方法、及び情報処理プログラム
US20200013028A1 (en) * 2018-07-09 2020-01-09 American Express Travel Related Services Company, Inc. Peer-to-peer money transfers

Patent Citations (4)

* 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 与信機能付きのプリペイド方式での決済システム
JP2016218861A (ja) * 2015-05-22 2016-12-22 大日本印刷株式会社 支払可否決定システム、携帯端末、装置およびそれらのプログラム
JP2018205979A (ja) * 2017-06-01 2018-12-27 株式会社野村総合研究所 端数資金振替蓄積システム
JP6585808B1 (ja) * 2018-12-21 2019-10-02 ＬＩＮＥ Ｐａｙ株式会社 生成方法、プログラム、情報処理装置

Also Published As

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

Similar Documents

Publication Publication Date Title
JP7460686B2 (ja) プログラム、情報処理方法、サーバ
WO2021084924A1 (ja) 端末、情報処理方法、プログラム
JP7354089B2 (ja) サーバ、プログラム、情報処理方法
JP6977127B1 (ja) プログラム、情報処理方法、端末、サーバ
JP2021192260A (ja) プログラム、情報処理方法、端末
JP7175877B2 (ja) プログラム、表示方法、端末
WO2022085579A1 (ja) プログラム、情報処理方法、端末、サーバ
JP7456986B2 (ja) プログラム、情報処理方法、端末
JP2022099174A (ja) プログラム、情報処理方法、端末、サーバ
JP7064046B1 (ja) アプリケーションプログラム、サービス提供システム、および端末装置
JP7250186B2 (ja) サーバ、プログラム、情報処理方法
JP7405930B2 (ja) プログラム、情報処理方法、端末
JP7287243B2 (ja) ウォレットシステムおよびウォレットプログラム
JP7034226B1 (ja) プログラム、情報処理方法、端末
JP7146866B2 (ja) プログラム、情報処理方法、端末
WO2022070453A1 (ja) プログラム、情報処理方法、端末、サーバ
JP7183217B2 (ja) プログラム、情報処理方法、端末
WO2022138448A1 (ja) プログラム、情報処理方法、端末、サーバ
JP7357591B2 (ja) プログラム、情報処理方法、端末
JP2023006759A (ja) プログラム、情報処理方法、情報処理装置
JP2023006758A (ja) プログラム、情報処理方法、サーバ
JP2023006760A (ja) プログラム、情報処理方法、サーバ

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19958604

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19958604

Country of ref document: EP

Kind code of ref document: A1