Information processing device, information processing method, and program
By using the information of historical electronic payment services and the average payment amount of each member store in the information processing equipment, combined with the payment information of the target user and the correction value of each member store, the problem of being unable to accurately estimate the number of members' stores in the prior art, and more accurate user number estimation and service support are achieved.
Patent Information
- Application Number
- JP2024166162
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2024-09-25
- Publication Date
- 2025-05-14
- Estimated Expiration
- 2044-09-25
AI Technical Summary
When estimating the number of users of a member store, the prior art fails to effectively reflect the characteristics of each member store, resulting in the inability to accurately estimate or process the process of supporting estimation.
By using the information of historical electronic payment services in the information processing equipment, the average payment amount of each member store is obtained, and the number of members used by the target user is estimated by combining the payment information of the target user and the correction value of each member store.
It has achieved more accurate processing of the number of users in multiple member stores, which can better support the provision of various services.
Smart Images

Figure 0007676646000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to an information processing device, an information processing method, and a 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. In this electronic payment service, the number of users who used a store (the number of users) may not be directly included in the communication. This makes it difficult to provide various services according to the number of users. In relation to this, Patent Document 1 describes a method of estimating the average number of users when a user uses a facility based on the average amount spent when the user uses the facility and the average amount spent at the facility used by the user. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Patent No. 6419263 Summary of the Invention [Problem to be solved by the invention]
[0004] The invention described in Patent Document 1 simply uses the average usage amount and does not reflect correction values according to the characteristics of each affiliated store, so when targeting a variety of affiliated stores, it may not be possible to accurately estimate the number of users or perform processing to support that estimation.
[0005] The present invention has been made in consideration of the above circumstances, and one of its objectives is to provide an information processing device, an information processing method, and a program that can more accurately perform processing related to estimating the number of people at various affiliated stores. [Means for solving the problem]
[0006] One aspect of the present invention is an information processing device comprising: a first acquisition unit that acquires historical information for an electronic payment service, wherein the historical information enables the average payment amount for each affiliated store to which the store used belongs to be recognized; a second acquisition unit that acquires payment information when a target user makes a payment using the electronic payment service, wherein the payment information includes information on the payment amount and information on the affiliated store to which the store used belongs; and a processing unit that estimates how many of the target users used the store based on the payment amount information, the average payment amount for each affiliated store obtained from the historical information, and a correction value for each affiliated store. Effect of the Invention
[0007] According to one aspect of the present invention, processing related to estimating the number of people in various member stores can be performed more accurately. [Brief description of the drawings]
[0008] [Figure 1] FIG. 1 illustrates basic aspects of brick-and-mortar electronic payment. [Diagram 2] FIG. 1 is a diagram showing an example of a configuration for performing electronic payment (terminal payment) using a payment application. [Diagram 3] FIG. 13 is a diagram showing an example of the contents of user information 172. [Figure 4] FIG. 13 is a diagram showing an example of the contents of affiliated store / shop information 174. [Diagram 5] FIG. 13 is a diagram showing an outline of a process flow when a user scan is performed. [Figure 6] FIG. 13 is a diagram showing an overview of the process 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] 13A and 13B 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] 13 is a diagram showing an example of the contents of target affiliated store list / threshold information 176. FIG. [Figure 10] 11 is a flowchart showing an example of a flow of a process executed by the payment server 100 of the embodiment. [Figure 11] FIG. 13 is a diagram showing an example of a recommendation displayed in a group chat frame based on a bill splitting history. [Figure 12] FIG. 13 is a diagram showing an outline of a process in which the group recommendation unit 150 estimates the preferences of a split-the-bill group. [Figure 13] FIG. 2 illustrates an example of the configuration of an information processing device 300. [Figure 14] FIG. 13 is a diagram showing an example of the contents of history information 372. [Figure 15] FIG. 13 is a diagram showing an example of the contents of history compilation information 374. [Figure 16] FIG. 13 is a diagram comparing the estimated number of users and the P2P receipt ratio (corresponding to R1) when the correction value Adj(k) is applied and when it is not applied. [Figure 17] This figure compares the estimated number of users and the P2P receipt ratio (corresponding to R2) from multiple users when the correction value Adj(k) is applied and when it is not. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0009] [overview] Hereinafter, with reference to the drawings, an embodiment of an information processing device, an information processing method, and a program according to the present invention will be described. An application program, a payment server, and a credit card server work together to provide an electronic payment service. The payment server is an example of a "payment management device." In the following description, the application program is referred to as a payment application. In addition, a combination of the payment server and the credit card server may be referred to as a payment management system. An electronic payment service is a service that supports payments related to the purchase of goods and services at a store. A store is, for example, a physical store (real store) that exists in real space, but may also include a virtual store for electronic commerce. The virtual store may include a store provided by an entity different from the operator of the electronic payment service. In that case, when making a payment for shopping at the virtual store, the screen is controlled to transition to an interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and processing such as payment when a purchase is made at a store is mainly performed between the user and the affiliated store. Alternatively, processing such as payment may be performed between the user and the store.
[0010] [Electronic payment methods at brick-and-mortar stores] FIG. 1 is a diagram showing a basic aspect of a brick-and-mortar electronic payment. Basically, electronic payment is performed by three parties: a medium M held by a user U, a store facility E, and a payment system S. The medium M is a portable computer device such as a smartphone, a credit card, etc. The store facility E is present in a physical brick-and-mortar store (hereinafter simply referred to as a store) that exists in real space, and is 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 that displays a code image. In a brick-and-mortar electronic payment, first, information that can recognize the user's identification information and information on the payment amount are shared unidirectionally or bidirectionally between the medium M and the store facility E. At this time, one of the medium M or the store facility E optically reads various information from a code image displayed by the other, information is provided by NFC (Near Field Communication), or a PAN (Primary Account Number) is read by a credit card reader. Then, one of the medium M or the store facility E (the side that acquires information from the other) transmits payment information required for payment to the payment system S via the network NW. Both the medium M and the store equipment E may transmit some 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 ways. Electronic payment is performed by one or both of a prepaid system and postpay, or by other methods. In addition, electronic payment may also include the so-called online shopping mode, which is performed 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, etc. Various devices that communicate via the network NW, which will be described later, 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 a configuration for performing electronic payment (terminal payment) using a payment app. This electronic payment is executed mainly by a payment app 20 that operates on a user terminal device 10 that is one of the media M, one or more store payment terminals 30 and one or more store code images 40 that are one of the store facilities E, a payment server 100 that constitutes a part of a payment system S, and the like. 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 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 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, thereby operating to provide an electronic payment service to a user in cooperation with a payment server 100. The payment application 20 is, for example, installed in the user terminal device 10 from 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) 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 a store and is a code image such as a QR code (registered trademark) printed on a medium such as paper or plastic. 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 manages the stores. In the electronic payment service, a customer who is a provider of goods or services is treated as an affiliated store (brand), and one or more stores exist under the affiliated store. An affiliated store that operates only one store may exist. The information terminal 50 is a smartphone, a tablet terminal, a personal computer, or the like. The information terminal 50 operates an interface 55 for affiliated stores. The interface 55 for affiliated stores may be an app for affiliated stores, or may be a web page displayed by a general-purpose browser. The interface 55 for affiliated stores accepts coupon settings and the like by the operator of the affiliated store and transmits them to the payment server 100. The information terminal 50 may have a function of displaying a code image equivalent to the store code image 40 or reading a code image displayed by the user terminal device 10 by executing the interface 55 for affiliated stores (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 has, for example, a content provider 110, an information manager 120, a payment processor 130, a proposal determiner 140, a group recommendation unit 150, and a memory unit 170. The components other than the memory unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented using LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), 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 having a non-transient storage medium) such as a Hard Disk Drive (HDD) or a flash memory, or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or CD-ROM, and installed in the storage device by mounting the storage medium in a drive device.
[0017] The storage unit 170 is a HDD, a flash memory, a RAM (Random Access Memory), etc. The storage unit 170 may be a NAS (Network Attached Storage) device that the payment server 100 can access 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 in the form of a web page to the user terminal device 10, and provides the parameters required for the payment application 20 to render an image to the user terminal device 10.
[0019] The information management unit 120 manages user information 172 and affiliated store / shop information 174 by editing, adding, deleting, etc. Target affiliated store list / threshold information 176 is generated, updated, etc. by the information processing device 300, which 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 setting, deferred payment condition information, chat group, split payment group, split payment history, location information history, P2P history, etc. are associated with each other. Hereinafter, a user instance (electronic payment account) with which such information is associated 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 the remittance process between users. When registering for the electronic payment service, it is necessary to register a phone number and a password. 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 is set by the user remitting money to the account in advance. Remittance methods include depositing money into an ATM (Automatic Teller Machine) of a designated company (bank) and remittance 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 payment. The terminal payment method is setting information indicating whether the user will make electronic payment using the charge balance (balance payment) or 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 deferred payment in card payment. The various historical information includes charge history, which is a history of when a user has previously transferred funds to an electronic payment service to increase their charge balance, and payment history, which shows the details of 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 is information indicating whether or not the user has completed identity verification using an ID. Postpaid becomes selectable when identity verification has been completed, and since the user with the account ID "002" in the figure has not completed identity verification, only balance payment can be selected as the terminal payment method. The bank account is the account number of a bank account that can be deposited into the electronic payment service. The postpaid setting is information indicating whether or not the setting operation for making postpaid selectable has been completed. The postpaid condition information is information indicating various conditions such as the limit amount for postpaid and the amount used in the current month. The chat group is a group of users with whom the user chats using the group chat function. The split-bill group is a group of users who are targets of the split-bill function described later. These pieces of information are represented, for example, by the account IDs of other users. This form is not limited to this, and users who are targets of chats and split-bills may be registered in any form. The split-bill history is a history of the user's splitting of the bill. The location information history is a history of the user's location information (obtained, for example, at a frequency of about 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 a remittance service included in an 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 name and sales amount (described above) are associated with an affiliated store ID, 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 location of the store, 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 described below.
[0025] FIG. 5 is a diagram showing an outline 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 by using an optical reading function (S1). The store code image 40 includes store URL information. The payment application 20 transmits the 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 the affiliated store name and store name information (S3), and transmits it to the payment application 20 (S4). The user inputs the payment amount to the payment application 20 on the screen displaying the affiliated store name and store name (S5). The payment application 20 then generates the second payment information including at least the payment amount, and transmits 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. The item value of the affiliated store's sales is not used as electronic money itself, for example, but an amount corresponding to the item value of the sales is transferred to a bank account in a cycle according to an agreement between the affiliated store and the electronic payment service. On the other hand, if the "Terminal Payment Method" is set to "Postpaid", 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 monthly usage amount of the user 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 application 20 via the content providing unit 110 (S8), and the payment application 20 displays the payment completion screen (S9). When the store code image 40 is displayed on a display placed in a store, the store code image 40 may include not only the store URL but also information on the payment amount. In this case, the step of the user inputting 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 outline of the process flow when a store scan is performed. First, when the payment application 20 is started, when a payment operation is performed in the payment application 20, when an automatic update timing (for example, every minute) occurs, and at other timings, the payment application 20 transmits a request for issuing 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 transmits it to the payment application 20 (S13). The payment application 20 displays a code image such as a QR code or a 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 by an optical reading function to obtain the one-time code, etc. (S15). Then, the store payment terminal 30 generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and transmits it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a bar code or by manually entering the information.
[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", performs electronic payment based on the received second payment information (S17-1). The content of the process at this time is the same as the process of S7-1 in FIG. 5. On the other hand, if the "Terminal payment method" is set to "Deferred 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, issuance of a one-time code may be omitted in the store scan, 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] Note that the "deferred 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 of “generating second payment information including at least the payment amount and transmitting it to the payment server 100” in FIG. 5 and the process of “displaying a code image such as a QR code or a barcode generated based on the one-time code” in FIG. 6 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 with 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 and a credit card server 200, which constitute a part of a payment system S. 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 store payment terminal 30. The credit processing terminal 70 includes, for example, a credit card payment terminal (credit card reader) and a POS device. The credit card payment terminal reads a PIN (Personal Identification Number) from an inserted or held credit card and collates it with the PIN entered by the user, or transmits a PAN (Primary Account Number) read from the credit card to the credit card server 200 via the POS device. The POS device cooperates with the credit card payment terminal to transmit information such as the payment amount to the credit card server 200. A payment agent server (acquirer) may be interposed between the credit card processing terminal 70 and the credit card server 200, but in the following, the description of the payment agent server will be omitted for the sake of simplicity. The payment card 60 is, for example, of the same type as a commonly used credit card, and has a communication chip embedded in the card substrate. The communication chip has a built-in storage medium that stores 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 (message) sent and received when using a credit card includes 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 the network NW. The credit card server 200 has, for example, an information management unit 210, a credit interface 220, a payment allocation unit 230, a credit payment processing unit 240, and a storage unit 270. The components other than the storage unit 270 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 may be realized by cooperation between software and hardware. The program may be stored in a storage device (storage device having a non-transient storage medium) such as an HDD or flash memory in advance, or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or CD-ROM, and may be installed in the storage device by mounting the storage medium in a drive device. Information such as card user information 272 is stored in the storage unit 270.
[0037] The information management unit 210 manages the card user information 272 by editing, adding, deleting, etc. 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 each other. The card payment method is setting information indicating whether the user will make electronic payment using the charge balance (balance payment) or deferred payment in 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 its own company, and if it is, passes the message received from the credit processing terminal 70 to the payment allocation unit 230, and if it is not a code for its own company, discards the received message.
[0039] The payment allocation unit 230 refers to the card user information 272 of the user corresponding to the message obtained from the credit interface 220, and judges whether the "card payment method" is set to "deferred payment". If the "card payment method" is set to "deferred payment", the payment allocation unit 230 notifies the credit interface 220 of that fact, 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 allocation unit 230 adds the account ID of the user to the message obtained from the credit interface 220 and sends it to the payment server 100 to request electronic payment. The payment server 100 that has been requested to make electronic payment performs the same process as S7-1 in FIG. 5 and S17-1 in FIG. 6.
[0040] The credit interface 220 checks the PAN and expiration date, and checks whether the cumulative payment amount exceeds the upper limit for the current month, 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 proposal by the proposal determining unit 140. As described above, the payment processing unit 130 acquires payment information indicating the content of the payment from the payment application 20 or the store payment terminal 30 via communication, and performs payment processing.
[0042] The proposal decision unit 140 decides whether or not to have the payment app 20 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 decision result. For example, when the proposal decision unit 140 decides to have the payment app 20 display a suggestion to split the bill, it instructs the payment app 20 to display the suggestion to split the bill, and when it decides not to have the payment app 20 display the suggestion to split the bill, it instructs the payment app 20 not to display the suggestion to split the bill. When 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 the completion of payment, for example, and does not display this button if no instruction is given.
[0043] Alternatively, the display of the Split the Bill button is treated as a default setting, and when the proposal decision unit 140 decides to have the payment app 20 display a suggestion to split the bill, it instructs the payment app 20 to display a suggestion to split the bill, and when 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 the Bill button unless there is a special instruction. Conversely, when the display of the Split the Bill button is treated as a default setting, and when 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 when it decides not to have the payment app 20 display a suggestion to split the bill, it may instruct not to display the Split the Bill button. The payment app 20 displays the Split the Bill button unless there is a special instruction.
[0044] FIG. 8 is a diagram showing an example of a payment completion notification screen in the case where a proposal to split the bill is displayed and in the case where a proposal to split the bill is not displayed. IM1 is an example of a payment completion notification screen in the case where a proposal to split the bill is displayed, and IM2 is an example of a payment completion notification screen in the case where a proposal to split the bill is displayed. IM1 is provided with a Split the Bill button B1 on which the content of the proposal to split the bill is displayed. When the Split the Bill button B1 is operated, the screen transitions to the group chat screen of the user, and when a group to split the bill is selected on that screen, a remittance request is sent to the other users who make up the group. In response, the other users remit money to the user, completing the split. Since the Split the Bill button B1 is not provided in IM2, it is possible to prevent users who do not intend to split the bill from feeling annoyed. In addition, if the Split the Bill button B1 is operated unintentionally, an unnecessary screen transition is performed, so the user needs to be careful not to operate it, but such care is not necessary in IM2. Furthermore, since no display is made, a blank space is generated on the screen, so it is possible to convey some additional information.
[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 preset 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 is caused to display a suggestion to split the bill when the payment amount is equal to or greater than a threshold preset for each affiliated store, and is not caused 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 target affiliated store list / threshold information 176. Target affiliated store list / threshold information 176 is information in which a threshold value for each affiliated store is associated with the affiliated store ID (and / or affiliated store name) of a specific target affiliated store that is the subject of the split-the-bill proposal. Proposal decision unit 140 decides to cause payment application 20 to display a proposal to split the bill if the payment amount is equal to or greater than the threshold value associated with the affiliated store related to the payment, and decides 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 the embodiment. The processing of this flowchart is started 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 the affiliated store ID and payment amount information from the payment information (S21), searches the target affiliated store list / threshold information 176 using the acquired affiliated store ID, and acquires (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 or an image for displaying a payment completion notification screen (S26).
[0049] If the affiliated store ID is registered in the target affiliated 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 affiliated store ID (S24). If the current payment amount is less than the threshold corresponding to the affiliated 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 or an image for displaying a payment completion notification screen (S25).
[0051] The target affiliated store list / threshold information 176 is created after selecting affiliated stores related to stores that are relatively often used by multiple people as target affiliated stores. The threshold for each affiliated store is set to a value that is considered to be highly likely to be used by two or more users. There are affiliated stores that tend to be used by one person and those that tend to be used by multiple people, and the threshold for each affiliated store is set to reflect such tendencies. Therefore, when the payment amount is equal to or greater than the threshold, it is estimated that the user is highly likely to split the bill, so that the convenience of the user can be improved by displaying the Split the Bill button B1. On the other hand, as described above, when 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 considered that the user is less likely to split the bill, so that the various effects described above can be achieved by omitting the display of the Split the Bill button B1. In this way, according to the embodiment, it is possible to give the user a natural feeling of use.
[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 judgment processes of S23 and S24, but may further include "other users who are the other party in a group chat, other users who are the other party in a split the bill group, or other users who have a history of splitting the bill being within a radius of X [m] of the user" immediately before the payment (X is a value of about 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, and more appropriate processing can be performed.
[0053] [When the app is the determining entity] In the above description, the proposal decision unit 140 of the payment server 100 is the decision unit that decides whether or not to display the Split button B1. Alternatively, the decision 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 target affiliated store list / threshold information 176 to the payment application 20, and when the payment application 20 sends payment information to the payment server 100, it may perform a decision process similar to that of the proposal decision unit 140.
[0054] [Additional services] The group recommendation unit 150 performs various recommendations related to the split-bill proposal. For example, the group recommendation unit 150 estimates the common preferences of the split-bill group based on the split-bill history of the user information 172, and recommends participation in a group chat for an event that matches the preference. FIG. 11 is a diagram showing an example of a recommendation displayed in a group chat frame according to the split-bill history. FIG. 12 is a diagram showing an outline of a process in 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 preferences of the users into distributed representation vectors by a method such as word2vec in advance, converts keywords included in the split-bill history into distributed representation vectors in the same way, and estimates that the representative keywords that are the basis of the distributed representation vectors that are close (similar) to the distributed representation vectors obtained from the split-bill history represent the preferences of the split-bill group. Then, for example, if a campaign of an affiliated store input / set using the affiliated store interface 55 includes a representative keyword representing the preferences of the split-bill group (or the distributed representation vector obtained from the wording of the campaign is close to the distributed representation vector of the representative keyword), a recommendation related to the campaign is displayed on the payment applications 20 of some or all of the multiple users constituting the split-bill group. In addition, the group recommendation unit 150 may recommend information such as events based on general knowledge obtained using a crawler or LLM (Large Language Model). Instead of using the 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 were within a radius of Y [m] within a predetermined time from the payment (Y is a value of several to tens of meters) 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 split-the-bill proposal described above provides a natural user 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 users of the electronic payment service have used a store, 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 people 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 may be realized by cooperation between 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-transient storage medium), or may be stored in a removable storage medium (non-transient 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, a flash memory, a 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 compilation 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. 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. These pieces of information are provided, for example, by editing the user information 172 of 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 value, which will be described later, in response to the history information.
[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 to which the used store belongs (affiliated store ID). 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] Number of people estimation unit 332 of processing unit 330 estimates how many target users have used the store, based on information on the payment amount of the target user, the average payment amount for each affiliated store obtained from history information 372, and a correction value for each affiliated store. Number of people estimation unit 332 creates a part of history compilation information 374 based on history information 372.
[0062] FIG. 15 is a diagram showing an example of the contents of the historical aggregation information 374. The historical aggregation information 374 includes, for example, the average payment amount for each affiliated store and the P2P remittance (received) ratio. The number of people estimation unit 332 aggregates the affiliated store IDs and payment amounts related to payments from the historical information 372 to calculate the average payment amount Av(k) for each affiliated store, where k is the identifier of the affiliated store. Note that the correction value Adj(k) and threshold value Th(k) are also shown for the sake of later explanation.
[0063] The P2P remittance (receiving) 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) = (the number of times that a payment amount less than the payment amount was received from another user within a given time T from a payment made by the affiliated store k during the observation period: m) / (the number of payments made by the affiliated store k during the observation period: n) ... (1) R2(k) = (the number of times that multiple users have received an amount less than the payment amount within a given time T from a payment made to a member store k during the observation period: q) / m…(2)
[0065] The number of users 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 action of a user who receives money by P2P immediately after settlement is an action 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 said to be set to a larger value for an affiliated store that tends to be used by multiple people (and therefore has a high probability of splitting the bill). Note that the correction value Adj(k) may be set to a smaller value for an affiliated store that tends to be used by multiple people. In this case, the "addition or multiplication" described below is to be read as "subtraction or division".
[0066] The number of people estimation unit 332 estimates how many target users have used the store related to the affiliated store based on the score value Sc obtained by dividing the payment amount P of the target user by the average payment amount Av(k) of the affiliated store related to the payment and adding or multiplying the correction value Adj(k) for each affiliated store. In the following, it is assumed that the correction value Adj(k) is added to the "divided value". The score value Sc is expressed by formula (3). For example, the number of people estimation unit 332 estimates that an integer obtained by rounding the score value Sc indicates how many target users have used the store related to the affiliated store. 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] 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, so that it is possible to estimate the number of people more accurately.
[0069] Here, we will explain why applying the correction value Adj(k) improves the estimation accuracy. The average payment amount Av(k) for each affiliated store is not the average payment amount per user, but the average payment amount per payment regardless of the number of users (because the payment information does not include the "number of users"). Therefore, compared to affiliated stores that tend to be used by one person (such as a specific coffee shop), affiliated stores that tend to be used by multiple people (such as a hot pot restaurant) will have a relatively large average payment amount. If the correction value Adj(k) is not applied, the average payment amount Av(k) is in the denominator in formula (3), so affiliated stores that tend to be used by multiple people will be biased in that the number of users is calculated to be relatively low. The correction value Adj(k) works to counter this bias, so the number of users can be estimated more accurately. Figure 16 is a diagram comparing the estimated number of users and the P2P receipt ratio (equivalent to R1) when the correction value Adj(k) is applied and not applied. In addition, Figure 17 is a diagram comparing 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 applied. 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, and it can be seen that the accuracy is improved.
[0070] The threshold setting unit 334 of the processing unit 330 determines a threshold Th(k) for each affiliated store for estimating that two or more target users have used the 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 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 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 the 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 manner, the event "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 allowed to estimate the number of users, it is estimated to be two or more."
[0072] For example, for the member store k with the member store ID "2716" in FIG. 15, the threshold Th(k) is set to 6142 yen. The correction value Adj(k) for this member store k is 0.22. If a user uses the store of this member store k and pays 6142 yen, the number of people estimation unit 332 should calculate (6142 / 4798)+0.22=1.5, round it up, and output the 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 as possible to 2 people. This allows for highly accurate estimation, and the validity of the split-the-bill proposal in the payment server 100 can be maintained.
[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., do not include them in the target affiliated store list / threshold information 176). However, a threshold may be set for an affiliated store with a very large 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, processing related to estimating the number of people in various member stores can be performed more accurately.
[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 member store 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 first acquisition unit that acquires history information in an electronic payment service, the history information being capable of identifying an average payment amount for each affiliated store to which the store used is affiliated; a second acquisition unit that acquires payment information when a target user makes a payment using the electronic payment service, the payment information including information on a payment amount and information on an affiliated store to which the store used belongs; a processing unit that estimates how many of the target users have used the store based on the payment amount information, an average payment amount for each of the affiliated stores obtained from the history information, and a correction value for each of the affiliated stores; Equipped with The processing unit estimates how many people in the target user visited the store based on a score value obtained by dividing the payment amount by the average payment amount and adding or multiplying the correction value, and sets the correction value to a larger value for the affiliated store that is more likely to be used by multiple people. Information processing device.
2. a first acquisition unit that acquires history information in an electronic payment service, the history information being capable of identifying an average payment amount for each affiliated store to which the store used is affiliated; a second acquisition unit that acquires payment information when a target user makes a payment using the electronic payment service, the payment information including information on a payment amount and information on an affiliated store to which the store used belongs; a processing unit that estimates how many of the target users have used the store based on the payment amount information, an average payment amount for each of the affiliated stores obtained from the history information, and a correction value for each of the affiliated stores; Equipped with The history information further includes information on the usage history of the remittance service between users, the processing unit estimates how many of the target users have used the store based on a score value obtained by dividing the payment amount by the average payment amount and adding or multiplying the correction value, and sets the correction value to a larger value as the rate at which the user has received money from other users using the remittance service after payment in the history information compiled for each affiliated store increases. Information processing device.
3. The processing unit presumes that the target user used the store alone if the score value is less than a predetermined value, and presumes that the target user used the store with two or more people if the score value is equal to or greater than a predetermined value.
3. The information processing device according to claim 1 or 2.
4. The processing unit sets the correction value to a larger value as the ratio of the user receiving amounts from a plurality of other users using the remittance service after settlement increases.
3. The information processing device according to claim 2.
5. a first acquisition unit that acquires history information in an electronic payment service, the history information being capable of identifying an average payment amount for each affiliated store to which the store used is affiliated; a processing unit that determines a threshold value for each of the member stores for estimating that two or more target users have used the store based on an average payment amount for each of the member stores obtained from the history information and a correction value for each of the member stores; Equipped with The threshold value is a value used for the purpose of inferring that the target user has used the store in a group of two or more if a value obtained by dividing the payment amount of the electronic payment service by the average payment amount for each affiliated store is equal to or greater than the threshold value, The processing unit sets the correction value to a larger value for the affiliated store that is more likely to be used by multiple people. Information processing device.
6. a first acquisition unit that acquires history information in an electronic payment service, the history information being capable of identifying an average payment amount for each affiliated store to which the store used is affiliated; a processing unit that determines a threshold value for each of the member stores for estimating that two or more target users have used the store based on an average payment amount for each of the member stores obtained from the history information and a correction value for each of the member stores; Equipped with The threshold value is a value used for the purpose of inferring that the target user has used the store in a group of two or more if a value obtained by dividing the payment amount of the electronic payment service by the average payment amount for each affiliated store is equal to or greater than the threshold value, The history information further includes information on the usage history of the remittance service between users, the processing unit sets the correction value to a larger value as the rate at which the user receives money from other users using the remittance service after settlement increases in the history information compiled for each affiliated store. Information processing device.
7. the processing unit sets a threshold for each of the member stores so that a score value obtained by dividing the threshold by the average payment amount and adding or multiplying the correction value to the value becomes a predetermined value.
7. The information processing device according to claim 5 or 6.
8. In the information processing device, acquiring historical information in an electronic payment service that enables recognition of an average payment amount for each affiliated store to which the store used belongs; acquiring payment information when a target user makes a payment using the electronic payment service, the payment information including information on the payment amount and information on the affiliated store to which the store used is affiliated; estimating how many of the target users have used the store based on the information on the payment amount, an average payment amount for each of the affiliated stores obtained from the history information, and a correction value for each of the affiliated stores; In the process of estimating, the information processing device estimating how many of the target users have used the store based on a score value obtained by dividing the payment amount by the average payment amount and adding or multiplying the correction value to the score value; The correction value is set to be larger for the affiliated store which is more likely to be used by multiple people. Program for.
9. In the information processing device, acquiring historical information in an electronic payment service that enables recognition of an average payment amount for each affiliated store to which the store used belongs; acquiring payment information when a target user makes a payment using the electronic payment service, the payment information including information on the payment amount and information on the affiliated store to which the store used is affiliated; estimating how many of the target users have used the store based on the information on the payment amount, an average payment amount for each of the affiliated stores obtained from the history information, and a correction value for each of the affiliated stores; A program for: The history information further includes information on the usage history of the remittance service between users, In the process of estimating, the information processing device estimating how many of the target users have used the store based on a score value obtained by dividing the payment amount by the average payment amount and adding or multiplying the correction value to the score value; the correction value is set to a larger value as the ratio of a user receiving money from another user using the remittance service after settlement increases in the history information collected for each affiliated store; program.
10. In the information processing device, acquiring historical information in an electronic payment service that enables recognition of an average payment amount for each affiliated store to which the store used belongs; a program for determining, for each of the member stores, a threshold value for estimating that two or more target users have used the store, based on an average payment amount for each of the member stores obtained from the history information and a correction value for each of the member stores, The threshold value is a value used for the purpose of inferring that the target user has used the store in a group of two or more if a value obtained by dividing the payment amount of the electronic payment service by the average payment amount for each affiliated store is equal to or greater than the threshold value, The information processing device is configured to set the correction value to a larger value for the affiliated store that is more likely to be used by multiple people. program.
11. In the information processing device, acquiring historical information in an electronic payment service that enables recognition of an average payment amount for each affiliated store to which the store used belongs; a program for determining, for each of the member stores, a threshold value for estimating that two or more target users have used the store, based on an average payment amount for each of the member stores obtained from the history information and a correction value for each of the member stores, The threshold value is a value used for the purpose of inferring that the target user has used the store in a group of two or more if a value obtained by dividing the payment amount of the electronic payment service by the average payment amount for each affiliated store is equal to or greater than the threshold value, The history information further includes information on the usage history of the remittance service between users, the information processing device sets the correction value to a larger value as the rate at which the user receives money from other users by using the remittance service after settlement increases in the history information compiled for each affiliated store; program.
Citation Information
Patent Citations
Customer information providing system and method for providing customer management information of member customers to affiliated stores
JP2009512100A
Provision device, provision method and provision program
JP6419263B1
Providing device, providing method, and providing program
JP6754884B1
Information processing device, information processing method, and information processing program
JP7370440B1
Method for providing card recommendation information and device thereof
US20200356983A1