JP7598906B2 - Server, program, information processing method, and system - Google Patents

Description

This disclosure relates to programs, information processing methods, terminals, servers, etc.

Recently, services that allow terminals or terminal users to make payments using applications that can be executed on terminals such as smartphones are becoming more common. For example, Patent Literature 1 discloses a technology for making payments for the purchase amount of goods.

JP 2002-176671 A

According to a first aspect of the present invention, a program to be executed by a terminal includes a control unit of the terminal performing processing related to a first payment by the terminal of a first user based on a first account of a first user of the terminal and a second account associated with the first account, receiving first information related to transferring money to the second account based on the first payment by a communication unit of the terminal, and displaying a first display based on the first information on a display unit of the terminal.
According to a second aspect of the present invention, an information processing method for a terminal includes performing processing related to a first payment by a first user's terminal based on a first account of a first user of the terminal and a second account associated with the first account, receiving first information related to transferring money to the second account based on the first payment by a communication unit of the terminal, and displaying a first display based on the first information on a display unit of the terminal.
According to a third aspect of the present invention, the terminal comprises a control unit that performs processing related to a first payment by the terminal of a first user based on a first account of a first user of the terminal and a second account associated with the first account, a communication unit that receives first information related to transferring money to the second account based on the first payment, and a display unit that displays a first display based on the first information.
According to a fourth aspect of the present invention, the terminal includes a processor that reads a program from a memory and executes processing based on the program, and the processor executes the following: performing processing related to a first payment by the terminal of a first user based on a first account of a first user of the terminal and a second account associated with the first account; receiving first information related to transferring money to the second account based on the first payment by a communication unit of the terminal; and displaying a first display based on the first information on a display unit of the terminal.
According to a fifth aspect of the present invention, a server that communicates with a terminal and performs processing related to payments includes a control unit that performs processing related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account, and a communication unit that transmits first information to the terminal regarding transferring money to the second account based on the first payment, and the control unit performs processing related to transferring an amount based on the first information from the first account to the second account based on input by the first user to a first display based on the first information displayed on the terminal.

FIG. 1 is a diagram showing an example of a system configuration of a communication system according to a first embodiment. FIG. 4 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of information stored in a storage unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of account registration data according to the first embodiment. FIG. 4 is a diagram showing an example of a data configuration of an account management database according to the first embodiment. A figure showing an example of the data configuration of a first linked wallet management database, which is an example of the linked wallet management database related to the first embodiment. FIG. 4 is a diagram showing an example of functions realized by a control unit of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. 4 is a flowchart showing an example of a flow of processes executed by each device according to the first embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a first modified example. 10 is a flowchart showing an example of a flow of processes executed by each device according to a first modified example. FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second embodiment. 10 is a flowchart showing an example of a flow of processes executed by each device according to the second embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. 13 is a flowchart showing an example of a flow of a process executed by each device according to the third embodiment. 13 is a flowchart showing an example of a flow of processes executed by each device according to the third embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. 13 is a flowchart showing an example of a flow of processes executed by each device according to a third modified example. 13 is a flowchart showing an example of a flow of processes executed by each device according to a third modified example. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. 13 is a flowchart showing an example of a flow of processes executed by each device according to a third modified example. FIG. 13 is a diagram showing an example of information stored in a storage unit of a server according to the fourth embodiment. FIG. 13 is a diagram showing an example of a data configuration of a group management database according to the fourth embodiment. A figure showing an example of the data configuration of a second linked wallet management database, which is an example of an linked wallet management database related to the fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth modified example. 13 is a flowchart showing an example of a flow of processes executed by each device according to a fourth modified example. 13 is a flowchart showing an example of a flow of processes executed by each device according to a fourth modified example. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. FIG. 13 is a diagram showing an example of a system configuration of a communication system according to a sixth embodiment. FIG. 13 is a diagram showing an example of the functional configuration of a store POS system according to a sixth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a sixth embodiment. 23 is a flowchart showing an example of the flow of a process executed by each device according to the sixth embodiment. A figure showing an example of the data configuration of a third linked wallet management database, which is an example of a linked wallet management database related to the seventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to the seventh embodiment. 23 is a flowchart showing an example of the flow of a process executed by each device according to the seventh embodiment. 23 is a flowchart showing an example of the flow of a process executed by each device according to the seventh embodiment. 23 is a flowchart showing an example of the flow of an associated wallet settlement process according to the seventh embodiment. FIG. 23 is a diagram showing an example of information stored in a storage unit of a server according to the eighth embodiment. FIG. 23 is a diagram showing an example of the data configuration of a common wallet management database according to the eighth embodiment. A figure showing an example of the data configuration of a fourth linked wallet management database, which is an example of an linked wallet management database related to the eighth embodiment. FIG. 23 is a diagram showing an example of a table regarding the burden ratios of cooperation members in the ninth embodiment. A figure showing an example of the data configuration of a fifth linked wallet management database, which is an example of a linked wallet management database related to the tenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a tenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a tenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the tenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the tenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an eleventh modified example. A figure showing an example of the data configuration of a sixth linked wallet management database, which is an example of an linked wallet management database related to the twelfth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a twelfth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a twelfth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the twelfth embodiment; A figure showing an example of the data configuration of the seventh linked wallet management database, which is an example of the linked wallet management database related to the thirteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a thirteenth embodiment FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a thirteenth embodiment 23 is a flowchart showing an example of the flow of processes executed by each device according to the thirteenth embodiment; A figure showing an example of the data configuration of the eighth linked wallet management database, which is an example of the linked wallet management database related to the fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the fourteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the fourteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the fourteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to a fourteenth modified example. 23 is a flowchart showing an example of the flow of processes executed by each device according to a fourteenth modified example. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourteenth modified example. 23 is a flowchart showing an example of the flow of processes executed by each device according to a fourteenth modified example. A figure showing an example of the data configuration of the ninth linked wallet management database, which is an example of the linked wallet management database related to the fifteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifteenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the fifteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the fifteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the fifteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to a fifteenth modified example. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a sixteenth embodiment. FIG. 23 is a diagram showing an example of an account management database according to the seventeenth embodiment. A figure showing an example of an associated wallet management database related to the 17th embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a seventeenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the seventeenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the seventeenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to a seventeenth modified example. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a seventeenth modified example. A figure showing an example of an associated wallet management database related to the 18th embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an 18th embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an 18th embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an 18th embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an 18th embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the eighteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the eighteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the eighteenth embodiment; 23 is a flowchart showing an example of the flow of processes executed by each device according to the eighteenth embodiment; FIG. 23 is a diagram showing an example of a timing chart according to the eighteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to an 18th modified example. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a nineteenth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a nineteenth embodiment. 23 is a flowchart showing an example of the flow of processes executed by each device according to the nineteenth embodiment; FIG. 26 is a diagram showing an example of a screen displayed on a display unit of a terminal according to the twentieth embodiment. 20 is a flowchart showing an example of the flow of processes executed by each device according to the twentieth embodiment. 20 is a flowchart showing an example of the flow of processes executed by each device according to the twentieth embodiment. FIG. 23 is a diagram showing an example of a timing chart according to the twentieth embodiment. FIG. 23 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a twentieth modified example.

<Compliance with legal matters>
It should be noted that the disclosures described herein are subject to compliance with the laws of the country of implementation, such as communications secrecy, as necessary for the implementation of the disclosure.

An embodiment for implementing the program etc. related to this disclosure will be described with reference to the drawings.

＜Overview＞
In recent years, applications (application software) related to network services, such as applications for making payments and settlements using electronic currency (payment applications/settlement applications), applications for sending/receiving remittances using electronic currency (remittance applications), and applications that combine some or all of the functions of these applications, have become widespread, and terminal users are now able to use these applications to receive a variety of services related to electronic currency.

"Electronic currency" means electronic currency that is distinct from physical currency and that is owned by a terminal managed in the various applications mentioned above or by a user of the terminal.

In addition, electronic currency may or may not be expressed as "electronic money" or "digital currency (digital currency)."
Furthermore, as "electronic currency (electronic money)" or "digital currency (digital money)", legal tender currency or virtual currency may be used.
In addition, "electronic currency (electronic money)" and "digital currency (digital money)" may include cryptocurrency (crypto assets).
Virtual currency may also include physical currency such as coupons.

In this specification, the expression "through a communication I/F" is used where appropriate. This indicates, by way of example and not limitation, that the device transmits and receives various types of information and data through the communication I/F (through a communication unit) based on the control of a control unit (such as a processor).

In addition, in this specification, "payment" means electronic payment. One example of this is electronic payment using electronic currency.

In addition, in this specification, "code information" includes a code image, information stored in a code image by encoding or the like (stored information), and information to be stored (information to be stored). Examples of stored information and information to be stored include, but are not limited to, tokens, which will be described in detail below.

In addition, in this specification, the following is an example of a code payment, which is a payment method using a code (code information), and is not limited to the above:
Two types of payment methods are shown below: (1) Customer-presented type and (2) Store-presented type.

The customer-presented type is a method in which, for example and not limitation, the user (user of the terminal) presents a payment code displayed on the display unit of the terminal to a store clerk or other person at a store (for example and not limitation, an affiliated store) and has the code read by a code reader in a store code reader device, thereby making a payment.
The store-presented type is a method in which a user makes a payment by reading a payment store code presented or posted in a store (by way of example and not limitation, an affiliated store) using the terminal's camera or code reader (including a code reader in the payment application).

In the following, the customer-presented code displayed on the display unit of the terminal will be referred to as a "payment code," but it may alternatively be referred to as a "customer-presented code," etc.
In the following description, the code that is read by the terminal in a store-presented payment method is referred to as a "payment store code," but it may alternatively be referred to as a "store-presented code," etc.

In this specification, by way of example and not by way of limitation, the store presented type is mainly described.
However, the present invention is similarly applicable to a user-presented type, and an embodiment of the user-presented type will be described later.

Also referred to herein as account-based payments, by way of example and not by way of limitation,
Two types of payment are shown as examples: (A) account linkage payment and (B) common account payment.

An "account" refers, by way of example and not limitation, to an account for an application (such as a payment application, messaging application, etc.) used by a user to make payments, settlements, etc. using electronic currency.

(A) Account Linking Payment Account linking payment is a method of making payments by linking multiple accounts. Account linking means associating multiple accounts so that they can be used for payments.
This association may be made on a data basis (on data managed by a terminal or a server) so that multiple accounts are associated with each other to enable account linked payment.

Linking accounts is referred to as "account linking," and payment using account linking is referred to as "account linking payment."
In this case, multiple accounts of one user may be linked, or multiple accounts of multiple users may be linked. In other words, other people's accounts are not necessarily required for linking, and as a non-limiting example, multiple of one's own accounts may be linked.

In order to realize account linking payment, as an example and not a limitation, multiple accounts are linked and then, as an example and not a limitation, a process (account linking process) is executed in which the payment is set up so that payment is equally divided (or split evenly) from each of the linked accounts.
Account linking payment can also be considered as a payment made by a user using a different account (either another of their own or someone else's account) in addition to their own account.
Note that account linking may be expressed as wallet linking, and account linking payment may be expressed as wallet linking payment.

The following describes, as an example only, an embodiment in which multiple users, such as friends or colleagues, make payments together for purchases, etc.

By way of example and not limitation, account linking can be performed either (A-1) before making a payment or (A-2) when making a payment.
(A-1) Before making a payment, by way of example and not limitation, it can be applied in cases where subsequent settlement is troublesome.
(A-2) When making a payment, for example and not by way of limitation, this can be applied when the balance of the account set as the account to be used for settlement at the time of payment (for example and not by way of limitation, one's own account) is insufficient. In this case, for example and not by way of limitation, the payment can be made by linking the account with another user's account.

(B) Common Account Payment Common account payment is a method of making payments based on an account that can be used in common by multiple users (hereinafter referred to as a "common account"). This type of payment is called "common account payment." Common account payment is realized by using a common wallet. A "common wallet" is a form of electronic money account set up by multiple users, and constitutes a single virtual wallet.
Common account payment can also be considered as payment in which a user uses an account (one common account) that is common to multiple users.
In addition, common account payment may also be expressed as common wallet payment.

By way of example and not limitation, shared account payment refers to payments being made from a single account that is intended to be used by multiple users.

In a first form, the common account can be an account linked to each user (member) who uses the common wallet.
In a second form, the common account can be an account associated with a specific user among users who use the common wallet. The specific user can be, by way of example and not limitation, a user who is a representative or master of the common wallet (hereinafter collectively referred to as a "common account master user"). The common account master user can be, by way of example and not limitation, a user who created the common account.

Regardless of whether the first or second form is applied, by way of example and not by way of limitation, each user of a common account may be able to freely use the common wallet. By way of example and not by way of limitation, the user may be able to freely check information such as the balance of the common wallet, and freely deposit money into/withdraw money from the common wallet, etc.

In addition, when applying the second embodiment, by way of example and not limitation, it is also possible to restrict the use of the common wallet by users other than the common account master user.
Specifically, some or all of the functions of the common wallet may be made unavailable, and approval of the common account master user may or may not be required when some or all of the functions of the common wallet are used.

In shared account payments, a common account is used for multiple users, so if one user makes a payment in advance for another user, a post-payment settlement process may be required. In other words, at some point after the payment is completed, it may be necessary to adjust the amounts for each user, such as during remittance/receive processes.

In contrast, with account linked payments, permission is obtained from the user of the linked accounts in advance, or permission is obtained on the spot, and then the amount is consumed from each account, essentially eliminating the need for subsequent settlement processing.
However, even with account linkage payment, there are cases where a post-account settlement is required, which will be described later in the embodiment.

In light of the above, this specification will mainly explain an example in which (A) "account linked payment" is applied, as an example and not a limitation.

Note that "linking" includes the meaning of doing something together for one purpose. Therefore, in the sense of multiple users making a payment together, by way of example and not limitation, account linked payment and common account payment can be considered to have the same purpose.

In the following, it will be explained that various processes according to the present invention are performed by applications (such as a payment application or messaging application) installed on the terminal.

It is also possible for a payment application to have a chat service function (for example, but not limited to, a messaging service) as one of its functions, or for a chat application (for example, but not limited to, a messaging application) to have a payment service function as one of its functions.

The messaging service is configured to allow users to chat using chat rooms.
In the following description, a UI (User Interface) or GUI (Graphical User Interface) that allows each user to view content transmitted and received between terminals of multiple users is referred to as a "talk room" as appropriate. A talk room may also be referred to as a chat room.

In addition to messages containing simple text and emoticons, the content can include various types of information that can be sent and received between terminals, such as, but not limited to, image information (including still images, moving images, etc.), operation information (including buttons, icons, etc.), communication information and link information (including URIs, URLs, etc.).

Note that, by way of example and not limitation, talk rooms can include one-to-one user talk rooms as well as talk rooms for groups that include multiple users (group talk rooms). In this case, a talk room refers to a UI or GUI that allows users in a group to view content sent and received between each terminal of a group that includes multiple users.

The messaging service may or may not include an instant messaging service (IMS), which allows terminals to send and receive content such as simple messages.

There is also a view that considers messaging services (MS) (including IMS) as one form of social networking services (SNS).
Therefore, a distinction may or may not be made between a messaging service (MS) and a social networking service (SNS).

In the following, as an example of an input to a terminal, an operational input by a user of the terminal (as an example and not a limitation, an input by tapping (tapping operation)) is mainly given, but is not limited to this.
Instead of or in addition to the operation input, sound input (including voice input) may or may not be input to the terminal.

In this specification, "payment-related processing" performed by the terminal means processing that is directly or indirectly related to payment, such as, but not limited to, processing that is directly or indirectly related to the above-mentioned (A) account linkage payment and (B) shared account payment.
Specifically, by way of example and not limitation, this includes processes that are somehow related to making a payment, such as a process of obtaining code information for making a payment from a server (including a process of requesting the server to generate code information and a process of receiving the generated code information from the server), a process of displaying the obtained code information, a process of requesting the server to make a payment, a process of obtaining the payment result (including a payment completion notification, etc.) from the server, and more specifically, all processes executed on the terminal as processes related to making a payment.

In addition, in this specification, "payment-related processing" performed by the server also means processing that is directly or indirectly related to payment, and by way of example and not limitation, processing that is directly or indirectly related to the above-mentioned (A) account linkage payment and (B) common account payment.
Specifically, by way of example and not limitation, this includes processes that are somehow related to making a payment, such as a process for generating code information for making a payment, a process for sending the generated code information to a terminal, a payment process (a process for making a payment), and a process for sending a payment result (including a payment completion notification, etc.) to a terminal, and more specifically, all processes executed on a server as processes related to making a payment.

The same applies to other terms that start with "related to." In other words, "related to" is a concept that includes things that are directly or indirectly related.

In the following, systems including at least a terminal and a server (as examples, but not limited to, communication system 1A and communication system 1B) will be illustrated.
However, the system is not limited to the system described below. As an example and not a limitation, a system of any of the following patterns can be configured.
(1) Terminal & Server (2) Server (3) Terminal

(1) is, by way of example and not limitation, a system including at least one terminal and at least one server. A typical example of this is a server-client system.
In this case, the control unit of the system can be at least one of the control unit of the terminal and the control unit of the server. That is, by way of example and not limitation, the control unit of the system can be any of the following: (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server.

In addition, the control and processing (hereinafter collectively referred to as "control, etc.") performed by the control unit of the system may be (1A) performed only by the control unit of the terminal, (1B) performed only by the control unit of the server, or (1C) performed by both the control unit of the terminal and the control unit of the server.
In addition, in (1C), by way of example and not limitation, some of the controls etc. performed by the system's control unit can be performed by the control unit of the terminal, and the remaining controls etc. can be performed by the control unit of the server.

(2) can be, by way of example and not limitation, a system made up of multiple servers. Because it is a system made up of multiple servers, it may be called a "server system."

(3) By way of example and not limitation, the system may be comprised of multiple terminals.
A system that does not include a server and is configured by a terminal may be, by way of example and not by way of limitation, a system as follows.
A system that provides server functions to terminals (distributed system). This can be realized, for example and without limitation, by using blockchain technology.
A system in which terminals communicate wirelessly with each other. This can be realized, for example and without limitation, by communicating in a peer-to-peer (P2P) manner using short-range wireless communication technology such as Bluetooth.

The above is not limited to the control unit, but also applies to each functional unit such as the input/output unit, communication unit, memory unit, clock unit, etc., which may be components of the system.

First Example
The first embodiment is a basic embodiment for realizing the above-mentioned (A) account linkage payment.
When making an account linking payment, it is possible that some or all of the accounts participating in the account linking payment will be required to pay the amount.
However, in this case, by way of example and not limitation, there may be cases where an account linked payment cannot be made due to insufficient balance in one of the linked accounts.

In the following, the concept of a "linked wallet" is introduced as data for realizing account linked payment and managed by the server 10. A request to create (generate) a linked wallet is made by a user (user account) of the terminal 20, and linked wallet data is generated by the server 10, making it possible to perform account linked payment.
In addition, linking multiple accounts to realize account linking payments is referred to as "account linking" or "wallet linking."

The contents described in the first embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

First, as an example of account linking, a case where a plurality of accounts of one user are linked will be described. In this embodiment, as an example and not a limitation, a case where two accounts of user A.A are linked will be described.
As an example, a case where the server 10 executes an account linking process will be described.

It is also possible to link the accounts of multiple users, as will be described in more detail later.
In addition, although details will be described later, it is also possible for the terminal 20 to execute the account linking process.

<System Configuration>
FIG. 1A is a diagram showing an example of a system configuration of a communication system 1A according to the present embodiment.
In the communication system 1A, as an example and not a limitation, a server 10 and one or more terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ) are connected via a network 30.

The server 10 has a function of providing, by way of example and not limitation, a payment service and a messaging service to the terminal 20 owned by the user via the network 30. The server 10 can also be expressed as a payment service server, a payment management server, a settlement service server, a settlement management server, a messaging server, a messaging service server, etc. In this embodiment, by way of example and not limitation, the user of the server 10 is a payment service provider or a messaging service provider.
The number of servers 10 and the number of terminals 20 connected to the network 30 are not limited.

The terminal 20 (terminal 20A, terminal 20B, terminal 20C, ...) may be any information processing terminal capable of implementing the functions described in each embodiment. Examples of the terminal 20 include, but are not limited to, a smartphone, a mobile phone (feature phone), a computer (such as, but not limited to, a desktop, laptop, tablet, etc.), a media computer platform (such as, but not limited to, a cable or satellite set-top box, a digital video recorder), a handheld computer device (such as, but not limited to, a PDA (personal digital assistant), an email client, etc.), a wearable device (such as, but not limited to, a glasses-type device, a watch-type device, etc.), a VR (Virtual Reality) terminal, a smart speaker (a device for voice recognition), or other types of computers or communication platforms. The terminal 20 may also be expressed as an information processing terminal.

The configurations of the terminals 20A, 20B, and 20C can be the same as one another, for example and not for limitation. In addition, if necessary, the terminal used by the user X may be expressed as the terminal 20X, and the user information in a predetermined service associated with the user X or the terminal 20X may or may not be expressed as the user information X.
The user information is information of a user associated with an account used by the user in a specific service. The user information includes, but is not limited to, information associated with a user, such as the user's name, the user's icon image, the user's age, the user's sex, the user's address, the user's hobbies and interests, and the user's identifier, which is input by the user or given by a specific service, and may be any one of these, or a combination of these, or may not be the same.

The network 30 serves to connect one or more terminals 20 and one or more servers 10. In other words, the network 30 refers to a communication network that provides a connection path so that the above-mentioned various devices can connect and then send and receive data.

One or more portions of network 30 may or may not be wired or wireless. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular network, integrated service digital networks (ISDN), wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth, satellite communications, or the like, or a combination of two or more thereof. Network 30 may include one or more networks 30.

The server 10 (not limited to, but an example of a server, information processing device, or information management device) has a function of providing a predetermined service (a payment service in this embodiment) to the terminal 20. The server 10 may be any device that is an information processing device that can realize the functions described in each embodiment. The server 10 includes, not limited to, but an example of a server device, a computer (not limited to, but an example of a desktop, laptop, tablet, etc.), a media computer platform (not limited to, but an example of a cable or satellite set-top box, digital video recorder, etc.), a handheld computer device (not limited to, but an example of a PDA, email client, etc.), or other types of computers or communication platforms. The server 10 may also be expressed as an information processing device. When there is no need 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.

[Hardware (HW) configuration of each device]
The HW configuration of each device included in the communication system 1A will be described.

(1) Terminal Hardware Configuration FIG. 1A shows an example of the hardware 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 clock unit 29A, and a position calculation information detection unit 29B. The HW components of the terminal 20 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW configuration of the terminal 20 includes all of the components. For example and not for limitation, the terminal 20 may or may not be configured such that individual components or multiple components are removable.

The communication I/F 22 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 22 has a function of performing 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 instructions from the control unit 21. The communication I/F 22 also receives various data transmitted from various devices such as the server 10 and transmits it to the control unit 21. The communication I/F 22 may also be simply referred to as a communication unit. When the communication I/F 22 is configured with a physically structured circuit, it may also be referred to as a communication circuit.

The input/output unit 23 includes a device for inputting various operations to the terminal 20, a device for outputting the results of processing performed by the terminal 20, etc. The input/output unit 23 may be an integrated input unit and an output unit, or may be separate input unit and output unit, or it may not be the case.

The input unit is realized by any one or combination of any type of device that can accept input from a user and transmit information related to the input to the control unit 21. Examples of the input unit include, but are not limited to, a touch panel, a touch display, hardware keys such as a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input by voice).

The output unit is realized by any one or a combination of any type of device capable of outputting the results of processing by the control unit 21. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (audio output), a lens (for example, but not limited to, 3D (three dimensions) output or hologram output), a printer, etc.

By way of example only, the input/output unit 23 includes, by way of example and not limitation, a display unit 24, a sound input unit 25, a sound output unit 26, and an imaging unit 27.

The display unit 24 is realized by any one of all types of devices or a combination thereof that can display according to the display data written to the frame buffer. Examples of the display unit 24 include, but are not limited to, touch panels, touch displays, monitors (for example, but not limited to, liquid crystal displays and organic electroluminescence displays (OELDs)), head mounted displays (HDMs), projection mapping, holograms, devices that can display images, text information, etc. in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.

The sound input unit 25 is used to input sound data (including voice data; the same applies below). The sound input unit 25 includes a microphone and the like.
The sound output unit 26 is used to output sound data and includes a speaker and the like.
The imaging unit 27 is used to obtain image data (including still image data and moving image data; the same applies below). The imaging unit 27 includes a camera and the like.

If the input/output unit 23 is a touch panel, the input/output unit 23 and the display unit 24 may be arranged facing each other and have approximately 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 and not limitation, a clock that uses a quartz oscillator. The clock unit 29A can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

The clock unit 29A may or may not have a clock that conforms to the NITZ (Network Identity and Time Zone) standard or the like.

The position calculation information detection unit 29B is a functional unit that detects (measures) information (hereinafter referred to as "position calculation information") necessary for the control unit 21 to calculate (measure) the position of its own terminal 20. The position calculation information detection unit 29B can also be expressed as a position calculation sensor unit, for example and not by way of limitation.

The position calculation information detection unit 29B includes, by way of example and not limitation, a satellite positioning sensor (satellite positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System), an inertial measurement sensor (inertial measurement unit (IMU (Inertial Measurement Unit))) which is a sensor or unit for calculating the position of the terminal 20 using an inertial navigation system, a UWB positioning sensor (UWB positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using UWB (Ultra Wide Band), etc.

The satellite positioning unit includes, by way of example and not limitation, an RF receiving circuit that converts RF (Radio Frequency) signals, including positioning satellite signals transmitted from positioning satellites and received by an antenna (not shown), into digital signals, and a baseband processing circuit that performs correlation calculation processing or the like on the digital signals output from the RF receiving circuit to capture the positioning satellite signals, and outputs information such as satellite orbit data and time data extracted from the positioning satellite signals as information for position calculation.

The inertial measurement unit has an inertial sensor that detects information required to calculate the position of the terminal 20 by inertial navigation calculation. Examples of inertial sensors include, but are not limited to, a three-axis acceleration sensor and a three-axis gyro sensor, and output the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as information for position calculation.

The UWB positioning unit includes, by way of example and not limitation, an ultra-wideband RF (Radio Frequency) receiving circuit that converts an ultra-wideband RF signal, including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon and received by an antenna not shown, into a digital signal, and a relative position calculation processing circuit that calculates the relative position between the terminal 20 and the positioning beacon based on the digital signal output from the ultra-wideband RF receiving circuit.
As an example and not by way of limitation, the UWB positioning unit may or may not cause the terminal 20 to function as a positioning beacon by transmitting an ultra-wideband RF signal including an ultra-wideband pulse signal for positioning from an antenna not shown.

By way of example and not limitation, the control unit 21 calculates the position of its own terminal 20 at regular or specific timings based on the position calculation information detected by the position calculation information detection unit 29B. The terminal position is referred to as the "terminal position", and the calculated terminal position is referred to as the "calculated terminal position". The control unit 21 may, but may not, associate the calculated terminal position with the date and time when the calculated terminal position is calculated and store it in the storage unit 28 as calculated terminal position history data.

The control unit 21 has circuitry that is physically structured to execute functions realized by the code or instructions contained in the program, and is realized by, for example and not by way of limitation, a data processing device built into hardware. As such, the control unit 21 may or may not be described as a control circuit.

The control unit 21 may include, by way of example and not limitation, a central processing unit (CPU), a microprocessor, a processor core, a multiprocessor, an application-specific integrated circuit (ASIC), and a field programmable gate array (FPGA).

The storage unit 28 has a function of storing various programs and various data required for the operation of the terminal 20. The storage unit 28 includes, by way of example and not limitation, various storage media such as a hard disk drive (HDD), a solid state drive (SSD), a flash memory, a random access memory (RAM), and a read only memory (ROM). In addition, the storage unit 28 may or may not be expressed as a memory.

The terminal 20 stores the program P in the memory unit 28, and by executing this program P, the control unit 21 executes the processing of each unit included in the control unit 21. In other words, the program P stored in the memory unit 28 causes the terminal 20 to realize each function executed by the control unit 21. Furthermore, this program P may or may not be expressed as a program module.

(2) HW Configuration of Server FIG. 1A shows an example of the HW configuration of the server 10. As shown in FIG.
The server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I/F 14 (interface), an input/output unit 12, and a clock unit 19. The components of the HW of the server 10 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW of the server 10 includes all components as the configuration of the HW of the server 10. For example and not for limitation, the HW of the server 10 may or may not be configured such that individual components or multiple components are removable.

The control unit 11 has circuitry that is physically structured to execute functions realized by the code or instructions contained in the program, and is realized, for example and not by way of limitation, by a data processing device built into hardware.

The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA, or may not be such a unit. In this 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 operation of the server 10. The storage unit 15 is realized by various storage media such as a HDD, SSD, and flash memory. However, in this disclosure, the storage unit 15 is not limited to these. Furthermore, the storage unit 15 may or may not be expressed as a memory.

The communication I/F 14 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I/F 14 has a function of communicating with various devices such as the terminal 20 via the network 30. The communication I/F 14 transmits various data to various devices such as the terminal 20 according to instructions from the control unit 11. The communication I/F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits it to the control unit 11. The communication I/F 14 may also be simply referred to as a communication unit. When the communication I/F 14 is composed of a physically structured circuit, it may also be referred to as a communication circuit.

The input/output unit 12 includes a device for inputting various operations to the server 10, a device for outputting the results of processing performed by the server 10, and the like. The input/output unit 12 may be an integrated input unit and an output unit, or may be separate input unit and output unit, or it may not be the case.

The input unit is realized by any one or combination of all types of devices that can accept input from a user and transmit information related to the input to the control unit 11. The input unit is typically realized by hardware keys such as a keyboard, or a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via video images), or a microphone (operation input by voice), but is not limited to these.

The output unit is realized by any one or a combination of any type of device capable of outputting the results of processing by the control unit 11. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (sound output), a lens (for example, but not limited to, 3D (three dimensions) output or hologram output), a printer, etc.

By way of example only, the input/output unit 12 is provided with a display unit 13, by way of example and not limitation.

The display unit 13 is realized by a display or the like. The display is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OELD)). The display may or may not be a head mounted display (HDM) or the like. These displays may or may not be capable of displaying display data in 3D. In the present disclosure, displays are 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 and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

(3) Others The server 10 stores the program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processes of each unit included in the control unit 11. In other words, 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.

In each embodiment of the present disclosure, the description will be given assuming that the CPU of the terminal 20 and/or the server 10 executes the program P to realize the present invention.
The same applies to other devices.

The control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 may or may not realize each process by a CPU having a control circuit, but may also realize each process by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or a dedicated circuit. These circuits may or may not be realized by one or more integrated circuits, and the multiple processes shown in each embodiment may or may not be realized by one integrated circuit. Furthermore, LSIs may be called VLSIs, super LSIs, ultra LSIs, etc. depending on 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.

In addition, the program P (which may be, for example and not by way of limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may or may not be provided in a state stored in a computer-readable storage medium. The storage medium is capable of storing the program P in a "non-transitory tangible medium." The program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the program P 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 a program P already recorded in a storage medium.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application specific IC (ASIC)), a hard disk drive (HDD), a hybrid hard drive (HHD), an optical disk, an optical disk drive (ODD), a magneto-optical disk, a magneto-optical drive, a floppy diskette, a floppy disk drive (FDD), a magnetic tape, a solid-state drive (SSD), a RAM drive, a secure digital card, or a drive, any other suitable storage medium, or a suitable combination of two or more thereof. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, as appropriate. It should be noted that the storage medium is not limited to these examples and may be any device or medium capable of storing the program P. Also, the storage medium may or may not be referred to as a memory.

The server 10 and/or the terminal 20 can realize the functions of the multiple functional units shown in each embodiment by reading out a program P stored in a storage medium and executing the read out program P.
The same applies to other devices.

Furthermore, the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium capable of transmitting a program (such as a communication network or broadcast waves). The server 10 and/or the terminal 20 executes the program P downloaded via the Internet or the like, by way of example and not of limitation, to realize the functions of the multiple functional units shown in each embodiment.
The same applies to other devices.

In addition, each embodiment of the present disclosure may be realized in the form of a data signal in which the program P is embodied by electronic transmission.
At least a part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing consisting of one or more computers.
At least a part or all of the processing in the terminal 20 may or may not be performed by the server 10. In this case, at least a part or all 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 or all of the processing in the server 10 may or may not be performed by the terminal 20. In this case, at least a part or all 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.
Unless explicitly stated, the judgment configuration in the embodiments of the present disclosure is not essential, and a specified process may or may not be executed when the judgment condition is satisfied, or a specified process may or may not be executed when the judgment condition is not satisfied.

The programs disclosed herein are implemented using, by way of example and not limitation, scripting languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), and markup languages such as HTML5.

[Functional configuration of each device]
(1) Server FIG. 1B is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
The control unit 11 includes, as a functional unit, a payment application management processing unit 111 for executing a payment application management process in accordance with a payment application management processing program 151 stored in the memory unit 15, by way of example and not limitation.

FIG. 1-3 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The memory unit 15 stores, by way of example and not limitation, a payment application management processing program 151 executed as a payment application management processing, account registration data 153, an account management database 155, and an associated wallet management database 157.

The account registration data 153 is registration data relating to the account of an application (a payment application in this example), and an example of the data configuration is shown in FIG. 1-4.
In the account registration data 153, for example and not by way of limitation, a user name, an application ID, 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 application, and as a non-limiting example, the name registered by the user of the terminal 20 when using the application is stored.

The application ID is information used to identify an application account, or the account itself.
This application ID is preferably a value unique to each account, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each account.
The application ID is information associated with the terminal 20 or the user of the terminal 20, and is an example of information related to the terminal or information related to the user of the terminal.

Other registration information may include, by way of example and not limitation, various types of information such as identification information for identifying the terminal 20, the telephone number (terminal telephone number) of the terminal 20, an email address (terminal email address), and authentication information such as passwords (login password, authentication password, etc.) used for various authentications in the application.

The identification information for identifying the terminal 20 may be, for example and not for limitation, a terminal ID (for example and not for limitation, an International Mobile Equipment Identity (IMEI)).
Furthermore, the identification information for identifying the user of the terminal 20 may be, for example and without limitation, an application ID. Note that a "user ID" may or may not be used instead of the application ID.

Furthermore, if the application allows only one account to be registered per terminal 20, then, as a non-limiting example, "identification information for identifying the terminal 20 = identification information for identifying the user of the terminal 20 = application ID" can be used.

Also, by way of example and not limitation, it may or may not be possible to assign multiple terminal IDs to one user ID.

Also, instead of various IDs such as application IDs, it is possible to apply a method of managing accounts using information such as terminal telephone numbers.
In this case, instead of storing ID information such as an application ID in the account registration data 153 , information such as a terminal telephone number can be stored in the account registration data 153 .

The account management database 155 is a database for managing the accounts stored in the account registration data 153, and an example of the data configuration of a first account management database 155A is shown in FIG. 1-5.
In the first account management database 155A, account management data is stored as management data for each application ID stored in the account registration data 153.

Each account management data includes, by way of example and not limitation, an application ID and an electronic money account balance.
The electronic money account balance is the balance of the electronic money account for that application ID (that account), and is, by way of example and not limitation, the balance stored and managed by the server 10. It may also be simply referred to as the "balance."

The associated wallet management database 157 is a database for managing the associated wallets described above, and an example of the data configuration of a first associated wallet management database 157A is shown in FIG. 1-6.
The first linked wallet management database 157A stores linked wallet management data as management data for each linked wallet.

Each linked wallet management data stores, by way of example and not limitation, a linked wallet ID, linked account data, and payment history data.

The linked wallet ID is, by way of example and not limitation, information used to identify the linked wallet used in account linked payments.

The associated wallet ID is preferably a unique value for each associated wallet, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each associated wallet.

The linked account data is data related to a user account (hereinafter referred to as a "linked account") that is linked to perform account linked payments, and by way of example and not limitation, the application ID corresponding to this linked account and the user name corresponding to this application ID are stored in association with each other.

In the following, users who participate in account linked payments will be referred to as "linked members," while user accounts that are linked to make account linked payments as described above will be referred to as "linked accounts."

Note that one user may own multiple user accounts, and may link multiple user accounts. For this reason, there is not necessarily a one-to-one correspondence between linked members and linked accounts.

In the example of Figure 1-6, in the linked wallet management data shown at the front, two application IDs, "U0001" and "U0005", are stored in the linked account data, but the user name corresponding to these application IDs is "A.A." In other words, in this example, the two accounts owned by user A.A are associated as linked accounts.

The payment history data is data on the history of payments made through account linking payments, and by way of example and not limitation, the transaction ID, store ID, store name, payment date and time, and payment amount are associated with each other and stored in chronological order.

The transaction ID is an ID serving as identification information for identifying the transaction in which the payment has been made.
This transaction ID is preferably a value unique for each transaction, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each transaction.

The store ID is identification information for identifying the store where the transaction was made.
This store ID is preferably a value unique to each store, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each affiliated store.

The store name stores the name of the store where the transaction was made. The store name information can be stored and managed by the server 10 in association with the store ID using data not shown.

As a non-limiting example, the date and time of payment is stored as the date and time when the server 10 performed the payment process for the transaction.

The payment amount is, by way of example and not limitation, the amount settled by the server 10 for the transaction. This payment amount means the amount settled by the server 10 (the amount that has already been settled).

(2) Terminal FIG. 1-7 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The control unit 21 includes, as a functional unit, a payment application processing unit 211 for executing payment application processing in accordance with a payment application processing program 281 stored in the storage unit 28, for example and not by way of limitation.

FIG. 1-8 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment.
In the storage unit 28, for example and not limitation, a payment application processing program 281 executed as a payment application process and an application ID 283 of the own terminal 20 or the user of the own terminal 20 are stored.
It should be noted that the application ID 283 may or may not be able to store a plurality of application IDs.

<Display screen>
In the following, as an example and not a limitation, a case will be described in which the terminal 20 is a smartphone equipped with a display unit 24 having a portrait display.

For example, but not by way of limitation, a smartphone has a touch panel that functions as an input unit and is disposed opposite the display, thereby forming a touch screen. When an element such as an icon, button, item, or input area is displayed on the display, and a part of the touch panel that faces the area in which the element is displayed is operated by a user, a program associated with that element or a subroutine of that program is executed.

In the following, the operation by the user will be described as a tap (tap operation) as an example and not as a limitation.
A tap (tap operation) is, by way of example and not limitation, an action in which a user lightly touches the display unit 24 (touch screen) that is integrally configured with a touch panel with a finger or the tip of a pen, and then releases the touch.

Note that the display screen transitions described below are merely examples of display screen transitions for implementing the method of the present disclosure. In the display screen transitions illustrated below, the display of some display screens may be omitted, or other display screens may be added.

1-9 and 1-10 are diagrams showing an example of transition of screens displayed on the display unit 24 of the terminal 20 in this embodiment.
On the left side of FIG. 1-9 is, by way of example and not limitation, a main menu screen of a payment application displayed on the display 24 of the terminal 20A of user A.

The name of the payment application, "Payment App," is displayed in the center of the top of the menu screen. In addition, the icon image of the payment application and the user name of the user of this terminal 20 (user A.A. in this example) are displayed in the top right of the screen.

Below this is a current location display area CLR1 that shows the current location in the payment application. In this example, the words "Wallet Main Menu" are displayed in the current location display area, indicating that the current location is the main menu of the payment application.

When a linked wallet icon IC1, which includes text and an image of a linked wallet displayed at the bottom of the main menu screen, is tapped, linked wallet information for an account that links multiple user accounts of user A.A. is displayed, by way of example and not by way of limitation.

An example of a display screen for linked wallet information is shown in the center of Figure 1-9.
On this screen, the words "Linked Wallet" are displayed in current location display area CLR1, indicating that the linked wallet function is being used. Also, below current location display area CLR1, a code reader icon IC2 indicated with the words "Code Reader" for making a "store-presented" code payment using the linked wallet, and a code payment icon IC3 indicated with the words "Code Payment" for making a "customer-presented" code payment are displayed side by side.

Below these icons is the link wallet for A.A., which includes the user name of the linked wallet, and below that is the linked member information display area MIR1, which shows the status of the linked account for this linked wallet.

In the linked member information display area MIR1, each linked account and its linking status are displayed in association with each other on a line basis. As an example and not a limitation, "A.A main account" is the main user account of user A.A. (hereinafter referred to as "main account" as appropriate). As an example and not a limitation, the main account is a user account used when performing operations other than those related to the linked wallet on the main menu screen on the left side of FIG. 1-9. In this example, the electronic money account balance of the main account is shown to be "5,000 yen."

Also, by way of example and not limitation, "A.A. Subaccount" is a sub-user account of user A.A. (hereinafter referred to as "subaccount" where appropriate). A subaccount is a user account other than the main account owned by user A.A. In this example, the electronic money account balance of the subaccount is shown to be "3,000 yen."

As a non-limiting example, when the code reader icon IC2 on this screen is tapped (touched), linked wallet code reader information for making a payment using this linked wallet is sent from the server 10 to the terminal 20A. The control unit 21 of the terminal 20A then starts up a code reader (hereinafter referred to as the "application code reader") provided as a function of the code payment application in order to read the terminal reading code presented at the store with the terminal 20A.

An example of the application code reader screen is shown on the right side of Figure 1-9.
On this screen, the word "Code Reader" which is the currently executed function is displayed below the current position display area CLR1. Also, a code reading area CR1 for reading the payment store code is displayed in the center of the screen.

The left side of Figure 1-10 shows an example of a payment amount input screen that is displayed when information is obtained by decoding the payment store code read on the right side of Figure 1-9.

This payment amount input screen displays the name "XX Musical Instrument" along with an icon image of "XX Musical Instrument" to which the payment amount is to be sent. Below this is displayed a payment amount display area PR1 for displaying the input payment amount, with "4,500 yen" input and displayed here as the payment amount. Also displayed on the left end of the payment amount display area PR1 is an erase button indicated by a circled x for erasing the payment amount.
A keyboard for inputting the payment amount is displayed at the bottom of the screen, along with a payment button BT1 marked with the word "Pay" for making a payment with the payment amount entered in the payment amount display area PR1.

When the payment button BT1 for making a payment is tapped on the payment amount input screen shown on the left side of Figure 1-10, a code payment is made using the linked wallet.

When the code payment icon IC3 is tapped on the screen in the center of FIG. 1-9, a code payment screen is displayed on display unit 24 of terminal 20A. The code payment screen displays a one-dimensional payment code represented by a barcode, by way of example and not limitation, and a two-dimensional payment code represented by a QR code (registered trademark), by way of example and not limitation, as the linked wallet payment code, which is a code (code image) transmitted from server 10 and received by terminal 20 and used to make a "customer-presented" payment. User A.A of terminal 20A can also make a code payment using the linked wallet by presenting the code payment screen to a store clerk at the code register and having the payment code read by a store code reader device.

The center of Figure 1-10 shows the linked payment result display screen, which allows users to check the results of payments made using a linked wallet.

At the top of the linked payment result display screen, the words "Payment Completed" are displayed, indicating that the payment using the linked wallet has been completed, along with an icon image of "XX Musical Instrument," the recipient of the payment amount, its name "XX Musical Instrument," and the date and time of the payment, "2020-07-24/12:17:08."

Also, at the bottom of the linked payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of this payment for each linked account.
Member payment result display area MRR1 displays, for each linked account, the user account that made the payment, the amount paid by each user account, and the electronic money account balance after the payment.

By way of example and not limitation, in this embodiment, each linked account will pay an amount equal to the total payment amount divided equally between the linked accounts (the split amount).

However, unlike this, the ratio of payment amounts may or may not be different for each linked account. As a non-limiting example, the ratio of "main account:sub-account" may or may not be "2:1".

The right side of Figure 1-10 is an example of a screen that is displayed on the display unit 24 of terminal 20A after the screen in the center of Figure 1-10 is displayed. On this screen, a remittance promotion notification area RER1 is displayed, which is raised from the bottom of the linked payment result display screen and displays a message encouraging the user A.A. to transfer money from the main account selected on the main menu screen to the subaccount. This is an area that displays a message encouraging user A.A. to transfer money from the main account selected on the main menu screen to the subaccount, because a payment has been made to a subaccount that was not selected on the main menu screen as a result of the linked payment.

<Processing>
In the following, the "payment store code" used in store-presented code payment will be described, by way of example and not by way of limitation, as a code (one-dimensional code or two-dimensional code) that includes affiliated store identification information (a store ID uniquely assigned to an affiliated store, by way of example and not by way of limitation) for identifying the affiliated store.

The payment store code may or may not include information about a specific payment amount (for example, but not limited to, "500 yen").

FIG. 1-11 is a flowchart showing an example of the flow of the process executed by each device in this embodiment in this case.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

Here, as an example, a process will be described in which an account linking settlement is performed between a first user account of user A.A (as an example, not a limitation, an account with an application ID of "U0001") and a second user account of user A.A (as an example, not a limitation, an account with an application ID of "U0005") as linked accounts.
In reality, the number of user accounts linked in account linking payment is not limited to two, but the same applies when there are three or more accounts, so illustrations and explanations are omitted here.

Moreover, this process is merely an example of a process for implementing the technique of the present disclosure, and the present disclosure is not limited to this process. Another step may be added to this process, or some steps may be omitted (deleted) from this process.
This also applies to each of the flowcharts (processes) described below.

First, the control unit 11 of the server 10 generates, by way of example and not limitation, a payment token (hereinafter referred to as the "linked wallet payment token") that authorizes a payment using the balance of each account of an associated member linked to an associated wallet identified by an associated wallet ID, which is specified in advance based on user operation of terminal 20A.
By way of example and not limitation, the linked wallet payment token is identified by an integer value of a predetermined number of digits (by way of example and not limitation, 12 digits).
In addition, the linked wallet payment token may be a token with an expiration date that only grants authorization within a certain period of time from generation (for example, but not limited to, "5 minutes"), or it may not be such a token.

The control unit 11 of the server 10 then generates linked wallet code reader information, which is code reading information including the linked wallet payment token. The control unit 11 of the server 10 then transmits the generated linked wallet code reader information to the terminal 20A via the communication I/F 14 (S100).

When the control unit 21 of the terminal 20A receives linked wallet code reader information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display a code reader screen for reading the payment store code based on the received linked wallet code reader information. The control unit 21 of the terminal 20A also activates the imaging unit 27 to read the code. The control unit 21 of the terminal 20A then executes a code reading process to read the payment store code using the activated imaging unit 27 etc. (A100).

When the store ID is obtained from the payment store code read in the process of A100, the control unit 21 of the terminal 20A causes the display unit 24 to display a display screen for inputting the planned payment amount, by way of example and not limitation. When the planned payment amount is input based on a user operation on the input/output unit 23 of the terminal 20A, the control unit 21 transmits linked payment request information including, by way of example and not limitation, the linked wallet payment token contained in the linked wallet code reader information, the store ID, and the planned payment amount to the server 10 via the communication I/F 22 (A110).

When the communication I/F 14 receives the linked payment request information from the terminal 20A, the control unit 11 of the server 10 searches for the linked wallet ID from the requested linked wallet payment token, and executes a store-presented linked payment process, which is an example of a store-presented account linked payment process, in which the planned payment amount is paid to the affiliated store specified by the store ID into the linked wallet (S110).

In the store-presented linked payment process, first, the control unit 11 of the server 10 calculates, by way of example and not limitation, an amount obtained by dividing (equally splitting) the planned payment amount among the number of linked accounts (hereinafter referred to as "equal payment amount"). Then, the control unit 11 of the server 10 performs a payment process for each linked account stored in the linked account data of the linked wallet data, with the equal payment amount as the payment amount.

If the value of "electronic money account balance - equal payment amount" is equal to or greater than 0 for all linked accounts, a payment process for the equal payment amount is executed for each linked account, and the store-presented type linked payment process is successful.
On the other hand, if the value of "electronic money account balance - equal payment amount" is negative for any account, the payment process to the linked account is not performed and the store-presented linked payment process fails.

In addition, in the store-presented linked payment process, rather than executing equal payments from each linked account, the equal payments may be transferred from another account to a specified account of the linked accounts (for example, and not by way of limitation, the first user account of user A.A.), and then the planned payment amount may be paid from the specified account, or it may not be necessary to do so.

If the store-presented integrated payment process is successful, the control unit 11 of the server 10 sends, by way of example and not limitation, remittance request information prompting the transfer of money from the first user account to the second user account to the terminal 20A via the communication I/F 14 (S120).

By way of example, and not limitation, it is possible to imagine a case in which user A.A uses a first user account as a main account and a second user account as a sub-account, as described in the example display screen.
If the store-presented cooperative payment process is successful, the equal payment amount is also deducted from the electronic money account balance of the subaccount of user A.A., decreasing the balance. In such a case, server 10 can prompt user A.A. to transfer money from the first user account (main account) to the second user account (subaccount) to replenish the balance of the second user account.

If the settlement of the equal payment amount fails in the first user account or the second user account, or both (i.e., if the store-presented linked payment process fails), information prompting the user A.A to charge (remit) the account for which the settlement has failed may be transmitted as remittance request information from an account of an external financial institution registered in advance by the user A.A, but this is not essential.
In addition, for an account where a payment has failed, for example and not by way of limitation, information encouraging the account to obtain a loan or borrowing from an external financial institution or the like may or may not be sent as remittance request information.

Once the control unit 11 of the server 10 has sent the remittance request information, it ends the process.

When the remittance request information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the received remittance request information (A120). Then, the control unit 21 of the terminal 20A ends the process.

Effects of the First Embodiment
In this embodiment, the terminal 20 performs processing related to account linked payment (not limited to, an example of processing related to the first payment) through the control unit 21 based on a first user account (not limited to, an example of the first account) of a user of the terminal 20 (not limited to, an example of the first user of the terminal) and a second user account (not limited to, an example of the second account associated with the first account) linked to the first user account.
In addition, the terminal 20 receives remittance request information (not limited to, an example of first information regarding remittance to the second account) from the first user account to the second user account via the communication I/F 22 based on account linking settlement.
The terminal 20 is configured to display the received remittance request information (not limited to this, an example of the first display based on the first information) on the display unit 24 .
As an example of an effect of an embodiment obtained by such a configuration, it is possible to enable a first payment using at least two associated accounts by having a control unit of a first user's terminal perform processing related to a first payment based on a first account of the first user of the terminal and a second account associated with the first account.
Additionally, first information regarding the first payment being sent to the second account may be communicated to a first user of the terminal, such that, by way of example and not limitation, the first user may be prompted to send money to the second account.

Note that transferring money to a second account is a concept that includes not only transferring money to the second account, but also transferring money to multiple accounts (including the second account). Therefore, the first information regarding transferring money to a second account is a concept that includes information regarding transferring money to multiple accounts.

Also in this case, by way of example and not limitation, not only the first account but also the second account may be the first user's account, allowing payments to be made based on multiple accounts of a single user. Also, by way of example and not limitation, the first user may be prompted to transfer money to another account (the second account) of the first user.

In this embodiment, server 10 (not limited to this, but an example of a server that communicates with a terminal and performs processing related to a payment) executes a store-presented account linkage payment process (not limited to this, but an example of processing related to a first payment) using control unit 11 based on a first user account of the user of terminal 20 and a second user account linked with the first user account. Also, server 10 is configured to transmit remittance request information to terminal 20 via communication I/F 14 based on this account linkage payment.
As an example of an effect of an embodiment obtained by such a configuration, a first payment can be made using at least two associated accounts by having a control unit of the server perform processing related to the first payment based on a first account of a first user of the terminal and a second account associated with the first account.
Also, based on the first payment, first information regarding transferring funds to the second account may be communicated to a first user of the terminal, such that, by way of example and not limitation, the first user may be prompted to transfer funds to the second account.

<First Modification (1)>
In the first embodiment, the remittance request information was, but is not limited to, information encouraging a remittance from a first user account to a second user account, information encouraging a charge to the first user account or the second user account, or both, information encouraging a loan or borrowing, etc. By way of example and not of limitation, the remittance request information may be information including specific amounts of these.

<Display screen>
FIG. 1-12 is a screen diagram showing another example of FIG. 1-10.
The left side of FIG. 1-12 and the center of FIG. 1-12 are similar to FIG. 1-10.

On the right side of Figure 1-12, the remittance promotion notification area RER2 displays a notification to encourage user A.A. to remit money from the main account to the subaccount, as well as the recommended remittance amount of "2,250 yen" from the main account to the subaccount. This amount is the amount paid from the subaccount at the time of the payment displayed on the linked payment result display screen.

<Processing>
FIG. 1-13 is a flowchart showing an example of the flow of the processes executed by each device in this case.
From the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

After S120, if the store-presented linked payment process of S110 is successful, the control unit 11 of the server 10 sets the equal payment amount as the amount recommended to be transferred or charged from the first user account to the second user account (hereinafter collectively referred to as the "recommended transfer amount"), and transmits this information, that is, the recommended transfer amount information, to the terminal 20A via the communication I/F 14 (S130).

In addition, if the store-presented linked payment process fails, the amount calculated by "equal payment amount - electronic money account balance" for the linked account for which the equal payment payment has failed may be transmitted to terminal 20A via communication I/F 14 as the amount recommended to be charged to the account, or it may not be transmitted in this way.
Then, the control unit 11 of the server 10 ends the process.

When the control unit 21 of the terminal 20A receives the recommended remittance amount information (information on the remittance amount or charge amount) from the server 10 via the communication I/F 22, it causes the display unit 24 to display the received recommended remittance amount information (A130). Then, the control unit 21 of the terminal 20A ends the process.

This modified example illustrates a configuration in which the first information is recommended remittance amount information (not limited to this, but is an example of information based on the amount paid in the first settlement by the second account).
As an example of an effect of an embodiment obtained by such a configuration, the first information based on the amount paid in the first payment by the second account can be provided to the first user of the terminal. By way of example and not limitation, the first user of the terminal can be provided with an amount recommended for remittance or top-up.

Second Example
In the first embodiment, the terminal 20A displays the remittance request information on the display unit 24 and then ends the process.
In addition, the second embodiment is an embodiment in which remittance between accounts is executed based on remittance request information.

The contents described in the second embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
FIG. 2A is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of FIG. 2-1 shows an example of a display screen in which a remittance promotion notification area RER3 is displayed following the linked payment result display screen.

In addition to the contents of the remittance promotion notification area RER2, the remittance promotion notification area RER3 displays a remittance button BT2 at the bottom for executing the remittance process based on the notification contents of the remittance promotion notification area.

As a non-limiting example, when the transfer button BT2 is tapped, a transfer screen from the main account to the sub-account is displayed, and the initial transfer amount is set to "2,250 yen."

The right side of FIG. 2-1 shows an example of a notification screen that is displayed on the display unit 24 of the terminal 20A after remittance has been executed.
Based on the tapping of the remittance button BT2, information indicating that remittance has been made from the main account of user A.A to the subaccount is displayed on the notification screen of the payment application.

<Processing>
FIG. 2B is a flowchart showing an example of the flow of processes executed by each device in this embodiment.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

When the control unit 21 of the terminal 20A executes step A130, it causes the display unit 24 to display, by way of example and not limitation, a selection screen for deciding whether or not to transfer the recommended remittance amount from the first user account to the second user account (A140).

In addition, instead of the recommended remittance amount, the screen may be a selection screen for deciding whether or not to remit a predetermined amount or an amount based on the user's input, but this is not required. In this case, steps S130 and A130 may be omitted, but this is not required.

When a remittance is selected based on a user operation on the input/output unit 23 of the terminal 20A (A140: YES), the control unit 21 of the terminal 20A sends, by way of example and not limitation, remittance command information for remittance of the recommended remittance amount from the first user account to the second user account to the server 10 via the communication I/F 22 (A150).

On the other hand, if the user selects not to transfer money (A140: NO), the control unit 21 of terminal 20A ends the process.

When remittance command information is received from terminal 20A via communication I/F 14 (S140: YES), control unit 11 of server 10 executes remittance processing based on the remittance command information, for example but not limited to, remittance of the recommended remittance amount from the first user account to the second user account (S150). Then, control unit 11 of server 10 transmits the result of the remittance processing as remittance result information to terminal 20A via communication I/F 14 (S160). Thereafter, control unit 11 of server 10 ends the processing.

If no remittance command information is received from terminal 20A (S140: NO), the control unit 11 of server 10 terminates the process.

When the remittance result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the remittance result information (A160). Then, the control unit 21 of the terminal 20A ends the process.

<Effects of the Second Example>
This embodiment illustrates a configuration in which the terminal 20 executes a process for transferring money from a first user account to a second user account based on input by a user of the terminal 20 in response to a selection screen displayed on the display unit 24 for selecting whether or not to transfer the recommended transfer amount from the first user account to the second user account (this is an example of a first display, not limiting the present invention).
As an example of an effect of an embodiment obtained by such a configuration, the terminal can transfer an amount based on the first information from a first account to a second account by the simple method of a first user inputting information into a first display based on the first information.

In addition, in this embodiment, the server 10 (not limited to this, but an example of a server that communicates with a terminal and performs processing related to a payment) executes an account linkage payment process (not limited to this, but an example of processing related to a first payment) by the control unit 11 based on a first user account of the user of the terminal 20 and a second user account linked with the first user account. Based on this account linkage payment, the server 10 transmits remittance request information to the terminal 20 by the communication I/F 14. The server 10 then performs a remittance process from the first user account to the second user account based on an input by the user of the terminal 20 in response to a selection screen displayed on the terminal 20 for selecting whether or not to remit the recommended remittance amount from the first user account to the second user account.
As an example of an effect of an embodiment obtained by such a configuration, the server can transfer an amount based on the first information from a first account to a second account based on input by a first user to a first display based on the first information displayed on the terminal.

<Third Example>
In the first and second embodiments, the linked accounts are described as different user accounts of one user, but the present invention is not limited to this.
In the following, a case where user accounts of different users are linked (where linked accounts are accounts of different users) will be described.

When making a payment using a linked wallet, as a non-limiting example, if the balance in the electronic money account of one of the linked user accounts (one of the linked accounts) is low and does not cover the equal payment amount, one possible method is to have the other linked user account temporarily cover the shortfall and then execute the payment.
In this case, it becomes necessary to return the fee after paying the advance amount, but by way of example and not limitation, the return process needs to be performed manually, which is inconvenient.

The contents described in the third embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, the linked account data in the first linked wallet management database 157A stores the application IDs of different users as application IDs.

In the following, as an example and not a limitation, a case will be illustrated in which a user account of user A.A (as an example and not a limitation, application ID "U0001") and a user account of user B.B (as an example and not a limitation, application ID "U0002") are stored in the linked account data.
That is, a case where user A.A and user B.B are linked members will be illustrated.

In addition, this embodiment illustrates a case where the balance of the electronic money account of the user A. A who is performing the code payment is low and does not cover the amount of the equal payment.

<Display screen>
In the following, an example will be described in which the user account of user A.A and the user account of user B.B are linked as linked accounts, and these linked accounts are used to perform account linked payment. In this example, one user account of each of multiple users is linked, so there is a one-to-one correspondence between linked members and linked accounts.

FIG. 3A is a diagram showing an example of the transition of screens displayed on the display unit 24 of the terminal 20 in this embodiment, and shows an example of a screen displayed on the display unit 24 of the terminal 20A.
The left side of Figure 3-1 shows the main menu screen of the payment application described above, with the linked wallet icon IC1 tapped.

The center of Figure 3-1 is an example of a display screen for linked wallet information that is displayed when linked wallet icon IC1 is tapped, and corresponds to Figure 1-9.
In this embodiment, since the user account of user A.A and the user account of user B.B are linked, the words "Linked wallet of A.A and B.B" are displayed, including the user name of the linked wallet.

In addition, in the linked member information display area MIR1, the letters "A.A" indicating that it is the user account of user A.A and the letters "B.B" indicating that it is the user account of user B.B are displayed in association with the icon image of each user. In this example, the electronic money account balance of user A.A's user account is shown to be "1,000 yen," and the electronic money account balance of user B.B's user account is shown to be "6,000 yen."

As an example and not a limitation, when the code reader icon IC2 on this screen is tapped, linked wallet code reader information for making a payment using this linked wallet is sent from the server 10 to the terminal 20A. The control unit 21 of the terminal 20A then starts the application code reader. As a result, the application code reader screen as shown on the right side of Figure 3-1 is displayed.

The left side of Figure 3-2 is a payment amount input screen similar to that shown on the left side of Figure 1-10, and when the payment button BT1 is tapped, a code payment is executed using the linked wallet.
However, in this example, based on the fact that the electronic money account balance of the user account of user A.A is insufficient, a linked payment confirmation screen such as that shown in the center of FIG. 3-2 is displayed, by way of example and not by way of limitation.

On this linked payment confirmation screen, by way of example and not limitation, a payment amount confirmation area PIR1 is displayed below the current location display area CLR1. In the payment amount confirmation area PIR1, by way of example and not limitation, an icon image of "XX Musical Instrument," the destination of the payment amount, is displayed along with its name "XX Musical Instrument" and the payment amount "4,500 yen." Below the payment amount, the current available linked payment amount, "3,250 yen," is displayed.

In addition, a warning mark and the words "Insufficient balance" are displayed in the payment amount confirmation area PIR1 because the current available linked payment amount is lower than the payment amount.

In addition, below the payment amount confirmation area PIR1, the names of the affiliated members are displayed along with their icons. Below that, a payment member confirmation area PMR1 is displayed to check the payment status of each affiliated member.

Here, the linked payable amount is defined by the following formula, assuming that the payment amount is divided equally between the linked accounts.
・Linked payment available amount = Sum of payment capacity for all linked accounts

Here, the payment margin of a linked account is defined as follows:
Payment margin of one linked account = electronic money account balance of that linked account (if electronic money account balance of that linked account - equal payment amount < 0)
Payment margin of one linked account = equal payment amount (if the electronic money account balance of that linked account - equal payment amount ≧ 0)
However, the amount is calculated as "equal payment amount = payment amount ÷ number of linked accounts".

Note that these formulas may or may not be applied to the first and second embodiments as examples and not limitations, to similarly calculate the linked payable amount.
In other words, the linked accounts may or may not be multiple user accounts of a single user, such as, for example but not limited to, two user accounts, the first user account (main account) and the second user account (sub-account) mentioned above, and the linked payable amount may or may not be calculated.

In this embodiment, since there is a one-to-one correspondence between linked members and linked accounts, the above formula can also be defined by linked members. In other words, the above formula can also be expressed as follows:
· Collaborative payment available amount = the sum of payment margins for all collaborative members · Payment margin of one collaborative member = the balance of the collaborative member's electronic money account (if the balance of the collaborative member's electronic money account - equal payment amount < 0)
Payment margin of one linked member = equal payment amount (if the linked member's electronic money account balance - equal payment amount ≧ 0)
However, the amount of equal payment is calculated as "amount paid = amount paid ÷ number of affiliated members."

In the paying member confirmation area PMR1, for example and not by way of limitation, an icon, user name, payment capacity, and electronic money account balance are displayed in association with each row for each linked member (linked account). In addition, for users whose payment capacity falls below the equal payment amount, a warning mark is displayed superimposed on the top left of the icon.

In this example, the amount of the equal payments is 4,500 yen divided by 2 = 2,250 yen.
For user A.A, since the remaining payment capacity falls below the equal payment amount, a warning mark is displayed in the upper left corner of the icon of user A.A, indicating that the remaining payment capacity is "1,000 yen".
On the other hand, for user B.B, since the remaining payment capacity does not fall below the equal payment amount, no warning mark is displayed and the remaining payment capacity is shown as "2,250 yen".

In this example, the collaborative payment available amount is less than the payment amount, so the payment cannot be made as is. Therefore, at the bottom of the collaborative payment confirmation screen, an advance request button BT4 is displayed, indicated by the words "Ask another member to advance" to request that user B.B advance the amount that needs to be advanced (2,250 yen - 1,000 yen = 1,250 yen) that is not covered by user A.A's payment margin of 1,000 yen out of the equal payment amount of 2,250 yen, and to execute the payment.

The right side of FIG. 3-2 shows an example of a linked payment confirmation screen when the advance payment request button BT4 is tapped.
On this linked payment confirmation screen, in the paying member confirmation area PMR1, the payment margin of user B.B has increased to "3,500 yen", which is the sum of the equal payment amount of "2,250 yen" and the advance payment required amount of "1,250 yen". Accordingly, the linked payment available amount in the payment amount confirmation area PIR1 has increased to "4,500 yen", the words "Insufficient balance" have disappeared, and the words "Payable" are displayed.

Also, at the bottom of the linked payment confirmation screen, a linked payment execution button BT5 is displayed, indicated by the word "Payment", which allows the user to execute a payment based on the user's current payment capacity.

FIG. 3-3 shows an example of a screen transition when the linked payment execution button BT5 is tapped on the linked payment confirmation screen on the right side of FIG. 3-2.
The left side of Figure 3-3 shows the linked payment result display screen for checking the results of a payment made using a linked wallet.

At the top of the linked payment result display screen, the words "Payment Completed" are displayed, indicating that the payment using the linked wallet has been completed, along with an icon image of "XX Musical Instrument," the recipient of the payment amount, its name "XX Musical Instrument," and the date and time of the payment, "2020-07-24/12:17:08."

At the bottom of the linked payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of this payment for each linked member.
The member payment result display area MRR1 displays, for each linked member, the name of the user who made the payment, the amount paid as payment margin, and the balance of the electronic money account after the payment.

By way of example and not limitation, the member payment result display area MRR1 shows that user A.A paid his remaining payment capacity of "1,000 yen", resulting in his electronic money account balance being "0 yen". Also, it shows that user B.B paid his remaining payment capacity of "3,500 yen", resulting in his electronic money account balance being "2,500 yen".

In addition, the item for User B.B. also displays a refund button BT6 for User A.A to return the 1,250 yen paid by User B.B. to User B.B.

The right side of Figure 3-3 is an example, by way of example and not limitation, of a notification screen which is accessed by tapping the "Notification" icon from the main menu of the payment application.
It is also possible to transition to the notification screen by, for example, tapping on a payment completion notification (not shown) that is displayed superimposed on the linked payment result display screen.

The notification information display area NTR2 of this notification screen displays linked payment result information CT2 based on the execution of a linked payment, and advance payment information CT3 based on the occurrence of an advance payment in the linked payment.

The linked payment result information CT2 displays the amount paid by user A.A, "1,000 yen," the date and time of the payment, that the payment was completed using the linked wallet, and that the payment was made to "XX Musical Instrument." In addition, an icon indicating that the payment was made using the linked wallets of user A.A and user B.B is displayed in the upper right corner.
At the bottom of the linked payment result information CT2, a details confirmation button with the words "Confirm details" is displayed for confirming the details of the payment. When this details confirmation button is tapped, the linked payment result display screen shown on the left side of FIG. 3-3 is displayed, by way of example and not limitation.

In addition, the linked settlement result information CT2 may or may not display the total payment amount paid to "XX Musical Instrument", "4,500 yen", instead of the amount paid by user A.A, "1,000 yen".
Alternatively, both the amount paid by user A.A and the total amount paid may or may not be displayed.
Alternatively, the amount paid by other users may be added to the display, or it may not be displayed.

The advance payment information CT3 displays information indicating that user B.B. has advanced "1,250 yen" to pay using the linked wallet. Also, an icon is displayed in the upper right corner indicating that a payment was made using the linked wallets of user A.A and user B.B.
Below that, a button for confirming the details of the payment is displayed, which is indicated by the words "Confirm Details." When the button for confirming the details is tapped, the linked payment result display screen shown on the left side of Figure 3-3 is displayed, by way of example and not by way of limitation.
Below the advance payment information CT3, an advance payment refund button BT6 is displayed.

When the advance payment amount refund button BT6 is tapped, the advance payment amount of 1,250 yen is transferred from user A.A's electronic money account to user B.B's electronic money account.

If the balance of the electronic money account of the user A.A is not sufficient to cover the advance payment amount and the remittance cannot be executed, the display mode of the advance payment amount refund button BT6 may be grayed out, or the button operation may be disabled, but this is not necessary.
Furthermore, when the advance payment refund button BT6 is tapped when the balance in the user A.A's electronic money account is insufficient to cover the advance payment, the screen may transition to a screen that prompts the user to charge the amount from a bank account, but this is not essential.

When the refund of the advance payment amount is completed using the advance payment amount refund button BT6, the display mode of the advance payment amount refund button BT6 may be grayed out in the subsequent display to disable button operation, or it may not be necessary to do so.

In addition, in the notification information display area NTR2, the linked payment result information CT2 and the advance payment information CT3 may be displayed together as one piece of information, but this is not essential.

<Processing>
3-4 and 3-5 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

When the control unit 11 of the server 10 receives the linked payment request information from the terminal 20A via the communication I/F 14, the control unit 11 of the server 10 calculates the linked payable amount and determines whether the calculated linked payable amount is less than the planned payment amount (whether the linked payable amount - planned payment amount < 0) (S210). If the linked payable amount is less than the planned payment amount (S210: YES), the control unit 11 of the server 10 sends linked balance insufficient information to the terminal 20A via the communication I/F 14, indicating that the linked payable amount is insufficient and payment cannot be made, and therefore a transfer is required from another linked account to the account of the code payment executor (S220).

If the linked payable amount is not less than the planned payment amount (linked payable amount - planned payment amount is 0 or more) (S210: NO), payment is possible using the linked wallet, so the control unit 11 of the server 10 proceeds to step S110.

When the communication I/F 22 receives linked balance insufficiency information from the server 10 (A200: YES), the control unit 21 of the terminal 20A has the account of another linked member of the linked wallet (in this case, user B.B.) cover the shortfall in user A.A's payment margin (i.e., equal payment amount - user A.A's payment margin) and sends balance replenishment request information to the server 10 via the communication I/F 22 to continue the payment (A210).

If the balance of the electronic money account of user B.B.'s account is equal to or greater than the planned payment amount, information requesting payment of the full amount of the planned payment from user B.B.'s account may be transmitted as balance replenishment request information, but this is not essential.

In addition, if the communication I/F 22 does not receive insufficient linked balance information from the server 10 (A200: NO), step A210 is not executed.

When the balance replenishment request information is received from the terminal 20A via the communications I/F 14, the control unit 11 of the server 10 executes an linked balance replenishment process based on the received balance replenishment request information (S230).
In the linked balance replenishment process, the control unit 11 of the server 10 updates the payment margin of the user A.A (the amount required to be paid in advance) by adding the shortfall in the payment margin of the user A.A to the payment margin of the user B.B, as the new payment margin of the user B.B. Then, the control unit 11 of the server 10 stores the amount required to be paid in advance in the storage unit 15 as the amount required to be returned from the user A.A to the user B.B.

The control unit 11 of the server 10 may transmit the processing result of the linked balance replenishment process to the terminal 20A via the communication I/F 14, and the control unit 21 of the terminal 20A may or may not display the processing result of the linked balance replenishment process received via the communication I/F 22 on the display unit 24.

In addition, in the linked balance replenishment process, rather than increasing the payment capacity of user B.B, a process of transferring the required amount to be paid in advance from user B.B's account to user A.A's account may be executed to increase user A.A's payment capacity, or it may not be necessary to do so.

When the control unit 11 of the server 10 executes the store-presented cooperative payment process (S110), it transmits cooperative payment result information, which is the result of the execution of the cooperative payment process, to each terminal 20 of the cooperative members via the communication I/F 14 (S240).

When the linked payment result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the linked payment result information (A230).

When the linked payment result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the linked payment result information (B200).

If the linked balance replenishment process is executed prior to the linked payment process (S250: YES), the control unit 11 of the server 10 transmits the lending/borrowing information, including the amount to be returned, stored in the memory unit 15 to each terminal 20 of the linked members via the communication I/F 14 (S260).
On the other hand, if the linked balance replenishment process has not been executed (S250: NO), the control unit 11 of the server 10 ends the process.

When lending/borrowing information is received from the server 10 via the communication I/F 22 (A240: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display the received lending/borrowing information (A250).
On the other hand, if lending/borrowing information is not received (A240: NO), the control unit 21 of the terminal 20A ends the process.

After step A250, the control unit 21 of the terminal 20A causes the display unit 24 to display a selection screen for prompting the user whether or not to return the required return amount to the user B.B (A260).
Note that between steps A250 and A260, processing such as charging the account of user A.A. from an account at an external financial institution, or transferring money from another account to the account of user A.A. may be inserted.

When it is selected to return the required return amount to user B.B based on a user operation on the input/output unit 23 of terminal 20A (A260: YES), the control unit 21 of terminal 20A transmits required return amount return information for executing a transfer of an amount equivalent to the required return amount from the account of user A.A to the account of user B.B to the server 10 via the communication I/F 22 (A270).
On the other hand, if returning the required refund amount to user B.B is not selected (A260: NO), the control unit 21 of the terminal 20A ends the process.

When the communication I/F 14 receives the required return amount return information from the terminal 20A (S270: YES), the control unit 11 of the server 10 executes a loan/borrow return process to transfer the amount set forth in the required return amount from the account of the user A.A to the account of the user B.B based on the required return amount return information (S280). In addition, if the loan/borrow return process is successful, the control unit 11 of the server 10 erases the required return amount stored in the memory unit 15.

Then, the control unit 11 of the server 10 transmits the loan/borrow/return information, including the execution result of the remittance process executed by the loan/borrow/return process, to each terminal 20 corresponding to the remitter and remittance destination accounts of the required return amount return information via the communication I/F 14 (S290). Then, the control unit 11 of the server 10 ends the process.

If the required return amount return information is not received from terminal 20A (S270: NO), the control unit 11 of server 10 ends the process.

When the loan/borrow/return information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A displays the loan/borrow/return information on the display unit 24 (A280). Then, the control unit 21 of the terminal 20A ends the process.

When lending/borrowing information is received from server 10 via communication I/F 22 (B210: YES), control unit 21 of terminal 20B causes display unit 24 to display the received lending/borrowing information (B220).
If lending/borrowing information is not received (B210: NO), the control unit 21 of the terminal 20B ends the process.

When loan/borrow/return information is received from the server 10 via the communication I/F 22 (B230: YES), the control unit 21 of the terminal 20B causes the loan/borrow/return information to be displayed on the display unit 24 (B240). Then, the control unit 21 of the terminal 20B ends the process.

<Effects of the Third Embodiment>
According to this embodiment, a settlement can be made based on a first user account of a first user and a second user account of a second user linked to the first user account. Based on this settlement, money can be transferred from the first user account to the second user account. Since the second user account is an account of the second user, a settlement can be realized based on the first account of the first user and the second account of the second user linked to the first account.

It should be noted that the second user account is an account of the second user.
Therefore, a transfer to a second user account may be regarded as a transfer to the second user, or as a transfer to the second user's terminal.

In this embodiment, the account linking settlement is performed by at least the second user account paying the shortfall of the first user account. Also, the lending/borrowing information (not limited to, but an example of the first information) shows a configuration including information on the required return amount (not limited to, but an example of the amount paid by the second account on behalf of the first account).
As an example of the effect of the embodiment obtained by such a configuration, in the first settlement, at least the second account can be made to pay the shortfall in the first account. In this way, when the balance of the first account is insufficient and the first account is unable to pay the entire amount due, the shortfall can be paid by the second account. In addition, the first user can be prompted to transfer the amount paid by the second account on behalf of the first account from the first account to the second account.

In the above, payment may not be made through the first user account.
As an example of an effect of an embodiment obtained by such a configuration, in the first settlement, all payments can be made from the second account.

In the above, the account linking settlement may involve payment by the first user account and payment of any shortfall in the first user account by at least the second user account.
As an example of an effect of an embodiment obtained by such a configuration, in the first settlement, a payment is made from the first account, but at least the second account can be used to pay the shortfall in the first account.

In the above, the linked balance insufficient information (not limited to this, but an example of the first information) is configured to be received by the communication I/F 22 of the terminal 20 via the server 10 .
As an example of an effect of the embodiment obtained by such a configuration, the first information can be easily acquired via the server.

<Third Modification (1)>
In the third embodiment, a case has been shown in which user A.A, who has been advanced the shortfall, actively returns the required return amount to user B.B. However, this is not limiting. As a non-limiting example, user B.B, who is an associated member who has advanced (lent) the required return amount, may or may not be able to request the required return amount from user A.A, who has been advanced.

<Display screen>
FIG. 3-6 is a diagram showing an example of a screen transition on terminal 20B when the linked payment execution button BT5 is tapped on the linked payment confirmation screen of terminal 20A on the right side of FIG. 3-3.

The left side of Figure 3-6 is an example of a notification screen to which the user transitions by tapping the "Notification" icon from the main menu of the payment application, by way of example and not of limitation. Note that the user can also transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is sent to and displayed on terminal 20B.

The notification information display area NTR3 of this notification screen displays linked payment result information CT4 based on the execution of a linked payment, and advance payment information CT5 based on the occurrence of an advance payment in the linked payment.

The linked payment result information CT4 displays the amount paid by user B.B., "3,500 yen," the date and time of the payment, that the payment was completed using the linked wallet, and that the payment was made to "XX Musical Instrument." In addition, an icon indicating that the payment was made using the linked wallets of user A.A. and user B.B. is displayed in the upper right corner.
At the bottom of the linked payment result information CT4, a details confirmation button with the words "Confirm details" is displayed for confirming the details of the payment. When this details confirmation button is tapped, the linked payment result display screen shown on the right side of FIG. 3-6 is displayed, by way of example and not limitation.

The advance payment information CT5 displays a display indicating that "1,250 yen" was advanced to user A.A. using the linked wallet for payment. Also, in the upper right corner, an icon is displayed indicating that a payment was made using the linked wallets of user A.A. and user B.B.
Below that, a button for confirming the details of the payment is displayed, which is indicated by the words "Confirm Details." When the button for confirming the details is tapped, the linked payment result display screen shown on the right side of Figure 3-6 is displayed, by way of example and not by way of limitation.
Below the advance payment information CT5, an advance payment request button BT7 for requesting a refund of the "1,250 yen" that User B.B. advanced to User A.A. is displayed.

The right side of FIG. 3-6 is an example of a linked payment result display screen displayed on the display unit 24 of the terminal 20B.
On this screen, in the member payment result display area MRR2, instead of the Advance Payment Amount Refund button BT6, a Advance Payment Amount Request button BT7 for urging the return of the "1,250 yen" advanced by user B.B is additionally displayed in the item for user A.A.

When the advance payment amount request button BT7 is tapped, information is transmitted to terminal 20A, prompting the transfer of the advance payment amount of "1,250 yen" from the electronic money account of user A.A to the electronic money account of user B.B, and is displayed on display unit 24 of terminal 20A.
In addition, when the balance of the electronic money account of user A.A is larger than the advance amount, the advance amount may or may not be automatically transferred from the electronic money account of user A.A to the electronic money account of user B.B.

In addition, if the refund of the advance payment has been completed, the display of the advance payment amount request button BT7 may be grayed out in the subsequent display to disable button operation, or it may not be necessary to do so.

<Processing>
3-7 to 3-8 are flowcharts showing an example of the flow of processes executed by each device in this modified example, continuing from FIG. 3-4.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

When the control unit 21 of the terminal 20B executes step B220, it causes the display unit 24 to display a selection screen for asking whether or not to request (urge) the user A.A to return the required return amount (B223).

If it is selected to prompt user A.A to return the required return amount based on a user operation on the input/output unit 23 of terminal 20B (B223: YES), the control unit 21 of terminal 20B sends required return amount request information to the server 10 via the communication I/F 22 to request a transfer of an amount equivalent to the required return amount from user A.A's account to user B.B's account (B226).

If it is not selected to prompt user A.A to return the required return amount (B223: NO), the control unit 21 of terminal 20B proceeds to step B230.

After executing step S260, if the control unit 11 of the server 10 receives return amount request information from the terminal 20B via the communication I/F 14 (S263: YES), the control unit 11 transmits return amount reminder information to the terminal 20A of the user A, who is the reminder destination, via the communication I/F 14, reminding the user A to return the return amount (S266). Then, the control unit 11 executes steps from S270 onwards.

If the required return amount request information is not received (S263: NO), the control unit 11 of the server 10 does not execute step S266, but executes steps S270 and onward.

After executing step A250, if the control unit 21 of the terminal 20A receives return amount reminder information from the server 10 via the communication I/F 22 (A253: YES), it causes the return amount reminder information to be displayed on the display unit 24 (A256). After that, the control unit 21 of the terminal 20A proceeds to step A260.

If the required return amount reminder information is not received (A253: NO), the control unit 21 of the terminal 20A proceeds to step A260.

If "A260: NO" is returned after step A256 is executed, the process may return to step A256 again to repeatedly notify user A.A of terminal 20A, or it may not be necessary to do so. Also, step A256 may be executed at regular intervals to continue to provide reminders, or it may not be necessary to do so.

<Third Modification (2)>
In the third embodiment, a case was shown in which the balance of the electronic money account of the account of user A.A who performs code payment does not satisfy the equal payment amount, but this is not limited to this. As a non-limiting example, when the balance of the electronic money account of user B.B, who is an account of a linked member, does not satisfy the equal payment amount, the shortfall in the payment capacity of user B.B (i.e., the equal payment amount - user B.B's payment capacity) may be borne by the account of user A.A, and the payment may be performed using the linked wallet, or it may not be.

<Display screen>
Fig. 3-9 is an example of screen transitions until the account linkage payment is completed, displayed on terminal 20B. This figure shows the screen transitions until the account linkage payment is completed, displayed on terminal 20A in Fig. 3-2, as viewed from terminal 20B.
The left side of Figure 3-9 shows a linked payment confirmation screen that includes a warning mark and the words "Insufficient balance," similar to the center of Figure 3-2.

At the bottom of the linked payment confirmation screen, a payment button BT10 is displayed with the words "Advance Shortfall," which allows User B.B to advance the shortfall (2,250 yen - 1,250 yen = 1,250 yen) that is required to be paid out of the 2,250 yen equal payment amount that is not covered by User A.A's payment margin of 1,000 yen, and to execute the payment.

When the advance payment button BT10 is tapped, the display transitions to the linked payment confirmation screen shown in the center of FIG.
In this screen, in the payment member confirmation area PMR2, the payment balance of user B.B has increased to "3,500 yen", which is the sum of the equal payment amount of "2,250 yen" and the advance payment required amount of "1,250 yen". Accordingly, the cooperative payment available amount in the payment amount confirmation area PIR2 has increased to "4,500 yen", the words "Insufficient balance" have disappeared, and the words "Payable" are displayed.

Also, at the bottom of the linked payment confirmation screen, a linked payment execution button BT11 is displayed, indicated by the word "Payment", which allows the user to execute a payment based on the user's current payment capacity.

When the linked payment execution button BT11 is tapped, the display transitions to the linked payment result display screen shown on the right side of FIG. 3-9.
This screen displays the word "Payment Completed" indicating that the payment using the linked wallet has been completed, as well as an icon image of "XX Musical Instrument" to which the payment amount has been transferred, its name, and the date and time of payment. At the bottom of the linked payment result display screen, a member payment result display area MRR3 is displayed.

By way of example and not limitation, the member payment result display area MRR3 displays that user A.A has paid his remaining payment capacity of "1,000 yen", resulting in his electronic money account balance being "0 yen". Also, it displays that user B.B has paid his remaining payment capacity of "3,500 yen", resulting in his electronic money account balance being "2,500 yen".

Further, in the item for user A.A, an advance payment request button BT12 for requesting the "1,250 yen" that user B.B. has advanced to user A.A is additionally displayed.
The behavior when the advance payment claim button BT12 is tapped can be configured to be similar to that when the advance payment claim button BT7 is tapped in FIG. 3-6.

Figure 3-10 shows an example of the screen transition on terminal 20A when the linked payment execution button BT5 is tapped on the linked payment confirmation screen of terminal 20B in the center of Figure 3-9.

The left side of Figure 3-10 is an example of a notification screen to which you can transition by tapping the "Notification" icon from the main menu of the payment application, by way of example and not limitation. Note that it is also possible to transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is sent to and displayed on terminal 20A.

The notification information display area NTR3 of this notification screen displays linked payment result information CT4 based on the execution of a linked payment, and advance payment information CT5 based on the occurrence of an advance payment in the linked payment.

The linked payment result information CT4 displays the amount paid by user A.A, "1,000 yen," the date and time of the payment, that the payment was completed using the linked wallet, and that the payment was made to "XX Musical Instrument." In addition, an icon indicating that the payment was made using the linked wallets of user A.A and user B.B is displayed in the upper right corner.
At the bottom of the linked payment result information CT4, a details confirmation button with the words "Confirm details" is displayed for confirming the details of the payment. When this details confirmation button is tapped, the linked payment result display screen shown on the right side of FIG. 3-10 is displayed, by way of example and not limitation.

The advance payment information CT5 displays a display indicating that user B.B. has advanced "1,250 yen" to pay using the linked wallet. Also, in the upper right corner, an icon is displayed indicating that a payment was made using the linked wallets of user A.A and user B.B.
Below that, a button for confirming the details of the payment is displayed, which is indicated by the words "Confirm Details." When the button for confirming the details of the payment is tapped, the linked payment result display screen shown on the right side of FIG. 3-10 is displayed, by way of example and not by way of limitation.
Below the advance payment information CT5, an advance payment refund button BT6 is displayed for user A.A to return the "1,250 yen" that user B.B. has advanced to user A.A.

The right side of FIG. 3-10 is an example of a linked payment result display screen displayed on the display unit 24 of the terminal 20A.
On this screen, in the member payment result display area MRR2, a refund button BT6 for refunding the "1,250 yen" paid in advance by user B.B. is additionally displayed in the user B.B.'s item.

<Processing>
As an example, and not a limitation, the processing in this case can be executed in the same manner as in FIGS. 3-4 to 3-5 by using, in step A210 in FIG. 3-4, the balance replenishment request information as information for user A.A to cover the shortfall in the payment margin of another linked member (in this case, user B.B.) of the linked wallet (i.e., equal payment amount - payment margin of user B.B.), and by switching and executing the steps of terminal 20A and terminal 20B in FIG. 3-5 between the terminals.

<Third Modification (3)>
In the third embodiment, when the balance of the electronic money account of the account of the user A.A who performs the code settlement is not sufficient for the equal payment amount, an example is shown in which the shortfall is paid in advance by another linked account, but this is not limited to this. As a non-limiting example, the shortfall may or may not be charged to the account of the user A.A from an account of an external financial institution when the code settlement is performed.

<Display screen>
FIG. 3-11 shows an example of the screen transition of the linked payment confirmation screen when a code payment is executed using a linked wallet.

The linked payment confirmation screen is displayed on the left side of Figure 3-11. On this screen, a charge button BT8 indicated with a "+" mark for charging the balance of the electronic money account is also displayed in the payment member confirmation area PMR1.

When the charge button BT8 is tapped instead of the advance payment request button BT4, a screen shown in the center of FIG. 3-11 is displayed, by way of example and not limitation.
In this screen, a charge display area CGR1 rises from the bottom of the linked payment confirmation screen and is displayed overlapping it.

The charge display area CGR1 displays "Charge" as an operation guide for the user, and below that is a bank account display area.

In this example, the bank name "XX Bank" is displayed in the bank account display area along with the "XX Bank" logo (XX BANK). Below that, "Regular Savings Account ****" is displayed as the deposit type and account number, and below that, the account holder "A.A." is displayed.

Below the bank account display area is a planned charge amount input area for displaying the input planned charge amount along with the display of "Charge Amount." Here, "2,000 yen" is input and displayed as the planned charge amount. Also below that is a field for inputting the charge amount into the planned charge amount input area, and in this example, a first charge button for adding "100 yen" to the planned charge amount, a second charge button for adding "1,000 yen" to the planned charge amount, and a third charge button for adding "10,000 yen" to the planned charge amount are displayed lined up horizontally.

In addition, a "clear planned charge amount" button is displayed on the left side of the planned charge amount input field. When the "clear planned charge amount" button is tapped, the amount in the planned charge amount input field is cleared and "0 yen" is displayed in the planned charge amount input field.

At the bottom of the charge display area CGR1, a charge execution button BT9 is displayed for executing a charge of the amount entered in the planned charge amount input area. In this example, when the charge execution button BT9 is tapped, "2,000 yen" is charged to the user's electronic money account balance.

When the planned charge amount input area is tapped, a numeric keypad area for inputting the planned remittance amount is displayed at the bottom of the display unit 24, and the planned remittance amount can be input in detail based on the input into the numeric keypad area.

The right side of FIG. 3-11 is an example of a linked payment confirmation screen when the charge execution button BT9 is tapped.
In this screen, as the balance of the electronic money account of user A.A has increased by "2,000 yen," the payment capacity of user A.A has increased to "2,250 yen" in the payment member confirmation area PMR1. Accordingly, the cooperative payment available amount in the payment amount confirmation area PIR1 has increased to "4,500 yen," the words "Insufficient balance" have disappeared, and the words "Payment available" are displayed.

Also, at the bottom of the linked payment confirmation screen, a linked payment execution button BT5 is displayed, indicated by the word "Payment", which allows the user to execute a payment based on the user's current payment capacity.

<Processing>
As an example of the process in this case, but not limited thereto, in step A210 in FIG. 3-4, the control unit 21 of the terminal 20A transmits, instead of balance replenishment request information, charge request information for charging the shortfall in payment margin from an account of an external financial institution registered in advance by the user A.A to the account of the user A.A via the communication I/F 22 to the server 10. Then, in step S230 in FIG. 3-4, the control unit 11 of the server 10 charges the shortfall in payment margin from the account of the external financial institution to the account of the user A.A according to the charge request information received via the communication I/F 14.

<Third Modification (4)>
In the third embodiment, the terminal 20A receives the insufficient linked balance information (as an example and not as a limitation, an example of the first information) from the server 10, but is not limited to this. As an example and not as a limitation, the terminal 20A may or may not receive the insufficient linked balance information from another member's terminal 20 (as an example and not as a limitation, the terminal 20B).

<Processing>
FIG. 3-12 is a flowchart showing an example of the flow of processes executed by each device in this modified example.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

If the collaborative payment amount is less than the planned payment amount (S210: YES), the control unit 11 of the server 10 transmits collaborative payment amount insufficiency information to each of the collaborative members' terminals 20 via the communication I/F 14, indicating that the collaborative payment amount is insufficient and that the payment will fail if left as is (S222).

When the information on the shortfall in the linked payment capacity is received from the server 10 via the communication I/F 22 (B180: YES), the control unit 21 of the terminal 20B determines whether the shortfall in the payment capacity of the user A.A can be covered by the account of the user B.B, and if so, transmits the information on the shortfall in the linked balance to the terminal 20A via the communication I/F 22 (B190).

If the linked payment available amount deficiency information is not received (B180: NO), the control unit 21 of terminal 20B does not execute step B190.

When steps B180 and B190 are executed, the control unit 21 of the terminal 20B may display on the display unit 24 a message indicating that a situation has arisen in which an advance payment is required for the linked wallet payment, or may proceed with the process without informing the user B.B.

When insufficient linked balance information is received from terminal 20B via communication I/F 22 (A205: YES), control unit 21 of terminal 20A executes step A210.

Note that if communication I/F 22 does not receive insufficient linked balance information from terminal 20B (A205: NO), step A210 is not executed.

When the steps in Figure 3-12 are executed, the processing of each step in Figure 3-5 is then executed.

<Fourth Example>
In the third embodiment, the case where there are two cooperation members has been described, but the present invention is not limited to this.
In this embodiment, a case where there are three or more cooperation members will be described.

The contents described in the fourth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

When operating with three or more cooperating members, the processing method can be, by way of example and not limitation, two methods.
(1) A method of simply increasing the number of linked accounts registered in the linked account data. (2) A method of introducing a group that is pre-configured with multiple linked members.

In the method (1), by way of example and not limitation, the linked account data in the first linked wallet management database 157A may store user accounts for each of three or more linked members.
The same applies to the case where three or more user accounts of any linked members are used, rather than the individual user accounts of three or more linked members.

Method (2) will be described in detail below.
Here, as an example and not a limitation, we will explain a case in which a group including multiple users is formed in a payment application, and the user accounts of each of the users included in this group (hereinafter referred to as "group members") are linked to perform account linked payment.
In addition, here, a case where all group members included in the same group are regarded as linked members will be illustrated.

FIG. 4A is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The memory unit 15 stores, by way of example and not limitation, a payment application management processing program 151 executed as a payment application management processing, account registration data 153, an account management database 155, an associated wallet management database 157, and a group management database 159.

The group management database 159 is a database for managing groups formed in the payment application (or messaging application), and an example of its data structure is shown in FIG. 4-2.
The group management database 159 stores group management data as management data for each group.

Each group management data includes, by way of example and not limitation, a group ID, a group name, and group member data.
The group ID is information used to identify a group (identification information for identifying a group).
This group ID is preferably a value unique to each group, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each group.

The group name is the name of this group, and as a non-limiting example, the name entered on the terminal 20 by the user creating the group is registered by the server 10.

Group member data is data related to the user accounts of group members included in this group, and by way of example and not limitation, the group member's application ID and the group member's username are stored in association with each other.

Note that the group member data may or may not store multiple accounts belonging to the same group member. Furthermore, the number of accounts stored in the group member data is not limited to three or more. If one or more accounts are registered in the group member data, they may or may not be treated as a group.

FIG. 4C is a diagram showing an example of the data configuration of the second linked wallet management database 157B, which is an example of the linked wallet management database 157.
The second linked wallet management database 157B stores linked wallet management data as management data for each linked wallet.

Each linked wallet management data stores, by way of example and not limitation, a group ID, a group name, and payment history data.

The group ID is information for identifying the group that uses this linked wallet, and is information for identifying the linked wallet used for account linking payments on a group-by-group basis stored in the group management database 159. In other words, the group ID can determine a unique linked wallet to be used.

The group name is the name of the group that uses this linked wallet, and as a non-limiting example, the group name corresponding to the group ID stored in the group management data is stored in association with it.

The payment history data is the same as that in the first linked wallet management database 157A.

In other words, method (2) can be said to be method (1) in which the linked wallet ID in the linked wallet management data of the first linked wallet management database 157A is replaced with a group ID, and the linked account data in the group management database 159 is replaced with group member data.

<Display screen>
Here, as an example and not a limitation, a display screen example in the case where method (2) is applied will be described.

FIG. 4-4 is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of FIG. 4-4 is, by way of example and not limitation, a main menu screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
When the linked wallet icon IC1 is tapped on this main menu screen, information requesting group list information for selecting a group to perform wallet linkage is transmitted from the terminal 20A to the server 10, and the group list information is transmitted from the server 10 to the terminal 20A. As a result, a group selection screen such as that shown on the right side of FIG. 4-4 is displayed, as an example and not a limitation.

On this screen, the current location display area CLR1 displays the words "Linked Wallet," indicating that the linked wallet function is being used, and below that are the words "Please select a group," prompting the user to select a group with which to link the wallet.

Below that, groups to which the user of this terminal (user A.A. in this case) belongs are listed, grouped together on each line. Each group item shows, by way of example and not limitation, the group icon, group name, and the number of members that make up the group.

As a non-limiting example, when a group with the group name “Bandmates” (hereinafter referred to as the group “Bandmates”) is tapped as a group that will link wallets, a screen such as that shown in FIG. 4-5 will appear, as a non-limiting example.
The left side of FIG. 4-5 is an example of the main screen of the linked wallet, and on this screen, the linked member information display area MIR1 displays the electronic money account balance of each user in the group "Bandmate."

As a non-limiting example, when the code reader icon IC2 is touched on this screen, the control unit 21 of the terminal 20A launches an application code reader to read the terminal-reading code on the terminal 20A when performing a "store-presented" code payment.

An example of an application code reader screen is shown in the center of Figure 4-5.
On this screen, the word "Code Reader" which is the currently executed function is displayed below the current position display area CLR1. Also, a code reading area CR1 for reading the payment store code is displayed in the center of the screen.

The right side of Figure 4-5 shows an example of a payment amount input screen that is displayed when information is obtained by decoding the payment store code read in the center of Figure 4-5.

This payment amount input screen displays the name "XX Musical Instrument" along with an icon image of "XX Musical Instrument" to which the payment amount is to be sent. Below this is displayed a payment amount display area PR1 for displaying the input payment amount, with "4,500 yen" input and displayed here as the payment amount. Also displayed on the left end of the payment amount display area PR1 is an erase button indicated by a circled x for erasing the payment amount.
A keyboard for inputting the payment amount is displayed at the bottom of the screen, along with a payment button BT1 marked with the word "Pay" for making a payment with the payment amount entered in the payment amount display area PR1.
When the payment button BT1 is tapped on the payment amount input screen shown on the right side of Figure 4-5, a code payment is executed using the linked wallet.

When the code payment icon IC3 is tapped on the screen on the left side of FIG. 4-5, a code payment screen is displayed on display unit 24 of terminal 20A. The code payment screen displays a one-dimensional payment code represented by a barcode, by way of example and not limitation, and a two-dimensional payment code represented by a QR code (registered trademark), by way of example and not limitation, as the linked wallet payment code, which is a code (code image) transmitted from server 10 and received by terminal 20 and used to make a "customer-presented" payment. User A.A of terminal 20A can also make a code payment using the linked wallet by presenting the code payment screen to a store clerk at the code register and having the payment code read by a store code reader device.

FIG. 4-6 shows an example of the transition of the linked payment confirmation screen when a code payment is executed using a linked wallet.
On the left side of FIG. 4-6, as an example, but not limited to, a payment amount confirmation area PIR1 is displayed below a current location display area CLR1 as a linked payment confirmation screen. In the payment amount confirmation area PIR1, as an example, but not limited to, an icon image of "XX Musical Instrument" to which the payment amount is to be sent, its name "XX Musical Instrument" and the payment amount "4,500 yen" are displayed. Below the payment amount, the current linked payment amount of "4,000 yen" is displayed. Also, in the payment amount confirmation area PIR1, a warning mark and the words "Insufficient balance" are displayed based on the fact that the current linked payment amount is less than the payment amount.

In addition, below the payment amount confirmation area PIR1, the name of the "Bandmates" group, which is the linked wallet used for the payment, is displayed along with an icon. Below that is a payment member confirmation area PMR1, which allows the user to check the payment burden status of each member of the "Bandmates" group.

In the paying member confirmation area PMR1, for example and not by way of limitation, an icon, a user name, the amount of the payment burden (payment margin), and the balance of the electronic money account are displayed in association with each other on each line for each member. In addition, for users whose payment margin falls below the equal payment amount, a warning mark is displayed superimposed on the top left of the icon.

In this example, the equal payment amount is "4,500 yen ÷ 3 = 1,500 yen."
A warning mark is displayed in the upper left corner of User A's icon, indicating that the remaining payment capacity is "1,000 yen." In this case, the available linked payment amount is less than the payment amount, and the payment cannot be made as it is.
Therefore, at the bottom of the linked payment confirmation screen, out of the equal payment amount of "1,500 yen", the amount that needs to be paid in advance (1,500 yen - 1,000 yen = 500 yen) that is not covered by the payment margin of "1,000 yen" is displayed, and a payment request button BT4 indicated with the words "Have another member pay in advance" is displayed for making the payment by having another member other than user A.A pay in advance.

The center of FIG. 4-6 is an example of a linked payment confirmation screen that appears when the advance payment request button BT4 is tapped.
On this screen, instead of the paying member confirmation field PMR1, a paying member selection field PSR1 is displayed for displaying a list of members who can pay on behalf of the user and allowing the user to select one of them.

In the advance payment member selection area PSR1, the names of members who can advance payment and their electronic money account balances are displayed on a line below the words "Please select the member who will advance payment" that prompt the user to select a person to advance payment. In this example, users B.B and C.C are displayed as members who can pay "2,000 yen", which is the sum of the equal payment amount of "1,500 yen" plus the required advance amount of "500 yen". In this example, user B.B's electronic money account balance is "3,000 yen" and user C.C's electronic money account balance is "6,000 yen".

By way of example and not limitation, when user C.C. is tapped and selected as the payer, the display transitions to the linked payment confirmation screen shown on the right side of FIG. 4-6.
In this screen, in the payment member confirmation area PMR1, the payment balance of user C.C. has increased to "2,000 yen", which is the sum of the equal payment amount of "1,500 yen" and the advance payment required amount of "500 yen". Accordingly, the cooperative payment available amount in the payment amount confirmation area PIR1 has increased to "4,500 yen", the words "Insufficient balance" have disappeared, and instead the words "Payment available" are displayed.

Also, at the bottom of the linked payment confirmation screen, a linked payment execution button BT5 is displayed, indicated by the word "Payment", which allows the user to execute a payment based on the user's current payment capacity.

In the center of Figure 4-6, it may be possible to select multiple payers instead of just one, but this is not essential. If multiple payers are selected, the amount to be paid may be divided equally among them, or, as a non-limiting example, the amount may be divided proportionately according to the balance of the electronic money account.

FIG. 4-7 shows an example of a screen transition when the linked payment execution button BT5 is tapped on the linked payment confirmation screen on the right side of FIG. 4-6.
The left side of Figure 4-7 shows a linked payment result display screen for checking the results of a payment using a linked wallet.

At the top of the linked payment result display screen, the words "Payment Completed" are displayed, indicating that the payment using the linked wallet has been completed, along with an icon image of "XX Musical Instrument," the recipient of the payment amount, its name "XX Musical Instrument," and the date and time of the payment, "2020-07-24/12:17:08."

At the bottom of the linked payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of the payment for each member in the linked wallet.
The member payment result display area MRR1 displays, for each member, the name of the user who made the payment, the amount paid as payment margin, and the balance of the electronic money account after the payment.

By way of example and not limitation, the member payment result display area MRR1 displays that user A.A has paid his remaining payment capacity of "1,000 yen", resulting in his electronic money account balance being "0 yen". It also displays that user B.B has paid his remaining payment capacity of "1,500 yen", resulting in his electronic money account balance being "1,500 yen". It also displays that user C.C has paid his remaining payment capacity of "2,000 yen", resulting in his electronic money account balance being "4,000 yen".

In addition, the item for user C.C. also displays a refund button BT6 for returning the "500 yen" that user A.A. had user C.C. pay in advance.

The right side of Figure 4-7 is an example of a notification screen that is transitioned to by tapping the "Notification" icon from the main menu of the payment application, by way of example and not of limitation. Note that it is also possible to transition to the notification screen by tapping the payment completion notification (not shown) that is displayed superimposed on the linked payment result display screen.

The notification information display area NTR2 of this notification screen displays linked payment result information CT2 based on the execution of a linked payment, and advance payment information CT3 based on the occurrence of an advance payment in the linked payment.

The linked payment result information CT2 displays the amount paid by user A.A., "1,000 yen," the date and time of the payment, that the payment was completed using the linked wallet, and that the payment was made to "XX Musical Instruments." In addition, the icon of the group "Bandmates" to which the linked wallet was applied is displayed in the upper right corner.
At the bottom of the linked payment result information CT2, a details confirmation button with the words "Confirm details" is displayed for confirming the details of the payment. When this details confirmation button is tapped, the linked payment result display screen shown on the left side of FIG. 4-7 is displayed, by way of example and not limitation.

The linked payment result information CT2 may or may not display the total payment amount "4,500 yen" paid to "XX Musical Instrument" instead of the amount "1,000 yen" paid by user A.A. Alternatively, it may or may not display both the amount paid by user A.A. and the total payment amount. It may or may not display the amounts paid by other users as well.

The advance information CT3 shows that user C.C. has advanced "500 yen" to pay using the linked wallet. In addition, the icon of the group "Bandmates" to which the linked wallet is applied is displayed in the upper right corner.
Below that, a button for confirming the details of the payment is displayed, which is indicated by the words "Confirm Details." When the button for confirming the details is tapped, the linked payment result display screen shown on the left side of FIG. 4-7 is displayed, by way of example and not by way of limitation.
Below the advance payment information CT3, an advance payment refund button BT6 for returning the "500 yen" that User A.A. has received in advance from User C.C. is displayed.

When the Advance Payment Refund Button BT6 is tapped, the advance payment amount of "500 yen" is transferred from User A.A's electronic money account to User C.C's electronic money account. If the balance in User A.A's electronic money account is insufficient to cover the advance payment amount and the transfer cannot be executed, the display mode of the Advance Payment Refund Button BT6 may be grayed out, for example, to disable button operation, but this is not necessary. Also, when the Advance Payment Refund Button BT6 is tapped when the balance in User A.A's electronic money account is insufficient to cover the advance payment amount, the screen may transition to a screen that encourages charging from a bank account, but this is not necessary.

When the refund of the advance payment amount is completed using the advance payment amount refund button BT6, the display mode of the advance payment amount refund button BT6 may be grayed out in the subsequent display to disable button operation, or it may not be necessary to do so.

In addition, in the notification information display area NTR2, the linked payment result information CT2 and the advance payment information CT3 may be displayed together as one piece of information, but this is not essential.

Figure 4-8 shows an example of the screen transition on terminal 20C when the linked payment execution button BT5 is tapped on the linked payment confirmation screen on the right side of Figure 4-6.

The left side of Figure 4-8 is an example of a notification screen to which the user transitions by tapping the "Notification" icon from the main menu of the payment application, by way of example and not of limitation. Note that the user can also transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is sent to and displayed on terminal 20C.

The notification information display area NTR4 of this notification screen displays linked payment result information CT4 based on the execution of a linked payment, and advance payment information CT5 based on the occurrence of an advance payment in the linked payment.

The linked payment result information CT4 displays the amount paid by user C.C., "2,000 yen," the date and time of the payment, that the payment was completed using the linked wallet, and that the payment was made to "XX Musical Instruments." In addition, the icon of the group "Bandmates" to which the linked wallet was applied is displayed in the upper right corner.
At the bottom of the linked payment result information CT4, a details confirmation button with the words "Confirm details" is displayed for confirming the details of the payment. When this details confirmation button is tapped, the linked payment result display screen shown on the right side of FIG. 4-8 is displayed, by way of example and not limitation.

The advance payment information CT5 displays a display indicating that "500 yen" was advanced to user A. A through payment using the linked wallet. Also, in the upper right corner, an icon of the group "Bandmates" to which the linked wallet was applied is displayed.
Below that, a button for confirming the details of the payment is displayed, which is indicated by the words "Confirm Details." When the button for confirming the details is tapped, the linked payment result display screen shown on the right side of FIG. 4-8 is displayed, by way of example and not by way of limitation.
Below the advance payment information CT5, an advance payment request button BT7 for requesting a refund of the "500 yen" that user C.C. advanced to user A.A. is displayed.

The right side of FIG. 4-8 is an example of a linked payment result display screen displayed on terminal 20C.
On this screen, in the member payment result display area MRR2, instead of the advance payment amount refund button BT6, an advance payment amount request button BT7 for urging the return of the "500 yen" advanced by user C.C. is additionally displayed in the user A.A's item.

When the advance payment amount request button BT7 is tapped, information is transmitted to terminal 20A, prompting the user to remit the advance payment amount of "500 yen" from the electronic money account of user A.A to the electronic money account of user C.C., and the information is displayed on display unit 24 of terminal 20A.
In addition, when the balance of the electronic money account of user A.A is larger than the advance amount, the advance amount may or may not be automatically transferred from the electronic money account of user A.A to the electronic money account of user C.C.

In addition, if the refund of the advance payment has been completed, the display of the advance payment amount request button BT7 may be grayed out in the subsequent display to disable button operation, or it may not be necessary to do so.

<Processing>
The processing in this embodiment can be realized in the same manner as in Figures 3-4 to 3-5 by, for example and not by limiting it, assigning the terminal 20 of the group member who makes a payment using the linked wallet to the processing of terminal 20A, and the terminal 20 of the other group member to the processing of terminal 20B, and therefore repeated explanation will be omitted.

<Effects of the Fourth Embodiment>
This embodiment illustrates a configuration in which account linked payment is made by a first user account (not limiting, an example of a first account) of the group member making the payment, a second user account (not limiting, an example of a second account) of another group member, and a fourth user account (not limiting, an example of a fourth account linked with the first account and the second account) of a group member other than these.
As an example of an effect of an embodiment obtained by such a configuration, payment can be made not only by the first account and the second account, but also by a fourth account to which the first account and the second account are associated.

In the above, the shortfall in the first user account may be paid by at least the second user account and the fourth user account.
As an example of an effect of an embodiment obtained by such a configuration, the payment of a shortfall in a first account can be made by a plurality of accounts.

In the above, the payment of the shortfall in the first user account may be made only by the second user account.
As an example of the effect of the embodiment obtained by such a configuration, the payment of the shortfall in the first account can be made only by the second account, without using the fourth account.

In the above, the second user account that pays the shortfall in the first user account may be determined based on the balance of the electronic money account of the second user account.
As an example of an effect of an embodiment obtained by such a configuration, a second account to pay the shortfall of a first account may be determined based on the balance of the second account. By way of example and not by way of limitation, the second account with the largest balance may be determined to be the second account to pay the shortfall of the first account.

In the above, the second user account for paying the shortfall in the first user account may be selected based on an input to the terminal by the first user.
As an example of the effect of the embodiment obtained by such a configuration, the second account for paying the shortfall in the first account can be selected by the first user simply by inputting the selection into the terminal.

<Fourth Modification (1)>
In the fourth embodiment, when the shortfall is paid in advance by another linked account, the linked balance replenishment process is executed without seeking approval from the user of the account that pays in advance, but this is not limited to this. As a non-limiting example, when the shortfall needs to be paid in advance, approval from the user of the account that pays in advance may or may not be required.

<Display screen>
FIG. 4-9 is a diagram showing an example of the transition of the display screen on the terminal 20 when the other party's approval is required for the advance payment in the above example.
In this diagram, in the process of transitioning from the center of Fig. 4-6 to the right side of Fig. 4-6, approval must be obtained from user C.C. who will pay on behalf of the user. Specifically, when user C.C. is selected as a member requesting to pay on behalf of the user on the screen displayed on the display unit 24 of terminal 20A on the left side of Fig. 4-9, a notice screen as shown in the center of Fig. 4-9 is displayed on the display unit 24 of terminal 20C. This notice screen displays advance payment request information indicating that there has been a request for advance payment from user A.A.

The advance payment request information includes, in addition to information regarding the details of the advance payment, by way of example and not limitation, an approval button BTa for approving the advance payment and a rejection button BTb for rejecting the advance payment. When the approval button BTa is tapped, information indicating approval is sent from terminal 20C to server 10, and processing related to the advance payment is executed. As a result, the screen shown on the right side of Figure 4-9, which is similar to the screen on the right side of Figure 4-6, is displayed on display unit 24 of terminal 20A.

<Processing>
4-10 to 4-11 are flowcharts showing an example of the flow of processes executed by each device in this modified example.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

When the control unit 11 of the server 10 receives the balance replenishment request information from the terminal 20A via the communication I/F 14, the control unit 11 of the server 10 transmits the balance replenishment request information to the terminal (terminal 20B, as an example and not a limitation) of the user (user B.B., as an example and not a limitation) who covers the shortfall in user A.A's payment margin, requesting the shortfall in payment margin to be replenished via the communication I/F 14 (S224).

When balance replenishment request information is received from the server 10 via the communication I/F 22 (B150: YES), the control unit 21 of the terminal 20B causes the display unit 24 to display a selection screen for prompting the user A.A to cover the shortfall in the payment margin (B160).

If the user selects to cover the shortfall based on a user operation on the input/output unit 23 of the terminal 20B (B160: YES), the control unit 21 of the terminal 20B transmits balance replenishment authorization information authorizing the covering of the shortfall to the server 10 via the communication I/F 22 (B170).

If balance replenishment request information is not received (B150: NO), the control unit 21 of terminal 20B skips steps B160 and B170. Also, if it is selected not to cover the shortfall (B160: NO), the control unit 21 of terminal 20B skips step B170.

When balance replenishment authorization information is received from terminal 20B via communication I/F 14 (S226: YES), control unit 11 of server 10 executes linked balance replenishment processing based on the received balance replenishment request information (S230). When balance replenishment authorization information is not received, control unit 11 of server 10 does not execute step S230.

When the steps in Figure 4-11 are executed, the processing of each step in Figure 3-5 is then executed.

This modified example shows a configuration in which the second user account to pay the shortfall in the first user account is selected based on input by a user of one's own terminal 20 (an example of a first user, not limited to) to one's own terminal 20, and then determined based on the permission of the second user of the second user account.
As an example of an effect of an embodiment obtained by such a configuration, even if a second account is selected based on an input to a terminal by a first user, the second account can be prevented from being determined as the second account that pays the shortfall of the first account without the permission of the second user of the second account, by way of example and not limitation. As a result, it is possible to prevent the shortfall of the first account from being paid from the second account against the will of the second user.

<Fourth Modification (2)>
As described in the fourth embodiment, all group members in a group may be linked members, but only some of the group members in a group may be linked members. In other words, within the same group, it is possible to separate group members who participate in the account linking payment from group members who do not participate in the account linking payment.
This is because it is anticipated that some users may not wish to participate in account linking payment, even if they belong to the same group.

One example of the effect of this modified configuration is that it is possible to select users who make payments by linking multiple accounts, thereby improving user convenience.

Fifth Example
In the fourth embodiment, a description has been given of a case where one linked member (or one linked account) has insufficient payment margin during account linkage settlement. However, this is merely one example.
In this embodiment, a case will be described in which the payment margins of multiple linked members (or multiple linked accounts) are insufficient when executing account linkage settlement.

The contents described in the fifth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
5-1 is a diagram showing an example of the transition of a display screen displayed on the display unit 24 of the terminal 20A in this embodiment. It shows an example of the transition of a linked payment confirmation screen when a code payment is executed using a linked wallet.

Figure 5-1 is a diagram of the screen when the payment button BT1 is tapped on the screen on the right side of Figure 4-5. In this example, however, the electronic money account balance of user B.B. is assumed to be "500 yen."

On the left side of Figure 5-1, as an example, but not by way of limitation, a payment amount confirmation area PIR3 is displayed below the current location display area CLR1 as a linked payment confirmation screen. The current linked payment available amount of "3,000 yen" is displayed below the payment amount in the payment amount confirmation area PIR3. Also, a warning mark and the words "Insufficient balance" are displayed in the payment amount confirmation area PIR3, because the current linked payment available amount is lower than the payment amount.

In the paying member confirmation area PMR3, a warning mark is displayed in the upper left corner of the icons of user A.A and user B.B, indicating that their payment margins are "1,000 yen" and "500 yen," respectively.

At the bottom of the linked payment confirmation screen, there is displayed an advance request button BT4 for requesting that another member other than User A.A and User B.B advance the necessary amount "1,500 yen" that is the shortfall in User A.A's payment margin of "1,000 yen" (1,500 yen - 1,000 yen = 500 yen) and the shortfall in User B.B's payment margin of "500 yen" (1,500 yen - 500 yen = 1,000 yen) of the equal payment amount "1,500 yen".

The center of FIG. 5-1 shows an example of a linked payment confirmation screen when the advance payment request button BT4 is tapped.
In this screen, a payment member selection field PSR3 is displayed instead of the paying member confirmation field PMR3.

In the advance payment member selection area PSR3, under the text "Please select the member who will advance the payment" that prompts the user to select a member to advance the payment, user C.C. is displayed as a member who can cover the "3,000 yen" that is the sum of the equal payment amount "1,500 yen" plus the necessary advance amounts "500 yen" and "1,000 yen."

When user C.C is tapped and selected as the payer, the display transitions to the linked payment confirmation screen shown on the right side of FIG. 5-1.
In this screen, in the payment member confirmation area PMR3, the payment balance of user C.C. has increased to "3,000 yen", which is the sum of the total amount of the advance required amount "1,500 yen" to the equal payment amount "1,500 yen". Accordingly, the cooperative payment available amount in the payment amount confirmation area PIR3 has increased to "4,500 yen", the words "Insufficient balance" have disappeared, and instead the words "Payable" are displayed.
At the bottom of the linked payment confirmation screen, a linked payment execution button BT14 is displayed.

Figure 5-2 shows an example of the linked payment result display screen on each terminal when the linked payment execution button BT14 is tapped on the linked payment confirmation screen on the right side of Figure 5-1.

In the member payment result display area of these linked payment result display screens, by way of example and not limitation, it is displayed that user A.A has paid his remaining payment capacity of "1,000 yen", and as a result, his electronic money account balance is "0 yen". And user B.B has paid his remaining payment capacity of "500 yen", and as a result, his electronic money account balance is "0 yen". And user C.C has paid his remaining payment capacity of "3,000 yen", and as a result, his electronic money account balance is "3,000 yen".

In the member payment result display area MRR5 of the terminal 20A, in the item of the user C.C., an advance amount refund button BT15 for returning the "500 yen" that the user A.A. had the user C.C. advance. is displayed.
In the member payment result display area MRR6 of the terminal 20B, in the item of the user C.C., an advance amount refund button BT16 for returning the "1,000 yen" that the user B.B. had advanced to the user C.C. is displayed.
In the member payment result display area MRR7 of the terminal 20C, an advance payment request button BT17 for requesting a refund of the "500 yen" that user C.C. advanced to user A.A is displayed in the user A.A item, and an advance payment request button BT18 for requesting a refund of the "1,000 yen" that user C.C. advanced to user B.B is displayed in the user B.B item.

The functions of each advance payment refund button and advance payment claim button can be configured in the same way as the advance payment refund button BT6 and advance payment claim button BT7.

Figure 5-3 shows another example of the linked payment result display screen on each terminal when the linked payment execution button BT14 is tapped on the linked payment confirmation screen on the right side of Figure 5-1.

In FIG. 5-3, in the member payment result display area MRR5 of terminal 20A, in the item for user C.C, a refund button BT20 is displayed for users A.A and B.B to return the "1,500 yen" that user C.C paid in advance. In addition, in the item for user B.B, a request button BT19 is displayed for requesting a refund of the "1,000 yen" that user A.A paid in advance to user B.B.

In addition, in the member payment result display area MRR6 of terminal 20B, in the item for user A.A, a refund button BT21 for user B.B to return the "1,000 yen" that user A.A paid in advance is displayed.

In the member payment result display area MRR7 of terminal 20C, in the item for user A.A, a button BT22 for requesting a refund of the "1,500 yen" that user C.C. paid in advance to user A.A. is displayed.

<Processing>
The processing in this embodiment can be realized in a similar manner by applying the processing of Figures 3-4 to 3-5 as an example and not a limitation, in which the balance replenishment request information is used as information for advancing the shortfall in payment margins of multiple accounts, so a repeated explanation will be omitted.

<Fifth Modification (1)>
In the fifth embodiment, one of the linked members advances the payment margin shortfall that occurs among the other linked members, but the present invention is not limited to this.
As a non-limiting example, a shortfall in payment capacity that occurs among multiple affiliated members may or may not be distributed among the multiple affiliated members and paid in advance.
In addition, any shortfall in payment capacity that occurs among multiple linked accounts may or may not be paid in advance by multiple linked accounts.

Sixth Example
In the first to fifth embodiments, a method for implementing account linking payment by store-presented code payment has been described. However, this is merely one example.
In the sixth embodiment, a method for implementing account linking payment using customer-presented code payment will be described.

The contents described in the sixth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<System Configuration>
FIG. 6A is a diagram showing an example of a system configuration of a communication system 1B in this embodiment.
In communication system 1B, by way of example and not limitation, a server 10, multiple terminals 20 (terminal 20A, terminal 20B, terminal 20C, ...), and multiple store POS systems 40 (store POS system 40A, store POS system 40B, store POS system 40C, ...) are connected via a network 30.
The communication system 1A differs in that a store POS system 40 is added as a component.

FIG. 6B shows an example of the system configuration of the store POS system 40. In FIG.
The store POS system 40 is, by way of example and not limitation, a POS system that is installed and used in a store that is affiliated with the operator that operates the server 10, and includes, by way of example and not limitation, a store code reader device 50, a code register 60, and a store server 70.

The store code reader device 50 is communicatively connected to the code register 60 and store server 70 via a POS communication I/F 57 (for example, but not limited to, a wired communication I/F or wireless communication I/F within the store), and reads the code information displayed on the display unit 24 of the terminal 20 during a transaction at the code register 60. Then, based on the read code information, it sends payment request information to the server 10 via the communication I/F 54, and after the payment is made by the server 10, it receives information about the payment result from the server 10 via the communication I/F 54.

The store code reader device 50 includes, by way of example and not limitation, a control unit 51, an input/output unit 52, a communication I/F 54, a memory unit 55, a POS communication I/F 57, a code reader 58, and a clock unit 59.

By way of example only, the input/output unit 52 includes, by way of example and not limitation, a display unit 53 and a sound output unit 56.

The code reader 58 is a code reader for reading one-dimensional codes (one-dimensional code images), two-dimensional codes (two-dimensional code images), and, by way of example and not limitation, payment codes (payment code images) described below.

The code register 60 is, by way of example and not limitation, connected to the store code reader device 50 and the store server 70 via the POS communication I/F 57, and issues a receipt on which is printed information such as the total amount of the sold items and the electronic currency balance of the user of the terminal 20, based on the payment completion notification received by the store code reader device 50 from the server 10.

Also, by way of example and not limitation, a display may be provided integrally with the code register 60 or separately from the code register 60, with the display surface facing the customer.
The code register 60 is a cash register configured to be compatible with a payment application, and can also be called a stationary terminal compatible with a payment application.

The store server 70 manages various types of information, such as, but not limited to, store information about the store itself, information about products sold at the store, information about services provided at the store, and information about sales from the sale of products and provision of services at the store. The store server 70 is configured to be able to communicate with the store code reader device 50 and the code register 60 via the POS communication I/F 57, and is also configured to be able to communicate with external devices such as the server 10 via the network 30.

The store server 70 does not necessarily need to be configured to be able to communicate directly with the store code reader device 50, but may be configured to be able to communicate with the store code reader device 50 via the code register 60. As a non-limiting example, a payment completion notification or the like received by the store code reader device 50 from the server 10 can be sent to the code register 60, and then sent from the code register 60 to the store server 70.

<Display screen>
FIG. 6C is a diagram showing an example of a transition of screens displayed on display unit 24 of terminal 20 when account linkage payment is realized by a “customer-presented” payment.
The left side of Fig. 6-3 corresponds to the screen on the left side of Fig. 4-5. When the code payment icon IC3 is tapped on this screen, a code payment screen as shown in the center of Fig. 6-3 is displayed on the display unit 24 of the terminal 20A.

This code payment screen displays the linked wallet payment code, which is a code (code information) sent from server 10 and received by terminal 20A as a code for making an account linked payment in the group "Bandmates" and is a code used for making a "customer-presented" payment. Specifically, a one-dimensional payment code represented by a barcode, by way of example and not limitation, and a two-dimensional payment code represented by a QR code (registered trademark), by way of example and not limitation, are displayed. User A.A of terminal 20A can make a code payment using the linked wallet by presenting the above code payment screen to a store clerk at the code register and having the payment code read by a store code reader device.

The right side of Figure 6-3 shows a screen displayed on the display unit 24 of terminal 20A based on the fact that user A.A.'s payment margin is insufficient, and is similar to the screen on the left side of Figure 4-6, by way of example and not limitation.

<Processing>
FIG. 6D is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), processing performed by the control unit 11 of the server 10, and processing performed by the control unit 51 of the store code reader device 50.

The control unit 11 of the server 10 generates an associated wallet payment token. The control unit 11 of the server 10 then generates associated wallet code information, which is code information including this associated wallet payment token. The associated wallet code information includes, by way of example and not limitation, a payment code (image information) in which the identifier of the associated wallet payment token is encoded as a one-dimensional code (such as a barcode) or a two-dimensional code (such as a QR code).

Then, the control unit 11 of the server 10 transmits the generated linked wallet code information to the terminal 20A via the communication I/F 14 (S105).

When the control unit 21 of the terminal 20A receives the linked wallet code information from the server 10 via the communication I/F 22, the control unit 21 causes the display unit 24 to display the received linked wallet code information (A105). Specifically, as a non-limiting example of the linked wallet code information, the control unit 21 causes the display unit 24 to display a payment code.

When the identifier and expiration date of the linked wallet payment token are included in the linked wallet code information, the control unit 21 of terminal 20A may or may not display the identifier and expiration date.

In addition, if the linked wallet payment token expires while the payment code is being displayed, the control unit 21 of terminal 20A may, or may not, send information to server 10 via communication I/F 22 requesting regeneration of the linked wallet payment token.
In this case, the control unit 21 of the server 10 regenerates the associated wallet payment token and the associated wallet code information, and transmits the associated wallet code information to the terminal 20A via the communication I/F 14. Then, upon receiving the regenerated associated wallet code information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A can cause the display unit 24 to re-display the payment code and the expiration date.

The control unit 51 of the store code reader device 50 executes the store payment process, and a predetermined planned payment amount (for example, but not limited to, "4,500 yen") is input to the control unit 51 based on an operation on the input/output unit 52 of the store code reader device 50. The control unit 51 of the store code reader device 50 then uses the code reader 58 to read the payment code displayed on the display unit 24 of the terminal 20A (P100). In this case, since the payment code displayed on the display unit 24 is associated with the linked wallet payment token, the reading result of the code reader 58 includes the linked wallet payment token as the payment token.

The control unit 51 of the store code reader device 50 sends linked payment request information, which includes, by way of example and not limitation, the store ID, the planned payment amount, and the read linked wallet payment token, to the server 10 via the communication I/F 54 (P110).

When the communication I/F 14 receives the linked payment request information from the store code reader device 50, the control unit 11 of the server 10 calculates the linked payment available amount and determines whether the calculated linked payment available amount is lower than the planned payment amount (whether linked payment available amount - planned payment amount < 0) (S215).

If the linked payable amount - the planned payment amount is greater than or equal to 0 (S215: NO), the control unit 11 of the server 10 searches for the linked wallet ID from the requested linked wallet payment token, and executes a customer-presented linked payment process, which is an example of a customer-presented account linked payment process, in which the planned payment amount is paid to the affiliated store specified by the store ID into the linked wallet (S115).

The customer-presented type coordinated payment process is similar to the store-presented type coordinated payment process.
However, the difference is that in the customer-presented linked payment process, the control unit 11 of the server 10 transmits payment result information regarding the payment result, whether or not the payment of the planned payment amount using the linked wallet was successful, to the store code reader device 50 via the communication I/F 14.

If the linked payable amount - the planned payment amount is less than 0 (S215: YES), the control unit 11 of the server 10 executes steps S220 and S230, and then executes step S115.

After executing step S115, the control unit 11 of the server 10 executes step S240.

When payment result information is received from the server 10 via the communication I/F 54, the control unit 51 of the store code reader device 50 displays the payment result information on the display unit 53 and ends the process.

In this embodiment, the terminal 20 performs processing related to account linked payment (not limiting, an example of processing related to the first payment) using the control unit 21 based on a first user account (not limiting, an example of the first account) and a second user account linked to the first user account (not limiting, an example of the second account associated with the first account).
Furthermore, based on the account linking settlement, the terminal 20 receives remittance request information (not limited to this, an example of first information related to remittance to the second account) via the communication I/F 22 .
Then, the terminal 20 displays the received remittance request information (not limited to this, but an example of the first display based on the first information) on the display unit 24 .
In this case, the terminal 20 receives linked wallet code information (not limited to, but an example of code information) for performing account linking payment based on the first user account and the second user account from the server 10 via the communication I/F 22, and displays the received linked wallet code information on the display unit 24. Then, the linked wallet code information displayed on the display unit 24 is read by the store code reader device, and based on this, the server 10 performs the account linking payment.
As an example of an effect of the embodiment obtained by such a configuration, a first payment can be realized by at least two associated accounts by performing a process related to the first payment by the terminal of the first user based on a first account of the first user of the terminal and a second account associated with the first account by a control unit of the terminal. Also, first information related to the transfer of money to the second account by the first payment can be notified to the first user of the terminal. As a result, by way of example and not of limitation, the first user can be prompted to transfer money to the second account. Also, the first payment can be realized by a simple method such as having a code reader in a store read code information for making the first payment based on the first account and the second account.

Seventh Example
In the first to sixth embodiments, the method of prompting remittance each time based on account linkage settlement has been described, but the present invention is not limited to this.
In the seventh embodiment, a method for settling payments made on behalf of a user collectively based on a plurality of account linked settlements will be described. In relation to this, a method for discarding a linked wallet will also be described.

"Deleting a linked wallet" means that the linked wallet will no longer be usable and will be invalidated for all linked accounts at once.

The contents described in the seventh embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 7-1 is a diagram showing an example of the data configuration of the third linked wallet management database 157C, which is an example of the linked wallet management database 157 used in this embodiment.
The third associated wallet management database 157C stores associated wallet management data as management data for each associated wallet.

Each linked wallet management data stores, by way of example and not limitation, a group ID, a group name, payment history data, and advance payment history data.

The group ID, group name, and payment history data are the same as those in the second linked wallet management database 157B.

The advance payment history data is data related to the advance payment of money incurred in each transaction stored in the payment history data, and by way of example and not limitation, the transaction ID, the advance recipient ID, the advance payer ID, and the advance payment amount are stored in association with each other.

The transaction ID stores the transaction ID included in the payment history data in which money was paid on behalf of the other party.

The reimbursed party ID stores the application ID of the user account that has received money in advance (hereafter referred to as the "reimbursed party").

The advance payer ID stores the application ID of the user account that advanced the money (hereafter referred to as the "advance payer").

The amount of money paid in advance by the payer (hereinafter referred to as the "payment in advance amount") is stored in the "payment amount" field.

<Display screen>
FIG. 7B is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Figure 7-2 is the main screen of the linked wallet similar to that of the left side of Figure 4-5, but the display is slightly different. Specifically, in the area indicating that it is a linked wallet of the group "Bandmate", a history button BT25 for displaying the history of payments made in the linked wallet of the group "Bandmate" is displayed.

When the history button BT25 is tapped, the screen transitions to the screen shown in the center of FIG. 7-2.
This screen displays information about the purchase history of goods and services, including information about payments made with the linked wallet of the group "Bandmates." In this example, information about two purchase histories, "XX Musical Instruments" and "YY Studio," is displayed, with a check box associated with each purchase history. When the check box for the purchase history for which settlement is desired is checked and the lump-sum settlement button BT26 at the bottom of the screen is tapped, all checked purchase histories can be settled together.

In addition, at the bottom of the screen, there is provided a linked wallet discard button BT30 containing the words "Discard linked wallet" for discarding the linked wallet. When this linked wallet discard button BT30 is tapped, the server 10 performs the linked wallet discard process.

In addition, in the linked wallet destruction process, the linked wallet data is not deleted from the linked wallet management database 157, but the execution of account linked payments based on the destroyed linked wallet may or may not be prohibited on the terminal 20 side or the server 10 side.

The right side of FIG. 7-2 is a diagram showing an example of a screen that is displayed when the lump-sum settlement button BT26 is tapped with two purchase histories checked in the center of FIG. 7-2.
In this screen, the lump-sum settlement information for executing the lump-sum settlement is displayed in a pop-up format in the center of the screen shown in the center of Fig. 7-2. In this example, the lump-sum settlement information displays a message indicating that "500 yen" needs to be transferred from user A.A to user B.B, and "1,000 yen" needs to be transferred from user A.A to user C.C, along with a "Yes" button for approving this content and making the lump-sum settlement, and a "No" button for canceling the lump-sum settlement.

When the "Yes" button is tapped, a remittance of "500 yen" is made from user A.A to user B.B, and a remittance of "1,000 yen" is made from user A.A to user C.C via server 10.

<Processing>
7-3 and 7-4 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
These figures show, from left to right, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

When the control unit 11 of the server 10 executes the linked balance replenishment process (S230), it adds the advance payment of the required amount that occurred during the linked balance replenishment process to the advance payment history data and stores it (S235).

When steps A230, B200, and S240 are executed, terminal 20A, terminal 20B, and server 10 execute the linked wallet settlement process.

FIG. 7-5 is a flowchart showing an example of the processing flow of the linked wallet settlement process.
In the associated wallet settlement process, first, the control unit 11 of the server 10 refers to the third associated wallet management database 157C and determines whether or not a deferral history is recorded in the deferral history data of the associated wallet management data (S400).
If no advance payment history is recorded in the advance payment history data (S400: NO), the control unit 11 of the server 10 ends the process.

On the other hand, if a payment history has been recorded (S400: YES), the control unit 11 of the server 10 transmits payment history information including the contents of the payment history data to the terminals 20A and 20B, which are the terminals of the affiliated members, via the communication I/F 14 (S410).

When the advance payment history information is received from the server 10 via the communication I/F 22 (A400: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display the received advance payment history information (A410). When the advance payment history information is not received (A400: NO), the control unit 21 of the terminal 20A ends the process.

Based on a user operation on the input/output unit 23 of the terminal 20A, one or more transaction histories are selected from the advance payment history in which the advance payer ID in the advance payment history information is the user account of the terminal, and if it is selected to return the advance payment amount to the user account of the advance payer ID (A420: YES), the control unit 21 of the terminal 20A sends linked wallet settlement request information including the transaction IDs of those advance payment histories to the server 10 via the communication I/F 22 (A430).

In addition, in steps A420 and A430, one or more transaction histories may be selected from the deferred payment history in which the deferred payment payer ID in the deferred payment history information is the user account of the own terminal, and linked wallet settlement request information including a request for refund of the deferred payment amount to the user of the user account of the deferred payment payer ID may be generated and transmitted, or it is not necessary to do so.
In addition, the linked wallet settlement request information may or may not include a return of the advance amount to the user account of the payer ID and a request for the advance amount to the user account of the payee ID.

When linked wallet settlement request information is received from terminal 20A via communication I/F 14 (S420: YES), control unit 11 of server 10 executes linked wallet settlement processing (S430).

In the associated wallet settlement process, based on the received associated wallet settlement request information, the advance amount for each selected transaction ID is transferred from the account of the payer ID to the account of the payer ID.
Regarding the claim for the advance amount, information including a message urging the remittance may be sent to the terminal of the account of the payee ID.

When the associated wallet settlement process is executed, the control unit 11 of the server 10 sends associated wallet settlement result information, which is the processing result of the associated wallet settlement, to the terminal of the account of the payer ID and payer ID of the advance payment history for which the settlement was performed, by way of example and not limitation (S440).
The results of remittances and the like relating to the history of payments made on behalf of the recipient may or may not be transmitted to all terminals of the associated members.

Then, the control unit 11 of the server 10 ends the process.
If linked wallet settlement request information is not received (S420: NO), the control unit 11 of the server 10 ends the process.

When the associated wallet settlement result information is received from the server 10 via the communication I/F 22 (A440: YES), the control unit 21 of the terminal 20A displays the received associated wallet settlement result information on the display unit 24 (A450) and terminates the processing.
If the linked wallet settlement result information is not received (A440: NO), the control unit 21 of the terminal 20A terminates the process.

The processing for terminal 20B and the terminals of other affiliated members is the same as for terminal 20A.

After executing the associated wallet settlement process, the control unit 21 of the terminal 20A displays a selection screen for selecting whether or not to discard the associated wallet (A310). If discarding the associated wallet is selected based on a user operation on the input/output unit 23 of the terminal 20A (A310: YES), the control unit 21 of the terminal 20A transmits associated wallet discard request information requesting the discarding of the associated wallet to the server 10 via the communication I/F 22 (A320), and executes the associated wallet settlement process (A330).

If it is selected not to discard the linked wallet (A310: NO), the control unit 21 of the terminal 20A determines whether or not to receive linked wallet settlement request information from the server 10 via the communication I/F 22 (A340), and if received (A340: YES), executes the linked wallet settlement process (A330). If not received (A340: NO), the process proceeds to step A100.

After executing the associated wallet settlement process, if associated wallet destruction request information is received from the associated member's terminal via the communication I/F 14 (S310: YES), the control unit 11 of the server 10 sends the associated wallet settlement request information to each associated member's terminal via the communication I/F 14 (S320), and executes the associated wallet settlement process (S330).

If the linked wallet destruction request information is not received (S310: NO), the control unit 11 of the server 10 proceeds to step S100.

After executing the associated wallet settlement process, the control unit 11 of the server 10 executes the associated wallet destruction process (S340).
In the associated wallet destruction process, each record of the associated wallet management data of this associated wallet is deleted from the third associated wallet management database 157 C. Note that, when the associated wallet management data is identified by a group ID, the group management data of the group ID for which the associated wallet destruction has been selected from the group management data in the group management database 159 may or may not be deleted.

The linked wallet destruction process may be configured not to be executed if unsettled advance history remains in the advance history data after the linked wallet settlement process, or may be executed even if advance history remains.

When the associated wallet discard process is executed, the control unit 11 of the server 10 sends associated wallet discard information, including information that the associated wallet has been discarded and can no longer be used, to each terminal of the associated members via the communication I/F 14 (S350), and ends the process.

After executing the associated wallet settlement process, the control unit 21 of the terminal 20A receives associated wallet destruction information from the server 10 via the communication I/F 22, and causes the display unit 24 to display the received associated wallet destruction information (A350). The control unit 21 of the terminal 20A then ends the process.

The processing of terminal 20B is the same as that of terminal 20A from step B300 onwards, so a repeated explanation will be omitted.

<Effects of the Seventh Example>
In this embodiment, the terminal 20 performs processing related to a payment (not limited to, but an example of a third payment) based on the first user account and a third user account that is different from the second user account and associated with the first user account, using the control unit 21. Furthermore, the terminal 20 receives third information related to transferring money to the third user account based on this payment, using the communication I/F 22, and displays a third display based on the received third information on the display unit 24.
The terminal 20 is configured to perform processing related to transferring an amount based on the first information from the first user account to the second user account based on input by the user of the terminal 20 on the first display and the third display, using the control unit 21, and to perform processing related to transferring an amount based on the third information from the first user account to the third user account using the control unit 21.
As an example of the effect of an embodiment obtained by such a configuration, remittance from a first account to multiple accounts can be realized by the simple method of the first user inputting information into the first and third displays.

Eighth Example
In the first to seventh embodiments, the method of linking user accounts in the account linking payment has been described, but the present invention is not limited to this.
In the eighth embodiment, the concept of a common wallet is introduced. Then, payments are made using a linked wallet that links this common wallet (common account) with a user account.

The contents described in the eighth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 8A is a diagram illustrating an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The memory unit 15 stores a payment application management processing program 151, account registration data 153, an account management database 155, an associated wallet management database 157, and, by way of example and not limitation, a common wallet management database 161.

Now, we will explain the common wallet in detail with reference to the common wallet management database 161.

A shared wallet is a type of electronic money account that is set up in advance by multiple users of a payment application before making a payment.

In a shared wallet, multiple users can use the balance to make payments. In the following, users who can use the shared wallet are referred to as "shared wallet members."

To use a shared wallet, a user first performs an operation to generate a shared wallet. This generation requires, by way of example and not limitation, information that identifies the electronic money account of the shared wallet member (by way of example and not limitation, an application ID).

The shared wallet management database 161 is a database for the server 10 to manage the shared wallet, and an example of the data configuration thereof is shown in FIG.
The common wallet management database 161 stores common wallet management data as management data for each common wallet ID for uniquely identifying a common wallet.

Each common wallet management data stores, by way of example and not limitation, a common wallet ID, a common wallet name, a common wallet balance, and a common wallet member ID in association with each other.

The common wallet ID is the account of the common wallet in the payment application (hereinafter referred to as the "common account" as appropriate).
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 the application ID of the common wallet member that is specified when the common wallet is created.

It is also possible to add a new common wallet member by adding an application ID to the common wallet member ID after generating the common wallet. Also, multiple application IDs owned by the same user may or may not be stored in the common wallet member ID.

When a common wallet is created, its common wallet balance is "0". Before making a payment, common wallet members transfer electronic money from their respective electronic money accounts to the common wallet to increase the common wallet balance.

In addition, common wallet members can also charge the common wallet (convert to electronic money and transfer) from an account (for example, but not limited to, a bank account) of an external financial institution registered with the payment service.

When a common wallet is no longer needed, a common wallet discard operation is performed to cancel the existing common wallet. When the common wallet discard operation is executed, the common wallet balance is divided (evenly) among the number of common wallet members and transferred to each of the common wallet members' electronic money accounts. Then, after the common wallet balance becomes "0", the record of that common wallet management data is deleted from the common wallet management database 161.

FIG. 8-3 is a diagram showing an example of the data configuration of the fourth linked wallet management database 157D, which is an example of the linked wallet management database 157 used in this embodiment.
The fourth associated wallet management database 157D stores associated wallet management data as management data for each associated wallet.

Each linked wallet management data stores, by way of example and not limitation, a linked wallet ID, linked account data, and payment history data.
The linked wallet ID and payment history data are, by way of example and not limitation, similar to those of the first linked wallet management database 157A.

Linked account data is data related to the account that is linked to make an account linked payment, and by way of example and not limitation, the wallet ID and name are stored.

The wallet ID is an identifier for the user account or common wallet linked with this linked wallet; in the case of a user account, the application ID is stored, and in the case of a common wallet, the common wallet ID is stored.

The name is a name associated with the application ID or common wallet ID. In the case of a user account, the user name is stored in association with the wallet ID, and in the case of a common wallet, the common wallet name is stored in association with the wallet ID.

The number of accounts stored in the linked account data is not limited to two. Three or more accounts may or may not be linked. Also, only the common wallet may or may not be linked.

In other words, in this embodiment, linked accounts include user accounts and shared wallet accounts.

Note that it is possible to introduce the group described in the fourth embodiment and add the account information of the common wallet (common wallet ID and common wallet name) to the group member data in the group management database 159, but this is not essential.

<Processing>
The processing in this embodiment can be realized in the same manner as in Figures 3-4 to 3-5 by treating the linked account as a common wallet and the common wallet ID as an application ID, as an example and not a limitation, so a repeated explanation will be omitted.

Here, we will explain in more detail what happens when the loan/borrow/return process is executed in step S280 of Figure 3-5 and money is transferred to the common wallet.

As an example and not a limitation, assume that the common wallet is composed of an account for user B.B. and an account for user C.C. In this case, when a predetermined amount (as an example and not a limitation, the entire amount to be returned that the common wallet has paid in advance) is transferred to the common wallet, half of the predetermined amount may or may not be transferred from the balance of electronic money in the common wallet (common wallet balance) to the accounts of users B.B. and C.C., who are common wallet members, respectively, as an example and not a limitation.

In other words, when a refund of the required return amount paid in advance to the common wallet is executed, the refund may or may not be made to the common wallet member's account via the common wallet.

<Effects of the Eighth Example>
In this embodiment, the second account is a common wallet account (not limiting, but an example of a common account to which multiple users can make payments), and the terminal 20 is configured to execute a process for transferring money from the first user account to the common wallet account based on an input by the user of the terminal 20 in response to a selection screen displayed on the display unit 24 for selecting whether or not to transfer the recommended transfer amount from the first user account to the common wallet account (not limiting, but an example of a first display).
As an example of an effect of an embodiment obtained by such a configuration, payment can be made based on the account of the first user and a common account to which multiple users can make payments.
Furthermore, an amount based on the first information can be transferred from the first account to the common account by the simple method of the first user inputting information on the first display.

In this case, each of the user accounts of the multiple users may be associated with the common wallet account as a common wallet member account, and when making a refund, the amount required for return (which is not limited to, but is an example of a second amount that is at least a part of the first amount) may be transferred from the common wallet account to each of the user accounts of the common wallet members.
As an example of an effect of an embodiment obtained by such a configuration, a second amount, which is at least a portion of the first amount, can be transferred from the common account to each of the accounts of multiple users associated as the common account.
As a non-limiting example, when a certain amount of money is accumulated in a common account, the refundable amount may be refunded from the common account to each of the accounts of multiple users as a second amount.

Ninth Example
In the above embodiment, in the account linked payment, the linked accounts are described as each paying (splitting) an equal payment amount obtained by dividing the planned payment amount equally among the number of linked accounts, but the present invention is not limited to this.
In the ninth embodiment, a method of sharing the burden other than splitting the cost will be described.

The contents described in the ninth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

As a non-limiting example, consider a case where the accounts of three users, user A.A, user B.B, and user C.C, are linked as linked accounts, and a payment of "3,000 yen" is made using the linked accounts. Also, assume that the electronic money account balance of user A.A's account is "4,000 yen," the electronic money account balance of user A.A's account is "500 yen," and the electronic money account balance of user A.A's account is "2,000 yen."

Figure 9-1 shows a table showing the amount of burden for each collaborating member in this case.

Pattern 1 is the same as before, where the bill is split evenly.
In this case, all of the linked members share the payment equally, and each member's share is 1,000 yen. At this time, user B.B does not have enough payment capacity, so he or she cannot make the payment.

Pattern 2 is an example in which some of the linked accounts do not bear the burden, and the remaining linked accounts equally divide the burden.
In this case, as a non-limiting example, the amount charged to user B.B is set to "0", and users A.A and C.C equally divide "3,000 yen" and each pay "1,500 yen".

Pattern 3 is an example in which some of the linked accounts do not contribute, and the remaining linked accounts contribute in a disproportionate manner.
As a non-limiting example, assume that the amount borne by user B.B is "0", and users A.A and C.C each contribute "3,000 yen" in the ratio of their respective electronic money account balances (user A.A:user C.C = 2:1).

Pattern 4 is an example in which, when some of the linked accounts are unable to cover the equal payment amount, those accounts pay the entire balance of their electronic money accounts, and the remaining balance is shared equally among the remaining linked accounts.
As a non-limiting example, user B.B. will pay "500 yen", which is the limit he or she can pay, out of the equal payment amount of "1,000 yen", and the remaining "2,500 yen" will be equally divided between user A.A. and user C.C.

Pattern 5 is an example in which, when some of the linked accounts are unable to cover the equal payment amount, those accounts pay the entire balance of their electronic money accounts and the remaining amount is distributed among the remaining linked accounts.
As a non-limiting example, user B.B. pays "500 yen", which is the limit he or she can pay, out of the equal payment amount of "1,000 yen", and of the remaining "2,500 yen", user A.A., who has a larger balance in his or her electronic money account, pays the sum of the equal payment amount of "1,000 yen" and the "500 yen" equivalent to the shortfall in user B.B.'s account ("1,500 yen"), and user C.C. pays the equal payment amount of "1,000 yen".

In the above embodiments, the payment amount is divided equally, and if a shortfall occurs, the shortfall is paid in advance and returned.
However, as an example and not a limitation, it is also possible to vary the proportion of the payment amount shared among linked accounts rather than sharing the amount equally among linked accounts, as in patterns 2 to 5 above.

Tenth Example
In the above embodiment, in the account linking payment, the accounts are linked in advance, that is, the accounts are already linked, but the present invention is not limited to this.
In the tenth embodiment, a method for linking accounts will be described.

The contents described in the tenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 10A is a diagram showing an example of the data configuration of the fifth linked wallet management database 157E, which is an example of the linked wallet management database 157 used in this embodiment.
The fifth linked wallet management database 157E stores linked wallet management data as management data for each linked wallet.

By way of example and not limitation, each linked wallet management data stores a group ID, a group name, linked status management data, payment history data, and advance payment history data. By way of example and not limitation, the group ID, group name, payment history data, and advance payment history data are the same as those of the third linked wallet management database 157C.

The linkage status management data is data that indicates the linkage status of each account of the group members in this linked wallet.
In the cooperation status management data, as a non-limiting example, an application ID, a user name, and cooperation approval are stored in association with each other.

The application ID and user name are the group member information corresponding to this linked wallet.

The link approval is a flag used to determine whether or not each user (user account) has approved making a payment using this linked wallet; by way of example and not limitation, if approval has been given, “Done” is stored, and if approval has not been given, “Not yet” is stored.
In the following, the act of a user (user account) approving a payment using a linked wallet may be referred to as “approving linkage.”

A "linked account" can be, by way of example and not limitation, an account that is a candidate for linking to a linked wallet, regardless of whether linkage has been approved.
Similarly, a "linked member" may be, by way of example and not limitation, a user who is a candidate for linking a linked wallet, with or without linkage approval.

Note that this is not limiting, and an account that has been approved for linkage may or may not be defined as a "linked account."
Similarly, a user who has been approved for collaboration may or may not be defined as a "collaboration member."

<Display screen>
FIG. 10B is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Figure 10-2 is an example of a group selection screen, where the current location display area CLR1 displays the words "Linked Wallet," indicating that the linked wallet function is being used, and below that are the words "Please select a group," prompting the user to select a group with which to link the wallets.

Below that, groups to which the user of this terminal (user A.A. in this case) belongs are listed, grouped together on each line. Each group item shows, by way of example and not limitation, the group icon, group name, and the number of members that make up the group.

As a non-limiting example, when the group "Bandmates" is tapped as a group that will link wallets, a group information display screen such as that shown in the center of FIG. 10-2 is displayed, as a non-limiting example.
In this screen, a linked wallet information display area WIR1 is displayed below the current location display area CLR1. In the linked wallet information display area WIR1, the words "Request wallet linkage?" are displayed, and below that, a list of members belonging to the group "Bandmates" who will link wallets is displayed. By way of example and not of limitation, this screen shows that the group "Bandmates" is a group including three members, user A.A, user B.B, and user C.C.

In addition, at the bottom of the screen, a wallet linkage request button BT35 is provided, which is indicated by the text "Request wallet linkage." When this wallet linkage request button BT35 is tapped, linkage group selection information is sent from terminal 20A to server 10 to request wallet linkage from other members in the group.

When the wallet link request button BT35 is tapped, the main screen of the linked wallet before other members of the group "Bandmates" linked their wallets is displayed, as shown on the right side of Figure 10-2.

On this screen, below the current location display area CLR1, a code reader icon IC2 indicated with the words "code reader" for making a "store-presented" code payment using the linked wallet, and a code payment icon IC3 indicated with the words "code payment" for making a "customer-presented" code payment are displayed side by side.
In addition, since the linked wallet has not yet been enabled on this screen, the code reader icon IC2 and the code payment icon IC3 will not function even if tapped, and are displayed grayed out.

Below these icons is the name of the group that is the subject of the linked wallet, "Bandmates," and below that is the linked member information display area MIR1, which shows the linking status of each member of the group "Bandmates."

In the linked member information display area MIR1, the name of each member who is the target of wallet linkage and the linkage status are displayed in association with each other on a line basis. As a non-limiting example, it is shown that user A.A is in the process of wallet linkage and that the balance of user A.A's electronic money account is "1,000 yen."
It is also shown that user B.B. and user C.C are in the process of requesting wallet linkage, but the linkage has not yet been approved.

The left side of Fig. 10-3 is an example of a notification screen on the terminal 20B of user B, who has been requested to link wallets based on the tapping of the wallet link request button BT35 in Fig. 10-2.
On this notification screen, the word "Notification" is displayed in the current location display area CLR2, indicating that this is the notification function of the payment application.

Below the current location display area CLR2, a notification NT1 is displayed to inform user B.B that user A.A has requested wallet linking. In addition, below the notification NT1, a notification information display area NTR1 for displaying notification information is configured, and information corresponding to the notification NT1 is displayed in this notification information display area NTR1.

In this example, the notification information display area NTR1 displays wallet linkage approval confirmation information CT1, which contains the text “A request for wallet linkage has been received from A.A.” along with the text and icon of the group “Bandmates” that will be performing the wallet linkage.
At the bottom of the wallet linkage approval confirmation information CT1, there are displayed a wallet linkage approval button indicated with the word “Link” to approve wallet linkage with members of the group “Bandmates,” and a wallet linkage rejection button indicated with the word “Decline” to not approve the wallet linkage.

By way of example and not limitation, when the wallet link reject button is tapped, a notification indicating that wallet linking has failed is sent to and displayed on the device of the member currently linked to the linked wallet (in this example, user A.A.). The linked wallet in the group "Bandmates" is then discarded, and processing ends.

The center of Figure 10-3 is an example of the linked wallet main screen when the wallet linkage approval button in the wallet linkage approval confirmation information CT1 is tapped. On this screen, the linked member information display area MIR1 shows that user B.B. is currently linking his wallet, and that the balance in user B.B.'s electronic money account is "3,000 yen."

In addition, in the center of FIG. 10-3, a notification indicating that user B.B. has linked their wallet may or may not be displayed.

The right side of Figure 10-3 shows an example of the linked wallet main screen that is displayed when all members of a group have linked their linked wallets. On this screen, the linked member information display area MIR1 displays the balance of each user's electronic money account. Additionally, the code reader icon IC2 and code payment icon IC3 are no longer grayed out, and touch operation is enabled.

<Processing>
10-4 and 10-5 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
These figures show, from left to right, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

First, the control unit 21 of the terminal 20A sends group list request information to the server 10 via the communication I/F 22 to request information regarding a list of groups in order to select a group to which the linked wallet will be applied (A500).

When the group list request information is received from terminal 20A via communication I/F 14, the control unit 11 of server 10 refers to the group management database 159 and, as a non-limiting example, transmits group list information consisting of a list of group IDs and group names to terminal 20A via communication I/F 14 (S500).

When a group to which the linked wallet is to be applied is selected from the group list information based on a user operation on the input/output unit 23 of the terminal 20A, the control unit 21 of the terminal 20A transmits linked group selection information including at least the group ID to the server 10 via the communication I/F 22 (A510).

When the linkage group selection information is received from terminal 20A via communication I/F 14, control unit 11 of server 10 adds management data of the group ID and the linked group name as a new record to the linked wallet management data of fifth linked wallet management database 157E. Control unit 11 of server 10 also refers to group management database 159 and writes user information of the group (application ID and user name as an example, but not limited to) to the linkage status management data of the added linked wallet management data. Control unit 11 of server 10 then sets the linkage approval to "Not Approved" in the item of each user in the linkage status management data, and sets the linkage approval of the user of the terminal that sent the linkage group selection information to "Approved" (S505).

Then, the control unit 11 of the server 10 transmits wallet linkage approval confirmation information, which is approval confirmation information as to whether or not to approve the wallet linkage, to the terminal of the user for which linkage approval has not been granted (terminal 20B as an example and not as a limitation) via the communication I/F 14 (S510).

When the wallet linkage approval confirmation information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B causes the wallet linkage approval confirmation information to be displayed on the display unit 24 (B500). If approval of the wallet linkage is selected based on a user operation on the input/output unit 23 of the terminal 20B (B500: YES), the control unit 21 of the terminal 20B transmits the wallet linkage approval information to the server 10 via the communication I/F 22 (B510).

If it is selected not to approve the wallet linkage (B500: NO), the control unit 21 of terminal 20B skips step B510.

When the wallet linkage approval information is received from the terminal that sent the wallet linkage approval confirmation information via the communication I/F 14 (S520: YES), the control unit 11 of the server 10 changes the linkage approval in the linkage status management data for the application ID of the received terminal to "Done." Then, as a non-limiting example, linked member information including the application ID and electronic money account balance of the linked member is sent to the terminal of each member of the group (S530).

If the wallet linkage approval information is not received (S520: NO), the control unit 11 of the server 10 waits to receive the wallet linkage approval information. If the wallet linkage approval information is still not received after a certain period of time has passed, the control unit 11 of the server 10 may or may not end the process after transmitting information to each terminal indicating that the wallet linkage has failed.

After executing step S530, the control unit 11 of the server 10 determines whether the linkage approval in the linkage status management data has been set to "done" for all users (S540). If all group members have agreed to wallet linkage (S540: YES), the control unit 11 of the server 10 sends linked wallet information indicating that a linked wallet payment token for this group (linked wallet) can now be generated and that the linked wallet can now be used to the terminals of each group member via the communication I/F 14 (S550). Then, as an example and not a limitation, the control unit 11 of the server 10 proceeds to step S100 in FIG. 7-3.

If all group members have not yet agreed to wallet linking (S540: NO), the control unit 11 of the server 10 returns the process to waiting for receipt of wallet linking approval information.

When the linked member information is received from the server 10 via the communication I/F 22 (A515: YES), the control unit 21 of the terminal 20A causes the linked member information to be displayed on the display unit 24 (A520). Then, the control unit 21 of the terminal 20A waits to receive linked wallet information.

When the associated wallet information is received from the server 10 via the communication I/F 22 (A530: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display a message indicating that the associated wallet has been activated based on the associated wallet information, and notifies the user that the associated wallet in the selected group is available for use (A540). Then, as an example and not a limitation, the control unit 21 of the terminal 20A receives associated wallet code reader information from the server 10, and proceeds to step A100 in FIG. 7-3.

If the associated wallet information is not received (A530: NO), the control unit 21 of the terminal 20A waits again to receive associated member information.
In addition, when information indicating that wallet linkage has failed is received from server 10, control unit 21 of terminal 20A may or may not terminate the processing.

In terminal 20B, steps B515 to B540 are executed in the same manner as steps A515 to A540. Then, as an example and not a limitation, when the control unit 21 of terminal 20B receives linked wallet information from server 10, it moves the process to step B200 in FIG. 7-3.

However, if linked wallet information is not received (B530: NO), it is determined whether the account of the terminal has already been linked to a wallet (B550).

If the own terminal has already been linked (B550: YES), the control unit 21 of the terminal 20B waits to receive linked member information again.
If the terminal itself has not yet performed linkage (B550: NO), the control unit 21 of the terminal 20B returns the process to step B500.

<Tenth Modification (1)>
In the tenth embodiment, a method for introducing an associated wallet in a group previously configured with a plurality of members is illustrated, but the present invention is not limited to this. As a non-limiting example, in an associated wallet configured in the method (1) of the fourth embodiment (a method for registering a plurality of associated accounts in associated account data), the associated wallet may or may not be made available based on the authorization of the associated member.

In this case, as an example and not a limitation, in the fifth linked wallet management database 157E, the linked wallet ID is used to identify the linked wallet instead of the group ID and group name. Then, processing can be performed by regarding the data in which the linking approval has been added to the linked account data as linking status management data.

To achieve this, at the beginning of the process (steps A500 to A510 in FIG. 10-4), the control unit 21 of the terminal 20A may select an application ID of an arbitrary user (user account) instead of selecting a group, and transmit this to the server 10. The server 10 may then add the selected application ID to the collaboration status management data.

<Tenth Modification (2)>
In the above embodiment, the account linking may or may not be performed when a linked wallet is created without requiring linking approval.
In other words, the process for approving linkage may be omitted, and when a linked wallet is created, multiple accounts that are candidates for linkage may or may not be automatically associated in the linked wallet management data.
In this case, the creation of a linked wallet constitutes "account linking."

<Eleventh Example>
In the first to tenth embodiments, the application is a payment application, which is described as an example and not a limitation. However, the application is not limited to this.
The eleventh embodiment is an embodiment in which a payment is made using an associated wallet in a group of chat applications, and the payment is displayed in the chat room.

The contents described in the eleventh embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, the chat service is used as a messaging service, and a display based on linked payment result information and a display based on advance payment history information are performed by a messaging application installed on the terminal 20.
In addition, a talk room will be exemplified below as a chat room when a messaging service (messaging application) is applied.

In this embodiment, an example is given of wallet linkage being performed in a payment application service linked to a messaging service for a group used in the messaging service.

<Display screen>
In the following, it is assumed that User A.A, User B.B, and User C.C, who are users of both the messaging application and the payment application, all belong to the group "Bandmates" and are registered as friends.

Figure 11-1 is a diagram showing an example of a talk room screen of a messaging application displayed on the display unit 24 of the terminal 20 in this embodiment. This talk room screen is a group talk room screen for the group "Bandmates." On the talk room screen, by way of example and not limitation, messages sent by the user (user A.A. in this example) are displayed as speech bubbles on the right side of the display area, and messages sent by other users are displayed as speech bubbles on the left side of the display area.

The left side of Figure 11-1 shows a state in which user A.A is exchanging messages with other group members, user B.B. and user C.C. In this state, when the linked wallet icon IC1 at the bottom of the screen is tapped, the screen on the right side of Figure 11-1 is displayed, by way of example and not limitation.

Specifically, the linked wallet information display area WIR1 is displayed by rising from the bottom of the screen. The linked wallet information display area WIR1 displays the icons and user names of each group member included in the group "Bandmates" along with the text "Request wallet linkage?". In this state, when the wallet linkage request button BT35 displayed at the bottom of the linked wallet information display area WIR1 is tapped, a request for wallet linkage is sent from terminal 20A to the terminals 20 of the other group members via server 10.

FIG. 11B is a diagram showing an example of the group talk room screen displayed on the display unit 24 of the terminal 20B in this case.
In the group talk room, a wallet linking request message MS1 indicating a request for wallet linking is displayed on the left side of the display area as a message sent by user A.A. This wallet linking request message MS1 displays a link button including the characters "Link" indicating approval of the wallet linking request, and a reject button including the characters "Reject" indicating rejection of the wallet linking request, along with text indicating a request for wallet linking. When the link button is tapped, information indicating consent to wallet linking is transmitted to the server 10, and the user account of user B.B is linked. As a result, the display unit 24 of terminal 20A displays the screen on the right side of FIG. 11-2, by way of example and not limitation.

In this screen, the linked member information display area MIR1 is displayed rising from the bottom of the group chat room screen on the left side of FIG. 11-1. It is shown that user A.A is linking their wallets, and that the balance of user A.A's electronic money account is "1,000 yen." In addition, it is shown that user B.B has approved wallet linking, and that user B.B is also linking their wallets, and that the balance of user B.B's electronic money account is "3,000 yen."
Also, it is shown that user C.C is in the process of requesting wallet linkage, and the linkage has not yet been approved.

11-3 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A when an account linking payment is made using the linked wallet of the group "Bandmate" after the linking is approved by the user C.C.
On the left side of Figure 11-3, a linked wallet payment completion notification including a member payment result display area MRR8 containing information indicating that the payment via the linked wallet has been completed is displayed rising from the bottom of the screen and superimposed on the group chat room for the group "Bandmates."
In this example, the electronic money account balance of user A.A.'s user account is "1,000 yen", and "500 yen" is insufficient for the equal payment amount of "1,500 yen", so "500 yen" is paid in advance by user C.C.

For user A.A, the shortfall of the equal payment amount of "1,500 yen" (500 yen) is paid in advance by user C.C, and the remaining payment amount of "1,000 yen" is paid, and as a result, the balance of the electronic money account becomes "0 yen".
User B. It is shown that B has paid the equal payment amount of "1,500 yen", and as a result, the balance of his electronic money account has become "1,500 yen".
It is shown that user C.C. advanced the remaining amount of "500 yen" for user A.A out of the equal payment amount of "1,500 yen," paying "1,500 yen + 500 yen = 2,000 yen," and as a result, the balance of the electronic money account became "4,000 yen."

In addition, in the member payment result display area MRR8, in the item for user C.C., an advance payment refund button BT6 for user A.A to return the "500 yen" advanced to user C.C. is displayed.
When the advance payment amount refund button BT6 is tapped, the advance payment amount of "500 yen" is transferred from the electronic money account of user A.A to the electronic money account of user C.C.

When the close button (button with an x mark) in the upper right of the member payment result display area MRR2 is tapped, the member payment result display area MRR2 is hidden, and as a result, the group talk room becomes visible. In this group talk room, a linked payment result message MS2 (linked payment result information) indicating that user A.A has paid "1,000 yen" using the linked wallet, and an advance message MS3 (advance information) indicating that user C.C. has advanced "500 yen" are displayed.
The linked payment result message MS2 and the advance payment message MS3 may or may not be displayed together as a single piece of information.

The advance payment message displays an advance payment amount refund button BT6.
When the advance payment amount refund button BT6 is tapped, the advance payment amount of "500 yen" is transferred from the electronic money account of user A.A to the electronic money account of user C.C.

FIG. 11D is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20C in this example.
The left side of FIG. 11-4 displays a group chat room, along with a linked payment result message MS4 (linked payment result information) indicating that user C.C. paid "2,000 yen" using the linked wallet, and an advance message MS5 (advance information) indicating that user C.C. paid "500 yen" for user A.A.
The linked payment result message MS4 and the advance payment message MS5 may or may not be displayed together as a single piece of information.

The advance payment message MS5 displays an advance payment request button BT7 for user C.C. to request user A.A for the "500 yen" that he/she has advanced.
When the advance payment amount request button BT7 is tapped, information requesting the advance payment amount is transmitted from terminal 20C to terminal 20A via server 10.

As a non-limiting example, when the “>Payment App” button included in the advance payment message MS5 is tapped, a linked wallet payment completion notification including a member payment result display area MRR9 appears rising from the bottom of the screen and is superimposed on the group chat room, as shown on the right side of FIG. 11-4.
In the member payment result display area MRR9, a request for advance payment button BT7 is displayed in the item for user A.A.

Figure 11-5 shows an example of a screen transition displayed on display 24 of terminal 20A when another account linked payment (next account linked payment) is made following a payment using the linked wallet described in Figures 11-1 to 11-4.
The left side of Fig. 11-5 shows the state where a chat has progressed in the group chat room shown on the right side of Fig. 11-3. In this example, a message is sent from user A.A to the group expressing a desire to purchase another product (in this example, a stick), and a message is sent from user C.C indicating approval of this purchase.

When the above-mentioned product (stick) is purchased through account linked payment and the payment is completed, as an example and not a limitation, as shown in the center of Figure 11-5, a linked wallet payment completion notification including a member payment result display area MRR10 will rise from the bottom of the screen and be displayed superimposed on the group chat room on the left side of Figure 11-5.

In this example, the price of the product (sticks) is 900 yen, and the amount to be paid in equal installments is 900 yen divided by 3 = 300 yen. However, as described above, the balance of user A.A's electronic money account is now 0 yen, so user A.A is unable to make a payment. Therefore, this example shows the result of user A.A having user C.C pay the shortfall in advance, as described above.

Specifically, for user A.A, the payment amount is shown to be "0 yen" and the balance of the electronic money account is also shown to be "0 yen."
User B. It is shown that B has paid the equal payment amount of "300 yen", and as a result, the balance of his electronic money account has become "1,200 yen".
It is shown that user C.C. advanced the remaining amount of "300 yen" for user A.A, which was the shortfall of "300 yen," and paid "300 yen + 300 yen = 600 yen," resulting in the electronic money account balance becoming "3,400 yen."

The right side of Fig. 11-5 shows an example of a group talk room displayed on terminal 20A in this case. In this group talk room, a linked payment result message MS6 (linked payment result information) indicating that user A.A's payment using the linked wallet is "0 yen" and an advance message MS7 (advance information) indicating that user C.C. has advanced "300 yen" are displayed.
The linked payment result message MS6 and the advance payment message MS7 may or may not be displayed together as a single piece of information.

The advance payment message displays an advance payment amount refund button BT6.
When the advance payment amount refund button BT6 is tapped, the advance payment amount of "300 yen" is transferred from the electronic money account of user A.A to the electronic money account of user C.C.

FIG. 11-6 is a diagram showing an example of a display screen when performing a lump-sum settlement of linked wallets, and shows an example of a group talk room screen displayed on the display unit 24 of the terminal 20A.
In this example, as shown on the left side of Fig. 11-6, a notification urging settlement of the linked wallet is displayed, including the text "Settlement of linked wallet is required," in a manner that hangs down from the group name "Bandmate (3)" in the current location display area. When this bubble is tapped, a display area that displays information about lump-sum settlement of the linked wallet is displayed, rising from the bottom of the group chat room screen, as shown on the right side of Fig. 11-6.

In this display area, the text "Do you want to settle the linked wallet?" is displayed along with a message to confirm that a total of "800 yen" will be returned (transferred) from user A.A to user C.C, which corresponds to the two advance payments of "500 yen" and "300 yen" mentioned above, along with a "Yes" button to approve this and a "No" button to reject this. When the "Yes" button is tapped, the transfer of "800 yen" from user A.A to user C.C is executed.

In addition, in the screen on the left side of Figure 11-6, a notification to prompt settlement of the linked wallet may or may not be displayed based on a tap on the group name display area or other area in the current location display area.

<Processing>
As for the processing in this embodiment, as an example and not a limitation, the processing of a payment application management server that manages payment applications and a messaging application management server that manages messaging services can be realized in a similar manner as processing in server 10 in accordance with Figures 10-4 to 10-5 and Figures 7-3 to 7-5, so repeated explanation will be omitted.

<Effects of the Eleventh Example>
In this embodiment, the display of the remittance request information (not limited to, an example of a first display) is included in a chat room associated with a first user account and a second user account (not limited to, an example of a chat room associated with a first account and a second account), and the terminal 20 is configured to display the chat room including the display of the remittance request information on the display unit 24.
As an example of an effect of an embodiment obtained by such a configuration, first information regarding a transfer of money to a second account can be communicated to a first user of a terminal in an easy-to-understand manner by displaying it in a chat room in which the first account and the second account are associated.

In this embodiment, the terminal 20 performs a process (not limiting, an example of a process related to the second payment) for causing the server 10 to perform an account linking payment based on the first user account and the second user account through the control unit 21. The terminal 20 also receives remittance request information (not limiting, an example of the second information) through the communication I/F 22 based on the account linking payment. The terminal 20 then displays a talk room on the display unit 24 that includes a display of the received remittance request information (not limiting, an example of the second display) and a display of other remittance request information (not limiting, an example of the first display).
As an example of an effect of an embodiment obtained by such a configuration, a process related to a second payment is performed by a terminal of a first user of the terminal based on a first account of the first user of the terminal and a second account associated with the first account, thereby realizing a second payment by at least two associated accounts. In addition to the first information related to the transfer of money to the second account by the first payment, the second information related to the transfer of money to the second account by the second payment can be notified to the first user of the terminal in an easy-to-understand manner by displaying it in a chat room.

In addition, this embodiment illustrates a configuration that executes a process for transferring a recommended remittance amount based on one remittance request information and a recommended remittance amount based on the other remittance request information from a first user account to a second user account based on input by a user of terminal 20 in response to a display of one remittance request information (not limiting, an example of the second display) and a display of another remittance request information (not limiting, an example of the first display).
As an example of an effect of an embodiment obtained by such a configuration, an amount based on the first information and an amount based on the second information can be transferred from a first account to a second account by the simple method of the first user inputting information into the first display and the second display.

<Eleventh Modification (1)>
In the eleventh embodiment, when an account linkage in a talk room (chat room) of multiple linked accounts is terminated, any outstanding refunds for account linkage payments that have been made up to that point may or may not be made.

"Unlinking accounts" means removing the association between accounts. This includes, by way of example and not limitation, destroying a linked wallet.

Additionally, if a linked wallet is created in association with a chat room, “unlinking an account in a chat room” includes, by way of example and not limitation, any of the following:
(A) Disassociating the accounts without abandoning the chat room (B) Destroying the chat room

(A) means, by way of example and not limitation, that the chat room is not destroyed, but that the association between the accounts in the linked wallet associated with the chat room is eliminated. By way of example and not limitation, this includes a case where a user inputs an input to destroy the linked wallet in the chat room, thereby destroying the linked wallet.

(B) means that abandoning a chat room results in the association between the accounts in the linked wallet associated with that chat room being broken. By way of example and not limitation, this includes abandoning a chat room by a user making an input to abandon the chat room.

If the design and specifications only allow members to exit a chat room and the chat room cannot be made to disappear, then, by way of example and not limitation, when the remaining number of members becomes "1" or "0" as a result of an exit, the account link may or may not be terminated.

FIG. 11-7 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A in this modified example.
On the left side of Fig. 11-7, a linked member information display area MIR1 for the linked wallet of the group "Bandmate" is displayed rising from the bottom of the screen of the group chat room. At the bottom of the linked member information display area MIR1, a linked wallet discard button BT30 is displayed.

In this modified example, when the associated wallet discard button BT30 is tapped, it is possible to discard the associated wallet after making a lump-sum settlement. Specifically, as an example and not a limitation, as shown on the right side of Figure 11-7, information indicating that the associated wallet will be discarded and information regarding the lump-sum settlement are displayed in a pop-up format so as to be superimposed on the associated wallet information.

In this example, a message is displayed to confirm the return (transfer) of a total of "800 yen" from user A.A to user C.C, which corresponds to the two advance payments of "500 yen" and "300 yen" mentioned above, along with a "Yes" button to approve this and a "No" button to reject this. When the "Yes" button is tapped, the transfer of "800 yen" from user A.A to user C.C is executed.

This modified example shows a configuration in which terminal 20 performs a process of transferring a lump-sum settlement amount (not limiting, an example of an amount based on the first information and an amount based on the second information) from the first user account to the second account based on disassociating the first user account from the second user account in a chat room (not limiting, an example of disassociating in a chat room).
As an example of an effect of an embodiment obtained by such a configuration, when the association between the first account and the second account in a chat room is released, an amount based on the first information and an amount based on the second information can be transferred from the first account to the second account. By way of example and not of limitation, when the association between the first account and the second account in the chat room is cancelled, or when the chat room itself is cancelled, it becomes possible to refund the unprocessed amount.

<Twelfth Example>
In the above embodiment, the electronic money account balance of each linked account can be confirmed on each terminal 20 of the linked members. By way of example and not limitation, information on the electronic money account balance of each linked account can be transmitted from the server 10 to the terminal 20 of the linked member, received by the terminal 20, and displayed on the display unit 24. Alternatively, information on the electronic money account balance can be transmitted and received between the terminals 20.
In other words, in the above embodiment, the true balance of the electronic money account in each linked account is shared by the linked members.
However, it is expected that some users may be hesitant to disclose their true balance in their electronic money account to other linked members.

The embodiment described below is an embodiment in which a balance different from the true balance of an electronic money account can be displayed according to a preset limit.
Hereinafter, the displayed balance of a linked account displayed in a linked wallet will be referred to as the "displayed balance."

However, as described above, it is not necessary that user accounts of different users are linked accounts, and multiple user accounts of the same user can be linked accounts.
Therefore, in this embodiment, a case where multiple user accounts of the same user are linked accounts will be described first.

In addition, in this embodiment, a "display lower limit amount" is illustrated as an example of an amount set to limit the displayed balance, but the amount is not limited to this.
The amount set to limit the displayed balance may be the "display upper limit amount" described in detail below, or an amount input and set arbitrarily by the user of the linked account.

The displayed balance is a concept that allows a balance different from the true balance of an electronic money account to be displayed, and can be similarly applied to other than account linking payments.
By way of example and not limitation, the present invention is equally applicable to normal payments using a user account, joint account payments, and the like.

The contents described in the twelfth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 12-1 is a diagram showing an example of the data configuration of the sixth linked wallet management database 157F, which is an example of a database for managing linked wallets in this case.
The sixth associated wallet management database 157F stores associated wallet management data as management data for each associated wallet.

Each linked wallet management data stores, by way of example and not limitation, a linked wallet ID, linked account data, and payment history data. The linked wallet ID and payment history data are, by way of example and not limitation, similar to those of the first linked wallet management database 157A.

The linked account data stores the application ID corresponding to the linked account, the user name corresponding to the application ID, and, by way of example and not limitation, the minimum display amount.

The display lower limit amount is an example of an amount that is set to limit the display balance, and is an amount that is set as the lower limit amount that can be displayed as the display balance.
As an example and not a limitation, in FIG. 12A, a user account with application ID "U0001" which is a main account of user A.A and a user account with application ID "U0005" which is a sub-account of user A.A are associated as linked accounts.

Further, no minimum display amount is set for application ID "U0001", but a minimum display amount of "5,000 yen" is set for application ID "U0005".
In this case, even if the balance of the electronic money account of the application ID "U0005" is less than "5,000 yen," the displayed balance will be "5,000 yen." On the other hand, if the balance of the electronic money account is "5,000 yen" or more, the electronic money account balance will be used as it is as the displayed balance.

<Display screen>
Here, a linked wallet in which the main account and sub-account of user A.A. are linked as a linked account will be described using a display screen example. Here, it is assumed that the electronic money account balance of the sub-account is "1,000 yen" and the display lower limit of the sub-account is "5,000 yen."

FIG. 12B is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
When the linked wallet icon IC1 is tapped on the main menu screen of the payment application on the left side of Fig. 12-2, the screen in the center of Fig. 12-2 is displayed. On this screen, along with information indicating that it is a linked wallet of user A.A, the linked member information display area MIR1 below it displays the electronic money account balance of user A.A's main account (in this example, "10,000 yen") and the display balance set for user A.A's subaccount (in this example, "5,000 yen"). The balance display field for user A.A's subaccount displays the set display balance, unlike the main account.

When the code reader icon IC2 is tapped on this screen, the code reader screen on the right side of Figure 12-2 is displayed. When the payment store code falls within the code reading area CR1 and the linked wallet code reader information is read, the screen shown on the left side of Figure 12-3 is displayed. This screen shows that "6,000 yen" has been entered as the payment amount in the linked wallet. When the payment button BT1 at the bottom of the screen is tapped in this state, the screen on the right side of Figure 12-3 is displayed.

In this example, the equal payment amount is "3,000 yen."
In the affiliated member information display area MIR1, the payment amount of the main account of user A.A (in this example, "3,000 yen") and the payment amount of the sub-account of user A.A (in this example, "3,000 yen") are displayed.

User A. The balance of the electronic money account of A's main account is "10,000 yen", which exceeds the amount of the equal payment.
However, for user A.A's subaccount, although the displayed balance is "5,000 yen", the actual electronic money account balance is "1,000 yen", which means that the electronic money account balance is less than the equal payment amount.
As a result, a warning mark and the words "insufficient balance" are displayed in the payment amount confirmation area PIR1 because the cooperative payment available amount falls below the payment amount.

<Processing>
FIG. 12D is a flowchart showing an example of the flow of the process executed by each device in this embodiment.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

First, the control unit 11 of the server 10 calculates the displayed balance for each linked account according to the display lower limit amount stored in the sixth linked wallet management database 157F. Then, the control unit 11 of the server 10 transmits linked account balance information with a lower limit limit, including the calculated displayed balance, to the terminal 20A via the communication I/F 14 (S600).

In addition, if a minimum display amount has not been set, the electronic money account balance of the linked account may be sent as linked account balance information with a minimum limit in a manner that is distinguishable from the displayed balance. Alternatively, the electronic money account balance may be sent in the form of a displayed balance (i.e., "displayed balance" = "electronic money account balance").

When the communication I/F 22 receives linked account balance information with a lower limit from the server 10, the control unit 21 of the terminal 20A causes the display unit 24 to display the displayed balance of each linked account (A600).

Even if the displayed balance is limited by the minimum display amount, the linked payment process uses the true electronic money account balance to perform the payment process (S110). In other words, the displayed balance is merely a value that the user of the terminal 20 can confirm.

Note that, as an example and not a limitation, in step S600, the server 10 may or may not transmit the true electronic money account balance and the display lower limit amount to the terminal 20A.
In this case, the control unit 21 of the terminal 20A can calculate the displayed balance using the received true electronic money account balance and the display lower limit amount, and cause the display unit 24 to display it.

In addition, if there are multiple terminals 20 corresponding to a linked account, the electronic money account balance of each linked account may be received from the server 10, and the display lower limit amount may be transmitted and received between the terminals 20, thereby calculating the display balance on each terminal 20, but this is not essential.

When there is one terminal 20 corresponding to a linked account (i.e., there is one linked member), by way of example and not limitation, the display lower limit amount may be stored in the memory unit 28 of terminal 20A, the electronic money account balance of each linked account may be received from the server 10, and the display balance may be calculated on the terminal itself, or it may not be. In this case, there is no need to send or receive information regarding the display lower limit amount.

<Effects of the twelfth embodiment>
In this embodiment, the terminal 20 displays on the display unit 24 a displayed balance (not limited, an example of the balance of the second account based on the second amount) based on a display lower limit amount (not limited, an example of the second amount) set in a second user account (not limited, an example of the second account) of a user (not limited, an example of a first user) of the terminal 20 itself. The terminal 20 then shows a configuration in which the control unit 21 performs processing related to linked account payment (not limited, an example of processing related to the first payment) based on the first user account (not limited, an example of the first account) of the user of the terminal 20 itself and the second user account in which a display lower limit amount is set.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to allow a first user to check the balance of a second account associated with the first account of the first user, based on a second amount set in the second account.
In addition, a first payment can be made by the terminal of the first user based on the first account and a second account in which the second amount is set.

In this case, the terminal 20 receives information on the display balance (not a limitation, but an example of balance information of the second account based on the second amount) based on the display lower limit amount (not a limitation, but an example of the second amount) via the communication I/F 22. The terminal 20 can then display the display balance based on the received display balance information on the display unit 24.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to allow a first user to check the balance of a second account based on a second amount based on balance information of the second account based on the second amount received and obtained from another device.

Furthermore, in this embodiment, the server 10 transmits information on the displayed balance based on the display lower limit amount set in the second user account (not limited to this, but an example of information on the balance of the second account based on the second amount) to the terminal 20 of the first user via the communication I/F 22. The server 10 then shows a configuration in which the control unit 11 performs account linking payment processing based on the first user account and the second user account in which the display lower limit balance is set.
As an example of an effect of an embodiment obtained by such a configuration, information regarding the balance of the second account based on the second amount set in the second account can be sent to the terminal of the first user so that the first user can confirm it.
Also, a first payment can be made based on the first account and a second account in which a second amount is set.

<Thirteenth Example>
In the twelfth embodiment, the concept of a displayed balance is newly introduced.
The displayed balance explained in the twelfth embodiment merely displays the set displayed balance, but in this embodiment, an embodiment will be described in which the displayed balance can affect the payment process.

As with the twelfth embodiment, this embodiment also describes a case where two user accounts (main account, sub-account) of the same user (first user) are linked accounts.

Some users may wish to limit the electronic money account balance that can be used for a single payment in a linked wallet.
Also, by way of example and not limitation, it is conceivable that the user may lose or have the terminal 20 stolen, causing the true balance of the user's electronic money account to be seen by others.

The contents described in the thirteenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 13A is a diagram showing an example of the data configuration of the seventh linked wallet management database 157G, which is an example of a database for managing linked wallets in this embodiment.
The seventh associated wallet management database 157G stores associated wallet management data as management data for each associated wallet.

By way of example and not limitation, each linked wallet management data stores a linked wallet ID, linked account data, and payment history data. The linked wallet ID and payment history data are, by way of example and not limitation, similar to those of the sixth linked wallet management database 157F.

The linked account data stores the application ID corresponding to the linked account, the user name corresponding to the application ID, and, by way of example and not limitation, the maximum display amount.

The display upper limit amount is, by way of example and not limitation, one example of an amount set to limit the displayed balance, and is an amount set as the upper limit amount that may be displayed as the displayed balance.
As an example and not a limitation, in FIG. 13-1, a user account with application ID "U0001" which is a main account of user A.A. and a user account with application ID "U0005" which is a sub-account of user A.A. are associated as linked accounts.

Additionally, no upper limit display amount is set for application ID "U0001," but "5,000 yen" is set as the upper limit display amount for application ID "U0005." In this case, if the balance of the electronic money account of application ID "U0005" exceeds "5,000 yen," the displayed balance will be "5,000 yen."
On the other hand, if the balance of the electronic money account is less than 5,000 yen, the balance of the electronic money account is used as the displayed balance.

<Display screen>
Here, a linked wallet in which the main account and sub-account of user A.A. are linked as linked accounts will be described using a display screen example. Here, it is assumed that the electronic money account balance of the sub-account is "5,000 yen" and the display upper limit amount is set to "5,000 yen".

FIG. 13B is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Fig. 13-2 is the main screen of the linked wallet, and the linked member information display area MIR1 displays the electronic money account balance (10,000 yen) of the main account of user A.A and the displayed balance (5,000 yen) based on the display upper limit amount (5,000 yen) set for user A.A's sub-account.

In the main account display area, an upper limit button BT40 for setting the upper limit of the display amount is displayed together with information on the electronic money account balance.
Since the display upper limit amount has already been set for the sub-account, the upper limit button BT40 is not displayed in the sub-account display field.

When the upper limit button BT40 in the main account display field is tapped, the screen shown in the center of Fig. 13-2 is displayed. This screen is for inputting the display upper limit amount, and in this example, "3,000 yen" is input as the display upper limit amount for the main account. When the setting button BT41 at the bottom of the screen is tapped in this state, the screen returns to the main screen of the linked wallet, and the screen shown on the right side of Fig. 13-2 is displayed.
This main screen differs from the main screen on the left side of FIG. 13-2 in that the display column for User A.A's main account shows a displayed balance of "3,000 yen."
In addition, based on the setting of the display upper limit amount, the upper limit button BT40 displayed in the main account display field on the left screen of FIG. 13-2 is hidden.

The left side of FIG. 13-3 is a diagram showing an example of a code reader screen that is displayed when the code reader icon IC2 is tapped on the screen on the right side of FIG. 13-2.
When the payment store code is within the code reading area CR1 and the associated wallet code reader information is read, the screen shown in the center of Figure 13-3 is displayed. This screen shows that "6,000 yen" has been entered as the payment amount in the associated wallet.

In this example, the equal payment amount is "3,000 yen."
User A. The balance of the electronic money account of A's main account is "10,000 yen", which exceeds the amount of the equal payment.
Furthermore, the electronic money account balance of user B.B's subaccount is "5,000 yen", which exceeds the equal payment amount.
Therefore, payment is possible using the linked wallet, and when the payment button BT1 at the bottom of the screen is tapped in this state, the screen on the right side of Figure 13-3 will be displayed.

This screen displays information indicating that the payment via the linked wallet has been completed.
Because the amount of the equal payment is 3,000 yen, the payment has reduced the electronic money account balance of the main account from 10,000 yen to 7,000 yen. However, since this exceeds the displayed balance of 3,000 yen, 3,000 yen is displayed as the displayed balance.
On the other hand, for the subaccount, the payment has reduced the electronic money account balance from "5,000 yen" to "2,000 yen", but since this is below the displayed balance of "3,000 yen", "2,000 yen" is displayed.

<Processing>
FIG. 13D is a flowchart showing an example of the flow of the process executed by each device in this embodiment.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

The control unit 21 of the terminal 20A receives the display upper limit amount based on a user operation on the input/output unit 23 of the terminal 20A, for example and not for limitation. The control unit 21 of the terminal 20A then transmits display upper limit amount setting information including the display upper limit amount to the server 10 via the communication I/F 22 (A610).

When the display upper limit amount setting information is received via the communication I/F 14, the control unit 11 of the server 10 stores the display upper limit amount in the seventh linked wallet management database 157G. The control unit 11 of the server 10 then calculates the display balance for each linked account according to the stored display upper limit amount. The control unit 11 of the server 10 then transmits upper limit limited linked account balance information, including the calculated display balance, to the terminal 20A via the communication I/F 14 (S610).

When the communication I/F 22 receives the upper limit-limited linked account balance information from the server 10, the control unit 21 of the terminal 20A causes the display unit 24 to display the displayed balance of each linked account (A620).

Note that, as an example and not a limitation, in step S610, the server 10 may or may not transmit the true electronic money account balance and the display upper limit amount to the terminal 20A.
In this case, the control unit 21 of the terminal 20A can calculate the displayed balance using the received true electronic money account balance and the display upper limit amount, and cause the display unit 24 to display it.

In addition, if there are multiple terminals 20 corresponding to a linked account, the electronic money account balance of each linked account may be received from the server 10, and the display upper limit amount may be transmitted and received between the terminals 20, thereby calculating the display balance on each terminal 20, but this is not essential.

When the linked payment request information is received via the communication I/F 14, the control unit 11 of the server 10 searches for the linked wallet ID from the requested linked wallet payment token, and executes a store-presented, upper limit-limited linked payment process to pay the planned payment amount between the linked wallet and the affiliated store specified by the store ID (S690).

In the store-presented, upper limit-limited linked payment process, the displayed balance is used instead of the electronic money account balance in each determination in the store-presented, upper limit-limited linked payment process. In other words, if the value of "displayed balance - equal payment amount" is equal to or greater than "0" for all linked accounts, a payment process for the equal payment amount is executed for each linked account, and the store-presented, upper limit-limited linked payment process is successful.
On the other hand, if the value of "displayed balance - equal installment payment amount" is negative for any account, the payment process to the linked account is not performed and the store-presented upper limit linked payment process fails.

In addition, in the linked payment result information sent in step S240, the displayed balance recalculated after the payment process is sent instead of the electronic money account balance.

<Effects of the Thirteenth Example>
In this embodiment, the terminal 20 displays on the display unit 24 a displayed balance (not limited, an example of the balance of the second account based on the second amount) based on a display upper limit amount (not limited, an example of the second amount) set in a second user account (not limited, an example of the second account) of a user (not limited, an example of the first user) of the terminal 20. The terminal 20 then shows a configuration in which the control unit 21 performs processing related to linked account payment (not limited, an example of processing related to the first payment) based on the first user account (not limited, an example of the first account) of the user of the terminal 20 and the second user account in which the display upper limit amount is set.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to allow a first user to check the balance of a second account associated with the first account of the first user, based on a second amount set in the second account.
In addition, a first payment can be made by the terminal of the first user based on the first account and a second account in which the second amount is set.

In this embodiment, the control unit 21 controls the terminal 20 to set a display upper limit amount for the first user account based on an input to the terminal 20 by a user of the terminal 20 (not limited to this, but an example of a first user).The terminal 20 is configured to display on the display unit 24 the displayed balance of the first user account based on the set display upper limit amount and the displayed balance of the second user account based on the set display upper limit amount.
As an example of the effect of the embodiment obtained by such a configuration, a displayed amount (first amount) can be set for the first account as well.
In addition, the first user may be able to check both the balance of the first account based on the set first amount and the balance of the second account based on the set second amount.

In this case, information on the maximum display amount set for the second user account can include information on the maximum amount to be displayed on the first user's terminal 20 from the electronic money account balance of the second user account (not limited to this, but an example of the balance of the second account).
As an example of an effect of the embodiment obtained by such a configuration, it is possible to allow the first user to check information on the maximum amount set for the second account.

In this case, information on the display upper limit amount set for the second user account may include information on the maximum amount that can be used in a single linked account payment.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to allow the first user to confirm the maximum amount that can be used for a single payment, which is set in the second account.

In this case, the displayed balance of the second user account displayed on the display unit 24 of the terminal 20 can be such that, if the electronic money account balance of the second user account is greater than the display upper limit amount, the display upper limit amount is displayed on the display unit 24, and, if the electronic money account balance of the second user account is less than the display upper limit amount, the electronic money account balance of the second user account is displayed.
As an example of an effect of an embodiment obtained by such a configuration, the amount can be appropriately displayed based on the relationship between the balance of the second account and the second amount set in the second account.

<Thirteenth Modification (1)>
In the above embodiment, the store-presented upper limit-limited cooperative payment process is executed as the payment process, but the present invention is not limited to this. As a non-limiting example, the store-presented cooperative payment process shown in step S110 of FIG. 1-11 may or may not be executed in step S690 of FIG. 13-4.

In this case, if you have an electronic money account balance that exceeds the displayed balance, you can make a payment using that electronic money account balance. In other words, the displayed balance is just a displayed value and does not affect the payment process.

<Thirteenth Modification (2)>
In the above embodiment, an example was shown in which different display upper limit amounts are used for each linked account, but the present invention is not limited to this.
By way of example and not limitation, a predetermined maximum display amount may or may not be set for each associated wallet.
In this case, if the electronic money account balance of a certain linked account exceeds the display upper limit amount of the linked wallet, the displayed balance of this linked account will be the display upper limit amount of the linked wallet.

In addition, the maximum display amount for the linked wallet and the maximum display amount for each linked account may or may not be determined or set separately.
In this case, the display upper limit amount may be set in each linked account to an amount that is smaller than the display upper limit amount of the linked wallet, or it may not be necessary to do so.
If a display upper limit is set for a linked account that exceeds the display upper limit for the linked wallet, the displayed balance for that linked account may or may not reflect the display upper limit set for that account.

<Thirteenth Modification (3)>
In the above embodiment, an example in which a user account is linked as a linked account is shown, but this is not limiting. As a non-limiting example, the common wallet described in the eighth embodiment may be used as a linked wallet with the linked account, or it may not be used.

In this case, the linked account data in the sixth linked wallet management database 157F may be, by way of example and not limitation, stored in association with the wallet ID and name similar to those in the fourth linked wallet management database 157D, as well as the above-mentioned maximum display amount.

Then, if the common wallet balance of the shared wallet exceeds the display upper limit amount, the display upper limit amount will be calculated as the displayed balance of the common wallet, and if the common wallet balance is equal to or less than the display upper limit amount, the common wallet balance will be calculated as the displayed balance of the common wallet.

This modified example illustrates a configuration in which the second account is a shared wallet account (not limited to this, but is an example of a common account).
As an example of the effect of this modified example obtained by such a configuration, the true balance of the common account can be kept secret.

<Thirteenth Modification (4)>
For a user account for which a display upper limit is set, authentication may or may not be required to inquire about and display the electronic money account balance. In other words, unless authentication is performed and the authentication result is OK (authentication OK), the electronic money account balance may or may not be displayed on the display unit 24 of the terminal 20.
In this case, terminal 20 can perform authentication processing using control unit 21 based on input by the user of terminal 20, and if authentication is successful, can cause display unit 24 to display the balance of the electronic money account.

As a non-limiting example, if the electronic money account balance exceeds the set display upper limit amount, the display upper limit amount is displayed as the displayed balance, and the true electronic money account balance is kept secret. In this case, the true electronic money account balance will not be displayed on the display unit 24 unless authentication is successful.

This also applies to the case where an amount such as a minimum display amount is set.
By way of example and not limitation, if the electronic money account balance is below a set minimum display amount, the minimum display amount is displayed as the displayed balance, and the true electronic money account balance is concealed. In this case as well, the true electronic money account balance will not be displayed on display unit 24 unless authentication is successful.

As mentioned above, this prevents the user's true electronic money account balance from being discovered by others even if the user loses or has their terminal 20 stolen.

Furthermore, the user of the terminal 20 may be able to configure settings relating to the above authentication (authentication ON/OFF).
In this case, the user may be able to configure settings related to authentication for each user account owned by the user, or for all user accounts owned by the user collectively.
Also, as a non-limiting example, authentication may be set to ON only for user accounts for which an amount for limiting the displayed balance (such as the above-mentioned upper and lower display limits) has been set.

<Fourteenth Example>
In the thirteenth embodiment, a case where the displayed balance may affect the settlement process has been described.
In this embodiment, the thirteenth embodiment is combined with the tenth embodiment described above, and a case will be described in which a display balance limited by a display upper limit amount is introduced in linked wallets of multiple linked members.
That is, in this embodiment, the first account is described as a user account of a first user, and the second account is described as a user account of a second user different from the first user.

As described above, it is expected that some users may be reluctant to disclose their true electronic money account balance to other linked members. By way of example and not of limitation, it is expected that a user may wish to conceal their true electronic money account balance when a large amount remains in the electronic money account balance.
Also, as mentioned above, some users may wish to limit the electronic money account balance that can be used for a single payment in a linked wallet.

The contents described in the fourteenth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 14-1 is a diagram showing an example of the data configuration of the eighth linked wallet management database 157H, which is an example of a database for managing linked wallets in this case.
The eighth associated wallet management database 157H stores associated wallet management data as management data for each associated wallet.

By way of example and not limitation, each linked wallet management data stores a group ID, a group name, linked status management data, payment history data, and advance payment history data. By way of example and not limitation, the group ID, group name, payment history data, and advance payment history data are the same as those of the fifth linked wallet management database 157E.

The link status management data stores the application ID, user name, link approval, and, by way of example and not limitation, the maximum display amount in association with the application.

In this embodiment, by way of example and not limitation, each affiliated member is configured to be able to set the maximum display amount that they are willing to accept when agreeing to participate in the affiliated wallet.

<Display screen>
FIG. 14B is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Fig. 14-2 shows a screen for requesting wallet linkage with members of the group "Bandmates." When the wallet linkage request button BT35 at the bottom of the screen is tapped, the screen in the center of Fig. 14-2 is displayed.

This screen is for user A.A to set his/her own display upper limit amount, and in this example, "3,000 yen" is entered as the display upper limit amount. When the setting button BT41 at the bottom of the screen is tapped in this state, the screen on the right side of Figure 14-2 is displayed.

In this example, in the affiliated member information display area MIR1, the electronic money account balance is displayed as "10,000 yen" and the displayed balance is displayed as "3,000 yen" in the column for user A.A.

In addition, for User B.B and User C.C, the wallet linking request from User A.A has not yet been approved, so the "Request in progress" mark is displayed for each of them.

14C is a diagram showing an example of a transition of screens displayed on the display unit 24 of the terminal 20B based on a wallet linking request from the user A.A.
A notice screen of the payment application is displayed on the left side of FIG. 14-3, and a notice that a wallet linking request has been received from user A.A is displayed below the current location display area CLR2.

In the display area below where the contents of the notice are displayed, wallet linking request information regarding a wallet linking request from user A.A. is displayed. In addition to text indicating that user A.A. has requested wallet linking, the wallet linking request information also displays a confirmation button for confirming the details. When this confirmation button is tapped, the screen in the center of Figure 14-3 is displayed.

This screen is the main screen for the linked wallet of the payment application, and the linked member information display area MIR2 displays information about each member of the group "Bandmates." In the column for User B.B., a wallet link button for wallet linking is displayed.

User A. Since A is the requester of wallet linkage and is already a linked member, the displayed balance (in this example, "3,000 yen") is displayed.
In addition, for user C.C, the wallet linking request from user A.A has not yet been approved, so a "request in progress" mark is displayed.

When the Wallet Link button is tapped, the screen on the right side of Figure 14-3 will be displayed.
This screen is a screen for user B.B to set his/her own display upper limit amount, and in this example, a state in which "4,000 yen" has been entered as the display upper limit amount is shown. In this state, when the setting button BT41 at the bottom of the screen is tapped, the screen on the left side of FIG. 14-4 is displayed.
On this screen, in the associated member information display area MIR2, the column for user B.B. displays "6,000 yen" as the electronic money account balance and "4,000 yen" as the displayed balance.

On the other hand, when user B.B. approves wallet linkage, a screen such as that shown on the right side of FIG. 14-4 is displayed on the terminal 20A side.
On the terminal 20A side, in the associated member information display area MIR1, the "Requesting" mark displayed in the column for user B.B. disappears, and instead, "4,000 yen" is displayed as the displayed balance.
In addition, for user C.C, the wallet linking request from user A.A has not yet been approved, so the "request in progress" mark remains displayed.

14-5 is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20C based on a wallet linking request from the user A.A.
A notice screen of the payment application is displayed on the left side of FIG. 14-5, and a notice that a wallet linking request has been received from user A.A is displayed below the current location display area CLR3.

In the display area below where the content of the notice is displayed, wallet linking request information regarding a wallet linking request from user A.A. is displayed. The wallet linking request information displays text indicating that user A.A. has requested wallet linking, as well as a confirmation button to confirm the details.

When the Confirm button is tapped and user C.C. approves wallet linking and sets the display upper limit amount by following the flow from the center of FIG. 14-3 to the right side of FIG. 14-3 on terminal 20B, the screen in the center of FIG. 14-5 is displayed.

On this screen, in the linked member information display area MIR3, the electronic money account balance of "2,0000 yen" and the displayed balance of "10,000 yen" are displayed in the column for user C.C.

On the other hand, when the user C.C. approves the wallet linkage, a screen such as that shown on the right side of FIG. 14-5 is displayed on the terminal 20A side.
On the terminal 20A side, in the associated member information display area MIR1, the "Requesting" mark displayed in the column of user C.C. disappears, and instead, "10,000 yen" is displayed as the displayed balance.

In addition, with all members of the group "Band Nakama" now having their wallets linked, the code reader icon IC2 and code payment icon IC3 are no longer greyed out and are displayed as active.

In this state, when user A.A taps the code payment icon IC3 as shown on the left side of FIG. 14-6, the screen shown in the center of FIG. 14-6 is displayed. This screen is the code payment screen described above.

When the payment code displayed on the code payment screen is read by the store code reader device and the payment process of the customer-presented linked wallet is performed by server 10, the linked payment confirmation screen shown on the right side of Figure 14-6 is displayed.
On this linked payment confirmation screen, a payment amount confirmation area PIR3 is displayed below the current position display area CLR1. In the payment amount confirmation area PIR3, "12,000 yen" is displayed as the payment amount.

Here, the linked payable amount in this embodiment is an amount defined by the following formula, assuming that the payment amount is divided equally between the linked accounts.
・Linked payment available amount = Sum of payment capacity for all linked accounts

Here, the payment margin of a linked account is defined as follows:
・Payment margin of a linked account = the displayed balance of that linked account (if the displayed balance of that linked account - equal payment amount < 0)
・Payment margin of one linked account = equal payment amount (if the displayed balance of that linked account - equal payment amount ≧ 0)
However, the amount is calculated as "equal payment amount = payment amount ÷ number of linked accounts".

Note that in this embodiment, since there is a one-to-one correspondence between linked members and linked accounts, the linked account in the above formula is essentially synonymous with the linked member.

In this example, the amount of the equal payments is 12,000 yen divided by 3, which equals 4,000 yen.
User A. As for A's user account, the displayed balance is "3,000 yen", which is less than the equal payment amount of "4,000 yen", so the payment capacity is "3,000 yen".
User B. As for B's user account, the displayed balance is "4,000 yen", which is the same as the equal payment amount of "4,000 yen", so the payment capacity is "4,000 yen".
User C. As for C's user account, the displayed balance is "10,000 yen", which exceeds the equal payment amount of "4,000 yen", so the payment capacity is "4,000 yen".
Therefore, the cooperative payable amount is "3,000 yen + 4,000 yen + 4,000 yen = 11,000 yen."

In this example, the payment amount is "12,000 yen," while the linked payable amount is "11,000 yen," resulting in a shortfall of "1,000 yen."
As a result, a warning mark and the words "Insufficient balance" are displayed in the payment amount confirmation area PIR3.

In this example, since the user account of user A.A. is the one that has a shortage of payment margin, a warning mark is displayed in the upper left corner of user A.A.'s icon in the paying member confirmation area PMR3.

In this case, user A.A can change the display upper limit amount previously set for his/her user account in order to enable payment via the linked wallet.

FIG. 14-7 is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this case.
On the left side of Figure 14-7, information for changing the maximum displayed amount is displayed in a pop-up format in the center of the screen on the right side of Figure 14-6. Specifically, information is displayed urging the user to change the maximum displayed amount from the currently set "3,000 yen" to "4,000 yen" along with the text "Do you want to change the maximum displayed amount for this payment?". Also displayed are a "Yes" button to be operated if the user agrees to the change, and a "No" button to be operated if the user does not agree to the change.

When the "Yes" button is tapped, the screen in the center of Fig. 14-7 is displayed. In this screen, the warning mark and the text "Insufficient balance" that were displayed in the payment amount confirmation area PIR3 on the screen on the right side of Fig. 14-6 disappear, and the text "Payment possible" is displayed.
In this state, when the linked payment execution button BT5 at the bottom of the screen is tapped, the linked payment result display screen shown on the right side of FIG. 14-7 is displayed.

At the top of the linked payment result display screen, the words "Payment Completed" are displayed, indicating that the payment using the linked wallet has been completed, along with an icon image of "XX Musical Instrument," the recipient of the payment amount, its name "XX Musical Instrument," and the date and time of the payment, "2020-07-24/12:17:08."

Also, at the bottom of the linked payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of this payment for each linked account.
The member payment result display area MRR1 displays, for each linked account, the user account that made the payment, the amount paid by each user account, and the displayed balance after payment.
On this screen, the displayed balance for User A.A has returned to the previous balance of "3,000 yen." Also, the displayed balance for User B.B is updated to "2,000 yen" based on the fact that the balance of the electronic money account has become "6,000 yen - 4,000 yen = 2,000 yen."

<Processing>
14-8 to 14-10 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
In this figure, from the left, examples of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A.), processing performed by the control unit 21 of terminal 20B, and processing performed by the control unit 11 of server 10 are shown.

When the control unit 21 of terminal 20A executes step A510, it executes step A610. Furthermore, when the control unit 21 of terminal 20B executes step B510, it executes step B610. As step B610 can be processed in the same way as step A610, a detailed description will be omitted.

When the display upper limit amount setting information is received from the linked member's terminal 20 via the communication I/F 14, the control unit 11 of the server 10 changes the link approval in the link status management data for the application ID of the received terminal to "Completed."

Next, the control unit 11 of the server 10 calculates the display balance based on the display upper limit amount based on the received display upper limit amount setting information and the electronic money account balance of the linked member. Then, the control unit 11 of the server 10 transmits, by way of example and not limitation, restricted linked member information including the linked member's application ID and displayed balance to the terminal 20 of each member of the group via the communication I/F 14 (S630).

When the control unit 21 of the terminal 20A receives the limited affiliated member information via the communication I/F 22, the control unit 21 causes the display unit 24 to display the received limited affiliated member information (A630).
When the control unit 21 of the terminal 20B receives the limited affiliated member information via the communication I/F 22, the control unit 21 causes the display unit 24 to display the received limited affiliated member information (B630).

When the communication I/F 14 receives the linked payment request information, the control unit 11 of the server 10 calculates the linked payment available amount based on the displayed balance and determines whether the calculated linked payment available amount is lower than the planned payment amount (whether linked payment available amount - planned payment amount < 0) (S640).

If the linked payable amount is not less than the planned payment amount (linked payable amount - planned payment amount is 0 or more) (S640: NO), payment using the linked wallet is possible within the displayed balance, so the control unit 11 of the server 10 proceeds to step S690.

If the linked payment available amount is less than the planned payment amount (S640: YES), the control unit 11 of the server 10 executes step S220.

When receiving linked balance insufficiency information from server 10 via communication I/F 22 (A200: YES), control unit 21 of terminal 20A sends display upper limit amount change information to server 10 via communication I/F 22 (A640), which includes, by way of example and not limitation, a display upper limit amount addition amount for increasing the displayed balance of the user of the terminal (user A.A in this case) to above the shortfall in user A.A's payment capacity (i.e., the equal payment amount - user A.A's payment capacity).

The display upper limit amount addition amount may be set based on a user operation on the input/output unit 23 of the terminal 20A, or may be automatically determined according to the shortfall in the user A.A's payment capacity.

If the link balance insufficient information is not received (A200: NO), the control unit 21 of terminal 20A skips step A640.

When the communication I/F 14 receives the display upper limit change information from the terminal 20A, the control unit 11 of the server 10 adds the display upper limit addition amount in the received display upper limit change information to the display upper limit for user A.A, and recalculates the display amount (S680).

After the display amount is updated in step S680, the control unit 11 of the server 10 may, or may not, send the updated display amount to the terminals of the affiliated members via the communication I/F 14 and update and display the displayed balance on each terminal.

Then, the control unit 11 of the server 10 executes step S690.

After executing step S690, the control unit 11 of the server 10 may subtract the display upper limit amount addition amount from the display upper limit amount of user A.A to return it to the original display upper limit amount, or it may not do so.
Also, as an example and not as a limitation, in step A640, it may be possible to set whether the addition to the display upper limit amount addition is temporary or permanent based on user operation on the input/output unit 23 of terminal 20A, or it may not be possible to do so.

Note that Figures 14-8 to 14-10 show the flow for a single payment process, but after Figure 14-10, by way of example and not limitation, the process of Figure 7-4 may be executed to execute the payment process multiple times, or it is not necessary to do so.

In addition, the display upper limit amount is set when joining the linked wallet, but is not limited to this. As a non-limiting example, the display upper limit amount may be reset at any time, but it is not necessary to do so. As a non-limiting example, when an approximate payment amount is known, the linked member may or may not set the display upper limit amount so that the linked payable amount exceeds the approximate amount.

<Effects of the Fourteenth Example>
In this embodiment, the terminal 20 displays on the display unit 24 a displayed balance (not limited, an example of the balance of the second account based on the second amount) based on a display upper limit amount (not limited, an example of the second amount) set in a second user account (not limited, an example of the second account) of a user of a different terminal 20 (not limited, an example of the second user).The terminal 20 then shows a configuration in which the control unit 21 performs processing related to linked account payment (not limited, an example of processing related to the first payment) by the terminal 20 of the first user based on the first user account (not limited, an example of the first account) of the user of its own terminal 20 and the second user account in which the display upper limit amount is set.
As an example of an effect of an embodiment obtained by such a configuration, the balance of the second account associated with the first account of the first user can be made visible to the first user based on the second amount set in the second account. In this case, by way of example and not limitation, an amount different from an amount corresponding to the true balance of the second account can be set as the second amount, thereby concealing the true balance of the second account from the first user.
In addition, a first payment can be made by the terminal of the first user based on the first account and a second account in which the second amount is set.

In this embodiment, the control unit 21 controls the terminal 20 to set a display upper limit amount for the first user account based on an input to the terminal 20 by a user of the terminal 20 (not limited to this, but an example of a first user).The terminal 20 is configured to display on the display unit 24 the displayed balance of the first user account based on the set display upper limit amount and the displayed balance of the second user account based on the set display upper limit amount.
As an example of the effect of the embodiment obtained by such a configuration, a displayed amount (first amount) can be set for the first account as well. In this case, by way of example and not limitation, by setting the first amount to an amount different from the amount corresponding to the true balance of the first account, the true balance of the first account can be concealed from other users.
In addition, the first user may be able to check both the balance of the first account based on the set first amount and the balance of the second account based on the set second amount.

In this case, information on the maximum display amount set for the second user account can include information on the maximum amount to be displayed on the first user's terminal 20 from the electronic money account balance of the second user account (not limited to this, but an example of the balance of the second account).
As an example of the effect of an embodiment obtained by such a configuration, it is possible to allow the first user to visually confirm the set maximum amount while keeping the true balance of the second account secret.

In this case, information on the display upper limit amount set for the second user account may include information on the maximum amount that can be used in a single linked account payment.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to allow the first user to visually confirm the maximum amount that can be used for a single payment, which is set in the second account.

In this case, the displayed balance of the second user account displayed on the display unit 24 of the terminal 20 can be such that, if the electronic money account balance of the second user account is greater than the display upper limit amount, the display upper limit amount is displayed on the display unit 24, and, if the electronic money account balance of the second user account is less than the display upper limit amount, the electronic money account balance of the second user account is displayed.
As an example of an effect of an embodiment obtained by such a configuration, when the balance of the second account is greater than the second amount, the true balance of the second account can be concealed from the first user, whereas when the balance of the second account is less than the second amount, the true balance of the second account can be disclosed to the first user.

Furthermore, in this embodiment, the terminal 20 is configured to use the control unit 21 to control the change of the display upper limit amount set in the first user account based on input to the terminal 20 by the user of the terminal 20 (not limited to, but an example of the first user).
As an example of an effect of the embodiment obtained by such a configuration, the first amount once set in the first account can be changed.

In addition, this embodiment shows a configuration in which the second user account is a user account of the second user.
As an example of an effect of an embodiment obtained by such a configuration, payment can be realized based on a first account of a first user and a second account of a second user associated with the first account.

<Fourteenth Modification (1)>
In the above embodiment, an example has been described in which the display upper limit amount is increased when the payment margin of an associated member who makes a payment is insufficient with the set display upper limit amount, but the present invention is not limited to this.

As an example and not a limitation, if the payment capacity of any user other than user A who is making the payment is insufficient, in step A640 of FIG. 14-10, the control unit 21 of terminal 20A may or may not set the display upper limit amount addition amount so as to exceed the shortfall in the payment capacity of the other linked members.

<Fourteenth Modification (2)>
In the above embodiment, the insufficient payment margin is resolved by increasing the display upper limit amount of the person making the payment (user A.A. in this example), but the present invention is not limited to this.
By way of example and not limitation, a member may or may not request that other affiliated members increase their display upper limit.

FIG. 14-11 and FIG. 14-12 are flowcharts showing an example of the flow of processes executed by each device in this modified example.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.
By way of example and not limitation, after each step of FIG. 14-8 to FIG. 14-9 is performed, the processes of FIG. 14-11 to FIG. 14-12 are performed.

When the communication I/F 22 receives information about a shortfall in the linked balance from the server 10 (A200: YES), the control unit 21 of the terminal 20A transmits, via the communication I/F 22, display upper limit amount change request information to the server 10 to request that the displayed balance of another linked member (e.g., user B.B.), for example and not limitation, be increased to above the shortfall in the payment capacity of user A.A. (A650).

In addition, the control unit 21 of the terminal 20A may, for example and not by way of limitation, set the display upper limit amount addition amount based on user operation and send display upper limit amount change request information including the display upper limit amount addition amount, or may not do so.

In addition, the affiliated member requesting an increase in the displayed balance may be, for example and without limitation, a member with a large displayed balance, automatically selected, or may be selected by the user.

When display upper limit amount change request information is received from terminal 20A via communication I/F 14, the control unit 11 of server 10 transmits display upper limit amount change request information to request an increase in the displayed balance based on the display upper limit amount change request information via communication I/F 14 to the terminal of the affiliated member (e.g. user B.B.) requesting an increase in the displayed balance.

The control unit 11 of the server 10 may calculate the display upper limit amount addition amount based on the shortfall in the payment capacity and may or may not include the calculated display upper limit amount addition amount in the display upper limit amount change request information and send it.

When display upper limit amount change request information is received from the server 10 via the communication I/F 22 (B640: YES), the control unit 21 of the terminal 20B transmits display upper limit amount change information to the server 10 via the communication I/F 22 (B650). Details of the process are the same as step A640 in FIG. 14-10.

As an example and not a limitation, if an increase in the display upper limit amount is rejected based on a user operation on the input/output unit 23 of the terminal 20B, the control unit 21 of the terminal 20B may or may not choose not to execute step B650.

When display upper limit amount change information is received from terminal 20B via communication I/F 14, the control unit 11 of server 10 executes step S680 and then step S690.

In addition, in step A650, the control unit 21 of terminal 20A may or may not send the display upper limit amount change request information directly to terminal 20B via the communication I/F 22.

This modified example illustrates a configuration in which, when the payment amount of the account linked payment (not limited to this, but an example of the amount of the first payment) exceeds the total of the display upper limit amounts of the linked accounts, the terminal 20 sends display upper limit amount change request information (not limited to this, but an example of information regarding changing the second amount) to the second user account via the communication I/F 22.
As an example of an effect of an embodiment obtained by such a configuration, when the amount of the first payment exceeds the sum of the first amount and the second amount and the first payment cannot be made, a request can be made to the second account to change the set second amount.

<Fourteenth Modification (3)>
In the above embodiment, an example has been described in which the display upper limit amount is increased when the payment margin of an associated member who makes a payment is insufficient with the set display upper limit amount, but the present invention is not limited to this.
By way of example and not limitation, as described in the third embodiment, the other affiliated members may or may not be asked to advance the remaining payment.

<Display screen>
14-13 are diagrams showing an example of transition of screens displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Fig. 14-13 is a screen similar to the linked payment confirmation screen on the right side of Fig. 14-6, but the display is partially different. Specifically, at the bottom of the screen, a payment request button BT4 is displayed, which allows user A.A to have another user pay the shortfall in advance.

In the user A.A's item in the payment member confirmation area PMR3, a change limit button labeled "Change limit" is provided for changing the displayed limit. When the change limit button is tapped, the screen transitions to the screen shown on the left in FIG. 14-7, by way of example and not limitation.

When the advance payment request button BT4 is tapped, the screen shown in the center of FIG. 14-13 is displayed.
On this screen, an area for selecting a candidate affiliated member to be requested to pay on behalf of is displayed below the information indicating that the wallet is an affiliated wallet for the group "Bandmates." In this example, user C.C. is displayed as a candidate affiliated member to be requested to pay on behalf of the user.
In this example, user B.B. has a displayed balance of "4,000 yen" and does not have the financial capacity to advance the shortfall to user A.A., so he is not displayed as a candidate for an affiliated member to be requested to advance the shortfall.

A radio button is displayed associated with the candidate affiliated member to be requested to pay in advance (user C.C. in this example), and when the radio button is tapped to turn "ON," that affiliated member is selected as the affiliated member to be requested to pay in advance. This will then display the screen shown on the right side of Figure 14-13.

In this screen, the warning mark and the words "Insufficient balance" that were displayed in the payment amount confirmation area PIR3 on the screen on the left side of FIG. 14-13 have disappeared, and the words "Payment possible" are displayed instead.
In this state, when the linked payment execution button BT5 at the bottom of the screen is tapped, the payment is executed.

In addition, in the case where multiple affiliated members are able to pay in advance, by way of example and not limitation, the control unit 21 of terminal 20A may display candidate members who can pay in advance in order of the displayed balance, or it may not be necessary to do so.
Also, the associated member with the largest displayed balance may or may not be suggested as the person making the advance payment.

<Processing>
FIG. 14 is a flowchart showing an example of the flow of processes executed by each device in this modified example.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.
By way of example and not limitation, after each step of FIG. 14-8 to FIG. 14-9 is performed, the process of FIG. 14-14 is performed.

When the control unit 11 of the server 10 receives the linked payment request information from the terminal 20A via the communication I/F 14, the control unit 11 of the server 10 executes step S640. If the linked payment available amount is less than the planned payment amount (S640: YES), the control unit 11 of the server 10 executes step S220.

After executing step S235, the control unit 11 of the server 10 executes step S690. Then, it executes step S240.

In addition, after executing the process of FIG. 14-14, by way of example and not limitation, the process of FIG. 7-4 may be executed to settle the advance payment incurred in the linked balance replenishment process, or it may not be necessary to do so.

This modified example shows a configuration in which account linked payment (not limited to this, but an example of a first payment) is made between a first user account, a second user account, and a third user account linked to these user accounts, and the user account that pays the shortfall of the first user account is set to either the second user account or the third user account based on the maximum display amount set for the second user account and the maximum display amount set for the third user account.
As an example of an effect of an embodiment obtained by such a configuration, an account that pays the shortfall of the first account can be appropriately set based on the second amount set in the second account and the third amount set in the third account. By way of example and not of limitation, the account that has the higher amount set between the second account and the third account can be set as the account that pays the shortfall of the first account.

<Fourteenth Modification (4)>
In the fourteenth embodiment, the server 10 calculates the display balance based on the display upper limit amount obtained from the terminal 20 of the affiliated member and the balance of the affiliated member's electronic money account, and then transmits it to the terminal 20 of each affiliated member, but this is not limited to this.

As an example and not a limitation, processing similar to that of the above embodiment may or may not be performed by communication between terminals 20 without going through server 10.

As a non-limiting example, the server 10 may transmit the electronic money account balance of the associated member's terminal 20 to each associated member's terminal 20 instead of the displayed balance of the associated member's terminal 20. The associated member's terminal 20 may then calculate the displayed balance based on a display upper limit amount acquired by a method other than acquisition from the server 10 (as a non-limiting example, a display upper limit amount agreed upon in advance between the associated members, a display upper limit amount informed by an associated member who set the display upper limit amount, a display upper limit amount received from the associated member's terminal 20 who set the display upper limit amount, etc.).
In other words, the displayed amount of the balance of the second account may be controlled on the terminal 20 side.

<Fifteenth Example>
In the fourteenth embodiment, the displayed balance is limited by a display upper limit amount, which is a limit that affects the linked payment available amount for each payment.
In this embodiment, in addition to the maximum display amount, two restrictions are introduced as examples, not limitations, that affect when multiple payments are made in a linked wallet: the number of consecutive payments and the total amount restriction.

The contents described in the fifteenth embodiment are applicable to any of the other embodiments and the other modified examples.
In addition, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 15-1 is a diagram showing an example of the data configuration of the ninth linked wallet management database 157I, which is an example of a database for managing linked wallets in this case.
The ninth associated wallet management database 157I stores associated wallet management data as management data for each associated wallet.

By way of example and not limitation, each linked wallet management data stores a group ID, a group name, linked status management data, payment history data, and advance payment history data. By way of example and not limitation, the group ID, group name, payment history data, and advance payment history data are the same as those of the eighth linked wallet management database 157H.

In addition to the application ID, user name, link approval, and maximum display amount, the link status management data also stores, in association with each other, the number of consecutive payments and the total limit amount, by way of example and not limitation.

The number of consecutive payments is the number of times that payments can be made using this linked wallet. As a non-limiting example, if the number of consecutive payments for user B.B. is set to 5, up to 5 payments can be made from user B.B.'s electronic money account balance up to the displayed balance.

The total limit is the total amount that each linked account can bear when making a payment using this linked wallet. As a non-limiting example, if user A.A.'s total limit is set to "10,000 yen," user A.A. will bear the total amount of payments up to "10,000 yen" when making payments using this linked wallet, regardless of the number of payments. If the total limit is exceeded, payments will no longer be made from user A.A.'s account.

With the introduction of the total limit, the displayed balance for each linked account will be as follows:
Displayed balance = MIN (MIN (display upper limit, total limit), electronic money account balance)
Here, MIN(x, y) is a function that takes the minimum value among (x, y).
That is, the total limit amount must be set to an amount equal to or greater than the maximum display amount in order to avoid deviation from the original definition.

If the maximum display amount, total limit, and number of consecutive payments are not set, these values can be treated as any sufficiently large number (for example, an infinite number, but not limited to this).

<Display screen>
FIG. 15B is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
When the wallet link request button BT35 at the bottom of the screen on the left side of Figure 15-2 is tapped, the usage restriction setting screen in the center of Figure 15-2 is displayed.

On this usage limit setting screen, below the display field for information about User A.A's user account, information about setting the maximum display amount (in this example, already set/not set), information about setting the number of consecutive payments (in this example, already set/not set), and information about setting the total amount limit (in this example, already set/not set) are displayed. A change button for changing the settings is associated with each setting.

Also, at the bottom of the screen, a setting completion button BT43 is displayed to complete and confirm the currently displayed settings.

As a non-limiting example, when the change button in the display upper limit amount field is tapped, the screen on the right side of FIG. 15-2 is displayed.
This screen is for changing the upper limit displayed amount, and in this example, "3,000 yen" is input as the upper limit displayed amount to be changed. When the setting button BT41 at the bottom of the screen is tapped in this state, the upper limit displayed amount is set to the input amount.

The left side of Figure 15-3 shows the usage limit setting screen in the center of Figure 15-2, in which the display upper limit amount, number of consecutive payments, and total limit amount have been set. In this example, the display upper limit amount is set to "3,000 yen," the number of consecutive payments is set to "10 times," and the total limit amount is set to "10,000 yen." When the setting completion button BT43 at the bottom of the screen is tapped in this state, the screen in the center of Figure 15-3 is displayed.

This screen is the main screen for the linked wallet, and in the user A.A's column in the linked member information display area MIR4, the displayed balance "3,000 yen" and the electronic money account balance "10,000 yen" are displayed. Also displayed below that are the displayed upper limit amount "3,000 yen", the number of linked payments "10 times", and the total limit amount "10,000 yen".

In addition, for User B.B and User C.C, the wallet linking request from User A.A has not yet been approved, so the "Request in progress" mark is displayed for each of them.

The right side of Figure 15-3 shows the main screen of the linked wallet when the linkage is approved by user B.B and user C.C.
On this screen, the word "Requesting" has disappeared from the columns for User B.B and User C.C in the affiliated member information display area MIR4, and the displayed balances of each user are displayed.
In addition, in the column for user A.A in the linked member information display area MIR4, the displayed balance "3,000 yen" and the electronic money account balance "10,000 yen" are displayed. Also, below that, the displayed upper limit amount "3,000 yen", the number of linked payments "10 times", and the total limit amount "10,000 yen" are displayed.
Also, as wallet linking has been completed for all members of the group "Bandmates," the code reader icon IC2 and the code payment icon IC3 are no longer grayed out and are displayed as active.

<Processing>
15-4 to 15-6 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

When the control unit 21 of the terminal 20A executes step A510, by way of example and not limitation, it accepts the display upper limit amount, the total limit amount, and the number of consecutive payments based on user operation on the input/output unit 23 of the terminal 20A. Then, the control unit 21 of the terminal 20A transmits account limit setting information including the set display upper limit amount, the total limit amount, and the number of consecutive payments to the server 10 via the communication I/F 22 (A615).

After executing step B510, the control unit 21 of terminal 20B executes step B615, which is similar to step A615.

When the account limit setting information is received from terminal 20B via communication I/F 14, the control unit 11 of server 10 changes the link approval in the link status management data for the application ID of the received terminal to "Completed". Next, the control unit 11 of server 10 calculates the displayed balance based on the received displayed upper limit amount, total limit amount, and the electronic money account balance of the linked member. Then, by way of example and not limitation, the control unit 11 of server 10 transmits limited linked member information, including the application ID and displayed balance of the linked member, to the terminal of each member of the group via communication I/F 14 (S635).

Note that the limited linked member information may or may not include the number of consecutive payments for each linked account.

When the linked payment request information is received by the communication I/F 14, the control unit 11 of the server 10 calculates the payment margin based on the displayed balance for linked accounts with a consecutive payment count greater than 0, and calculates the linked payment possible amount. For accounts with a consecutive payment count of 0, the payment margin is set to 0. In other words, linked accounts with a consecutive payment count of 0 are excluded from the payment sharing targets.
Then, the control unit 11 of the server 10 determines whether or not the calculated cooperative payment possible amount is lower than the planned payment amount (S645).

When the linked payment request information is received via the communication I/F 14, the control unit 11 of the server 10 executes the store-presented restricted linked payment process (S695).

In the store-presented restriction linked payment process, after executing the process in step S690, if the payment process is successful, the total limit amount and the number of consecutive payments for each linked account are updated.
That is, the number of consecutive payments is decremented, and the payment margin of the linked account is subtracted from the total limit amount.

It is also possible to leave the settings for the number of consecutive payments and the total limit unchanged and rewrite the values in the temporary storage area linked to the number of consecutive payments and the total limit. In this case, the updated number of consecutive payments and the total limit stored in this temporary storage area are used to calculate the displayed amount in the above steps, determine the payment capacity, etc.

After executing step S695, the control unit 11 of the server 10 sends the linked payment result information to the linked member's terminal (S240) and determines whether to end the process (S699). By way of example and not of limitation, if the process is continuing on the linked member's terminal 20, the control unit 11 of the server 10 continues the process (S699: NO) and executes step S100 again.

When the linked payment result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A determines whether or not to continue the process based on, for example and not limitation, a user operation on the input/output unit 23 of the terminal 20A (A699). If the process is to be continued (A699: NO), the control unit 21 of the terminal 20A receives the linked wallet code reader information again and executes step A100.

The same applies to terminal 20B.

The processing in Figures 15-4 to 15-6 may be combined with the processing in Figure 7-4 to continue processing until the linked wallet is discarded, but this is not essential.

<Effects of the 15th embodiment>
This embodiment illustrates a configuration in which the terminal 20 uses the control unit 21 to set the number of consecutive payments, etc. (not a limitation, an example of a first setting related to making multiple payments) for the first user account based on input to the terminal 20 by the user of the terminal 20 (not a limitation, an example of a first user).
As an example of an effect of the embodiment obtained by such a configuration, settings related to performing a payment multiple times can be easily and appropriately performed on the first account.

In this case, the above settings indicate a configuration including a setting of the number of consecutive payments (not limited to this, but an example of a setting regarding the number of times a payment can be made using the first user account).
As an example of an effect of the embodiment obtained by such a configuration, the number of times a payment can be made using the first account can be easily and appropriately set.

In this case, the number of consecutive payments includes the number of times that a payment can be made without authenticating the first user of the first user account.
As an example of an effect of an embodiment obtained by such a configuration, while the number of payments has not reached the number of possible payments set by the first setting, authentication of the first user is not required and payment can be made based on the second account and the first account of the first user. On the other hand, when the number of payments has reached the number of possible payments set by the first setting, authentication by the first user is required, and unless the first user is authenticated, payment can be prevented from being made based on the second account and the first account of the first user.

<Fifteenth Modification (1)>
In the above embodiment, an example was shown in which if payments are made repeatedly and the number of consecutive payments of an affiliated member becomes "0" or less or the total limit amount becomes "0" or less, payments will no longer be made from that member's account, but this is not limited to the above example.

As an example and not by way of limitation, if a payment is made repeatedly and the number of consecutive payments by an associated member falls below "0" or the total limit falls below "0" (exceeding the number of consecutive payments or the total limit set in the associated account), payments may or may not be prevented from being made with the associated wallet (by way of example and not by way of limitation, generation of associated wallet payment tokens may be stopped).
In this case, by way of example and not limitation, automatic destruction of the associated wallet may or may not be performed.

<Fifteenth Modification (2)>
In the above embodiment, the number of payments made to the linked wallet is limited by the number of consecutive payments, but the present invention is not limited to this.
By way of example and not limitation, a consecutive payment count may or may not be defined for each affiliated member making payments.

As a non-limiting example, the settings for user A.A are such that user B.B can make payments "three times" and user C.C can make payments "five times." Then, when making a payment using terminal 20B, payments are charged to user A.A's account up to three times, and when making a payment using terminal 20C, payments are charged to user A.A's account up to five times.

Similarly, the total limit amount may be set for each user, or it may not be necessary to do so.

<Fifteenth Modification (3)>
In the above embodiment, when the consecutive payment count or the total limit amount of an associated member becomes equal to or less than "0", payments from that member's account are no longer executed. However, the present invention is not limited to this.
By way of example and not by way of limitation, a user who is restricted and therefore unable to make a payment may or may not be able to make the payment by obtaining consent at the time of making the payment.

In this case, by way of example and not limitation, with the permission of the member for whom the limit was triggered, the number of consecutive payments or the total limit amount may be increased so that the payment burden is once again met.

<Fifteenth Modification (4)>
In the above embodiment, an example has been described in which the display upper limit amount is increased when the payment margin of an associated member who makes a payment is insufficient with the set display upper limit amount, but the present invention is not limited to this.
As an example and not by way of limitation, as described in the fourteenth modification, the other cooperation members may be asked to advance the remaining payment amount, but this is not essential.

FIG. 15-7 is a flowchart showing an example of the flow of processes executed by each device in this modified example.
In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.
By way of example and not limitation, after each step in FIG. 15-4 to FIG. 15-5 is performed, the process in FIG. 15-7 is performed.

When the control unit 11 of the server 10 receives the linked payment request information from the terminal 20A via the communication I/F 14, the control unit 11 of the server 10 executes step S645. If the linked payment available amount is less than the planned payment amount (S645: YES), the control unit 11 of the server 10 executes steps S220 to S235.

After executing step S235, the control unit 11 of the server 10 executes step S695. Then, it executes step S240 and step S699.

Following the processing of FIG. 15-7, and by way of example and not limitation, the processing of FIG. 7-4 may be executed to execute a process for settling the advance payment incurred in the linked balance replenishment process, or it may not be necessary to do so.

In addition, in step A200, when selecting an affiliated member to cover the shortfall in payment capacity, if multiple affiliated members are available to pay in advance, the control unit 21 of terminal 20A may, but need not, display the candidates for members who can pay in advance in order of the number of consecutive payments. Also, the affiliated member with the most consecutive payments may, but need not, be suggested as the member who can pay in advance.

<16th Example>
In the twelfth to fifteenth embodiments, the application is a payment application, but the application is not limited to this.
The sixteenth embodiment is an embodiment in which a payment is made using a linked wallet in a group formed in a chat application (for example, but not limited to, a messaging application) and the payment is displayed in a chat room (for example, but not limited to, a talk room).

The contents described in the sixteenth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
In the following, it is assumed that User A.A, User B.B, and User C.C, who are users of both the messaging application and the payment application, all belong to the group "Bandmates" and are registered as friends.

FIG. 16A is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of FIG. 16-1 is a group chat room screen for the group "Bandmates," showing a state in which user A.A is having a group chat with users B.B and C.C. Specifically, user A.A sends a message to purchase an item, user B.B sends a message agreeing to this, and user C.C sends a message proposing that all group members pay for the price.
In this state, when the linked wallet icon IC1 at the bottom of the screen is tapped, the screen in the center of Figure 16-1 will be displayed.

On this screen, the linked wallet information display area WIR1 is displayed rising from the bottom of the group chat room screen on the left side of Figure 16-1. The linked wallet information display area WIR1 displays a list of users who are candidates for linked members (in this example, user A.A, user B.B, and user C.C) along with the text "Would you like to request wallet linking?" When the wallet linking request button BT35 at the bottom of the screen is tapped, the screen on the right side of Figure 16-1 is displayed.

On this screen, a code reader icon IC2 and a code payment icon IC3 are both displayed in an active state in the linked wallet information display area WIR1.
In addition, in the associated member information display area MIR4 below, information relating to the user account of user A.A, information relating to the user account of user B.B, and information relating to the user account of user C.C.

In this example, for User A.A, in addition to the displayed balance and electronic money account balance, the set display upper limit amount, the set number of consecutive payments, and the set total limit amount are also displayed.
In this example, the display balances of the other linked members, user B.B. and user C.C., are also displayed.

<Processing>
Regarding the processing in this embodiment, as an example and not a limitation, the processing in the payment application management server that manages the payment application and the messaging application management server that manages the messaging service can be executed in the same manner as the processing in the server 10 according to Figures 15-4 to 15-6, so a repeated explanation will be omitted.

<17th Example>
In the first to sixteenth embodiments, the embodiment has been described in which settlement (advance payment settlement) is performed between linked accounts for payments made after linkage approval.
The seventeenth embodiment is an embodiment relating to processing for payments made before the linkage was approved.
In the above embodiment, if there is an account that has not been approved for linking, it is not possible to make a payment. By way of example and not of limitation, it is possible that it may take time to obtain approval for account linking, in which case it may not be possible to make a payment until the linking is approved.

In the embodiment described below, settlement of payments made before the linked account approved the link is referred to as "retroactive settlement," meaning that it is a retroactive settlement, and is distinguished from the "advance settlement" described in the previous embodiment.
In addition, retroactive settlement is also a type of settlement. In other words, settlement includes "advance settlement" and "retroactive settlement."

The contents described in the seventeenth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

First, in this embodiment, based on the link between the first user account and the second user account (not limited to this, but an example of an association between the first account and the second account), information regarding at least the payment made by the second account is displayed on the display unit 24 of the terminal 20 of the first user of the first user account.
In this embodiment, the linkage between the first user account and the second user account (association between the first account and the second account) in this case is described as the first user account approving the linkage (linkage being approved) after the linked wallet is generated.
In addition, in this embodiment, based on the first user account approving the link, information regarding at least the payment made by the second user account before the linked wallet is generated (before the linked wallet generation request information is sent to the server) is displayed on the display unit 24 of the terminal 20 of the first user of the first user account.

Secondly, in this embodiment, after the information regarding the above payment is displayed on the terminal 20 of the first user of the first user account, it is possible for the first user account to retroactively settle the payment for that payment to the second user account.

As with the previous embodiment, one pattern is to link multiple user accounts of the same user (for example, but not limited to, the main account of user A.A. and the sub-account of user A.A.). In other words, it is also possible to link the first user account of a first user with the second user account of the first user.

By way of example and not limitation, a first user may make a payment using a second user account, which is then linked to the first user's first user account.
In this case, once the accounts are linked, the first user will view the payment history made by the second user account.
Thereafter, the first user may, by way of example and not limitation, determine that the electronic money account balance of the second user account is low and then transfer money from the first user account to the second user account.
This can be seen as an example, and not a limitation, of a method by which a single user can transfer funds between electronic money accounts of multiple user accounts.

Below, we will explain a different pattern from the above, where user accounts of different users are linked together.

In this embodiment, the memory unit 15 of the server 10 stores the information shown in Figure 1-3, by way of example and not limitation.

FIG. 17A is a diagram showing an example of the data structure of the second account management database 155B, which is an example of the account management database 155 used in this embodiment.
In the second account management database 155B, account management data is stored as management data for each application ID stored in the account registration data 153.

Each account management data stores, by way of example and not limitation, an application ID, an electronic money account balance, and payment history data. The application ID and electronic money account balance are, by way of example and not limitation, similar to those of the first account management database 155A.

The payment history data is data on the history of payments made using this user account, and by way of example and not limitation, the transaction ID, store ID, store name, payment date and time, and payment amount are associated with each other and stored in chronological order.
As an example and not by way of limitation, each element may be configured similarly to the payment history data in the linked wallet management data of the first linked wallet management database 157A.

FIG. 17-2 is a diagram showing an example of the data configuration of the tenth linked wallet management database 157J, which is an example of a database for managing linked wallets used in this embodiment.
The tenth associated wallet management database 157J stores associated wallet management data as management data for each associated wallet.

Each linked wallet management data stores, by way of example and not limitation, a linked wallet ID, linked account data, and payment history data. The linked wallet ID and payment history data are, by way of example and not limitation, similar to those of the first linked wallet management database 157A.

In addition to the application ID and user name, the linked account data also stores a link approval in association with the application ID and user name. The link approval is, by way of example and not limitation, similar to the link approval in the link status management data of the fifth linked wallet management database 157E.

<Display screen>
An example of a display screen when user B.B. makes a payment of "2,000 yen" at PP Supermarket using the user account of user B.B. before generating a linked wallet will be described below.

FIG. 17C is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The screen on the left side of Fig. 17-3 is a notification screen of the payment application, and in this example, information regarding a wallet linking request from user B.B is displayed. This information includes, by way of example and not limitation, text indicating that a wallet linking request has been made by user B.B, and an icon and text indicating that the wallet is a linked wallet for user A.A and user B.B, generated by user B.B.

Below that are displayed a link approval button containing the word "Link" to approve the link, and a link rejection button containing the word "Decline" to reject the link. When the link approval button is tapped, the screen in the center of Figure 17-3 is displayed.

This screen is the main screen of the linked wallet, and in the user B.B. column of the linked member information display area MIR1, in addition to information on the electronic money account balance of the user account of user B.B., an individual payment history button BT50 for displaying the payment history by the user account of user B.B. alone before the linked wallet was generated (hereinafter referred to as "individual payment history") is displayed.
It should be noted that the payment history may or may not be expressed as a settlement history.

When this Individual Payment History button BT50 is tapped, the screen on the right side of FIG. 17-3 is displayed.
On this screen, an icon and text indicating that this is a single payment history (shown as "Purchase History" on the screen) by user B.B's user account are displayed below the current location display area CLR1, and the single payment history is displayed below that. In this example, the single payment history for the purchase of "2,000 yen" worth of goods made by user B.B's user account at "PP Supermarket" on "August 2, 2020, 19:10:33" is displayed.

In other words, in this example, at the time user B.B made the payment, user B.B had not yet generated an associated wallet, and naturally user B.B had not requested wallet association from user A.A. However, user A.A approved the wallet association request from user B.B, and thus user A.A was able to view and confirm the individual payment history from user B.B's user account on his/her own terminal 20A.

Next, an example of retroactive settlement based on the individual payment history thus displayed will be described.
In the screen on the right side of FIG. 17-3, a remittance button BT52 is displayed in the display field for the individual payment history, for remittance from user A.A, who approved the linkage, to user B.B as a retroactive settlement for payments made by the user account of user B.B. In this example, a remittance button BT52 is displayed for remittance of "1,000 yen" as the amount of "2,000 yen" split between user A.A and user B.B.

In this way, this embodiment is configured so that user A.A can confirm user B.B's individual payment history and then transfer money to user B.B, assuming full or partial payment of the payment amount.

<Processing>
17-4 and 17-5 are flowcharts showing an example of the flow of processes executed by each device in this embodiment.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

First, the control unit 11 of the server 10 generates a payment token for the account of user B.B, and generates code reader information, which is information for reading a code, including the payment token. The control unit 11 of the server 10 then transmits the generated code reader information to the terminal 20B via the communication I/F 14 (S710).

When the communication I/F 22 receives the code reader information from the server 10, the control unit 21 of the terminal 20B activates the imaging unit 27 to read the code based on the received code reader information, by way of example and not limitation. The control unit 21 of the terminal 20B then reads the code to read the payment store code using the activated imaging unit 27, etc. Then, the control unit 21 of the terminal 20B obtains the store ID from the payment store code, and transmits user account payment request information including, by way of example and not limitation, the payment token, the store ID, and the planned payment amount to the server 10 via the communication I/F 22 (B710).

When the communication I/F 14 receives user account payment request information from terminal 20B, the control unit 11 of the server 10 executes a user account payment process based on the received payment token to make a payment of the planned payment amount between user B.B's account and the affiliated store specified by the store ID (S720). If the payment process is successful, the control unit 11 of the server 10 stores the payment history in the second account management database 155B.

As an example and not a limitation, when a selection is made to generate a linked wallet between user B.B's account and user A.A's account based on a user operation on input/output unit 23 of terminal 20B, control unit 21 of terminal 20B sends linked wallet generation request information including the application ID of the account to be linked to the linked wallet to server 10 via communication I/F 22 (B720).

When the control unit 11 of the server 10 receives the linked wallet creation request information from terminal 20B via the communication I/F 14, the control unit 11 creates a record of the linked wallet management data with the application ID in the linked wallet creation request information as linked account data, and sets the linkage approval to "not approved."Then, the control unit 11 sets the linkage approval to "approved" for the application ID of the user of terminal 20B (S730).
Then, the control unit 11 of the server 10 transmits wallet linkage approval confirmation information to the terminal 20A (S510).

When wallet linkage approval confirmation information is received from the server 10 via the communication I/F 22, the control unit 21 of terminal 20A determines whether to approve the linkage (A710), and if the linkage is approved (A710: YES), the control unit 21 transmits the wallet linkage approval information to the server 10 via the communication I/F 22 (A720). Details of steps A710 to A720 can be executed similarly to steps B500 to B510 in FIG. 10-4, for example and not for limitation. If the linkage is not approved (A710: NO), the control unit 21 of terminal 20A ends the process.

When the wallet linkage approval information is received from the terminal 20A via the communication I/F 14 (S520: YES), the control unit 11 of the server 10 sets the linkage approval for the application ID of the user of the terminal 20A to "done".
On the other hand, if the wallet link approval information is not received (S520: NO), the control unit 11 of the server 10 ends the process.

In addition, as a non-limiting example, when the control unit 11 of the server 10 receives wallet linkage approval information from the terminal 20A, the control unit 11 can notify the terminal 20B (user B.B) that the linkage has been approved by transmitting the wallet linkage approval information to the terminal 20B via the communication I/F 14.

Next, the control unit 11 of the server 10 transmits user account payment history information, which is a history of payments made under the user account of user B.B, to the terminal 20A via the communication I/F 14 (S740).

In addition, the payment history to be transmitted may be, but is not limited to, a history from a specified period prior to the associated wallet generation process being performed, or may not be transmitted.
Furthermore, the linked wallet creation request information may or may not include information for selecting the payment history to be sent in step S740.

When the user account payment history information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A displays the user account payment history information on the display unit 24 (A730).

Then, the control unit 21 of the terminal 20A executes steps A140 to A160 in FIG. 2-2, using, as an example and not as a limitation, the total payment amount in the settlement history divided as the recommended remittance amount. Note that the control unit 21 of the terminal 20A may, or may not, obtain the recommended remittance amount based on a user operation on the input/output unit 23 of the terminal 20A.

The control unit 11 of the server 10 executes steps S140 to S160 in FIG. 2-2.

When remittance result information is received from the server 10 via the communication I/F 22 (B730: YES), the control unit 21 of the terminal 20B displays the received remittance result information on the display unit 24 (B740) and ends the process.

Note that in the above process, an example of linking accounts of different users has been described, but as mentioned above, multiple accounts of the same user may or may not be linked.

<Effects of the 17th embodiment>
In this embodiment, the terminal 20 receives wallet linkage approval confirmation information (not limiting, an example of first information) for making an account linking payment based on a first user account (not limiting, an example of the first account) of a user of the terminal 20 (not limiting, an example of the first user) and a second user account via the communication I/F 22, and displays a display (not limiting, an example of the first display) of the received wallet linkage approval confirmation information on the display unit 24.
In addition, the terminal 20 performs processing related to account linkage and linkage approval (not limited to this, an example of processing related to association between a first account and a second account) via the control unit 21 based on input by the user of the terminal 20 in response to the display of wallet linkage approval confirmation information.
The terminal 20 is configured to display on the display unit 24 information on the payment history made by at least the second user account (not limiting, but an example of information regarding at least the first payment made by the second account) based on account linkage/linkage approval (not limiting, but an example of an association between the first account and the second account).
As an example of an effect of an embodiment obtained by such a configuration, based on the association between the first account and the second account, information regarding at least the first payment made by the second account is displayed on the display unit of the terminal, so that the first user can, by way of example and not limitation, check and understand the content of at least the first payment made by the second account before the first account and the second account were associated.

In this case, the terminal 20 can be configured to perform, through the control unit 21, a process for transferring part or all of the payment amount (not limited to, an example of a first amount that is at least a part of the first payment) from the first user account of the first user to the second account (not limited to, an example of a process related to transferring money from the first account to the second account) based on input by the user of the terminal 20 regarding the displayed payment history information.
As an example of an effect of an embodiment obtained by such a configuration, a first amount, which is at least a part of the first payment, can be transferred from a first account to a second account by the simple method of a first user inputting information regarding the first payment.

In addition, in this embodiment, the server 10 transmits to the terminal 20 via the communication I/F 14 wallet linkage approval confirmation information (not limiting, an example of the first information) for performing account linkage payment based on the first user account (not limiting, an example of the first account) of the user of the terminal 20 (not limiting, an example of the first user) and the second user account.
In addition, the server 10 performs processing related to account linkage and linkage approval (not limited to, but an example of processing related to association between a first account and a second account) via the control unit 11 based on input by the user of terminal 20 in response to the display of wallet linkage approval confirmation information displayed on terminal 20 (not limited to, but an example of a first display).
The server 10 is configured to transmit information on the payment history made at least by the second user account (not limited to, but an example of information regarding at least the first payment made by the second account) to the terminal 20 via the communication I/F 14 based on account linkage/linkage approval (not limited to, but an example of association between the first account and the second account).
As an example of an effect of an embodiment obtained by such a configuration, by transmitting information regarding at least a first payment made by the second account to a terminal of the first user based on the association between the first account and the second account, it is possible to allow the first user to confirm the content of the first payment made by at least the second account before the first account and the second account were associated, for example and not by way of limitation.

Here, the process related to account linking (not being limited to this, but being an example of a process related to associating a first account with a second account) is a concept that includes, not being limited to this, but being a process in which the terminal 20 requests the server 10 to link accounts, and a process in which the terminal 20 performs account linking.

In this case, the server 10 can perform a process (not limited to, an example of a process relating to transferring money from the first account to the second account) of part or all of the payment amount (not limited to, an example of a first amount that is at least a part of the first payment) from the first user account of the first user to the second account based on input by the user of the terminal 20 regarding the payment history information displayed on the terminal 20.
As an example of an effect of an embodiment obtained by such a configuration, a first amount, which is at least a part of the first payment, can be transferred from a first account to a second account based on an input by a first user regarding information related to a first payment displayed on the terminal.

In addition, in this embodiment, the terminal 20 transmits wallet linkage approval confirmation information (not limited to, an example of the first information) to the second user account via the communication I/F 22 in order to perform account linking payment based on a first user account (not limited to, an example of the first account) of the user of the terminal 20 (not limited to, an example of the first user) and the second user account.
In addition, between the time when the terminal 20 sends wallet linkage approval confirmation information to the second user account and the time when the terminal 20 receives wallet linkage approval information (not limited to this, an example of information regarding approval of the association between the first account and the second account) based on the wallet linkage approval confirmation information from the second account via the communication I/F 22, the terminal 20 performs processing (not limited to this, an example of processing related to the first payment) to perform account linkage payment based on at least the first user account.
The terminal 20 is configured to use the control unit 21 to perform a process of receiving a first amount (not limited to, but an example of an amount based on a first payment) transferred from the second user account based on account linkage/linkage approval (not limited to, but an example of an association between a first account and a second account).
As an example of an effect of an embodiment obtained by such a configuration, between sending first information regarding the association between a first account and a second account to the second account and receiving information from the second account regarding approval of the association between the first account and the second account based on the first information, it is possible to make at least a first payment based on the first account and then receive an amount based on the first payment transferred from the second account based on the association between the first account and the second account.

<Seventeenth Modification (1)>
In the above embodiment, a retroactive settlement is made between linked accounts for payments made before the linked wallet generation request information is sent from terminal 20B to server 10, but this is not limited to the above.
As an example and not as a limitation, retroactive settlement may or may not be made for payments made between the time when the linked wallet generation request information is sent from terminal 20B to server 10 and the time when the first user account that has been requested to approve wallet linkage approves the linkage.

In addition, the period from when linked wallet generation request information is sent from terminal 20B to server 10 to when the first user account of terminal 20A, which has been requested to approve wallet linkage, approves the linkage includes the period from when terminal 20A receives wallet linkage approval confirmation information from server 10 to when the first user account approves the linkage.
Therefore, this also includes making retroactive settlements for payments made between the time terminal 20A receives wallet linkage approval confirmation information (not limited to this, but an example of the first information) and the time the first user account approves the linkage.

In addition, the period from when linked wallet generation request information is sent from terminal 20B to server 10 until the first user account of terminal 20A, which has been requested to approve wallet linkage, approves the linkage includes the period from when server 10 sends wallet linkage approval confirmation information to terminal 20A until the first user account approves the linkage.
Therefore, this also includes making retroactive settlements for payments made between the time when the server 10 sends wallet linkage approval confirmation information (an example of the first information, not limited to this) and the time when the first user account approves the linkage.

FIG. 17-6 is a flowchart showing an example of the flow of the process executed by each device in this case.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), and processing performed by the control unit 11 of server 10.

The control unit 21 of terminal 20B executes step B720, and then executes step B710. Then, the control unit 11 of server 10 executes step S730, then executes step S510, and executes steps S710 to S720, and then executes step S520.

As a result, the user account payment history information sent in step S740 includes information on the history of payments made from the time the linked wallet creation request information was sent from terminal 20B to server 10 until user A.A approved the link.

This modified example shows a configuration in which an account linking payment (an example of the first payment, not limited to the above) is an account linking payment made between the time when terminal 20 receives wallet linking approval confirmation information (an example of the first information, not limited to the above) and the time when linking is approved.
As an example of the effect of the modified example obtained by such a configuration, information relating to a first payment made between when the terminal receives the first information and when the first account is associated with the second account can be displayed on the display unit of the terminal so that the first user can check and understand the details.
In addition, for a first payment made between when the terminal receives the first information and when the first account is associated with the second account, a first amount, which is at least a part of the first payment, can be transferred from the first account to the second account.

<Seventeenth Modification (2)>
In the above modified example, the payment history information transmitted in step S740 of FIG. 17-6 is information on the history of payments made under the user account, but is not limited to this.
For example and not for limitation, the payment history information may be information on the history of payments made in a linked wallet after the linked wallet is created and before the linked account approves the link. In other words, payment history may be displayed and retroactive settlement may be performed for payments made in a linked wallet after the linked wallet is created and before the linked account approves the link.

FIG. 17-7 is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20A in this modified example.
The left side of FIG. 17-7 is the main screen of the payment application, showing the state in which user A.A. has approved the linkage.
In this example, a linked wallet payment history button BT54 is displayed in the display field for information indicating that the linked wallet is for user A.A and user B.B. The linked wallet payment history button BT54 is used to display the history of payments made in the linked wallet from the time the linked wallet was created until user A.A approved the link (hereinafter referred to as the "linked wallet payment history"). When the linked wallet payment history button BT54 is tapped, the screen shown on the right side of FIG. 17-7 is displayed.

On this screen, below the current location display area CLR1, an icon and text indicating that this is the linked wallet payment history (shown as "Purchase History" on the screen) using the linked wallets of User A.A. and User B.B. are displayed, and below that the linked wallet payment history is displayed. In this example, the linked wallet payment history for the purchase of "2,000 yen" worth of goods made at "PP Supermarket" on "August 2, 2020, 19:10:33" using the linked wallet is displayed.

This display area also displays a remittance button BT56 for user A.A to remit (return) the amount advanced to user B.B for the payment made using the linked wallet. In this example, a remittance button BT56 for remittance of "1,000 yen" is displayed, which is the amount split between users A.A and B.B of "2,000 yen."

That is, in this example, based on the user A.A's approval of the linkage, the system is configured so that the user A.A can view and check on his/her own terminal 20A the history of payments made using the linked wallet made after the linked wallet was generated by user B.B and before user A.A approved the linkage.
Furthermore, after checking the payment history using this linked wallet, user A.A can bear all or part of the amount paid using the linked wallet and remit the amount to user B.B, who has made the payment on his/her behalf (returning the amount paid in advance).

In this case, by way of example and not limitation, payments can be made with the linked wallet even if there are accounts in the linked wallet that have not yet been approved for linkage (if there are accounts for which linkage approval has not been granted). Then, the payment history is stored in the tenth linked wallet management database 157J, and in step S740 of FIG. 17-6, by way of example and not limitation, the payment history with the linked wallet is transmitted.

Note that the number of linked members in a linked wallet is not limited to two (or two linked accounts). The same applies when there are three or more linked members (or three or more linked accounts).

As a non-limiting example, suppose that linked wallets are generated for user A.A, user B.B, and user C.C, and when user A.A and user C.C approve the link, a payment of "900 yen" is made in the linked wallet, and user A.A and user C.C pay the equal payment amount of "450 yen" for the two of them. If user B.B then approves the link, user B.B may send "150 yen", which is the equal payment amount of "450 yen" for the two of them and the equal payment amount of "300 yen" for the three of them, to user A.A and user C.C, respectively.

Note that the linked account in a linked wallet is not limited to a user account. By referring to the eighth embodiment as an example and not a limitation, the above method may or may not be applied to a linked wallet between a common wallet and a user account, or to a linked wallet between multiple common wallets.

This modified example shows a configuration in which the account linked payment is made between a second user account (not limited to, but an example of a second account) and a third user account (not limited to, but an example of a third account associated with the second account) linked to the second user account.
As an example of the effect of the modified example obtained by such a configuration, information regarding a first payment made to a second account and a third account associated with the second account can be displayed on the display unit of the terminal so that the first user can check and understand the details.
In addition, for a first payment made to a second account and a third account associated with the second account, a first amount that is at least a portion of the first payment can be transferred from the first account to the second account.

In addition, this modified example shows a configuration in which the linked second account is a common wallet account (not limited to this, but is an example of a common account to which multiple users can make payments).
As an example of an effect of an embodiment obtained by such a configuration, a common account that multiple users can use for payment can be associated with a first account as a second account, thereby improving user convenience.

<Seventeenth Modification (3)>
In the above embodiment, even if the first user account is in an unapproved state for linking, the first user account may be able to view at least the payment history made by the second user account (the aforementioned individual payment history and linked wallet history) and make transfers (retroactive settlement) to the second user account.

In this case, as an example and not as a limitation, the terminal 20 receives wallet linkage approval confirmation information (an example of first information, not as a limitation) via the communication I/F 22, and displays a display of the received wallet linkage approval confirmation information (an example of the first display, not as a limitation) on the display unit 24.
In this case, even if the first user account has not yet approved the link, when the user (first user) of his/her terminal 20 makes an input to display the payment history (single payment history or linked wallet payment history), the terminal 20 can request the payment history from the server 10 and, based on receiving the payment history sent from the server 10, display the payment history on the display unit 24.

In this case, even if the first user account has not yet approved the link, the terminal 20 can perform processing by the control unit 21 to transfer part or all of the payment amount from the first user account of the user of the terminal 20 (the first user) to the second account based on the input to the displayed payment history.

<Seventeenth Modification (4)>
As mentioned above, the period covered by retroactive settlement is, by way of example and not by way of limitation, as follows:
Either of the following can be applied: (a) the period before the linked wallet creation request information is sent from terminal 20B to server 10; or (b) the period from when the linked wallet creation request information is sent from terminal 20B to server 10 until the user account requested to approve wallet linkage approves the linkage.

However, by way of example and not limitation, the period (a)+(b) may or may not be the period that is subject to retroactive settlement.

In addition, the period for which the payment history (settlement history) is displayed may or may not be different from the period for which retroactive settlement is performed.
By way of example and not limitation, the period for which the payment history is displayed may be period (a)+(b), but the period for which retroactive settlement is applied may be period (a). Alternatively, by way of example and not limitation, the period for which the payment history is displayed may be period (a)+(b), but the period for which retroactive settlement is applied may be period (b).

<18th Example>
In the seventeenth embodiment, it has been explained that payments related to an associated wallet are possible even if not all associated members of the associated wallet have approved the association.
In relation to this, the 18th embodiment is an embodiment in which an associated wallet is generated on a group basis for a messaging application (messaging service) and payments can be made using the associated wallet of this group even if all group members have not approved the association.

The contents described in the 18th embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, the storage unit 15 of the server 10 stores the information shown in FIG. 4A by way of example and not limitation.
FIG. 18-1 is a diagram showing an example of the data configuration of the eleventh linked wallet management database 157K, which is an example of a database for managing linked wallets used in this embodiment.
The eleventh linked wallet management database 157K stores linked wallet management data as management data for each linked wallet.

By way of example and not limitation, each linked wallet management data stores a group ID, a group name, linked status management data, payment history data, advance payment history data, and payment participating account data. The group ID, group name, linked status management data, payment history data, and advance payment history data are, by way of example and not limitation, similar to those of the fifth linked wallet management database 157E.

The payment participating account data is data for storing the account that was linked at the time of each payment (payment) stored in the payment history data, and by way of example and not limitation, the transaction ID and the payment participating account ID are stored in association with each other.

The transaction ID is identification information for identifying a payment (payment) in the payment history data. The payment participating account ID is the application ID of the linked account for which link approval was "done" in this linked wallet when the payment identified by the transaction ID was executed.

In FIG. 18-1, by way of example and not by way of limitation, it is shown that when making a payment with "XX Instrument," user A.A and user B.B have agreed to the payment with the linked wallet. In other words, it is shown that the payment with "XX Instrument" in the linked wallet of the group "Bandmates" involves (bears) the costs of user A.A and user B.B, and user C.C is not involved in (bears) the costs of the payment.

<Display screen>
In the following, it is assumed that User A.A, User B.B, and User C.C, who are users of both the messaging application and the payment application, all belong to the group "Bandmates" and are registered as friends.

Furthermore, User A.A creates a linked wallet for "Bandmate", and before User B.B and User C.C approve the link, User A.A pays "4,500 yen" to "XX Musical Instrument" using the linked wallet for "Bandmate".

FIG. 18B is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of FIG. 18-2 is a diagram showing an example of a talk room screen of a messaging application displayed on the display unit 24 of the terminal 20A.
This talk room screen is a group talk room screen for the group "Bandmates," and shows a state in which user A.A is talking (chatting) with user B.B and user C.C.

In this example, user A.A sends a message to purchase a product (in this example, a score for a live performance), and user B.B suggests that all members of the group pay for it. However, user C.C is short on money, so user C.C sends a message to make the payment later, and user A.A agrees to this. In this state, when the linked wallet icon IC1 at the bottom of the screen is tapped, the screen in the center of Figure 18-2 is displayed.

In this screen, linked wallet information display area WIR1 is displayed rising from the bottom of the group chat room screen on the left side of Figure 18-2. This linked wallet information display area WIR1 displays the message "Request wallet linking?" along with the message that the group members of the group "Bandmates" (User A.A, User B.B., User C.C) will be linked members. When the wallet linking request button BT35 is tapped in this state, wallet linking request information is sent from terminal 20A to terminals 20B and 20C via server 10.

The right side of FIG. 18-2 shows an example of a talk room screen of a messaging application displayed on the display unit 24 of the terminal 20B in this case.
This chat room screen is a group chat room screen for the group "Bandmates," and displays a wallet linking request message from user A.A below a message in which user A.A has approved user C.C's deferred payment. Also, below that, a message reporting that user A.A has purchased a product is displayed.

The wallet linking request message includes, by way of non-limiting example, a linking approval button and a linking rejection button in addition to text and an image indicating that a wallet linking request has been made by user A.A.
When the link approval button is tapped, the screen shown on the left side of FIG. 18-3 is displayed on the display unit 24 of the terminal 20B.

On this screen, a linked wallet information display area WIR1 is displayed rising from the bottom of the chat room screen for the group "Bandmates."
In the linked wallet information display area WIR1, a linked wallet payment history button BT54 is displayed in the display field for information indicating that this is a linked wallet for the group "Bandmates."

The linked member information display area MIR1 displays the electronic money account balances of users A.A and B.B. However, since user C.C. has not yet been approved for linkage, the "Requesting" mark is displayed.

When the linked wallet payment history button BT54 is tapped, the screen shown in the center of Figure 18-3 will be displayed.
On this screen, the linked wallet information display area WIR1 displays information about a payment of "4,500 yen" to "XX Musical Instruments" as the payment history of the linked wallet of the group "Bandmate." Also displayed in this display area is a settlement button BT58 for retroactively settling this payment. When the settlement button BT58 is tapped, the screen on the right side of FIG. 18-3 is displayed.

In this screen, information about the settlement details is displayed in pop-up format in the center of the linked wallet information display area WIR1. In this example, since user C.C. has not yet been approved for linking, the payment will be shared by both user A.A. and user B.B.

The above payment is a payment made to the linked wallet after user A.A created the linked wallet and before user B.B approved the link. For this reason, user B.B needs to settle his or her share retroactively. In this example, the message "Do you want to settle past payments?" is displayed along with information about a transfer of "2,250 yen" from user B.B to user A.A. When the "Yes" button below is tapped, the transfer from user B.B to user A.A is made.

FIG. 18-4 is a diagram showing an example of a talk room screen displayed on the display unit 24 of the terminal 20 of each member of the group “Bandmates” in the above example.
Illustrated from the left are examples of group talk room screens displayed on terminal 20A, terminal 20B, and terminal 20C.

On the group talk room screen displayed on terminal 20A, messages are displayed in the following chronological order: payment completion notification message via linked wallet → product purchase report message from user A.A via linked wallet → wallet linking message from user B.B → settlement completion notification message.

On the group talk room screen displayed on terminal 20B, messages are displayed in the following chronological order: product purchase report message from user A.A using the linked wallet → wallet linking message from user B.B → payment completion notification message using the linked wallet → settlement completion notification message.

On the group talk room screen displayed on terminal 20C, messages are displayed in the following chronological order: wallet linking request message from user A.A → product purchase report message from user A.A using the linked wallet → wallet linking message from user B.B.

In this example, the payment completion notification message and the settlement completion notification message are not displayed on the group talk room screen displayed on terminal 20C. This is because user C.C. is in an unapproved link state and is not currently involved in the payment.

FIG. 18-5 is a diagram showing an example of a talk room screen of a messaging application displayed on the display unit 24 of the terminal 20C.
This chat room screen is the group chat room screen for the group "Bandmates," and in the screen on the left side of Figure 18-5, a linked wallet information display area WIR1 is displayed rising from the bottom of the chat room screen for the group "Bandmates."

In the linked wallet information display area WIR1, since user C.C. is in an unapproved linkage state, the use of the linked wallet is restricted.
Specifically, the code reader icon IC2 and the code payment icon IC3 are grayed out, and are configured so that even if they are tapped, the operation will not be accepted.
In addition, the linked wallet payment history button BT54 is also grayed out, and is configured so that even if it is tapped, the operation will not be accepted.
In addition, the linked wallet discard button BT30 is also grayed out, and is configured so that the operation will not be accepted even if tapped.

By way of example and not limitation, when the greyed out code payment icon IC3 is tapped, the screen on the right side of FIG. 18-5 is displayed.
On this screen, information indicating that payments cannot be made unless wallets are linked is displayed in a pop-up format in the center of the linked wallet information display area WIR1. Specifically, the words "Payments cannot be made unless wallets are linked" are displayed.
Below that is a link approval button labeled "Link your wallet," and when the link approval button is tapped, restrictions on using the linked wallet will also be lifted.

<Processing>
FIG. 18-6 is a flowchart showing an example of the flow of the process executed by each device in this case.
This diagram shows an example of processing executed by a system configured with a terminal 20 and a server 10. Note that the server 10 may or may not be configured separately into a payment application management server that manages payment services and a messaging application management server that manages messaging services.

First, by way of example and not limitation, an associated wallet generation process is executed to generate a new associated wallet based on a user operation on the terminal 20 (L100).

The trigger or condition for executing the associated wallet generation process is not limited to the operation in the group chat room described in the example display screen. For example and without limitation, when a new group is created, the associated wallet generation process for the group may or may not be automatically executed.
In addition, when a chat room between two users is created, a linked wallet may be automatically created for the chat room, or it may not be necessary to do so. In this case, the chat room may be treated as a group of two members.

FIG. 18-7 is a flowchart showing an example of the process flow executed by each device in the linked wallet generation process.
In this figure, from the left, there are shown an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), which is the terminal of a user instructing the generation of an associated wallet in a certain group, processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), which is the terminal of a member of this group, and processing performed by the control unit 11 of server 10.

The control unit 21 of terminal 20A executes steps A500 to A510. When the control unit 11 of the server 10 executes steps S500 to S505, it transmits, via the communication I/F 14, linked wallet information indicating that a linked wallet payment token for the linked wallet in this group can be generated and that the linked wallet can be used, to the terminal 20 for which linkage approval is "done" in the fifth linked wallet management database 157E (in this case, terminal 20A) (S750). The control unit 11 of the server 10 then transmits, via the communication I/F 14, wallet linkage approval confirmation information to the terminal 20 for which linkage approval is "not yet" in the fifth linked wallet management database 157E (in this case, terminal 20B, as an example and not a limitation) (S760).

When the communication I/F 22 receives linked wallet information from the server 10, the control unit 21 of terminal 20A executes step A540 and ends the process. Also, when the communication I/F 22 receives wallet linkage approval confirmation information from the server 10, the control unit 21 of terminal 20B displays the wallet linkage approval confirmation information on the display unit 24 (B750) and ends the process.

Returning to FIG. 18-6, when approval of the link is selected based on a user operation on a terminal 20 for which link approval is "not approved" (L110: Link approval), the account addition link process is executed (L120).

FIG. 18E is a flowchart illustrating an example of a process flow executed by each device in the account addition link process.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), which is a terminal of a linked user, processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), which is a terminal of an unlinked user, and processing performed by the control unit 11 of server 10.

When wallet linkage approval information is received from terminal 20B via communication I/F 14 (S520: YES), control unit 11 of server 10 changes the linkage approval in the linkage status management data for the application ID of the received terminal to "Done" and executes step S530. When wallet linkage approval information is not received (S520: NO), control unit 11 of server 10 skips step S530. Then, control unit 11 of server 10 executes steps S750 to S760 and ends the process.

After executing step A520, the control unit 21 of terminal 20A executes step A540 and ends the process.

When linked wallet information is received from the server 10 via the communication I/F 22 (B530: YES), the control unit 21 of terminal 20B executes step B540 and ends the process. When linked wallet information is not received (B530: NO), the control unit 21 of terminal 20B receives wallet linkage approval confirmation information from the server 10 via the communication I/F 22, displays the wallet linkage approval confirmation information on the display unit 24 (B760), and ends the process.

Returning to FIG. 18-6, if the linked wallet is approved to link a new account during the account addition linking process (L130: YES), the linked wallet retroactive settlement process is executed (L140). If the linked wallet is not approved to link (L130: NO), the process returns to step L110.

Even if new account linkage is approved (L130: YES), by way of example and not limitation, if retroactive settlement is not approved for the newly approved terminal 20, the linked wallet retroactive settlement process may or may not be executed.

FIG. 18-9 is a flowchart showing an example of the flow of processing executed by each device in the linked wallet retroactive settlement process.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), which is the terminal of a user whose account has already been linked, processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), which is the terminal of a user whose account has been newly linked, and processing performed by the control unit 11 of server 10.

The control unit 11 of the server 10 references the payment participating account data in the 11th linked wallet management database 157K and searches for transaction IDs in which the newly approved account for linking is not participating among payments made using the linked wallet. Then, based on the searched transaction IDs, payment history data, and advance payment history data, it calculates the retroactive settlement amount required for each transaction ID and the amount to be sent to each account, and links this to the payment history data to generate linked wallet retroactive settlement candidate information. The control unit 11 of the server 10 then transmits the linked wallet retroactive settlement candidate information to terminal 20B via the communication I/F 14 (S765).

By way of example and not limitation, when payments in linked wallets are split evenly, the amount required for retroactive settlement and the amount to be transferred to each account may be calculated as follows, by way of example and not by way of limitation:
・Retroactive settlement required amount = payment amount in settlement ÷ (number of accounts recorded in settlement participating account data + 1)
・Amount transferred to each account recorded in the settlement participating account data = amount required for retroactive settlement ÷ number of accounts recorded in the settlement participating account data

When determining the amount to be sent to an account for which there is advance payment history data, the advance payment amount may be referenced and the amount to be sent to the payer may be increased up to the advance payment amount, and the amount to be sent to the payee may be decreased by that amount, or it may not be necessary. In this case, the control unit 11 of the server 10 updates the advance payment amount when retroactive settlement is performed. If the advance payment amount becomes "0", the control unit 11 of the server 10 erases the advance payment history for that transaction from the advance payment history data.

When the linked wallet retroactive settlement candidate information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B determines whether or not to transfer the amount required for retroactive settlement for each transaction in the linked wallet retroactive settlement candidate information, based on, for example but not limited to, user operation, and transmits retroactive settlement information, which is information about the transaction for which retroactive settlement is to be performed, to the server 10 via the communication I/F 22 (B780).

The amount required for retroactive settlement and the amount to be sent to each account may or may not be calculated by terminal 20B based on the payment history data and advance payment history data. The amount required for retroactive settlement and the amount to be sent to each account may or may not be determined based on a user operation on terminal 20B.

When the communication I/F 14 receives the retroactive settlement information from terminal 20B, the control unit 11 of the server 10 executes a transfer from user B.B's account to each account recorded in the payment participating account data for the selected transaction. Then, when the amount required for retroactive settlement is transferred, the control unit 11 of the server 10 adds and stores the user account that performed the retroactive settlement to the payment participating account data (S780).

Then, the control unit 11 of the server 10 transmits the retroactive settlement result information, which is the result of the remittance in the retroactive settlement process, to each terminal via the communication I/F 14 (S790). Then, the control unit 11 of the server 10 ends the process.

The retroactive settlement result information may or may not include information about remittances that are not related to the account of the terminal receiving the retroactive settlement result information. The retroactive settlement result information may be sent to all group members, or may be sent only to the terminals of members whose collaboration approval has been "approved."

When the control unit 21 of the terminal 20A receives the retroactive settlement result information from the server 10 via the communication I/F 22, the control unit 21 causes the display unit 24 to display the retroactive settlement result information (A760), and ends the process.
When the control unit 21 of the terminal 20A receives the retroactive settlement result information from the server 10 via the communication I/F 22, the control unit 21 causes the display unit 24 to display the retroactive settlement result information (B790), and ends the process.

Returning to Figure 18-6, once the linked wallet retroactive settlement process has been executed, processing returns to step L110.

As a non-limiting example, when a user operation on the terminal 20 selects to make a payment using a linked wallet (L110: Payment), the control unit 11 of the server 10 determines whether or not the account of the terminal 20 attempting to make the payment has been approved for linking (L150).

If the account of the terminal 20 attempting to make a payment has been approved for linkage (L150: YES), linked wallet payment processing is executed (L160). The linked wallet payment processing can be executed according to FIG. 7-3, for example and not for limitation.

In the linked wallet payment process, if the linked payable amount is insufficient and the linked balance replenishment process is executed (L170: YES), the linked wallet settlement process is executed (L180). After the linked wallet settlement process is executed, the process returns to step L110.
In addition, the linked wallet settlement process can be performed according to Figure 7-5, for example and not for limitation.

If no advance payment is made for the linked payable amount in the linked wallet payment process (L170: NO), the linked wallet settlement process is not executed.

Note that even if no advance payment was made for the linked payable amount in the immediately preceding linked wallet payment process, if advance payment history data exists for the previous linked wallet payment process and the advance payment has not been resolved, the linked wallet settlement process may or may not be executed.

If the account of the terminal 20 attempting to make the payment has not been approved for linkage (L150: NO), the linked wallet payment process is not executed and the process returns to step L110.
In this case, the wallet linkage approval confirmation information may be displayed again on the display unit 24 of the terminal 20 attempting to make the payment, to prompt approval of the linkage, or it may not be necessary to do so.

As a non-limiting example, when a user operation on the terminal 20 is selected to check the payment history using the linked wallet (L110: Check history), the control unit 11 of the server 10 determines whether or not the account of the terminal 20 attempting to make a payment has been approved for linkage (L185). If the account of the terminal 20 attempting to make a payment has been approved for linkage (L185: YES), a linked wallet payment history check process is executed (L190).

In the linked wallet payment history confirmation process, the control unit 11 of the server 10 refers to the 11th linked wallet management database 157K, and transmits the payment history data and advance payment history data of this linked wallet to the terminal 20 (terminal 20A, as an example and not a limitation) that requested the history confirmation via the communication I/F 14. In addition, payment participating account data may or may not be transmitted.

The control unit 11 of the server 10 may or may not transmit only the history of transactions that occur after the terminal 20A has approved the linkage, out of the payment history data and the advance payment history data.

When the payment history data and the advance payment history data are received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the payment history data and the advance payment history data.
In addition, the control unit 21 of terminal 20A may additionally receive payment participating account data and display only the history of transactions that occur after terminal 20A has approved the connection, from the payment history data and advance payment history data, or it may not be possible to do so.

If an advance payment settlement or retroactive settlement for payment made before the collaboration approval is selected from the displayed payment history data based on user operation on the input/output unit 23 of the terminal 20A (L200: YES), the control unit 11 of the server 10 determines the content of the settlement (L210).
If the settlement content is an advance payment (L210: Advance payment), the linked wallet settlement process is executed (L180). On the other hand, if the settlement content is a retroactive settlement for a payment made before the linkage was approved (L210: Retroactive settlement), the linked wallet retroactive settlement process is executed (L140).
In addition, advance settlement and retroactive settlement of multiple transactions may or may not be performed together.

As an example and not a limitation, when a user operation on the terminal 20 selects to destroy the associated wallet (L110: destroy), an associated wallet destroy process is executed (L220). As an example and not a limitation, the associated wallet destroy process can be executed according to the steps from S340 onwards in FIG. 7-4. The system then ends the process.

Before executing the associated wallet discarding process, the associated wallet retroactive settlement process, the associated wallet settlement process, or both may or may not be executed. Also, if transactions remain in the advance payment history data, the associated wallet discarding process may or may not be executed. If retroactive settlement has not been completed, the associated wallet discarding process may or may not be executed.

FIG. 18-10 is a diagram showing an example of a timing chart for explaining the timing at which each process is executed in this embodiment.
Here, we will explain the timing at which the account addition link process, linked wallet payment process, and linked wallet retroactive settlement process described in the above flow are instructed to be executed at each terminal. To simplify the explanation, we will consider a case where no advance payment is required in the linked wallet payment process.

The terminal that executes the creation of the linked wallet is assumed to be terminal 20A. The terminals of the other linked members of the linked wallet are assumed to be terminal 20B and terminal 20C.
In this timing chart, the horizontal axis is the time axis, and the timing when each terminal 20 performs account addition linkage processing is indicated by a white hexagon, the timing when it performs linked wallet payment processing is indicated by a white circle, and the timing when it performs linked wallet retroactive settlement processing is indicated by a white square.

After the associated wallet generation process, payment 1 is executed at terminal 20A. Only user A.A participates in payment 1.
Thereafter, the account addition linkage process is executed in terminal 20B. Then, the linked wallet retroactive settlement process for payment 1 is executed in terminal 20B.

Next, payment 2 is executed at terminal 20B. Payment 2 involves users A.A and B.B.
Thereafter, the account addition linkage process is executed in terminal 20C. Then, the linked wallet retroactive settlement process for payment 1 and payment 2 is executed in terminal 20C.
Then, payment 3 is executed at terminal 20C. Payment 3 involves users A.A, B.B, and C.C.

Finally, the linked wallet destruction process is executed by one of the terminals 20, and the process is terminated.

<Effects of the 18th embodiment>
This embodiment illustrates a configuration in which wallet linkage approval confirmation information (an example of the first information, not limited to the present invention) is transmitted to the terminal 20 of the first user based on input by the second user of the second user account to a talk room (an example of a chat room, not limited to the present invention) including the first user of the first user account and the second user.
As an example of an effect of an embodiment obtained by such a configuration, first information can be easily transmitted to a terminal of a first user based on an input by a second user of a second account to a chat room including the first user and the second user.

In addition, this embodiment illustrates a configuration in which wallet linkage approval confirmation information (an example of the first information, not limited to the present invention) is transmitted to the terminal 20 of the first user based on the creation by the second user of the second user account of a talk room (an example of a chat room, not limited to the present invention) including the first user of the first user account and the second user.
As an example of an effect of an embodiment obtained by such a configuration, the first information can be easily transmitted to the terminal of the first user based on the creation of a chat room including the first user and the second user by the second user of the second account.

In addition, in these cases, the terminal 20 can display information in the chat room indicating that the amount has been transferred to the second user account based on a process for transmitting part or all of the payment amount from the first user account to the second user account.
As an example of an effect of an embodiment obtained by such a configuration, a first user of a first account can be notified that a first amount has been transferred to a second account in an easy-to-understand manner by displaying the information in a chat room.

In addition, in these cases, when the first user account and the second user account are not linked, the terminal 20 can be configured to control the control unit 21 to not display on the display unit 24 a code reader screen (not limiting, an example of a display for reading the second code information) for reading a payment code (not limiting, an example of the first code information) based on the first user account and the second user account, or a payment store code (not limiting, an example of the second code information) based on the first user account and the second user account.
As an example of an effect of an embodiment obtained by such a configuration, if the first account and the second account are not associated with each other, it is possible to prevent payments from being made based on the first account and the second account.

<Eighteenth Modification (1)>
In the above embodiment, it has been described that the payment history in the linked wallet can be confirmed after the link is approved, but this is not limited to the above.
As with the 17th variant example (3), after an associated wallet is created, it may be possible to check the payment history in the associated wallet on the terminal 20 of an account for which association approval has not been granted, or it may not be possible to do so.

FIG. 18-11 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this case.
The screens displayed on the display unit 24 of the terminal 20A on the left and center of FIG. 18-11 are similar to those on the left and center of FIG. 18-2, respectively.
The screen displayed on the display unit 24 of the terminal 20B on the right side of FIG. 18-11 is the same as that on the right side of FIG. 18-2, but in this example, the chronological order of messages displayed in the group talk room is partially different.

Specifically, messages are displayed in chronological order from oldest to newest: wallet linkage request message from user A.A. → payment completion notification message from linked wallet → product purchase report message from user A.A.
That is, this example display screen is configured so that user B.B can check the payment history using the linked wallet on the group talk room screen displayed on his/her own terminal 20B before approving the link.

In this case, as an example and not a limitation, the process in FIG. 18-6 may be such that step L185 is not executed, and when L110: History check occurs, step L190 is executed. Then, after step L190 is executed, the process returns to L110.

<Eighteenth Modification (2)>
In the above embodiment, after checking the payment history of the linked wallet, advance settlement or retroactive settlement is executed, but the present invention is not limited to this.
As an example and not by way of limitation, when lump-sum advance settlement is selected in step L110 in FIG. 18-6, the advance payments for transactions (payments) up to that point may or may not be settled in a lump sum.
Also, by way of example and not limitation, when lump-sum retroactive settlement is selected in step L110 in FIG. 18-6, retroactive settlement of transactions (payments) up to that point may or may not be performed in a lump sum.
Alternatively, the lump-sum advance settlement and the lump-sum retroactive settlement may be carried out together, or may not be carried out in this manner.

<19th Example>
In the eighteenth embodiment, the linked wallet retroactive settlement process has been described as a process in which the user of the account that has newly approved the link actively executes settlement for payments made before the link was approved, but the present invention is not limited to this.
The nineteenth embodiment is an embodiment in which a user who has been newly approved for cooperation is prompted to make a payment that was made before the cooperation was approved.

The contents described in the 19th embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
FIG. 19A is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20A in this embodiment.
On the left side of Fig. 19-1, the linked wallet information display area WIR1 is displayed rising from the bottom of the screen of the group chat room of the group "Bandmates". In addition, the linked wallet payment history button BT54 is displayed in the display area of the information indicating the linked wallet of the group "Bandmates". When this linked wallet payment history button BT54 is tapped, the screen in the center of Fig. 19-1 is displayed.

On this screen, in the linked wallet payment history display field in linked wallet information display area WIR1, a payment reminder button BT60 containing the word "begging" is displayed to remind another linked member (user B.B in this example) to pay at least a portion of the total payment of "4,500 yen" paid by user A.A for the product purchase. When this payment reminder button BT60 is tapped, the screen on the right side of Figure 19-1 is displayed.

On this screen, information for confirming that a reminder for past payments in the linked wallet is to be sent is displayed in pop-up format in the center of the linked wallet information display area WIR1. Specifically, the text "Ask for past payments?" and information indicating that user B.B is being reminded to pay "2,250 yen" to user A.A are displayed. Also displayed below this are a "Yes" button and a "No" button, and when the "Yes" button is tapped, user A.A will send a reminder to user B.B to make a payment.

FIG. 19B is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 of each of the cooperation members in this case.
The left side of FIG. 19-2 is a group talk room screen displayed on terminal 20A, which displays messages in the following order: a payment completion notification message in the linked wallet, a product purchase report message from user A.A, and a linkage approval message from user B.B.

The center of Figure 19-2 is a group talk room screen displayed on terminal 20B, and by way of example and not limitation, messages are displayed in the following order: product purchase report message from user A.A → linkage approval message from user B.B → payment completion notification message in the linked wallet → payment reminder message from user A.A.

The payment reminder message is a message corresponding to a reminder for payment from user A.A to user B.B.
This payment reminder message displays the words "Payment App" and "Request," as well as information regarding the details of the payment reminder.
In addition, the payment reminder message is provided with a settlement button, and by tapping the settlement button, it is possible to settle the payment reminder from user A.A, that is, to transfer money from user B.B to user A.A.

The right side of FIG. 19-2 is a group talk room screen displayed on terminal 20C, and by way of example and not limitation, messages are displayed in the following order: wallet linking request message from user A.A → product purchase report message from user A.A → linking approval message from user B.B.

In this example, the payment reminder message is not displayed in the group talk room displayed on terminal 20A because user A.A is the person who sent the payment reminder.
It should be noted that the present invention is not limited to this, and a payment reminder message may also be displayed in the group talk room displayed on terminal 20A.

The payment reminder message is not displayed in the group chat room displayed on terminal 20C. This is because user C.C. is in an unapproved link state and is not currently involved in the payment.

<Processing>
FIG. 19-3 is a flowchart showing an example of the flow of processing executed by each device in the linked wallet retroactive settlement processing in this embodiment.
In this figure, from the left, there are shown an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), which is the terminal of an already linked user, processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), which is the terminal of a newly linked user, and processing performed by the control unit 11 of the server 10.

When the linked wallet retroactive settlement candidate information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A determines whether or not to prompt for the transfer of the amount required for retroactive settlement for each transaction in the linked wallet retroactive settlement candidate information, based on, for example but not limited to, user operation, and transmits retroactive settlement request information, which is information about the transaction for which a prompt will be issued, to the server 10 via the communication I/F 22 (A740).

The amount required for retroactive settlement and the amount to be transferred to each account may or may not be calculated by terminal 20A based on the payment history data and advance payment history data. The amount required for retroactive settlement and the amount to be transferred to each account may or may not be determined based on user operations on terminal 20A.

When the retroactive settlement request information is received from terminal 20A via communication I/F 14, the control unit 11 of the server 10 transmits retroactive settlement request information including, by way of example and not limitation, the retroactive settlement amount required for each transaction based on the retroactive settlement request information to the terminal 20 (terminal 20B in this case) that approved the connection after the transaction via communication I/F 14 (S770).

When server 10 is composed of a payment application management server and a messaging application management server, by way of example and not limitation, the payment application management server may receive the retroactive settlement request information, and the messaging application management server that receives the request from the payment application management server may or may not transmit the retroactive settlement request information to terminal 20B. Also, the messaging application management server may receive the retroactive settlement request information without going through the payment application management server, and the messaging application management server may or may not transmit the retroactive settlement request information.

When the retroactive settlement request information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B displays the retroactive settlement request information on the display unit 24 (B770).

The control unit 11 of the server 10 may or may not send the retroactive settlement request information to the terminal 20A so that the terminal 20A can confirm that the retroactive settlement request information has been sent. The control unit 21 of the terminal 20A may or may not display the received retroactive settlement request information on the display unit 24.

When retroactive settlement of a transaction (payment) for which retroactive settlement has been requested based on a user operation on the input/output unit 23 of the terminal 20B is to be performed (B775: YES), the control unit 21 of the terminal 20B executes steps B780 to B790.
When retroactive settlement information is received from terminal 20B via communication I/F 14 (S775: YES), control unit 11 of server 10 executes steps S780 to S790.
When retroactive settlement result information is received from the server 10 via the communication I/F 22 (A750: YES), the control unit 21 of the terminal 20A executes step A760.

<Effects of the 19th embodiment>
In this embodiment, the terminal 20 displays information on a payment history (not limited to, but an example of information related to the second payment) made by at least the second user account based on the link between the first user account and the second user account on the display unit 24. The terminal 20 also shows a configuration in which the terminal 20 receives information (not limited to, but an example of second information related to a payment request for the second payment) prompting payment based on this payment history through the communication I/F 22.
As an example of an effect of an embodiment obtained by such a configuration, based on the association between the first account and the second account, information regarding at least the second payment made by the second account is displayed on the display unit of the terminal, so that the first user can, by way of example and not limitation, check and understand information regarding at least the second payment made by the second account before the first account and the second account were associated.

In this case, the terminal 20 can be configured to control, via the control unit 21, the display of information urging payment (not limited to, but an example of a second display based on the second information) in a talk room (not limited to, but an example of a chat room) including the user of the terminal 20 and the second user of the second user account.
As an example of an effect of an embodiment obtained by such a configuration, the first user can make payment of the second payment after confirming the second information related to the received request for payment of the second payment.

In this case, the information prompting payment can be sent by the server 10 that relays messages sent and received between the first user and the second user in the talk room.
As an example of an effect of an embodiment obtained by such a configuration, the second information can be easily obtained from a server that relays messages sent and received between a first user and a second user in a chat room.

In this case, the information urging payment can be displayed in the first user's talk room but not in the second user's talk room.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to reliably inform the user (first user) to whom the payment is requested that the second settlement be paid that has been requested, while it is possible to eliminate the need for the user (second user) from whom the payment is requested to confirm that the payment has been requested.

In this case, the terminal 20 can be configured to perform, via the control unit 21, a process for transferring part or all of the payment amount (an example of the second amount, not limited to this) from the first user account to the second user account (an example of a process relating to transferring money from the first account to the second account, not limited to this) based on an input by the first user in response to information displayed in the chat room urging payment.
As an example of an effect of an embodiment obtained by such a configuration, a second amount, which is at least a part of the second payment, can be transferred from the first account to the second account by the simple method of the first user inputting information on a second display displayed in the chat room.

<Nineteenth Modification (1)>
In the above embodiment, the retroactive settlement request information is transmitted from the server 10, but this is not limiting. As a non-limiting example, in step A740 of Fig. 19-3, the control unit 21 of the terminal 20A may or may not directly transmit the retroactive settlement request information to the terminal 20B via the communication I/F 22.

Then, the control unit 21 of the terminal 20B may display the received retroactive settlement request information on the display unit 24 and accept the selection of whether or not to perform retroactive settlement (B775), or it may not do so.

<20th Example>
In the above embodiment, the linked wallet is discarded (the linked wallet is invalidated for all linked accounts at once), but the present invention is not limited to this.
The twentieth embodiment relates to a method in which each linked account cancels account linkage.

The contents described in the twentieth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, "canceling account linkage" includes, by way of example and not limitation, any of the following:
(a) Cancellation of link authorization (b) Deletion of linked account

(a) means that the link approval that was set to "done" will be changed back to "not approved." In this case, the data for that linked account will remain in the linked wallet management data without being deleted, but the linked account will no longer be usable.

(b) means that the data for the linked account is deleted from the linked wallet management data. In this case, the linked account will also become unusable.

By way of example and not limitation, the above-mentioned account linking may be cancelled when a linked account (or a user of the linked account) wishes to withdraw from a linked wallet.

Note that in the above (a) cancellation of link approval, the linked account data remains in the linked wallet management data without being deleted, so strictly speaking, it could be considered not to be withdrawal from the linked wallet. However, since "withdrawal from the linked wallet" may be intuitively easier for users to understand, this is how it will be expressed.

In addition, it may be desirable for a user to be able to freely cancel account linkage at their own will. Thus, by way of example and not limitation, cancellation of account linkage may not require approval from other linked accounts.
Alternatively, approval of other linked accounts may be required to cancel account linkage.

<Display screen>
FIG. 20A is a diagram showing an example of transition of a screen displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of Fig. 20-1 shows an example of a screen displayed on the display unit 24 of the terminal 20B. This screen is a group chat room screen for the group "Bandmates," and a linked wallet information display area WIR1 is displayed protruding from the bottom of the screen.

At the bottom of the linked wallet information display area WIR1, there are displayed a linked wallet withdrawal button BT70 for withdrawing from the linked wallet, and the linked wallet discard button BT30 described above.
It should be noted that displaying the linked wallet discard button BT30 is not essential, and it may be possible to choose not to display it.

When the linked wallet withdrawal button BT70 is tapped, account linkage cancellation confirmation information is sent to terminal 20A via server 10. As a result, the screen shown in the center of Figure 20-1 is displayed on the display unit 24 of terminal 20A.

This screen is the group chat room screen for the group "Bandmates," and displays a linked wallet withdrawal request message from user A.A, requesting to withdraw from the linked wallet. The linked wallet withdrawal request message displays the details of the request to withdraw from the linked wallet, and below this are a reject button to reject the withdrawal, and an approve button to approve (permit) the withdrawal.

When the authorization button is tapped, account linkage cancellation authorization information is sent from terminal 20A to server 10. Then, the server 10 performs an account linkage cancellation process, and the account linkage of user B.B is cancelled. As a result, the screen on the right side of FIG. 20-1 is displayed on the display unit 24 of terminal 20B.

This screen is the group chat room screen for the group "Bandmates," and displays messages in the following order: a message indicating that user B.B. wishes to withdraw from the linked wallet, a message authorizing user A.A. to withdraw from the linked wallet, and a message indicating that user B.B. has withdrawn from the linked wallet.

<Processing>
FIG. 20B is a flowchart showing an example of the flow of the processes executed by each device in this case.
This figure shows an example of processing executed by a system made up of a terminal 20 and a server 10.
The server 10 may or may not be configured to be divided into a payment application management server that manages the payment service and a messaging application management server that manages the messaging service.

As a non-limiting example, when a user operation on the terminal 20 is performed to select to cancel the account linkage of user B.B (L110: Withdraw), a linked wallet withdrawal process is executed (L230).

Alternatively, and by way of example and not limitation, when a user leaves a messaging service group for which an associated wallet has been created, an associated wallet withdrawal process may or may not be executed.

In addition, when the total limit amount or number of consecutive payments set for the linked account becomes "0," the linked wallet withdrawal process may or may not be executed.

FIG. 20C is a flowchart showing an example of the process flow executed by each device in the linked wallet withdrawal process.
This figure shows, from the left, an example of processing performed by the control unit 21 of terminal 20A (terminal 20 of user A.A), which is the terminal of a user who has been approved for account linkage, processing performed by the control unit 21 of terminal 20B (terminal 20 of user B.B), which is the terminal of a user who has chosen to cancel account linkage, and processing performed by the control unit 11 of server 10.

The control unit 21 of the terminal 20B sends account linkage cancellation request information requesting cancellation of the account linkage to the server 10 via the communication I/F 22 (B810).

When the communication I/F 14 receives the account linkage cancellation confirmation information from terminal 20B, the control unit 11 of the server 10 transmits the account linkage cancellation confirmation information, which confirms whether or not to approve the cancellation of the account linkage, to terminal 20A via the communication I/F 14 (S810).

The account linkage cancellation confirmation information may be sent to the terminal 20 that generated the linked wallet, or may be sent to all terminals 20 of the linked accounts that have been approved for linkage with the linked wallet. Also, if a representative is set for the linked wallet or group, the information may be sent to that representative, but this is not essential.

When the account linkage cancellation confirmation information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the account linkage cancellation confirmation information to be displayed on the display unit 24 (A810).
If it is selected to authorize the cancellation of account linkage based on user operation on the input/output unit 23 of terminal 20A (A810: YES), the control unit 21 of terminal 20A sends account linkage cancellation authorization information to the server 10 via the communication I/F 22.
If it is selected not to approve (A810: NO), the control unit 21 of the terminal 20A ends the process.

When account linkage cancellation authorization information is received from the terminal 20 that sent the account linkage cancellation confirmation information via the communication I/F 14 (S820: YES), the control unit 11 of the server 10 executes the account linkage cancellation process based on the account linkage cancellation request information (S830).

In the account linkage cancellation process, the control unit 11 of the server 10 changes the linkage approval in the linkage status management data in the user account of user B.B. from "Completed" to "Not yet," as a non-limiting example. This corresponds to the above-mentioned (a) cancellation of linkage approval.

Instead of doing this, the user account of user B.B. itself may be deleted from the linkage status management data. This corresponds to the above-mentioned (b) Deletion of a linked account.

Then, the control unit 11 of the server 10 transmits account linkage cancellation information indicating that the account linkage of user B.B has been cancelled to the terminals 20 in the group via the communication I/F 22 (S840).
In addition, the account linkage cancellation information may or may not be sent only to the terminal 20 that requested (applied for) the account linkage cancellation and the terminal 20 that sent the account linkage cancellation confirmation information.
In addition, the account linkage cancellation information may or may not be sent to the terminal 20 that requested (applied for) the account linkage cancellation and the terminal 20 that generated the linked wallet.
In addition, the terminal 20 of the representative of the linked wallet or the representative of the group may also be included in the transmission.

When the account linkage cancellation information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A displays the received account linkage cancellation information on the display unit 24 (A830) and ends the process.

When account linkage cancellation information is received from the server 10 via the communication I/F 22 (B820: YES), the control unit 21 of the terminal 20B causes the display unit 24 to display the received account linkage cancellation information (B830). Then, the control unit 21 of the terminal 20B notifies the user that the linked wallet has become unusable, for example by causing the display unit 24 to display a display indicating that payments using the linked wallet with the user account of user B.B cannot be made (B840).
If the account linkage cancellation information is not received (B820: NO), the control unit 21 of the terminal 20B ends the process.

The account unlinking process may be performed in the following cases:
・When permission to unlink accounts is obtained from all members in the group ・When permission to unlink accounts is obtained from all members who have been approved for linking ・When permission to unlink accounts is obtained from more than a set number of members (for example, not limited to, a majority of the members who have been approved for linking) ・When permission to unlink accounts is obtained from the member who created the linked wallet ・When permission to unlink accounts is obtained from the representative of the linked wallet or the representative of the group ・When account unlinking is performed unconditionally without permission from other members to unlink accounts

After the linked wallet withdrawal process is executed, the control unit 11 of the server 10 judges whether the account linkage of all linked members of the linked wallet has been released (L240). If the account linkage of all members has been released (L240: YES), the linked wallet destruction process is executed (L220).
On the other hand, if there are any members whose account linkage has not been released (L240: NO), the process returns to step L110.

Even if the account linkage of all linked members of the linked wallet is terminated (L240: YES), the linked wallet destruction process may not be executed and payment history, advance payment history, etc. in the linked wallet may be retained, or it may not be necessary to do so.
In this case, if a member in the group approves the link, it will be possible to make payments using the linked wallet again without having to execute the linked wallet generation process.

FIG. 20D is an example of a timing chart for explaining the timing at which each process is executed in this embodiment.
Here, we will explain the timing at which each terminal is instructed to execute the account addition link process, linked wallet payment process, linked wallet retroactive settlement process, and linked wallet withdrawal process described in the above flow. To simplify the explanation, we will consider a case where no advance payment is required in the linked wallet payment process.

The terminal that executes the creation of the linked wallet is assumed to be terminal 20A. The terminals of the other linked members of the linked wallet are assumed to be terminal 20B and terminal 20C.
In this timing chart, the horizontal axis is the time axis, and the timing when each terminal 20 performs the account addition linkage process is indicated by a white hexagon, the timing when the linked wallet payment process is indicated by a white circle, the timing when the linked wallet retroactive settlement process is indicated by a white square, and the timing when the linked wallet withdrawal process is indicated by a white triangle.

After the linked wallet generation process, the account addition linking process is executed on terminal 20B. Then, payment 1 is executed on terminal 20A. User A.A and user B.B participate in payment 1.

Next, the account addition linkage process is executed in terminal 20C. Then, the linked wallet retroactive settlement process for payment 1 is executed in terminal 20C.
Thereafter, the linked wallet withdrawal process is executed in terminal 20B.
Then, payment 2 is executed at terminal 20C. Payment 3 involves users A.A and C.C.

Thereafter, the account addition linkage process is executed again in terminal 20B. Then, in terminal 20B, the linked wallet retroactive settlement process for payment 2 is executed.
Payment 3 is executed at terminal 20B. Payment 3 involves users A.A, B.B, and C.C.

After payment 3, an associated wallet withdrawal process is executed in terminal 20C. Also, an associated wallet withdrawal process is executed in terminal 20A.
Finally, in terminal 20B, the associated wallet withdrawal process is executed, and then the associated wallet destruction process is executed.

<Effects of the 20th embodiment>
This embodiment illustrates a configuration in which the terminal 20 uses the control unit 21 to perform processing for canceling the account linkage of the first user account, that is, processing for canceling the linkage between the first user account and the second user account (not limited to this, but an example of processing related to canceling the association between the first account and the second account).
As an example of an effect of the embodiment obtained by such a configuration, it is possible to cancel the association between a first account and a second account that was once associated with each other.

In this case, the process for canceling the account association of the first user account may include a process of sending account association cancellation request information (not limited to, but an example of information regarding a request to cancel the association) to the second user account.
As an example of an effect of the embodiment obtained by such a configuration, it is possible to confirm that the association with the second account has been released.

In this case, the account linkage of the first user account can be released based on the permission of the second user of the second user account.
As an example of an effect of the embodiment obtained by such a configuration, it is possible to prevent the association between the first account and the second account from being released without the permission of the second user of the second account, which means that it is possible to prevent the first account and the second account from being released against the will of the second user.

In this case, account linking of the first user account can be performed based on the first user leaving a talk room including the first user and a second user of the second account.
As an example of an effect of an embodiment obtained by such a configuration, when a first user leaves a chat room that includes the first user and a second user of a second account, the association between the first account and the second account can also be released.

<20th Modification (1)>
In the above embodiment, when the linked wallet withdrawal process is executed, the account linkage is released, but this is not limited to the above.
By way of example and not limitation, when a linked wallet withdrawal process is performed, a linked wallet settlement process or a linked wallet retroactive settlement process, or both, may be performed, after which the account linkage may or may not be released.

FIG. 20-5 is a diagram showing an example of a transition of a screen displayed on the display unit 24 of the terminal 20B in this modified example.
The left side of Fig. 20-5 displays a screen similar to that of the left side of Fig. 20-1. When the linked wallet withdrawal button BT70 is tapped, the right side of Fig. 20-5 is displayed, by way of example and not limitation.

In this screen, information for confirming whether or not to settle the linked wallet is displayed in the center of the linked wallet information display area WIR1. Specifically, detailed information on the unsettled purchase history is displayed along with the text "There is an unsettled purchase history." In this example, it is shown that for a payment of "4,500 yen" to "XX Musical Instruments," a transfer of "2,250 yen" from user B.B to user A.A has not yet been made.

Below that, the words "Do you want to settle?" are displayed along with a "Yes" button and a "No" button. When the "Yes" button is tapped, the settlement is carried out. In other words, in this example, "2,250 yen" is transferred from user B.B to user A.A.

In this case, by way of example and not limitation, after executing step B810 in FIG. 20-3, the linked wallet settlement process or the linked wallet retroactive settlement process, or both, may be executed, and the process of FIG. 20-3 may then be continued again.

In addition, after executing the linked wallet settlement process or the linked wallet retroactive settlement process, or both, if there are outstanding advance settlements or retroactive settlements remaining in the linked account requesting to unlink the linked account, the control unit 11 of the server 10 may choose not to execute step S810 in Figure 20-3.
In this case, if the linked account for which you are trying to cancel the account link has any outstanding advance payments or retroactive payments, the account link will not be canceled.

In addition, after executing the linked wallet settlement process or the linked wallet retroactive settlement process, or both, if there are no outstanding advance settlements or retroactive settlements remaining in the linked account requesting to unlink the linked account, the control unit 11 of the server 10 may, or may not, execute the account linkage cancellation process regardless of whether or not account linkage cancellation authorization information is received.
In other words, if the linked account for which the account linkage is to be cancelled has no loans or borrowings within the linked wallet, it is possible to cancel the account linkage without obtaining approval from other members.

In this modified example, the terminal 20 displays information about at least a payment made by the second user account (not limited to this, an example of a third payment) based on the account linkage of the first account on the display unit 24. Then, the terminal 20 shows a configuration in which the terminal 20 displays information about the payment of this payment (not limited to this, an example of a third display) on the display unit 24 based on the release of the account linkage of the first account.
As an example of an effect of an embodiment obtained by such a configuration, based on the association between the first account and the second account, the first user can view and confirm information related to at least the third payment made by the second account. Furthermore, when the first account and the second account are released, the first user can view and confirm information related to the payment of the third payment.

Reference Signs List 1 Communication system 10 Server 20 Terminal 30 Network 40 Store POS system 50 Store code reader device

Claims (27)

A server that communicates with a terminal and processes payments,
A control unit that performs processing related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
a communication unit configured to transmit, to the terminal, first information related to a transfer to the second account based on the first payment;
the control unit performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal ;
the first representation is included in a chat room associated with the first account and the second account;
The control unit performs a process related to a second payment based on the first account and the second account;
The communication unit transmits second information regarding the transfer of money to the second account based on the second payment and the first information to the chat room . 2. The server of claim 1 ,
The control unit performs processing related to transferring an amount based on the first information and an amount based on the second information from the first account to the second account based on input by the first user to the first display and the second display based on the second information included in the chat room. The server according to claim 1 or 2 ,
The control unit performs processing to transfer an amount based on the first information and an amount based on the second information from the first account to the second account based on disassociating the first account with the second account in the chat room. The server according to any one of claims 1 to 3 ,
The first settlement comprises at least a payment of a deficit on the first account by the second account. 5. The server according to claim 4 ,
The first settlement is not paid by the first account. A server that communicates with a terminal and processes payments,
A control unit that performs processing related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
a communication unit configured to transmit, to the terminal, first information related to a transfer to the second account based on the first payment;
the control unit performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement includes a payment by the first account and a payment of any shortfall in the first account by at least the second account. A server that communicates with a terminal and processes payments,
A control unit that performs processing related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
a communication unit configured to transmit, to the terminal, first information related to a transfer to the second account based on the first payment;
the control unit performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and the shortfall in the first account is paid by the second account and the third account. A server that communicates with a terminal and processes payments,
A control unit that performs processing related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
a communication unit configured to transmit, to the terminal, first information related to a transfer to the second account based on the first payment;
the control unit performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and any shortfall in the first account is paid only by the second account. The server according to claim 7 or claim 8 ,
The second account that pays the deficit of the first account is determined based on the balance of the second account. The server according to claim 7 or claim 8 ,
The second account to pay the deficit of the first account is selected based on input by the first user to the terminal. 11. The server of claim 10 ,
The second account to pay the deficit of the first account is determined based on the permission of a second user of the second account after the second account is selected based on an input to the terminal by the first user. A server according to any one of claims 1 to 11 ,
The first information includes information based on an amount paid in the first payment by the second account. A server according to any one of claims 1 to 12 ,
The second account is an account of a second user. A server according to any one of claims 1 to 13 ,
The second account is a common account that multiple users can use for payment,
The control unit performs processing related to transferring an amount based on the first information from the first account to the common account based on an input by the first user on the first display. 15. The server of claim 14 ,
the amount based on the first information is a first amount;
The common account is associated with each of the accounts of the plurality of users, and each of the accounts receives a second amount, which is at least a portion of the first amount, from the common account. A program executed by a server that communicates with a terminal and processes payments,
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
The server executes, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal ;
the first representation is included in a chat room associated with the first account and the second account;
performing a process related to a second payment based on the first account and the second account by the control unit;
The server executes, based on the second payment, transmitting second information regarding transferring money to the second account and the first information to the chat room via the communication unit . A program executed by a server that communicates with a terminal and processes payments,
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
The server executes, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement includes a payment by the first account and a payment of any shortfall in the first account by at least the second account. A program executed by a server that communicates with a terminal and processes payments,
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
The server executes, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and the shortfall in the first account is paid by the second account and the third account. A program executed by a server that communicates with a terminal and processes payments,
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
The server executes, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and any shortfall in the first account is paid only by the second account. An information processing method for a server that communicates with a terminal and processes payment, comprising:
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
and performing, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal ;
the first view is included in a chat room associated with the first account and the second account;
performing a process related to a second payment based on the first account and the second account by the control unit;
The method includes transmitting, by the communication unit, second information regarding transferring money to the second account based on the second payment and the first information to the chat room . An information processing method for a server that communicates with a terminal and processes payment, comprising:
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
and performing, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement includes a payment by the first account and a payment of any shortfall in the first account by at least the second account. An information processing method for a server that communicates with a terminal and processes payment, comprising:
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
and performing, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and the shortfall in the first account is paid by the second account and the third account. An information processing method for a server that communicates with a terminal and processes payment, comprising:
performing a process related to a first payment by a control unit of the server based on a first account of a first user of the terminal and a second account associated with the first account;
transmitting first information regarding a transfer to the second account based on the first payment to the terminal by a communication unit of the server;
and performing, by the control unit, a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user to a first display based on the first information displayed on the terminal;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and any shortfall in the first account is paid only by the second account. A system including a terminal and a server that communicates with the terminal and performs processing related to payment,
A control unit of the server that performs a process related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
A communication unit of the server that transmits first information to the terminal regarding a transfer to the second account based on the first payment;
A communication unit of the terminal that receives the first information;
a display unit of the terminal that displays a first display based on the first information,
a control unit of the server performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user on the first display;
the first representation is included in a chat room associated with the first account and the second account;
The control unit of the server performs a process related to a second payment based on the first account and the second account;
The communication unit of the server transmits to the chat room second information regarding transferring money to the second account based on the second payment, and the first information . A system including a terminal and a server that communicates with the terminal and performs processing related to payment,
A control unit of the server that performs a process related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
A communication unit of the server that transmits first information to the terminal regarding a transfer to the second account based on the first payment;
A communication unit of the terminal that receives the first information;
a display unit of the terminal that displays a first display based on the first information,
a control unit of the server performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user on the first display;
The first settlement includes a payment by the first account and a payment of any shortfall in the first account by at least the second account. A system including a terminal and a server that communicates with the terminal and performs processing related to payment,
A control unit of the server that performs a process related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
A communication unit of the server that transmits first information to the terminal regarding a transfer to the second account based on the first payment;
A communication unit of the terminal that receives the first information;
a display unit of the terminal that displays a first display based on the first information,
a control unit of the server performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user on the first display;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and the shortfall in the first account is paid by the second account and the third account. A system including a terminal and a server that communicates with the terminal and performs processing related to payment,
A control unit of the server that performs a process related to a first payment based on a first account of a first user of the terminal and a second account associated with the first account;
A communication unit of the server that transmits first information to the terminal regarding a transfer to the second account based on the first payment;
A communication unit of the terminal that receives the first information;
a display unit of the terminal that displays a first display based on the first information,
a control unit of the server performs a process for transferring an amount based on the first information from the first account to the second account based on an input by the first user on the first display;
The first settlement is made by the first account, the second account, and a third account to which the first account and the second account are associated, and any shortfall in the first account is paid only by the second account.

Images