Payment management device, payment management method, program, and application program

Abstract

To provide users with a natural user experience. [Solution] A payment management device that provides electronic payment services in cooperation with an application program running on a user terminal device, comprising: a payment processing unit that acquires payment information indicating the details of a payment via communication and performs payment processing; and a proposal decision unit that determines whether or not to have the application program display a proposal for splitting the bill among users based on the payment information, and instructs the application program to display the proposal for splitting the bill according to the decision result.

Description

Technical Field

[0001] The present invention relates to a settlement management device, a settlement management method, a program, and an application program.

Background Art

[0002] An electronic payment service provided by communication between an application program operating on a terminal device such as a smartphone and a payment management device has become widespread. In this electronic payment service, a function for assisting in making settlements among a plurality of users having accounts is provided. For example, in Patent Document 1, based on an input to the terminal by the user of the terminal, first settlement information based on processing related to a first settlement by the user of the terminal is transmitted by the communication unit of the terminal, and based on the first settlement information, at least information on the first amount that the user of the terminal sends or receives and the second amount that the user of a terminal different from the terminal sends or receives, is received by the communication unit, and a remittance process or a receipt process based on the first amount is performed by the control unit of the terminal.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In conventional electronic payment services, a button (or equivalently, a switch, GUI, link, etc.) for proposing a settlement is displayed by default each time a settlement is made by the settlement application, which may make the user feel annoyed and not provide a natural feeling of use. Since a lot of information is displayed on the display screen of the settlement application, it is desirable to avoid displaying unnecessary buttons.

[0005] This invention has been made in consideration of these circumstances, and one of its objectives is to provide a payment management device, payment management method, program, and application program that can give users a natural user experience. [Means for solving the problem]

[0006] One aspect of the present invention is a payment management device that provides electronic payment services in cooperation with an application program operating on a user terminal device, comprising: a payment processing unit that acquires payment information indicating the details of a payment via communication and performs payment processing; and a proposal decision unit that determines whether or not to have the application program display a proposal for splitting the bill among users based on the payment information, and instructs the application program to display the proposal for splitting the bill according to the decision result. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to provide users with a natural user experience. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the basic forms of in-store electronic payment. [Figure 2] This diagram shows an example of a configuration for performing electronic payments (terminal payments) using a payment app. [Figure 3] This figure shows an example of the contents of user information 172. [Figure 4] This diagram shows an example of the contents of merchant / store information 174. [Figure 5] This diagram shows an overview of the processing flow when a user scan is performed. [Figure 6] This diagram shows an overview of the processing flow when a store scan is performed. [Figure 7] This diagram shows an example of a configuration for performing electronic payments (card payments) using payment cards. [Figure 8]This figure shows examples of payment completion notification screens, both with and without a message suggesting splitting the bill. [Figure 9] This figure shows an example of the contents of the target merchant list / threshold information 176. [Figure 10] This flowchart shows an example of the processing flow performed by the payment server 100 of the embodiment. [Figure 11] This figure shows an example of how recommendations are displayed in a group chat based on the history of splitting the bill. [Figure 12] This diagram shows an overview of the process by which the group recommendation unit 150 estimates the preferences of a group that splits the bill. [Figure 13] This figure shows an example of the configuration of the information processing device 300. [Figure 14] This figure shows an example of the contents of history information 372. [Figure 15] This figure shows an example of the contents of historical summary information 374. [Figure 16] This figure compares the estimated number of users and the P2P payment rate (corresponding to R1) with and without applying the correction value Adj(k). [Figure 17] This figure compares the estimated number of users and the percentage of P2P payments received from multiple users (corresponding to R2) with and without applying the correction value Adj(k). [Modes for carrying out the invention]

[0009] [overview] The following describes embodiments of the payment management device, payment management method, program, and application program according to the present invention, with reference to the drawings. The application program, payment server, and credit card server work together to provide electronic payment services. The payment server is an example of a "payment management device." In the following description, the application program will be referred to as a payment app. The payment server and credit card server together may also be referred to as a payment management system. An electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in the real world, but may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the operator of the electronic payment service. In that case, when settling a purchase at a virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and processing such as payment when a purchase is made at a store is mainly carried out between the user and the merchant. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Types of in-store electronic payment methods] FIG. 1 is a diagram showing a basic mode of in-store electronic payment. Basically, electronic payment is executed by three parties: a medium M held by a user U, store equipment E, and a payment system S. The medium M is a portable computer device such as a smartphone or a credit card. The store equipment E exists in a physical store in the real space (hereinafter simply referred to as a store), and includes a POS device, a wireless communication device, a credit card reader, a printed matter of a code image such as a QR code (registered trademark), or a display device for displaying a code image. In in-store electronic payment, first, information such as information that can recognize the user's identification information and payment amount information is shared unidirectionally or bidirectionally between the medium M and the store equipment E. At this time, one of the medium M or the store equipment E optically reads various information from the code image displayed by the other, provides information by NFC (Near Field Communication), or the PAN (Primary Account Number) is read by a credit card reader. Then, one of the medium M or the store equipment E (the side that has acquired information from the other) transmits payment information necessary for payment to the payment system S via the network NW. Note that both the medium M and the store equipment E may transmit information to the payment system S. The payment system S manages various information of the user U and performs electronic payment between the store and the user U in various modes. Electronic payment is performed by one or both of the prepaid method and the postpaid method, or by other methods. In addition, electronic payment may include a so-called online shopping mode executed by both the user's terminal device and the payment system. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like. Each of the various devices that communicate via the network NW that appears hereinafter is assumed to have a communication device such as a network card or a wireless communication module.

[0011] [Configuration (Terminal Payment)] FIG. 2 is a diagram showing an example of a configuration for performing electronic payment (terminal payment) using a payment application. This electronic payment is executed centering around a payment application 20 operating on a user terminal device 10 which is one of the media M, one or more store payment terminals 30 which are one of the store facilities E and one or more store code images 40, a payment server 100 which constitutes a part of the payment system S, and the like. The payment server 100 communicates with the user terminal device 10, the store payment terminals 30, and one or more information terminals 50 via a network NW.

[0012] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as a CPU, and operates to provide an electronic payment service to the user in cooperation with the payment server 100. The payment application 20 is installed in the user terminal device 10 from, for example, an app distribution server (not shown), and controls the camera, the communication device, the touch panel, etc. of the user terminal device 10.

[0013] The store payment terminal 30 is installed in a store, for example. The store payment terminal 30 is a computer device (or an aggregate thereof) having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The store payment terminal 30 includes a so-called POS (Point of Sale) device, and the POS device may have a product price acquisition function and an optical reading function.

[0014] The store code image 40 is placed in the store, and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. Note that the store code image 40 may be displayed by a display placed in the store (which may be a display of a terminal device such as a smartphone or a tablet terminal).

[0015] The information terminal 50 is used by the operator of a merchant that oversees the stores. In the electronic payment service, customers as providers of goods or services are treated as merchants (brands), and have one or more stores under their umbrella. There may also be merchants that operate only one store. The information terminal 50 is a smartphone, tablet, personal computer, etc. The information terminal 50 operates the merchant interface 55. The merchant interface 55 may be a merchant application or a web page displayed by a general-purpose browser. The merchant interface 55 accepts coupon settings etc. from the merchant operator and transmits them to the payment server 100. By executing the merchant interface 55, the information terminal 50 may have the function of displaying a code image corresponding to the store code image 40 or reading a code image displayed by the user terminal device 10 (in the latter case, an optical reading function is required).

[0016] The payment server 100 communicates with the credit card server 200 via a network NW. The payment server 100 includes, for example, a content provision unit 110, an information management unit 120, a payment processing unit 130, a proposal decision unit 140, a group recommendation unit 150, and a storage unit 170. The components other than the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components are LSIs (Large Scale Integrations), ASICs (Application Specific Integrated Circuits), FPGAs (Field-Programmable Graphite Arrays). The program may be implemented by hardware (including circuitry) such as a Gate Array or a GPU (Graphics Processing Unit), or by the collaboration of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into a drive device.

[0017] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device that the payment server 100 can access via the network. The storage unit 170 stores information such as user information 172, merchant / store information 174, and target merchant list / threshold information 176.

[0018] The content provider unit 110, for example, has the functionality of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The content provider unit 110 provides content to the user terminal device 10 in the form of a web page, or provides the user terminal device 10 with parameters necessary for the payment application 20 to render images.

[0019] The information management unit 120 edits, adds, and deletes user information 172 and merchant / store information 174, and manages them. The target merchant list / threshold information 176 is generated and updated by the information processing device 300. This will be described later. The information processing device 300 may be an internal component of the payment server 100, but in the diagram it is shown as a separate device.

[0020] Figure 3 shows an example of the contents of User Information 172. User Information 172 is a collection of information such as User URL, Account ID, Phone Number, Password, Registration Date, Charge Balance, Electronic Money Type, Terminal Payment Method, Card Payment Method, Various History Information, Identity Verification Flag, Name, Address, Date of Birth, Email Address, Bank Account, Postpay Settings, Postpay Conditions Information, Chat Group, Split Payment Group, Split Payment History, Location History, and P2P History, all of which are linked to each other. Hereafter, the instance of a user (electronic payment account) to which this information is linked may be referred to as an account. In the figure, items indicated by "-" indicate that they are not set.

[0021] The user URL is used for transferring funds between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100. The registration date is the date the user registered for the electronic payment service (the date the account was created). The charge balance is information indicating the balance of electronic money set by the user beforehand by sending money to the account. Methods of transfer include depositing money into an ATM (Automatic Teller Machine) of a designated company (bank) and transferring money from a registered bank account. The type of electronic money is information indicating, for example, whether the electronic money can be withdrawn or can only be used for electronic payments. The terminal payment method is setting information indicating whether the user will make an electronic payment using the charge balance (balance payment) or a deferred payment in terminal payments. The card payment method is setting information indicating whether the user will make an electronic payment using the charge balance (balance payment) or a deferred payment in card payments. Various types of transaction history information include charge history, which shows the history of users sending money to electronic payment services in advance to increase their balance, and payment history, which shows the details of each transaction made by the user (date and time, store ID of the store where the purchase was made, merchant ID, payment amount, payment method, etc.).

[0022] The "Verified" flag indicates whether the user has completed identity verification using an identification document. Post-payment becomes available only after identity verification is complete. In the diagram, the user with account ID "002" has not completed identity verification and can only select balance payment as a terminal payment method. The bank account is the account number of a bank account into which funds can be deposited for the electronic payment service. The "Post-payment settings" indicates whether the settings necessary to enable post-payment have been completed. The "Post-payment conditions" information indicates various conditions for post-payment, such as the limit and the amount used in the current month. The "Chat group" is a group of users with whom the user can chat using the group chat function. The "Split bill group" is a group of users who will use the split bill function described later. This information is represented, for example, by the account IDs of other users. Users who will be included in chats and split bills may be registered in any format, not limited to this form. The "Split bill history" is a history of split bills made by the user in question. The "Location history" is a history of the user's location information (for example, acquired at a frequency of about every minute). The user's location information is uploaded to the payment server 100 if the payment app 20 is permitted to use location information. The P2P history is the usage history of the money transfer service included in the electronic payment service. The P2P history includes the history of sending money to other users and the history of receiving money from other users.

[0023] Figure 4 shows an example of the contents of the merchant / store information 174. The merchant / store information 174 includes, for example, a first table 174A in which merchant IDs and store IDs are associated with store URLs, a second table 174B in which merchant names and sales figures (as described above) are associated with merchant IDs, and a third table 174C in which store IDs are associated with store IDs. In addition to this information, the merchant / store information 174 may also include information such as the merchant or store category, store location, and payment patterns.

[0024] The payment processing unit 130 performs various processes for electronic payment. There are two methods for terminal payment, which are described below: the first method (user scan) and the second method (store scan).

[0025] Figure 5 shows an overview of the processing flow when a user scan is performed. First, the user terminal device 10, with the payment application 20 running, reads and decodes the store code image 40 using its optical reading function (S1). The store code image 40 contains information about the store URL. The payment application 20 sends first payment information, including the store URL and the user's account ID, to the payment server 100 (S2). The payment server 100 searches for merchant / store information 174 using the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the payment application 20 on the screen where the merchant name and store name are displayed (S5). Then, the payment application 20 generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6).

[0026] The payment processing unit 130 of the payment server 100 performs electronic payment based on the received second payment information if the "terminal payment method" in the user information 172 of the user is set to "balance payment" (S7-1). At this time, the payment processing unit 130 performs electronic payment by, for example, decreasing the charge balance managed in association with the user ID and increasing the item value of the merchant's sales proceeds. The item value of the merchant's sales proceeds is not used as electronic money itself, for example, but the amount corresponding to the item value of the sales proceeds is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service. On the other hand, if the "terminal payment method" is set to "post-payment", the payment processing unit 130 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S7-2). The credit card server 200 performs electronic payment by adding the payment amount to the user's monthly usage amount based on the received information and deducting the monthly usage amount from the user's bank account after the closing date (S7-3).

[0027] Then, the payment processing unit 130 sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 via the content provision unit 110 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 40 is displayed on a display placed in the store, the store code image 40 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0028] Figure 6 shows an overview of the processing flow when a store scan is performed. First, when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S11). The payment processing unit 130 of the payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image such as a QR code or barcode that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the store payment terminal 30, and the store payment terminal 30 reads and decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the store payment terminal 30 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). Payment amount information is obtained in advance through methods such as barcode scanning or manual entry.

[0029] The payment processing unit 130 of the payment server 100 identifies the user corresponding to the one-time code based on the received information, and if the "terminal payment method" in the user information 172 of that user is set to "balance payment", it performs electronic payment based on the received second payment information (S17-1). The content of the processing at this time is the same as the processing in S7-1 in Figure 5. On the other hand, if the "terminal payment method" is set to "post-payment", the payment server 100 sends the first payment information and the second payment information to the credit card server 200 to request electronic payment (S17-2). The credit card server 200 adds the payment amount to the user's monthly usage amount based on the received information, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date (S17-3).

[0030] Then, the payment processing unit 130 sends a payment completion notification to the payment application 20 via the content provision unit 110 (S18), and the payment application 20 displays a payment completion screen (S19).

[0031] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 will identify the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0032] Furthermore, instead of managing the "post-payment" settlement through the credit card server 200, it may be handled internally by the payment server 100. In this case, the configuration of the payment card 60, credit card server 200, etc., may be omitted.

[0033] The process in Figure 5, "generate second payment information including at least the payment amount and send it to the payment server 100," and the process in Figure 6, "display a code image such as a QR code or barcode generated based on the one-time code," are specific examples of "processes for sending payment information indicating the details of the payment to the payment server 100."

[0034] [Payment Method (Card Payment)] Figure 7 shows an example of a configuration for electronic payment (card payment) using a payment card. This electronic payment is executed around a payment card 60, which is one of the media Ms; a credit processing terminal 70, which is one of the store equipment Es; and a payment server 100 and a credit card server 200, which constitute part of the payment system S. The credit card server 200 communicates with the credit processing terminal 70 via a network NW.

[0035] The credit processing terminal 70 is installed in the store, similar to the store payment terminal 30. The credit processing terminal 70 includes, for example, a credit payment terminal (credit card reader) and a POS device. The credit payment terminal reads the PIN (Personal Identification Number) from the inserted or scanned credit card and verifies it against the PIN entered by the user, or transmits the PAN (Primary Account Number) read from the credit card to the credit card server 200 via the POS device. The POS device works with the credit payment terminal to transmit information such as the payment amount to the credit card server 200. An acquisitioner server may be interposed between the credit processing terminal 70 and the credit card server 200, but for the sake of simplicity, the description of the acquisitioner server will be omitted below. The payment card 60 is, for example, similar in form to a commonly used credit card, with a communication chip embedded in the card base material. The communication chip contains a storage medium that stores the PIN and communicates with an external device via a contactor (or wireless antenna). Alternatively, the payment card 60 may be a magnetic stripe card. Note that the information (messages) transmitted and received when using a credit card includes an authorization message for authentication and a sales message to indicate the payment amount; however, a detailed explanation distinguishing between these will be omitted below.

[0036] The credit card server 200 communicates with the settlement server 100 via a network NW. The credit card server 200 includes, for example, an information management unit 210, a credit interface 220, a settlement distribution unit 230, a credit settlement processing unit 240, and a storage unit 270. Components other than the storage unit 270 are implemented, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted in a drive device. The storage unit 270 stores information such as card user information 272.

[0037] The information management unit 210 edits, adds, and deletes card user information 272 and manages it. Card user information 272 is information that associates, for example, information unique to the user (e.g., PAN), the card payment method, and the user's account ID (used by the payment server 100) with each other. The card payment method is setting information that indicates whether the user will make an electronic payment using their charged balance (balance payment) or a deferred payment in card payments.

[0038] The credit interface 220 determines whether the BIN (Bank Identification Number) in the PAN included in the message received from the credit processing terminal 70 is a code for the company. If it is a code for the company, it passes the message received from the credit processing terminal 70 to the settlement distribution unit 230. If it is not a code for the company, it discards the received message.

[0039] The settlement distribution unit 230 refers to the user's card user information 272 corresponding to the message obtained from the credit interface 220 and determines whether the "card payment method" is set to "post-payment". If the "card payment method" is set to "post-payment", the settlement distribution unit 230 notifies the credit interface 220 of this and passes the message obtained from the credit interface 220 to the credit payment processing unit 240. On the other hand, if the "card payment method" is set to "balance payment", the settlement distribution unit 230 adds the user's account ID to the message obtained from the credit interface 220 and sends it to the settlement server 100 to request electronic payment. The settlement server 100, upon receiving the request for electronic payment, performs the same processing as in S7-1 in Figure 5 and S17-1 in Figure 6.

[0040] The credit interface 220 checks the PAN and expiration date, and verifies whether the cumulative payment amount exceeds the monthly limit. The credit payment processing unit 240 adds the payment amount to the user's monthly usage amount based on the information contained in the message obtained from the payment distribution unit 230, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date.

[0041] [Suggesting splitting the bill] The following describes the processing related to the split-bill proposal by the proposal decision unit 140. As mentioned above, the payment processing unit 130 obtains payment information indicating the details of the payment from the payment application 20 or the store payment terminal 30 via communication and performs the payment processing.

[0042] The proposal decision unit 140 decides whether or not to have the payment app 20 display a message suggesting splitting the bill among users based on the payment information, and instructs the payment app 20 to either display the message suggesting splitting the bill or not, depending on the decision result. For example, if the proposal decision unit 140 decides to have the payment app 20 display a message suggesting splitting the bill, it instructs the payment app 20 to display the message suggesting splitting the bill, and if it decides not to have the payment app 20 display a message suggesting splitting the bill, it instructs the payment app 20 not to display the message suggesting splitting the bill. If instructed to display a message suggesting splitting the bill, the payment app 20 displays a split-the-bill button, for example, on the payment completion notification screen that notifies the completion of the payment, and does not display it if not instructed to do so.

[0043] Alternatively, the default setting may be to hide the split-the-bill button, and the proposal decision unit 140 may, if it decides to have the payment app 20 display a split-the-bill suggestion, instruct the payment app 20 to display the split-the-bill suggestion, or, if it decides not to have the payment app 20 display the split-the-bill suggestion, not give any special instructions. The payment app 20 will not display the split-the-bill button unless specifically instructed. Conversely, the default setting may be to display the split-the-bill button, and the proposal decision unit 140 may, if it decides to have the payment app 20 display a split-the-bill suggestion, not give any special instructions, or, if it decides not to have the payment app 20 display a split-the-bill suggestion, instruct the payment app 20 not to display the split-the-bill button. The payment app 20 will display the split-the-bill button unless specifically instructed.

[0044] Figure 8 shows examples of payment completion notification screens with and without a display suggesting splitting the bill. IM1 is an example of a payment completion notification screen when a display suggesting splitting the bill is shown, and IM2 is an example of a payment completion notification screen when a display suggesting splitting the bill is shown. IM1 has a split-the-bill button B1 that displays the content suggesting splitting the bill. When the split-the-bill button B1 is operated, the user is redirected to their group chat screen, and when the group to split the bill is selected on that screen, a payment request is sent to the other users in the group. The other users then send the money to the user in question, completing the split-the-bill. In IM2, the split-the-bill button B1 is not provided, which prevents users who do not intend to split the bill from feeling annoyed. Also, if the split-the-bill button B1 is operated unintentionally, unnecessary screen transitions will occur, so users need to be careful not to operate it, but in IM2, such caution is unnecessary. Furthermore, because no display is shown, empty space is created on the screen, making it possible to convey additional information.

[0045] The proposal decision unit 140 may, for example, decide not to display a bill-splitting suggestion to the payment app 20 if the merchant involved in the payment is not a specific target merchant. The proposal decision unit 140 may also decide to display a bill-splitting suggestion to the payment app 20 if the payment amount is above a threshold. Furthermore, the proposal decision unit 140 may decide to display a bill-splitting suggestion to the payment app 20 if the payment amount is above a threshold set in advance for each merchant, and not to display a bill-splitting suggestion to the payment app 20 if no threshold is set for the merchant. In the following explanation, it will be assumed that the bill-splitting suggestion will be displayed to the payment app 20 if the payment amount is above a threshold set in advance for each merchant, and that the bill-splitting suggestion will not be displayed to the payment app 20 if no threshold is set for the merchant.

[0046] Figure 9 shows an example of the contents of the target merchant list / threshold information 176. The target merchant list / threshold information 176 is information that associates a threshold for each merchant with the merchant ID (and / or merchant name) of a specific target merchant that is subject to a split-bill proposal. The proposal decision unit 140 decides to have the payment application 20 display a split-bill proposal if the payment amount is equal to or greater than the threshold associated with the merchant involved in the payment, and decides not to display it if it is less than the threshold. The threshold is calculated in advance by the information processing device 300, and the calculation method will be described later.

[0047] Figure 10 is a flowchart showing an example of the processing flow performed by the payment server 100 of the embodiment. The processing in this flowchart starts when payment information for smartphone payment is acquired. First, the payment processing unit 130 performs payment processing based on the payment information (S20). Next, the proposal decision unit 140 acquires the merchant ID and payment amount information from the payment information (S21), searches the target merchant list / threshold information 176 using the acquired merchant ID, and attempts to acquire the threshold corresponding to the merchant (S22).

[0048] Next, the proposal decision unit 140 determines whether the merchant ID is registered in the target merchant list / threshold information 176 (S23). If the merchant ID is not registered in the target merchant list / threshold information 176, it sends a flag to the payment app 20 instructing it not to display the split payment button, along with information and images for displaying the payment completion notification screen, for example (S26).

[0049] If the merchant ID is registered in the target merchant list / threshold information 176, the proposal decision unit 140 determines whether the current payment amount is equal to or greater than the threshold corresponding to the merchant ID (S24). If the current payment amount is less than the threshold corresponding to the merchant ID, the process proceeds to S26.

[0050] If the settlement amount is equal to or greater than the threshold corresponding to the merchant ID, the proposal decision unit 140 sends a flag to the payment app 20 instructing it to display the split payment button, along with information and images for displaying the settlement completion notification screen, for example (S25).

[0051] The target merchant list / threshold information 176 is created by selecting merchants that are relatively often used by multiple people. The threshold for each merchant is set to a value that is considered to indicate a high probability that two or more people used the store. Some merchants tend to be used by one person, while others tend to be used by multiple people, and the threshold for each merchant is set to reflect these tendencies. Therefore, if the payment amount is above the threshold, it is estimated that there is a high probability that the user will split the bill, and displaying the split-the-bill button B1 can improve user convenience. On the other hand, as mentioned above, if the merchant is not registered in the target merchant list / threshold information 176 or if the payment amount is below the threshold, it is considered that there is a low probability that the user will split the bill, and the display of the split-the-bill button B1 can be omitted to achieve the various effects mentioned above. In this way, according to this embodiment, a natural user experience can be provided to the user.

[0052] Here, the conditions for displaying the split-the-bill button B1 in the payment app 20 are not limited to the conditions expressed in the judgment processes of S23 and S24, but may also include the condition that "another user who is a group chat partner, another user who is part of a split-the-bill group, or another user with a history of splitting the bill is within a radius X [m] of the user" at the moment immediately before payment (X is a value of about 1 to several tens). In other words, the proposal decision unit 140 may instruct the payment app 20 to display or not display the split-the-bill button based on the relationship between the user's location information and the location information of other users. This makes it possible to narrow down the display of the split-the-bill button B1 in the payment app 20 to situations where there is a high probability that the user will split the bill, and to process the data more appropriately.

[0053] [When the app is the primary decision-maker] In the above explanation, the decision-making entity that determines whether or not to display the split-the-bill button B1 is the proposal decision unit 140 of the payment server 100. Alternatively, the payment application 20 may perform this determination. In this case, for example, the payment server 100 may periodically distribute information equivalent to the target merchant list / threshold information 176 to the payment application 20, and the payment application 20 may perform the same determination process as the proposal decision unit 140 when it sends payment information to the payment server 100.

[0054] [Ancillary services] The group recommendation unit 150 makes various recommendations related to splitting the bill. For example, based on the bill-splitting history of user information 172, the group recommendation unit 150 estimates the common preferences of the bill-splitting group and recommends participation in the group chat of the bill-splitting group for events that match those preferences. Figure 11 shows an example of recommendations displayed in the group chat frame according to the bill-splitting history. Figure 12 shows an overview of the process by which the group recommendation unit 150 estimates the preferences of the bill-splitting group. For example, the group recommendation unit 150 converts various representative keywords representing the user's preferences (which are set comprehensively) into distributed representation vectors in advance using a method such as word2vec, similarly converts keywords included in the bill-splitting history into distributed representation vectors, and estimates that the representative keywords that are close (similar) to the distributed representation vectors obtained from the bill-splitting history represent the preferences of the bill-splitting group. Then, for example, if a merchant's campaign, which is input and set using the merchant interface 55, includes a representative keyword that represents the preferences of the split-bill group (or if the distributed representation vector obtained from the campaign text is close to the distributed representation vector of the representative keyword), recommendations related to that campaign are displayed to some or all of the payment apps 20 of the multiple users constituting the split-bill group. The group recommendation unit 150 may also recommend information such as events based on general knowledge obtained using a crawler or LLM (Large Language Model). Instead of using a distributed representation vector, the group recommendation unit 150 may estimate preferences based on keyword matches standardized using a thesaurus.

[0055] Furthermore, the group recommendation unit 150 may recommend to users who have permitted the payment app 20 to use their location information that they generate a split-the-bill group based on their location information. The group recommendation unit 150 may also recommend to users that they generate a split-the-bill group if there are multiple users (where Y is a value of several to tens) who have made a payment using an electronic payment service at the same store and have been within a radius Y [m] of a certain distance within a predetermined time since the payment, and this event has occurred multiple times. After the split-the-bill group has been generated, the unit may recommend campaigns and events in the same manner as described above.

[0056] As explained above, the [split-the-bill proposal] can give users a natural and comfortable experience.

[0057] [Information Processing Device] The information processing device 300 will be described below. The information processing device 300 is a device that estimates how many target users among the users of the electronic payment service have used a store, and also sets thresholds to be registered in the target merchant list / threshold information 176. Figure 13 is a diagram showing an example of the configuration of the information processing device 300. The information processing device 300 includes, for example, a first acquisition unit 310, a second acquisition unit 320, a processing unit 330, and a storage unit 370. The processing unit 330 includes a number of people estimation unit 332 and a threshold setting unit 334. Components other than the storage unit 370 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as LSI, ASIC, FPGA, and GPU, or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into a drive device.

[0058] The storage unit 370 can be an HDD, flash memory, RAM, etc. The storage unit 370 may also be a NAS device that can be accessed by the information processing device 300 via a network. The storage unit 370 stores information such as history information 372 and history summary information 374.

[0059] The first acquisition unit 310 acquires history information in the electronic payment service and stores it in the storage unit 370 as history information 372. Figure 14 shows an example of the contents of history information 372. History information 372 includes, for example, a payment history in which the user's account ID, the merchant ID related to the payment, the payment time, and the payment amount are associated with each other, and a P2P history in which the account ID of the receiving user, the account ID of the sending user, the sending user, the sending time, and the sending amount are associated with each other. This information is provided, for example, by editing as appropriate from the user information 172 of the payment server 100. The first acquisition unit 310 acquires history information at a frequency of, for example, once every few months, and the processing unit 330 updates the threshold described later accordingly.

[0060] The second acquisition unit 320 acquires payment information when a target user makes a payment using the electronic payment service. As mentioned above, the payment information includes information on the payment amount and information on the merchant to which the store used belongs (merchant ID). For example, the second acquisition unit 320 acquires the target user's payment information without delay each time the payment server 100 makes a payment.

[0061] The person estimation unit 332 of the processing unit 330 estimates how many target users used the store based on information on the payment amount of the target users, the average payment amount for each merchant obtained from the history information 372, and the correction value for each merchant. The person estimation unit 332 creates a portion of the history summary information 374 based on the history information 372.

[0062] Figure 15 shows an example of the contents of the historical summary information 374. The historical summary information 374 includes, for example, the average payment amount for each merchant and the P2P remittance (receiving) ratio. The number of people estimation unit 332 aggregates the merchant ID and payment amount related to the payment from the historical information 372 to calculate the average payment amount Av(k) for each merchant. k is the merchant identifier. For the purpose of the explanation described later, the correction value Adj(k) and threshold Th(k) are also shown.

[0063] The P2P transfer (receiving) ratio includes a first ratio R1 and a second ratio R2. The first ratio R1 is the percentage of money that a user receives from another user using the transfer service within a predetermined time T (for example, 1 hour to several tens of hours) from the settlement time. The first ratio R1 is expressed by equation (1), and the second ratio R2 is expressed by equation (2).

[0064] R1(k) = (Number of times when merchant k received a payment less than the payment amount from another user within a specified time T after a payment during the observation period: m) / (Number of payments made by merchant k during the observation period: n) ... (1) R2(k) = (The number of times, within a specified time T, that merchant k received payments from multiple other users for amounts less than the payment amount during the observation period: q) / m ... (2)

[0065] The person estimation unit 332 calculates a correction value Adj(k) for each merchant by adding, for example, the first proportion R1 and the second proportion R2. Here, the action of a user who receives money via P2P immediately after payment is an action that is estimated to have a relatively high probability of splitting the bill among multiple users using P2P. This probability is estimated to be even higher if the user receives money from multiple other users. Therefore, the correction value Adj(k) for each merchant is set to a larger value for merchants that tend to be used by multiple people (and as a result, have a higher probability of splitting the bill). Note that the correction value Adj(k) may also be set to a smaller value for merchants that tend to be used by multiple people. In that case, "addition or multiplication" described later can be read as "subtraction or division".

[0066] The person estimation unit 332 then estimates how many target users used the stores of the participating merchants based on a score value Sc obtained by adding or multiplying the value obtained by dividing the payment amount P of the target users by the average payment amount Av(k) of the participating merchants involved in the payment by a correction value Adj(k) for each participating merchant. In the following, the correction value Adj(k) will be added to the "divided value". The score value Sc is expressed by formula (3). For example, the person estimation unit 332 estimates that the integer obtained by rounding the score value Sc indicates how many target users used the stores of the participating merchants. For example, if the score value is less than 1.5, it is 1 person; if it is 1.5 or more and less than 2.5, it is 2 people; and if it is 2.5 or more and less than 3.5, it is 3 people. Here, 1.5 is an example of a "predetermined value".

[0067] Sc = {P / Av(k)} + Adj(k) ... (3)

[0068] Thus, the person estimation unit 332 uses a correction value Adj(k) that corresponds to the characteristics of each member store to estimate the number of people, thereby enabling more accurate estimation of the number of people.

[0069] Here, we will explain why applying the correction value Adj(k) improves estimation accuracy. The average payment amount Av(k) for each merchant is not the average payment amount per user, but rather the average payment amount per transaction regardless of the number of users (because the payment information does not include the "number of users"). Therefore, merchants that tend to be used by multiple people (e.g., hot pot restaurants) will have a relatively larger average payment amount than merchants that tend to be used by one person (e.g., certain coffee shops). Consequently, if the correction value Adj(k) is not applied, the average payment amount Av(k) is in the denominator of equation (3), which introduces a bias that makes merchants that tend to be used by multiple people appear to have a relatively smaller number of users. The correction value Adj(k) works to counteract this bias, allowing for a more accurate estimation of the number of users. Figure 16 compares the estimated number of users and the P2P payment ratio (corresponding to R1) with and without applying the correction value Adj(k). Figure 17 compares the estimated number of users and the P2P payment rate from multiple users (corresponding to R2) with and without applying the correction value Adj(k). It can be seen that when the correction value Adj(k) is applied, the correlation between the estimated number of users and the P2P payment rate is higher compared to when it is not applied, indicating improved accuracy.

[0070] The threshold setting unit 334 of the processing unit 330 determines a threshold Th(k) for each merchant to estimate that two or more target users used the store, based on the average payment amount Av(k) for each merchant and the correction value Adj(k) for each merchant in the history summary information 374 created based on the history information 372. This threshold Th(k) is registered in the target merchant list / threshold information 176 and used by the payment server 100. As mentioned above, the threshold Th(k) is a value that is compared with the payment amount of the electronic payment service. The method for setting the correction value Adj(k) is as described above.

[0071] The threshold setting unit 334 sets the threshold Th(k) for each merchant so that the score value Sc, obtained by adding or multiplying the value obtained by dividing the threshold Th(k) by the average payment amount Av(k) by a correction value Adj(k), becomes a predetermined value. The predetermined value is set to 1.5, for example, the same as the number of people estimation unit 332. With this setting, the event that "the payment amount is equal to or greater than the threshold Th(k)" becomes equivalent to "if the number of people estimation unit 332 were to estimate the number of users, it would be estimated to be 2 or more."

[0072] For example, for merchant k with merchant ID "2716" in Figure 15, the threshold Th(k) is set to 6142 yen. The correction value Adj(k) for this merchant k is 0.22. If a user were to use this merchant k's store and make a payment of 6142 yen, the person estimation unit 332 would perform the calculation (6142 / 4798) + 0.22 = 1.5 and round it to output an estimated result of 2 people. In this way, the threshold Th(k) is set to a value that reflects the characteristics of each merchant while estimating that the number of users is just under 2. This enables highly accurate estimation and maintains the validity of the split-the-bill suggestion in the payment server 100.

[0073] Here, the threshold setting unit 334 may set a threshold for all merchants included in the history information 372, but it may also narrow down the processing to merchants with a high probability of splitting the bill and not set a threshold for merchants with a low probability of splitting the bill (i.e., not include them in the target merchant list / threshold information 176). However, for merchants with a very large number of transactions, a threshold may be set even if the probability of splitting the bill is low. For example, the threshold setting unit 334 may rank the merchants in descending order of correction value Adj(k) and narrow down the processing to a predetermined number of merchants from the top.

[0074] According to the [information processing device] described above, it is possible to perform more accurate processing related to estimating the number of people at various affiliated stores.

[0075] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of Symbols]

[0076] E. Store facilities M medium S Payment System 10. User terminal device 20 Payment Apps 30 Store Payment Terminals 40 Store Code Images 100 Payment Servers 130 Payment Processing Unit 140 Proposal Decision Department 150 Group Recommendation Department 176 List of Participating Merchants / Threshold Information 300 Information Processing Devices 310 First acquisition part 320 Second Acquisition Department 330 Processing Unit 370 Storage section 372 History Information 374 Historical Summary Information

Claims

1. A payment management device that provides electronic payment services in cooperation with an application program running on a user terminal device, A payment processing unit that obtains payment information indicating the details of the payment via communication and performs payment processing, A proposal decision unit determines whether or not to have the application program display a proposal for splitting the bill among users based on the payment information, and instructs the application program to display the proposal for splitting the bill according to the decision result, A payment management device equipped with the following features.

2. The aforementioned proposal decision unit, If it is decided to have the application program display the aforementioned proposal for splitting the bill, the system instructs the application program to display the aforementioned proposal for splitting the bill. The settlement management device according to claim 1.

3. The aforementioned payment information includes information about the merchant from which the user purchases goods or services at the store. The proposal decision unit decides not to allow the application program to display the proposal for splitting the bill if the merchant is not a specific target merchant. The payment management device according to claim 1 or 2.

4. The aforementioned payment information includes information on the payment amount. The proposal decision unit determines, if the settlement amount is above a threshold, to cause the application program to display a proposal for splitting the bill. The payment management device according to claim 1 or 2.

5. The aforementioned payment information includes information about the merchant where the user purchases goods or services at the store, and information about the payment amount. The proposal decision unit determines that if the settlement amount is equal to or greater than a threshold set in advance for each merchant, it will cause the application program to display a proposal for splitting the bill. The payment management device according to claim 1 or 2.

6. The proposal decision unit decides not to allow the application program to display the proposal for splitting the bill if the threshold is not set for the member store. The settlement management device according to claim 5.

7. The proposal decision unit further instructs the application program to display a proposal for splitting the bill based on the relationship between the user's location information and the location information of other users. The payment management device according to claim 1 or 2.

8. The system further includes a group recommendation unit that estimates the preferences of a bill-splitting group, which includes multiple pre-configured users, and recommends events or campaigns that match the estimated preferences to some or all of the users. The payment management device according to claim 1 or 2.

9. It further includes a group recommendation section that recommends the creation of split-the-bill groups based on the payment history and location information of multiple users. The payment management device according to claim 1 or 2.

10. A payment management device that provides electronic payment services in cooperation with an application program running on a user terminal device, The system obtains payment information indicating the details of the payment via communication and performs the payment processing. Based on the payment information, the system determines whether or not to have the application program display a message suggesting splitting the bill among the users, and instructs the application program to display the message suggesting splitting the bill according to the result of the determination. Payment management methods.

11. The processor of the payment management device that provides electronic payment services in cooperation with the application program running on the user terminal device, The process involves obtaining payment information that indicates the details of the payment via communication and performing the payment processing. Based on the payment information, the system determines whether or not to have the application program display a message suggesting splitting the bill among the users, and instructs the application program to display the message suggesting splitting the bill according to the result of the decision. A program to execute.

12. An application program that operates on a user terminal device and cooperates with a payment management device to provide electronic payment services, The user terminal device, A process for transmitting payment information indicating the details of the payment to the aforementioned payment management device, The process involves obtaining information from the payment management device indicating the decision result of whether or not to display a message suggesting splitting the bill among users based on the payment information, and then, according to the decision result, performing the display suggesting splitting the bill. An application program to execute [something].

13. An application program that operates on a user terminal device and cooperates with a payment management device to provide electronic payment services, The user terminal device, A process of obtaining payment information indicating the details of a payment through user input or from the payment management device, The process involves determining whether or not to display a message suggesting splitting the bill among users based on the aforementioned payment information, and then, depending on the result of that decision, executing the process of displaying the aforementioned message suggesting splitting the bill. An application program to execute [something].

Images