JP7566848B2 - Program, information processing method, server, and system - Google Patents

Description

This disclosure relates to a program, an information processing method, and a terminal.

Recently, services that enable the management of electronic currency (electronic money) of a terminal or a terminal user, and the sending and receiving of money, etc., using applications that can be executed on terminals such as smartphones are becoming more widespread. For example, Patent Literature 1 discloses a technology for settling the purchase amount of a product.

JP 2002-176671 A

According to a first aspect of the present invention, a program executed by the terminal displays, on at least a display unit of the terminal, a first display based on first information relating to a remittance request from a first user to a user of the terminal, or from the user of the terminal to the first user, and a second display based on second information relating to a remittance request from a second user to the user of the terminal, or from the user of the terminal to the second user, and performs a first process based on the first information and the second information by a control unit of the terminal based on an input to the terminal on which the first display and the second display are displayed.
According to a second aspect of the present invention, an information processing method for a terminal includes displaying, on at least a display unit of the terminal, a first display based on first information relating to a remittance request from a first user to a user of the terminal, or a remittance request from the user of the terminal to the first user, and a second display based on second information relating to a remittance request from a second user to a user of the terminal, or a remittance request from the user of the terminal to the second user, and performing a first process based on the first information and the second information by a control unit of the terminal, based on an input to the terminal on which the first display and the second display are displayed.
According to a third aspect of the present invention, the terminal comprises a display unit that displays at least a first display based on first information relating to a remittance request from a first user to a user of the terminal, or from the user of the terminal to the first user, and a second display based on second information relating to a remittance request from a second user to the user of the terminal, or from the user of the terminal to the second user, and a control unit that performs a first processing based on the first information and the second information based on an input to the terminal on which the first display and the second display are displayed.
According to a fourth aspect of the present invention, the terminal comprises a processor that reads a program stored in a memory and executes processing based on the program, and the processor executes the following operations: displaying, on at least a display unit of the terminal, a first display based on first information relating to a remittance request from a first user to a user of the terminal, or from the user of the terminal to the first user, and a second display based on second information relating to a remittance request from a second user to the user of the terminal, or from the user of the terminal to the second user; and performing a first process based on the first information and the second information based on an input to the terminal on which the first display and the second display are displayed.

FIG. 1 illustrates an example of a configuration of a communication system according to an embodiment. FIG. 4 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of information stored in a storage unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of user registration data according to the first embodiment. FIG. 4 is a diagram showing an example of a user management database according to the first embodiment. FIG. 11 is a diagram showing an example of remittance request management data 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. FIG. 4 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. 6 is a flowchart showing an example of a processing flow of the terminal and the server according to the first embodiment. 10 is a flowchart showing an example of the flow of a settlement process according to the first embodiment. FIG. 11 is a diagram showing an example of a table for explaining lump-sum settlement according to the first embodiment. 6 is a flowchart showing an example of a processing flow of the terminal and the server according to the first embodiment. 10 is a flowchart showing an example of the flow of a settlement process according to the first embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 11 is a diagram showing an example of a display screen of a terminal according to a second embodiment. FIG. 11 is a diagram showing an example of a display screen of a terminal according to a second embodiment. FIG. 11 is a diagram showing an example of a display screen of a terminal according to a second embodiment. 10 is a flowchart showing an example of a processing flow of a terminal and a server according to a second embodiment. 10 is a flowchart showing an example of a processing flow of a terminal and a server according to a second embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a third embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a third embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to the fourth embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 13 is a diagram showing an example of a display screen of a terminal according to a fifth embodiment. 13 is a flowchart showing an example of a processing flow of a terminal and a server according to the fifth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the sixth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the sixth embodiment. 23 is a flowchart showing an example of the flow of a batch remittance request creation process according to the sixth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the seventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the seventh embodiment. 23 is a flowchart showing an example of the flow of a settlement process according to the seventh embodiment. 23 is a flowchart showing an example of the flow of a settlement process according to the seventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the eighth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the eighth embodiment. 23 is a flowchart showing an example of a processing flow of a terminal and a server according to the eighth embodiment; 13 is a flowchart showing an example of a processing flow of a terminal and a server according to an eighth modified example. FIG. 23 is a diagram showing an example of a table for explaining a processing method according to the ninth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the ninth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the ninth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the ninth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the ninth embodiment. 23 is a flowchart showing an example of a processing flow of a terminal and a server according to the ninth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. 23 is a flowchart showing an example of a processing flow of a terminal and a server according to a tenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. 23 is a flowchart showing an example of a processing flow of a terminal and a server according to an eleventh embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the seventeenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the seventeenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the seventeenth embodiment. 23 is a flowchart showing an example of the processing flow of a terminal and a server according to a seventeenth embodiment; 23 is a flowchart showing an example of the processing flow of a terminal and a server according to a seventeenth embodiment; 23 is a flowchart showing an example of a processing flow of a terminal and a server according to a seventeenth modified example. FIG. 23 is a diagram showing an example of a table for explaining a processing method according to the eighteenth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to the eighteenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the eighteenth embodiment. 23 is a flowchart showing an example of the processing flow of a terminal and a server according to the eighteenth embodiment; FIG. 23 is a diagram showing an example of a display screen of a terminal according to the nineteenth embodiment. FIG. 23 is a diagram showing an example of a display screen of a terminal according to the nineteenth embodiment. FIG. 29 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. FIG. 29 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. FIG. 29 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. 20 is a flowchart showing an example of the processing flow of a terminal and a server according to a twentieth embodiment; FIG. 21 is a diagram showing an example of a display screen of a terminal according to the twenty-first embodiment. FIG. 21 is a diagram showing an example of a display screen of a terminal according to the twenty-first embodiment. FIG. 21 is a diagram showing an example of a display screen of a terminal according to the twenty-first embodiment. 21 is a flowchart showing an example of the processing flow of a terminal and a server according to the twenty-first embodiment; FIG. 22 is a diagram showing an example of a display screen of a terminal according to the twenty-second embodiment. FIG. 22 is a diagram showing an example of a display screen of a terminal according to the twenty-second embodiment. FIG. 22 is a diagram showing an example of a display screen of a terminal according to the twenty-second embodiment. FIG. 22 is a diagram showing an example of a display screen of a terminal according to the twenty-second embodiment. FIG. 26 is a diagram showing an example of a display screen of a terminal according to a twenty-sixth embodiment. FIG. 26 is a diagram showing an example of a display screen of a terminal according to a twenty-sixth embodiment. FIG. 27 is a diagram showing an example of a display screen of a terminal according to the twenty-seventh embodiment. FIG. 27 is a diagram showing an example of a display screen of a terminal according to the twenty-seventh embodiment. FIG. 27 is a diagram showing an example of a display screen of a terminal according to the twenty-seventh embodiment. FIG. 27 is a diagram showing an example of a display screen of a terminal according to the twenty-seventh embodiment.

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

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

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

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

The server 10 has a function of providing payment services and messaging services to the terminals 20 owned by users via the network 30. The server 10 can also be expressed as a payment management server, a payment service server, a messaging server, a messaging service server, etc. In this embodiment, as an example and not a limitation, the users of the server 10 are payment service providers and messaging service providers.

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

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

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

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

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

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

(1) Terminal Hardware Configuration FIG. 1A shows an example of the hardware configuration of the terminal 20.
The terminal 20 includes a control unit 21 (CPU: central processing unit), a storage unit 28, a communication I/F 22 (interface), an input/output unit 23, a clock unit 29A, and a position calculation information detection unit 29B. The HW components of the terminal 20 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW configuration of the terminal 20 includes all of the components. For example and not for limitation, the terminal 20 may or may not be configured such that individual components or multiple components are removable.

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

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

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

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

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

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

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

If the input/output unit 23 is a touch panel, the input/output unit 23 and the display unit 24 may be arranged facing each other and have approximately the same size and shape.

The clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information). The clock unit 29A is configured to include, for example and not limitation, a clock that uses a quartz oscillator. The clock unit 29A can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

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

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

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

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

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

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

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

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

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

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

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

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

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

The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA, or may not be such a unit. In this disclosure, the control unit 11 is not limited to these.

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

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

The input/output unit 12 is realized by a device for inputting various operations to the server 10 .
The input unit is realized by any one or a combination of all kinds of devices that can receive input from a user and transmit information related to the input to the control unit 11. The input unit is typically realized by hardware keys such as a keyboard or a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via moving images), or a microphone (operation input by voice), as examples and without limitation.

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

In the first embodiment, the input/output unit 12 is equipped with a display unit 13.

The display unit 13 is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OELD)). The display unit 13 may or may not be a head mounted display (HDM) or the like. These display units 13 may or may not be capable of displaying display data in 3D. In the present disclosure, the display unit 13 is not limited to these.

The clock unit 19 is a built-in clock of the server 10, and outputs time information (timekeeping information). The clock unit 19 is configured to include, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

(3) Others The server 10 stores the program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processes of each unit included in the control unit 11. In other words, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11. This program P may or may not be expressed as a program module.
The same applies to other devices.

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

The control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 may or may not realize each process by a CPU having a control circuit, but may also realize each process by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or a dedicated circuit. These circuits may or may not be realized by one or more integrated circuits, and the multiple processes shown in each embodiment may or may not be realized by one integrated circuit. Furthermore, LSIs may be called VLSIs, super LSIs, ultra LSIs, etc. depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit.
The same applies to other devices.

In addition, the program P (which may be, for example and not by way of limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may or may not be provided in a state stored in a computer-readable storage medium. The storage medium is capable of storing the program P in a "non-transitory tangible medium." The program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the program P may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded in a storage medium.

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

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

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

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

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

The following describes an embodiment in which the present invention is implemented using a server-client system.

However, the present invention is not limited to a server-client system, and may be implemented by a system that does not include a server, such as the following system, which is an example and not a limitation of the present invention.
A system (distributed system) in which the terminal 20 has a server function. This can be realized by using block chain technology, for example and not by way of limitation.
A system in which terminals 20 perform wireless communication with each other. This can be realized, for example and without limitation, by performing communication in a peer-to-peer (P2P) system using a short-range wireless communication technology such as Bluetooth.

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

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

"Electronic currency" refers to electronic currency that is distinct from physical currency and that is owned by the terminal 20 managed in the various applications described above or by the user of the terminal 20.

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

In this specification, the term "electronic money" is used as an example, and by way of example and not limitation, the balance of the electronic money account of the user of terminal 20 is referred to as the "electronic money account balance."

In the following description, a request from a user of a terminal 20 to a user (other user) of another terminal 20 to remit money is referred to as a "remittance request" (synonymous with a remittance request). Information regarding this remittance request is referred to as "remittance request information."
Requesting a remittance may be expressed as "requesting a remittance" or "making a remittance request."
In addition, a request to remit may be expressed as "a remittance is requested" or "a remittance request is made", etc.

In addition, sending a remittance request will be expressed as "sending a remittance request" or "delivering a remittance request," but these are essentially synonymous.
Conversely, receiving a remittance request is expressed as "receiving a remittance request" or "accepting a remittance request," but these are essentially synonymous.

In addition, in the following, the term meaning to remind, recollect, or reconfirm the contents of a remittance request to the other user will be referred to as a "remittance reminder," and information regarding this remittance reminder will be referred to as "remittance reminder information."
Reminding someone to remit may be expressed as "reminding someone to remit" or "making a remittance reminder."
In addition, being reminded to remit may be expressed as "being reminded to remit" or "a remittance reminder is made."

In addition, the remittance request information (the same applies to remittance reminder information) only needs to include at least information indicating that a remittance has been requested, information about the user requesting the remittance (the source of the remittance request), and information about the user to whom the remittance is requested.

As will be described later, the remittance request information may also include information such as the amount requested for remittance (hereinafter referred to as the "remittance request amount"), the reason for the remittance, and the deadline for payment by remittance (hereinafter referred to as the "payment deadline").

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

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

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

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

The messaging service may or may not include an instant messaging service (IMS), which allows the sending and receiving of content such as simple messages between terminals 20.

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

<Example>
An embodiment to which the present invention is applied will be described below.
There may be cases where a remittance request from a second user (first user) to you (the user of the terminal) or from you to a second user is not processed, resulting in multiple remittance requests accumulating in the terminal 20. By way of example and not limitation, this may be the case if you accidentally forget to process a remittance request.

In this case, processing each pending remittance request one by one would be time-consuming and inconvenient. Also, processing each pending remittance request one by one could result in the user's balance running out.

Therefore, a method for processing a plurality of remittance requests (here, a plurality of unprocessed remittance requests) in a batch will be described. This batch processing will be referred to as "batch processing".
Batch processing can be broadly divided into at least the following processes:
(1) Processing related to bulk settlement (hereinafter referred to as "bulk settlement"). (2) Processing related to offsetting remittance requests (hereinafter referred to as "request offsetting"). (3) Processing related to the creation of bulk remittance requests (hereinafter referred to as "bulk remittance requests"). (4) Processing related to special bulk settlement (hereinafter referred to as "special bulk settlement"). Processing related to the creation of special bulk remittance requests (hereinafter referred to as "special bulk remittance requests").

In addition, in the embodiment described below, a case will be exemplified in which the other user is one user, that is, the second user is the first user (or the first user is the second user).
As will be explained in the modified examples, the method described below can also be applied in the case where the other users are different users, that is, where the first user is a user different from the second user (where the second user is a user different from the first user).

First Example
The first embodiment is an embodiment relating to lump-sum settlement of the above-mentioned lump-sum processing.
The contents described in the first embodiment are applicable to any of the other embodiments and other modified examples.
In addition, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Functional configuration>
(1) Server FIG. 1B is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
The control unit 11 of the server 10 includes, as a functional unit and not as a limitation, a payment application management processing unit 111 that performs processing to provide various payment services via payment applications to the terminal 20 or the user of the terminal 20 in accordance with a payment application management processing program 151 stored in the memory unit 15.

FIG. 1C is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The memory unit 15 stores, by way of example and not limitation, a payment application management processing program 151 which is read by the control unit 11 and executed as a payment application management process, user registration data 153, a user management database 155, and remittance request management data 157.

The user registration data 153 is registration data relating to the terminal 20 that uses the payment application or the user of that terminal 20, and an example of the data configuration is shown in FIG. 1-4.
In the user registration data 153, for example and not for limitation, a user name, an application ID, a terminal phone number, and other registration information are stored in association with each other.

The user name is the name of the user of the terminal 20 using the payment application, and by way of example and not limitation, the name registered by the user of the terminal 20 when using the payment application is stored.

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

The terminal phone number is the phone number of the terminal 20 of the user with this username, and by way of example and not limitation, the phone number of the terminal 20 that the user of the terminal 20 registers when using the payment application is stored.

Other registration information may include, by way of example and not limitation, the ID of the terminal 20: terminal ID (IMEI (International Mobile Equipment Identity) as an example and not limitation), the email address of the terminal 20 of the user of this username (terminal email address), and authentication information such as passwords (login password, authentication password) used for various authentications in the payment application.

The identification information for identifying the terminal 20 may be, for example and without limitation, a terminal ID.
Furthermore, the identification information for identifying the user of the terminal 20 can be, for example and without limitation, an application ID. Note that this may or may not be a "user ID."

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

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

Note that registration of the terminal telephone number is not mandatory, and the terminal telephone number may not be stored in the user registration data 153.

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

The user management database 155 is a database that cumulatively stores data for managing information about the terminal 20 that uses the payment application or its user. One example of the configuration of the first user management database 155A is shown in Figure 1-5.

In the first user management database 155A, user management data is stored as management data for each application ID.
Each user management data includes, by way of example and not limitation, an application ID, the balance of an electronic money account of a user identified by the application ID, remittance history data, and receipt history data.

The remittance history data is data that stores information about the history of remittances from a user of this application ID to a user of another application ID (remittance history information).

The receipt history data is data that stores information about the history of receipts made by the user of this application ID from users of other application IDs (receipt history information).

The remittance request management data 157 is a database that cumulatively stores data for managing information related to remittance requests. FIG. 1-6 shows an example of the configuration of the first remittance request management data 157A.
In the first remittance request management data 157A, for example and not by way of limitation, a date and time, a remittance request management ID, a remittance master ID, a remittance request destination ID, a remittance request amount, and a remittance completion flag are stored in association with each other.

As a non-limiting example, the date and time stored is the date and time when the remittance request information for the corresponding remittance request was sent from the server 10 to the terminal 20 of the remittance request destination user.

The remittance request management ID stores an ID that is uniquely set by the server 10 for each remittance request.

The remittance master ID stores the application ID of the user who requested the remittance (also called the remittance master user).
The remittance request destination ID stores the application ID of the user who has requested remittance (also called the remittance request destination user).

The remittance request amount stores the amount requested by the remittance master user to be remitted to the remittance request destination user by the remittance request.

The remittance completed flag is a flag that indicates whether or not the remittance corresponding to the remittance request has been completed by executing the settlement process by the control unit 11. The default is "OFF" and is set to "ON" when the remittance is completed.

There are two possible methods for the server 10 to manage remittance requests:
(1) Pattern A: The remittance request that has been executed is left without being deleted.
(2) Pattern B: Delete the remittance request that has been executed.

Either pattern can be applied, but when pattern A is applied, data of remittance requests with the remittance completion flag set to "ON" is not deleted but remains.
On the other hand, when pattern B is applied, the record of the data of the remittance request for which remittance has been executed is deleted.

(2) Terminal FIG. 1-7 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The control unit 21 includes, as a functional unit, a payment application processing unit 211 that executes payment application processing in accordance with a payment application processing program 281 stored in the storage unit 28, for example and not for 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 memory unit 28 stores, by way of example and not limitation, a payment application processing program 281 that is read by the control unit 21 and executed as a payment application process, and an application ID 283 associated with the terminal 20 or its user.

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

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

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

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

Figure 1-9 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a main menu screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.A.

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

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

When the remittance request list icon IC1 displayed at the bottom of the main menu screen is tapped, information requesting remittance request list information is sent from terminal 20A to server 10, and the remittance request list information is sent from server 10 to terminal 20A. As a result, by way of example and not limitation, a remittance request list screen such as that shown in FIG. 1-10 is displayed.

The current location display area CLR1 displays the words "Remittance Request List," indicating that remittance request list information is being displayed.

This remittance request list screen displays unprocessed remittance requests (hereinafter referred to as "unprocessed requests") between users of different terminals 20 as remittance requests related to the user of the user's own terminal 20 (user A.A.), grouped by user of the different terminals 20.

In the following, the user who proposes performing batch processing will be referred to as the "proposer user" as appropriate.
Furthermore, a user to whom a batch process is proposed by the proposer user is appropriately referred to as a "partner user."

Specifically, for multiple users, such as user B.B, user C.C, user D.D, and user E.E, the number of unprocessed requests between the users and the user is displayed in association with each user's icon image and user name, along with the settlement amount (hereinafter referred to as the "lump settlement amount") that would be incurred if the unprocessed requests between the users were processed collectively.

Here, the amount that you will pay to the other party according to a remittance request made to you by the other party will be referred to as the "payment amount" as appropriate, and the amount that you will receive from the other party according to a remittance request made to you by yourself will be referred to as the "received amount" as appropriate.
In this case, the "lump sum settlement amount" is the sum of the payment amount and the receipt amount corresponding to each unprocessed request with the positive and negative signs reversed when all the unprocessed requests are processed at once. This lump sum settlement amount is calculated in the settlement process executed by the control unit 11 of the server 10, as an example and not a limitation.

In addition, in this example display screen, a payment mark indicating "payment" is displayed next to the lump sum settlement amount if you are paying that lump sum settlement amount to the other party, and a receipt mark indicating "receipt" is displayed next to the lump sum settlement amount if you are receiving that lump sum settlement amount from the other party.

As a non-limiting example, it is shown that if user A.A (yourself) has four outstanding requests with user B.B (the other party) and these four outstanding requests are processed together, user A.A will pay user B.B a lump sum settlement amount of "1,000 yen."

Similarly, by way of example and not limitation, it is shown that user A.A (self) has four outstanding requests with user C.C (other party), and if these four outstanding requests are processed in a lump sum, user A.A will receive "4,000 yen" as a lump sum settlement amount from user C.C.

Also, at the bottom of the screen, a settlement button BT1 is displayed to request the server 10 to settle all outstanding requests in one go.

On this screen, by way of example and not limitation, when the display area WR1 of user C.C. is tapped, the remittance request details screen shown in FIG. 1-11 is displayed. This remittance request details screen displays details of the pending request between user C.C.

Bulk settlement refers to settling multiple unprocessed requests at once, and examples include, but are not limited to, "all-selection lump-sum settlement," in which all unprocessed requests are settled at once, and "partial-selection lump-sum settlement," in which some and multiple unprocessed requests are settled at once.

The current location display area CLR1 at the top of the screen displays the words "Remittance request with C.C.", indicating that an unprocessed request between user C.C. and the user is being displayed.
Also, under the current location display area CLR1, the lump sum settlement amount (in this example, "4,000 yen") and a mark (in this example, "receive mark") are displayed in association with the icon image and user name of user C.C., assuming that all selections are made and lump sum settlement is performed.

Next to the icon image of user C.C., a check area ASR1 is provided that can be switched between ON and OFF by tapping, and by checking the area to ON, a check mark is displayed in the check area, making it possible to settle all outstanding requests at once.

Below that, remittance requests addressed to user C.C. are listed. In this example, unprocessed requests addressed to user C.C. are listed in chronological order from the top to the bottom, and processed requests (hereafter referred to as "processed requests") are listed in chronological order from the top to the bottom below the list of unprocessed requests. In addition, processed requests are displayed in a different manner (grayed out in this example) to distinguish them from unprocessed requests.

In the following, a remittance request that has already been sent from one party to another party is referred to as a "sent remittance request", and a remittance request that has already been received from another party is referred to as a "received remittance request".
In this case, a request sending mark indicating "Request Sent" is displayed for a remittance request that has been sent among the unprocessed requests, and a request receiving mark indicating "Request Received" is displayed for a remittance request that has been received among the unprocessed requests.

In addition, for each unprocessed request, the date and time when the request was sent from the user's own terminal 20 to the other user's terminal 20 is displayed in association with the sent remittance request, and for each received remittance request, the date and time when the request was received by the user's own terminal 20 from the other user's terminal 20 is displayed in association with the received remittance request.

Additionally, each outstanding request may have associated with it, by way of example and not limitation, a reason for the payment being made with that outstanding request.

It is also possible to not include information on the remittance request amount in the remittance request information, and not display the information on the remittance request amount. In this case, by way of example and not limitation, the proposer user can inquire about the remittance request amount from the server 10 or from the other user.

In addition, information on the remittance request amount may be included in the remittance request information, but may not be displayed on the remittance request list screen or the individual remittance request screen. In this case, as a non-limiting example, a remittance request details screen including information on the remittance request amount may be displayed based on an input made on the individual remittance request screen to confirm the details of the remittance request.

The same applies to other information related to a remittance request, such as the reason for the remittance.

In addition, for each unprocessed request, by way of example and not limitation, for a sent remittance request, a receipt mark is displayed in association with the amount of receipt that you will receive from the other party by processing the sent remittance request, and for a received remittance request, a payment mark is displayed in association with the amount of payment that you will pay to the other party by processing the received remittance request.

In addition, next to each unprocessed request, there is a check area SR1 that can be tapped to switch the check "ON/OFF." By checking the area "ON," a check mark is displayed in the check area SR1, and the unprocessed request can be selected as a target for lump-sum settlement.

Also displayed at the bottom of the screen is a settlement button BT2 for requesting the server 10 to settle all selected unprocessed requests in one go.

In Figure 1-11, processed requests are displayed along with unprocessed requests, but processed requests may not be displayed.

As a non-limiting example, when two requests, the third sent remittance request (received 10,000 yen) and the fourth received remittance request (paid 3,000 yen), are selected by checking them "ON" and the settlement button BT2 is tapped, the display shown in FIG. 1-12 is displayed.

In Figure 1-12, lump-sum settlement confirmation information is displayed at the bottom of the screen in Figure 1-11 to allow the user to confirm the contents of the lump-sum settlement. In this example, a settlement content confirmation area ACR1 is provided within an electronic money account balance display area WBR1, which contains the text "Wallet Balance," to show how the user's current electronic money account balance will change as a result of the lump-sum settlement.

In the settlement details confirmation area ACR1, by way of example and not limitation, the current balance of the user's (user A.A.'s) electronic money account is displayed on the left side, and the balance of the user's electronic money account after settlement is displayed on the right side.
Also below that, along with the text "Do you want to propose payment with this content?", there is displayed a proposal button BT3 marked "Propose" for proposing payment, and a cancel button marked "Cancel" for canceling payment.

In this example, the current balance in the user A.A's electronic money account is "500 yen."
When the two requests selected above are settled in a lump sum, for User A.A, "Received 10,000 yen" and "Payed 3,000 yen" will result in "Received 7,000 yen." This shows that the lump sum settlement amount of "7,000 yen" will be added to the current electronic money account balance of "500 yen," resulting in the electronic money account balance after settlement being "7,500 yen."

Figure 1-13 is a diagram showing an example of a notification screen of a payment application that is displayed when the proposal button BT3 on the above screen is tapped. This notification screen is an example of a screen that is displayed on the display unit 24 of the terminal 20C of user C.C, who is the other party of user A.A.

When the proposal button BT3 on the screen displayed on the display unit 24 of the terminal 20A in FIG. 1-12 is tapped, the terminal 20A requests the server 10 to execute lump-sum settlement. The server 10 then sends lump-sum settlement approval confirmation information to the terminal 20C of the other party, user C.C., to confirm whether or not to approve the lump-sum settlement, and the lump-sum settlement approval confirmation information is displayed on the display unit 24 of the terminal 20C.

At the top of this notification screen, a current location display area CLR2 is configured, and the word "Notice" is displayed, indicating that a notification about a payment application is being displayed.

Below the current location display area CLR2, a notification NT1 containing a bell mark and the words "A settlement proposal for your remittance request has arrived" is displayed as a notification indicating that a settlement proposal for the remittance request has been received from user A.A's terminal 20A via server 10.

Below that, an announcement information display area NTR1 for displaying announcement information is configured, and information corresponding to the above-mentioned notification NT1 is displayed in this announcement information display area NTR1.
In this example, the lump-sum settlement approval confirmation information includes the text "Settlement proposal," an icon image of the other party, user A.A, and the lump-sum settlement amount. In this example, the lump-sum settlement amount is displayed, indicating that user C.C must pay "7,000 yen" to user A.A.

The lump-sum settlement approval confirmation information also includes a link LK1 with the text "Check details" for checking the details of the lump-sum settlement, and by tapping this link LK1, the user can check the details of the lump-sum settlement (for example, but not limited to, the breakdown).

In addition, instead of displaying the details of the lump-sum settlement from the "Check details" link LK1, the details of the lump-sum settlement may be displayed in a manner that allows switching between left and right directions or depth directions, for example and not limitation. One example of this is a carousel display, for example and not limitation.
This technique is equally applicable to any of the embodiments.

The lump sum settlement approval confirmation information also displays a settlement button marked "Settle" to approve the settlement with the above details, and a rejection button marked "Reject" to decline and not approve the settlement with the above details.

When the above link LK1 is tapped, a screen such as that shown in FIG. 1-14 is displayed, by way of example and not limitation.
This screen is one of the remittance request list screens displayed on the display unit 24 of the terminal 20C, which displays a list of pending requests between the remittance request and the other user A. This screen corresponds to the screen displayed on the display unit 24 of the terminal 20A shown in FIG.

The current location display area CLR2 displays the words "Transfer request with A.A.", indicating that an unprocessed request between user A.A. is being displayed.

In the settlement details confirmation area ACR2 at the bottom of the screen, by way of example and not limitation, the current balance of the user's (user CC's) electronic money account is displayed on the left, and the balance of the user's electronic money account after settlement is displayed on the right.
Also displayed below that, along with the text "Do you want to settle with this amount?", is a settlement button BT4 labeled "Settlement" for approving the settlement, and a revision proposal button labeled "Revision proposal" for suggesting revisions to the settlement without approving the settlement.

In this example, the current balance of the user C.C.'s electronic money account is "11,000 yen."
When the two requests proposed by user A.A are settled in a lump sum, for user C.C, "payment 10,000 yen" and "receipt 3,000 yen" come to "payment 7,000 yen." Therefore, it is shown that the lump sum settlement amount "7,000 yen" is subtracted from the current electronic money account balance "11,000 yen," so that the electronic money account balance after settlement will be "4,000 yen."

FIG. 1-15 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT4 is tapped.
In this example, the notification information display area NTR2 of the notification screen displays two sets of settlement result information as the contents of a lump sum settlement between the user C.C. and the user C.
Specifically, by way of example and not limitation, settlement result information corresponding to the third and fourth remittance requests selected in Figs. 1-11 and 1-12, respectively, is displayed.

Each settlement result information shows the individual amount along with "Request settlement" and the icon image of the other user.

In addition, rather than displaying the settlement result information corresponding to each selected remittance request, it is also possible to display the settlement result information together as a single result of a lump-sum settlement, as shown in FIG. 1-16, by way of example and not limitation.

As a non-limiting example, when the details confirmation link LK2 included in the payment result information in FIG. 1-16 is tapped, a screen such as that shown in FIG. 1-17 is displayed.
The current location display area CLR1 of this screen displays the words "Request Settlement," indicating that the results of lump-sum settlement are being displayed.

Below the current location display area CLR1, the lump sum settlement amount (in this example, "7,000 yen") and a mark (in this example, "received mark") of the executed lump sum settlement are displayed in association with the icon image and user name of user C.C.
Below that is a list of transfer requests that have been processed in bulk.

Also, at the bottom of the screen, an electronic money account balance display area WBR1 is displayed.
The words "Wallet Balance" are displayed in this electronic money account balance display area WBR1, and below that is a settlement result balance display area ARR1 which shows how one's electronic money account balance has changed as a result of the lump-sum settlement.

In the settlement result balance display area ARR1, by way of example and not limitation, the current electronic money account balance of the user (User A.A.) is displayed on the left side, and the electronic money account balance of the user as a result of lump-sum settlement is displayed on the right side.
Below that, the text "Two requests have been settled" is displayed to indicate that a lump sum settlement has been made.

In this example, it is shown that the balance of user A.A's electronic money account has changed from "500 yen" to "7,500 yen" as a result of a lump-sum settlement.

<Processing>
(1) Example of Processing First, an example of processing in this embodiment will be described.
The processes described below are merely examples of processes for implementing the method of the present disclosure, and the present disclosure is not limited to these processes.
Further, other steps may be added to the processes described below, or some steps may be omitted (deleted).
This also applies to each of the flowcharts (processes) described below.

FIG. 1-18 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
From the left, there are shown a process executed by the control unit 21 of the terminal 20A, a process executed by the control unit 21 of the terminal 20B, and a process executed by the control unit 11 of the server 10, respectively.
By way of example and not limitation, consider the case where user A.A of terminal 20A requests batch processing of remittance requests made to and from user B.B of terminal 20B.
In this process, for simplicity, the determination of whether the process is complete is omitted.

First, the control unit 21 of the terminal 20A, based on the input to the input unit, sends remittance request list request information for requesting a list of remittance requests, for example but not limited to, to the server 10 via the communication I/F 22 (A110).

In response to this, the control unit 11 of the server 10 refers to the first remittance request management data 157A and transmits the remittance request list information for user A.A to the terminal 20A via the communication I/F 14 (S120).

When the remittance request list information is received via the communication I/F 22, the control unit 21 of the terminal 20A displays the received remittance request list information on the display unit 24 (A120).

Then, the control unit 21 of the terminal 20A determines whether one or more remittance requests have been selected (A130), and if it determines that they have been selected (A130: YES), it transmits request selection information regarding the selected remittance requests to the server 10 via the communication I/F 22 (A140).

The control unit 11 of the server 10 determines whether or not request selection information has been received from the terminal 20A via the communication I/F 14 (S140), and if it is determined that the request selection information has been received, executes the settlement process (S150).

FIG. 1-19 is a flowchart showing an example of the flow of a first settlement process, which is an example of a settlement process.
The control unit 11 of the server 10 judges whether the remittance request is a lump-sum remittance request based on the request selection information received from the terminal 20A (S1510). Specifically, the control unit 11 judges whether the remittance request selected is two or more (plural) remittance requests.

If it is determined that the remittance requests are eligible for lump-sum settlement (S1510: YES), the control unit 11 of the server 10 calculates the lump-sum settlement amount based on the remittance request amount of the selected remittance request and the type of each selected remittance request (received remittance request (payment)/sent remittance request (received)) (S1515).

Then, the control unit 11 of the server 10 determines whether the balance of the electronic money account of at least one of the proposer user and the other user will become negative based on the calculated lump-sum settlement amount (S1520).

If it is determined that the amount will be negative (S1520: YES), then the control unit 11 of the server 10, by way of example and not limitation, sends lump-sum settlement NG information indicating that lump-sum settlement is not possible to the terminal 20A via the communication I/F 14 (S1523).
Then, the control unit 11 of the server 10 ends the first settlement process.

On the other hand, if it is determined that the electronic money account balance will not become negative (S1520: NO), the control unit 11 of the server 10 sends settlement confirmation information including lump-sum settlement amount information, which is information on the calculated lump-sum settlement amount, to the terminal 20A via the communication I/F 14 (S1525).

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

Then, the control unit 21 of the terminal 20A determines whether or not to request the server 10 to execute settlement based on whether or not an input has been made to the settlement confirmation information displayed on the display unit 24, for example and not by way of limitation (A160). Then, if it is determined that settlement is to be requested (A160: YES), the control unit 21 of the terminal 20A transmits settlement execution request information to the server 10 via the communication I/F 22 (A170).

The control unit 11 of the server 10 determines whether or not to execute settlement based on whether or not settlement execution request information has been received from the terminal 20A via the communication I/F 14 (S1530). Then, if it is determined that settlement is to be executed (S1530: YES), the control unit 11 of the server 10 executes lump-sum settlement (S1540).

FIG. 1-20 is a diagram showing an example of a table for explaining lump-sum settlement.
This table shows the types of unprocessed requests of the user who proposed the lump-sum settlement (user A.A in this processing example) vertically and horizontally, and shows the process for lump-sum settlement of two unprocessed requests based on a proposal by the proposer user, when the other user (user B.B in this processing example) is considered to be a single user.
The vertical and horizontal pending requests include received remittance requests and sent remittance requests, respectively.

(1-1) Combination of a received remittance request and a received remittance request In this combination, the proposer user (user A.A) remits money to the other user (user B.B) based on two unprocessed remittance requests that have been received from the other user.

In this case, the control unit 11 of the server 10 executes a process for transferring the lump-sum settlement amount, which is the sum of the remittance request amounts of the two received remittance requests, from the proposer user to the other user in the lump-sum settlement. Specifically, the control unit 11 of the server 10 updates the electronic money account balance of the proposer user by subtracting the lump-sum settlement amount, and updates the electronic money account balance of the other user by adding the lump-sum settlement amount.

(1-2) Combination of received remittance request and sent remittance request (1-3) Combination of sent remittance request and received remittance request In this combination, the proposer user remits money to/receives money from the other user based on the unprocessed remittance request received from the other user and the unprocessed remittance request sent to the other user. In this case, since there is a pay-and-receive relationship, the difference between the remittance request amount of the received remittance request and the remittance request amount of the sent remittance request becomes the lump-sum settlement amount.
Hereinafter, taking the difference in the remittance request amount (subtracting an amount) will be referred to as "subtracting an amount."

In addition, the deduction of amounts includes offsetting of amounts (hereinafter referred to as "amount offset").
By way of example and not limitation, offsetting amounts means that the amounts of the remittance requests selected for processing are subtracted from each other to result in zero amounts.
Amount offsetting occurs when the net result of deductions is zero.

In this example, if the remittance request amount of the received remittance request (the amount to be remitted) and the remittance request amount of the sent remittance request (the amount to be received) are the same amount, the amounts will be offset.

In this case, if the remittance request amount of the received remittance request (second amount) is greater than the remittance request amount of the sent remittance request (first amount), the control unit 11 of the server 10 calculates the lump-sum settlement amount as the amount obtained by subtracting the remittance request amount of the sent remittance request from the remittance request amount of the received remittance request (third amount). The control unit 11 then updates the electronic money account balance of the proposer's user by subtracting the lump-sum settlement amount, and updates the electronic money account balance of the other user by adding the lump-sum settlement amount.

In the opposite case, the lump-sum settlement amount is subtracted from the balance of the other user's electronic money account and updated, and the lump-sum settlement amount is added to the balance of the proposer's user's electronic money account and updated.

In addition, if the remittance request amount (second amount) of the received remittance request is the same as the remittance request amount (first amount) of the sent remittance request, the amounts are offset and no remittance is made.

As will be described in detail in a later embodiment, in a combination of a received remittance request and a sent remittance request, it is also possible, by way of example and not limitation, to process "remittance + remittance reminder (or new remittance request)."
In other words, it is possible to send money to the other user based on the received remittance request, and also to send a remittance reminder (or a new remittance request) to the other user based on the sent remittance request.

(1-4) Combination of a sent remittance request and a sent remittance request In this combination, the user proposing the lump-sum settlement sends to the other user a new remittance request that combines two unprocessed remittance requests (sent remittance requests) addressed to the other user.

This remittance request is a type of remittance request that consolidates multiple remittance requests (hereinafter referred to as a "bulk remittance request") and is used for purposes such as encouraging the remittance of the amount already requested to be remitted in one lump sum.
For convenience, this remittance request will be referred to as a "confirmation batch remittance request."

In this case, the control unit 11 of the server 10 creates a confirmation lump sum remittance request based on a request from the proposer's terminal 20. The control unit 11 of the server 10 then transmits confirmation lump sum remittance request information corresponding to the created confirmation lump sum remittance request to the other user's terminal 20.

In addition, in this combination (1-4), the control unit 11 of the server 10 may or may not send remittance reminder information corresponding to each of the selected multiple sent remittance requests to the other user's terminal 20, instead of sending the confirmation lump sum remittance request information to the other user's terminal 20.

In addition, in the combination (1-4), the user who proposes the lump-sum settlement (user A.A in this processing example) may or may not receive money from the other user (user B.B in this processing example) based on two unprocessed remittance requests that he or she has made to the other user.

In this case, the control unit 11 of the server 10 executes a process for transferring the total amount of the remittance requests of the selected sent remittance requests from the other user to the proposer user as the lump-sum settlement amount in the lump-sum settlement. Specifically, the control unit 11 of the server 10 updates the other user's electronic money account balance by subtracting the lump-sum settlement amount, and updates the proposer user's electronic money account balance by adding the lump-sum settlement amount.

Making a confirmation bulk remittance request (sending a confirmation bulk remittance request information) and making a remittance reminder (sending remittance reminder information) can be considered to have a different meaning and concept from "settlement" strictly speaking.
However, for the sake of simplicity, this specification will be illustrated and described as including these in settlement (as a type of settlement).

Returning to FIG. 1-19, after performing lump-sum settlement in S1540, the control unit 11 of the server 10 ends the first settlement process.

On the other hand, if it is determined that the settlement target is not a lump-sum settlement target, that is, only one remittance request has been selected (S1510: NO), the control unit 11 of the server 10 determines whether the balance in the electronic money account of the proposer's user will be negative (S1570). If it is determined that the balance will be negative (S1570: YES), the control unit 11 of the server 10 transmits, by way of example and not limitation, settlement NG information indicating that settlement is not possible to the terminal 20A via the communication I/F 14 (S1573).
Then, the control unit 11 of the server 10 ends the first settlement process.

On the other hand, if it is determined that the electronic money account balance will not become negative (S1570: NO), the control unit 11 of the server 10 sends settlement confirmation information including the settlement amount (the remittance request amount of the selected received remittance request) to the terminal 20A via the communication I/F 14 (S1575).

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

Then, the control unit 21 of the terminal 20A determines whether or not to request execution of settlement based on whether or not an input has been made to the settlement confirmation information displayed on the display unit 24, for example and not by way of limitation (A160). Then, if it is determined that execution of settlement is requested (A160: YES), the control unit 21 of the terminal 20A transmits settlement execution request information to the server 10 via the communication I/F 22 (A170).

The control unit 11 of the server 10 determines whether or not to execute the settlement (S1580) based on whether or not the settlement execution request information has been received from the terminal 20A via the communication I/F 14. Then, if it is determined that the settlement should be executed (S1580: YES), the control unit 11 of the server 10 executes the settlement (S1590).
Then, the control unit 11 of the server 10 ends the first settlement process.

Returning to FIG. 1-18, once the settlement process has been executed, the control unit 11 of the server 10 determines whether the settlement result is "OK" (S170). If it is determined that the settlement result is "OK" (S170: YES), the control unit 11 of the server 10 transmits the settlement result information to terminal 20A and terminal 20B via the communication I/F 14 (S190). The control unit 11 of the server 10 then terminates the process.

When the 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 received settlement result information (A190).
Then, the control unit 21 of the terminal 20A ends the process.

Similarly, when the settlement result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the received settlement result information (B190).
Then, the control unit 21 of the terminal 20B ends the process.

(2) Another Example of Processing Next, another example of processing in this embodiment will be described.
When making a lump sum settlement, it is also possible to require the approval of the other user. This is because the following cases can be considered:

(A) Cases where a malicious user tries to gain an advantage by making a lump-sum settlement. This is a problem that cannot be avoided in a system in which remittance requests can be created by user operation.

As an example and not a limitation, a malicious user may send a false remittance request to the other user. Specifically, it is assumed that a malicious user creates a false remittance request, sends it to the other user, and then offsets the amount by settling in a lump sum. More specifically, as an example and not a limitation, when user A.A receives a remittance request from user B.B for a specific remittance request amount (e.g., "3,000 yen"), user A.A creates a remittance request for the same amount (e.g., "3,000 yen") and sends it back to user B.B, and then user A.A setstling in a lump sum.

In addition to this, it is also possible that a malicious user may sneak in a false remittance request among other remittance requests. Specifically, this could involve creating and sending several false remittance requests without the other user realizing it, and then using these false remittance requests to settle a lump sum.

In these cases, not requiring the other user's approval would leave them open to deception.

(B) Cases where a lump-sum settlement is made against the will of the other party This is an example, but not a limitation, where a lump-sum settlement is made that includes at least one of the remittance requests that have already been sent to the other user, and the other user may feel that they have suffered a loss because the remittance request that is the sender (payment) from the other user's perspective is included in the lump-sum settlement.
However, if all transfer requests are processed, the end result will be the same, as long as legitimate transfer requests are processed.

In either of the above cases, approval from the other user can be required in order to allow the other user to confirm whether the remittance request that is the subject of bulk settlement is a legitimate remittance request (whether it is truly correct).

Fig. 1-21 is a flow chart showing another example of the flow of the processes executed by each device in this embodiment. The diagram should be read in the same way as Fig. 1-18.
In this process, the control unit 11 of the server 10 executes a second settlement process in S150.

FIG. 1-22 is a flowchart showing an example of the flow of the second settlement process.
If it is determined in S1530 that a request for execution of lump-sum settlement has been made (S1530: YES), the control unit 11 of the server 10 determines whether approval of the other user is required (S1531). Specifically, as a non-limiting example, it determines whether the remittance request management IDs of the two or more selected remittance requests include a remittance request management ID whose associated remittance master ID is the application ID of user A.A and whose associated remittance request destination ID is the application ID of a user other than user A.A, that is, whether a remittance request from the other party (user B.B) to the proposer's user (user A.A) is included.

If it is determined that approval from the other user is required (S1531: YES), the control unit 11 of the server 10 sends lump-sum settlement approval confirmation information, including lump-sum settlement amount information, to the terminal 20B via the communication I/F 14 as information for confirming with the other user (user B.B in this example) whether or not he or she approves the lump-sum settlement (S1533).

The control unit 21 of the terminal 20B determines whether or not lump-sum settlement approval confirmation information has been received from the server 10 via the communication I/F 22 (B150), and if it determines that it has been received (B150: YES), causes the display unit 24 to display the received lump-sum settlement approval confirmation information (B160).

Then, the control unit 21 of the terminal 20B determines whether or not to approve the lump-sum settlement based on whether an input approving the lump-sum settlement has been made to the input unit (B170). If it is determined to approve (B170: YES), the control unit 21 of the terminal 20B transmits lump-sum settlement approval information indicating that the lump-sum settlement is approved to the server 10 via the communication I/F 22 (B180).

After S1533, the control unit 11 of the server 10 determines whether the lump-sum settlement has been approved by the other user based on whether lump-sum settlement approval information has been received from the terminal 20B via the communication I/F 14 (S1535). If it is determined that the lump-sum settlement has been approved (S1535: YES), the process proceeds to S1540.

<First process by terminal>
The first processing, which is executed by the control unit of the terminal and is based on the first information and the second information, can include, by way of example and without limitation, processing somehow related to a remittance from a user of the proposer (user of the terminal) to a counterpart user (first user, second user) and processing somehow related to the user of the proposer receiving (receiving) an amount remitted from the counterpart user. Not only processing directly related to remittance or receipt of money, but also processing indirectly related to remittance or receipt of money can be included in the first processing.

By way of example and not limitation, the first process includes at least the following processes:
- A process for selecting a remittance request - A process for notifying the server 10 of a selected remittance request - A process for obtaining settlement confirmation information from the server 10 and displaying this on the display unit 24 - A process for requesting the server 10 to execute settlement - A process for obtaining settlement result information from the server 10 and displaying this on the display unit 24 - A process for requesting the server 10 to deduct an amount (including offsetting an amount) - A process for requesting the server 10 to create a confirmation lump sum remittance request

<Input to the terminal, etc.>
In the above process, the input to the terminal or the input by the user of the terminal is regarded as the operation input to the input unit (operation unit), but this is not limiting.

As an example and not as a limitation, instead of or in addition to operational input to the input unit (operation unit), sound (including voice) input to the input unit (sound input unit 25) may or may not be possible.
The same is true for other inputs to the terminal or by the user of the terminal.

Effects of the First Embodiment
According to this embodiment, by way of example and not limitation, multiple remittance requests can be processed in a batch, thereby improving user convenience.
In addition, by way of example and not limitation, users can send and receive money up to the limit of their balance, thereby improving user convenience.

More specifically, in this embodiment, the terminal 20 displays, at least on the display unit 24, remittance request information (not limiting, an example of the first information) regarding a remittance request from a first user (not limiting, an example of the first user) of a terminal 20 of a first user different from the terminal 20 itself to a user of the terminal 20 itself (not limiting, an example of the user of the terminal), or a display (not limiting, an example of the first display) based on first remittance request information (not limiting, an example of the first information) regarding a remittance request from the user of the terminal 20 itself to the first user, and a display (not limiting, an example of the second display) based on second remittance request information between the above-mentioned first user (not limiting, an example of the second user).
Terminal 20 is configured to perform a first process (not limited to, but an example of a first process based on the first information and the second information) based on the first remittance request information and the second remittance request information through control unit 21, based on input to terminal 20 on which the above-mentioned first display and second display are displayed.
As an example of an effect of an embodiment obtained by such a configuration, it becomes possible to process multiple pieces of information related to remittance requests collectively based on input to a terminal that displays a first display based on first information related to a remittance request from a first user to a user of the terminal, or a remittance request from the user of the terminal to the first user, and a second display based on second information related to a remittance request from a second user to a user of the terminal, or a remittance request from the user of the terminal to the second user, thereby improving user convenience.

In addition, in this embodiment, the first remittance request information includes information regarding a remittance request from a counterpart user to a user of one's own terminal 20 (not limited to this, but an example of information regarding a remittance request from a first user to a user of a terminal), and the second remittance request information includes information regarding a remittance request from a user of one's own terminal 20 to a counterpart user (not limited to this, but an example of information regarding a remittance request from a user of a terminal to a second user).
As an example of the effect of the embodiment obtained by such a configuration, the above-mentioned batch processing can be used to send to the first user or to send from the second user the difference between the amount sent by the user of the terminal to the first user (the amount paid by the user of the terminal) and the amount sent by the user of the terminal from the second user (the amount received by the user of the terminal). In this case, the amount sent or the amount sent is smaller than when multiple pieces of information related to the remittance request are processed one by one (the absolute value of the difference is smaller). Therefore, as one effect, not limited to this, it is more likely that the processing can be performed within the user's balance, and the user does not have to go through the trouble of recharging or taking a loan to send money. Also, as another effect, not limited to this, since multiple pieces of information can be processed in a batch, an increase in the number of cases to be processed can be expected.

In addition, this embodiment illustrates a configuration in which the first remittance request information includes information on a first remittance request amount (not limiting, an example of a first amount related to a remittance), and the second remittance request information includes information on a second remittance request amount (not limiting, an example of a second amount related to a remittance).
As an example of the effect of the embodiment obtained by such a configuration, the first amount related to the remittance and the second amount related to the remittance can be notified to the user of the terminal by the first display and the second display.

In this embodiment, the first process includes a process based on the first remittance request amount and the second remittance request amount.
As an example of an effect of an embodiment obtained by such a configuration, and by way of example and not limitation, it becomes possible to carry out processing such as lump-sum settlement based on the amount of the difference between the first amount and the second amount.

In this embodiment, the terminal 20 transmits lump-sum settlement confirmation information based on the second remittance request information to the terminal 20 of the first user (not limited to this, but an example of the terminal of the second user) via the server 10 through the communication I/F 22. In this case, the first process is configured to be executed by the control unit 21 based on the approval of the execution of the first process by the first user based on the lump-sum settlement confirmation information.
As an example of an effect of an embodiment obtained by such a configuration, the first process can be executed if the other party approves it, and, as a non-limiting example, the first process can be prevented from being executed if the other party does not approve it.

In addition, this embodiment illustrates a configuration in which the second user is the first user.
As an example of an effect of an embodiment obtained by such a configuration, the first process can be executed based on information regarding multiple remittance requests between a single user (first user) other than the user of the terminal 20.

In addition, in this embodiment, the first process is configured to include a process of transferring to the first user an amount obtained by subtracting the first remittance request amount from the second remittance request amount (this is an example of a third amount, but is not limited to this amount) when the second remittance request amount is greater than the first remittance request amount.
As an example of an effect of an embodiment obtained by such a configuration, since the difference between the second amount and the first amount can be transferred to the first user, the amount to be paid can be made smaller than when transferring money based on a single piece of information, thereby improving user convenience.

Furthermore, this embodiment illustrates a configuration in which the first remittance request information (not limiting, an example of the first information) includes information on the first remittance request amount (not limiting, an example of the first amount), the second remittance request information (not limiting, an example of the second information) includes information on the second remittance request amount (not limiting, an example of the second amount), and the first process is performed by the control unit 21 based on the first remittance request amount, the second remittance request amount, and the electronic money account balance of the user of the terminal 20 (not limiting, an example of the balance of the user of the terminal).
As an example of an effect of an embodiment obtained by such a configuration, a first process based on a first amount and a second amount can be executed taking into account the balance of the user of the terminal, so that, by way of example and not limitation, the first process can be executed if the balance of the user of the terminal is sufficient, but the first process can be prevented from being executed if the balance of the user of the terminal is insufficient.

In addition, this embodiment shows a configuration in which the first process is executed based on an operation of the suggestion button by the user of one's own terminal 20 (not limited to this, but an example of an input to the fifth display) and approval of the other user regarding lump-sum settlement (not limited to this, but an example of approval of the first user or the second user regarding the execution of the first process).
As an example of the effect of an embodiment obtained by such a configuration, the first process can be prevented from being executed without not only input by the user of the terminal to the fifth display, but also approval of the first user or the second user regarding the execution of the first process.

Furthermore, this embodiment illustrates a configuration in which the first process is executed based on the proposer's user's electronic money account balance (not limited to, but an example of the balance of a terminal user) and the other party's user's electronic money account balance (not limited to, but an example of the balance of a first user or a second user).
As an example of an effect of an embodiment obtained by such a configuration, the first process can be executed taking into account not only the balance of the user of the terminal, but also the balance of the first user or the second user, so that, by way of example and not by way of limitation, the first process is executed if the balance of the first user or the second user is sufficient, but the first process is not executed if the balance of the first user or the second user is insufficient.

Furthermore, in this embodiment, the first process is configured to include processing based on the first remittance request information and the second remittance request information, based on input to the terminal 20 by the user of the proposer, from among a plurality of remittance request information related to the user of the proposer, including the first remittance request information and the second remittance request information (an example of a plurality of pieces of information related to a remittance request to a user of the terminal or a remittance request by the user of the terminal, including at least the first information and the second information, but not limited to the first information and the second information).
As an example of an effect of an embodiment obtained by such a configuration, among a plurality of pieces of information related to a remittance request to a user of a terminal or a remittance request by a user of the terminal, which includes at least the first information and the second information, the first information and the second information can be appropriately processed based on input by the user of the terminal to the terminal.

In addition, this embodiment shows a configuration in which the other user is one user (not limited to this, this is an example of the second user being the first user), and the first process includes a process related to a transfer of money from the other user to the proposer's user, or a process related to a transfer of money from the proposer's user to the other user.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to realize a remittance from the first user to the user of the terminal, or a remittance from the user of the terminal to the first user, based on multiple pieces of information regarding a remittance request, with the same single user (first user = second user) as the other user.

In addition, in this embodiment, the above-mentioned remittance-related processing is configured to include processing for displaying lump-sum settlement confirmation information and lump-sum settlement result information (which are not limited to information, but are examples of information indicating that processing of a remittance request based on the first information and processing of a remittance request based on the second information have been executed) on the display unit 24.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to notify the user of the terminal that a remittance request based on the first information and a remittance request based on the second information have been processed.

<First Modification (1)>
As described above, the method of the above embodiment can be similarly applied to the case where the other users are different users.

Figure 1-23 is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20 in this modified example. This screen is an example of a remittance request list screen displayed on the display unit 24 of the terminal 20A, and is an example, by way of example and not limitation, of a screen that is displayed when the remittance request list icon is tapped on the main menu screen of Figure 1-9.

The current location display area CLR1 displays the words "Remittance Request List," which indicates that remittance request list information is being displayed.
Below the current location display area CLR1, pending requests transmitted and received between users of different terminals 20 are displayed in chronological order from the top to the bottom, starting from the oldest, by way of example and not limitation. In this example, from the top, a received remittance request from user B.B, a received remittance request from user C.C, a received remittance request from user B.B, a received remittance request from user C.C, a received remittance request from user D.D, a remittance request sent to user C.C, ... are displayed.

Next to each remittance request is a check area SR2 that can be tapped to switch the check "ON/OFF." By checking the area "ON," a check mark is displayed in the check area SR2, and the remittance request between the user and the requester can be selected for lump-sum settlement.

In this example, a received remittance request (payment of 2,000 yen) from the first user B.B and a received remittance request (payment of 1,000 yen) from the fourth user C.C are shown selected. When the settlement button BT5 at the bottom of the screen is tapped in this state, settlement request information for requesting lump-sum settlement of the two selected remittance requests is sent from terminal 20A to server 10.

In this example, a remittance (payment) is made from user A.A to user B.B, and a remittance (payment) is made from user C.C to user C.C, and there is no remittance (receipt) from the other user, so approval from the other user may be unnecessary.
Then, a lump sum settlement is executed by the server 10, and a remittance (payment) of "2,000 yen" from user A.A to user B.B, and a remittance (payment) of "1,000 yen" from user A.A to user C.C are realized.

This variation illustrates a configuration in which the first user is a different user than the second user.
As an example of the effect of the modified example obtained by such a configuration, the first process can be executed based on information regarding multiple remittance requests between at least two users (a first user and a second user different from the second user) other than the user of the terminal 20.

<First Modification (2)>
In the first embodiment, the proposer user manually selects the remittance requests to be subject to lump-sum settlement, but the present invention is not limited to this.
The terminal 20 of the proposer's user or the server 10 may or may not automatically select the remittance requests to be subject to lump-sum settlement.
This automatic selection of remittance requests to be subject to lump-sum settlement by the terminal 20 of the proposer's user or the server 10 also includes the meaning of proposing (suggesting) the selected remittance requests to the proposer's user.

Specifically, the control unit 21 of the proposer's terminal 20 performs a process of inquiring of the server 10 about the current electronic money account balance of the proposer's user. Then, the control unit 21 of the proposer's terminal 20 selects one or more remittance requests from among the remittance requests included in the remittance request list information received from the server 10, based on the amount of each remittance request and the type of each remittance request (received remittance request (payment)/sent remittance request (receive)), by way of example and not limitation, such that the current electronic money account balance of the proposer's user is the upper limit of the payment amount. In other words, one or more remittance requests are selected within a range that does not cause the current electronic money account balance of the proposer's user to become negative.

When the control unit 11 of the server 10 selects a remittance request, it may perform similar processing based on the remittance request data stored in the first remittance request management data 157A.

In this modified example, the first process is configured to select at least first remittance request information and second remittance request information from multiple pieces of remittance request information (not limited to, one example of multiple pieces of information) based on the proposer's user's electronic money account balance (not limited to, one example of the terminal user's balance), and to include processing based at least on this first remittance request information and second remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, at least the first information and the second information among the multiple pieces of information can be automatically selected in consideration of the balance of the user of the terminal, and settlement can be performed. In this case, the user of the terminal does not need to manually select the information, and therefore the convenience of the user can be improved.

<First Modification (3)>
The user interface of the display screen shown in the <Display Screen> of the first embodiment is merely an example, and is not limited to this.

Fig. 1-24 is a diagram showing another example of a UI (user interface) of a display screen displayed on the display unit 24 of the terminal 20. This display screen is an example of a remittance request list screen displayed on the display unit 24 of the terminal 20A, and shows another example of the remittance request list screen corresponding to Fig. 1-12.
On this display screen, received remittance requests and sent remittance requests are displayed in a table format as a list of remittance requests to and from user C.C. In this example, the left column of the table displays a list of received remittance requests, and the right column of the table displays a list of sent remittance requests.

For each of the lists of received remittance requests and sent remittance requests, the display field for each remittance request displays information such as the received date/time of the remittance request, the reason for payment, the request type (payment/receipt), and the amount of the remittance request.

By displaying the request in this way, it becomes possible to compare received remittance requests with sent remittance requests, improving user convenience.

In the above embodiment, the unprocessed remittance requests are displayed on the remittance request list screen, but the present invention is not limited to this.
In addition, by way of example and not limitation, a list of pending remittance requests may or may not be available for viewing from a screen such as a notification screen of the payment application, a profile screen of the payment application, or a home page of the payment application.

<First Modification (4)>
In the above embodiment, the case where approval of the other user is required for lump-sum settlement has been described. However, if the system is configured so that a remittance request cannot be created based on a user's operation, approval of the other user may not be required.

One possible example of such a system is, but is not limited to, a system that links and manages a user's electronic money or electronic payment with a remittance request. More specifically, one possible system is one in which, after one user makes an electronic payment using electronic money, at least a portion of the payment amount can be charged to another user via a remittance request as an advance (advance amount). One possible use of this system is, but is not limited to, when multiple users split the bill.

In this case, after making the electronic payment, the server 10 can create a remittance request in which the advance payment amount is set as the remittance request amount according to the user operation, and send the request to the terminal 20 of another user.

In such a system, a user who wishes to settle a bill in a lump sum must first spend their electronic money account balance to make the electronic payment, thereby minimizing the risk of the above-mentioned lump sum processing being misused.

<First Modification (5)>
When making a lump-sum settlement, a settlement proposal proposed to one user by another user to make a payment (a settlement proposal in which one user needs to make a payment to the other user) may be treated as a new remittance request requested by the other user to send money, and this new remittance request may be managed on the server 10 side as an unprocessed received remittance request of the one user.

Specifically, as an example and not a limitation, in the example of FIG. 1-13, a settlement proposal proposed to user C.C. (first user) by user A.A. (second user) to make a payment of "7,000 yen" may be treated as a new remittance request requested by user A.A. to remit "7,000 yen", and this remittance request may be managed on the server 10 side as an unprocessed received remittance request for "payment 7,000 yen" from user C.C.

In addition, as a non-limiting example, when a newly created received remittance request is tapped on a remittance request list screen displayed on the display unit 24 of the terminal 20, information about the remittance request that contributed to the creation of the received remittance request (the remittance request that caused the creation of the received remittance request) (as a non-limiting example, detailed information such as the type of remittance request, the remittance request amount, date and time, and reason) can be displayed hierarchically along the time axis, thereby enabling the user to trace the history of a single remittance request.

Specifically, when the unprocessed received remittance request "Payment 7,000 yen" of the above user C.C is tapped, information on each of the remittance requests that contributed to the creation of the received remittance request, for example but not limited to, the third received remittance request "Payment 10,000 yen" and the fourth sent remittance request "Receive 3,000 yen" in the example of FIG. 1-14, may be displayed.
This technique can also be applied to previously sent remittance requests.

<First Modification (6)>
In the first embodiment, the first user and the second user are described as general users of the terminal 20, but the present invention is not limited to this.
At least one of the first user and the second user may or may not be a user of a business such as a store, rather than a general user. In this case, the business may include, but is not limited to, a business (store) that is expected to request money from the user of the terminal 20 by making a remittance request, such as a business that sells products (including the provision of services) or a business that operates a money lending business.

In this case, in the above embodiment, these businesses obtain an account for the payment service (payment application). Then, using this account, they can send remittance request information and remittance reminder information via the server 10 to the terminal 20 of the user to whom money is to be billed (the remittance request destination user).

The account acquired by the business (store) may be a general account, which is an account for the user of the terminal 20, or an account for the business.

In this modified example, at least one of the first user and the second user is a shop that sells the product related to the remittance request.
As an example of the effect of this modified example obtained by such a configuration, not only general users but also users at shops can be made users who can make remittance requests to users of terminals.

<First Modification (7)>
It is assumed that some users of terminal 20 may feel awkward and hesitate to propose lump-sum settlement to the other user. For example and without limitation, this may be the case when the other user is a senior or a close friend.

Therefore, it is possible for the user making the batch proposal to be a user using a business account instead of the user of the terminal 20 .
By way of example and not limitation, a business account is a user who has an official account (hereinafter referred to as an "official account" and appropriately expressed as "OA: Official Account") in that service (in the above example, a payment service).

As an example, a user with an official account may be, by way of example and not limitation, a payment service provider or a messaging service provider.
In this case, the server 10 can treat the user who proposed the lump-sum settlement as a payment service provider or messaging service provider and send lump-sum settlement approval confirmation information to the terminal 20 of the other user.

This modified example shows a configuration in which the user who proposes lump-sum settlement is a user who uses an official account (not limited to this, but is an example of a business account).
As an example of the effect of this modified example obtained by such a configuration, a user using a business account can be allowed to request lump-sum settlement on behalf of the user who wishes to settle the bill in one lump sum, thereby improving user convenience.

Second Example
The second embodiment relates to a process performed when the user's balance is insufficient in the lump-sum settlement described in the first embodiment.
The contents described in the second embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
FIG. 2A is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20 in this embodiment.
This remittance request list screen is a screen displayed on the display unit 24 of the terminal 20A of the user A.A, and is a list screen of remittance requests addressed to the other user B.B.
The current location display area CLR1 at the top of the screen displays the words "Remittance request with B.B.", indicating that an unprocessed request between user B.B. is being displayed.

Below current location display area CLR1, a list of remittance requests addressed to user B.B. is displayed. In this example, the first received remittance request, the second received remittance request, and the fourth sent remittance request are selected, and the change in the user's (user A.A's) electronic money account balance is shown in settlement details confirmation area ACR3 in electronic money account balance display area WBR2 at the bottom of the screen. In this example, the user's current electronic money account balance is "500 yen," and it is shown that the user's electronic money account balance will become "0 yen" after lump-sum settlement. In this case, the balance is sufficient, so lump-sum settlement is possible.

In addition, to the right of the words "Wallet Balance" in the electronic money account balance display area WBR2, a charge button, indicated by a plus icon in a circle, for charging the wallet balance is also displayed.

FIG. 2-2 shows a remittance request list screen similar to that of FIG. 2-1, but with a different remittance request selected.
In this example, in addition to the first received remittance request, the second received remittance request, and the fourth sent remittance request, the third received remittance request is selected, and the change in the user's (user A.A's) electronic money account balance is shown in settlement content confirmation area ACR4 in electronic money account balance display area WBR2 at the bottom of the screen. In this example, the user's current electronic money account balance is "500 yen," and it is shown that the user's electronic money account balance will become "-500 yen" after lump-sum settlement. In this example, the user's current electronic money account balance is "500 yen," while the payment is "1000 yen," meaning that there is a shortfall of "500 yen," and lump-sum settlement is not possible.

In this case, the text "Insufficient balance!" is displayed in the settlement details confirmation area ACR4 along with a warning mark as insufficient balance information indicating that the electronic money account balance is insufficient, by way of example and not limitation. When the proposal button BT6 is tapped in this state, the display shown in FIG. 2-3 is displayed.

In Figure 2-3, charge confirmation information CG1 is displayed as a pop-up in the center of the remittance request list screen in Figure 2-2 as information to confirm to the user whether or not to charge the balance of the electronic money account. Specifically, along with the text "Do you want to charge the 500 yen shortfall?", an OK button for confirming the charge and a Cancel button for canceling the charge are displayed.

When the OK button is tapped in this state, the server 10 executes a charge process to charge "500 yen" to the balance of the electronic money account of the user A. A. Then, a lump sum settlement is performed.

<Processing>
2-4 and 2-5 are flow charts showing an example of the flow of a third settlement process which is an example of the settlement process executed by the control unit 11 of the server 10 in this embodiment.
If it is determined in S1520 that the electronic money account balance of any user will be negative (S1520: YES), the control unit 11 of the server 10 determines whether or not the user whose electronic money account balance will be negative is the user of the proposer (S1550). If it is determined that the user is the user of the proposer (S1550: YES), the control unit 11 of the server 10 transmits lump-sum settlement confirmation information including, by way of example and not limitation, lump-sum settlement amount information and insufficient balance information to the terminal 20A via the communication I/F 14 (S1551).

Then, the control unit 11 of the server 10 judges whether or not a request to execute lump-sum settlement has been made based on whether or not settlement execution request information has been received from the terminal 20A via the communication I/F 14 (S1553). If it is judged that a request has been made (S1553: YES), the control unit 11 of the server 10 judges whether or not to charge the balance of the electronic money account of the user A.A (S1555). Specifically, by way of example and not limitation, the control unit 11 of the server 10 transmits the charge confirmation information described above to the terminal 20A and causes it to be displayed on the display unit 24, and judges whether or not information for approving the charge has been received from the terminal 20A.

If it is determined that recharge is to be performed (S1555: YES), the control unit 11 of the server 10 executes the recharge process (S1557). Specifically, the control unit 11 executes a process to replenish the shortfall in the lump-sum settlement to the balance of the electronic money account of the user A.A. using the bank account or credit card of the user A.A. that has been registered in advance. The control unit 11 of the server 10 then proceeds to S1531.

On the other hand, if it is determined that the user whose electronic money account balance will become negative is not the proposer's user, i.e., that the user whose electronic money account balance will become negative is the other party's user (S1550: NO), the control unit 11 of the server 10 sends lump-sum settlement confirmation information, including lump-sum settlement amount information, to the terminal 20A via the communication I/F 14 (S1559).

After that, if it is determined that a request to execute lump-sum settlement has been made from terminal 20A (S1561: YES), the control unit 11 of the server 10 sends lump-sum settlement approval confirmation information, including lump-sum settlement amount information and insufficient balance information, to terminal 20B via the communication I/F 14 (S1563).

Then, the control unit 11 of the server 10 determines whether the lump-sum settlement has been approved based on whether lump-sum settlement approval information has been received from the terminal 20B via the communication I/F 14 (S1565).

If it is determined that the lump sum settlement has been approved (S1565: YES), the control unit 11 of the server 10 determines whether or not to charge the balance of the electronic money account of user B.B (S1567). Specifically, and by way of example and not limitation, the control unit 11 transmits the charge confirmation information described above to terminal 20B and causes it to be displayed on the display unit 24, and determines whether or not information for approving the charge has been received from terminal 20B.

If it is determined that recharge is to be performed (S1567: YES), the control unit 11 of the server 10 executes a recharge process (S1569). Specifically, the control unit 11 executes a process of replenishing the balance of the electronic money account of the user B.B. with the shortfall in the lump-sum settlement using the bank account or credit card of the user B.B. that has been registered in advance.
Then, the control unit 11 of the server 10 advances the process to S1540.

If it is determined in S1553 that lump-sum settlement has not been requested (S1553: NO), or if it is determined in S1555 that charging will not be performed (S1555: NO), the control unit 11 of the server 10 ends the third settlement process.

In addition, if it is determined in S1561 that lump-sum settlement has not been requested (S1561: NO), if it is determined in S1565 that lump-sum settlement has not been approved (S1565: NO), or if it is determined in S1567 that charging will not be performed (S1567: NO), the control unit 11 of the server 10 ends the third settlement process.

Note that before executing the process of S1540, the same process as S1520 may be executed again, and if it is determined that the balance of any user's electronic money account will become negative, the process of S1540 may be suspended, or it may not be necessary to do so.

<Effects of the Second Example>
In this embodiment, the first remittance request information (not limiting, an example of the first information) includes information on the first remittance request amount (not limiting, an example of the first amount), the second remittance request information (not limiting, an example of the second information) includes information on the second remittance request amount (not limiting, an example of the second amount), and the first process is performed by the control unit 21 based on the first remittance request amount, the second remittance request amount, and the electronic money account balance of the user of the terminal 20 (not limiting, an example of the balance of the user of the terminal).
As an example of an effect of an embodiment obtained by such a configuration, the first process can be appropriately executed based on the first amount and the second amount, taking into account the balance of the user of the terminal.

Furthermore, this embodiment illustrates a configuration in which, when the sum of the first remittance request amount and the second remittance request amount exceeds the balance of the electronic money account of the user of one's own terminal 20 and the user of one's own terminal 20 makes a remittance, a display of insufficient balance information (not limited to this, but an example of a third display indicating that the first process cannot be executed) is displayed on the display unit 24 of one's own terminal 20.
As an example of the effect of an embodiment obtained by such a configuration, in a case where the user of the terminal attempts to transfer money even though the sum of the first amount and the second amount exceeds the terminal user's balance, the user of the terminal can be informed that the first process cannot be executed.

Furthermore, this embodiment illustrates a configuration in which, when the sum of the first remittance request amount and the second remittance request amount exceeds the electronic money account balance of the user of one's own terminal 20 and a remittance is made from the user of one's own terminal 20, a display of confirmation of charging the electronic money account balance of the user of one's own terminal 20 (not limited to this, an example of a fourth display indicating that the balance will be charged) is displayed on the display unit 24 of one's own terminal 20.
As an example of the effect of an embodiment obtained by such a configuration, in a case where the sum of the first amount and the second amount exceeds the terminal user's balance but the terminal user is to transfer money, the terminal user can be informed that it is possible to top up the balance and make up the shortfall.

<Second Modification>
In the second embodiment, by way of example and not limitation, when the terminal 20 displays a remittance request list screen on the display unit 24, it may or may not display on the display unit 24 information indicating that one's electronic money account balance can be topped up (top-up information) and information indicating that a loan (financing) can be made (loan information).

Businesses that provide loans can be, by way of example and not limitation, payment service businesses (payment application businesses)/messaging service businesses (messaging application businesses) and financial institutions such as banks.

In this case, based on the input of the user requesting a loan, the server 10 can provide a loan in the form of electronic money (using electronic money as a means) within a certain loan amount. Alternatively, the server 10 can communicate with a server of an affiliated financial institution to request a loan and have the loan approved.
In this case, the balance of the electronic money account may be treated as either a negative or positive value.

Once the loan has been settled, by way of example and not limitation, the user may be prompted to repay the loan amount by a set repayment deadline.
In this case, the repayment method may be the same as that for a general loan.

This modified example shows a configuration in which the terminal 20 displays on the display unit 24 a display based on the first remittance request information (not limiting, an example of a first display), a display based on the second remittance request information (not limiting, an example of a second display), a display of charge information (not limiting, an example of a display related to charging a balance), or loan information (not limiting, an example of a display related to making a loan).
As an example of the effect of the modified example obtained by such a configuration, when displaying a first display based on the first information and a second display based on the second information, a display regarding topping up the balance or taking out a loan can be displayed together, enabling the user to easily top up the balance or take out a loan.

<Third Example>
The third embodiment is related to the second embodiment and is an embodiment in which the display mode of the display related to the execution of lump-sum settlement is changed.
The contents described in the third embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
FIG. 3A is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20 in this embodiment.
This remittance request list screen corresponds to the screen shown in FIG. 2-1 displayed on the display unit 24 of the terminal 20A of the user A.A, and is displayed when the balance in the electronic money account of the user A.A is sufficient.

A settlement content confirmation area ACR5 at the bottom of the screen indicates that the balance of the user's electronic money account will become "0 yen" if the lump sum is settled, but that lump sum settlement is possible.
In this case, when the proposal button BT7 is operated (tapped), the terminal 20A accepts the operation of proposing the lump-sum settlement.

FIG. 3B is a diagram showing another example of a remittance request list screen displayed on the display unit 24 of the terminal 20 in this embodiment.
This remittance request list screen corresponds to the screen shown in FIG. 2-2 displayed on the display unit 24 of the terminal 20A of the user A.A, and is displayed when the balance of the electronic money account of the user A.A is insufficient.
In this screen, based on the fact that the balance of the electronic money account of the user A.A is insufficient, the proposal button BT7 displayed in the settlement content confirmation area ACR5 at the bottom of the screen is displayed in a different display mode from that in FIG. 3-1. Specifically, as an example and not a limitation, the proposal button BT7 is displayed grayed out, and even if an operation (tap) is performed on the proposal button BT7, the terminal 20A does not accept the operation.

In FIG. 3B, a charge button for the electronic money account may be displayed in the electronic money account balance display area WBR1 to prompt the user to charge, but this is not essential.
In addition, if the company that operates the payment service has a partnership with a financial institution, it may or may not display a loan function button to obtain a loan from the financial institution and charge an electronic money account.

<Effects of the Third Embodiment>
In this embodiment, the terminal 20 displays a suggestion button (not limited to this, but an example of the fifth display related to the execution of the first process) on the display unit 24. In this case, the suggestion button is configured to change its display mode based on the first remittance request amount, the second remittance request amount, and the user's electronic money account balance.
As an example of the effect of an embodiment obtained by such a configuration, the display manner of the fifth display regarding the execution of the first process is changed based on the first amount, the second amount, and the balance of the user of the terminal, so that, by way of example and not limitation, the user of the terminal can be simply and appropriately notified that the first process cannot be executed, taking into account the balance of the user of the terminal.

Furthermore, in this embodiment, when the sum of the first remittance request amount and the second remittance request amount exceeds the balance of the electronic money account of the user of the own terminal 20 and a remittance is made from the user of the own terminal 20, the suggestion button is displayed on the display unit 24 of the own terminal 20 in a display mode indicating that the operation is not accepted (this is not limiting, but is an example of a display mode indicating that the first process cannot be executed).
As an example of the effect of an embodiment obtained by such a configuration, in a case where the user of the terminal attempts to transfer money even though the sum of the first amount and the second amount exceeds the terminal user's balance, the user of the terminal can be informed that the first process cannot be executed.

<Fourth Example>
The fourth embodiment relates to a method (algorithm) for processing lump-sum settlement.
The contents described in the fourth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Processing>
The bulk settlement performed by the server 10 may include, by way of example and not limitation, the following two schemes.
(1) Batch settlement
(2) Sequential settlement

(1) Batch settlement is, by way of example and not limitation, a method of batch settlement in which two or more selected remittance requests are processed at once.
In this method, the control unit 11 of the server 10 calculates the final lump-sum settlement amount based on the remittance request amount of each selected remittance request and its type (received remittance request/sent remittance request).
In this case, even if settlement is made based on the calculated lump-sum settlement amount, if the balance of the electronic money account of the user of the proposer's terminal 20 and the balance of the electronic money account of the other user do not both become negative, settlement is deemed OK.
On the other hand, if settlement based on the calculated lump-sum settlement amount results in a negative balance in either the electronic money account of the user of the proposer's terminal 20 or the electronic money account of the other user, settlement is not allowed.

(2) Sequential settlement is, by way of example and not limitation, a method of batch settlement in which two or more selected remittance requests are processed sequentially.
In this method, the control unit 11 of the server 10 repeats sequential processing for two or more selected remittance requests, including calculating the settlement amount and updating the electronic money account balance of the proposer's user and the electronic money account balance of the recipient user, based on the amount of each remittance request and its type (received remittance request/sent remittance request).
If either the balance of the electronic money account of the user of the terminal 20 of the proposer or the balance of the electronic money account of the other user becomes negative during the sequential processing, the settlement in that order is rejected. Then, the order of processing the remittance requests is changed and the sequential processing is performed again from the beginning.
On the other hand, as a result of sequential processing up to the final remittance request, if at least one of the balance of the electronic money account of the user of the proposer's terminal 20 and the balance of the electronic money account of the other user is not negative, the settlement is deemed OK, and the settlement is carried out in that order.

Even if a brute force approach is taken by changing the order in which remittance requests are processed, if either the balance in the electronic money account of the user of the proposer's terminal 20 or the balance in the electronic money account of the other user becomes negative during sequential processing, sequential settlement cannot be performed, and settlement can be rejected.

<Display screen>
The difference between batch settlement and sequential settlement will be described with reference to the example of FIG.
Here, the following two cases will be considered.
(Case 1) User A. A's current electronic money account balance = 500 yen, User B. B's current electronic money account balance = 1,500 yen (Case 2) User A. A's current electronic money account balance = 500 yen, User B. B's current electronic money account balance = 1,000 yen

First, (Case 1) will be described.
(1) When batch settlement is applied When batch settlement is applied, the first received remittance request, the second received remittance request, and the fourth sent remittance request selected in Figure 3-1 will be processed simultaneously.
In this case, the lump sum settlement consists of "payment 2,000 yen", "payment 500 yen", and "receipt 2,000 yen", totalling "payment 500 yen" (a payment of 500 yen from user AA to user BB).
The current balance of user A.A's electronic money account is "500 yen", and since user A.A's balance is not negative, if an instalment is made, settlement can be made regardless of user B.B's electronic money account balance.

(2) When sequential settlement is applied When sequential settlement is applied, the first received remittance request, the second received remittance request, and the fourth sent remittance request selected in Figure 3-1 will be processed one by one.
By way of example and not limitation, consider the following order of processing: second received remittance request → fourth sent remittance request → first received remittance request.

First, the second received remittance request is a payment of "500 yen" from user A.A to user B.B, so when this payment is settled, the balance of user A.A's electronic money account will change from "500 yen to 0 yen," and the balance of user B.B's electronic money account will change from "1,500 yen to 2,000 yen."

Next, the fourth remittance request that has already been sent is for user A.A to receive "2,000 yen" from user B.B., so when this payment is settled, the balance of user A.A's electronic money account will change from "0 yen to 2,000 yen," and the balance of user B.B's electronic money account will change from "2,000 yen to 0 yen."

Finally, the first received remittance request is a payment of "2,000 yen" from user A.A to user B.B, so when this payment is settled, the balance of user A.A's electronic money account will change from "2,000 yen to 0 yen," and the balance of user B.B's electronic money account will change from "0 yen to 2,000 yen."

Since the current balance of the electronic money account of user B.B. is "1,500 yen", as a result of the above settlement, user B.B. will receive "500 yen" from user A.A.
In this example, since neither the balance in the electronic money account of user A.A nor the balance in the electronic money account of user B.B are negative, settlement is possible even by sequential settlement.

Next, (Case 2) will be described.
(1) Case where batch adjustment is applied When batch adjustment is applied, the procedure is the same as (Case 1).
In other words, the current balance of user A.A's electronic money account is "500 yen", and since user A.A's balance is not negative, if an instalment is made, settlement is possible regardless of user B.B's electronic money account balance.

(2) When sequential settlement is applied When sequential settlement is applied, similar to (Case 2), the first received remittance request, the second received remittance request, and the fourth sent remittance request selected in Figure 3-1 will be processed one by one.
However, in (Case 2), unlike (Case 1), because the current electronic money account balance of user B.B is "1,000 yen," no matter in what order the first received remittance request, the second received remittance request, and the fourth sent remittance request selected in FIG. 3-1 are processed, it is not possible to settle the electronic money account balance of user A.A and the electronic money account balance of user B.B so that they do not become negative.

From the above, in (Case 1), settlement is possible through either batch settlement or sequential settlement, but in (Case 2), settlement through batch settlement is possible but sequential settlement is not possible.

In both of the above cases, by way of example and not limitation, if the operator of the payment service is affiliated with a financial institution, the operator may or may not allow settlement by temporarily allowing a shortfall in the user's electronic money account balance to be a negative value in the account balance.

FIG. 4-1 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20B when successive settlement is applied in the above (Case 1).
A current location display area CLR3 is configured at the top of the notice screen, and displays the word "Notice" to indicate that a notice regarding a payment application is being displayed.
In the notice information display area NTR3 below the current location display area CLR3, lump-sum settlement approval confirmation information transmitted from the server 10 to the terminal 20B based on a proposal from the user A.A is displayed.
In (Case 1), since settlement by successive settlement is possible, the settlement button BT8 included in the lump-sum settlement approval confirmation information is displayed in a state where it can accept operation.

In contrast, FIG. 4-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20B when successive settlement is applied in the above (Case 2).
The information displayed on this notification screen is the same as that shown in Figure 4-1, however, in (Case 2), since settlement by sequential settlement is not possible, the settlement button BT8 included in the lump-sum settlement approval confirmation information is displayed grayed out, and even if an operation (tap) is performed on the settlement button, terminal 20B will not accept the operation.

Fifth Example
The fifth embodiment is an embodiment related to the "request offset" of the batch processing described above.
The contents described in the fifth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

As mentioned above, if the remittance request amount of the selected received remittance request (amount to be remitted) is the same as the remittance request amount of the selected sent remittance request (amount to be received), it is possible to offset the amounts through a lump sum settlement.

However, in such a case, it is also possible to offset the requests instead of making a lump sum settlement.
By way of example and not limitation, request offsetting means cancelling out the remittance requests selected for processing against each other, eliminating those remittance requests, and deleting the data for those remittance requests.

<Display screen>
5-1 is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20A of user A. A in this embodiment. This remittance request list screen is a screen in which the other user is user B. B.
This remittance request list screen shows the first received remittance request (payment 2,000 yen) and the fourth sent remittance request (received 2,000 yen) in a selected state.

In the settlement details confirmation area ACR6 at the bottom of the screen, user A.A's current electronic money account balance and user A.A's post-settlement electronic money account balance are displayed. When a lump-sum settlement is made based on the two selected remittance requests, the amounts are offset. For this reason, in this example, user A.A's current electronic money account balance and user A.A's post-settlement electronic money account balance are the same amount (500 yen).

Also, below that is the text "Do you want to propose offsetting the request?" along with a propose button and a cancel button.
By way of example and not limitation, when the suggest button is tapped, information for requesting a request offset is sent from terminal 20A to server 10. Then, a request offset process is executed by server 10, and the data of the two selected remittance requests is deleted.

<Processing>
(1) Example of Processing FIG. 5B is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
If it is determined in S140 that the request selection information has been received from the terminal 20A (S140: YES), the control unit 11 of the server 10 executes a request cancellation process (S350).

In the request offset process, the control unit 11 of the server 10 calculates a lump-sum settlement amount based on the remittance request selected by the terminal 20A, and determines whether or not the remittance request can be offset based on the calculated lump-sum settlement amount. If it is determined that the remittance request can be offset, the control unit 11 of the server 10 transmits request offset confirmation information to the terminal 20A.

In terminal 20A, request offset confirmation information is displayed on display unit 24 (A350), and if it is determined that a request for executing request offset is to be made based on input on this display (A360: YES), request offset execution request information is transmitted from terminal 20A to server 10 (A370).

The control unit 11 of the server 10 executes the request offset based on the request for executing the request offset received from the terminal 20A. Specifically, the control unit 11 deletes the data of the remittance request to be offset from the first remittance request management data 157A.
It is also possible to set the remittance completion flag of the remittance request to be offset to "ON" without deleting the remittance request data.
Then, the control unit 11 of the server 10 ends the request offset process.

Then, the control unit 11 of the server 10 judges whether the request offset result is "OK" (S370). If it is judged to be "OK" (S370: YES), the control unit 11 of the server 10 transmits the request offset result information to each of the terminals 20A and 20B via the communication I/F 14 (S390). The control unit 11 of the server 10 then ends the process.

When the request offset 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 received request offset result information (A390).
Then, the control unit 21 of the terminal 20A ends the process.

Similarly, when the request offset result information is received from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the received request offset result information (B390).
Then, the control unit 21 of the terminal 20B ends the process.

(2) Another Example of Processing When offsetting a request as described above, approval of the other user may be required. The cases where approval of the other user is required are similar to those described in the lump-sum settlement.

The processing in this case can be configured in a similar manner to the processing when approval from the other user is required for lump-sum settlement (as an example, not a limitation, the processing in Figures 1-21 to 1-22), so illustrations and detailed explanations will be omitted.

<Effects of the Fifth Example>
In this embodiment, the first process is configured to include processing based on the first remittance request information and the second remittance request information, based on input to the terminal 20 by the user of the proposer, from among a plurality of remittance request information related to the user of the proposer, including the first remittance request information and the second remittance request information (an example of a plurality of pieces of information related to a remittance request to a user of the terminal or a remittance request by a user of the terminal, including at least the first information and the second information, but not limited to the first information and the second information).
As an example of an effect of an embodiment obtained by such a configuration, among a plurality of pieces of information related to a remittance request to a user of a terminal or a remittance request by a user of the terminal, which includes at least the first information and the second information, the first information and the second information can be appropriately processed based on input by the user of the terminal to the terminal.

In addition, this embodiment illustrates a configuration in which the first remittance request information and the second remittance request information are information on the same remittance request amount, and the first process is a process of request offsetting the first remittance request information and the second remittance request information based on the first remittance request information and the second remittance request information (this is not limiting, but is an example of offsetting the first information and the second information).
As an example of the effect of the embodiment obtained by such a configuration, when the first information and the second information are information of the same amount, these pieces of information can be offset, thereby improving the convenience of both the user who requests remittance using the first information and the user who requests remittance using the second information.

<Fifth Modification>
In the fifth embodiment, if the remittance request amount of the remittance request selected for processing is not offset, a new remittance request may or may not be created, with the difference amount being the remittance request amount, and the type (payment/receipt) being determined by the positive or negative sign of the amount deduction result.

Sixth Example
The sixth embodiment is an embodiment relating to "creating a batch remittance request" from the batch processing described above.
The contents described in the sixth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
FIG. 6A is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20A in this embodiment.
The current location display area CLR1 at the top of this screen displays the words "Remittance request with D.D.", indicating that an unprocessed request between user D.D. and the user is being displayed.
Also, the current location display area CLR1 shows that the first to fourth remittance requests are selected from among the pending requests between user D.D.

When the first through fourth selected remittance requests are settled in a lump sum, the lump sum settlement will be "Payment 1,100 yen," and "1,100 yen" will be paid from user A.A to user D.D. However, in this example, user A.A's current electronic money account balance is "500 yen," so there will be a shortfall of "600 yen" in the payment amount.

Therefore, in this embodiment, the server 10 creates a lump-sum remittance request based on the amount of the shortfall in payment when lump-sum settlement is performed.
However, in this embodiment, although a lump sum remittance request is created, no lump sum settlement is performed.

Specifically, the settlement details confirmation area ACR7 at the bottom of the screen displays your current electronic money account balance, and the balance that will be your electronic money account if you settle the balance, which is "500 yen."

Below that, a suggestion button BT9 and a cancel button are displayed along with the text "Would you like to suggest consolidating the requests?".
When the proposal button BT9 is tapped in this state, a new remittance request is created based on the shortfall in payment amount of 1,100 yen. As a result, the screen shown in FIG. 6-2 is displayed.

In FIG. 6-2, a newly created remittance request is displayed, which is a lump-sum remittance request that combines four remittance requests and has a payment amount of "1,100 yen".
In this example display screen, the four remittance requests selected in Fig. 6-1, i.e., the remittance requests used to create the batch remittance request (combined remittance requests), are displayed in a hanging format under the batch remittance request. In addition, to make it easier for the user to recognize, these remittance requests are displayed in a different manner (grayed out in this example) from the other remittance requests.

Unlike this example display screen, the remittance requests used to create the lump sum remittance request may not be displayed.
In addition, when a lump sum remittance request is tapped, the remittance requests used to create the lump sum remittance request may be displayed.

<Processing>
FIG. 6C is a flowchart showing an example of the flow of the lump sum remittance request creation process executed by the control unit 11 of the server 10 in this embodiment.
The control unit 11 of the server 10 determines whether or not the creation of a lump sum remittance request has been requested from the terminal 20 based on whether or not lump sum remittance request creation request information has been received from the terminal 20 (S510).
The bulk remittance request creation request information may include, by way of example and not limitation, a selection of remittance requests for which the bulk remittance request is to be created.

If it is determined that a request has been made (S510: YES), the control unit 11 of the server 10 refers to the remittance request management data 157 and calculates the remittance request amount of the bulk remittance request to be created (hereinafter referred to as the "bulk remittance request amount") based on the remittance request amount of each selected remittance request and its type (received remittance request (payment)/sent remittance request (receive)) (S530).

Then, the control unit 11 of the server 10 creates a lump sum remittance request based on the calculated lump sum remittance request amount, and stores the data of the created lump sum remittance request in the remittance request management data 157 (S550).

Next, the control unit 11 of the server 10 transmits lump sum remittance request creation result information regarding the result of creating the lump sum remittance request to the requesting terminal 20 via the communication I/F 14 (S570).
Then, the control unit 11 of the server 10 ends the lump-sum remittance request creation process.

After this process is performed, the terminal 20 displays the bulk remittance request information corresponding to the bulk remittance request on a remittance request list screen or the like displayed on the display unit 24. Then, it becomes possible to execute a bulk settlement based on this bulk remittance request.

In addition, if it is determined in S510 that the creation of a lump-sum remittance request has not been requested from the terminal 20 (S510: NO), the control unit 11 of the server 10 may, by way of example and not limitation, perform other lump-sum processing, such as the lump-sum settlement described above or the request offset described above, based on a request from the terminal 20.

There is also a risk that a malicious user may create a false remittance request as described above and then create a bulk remittance request that includes that false remittance request.
Thus, creation of a bulk remittance request may or may not require the other party's approval.

<Effects of the Sixth Embodiment>
In this embodiment, the other user is a single user (this is an example, not limiting, of the second user being the first user), and the first process shows a configuration including a process of displaying on the display unit 24 a display of a lump-sum remittance request (this is an example, not limiting, of the sixth display) based on remittance request information (this is an example, not limiting, of a third information relating to a remittance request from the first user to the user of the terminal, or a remittance request from the user of the terminal to the other user) in which the remittance request amounts of the first remittance request information and the second remittance request information are added together.
As an example of the effect of the embodiment obtained by such a configuration, when the other user is a single user, the sixth display based on the third information summarizing the information on a plurality of remittance requests can be displayed to inform the user of the terminal of the third information. Also, by way of example and not of limitation, it becomes possible to perform comprehensive settlement based on the third information summarizing the information on a plurality of remittance requests, thereby improving the convenience for the user.

Seventh Example
The seventh embodiment is an embodiment relating to "creation of a special lump sum settlement/special lump sum remittance request" from the above-mentioned lump sum processing.
The contents described in the seventh embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
Fig. 7-1 is a diagram showing an example of a remittance request list screen displayed on the display unit 24 of the terminal 20A in this embodiment, and shows a screen displaying a list of remittance requests between the user D.D., similar to Fig. 6-1. Here, similar to Fig. 6-1, the first to fourth remittance requests are shown in the selected state.

When the first through fourth selected remittance requests are settled in a lump sum, the lump sum settlement will be "Payment 1,100 yen," and "1,100 yen" will be paid from user A.A to user D.D. However, in this example, user A.A's current electronic money account balance is "500 yen," so there will be a shortfall of "600 yen" in the payment amount.

In this case, in this embodiment, the control unit 11 of the server 10 performs a lump-sum settlement by transferring the entire amount of the current balance of the electronic money account of the user A.A to the user D.D.
In addition, the control unit 11 of the server 10 creates a new remittance request with the amount of the shortfall in the lump-sum payment set as the remittance request amount.
In other words, in this embodiment, unlike the sixth embodiment, the proposer's user makes payments up to the amount that can be paid with his/her balance, and then creates a new remittance request with the amount that cannot be paid as the remittance request amount.

For convenience, a lump sum settlement in which payments are made to the extent possible based on multiple remittance requests will be referred to as a "special lump sum settlement," and a new lump sum remittance request created after a special lump sum settlement is performed will be referred to as a "special lump sum remittance request."

Specifically, the settlement details confirmation area ACR8 at the bottom of the screen displays "500 yen" as the user's current electronic money account balance, and "0 yen" as the user's electronic money account balance if settlement is made. When the Proposal button is tapped in this state, a special lump-sum settlement is executed in which the entire amount of user A.A's current electronic money account balance, "500 yen", is transferred from user A.A to user D.D and paid. After that, a special lump-sum remittance request is created based on the shortfall in payment, "600 yen". As a result, a screen like the one shown in Figure 7-2 is displayed.

In FIG. 7-2, a special lump sum remittance request with a payment amount of "600 yen" is displayed as a special lump sum remittance request.
In this example display screen, the special bulk remittance request is displayed with the four remittance requests selected in Fig. 7-1, i.e., the remittance requests (combined remittance requests) used to create the special bulk remittance request, hanging down. In addition, to make it easier for the user to understand, these remittance requests are displayed in a different manner (grayed out in this example) from normal remittance requests.

Unlike this example display screen, the remittance request used to create the special lump remittance request may not be displayed.
In addition, when a special lump sum remittance request is tapped, the remittance request used to create the special lump sum remittance request may be displayed.

<Processing>
7-3 and 7-4 are diagrams showing an example of the fourth settlement process executed by the control unit 21 of the server 10 in this embodiment.

After S1515, the control unit 11 of the server 10 determines whether the electronic money account balance of any user will become negative (S1520), and if it is determined that the balance will become negative (S1520: YES), determines whether the electronic money account balance will become negative for the proposer user (S1570).

If it is determined that the user whose electronic money account balance is negative is the proposer (S1570: YES), the control unit 11 of the server 10 sends lump-sum settlement type confirmation information, including the lump-sum settlement amount, to terminal 20A via communication I/F 14 to confirm the type of lump-sum settlement to be performed (normal lump-sum settlement/special lump-sum settlement) (S1571).
In this case, the aforementioned insufficient balance information may or may not be included in the lump-sum settlement type confirmation information and sent.

Then, the control unit 11 of the server 10 determines whether or not a special lump-sum settlement has been requested to be executed based on receipt of settlement execution request information from the terminal 20A, which includes information on the type of lump-sum settlement to be executed (S1574). If it is determined that the execution of the normal lump-sum settlement described above has been requested, rather than the special lump-sum settlement (S1574: NO), the control unit 11 of the server 10 proceeds to S1555 in FIG. 2-5, by way of example and not limitation.

On the other hand, if it is determined that a request for special lump-sum settlement has been made (S1574: YES), the control unit 11 of the server 10 determines whether or not approval of the other user is required (S1575).
If it is determined that approval from the other user is required (S1575: YES), the control unit 11 of the server 10 sends special lump-sum settlement approval confirmation information including special lump-sum settlement amount information, which is information on the settlement amount based on the special lump-sum settlement (hereinafter referred to as the ``special lump-sum settlement amount''), to the terminal 20B via the communication I/F 14 (S1577).
The special lump sum settlement amount may be, by way of example and not limitation, an amount equivalent to the proposer's user's current electronic money account balance.

However, without being limited to this, the special lump-sum settlement amount can be any amount as long as it is greater than "0" and less than or equal to the proposer's user's current electronic money account balance.

Then, the control unit 11 of the server 10 determines whether the special lump-sum settlement has been approved by determining whether special lump-sum settlement approval information indicating that the special lump-sum settlement is approved has been received from the terminal 20B (S1579).

If it is determined that the proposal has been approved (S1579: YES), the control unit 11 of the server 10 executes a special lump-sum settlement (S1581). Specifically, the control unit 11 of the server 10 updates the electronic money account balance of the proposer's user (user A.A in this example) to zero, and adds the special lump-sum settlement amount to the electronic money account balance of the other user (user B.B in this example) to update it.

Thereafter, the control unit 11 of the server 10 creates a special lump-sum remittance request (S1583). Specifically, the control unit 11 of the server 10 creates a special lump-sum remittance request from the other user to the proposer user, in which the remittance request amount is the lump-sum settlement amount minus the special lump-sum settlement amount.
Then, the control unit 11 of the server 10 ends the fourth settlement process.

In addition, as described above, the method of making payments up to the proposer's user's balance that can be used to pay is not limited to the case where multiple remittance requests are selected as described above, but can also be applied when a single remittance request is selected.
In other words, when one received remittance request is selected whose remittance request amount is greater than the current balance in the electronic money account of the proposer's user, the control unit 11 of the server 10 creates a remittance request whose remittance request amount is the amount obtained by subtracting the balance in the electronic money account from the remittance request amount (the shortfall amount).

<Second process by terminal>
In this embodiment, the control unit 21 of the terminal 20 can be configured to execute, in addition to the first process described above, a second process that processes at least one piece of information based on the electronic money account balance of the user of the terminal 20 (the balance of the user of the terminal).

By way of example and not limitation, the second process includes at least the following processes:
- Processing for sending request selection information to the server 10 - Processing for receiving lump-sum settlement confirmation information from the server 10 - Processing for displaying lump-sum settlement confirmation information - Processing for receiving lump-sum settlement result information from the server 10 - Processing for displaying lump-sum settlement result information - Processing for requesting the server 10 to deduct an amount (including offsetting an amount) - Processing for requesting the server 10 to execute a special lump-sum settlement - Processing for requesting the server 10 to create a special lump-sum remittance request

<Effects of the Seventh Example>
This embodiment illustrates a configuration in which a second process (not limiting, an example of a second process for processing at least one piece of information) for lump-sum settlement for at least one piece of remittance request information is executed by the terminal 20 of the user of the proposer of lump-sum settlement based on the electronic money account balance (not limiting, an example of the balance of the user of the terminal) of the user of the proposer of lump-sum settlement among a remittance request to the user of the proposer of lump-sum settlement (not limiting, an example of the balance of the user of the terminal) or multiple remittance request information related to remittance requests by the user of the proposer of lump-sum settlement.
As an example of an effect of an embodiment obtained by such a configuration, at least one of a plurality of pieces of information related to a remittance request to the user of the terminal or a remittance request by the user of the terminal can be processed by the second processing, taking into account the balance of the user of the terminal, thereby improving convenience for the user.

<Seventh Modification>
This is related to the first variant example (3), but in the seventh embodiment, the proposer's terminal 20 or the server 10 may or may not automatically select (including suggest) a remittance request based on the proposer's user's current electronic money account balance.

Specifically, the control unit 21 of the proposer's terminal 20 performs a process of inquiring of the server 10 about the current balance of the electronic money account of the proposer's user. Then, the control unit 21 of the proposer's terminal 20 identifies and selects, from among the remittance requests included in the remittance request list information received from the server 10, a combination of remittance requests that will result in a payment that exceeds the current balance of the electronic money account of the proposer's user, by way of example and not limitation, based on the amount of each remittance request and the type of each remittance request (received remittance request (payment)/sent remittance request (received)).

In this case, as an example and not a limitation, in FIG. 7-1, among the unprocessed requests between user D.D., the requests to be automatically selected as requests to be processed for lump-sum settlement are selected in order from the past remittance requests, and the state up to the remittance request with insufficient balance (the fourth request in this example) may or may not be suggested to the user.

When the control unit 11 of the server 10 selects a remittance request, it may perform similar processing based on the remittance request data stored in the remittance request management data 157.

In this modified example, the second process includes a process of selecting, from among a plurality of remittance request information, remittance request information that can be processed with the proposer's user's electronic money account balance (not limited to this, but an example of the terminal user's balance), and shows a configuration in which the selected information is processed.
As an example of the effect of an embodiment obtained by such a configuration, information that can be processed with the balance of the user of the terminal is selected and processed, so that, by way of example and not limitation, information can be processed within a range that does not cause the balance of the user of the terminal to become negative, thereby further improving user convenience.

Eighth Example
The eighth embodiment is an embodiment in which, when a user of a terminal 20 remits money to a partner user or makes a remittance request to a partner user, an outstanding request is displayed.
The contents described in the eighth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
8-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a remittance screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which shows the current location in the payment application, the word "Remittance" is displayed, which indicates that the current location is the remittance function of the payment application.

Below the current location display area CLR1, the icon image of the payment application of the user selected as the recipient and the user name (user E.E. in this example) are displayed. Also below that, the amount to be remitted to the user selected as the recipient ("500 yen" in this example) and a function button for increasing the remittance amount by a certain amount are displayed.

Further below that is an unprocessed request confirmation area URR1, which is configured to allow confirmation of unprocessed requests between the user selected as the remittance recipient (user E.E. in this example) and the user making the remittance (user A.A. in this example).

At the top of the unprocessed request confirmation area URR1, the words "Unsettled request with E.E." are displayed, indicating that an unprocessed request between user E.E. is being displayed.

Also displayed below that is the lump sum payment amount (in this example, "1,500 yen") and a mark (in this example, a "payment mark") if all selected items are paid in a lump sum.
It should be noted that the display column for assuming that all selected items will be settled at once does not need to be provided.

Below that is a list of remittance requests to user E.E. In this example, unprocessed requests to user E.E. are listed in chronological order from the top to the bottom.

Also, under the unprocessed request confirmation area URR1, a remittance button labeled "Remit" is displayed for executing remittance (remittance processing).
When the remittance button is tapped, the remittance process (remittance from user A.A to user E.E) is executed by the server 10.

In addition, the remittance button may be displayed, for example and not by way of limitation, below the display area of the function button for increasing the remittance amount by a certain amount, in an area above the pending request confirmation area URR1, etc.

In this way, this embodiment is configured to display pending requests along with remittance information, allowing the user to check pending requests when making a remittance.

8-2 is a diagram showing another example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a remittance request screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which indicates the current location in the payment application, the words "Remittance Request" are displayed, which indicates that the current location is the remittance request function of the payment application.

Below the current location display area CLR1, the icon image and user name (user E.E. in this example) of the payment application of the user selected as the recipient of the remittance request are displayed. Also displayed below that is the remittance request amount (in this example, "500 yen") for the user selected as the recipient of the remittance request, and a function button for increasing the remittance request amount by a certain amount.

When the user selected as the recipient of the remittance request accepts the remittance request, the amount of the remittance request is transferred from the electronic money account of the user selected as the recipient of the remittance request to the electronic money account of the user who made (sent) the remittance request.

Also, just like in Fig. 8-1, an unprocessed request confirmation area URR1 is displayed below that, and a remittance request button labeled "Make a remittance request" is displayed below that for executing the remittance request transmission (remittance request transmission process).
When the remittance request button is tapped, a remittance request transmission process (transmission of remittance request information from user A.A to user E.E.) is executed by the server 10.

In addition, the remittance request button may be displayed, for example and not by way of limitation, below the display area of the function button for increasing the remittance request amount by a certain amount, in an area above the pending request confirmation area URR1, etc.

In this way, in this embodiment, by displaying pending requests along with the information for sending a remittance request, the user is able to check the pending requests when making a remittance request.

<Processing>
Fig. 8-3 is a flowchart showing an example of the flow of the process executed by each device in this embodiment. Here, as an example, the process of displaying pending requests when a user remits money, as described in Fig. 8-1, is described.

First, the control unit 21 of the terminal 20A judges whether or not an input for displaying a remittance screen has been made to the input unit (A105).
If it is determined that input has been made (A105: YES), the control unit 21 of the terminal 20A performs processing of A110 and, based on the receipt of the remittance request list information from the server 10 via the communication I/F 22, causes the display unit 24 to display a remittance screen (a screen for remittances) including the remittance request list information (A125).

Thereafter, the control unit 21 of the terminal 20A determines whether or not an input for executing a remittance (for example, but not limited to, the operation of the remittance button) has been made (A630).
If it is determined that no input has been made to execute the remittance (A630: NO), the control unit 21 of the terminal 20A ends the process.

On the other hand, if it is determined that an input has been made to execute a remittance (A630: YES), the control unit 21 of the terminal 20A transmits remittance request information for requesting a remittance to the server 10 via the communication I/F 22 (A640).

After S120, the control unit 11 of the server 10 determines whether or not remittance request information has been received from the terminal 20A via the communication I/F 14 (S640).
If it is determined that the remittance request information has not been received (S640: NO), the control unit 11 of the server 10 ends the process.

On the other hand, if it is determined that the remittance request information has been received (S640: YES), the control unit 11 of the server 10 executes the remittance process (S650). Specifically, as a non-limiting example, the control unit 11 transmits remittance confirmation information for confirming the remittance contents to the terminal 20A via the communication I/F 14, and executes the remittance from user A.A to user B.B based on the reception of remittance execution request information from the terminal 20A via the communication I/F 14.
In this case, the control unit 21 of the terminal 20A executes the processes A650 to A670, for example and not for limitation.

Thereafter, the control unit 11 of the server 10 judges whether the remittance result is "OK" or not (S670). If it is judged to be "OK" (S670: YES), the control unit 11 of the server 10 transmits the remittance result information to each of the terminals 20A and 20B via the communication I/F 14 (S690).
Then, the control unit 11 of the server 10 ends the process.

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

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

As for the process of displaying pending requests when a user makes a remittance request, as described in Figure 8-2, this can be configured in a similar manner by replacing "remittance" in the process of Figure 8-3 with "send remittance request," so illustration and explanation are omitted.
Specifically, in the processing of terminal 20A, A105 determines whether or not an input has been made to display a remittance request sending screen, A125 displays the remittance request sending screen including remittance request list information, A630 determines whether or not to execute the remittance request sending, A640 sends remittance request sending request information, A650 displays remittance request sending confirmation information, A660 determines whether or not a request to execute the remittance request sending has been made, A670 sends remittance request sending execution request information, and A690 displays remittance request sending result information.
Furthermore, in the processing of the terminal 20B, information on the result of transmission of the remittance request is displayed at B690.
In addition, in the processing of the server 10, it is determined in S640 whether or not remittance request transmission request information has been received, the remittance request transmission processing is executed in S650, it is determined in S670 whether or not the remittance request transmission result is OK, and remittance request transmission result information is transmitted in S690.

<Viewing pending requests>
The pending requests displayed on the display unit 24 of the terminal 20 may be, by way of example and not limitation, either or both of the following:
- Pending requests corresponding to the user to whom you are sending money (remittance destination user) or the user to whom you are sending a remittance request (remittance request destination user) - Pending requests corresponding to a user other than the user to whom you are sending money (remittance destination user) or the user to whom you are sending a remittance request (remittance request destination user)

It is possible to display the pending request corresponding to the other user. As an example and not a limitation, when user A.A sends money to user E.E as a remittance destination user as shown in FIG. 8-1, or when user A.A sends a remittance request to user E.E as a remittance request destination user as shown in FIG. 8-2, the pending request corresponding to user E.E can be displayed.

However, some users may wish to view pending requests corresponding to different users than the other user.
Thus, by way of example and not limitation, in addition to the unprocessed requests corresponding to user E.E in FIG. 8-1 and FIG. 8-2, by way of example and not limitation, unprocessed requests corresponding to user B.B and user C.C may also be displayed.
In this case, it is also possible to display the unprocessed requests corresponding to user B.B and user C.C, instead of displaying the unprocessed requests corresponding to user E.E., for example and not by way of limitation.

That is, the following three patterns are possible for displaying unprocessed requests, but are not limiting examples.
(Pattern 1) An unprocessed request corresponding to the other user. (Pattern 2) An unprocessed request corresponding to the other user + an unprocessed request corresponding to a user other than the other user. (Pattern 3) An unprocessed request corresponding to a user other than the other user.

Furthermore, in any of the above patterns, for each user, all of the unprocessed requests corresponding to that user may be displayed, or only a portion of the unprocessed requests corresponding to that user may be displayed.
In other words, the user (the other user/a user different from the other user) displaying the unprocessed requests and the range (all/a part) of the unprocessed requests to be displayed can be combined arbitrarily. As a non-limiting example (Pattern 2), all unprocessed requests corresponding to the other user may be displayed, but only a part of the unprocessed requests corresponding to a user different from the other user may be displayed.

In addition, when displaying some of the unprocessed requests, it is possible to determine which unprocessed requests to display based on various information (conditions).
In this case, it is possible to combine the contents of the sixteenth embodiment described later. As will also be described in the sixteenth embodiment, the various types of information include, but are not limited to, the following information by way of example.
- Date and time when the remittance request was sent/received - The amount of the remittance request - The payment deadline for the remittance request - Remittance requests in which the amount or reason for the remittance request is involved other than the user who made the remittance request and the user to whom the remittance request was made Note that this information is merely an example and is not limited to this.
Moreover, a combination of a plurality of pieces of information among these pieces of information can be applied.

Since a user may have forgotten about pending requests whose dates or times are older than a certain number, it may be possible to decide to display pending requests even if they correspond to a different user than the target user.
Pending requests with a large remittance request amount may be of high importance, so it may be decided to display pending requests even if they correspond to a different user than the target user.
Remittance requests where other users than the requesting user and the requested user are involved in the remittance request amount or reason may also be of high importance, so it may be decided to display pending requests even if they correspond to users other than the other user.
Pending requests that are due for payment within a certain period of time may require urgent processing, so it may be decided to display pending requests even if they correspond to a different user than the target user.

As will be described in the 16th embodiment, the unprocessed requests can also be sorted and displayed in ascending or descending order based on the various information (conditions) described above. As an example, the more important an unprocessed request is, the higher it can be displayed.

In addition to these, the pending requests displayed on the display unit 24 of the terminal 20 can be hidden based on, for example and not by way of limitation, an input by the user of the terminal 20 on an input unit.
In this case, by way of example and not limitation, pending requests corresponding to some users may be hidden, or pending requests corresponding to all users may be hidden.

Also, it is considered that some users may find it annoying to see pending requests displayed.
Therefore, it may be possible to set whether to display or not display the unprocessed requests on a setting screen (not shown) or the like.

Specifically, on the application settings screen, as setting information related to the display of unprocessed requests, for example and without limitation, a slide button or check box that can switch between displaying and hiding unprocessed requests is displayed. Then, based on the operation of this slide button or check box, the terminal 20 or server 10 can be made to set the display/hide state.

In this case, it may be possible to set whether to display or hide unprocessed requests collectively for all users, or it may be possible to set whether to display or hide unprocessed requests individually for each user.
Also, it may be possible to set whether to display all unprocessed requests or to display only some of the unprocessed requests.

These contents also apply to the following examples.

<Effects of the Eighth Example>
This embodiment illustrates a configuration in which the terminal 20 of the proposer's user displays on the display unit 24 a first display based on information for remittance from the proposer's user (not limited to, an example of a user of the terminal) to the other user (not limited to, an example of a first user) (not limited to, an example of first information regarding a remittance from the user of the terminal to the first user) or information for sending a remittance request from the proposer's user to the other user (not limited to, an example of first information regarding a remittance request sent from the user of the terminal to the first user), and a second display based on remittance request information regarding a received remittance request that the proposer's user has received from the other user (not limited to, an example of second information regarding a remittance request sent from a second user to the user of the terminal) or remittance request information regarding a sent remittance request that the proposer's user has sent to the other user (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to the second user).
As an example of an effect of the embodiment obtained by such a configuration, when the user of the terminal checks the first information, the user can also check the second information.

In addition, this embodiment illustrates a configuration in which the terminal 20 of the proposer's user performs processing for transferring money (not limited to this, but an example of processing related to remittance) via the control unit 21 based on input by the proposer's user to the terminal 20 on which the first display is displayed.
As an example of the effect of the embodiment obtained by such a configuration, remittance to the other user can be easily realized based on an input to the terminal on which the first display is displayed.

<Eighth Modification>
In the above embodiment, settlement (including lump-sum settlement of outstanding requests) can also be performed based on input for information on outstanding requests that are displayed together with information for transferring money to the other user and information for sending a transfer request to the other user.

Specifically, in the example screen of, but not limited to, Figure 8-1, in addition to the remittance button, a settlement button for executing settlement of the selected unprocessed requests (lump settlement if multiple requests are selected) is displayed.
Then, when the settlement button is tapped, the server 10 can execute the settlement process for the selected unprocessed request.

Similarly, in the example screen of, but not limited to, FIG. 8-2, in addition to the remittance request button, a settlement button is displayed for executing settlement of selected unprocessed requests (lump settlement if multiple requests are selected).
Then, when the settlement button is tapped, the server 10 can execute the settlement process for the selected unprocessed request.

The settlement process for unprocessed requests has been described above, so we will not explain it again.

Figure 8-4 is a flowchart showing an example of the flow of processing executed by each device in this modified example. As an example, we will explain the process of displaying pending requests when a user makes a remittance shown in Figure 8-3, in which either a remittance or settlement of the pending request is performed.

After A125, the control unit 21 of the terminal 20A determines an execution target based on an input to the input unit (A631).
If it is determined that the target of execution is settlement of unprocessed requests (lump sum settlement if multiple requests are selected) (A631: Settlement of unprocessed requests), the control unit 21 of terminal 20A sets request selection information including unprocessed request selection information indicating the selected unprocessed requests (A632).

On the other hand, if it is determined that the execution target is a money transfer (A631: money transfer), the control unit 21 of the terminal 20A sets request selection information including money transfer information related to the money transfer to be executed (A133).

After A632 or A133, the control unit 21 of the terminal 20A transmits the set request selection information to the server 10 via the communication I/F 22 (A140).
Then, the control unit 21 of the terminal 20A transfers the processing to A150.

After S120, if it is determined that request selection information has been received from terminal 20A (S140: YES), the control unit 11 of server 10 determines the processing target based on the received request selection information (S641).

If it is determined that the processing target is "settlement of unprocessed requests", the control unit 11 of the server 10 sets the selected unprocessed requests as the targets for settlement (if multiple requests are selected, they are all set for lump-sum settlement) (S642).
On the other hand, if it is determined that the processing object is "remittance", the control unit 11 of the server 10 sets remittance as the settlement object (S143).

After S642 or S143, the control unit 11 of the server 10 executes the settlement process of S150.

When applying the first settlement process described in FIG. 1-19 by way of example and not by way of limitation,
When S642 is set and there are multiple unprocessed requests to be processed, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target is "YES". As a result, the processing from S1515 onwards is executed with these multiple unprocessed requests as the lump-sum settlement target. Also, when S642 is set and there is only one unprocessed request to be processed, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target is "NO". As a result, the processing from S1570 onwards is executed with this one unprocessed request as the lump-sum settlement target.
On the other hand, if the setting of S143 has been made, the result of the determination in S1510 as to whether the settlement object is a lump-sum settlement object is “NO.” As a result, the processing from S1570 onward is executed with the remittance as the settlement object.

As for the process of displaying pending requests when a user makes a remittance request and either sending the remittance request or settling the pending request, this can be configured in a similar manner by replacing "remittance" in the process of Figure 8-4 with "send remittance request," so illustrations and explanations are omitted.
Specifically, in the processing of terminal 20A, A105 determines whether an input has been made to display a remittance request sending screen, A125 displays the remittance request sending screen including remittance request list information, A631 determines whether the execution target is settling an unprocessed request or sending a remittance request, and A133 sets request selection information including remittance request sending information.
In the processing of the server 10, it is determined in S641 whether the processing target is the settlement of an unprocessed request or a remittance request transmission, and in S143 the remittance request transmission is set as the processing target for settlement.

In this modified example, the terminal 20 of the proposer's user displays on the display unit 24 a first display based on information for remittance from the proposer's user (an example of a user of the terminal, not limited to the above) to the other user (an example of a first user, not limited to the above) (an example of first information regarding a remittance from the user of the terminal to the first user) or information for sending a remittance request from the proposer's user to the other user (an example of first information regarding a remittance request sent from the user of the terminal to the first user, not limited to the above), and a second display based on remittance request information regarding a received remittance request that the proposer's user has received from the other user (an example of second information regarding a remittance request sent from a second user to the user of the terminal) or remittance request information regarding a sent remittance request that the proposer's user has sent to the other user (an example of second information regarding a remittance request sent from the user of the terminal to the second user, not limited to the above).
The terminal 20 of the proposer's user is configured to perform, through the control unit 21, a process for transferring money, a process for receiving the transferred amount, or a process for sending/receiving a remittance request (remittance reminder) based on an input by the proposer's user to the terminal 20 on which the first display or the second display is displayed (not limited to this, an example of a first process related to transferring money, receiving a remittance, or requesting a remittance).
As an example of the effect of an embodiment obtained by such a configuration, it is possible to easily transfer money to a partner user, receive money from a partner user, and send/receive a transfer request to a partner user based on input to a terminal on which the first or second display is displayed.

Next, as an example related to the eighth example, we will explain an example in which, when a user of terminal 20 transfers money to a different user or sends a transfer request to a different user, an unprocessed request selected from the displayed unprocessed requests is also processed.

In the following embodiments, the following five patterns will be described.
(A) A pattern of remittance + processing a received remittance request (B) A pattern of remittance + processing a sent remittance request (C) A pattern of sending a remittance request + processing a received remittance request (D) A pattern of sending a remittance request + processing a sent remittance request (E) A pattern of processing a remittance request + received remittance request + sent remittance request. Each pattern will be explained with separate examples.

As also shown in the eighth variant example, the processing (first processing, etc.) executed by the terminal 20 via the control unit 21 includes, by way of example and not limitation, processing for making a remittance (a non-limiting example of a processing related to a remittance), processing for receiving (accepting) a remittance (a non-limiting example of a processing related to receiving a remittance), processing for sending/receiving a remittance request (a non-limiting example of a processing related to a remittance request), etc.
In the following, a server-client system is exemplified, and it is assumed that remittances and transmission of remittance requests are carried out via the server 10.

In the following, as described above, a case will be exemplified in which the other user is one user, that is, the second user is the first user (or the first user is the second user).
As mentioned above, the method described below can also be applied when the other users are multiple different users, that is, when the first user is a user different from the second user (and the second user is a user different from the first user).

Ninth Example
The ninth embodiment is an embodiment relating to processing of the above pattern (A).
The contents described in the ninth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, in addition to including "received remittance requests" among unprocessed requests as targets for lump-sum settlement, "remittances" are also included in the lump-sum settlement and lump-sum settlement is performed.

FIG. 9A is a diagram showing an example of a table for explaining a processing method corresponding to each pattern.
The vertical column of the table shows the target of a new process that is about to be executed (new process target), and the horizontal column shows the type of unprocessed request. The intersection of the vertical column and the horizontal column shows an example of a process that is realized by combining the new process target and an unprocessed request of that type.

In this embodiment, the process of the pattern (A) remittance + received remittance request will be described. In this pattern, the process of (A1) remittance [remittance + remittance] can be performed.
That is, when a new remittance is made to the other user, a remittance is also made to the other user based on a remittance request already received from the other user. More specifically, the sum of the amount to be remitted to the other user by the new remittance and the remittance request amount included in the received remittance request information (the amount requested to be remitted by the other user) is remitted to the other user.

<Display screen>
An example of a display screen when the above process (A1) is performed will be described.
9-2 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a remittance screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which shows the current location in the payment application, the word "Remittance" is displayed, which indicates that the current location is the remittance function of the payment application.

Below the current location display area CLR1, the icon image of the payment application of the user selected as the recipient and the user name (user E.E. in this example) are displayed. Also below that, the amount to be remitted to the user selected as the recipient ("500 yen" in this example) and a function button for increasing the remittance amount by a certain amount are displayed.

Further below that is an unprocessed request confirmation area URR1, which is configured to allow confirmation of unprocessed requests between the user selected as the recipient of the remittance (user E.E. in this example) and the user making the remittance (user A.A. in this example).

At the top of the unprocessed request confirmation area URR1, the words "Unsettled request with E.E." are displayed, indicating that an unprocessed request between user E.E. and the user is being displayed.
Also displayed below that is the lump sum payment amount (in this example, "1,500 yen") and a mark (in this example, a "payment mark") in the case where all selected items are paid in a lump sum.

Below that, remittance requests to user E.E are displayed in a list. In this example, unprocessed requests to user E.E are displayed in chronological order from the oldest at the top. The display format of each unprocessed request can be configured in the same way as in FIG. 1-11, but is not limited to this, and will not be described again.

Below the unprocessed request confirmation area URR1, a remittance all-selection lump-sum settlement button labeled "Settle all and send" is displayed, allowing the user to execute the remittance process and settle all selected requests at once. Below that is a remittance lump-sum settlement button BT11 labeled "Settle and send one item" is displayed, allowing the user to execute the remittance process and settle some of the unprocessed requests selected in the unprocessed request confirmation area URR1 at once. Below that is a remittance button labeled "Just transfer" is displayed, allowing the user to execute only the remittance process.

As a non-limiting example, when the check box for the first received remittance request (payment of 2,500 yen) is checked "ON" and selected in the pending request confirmation area URR1 and the lump-sum remittance settlement button BT11 is tapped, terminal 20A requests server 10 to execute the remittance and lump-sum settlement of the selected pending requests. Then, server 10 sends settlement result information regarding the execution result to terminal 20E of user E, who is the other party.

FIG. 9C is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E when the lump-sum remittance settlement button BT11 is tapped.
In this example, the notification information display area NTR4 of the notification screen displays two sets of settlement result information, one for remittance and the other for lump sum settlement.
Specifically, by way of example and not limitation, settlement result information corresponding to receipt of the remittance amount "500 yen" remitted by user A.A to user E.E, and receipt of the remittance amount "2,500 yen" remitted based on the remittance request amount "2,500 yen" received by user A.A from user E.E in accordance with the first remittance request selected in FIG. 9-2, are displayed.

As shown in FIG. 9-4, the two pieces of settlement result information may be combined and displayed as one piece of settlement result information in the notification information display area NTR4 of the notification screen, but this is not essential.
As a non-limiting example, FIG. 9-4 displays, as settlement result information, information indicating that user E.E will receive "3,000 yen", which is the sum of the remittance amount "500 yen" received from user A.A and the remittance amount "2,500 yen" received from the remittance request amount "2,500 yen" to user A.A.

In FIG. 9-2, the pending request confirmation area URR1 displays pending requests between the user selected as the remittance recipient and the user making the remittance, but this is not limited to this.

Figure 9-5 shows an example of a display screen that displays all pending requests for a user making a remittance. Figure 9-5 is another example of the remittance screen in Figure 9-2.

In FIG. 9-5, the unprocessed request confirmation area URR2 displays all unprocessed requests of the user making the remittance in chronological order, starting from the oldest at the top. In addition, below the unprocessed request confirmation area URR2, a lump-sum remittance settlement button BT11 and a remittance button are displayed. As a non-limiting example, in the unprocessed request confirmation area URR2, the fourth remittance request received from user E. E (payment 2,500 yen) is checked "ON" and selected, and when the lump-sum remittance settlement button BT11 is tapped, the display screen of FIG. 9-3 is displayed on the display unit 24 of terminal 20E.

<Processing>
FIG. 9-6 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
This flowchart is a rewrite of the flowchart in FIG. 1-18 for processing in which the new processing target is "remittance."

In the processing of the pattern (A) remittance + received remittance request in this embodiment, since the remittance is made unilaterally to the other user, approval of the other user is not required when making a lump-sum settlement. Therefore, the processing that does not require approval of the other user is illustrated and described here.
However, the present invention is not limited to this, and approval of the other user may be required.

After A125, the control unit 21 of the terminal 20A determines whether an unprocessed request has been selected from the remittance request list information (A131).

If an unprocessed request is selected, that is, if it is determined that a request is made to execute a remittance + unprocessed request processing (A131: YES), the control unit 21 of terminal 20A sets request selection information including remittance information related to the remittance to be executed and unprocessed request selection information indicating the selected unprocessed request (A132).

On the other hand, if no unprocessed request is selected from the remittance request list information, that is, if it is determined that only the remittance is to be executed (A131: NO), the control unit 21 of terminal 20A sets request selection information including remittance information regarding the remittance to be executed (A133).

It should be noted that this process will be described on the assumption that remittance is being carried out.
In reality, there may be cases where a user chooses to process only the pending requests without transferring funds. In this case, the process is the same as the process for lump-sum settlement of the pending requests described above, so illustrations and repeated explanations are omitted.

After A132 or A133, the control unit 21 of the terminal 20A transmits the set request selection information to the server 10 via the communication I/F 22 (A140).
Then, the control unit 21 of the terminal 20A transfers the processing to A150.

If it is determined in S140 that request selection information has been received from terminal 20A (S140: YES), the control unit 11 of the server 10 determines whether or not to process the remittance + unprocessed request based on the information contained in the received request selection information (S141). If it is determined to process (S141: YES), the control unit 11 of the server 10 sets the remittance + settlement of the selected unprocessed request (lump settlement if multiple requests are selected) as the target for lump-sum settlement (S142).

On the other hand, if it is determined that the processing is not a combination of remittance and unprocessed request, i.e., that only the remittance is to be executed (S141: NO), the control unit 11 of the server 10 sets the remittance as the settlement target (S143).

After S142 or S143, the control unit 11 of the server 10 executes the settlement process of S150.

When applying the first settlement process described in FIG. 1-19 by way of example and not by way of limitation,
When the setting of S142 is made, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target is "YES." As a result, the processing from S1515 onwards is executed with the settlement of the remittance plus the selected unprocessed request as the lump-sum settlement target.
On the other hand, if the setting of S143 has been made, the result of the determination in S1510 as to whether the settlement object is a lump-sum settlement object is “NO.” As a result, the processing from S1570 onward is executed with the remittance as the settlement object.

<Effects of the ninth embodiment>
In this embodiment, the terminal 20 of the proposer's user displays on the display unit 24 a first display based on remittance information (not limited to, an example of first information regarding a remittance from the user of the terminal to the first user) from the proposer's user (not limited to, an example of a user of the terminal) to the other user (not limited to, an example of a first user) or remittance request information regarding a remittance request to be sent from the proposer's user to the other user (not limited to, an example of first information regarding a remittance request sent from the user of the terminal to the first user), and a second display based on remittance request information regarding a received remittance request that the proposer's user has received from the other user (not limited to, an example of second information regarding a remittance request sent from a second user to the user of the terminal) or remittance request information regarding a sent remittance request that the proposer's user has sent to the other user (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to the second user).
The terminal 20 of the proposer's user is configured to perform, through the control unit 21, a process for transferring money, a process for receiving the transferred amount, or a process for sending/receiving a remittance request (remittance reminder) based on an input by the proposer's user to the terminal 20 on which the first display or the second display is displayed (not limited to this, an example of a first process related to transferring money, receiving a remittance, or requesting a remittance).
As an example of the effect of an embodiment obtained by such a configuration, it is possible to easily realize, based on input to a terminal on which the first display or the second display is displayed, a transfer of money to a partner user, receipt of a transfer of money from a partner user (receiving money), sending a transfer request to a partner user, receiving a transfer request from a partner user, etc.

In addition, this embodiment shows a configuration in which the first process is performed by the control unit 21 based on the input to the first display and the second display, and on the first information and the second information.
As an example of an effect of an embodiment obtained by such a configuration, processing based on the first information and the second information can be easily performed based on input to the first display and the second display.

In addition, in this embodiment, the first information is remittance information from the proposer's user to the other user (not limited to, but an example of information regarding a remittance from a user of the terminal to a first user), the second information is received remittance request information regarding a remittance request already received from the other user (not limited to, but an example of information regarding a remittance request sent from the second user to the user of the terminal), and the first process shows a configuration including a process of remittance to the other user based on the remittance information and the received remittance request information.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to easily realize a money transfer between a first user and a second user based on input to the first display and the second display, based on information regarding a money transfer from the user of the terminal to the first user and information regarding a money transfer request sent from the second user to the user of the terminal.

In this case, the other user is one user (this is an example, not limiting, of the second user being the first user), and the first process can include a process of transferring to the other user an amount that is the sum of the amount to be transferred from the proposer user to the other user and the remittance request amount included in the remittance request information already received from the other user (this is an example, not limiting, of an amount based on the first information and the second information).
As an example of the effect of the embodiment obtained by such a configuration, it is possible to transfer an amount based on the first information and the second information to the same single user.

<Ninth Modification>
In the above embodiment, as an example of an amount based on the first information and the second information, a case was given in which the sum of the amount to be remitted from the proposer user to the other user and the remittance request amount included in the remittance request information already received from the other user was remitted to the other user, but the present invention is not limited to this.

It is envisioned that the proposer user may borrow money from the other user, in which case, by way of example and not limitation, the proposer user may transfer money to the other user with interest.
Specifically, as an example and not as a limitation, a process can be performed on the terminal 20 of the proposer's user or on the server 10 side to automatically add a preset percentage of interest (for example and not as a limitation, 5% interest) to the total amount of the above amounts, and the amount with the interest added can be used as the remittance amount to be remitted from the proposer's user to the other user.

This method also applies when the other user transfers an amount based on the first information and the second information.

Tenth Example
The tenth embodiment is an embodiment relating to the processing of the above-mentioned pattern (B).
The contents described in the tenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, in addition to including "sent remittance requests" among unprocessed requests as targets for lump-sum settlement, "remittances" are also included in the lump-sum settlement and lump-sum settlement is performed.

Please refer again to the table in FIG. 9-6.
In this embodiment, the process for pattern (B) remittance + sent remittance request is performed.
In this pattern, either of the following processes can be performed: (B1) remittance + remittance reminder, or (B2) [remittance + receipt] (amount can be deducted).

In the process of (B1), when a new remittance is made to the other user, a remittance reminder is also sent to the other user based on the remittance request already sent to the other user.
It should be noted that a new remittance request may or may not be sent in place of the remittance reminder.

In the process of (B2), when a new remittance is made to the other user, the other user remits money based on a remittance request already sent to the other user, and the remittance is received.
In this case, since the payment and receipt of money are in an opposing relationship, the difference between the remittance request amount can be sent/received.
In addition, if the remittance request amounts are the same, the amounts can be offset.

Specifically, the proposer's user transfers to the other user an amount obtained by subtracting the remittance request amount included in the transmitted remittance request information from the amount to be transferred from the proposer's user to the other user.
Conversely, the amount obtained by subtracting the amount to be remitted from the proposer's user to the other user from the remittance request amount included in the transmitted remittance request information is received from the other user.

<Display screen>
First, an example of a display screen when the above process (B1) is performed will be described.
10-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a remittance screen of a payment application displayed on the display unit 24 of the terminal 20A of user A. As the details of the screen configuration can be configured similarly to that of FIG. 9-2, by way of example and not limitation, a detailed description will be omitted.

As a non-limiting example, when the check box for the second sent remittance request (received 1,000 yen) is checked "ON" and selected in the pending request confirmation area URR1, and the lump-sum remittance settlement button BT11 is tapped, terminal 20A requests server 10 to execute the remittance and lump-sum settlement of the selected pending requests. Then, server 10 sends settlement result information regarding the execution result to terminal 20E of user E, who is the other party.

FIG. 10B is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E when the lump-sum remittance settlement button BT11 is tapped.
In this example, the notification information display area NTR4 of the notification screen displays two sets of settlement result information, one for remittance and the other for lump sum settlement.
Specifically, by way of example and not limitation, settlement result information corresponding to receipt of the remittance amount "500 yen" remitted by user A.A to user E.E, and a reminder corresponding to the second remittance request selected in FIG. 10-1 (the remittance request for the remittance request amount "1,000 yen" sent by user A.A to user E.E) are displayed.

Next, an example of a display screen when the above process (B2) is performed will be described.
Fig. 10-3 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is a remittance screen of a payment application displayed on the display unit 24 of the terminal 20A of user A. As an example and not a limitation, the screen configuration can be configured similarly to that of Fig. 9-2, and therefore a detailed explanation will be omitted. Note that in Fig. 10-3, as an example and not a limitation, the remittance amount to the user selected as the remittance destination is set to "1,500 yen".

As a non-limiting example, when the check box for the second sent remittance request (received 1,000 yen) is checked "ON" and selected in the pending request confirmation area URR1 and the lump-sum remittance settlement button BT11 is tapped, terminal 20A requests server 10 to transfer the money and settle the lump-sum settlement of the selected pending requests. Then, server 10 sends lump-sum settlement approval confirmation information to terminal 20E of user E, the other party, to confirm whether or not to approve the lump-sum settlement, and the information is displayed on display 24 of terminal 20E.

FIG. 10-4 is a diagram showing an example of a notification screen that is displayed when the lump-sum remittance settlement button BT11 is tapped.
In the notification information display area NTR4, an icon image of user A.A, who is the other party of the "settlement proposal", and the lump-sum settlement amount are displayed as lump-sum settlement approval confirmation information.

The lump-sum settlement approval confirmation information indicates that the lump-sum settlement details are that User E.E will receive "1,500 yen" from the current remittance from User A.A to User E.E, and will pay the remittance request amount of "1,000 yen" based on the receipt of a previous remittance request from User A.A.

Note that, by way of example and not limitation, the contents of the lump-sum settlement can be stored by tapping the "Close" icon in the lump-sum settlement approval confirmation information, and can be expanded from the stored state by tapping the "Summary" icon.

The lump-sum settlement approval confirmation information also indicates that user E.E will receive from user A.A the lump-sum settlement amount of "500 yen", calculated by subtracting the remittance request amount of "1,000 yen" from the amount received from the remittance of "1,500 yen".

At the bottom of the lump-sum settlement approval confirmation information, there is displayed a settlement button BT12 marked "Settle" to approve the settlement with the above details, and a rejection button marked "Reject" to decline and not approve the settlement with the above details.

FIG. 10-5 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT12 is tapped.
Below the current location display area CLR1, a notification NT2 including the text "500 yen has been remitted" is displayed together with a bell mark as a notification that the lump-sum settlement of the remittance request from user E.E's terminal 20E has been approved via server 10 and that the remittance has been completed as a result.

Further, in the notification information display area NTR2 of the notification screen, information corresponding to the above notification NT2 is displayed.
In this example, the notification information display area NTR2 of the notification screen displays the result of the lump-sum settlement between user E.E. and the user E.E. (in this example, the payment of the remittance amount of "500 yen" sent by user A.A. to user E.E.) as the content of the lump-sum settlement.

In FIG. 10-3, when the lump-sum remittance settlement button BT11 is tapped, a confirmation screen is displayed on the display unit 24 of the terminal 20A to inform the user A.A that the lump-sum settlement amount of "500 yen" will be paid if the settlement is to be carried out, and the remittance and the lump-sum settlement of the selected unprocessed requests may or may not be requested based on the approval of the user A.A.

<Processing>
In this embodiment, the processes executed by each device can be realized in a similar manner to the processes in FIG.
However, when executing the process of (B2) [Remit + Receive] (amount deduction possible), the process of remittance by the other user is included. Therefore, as described above, approval of the other user may be required for lump-sum settlement.

FIG. 10-6 is a flowchart showing an example of the flow of the process executed by each device in this case.
This flowchart is an example, not a limitation, of the process of FIG. 1-21 applied to the process of FIG. 9-6.
The difference from the process in FIG. 9-6 is that steps B150 to B190 are added as processes executed by the control unit 21 of the terminal 20B.

<Effects of the Tenth Example>
In this embodiment, the first information is remittance information from the proposer user to the other user (not limited to this, but an example of information regarding a remittance from a terminal user to a first user), and the second information is sent remittance request information regarding a remittance request that has already been sent from the proposer user to the other user (not limited to this, but an example of information regarding a remittance request sent from a terminal user to a second user).
As an example of an effect of an embodiment obtained by such a configuration, a remittance from a user of a terminal to a first user and a remittance request sent from a user of a terminal to a second user can be processed together.

In this case, the first process may include a process of sending money to the other user based on the remittance information, and sending a remittance reminder to the other user based on the sent remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to simultaneously perform remittance to a first user and a request for remittance to a second user.

In addition, in this embodiment, the other user is one user (this is an example, not limiting, of the second user being the first user), and the first process shows a configuration including a process of transferring an amount based on the amount to be transferred from the proposer user to the other user and the remittance request amount included in the transmitted remittance request information (this is an example, not limiting, of an amount based on the first information and the second information) to the other user (this is an example, not limiting, of a process of transferring money to the first user) or a process of receiving money from the first user (this is an example, not limiting, of a process of receiving money from the first user).
As an example of the effect of an embodiment obtained by such a configuration, it is possible to send an amount based on the first information and the second information to the same user, or to receive an amount based on the first information and the second information from the same user.

In this case, the first process is configured to include a process of transferring to the other user an amount obtained by subtracting the remittance request amount (not limiting, an example of the second amount) included in the transmitted remittance request information from the amount to be transferred from the proposer's user to the other user (not limiting, an example of the first amount), or a process of receiving from the other user an amount obtained by subtracting the amount to be transferred from the proposer's user to the other user (first amount) from the remittance request amount (second amount) included in the transmitted remittance request information (not limiting, an example of the process of transferring from the first user).
As an example of the effect of an embodiment obtained by such a configuration, it is possible to send an amount equal to the difference between a first amount and a second amount to the same user, or to receive an amount equal to the difference between the first amount and a second amount from the same user.

Further, in this embodiment, the first process is executed based on an input to the terminal of the other user and based on approval by the other user.
As an example of an effect of the embodiment obtained by such a configuration, the first process can be executed based on the input to the terminal of the first user and based on the approval of the first user, which can prevent the first process from being executed against the will of the first user, for example and not by way of limitation.

<Eleventh Example>
The eleventh embodiment is an embodiment relating to the processing of the above-mentioned (C) pattern.
The contents described in the eleventh embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, in addition to including "received remittance requests" among unprocessed requests in the lump-sum settlement, "sent remittance requests" are also included in the lump-sum settlement and lump-sum settlement is performed.

Please refer again to the table in FIG. 9-6.
In this embodiment, the process for pattern (C) sending a remittance request + receiving a remittance request is performed.
In this pattern, either of the following processes can be performed: (C1) remittance request + remittance, or (C2) [receive + remittance] (amount deduction possible).

In process (C1), when making a new remittance request to the other user, a remittance to the other user is also made based on a remittance request already received from the other user.

In the process of (C2), when making a new remittance request to the other user, the other user remits money based on the new remittance request and receives the money, and also remits money to the other user based on the remittance request already received from the other user.
In this case, the difference between the remittance request amount can be received/remitted.
In addition, if the remittance request amounts are the same, the amounts can be offset.

<Display screen>
First, an example of a display screen when the above process (C1) is performed will be described.
11-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a remittance request screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which indicates the current location in the payment application, the words "Remittance Request" are displayed, which indicates that the current location is the remittance request function of the payment application.

Below the current location display area CLR1, the icon image and user name (user E.E. in this example) of the payment application of the user selected as the recipient of the remittance request are displayed. Also below that are the remittance request amount (in this example, "500 yen") for the user selected as the recipient of the remittance request, and a function button for increasing the remittance request amount by a certain amount. If the user selected as the recipient of the remittance request accepts the remittance request, the remittance request amount is transferred from the electronic money account of the user selected as the recipient of the remittance request to the electronic money account of the user who made (sent) the remittance request.

Further below that, an unprocessed request confirmation area URR1 is displayed. As the unprocessed request confirmation area URR1 can be configured in the same way as in FIG. 9-2, it is not necessary to limit the area, and so a description thereof is omitted.

Below the unprocessed request confirmation area URR1, a remittance request transmission all-selection lump-sum settlement button labeled "Settle all and request remittance" is displayed, which allows the user to execute the remittance request transmission process and select and settle all at once. Below that, a remittance request transmission lump-sum settlement button BT13 labeled "Settle one item and request remittance" is displayed, which allows the user to execute the remittance request transmission process and select and settle some of the unprocessed requests selected in the unprocessed request confirmation area URR1 at once. Below that, a remittance request transmission button labeled "Only make a remittance request" is displayed, which allows the user to execute only the remittance request transmission process.

As a non-limiting example, when the check box for the first received remittance request (payment of 2,500 yen) is checked "ON" and selected in the pending request confirmation area URR1 and the remittance request transmission lump-sum settlement button BT13 is tapped, terminal 20A requests server 10 to transmit a new remittance request and perform lump-sum settlement of the selected pending requests. Then, server 10 transmits remittance request information and settlement result information regarding the execution result of the lump-sum settlement to terminal 20E of user E, the other party.

FIG. 11-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E when the remittance request transmission lump-sum settlement button BT13 is tapped.
In this example, the notification information display area NTR4 of the notification screen displays settlement result information for one remittance request selected in FIG. 11-1 and new remittance request information.

The settlement result information shows that user E.E received the remittance request amount of "2,500 yen" in response to a remittance request to user A.A.

The remittance request information displays, by way of example and not limitation, a remittance request sent by user A.A to user E.E for the remittance request amount of "500 yen", a remittance request remittance button marked "Remit" for approving the remittance request and remitting money based on the remittance request, and a remittance request rejection button marked "Reject" for rejecting the remittance request without approving it.

Next, an example of a display screen when the process (C2) is performed will be described.
FIG. 11-3 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a remittance request screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.A. The details of the screen configuration can be configured similarly to that shown in FIG. 11-1, by way of example and not limitation, and therefore will not be described in detail. Note that in FIG. 11-3, by way of example and not limitation, the remittance request amount to the user selected as the destination of the remittance request (user E.E. in this example) is set to "1,000 yen."

As a non-limiting example, when the check box for the first received remittance request (payment of 2,500 yen) is checked "ON" and selected in the pending request confirmation area URR1 and the remittance request transmission lump-sum settlement button BT13 is tapped, terminal 20A requests server 10 to transmit a new remittance request and perform lump-sum settlement of the selected pending requests. Then, server 10 transmits lump-sum settlement approval confirmation information to terminal 20E of user E, the other party, to confirm whether or not to approve the lump-sum settlement, and the information is displayed on display unit 24 of terminal 20E.

FIG. 11-4 is a diagram showing an example of a notification screen that is displayed when the remittance request transmission/lump settlement button BT13 is tapped.
In the notification information display area NTR4, an icon image of user A.A, who is the other party of the "request settlement and remittance request", and the lump-sum settlement amount are displayed as lump-sum settlement approval confirmation information.

In this example, the lump-sum settlement approval confirmation information displays the lump-sum settlement details as follows: User E.E will receive the remittance request amount of "2,500 yen" based on the remittance request sent to User A.A, and will pay the remittance request amount of "1,000 yen" based on the receipt of this remittance request from User A.A.

The lump-sum settlement approval confirmation information also indicates that user E.E will receive from user A.A the lump-sum settlement amount of "1,500 yen", calculated by subtracting the remittance request amount of "1,000 yen" from the remittance request amount of "2,500 yen" to be received.

At the bottom of the lump-sum settlement approval confirmation information, there is displayed a settlement button BT14 marked "Settle" for approving the settlement with the above details, and a rejection button marked "Reject" for rejecting the settlement with the above details.

FIG. 11-5 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT14 is tapped.
Below the current location display area CLR1, a notification NT3 including the text "1,500 yen has been remitted" along with a bell mark is displayed as a notification that the lump-sum settlement of the remittance request from user E.E's terminal 20E has been approved via server 10 and that the remittance has been completed as a result.

Further, in the notification information display area NTR2 of the notification screen, information corresponding to the above notification NT3 is displayed.
In the specific example, settlement result information is displayed after a lump-sum settlement has been made between user A.A and user E.E. In this example, the settlement result information displays that a lump-sum settlement amount of "1,500 yen" has been transferred from user A.A to user E.E.

The settlement result information also shows that the lump sum settlement includes the payment of "2,500 yen" based on the receipt of the previous remittance request, and the receipt of "1,000 yen" based on the sending of the current remittance request.

In FIG. 11-3, when the remittance request transmission lump-sum settlement button BT13 is tapped, a confirmation screen is displayed on the display unit 24 of the terminal 20A to inform the user A.A that if settlement is to be made, the user A.A will receive "1,000 yen." Based on the user A.A's approval, the remittance request may be sent and the lump-sum settlement of the selected unprocessed requests may be requested, or it may not be necessary to do so.

<Processing>
FIG. 11-6 is a flowchart showing an example of the flow of the process executed by each device in this embodiment.
This flowchart is a rewrite of the flowchart in FIG. 1-18, in which the new process target is "send a remittance request."

Strictly speaking, making a remittance request (sending a remittance request) can be considered to have a different meaning and concept from settlement (including lump-sum settlement). However, for the sake of simplicity, the process (flowchart) will be illustrated and explained assuming that making a remittance request (sending a remittance request) is also a type of settlement.
Alternatively, the flowchart may be configured so that making a remittance request (sending a remittance request) is a separate process from settlement.

In addition, in the processing of pattern (C) in this embodiment, by way of example and not limitation, when processing (C1) is performed, approval of the other user may not be required, and when processing (C2) is performed, approval of the other user may be required.
For simplicity, a process (flowchart) in which approval of the other user is not required will be exemplified here.

First, the control unit 21 of the terminal 20A determines whether or not to send a remittance request based on whether an input for executing the transmission of a remittance request has been made to the input unit (A107).

If it is determined that a remittance request is to be sent (A107: YES), the control unit 21 of the terminal 20A executes the process of A110. After that, based on receiving the remittance request list information from the server 10 via the communication I/F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display a remittance request sending screen (a screen for sending a remittance request) including the received remittance request list information (A127).

Then, the control unit 21 of the terminal 20A determines whether or not an unprocessed request has been selected from the remittance request list information (A135).

If an unprocessed request is selected, that is, if it is determined that a request is made to send a remittance request and to execute the processing of the unprocessed request (A135: YES), the control unit 21 of terminal 20A sets request selection information including remittance request sending information regarding the sending of the remittance request to be executed and unprocessed request selection information indicating the selected unprocessed request (A136).

On the other hand, if no unprocessed request is selected from the remittance request list information, that is, if it is determined that only the remittance request is to be sent (A135: NO), the control unit 21 of terminal 20A sets request selection information that includes remittance request sending information (A137).

In addition, this process will be described on the assumption that a remittance request is to be sent.
In reality, there may be cases where the choice is made to process only the outstanding requests without sending a remittance request, but in this case the processing is similar to the processing for lump-sum settlement of outstanding requests described above, and therefore illustrations and repeated explanations will be omitted.

After A136 or A137, the control unit 21 of the terminal 20A transmits the set request selection information to the server 10 via the communication I/F 22 (A140).
Then, the control unit 21 of the terminal 20A transfers the processing to A150.

If it is determined in S140 that request selection information has been received from terminal 20A (S140: YES), the control unit 11 of the server 10 determines whether or not to process the remittance request transmission + unprocessed request based on the information contained in the received request selection information (S144). If it is determined to process the remittance request transmission + unprocessed request (S145: YES), the control unit 11 of the server 10 sets the remittance request transmission + settlement of the selected unprocessed request (lump settlement if multiple requests are selected) as the target for lump-sum settlement (S146).

On the other hand, if it is determined that the processing is not a remittance request transmission + unprocessed request, i.e., that only the remittance request transmission is to be executed (S145: NO), the control unit 11 of the server 10 sets the remittance request transmission as the settlement target (S147).

After S146 or S147, the control unit 11 of the server 10 executes the settlement process of S150.

When applying the first settlement process described in FIG. 1-19 by way of example and not by way of limitation,
When the setting of S146 is made, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target is "YES." As a result, the processing from S1515 onwards is executed with the remittance request transmission + settlement of the selected unprocessed request as the lump-sum settlement target.
On the other hand, if the setting of S147 has been made, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target or not is “NO.” As a result, the processing from S1570 onwards is executed with the remittance request transmission as the settlement target.

<Effects of the Eleventh Example>
In this embodiment, the first information is remittance request sending information for sending a remittance request from the proposer user to the other user (not limited to, but an example of information regarding a remittance request sent from a terminal user to a first user), and the second information is received remittance request information regarding a remittance request that has already been received from the other user (not limited to, but an example of information regarding a remittance request sent from a second user to a terminal user).
As an example of an effect of an embodiment obtained by such a configuration, a remittance request sent from a user of a terminal to a first user and a remittance request sent from a second user to a user of the terminal can be processed together.

In this case, the first process may include a process of transmitting remittance request information to the other user based on the remittance request transmission information, and transmitting money to the other user based on the received remittance request information.
As an example of an effect of the embodiment obtained by such a configuration, a request for remittance to a first user and a remittance to a second user can be performed simultaneously.

In addition, in this embodiment, the other user is one user (this is not limited to an example in which the second user is the first user), and the first process is configured to include a process of transferring to the other user or receiving from the other user an amount based on the remittance request amount included in the remittance request information to be sent to the other user and the remittance request amount included in the remittance request information already received from the other user.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to remit an amount based on the first information and the second information to the first user, or to receive an amount remitted by the first user.

In this case, the first process may include a process of remitting to the other user an amount obtained by subtracting the remittance request amount (first amount) included in the remittance request information to be sent to the other user from the remittance request amount (second amount) included in the remittance request information already received from the other user, or a process of receiving from the other user an amount obtained by subtracting the remittance request amount (second amount) included in the remittance request information to be sent to the other user from the remittance request amount (first amount) included in the remittance request information already received from the other user.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to send an amount equal to the difference between a first amount and a second amount to the same user, or to receive an amount equal to the difference between the first amount and a second amount from the same user.

Further, in this embodiment, the first process is executed based on an input to the terminal of the other user and based on approval by the other user.
As an example of an effect of the embodiment obtained by such a configuration, the first process can be executed based on the input to the terminal of the first user and based on the approval of the first user, which can prevent the first process from being executed against the will of the first user, for example and not by way of limitation.

<Twelfth Example>
The twelfth embodiment is an embodiment relating to the processing of the above-mentioned pattern (D).
The contents described in the twelfth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, in addition to including "sent remittance requests" among unprocessed requests in the lump-sum settlement, "sent remittance requests" are also included in the lump-sum settlement and lump-sum settlement is performed.

Please refer again to the table in FIG. 9-6.
In this embodiment, the process for pattern (D) sending a remittance request + a sent remittance request is performed.
In this pattern, either of the following processes can be performed: (D1) remittance request + [remittance request or remittance reminder], or (D2) integrated remittance request.

In the process of (D1), when making a new remittance request to the other user, a remittance request to the other user or a remittance reminder to the other user is also made based on a remittance request that has already been sent to the other user.

In this case, the remittance request based on the already sent remittance request may be treated as the same remittance request as the already sent remittance request, and two different remittance requests, the new remittance request and the already sent remittance request, may be sent to the other user, or the remittance request based on the already sent remittance request may be treated as a remittance reminder, and the new remittance request and the remittance reminder may be sent to the other user.

In process (D2), when making a new remittance request to the other user, a combined (integrated) remittance request is sent to the other user, combining this new remittance request with a remittance request based on a remittance request already sent to the other user.

<Display screen>
An example of a display screen when performing each of the above processes (D1) and (D2) will be described.
Fig. 12-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a remittance request screen of a payment application displayed on the display unit 24 of the terminal 20A of user A. As the details of the screen configuration can be configured similarly to Fig. 11-3, by way of example and not limitation, a detailed description will be omitted.

As a non-limiting example, when the check box for the second remittance request (received 1,000 yen) is checked "ON" and selected in the pending request confirmation area URR1, and the remittance request transmission lump-sum settlement button BT13 is tapped, terminal 20A requests server 10 to transmit a new remittance request and to lump-sum settle the selected pending request. Then, server 10 transmits new remittance request information and remittance reminder information based on the past remittance request transmission to terminal 20E of user E, who is the other party, and these are displayed on display 24 of terminal 20E.

FIG. 12-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E when the remittance request transmission lump-sum settlement button BT13 is tapped.
In this example, the notification information display area NTR4 of the notification screen displays reminder information regarding the one remittance request selected in Figure 12-1 (in this example, a reminder regarding a remittance request from user A.A to user E.E for the amount of 1,000 yen) and new remittance request information (in this example, a remittance request from user A.A to user E.E for the amount of 1,500 yen).

It is also possible to consolidate new remittance requests with past remittance requests in a bulk settlement process.
FIG. 12C is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E in this case.
In the notification information display area NTR4, an icon image of user A.A, who is the other party of the "remittance request", and the lump-sum settlement amount are displayed as lump-sum settlement approval confirmation information. In this example, it is displayed that user E.E will pay user A.A the remittance request amount of "1,000 yen" plus the remittance request amount of "1,500 yen", totaling "2,500 yen", as the lump-sum settlement amount.

The lump-sum settlement approval confirmation information also displays the details of the lump-sum settlement, stating that User E.E will pay the remittance request amount of "1,000 yen" based on the previous remittance request sent by User A.A to User E.E, and will pay the remittance request amount of "1,500 yen" based on the current remittance request.

At the bottom of the lump sum settlement approval confirmation information, there is displayed a settlement button BT15 marked "Settle" to approve the settlement with the above details, and a rejection button marked "Reject" to decline and not approve the settlement with the above details.

FIG. 12-4 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT15 is tapped.
Below the current location display area CLR1, a notification NT4 including the words "Remittance has been received" is displayed together with a bell mark as a notification that the lump-sum settlement of the remittance request from the terminal 20E of user E.E has been approved via the server 10, and as a result, remittance has been received from user E.E.

Further, in the notification information display area NTR2 of the notification screen, information corresponding to the above notification NT4 is displayed.
In the specific example, settlement result information is displayed after a lump-sum settlement has been made with user E.E. In this example, the settlement result information displays that user A.A has received a lump-sum settlement amount of "2,500 yen", which is the sum of the remittance request amount of "1,000 yen" to user E.E and the remittance request amount of "1,500 yen".

The settlement result information also displays the details of the lump-sum settlement, stating that User A.A received the remittance request amount of "1,000 yen" based on a previous remittance request sent to User E.E, and received the remittance request amount of "1,500 yen" based on the current remittance request sent.

<Processing>
In this embodiment, the processes executed by each device can be realized in a similar manner to the processes in FIG. 11-6, and therefore illustrations and detailed descriptions thereof will be omitted.

<Effects of the twelfth embodiment>
In this embodiment, the first information is remittance request transmission information for sending a remittance request from the proposer user to the other user (not limited to, but an example of information regarding a remittance request sent from a terminal user to a first user), and the second information is sent remittance request information regarding a remittance request that has already been sent from the proposer user to the other user (not limited to, but an example of information regarding a remittance request sent from a terminal user to a second terminal user).
As an example of an effect of an embodiment obtained by such a configuration, a remittance request from a user of a terminal to a first user and a remittance request from a user of a terminal to a user of a second terminal can be processed together.

In addition, in the above, the other user is one user (this is an example, not limiting, of the second user being the first user), and the first process can include a process of sending a remittance request (this is an example, not limiting, of the first remittance request) to the other user based on the remittance request sending information, and sending a remittance request or a remittance reminder (this is an example, not limiting, of the second remittance request) to the other user based on the sent remittance request information.
As an example of an effect of the embodiment obtained by such a configuration, a first remittance request to the first user and a second remittance request to the first user can be made simultaneously.

In addition, in the above, the other user is one user (this is an example, not limiting, of the second user being the first user), and the first process shows a configuration including a process of sending to the first user an integrated remittance request (this is an example, not limiting, of a third remittance request) in which the remittance request amount is the sum of the remittance request amount of the remittance request to be sent to the other user and the remittance request amount included in the sent remittance request information.
As an example of an effect of an embodiment obtained by such a configuration, by sending a lump sum third remittance request to the first user based on a third amount, which is the sum of the first amount and the second amount, it is possible to effectively prompt the first user to make a remittance to the user of the terminal.

<Thirteenth Example>
The thirteenth embodiment is an embodiment relating to the processing of the above-mentioned (E) pattern.
The contents described in the thirteenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In this embodiment, in addition to including "received remittance requests" and "sent remittance requests" among the unprocessed requests in the lump-sum settlement, "sent remittance requests" are also included in the lump-sum settlement and lump-sum settlement is performed.

Please refer again to the table in FIG. 9-6.
In this pattern, any one of the following processes can be performed: (E1) remittance request + [remittance + receipt] (amount can be deducted), (E2) [receive + remittance] (amount can be deducted) + [remittance request or remittance reminder], or (E3) [receive + remittance] (amount can be deducted) + [remittance + receipt] (amount can be deducted).

In the process of (E1), when making a new remittance request to the other user, remittance and receipt are performed together based on the remittance request already received from the other user and the remittance request already sent to the other user. In this case, the difference in the remittance request amount can be sent/received. Also, if the remittance request amounts are the same, it is possible to offset the amounts.

In the process of (E2), when making a new remittance request to the other user, the other user remits money based on this new remittance request and receives the money, and also remits money to the other user based on the remittance request already received from the other user. In this case, it is possible to receive/transmit the difference in the remittance request amount. Also, if the remittance request amounts are the same, it is possible to offset the amounts.
Also, based on a remittance request already sent to the other user, the same remittance request is sent to the other user, or a remittance reminder is sent to the other user.

In the process of (E3), when making a new remittance request to the other user, the other user remits money based on this new remittance request and receives the money, and also remits money to the other user based on the remittance request already received from the other user. In this case, it is possible to receive/transmit the difference in the remittance request amount. Also, if the remittance request amounts are the same, it is possible to offset the amounts.
In addition, a user can send money to a user based on a remittance request already received from the other user, and can receive money from the other user based on a remittance request already sent to the other user. In this case, the user can send/receive the difference in the remittance request amount. In addition, if the remittance request amounts are the same, the amounts can be offset.

<Display screen>
Fig. 13-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a remittance request screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.A. The details of the screen configuration can be configured similarly to Fig. 11-1 by way of example and not limitation, so a detailed explanation will be omitted. Note that in Fig. 13-1, by way of example and not limitation, the remittance request amount to the user selected as the destination of the remittance request (user E.E. in this example) is set to "1,200 yen".

As a non-limiting example, in the pending request confirmation area URR1, when the first received remittance request (payment 2,500 yen) and the second sent remittance request (received 1,000 yen) are both checked "ON" and selected, and the remittance request sending lump-sum settlement button BT13 is tapped, terminal 20A requests server 10 to send a new remittance request and lump-sum settle the selected pending requests. Then, server 10 sends lump-sum settlement approval confirmation information to the other party, user E. E's terminal 20E to confirm whether or not to approve the lump-sum settlement, and the information is displayed on the display unit 24 of terminal 20E.

FIG. 13B is a diagram showing an example of a notification screen that is displayed when the remittance request transmission/lump settlement button BT13 is tapped.
In the notification information display area NTR4, an icon image of user A.A, who is the other party of the "request settlement and remittance request", and the lump-sum settlement amount are displayed as lump-sum settlement approval confirmation information.

In this example, the lump-sum settlement approval confirmation information displays the lump-sum settlement details as follows: User E.E will receive a remittance request amount of "2,500 yen" based on a past remittance request sent to User A.A, will pay a remittance request amount of "1,000 yen" based on a past remittance request received from User A.A, and will pay a remittance request amount of "1,200 yen" based on the current remittance request received from User A.A.

The lump-sum settlement approval confirmation information also indicates that User E.E will receive the lump-sum settlement amount of "300 yen", calculated by subtracting the remittance request amount of "1,000 yen" to be paid to User A.A from the remittance request amount of "2,500 yen" to be received from User A.A and the remittance request amount of "1,200 yen".

At the bottom of the lump-sum settlement approval confirmation information, there is displayed a settlement button BT16 marked "Settle" to approve the settlement with the above details, and a rejection button marked "Reject" to decline and not approve the settlement with the above details.

FIG. 13C is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT16 is tapped.
Below the current location display area CLR1, a notification NT5 including the text "300 yen has been remitted" is displayed together with a bell mark as a notification that the lump-sum settlement of the remittance request from user E.E's terminal 20E has been approved via server 10 and that the remittance has been completed as a result.

Further, in the notification information display area NTR2 of the notification screen, information corresponding to the above notification NT5 is displayed.
In the specific example, settlement result information is displayed after a lump-sum settlement has been made between user A.A and user E.E. In this example, the settlement result information displays that user A.A paid "300 yen" to user E.E as the lump-sum settlement amount.

The settlement result information also displays the details of the lump-sum settlement, stating that User A.A paid the remittance request amount of "2,500 yen" based on receiving a past remittance request from User E.E, received the remittance request amount of "1,000 yen" based on sending a past remittance request to User E.E, and received the remittance request amount of "1,200 yen" based on sending the current remittance request to User E.E.

<Processing>
The processes related to (E1) to (E3) above can be similarly configured based on the processes described in the previous embodiment, and are self-evident, so illustrations and detailed descriptions thereof will be omitted.

<Fourteenth Example>
The fourteenth embodiment is an embodiment relating to processing of a pattern different from the patterns described above.
The contents described in the fourteenth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In addition to the above-mentioned patterns, by way of example and not limitation, the combination patterns of new processing targets in the table of FIG. 9-6, that is,
It is also possible to process the following pattern: remittance + send remittance request.

The processing of this pattern is similar to that of pattern (C).
In other words, you can perform either of the following operations: "send money + send a remittance request" or "send money + receive money (amount can be deducted)."
When performing the process of "send + receive (amount can be deducted)", approval of the other user is required, and approval of the other user may or may not be obtained.

<Effects of the Fourteenth Example>
In this embodiment, the first information is remittance request information from the proposer's user to the other user, and the proposer's user terminal 20 displays a third display based on the remittance request information (not limited to, but an example of the third information) sent from the proposer's user to the other user on the display unit 24. The proposer's user terminal 20 then performs a second process related to remittance, receipt, or remittance request through the control unit 21 based on an input by the proposer's user to the terminal 20 displaying the remittance display from the proposer's user to the other user (not limited to, but an example of the first display) and the third display.
As an example of the effect of the embodiment obtained by such a configuration, remittance, receipt of remittance, or request for remittance can be performed all at once.

In addition, in the above, the second process shows a configuration including a process of transferring money to the other user based on remittance information (not limited to, but an example of the first information) and sending a remittance request to the other user based on remittance request information sent from the proposer user to the other user.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to simultaneously transfer money to a first user based on the first information and send a transfer request to the first user based on the third information.

In addition, in the above, the second process shows a configuration including a process of transferring an amount based on the amount to be transferred by the proposer user to the other user and the remittance request amount requested by the proposer user to the other user (this is not limited to an example of an amount based on the first information and the third information) to the other user or receiving an amount from the other user.
As an example of an effect of the embodiment obtained by such a configuration, an amount based on the first information and the third information can be paid to the first user or received from the first user.

In this case, the second process is configured to include a process of transferring to the other user an amount obtained by subtracting the remittance request amount requested by the proposer user from the amount to be transferred by the proposer user to the other user, or receiving from the other user an amount obtained by subtracting the amount to be transferred by the proposer user to the other user from the remittance request amount requested by the proposer user to the other user.
As an example of an effect of an embodiment obtained by such a configuration, the difference between the first amount and the third amount can be paid to the first user or received from the first user.

In this case, the second process may be executed based on the approval of the other user (not limited to, an example of the first user) based on an input to the terminal 20 of the other user.
As an example of an effect of the embodiment obtained by such a configuration, the second process can be executed based on the input to the terminal of the first user and based on the approval of the first user, which can prevent the second process from being executed against the will of the first user, for example and not by way of limitation.

<Fifteenth Example>
The fifteenth embodiment, like the fourteenth embodiment, is an embodiment relating to processing of a pattern different from the patterns described above.
The contents described in the fifteenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In addition to the above-mentioned patterns, by way of example and not limitation, the combination patterns of unprocessed requests shown horizontally in the table of FIG. 9-6, i.e.
It is also possible to process the pattern of received remittance request + sent request.

The processing of this pattern is similar to that of pattern (B).
In other words, you can perform either of the following operations: "send money + receive money (amount can be deducted)" or "send money + send a remittance request."
When performing the process of "send + receive (amount can be deducted)", approval of the other user is required, and approval of the other user may or may not be obtained.

<Effects of the 15th embodiment>
In this embodiment, the second information is remittance request information from the other user to the proposer's user, and the proposer's user terminal 20 displays a fourth display based on the transmitted remittance request information (not limited to, an example of the fourth information) transmitted from the proposer's user to the other user on the display unit 24. The proposer's user terminal 20 is configured to perform a third process related to remittance, receipt, or remittance request by the control unit 21 based on an input to the terminal 20 on which the second display based on the received remittance request information (not limited to, an example of the second information) related to the received remittance request received by the proposer's user from the other user and the fourth display are displayed.
As an example of the effect of the embodiment obtained by such a configuration, remittance, receipt of remittance, or request for remittance can be performed all at once.

The third process includes a process of sending money to a partner user based on the received remittance request information, and a process of sending a remittance request to the partner user based on the sent remittance request information.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to simultaneously transfer money to the second user based on the second information and send a transfer request to the second user based on the fourth information.

The third process includes a process of remitting an amount based on the received remittance request information and the transmitted remittance request information to the other user, or receiving an amount based on the received remittance request information and the transmitted remittance request information from the other user.
As an example of an effect of an embodiment obtained by such a configuration, an amount based on the second information and the fourth information can be paid to the second user or received from the first user.

In addition, the above-mentioned third process shows a configuration including a process of transferring an amount obtained by subtracting the remittance request amount of the transmitted remittance request information from the remittance request amount of the received remittance request information to the other user, or receiving an amount obtained by subtracting the remittance request amount of the transmitted remittance request information from the remittance request amount of the received remittance request information from the other user.
In an embodiment of the present invention, the amount obtained by this configuration is the difference between the second amount and the fourth amount, which can be paid to the second user or received from the second user.

In this case, the third process may be executed based on the approval of the other user (not limited to, an example of a second user) based on an input to the terminal 20 of the other user.
As an example of an effect of the embodiment obtained by such a configuration, the third process can be executed based on the second user's approval based on an input to the second user's terminal, which can prevent the third process from being executed against the second user's will, for example and not by way of limitation.

<16th Example>
The sixteenth embodiment relates to a method for displaying remittance request information.
The contents described in the sixteenth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
14-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a remittance screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
Below the current location display area CLR1, an icon image of the payment application of the user selected as the remittance destination and the user name (user C.C. in this example) are displayed.

Below the function button for increasing the remittance amount by a fixed amount is an unprocessed request confirmation area URR3, which is designed to enable confirmation of unprocessed requests between the user selected as the remittance recipient (user C.C. in this example) and the user making the remittance (user A.A. in this example).

At the top of the unprocessed request confirmation area URR3, the words "Unsettled request with C.C." are displayed, indicating that an unprocessed request between user C.C. and the user is being displayed.
To the right of this is displayed a remittance request history sort button STB1 for changing the display order of unprocessed remittance requests. The other display aspects are the same as those in the unprocessed request confirmation area URR1.

When the remittance request history sort button STB1 is touched, a sort selection area for selecting a sort order is displayed, by way of example and not limitation, from the bottom of the screen.
Based on user operations on the sort selection area, the display order of unprocessed remittance requests can be rearranged and displayed in ascending/descending order, for example but not limited to, by the date the remittance request was sent/received, or by the remittance request amount of the remittance request.

In addition, it is also possible to rearrange and display the order in which unprocessed remittance requests are displayed, so that they are displayed in the order of the date and time that the remittance requests were sent/received, instead of in the order of the date that the remittance requests were sent/received.

Figure 14-2 shows an example of a display screen in which remittance requests in the unprocessed request confirmation area URR3 are sorted in descending order by remittance request amount based on a user operation on the sort selection area, but is not limited to this example.

In Figure 14-1, the remittance requests in the unprocessed request confirmation area URR3 are sorted in ascending order by date, but in Figure 14-2, they are sorted in descending order by the remittance request amount.

When a payment deadline is set for a remittance request, by way of example and not by way of limitation, the remittance requests may or may not be displayed in the order in which their payment deadline approaches. Setting a payment deadline includes, by way of example and not by way of limitation, setting a repayment deadline for a loan (CtoB) from a financial institution or other business entity, in addition to payments between general users (CtoC).

In addition, remittance requests in which the amount or reason for the remittance request is related to a user other than the user who made the remittance request and the user to whom the remittance request was made may be displayed preferentially. As a non-limiting example, this is the case when other users are included as members of a split payment arrangement.

In addition, the pending request confirmation area URR3 is intended to display pending remittance requests, but is not limited to this.

FIG. 14-3 shows an example of a display screen in which processed remittance requests are mixed in with the unprocessed request confirmation area URR3.
In Fig. 14-3, by way of example and not limitation, the first remittance request in the unprocessed request confirmation area URR3 shows that a remittance request for the payment of the remittance request amount "1,000 yen" has been received, and is displayed in a grayed-out manner to indicate that the remittance request has been processed. Since processed remittance requests are not selected for lump-sum settlement, there is no check area.

<Effects of the Sixteenth Example>
In this embodiment, the terminal 20 of the user of the proposer displays on the display unit 24 a fourth display based on remittance request information regarding a received remittance request that the user of the proposer has received from the other user (not limited to, an example of the fourth information regarding a remittance request sent from a second user to the user of the terminal) or on remittance request information regarding a sent remittance request that the user of the proposer has sent to the other user (not limited to, an example of the fourth information regarding a remittance request sent from the user of the terminal to the second user).The terminal 20 of the user of the proposer shows a configuration in which the second display and the fourth display are displayed on the display unit 24 in an order based on the above-mentioned second information and the above-mentioned fourth information.
As an example of an effect of the embodiment obtained by such a configuration, the second display and the fourth display can be displayed in an appropriate order based on the second information and the fourth information.

In addition, this embodiment shows a configuration in which the above-mentioned second information and fourth information include information regarding the date when the remittance request was sent/received (not limited to this, but an example of information regarding the date), or information regarding the date and time when the remittance request was sent/received (not limited to this, but an example of information regarding the date and time), and the order in which the second display and the fourth display are displayed is determined based on this information regarding the date or the date and time.
As an example of an effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on information related to the date and time or date, it is possible to realize a display that is intuitively easy for the user to understand.

Furthermore, in this embodiment, the second information and fourth information include information regarding the amount of the remittance request (not limited to this, but an example of information regarding the amount), and the order in which the second display and the fourth display are displayed is determined based on this information regarding the amount.
As an example of the effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on information regarding the amount, it is possible to realize a display that is intuitively easy for the user to understand.

In this case, the information regarding the amount of the remittance request may include, in addition to the remittance request amount, information regarding the payment deadline, for example and not by way of limitation.
As an example of the effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on information regarding the payment deadline, it is possible to realize a display that is intuitively easy for the user to understand.

Next, as an opposite approach to the ninth to sixteenth embodiments, we will explain an embodiment relating to the processing when a user of terminal 20 receives (accepts) an amount remitted by a different user or receives a remittance request from a different user.

<17th Example>
The seventeenth embodiment is an embodiment in which, when a user of the terminal 20 receives an amount of money remitted from a partner user or a remittance request from a partner user, an outstanding request is displayed.
The contents described in the seventeenth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

15-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which shows the current location in the payment application, the word "NOTICE" is displayed, which indicates that the current location is the notification function of the payment application.

In the notification information display area NTR2 of the notification screen, remittance result information NC1 is displayed as the content related to the receipt of remittance (acceptance of remittance).
Note that for server 10, this is remittance result information because it is the result of the remittance process, and it is also remittance result information for the other user (user B.B. in this example), but for oneself (user A.A. in this example), it is the result of receiving money, so it can also be said to be receiving result information.

This remittance result information NC1 displays, by way of example and not limitation, the content corresponding to the receipt of the remittance amount "500 yen" sent (received) by user A.A from user B.B.

Below that, a list of pending remittance requests for the recipient user (user A.A. in this example) at the time the remittance was received is displayed. In this example, four pending requests are listed in chronological order starting from the oldest. The display format for each pending request is not limited to this, and can be configured in the same way as in Figure 1-23, so a repeated explanation will be omitted.

Note that, as for the pending requests, it is possible to display only pending requests between the user who sent the money (user A.A in this example) and the user who made the transfer (user B.B in this example), but this is not a requirement.

In this way, this embodiment is configured to display pending requests along with information on the remittance result (received result), so that when the user wants to confirm that the remitted amount has been received, the pending requests can also be checked.

Fig. 15-2 is a diagram showing another example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen corresponds to Fig. 15-1, but the display contents are partly different.
Specifically, by way of example and not limitation, a remittance receipt button labeled "RECEIVE TRANSFER" for accepting and receiving the remittance is displayed in the remittance result information NC1.
The remittance process is not complete until the remittance receipt button is tapped by user A.A, and when the remittance receipt button is tapped, the remittance amount (in this example, "500 yen") is added to the balance of the electronic money account of the user to whom the remittance was made (user A.A in this example).

In this example, when money is transferred from the other user (first user or second user) to the proposer user (user of the terminal), the proposer user is configured to be able to stop receipt of the amount being transferred.
Details will be given later, but this is called "holding receipt of remittance" or "holding receipt of funds."
Since the remittance is incomplete, this can also be considered as a "remittance on hold."

In this way, in this embodiment, by displaying the pending request together with the remittance result (received result) information where receipt of the remittance is put on hold, the user can check the pending request when deciding whether or not to receive the remitted amount.

Figure 15-3 is a diagram showing another example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a notification screen for a payment application displayed on the display unit 24 of the terminal 20A of user A.A.

In the notification information display area NTR2 of the notification screen, remittance request information NC7 is displayed as information related to the reception of the remittance request.
The remittance request information NC7 displays, by way of example and not limitation, the content corresponding to a remittance request for a remittance request amount of "500 yen" received by user A.A from user B.B. The remittance request information NC7 also displays a remittance request remittance button marked "Remit" for accepting the remittance request and making the remittance, and a remittance request rejection button marked "Reject" for rejecting the remittance request.

Below that is a list of pending remittance requests by the user who received the remittance request (user A.A. in this example) at the time the remittance request was received.

Note that, as for the pending requests, it is possible to display only pending requests between the user who received the remittance request (user A.A in this example) and the user who sent the remittance request (user B.B in this example), but this is not a requirement.

In this way, in this embodiment, by displaying the pending requests along with the information on the reception result of the remittance request, the user can also check the pending requests when confirming that the remittance request has been received.

<Processing>
Fig. 15-4 is a flowchart showing an example of the flow of the process executed by each device in this embodiment. Here, as an example, the process of displaying pending requests when a user receives remittance (receives money) described in Fig. 15-1 will be described.

Based on a request from terminal 20B (not shown), the control unit 11 of the server 10 executes a remittance process for user A.A of terminal 20A (S210). Specifically, as a non-limiting example, the control unit 11 updates the balance of user B.B's electronic money account by subtracting the remittance amount, and updates the balance of user A.A's electronic money account by adding the remittance amount.

Then, the control unit 11 of the server 10 transmits the remittance result information and the remittance request list information to the terminal 20A via the communication I/F 14 (S220).
Then, the control unit 11 of the server 10 ends the process.

In this case, the control unit 11 of the server 10 may or may not send the remittance result information to the terminal 20B.

The control unit 21 of the terminal 20A determines whether or not the remittance result information and the remittance request list information have been received from the server 10 via the communication I/F 22 (A205), and if it determines that they have been received (A205: YES), it causes the display unit 24 to display a lump-sum settlement screen including the remittance result information and the remittance request list information (A225).
The lump-sum settlement screen is the notification screen shown in the example display screen, by way of example and not limitation.
Then, the control unit 21 of the terminal 20A ends the process.

Figure 15-5 is a flowchart showing another example of the flow of processing executed by each device in this embodiment. Here, as an example, we will explain the processing when applying the suspension of remittance receipt (suspension of receipt) described in Figure 15-2.

The control unit 11 of the server 10 executes a first remittance process for user A.A of terminal 20A based on a request from terminal 20B (not shown) (S310a). Specifically, by way of example and not limitation, the remittance amount is subtracted from the balance of user B.B's electronic money account to update it.
In the first remittance process, unlike the remittance process (S210) in Fig. 15-4, the remittance amount is subtracted from the balance of the remittance source user's electronic money account, but the remittance amount is not added to the balance of the remittance destination user's electronic money account. In this state, the remittance is incomplete.

Then, the control unit 11 of the server 10 transmits the remittance result information of the first remittance process and the remittance request list information to the terminal 20A via the communication I/F 14 (S320).

In this case, the control unit 11 of the server 10 may or may not transmit remittance result information of the first remittance process to the terminal 20B.

After A225, the control unit 21 of the terminal 20A determines whether or not an input for receiving the remittance has been made to the input unit (A730), and if it determines that an input for receiving the remittance has been made (A730: YES), it transmits remittance receipt information for requesting receipt of the remittance to the server 10 via the communication I/F 22 (A740).

After S320, the control unit 11 of the server 10 determines whether remittance receipt information has been received from the terminal 20A via the communication I/F 14 (S740), and if it is determined that remittance receipt information has been received (S740: YES), executes the second remittance process (S310b). Specifically, by way of example and not limitation, based on the result of the first remittance process, the remittance amount is added to the balance of the electronic money account of the user A. A to update it. In other words, the state in which the receipt of the remittance was on hold is released, and the remittance is completely transferred.

Thereafter, the control unit 11 of the server 10 transmits remittance result information of the second remittance process to each of the terminals 20A and 20B via the communication I/F 14 (S790).
Then, the control unit 11 of the server 10 ends the process.

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

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

As for the process of displaying pending requests when a user receives a remittance request, as described in Figure 15-3, this can be configured in a similar manner by replacing "remittance" (receiving money for user A.A.) in the process of Figure 15-4 with "receiving remittance request," so illustration and explanation are omitted.
Specifically, in the processing of the terminal 20A, it is determined in A205 whether or not the remittance request transmission result information and the remittance request list information have been received, and in A225 a lump-sum settlement screen including these pieces of information is displayed.
In the processing of the server 10, a remittance request transmission process is executed in S210, and remittance request transmission result information and remittance request list information are transmitted in S220.

<Viewing pending requests>
The pending requests displayed on the display unit 24 of the terminal 20 may be, by way of example and not limitation, either or both of the following:
- Pending requests corresponding to the user who is sending money to you (the sending user) or the user who is sending a money transfer request to you (the sending request user) - Pending requests corresponding to a user other than the user who is sending money to you (the sending user) or the user who is sending a money transfer request to you (the sending request user)

Pending requests corresponding to the other user may be displayed. By way of example and not limitation, when user A.A receives a remittance from user B.B as the sending user, or when user A.A receives a remittance request from user B.B as the sending user, the pending request corresponding to user B.B may be displayed.

However, some users may wish to view pending requests corresponding to different users than the other user.
Thus, as illustrated in FIGS. 15-1 to 15-3, in addition to the pending requests corresponding to user B.B, by way of example and not limitation, pending requests corresponding to user C.C may also be displayed.
It should be noted that in this case, instead of displaying the pending requests corresponding to user B.B, it is also possible to display the pending requests corresponding to user C.C, for example and not by way of limitation.

That is, similarly to the eighth embodiment, the following three patterns are conceivable as examples of patterns for displaying unprocessed requests, and are not limiting.
(Pattern 1) An unprocessed request corresponding to the other user. (Pattern 2) An unprocessed request corresponding to the other user + an unprocessed request corresponding to a user other than the other user. (Pattern 3) An unprocessed request corresponding to a user other than the other user.

Furthermore, in any of the above patterns, for each user, all of the unprocessed requests corresponding to that user may be displayed, or only a portion of the unprocessed requests corresponding to that user may be displayed.
In other words, the user (the other user/a user different from the other user) displaying the unprocessed requests and the range (all/a part) of the unprocessed requests to be displayed can be combined arbitrarily. As a non-limiting example (Pattern 2), all unprocessed requests corresponding to the other user may be displayed, but only a part of the unprocessed requests corresponding to a user different from the other user may be displayed.

In addition, when displaying some of the unprocessed requests, it is possible to determine which unprocessed requests to display based on various information (conditions).
In this case, it is possible to combine the contents of the twenty-sixth embodiment described later. As will also be described in the twenty-sixth embodiment, the various types of information include, but are not limited to, the following information by way of example.
- Date and time when the remittance request was sent/received - The amount of the remittance request - The payment deadline for the remittance request - Remittance requests in which the amount or reason for the remittance request is related to the user other than the user who made the remittance request and the user to whom the remittance request was made Note that this information is merely an example and is not limited to this.
Moreover, a combination of a plurality of pieces of information among these pieces of information can be applied.

Since a user may forget about pending requests whose dates or times are older than a certain number, it may be decided to display pending requests even if they correspond to a different user than the target user.
Pending requests with a large remittance request amount may be of high importance, so it may be decided to display pending requests even if they correspond to a different user than the target user.
Remittance requests where other users than the requesting user and the requested user are involved in the remittance request amount or reason may also be of high importance, so it may be decided to display pending requests even if they correspond to users other than the other user.
Pending requests that are due for payment within a certain period of time may require urgent processing, so it may be decided to display pending requests even if they correspond to a different user than the target user.

As will also be described in the 26th embodiment, the unprocessed requests can be sorted and displayed in ascending or descending order based on the various information (conditions) described above. As an example, the more important an unprocessed request is, the higher it is displayed at the top.

In addition to these, the pending requests displayed on the display unit 24 of the terminal 20 can be hidden based on, for example and not by way of limitation, an input by the user of the terminal 20 on an input unit.
In this case, by way of example and not limitation, pending requests corresponding to a portion of users may be hidden, or pending requests corresponding to all users may be hidden.

Also, it is considered that some users may find it annoying to see pending requests displayed.
Therefore, it may be possible to set whether to display or not display the unprocessed requests on a setting screen (not shown) or the like.

Specifically, on the application settings screen, as setting information related to the display of unprocessed requests, for example and without limitation, a slide button or check box that can switch between displaying and hiding unprocessed requests is displayed. Then, based on the operation of this slide button or check box, the terminal 20 or server 10 can be made to set the display/hide state.

In this case, it may be possible to set whether to display or hide unprocessed requests collectively for all users, or it may be possible to set whether to display or hide unprocessed requests individually for each user.
Also, it may be possible to set whether to display all unprocessed requests or to display only some of the unprocessed requests.

These contents also apply to the following examples.

<Effects of the 17th embodiment>
In this embodiment, the terminal 20 of the proposer's user receives remittance result information from the other user (not limited to, an example of first information regarding a remittance from the first user to the user of the terminal) or remittance request information sent from the other user (not limited to, an example of first information regarding a remittance request sent from the first user to the user of the terminal) from the server 10 via the communication I/F 22.
The terminal 20 of the proposer's user is then configured to display on the display unit 24 a first display based on the received information, and based on receiving the first information, display on the display unit 24 a second display based on received remittance request information regarding a remittance request already received from the other user (not limited to, an example of second information regarding a remittance request sent from the second user to the user of the terminal) or sent remittance request information regarding a remittance request already sent to the other user (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to the second user).
As an example of an effect of the embodiment obtained by such a configuration, when the user of the terminal checks the first information, the user can also check the second information.

Furthermore, this embodiment illustrates a configuration in which the terminal 20 of the proposer's user performs a process for receiving the remittance amount (not limited to, an example of a first process related to receiving the remittance) through the control unit 21 based on input by the proposer's user to the terminal 20 on which the first display and the second display are displayed.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to easily receive remittances from the other user based on input to the terminal on which the first display and the second display are displayed.

<Seventeenth Modification (1)>
In the seventeenth embodiment, settlement (including lump-sum settlement of unprocessed requests) may be performed based on input regarding information on unprocessed requests that are displayed together with remittance result information from the other user and remittance request information sent by the other user.

Specifically, but not limited to, in the screen examples of Figs. 15-1 to 15-3, a settlement button for executing settlement of the selected unprocessed requests (lump settlement if multiple requests are selected) is displayed.
Then, when the settlement button is tapped, the server 10 can execute the settlement process for the selected unprocessed request.

The settlement process for unprocessed requests has been described above, so we will not explain it again.

Figure 15-6 is a flowchart showing an example of the flow of processing executed by each device in this modified example. Here, as an example, the processing for holding receipt of a remittance (holding receipt) shown in Figure 15-5, in which either receiving the remittance or settling an unprocessed request is performed, is described.

After A225, the control unit 21 of the terminal 20A determines an execution target based on an input to the input unit (A831).
If it is determined that the execution target is settlement of unprocessed requests (lump settlement if multiple requests are selected) (A831: Settlement of unprocessed requests), the control unit 21 of the terminal 20A moves the process to A632. That is, it sets request selection information including unprocessed request selection information indicating the selected unprocessed request.

On the other hand, if it is determined that the execution target is receiving a remittance (A831: receiving a remittance), the control unit 21 of the terminal 20A sets request selection information including remittance receipt information (A333).

After A632 or A333, the control unit 21 of the terminal 20A transmits the set request selection information to the server 10 via the communication I/F 22 (A140).
Then, the control unit 21 of the terminal 20A transfers the processing to A150.

If it is determined in S140 that request selection information has been received from terminal 20A (S140: YES), the control unit 11 of the server 10 determines the processing target based on the received request selection information (S841).

If it is determined that the processing target is settlement of an unprocessed request (S841: Settlement of an unprocessed request), the control unit 11 of the server 10 proceeds to S642. In other words, the selected unprocessed request is set as the target for settlement (if multiple requests are selected, they are set as the target for lump-sum settlement). The control unit 11 of the server 10 then executes the settlement process of S150.

On the other hand, if it is determined that the processing target is remittance receipt (S841: remittance receipt), the control unit 11 of the server 10 advances the process to S310b, that is, executes the second remittance processing.
Then, the control unit 11 of the server 10 advances the process to S170.

When applying the first settlement process described in FIG. 1-19 by way of example and not by way of limitation,
When the setting of S642 is performed and there are multiple unprocessed requests to be processed, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target is "YES." As a result, the processing from S1515 onward is executed with the multiple unprocessed requests as the lump-sum settlement targets.
In addition, when the setting of S642 is performed and there is one unprocessed request to be processed, the result of the determination in S1510 as to whether the settlement target is a lump-sum settlement target or not is "NO." As a result, the processing from S1570 onward is executed with this one unprocessed request as the settlement target.

In addition, the process of displaying pending requests and settling pending requests when the user receives the remittance amount without suspending receipt of the remittance can be configured in a similar manner to Figure 15-6, so illustrations and explanations are omitted.
In addition, the process of displaying pending requests when a user receives a remittance request and either remittance or settling the pending request can be configured in a similar manner following Figure 15-6, so illustration and explanation are omitted.

In this modified example, the terminal 20 of the proposer's user receives remittance result information from the other user (not limited to, an example of first information regarding a remittance from the first user to the user of the terminal) or remittance request information sent from the other user (not limited to, an example of first information regarding a remittance request sent from the first user to the user of the terminal) from the server 10 via the communication I/F 22.
In addition, the terminal 20 of the proposer's user displays on the display unit 24 a first display based on the received information, and based on receiving the first information, displays on the display unit 24 a second display based on received remittance request information regarding a remittance request already received from the other user (not limited to, an example of second information regarding a remittance request sent from the second user to the user of the terminal) or sent remittance request information regarding a remittance request already sent to the other user (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to the second user).
The terminal 20 of the proposer's user is configured to perform, through the control unit 21, a process for transferring money, a process for receiving the transferred amount, a process for sending a remittance request, or a process for receiving a remittance request (not limited to, an example of a first process related to transferring money, receiving a remittance, or requesting a remittance), based on an input by the proposer's user to the terminal 20 on which the first display and the second display are displayed.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to easily transfer money to a partner user, receive money from a partner user, and send/receive a transfer request to a partner user based on input to a terminal on which the first display and the second display are displayed.

<Seventeenth Modification (2)>
In the above embodiment, the settlement result information on the display screen is rendered and displayed based on the first information, i.e., the first display and the second display are displayed substantially simultaneously.
However, in the above embodiment, the first display and the second display include the following two cases.
(1) Reception of first information → first display → second display (2) Reception of first information → first display, reception of first information → second display

(1) is a case in which a first display is displayed based on the received first information, and a second display is displayed based on the displayed first display.
(2) is a case in which the first display is displayed based on the received first information, and the second display is displayed based on the received first information.
In any case, the fact remains that the reception of the first information is the trigger.

Furthermore, the first and second displays may be displayed in any order.
In other words, the above case (1) can be expressed as "receive first information → second display → first display", and the above case (2) can be expressed as "receive first information → second display, receive first information → first display".

This also applies to the examples described below.

Next, as an example related to the 17th example, we will explain an example in which, when a user of terminal 20 receives (accepts) an amount transferred from a different user or receives a remittance request from a different user, an unprocessed request selected from the displayed unprocessed requests is also processed.

In the following embodiments, the following five patterns will be described.
(a) A pattern of receiving money + processing a received remittance request (b) A pattern of receiving money + processing a sent remittance request (c) A pattern of receiving money + processing a received remittance request + processing a sent remittance request (d) A pattern of receiving a remittance request + processing a received remittance request (e) A pattern of receiving a remittance request + processing a sent remittance request We will explain each pattern using separate examples.

As also shown in the 17th variant example, the processing (first processing, etc.) executed by the terminal 20 via the control unit 21 includes, by way of example and not limitation, processing for making a remittance (a non-limiting example of a processing related to a remittance), processing for receiving (accepting) a remittance (a non-limiting example of a processing related to receiving a remittance), processing for sending/receiving a remittance request (a non-limiting example of a processing related to a remittance request), etc.
In the following, a server-client system is exemplified, and it is assumed that remittances and transmission of remittance requests are carried out via the server 10.

In the following, as described above, a case will be exemplified in which the other user is one user, that is, the second user is the first user (or the first user is the second user).
As mentioned above, the method described below can also be applied when the other users are multiple different users, that is, when the first user is a user different from the second user (and the second user is a user different from the first user).

<18th Example>
This embodiment relates to processing of the above pattern (a).
The contents described in the 18th embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 16A is a diagram showing an example of a table for explaining a processing method corresponding to each of the above patterns.
The vertical direction of the table shows the target of a new process to be executed (new process target) as an item, and the horizontal direction of the table shows the type of unprocessed request as an item. Then, in the field where the vertical and horizontal items intersect, an example of a process that is realized by a combination of the new process target and the type of unprocessed request is shown.
I will explain in order.

In the case of the (a) receiving + received remittance request pattern, the (a1) receiving + sending process can be performed. In other words, when receiving money from the other user, the other user also sends money to the other user based on the remittance request that has been received from the other user.

<Display screen>
16-2 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the current location display area CLR1 which shows the current location in the payment application, the word "NOTICE" is displayed, which indicates that the current location is the notification function of the payment application.

In the notification information display area NTR2 of the notification screen, remittance result information NC1 is displayed as the content related to the receipt of remittance (acceptance of remittance).
In the following description, for convenience, the remittance result information may be illustrated as including the remittance request list information. In this case, the remittance result information may be referred to as lump-sum settlement information.

In addition, for server 10, it is remittance result information because it is the result of the remittance process, and for the other user (user B.B. in this example), it is remittance result information, but for you (user A.A. in this example), it is the result of receiving the money, so it can also be said to be receipt result information.

This remittance result information NC1 displays, by way of example and not limitation, the content corresponding to the receipt of the remittance amount "500 yen" sent (received) by user A.A from user B.B.

Below that, a list of pending remittance requests for the recipient user (user A.A. in this example) at the time the remittance was received is displayed. In this example, four pending requests are listed in chronological order starting from the oldest. The display format for each pending request is not limited to this, and can be configured in the same way as in Figure 1-23, so a repeated explanation will be omitted.

Note that, as unprocessed requests, it is possible to display only unprocessed requests between the user who sent the remittance (user A.A in this example) and the user who sent the remittance (user B.B in this example), but this is not essential. In this case, the display format of each unprocessed request can be configured in the same way as in FIG. 1-11, but is not limited thereto.

At the bottom of the remittance result information NC1, a lump-sum settlement button labeled "Settle all" is displayed to allow the user to settle all requests at once. In addition, next to the lump-sum settlement button, a lump-sum settlement button BT17 labeled "Settle one request" is displayed to allow the user to settle a portion of the unprocessed requests displayed in the remittance result information NC1.

As a non-limiting example, when the check box for the first received remittance request (payment of 2,000 yen to user C.C.) is checked "ON" and selected in the remittance result information NC1 and the partial selection lump-sum settlement button BT17 is tapped, terminal 20A requests server 10 to execute lump-sum settlement of the selected unprocessed requests. Then, server 10 transmits settlement result information regarding the execution result to terminal 20C of user C.C., the other party, and terminal 20A of user A.A., the user.

FIG. 16C is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the partial selection lump-sum settlement button BT17 is tapped.
In this example, in the notification information display area NTR2 of the notification screen, settlement result information NC2 is displayed as the details of the lump-sum settlement below remittance result information NC1.

As an example, but not by way of limitation, the settlement result information NC2 displays information regarding the fact that user A.A has executed a remittance of "2,000 yen" to user C.C. through settlement of the payment of the remittance request amount of "2,000 yen" in response to a remittance request from user C.C.

The settlement result information displayed on user C.C's terminal 20C not only displays the receipt of the remittance amount of "2,000 yen" from user A.A, but also displays a list of user C.C's unprocessed requests in accordance with the display mode of remittance result information NC1.

<Processing>
FIG. 16D is a flowchart showing an example of the flow of the process executed by each device in this embodiment.
Based on the request from terminal 20B, the control unit 11 of the server 10 executes a remittance process for user A.A of terminal 20A (S210). Specifically, by way of example and not limitation, the control unit 11 updates the balance of the electronic money account of user B.B by subtracting the remittance amount, and updates the balance of the electronic money account of user A.A by adding the remittance amount.
Then, the control unit 11 of the server 10 transmits the remittance result information and the remittance request list information to the terminal 20A via the communication I/F 14 (S220).

The control unit 21 of the terminal 20A determines whether or not the remittance result information and the remittance request list information have been received from the server 10 via the communication I/F 22 (A205), and if it determines that they have been received (A205: YES), causes the display unit 24 to display a lump-sum settlement screen including the remittance result information and the remittance request list information (A225).

If it is determined in A131 that an unprocessed request has been selected (A131: YES), the control unit 21 of the terminal 20A sets the unprocessed request selection information as the request selection information (A232).Then, the control unit 21 of the terminal 20A moves the process to A140.
On the other hand, if it is determined that no unprocessed request has been selected (A131: NO), the control unit 21 of the terminal 20A ends the process.

If it is determined in S141 that the unprocessed requests are to be processed (S141: YES), the control unit 11 of the server 10 sets the selected unprocessed requests as targets for lump-sum settlement (S242), and then the control unit 11 of the server 10 proceeds to S150.
Moreover, if it is determined that the process is not for an unprocessed request (S141: NO), the control unit 11 of the server 10 ends the process.

<Effects of the 18th embodiment>
In this embodiment, the terminal 20 of the proposer user receives remittance result information from the other user (not limited to, an example of first information regarding a remittance from the first user to the terminal user) from the server 10 via the communication I/F 22.
In addition, the terminal 20 of the proposer's user displays on the display unit 24 a first display (not limited to, an example of the first display) based on the received remittance result information, and based on the reception of the remittance result information, displays on the display unit 24 a second display (not limited to, an example of the second display) based on received remittance request information (not limited to, an example of second information regarding a remittance request sent from a second user to the user of the terminal) regarding the received remittance request from the other user.
The configuration shows that the terminal 20 of the proposer's user executes a first process related to remittance or receipt (not limited to, but an example of receiving remittance) through the control unit 21 based on an input by the proposer's user to the terminal 20 on which the first display and the second display are displayed.
As an example of the effect of an embodiment obtained by such a configuration, a first process related to remittance or receipt of remittance can be easily and appropriately performed based on an input to a terminal on which the first display and the second display are displayed.

Furthermore, in this embodiment, the second information is remittance result information (not limiting, but an example of information relating to a remittance from the first user to the user of the terminal), the second information is received remittance request information (not limiting, but an example of information relating to a remittance request sent from the second user to the user of the terminal), and the first process shows a configuration including a process of remittance to the other user (not limiting, but an example of the second user) based on an input to the terminal 20 on which the second display is displayed.
As an example of an effect of an embodiment obtained by such a configuration, the user of the terminal can be notified that a transfer of money is scheduled to be made from the first user to the user of the terminal, and the money can be transferred to the second user based on input into the terminal showing the second display.

In addition, this embodiment shows a configuration in which the first display and the second display are displayed on the display unit 24 by a payment application installed on the terminal 20 of the proposer's user, and the payment application is included in the program related to the present disclosure.
As an example of an effect of the embodiment obtained by such a configuration, the first display and the second display can be displayed on the display unit of the terminal by an application installed on the terminal.

<18th Modification>
In the above embodiment, it is assumed that the remittance from the other user is completed at the time when the remittance result information is received by the terminal 20 of the proposer user, but this is not limited to the above.
Specifically, the method of suspending receipt of a remittance described above (suspending receipt of remittance) may be applied, and the remittance from the other user may or may not be completed based on an input (operation, etc.) for receiving the remittance being made while the second display is displayed.
This also applies to the other embodiments.

<19th Example>
The 19th embodiment is an embodiment relating to processing of the above-mentioned pattern (b).
The contents described in the 19th embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In the case of the pattern (b) receiving money + remittance request already sent, the process of (b1) receiving money + remittance reminder can be performed. In other words, when receiving money from a user on the other side, a remittance reminder for this remittance request is sent based on the remittance request already sent to the user on the other side.
In this case, a new remittance request may or may not be made instead of a remittance reminder.

<Display screen>
Fig. 17-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A. As for the details of the screen configuration, by way of example and not limitation, it is possible to configure it in the same way as in Fig. 16-2, so a detailed description will be omitted.

As a non-limiting example, in the remittance result information NC1, when the check box for the third received remittance request (received from user C.C. for 1,000 yen) is checked "ON" and selected, and the partial selection lump-sum settlement button BT17 is tapped, terminal 20A requests server 10 to execute lump-sum settlement of the selected unprocessed requests. Then, server 10 sends settlement result information regarding the execution result to terminal 20C of user C.C., the other party.

FIG. 17-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20C when the partial selection lump-sum settlement button BT17 is tapped.
In this example, the notification information display area NTR1 of the notification screen displays settlement result information NC3 as the contents of the lump-sum settlement.
As an example and not a limitation, the settlement result information NC3 displays a reminder corresponding to the third remittance request selected in Figure 17-1 (a remittance request for the amount of 1,000 yen sent by user A.A to user C.C.).

When the partial selection lump-sum settlement button BT17 is tapped, the notification information display area NTR2 of the terminal 20A may or may not display information such as "A reminder has been sent to user C.C.", indicating that a remittance reminder has been sent to user C.C.

<Processing>
In this embodiment, the processes executed by each device can be realized in a similar manner to the processes in FIG. 16-4, and therefore illustrations and detailed descriptions thereof will be omitted.

<Effects of the 19th embodiment>
In this embodiment, the terminal 20 of the proposer user receives remittance result information from the other user (not limited to, an example of first information regarding a remittance from the first user to the terminal user) from the server 10 via the communication I/F 22.
In addition, the terminal 20 of the proposer's user displays on the display unit 24 a first display (not limited to, an example of the first display) based on the received remittance result information, and based on the reception of the remittance result information, displays on the display unit 24 a display (not limited to, an example of the second display) based on sent remittance request information (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to a second user) regarding the remittance request that has already been sent to the other user.
The configuration shows that the terminal 20 of the proposer's user executes a first process related to receiving money (not limited to this, but an example of receiving a money transfer), or related to a money transfer reminder or a new money transfer request (not limited to this, but an example of a money transfer request), through the control unit 21, based on an input by the proposer's user to the terminal 20 on which the first display and the second display are displayed.
As an example of the effect of an embodiment obtained by such a configuration, a first process related to receiving a remittance or requesting a remittance can be easily and appropriately performed based on an input to a terminal on which the first display and the second display are displayed.

In addition, this embodiment illustrates a configuration in which the first information is remittance result information from the other user (not limited to, but an example of information regarding a remittance from the first user to the user of the terminal), and the second information is sent remittance request information regarding a remittance request that has already been sent from the proposer user to the other user (not limited to, but an example of information regarding a remittance request sent from the user of the terminal to the second user).
An advantage of this embodiment is that it is possible to carry out processing in a unified manner based on a remittance from a first user to a user of a terminal and a remittance request sent from the user of the terminal to a second user.

In this case, the first process is configured to include a process of sending a remittance reminder or a new remittance request to the other user (not limited to, but an example of a second user) based on an input to the terminal 20 on which the second display is displayed.
As an example of an effect of an embodiment obtained by such a configuration, a remittance request can be easily made to the second user based on an input to the terminal on which the second display is displayed.

<20th Example>
The twentieth embodiment is an embodiment relating to processing of the above-mentioned pattern (c).
The contents described in the twentieth embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In the case of (c) Receipt + received remittance request + sent remittance request, the following process can be performed: (c1) [Receipt + Remittance] (amount can be deducted) + [Remittance + Receipt] (amount can be deducted).

In this process, when receiving money from a user, a transfer to the other user is also performed based on the remittance request already received from the other user. In this case, the difference in the remittance request amount can be received/transmitted. Also, if the remittance request amounts are the same, the amounts can be offset.
In addition, a user can send money to a user based on a remittance request already received from the other user, and can receive money from the other user based on a remittance request already sent to the other user. In this case, the user can send/receive the difference in the remittance request amount. In addition, if the remittance request amounts are the same, the amounts can be offset.

<Display screen>
Here, as an example, a display screen example in the case where the above-mentioned suspension of receipt of remittance (suspension of receipt) is applied will be described.

18-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the notification information display area NTR2 of the notification screen, remittance result information NC4 is displayed as the content related to the receipt of remittance (acceptance of remittance).
The remittance result information NC4 displays, by way of example and not limitation, the content corresponding to the receipt of the remittance amount "500 yen" remitted by user A.A from user C.C.

The remittance result information NC4 displays a remittance receipt button marked "Receive Remittance" for accepting and receiving the remittance. In other words, the remittance process is not complete until the remittance receipt button is tapped by user A.A., and when the remittance receipt button is tapped, the remittance amount (in this example, "500 yen") is added to the electronic money account balance of the user to whom the remittance was made (user A.A. in this example).

In addition, remittance result information NC4, like remittance result information NC1, displays a list of remittance requests that are pending for the user to whom the remittance was sent (user A.A. in this example) at the time the remittance was received.

At the bottom of the remittance result information NC4, a receive all selected lump sum settlement button labeled "Settle all and receive remittance" is displayed, which allows the user to select and settle all requests at once, assuming that the remittance has been approved. In addition, next to the receive all selected lump sum settlement button is a receive lump sum settlement button BT18 labeled "Settle one request," which allows the user to select and settle some of the unprocessed requests selected by the user from the unprocessed requests displayed in the remittance result information NC4, assuming that the remittance has been approved.

When the remittance receipt button in the remittance result information NC4 is tapped by user A.A, by way of example and not limitation, the display mode of the remittance result information NC4 changes in the same manner as the remittance result information NC1 when the user who made the remittance is user C.C.

As a non-limiting example, in the remittance result information NC4, when the first received remittance request (payment of 2,000 yen to user C.C.) and the third sent remittance request (received of 1,000 yen from user C.C.) are checked "ON" and selected, and the lump-sum receipt button BT18 is tapped, a request is made from terminal 20A to server 10 to transfer the money (remittance from user C.C. to user A.A.) and settle the selected unprocessed requests in a lump sum. For user A.A., this remittance is a receipt of the remittance (receipt).

Then, the server 10 transmits lump-sum settlement approval confirmation information to the terminal 20C of the other party, user C.C., to confirm whether or not to approve the lump-sum settlement, and the information is displayed on the display unit 24 of the terminal 20C.

FIG. 18B is a diagram showing an example of a notification screen that is displayed when the Receive Lump Sum Settlement button BT18 is tapped.
In the notification information display area NTR1, an icon image of user A.A, who is the other party of the "settlement proposal", and the lump-sum settlement amount are displayed as lump-sum settlement approval confirmation information NC5.

The lump-sum settlement approval confirmation information NC5 displays the lump-sum settlement details as follows: User C.C received a remittance request amount of "2,000 yen" based on a past remittance request sent to User A.A, paid a remittance request amount of "1,000 yen" based on a past remittance request received from User A.A, and will pay "500 yen" with the current remittance to User A.A.

The lump-sum settlement approval confirmation information NC5 also indicates that user C.C. will receive from user A.A the lump-sum settlement amount of "500 yen", calculated by subtracting the remittance request amount of "1000 yen" upon receiving the remittance request and the current remittance amount of "500 yen" from the amount received by sending the remittance request of "2,000 yen".

At the bottom of the lump-sum settlement approval confirmation information NC5, there is displayed a settlement button BT19 marked "Settle" for approving the settlement with the above details, and a rejection button marked "Reject" for rejecting the settlement with the above details.

FIG. 18C is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT19 is tapped.
In this example, in the notification information display region NTR2 of the notification screen, settlement result information NC6 is displayed below remittance result information NC4 as the details of lump-sum settlement.

As an example, but not by way of limitation, the settlement result information NC6 shows the amount of the settlement result (in this example, the payment of "500 yen" remitted by user A.A to user C.C) as the content of the lump-sum settlement that has been made between user A.A and user C.C.

In other words, in this embodiment, even if the Select All Receipt and Settle All at Once button or the Receipt and Settle All at Once button BT18 is tapped in the remittance result information NC4, the remittance is not immediately received. The remittance amount is temporarily suspended (suspended receipt of remittance, suspended receipt) and then included in the contents of the lump-sum settlement, so that the remittance is settled all at once.

The remittance may be cancelled after a certain period of time has elapsed since the server 10 sent the remittance result information. Conversely, the remittance may be forcibly completed.

In FIG. 18-1, when the lump-sum settlement of received money button BT18 is tapped, a confirmation screen is displayed on the display unit 24 of the terminal 20A to inform the user A.A that the lump-sum settlement amount of "500 yen" will be paid if the settlement is made, and the receipt of the remittance and the lump-sum settlement of the selected unprocessed requests may or may not be requested based on the approval of the user A.A.

<Processing>
FIG. 18D is a flowchart showing an example of the flow of the process executed by each device in this embodiment.

If it is determined in A131 that an unprocessed request has been selected (A131: YES), the control unit 21 of the terminal 20A sets the remittance receipt information regarding receipt of the remittance in the first remittance process and the unprocessed request selection information as request selection information (A332).

On the other hand, if it is determined that an unprocessed request has not been selected (A131: NO), the control unit 21 of terminal 20A sets the remittance receipt information as the request selection information (A333).

In addition, the process of A333 is executed only if receipt of the remittance is explicitly selected in A131, and if it is not selected, the control unit 21 of the terminal 20A may or may not terminate the process.
After A332 or A333, the control unit 21 of the terminal 20A transfers the process to A140.

If it is determined in S141 that the unprocessed request is to be processed (S141: YES), the control unit 11 of the server 10 sets the remittance (remittance from user B.B. to user A.A.) and the lump-sum settlement of the unprocessed requests as targets for lump-sum settlement (S342). The control unit 11 of the server 10 then proceeds to S150.

On the other hand, if it is determined that the unprocessed request is not to be processed (S141: NO), the control unit 11 of the server 10 proceeds to S310b, in other words, the second remittance process is executed.
Then, the control unit 11 of the server 10 advances the process to S170.

The control unit 21 of the terminal 20B executes the processes B150 to B190.
Then, the control unit 21 of the terminal 20B ends the process.

<Effects of the 20th embodiment>
In this embodiment, the terminal 20 of the proposer user receives incomplete remittance result information from the other user (not limited to this, an example of first information regarding a remittance from the first user to the terminal user) from the server 10 via the communication I/F 22.
In addition, the terminal 20 of the proposer's user displays on the display unit 24 a first display (not limited to, an example of the first display) based on the received incomplete remittance result information, and displays on the display unit 24 a second display (not limited to, an example of the second display) based on the received remittance request information (not limited to, an example of second information regarding a remittance request sent from the second user to the user of the terminal) or the sent remittance request information (not limited to, an example of second information regarding a remittance request sent from the user of the terminal to the second user) based on the reception of the remittance result information.
The configuration shows that the terminal 20 of the proposer's user executes a first process related to sending or receiving money (not limited to this, but an example of receiving a remittance) through the control unit 21 based on an input by the proposer's user to the terminal 20 on which the first display and the second display are displayed.
As an example of the effect of an embodiment obtained by such a configuration, a first process related to remittance or receipt of remittance can be easily and appropriately performed based on an input to a terminal on which the first display and the second display are displayed.

In this case, the first process is configured to include a process of receiving the amount remitted from the other user (not limited to, but an example of a process of receiving the amount remitted from the first user to the user of the terminal) based on an operation of receiving remittance (not limited to, but an example of an input to the terminal on which the first display is displayed) after the first display is displayed on the display unit 24.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to receive the amount of money remitted from the first user based on an input to the terminal on which the first display is displayed.

In addition, this embodiment shows a configuration in which the other user is one user (this is not a limitation, but an example in which the second user is the first user), and the first process includes a process of transferring an amount based on the received remittance request information and the sent remittance request information to the other user, or receiving a transfer from the other user.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to transfer an amount based on the first information and the second information to the first user, or to receive money transferred from the first user.

In this case, the first process may include a process of transferring to the other user an amount obtained by subtracting the remittance request amount included in the transmitted remittance request information from the remittance request amount included in the received remittance request information, or a process of receiving from the other user an amount obtained by subtracting the remittance request amount included in the transmitted remittance request information from the remittance request amount included in the received remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, the difference amount can be remitted to the first user, or can be received by having the first user remit the difference amount.

In this case, the first process can be executed based on the approval of the other user, based on an input to the terminal 20 of the other user.
As an example of an effect of the embodiment obtained by such a configuration, the first process can be executed based on the input to the terminal of the first user and based on the approval of the first user, which can prevent the first process from being executed against the will of the first user, for example and not by way of limitation.

<20th Modification>
In relation to the above embodiment, the "receipt" in the new processing target in the table of FIG. 16A can also be changed to "receipt pending."

in this case,
It is possible to carry out processing in one of the following patterns: - Pending receipt + received remittance request - Pending receipt + sent remittance request - Pending receipt + received remittance request + sent remittance request

The processing for these patterns is similar to that for patterns (a) to (c). The only difference is whether the transferred amount is received immediately or at a later time.

<Twenty-first embodiment>
The twenty-first embodiment is an embodiment relating to processing of the above-mentioned pattern (d).
The contents described in the twenty-first embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In the case of the pattern (d) receiving a remittance request + received remittance request, it is possible to carry out the process of (d1) remittance [remittance + remittance]. In other words, remittance is made to the other user based on the remittance request received from the other user, and remittance is made to the other user based on the remittance request already received from the other user.

<Display screen>
19-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.

In the notification information display area NTR2 of the notification screen, remittance request information NC7 is displayed as information related to the reception of the remittance request.
The remittance request information NC7 displays, by way of example and not limitation, the content corresponding to a remittance request for a remittance request amount of "500 yen" received by user A.A from user B.B. The remittance request information NC7 also displays a remittance request remittance button marked "Remit" for accepting the remittance request and making the remittance, and a remittance request rejection button marked "Reject" for rejecting the remittance request.

Below that, a list of pending remittance requests by the user who received the remittance request (user A.A. in this example) at the time the remittance request was received is displayed. The display format of pending requests can be configured in the same way as in Figure 16-2, but is not limited to this, so a detailed explanation will be omitted.

Note that, as for the pending requests, it is possible to display only pending requests between the user who received the remittance request (user A.A in this example) and the user who sent the remittance request (user B.B in this example), but this is not a requirement.

At the bottom of the remittance request information NC7, a remittance request remittance all-selection lump-sum settlement button labeled "Settle all and send" is displayed for executing the remittance based on this remittance request and settling all selected requests in a lump sum. In addition, next to the remittance request remittance all-selection lump-sum settlement button is a remittance request remittance partial selection lump-sum settlement button BT20 labeled "Settle and send one item" for executing the remittance based on this remittance request and settling a portion of the unprocessed requests selected by the user from the unprocessed requests displayed in the remittance request information NC7 in a lump sum.

As a non-limiting example, in the remittance request information NC7, when the check box for the second received remittance request (payment of 3,500 yen to user B.B.) is checked "ON" and selected, and the remittance request partial selection lump-sum settlement button BT20 is tapped, a request is made from terminal 20A to server 10 to execute lump-sum settlement of the selected unprocessed requests. Then, settlement result information regarding the execution result is sent from server 10 to terminal 20B of user B.B., which is the other party, and terminal 20A of user A.A, which is our party.

FIG. 19-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the remittance request remittance partial lump sum settlement button BT20 is tapped.
In this example, in the notification information display area NTR2 of the notification screen, settlement result information NC8 and settlement result information NC9 are displayed below remittance request information NC7 as the contents of the lump-sum settlement.

The settlement result information NC8 displays, by way of example and not limitation, information regarding the fact that user A.A has executed a remittance of "3,500 yen" to user B.B through settlement of a payment of a remittance request amount of "3,500 yen" based on a past remittance request from user B.B.
The settlement result information NC9 displays, by way of example and not limitation, information regarding the fact that user A.A has executed a remittance of "500 yen" to user B.B through settlement of the payment of the remittance request amount "500 yen" in accordance with the current remittance request from user B.B.

The settlement result information displayed on User B.B's terminal 20B not only displays the receipt of remittance from User A.A, but also displays a list of User B.B's unprocessed requests in accordance with the display mode of remittance result information NC1.

FIG. 19-3 is another example of the display screen of FIG. 19-2.
In this example, in the notification information display area NTR2 of the notification screen, settlement result information NC10 is displayed below remittance request information NC7 as the contents of lump-sum settlement.

As an example, but not by way of limitation, the settlement result information NC10 shows that a lump-sum settlement has been made between user A.A and user B.B, and that user A.A has paid (transferred) 1,000 yen to user B.B as the lump-sum settlement amount, which is the sum of the remittance request amount of 3,500 yen from the previous remittance request received and the remittance request amount of 500 yen from the current remittance request received.

In addition, the settlement result information displayed on user B.B's terminal 20B may or may not display the contents of the lump-sum settlement together as a single settlement result information.

<Processing>
FIG. 19D is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
Based on the request from terminal 20B, the control unit 11 of the server 10 transmits the remittance request information from user B.B and the remittance request list information to terminal 20A via the communication I/F 14 (S420).
Then, the control unit 11 of the server 10 advances the process to S140.

The control unit 21 of the terminal 20A determines whether or not the remittance request information and the remittance request list information have been received from the server 10 via the communication I/F 22 (A405), and if it is determined that they have been received (A405: YES), it causes the display unit 24 to display a lump-sum settlement screen including this information (A425).

When it is determined in A131 that an unprocessed request has been selected (A131: YES), the control unit 21 of the terminal 20A proceeds to A132. That is, the control unit 21 sets request selection information including remittance information regarding a remittance based on the received remittance request information and unprocessed request selection information indicating the selected unprocessed request.
On the other hand, if it is determined in A131 that no unprocessed request has been selected (A131: NO), the control unit 21 of the terminal 20A proceeds to A133. That is, the control unit 21 sets request selection information including remittance information related to remittance based on the received remittance request information.

It should be noted that this process will be described on the assumption that remittance is carried out based on received remittance request information.
In reality, there may be cases where the choice is made to process only the outstanding request without making a remittance based on the received remittance request information; however, the processing in this case is similar to the processing for lump-sum settlement of outstanding requests described above, and therefore illustrations and repeated explanations will be omitted.

When it is determined in S141 that the unprocessed request is to be processed (S141: YES), the control unit 11 of the server 10 advances the process to S142.
On the other hand, when it is determined in S141 that the unprocessed request is not to be processed (S141: NO), the control unit 11 of the server 10 advances the process to S143.

<Effects of the 21st embodiment>
In this embodiment, the first information is remittance request information regarding a remittance request received from the other user, the second information is received remittance request information regarding a remittance request that has already been received from the other user, and the first process includes a process of remittance to the other user based on an input to a terminal 20 that displays the first display and the second display.
As an example of an effect of an embodiment obtained by such a configuration, money can be easily transferred between a first user and a second user based on an input to a terminal that displays a first display and a second display.

In this case, the other user is a single user, and the first process can include a process of transferring money to the other user based on an input to the terminal 20 displaying the first display and the second display.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to easily transfer money from one user (first user) to another user based on input to a terminal displaying the first display and the second display.

<Twenty-second Example>
The twenty-second embodiment is an embodiment relating to processing of the above-mentioned pattern (e).
The contents described in the twenty-second embodiment are applicable to the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In the case of (e) receiving a remittance request + sending a remittance request, either (e1) remittance + remittance reminder or (e2) [remittance + receipt] (amount can be deducted) can be processed.

In the process of (e1), a remittance is made to the other user based on the remittance request received from the other user, and a remittance reminder is also sent based on the remittance request already sent to the other user.
In this case, a new remittance request may or may not be made instead of a remittance reminder.

In the process of (e2), the user remits money to the other user based on the remittance request received from the other user, and receives money from the other user based on the remittance request already sent to the other user. In this case, the user can remit/receive the difference in the remittance request amount. Also, if the remittance request amounts are the same, the amounts can be offset.
In this case, the approval of the other user may be required, and the approval of the other user may or may not be obtained.

<Display screen>
Fig. 20-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.A. Details of the screen configuration can be configured similarly to Fig. 19-1 in the case where the sender of the remittance request is user C.C., by way of example and not limitation, and therefore a detailed description will be omitted.
In this case, the remittance request information when the sender of the remittance request is user C.C. is referred to as remittance request information NC11.

As a non-limiting example, in the remittance request information NC11, when the check box for the third sent remittance request (received 1,000 yen from user C.C.) is checked "ON" and selected, and the remittance request partial selection lump-sum settlement button BT21 is tapped, terminal 20A requests server 10 to execute lump-sum settlement of the selected unprocessed requests. Then, server 10 transmits settlement result information regarding the execution result to terminal 20C of user C.C., which is the other party, and terminal 20A of user A.A, which is our party.

FIG. 20-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E when the remittance request remittance partial selection lump-sum settlement button BT21 is tapped.
In this example, the notification information display area NTR1 of the notification screen displays settlement result information NC12 and settlement result information NC13 as the contents of the lump-sum settlement.

The settlement result information NC12 shows, by way of example and not by way of limitation, that based on this remittance request, user C.C. received the remittance request amount of "500 yen" for the remittance request to user A.A. Below that, by way of example and not by way of limitation, it shows that there are two unprocessed requests from user C.C.

As an example and not a limitation, the settlement result information NC13 displays a reminder corresponding to the third remittance request selected in FIG. 20-1 (a remittance request for the amount of 1,000 yen sent by user A.A to user C.C.).

FIG. 20-3 is another example of the display screen of FIG. 20-2.
In Fig. 20-3, when the third remittance request (received from user C.C. for 1,000 yen) is selected in the remittance request information NC11 and the remittance request partial selection lump-sum settlement button BT21 is tapped, the terminal 20A requests the server 10 to execute lump-sum settlement of the selected unprocessed requests. Then, the server 10 transmits lump-sum settlement approval confirmation information to the terminal 20C of the other party, user C.C., to confirm whether or not to approve the lump-sum settlement, and the information is displayed on the display unit 24 of the terminal 20C.

In FIG. 20-3, the notification information display area NTR1 of the notification screen displays lump-sum settlement approval confirmation information NC14 instead of settlement result information NC12 and settlement result information NC13.

The lump-sum settlement approval confirmation information NC14 displays the lump-sum settlement details, stating that user C.C. will pay the remittance request amount of "1,000 yen" based on the receipt of a previous remittance request from user A.A, and will receive the remittance request amount of "500 yen" based on the transmission of the current remittance request to user A.A.

The lump-sum settlement approval confirmation information NC14 also indicates that user C.C. will pay "500 yen" as the lump-sum settlement amount from user A.A., which is the sum of the remittance request amount of "500 yen" resulting from the transmission of this remittance request from "1,000 yen" received in the remittance request.

FIG. 20-4 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A when the settlement button BT22 in FIG. 20-3 is tapped.
In this example, in the notification information display area NTR2 of the notification screen, settlement result information NC15 is displayed as the contents of the lump sum settlement below remittance request information NC11.

In the settlement result information NC15, by way of example and not limitation, a lump sum settlement has been made between user A.A and user C.C., and the details of the lump sum settlement include the amount of the settlement result (in this example, the receipt of the remittance amount "500 yen" remitted by user A.A from user C.C.).
Further, under the contents of the lump sum settlement, the unprocessed requests of the user A.A are displayed, and under that, a "All Selected Lump Summary Settlement" button and a "Partial Selected Lump Summary Settlement" button are displayed.
As an example and not a limitation, the unprocessed requests displayed in the settlement result information NC15 are the three unprocessed requests displayed in the remittance request information NC11, excluding (deleting) the third sent remittance request that has been processed this time.

<Processing>
In this embodiment, the processes executed by each device can be realized in a similar manner to the processes in FIG. 19-4, and therefore illustrations and detailed descriptions thereof will be omitted.

<Effects of the 22nd embodiment>
In this embodiment, the first information is remittance request information regarding a remittance request sent from the other user to the proposer's user, and the second information is sent remittance request information regarding a remittance request that has already been sent from the proposer's user to the other user.
As an example of an effect of an embodiment obtained by such a configuration, processing based on a remittance request from a first user to a terminal user and a remittance request sent from the terminal user to a second user can be performed in a unified manner.

In this case, the first process may include a process of transferring money to the other user and sending a transfer reminder or a new transfer request to the other user based on an input to the terminal 20 on which the first and second displays are displayed.

In addition, the other user may be a single user, and the first process may include a process of transferring an amount to the other user or receiving an amount of money from the other user based on remittance request information regarding a remittance request sent from the other user to the proposer's user and sent remittance request information regarding a remittance request already sent from the proposer's user to the other user.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to transfer an amount based on the first information and the second information to the first user, or to receive money transferred from the first user.

Also, in this case, the first process may include a process of transferring to the other user an amount obtained by subtracting the remittance request amount included in the remittance request information regarding the remittance request already sent from the proposer's user to the other user from the remittance request amount included in the remittance request information regarding the remittance request sent from the proposer's user to the other user, or receiving from the other user an amount obtained by subtracting the remittance request amount included in the remittance request information regarding the remittance request sent from the proposer's user to the other user from the remittance request amount included in the remittance request information regarding the remittance request sent from the proposer's user to the other user.
As an example of the effect of the embodiment obtained by such a configuration, the difference amount can be remitted to the first user, or can be received by having the first user remit the difference amount.

In this case, the first process may be executed based on the consent of the other user, based on an input to the terminal 20 of the other user.
As an example of an effect of the embodiment obtained by such a configuration, the first process can be executed based on the input to the terminal of the first user and based on the approval of the first user, which can prevent the first process from being executed against the will of the first user, for example and not by way of limitation.

<Twenty-third embodiment>
The twenty-third embodiment is an embodiment relating to processing of a pattern different from the patterns described above.
The contents described in the twenty-third embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In addition to the above-mentioned patterns, by way of example and not limitation, the combination patterns of new processing targets in the table of FIG. 16-1, that is,
It is also possible to process the following pattern: receive + remittance request.

The processing of this pattern is the same as that of pattern (a). In other words, it is possible to perform "receive + remittance" processing.

<Effects of the 23rd embodiment>
In this embodiment, the first information is remittance result information from the other user (not limited to this, but an example of information related to a remittance from the first user to the user of the terminal), and the terminal 20 of the proposer's user receives remittance request information related to the remittance request sent from the other user to the proposer's user via the communication I/F 22, and displays a third display based on the received remittance request information on the display unit 24. The terminal 20 of the proposer's user is configured to execute a remittance process (not limited to this, but an example of the second process) via the control unit 21 based on an input by the proposer's user to the terminal 20 displaying the third display.
As an example of an effect of the embodiment obtained by such a configuration, a second process related to remittance can be performed based on an input by a terminal user to the terminal displaying the third display.

<Twenty-fourth Example>
The twenty-fourth embodiment is an embodiment relating to processing of a pattern different from the patterns described above.
The contents described in the twenty-fourth embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In addition to the above-mentioned patterns, by way of example and not limitation, the following combination patterns of unprocessed requests in the table of FIG. 16-1, i.e.
It is also possible to process the pattern of received remittance requests + sent remittance requests.

The processing of this pattern is the same as that of pattern (e). That is, either "remittance + remittance reminder" or "remittance + receipt (amount can be deducted)" can be performed.
In addition, when performing the process of "[Send + Receive] (amount can be deducted)", approval of the other user is required, and it is possible to either obtain approval from the other user or not.

<Effects of the 24th embodiment>
In this embodiment, the second information is received remittance request information regarding a remittance request already received from the other user, and based on the reception of a remittance request from the other user, a fourth display based on sent remittance request information regarding a remittance request already sent from the proposer's user to the other user is displayed on the display unit 24. Then, based on an input by the proposer's user to the terminal 20 on which the second display and the fourth display are displayed, the control unit 21 performs a third process regarding remittance, receipt, or a remittance request (remittance reminder).
As an example of an effect of an embodiment obtained by such a configuration, a third process related to remittance, receiving remittance, or requesting remittance can be performed by the control unit based on input by a user of the terminal to a terminal on which the second display and the fourth display are displayed.

In this case, the third process may include a process of transferring money to the other user and sending a transfer request or a transfer reminder to the other user based on the input on the second display and the fourth display.
As an example of an effect of the embodiment obtained by such a configuration, it is possible to simultaneously perform remittance to the second user and a request for remittance to the second user.

In addition, in this embodiment, the other user is a single user, and the third process includes a process of transferring an amount based on the received remittance request information and the sent remittance request information to the other user, or receiving money from the other user.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to remit an amount based on the second information and the fourth information to the second user, or to receive remittance from the second user.

In this case, the third process may include a process of transferring to the other user an amount obtained by subtracting the remittance request amount included in the transmitted remittance request information from the remittance request amount included in the received remittance request information, or a process of receiving from the other user an amount obtained by subtracting the remittance request amount included in the received remittance request information from the remittance request amount included in the transmitted remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, the difference in amount can be remitted to the second user, or can be received by having the second user remit the amount.

In this case, the third process can be executed based on the approval of the other user, based on an input to the terminal 20 of the other user.
As an example of an effect of the embodiment obtained by such a configuration, the third process can be executed based on the second user's approval based on an input to the second user's terminal, which can prevent the third process from being executed against the second user's will, for example and not by way of limitation.

<Twenty-fifth Example>
The twenty-fifth embodiment is an embodiment relating to processing of a pattern different from the patterns described above.
The contents described in the twenty-fifth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

As a non-limiting example, the "receipt" of the new processing target in the table of FIG. 16A can be changed to "rejection of receipt."
"Rejection of receipt" refers to the recipient user refusing to receive the remittance amount.

in this case,
It is possible to process one of the following patterns: - Receipt refusal + received remittance request - Receipt refusal + sent remittance request - Receipt refusal + received remittance request + sent remittance request

In the case of a rejection of receipt + a received remittance request, only the remittance can be processed.
In the case of a rejected payment + a sent remittance request, the only processing that can be performed is sending a remittance reminder (or a new remittance request).
In the case of a combination of a refusal to receive + a received remittance request + a sent remittance request, the process of [remittance + receipt] (amount can be deducted) can be performed.

<Twenty-sixth Example>
The twenty-sixth embodiment is an embodiment relating to a method for displaying remittance request information.
The contents described in the twenty-sixth embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<Display screen>
21-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is, by way of example and not by way of limitation, a notification screen of a payment application displayed on the display unit 24 of the terminal 20A of user A.
In the notification information display area NTR2 of the notification screen, remittance result information NC16 is displayed as the content related to the receipt of remittance (acceptance of remittance).
The remittance result information NC16 displays, by way of example and not limitation, the content corresponding to the receipt of the remittance amount "1,000 yen" remitted (received) by user A.A from user B.B.

Below that is a list of remittance requests that are pending for the user to whom the remittance was sent (user A.A. in this example) at the time the remittance was received. In the upper right corner of the remittance request list is a remittance request history sort button STB2 for changing the display order of pending remittance requests. The other display aspects are the same as the remittance result information NC1.

When the remittance request history sort button STB2 is touched, a sort selection area for selecting a sort order is displayed, by way of example and not limitation, from the bottom of the screen.
Based on user operations on the sort selection area, the display order of unprocessed remittance requests can be rearranged and displayed in ascending/descending order, for example but not limited to, by the date the remittance request was sent/received, or by the remittance request amount of the remittance request.

In addition, it is also possible to rearrange and display the order in which unprocessed remittance requests are displayed, so that they are displayed in the order of the date and time that the remittance requests were sent/received, instead of in the order of the date that the remittance requests were sent/received.

FIG. 21-2 shows an example of a display screen in which unprocessed remittance requests in the remittance result information NC16 are sorted in descending order by remittance request amount based on a user operation on the sort selection area, and is not intended to be limiting.

In Figure 21-1, the unprocessed remittance requests in remittance result information NC16 are sorted in ascending order by date, but in Figure 21-2, they are sorted in descending order by remittance request amount.

When a payment deadline is set for a remittance request, by way of example and not by way of limitation, the remittance requests may or may not be displayed in the order in which their payment deadline approaches. Setting a payment deadline includes, by way of example and not by way of limitation, setting a repayment deadline for a loan from a financial institution (CtoB) in addition to payments between individuals (CtoC).

In addition, remittance requests in which the amount or reason for the remittance request is related to a user other than the user who made the remittance request and the user to whom the remittance request was made may be displayed preferentially. As a non-limiting example, this is the case when other users are included as members of a split payment arrangement.

In addition, although it has been stated that unprocessed remittance requests are displayed in the remittance result information and remittance request information, this is not limiting. As a non-limiting example, processed remittance requests may be displayed in a different display format, such as grayed out, mixed in with unprocessed remittance requests, or may not be displayed in this way.

<Effects of the 26th embodiment>
In this embodiment, the terminal 20 of the user of the proposer displays on the display unit 24 a fourth display based on remittance request information regarding a received remittance request that the user of the proposer has received from the other user (not limited to, an example of the fourth information regarding a remittance request sent from a second user to the user of the terminal) or on remittance request information regarding a sent remittance request that the user of the proposer has sent to the other user (not limited to, an example of the fourth information regarding a remittance request sent from the user of the terminal to the second user).The terminal 20 of the user of the proposer shows a configuration in which the second display and the fourth display are displayed on the display unit 24 in an order based on the above-mentioned second information and the above-mentioned fourth information.
As an example of an effect of the embodiment obtained by such a configuration, the second display and the fourth display can be displayed in an appropriate order based on the second information and the fourth information.

In addition, this embodiment shows a configuration in which the above-mentioned second information and fourth information include information regarding the date when the remittance request was sent/received (not limited to this, but an example of information regarding the date), or information regarding the date and time when the remittance request was sent/received (not limited to this, but an example of information regarding the date and time), and the order in which the second display and the fourth display are displayed is determined based on this information regarding the date or the date and time.
As an example of an effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on information related to the date and time or date, it is possible to realize a display that is intuitively easy for the user to understand.

Furthermore, in this embodiment, the second information and fourth information include information regarding the amount of the remittance request (not limited to this, but an example of information regarding the amount), and the order in which the second display and the fourth display are displayed is determined based on this information regarding the amount.
As an example of the effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on the information regarding the amount, it is possible to realize a display that is intuitively easy for the user to understand.

In this case, the information regarding the amount of the remittance request may include, in addition to the remittance request amount, information regarding the payment deadline, for example and not by way of limitation.
As an example of the effect of an embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on information regarding the payment deadline, it is possible to realize a display that is intuitively easy for the user to understand.

<27th Example>
The twenty-seventh embodiment is an embodiment in which a chat service (chat application) is applied.
The contents described in the 27th embodiment are applicable to any of the other embodiments and the other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

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

22-1 is a diagram showing an example of a screen displayed on the display unit 24 of the terminals 20A to 20C in this embodiment. This screen is, by way of example and not by way of limitation, a group chat screen (in this example, a chat screen for "Group X") of a messaging application displayed on the display unit 24 of the terminal 20 of each user.
The name of the messaging application is displayed in the center of the top of the screen as "Messaging App." Also, an icon image and the user name of the messaging application of the user of terminal 20 are displayed in the top right of the screen.

Below this is a current location display area that shows the current location in the messaging application. In this example, the word "Group X" is displayed in the current location display area, indicating that the current location is in a group chat for "Group X" in the messaging application.

Below the current location display area, a message display area for displaying group chat messages (contents) is displayed. The message display areas on the display units 24 of the terminals 20A to 20C are designated as message display area MSG1 to message display area MSG3, respectively.
In the message display area, messages sent from the user's own terminal are displayed in a balloon on the right side, while messages sent from terminals other than the user's own terminal are displayed in a balloon on the left side together with the icon of the sender.

As an example and not a limitation, consider the case where user B.B. makes a money transfer request to user A.A. for the amount of "1,000 yen" by way of example and not a limitation, using a money transfer request sending function within a messaging application.

Then, remittance request information MC1 is displayed in the message display area MSG1 of the terminal 20A.
The remittance request information MC1 displays, by way of example and not limitation, the content corresponding to the remittance request of "1,000 yen" received by user A.A from user B.B. In addition, below the remittance request, a remittance request button and a remittance request rejection button are displayed.
Below that is a list of pending remittance requests between the user who sent the remittance request (user B.B. in this example) and the user who received the remittance request (user A.A. in this example) at the time the remittance request was received.
In addition, at the bottom of the remittance request information MC1, a remittance request remittance all-selection lump-sum settlement button labeled "All Settlements and Remittance" is displayed to execute the remittance based on this remittance request and the all-selection lump-sum settlement.

Moreover, remittance request information MC2 is displayed in the message display area MSG2 of the terminal 20B.
The remittance request information MC2 displays, by way of example and not limitation, the content corresponding to the remittance request of "1,000 yen" sent by user B.B to user A.A. In addition, below that, the remittance request remit button and the remittance request reject button are displayed in a grayed-out manner and disabled.
Below that is a list of pending remittance requests between the user who sent the remittance request (user B.B. in this example) and the user who received the remittance request (user A.A. in this example) at the time the remittance request was received.
At the bottom of the remittance request information MC2, an all-selection lump-sum settlement button labeled "Settle all" is displayed for executing lump-sum settlement of all selected items.

Remittance request information MC3 is displayed in a message display area MSG3 of terminal 20C.
The remittance request information MC3 displays, by way of example and not limitation, the content corresponding to the remittance request of "1,000 yen" sent by user B.B to user A.A. In addition, below that, the remittance request remit button and the remittance request reject button are displayed in a grayed-out manner and disabled.
Also, below that, a list of pending remittance requests between the user who sent the remittance request (user B.B. in this example) and the user who received the remittance request (user A.A. in this example) is not displayed because A.A. is not a party to these remittance requests.

Note that unprocessed remittance requests from parties other than the parties may or may not be displayed in the remittance request information.

FIG. 22-2 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A based on a user operation of swiping (swiping operation) the remittance request information MC1 from right to left (touching the screen with a finger and sliding the finger), by way of example and not limitation.
In FIG. 22-2, by way of example and not limitation, a settlement details confirmation area ACR9 is displayed rising from the bottom of the display unit 24 of the terminal 20A in FIG. 22-1.

At the top of settlement content confirmation area ACR9, a display is displayed indicating that User A.A has received a remittance request from User B.B, and that there are two outstanding remittance requests (unsettled requests) between User A.A and User B.B.

In addition, at the bottom of the settlement content confirmation area ACR9, a confirmation message is displayed indicating that when user A.A makes a lump-sum settlement of all selected remittance requests with user B.B, the lump-sum settlement amount will be "5,000 yen", which is the sum of the currently received remittance request amount of "1,000 yen" and the previously received remittance request amounts of "3,500 yen" and "500 yen". Also displayed below this are a remittance request remittance all-selection lump-sum settlement button BT23 marked "OK" for executing the remittance request remittance all-selection lump-sum settlement, and a cancel button marked "Cancel" for canceling the remittance request remittance all-selection lump-sum settlement.

In addition, even when the remittance request remittance all-select lump-sum settlement button in the remittance request information MC1 is tapped, the settlement details confirmation area ACR9 may or may not be displayed.

FIG. 22-3 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A when the remittance request remittance all-select lump-sum settlement button BT23 is tapped in the settlement content confirmation area ACR9 of FIG. 22-2.
In FIG. 22-3, in the message display area MSG1, remittance result information MC4 is displayed below remittance request information MC1 based on the remittance results of the remittance process by remittance request and the remittance process by all selection lump sum settlement.

The upper part of the remittance result information MC4 shows the details of the settlement, that is, User A.A paid (transferred) the remittance request amount of "1,000 yen" to User B.B, and paid (transferred) "4,000 yen" as the lump-sum settlement amount for the outstanding remittance requests.

The bottom of the remittance result information MC4 shows that User A.A. remitted "5,000 yen" as the settled amount, which is the sum of the remittance request amount of "1,000 yen" and the lump-sum settlement amount of "4,000 yen."

It should be noted that the display corresponding to the remittance result information MC4 may or may not be displayed on terminals 20 other than terminal 20A and terminal 20B.
Also, only the remittance result at the bottom of the remittance result information MC4 may or may not be displayed on terminals 20 other than terminals 20A and 20B which are the parties involved.

FIG. 22-4 is a diagram showing an example of a screen in which unprocessed remittance requests are not displayed in the remittance request information MC1.
As a non-limiting example, when a user taps a pending request hide button BT24 indicated by an x in the remittance request information MC1, a pending request display cancel confirmation field DRR1 is displayed rising from the bottom of the message display field MSG1.

When a remittance or remittance request is made, the pending request display cancellation confirmation area DRR1 displays an "OK" button to cancel the pending request display so that the remittance request information and remittance result information do not display a list of pending remittance requests between the user who made the remittance request (remittance) (e.g. user B.B.), and an "Cancel" button to continue displaying the list.

As an example and not by way of limitation, when the cancel pending request display button in the cancel pending request display confirmation area DRR1 is tapped by the user, the list of pending remittance requests with this user (e.g., user B.B.) will no longer be displayed in any remittance request information or remittance result information received thereafter.

Similarly, if the unprocessed request hide button in the remittance request information MC2 is tapped by user B.B and then the unprocessed request display cancel button in the unprocessed request display cancel confirmation area is tapped, the list of unprocessed remittance requests with user A.A will no longer be displayed in the remittance request information or remittance result information received thereafter.

When the Cancel Unprocessed Request Display button in the Cancel Unprocessed Request Display confirmation area is tapped, the list of unprocessed remittance requests may or may not be displayed in the remittance request information and remittance result information received thereafter between all users.

In other words, in this embodiment, the unprocessed requests are configured to be hidden based on input by the user of the terminal 20 to the input section.

In addition, instead of doing as described above, the display/non-display setting for unprocessed requests may or may not be made possible on a setting screen (not shown) or the like, as described above.

<Effects of the 27th embodiment>
In this embodiment, the terminal 20 of the proposer's user displays on the display unit 24 a talk room (not limited to, an example of a chat room) including at least the proposer's user (not limited to, an example of a user of the terminal) and the other user (not limited to, an example of a first user).The first display and second display indicate the configuration displayed in this talk room.
As an example of an effect of the embodiment obtained by such a configuration, the first information and the second information can be notified to the user of the terminal in an easy-to-understand manner by displaying them in a chat room.

In this case, the second display displayed in the talk room can also be hidden based on an input to the terminal 20 by the user who makes the proposal.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to secure a large space for the display area.

In this case, the talk room may include a user other than the parties involved (not limited to, an example of a third user), and the second display may be displayed in the talk room displayed on the terminal 20 of a user other than the parties involved.
As an example of the effect of an embodiment obtained by such a configuration, a second display based on second information regarding a remittance request sent from the second user to the user of the terminal, or regarding a remittance request sent from the user of the terminal to the second user, i.e., information regarding a user who is a party to the remittance, can be made unavailable for viewing by a third user who is a user other than the parties involved.

In this case, the talk room displayed on the terminal 20 of the user other than the party includes a fifth display that is different from the second display and is based on remittance request information regarding the remittance request sent from the user other than the party, or on the remittance request information regarding the remittance request sent to the user other than the party. The fifth display can be made not to be displayed in the talk room displayed on the terminal 20 of the user of the proposer.
As an example of the effect of an embodiment obtained by such a configuration, it is possible to prevent the user of the terminal from viewing a fifth display that is different from the second display and is based on fifth information regarding a remittance request sent from a third user or regarding a remittance request sent to the third user, i.e., information in which the third user is a party to the remittance.

In this case, the first display can be prevented from being displayed in the talk room displayed on the terminal 20 of a user other than the person involved.
As an example of an effect of an embodiment obtained by such a configuration, it is possible to prevent a third user from viewing a first display based on first information regarding a remittance from a first user to a user of the terminal, or regarding a remittance request sent from the first user to the user of the terminal, i.e., information regarding the user who is a party to the remittance.

Furthermore, in this embodiment, the first display and the second display are displayed on the display unit 24 by a messaging application installed on the terminal 20 of the proposer's user, and the messaging application is included in the program related to the present disclosure.
As an example of an effect of the embodiment obtained by such a configuration, the first display and the second display can be displayed on the display unit of the terminal by an application installed on the terminal.

＜Other＞
In the above embodiment, received remittance request information and sent remittance request information are exemplified as unprocessed information related to remittance requests.

However, even if these pieces of information are replaced with remittance reminder information, the same processing as in the above embodiment can be applied. In other words, without distinguishing between remittance requests and remittance reminders, received remittance reminder information and sent remittance reminder information can be applied as unprocessed information related to remittance requests.
This is because a remittance request and a remittance reminder can be treated as synonymous.

In addition, remittance request information and remittance reminder information can be combined in any way. In other words, the following four combinations of received information and sent information are possible:

(1) First Combination: Received: Remittance Request Information; Sent: Remittance Request Information. This combination is the combination described in the above embodiment.

(2) Second combination: Received: remittance request information Sent: remittance reminder information

(3) The third combination: Received: remittance reminder information Sent: remittance request information

(4) Fourth combination: Received: remittance reminder information Sent: remittance reminder information

Reference Signs List 1 Communication system 10 Server 20 Terminal 30 Network

Claims (24)

A program executed by a server in communication with a terminal,
transmitting, by a communication unit of the server, first information regarding a remittance from a first user to a user of the terminal, or regarding a remittance request sent from the first user to the user of the terminal, to the terminal;
transmitting, to the terminal by the communication unit, second information relating to a remittance request transmitted from a second user to the user of the terminal based on the transmission of the first information, or relating to a remittance request transmitted from the user of the terminal to the second user;
The server executes a first process related to a remittance or a request for a remittance based on an input by a user of the terminal to the terminal on which a first display based on the first information and a second display based on the second information are displayed, using a control unit of the server . The program according to claim 1,
The first information is information regarding a remittance from the first user to a user of the terminal,
the second information is information regarding a remittance request transmitted from the second user to the user of the terminal;
The first process includes a process of transferring money to the second user based on an input to the terminal on which the second display is displayed. The program according to claim 2,
The first process includes a process of receiving an amount transferred from the first user to a user of the terminal based on an input to the terminal on which the first display is displayed after the first display is displayed on the terminal. The program according to claim 1,
The first information is information regarding a remittance from the first user to a user of the terminal,
The second information is information relating to a remittance request sent from a user of the terminal to the second user. The program according to claim 4,
The first process includes a process of transmitting a remittance request to the second user based on an input to the terminal on which the second display is displayed. The program according to claim 1,
the second user is the first user,
the first information is information regarding a remittance request transmitted from the first user to a user of the terminal;
the second information is information regarding a remittance request transmitted from a user of the terminal to the second user;
The first process includes a process of transferring an amount based on the first information and the second information to the first user or to a user of the terminal. The program according to claim 6,
The first information includes information of a first amount,
The second information includes information of a second amount,
The first process includes a process of transferring an amount obtained by subtracting the second amount from the first amount to the first user, or transferring an amount obtained by subtracting the first amount from the second amount to a user of the terminal. The program according to claim 6 or 7,
The first process is executed based on approval by the first user based on an input to a terminal of the first user. The program according to claim 1,
the first information is information regarding a remittance request transmitted from the first user to a user of the terminal;
the second information is information regarding a remittance request transmitted from the second user to the user of the terminal;
The first process includes a process of transferring money to the first user and the second user based on an input to the terminal that displays the first display and the second display. The program according to claim 9,
the second user is the first user,
The first process includes a process of transferring money to the first user based on an input to the terminal displaying the first display and the second display. The program according to claim 1,
the first information is information regarding a remittance request transmitted from the first user to a user of the terminal;
The second information is information relating to a remittance request sent from a user of the terminal to the second user. The program according to claim 11,
The first process includes a process of transferring money to the first user and sending a transfer request to the second user based on an input to the terminal on which the first display and the second display are displayed. The program according to claim 11,
the second user is the first user,
The first process includes a process of transferring an amount based on the first information and the second information to the first user or to a user of the terminal. The program according to claim 13,
The first information includes information of a first amount,
The second information includes information of a second amount,
The first process includes a process of transferring an amount obtained by subtracting the second amount from the first amount to the first user, or transferring an amount obtained by subtracting the first amount from the second amount to a user of the terminal. The program according to claim 13 or 14,
The first process is executed based on approval by the first user based on an input to a terminal of the first user. The program according to claim 1,
The first information is information regarding a remittance from the first user to a user of the terminal,
transmitting third information related to a remittance request transmitted from a first user to a user of the terminal by the communication unit to the terminal;
The server causes the control unit to carry out a second process relating to remittance based on an input by a user of the terminal to the terminal displaying a third display based on the third information. The program according to claim 1,
the second information is information regarding a remittance request transmitted from the second user to the user of the terminal;
transmitting, to the terminal by the communication unit, fourth information related to a remittance request transmitted from the user of the terminal to the second user based on the transmission of the first information;
The server executes, via the control unit, a third process related to a remittance or a request for a remittance based on input by a user of the terminal to the terminal on which the second display and a fourth display based on the fourth information are displayed. 18. The program according to claim 17,
The third process includes a process of transferring money to the second user and sending a remittance request to the second user based on inputs to the second display and the fourth display. 18. The program according to claim 17,
the second user is the first user,
The third process includes a process of transferring an amount based on the second information and the fourth information to the second user or to a user of the terminal. 20. The program of claim 19,
The second information includes information of a second amount,
The fourth information includes information of a fourth amount,
The third process includes a process of transferring an amount obtained by subtracting the fourth amount from the second amount to the second user, or transferring an amount obtained by subtracting the second amount from the fourth amount to the user of the terminal. The program according to claim 19 or 20,
The third process is executed based on approval by the second user based on an input to a terminal of the second user. An information processing method for a server communicating with a terminal, comprising:
transmitting, by a communication unit of the server, first information regarding a remittance from a first user to a user of the terminal, or regarding a remittance request sent from the first user to the user of the terminal, to the terminal;
transmitting, to the terminal by the communication unit, second information relating to a remittance request transmitted from a second user to the user of the terminal based on the transmission of the first information, or relating to a remittance request transmitted from the user of the terminal to the second user;
The method includes carrying out a first process related to a remittance or a request for a remittance by a control unit of the server based on an input by a user of the terminal to the terminal on which a first display based on the first information and a second display based on the second information are displayed. A server that communicates with a terminal,
a communication unit that transmits to the terminal first information relating to a remittance from a first user to a user of the terminal, or a remittance request transmitted from the first user to the user of the terminal, and transmits to the terminal second information relating to a remittance request transmitted from a second user to the user of the terminal, or a remittance request transmitted from the user of the terminal to the second user, based on the transmission of the first information;
and a control unit that performs a first process related to a remittance or a request for a remittance based on an input by a user of the terminal to the terminal on which a first display based on the first information and a second display based on the second information are displayed. A system including a terminal and a server in communication with the terminal,
a communication unit of the server that transmits to the terminal first information on a remittance from a first user to a user of the terminal, or a remittance request transmitted from the first user to the user of the terminal, and transmits to the terminal second information on a remittance request transmitted from a second user to the user of the terminal, or a remittance request transmitted from the user of the terminal to the second user, based on the transmission of the first information;
a display unit of the terminal that displays a first display based on the first information and a second display based on the second information;
and a control unit of the server that performs a first process related to a remittance or a request for a remittance based on an input by a user of the terminal to the terminal on which the first display and the second display are displayed.

Images