JP7574257B2 - Information processing program, method, device, and system - Google Patents

Description

The present invention relates generally to an information processing program, method, device, and system for collecting money from users and processing payments between users via a network, and more specifically to a program, method, device, and system for managing and controlling collection processing, payment processing, and the like by controlling electronic value including electronic settlement.

In recent years, payments using electronic value such as credit cards and electronic money have become widespread.
For example, when several people use a credit card to split the bill when dining together, this is called "split the check" and is widely used in the United States and other countries. Payments using electronic value have been developed in a wide variety of ways.

For example, a system has been proposed that reduces the risk of losses to issuers of prepaid payment instruments that utilize the credit card mechanism (Patent Document 1).

That is, Patent Document 1 discloses an information processing system including a determination unit that sets a usage limit and a guarantee amount for each user within the range of each prepaid amount paid by multiple users who have applied for a prepaid payment means usable at a member store of a deferred payment means, a pool memory unit that stores a pool amount, which is used for paying sales invoices from the member store that exceed the remaining balance of the prepaid payment means and is the total amount of guarantee deposits for the multiple users, and a change unit that adds the guarantee amount to the pool amount stored in the pool memory unit each time the guarantee amount is set by the determination unit.

In addition, a system has been proposed that accepts reservations in which, even if a user does not have the credit to pay the usage fee with the credit card they wish to use at the time of making the reservation, the user will be able to pay with that credit card if the credit is restored (Patent Document 2).

That is, Patent Document 2 discloses an information processing device comprising: a reservation means for accepting a reservation in response to a request for a reservation in which the usage fee is paid by credit card after the date of service use, and storing information of the specified credit card in a storage means, when the validity of the specified credit card cannot be confirmed, a confirmation means for confirming the validity of the specified credit card based on the information stored in the storage means after the reservation is accepted by the reservation means, and an output means for outputting information indicating that the payment method will be payment with the specified credit card if the confirmation means is able to confirm that the specified credit card is valid, and for outputting information indicating that the payment method will be a method other than payment with the specified credit card if the confirmation means is unable to confirm that the specified credit card is valid.

Also, an information processing server that enhances user convenience by combining a stored-value type and a server-managed type payment system has been proposed (Patent Document 3).

In other words, Patent Document 3 discloses an information processing server that connects to a currency terminal that stores a first electronic value and has the function of increasing or decreasing the balance of the first electronic value using specified amount change information, and executes payment processing for a specified payment amount, characterized in that it is equipped with an identification data acquisition means for acquiring identification data from the currency terminal, and a shortfall reduction means for generating amount change information for reducing the balance of the first electronic value by at least the shortfall amount and transmitting the amount change information to the currency terminal when it is determined that a shortfall will occur when settling the specified payment amount using a second electronic value stored in a server-side storage means in correspondence with the acquired identification data.

In addition, in order to clarify who is responsible for payment when splitting the bill,
A system has also been proposed that reduces the possibility of the representative becoming aware of the contents of the payment settlement information when the representative receives payment settlement information from each member and sends it to the store (Patent Document 4).

In other words, Patent Document 4 discloses a system configured so that when each member terminal 50 notifies a credit company server 70 of the payment amount determined by the representative dividing the total amount sent from the store terminal 10 at the representative terminal 30, the credit company server 70 retains information for settling the payment and sends payment authorization information 63 containing encrypted information obtained by encrypting this information to each member terminal 50, each member terminal 50 sends payment authorization information 43 with the same content as the payment authorization information 63 to the representative terminal 30, and the representative terminal 30 sends payment authorization information 23 linked to the payment authorization information 43 to the store terminal 10.

Also, a credit card system that allows multiple-stage split payment has been proposed (Patent Document 5).

That is, Patent Document 5 discloses a credit card system comprising a notification means for notifying a member other than the credit card member of request information requesting that a portion of the credit card payment amount by the member be split equally, and a split information generation means for generating split information including the corresponding relationship between the person to split the bill and the person to split the bill and the respective credit card payment amounts when a member who has been notified of the request information by the notification means makes a credit card payment of part of the credit card payment amount, wherein the notification means is configured to notify another member other than the member in question of request information requesting that a portion of the credit card payment amount by the member who was the recipient of the split in a previous split payment be split equally, and the split information generation means is configured to generate split information including the corresponding relationship between the person to split the bill and the person to split the bill and the respective credit card payment amounts when the other member who has been notified of the request information by the notification means makes a credit card payment of part of the credit card payment amount by the member who was the recipient of the split.

In addition, an accounting processing device has been proposed that is capable of a shared settlement process in which, when a single ordered item is shared among multiple people, the price of the single item is divided and allocated among the multiple people (Patent Document 6).

That is, in Patent Document 6, in an accounting processing device that processes the payment amount of ordered products, when a group of multiple people orders a single product consisting of one item, a Share system is provided that divides and allocates the amount of the single ordered product to the multiple people who placed the order.
An accounting processing device that performs accounting settlement processing is disclosed.
With this accounting processing device, when multiple people are splitting the bill and each person is paying separately for each item they ordered, a list of ordered items for individual payment processing is displayed, with multiple items ordered in quantities divided into individual items.If Shared payment processing, which divides the amount of a single item, is also required, the relevant items are selected and the number of people for Shared payment is registered, and the relevant items are displayed on the screen divided into portions for that number of people.The relevant people can then be specified, and the accounting processing is performed by calculating the total individual payment amount and the Shared payment amount for each person and displaying it on the screen.

Patent No. 5678235 specification Patent No. 5269221 specification Patent No. 5595434 specification JP 2014-112286 A JP 2013-186732 A JP 2008-65574 A

However, the above-mentioned conventional technologies are mainly devised for electronic payments for individuals, and there is room for improvement in electronic payments within a group consisting of multiple members. Indeed, systems for processing payments related to splitting or sharing have been proposed (Patent Documents 4 to 6), but there is still room for further improvement in the processing of post-payment and post-payment collection, management control, etc.

Furthermore, it is desirable to provide new technologies (such as reminder technology and interface technology) and variations of technologies that can facilitate these interactions.

An information processing program according to an embodiment of the present invention is a program for coordinating a payment between a first user associated with a first information processing terminal configured to be able to converse with the first information processing terminal via a talk room managed on a server, and one or more second users associated with one or more second information processing terminals configured to be able to converse with the first information processing terminal via the talk room, the program including the steps of causing the first information processing terminal to request a payment to the second information processing terminal, receiving a response from the second information processing terminal, and, upon receiving the response from the second information processing terminal, making a payment to one or more second users associated with the second information processing terminal.
requesting the server to manage the user's payment method and payment term;
The present invention is characterized by carrying out the following steps.

The present invention provides improved bill-splitting and cost-sharing payment processing and/or administrative control techniques.

1 is an explanatory diagram illustrating an overall configuration of an information processing system according to an embodiment of the present invention; FIG. 1 is an explanatory diagram illustrating an example of the configuration of a system or device according to a variation of an embodiment of the present invention. FIG. 2 is an explanatory diagram for explaining an example of a basic operation in a system or device according to an embodiment of the present invention. 1 is a flowchart illustrating a basic operational concept flow in a system according to an embodiment of the present invention. 4 is a flowchart showing a more detailed example of the operation of the system etc. according to one embodiment of the present invention. 4 is a flowchart showing a more detailed example of the operation of the system etc. according to one embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating a functional concept of an operation in a system etc. according to an embodiment of the present invention. 2 is an explanatory diagram illustrating the flow of processing and data between devices or terminals in a system etc. according to one embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. FIG. 2 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. FIG. 11 is an explanatory diagram illustrating another example of a screen display on a device or terminal in a system or the like according to an embodiment of the present invention. 13 is a flowchart showing an example of operation of a system etc. according to another embodiment of the present invention. 13 is a flowchart showing an example of operation of a system etc. according to another embodiment of the present invention. 13 is a flowchart showing an example of operation of a system etc. according to another embodiment of the present invention. FIG. 13 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system etc. according to another embodiment of the present invention. FIG. 13 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system etc. according to another embodiment of the present invention. FIG. 13 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system etc. according to another embodiment of the present invention. FIG. 13 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system etc. according to another embodiment of the present invention. FIG. 13 is an explanatory diagram illustrating an example of a screen display on a device or terminal in a system etc. according to another embodiment of the present invention.

<Maintenance of confidentiality of communications>
It should be noted that the disclosure herein may be practiced subject to compliance with laws governing communications secrecy.

An embodiment for implementing an information processing system and the like according to the present disclosure will be described with reference to the drawings.

<System Configuration>
1 is a diagram showing a configuration of an information processing system according to an embodiment of the present disclosure. As shown in FIG. 1, the information processing system 100 includes one or more servers (server 110, server 120) and one or more terminals (terminal 151, terminal 152, terminal 153) via a network 199.
3) are connected. Servers 110, 120 provide a service to terminals 151 to 153 owned by users, which enables sending and receiving of messages between terminals via network 199. There is no limit to the number of terminals connected to network 199. There is also no limit to the number of servers (servers can be added to expand functions as necessary. The service may be provided by one server).

1, the network 199 serves to connect one or more servers and one or more terminals.
0 or 120, and then provides a connection path so that data can be transmitted and received.

For example, one or more portions of network 199 may be a wired network or a wireless network. Network 199 may be an ad-hoc network.
hoc network), intranet, extranet, virtual private network (VPN), local area network (LOA)
network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, part of the Public Switched Telephone Network (PSTN), mobile phone network,
ISDNs (integrated service digital networks), wireless LANs, LTE (long te
rm evolution), CDMA (code division multiple access), Bluetooth
oth (registered trademark), satellite communication, or the like, or a combination of two or more of these. However, in this disclosure, the network 199 is not limited to these.
Network 199 may include one or more networks.

The terminals (terminal 151, terminal 152, terminal 153) may be any information processing terminal capable of implementing the functions described in each embodiment. The terminals 151 to 153 are typically smartphones, and may also be mobile phones (e.g., feature phones).
, computers (e.g., desktops, laptops, tablets, etc.), media computing platforms (e.g., cable, satellite set-top boxes, digital video recorders), handheld computing devices (e.g., personal digital assistants (PDAs), etc.),
The terminals 151 to 153 may include a mobile terminal (a personal assistant, an email client, etc.), a wearable terminal (a glasses-type device, a watch-type device, etc.), or other types of computers or communication platforms. However, in this disclosure, the terminals 151 to 153 are not limited to these. Also, the terminals 151 to 153 may be expressed as information processing terminals.

Since the configurations of the terminals 151 to 153 are basically the same, in the following description, the terminal 151 will be described as a representative, and the terminals 152 and 153 will be described as necessary.
Similarly, for the servers 110 and 120, the server 110 will be described as a representative.

The server 110 has a function of providing a predetermined service to the terminal 151 and the like. The server 110 may be any device that can realize the functions described in each embodiment as an information processing device. The server 110 is typically a server device, and may also include computers (e.g., desktops, laptops, tablets, etc.), media computer platforms (e.g., cable, satellite set-top boxes, digital video recorders), handheld computer devices (e.g., PDAs, email clients, etc.), or other types of computers or communication platforms. However, in the present disclosure, the server 110 is not limited to these. The server 110 may also be expressed as an information processing device.

<Hardware (HW) configuration>
The HW configuration of each device included in the communication system will be described with reference to FIG.

(1) Device hardware configuration

The terminal 151 includes a control device 1510 (CPU: central processing unit), a storage device 1515, a communication I/F 1516 (interface), and an input/output device 1517.
, a display device 1518, a microphone 1519a, a speaker 1519b, and a camera 1519c. The hardware components of the terminal 151 are connected to each other via, for example, a bus B2.

The communication I/F 1516 transmits and receives various data via the network 199. The communication may be performed either wired or wirelessly.
Any communication protocol may be used.
The communication I/F 1516 transmits various data to the server 110 in accordance with an instruction from the control device 1510.
The /F 1516 receives various data sent from the server 110 and transmits it to the control device 1510 .

The input/output device 1517 is a device for inputting various operations to the terminal 151, and
The input/output device 1517 may be an integrated input device and an output device, or may be separate into an input device and an output device (in the latter case, for example, separated into an input device 1517a such as a touch panel input sensor and an output device 1517b such as a touch panel output device, a vibration drive mechanism, etc.).

The input device receives an input from a user and transmits information related to the input to the control device 1510.
The input device is realized by any one of all types of devices capable of transmitting a command to the control device 1510 or a combination thereof. The input device is typically realized by a touch panel or the like, detects a contact by a pointing tool such as a user's finger or a stylus and the contact position, and transmits the coordinates of the contact position to the control device 1510. On the other hand, the input device may be realized by an input device other than a touch panel. The input device includes, for example, hardware keys such as a keyboard, a pointing device such as a mouse, a camera (operation input via a moving image), and a microphone (operation input by voice). However, in the present disclosure, the input device is not limited to these.

The output device is realized by any one or a combination of all kinds of devices capable of outputting the processing results processed by the control device 1510. Representative output devices include:
The output device may be realized by a touch panel or the like. On the other hand, the output device may be realized by an output device other than a touch panel. For example, a speaker (audio output), a lens (e.g., 3D (three dimensional)
It may include a display device (messages output, hologram output), printer, etc. However, in the present disclosure, the output device is not limited to these.

The display device 1518 is realized by any one or a combination of all kinds of devices that can display according to display data written in a frame buffer (not shown). The display device 1518 is typically a monitor (e.g., a liquid crystal display or an OELD (organic display)).
The display device 1518 may be a head mounted display (HDM).
The display device 1518 may be realized by a device capable of displaying images, text information, and the like, by projection mapping, a hologram, or in air (which may be a vacuum). Note that these display devices 1518 may be capable of displaying display data in 3D. However, in the present disclosure, the display device 1518 is not limited to these.

When the input/output device 1517 is a touch panel, for example, the input/output device 1517 and the display device 1518 may be configured to have approximately the same size and shape and be disposed opposite each other.

The control device 1510 has circuits that are physically structured to execute functions implemented by codes or instructions contained in a program, and is realized, for example, by a data processing device incorporated in hardware.

The control device 1510 is typically a central processing unit (CPU), and may also be a microprocessor, a processor core, a multiprocessor, an ASIC (application-specific integrated circuit), or an FPGA.
However, in the present disclosure, the control device 1510 is not limited to this.

The storage device 1515 has a function of storing various programs and various data required for the operation of the terminal 151. The storage device 1515 includes a HDD (hard disk drive), a SS,
D (solid state drive), flash memory, RAM (random access memory), RO
The storage device 1515 may be realized by various storage media such as a read only memory (M), etc. However, in this disclosure, the storage device 1515 is not limited to these.

The terminal 151 stores the program P in the storage device 1515, and by executing the program P, the control device 1510 executes the processes of each unit included in the control device 1510. In other words, the program P stored in the storage device 1515 is
510 to realize each of the functions executed by the CPU 510.

The microphone 1519a is used to input voice data, the speaker 1519b is used to output voice data, and the camera 1519c is used to obtain moving image data.

(2) Server hardware configuration
The server 110 includes a control device 1110 (CPU), a storage device 1105, an input/output device 110
6, a display 1107, and a communication I/F 1108 (interface).
The various components of the HW in 10 are connected to one another via, for example, a bus B1.

The control device 1110 has circuits that are physically structured to execute functions implemented by codes or instructions included in a program, and is realized, for example, by a data processing device incorporated in hardware.

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

The storage device 1105 has a function of storing various programs and various data required for the server to operate. The storage device 1105 is realized by various storage media such as a HDD, an SSD, a flash memory, etc. However, in the present disclosure, the storage device 1105 is not limited to these.

The input/output device 1106 is realized by a device that inputs various operations to the server 110. The input/output device 1106 is realized by any of all types of devices that can receive input from a user and transmit information related to the input to the control device 1110, or a combination thereof. The input/output device 1106 is typically realized by hardware keys such as a keyboard, or a pointing device such as a mouse. The input/output device 1106 may include, for example, a touch panel, a camera (operation input via moving images), or a microphone (operation input by voice). However, in the present disclosure, the input/output device 1106 is not limited to these.

The display 1107 is typically a monitor (e.g., a liquid crystal display or an OELD (organic
The display 1107 is realized by a 3D electroluminescence display (3D display).
A head mounted display (HDM) or the like may be used. Note that these displays 1107 may be capable of displaying display data in 3D. However, in the present disclosure, the display 1107 is not limited to these.

A communication I/F 1108 transmits and receives various data via a network 199. The communication may be performed either wired or wirelessly.
Any communication protocol may be used.
The communication I/F 1108 has a function of executing communication with the terminal 151 via the communication I/F 1108. The communication I/F 1108 transmits various data to the terminal 151 in accordance with an instruction from the control device 1110.
The unit 1108 receives various data transmitted from the terminal 151 and transmits it to the control device 1110 .
The server 110 stores a program P in the storage device 1105, and executes the program P, causing the control device 1110 to execute the processes of each unit included in the control device 1110. In other words, the program P stored in the storage device 1105 causes the server 110 to realize each function executed by the control device 1110.

In each embodiment of the present invention, the CPU of the terminal 151 or the like and/or the server 110 or the like
The following description will be given assuming that the above is realized by executing a program P.

In addition, the control device 1510 of the terminal 151 and/or the control device 11 of the server 110
10 is not only a CPU but also an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)
Each process may be realized by a logic circuit (hardware) formed in a general scale integration (GeRSI) or a dedicated circuit. These circuits may be realized by one or more integrated circuits, and a plurality of processes shown in each embodiment may be realized by one integrated circuit. Also, LSIs are classified into VLSI, super LSI, ultra LSI, etc. according to the degree of integration.
It is sometimes referred to as SI.

Furthermore, the program P (software program/computer program) of each embodiment of the present disclosure may be provided in a state stored in a computer-readable storage medium. The storage medium can store the program in a "non-transitory tangible medium."

The storage medium may, where appropriate, include one or more semiconductor-based or other integrated circuits (ICs).
) (e.g., field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs)), hard disk drives (HDDs), hybrid
Hard drive (HHD), optical disk, optical disk drive (ODD), magneto-optical disk, magneto-optical drive, floppy diskette, floppy disk drive (
The storage medium may include a hard disk drive (HDD), a hard disk drive (FDD), a magnetic tape, a solid state drive (SSD), a RAM drive, a secure digital card or drive, any other suitable storage medium, or a suitable combination of two or more of these. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, as appropriate. It should be noted that the storage medium is not limited to these examples and may be any device or medium capable of storing the program P.

The server 110 and/or the terminal 151 can realize the functions of the multiple functional units shown in each embodiment, for example, by reading out a program P stored in a storage medium and executing the read out program P.

Furthermore, the program P according to one embodiment of the present invention may be provided to the server 110 or the terminal 151 via any transmission medium capable of transmitting the program (such as a communication network or broadcast waves). The server 110 and/or the terminal 151 executes the program P downloaded via the Internet or the like, for example, to realize the functions of the multiple functional units shown in each embodiment.

Furthermore, each embodiment of the present disclosure may also be realized in the form of a data signal embedded in a carrier wave in which the program P is embodied by electronic transmission.
At least a portion of the processing in the server 110 and/or the terminal 151 may be realized by cloud computing consisting of one or more computers.
At least a part of the processing in the terminal 151 may be configured to be performed by the server 110. In this case, for example, at least a part of the processing of each functional unit of the control device 1510 of the terminal 151 may be configured to be performed by the server 110.
At least a part of the processing in the server 110 may be performed by the terminal 151. In this case, for example, at least a part of the processing of each functional unit of the control device 1110 of the server 110 may be performed by the terminal 151.
In the present disclosure, a judgment configuration is not essential, and it goes without saying that a predetermined process may be executed when a judgment condition is satisfied, or a predetermined process may be executed when a judgment condition is not satisfied.

The program of the present disclosure can be implemented using, for example, a script language such as ActionScript or JavaScript (registered trademark), an object-oriented programming language such as Objective-C or Java (registered trademark), or a markup language such as HTML5, but the present disclosure is not limited to these.

<System configuration variations>
An example of the configuration of a system or device showing a variation of an embodiment of the present invention is shown in Fig. 2. The characteristic processing operation in the configuration shown in Fig. 2 (and Fig. 3) is that the present invention is not only realized by a linked operation with a server or terminal via a network, but can also be realized on a single terminal as necessary.

As shown in FIG. 2, the information processing system 200 includes, as a minimum configuration, an information processing server 210 and various information processing terminals used by users (for example, PC2
2, the server and the various terminals are connected via dedicated lines or public lines such as the Internet (wired lines,
In the case of wireless, the mobile phone 240 and the mobile information terminal or tablet terminal 250 wirelessly access the Internet 290 via a base station, a wireless router, or the like (not shown), and are further connected to the information processing server 210 via the line 280 so as to be able to communicate with each other.

In addition, mobile phones, mobile information terminals, and tablets are considered personal computers (PCs).
Many of them have the same processing capabilities (communication processing speed, image processing capabilities, etc.) as a small computer.

In addition, the program or software necessary for implementing the present invention is typically installed or stored in a HDD or SSD in the storage unit of a PC or mobile information terminal, and when the program or software is executed, all or part of it is read out as a software module into the memory in the storage unit as necessary, and is calculated and executed by the CPU.

The calculations do not necessarily have to be performed by a central processing unit such as a CPU, but may be performed by an auxiliary calculation device such as a digital signal processor (DSP) (not shown).

A PC can also be basically used as the hardware configuration of the information processing server 210. Although the present invention is not limited to this, the information processing server 210 can also be configured to be suitable for processing large-scale data by operating multiple PCs (for example, tens to tens of thousands) in parallel to increase the hardware specifications as necessary.

<Linkage with other systems not shown>
The information processing system according to one embodiment of the present invention is characterized by the fact that, when completing processing such as payment and collection, it can complete processing such as payment by appropriately coordinating with a credit company server, financial institution server, or store server (including an affiliated store terminal affiliated with the store) (not shown) as necessary. In that sense, it is not necessary for the information processing system according to one embodiment of the present invention to complete the entire series of processing such as payment within itself. In other words, the processing in the information processing system according to one embodiment of the present invention is sufficient at least up to outputting data such as ledger data required to complete a series of processing such as payment (of course,
Further processing is not excluded.

<Basic variations in movement>
Fig. 3 shows an example of basic operations in the system or device according to one embodiment of the present invention illustrated with reference to Fig. 1 and Fig. 2. What is particularly noted here is that the characteristic operations of the present invention can be realized independently of server cooperation by cooperative operations with a server or terminal via a network, or on a single terminal or between terminals.

3, the "user terminal" corresponds to the terminals 151 to 153 in FIG. 1 and the terminals 220, 230, 240, and 250 to 252 in FIG. 2, and the "information processing server" corresponds to the servers 110 and 120 in FIG. 1 and the information processing server 210 in FIG. 2.
In the figure, t1 to t10 indicate a time series flow, in which operations and processes described below are performed over time.

Note that the operations or processing times (t1, etc.) illustrated in the embodiments are illustrated for ease of understanding of the concept of the present invention, and the present invention is not limited to the individual chronological relationships illustrated in the embodiments.

First, at date and time t1, a user downloads application software from the information processing server via the user terminal for operating the user terminal as an information processing terminal according to the present invention (step S301). This application software is client software or application software for processing a part or all of the program according to the present invention. The downloaded application software is then installed in the user terminal (step S302). At this time, at time t2, the user terminal can also upload the user's own email address, as well as profile information as shown in the following table, to the information processing server (step S303) as user registration information, if necessary, for registration and management (step S304).

The above data items are stored as user data in a storage device on the information processing server (
Step S305. After time t3, the user can operate the information processing terminal to start the application (the server can start providing the service to the terminal).

Next, the user who has downloaded and installed the application on the user terminal starts the application software at time t4 (step S306). From time t4 to time t5, the user illustratively enjoys a service provided by the information processing terminal.

At time t5, the user temporarily suspends or terminates the application software according to one embodiment of the present invention. At this time, if necessary, the status information of the application is transferred to the information processing server (step S307), and the server receives the status information and updates (step S308) and stores (step S309) the status information as the user information of the user. In FIG. 3, these processes are completed by time t6.

After the application software according to one embodiment of the present invention is installed on an information processing terminal, it is of course possible for it to be in a form that can be executed in a completely closed manner on the terminal. In this case, the above-mentioned steps S304 to S305 and steps S308 to S309 can be omitted, and any necessary information is stored and managed in the memory on the terminal.

3, from time t7 to time t10, an embodiment in which at least a part of the application software according to one embodiment of the present invention is implemented in an information processing server is illustrated. In this case, a user performs two typical user terminal operations, namely, a login operation and a command transmission, and receives necessary data transmission or service provision from the information processing server.

3, when a user performs a login process to the server via his/her own information processing terminal at time t7 (step S310), the information processing server appropriately performs a necessary authentication process (step S311), and transmits data for the user to receive the service at time t8 (step S312), such as a top menu screen configured to be able to receive commands from the terminal, or an application startup screen.
At time t9, the user transmits a command via the information processing terminal (step S313). This command may be a selection of a menu displayed on a menu screen.
If it is an application start screen, it may be a start command for starting the application. The server side receives this command and starts service processing (step S314). Then, at time t10, the server provides the service according to the request of the terminal (step S315).

Although not shown in FIG. 3, even after time t10, the terminal can send commands at any time (for example, a message sending command or a menu selection command), and the server can receive commands from the terminal and provide services each time (for example, forwarding a received message to another terminal, analyzing the message and returning the results, etc.).

In one embodiment of the present invention, a user can also send a message from a user terminal to a specific person or a large number of specific people (not shown in FIG. 3). This message is relayed by the information processing server, forwarded to the specific person or to a large number of specific people, and received by the person. The sent message can also be viewed on the user's own terminal.
In particular, these message processes are realized by functional configurations (described later) implemented in the server and terminals.

<Functional configuration>
(1) Functional Configuration of the Terminal In one embodiment of the present invention, as shown in FIG. 1, the terminal 151 includes a control device 1510.
The functions realized by the programs and data stored in the storage device 1515 include a talk participation unit 1511 and a message processing unit 1512.
The talk participation unit 1511 has a function of performing processing for participating in a desired talk room. A user can participate in a talk room on an individual basis, and can also participate in a talk room on a group basis.

In one embodiment of the present invention, a BOT server (for example, server 110,
20, or a server equivalent thereto) can be provided, and this BOT server can also be equipped with the functions exemplified with reference to the terminal 151, thereby allowing the BOT to participate in a talk room in the same way as an individual user (at this time, a BOT as a user is given one account of an instant messenger service in the same way as a human user).
.
It is also possible to create a new talk room. By sending (saying) a message while participating in a talk room, the message is transmitted via the server 110 or the like to other participant terminals 2 participating in the same talk room and/or to the BOT server (a BOT as one user participating in the talk room).
Incidentally, BOT is a general term for a computer that performs tasks on behalf of humans, named after robot, and in the narrow sense, is a program that performs automatic chats.
In one embodiment of the present invention, the BOT may be managed in association with one or more users, or with a group to which one or more users belong.

The message processing unit 1512 has a function of performing processes such as generating messages in a talk room, sending and receiving messages, and controlling the display of the sent and received messages on the user's own terminal. A typical and basic example of message processing and display control is to display received messages on the left side of a time axis going from top to bottom, and to display sent messages on the right side.

The display processing unit 1513 displays the message data processed by the message processing unit 1512 on the display device 1518. The display processing unit 1513 has a function of converting display data (for example, character codes) into pixel information (for example, fonts, pictograms, etc.) and writing the pixel information into a frame buffer (not shown) of the display device 1518.
In addition, the BOT processing unit 1514 assumes part or all of the functions of a BOT processing unit 1116 on the server 110, which will be described later.

(2) Functional configuration of the server
In one embodiment of the present invention, as shown in FIG. 1, the server 110 includes a control device 111.
1105, and functions realized by the programs and data stored in the storage device 1105 include a talk room management unit 1111, a message processing unit 1112, and a billing information management unit 1113.
13, a billing processing unit 1114, a statistical processing unit 1115, and a BOT processing unit 1116.

The talk room management unit 1111 has a function of managing participants in a talk room.
When the message processor 1112 receives a message sent in a specific talk room from the terminal 151, the message processor 1112 detects the destination of the message from another participant terminal (e.g., the terminals 152 and 153).
3) and/or has the function of transmitting (transferring) the message to a BOT server (eg, server 120).

The billing information management unit 1113 performs calculations and management for billing a user (including a BOT) account in response to the provision of messages and the like for which billing is required.

The billing processing unit 1114 performs billing processing for each user account (including BOT) based on the billing information processed and managed by the billing information management unit 1113.

The statistical processing unit 1115 performs statistical processing from various viewpoints on the data processed by the billing information processing unit 1113 and/or the billing processing unit 1114, and stores and manages the results.

The BOT processing unit 1116 performs processing to perform tasks, make decisions, give advice, etc. on behalf of a user (human). Although the present invention is not limited to these, in more detail, the BOT processing unit 1116 includes a search unit 1116a for searching for appropriate data, a language processing unit 1116b for processing the language (including spoken language) contained in a transmitted/received message, an AI processing unit 1116c for determining the meaning or value of the processed language, etc., and learning based on the success or failure of the determination result, an image processing unit 1116a for analyzing a given image and recognizing an object that has been captured, etc.
d and other processing modules.

As described above, the BOT server (for example, the servers 110, 120, or equivalent servers) can also function similarly to an individual user by providing each of the functions exemplified with reference to the terminal 151 (at this time, the BOT server as a single user can be used as a single user).
T is assigned one account for an instant messenger service, just like a human user.) The assistant BOT operated by the BOT server and the human user can build a predetermined relationship with each other by forming a friendship relationship (linking accounts together), just like human users do with each other (such a predetermined relationship is appropriately described and managed in a database or relationship table, not shown).

First Embodiment
In the first embodiment, a user who participates in a talk room operated by a server or the like (for example, a "talk server" described later) can send and receive messages via a terminal, create an event page in the talk room, and, if necessary, appoint an assistant (a BOT) for himself or her or a group.
), have assistants (BOTs) communicate with each other, select the billing method between group members recruited on the event page, and process payments between members. The basic operation of the talk server, as well as
The basic operation of a BOT server that participates in a talk room as one user (one account) is described below with reference to Figures 4A to 6.
It should be noted that some or all of the contents described in the first embodiment are applicable to the other embodiments, except in cases where the features are mutually exclusive.

4A to 6, a server that basically provides a messaging service is a talk server (corresponding to server 110 in FIG. 1, etc.). In one embodiment of the present invention, a BOT server (corresponding to server 110 in FIG. 1, etc.) is introduced that participates in a talk room as one user (one account) in the same way as a user terminal.

Fig. 4A is a basic operational flow outlining the processes that occur when members of a chat room participate in an event such as a dinner party and settle the expenses through an information system according to an embodiment of the present invention. As a premise of Fig. 4A, at the start of the operational flow, one of the members (e.g., the organizer of the event within the group or other members who wish to participate in the event) enters and leaves the chat room as appropriate. Necessary messages and the like are exchanged in the chat room.

The basic example flow starts in step S401 of FIG.
Proceed to step 02, and as an example, an organizer user creates an event page via his/her own terminal. The event page can basically be set up independently on a server, but the present invention is not limited to this. For example, the event page can also be set up linked to a talk room (or within a talk room). In the following, for ease of understanding of the present invention, it is assumed that the event page is set up linked to a talk room or set up within a talk room.

An example of an event registration screen for an organizer user to create an event page via his/her own terminal is shown in Fig. 7. Fig. 7 shows a screen 700 of a user terminal (the terminal housing is omitted and only the display part is shown; the same applies below), and in addition to terminal status information 701 displayed at the top of the screen 700, there are also displayed, as bibliographical information for event registration, an event date and time input field 702, an event venue input field 703, an event budget input field 704, and a pre-participant list creation field 705. Although not shown in Fig. 7, it is also possible to input the event name separately.

The organizer user can register the event via the screen 700 illustrated in FIG. 7, create an event page (not shown) on a server, etc., and invite people to participate in the event by making announcements via the chat room, etc.

In step S403, the members of the other groups receive the event notification from the process in the previous step and declare their participation in the event (or their non-participation).
Participation/non-participation can also be indicated via the user terminal and the talk room.

FIG. 8 shows an example of a contact screen for group members to notify whether or not they will participate in the event via their own terminals. FIG. 8 shows a screen 800 of a user terminal.
At the top of the screen 800, terminal status information 801 is displayed, as well as the title "Participate/Non-participate", an event name display field 802, an event venue and date/time display field 803, and an event budget display field 804.

Group members indicate whether or not they will participate in the event via a screen 800 illustrated in Fig. 8. For example, they can indicate their intention by inputting information in a response section 805, such as whether or not they agree with the budget, and in a participation/non-participation response section 806.

More specifically, if the user agrees with the budget, the user presses check button 805a, and if the user does not agree, the user presses check button 805b. The user can also input a desired budget amount as necessary. In this case, the user presses button 805c and inputs the desired amount on a screen not shown. If the user wishes to participate in the event, the user presses check button 806a, and if the user does not wish to participate, the user presses check button 806b. The responses are recorded and managed by, for example, uploading them to a server.

[Guarantor Settings]
In one embodiment of the present invention, for example, a guarantor for payment can be set at the time of declaring participation/non-participation in an event. This is a system that flexibly reflects conventions such as a senior covering the expenses when a junior cannot pay, or a parent paying for their child in advance, and these relationships can be linked to a database or management table on a server, etc., through a guarantee request via a request screen (requester's terminal) not shown, and an approval process via an approval screen (guarantor's terminal) not shown.
In addition, the "guarantor" setting can be made for any user who is registered in the same chat room as the user who set the guarantor, or any user who is registered in a different chat room.

Fig. 9 shows an example of a notification screen on the terminal of the guarantor (user) who has received the guarantee request. Fig. 9 shows a screen 900 of the user terminal that has received the guarantee request, and in addition to the terminal status 901 displayed at the top of the screen 900, it also shows the notification title "Guarantee Approval Notification", an event name display field 902, an event venue and event date and time display field 903, and an event budget display field 904.
is displayed.
Also displayed is a message 905 informing the user that another user in the group has requested a guarantee for payment of the event fee.

The user who receives this can reply as to whether or not he/she agrees to pay on behalf of the client as the guarantor via reply field 906. Specifically, if he/she agrees to pay on behalf of the client as the guarantor, he/she presses check button 906a, and if he/she does not agree, he/she presses check button 906b. The reply content is recorded and managed by uploading it to a server, for example.

(Variations on the method of advance payment by guarantor)
As mentioned above, there are various methods for a guarantor to make an advance payment, such as paying the expenses later if the requester is unable to pay, or the guarantor paying the requester's share of the expenses in advance in advance. These types can be stored and managed on a server, etc., using flags, etc.

Returning to Fig. 4A again, when step S403 is completed, an event (such as a dinner party, a function, or a rehearsal or practice in a shared space, for which each participant incurs their own expenses) will be held at a date and time not shown in a place not shown. Of course, during this time, users will still communicate with each other via talk rooms. For example, they may exchange questions about how to get to a venue, or people living nearby may make individual arrangements to meet up.

In step S404, the event ends, and in order to begin accounting, the organizer, for example, takes a photo of a receipt or invoice showing the expenses incurred at the venue on his/her own terminal (equipped with a CMOS camera, not shown). Although the present invention is not limited to this, at this point, the representative (the organizer, for example) has paid the expenses in advance, for example by paying a lump sum by card. This receipt or invoice will include a breakdown of the food and drink consumed and the total amount if the event was a dinner party at a restaurant, and will include the amount of the venue usage fee, etc., if the venue is rented and the members practice, etc. Generally, this is printed, but this is not intended to exclude handwritten invoices.

In one embodiment of the present invention, a receipt or invoice photographed by a user terminal (such as an organizer terminal) is subjected to character recognition and converted into digital data, and is then stored and managed on the user terminal and/or a server.

If there are multiple receipts or if donations (investments) have been received in advance from non-participants, etc., a calculation operation is required, so in step S405, a calculation process is performed on the user terminal and/or server to calculate the total amount (the sum of amounts to be paid by participants).

If the process in step S405 is unnecessary, or if the total amount has already been determined in step S404, step S405 is omitted.

Next, proceed to step S406, and among the event participants (i.e., those who are obligated to pay in principle), paying participants are determined. Those who participate in the event but have their expenses covered by seniors or parents are excluded by the above-mentioned pre-processing. Alternatively, those who have declared that they will not participate in the event, or those who have not declared that they will participate/not participate but show up, can be added to the list of paying participants at this point.
In this way, the paying participant list is determined via the organizer terminal etc. The determined list is stored and managed on the user terminal and/or the server.

In step S407, an accounting method is selected for how the paying participants will share the payment. The simplest payment method is the so-called split payment, but the present invention allows various payment methods to be flexibly selected using an easy-to-understand interface (details will be described later).

Next, the process proceeds to step S408, where the payment amount of each paying participant is calculated. The calculated results are stored and managed on the server, and can be notified to the terminal of each paying participant.

In step S409, the selection of the payment time, payment method, etc. is accepted on the terminal of each paying participant. The accepted contents are stored and managed on the server.

In step S410, the payment is individually calculated based on the individual payment relationships managed on the server.
A payment process is performed (via the user terminal).

FIG. 10 shows an example of a notification screen on the terminal of the guarantor (user) who has accepted the guarantee request.
0 shows a screen 1000 of a user terminal that has accepted a guarantee request, and in addition to the terminal status 1001 displayed at the top of the screen 1000, there are also displayed the notification title "Inquiry regarding guarantor's ability to pay in advance," an event name display field 1002, an event venue and date and time display field 1003, and an event expense advance display field 1004.
Also displayed is a message 1005 informing the user that another user in the group who accepted the warranty request has not yet paid the amount even after a predetermined period of time has passed.

The user who receives this can instruct whether or not to make an advance payment as a guarantor for the client through the instruction field 1006. Specifically, if the user wishes to make an advance payment as a guarantor for the client, he or she presses the check button 1006a, and if not, he or she does not press the check button 1006b.
These instruction commands are recorded and managed by being uploaded to a server, and are appropriately processed for payment in cooperation with a payment server (not shown).

[Payment delay notice to a "friend" other than the guarantor]
In one embodiment of the present invention, in addition to the guarantor function described above, it is possible to set up a "friend" who will not guarantee the payment but will notify the member when the member has not made a payment (has made a payment late).
If the debt is left unattended, the aim is to encourage the debtor to make payment or repayment by sending a notice of delay to those whom it would be inconvenient for the debtor to know about the debt (such as a parent, close friend, or partner).

Such "friend" settings can be set up between members in advance, or by having someone who has acted as a guarantor in the past carry over as the "friend" setting, or by automatically registering particularly close people as "friends" to whom each other will send late notifications based on their communication history within the chat room.
In addition, the "friend" setting can be performed for users who are registered in the same chat room as the user who originally set the setting, or users who are registered in different chat rooms.

11A shows an example of a notification screen on a user terminal of a "friend" who is the destination of the delay notification. In FIG. 11A, a screen 1100 of the user terminal of the destination of the delay notification is shown.
The upper part displays the terminal status 1101, as well as the notification title "Friend's unpaid payment notification," an event name display field 1102, an event venue and date/time display field 1103, and an event fee unpaid amount display field 1104.
Also displayed is a message 1105 informing the friend user that the payment has not been made even after a predetermined period of time has passed.

The friend user who receives this can reply via reply field 1106 as to whether or not to notify the unpaid friend that he or she has received the unpaid notice. Specifically, if the friend user wishes to notify the unpaid friend that he or she has received the unpaid notice, he or she presses check button 1106a, and if the friend user does not wish to be notified, he or she presses check button 1106b. These instruction commands are recorded and managed by uploading them to a server, and can be used, for example, by pressing check button 1106.
When a is pressed, the server may send a notification or automatically transition to a chat room between the two parties (not shown) so that the two parties can contact each other.

[Payment management on the server, etc.]
The guarantees and other relationships described above are associated with a paying participant list, e.g., as shown in FIG.
When step S409 is completed, the information is managed on the server as shown in the following table.

Although the present invention is not limited thereto, in the above table, the paying participant is “Name (
The paying participant is managed by a "nickname" and a "membership number (ID)" (information about the paying participant can be obtained by referring to another table linked to this ID).
Same below).

The "Payment amount" field stores, for example, the amount calculated in step S408 of FIG. 4A. The "Guarantor" field stores the ID of the guarantor (the person who guarantees the payment of the paying participant) set as described above. If there is no guarantor, null or the like is inserted. The "Friend" field stores the ID of the friend described above. "Whether there is an obligation to repay to the guarantor"
The "Payment due date" field stores whether or not there is an obligation to repay the amount to be paid by the guarantor (repayment requirement flag). This repayment requirement flag can be set when the guarantor is set, etc., via a screen input field (not shown). The "Payment due date" field stores the payment due date by the paying participant. This payment due date can also be set as appropriate via a screen input field (not shown). Each payment due date is managed by the server, and various reminder processes (described later) are carried out for participants who have not made a payment by the due date.

FIG. 4B is a basic operational flow that more specifically illustrates the process of entering a talk room, which is a basic means of communication, sending and receiving messages, and the process when a BOT is present when a message is received through an information system according to one embodiment of the present invention.

In step S421 of FIG. 4B, when a user (a human user who is not a BOT) enters a talk room by starting an app via a user terminal, step S422
The user terminal then reads status information such as a talk list for running the app and/or information such as read messages from the talk server or from a storage device in the user terminal itself, and the information is loaded into the memory of the user terminal.

A talk list is a list of multiple talk rooms operated in a talk server, and for example, a user can enter a talk room of which he or she is a member by selecting the talk room and have a group talk with other member users. The group talk proceeds by members exchanging messages (sending and receiving messages from each other) through a messaging service provided by the talk server.

In FIG. 4B, the loop from step S423 to step S431 is a basic operation loop for communication, and unless the application is terminated (i.e., the user leaves the talk room) in step S431, the user can continue to send and receive messages with other members. In addition, in the basic operation loop, the user or group can be notified of the assistant B
When an OT (an advisor program with so-called AI functions, this BOT itself can participate in a talk room as a user with an account) is linked, this assistant BOT can provide advice to the user or forward at least a portion of messages received from other users to a talk server, etc.
In this case, the relationship between the user and the assistant BOT is similar to the relationship between human users.

In step S423, if the user sends a message or the like by an operation not shown (Yes), the process proceeds to step S424, where the message or the like is sent to the talk server (if the answer is No in step S423, the process proceeds to step S425). Although not shown in FIG. 4B, examples of basic operations that are processed depending on the contents of the message or the like sent in step S424 are as follows (1) to (3).

(1) When a user sends a message from the user's device to the talk server, the talk server forwards the received message to other members in the talk room.
In addition, if necessary, one or more BOT candidates related to the received message (i.e., capable of responding appropriately to the received message) can be extracted and sent back to the user who sent the message and/or other members in the chat room.

In one embodiment of the present invention, these BOT candidates are associated with BOT_I
D and a character image representing each BOT and/or a message indicating that it is a statement by a BOT.

(2) When a BOT_ID (described above) is transmitted from a user terminal to a talk server, the talk server can also make a request to a corresponding BOT (BOT server) based on the specified BOT_ID. In one embodiment of the present invention, the talk server makes a request to the BOT server for content candidates that the BOT server is currently preparing (i.e., content candidates that can be provided in accordance with the flow of the conversation in the talk room at that time).
Note that in one embodiment, the BOT_ID may be sent along with the user's message.

(3) When content is sent or specified from a user terminal to the talk server, the talk server sends (transfers) the content sent or specified by the user (such as text/audio information, image information, or links to specific sites, etc.) to other members in the group.

In step S425, if a message or the like is received for the user (Yes),
Proceeding to step S426, the user (or the talk group in which the user is participating)
It is determined whether an assistant BOT exists (i.e., is linked) in
If the answer is Yes, the process proceeds to step S427a, where a part or all of the message (already received in step S425) is selected. Then, the process proceeds to step S427b, where Assistant B
The call is transferred to the talk server via OT, and the process proceeds to step S428 (if No in step S426, the process proceeds directly to step S428).

In steps S427a to S427b, how many of the received messages are transferred to the talk server via the assistant BOT is determined by the user's permission settings, but the dunning BOT described below can be operated so that it cannot be set to not be permitted (i.e., it is always permitted).

Furthermore, the timing of the above transfer can be varied, for example, by (1) transferring at least a portion of the message to the talk server each time a message is received, or (2) transferring at least a portion of the message to the talk server each time a received message is displayed on the terminal.

In addition, at the timing of the above-mentioned transfer, when at least a portion of the received messages is transferred to the talk server, it is also possible to control so that, together with the portion of the messages, messages among the received messages that are not displayed on the terminal are also transferred to the talk server.

In step S428, the received message etc. is displayed on the user terminal.

In step S429, an object display for the user is received (Yes).
The process then proceeds to step S430, where appropriate processing is performed regarding how the received object is to be displayed on the terminal, and the process then proceeds to step S431 (if No in step S429, the process proceeds directly to step S431).

In step S431, when an instruction to leave the talk room is given by a user operation (not shown), this flow ends (step S432). If the answer is No in step S431, the process returns to step S423.

FIG. 4C is a basic operational flow shown primarily from the talk server's perspective.
In step S451 of FIG. 4C, when the talk server starts processing, step S4
Proceeding to 52, various status information for operating the talk room and the like are loaded into the memory in the server.

In FIG. 5, the loop from step S453 to step S461 is a basic operation loop of the talk server that manages communication between users. The talk server continues to send messages and the like (typically, BOT_I
There are messages that include D and messages that do not include D. There may also be a message with only BOT_ID) or content (containing the content itself or a designation message for designating the content).

In step S453, it is determined whether a message or the like has been received, and if the answer is No, the process proceeds to step S459, but if the answer is Yes, the process proceeds to step S454, where it is determined whether the received message or the like includes a BOT_ID. If the answer is No in step S454, a message or the like has been received from another user, so the process proceeds to step S457, where a process is performed to extract or identify a BOT (or a plurality of BOTs) that can respond in accordance with the contents of the received message. In one embodiment, the process of extracting or identifying a BOT is realized by an inquiry from the talk server to the BOT server (s) and a response.

Then, in step S458, the BOT candidates extracted or identified in the previous step are transmitted to other users in the talk group, and the process proceeds to step S459.
It should be noted that steps S457 and S458 are not essential steps and can be omitted as appropriate.

On the other hand, if the answer is Yes in step S454, the received message is typically (
Since this is a specification for a BOT candidate (already presented), the process proceeds to step S455, where a request for content or content candidates is sent to the specified specific BOT (server). Next, if content candidates are sent from the specific BOT (server), the received content candidates are sent to the user terminal that sent the message in step S456, and the above-mentioned content candidates are also sent to the terminals of other users via this user terminal (or without via this user terminal), thereby realizing real-time sharing of content.
Then, proceed to step S459.

In step S459, it is determined whether the content itself or a message designating the content has been received, and if Yes, the process proceeds to step S460, where the content is sent to other users in the group (if No in step S459, the process proceeds to step S461). At this time, if the received message is a message designating the content (for example, content information that can be obtained by specifying a URL), the content is acquired in the talk server as necessary and sent to other users in the group. Then, the process proceeds to step S461.

In step S461, it is determined whether or not to terminate the operation as a talk server, and the operation of the talk server is terminated by an operation not shown (Yes in step S461).
If so, the process proceeds to step S462 and the flow ends, but if the result is No in step S461, the process returns to step S453.

[Summary of functional modules for executing accounting flows such as payments]
FIG. 5 shows a functional concept of the operation of a system according to an embodiment of the present invention. In particular,
The functions described with reference to FIGS. 2 to 4C are implemented by the control device 1110 (server side) in FIG.
Since this requires an expanded processing unit in the control device 1510 (terminal side), the functions of each will be explained here.

As explained so far, a system etc. relating to one embodiment of the present invention broadly includes a collection UI etc. providing function 510 on the organizer terminal and a collection UI etc. providing function 520 on the terminals of participants, guarantors, other friends, etc., which are linked or synchronized with the server 110 etc. as appropriate (and thus the organizer terminal and participant terminals are linked), and the substance of each function is realized as various programs and data stored in memory devices 1105 and 1515, which are read into control device 1110 and control device 1510 as appropriate and executed (the same applies to the lower functions described below).

In Figure 5, the collection UI etc. provision function 510 on the organizer terminal broadly includes, as already mentioned, a receipt reading function, an amount confirmation (tallying) function, a bill splitting method selection function, various calculation functions, and various notification functions, but more specifically, it is divided into a collection list creation UI provision function 511 and a collection UI provision function 512, each of which has the sub-functions as shown in the following table.

In addition, the function 520 for providing collection UI etc. on the participant's terminal can be broadly divided into a function for reading receipts etc., a function for confirming (tallying) the amount, a function for selecting the method for splitting the payment etc., various calculation functions, and various notification functions, as already mentioned, but in more detail it is divided into a participant function 521 and a guarantor function 522, each of which has the sub-functions as shown in the following table.

Second Embodiment
The second embodiment describes the exchange of payments, messages, etc. between multiple user terminals (for example, an organizer terminal and participant terminals A to C, and guarantor terminals and friend terminals that may also be participants) as an operation scene of the entire system. As is clear from the explanation of the talk room, a server is also involved in the message exchange between user terminals, but the existence of the server is omitted here for ease of understanding (in reality, the server is involved as appropriate).
It should be noted that some or all of the contents described in the second embodiment are applicable to the other embodiments, except in cases where the features are mutually exclusive.
In addition, the operations or processing times (t1, etc.) illustrated in the embodiments are illustrated for ease of understanding of the concept of the present invention, and the present invention is not limited to the individual time series relationships illustrated in the embodiments (the same applies to the following embodiments in which the times are explicitly illustrated). In addition, what is described as an interaction between people is an interaction between terminals owned by each person, or an interaction between terminals via a server.
The following description will be given with reference to FIG.

In one embodiment of the present invention shown in FIG. 6, an event page is created on the organizer terminal by time t1, a list of participants to be invited in advance (pre-participant list) is created, and an event participation UI is sent to the invited members (A to C) (step S601).
Next, at time t2, each terminal returns a participation notice for the event (step S
6, for the sake of convenience, only one arrow indicates the declaration of participation in the event, but it is assumed that multiple participants have replied (the same applies to each process such as notification and payment described below, unless otherwise specified in step S305).

An event is held at a venue (not shown) from time t3 to time t4. In one embodiment of the present invention, participants bring their own terminals to participate in this event.

Next, the organizer requests the participants to pay the expenses incurred for the event up to time t5 (step S603). Although the present invention is not limited to this, the organizer can make a lump-sum advance payment (and then bill each participant), or the organizer can collect the expenses from each terminal in order to make a lump-sum payment (and then pay the lump-sum payment).

At time t6, participants A to C notify the organizer terminal of the payment method and payment time (payment deadline) from their own terminals (step S604). This information can also be recorded and managed by the server (the same applies to information exchanged between terminals below).
From this point on, in order to facilitate understanding of the invention, the responses of participants A to C (and the responses to participants A to C) will be made different, and the explanation will continue based on these assumptions.

[Participant A's response]
At time t7, payment is made from participant A to the organizer (step S605). In one embodiment of the present invention, electronic value is transferred (sent or moved) from the terminal of participant A to the organizer terminal, but the present invention is not limited to this and may involve any information processing that is essential for final settlement or the like.

[Response to Participant B, etc.]
Time t8 to time t12 are an operational flow showing an example of how to deal with participant B and his/her guarantor. At time t8, a predetermined period has already passed since time t6. Specifically, participant B's payment deadline to the organizer has passed (majorly in some cases).
First, the organizer sends a payment reminder to participant B (step S606).
The sender of this reminder notice does not necessarily have to be the organizing terminal, but may be the server-based party based on the server's time limit management (the same applies to the subject of notices, etc. below).

Time t9 may be a predetermined time after time t8 or may be immediately after time t8. At time t9, the organizer terminal (or server) sends a notice of participant B's non-payment to the terminal of participant B's guarantor (step S607). An example of the notice screen may be a simple non-payment notice (not shown), but the present invention is not limited to this, and may be a notice of inquiring whether or not payment can be made on behalf of the guarantor as exemplified with reference to FIG. 10 (in this operation flow, a notice of inquiring whether or not payment can be made on behalf of the guarantor is sent).
In addition, the above-mentioned notice of non-payment may be sent to the guarantor before sending an inquiry to the guarantor as to whether or not the guarantor can make the payment on behalf of the guarantor.

The notification subject as an application in steps S606 and S607 may be the above-mentioned BOT (dunning process by so-called dunning BOT).
In this case, the BOT can be made to make reminders and/or notifications by overcoming the non-permission settings of the reminder and/or notification recipient users in steps S606 and S607 (this is to prevent the BOT's contact, etc. from being rejected due to the non-permission settings of the reminder and/or notification recipient users).

At time t10, the guarantor of participant B agrees to pay the expenses of participant B on his/her behalf, and a payment process is carried out from the guarantor to the organizer (step S608). As a specific example, but not limited to, payment is made by electronic value.

At time t11, a notice of advance payment is sent from Participant B's guarantor to Participant B (Step S609), and at time t12, payment (so-called repayment) is made from Participant B to Participant B's guarantor (Step S610). In one embodiment of the present invention, repayment is made in Step S610 because the guarantee relationship between Participant B and Participant B's guarantor has been registered or set as one with an obligation to repay at the time of advance payment. If a guarantee relationship without an obligation to repay is established between the two parties, Step S610 is unnecessary and is omitted.

[Response to Participant C]
The period from time t13 to time t14 is an operational flow showing an example of how to respond to participant C and participant C's friends. At time t13, a predetermined period has already passed since time t6. Specifically, participant C's payment deadline to the organizer has passed. At time t13, the organizer first notifies participant C's friends of the non-payment (step S611). This non-payment notification does not necessarily have to be sent from the organizer terminal, but may be sent mainly by the server based on the server's deadline management (the same applies below). An example of a notification screen for notifying a participant's friend of the non-payment is shown in FIG.
As described with reference to FIG. 1A.

At time t14, the friend of participant C urges participant C to make payment (step S612
). Participant C is expected to make the payment to the manager promptly because he is being prompted by his close friend rather than by the manager.

The notification subject as an application in steps S611 and S612 may be the above-mentioned BOT (dunning process by so-called dunning BOT).
In this case, the BOT can be made to make reminders and/or notifications by overcoming the non-permission settings of the reminder and/or notification recipient user in steps S611 and S612 (this is to prevent the BOT's contact, etc. from being rejected due to the non-permission settings of the reminder and/or notification recipient user).

In particular, Fig. 11B shows an example of a notification screen when a variation of a third-party notification by a BOT is performed. Fig. 11B shows a screen 1150 of a user terminal that is communicating in a talk room, and in addition to displaying a terminal status 1501 at the top of the screen 1150, various messages are displayed in chronological order (flowing from top to bottom) within the talk room screen.

In this talk room screen, messages 1161 and 1162 are sent from a user terminal other than the user terminal displaying the screen, and messages 1163 and
1164 is sent from the user terminal displaying the screen.
Messages 1170 and 1180 are messages in which the BOT judges the flow of the above-mentioned message exchanges and sends a reminder or notification to the defaulter XX.

As an embodiment of the present invention, the conditions under which messages 1170 and 1180 are generated are as follows:
(1) A certain period of time has passed since the payment deadline for the non-payer.
(2) The non-payer or a friend or guarantor of the non-payer is participating in the chat room.

In addition, in FIG. 11B, an example of a reminder notice in the case where there is an obligation to repay the advance is shown, but the present invention is not limited to this, and the BOT can also send a reminder notice in the case where there is no obligation to repay the advance. In this case, the message 1170 is "By the way, Mr. XX, △
I haven't thanked △-san yet for the money he paid for me," and so on, with message 1180.
"I have to say thank you to Mr./Ms. XX! I have to say thank you to Mr./Ms. XX." Such reminders to say thank you also contribute to improving etiquette in social messaging.
Of course, in cases where there is no obligation to repay the advance, it is possible to operate the system so that the BOT is not required to send a reminder notice.

Third Embodiment
The third embodiment describes a variation of the present invention in which a third party transfers money to a group. According to this variation, for example, a third party inside or outside a group who does not participate in an event but wishes to provide funds (donate) can transfer money to the group (or a subgroup consisting of members who will participate in the event). The transfer method of this embodiment can also be applied to electronic red envelopes (online New Year's gifts of electronic money via an information processing terminal), which have become widespread in recent years.
It should be noted that some or all of the contents described in the third embodiment are applicable to the other embodiments, except in cases where the features are mutually exclusive.

A basic operation flow is shown in Fig. 12. When a remittance reservation setting process is started via a terminal screen (not shown) in step S1201 in Fig. 12, the process proceeds to step S1202, where a remittance destination group is set. In one embodiment of the present invention, remittance is performed automatically, and the remittance conditions therefor are set via a setting screen (not shown) in the subsequent step S1203.

Another feature of the present invention is that the remittance destination can be set not only to multiple individuals, but also to a group. When a remittance destination is set to multiple individuals, the remittance destination is fixed after the setting, but when a remittance destination is set to a group, even if the members of the group change after the setting, the remittance can be sent to the members at the time of the remittance (note that the remittance here has the same meaning as the transmission of electronic value or the transfer between terminals that has been explained so far. The same applies below).

The ability to set remittance destinations on a group basis makes it possible, even when making investments or donations to an event-participation group as described above, to accurately and reliably make investments or donations to the participating members who are confirmed at the start or end of the event.

In step S1203, remittance conditions are set. The conditions can be set with respect to the timing of remittance and the distribution at the time of remittance. Although the present invention is not limited to these, the following can be mentioned as the timing of remittance:
(1) When some event the group is working on is completed.
(2) When the sender (or receiver) achieves good results in an endeavor (such as an exam or competition).

In addition, the following distributions may be made at the time of remittance:
(1) Leave it with the group representative.
(2) Divide equally among group members.
(3) The points will be distributed according to each member's level of achievement in the event the group is working on.

When the above remittance condition settings are completed, the process proceeds to step S1204, and the remittance schedule setting process is completed.

FIG. 13 shows the process carried out on the server (or remittance server) side after the remitter (reserving) has completed the remittance reservation setting described with reference to FIG.

In step S1301, when an event trigger or an event handler is started based on the remittance conditions (among them, conditions related to the remittance timing) set in FIG. 12,
The process proceeds to step S1302, where it is determined whether an event that satisfies the remittance condition (or payment condition) has occurred. If the result in step S1302 is No, the process returns to step S13.
If the answer is Yes, the process returns to step S130.
Go to 3.

In step S1303, the remittance destination group information is read. At this time, the members belonging at this time are read, so that when a group invites a specific event participation group, the remittance to the specific participation group is allocated to the participants at this time. Alternatively, as another embodiment of the present invention, the remittance may be always remitted as a reserve fund to the entire group.

In step S1304, a remittance allocation process is performed for the group members to whom remittance is to be made, and in step S1305, remittance processing is performed for the group members. At this time, a remittance completion notice may be sent to the remitter (remitter) as necessary.
Then, the process proceeds to step S1306, where the remittance process is completed.

Fourth Embodiment
The fourth embodiment is a variation of the payment request in step S603 in Fig. 6, and will explain in detail the process from the start of collection to split payment processing or shared payment processing. The following will be explained with reference to Fig. 14.
It should be noted that some or all of the contents described in the fourth embodiment are applicable to the other embodiments, except in cases where the features are mutually exclusive.

When the process starts in step S1401 of FIG. 14, the process proceeds to step S1402.
The organizer terminal reads out the event participants. This reading may be performed by having the organizer terminal read out the registered members of the chat room, but the present invention is not necessarily limited to this, and it is also possible to operate it so that the members registered in some group managed on the server are read out (that is, in the fourth and subsequent embodiments, the event participants do not necessarily have to be members registered in the chat room).
.
In other embodiments of the present invention, this step may be omitted (in which case, skip from step S1401 to step S1403).

In step S1403, the organizer terminal calls for payment from the participant terminals present at the event (such as the event venue). In one embodiment of the present invention, a payment collection notification may be sent using near field communication (NFC).

In step S1404, the organizer terminal waits for payment applications from the participant terminals that have received the collection notification (if the result in step S1404 is No, the process returns to this step in a loop).
In one embodiment of the present invention, the payment entry of the participant terminal is performed using near field communication (NFC).
The notification is sent (transmitted) by pressing the terminal button, or by shaking the terminal. The shaking action is detected as a shaking of the terminal by an acceleration sensor or the like built into the terminal, and this can be regarded as a positive response to the collection notification.
Alternatively, the payment offers of the participant terminals may be transmitted by other means (sound waves, magnetic transmission means).
If the answer is Yes in step S1404, the process proceeds to step S1405.

In step S1405, the paying applicant (a person who agrees to pay) is added to the paying members. Then, the process proceeds to step S1406, where it is determined whether or not to end the payment application (call). This determination may be made by waiting for a response from all participants who have been called, or by having the organizer terminal end the process when a certain number of applications are received.
If the answer is No in step S1406, the process returns to step S1404, but if the answer is Yes, the process proceeds to step S1407.

In step S1407, the payment amount is divided among the paying members. In one embodiment of the present invention, an equal division process is performed, but the present invention is not limited to this, and various adjustments are possible. Further variations will be described in detail with reference to FIG. 15 etc.

In step S1408, a reconciliation process is performed between the paying members or between the paying members and other participating members. For example, if there are paying members D, E, and F, then D
If D pays for E and F, E and F will repay the advance to D at a later date. Alternatively, a certain percentage of the amount paid by the senior (for example, 10,000 yen) will be paid by the juniors at a later date (for example, a flat rate of 1,000 yen each).

After the above processing, this flow ends (step S1409).

Fifth Embodiment
The fifth embodiment will be described with reference to Figs. 15 to 19, focusing on examples of screen displays on a user terminal.
It should be noted that some or all of the contents described in the fifth embodiment are applicable to the other embodiments, except in cases where the features are mutually exclusive.
In particular, the fifth embodiment, which is specialized for the user interface, does not necessarily involve the transmission and reception of electronic value between user terminals or via a server, and can be adopted in various applications such as a bill splitting app when conducting cash transactions, or a "visible expense burden adjustment app."

In one embodiment of the present invention shown in Fig. 15(A), the display screen of a terminal 1500 (casing and the like are not shown) displays a terminal status 1501 as well as a friend or event participant list display field 1502. To display the relevant person in the display field 1502, the call and application (by shaking or the like) described in Fig. 14 may be performed, but these are not necessarily required on the screen of Fig. 15(A), and it is sufficient to simply call up (read out) the friend list or event participant list that has already been registered on the terminal.
The list is shown in Fig. 15B as M1 to M9, each of which represents an individual friend or an individual participant of the event.

15B, in addition to the terminal status 1511, the display screen of the terminal 1510 displays friends or event participants M1 to M9 read out in a friend or event participant list display field 1512, and as the screen indicates "Please check the payer," the organizer or the like can specify the person who will make the payment by tapping on the screen. In this case, at the venue (restaurant or the like) of the event such as a dinner party, it is sufficient for the organizer to actually call out to the person who will apply for payment, and therefore it is not necessary to use the above-mentioned NFC.
etc. is not necessary (of course, confirmation may be made by NFC communication etc.).

In one embodiment of the present invention, M1 to M3, M5, and M6 have responded to payment, and therefore the participant marks (circles) in the display field 1512 have been tapped or otherwise checked.

In one embodiment of the present invention shown in Fig. 16, in addition to displaying a terminal status 1601 on the screen of a terminal 1600, a friend or event participant list display field 1602 is also displayed. For ease of explanation, as a continuation of Fig. 15, participants M1 to M3, M5, and M6 who have made payments are displayed with check marks in display field 1602. An interface is provided here for determining each payment ratio (share of the payment amount).

In Fig. 16, first, the type of payment rate is determined using a selection menu (not shown). For example, there are the following options:
(1) Equal division (2) Step-by-step burden (e.g., three-step burden as shown in FIG. 16) and number of steps (3) Amount of each step in the case of (2) above (e.g., 10,000 yen, 50,000 yen, etc. as shown in FIG. 16)
00 yen, 3000 yen, etc.)

In FIG. 16, the above (2) and (3) are selected, and the burden is determined in three stages. The burden amount in each stage is 10,000 yen, 5,000 yen, 30,000 yen, and 40,000 yen, from the largest amount.
When such a selection is made, in one embodiment, burden icons (also called payment areas) 1605 to 1607 are displayed as shown in the figure.

Next, in order to determine how much each of the participants M1 to M3, M5, and M6 who have made the payment will pay, the icon of each person is moved to the burden amount icon by drag and drop or flick operation. In one embodiment, in the figure, M1 is 10,000
Since the payment is now 5,000 yen, the M1 icon is moved to the payment area 1605, and M2 is 5,000 yen.
Since the payment is now 3,000 yen, the M2 icon is moved to the payment area 1606, and M3 is 3,000 yen.
Since the burden is now in yen, the M3 icon is moved to the payment amount area 1607 (M5 and M6 will also be moved when the burden amounts are determined).

When determining the amount of burden in stages, the smallest amount of burden can include a fraction of the total amount. Also, if a contribution or donation has been received in advance from a third party, the contribution or donation can be subtracted from the total amount at this point before starting the burden ratio determination process.

FIG. 17 shows another method of determining the payment amount between the parties who have agreed to pay.
On the screen of 700, a terminal status 1701 is displayed, and a friend or event participant list display field 1702 is displayed. For convenience of explanation, this figure is depicted in relation to FIG. 16 (so that the payer is the same), but it can also be understood as a continuation of FIG. 15.

In FIG. 17A, icons of payers M1 to M3, M5, and M6 are displayed in display field 1702. Here, before or after determining the payment amount, the payer can be adjusted by the following operations.
(1) When bearing the share of other payers as well, the icon of the payer for the party being paid should be placed over the icon of the party paying.
(2) The above operation (1) can be executed multiple times (overlapping).
The above operations (1) and (2) are also called integrated operations or comprehensive processing.

In FIG. 17(A), as an example, M1 is to bear the burden of M2, M5, and M6 as well, so first the M2 icon is superimposed on the M1 icon by drag-and-drop or a flick operation, and then the M5 and M6 icons are each superimposed on the M1 icon (each is integrated).

Then, as shown in FIG. 17B, M1 and M3 remain on the display field 1712 as the actual payers (payment window), and the M1 icon shows "4" which indicates four people including M1's own payment, in the sense that it includes payments on behalf of three people, M2, M5, and M6.
The number will be displayed.

In the management table managed by the server, etc., a record or sub-table (not shown) is added to the data structure, and M1 pays for M2, M5, and M6 on behalf of M2 (or
Records such as "M2, M5, and M6 are to be borne by M1" are added.
Note that 1710 and 1711 correspond to 1700 and 1701, respectively.

Figure 18 shows the list of free people (those exempt from payment) from the friends or event participants list.
The interface function shown in Fig. 18 can also be used to exclude or exempt a person who has once agreed to pay.

In the figure, a terminal status 1801 is displayed on the screen of a terminal 1800, and a friend or event participant list display field 1802 is also displayed.
In the embodiment of the present invention, icons of members M1 to M9 are displayed.
In order to exclude free users (those exempt from payment) from this list, the user need only drag and drop or flick the relevant user out of a predetermined frame (frame 1803 in FIG. 18).

In one embodiment of the present invention, M4, M7 to M9 are determined to be free, so the respective icons are flicked out of the frame 1803. As a result, in the management table, M4
The charges for the events M7 to M9 are recorded and managed as zero.

19A shows an example of an interface that is configured to make it easy to intuitively check the progress rate of payments made by those who have made their payments. In FIG. 19A, a terminal status 1901 is displayed on the screen of a terminal 1900, and a friend or event participant list display field 1902 is also displayed. In the display field 1902, the following people M1 to M3, M5, M6, M7, M8, M9, M10, M11, M12, M13, M14, M15, M16, M17, M18, M19, M20, M21, M22, M23, M24, M25, M26, M27, M28, M29, M30, M31, M32, M33, M34, M35, M36, M37, M38, M39, M40, M41, M42, M43, M44, M45, M46, M47, M48, M49, M50, M51, M52, M53, M54, M55, M66, M67, M68, M70, M71, M72, M73, M74, M75, M76, M81, M82, M83, M84, M85, M91, M92, M93, M94, M95, M96, M97, M98, M99, M100, M101, M102, M1102, M1202, M1302, M140, M150, M161, M172, M182, M190, M190, M190, M190, M190, M190, M201, M202, M21, M22, M23, M24,
6, and a payment completion confirmation box 1903 is displayed.
This payment completion confirmation frame is a confirmation area in which the payment status of the person making the payment can be confirmed.

In one embodiment of the present invention, those who have actually completed their payment flick the corresponding icons into frame 1902 in sequence.

Then, the percentage of the total amount collected can be visually displayed as in (B) to (D) in the figure. (B) shows the state where 30% of the total amount has been collected, (C) shows the state where 50% of the total amount has been collected, and (D) shows the state where 100% has been collected.
In one embodiment of the present invention, (B) to (D) in the figure show the area according to the burden ratio of the person who pays (or the total payment amount at that time).
The display area of "100% Complete" shown in the confirmation area 100 is an area corresponding to the total of the burden ratios of those who agree to pay, and corresponds to the total area of the confirmation area.

In this way, by adopting the interfaces shown in Figures 19(A) and (B), the bill collection process can be smoothly carried out even in busy restaurants, which is preferable.
The payment method may be the transfer of electronic value between terminals as explained above, or may be a cash transaction. In either case, the effect of making it easier to share and collect the cost ratio is achieved.

Although the embodiments of the present disclosure have been described based on the drawings and examples, it should be noted that those skilled in the art can easily make various modifications and corrections based on the present disclosure. Therefore, it should be noted that these modifications and corrections are included in the scope of the present disclosure. For example, the functions included in each means, each step, etc. can be rearranged so as not to be logically contradictory, and multiple means, steps, etc. can be combined into one or divided. In addition, the configurations shown in each embodiment may be appropriately combined.

100, 200 Information processing system 110, 120 Information processing device (server)
151, 152, 153 Information processing terminal 199 Network 210 Information processing server 220, 230 PC (information processing terminal)
240 Mobile phone (information processing terminal)
250, 251, 252 Tablet (information processing terminal)
260, 270, 280, 290 Network

Claims (9)

A program executed by a server that processes information displayed in a talk room in which a first user and a second user participate,
acquiring a first amount to be paid by the second user and a first payment deadline for the first amount by a control unit of the server;
executing a first control by the control unit to display a first display in the talk room, the first display requesting payment of the first amount;
The program includes: executing second control by the control unit to display a second display in the talk room urging payment of the first amount based on the first amount not being paid by the first payment due date. The program according to claim 1 ,
A program that executes the second control by the control unit based on information based on the second user's failure to pay the first amount by the first payment due date being acquired by the control unit from the terminal of the first user. The program according to claim 1 ,
A program for causing the control unit to execute the second control based on a determination by the control unit that the second user has not paid the first amount by the first payment due date. The program according to claim 3 ,
The second control is a program including control for associating the second display with a BOT account and displaying it in the chat room. The program according to any one of claims 1 to 4 ,
the talk room is a talk room in which a third user participates,
acquiring, by the control unit, a second amount to be requested to be paid by the third user and a second payment deadline for the second amount;
performing a third control by the control unit to display a third display in the talk room, the third display requesting payment of the second amount;
The program includes a fourth control performed by the control unit to display a fourth display in the talk room urging payment of the second amount based on the second amount not being paid by the second payment due date. The program according to claim 5 ,
The first amount and the second amount are calculated based on a recognition result of an image captured by an imaging unit of the terminal of the first user. The program according to any one of claims 1 to 6 ,
A program including executing a fifth control by the control unit to display a fifth display notifying that payment of the first amount has not been made in a talk room in which a fourth user different from the second user participates. 1. An information processing method for a server that processes information displayed in a talk room in which a first user and a second user participate, comprising:
acquiring a first amount to be paid by the second user and a first payment deadline for the first amount by a control unit of the server;
performing a first control by the control unit to display a first display in the talk room, the first display requesting payment of the first amount;
An information processing method including: performing second control by the control unit to display a second display in the talk room urging payment of the first amount based on the first amount not being paid by the first payment due date. A server that performs processing related to information displayed in a talk room in which a first user and a second user participate,
a control unit that performs first control to acquire a first amount requested to be paid by the second user and a first payment deadline for the first amount, and to display a first display requesting payment of the first amount in the talk room;
The control unit performs a second control to display a second display in the chat room urging payment of the first amount based on the fact that the first amount has not been paid by the first payment due date.