Program, information processing method, server, and system
Patent Information
- Application Number
- JP2023133102
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-17
- Publication Date
- 2025-02-28
Smart Images

Figure 2025027879000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a program, an information processing method, a server, a system, and the like. [Background technology]
[0002] Recently, services that use applications executable on terminals such as smartphones to manage the terminals or the terminal users' electronic currency (electronic money) and to realize settlement using electronic currency are becoming widespread. For example, Patent Document 1 discloses a technology for settling the purchase amount of a product. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2002-176671 A Summary of the Invention
[0004] According to a first aspect of the present invention, a program executed by a server communicating with a first terminal of a first user is executed by the server to transmit information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user via a communication unit of the server, and to transmit information of a first amount, of multiple amounts to be remitted to the first user, to the second terminal via the communication unit based on an input by the second user in response to the remittance request information. According to a second aspect of the present invention, an information processing method of a server communicating with a first terminal of a first user includes transmitting information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user via a communication unit of the server, and transmitting information of a first amount, among multiple amounts to be remitted to the first user, to the second terminal via the communication unit based on an input by the second user in response to the remittance request information. According to a third aspect of the present invention, a server communicating with a first terminal of a first user has a communication unit that transmits information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user, and transmits information of a first amount, among multiple amounts to be remitted to the first user, to the second terminal based on an input by the second user in response to the remittance request information. According to a fourth aspect of the present invention, a system including a first terminal of a first user and a server communicating with the first terminal comprises a communication unit of the server that transmits information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user, and a communication unit of the second terminal that receives the information of the remittance request, and the communication unit of the server transmits information of a first amount, of multiple set amounts to be remitted to the first user, to the second terminal based on an input by the second user in response to the information of the remittance request. [Brief description of the drawings]
[0005] [Figure 1-1] FIG. 1 is a diagram showing an example of the configuration of a communication system according to an embodiment. [Figure 1-2] FIG. 4 is a diagram showing an example of functions realized by a control unit of the server according to the embodiment. [Figure 1-3] FIG. 4 is a diagram showing an example of information stored in a storage unit of a server according to an embodiment. [Figure 1-4] FIG. 4 is a diagram showing an example of account registration data according to the embodiment. [Figure 1-5] FIG. 4 is a diagram showing an example of an account management database according to the embodiment. [Figure 1-6] FIG. 13 is a diagram showing an example of a division management database according to the embodiment. [Figure 1-7] FIG. 4 is a diagram illustrating an example of functions implemented by a control unit of the terminal according to the embodiment. [Figure 1-8] FIG. 4 is a diagram showing an example of information stored in a storage unit of the terminal according to the embodiment. [Figure 1-9] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-10] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-11]FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-12] 4 is a flowchart showing an example of the flow of processes executed by each device according to the first embodiment. [Figure 1-13] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-14] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a first modified example. [Figure 1-15] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a first modified example. [Figure 2-1] FIG. 11 is a diagram showing an example of account management data according to the second embodiment. [Figure 2-2] FIG. 11 is a diagram showing an example of split management data according to the second embodiment. [Figure 2-3] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second embodiment. [Figure 2-4] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second embodiment. [Figure 2-5] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second embodiment. [Figure 2-6] 10 is a flowchart showing an example of the flow of processes executed by each device according to the second embodiment. [Figure 3-1] FIG. 13 is a diagram showing an example of division management data according to the third embodiment. [Figure 3-2] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. [Figure 3-3] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. [Diagram 3-4] 13 is a flowchart showing an example of the flow of processes executed by each device according to the third embodiment. [Figure 3-5] 13 is a flowchart showing an example of the flow of processes executed by each device according to the third embodiment. [Diagram 3-6] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. [Diagram 3-7] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. [Diagram 3-8] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. [Diagram 3-9] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. [Figure 3-10] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third modified example. [Figure 3-11] 13 is a flowchart showing an example of the flow of processes executed by each device according to a third modified example. [Figure 3-12] 13 is a flowchart showing an example of the flow of processes executed by each device according to a third modified example. [Figure 3-13] 13 is a flowchart showing an example of the flow of processes executed by each device according to a third modified example. [Figure 4-1] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-2] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-3] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-4] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth modified example. [Figure 4-5] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth modified example. [Figure 5-1] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. [Figure 5-2] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. [Figure 5-3] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fifth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0006] <Compliance with legal matters> It should be noted that the disclosures described herein are subject to compliance with the laws of the country of implementation, such as communications secrecy, as necessary for the implementation of the disclosure.
[0007] <Embodiment> In this specification, for ease of understanding, there are some places where the phrase "by way of example and not by way of limitation" is used, but please note that not only these places but also the entire embodiment described below are not limited to the contents of the description.
[0008] An embodiment for implementing a program or the like according to the present disclosure will be described with reference to the drawings.
[0009] The production of a terminal of the present invention (a terminal of the present invention) may include, by way of example and not limitation, the concept of a program (an application program, by way of example and not limitation) described in this specification being received (or being received and stored in) a terminal owned (possessed) by a user, thereby creating a state in which the functions of the present invention can be realized (a state in which the present invention can be executed) in the terminal.
[0010] Furthermore, the production of the system of the invention claimed in the present application (the system of the invention) may include the concept that, by way of example and not limitation, a state in which the functions of the invention of the system claimed in the present application can be realized (a state in which the invention claimed in the present application can be executed) is created by receiving, at a terminal included in the system of the present application, a program described in this specification (by way of example and not limitation, an application program) transmitted from a server included in the system of the present application (or by storing the received program in the terminal).
[0011] In addition, in this specification, a system may be, for example and not by way of limitation, configured to include a plurality of devices. The multiple devices may be a combination of devices of the same type, a combination of devices of different types, or a combination of devices of the same type and devices of different types. Note that a system can be considered, for example and not by way of limitation, as a plurality of devices working together to perform some kind of processing.
[0012] Furthermore, a system relating to a client (client device) and a server can be considered to be, by way of example and not of limitation, at least one of the following: (1) Terminals and servers (2) Server (3) Terminal
[0013] (1) is, by way of example and not limitation, a system including at least one terminal and at least one server. One example of this is a client-server system.
[0014] The server is configured by the following devices, for example and not by way of limitation, and may be a single device or a combination of multiple devices.
[0015] Specifically, the server is configured to have at least one processor (for example and without limitation, CPU: Central Processing Unit, GPU: Graphics Processing Unit, APU: Accelerated Processing Unit, DSP: Digital Signal Processor (for example and without limitation, ASIC: Application Specific Integrated Circuit, FPGA: Field Programmable Gate Array), etc.), computer device (processor + memory), control device, arithmetic device, processing device, etc., and may be a configuration having multiple of the same type of any one device (for example and without limitation, CPU + CPU, homogeneous multi-core processor, etc.) or a configuration having multiple different types of any one device (for example and without limitation, CPU + DSP, heterogeneous multi-core processor, etc.), or may be a combination of multiple devices (for example and without limitation, processor + computer device, processor + arithmetic device, multiple devices made heterogeneous, etc.). The processor may be a virtual processor.
[0016] Also, when a server executes some processing, if the server is configured with a single device, the processing described in the embodiment is executed by the single device. If the server is configured with multiple devices, one device may execute some processing, and the other device may execute other processing. As a non-limiting example, if the server is configured with a processor and an arithmetic device, the processor may execute a first processing, and the arithmetic device may execute a second processing. Furthermore, when a configuration is made up of a plurality of devices, the devices may be arranged in locations physically separated from one another.
[0017] Furthermore, the functions of the server may be provided in the form of PaaS, IaaS, or SaaS in cloud computing, for example and without limitation.
[0018] The control unit of the system may be at least one of the control unit of the terminal and the control unit of the server. That is, by way of example and not limitation, the control unit of the system may be any of the following: (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server.
[0019] In addition, the control and processing (hereinafter collectively referred to as "control, etc.") performed by the control unit of the system may be performed by (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server. In addition, in (1C), as an example and not a limitation, some of the controls performed by the control unit of the system may be performed by the control unit of the terminal, and the remaining controls may be performed by the control unit of the server. In this case, the allocation (allocation) of the controls may be equal or may be allocated in different proportions.
[0020] Furthermore, when referring to a communication unit of a server, if the server is configured with a single device, it may be the communication unit itself that the single device has, or, if the server is configured with multiple devices, the communication unit of the server may be configured to include each communication unit that each device has. As an example and not by way of limitation, if a server comprises a first device and a second device, the first device having a first communication unit and the second device having a second communication unit, the communication unit of the server may be conceptualized as including the first communication unit and the second communication unit.
[0021] (2) is not limited to, but may be, for example, a system consisting of multiple servers (hereinafter, referred to as a "server system"). In this case, the configuration of each server may be the same as that described above.
[0022] The control etc. performed by the server system may be performed by only one of the multiple servers (2A), by only the other servers (2B), or by both the one server and the other servers (2C). In addition, in (2C), as an example and not a limitation, one server may perform part of the control etc. performed by the server system, and another server may perform the remaining control etc. In this case, the allocation (allocation) of the control etc. may be equal or may be allocated in different proportions.
[0023] (3) By way of example and not limitation, the system may be comprised of multiple terminals. The system may be, by way of example and not limitation, a system such as the following: A system that gives server functions to terminals (distributed system). This can be realized using blockchain technology, for example and not by way of limitation. A system in which terminals communicate wirelessly with each other. This can be realized, for example and without limitation, by communicating in a peer-to-peer (P2P) manner using short-range wireless communication technology such as Bluetooth (registered trademark).
[0024] The above is not limited to the control unit, but also applies to each functional unit such as an input / output unit, a communication unit, a storage unit, and a clock unit that may be components of the system.
[0025] In the following embodiment, a system including a terminal and a server (a client-server system) is illustrated as an example and not as a limitation. It should be noted that the server system described above in (2) can also be used as the server.
[0026] Also, instead of a system including a terminal and a server, a system not including a server, such as the above system (3) as an example and not a limitation, may be applied. In this case, the embodiment can be configured based on the above-mentioned blockchain technology. Specifically, by way of example and not limitation, data stored and managed in a server described in the following embodiment is stored on the blockchain. Then, the terminal generates a transaction to the blockchain, and when the transaction is approved on the blockchain, the data stored on the blockchain can be updated.
[0027] It should be noted that even when the term "terminal" is used, this is not limited to the meaning of a terminal as a client device in a client server. That is, a terminal may include the concept of a device other than that of a client-server.
[0028] Furthermore, in this specification, the expression "through a communication I / F" is used as appropriate. This is not intended to be limiting, but may indicate, by way of example, that a device transmits and receives various types of information and data through a communication I / F (through a communication unit) based on the control of a control unit (such as a processor).
[0029] In addition, in this specification, when the terms "related to" and "associated with" are used, "B related to A" or "B related to A" may mean, by way of example and not limitation, "B" having some kind of relationship with "A." Specific examples of this will be described later.
[0030] In addition, in this specification, when a device performs processing on two or more objects, such as "transmitting A and B" or "receiving A and B," this may include performing "A" and "B" in a synchronized manner (hereinafter referred to as "simultaneous"), and performing "A" and "B" with a different timing (hereinafter referred to as "non-simultaneous"). As an example and not a limitation, when referring to transmitting first information and second information, this may include both concepts of transmitting the first information and the second information in a synchronized manner and transmitting the first information and the second information with a lag in timing. In addition, taking into account the lag (time lag), "simultaneous" may include "almost simultaneous."
[0031] Note that, even if "A" and "B" are performed at different times, this only needs to be the processing targeting "A" and "B," and the purpose does not necessarily have to be the same. As an example and not a limitation, when the first information and the second information are transmitted as described above, it is sufficient to transmit the first information and the second information, and this may include cases where the first information and the second information are transmitted for the same purpose, as well as cases where the first information and the second information are transmitted for different purposes.
[0032] In the following embodiment, a messaging service is illustrated as an example of a service that allows users to chat (hereinafter, referred to as a "chat service"). An application for realizing the chat service is referred to as a "chat application," and an application for realizing the messaging service is referred to as a "messaging application." By way of example and not limitation, a chat application may enable users to chat in chat rooms.
[0033] Note that messaging services (MS) (including instant messaging services (IMS)) can be considered as one form of social networking services (SNS). Therefore, messaging services and social networking services may or may not be distinguished. In other words, social networking services may include messaging services.
[0034] In addition, in the following embodiments, as an example of a messaging service, an instant messaging service (IMS) that transmits and receives simple messages between multiple devices (terminals, for example and not limitation) via a server is exemplified. By way of example and not limitation, an instant messaging application may allow users to talk in talk rooms.
[0035] A chat room (for example, but not limited to, a talk room) can be a UI (User Interface) or GUI (Graphical User Interface) that allows each user to view content transmitted and received between the terminals of multiple users.
[0036] In addition, talk rooms can include one-to-one user talk rooms (hereinafter referred to as "one-to-one talk rooms"), talk rooms for groups including multiple users (hereinafter referred to as "group talk rooms"), and talk rooms with OA businesses (as an example, but not limited to, businesses that are affiliated with messaging service providers) (hereinafter referred to as "OA talk rooms").
[0037] In addition, an account of a messaging application that is an account of a business operator and not a general user may be referred to as an "Official Account (OA)", and a user of this official account may be referred to as an "Official User". This may also be referred to as an "Official Account User" or "Official Account Business Operator", etc. In contrast, an account of a messaging application that is a user who is not an OA business is called a "general account," and a user of a general account is called a "general user." This may also be called a "general account user," etc. In other words, messaging application accounts may include general accounts and official accounts.
[0038] A general account may be an example of a first type of account, and an official account may be an example of a second type of account. In addition, a general account may be an example of an account of a first type in a messaging service (messaging application) associated with a terminal 20 or a user of that terminal 20, and an official account may be an example of an account of a second type in a messaging service (messaging application) associated with a terminal 20 or a user of that terminal 20.
[0039] In addition, as a non-limiting example, OA operators may be able to use a terminal similar to that of a user with a general account to send and receive messages with other devices via the server.
[0040] Further, a message (message information) may be, by way of example and not limitation, information that defines a sender and a destination used in a messaging service, and may be information that is composed of identification information (message ID) for identifying the message and message content. Additionally, message content may refer to, by way of example and not limitation, the contents of a message excluding the message ID. Message content may be one or more pieces of content.
[0041] Moreover, information set as identification information for identifying a message is referred to as a "message ID." It can also be considered that message content included in a message with the same message ID is identified by this message ID. Therefore, it can also be considered that identification information for identifying a message is substantially synonymous with identification information for identifying message content. Alternatively, individual identification information (message content ID) may be set for each message content, but this is not essential.
[0042] The content may include, by way of example and not limitation, text content in text format, image content in image format (including at least one of still images and / or moving images), audio content in sound format (including voice), and the like. In addition, the content may include operation content such as buttons and icons for user operations, and link content such as URIs (including URLs).
[0043] The text may include, by way of example and not limitation, at least one of national characters, extended characters, machine-dependent characters, numbers, symbols, graphics, and symbols represented by character codes. Note that the text does not have to include at least one of the above characters, extended characters, machine-dependent characters, numbers, symbols, figures, and signs, and may include other text.
[0044] The image may include at least one of various types of image information, such as, for example and without limitation, an icon, a button, a stamp, an emoji, and a banner image.
[0045] Unlike the above definition, the superordinate concept of a message may be content, or content and message may be synonymous, or it is not necessary to define them in this way.
[0046] In the following description, it is assumed that the server 10 is operated and managed by a payment service provider or a messaging service provider. In the following description, the name of the payment application will be referred to as "Payment App" as appropriate.
[0047] As a form for realizing the payment service (payment application), any of the following forms may be applied, by way of example and not by way of limitation. (A) A form constituting a stand-alone payment application (B) A form in which a payment service function is provided as a part of a messaging application (C) A form constituting an application having a payment service function and a messaging service function (a composite application) (D) A messaging application that is a separate application from a payment application.
[0048] In forms (B) and (C), by way of example and not limitation, the payment service provider may be the same as the messaging service provider. In this case, one method is to have the user's account in the messaging application and the user's account in the payment application be a common account. Alternatively, the user's account in the messaging application and the user's account in the payment application may be automatically associated (linked).
[0049] In form (D), by way of example and not by way of limitation, the payment service provider may be a different entity from the messaging service provider. In the case of the (D) embodiment, a process for associating (linking) a user's account in the messaging application with a user's account in the payment application can be performed.
[0050] Alternatively, it is possible to provide a messaging service function as one of the functions of the payment application.
[0051] In the following description, the user of terminal 20A is referred to as "user AA", the user of terminal 20B as "user BB", the user of terminal 20C as "user CC", . . . .
[0052] <Example> An example of an embodiment to which the present invention is applied will be described below. For example, when multiple people gather for a meal or drinking party, they may share the cost. In such cases, the amount paid by each participant is often divided equally among themselves or set by an organizer or other such person, and few other methods of setting payment amounts have been proposed.
[0053] In addition, the concept of "splitting the bill" is not limited to, but may include, for example, dividing an amount equally among multiple users (equal division), as well as dividing an amount pro rata (apportionment) among multiple users ("equal division": dividing in the same proportions; "pro rata": dividing in different proportions).
[0054] <First Example> The first embodiment is a basic embodiment for determining the payment amount of users participating in split roulette in the method of the present invention. The contents described in the first embodiment are applicable to any of the other embodiments and other modified examples.
[0055] <System configuration> FIG. 1-1 is a diagram illustrating an example of a system configuration of a communication system 1 according to the present embodiment. In the communication system 1, as an example and not a limitation, a server 10 and a plurality of terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ) are connected via a network 30.
[0056] The server 10 provides a given service to a terminal 20 or a user of the terminal 20 via a network 30, for example and not by way of limitation. A user of the server 10 may be, for example and not limitation, a social networking service operator (for example and not limitation, a messaging service operator) or a payment service operator.
[0057] In addition, a payment service (payment application) provider that enables electronic settlement using electronic money (electronic currency) or the like may become a user of the server 10 and operate a messaging service or the like. Additionally, a payment service provider may or may not provide messaging services as a feature of the payment application.
[0058] The number of servers 10 and the number of terminals 20 connected to the network 30 are not limited.
[0059] The terminal 20 (terminal 20A, terminal 20B, terminal 20C, ...) may be any information processing terminal capable of implementing the functions described in each embodiment. The terminal 20 includes, but is not limited to, a smartphone, a mobile phone (feature phone), a computer (such as, but not limited to, a desktop, laptop, tablet, etc.), a media computer platform (such as, but not limited to, a cable or satellite set-top box, digital video recorder), a handheld computer device (such as, but not limited to, a PDA (personal digital assistant), email client, etc.), a wearable device (such as a glasses-type device, a watch-type device, etc.), a VR (Virtual Reality) terminal, a smart speaker (a device for voice recognition), or other types of computers or communication platforms. The terminal 20 may also be expressed as an information processing terminal.
[0060] The configurations of the terminals 20A, 20B, and 20C can be the same, for example and not for limitation. In addition, if necessary, the terminal used by the user XX may be expressed as the terminal 20X, and the user information in a predetermined service associated with the user XX or the terminal 20X may or may not be expressed as the user information X. The user information may be information of a user associated with an account used by the user in a specific service. The user information may include, but is not limited to, information associated with a user, such as the user's name, the user's icon image, the user's age, the user's sex, the user's address, the user's hobbies and interests, and the user's identifier, which are input by the user or given by a specific service, and may be any one of these, or a combination of these, or may not be the same.
[0061] The network 30 plays a role of connecting one or more terminals 20 and one or more servers 10. In other words, the network 30 refers to a communication network that provides a connection path so that the above-mentioned various devices can be connected and then transmit and receive data.
[0062] One or more portions of network 30 may or may not be wired or wireless networks. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular network, integrated service digital networks (ISDN), wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth, satellite communications, or the like, or a combination of two or more thereof. Network 30 may include one or more networks 30.
[0063] The server 10 (not limited to, an example of a server, information processing device, or information management device) has a function of providing a predetermined service (not limited to, a messaging service, for example) to the terminal 20. The server 10 may be any device as long as it is an information processing device capable of realizing the functions described in each embodiment. The server 10 includes, not limited to, a server device, a computer (not limited to, for example, a desktop, a laptop, a tablet, etc.), a media computer platform (not limited to, for example, a cable or satellite set-top box, a digital video recorder), a handheld computer device (not limited to, for example, a PDA, an email client, etc.), or other types of computers or communication platforms. The server 10 may also be expressed as an information processing device. When it is not necessary to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be expressed as information processing devices.
[0064] [Hardware (HW) configuration of each device] The hardware configuration of each device included in the communication system 1 will be described.
[0065] (1) Terminal hardware configuration FIG. 1-1 shows an example of the hardware configuration of the terminal 20. In FIG. The terminal 20 includes a control unit 21 (CPU: central processing unit), a storage unit 28, a communication I / F 22 (interface), an input / output unit 23, a clock unit 29A, and a position calculation information detection unit 29B. The HW components of the terminal 20 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW configuration of the terminal 20 includes all of the components. For example and not for limitation, the terminal 20 may or may not be configured such that individual components or multiple components are removable.
[0066] The communication I / F 22 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I / F 22 has a function of communicating with various devices such as the server 10 via the network 30. The communication I / F 22 transmits various data to various devices such as the server 10 according to instructions from the control unit 21. The communication I / F 22 also receives various data transmitted from various devices such as the server 10 and transmits it to the control unit 21. The communication I / F 22 may also be simply referred to as a communication unit. When the communication I / F 22 is configured with a physically structured circuit, it may also be referred to as a communication circuit.
[0067] The input / output unit 23 includes a device for inputting various operations to the terminal 20, a device for outputting the results of processing performed by the terminal 20, etc. The input / output unit 23 may be an integrated input unit and an output unit, or may be separate from the input unit and the output unit, or may not be.
[0068] The input unit is realized by any one or a combination of all kinds of devices that can receive input from a user and transmit information related to the input to the control unit 21. Examples of the input unit include, but are not limited to, a touch panel, a touch display, hardware keys such as a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input by voice).
[0069] The output unit is realized by any one or a combination of all kinds of devices capable of outputting the processing results processed by the control unit 21. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (audio output), a lens (for example, but not limited to, 3D (three dimensions) output and hologram output), a printer, etc.
[0070] By way of example only, the input / output unit 23 includes, by way of example and not limitation, a display unit 24, a sound input unit 25, a sound output unit 26, and an imaging unit 27.
[0071] The display unit 24 is realized by any one of all kinds of devices capable of displaying according to the display data written in the frame buffer, or a combination thereof. The display unit 24 includes, by way of example and not limitation, a touch panel, a touch display, a monitor (by way of example and not limitation, a liquid crystal display or an organic electroluminescence display (OLED)), a head mounted display (HDM), a projection mapping, a hologram, a device capable of displaying images, text information, and the like in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.
[0072] The sound input unit 25 is used to input sound data (including voice data; the same applies below). The sound input unit 25 includes a microphone and the like. The sound output unit 26 is used to output sound data and includes a speaker and the like. The imaging unit 27 is used to obtain image data (including still image data and moving image data; the same applies below.) The imaging unit 27 includes a camera and the like.
[0073] When the input / output unit 23 is a touch panel, the input / output unit 23 and the display unit 24 may be disposed facing each other and have approximately the same size and shape.
[0074] The clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information). The clock unit 29A is configured to include, for example and not limitation, a clock using a crystal oscillator. The clock unit 29A can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.
[0075] The clock unit 29A may or may not have a clock that conforms to the Network Identity and Time Zone (NITZ) standard or the like.
[0076] The position calculation information detection unit 29B is a functional unit that detects (measures) information (hereinafter referred to as "position calculation information") necessary for the control unit 21 to calculate (measure) the position of its own terminal 20. The position calculation information detection unit 29B can also be expressed as a position calculation sensor unit, for example and not by way of limitation.
[0077] The position calculation information detection unit 29B includes, by way of example and not limitation, a satellite positioning sensor (satellite positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System), an inertial measurement sensor (inertial measurement unit (IMU (Inertial Measurement Unit))) which is a sensor or unit for calculating the position of the terminal 20 using an inertial navigation system, a UWB positioning sensor (UWB positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using UWB (Ultra Wide Band), and the like.
[0078] The satellite positioning unit includes, by way of example and not limitation, an RF receiving circuit that converts RF (Radio Frequency) signals, including positioning satellite signals transmitted from positioning satellites and received by an antenna (not shown), into digital signals, and a baseband processing circuit that performs correlation calculation processing or the like on the digital signals output from the RF receiving circuit to capture the positioning satellite signals, and outputs information such as satellite orbit data and time data extracted from the positioning satellite signals as information for position calculation.
[0079] The inertial measurement unit has an inertial sensor that is a sensor that detects information required for calculating the position of the terminal 20 by inertial navigation calculation. The inertial sensor includes, but is not limited to, a three-axis acceleration sensor and a three-axis gyro sensor, and outputs the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as information for position calculation.
[0080] The UWB positioning unit includes, by way of example and not limitation, an ultra-wideband RF receiving circuit that converts an ultra-wideband RF (Radio Frequency) signal, including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon and received by an antenna not shown, into a digital signal, and a relative position calculation processing circuit that calculates the relative position between the terminal 20 and the positioning beacon based on the digital signal output from the ultra-wideband RF receiving circuit. As an example and not by way of limitation, the UWB positioning unit may or may not cause the terminal 20 to function as a positioning beacon by transmitting an ultra-wideband RF signal including an ultra-wideband pulse signal for positioning from an antenna not shown.
[0081] As an example and not a limitation, the control unit 21 calculates the position of its own terminal 20 at regular timing or specific timing based on the position calculation information detected by the position calculation information detection unit 29B. The terminal position is referred to as the "terminal position", and the calculated terminal position is referred to as the "calculated terminal position". The control unit 21 may, but may not, associate the calculated terminal position with the date and time when the calculated terminal position is calculated and store it in the storage unit 28 as calculated terminal position history data.
[0082] Incidentally, it is not essential to provide the position calculation information detector 29, and it is not necessary to provide this.
[0083] The control unit 21 has a circuit physically structured to execute the functions realized by the code or instructions contained in the program, and is realized by a data processing device built into hardware, for example and not by way of limitation. Therefore, the control unit 21 may or may not be expressed as a control circuit.
[0084] The control unit 21 includes, by way of example and not limitation, a central processing unit (CPU), a microprocessor, a processor core, a multiprocessor, an application-specific integrated circuit (ASIC), and a field programmable gate array (FPGA).
[0085] The storage unit 28 has a function of storing various programs and various data required for the operation of the terminal 20. The storage unit 28 includes, by way of example and not limitation, various storage media such as a hard disk drive (HDD), a solid state drive (SSD), a flash memory, a random access memory (RAM), and a read only memory (ROM). In addition, the storage unit 28 may or may not be expressed as a memory.
[0086] Terminal 20 stores program P in storage unit 28, and executes this program P, causing control unit 21 to execute processing as each unit included in control unit 21. In other words, program P stored in storage unit 28 causes terminal 20 to realize each function executed by control unit 21. Also, this program P may or may not be expressed as a program module.
[0087] (2) Server hardware configuration FIG. 1-1 shows an example of the HW configuration of the server 10. In FIG. The server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I / F 14 (interface), an input / output unit 12, and a clock unit 19. The components of the HW of the server 10 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW of the server 10 includes all the components as the configuration of the HW of the server 10. For example and not for limitation, the HW of the server 10 may or may not be configured such that individual components or multiple components are removable.
[0088] The control unit 11 has circuits physically structured to execute functions realized by codes or instructions contained in a program, and is realized, for example and not by way of limitation, by a data processing device embedded in hardware.
[0089] The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA, but is not limited to these in the present disclosure.
[0090] The storage unit 15 has a function of storing various programs and various data required for the operation of the server 10. The storage unit 15 is realized by various storage media such as an HDD, an SSD, and a flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Furthermore, the storage unit 15 may or may not be expressed as a memory.
[0091] The communication I / F 14 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I / F 14 has a function of communicating with various devices such as the terminal 20 via the network 30. The communication I / F 14 transmits various data to various devices such as the terminal 20 according to instructions from the control unit 11. The communication I / F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits it to the control unit 11. The communication I / F 14 may also be simply referred to as a communication unit. When the communication I / F 14 is configured with a physically structured circuit, it may also be referred to as a communication circuit.
[0092] The input / output unit 12 includes a device for inputting various operations to the server 10, a device for outputting the results of processing by the server 10, etc. The input / output unit 12 may be an integrated input unit and an output unit, or may be separate input unit and output unit, or may not be the same.
[0093] The input unit is realized by any one or a combination of all kinds of devices capable of receiving input from a user and transmitting information related to the input to the control unit 11. The input unit is typically realized by hardware keys such as a keyboard or a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via moving images), or a microphone (operation input by voice), as examples and without limitation.
[0094] The output unit is realized by any one or a combination of all kinds of devices capable of outputting the processing results processed by the control unit 11. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (sound output), a lens (for example, but not limited to, 3D (three dimensions) output and hologram output), a printer, etc.
[0095] By way of example only, the input / output unit 12 includes a display unit 13, by way of example and not by way of limitation.
[0096] The display unit 13 is realized by a display or the like. The display is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OLED)). The display may or may not be a head mounted display (HDM) or the like. These displays may or may not be capable of displaying display data in 3D. In the present disclosure, the display is not limited to these.
[0097] The clock unit 19 is a built-in clock of the server 10, and outputs time information (timekeeping information). The clock unit 19 is configured to include, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.
[0098] (3)Other The server 10 stores a program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processes of each unit included in the control unit 11. In other words, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11. This program P may or may not be expressed as a program module. The same applies to other devices.
[0099] In each embodiment of the present disclosure, the description will be given assuming that the CPU of the terminal 20 and / or the server 10 executes the program P to realize the present invention.
[0100] The control unit 21 of the terminal 20 and / or the control unit 11 of the server 10 may or may not realize each process by a CPU having a control circuit, but may also realize each process by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or a dedicated circuit. These circuits may or may not be realized by one or more integrated circuits, and the multiple processes shown in each embodiment may or may not be realized by one integrated circuit. Furthermore, an LSI may be called a VLSI, a super LSI, an ultra LSI, or the like, depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit.
[0101] In addition, the program P (as an example, but not limited to, a software program, a computer program, or a program module) of each embodiment of the present disclosure may or may not be provided in a state stored in a computer-readable storage medium. The storage medium can store the program P in a "non-transitory tangible medium." In addition, the program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the program P may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded in a storage medium.
[0102] The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application specific IC (ASIC)), a hard disk drive (HDD), a hybrid hard drive (HHD), an optical disk, an optical disk drive (ODD), a magneto-optical disk, a magneto-optical drive, a floppy diskette, a floppy disk drive (FDD), a magnetic tape, a solid state drive (SSD), a RAM drive, a secure digital card, or a drive, any other suitable storage medium, or a suitable combination of two or more of these. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where 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. In addition, the storage medium may or may not be referred to as a memory.
[0103] The server 10 and / or the terminal 20 can realize the functions of the multiple functional units shown in each embodiment by reading out the program P stored in a storage medium and executing the read out program P.
[0104] Furthermore, the program P of the present disclosure may or may not be provided to the server 10 and / or the terminal 20 via any transmission medium capable of transmitting a program (such as a communication network or broadcast waves). The server 10 and / or the terminal 20 executes the program P downloaded via the Internet or the like, for example and not for limitation, to realize the functions of the multiple functional units shown in each embodiment.
[0105] In addition, each embodiment of the present disclosure may also be realized in the form of a data signal in which the program P is embodied by electronic transmission. At least a part of the processing in the server 10 and / or the terminal 20 may or may not be realized by cloud computing configured with one or more computers. At least a part or all of the processing in the terminal 20 may or may not be performed by the server 10. In this case, at least a part or all of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be performed by the server 10. At least a part or all of the processing in the server 10 may or may not be performed by the terminal 20. In this case, at least a part or all of the processing of each functional unit of the control unit 11 of the server 10 may or may not be performed by the terminal 20.
[0106] Unless explicitly stated, the judgment configuration in the embodiments of the present disclosure is not essential, and a specified process may or may not be executed when the judgment condition is satisfied, or a specified process may or may not be executed when the judgment condition is not satisfied.
[0107] Note that the programs of the present disclosure are implemented using, by way of example and not limitation, scripting languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), and markup languages such as HTML Living Standard.
[0108] <Function configuration / Data configuration> (1) Server FIG. 1-2 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment. The control unit 11 of the server 10 includes, by way of example and not limitation, an application management processing unit 111 that performs application management processing in accordance with an application management processing program 151 .
[0109] FIG. 1-3 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment. The memory unit 15 stores, by way of example and not limitation, an application management processing program 151 that is read by the control unit 11 and executed as application management processing, account registration data 153, an account management database 155, and a split management database 157.
[0110] The account registration data 153 is registration data related to the terminal 20 that uses the application or the account of the user of the terminal 20, and an example of the data configuration is shown in FIG. 1-4. In the account registration data 153, for example and not by way of limitation, a user name, an application ID, and other registration information are stored in association with each other.
[0111] The user name is the name of the user of the terminal 20 who uses the application, and as a non-limiting example, the name registered by the user of the terminal 20 when using the application is stored.
[0112] The application ID is information used to identify an application account, or the account itself. This application ID is preferably a value unique to each account, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each account. The application ID is information associated with the terminal 20 or the user of the terminal 20, and is an example of information related to the terminal or information related to the user of the terminal.
[0113] Other registration information may include, by way of example and not limitation, various types of information such as identification information for identifying terminal 20, contact information such as the telephone number and email address of terminal 20, authentication information such as passwords (login password, authentication password, etc.) used for various authentications in applications, and an icon image of the general user registered in the messaging application (hereinafter referred to as a "general user icon image").
[0114] The identification information for identifying the terminal 20 may be, for example and not for limitation, a terminal ID (for example and not for limitation, an International Mobile Equipment Identity (IMEI)).
[0115] The application ID may be an example of identification information for identifying the user of the terminal 20, in which case the application ID may or may not be replaced by a "user ID." Furthermore, contact information may also be an example of identification information for identifying a user of the terminal 20.
[0116] Also, in the case of an application in which only one account can be registered per terminal 20, as a non-limiting example, "identification information for identifying terminal 20 = identification information for identifying the user of terminal 20 = application ID" may be used.
[0117] Also, by way of example and not limitation, it may or may not be possible to assign multiple terminal IDs to one application ID.
[0118] Also, instead of various IDs such as application IDs, a method of managing accounts using contact information such as telephone numbers may be applied. In this case, instead of storing ID information such as an application ID in the account registration data 153, contact information such as a telephone number may be stored in the account registration data 153.
[0119] The account management database 155 is a database that stores management data related to each account stored in the account registration data 153, and an example of the data configuration is shown in FIG. 1-5. The account management data is stored as data for each account.
[0120] In each account management data, for example and not by way of limitation, an application ID and an electronic money balance that is the electronic money balance of the account corresponding to that application ID are stored.
[0121] The split management database 157 is a database in which data for management related to splitting in this embodiment is stored, and an example of the data structure is shown in FIG. 1-6. In the split management database 157, split management data is stored as data for each user who is a master.
[0122] The split-dollar management database 157 may be referred to as a database for managing split-dollar requests.
[0123] In each of the split management data, for example and not by way of limitation, the master application ID, the total split amount, split member management data, split roulette settings, and burden setting data are stored.
[0124] The split total is the total amount of the bill to be split, and is stored by the control unit 11 of the server 10 based on information sent from the master terminal 20, for example and not by way of limitation.
[0125] The split-bill member management data is data for managing members who split bills, and by way of example and not limitation, stores an application ID, a user name corresponding to this application ID, a member type which is the type of split-bill member of the user with this user name, and the payment amount to be paid by the user with this user name.
[0126] Member types may include, by way of example and not limitation, "master" and "non-master." In the embodiment described below, the master is included in the splitting members as an example and not as a limitation. However, the present invention is not limited to this, and the master may not be included in the splitting members.
[0127] The payment amount is a buffer that stores the amount determined as the amount to be paid by this sharing member. By default, "-" may be stored in the payment amount.
[0128] The split roulette setting is a flag that is set to "ON" when split roulette is to be played, and is stored by the control unit 11 of the server 10 based on information transmitted from the master terminal 20, for example and not by way of limitation.
[0129] The burden amount setting data is, by way of example and not limitation, setting data for multiple burden amounts that are set when the split roulette setting is set to "ON", and, by way of example and not limitation, the payer number, the payer, and the burden amount are stored in association with each other.
[0130] The payer number is a number set by the server 10, and by way of example and not limitation, a serial number is set equal to the number of sharing members stored in the sharing member management data.
[0131] The payer is the person (shared member) who will pay this amount, and as a non-limiting example, "???" (unknown) may be stored by default.
[0132] The burden amount stores the burden amount set as the amount to be borne by this burdener.
[0133] Although details will be described later, the charge amount may be automatically set by the server 10 or the terminal 20A, or may be manually set by the master. In addition, the set burden amount may be said to be a candidate (candidate amount) of the burden amount to be borne by each sharing member, and may be called a "candidate burden amount" or the like.
[0134] In addition, when the sharing roulette setting is set to "OFF", the burden amount setting data may not be stored.
[0135] Also, for convenience, this figure shows a case where the split roulette setting is "ON", in which case the split members are the members who will participate in the split roulette (hereinafter referred to as "split roulette members" as appropriate). In the following description, it is assumed that the split members who participate in the split roulette are split roulette members.
[0136] In addition to the above, by way of example and not limitation, information such as the date and time when the master requested the splitting of the bill and the date and time when the splitting request information was sent to the terminal 20 of the splitting member may be stored.
[0137] (2) Terminal FIG. 1-7 is a diagram showing an example of functions realized by a control unit 21 of a terminal 20 in this embodiment. The control unit 21 includes, as a functional unit, an application processing unit 211 that performs application processing according to an application processing program 281, for example and not for limitation.
[0138] FIG. 1-8 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment. In the storage unit 28, for example and not for limitation, an application processing program 281 that is read by the control unit 21 and executed as application processing, and an application ID 283 of this terminal 20 or the user of this terminal 20 are stored.
[0139] <Examples to which the present invention can be applied> In the following embodiments, by way of example and not limitation, examples are given of display screens and processing assuming a case such as a drinking party where the master (organizer, etc.) pays the total split amount to the establishment, etc. on behalf of the other members using a payment application, and receives amounts transferred from the other members to receive each member's payment amount. In addition, the master may first pay the amount to the store etc. as an advance payment and then receive remittances from the other sharing members (pre-collection payment), or may first receive remittances from the other sharing members and then pay the amount to the store etc. (post-collection payment).
[0140] Although a drinking party is described as an example, the same method can be applied to the purchase of other products or services. As a non-limiting example, the method described below can also be applied to a case where the master makes an advance payment for some payment and collects money from users other than the master. In other words, the embodiments to which the present invention can be applied are not limited to the split-the-bill embodiment.
[0141] Also, unlike the above, a seller of goods or a provider of services (a store) may collect money from split members (multiple customers) using a payment application, etc. In this case, the "master" is the store user, and the master may be a user who does not bear the payment.
[0142] <Display screen> An example of a display screen in this embodiment will be described. The transition of the display screens described below is merely an example of the transition of the display screens for implementing the method of the present disclosure. In the transition of the display screens illustrated below, some of the display screens may be omitted, or other display screens may be added.
[0143] In addition, the terminology used on the display screen described below may differ from the terminology used in the processes described thereafter (some terminology may not be consistent), but this is merely for convenience and to provide an easy-to-understand explanation of the display screen from the user's perspective. The same applies to the other embodiments and modifications.
[0144] In the following, as an example and not a limitation, a case will be illustrated in which the terminal 20 is a smartphone equipped with a display unit 24 having a portrait display.
[0145] For example, but not by way of limitation, a smartphone has a touch panel that functions as an input unit and is disposed opposite the display, thereby forming a touch screen. When an element such as an icon, button, item, or input area is displayed on the display, and a part of the touch panel that faces the area where the element is displayed is operated by a user, a program associated with the element or a subroutine of the program is executed.
[0146] The transition of the display screens described below is merely an example of the transition of the display screens for realizing the method of the present disclosure. In the transition of the display screens illustrated below, the display of some of the display screens may be omitted, or other display screens may be added.
[0147] In addition, in one drawing or across multiple drawings, a flow of screen transition may be explained by showing a specific screen (a screen such as a notification screen, for example and not by way of limitation) displayed on a different terminal 20. In this case, by way of example and not by way of limitation, a specific screen may be displayed on a different terminal 20 based on at least one of the following (triggered by at least one of the following): Automatically displayed A notification (including a push notification, etc.; the same applies below) is sent to the terminal 20, and is displayed when the user performs an operation in response to the notification. No notification is sent to the terminal 20, but it is displayed when the user performs a specific operation on the application. A notification is sent to the terminal 20, and the message is displayed when the user performs a specific operation on the application that sent the notification.
[0148] 1-9 to 1-11 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this embodiment. Here, the user AA is the master, and the other split members are users BB and CC, making a total of three split members. In addition, although the split members are shown on the display screen, in this embodiment, the split members are split roulette members.
[0149] The left side of FIG. 1-9 shows an example of a main menu screen of a payment application displayed on the display unit 24 of the terminal 20A. This main menu screen has an electronic money balance display area at the top of the screen that displays information about the balance of user AA's electronic money account (hereinafter referred to as the "electronic money balance").In addition to user AA's electronic money balance (in this example, "7,500 yen"), a charge button for charging the electronic money account is also displayed. Below the electronic money balance display area is an area containing function icons corresponding to various functions of the payment application.
[0150] When the "Split" icon is tapped among these function icons, for example and not limitation, the display changes to the screen in the center. This screen is a split-dollar setting screen for configuring settings related to splitting, and the user information of the split-dollar members (in this example, the user icons and user names of the split-dollar members) is displayed at the top of the screen, with three users displayed: user AA, user BB, and user CC. In this example, user AA is set as the master based on the fact that he or she tapped the "Split" icon, and as a result, a crown mark indicating that he or she is the master is displayed in association with the icon image of user AA. Also, to the right of the list of split-dollar members' information, an add button for adding a split-dollar member is displayed.
[0151] The master may allow the user to select sharing members from among users associated with the master (accounts associated with the master's account). Here, the association of a user (account association) in a payment application may include, by way of example and not limitation, a history of sending or receiving money (receiving a remittance) in the past, etc. However, it is not limited thereto, and may also include being registered as a friend or a group in the payment application, as in a messaging application described below.
[0152] The master may also be able to add sharing members by selecting a group made up of a payment application or messaging application.
[0153] In addition, the master may search for users by manually inputting contact information such as a user name, a telephone number, an email address, and an application ID (which may be the same as the application ID stored in the server 10 or the terminal 20, or may be a different ID), and add the users as sharing members.
[0154] Below that is a total split display area R1, which displays the total amount entered by the user for splitting (hereinafter referred to as the "total split amount"); in this example, "12,000 yen" has been entered by user AA and is displayed. Below that are a first slide button for setting the amount each sharing member will be responsible for an equal share, and a second slide button for determining the amount each sharing member will be responsible for by roulette; in this example, the second slide button is shown to be in the "ON" position by user AA.
[0155] In this example, there are three sharing members, and with the second slide button set to "ON," the user information for the three payers (in this example, user icons and user names) is displayed at the bottom of the screen, and amount boxes MB1 to MB3, each containing the amount to be paid, are displayed in association with the user information for that person. In this embodiment, which sharing member will be assigned which burden amount is determined by drawing lots, but since the drawing has not yet been done at this point, each user's information is set to "?".
[0156] In this example, the amount boxes MB1 to MB3 show the amounts set as "6,000 yen," "4,000 yen," and "2,000 yen" from the top. More specifically, the amounts set for each of the three people are displayed so that the sum of the amounts shared is the total amount.
[0157] The right side of FIG. 1-9 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20B when the "OK" button BT1 at the bottom of the screen in the center of FIG. 1-9 is tapped. This screen is, by way of example and not by way of limitation, a notification screen for a payment application, and displays split request information RI1 indicating that a split request has been received from user AA. In this example, the split request information RI1 includes information indicating that a split request has been received from user AA, who is the master, and a "Check details" button for checking the details.
[0158] When the "Check details" button is tapped, the display will change to the screen shown on the left side of Figure 1-10, by way of example and not limitation. This screen is a split roulette screen of the payment application, and in this example, an image of a roulette wheel (roulette dial), the total amount to be split, and the amounts to be paid by each of the three people are displayed.
[0159] The roulette image may be divided into areas corresponding to the number of sharing members and displayed. In addition, the user icons displayed in association with the respective amounts to be paid on the screen in the center of FIG. 1-9 may be displayed in correspondence with the divided areas of the roulette. The colors of the user icons (background colors) may be displayed in correspondence with the areas.
[0160] When the “Spin Roulette” button BT3 at the bottom of the screen is tapped, the display changes to the screen shown in the center of Figure 1-10, as an example and not a limitation. This screen is a payment amount notification screen for the payment application, and based on the amount that user BB is required to pay being determined to be "2,000 yen", information is displayed indicating that user BB's payment amount is "2,000 yen". The timing of the lottery may vary, and details will be described later.
[0161] In addition, in this example, the payment amount notification screen displays a share icon SIC along with the text "Share results" for sharing one's payment amount information (the result of the split roulette) with other split members via a payment application or messaging application. When the share icon SIC is tapped, by way of example and not limitation, sharing request information is transmitted from the terminal 20 to the server 10. Then, by way of example and not limitation, the server 10 may transmit shared information including information on the payment amount of the user of the terminal 20 as shared information with the user of the terminal 20 as the sender to each of the terminals 20 of the splitting members (which may or may not include the terminal 20 of the splitting member who requested sharing).
[0162] When the “Transfer split amount” button BT5 at the bottom of the screen is tapped, the display changes to the screen shown on the right side of Figure 1-10, which is an example and not a limitation. This screen is a remittance screen for a payment application, and the top of the screen is configured with a remittance amount display area where the remittance amount is displayed. In this example, the payment amount of user BB, "2,000 yen", is automatically entered and displayed in the remittance amount display area. Below the remittance amount display area, user BB's electronic money balance ("15,000 yen" in this example) is displayed.
[0163] The user may be allowed to manually input the remittance amount in the remittance amount display area, or may be allowed to manually correct the remittance amount that has been automatically input in the remittance amount display area.
[0164] Below that, the user information of the remittance destination user is displayed; in this example, the user information of the master user AA is displayed. When the "OK" button BT1 at the bottom of the screen is tapped, the remittance amount displayed in the remittance amount display area is remitted in electronic money from user BB to user AA.
[0165] An example of a screen displayed on the display unit 24 of the terminal 20C is shown on the left side of FIG. 1-11. The same can be said about user CC as user BB, and the left side of Fig. 1-11 shows a screen similar to that in the center of Fig. 1-10. In this example, the amount to be paid by user CC has been determined to be "6,000 yen," and information indicating that the amount to be paid by user BB is "6,000 yen" is displayed. When the "Transfer split amount" button BT5 is tapped, the amount is transferred from user CC to user AA. The procedure and method for transferring money from user CC to user AA may be the same as those for user BB.
[0166] An example of a notice screen displayed on the display unit 24 of the terminal 20A is shown in the center of FIG. 1-11. This notification screen displays decision notification information DI1 indicating that the amount to be split between the three people (amount to be borne) has been decided. When the "Check details" button included in this screen is tapped, the display changes to the screen shown on the right side of Figure 1-11.
[0167] This screen is the same splitting setting screen as the one in the center of Figure 1-9, but based on the amount each splitting member is responsible for, the user information displayed at the bottom of the screen that was "?" on the splitting setting screen in the center of Figure 1-9 has changed to the user information of each payer (splitting member). Specifically, the amount box MB1 for the amount "6,000 yen" displays the user information of user CC in association with it, the amount box MB2 for the amount "4,000 yen" displays the user information of user AA in association with it, and the amount box MB3 for the amount "2,000 yen" displays the user information of user BB in association with it.
[0168] <Processing> 1-12 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. From the left, the diagram shows processing executed by the control unit 21 of the terminal 20A of the user AA, processing executed by the control unit 11 of the server 10, processing executed by the control unit 21 of the terminal 20B, and processing executed by the control unit 21 of the terminal 20C. Here, the case where the master has set the split roulette to "ON" will be illustrated. For ease of understanding, the split members and the master will be described as being the same as in the example display screen.
[0169] Note that this process is merely an example of a process for implementing the method of the present disclosure, and is not limited to this process. Another step may be added to this process, or some steps may be omitted (deleted) from this process. This also applies to each of the flowcharts (processes) described below.
[0170] Although not shown in the figures, first, the control unit 21 of the terminal 20A displays the splitting setting information (such as a splitting setting screen based on the splitting setting information) on the display unit 24, and based on the user's input to add a splitting member, transmits splitting member addition information including information such as the application ID of the user to be added to the server 10 via the communication I / F 22. Then, based on the received information, the control unit 11 of the server 10 generates splitting management data, stores the master application ID (in this example, the application ID of user AA), and generates splitting member management data. At this point, the payment amount may be "-". It should be noted that, based on the input of the total split amount, information on the total split amount may also be transmitted from the terminal 20A to the server 10 and stored in the split management data.
[0171] Next, the control unit 21 of the terminal 20A, based on an input to set the split roulette setting to "ON," for example and not limitation, transmits split roulette request information to the server 10 via the communication I / F 22 (A110).
[0172] When the communication I / F 14 receives the sharing roulette request information from the terminal 20A, the control unit 11 of the server 10 performs a burden setting process to set the burden amount (candidate burden amount) for the number of sharing members (hereinafter referred to as "number of sharing members") based on the sharing member management data (S110). However, in this embodiment, since the sharing members are also sharing roulette members, "number of sharing members = number of sharing roulette members". Specifically, by way of example and not limitation, the amount of each sharing member's share is set based on the total amount of the sharing and the number of sharing members. More specifically, the amount of each sharing member's share is set based on the total amount of the sharing and the ratio / proportion set according to the number of sharing members (by way of example and not limitation, if there are three sharing members, it is "3:2:1", if there are four sharing members, it is "3:2:2:1", etc., but is not limited to these).
[0173] Next, the control unit 11 of the server 10 transmits information on the multiple set amounts of charge to the terminal 20A via the communication I / F 14 (S110).
[0174] After A110, when information on the multiple set amounts to be charged is received via the communication I / F 22, the control unit 21 of the terminal 20A displays this information (such as a splitting setting screen based on this information) on the display unit 24 (A120), and based on the user's input of the decision, transmits the decision information to the server 10 via the communication I / F 22 (A130).
[0175] Note that, unlike this process, the control unit 21 of the terminal 20A may perform the burden setting process. In this case, the control unit 21 of the terminal 20A may, for example and not by way of limitation, transmit information on the multiple burden amounts set to the server 10 by including it in the split roulette request information or the determination information.
[0176] When the control unit 11 of the server 10 receives the determination information from the terminal 20A via the communication I / O 14, it performs a lottery process (S130). In this example, the amount to be paid by each of the three users, user AA, user BB, and user CC, who are all members of the sharing payment plan, is determined by lottery based on a plurality of amounts to be paid set. The determined amount to be paid is then stored as the payment amount in the sharing payment member management data.
[0177] In this process, the master may receive the user's share (payment amount) transferred from each of the other sharing members. In this case, if the number of sharing members is "N" (N≧3), the N-1 share of the N shares, excluding the master's share, will be the amount transferred from the other sharing members to the master.
[0178] Next, the control unit 11 of the server 10 transmits the split request information to each of the terminals 20B and 20C via the communication I / F 14 (S150). The split request information may include, by way of example and not limitation, at least one of the following information: - Information to notify you that a split request has been made - Information of the user who sent the split request Information on the total amount split -Information on multiple payment amounts Information on the contents of the "Warikan Roulette" (including images (including still images and moving images), sounds, etc.) Information about objects such as buttons (or information for displaying them) It is not necessary to include all of this information in the split request information, and some of the information may be omitted. Also, information on the page of the application that includes this information may be transmitted.
[0179] When the split charge request information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the received split charge request information (such as a split charge request screen based on the split charge request information) (B110). In this case, as shown in the example of the display screen, a split roulette screen including split roulette information may be displayed based on an input to the displayed split request information.
[0180] Next, based on the input to play the split roulette, the control unit 21 of the terminal 20B transmits split roulette play request information to the server 10 via the communication I / F 22 (B150).
[0181] When the control unit 11 of the server 10 receives split roulette execution request information from the terminal 20B via the communication I / F 14, the control unit 11 of the server 10 transmits payment amount notification information including information on the payment amount (amount borne) of the user BB to the terminal 20B via the communication I / F 14 based on the result of the lottery process (S130) (S170). In addition, in order to enable user BB to transfer money to user AA based on the payment amount notification information, information that will serve as a guide for the transfer (information for displaying an object such as a transfer button) may be included in the payment amount notification information and sent.
[0182] After B150, when payment amount notification information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the received payment amount notification information (such as a notification screen based on the payment amount notification information) (B190).
[0183] The same is true for the terminal 20C, where the control unit 21 of the terminal 20C performs the processes of C110 and C150, the control unit 11 of the server 10 performs the process of S180, and the control unit 21 of the terminal 20C performs the process of C190.
[0184] In this example, terminal 20B sends split-note roulette execution request information to server 10 before terminal 20C, and server 10 sends payment amount notification information to terminal 20B. However, if terminal 20C accepts user CC's input to execute split-note roulette before terminal 20B, terminal 20C will send split-note roulette execution request information to server 10 before terminal 20B, and server 10 will send payment amount notification information to terminal 20C.
[0185] In addition, when an input to play split roulette is made in each of terminals 20B and 20C, a predetermined effect (such as a display effect on display unit 24 or a sound output from sound output unit 26) may be performed. However, in this process, the control unit 11 of the server 10 performs a lottery process before S150, and the amount to be paid (amount to be borne) by each user has already been determined. Therefore, the presentation is merely a presentation that is based on a predetermined result.
[0186] Note that, as a non-limiting example, the control unit 11 of the server 10 may also transmit payment amount notification information to the terminal 20A. Then, the control unit 21 of the terminal 20A may cause the received payment amount notification information (such as a notification screen based on the payment amount notification information) to be displayed on the display unit 24. However, in this process, since the user AA is the party receiving the remittance, information leading to the remittance does not need to be included in the payment amount notification information.
[0187] After S180, the control unit 11 of the server 10 transmits decision notification information to the terminal 20A via the communication I / F 14 (S190). When the decision notification information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the received decision notification information (such as a notification screen based on the decision notification information) (A190).
[0188] Although not shown in the figure, when an input to remit the payment amount is made at terminal 20B, remittance request information is sent to server 10, and server 10 performs remittance processing (remittance processing each time), and the payment amount is remitted from user BB to user AA. The remittance may be made by electronic money, for example and not by way of limitation, and the amount of the payment amount for user BB may be subtracted from the electronic money balance of user BB (the remitter), and the amount of the payment amount may be added to the electronic money balance of user AA (the recipient). The same may be done for terminal 20C (user CC).
[0189] Instead of performing remittance each time, remittance may be performed in a lump sum. Specifically, as a non-limiting example, even if the control unit 11 of the server 10 receives remittance request information from the terminal 20 of one of the split members, the control unit 11 may not perform remittance processing (each-time remittance processing) at that timing, but may perform remittance processing (lump remittance processing) based on receiving remittance request information from the terminals 20 of all the split members.
[0190] Furthermore, in this process, each of the multiple set burden amounts (not limited to, but an example of each of the multiple set amounts to be remitted to the first user) is determined by the total split amount entered by the master (not limited to, but an example of the first user). The amount obtained by subtracting the master's share from the total split amount is the total amount of remittance requests made by the master to the other split members (hereinafter referred to as the "total remittance request amount"). Therefore, it can be considered that the N-1 share amounts excluding the master's share are determined based on the total remittance request amount entered by the master. These share amounts are not limiting and may be examples of amounts to be sent to multiple first users. In addition, the total amount of the remittance request may be defined as the total of the split amounts of the split members excluding the master, or the total amount of the remittance request may be defined as the total of the split amounts of the split members including the master.
[0191] Furthermore, determining the multiple set amounts to be paid may be essentially the same as determining the amount to be remitted to the master (not limited to this, but an example of the first user).
[0192] In addition, the split request information may be considered as a type of remittance request information requesting the user to remit money, and the payment amount notification information may be considered as a type of remittance request information requesting the user to remit money.
[0193] Also, instead of having the sharing members other than the master transfer money to the master's electronic money account, the sharing members may transfer money to an account at a financial institution (such as a bank account) held by the master.
[0194] The total split amount may be set by the server 10. As a non-limiting example, when a product or service is purchased by any of the split members, the amount information may be received and obtained from the store's server, the store's code reader device, or the like. It may also be received and obtained from the terminal 20 that purchased the product or service.
[0195] Also, as a non-limiting example, if the user is allowed to manually input and set the total split amount and the amount to be borne, when an input such as a tap is made on the display unit 24 of the terminal 20, the control unit 21 of the terminal 20 may cause a numeric keypad or the like to be displayed on the display unit 24, and may accept input using the displayed numeric keypad or the like.
[0196] Also, as a non-limiting example, in S190, the control unit 11 of the server 10 may transmit the decision notification information not only to the terminal 20A, but also to each of the terminals 20B and 20C. Then, the control unit 21 of the terminal 20B may cause the display unit 24 to display the received decision notification information, and the control unit 21 of the terminal 20C may cause the display unit 24 to display the received decision notification information. Also, the user AA (master) may be able to share the result notification information with other sharing members by operating a share icon SIC, for example.
[0197] Also, as a non-limiting example, the control unit 11 of the server 10 may transmit, instead of or in addition to the determination notification information, master payment amount notification information notifying the payment amount of the user AA (master) to each of the terminals 20B and 20. It may also be transmitted to the terminal 20A.
[0198] Additionally, setting a burden amount (which is an example, but not limited to, of an amount to be remitted to the first user) may include, by way of example and not limitation, setting an equal amount of an equal payment. In addition, setting the burden amount (which is not limited to, and is an example of, the amount to be transferred to the first user) may include, by way of example and not limitation, that after the burden amount is set, the burden amount is changed to an equal amount, as will be described in more detail below.
[0199] <Effects of the First Embodiment> In this embodiment, the server 10, which communicates with the terminal 20 (not limited to, but an example of the first terminal) of the master (not limited to, but an example of the first user), transmits payment amount notification information (not limited to, but an example of information of a remittance request) from the master terminal 20 to at least the terminal 20 (not limited to, but an example of the second terminal) of the first split member (not limited to, but an example of the second user) and the terminal 20 (not limited to, but an example of the third terminal) of the second split member (not limited to, but an example of the third user) via the communication I / F 14. Then, based on the input of the first split member in response to the transmitted payment amount notification information, the server 10 transmits information (not limited to, but an example of the first amount) of the first split member's burden amount (not limited to, but an example of the first amount) among the multiple burden amounts (not limited to, but an example of the multiple amounts to be remitted to the master) to the terminal 20 of the first split member via the communication I / F 14. This allows information on a remittance request from the first terminal to be sent to at least the second terminal of the second user and the third terminal of the third user, and then information on a first amount, among a plurality of amounts set to be remitted to the first user, is sent to the second terminal based on an input by the second user in response to the information on the remittance request. As a result, by way of example and not limitation, the information on the first amount is output on the second terminal, so that the first amount can be notified to the second user. Also, by way of example and not limitation, as described above, the application of a game such as roulette can increase the interest of splitting the bill, etc.
[0200] Furthermore, according to this embodiment, information on a second amount among a plurality of amounts to be remitted to the first user can be transmitted to the third terminal based on an input by the third user of the third terminal in response to information on a remittance request from the first terminal. As a result, by way of example and not limitation, the information on the second amount is output by the third terminal, so that the third user can be informed of the second amount.
[0201] Furthermore, according to this embodiment, each of the amounts to be remitted to multiple set masters (not limiting, but an example of each of the amounts to be remitted to multiple set first users) can be easily determined based on the total split amount (not limiting, but an example of the total remittance request amount) entered by the master (not limiting, but an example of the first user).
[0202] <First Modification Example (1)> In the above embodiment, the master does not remit, but the present invention is not limited to this. As a non-limiting example, a payment account (such as an electronic money account) for the group of split members may be configured in the memory unit 15 of the server 10, and each split member, including the master, may transfer money to this payment account. The total amount of the split may then be paid from this payment account. The payment account may or may not be a common account that can be used by each of the splitting members.
[0203] <First Modification (2)> In the above embodiment, the master does not play split roulette, but the present invention is not limited to this. Similarly to users BB and CC in the above embodiment, the master (user AA in the above embodiment) may also be able to play split roulette. In this case, by way of example and not by way of limitation, in the processing of Fig. 1-12 and Fig. 1-13 described later, the control unit 11 of the server 10 may also transmit split-dollar request information to the terminal 20A in step S150. In this case, split-dollar roulette information may be transmitted to the terminal 20A instead of the split-dollar request information.
[0204] <First Modification (3)> In the above embodiment, the server 10 may perform the lottery process at the timing when it receives the split-the-dollar roulette play request information from the terminal 20 of each split-the-dollar member.
[0205] Fig. 1-13 is a flow chart showing an example of the flow of processing executed by each device in this modified example. The view of the figure is the same as that of Fig. 1-12. In this process, the control unit 11 of the server 10 does not perform the lottery process after S110.
[0206] After S150, when receiving split roulette execution request information from the terminal 20B via the communication I / F 14, the control unit 11 of the server 10 performs a lottery process (first time) (S130a). Then, based on the result, the control unit 11 of the server 10 transmits payment amount notification information including information on the payment amount of the user BB to the terminal 20B via the communication I / F 14 (S170).
[0207] Thereafter, when receiving split roulette execution request information from the terminal 20C via the communication I / F 14, the control unit 11 of the server 10 performs the lottery process (second time) (S130b). Then, based on the result, the control unit 11 of the server 10 transmits payment amount notification information including information on the payment amount of the user CC to the terminal 20C via the communication I / F 14 (S180).
[0208] <First Modification (4)> In the above embodiment, the multiple set amounts of payment are determined by the total split amount entered by the master. In other words, each of the multiple set amounts of remittance to the master is determined by the total remittance request amount entered by the master. The process of determining this amount may be performed by the control unit 11 of the server 10, or may be performed by the control unit 21 of the master terminal 20.
[0209] The above may also include any of the following: (A) The total of the burden amounts will be the same as the total split amount (the total amount to be transferred to the master will be exactly the same as the total split amount minus the master's burden amount) (B) The total of the contributions will be different from the total split amount (the total amount to be remitted to the master will be different from the total split amount minus the master's contributions).
[0210] (B) may include any of the following: (B1) The total of the burden amounts is less than the total split amount by the first set amount (the total amount to be remitted to the master is less than the total split amount minus the master's burden amount by the first set amount) (B2) The total of the burden amounts is more than the total split amount by the second set amount (the total amount to be remitted to the master is more than the total split amount minus the master's burden amount by the second set amount) The first set amount and the second set amount may be set to the same amount or may be set to different amounts.
[0211] In addition, the multiple charges set may be manually set and changed by inputting the charges using the master. In addition, the multiple set amounts of burden may be set randomly based on the total amount of the split payment, for example and not for limitation. In other words, each of the multiple set amounts of remittance to the master may be set randomly based on the total amount of the remittance request input by the master. As an example and not for limitation, the amounts of burden may be set randomly so that the sum of the amounts is the total amount of the split payment. This setting process may be performed by the control unit 11 of the server 10, or may be performed by the control unit 21 of the master terminal 20.
[0212] 1-14 and 1-15 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this modified example. The left and center of Figure 1-14 are similar to the left and center of Figure 1-9, respectively, but in the center screen, the amount boxes MB1 to MB3 corresponding to each burden amount are provided with amount increase / decrease buttons (amount increase button, amount decrease button) for the user to increase / decrease the burden amount in addition to the burden amount. In other words, it is configured so that the master can manually allocate the burden amount.
[0213] Alternatively, the user may be able to manually enter an amount in the amount box. Furthermore, if a user enters an inappropriate amount (an extreme amount), by way of example and not limitation, error information may be displayed on display unit 24, and the entered amount may not be accepted or may not be able to be entered. By way of example and not limitation, this processing may be performed when an amount that is not within X% (a set percentage) of the equal amount is entered, or when an amount equal to or greater than the total split amount is entered. Also, by way of example and not limitation, this processing may be performed when "0 yen" or a single digit amount is entered. Furthermore, if the user enters an inappropriate amount, a dialog box or the like displaying the acceptable upper and lower limit amounts may be displayed on the display unit 24. The upper limit amount may be the same as the total split amount, or an amount smaller than the total split amount. The lower limit amount may be "0 yen" or an amount larger than "0 yen." Furthermore, the upper limit amount and the lower limit amount may be an amount that is X% (a set percentage) higher or lower than the equal amount.
[0214] This also relates to the second embodiment, but by doing so, it is possible to prevent an inappropriate amount from being set as the burden amount, and it is possible to prevent bullying from occurring.
[0215] As mentioned above, the allocation may be made so that the total of the burden amounts is the same as the total divided amount, but this is not limited to this, and the allocation may be made so that the total of the burden amounts is an amount different from the total divided amount.
[0216] In this example, a "RANDOM" slide button for randomly setting the amount to be borne is provided below the "Decide by Roulette" slide button. This "RANDOM" slide button may be configured, by way of example and not limitation, to be set to "ON" when "Decide by Roulette" is set to "ON", and by being set to "ON", the amount to be borne is set randomly based on the total amount to be split, by way of example and not limitation.
[0217] As a non-limiting example, assume that user AA taps the amount increase / decrease button in amount box MB3, and the amount to be paid is changed from top to bottom to "5,000 yen," "4,500 yen," and "2,500 yen," as shown on the right side of Figure 1-14.
[0218] The left side of Figure 1-15 shows an example of a notification screen displayed on the display unit 24 of terminal 20B based on tapping the "Decision" button BT1 on the screen on the right side of Figure 1-14 of terminal 20A, and this screen corresponds to the screen shown on the right side of Figure 1-9. When the "Check details" button included in the split request information RI1 is tapped, the display on the center screen changes. This screen corresponds to the screen shown on the left side of Figure 1-10, but in this example, the amounts to be paid at the bottom of the screen are "5,000 yen," "4,500 yen," and "2,500 yen," from top to bottom.
[0219] When the “Spin Roulette” button BT3 at the bottom of the screen is tapped, the display changes to the screen shown on the right side of Figure 1-15, as an example and not a limitation. In this example, the amount to be paid by user BB has been determined to be "5,000 yen," and information indicating that the amount to be paid by user BB is "5,000 yen" is displayed.
[0220] According to this modified example, each of the multiple set amounts to be charged (not limited to, but an example of each of the multiple set amounts to be remitted to the first user of the first terminal) can be determined by input by the master (not limited to, but an example of the first user).
[0221] Furthermore, according to this modified example, each of the multiple set burden amounts (not limiting, but an example of each of the multiple set amounts to be remitted to the first user of the first terminal) can be set randomly based on the total split amount (not limiting, but an example of the total remittance request amount) entered by the master (not limiting, but an example of the first user).
[0222] <First Modification (5)> The control unit 11 of the server 10 may not transmit the payment amount notification information to the terminal 20 of a sharing member when it receives the request information to play the split roulette from that terminal 20, but may transmit the corresponding payment amount notification information to the terminal 20 of each sharing member when it receives the request information to play the split roulette from the terminals 20 of all sharing members (which may or may not include the master), as an example and not a limitation.
[0223] In addition, the control unit 11 of the server 10 may share the shared information not when it receives sharing request information from the terminal 20 of a splitting member, but when it receives split roulette execution request information from the terminal 20 of all splitting members (which may or may not include the master).
[0224] <Second Example> The second embodiment is an embodiment in which a user performs settings relating to participation in the split-the-dollar roulette in advance. The contents described in the second embodiment are applicable to any of the other embodiments and other modified examples.
[0225] Since there is a possibility of winning a large amount in split roulette, some users may not want to participate in split roulette or may wish to pay equal amounts from the start. Also, forcing users to participate in split roulette could lead to bullying.
[0226] <Data structure> FIG. 2-1 is a diagram showing an example of a data configuration of account management data in this embodiment. In this account management data, in addition to the application ID and the electronic money balance, by way of example and not limitation, a split roulette participation setting is stored.
[0227] The split roulette participation setting is a setting regarding the participation of the user (account) of this application ID in the split roulette, and may be stored as "Participate" if the user wishes to participate in the split roulette, "Do not participate" if the user does not wish to participate in the split roulette, or "Equal amount" if the user wishes to participate in the split roulette at an "equal amount."
[0228] FIG. 2-2 is a diagram showing an example of the data configuration of the division management data in this embodiment. In this split payment management data, the master application ID, the total split payment amount, split payment member management data, split payment roulette settings, split payment roulette member management data, and payment amount setting data are stored.
[0229] In this embodiment, the split member management data may store, by way of example and not by way of limitation, information about users who participate in the split roulette regardless of the split roulette participation setting. Also, in this embodiment, the split roulette member management data may store, by way of example and not by way of limitation, information about split members whose split roulette participation setting is "participate" or "equal amount". That is, a user who sets "Equal Amount" may be added to the split members and the split roulette members, by way of example and not by way of limitation. Also, a user who sets "Non-Participant" may be added to the split members but not to the split roulette members, by way of example and not by way of limitation. By doing this, users who have set "equal amount" in advance can appear as if they are participating in split roulette.
[0230] In this example, in the split management data, the split member management data and the split roulette member management data are separate data, but they may be managed as one data.
[0231] <Display screen example> 2-3 to 2-5 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this embodiment. The left side of Figure 2-3 shows the main menu screen of the payment application displayed on the display unit 24 of the terminal 20B, in which the "Settings" icon among the function icons is shown as being tapped. Then, by way of example and not limitation, the display changes to the screen shown in the center of Figure 2-3.
[0232] This screen is the settings screen for the payment application, and displays various setting items. These setting items include an item for "Participate in the split roulette" for setting up participation in the split roulette, and when this item is tapped, the display changes to the screen shown on the right side of Figure 2-3.
[0233] This screen is the split-dollar roulette participation setting screen, which allows you to make settings regarding participation in the split-dollar roulette. It displays three options: "Participate in roulette" to set yourself to participate in the split-dollar roulette, "Do not participate in roulette" to set yourself not to participate in the split-dollar roulette, and "Participate in roulette with equal amounts" to set yourself to participate in the split-dollar roulette with equal amounts associated with each option.
[0234] Here, it is said that "participate in roulette with equal amounts" because, as an example and not a limitation, even if a user sets "equal amounts" in advance, the user is still included as a split roulette member.
[0235] In this example, the radio button associated with the item "Play roulette with equal odds" is turned "ON" by user BB, and the "OK" button BT10 at the bottom of the screen is tapped.
[0236] FIG. 2-4 shows an example of a screen displayed on the display unit 24 of the terminal 20A in this case. As shown on the left side of Figure 2-4, when the "Split" icon is tapped on the main menu screen of the payment application, the display changes to the screen shown on the right side of Figure 2-4, by way of example and not limitation. This screen corresponds to the splitting setting screen in the center of Figure 1-9, but because user BB has set "Participate in roulette with an equal amount," user BB is included among the payers, and the amount box MB2 for the payment amount associated with user BB displays the equal amount of "4,000 yen" (total amount split ÷ number of splitting members = 12,000 yen ÷ 3) as user BB's payment.
[0237] The left side of FIG. 2-5 shows an example of a notification screen that is displayed on the display unit 24 of the terminal 20B when the "OK" button BT1 is tapped on the screen on the right side of FIG. 2-4. When the "Check details" button included in the split request information RI1 is tapped on this screen, the display changes to the screen shown in the center of Figure 2-5, which is an example and not a limitation.
[0238] This screen corresponds to the split roulette screen shown on the left side of Figure 1-10, but unlike the screen on the left side of Figure 1-10, the user icon of user BB is displayed in association with the equal amount of the payment amount, "4,000 yen", based on the equal amount that user BB set. Also, the area of the roulette image that corresponds to user BB is colored a specified color, and user BB's user icon is displayed superimposed. And, a mark of the same color as the area of the roulette image that corresponds to user BB is displayed superimposed on the upper left of user BB's user icon displayed in association with the payment amount of "4,000 yen". Also, unlike the screen on the left side of Figure 1-10, at the bottom of the screen, instead of the "Spin Roulette" button BT3, a "Pay Equal Amount" button BT11 for making an equal payment (transfer) is displayed.
[0239] When the "Pay Equal Amounts" button BT11 is tapped, the display changes to the screen shown on the right side of Figure 2-5, by way of example and not limitation. On this screen, information indicating that the amount to be paid by user BB is "4,000 yen" is displayed based on the fact that the amount to be paid by user BB is "4,000 yen."
[0240] <Processing> Fig. 2-6 shows an example of a process related to participation settings for split roulette in this embodiment, with the left side showing a process executed by the control unit 21 of the terminal 20 and the right side showing a process executed by the control unit 11 of the server 10. This process may be executed before the processes of Fig. 1-12, Fig. 1-13, etc. are started, as an example and not a limitation. The terminals 20 in this process may or may not include the master terminal 20.
[0241] The control unit 21 of the terminal 20 displays the split cash roulette participation setting information on the display unit 24 (B210), and based on the setting input regarding participation in the split cash roulette based on the split cash roulette participation setting information displayed on the display unit 24, transmits the split cash roulette participation setting information including the selected type of participation in the split cash roulette (hereinafter referred to as the "split cash roulette participation type") to the server 10 via the communication I / F 22 (B230). As a non-limiting example, when a setting input of “not participating” is made, roulette participation setting information including the type “not participating” is sent to the server 10, and when a setting input of “equal amount” is accepted, roulette participation setting information including the type “equal amount” is sent to the server 10. Then, the control unit 21 of the terminal 20 ends the process.
[0242] When the control unit 11 of the server 10 receives split pay roulette participation setting information from the terminal 20 via the communication I / F 14, the control unit 11 stores the type included in the received split pay roulette participation setting information in the split pay roulette participation setting of the account management data of the user of that terminal 20 (S210). Then, the control unit 11 of the server 10 ends the process.
[0243] In this embodiment, as an example and not a limitation, in the processing of Figures 1-12 and 1-13, when splitting member addition information is received from terminal 20A (master terminal 20), the control unit 11 of the server 10 refers to the account management data, and includes users whose splitting roulette participation setting is "not participating" in the splitting member management data, but may not include them in the splitting roulette member management data.
[0244] When the master selects "divide equally," the control unit 11 of the server 10 can calculate the equal amount based on the sharing members included in the sharing member management data as "equal amount = total amount shared / number of sharing members," and send payment amount notification information to the terminal 20 of each sharing member (which may or may not include the master).
[0245] If there is a user whose split roulette participation setting is "non-participating" among the split members, the control unit 11 of the server 10 calculates the equal amount as "equal amount = total split amount / number of split members" in S110 of the process in Figs. 1-12 and 1-13, by way of example and not limitation, and updates the total split amount entered by the master to "total split amount - equal amount x number of users whose split roulette participation setting is "non-participating". Then, the amount to be paid may be set based on the total split amount updated in this way and the split roulette members. In this case, if there is a split roulette member whose split roulette participation setting is "equal amount", the amount to be paid for that split roulette member may be set to an equal amount. Then, the control unit 11 of the server 10 may transmit information on the set charge amount via the communication I / F 14 to the terminal 20A.
[0246] When an input is made to pay an equal amount based on the splitting request information (B110, C110) displayed on the display unit 24 at the terminal 20 of a splitting roulette member whose participation setting for the splitting roulette is "equal amount," the control unit 21 of that terminal 20 transmits the equal amount payment request information to the server 10 via the communication I / F 22 (B150, C150). Then, the control unit 11 of the server 10 transmits payment amount notification information including information about the equal amount to the terminals 20 of the split roulette members whose participation setting for the split roulette is "equal amount" (S170, S180).
[0247] Unlike the above, if there is a user whose split roulette participation setting is "not participating" among the split members, the control unit 11 of the server 10 transmits information to that effect to the terminal 20A (the master terminal 20). Then, when the master inputs to select "decide by roulette", the control unit 21 of the terminal 20A may display error information, etc., so that the master cannot select "decide by roulette". In other words, if there is a user whose split roulette participation setting is "not participating" among the split members added by the master, the master may be prevented from selecting "decide by roulette". In this case, the control unit 21 may be controlled so that the setting is forcibly set to "divide equally".
[0248] Also, if the master has set up the split roulette in advance, or if the master adds split members after turning on "Decide by roulette" on the split setting screen, when a user whose split roulette participation setting is "not participating" is selected, the control unit 21 of the terminal 20A may display error information, or the like, so that the user cannot be added to the split members. In other words, it may be so arranged that users whose split roulette participation setting is "not participating" cannot be included in the split members for which the master has turned on the split roulette. In this case, users whose split roulette participation setting is "not participating" may not be displayed in the list of users to be added, or may be displayed but in a special manner so that they cannot be selected.
[0249] <Effects of the second embodiment> According to this embodiment, when a first splitting member (not limited to, but an example of a second user of a second terminal) makes settings regarding participation in the splitting roulette (not limited to, but an example of a first setting), information on the set equal amount or other amount (not limited to, but an example of a set third amount) can be sent to the terminal of the first splitting member instead of the first amount described above.
[0250] In this case, if the first splitting member has set up to participate in the splitting roulette with an equal amount (not limited to this, but an example of a setting related to transferring an equal amount based on the total amount of the remittance request), information on the set equal amount can be sent to the first splitting member's terminal instead of the first amount.
[0251] <Third Example> The third embodiment is an embodiment in which a plurality of amounts to be paid are set based on the settings made by each of the split members (split roulette members) regarding their participation in the split roulette. The contents described in the third embodiment are applicable to any of the other embodiments and other modified examples.
[0252] If the function for setting participation in the split-dollar roulette described in the second embodiment is not provided, the user cannot set up participation in the split-dollar roulette in advance. In this case, the user may decide to participate in the split-dollar roulette, but may wish to pay an "equal amount," for example and not by way of limitation. In addition, there may be cases where a user has previously set up their participation in the split roulette, but when the time comes to actually play the split roulette, they wish to make a different choice.
[0253] In this embodiment, one method is to prevent the amount of payment from being set until the users who will participate in the split-payment roulette among the split-payment members are determined.
[0254] FIG. 3-1 is a diagram showing an example of the data configuration of the division management data in this embodiment. In this split-dollar management data, in the split-dollar member management data, in addition to the application ID, the user name, the member type, and the payment amount, by way of example and not limitation, split-dollar roulette participation settings are stored.
[0255] In the present embodiment, the participation setting for the split roulette may be set to "Participate" as a default, for example and not as a limitation. For the split members who select the "equal amount" payment, the participation setting for the split roulette may be updated from "Participate" to "equal amount."
[0256] In the following, for the sake of convenience, a user who has become a member who plays split-the-dollar roulette will be described as a split-the-dollar member, regardless of whether or not he or she selects to pay "equal amounts."
[0257] <Display screen> 3-2 to 3-3 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this embodiment. Here, the case where user AA is the master, and the other sharing members are user BB, user CC, and user DD, totaling four sharing members, is illustrated.
[0258] The left side of FIG. 3-2 shows a split payment setting screen displayed on the display unit 24 of the terminal 20A. In this example, a state in which "10,000 yen" has been entered as the total split payment amount is shown. Below the total split amount display area are a "Divide equally" slide button for dividing the burden equally, a "Determine by roulette" slide button for deciding the burden by split roulette, and a "Random" slide button for deciding the burden randomly; in this example, the "Determine by roulette" slide button is shown in the "ON" state.
[0259] In this example, since there are four people in the sharing group, the four payers are displayed with a "?". In this example, the amount box for the four payers shows "? yen," indicating that the amount to be paid is undetermined.
[0260] The center of FIG. 3-2 shows an example of a split roulette screen that is displayed on the display unit 24 of the terminal 20B when the "OK" button is tapped on the screen on the left side of FIG. 3-2. This screen displays the roulette dial and the total split amount (in this example, "10,000 yen"), and at the bottom of the screen are an equal amount payment button BT21 (in this example, a button "Pay 2,500 yen without participating in roulette") for paying an equal amount without participating in the split roulette, and a roulette participation button BT22 (in this example, a button "Participate in roulette") for participating in the split roulette. This example shows a state in which user BB has tapped the roulette participation button BT22 to participate in the split roulette.
[0261] Here, the equal amount payment button BT21 is set to "Pay *** yen without participating in roulette" because, as an example and not a limitation, it has the implication that the user of the terminal 20 is a split-payment member (is included in the split-payment members), but will not participate in the split-payment roulette.
[0262] Note that instead of the equal amount payment button, a roulette non-execution button (for example, but not limited to, a "do not spin roulette" button) may be displayed to perform the same process.
[0263] The right side of FIG. 3-2 shows an example of a split roulette screen that is displayed on the display unit 24 of the terminal 20C when the "OK" button is tapped on the screen on the left side of FIG. 3-2. The screen configuration is the same as the screen in the center of Figure 3-2. In this example, user CC is shown tapping the equal amount payment button BT21 (in this example, the button for "Pay 2,500 yen without participating in roulette") to make an equal payment without participating in the split roulette.
[0264] The left side of FIG. 3-3 shows an example of a split roulette screen that is displayed on the display unit 24 of the terminal 20D when the "OK" button is tapped on the screen on the left side of FIG. 3-2. The screen configuration is the same as the screen in the center of Figure 3-2. In this example, user DD is shown tapping the equal amount payment button BT21 (in this example, the button for "Pay 2,500 yen without participating in roulette") to make an equal payment without participating in the split roulette.
[0265] An example of a splitting setting screen that is subsequently displayed on the display unit 24 of the terminal 20A is shown in the center of FIG. 3-3. In this screen, based on the settings made by users BB, CC and DD on their own terminals 20 as to whether they would like to participate in the split roulette or pay an equal amount, the amount boxes for users CC and DD that showed "? yen" on the screen on the left side of Figure 3-2 now show the equal amount of "2,500 yen" as the amount to be paid. In this case, the remaining amount (=total amount split - 2,500 yen x 2 people = 5,000 yen) will be determined by lottery between users AA and BB who are participating in the split roulette. In this example, the display of "Total split amount" has changed to "Total remaining split amount," and "5,000 yen" is displayed as the remaining total split amount. Also, in this example, the amount boxes for the burden amounts of the two payers "?" are set to "4,000 yen" and "1,000 yen," respectively.
[0266] The right side of FIG. 3-3 shows an example of a split roulette screen that is displayed on the display unit 24 of the terminal 20B when the "OK" button is tapped on the screen in the center of FIG. 3-3. On this screen, the amounts to be paid by the four people are displayed below the total amount split: "4,000 yen," "2,500 yen," "2,500 yen," and "1,000 yen."
[0267] <Processing> 3-4 to 3-5 are flow charts showing an example of the flow of processes executed by each device in this embodiment, and should be read in the same way as FIG. 1-12. As shown in the example display screen, user DD may be included in the sharing members, but here the process will be explained assuming three users: user AA, user BB, and user CC.
[0268] When the control unit 11 of the server 10 receives the split roulette request information from the terminal 20A via the communication I / F 14, the control unit 11 of the server 10 transmits information on the burden amount, in which the burden person and burden amount are unknown, by way of example and not limitation, to the terminal 20A via the communication I / F 14. The control unit 21 of the terminal 20A displays the received burden amount information on the display unit 24, and transmits decision information to the server 10 via the communication I / F 22 based on the user's input of decision (A310).
[0269] When the control unit 11 of the server 10 receives the decision information from terminal 20A via the communication I / F 14, the control unit 11 of the server 10 transmits split pay roulette participation setting information including, by way of example and not limitation, the type of split pay roulette participation setting (by way of example and not limitation, “Participate” or “Equal Amount”) to terminal 20B and terminal 20C via the communication I / F 14 (S310).
[0270] When the split pay roulette participation setting information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the received split pay roulette participation setting information (B310). Then, based on the setting input regarding participation in the split pay roulette based on the split pay roulette participation setting information displayed on the display unit 24, the control unit 21 of the terminal 20B transmits the split pay roulette participation setting information including the split pay roulette participation type to the server 10 via the communication I / F 22 (B330). Here, it is assumed that user BB selects "participate."
[0271] Similarly, with regard to the terminal 20C, the control unit 21 of the terminal 20C performs the processes C310 and C330. Here, it is assumed that user CC has selected "Equal Amount."
[0272] After S310, the control unit 11 of the server 10 judges whether or not the split roulette participation setting information has been received from the terminals 20 of all the members except the master (S320).
[0273] If there is a member terminal 20 that has not received the message (S320: NO), the control unit 11 of the server 10 waits. On the other hand, if it is determined that the information has been received (S320: YES), the control unit 11 of the server 10 performs a burden amount setting process (S330). Specifically, by way of example and not limitation, the burden amount is set based on the split roulette participation setting of each member in the split member management data. More specifically, for members whose split roulette participation setting is "equal amount", the payment amount is set to "total split amount ÷ number of split members". Then, the burden amount is set based on the number of members whose split roulette participation setting is "participation" and the remaining amount. Then, the control unit 11 of the server 10 transmits information on the multiple burden amounts set to the terminal 20A via the communication I / F 14 (S330).
[0274] After A310, the control unit 21 of the terminal 20A performs the processes of A120 and A130. After S330, the control unit 11 of the server 10 performs the process of S130, and in S150, transmits the split request information to the terminal 20B via the communication I / F 22.
[0275] In this process, since user CC selected "Equal Amount," in S150, the control unit 11 of the server 10 does not transmit the split request information to the terminal 20C. However, this is not limited to this, and the split request information may be transmitted to the terminal 20C as well.
[0276] After B330, the control unit 21 of the terminal 20B performs processes B110, B150, and B190. Then, although not shown in the figure, when an input to remit the payment amount is made in the terminal 20B, the control unit 21 of the terminal 20B transmits remittance request information to the server 10 via the communication I / F 22, and the control unit 11 of the server 10 performs the remittance process.
[0277] Also, although not shown in the figure, after C330, when an input is made in terminal 20C to transfer the payment amount (in this example, an "even amount"), the control unit 21 of terminal 20C transmits remittance request information to server 10 via communication I / F 22, and the remittance processing is carried out by the control unit 11 of server 10.
[0278] Unlike this method, if at least one of the splitting members excluding the master selects "equal amount," the control unit 11 of the server 10 may determine the payment amount for each splitting member using the "divide equally" method without playing the splitting roulette. In other words, the other splitting members may also be forced to pay an equal amount.
[0279] <Effects of the third embodiment> This embodiment illustrates a configuration in which the first amount based on the information on the first amount to be sent to the terminal 20 (not limited to, but an example of the second terminal) of the first split member (not limited to, but an example of the second user) is an equal amount when the first split member selects an equal amount based on the total split amount (not limited to, but an example of the total remittance request amount) of the master (not limited to, but an example of the first user). According to this, when the second user of the second terminal selects an equal amount based on the total amount of the remittance request made by the first user of the first terminal, information on the equal amount can be transmitted to the second terminal.
[0280] In addition, in this embodiment, the input of the first split member (not limited to, but an example of a second user) in response to the remittance request information of the master is an input related to participation in the split roulette (not limited to, but an example of an input related to participation in a remittance request related to the remittance request information by the first user).Then, the configuration is shown in which the information of the first amount to be sent to the first split member is sent to the master's terminal 20 based on the server 10 receiving the participation possibility from the split member to whom the payment amount notification information by the master has been sent. According to this, an input regarding participation in the remittance request by the second user in response to the remittance request information from the first terminal is made by the first user of the first terminal, and information on the first amount can be transmitted to the first terminal based on the server receiving a participation decision from the user to whom the remittance request information by the first user was sent. As a result, by way of example and not limitation, the information on the first amount can be output at the first terminal to inform the first user of the first amount.
[0281] <Third Modification (1)> As an alternative method to the above embodiment, the control unit 11 of the server 10 may refrain from sending payment amount notification information to the terminal 20 of a splitting member, even if it has received splitting roulette execution request information from the terminal 20 of the splitting member, until it has received splitting roulette execution request information from the terminal 20 of all splitting members except the master.
[0282] In this case, the control unit 11 of the server 10 does not include information on the multiple set amounts to be paid when sending split request information to the terminal 20. Alternatively, the control unit 21 of the terminal 20 may include information on the multiple set amounts to be paid, but may not display the information on the amounts to be paid on the split roulette screen. When the control unit 11 of the server 10 receives split roulette execution request information from the terminals 20 of all split members except the master, the control unit 11 of the server 10 may transmit payment amount notification information including information on the corresponding payment amount to the terminals 20 of each split member. In this way, even if one of the splitting members selects "equal amount," it is possible to prevent the person who selected the equal amount from knowing.
[0283] Furthermore, as a method different from the above embodiment, the control unit 11 of the server 10 may, by way of example and not limitation, receive split roulette execution request information from the terminal 20 of one of the split members excluding the master, transmit payment amount notification information, and then receive split roulette participation setting information from the terminal 20 of another split member that sets the split roulette participation setting to "equal amount," reset and start the process over from the beginning (re-draw the lottery).
[0284] As an alternative method to the above embodiment, multiple payment amounts may be set, and then if a sharing member selects "equal amount," the payment amount may be reset (changed).
[0285] 3-6 to 3-10 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this case. The left side of Figure 3-6 shows the splitting setting screen displayed on the display unit 24 of terminal 20A. In this example, the amounts to be paid by the four splitting members are set to "4,000 yen," "3,000 yen," "2,000 yen," and "1,000 yen."
[0286] The center of Figure 3-6 shows an example of a split roulette screen that is displayed on the display unit 24 of terminal 20B based on the tapping of the "Decide" button on the screen on the left side of Figure 3-6, and shows the state in which user BB has tapped the equal amount payment button (in this example, the button for "Pay 2,500 yen without participating in roulette") BT21 (selecting "Equal Amount"). In this case, by way of example and not limitation, the server 10 notifies the terminal 20A that the split request needs to be modified.
[0287] An example of a notification screen displayed on the display unit 24 of the terminal 20A in this case is shown on the right side of FIG. 3-6. On this notification screen, beneath the split request information based on the tapping of the “Decide” button on the screen on the left side of Figure 3-6, split request change notification information RNI1, indicating that the split request needs to be changed, is displayed.
[0288] When the "Check details" button included in this sharing request change required notification information RNI1 is tapped, the sharing setting screen shown on the left side of Figure 3-7 is displayed, as an example and not a limitation. Because user BB has selected to pay in equal installments, the split request setting screen displays user BB's share of the bill as "2,500 yen." Also, in this example, the "total split amount" display has changed to "remaining total split amount," which is displayed as "7,500 yen," calculated by subtracting user BB's share of the bill, "2,500 yen," from the original total split amount of "10,000 yen." In this example, the remaining total amount will be shared by the three members excluding user BB. Therefore, the remaining three members' shared amounts are displayed as "4,000 yen," "2,000 yen," and "1,500 yen," respectively.
[0289] In this case, the user may be able to manually adjust the amounts paid by the remaining three people by operating the amount increase / decrease button so that the total amounts equal the remaining total amount to be shared. However, the present invention is not limited to this, and the terminal 20A or the server 10 may automatically adjust the amounts to be paid by the remaining three people so that the sum of these amounts becomes the total remaining split amount.
[0290] The center of FIG. 3-7 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20C when the "OK" button is tapped on the screen on the left side of FIG. 3-7. On this notification screen, below the sharing request information, sharing request update notification information RUI1 is displayed, indicating that the sharing request has been updated.
[0291] When the "Check details" button included in this split request update notification information RUI1 is tapped, the split roulette screen shown on the right side of FIG. 3-7 is displayed, by way of example and not limitation. On this split roulette screen, the total remaining split amount is displayed as "7,500 yen," and the amounts to be paid by the three users excluding user BB are displayed as "4,000 yen," "2,000 yen," and "1,500 yen."
[0292] In this example, the amounts to be paid by three users excluding user BB are displayed. In this case, however, there is a possibility that someone may know that an equal amount has been selected. Therefore, the flat rate of "2,500 yen" may also be displayed, and the total amount to be paid by all four people may be displayed.
[0293] The left side of Figure 3-8 shows an example of a payment amount notification screen that is displayed on the display unit 24 of terminal 20C based on tapping the ``Spin Roulette'' button BT3 on the screen on the right side of Figure 3-7.In this example, the payment amount of user CC is shown to be ``1,500 yen.'' Similarly, the center of FIG. 3-8 shows an example of a payment amount notification screen displayed on the display unit 24 of the terminal 20A, which shows that the payment amount for user AA is "4,000 yen."
[0294] An example of a split roulette screen displayed on the display unit 24 of the terminal 20D is shown on the right side of FIG. 3-8. On this split roulette screen, the total remaining split amount is displayed as "7,500 yen," and the amounts to be paid by the three users excluding user BB are displayed as "4,000 yen," "2,000 yen," and "1,500 yen."
[0295] In this example, the amounts due for three people are displayed on the display 24 of terminal 20D. However, since "1,500 yen" is the amount paid by user CC and "4,000 yen" is the amount paid by user AA, when user DD taps the "Spin the roulette" button BT3, the amount paid by user DD is displayed as "2,000 yen."
[0296] The left side of Figure 3-9 shows an example of a notification screen that is displayed on the display 24 of terminal 20A based on user DD tapping the equal amount payment button (in this example, the button for "Pay 2,500 yen without participating in roulette") BT21 instead of the "Spin roulette" button BT3 on the screen on the right side of Figure 3-8, and split request change notification information RNI1 is displayed below the aforementioned split request update notification information RUI1.
[0297] When the "Check details" button included in this sharing request change required notification information RNI1 is tapped, the sharing setting screen shown in the center of Figure 3-9 is displayed, as an example and not a limitation. Because user BB and user DD have chosen to pay equally, the split request setting screen shows the amount owed by user BB and user DD as "2,500 yen." The remaining split total has also been updated and displayed as "5,000 yen." In this example, the remaining total amount will be shared by the two other split members, excluding users BB and DD. In this example, the user operates the increase / decrease buttons to adjust the remaining two members' share amounts to "4,000 yen" and "1,000 yen," as shown on the right side of Figure 3-9, and these share amounts are displayed in the amount boxes.
[0298] The left side of FIG. 3-10 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20C when the "OK" button is tapped on the screen on the right side of FIG. 3-9. On this notification screen, below the previously described split charge request update notification information RUI1, split charge amount update notification information FUI1 is displayed, notifying that the split charge amount has been updated. When the "Check details" button included in this shared payment amount update notification information is tapped, the payment amount notification screen shown on the right side of Figure 3-10 will be displayed, as an example and not a limitation. In this example, the payment amount of user CC is shown to be "1,000 yen." In other words, the original payment amount of user CC was "1,500 yen," but based on user DD's selection to pay in equal installments, the payment amount of user CC was changed to "1,000 yen."
[0299] 3-11 to 3-13 are flowcharts showing an example of the flow of processes executed by each device in this modified example. In this process, for convenience, user DD is also included in the sharing members, but the process flow of user DD's terminal 20D is omitted from the illustration.
[0300] When the sharing request information is received from the server 10 via the communication I / F 14, the control unit 21 of the terminal 20B and the control unit 21 of the terminal 20C perform operations B110 and C110, respectively.
[0301] Here, as an example and not a limitation, it is assumed that the user BB selects "equal amount." In this case, the control unit 21 of the terminal 20B transmits equal amount payment request information to the server 10 via the communication I / F 22 (B350).
[0302] After S150, when equal amount payment request information is received from terminal 20B via communication I / F 14, control unit 11 of server 10 performs a burden amount resetting process (S350). Specifically, the burden amount of user BB is set as the equal amount, and "remaining total amount of split payment = total amount of split payment - equal amount" is calculated, and the burden amount for the remaining number of split payment members is set based on the remaining total amount of split payment and the number of remaining split payment members (in this example, three users: user AA, user CC, and user DD).
[0303] Thereafter, the control unit 11 of the server 10 transmits the split request change necessity notification information to the terminal 20A via the communication I / F 14 (S355). The split request change necessity notification information may include, for example and without limitation, information on the remaining split total amount, information on the reset charge amount, information on the charge amount of user BB (in this example, an equal amount), and the like.
[0304] When the control unit 21 of the terminal 20A receives the notification information indicating the need to change the split charge request from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the received notification information indicating the need to change the split charge request (such as a notification screen based on the notification information indicating the need to change the split charge request) (A350).
[0305] For example, but not by way of limitation, when an input is made to the split charge request change necessary notification information displayed on the display unit 24, the control unit 21 of the terminal 20A causes the display unit 24 to display split charge setting information (such as a split charge setting screen based on the split charge setting information) based on the information included in the split charge request change necessary notification information. Then, based on the user's input of a decision, the control unit 21 transmits the decision information to the server 10 via the communication I / F 22 (A360). As shown in the example display screen, the user may be able to manually change the displayed amount to be borne, in which case information on the changed amount to be borne may be included in the sharing roulette execution request information and transmitted to the server 10.
[0306] After S355, when the control unit 11 of the server 10 receives split roulette execution request information from the terminal 20A via the communication I / F 14, the control unit 11 of the server 10 performs a re-lottery process (S360). This determines the amounts to be paid by the remaining split members, user AA, user CC, and user DD.
[0307] Next, the control unit 11 of the server 10 transmits the split request update notification information to each of the terminals 20C and 20D via the communication I / F 14 (S370). The split request update notification information may include the reset charge amount (which may include the amount corrected by the master), and may allow the user to confirm the reset charge amount. The split charge request update notification information may be sent to the terminal 20B, and may also be sent to the terminal 20A.
[0308] After C110, when split charge request update notification information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20C causes the display unit 24 to display the received split charge request update notification information (such as a notification screen based on the split charge request update notification information) (C350).
[0309] For example, but not by way of limitation, when an input is made to the split charge request update notice information displayed on the display unit 24, the control unit 21 of the terminal 20C causes the display unit 24 to display split charge request information (such as a split charge roulette screen based on the split charge request information) based on the information included in the split charge request update notice information. Then, when the user makes an input to request playing the split charge roulette, the control unit 21 transmits split charge roulette playing request information to the server 10 via the communication I / F 22 (C150).
[0310] When the control unit 11 of the server 10 receives split roulette execution request information from the terminal 20C via the communication I / F 14, the control unit 11 of the server 10 transmits payment amount notification information including information on the payment amount (amount owed) of the user CC to the terminal 20C via the communication I / F 14 (S180) based on the result of the re-lottery process (S360). In response to this, the control unit 21 of the terminal 20C causes the display unit 24 to display the received payment amount notification information (C190).
[0311] Furthermore, based on the result of the re-lottery process (S360), the control unit 11 of the server 10 transmits payment amount notification information including information on the payment amount (amount owed) of the user AA to the terminal 20A via the communication I / F 14 (S380). In response to this, the control unit 21 of the terminal 20A causes the display unit 24 to display the received payment amount notification information (A390). In addition, the processes of S380 and A390 may be omitted.
[0312] It is assumed that the server 10 subsequently receives equal amount payment request information from the terminal 20D via the communication I / F 14. In this case, the control unit 11 of the server 10 performs the same process as S350 to reset the charges, and sets the charges for the two users, the master user AA and user CC who did not select the equal amount. The charges for users BB and DD are set to an equal amount.
[0313] Next, the control unit 11 of the server 10 performs the process of S370. After A390, the control unit 21 of the terminal 20A performs the processes of A350 and A360. After S370, the control unit 11 of the server 10 performs a re-lottery process (S390).
[0314] Thereafter, the control unit 11 of the server 10 transmits payment amount update notification information including information on the updated payment amount based on the result of the re-lottery process (S390) to the terminal 20C via the communication I / F 14 (S395). When the payment amount update notice information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20C causes the display unit 24 to display the received payment amount update notice information (C395).
[0315] In this example, after payment amount notification information is sent to terminal 20C and displayed in S180, the amount to be paid is reset based on user DD's selection of "flat rate," and as a result, the payment amount for user CC is updated (changed). However, before the payment amount update notification information is transmitted to and displayed on terminal 20C, user CC may have already completed remittance of the payment amount before the update based on the payment amount notification information. In this case, if it is determined that the remittance amount of user CC is excessive, the control unit 11 of the server 10 may perform a refund process to refund the difference (the difference between the payment amount before and after the update) to user CC. On the other hand, if it is determined that the remittance amount of user CC is insufficient, the control unit 11 of the server 10 may perform an additional remittance request process to request user CC to remit an additional amount of the difference. In the above example display screen, the payment amount of user CC before the update is "1,500 yen" and the payment amount of user CC after the update is "1,000 yen", so user CC may have over-transmitted "500 yen". In this case, the control unit 11 of the server 10 may perform a refund process to refund "500 yen" to user CC.
[0316] As a non-limiting example, when equal amount payment request information is received from at least one terminal 20 of the splitting members excluding the master, the control unit 11 of the server 10 may determine the payment amount for each splitting member by the "equal division" method without performing the splitting roulette. In other words, the other splitting members may also be forced to pay equal amounts.
[0317] Also, as a non-limiting example, when equal amount payment request information is received from at least one terminal 20 of the splitting members excluding the master, the control unit 11 of the server 10 may transmit information to that effect to the terminals 20 of the other splitting members. Then, when a user inputs to play the splitting roulette, the control unit 21 of that terminal 20 may display error information, or the like, and may not transmit the splitting roulette play request information to the server 10.
[0318] In addition, if the set burden amounts include an amount equal to the equal amount, the control unit 11 of the server 10 may determine the burden amount as the payment amount of the sharing member who set the "equal amount". In other words, the sharing member who set the "equal amount" may be notified that he / she has won the equal amount burden amount by lottery.
[0319] This modified example illustrates a configuration in which the first amount based on the information on the first amount to be sent to the terminal 20 (not limited to, but an example of the second terminal) of the first split member (not limited to, but an example of the second user) is an equal amount when the first split member selects an equal amount based on the total split amount (not limited to, but an example of the total remittance request amount) of the master (not limited to, but an example of the first user). According to this, when the second user of the second terminal selects an equal amount based on the total amount of the remittance request made by the first user of the first terminal, information on the equal amount can be transmitted to the second terminal.
[0320] In addition, this modified example shows a configuration in which the multiple set burden amounts (not limited to, but an example of the amount to be remitted to the multiple set first users) are reset when the first split member (not limited to, but an example of the second user) sets an equal amount based on the master's split total amount (not limited to, but an example of the total remittance request amount). According to this, the amount to be remitted to a first user of a first terminal, which is set in multiple places, can be reset if a second user of a second terminal selects an equal amount based on the total amount of the remittance request made by the first user.
[0321] In this case, the server 10 may also control, via the control unit 11, to transmit information on the reset charge amount (not limited to, but an example of, the reset amount to be remitted to multiple first users) to the terminal 20 (not limited to, but an example of, the third terminal) of the second sharing member. This allows information on the amount to be remitted to the reset first user to be transmitted to the third terminal of the third user, so that, by way of example and not limitation, the information on the amount to be remitted to the reset first user is output at the third terminal, thereby informing the third user of the amount to be remitted to the reset first user.
[0322] In addition, this modified example shows a configuration in which, when a second split member (not limited to, but an example of a third user) selects an equal amount based on the master's (not limited to, but an example of the first user) total split amount (not limited to, but an example of the total remittance request amount), information on a third amount different from the first amount based on the information on the first amount sent to the master's terminal 20 is sent to the master's terminal 20. According to this, when the third user of the third terminal selects an equal amount based on the total remittance request amount of the first user of the first terminal, information on a third amount, which is an amount different from the first amount based on the information on the first amount transmitted to the first terminal, can be transmitted to the first terminal. As a result, by way of example and not limitation, the information on the third amount can be output at the first terminal to inform the first user of the third amount.
[0323] <Fourth Example> The fourth embodiment relates to an embodiment that allows a splitting member to transfer an amount to the master that is different from the determined amount of his / her payment (for example, but not by way of limitation, an amount greater than the amount of his / her payment). The contents described in the fourth embodiment are applicable to any of the other embodiments and other modified examples.
[0324] There may be cases where a user wishes to pay more than the amount decided for the user to pay. This includes, by way of example and not limitation, cases where a senior or superior person wishes to pay more at a drinking party or the like. Also, some users may wish to pay more than a small amount won in the split roulette.
[0325] <Display screen> 4-1 to 4-3 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this embodiment. The left side of Figure 4-1 shows an example of a split-payment setting screen displayed on the display unit 24 of terminal 20A. In this example, the split-payment members are user AA, user BB, and user CC, the total split amount is "12,000 yen," and the amounts to be paid are set as "6,000 yen," "4,000 yen," and "2,000 yen."
[0326] The center of FIG. 4-1 shows an example of a payment amount notification screen that is displayed on the display unit 24 of the terminal 20B when the "OK" button BT1 is tapped on the screen on the left side of FIG. 4-1. This payment amount notification screen displays information indicating that the amount to be paid by user BB is "2,000 yen", as well as a "Pay More" button BT41 for paying an amount greater than this amount.
[0327] When the "Pay More" button BT41 is tapped, a display such as that shown on the right side of FIG. 4-1 is displayed, by way of example and not limitation. In this example, the "Pay More" button BT41 disappears, and an increase button is displayed that allows the user to specify the amount to be paid more. In this example, the increase buttons displayed are a "+500 yen" button for paying 500 yen more, a "+1,000 yen" button for paying 1,000 yen more, and a "+2,000 yen" button for paying 2,000 yen more. In this example, the "+1,000 yen" button is tapped by user BB to pay 1,000 yen more, and this button is displayed inverted.
[0328] Regardless of whether the increase button is displayed or not, the user may be able to input the additional amount to be paid (hereinafter referred to as the "additional payment amount") or the amount obtained by adding the additional payment amount to the payment amount using a numeric keypad or the like.
[0329] The left side of FIG. 4-2 shows an example of a notification screen that is displayed on the display unit 24 of the terminal 20A when the "Remit split amount" button BT5 is tapped on the screen on the right side of FIG. 4-1. On this notification screen, below the split request information RI1, split request change required notification information RNI1, which indicates that the split request needs to be changed, is displayed. When the "Check details" button included in this sharing request change required notification information RNI1 is tapped, the sharing setting screen shown in the center of Figure 4-2 is displayed, as an example and not a limitation. On this split payment setting screen, the amount paid by user BB is displayed as "3,000 yen," which is the original amount of "2,000 yen" plus "1,000 yen." The remaining split payment total is also updated to "9,000 yen." In this case, the remaining split amount will be shared between users AA and CC. In this example, user AA has changed the amount from "6,000 yen" to "5,000 yen" by operating the amount reduction button in the amount box MB2 (center to right side of Figure 4-2).
[0330] The left side of FIG. 4-3 shows an example of a split-payment roulette screen that is displayed on the display unit 24 of the terminal 20C after a split-payment request based on the initial payment amount is sent to the terminal 20C. When the user closes the split roulette screen, a notice screen is displayed (center of Figure 4-3). In this example, the notice screen displays split request update notice information RUI1 below the split request information RI1, notifying the user that the split request has been updated. When the "Check details" button included in the split request update notice information RUI1 is tapped, the split roulette screen is displayed again (right side of Figure 4-3). In this split roulette screen, the amounts to be paid are different from those shown in the left screen of Figure 4-3, based on the fact that user BB has requested to pay "3,000 yen" as described above. Specifically, the amounts to be paid by the three people have changed to "5,000 yen," "4,000 yen," and "3,000 yen."
[0331] In this example, the amounts to be paid by three people are displayed on the display unit 24 of the terminal 20C, but since "3,000 yen" is the amount to be paid by user BB, even if user CC taps the "Spin the roulette" button BT3, the amount to be paid by user CC will not become "3,000 yen."
[0332] In this way, if there is a user who pays more than the amount due, the amount due will be automatically reset, or the amount due will be reset by the master, and finally, the sharing member only needs to transfer the payment amount adjusted to take into account the amount paid more than the amount due to the user to the master.
[0333] In this example, user BB chooses to pay more, but in this case, the control unit 11 of the server 10 may notify the other members of the terminals 20 of the fact that user BB will pay more and the amount of the payment. The master may or may not be notified.
[0334] <Processing> The processes executed by each device in this embodiment can be realized similarly to the processes shown in FIGS. 3-4 to 3-5 and 3-11 to 3-13, by way of example and not limitation, and therefore detailed description thereof will be omitted. In this embodiment, by way of example and not limitation, in S170 and S180 of the processing in FIG. 1-12, in addition to information on the payment amount, display information that serves as a guide to paying more than the payment amount may be included in the payment amount notification information and transmitted to the terminal 20 of the splitting member.
[0335] The control unit 21 of the terminal 20 of the splitting member, at B190 and C190, displays payment amount notification information (such as a payment amount notification screen based on the payment amount notification information) including the above-mentioned "Pay More" button, etc., on the display unit 24 based on the information received from the server 10. Then, when the user inputs an input to pay more and the additional payment amount is determined, the terminal 20 of the splitting member may transmit payment amount update request information including information on the additional payment amount to the server 10, by way of example and not limitation. In addition, information on the updated (changed) payment amount of the sharing member (hereinafter, for convenience, referred to as the “updated payment amount”), which is calculated as “payment amount + additional payment amount”, may be transmitted to the server 10.
[0336] When the control unit 11 of the server 10 receives payment amount update request information from the terminal 20 of a splitting member, the control unit 11 may perform a burden amount resetting process similar to, but not limited to, S350 in Fig. 3-11, for example. Specifically, the burden amount of that splitting member may be set as the updated payment amount, and calculated as "remaining split total amount = total split amount - updated payment amount", and the burden amount for the remaining splitting members may be set based on the remaining split total amount and the number of remaining splitting members. Then, the control unit 11 of the server 10 may perform the same processes as S355 to S370 in FIG. 3-11.
[0337] Alternatively, the sharing member may remit to the master the payment amount based on the initially set sharing amount without carrying out the sharing amount reset process. In this case, the sharing member who pays more may remit the updated payment amount to the master. If a sharing member transfers an amount to the master that is greater than the amount paid, the master will receive more by the amount of the additional payment. In this case, as an example and not as a limitation, the control unit 11 of the server 10 may transmit information including information on the additional payment amount or the updated payment amount to the master terminal 20, and the master terminal 20 may display, on the display unit 24, information on the additional payment amount and confirmation information confirming whether or not to distribute the additional payment amount based on the information received from the server 10.
[0338] In this case, the additional payment amount may be distributed equally to the members excluding the member who paid more, based on the input by the master to the terminal 20. In this case, the master may secure his / her own share and then remit the remaining amount. Also, by way of example and not limitation, based on input by the master to terminal 20, an additional payment amount may be sent to the user who won the largest payment amount.
[0339] <Effects of the Fourth Embodiment> In this embodiment, when the first split member's terminal 20 selects to transfer an updated payment amount (not limiting, an example of a fourth amount) that is greater than the first split member's payment amount based on information on the first split member's share of the bill (not limiting, an example of the first amount) sent to the first split member's terminal 20 (not limiting, an example of the second terminal), the server 10 transmits payment amount information based on the updated payment amount to the master terminal 20 via the communication I / F 14. According to this, when a transfer of a fourth amount, which is greater than the first amount based on the first amount information, is selected by the second terminal of the second user based on the first amount information, information of the fourth amount based on the fourth amount is sent to the first terminal, thereby notifying the first user of the fourth amount.
[0340] In this case, the multiple set burden amounts (not a limitation, but an example of the multiple set amounts to be remitted to the first user) may be reset when a transfer of an updated payment amount (not a limitation, but an example of the fourth amount) that is greater than the first sharing member's burden amount (not a limitation, but an example of the first amount) is selected. According to this, when a fourth amount of remittance is selected, the multiple amounts set to be remitted to the first user can be reset.
[0341] Furthermore, this embodiment illustrates a configuration in which, when the transfer of an updated payment amount (not limited to, an example of a fourth amount) that is greater than the first split member's payment amount based on information of the first split member's payment amount is selected by the first split member's terminal 20 (not limited to, an example of a second terminal) based on information of the first split member's payment amount, information of the re-set payment amount (not limited to, an example of a sixth amount based on the fourth amount) based on the above-mentioned updated payment amount (not limited to, an example of the fourth amount) is transmitted via communication I / F 14 to the second split member of the terminal 20 (not limited to, an example of a third terminal) of the second split member (not limited to, an example of a third user) to which the payment amount information was transmitted, among the multiple set payment amounts (not limited to, an example of multiple set amounts to be transferred to the first user). According to this, when the second terminal of the second user selects, based on the information on the first amount, to transfer a fourth amount, which is an amount greater than the first amount based on the information on the first amount, information on a sixth amount based on the fourth amount can be sent to the third user of the third terminal of the third user to which information on the fifth amount was sent, out of the multiple amounts set to be transferred to the first user, thereby informing the third user of the sixth amount.
[0342] <Fourth modified example (1)> Unlike the method of the above embodiment, the payment amount may be adjusted by transfer between division members other than the master.
[0343] 4-4 and 4-5 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this modified example. The left side of Fig. 4-4 shows an example of a splitting setting screen displayed on the display unit 24 of the terminal 20A, similar to the left side of Fig. 4-1, and shows a state in which the "OK" button BT1 has been tapped by the user AA.
[0344] The center of FIG. 4-4 shows an example of a payment amount notification screen displayed on the display unit 24 of the terminal 20C in this example. This payment amount notification screen shows that the amount to be paid by user CC is "6,000 yen", and similarly to the screen in the center of FIG. 4-1, a "Pay More" button BT41 is displayed.
[0345] An example of a payment amount notification screen displayed on the display unit 24 of the terminal 20B in this example is shown on the right side of FIG. 4-4. This payment amount notification screen shows that the amount to be paid by user BB is "2,000 yen", and similarly to the screen in the center of FIG. 4-1, a "Pay More" button BT41 is displayed. When the "Pay More" button BT41 is tapped, the display shown on the left side of Fig. 4-5 is displayed, for example and not for limitation. In this example, the screen is the same as that on the right side of Fig. 4-1, and in this example, the "+2,000 yen" button is displayed inverted based on the fact that user BB tapped the button to pay 2,000 yen more.
[0346] The center of FIG. 4-5 shows an example of a notification screen that is displayed on the display unit 24 of the terminal 20C when the "Remit split amount" button BT5 is tapped on the screen on the left side of FIG. 4-5. In this notification screen, shared charge amount update notification information FUI1, which indicates that the shared charge amount has been updated, is displayed below shared charge request information RI1. When the "Check details" button included in this shared payment amount update notification information FUI1 is tapped, the payment amount notification screen shown on the right side of Figure 4-5 is displayed, as an example and not a limitation. On this payment amount notification screen, the amount to be borne by user CC is updated to "4,000 yen", which is the amount initially determined to be "6,000 yen" minus the additional payment amount of "2,000 yen". This is equivalent to "2,000 yen" being transferred from user BB to user CC.
[0347] In addition, the additional payment amount may be transferred to the member who won the largest payment amount. In the above example, the additional payment amount of "2,000 yen" may be transferred to user CC who won the payment amount of "6,000 yen." Alternatively, the additional payment amount may be divided equally among the other split members. In the above example, the additional payment amount of "2,000 yen" may be divided into "1,000 yen" each for user AA and user CC, by way of example and not by way of limitation.
[0348] Furthermore, in this example, there may be cases where user CC has already completed remittance of the payment amount before the payment amount update notification information is transmitted to and displayed on terminal 20C, based on the payment amount notification information. As in the third modified example (1), if it is determined that the remittance amount of user CC is excessive, the control unit 11 of the server 10 may perform a refund process to refund the difference (the difference between the payment amounts before and after the update) to user CC. On the other hand, if it is determined that the remittance amount of user CC is insufficient, the control unit 11 of the server 10 may perform an additional remittance request process to request user CC to remit an additional amount of the difference. In the above example, the payment amount of user CC before the update is "6,000 yen" and the payment amount of user CC after the update is "4,000 yen", so there is a possibility that user CC has over-transmitted "2,000 yen". In this case, the control unit 11 of the server 10 may perform a refund process to refund "2,000 yen" to user CC.
[0349] <Fifth Example> The fifth embodiment relates to the application of the technique of the present disclosure to a chat service (as an example and not a limitation, a messaging service). The contents described in the fifth embodiment are applicable to any of the other embodiments and other modified examples.
[0350] 5-1 to 5-3 are diagrams showing examples of screens displayed on the display unit 24 of the terminal 20 in this embodiment.
[0351] The left side of FIG. 5-1 shows an example of a talk room screen of a messaging application displayed on the display unit 24 of the terminal 20A. This chat room screen shows, by way of example and not limitation, an example of a group chat room screen for a group named "Development Group" configured using a messaging application, with four group members: user AA, user BB, user CC, and user DD. The message content display area MCR, where message content is displayed, is configured so that message content corresponding to messages sent by the user (user AA in this screen) is displayed in a speech bubble on the right side of the screen, and message content corresponding to messages sent by other group members is displayed in a speech bubble on the left side of the screen.
[0352] In addition, below the message content display area MCR, an area is provided in which functional icons corresponding to various functions of the messaging application are displayed, and in addition to the functional icons corresponding to various functions, a message content input area is also provided for the user to input message content.
[0353] In this example, the contents of the conversation show that user AA is the organizer (master), that the development group members are holding a welcome party for user DD, and that user AA is collecting the party fees. The contents of the conversation also show that user CC proposes to decide the amount for each person by splitting the bill with a roulette, and that user DD is surprised.
[0354] By way of example and not limitation, when the "+" button located in the upper left corner of this area is tapped, a payment application is launched and the display changes to the screen shown on the right side of Figure 5-1. This screen is the splitting setting screen for the payment application mentioned above. In this example, "20,000 yen" has been entered as the total split amount, and the amounts to be paid by each of the four people have been set as "8,000 yen," "6,000 yen," "4,000 yen," and "2,000 yen," which are displayed in amount boxes MB1 to MB4, respectively.
[0355] The left side of FIG. 5-2 shows an example of a talk room screen of a messaging application that is displayed on the display unit 24 of the terminal 20B when the "OK" button BT1 is tapped on the screen on the right side of FIG. 5-1. This chat room screen shows, by way of example and not limitation, an example of an OA chat room screen with a payment application as the chat partner, and in the message content display area MCR, message content corresponding to a message sent by the user (user BB) is displayed in a speech bubble on the right side of the screen, and messaging content corresponding to a message sent by the chat partner is displayed in a speech bubble on the left side of the screen. In this example, the split-account request message content RCT1 corresponding to the split-account request information described above is displayed as the message content originating from the payment application.
[0356] When the "Check details" button included in the split payment request message content RCT1 is tapped, by way of example and not limitation, a payment application is launched and the screen shown in the center of Figure 5-2 is displayed. This screen is the split roulette screen of the payment application mentioned above, and shows the total split amount as "20,000 yen," and the amounts paid by each of the four people as "8,000 yen," "6,000 yen," "4,000 yen," and "2,000 yen."
[0357] In this example, a state is shown in which the "Spin Roulette" button BT3 has been tapped by user BB. Then, by way of example and not limitation, a payment amount notification screen of the payment application is displayed, as shown on the right side of Figure 5-2. This screen is the payment amount notification screen of the payment application described above, and in this example, it shows that the payment amount for user BB is "2,000 yen."
[0358] Here, assume that user BB taps the share icon SIC on the payment amount notification screen. In this case, by way of example and not limitation, the server 10 transmits message content including information on the amount borne by user BB to the group chat room with the group name “Development Group” of the messaging application described above, and the information on the amount borne by user BB is shared with the group members.
[0359] The left side of FIG. 5-3 shows an example of a talk room screen in a messaging application displayed on the display unit 24 of the terminal 20A. This chat room screen is an OA chat room screen with the payment application as the chat partner, and below the split charge request message content RCT1 corresponding to the split charge request information described above, the decision notification message content DCT1 corresponding to the amount determination notification information described above is displayed.
[0360] By way of example and not limitation, when the "Check Details" button included in the decision notification message content DCT1 is tapped, a payment application is launched and the display changes to the screen shown in the center of Figure 5-3. This screen is the payment application's split payment setting screen, which corresponds to the screen on the right side of Figure 5-1, and shows the state in which the amount to be paid by each split payment member has been determined. In this example, it is shown that the amount determined as "8,000 yen" for user DD, "6,000 yen" for user CC, "4,000 yen" for user AA, and "2,000 yen" for user BB.
[0361] Now, assume that user AA taps the share icon SIC provided on the splitting setting screen. In this case, by way of example and not limitation, server 10 transmits message content including information on the amount of each splitting member's share to the group chat room of the group named "Development Group" in the messaging application described above, and the information on the amount of each splitting member's share is shared with the group members.
[0362] The right side of FIG. 5-3 shows an example of a group talk room screen for the "development group" of the messaging application displayed on the display unit 24 of the terminal 20A in this case. On this group chat room screen, below the message content "Seriously?" sent by user DD in the message content display area MCR of the group chat room screen shown on the left side of Figure 5-1, message content sent to the group chat room based on user BB tapping the share icon SIC on the screen on the right side of Figure 5-2 and sent by user BB (in this example, message content including a roulette thumbnail and the text "Payment amount is 2,000 yen") is displayed. In addition, the message content sent to the group chat room based on user AA tapping the share icon SIC on the screen in the center of Figure 5-3, which is the message content sent from user AA (in this example, the message content titled ``Split the Treasury Roulette Results''), is displayed. In this example, based on the fact that user DD, who is a guest at the welcoming party, was the one who paid the highest amount, a message content is displayed that originates from user DD, causing the user to feel depressed that he or she may not be welcome (in this example, "Maybe I'm not welcome...").
[0363] <Processing> The processing performed by each device in this embodiment can be realized in a similar manner to the processing shown in Figures 1-12, 1-13, 3-4 to 3-5, and 3-11 to 3-13, by way of example and not limitation, so detailed explanations will be omitted.
[0364] In this embodiment, by way of example and not limitation, the server 10 may have a function of providing a messaging service (a function of managing various information related to the messaging service) and a function of providing a payment service.
[0365] In this embodiment, by way of example and not limitation, the server 10 (or messaging server) transmits talk room information to the terminal 20, and the terminal 20 displays a talk room screen on the display unit 24 based on the received talk room information. When an input to perform split payment is made on the chat room screen, a request for split payment settings is sent from terminal 20 to server 10 (or the messaging server), information for split payment settings is sent from server 10 to terminal 20, and the split payment settings screen is displayed.
[0366] As described above, a payment application may be launched on terminal 20 and the splitting setting screen may be displayed by the payment application, or the splitting setting screen may be displayed by a messaging application.
[0367] The control unit 11 of the server 10 transmits a split-billing request message content corresponding to the split-billing request information to the terminal 20 via the communication I / F 14. Then, the control unit 21 of the terminal 20 displays the received split-billing request message content on the talk room screen.
[0368] When an input to share the results is made on the payment amount notification screen displayed on the user's terminal 20, the control unit 21 of the terminal 20 transmits sharing request information to the server 10 via the communication I / F 22. In response to this, the server 10 transmits shared message content including information on the user's payment amount as message content originating from the user to the group talk room of the group including the user and the other split members.
[0369] Similarly, when an input to share the results is made on the split payment setting screen displayed on the master terminal 20, the control unit 21 of the master terminal 20 transmits sharing request information to the server 10 via the communication I / F 22. In response to this, the server 10 transmits shared message content including information on the payment amount of each split payment member as message content originating from the master to the group talk room.
[0370] Unlike the above, two servers may be configured: a messaging server (first server) having a function of providing a messaging service, and a payment server (second server) having a function of providing a payment service.
[0371] <Other Examples> (1) First Modification As described in (1) above, the above embodiment illustrates a case in which the master makes a payment to a store or the like on behalf of the other users, but the present invention is not limited to this.
[0372] As mentioned above, by way of example and not limitation, a payment account (such as an electronic money account) for the group of split members may be configured in the memory unit 15 of the server 10, and each split member, including the master, may transfer money to this payment account. The total amount of the split may then be paid from this payment account.
[0373] The payment account may or may not be a common account that can be used by each of the splitting members.
[0374] The techniques described in the above embodiments and modifications can be similarly applied to this technique.
[0375] For example and not by way of limitation, the server may transmit information on a remittance request to at least a first terminal of a first user and a second terminal of a second user, and may transmit information on a first amount, among amounts to be remitted to a plurality of predetermined accounts, to the first terminal based on an input by the first user to the information on the remittance request.
[0376] In this case, by way of example and not limitation, the server may be configured to send information on a second amount, out of the amounts to be remitted to multiple specified accounts, to the second terminal based on the second user's input regarding the remittance request information.
[0377] Also, instead of inputting the total split amount, the master may input the total remittance request amount to be requested to the master (the master). In this case, as a non-limiting example, the master may determine his / her own payment amount based on the total split amount, and input the amount obtained by subtracting his / her own payment amount from the total split amount as the total remittance request amount in his / her terminal 20. Then, the amount to be paid by each of the sharing members excluding the master may be set by using a method similar to that described in the above embodiment and modified example.
[0378] (2) In the above embodiment, "roulette" is used as an example of a game, but the invention is not limited to this. In addition to roulette, games such as lotteries (which may include omit lottery, maze lottery, etc.), slots, etc. may be used, but are not limited to these. Various games may be applied, and the amount to be paid (amount to be borne) by each user may be determined by lottery.
[0379] <Other> At least a part of the processing that is to be performed by the server 10 in the above embodiment and the like may be performed by the terminal 20. Conversely, at least a part of the processing that is to be performed by the terminal 20 in the above embodiment may be performed by the server 10.
[0380] In addition, the payment service provider may also be an SNS provider, such as a messaging service provider. In this case, the processing described in the above embodiments may be realized by one server, or the processing described in the above embodiments may be realized by a server system composed of multiple servers.
[0381] Note that, as an example and not a limitation, a system configured with one or more servers may be defined as a server system, and the server of the present invention may be a server system.
[0382] In addition, in the above embodiments, a server for distributing various applications (a server from which the terminal 20 downloads applications) may be configured as a server different from a server for providing the corresponding service (application). In other words, a server for distributing applications and a server for performing application management processing, etc., described in the above embodiments, etc., may be configured as physically separated servers, or may be configured as a single server.
[0383] Furthermore, the application is not limited to various application programs, but may include, for example and without limitation, a program for providing a function of another service as one function of a base application (for example and without limitation, a program for providing a payment service function as one function of a messaging application, or vice versa), a program for updating the base application, etc. Also, data used in the application program (which may include data for updating the application, etc.) may be included.
[0384] In the above embodiment, the present invention is realized by a client-server system, but the present invention is not limited to this. As described above, the present invention may be realized by a system such as a distributed system that provides the terminal 20 with the functions of a server or server system. As an example, the process described in the flowchart of the above embodiment as being performed by a server or server system may be performed by a terminal.
[0385] As described above, the contents described in the above embodiments, the modifications, other embodiments, and the like can be applied in combination with each other. [Explanation of symbols]
[0386] 1. Communication Systems 10 Server 20 Terminals 30 Network
Claims
1. A program executed by a server in communication with a first terminal of a first user, transmitting information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user by a communication unit of the server; The server executes the process of transmitting information on a first amount, out of multiple amounts set to be remitted to the first user, to the second terminal via the communication unit based on the second user's input regarding the remittance request information.
2. The program according to claim 1, The server executes the process of transmitting information on a second amount, out of multiple set amounts to be remitted to the first user, to the third terminal via the communication unit based on the third user's input regarding the remittance request information.
3. The program according to claim 1 or 2, Each of the multiple amounts to be remitted to the first user is determined based on a total amount of the remittance request input by the first user.
4. The program according to claim 3, Each of the multiple amounts to be remitted to the first user is determined by an input by the first user.
5. The program according to claim 3, Each of the multiple amounts to be remitted to the first user is set randomly based on the total amount of the remittance request.
6. The program according to any one of claims 1 to 5, When the second user has made a first setting, the server executes the process of transmitting information of the set third amount to the second terminal via the communication unit instead of the first amount.
7. The program according to claim 6, the first setting is a setting for remittance of an equal amount based on a total amount of the remittance request of the first user, The third amount is the equal amount.
8. The program according to any one of claims 1 to 7, The first amount based on the information of the first amount is the equal amount if the second user selects an equal amount based on the total amount of the first user's remittance request.
9. The program according to claim 8, The multiple set amounts to be remitted to the first user are reset when the second user selects the equal amount based on the total amount of the remittance requests of the first user.
10. The program according to claim 9, The server controls a control unit of the server to transmit information on the reset amount to be remitted to the first user to the third terminal.
11. The program according to any one of claims 1 to 10, the input of the second user with respect to the information of the remittance request is an input regarding participation in the remittance request by the first user with respect to the information of the remittance request; The information on the first amount is transmitted to the first terminal based on the server receiving a participation decision from a user to whom the information on the remittance request by the first user was transmitted.
12. The program according to any one of claims 1 to 11, When the third user selects an equal amount based on the total amount of the remittance request of the first user, the server transmits to the first terminal information of a third amount, which is an amount different from the first amount based on the information of the first amount transmitted to the first terminal.
13. The program according to any one of claims 1 to 12, When the second terminal selects, based on the information on the first amount, to transfer a fourth amount, which is an amount greater than the first amount based on the information on the first amount, the server executes the step of transmitting information on the fourth amount based on the fourth amount to the first terminal via the communication unit.
14. The program according to claim 13, The multiple amounts set to be remitted to the first user are reset when the remittance of the fourth amount is selected.
15. The program according to any one of claims 1 to 12, When the second terminal selects, based on the information on the first amount, to transfer a fourth amount, which is greater than the first amount based on the information on the first amount, the server executes the following operation: transmitting, via the communication unit, information on a sixth amount, based on the fourth amount, to the third user of the third terminal to which information on the fifth amount was sent, out of the multiple amounts to be transferred to the first users.
16. 1. An information processing method for a server communicating with a first terminal of a first user, comprising: transmitting information of a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user by a communication unit of the server; The method includes transmitting information on a first amount, out of multiple amounts set to be remitted to the first user, to the second terminal via the communication unit based on the second user's input regarding the remittance request information.
17. A server in communication with a first terminal of a first user, The device includes a communication unit that transmits information about a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user, and transmits information about a first amount, out of multiple amounts set to be remitted to the first user, to the second terminal based on an input by the second user in response to the remittance request information.
18. A system including a first terminal of a first user and a server in communication with the first terminal, a communication unit of the server that transmits information on a remittance request from the first terminal to at least a second terminal of a second user and a third terminal of a third user; a communication unit of the second terminal for receiving the remittance request information, The communication unit of the server transmits information on a first amount, out of multiple amounts set to be remitted to the first user, to the second terminal based on the second user's input in response to the remittance request information.
Citation Information
Patent Citations
Mobile phone
JP2002176671A