JP7146866B2 - program, information processing method, terminal - Google Patents

Description

The present disclosure relates to programs, information processing methods, terminals, servers, and the like.

2. Description of the Related Art In recent years, a service that realizes settlement of a terminal or a user of a terminal by an application that can be executed on a terminal such as a smart phone is spreading. For example, Japanese Laid-Open Patent Publication No. 2002-200000 discloses a technique for settling the purchase price of a product.

JP-A-2002-176671

According to a first aspect of the present invention, a program for causing a terminal to execute, 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: performing processing related to the first payment by the control unit of the terminal; receiving, by the communication unit of the terminal, first information regarding remittance to the second account based on the first payment; Displaying the first display on the display unit of the terminal, and performing, by the control unit, processing related to transferring money from the first account to the second account based on the first user's input to the first display are performed by the terminal. be done.
According to a second aspect of the present invention, a terminal information processing method is based on a first account of a first user of the terminal and a second account associated with the first account, a first performing processing related to payment by a control unit of the terminal; receiving, by a communication unit of the terminal, first information regarding remittance to a second account based on the first payment; and first display based on the first information is displayed on the display of the terminal, and the controller performs processing related to transferring money from the first account to the second account based on the first user's input to the first display .
According to a third aspect of the present invention, the terminal causes the terminal of the first user to process the first payment based on the first account of the first user of the terminal and the second account associated with the first account. a communication unit for receiving first information about transferring money to a second account based on the first payment; and a display unit for displaying a first display based on the first information, wherein the control unit , performs processing related to transferring money from the first account to the second account based on the input by the first user to the first display .
According to a fourth aspect of the invention, a terminal comprises a processor for reading a program from a memory and executing a process based on the program, the processor being associated with a first account of a first user of the terminal and the first account. The communication unit of the terminal receives first information about performing processing related to the first payment by the terminal of the first user based on the second account and transferring money to the second account based on the first payment. , displaying a first display based on the first information on the display unit of the terminal, and performing processing related to transferring money from the first account to the second account based on the first user's input to the first display. do things .
According to a fifth aspect of the present invention, a server that performs processing related to payment and communicates with a terminal performs 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 control unit that performs processing related to payment; and a communication unit that transmits first information regarding remittance to the second account based on the first payment to the terminal, wherein the control unit controls the first payment displayed on the terminal. A process relating to transferring money from the first account to the second account is performed based on the input by the first user to the first information-based display.

The figure which shows an example of the system configuration|structure of the communication system which concerns on 1st Example. 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; The figure which shows an example of the account registration data based on 1st Example. FIG. 4 is a diagram showing a data configuration example of an account management database according to the first embodiment; FIG. 4 is a diagram showing a data configuration example of a first linked wallet management database, which is an example of a linked wallet management database according 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; The figure which shows an example of the information memorize|stored in the memory|storage part of the terminal which concerns on 1st Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 1st Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 1st Example. 4 is a flowchart showing an example of the flow of processing executed by each device according to the first embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 1st modification. 10 is a flowchart showing an example of the flow of processing executed by each device according to the first modified example; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 2nd Example. 9 is a flowchart showing an example of the flow of processing executed by each device according to the second embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 3rd Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 3rd Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 3rd Example. FIG. 11 is a flow chart showing an example of the flow of processing executed by each device according to the third embodiment; FIG. FIG. 11 is a flow chart showing an example of the flow of processing executed by each device according to the third embodiment; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 3rd modification. FIG. 11 is a flowchart showing an example of the flow of processing executed by each device according to the third modified example; FIG. FIG. 11 is a flowchart showing an example of the flow of processing executed by each device according to the third modified example; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 3rd modification. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 3rd modification. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 3rd modification. FIG. 11 is a flowchart showing an example of the flow of processing executed by each device according to the third modified example; FIG. The figure which shows an example of the information memorize|stored in the memory|storage part of the server based on 4th Example. The figure which shows the data structural example of the group management database based on 4th Example. FIG. 12 is a diagram showing an example data configuration of a second linked wallet management database, which is an example of a linked wallet management database according to the fourth embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 4th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 4th modification. FIG. 14 is a flowchart showing an example of the flow of processing executed by each device according to the fourth modification; FIG. FIG. 14 is a flowchart showing an example of the flow of processing executed by each device according to the fourth modification; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 5th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 5th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 5th Example. The figure which shows an example of the system configuration|structure of the communication system which concerns on 6th Example. The figure which shows an example of the functional structure of the store POS system based on 6th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 6th Example. FIG. 14 is a flow chart showing an example of the flow of processing executed by each device according to the sixth embodiment; FIG. FIG. 21 is a diagram showing a data configuration example of a third linked wallet management database, which is an example of a linked wallet management database according to the seventh embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 7th Example. FIG. 11 is a flow chart showing an example of the flow of processing executed by each device according to the seventh embodiment; FIG. FIG. 11 is a flow chart showing an example of the flow of processing executed by each device according to the seventh embodiment; FIG. 15 is a flow chart showing an example of the flow of cooperative wallet settlement processing according to the seventh embodiment. FIG. 14 is a diagram showing an example of information stored in a storage unit of a server according to the eighth embodiment; FIG. 20 is a diagram showing a data configuration example of a common wallet management database according to the eighth embodiment; FIG. 20 is a diagram showing a data configuration example of a fourth linked wallet management database, which is an example of a linked wallet management database according to the eighth embodiment; FIG. 22 is a diagram showing an example of a table regarding burden ratios of cooperation members according to the ninth embodiment; FIG. 20 is a diagram showing a data configuration example of a fifth linked wallet management database, which is an example of a linked wallet management database according to the tenth embodiment; The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 10th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 10th Example. FIG. 12 is a flow chart showing an example of the flow of processing executed by each device according to the tenth embodiment; FIG. FIG. 12 is a flow chart showing an example of the flow of processing executed by each device according to the tenth embodiment; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on 11th Example. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on an 11th modification. FIG. 22 is a diagram showing a data configuration example of a sixth linked wallet management database, which is an example of a linked wallet management database according to the twelfth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the twelfth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the twelfth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the twelfth embodiment; FIG. FIG. 21 is a diagram showing a data configuration example of a seventh linked wallet management database, which is an example of a linked wallet management database according to the thirteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the thirteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the thirteenth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the thirteenth embodiment; FIG. FIG. 21 is a diagram showing a data configuration example of an eighth linked wallet management database, which is an example of a linked wallet management database according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fourteenth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fourteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fourteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fourteenth embodiment; FIG. FIG. 21 is a flowchart showing an example of the flow of processing executed by each device according to the fourteenth modification; FIG. FIG. 21 is a flowchart showing an example of the flow of processing executed by each device according to the fourteenth modification; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on a 14th modification. FIG. 21 is a flowchart showing an example of the flow of processing executed by each device according to the fourteenth modification; FIG. FIG. 21 is a diagram showing a data configuration example of a ninth linked wallet management database, which is an example of a linked wallet management database according to the fifteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fifteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the fifteenth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fifteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fifteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fifteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the fifteenth modification; FIG. FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the sixteenth embodiment; FIG. 22 is a diagram showing an example of an account management database according to the seventeenth embodiment; FIG. FIG. 21 is a diagram showing an example of a cooperative wallet management database according to the seventeenth embodiment; FIG. FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the seventeenth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the seventeenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the seventeenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the seventeenth modification; FIG. FIG. 22 is a diagram showing an example of a screen displayed on a display unit of a terminal according to Modification 17; FIG. 20 is a diagram showing an example of a cooperative wallet management database according to the eighteenth embodiment; FIG. FIG. 20 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the 18th embodiment; FIG. 20 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the 18th embodiment; FIG. 20 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the 18th embodiment; FIG. 20 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the 18th embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the eighteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the eighteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the eighteenth embodiment; FIG. FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the eighteenth embodiment; FIG. FIG. 21 is a diagram showing an example of a timing chart according to an eighteenth embodiment; FIG. The figure which shows an example of the screen displayed on the display part of the terminal which concerns on an 18th modification. FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the nineteenth embodiment; FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the nineteenth embodiment; FIG. 21 is a flow chart showing an example of the flow of processing executed by each device according to the nineteenth embodiment; FIG. FIG. 20 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the twentieth embodiment; FIG. 12 is a flow chart showing an example of the flow of processing executed by each device according to the twentieth embodiment; FIG. FIG. 12 is a flow chart showing an example of the flow of processing executed by each device according to the twentieth embodiment; FIG. FIG. 21 is a diagram showing an example of a timing chart according to a twentieth embodiment; FIG. FIG. 22 is a diagram showing an example of a screen displayed on the display unit of the terminal according to the twentieth modification;

<Compliance with legal matters>
Note that the disclosure provided herein is subject to compliance with the legal requirements of the implementing country required for the practice of this disclosure, such as confidentiality of communications.

An embodiment for implementing a program or the like according to the present disclosure will be described with reference to the drawings.

<Overview>
In recent years, as applications (application software) related to network services, there are applications such as applications for making payments and settlements using electronic money (payment applications/settlement applications) and applications for sending/receiving electronic money (remittance applications). In addition, applications that integrate some or all of these applications' functions are becoming popular, and terminal users can use these applications to receive various services related to electronic money. ing.

"Electronic money" means electronic money that is distinguished from physical money and that is owned by a terminal managed by the various applications described above or by a user of the terminal.

Note that electronic money may be expressed as “electronic money” or “digital currency (digital currency)”, or may not be expressed as such.
Also, as "electronic money (electronic money)" or "digital currency (digital currency)", a legal currency may be used, or a virtual currency may be used.
Also, "electronic currency (electronic money)" and "digital currency (digital currency)" may include cryptocurrency (cryptographic assets).
Virtual currency may also include physical money such as coupons.

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

Further, in this specification, "payment" means electronic payment (electronic payment). An example of this is electronic payment using electronic money.

In this specification, "code information" includes a code image, information stored in the code image by encoding or the like (stored information), or information to be stored (stored information). . The stored information and information to be stored include, by way of example and not limitation, tokens, which will be described in detail below.

In addition, in this specification, the code payment, which is a payment method/settlement method using a code (code information), is not limited to but an example,
(1) User presentation type (2) Store presentation type Two types are exemplified.

The user presentation type is, as an example and not a limitation, a user (terminal user) presenting a payment code displayed on the display unit of the terminal to a store clerk (as an example, not a limitation, a member store), and the store This is a method of settlement by having the code read by the code reader of the code reader device.
The store presentation type is, as a non-limiting example, a payment store code presented or posted at a store (as an example, not a limitation, a member store) when a user uses a terminal camera or code reader (including a code reader of a payment application). ) to read and settle.

In the following description, the code presented by the user and displayed on the display unit of the terminal is referred to as "payment code", but may be referred to as "user presented code" or the like.
In the following description, the code read by the terminal in the store presentation type is referred to as the "payment store code", but it may be referred to as the "store presentation type code" or the like.

For purposes of illustration and not limitation, store presentations are primarily discussed herein.
However, the present invention can be similarly applied to the user presentation type, and an embodiment of the user presentation type will be described later.

Also herein, as account-based payments, by way of example and not limitation:
(A) Account linked settlement (B) Common account settlement Two types are exemplified.

An "account" is, by way of example and not limitation, an account of an application (payment application, settlement application, messaging application, etc.) used by a user to make payments, settlements, etc., using electronic money.

(A) Account-linked settlement Account-linked settlement is a method of making settlements by linking multiple accounts. Linking accounts means linking multiple accounts so that they can be used for settlement.
This association may be any one in which multiple accounts are associated in terms of data (data managed by a terminal or server) so that account-linked settlement can be performed.

Linking accounts is called "account linking", and settlement using account linking is called "account linking settlement".
In this case, a plurality of accounts of one user may be linked, or accounts of a plurality of users may be linked. In other words, other people's accounts are not necessarily required for linking, and it is possible to link multiple accounts of one's own as an example and not as a limitation.

In order to realize account-linked settlement, as an example, not a limitation, after associating multiple accounts, settlement is performed by splitting the bill equally from each linked account (as an example, not a limitation). Execute the setting process (account linkage process).
Account-linked settlement can also be understood as settlement using a different account (your own account or someone else's account) in addition to your own account.
Account linkage may also be expressed as wallet linkage. Also, account-linked settlement may be expressed as wallet-linked settlement.

In the following, although it is only an example, an embodiment will be described on the assumption that a plurality of users, such as friends or associates, all make payments for shopping or the like.

Account linking can be performed, by way of example and not limitation, either (A-1) before making a payment or (A-2) when making a payment.
(A-1) Before making a payment, as an example and not as a limitation, it can be applied when post-payment is troublesome.
(A-2) When making a payment, as an example, not as a limitation, if the balance of the account set as the account for settlement at the time of payment (your account as an example, not as a limitation) is insufficient. can be applied to In this case, as an example and not a limitation, settlement can be performed by linking accounts with other users' accounts.

(B) Common Account Payment Common account payment is a method of making payments based on an account that can be used commonly by a plurality of users (hereinafter referred to as "common account"). This settlement is called "common account settlement". Common account settlement is realized by using a common wallet. A "common wallet" is a form of electronic money account set up by a plurality of users, and constitutes one virtual wallet.
A common account settlement can also be regarded as a settlement by a user using an account common to a plurality of users (one common account).
The common account payment may be expressed as a common wallet payment.

Common account settlement is, for example and not limitation, settlement from one account that is assumed to be shared by a plurality of users.

As a first form, the common account can be an account linked to each user (member) using the common wallet.
As a second form, the shared account can be an account linked to a specific user among users who use the shared wallet. A particular user can be, by way of example and not limitation, a user who is a representative or master of a common wallet (hereinafter collectively referred to as a "common account master user"). A common account master user can be, by way of example and not limitation, such as a user who created a common account.

Regardless of whether the first form or the second form is applied, as an example and not as a limitation, each common account user can freely use the common wallet. . As a non-limiting example, it is possible to check information such as the balance of the common wallet, and to freely deposit money into the common wallet/withdraw money from the common wallet.

When applying the second form, as an example and not as a limitation, it is also possible to restrict the use of the common wallet by users other than the common account master user.
Specifically, the use of some or all of the functions of the common wallet is prohibited, or the approval of the common account master user is required when using some or all of the functions of the common wallet. It may or may not be required.

In common account settlement, since a common account is used by multiple users, in the event that one user pays for another user's payment on behalf of another user, subsequent settlement (settlement) processing is required. may become. In other words, at some point after the payment is completed, it may be necessary to adjust the amount of money for each user, such as remittance processing/receipt processing.

On the other hand, in account linked settlement, after obtaining the permission of the user of the linked account or obtaining permission on the spot, the amount will be consumed from each account, so that the settlement will be made after the fact. processing is basically unnecessary.
However, there are cases where account-linked settlement is also performed after the fact, and this will be described later in Examples.

Based on the above, in this specification, as an example and not as a limitation, an embodiment in which (A) "account-linked settlement" is applied will be mainly described.

Note that "collaboration" includes the meaning of doing things together for one purpose. For this reason, in the sense that a plurality of users make payments together, as an example and not as a limitation, both account-linked payments and common account payments can be considered to have the same purpose.

Further, in the following description, it is assumed that various processes according to the present invention are executed by applications (payment application and messaging application) installed in the terminal.

In addition, having a chat service function (as a non-limiting example, a messaging service) as a function of a payment application, or having a payment service function as a function of a chat application (as a non-limiting example, a messaging application) You can also make

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

The content includes messages including simple texts and pictograms, as well as non-limiting examples of image information (including information such as still images and moving images), operation information (including buttons, icons, etc.). , communication information/link information (including URI, URL, etc.), and various other information that can be transmitted and received between terminals.

Note that the talk room can include, by way of example and not limitation, a one-to-one user talk room as well as a group talk room including a plurality of users (group talk room). The talk room in this case means a UI or GUI that allows users included in the group to view content transmitted and received between terminals of the group including a plurality of users.

The messaging service may or may not include an instant messaging service (IMS) that enables transmission and reception of contents such as simple messages between terminals.

There is also a way of thinking that messaging service: MS (including IMS) is regarded as one form (one form) of social networking service: SNS.
Therefore, the messaging service: MS and the social networking service: SNS may or may not be distinguished.

Further, in the following description, the input to the terminal is mainly an operation input by the user of the terminal (input by tapping (tap operation) as an example, not a limitation), but the input is not limited to this.
Sound input (including voice input) may or may not be input to the terminal instead of or in addition to the operation input.

In this specification, "processing related to payment" performed by the terminal means processing directly or indirectly related to payment, such as the above (A) account linked payment and (B) shared account payment as examples without limitation. means directly or indirectly related processing;
Specifically, as a non-limiting example, the process of acquiring code information for payment from the server (including the process of requesting the server to generate code information and the process of receiving the generated code information from the server) ), processing to display the acquired code information, processing to request the server to make a payment, processing to obtain payment results (including payment completion notification, etc.) from the server, etc. It includes a certain process, more specifically, all processes that are executed by the terminal as related processes for settlement.

In addition, in this specification, "processing related to settlement" performed by the server also means processing directly or indirectly related to settlement. means any process related directly or indirectly to
Specifically, as a non-limiting example, processing to generate code information for payment, processing to send the generated code information to the terminal, payment processing (processing to make payment), payment result (payment completion notification, etc.) ) to the terminal, more specifically, it includes all processing executed by the server as processing related to payment.

It should be noted that the same applies to other terms described as "related". That is, "related to" is a concept that includes directly or indirectly related things.

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

(1) is a system including, by way of example and not limitation, at least one terminal and at least one server. A typical example of this is a server-client system.
In this case, the controller of the system can be at least one of the controller of the terminal and the controller of the server. That is, as an example and not a limitation, any one of (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 may be used in the system. can be a control unit.

Further, the control and processing performed by the control unit of the system (hereinafter collectively referred to as "control, etc.") may be performed only by (1A) the control unit of the terminal, or (1B) the control of the server (1C) It may be performed by both the control unit of the terminal and the control unit of the server.
In addition, in (1C), as an example and not a limitation, part of the control performed by the control unit of the system is performed by the control unit of the terminal, and the rest of the control is performed by the control unit of the server. can be made

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

(3) can be, by way of example and not limitation, a system composed of a plurality of terminals.
A system that does not include a server and is composed of terminals can be, by way of example and not limitation, a system such as the following.
・A system in which terminals have server functions (distributed system). This can be accomplished using blockchain technology, by way of example and not limitation.
・A system in which terminals communicate wirelessly with each other. As an example and not a limitation, this can be realized by performing communication in a P2P (Peer-to-Peer) method or the like using short-range wireless communication technology such as Bluetooth.

Note that the above is not limited to the control section, and the same applies to each functional section such as an input/output section, a communication section, a storage section, a clock section, etc., which can be components of the system.

<First embodiment>
The first embodiment is a basic embodiment for realizing the above-described (A) account-linked settlement.
When performing account-linked settlement, it is conceivable to make some or all of the accounts participating in the account-linked settlement pay the amount.
However, in this case, as an example and not as a limitation, there may be cases where account-linked settlement cannot be performed due to insufficient balance in one of the linked accounts.

In the following, the concept of "linked wallet" is introduced as data managed by the server 10, which is data for realizing account linked settlement. The user (user account) of the terminal 20 makes a request to create (generate) a linked wallet, and the server 10 generates data for the linked wallet, thereby enabling account linked settlement.
In addition, linking multiple accounts to achieve account linking settlement is referred to as "account linking" or "wallet linking."

The content described in the first embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

Although the details will be described later, it is also possible to link accounts of a plurality of users.
Further, although the details will be described later, it is also possible for the terminal 20 to execute the account linking process.

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

The server 10 is capable of providing, by way of example and not limitation, payment services and messaging services to terminals 20 owned by users via a network 30 . The server 10 can also be expressed as a payment service server, a payment management server, a payment service server, a payment management server, a messaging server, a messaging service server, and the like. 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.
Note that 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 realizing the functions described in each embodiment. Terminal 20 includes, by way of example and not limitation, smart phones, mobile phones (feature phones), computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set top boxes, digital video recorders), handheld computer devices (as non-limiting examples include PDA (personal digital assistant), email clients, etc.), wearable terminals (glass-type devices, watch-type devices, etc.), VR (Virtual Reality) Including terminals, smart speakers (devices for voice recognition), or other types of computers or communication platforms. Also, the terminal 20 may be expressed as an information processing terminal.

The configuration of terminal 20A, terminal 20B and terminal 20C may be identical, by way of example and not by way of limitation. Further, 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 be expressed as the user information X. It doesn't have to be.
The user information is user information associated with an account used by the user in a predetermined service. User information includes, by way of example and not limitation, user's name, user's icon image, user's age, user's gender, user's address, user's hobbies, entered by the user or provided by a given service It may include information associated with the user, such as preferences, user identifiers, etc., and may or may not be any one or combination of these.

The network 30 serves to connect one or more terminals 20 and one or more servers 10 . That is, the network 30 means a communication network that provides a connection path so that the various devices can transmit and receive data after being connected.

One or more portions of network 30 may or may not be wired or wireless networks. 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 (wireless LAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, public switched telephone network (Public Part of Switched Telephone Network (PSTN), mobile phone network, ISDN (integrated service digital networks), wireless LAN, LTE (long term evolution), CDMA (code division multiple access), Bluetooth (registered trademark), satellite communication, etc., 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, an information processing device, an 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 information processing device capable of realizing the functions described in each embodiment. Server 10 includes, by way of example and not limitation, server devices, computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set-top boxes, digital video recorders, etc.). ), handheld computing devices (by way of example and not limitation, PDAs, email clients, etc.), or other types of computers or communication platforms. Also, the server 10 may be expressed as an information processing device. If 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 represented 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) HW Configuration of Terminal FIG. 1-1 shows an example of the HW configuration of the terminal 20. As shown in FIG.
The terminal 20 includes a control unit 21 (CPU: central processing unit (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. . Each component of the HW of terminal 20 is interconnected via bus B, by way of example and not limitation. Note that the HW configuration of the terminal 20 does not necessarily include all the components. By way of example and not limitation, terminal 20 may or may not be configured for individual or multiple components to be removed.

Communication I/F 22 transmits and receives various data via network 30 . Communication may be performed by wire 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 executing communication with various devices such as the server 10 via the network 30 . Communication I/F 22 transmits various data to various devices such as server 10 according to instructions from control unit 21 . The communication I/F 22 also receives various data transmitted from various devices such as the server 10 and transmits the data to the control unit 21 . Also, the communication I/F 22 may be simply referred to as a communication section. Moreover, when the communication I/F 22 is configured by a physically structured circuit, it may be expressed as a communication circuit.

The input/output unit 23 includes a device for inputting various operations to the terminal 20, a device for outputting processing results processed by the terminal 20, and the like. In the input/output unit 23, the input unit and the output unit may be integrated, the input unit and the output unit may be separated, or not.

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

The output unit is implemented by any one or a combination of all types of devices capable of outputting processing results processed by the control unit 21 . The output unit includes, as non-limiting examples, a touch panel, a touch display, a speaker (audio output), a lens (non-limiting examples include 3D (three dimensions) output and hologram output), a printer, and the like.

Although it is only an example, the input/output unit 23 includes a display unit 24 , a sound input unit 25 , a sound output unit 26 and an imaging unit 27 as an example and not a limitation.

The display unit 24 is realized by any one or a combination of all kinds of devices capable of displaying according to the display data written to the frame buffer. The display unit 24 includes a touch panel, a touch display, a monitor (as a non-limiting example, a liquid crystal display and an OELD (organic electroluminescence display)), a head mounted display (HDM), projection mapping, and a hologram. , including devices capable of displaying 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 hereinafter). Sound input unit 25 includes a microphone and the like.
The sound output unit 26 is used for outputting sound data. Sound output unit 26 includes a speaker and the like.
The imaging unit 27 is used to acquire image data (including still image data and moving image data; the same applies hereinafter). The imaging unit 27 includes a camera and the like.

When the input/output unit 23 is a touch panel, the input/output unit 23 and the display unit 24 may be arranged to face each other with substantially the same size and shape.

The clock unit 29A is a built-in clock of the terminal 20 and outputs time information (clock information). The clock unit 29A is configured with a clock using a crystal oscillator or the like, for example and not limitation. The clock unit 29A can also be expressed as a clock unit or a time information detection unit as an example and not as a limitation.

Note that the clock unit 29A may or may not have a clock to which the NITZ (Network Identity and Time Zone) standard or the like is applied.

The position calculation information detection unit 29B has a function of detecting (measuring) information necessary for the control unit 21 to calculate (measure) the position of its own terminal 20 (hereinafter referred to as “position calculation information”). Department. The position calculation information detection section 29B can also be expressed as a position calculation sensor section as an example and not as a limitation.

The position calculation information detection unit 29B includes, as a non-limiting example, a satellite positioning sensor (satellite positioning sensor) 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). unit), 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, UWB (ultra wideband radio: Ultra Wide A UWB positioning sensor (UWB positioning unit), etc., which is a sensor or unit for calculating the position of the terminal 20 using a band).

The satellite positioning unit includes, as a non-limiting example, an RF receiving circuit that converts an RF (Radio Frequency) signal including a positioning satellite signal transmitted from a positioning satellite received by an antenna (not shown) into a digital signal, Positioning satellite signals are acquired by performing correlation calculation processing, etc. on the digital signals output from the RF receiving circuit, and information such as satellite orbit data and time data extracted from the positioning satellite signals is used as position calculation information. It has a baseband processing circuit for output.

The inertial measurement unit has an inertial sensor that detects information necessary to calculate the position of terminal 20 by inertial navigation calculation. Examples of inertial sensors include, but are not limited to, triaxial acceleration sensors and triaxial gyro sensors. The acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor are used as position calculation information. Output.

As a non-limiting example, the UWB positioning unit converts an ultra-wideband RF (Radio Frequency) signal including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon received by an antenna (not shown) into a digital signal. It has a wideband RF receiving circuit, 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, and the like.
As an example and not a limitation, the UWB positioning unit may cause the terminal 20 to function as a positioning beacon by transmitting an ultra-wideband RF signal including a positioning ultra-wideband pulse signal from an antenna (not shown), You don't have to.

As a non-limiting example, the control unit 21 calculates the position of its own terminal 20 at regular timings or specific timings based on the position calculation information detected by the position calculation information detection unit 29B. The position of the terminal is called "terminal position", and the calculated terminal position is called "calculated terminal position". The control unit 21 may or may not associate the calculated terminal position with the date and time when the calculated terminal position was calculated and store it in the storage unit 28 as calculated terminal position history data.

The control unit 21 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by Therefore, the control unit 21 may or may not be expressed as a control circuit.

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

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

The terminal 20 stores the program P in the storage unit 28 and executes the program P so that the control unit 21 executes processing as each unit included in the control unit 21 . That is, the program P stored in the storage unit 28 causes the terminal 20 to implement each function executed by the control unit 21 . Also, this program P may or may not be expressed as a program module.

(2) Server HW Configuration FIG. 1-1 shows an example of the HW configuration of the server 10. As shown in FIG.
The server 10 includes a control section 11 (CPU), a storage section 15 , a communication I/F 14 (interface), an input/output section 12 and a clock section 19 . Each component of the HW of server 10 is interconnected via bus B, by way of example and not limitation. It should be noted that the HW of the server 10 does not have to include all components as the HW configuration of the server 10 . By way of example and not limitation, the HW of server 10 may or may not be configured to remove individual components or multiple components.

The control unit 11 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by

The control unit 11 is typically a central processing unit (CPU), and may or may not be a microprocessor, processor core, multiprocessor, ASIC, or FPGA. In the present disclosure, the controller 11 is not limited to these.

The storage unit 15 has a function of storing various programs and various data necessary for the operation of the server 10 . The storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Also, the storage unit 15 may or may not be expressed as a memory.

Communication I/F 14 transmits and receives various data via network 30 . Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 14 has a function of executing communication with various devices such as the terminal 20 via the network 30 . Communication I/F 14 transmits various data to various devices such as terminal 20 according to instructions from control unit 11 . The communication I/F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits the data to the control unit 11 . Also, the communication I/F 14 may be simply referred to as a communication unit. Moreover, when the communication I/F 14 is configured by a physically structured circuit, it may be expressed as a communication circuit.

The input/output unit 12 includes a device for inputting various operations to the server 10, a device for outputting processing results processed by the server 10, and the like. In the input/output unit 12, the input unit and the output unit may be integrated, the input unit and the output unit may be separated, or not.

The input unit is implemented by any one or a combination of all types of devices that can receive input from the user and transmit information related to the input to the control unit 11 . The input unit is realized by hardware keys typically represented by a keyboard and 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 a moving image), and a microphone (operation input by voice) as examples, not limitation.

The output unit is implemented by any one or a combination of all types of devices capable of outputting processing results processed by the control unit 11 . The output unit includes, as non-limiting examples, touch panels, touch displays, speakers (sound output), lenses (three-dimension (3D) output and hologram output as non-limiting examples), printers, and the like.

Although it is only an example, the input/output unit 12 includes the display unit 13 as an example and not as a limitation.

The display unit 13 is realized by a display or the like. The display is typically implemented by a monitor (for example, but not by way of limitation, a liquid crystal display or an OELD (organic electroluminescence display)). Note that 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 an internal clock of the server 10 and outputs time information (timekeeping information). The clock unit 19 includes, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, and the like. The clock unit 19 can also be expressed as a clock unit or a time information detection unit as an example and not as a limitation.

(3) Others The server 10 stores the program P in the storage unit 15 and executes the program P so that the control unit 11 executes processing as each unit included in the control unit 11 . That is, the program P stored in the storage unit 15 causes the server 10 to implement each function executed by the control unit 11 . This program P may or may not be expressed as a program module.
The same is true for other devices.

Each embodiment of the present disclosure will be described as being implemented by the CPU of the terminal 20 and/or the server 10 executing the program P. FIG.
The same is true for other devices.

Note that the control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 is not only a CPU having a control circuit, but also an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or the like. Each process may or may not be implemented by a logic circuit (hardware) or a dedicated circuit. Also, these circuits may be realized by one or more integrated circuits, and the plurality of processes shown in each embodiment may or may not be realized by one integrated circuit. LSIs are also 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 is true for other devices.

In addition, the program P of each embodiment of the present disclosure (as a non-limiting example, a software program, a computer program, or a program module) may be provided in a state stored in a computer-readable storage medium, It does not have to be. The storage medium can store the program P in a "non-transitory tangible medium". Also, the program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the function of each embodiment of the present disclosure may or may not be a so-called difference file (difference program) that can be realized in combination with a program P already recorded on 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 without limitation, field programmable gate arrays (FPGAs) or application specific ICs (ASICs)), hard Disk drive (HDD), hybrid hard drive (HHD), optical disk, optical disk drive (ODD), magneto-optical disk, magneto-optical drive, floppy diskette, floppy disk drive (FDD), magnetic tape, solid state It may include a drive (SSD), RAM drive, secure digital card or drive, any other suitable storage medium, or any suitable combination of two or more thereof. Storage media may, where appropriate, be volatile, nonvolatile, or a combination of volatile and nonvolatile. Note that the storage medium is not limited to these examples, and any device or medium that can store the program P may be used. Also, the storage medium may or may not be expressed as memory.

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

In addition, 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 (communication network, broadcast wave, etc.) capable of transmitting the program. . As a non-limiting example, the server 10 and/or the terminal 20 implement the functions of the plurality of functional units shown in each embodiment by executing a program P downloaded via the Internet or the like.
The same is true for other devices.

Each embodiment of the present disclosure can also be implemented in the form of a data signal in which the program P is embodied by electronic transmission.
At least part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
At least part or all of the processing in the terminal 20 may or may not be performed by the server 10 . In this case, the server 10 may or may not perform at least some or all of the processing of the functional units of the control unit 21 of the terminal 20 .
At least part or all of the processing in the server 10 may or may not be performed by the terminal 20 . In this case, the terminal 20 may or may not perform at least some or all of the processing of the functional units of the control unit 11 of the server 10 .
Unless explicitly mentioned, the configuration of determination in the embodiments of the present disclosure is not essential, and predetermined processing is performed when the determination condition is satisfied, or predetermined processing is performed when the determination condition is not satisfied. may or may not.

Note that the program of the present disclosure uses script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), markup languages such as HTML5, and the like, for example and not limitation. Implemented.

[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.
Control unit 11 includes, as a functional unit, payment application management processing unit 111 for executing payment application management processing according to payment application management processing program 151 stored in storage unit 15, as an 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 storage unit 15 stores a payment application management processing program 151 executed as payment application management processing, account registration data 153, an account management database 155, and a cooperative wallet management database 157, as an example and not limitation. .

The account registration data 153 is registration data relating to the account of the application (payment application in this example), and an example of the data configuration is shown in FIG. 1-4.
The account registration data 153 stores, for example and not limitation, a user name, an application ID, and other registration information 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 when the user of the terminal 20 uses the application is stored.

The application ID is information used to identify the account of the application, or the account itself.
This application ID is preferably a unique value for each account, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) 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 about the terminal or information about the user of the terminal.

The other registration information includes, for example and not limitation, identification information for identifying the terminal 20, the telephone number of the terminal 20 (terminal telephone number), the e-mail address (terminal e-mail address), and the Various information such as authentication information such as a password (login password, authentication password, etc.) can be included.

The identification information for identifying the terminal 20 may be, by way of example and not by way of limitation, a terminal ID (by way of example and not by way of limitation, IMEI (International Mobile Equipment Identity)).
Also, the identification information for identifying the user of the terminal 20 can be an application ID as an example and not a limitation. A "user ID" may or may not be used instead of the application ID.

Also, if the application allows only one account to be registered for one terminal 20, as an example without limitation, "identification information for identifying the terminal 20=identification information for identifying the user of the terminal 20= Application ID".

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

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

The account management database 155 is a database for managing accounts stored in the account registration data 153, and an example of the data structure of the first account management database 155A is shown in FIG. 1-5.
Account management data is stored in the first account management database 155A 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 and an electronic money account balance.
The e-money account balance is the balance of the e-money account for that application ID (that account), which is stored and managed by server 10 by way of example and not limitation. It may be simply referred to as "balance".

The cooperative wallet management database 157 is a database for managing the aforementioned cooperative wallets, and an example of the data structure of the first cooperative 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 federated wallet management data stores, by way of example and not limitation, a federated wallet ID, federated account data, and payment history data.

The linked wallet ID is information for identifying the linked wallet used for account linked settlement, as an example and not as a limitation.

The federated wallet ID is preferably a unique value for each federated wallet, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each federated wallet.

Linked account data is data related to a user account that is linked to perform account linked settlement (hereinafter referred to as "linked account"). A user name corresponding to the ID is associated and stored.

Hereinafter, a user who participates in account-linked settlement is referred to as a "linked member," while a user account linked to perform account-linked settlement as described above is referred to as a "linked account."

One user owns a plurality of user accounts, and it is also possible for this one user to link his/her own user accounts. For this reason, there is not necessarily a one-to-one correspondence relationship between a linked member and a linked account.

In the example of FIG. 1-6, two application IDs, "U0001" and "U0005", are stored in the linked wallet management data shown in the foreground. The name is "A.A". Thus, in this example, user A. Two accounts owned by A are associated as linked accounts.

The payment history data is the data of the history of settlement (payment) by account linked settlement. stored in series.

The transaction ID is an ID as identification information for identifying the transaction for which the payment was made.
This transaction ID is preferably a unique value for each transaction, and by way of example and not limitation, a unique value (unique value) is set and stored by the server 10 for each transaction.

The shop ID is an ID as identification information for identifying the shop where the transaction was made.
This store ID is preferably a unique value for each store, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each member store.

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).

For the date and time of payment, as an example and not as a limitation, the date and time when the server 10 performed settlement processing for the transaction is stored as the date and time of payment.

The payment amount stores, by way of example and not limitation, the amount settled by server 10 for the transaction. This payment amount means the amount settled by the server 10 (settled amount).

(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.
Control unit 21 includes, as a functional unit, payment application processing unit 211 for executing payment application processing according to payment application processing program 281 stored in storage unit 28, as an example and not 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.
The storage unit 28 stores a payment application processing program 281 to be executed as payment application processing and an application ID 283 of the own terminal 20 or the user of the own terminal 20 as an example and not a limitation.
Note that the application ID 283 may or may not store a plurality of application IDs.

<Display screen>
In the following, as an example and not a limitation, a case where the terminal 20 is a smart phone having a vertically long display unit 24 will be illustrated.

As an example and not a limitation, a smartphone has a touch panel that functions as an input unit facing its display, thereby forming a touch screen. When an element such as an icon, button, item, or input area is displayed on the display, if the user operates an area that is part of the touch panel and faces the area where the element is displayed, A program associated with the element or a subroutine of that program is executed.

Hereinafter, the user's operation will be described as a tap (tap operation) as an example and not as a limitation.
A tap (tap operation) is, for example and not limitation, an operation in which the user touches the display unit 24 (touch screen) integrated with a touch panel by lightly tapping the display unit 24 (touch screen) with a finger or a pen tip, or touches and then releases It is action.

Note that the transition of the display screens described below is merely an example of the transition of the display screens for realizing the technique of the present disclosure. Regarding the transition of the display screens illustrated below, the display of a part of the display screens may be omitted, or another display screen may be added.

1-9 and 1-10 are diagrams showing examples of screen transitions displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of FIGS. 1-9 shows, by way of example and not limitation, user A.A. 4 is a main menu screen of a payment application displayed on the display unit 24 of A's terminal 20A.

At the top center of the menu screen, characters "Payment App" are displayed as the name of the payment application. Also, an icon image and a user name (user A.A in this example) of the payment application of the user of this terminal 20 are displayed on the right side of the top of the screen.

Further, a current position display area CLR1 indicating the current position in the payment application is configured below it, and in this example, the characters "wallet main menu" indicating that the current position is the main menu of the payment application are displayed. , is displayed in the current position display area.

By way of example and not limitation, when the federated wallet icon IC1 containing the text and image of the federated wallet displayed at the bottom of the main menu screen is tapped, the user A.P. Linked wallet information about the account linking multiple user accounts of A is displayed.

An example of the linked wallet information display screen is shown in the center of Figure 1-9.
In this screen, the current position display area CLR1 displays the characters "cooperative wallet" indicating that the cooperative wallet function is being used. Also, below the current location display area CLR1, a code reader icon IC2 indicated by the characters "code reader" for performing "store presentation type" code payment using the cooperative wallet, and a "user presentation type" icon IC2. A code payment icon IC3 indicated by the characters "code payment" for performing code payment is displayed side by side.

Below these icons, "A.A's Linked Wallet" including the user name of the linked wallet is displayed, and further below that is the linked wallet to display the status of the linked account of this linked wallet. A member information display area MIR1 is displayed.

In the cooperation member information display area MIR1, each cooperation account and the cooperation status are displayed in association with each other. By way of example and not limitation, an "A.A main account" is defined as user A.A. A's main user account (hereinafter referred to as "main account" as appropriate). The main account is, as an example and not a limitation, a user account that is used when an operation other than the linked wallet is performed on the main menu screen on the left side of FIG. 1-9. In this example, it is shown that the electronic money account balance of the main account is "5,000 yen".

Also, by way of example and not limitation, an "A.A subaccount" refers to user A.A. A's sub-user account (hereinafter referred to as "sub-account" as appropriate). The subaccount is user A. A user account other than the main account owned by A. In this example, it is indicated that the electronic money account balance of the sub-account is "3,000 yen".

As a non-limiting example, when the code reader icon IC2 is tapped (touched) on this screen, cooperative wallet code reader information for making payment using this cooperative wallet is transmitted from the server 10 to the terminal 20A. . Then, the control unit 21 of the terminal 20A uses a code reader provided as a function of the code payment application (hereinafter referred to as "application code reader") to read the terminal reading code presented to the store on the terminal 20A. to start.

An example of an application code reader screen is shown on the right side of FIG. 1-9.
On this screen, under the current position display area CLR1, characters of "code reader", which is the function currently being executed, are displayed. A code reading area CR1 for reading the payment shop code is displayed in the center of the screen.

The left side of FIG. 1-10 is a diagram showing an example of a payment amount input screen displayed when information is acquired by decoding from the paying store code read in the right side of FIG. 1-9.

On this payment amount input screen, the name "XX musical instrument" is displayed together with the icon image of "XX musical instrument" which is the recipient of the payment amount. Below that, a payment amount display area PR1 for displaying the input payment amount is displayed. Here, "4,500 yen" is input and displayed as the payment amount. At the left end of the payment amount display area PR1, an erase button indicated by a circled x mark for erasing the payment amount is displayed.
A keyboard for inputting the payment amount is displayed at the bottom of the screen, and a payment button BT1 indicated by the characters "payment" for executing payment with the payment amount entered in the payment amount display area PR1. is displayed.

When the payment button BT1 for executing payment is tapped on the payment amount input screen shown on the left side of FIG. 1-10, code payment using the linked wallet is executed.

1-9, when the code payment icon IC3 is tapped, the code payment screen is displayed on the display unit 24 of the terminal 20A. On the code payment screen, a code (code image) sent from the server 10 and received by the terminal 20 is displayed as a cooperative wallet payment code, which is a code used for making a payment in the "user presentation type". A one-dimensional payment code, represented by a bar code as an example and not by way of limitation, and a two-dimensional payment code, represented by a QR code as an example and not by way of limitation, are displayed. User A. of terminal 20A. A can also 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 store code reader read the payment code.

In the center of FIG. 1-10, a cooperative payment result display screen is displayed for confirming the payment result using the cooperative wallet.

At the top of the linked payment result display screen, along with the text "Payment completed" indicating that the payment using the linked wallet has been completed, the icon image of "XX musical instrument", which is the destination of the payment amount, and its name "XX musical instrument” and the payment date and time “2020-07-24/12:17:08” are displayed.

At the bottom of the cooperative payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of this payment for each cooperative account.
In the member payment result display area MRR1, for each linked account, the paid user account, the amount paid by each user account, and the electronic money account balance after payment are displayed.

As an example and not a limitation, in this embodiment, each linked account pays an amount obtained by equally dividing the total payment amount among linked accounts (a split amount) as a payment amount.

Note that, unlike this, the payment amount ratio may or may not be changed for each linked account. As a non-limiting example, "main account: subaccount" = "2:1" or the like may or may not be used.

The right side of FIG. 1-10 is an example of a screen displayed on the display section 24 of the terminal 20A after the screen in the center of FIG. 1-10 is displayed. In this screen, a remittance promotion notification area RER1 for prompting remittance from the main account to the sub-account is displayed rising from the bottom of the linked payment result display screen. This is because, as a result of the cooperative payment, the payment is made in a subaccount that is not selected on the main menu screen, so the user A.A. This is an area for displaying a notification to prompt A.

<Processing>
In the following, the "payment store code" used in store presentation type code payment is used as an example, not limitation, as member store identification information for identifying member stores (as an example, not as a limitation, a store uniquely assigned to a member store It will be described as a code (one-dimensional code or two-dimensional code) including an ID).

The payment store code may or may not include information on a specific scheduled payment amount ("500 yen" as an example, not a limitation).

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

Here, as an example, the linked account is user A. A first user account (as an example and not by way of limitation, an account whose application ID is indicated by "U0001") and user A.A. A process in the case of performing account-linked settlement with A's second user account (as an example, not limitation, an account whose application ID is indicated by "U0005") will be described.
In practice, the number of user accounts to be linked in account linked settlement is not limited to two, but the same applies when there are three or more user accounts, so illustrations and descriptions are omitted here.

Also, this processing is merely an example of processing for realizing the technique of the present disclosure, and is not limited to this processing. Another step may be added to this process, or some steps may be omitted (deleted) from this process.
This is the same for each flowchart (process) described below.

First, as a non-limiting example, the control unit 11 of the server 10 calculates the account balance of each cooperative member linked to the cooperative wallet identified by the cooperative wallet ID, which is specified in advance based on the user's operation of the terminal 20A. Generate a payment token (hereinafter referred to as a “federated wallet payment token”) that authorizes the payment used.
Federated Wallet Payment Tokens are identified, by way of example and not by way of limitation, by integer values of a predetermined number of digits (12 digits by way of example and not by way of limitation).
It should be noted that the federated wallet payment token may or may not be a token with an expiration date that permits authorization only within a predetermined period of time ("5 minutes" as an example, not a limitation) from generation.

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

When the cooperative wallet code reader information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A displays a code reader screen for reading the payment store code based on the received cooperative wallet code reader information. 24. Also, the control unit 21 of the terminal 20A activates the imaging unit 27 to read the code. Then, the control unit 21 of the terminal 20A uses the activated imaging unit 27 or the like to execute code reading processing for reading the payment store code (A100).

When the store ID is acquired from the payment store code read in the processing of A100, the control unit 21 of the terminal 20A causes the display unit 24 to display a display screen for inputting the planned settlement amount as an example and not as a limitation. When the estimated payment amount is input based on the user's operation on the input/output unit 23 of the terminal 20A, the control unit 21, for example and not limitation, inputs the linked wallet payment token included in the linked wallet code reader information, the store ID, and , and the planned settlement amount are transmitted to the server 10 via the communication I/F 22 (A110).

When the cooperative payment request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 searches for the cooperative wallet ID from the requested cooperative wallet payment token, and sends the cooperative wallet with the store ID. A store-presented cooperative settlement process, which is an example of a store-presented account-linked settlement process, is executed to pay a scheduled settlement amount with a predetermined member store (S110).

In the store-presented cooperative payment process, first, as an example and not a limitation, the control unit 11 of the server 10 splits (divides) the planned payment amount by the number of cooperative accounts (hereinafter referred to as "divided payment amount"). ) is calculated. Then, the control unit 11 of the server 10 performs settlement processing using the equal payment amount as the payment amount for each linked account stored in the linked account data of the linked wallet data.

If the value of "Electronic money account balance - Equal payment amount" is 0 or more for all linked accounts, the equal payment amount will be processed for each linked account, and the linked payment processing will be successful. becomes.
On the other hand, if the value of "electronic money account balance-equal payment amount" is negative for any of the accounts, the payment processing to the linked account is not performed, and the store presentation type linked payment processing fails.

In addition, in the store presentation type cooperative payment processing, instead of executing settlement of the equal payment amount from each cooperative account, once, a predetermined account of the cooperative account (as an example, not limited to, the first user AA account) from another account, and then execute settlement of the scheduled settlement amount from a predetermined account, or it is not necessary to do so.

When the store presentation type cooperative settlement process is successful, the control unit 11 of the server 10, as a non-limiting example, sends remittance request information prompting remittance from the first user account to the second user account through the communication I/F 14 to the terminal. 20A (S120).

As an example and not a limitation, as described in the display screen example, the user A.A. It can be assumed that A uses the first user account as a main account and the second user account as a sub-account.
If the store presentation type cooperative payment processing is successful, the user A. The equal payment amount is also deducted from the electronic money account balance of A's subaccount, and the balance decreases. In such a case, the server 10 instructs the user A. to transfer money from the first user account (main account) to the second user account (sub-account) to replenish the balance of the second user account. You can encourage A.

Note that if settlement of the equally divided payment amount fails in the first user account, the second user account, or both (that is, if the store presentation type cooperative settlement process fails), the user A.A. The account of the external financial institution registered in advance by A may or may not transmit information prompting charging (remittance) to the account for which the settlement failed as remittance request information.
In addition, as a non-limiting example, information prompting an account to make a loan from an external financial institution or the like may be sent as remittance request information to an account for which settlement has failed, or not. good.

After transmitting the remittance request information, the control unit 11 of the server 10 terminates the process.

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

<Effect of the first embodiment>
In this embodiment, the terminal 20 has a first user account (not a limitation, but an example of a first user of the terminal) of its own terminal 20 user (not a limitation, but an example of a first user of the terminal) and a first user account Based on the second user account linked with (not limited, but an example of a second account associated with the first account), the process related to the account linked settlement (not limited, but an example of the process related to the first settlement) is controlled. by the unit 21.
In addition, the terminal 20 communicates remittance request information from the first user account to the second user account (not a limitation, but an example of first information regarding remittance to the second account) based on account-linked settlement. Received by F22.
Then, the terminal 20 is configured to display the received remittance request information on the display unit 24 (not a limitation, but an example of a first display based on the first information).
As an example of the effect of the embodiment obtained by such a configuration, based on the first account of the first user of the terminal and the second account associated with the first account, By performing processing by the control unit of the terminal, it is possible to enable the first payment by at least two associated accounts.
Also, the first user of the terminal can be notified of the first information regarding the transfer of money to the second account by the first payment. As a result, by way of example and not limitation, the first user may be prompted to transfer money to the second account.

The concept of transferring money to the second account includes not only transferring money to the second account but also transferring money to a plurality of accounts (including the second account). Therefore, the first information about transferring money to the second account is a concept that also includes information about transferring money to a plurality of accounts.

In this case, as an example and not a limitation, not only the first account but also the second account can be the account of the first user, so that settlement can be made based on a plurality of accounts of one user. Also, by way of example and not limitation, the first user may be prompted to transfer money to another account of the first user (second account).

In addition, in the present embodiment, the server 10 (not limited to, but an example of a server that communicates with a terminal and performs processing related to payment) has a first user account of the user of the terminal 20 and a second user account linked with the first user account. Based on the user account, the control unit 11 executes store presentation type account-linked settlement processing (not limited, but an example of processing related to the first settlement). Moreover, the server 10 shows the structure which transmits remittance request information to the terminal 20 by communication I/F14 based on this account cooperation settlement.
As an example of the effect of the embodiment obtained by such a configuration, the server performs processing related to the first payment based on the first account of the first user of the terminal and the second account associated with the first account. By being performed by the control unit, the first payment can be performed by the associated at least two accounts.
Also, the first user of the terminal may be notified of first information about transferring money to the second account based on the first payment. As a result, by way of example and not limitation, the first user may be prompted to transfer money to the second account.

<First modification (1)>
In the first embodiment, the remittance request information is information that prompts remittance from the first user account to the second user account, information that prompts the first user account or the second user account, or both to charge money, a loan, or the like. Although it is information that prompts borrowing, it is not limited to this. As an example and not a limitation, the remittance request information may be information including these specific amounts.

<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, respectively.

On the right side of FIG. 1-12, in the remittance promotion notification area RER2, the remittance from the main account to the sub-account is indicated by the user A. In addition to the notification for prompting A, the recommended amount for remittance from the main account to the sub-account, "¥2,250", is displayed. This amount is the amount paid from the sub-account at the time of the payment displayed on the linked payment result display screen.

<Processing>
FIG. 1-13 is a flow chart showing an example of the flow of processing executed by each device in this case.
An example of processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A) and processing executed by the control unit 11 of the server 10 are shown in order from the left.

After S120, the control unit 11 of the server 10 recommends remittance or charge of the equally divided payment amount from the first user account to the second user account when the store presentation type cooperative settlement processing of S110 is successful. (hereinafter collectively referred to as "recommended remittance amount"), and the recommended remittance amount information, which is the information, is transmitted to the terminal 20A via the communication I/F 14 (S130).

In addition, if the store presentation type cooperative payment process fails, the amount calculated by "Equal payment amount - electronic money account balance" will be charged to the linked account for which the payment of the equal payment amount fails. The recommended amount may be transmitted to the terminal 20A through the communication I/F 14, or may not be transmitted.
Then, the control unit 11 of the server 10 terminates the process.

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

This modification shows a configuration in which the first information is recommended remittance amount information (not limited, but an example of information based on the amount paid by the second account in the first settlement).
As an example of the effect of the embodiment obtained by such a configuration, it is possible to inform the first user of the terminal of the first information based on the amount paid in the first payment by the second account. By way of example and not limitation, the recommended amount to transfer or charge may be communicated to the first user of the terminal.

<Second embodiment>
In the first embodiment, when the terminal 20A displays the remittance request information on the display unit 24, the process is finished.
In addition to this, the second embodiment is an embodiment in which remittance between accounts is executed based on remittance request information.

The content described in the second embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

In the remittance promotion notification area RER3, in addition to the contents of the remittance promotion notification area RER2, a remittance button BT2 for executing remittance processing based on the notification contents of the remittance promotion notification area is displayed at the bottom.

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

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

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

After executing step A130, the control unit 21 of the terminal 20A displays on the display unit 24 a screen for selecting whether or not to transfer the recommended remittance amount from the first user account to the second user account, as an example and not a limitation. (A140).

Instead of the recommended remittance amount, the remittance screen may or may not be a screen for selecting whether to remit a predetermined amount or an amount based on the user's input. In this case, the steps S130 and A130 may be omitted or not.

If remittance is selected based on the user operation on input/output unit 23 of terminal 20A (A140: YES), control unit 21 of terminal 20A sets the recommended remittance amount to the first user account as an example and not as a limitation. to the server 10 via the communication I/F 22 (A150).

On the other hand, when not remittance is selected (A140: NO), the control unit 21 of the terminal 20A terminates the process.

When the remittance instruction information is received from the terminal 20A through the communication I/F 14 (S140: YES), the control unit 11 of the server 10, based on the remittance instruction information, for example, without limitation, transfers the first user account to the second user account. A remittance process for remittance of the recommended remittance amount is executed (S150). Then, the control unit 11 of the server 10 transmits the result of the remittance process to the terminal 20A through the communication I/F 14 as remittance result information (S160). After that, the control unit 11 of the server 10 terminates the process.

When the remittance instruction information is not received from the terminal 20A (S140: NO), the control section 11 of the server 10 terminates the process.

Upon receiving the remittance result information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A displays the remittance result information on the display unit 24 (A160). Then, the control unit 21 of the terminal 20A terminates the process.

<Effect of Second Embodiment>
In this embodiment, the terminal 20 displays a screen for selecting whether or not to transfer the recommended remittance amount displayed on the display unit 24 from the first user account to the second user account (not a limitation, but an example of the first display). ) by the user of the terminal 20, the configuration for executing the processing for transferring money from the first user account to the second user account.
As an example of the effect of the embodiment obtained by such a configuration, the terminal receives the amount based on the first information from the first account by a simple method of input by the first user to the first display based on the first information. You can transfer money to a second account.

In addition, in the present embodiment, the server 10 (not limited to, but an example of a server that communicates with a terminal and performs processing related to payment) has a first user account of the user of the terminal 20 and a second user account linked with the first user account. Based on the user account, the control unit 11 executes an account-linked settlement process (not a limitation, but an example of a process related to the first settlement). In addition, the server 10 transmits remittance request information to the terminal 20 through the communication I/F 14 based on this account-linked settlement. Then, the server 10, based on the input by the user of the terminal 20 on the display of the screen for selecting whether to remit the recommended remittance amount from the first user account to the second user account displayed on the terminal 20, It shows a configuration for performing remittance processing from one user account to a second user account.
As an example of the effect of the embodiment obtained by such a configuration, the server calculates the amount based on the first information based on the input by the first user to the first display based on the first information displayed on the terminal, Money can be transferred from the first account to the second account.

<Third embodiment>
In the first embodiment and the second embodiment, the cooperative accounts are explained as different user accounts of one user, but the invention is not limited to this.
Below, the case of linking user accounts of different users (when linking accounts are accounts of different users) will be described.

When making a payment using a linked wallet, as an example and not a limitation, if the electronic money account balance of one of the linked user accounts (one of the linked accounts) is small and does not reach the equal payment amount, A possible method is to temporarily ask another linked user account to cover the shortfall and execute the payment.
In this case, it is necessary to return the burdened amount (reimbursement amount) after payment, but as an example rather than as a limitation, it is necessary to manually execute the process of returning, which is inconvenient.

The content described in the third embodiment can be applied to each of the other embodiments and modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

In this practical example, application IDs of different users are stored as application IDs in the linked account data of the first linked wallet management database 157A.

In the following, by way of example and not limitation, federated account data may include user A. A's user account (as an example and not by way of limitation, application ID "U0001") and user B.A. B's user account (application ID "U0002" as an example, not a limitation) is stored.
That is, user A. A and user B. A case where B is a cooperation member is illustrated.

Also, in this embodiment, user A. who executes code settlement. A case is exemplified in which the electronic money account balance of user A's account is small and does not reach the equal installment payment amount.

<Display screen>
In the following, user A. A's user account and user B.A's user account. A user account of B is linked as a linked account, and an example of performing account linked settlement using these linked accounts will be described. In this example, since one user account of each of a plurality of users is linked, there is a one-to-one correspondence relationship between a linked member and a linked account.

FIG. 3-1 is a diagram showing an example of screen transitions 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 FIG. 3-1 is the main menu screen of the payment application described above, and shows a state where the linked wallet icon IC1 is tapped.

The central part of FIG. 3-1 is an example of the linked wallet information display screen displayed when the linked wallet icon IC1 is tapped, and is a screen corresponding to FIG. 1-9.
In this example, user A. A's user account and user B.A's user account. Since the user account of B is linked, the characters "A.A and BB linked wallet" including the user name for the linked wallet are displayed.

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

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

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

In this cooperative payment confirmation screen, as an example and not limitation, a payment amount confirmation area PIR1 is displayed below the current position display area CLR1. In the payment amount confirmation area PIR1, as an example and not limitation, an icon image of "XX musical instrument" which is the destination of the payment amount, its name "XX musical instrument", and the payment amount "4,500 yen" are displayed. ing. Under the payment amount, the current cooperative payable amount of "3,250 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 cooperative payable amount is less than the payment amount.

Also, under the payment amount confirmation area PIR1, the name of the cooperation member is displayed together with the icon. Below that, a paying member confirmation area PMR1 is displayed for confirming the payment burden status of each cooperation member.

Here, the cooperative payable amount is an amount defined by the following formula, assuming that the payment amount is divided equally among the cooperative accounts.
・Collaboration Payable Amount = Sum of payment capacity for all cooperative accounts

Here, the payment capacity of one linked account is defined by the following formula.
・Payment capacity of one linked account = Electronic money account balance of that linked account (Electronic money account balance of linked account - Equal payment amount < 0)
・Payment capacity of one linked account = Equal payment amount (If the electronic money account balance of the linked account - Equal payment amount ≥ 0)
However, it is calculated as "Equal payment amount = payment amount / number of linked accounts".

It should be noted that these formulas may or may not be applied to the first embodiment and the second embodiment to calculate the cooperative payable amount in the same way, as examples rather than limitations.
In other words, the above-mentioned cooperative account can be defined as a plurality of user accounts of one user, for example without limitation, as two user accounts such as the above-mentioned first user account (main account) and second user account (sub-account). , the cooperative payable amount may or may not be calculated.

In this embodiment, since there is a one-to-one correspondence between the cooperation member and the cooperation account, the above formula can also be defined by the cooperation member. That is, the above formula can also be expressed as follows.
・Collaboration Payable Amount = Total Payable Ability of All Cooperating Members ・Payment Ability of One Cooperating Member = Electronic Money Account Balance of the Cooperating Member (Electronic Money Account Balance of the Cooperating Member - Equal Payment Amount < 0) case)
・Payment capacity of one cooperative member = equal payment amount (if the cooperative member's electronic money account balance - equal payment amount ≥ 0)
However, it is calculated as "equally divided payment amount = payment amount / number of cooperative members".

In the payment member confirmation area PMR1, as an example and not limitation, for each cooperation member (cooperation account), an icon, a user name, a payment capacity, and an electronic money account balance are displayed in association with each other for each line. there is In addition, a warning mark is superimposed on the upper left of the icon for a user whose payment capacity is less than the equal payment amount.

In this example, the equal payment amount is "4,500 yen/2=2,250 yen".
User A. As for user A, since the remaining payment capacity is less than the equal payment amount, user A.A. A warning mark is displayed on the upper left of the icon of A, indicating that the payment capacity is "1,000 yen".
On the other hand, user B. As for B, since the ability to pay does not fall below the amount of equal payment, no warning mark is displayed, indicating that the ability to pay is "2,250 yen".

In this example, since the cooperative payable amount is less than the payment amount, the payment cannot be made as it is. Therefore, at the bottom of the cooperative payment confirmation screen, user A.A. User B. A needs to pay upfront "2,250 yen - 1,000 yen = 1,250 yen", which is insufficient for User A's ability to pay "1,000 yen". A reimbursement request button BT4 is displayed, which is indicated by the characters "Get reimbursed by another member" for executing payment with B reimbursed.

The right side of FIG. 3-2 is an example of a linked payment confirmation screen when the advance request button BT4 is tapped.
In this linked payment confirmation screen, user B. is displayed in the payment member confirmation area PMR1. B's ability to pay has increased to "3,500 yen", which is the amount "2,250 yen" for equal installment plus the amount "1,250 yen" required for advance payment. Along with this, the cooperative payable amount in the payment amount confirmation area PIR1 is increased to "4,500 yen", the characters "Insufficient balance" disappear, and the characters "Payable" are displayed.

Also, at the bottom of the cooperative payment confirmation screen, a cooperative payment execution button BT5 indicated by the characters "payment" for executing payment according to the current payment capacity is displayed.

FIG. 3-3 is an example of screen transition when the cooperative payment execution button BT5 is tapped on the cooperative payment confirmation screen on the right side of FIG. 3-2.
On the left side of FIG. 3-3, a linked payment result display screen is displayed for checking the payment result using the linked wallet.

At the top of the linked payment result display screen, along with the text "Payment completed" indicating that the payment using the linked wallet has been completed, the icon image of "XX musical instrument", which is the destination of the payment amount, and its name "XX musical instrument” and the payment date and time “2020-07-24/12:17:08” are displayed.

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

As an example and not by way of limitation, member payment result display area MRR1 shows user A.A. It is shown that A has paid the remaining payment capacity of "1,000 yen", and as a result, the electronic money account balance has become "0 yen". Also, user B. It is shown that B has paid the remaining payment capacity of "3,500 yen", and as a result, the electronic money account balance has become "2,500 yen".

Also, user B. In item B, user A.B. A is user B.A. User B pays the "1,250 yen" paid by User B. An advance amount refund button BT6 for returning to B is additionally displayed.

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

In the notification information display area NTR2 of the notification screen, cooperative settlement result information CT2 based on execution of the cooperative payment and advance payment information CT3 based on the occurrence of the cooperative payment are displayed.

The linked settlement result information CT2 includes user A. The amount "1,000 yen" paid by A, the payment date and time, the fact that the payment was completed using the linked wallet, and the payment destination "XX musical instrument" are displayed. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
At the bottom of the linked settlement result information CT2, a detail confirmation button indicated by the words "confirm details" is displayed for confirming the details of the payment. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the left side of FIG. 3-3 is displayed.

In addition, the linked settlement result information CT2 includes the user A. Instead of "1,000 yen", which is the amount paid by A, "4,500 yen", which is the total payment amount paid for "XX instrument", may be displayed, or not. good.
Or user A. Both the amount paid by A and the total amount paid may or may not be displayed.
Alternatively, the amount paid by the other user may be added and displayed, or may not be displayed.

In the advance payment information CT3, user B.B. Information indicating that "1,250 yen" was paid for by B is displayed. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
Below that is a detail confirmation button indicated by the words "Confirm details" for confirming payment details. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the left side of FIG. 3-3 is displayed.
At the bottom of the advance information CT3, an advance amount refund button BT6 is displayed.

When the advance payment amount refund button BT6 is tapped, user A. A's e-money account to user B.A. Remittance of "1,250 yen" for payment is executed to B's electronic money account.

Note that user A. If A's electronic money account balance is less than the amount paid and remittance cannot be executed, the button operation may be invalidated by graying out the display mode of the payment amount refund button BT6, or otherwise. good.
Also, user A. When A's electronic money account balance is less than the amount to be paid, and the advance payment amount refund button BT6 is tapped, the screen may or may not be changed to a screen prompting charging from the bank account.

When the refund for the paid amount is completed using the refund button BT6, the button operation may be invalidated by graying out the display mode of the refund button BT6 in the subsequent display, or otherwise. may

In addition, in the notification information display area NTR2, the cooperative settlement result information CT2 and the advance information CT3 may be collectively displayed as one piece of information, or may not be displayed in such a manner.

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

When the cooperative payment request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 calculates the cooperative payable amount and determines whether the calculated cooperative payable amount is less than the planned settlement amount ( A determination is made as to whether or not cooperative payable amount−scheduled settlement amount<0 (S210). If the cooperative payable amount is less than the planned settlement amount (S210: YES), the control unit 11 of the server 10 determines that the cooperative payable amount is insufficient and payment cannot be executed. Insufficient cooperative balance information indicating that remittance is necessary to the account of is transmitted to the terminal 20A through the communication I/F 14 (S220).

If the cooperative payable amount is not less than the planned settlement amount (when the cooperative payable amount minus the planned settlement amount is 0 or more) (S210: NO), payment using the cooperative wallet is possible, so the server 10 shifts the processing to step S110.

When the communication I/F 22 receives the linked balance shortage information from the server 10 (A200: YES), the control unit 21 of the terminal 20A adds to the account of another linked wallet member (user BB in this case). User A. The balance replenishment request information for continuing the payment is sent to the server 10 via the communication I/F 22 by asking the user A to bear the shortfall of the payment capacity of A (that is, the equal payment amount - the payment capacity of the user A.A). (A210).

It should be noted that user B. When the electronic money account balance of the account of B.B is equal to or greater than the planned settlement amount, the balance replenishment request information of user B.B. Information may be transmitted to have B's account bear the full amount of the scheduled payment amount, or it may not.

Further, when the link balance shortage information is not received from the server 10 via the communication I/F 22 (A200: NO), step A210 is not executed.

When the balance replenishment request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 executes cooperative balance replenishment processing based on the received balance replenishment request information (S230).
In the linked balance replenishment process, the control unit 11 of the server 10 controls the user A.A. The shortfall of A's ability to pay (required amount for advance payment) is transferred to user B.A. The amount added to B's ability to pay is given to new user B.B. Update it as B's ability to pay. Then, the control unit 11 of the server 10 sends the required amount for advance payment to the user A.A. A to user B. It is stored in the storage unit 15 as the required amount to be returned to B.

Note that the control unit 11 of the server 10 transmits the processing result of the cooperative balance replenishment processing to the terminal 20A via the communication I/F 14, and the control unit 21 of the terminal 20A processes the cooperative balance replenishment processing received through the communication I/F 22. The result may be displayed on the display unit 24, or may not be displayed.

Also, in the cooperative balance replenishment process, user B. Rather than increase B's ability to pay, user B.B. B's account to user A.B's account. By executing the remittance process of the amount required for advance payment to the account of user A. A's ability to pay may or may not be increased.

When executing the store presentation type cooperative payment process (S110), the control unit 11 of the server 10 transmits cooperative payment result information, which is the execution result of the cooperative payment process, to each terminal 20 of the cooperative member via the communication I/F 14. (S240).

When the cooperative settlement result information is received from the server 10 by the communication I/F 22, the control unit 21 of the terminal 20A displays the cooperative settlement result information on the display unit 24 (A230).

Upon receiving the cooperative payment result information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the cooperative payment result information (B200).

If the coordinated balance replenishment processing is executed prior to the coordinated settlement processing (S250: YES), the control unit 11 of the server 10 sends the lending and borrowing information including the required return amount stored in the storage unit 15 to the communication I/F 14. to each terminal 20 of the cooperation member (S260).
On the other hand, if the cooperative balance replenishment process has not been executed (S250: NO), the control unit 11 of the server 10 terminates the process.

When the 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 the lending/borrowing information is not received (A240: NO), the control unit 21 of the terminal 20A terminates the process.

After step A250, the control unit 21 of the terminal 20A sends the required return amount to the user B. A screen for selecting whether or not to return the item to B is displayed on the display unit 24 (A260).
It should be noted that between step A250 and step A260, user A. Charges to user A.A's account or from other accounts to user A.A. Processing such as remittance to A's account may be interposed.

Based on the user's operation on the input/output unit 23 of the terminal 20A, the required return amount is sent to the user B. If returning to user A.B is selected (A260: YES), control unit 21 of terminal 20A controls user A.B. User B.A from A's account. Required return amount return information for executing remittance of an amount equivalent to the required return amount to B's account is transmitted to the server 10 via the communication I/F 22 (A270).
On the other hand, user B. If returning to B is not selected (A260: NO), the control unit 21 of the terminal 20A terminates the process.

When the required return amount return information is received from the terminal 20A via the communication I/F 14 (S270: YES), the control unit 11 of the server 10 receives the required return amount return information from the user A. User B.A from A's account. A lending/borrowing return process is executed to remit the amount described in the required return amount to B's account (S280). Further, when the borrowing and returning process is successful, the control unit 11 of the server 10 erases the required return amount stored in the storage unit 15 .

After that, the control unit 11 of the server 10 transmits the lending/borrowing return information including the execution result of the remittance processing executed by the lending/borrowing return processing to the accounts of the sender and the remittee of the required return amount return information through the communication I/F 14 . is transmitted to each terminal 20 corresponding to (S290). Then, the control unit 11 of the server 10 terminates the process.

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

Upon receiving the lending/borrowing return 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 the lending/borrowing return information (A280). Then, the control unit 21 of the terminal 20A terminates the process.

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

When the lending/borrowing 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 display unit 24 to display the lending/borrowing return information (B240). Then, the control unit 21 of the terminal 20B terminates the process.

<Effect of the third embodiment>
According to this embodiment, settlement can be performed based on the first user account of the first user and the second user account of the second user linked with the first user account. Also, based on this settlement, money can be transferred from the first user account to the second user account. Since the second user account is the account of the second user, settlement based on the first account of the first user and the second account of the second user associated with the first account can be realized.

Note that the second user account is the account of the second user.
Therefore, remittance to the second user account may be regarded as remittance to the second user, or may be regarded as remittance to the terminal of the second user.

In addition, in this embodiment, in the account linked settlement, the shortfall of the first user account is paid by at least the second user account. In addition, the lending and borrowing information (not limited, but an example of the first information) shows a configuration including information on the required return amount (not limited, but an example of the amount paid by the second account instead 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 used to pay for the shortfall of the first account. As a result, when the balance of the first account is insufficient and the entire amount to be paid cannot be paid, the second account can be made to pay the insufficient amount. Also, the first user may 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.

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

Further, in the above, the account-linked settlement may be made such that the payment by the first user account and the payment for the shortfall of the first user account are made by at least the second user account.
As an example of the effect of the embodiment obtained by such a configuration, in the first settlement, payment is also made by the first account, but at least the second account is used to make the payment for the shortfall of the first account. can be done.

Further, in the above description, the cooperation balance shortage information (not a limitation, but an example of the first information) is received by the communication I/F 22 of the terminal 20 via the server 10 .
As an example of the 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, user A. who had the shortfall paid in advance. A actively sends the required return amount to user B.A. Although the case of returning to B is shown, it is not limited to this. As an example and not a limitation, user B., who is a cooperation member who paid for (lent out) the required return amount. User A. It may be possible to charge A for the required return amount, or it is not necessary to do so.

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

The left side of FIG. 3-6 is, by way of example and not limitation, an example of a notification screen that is transitioned to by tapping the "Notice" icon from the main menu of the payment application. It is also possible to transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is transmitted to and displayed on the terminal 20B.

In the notification information display area NTR3 of the notification screen, cooperative settlement result information CT4 based on execution of the cooperative payment and advance payment information CT5 based on the occurrence of payment by the cooperative payment are displayed.

The linked settlement result information CT4 includes user B. The amount "3,500 yen" paid by B, the payment date and time, the fact that the payment was completed using the linked wallet, and the payment destination "XX musical instrument" are displayed. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
At the bottom of the linked settlement result information CT4, there is displayed a detail confirmation button indicated by characters "confirm details" for confirming the details of payment. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 3-6 is displayed.

In the advance payment information CT5, the payment made by the user A.I. A display indicating that "1,250 yen" has been paid is displayed. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
Below that is a detail confirmation button indicated by the words "Confirm details" for confirming payment details. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 3-6 is displayed.
Below the payment information CT5, user B. B is user A.B. A payment amount request button BT7 for requesting a refund of the "1,250 yen" that was paid in advance for A is displayed.

The right side of FIG. 3-6 is an example of a cooperative payment result display screen displayed on the display unit 24 of the terminal 20B.
In this screen, in the member payment result display area MRR2, instead of the advance payment refund button BT6, the user A. User B.A. A payment amount request button BT7 for prompting the return of "1,250 yen" paid by B is additionally displayed.

When the billing amount button BT7 is tapped, the user A. is sent to the terminal 20A. A's e-money account to user B.A. Information prompting remittance of "1,250 yen" for payment to B's electronic money account is transmitted and displayed on the display unit 24 of the terminal 20A.
Note that user A. If the electronic money account balance of user A is greater than the amount paid for, user A. A's e-money account to user B.A. The remittance of the advance to B's electronic money account may or may not be performed.

Further, when the refund for the advance has been completed, the button operation may be invalidated by graying out the display mode of the payment amount request button BT7 in the subsequent display, or it is not necessary to do so.

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

When the control unit 21 of the terminal 20B executes step B220, the required return amount is sent to the user A. The display section 24 displays a screen for selecting whether or not to request (promote) the return from A (B223).

Based on the user's operation on the input/output unit 23 of the terminal 20B, the user A. If it is selected to prompt user A to return the required return amount (B223: YES), the control unit 21 of the terminal 20B instructs the user A.A to return the required amount. User B.A from A's account. Required return billing information for requesting remittance of an amount equivalent to the required return amount to B's account is transmitted to the server 10 via the communication I/F 22 (B226).

User A. If prompting A to return the required amount is not selected (B223: NO), the control unit 21 of the terminal 20B advances the process to step B230.

After executing the step of S260, the control unit 11 of the server 10, when receiving the required return amount billing information from the terminal 20B via the communication I/F 14 (S263: YES), uses the communication I/F 14 to request the user A who is the reminder destination. . The required return amount demanding information for demanding the return of the required return amount is transmitted to A's terminal 20A (S266). After that, the steps after S270 are executed.

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

After executing step A250, the control unit 21 of the terminal 20A causes the display unit 24 to display the required return amount reminder information when receiving the required return amount reminder information from the server 10 via the communication I/F 22 (A253: YES). (A256). After that, the control unit 21 of the terminal 20A advances the process to step A260.

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

After step A256 is executed, if "A260: NO" is returned, the process returns to step A256, and user A.A. A may or may not be made to notify repeatedly. Further, step A256 may be executed at regular intervals to continue reminding, or it may not be so.

<Third modification (2)>
In the third embodiment, user A. who executes code settlement. Although the electronic money account balance of A's account is less than the equal payment amount, it is not limited to this. By way of example and not limitation, user B.B. If the electronic money account balance of user A.B is less than the equal payment amount, A's account allows user B. The shortfall of B's ability to pay (that is, the equal payment amount - user BB's ability to pay) may be borne, and the payment using the linked wallet may or may not be made.

<Display screen>
FIG. 3-9 is an example of transition of screens displayed on the terminal 20B until the account linked settlement is completed. This diagram shows the transition of screens displayed on the terminal 20A in FIG. 3-2 until the account-linked settlement is completed, viewed from the terminal 20B side.
The left side of FIG. 3-9 shows a linked payment confirmation screen including a warning mark and the words "Insufficient balance" as in the center of FIG. 3-2.

In addition, at the bottom of the linked payment confirmation screen, user A.A. User B. A's remaining payment capacity of '1,000 yen' is short of the required amount for advance payment, ie, '2,250 yen - 1,250 yen = 1,250 yen'. An advance payment button BT10 indicated by the characters "pay the shortfall" for B to pay is displayed.

When the advance payment button BT10 is tapped, the display transitions to the linked payment confirmation screen in the center of FIG. 3-9.
In this screen, in the paying member confirmation area PMR2, the user B. B's ability to pay has increased to "3,500 yen", which is the sum of "2,250 yen" for equal installment payment and "1,250 yen" for advance payment. Along with this, the cooperative payable amount in the payment amount confirmation area PIR2 is increased to "4,500 yen", the characters "insufficient balance" disappear, and the characters "payable" are displayed.

Also, at the bottom of the cooperative payment confirmation screen, a cooperative payment execution button BT11 indicated by the characters "payment" for executing payment according to the current payment capacity is displayed.

When the cooperative payment execution button BT11 is tapped, the display transitions to the cooperative payment result display screen on the right side of FIG. 3-9.
This screen displays the text "Payment complete" indicating that the payment using the linked wallet has been completed, as well as the icon image of "XX Gakki" to which the payment will be sent, its name, and the payment date and time. It is A member payment result display area MRR3 is displayed at the bottom of the cooperative payment result display screen.

As an example and not by way of limitation, member payment result display area MRR3 shows user A.A. It is displayed that A has paid the remaining payment capacity of "1,000 yen" and as a result, the electronic money account balance has become "0 yen". Also, user B. It is displayed that B has paid the remaining payment capacity of "3,500 yen" and as a result, the electronic money account balance has become "2,500 yen".

Also, user A. User B.A. B is user A.B. In addition to A, a billing amount billing button BT12 for billing "1,250 yen" paid in advance is displayed.
The behavior when the payment amount request button BT12 is tapped can be configured in the same manner as when the payment amount request button BT7 is tapped in FIG. 3-6.

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

The left side of FIG. 3-10 is, by way of example and not limitation, an example of a notification screen transitioned by tapping the "Notice" icon from the main menu of the payment application. It is also possible to transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is transmitted to and displayed on the terminal 20A.

In the notification information display area NTR3 of the notification screen, cooperative settlement result information CT4 based on execution of the cooperative payment and advance payment information CT5 based on the occurrence of payment by the cooperative payment are displayed.

The linked settlement result information CT4 includes user A. The amount "1,000 yen" paid by A, the payment date and time, the fact that the payment was completed using the linked wallet, and the payment destination "XX musical instrument" are displayed. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
At the bottom of the linked settlement result information CT4, there is displayed a detail confirmation button indicated by characters "confirm details" for confirming the details of payment. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 3-10 is displayed.

In the advance payment information CT5, user B.B. A display is displayed indicating that "1,250 yen" was charged to B. Also, on the upper right is the user A. A and user B. An icon indicating that payment has been made with B's linked wallet is displayed.
Below that is a detail confirmation button indicated by the words "Confirm details" for confirming payment details. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 3-10 is displayed.
At the bottom of the payment information CT5, user A. A is user B.A. A refund button BT6 for returning the "1,250 yen" paid by B is displayed.

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

<Processing>
For the processing in this case, as an example and not as a limitation, in step A210 in FIG. The shortfall (i.e., equal payment amount - user BB's ability to pay) is calculated by user A.B. 3-5 can be executed in the same manner as in FIGS. is.

<Third modification (3)>
In the third embodiment, user A. who executes code settlement. An example has been shown in which if the electronic money account balance of A's account is less than the equal payment amount, the shortfall is paid for by another linked account, but the present invention is not limited to this. By way of example and not limitation, the shortfall is transferred from the account of the external financial institution to user A. You may or may not charge A's account.

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

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

When the charge button BT8 is tapped instead of the advance request button BT4, the screen shown in the center of FIG. 3-11 is displayed as an example and not as a limitation.
In this screen, a charge display area CGR1 rises from the lower side of the cooperative payment confirmation screen and is displayed in an overlapping manner.

In the charge display area CGR1, "charge" is displayed as an operation guide for the user, and a bank account display area is provided below it.

In this example, in the bank account display area, the bank name "XX bank" is displayed together with the logo of "XX bank" (XX BANK). Below that, "ordinary deposit 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, there is provided 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 scheduled charge amount. Further, below it, there is a first charge button for inputting the charge amount to the charge amount input area. A second charge button for adding to the planned charge amount and a third charge button for adding "10,000 yen" to the planned charge amount are displayed side by side.

In addition, a planned charge amount deletion button is displayed on the left side of the planned charge amount input area. When the planned charge amount deletion button is tapped, the amount in the planned charge amount input area is deleted and the planned charge amount input is entered. "0 Yen" is displayed in the area.

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

Note that when the planned charge amount input area is tapped, a ten-key area for entering the planned remittance amount is displayed at the bottom of the display unit 24, and the planned remittance amount is entered in detail based on the input to the ten-key area. is also possible.

The right side of FIG. 3-11 is an example of the linked payment confirmation screen when the charge execution button BT9 is tapped.
In this screen, user A.A. As the balance of the electronic money account of A increases by "2,000 yen", the user A.A. A's ability to pay has increased to 2,250 yen. Along with this, the cooperative payable amount in the payment amount confirmation area PIR1 is increased to "4,500 yen", and the characters "Insufficient balance" disappear and the characters "Payable" are displayed.

Also, at the bottom of the cooperative payment confirmation screen, a cooperative payment execution button BT5 indicated by the characters "payment" for executing payment according to the current payment capacity is displayed.

<Processing>
As for the processing in this case, as an example and not as a limitation, in step A210 of FIG. user A.A from an external financial institution account registered by A.A. The charge request information for charging the account of A for the shortfall of the payment capacity is transmitted to the server 10 via the communication I/F 22 . Then, in step S230 in FIG. 3-4, the control unit 11 of the server 10 transfers the shortfall of the payment capacity from the account of the external financial institution to the user A.A. You can charge A's account.

<Third modification (4)>
In the third embodiment, the terminal 20A receives the cooperation balance shortage information (as an example, not as a limitation, an example of the first information) from the server 10, but it is not limited to this. By way of example and not limitation, the linked balance shortage information may or may not be received from another member's terminal 20 (terminal 20B as an example and not limitation).

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

If the cooperative payable amount is less than the planned settlement amount (S210: YES), the control unit 11 of the server 10 provides cooperative payable amount shortage information indicating that the cooperative payable amount is insufficient and payment will fail if this situation continues. is transmitted to each terminal 20 of the cooperation member via the communication I/F 14 (S222).

When the communication I/F 22 receives the cooperative payable amount shortage information from the server 10 (B180: YES), the control unit 21 of the terminal 20B receives the information from the user A.A. User B.A's shortfall in payment capacity It is determined whether or not the account of B can pay, and if it can be paid, information on the lack of cooperation balance is transmitted to the terminal 20A through the communication I/F 22 (B190).

If the cooperation payable amount shortage information is not received (B180: NO), the control unit 21 of the terminal 20B does not execute step B190.

Note that when executing steps B180 and B190, the control unit 21 of the terminal 20B may cause the display unit 24 to display that a situation arises in which an advance is required to pay for the cooperative wallet. The process may proceed without B being notified.

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

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

After the steps of FIGS. 3-12 are executed, the processing of each step of FIGS. 3-5 is subsequently executed.

<Fourth embodiment>
In the third embodiment, the case where there are two cooperation members has been described, but this is not the only option.
In this embodiment, a case where there are three or more collaborating members will be described.

The content described in the fourth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

When three or more collaborating members operate, two processing methods are conceivable as an example and not as a limitation.
(1) A method of simply increasing the number of linked accounts registered in linked account data (2) A method of introducing a group pre-configured with multiple linked members

In the method (1), for example and not limitation, the federated account data of the first federated wallet management database 157A can store user accounts of three or more federated members.
It should be noted that the same applies to the case of using three or more user accounts of arbitrary cooperation members instead of the user accounts of each of three or more cooperation members.

The method (2) will be described in detail below.
Here, by way of example and not limitation, a group including a plurality of users is formed in the payment application, and the user accounts of each of the users included in this group (hereinafter referred to as "group members") are linked to account linking. A case of making a payment will be explained.
Also, here, a case is illustrated in which all group members included in the same group are set as cooperation members.

FIG. 4A is a diagram showing an example of information and the like stored in the storage unit 15 of the server 10 in this embodiment.
The storage unit 15 stores, as a non-limiting example, a payment application management processing program 151 executed as payment application management processing, account registration data 153, an account management database 155, a linked wallet management database 157, a group management database 159 are stored.

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

Each group management data stores, by way of example and not limitation, a group ID, a group name, and group member data.
A group ID is information used to identify a group (identification information for identifying a group).
This group ID is preferably a unique value for each group, and as an example and not a limitation, the server 10 sets and stores a unique value (unique value) for each group.

The group name is the name of this group, and as an example and not as a limitation, the name entered by the user or the like who creates the group at the terminal 20 is registered by the server 10 .

Group member data is data relating to user accounts of group members included in this group, and for example and not limitation, group member application IDs and group member user names are associated and stored.

Note that the group member data may or may not store multiple accounts belonging to the same group member. Also, the number of accounts stored in the group member data is not limited to 3 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. 4-3 is a diagram showing a data configuration example of the second cooperative wallet management database 157B, which is an example of the cooperative wallet management database 157. As shown in FIG.
The second linked wallet management database 157B stores linked wallet management data as management data for each linked wallet.

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

A group ID is information for identifying a group that uses this linked wallet, and is information for identifying a linked wallet that is used for account linked settlement in units of groups stored in the group management database 159 . That is, a group ID can define a uniquely used federated wallet.

The group name is the name of the group that uses this cooperative wallet, and as an example and not a limitation, the group name corresponding to the group ID stored in the group management data is associated and stored.

The settlement history data is the same as the first linked wallet management database 157A.

That is, the method (2) is similar to the method (1), with the linked wallet ID in the linked wallet management data of the first linked wallet management database 157A as the group ID, and the linked account data in the group management database 159 as group member data. It can be said that they are replaced by .

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

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

On this screen, in the current location display area CLR1, the characters "coordinated wallet" are displayed to indicate that the function of the linked wallet is being used. The prompt "Please select a group" is displayed.

Below that, groups to which the user of this terminal (in this case, user A.A) belongs are displayed in a row for each row. Each group entry shows, by way of example and not limitation, an icon for the group, the name of the group, and the number of members that make up the group.

As an example, not a limitation, when a group with the group name "Band Friends" (hereinafter referred to as a group "Band Friends") is tapped as a group that performs wallet cooperation, as a non-limiting example, as shown in Fig. 4-5 Move to the screen as shown.
The left side of FIG. 4-5 is an example of the main screen of the cooperative wallet, and in this screen, the electronic money account balance of each user of the group "band friends" is displayed in the cooperative member information display area MIR1.

As a non-limiting example, when the code reader icon IC2 is touched on this screen, the control unit 21 of the terminal 20A reads the terminal reading code with the terminal 20A when performing the "store presentation type" code payment. to start the application code reader.

An example of the application code reader screen is shown in the center of FIG. 4-5.
On this screen, under the current position display area CLR1, characters of "code reader", which is the function currently being executed, are displayed. A code reading area CR1 for reading the payment shop code is displayed in the center of the screen.

The right side of FIG. 4-5 is a diagram showing an example of a payment amount input screen displayed when information is acquired by decoding from the payment store code read in the center of FIG. 4-5.

On this payment amount input screen, the name "XX musical instrument" is displayed together with the icon image of "XX musical instrument" which is the recipient of the payment amount. Below that, a payment amount display area PR1 for displaying the input payment amount is displayed. Here, "4,500 yen" is input and displayed as the payment amount. At the left end of the payment amount display area PR1, an erase button indicated by a circled x mark for erasing the payment amount is displayed.
A keyboard for inputting the payment amount is displayed at the bottom of the screen, and a payment button BT1 indicated by the characters "payment" for executing payment with the payment amount entered in the payment amount display area PR1. is displayed.
When the payment button BT1 is tapped on the payment amount input screen shown on the right side of FIG. 4-5, code payment using the cooperative wallet is executed.

Note that 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 the display unit 24 of the terminal 20A. On the code payment screen, a code (code image) sent from the server 10 and received by the terminal 20 is displayed as a cooperative wallet payment code, which is a code used for making a payment in the "user presentation type". A one-dimensional payment code, represented by a bar code as an example and not by way of limitation, and a two-dimensional payment code, represented by a QR code as an example and not by way of limitation, are displayed. User A. of terminal 20A. A can also 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 store code reader read the payment code.

FIG. 4-6 is a diagram showing an example of screen transition of the cooperative payment confirmation screen when code payment using the cooperative wallet is executed.
On the left side of FIG. 4-6, a payment amount confirmation area PIR1 is displayed below the current location display area CLR1 as an example, not limitation, as a cooperative payment confirmation screen. In the payment amount confirmation area PIR1, as an example and not limitation, an icon image of "XX musical instrument" which is the destination of the payment amount, its name "XX musical instrument", and the payment amount "4,500 yen" are displayed. ing. Under the payment amount, the current cooperative payable 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 cooperative payable amount is less than the payment amount.

In addition, under the payment amount confirmation area PIR1, the name of the cooperative wallet group used for payment, ie, "band friends" is displayed together with an icon. Below that, a payment member confirmation area PMR1 is displayed for confirming the payment burden status of each member of the group "Bandmates".

In the payment member confirmation area PMR1, as an example and not a limitation, for each member, an icon, a user name, an amount of payment (payment capacity), and an electronic money account balance are displayed in association with each other for each line. ing. In addition, a warning mark is superimposed on the upper left of the icon for a user whose payment capacity is less than the equal payment amount.

In this example, the equal payment amount is "4,500 yen/3=1,500 yen".
User A. A warning mark is displayed on the upper left of the icon of A, indicating that the payment capacity is "1,000 yen". In this case, the cooperative payable amount is less than the payment amount, and the payment cannot be made as it is.
Therefore, at the bottom of the cooperative payment confirmation screen, out of the equal payment amount of "1,500 yen", the amount required for advance payment "1,500 yen - 1,000 yen =" is insufficient for the payment capacity of "1,000 yen". 500 yen" by user A. A repayment request button BT4 is displayed, which is indicated by characters of "get paid by another member" for executing payment by having another member other than A pay the bill.

The center of FIG. 4-6 is an example of a linked payment confirmation screen when the advance request button BT4 is tapped.
In this screen, instead of the paying member confirmation area PMR1, a list of members who can be paid on behalf of the member is displayed, and a payment member selection area PSR1 for selection is displayed.

In the reimbursement member selection area PSR1, the name of the member who can reimburse and the balance of the electronic money account are displayed for each row under the words "Please select the member to be reimbursed." It is In this example, user B. is a member who can pay "2,000 yen", which is the equal payment amount of "1,500 yen" plus the required amount for advance payment of "500 yen". B and user C.B. C is displayed. In this example, user B. The electronic money account balance of user C.B is "3,000 yen". C's electronic money account balance is "6,000 yen".

By way of example and not limitation, user C.I. When C is tapped and selected as a payer, the display transitions to the linked payment confirmation screen on the right side of FIG. 4-6.
In this screen, in the paying member confirmation area PMR1, the user C.I. C's ability to pay has increased to '2,000 yen', which is the amount '1,500 yen' to be paid in equal installments plus the required amount '500 yen' for advance payment. Along with this, the cooperative payable amount in the payment amount confirmation area PIR1 increases to "4,500 yen", the words "insufficient balance" disappear, and the words "payable" are displayed instead.

Also, at the bottom of the cooperative payment confirmation screen, a cooperative payment execution button BT5 indicated by the characters "payment" for executing payment according to the current payment capacity is displayed.

In addition, in the center of FIG. 4-6, it may be possible to select a plurality of repayers instead of one, or it is not necessary to do so. When a plurality of people are selected for payment, the required amount for payment may be equally divided, or, as a non-limiting example, the payment may be proportionally divided according to the balance of the electronic money account.

FIG. 4-7 is an example of screen transition when the cooperative payment execution button BT5 is tapped on the cooperative payment confirmation screen on the right side of FIG. 4-6.
On the left side of FIG. 4-7, a cooperative payment result display screen is displayed for confirming the payment result using the cooperative wallet.

At the top of the linked payment result display screen, along with the text "Payment completed" indicating that the payment using the linked wallet has been completed, the icon image of "XX musical instrument", which is the destination of the payment amount, and its name "XX musical instrument” and the payment date and time “2020-07-24/12:17:08” are displayed.

Also, at the bottom of the cooperative payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of each member of the cooperative wallet regarding this payment.
The member payment result display area MRR1 displays, for each member, the name of the user who has paid, the amount paid as the remaining payment capacity, and the electronic money account balance after payment.

As an example and not by way of limitation, member payment result display area MRR1 shows user A.A. It is displayed that A has paid the remaining payment capacity of "1,000 yen" and as a result, the electronic money account balance has become "0 yen". Also, user B. It is displayed that B has paid the remaining payment capacity of "1,500 yen" and as a result, the electronic money account balance has become "1,500 yen". Also, user C.I. It is displayed that C paid the remaining payment capacity of "2,000 yen" and as a result, the electronic money account balance became "4,000 yen".

Also, user C.I. In item C, user A.C. A is user C. An advanced amount refund button BT6 for returning the "500 yen" paid by C is additionally displayed.

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

In the notification information display area NTR2 of the notification screen, cooperative settlement result information CT2 based on execution of the cooperative payment and advance payment information CT3 based on the occurrence of the cooperative payment are displayed.

The linked settlement result information CT2 includes user A. The amount "1,000 yen" paid by A, the payment date and time, the fact that the payment was completed using the linked wallet, and the payment destination "XX musical instrument" are displayed. Also, in the upper right, the icon of the group "Band Friends" to which the linked wallet is applied is displayed.
At the bottom of the linked settlement result information CT2, a detail confirmation button indicated by the words "confirm details" is displayed for confirming the details of the payment. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the left side of FIG. 4-7 is displayed.

In addition, the linked settlement result information CT2 includes the user A. Instead of "1,000 yen", which is the amount paid by A, "4,500 yen", which is the total payment amount paid for "XX instrument", may be displayed, or not. good. Alternatively, user A. Both the amount paid by A and the total amount paid may or may not be displayed. The amount paid by other users may be displayed in addition, or may not be displayed.

In the advance payment information CT3, user C.I. A display indicating that "500 yen" was paid on C is displayed. Also, in the upper right, the icon of the group "Band Friends" to which the linked wallet is applied is displayed.
Below that is a detail confirmation button indicated by the words "Confirm details" for confirming payment details. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the left side of FIG. 4-7 is displayed.
At the bottom of the payment information CT3, user A. A is user C. A refund button BT6 for returning the "500 yen" paid for by C is displayed.

When the advance payment amount refund button BT6 is tapped, user A. A's e-money account to user C.A. Remittance of "500 yen" for payment to C's electronic money account is executed. Note that user A. If A's electronic money account balance is less than the amount paid and remittance cannot be executed, the button operation may be invalidated by graying out the display mode of the payment amount refund button BT6, or otherwise. good. Also, user A. When A's electronic money account balance is less than the amount to be paid, and the advance payment amount refund button BT6 is tapped, the screen may or may not be changed to a screen prompting charging from the bank account.

When the refund for the paid amount is completed using the refund button BT6, the button operation may be invalidated by graying out the display mode of the refund button BT6 in the subsequent display, or otherwise. may

In addition, in the notification information display area NTR2, the cooperative settlement result information CT2 and the advance information CT3 may be collectively displayed as one piece of information, or may not be displayed in such a manner.

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

The left side of FIG. 4-8 is, by way of example and not limitation, an example of a notification screen transitioned by tapping the "Notice" icon from the main menu of the payment application. It should be noted that it is also possible to transition to the notification screen by, for example, tapping a payment completion notification (not shown) that is transmitted to and displayed on the terminal 20C.

In the notification information display area NTR4 of the notification screen, cooperative settlement result information CT4 based on execution of the cooperative payment and advance payment information CT5 based on the occurrence of the cooperative payment are displayed.

User C.I. "2,000 yen" which is the amount paid by C, the payment date and time, the fact that the payment was completed using the linked wallet, and the payment destination being "XX musical instrument" are displayed. Also, in the upper right, the icon of the group "Band Friends" to which the linked wallet is applied is displayed.
At the bottom of the linked settlement result information CT4, there is displayed a detail confirmation button indicated by characters "confirm details" for confirming the details of payment. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 4-8 is displayed.

In the advance payment information CT5, the payment made by the user A.I. A display indicating that "500 yen" has been paid in advance is displayed. Also, in the upper right, the icon of the group "Band Friends" to which the linked wallet is applied is displayed.
Below that is a detail confirmation button indicated by the words "Confirm details" for confirming payment details. When this detail confirmation button is tapped, by way of example and not limitation, the linked payment result display screen on the right side of FIG. 4-8 is displayed.
Under the payment information CT5, user C.I. C is user A.C. A payment amount request button BT7 for requesting a refund of the "500 yen" paid in advance for A is displayed.

The right side of FIG. 4-8 is an example of the linked payment result display screen displayed on the terminal 20C.
In this screen, in the member payment result display area MRR2, instead of the advance payment refund button BT6, the user A. User C.A. In addition, an advance amount request button BT7 for prompting the return of the "500 yen" paid by C is displayed.

When the billing amount button BT7 is tapped, the user A. is sent to the terminal 20A. A's e-money account to user C.A. Information prompting remittance of "500 yen" for payment to C's electronic money account is transmitted and displayed on the display unit 24 of the terminal 20A.
Note that user A. If the electronic money account balance of user A is greater than the amount paid for, user A. A's e-money account to user C.A. Remittance of the payment to C's electronic money account may be performed, or may not be performed.

Further, when the refund for the advance has been completed, the button operation may be invalidated by graying out the display mode of the payment amount request button BT7 in the subsequent display, or it is not necessary to do so.

<Processing>
For the processing in this embodiment, as a non-limiting example, apply the terminal 20 of the group member who pays using the cooperative wallet to the processing of the terminal 20A, and apply the terminal 20 of the other group members to the processing of the terminal 20B. 3-4 to 3-5 can be implemented in the same manner as in FIGS.

<Effects of the fourth embodiment>
In this embodiment, the account-linked settlement is performed by the group member's first user account (not limited, but an example of the first account) and the other group member's second user account (not limited, the second account example) and a fourth user account of a group member other than these (not limited to, but an example of a fourth account linked with the first account and the second account).
As an example of the effect of the embodiment obtained by such a configuration, payment is made not only by the first account and the second account, but also by the fourth account associated with the first account and the second account. be able to.

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

Moreover, in the above, the payment for the shortfall of 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 shortfall of the first account can be paid only by the second account without using the fourth account.

Further, in the above, the second user account to pay the shortfall of the first user account may be determined based on the electronic money account balance of the second user account.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to determine the second account to pay the shortfall of the first account based on the balance of the second account. By way of example and not limitation, the second account with the highest balance can be determined to be the second account that pays the first account's shortfall.

Further, in the above, the second user account to pay the shortfall of the first user account may be selected based on the first user's input to the terminal.
As an example of the effect of the embodiment obtained by such a configuration, the second account for paying the shortfall of the first account can be selected by a simple method of inputting to the terminal by the first user.

<Fourth Modification (1)>
In the fourth embodiment, when another linked account is used to pay for the shortfall, the linked balance replenishment process is executed without requesting approval from the user of the account for which the payment is to be made, but the present invention is not limited to this. By way of example and not limitation, the need to pay for the shortfall may or may not require the approval of the user whose account the payment is being made for.

<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 payment in the above example.
In this figure, user C. who pays the advance in the process of transitioning from the center of FIG. 4-6 to the right side of FIG. 4-6. Approval from C is required. Specifically, on the screen displayed on the display unit 24 of the terminal 20A on the left side of FIG. 4-9, the user C.I. When C is selected, a notification screen as shown in the center of FIG. 4-9 is displayed on the display unit 24 of the terminal 20C. On this notification screen, user A. Reimbursement request information indicating that A has requested reimbursement is displayed.

The payment request information includes, as a non-limiting example, an approval button BTa for approving the payment and a refusal button BTb for rejecting the payment, in addition to information on details of the payment. When the approval button BTa is tapped, information indicating approval is transmitted from the terminal 20C to the server 10, and processing relating to advance payment is executed. As a result, the screen shown on the right side of FIG. 4-9 is displayed on the display section 24 of the terminal 20A as the screen on the right side of FIG. 4-6.

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

When the communication I/F 14 receives the balance replenishment request information from the terminal 20A, the control unit 11 of the server 10 receives the information from the user A.A. The balance for requesting the terminal (terminal 20B as an example, not limitation) of the user (user BB as an example, not limitation) who bears the shortfall of A's ability to pay to replenish the shortage of the ability to pay Replenishment request information is transmitted via communication I/F 14 (S224).

When the 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 receives the information from the user A.A. The display section 24 displays a screen for selecting whether or not to bear the shortfall of A's remaining payment capacity (B160).

If the user selects to bear the shortfall based on the user's operation on the input/output unit 23 of the terminal 20B (B160: YES), the control unit 21 of the terminal 20B receives the balance replenishment authorization information for authorizing the burden of the shortfall. is transmitted to the server 10 via the communication I/F 22 (B170).

If the balance replenishment request information is not received (B150: NO), the control unit 21 of the terminal 20B skips steps B160 and B170. Further, when not paying the shortfall is selected (B160: NO), the control unit 21 of the 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 coordinated balance replenishment processing based on the received balance replenishment request information (S230). . If the balance replenishment authorization information is not received, the control section 11 of the server 10 does not execute step S230.

After the steps of FIGS. 4-11 are executed, the processing of each step of FIGS. 3-5 is subsequently executed.

In this modification, the second user account that pays the shortfall of the first user account is the second user account based on the input to the own terminal 20 by the user of the own terminal 20 (not limited, but an example of the first user) is selected, the configuration determined based on the permissions of the second user of the second user account.
As an example of the effect of the embodiment obtained by such a configuration, even if the second account is selected based on the input to the terminal by the first user, as an example, not as a limitation, the second account of the second account Without the user's permission, the second account may not be determined to be the second account to pay for the shortfall of the first account. As a result, it is possible to prevent the second account from paying the shortfall of the first account against the second user's will.

<Fourth Modification (2)>
As described in the fourth embodiment, all group members included in the group may be cooperating members, but some group members included in the group may also be cooperating members. In other words, within the same group, group members who participate in account-linked settlement and group members who do not participate in account-linked settlement can be divided.
This is because some users, even if they belong to the same group, may not wish to participate in account-linked settlement.

As an example of the effect of the modification obtained by such a configuration, it is possible to select a user who performs settlement by linking a plurality of accounts, thereby improving convenience for the user.

<Fifth embodiment>
In the fourth embodiment, it is assumed that there is only one linked member (or one linked account with insufficient payment capacity) in account linked settlement. However, this is only an example.
In this embodiment, a case will be described in which the payment capacity of a plurality of cooperative members (or a plurality of cooperative accounts) is insufficient when account-linked settlement is executed.

The content described in the fifth embodiment can be applied to each of the other embodiments and other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

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

On the left side of FIG. 5-1, a payment amount confirmation area PIR3 is displayed below the current location display area CLR1 as an example, not limitation, as a cooperative payment confirmation screen. Below the payment amount in the payment amount confirmation area PIR3, "3,000 yen", which is the current cooperative payable amount, is displayed. Also, in the payment amount confirmation area PIR3, a warning mark and the words "insufficient balance" are displayed based on the fact that the current cooperative payable amount is less than the payment amount.

In the paying member confirmation area PMR3, the user A. A and user B. A warning mark is displayed on the upper left of icon B, indicating that the remaining payment capacities are "1,000 yen" and "500 yen", respectively.

At the bottom of the cooperative payment confirmation screen, user A.A. A's remaining payment capacity of '1,000 yen' is not enough to pay up front, and user B.A needs '1,500 yen - 1,000 yen = 500 yen'. User A. B's ability to pay "500 yen" is short of the required amount for advance payment "1,500 yen - 500 yen = 1,000 yen". A and user B. A payment request button BT4 is displayed for asking another member other than B to pay for the payment.

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

In the reimbursement member selection area PSR3, under the words "Please select a member for reimbursement" prompting the user to select the reimbursement person, the equal payment amount "1,500 yen" and the reimbursement required amount "500 yen" are displayed. and "1,000 yen" are added, and user C.C. C is displayed.

User C.I. When C is tapped and selected as a payer, the display transitions to the linked payment confirmation screen on the right side of FIG. 5-1.
In this screen, in the paying member confirmation area PMR3, the user C.I. C's ability to pay has increased to "3,000 yen" by adding the total amount "1,500 yen" required for advance payment to the equal payment amount "1,500 yen". Along with this, the cooperative payable amount in the payment amount confirmation area PIR3 is increased to "4,500 yen", the words "insufficient balance" disappear, and the words "payable" are displayed instead.
In addition, a cooperative payment execution button BT14 is displayed at the bottom of the cooperative payment confirmation screen.

FIG. 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 FIG. 5-1.

By way of example and not limitation, the member payment result display areas of these linked payment result display screens include user A.A. It is displayed that A has paid the remaining payment capacity of "1,000 yen" and as a result, the electronic money account balance is "0 yen". and user B. It is displayed that B has paid the remaining payment amount of "500 yen" and as a result, the electronic money account balance is "0 yen". Also, user C.I. It is displayed that C has paid the remaining payment capacity of "3,000 yen" and as a result, the electronic money account balance is "3,000 yen".

In the member payment result display area MRR5 of terminal 20A, user C.I. In item C, user A.C. A is user C. A refund button BT15 for returning the "500 yen" paid by C is displayed.
In the member payment result display area MRR6 of terminal 20B, user C.I. In the item of C, the user B.C. B is user C.B. A refund button BT16 for returning the "1,000 yen" paid by C is displayed.
User A. is displayed in member payment result display area MRR7 of terminal 20C. User C.A. C is user A.C. When the user B.A pushes the advance payment request button BT17 for requesting the return of the "500 yen" paid for by the user B.A. User C.B in item B. C is user B.C. A payment amount request button BT18 for requesting the return of "1,000 yen" paid for B is displayed respectively.

The functions of the advance amount refund button and the advance amount request button can be configured in the same manner as the advance amount refund button BT6 and the advance amount request button BT7.

FIG. 5-3 is 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 FIG. 5-1.

In FIG. 5-3, the member payment result display area MRR5 of the terminal 20A displays user C.I. In item C, user A.C. A and user B. B is user C.B. A refund button BT20 for returning the "1,500 yen" paid by C is displayed. Also, user B. In item B, user A.B. A is user B.A. A billing amount button BT19 for requesting the return of the "1,000 yen" paid in advance is displayed on B.

User A. is displayed in member payment result display area MRR6 of terminal 20B. User B.A. B is user A.B. A refund button BT21 for returning the "1,000 yen" paid by A is displayed.

User A. is displayed in member payment result display area MRR7 of terminal 20C. User C.A. C is user A.C. A payment amount request button BT22 for requesting the return of the "1,500 yen" paid for A is displayed.

<Processing>
As for the processing in the present embodiment, as an example and not as a limitation, the processing of FIGS. 3-4 to 3-5 is applied as balance replenishment request information as information for reimbursement of insufficient payment capacity of a plurality of accounts. Since it can be realized in the same way by

<Fifth Modification (1)>
In the fifth embodiment, one of the cooperation members pays for the shortfall in the payment capacity of the other cooperation members, but the present invention is not limited to this.
As an example and not a limitation, the shortfall in the payment capacity that has occurred in a plurality of cooperation members may be distributed among the plurality of cooperation members and paid up front, or may not be so.
In addition, the shortfall of the payment capacity generated in a plurality of linked accounts may be paid on behalf of the plurality of linked accounts, or may not be done in such a manner.

<Sixth embodiment>
In the first to fifth embodiments, a method of realizing account-linked payment by code payment presented at a store has been described. However, this is only an example.
In the sixth embodiment, a method of realizing account-linked settlement by user-provided code settlement will be described.

The content described in the sixth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

FIG. 6-2 shows an example of the system configuration of the store POS system 40. As shown in FIG.
The store POS system 40 is, by way of example and not limitation, a POS system that is introduced and used in a store affiliated with the business operator that operates the server 10, and is, by way of example and not limitation, a store code reader device 50, A code register 60 and a store server 70 are included.

The store code reader device 50 is connected for communication with the code register 60 and the store server 70 via a POS communication I/F 57 (for example, but not limited to, a wired communication I/F or a wireless communication I/F in the store). , the code information displayed on the display unit 24 of the terminal 20 is read. Then, based on the read code information, the payment request information is transmitted to the server 10 through the communication I/F 54, and after the payment is made in the server 10, the information on the payment result is received from the server 10 through the communication I/F 54. .

The store code reader device 50 includes, as a non-limiting example, a control unit 51, an input/output unit 52, a communication I/F 54, a storage unit 55, a POS communication I/F 57, a code reader 58, and a clock unit 59. and

Although it is only an example, the input/output unit 52 includes a display unit 53 and a sound output unit 56 as an example and not a limitation.

The code reader 58 is a code reader for reading a one-dimensional code (one-dimensional code image), a two-dimensional code (two-dimensional code image), and as a non-limiting example, a payment code (payment code image) described later.

As an example and not a limitation, the code register 60 is connected to the store code reader device 50 and the store server 70 via the POS communication I/F 57, and based on the settlement completion notification received by the store code reader device 50 from the server 10, A receipt on which information such as the total amount of sold products and the electronic money balance of the user of the terminal 20 is printed is issued.

Further, as an example and not a limitation, a display may be provided integrally with the code register 60 or separately from the code register 60 and having a display surface facing the customer side.
The code register 60 is a cash register configured to be compatible with payment applications, and can also be called a fixed terminal compatible with payment applications.

The store server 70 stores, as a non-limiting example, store information related to its own store, information related to products sold at its own store, information related to services provided at its own store, and information related to sales of products and provision of services at its own store. Manage various information such as information related to sales. 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 an external device such as the server 10 via the network 30 .

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

<Display screen>
FIG. 6-3 is a diagram showing an example of transition of screens displayed on the display unit 24 of the terminal 20 when the account-linked payment is realized by the "user presentation type" 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, the code payment screen as shown in the center of FIG. 6-3 is displayed on the display section 24 of the terminal 20A.

On this code payment screen, as a code (code information) for performing account linked settlement in the group "band friends", the code transmitted from the server 10 and received by the terminal 20A is displayed in the "user presentation type". A linked wallet payment code is displayed, which is the code used to make the payment. Specifically, a one-dimensional payment code represented by a bar code, by way of example and not limitation, and a two-dimensional payment code represented by a QR code, by way of example and not limitation, are displayed. User A. of terminal 20A. A 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 store code reader read the payment code.

The right side of FIG. 6-3 shows user A.3 in the above. This is a screen displayed on the display unit 24 of the terminal 20A based on A's insufficient payment capacity, and is similar to the screen on the left side of FIG. 4-6 as an example and not a limitation.

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

The control unit 11 of the server 10 generates a cooperative wallet payment token. Then, the control unit 11 of the server 10 generates linked wallet code information, which is code information including the linked wallet payment token. The federated wallet code information includes, by way of example and not limitation, a payment code (image information) that encodes the identifier of the federated wallet payment token as a one-dimensional code (such as a barcode) or a two-dimensional code (such as a QR code).

After that, 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 linked wallet code information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A displays the received linked wallet code information on the display unit 24 (A105). Specifically, as the linked wallet code information, the payment code is displayed on the display unit 24 as an example and not as a limitation.

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 the terminal 20A may or may not display the identifier and expiration date.

Also, if the cooperative wallet payment token expires while the payment code is being displayed, the control unit 21 of the terminal 20A transmits information requesting regeneration of the cooperative wallet payment token to the server 10 via the communication I/F 22. may or may not.
In this case, the control unit 21 of the server 10 regenerates the cooperative wallet payment token and the cooperative wallet code information, and transmits the cooperative wallet code information to the terminal 20A via the communication I/F 14 . When the regenerated linked wallet code information is received from the server 10 by the communication I/F 22, the control unit 21 of the terminal 20A can cause the display unit 24 to redisplay the payment code and the expiration date. can.

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

The control unit 51 of the shop code reader device 50 transmits cooperative payment request information including the shop ID, the planned payment amount, and the read cooperative wallet payment token to the server 10 via the communication I/F 54 as an example and not limitation. (P110).

When the cooperative payment request information is received from the shop code reader device 50 via the communication I/F 14, the control unit 11 of the server 10 calculates the possible cooperative payment amount, and determines whether the calculated cooperative payment possible amount is less than the planned payment amount. It is determined whether or not (cooperation payable amount−scheduled settlement amount<0) (S215).

If the cooperative payable amount−scheduled settlement amount≧0 (S215: NO), the control unit 11 of the server 10 searches for the cooperative wallet ID from the requested cooperative wallet payment token, and for the cooperative wallet, A user-provided cooperative payment process, which is an example of a user-provided account cooperative payment process, is executed (S115).

The user presentation type cooperative payment processing is the same processing as the store presentation type cooperative payment processing.
However, in the user-provided cooperative payment processing, the control unit 11 of the server 10 transmits the payment result information about whether or not the payment of the planned payment amount by the cooperative wallet was successful to the store code reader through the communication I/F 14. It differs in that it is transmitted to the device 50 .

If the cooperative payable amount−scheduled settlement amount<0 (S215: YES), the control unit 11 of the server 10 executes steps S220 and S230, and then executes step S115.

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

Upon receiving the payment result information from the server 10 via the communication I/F 54, the control unit 51 of the store code reader device 50 causes the display unit 53 to display the payment result information, and terminates the process.

In this embodiment, the terminal 20 is configured to connect a first user account (one example of a first account, without limitation) and a second user account linked with the first user account (without limitation, a second account associated with the first account). 2 account), the control unit 21 performs processing related to account-linked settlement (not limited, but an example of processing related to the first settlement).
Also, based on the account-linked settlement, the terminal 20 receives remittance request information (not limited, but an example of first information regarding remittance to the second account) via the communication I/F 22 .
Then, the terminal 20 displays the received remittance request information on the display unit 24 (not a limitation, but an example of the first display based on the first information).
In this case, the terminal 20 receives from the server 10 through the communication I/F 22 linked wallet code information (not limited, but an example of code information) for performing account linked settlement based on the first user account and the second user account. and displays the received linked wallet code information on the display unit 24 . Then, it shows a configuration in which account-linked settlement is performed by the server 10 based on the linked wallet code information displayed on the display unit 24 being read by the store code reader device.
As an example of the effect of the embodiment obtained by such a configuration, based on the first account of the first user of the terminal and the second account associated with the first account, By performing processing by the control unit of the terminal, it is possible to realize the first payment using at least two associated accounts. Also, the first user of the terminal can be notified of the first information regarding the transfer of money to the second account by the first payment. As a result, by way of example and not limitation, the first user may be prompted to transfer money to the second account. Further, the first payment can be realized by a simple method of having a code reader at the store read code information for performing the first payment based on the first account and the second account.

<Seventh embodiment>
In the first to sixth embodiments, the method of prompting remittance each time based on account-linked settlement has been described, but the present invention is not limited to this.
In the seventh embodiment, a method will be described for collectively settlement of advances that have occurred based on a plurality of account-linked settlements. Also, in relation to this, a method of destroying the linked wallet will be explained.

“Discarding the linked wallet” means to make the linked wallet unusable from now on, and to disable the linked wallet for all linked accounts at once.

The content described in the seventh embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

Each linked wallet management data stores, as a non-limiting example, a group ID, a group name, payment history data, and payment history data.

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

The reimbursement history data is data related to reimbursement of money that occurred in each transaction stored in the settlement history data, and as a non-limiting example, transaction ID, reimbursement recipient ID, reimbursement person ID, reimbursement amount, and are stored in association with each other.

The transaction ID stores a transaction ID in which cash is paid for the transaction, among the transaction IDs included in the settlement history data.

The application ID of the user account (hereinafter referred to as "reimbursed person") for which money was paid in advance is stored in the reimbursed person ID.

The application ID of the user account that paid the money (hereinafter referred to as "payer") is stored in the payer ID.

The amount of money paid on behalf of the customer (hereinafter referred to as "amount of money paid on behalf of the customer") is stored.

<Display screen>
FIG. 7B is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Figure 7-2 is the same main screen of the linked wallet as the left side of Figure 4-5, but the display is partially different. Specifically, a history button BT25 for displaying the history of settlements made with the linked wallet of the group "Band Friends" is displayed in the area displaying that it is a linked wallet of the group "Band Friends". .

When the history button BT25 is tapped, the screen transitions to the screen in the center of FIG. 7-2.
On this screen, information on the purchase history of products and services is displayed as information on payments made with the linked wallet of the group "Band Friends". In this example, information on two purchase histories of "XX musical instrument" and "YY studio" is displayed, and each purchase history is associated with a check box. When the collective settlement button BT26 at the bottom of the screen is tapped while the check boxes of purchase histories for which settlement is desired are checked, the checked purchase histories can be collectively settled.

Also, at the bottom of the screen, there is provided a link wallet discard button BT30 containing characters of "discard link wallet" for discarding the link wallet. When this linked wallet discard button BT30 is tapped, the server 10 performs linked wallet discard processing.

In the linked wallet destruction process, the linked wallet data is not deleted from the linked wallet management database 157, but the terminal 20 side or the server 10 side prohibits the execution of the account linkage settlement based on the destroyed linked wallet. may or may not.

The right side of FIG. 7-2 shows an example of a screen displayed when the collective payment button BT26 is tapped with two purchase histories checked in the center of FIG. 7-2.
In this screen, batch payment information for executing batch payment is displayed in a pop-up format in the center of the screen in the center of FIG. 7-2. In this example, the collective settlement information includes user A. A to user B. User A.B remits "500 yen" to user A.B. A to user C. Along with a message indicating that it is necessary to remit "1,000 yen" to C, a "Yes" button to approve this content and make a lump sum payment, and a "No" button to stop the lump sum payment. button is displayed.

When the "Yes" button is tapped, user A. A to user B. Remittance of "500 yen" to user A.B and user A.B. A to user C. Remittance of "1,000 yen" to C is executed.

<Processing>
7-3 to 7-4 show flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A), the processing executed by the control unit 21 of the terminal 20B (the terminal 20 of the user B.B), the server 10 shows an example of processing executed by the control unit 11 of FIG.

When the control unit 11 of the server 10 executes the coordinated balance replenishment process (S230), the reimbursement of the required amount for reimbursement generated in the coordinated balance replenishment process is added to and stored in the payment history data (S235).

When steps A230, B200, and S240 are executed, terminal 20A, terminal 20B, and server 10 execute cooperative wallet settlement processing.

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

On the other hand, if the payment history is recorded (S400: YES), the control unit 11 of the server 10 sends the payment history information including the content of the payment history data to the terminal 20A, which is the terminal of the cooperation member, via the communication I/F 14. and the terminal 20B (S410).

When the 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 displays the received payment history information on the display unit 24 (A410). When the payment history information is not received (A400: NO), the control unit 21 of the terminal 20A terminates the process.

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

In steps A420 and A430, one or more transaction histories are selected from the payment histories in which the user ID of the payment history information is the user account of the own terminal, and a request for refund of the amount paid is made. It may or may not generate and transmit linked wallet settlement request information including billing to the user of the user account.
In addition, the linked wallet settlement request information may include the return of the amount paid to the user account of the payer ID and the request of the amount paid to the user account of the payer ID. It doesn't have to be.

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

In the coordinated wallet settlement process, based on the received coordinated wallet settlement request information, the payment amount for each selected transaction ID is transferred from the account of the payer ID to the account of the payer ID.
In regards to billing the amount of money paid, information including a message prompting remittance may be sent to the terminal of the account of the payer ID.

When the coordinated wallet settlement process is executed, the control unit 11 of the server 10 uses the coordinated wallet settlement result information, which is the processing result of the coordinated wallet settlement, as an example, not as a limitation, as the payer ID of the payment history that performed the settlement, the payment It is transmitted to the terminal of the account of the user ID (S440).
It should be noted that the remittance results and the like related to the payment history for which the payment was made may be transmitted to all the terminals of the cooperation members, or they may not be transmitted.

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

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

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

After executing the linked wallet settlement process, the control unit 21 of the terminal 20A displays a screen for selecting whether or not to discard this linked wallet (A310). When discarding the linked wallet is selected based on the user's operation on the input/output unit 23 of the terminal 20A (A310: YES), the control unit 21 of the terminal 20A issues a linked wallet destruction request requesting the destruction of the linked wallet. The information is transmitted to the server 10 via the communication I/F 22 (A320), and the linked wallet settlement process is executed (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). , if received (A340: YES), the linked wallet settlement process is executed (A330). If not received (A340: NO), the process proceeds to step A100.

When cooperative wallet destruction request information is received from the terminal of the cooperative member via the communication I/F 14 after executing the cooperative wallet settlement process (S310: YES), the control unit 11 of the server 10 sends the cooperative wallet settlement request information to the communication I/F 14. It is transmitted to each terminal of the cooperative member by F14 (S320), and cooperative wallet settlement processing is executed (S330).

It should be noted that if the cooperative wallet destruction request information is not received (S310: NO), the control unit 11 of the server 10 shifts the process to step S100.

After executing the cooperative wallet settlement process, the control unit 11 of the server 10 executes cooperative wallet discarding process (S340).
In the linked wallet destruction process, each record of linked wallet management data of this linked wallet is deleted from the third linked wallet management database 157C. If the linked wallet management data is identified by a group ID, the group management data of the group ID for which linked wallet destruction has been selected may also be deleted from the group management data in the group management database 159. You don't have to.

In addition, after the coordinated wallet settlement process, the linked wallet destruction process may be disabled if unsettled payment history remains in the payment history data, or it may be executed even if the payment history remains. may

When the cooperative wallet disposal process is executed, the control unit 11 of the server 10 transmits cooperative wallet destruction information including information indicating that the cooperative wallet has been disposed of and can no longer be used, to each terminal of the cooperative members via the communication I/F 14. (S350) to end the process.

After executing the cooperative wallet settlement process, when the control unit 21 of the terminal 20A receives the cooperative wallet discard information from the server 10 through the communication I/F 22, it displays the received cooperative wallet discard information on the display unit 24 (A350). After that, the control unit 21 of the terminal 20A terminates the process.

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

<Effects of the seventh embodiment>
In this embodiment, the terminal 20 makes a payment (an example of a third payment, not a limitation) based on a first user account and a third user account associated with the first user account, which is different from the second user account. ) is performed by the control unit 21 . In addition, the terminal 20 receives the third information regarding the remittance to the third user account through the communication I/F 22 based on this payment, and displays the third display based on the received third information on the display unit 24. .
Then, the terminal 20 controls processing related to transferring the amount based on the first information from the first user account to the second user account based on the input by the user of the terminal 20 to the first display and the third display. It shows a configuration in which the control unit 21 performs processing related to transferring money based on the third information from the first user account to the third user account.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to implement remittance from a first account to a plurality of accounts by a simple method of inputting by the first user to the first display and the third display. can.

<Eighth embodiment>
In the first to seventh embodiments, the method of linking user accounts in account linking settlement has been described, but the present invention is not limited to this.
The eighth embodiment introduces the concept of a common wallet. Then, the payment is made by the linked wallet that links the common wallet (common account) and the user account.

The content described in the eighth embodiment can be applied to each of the other embodiments and modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

FIG. 8-1 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
In addition to the payment application management processing program 151, the account registration data 153, the account management database 155, and the linked wallet management database 157, the storage unit 15 stores a common wallet management database 161 as an example and not a limitation. be.

Here, the common wallet will be described in detail with reference to the common wallet management database 161. FIG.

A common wallet is a form of electronic money account pre-established by multiple users of a payment application prior to making a payment.

A common wallet allows multiple users to make payments using the balance. A user who can use the common wallet is hereinafter referred to as a "common wallet member".

In order to use the common wallet, the user first performs an operation to generate the common wallet. This generation requires, by way of example and not by way of limitation, information identifying the co-wallet member's e-money account (by way of example, but not by way of limitation, Application ID).

The common wallet management database 161 is a database for the server 10 to manage the common wallet, and an example data configuration is shown in FIG. 8-2.
Common wallet management data is stored in the common wallet management database 161 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 "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 for 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 specified when creating the common wallet.

It is also possible to add a new common wallet member by adding an application ID to the common wallet member ID after creating 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 payments, common wallet members transfer electronic money from their respective electronic money accounts to the common wallet to increase the common wallet balance.

The common wallet member can also charge the common wallet (convert to electronic money and remit) from an external financial institution account registered with the payment service (as an example, not a limitation, a bank account).

When the common wallet becomes unnecessary, a common wallet destruction operation is performed to cancel the existing common wallet. When the common wallet destruction operation is executed, the amount obtained by dividing the common wallet balance by the number of common wallet members (equal division) is transferred to each electronic money account of the common wallet members. After the common wallet balance becomes “0”, the record of the common wallet management data is deleted from the common wallet management database 161 .

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

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

Linked account data is data relating to accounts that are linked to perform account linked settlement, and stores a wallet ID and a name as an example and not a limitation.

A wallet ID is an identifier of a user account or common wallet that is linked by this linked wallet, and in the case of a user account, an application ID is stored, and in the case of a common wallet, a common wallet ID is stored.

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

Note that the number of accounts stored in the linked account data is not limited to two. You may or may not link more than two accounts. Also, only the common wallet may be linked, or not.

That is, in this embodiment, the linked account includes the user account and the common wallet account.

It should be noted that the group described in the fourth embodiment may be introduced so that the account information of the common wallet (common wallet ID and common wallet name) can be added to the group member data of the group management database 159. does not have to be

<Processing>
As a non-limiting example, the processing in this embodiment can be realized in the same manner as in FIGS. is omitted.

Here, in step S280 of FIG. 3-5, the case where lending, borrowing and returning processing is executed and money is transferred to the common wallet will be described in more detail.

By way of example and not limitation, the common wallet is for user B. B's account and user C.B. C's account. In this case, when a predetermined amount of money (as an example, not as a limitation, the total amount of the required return paid by the common wallet) is remitted to the common wallet, the balance of the electronic money in the common wallet (common wallet balance) will be User B. B's account and user C.B. As an example and not by way of limitation, C's account may or may not be remitted in halves of the predetermined amount.

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

<Effects of the eighth embodiment>
In this embodiment, the second account is a common wallet account (not limited to, but an example of a common account that can be settled by a plurality of users), and the terminal 20 displays the recommended remittance amount displayed on the display unit 24 as the first account. From the first user account to the common wallet account, based on the input by the user of the terminal 20 on the display of the screen for selecting whether or not to transfer money from the user account to the common wallet account (not a limitation, but an example of the first display) 1 shows a configuration for executing processing for remittance to
As an example of the effect of the embodiment obtained by such a configuration, it is possible to make payments based on the first user's account and a common account with which a plurality of users can make payments.
Also, the amount of money based on the first information can be transferred from the first account to the common account by a simple method of input by the first user to the first display.

In this case, each user account of a plurality of users is associated with the common wallet account as a common wallet member account. A required return amount (not a limitation, but an example of a second amount that is at least part of the first amount) may be remitted.
As an example of the effect of the embodiment obtained by such a configuration, a second amount of money, which is at least part of the first amount of money, is transferred from the common account to each account of a plurality of users associated as a common account. can be
As a non-limiting example, when a certain amount of money accumulates in the common account, the refundable amount can be refunded from the common account to each account of a plurality of users as a second amount. can.

<Ninth embodiment>
In the above-described embodiment, in the account-linked settlement, each linked account bears (splits) an equal payment amount obtained by equally dividing the planned settlement amount by the number of linked accounts. However, the present invention is not limited to this.
In the ninth embodiment, a burden sharing method other than splitting the bill will be described.

The content described in the ninth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

By way of example and not limitation, as a federated account, user A. A and user B.A. B and user C.B. Consider a case where three accounts with C are linked and payment of "3,000 yen" is made using the linked account. Also, user A. The electronic money account balance of user A's account is "4,000 yen"; The electronic money account balance of user A's account is "500 yen". Assume that the electronic money account balance of A's account is "2,000 yen".

FIG. 9-1 shows a table showing the amount borne by each cooperation member in this case.

Pattern 1 is the same case of splitting the bill as before.
In this case, all cooperation members bear the payment equally, and each burden amount is "1,000 yen". At this time, user B. B cannot make the payment due to insufficient payment capacity.

Pattern 2 is an example in which some of the linked accounts do not bear the burden, and the remaining linked accounts are divided equally.
In this case, by way of example and not limitation, user B. User A. B's burden amount is assumed to be "0". A and user C.A. C and C divide "3,000 yen" equally and pay "1,500 yen" each.

Pattern 3 is an example of a case where some of the linked accounts do not bear the burden, and the remaining linked accounts are slanted to bear the burden.
By way of example and not limitation, user B. User A. B's burden amount is assumed to be "0". A and user C.A. C and C bear "3,000 yen" in proportion to their respective electronic money account balances (user AA:user C.C=2:1).

Pattern 4 is an example of a case where some of the linked accounts cannot bear the equal payment amount, the account pays the entire balance of the electronic money account, and the remaining linked accounts share the balance equally.
By way of example and not limitation, user B. User A pays the limit of "500 yen" out of the equal payment amount of "1,000 yen", and user A.B pays the remaining "2,500 yen". A and user C.A. It will be divided equally between C and C.

Pattern 5 is an example of a case where if some of the linked accounts cannot bear the equal payment amount, the account will pay the entire balance of the electronic money account, and the remaining linked accounts will pay the remaining balance in a gradual manner. be.
By way of example and not limitation, user B. User B pays the limit of "500 yen" out of the equal payment amount of "1,000 yen", and the remaining "2,500 yen" is paid by user A.B who has a large electronic money account balance. A pays even amount "1,000 yen" and user B.A. User C.B bears the total amount ("1,500 yen") of "500 yen" corresponding to the account shortage of user C.B. C bears the equal payment amount of "1,000 yen".

In the embodiments so far, it has been explained that the payment amount is divided equally, and if there is a shortfall, the shortfall is paid upfront and returned.
However, as a non-limiting example, it is also possible to make payments by changing the proportion of the burden instead of sharing the payment amount equally among the linked accounts as in patterns 2 to 5 above. be.

<Tenth embodiment>
In the above-described embodiment, it is assumed that account linkage has been performed in advance in account linkage settlement, that is, account linkage has been completed, but the present invention is not limited to this.
In the tenth embodiment, a method of linking accounts will be described.

The content described in the tenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

FIG. 10-1 is a diagram showing a data configuration example of a 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.

Each linked wallet management data stores, as a non-limiting example, a group ID, a group name, linked status management data, payment history data, and payment history data. The group ID, group name, payment history data, and payment history data are the same as those of the third linked wallet management database 157C, for example and not limitation.

The linkage status management data is data that indicates the linkage status of each account of the group members in this linkage wallet.
In the cooperation status management data, as an example and not limitation, an application ID, a user name, and cooperation approval are associated and stored.

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

Cooperation approval is a flag for determining whether or not each user (user account) approves payment using this cooperation wallet. is "completed", and "not yet" is stored if approval has not been given.
In the following, the user (user account) approving the payment using the cooperative wallet may be expressed as "cooperation approval".

A "federated account" can be, by way of example and not limitation, an account that is a candidate for federation of a federated wallet, regardless of whether it is approved for federation.
Similarly, a "federated member" can be, by way of example and not limitation, a user who is a candidate for federation of a federated wallet, with or without federation approval.

Note that the account is not limited to this, and an account that has been approved for cooperation and has been approved for cooperation may or may not be defined as a “cooperation account”.
Similarly, a user who has been approved for cooperation and has been approved for cooperation may or may not be defined as a "collaboration member".

<Display screen>
FIG. 10B is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of Fig. 10-2 is an example of the group selection screen. In the current location display area CLR1, the characters "cooperative wallet" are displayed to indicate that the cooperative wallet function is being used. The text "Please select a group" prompting the user to select a group for cooperation is displayed.

Below that, groups to which the user of this terminal (in this case, user A.A) belongs are displayed in a row for each row. Each group entry shows, by way of example and not limitation, an icon for the group, the name of the group, and the number of members that make up the group.

As a non-limiting example, when the group "band friends" is tapped as a group for wallet cooperation, a group information display screen as 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 cooperative wallet information display area WIR1, the characters "Would you like to request wallet cooperation?" By way of example and not limitation, in this screen the group "Bandmates" is user A. A and user B.A. B and user C.B. It is shown that it is a group containing 3 people with C.

Also, at the bottom of the screen, a wallet cooperation request button BT35 indicated by the characters "request wallet cooperation" is provided. When this wallet cooperation request button BT35 is tapped, the terminal 20A , the cooperation group selection information is sent to request wallet cooperation from other members in the group.

When the wallet cooperation request button BT35 is tapped, as shown on the right side of FIG. 10-2, the main screen of the cooperative wallet before the other members of the group "bandmates" carry out wallet cooperation is displayed.

In this screen, under the current location display area CLR1, a code reader icon IC2 indicated by the characters "code reader" for making a "store presentation type" code payment using a linked wallet, and a "user presentation type" icon IC2 are displayed. is displayed side by side.
In this screen, since the cooperative wallet has not yet been activated, the code reader icon IC2 and the code payment icon IC3 do not function even if they are tapped, and are displayed grayed out.

Below these icons, the group name "Band Friends", which is the target of the linked wallet, is displayed, and below that, the linked member information display for displaying the collaboration status of each member of the group "Band Friends". Area MIR1 is displayed.

In the linking member information display area MIR1, the name of each member who has become a target of wallet linking and the linking status are displayed in association with each line. By way of example and not limitation, user A.A. A is in wallet cooperation, and user A.A. A's electronic money account balance is shown to be "1,000 yen".
Also, user B. B and user C.B. C indicates that a request for wallet cooperation is in progress and approval for cooperation has not been obtained.

The left side of FIG. 10-3 shows user B. who has been requested to cooperate with the wallet based on tapping the wallet cooperation request button BT35 in FIG. 10-2. It is an example of the notification screen in B's terminal 20B.
In this notification screen, the current location display area CLR2 displays the characters "notice" indicating that the notification function is for the payment application.

Below the current position display area CLR2, user A. User B.A receives a request for wallet linkage from user B.A. A notification NT1 to be notified to B is displayed. Under the notification NT1, a notification information display area NTR1 for displaying notification information is formed, and information corresponding to the notification NT1 is displayed in this notification information display area NTR1.

In this example, in the notification information display area NTR1, the text "A request for wallet collaboration has arrived from Mr. A." and the text and icon of the group "Bandmates" that performs wallet linkage are displayed. Approval confirmation information CT1 is displayed.
At the bottom of the wallet cooperation approval confirmation information CT1, there is a wallet cooperation approval button indicated by the characters "cooperate" for approving wallet cooperation with the members of the group "band friends", and a wallet cooperation approval button for not approving wallet cooperation. A wallet cooperation refusal button indicated by the characters "decline" is displayed.

As an example and not a limitation, when the wallet cooperation refusal button is tapped, a notification indicating that the wallet cooperation has failed is sent to the terminal of the member (user A.A in this example) who is currently cooperating with the cooperative wallet, and is displayed. be done. After that, the cooperative wallet in the group "Bandmate" is destroyed, and the process ends.

The center of FIG. 10-3 is an example of the linked wallet main screen when the wallet link approval button of the wallet link approval confirmation information CT1 is tapped. In this screen, user B. is displayed in the cooperation member information display area MIR1. User B is now linked to the wallet. B's electronic money account balance is shown to be "3,000 yen".

In the center of FIG. 10-3, user B. A notification indicating that B has performed wallet linkage may be displayed, or it may not be displayed.

The right side of Fig. 10-3 is an example of the main screen of the linked wallet that is displayed when all the members of the group have linked the linked wallet. Electronic money account balance is displayed. Also, the code reader icon IC2 and the code payment icon IC3 are not grayed out, and the touch operation is enabled.

<Processing>
10-4 and 10-5 show flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A), the processing executed by the control unit 21 of the terminal 20B (the terminal 20 of the user B.B), the server 10 shows an example of processing executed by the control unit 11 of FIG.

First, the control unit 21 of the terminal 20A transmits group list request information to the server 10 via the communication I/F 22 for selecting a group to which the cooperative wallet is applied and for requesting information on the group list ( A500).

When the group list request information is received from the terminal 20A by the communication I/F 14, the control unit 11 of the server 10 refers to the group management database 159, and as an example, not limited to, a list of group IDs and group names. group list information is transmitted to the terminal 20A through the communication I/F 14 (S500).

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

Upon receiving the linked group selection information from the terminal 20A via the communication I/F 14, the control unit 11 of the server 10 stores the group ID and the associated group name in the linked wallet management data of the fifth linked wallet management database 157E. management data as a new record. In addition, the control unit 11 of the server 10 refers to the group management database 159, and adds the user information of the group (application ID and user name as an example, not limitation) to the linkage status management data of the added linked wallet management data. write. Then, the control unit 11 of the server 10 sets "unauthorized" as cooperation approval in the item of each user in the cooperation status management data, and sets "accepted" as cooperation approval of the user of the terminal that transmitted the cooperation group selection information. (S505).

Then, the control unit 11 of the server 10 sends the wallet cooperation approval confirmation information, which is approval confirmation information as to whether or not to approve the wallet cooperation, to the user's terminal (limited Instead, as an example, it transmits to the terminal 20B) (S510).

When the wallet cooperation approval confirmation information is received from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20B displays the wallet cooperation approval confirmation information on the display unit 24 (B500). If approval of wallet cooperation is selected based on the user's operation on the input/output unit 23 of the terminal 20B (B500: YES), the control unit 21 of the terminal 20B transmits the wallet cooperation approval information via the communication I/F 22. It is transmitted to the server 10 (B510).

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

When the wallet cooperation approval information is received from the terminal that sent the wallet cooperation approval confirmation information via the communication I/F 14 (S520: YES), the control unit 11 of the server 10 approves the cooperation status management data of the application ID of the received terminal. to "done". Then, as an example and not as a limitation, the cooperative member information including the application ID and the electronic money account balance of the cooperative member is transmitted to the terminal of each member of the group (S530).

If the wallet cooperation approval information is not received (S520: NO), the control unit 11 of the server 10 waits for reception of the wallet cooperation approval information. If the wallet cooperation approval information is not received even after a certain period of time has passed, the control unit 11 of the server 10 sends information indicating that the wallet cooperation has failed to each terminal, and then terminates the process. may or may not be so.

After executing the step of S530, the control unit 11 of the server 10 determines whether or not the cooperation approval of the cooperation status management data is "completed" for all users (S540). If all group members agree to wallet cooperation (S540: YES), the control unit 11 of the server 10 can generate a cooperative wallet payment token for this group (cooperative wallet), and the cooperative wallet can be used. Linked wallet information indicating that the group is connected is sent to the terminal of each member of the group via the communication I/F 14 (S550). Then, the control unit 11 of the server 10 shifts the processing to step S100 in FIG. 7-3 as an example and not as a limitation.

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

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

When the cooperative wallet information is received from the server 10 via the communication I/F 22 (A530: YES), the control unit 21 of the terminal 20A displays a display indicating that the cooperative wallet has been activated based on the cooperative wallet information. 24 to inform the user that the cooperative wallet in the selected group can be used (A540). Then, as a non-limiting example, the control unit 21 of the terminal 20A receives the cooperative wallet code reader information from the server 10, and shifts the processing to step A100 in FIG. 7-3.

If the cooperative wallet information is not received (A530: NO), the control unit 21 of the terminal 20A waits for reception of the cooperative member information again.
When information indicating that the wallet cooperation has failed is received from the server 10, the control unit 21 of the terminal 20A may or may not terminate the process.

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

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

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

<Tenth Modification (1)>
In the tenth embodiment, the case of introducing a cooperative wallet in a group pre-configured with a plurality of members was exemplified, but the present invention is not limited to this. As an example and not a limitation, in a cooperative wallet configured by the method (1) of the fourth embodiment (a method of registering multiple cooperative accounts in the cooperative account data), the cooperative wallet is used based on the authorization of the cooperative member. It may or may not be possible.

In this case, as an example and not a limitation, in the fifth federated wallet management database 157E, the federated wallet ID is used in place of the group ID and group name to identify the federated wallet. Then, the data obtained by adding the cooperation approval to the cooperation account data may be regarded as the cooperation status management data, and the process may be executed.

For this purpose, at the beginning of the process (steps A500 to A510 in FIG. 10-4), the control unit 21 of the terminal 20A selects the application ID of any user (user account) instead of selecting a group. , to the server 10 . Then, the server 10 may add the selected application ID to the cooperation status management data.

<Tenth Modification (2)>
In the above embodiment, the creation of a linked wallet may or may not require linking approval, and account linking may be performed.
In other words, when a cooperative wallet is created by omitting the processing related to cooperation approval, multiple accounts that are candidates for cooperation may be automatically associated in the cooperative wallet management data. good too.
In this case, creating a linked wallet is "account linking".

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

The content described in the eleventh embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

In this embodiment, a chat service is used as a messaging service, and a messaging application installed in the terminal 20 performs display based on cooperative settlement result information or based on reimbursement history information.
A chat room is exemplified below as a chat room in the case of applying the messaging service (messaging application).

In this embodiment, a case will be exemplified in which wallet cooperation is performed in a payment application service that cooperates with a messaging service for a group used in a messaging service.

<Display screen>
In the following, user A. who is also a user of a messaging application and a user of a payment application. A and user B.A. B and user C.B. Both C and C belong to the group "band friends" and are registered as friends.

FIG. 11A is a diagram showing an example of a chat 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 of the group "band friends". On the talk room screen, as a non-limiting example, messages sent by you (user A.A in this example) are displayed as balloons on the right side of the display area, and messages sent by other users are displayed on the left side of the display area. Appears as a speech bubble.

On the left side of FIG. 11-1, user A.A. User B.A is another group member. B, user C. C and the state of exchanging messages are shown. In this state, when the linked wallet icon IC1 at the bottom of the screen is tapped, the screen on the right side of FIG. 11-1 is displayed as an example and not as a limitation.

Specifically, the linked wallet information display area WIR1 is displayed rising from the bottom of the screen. In the linked wallet information display area WIR1, the text "Would you like to request a wallet link?" In this state, when the wallet cooperation request button BT35 displayed at the bottom of the cooperative wallet information display area WIR1 is tapped, a wallet cooperation request is sent from the terminal 20A to the terminals 20 of the other group members via the server 10. sent.

FIG. 11-2 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, user A. As a message sent from A, a wallet cooperation request message MS1 indicating a request for wallet cooperation is displayed on the left side of the display area. This wallet cooperation request message MS1 includes a text indicating a request for wallet cooperation, a cooperation button containing the characters "cooperate" indicating that the request for wallet cooperation is approved, and a message indicating that the request for wallet cooperation is rejected. A refusal button containing the characters "decline" indicating the request is displayed. When the link button is tapped, information indicating that the user has agreed to link the wallet is sent to the server 10, and the user B. B's user account is linked. As a result, the screen on the right side of FIG. 11-2 is displayed on the display unit 24 of the terminal 20A as an example and not as a limitation.

In this screen, a cooperative member information display area MIR1 is displayed rising from the bottom of the group talk room screen on the left side of FIG. 11-1. User A. A is in wallet cooperation, and user A.A. A's electronic money account balance is shown to be "1,000 yen". In addition to this, user B. Since user B has approved the wallet linkage, user B.B. B is also in wallet cooperation, and user B.B. B's electronic money account balance is shown to be "3,000 yen".
Also, user C.I. C is in the process of requesting wallet cooperation, and approval for cooperation has not yet been obtained.

FIG. 11-3 shows that user C.I. 10 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A when account-linked settlement is performed by the linked wallet of the group "bandmates" after the collaboration is approved by C. FIG.
On the left side of Fig. 11-3, a cooperative wallet payment completion notification including a member payment result display area MRR8 containing information indicating that payment by the cooperative wallet has been completed rises from the bottom of the screen, and a group talk of the group "Bandmates" is displayed. It is displayed superimposed on the room.
In this example, user A. Based on the fact that the electronic money account balance of A's user account is "1,000 yen" and that "500 yen" is insufficient for the equal payment amount of "1,500 yen", "500 yen"' to user C. An example of a case in which C pays the bill is shown.

User A. As for A, the shortfall amount of "500 yen" of the equally divided payment amount of "1,500 yen" is sent to user C.A. It shows that C paid the advance and paid "1,000 yen", which is the remaining payment capacity, and as a result, the balance of the electronic money account became "0 yen".
User B. As for B, it is shown that an equal payment amount of "1,500 yen" was paid, and as a result, the electronic money account balance became "1,500 yen".
User C.I. As for user A.C, user A.C of the equal payment amount of "1,500 yen" It shows that A's shortfall amount "500 yen" was paid in advance and "1,500 yen + 500 yen = 2,000 yen" was paid, and as a result, the electronic money account balance became "4,000 yen". ing.

Also, in the member payment result display area MRR8, the user C.I. In item C, user A.C. User C.A pays the "500 yen" that was paid in advance to user C.A. An advance amount refund button BT6 for returning the product to C is displayed.
When the advance payment amount refund button BT6 is tapped, user A. A's e-money account to user C.A. Remittance of "500 yen" for payment is executed to C's electronic money account.

When the upper right close button (X mark button) 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 chat room, user A. A linked payment result message MS2 (linked payment result information) indicating that User C.A paid "1,000 yen"; In C, an advance message MS3 (advance information) indicating that "500 yen" was paid in advance is displayed.
The cooperative settlement result message MS2 and the payment message MS3 may or may not be collectively displayed as one piece of information.

In the payment message, a payment amount refund button BT6 is displayed.
When the advance payment amount refund button BT6 is tapped, user A. A's e-money account to user C.A. Remittance of "500 yen" for payment is executed to C's electronic money account.

FIG. 11-4 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20C in this example.
A group chat room is displayed on the left side of FIG. 11-4, and user C.I. user C.C. C is user A.C. A payment message MS5 (advance payment information) indicating that A's payment of "500 yen" has been paid in advance is displayed.
Note that the cooperative settlement result message MS4 and the payment message MS5 may be collectively displayed as one piece of information, or may not be displayed in such a manner.

User C.I. User C pays the "500 yen" paid upfront to user A.C. A billing amount button BT7 for billing A is displayed.
When the billing amount button BT7 is tapped, information for billing the billing amount is transmitted from the terminal 20C to the terminal 20A via the server 10. FIG.

As a non-limiting example, when the ">Payment App" button included in the payment message MS5 is tapped, a cooperative wallet payment completion notification including the member payment result display area MRR9 is displayed as shown on the right side of FIG. 11-4. It rises from the bottom of the screen and is superimposed on the group talk room.
In the member payment result display area MRR9, user A. In item A, an advance amount request button BT7 is displayed.

FIG. 11-5 shows the screen displayed on the display unit 24 of the terminal 20A when another account-linked payment (next account-linked payment) is performed following the payment by the linked wallet described in FIGS. 11-1 to 11-4. FIG. 10 is a diagram showing an example of transition of displayed screens;
The left side of FIG. 11-5 shows the progress of the chat in the group chat room shown on the right side of FIG. 11-3. In this example, user A. User C.A sends a message to the group requesting the purchase of another product (in this example, a stick), and user C.A sends a message to the effect of approval. The state originating from C is shown.

When the above product (stick) is purchased by the account-linked payment and the payment is completed, as shown in the center of FIG. It rises from the bottom of the screen and is superimposed on the group talk room on the left side of Figure 11-5.

In this example, the price of the product (stick) is "900 yen" and the equal payment amount is "900 yen/3=300 yen". However, as noted above, user A. Since the electronic money account balance of user A has become "0 yen", user A. A cannot make the payment. Thus, in this example, user A. User C.A. It shows the result of having C pay the shortfall in advance.

Specifically, user A. For A, the payment amount is "0 yen" and the electronic money account balance is "0 yen".
User B. For B, it is indicated that the equal payment amount of "300 yen" was paid, and as a result, the electronic money account balance became "1,200 yen".
User C.I. As for user A.C, user A.C of the equal payment amount of "300 yen" It shows that A's shortfall amount of "300 yen" was paid in advance and "300 yen + 300 yen = 600 yen" was paid, and as a result, the electronic money account balance became "3,400 yen".

The right side of FIG. 11-5 shows an example of the group talk room displayed on the terminal 20A in this case. In this group talk room, user A. User C.A's payment is "0 Yen". C displays a payment message MS7 (payment information) indicating that "300 yen" has been paid in advance.
The cooperative settlement result message MS6 and the payment message MS7 may or may not be collectively displayed as one piece of information.

In the payment message, a payment amount refund button BT6 is displayed.
When the advance payment amount refund button BT6 is tapped, user A. A's e-money account to user C.A. Remittance of "300 yen" for payment is executed to C's electronic money account.

FIG. 11-6 is a diagram showing an example of a display screen when batch settlement of linked wallets is performed, and shows an example of a group chat room screen displayed on the display unit 24 of the terminal 20A.
In this example, as shown on the left side of Figure 11-6, the linked A notification is displayed to prompt the settlement of the wallet. When this balloon is tapped, as shown on the right side of FIG. 11-6, a display area for displaying information about the batch settlement of linked wallets rises from the bottom of the screen of the group chat room.

In this display area, along with the text "Would you like to pay for the linked wallet?" A to user C. Confirm that C will return (remittance) a total of "800 yen", which is equivalent to the advance payment of "500 yen" and "300 yen" mentioned above. A "Yes" button for approving it and a "No" button for rejecting it are displayed along with a message for the request. When the "yes" button is tapped, user A. A to user C. Remittance of "800 yen" to C is executed.

In addition, on the screen on the left side of Figure 11-6, a notification prompting payment for the linked wallet will be displayed when the group name display area or other areas within the current location display area are tapped. may or may not.

<Processing>
As for the processing in this embodiment, as an example and not limitation, the processing of the payment application management server that manages the payment application and the messaging application management server that manages the messaging service is assumed to be the processing in the server 10, and FIG. 10-5 and FIGS. 7-3 to 7-5, so a repeated description will be omitted.

<Effects of the Eleventh Embodiment>
In this embodiment, the display of remittance request information (one example of the first display, not limited) is a chat room in which the first user account and the second user account are associated (not limited, the first account and the second display). An example of a chat room associated with an account), and the terminal 20 displays on the display unit 24 a talk room including display of remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, the first information regarding the transfer of money to the second account is displayed in an easy-to-understand manner by being displayed in the chat room in which the first account and the second account are associated. , can be made known to the first user of the terminal.

In addition, in the present embodiment, the terminal 20 performs processing for causing the server 10 to perform account-linked settlement based on the first user account and the second user account (not limited, but an example of processing related to the second settlement). It is performed by the control unit 21 . In addition, the terminal 20 receives remittance request information (not limited, but an example of the second information) through the communication I/F 22 based on the account-linked settlement. Then, the terminal 20 opens a talk room including the display of the received remittance request information (not limited, but an example of the second display) and the display of other remittance request information (not limited, but an example of the first display). The configuration displayed on the display unit 24 is shown.
As an example of the effect of the embodiment obtained by such a configuration, based on the first account of the first user of the terminal and the second account associated with the first account, By performing processing by the control unit of the terminal, it is possible to realize the second payment using at least two associated accounts. Also, in addition to the first information regarding the remittance to the second account by the first payment, the second information regarding the remittance to the second account by the second payment is displayed in the chat room in an easy-to-understand manner on the terminal. can be notified to the first user of

In addition, the present embodiment is based on the display of one remittance request information (not limited, but an example of the second display) and the display of other remittance request information (not limited, but an example of the first display). Execute processing for transferring a recommended remittance amount based on one remittance request information and a recommended remittance amount based on other remittance request information from a first user account to a second user account based on an input by a user. showing configuration.
As an example of the effect of the embodiment obtained by such a configuration, the amount of money based on the first information and the amount of money based on the second information can be changed by a simple method of inputting by the first user to the first display and the second display. , can be transferred from the first account to the second account.

<Eleventh Modification (1)>
In the eleventh embodiment, based on canceling the account linkage in the talk room (chat room) of a plurality of linked accounts, unprocessed refunds may be made for account-linked payments that have been made so far. may or may not.

“Cancel account linkage” means to remove the association between accounts. By way of example and not limitation, this includes destroying federated wallets.

Also, if you create a linked wallet linked to a chat room, "disconnect account link in chat room" includes any of the following as an example, not as a limitation:
(A) Disassociate the accounts without destroying the chat room (B) Destroy the chat room

(A) means, as an example and not a limitation, to eliminate the association between accounts in the linked wallet associated with the chat room without destroying the chat room. By way of example and not limitation, this includes destroying a federated wallet by a user providing input on a chat room to destroy a federated wallet.

(B) means that, by destroying the chat room, the association between the accounts in the cooperative wallet linked to that chat room will be lost as a result. By way of example and not by way of limitation, this includes destroying a chat room by a user providing input to destroy the chat room.

In addition, if the design and specifications are such that members can only leave the chat room and the existence of the chat room cannot be eliminated, as an example rather than as a limitation, the remaining number of members will be "1" or "0" by leaving. In such a case, the account linkage may be canceled or may not be performed.

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 cooperative member information display area MIR1 related to the cooperative wallet of the group "bandmates" is displayed rising from the bottom of the screen of the group talk room. A cooperative wallet discard button BT30 is displayed at the bottom of the cooperative member information display area MIR1.

In this modified example, when the linked wallet discard button BT30 is tapped, the linked wallet can be discarded after the batch settlement. Specifically, as a non-limiting example, as shown on the right side of Figure 11-7, information indicating that the linked wallet is to be destroyed and information on batch settlement are displayed in a pop-up format so as to be superimposed on the linked wallet information. is displayed.

In this example, user A. A to user C. To confirm that C will return (remit) a total of "800 yen", which corresponds to two advances, the above-mentioned "500 yen" and the above-mentioned "300 yen". is displayed along with a "Yes" button for approving it and a "No" button for rejecting it. When the "yes" button is tapped, user A. A to user C. Remittance of "800 yen" to C is executed.

In this modification, the terminal 20 cancels the association in the chat room between the first user account and the second user account (not a limitation, but an example of canceling the association in the chat room). It shows a configuration for performing a process of transferring an amount of money (a non-limiting example of an amount based on first information and an amount based on second information) from a first user account to a second account.
As an example of the effect of the embodiment obtained by such a configuration, when canceling the association in the chat room between the first account and the second account, the amount based on the first information and the amount based on the second information are Money can be transferred from the first account to the second account. As a non-limiting example, if the association between the first account and the second account is discarded in the chat room, or if the chat room itself is discarded, it is possible to refund the unprocessed amount. Become.

<Twelfth embodiment>
In the above embodiment, the terminal 20 of each cooperation member is configured to be able to check the electronic money account balance of each cooperation account. The information of the electronic money account balance in each linked account can be sent from the server 10 to the terminal 20 of the linked member, received by the terminal 20, and displayed on the display unit 24, for example and not limitation. In addition, unlike this, it is also possible to transmit and receive information on the electronic money account balance between the terminals 20 .
In other words, in the above embodiment, the true electronic money account balance was shared among the linked members in each linked account.
However, it is assumed that some users are hesitant to disclose their true electronic money account balances to other cooperative members.

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

However, as described above, user accounts of different users do not necessarily have to be linked accounts, and multiple user accounts of the same user can be linked accounts.
Therefore, in this embodiment, first, a case where a plurality of user accounts of the same user are used as linked accounts will be described.

Also, in this embodiment, as an example of the amount set to limit the displayed balance, the "display lower limit amount" is exemplified, but the present invention is not limited to this.
The amount set to limit the displayed balance can also be an amount arbitrarily input and set by the user of the linked account, or a "maximum display amount", which will be described later in detail.

Note that the displayed balance is a concept that enables display of a balance different from the true electronic money account balance, and is similarly applicable to other than account-linked settlement.
As an example and not as a limitation, the same can be applied to normal settlement using a user account, common account settlement, and the like.

The content described in the twelfth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

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

In addition to the application ID corresponding to this cooperation account and the user name corresponding to this application ID, the lower limit display amount is associated and stored in the cooperation account data as an example and not as a limitation.

The display lower limit amount is an example of an amount set to limit the display balance, and is an amount set as the lower limit amount that can be displayed as the display balance.
By way of example and not limitation, in FIG. The user account with the application ID "U0001", which is the main account of A, and the user A.A. A's sub-account, which is the user account with application ID "U0005", is associated.

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

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

FIG. 12B is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
When the cooperative 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. In this screen, user A.A. Along with information indicating that it is a cooperative wallet of A., user A.A. A's main account electronic money account balance ("10,000 yen" in this example) and user A.A's main account balance ("10,000 yen" in this example) The display balance set for A's subaccount ("5,000 yen" in this example) is displayed. User A. Unlike the main account, the set display balance is displayed in the balance display column of A's sub-account.

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

In this example, the equal payment amount is "3,000 yen".
User A. is displayed in the cooperation member information display area MIR1. A's main account payment amount ("3,000 yen" in this example) and user A.A. The payment amount for A's subaccount ("3,000 yen" in this example) is displayed.

User A. As for A's main account, the electronic money account balance is "10,000 yen", which exceeds the equal installment payment amount.
However, user A. Regarding sub-account A, the displayed balance is "5,000 yen", but the actual electronic money account balance is "1,000 yen", which is less than the equal payment amount.
As a result, based on the fact that the cooperative payable amount is less than the payment amount, a warning mark and the words "Insufficient balance" are displayed in the payment amount confirmation area PIR1.

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

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

If the display lower limit amount is not set, the electronic money account balance of the linked account may be transmitted as the linked account balance information with the lower limit in a manner distinguishable from the displayed balance. Alternatively, the electronic money account balance may be transmitted in the form of a displayed balance (that is, “displayed balance”=“electronic money account balance”).

Upon receiving the lower limit linked account balance 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 the displayed balance of each linked account (A600).

Even if the display balance is restricted by the lower limit display amount, the linked payment process uses the true electronic money account balance to execute the payment process (S110). That is, the displayed balance is simply a value that the user of the terminal 20 can confirm.

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 minimum amount to the terminal 20A.
In this case, the control unit 21 of the terminal 20A can calculate the display 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, when there are multiple terminals 20 corresponding to the linked account, the electronic money account balance of each linked account is received from the server 10, and the display balance is displayed on each terminal 20 by transmitting and receiving the display lower limit amount between the terminals 20. It may or may not be calculated.

When there is one terminal 20 corresponding to the linked account (that is, there is one linked member), as an example and not as a limitation, the display lower limit amount is stored in the storage unit 28 of the terminal 20A, and the server 10 reads each linked account. The electronic money account balance may be received and the display balance may be calculated on the own terminal, or it may not be so. In this case, it is not necessary to transmit/receive information about the display lower limit amount.

<Effects of the 12th embodiment>
In this embodiment, the terminal 20 sets the display lower limit amount ( The display unit 24 displays a display balance based on the second amount (not limited, but an example of the second amount) (not limited, but an example of the balance of the second account based on the second amount). Then, the terminal 20 performs processing related to linked account settlement based on the first user account of the user of its own terminal 20 (not a limitation, but an example of the first account) and the second user account for which the display lower limit amount is set. It shows a configuration in which the control unit 21 performs (not a limitation, but an example of a process related to the first payment).
As an example of the effect of the embodiment obtained by such a configuration, the balance of the second account based on the second amount set in the second account associated with the first account of the first user is confirmed by the first user. can be made
Also, the first payment can be made by the terminal of the first user based on the first account and the second account in which the second amount of money is set.

Also, in this case, the terminal 20 communicates the information of the displayed balance based on the display lower limit amount (not limited, but an example of the second amount) (not limited, but an example of the balance information of the second account based on the second amount). It is received by I/F22. Then, the terminal 20 can display the displayed balance on the display unit 24 based on the received information on the displayed balance.
As an example of the effect of the embodiment obtained by such a configuration, based on receiving and acquiring the balance information of the second account based on the second amount from another device, the balance information of the second account based on the second amount The balance can be verified by the first user.

In addition, in the present embodiment, the server 10 communicates information on the display balance based on the display lower limit amount set for the second user account (not a limitation, but an example of information on the balance of the second account based on the second amount). It is transmitted to the terminal 20 of the first user through the I/F 22 . Then, the server 10 shows a configuration in which the control unit 11 performs account-linked settlement processing based on the first user account and the second user account to which the display lower limit balance is set.
As an example of the effect of the embodiment obtained by such a configuration, information regarding the balance of the second account based on the second amount set in the second account is transmitted to the terminal of the first user and confirmed by the first user. can be made
Also, the first payment can be made based on the first account and the second account in which the second amount of money is set.

<Thirteenth embodiment>
In the twelfth embodiment, the concept of displayed balance is newly introduced.
Although the displayed balance described in the twelfth embodiment merely displays the set displayed balance, this embodiment describes an embodiment in which the displayed balance can affect the settlement process.

As in the twelfth embodiment, also in this embodiment, a case where two user accounts (main account and sub-account) of the same user (first user) are used as linked accounts will be described.

Some users may want to limit the electronic money account balance that can be used for one payment in the linked wallet.
Also, as an example and not as a limitation, it is possible that the user's terminal 20 is lost or stolen, and the true electronic money account balance of the user is seen by others.

The content described in the thirteenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

Each federated wallet management data stores, by way of example and not limitation, a federated wallet ID, federated account data, and payment history data. The linked wallet ID and settlement history data are the same as those of the sixth linked wallet management database 157F, for example and not limitation.

In addition to the application ID corresponding to this cooperation account and the user name corresponding to this application ID, the display upper limit amount is associated and stored in the cooperation account data as an example and not as a limitation.

The display upper limit amount is, as an example and not a limitation, an example of an amount set to limit the display balance, and is an amount set as the upper limit amount that can be displayed as the display balance.
By way of example and not limitation, in FIG. The user account with the application ID "U0001", which is the main account of A, and the user A.A. A's sub-account, which is the user account with application ID "U0005", is associated.

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

<Display screen>
Here, user A. A linked wallet in which A's main account and sub-account are linked as linked accounts will be described using an example of a display screen. 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 screen transitions 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 user A. is displayed in the linked member information display area MIR1. A's main account electronic money account balance (10,000 yen) and user A.A's main account balance (10,000 yen). The display balance (5,000 yen) based on the display upper limit amount (5,000 yen) set for A's subaccount is displayed.

In the main account display column, an upper limit button BT40 for setting a display upper limit amount is displayed together with information on the balance of the electronic money account.
Since the display upper limit amount has been set for the subaccount, the upper limit button BT40 is not displayed in the subaccount display column.

When the upper limit button BT40 in the main account display column 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, the state where "3,000 yen" is input as the display upper limit amount for the main account is shown. In this state, when the setting button BT41 at the bottom of the screen is tapped, the screen returns to the main screen of the cooperative wallet, and the display shown on the right side of FIG. 13-2 is displayed.
In this main screen, unlike the main screen on the left side of FIG. In the display column of A's main account, "3,000 yen" is displayed as the displayed balance.
Further, based on the display upper limit amount being set, 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 shows an example of the code reader screen displayed when the code reader icon IC2 is tapped on the right side of the screen of FIG. 13-2.
When the payment store code fits within the code reading area CR1 and the linked wallet code reader information is read, the screen shown in the center of FIG. 13-3 is displayed. This screen shows a state in which "6,000 yen" has been entered as the payment amount for the cooperative wallet.

In this example, the equal payment amount is "3,000 yen".
User A. As for A's main account, the electronic money account balance is "10,000 yen", which exceeds the equal installment payment amount.
Also, user B. As for the sub-account B, the electronic money account balance is "5,000 yen", which exceeds the equal payment amount.
Therefore, it is possible to make a payment using the cooperative wallet, and if the payment button BT1 at the bottom of the screen is tapped in this state, the screen on the right side of FIG. 13-3 is displayed.

This screen displays information indicating that payment by the linked wallet has been completed.
Since the equal payment amount is "3,000 yen", the electronic money account balance for the main account has changed from "10,000 yen" to "7,000 yen" due to the payment, but the displayed balance is "3,000 yen". 000 yen", "3,000 yen" is displayed as the displayed balance.
On the other hand, for the sub-account, the electronic money account balance has changed from "5,000 yen" to "2,000 yen" due to the payment, but since it is less than the displayed balance of "3,000 yen", the displayed balance will be "2,000 yen". 000 yen” is displayed.

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

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

Upon receiving the display upper limit amount setting information through the communication I/F 14, the control unit 11 of the server 10 stores the display upper limit amount in the seventh cooperative wallet management database 157G. Then, the control unit 11 of the server 10 calculates the display balance of each linked account according to the stored maximum display amount. Then, the control unit 11 of the server 10 transmits the upper limit linked account balance information including the calculated displayed balance to the terminal 20A via the communication I/F 14 (S610).

Upon receiving the upper-limit linked account balance 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 the displayed balance of each linked account (A620).

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 maximum display amount to the terminal 20A.
In this case, the control unit 21 of the terminal 20A can calculate the display balance using the received true electronic money account balance and the display upper limit amount, and cause the display unit 24 to display the balance.

In addition, when there are multiple terminals 20 corresponding to a linked account, the electronic money account balance of each linked account is received from the server 10, and the maximum display amount is transmitted and received between the terminals 20, so that each terminal 20 can display the balance. It may or may not be calculated.

When the cooperative payment request information is received by the communication I/F 14, the control unit 11 of the server 10 searches for the cooperative wallet ID from the cooperative wallet payment token that received the request. A store-presented type upper limit cooperative settlement process for paying the planned settlement amount with the store is executed (S690).

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

Also, in the cooperative settlement result information transmitted in step S240, instead of the electronic money account balance, the displayed balance recalculated after the settlement process is transmitted.

<Effect of the thirteenth embodiment>
In this embodiment, the terminal 20 uses the display upper limit amount ( The display unit 24 displays a display balance based on the second amount (not limited, but an example of the second amount) (not limited, but an example of the balance of the second account based on the second amount). Then, the terminal 20 performs processing related to linked account settlement based on the first user account of the user of its own terminal 20 (not a limitation, but an example of the first account) and the second user account for which the display upper limit amount is set. It shows a configuration in which the control unit 21 performs (not a limitation, but an example of a process related to the first payment).
As an example of the effect of the embodiment obtained by such a configuration, the balance of the second account based on the second amount set in the second account associated with the first account of the first user is confirmed by the first user. can be made
Also, the first payment can be made by the terminal of the first user based on the first account and the second account in which the second amount of money is set.

In addition, in this embodiment, the terminal 20 sets the display upper limit amount for the first user account based on the input to the terminal 20 by the user of the terminal 20 (not limited, but an example of the first user). The setting control is performed by the control unit 21 . Then, the terminal 20 displays 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. there is
As an example of the effect of the embodiment obtained by such a configuration, it is possible to set a displayed amount of money (first amount of money) for the first account as well.
Also, the first user can 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.

Also, in this case, the information on the display upper limit amount set in the second user account is the electronic money account balance of the second user account (not a limitation, but an example of the balance of the second account), the first user's terminal 20 may include maximum amount information.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to allow the first user to confirm information on the maximum amount set in the second account.

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

Also, in this case, the display balance of the second user account displayed on the display unit 24 of the terminal 20 will be displayed on the display unit 24 if the electronic money account balance of the second user account is greater than the display upper limit amount. If displayed and the electronic money account balance of the second user account is less than the display limit amount, the electronic money account balance of the second user account may be displayed.
As an example of the effect of the 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 for the second account.

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

In this case, if the user has an electronic money account balance that exceeds the displayed balance, the payment can be made using the electronic money account balance. In other words, the displayed balance is a displayed value and does not affect the settlement process.

<Thirteenth Modification (2)>
In the above embodiment, an example was shown in which a different display upper limit amount is 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 federated wallet.
In this case, if the electronic money account balance of a linked account exceeds the maximum display amount of the linked wallet, the displayed balance of this linked account will be the maximum display amount of the linked wallet.

In addition, the display upper limit amount of the linked wallet and the display upper limit amount of each linked account may be defined or set, or may not be set.
In this case, only an amount smaller than the display upper limit amount of the linked wallet may be set as the display upper limit amount in each linked account, or it is not necessary to do so.
If the linked account has a display limit that exceeds the display limit of the linked wallet, the display balance of this linked account may reflect the display limit set for each account. does not have to be

<Thirteenth Modification (3)>
In the above embodiment, an example in which a user account is linked as a linked account was shown, but this is not the only option. As an example and not a limitation, the shared wallet described in the eighth embodiment may be a cooperative wallet with a cooperative account, or may not be so.

In this case, the linked account data of the sixth linked wallet management database 157F is associated with the wallet ID similar to that of the fourth linked wallet management database 157D, the name, and the above display upper limit amount, for example and not limitation. It should be remembered.

Then, if the common wallet balance of the common wallet exceeds the display upper limit amount, the display upper limit amount will be calculated, and if the common wallet balance is less than the display upper limit amount, the common wallet balance will be calculated as the display balance of the common wallet. Just do it.

This modification shows a configuration in which the second account is a common wallet account (not a limitation, but an example of a common account).
As an example of the effect of the modification 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 amount is set, authentication may be required for inquiry and display of the electronic money account balance, or it may not be required. That is, the electronic money account balance may or may not be displayed on the display unit 24 of the terminal 20 unless the authentication is performed and the authentication result is OK (authentication OK).
In this case, the terminal 20 performs the authentication process by the control unit 21 based on the input by the user of the terminal 20 itself, and displays the electronic money account balance on the display unit 24 when the authentication is OK. can.

As an example and not a limitation, when the electronic money account balance exceeds the set display upper limit amount, the display upper limit amount is displayed as the display balance, so 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 the authentication is OK.

The same applies to the case of setting the amount such as the display lower limit amount.
As an example and not a limitation, when the electronic money account balance is below the set display minimum amount, the display minimum amount is displayed as the display balance, so the true electronic money account balance is kept secret. In this case also, the true electronic money account balance will not be displayed on the display unit 24 unless the authentication is OK.

By doing so, as described above, even if the terminal 20 is lost or stolen, the user's true electronic money account balance can be prevented from being known to others.

Also, the user of the terminal 20 may be allowed to perform the above authentication settings (authentication ON/OFF).
In this case, it may be possible to configure settings related to authentication for each user account owned by the user or collectively for all user accounts owned by the user.
As an example and not a limitation, authentication may be set to ON only for a user account for which an amount for limiting the displayed balance (such as the above display upper limit amount and display lower limit amount) is set.

<14th embodiment>
In the thirteenth embodiment, the case where the displayed balance can affect settlement processing has been described.
In this embodiment, the thirteenth embodiment is combined with the tenth embodiment described above to introduce a display balance restricted by the display upper limit amount in a cooperative wallet for a plurality of cooperative members.
That is, in the present embodiment, the first account is assumed to be the user account of the first user, and the second account is assumed to be the user account of the second user who is different from the first user.

As described above, it is assumed that some users are hesitant to disclose their true electronic money account balances to other cooperative members. By way of example and not by way of limitation, it is assumed that users wish to keep their true electronic money account balance private, such as when there is a large balance in the electronic money account balance.
Also, as described above, some users may want to limit the electronic money account balance that can be used for one payment in the linked wallet.

The content described in the fourteenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

Each linked wallet management data stores, as a non-limiting example, a group ID, a group name, linked status management data, payment history data, and payment history data. The group ID, group name, payment history data, and payment history data are the same as those of the fifth cooperative wallet management database 157E, for example and not limitation.

The cooperation status management data stores an application ID, a user name, cooperation approval, and, as an example, not a limitation, an upper limit display amount in association with each other.

In the present embodiment, as an example and not as a limitation, when agreeing to participate in a cooperative wallet, each cooperative member can set an allowable maximum display amount.

<Display screen>
FIG. 14-2 is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
On the left side of FIG. 14-2 is displayed a screen for requesting wallet cooperation from members of the group "band friends". When the wallet cooperation 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 is a screen for setting the display upper limit amount of money for itself, and in this example, a state in which "3,000 yen" has been entered as the display upper limit amount amount is shown. In this state, when the setting button BT41 at the bottom of the screen is tapped, the screen on the right side of FIG. 14-2 is displayed.

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

Also, user B. B and user C.B. For user A.C. Since the request for wallet linkage from A has not yet been approved, a "requested" mark is displayed for each.

FIG. 14-3 shows user A. FIG. 10 is a diagram showing an example of transition of screens displayed on the display unit 24 of the terminal 20B based on a wallet cooperation request from A;
A notification screen of the payment application is displayed on the left side of FIG. 14-3. A notification is displayed to the effect that A has requested wallet linkage.

In addition, in the display area below which the content of the announcement is displayed, user A. Wallet cooperation request information regarding a request for wallet cooperation from A is displayed. User A. is included in the wallet link request information. In addition to characters indicating that A has requested wallet cooperation, a confirmation button for confirming the details is displayed. When this confirmation button is tapped, the screen in the center of FIG. 14-3 is displayed.

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

User A. As for A, since he is the requester of the wallet cooperation and is already a cooperation member, the displayed balance (“3,000 yen” in this example) is displayed.
Also, user C.I. For user A.C. Since the request for wallet linkage from A has not yet been approved, a "requesting" mark is displayed.

When the wallet cooperation button is tapped, the screen on the right side of Fig. 14-3 is displayed.
This screen is for user B. B is a screen for setting the display upper limit amount, and in this example, the state where "4,000 yen" is input 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.
In this screen, in the cooperation member information display area MIR2, the user B. In column B, "6,000 yen" is displayed as the electronic money account balance, and "4,000 yen" is displayed as the displayed balance.

On the other hand, user B. With B's approval of the wallet linkage, a screen as shown on the right side of FIG. 14-4 is displayed on the terminal 20A side.
On the terminal 20A side, user B. is displayed in the cooperation member information display area MIR1. The mark "under request" displayed in column B disappears, and instead, "4,000 yen" is displayed as the displayed balance.
It should be noted that user C.I. For user A.C. Since the request for wallet linkage from A has not yet been approved, the "requested" mark remains displayed.

FIG. 14-5 shows user A. FIG. 10 is a diagram showing an example of transition of screens displayed on the display unit 24 of the terminal 20C based on a wallet cooperation request from A;
A notification screen of the payment application is displayed on the left side of FIG. 14-5. A notification is displayed to the effect that A has requested wallet linkage.

In addition, in the display area below which the content of the announcement is displayed, user A. Wallet cooperation request information regarding a request for wallet cooperation from A is displayed. User A. is included in the wallet link request information. In addition to characters indicating that A has requested wallet cooperation, a confirmation button for confirming the details is displayed.

The confirmation button is tapped, and the flow from the center of FIG. 14-3 to the right side of FIG. When C approves the wallet linkage and sets the maximum display amount, the screen in the center of Fig. 14-5 is displayed.

In this screen, in the cooperation member information display area MIR3, user C.I. In column C, "2,000 yen" is displayed as the electronic money account balance, and "10,000 yen" is displayed as the displayed balance.

On the other hand, user C.I. Upon approval of wallet cooperation by C, a screen as shown on the right side of FIG. 14-5 is displayed on the terminal 20A side.
On the terminal 20A side, the user C.I. The mark "under request" displayed in column C disappears, and instead, "10,000 yen" is displayed as the displayed balance.

In addition, with the completion of the wallet cooperation of all the members of the group "band friends", the code reader icon IC2 and the code payment icon IC3 are released from being grayed out, and are displayed in an active state.

In this state, as shown on the left side of FIG. When the code payment icon IC3 is tapped by A, 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 server 10 performs payment processing for the user-provided cooperative wallet, the cooperative payment confirmation screen shown on the right side of FIG. 14-6 is displayed. be.
In this cooperative payment confirmation screen, a payment amount confirmation area PIR3 is displayed below the current position display area CLR1. The payment amount confirmation area PIR3 displays "12,000 yen" as the payment amount.

Here, the cooperative payable amount in this embodiment is an amount defined by the following formula, assuming that the payment amount is divided equally among the cooperative accounts.
・Collaboration Payable Amount = Sum of payment capacity for all cooperative accounts

Here, the payment capacity of one linked account is defined by the following formula.
・Payment capacity of one linked account = displayed balance of that linked account (if displayed balance of linked account - equal payment amount < 0)
・Payment capacity of one linked account = equal payment amount (if the displayed balance of the linked account - equal payment amount ≥ 0)
However, it is calculated as "Equal payment amount = payment amount / number of linked accounts".

Note that, in the present embodiment, the linking member and the linking account have a one-to-one correspondence, so the linking account in the above formula is substantially synonymous with the linking member.

In this example, the equal payment amount is "12,000 Yen/3=4,000 Yen".
User A. As for the user account A, the displayed balance is "3,000 yen", which is less than the equal installment payment amount of "4,000 yen", so the payment capacity is "3,000 yen".
User B. As for the user account B, the displayed balance is "4,000 yen", which is the same as the equal installment payment amount of "4,000 yen", so the payment capacity is "4,000 yen".
User C.I. As for the user account C, the displayed balance is "10,000 yen", which exceeds the equal installment payment amount of "4,000 yen", so its 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", whereas the cooperative payable amount is "11,000 yen", resulting in a shortage of "1,000 yen".
As a result, a warning mark and the words "insufficient balance" are displayed in the payment amount confirmation area PIR3.

Also, in this example, it is user A. who has insufficient payment capacity. A's user account, the paying member confirmation area PMR3 shows the user A.A. A warning mark is displayed on the upper left of the A icon.

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

FIG. 14-7 is a diagram showing an example of transition of screens displayed on the display unit 24 of the terminal 20A in this case.
On the left side of FIG. 14-7, information for changing the maximum display amount is displayed in a pop-up format in the center of the screen on the right side of FIG. 14-6. Specifically, along with the text "Are you sure you want to change the maximum display amount for this payment?" information prompting you to Also displayed are a "Yes" button to be operated when agreeing to this change and a "No" button to be operated when not agreeing to this change.

When the "Yes" button is tapped, the screen in the center of Fig. 14-7 is displayed. On this screen, the warning mark and the characters "insufficient balance" displayed in the payment amount confirmation area PIR3 on the screen on the right side of FIG. 14-6 disappear, and the characters "payable" are displayed.
In this state, when the cooperative payment execution button BT5 at the bottom of the screen is tapped, the cooperative payment result display screen on the right side of FIG. 14-7 is displayed.

At the top of the linked payment result display screen, along with the text "Payment completed" indicating that the payment using the linked wallet has been completed, the icon image of "XX musical instrument", which is the destination of the payment amount, and its name "XX musical instrument” and the payment date and time “2020-07-24/12:17:08” are displayed.

At the bottom of the cooperative payment result display screen, a member payment result display area MRR1 is displayed, which shows the breakdown of this payment for each cooperative account.
In the member payment result display area MRR1, for each linked account, the paid user account, the amount paid by each user account, and the displayed balance after payment are displayed.
In this screen, user A.A. The displayed balance of A has returned to "3,000 yen" before the change. Also, user B. The displayed balance of B is updated to "2,000 yen" based on the fact that the electronic money account balance 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 processing executed by each device in this embodiment.
In this figure, from the left side, processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A), processing executed by the control unit 21 of the terminal 20B, and processing executed by the control unit 11 of the server 10 are shown. An example is shown.

After executing step A510, control unit 21 of terminal 20A executes step A610. Further, after executing the step of B510, the control unit 21 of the terminal 20B executes the step of B610. As for step B610, the process can be executed in the same manner as step A610, so a detailed description thereof will be omitted.

When the display upper limit amount setting information is received from the cooperation member's terminal 20 via the communication I/F 14, the control unit 11 of the server 10 changes the cooperation approval of the cooperation status management data in 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 associated member. Then, the control unit 11 of the server 10 transmits restricted cooperation member information including the application ID and the displayed balance of the cooperated member to the terminal 20 of each member of the group via the communication I/F 14 as an example and not limitation. (S630).

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

When the cooperative payment request information is received by the communication I/F 14, the control unit 11 of the server 10 calculates the cooperative payable amount based on the displayed balance, and determines whether the calculated cooperative payable amount is less than the planned settlement amount. (whether or not the cooperative payable amount−scheduled settlement amount<0) is determined (S640).

If the cooperative payable amount is not less than the planned settlement amount (the cooperative payable amount minus the planned settlement amount is 0 or more) (S640: NO), payment using the cooperative wallet is possible within the displayed balance. Therefore, the control unit 11 of the server 10 shifts the process to step S690.

If the cooperative payable amount is less than the scheduled settlement amount (S640: YES), the control unit 11 of the server 10 executes step S220.

When the communication I/F 22 receives the linked balance shortage information from the server 10 (A200: YES), the control unit 21 of the terminal 20A limits the displayed balance of the user of the terminal 20A (user A.A in this case). As an example, instead of user A. Display upper limit amount change information including the display upper limit amount addition amount for raising the shortage of A's ability to pay (that is, equal payment amount - user A's ability to pay) to server 10 via communication I/F 22 Send (A640).

The display upper limit additional amount may be set based on the user's operation on the input/output unit 23 of the terminal 20A. It may be determined automatically according to the shortfall of A's ability to pay.

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

When the display upper limit amount change information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 transmits the display upper limit amount addition amount of the received display upper limit amount change information to the user A.A. The amount is added to the display upper limit amount of A, and the display amount is calculated again (S680).

After the displayed amount of money is updated in step S680, the control unit 11 of the server 10 transmits the updated displayed amount of money to the terminals of the cooperation members via the communication I/F 14, and updates the displayed balance on each terminal. It may or may not be displayed.

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

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

14-8 to 14-10 show the flow of one-time payment processing, but after FIG. 14-10, by executing the processing in FIG. The payment process may be executed multiple times, or may not be executed.

Also, the display upper limit amount is set when participating in the linked wallet, but it is not limited to this. As an example and not as a limitation, the maximum display amount may be reset at any timing, or may not be set. As an example and not as a limitation, if the amount that can be used as a guideline for payment is known, the cooperative member may set the maximum display amount so that the cooperative payable amount exceeds the amount that can be used as a guideline. may

<Effect of the 14th embodiment>
In this embodiment, the terminal 20 can display the maximum amount of money (limited The display unit 24 displays the display balance based on the second amount of money (an example of the second amount of money, not the limit) on the display unit 24 (not a limitation, but an example of the balance of the second account based on the second amount of money). Then, the terminal 20, based on the first user account of the user of its own terminal 20 (not a limitation, but an example of the first account) and the second user account in which the display upper limit amount is set, the first user's terminal 20 shows a configuration in which the control unit 21 performs processing related to linked account settlement (not limited, but an example of processing related to the first settlement).
As an example of the effect of the embodiment obtained by such a configuration, the balance of the second account based on the second amount set in the second account associated with the first account of the first user is visually recognized by the first user. can be made In this case, as an example and not a limitation, an amount different from the amount corresponding to the true balance of the second account is set as the second amount, thereby concealing the true balance of the second account from the first user. can be done.
Also, the first payment can be made by the terminal of the first user based on the first account and the second account in which the second amount of money is set.

In addition, in this embodiment, the terminal 20 sets the display upper limit amount for the first user account based on the input to the terminal 20 by the user of the terminal 20 (not limited, but an example of the first user). The setting control is performed by the control unit 21 . Then, the terminal 20 displays 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. there is
As an example of the effect of the embodiment obtained by such a configuration, it is possible to set a displayed amount of money (first amount of money) for the first account as well. In this case, as an example and not a limitation, by setting an amount different from the amount corresponding to the true balance of the first account as the first amount, the true balance of the first account can be hidden from other users. can.
Also, the first user can 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.

Also, in this case, the information on the display upper limit amount set in the second user account is the electronic money account balance of the second user account (not a limitation, but an example of the balance of the second account), the first user's terminal 20 may include maximum amount information.
As an example of the effect of the embodiment obtained by such a configuration, the set maximum amount can be visually recognized by the first user while the true balance of the second account is concealed.

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

Also, in this case, the display balance of the second user account displayed on the display unit 24 of the terminal 20 will be displayed on the display unit 24 if the electronic money account balance of the second user account is greater than the display upper limit amount. If displayed and the electronic money account balance of the second user account is less than the display limit amount, the electronic money account balance of the second user account may be displayed.
As an example of the effect of the embodiment obtained by such a configuration, when the balance of the second account is larger than the second amount of money, the true balance of the second account can be hidden from the first user. can. On the other hand, if 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.

In addition, in the present embodiment, the terminal 20, based on the input to the terminal 20 by the user of the terminal 20 (not limited, but an example of the first user), the display upper limit amount set in the first user account , a configuration is shown in which the control unit 21 performs control to change .
As an example of the effect of the embodiment obtained by such a configuration, it is possible to change the first amount once set in the first account.

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

<Fourteenth Modification (1)>
In the above embodiment, an example was explained in which the maximum display amount is increased when the payment capacity of the cooperation member who executes the payment is insufficient for the set maximum display amount, but the present invention is not limited to this.

By way of example and not limitation, user A.M. If the payment capacity other than A is insufficient, in step A640 of FIG. 14-10, the control unit 21 of the terminal 20A sets the display upper limit amount addition amount so as to exceed the insufficient payment capacity of the other cooperative members. You may or may not do so.

<Fourteenth Modification (2)>
In the above embodiment, an example was shown in which the shortage of the payment capacity is resolved by increasing the maximum display amount of the person making the payment (user A.A in this example), but the present invention is not limited to this.
As an example and not as a limitation, other cooperative members may or may not be requested to raise the maximum display amount.

14-11 and 14-12 are flowcharts showing an example of the flow of processing executed by each device in this modified example.
In this figure, an example of processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A) and processing executed by the control unit 11 of the server 10 are shown in order from the left.
By way of example and not limitation, after performing the steps of FIGS. 14-8 through 14-9, the processes of FIGS. 14-11 through 14-12 are performed.

When receiving cooperation balance shortage information from the server 10 via the communication I/F 22 (A200: YES), the control unit 21 of the terminal 20A displays the displayed balance of another cooperation member (for example, user BB) as an example, not as a limitation. as user A. The display upper limit amount change request information for requesting an increase of A's remaining payment capacity beyond the shortfall is transmitted to the server 10 via the communication I/F 22 (A650).

As an example, not limitation, the control unit 21 of the terminal 20A sets the display upper limit additional amount based on the user's operation, and transmits the display upper limit amount change request information including the display upper limit additional amount. You may or may not.

In addition, as a cooperative member to request an increase in the displayed balance, as an example and not as a limitation, a member with a large displayed balance may be automatically selected, or may be selected by the user.

When the display upper limit amount change request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 transmits a display upper limit amount change request for requesting an increase in the displayed balance based on the display upper limit amount change request information. The information is transmitted to the terminal of the cooperative member (for example, user B.B) who requests an increase in the displayed balance through the communication I/F 14 .

It should be noted that the control unit 11 of the server 10 may calculate the display upper limit amount addition amount based on the shortage of the remaining payment capacity, and transmit the calculated display upper limit amount addition amount in the display upper limit amount change request information. OK, you don't have to.

When the 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 the display upper limit amount change information to the server 10 via the communication I/F 22 ( B650). The details of the processing are the same as the step A640 in FIG. 14-10.

As an example and not a limitation, when rejecting an increase in the display upper limit amount based on a user operation on the input/output unit 23 of the terminal 20B, the control unit 21 of the terminal 20B does not execute step B650. OK, you don't have to.

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

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

In this modification, when the settlement amount of the account linked settlement (an example of the first settlement amount, not limited) exceeds the total display upper limit amount of the linked account, the terminal 20 displays the It shows a configuration for transmitting upper limit money amount change request information (not a limitation, but an example of information relating to a change of the second amount) through communication I/F 22 .
As an example of the effect of the embodiment obtained by such a configuration, the set A request can be made to the second account to change the second amount.

<14th Modification (3)>
In the above embodiment, an example was explained in which the maximum display amount is increased when the payment capacity of the cooperation member who executes the payment is insufficient for the set maximum display amount, but the present invention is not limited to this.
As an example and not a limitation, as described in the third embodiment, it may or may not request other cooperative members to reimburse the remaining payment capacity.

<Display screen>
14-13 are diagrams showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of FIG. 14-13 is the same screen as the cooperative payment confirmation screen on the right side of FIG. 14-6, but the display is partially different. Specifically, user A. is displayed at the bottom of the screen. An advance request button BT4 is displayed for A to ask another user to pay for the shortfall.

User A. in the paying member verification area PMR3. In item A, an upper limit amount change button labeled "upper limit change" for changing the display upper limit amount is arranged. When the upper limit amount change button is tapped, as a non-limiting example, the screen transitions to the screen on the left side of FIG. 14-7.

When the advance request button BT4 is tapped, the screen in the center of FIG. 14-13 is displayed.
On this screen, under the information indicating that the wallet is a cooperative wallet of the group "Band Friends", an area for selecting candidates for cooperative members to request advance payment is displayed. In this example, user C.I. C is displayed.
Note that in this example, user B. User A. B has a displayed balance of "4,000 yen". Since A does not have the capacity to pay for the shortfall, he is not displayed as a candidate for cooperation members who request payment.

A radio button is associated with the cooperation member candidate (user C.C. in this example) to whom the payment is requested, and when the radio button is tapped to turn it "ON", the cooperation member requests the payment. is selected as a cooperation member to request. Then, the screen shown on the right side of FIG. 14-13 is displayed.

On this screen, the warning mark and the words "insufficient balance" displayed in the payment amount confirmation area PIR3 on the left side of the screen in FIG. 14-13 have disappeared, and the words "payable" are displayed.
In this state, when the cooperative payment execution button BT5 at the bottom of the screen is tapped, the payment is executed.

In addition, when a plurality of cooperative members can pay up front, as an example and not as a limitation, the control unit 21 of the terminal 20A may arrange and display the member candidates to be paid up front in descending order of the displayed balance. You don't have to.
Also, the cooperation member with the largest displayed balance may or may not be proposed as the payer.

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

When the cooperative settlement request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 executes step S640. If the cooperative payable amount is less than the scheduled settlement amount (S640: YES), the control unit 11 of the server 10 executes step S220.

After executing the step of S235, the control unit 11 of the server 10 executes the step of S690. After that, the step of S240 is executed.

Incidentally, after executing the processing in FIG. 14-14, as an example and not as a limitation, by executing the processing in FIG. and do not have to.

In this modification, an account-linked payment (an example of a first payment, not a limitation) is performed by a first user account, a second user account, and a third user account linked with these user accounts, The user account that pays the shortfall of one user account is the second user account and the third user account based on the display upper limit amount set for the second user account and the display upper limit amount set for the third user account. , one of which is set.
As an example of the effect of the embodiment obtained by such a configuration, the shortfall of the first account is paid based on the second amount set for the second account and the third amount set for the third account. You can set up your account properly. By way of example and not limitation, the account with the higher set amount out of the second account and the third account can be set as the account to pay the shortfall of the first account.

<14th Modification (4)>
In the fourteenth embodiment, the server 10 calculates the display balance based on the maximum display amount acquired from the terminal 20 of the cooperation member and the electronic money account balance of the cooperation member, and then 20, but it is not limited to this.

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

Also, as an example and not a limitation, the server 10 transmits the electronic money account balance of the terminal 20 of the cooperation member to each terminal 20 of the cooperation member instead of the displayed balance of the terminal 20 of the cooperation member. Then, the cooperation member's terminal 20 acquires the display upper limit amount acquired by a method other than acquiring from the server 10 (not limited, but as an example, the display upper limit amount prearranged between the cooperation members, the display upper limit amount The display balance may be calculated based on the maximum display amount received from the terminal 20 of the collaborating member who set the maximum display amount, etc.).
That is, the terminal 20 side may control the amount of the balance of the second account to be displayed.

<Fifteenth embodiment>
In the 14th embodiment, the display balance is restricted by the maximum display amount. The display limit was a limit that affected the combined payable amount on an individual payment.
In this embodiment, in addition to the display upper limit amount, as a limit that affects when multiple payments occur in the linked wallet, as an example instead of a limitation, two limits are introduced: the number of consecutive payments and the total limit amount. .

The content described in the fifteenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

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

Each linked wallet management data stores, as a non-limiting example, a group ID, a group name, linked status management data, payment history data, and payment history data. The group ID, group name, payment history data, and payment history data are the same as those of the eighth linked wallet management database 157H, for example and not limitation.

In addition to the application ID, user name, cooperation approval, and upper limit display amount, the number of consecutive payments and total limit amount are associated and stored in the cooperation status management data.

The number of consecutive payments is the number of times payment can be made using this cooperative wallet. By way of example and not limitation, user B. If the number of consecutive payments for user B is set to 5, user B. From B's electronic money account balance, payment can be made within the displayed balance.

The total limit amount is the total amount that each linked account can bear when making payments using this linked wallet. By way of example and not limitation, user A.A. If the total limit amount for user A is set to "10,000 yen", regardless of the number of payments, user A.A. A will bear the payment up to a total of "10,000 yen". Then, when the total limit amount is exceeded, user A. Payments are no longer made from A's account.

After introducing the total limit amount, the displayed balance of each linked account will be as follows.
・Display balance = MIN (MIN (display upper limit amount, total limit amount), electronic money account balance)
However, MIN(x, y) is a function that takes the minimum value of (x, y).
That is, the total limit amount must be set to an amount equal to or greater than the display upper limit amount in order not to deviate from the original definition.

If the display upper limit amount, the total limit amount, and the number of consecutive payments are not set, these values can be handled as sufficiently large arbitrary numbers (not as a limitation, but as an example, an infinite number).

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

On this usage restriction setting screen, user A.A. Below the information display column for user A's account, there are information on the setting of the maximum display amount (set/unset in this example) and information on setting the number of consecutive payments (set/unset in this example). , and information on the setting of the total limit amount (set/unset in this example) are displayed. Information about each setting is displayed in association with a change button for changing the contents of the setting.

In addition, a setting completion button BT43 is displayed at the bottom of the screen for completing and confirming the setting with the currently displayed setting contents.

As an example and not a limitation, when the change button in the display upper limit amount column is tapped, the screen on the right side of FIG. 15-2 is displayed.
This screen is for changing the display upper limit amount, and in this example, the state where "3,000 yen" is entered as the display upper limit amount to be changed is shown. In this state, when the setting button BT41 at the bottom of the screen is tapped, the upper limit display amount is set to the input amount.

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

This screen is the main screen of the linked wallet, and the user A.A. in the linked member information display area MIR4. In column A, the displayed balance "3,000 yen" and the electronic money account balance "10,000 yen" are displayed. Further, below it, the display upper limit amount "3,000 yen", the number of cooperative settlements "10 times", and the total limit amount "10,000 yen" are displayed.

Also, user B. B and user C.B. For user A.C. Since the request for wallet linkage from A has not yet been approved, a "requested" mark is displayed for each.

The right side of FIG. 15-3 shows, in the above, user B. B, user C. This is the main screen of the linked wallet when C has approved the link.
In this screen, the user B. in the cooperation member information display area MIR4 is displayed. B, user C. The characters "under request" in column C have disappeared, and each display balance is displayed.
In addition, user A. in the cooperation member information display area MIR4. In column A, the displayed balance "3,000 yen" and the electronic money account balance "10,000 yen" are displayed. Further, below it, the display upper limit amount "3,000 yen", the number of cooperative settlements "10 times", and the total limit amount "10,000 yen" are displayed.
In addition, with the completion of the wallet cooperation of all the members of the group "band friends", the code reader icon IC2 and the code payment icon IC3 are released from being grayed out, and are displayed in an active state.

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

When executing step A510, the control unit 21 of the terminal 20A sets the display upper limit amount, the total limit amount, and the number of consecutive payments based on the user's operation on the input/output unit 23 of the terminal 20A, as an example and not as a limitation. accept. 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 the step of B510, the control unit 21 of the terminal 20B executes the step of B615 similar to the step of A615.

When the account restriction setting information is received from the terminal 20B through the communication I/F 14, the control unit 11 of the server 10 changes the cooperation approval of the cooperation 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 received display upper limit amount and total limit amount, and the electronic money account balance of the associated member. Then, as an example and not as a limitation, restricted cooperation member information including the application ID and the displayed balance of the cooperated member is transmitted to the terminal of each member of the group via the communication I/F 14 (S635).

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

When the communication I/F 14 receives the cooperative payment request information, the control unit 11 of the server 10 calculates the payment capacity based on the displayed balance and the cooperative payable amount for the cooperative account whose number of consecutive payments is greater than 0. . For an account with 0 consecutive payments, the payment capacity is set to 0. In other words, a linked account whose number of consecutive payments is 0 is excluded from the allocation of payments.
Then, the control unit 11 of the server 10 determines whether or not the calculated cooperative payable amount is less than the scheduled settlement amount (S645).

When the cooperative settlement request information is received by the communication I/F 14, the control unit 11 of the server 10 executes the store presentation type limited cooperative settlement process (S695).

In the store presentation type limited cooperative payment processing, after the processing in step S690 is executed, if the payment processing is successful, the total limited amount of each cooperative account and the number of consecutive payments are updated.
That is, the number of consecutive settlements is decremented, and the payment capacity of the linked account is subtracted from the total limit amount.

Note that the settings for the number of consecutive payments and the total limit amount may not be changed, and the values in the temporary storage area linked to the number of consecutive payments and the total limit amount may be rewritten or not. . In this case, the updated number of consecutive payments and the total limit amount stored in this temporary storage area are used for calculating the displayed amount and determining the payment capacity in the above steps.

After executing the step of S695, the control unit 11 of the server 10 transmits the cooperative settlement result information to the terminal of the cooperative member (S240), and determines whether or not to end the processing (S699). As an example and not a limitation, if the processing is continuing in the cooperation member's terminal 20, the control unit 11 of the server 10 continues the processing (S699: NO), and executes the step of S100 again.

When the cooperative settlement 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 processing based on the user's operation on the input/output unit 23 of the terminal 20A, for example and not limitation. (A699). When continuing the process (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 the terminal 20B.

The processing of FIGS. 15-4 to 15-6 and the processing of FIG. 7-4 may be combined to continue the processing until the cooperative wallet is destroyed, or it may not be so.

<Effects of the fifteenth embodiment>
In this embodiment, the terminal 20, based on the input to the own terminal 20 by the user of the own terminal 20 (not limited, but an example of the first user), for the first user account, such as the number of consecutive payments It shows a configuration in which the setting (not limited, but an example of a first setting related to making payments multiple times) is performed by the control unit 21 .
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily and appropriately set the first account for multiple payments.

Also, in this case, the above setting indicates a configuration including setting of the number of consecutive payments (not a limitation, but an example of setting regarding the number of times payment can be made by the first user account).
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily and appropriately set the number of times settlement can be made using the first account.

Also, in this case, the number of times of continuous payment includes the number of times payment can be made without authenticating the first user of the first user account.
As an example of the effect of the embodiment obtained by such a configuration, while the number of settlements has not reached the number of settlements set by the first setting, authentication of the first user is not required, and the second Payments based on the account and the first account of the first user may be enabled. On the other hand, if the number of settlements has reached the number of settlements set by the first setting, authentication by the first user is required, and if not authenticated by the first user, the second account , and the first account of the first user.

<Fifteenth Modification (1)>
In the above example, payments are executed repeatedly, and if the number of consecutive payments of a cooperative member becomes "0" or less, or the total limit amount becomes "0" or less, payments from that member's account will not be executed. Examples are given, but not limited to.

As an example, not a limitation, if payments are made repeatedly and the number of consecutive payments made by a linked member becomes "0" or less, or the total limit amount becomes "0" or less (the number of consecutive payments set in the linked account or the total If the limit is exceeded), it may or may not be able to make payments with this federated wallet (for example, but not by way of limitation, stop generating federated wallet payment tokens).
In this case, as an example and not by way of limitation, destruction of the federated wallet may or may not be performed automatically.

<Fifteenth Modification (2)>
In the above embodiment, the number of payments to the associated 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, there may or may not be a set number of consecutive payments for each affiliated member making payments.

By way of example and not limitation, user A.A. As a setting of user B.A. The number of consecutive payments is determined so that B can execute payment "three times" and "user C.C." can execute payment "five times". Then, the user A.3 will be allowed to pay up to three times when executing the payment using the terminal 20B, and up to five times when executing the payment using the terminal 20C. Payment is charged to A's account.

Similarly, the total limit amount may be determined for each user, or may not be set.

<Fifteenth Modification (3)>
In the above embodiment, when the number of consecutive payments or the total limit amount of a linked member becomes "0" or less, payment from that member's account is not executed, but it is not limited to this.
As an example and not a limitation, a user who is not subject to payment due to restrictions being exercised may be able to pay the payment by obtaining consent at the time of payment, as an example and not a limitation. You don't have to do it that way.

In this case, as an example and not as a limitation, the number of consecutive payments or the total limit amount may be increased according to the permission of the member whose limit has been activated so that the payment burden can be made again.

<Fifteenth Modification (4)>
In the above embodiment, an example was explained in which the maximum display amount is increased when the payment capacity of the cooperation member who executes the payment is insufficient for the set maximum display amount, but the present invention is not limited to this.
As an example and not a limitation, as described in the fourteenth modified example, it may be possible to request other cooperation members to reimburse the remaining payment capacity, or it is not necessary to do so.

FIG. 15-7 is a flow chart showing an example of the flow of processing executed by each device in this modified example.
In this figure, an example of processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A) and processing executed by the control unit 11 of the server 10 are shown in order from the left.
By way of example and not limitation, the process of FIG. 15-7 is performed after performing each step of FIGS. 15-4 through 15-5.

When the cooperative settlement request information is received from the terminal 20A through the communication I/F 14, the control unit 11 of the server 10 executes step S645. If the cooperative payable amount is less than the scheduled settlement amount (S645: YES), the control section 11 of the server 10 executes steps S220 to S235.

After executing the step of S235, the control unit 11 of the server 10 executes the step of S695. After that, the step of S240 is executed, and the step of S699 is executed.

Following the processing of FIG. 15-7, by executing the processing of FIG. 7-4 as a non-limiting example, processing to settle advances incurred in the coordinated balance replenishment processing may be executed. You don't have to.

In step A200, when selecting a cooperative member to bear the shortfall of the payment capacity, if a plurality of cooperative members can pay the advance, the control unit 21 of the terminal 20A selects the member candidates who will pay the advance. They may be arranged and displayed in descending order of the number of consecutive settlements, or they may not be displayed in this order. Also, the cooperation member who has made the largest number of consecutive payments may or may not be proposed as the payer.

<Sixteenth embodiment>
In the twelfth to fifteenth embodiments, an embodiment in which a payment application is applied as an application has been described, but the present invention is not limited to this.
The 16th embodiment makes payments using a federated wallet in a group formed in a chat application (messaging application as an example and not limitation) and displays it in a chat room (as an example and not limitation a talk room). It is an example.

The content described in the 16th embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

<Display screen>
In the following, user A. who is also a user of a messaging application and a user of a payment application. A and user B.A. B and user C.B. Both C and C belong to the group "band friends" and are registered as friends.

FIG. 16-1 is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
The left side of FIG. 16-1 is a group talk room screen of the group "Bandmates", where user A.A. A is user B.A. B, user C. A state of having a group talk with C is shown. Specifically, user A. User A sends a message to the effect that he has purchased the product. User C.B sends a message agreeing to it. A message is sent from C suggesting that all members of the group pay 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 FIG. 16-1 is displayed.

In this screen, the linked wallet information display area WIR1 is displayed rising from the lower part of the screen of the group chat room on the left side of FIG. 16-1. In the linked wallet information display area WIR1, along with the text "Would you like to request a wallet link?" are listed. When the wallet cooperation request button BT35 at the bottom of the screen is tapped, the screen on the right side of FIG. 16-1 is displayed.

In this screen, a code reader icon IC2 and a code payment icon IC3 are displayed in an active state in the cooperative wallet information display area WIR1.
In addition, in the cooperation member information display area MIR4 below it, user A. A's user account information and user B.A's user account. information about user accounts of user C.B and user C.B. Information about C's user account is displayed.

In this example, user A.A. For A, in addition to the display 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 displayed.
Also, in this example, user B. who is another collaboration member. B, user C. For C, the displayed balance is displayed.

<Processing>
For the processing in this embodiment, as an example and not 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 are the processing in the server 10, and the processing in FIGS. Since it can be executed in the same manner according to FIG. 15-6, re-explanation is omitted.

<17th embodiment>
In the first embodiment to the sixteenth embodiment, an embodiment has been described in which settlement (reimbursement settlement) is performed between linked accounts for payments made after approval of collaboration.
The 17th embodiment is an embodiment relating to processing for a payment made before cooperation approval.
In the above example, payment could not be made if there was an unlinked approved account. As an example and not as a limitation, it may take some time to obtain approval for account linking, in which case payment cannot be made until the linking is approved.

In the embodiments described below, settlement of payments made before the linked account approves the linkage is referred to as "retroactive settlement" in the sense of retroactive settlement. Distinguish from the explained "reimbursement settlement".
Retroactive settlement is also a kind of settlement. In other words, settlement includes "reimbursement settlement" and "retroactive settlement".

The content described in the seventeenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

First, in this embodiment, based on the linkage between the first user account and the second user account (not limited, but an example of the association between the first account and the second account), at least the second account Information about payment is displayed on the display unit 24 of the terminal 20 of the first user of the first user account.
In this embodiment, after the linked wallet is generated, the linking of the first user account and the second user account (association of the first account and the second account) in this case is approved by the first user account. It will be explained as a fact (that the cooperation has been approved).
In addition, in this embodiment, based on the fact that the first user account has approved the cooperation, at least the second user account performs It is assumed that the information related to the settlement is displayed on the display unit 24 of the first user's terminal 20 of the first user account.

Secondly, in this embodiment, after the information regarding the above settlement is displayed on the terminal 20 of the first user of the first user account, the first user account retroactively transfers the payment to the second user account. Allows for settlement.

As in the previous embodiment, one pattern is to link multiple user accounts of the same user (as an example, not limitation, user A.A's main account and user A.A's sub-account). is also possible. That is, it is also possible to link the first user's first user account and the first user's second user account.

By way of example and not limitation, it is contemplated that a first user may make a payment using a second user account, which is then associated with the first user's first user account.
In this case, once the accounts are linked, the first user checks the payment history with the second user account.
After that, the first user confirms that the electronic money account balance of the second user account is low, and then instructs the first user account to transfer money from the first user account to the second user account, as an example and not a limitation. can do.
By way of example and not limitation, this can also be viewed as one method by which a single user transfers funds between electronic money accounts of his/her multiple user accounts.

In the following, as a pattern different from the above, a case of linking user accounts of different users will be described.

In this embodiment, the storage unit 15 of the server 10 stores the information shown in FIGS. 1-3 as an example and not as a limitation.

FIG. 17-1 is a diagram showing a data configuration example of a second account management database 155B, which is an example of the account management database 155 used in this embodiment.
Account management data is stored in the second account management database 155B 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 similar to the first account management database 155A, by way of example and not limitation.

The settlement history data is the data of the settlement (payment) history by this user account. stored in chronological order.
Individual elements can be configured in the same way as the payment history data in the linked wallet management data of the first linked wallet management database 157A, as an example and not as a limitation.

FIG. 17-2 is a diagram showing a data configuration example of a tenth linked wallet management database 157J, which is an example of a database for managing linked wallets used in this embodiment.
The tenth linked wallet management database 157J stores linked wallet management data as management data for each linked wallet.

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

In addition to the application ID and user name, cooperation approval is associated and stored in the cooperation account data. The federation approval is the same as the federation approval in the federation status management data of the fifth federation wallet management database 157E, by way of example and not limitation.

<Display screen>
Below, user B. Before user B creates a federated wallet, user B.B. An example of a display screen when paying "2,000 yen" at a PP supermarket using the user account of B will be described.

FIG. 17-3 is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
The screen on the left side of FIG. 17-3 is the notification screen of the payment application. Information about a request for wallet linkage from B is displayed. This information includes, by way of example and not limitation, user B. A letter indicating that there is a request for wallet cooperation from User B and user B.B. User A.B created by user A.B. A and user B. It contains an icon and text indicating that it is B's federated wallet.

Further, below it, a cooperation approval button containing the words "cooperate" for approval of cooperation and a cooperation rejection button containing the words "decline" for rejecting the cooperation are displayed. When the cooperation approval button is tapped, the screen in the center of FIG. 17-3 is displayed.

This screen is the main screen of the linked wallet, and is used by user B.1 in the linked member information display area MIR1. In the B column, user B.B. In addition to information on the electronic money account balance of user B's user account, user B.B before the linked wallet is generated. A single payment history button BT50 is displayed for displaying the payment history of B's user account alone (hereinafter referred to as "single payment history").
The payment history may or may not be expressed as a payment history.

When this single payment history button BT50 is tapped, the screen on the right side of FIG. 17-3 is displayed.
On this screen, under the current position display area CLR1, user B. An icon and characters indicating a single payment history ("purchase history" on the screen) by the user account of B are displayed, and the single payment history is displayed below it. In this example, user B. A single payment history related to the purchase of a product worth "2,000 yen" made at "19:10:33 on August 2, 2020" at "PP Super" by user B's account is displayed.

Thus, in this example, user B. At the time B makes the payment, user B.B. A federated wallet has not been created by user B.B. B to user A.B. A has not been requested to cooperate with the wallet, but user A.A. A is user B.A. By having approved the cooperation in response to the wallet cooperation request from user B. A single payment history from user A.B's user account can be viewed by user A.B. It is configured so that A can browse and check it on his own terminal 20A.

Next, an example of retroactive settlement based on the single payment history displayed in this way will be described.
In the screen on the right side of FIG. 17-3, the display column of the single payment history shows the user B. User A.B who has approved the cooperation for the payment made by the user account of A.B. A to user B. A remittance button BT52 for remittance to B as retroactive settlement is displayed. In this example, "2,000 yen" is entered by user A. A and user B. A remittance button BT52 for remittance of "1,000 yen" as the amount split between B and B is displayed.

Thus, in this example, user A. A is user B.A. After confirming the single payment history of user B, user B.B will pay part or all of the payment amount. It is configured so that remittance can be made to B.

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

First, the control unit 11 of the server 10 controls the user B. A payment token for B's account is generated, and code reader information, which is information for reading the code including the payment token, is generated. Then, the control unit 11 of the server 10 transmits the generated code reader information to the terminal 20B through the communication I/F 14 (S710).

When the code reader information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B activates the imaging unit 27 to read the code, for example and not limitation, based on the received code reader information. Then, the control unit 21 of the terminal 20B uses the activated imaging unit 27 or the like to read the code for reading the payment store code. Then, the control unit 21 of the terminal 20B acquires the store ID from the payment store code, and transmits the user account settlement request information including the payment token, the store ID, and the scheduled settlement amount as an example and not limitation to the communication I/ It is transmitted to the server 10 by F22 (B710).

When the user account payment request information is received from the terminal 20B through the communication I/F 14, the control unit 11 of the server 10, based on the received payment token, the user B. For the account of B, a user account settlement process is executed to pay the planned settlement amount with the member store determined by the store ID (S720). When the settlement process is successful, the control unit 11 of the server 10 stores the settlement history in the second account management database 155B.

As an example and not a limitation, based on the user's operation on the input/output unit 23 of the terminal 20B, the user B. B's account and user A.B. When generation of a linked wallet with A's account is selected, the control unit 21 of the terminal 20B communicates linked wallet generation request information including the application ID of the account linked to the linked wallet as an example and not as a limitation. /F22 to send to the server 10 (B720).

When the cooperative wallet generation request information is received from the terminal 20B through the communication I/F 14, the control unit 11 of the server 10 generates a record of the cooperative wallet management data using the application ID of the cooperative wallet generation request information as the cooperative account data. Approval is set to "Not". Then, for the application ID of the user of the terminal 20B, cooperation approval is set to "completed" (S730).
Then, the control unit 11 of the server 10 transmits wallet cooperation approval confirmation information to the terminal 20A (S510).

When the wallet cooperation approval confirmation information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A determines whether to approve the cooperation (A710). to the server 10 via the communication I/F 22 (A720). Details of steps A710-A720, by way of example and not limitation, may be performed similarly to steps B500-B510 of FIG. 10-4. If the cooperation is not approved (A710: NO), the control unit 21 of the terminal 20A terminates the process.

When wallet cooperation 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 cooperation approval of the application ID of the user of the terminal 20A to "completed".
On the other hand, if the wallet cooperation approval information is not received (S520: NO), the control unit 11 of the server 10 terminates the process.

As an example and not a limitation, when the wallet cooperation approval information is received from the terminal 20A, the control unit 11 of the server 10 transmits the wallet cooperation approval information to the terminal 20B via the communication I/F 14. It is also possible to notify the terminal 20B (user B.B) that cooperation has been approved.

Next, the control unit 11 of the server 10 requests the user B. User account settlement history information, which is the history of payments made with the user account of B, is transmitted to the terminal 20A via the communication I/F 14 (S740).

As a non-limiting example, the payment history to be sent may be limited to the history for a predetermined period before the linked wallet generation process is performed, or may not be sent.
Further, the linked wallet generation request information may or may not include information for selecting the payment history to be transmitted in step S740.

When the communication I/F 22 receives the user account settlement history information from the server 10, the control unit 21 of the terminal 20A displays the user account settlement history information on the display unit 24 (A730).

Then, as a non-limiting example, the control unit 21 of the terminal 20A executes steps A140 to A160 in FIG. 2-2 using the amount obtained by splitting the total payment amount in the settlement history as the recommended remittance amount. Note that the control unit 21 of the terminal 20A may or may not acquire the recommended remittance amount based on the user's 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 the 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 terminates the process.

In the above processing, an example of linking accounts of different users has been described, but as described above, multiple accounts of the same user may be linked or may not be linked.

<Effect of the 17th embodiment>
In the present embodiment, the terminal 20 has a first user account (not limited, but an example of a first user) of its own terminal 20 user (not limited, but an example of a first user) and a second user account. Wallet cooperation approval confirmation information (not limited, but an example of the first information) for performing account cooperation settlement based on ) is displayed on the display unit 24 .
In addition, the terminal 20 performs processing related to account linkage/linkage approval (not limited to, processing related to associating the first account and the second account) based on the input of the display of the wallet linkage approval confirmation information by the user of the terminal 20 itself. (an example) is performed by the control unit 21 .
Then, based on the account linkage/linkage approval (not limited, but an example of association between the first account and the second account), the terminal 20 provides at least information on the history of payments made by the second user account (not limited, An example of information on the first payment made by at least the second account) is displayed on the display unit 24. FIG.
As an example of the effect of the embodiment obtained by such a configuration, based on the association between the first account and the second account, at least information regarding the first payment made by the second account is displayed on the display unit of the terminal. Thus, by way of example and not limitation, the first user can verify and understand the content of the first payment made by at least the second account before the first and second accounts are associated.

Also, in this case, the terminal 20, based on the input of the displayed payment history information by the user of the terminal 20 itself, the amount of part or all of the payment amount (not limited to, the amount of the first payment) A process for transferring at least a portion of a first amount of money from a first user account of a first user to a second account (without limitation, a process related to transferring money from a first account to a second account). example) can be performed by the control unit 21 .
As an example of the effect of the embodiment obtained by such a configuration, the first amount, which is at least part of the first payment, can be transferred to the first payment by a simple method of inputting information on the first payment by the first user. It is possible to transfer money from an account to a second account.

In addition, in the present embodiment, the server 10 establishes a first user account (not a limitation, but an example of a first user) of a terminal 20 user (not a limitation, but an example of a first user) and a second user account. Wallet cooperation approval confirmation information (not limited, but an example of the first information) for performing account cooperation settlement based on the communication I/F 14 is transmitted to the terminal 20 .
In addition, the server 10 performs processing (limited Instead, the control unit 11 performs an example of processing related to associating the first account and the second account).
Then, based on the account linkage/linkage approval (not limited, but an example of association between the first account and the second account), the server 10 provides at least information on the history of payments made by the second user account (not limited, An example of information on at least the first payment made by the second account) is shown to be transmitted to the terminal 20 via the communication I/F 14 .
As an example of the effect of the embodiment obtained by such a configuration, based on the association between the first account and the second account, at least information regarding the first payment made by the second account is transmitted to the terminal of the first user. Thus, by way of example and not limitation, the first user can be made aware of the details of the first payment made by at least the second account before the first and second accounts are associated.

Here, the processing related to account linking (not limited, but an example of processing related to associating the first account and the second account) is not limited to a process of requesting account linking from the terminal 20 to the server 10, , the concept including the process of performing account linkage on the terminal 20 side.

Also, in this case, the server 10, based on the input of the payment history information displayed on the terminal 20 by the user of the terminal 20, the amount of part or all of the payment amount (not limited to the first payment) (an example of a first amount that is at least part of the example) can be performed by the control unit 11 .
As an example of the effect of the embodiment obtained by such a configuration, based on the first user's input of information related to the first payment displayed on the terminal, at least part of the first payment A first amount of money can be transferred from a first account to a second account.

In addition, in the present embodiment, the terminal 20 has a first user account (not limited, but an example of a first user) of its own terminal 20 user (not limited, but an example of a first user) and a second user account. wallet cooperation approval confirmation information (not a limitation, but an example of the first information) for performing account cooperation settlement based on the communication I/F 22 to the second user account.
In addition, the terminal 20 transmits the wallet cooperation approval confirmation information to the second user account, and then, based on the wallet cooperation approval confirmation information, the wallet cooperation approval information (not limited to, the first account and the second account (an example of information related to approval of association) is received from the second account by the communication I/F 22, processing for performing account-linked settlement based on at least the first user account (not limited to, but related to the first settlement example of processing) is performed by the control unit 21 .
Then, the terminal 20 receives the first amount of money remitted from the second user account (not limited, the first An example of the amount of money based on settlement) is shown.
As an example of the effect of the embodiment obtained by such a configuration, after transmitting the first information regarding the association between the first account and the second account to the second account, the first account based on the first information Before receiving from the second account information regarding the approval of the association with the second account, at least after performing the first payment based on the first account, based on the association between the first account and the second account, You can receive the amount based on the first payment sent from the second account.

<Seventeenth Modification (1)>
In the above embodiment, payments made before the linked wallet generation request information is sent from the terminal 20B to the server 10 are retroactively settled between linked accounts, but the present invention is not limited to this.
As an example and not a limitation, retroactive settlement of payments made during the period from when the linked wallet generation request information is sent from the terminal 20B to the server 10 to when the first user account requested to approve the wallet link approves the link. may or may not be used.

It should be noted that during the period from when the cooperative wallet generation request information is transmitted from the terminal 20B to the server 10 until the first user account of the terminal 20A to which the wallet cooperation approval is requested approves the cooperation, the terminal 20A receives the wallet from the server 10. It includes the period from when the cooperation approval confirmation information is received until the first user account approves the cooperation.
For this reason, after the terminal 20A receives the wallet cooperation approval confirmation information (not a limitation, but an example of the first information), it is necessary to retroactively settle payments made between the time when the first user account approves the cooperation. is also included in this.

In addition, during the period from when the cooperative wallet generation request information is transmitted from the terminal 20B to the server 10 until the first user account of the terminal 20A requested to approve the wallet cooperation approves the cooperation, the server 10 sends the wallet to the terminal 20A. This includes the period from when the cooperation approval confirmation information is sent until the first user account approves the cooperation.
For this reason, after the server 10 sends the wallet cooperation approval confirmation information (an example of the first information, not a limitation), it is possible to retroactively settle payments made between the time when the first user account approves the cooperation. is also included in this.

FIG. 17-6 is a flowchart showing an example of the flow of processing executed by each device in this case.
In this figure, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user A.A), the processing executed by the control unit 21 of the terminal 20B (the terminal 20 of the user B.B), the server 10 1 shows an example of processing executed by the control unit 11 of .

After executing step B720, the control unit 21 of the terminal 20B executes step B710. After executing the step of S730, the control unit 11 of the server 10 executes the step of S510, and after executing the steps of S710 to S720, executes the step of S520.

As a result, in the user account settlement history information transmitted in step S740, after the cooperative wallet generation request information was transmitted from the terminal 20B to the server 10, the user A.E. It contains information on the history of payments made until A approves the cooperation.

In this modification, the account-linked payment (not limited, but an example of the first payment) is linked and approved after the terminal 20 receives the wallet link approval confirmation information (not limited, but an example of the first information). It shows a configuration that is an account linked settlement performed between.
As an example of the effect of the modification obtained by such a configuration, the first payment made between the terminal receiving the first information and the association between the first account and the second account is performed. , the information about the first payment can be displayed on the display unit of the terminal so that the first user can confirm and grasp the contents.
Also, for the first payment made between when the terminal receives the first information and when the first account and the second account are associated, at least part of the first payment A first amount of money can be transferred from a first account to a second account.

<Seventeenth Modification (2)>
In the above modified example, the payment history information transmitted in step S740 in FIG. 17-6 is information on the payment history in the user account, but it is not limited to this.
As an example and not a limitation, the above payment history information can also be information about the history of payments made in the linked wallet after the creation of the linked wallet until the linked account approves the linkage. In other words, after the generation of the linked wallet, it is possible to display the settlement history and perform retroactive settlement for the settlement with the linked wallet performed until the linked account approves the linkage.

FIG. 17-7 is a diagram showing an example of transition of screens 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, where user A.A. A state in which A has approved cooperation is shown.
In this example, user A. A and user B. After creating the linked wallet, the user A. A linked wallet payment history button BT54 is displayed for displaying the payment history with the linked wallet (hereinafter referred to as "linked wallet payment history") until A approves the collaboration. When this cooperative wallet payment history button BT54 is tapped, the screen on the right side of FIG. 17-7 is displayed.

On this screen, under the current position display area CLR1, the user A. A and user B. An icon and characters indicating the linked wallet payment history (“Purchase History” on the screen) from the linked wallet of B are displayed, and the linked wallet payment history is displayed below it. In this example, the linked wallet payment history related to the purchase of a product worth "2,000 yen" made at "PP Super" at "19:10:33 on August 2, 2020" by the linked wallet is displayed. ing.

In addition, in this display field, user A.A. A is user B.A. For B, a remittance button BT56 for remittance (return) of the paid amount is displayed. In this example, "2,000 yen" is entered by user A. A and user B. A remittance button BT56 for remittance of "1,000 yen" as the amount split between B and B is displayed.

Thus, in this example, user A. Based on the cooperation approval by user B.A, user B.A. After creation of the federated wallet by user A.B, user A. The payment history by the linked wallet made until A approves the link is sent to user A. It is configured so that A can browse and check it on his own terminal 20A.
Furthermore, after confirming the payment history by this cooperative wallet, user A. A pays part or all of the amount paid by the cooperative wallet, and the user B. It is configured so that remittance to B (return of the amount paid in advance) can be performed.

In this case, as an example and not a limitation, even if there is an account that has not been approved for cooperation yet in the cooperative wallet (when there is an account that has not been approved for cooperation), payment with the cooperative wallet is possible. Then, the payment history is stored in the tenth linked wallet management database 157J, and in step S740 in FIG. 17-6, as an example and not as a limitation, the payment history in the linked wallet may be transmitted.

Note that the number of cooperative members of the cooperative wallet is not limited to two (or the number of cooperative accounts is two). The same applies when there are three or more cooperation members (or three or more cooperation accounts).

By way of example and not limitation, user A.A. A and user B.A. B and user C.B. A federated wallet with user A.C is created. A and user C.A. At the stage where user A.C has approved the cooperation, the payment of "900 yen" is executed in the cooperative wallet, and user A.C executes the payment. A and user C.A. Assume that C and C bear the equal payment amount of "450 yen" for two people. After that, user B. If user B approves the cooperation, user B.B. As a non-limiting example, user A.B sends an equal payment amount of "450 yen" for two people and "150 yen", which is an equal payment amount of "300 yen" for three people, to user A.B. A and user C.A. It is sufficient to send money to C and C respectively.

Note that the linked account in the linked wallet is not limited to the user account. As an example and not a limitation, by considering the eighth embodiment, the above method may be applied to a linked wallet between a common wallet and a user account, or to a linked wallet with a plurality of common wallets. You don't have to.

In this modification, the account-linked settlement is performed by a second user account (not limited, but an example of a second account) and a third user account linked with the second user account (not limited, but associated with the second account). An example of a third account) shows a configuration that is an account linked settlement performed by.
As an example of the effect of the modification obtained by such a configuration, information on the first payment made to the second account and the third account associated with the second account is sent to the terminal. so that the first user can confirm and understand the content.
Also, 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 part of the first payment is transferred from the first account to the first account. You can send money to 2 accounts.

In addition, this modification shows a configuration in which the linked second account is a common wallet account (not a limitation, but an example of a common account that can be settled by a plurality of users).
As an example of the effect of the embodiment obtained by such a configuration, it is possible to associate a common account with which a plurality of users can make payments as a second account with the first account, thereby improving user convenience. .

<Seventeenth Modification (3)>
In the above-described embodiment, even if the first user account is in a non-cooperation approval state, the first user account can at least view the payment history by the second user account (the above-mentioned single payment history and cooperative wallet history). , remittance (retroactive settlement) to the second user account.

In this case, as an example and not a limitation, the terminal 20 receives the wallet cooperation approval confirmation information (not a limitation, but an example of the first information) via the communication I/F 22, and displays the received wallet cooperation approval confirmation information (not limited to , an example of the first display) is displayed on the display unit 24 .
In this case, even if the first user account has not yet approved the cooperation, the user of the terminal 20 (the first user) can display the payment history (single payment history or cooperative wallet payment history). When the input is made, the terminal 20 requests the payment history from the server 10, and displays the payment history on the display unit 24 based on the reception of the payment history transmitted from the server 10. can.

Also, in this case, even if the first user account has not yet been approved for cooperation, the terminal 20 will automatically transfer part or all of the payment amount based on the input to the displayed payment history. It is also possible for the control unit 21 to perform processing for transferring money from the first user account of the user (first user) of the terminal 20 to the second account.

<Seventeenth Modification (4)>
As mentioned above, as a period to be subject to retroactive settlement, as an example, not as a limitation,
(a) The period before the linked wallet generation request information is sent from the terminal 20B to the server 10 (b) The user account requested to approve the wallet linkage after the linked wallet generation request information is sent from the terminal 20B to the server 10 Either of the period until the joint approval can be applied.

However, by way of example and not limitation, the period (a)+(b) may or may not be the period subject to retroactive settlement.

Also, the period for which the payment history (settlement history) is displayed may be different from the period for which the retroactive settlement is to be performed, or the period may be different.
As a non-limiting example, the payment history display target period is (a)+(b), but the retroactive settlement target period is (a). Alternatively, as a non-limiting example, the payment history may be displayed for the period (a) + (b), but the period for retroactive settlement may be the period (b). .

<Eighteenth embodiment>
In the 17th embodiment, it has been explained that payment related to the linked wallet is possible even if all linked wallet members have not approved the collaboration.
In this regard, the 18th embodiment generates a cooperative wallet for each group of messaging applications (messaging services), and makes payments using the cooperative wallet of this group even if all group members do not approve cooperation. This is an embodiment that enables execution of

The content described in the eighteenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

In this embodiment, the storage unit 15 of the server 10 stores the information shown in FIG. 4-1 as an example and not as a limitation.
FIG. 18-1 is a diagram showing a data configuration example of an 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.

Each linked wallet management data stores, as a non-limiting example, a group ID, a group name, linked status management data, payment history data, reimbursement history data, and payment participation account data. The group ID, group name, cooperation status management data, payment history data, and payment history data are the same as those of the fifth cooperative wallet management database 157E, for example and not limitation.

The payment participation account data is data for storing the accounts linked at the time of payment for each payment (payment) stored in the payment history data. stored in association with an ID.

The transaction ID is identification information for identifying a settlement (payment) in settlement history data. The payment participating account ID is the application ID of the linked account for which the linked wallet has been approved for linkage when the payment identified by the transaction ID is executed.

In FIG. 18-1, by way of example and not limitation, when paying with "XX instrument", user A.A. A and user B. It shows that B agreed to pay with the linked wallet. That is, the payment with "XX musical instrument" in the linked wallet of the group "band mates" can be made by user A. A and user B. B is involved (incurred) and user C.B. It is shown that C is not involved in (does not pay for) the payment.

<Display screen>
In the following, user A. who is also a user of a messaging application and a user of a payment application. A and user B.A. B and user C.B. Both C and C belong to the group "band friends" and are registered as friends.

Also, user A. A creates a cooperative wallet for "bandmates", and user B.A. B and user C.B. Before C approves the cooperation, he pays "4,500 yen" with "XX musical instrument" using the cooperative wallet of "Band Associates".

FIG. 18B is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20 in this embodiment.
The left side of FIG. 18-2 shows an example of the chat room screen of the messaging application displayed on the display unit 24 of the terminal 20A.
This talk room screen is a group talk room screen of the group "bandmates", and user A.I. A is user B.A. B and user C.B. A state of talking (chatting) with C is shown.

In this example, a message to the effect that a product (a live score in this example) has been purchased is sent to user A.A. A is called by user B.A and the payment is made by all members of the group. proposed by B. However, user C.I. User C.C is out of money, so a message stating that payment will be made later is sent to user C.C. A.C originates from user A.C. A's accepted state is shown. In this state, when the linked wallet icon IC1 at the bottom of the screen is tapped, the screen in the center of FIG. 18-2 is displayed.

In this screen, the cooperative wallet information display area WIR1 is displayed rising from the lower part of the screen of the group chat room on the left side of FIG. 18-2. In this cooperative wallet information display area WIR1, the message "Would you like to request wallet cooperation?" indicated to be a member. In this state, when the wallet cooperation request button BT35 is tapped, wallet cooperation request information is transmitted from the terminal 20A to the terminals 20B and 20C via the server 10. FIG.

The right side of FIG. 18-2 shows an example of the chat room screen of the messaging application displayed on the display unit 24 of the terminal 20B in this case.
This talk room screen is a group talk room screen of the group "bandmates", and user A.I. A is user C. Underneath the message of acceptance of C's deferred payment, user A.C. A wallet cooperation request message from A is displayed. User A. A message is displayed reporting that A has purchased the product.

In the wallet cooperation request message, user A. In addition to characters and images indicating that wallet cooperation has been requested from A, as a non-limiting example, a cooperation approval button and a cooperation refusal button are included.
When the cooperation approval button is tapped, the screen on the left side of FIG. 18-3 is displayed on the display unit 24 of the terminal 20B.

In this screen, a linked wallet information display area WIR1 is displayed rising from the lower part of the talk room screen of the group "Bandmates".
In the linked wallet information display area WIR1, a linked wallet payment history button BT54 is displayed in the information display field indicating that the linked wallet belongs to the group "bandmates."

User A. is displayed in the cooperation member information display area MIR1. A and user B. For user C.B, the electronic money account balance is displayed. Since C is in a non-collaboration approval state, a "requesting" mark is displayed.

When the linked wallet payment history button BT54 is tapped, the screen in the center of FIG. 18-3 is displayed.
In this screen, in the linked wallet information display area WIR1, information related to the payment of "4,500 yen" to "XX musical instrument" is displayed as the payment history of the linked wallet of the group "band friends". Also, in this display column, a settlement button BT58 is displayed for retroactive settlement of 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 on the settlement details is displayed in a pop-up format in the center of the linked wallet information display area WIR1. In this example, user C.I. Since user A.C is in the non-cooperation approval state, A and user B. The payment will be borne by two people, B.

The above payment is for user A. After creation of the federated wallet by A, user B.A. This is the payment for the linked wallet made until B approves the link. Therefore, user B. B needs to retroactively settle the amount of his own share. In this example, the user B.D. B to user A.B. The contents of remittance of "2,250 yen" to A are displayed. When the "Yes" button provided below is tapped, user B. B to user A.B. Remittance to A is made.

FIG. 18-4 is a diagram showing an example of the talk room screen displayed on the display unit 24 of the terminal 20 of each member of the group "bandmates" in the above example.
Examples of group talk room screens displayed on the terminals 20A, 20B, and 20C are shown in order from the left.

On the group chat room screen displayed on the terminal 20A, in chronological order, the payment completion notification message by the linked wallet→user A.A. Product purchase report message from cooperative wallet from A → User B. Messages are displayed in the order of wallet cooperation message by B → settlement completion notification message.

On the group talk room screen displayed on the terminal 20B, users A.A. Product purchase report message from cooperative wallet from A → User B. Messages are displayed in the order of wallet cooperation message by B → settlement completion notification message by cooperative wallet → settlement completion notification message.

On the group talk room screen displayed on the terminal 20C, users A.A. Wallet cooperation request message from User A. Product purchase report message from cooperative wallet from A → User B. Messages are displayed in the order of wallet cooperation message by B.

In this example, the settlement completion notification message and the settlement completion notification message are not displayed on the group talk room screen displayed on the terminal 20C. This is because user C.I. This is because C is in the state of uncoordinated approval and is not involved in payment at this time.

FIG. 18-5 is a diagram showing an example of the chat room screen of the messaging application displayed on the display unit 24 of the terminal 20C.
This talk room screen is a group talk room screen of the group "Band Friends", and in the screen on the left side of Fig. 18-5, the cooperative wallet information display area WIR1 rises from the bottom of the talk room screen of the group "Band Friends". are displayed.

In the linked wallet information display area WIR1, user C.I. Since C is in the non-cooperation approved state, the use of the cooperative wallet is restricted.
Specifically, the code reader icon IC2 and the code payment icon IC3 are grayed out, and are configured not to accept the operation even if they are tapped.
The cooperative wallet payment history button BT54 is also grayed out, and is configured not to accept the operation even if tapped.
In addition, the linked wallet discard button BT30 is also grayed out, and is configured not to accept the operation 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.
In this screen, information indicating that payment cannot be made without wallet cooperation is displayed in a pop-up format in the center of the linked wallet information display area WIR1. Specifically, the text "Payment cannot be made without cooperation" is displayed. "
Below that, there is a link approval button labeled "Link Wallet", and when the link approval button is tapped, restrictions on the use of the linked wallet are also lifted.

<Processing>
FIG. 18-6 is a flowchart showing an example of the flow of processing executed by each device in this case.
This figure shows an example of processing executed by a system composed of the terminal 20 and the server 10 . The server 10 may or may not be divided into a payment application management server that manages payment services and a messaging application management server that manages messaging services.

First, as an example and not a limitation, based on the user's operation on the terminal 20, a cooperative wallet generation process is executed for generating a new cooperative wallet (L100).

It should be noted that the trigger/condition for execution of the cooperative wallet generation process is not limited to the operation in the group chat room described in the example of the display screen. By way of example and not limitation, creation of a new group may or may not automatically trigger a federated wallet creation process for that group.
Also, in a chat room between two users, when the chat room is created, a cooperative wallet may be automatically created in the chat room, or may not be so. In this case, the talk room should be treated as a group of two members.

FIG. 18-7 is a flow chart showing an example of the flow of processing executed by each device in the cooperative wallet generation processing.
In this figure, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user AA), which is the terminal of the user who instructs the generation of the cooperative wallet in a certain group, is the terminal of this group member. An example of processing executed by the control unit 21 of the terminal 20B (user BB's terminal 20) and processing executed by the control unit 11 of the server 10 is shown.

The control unit 21 of the terminal 20A executes steps A500 to A510. When the control unit 11 of the server 10 executes steps S500 to S505, it becomes possible to generate a cooperative wallet payment token for the cooperative wallet in this group, and communicates cooperative wallet information indicating that the cooperative wallet can be used. The I/F 14 sends to the terminal 20 (in this case, the terminal 20A) for which cooperation approval is "completed" in the fifth cooperative wallet management database 157E (S750). Then, the control unit 11 of the server 10 sends the wallet cooperation approval confirmation information to the terminals 20 (in this case, in this case, As an example, it transmits to the terminal 20B) (S760).

When the cooperative wallet information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A executes step A540 and terminates the process. Further, when the wallet cooperation approval confirmation information is received from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the wallet cooperation approval confirmation information (B750), and terminates the process.

Returning to FIG. 18-6, if cooperation approval is selected (L110: cooperation approval) based on the user's operation on the terminal 20 for which cooperation approval is "not yet", account addition cooperation processing is executed (L120 ).

FIG. 18-8 is a flowchart showing an example of the flow of processing executed by each device in account addition cooperation processing.
In this figure, from the left side, processing executed by the control unit 21 of the terminal 20A (terminal 20 of user A.A) which is the terminal of the linked user, terminal 20B (terminal 20 of user B.B) which is the terminal of the uncoordinated user, An example of processing executed by the control unit 21 of the terminal 20) and processing executed by the control unit 11 of the server 10 is shown.

When wallet cooperation approval information is received from the terminal 20B via the communication I/F 14 (S520: YES), the control unit 11 of the server 10 sets the cooperation approval of the cooperation status management data for the application ID of the received terminal to "completed". change and execute the step of S530. If the wallet cooperation approval information is not received (S520: NO), the control unit 11 of the server 10 skips the step of S530. Then, the control unit 11 of the server 10 executes steps S750 to S760 and terminates the process.

After executing step A520, the control unit 21 of the terminal 20A executes step A540 and terminates the process.

When cooperative wallet information is received from the server 10 via the communication I/F 22 (B530: YES), the control unit 21 of the terminal 20B executes step B540 and terminates the process. When the cooperative wallet information is not received (B530: NO), the control unit 21 of the terminal 20B receives the wallet cooperation approval confirmation information from the server 10 through the communication I/F 22, and causes the display unit 24 to display the wallet cooperation approval confirmation information (B760). ) to end the process.

Returning to FIG. 18-6, in the account addition cooperation process, if the cooperation wallet has newly been approved for cooperation of the account (L130: YES), the cooperative wallet retroactive settlement process is executed (L140). If the cooperation wallet has not been approved for cooperation (L130: NO), the process returns to step L110.

It should be noted that even if the account is newly approved for cooperation (L130: YES), as an example and not as a limitation, if there is no approval for retroactive settlement on the terminal 20 that has been newly approved for cooperation, the cooperative wallet retroactive settlement process may or may not be executed.

FIG. 18-9 is a flow chart showing an example of the flow of processing executed by each device in the linked wallet retroactive settlement processing.
In this figure, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user AA) which is the terminal of the user whose account has already been linked, the terminal 20B (the terminal 20B of the user who has newly linked the account) An example of the processing executed by the control unit 21 of the terminal 20 of B.B and the processing executed by the control unit 11 of the server 10 is shown.

The control unit 11 of the server 10 refers to the payment participation account data in the 11th linked wallet management database 157K, and searches for a transaction ID in which the newly approved account does not participate in the payment by the linked wallet. Then, based on the retrieved transaction ID, settlement history data, and reimbursement history data, the amount required for retroactive settlement for each transaction ID and the remittance amount to each account are calculated, and linked with the settlement history data. to generate linked wallet retroactive settlement candidate information. Then, the control unit 11 of the server 10 transmits the linked wallet retroactive settlement candidate information to the terminal 20B via the communication I/F 14 (S765).

By way of example and not limitation, if the payment in the linked wallet is split, the amount required for retroactive settlement and the amount to be transferred to each account can be calculated as follows, by way of example and not limitation.
・Amount required for retroactive settlement = Amount paid for settlement ÷ (Number of accounts recorded in settlement participation account data + 1)
・Remittance amount to each account recorded in payment participation account data = Amount required for retroactive settlement ÷ Number of accounts recorded in payment participation account data

When determining the remittance amount to an account for which reimbursement history data exists, refer to the reimbursed amount, increase the remittance amount to the reimbursed person's maximum reimbursement amount, and then remit the remittance amount to the reimbursed person by that amount. may or may not be reduced. In this case, the control unit 11 of the server 10 updates the payment amount when retroactive settlement is executed. When the payment amount is "0", the control unit 11 of the server 10 deletes the payment history of the transaction from the payment history data.

Upon receiving the candidate information for the retroactive settlement of the linked wallet from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B retroactively performs each transaction of the candidate information for the coordinated wallet retroactive settlement based on the user's operation. It is determined whether or not to remit the amount required for settlement, and retroactive settlement information, which is information on transactions for which retroactive settlement is to be executed, is transmitted to the server 10 via the communication I/F 22 (B780).

The amount required for retroactive settlement and the amount to be remitted to each account may or may not be calculated by the terminal 20B based on the settlement history data and the payment history data. . Also, the required amount for retroactive settlement and the amount to be remitted to each account may or may not be determined based on the user's operation on the terminal 20B.

When the communication I/F 14 receives the retroactive settlement information from the terminal 20B, the control unit 11 of the server 10 sends the selected transaction to the user B. Execute remittance from B's account to each account recorded in the payment participation account data. Then, when the amount required for retroactive settlement is remitted, the control unit 11 of the server 10 adds and stores the user account for which the retroactive settlement was performed to the payment participating account data (S780).

After that, the control unit 11 of the server 10 transmits retroactive settlement result information, which is the remittance result in the retroactive settlement process, to each terminal via the communication I/F 14 (S790). Then, the control unit 11 of the server 10 terminates the process.

The retroactive settlement result information may or may not include remittance information unrelated to the account of the terminal that receives the retroactive settlement result information. Further, the retroactive settlement result information may be transmitted to all group members, or may be transmitted only to the terminals of members whose cooperation approval is "completed".

When the retroactive settlement 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 retroactive settlement result information (A760), and terminates the process.
When the retroactive settlement 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 retroactive settlement result information (B790), and terminates the process.

Returning to FIG. 18-6, when the linked wallet retroactive settlement process is executed, the process returns to step L110.

As an example and not a limitation, when execution of payment by the linked wallet is selected based on the user's operation on the terminal 20 (L110: payment), the control unit 11 of the server 10 instructs the terminal 20 to execute the payment. account is "completed" for cooperation approval (L150).

If the account of the terminal 20 for which payment is to be made has been approved for cooperation (L150: YES), cooperative wallet payment processing is executed (L160). Federated wallet payment processing may be performed, by way of example and not limitation, in accordance with FIG. 7-3.

In the cooperative wallet payment process, when the cooperative payable amount is insufficient and the cooperative balance replenishment process is executed (L170: YES), the cooperative wallet settlement process is executed (L180). After executing the cooperative wallet settlement process, the process returns to step L110.
Note that the cooperative wallet settlement process can be executed according to FIG. 7-5 as an example and not as a limitation.

If there is no advance payment for the cooperative payable amount in the cooperative wallet payment process (L170: NO), the cooperative wallet settlement process is not executed.

In addition, even if advance payment related to the cooperative payable amount did not occur in the previous linked wallet payment process, if there is advance history data in the previous linked wallet payment process and the advance has not been resolved, the linked wallet Settlement processing may or may not be performed.

If the account of the terminal 20 for which payment is to be made has not been approved for cooperation (L150: NO), the cooperative wallet payment process is not executed, and the process returns to step L110.
In this case, the wallet cooperation approval confirmation information may be displayed again on the display unit 24 of the terminal 20 where the payment is to be executed to prompt the cooperation approval, or it is not necessary.

As an example and not a limitation, when confirmation of the payment history by the cooperative wallet is selected based on the user's operation on the terminal 20 (L110: history confirmation), the control unit 11 of the server 10 attempts to execute the payment. It is determined whether or not the account of the terminal 20 to be the target is “completed” in cooperation approval (L185). If the account of the terminal 20 for which payment is to be made has already been approved for cooperation (L185: YES), a cooperative wallet payment history confirmation 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 checks the payment history data and the payment history data of this linked wallet via the communication I/F 14. Send to the requesting terminal 20 (terminal 20A as an example and not as a limitation). In addition, the settlement participation account data may be transmitted, or may not be transmitted.

Note that the control unit 11 of the server 10 may or may not transmit only the transaction history after the terminal 20A has performed cooperation approval, out of the payment history data and the payment history data. good too.

When the payment history data and the payment history data are received from the server 10 by 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 payment history data.
Note that the control unit 21 of the terminal 20A additionally receives the payment participation account data, and displays only the history of the transactions after the terminal 20A has performed cooperation approval, out of the payment history data and the advance payment history data. may or may not.

Based on the user operation on the input/output unit 23 of the terminal 20A, the control unit 11 of the server 10 selects from the displayed settlement history data the payment on behalf of the customer or the retroactive settlement related to the payment before the cooperation approval (L200: YES). determines the content of the settlement (L210).
Then, if the settlement content is reimbursement settlement (L210: reimbursement settlement), cooperative wallet settlement processing is executed (L180). On the other hand, if the settlement content is retroactive settlement related to payment before cooperation approval (L210: retroactive settlement), cooperative wallet retroactive settlement processing is executed (L140).
It should be noted that the advance settlement and the retroactive settlement for a plurality of transactions may be performed collectively, or may not be performed in such a manner.

As an example and not a limitation, based on the user's operation on the terminal 20, when it is selected to destroy the linked wallet (L110: Discard), linked wallet destruction processing is executed (L220). As an example and not a limitation, the cooperative wallet destruction process can be executed according to the steps following S340 in FIG. 7-4. The system then terminates processing.

Note that the cooperative wallet retroactive settlement process, the cooperative wallet settlement process, or both may or may not be executed before executing the cooperative wallet destruction process. Also, if the transaction remains in the payment history data, the linked wallet destruction process may or may not be executed. If the retroactive settlement has not been completed, the cooperative wallet destruction 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 in this embodiment is executed.
Here, the timing at which each terminal is instructed to execute the account addition linkage process, the linked wallet payment process, and the linked wallet retroactive settlement process described in the above flow will be described. To simplify the explanation, let's consider a case where advance payment does not occur in cooperative wallet payment processing.

Let the terminal 20A be a terminal that executes cooperative wallet generation. Terminals of other cooperative members of the cooperative wallet are terminals 20B and 20C.
In this timing chart, the horizontal axis is the time axis, the timing of each terminal 20 performing account addition linkage processing is indicated by a white hexagon, the timing of linked wallet payment processing is indicated by a white circle, and the linked wallet retroactive settlement processing is indicated by a white circle. The white rectangles indicate the timings of execution.

After the cooperative wallet generation process, payment 1 is executed at the terminal 20A. For payment 1, user A. Only A participates.
After that, the terminal 20B executes an account addition cooperation process. Then, in the terminal 20B, the cooperative wallet retroactive settlement process for the payment 1 is executed.

Payment 2 is then performed at terminal 20B. Payment 2 is for user A. A and user B. B is participating.
After that, the terminal 20C executes an account addition cooperation process. Then, in the terminal 20C, the cooperative wallet retroactive settlement process for Payment 1 and Payment 2 is executed.
Then, payment 3 is executed at the terminal 20C. For payment 3, user A. A and user B. B and user C.B. Participating in C.

Finally, the linked wallet destruction process is executed by one of the terminals 20, and the process ends.

<Effect of the 18th embodiment>
In this embodiment, the wallet linkage approval confirmation information (an example of the first information, not limitation) is a token by the second user of the second user account, including the first user of the first user account and the second user. It shows the configuration sent to the terminal 20 of the first user based on the input to the room (an example of a chat room, not a limitation).
As an example of the effect of the embodiment obtained by such a configuration, based on the input by the second user of the second account to the chat room containing the first user and the second user, the first information is can be easily sent to other terminals.

In addition, in this embodiment, the wallet cooperation approval confirmation information (an example of the first information, not limitation) is the first user of the first user account and the second user by the second user of the second user account. It shows the configuration sent to the terminal 20 of the first user based on the creation of a talk room (an example of a chat room, not a limitation).
As an example of the effect of the embodiment obtained by such a configuration, based on the creation of a chat room including the first user and the second user by the second user of the second account, the first information is the first user can be easily sent to other terminals.

In these cases, the terminal 20 transfers part or all of the settlement amount to the second user account based on the process for transmitting the amount from the first user account to the second user account. Information indicating this can be displayed in the talk room.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to notify the first user of the first account that the first amount of money has been transferred to the second account in an easy-to-understand manner by displaying it in the chat room. can.

In addition, in these cases, if the first user account and the second user account are not linked, the terminal 20 will use the payment code based on the first user account and the second user account (not limited to, the 1 code information), or a code reader screen (not limited to, second An example of display for reading code information) can be controlled not to be displayed on the display unit 24 by the control unit 21 .
As an example of the effect of the embodiment obtained by such a configuration, if the first account and the second account are not associated, settlement based on the first account and the second account cannot be performed. can be

<18th Modification (1)>
In the above embodiment, it has been explained that the payment history in the cooperative wallet can be checked after approval of the cooperation, but it is not limited to this.
As in the seventeenth modification (3), after the creation of the linked wallet, it may be possible to check the payment history in the linked wallet even on the terminal 20 of the account for which the collaboration approval is "not yet". does not have to be

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 left and center terminals 20A in FIG. 18-11 are the same as those in 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. there is

Specifically, the user A. is the oldest in chronological order. Wallet cooperation request message from A → payment completion notification message by cooperative wallet → user A.A. The messages are displayed in the order of a product purchase report message from the affiliated wallet from A.
That is, in this display screen example, the user B. Before B approves the cooperation, it is configured so that the payment history by the cooperative wallet can be confirmed on the group talk room screen displayed on his own terminal 20B.

In this case, as an example and not a limitation, step L185 in FIG. 18-6 is not executed, and step L190 is executed when L110: history confirmation is reached. After executing the step of L190, the process returns to L110.

<18th Modification (2)>
In the above embodiment, after confirming the payment history of the linked wallet, the advance payment and the retroactive payment are executed, but the present invention is not limited to this.
As a non-limiting example, if lump sum payment settlement is selected in step L110 in FIG. may
Also, as a non-limiting example, when lump-sum retroactive settlement is selected in step L110 in FIG. You don't have to.
Alternatively, the collective advance settlement and the collective retroactive settlement may be executed collectively, or may not be executed in such a manner.

<Nineteenth embodiment>
In the 18th embodiment, the linked wallet retroactive settlement process is described as a process in which the user of the newly approved account actively settles the payment before the approval of the link, but it is not limited to this.
The 19th embodiment is an embodiment in which a user who newly approves cooperation is prompted to make a payment before approval of cooperation.

The content described in the nineteenth embodiment can be applied to each of the other embodiments and each of the other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

<Display screen>
FIG. 19A is a diagram showing an example of screen transitions displayed on the display unit 24 of the terminal 20A in this embodiment.
On the left side of FIG. 19-1, the cooperative wallet information display area WIR1 is displayed rising from the bottom of the screen of the group talk room of the group "Band Friends". In addition, a linked wallet payment history button BT54 is displayed in the information display column indicating that the linked wallet belongs to the group "Band Friends". When this cooperative wallet payment history button BT54 is tapped, the screen in the center of FIG. 19-1 is displayed.

In this screen, user A. is displayed in the linked wallet payment history display field in the linked wallet information display area WIR1. A request for demanding payment of at least part of the payment amount of "4,500 yen" paid by A to purchase a product from another cooperative member (user B.B in this example). A payment reminder button BT60 including characters is displayed. When this payment reminder button BT60 is tapped, the screen on the right side of FIG. 19-1 is displayed.

In this screen, in the central part of the linked wallet information display area WIR1, information for confirming a reminder for past payments in the linked wallet is displayed in a pop-up format. Specifically, the text "Are you asking for past payments?" User B. asks A to pay "2,250 yen". Information indicating that B is being urged is displayed. Further, a "Yes" button and a "No" button are displayed below it, and when the "Yes" button is tapped, user A.A. A to user B. A payment reminder is sent to B.

FIG. 19-2 is a diagram showing an example of a screen displayed on the display unit 24 of each cooperation member's terminal 20 in this case.
The left side of FIG. 19-2 is a group chat room screen displayed on the terminal 20A. Product purchase report message from user B. Messages are displayed in order of cooperation approval message by B.

The center of FIG. 19-2 is a group talk room screen displayed on terminal 20B, and by way of example and not limitation, user A.B. Product purchase report message from user B. Message of approval of cooperation by B → Message of completion of payment in cooperative wallet → User A.B. The messages are displayed in the order of payment reminder message from A.

A payment reminder message is sent to user A. A to user B. A message corresponding to a payment reminder to B.
In this payment reminder message, along with the text of the payment application [Payment App] and the text of "Ask", information regarding the details of the payment reminder is displayed.
In addition, the payment reminder message is provided with a settlement button, and by tapping the settlement button, the user A.A. Accounting for payment reminders from A, ie, user B.A. B to user A.B. Remittance to A is possible.

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, user A.A. Wallet cooperation request message from User A. Product purchase report message from user B. Messages are displayed in order of cooperation approval message by B.

In this example, no payment reminder message is displayed in the group chat room displayed on terminal 20A. This is because user A. This is because A is the person who requested payment.
Note that the payment reminder message may also be displayed in the group chat room displayed on the terminal 20A without being limited to this.

Also, the payment reminder message is not displayed in the group talk room displayed on terminal 20C. This is because user C.I. This is because C is in a non-collaboration approval state and is currently not involved in payment.

<Processing>
FIG. 19-3 is a flow chart 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 side, processing executed by the control unit 21 of the terminal 20A (terminal 20 of user A.A), which is the terminal of the linked user, terminal 20B (terminal 20 of user B.A.), which is the terminal of the newly linked user. An example of the processing executed by the control unit 21 of the terminal 20) of B and the processing executed by the control unit 11 of the server 10 are shown.

Upon receiving the candidate information for the retroactive settlement of the linked wallet from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A retroactively performs each transaction of the candidate information for the coordinated wallet retroactive settlement based on the user's operation. It is determined whether or not to demand the remittance of the amount required for settlement, and retroactive settlement request information, which is information on the transaction for which the demand is to be executed, is transmitted to the server 10 via the communication I/F 22 (A740).

The amount required for retroactive settlement and the amount to be remitted to each account may or may not be calculated by the terminal 20A based on the settlement history data and the payment history data. . Further, the amount required for retroactive settlement and the amount to be remitted to each account may or may not be determined based on the user's operation on the terminal 20A.

When the retroactive settlement request information is received from the terminal 20A by the communication I/F 14, the control unit 11 of the server 10, based on the retroactive settlement request information, for example, not as a limitation, retroactive settlement request including the amount required for retroactive settlement for each transaction After the transaction, the information is transmitted to the terminal 20 (the terminal 20B in this case) that has performed the cooperation approval through the communication I/F 14 (S770).

It should be noted that when the server 10 is composed of a payment application management server and a messaging application management server, for example and not limitation, the payment application management server receives retroactive settlement request information and receives a request from the payment application management server. The messaging application management server may or may not transmit the retroactive settlement request information to the terminal 20B. Alternatively, the messaging application management server may receive the retroactive settlement request information and transmit the retroactive settlement request information without going through the payment application management server.

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 causes the display unit 24 to display the retroactive settlement request information (B770).

Note that the control unit 11 of the server 10 may or may not transmit the retroactive settlement request information to the terminal 20A so that the terminal 20A can confirm that the retroactive settlement request information has been transmitted. . Then, the control unit 21 of the terminal 20A may or may not cause the display unit 24 to display the received retroactive settlement request information.

When executing retroactive settlement of a transaction (payment) for which retroactive settlement is requested based on the user's operation on the input/output unit 23 of the terminal 20B (B775: YES), the control unit 21 of the terminal 20B performs steps B780 to B790. to run.
When retroactive settlement information is received from the terminal 20B via the communication I/F 14 (S775: YES), the control unit 11 of the 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.

<Effect of the 19th embodiment>
In this embodiment, the terminal 20, based on the cooperation between the first user account and the second user account, at least information of the payment history made by the second user account (not limited to, but an example of information on the second payment) is displayed on the display unit 24 . Also, the terminal 20 shows a configuration for receiving, through the communication I/F 22, information prompting payment based on this payment history (not a limitation, but an example of second information regarding a payment request for the second payment).
As an example of the effect of the embodiment obtained by such a configuration, based on the association between the first account and the second account, at least information regarding the second payment made by the second account is displayed on the display unit of the terminal. Thus, by way of example and not by way of limitation, the first user can see and understand information regarding the second payment made by at least the second account prior to the association of the first and second accounts.

Also, in this case, the terminal 20 displays information prompting payment in a talk room (not limited to, but an example of a chat room) containing the user of the terminal 20 itself and the second user of the second user account ( The control unit 21 can perform control to display (an example of the second display based on the second information) without limitation.
As an example of the effect of the embodiment obtained by such a configuration, the first user can make the payment for the second payment after confirming the received second information regarding the payment request for the second payment.

Also, 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 included in the talk room.
As an example of the effect of the embodiment obtained by such a configuration, second information can be easily obtained from a server that relays messages sent and received between a first user and a second user included in a chat room. .

Also, in this case, the display of the information prompting payment can be displayed in the first user's talk room, but not displayed 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 payment for the second payment has been requested. On the other hand, it is possible to eliminate the need to confirm that the payment has been requested for the user (second user) who requested the payment.

Also, in this case, the terminal 20 may, based on the input by the first user in response to the display of information prompting payment displayed in the talk room, part or all of the payment amount (not limited to the second amount of money) from the first user account to the second user account (not limited, but an example of processing related to remittance from the first account to the second account) is performed by the control unit 21 be able to.
As an example of the effect of the embodiment obtained by such a configuration, the second amount, which is at least part of the second payment, can be obtained by a simple method of inputting by the first user to the second display displayed in the chat room. can be transferred from the first account to the second account.

<Nineteenth Modification (1)>
Although the retroactive settlement request information is transmitted from the server 10 in the above embodiment, it is not limited to this. As an example and not a limitation, in step A740 of FIG. It doesn't have to be.

Then, the control unit 21 of the terminal 20B may cause the display unit 24 to display the received retroactive settlement request information, and accept the selection of whether or not to perform retroactive settlement (B775), or may not do so. good.

<Twentieth embodiment>
In the above embodiment, destruction of the linked wallet (batch invalidation of linked wallets for all linked accounts) has been described, but the present invention is not limited to this.
The twentieth embodiment is an embodiment relating to a method for each linked account to cancel account linkage.

The content described in the twentieth embodiment can be applied to each of the other embodiments and other modifications.
Moreover, the same code|symbol is attached|subjected about the component same as an already-appearing component, and description for the second time is abbreviate|omitted.

"Cancellation of account linkage" in this embodiment includes, by way of example and not limitation, any of the following.
(a) Cancellation of cooperation approval (b) Deletion of cooperation account

(a) means returning the cooperation approval "completed" to "not yet". In this case, in the linked wallet management data, the linked account data remains without being deleted, but the linked account cannot be used.

(b) means deleting the linked account data in the linked wallet management data. In this case also, the linked account cannot be used.

By way of example and not limitation, the above account unlinking occurs when a federated account (the user of that federated account) wishes to leave the federated wallet.

In addition, in the above (a) cancellation of cooperation approval, since the data of the linked account remains in the linked wallet management data without being deleted, strictly speaking, it can be considered that it is not withdrawal from the linked wallet. However, for the user, "withdrawal from the linked wallet" may be intuitively easy to understand, so it is expressed in this way.

Further, it may be desirable for users 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 of other linked accounts.
Note that, unlike this, the cancellation of account linkage may require the approval of another linked account.

<Display screen>
FIG. 20-1 is a diagram showing an example of screen transitions 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 talk room screen of the group "Band Friends", and the cooperative wallet information display area WIR1 is displayed rising from the bottom of the screen.

At the bottom of the cooperative wallet information display area WIR1, a cooperative wallet withdrawal button BT70 for withdrawing from the cooperative wallet and the aforementioned cooperative wallet discard button BT30 are displayed.
It should be noted that the display of the linked wallet discard button BT30 is not essential, and may not be displayed.

When the link wallet withdrawal button BT70 is tapped, account link cancellation confirmation information is sent to the terminal 20A via the server 10. FIG. As a result, the screen in the center of FIG. 20-1 is displayed on the display unit 24 of the terminal 20A.

This screen is a group talk room screen of the group "bandmates", and user A.I. A cooperative wallet withdrawal request message, which is a message requesting withdrawal from the cooperative wallet from A, is displayed. In this linked wallet withdrawal request message, the contents of the request to withdraw from the linked wallet are displayed, and below it, a rejection button for rejecting the withdrawal and an approval button for authorizing (permitting) the withdrawal are provided. It is

When the approval button is tapped, account link cancellation approval information is transmitted from the terminal 20A to the server 10 . Then, the server 10 performs the account link cancellation process, and the user B. B's account linkage is canceled. As a result, the screen on the right side of FIG. 20-1 is displayed on the display unit 24 of the terminal 20B.

This screen is a group talk room screen of the group "band friends", and user B. A message indicating that B wishes to withdraw from the linked wallet → user A.B. A message permitting A to withdraw from the linked wallet → User B. A message indicating that B has withdrawn from the cooperative wallet.

<Processing>
FIG. 20-2 is a flowchart showing an example of the flow of processing executed by each device in this case.
This figure shows an example of processing executed by a system composed of the terminal 20 and the server 10 .
The server 10 may or may not be divided into a payment application management server that manages payment services and a messaging application management server that manages messaging services.

By way of example and not limitation, based on user operations on terminal 20, user B. If canceling B's account linkage is selected (L110: Withdrawal), linked wallet withdrawal processing is executed (L230).

Alternatively, and by way of example and not limitation, when a user leaves a group of messaging services in which a federated wallet was created, the federated wallet leave process may or may not be performed. may

In addition, when the above-mentioned total limit amount and the number of consecutive payments set in the linked account become "0", the linked wallet withdrawal process may or may not be performed. .

FIG. 20-3 is a flow chart showing an example of the flow of processing executed by each device in the cooperative wallet withdrawal processing.
In this figure, from the left side, the processing executed by the control unit 21 of the terminal 20A (the terminal 20 of the user AA), which is the terminal of the user whose cooperation has been approved, the terminal 20B, which is the terminal of the user who has selected to cancel the account cooperation, An example of processing executed by the control unit 21 of (user B.B's terminal 20) and processing executed by the control unit 11 of the server 10 is shown.

The control unit 21 of the terminal 20B transmits account linkage cancellation request information requesting cancellation of account linkage to the server 10 via the communication I/F 22 (B810).

When the account linkage cancellation confirmation information is received from the terminal 20B via the communication I/F 14, the control unit 11 of the server 10 transmits the account linkage cancellation confirmation information for confirming whether or not to approve the cancellation of the account linkage to the terminal 20B via the communication I/F 14. 20A (S810).

Note that the account link cancellation confirmation information may be sent to the terminal 20 that generated the linked wallet, or sent to all terminals 20 of linked accounts for which linking of the linked wallet has been approved. may Also, if a representative is set for the linked wallet or group, the message may or may not be sent to that representative.

When receiving the account linking cancellation confirmation information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the account linking cancellation confirmation information (A810).
Based on the user's operation on the input/output unit 23 of the terminal 20A, when it is selected to authorize the cancellation of the account cooperation (A810: YES), the control unit 21 of the terminal 20A receives the account cooperation cancellation authorization information is transmitted to the server 10 via the communication I/F 22 .
If not to authorize is selected (A810: NO), the control unit 21 of the terminal 20A terminates the process.

When account linking cancellation authorization information is received from the terminal 20 that has transmitted the account linking cancellation confirmation information via the communication I/F 14 (S820: YES), the control unit 11 of the server 10 performs account linking based on the account linking cancellation request information. Release processing is executed (S830).

In the account linking cancellation process, the control unit 11 of the server 10, as an example and not limitation, the user B. In the user account of B, the cooperation approval of the cooperation status management data is changed from "completed" to "not completed". This corresponds to (a) cancellation of collaboration approval described above.

It should be noted that, instead of doing this, user B. is selected from the cooperation status management data. B's user account itself may be deleted. This corresponds to (b) deletion of the linked account described above.

Then, the control unit 11 of the server 10 controls the user B. Account linkage cancellation information indicating that the account linkage of B has been canceled is transmitted to the terminals 20 in the group via the communication I/F 22 (S840).
Note that the account linking cancellation information may or may not be sent only to the terminal 20 that requested (applied for) the account linking cancellation and the terminal 20 that sent the account linkage cancellation confirmation information. good too.
Also, the account linking cancellation information may be transmitted to the terminal 20 that requested (applied for) the account linking cancellation and the terminal 20 that generated the linked wallet, or it does not have to be.
Also, the terminal 20 of the representative of the cooperative wallet or the representative of the group may be included in the transmission.

When receiving the account linking cancellation information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A displays the received account linking cancellation information on the display unit 24 (A830), and terminates the process.

When the account linking cancellation information is received from the server 10 via the communication I/F 22 (B820: YES), the control unit 21 of the terminal 20B displays the received account linking cancellation information on the display unit 24 (B830). Then, the control unit 21 of the terminal 20B controls the user B. The user is notified that the linked wallet has become unusable by, for example, displaying on the display unit 24 a display indicating that payment by the linked wallet in the user account of B has become unexecutable (B840).
If the account linking cancellation information is not received (B820: NO), the control unit 21 of the terminal 20B terminates the process.

The following cases are conceivable as conditions for executing the account linking cancellation process.
・When approval to cancel account linkage is obtained from all members of the group ・When approval to cancel account linkage is obtained from all members who have been approved for linkage If you obtain approval to cancel the account linkage ・If you obtain approval to cancel the account linkage from the member who created the linked wallet ・If you obtain approval to cancel the account linkage from the representative of the linked wallet or the representative of the group ・Others If account unlinking is performed unconditionally without approval of account unlinking of members of

After executing the linked wallet withdrawal process, the control unit 11 of the server 10 determines whether or not the account linking of all linked members of the linked wallet has been canceled (L240). If the account linkage of all members has been canceled (L240: YES), the linked wallet destruction process is executed (L220).
On the other hand, if there are still members whose account linkage has not been canceled (L240: NO), the process returns to step L110.

In addition, even if the account linkage of all the linked wallet members is canceled (L240: YES), the linked wallet destruction process will not be executed, and the payment history, advance payment history, etc. in this linked wallet will be retained. may or may not.
In this case, even if the cooperative wallet generation process is not executed, once the group member approves the cooperation, it is possible to make payment using the cooperative wallet again.

FIG. 20-4 is a diagram showing an example of a timing chart for explaining the timing at which each process in this embodiment is executed.
Here, the timing at which each terminal is instructed to execute the account addition linkage process, the linked wallet payment process, the linked wallet retroactive settlement process, and the linked wallet withdrawal process described in the above flow will be described. To simplify the explanation, let's consider a case where advance payment does not occur in cooperative wallet payment processing.

Let the terminal 20A be a terminal that executes cooperative wallet generation. Terminals of other cooperative members of the cooperative wallet are terminals 20B and 20C.
In this timing chart, the horizontal axis is the time axis, the timing of each terminal 20 performing account addition linkage processing is indicated by a white hexagon, the timing of linked wallet payment processing is indicated by a white circle, and the linked wallet retroactive settlement processing is indicated by a white circle. The timing of withdrawal is indicated by a white rectangle, and the timing of withdrawal from the linked wallet is indicated by a white triangle.

After the cooperative wallet generation process, the terminal 20B executes the account addition cooperative process. Payment 1 is then executed at the terminal 20A. For payment 1, user A. A and user B. B is participating.

Next, the terminal 20C executes account addition cooperation processing. Then, in the terminal 20C, the cooperative wallet retroactive settlement process for the payment 1 is executed.
After that, the linked wallet withdrawal process is executed in the terminal 20B.
Then, payment 2 is executed at the terminal 20C. For payment 3, user A. A and user C.A. Participating in C.

After that, the terminal 20B executes the account addition cooperation process again. Then, in the terminal 20B, the cooperative wallet retroactive settlement process for the payment 2 is executed.
Payment 3 is performed at terminal 20B. For payment 3, user A. A and user B. B and user C.B. Participating in C.

After the payment 3, the terminal 20C executes the cooperative wallet withdrawal process. In addition, linked wallet withdrawal processing is executed in the terminal 20A.
Finally, in the terminal 20B, cooperative wallet withdrawal processing is executed, and then cooperative wallet destruction processing is executed.

<Effect of the 20th embodiment>
In this embodiment, the terminal 20 performs 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 the first An example of processing related to releasing the association between the account and the second account) is shown to be performed by the control unit 21. FIG.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to cancel the association between the first account and the second account once associated.

Also, in this case, the process for canceling the account linkage of the first user account is to send account linkage cancellation request information (not a limitation, but an example of information regarding a request to cancel the association) to the second user account. processing can be included.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to confirm that the association with respect to the second account is cancelled.

Also, in this case, the account linkage of the first user account can be canceled based on the permission of the second user of the second user account.
As an example of the 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. In other words, it is possible to prevent the first account and the second account from being canceled against the will of the second user.

Also, in this case, the account linkage of the first user account may be performed based on the first user leaving the chat room containing the first user and the second user of the second account. can.
As an example of the effect of the embodiment obtained by such a configuration, when the first user leaves a chat room that includes the first user and the second user of the second account, the first account and the second account can be disassociated with.

<Twentieth Modification (1)>
In the above embodiment, when the linked wallet withdrawal process is executed, the account linking is canceled, but the present invention is not limited to this.
By way of example and not limitation, when the linked wallet withdrawal process is performed, the linked wallet settlement process and/or the linked wallet retroactive settlement process may be performed, and then the account linking may be canceled. You don't have to.

FIG. 20-5 is a diagram showing an example of transition of screens displayed on the display unit 24 of the terminal 20B in this modified example.
On the left side of FIG. 20-5, a screen similar to that on the left side of FIG. 20-1 is displayed. When the linked wallet withdrawal button BT70 is tapped, the screen on the right side of FIG. 20-5 is displayed as an example and not as a limitation.

In this screen, information for confirming whether or not to settle accounts for the linked wallet is displayed in the center of the linked wallet information display area WIR1. Specifically, detailed information about the purchase history of unpaid bills is displayed along with the words "There is a purchase history of unpaid bills." In this example, for payment of "4,500 yen" to "XX musical instrument" as the payee, user B. B to user A.B. It shows that the remittance of "2,250 yen" to A has not yet been made.

Underneath it, the words "Do you want to settle the bill?" are displayed together with a "Yes" button and a "No" button. When the "Yes" button is tapped, the above settlement is executed. Thus, in this example, user B. B to user A.B. "2,250 yen" is remitted to A.

In this case, as an example and not a limitation, after executing step B810 in FIG. to run it.

After executing the linked wallet settlement process, the linked wallet retroactive settlement process, or both, in the linked account requesting to cancel the linking of the linked account, if there are unpaid advance settlements or retroactive settlements remaining, the server 10 The control unit 11 may not execute step S810 in FIG. 20-3.
In this case, if the linked account for which the account linking is to be canceled has an unpaid payment or retroactive payment, the account linking is not canceled.

In addition, after executing the linked wallet settlement process, the linked wallet retroactive settlement process, or both, in the linked account requesting to cancel the linking of the linked account, if there are no unpaid advance settlements or retroactive settlements remaining, the server 10 The control unit 11 may or may not execute the account linking cancellation process regardless of whether or not the account linking cancellation authorization information is received.
In other words, if there is no lending or borrowing in the linked wallet for the linked account to be released from the account linking, it is possible to release the account linking without the approval of other members.

In this modification, the terminal 20 displays on the display unit 24 information about the payment (not limited, but an example of the third payment) made by at least the second user account based on the account linkage of the first account. Then, the terminal 20 displays a display of information (not a limitation, but an example of a third display) regarding the payment of this settlement on the display unit 24 based on the cancellation of the account linkage of the first account. there is
As an example of the effect of the embodiment obtained by such a configuration, based on the association between the first account and the second account, the first user browses and confirms information on the third payment made by at least the second account. can be made possible. Further, when the first account and the second account are canceled, the first user can view and check the information regarding the payment of the third payment.

1 communication system 10 server 20 terminal 30 network 40 store POS system 50 store code reader device

Claims (29)

A program for a terminal to execute,
a control unit of the terminal that causes the terminal of the first user to process a first payment based on the first account of the first user of the terminal and the second account of the second user associated with the first account; and
Receiving, by the communication unit of the terminal, first information regarding remittance to the second account based on the first payment;
displaying a first display based on the first information on a display unit of the terminal;
Based on the first user's input to the first display, the terminal performs a process related to transferring money from the first account to the second account by the control unit. A program for a terminal to execute,
a first account of a first user of said terminal and a plurality associated with said first account Based on the second account, which is a common account that can be settled by the user, the first user performing processing related to the first payment by the terminal of the terminal, and
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing a process related to transferring money to the second account by the control unit. performed by the terminal. The program according to claim 1 or claim 2 ,
The first information is information based on the amount paid in the first payment by the second account. The program according to any one of claims 1 to 3 ,
The processing related to remittance is processing related to remittance of the amount based on the first information from the first account to the second account. The program according to claim 2 ,
The process related to the remittance is a process related to remittance of the first amount, which is the amount based on the first information, from the first account to the second account,
the second account is associated with each account of the plurality of users;
The respective account is transferred a second amount that is at least a portion of the first amount from the second account. A program for a terminal to execute,
a first account of a first user of said terminal and a second account associated with said first account; Based on the account, the terminal of the first user performs processing related to the first payment by the control unit of the terminal;
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing a process related to transferring money to the second account by the control unit. executed by the terminal,
The first payment is made at least by the second account for the shortfall of the first account. payment is made and
said first information paid by said second account on behalf of said first account Contains monetary information. The program according to claim 6 ,
The first payment is not made by the first account. The program according to claim 6 ,
In the first settlement, payment is made by the first account and at least the second account is used to pay the shortfall of the first account. The program according to any one of claims 6 to 8 ,
The first payment is made by the first account, the second account, and a fourth account associated with the first account and the second account. The program according to claim 9 ,
The shortfall of said first account is paid by at least said second account and said fourth account. The program according to claim 9 ,
Any shortfall of the first account is paid only by the second account. The program according to claim 10 or claim 11 ,
The second account to pay the shortfall of the first account is determined based on the balance of the second account. The program according to claim 10 or claim 11 ,
The second account to pay for the shortfall of the first account is selected based on input to the terminal by the first user. 14. The program according to claim 13 ,
The second account to pay for the shortfall of the first account is determined based on the permission of the second user of the second account after the second account is selected based on the first user's input to the terminal. be done. The program according to any one of claims 1 to 14 ,
the first display is included in a chat room associated with the first account and the second account;
Displaying the chat room including the first display on the display is performed by the terminal. 16. The program according to claim 15 ,
Based on the first account and the second account, the terminal of the first user performs processing related to a second payment by the control unit;
Receiving, by the communication unit, second information related to transferring money to the second account based on the second payment;
Displaying the chat room including the second display based on the second information and the first display on the display is performed by the terminal. 17. The program according to claim 16 ,
Based on the input by the first user to the first display and the second display, the amount based on the first information and the amount based on the second information are transferred from the first account to the second account. The terminal performs a process related to remittance by the control unit. The program according to claim 16 or 17 ,
based on releasing the association in the chat room between the first account and the second account, the amount based on the first information and the amount based on the second information are transferred from the first account to the second account; The terminal performs a process related to transferring money to No. 2 account by the control unit. 15. The program according to claim 14 ,
performing processing related to a third payment by the terminal of the first user based on the first account and a third account associated with the first account, which is different from the second account; and ,
Receiving, by the communication unit, third information about transferring money to the third account based on the third payment;
displaying a third display based on the third information on the display unit;
By the control unit, based on the first user's input to the first display and the third display, the amount based on the first information is transferred from the first account to the second account. and performing a process related to transferring the amount based on the third information from the first account to the third account by the control unit is executed by the terminal. The program according to any one of claims 1 to 19 ,
The first information is received by the communication unit via a server. An information processing method for a terminal,
a control unit of the terminal that causes the terminal of the first user to process a first payment based on the first account of the first user of the terminal and the second account of the second user associated with the first account; and
Receiving, by the communication unit of the terminal, first information regarding remittance to the second account based on the first payment;
displaying a first display based on the first information on a display unit of the terminal;
and performing, by the control unit, processing related to transferring money from the first account to the second account based on an input by the first user to the first display. a terminal,
a control unit that performs a process related to a first payment by the terminal of the first user based on the first account of the first user of the terminal and the second account of the second user associated with the first account;
a communication unit that receives first information about transferring money to the second account based on the first payment;
A display unit that displays a first display based on the first information,
The control unit performs processing related to transferring money from the first account to the second account based on the first user's input to the first display. a terminal,
A processor that reads a program from memory and executes processing based on the program,
The processor
performing processing related to a 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 of a second user associated with the first account;
Receiving, by the communication unit of the terminal, first information regarding remittance to the second account based on the first payment;
displaying a first display based on the first information on a display unit of the terminal;
and performing processing related to transferring money from the first account to the second account based on input by the first user to the first display. An information processing method for a terminal,
a first account of a first user of said terminal and a plurality associated with said first account Based on the second account, which is a common account that can be settled by the user, the first user performing processing related to the first payment by the terminal of the terminal, and
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing, by the controller, processing related to transferring money to the second account. . a terminal,
a first account of a first user of said terminal and a plurality associated with said first account Based on the second account, which is a common account that can be settled by the user, the first user A control unit that performs processing related to the first payment by the terminal of
receiving first information relating to transferring money to said second account based on said first payment; a communication unit that
A display unit that displays a first display based on the first information,
The control unit controls the first display based on the first user's input to the first display. Perform processing related to transferring money from an account to the second account. a terminal,
A processor that reads a program from memory and executes processing based on the program -
The processor
a first account of a first user of said terminal and a plurality associated with said first account Based on the second account, which is a common account that can be settled by the user, the first user performing processing related to the first payment by the terminal of
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing processing related to transferring money to the second account. An information processing method for a terminal,
a first account of a first user of said terminal and a second account associated with said first account; Based on the account, the terminal of the first user performs processing related to the first payment by the control unit of the terminal;
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing, by the control unit, a process related to transferring money to the second account. ,
The first payment is made at least by the second account for the shortfall of the first account. payment is made and
said first information paid by said second account on behalf of said first account Contains monetary information. a terminal,
a first account of a first user of said terminal and a second account associated with said first account; Based on the account, the terminal of the first user performs processing related to the first payment. a control unit;
receiving first information relating to transferring money to said second account based on said first payment; a communication unit that
A display unit that displays a first display based on the first information,
The control unit controls the first display based on the first user's input to the first display. perform processing related to transferring money from the account to the second account;
The first payment is made at least by the second account for the shortfall of the first account. payment is made and
said first information paid by said second account on behalf of said first account Contains monetary information. a terminal,
A processor that reads a program from memory and executes processing based on the program -
The processor
a first account of a first user of said terminal and a second account associated with said first account; Based on the account, the terminal of the first user performs processing related to the first payment. and
the first information about transferring money to the second account based on the first payment; receiving by a communication unit of the terminal;
displaying a first display based on the first information on a display unit of the terminal;
from the first account based on input by the first user to the first view and performing processing related to transferring money to the second account;
The first payment is made at least by the second account for the shortfall of the first account. payment is made and
said first information paid by said second account on behalf of said first account Contains monetary information.

Images