Estimation device, estimation method, and program

Abstract

To accurately estimate a silent customer having a question or a problem about the use of an electronic settlement service.SOLUTION: An estimation device comprising: an acquisition unit configured to acquire estimated user information on a user of an electronic payment service; and an estimation unit configured to acquire an index value indicating a possibility that the user makes an inquiry about the electronic payment service by inputting the acquired estimated user information to a learned model learned to output the index value when the estimated user information on the user of the electronic payment service is input.SELECTED DRAWING: Figure 1

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 services 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] Japanese Patent Publication No. 2022-113675 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 determining the number of pieces of data belonging to the identified clusters among the passive data of all users. However, conventional technology sometimes fails to accurately identify 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 that represents 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. [Effects 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 explanation of the drawings]

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

[0009] Hereinafter, with reference to the drawings, embodiments of an estimation device, an estimation method, and a program according to the present invention will be described. Various devices, such as a "server," a "management device," and an "information providing device," that provide services to users or perform internal analysis, may be implemented as a group of distributed devices, and each device may be operated by a different business. Furthermore, the hardware owner (the cloud server provider) and the business 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 app." An electronic payment service is a service that supports payments for the purchase of goods and services at a store. A store is, for example, a physical store (real-world store) existing in the real world, but may also include a virtual store for e-commerce transactions. A virtual store may also include a store operated by an entity other than the operator of the electronic payment service. In such a case, when making a payment for a purchase at the virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, an affiliated store (brand), and when a purchase is made at a store, processing such as payment is primarily conducted between the user and the affiliated store. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] Figure 1 shows 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, etc.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input acceptance function, and a program execution function. In the following description, components for realizing these functions are referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a processor such as a CPU executes a payment app 20, which operates in cooperation with the payment server 100 to provide electronic payment services to users. The payment app 20 is installed on 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, tablet terminal, personal computer, etc. An interface for affiliated stores 72 runs on the second store terminal device 70. The interface for affiliated stores 72 may be an app for affiliated stores or a browser. The interface for affiliated stores 72 accepts coupon settings and the like from 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 the 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 payment information is sent from the POS device via the affiliated store server to the payment server 100. In the following explanation, this distinction will not be made and it is assumed that 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 for 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 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 includes store URL (Uniform Resource Locator) information. This store URL is the domain of the electronic payment service to which store identification information has been added, and is associated with an affiliated store ID, store ID, etc. in the payment server 100 (described below). The payment application 20 sends first payment information including the store URL and account ID to the payment server 100 (S2). The payment server 100 searches for store information (described below) using the affiliated store ID and store ID corresponding to the store URL, acquires the affiliated store name and store name information (S3), and sends this to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen displaying the affiliated store name and store name (S5). Then, the user terminal device 10 generates second payment information including at least the payment amount and sends it to the payment server 100 (S6). The payment server 100 makes the electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notice (information for displaying a payment completion screen) to the payment app 20 (S8), and the payment app 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 information on the payment amount in addition to the store URL. In this case, the step of the user inputting the payment amount is omitted, and the payment amount information 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.

[0017] In the case of pattern 2 (hereinafter referred to as store scan) shown in FIG. 3, the payment app 20 sends a request to issue a one-time code to the payment server 100 when the payment app 20 is launched, when a payment operation is performed in the payment app 20, at the automatic update timing (e.g., every minute), and at other timings (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image, such as a QR code or barcode, generated based on the one-time code (S14). The user holds (presents) the display surface of the user terminal device 10 over the first in-store terminal device 50, and the first in-store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). The first in-store terminal device 50 then generates payment information including the one-time code, payment amount, affiliated store ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is acquired in advance by reading a barcode, manually entering it, etc. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs electronic payment (S17). Then, the payment server 100 sends 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, issuing a one-time code may be omitted in store scanning, and the payment application 20 may display a code image generated based on the user's account ID. In this case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[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 implemented by, for example, a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as a large-scale integration (LSI), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU), or may be implemented by a combination of software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transitory storage medium) such as a hard disk drive (HDD) or flash memory, or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and installed in the storage device by inserting the storage medium into a drive device. 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 hard disk drive (HDD), a flash memory, a random access memory (RAM), etc. The storage unit 170 may be a network attached storage (NAS) 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, and 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 reads out necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. The user terminal device 10 accepts various inputs from the user while 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 user information 172. User information 172 is an example of user registration information. User information 172 includes, for example, a user URL, account ID, telephone number, and password, as well as other information such as email address, user ID, gender, name, address, date of birth, registration date, identity verification status, charge balance, credit card payment settings, credit card limit, credit card payment amount, available credit card payment amount, payment method settings, bank account, credit card number, charge history information, and payment history information. The user URL is used for remittance processing between users. Registration of a phone number and password is required when registering for an electronic payment service. The account ID is issued to the user by the payment server 100, and the user ID can be set by the user (or does not have to be set). The email address, name, address, and date of birth are also information that can be set by the user (or do 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 app 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 indicates the balance of electronic money set by the user by transferring funds to the account in advance. Transfer methods include transfers from a designated bank's ATM (Automatic Teller Machine) or from a registered bank account. The credit payment setting indicates whether the settings for electronic credit payment have been completed and is set to either "Completed" or "Not Completed." The credit payment limit is the monthly credit payment limit. The credit payment amount is the amount of credit payment already used in the current month. The available credit payment amount is the amount of credit payment available in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the figure shows only one credit payment limit, in reality, there may also be daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be discussed later. The payment method setting indicates whether the user will currently make electronic payments using the charge balance or by credit payment. The bank account and credit card number are information about 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's previous transfers to the electronic payment service to increase the charge balance. The payment history information is information that shows the details of each payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.). Although not shown in Figure 5, the user information 172 may also store information about points earned by the user by performing electronic payments. Points are awarded according to the payment amount of the electronic payment 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 ID is associated with an affiliated store name and sales amount (described above), 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 store's location, and payment patterns.

[0027] The information management unit 140 manages the user information 172 and the 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, deletes, etc. the user information 172 and the 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 references the user information 172 to acquire the "payment method setting" of the user. For users 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 proceeds. The item value of the affiliated store's sales proceeds is not itself used as electronic money, for example, but rather the amount corresponding to the item value of the sales proceeds 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 payments 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. The operator of the electronic payment service acts as the creditor, allowing electronic payments within the credit card payment limit and independent of the remaining balance. To receive the credit card payment service, a user may be required to obtain a credit card provided by the operator of the electronic payment service. The monthly amount used for credit card payment is settled on the following month's payment date, for example, by debit from a bank account. In this case, the payment processing unit 130 makes a provisional settlement by adding the settlement amount to the credit card payment amount and subtracting the same amount from the available credit card balance. On the closing date, the payment processing unit 130 performs the process described above to debit the current month's payment on the following month's payment date, or requests the credit card company operator to perform this process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, an error notification is returned to the payment app 20.

[0030] [Help Information] In this way, users who register with the electronic payment service can make electronic payments at affiliated stores using payment app 20. However, as described above, in order for a user to make an electronic payment using payment app 20, the user must perform multiple operations, such as creating an account, registering user information, verifying identity, 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 them. For this reason, the electronic payment service provides help information on payment app 20 that users can refer to.

[0031] FIG. 7 is a diagram showing an example of screen transitions of help information displayed by payment app 20. The screen shown on the left side of FIG. 7 is displayed, for example, when a user selects an item showing help information on the top screen of payment app 20. The help information includes, for example, a display area A1 for causing a chatbot to output an answer corresponding to a search keyword entered in response to the search keyword; a display area A2 for outputting an explanation corresponding to a category that classifies 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 entered by the user as options.

[0032] More specifically, in the left portion of FIG. 7, display area A2 includes, as examples of categories for categorizing user questions, a payment category C1 that represents user questions about payment methods, a charge category C2 that represents user questions about charge methods, and an account category C3 that represents user questions about account settings. Display area A2 also includes accordion buttons B1 to B3 that, when clicked, display detailed information about these categories. Display area A3 includes, for example, link L1 that transitions to an inquiry form for direct inquiries to the customer service of the electronic payment service. Display area A3 may also include the telephone number of the customer service of the electronic payment service, and link L1 may launch a mailer installed on user terminal device 10 instead of an inquiry form when clicked.

[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 that further categorize users' questions about payment methods, as shown in the right part of Fig. 7. As an example, Fig. 7 shows the following child categories of payment category C1: child category C1_1 that represents users' questions about payment methods using their charge balance, child category C1_2 that represents users' questions about payment methods using credit, and child category C1_3 that represents users' questions about payment methods using points.

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

[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 how to make a payment using the remaining balance. As a result, on the screen shown on the right side of FIG. 8, the user can understand how to make a payment using the remaining balance in the electronic payment service.

[0036] [Generate a 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 harboring 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 be reduced.

[0037] In light of this situation, in this embodiment, when a user's user information for estimation is input, a trained model 180 is generated that is trained to output an index value representing the likelihood that the user will make an inquiry about an electronic payment service. The generated trained model 180 is then used to estimate silent customers among the users. The estimated silent customers are then notified of help information and current status information, for example, by a pop-up notification. This improves the convenience of the service for silent customers. The notification in this case is not limited to a pop-up notification, but 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 app 20. Below, with reference to FIGS. 9 and 10 , the contents of the training data 178 used to generate the trained model 180 and the configuration of the trained model 180 will be described in detail.

[0038] 9 is a diagram showing an example of the contents of the training data 178. The training data 178 is, for example, a training 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 training data 178 is, for example, collected from data (e.g., 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 estimated user information about the user who made the inquiry.

[0039] The help browsing history is information representing 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 pages were browsed in what order, or what search keywords were used for the search). For the sake of simplicity, FIG. 9 shows only the user's actions in the help browsing history, but it may also include additional information, such as the date and time when the user browsed the help information and the time spent on each page.

[0040] The status information 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 app 20 (which may be the period since downloading or the period since identity verification), and whether or not an error has occurred and details of such an 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 of a user, such as age and gender. Demographic information may be collected and recorded from the user's user information 172. In FIG. 9, for simplicity, the demographic information includes the user's age and gender. Alternatively or additionally, the demographic information may include information such as the user's date of birth, address, occupation, and annual income. Behavioral age is different from the user's actual age and is calculated based on the user's behavior using the payment app 20. For example, based on the user's payment history, if the user frequently makes payments in a particular category or store (e.g., amusement facilities, convenience stores, game arcades, etc.), the user's behavioral age may be calculated as low. As another example, in an electronic payment service, the payment history of all users may be classified by age group to calculate feature values ​​(e.g., payment unit price, payment time zone, category, region, etc.), and the age group with the most similar feature value may be calculated as the behavioral age for a given user.

[0042] The inquiry category is information representing an annotation that associates the inquiry content of the user who made the inquiry with the category explained with reference to, for example, FIGS. 7 and 8. The inquiry category is basically assigned manually by the operator of the electronic payment service when checking 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 also 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 illustrating an example of the configuration of the trained model 180. As illustrated in FIG. 10, the trained model 180 is generated by training a machine learning model such as a deep neural network (DNN) based on the training data 178 described with reference to FIG. 9, using estimation user information including help browsing history, status information, payment history, and demographic information as input, so as to output the inquiry category that is the correct answer data (more precisely, so that the index value representing the inquiry category that is the correct answer data is the highest). In FIG. 10, as an example, the trained model 180 is trained to output a probability value that the user has a question about each category in response to input estimation user information of the user to be estimated as a silent customer. The probability value is an example of an "index value representing the likelihood of making an inquiry about electronic payment services" in the claims.

[0044] In another embodiment, the trained model 180 may be trained to output a value (e.g., 1) indicating the correct category among multiple categories, rather than a probability value corresponding to each category. In 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 that category. In this case, the correct answer data in the training data 178 becomes a flag indicating the act of the user making an inquiry about that single category. In this case, multiple 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 multiple trained models 180 is selected.

[0045] Once the trained model 180 is generated, the acquisition unit 142 acquires user information for estimation regarding a user whose silent customer status is to be estimated, and the estimation unit 144 inputs the acquired user information for estimation into the trained model 180 to acquire an index value regarding the user. For example, if 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 the user information for estimation at any timing while the user is using the payment app 20 and input it into the trained model 180. For example, the estimation unit 144 may acquire the user information for estimation when the user launches the payment app 20 or when a predetermined event is performed on the payment app 20 (e.g., when registering an account, when identity verification succeeds / fails, when charging succeeds / fails, when electronic payment succeeds / fails, when help information is viewed, when user information 172 is changed, etc.), and input it into the trained model 180. Furthermore, 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 into the trained model 180. This allows the output unit 146, which will be 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 likely to have. As described below, the pop-up notification output at this time includes content corresponding to the "inquiry category" with the highest probability value. This allows the user estimated to be a silent customer to resolve their question or problem without having to actively use a chatbot function, a function for browsing help information by category, or a function for contacting support. 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, in the situation shown in FIG. 10, 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 this case, the output unit 146 may output the pop-up notification P1 to the user terminal device 10 only if 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 charging the electronic payment service, and displays a link L2 for transitioning to help information regarding charging.

[0048] When the user clicks 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 on the right side 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 help information regarding charging with an electronic payment service without having to access the help information by their own operation or press accordion button B2.

[0049] While FIG. 11 shows an example in which the pop-up notification P1 displays a link L2 to help information, 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 probability values ​​for subcategories, the pop-up notification P1 may include the content of the help information corresponding to the subcategory. This allows the user to check the help information more quickly. Furthermore, the pop-up notification P1 may include user status information (e.g., whether identity verification has been completed or not) 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 their own problems.

[0050] As described above, the estimation unit 144 may acquire estimation user information at any time while the user is using the payment app 20 or when a predetermined event occurs, and input the information into the trained model 180. The output unit 146 may output a pop-up notification P1 to the user terminal device 10 at these times. In this case, for example, if the predetermined event corresponds to the occurrence of a problem (such as a failure in identity verification, a failure in charging, or a failure in electronic payment), the output unit 146 may include in the pop-up notification P1 a status notification indicating the problem (such as "Charging is not possible"), 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 for customer service of the electronic payment service, depending on the situation (for example, if the number of payments made by the user in the most recent period falls below a threshold). Furthermore, 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 (e.g., "Account registration is complete. Register a payment method"), 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 event following the prescribed event to the payment app 20 by push notification or SMS, instead of the help information. More generally, the output unit 146 may change the format of the notification information output to the payment app 20 depending on 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 identity verification failure, charge failure, or electronic payment failure), but also assistance (proactive onboarding) to the user when a prescribed event occurs on the payment app 20 (such as account registration or identity verification completion), thereby assisting silent customers in a wider range of situations and occasions.

[0051] FIG. 12 is a diagram illustrating another example of notification information output by the output unit 146. The left part of FIG. 12 illustrates a case in which, similar to the situation illustrated in FIG. 10, the trained model 180 outputs probability values ​​of 0.3 for payment category C1, 0.6 for charge category C1, and 0.1 for account category C3. As illustrated in the right part of FIG. 12, in this case, the output unit 146 may display not only the category corresponding to the largest probability value, but also the pop-up notification P1 including a link to help information or the help information itself, for example, in order of the magnitude of the probability value output by the trained model 180. This basically prioritizes the presentation of help information that is more likely to address the user's questions or issues, while still providing assistance to the user even when the trained model 180 erroneously outputs the largest probability value.

[0052] FIG. 13 is a diagram illustrating another example of notification information output by the output unit 146. FIG. 11 illustrates, as an example, a case in which 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 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 the customer service of the electronic payment service, instead of or 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 included in the pop-up notification P1 depending on the magnitude of the probability value output by the trained model 180.

[0053] In another aspect, the output unit 146 may change the information to be included in the pop-up 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 determination of the threshold value described above, the output unit 146 may guide the user to use the chatbot function (for example, by displaying 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 leading to an inquiry form in the pop-up notification P1 when the user's behavioral age is high. Also, for example, if the output unit 146 refers to the user's help browsing history and finds that the user has viewed help information, it is estimated that the user has already checked the help information, and therefore the output unit 146 may guide the user to the chatbot function or the inquiry form without including the link L2 to the help information in the pop-up notification P1. Also, for example, if the user makes payments infrequently or has a short registration period for the electronic payment service, the output unit 146 may display a link L1 that transitions 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, if the probability value output by the trained model 180 is equal to or greater than the second threshold, if the user's behavioral age (or age in demographic information) is high, or if 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 or in addition to the link L1 that transitions to the inquiry form. Here, "if the level of urgency is high" means, for example, if 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 the correspondence between the estimation result by the estimation unit 144 and the corresponding channel. The table shown in FIG. 14 shows the correspondence between inquiry categories and channels as an example, but it may also show the correspondence between subcategories (i.e., individual issues) and channels. The operator of the electronic payment service can predefine the table shown in FIG. 14 by measuring in advance which channel users frequently use to solve problems for each inquiry category or subcategory and recording the correspondence. In this case, the channel that solved the problem can be identified as, for example, the channel last used by each user when they finished searching within the payment app 20. When a certain inquiry category is estimated for a silent customer by the estimation unit 144, the output unit 146 refers to the table in FIG. 14 to select a corresponding channel and outputs a pop-up notification P1 to the user terminal device 10 to guide the user to the selected corresponding channel.

[0057] As another example of correspondence relationships defined in the table, if the estimation result by the estimation unit 144 indicates an issue that can be resolved by a chatbot (e.g., a question about the charge limit), the output unit 146 may select a chatbot as the response channel. More specifically, since the rate at which a chatbot can resolve a problem varies depending on the inquiry, the output unit 146 may guide the user to a bot for an issue that has a high self-resolution rate with a bot, such as a question such as, "I just want to know the charge limit." Furthermore, if the estimation result by the estimation unit 144 indicates an issue that does not require explanatory guidance (e.g., point payment settings), the output unit 146 may select a settings screen of the payment app 20 (e.g., a point payment settings screen) as the response 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 up," a link for deep linking to a point usage settings screen is displayed as a pop-up on the screen. This is because such questions do not require explanatory guidance from a bot or the like; they can simply be guided directly to the settings screen. Furthermore, for example, when the estimation result by the estimation unit 144 indicates an issue requiring explanatory guidance (e.g., an error in taking a photo for identity verification), the output unit 146 may select help information as the response channel. If the user is required to thoroughly read the guidance or if a diagrammatic explanation is easier to understand, the output unit 146 may direct the user to a help or guide. For example, in response to the question, "I'm getting an error taking a photo for eKYC. What should I do?", the "eKYC not working" help page provides diagrammatic hints on how to take a photo of the certificate, so sending a link to the help via SMS is effective. Furthermore, for example, when the estimation result by the estimation unit 144 indicates an issue requiring troubleshooting or a procedure at a counter (e.g., an unintended charge cancellation), the output unit 146 may select an inquiry form or a customer service phone number for the electronic payment service as the response channel. This is because special handling at the counter needs to be considered, and directing the user to the inquiry counter is effective.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, the flow of processing executed by information management unit 140 will be described with reference to Fig. 15. Fig. 15 is a flowchart showing an example of the flow of processing executed by information management unit 140. The processing of the flowchart shown in Fig. 15 is executed, for example, when a user starts payment app 20 or at any time while using payment app 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. However, the present invention is not limited to such a configuration, and some of the functions of the payment server 100 may be incorporated into the payment application 20. For example, the payment application 20 may acquire estimation user information about a user and input it into a trained model 180 inside or outside the payment application 20 to acquire a probability value. Conversely, some of the functions of the payment application 20 may be incorporated into the payment server 100. For example, the screen transition and the display of help information in response to 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, output unit 146 outputs a pop-up notification on payment application 20 of user terminal device 10. However, the present invention is not limited to such a configuration, and output unit 146 may simply output the content of the above-mentioned pop-up notification on a part of the display screen of payment application 20 (for example, the top screen or account setting screen) instead of the pop-up notification.

[0063] According to the embodiment described above, estimation user information about a user of an electronic payment service is acquired, and the acquired estimation user information is input to 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 the estimation user information about the user of the electronic payment service is input, thereby obtaining an index value about 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 Department 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 related to users of the electronic payment service; an estimation unit that inputs the acquired estimation 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 estimation user information about the user of the electronic payment service is input, thereby acquiring the index value about the user; Estimation device.

2. The estimated user information includes at least one of a browsing history of help information about the electronic payment service that the user has viewed on a user terminal device, status information about the user in the electronic payment service, a payment history of electronic payments made by the user using the electronic payment service, demographic information about 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, for a predetermined category, an index value representing the likelihood that the user will make an inquiry regarding the electronic payment service when the estimation user information is input. 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 about the electronic payment service for a plurality of categories. The estimation device according to claim 1 or 2.

5. The trained model is trained based on training data in which annotations indicating categories of inquiries made by the user to the electronic payment service are associated with the estimation user information. The estimation device according to claim 1 or 2.

6. 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 causes the user terminal device to output, as the auxiliary information, a link to a page of the electronic payment service on which explanatory information related to the inquiry is described. The estimation device according to claim 6 .

9. The computer Obtain estimated user information regarding users of the electronic payment service; The acquired estimation user information is input to 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 estimation user information about the user of the electronic payment service is input, thereby acquiring the index value about the user. Estimation method.

10. On the computer, Obtain estimated user information regarding users of electronic payment services; inputting the acquired estimation 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 about the electronic payment service when estimation user information about the user of the electronic payment service is input, thereby obtaining the index value about the user; program.

Images