Estimation device, estimation method, and program

Abstract

To accurately estimate silent customers who have questions or issues regarding the use of electronic payment services. [Solution] An estimation device comprising: an acquisition unit that acquires estimated user information regarding a user of an electronic payment service; and an estimation unit that acquires an index value regarding the user by inputting the acquired estimated user information into a trained model that is trained to output an index value representing the likelihood that the user will make an inquiry regarding the electronic payment service when estimated user information regarding the user of the electronic payment service is input.

Description

[Technical field]

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

[0002] Conventionally, the existence of silent customers, who are users of a service and do not explicitly present their own questions or problems, has been known. For example, Patent Document 1 discloses a technology for efficiently acquiring information that contributes to improving a service by using problems presented by active customers who explicitly present their own questions or problems and the behavioral history of silent customers. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2022-113675 A Summary of the Invention [Problem to be solved by the invention]

[0004] The technology described in Patent Document 1 clusters passive data related to active customers to identify clusters of passive data, and identifies silent customers by grasping the number of pieces of data that belong to the identified clusters among the passive data of all users. However, with the conventional technology, there were cases where it was not possible to accurately estimate silent customers who have questions or issues regarding the use of electronic payment services.

[0005] The present invention has been made in consideration of these circumstances, and one of its objectives is to provide an estimation device, estimation method, and program that can accurately estimate silent customers who have questions or issues regarding the use of electronic payment services. [Means for solving the problem]

[0006] One aspect of the present invention is an estimation device that includes an acquisition unit that acquires estimated user information about a user of an electronic payment service, and an estimation unit that acquires an index value about the user by inputting the acquired estimated user information into a trained model that is trained to output an index value representing the likelihood that the user will make an inquiry about the electronic payment service when estimated user information about the user of the electronic payment service is input. Effect of the Invention

[0007] According to one aspect of the present invention, it is possible to provide an estimation device, an estimation method, and a program that can accurately estimate silent customers who have questions or issues regarding the use of electronic payment services. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. [Diagram 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payment. [Diagram 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payment. [Figure 4] 1 is a configuration diagram of a payment server 100 according to a first embodiment. [Diagram 5] FIG. 13 is a diagram showing an example of the contents of user information 172. [Figure 6] FIG. 13 is a diagram showing an example of the contents of affiliated store / store information 176. [Figure 7] 13A to 13C are diagrams illustrating an example of screen transition of help information displayed by payment application 20. [Figure 8] 13A to 13C are diagrams illustrating an example of screen transition of help information displayed by payment application 20. [Figure 9] FIG. 13 is a diagram showing an example of the contents of teacher data 178. [Figure 10] FIG. 2 is a diagram showing an example of the configuration of a trained model 180. [Figure 11] 13 is a diagram showing an example of notification information output by an output unit 146. FIG. [Figure 12] 13 is a diagram showing another example of notification information output by the output unit 146. FIG. [Figure 13] 13 is a diagram showing yet another example of notification information output by the output unit 146. FIG. [Figure 14] 13 is a table showing an example of a correspondence relationship between an estimation result by an estimation unit 144 and a corresponding channel. [Figure 15] 13 is a flowchart showing an example of the flow of processing executed by an information management unit 140. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, with reference to the drawings, an embodiment of an estimation device, an estimation method, and a program of the present invention will be described. Various devices for providing services to users and performing internal analysis, such as a "server," a "management device," and an "information providing device" that will appear below, may be realized by a group of distributed devices, and each device may be operated by a different business operator. Furthermore, the owner of the hardware of the device (the cloud server provider) and the business operator that actually operates the device may also be different. An application program and a payment server work together to provide an electronic payment service. In the following description, the application program is referred to as a payment application. 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 the real world, but may also include a virtual store for electronic commerce. A 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 a 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 carried out between the user and the store.

[0010] [Electronic payment service] Fig. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. The electronic payment service is realized mainly by a payment server 100. The payment server 100 communicates with, for example, one or more user terminal devices 10, one or more first store terminal devices 50, and one or more second store terminal devices 70 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, 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 installed in the user terminal device 10 from, for example, an application store, and controls the camera, communication device, touch panel, etc.

[0012] The first store terminal device 50 is installed, for example, in a store. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store, and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. The store code image 60 may be displayed on a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0013] The second store terminal device 70 is used by the operator of the affiliated store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. An interface 72 for affiliated stores runs on the second store terminal device 70. The interface 72 for affiliated stores may be an app for affiliated stores or a browser. The interface 72 for affiliated stores accepts coupon settings and the like made by the operator of the affiliated store and transmits them to the payment server 100. The second store terminal device 70, which is a smartphone, has the function of displaying a code image corresponding to a store code image and reading a code image displayed by the user terminal device 10 by executing the app for affiliated stores.

[0014] The payment server 100 realizes electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and an affiliated store server, in which case the payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, no distinction is made between these two and it is assumed that the payment information is sent from the first store terminal device 50.

[0015] 2 and 3 are sequence diagrams illustrating the general flow of electronic payment. There may be two patterns of electronic payment: pattern 1 and pattern 2.

[0016] In the case of pattern 1 (hereinafter referred to as user scan) shown in FIG. 2, the user terminal device 10 with the payment application 20 activated decodes the store code image 60 by the optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is an electronic payment service domain to which information capable of identifying a store is added, and is associated with an affiliated store ID, a store ID, etc. in the payment server 100 (described later). The payment application 20 transmits the first payment information including the store URL and the account ID to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the affiliated store ID and the store ID corresponding to the store URL, acquires the affiliated store name and the store name information (S3), and transmits it to the payment application 20 (S4). The user inputs the payment amount into the user terminal device 10 on the screen on which the affiliated store name and the store name are displayed (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount, and transmits it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then transmits a payment completion notice (information for displaying a payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). Note that when the store code image 60 is displayed on a display installed in the store, the store code image 60 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 transmitted to the payment server 100. Information on the affiliated store name and the store name may be included in the payment completion screen and displayed.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, when the payment application 20 is started, when a payment operation is performed in the payment application 20, when an automatic update timing (e.g., 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 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 first store terminal device 50, and the first store terminal device 50 decodes the code image by an optical reading function and obtains the one-time code, etc. (S15). The first store terminal device 50 then 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 barcode or manually entering it. The payment server 100 identifies the user corresponding to the one-time code based on the received information and performs electronic payment (S17). The payment server 100 then transmits a payment completion notice to the payment application 20 (S18), and the payment application 20 displays a payment completion screen (S19).

[0018] 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.

[0019] [Payment server] FIG. 4 is a configuration diagram of the payment server 100 according to the first embodiment. The payment server 100 includes, for example, a communication unit 110, a payment content providing unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. The components other than the communication unit 110 and the storage unit 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 realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by cooperation between software and hardware. The program may be stored in advance in a storage device (storage device having a non-transient storage medium) such as an HDD (Hard Disk Drive) or a flash memory, or may be stored in a removable storage medium (non-transient storage medium) such as a DVD or a CD-ROM, and may be installed in the storage device by mounting the storage medium in a drive device. The information management unit 140 further includes an acquisition unit 142, an estimation unit 144, and an output unit 146, the functions of which will be described in detail later. The function of the information management unit 140 in the payment server 100 is an example of an "information processing device."

[0020] 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, payment content information 174, affiliated store / shop information 176, training data 178, and trained model 180.

[0021] The communication unit 110 is a communication interface for connecting to the network NW. The communication unit 110 is, for example, a network interface card.

[0022] The payment content providing unit 120 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 payment content providing unit 120 appropriately reads necessary content from the payment content information 174 and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs by the user while the content is being played by the payment application 20, and transmits the above-mentioned payment information and the like to the payment server 100.

[0023] The payment processing unit 130 performs payment processing based on the payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 130 performs payment processing while referring to the user information 172.

[0024] FIG. 5 is a diagram showing an example of the contents of the user information 172. The user information 172 is an example of the registration information of a user. The user information 172 is information associated with, for example, a user URL, an account ID, a telephone number, a password, an email address, a user ID, sex, name, address, date of birth, registration date, identity verification completed / not completed, charge balance, credit payment setting, credit payment limit, credit payment usage amount, credit payment available amount, payment method setting, bank account, credit card number, charge history information, and payment history information. The user URL is used for remittance processing between users. When registering for the electronic payment service, it is necessary to register a telephone number and a password. The account ID is issued to the user by the payment server 100, and the user ID is an ID that can be set by the user at will (does not have to be set). Similarly, the email address, name, address, and date of birth are information that can be set by the user at will (does not have to be set). The registration date is the date on which the user registered for the electronic payment service (the date on which the account was created). Identity verification is information indicating whether or not a user has completed identity verification by, for example, uploading their identity verification document (e.g., official identification such as a driver's license) to the payment server 100 using the payment application 20, and is set to either "Completed" or "Not Completed." If identity verification is "Completed," the user will be able to withdraw the charge balance to a bank account, as described below. Hereinafter, the user's instance (electronic payment account) associated with this information will be referred to as an account.

[0025] The charge balance is information indicating the balance of electronic money that is set by a user by transferring money to an account in advance. The means of transfer include transfer from an ATM (Automatic Teller Machine) of a designated company (bank) and transfer from a registered bank account. The credit payment setting is information indicating whether or not the setting for enabling electronic payment by credit payment has been completed, and is set to either "completed" or "not completed." The credit payment limit is the credit payment limit that can be used each month, the credit payment usage amount is the amount of credit payment that has already been used in the current month, and the credit payment available amount is the amount of credit payment that can be used in the current month, which is calculated by subtracting the credit payment usage amount from the credit payment limit. Although only one credit payment limit is shown in the figure, in reality, there is also a daily upper limit, and the lower of these may be set as the credit payment limit. Further details of credit payment will be described later. The payment method setting is setting information indicating whether the user will perform electronic payment using the charge balance or payment by credit payment at that time. The bank account and credit card number are information on a bank account or credit card number (account number, card number) that can be used to deposit funds into the electronic payment service. The charge history information is a history of the user transferring funds to the electronic payment service in advance to increase the charge balance. The payment history information is information showing the details of the payment made by the user for each payment (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.). Although not shown in FIG. 5, the user information 172 may further store information on points acquired by the user by performing electronic payments. Points are awarded according to the payment amount of electronic payments made by the user, and the awarded points can be used, for example, to discount the payment amount of the next electronic payment.

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

[0027] The information management unit 140 manages user information 172 and affiliated store / store information 176 based on information acquired from the user terminal device 10 and the second store terminal device 70. The information management unit 140 adds new records to, edits, and deletes the user information 172 and affiliated store / store information 176.

[0028] [Electronic payment] When payment information is acquired from the user terminal device 10 or the first store terminal device 50, the payment processing unit 130 refers to the user information 172 to acquire the "payment method setting" of the user. For a user whose "payment method setting" is set to "charge balance", the payment processing unit 130 performs electronic payment as follows. For example, the payment processing unit 130 performs electronic payment by 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, and 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.

[0029] The payment processing unit 130 performs electronic payment for users whose "setting information" is set to "credit card payment" as follows. Credit card payment is a payment method in cooperation with a credit card company, which is a separate entity from the operator of the electronic payment service, and the operator of the electronic payment service acts as a creditor and allows electronic payment that is not dependent on the charge balance within the credit card payment limit. In order to receive the credit card payment service, a credit card provided by the operator of the electronic payment service may be required. The amount used in the credit card payment is settled on the payment date of the following month, for example, by debiting from a bank account, for one month. In this case, the payment processing unit 130 performs provisional payment by adding the payment amount to the credit card payment amount and subtracting the same amount from the available credit card payment amount, and when the closing date comes, it performs processing to debit the payment for the current month on the payment date of the following month as described above, or requests the operator of the credit card company to perform the processing. In addition, if the payment amount exceeds the available credit card payment amount at the time of provisional payment, an error notification is returned to the payment application 20.

[0030] [Help Information] In this way, a user who has registered with the electronic payment service can make electronic payments at affiliated stores using payment application 20. However, as described above, in order for a user to make an electronic payment using payment application 20, the user must perform multiple operations, such as creating an account, registering user information, performing identity verification, and registering a bank account or credit card number, and some users may have questions about the content of these operations or fail to perform the operations. For this reason, the electronic payment service provides help information on payment application 20 that users can refer to.

[0031] FIG. 7 is a diagram showing an example of screen transition of help information displayed by payment application 20. The screen shown in the left part of FIG. 7 is displayed, for example, by a user selecting an item showing help information on the top screen of payment application 20. The help information includes, for example, a display area A1 for causing a chatbot to output an answer corresponding to a search keyword input, a display area A2 for outputting an explanation corresponding to a category that classifies the content of the user's question, and a display area A3 for inquiring about support for the electronic payment service. Here, the chatbot may be an AI-type chatbot equipped with a large-scale language model (LLM) and trained to converse with the user in natural language, or a non-AI-type chatbot that outputs answers similar to the search keyword input by the user as options.

[0032] More specifically, in the left part of FIG. 7, the display area A2 includes, as an example of categories for classifying user questions, a payment category C1 representing the user's questions about payment methods, a charge category C2 representing the user's questions about charge methods, and an account category C3 representing the user's questions about account settings. The display area A2 further includes accordion buttons B1 to B3 for displaying detailed information about these categories in response to clicking. The display area A3 includes, for example, a link L1 transitioning to an inquiry form for directly inquiring to a customer service of the electronic payment service. The display area A3 may further include a telephone number of the customer service of the electronic payment service, and the link L1 may launch a mailer installed in the user terminal device 10 in response to clicking, instead of an inquiry form.

[0033] For example, when a user clicks button B1 corresponding to payment category C1, payment application 20 displays in display area A4 child categories C1_1 to C1_3 that are included in payment category C1 and further classify the user's questions about payment methods in more detail, as shown in the right part of Fig. 7. As an example, Fig. 7 shows, as child categories of payment category C1, child category C1_1 representing the user's questions about payment methods with the charge balance, child category C1_2 representing the user's questions about payment methods by credit card, and child category C1_3 representing the user's questions about payment methods with points.

[0034] When a user clicks on any of the areas of these child categories C1_1 to C1_3, payment application 20 transitions the user to a page that describes an explanation corresponding to the clicked child category C1_1 to C1_3 (i.e., a page that describes help information), for example.

[0035] FIG. 8 is a diagram showing an example of screen transitions of help information displayed by payment application 20. The screen shown on the left side of FIG. 8 corresponds to the screen shown on the right side of FIG. 7. For example, when a user clicks on the area of ​​child category C1_1 on the screen shown on the left side of FIG. 8, payment application 20 transitions to a page that describes a payment method with the charge balance. As a result, on the screen shown on the right side of FIG. 8, the user can understand how to make a payment with the charge balance in the electronic payment service.

[0036] [Generate trained model] In this way, users can use the chatbot function, the categorized help information viewing function, and the support inquiry function to resolve questions and issues regarding electronic payment services. However, because users are required to actively select and utilize these functions to resolve their own questions and issues, some users of electronic payment services may be unable to fully utilize these functions while having some questions or issues. As a result, the convenience of the service for such silent customers who have questions or issues regarding the use of electronic payment services may decrease.

[0037] In this embodiment, when user information for estimation of a user is input, a trained model 180 is generated that is trained to output an index value representing the possibility that the user will make an inquiry about an electronic payment service, and silent customers among the users are estimated using the generated trained model 180. After that, the estimated silent customers are notified of help information and current status information, for example, by a pop-up notification. This can improve the convenience of the service for silent customers. The notification in this case is not limited to a pop-up notification, and may be a notification using an SMS (short message service) function installed in the user terminal device 10, or a push notification output on the payment application 20. Hereinafter, the contents of the teacher data 178 used to generate the trained model 180 and the configuration of the trained model 180 will be described in detail with reference to FIG. 9 and FIG. 10.

[0038] 9 is a diagram showing an example of the contents of the teacher data 178. The teacher data 178 is, for example, a teacher data ID in which a help browsing history, status information, payment history, and demographic information constituting the input are associated with an inquiry category constituting the output. Each record of the teacher data 178 is, for example, collected from data (for example, inquiry form data or email data) in which a user actually makes an inquiry to support via an inquiry form or email, and an annotation indicating the inquiry category is associated with estimation user information on the user who made the inquiry.

[0039] The help browsing history is information that indicates the history of the user who made the inquiry browsing help information related to the electronic payment service on payment application 20 before making the inquiry. The help browsing history includes, for example, what actions the user took on the screens shown in Figs. 7 and 8 (for example, what order the pages were browsed and what search keywords were used for the search). For the sake of simplicity, in Fig. 9, the help browsing history shows only the user's actions, but it may additionally include information such as date and time information when the user browsed the help information and the duration of stay on each page.

[0040] The status information is information that indicates the status of the user who made the inquiry in the electronic payment service at the time of the inquiry. The status information includes, for example, whether identity verification has been completed or not, the registration period since the user registered with payment application 20 (it may be the period since downloading or the period since identity verification was performed), and whether an error has occurred and details of the error. The payment history includes some or all of the payment history recorded in user information 172.

[0041] Demographic information is information that represents attributes such as the age and sex of a user. The demographic information may be collected and recorded from the user information 172 of the user. In FIG. 9, for the sake of simplicity, the demographic information includes the age and sex of the user, but alternatively / additionally, the demographic information may include information such as the user's date of birth, address, occupation, and annual income. The behavioral age is different from the user's actual age and is calculated based on the user's behavior using the payment application 20. As a method of calculating the behavioral age, for example, based on the user's payment history, if the user frequently makes payments in a specific category or store (e.g., a category such as amusement, or a store such as a convenience store or game center), the behavioral age of the user may be calculated to be low. As another example, in an electronic payment service, the payment history of all users may be classified by age group to calculate feature amounts (e.g., payment unit price, payment time zone, category, region, etc.), and for a certain user, the age group with the most similar feature amount may be calculated as the behavioral age.

[0042] The inquiry category is information representing an annotation that associates the inquiry content of the user who made the inquiry with the categories explained through, for example, Figs. 7 and 8. The inquiry category is basically assigned manually by the operator of the electronic payment service when confirming the inquiry content of the user. In the example of Fig. 9, the inquiry content of the user is associated with one of categories C1 to C3, but the present invention is not limited to such a configuration, and the inquiry content of the user may be associated with a subcategory (for example, in the case of category C1, subcategories C1_1 to C1_3).

[0043] FIG. 10 is a diagram showing an example of the configuration of the trained model 180. As shown in FIG. 10, the trained model 180 is generated by training a machine learning model such as a deep neural network (DNN) to output the inquiry category that is the correct answer data (more precisely, to maximize the index value representing the inquiry category that is the correct answer data) using the estimation user information including the help browsing history, the status information, the payment history, and the demographic information based on the teacher data 178 described with reference to FIG. 9. In FIG. 10, as an example, the trained model 180 is trained to output a probability value that the user who is to be estimated as a silent customer has a question about each category in response to the input of the estimation user information of the user. The probability value is an example of an "index value representing the possibility of making an inquiry about an electronic payment service" in the claims.

[0044] As another embodiment, the trained model 180 may be trained to output a value (e.g., 1) indicating a correct category among a plurality of categories, instead of a probability value corresponding to each category. As another embodiment, the trained model 180 may be trained to output, for a single category, a probability value indicating that the user has a question about the category. In this case, the correct answer data of the teacher data 178 becomes a flag indicating the act itself of the user making an inquiry about the single category. In this case, a plurality of trained models 180 are prepared, and the category corresponding to the trained model 180 that outputs the maximum value among the probability values ​​output from the plurality of trained models 180 is selected.

[0045] When the trained model 180 is generated, the acquisition unit 142 acquires user information for estimation regarding a user who is to be estimated as being a silent customer, and the estimation unit 144 acquires an index value regarding the user by inputting the acquired user information for estimation into the trained model 180. For example, when the acquired index value is equal to or greater than a threshold, the estimation unit 144 can estimate that the user is a silent customer. The estimation unit 144 may acquire user information for estimation at any timing while the user is using the payment application 20, and input the information to the trained model 180. For example, the estimation unit 144 may acquire user information for estimation at a timing when the user starts the payment application 20 or a timing when a predetermined event is performed on the payment application 20 (for example, when registering an account, when identity verification is successful / failed, when charging is successful / failed, when electronic payment is successful / failed, when help information is viewed, when user information 172 is changed, etc.), and input the information to the trained model 180. Also, for example, the estimation unit 144 may periodically acquire the estimation user information of the user, and when the content of the acquired estimation user information is changed, input the estimation user information to the trained model 180. This allows the output unit 146 described below to output notification information to the user terminal device 10 at a timing required by the user.

[0046] [Notification information output] When a user is estimated to be a silent customer, the output unit 146, for example, causes the user terminal device 10 to output a pop-up notification related to a question or problem that the user is thought to potentially have. As described below, the pop-up notification output at this time contains content corresponding to the "inquiry category" with the highest probability value. This allows a user estimated to be a silent customer to solve the question or problem he or she has without having to actively utilize a chatbot function, a function for browsing help information by category, a function for inquiring support, or the like. The pop-up notification is an example of "auxiliary information" in the claims.

[0047] FIG. 11 is a diagram showing an example of notification information output by the output unit 146. The left part of FIG. 11 shows an example in which the output unit 146 outputs a pop-up notification P1 to the user terminal device 10 in response to the trained model 180 outputting the maximum probability value (i.e., 0.6) for the charge category C2 in the situation shown in FIG. 10. At this time, the output unit 146 may output the pop-up notification P1 to the user terminal device 10 only when the maximum probability value output by the trained model 180 is equal to or greater than a threshold value (e.g., 0.5). In the left part of FIG. 11, as an example, the pop-up notification P1 inquires whether the user has any questions or issues regarding the charge of the electronic payment service, and displays a link L2 for transitioning to help information regarding the charge.

[0048] When the user clicks on link L2 on user terminal device 10, payment application 20 transitions the display screen of user terminal device 10 to help information. At this time, because the largest probability value is output for charge category C2, payment application 20 may display the help information with charge category C2 selected in advance (i.e., with accordion button B2 pressed), as shown in the right part of FIG. 11. As a result, a user who is presumed to have questions or issues regarding charging with an electronic payment service can quickly check the help information regarding charging with an electronic payment service, without having to access the help information by his / her own operation or press accordion button B2.

[0049] In addition, FIG. 11 shows an example in which the pop-up notification P1 displays a link L2 to help information, but the present invention is not limited to such a configuration, and the pop-up notification P1 may include the content of the help information itself. For example, if the trained model 180 is configured to output a probability value of a small category, the pop-up notification P1 may include the content of the help information corresponding to the small category. This allows the user to check the help information more quickly. Furthermore, the pop-up notification P1 may include user status information (for example, identity verification "done" / "not yet", etc.) in addition to the link to the help information and the content of the help information itself. This allows the user to obtain clues to solving his or her own problems.

[0050] As described above, the estimation unit 144 may acquire estimated user information at any timing when the user is using the payment application 20 or at the timing when a predetermined event occurs, and input the information to the trained model 180, and the output unit 146 outputs a pop-up notification P1 to the user terminal device 10 at these timings. In this case, for example, when the predetermined event corresponds to the occurrence of a problem (such as failure of identity verification, failure of charging, failure of electronic payment, etc.), the output unit 146 may include in the pop-up notification P1 a status notification indicating the problem (such as "Charging is not possible") and a link to help information or the content of the help information itself. In this case, the output unit 146 may include in the pop-up notification P1 a link L1 that transitions to an inquiry form or a telephone number of a customer service of the electronic payment service depending on the situation (such as when the number of payments made by the user in the most recent period falls below a threshold). Also, for example, when the predetermined event corresponds to the occurrence of a prescribed event (such as the completion of account registration or identity verification), the output unit 146 may include, in the pop-up notification P1, a status notification indicating the prescribed event (such as "Account registration is complete. Register a payment method") and a link to help information or the content of the help information itself. In this case, the output unit 146 may output tutorial information corresponding to the next event after the prescribed event to the payment application 20 by push notification or SMS instead of the help information. More generally, the output unit 146 may change the mode of the notification information output to the payment application 20 according to the classification of the prescribed event. In this way, the output unit 146 can provide not only support (proactive support) when the user faces a specific problem (such as failure in identity verification, failure in charging, failure in electronic payment, etc.), but also support (proactive onboarding) to the user when a prescribed event (such as completion of account registration or identity verification) occurs on the payment application 20, thereby assisting silent customers in a wider range of situations and scenes.

[0051] FIG. 12 is a diagram showing another example of notification information output by the output unit 146. The left part of FIG. 12 shows a case where the trained model 180 outputs probability values ​​of 0.3 for the payment category C1, 0.6 for the charge category C1, and 0.1 for the account category C3, similar to the situation shown in FIG. 10. As shown in the right part of FIG. 12, at this time, the output unit 146 may display not only the category corresponding to the maximum probability value, but also, for example, in the order of the magnitude of the probability value output by the trained model 180, a link to help information or the help information itself in the pop-up notification P1. This basically allows the user to be assisted even if the trained model 180 erroneously outputs the maximum probability value, while preferentially presenting help information that is more likely to be of concern to the user.

[0052] FIG. 13 is a diagram showing another example of notification information output by the output unit 146. FIG. 11 shows, as an example, a case where the output unit 146 displays a link L2 to help information on the user terminal device 10 when the probability value output by the trained model 180 is equal to or greater than a threshold value (e.g., 0.5). On the other hand, as shown in FIG. 13, when the probability value output by the trained model 180 is equal to or greater than a second threshold value (e.g., 0.8) that is greater than the above threshold value, the output unit 146 may display, in the pop-up notification P1, a link L1 that transitions to an inquiry form for directly inquiring about a customer service of the electronic payment service instead of / in addition to the help information (i.e., the information in the pop-up notification P1 may be enriched). That is, the output unit 146 may gradually change the information to be included in the pop-up notification P1 according to the magnitude of the probability value output by the trained model 180.

[0053] As another embodiment, the output unit 146 may change the information to be included in the popup notification P1 in combination with conditions related to the user's help browsing history, status information, payment history, demographic information, or behavioral age. For example, in addition to the above-mentioned determination regarding the threshold value, the output unit 146 may guide the user to use the chatbot function (for example, display a link to the chatbot function) when the user's behavioral age (or the age of the demographic information) is low, while displaying a link L1 to a query form in the popup notification P1 when the user's behavioral age is high. Also, for example, the output unit 146 may refer to the user's help browsing history, and if there is a history of the user browsing help information, this is presumed to mean that the user has already confirmed the help information, so the output unit 146 may guide the user to the chatbot function or the query form without including the link L2 to the help information in the popup notification P1. Also, for example, if the user makes payments infrequently or has been registered with the electronic payment service for a short period of time, the output unit 146 may display a link L1 leading to an inquiry form in the pop-up notification P1 instead of / in addition to the link L2 to the chatbot function or help information.

[0054] Furthermore, when the probability value output by the trained model 180 is equal to or greater than the second threshold, when the user's behavioral age (or age in demographic information) is high, or when the level of urgency is high, the output unit 146 may display the telephone number of the customer service of the electronic payment service in the pop-up notification P1 instead of / in addition to the link L1 transitioning to the inquiry form. Here, "when the level of urgency is high" means, for example, when a predetermined problem (such as failure in identity verification, failure in charging, or failure in electronic payment) occurs on the payment application 20.

[0055] Furthermore, the output unit 146 may select a response channel that is more likely to resolve the inquiry depending on the silent customer's inquiry category or subcategory estimated by the estimation unit 144, and output a pop-up notification P1 to the user terminal device 10 to guide the user to the selected response channel.

[0056] FIG. 14 is a table showing an example of a correspondence relationship between the estimation result by the estimation unit 144 and the corresponding channel. The table shown in FIG. 14 shows the correspondence relationship between the inquiry category and the channel as an example, but may show the correspondence relationship between the subcategory (i.e., individual problem) and the channel. The operator of the electronic payment service may define the table shown in FIG. 14 in advance by measuring in advance which channel the user uses most frequently to solve the problem for each inquiry category or subcategory and recording the correspondence relationship. In this case, the channel that solved the problem can be specified as the channel that each user used last when the search behavior in the payment application 20 was ended, for example. When a certain inquiry category is estimated by the estimation unit 144 for the silent customer, the output unit 146 refers to the table in FIG. 14 to select a corresponding channel, and outputs a pop-up notification P1 to guide the user to the selected corresponding channel to the user terminal device 10.

[0057] As another example of the correspondence defined in the table, when the estimation result by the estimation unit 144 indicates an issue that can be solved by a chatbot (for example, a question about the upper limit of charge), the output unit 146 may select a chatbot as a corresponding channel. More specifically, since the rate at which the chatbot can solve the issue varies depending on the inquiry content, if the issue is an issue with a high self-solving rate by the bot, for example, a question such as "I just want to know the upper limit of charge," the output unit 146 may guide the user to the bot. Also, for example, when the estimation result by the estimation unit 144 indicates an issue that does not require explanatory guidance (for example, point payment settings), the output unit 146 may select a setting screen of the payment application 20 (for example, a point payment setting screen) as a corresponding channel, rather than a chatbot or help information. More specifically, in response to a question such as "I want to use points for payment, but I don't know where to set it," a link for deep linking to the point usage setting screen is displayed as a pop-up on the screen. This is because such a question does not require explanatory guidance from a bot or the like, and can be directly guided to the setting screen. Also, for example, when the estimation result by the estimation unit 144 indicates an issue that requires explanatory guidance (for example, an error in taking a photo for identity verification), the output unit 146 may select help information as a response channel. When the user is required to read the guidance thoroughly or when an explanation with a diagram is easier to understand, the output unit 146 guides the user to a help or guide. For the question "There is an error in taking a photo for eKYC. What should I do?", the help page "I can't do eKYC" shows a hint on how to take a photo of the certificate with a diagram, so guidance such as sending a link to the help via SMS is effective. Also, for example, when the estimation result by the estimation unit 144 indicates an issue that requires troubleshooting or a procedure at the counter (for example, cancellation of an unintended charge), the output unit 146 may select an inquiry form or a telephone number of the customer service of the electronic payment service as a response channel. This is because it is effective to guide the user to the inquiry counter since special handling at the counter needs to be considered.In this way, by defining appropriate corresponding channels in advance and allocating them according to the estimation result by the estimation unit 144, it is possible to improve the satisfaction of silent customers.

[0058] [Processing flow] Next, a process flow executed by the information management unit 140 will be described with reference to Fig. 15. Fig. 15 is a flowchart showing an example of a process flow executed by the information management unit 140. The process of the flowchart shown in Fig. 15 is executed, for example, when a user starts up the payment application 20 or at any timing while using the payment application 20.

[0059] First, the acquisition unit 142 acquires estimation user information of a user who is estimated to be likely to make an inquiry about an electronic payment service (step S100). Next, the estimation unit 144 inputs the acquired estimation user information into the trained model 180 (step S102).

[0060] Next, the output unit 146 determines whether the probability value of a certain category output from the trained model 180 is equal to or greater than a threshold (step S104). If it is determined that the probability value of a certain category output from the trained model 180 is equal to or greater than the threshold, the output unit 146 outputs a pop-up notification regarding the category to the user terminal device 10 (step S106). On the other hand, if it is determined that the probability value output from the trained model 180 is less than the threshold for any category, the information management unit 140 ends the processing. This ends the processing of this flowchart.

[0061] In this embodiment, for convenience of explanation, the functions of the payment server 100 (particularly, the acquisition unit 142, the estimation unit 144, and the output unit 146) are distinguished from the functions of the payment application 20, but the present invention is not limited to such a configuration, and some of the functions of the payment server 100 may be installed in the payment application 20. For example, the payment application 20 may acquire a probability value by acquiring estimation user information related to a user and inputting it into a trained model 180 inside or outside the payment application 20. Conversely, some of the functions of the payment application 20 may be installed in the payment server 100. For example, the screen transition and the display of help information caused by clicking on a link displayed on the user terminal device 10 may be realized by the output unit 146 controlling the user terminal device 10.

[0062] Furthermore, in this embodiment, the output unit 146 outputs a pop-up notification on the payment application 20 of the user terminal device 10. However, the present invention is not limited to such a configuration, and the output unit 146 may simply output the contents of the above-mentioned pop-up notification on a part of the display screen of the payment application 20 (for example, the top screen or the account setting screen) instead of the pop-up notification.

[0063] According to the embodiment described above, estimated user information on a user of an electronic payment service is acquired, and the acquired estimated user information is input to a trained model that has been trained to output an index value representing the likelihood that the user will make an inquiry about the electronic payment service when estimated user information on a user of an electronic payment service is input, thereby acquiring an index value on the user. This makes it possible to accurately estimate silent customers who have questions or issues regarding the use of electronic payment services.

[0064] 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]

[0065] 10 User terminal device 20. Payment App 100 Payment Server 110 Communications Department 120 Payment Contents Provider 130 Payment processing unit 140 Information Management Department 142 Acquisition Department 144 Estimation Department 146 Output section

Claims

1. An acquisition unit that acquires estimated user information regarding a user of an electronic payment service; and an estimation unit that, when the acquired estimated user information on a user of the electronic payment service is input, inputs an index value representing the likelihood that the user will make an inquiry about the electronic payment service into a trained model that has been trained to output the index value for a category representing a classification of the content of the inquiry, thereby acquiring the index value on the user. Estimation device.

2. The estimated user information includes at least one of a browsing history of help information related to the electronic payment service viewed by the user on a user terminal device, status information of the user in the electronic payment service, a payment history of electronic payments made by the user using the electronic payment service, demographic information on the user, and a behavioral age of the user estimated based on the payment history. The estimation device according to claim 1 .

3. The trained model is trained to output, when the estimated user information is input, an index value representing the likelihood that the user will make an inquiry regarding the electronic payment service for a predetermined category. The estimation device according to claim 1 or 2.

4. The trained model is trained to output, when the estimation user information is input, index values ​​representing the likelihood that the user will make an inquiry regarding the electronic payment service for a plurality of categories. The estimation device according to claim 1 or 2.

5. An acquisition unit that acquires estimated user information regarding a user of an electronic payment service; an estimation unit that inputs the acquired estimated user information into a trained model that is trained to output an index value representing a likelihood that the user will make an inquiry about the electronic payment service when estimated user information about a user of the electronic payment service is input, thereby acquiring the index value about the user; The trained model is trained based on training data in which an annotation indicating a category of inquiry data sent by the user to support of the electronic payment service is associated with the estimation user information. Estimation device.

6. and an output unit that outputs auxiliary information related to the inquiry to a user terminal device used by the user based on the acquired index value. The estimation device according to claim 1 .

7. the output unit causes the user terminal device to output auxiliary information related to the inquiry only when the acquired index value is equal to or greater than a threshold value. The estimation device according to claim 6.

8. the output unit outputs, as the auxiliary information, a link to a page of the electronic payment service on which explanatory information related to the inquiry is described, to the user terminal device. The estimation device according to claim 6.

9. The computer Obtain presumed user information regarding users of the electronic payment service; the acquired estimated user information is input to a trained model that has been trained to output an index value representing the likelihood that the user will make an inquiry about the electronic payment service for a category representing a classification of the content of the inquiry, thereby acquiring the index value relating to the user; Estimation method.

10. The computer Obtain presumed user information regarding users of the electronic payment service; inputting the acquired estimated user information into a trained model that has been trained to output an index value representing the likelihood that the user will make an inquiry regarding the electronic payment service when estimated user information regarding a user of the electronic payment service is input, thereby acquiring the index value regarding the user; The trained model is trained based on training data in which an annotation indicating a category of inquiry data sent by the user to support of the electronic payment service is associated with the estimation user information. Estimation method.

Images