JP7417482B2 - Programs, information processing methods, terminals - Google Patents

Description

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

2. Description of the Related Art Recently, services that enable management of electronic money (electronic money) of terminals or users of terminals, remittances/receipts, etc., are becoming widespread using applications that can be executed on terminals such as smartphones. For example, Patent Document 1 discloses a technique for settling the purchase price of a product.

Japanese Patent Application Publication No. 2002-176671

According to a first aspect of the present invention, a program executed by a terminal is configured to perform a remittance request based on first information regarding a remittance from a user of the terminal to a first user or regarding a remittance request sent from a user of the terminal to a first user. 1 display and a second display based on second information regarding a remittance request sent from a second user to a user of the terminal or regarding a remittance request sent from a user of the terminal to a second user on a display section of the terminal. and a control unit of the terminal to perform a first process related to remittance, receipt of remittance, or request for remittance based on the input by the terminal user to the terminal on which the first display and the second display are displayed. What you do is performed by the terminal.
According to a second aspect of the present invention, an information processing method for a terminal includes a first information processing method based on first information regarding a remittance from a user of the terminal to a first user or a remittance request transmitted from a user of the terminal to a first user. and a second display based on second information regarding the remittance request sent from the second user to the user of the terminal or regarding the remittance request sent from the user of the terminal to the second user on the display section of the terminal. and, based on the input by the user of the terminal to the terminal on which the first display and the second display are displayed, the control unit of the terminal performs a first process regarding remittance, receiving remittance, or requesting remittance. including doing.
According to a third aspect of the present invention, the terminal displays a first display based on first information regarding a remittance from a user of the terminal to a first user or a remittance request transmitted from a user of the terminal to the first user; a display unit that displays a second display based on second information regarding a remittance request sent from the second user to the terminal user, or based on second information regarding the remittance request sent from the terminal user to the second user; and a control unit that performs a first process related to remittance , receipt of remittance, or request for remittance based on input to the terminal on which the first display and the second display are displayed.
According to a fourth aspect of the invention, the terminal includes a processor that reads a program stored in the memory and performs processing based on the program, and the processor is configured to perform processing related to remittance from a user of the terminal to a first user, or A first display based on first information regarding a remittance request sent from a user of the terminal to a first user, and a first display based on first information regarding a remittance request sent from a second user to a user of the terminal, or regarding a remittance request sent from a user of the terminal to a second user. A second display based on second information regarding the remittance request is displayed on the display section of the terminal, and based on an input by the terminal user to the terminal on which the first display and the second display are displayed, regarding the remittance, or performing a first process related to receiving a remittance or requesting a remittance.

FIG. 1 is a diagram illustrating an example of a configuration of a communication system in one aspect of an embodiment. FIG. 3 is a diagram illustrating an example of functions realized by the control unit of the server according to the first embodiment. FIG. 3 is a diagram showing an example of information stored in a storage unit of the server according to the first embodiment. FIG. 3 is a diagram showing an example of user registration data according to the first embodiment. The figure which shows an example of the user management database based on 1st Example. The figure which shows an example of remittance request management data based on 1st Example. FIG. 3 is a diagram illustrating an example of functions realized by the control unit of the terminal according to the first embodiment. FIG. 3 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. The figure which shows an example of the display screen of the terminal based on 1st Example. 5 is a flowchart illustrating an example of a process flow of a terminal and a server according to the first embodiment. 5 is a flowchart showing an example of the flow of payment processing according to the first embodiment. The figure which shows an example of the table for demonstrating the lump sum payment based on 1st Example. 5 is a flowchart illustrating an example of a process flow of a terminal and a server according to the first embodiment. 5 is a flowchart showing an example of the flow of payment processing according to the first embodiment. The figure which shows an example of the display screen of the terminal based on the 1st modification. The figure which shows an example of the display screen of the terminal based on the 1st modification. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a second embodiment. 7 is a flowchart illustrating an example of the processing flow of a terminal and a server according to the second embodiment. 7 is a flowchart illustrating an example of the processing flow of a terminal and a server according to the second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a third embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a third embodiment. The figure which shows an example of the display screen of the terminal based on 4th Example. The figure which shows an example of the display screen of the terminal based on 4th Example. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fifth embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal and a server according to a fifth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a sixth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a sixth embodiment. 12 is a flowchart illustrating an example of the flow of batch remittance request creation processing according to the sixth embodiment. The figure which shows an example of the display screen of the terminal based on 7th Example. The figure which shows an example of the display screen of the terminal based on 7th Example. 12 is a flowchart showing an example of the flow of payment processing according to the seventh embodiment. 12 is a flowchart showing an example of the flow of payment processing according to the seventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eighth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eighth embodiment. 10 is a flowchart illustrating an example of the processing flow of a terminal and a server according to an eighth embodiment. 12 is a flowchart illustrating an example of a processing flow of a terminal and a server according to an eighth modification. FIG. 9 is a diagram showing an example of a table for explaining a processing method according to a ninth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a ninth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a ninth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a ninth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a ninth embodiment. 10 is a flowchart illustrating an example of the processing flow of a terminal and a server according to a ninth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a tenth embodiment. 10 is a flowchart showing an example of the processing flow of a terminal and a server according to a tenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eleventh embodiment. 11 is a flowchart showing an example of the processing flow of a terminal and a server according to an eleventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twelfth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a thirteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a sixteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a seventeenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a seventeenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a seventeenth embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal and a server according to a seventeenth embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal and a server according to a seventeenth embodiment. 12 is a flowchart illustrating an example of a processing flow of a terminal and a server according to a seventeenth modification. FIG. 7 is a diagram showing an example of a table for explaining a processing method according to an eighteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eighteenth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to an eighteenth embodiment. 12 is a flowchart showing an example of the processing flow of a terminal and a server according to the 18th embodiment. The figure which shows an example of the display screen of the terminal based on 19th Example. The figure which shows an example of the display screen of the terminal based on 19th Example. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twentieth embodiment. 10 is a flowchart illustrating an example of the processing flow of a terminal and a server according to the 20th embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-first embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-first embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-first embodiment. 12 is a flowchart illustrating an example of a process flow of a terminal and a server according to a twenty-first embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-second embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-sixth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-sixth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-seventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-seventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-seventh embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a twenty-seventh embodiment.

<Compliance with legal matters>
Please note that the disclosures described herein are subject to compliance with the host country's legal requirements necessary for the implementation of the disclosures, such as confidentiality of communications.

Embodiments for implementing programs and the like according to the present disclosure will be described with reference to the drawings.

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

<System configuration>
FIG. 1-1 is a diagram showing an example of the system configuration of the communication system 1 in this embodiment.
In the communication system 1, by way of example and not 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 terminals 20 owned by users via the network 30. Server 10 may also be referred to as a payment management server, payment service server, messaging server, messaging service server, or the like. In this embodiment, by way of example and not limitation, the user of the server 10 is a payment service provider or a messaging service provider.

The terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ) may be any information processing terminal that can implement the functions described in each embodiment. Terminal 20 may include, by way of example and not limitation, a smartphone, a mobile phone (feature phone), a computer (by way of example and not limitation, a desktop, laptop, tablet, etc.), a media computer platform (by way of example and not limitation, a cable, satellite set, etc.). top boxes, digital video recorders), handheld computing devices (by way of example and not limitation, personal digital assistants, e-mail clients, etc.), wearable terminals (glass-like devices, watch-like devices, etc.), VR (Virtual Reality) including a terminal, smart speaker (speech recognition device), or other type of computer or communication platform. Further, the terminal 20 may be expressed as an information processing terminal.

The configurations of terminal 20A, terminal 20B, and terminal 20C are basically the same. Further, if necessary, the terminal used by user X may be expressed as terminal 20X, and the user information in a predetermined service associated with user X or terminal 20X may be expressed as user information X.
Note that the user information is user information associated with an account used by the user in a predetermined service. User information includes, by way of example and not limitation, the user's name, the user's icon image, the user's age, the user's gender, the user's address, and the user's hobbies, entered by the user or provided by a predetermined service. It includes information associated with the user such as preferences and user identifiers, and may be any one or a combination of these, or may not be the same.

The network 30 plays a role of connecting one or more terminals 20 and one or more servers 10. That is, the network 30 refers to a communication network that provides a connection path so that the various devices described above can transmit and receive data after being connected.
Note that 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 a wired network or a wireless network. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (wireless LAN: WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, public switched telephone network (Public Switched Telephone Network (PSTN), mobile phone network, ISDN (integrated service digital networks), wireless LAN, LTE (long term evolution), CDMA (code division multiple access), Bluetooth (registered trademark), satellite communication, etc., or a combination of two or more of these. Network 30 may include one or more networks 30.

The server 10 (not limited to, but an example of a server, an information processing device, or an information management device) has a function of providing a predetermined service (in this embodiment, a payment service, a messaging service, etc.) to the terminal 20. The server 10 may be any information processing device that can implement the functions described in each embodiment. Server 10 may include, by way of example and not limitation, a server device, a computer (such as, by way of example and not limitation, a desktop, laptop, tablet, etc.), a media computer platform (by way of example and not limitation, a cable, satellite set-top box, digital video recorder, etc.). ), handheld computing devices (by way of example and not limitation, PDAs, email clients, etc.), or other types of computers or communication platforms. Further, the server 10 may be expressed as an information processing device. If there is no need to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be each expressed as an information processing device.

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

(1) HW configuration of terminal FIG. 1-1 shows an example of the HW configuration of the terminal 20.
The terminal 20 includes a control section 21 (CPU: central processing unit), a storage section 28, a communication I/F 22 (interface), an input/output section 23, a clock section 29A, and a position calculation information detection section 29B. . Each component of the HW of terminal 20 is interconnected via bus B, by way of example and not limitation. Note that it is not essential that the HW configuration of the terminal 20 includes all the components. By way of example and not limitation, terminal 20 may or may not be configured to have individual components or components removed.

The communication I/F 22 transmits and receives various data via the network 30. Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 22 has a function of communicating 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. Furthermore, the communication I/F 22 receives various data transmitted from various devices such as the server 10 and transmits the received data to the control unit 21 . Moreover, the communication I/F 22 may be simply expressed as a communication section. In addition, when the communication I/F 22 is composed of a physically structured circuit, it may be expressed as a communication circuit.

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

The input unit is realized by any one or a combination of all types of devices that can receive input from the user and transmit information related to the input to the control unit 21. The input unit includes, by way of example and not limitation, 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 via voice).

The output unit is realized by any one of all types of devices capable of outputting the processing results processed by the control unit 21 or a combination thereof. Output units include, by way of example and not limitation, a touch panel, a touch display, a speaker (audio output), a lens (including, by way of non-limiting example, three dimensions output or hologram output), a printer, and the like.

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

The display unit 24 is realized by any one or a combination of all types of devices capable of displaying data according to the display data written in the frame buffer. The display unit 24 may include, by way of example and not limitation, a touch panel, a touch display, a monitor (including, but not limited to, a liquid crystal display or an OELD (organic electroluminescence display)), a head mounted display (HDM), a projection mapping, and a hologram. , devices capable of displaying images, text information, etc. in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.

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

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

The clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information). The clock section 29A includes, by way of example and not limitation, a clock using a crystal oscillator. The clock section 29A can also be expressed as a clock section or a time information detection section, by way of example and not limitation.

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

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

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

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

The inertial measurement unit has an inertial sensor that is a sensor that detects information necessary for calculating the position of the terminal 20 by inertial navigation calculation. Inertial sensors include, by way of example and not limitation, a 3-axis acceleration sensor and a 3-axis gyro sensor, and use the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as position calculation information. Output.

By way of example and not limitation, the UWB positioning unit is an ultra-wideband RF (Radio Frequency) signal that converts into a digital signal an ultra-wideband RF (Radio Frequency) signal including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon that is received by an antenna (not shown). It includes 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 wideband RF reception circuit and the ultra-wideband RF reception circuit.
Note that, by way of example and not limitation, the UWB positioning unit may 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). You don't have to do that.

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

The control unit 21 has a physically structured circuit for executing functions realized by codes or instructions included in a program, and includes, by way of example and not limitation, a data processing device built into hardware. This is realized by Therefore, the control unit 21 may or may not be expressed 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 ASIC (application-specific integrated circuit), and a FPGA (field programmable). gate array).

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

In the terminal 20, the program P is stored in the storage unit 28, and by executing the program P, the control unit 21 executes processing as each unit included in the control unit 21. That is, the program P stored in the storage unit 28 causes the terminal 20 to 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. 1-1 shows an example of the HW configuration of the server 10.
The server 10 includes a control section 11 (CPU), a storage section 15, a communication I/F 14 (interface), an input/output section 12, and a clock section 19. The HW components of server 10 are interconnected via bus B, by way of example and not limitation. Note that the HW of the server 10 does not necessarily include all the components as the HW configuration of the server 10 . By way of example and not limitation, the HW of server 10 may or may not be configured to allow removal of individual components, or multiple components.

The control unit 11 has a physically structured circuit for executing functions realized by codes or instructions included in a program, and includes, by way of example and not limitation, a data processing device built into hardware. This is realized by

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

The storage unit 15 has a function of storing various programs and various data necessary for the operation of the server 10. The storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. 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. Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 14 has a function of 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. Further, the communication I/F 14 receives various data transmitted from various devices such as the terminal 20 and transmits the received data to the control unit 11. Moreover, the communication I/F 14 may be simply expressed as a communication section. Furthermore, when the communication I/F 14 is composed of a physically structured circuit, it may be expressed as a communication circuit.

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

The output unit is realized by any one of all types of devices capable of outputting the processing results processed by the control unit 11 or a combination thereof. Output units include, by way of example and not limitation, a touch panel, a touch display, a speaker (audio output), a lens (including, by way of non-limiting example, three dimensions output or hologram output), a printer, and the like.

As a primary embodiment, the input/output section 12 includes a display section 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)). Note that the display unit 13 may or may not be a head mounted display (HDM). Note that 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 includes, by way of example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, and the like. The clock section 19 can also be expressed as a timekeeping section or a time information detection section, by way of example and not limitation.

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

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

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

Further, the program P (by way of example, but not limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may be provided in a state stored in a computer-readable storage medium, or It doesn't have to be done. The storage medium can store the program P in a "non-temporary tangible medium". Further, the program P may or may not be for realizing a part of the functions of each embodiment of the present disclosure. Furthermore, it may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded on a storage medium.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs), such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), a hard・Disk drive (HDD), hybrid hard drive (HHD), optical disk, optical disk drive (ODD), magneto-optical disk, magneto-optical drive, floppy diskette, floppy disk drive (FDD), magnetic tape, solid state (SSD), a RAM drive, a secure digital card, or any other suitable storage medium, or a suitable combination of two or more thereof. Storage media may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. Note that the storage medium is not limited to these examples, and may be any device or medium as long as it can store the program P. Further, the storage medium may or may not be expressed as a memory.

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

Further, the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium (communication network, broadcast waves, etc.) that can transmit the program. . By way of example and not limitation, the server 10 and/or the terminal 20 realize the functions of the plurality of functional units shown in each embodiment by executing a program P downloaded via the Internet or the like.
The same applies to other devices.

Furthermore, each embodiment of the present disclosure may be implemented in the form of a data signal in which the program P is embodied by electronic transmission.
At least part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
At least part or all of the processing in the terminal 20 may or may not be performed by the server 10. In this case, at least some 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 part or all of the processing in the server 10 may be performed by the terminal 20, or may not be performed. In this case, at least some 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 configuration of the determination in the embodiments of the present disclosure is not essential, and a predetermined process may be performed when the determination condition is met, or a predetermined process is performed when the determination condition is not met. You may or may not.

Note that the program of this disclosure uses, by way of example and not limitation, a scripting language such as ActionScript or JavaScript (registered trademark), a compiler language such as Objective-C or Java (registered trademark), or a markup language such as HTML5. Implemented.

An embodiment in which the present invention is implemented by a server-client system will be described below.

However, the present invention is not limited to a server-client system, and it is also possible to implement the present invention by a system that does not include a server. This is, by way of example and not limitation, a system such as:
- A system (distributed system) in which the terminal 20 has a server function. This can be accomplished using blockchain technology, by way of example and not limitation.
- A system in which terminals 20 communicate wirelessly with each other. This can be achieved, by way of example and not limitation, by communicating in a P2P (peer-to-peer) manner using short-range wireless communication technology such as Bluetooth.

Furthermore, in the following, the expression "by communication I/F" will be used as appropriate. This indicates, by way of example and not limitation, that the device transmits and receives various information and data via the communication I/F (via the communication unit) based on the control of the control unit (processor, etc.) .

<Summary>
In recent years, applications (application software) related to network services include applications for making payments using electronic money (payment applications), applications for making payments using electronic money (payment applications), and applications for sending and receiving electronic money. Applications such as applications for transferring money (remittance applications) and applications that aggregate some or all of the functions of these applications are becoming popular, and users of the terminal 20 can use these applications to transfer electronic money (electronic money). It has become possible to receive various services using money.

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

Note that electronic money may or may not be expressed as "electronic money" or "digital currency (digital money)."
Further, legal currency or virtual currency may be used as "electronic money" or "digital currency".
Furthermore, "electronic money (electronic money)" and "digital currency (digital money)" may include cryptocurrencies (cryptoassets).
Further, virtual currency may include physical money such as coupons.

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

Furthermore, hereinafter, a request from a user of the terminal 20 to a user of a different terminal 20 (another user) to make a remittance will be 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 is sometimes expressed as "requesting a remittance", "making a remittance request", etc.
Further, being requested to remit money may be expressed as "remittance request is made", "remittance request is made", etc.

Furthermore, sending a remittance request is expressed as "sending a remittance request", "sending a remittance request", etc., which are substantially synonymous.
Conversely, receiving a remittance request is expressed as "receiving a remittance request", "receiving a remittance request", etc., but these terms are substantially synonymous.

Furthermore, in the following, the term "remittance reminder" means to remind, recall, reconfirm, etc. the content of the remittance request to the other user, and the information regarding this remittance reminder is referred to as "remittance reminder information". It is called.
Remittance reminders are sometimes expressed as "remittance reminder", "remittance reminder", etc.
Furthermore, being reminded to remit money may be expressed as "being reminded to remit", "remitting remittance being performed", etc.

In addition, the remittance request information (the same applies to remittance reminder information) includes at least information indicating that a remittance has been requested, information on the user who is the remittance requester (remittance requester), and information on the user to whom the remittance is requested. It's fine if you can.

As will be described later, 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"), etc. It can also be included in remittance request information.

Further, in the following description, it will be assumed that various processes according to the present invention are executed by an application (a payment application or a messaging application) installed on the terminal 20.

Additionally, a payment application may have a function of a chat service (by way of example, but not limited to, a messaging service), or a payment application may have a function of a payment service as a function of a chat application (by way of example, but not limited to, a messaging application). You can also do it like this.

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 will be referred to as a "talk room" as appropriate. Further, the talk room may be referred to as a chat room.

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

Further, the messaging service may or may not include an instant messaging service (IMS) that enables the transmission and reception of content such as simple messages between the terminals 20.

Note that there is also a way of thinking that messaging service: MS (including IMS) is regarded as one form (one form) of social networking service: SNS.
For this reason, a messaging service (MS) and a social networking service (SNS) may or may not be distinguished.

<Example>
Examples to which the present invention is applied will be described below.
Requests for remittances (remittance requests) from the other user (first user) to you (user of the device) and requests for remittances (remittance requests) from yourself to the other user (remittance requests) are not processed, and multiple remittance requests are sent to the terminal. It may accumulate to 20. By way of example and not limitation, this may be the case if you inadvertently forget to process a money transfer request.

In this case, attempting to process each unprocessed remittance request one by one takes time and is inconvenient. Furthermore, if the unprocessed remittance requests are processed one by one, the user's balance may run out.

Therefore, a method for collectively processing multiple remittance requests (here, multiple unprocessed remittance requests) will be described. This batch processing is referred to as "batch processing."
Broadly speaking, batch processing can include at least the following processing.
(1) Processing related to lump-sum settlement (hereinafter referred to as "lump settlement") (2) Processing related to offset of remittance requests (hereinafter referred to as "request offset") (3) Processing related to lump-sum remittance request (hereinafter referred to as "request offset") (4) Processing related to the creation of special lump sum payment (hereinafter referred to as "special lump sum payment") ・Special lump sum remittance request (hereinafter referred to as "special lump sum remittance request") processing related to the creation of

Furthermore, 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, when the other user is a plurality of different users, that is, the first user is a different user from the second user (the second user is a user different from the first user). In this case, the method described below can be similarly applied.

<First example>
The first embodiment is an example related to batch payment of the batch processing described above.
The content described in the first embodiment is applicable to each of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

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

FIG. 1-3 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The storage unit 15 includes, by way of example and not limitation, a payment application management processing program 151 that 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 requests. management data 157 is stored.

The user registration data 153 is registration data regarding the terminal 20 that uses the payment application or the user of the terminal 20, and an example of the data structure is shown in FIGS. 1-4.
The user registration data 153 stores, by way of example and not limitation, a user name, an application ID, a terminal telephone number, and other registration information in association with each other.

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

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

The terminal phone number is the phone number of the terminal 20 of the user with this user name, 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 includes, by way of example and not limitation, the ID of the terminal 20: terminal ID (IMEI (International Mobile Equipment Identity), by way of example and not limitation), the email address of the terminal 20 of the user with this user name (terminal email address ), authentication information such as passwords (login password, authentication password) used for various types of authentication in payment applications.

The identification information for identifying the terminal 20 may be, by way of example and not limitation, a terminal ID.
Further, the identification information for identifying the user of the terminal 20 may be an application ID, by way of example and not limitation. Note that this may or may not be used as a "user ID."

In addition, if the application allows only one account to be registered for one terminal 20, it is not limited, but as an example, "Identification information for identifying the terminal 20 = Identification information for identifying the user of the terminal 20 = Application ID".

Further, as an example and not a limitation, it may be possible to assign a plurality of terminal IDs to one user ID, or it may not be necessary to do so.

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

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

The user management database 155 is a database that cumulatively stores data for managing information regarding the terminal 20 that uses the payment application or its users. Shown in Figure 1-5.

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

The remittance history data is data in which information on the history of remittances (remittance history information) from a user with this application ID to a user with another application ID is stored.

The received money history data is data in which information on the history of money received by the user of this application ID from users of other application IDs (received money history information) is stored.

The remittance request management data 157 is a database that cumulatively stores data for managing information regarding remittance requests, and an example of the configuration of the first remittance request management data 157A is shown in FIG. 1-6.
The first remittance request management data 157A stores, by way of example and not 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 completed flag in association with each other. be done.

The date and time stores, by way of example and not limitation, the date and time when the remittance request information of the corresponding remittance request was transmitted from the server 10 to the terminal 20 of the remittance request destination user.

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

The application ID of the user who requested the remittance (also referred to as the remittance master user) is stored in the remittance master ID.
The remittance request destination ID stores an application ID of a user who is requested to make a remittance (also referred to as a remittance request destination user).

The remittance request amount stores the amount of money requested to be remitted from the remittance master user to the remittance request destination user according to the remittance request.

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

The following two patterns can be considered as methods for the server 10 to manage remittance requests.
(1) Pattern A: The remittance request that executed the remittance is left without being deleted.
(2) Pattern B: Delete the remittance request that executed the remittance.

Either of these patterns can be applied, but when pattern A is applied, the data of the remittance request with the remittance completed flag set to "ON" is left without being deleted.
On the other hand, when applying pattern B, the record of the data of the remittance request that executed the remittance is deleted.

(2) Terminal FIGS. 1-7 are diagrams showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
Control unit 21 includes, by way of example and not limitation, payment application processing unit 211 as a functional unit that executes payment application processing according to payment application processing program 281 stored in storage unit 28 .

FIG. 1-8 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment.
The storage unit 28 stores, by way of example and not limitation, a payment application processing program 281 read by the control unit 21 and executed as payment application processing, and an application ID 283 associated with the own terminal 20 or its user. be done.

<Display screen>
Below, as an example and not a limitation, a case where the terminal 20 is a smartphone including the display section 24 of a vertically long display will be exemplified.

By way of example and not limitation, a smartphone is provided with a touch panel that functions as an input unit and is placed opposite its display, thereby forming a touch screen. When an element such as an icon, button, item, or input area is displayed on the display, if a part of the touch panel that is opposite to the area where the element is displayed is operated by the user, The program associated with the element or a subroutine of that program is executed.

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

Note that the transition of the display screen described below is only an example of the transition of the display screen for realizing the method of the present disclosure. Regarding the transition of display screens illustrated below, display of some display screens may be omitted, or other display screens may be added.

FIG. 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 shown by way of example and not limitation for user A. This is the main menu screen of the payment application displayed on the display unit 24 of A's terminal 20A.

At the top center of the menu screen, the words "Payment App" are displayed as the name of the payment application. Further, at the top right of the screen, an icon image and a user name (user AA in this example) of the payment application of the user of this terminal 20 are displayed.

Further, below that, a current location display area CLR1 is configured that indicates the current location in the payment application, and in this example, the characters "Wallet Main Menu" indicating that the current location is the main menu of the payment application are displayed. , is displayed within the current position display area.

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 the terminal 20A to the server 10, and from the server 10 to the terminal 20A, Remittance request list information will be sent. As a result, by way of example and not limitation, a remittance request list screen as shown in FIG. 1-10 is displayed.

In the current position display area CLR1, characters "Remittance request list" indicating that remittance request list information is displayed are displayed.

This remittance request list screen displays unprocessed remittance requests between users of different terminals 20 (hereinafter referred to as "unprocessed requests") as remittance requests regarding the user of the own terminal 20 (user AA). are displayed for each user of different terminals 20.

Hereinafter, a user who proposes to perform batch processing will be appropriately referred to as a "proposer user."
Further, the user to whom batch processing is proposed by the proposer user will be appropriately referred to as the "other user."

Specifically, user B. B. User C. C. User D. D. User E. For multiple users such as E, if you associate the icon image and user name of each user and process the number of unprocessed requests with that user and the unprocessed requests with that user at once. The payment amount (hereinafter referred to as the "lump payment amount") is displayed.

Here, the amount that you will pay to the other party in response to a remittance request requested by the other party is appropriately referred to as the "payment amount", and the amount that you will receive from the other party in response to the remittance request that you request to the other party is appropriately referred to as "receipt". ``amount''.
In this case, the "lump payment amount" is the sum of the payment amount and receipt amount corresponding to each unprocessed request, with the signs reversed, when all 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, by way of example and not limitation.

In addition, in this display screen example, a payment mark is displayed next to the lump-sum payment amount to indicate that it is a "payment" when you pay the lump-sum payment amount to the other party. When receiving the lump-sum payment amount from, a receipt mark indicating "receipt" is displayed in association with the payment.

By way of example and not limitation, user A. A (self) is user B. If there are four unprocessed requests with B (the other party) and these four unprocessed requests are processed all at once, user A. A is user B. It is shown that "1,000 yen" will be paid to B as a lump sum settlement amount.

Similarly, by way of example and not limitation, user A. A (self) is user C. If there are four unprocessed requests with C (the other party) and these four unprocessed requests are processed at once, then user A. A is user C. It is shown that "4,000 yen" will be received from C as the lump sum settlement amount.

Further, at the bottom of the screen, a settlement button BT1 for requesting the server 10 to settle all unprocessed requests at once is displayed.

In this screen, by way of example and not limitation, user C. When the display area WR1 of C is tapped, the remittance request details screen shown in FIG. 1-11 is displayed. This remittance request details screen shows user C. Details of outstanding requests to and from C are displayed.

Batch settlement is to perform settlement at once based on multiple unprocessed requests.As an example and not a limitation, there are "all selected batch settlement" which settles all unprocessed requests at once, and unprocessed requests. This includes ``partial selection lump sum settlement'', in which a portion or multiple of the above items are settled at once.

In the current position display area CLR1 at the top of the screen, user C. The words "Remittance request with C.C" indicating that an unprocessed request with C is displayed are displayed.
Further, below the current position display area CLR1, user C. In association with the icon image and user name of C, the lump-sum payment amount (in this example, "4,000 yen") and mark (in this example, "receipt mark") will be displayed, assuming that all selections are made at once. ing.

User C. Next to the icon image of C, there is a check area ASR1 configured so that the check can be turned on/off by tapping, and when the check is turned on, a check mark is displayed in the check area. It is configured so that all unprocessed requests can be settled at once.

Below that, the other party is user C. A list of remittance requests named C is displayed. In this example, the other party is user C. Unprocessed requests labeled as C are listed in chronological order from top to bottom, and below the list of unprocessed requests, processed requests (hereinafter referred to as "processed requests") are listed in chronological order from top to bottom. Listed in series. Additionally, processed requests are displayed in a different display format (grayed out in this example) to distinguish them from unprocessed requests.

Hereinafter, a remittance request that you have already sent to the other party will be referred to as a "sent remittance request," and a remittance request that you have already received from the other party will be referred to as a "received remittance request."
In this case, the sent request mark will be displayed for the sent remittance request among the unprocessed requests, and will be displayed as "Request received" for the received remittance request among the unprocessed requests. A request reception mark is displayed.

In addition, each unprocessed request includes the date and time when the request was sent from the user's terminal 20 to the other user's terminal 20 for a sent remittance request, and the date and time when the request was sent from the user's terminal 20 for a received remittance request. The dates and times when the terminal 20 received the terminal 20 from the terminal 20 of the other user are displayed in association with each other.

In addition, each unprocessed request is displayed in association with the reason for remittance based on the unprocessed request, by way of example and not limitation.

Note that the information on the remittance request amount may not be included in the remittance request information and the information on the remittance request amount may not be displayed. In this case, by way of example and not limitation, the proposer user may inquire of the server 10 or the other party's user for information on the remittance request amount.

Further, 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 remittance request individual screen. In addition, in this case, by way of example and not limitation, based on input to confirm the details of the remittance request on the individual remittance request screen, the remittance request details screen including information on the remittance request amount may be displayed. It may also be displayed.

Note that the same applies to other information regarding the remittance request, such as information on the reason for remittance.

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

Also, next to each unprocessed request, there is a check area SR1 configured so that the check can be turned on/off by tapping. A check mark is displayed, and the unprocessed requests can be selected for bulk payment.

Further, at the bottom of the screen, a settlement button BT2 is displayed for requesting the server 10 to collectively settle the selected unprocessed requests.

Note that in FIG. 1-11, processed requests are displayed along with unprocessed requests, but processed requests may not be displayed.

As an example and not a limitation, two requests, the third sent remittance request (receipt 10,000 yen) and the fourth received remittance request (payment 3,000 yen), are checked as "ON". When the payment button BT2 is selected and the payment button BT2 is tapped, a display as shown in FIG. 1-12 is displayed.

In FIG. 1-12, bulk payment confirmation information is displayed at the bottom of the screen in FIG. 1-11 to allow the user to confirm the contents of the bulk payment. In this example, within the electronic money account balance display area WBR1 that includes the text "Wallet Balance", there is provided a payment details confirmation area ACR1 that shows how the current electronic money account balance will change due to batch payment. ing.

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

In this example, user A. A's current electronic money account balance is "500 yen."
When the two requests selected above are settled at once, user A. For A, the ``receipt of 10,000 yen'' and the ``payment of 3,000 yen'' result in a ``receipt of 7,000 yen.'' Therefore, by adding the lump sum settlement amount of ``7,000 yen'' to the current electronic money account balance of ``500 yen'', the electronic money account balance after settlement will be ``7,500 yen''. There is.

FIG. 1-13 is a diagram showing an example of a notification screen of a payment application that is displayed based on the suggestion button BT3 being tapped on the above screen. This announcement screen is for user A. A's counterpart, user C. It is an example of the screen displayed on the display part 24 of terminal 20C of C.

When the proposal button BT3 is tapped on the screen displayed on the display unit 24 of the terminal 20A in FIG. 1-12, the terminal 20A requests the server 10 to perform a lump sum payment. Then, from the server 10, the other party, user C. Lump-sum payment approval confirmation information for confirming whether or not to approve the lump-sum payment is sent to the terminal 20C of C, and displayed on the display unit 24 of the terminal 20C.

A current position display area CLR2 is configured at the top of this notification screen, and the characters "Notice" are displayed to indicate that a notification regarding the payment application is being displayed.

Below the current position display area CLR2, user A. As a notification indicating that a settlement proposal for a remittance request has been received from A's terminal 20A, a notification NT1 including a bell mark and the words "A proposal for settlement of a remittance request has been received" is displayed.

Furthermore, a notification information display area NTR1 for displaying notification information is configured below it, and information corresponding to the above-mentioned notification NT1 is displayed in this notification information display area NTR1.
In this example, the bulk payment approval confirmation information includes the text "Payment proposal" and the other user A. The icon image of A and the lump sum payment amount are displayed. In this example, user C. C is user A. It is displayed that it is necessary to pay "7,000 yen" to A.

In addition, the lump sum payment approval confirmation information includes a link LK1 that displays the text "Confirm details" to confirm the details of the lump sum payment. If you tap this link LK1, you can check the details of the lump sum payment. It is configured so that the content (by way of example and not limitation, the breakdown) can be confirmed.

In addition, instead of displaying the details of the lump sum payment from the link LK1 of "Check details", as an example and not a limitation, the details of the lump sum payment can be displayed in a manner that can be switched in the left/right direction or in the depth direction. You can do it like this. An example of this includes, by way of example and not limitation, a carousel display.
This method is equally applicable to any of the embodiments.

In addition, the bulk payment approval confirmation information includes a payment button that says "Pay" to approve the payment with the above content, and a payment button that says "Decline" to decline the payment without approving the payment with the above content. The rejected button is displayed.

When the above link LK1 is tapped, a screen as shown in FIG. 1-14 is displayed, by way of example and not limitation.
This screen is displayed on the remittance request list screen displayed on the display unit 24 of the terminal 20C. This screen displays a list of unprocessed requests with A. This screen corresponds to the screen displayed on the display unit 24 of the terminal 20A shown in FIG. 1-12.

In the current position display area CLR2, user A. The words "Remittance request with A.A" indicating that an unprocessed request with A is being displayed are displayed.

In the payment details confirmation area ACR2 at the bottom of the screen, as an example and not a limitation, the current electronic money account balance of yourself (user C.C.) is displayed on the left, and the balance of your electronic money account after payment is displayed on the right. Ru.
Also, below that, there is a payment button BT4 that says "Payment" for approving the payment, along with the text "Do you want to pay with this content?", and a payment button BT4 that allows you to propose corrections to the payment without approving the payment. A modification proposal button labeled "Revision Proposal" for making the modification is displayed.

In this example, user C. C's current electronic money account balance is "11,000 yen."
And user A. When the two requests proposed by A are settled together, user C. For C, the ``payment of 10,000 yen'' and the ``receipt of 3,000 yen'' result in a ``payment of 7,000 yen.'' Therefore, by subtracting the lump-sum settlement amount "7,000 yen" from the current electronic money account balance "11,000 yen," the electronic money account balance after settlement will be "4,000 yen." has been done.

FIG. 1-15 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT4.
In this example, user C. Since the lump-sum payment was made with C, two pieces of payment result information are displayed as the contents of the lump-sum payment.
Specifically, by way of example and not limitation, settlement result information corresponding to each of the third remittance request and the fourth remittance request selected in FIGS. 1-11 and 1-12 is displayed.

In each payment result information, an individual amount is displayed together with "request payment" and the icon image of the other user.

Note that instead of displaying the payment result information corresponding to each selected remittance request, as an example and not a limitation, the payment result information is displayed together as a result of batch payment, as shown in Figure 1-16. You can also make it appear.

By way of example and not limitation, when the detailed confirmation link LK2 included in the payment result information in FIG. 1-16 is tapped, a screen as shown in FIG. 1-17 is displayed.
In the current position display area CLR1 of this screen, the words "Request Settlement" are displayed, indicating that the result of a lump sum settlement is being displayed.

Below the current position display area CLR1, user C. The lump sum payment amount (in this example, "7,000 yen") and mark (in this example, a "receipt mark") of the batch payment that has been executed are displayed in association with the icon image and user name of C.
Below that, remittance requests processed through bulk payment are listed.

Furthermore, an electronic money account balance display area WBR1 is displayed at the bottom of the screen.
In this electronic money account balance display area WBR1, the words "wallet balance" are displayed, and below it is a settlement result balance display area ARR1 that shows how your electronic money account balance has changed due to bulk settlement. is displayed.

In the settlement result balance display area ARR1, by way of example and not limitation, the current electronic money account balance of oneself (user A.A) is displayed on the left side, and the own electronic money account balance as a result of batch settlement is displayed on the right side. .
Furthermore, below that, the text "Two requests have been settled." is displayed as a text indicating that the bulk settlement has been performed.

In this example, user A. It is shown that A's electronic money account balance changed from "500 yen" to "7,500 yen" due to the batch 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 realizing the technique of the present disclosure, and are not limited to these processes.
Further, another step may be added to the processing described below, or some steps may be omitted (deleted).
This is the same for each flowchart (process) 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 side, the processing executed by the control unit 21 of the terminal 20A, the process executed by the control unit 21 of the terminal 20B, and the process executed by the control unit 11 of the server 10 are shown, respectively.
By way of example and not limitation, user A. of terminal 20A. A is user B of terminal 20B. A case will be exemplified in which a request is made to collectively process remittance requests made with B.
In this process, for the sake of simplicity, determination of whether the process is complete is omitted.

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

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

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

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

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

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

If it is determined that the batch payment is to be made (S1510: YES), the control unit 11 of the server 10 sends the remittance request amount of the selected remittance request and the type of each selected remittance request (received remittance request). The lump-sum settlement amount is calculated based on (payment)/sent remittance request (receipt)) (S1515).

Thereafter, the control unit 11 of the server 10 determines whether or not the electronic money account balance of at least one of the proposer's user and the other party's user becomes negative based on the calculated lump-sum settlement amount ( S1520).

If it is determined that the amount is negative (S1520: YES), the control unit 11 of the server 10 transmits, by way of example and not limitation, batch payment NG information indicating that batch payment 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 payment process.

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

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

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

The control unit 11 of the server 10 determines whether to perform payment based on whether payment execution request information has been received from the terminal 20A through the communication I/F 14 (S1530). If it is determined that the payment is to be performed (S1530: YES), the control unit 11 of the server 10 executes the batch payment (S1540).

FIG. 1-20 is a diagram showing an example of a table for explaining lump-sum payment.
In this table, the types of unprocessed requests of the user who is proposing the lump sum payment (in this processing example, user A.A) are shown vertically and horizontally, and the other user (in this processing example, user B.B) is shown as one person. This figure shows a process in which two unprocessed requests are settled at once based on a proposal by a user who is a proposer.
The vertical and horizontal unprocessed requests include received remittance requests and sent remittance requests, respectively.

(1-1) Combination of received remittance request and received remittance request In this combination, the proposer user (user A.A) has received two unprocessed remittance requests from the other user (user B.B). Transfer money to the other user based on one remittance request.

In this case, the control unit 11 of the server 10 performs a process of remitting the amount obtained by adding the remittance request amounts of the two received remittance requests from the proposer user to the other user as the lump sum settlement amount in the lump sum settlement. Execute. Specifically, the control unit 11 of the server 10 subtracts the lump sum settlement amount from the proposer's user's electronic money account balance and updates it, and adds the lump sum settlement amount to the other user's electronic money account balance and updates it. do.

(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 receives the remittance request from the other party's user. Based on completed and unprocessed remittance requests and unprocessed remittance requests that have been sent to the other user, remittances are made to/receive from the other user. In this case, since there is a relationship between payment and receipt, 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 between the remittance request amounts (subtracting the amount) will be referred to as "amount deduction."

Note that the amount deduction includes amount offset (hereinafter referred to as "amount offset").
Amount offset means, by way of example and not limitation, that the amounts cancel each other out and become zero by subtracting amounts between remittance requests selected for processing.
Amount offset is when the deduction is zero out of the amount deductions.

In this example, if the remittance request amount (the amount to be sent) of the received remittance request is the same as the remittance request amount (the amount to be received) of the sent remittance request, the amount will be offset. will be done.

In this case, if the remittance request amount (second amount) of the received remittance request is larger than the remittance request amount (first amount) of the sent remittance request, the control unit 11 of the server 10 controls the remittance request of the received remittance request. The amount obtained by subtracting the remittance request amount of the sent remittance request from the amount (third amount) is calculated as the lump sum settlement amount. Then, the lump sum settlement amount is subtracted from the proposer's user's electronic money account balance for updating, and the lump sum settlement amount is added to and updated to the opponent user's electronic money account balance.

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

Furthermore, if the remittance request amount (second amount) of the received remittance request and the remittance request amount (first amount) of the sent remittance request are the same amount, the amounts are offset and no remittance is performed.

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

(1-4) Combination of sent remittance request and sent remittance request In this combination, the user who proposes the lump sum payment based on two unprocessed remittance requests (sent remittance requests) addressed to the other user. Then, a new remittance request that combines these into one is sent to the other user.

This remittance request is a type of remittance request that combines multiple remittance requests (hereinafter referred to as a "batch remittance request"), and is used for purposes such as encouraging remittance of the amount that has already been requested. It is something that will be done.
For convenience, this remittance request is referred to as a "confirmation lump sum 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. Then, the control unit 11 of the server 10 transmits confirmation lump sum remittance request information corresponding to the created confirmation lump sum remittance request to the terminal 20 of the other user.

In addition, in this combination (1-4), the control unit 11 of the server 10 transmits the selected plurality of sent remittance requests instead of transmitting the confirmation bulk remittance request information to the terminal 20 of the other user. The remittance reminder information corresponding to each of the above may or may not be transmitted to the terminal 20 of the other user.

In addition, in the combination (1-4), the user who proposes the lump sum payment (in this processing example, user A.A) requests the other user (in this processing example, user B.B) to complete the unprocessed 2 You may or may not receive money from the other user based on one remittance request.

In this case, the control unit 11 of the server 10 performs a process of remitting the sum of the remittance request amounts of the selected sent remittance requests from the other party's user to the proposer's user as the lump-sum settlement amount in the lump-sum settlement. Execute. Specifically, the control unit 11 of the server 10 subtracts the lump sum settlement amount from the other party's electronic money account balance and updates it, and adds the lump sum settlement amount to the proposer user's electronic money account balance and updates it. do.

Strictly speaking, making a confirmation lump sum remittance request (sending confirmation lump sum remittance request information) and sending a remittance reminder (sending remittance reminder information) are different in meaning and concept from "settlement". You can also do it.
However, in this specification, for the sake of simplicity, these are also illustrated and explained as being included in the payment (a type of payment).

Returning to FIG. 1-19, after executing the batch payment in S1540, the control unit 11 of the server 10 ends the first payment process.

On the other hand, if it is determined that the payment target is not a bulk payment target, that is, there is only one remittance request selected (S1510: NO), the control unit 11 of the server 10 controls the electronic money account of the proposer's user. It is determined whether the balance becomes negative (S1570). If it is determined that the value is negative (S1570: YES), the control unit 11 of the server 10 transmits payment NG information indicating that the payment cannot be made to the terminal 20A via the communication I/F 14, by way of example and not limitation. (S1573).
Then, the control unit 11 of the server 10 ends the first payment process.

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

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

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

The control unit 11 of the server 10 determines whether to perform payment based on whether payment execution request information has been received from the terminal 20A through the communication I/F 14 (S1580). If it is determined to execute (S1580: YES), the control unit 11 of the server 10 executes the payment (S1590).
Then, the control unit 11 of the server 10 ends the first payment process.

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

When receiving the payment result information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A displays the received payment result information on the display unit 24 (A190).
Then, the control unit 21 of the terminal 20A ends the process.

Similarly, when the communication I/F 22 receives payment result information from the server 10, the control unit 21 of the terminal 20B displays the received payment result information on the display unit 24 (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 performing bulk payment, it is also possible to require the approval of the other user. This is because the following cases are possible.

(A) A case where a malicious user wants to profit from bulk payment This can be said to be an unavoidable problem in a system where remittance requests can be created by user operations.

By way of example and not limitation, a malicious user may send a false remittance request to another 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 making a lump sum payment. More specifically, by way of example and not limitation, user A. A is user B. When user A receives a remittance request for a predetermined remittance request amount (for example, "3,000 yen") from user B. User A creates a remittance request with the same amount as the remittance request amount (for example, "3,000 yen") and sends it to user B. After sending it back to user A. This is a case where a lump sum settlement is performed by A.

In addition to this, it is also possible that a malicious user slips a false remittance request into a remittance request. Specifically, this is a case where several false remittance requests are created and sent without the other user's knowledge, and the false remittance requests are used to perform bulk payment.

In these cases, if the other user's approval is not required, the other user will be deceived.

(B) A case where a bulk payment is made against the other party's wishes This is an example, not a limitation, in which a lump sum payment is made that includes at least one remittance request among the remittance requests that have already been sent to the other party's user. This may cause the other user to feel that they have suffered a loss because the remittance request, which is a remittance (payment) for the other user, is included in the lump sum settlement.
However, if all remittance requests are processed, the end result is the same, as long as legitimate remittance requests are processed.

In any of the above cases, the other user's approval is required in order for the other user to confirm whether the remittance request that is subject to bulk payment is a legitimate remittance request (whether it is really correct). It can be done.

FIG. 1-21 is a flowchart showing another example of the flow of processing executed by each device in this embodiment. The view of the figure is the same as that of Figure 1-18.
In this process, the control unit 11 of the server 10 executes a second payment process in S150.

FIG. 1-22 is a flowchart showing an example of the flow of the second payment process.
If it is determined in S1530 that a bulk payment execution request has been made (S1530: YES), the control unit 11 of the server 10 determines whether approval from the other user is required (S1531). Specifically, by way of example and not limitation, in the remittance request management IDs of the selected two or more remittance requests, the associated remittance master ID is the user A. A's application ID, and the associated remittance request destination ID is user A.A's application ID. Whether or not the remittance request management ID, which is the application ID of a user other than A, is included, that is, whether a remittance request from the other party (user B.B) to the proposer's user (user A.A) is included. Determine.

If it is determined that the approval of the other user is required (S1531: YES), the control unit 11 of the server 10 asks the other user (in this example, user B.B. ), lump sum payment approval confirmation information including lump sum payment amount information is transmitted to the terminal 20B via the communication I/F 14 (S1533).

The control unit 21 of the terminal 20B determines whether or not the bulk payment approval confirmation information has been received from the server 10 via the communication I/F 22 (B150), and if it is determined that the information has been received (B150: YES), the received bulk payment The payment approval confirmation information is displayed on the display unit 24 (B160).

Thereafter, the control unit 21 of the terminal 20B determines whether to approve the lump sum payment based on whether an input to approve the lump sum payment 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 payment approval information indicating that the lump sum payment 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 payment has been approved by the other user based on whether the lump sum payment approval information has been received from the terminal 20B via the communication I/F 14 ( S1535). If it is determined that the request has been approved (S1535: YES), the process moves to S1540.

<First processing by terminal)>
The first process, which is executed by the control unit of the terminal and is based on the first information and the second information, includes, by way of example and not limitation, a request from the proposer user (the terminal user) to the other party's user (the first Processing that is related in some way to remittances to users (users, secondary users), and processing that is related in some way to the proposing user receiving (receiving) the amount remitted from the other user. can. The first process can include not only processes directly related to remittances and receipts, but also processes indirectly related to remittances and receipts.

By way of example and not limitation, the first process includes at least the following processes.
・Processing for selecting a remittance request ・Processing for notifying the server 10 of the selected remittance request ・Processing for acquiring payment confirmation information from the server 10 and displaying it on the display unit 24 ・Requesting the server 10 to execute payment Processing - Processing of acquiring payment result information from the server 10 and displaying it on the display unit 24 - Processing of requesting the server 10 to deduct the amount (including offset of the amount) - Creation of a bulk remittance request for confirmation to the server 10 Processing requested

<Input to the terminal, etc.>
In the above process, the input to the terminal or the input by the user of the terminal is an operation input to the input unit (operation unit), but the present invention is not limited to this.

As an example and not a limitation, instead of or in addition to the operation input to the input unit (operation unit), it may be possible to input sound (including voice) to the input unit (sound input unit 25). You don't have to.
This also applies to other inputs to the terminal and other inputs by the user of the terminal.

<Effects of the first embodiment>
According to this embodiment, by way of example and not limitation, a plurality of remittance requests can be processed at once, thereby improving convenience for the user.
Furthermore, by way of example and not limitation, remittances and receipts can be made within a range that does not exceed the user's balance, so it is possible to improve convenience for the user.

More specifically, in this embodiment, the terminal 20 receives information from a first user (an example of a first user, not limited) of a first user's terminal 20 different from its own terminal 20 to a user of its own terminal 20. Remittance request information (not a limitation, but an example of first information) regarding a remittance request to (an example, but not a limitation, of a user of a terminal), or a first remittance regarding a remittance request from a user of one's own terminal 20 to a first user The display based on the request information (not a limitation, but an example of the first information) and the first user (not a limitation, but an example of the second user) 2. A display based on the remittance request information (not limited to, but an example of a second display) is displayed on at least the display unit 24.
Then, the terminal 20 performs a first process (limited Rather, it shows a configuration in which the control unit 21 performs an example of the first process based on the first information and the second information.
As an example of the effect of the embodiment obtained by such a configuration, a first display based on first information regarding a remittance request from the first user to the terminal user, or a remittance request from the terminal user to the first user; A second display based on second information regarding a remittance request from the second user to the terminal user or a remittance request from the terminal user to the second user is displayed. It becomes possible to process information all at once, and it is possible to improve convenience for the user.

Further, in this embodiment, the first remittance request information is information regarding a remittance request from the other user to the user of the terminal 20 (not limited to this, but is an example of information regarding a remittance request from the first user to the user of the terminal). ), and the second remittance request information includes information regarding a remittance request from the user of the own terminal 20 to the other user (not limited to, but an example of information regarding a remittance request from the terminal user to the second user) It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, by way of example and not limitation, the amount remitted by the terminal user to the first user (the amount paid by the terminal user) and the terminal The difference between the amount remitted by the user from the second user (the amount received by the user of the terminal) can be remitted to the first user, or can be remitted from the second user. In this case, the amount to be remitted or the amount to be remitted will be smaller (the absolute value of the difference amount will be smaller) than when multiple pieces of information related to remittance requests are processed one by one. For this reason, one effect, not a limitation, is that there is a high possibility that processing can be done within the range of the user's balance, and the user does not have to take the trouble of charging or making a loan to send money. In addition, one effect, not a limitation, is that multiple pieces of information can be processed at once, so an increase in the number of items to be processed can be expected.

Further, in this embodiment, the first remittance request information includes information on the first remittance request amount (not limited to, but an example of the first amount regarding remittance), and the second remittance request information includes information on the second remittance request amount ( This is not a limitation, and shows a configuration including information on the second amount (an example of the second amount related to the remittance).
As an example of the effect of the embodiment obtained by such a configuration, the first display and the second display can inform the user of the terminal of the first amount related to the remittance and the second amount related to the remittance.

Furthermore, this embodiment shows a configuration in which the first process includes processing based on the first remittance request amount and the second remittance request amount.
As an example of the effect of the embodiment obtained by such a configuration, by way of example and not limitation, it is possible to perform processing such as lump sum payment based on the difference between the first amount and the second amount. .

Further, in this embodiment, the terminal 20 communicates bulk payment confirmation information based on the second remittance request information to the first user's terminal 20 (not limited to, but an example of the second user's terminal) via the server 10. Transmit via I/F22. In this case, the first process indicates a configuration in which the process is executed by the control unit 21 based on the first user's approval for execution of the first process based on the lump sum payment confirmation information.
As an example of the effect of the embodiment obtained by such a configuration, the first process can be executed when approved by the other party. Also, by way of example and not limitation, if the other party does not approve, the first process may not be executed.

Furthermore, this embodiment shows a configuration in which the second user is the first user.
As an example of the effect of the embodiment obtained by such a configuration, the first processing is performed based on information regarding multiple remittance requests with one user (first user) different from the user of the own terminal 20. can be executed.

Further, in this embodiment, when the second remittance request amount is larger than the first remittance request amount, the first process is the amount obtained by subtracting the first remittance request amount from the second remittance request amount (not limited to the third remittance request amount). This figure shows a configuration including a process of remitting an amount (an example of an amount) to a first user.
As an example of the effect of the embodiment obtained by such a configuration, since the difference between the second amount and the first amount can be remitted to the first user, when remittance is performed based on one piece of information. It is possible to reduce the amount of money to be paid compared to the previous version, thereby improving convenience for the user.

Further, in this embodiment, the first remittance request information (not a limitation, an example of first information) includes information on the first remittance request amount (not a limitation, an example of the first amount), and the second remittance request information The information (not a limitation, but an example of the second information) includes information about the second remittance request amount (not a limitation, but an example of the second amount), and the first process includes the first remittance request amount and the second remittance request amount. It shows a configuration performed by the control unit 21 based on the requested amount and the electronic money account balance of the user of the terminal 20 (not limited to this, but an example of the balance of the user of the terminal).
As an example of the effect of the embodiment obtained by such a configuration, the first process based on the first amount and the second amount can be executed in consideration of the balance of the user of the terminal. As a result, by way of example and not limitation, the first process may be executed if the terminal user has sufficient balance, but the first process may not be executed if the terminal user has insufficient balance.

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

Furthermore, in this embodiment, the first process is based on the e-money account balance of the proposer's user (not a limitation, but an example of the terminal user's balance) and the e-money account balance of the other user (not a limitation, but an example of the terminal user's balance). (Example of the balance of one user or the balance of a second user) is shown.
As an example of the effect of the embodiment obtained by such a configuration, the first process is executed in consideration of not only the balance of the terminal user but also the balance of the first user or the second user. I can do it. As a result, by way of example and not limitation, if the balance of the first user or the second user is sufficient, the first process is executed, but if the balance of the first user or the second user is insufficient, the first process is executed. can be prevented from being executed.

Further, in this embodiment, the first process includes a plurality of remittance request information regarding the proposer's user, including first remittance request information and second remittance request information (not limited to, first information and second information). (including at least the first remittance request information and the second remittance request information) based on the input to the terminal 20 by the proposer's user. The configuration includes processing based on remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, among a plurality of pieces of information regarding a remittance request to a terminal user or a remittance request by a terminal user, the terminal includes at least first information and second information. The first information and the second information can be appropriately processed based on the input to the terminal by the user.

Furthermore, in this embodiment, the other user is one user (an example, not a limitation, where the second user is the first user), and the first process is a communication from the other user to the proposer user. This shows a configuration including processing related to remittance or processing related to remittance from the proposer's user to the other party's user.
As an example of the effect of the embodiment obtained by such a configuration, when the same user (first user = second user) is the other user, the first user sends a message to the terminal based on multiple pieces of information regarding the remittance request. A transfer of money to the user or from the user of the terminal to the first user can be realized.

Additionally, in this embodiment, the above remittance-related processing includes batch payment confirmation information and batch payment result information (not limited to, processing of a remittance request based on the first information and processing of a remittance request based on the second information). The configuration includes a process of displaying an example of information indicating that the process has been executed on the display unit 24.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to notify the user of the terminal that the processing of the remittance request based on the first information and the processing of the remittance request based on the second information have been executed. can.

<First modification (1)>
As described above, the method of the above embodiment can be similarly applied even when the other user is a plurality of different users.

FIG. 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 modification. 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, not a limitation, based on the remittance request list icon being tapped on the main menu screen of Figure 1-9. This is an example of a displayed screen.

In the current position display area CLR1, characters "Remittance request list" indicating that remittance request list information is displayed are displayed.
Below the current position display area CLR1, unprocessed requests transmitted and received with users of a plurality of different terminals 20 are displayed in chronological order from the top to the oldest, by way of example and not limitation. In this example, from top to bottom, user B. Received money transfer request from user B, user C. Received money transfer request from user B. Received money transfer request from user B, user C. Received money transfer request from user D.C. Received money transfer request from D, user C. A remittance request sent to C is displayed.

Next to each remittance request, there is a check area SR2 that can be turned on/off by tapping, and by turning the check on, a check mark will be placed in the check area SR2. It is configured such that the remittance request with that user can be selected as a subject of batch settlement.

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

In this example, user A. A to user B. remittance (payment) to user C. C to user C. Since this is a remittance (payment) to C and there is no remittance (receipt) from the other user, approval from the other user can be made unnecessary.
Then, the server 10 executes the batch payment, and the user A. A to user B. A remittance (payment) of "2,000 yen" to user A. A to user C. A remittance (payment) of "1,000 yen" to C is realized.

This modification shows a configuration in which the first user is a different user from the second user.
As an example of the effect of the modified example obtained by such a configuration, a plurality of connections between at least two users different from the user of the own terminal 20 (a first user and a second user different from the second user) The first process can be executed based on the information regarding the remittance request.

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

Specifically, the control unit 21 of the proposer's terminal 20 performs a process of inquiring the server 10 about the present electronic money account balance of the proposer's user. Then, the control unit 21 of the proposer's terminal 20 selects the amount of each remittance request and the type of remittance request (received remittance request) from among the remittance requests included in the remittance request list information received from the server 10. By way of example and not limitation, send one or more money transfer requests such that the present e-money account balance of the proposer's user is the upper limit of the payment amount. select. That is, one or more remittance requests are selected within a range in which the current electronic money account balance of the proposer's user does not become negative.

Note that when the control unit 11 of the server 10 selects a remittance request, the same process may be performed based on the remittance request data stored in the first remittance request management data 157A.

In this modification, the first process is based on the proposer's user's electronic money account balance (not a limitation, but an example of the terminal user's balance), and multiple remittance request information (not a limitation, but a plurality of information example), at least the first remittance request information and the second remittance request information are selected, and the configuration includes processing based on at least the first remittance request information and the 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 from among the plurality of pieces of information are automatically selected in consideration of the balance of the terminal user, and the settlement is performed. You can make it happen. In this case, since the user of the terminal does not have to manually select information, it is possible to improve convenience for the user.

<First modification (3)>
The user interface of the display screen shown in <Display screen> in the first embodiment is merely an example, and the present invention is not limited thereto.

FIG. 1-24 is a diagram showing another example of the UI (user interface) of the 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 is a diagram showing another example of the remittance request list screen corresponding to FIG. 1-12.
In this display screen, user C. As a list of remittance requests with C, received remittance requests and sent remittance requests are displayed in a table format. 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.

Regarding the list of received remittance requests and the list of sent remittance requests, the display column for each remittance request includes the date and time of receipt/sent date and time of the remittance request, reason for payment, request type "Payment/Receipt", Information such as the remittance request amount is displayed.

By performing such a display, it becomes possible to check the received remittance request and the sent remittance request while comparing them, and it is possible to improve convenience for the user.

Further, in the above embodiment, 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, it is possible to check a list of unprocessed remittance requests from screens such as the payment application's announcement screen, the payment application's profile screen, and the payment application's top screen. You may or may not need to do so.

<First modification (4)>
In the above embodiment, a case has been described in which the approval of the other user is required for bulk payment. However, if the system is configured so that a remittance request cannot be created based on a user's operation, the other user's approval can be made unnecessary.

As such a system, by way of example and not limitation, a system that links and manages a user's electronic money or electronic payment and a remittance request can be considered. More specifically, after one user makes an electronic payment using electronic money, at least a portion of the payment amount is requested as an advance amount (advance amount) to another user through a remittance request. A system that can do this is conceivable. The application of this system is, by way of example and not limitation, in cases where multiple users split the bill.

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

In such a system, users who wish to make bulk payments are required to use their electronic money account balances to make electronic payments, so it is possible to minimize the risk of the above-mentioned bulk processing being misused. can.

<First modification (5)>
When performing bulk payment, a payment proposal in which one user is requested to make a payment from another user (a payment proposal that requires one user to make a payment to the other user) is sent to the other user when the other user requests remittance. This new remittance request may be managed on the server 10 side as an unprocessed received remittance request of one user.

Specifically, by way of example and not limitation, in the example of FIGS. 1-13, user C. C (first user) is user A. User A (the other user) accepts a payment proposal in which A (the other user) proposes a payment of "7,000 yen". This is a new remittance request in which user A requests a remittance of "7,000 yen," and this remittance request is sent to user C. The request may be managed on the server 10 side as an unprocessed received remittance request for "payment 7,000 yen" of C.

Furthermore, by way of example and not limitation, on the remittance request list screen etc. displayed by the terminal 20 on the display unit 24, based on the received remittance request newly created as described above being tapped, the received remittance request Information about the remittance request that contributed to the creation of the remittance request (the remittance request that caused the received remittance request to be created), including, by way of example and not limitation, the type of remittance request, the amount of the remittance request, the date and time, the reason, etc. It is also possible to enable the user to trace the history of a single remittance request by displaying information (information) hierarchically in the time axis direction.

Specifically, the above user C. When the unprocessed received remittance request for "Payment 7,000 yen" in C is tapped, the remittance requests that contributed to the creation of this received remittance request, 3 in the example in Figure 1-14, are shown by way of example and not limitation. Information regarding the respective remittance requests of the received remittance request "Payment 10,000 yen" and the fourth sent remittance request "Receipt 3,000 yen" may be displayed.
Note that this method can be similarly applied to sent remittance requests.

<First modification (6)>
In the first embodiment, the first user and the second user are described as users of the terminal 20 who are general users, but the present invention is not limited thereto.
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 instead of a general user. Businesses in this case include, by way of example and not limitation, businesses that sell products (including the provision of services), businesses that run money lending businesses, and other businesses that provide money to users of the terminal 20 through remittance requests. Includes businesses (stores) that are expected to make claims.

In this case, in the example described above, these operators obtain an account with a payment service (payment application). Then, using this account, remittance request information and remittance reminder information can be transmitted via the server 10 to the terminal 20 of the user to whom the money is requested (remittance request destination user).

Note that the account acquired by the above-mentioned business operator (store) may be a general account that is an account for the user of the terminal 20, or may be an account for the business operator.

This modification shows a configuration in which at least one of the first user and the second user is a store that sells products related to remittance requests.
As an example of the effect of the modification obtained by such a configuration, not only general users but also store users can be users who can request remittances to the terminal user.

<First modification (7)>
It is assumed that some users of the terminal 20 may feel awkward and hesitate to propose lump-sum payment to the other user. By way of example and not limitation, this may be the case where the other user is a superior to oneself, or the other user is a person with whom one has a particularly close relationship, such as a best friend.

Therefore, instead of the user of the terminal 20, the user who makes the bulk proposal can be a user who uses a business account.
A business account is, by way of example and not limitation, a user who has an official account (hereinafter referred to as "official account" and appropriately expressed as "OA: Official Account") for the service (payment service in the above example). It is.

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

This modification shows a configuration in which the user who proposes the lump-sum payment is a user who uses an official account (not limited to, but an example of a business account).
As an example of the effect of the modified example obtained by such a configuration, it is possible to have a user using a business account make a request for bulk payment on behalf of the user who requests bulk payment, which improves user convenience. can be improved.

<Second example>
The second embodiment is an embodiment related to processing when the user's balance is insufficient in the lump-sum payment described in the first embodiment.
The content described in the second embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 2-1 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 for user A. This is a screen displayed on the display unit 24 of A's terminal 20A, and the other party is user B. This is a screen showing a list of remittance requests designated as B.
In the current position display area CLR1 at the top of the screen, user B. The words "Remittance request with B.B" indicating that an unprocessed request with B is displayed are displayed.

Below the current position display area CLR1, the other party is user B. A list of remittance requests designated as 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 payment details confirmation area in the electronic money account balance display area WBR2 at the bottom of the screen is selected. ACR3 shows changes in the electronic money account balance of the user (user A.A.). This example shows that the current electronic money account balance of one's own is "500 yen" and that the one's own electronic money account balance will become "0 yen" by batch settlement. In this case, since there is sufficient balance, it is possible to settle the payments all at once.

Further, on the right side of the words "wallet balance" in the electronic money account balance display area WBR2, a charge button for charging the wallet balance, which is indicated by a plus icon in a circle, is additionally displayed.

FIG. 2-2 is a diagram showing a remittance request list screen similar to the screen in FIG. 2-1, but the selected remittance request is different.
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 electronic money Changes in the user's (user A.A's) electronic money account balance are shown in the payment details confirmation area ACR4 within the account balance display area WBR2. In this example, the user's current electronic money account balance is "500 yen," and it is shown that the one-time payment will reduce the electronic money account balance to "-500 yen." In this example, the payment is 1000 yen, but the current electronic money account balance is 500 yen, so there is a shortage of 500 yen, and you cannot make a lump sum payment. .

In this case, in the payment details confirmation area ACR4, a warning mark and the text "Insufficient balance!" are displayed as insufficient balance information indicating that the electronic money account balance is insufficient, as an example and not a limitation. ing. In this state, when the suggestion button BT6 is tapped, a display as shown in FIG. 2-3 is displayed.

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

When the OK button is tapped in this state, the server 10 selects the user A. A charge process is executed to charge "500 yen" to A's electronic money account balance. After that, lump-sum payment is performed.

<Processing>
2-4 to 2-5 are flowcharts showing an example of the flow of the third payment process, which is an example of the payment 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 becomes negative (S1520: YES), the control unit 11 of the server 10 determines whether the user whose electronic money account balance becomes negative is the proposer's user. It is determined whether or not (S1550). If it is determined that the user is the proposer (S1550: YES), the control unit 11 of the server 10 sends, by way of example and not limitation, lump sum settlement confirmation information including lump sum settlement amount information and balance shortage information. , is transmitted to the terminal 20A via the communication I/F 14 (S1551).

Thereafter, the control unit 11 of the server 10 determines whether or not execution of a lump sum payment has been requested, based on whether payment execution request information has been received from the terminal 20A via the communication I/F 14 (S1553). If it is determined that the request has been made (S1553: YES), the control unit 11 of the server 10 controls the user A. It is determined whether or not to charge A's electronic money account balance (S1555). Specifically, by way of example and not limitation, the charge confirmation information described above is transmitted to the terminal 20A and displayed on the display unit 24, and it is determined whether or not information for approving the charge has been received from the terminal 20A.

If it is determined that charging is to be performed (S1555: YES), the control unit 11 of the server 10 executes charging processing (S1557). Specifically, user A. User A. will pay the shortfall in the lump sum payment using A's bank account or credit card. Execute processing to replenish A's electronic money account balance. Then, the control unit 11 of the server 10 moves the process to S1531.

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

After that, if it is determined that execution of a lump sum settlement has been requested from the terminal 20A (S1561: YES), the control unit 11 of the server 10 transmits lump sum settlement approval confirmation information including lump sum settlement amount information and balance shortage information through communication. It is transmitted to the terminal 20B via the I/F 14 (S1563).

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

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

If it is determined that charging is to be performed (S1567: YES), the control unit 11 of the server 10 executes charging processing (S1569). Specifically, the pre-registered user B. User B will pay the shortfall in the lump sum payment using B's bank account or credit card. Execute processing to replenish B's electronic money account balance.
Then, the control unit 11 of the server 10 moves the process to S1540.

If it is determined in S1553 that execution of the lump sum payment is not requested (S1553: NO), or if it is determined in S1555 that charging is not to be performed (S1555: NO), the control unit 11 of the server 10 performs the third payment process. end.

Additionally, if it is determined in S1561 that execution of the lump sum payment is not requested (S1561: NO), if it is determined in S1565 that the lump sum payment is not approved (S1565: NO), or if it is determined in S1567 that the charge will not be performed. In this case (S1567: NO), the control unit 11 of the server 10 ends the third payment process.

Note that before executing the process of S1540, the process similar to S1520 may be executed again, and if it is determined that the electronic money account balance of any user becomes negative, the process of S1540 may be suspended. But you don't have to.

<Effects of the second embodiment>
In this embodiment, the first remittance request information (not a limitation, an example of the first information) includes information on the first remittance request amount (not a limitation, an example of the first amount), and the second remittance request information ( The second information (not a limitation, but an example of the second information) includes information on the second remittance request amount (not a limitation, but an example of the second amount), and the first process includes the first remittance request amount and the second remittance request amount. , and the electronic money account balance of the user of the terminal 20 (not limited to this, but an example of the balance of the user of the terminal).
As an example of the effect of the embodiment obtained by such a configuration, the first process can be appropriately executed based on the first amount and the second amount, taking into consideration the balance of the user of the terminal.

Further, in this embodiment, if the sum of the first remittance request amount and the second remittance request amount exceeds the electronic money account balance of the user of the own terminal 20 and the user of the own terminal 20 makes a remittance, the balance A configuration is shown in which a display of insufficient information (not a limitation, but an example of a third display indicating that the first process cannot be performed) is displayed on the display unit 24 of the own terminal 20.
As an example of the effect of the embodiment obtained by such a configuration, the terminal user will remit money even though the sum of the first amount and the second amount exceeds the terminal user's balance. In such a case, it is possible to notify the user of the terminal that the first process cannot be executed.

Further, in this embodiment, if the sum of the first remittance request amount and the second remittance request amount exceeds the electronic money account balance of the user of the own terminal 20 and the user of the own terminal 20 makes a remittance, A configuration in which display of confirmation information for charging to the electronic money account balance of the user of the terminal 20 of the user (not limited to, but an example of the fourth display indicating that the balance will be charged) is displayed on the display unit 24 of the user's terminal 20. It shows.
As an example of the effect of the embodiment obtained by such a configuration, the terminal user will remit money even though the sum of the first amount and the second amount exceeds the terminal user's balance. In such a case, the user of the terminal can be informed that it is possible to make up the shortfall by charging the balance.

<Second modification example>
In the second embodiment, when the terminal 20 displays the remittance request list screen on the display unit 24, by way of example and not limitation, information indicating that the terminal 20 can charge its own electronic money account balance (charging information) Information (loan information) indicating that a loan (loan) can be made may or may not be displayed on the display unit 24 as well.

By way of example and not limitation, the loan provider may be a payment service provider (payment application provider)/messaging service provider (messaging application provider), or a financial institution such as a bank. can.

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

Once payment has been made with a loan, by way of example and not limitation, the user may be required to repay the loan amount by a predetermined repayment deadline.
Note that the repayment method in this case may be the same as for a general loan.

In this modification, the terminal 20 displays a display based on the first remittance request information (an example of the first display, not a limitation) and a display based on the second remittance request information (an example of the second display, not a limitation). , a display of charge information (an example of a display related to charging the balance, not a limitation), or loan information (an example of a display related to making a loan, not a limitation) is displayed on the display unit 24. .
As an example of the effect of the modified example obtained by such a configuration, when displaying the first display based on the first information and the second display based on the second information, a display regarding charging the balance or a loan is performed. By displaying a display related to this, it is possible for the user to easily charge the balance or take out a loan.

<Third Example>
The third example is an example in which, in relation to the second example, the display mode of the display related to the execution of lump sum payment is changed.
The content described in the third embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 3-1 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 for user A. This screen corresponds to the screen of FIG. 2-1 displayed on the display unit 24 of the terminal 20A of user A. This screen is displayed when A's electronic money account balance is sufficient.

The settlement details confirmation area ACR5 at the bottom of the screen indicates that the balance of one's electronic money account will be "0 yen" due to the lump sum settlement, but that the lump sum settlement is possible.
In this case, when an operation (tap) is performed on the suggestion button BT7, the terminal 20A accepts the operation to propose the lump sum payment.

FIG. 3-2 is a diagram showing another example of the remittance request list screen displayed on the display unit 24 of the terminal 20 in this embodiment.
This remittance request list screen is for user A. This screen corresponds to the screen of FIG. 2-2 displayed on the display unit 24 of the terminal 20A of user A. This screen is displayed when A's electronic money account balance is insufficient.
On this screen, user A. Based on the fact that A's electronic money account balance is insufficient, the suggestion button BT7 displayed in the payment details confirmation area ACR5 at the bottom of the screen is displayed in a different display form from that shown in FIG. 3-1. Specifically, by way of example and not limitation, the suggestion button BT7 is displayed grayed out, and even if an operation (tap) is performed on the suggestion button BT7, the terminal 20A does not accept the operation.

Note that in FIG. 3-2, a charge button to the electronic money account may or may not be displayed in the electronic money account balance display area WBR1 to prompt the user to charge the electronic money account.
Additionally, if the business that operates the payment service is affiliated with a financial institution, it may display a loan function button that allows you to receive a loan from that financial institution and charge it to your electronic money account. You don't have to.

<Effects of the third embodiment>
In the present embodiment, the terminal 20 displays a suggestion button (not a limitation, but an example of the fifth display related to execution of the first process) on the display unit 24. In this case, the display mode of the suggestion button is changed based on the first remittance request amount, the second remittance request amount, and the balance of the user's electronic money account.
As an example of the effect of the embodiment obtained by such a configuration, the display mode of the fifth display regarding execution of the first process is changed based on the first amount, the second amount, and the balance of the user of the terminal. Therefore, by way of example and not limitation, it is possible to simply and appropriately notify the terminal user that the first process cannot be performed, taking into consideration the terminal user's balance.

Further, in this embodiment, the display of the suggestion button is such that the sum of the first remittance request amount and the second remittance request amount exceeds the electronic money account balance of the user of the own terminal 20, and the user of the own terminal 20 In the case of remittance, the configuration is displayed on the display unit 24 of the own terminal 20 in a display mode indicating that the operation is not accepted (not limited, but an example of the display mode indicating that the first process cannot be executed). There is.
As an example of the effect of the embodiment obtained by such a configuration, the terminal user will remit money even though the sum of the first amount and the second amount exceeds the terminal user's balance. In such a case, it is possible to notify the user of the terminal that the first process cannot be executed.

<Fourth Example>
The fourth embodiment is an embodiment related to a processing method (algorithm) for batch payment.
The content described in the fourth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Processing>
The batch payment performed by the server 10 can include, by way of example and not limitation, the following two methods.
(1) Batch settlement (batch settlement)
(2) Sequential settlement (sequential settlement)

(1) Batch settlement is, by way of example and not limitation, a batch settlement method 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 and the type (received remittance request/sent remittance request) of each selected remittance request. calculate.
In this case, even if the payment is made based on the calculated lump-sum payment amount, if the e-money account balance of the user of the proposer's terminal 20 and the e-money account balance of the other user do not become negative, the payment will be made. OK.
On the other hand, when settlement is performed based on the calculated lump sum settlement amount, if either the e-money account balance of the user of the proposer's terminal 20 or the e-money account balance of the other user becomes negative, the settlement will be canceled. It will be rejected.

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

Note that even if the remittance requests are processed in a different order and the remittance requests are processed in a round-robin manner, either the e-money account balance of the user of the proposer's terminal 20 or the e-money account balance of the other user will be changed in the middle of the sequential processing. If one of them is negative, sequential settlement cannot be performed, and therefore settlement can be rejected.

<Display screen>
The difference between batch payment and sequential payment will be explained with reference to the example shown in FIG. 3-1.
Here, we will consider the following two cases.
(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 explained.
(1) When applying batch settlement When applying batch settlement, the first received remittance request, the second received remittance request, and the fourth sent remittance selected in Figure 3-1. The request will be processed at the same time.
In this case, the lump sum payment is ``Payment 2,000 yen'', ``Payment 500 yen'', and ``Receipt 2,000 yen'' for ``Payment 500 yen'' (500 yen from user A.A to user B.B). payment).
User A. A's current electronic money account balance is "500 yen", and user A. Since A's balance will not become negative, if the payment is made in installments, user B. Payment can be made regardless of B's electronic money account balance.

(2) When applying sequential settlement When applying sequential settlement, the first received remittance request, the second received remittance request, and the fourth sent remittance selected in Figure 3-1. The requests will be processed one by one.
As an example and not a limitation, consider a case where processing is performed in the order of the second received remittance request → the fourth sent remittance request → the first received remittance request.

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

Next, the fourth sent remittance request is from user A. A is user B. Since "2,000 yen" is received from user B, when this payment is made, user A. A's electronic money account balance changes from 0 yen to 2,000 yen, and user B. B's electronic money account balance changes from 2,000 yen to 0 yen.

Finally, the first received remittance request is from user A. A to user B. Since the payment is ``2,000 yen'' to user B, when this payment is made, user A. A's electronic money account balance changes from 2,000 yen to 0 yen, and user B. B's electronic money account balance changes from 0 yen to 2,000 yen.

User B. Since B's current electronic money account balance is "1,500 yen," as a result of the above settlement, user B. B is user A. You will receive ``500 yen'' from A.
In this example, user A. A's electronic money account balance and user B. Since neither of the electronic money account balances with B becomes negative, payments can also be made sequentially.

Next, (Case 2) will be explained.
(1) When applying batch settlement When batch settlement is applied, it is the same as (Case 1).
In other words, user A. A's current electronic money account balance is "500 yen", and user A. Since A's balance will not become negative, user B. Payment can be made regardless of B's electronic money account balance.

(2) When applying sequential settlement When applying sequential settlement, as in (case 2), the first received remittance request and the second received remittance request selected in Figure 3-1 and the fourth sent remittance request will be processed one by one.
However, in (Case 2), unlike in (Case 1), user B. Because B's current electronic money account balance is "1,000 yen," the first received remittance request, the second received remittance request, and the fourth received remittance request are selected in Figure 3-1. User A.'s sent remittance requests are processed in any order. A's electronic money account balance and user B. It is not possible to settle the account so that the electronic money account balance with B does not become negative.

From the above, in (Case 1), it is possible to settle by either batch settlement or sequential settlement, but in (Case 2), settlement by batch settlement is possible, but settlement by sequential settlement is not possible. become.

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 insufficient balance in the user's electronic money account may be temporarily treated as a negative value of the account balance. Allowing may or may not enable settlement.

FIG. 4-1 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20B when sequential payment is applied in the above (case 1).
A current position display area CLR3 is configured at the top of the notification screen, and the characters "Notice" are displayed to indicate that a notification regarding the payment application is being displayed.
In the announcement information display area NTR3 below the current position display area CLR3, user A. Bulk payment approval confirmation information sent from the server 10 to the terminal 20B based on the proposal from A is displayed.
In (Case 1), since it is possible to pay by sequential payment, the payment button BT8 included in the batch payment approval confirmation information is displayed in a state where it can accept an operation.

On the other hand, FIG. 4-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20B when sequential payment is applied in the above (case 2).
The information displayed on this notification screen is the same as that shown in Figure 4-1, but in (case 2), payment cannot be made sequentially, so the payment button BT8 included in the batch payment approval confirmation information is grayed out. Therefore, even if the payment button is operated (tapped), the terminal 20B does not accept the operation.

<Fifth example>
The fifth embodiment is an embodiment related to "request cancellation" of the batch processing described above.
The contents described in the fifth embodiment can be applied to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

As mentioned above, the remittance request amount (the amount to be transferred) of the selected received remittance request is the same as the remittance request amount (the amount to be received) of the selected sent remittance request. If so, it is possible to offset the amount by lump sum settlement.

However, in such a case, it is also possible to perform request offset instead of performing lump-sum payment.
Request offset means, by way of example and not limitation, that remittance requests selected for processing cancel each other out, eliminating those remittance requests, and deleting the data of those remittance requests.

<Display screen>
FIG. 5-1 shows user A. It is a figure which shows an example of the remittance request list screen displayed on the display part 24 of A's terminal 20A. This remittance request list screen identifies the other user as user B. This is the screen labeled B.
This remittance request list screen shows that the first received remittance request (payment 2,000 yen) and the fourth sent remittance request (receipt 2000 yen) are selected.

In the payment details confirmation area ACR6 at the bottom of the screen, user A. A's current electronic money account balance and user A. A's electronic money account balance after payment is displayed. When lump sum settlement is performed based on the above two selected remittance requests, the amounts will be offset. Therefore, in this example, user A. A's current electronic money account balance and user A. A's electronic money account balance after payment is the same amount (500 yen).

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

<Processing>
(1) Example of Processing FIG. 5-2 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 request offset processing (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 the remittance request can be offset based on the calculated lump sum settlement amount. do. If it is determined that offset is possible, the control unit 11 of the server 10 transmits request offset confirmation information to the terminal 20A.

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

The control unit 11 of the server 10 executes request cancellation based on receiving the request cancellation execution request information from the terminal 20A. Specifically, the data of the remittance request to be offset is deleted from the first remittance request management data 157A.
Note that the remittance completion flag of the remittance request to be offset may be set to "ON" without deleting the remittance request data.
Then, the control unit 11 of the server 10 ends the request cancellation process.

After that, the control unit 11 of the server 10 determines whether the request cancellation result is "OK" (S370). If it is determined that the request is "OK" (S370: YES), the control unit 11 of the server 10 transmits request cancellation result information to the terminal 20A and the terminal 20B through the communication I/F 14 (S390). Then, the control unit 11 of the server 10 ends the process.

Upon receiving the request cancellation result information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A displays the received request cancellation result information on the display unit 24 (A390).
Then, the control unit 21 of the terminal 20A ends the process.

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

(2) Another example of processing When performing the above-mentioned request offset, it is also possible to require the approval of the other user. The case where the other user's approval is required is the same as the case explained for bulk payment.

The processing in this case can be configured in the same way as the processing when the other user's approval is required in bulk payment (as an example, not a limitation, the processing in Figures 1-21 to 1-22). Therefore, illustration and detailed description will be omitted.

<Effects of the fifth embodiment>
In this embodiment, the first process includes a plurality of remittance request information regarding the proposer's user, including first remittance request information and second remittance request information (without limitation, at least the first information and the second information). The first remittance request information and the second remittance request based on the input to the terminal 20 by the proposer's user (one example of multiple pieces of information regarding a remittance request to a terminal user or a remittance request by a terminal user) A configuration including processing based on information is shown.
As an example of the effect of the embodiment obtained by such a configuration, among a plurality of pieces of information regarding a remittance request to a terminal user or a remittance request by a terminal user, the terminal includes at least first information and second information. The first information and the second information can be appropriately processed based on the input to the terminal by the user.

Further, in this embodiment, the first remittance request information and the second remittance request information are information on the same remittance request amount, and the first process is based on the first remittance request information and the second remittance request information, A configuration is shown in which the first remittance request information and the second remittance request information are cancelled.
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 of money, these pieces of information can be offset. As a result, it is possible to improve the convenience for both the user who requests remittance based on the first information and the user who requests remittance based on the second information.

<Fifth modification example>
In the fifth embodiment, if the remittance request amount of the remittance request selected for processing is not offset, the difference amount is set as the remittance request amount, and the type (payment/receipt) is determined by the positive or negative sign of the result of amount deduction. You may or may not create a new remittance request in which the

<Sixth Example>
The sixth embodiment is an example related to "creating a batch remittance request" of the batch processing described above.
The content described in the sixth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 6-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.
In the current position display area CLR1 at the top of this screen, user D. The words "Remittance request with D.D." indicating that an unprocessed request with D is displayed are displayed.
In addition, the current position display area CLR1 includes user D. A state is shown in which the first to fourth remittance requests among the unprocessed requests with D are selected.

When making a batch payment for the selected 1st to 4th remittance requests, the batch payment will be "Payment 1,100 yen" and User A. A to user D. You will pay ``1,100 yen'' to D. However, in this example, user A. Since A's current electronic money account balance is "500 yen," the payment amount will be short by "600 yen."

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, lump sum settlement is not performed.

Specifically, in the payment details confirmation area ACR7 at the bottom of the screen, "500 yen" is displayed as the current electronic money account balance of the user and the balance of the electronic money account after the payment is made. .

Further, below that, a suggestion button BT9 and a cancel button are displayed along with the text "Do you want to make a proposal to consolidate the requests?".
When the proposal button BT9 is tapped in this state, a new remittance request is created based on the amount of the shortfall in payment, "1,100 yen." As a result, a screen as shown in Figure 6-2 is displayed.

In Figure 6-2, as a newly created remittance request, a batch remittance request with a payment amount of "1,100 yen", which is a collection of four remittance requests that have been received, is displayed. ing.
In this display screen example, the lump sum remittance request includes the four remittance requests selected in Figure 6-1, that is, the remittance requests used to create the lump sum remittance request (combined remittance requests). displayed in the format. In addition, these remittance requests are displayed in a different display format (grayed out in this example) from other remittance requests so that the user can easily recognize them.

Note that, unlike this display screen example, the remittance request used to create the lump sum remittance request may not be displayed.
Further, based on the fact that a lump sum remittance request is tapped, the remittance request used to create the lump sum remittance request may be displayed.

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

If it is determined that the request has been made (S510: YES), the control unit 11 of the server 10 refers to the remittance request management data 157, and displays the remittance request amount and type (received remittance request) of each selected remittance request. (Payment)/Sent Remittance Request (Receipt)), the remittance request amount (hereinafter referred to as "lump remittance request amount") of the batch remittance request to be created is calculated (S530).

Thereafter, 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 batch remittance request creation result to the requesting terminal 20 via the communication I/F 14 (S570).
Then, the control unit 11 of the server 10 ends the batch remittance request creation process.

After this process is performed, the terminal 20 displays lump sum remittance request information corresponding to the lump sum remittance request on the remittance request list screen displayed on the display unit 24 or the like. Based on this batch remittance request, it becomes possible to execute batch payment.

Note that if it is determined in S510 that the creation of a lump sum remittance request is not requested from the terminal 20 (S510: NO), the control unit 11 of the server 10 may, by way of example and not limitation, It is also possible to perform other batch processing such as batch payment or request offset described above.

Note that a malicious user may create the above-mentioned false remittance request and then create a bulk remittance request that includes the remittance request.
Therefore, the 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 party's user is one user (this is not a limitation, but is an example in which the second user is the first user), and the first process includes the first remittance request information and the second remittance request information. A lump sum based on remittance request information (not limited to, but an example of third information regarding a remittance request from a first user to a terminal user, or a remittance request from a terminal user to the other user), which is the sum of the remittance request amounts of The configuration includes a process of displaying a remittance request display (not limited, but an example of a sixth display) on the display unit 24.
As an example of the effect of the embodiment obtained by such a configuration, when the other user is a single user, a sixth display based on third information that summarizes information regarding multiple remittance requests is displayed, and the third display is 3 information can be notified to the terminal user. Furthermore, by way of example and not limitation, it is possible to perform comprehensive payment based on the third information that summarizes information regarding multiple remittance requests, thereby improving convenience for the user.

<Seventh Example>
The seventh embodiment is an example related to "creation of special lump sum payment/special lump sum remittance request" of the batch processing described above.
The content described in the seventh embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<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 similarly to FIG. 6-1, user D. This shows a screen on which a list of remittance requests to and from D is displayed. Here, similarly to FIG. 6-1, a state is shown in which the first to fourth remittance requests are selected.

When making a batch payment for the selected 1st to 4th remittance requests, the batch payment will be "Payment 1,100 yen" and User A. A to user D. You will pay ``1,100 yen'' to D. However, in this example, user A. Since A's current electronic money account balance is "500 yen," the payment amount will be short by "600 yen."

In this case, in this embodiment, the control unit 11 of the server 10 controls the user A. The entire amount of A's current electronic money account balance is transferred to user D. Make a lump sum payment by remittance to D.
Further, the control unit 11 of the server 10 creates a new remittance request in which the remittance request amount is the amount of the shortfall in the payment in the lump sum settlement.
In other words, in this embodiment, unlike the sixth embodiment, a new remittance request is made with the amount that cannot be paid as the remittance request amount after the proposer's user has made the payment to the extent that the balance can be used. create.

For convenience, a lump sum payment in which payments are made up to the maximum amount possible based on multiple remittance requests is referred to as a "special lump sum payment", and a lump sum remittance request that is newly created after performing a special lump sum payment is referred to as a "special lump sum payment". "Remittance Request".

Specifically, the payment details confirmation area ACR8 at the bottom of the screen shows "500 yen" as your current electronic money account balance and "0 yen" as your electronic money account balance after payment. Displayed. Then, when the suggestion button is tapped in this state, user A. The entire amount of A's current electronic money account balance, ``500 yen,'' is transferred to user A. A to user D. A special lump sum settlement is executed in which the money is transferred and paid to D. Thereafter, a special lump sum remittance request is created based on the amount of the shortfall in payment, which is "600 yen." As a result, a screen as shown in Figure 7-2 is displayed.

In FIG. 7-2, a special lump sum remittance request in which the payment amount is "600 yen" is displayed as a special lump sum remittance request.
In this example display screen, the special lump sum remittance request includes the four remittance requests selected in Figure 7-1, that is, the remittance requests used to create the special lump sum remittance request (combined remittance requests). is displayed in a hanging format. Furthermore, to make it easier for the user to understand, these remittance requests are displayed in a different display format (grayed out in this example) than normal remittance requests.

Note that, unlike this display screen example, the remittance request used to create the special lump sum remittance request may not be displayed.
Further, based on the fact that 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 payment 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 becomes negative (S1520), and if it is determined that the balance becomes negative (S1520: YES), the electronic money account balance becomes negative (S1520: YES). It is determined whether the user whose account balance becomes negative is the proposer user (S1570).

If it is determined that it is the proposer user whose electronic money account balance becomes negative (S1570: YES), the control unit 11 of the server 10 determines the type of lump sum payment to be executed (normal Bulk payment type confirmation information for confirming bulk payment/special lump sum payment) is transmitted to the terminal 20A via the communication I/F 14 (S1571).
In this case, the above-mentioned balance shortage information may or may not be transmitted while being included in the lump sum payment type confirmation information.

Thereafter, the control unit 11 of the server 10 determines whether execution of the special lump sum payment has been requested based on receipt of payment execution request information including information on the type of lump sum payment requested to be executed from the terminal 20A. (S1574). If it is determined that execution of the above-mentioned normal lump sum payment is requested instead of the special lump sum payment (S1574: NO), the control unit 11 of the server 10 executes the process in S1555 of FIG. 2-5, by way of example and not limitation. Move.

On the other hand, if it is determined that execution of special lump sum payment is requested (S1574: YES), the control unit 11 of the server 10 determines whether approval from the other user is required (S1575).
If it is determined that the other user's approval is required (S1575: YES), the control unit 11 of the server 10 uses information on the amount to be paid by special lump sum payment (hereinafter referred to as "special lump sum payment amount"). Special lump sum payment approval confirmation information including certain special lump sum payment amount information is transmitted 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 corresponding to the proposer's user's current electronic money account balance.

Note that the special lump sum settlement amount is not limited to this, and can be any amount as long as it is greater than "0" and less than or equal to the present electronic money account balance of the proposer's user.

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

If it is determined that the request has been approved (S1579: YES), the control unit 11 of the server 10 executes special lump sum payment (S1581). Specifically, the control unit 11 of the server 10 updates the electronic money account balance of the proposer user (in this example, user AA) to zero, and updates the special lump sum settlement amount to the other user (in this example, user AA). It is added to and updated to user B.B)'s electronic money account balance.

After that, 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 remittance request from the other party's user to the proposer's user as a special lump-sum remittance request, with the amount obtained by subtracting the special lump-sum payment amount from the lump-sum payment amount as the remittance request amount. do.
Then, the control unit 11 of the server 10 ends the fourth payment process.

Furthermore, as mentioned above, the method of paying as much as possible using the proposer's user's balance is not limited to the case where multiple remittance requests are selected as described above, but also when one remittance request is selected. is also applicable.
In other words, if one received remittance request whose remittance request amount is larger than the amount of the proposer's current electronic money account balance is selected, the control unit 11 of the server 10 selects an electronic money transfer request based on the remittance request amount. Create a remittance request whose remittance request amount is the amount obtained by subtracting the amount from the money account balance (the amount of the shortage).

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

By way of example and not limitation, the second process includes at least the following processes.
・Process of sending request selection information to server 10 ・Process of receiving bulk payment confirmation information from server 10 ・Process of displaying bulk payment confirmation information ・Process of receiving bulk payment result information from server 10 ・Process of receiving bulk payment result information Processing to display - Processing to request the server 10 to deduct the amount (including amount offset) - Processing to request the server 10 to execute special lump sum settlement - Processing to request the server 10 to create a special lump sum remittance request

<Effects of the seventh embodiment>
In this embodiment, among multiple remittance request information related to a remittance request to a user (not limited to, but an example of a terminal user) of a user who proposes a lump sum payment, or a remittance request by a user who proposes a lump sum payment, A second process for batch settlement of at least one remittance request information based on the electronic money account balance of the user of the proposer (not limited to, but an example of the balance of the user of the terminal) An example of the second process for processing information) is executed by the terminal 20 of the user who proposes the lump-sum payment.
As an example of the effect of the embodiment obtained by such a configuration, in consideration of the terminal user's balance, a remittance request to the terminal user or at least one of a plurality of pieces of information regarding the remittance request by the terminal user is processed. Since the information can be processed by the second process, user convenience can be improved.

<Seventh modification example>
Related to the first variation (3), in the seventh embodiment, the proposer's terminal 20 or the server 10 automatically selects a remittance request based on the proposer's user's current electronic money account balance. (Including suggestions.) You may or may not.

Specifically, the control unit 21 of the proposer's terminal 20 performs a process of inquiring the server 10 about the present electronic money account balance of the proposer's user. Then, the control unit 21 of the proposer's terminal 20 selects the amount of each remittance request and the type of remittance request (received remittance request) from among the remittance requests included in the remittance request list information received from the server 10. By way of example and not limitation, the combination of remittance requests that results in a payment in excess of the proposer's user's current electronic money account balance is identified and selected.

In this case, by way of example and not limitation, in FIG. 7-1, user D. Among the unprocessed requests with D, as an example and not a limitation, past remittance requests are automatically selected as requests to be processed for batch settlement, and remittance requests with insufficient funds (in this example, the fourth remittance request) ) may or may not be proposed to the user.

Note that when the control unit 11 of the server 10 selects a remittance request, the same process may be performed based on the remittance request data stored in the remittance request management data 157.

In this modification, the second process selects remittance request information that can be processed based on the proposer's user's electronic money account balance (not a limitation, but an example of the terminal user's balance) from among the plurality of remittance request information. The configuration includes processing and processes selected information.
As an example of the effect of the embodiment obtained by such a configuration, information that can be processed with the terminal user's balance is selected and processed, so as an example and not a limitation, there is a range in which the terminal user's balance does not become negative. Since the information can be processed by the user, convenience for the user can be further improved.

<Eighth Example>
The eighth embodiment is an embodiment in which an unprocessed request is displayed when the user of the terminal 20 sends money to the other user or requests money to the other user.
The contents described in the eighth embodiment can be applied to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 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 shown by way of example and not limitation for user A. This is a remittance screen of the payment application displayed on the display unit 24 of A's terminal 20A.
In the current location display area CLR1 indicating the current location in the payment application, the characters "remittance" indicating that the current location is the remittance function of the payment application are displayed.

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

Further below, there is a configuration that allows you to check the outstanding requests of 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). An unprocessed request confirmation area URR1 is displayed.

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

Further, below that, a lump sum payment amount (in this example, "1,500 yen") and a mark (in this example, a "payment mark") are displayed, assuming that all selections are to be paid at once.
Note that this display column may not be provided if it is assumed that this all-selected one-time payment is performed.

Below that, the other party is user E. A list of remittance requests named E is displayed. In this example, the other party is user E. Unprocessed requests named E are listed in chronological order from the oldest to the top.

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

Note that, by way of example and not limitation, the remittance button may be displayed in an area above the unprocessed request confirmation area URR1, under the display area of a function button for increasing the remittance amount by a certain amount.

In this way, in this embodiment, by displaying the unprocessed requests together with the remittance information, the user can also check the unprocessed requests when making a remittance.

FIG. 8-2 is a diagram showing another example of the screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen is shown by way of example and not limitation for user A. This is a remittance request screen of the payment application displayed on the display unit 24 of A's terminal 20A.
In the current position display area CLR1 indicating the current position in the payment application, the characters "Remittance Request" indicating that the current position is the remittance request function of the payment application are displayed.

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

Furthermore, if the user selected as the destination of the remittance request accepts the remittance request, the transfer will be made from the electronic money account of the user selected as the destination of the remittance request to the electronic money account of the user who made (sent) the remittance request. Then, the remittance for the remittance request amount is executed.

Further, below that, an unprocessed request confirmation area URR1 is displayed, similar to FIG. 8-1. Below that, a remittance request button labeled "Request remittance" for transmitting a remittance request (remittance request sending process) is displayed.
When the remittance request button is tapped, the server 10 executes remittance request transmission processing (transmission of remittance request information from user A.A to user E.E).

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

In this way, in this embodiment, the unprocessed requests are displayed together with the information for sending the remittance request, so that the user can also check the unprocessed requests when making the remittance request. ing.

<Processing>
FIG. 8-3 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. Here, as an example, the process of displaying unprocessed requests when a user makes a remittance, which was explained in FIG. 8-1, will be described.

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

After that, the control unit 21 of the terminal 20A determines whether or not an input for executing remittance (by way of example and not limitation, operation of a 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 the input for executing the remittance has been made (A630: YES), the control unit 21 of the terminal 20A transmits remittance request information for requesting remittance to the server 10 via the communication I/F 22. (A640).

After S120, the control unit 11 of the server 10 determines whether remittance request information has been received from the terminal 20A through 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 remittance processing (S650). Specifically, by way of example and not limitation, remittance confirmation information for confirming remittance details is sent to the terminal 20A via the communication I/F 14, and remittance execution request information is received from the terminal 20A via the communication I/F 14. Based on user A. A to user B. Execute remittance to B.
In this case, the control unit 21 of the terminal 20A executes the processes A650 to A670, by way of example and not limitation.

After that, the control unit 11 of the server 10 determines whether the remittance result is "OK" (S670). If it is determined that the result is "OK" (S670: YES), the control unit 11 of the server 10 transmits the remittance result information to the terminal 20A and the terminal 20B through the communication I/F 14 (S690).
Then, the control unit 11 of the server 10 ends the process.

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

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

Note that the process of displaying unprocessed requests when a user makes a remittance request, as explained in Figure 8-2, can be done in the same way by replacing "remittance" with "send remittance request" in the process of Figure 8-3. Since it is configurable, illustrations and explanations are omitted.
Specifically, in the process of the terminal 20A, it is determined at A105 whether an input has been made to display the remittance request sending screen, the remittance request sending screen including the remittance request list information is displayed at A125, and the remittance request sending screen including remittance request list information is displayed at A630. Determine whether or not to execute remittance request transmission, transmit remittance request transmission request information at A640, display remittance request transmission confirmation information at A650, and determine whether or not a remittance request transmission execution request is made at A660. , A670 transmits remittance request transmission execution request information, and A690 displays remittance request transmission result information.
Further, in the process of the terminal 20B, remittance request transmission result information is displayed at B690.
In addition, in the processing of the server 10, it is determined in S640 whether remittance request transmission request information has been received, the remittance request transmission process is executed in S650, and it is determined in S670 whether the remittance request transmission result is OK. Then, in S690, remittance request transmission result information is transmitted.

<Display of unprocessed requests>
The unprocessed requests displayed on the display unit 24 of the terminal 20 can be one or both of the following, by way of example and not limitation.
・Unprocessed request corresponding to the user to whom you want to send money (destination user) or the user to whom you want to send a money transfer request (destination user) ・The user to whom you want to send money (destination user) or send a money transfer request An unprocessed request that corresponds to a user different from the user you are sending money to (the user you are requesting to send money to)

Unprocessed requests corresponding to the other user can be displayed. By way of example and not limitation, user A. A is user E. When remittance is made with user E as the remittance destination user, or as shown in Figure 8-2, when user A. A is user E. When sending a remittance request with E as the remittance request destination user, user E. Unprocessed requests corresponding to E can be displayed.

However, some users may wish to check unprocessed requests corresponding to users different from the other user.
Therefore, by way of example and not limitation, in FIGS. 8-1 and 8-2, user E. In addition to the outstanding requests corresponding to user B.E, by way of example and not limitation, user B. B and user C. It is also possible to display unprocessed requests corresponding to C.
Note that in this case, user E. By way of example and not limitation, user B. B and user C. It is also possible to display unprocessed requests corresponding to C.

In other words, the following three patterns can be considered as examples, not limitations, for displaying unprocessed requests.
(Pattern 1) Unprocessed requests corresponding to the other user (Pattern 2) Unprocessed requests corresponding to the other user + Unprocessed requests corresponding to a user different from the other user (Pattern 3) Different from the other user Outstanding requests corresponding to the user

Also, when applying any of the above patterns, for each user, all unprocessed requests corresponding to that user may be displayed, or some unprocessed requests corresponding to that user may be displayed. It may also be displayed.
In other words, the user whose unprocessed requests are displayed (the other user/user different from the other user) and the range (all/part) of the unprocessed requests to be displayed can be arbitrarily combined. As an example and not a limitation (pattern 2), unprocessed requests corresponding to the other user will display all unprocessed requests, but unprocessed requests corresponding to a user different from the other user will display some unprocessed requests. You may also display the request.

Furthermore, when displaying some unprocessed requests, the unprocessed requests to be displayed can be determined based on various information (conditions).
In this case, the contents of the 16th embodiment described later can be combined. As will be explained in the 16th embodiment, various types of information include, by way of example and not limitation, the following information.
・Date and time of sending/receiving the remittance request ・Amount of remittance request ・Payment deadline of remittance request ・Remittance request in which the user who made the remittance request and other users other than the user who received the remittance request are involved in the amount or reason for the remittance request , these information are just examples and are not limited to these.
Moreover, a combination of a plurality of pieces of information among these pieces of information can also be applied.

Users may forget unprocessed requests whose dates and times are older than a certain level. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
An unprocessed request in which the remittance request amount is larger than a certain level may be of high importance. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
A remittance request in which the user who requested the remittance and other users other than the user who requested the remittance are involved in the amount or reason for the remittance request may also have high importance. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
Outstanding requests with payment deadlines approaching within a certain period of time may require immediate processing. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.

Further, as will be explained in the 16th embodiment, the unprocessed requests can be sorted and displayed in ascending/descending order based on the above-mentioned various information (conditions). For example, unprocessed requests with higher importance can be displayed higher.

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

Furthermore, some users may feel bothered by the display of unprocessed requests.
Therefore, it may be possible to set display/non-display of unprocessed requests on a setting screen (not shown) or the like.

Specifically, as setting information regarding the display of unprocessed requests, slide buttons and check boxes that can switch between displaying and hiding unprocessed requests are displayed, by way of example and not limitation, on the application settings screen. Then, based on the operation on the slide button or check box, the terminal 20 or the server 10 can be made to set display/non-display.

In this case, display/non-display of unprocessed requests may be settable for all users at once, or display/non-display of unprocessed requests may be set individually for each user.
Further, display/non-display of all unprocessed requests may be settable, or display/non-display of some unprocessed requests may be settable.

Note that these contents also apply to the following examples.

<Effects of the eighth embodiment>
In this embodiment, the terminal 20 of the proposer's user sends information for remittance from the proposer's user (not limited, an example of a terminal user) to the other party's user (not limited, but an example of a first user). (an example of first information regarding a remittance from a user of a terminal to a first user), or information for sending a remittance request from a user of a proposer to a user of the other party (without limitation, an example of first information regarding a remittance from a user of a terminal to a first user); The first display based on the first information regarding the remittance request sent to one user) and the remittance request information regarding the received remittance request that the proposer user has received from the other user (not limited to, from the second user) An example of second information regarding a remittance request sent to a user of a terminal) or remittance request information regarding a sent remittance request sent by a proposer user to an opposite user (without limitation, information regarding a remittance request sent from a user of a terminal to a second user) The configuration is shown in which a second display based on an example of second information regarding a remittance request transmitted to a remittance request is displayed on the display unit 24.
As an example of the effect of the embodiment obtained by such a configuration, when the user of the terminal confirms the first information, it is possible to enable the user of the terminal to confirm the second information at the same time.

Further, in this embodiment, the terminal 20 of the proposer's user performs processing for remittance (not limited to remittance-related processing) based on the input by the proposer's user to the terminal 20 on which the first display is displayed. (Example)) is performed by the control unit 21.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily realize remittance to the other user based on the input to the terminal on which the first display is displayed.

<Eighth modification example>
In the above embodiment, settlement (batch settlement of unprocessed requests) is performed based on the input for the information of the unprocessed requests displayed together with the information for remittance to the other user and the information for sending the remittance request to the other user. ) can also be executed.

Specifically, in the screen example shown in Figure 8-1, which is not limited, in addition to the remittance button, a settlement button is displayed to execute settlement of the selected unprocessed requests (batch settlement if multiple selections are made). let
Then, when the payment button is tapped, the server 10 can perform payment processing for the selected unprocessed request.

Similarly, in the screen example shown in Figure 8-2, which is not a limitation, in addition to the remittance request button, a settlement button is displayed to execute settlement of the selected unprocessed requests (batch settlement if multiple requests are selected). .
Then, when the payment button is tapped, the server 10 can perform payment processing for the selected unprocessed request.

Note that the settlement process for unprocessed requests is as described above, and therefore will not be explained again.

FIG. 8-4 is a flowchart showing an example of the flow of processing executed by each device in this modification. Here, as an example, in the process of displaying unprocessed requests when a user makes a remittance shown in FIG. 8-3, a process of performing either remittance or settlement of unprocessed requests will be described.

After A125, the control unit 21 of the terminal 20A determines the execution target based on the input to the input unit (A631).
If it is determined that the execution target is settlement of unprocessed requests (batch settlement if multiple requests are selected) (A631: settlement of unprocessed requests), the control unit 21 of the terminal 20A executes the selected unprocessed requests. Request selection information including unprocessed request selection information shown is set (A632).

On the other hand, if it is determined that the execution target is remittance (A631: remittance), the control unit 21 of the terminal 20A sets request selection information including remittance information regarding the remittance 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 moves the process to A150.

After S120, if it is determined that the request selection information has been received from the terminal 20A (S140: YES), the control unit 11 of the 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 settlement target (if multiple selections are made, the batch settlement target) ( S642).
On the other hand, if it is determined that the processing target is "remittance", the control unit 11 of the server 10 sets remittance as the settlement target (S143).

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

When applying the first payment process described in FIG. 1-19 by way of example and not limitation,
If the settings in S642 are made and there are a plurality of unprocessed requests to be processed, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "YES". As a result, the processes from S1515 onwards are executed with these multiple unprocessed requests as the subject of batch settlement. Further, if the settings in S642 are made and there is one unprocessed request to be processed, the determination result in S1510 as to whether the payment target is a lump sum payment target is "NO". As a result, the processing from S1570 onwards is executed with this one unprocessed request as the subject of settlement.
On the other hand, if the settings in S143 are made, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "NO". As a result, the processing from S1570 onwards is executed with the remittance as the subject of settlement.

For the process of displaying unprocessed requests when a user makes a remittance request, and either sending the remittance request or settling the unprocessed request, please refer to "Remittance" in the process shown in Figure 8-4. Since it can be configured in the same way by replacing it with "transfer remittance request", illustration and explanation will be omitted.
Specifically, in the process of the terminal 20A, it is determined in A105 whether an input has been made to display the remittance request sending screen, the remittance request sending screen including the remittance request list information is displayed in A125, and the remittance request sending screen including remittance request list information is displayed in A631. It is determined whether the execution target is settlement of unprocessed requests or transmission of a remittance request, and request selection information including remittance request transmission information is set in A133.
In addition, in the processing of the server 10, it is determined in S641 whether the processing target is settlement of unprocessed requests or transmission of remittance requests, and transmission of remittance requests is set as the target of settlement in S143.

In this modification, the terminal 20 of the proposer's user sends information for remittance from the proposer's user (not a limitation, an example of a terminal user) to an opponent user (not a limitation, an example of a first user). (an example of first information regarding a remittance from a user of a terminal to a first user), or information for sending a remittance request from a user of a proposer to a user of the other party (without limitation, an example of first information regarding a remittance from a user of a terminal to a first user); The first display based on the first information regarding the remittance request sent to one user) and the remittance request information regarding the received remittance request that the proposer user has received from the other user (not limited to, from the second user) An example of second information regarding a remittance request sent to a user of a terminal) or remittance request information regarding a sent remittance request sent by a proposer user to an opposite user (without limitation, information regarding a remittance request sent from a user of a terminal to a second user) A second display based on the second information (an example of the second information regarding the remittance request transmitted to) is displayed on the display unit 24.
Then, the terminal 20 of the proposer's user performs processing for remittance or for receiving the remitted amount based on the input by the proposer's user to the terminal 20 on which the first display or the second display is displayed. or processing for sending/receiving a remittance request (remittance reminder) (an example of a first process related to remittance, receipt of remittance, or request for remittance, but not limited to) is performed by the control unit 21. It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, based on the input to the terminal on which the first display or the second display is displayed, remittance to the other user, receipt of remittance from the other user, It is possible to easily send/receive a remittance request to the other user.

Next, as an example related to the eighth example, when the user of the terminal 20 sends money to the other user or sends a remittance request to the other user, the user selects from among the displayed unprocessed requests. An example will be described in which the unprocessed requests received are also processed.

In the following embodiments, the following five patterns will be explained.
(A) Pattern for processing remittances + received remittance requests (B) Pattern for processing remittances + sent remittance requests (C) Pattern for sending remittance requests + processing received remittance requests (D) Sending remittance requests + Pattern for processing sent remittance requests (E) Pattern for processing remittance requests + received remittance requests + sent remittance requests Examples of each pattern will be explained separately.

As shown in the eighth modification, the processing (first processing, etc.) executed by the control unit 21 of the terminal 20 includes, by way of example and not limitation, processing for remittance (not limited to, processing related to remittance). (one example), processing for receiving remittances (receipt) (not limited to, but an example of processing related to receiving remittances), processing for sending/receiving remittance requests (not limited to, processing related to remittance requests) example).
In the following, a server-client system will be exemplified, and it is assumed that remittances, transmission of remittance requests, etc. are performed via the server 10.

Furthermore, as described above, the case where the other user is one user, that is, the second user is the first user (or the first user is the second user) will be exemplified below.
As mentioned above, when the other users are multiple different users, that is, when the first user is a different user from the second user (the second user is a different user from the first user) The method described below can be similarly applied to this case.

<Ninth Example>
The ninth embodiment is an embodiment related to processing of the pattern (A) above.
The content described in the ninth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In this embodiment, in addition to including "received remittance requests" among unprocessed requests in the batch settlement target, "remittance" is also included in the batch settlement subject to perform the batch settlement.

FIG. 9-1 is a diagram showing an example of a table for explaining the processing method corresponding to each pattern.
The vertical direction of the table shows the target of the process to be newly executed (new processing target) as an item, and the type of unprocessed request is shown as an item in the horizontal direction of the table. The column where the vertical item intersects with the horizontal item shows an example of the process realized by the combination of the new processing target and the unprocessed request of the type.

In this embodiment, processing of the pattern (A) remittance + received remittance request will be explained. With this pattern, it is possible to process (A1) remittance [remittance + remittance].
That is, when making a new remittance to the other user, the remittance to the other party is also made based on the remittance request that has already been received from the other user. More specifically, the sum of the amount to be transferred to the other party's user through a new remittance and the remittance request amount (the amount requested to be remitted by the other party's user) included in the received remittance request information is transferred to the other party. Send money to users.

<Display screen>
An example of a display screen when performing the process (A1) above will be described.
FIG. 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 shown by way of example and not limitation for user A. This is a remittance screen of the payment application displayed on the display unit 24 of A's terminal 20A.
In the current location display area CLR1 indicating the current location in the payment application, the characters "remittance" indicating that the current location is the remittance function of the payment application are displayed.

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

Further below, there is a configuration that allows you to check the outstanding requests of 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). An unprocessed request confirmation area URR1 is displayed.

At the top of the unprocessed request confirmation area URR1, user E. The characters "Unsettled request with E.E." indicating that an unprocessed request with E.E is displayed are displayed.
Further, below that, a lump sum payment amount (in this example, "1,500 yen") and a mark (in this example, a "payment mark") are displayed, assuming that all selections are to be paid at once.

Below that, the other party is user E. A list of remittance requests named E is displayed. In this example, the other party is user E. Unprocessed requests named E are listed in chronological order from the oldest to the top. The display mode of each unprocessed request can be configured in the same manner as in FIG. 1-11, by way of example and not limitation, and therefore will not be described again.

Below the unprocessed request confirmation area URR1, a remittance all selection batch settlement button labeled "Settle all and remit" is displayed to execute remittance processing and all selection batch settlement. Below that, there is a remittance lump sum settlement indicated as "Settlement and Send of 1 item" to execute the remittance processing and batch settlement of some of the unprocessed requests selected in the unprocessed request confirmation area URR1. A button BT11 is displayed. Further below that, a remittance button labeled ``Just remit money'' is displayed to allow only the remittance process to be executed.

As an example and not a limitation, in the unprocessed request confirmation area URR1, the request check for the first received remittance request (payment 2,500 yen) is set to "ON" and selected, and the remittance batch settlement button BT11 is tapped. Then, the terminal 20A requests the server 10 to perform remittance and batch settlement of the selected unprocessed requests. Then, from the server 10, the other party, user E. Settlement result information regarding the execution result is transmitted to E's terminal 20E.

FIG. 9-3 is a diagram showing an example of a notification screen displayed on the display section 24 of the terminal 20E based on the tapping of the remittance lump sum settlement button BT11.
In this example, two settlement result information are displayed in the notice information display area NTR4 of the notice screen as contents of remittance and lump sum settlement.
Specifically, by way of example and not limitation, user A. A is user E. User A. receives the remittance amount "500 yen" sent to E and receives the first remittance request selected in Figure 9-2. A is user E. Settlement result information corresponding to the receipt of the remittance amount "2,500 yen" based on the remittance request amount "2,500 yen" based on the remittance request received from E is displayed.

As shown in Figure 9-4, the two payment result information may be combined and displayed as one payment result information in the notification information display area NTR4 of the notification screen, or it is not necessary to do so. Good too.
By way of example and not limitation, in FIG. 9-4, user E. E is user A. The remittance amount "500 yen" upon receiving the remittance from user A, and the remittance amount "500 yen" from user A. Information regarding receiving "3,000 yen", which is the sum of the remittance amount "2,500 yen" obtained by receiving the remittance request amount "2,500 yen" from the remittance request to A, is displayed.

In FIG. 9-2, the unprocessed request confirmation area URR1 displays the unprocessed requests of the user selected as the remittance destination and the user making the remittance, but the present invention is not limited thereto.

FIG. 9-5 shows an example of a display screen when displaying all unprocessed requests of users who make remittances. FIG. 9-5 is another example of the remittance screen shown in FIG. 9-2.

In FIG. 9-5, in the unprocessed request confirmation area URR2, all unprocessed requests of users who send money are displayed in chronological order from the top to the oldest. Further, below the unprocessed request confirmation area URR2, a remittance bulk settlement button BT11 and a remittance button are displayed. By way of example and not limitation, in the unprocessed request confirmation area URR2, the fourth user E. When the check of the received remittance request (payment 2,500 yen) from E is set to "ON" and the remittance batch settlement button BT11 is tapped, the display screen of Figure 9-3 will be displayed on the terminal 20E. It is displayed on the display section 24.

<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 flowchart in which the flowchart of FIG. 1-18 has been rewritten to include a process in which the new processing target is "remittance".

In the processing of the pattern (A) remittance + received remittance request in this embodiment, the remittance is made unilaterally to the other user, so the approval of the other user is not required when performing bulk payment. be able to. Therefore, here, the process will be illustrated and explained as a process that does not require the approval of the other user.
Note that the present invention is not limited to this, and the other user's approval 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 execution of remittance + unprocessed request processing is requested (A131: YES), the control unit 21 of the terminal 20A sends remittance information related to the remittance to be executed and the selection. Request selection information including unprocessed request selection information indicating the unprocessed requests that have been processed is set (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 remittance is to be executed (A131: NO), the control unit 21 of the terminal 20A sends remittance information regarding the remittance to be executed. The request selection information to be included is set (A133).

Note that this process will be explained on the assumption that remittance will be made.
In reality, it may be possible to choose to process only unprocessed requests without remittance, but in this case, the process is similar to the process for bulk settlement of unprocessed requests described above, so it is not shown in the diagram.・Omit the explanation again.

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 moves the process to A150.

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 performs remittance + unprocessed request based on the information included in the received request selection information. It is determined whether or not to process (S141). If it is determined to be processed (S141: YES), the control unit 11 of the server 10 sets remittance + settlement of the selected unprocessed requests (batch settlement if multiple selections are made) as the batch settlement target. (S142).

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

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

When applying the first payment process described in FIG. 1-19 by way of example and not limitation,
If the settings in S142 are made, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "YES". As a result, the processing from S1515 onwards is executed, with the remittance + settlement of the selected unprocessed request as the subject of collective settlement.
On the other hand, if the settings in S143 are made, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "NO". As a result, the processing from S1570 onwards is executed with the remittance as the subject of settlement.

<Effects of the ninth embodiment>
In this embodiment, the terminal 20 of the proposer's user sends remittance information (limited to An example of first information regarding a remittance from a user of a terminal to a first user) or remittance request information regarding a remittance request sent from a user of a proposer to a user of the other party (without limitation, an example of first information regarding a remittance from a user of a terminal to a first user) The first display based on the first information regarding the remittance request sent to the user) and the remittance request information regarding the received remittance request that the proposer user has received from the other user (not limited to example of the second information regarding the remittance request sent to the user of the user), or remittance request information regarding the sent remittance request sent by the proposer's user to the other user (without limitation, from the user of the terminal to the second user) A second display based on the second information (an example of the second information regarding the transmitted remittance request) is displayed on the display unit 24.
Then, the proposer's user terminal 20 performs processing for remittance or for receiving the remitted amount based on the input by the proposer's user to the terminal 20 on which the first display or the second display is displayed. or processing for sending/receiving a remittance request (remittance reminder) (an example of a first process related to remittance, receipt of remittance, or request for remittance, but not limited to) is performed by the control unit 21. It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, based on the input to the terminal on which the first display or the second display is displayed, it is possible to send money to the other user or receive money from the other user ( (receiving money), sending a remittance request to the other user, receiving a remittance request from the other user, etc. can be easily realized.

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

Further, in this embodiment, the first information is remittance information from the proposer's user to the other party's user (not limited to, but is an example of information regarding remittance from the terminal user to the first user), and the second information is is received remittance request information regarding a remittance request that has already been received from the other user (not limited to, but is an example of information regarding a remittance request sent from the second user to the user of the terminal), and the first process is the remittance request information that has been received from the other user. The configuration includes a process of remitting money to the other user based on the information and the received remittance request information.
As an example of the effect of the embodiment obtained by such a configuration, information regarding remittance from the terminal user to the first user and information regarding the remittance from the second user to the terminal user are transmitted based on inputs to the first display and the second display. It is possible to easily realize remittance between the first user and the second user based on the information regarding the transmitted remittance request.

Also, in this case, the other user is one user (an example, not a limitation, where the second user is the first user), and the first process is to transfer money from the proposer's user to the other user. Send the sum of the amount and the remittance request amount included in the received remittance request information from the other user (not a limitation, but an example of the amount based on the first information and the second information) to the other user. Processing may be included.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to remit an amount of money based on the first information and the second information to one and the same user.

<9th modification example>
In the above embodiment, as an example of the amount based on the first information and the second information, the amount to be remitted from the proposer's user to the other user, and the remittance request included in the received remittance request information from the other user. Although the case where the total amount of money is remitted to the other user is illustrated, the present invention is not limited to this.

A case can be assumed in which the proposing user borrows money from the other user. In such a case, by way of example and not limitation, the proposer user may remit money with interest to the other user.
Specifically, as an example and not a limitation, the proposer's user's terminal 20 side or the server 10 side may charge a preset percentage of interest on the sum of the above amounts (as an example and not a limitation, 5% interest) can be automatically added, and the amount to which interest has been added is used as the remittance amount, and can be remitted from the proposer user to the other party's user.

Note that this method also applies to the case where the other user remits an amount based on the first information and the second information.

<10th example>
The tenth embodiment is an embodiment related to processing of the pattern (B) described above.
The content described in the tenth embodiment is applicable to each of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In this embodiment, in addition to including "sent remittance requests" among unprocessed requests in the batch settlement target, "remittance" is also included in the batch settlement subject to perform the batch settlement.

This will be explained with reference to the table in FIG. 9-6 again.
In this embodiment, the pattern (B) remittance + sent remittance request is processed.
In this pattern, either (B1) remittance + remittance reminder, or (B2) [remittance + receipt] (amount can be deducted) can be performed.

In the process (B1), when making a new remittance to the other user, a remittance reminder to the other user is also performed based on the remittance request that has already been sent to the other user.
Note that instead of the remittance reminder, a new remittance request may or may not be made.

In the process (B2), when making a new remittance to the other user, the money is received from the other user based on the remittance request that has already been sent to the other user.
In this case, since there is a contradictory relationship between payment and receipt of money, it is possible to remit/receive the amount equal to the difference between the remittance request amount.
Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.

Specifically, the amount obtained by subtracting the remittance request amount included in the sent remittance request information from the amount to be remitted from the proposer's user to the other user is remitted to the other user.
Or, conversely, an amount obtained by subtracting the amount to be remitted from the proposer user to the other user from the remittance request amount included in the sent remittance request information is received from the other user.

<Display screen>
First, an example of a display screen when performing the process (B1) above will be described.
FIG. 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 shown by way of example and not limitation for user A. This is a remittance screen of the payment application displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, as an example and not a limitation, it is possible to configure the screen in the same manner as in FIG. 9-2, so a detailed explanation will be omitted.

As an example and not a limitation, in the unprocessed request confirmation area URR1, the request check for the second sent remittance request (receipt 1,000 yen) is selected as "ON", and the remittance batch settlement button BT11 is tapped. Then, the terminal 20A requests the server 10 to perform remittance and batch settlement of the selected unprocessed requests. Then, from the server 10, the other party, user E. Settlement result information regarding the execution result is transmitted to E's terminal 20E.

FIG. 10-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E based on the tapping of the remittance lump sum settlement button BT11.
In this example, two settlement result information are displayed in the notice information display area NTR4 of the notice screen as contents of remittance and lump sum settlement.
Specifically, by way of example and not limitation, user A. A is user E. Settlement result information corresponding to the receipt of the remittance amount "500 yen" sent to E. and the second remittance request selected in Figure 10-1 (remittance request amount sent by user A.A to user E.E. A reminder corresponding to a remittance request of "1,000 yen" is displayed.

Next, an example of a display screen when performing the process (B2) above 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 shown by way of example and not limitation for user A. This is a remittance screen of the payment application displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, as an example and not a limitation, it is possible to configure the screen in the same manner as in FIG. 9-2, so a detailed explanation will be omitted. Note that in FIG. 10-3, by way of example and not limitation, the amount to be remitted to the user selected as the remittance destination is "1,500 yen."

As an example and not a limitation, in the unprocessed request confirmation area URR1, the request check for the second sent remittance request (receipt 1,000 yen) is selected as "ON", and the remittance batch settlement button BT11 is tapped. Then, the terminal 20A requests the server 10 to perform remittance and batch settlement of the selected unprocessed requests. Then, from the server 10, the other party, user E. Lump-sum payment approval confirmation information for confirming whether or not to approve the lump-sum payment is sent to the terminal 20E of E, and is displayed on the display unit 24 of the terminal 20E.

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

The lump sum payment approval confirmation information includes user E. E is user A. A to user E. User A receives "1,500 yen" from this remittance sent to User A. It is displayed that the remittance request amount "1,000 yen" is to be paid based on the receipt of a past remittance request from A.

As an example and not a limitation, the contents of a lump sum payment can be stored by tapping the "close" icon of the lump sum payment approval confirmation information, and can be expanded by tapping the "Summary" icon from the stored state. Is possible.

In addition, the lump sum payment approval confirmation information includes user E. E is user A. From A, it is displayed that "500 yen" will be received, which is the amount obtained by subtracting the remittance request amount "1000 yen" from the remittance request from the remittance amount "1,500 yen".

At the bottom of the lump sum payment approval confirmation information, there is a payment button BT12 that says "Payment" to approve the payment with the above content, and a payment button BT12 that says "Decline" to decline the payment without approving the payment with the above content. The indicated Reject button is displayed.

FIG. 10-5 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT12.
Below the current position display area CLR1, the user E. A notification NT2 containing a bell mark and the words "500 yen has been remitted" is displayed as a notification that the batch settlement of the remittance request has been approved from E's terminal 20E, and the remittance has been made as a result.

Furthermore, information corresponding to the above notification NT2 is displayed in the notification information display area NTR2 of the notification screen.
In this example, the announcement information display area NTR2 of the announcement screen includes user E. As a lump-sum payment was made with E.E, the content of the lump-sum payment is the payment result information (in this example, the payment of the remittance amount "500 yen" sent by User A.A to User E.E). is displayed.

In addition, in FIG. 10-3, when the remittance lump sum settlement button BT11 is tapped, a message appears on the display section 24 of the terminal 20A, and when the settlement is performed, the user A. User A displays a confirmation screen to the effect that he/she will be paying a lump sum payment amount of "500 yen". Based on A's approval, remittance and batch settlement of the selected unprocessed requests may or may not be requested.

<Processing>
The processing executed by each device in this embodiment can be similarly realized by following the processing shown in FIG. 9-6.
However, when executing the process (B2) [Remittance + Receipt] (amount can be deducted), the process of remittance by the other user is included. Therefore, as described above, when performing a lump sum payment, the approval of the other user may be required.

FIG. 10-6 is a flowchart showing an example of the flow of processing executed by each device in this case.
This flowchart is a flowchart that applies the process of FIGS. 1-21 to the process of FIGS. 9-6, by way of example and not limitation.
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 10th Example>
In this embodiment, the above-mentioned first information is remittance information from the proposer's user to the other party's user (not limited to, but is an example of information regarding remittance from the terminal user to the first user), and the second information is indicates a configuration that is sent remittance request information (not limited to, but an example of information regarding a remittance request sent from a terminal user to a second user) regarding a remittance request that has already been sent from the proposer's user to the other party's user. ing.
As an example of the effect of the embodiment obtained by such a configuration, a remittance from the terminal user to the first user and a remittance request sent from the terminal user to the second user can be processed together. .

Further, in this case, the first process can include processing of remitting 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, remittance to the first user and request for remittance to the second user can be performed at the same time.

Furthermore, in this embodiment, 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 is to transfer money from the proposer user to the other user. A process of remitting to the other user an amount based on the remittance request amount included in the sent remittance request information and the remittance request amount included in the sent remittance request information (an example of an amount based on the first information and the second information, but not limited to). The configuration includes a process of remitting money to the first user) or a process of receiving money from the first user (not limited to this, but an example of a process of remitting money from the first user).
As an example of the effect of the embodiment obtained by such a configuration, an amount based on the first information and the second information is remitted to one and the same user, or an amount based on the first information and the second information is transferred. You can send and receive money.

In addition, in this case, the first process is based on the remittance request amount included in the sent remittance request information (not a limitation, but an example of the first amount) to be remitted from the proposer's user to the other party's user. The process of remitting the amount after deducting the amount (not limited to, but an example of the second amount) to the other user (not limited to, but an example of the process of remitting the money to the first user), or 2 amount) minus the amount to be remitted from the proposer's user to the other user (first amount) from the other user (not limited to the process of remitting money from the first user) example).
As an example of the effect of the embodiment obtained by such a configuration, an amount corresponding to the difference between the first amount and the second amount is remitted to one and the same user, or an amount corresponding to the difference between the first amount and the second amount is remitted. You can have the difference amount sent to you and receive it.

Further, the present embodiment shows a configuration in which 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 the effect of the embodiment obtained by such a configuration, the first process can be executed based on the first user's approval based on the input to the first user's terminal. As a result, by way of example and not limitation, it is possible to prevent the first process from being executed against the first user's wishes.

<Eleventh Example>
The eleventh embodiment is an embodiment related to processing of the pattern (C) described above.
The content described in the eleventh embodiment is applicable to each of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In this embodiment, in addition to including "received remittance requests" among unprocessed requests in the batch settlement, "transmission of remittance request" is included in the batch settlement to perform batch settlement.

This will be explained with reference to the table in FIG. 9-6 again.
In this embodiment, a pattern of (C) sending remittance request + received remittance request is processed.
In this pattern, either (C1) remittance request + remittance, or (C2) [receipt + remittance] (amount can be deducted) can be performed.

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

In the process (C2), when making a new remittance request to the other user, the other user sends and receives the money based on this new remittance request, and the remittance that has already been received from the other user is received. Based on the request, remittances are also made to the other user.
In this case, the difference between the remittance request amount can be received/remitted.
Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.

<Display screen>
First, an example of a display screen when performing the process (C1) above will be described.
FIG. 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 shown by way of example and not limitation for user A. This is a remittance request screen of the payment application displayed on the display unit 24 of A's terminal 20A.
In the current position display area CLR1 indicating the current position in the payment application, the characters "Remittance Request" indicating that the current position is the remittance request function of the payment application are displayed.

Below the current position display area CLR1, an icon image and a user name (user EE in this example) in the payment application of the user selected as the destination of the remittance request are displayed. Also, below that, the remittance request amount for the user selected as the recipient of the remittance request (in this example, "500 yen") and a function button to increase the remittance request amount by a certain amount are displayed. There is. If the user selected as the destination of the remittance request accepts the remittance request, the transfer will be made from the electronic money account of the user selected as the destination of the remittance request to the electronic money account of the user who made (sent) the remittance request. The remittance for the remittance request amount is executed.

Further below, an unprocessed request confirmation area URR1 is displayed. The unprocessed request confirmation area URR1 can be configured in the same manner as shown in FIG. 9-2, by way of example and not limitation, so a description thereof will be omitted.

Below the unprocessed request confirmation area URR1, a Send Remittance Request Send All Selection Batch Settlement button that says "Settle All and Request Remittance" is displayed in order to execute the sending process of the remittance request and the batch settlement of all selections. has been done. Below that, "1 settlement and remittance request" is displayed to execute the remittance request sending process and partial selective batch settlement of the unprocessed requests selected in the unprocessed request confirmation area URR1. A remittance request transmission batch settlement button BT13 is displayed. Further below, a remittance request transmission button labeled "Only request remittance" is displayed for executing only remittance request transmission processing.

As an example and not as a limitation, in the unprocessed request confirmation area URR1, the request check for the first received remittance request (payment 2,500 yen) is set to "ON" and selected, and the remittance request transmission bulk settlement button BT13 is selected. When tapped, the terminal 20A requests the server 10 to send a new remittance request and to collectively settle the selected unprocessed requests. Then, from the server 10, the other party, user E. Remittance request information and settlement result information regarding the execution result of the lump sum settlement are transmitted to the terminal 20E of E.

FIG. 11-2 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20E based on the tapping of the remittance request transmission batch settlement button BT13.
In this example, settlement result information regarding one remittance request selected in FIG. 11-1 and new remittance request information are displayed in the announcement information display area NTR4 of the announcement screen.

The payment result information includes user E. E is user A. Information regarding the receipt of the remittance request amount "2,500 yen" from the remittance request to A is displayed.

Remittance request information may include, by way of example and not limitation, user A. A is user E. A remittance request for the remittance request amount "500 yen" sent to E, a remittance request button that says "send money" to approve this remittance request and send money based on the remittance request, and a remittance button that says "send money" to send money based on the remittance request. A remittance request rejection button labeled "Decline" is displayed for refusing the remittance request without approval.

Next, an example of a display screen when performing the process (C2) 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 shown by way of example and not limitation for user A. This is a remittance request screen of the payment application displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, it is possible to configure it in the same manner as in FIG. 11-1 by way of example and not limitation, so a detailed explanation will be omitted. Note that in FIG. 11-3, by way of example and not limitation, the amount of money requested to be remitted to the user selected as the destination of the remittance request (user E.E in this example) is "1,000 yen."

As an example and not as a limitation, in the unprocessed request confirmation area URR1, the request check for the first received remittance request (payment 2,500 yen) is set to "ON" and selected, and the remittance request transmission bulk settlement button BT13 is selected. When tapped, the terminal 20A requests the server 10 to send a new remittance request and to collectively settle the selected unprocessed requests. Then, from the server 10, the other party, user E. Lump-sum payment approval confirmation information for confirming whether or not to approve the lump-sum payment is sent to the terminal 20E of E, and is displayed on the display unit 24 of the terminal 20E.

FIG. 11-4 is a diagram showing an example of a notification screen that is displayed based on tapping the remittance request transmission batch settlement button BT13.
In the announcement information display area NTR4, user A. The icon image of A and the lump sum payment amount are displayed.

In this example, the lump sum payment approval confirmation information includes user E. E is user A. User A receives the remittance request amount "2,500 yen" based on the remittance request sent to User A. It is displayed that the remittance request amount "1,000 yen" will be paid based on the reception of the current remittance request from A.

In addition, the lump sum payment approval confirmation information includes user E. E is user A. From A, it is displayed that ``1,500 yen'' will be received, which is obtained by subtracting the ``1,000 yen'' remittance request amount for payment from the ``2,500 yen'' remittance request amount for receipt.

At the bottom of the bulk payment approval confirmation information, there is a payment button BT14 that says "Payment" to approve the payment with the above content, and a payment button BT14 that says "Decline" to decline the payment without approving the payment with the above content. The indicated Reject button is displayed.

FIG. 11-5 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT14.
Below the current position display area CLR1, the user E. The batch payment for the remittance request has been approved from E's terminal 20E, and a notification NT3 containing the words "1,500 yen has been remitted" is displayed along with a bell mark as a notification that the remittance has been made. There is.

Furthermore, information corresponding to the above notification NT3 is displayed in the notification information display area NTR2 of the notification screen.
In a specific example, user E. The payment result information is displayed because the lump sum payment was made with E. In this example, the payment result information includes user A. A to user E. It is displayed that a remittance of "1,500 yen" has been made to E.

In addition, the payment result information includes the details of the lump-sum payment: ``2,500 yen'' will be paid based on the receipt of the past remittance request, and ``1,000 yen'' will be received based on the sending of the current remittance request. is displayed.

In addition, in FIG. 11-3, when the remittance request transmission batch settlement button BT13 is tapped, the display unit 24 of the terminal 20A will display a message indicating that the user A. User A displays a confirmation screen to the effect that he will receive "1,000 yen", and user A. Based on A's approval, the sending of the remittance request and the batch settlement of the selected unprocessed requests may or may not be requested.

<Processing>
FIG. 11-6 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
This flowchart is a flowchart in which the flowchart in FIG. 1-18 has been rewritten to include a process in which the new process target is "send 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 here assuming that making a remittance request (transmission of a remittance request) is also a type of settlement.
Note that, different from this, the flowchart can also be configured such that making a remittance request (transmission of a remittance request) is a separate process from settlement.

In addition, in the process of pattern (C) in this embodiment, as an example and not a limitation, when performing the process (C1), the other party's approval is not required, and when performing the process (C2), the other party's approval is not required. User approval may be required.
Here, for the sake of simplicity, we will exemplify the process (flowchart) when the other user's approval is not required.

First, the control unit 21 of the terminal 20A determines whether or not to transmit a remittance request based on whether an input for transmitting 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. Thereafter, based on receiving the remittance request list information from the server 10 through the communication I/F 22, the control unit 21 of the terminal 20A displays a remittance request transmission screen (screen for remittance request transmission) that includes the received remittance request list information. is displayed on the display unit 24 (A127).

Thereafter, the control unit 21 of the terminal 20A determines whether 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 to request transmission of a remittance request + execution of processing of the unprocessed request (A135: YES), the control unit 21 of the terminal 20A transmits the remittance request to be executed. Request selection information including remittance request transmission information regarding the selected unprocessed request and unprocessed request selection information indicating the selected unprocessed request is set (A136).

On the other hand, if an unprocessed request is not 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 the terminal 20A transmits the remittance request transmission information. request selection information including (A137).

Note that this process will be explained on the assumption that a remittance request will be sent.
In reality, you may choose to process only unprocessed requests without sending remittance requests, but in this case, the process is similar to the process for bulk settlement of unprocessed requests described above. Therefore, illustration and re-explanation 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 moves the process to A150.

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 sends the remittance request + unprocessed request based on the information included in the received request selection information. , is to be processed (S144). If it is determined to be processed (S145: YES), the control unit 11 of the server 10 sets the remittance request transmission + settlement of the selected unprocessed requests (if multiple selections are made, batch settlement) as the subject of batch settlement. Set (S146).

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

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

When applying the first payment process described in FIG. 1-19 by way of example and not limitation,
If the settings in S146 are made, the determination result in S1510 as to whether or not the payment target is a lump sum payment 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 subject of collective settlement.
On the other hand, if the settings in S147 are made, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "NO". As a result, the processing from S1570 onwards is executed with the remittance request transmission as the subject of settlement.

<Effects of the 11th embodiment>
In this embodiment, the first information is remittance request transmission information for transmitting a remittance request from the proposer's user to the other party's user (not limited to information regarding the remittance request transmitted from the terminal user to the first user). (one example), and 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). It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, a remittance request sent from the terminal user to the first user and a remittance request sent from the second user to the terminal user are processed together. I can do it.

Furthermore, in this case, the first process may include a process of transmitting remittance request information to the other user based on the remittance request sending information and remitting money to the other user based on the received remittance request information. I can do it.
As an example of the effect of the embodiment obtained by such a configuration, a remittance request to the first user and a remittance to the second user can be performed at the same time.

Furthermore, in this embodiment, the other user is one user (an example, not a limitation, where the second user is the first user), and the first process is performed on remittance request information to be sent to the other user. Indicates a configuration that includes processing to send to or receive from the other user an amount based on the included remittance request amount and the remittance request amount included in the received remittance request information from the other user. ing.
As an example of the effect of the embodiment obtained by such a configuration, an amount based on the first information and the second information can be sent to the first user, or can be received by having the money sent from the first user.

In addition, in this case, the first process is to convert the remittance request amount (second amount) included in the remittance request information received from the other user to the remittance request amount (second amount) included in the remittance request information to be sent to the other user. The process of remittance to the other user by deducting the amount (first amount) from the remittance request amount (first amount) included in the remittance request information sent to the other user, or the received remittance request from the other user. It is possible to include a process of receiving money from the other user after subtracting the remittance request amount (second amount) included in the information.
As an example of the effect of the embodiment obtained by such a configuration, an amount corresponding to the difference between the first amount and the second amount is remitted to one and the same user, or an amount corresponding to the difference between the first amount and the second amount is remitted. You can have the difference amount sent to you and receive it.

Further, the present embodiment shows a configuration in which 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 the effect of the embodiment obtained by such a configuration, the first process can be executed based on the first user's approval based on the input to the first user's terminal. As a result, by way of example and not limitation, it is possible to prevent the first process from being executed against the first user's wishes.

<12th example>
The twelfth embodiment is an embodiment related to processing of the pattern (D) described above.
The content described in the twelfth embodiment is applicable to each of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In this embodiment, in addition to including "sent remittance requests" among unprocessed requests in the batch settlement target, "transmission of remittance request" is included in the batch settlement target to perform the batch settlement.

This will be explained with reference to the table in FIG. 9-6 again.
In this embodiment, a pattern of (D) sending remittance request + sent remittance request is processed.
In this pattern, either (D1) remittance request + [remittance request or remittance reminder] or (D2) integrated remittance request can be processed.

In the process (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 made based on the remittance request that has already been sent to the other user. At the same time,

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

In the process (D2), when making a new remittance request to the other user, a request is made that combines (integrates) this new remittance request with a remittance request based on the remittance request that has already been sent to the other user. , send an integrated remittance request to the other user.

<Display screen>
Examples of display screens 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 shown by way of example and not limitation for user A. This is a remittance request screen of the payment application displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, it is possible to configure it in the same manner as in FIG. 11-3 by way of example and not limitation, so a detailed explanation will be omitted.

As an example and not as a limitation, in the unprocessed request confirmation area URR1, the request check for the second sent remittance request (receipt 1,000 yen) is set to "ON" and selected, and the remittance request transmission bulk settlement button BT13 is selected. When tapped, the terminal 20A requests the server 10 to send a new remittance request and to collectively settle the selected unprocessed requests. Then, from the server 10, the other party, user E. New remittance request information and remittance reminder information based on past remittance request transmissions are transmitted to the terminal 20E of E, and are displayed on the display unit 24 of the 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 based on the tapping of the remittance request transmission batch settlement button BT13.
In this example, the notification information display area NTR4 of the notification screen contains reminder information regarding one remittance request selected in Figure 12-1 (in this example, the amount requested for remittance from user A.A to user E.E. A reminder regarding a remittance request for "1,000 yen") and new remittance request information (in this example, a remittance request for the remittance request amount of "1,500 yen" from user A.A to user E.E). Displayed.

Furthermore, in the batch payment process, new remittance requests and past remittance requests can be integrated.
FIG. 12-3 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 announcement information display area NTR4, user A. The icon image of A and the lump sum payment amount are displayed. In this example, user E. E is user A. It is displayed that "2,500 yen", which is the sum of the remittance request amount "1,000 yen" and the remittance request amount "1,500 yen", is to be paid to A.

In addition, the bulk payment approval confirmation information includes user E. E is user A. A is user E. It is displayed that the remittance request amount "1,000 yen" is to be paid based on the past remittance request sent to E, and the remittance request amount "1,500 yen" is to be paid based on the current remittance request.

At the bottom of the lump sum payment approval confirmation information, there is a payment button BT15 that says "Payment" to approve the payment with the above content, and a payment button BT15 that says "Decline" to decline the payment without approving the payment with the above content. The indicated Reject button is displayed.

FIG. 12-4 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT15.
Below the current position display area CLR1, the user E. The batch payment of the remittance request is approved from the terminal 20E of user E. As a notification that money has been sent from E, a notification NT4 containing a bell mark and the words ``Remittance has been received.'' is displayed.

Furthermore, information corresponding to the above notification NT4 is displayed in the notification information display area NTR2 of the notification screen.
In a specific example, user E. The payment result information is displayed because the lump sum payment was made with E. In this example, the payment result information includes user A. A is user E. It is displayed that a remittance of ``2,500 yen'', which is the sum of the remittance request amount ``1,000 yen'' and the remittance request amount ``1,500'' to E, has been received.

In addition, the payment result information includes user A. A is user E. It is displayed that the remittance request amount of ``1,000 yen'' was received based on sending a past remittance request to E, and that the remittance request amount of ``1,500 yen'' was received based on sending the current remittance request. There is.

<Processing>
The processing executed by each device in this embodiment can be implemented in the same manner as the processing shown in FIG. 11-6, so illustrations and detailed explanations will be omitted.

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

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

In addition, in the above, the other user is one user (an example, but not limited to, the second user is the first user), and the first process is the remittance request amount and the remittance request amount of the remittance request sent to the other user. , a configuration including a process of transmitting an integrated remittance request (an example of a third remittance request, not a limitation) to the first user, in which the remittance request amount is the sum of the remittance request amount included in the sent remittance request information. It shows.
As an example of the effect of the embodiment obtained by such a configuration, by sending a third remittance request to the first user based on the third amount that is the sum of the first amount and the second amount, the terminal The first user can be effectively urged to make a remittance to the user.

<13th example>
The 13th embodiment is an embodiment related to processing of the pattern (E) described above.
The contents described in the thirteenth embodiment are applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In this example, in addition to including "received remittance requests" and "sent remittance requests" among unprocessed requests, "sending remittance requests" is included in the batch settlement, and the batch settlement is performed. I do.

This will be explained with reference to the table in FIG. 9-6 again.
In this pattern, (E1) remittance request + [remittance + receipt] (amount can be deducted), (E2) [receipt + remittance] (amount can be deducted) + [remittance request or remittance reminder], (E3) [receipt] Either of the following processes can be performed: money + remittance] (amount can be deducted) + [remittance + money received] (amount can be deducted).

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

In the process (E2), when making a new remittance request to the other user, the other user sends and receives the money based on this new remittance request, and the remittance that has already been received from the other user is received. Based on the request, remittances are also made to the other user. In this case, the difference between the requested remittance amount can be received/remitted. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.
Furthermore, based on the remittance request that has already been sent to the other user, the same remittance request is made to the other user, or a remittance reminder is sent to the other user.

In the process (E3), when making a new remittance request to the other user, the other user sends and receives the money based on this new remittance request, and the remittance that has already been received from the other user is received. Based on the request, remittances are also made to the other user. In this case, the difference between the requested remittance amount can be received/remitted. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.
Furthermore, the system sends money to the other user based on a remittance request that has been received from the other user, and receives money by receiving money from the other user based on the remittance request that has already been sent to the other user. In this case, it is possible to remit/receive the difference in the remittance request amount. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.

<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 shown by way of example and not limitation for user A. This is a remittance request screen of the payment application displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, it is possible to configure it in the same manner as in 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 amount of money requested to be remitted to the user selected as the destination of the remittance request (in this example, user E.E.) is "1,200 yen."

As an example and not as a limitation, both the first received remittance request (payment 2,500 yen) and the second sent remittance request (receipt 1,000 yen) are displayed in the unprocessed request confirmation area URR1. When the check is set to "ON" and the remittance request transmission bulk settlement button BT13 is tapped, a new remittance request is sent from the terminal 20A to the server 10, and the selected unprocessed requests are collectively settled. is requested to execute. Then, from the server 10, the other party, user E. Lump-sum payment approval confirmation information for confirming whether or not to approve the lump-sum payment is sent to the terminal 20E of E, and is displayed on the display unit 24 of the terminal 20E.

FIG. 13-2 is a diagram showing an example of a notification screen that is displayed based on tapping the remittance request transmission batch settlement button BT13.
In the announcement information display area NTR4, user A. The icon image of A and the lump sum payment amount are displayed.

In this example, the lump sum payment approval confirmation information includes user E. E is user A. User A receives the remittance request amount "2,500 yen" based on the past remittance request sent to A. User A pays the remittance request amount "1,000 yen" based on the past remittance request received from A. It is displayed that the remittance request amount "1,200 yen" will be paid based on the reception of the current remittance request from A.

In addition, the lump sum payment approval confirmation information includes user E. E is user A. From the remittance request amount "2,500 yen" received from user A. It is displayed that "300 yen" will be received, which is the sum of the remittance request amount "1,000 yen" to be paid to A and the remittance request amount "1,200 yen".

At the bottom of the lump sum payment approval confirmation information, there is a payment button BT16 that says "Payment" to approve the payment with the above content, and a payment button BT16 that says "Decline" to decline the payment without approving the payment with the above content. The indicated Reject button is displayed.

FIG. 13-3 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT16.
Below the current position display area CLR1, the user E. A notification NT5 containing a bell mark and the words "300 yen has been remitted" is displayed as a notification that the batch settlement of the remittance request has been approved from E's terminal 20E, and the remittance has been made as a result.

Furthermore, information corresponding to the above notification NT5 is displayed in the notification information display area NTR2 of the notification screen.
In a specific example, user E. The payment result information is displayed because the lump sum payment was made with E. In this example, the payment result information includes user A. A is user E. It is displayed that "300 yen" was paid to E.

In addition, the payment result information includes user A. A is user E. User E. pays the remittance request amount "2,500 yen" based on the past remittance request received from E. User E receives the remittance request amount "1,000 yen" based on the past remittance request sent to E. It is displayed that the remittance request amount "1,200 yen" was received based on the current remittance request sent to E.

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

<Fourteenth example>
The fourteenth embodiment is an embodiment related 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 other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In addition to the patterns described above, by way of example and not limitation, there are patterns of combinations of new processing targets in the table of FIG. 9-6, that is,
・It is also possible to process a pattern of remittance + send remittance request.

The processing for this pattern is similar to the processing for pattern (C).
In other words, either "remittance + send remittance request" or "remittance + receipt (amount can be deducted)" can be performed.
Note that when performing the process of "remittance + money receipt (amount can be deducted)", approval from the other user may or may not be obtained.

<Effects of the 14th Example>
In this embodiment, the first information is remittance request information from the proposer's user to the other party's user, and the terminal 20 of the proposer's user transmits the remittance request information ( A third display based on (not limited to, but an example of the third information) is displayed on the display unit 24. Then, the terminal 20 of the proposer's user displays a remittance display (an example of the first display, not a limitation) from the proposer's user to the other party's user, and the above-mentioned third display. The configuration is shown in which the control unit 21 performs second processing regarding remittance, receipt, or remittance request based on input to the terminal 20.
As an example of the effects of the embodiment obtained by such a configuration, it is possible to send money, receive money, or request money.

In addition, in the above, the second process is to send money to the other user based on the remittance information (not limited to, an example of the first information), and to send money based on the remittance request information sent from the proposer user to the other user. It shows a configuration that includes processing to send a remittance request to the other user.
As an example of the effect of the embodiment obtained by such a configuration, remittance to the first user based on the first information and transmission of a remittance request to the first user based on the third information can be performed at the same time. .

In addition, in the above, the second process includes an amount based on the amount that the proposer's user remits to the other user and the remittance request amount that the proposer's user requests from the other user (not limited to the first information and the third information) to the other user or receiving the money from the other user.
As an example of the effect of the embodiment obtained by such a configuration, an amount based on the first information and the third information can be paid to or received from the first user.

Further, in this case, the second process is to remit to the other user an amount obtained by subtracting the remittance request amount that the proposer user requests from the other user from the amount that the proposer user remits to the other user. Alternatively, the configuration includes a process of receiving from the other user an amount obtained by subtracting the amount to be remitted by the proposer user to the other user from the remittance request amount that the proposer user requests from the other user.
As an example of the effect of the embodiment obtained by such a configuration, the difference between the first amount and the third amount can be paid to or received from the first user.

Further, in this case, the second process may be executed based on approval by the other user based on input to the terminal 20 of the other user (not limited to, but an example of the first user).
As an example of the effect of the embodiment obtained by such a configuration, the second process can be executed based on the first user's approval based on the input to the first user's terminal. Thereby, by way of example and not limitation, it is possible to prevent the second process from being executed against the first user's wishes.

<15th example>
The 15th embodiment, like the 14th embodiment, is an embodiment regarding processing of a pattern different from the above-described pattern.
The contents described in the fifteenth embodiment are applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In addition to the patterns described above, by way of example and not limitation, the patterns of combinations of unprocessed requests shown horizontally in the table in Figure 9-6, that is,
- It is also possible to process a pattern of received remittance requests + sent requests.

The processing for this pattern is similar to the processing for pattern (B).
In other words, either "remittance + receipt (amount can be deducted)" or "remittance + send remittance request" can be performed.
Note that when performing the process of "remittance + money receipt (amount can be deducted)", approval from the other user may or may not be obtained.

<Effects of the 15th Example>
In this embodiment, the second information is remittance request information from the other party's user to the proposer's user, and the terminal 20 of the proposer's user is responsible for the sent remittance sent from the proposer's user to the other's user. A fourth display based on the request information (not limited, but an example of fourth information) is displayed on the display unit 24. Then, the proposer's user terminal 20 displays a second display based on the received remittance request information (not limited to, an example of the second information) regarding the received remittance request that the proposer's user has received from the other party's user. , and the above-mentioned fourth display are displayed on the terminal 20, the control unit 21 performs a third process related to remittance, receipt, or remittance request.
As an example of the effects of the embodiment obtained by such a configuration, it is possible to send money, receive money, or request money.

Further, the third process described above shows a configuration including a process of remitting money to the other user based on the received money transfer request information and transmitting the money transfer request to the other user based on the sent money transfer request information.
As an example of the effect of the embodiment obtained by such a configuration, remittance to the second user based on the second information and transmission of a remittance request to the second user based on the fourth information can be performed at the same time. .

Furthermore, the third process described above includes a process of remitting to or receiving money from the other user based on the received remittance request information and the sent remittance request information.
As an example of the effect of the 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 third process described above is to remit to the other user the amount obtained by subtracting the remittance request amount in the sent remittance request information from the remittance request amount in the received remittance request information, or to send the remittance request amount in the sent remittance request information to the other user. The configuration includes a process of receiving the amount obtained by subtracting the remittance request amount of the received remittance request information from the other user.
As the amount of money obtained in this embodiment with such a configuration, the difference between the second amount and the fourth amount can be paid to or received from the second user.

Further, in this case, the third process may be executed based on the approval by the other user based on the input to the terminal 20 of the other user (not limited to, but an example of the second user).
As an example of the effect of the embodiment obtained by such a configuration, the third process can be executed based on the second user's approval based on the input to the second user's terminal. Thereby, by way of example and not limitation, it is possible to prevent the third process from being executed against the second user's wishes.

<16th example>
The 16th embodiment is an embodiment related to a method of displaying remittance request information.
The content described in the 16th embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 14A 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 shown by way of example and not limitation for user A. This is a remittance screen of the payment application displayed on the display unit 24 of A's terminal 20A.
Below the current position display area CLR1, an icon image and a user name (user C.C. in this example) in the payment application of the user selected as the remittance destination are displayed.

Below the function button for increasing the remittance amount by a certain amount, there is a record of the outstanding relationship 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). An unprocessed request confirmation area URR3 configured to enable confirmation of processing requests is displayed.

At the top of the unprocessed request confirmation area URR3, user C. The characters "Unsettled request with C.C." indicating that an unprocessed request with C is displayed are displayed.
On the right side, a remittance request history sort button STB1 is displayed for changing the display order of unprocessed remittance requests. Other display modes are similar to the unprocessed request confirmation area URR1.

When the remittance request history sort button STB1 is touched, by way of example and not limitation, a sort selection area for selecting a sort order from the bottom of the screen is raised and displayed.
Based on user operations in the sort selection area, the display order of unprocessed remittance requests can be arranged in ascending/descending order by date of sending/receiving remittance requests, amount of remittance requests, etc., by way of example and not limitation. It can be rearranged and displayed.

Note that the display order of unprocessed remittance requests may be rearranged and displayed in order of the date and time of transmitting/receiving the remittance requests, instead of in the order of the date of transmitting/receiving the remittance requests.

FIG. 14-2 shows, by way of example and not limitation, an example of a display screen when the remittance requests in the unprocessed request confirmation area URR3 are sorted in descending order by remittance request amount based on the user's operation in the sort selection area. It is a diagram.

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

Note that when a payment deadline is set for a remittance request, by way of example and not limitation, the remittance requests may or may not be displayed in the order in which the payment deadline approaches. Setting payment deadlines includes, by way of example and not limitation, in addition to payments between general users (CtoC), setting repayment deadlines for loans from businesses such as financial institutions (CtoB). .

Further, remittance requests in which the user who requested the remittance and the user other than the user who requested the remittance are involved in the amount or reason for the remittance request may be preferentially displayed. By way of example and not limitation, this is the case where other users are included as members of the split bill.

Further, although unprocessed remittance requests are displayed in the unprocessed request confirmation area URR3, the present invention is not limited thereto.

FIG. 14-3 is an example of a display screen when processed remittance requests are mixed in the unprocessed request confirmation area URR3.
In FIG. 14-3, as an example and not a limitation, the first remittance request in the unprocessed request confirmation area URR3 indicates that a remittance request related to payment of the remittance request amount "1,000 yen" has been received and that the remittance request has been processed. It is displayed in a grayed-out display format, indicating that it is a remittance request. Processed remittance requests are not selected for batch settlement, so there is no check area.

<Effects of the 16th Example>
In this embodiment, the proposer's user's terminal 20 receives remittance request information regarding a received remittance request that the proposer's user has received from the other user (without limitation, information sent from the second user to the terminal user). An example of fourth information regarding a remittance request), or remittance request information regarding a sent remittance request that has been sent by the proposer user to the other user (without limitation, information regarding a remittance request sent from the terminal user to the second user) A fourth display based on the fourth information (an example of the fourth information) is displayed on the display unit 24. The proposer's user terminal 20 is configured to display the second display and the fourth display 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 the 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.

Furthermore, in this embodiment, the above-mentioned second information and fourth information are information related to the date when the remittance request was sent/received (not limited to, but an example of information related to the date), or the date and time when the remittance request was sent/received. (This is not a limitation, but is an example of information related to the date and time), and the order in which the second display and the fourth display are displayed is determined based on the information related to the date or date and time.
As an example of the effect of the embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on the date and time or information related to the date, a display that is intuitively understandable for the user can be realized. I can do it.

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

Furthermore, in this case, the information regarding the amount to be requested for remittance may include, by way of example and not limitation, information regarding the payment deadline in addition to the requested remittance amount.
As an example of the effect of the 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 understandable for the user. can.

Next, as a concept opposite to the ninth to sixteenth embodiments, the user of the terminal 20 receives (receives) the amount of money remitted from the other user, or receives a remittance request from the other user. An example of processing for receiving will be described.

<17th example>
The seventeenth embodiment is an embodiment in which an unprocessed request is displayed when the user of the terminal 20 receives an amount of money remitted from the other user or receives a remittance request from the other user.
The content described in the seventeenth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

FIG. 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A.
In the current position display area CLR1 indicating the current position in the payment application, the characters "Notice" indicating that the current position is a notification function of the payment application are displayed.

In the announcement information display area NTR2 of the announcement screen, remittance result information NC1 is displayed as content regarding receipt of remittance (receipt).
Note that for the server 10, it is remittance result information because it is the result of remittance processing, and for the other user (user B.B in this example), it is also remittance result information, but for the server 10 (user A.B. in this example), it is remittance result information. For A), since it is the result of receiving money, it can also be said to be receiving result information.

This remittance result information NC1 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the receipt of the remittance amount "500 yen" remitted (received) from B are displayed.

Below that, a list of unprocessed remittance requests of the user who received the remittance (user A.A in this example) is displayed at the time of receiving the remittance. In this example, four unprocessed requests are listed in chronological order from oldest to newest. The display mode of each unprocessed request can be configured in the same manner as shown in FIG. 1-23, by way of example and not limitation, and therefore will not be described again.

Note that, as unprocessed requests, only the unprocessed requests of the user who sent money (user A.A in this example) and the user who sent money (user B.B in this example) may be displayed. However, you don't have to do that.

In this way, in this embodiment, by displaying the unprocessed requests together with the information on the remittance results (receipt results), the unprocessed requests can be displayed together with the information on the remittance results when the user confirms that the remitted amount has been received. It is configured so that it can be checked.

FIG. 15-2 is a diagram showing another example of the screen displayed on the display unit 24 of the terminal 20 in this embodiment. This screen corresponds to FIG. 15-1, but some of the displayed contents are different.
Specifically, by way of example and not limitation, a remittance receiving button labeled "receive remittance" for accepting and receiving remittance is displayed in the remittance result information NC1.
User A. The remittance process is not complete until the remittance receipt button is tapped by A. When the remittance receipt button is tapped, the remittance is transferred to the e-money account balance of the user who received the remittance (in this example, user A.A). The amount ("500 yen" in this example) is added.

In this example, when money is transferred from the other party's user (first user or second user) to the proposer's user (terminal user), the proposer's user side receives (receives) the amount to be remitted. It is configured so that it can be stopped.
The details will be described later, but this is referred to as "holding the receipt of remittances" or "holding the receipt of funds."
Furthermore, since the remittance is not completed, this can also be interpreted as a "remittance hold."

In this way, in this embodiment, the user determines whether or not to receive the remitted amount by displaying the unprocessed request along with the information on the remittance result (receipt result) for which receipt of the remittance is suspended. The system is configured so that unprocessed requests can also be checked in case of a request.

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

Remittance request information NC7 is displayed in the announcement information display area NTR2 of the announcement screen as content related to receiving the remittance request.
The remittance request information NC7 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the remittance request received from B for the remittance request amount of "500 yen" are displayed. In addition, the remittance request information NC7 includes a remittance request remittance button that says "Send money" to accept this remittance request and perform the remittance, and a remittance button that says "Reject" to reject this remittance request. A button to reject the remittance request is displayed.

Below that, a list of remittance requests that are unprocessed by the user who received the remittance request (user A.A in this example) is displayed at the time of receiving the remittance request.

Note that only unprocessed 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) are displayed as unprocessed requests. You may or may not have to do so.

In this way, in this embodiment, by displaying the unprocessed requests together with the information on the reception result of the remittance request, the user can also check the unprocessed requests when confirming that the remittance request has been received. It is configured so that it can be done.

<Processing>
FIG. 15-4 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. Here, as an example, the process of displaying an unprocessed request when a user receives remittance (receipt), which was explained in FIG. 15-1, will be described.

The control unit 11 of the server 10 controls user A. of the terminal 20A based on a request from the terminal 20B (not shown). The remittance process for A is executed (S210). Specifically, by way of example and not limitation, user B. The remittance amount is subtracted and updated from the electronic money account balance of user A.B. Add the remittance amount to A's electronic money account balance and update it.

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 transmit 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 is determined that the remittance request list information has been received (A205: YES). , displays on the display unit 24 a batch payment screen including remittance result information and remittance request list information (A225).
The batch payment screen is, by way of example and not limitation, the notification screen shown in the display screen example.
Then, the control unit 21 of the terminal 20A ends the process.

FIG. 15-5 is a flowchart showing another example of the flow of processing executed by each device in this embodiment. Here, as an example, a process will be described in which the suspension of receipt of remittance (suspension of received money) described in FIG. 15-2 is applied.

The control unit 11 of the server 10 controls user A. of the terminal 20A based on a request from the terminal 20B (not shown). The first remittance process for A is executed (S310a). Specifically, by way of example and not limitation, user B. The remittance amount is subtracted from B's electronic money account balance and updated.
In the first remittance process, unlike the remittance process (S210) in Figure 15-4, the remittance amount is subtracted from the remittance source user's electronic money account balance, but the remittance amount is not added to the remittee user's electronic money account balance. Not added. In this state, the remittance has not been completed.

After that, 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 the 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 to receive remittance has been made to the input unit (A730), and if it is determined that it has been input (A730: YES), requests receipt of remittance. The remittance receipt information is sent to the server 10 via the communication I/F 22 (A740).

After S320, the control unit 11 of the server 10 determines whether or not the remittance receipt information has been received from the terminal 20A through the communication I/F 14 (S740), and if it is determined that the remittance receipt information has been received (S740: YES), the control unit 11 of the server 10 2 remittance processing is executed (S310b). Specifically, by way of example and not limitation, based on the results of the first remittance process, user A. Add the remittance amount to A's electronic money account balance and update it. In other words, the state in which the receipt of remittances (receipt of funds) is suspended is released, and the remittances are completely transferred.

After that, the control unit 11 of the server 10 transmits the remittance result information of the second remittance process to the terminal 20A and the terminal 20B through the communication I/F 14 (S790).
Then, the control unit 11 of the server 10 ends the process.

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

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

Note that regarding the process of displaying unprocessed requests when the user receives a remittance request, which was explained in Figure 15-3, "Remittance" (receipt for user A.A) in the process of Figure 15-4 is Since it can be configured in the same way by replacing it with "receiving remittance request," illustration and explanation will be omitted.
Specifically, in the process of the terminal 20A, it is determined in A205 whether remittance request transmission result information and remittance request list information have been received, and a batch settlement screen including these information is displayed in A225.
In addition, 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.

<Display of unprocessed requests>
The unprocessed requests displayed on the display unit 24 of the terminal 20 can be one or both of the following, by way of example and not limitation.
・Unprocessed requests corresponding to the user who sends money to you (remittance source user) or the user who sends a remittance request to you (remittance request source user) ・The user who sends money to you Outstanding requests that correspond to a user who is different from the user (the sending user) or the user who is sending the money request to you (the sending user)

Unprocessed requests corresponding to the other user can be displayed. By way of example and not limitation, user A. A is user B. When receiving a remittance with user B as the remittance source user, or when user A. A is user B. When receiving a remittance request with B as the remittance requesting user, user B. Unprocessed requests corresponding to B can be displayed.

However, some users may wish to check unprocessed requests corresponding to users different from the other user.
Therefore, as illustrated in FIGS. 15-1 to 15-3, user B. In addition to the outstanding requests corresponding to user C. It is also possible to display unprocessed requests corresponding to C.
Note that in this case, user B. By way of example and not limitation, without displaying any outstanding requests corresponding to user C.B. It is also possible to display unprocessed requests corresponding to C.

In other words, as in the eighth embodiment, the following three patterns are possible as examples, not limitations, for displaying unprocessed requests.
(Pattern 1) Unprocessed requests corresponding to the other user (Pattern 2) Unprocessed requests corresponding to the other user + Unprocessed requests corresponding to a user different from the other user (Pattern 3) Different from the other user Outstanding requests corresponding to the user

Also, when applying any of the above patterns, for each user, all unprocessed requests corresponding to that user may be displayed, or some unprocessed requests corresponding to that user may be displayed. It may also be displayed.
In other words, the user whose unprocessed requests are displayed (the other user/user different from the other user) and the range (all/part) of the unprocessed requests to be displayed can be arbitrarily combined. As an example and not a limitation (pattern 2), unprocessed requests corresponding to the other user will display all unprocessed requests, but unprocessed requests corresponding to a user different from the other user will display some unprocessed requests. You may also display the request.

Furthermore, when displaying some unprocessed requests, the unprocessed requests to be displayed can be determined based on various information (conditions).
In this case, the contents of the twenty-sixth embodiment described later can be combined. As will be explained in the twenty-sixth embodiment, various types of information include, by way of example and not limitation, the following information.
・Date and time of sending/receiving the remittance request ・Amount of remittance request ・Payment deadline of remittance request ・Remittance request in which the user who made the remittance request and other users other than the user who received the remittance request are involved in the amount or reason for the remittance request , these information are just examples and are not limited to these.
Moreover, a combination of a plurality of pieces of information among these pieces of information can also be applied.

Users may forget unprocessed requests whose dates and times are older than a certain level. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
An unprocessed request in which the remittance request amount is larger than a certain level may be of high importance. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
A remittance request in which the user who requested the remittance and other users other than the user who requested the remittance are involved in the amount or reason for the remittance request may also have high importance. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.
Outstanding requests with payment deadlines approaching within a certain period of time may require immediate processing. Therefore, even if an unprocessed request corresponds to a user different from the other user, it can be determined to be displayed.

Furthermore, as will be explained in the twenty-sixth embodiment, the unprocessed requests can be sorted and displayed in ascending/descending order based on the various types of information (conditions) described above. For example, unprocessed requests with higher importance can be displayed higher.

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

Furthermore, some users may feel bothered by the display of unprocessed requests.
Therefore, it may be possible to set display/non-display of unprocessed requests on a setting screen (not shown) or the like.

Specifically, as setting information regarding the display of unprocessed requests, slide buttons and check boxes that can switch between displaying and hiding unprocessed requests are displayed, by way of example and not limitation, on the application settings screen. Then, based on the operation on the slide button or check box, the terminal 20 or the server 10 can be made to set display/non-display.

In this case, display/non-display of unprocessed requests may be settable for all users at once, or display/non-display of unprocessed requests may be set individually for each user.
Further, display/non-display of all unprocessed requests may be settable, or display/non-display of some unprocessed requests may be settable.

Note that these contents also apply to the following examples.

<Effects of the 17th Example>
In this embodiment, the terminal 20 of the proposer's user receives remittance result information from the other party's user (not limited to this, but is an example of first information regarding remittance from the first user to the user of the terminal) or from the other party's user. The transmitted remittance request information (not limited to this, but an example of first information regarding a remittance request transmitted from the first user to the user of the terminal) is received from the server 10 by the communication I/F 22 .
Then, the proposer's user terminal 20 displays a first display based on the received information on the display unit 24, and based on the reception of the first information, a received remittance request regarding the received remittance request from the other user. information (an example, but not limited to, of secondary information regarding a remittance request sent from a second user to a user of a terminal) and sent remittance request information regarding a remittance request sent to the other user (without limitation, information regarding a remittance request sent to the other user) A configuration is shown in which a second display based on an example of second information regarding a remittance request transmitted from a user to a second user is displayed on the display unit 24.
As an example of the effect of the embodiment obtained by such a configuration, when the user of the terminal confirms the first information, it is possible to enable the user of the terminal to confirm the second information at the same time.

Further, in this embodiment, the terminal 20 of the proposer's user is configured to receive the remitted amount based on the input by the proposer's user to the terminal 20 on which the first display and the second display are displayed. A configuration is shown in which the control unit 21 performs a process (not limited to an example of a first process related to receiving a remittance).
As an example of the effects of the 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. .

<17th modification (1)>
In the 17th embodiment, settlement (including bulk settlement of unprocessed requests) is performed based on input to information on unprocessed requests displayed together with remittance result information from the other user and remittance request information sent from the other user. .) may be executed.

Specifically, instead of limiting the screen examples shown in Figures 15-1 to 15-3, a payment button is displayed to perform payment for the selected unprocessed requests (batch payment if multiple selections are made). .
Then, when the payment button is tapped, the server 10 can perform payment processing for the selected unprocessed request.

Note that the settlement process for unprocessed requests is as described above, and therefore will not be explained again.

FIG. 15-6 is a flowchart showing an example of the flow of processing executed by each device in this modification. Here, as an example, in the remittance receipt hold (receipt hold) process shown in FIG. 15-5, a process will be described in which either the remittance is received or the unprocessed request is settled.

After A225, the control unit 21 of the terminal 20A determines the execution target based on the input to the input unit (A831).
If it is determined that the execution target is settlement of unprocessed requests (batch 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, request selection information including unprocessed request selection information indicating the selected unprocessed request is set.

On the other hand, if it is determined that the execution target is remittance receipt (A831: remittance receipt), 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 moves the process to A150.

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 determines the processing target based on the received request selection information (S841).

If it is determined that the processing target is the settlement of unprocessed requests (S841: settlement of unprocessed requests), the control unit 11 of the server 10 moves the process to S642. In other words, the selected unprocessed requests are set as objects to be settled (if multiple requests are selected, objects to be settled all at once). Then, the control unit 11 of the server 10 executes the payment process in S150.

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

When applying the first payment process described in FIG. 1-19 by way of example and not limitation,
If the settings in S642 are made and there are a plurality of unprocessed requests to be processed, the determination result in S1510 as to whether or not the payment target is a lump sum payment target is "YES". As a result, the processes from S1515 onwards are executed with these multiple unprocessed requests as the subject of batch settlement.
Further, if the settings in S642 are made and there is one unprocessed request to be processed, the determination result in S1510 as to whether the payment target is a lump sum payment target is "NO". As a result, the processing from S1570 onwards is executed with this one unprocessed request as the subject of settlement.

In addition, the process of displaying unprocessed requests and settling the unprocessed requests when receiving the remitted amount without the user having to put the remittance receipt on hold can be configured in the same way as shown in Figure 15-6. Therefore, illustration and explanation will be omitted.
Furthermore, the process of displaying unprocessed requests when a user receives a remittance request, and performing either remittance or settlement of unprocessed requests can be configured in the same manner as shown in Figure 15-6. Therefore, illustrations and explanations are omitted.

In this modification, the terminal 20 of the proposer's user receives remittance result information from the other user (not limited to this, but is an example of first information regarding remittance from the first user to the user of the terminal) or from the other user. The transmitted remittance request information (not limited to this, but an example of first information regarding a remittance request transmitted from the first user to the user of the terminal) is received from the server 10 by the communication I/F 22 .
In addition, the terminal 20 of the proposer's user displays a first display based on the received information on the display unit 24, and displays a received remittance request regarding the received remittance request from the other user based on the reception of the first information. information (an example, but not limited to, of secondary information regarding a remittance request sent from a second user to a user of a terminal) and sent remittance request information regarding a remittance request sent to the other user (without limitation, information regarding a remittance request sent to the other user) A second display based on the second information regarding the remittance request transmitted from the user to the second user is displayed on the display unit 24.
Then, the proposer's user terminal 20 processes the remittance or receives the remitted amount based on the input by the proposer's user to the terminal 20 on which the first display and the second display are displayed. control the processing for sending a money transfer request, or the process for receiving a money transfer request (an example, without limitation, of the first process related to sending a money transfer, receiving a money transfer, or requesting a money transfer); The configuration performed by the section 21 is shown.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to send money to the other user or receive money from the other user based on the input to the terminal on which the first display and the second display are displayed. , it is possible to easily send/receive a remittance request to/from the other user.

<17th modification (2)>
In the above embodiment, the payment result information on the display screen is rendered and displayed based on the first information. That is, 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 where 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 where 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 display and the second display can be displayed in any order.
In other words, case (1) above can be changed to "reception of first information → second display → first display", or case (2) above can be changed to "reception of first information → second display, first display". reception → first display.

Note that this also applies to the embodiments described below.

Next, as an example related to the seventeenth example, when the user of the terminal 20 receives (receives) the amount remitted from the other user or receives a remittance request from the other user, An embodiment will be described in which an unprocessed request selected from the displayed unprocessed requests is also processed.

In the following embodiments, the following five patterns will be explained.
(a) Pattern for processing received money + received remittance requests (b) Pattern for processing received money + sent remittance requests (c) Pattern for processing received money + received remittance requests + sent remittance requests (d) Pattern of receiving a remittance request + processing a received remittance request (e) Pattern of receiving a remittance request + processing a sent remittance request Examples of each pattern will be explained separately.

As shown in the 17th modification, the processing (first processing, etc.) executed by the control unit 21 of the terminal 20 includes, by way of example and not limitation, processing for remittance (not limited to, processing related to remittance). (one example), processing for receiving remittances (receipt) (not limited to, but an example of processing related to receiving remittances), processing for sending/receiving remittance requests (not limited to, processing related to remittance requests) example).
In the following, a server-client system will be exemplified, and it is assumed that remittances, transmission of remittance requests, etc. are performed via the server 10.

Furthermore, as described above, the case where the other user is one user, that is, the second user is the first user (or the first user is the second user) will be exemplified below.
As mentioned above, when the other users are multiple different users, that is, when the first user is a different user from the second user (the second user is a different user from the first user) The method described below can be similarly applied to this case.

<18th example>
This embodiment is an embodiment related to processing of the pattern (a) above.
The contents described in the 18th embodiment are applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

FIG. 16-1 is a diagram showing an example of a table for explaining processing methods corresponding to each of the above patterns.
The vertical direction of the table shows the target of the process to be newly executed (new processing target) as an item, and the type of unprocessed request is shown as an item in the horizontal direction of the table. In the column where the vertical item and the horizontal item intersect, an example of the process realized by the combination of the new process target and the type of unprocessed request is shown.
I will explain them in order.

In the pattern of (a) received money + received remittance request, it is possible to perform the process of (a1) received money + remittance. That is, when receiving money from the other user, the user also sends money to the other user based on the remittance request that has already been received from the other user.

<Display screen>
FIG. 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A.
In the current position display area CLR1 indicating the current position in the payment application, the characters "Notice" indicating that the current position is a notification function of the payment application are displayed.

In the announcement information display area NTR2 of the announcement screen, remittance result information NC1 is displayed as content regarding receipt of remittance (receipt).
Below, for convenience, remittance request list information may be included in the remittance result information. In this case, the remittance result information may be referred to as batch payment information.

Also, for the server 10, it is remittance result information because it is the result of remittance processing, and for the other user (user B.B in this example), it is also remittance result information, but for the server 10 (user A.B. in this example), it is also remittance result information. For A), since it is the result of receiving money, it can also be said to be receiving result information.

This remittance result information NC1 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the receipt of the remittance amount "500 yen" remitted (received) from B are displayed.

Below that, a list of unprocessed remittance requests of the user who received the remittance (user A.A in this example) is displayed at the time of receiving the remittance. In this example, four unprocessed requests are listed in chronological order from oldest to newest. The display mode of each unprocessed request can be configured in the same manner as shown in FIG. 1-23, by way of example and not limitation, and therefore will not be described again.

Note that, as unprocessed requests, only the unprocessed requests of the user who sent money (user A.A in this example) and the user who sent money (user B.B in this example) may be displayed. However, you don't have to do that. In this case, the display mode of each unprocessed request can be configured in the same manner as in FIG. 1-11, by way of example and not limitation.

At the bottom of the remittance result information NC1, an all-select all-at-once payment button labeled "All selected at once" is displayed for executing all-select all-at-once payment. In addition, next to the Select All Batch Settlement button, there is a button that says ``One Item'', which allows you to perform selective bulk settlement of some unprocessed requests selected by the user among the unprocessed requests displayed in the remittance result information NC1. A partially selected batch payment button BT17 labeled "Payment" is displayed.

As an example and not a limitation, in the remittance result information NC1, the request check for the first received remittance request (payment to user C.C. 2,000 yen) is set to "ON" and selected, and some of the requests are selected. When the batch payment button BT17 is tapped, the terminal 20A requests the server 10 to perform batch payment for the selected unprocessed requests. Then, from the server 10, the other party, user C. C's terminal 20C and user A. Settlement result information regarding the execution result is transmitted to A's terminal 20A.

FIG. 16-3 is a diagram showing an example of a notification screen displayed on the display section 24 of the terminal 20A based on the above-mentioned tapping of the partial selection lump sum settlement button BT17.
In this example, in the announcement information display area NTR2 of the announcement screen, payment result information NC2 is displayed below the remittance result information NC1 as the contents of the lump sum payment.

The payment result information NC2 includes, by way of example and not limitation, user A. A is user C. By settling the payment for the remittance request amount "2,000 yen" based on the remittance request from user C. Information regarding the execution of a remittance amount of "2,000 yen" to C is displayed.

Note that user C. The payment result information displayed on the terminal 20C of user A. In addition to displaying the receipt of remittance amount "2,000 yen" from user A, user C. A list of C's unprocessed requests is added and displayed.

<Processing>
FIG. 16-4 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
The control unit 11 of the server 10 controls the user A. of the terminal 20A based on the request from the terminal 20B. The remittance process for A is executed (S210). Specifically, by way of example and not limitation, user B. The remittance amount is subtracted and updated from the electronic money account balance of user A.B. Add the remittance amount to A's electronic money account balance and update it.
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 is determined that the remittance request list information has been received (A205: YES). , displays on the display unit 24 a batch payment screen including remittance result information and 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 unprocessed request selection information as 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 batch payment of the selected unprocessed requests as a batch payment target (S242). Then, the control unit 11 of the server 10 moves the process to S150.
Further, if it is determined that the processing is not for an unprocessed request (S141: NO), the control unit 11 of the server 10 ends the processing.

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

Further, in this embodiment, the second information is remittance result information (not limited to this, but is an example of information regarding remittances from the first user to the user of the terminal), and the second information is received remittance request information ( (This is not a limitation, but is an example of information regarding a remittance request sent from a second user to a user of a terminal), and the first process is based on the input to the terminal 20 on which the second display is displayed. This is not a limitation, but shows a configuration including a process of remitting money to an example of a second user.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to notify the terminal user that a remittance is scheduled to be made from the first user to the terminal user, and to input information to the terminal on which the second display is displayed. The remittance can be transferred to the second user based on the .

Further, in this embodiment, 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 according to the present disclosure. It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, the first display and the second display can be displayed on the display section of the terminal by an application installed on the terminal.

<18th modification example>
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 at the terminal 20 of the proposer's user, but the present invention is not limited to this.
Specifically, by applying the above-mentioned method of suspending the receipt of remittance (holding the receipt), based on the input (operation, etc.) to receive the remittance while the second display is displayed, The remittance from the other user may or may not be completed.
Note that this also applies to other embodiments.

<19th example>
The nineteenth embodiment is an embodiment related to processing of the pattern (b) described above.
The contents described in the nineteenth embodiment are applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In the pattern of (b) received money + sent remittance request, it is possible to perform the process of (b1) received money + remittance reminder. That is, when receiving money from the other user, a remittance reminder for this remittance request is performed based on the remittance request that has already been sent to the other user.
In this case, a new remittance request may or may not be made instead of the 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A. As for the details of the screen configuration, it is possible to configure it in the same manner as in FIG. 16-2 by way of example and not limitation, so a detailed explanation will be omitted.

As an example and not a limitation, in the remittance result information NC1, the check for the third received remittance request (1,000 yen received from user C.C) is selected as "ON", and some of the requests are selected. When the batch payment button BT17 is tapped, the terminal 20A requests the server 10 to perform batch payment for the selected unprocessed requests. Then, from the server 10, the other party, user C. Settlement result information regarding the execution result is transmitted to C's terminal 20C.

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

In addition, when the above-mentioned partial selection bulk payment button BT17 is tapped, user C. You may or may not display information such as "User C. Reminder sent to C" indicating that a remittance reminder has been sent to C. .

<Processing>
The processing executed by each device in this embodiment can be implemented in the same manner as the processing shown in FIG. 16-4, and thus illustrations and detailed explanations will be omitted.

<Effects of the 19th Example>
In this embodiment, the terminal 20 of the proposer's user transmits remittance result information (not limited to, but an example of first information regarding remittance from the first user to the user of the terminal) from the other user via the communication I/F 22. Received from server 10.
Further, the terminal 20 of the proposer's user displays a first display based on the received remittance result information (an example of a first display, not a limitation) on the display unit 24, and displays a first display based on the received remittance result information on the other party based on the received remittance result information. A display (without limitation, a second display) based on sent remittance request information regarding a remittance request sent to a user of a terminal (an example of second information regarding a remittance request sent from a user of a terminal to a second user) example) is displayed on the display unit 24.
Then, the terminal 20 of the proposer's user receives the money (an example of receiving a remittance, not a limitation) based on the input by the proposer's user to the terminal 20 on which the first display and the second display are displayed. The configuration is shown in which the control unit 21 executes a first process regarding a remittance reminder or a new remittance request (not limited to, but an example of a remittance request).
As an example of the effect of the embodiment obtained by such a configuration, the first process related to receiving a remittance or requesting a remittance can be easily and easily performed based on the input to the terminal on which the first display and the second display are displayed. Can be done properly.

Further, in this embodiment, the first information is remittance result information from the other user (not limited to this, but is an example of information regarding remittance from the first user to the user of the terminal), and the second information is the proposal The configuration is shown as sent remittance request information regarding a remittance request sent from a second user to a second user (not limited to, but an example of information regarding a remittance request sent from a terminal user to a second user). .
As an effect of the embodiment obtained by such a configuration, processing based on a remittance from the first user to the terminal user and a remittance request sent from the terminal user to the second user can be performed at once. can.

Furthermore, in this case, the first process is to send a remittance reminder or a new remittance request to the other user (not limited to, but an example of the second user) based on the input to the terminal 20 on which the second display is displayed. A configuration including processing is shown.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily request the second user to remit money based on the input to the terminal on which the second display is displayed.

<20th example>
The 20th embodiment is an embodiment related to processing of the pattern (c) described above.
The content described in the 20th embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

(c) In the pattern of receiving money + receiving remittance request + sending remittance request, process (c1) [receiving + remittance] (amount can be deducted) + [receiving + remittance] (amount can be deducted). It can be carried out.

In this process, when receiving money from the other user, money is also transferred to the other user based on the received remittance request from the other user. In this case, the difference between the requested remittance amount can be received/remitted. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.
Furthermore, the system sends money to the other user based on a remittance request that has been received from the other user, and receives money by receiving money from the other user based on the remittance request that has already been sent to the other user. In this case, it is possible to remit/receive the difference in the remittance request amount. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.

<Display screen>
Here, as an example, an example of a display screen when applying the above-mentioned suspension of receipt of remittance (suspension of received money) will be described.

FIG. 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A.
In the announcement information display area NTR2 of the announcement screen, remittance result information NC4 is displayed as content regarding receipt of remittance (receipt).
The remittance result information NC4 includes, by way of example and not limitation, user A. A is user C. Contents corresponding to the receipt of the remittance amount "500 yen" remitted from C are displayed.

The remittance result information NC4 displays a remittance receiving button labeled "receive remittance" for accepting and receiving remittance. That is, user A. The remittance process is not complete until the remittance receipt button is tapped by A. When the remittance receipt button is tapped, the remittance is transferred to the e-money account balance of the user who received the remittance (in this example, user A.A). The amount ("500 yen" in this example) is added.

In addition, similar to the remittance result information NC1, the remittance result information NC4 displays a list of remittance requests that have not been processed by the user to whom the remittance was made (user A.A in this example) at the time of receiving the remittance.

At the bottom of the remittance result information NC4, a button for selecting all received funds and receiving the remittance is displayed, which says "Settle all and receive remittance", which allows you to select all and receive the remittance assuming that the remittance has been accepted. There is. In addition, next to the Select All Received Batch Payment button, assuming that the remittance has been accepted, select all unprocessed requests selected by the user among the unprocessed requests displayed in the remittance result information NC4. A received payment lump sum settlement button BT18, which is displayed as "Single settlement", is displayed.

The remittance receipt button in remittance result information NC4 is clicked by user A. By way of example and not limitation, when tapped by user A, the display mode of the remittance result information NC4 may change the user who made the remittance to user C. It changes in the same way as the remittance result information NC1 in the case of C.

As an example and not a limitation, in the remittance result information NC4, the first received remittance request (payment to user C.C. 2,000 yen) and the third sent remittance request (user C.C. When the check of the request for remittance (receiving 1,000 yen from user C.C. The user is requested to perform remittance from user A.A. to user A.A.) and bulk settlement of the selected unprocessed requests. This remittance is made by user A. For A, this is the receipt of remittances.

Then, from the server 10, the other party, user C. Lump-sum payment approval confirmation information for confirming whether or not to approve the lump-sum payment is sent to the terminal 20C of C, and displayed on the display unit 24 of the terminal 20C.

FIG. 18-2 is a diagram illustrating an example of a notification screen that is displayed based on tapping the received payment lump sum settlement button BT18.
In the notification information display area NTR1, user A, who is the other party of the "settlement proposal", displays lump sum payment approval confirmation information NC5. The icon image of A and the lump sum payment amount are displayed.

The lump sum payment approval confirmation information NC5 includes user C. C is user A. User A receives the remittance request amount "2,000 yen" based on the past remittance request sent to A. User A pays the remittance request amount "1,000 yen" based on the past remittance request received from A. It is displayed that ``500 yen'' will be paid by this remittance to A.

In addition, the lump sum payment approval confirmation information NC5 includes user C. C is user A. From A, receive "500 yen", which is the sum of the remittance request amount "1000 yen" received by receiving the remittance request and the current remittance amount "500 yen" from the received amount "2,000 yen" by sending the remittance request. is displayed.

At the bottom of the lump sum payment approval confirmation information NC5, there is a payment button BT19 indicating "Payment" for approving the payment with the above content, and a "Decline" button for declining the payment without approving the payment with the above content. and a Reject button that is displayed.

FIG. 18-3 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20A based on the tapping of the payment button BT19.
In this example, in the announcement information display area NTR2 of the announcement screen, payment result information NC6 is displayed below the remittance result information NC4 as the contents of the lump sum payment.

The payment result information NC6 includes, by way of example and not limitation, user A. A and user C. As a lump-sum payment was made with C., the content of the lump-sum payment is the amount of the payment result (in this example, the remittance amount "500 yen" that user A.A remitted to user C.C. ) is displayed.

That is, in this embodiment, even if the all-received payment selection batch settlement button or the receipt batch payment button BT18 is tapped in the remittance result information NC4, the receipt of the remittance is not immediately executed. The remittances are processed at once by putting the remittances on hold (holding the receipt of remittances, holding the receipts) and including them in the contents of the lump sum settlement.

Note that the remittance may be canceled after a certain period of time has passed since the server 10 sent the remittance result information. Alternatively, the remittance may be forcibly completed.

In addition, in FIG. 18-1, when the received payment lump sum settlement button BT18 is tapped, the display section 24 of the terminal 20A displays a message indicating that the user A. User A displays a confirmation screen to the effect that he/she will be paying a lump sum payment amount of "500 yen". Based on A's approval, a request may be made to receive the remittance and to collectively settle the selected unprocessed requests, or it may not be necessary.

<Processing>
FIG. 18-4 is a flowchart showing an example of the flow of processing 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 requests remittance receipt information regarding the receipt of remittance in the first remittance process and unprocessed request selection information. Set as 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 the terminal 20A sets remittance receipt information as request selection information (A333).

Note that the process of A333 may be executed only if receipt of remittance is explicitly selected in A131, and if it is not selected, the control unit 21 of the terminal 20A may terminate the process, You don't have to.
After A332 or A333, the control unit 21 of the terminal 20A moves the process to A140.

If it is determined in S141 that the unprocessed requests are to be processed (S141: YES), the control unit 11 of the server 10 performs remittance (remittance from user B.B to user A.A) and batch settlement of unprocessed requests. is set as a lump sum payment target (S342). Then, the control unit 11 of the server 10 moves the process 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 moves the process to S310b. That is, the second remittance process is executed.
Then, the control unit 11 of the server 10 moves 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 20th Example>
In this embodiment, the terminal 20 of the proposer's user transmits incomplete remittance result information (not limited to, but an example of first information regarding remittance from the first user to the user of the terminal) from the other user via a communication interface. /F22 from the server 10.
In addition, the proposer's user terminal 20 displays a first display (an example of the first display, not a limitation) based on the received incomplete remittance result information on the display unit 24, and displays a first display based on the received remittance result information. received remittance request information (without limitation, an example of second information regarding a remittance request sent from a second user to a user of a terminal), or sent remittance request information (without limitation, an example of second information regarding a remittance request sent from a second user to a user of a terminal); A second display (an example of a second display, not a limitation) based on an example of second information regarding a remittance request transmitted to a user is displayed on the display unit 24.
Then, the terminal 20 of the proposer's user sends or receives money (including, but not limited to, receiving money) based on the input by the proposer's user to the terminal 20 on which the first display and the second display are displayed. 2 shows a configuration in which the control unit 21 executes the first process related to (an example).
As an example of the effect of the embodiment obtained by such a configuration, the first process related to remittance or the receipt of remittance can be easily and appropriately performed based on the input to the terminal on which the first display and the second display are displayed. It can be carried out.

Further, in this case, the first process is based on the remittance receiving operation (not limited to, but an example of input to the terminal on which the first display is displayed) after the first display is displayed on the display unit 24. It shows a configuration including a process of receiving an amount of money remitted from the other user (not limited to this, but an example of a process of receiving an amount of money remitted from the first user to the user of the terminal).
As an example of the effect of the embodiment obtained by such a configuration, the amount remitted from the first user can be received based on the input to the terminal on which the first display is displayed.

Furthermore, in this embodiment, the other user is one user (not limited to this, but an example in which the second user is the first user), and the first process is based on the received remittance request information and the sent remittance request. This figure shows a configuration including a process of remitting an amount based on the information to the other user or having the other user remit the money.
As an example of the effect of the 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 have the amount remitted from the first user and receive the amount.

In addition, in this case, the first process is to remit to the other user the amount obtained by subtracting the remittance request amount included in the sent remittance request information from the remittance request amount included in the received remittance request information, or to send the sent remittance request This can include a process in which the other user remits an amount obtained by subtracting the remittance request amount included in the received remittance request information from the remittance request amount included in the information.
As an example of the effect of the embodiment obtained by such a configuration, the difference in amount can be remitted to the first user, or can be received by having the first user remit it.

Further, in this case, the first process can be executed based on the approval by the other user based on the input to the terminal 20 of the other user.
As an example of the effect of the embodiment obtained by such a configuration, the first process can be executed based on the first user's approval based on the input to the first user's terminal. As a result, by way of example and not limitation, it is possible to prevent the first process from being executed against the first user's wishes.

<Twentieth variation>
Although related to the above embodiment, "received money" among the new processing targets in the table of FIG. 16-1 can also be set as "received money pending."

in this case,
・Pending receipt + received remittance request ・Pending receiving money + sending remittance request ・Pending receiving money + received remittance request + sent remittance request It is possible to process one of the following patterns.

The processing for these patterns is similar to the processing for patterns (a) to (c), respectively. This is because the difference is simply whether the remitted amount is received immediately or later.

<21st Example>
The 21st embodiment is an embodiment related to processing of the pattern (d) described above.
The content described in the twenty-first embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In the pattern of (d) receiving a remittance request + received remittance request, it is possible to perform the process of (d1) remittance [remittance + remittance]. In other words, remittances are made to the other user based on the receipt of a remittance request from the other user, and money is transferred to the other user based on the already received remittance request from the other user.

<Display screen>
FIG. 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A.

In the announcement information display area NTR2 of the announcement screen, remittance request information NC7 is displayed as content related to receiving the requested remittance.
The remittance request information NC7 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the remittance request received from B for the remittance request amount of "500 yen" are displayed. In addition, the remittance request information NC7 includes a remittance request remittance button that indicates "send remittance" for accepting this remittance request and remittance, and a remittance request button that indicates "reject" for rejecting this remittance request. A button to reject the remittance request is displayed.

Below that, a list of remittance requests that are unprocessed by the user who received the remittance request (user A.A in this example) is displayed at the time of receiving the remittance request. The display mode of unprocessed requests can be configured in the same manner as shown in FIG. 16-2, by way of example and not limitation, and therefore detailed explanation will be omitted.

Note that only unprocessed 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) are displayed as unprocessed requests. You may or may not have to do so.

At the bottom of the remittance request information NC7, there is displayed a remittance request remittance all-select-all-batch-settlement button that says "Settle all and remit" in order to execute the remittance based on this remittance request and all-select all-selected lump-sum settlement. There is. In addition, next to the remittance request remittance selection all batch settlement button, remittances based on this remittance request and partial selection batch settlement of unprocessed requests selected by the user among the unprocessed requests displayed in the remittance request information NC7 are displayed. A remittance request remittance partial selection batch settlement button BT20, which is displayed as "one settlement and remittance", is displayed for executing the remittance request.

As an example and not as a limitation, in the remittance request information NC7, the request check for the second received remittance request (payment to user B.B: 3,500 yen) is set to "ON" and selected, and the remittance request remittance is completed. When the partial selection batch payment button BT20 is tapped, the terminal 20A requests the server 10 to perform batch payment for the selected unprocessed requests. Then, from the server 10, the other party, user B. B's terminal 20B and user A. Settlement result information regarding the execution result is transmitted to A's terminal 20A.

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

The payment result information NC8 includes, by way of example and not limitation, user A. A is user B. By settling the payment for the remittance request amount "3,500 yen" based on the past remittance request from user B. Information regarding the execution of a remittance to B of "3,500 yen" is displayed.
The payment result information NC9 includes, by way of example and not limitation, user A. A is user B. By settling the payment for the remittance request amount "500 yen" based on the current remittance request from user B. Information regarding the execution of remittance of the remittance amount "500 yen" to B is displayed.

Note that user B. The payment result information displayed on the terminal 20B of user A. In addition to displaying the receipt of remittance from user A, user B. A list of unprocessed requests of B is added and displayed.

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

The payment result information NC10 includes, by way of example and not limitation, user A. A and user B. As the lump-sum payment was made with user A. A is user B. I paid "1,000 yen" to B, which is the sum of the remittance request amount "3,500 yen" from receiving the past remittance request and the remittance request amount "500 yen" from receiving the current remittance request ( The remittance is displayed.

Note that user B. Regarding the payment result information displayed on B's terminal 20B, the contents of the batch payment may or may not be displayed together as one piece of payment result information.

<Processing>
FIG. 19-4 is a flowchart showing an example of the flow of processing executed by each device in this embodiment.
The control unit 11 of the server 10 controls the user B.B. based on the request from the terminal 20B. The remittance request information from B and the remittance request list information are transmitted to the terminal 20A through the communication I/F 14 (S420).
Then, the control unit 11 of the server 10 moves 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 the remittance request list information has been received (A405: YES). , a batch payment screen including these pieces of information is displayed on the display unit 24 (A425).

If it is determined in A131 that an unprocessed request has been selected (A131: YES), the control unit 21 of the terminal 20A moves the process to A132. That is, request selection information including remittance information regarding remittance based on the received remittance request information and unprocessed request selection information indicating the selected unprocessed request is set.
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 moves the process to A133. That is, request selection information including remittance information regarding remittance based on the received remittance request information is set.

Note that this process will be described on the premise that remittance is performed based on received remittance request information.
In reality, there may be cases where the company chooses to process only the unprocessed requests without remittance based on the received remittance request information, but in this case, the process for bulk settlement of unprocessed requests as described above Since it is the same as that, illustration and re-explanation will be omitted.

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

<Effects of 21st Example>
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 the remittance request already received from the other user, and the second information is information regarding the remittance request already received from the other user. The first process indicates a configuration including a process of remitting money to the other user based on input to the terminal 20 that displays the first display and the second display.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily transfer money to the first user and the second user based on input to the terminal that displays the first display and the second display.

Further, in this case, the other user is one user, and the first process includes processing for remitting money to the other user based on the input to the terminal 20 that displays the first display and the second display. can do.
As an example of the effect of the embodiment obtained by such a configuration, it is possible to easily transfer money from one user (the first user) to the other user based on the input to the terminal that displays the first display and the second display. be able to.

<22nd Example>
The twenty-second embodiment is an embodiment related to processing of the pattern (e) described above.
The contents described in the twenty-second embodiment can be applied to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In the pattern of (e) Receive remittance request + Sent remittance request, either (e1) Remittance + Remittance reminder, or (e2) [Remittance + Receipt] (amount can be deducted) can be performed. .

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

In the process (e2), based on receiving a remittance request from the other user, remittance is made to the other user, and the other user sends money based on the remittance request already sent to the other user. Receive money. In this case, it is possible to remit/receive the difference in the remittance request amount. Furthermore, if the remittance request amounts are the same amount, it is possible to offset the amounts.
In this case, the other user's approval may or may not be obtained.

<Display screen>
FIG. 20A 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A. For details of the screen configuration, by way of example and not limitation, the sender of the remittance request is user C. Since the configuration can be similar to that shown in FIG. 19-1 in the case of C, detailed explanation will be omitted.
Please note that the sender of the remittance request is user C. The remittance request information in the case of C is herein referred to as remittance request information NC11.

As an example and not as a limitation, in the remittance request information NC11, the check of the request for the third sent remittance request (1,000 yen received from user C.C) is selected as "ON", and the remittance request remittance is completed. When the partial selection batch payment button BT21 is tapped, the terminal 20A requests the server 10 to perform batch payment for the selected unprocessed requests. Then, from the server 10, the other party, user C. C's terminal 20C and user A. Settlement result information regarding the execution result is transmitted to A's terminal 20A.

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

The settlement result information NC12 includes, by way of example and not limitation, user C. C is user A. It is displayed that the remittance request amount "500 yen" was received from the remittance request to A. Below that, user C. It is displayed that there are two unprocessed requests for C, by way of example and not limitation.

Settlement result information NC13 includes, by way of example and not limitation, the third remittance request selected in Figure 20-1 (remittance request amount "1,000 yen" sent by user A.A to user C.C). A reminder is displayed for the remittance request (remittance request).

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

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

The lump sum payment approval confirmation information NC14 includes user C. C is user A. User A pays the remittance request amount "1,000 yen" based on the past remittance request received from A. It is displayed that based on sending the current remittance request to A, the remittance request amount "500 yen" will be received.

In addition, the lump sum payment approval confirmation information NC14 includes user C. C is user A. From A, it is displayed that "500 yen" is to be paid, which is obtained by subtracting the remittance request amount "500 yen" due to sending the current remittance request from the remittance request amount "1,000 yen" due to receiving 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 based on the tapping of the payment button BT22 in FIG. 20-3.
In this example, in the announcement information display area NTR2 of the announcement screen, payment result information NC15 is displayed below the remittance request information NC11 as the contents of the lump sum payment.

The payment result information NC15 includes, by way of example and not limitation, user A. A and user C. As the lump sum settlement was carried out with C., the content of the lump sum settlement is the amount of the settlement result (in this example, the remittance amount "500 yen" that was remitted by user A.A from user C.C). (receipt) is displayed.
Also, under the contents of bulk payment, user A. The unprocessed request of A is displayed, and below it are displayed an all selection batch payment button and a partial selection batch payment button.
As an example and not as a limitation, the unprocessed requests displayed in settlement result information NC15 exclude the third sent remittance request that was processed this time among the unprocessed requests displayed in remittance request information NC11 ( 3 remittance requests (deleted).

<Processing>
The processing executed by each device in this embodiment can be implemented in the same manner as the processing shown in FIG. 19-4, and thus illustrations and detailed explanations will be omitted.

<Effects of 22nd Example>
In this embodiment, the first information is remittance request information regarding a remittance request sent from the proposer's user to the proposer's user, and the second information is remittance request information regarding a remittance request sent from the proposer's user to the proposer's user. Shows configuration that is sent remittance request information regarding.
As an example of the effect of the embodiment obtained by such a configuration, processing based on a remittance request from the first user to the terminal user and a remittance request sent from the terminal user to the second user is performed at once. be able to.

In this case, the first process is to send money to the other user and send a remittance reminder or new remittance request to the other user based on the input to the terminal 20 on which the first display and the second display are displayed. It is possible to include processing to do so.

In addition, the other user is one user, and the first process is to collect remittance request information regarding a remittance request sent from the other user to the proposer user, and information on remittances that have already been sent from the proposer user to the other user. It is also possible to include a process of remitting an amount based on sent remittance request information regarding the request to the other user, or having the amount transferred from the other user.
As an example of the effect of the 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 have the amount remitted from the first user and receive the amount.

In addition, in this case, the first process is based on the remittance request amount included in the remittance request information regarding the remittance request sent from the proposer's user to the proposer's user. Transfer the amount less the remittance request amount included in the sent remittance request information about the sender's user, or send the remittance request included in the sent remittance request information about the sender's user to the sender's user. The request may include a process of receiving from the other user the amount obtained by subtracting the remittance request amount included in the remittance request information regarding the remittance request sent from the other user to the proposer's user.
As an example of the effect of the embodiment obtained by such a configuration, the difference in amount can be remitted to the first user, or can be received by having the first user remit it.

Further, in this case, the first process may be executed based on the other user's approval based on the other user's input to the terminal 20.
As an example of the effect of the embodiment obtained by such a configuration, the first process can be executed based on the first user's approval based on the input to the first user's terminal. As a result, by way of example and not limitation, it is possible to prevent the first process from being executed against the first user's wishes.

<23rd Example>
The 23rd embodiment is an embodiment related to processing of a pattern different from the above-described pattern.
The content described in the twenty-third embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In addition to the above-mentioned patterns, by way of example and not limitation, there are patterns of combinations of new processing targets in the table of FIG. 16-1, that is,
・It is also possible to process a pattern of receiving money and remittance requests.

The processing for this pattern is similar to the processing for pattern (a). In other words, it is possible to perform "receipt + remittance" processing.

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

<24th example>
The 24th embodiment is an embodiment related to processing of a pattern different from the above-described pattern.
The content described in the twenty-fourth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

In addition to the patterns described above, by way of example and not limitation, the patterns of combinations of unprocessed requests in the table of FIG. 16-1, that is,
- It is also possible to process a pattern of received remittance requests + sent remittance requests.

The processing for this pattern is similar to the processing for pattern (e). In other words, either "remittance + remittance reminder" or "[remittance + receipt] (amount can be deducted)" can be performed.
In addition, when processing "[Remittance + Receipt] (amount can be deducted)", the approval of the other user is required, and the approval of the other user may or may not be obtained. You can.

<Effects of 24th Example>
In this embodiment, the second information is received remittance request information regarding a remittance request that has already been received from the other user, and based on the receipt of the remittance request from the other user, the second information is sent from the proposer user to the other user. A fourth display based on sent remittance request information regarding the remittance request that has already been sent is displayed on the display unit 24. Then, based on the 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 remittance request (remittance reminder). It shows the configuration to be performed.
As an example of the effect of the embodiment obtained by such a configuration, based on the input by the user of the terminal to the terminal on which the second display and the fourth display are displayed, information regarding remittance, receipt of remittance, or remittance is determined. A third process related to the request can be performed by the control unit.

Furthermore, in this case, the third process may include a process of remitting money to the other user and sending a remittance request or remittance reminder to the other user based on the input to the second display and the fourth display. I can do it.
As an example of the effect of the embodiment obtained by such a configuration, remittance to the second user and request for remittance to the second user can be performed at the same time.

Further, in this embodiment, the other user is one user, and the third process is to remit an amount based on the received remittance request information and the sent remittance request information to the other user, or to send the amount based on the received remittance request information and the sent remittance request information. It shows a configuration including processing for remittance.
As an example of the effect of the embodiment obtained by such a configuration, the amount based on the second information and the fourth information can be remitted to the second user, or can be received by having the amount remitted from the second user.

In addition, in this case, the third process is to remit to the other user the amount obtained by subtracting the remittance request amount included in the sent remittance request information from the remittance request amount included in the received remittance request information, or to send the sent remittance The request may include a process in which the other user remits an amount obtained by subtracting the remittance request amount included in the received remittance request information from the remittance request amount included in the request information.
As an example of the effect of the embodiment obtained by such a configuration, the difference amount can be remitted to the second user, or can be received by having the second user remit it.

Further, in this case, the third process can be executed based on the other user's approval based on the input to the other user's terminal 20.
As an example of the effect of the embodiment obtained by such a configuration, the third process can be executed based on the second user's approval based on the input to the second user's terminal. Thereby, by way of example and not limitation, it is possible to prevent the third process from being executed against the second user's wishes.

<25th example>
The 25th embodiment is an embodiment related to processing of a pattern different from the above-described pattern.
The content described in the twenty-fifth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

As an example and not a limitation, "receiving money" among the new processing targets in the table of FIG. 16-1 may be set to "receiving money".
"Rejecting payment" means that the remittance destination user does not receive the remitted amount.

in this case,
- Rejection of payment + received remittance request - Rejection of payment + sent remittance request - Rejection of payment + received remittance request + sent remittance request It is possible to process one of the following patterns.

In the pattern of rejecting payment + request for remittance that has already been received, only remittance processing can be performed.
In the pattern of rejecting payment + sending remittance request, only sending a remittance reminder (or new remittance request) can be processed.
In the pattern of refusing payment + received remittance request + sent remittance request, it is possible to process [remittance + receipt] (amount can be deducted).

<26th Example>
The 26th embodiment is an embodiment regarding a method of displaying remittance request information.
The content described in the twenty-sixth embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
FIG. 21A 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 shown by way of example and not limitation for user A. This is a payment application notification screen displayed on the display unit 24 of A's terminal 20A.
In the announcement information display area NTR2 of the announcement screen, remittance result information NC16 is displayed as content regarding the receipt of remittance (receipt).
The remittance result information NC16 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the receipt of the remittance amount "1,000 yen" remitted (received) from B are displayed.

Below that, a list of remittance requests that are unprocessed by the user to whom the remittance was made (user AA in this example) is displayed at the time of receiving the remittance. At the upper right of the list of remittance requests, a remittance request history sort button STB2 is displayed for changing the display order of unprocessed remittance requests. Other display modes are the same as remittance result information NC1.

When the remittance request history sort button STB2 is touched, by way of example and not limitation, a sort selection area for selecting a sort order from the bottom of the screen is raised and displayed.
Based on user operations in the sort selection area, the display order of unprocessed remittance requests can be arranged in ascending/descending order by date of sending/receiving remittance requests, amount of remittance requests, etc., by way of example and not limitation. It can be rearranged and displayed.

Note that the display order of unprocessed remittance requests may be rearranged and displayed in order of the date and time of transmitting/receiving the remittance requests, instead of in the order of the date of transmitting/receiving the remittance requests.

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

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

Note that when a payment deadline is set for a remittance request, by way of example and not limitation, the remittance requests may or may not be displayed in the order in which the payment deadline approaches. Setting a payment deadline includes, by way of example and not limitation, in addition to payments between individuals (CtoC), setting a repayment deadline for a loan from a financial institution (CtoB).

Furthermore, remittance requests in which the user who requested the remittance and the user other than the user who requested the remittance are involved in the amount or reason for the remittance request may be preferentially displayed. By way of example and not limitation, this is the case where other users are included as members of the split bill.

Further, although it has been described that unprocessed remittance requests are displayed in remittance result information and remittance request information, the present invention is not limited to this. By way of example and not limitation, processed remittance requests may or may not be displayed together with unprocessed remittance requests in a different display mode, such as grayed out.

<Effects of 26th Example>
In this embodiment, the proposer's user's terminal 20 receives remittance request information regarding a received remittance request that the proposer's user has received from the other user (without limitation, information sent from the second user to the terminal user). An example of fourth information regarding a remittance request), or remittance request information regarding a sent remittance request that has been sent by the proposer user to the other user (without limitation, information regarding a remittance request sent from the terminal user to the second user) A fourth display based on the fourth information (an example of the fourth information) is displayed on the display unit 24. The proposer's user terminal 20 is configured to display the second display and the fourth display 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 the 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.

Furthermore, in this embodiment, the above-mentioned second information and fourth information are information related to the date when the remittance request was sent/received (not limited to, but an example of information related to the date), or the date and time when the remittance request was sent/received. (This is not a limitation, but is an example of information related to the date and time), and the order in which the second display and the fourth display are displayed is determined based on the information related to the date or date and time.
As an example of the effect of the embodiment obtained by such a configuration, by displaying the second display and the fourth display in an order based on the date and time or information related to the date, a display that is intuitively understandable for the user can be realized. I can do it.

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

Furthermore, in this case, the information regarding the amount to be requested for remittance may include, by way of example and not limitation, information regarding the payment deadline in addition to the requested remittance amount.
As an example of the effect of the 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 understandable for the user. can.

<27th Example>
The 27th embodiment is an embodiment in which a chat service (chat application) is applied.
The content described in the twenty-seventh embodiment is applicable to any of the other embodiments and other modifications.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Display screen>
In the following, we will discuss user A., who is both a user of a messaging application and a user of a payment application. A and user B. B and user C. It is assumed that C and C both belong to group X and are registered as friends.

FIG. 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 limitation, a group chat (in this example, "Group X" chat) screen of a messaging application displayed on the display unit 24 of each user's terminal 20.
At the top center of the screen, the words "Messaging App" are displayed as the name of the messaging application. Further, at the top right of the screen, an icon image and a user name of the messaging application of the user of the terminal 20 are displayed.

Also, below that, a current location display area is configured that indicates the current location in the messaging application, and in this example, "Group X" indicates that the current location is a group chat of "Group X" in the messaging application. The characters are displayed in the current position display area.

A message display area, which is a display area for group chat messages (content), is displayed below the current position display area. The message display areas on the display section 24 of the terminals 20A to 20C are respectively referred to as message display area MSG1 to message display area MSG3.
In the message display area, messages sent from the own terminal are displayed in a speech bubble from the right side, and messages sent from a terminal other than the own terminal are displayed in a speech bubble from the left side together with the sender's icon.

By way of example and not limitation, user B. B is user A.B. As an example and not a limitation, consider a case where a remittance request is made to A for a remittance request amount of "1,000 yen" using a remittance 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 includes, by way of example and not limitation, user A. A is user B. Contents corresponding to the remittance request received from B for the remittance request amount of "1,000 yen" are displayed. Further, below that, a remittance request remittance button and a remittance request rejection button are displayed.
Below that, there is a record of the outstanding balance 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. A list of remittance requests that are being processed is displayed.
In addition, at the bottom of the remittance request information MC1, a remittance request remittance all-select all-select batch-settlement button is displayed that says "All payments and remittance" to execute the remittance based on this remittance request and all-select all-select batch settlement. has been done.

Further, remittance request information MC2 is displayed in the message display area MSG2 of the terminal 20B.
The remittance request information MC2 includes, by way of example and not limitation, user B. B is user A. Contents corresponding to the remittance request sent to A for the remittance request amount of "1,000 yen" are displayed. Furthermore, below that, a remittance request remittance button and a remittance request rejection button are disabled and displayed in a grayed out manner.
Below that, there is a record of the outstanding balance 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. A list of remittance requests that are being processed is displayed.
Further, at the bottom of the remittance request information MC2, an all-select all-at-once payment button is displayed that indicates "Pay all at once" for executing all-select all-at-once payment.

Remittance request information MC3 is displayed in the message display area MSG3 of the terminal 20C.
The remittance request information MC3 includes, by way of example and not limitation, user B. B is user A. Contents corresponding to the remittance request sent to A for the remittance request amount of "1,000 yen" are displayed. Furthermore, below that, a remittance request remittance button and a remittance request rejection button are disabled and displayed in a grayed out manner.
Also, below that is a list of unprocessed 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). The display is not displayed because you are not a party to these transfer requests.

Note that unprocessed remittance requests from parties other than the parties concerned may or may not be displayed in the remittance request information.

FIG. 22-2 shows, by way of example and not limitation, that remittance request information MC1 is swiped from right to left (swipe operation) (operation of sliding the finger while touching the screen). FIG. 3 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A based on the screen shown in FIG.
In FIG. 22-2, by way of example and not limitation, a payment details confirmation area ACR9 is displayed rising from the bottom of the display section 24 of the terminal 20A in FIG. 22-1.

At the top of the payment details confirmation area ACR9, user A. A is user B. A remittance request is received from user B. A message is displayed indicating that two unprocessed remittance requests (unsettled requests) remain with B.

In addition, at the bottom of the payment details confirmation area ACR9, user A. A is user B. When performing a remittance request remittance all selection batch payment with B, the amount of the remittance request received this time is "1,000 yen", the previously received remittance request amount "3,500 yen", and " 500 yen" is added to 5,000 yen. A confirmation message is displayed. In addition, below that, there is a remittance request remittance all selection bulk adjustment button BT23 which is displayed as "OK" to execute the remittance request remittance all selection bulk adjustment, and a "Cancel remittance request remittance all selection bulk adjustment button BT23 to cancel the remittance request remittance all selection bulk adjustment" button BT23. ” and a cancel button are displayed.

Note that even when the remittance request remittance all selection batch settlement button of 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 the screen displayed on the display unit 24 of the terminal 20A when the remittance request remittance all selection batch adjustment button BT23 is tapped in the payment details confirmation area ACR9 of FIG. 22-2. be.
In FIG. 22-3, in the message display area MSG1, remittance result information MC4 is displayed below the remittance request information MC1, based on the remittance results of the remittance processing by the remittance request and the remittance processing by the all-selected batch settlement. ing.

At the top of remittance result information MC4, user A. A is user B. It is displayed that the remittance request amount of "1,000 yen" was paid (remitted) to B, and "4,000 yen" was paid (remitted) as the lump sum settlement amount for the unprocessed remittance requests.

At the bottom of remittance result information MC4, user A. It is displayed that A has remitted "5,000 yen", which is the sum of the remittance request amount "1,000 yen" and the lump sum payment amount "4,000 yen" as the settled amount.

Note that the display corresponding to the remittance result information MC4 may or may not be displayed on terminals 20 other than the terminals 20A and 20B.
Further, the terminals 20 other than the terminals 20A and 20B that are the parties may or may not display only the remittance results at the bottom of the remittance result information MC4.

FIG. 22-4 is a diagram showing an example of a screen when unprocessed remittance requests are hidden from the remittance request information MC1.
As an example and not a limitation, when the user taps the unprocessed request hide button BT24 indicated by an x in the remittance request information MC1, an unprocessed request display cancellation confirmation area DRR1 appears from the bottom of the message display area MSG1. displayed on the screen.

In the unprocessed request display cancellation confirmation area DRR1, when a remittance or remittance request is made, the remittance request information and remittance result information include information regarding the relationship between the user who made the remittance request (remittance) (for example, user B.B), and the remittance result information. An unprocessed request display cancel button indicated by "OK" to not display a list of unprocessed remittance requests, and an unprocessed request display approval button indicated by "Cancel" to continue displaying the list are displayed. There is.

By way of example and not limitation, if the unprocessed request display cancel button in the unprocessed request display cancellation confirmation area DRR1 is tapped by a user, the remittance request information and remittance result information received from then on will include information about this user (for example, user B. The list of unprocessed remittance requests with B) will no longer be displayed.

Similarly, the unprocessed request hide button in remittance request information MC2 is set to user B. If user B taps the unprocessed request display cancel button in the unprocessed request display cancellation confirmation area, then user A. The list of unprocessed remittance requests with A will no longer be displayed.

In addition, if the Unprocessed Request Display Cancel button in the Unprocessed Request Display Cancellation Confirmation Area is tapped, a list of unprocessed remittance requests will be displayed in the remittance request information and remittance result information received from then on with all users. may or may not be displayed.

In other words, the present embodiment is configured such that unprocessed requests can be hidden based on the input by the user of the terminal 20 to the input section.

Note that instead of doing the above, as described above, the display/hide setting of unprocessed requests may or may not be set on a settings screen (not shown). good.

<Effects of 27th Example>
In this embodiment, the terminal 20 of the proposer's user is connected to a talk room that includes at least the proposer's user (an example of the terminal user, not limited to) and the other party's user (not limited to, an example of the first user). (an example of a chat room, not a limitation) is displayed on the display unit 24.The first display and the second display indicate the configuration displayed in this chat room.
As an example of the 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 form of display in a chat room.

Further, in this case, the second display displayed in the talk room can be hidden based on an input to the terminal 20 by the proposer's user.
As an example of the effect of the embodiment obtained by such a configuration, it becomes possible to secure a wide space in the display area.

Furthermore, in this case, the talk room includes users other than the parties involved (not limited to, but an example of a third user), and the second display is displayed in the talk room displayed on the terminal 20 of the users other than the parties involved. You can also do it like this.
As an example of the effect of the embodiment obtained by such a configuration, based on the second information regarding the remittance request sent from the second user to the terminal user, or regarding the remittance request sent from the terminal user to the second user. The second display, that is, the information regarding the user who is the party to the remittance, can be prevented from being viewed by a third user who is not the party.

In addition, in this case, the talk room displayed on the terminal 20 of the user other than the party concerned may contain remittance request information regarding a remittance request sent from a user other than the party, or information about the remittance request sent by the user other than the party, which is different from the second display. A fifth display based on remittance request information regarding the sent remittance request is included. The fifth display can be made not to be displayed in the talk room displayed on the terminal 20 of the proposer's user.
As an example of the effect of the embodiment obtained by such a configuration, a third display based on the fifth information regarding the remittance request transmitted from the third user or regarding the remittance request transmitted to the third user, which is different from the second display. 5 display, that is, information in which the third user is the party to the remittance, can be prevented from being viewed by the terminal user.

Further, in this case, the first display can be made not to be displayed in the talk room displayed on the terminal 20 of a user other than the user concerned.
As an example of the effect of the embodiment obtained by such a configuration, a first display based on first information regarding a remittance from the first user to the terminal user or a remittance request transmitted from the first user to the terminal user. In other words, it is possible to prevent the third user from viewing information regarding the user who is the party involved in the remittance.

Further, 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 according to the present disclosure. It shows the configuration.
As an example of the effect of the embodiment obtained by such a configuration, the first display and the second display can be displayed on the display section of the terminal by an application installed on the terminal.

<Others>
In the above embodiment, received remittance request information and sent remittance request information are exemplified as unprocessed information regarding remittance requests.

However, even if this information is 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 may be respectively applied as unprocessed information regarding remittance requests.
This is because a remittance request and a remittance reminder can be treated as synonymous.

Further, remittance request information and remittance reminder information can be arbitrarily combined. In other words, the following four combinations can be applied as combinations of received information and transmitted information.

(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) Third combination ・Received: Remittance reminder information ・Sent: Remittance request information

(4) Fourth combination ・Received: Remittance reminder information ・Sent: Remittance reminder information

1 Communication system 10 Server 20 Terminal 30 Network

Claims (33)

A program executed by a terminal,
a first display based on first information regarding a remittance request from the user of the terminal to the first user or a remittance request transmitted from the user of the terminal to the first user; and a transmission from the second user to the user of the terminal. perform a second display based on second information regarding the remittance request received or transmitted from the user of the terminal to the second user , and a first process based on the first information and the second information. displaying a third display different from the first display and the second display on a display unit of the terminal ;
The terminal executes the first process based on the first information and the second information regarding remittance, receipt of remittance, or request for remittance based on an input to the third display by a user of the terminal. The operations performed by the control unit of the terminal are executed by the terminal. The program according to claim 1 ,
The first information is information regarding remittance from the user of the terminal to the first user,
The second information is information regarding a remittance request sent from the second user to the user of the terminal,
The first process includes a process of remitting money to the first user and the second user based on the first information and the second information. The program according to claim 2 ,
The second user is the first user,
The first process includes a process of remitting an amount based on the first information and the second information to the first user. The program according to claim 1 ,
The first information is information regarding remittance from the user of the terminal to the first user,
The second information is information regarding a remittance request sent from the user of the terminal to the second user. 5. The program according to claim 4 ,
The first processing includes processing of remitting money to the first user based on the first information and transmitting a remittance request to the second user based on the second information. 5. The program according to claim 4 ,
The second user is the first user,
The first process includes a process of remitting an amount based on the first information and the second information to the first user, or a process of having the amount remitted from the first user. 7. The program according to claim 6 ,
The first information includes information on a first amount,
The second information includes information on a second amount,
The first process includes remitting an amount obtained by subtracting the second amount from the first amount to the first user, or remitting an amount obtained by subtracting the first amount from the second amount from the first user. Includes processing. The program according to claim 6 or claim 7 ,
The first process is executed based on approval by the first user based on input to the first user's terminal. The program according to claim 1 ,
The first information is information regarding a remittance request sent from the user of the terminal to the first user,
The second information is information regarding a remittance request sent from the second user to the user of the terminal. The program according to claim 9 ,
The first process includes a process of transmitting a remittance request to the first user based on the first information and remitting money to the second user based on the second information. The program according to claim 9 ,
The second user is the first user,
The first process includes a process of remitting an amount based on the first information and the second information to the first user, or a process of having the amount remitted from the first user. Claim 1 The program according to claim 1,
The first information includes information on a first amount,
The second information includes information on a second amount,
The first process includes remitting an amount obtained by subtracting the first amount from the second amount to the first user, or remitting an amount obtained by subtracting the second amount from the first amount from the first user. Includes processing. The program according to claim 1 1 or claim 1 2 ,
The first process is executed based on approval by the first user based on input to the first user's terminal. The program according to claim 1 ,
The first information is information regarding a remittance request sent from the user of the terminal to the first user,
The second information is information regarding a remittance request sent from the user of the terminal to the second user. The program according to claim 14 ,
The second user is the first user,
The first process includes a process of transmitting a first remittance request to the first user based on the first information, and transmitting a second remittance request to the first user based on the second information. The program according to claim 14 ,
The second user is the first user,
The first information includes information on a first amount,
The second information includes information on a second amount,
The first process includes transmitting, to the first user, a third remittance request based on a third amount that is the sum of the first amount and the second amount, based on the first information and the second information. Includes processing to do. The program according to claim 1,
The first information is information regarding remittance sent from the user of the terminal to the first user,
Displaying on the display section a fourth display based on third information regarding a remittance request transmitted from the user of the terminal to the first user;
Based on an input by a user of the terminal to the terminal on which the first display and the fourth display are displayed, the control unit performs a second process related to remittance, receipt of remittance, or request for remittance. and are performed by the terminal. The program according to claim 17 ,
The second process includes a process of remitting money to the first user based on the first information and transmitting a remittance request to the first user based on the third information. The program according to claim 17 ,
The second process includes a process of remitting an amount based on the first information and the third information to the first user, or a process of having the amount remitted from the first user. 20. The program according to claim 19 ,
The first information includes information on a first amount,
The third information includes information on a third amount,
The second process includes remitting an amount obtained by subtracting the third amount from the first amount to the first user, or remitting an amount obtained by subtracting the first amount from the third amount from the first user. Includes processing. The program according to claim 19 or claim 20 ,
The second process is executed based on approval by the first user based on input to the first user's terminal. The program according to claim 1,
The second information is information regarding a remittance request sent from the second user to the user of the terminal,
displaying on the display section a fifth display based on fourth information regarding the remittance request sent from the user of the terminal to the second user;
Based on the input by the user of the terminal to the terminal on which the second display and the fifth display are displayed, the control unit performs a third process related to remittance, receipt of remittance, or request for remittance. and are performed by the terminal. 2. The program according to claim 2 ,
The third process includes a process of remitting money to the second user based on the second information and transmitting a remittance request to the second user based on the fourth information. 2. The program according to claim 2 ,
The third process includes a process of remitting an amount based on the second information and the fourth information to the second user, or a process of having the amount remitted from the second user. 2. The program according to claim 2 ,
The second information includes information on a second amount,
The fourth information includes information on a fourth amount,
The third process includes remitting an amount obtained by subtracting the fourth amount from the second amount to the second user, or remitting an amount obtained by subtracting the second amount from the fourth amount from the second user. Includes processing. The program according to claim 24 or claim 25 ,
The third process is executed based on approval by the second user based on input to the second user's terminal. The program according to claim 1,
Displaying on the display section a fifth display based on fourth 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. and,
Displaying the second display and the fifth display on the display unit in an order based on the second information and the fourth information is executed on the terminal. The program according to claim 27 ,
The second information and the fourth information include the date or information regarding the date and time,
The order is determined based on information regarding the date or information regarding the date and time. The program according to claim 27 or claim 28 ,
The second information and the fourth information include information regarding the amount,
The order is determined based on information regarding the amount. 30. The program according to claim 29 ,
The information regarding the amount includes information regarding the payment deadline. The program according to any one of claims 1 to 30 ,
The first information is information for remittance from the user of the terminal to the first user, or for requesting remittance to be sent from the user of the terminal to the first user. An information processing method of a terminal,
a first display based on first information regarding a remittance request from the user of the terminal to the first user or a remittance request transmitted from the user of the terminal to the first user; and a transmission from the second user to the user of the terminal. perform a second display based on second information regarding the remittance request received or transmitted from the user of the terminal to the second user , and a first process based on the first information and the second information. displaying a third display different from the first display and the second display on a display unit of the terminal ;
The terminal executes the first process based on the first information and the second information regarding remittance, receipt of remittance, or request for remittance based on an input to the third display by a user of the terminal. and the control unit of the controller. A terminal,
a first display based on first information regarding a remittance request from the user of the terminal to the first user or a remittance request transmitted from the user of the terminal to the first user; and a transmission from the second user to the user of the terminal. perform a second display based on second information regarding the remittance request received or transmitted from the user of the terminal to the second user , and a first process based on the first information and the second information. a display unit that displays the first display and a third display different from the second display ;
Control for performing the first process based on the first information and the second information regarding remittance, receipt of remittance, or request for remittance, based on input to the third display by the user of the terminal. It is equipped with a section.

Images