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

Abstract

To give users a natural feeling of use. [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 the payment via communication and performs payment processing; and a proposal decision unit that decides whether or not to have the application program display a suggestion to split the bill between users based on the payment information, and instructs the application program to display the suggestion to split the bill depending on the decision result.

Description

[Technical Field]

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

[0002] Electronic payment services provided by communication between an application program running on a terminal device such as a smartphone and a payment management device have become widespread. These electronic payment services offer a function that helps users split the bill among multiple users who hold accounts. For example, Patent Document 1 describes a system in which, based on input from a user of a terminal to the terminal, a communication unit of the terminal transmits first payment information based on a process related to a first payment by the user of the terminal; the communication unit receives information on at least the first amount of a first amount to be remitted or received by the user of the terminal and a second amount to be remitted or received by a user of a terminal different from the terminal, based on the first payment information; and a control unit of the terminal performs a remittance process or a receipt process based on the first amount. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2021-101337 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional electronic payment services, depending on the payment app, a button (in other words, a switch, GUI, link, etc.) suggesting splitting the bill is displayed by default every time a payment is made, which can be irritating to users and can result in an unnatural user experience. Furthermore, because a lot of information is displayed on the display screen of a payment app, it is desirable to avoid displaying unnecessary buttons.

[0005] The present invention has been made in consideration of these circumstances, and one of its objectives is to provide a payment management device, a payment management method, a program, and an application program that can give users a natural feel when using the device. [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 running on a user terminal device, and is equipped with a payment processing unit that acquires payment information indicating the details of the payment via communication and performs payment processing, and a proposal determination unit that decides whether or not to cause the application program to display a display suggesting splitting the bill between users based on the payment information, and instructs the application program to display the display suggesting splitting the bill based on the decision result. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to provide a user with a natural feeling when using the device. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates basic aspects of brick-and-mortar electronic payment. [Figure 2] FIG. 1 is a diagram illustrating an example of a configuration for performing electronic payment (terminal payment) using a payment application. [Figure 3] FIG. 10 is a diagram showing an example of the contents of user information 172. [Figure 4] FIG. 10 is a diagram showing an example of the contents of affiliated store / shop information 174. [Figure 5] FIG. 10 is a diagram showing an outline of a processing flow when a user scan is performed. [Figure 6] FIG. 10 is a diagram showing an outline of the processing flow when a store scan is performed. [Figure 7] FIG. 1 is a diagram showing an example of a configuration for performing electronic payment (card payment) using a payment card. [Figure 8]10A and 10B are diagrams illustrating examples of payment completion notification screens in which a proposal to split the bill is displayed and in which a proposal to split the bill is not displayed. [Figure 9] FIG. 10 is a diagram showing an example of the contents of target affiliated store list / threshold information 176. [Figure 10] 10 is a flowchart showing an example of the flow of processing executed by the payment server 100 of the embodiment. [Figure 11] FIG. 10 is a diagram showing an example of recommendations displayed in a group chat frame based on a bill splitting history. [Figure 12] FIG. 10 is a diagram illustrating an outline of a process in which the group recommendation unit 150 estimates the preferences of a group that splits the bill. [Figure 13] FIG. 2 is a diagram illustrating an example of the configuration of an information processing device 300. [Figure 14] FIG. 10 is a diagram showing an example of the contents of history information 372. [Figure 15] FIG. 10 is a diagram showing an example of the contents of history compilation information 374. [Figure 16] This is a diagram comparing the estimated number of users and the P2P receipt rate (corresponding to R1) when the correction value Adj(k) is applied and when it is not. [Figure 17] This figure compares the estimated number of users and the P2P receipt ratio (equivalent to R2) from multiple users when the correction value Adj(k) is applied and when it is not. DETAILED DESCRIPTION OF THE INVENTION

[0009] [overview] Hereinafter, with reference to the drawings, embodiments of a payment management device, a payment management method, a program, and an application program according to the present invention will be described. The application program, a payment server, and a credit card server cooperate to provide an electronic payment service. 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 combination of the payment server and the credit card server may also be referred to as a payment management system. An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store may be, for example, a physical store (real-world store) existing in real space, but may also include a virtual store for e-commerce transactions. Virtual stores may also include those operated by entities other than the operator of the electronic payment service. In such cases, when making a payment for a purchase at a virtual store, the user is controlled to transition to an interface screen for the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and when a purchase is made at a store, processing such as payment is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be conducted between the user and the store.

[0010] [Electronic payment methods at brick-and-mortar stores] FIG. 1 illustrates the basic aspects of brick-and-mortar electronic payments. Electronic payments are generally carried out by three parties: a medium M held by a user U, store equipment E, and a payment system S. The medium M may be a portable computer device such as a smartphone or a credit card. The store equipment E resides in a physical store (hereinafter simply referred to as the store) in real space and may include a POS device, a wireless communication device, a credit card reader, a printed code image such as a QR Code (registered trademark), or a display device displaying the code image. In brick-and-mortar electronic payments, information that can identify the user and information about the payment amount are first shared unidirectionally or bidirectionally between the medium M and the store equipment E. At this time, either the medium M or the store equipment E optically reads various information from a code image displayed by the other, provides information via near-field communication (NFC), or reads the PAN (primary account number) using a credit card reader. Then, either the medium M or the store equipment E (the party that obtains information from the other) transmits the payment information required for the payment to the payment system S via a network NW. Both the medium M and the store equipment E may send some information to the payment system S. The payment system S manages various information about the user U and performs electronic payments between the store and the user U in various ways. Electronic payments are performed using either or both of a prepaid system and a postpaid system, or by other methods. In addition, electronic payments may also include so-called online shopping, which is performed between 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, etc. The various devices that communicate via the network NW, which will be described below, are assumed to have communication devices such as network cards and wireless communication modules.

[0011] [Configuration (Terminal Payment)] 2 is a diagram showing an example of the configuration for performing electronic payment (terminal payment) using a payment app. This electronic payment is performed mainly by a payment app 20 running on a user terminal device 10, which is one of the media M, one or more store payment terminals 30 and one or more store code images 40, which are one of the store facilities E, and a payment server 100, which constitutes part of a payment system S. The payment server 100 communicates with the user terminal device 10, the store payment terminal 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 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 acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment application 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment application 20 is installed in the user terminal device 10 from, for example, an application distribution server (not shown), and controls the camera, communication device, touch panel, etc. of the user terminal device 10.

[0013] The store payment terminal 30 is installed, for example, in a store. The store payment terminal 30 is a computer device (or a collection of these) that has 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 a store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 40 may be displayed on a display placed in the store (or on a display of a terminal device such as a smartphone or tablet terminal).

[0015] The information terminal 50 is used by the operator of the affiliated store who oversees the stores. In electronic payment services, customers who provide goods or services are treated as affiliated stores (brands), and one or more stores exist under the affiliated store. An affiliated store may operate only one store. The information terminal 50 is a smartphone, tablet terminal, personal computer, etc. An affiliated store interface 55 runs on the information terminal 50. The affiliated store interface 55 may be an affiliated store app or a web page displayed by a general-purpose browser. The affiliated store interface 55 accepts coupon settings and the like from the affiliated store operator and transmits them to the payment server 100. By executing the affiliated store 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 provider 110, an information manager 120, a payment processor 130, a proposal determiner 140, a group recommender 150, and a memory 170. The components other than the memory 170 are realized by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented using a large scale integration (LSI), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like. The program may be realized by hardware (including circuitry) such as a Gate Array (GPU) or a Graphics Processing Unit (GPU), or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transitory storage medium) such as a hard disk drive (HDD) or flash memory, or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

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

[0018] The content providing unit 110 has, for example, a function 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 providing unit 110 provides the content to the user terminal device 10 in the form of a web page, and provides the user terminal device 10 with parameters required for the payment application 20 to render an image.

[0019] The information management unit 120 manages user information 172 and affiliated store / shop information 174 by editing, adding, deleting, etc. The target affiliated store list / threshold information 176 is generated and updated by the information processing device 300, as will be described later. The information processing device 300 may be an internal component of the payment server 100, but is shown in the figure as a separate device.

[0020] 3 is a diagram showing an example of the contents of user information 172. User information 172 is information in which, for example, 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, deferred payment settings, deferred payment condition information, chat group, split payment group, split payment history, location information history, P2P history, and other information are associated with each other. Hereinafter, a user instance (electronic payment account) with this information associated therewith may be referred to as an account. In the figure, items marked with "-" indicate that they are not set.

[0021] The user URL is used for remittance processing 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 on which the user registered for the electronic payment service (the date on which the account was created). The charge balance is information indicating the balance of electronic money that the user has set by transferring money to the account in advance. Remittance methods include depositing money into an ATM (Automatic Teller Machine) of a designated service provider (bank) or 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 electronic payment using the charge balance (balance payment) or by deferred payment in terminal payment. The card payment method is setting information indicating whether the user will make electronic payment using the charge balance (balance payment) or by deferred payment in card payment. The various historical information includes charge history, which is a record of the user transferring money to the electronic payment service in advance to increase the charge balance, and payment history, which shows the details of the payments made by the user for each payment (date and time, store ID of the store where the purchase was made, affiliated store ID, payment amount, payment method, etc.).

[0022] The identity verification flag indicates whether the user has completed identity verification using an ID document. Deferred payment is selectable only after identity verification has been completed. The user with account ID "002" in the figure has not completed identity verification, and therefore can only select balance payment as the terminal payment method. The bank account is the account number of a bank account that can be used to deposit funds into the electronic payment service. Deferred payment settings indicate whether the settings required to select deferred payment have been completed. Deferred payment condition information indicates various conditions, such as the deferred payment limit and the current month's usage amount. A chat group is a group of users with whom a user chats using the group chat function. A split-bill group is a group of users who are eligible to use the split-bill function, described below. This information is represented, for example, by the account IDs of other users. Users eligible for chat or split-bill registration may be registered in any format. Split-bill history is a history of the user's split-bill transactions. Location information history is a history of the user's location information (obtained, for example, approximately every minute). The user's location information is uploaded to the payment server 100 when the payment application 20 is permitted to use the location information. The P2P history is a usage history of the remittance service included in the electronic payment service. The P2P history includes a history of remittances to other users and a history of receipts from other users.

[0023] 4 is a diagram showing an example of the contents of affiliated store / store information 174. The affiliated store / store information 174 includes, for example, a first table 174A in which an affiliated store ID and a store ID are associated with a store URL, a second table 174B in which an affiliated store ID is associated with an affiliated store name and sales amount (described above), and a third table 174C in which a store ID is associated with a store ID. In addition to this information, the affiliated store / store information 174 may also include information such as the category of the affiliated store or store, the store's location, and payment patterns.

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

[0025] FIG. 5 shows an overview of the process 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 store URL information. 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 the affiliated store / store information 174 using the affiliated store ID and store ID corresponding to the store URL, acquires information about the affiliated store name and store name (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the payment application 20 on the screen displaying the affiliated store name and store name (S5). The payment application 20 then generates second payment information including at least the payment amount and sends it to the payment server 100 (S6).

[0026] If the "Terminal Payment Method" in the user information 172 of the user is set to "Balance Payment," the payment processing unit 130 of the payment server 100 performs electronic payment based on the received second payment information (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 affiliated store's sales proceeds. The item value of the affiliated store's sales proceeds is not used as electronic money itself, for example, but rather the amount corresponding to the item value of the sales proceeds is transferred to a bank account in a cycle determined by an agreement between the affiliated store and the electronic payment service. On the other hand, if the "Terminal Payment Method" is set to "Deferred Payment," the payment processing unit 130 transmits 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 notice (information for displaying a payment completion screen) to the payment app 20 via the content providing unit 110 (S8), and the payment app 20 displays the payment completion screen (S9). When the store code image 40 is displayed on a display installed in the store, the store code image 40 may include information on the payment amount in addition to the store URL. In this case, the procedure for the user to input the payment amount is omitted, and the information on the payment amount is included in the first payment information and sent to the payment server 100. Information on the affiliated store name and store name may be included and displayed on the payment completion screen.

[0028] FIG. 6 is a diagram showing 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 using the payment app 20, when an automatic update timing (e.g., every minute) occurs, and at other timings, the payment app 20 sends a request to issue a one-time code to the payment server 100 (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, generated based on the one-time code (S14). The user holds (presents) 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 to obtain the one-time code, etc. (S15). The store payment terminal 30 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode or manually entering it.

[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 the user is set to "balance payment," it performs electronic payment based on the received second payment information (S17-1). The processing content at this time is the same as the processing of S7-1 in FIG. 5. On the other hand, if the "terminal payment method" is set to "post-payment," the payment server 100 transmits 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 transmits a payment completion notification to the payment application 20 via the content providing unit 110 (S18), and the payment application 20 displays a payment completion screen (S19).

[0031] Note that electronic payment may be performed using only one of the above patterns. Furthermore, the "account ID" described in FIG. 2 may be other information (e.g., a phone number) that can be used as user identification information. Furthermore, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0032] It should be noted that the "post-payment" settlement may be performed within the settlement server 100, rather than being managed by the credit card server 200. In this case, the components such as the settlement card 60 and the credit card server 200 may be omitted.

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

[0034] [Configuration (Card Payment)] 7 is a diagram showing an example of a configuration for performing electronic payment (card payment) using a payment card. This electronic payment is performed mainly using a payment card 60, which is one of the media M, a credit card processing terminal 70, which is one of the store facilities E, a payment server 100, which constitutes part of a payment system S, and a credit card server 200. The credit card server 200 communicates with the credit card processing terminal 70 via a network NW.

[0035] The credit processing terminal 70 is installed in the store, similar to the in-store payment terminal 30. The credit processing terminal 70 includes, for example, a credit card reader and a POS device. The credit card terminal reads a personal identification number (PIN) from an inserted or held-up credit card and compares it with the PIN entered by the user. It also transmits a primary account number (PAN) read from the credit card to the credit card server 200 via the POS device. The POS device cooperates with the credit card terminal to transmit information such as the payment amount to the credit card server 200. A payment agent (acquirer) server may be interposed between the credit card processing terminal 70 and the credit card server 200; however, for simplicity, the following description omits the server. The payment card 60 is, for example, similar to a commonly used credit card, with a communication chip embedded in the card substrate. The communication chip incorporates a storage medium storing the PIN and communicates with an external device via a contactor (or a wireless antenna). Alternatively, the payment card 60 may be a magnetic card. The information (messages) sent and received when using a credit card include an authorization message for authentication and a sales message for conveying the payment amount, but detailed explanations distinguishing between these will be omitted below.

[0036] The credit card server 200 communicates with the payment server 100 via a network NW. The credit card server 200 includes, for example, an information management unit 210, a credit interface 220, a payment allocation unit 230, a credit payment processing unit 240, and a memory unit 270. The components other than the memory unit 270 are implemented by, for example, 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 may be implemented by a combination 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-transitory storage medium), or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device. The memory unit 270 stores information such as card user information 272.

[0037] The information management unit 210 edits, adds, deletes, etc., and manages the card user information 272. The card user information 272 is information in which, for example, information unique to a user (e.g., PAN), a card payment method, and the user's account ID (used by the payment server 100) are associated with one another. The card payment method is setting information that indicates whether the user will make electronic payment using the charged balance (balance payment) or deferred payment when making a card payment.

[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, and if it is a code for the company, passes the message received from the credit processing terminal 70 to the payment allocation unit 230, and if it is not a code for the company, discards the received message.

[0039] The payment allocating unit 230 refers to the card user information 272 of the user 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 payment allocating 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 payment allocating unit 230 adds the user's account ID to the message obtained from the credit interface 220 and sends it to the payment server 100, requesting electronic payment. When requested to make electronic payment, the payment server 100 performs the same processes as 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 current month's upper limit, etc. 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 allocation unit 230, and performs electronic payment by deducting the monthly usage amount from the user's bank account after the closing date.

[0041] [Split the bill proposal] The following describes the processing related to the split payment proposal performed by the proposal determination unit 140. As described above, the payment processing unit 130 acquires payment information indicating the details of the payment from the payment application 20 or the store payment terminal 30 via communication, and performs payment processing.

[0042] The proposal determination unit 140 determines whether or not to cause the payment app 20 to display a suggestion to split the bill between users based on the payment information, and instructs the payment app 20 to display or not display a suggestion to split the bill depending on the result of the determination. For example, if the proposal determination unit 140 determines that the payment app 20 should display a suggestion to split the bill, it instructs the payment app 20 to display a suggestion to split the bill, and if it determines that the payment app 20 should not display a suggestion to split the bill, it instructs the payment app 20 not to display a suggestion to split the bill. If instructed to display a suggestion to split the bill, the payment app 20 displays a "Split the Bill" button on a payment completion notification screen that notifies users that the payment has been completed, for example, but does not display this button if no instruction is given.

[0043] Alternatively, hiding the Split Bill button may be treated as a default setting, and if the proposal decision unit 140 decides to have the payment app 20 display a suggestion to split the bill, it may instruct the payment app 20 to display a suggestion to split the bill, and if it decides not to have the payment app 20 display a suggestion to split the bill, it may not give any special instruction. The payment app 20 does not display the Split Bill button unless a special instruction is given. Conversely, if the display of the Split Bill button is treated as a default setting, and the proposal decision unit 140 decides to have the payment app 20 display a suggestion to split the bill, it may not give any special instruction, and if it decides not to have the payment app 20 display a suggestion to split the bill, it may instruct not to display the Split Bill button. The payment app 20 will display the Split Bill button unless a special instruction is given.

[0044] FIG. 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 with a display suggesting splitting the bill, and IM2 is an example of a payment completion notification screen with a display suggesting splitting the bill. IM1 includes a Split the Bill button B1 displaying the splitting proposal. Operating the Split the Bill button B1 transitions to the user's group chat screen. When a group to split the bill is selected on that screen, a remittance request is sent to the other users in the group. The other users then remit money to the user, completing the split. IM2 does not include the Split the Bill button B1, which prevents users who do not intend to split the bill from feeling annoyed. Furthermore, accidentally operating the Split the Bill button B1 results in unnecessary screen transitions, so users need to be careful not to operate it. However, this is not necessary with IM2. Furthermore, by not displaying the button B1, free space is created on the screen, allowing for additional information to be conveyed.

[0045] For example, the proposal determination unit 140 determines not to cause the payment app 20 to display a suggestion to split the bill when the affiliated store related to the payment is not a specific target affiliated store. The proposal determination unit 140 may also determine to cause the payment app 20 to display a suggestion to split the bill when the payment amount is equal to or greater than a threshold. The proposal determination unit 140 may also determine to cause the payment app 20 to display a suggestion to split the bill when the payment amount is equal to or greater than a threshold set in advance for each affiliated store, and may determine not to cause the payment app 20 to display a suggestion to split the bill when no threshold is set for the affiliated store. In the following description, it is assumed that the payment app 20 displays a suggestion to split the bill when the payment amount is equal to or greater than a threshold set in advance for each affiliated store, and does not cause the payment app 20 to display a suggestion to split the bill when no threshold is set for the affiliated store.

[0046] FIG. 9 is a diagram showing an example of the contents of eligible affiliated store list / threshold information 176. Eligible affiliated store list / threshold information 176 is information in which a threshold value for each eligible affiliated store is associated with the affiliated store ID (and / or affiliated store name) of a specific eligible affiliated store that is eligible for split-the-bill proposals. Proposal determination unit 140 determines that payment app 20 should display a split-the-bill proposal if the payment amount is equal to or greater than the threshold value associated with the affiliated store related to the payment, and determines not to display the proposal if the payment amount is less than the threshold value. The threshold value is calculated in advance by information processing device 300, and the calculation method will be described later.

[0047] FIG. 10 is a flowchart showing an example of the flow of processing executed by the payment server 100 of an embodiment. The processing of 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 determination unit 140 acquires information on the affiliated store ID and payment amount from the payment information (S21), searches the target affiliated store list / threshold information 176 using the acquired affiliated store ID, and acquires (or attempts to acquire) the threshold corresponding to the affiliated store (S22).

[0048] Next, the proposal determination unit 140 determines whether the affiliated store ID is registered in the target affiliated store list / threshold information 176 (S23). If the affiliated store ID is not registered in the target affiliated store list / threshold information 176, a flag instructing not to display the "Split the Bill" button is sent to the payment application 20 together with, for example, information and an image for displaying a payment completion notification screen (S26).

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

[0050] If the current payment amount is equal to or greater than the threshold corresponding to the affiliated store ID, the proposal determination unit 140 sends a flag instructing the display of a split-the-bill button to the payment application 20 together with, for example, information and images for displaying a payment completion notification screen (S25).

[0051] The target affiliated store list / threshold information 176 is created by selecting affiliated stores associated with stores that are relatively frequently used by multiple people as target affiliated stores. The threshold for each affiliated store is set to a value that is considered to indicate a high probability that two or more users visit the store. Some affiliated stores tend to be used by individuals, while others tend to be used by multiple people. The threshold for each affiliated store is set to reflect this tendency. Therefore, if the payment amount is equal to or greater than the threshold, it is estimated that the user is likely to split the bill. Therefore, displaying the Split Bill button B1 can improve user convenience. On the other hand, as described above, if the affiliated store is not registered in the target affiliated store list / threshold information 176 or the payment amount is less than the threshold, it is estimated that the user is unlikely to split the bill. Therefore, omitting the display of the Split Bill button B1 can achieve the various effects described above. As described above, the embodiment provides a natural user experience.

[0052] Here, the conditions for displaying the Split the Bill button B1 on the payment app 20 are not limited to the conditions expressed by the determination processes of S23 and S24, but may also include "other users who are group chat partners, other users who are in a split the bill group, or other users with a history of splitting the bill being within a radius of X [m] from the user" immediately before the payment (X is a value from 1 to several tens). In other words, the proposal determination unit 140 may instruct the payment app 20 to display / not display the Split the Bill button based on the relationship between the user's location information and the location information of other users. In this way, the Split the Bill button B1 can be displayed on the payment app 20 only in situations where the user is likely to split the bill, allowing for more appropriate processing.

[0053] [When the app is the determining entity] In the above description, the entity that determines whether to display the Split button B1 is the proposal determining unit 140 of the payment server 100. Alternatively, this determination may be made on the payment application 20 side. In this case, for example, the payment server 100 may periodically deliver information equivalent to the eligible affiliated store list / threshold information 176 to the payment application 20, and the payment application 20 may itself perform the same determination process as the proposal determining unit 140 when sending payment information to the payment server 100.

[0054] [Ancillary services] The group recommendation unit 150 makes various recommendations related to split-bill proposals. For example, the group recommendation unit 150 estimates the common preferences of the split-bill group based on the split-bill history in the user information 172, and recommends participation in a group chat for the split-bill group for events that match the preferences. FIG. 11 is a diagram showing an example of recommendations displayed in a group chat frame based on the split-bill history. FIG. 12 is a diagram showing an overview of the process by which the group recommendation unit 150 estimates the preferences of the split-bill group. For example, the group recommendation unit 150 converts various representative keywords (which are comprehensively set) that represent the user preferences into distributed representation vectors using a technique such as word2vec, similarly converts keywords included in the split-bill history into distributed representation vectors, and estimates that the representative keywords that form the basis of the distributed representation vectors that are close (similar) to the distributed representation vector obtained from the split-bill history represent the preferences of the split-bill group. Then, for example, if a campaign of an affiliated store inputted and set using the affiliated store interface 55 includes a representative keyword representing the preferences of the split-bill group (or if the distributed representation vector obtained from the campaign wording is close to the distributed representation vector of the representative keyword), recommendations related to the campaign are displayed in the payment apps 20 of some or all of the multiple users who make up 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 a large language model (LLM). Instead of using a distributed representation vector, the group recommendation unit 150 may estimate preferences based on matching of keywords standardized using a thesaurus.

[0055] Furthermore, the group recommendation unit 150 may recommend to users who have permitted the payment application 20 to use their location information that they create a split-bill group based on the location information. When there are multiple users who have made a payment using an electronic payment service at the same store and who were within a radius of Y [m] (where Y is a value from several to tens) within a predetermined time after the payment, and this event has occurred multiple times, the group recommendation unit 150 may recommend to these users that they create a split-bill group. After the split-bill group has been created, campaigns and events may be recommended in the same manner as described above.

[0056] The above-described "split bill proposal" allows the user to feel at ease when using the service.

[0057] [Information processing device] The information processing device 300 will be described below. The information processing device 300 is a device that estimates the number of target users who have used a store among users of an electronic payment service and also sets a threshold to be registered in the target affiliated store list / threshold information 176. FIG. 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-users estimation unit 332 and a threshold setting unit 334. The 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 an LSI, ASIC, FPGA, or GPU, or by a combination of software and hardware. The program may be stored in advance in a storage device such as a HDD or flash memory (a storage device with a non-transitory storage medium), or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device.

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

[0059] The first acquisition unit 310 acquires history information for the electronic payment service and stores it in the storage unit 370 as history information 372. FIG. 14 is a diagram showing an example of the contents of the history information 372. The history information 372 includes, for example, a payment history in which the user's account ID, the affiliated store ID related to the payment, the payment time, and the payment amount are associated with each other, and a P2P history in which the receiving user's account ID, the sending user's account ID, the remittance time, and the remittance amount are associated with each other. This information is provided, for example, by editing the user information 172 in the payment server 100 as appropriate. The first acquisition unit 310 acquires the history information, 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 the target user makes a payment using an electronic payment service. As described above, the payment information includes information on the payment amount and information on the affiliated store (affiliated store ID) to which the store used belongs. For example, the second acquisition unit 320 acquires the payment information of the target user without delay every time the payment server 100 makes a payment.

[0061] The number of people estimation unit 332 of the processing unit 330 estimates how many people the target user has used the store based on information on the payment amount of the target user, the average payment amount for each affiliated store obtained from the history information 372, and a correction value for each affiliated store. The number of people estimation unit 332 creates a part of the history aggregation information 374 based on the history information 372.

[0062] FIG. 15 is a diagram showing an example of the contents of the history aggregation information 374. The history aggregation information 374 includes, for example, the average payment amount for each affiliated store and the P2P remittance (receive) ratio. The number of users estimation unit 332 aggregates the affiliated store IDs and payment amounts related to payments from the history information 372 to calculate the average payment amount Av(k) for each affiliated store, where k is the identifier of the affiliated store. For the sake of explanation below, the correction value Adj(k) and threshold value Th(k) are also listed.

[0063] The P2P remittance (receive) rate includes a first rate R1 and a second rate R2. The first rate R1 is the rate at which a user receives money from other users using the remittance service within a predetermined time T (e.g., one hour to several tens of hours) from the settlement time. The first rate R1 is expressed by formula (1), and the second rate R2 is expressed by formula (2).

[0064] R1(k) = (number of times that a payment made by merchant k in the observation period has been received from another user within a predetermined time T after the payment made by merchant k in the observation period: m) / (number of payments made by merchant k in the observation period: n) ... (1) R2(k) = (number of times that multiple users received an amount less than the payment amount within a given time T from a payment made at merchant k during the observation period: q) / m…(2)

[0065] The number of customers estimation unit 332, for example, calculates a correction value Adj(k) for each affiliated store by adding the first rate R1 and the second rate R2. Here, the behavior of a user who receives money via P2P immediately after payment is an behavior that is estimated to have a relatively high probability of splitting the bill among multiple users using P2P. If the user receives money from multiple other users, the probability is estimated to be even higher. Therefore, the correction value Adj(k) for each affiliated store can be set to a larger value for affiliated stores that tend to be used by multiple people (and therefore have a higher probability of splitting the bill). Note that the correction value Adj(k) can also be set to a smaller value for affiliated stores that tend to be used by multiple people. In this case, the "addition or multiplication" described below can be read as "subtraction or division."

[0066] The number-of-persons estimation unit 332 then estimates how many target users have visited the affiliated store based on the score Sc, which is calculated by dividing the target user's payment amount P by the affiliated store's average payment amount Av(k) and adding or multiplying the value obtained by dividing the amount by the average payment amount Av(k) of the affiliated store. Hereinafter, the correction value Adj(k) is assumed to be added to the "divided value." The score Sc is expressed by Equation (3). For example, the number-of-persons estimation unit 332 estimates that the integer obtained by rounding the score Sc indicates how many target users have visited the affiliated store. For example, if the score is less than 1.5, it is one person; if it is 1.5 or greater but less than 2.5, it is two people; and if it is 2.5 or greater but less than 3.5, it is three people. Here, 1.5 is an example of a "predetermined value."

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

[0068] In this way, the number of people estimation unit 332 estimates the number of people using the correction value Adj(k) according to the characteristics of each affiliated store, and therefore, it is possible to estimate the number of people more accurately.

[0069] Here, we 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, compared to merchants that tend to be used by single users (e.g., a particular coffee shop), merchants that tend to be used by multiple users (e.g., a hot pot restaurant) will have a relatively larger average payment amount. Therefore, without applying the correction value Adj(k), the average payment amount Av(k) is included in the denominator of equation (3), which results in a biased calculation of the number of users for merchants that tend to be used by multiple users. The correction value Adj(k) counters this bias, allowing for more accurate estimation of the number of users. Figure 16 compares the estimated number of users and the P2P receipt ratio (equivalent to R1) with and without applying the correction value Adj(k). In addition, Figure 17 compares the estimated number of users and the P2P receipt ratio (equivalent to R2) from multiple users when the correction value Adj(k) is applied and when it is not. When the correction value Adj(k) is applied, the correlation between the estimated number of users and the P2P receipt ratio is higher than 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 affiliated store based on the average payment amount Av(k) for each affiliated store in the history aggregation information 374 created based on the history information 372, and the correction value Adj(k) for each affiliated store. This threshold Th(k) is registered in the target affiliated store list / threshold information 176 and used by the payment server 100. As described above, the threshold Th(k) is a value that is compared with the payment amount for 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 affiliated store so that the score value Sc, obtained by dividing the threshold Th(k) by the average payment amount Av(k) and adding or multiplying the correction value Adj(k) to that value, becomes a predetermined value. The predetermined value is set to, for example, 1.5, similar to the number of people estimation unit 332. By setting it in this way, the event that "the payment amount is equal to or greater than the threshold Th(k)" becomes synonymous with "if the number of people estimation unit 332 is asked to estimate the number of users, it is estimated to be two or more."

[0072] For example, for member store k with member store ID "2716" in FIG. 15, the threshold Th(k) is set to 6,142 yen. The correction value Adj(k) for this member store k is 0.22. If a user uses a store at member store k and makes a payment of 6,142 yen, the number of people estimation unit 332 would calculate (6,142 / 4,798) + 0.22 = 1.5, round up, and 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 member store and estimates the number of users to be as close to 2 as possible. This enables highly accurate estimation and maintains the validity of the split-the-bill proposal in the payment server 100.

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

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

[0075] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]

[0076] E. Store Facilities M medium S payment system 10 User terminal device 20. Payment App 30 Store payment terminal device 40 Store code image 100 Payment Server 130 Payment processing unit 140 Proposal Decision Department 150 Group Recommendation Department 176 Targeted merchant list / threshold information 300 Information processing device 310 First acquisition part 320 Second Acquisition Department 330 Processing Section 370 Storage section 372 History Information 374 Historical Aggregation Information

Claims

1. A payment management device that provides an electronic payment service in cooperation with an application program running on a user terminal device, a payment processing unit that acquires payment information indicating the content of the payment through communication and performs payment processing; a proposal determination unit that determines whether or not to cause the application program to display a proposal to split the bill among users based on the payment information, and instructs the application program to display the proposal to split the bill according to the result of the determination; Equipped with The payment information includes information about the affiliated store where the user purchases goods or services and information about the payment amount, the proposal determination unit refers to correspondence information in which a preset threshold value is associated with each of a plurality of member stores, and determines to cause the application program to display the proposal to split the payment when the payment amount is equal to or greater than a threshold value in the correspondence information that corresponds to the member store included in the payment information; Payment management device.

2. The proposal determination unit when it is determined that the application program should display the proposal to split the bill, instructing the application program to display the proposal to split the bill; The payment management device according to claim 1.

3. the proposal determination unit determines not to cause the application program to display the proposal to split the bill if the threshold value has not been set for the affiliated store; 3. The payment management device according to claim 1 or 2.

4. The proposal determination unit further instructs the application program to display a proposal to split the bill when another user who has a specific relationship with the user is within a predetermined range of the user immediately before the settlement, based on the relationship between the user's location information and the location information of the other user.

3. The payment management device according to claim 1 or 2.

5. The system further comprises a group recommendation unit that converts representative keywords representing the preferences of a plurality of users included in a split-bill group into characteristic information in advance, converts keywords included in the split-bill history into characteristic information, estimates that the representative keywords that are the source of characteristic information that is closest to the characteristic information obtained from the split-bill history represent the preferences of the split-bill group, and recommends events or campaigns that match the estimated preferences to some or all of the plurality of users.

3. The payment management device according to claim 1 or 2.

6. The system further includes a group recommendation unit that, based on the payment history and location information of multiple users, recommends the creation of a split-payment group when multiple users make payments using an electronic payment service at the same store and are within a predetermined range within a predetermined time after the payment, and such an event occurs multiple times.

3. The payment management device according to claim 1 or 2.

7. A payment management device that provides an electronic payment service in cooperation with an application program running on a user terminal device, The payment information indicating the details of the payment is acquired through communication, and the payment is processed. determining whether to cause the application program to display a message proposing splitting the bill among users based on the payment information, and instructing the application program to display the message proposing splitting the bill according to the result of the determination; The payment information includes information about the affiliated store where the user purchases goods or services and information about the payment amount, When determining whether to have the application program display the suggestion to split the bill, reference is made to correspondence information in which a preset threshold is associated with each of a plurality of member stores, and if the payment amount is equal to or greater than the threshold in the correspondence information that corresponds to the member store included in the payment information, it is determined that the application program should display the suggestion to split the bill. Payment management methods.

8. a processor of a payment management device that provides an electronic payment service in cooperation with an application program running on a user terminal device, Acquiring payment information indicating the content of the payment through communication and performing payment processing; determining whether to cause the application program to display a message suggesting splitting the bill among users based on the payment information, and instructing the application program to display the message suggesting splitting the bill according to the result of the determination; A program for executing The payment information includes information about the affiliated store where the user purchases goods or services and information about the payment amount, the processor, When determining whether to have the application program display the suggestion to split the bill, reference is made to correspondence information in which a preset threshold value is associated with each of a plurality of member stores, and if the payment amount is equal to or greater than the threshold value in the correspondence information that corresponds to the member store included in the payment information, a decision is made to have the application program display the suggestion to split the bill. program.

9. An application program that operates on a user terminal device and cooperates with a payment management device to provide an electronic payment service, The user terminal device receiving correspondence information from the payment management device in which a preset threshold value is associated with each of a plurality of member stores; A process of acquiring payment information indicating the content of the payment by an input operation of a user or from the payment management device; a process of determining whether to display a message suggesting splitting the bill among users based on the payment information, and then, depending on the result of the determination, executing a process of displaying the message suggesting splitting the bill among users; An application program for executing The payment information includes information about the affiliated store where the user purchases goods or services and information about the payment amount, The user terminal device When determining whether to display the suggestion to split the bill, the correspondence information is referenced, and if the payment amount is equal to or greater than a threshold value in the correspondence information that corresponds to the affiliated store included in the payment information, a decision is made to display the suggestion to split the bill. Application program.

Images