Information processing device, information processing method, and program

Abstract

To provide an information processing device, information processing method, and program that improve the convenience of users or service providers. [Solution] In a service provision system including a payment server, an orchestrator, and multiple agents, each agent comprises: a processing unit 410 that acquires inquiry information provided by a user; a first information processing unit 430 that acquires multiple pieces of related information related to the inquiry information from service-related information stored in a storage unit 440 and assigns a degree of relevance to the related information; and a second information processing unit 460 that inputs the related information with assigned degrees of relevance and the inquiry to a first model 470 that has been trained to output an answer to the inquiry when an inquiry is input, and provides the answer output by the first model to the user.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] Conventionally, a customer support system including a public solution database publicly available to users by a customer support entity and an internal solution database normally used within the customer support entity is known (see Patent Document 1). When a user makes an inquiry to the customer support entity, in this customer support system, the search result of the public solution database by the user is transmitted to the customer support entity together with the inquiry content, and an answer obtained by searching the internal solution database and processing by an agent is displayed on the customer terminal of the user.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Conventionally, when a computer could not give an answer, an operator answered on behalf of the computer. In this case, it was sometimes impossible to handle congestion, or it was costly, resulting in low convenience for users or service providers.

[0005] The present invention has been made in view of such circumstances, and one of its purposes is to provide an information processing apparatus, an information processing method, and a program that can assist in improving the convenience for users or service providers. For example, an appropriate answer can be automatically provided to the user. [Means for solving the problem]

[0006] One aspect of the present invention is an information processing device comprising: a processing unit for acquiring inquiry information provided by a user terminal device; a first information processing unit for acquiring a plurality of related pieces of information related to the inquiry information from service-related information stored in a storage unit and assigning a degree of relevance to the related pieces of information; and a second information processing unit for inputting the related pieces of information to which the degree of relevance has been assigned and the inquiry into a first model that has been trained to output an answer to the inquiry when the inquiry is input, and providing the answer output by the first model to the user terminal device. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to help improve the convenience of users or service providers. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the configuration of electronic payment system 1 for realizing electronic payment services. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payments. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments. [Figure 4] This is a diagram showing the configuration of payment server 100. [Figure 5] This figure shows an example of the contents of user information 172. [Figure 6] This figure shows an example of the contents of merchant / store information 176. [Figure 7] This figure shows an example of an interface screen IF1, which displays an inquiry and an answer to that inquiry. [Figure 8] This figure shows an example of the functional configuration of Orchestrator 300. [Figure 9]This is a diagram for explaining the functional configuration and processing of agent 400. [Figure 10] This is a diagram showing an example of the configuration for realizing the electronic payment service of the second embodiment. [Figure 11] This is a configuration diagram of the payment server 100 according to the second embodiment. [Figure 12] This is a diagram showing an example of the top screen of the payment app 20. [Figure 13] This is a diagram showing a scenario where the user launches the AI assist app 20A and inputs a request in natural language. [Figure 14] This is a diagram showing an example of the orchestrator prompt 178 that the orchestrator unit 150A inputs to the LLM server 800. [Figure 15] This is a diagram showing an example of the agent prompt 180 that the agent unit 150B inputs to the LLM server 800. [Figure 16] This is a diagram showing an example of a common UI component defined in the UI component information 186. [Figure 17] This is a screen transition diagram showing the input task of the remittance recipient in the remittance process. [Figure 18] This is a screen transition diagram showing the input task of the remittance amount in the remittance process. [Figure 19] This is a screen transition diagram showing the task of adding a memo in the remittance process. [Figure 20] This is a screen transition diagram showing the final confirmation task before executing the remittance process. [Figure 21] This is a screen transition diagram for notifying the user that the remittance process has been completed. [Figure 22] This is a screen transition diagram showing the input task of the charge amount in the charge process. [Figure 23] This is a screen transition diagram showing the final confirmation task before executing the charge process. [Figure 24] This is a screen transition diagram for notifying the user that the charge process has been completed. [Figure 25]This is a diagram showing an example of the processing flow when an error occurs. [Figure 26] This is a sequence diagram showing an example of the processing flow of the AI assist function.

Embodiments for Carrying Out the Invention

[0009] Hereinafter, with reference to the drawings, embodiments of the information processing apparatus, information processing method, and program of the present invention will be described. Various apparatuses such as "servers", "management apparatuses", and "information providing apparatuses" that provide services to users or perform internal analysis may be realized by a decentralized group of apparatuses, and the operators of each apparatus may be different. Also, the holder of the hardware of the apparatus (provider of the cloud server) and the operator who actually operates the apparatus may be different. The application program and the settlement server cooperate to provide an electronic payment service. In the following description, the application program is referred to as a payment app. The electronic payment service is a service that supports the settlement related to the purchase of goods and services in a store. A store is, for example, a physical store (actual store) existing in the real space, but may include a virtual store for e-commerce. The virtual store may include those provided by a party different from the operator of the electronic payment service. In that case, when making a purchase settlement in the virtual store, it may be controlled to transition to the interface screen of the electronic payment service. In the electronic payment service, a store is, for example, treated as belonging to a franchise (brand), and processes such as settlement when a purchase action is performed in the store are mainly carried out between the user and the franchise. Instead of this, processes such as settlement may be carried out between the user and the store.

[0010] <First Embodiment> [Electronic Payment Service] Figure 1 shows an example of a configuration for realizing an electronic payment service. The electronic payment service is realized around a service provision system 80. The service provision system 80 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, and provider equipment.

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or tablet. The user terminal device 10 is a computer device having at least optical reading function, communication function, display function, input reception function, and program execution function. In the following description, the components for realizing these functions will be referred to as a camera, communication device, touch panel, CPU (Central Processing Unit), etc. In the user terminal device 10, the payment application 20 is executed by a processor such as the CPU, and it operates in cooperation with the payment server 100 to provide electronic payment services to the user. The payment application 20 is installed on the user terminal device 10, for example, from 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 may include a so-called POS (Point of Sale) device, and the product price acquisition function and 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 paper or plastic media. The store code image 60 may also 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, personal computer, etc. The affiliated store interface 72 operates on the second store terminal device 70. The affiliated store interface 72 may be an affiliated store application or a browser. The affiliated store interface 72 accepts coupon settings etc. from the affiliated store operator 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 by running the affiliated store application, or reading a code image displayed by the user terminal device 10.

[0014] The payment server 100 included in the service provision system 80 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 a merchant server, in which case payment information is transmitted from the POS device to the payment server 100 via the merchant server. In the following description, this will not be specifically distinguished, and it will be assumed that payment information is transmitted from the first store terminal device 50.

[0015] Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payments. There may be two patterns for electronic payments: Pattern 1 and Pattern 2.

[0016] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), 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 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the 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 later) from the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends 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 sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0017] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image such as a QR code or barcode that was generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is obtained in advance by barcode scanning or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

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

[0019] [Service delivery system] The service provision system 80 includes, for example, a payment server 100, an orchestrator 300, and multiple agents 400.

[0020] [Payment Server] Figure 4 is a diagram of the configuration of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a content provision unit 120, a payment processing unit 130, an information management unit 140, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted on a drive device.

[0021] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device accessible by the payment server 100 via a network. The storage unit 170 stores information such as user information 172, content information 174, and merchant / store information 176. Each piece of information will be described later.

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

[0023] The content provision unit 120, for example, has the functionality of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10, the merchant interface 72, etc. The content provision unit 120 reads the necessary content from the content information 174 as appropriate and provides it to the target device, etc. The user terminal device 10 receives various inputs from the user while the content is being played by the payment application 20 and transmits the aforementioned payment information, etc. to the payment server 100.

[0024] The payment processing unit 130 performs payment processing based on 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.

[0025] Figure 5 shows 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, user URL, account ID, phone number, password, as well as email address, user ID, name, address, date of birth, registration date, charge balance, credit payment settings, credit payment limit, credit payment amount, available credit payment amount, payment method settings, bank account, credit card number, charge history information, and payment history information.

[0026] The user URL is used for processing payments between users. When registering for the electronic payment service, registration of a phone number and password is required. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can optionally set (or not set). Similarly, the email address, name, address, and date of birth (age) are also information that the user can optionally set (or not set). If identity verification has been performed, for example, the address and age will be the address and age confirmed through identity verification. The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

[0027] The charge balance is information indicating the balance of electronic money set by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank) and sending from a registered bank account. The credit payment setting indicates whether or not the user has completed the settings to enable electronic payments by credit card, and is set to either "Completed" or "Not Completed". The credit payment limit is the monthly limit for credit payments, the credit payment amount is the amount already used for credit payments in the current month, and the available credit payment amount is the amount available for credit payments in the current month, calculated by subtracting the credit payment amount from the credit payment limit. While the diagram shows only one credit payment limit, in reality there are also daily limits, and the lower of these may be set as the credit payment limit. Further details on credit payments will be described later. The payment method setting indicates whether the user will use electronic payment with the charge balance or payment by credit card at that time. The bank account and credit card number information, respectively, refers to the bank account or credit card number (account number, card number) to which funds can be deposited into the electronic payment service. The charge history information is a record of when the user has previously sent money to the electronic payment service to increase the charge balance. The payment history information 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.).

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

[0029] The Information Management Unit 140 acquires various information from the user terminal device 10 or the second store terminal device 70 and manages the acquired information. Based on the information acquired from the user terminal device 10 or the second store terminal device 70, the Information Management Unit 140 manages user information 172 and affiliated store / store information 176. The Information Management Unit 140 performs operations such as adding, editing, and deleting new records for user information 172 and affiliated store / store information 176.

[0030] [Electronic payment] When the payment processing unit 130 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 172 to obtain the user's "payment method setting". 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, which is managed in association with the user ID, and increasing the value of the merchant's sales proceeds item. The merchant's sales proceeds item value is not used as electronic money itself, for example, but the amount corresponding to the sales proceeds item value is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service. The merchant may receive the sales proceeds as electronic money. In this case, the payment server 100 manages the account (wallet) corresponding to the merchant ID, the electronic money balance of the account, and the sales proceeds history for each payment method in association.

[0031] The payment processing unit 130 performs electronic payment as follows for users whose "settings information" is set to "credit payment". Credit payment is a payment method that cooperates with a credit card company, which is a separate entity from the operator of the electronic payment service, and allows electronic payment that does not depend on the charge balance within the credit limit. In order to use the credit payment service, it may be required to obtain a credit card provided by the operator of the electronic payment service. The payment processing unit 130 adds the payment amount to the credit payment usage amount in the user information 172 and subtracts the above payment amount from the available credit payment amount. If the payment amount exceeds the available credit payment amount, an error notification is sent back to the payment app 20. The amount used by credit payment is settled, for example, in a lump sum for one month on the payment date of the following month, for example, by direct debit from the bank account. This processing is performed by the operator of the credit card company. If the user has a gift certificate that can be used at the merchant, the payment server 100 performs electronic payment using the gift certificate held. In electronic payment, the amount that is insufficient with the gift certificate is settled by other payment methods.

[0032] The following describes the functional configuration and processing of Orchestrator 300 and Agent 400.

[0033] [Inquiry Interface Screen] When a user operates a user terminal device 10 (e.g., a payment application 20) and inputs an inquiry related to the electronic payment service, the service provision system 80 provides an answer to the inquiry to the user terminal device 10. Figure 7 shows an interface screen IF1 that illustrates an example of an inquiry and an answer to that inquiry. Interface screen IF1 displays the inquiry (Q) and the answer to the inquiry (A). When a user inputs an inquiry (Q), the answer (A) provided by the service provision system 80 is displayed. The answer is generated by the orchestrator 300 and the agent 400.

[0034] Furthermore, on the interface screen, users may enter information other than inquiries. For example, they may enter requests related to electronic payment services, such as "charge my account" or "send money." The orchestrator 300 identifies an agent 400 corresponding to the entered information and sends the user's request to the identified agent 400. The agent 400 provides the user with the service corresponding to the user's request. The agent 400 includes various agents, such as agents that output answers to inquiries (customer support agents), agents that provide payment-related services, and agents that provide money transfer services.

[0035] [Orchestrator] The orchestrator 300 determines which agent to distribute the information entered by the user. Figure 8 shows an example of the functional configuration of the orchestrator 300. The orchestrator 300 includes, for example, a category identification unit 310, an information processing unit 320, and a storage unit 330. The category identification unit 310 and the information processing unit 320 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted on a drive device.

[0036] The storage unit 330 can be an HDD, flash memory, RAM, etc. The storage unit 330 may also be a NAS device that can be accessed by the orchestrator 300 via a network. For example, category information 332 (details will be described later) is stored in the storage unit 330.

[0037] The category identification unit 310 identifies the category of the information entered by the user on the interface screen IF. The category identification unit 310 may identify the category by referring to identification information (not shown) stored in the memory unit, for example, or it may identify the category using a model.

[0038] For example, the identification information may include keywords and related expressions for each category. The category identification unit 310 identifies categories based on the degree of match and similarity between the words and expressions included in the information entered by the user and the keywords and expressions included in the identification information. For example, the category identification unit 310 uses language processing techniques such as distributed representations to identify categories using scores based on the degree of match and similarity.

[0039] Furthermore, the category identification unit 310 may identify a category based on the output of a model that has been trained to output a category corresponding to the information entered by the user. For example, the model identifies which category the information entered by the user matches from a given list of categories and outputs the identified category. For example, the category identification unit 310 inputs a list of categories, the information entered by the user, and a request to identify the category corresponding to the information entered by the user from the list of categories, and retrieves the category identified by the model. The model could be, for example, a Large Language Model (LLM) or an Artificial Intelligence (AI).

[0040] The information processing unit 320 identifies an agent corresponding to the specified category and provides the information entered by the user to the identified agent. Category information 332 is information that associates a category with an agent. The information processing unit 320 refers to the category information 332 to identify the agent corresponding to the category. For example, if the category is "inquiry (customer support)", the information entered by the user is provided to the inquiry (customer support) agent, and if the category is "money transfer", the information entered by the user is provided to the money transfer agent. In addition to the above, the categories may include various other categories such as electronic payment services, cash advances, investments, and points.

[0041] [agent] The following describes the inquiry (customer support) agent 400. Agent 400 provides answers to inquiries to the user. Agent 400 (processing unit 410, described later) acquires inquiry information provided by the user terminal device 10. Agent 400 (first information processing unit 430, described later) acquires multiple related pieces of information related to the inquiry information from the service-related information stored in the memory unit and assigns a degree of relevance to the related pieces of information. Agent 400 (second information processing unit 460, described later) inputs the related pieces of information with assigned degrees of relevance and the inquiry into a model (model 470, described later) that has been trained to output an answer to an inquiry when an inquiry is input, and provides the answer output by the model to the user terminal device 10.

[0042] Figure 9 is a diagram illustrating the functional configuration and processing of agent 400. Agent 400 comprises, for example, a processing unit 410, a model 420, a first information processing unit 430, a storage unit 440, a model 450, a second information processing unit 460, and a model 470. The processing unit 410, the first information processing unit 430, and the second information processing unit 460 are implemented, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be implemented by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or by the cooperation of software and hardware. The program may be stored in advance in a storage device such as an HDD or flash memory (a storage device with a non-transient storage medium), or it may be stored in a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed in the storage device when the storage medium is mounted on a drive device.

[0043] The storage unit 440 can be an HDD, flash memory, RAM, etc. The storage unit 440 may also be a NAS device that can be accessed by the agent 400 via a network. For example, related information 442 is stored in the storage unit 440.

[0044] Related information 442 includes, for example, information describing the service, information including pre-prepared questions and answers to those questions, and information showing how to solve problems. Related information 442 is, for example, various documents related to the service as described above.

[0045] Models 420, 450, and 470 are, for example, models that output information in response to requests. These models include, for example, Large Language Models (LLMs) and Artificial Intelligence (AI). Models 420, 450, and 470 are models trained to learn from large amounts of data and output responses in response to requests. Models 420, 450, and 470 may be different types of models or the same type of model. For example, Model 450 is a different type of model from Models 420 and 470, while Models 420 and 470 are the same type of model. The type of model that outputs information with high accuracy is selected depending on the task. Model 420 is an example of a "third model," Model 450 is an example of a "second model," and Model 470 is an example of a "first model." For example, the information provided to the above models and other functional units may be in JSON (JavaScript Object Notation) format or other formats.

[0046] The processing unit 410 obtains information (inquiries) entered by the user from the orchestrator 300. The processing unit 410 identifies the intent of the inquiry. When an inquiry is entered, the processing unit 410 outputs information indicating the intent of the inquiry. The inquiry is entered into the model 420, and the information indicating the intent of the inquiry output by the model 420 is obtained. For example, the processing unit 410 inputs a request to the model 420 to output the inquiry and its detailed content (for example, what kind of answer the user is seeking).

[0047] Model 420 is a model trained to output the intent of an inquiry (details of the inquiry and what kind of answer the user is seeking) when an inquiry is input. When an inquiry is input, Model 420 outputs information indicating the intent. For example, if the inquiry is "I want to know if I have verified my identity," Model 420 will output information such as "The user does not know whether they have verified their identity or not. The user wants to know on which screen they can find information indicating whether they have verified their identity or not." Model 420 may also be a Reasoning model. If the user's inquiry is ambiguous, Model 420 may output a question to the user to resolve the ambiguity, obtain an answer to the question, and then identify the intent of the inquiry based on the answer. As described above, Model 420 may be a model trained to output a question regarding the inquiry when an ambiguous inquiry is input, and then identify the intent of the inquiry based on the answer to the question.

[0048] The processing unit 410 outputs information indicating the intent of the query output by the model 420 to the first information processing unit 430, as described above. However, the acquisition of the above intent information may be omitted, and the user's query may be provided to the first information processing unit 430.

[0049] The first information processing unit 430 obtains reference information related to the intent (inquiry) from the related information 442. For example, if the inquiry concerns identity verification as described above, the first information processing unit 430 obtains related information 442 related to identity verification. For example, documents showing how to perform identity verification, documents showing how to perform verification if identity verification has already been performed, and documents about services or benefits that can be received if identity verification has been completed are obtained.

[0050] The first information processing unit 430 inputs multiple related information 442 to a model 450 that has been trained to assign a degree of relevance to the related information 442 when multiple related information 442 are input, and assigns a degree of relevance to each of the related information 442 based on the results output by the model 450. Assigning a degree of relevance includes the first information processing unit 430 causing the model 450 to assign a degree of relevance. The first information processing unit 430 inputs the acquired related information 442 and a prompt including instructions. The instructions are, for example, instructions to rank the related information 442 based on their relevance to the intent of the query. For example, a ranking is assigned to each document.

[0051] Model 470 is a model trained to output an answer to an inquiry based on the ranking results and ranked related information 442, given the above instructions, the inquiry (or information indicating the intent of the inquiry), the ranking results, and the ranked related information 442 as input. For example, if the documents showing how to verify identity if it has been verified, the documents showing how to perform identity verification, and the documents about services or benefits available to verified individuals are ranked in this order, and the inquiry is "I want to know if I am verified," Model 470 will prioritize using the document showing how to verify identity if it has been verified to generate an answer. For example, Model 470 will use the ranking results to output an appropriate answer to the inquiry, such as "If you operate ... on the home screen, if you are verified, information indicating that you are verified will be displayed in .... If you are not verified, we will explain how to perform identity verification...."

[0052] The second information processing unit 460 may also identify a predetermined number of related information items 442 (documents up to the 10th position) from the ranking and input the identified related information items 442 and the ranking into the model 470. As a result, the model 470 will use the related information items 442 with a high degree of relevance, and a highly accurate response will be output.

[0053] Furthermore, although the above explanation assumes that the ranking of related information 442 is used, instead, the relevance of related information 442, such as a score, may be used. In this case, model 450 assigns a relevance score to each document of related information 442, and the second information processing unit 460 inputs the documents of related information 442, the document relevance scores, and the query to model 470, causing model 470 to output an answer. By using an absolute evaluation such as a score, information with a higher relevance is used to generate an answer, resulting in a more accurate answer. Note that in the above, related information 442 with a relevance score above a threshold, or related information 442 that is above a threshold and a predetermined number may be used.

[0054] According to the first embodiment described above, the agent 400 acquires inquiry information provided by the user terminal device 10, acquires multiple related pieces of information related to the inquiry information from the service-related information stored in the storage unit 440, assigns a degree of relevance to the related pieces of information, inputs the related pieces of information with assigned degrees of relevance and the inquiry into a model 470 that has been trained to output an answer to the inquiry when the inquiry is input, and provides the answer output by the model 470 to the user terminal device 10, thereby helping to improve the convenience of the user or service provider.

[0055] <Second Embodiment> The second embodiment will be described below, focusing on the differences from the first embodiment.

[0056] [Electronic payment service] Figure 10 shows an example of a configuration for realizing the electronic payment service of the second embodiment. In this embodiment, the payment application 20 incorporates an AI assist application 20A. The AI ​​assist application 20A accepts natural language input from the user and, in cooperation with the AI ​​assist function unit 150 of the payment server 100 (described later), provides a function to execute processing in a conversational format in response to the user's request. The AI ​​assist application 20A may be a thin client application that displays input / output information from the AI ​​assist function unit 150 (described later), or it may include some or all of the functions of the AI ​​assist function unit 150. Alternatively, the AI ​​assist application 20A may be a web browser application that displays input / output information from the AI ​​assist function unit 150.

[0057] The LLM server 800 included in the configuration for realizing the electronic payment service is a server device such as a web server. The LLM server 800 is equipped with a large language model (LLM) that has been trained to receive user input information and prompts as text from the payment server 100 and generate inference results as text according to the received content. More specifically, the LLM server 800 interprets the user's intent in response to a request from the orchestrator unit 150A (described later) and determines which agent unit 150B should execute the processing. The LLM server 800 also breaks down the processing that the agent unit 150B should execute into multiple tasks in response to a request from the agent unit 150B, determines the UI components to be used in each task, and notifies the agent unit 150B. In this embodiment, the LLM server 800 is installed outside the payment server 100, but the present invention is not limited to such a configuration, and the LLM server 800 may be part of the functions of the payment server 100 (for example, the AI ​​assist function unit 150). The large-scale language model installed in the LLM server 800 is an example of "LLM". For the sake of brevity of explanation, even if a process is executed by the LLM server 800, if it is a process requested by the orchestrator unit 150A or the agent unit 150B, these orchestrator unit 150A or agent unit 150B may be referred to as the subject (i.e., the operator) in the description.

[0058] [Payment Server] Figure 11 is a configuration diagram of a payment server 100 according to the second embodiment. The payment server 100 includes, for example, a communication unit 110, a content provision unit 120, a payment processing unit 130, an information management unit 140, an AI assist function unit 150, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into the drive device.

[0059] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device accessible by the payment server 100 via the network. The storage unit 170 stores information such as user information 172, content information 174, and merchant / store information 176. In addition, the storage unit 170 stores orchestrator prompts 178, agent prompts 180, document information 182, API information 184, and UI component information 186, which are used by the AI ​​assist function unit 150. This information will be described later.

[0060] [Top screen] Figure 12 shows an example of the top screen of the payment app 20. The top screen displays a code image CI. The code image CI includes, for example, barcodes and QR codes. Next to the code image CI is a toggle switch SW for switching between electronic payment using the charged balance or electronic payment using credit. Note that "switch" and "button" are GUIs (Graphical User Interfaces) implemented in cooperation with the touch panel. In Figure 12, "Credit" is displayed, which means that the setting is to perform electronic payment using credit. The user can switch between electronic payment using the charged balance or electronic payment using credit by, for example, swiping the toggle switch SW. The top screen also includes an operation area OA, transition buttons TB1 and TB2. The operation area OA is equipped with buttons that instruct major operations in electronic payment, such as a button to instruct scanning (start user scanning), a button to send the charged balance to other users, a button to display points earned by the user, and a button to display the history of electronic payments performed by the user. When the transition button TB1 is pressed, the user transitions to a payment screen that displays the code image used for electronic payment and the available balance. When the transition button TB2 is pressed, the user transitions to a screen that displays the available balance for either balance payment or credit payment. In Figure 12, since electronic payment using the charged balance is set, when the transition button TB2 is pressed, the available balance for balance payment is displayed.

[0061] At the bottom of the operating area OA, for example, a group of buttons (switches) M1, M2, ... for launching mini-applications are displayed. A mini-application is an application that operates using the payment application 20 as a platform and provides some kind of service. The service provider develops the mini-application by referring to the SDK (Software Development Kit), which consists of application development programs and technical documents provided by the administrator of the payment application 20. A mini-application is an application that operates when the payment application 20 is running. For example, when the payment application 20 is installed, some or all of the mini-application may be installed, or some or all of the mini-application may be installed from the service server corresponding to the mini-application. For example, when a mini-application is launched, it accesses a service server (not shown) that provides the service corresponding to the mini-application, and the mini-application and the service server cooperate to provide the service to the user. In this case, the service server may be the payment server 100 itself, or it may be an external server different from the payment server 100. In Figure 12, as an example, a button M1 for launching the AI ​​assist app 20A and a button M2 for a mini-app that provides a function to view information about coupons offered by participating stores are displayed. However, buttons for launching various types of mini-apps may be displayed, such as an investment app for managing the charge balance or a payment app for paying public transport fares.

[0062] [AI Assist Function] The AI ​​assist function unit 150 performs natural language processing and dialogue control in response to requests from the AI ​​assist application 20A. The AI ​​assist function unit 150 comprises an orchestrator unit 150A and multiple agent units 150B. The orchestrator unit 150A is responsible for determining the agent unit 150B best suited for the processing based on the input information received from the user terminal device 10 and requesting the processing. Multiple agent units 150B are provided to correspond to each function of the electronic payment service (e.g., help, remittance, charge, etc.), and function as a kind of MCP (Model Context Protocol) server, holding document information 182 that defines the processing it can execute and API information 184 for calling functions that execute these processing as a catalog of tools. Thus, in this embodiment, the agent unit 150B has the functions of both an LLM client that utilizes the LLM server 800 and an MCP server.

[0063] The orchestrator unit 150A is responsible for determining which agent unit 150B (MCP server) is best suited for the processing based on the input information received from the user terminal device 10, and for requesting processing from that agent unit 150B. In addition, the orchestrator unit 150A manages context information (memory), such as the history of past interactions with the user executed on the AI ​​assist application 20A, and uses this context information when determining which agent unit 150B to use. For example, if the user has previously requested a money transfer on the AI ​​assist application 20A, and the current input information from the user is similar to that past transfer request, the orchestrator unit 150A uses this context information to request processing from the agent unit 150B that handles the money transfer. Each agent unit 150B that receives a request executes the processing of its assigned function in accordance with the request from the orchestrator unit 150A.

[0064] Figure 13 shows a scene where a user launches the AI ​​Assist app 20A and enters a request in natural language. The screen shown in Figure 13 is accessed, for example, by the user operating the "AI Assist" button M1 displayed on the top screen of the payment app 20. In other words, the AI ​​Assist app 20A may be implemented as a mini-app developed on the electronic payment service. As shown in Figure 13, the user enters input information IN, for example, "I want to send 3,000 yen to person A," in text or voice. The input information IN may include various contents related to the electronic payment service, such as questions from the user about the electronic payment service or requests to execute functions. The AI ​​Assist app 20A sends this input information IN to the payment server 100.

[0065] When the orchestrator unit 150A of the payment server 100 receives input information IN, it determines which agent unit 150B to request processing from. This determination process is performed using the LLM server 800. The orchestrator unit 150A functions as an "acquisition unit" that acquires information, but the acquisition unit as a software function unit that receives input information IN may be provided independently of the orchestrator unit 150A.

[0066] Figure 14 shows an example of an orchestrator prompt 178 that the orchestrator unit 150A inputs to the LLM server 800. The orchestrator prompt 178 includes instruction A1 that instructs the LLM on the role it should play as an orchestrator, information A2 that defines a list of available agents, and a reference A3 to document information 182 that describes the detailed specifications of each agent. In the example in Figure 14, the available agents are defined as a help agent, a remittance agent, a charge agent, and a coupon agent. As shown in Figure 14, information A2 may include a description of the function of each agent in addition to the list of agents. Also, although only the names of the available agents are listed in Figure 14 for the sake of brevity, in reality, it would include the endpoint (URL) of each agent.

[0067] The help agent is an agent that answers questions from users regarding the electronic payment service. The help agent generates answer results by referring to document information 182 and web information. The remittance agent is an agent that performs the process of sending the electronic money balance from one user to another. The charge agent is an agent that performs the process of charging (depositing) the electronic money balance of a user. The coupon agent is an agent that performs the process of searching for, obtaining, and using coupons available for the electronic payment service. The help agent is, for example, agent 400. As described in the first embodiment, the help agent obtains answers to questions from users and provides the obtained answers to the AI ​​assist application 20A. For example, the answers are provided via the payment server 100.

[0068] Here, we will explain in more detail how the LLM server 800 refers to document information 182. In this embodiment, the LLM server 800 improves the accuracy and reliability of the responses it generates by using a technique called Retrieval-Augmented Generation (RAG).

[0069] Specifically, the payment server 100 pre-divides the document information 182 (for example, the help page for the electronic payment service, the functional specifications for each agent, the terms of use, etc.) into predetermined units (chunks). This document information 182 constitutes the knowledge base in this invention. The text information of each chunk is then converted into a numerical vector (embedding) that reflects its semantic content and stored in the vector DB in the storage unit 170.

[0070] When user input information IN or an internal processing request occurs, the LLM server 800 first vectorizes the content of the request. Next, it searches the vector database using this vector and retrieves one or more chunks that have the highest semantic similarity (i.e., are most relevant to the request) as search results. In other words, the LLM server 800 can retrieve the portion of the document that is appropriate to the user's intent as context from the knowledge base. Based on the information retrieved as search results, the LLM server 800 then understands processes such as money transfers and charges. With this configuration, the LLM server 800 can always perform inferences based on accurate and up-to-date document information 182, rather than relying solely on the knowledge inherent in the large-scale language model. This method of vectorizing input information IN and retrieving information can also be executed by the LLM server 800 by specifying it in the orchestrator prompt 178 or the agent prompt 180.

[0071] As described above, the agent unit 150B in this embodiment can be classified into several types according to its role. For example, the agent unit 150B includes a first-type agent unit and a second-type agent unit.

[0072] The first type of agent unit is an agent that generates answers to user questions by referring to document information 182 stored in the memory unit 170. The "Help Agent" shown in Figure 14 corresponds to this. The Help Agent's primary purpose is to provide information, rather than executing APIs to change external states.

[0073] The second type of agent unit is an agent that breaks down the processing requested by the orchestrator unit 150A into multiple tasks and executes those tasks using APIs. The "transfer agent" and "charge agent" shown in Figure 14 are examples of this. These agents call APIs provided by the settlement server 100 to actually change the user's charge balance and perform transfers or charges. In this way, the orchestrator unit 150A appropriately distributes multiple agents with different characteristics, making it possible to respond to a variety of user requests through a single interface.

[0074] The orchestrator unit 150A combines the orchestrator prompt 178 with the user's input information IN ("I want to send 3,000 yen to person A.") and sends it to the LLM server 800. The LLM server 800 infers the user's intent from the input information and determines the most appropriate agent unit 150B. In this embodiment, the LLM server 800 determines the "transfer agent" and returns the result to the orchestrator unit 150A.

[0075] When the orchestrator unit 150A receives a decision result of "remittance agent" from the LLM server 800, it requests the remittance process from the agent unit 150B, which is responsible for the remittance function. Upon receiving the request, the agent unit 150B breaks down the requested process (remittance) into multiple tasks and executes the decomposed tasks. This task decomposition process is also performed using the LLM server 800. In other words, the agent unit 150B, which uses the LLM server 800, is an example of a "task execution unit".

[0076] Figure 15 shows an example of an agent prompt 180 that the agent unit 150B inputs to the LLM server 800. The agent prompt 180 is, for example, a template format containing variables, and its contents are dynamically set at runtime. This prompt includes instruction A4, which instructs the LLM on the role it should play as a specific agent (in this example, "$agnt"). This prompt functions as a single template, and the variables are dynamically replaced with specific function names such as "transfer" and "charge" depending on the type of agent determined by the orchestrator unit 150A. This eliminates the need to prepare separate prompts for each type of agent, simplifying the overall system management.

[0077] Furthermore, by adopting a template format that includes variables, it will not be necessary to create new prompts when adding new agent units 150B in the future, such as an "invoice payment agent." Simply preparing the specifications for the new function (document information 182 and API information 184) will allow existing prompt templates to be reused to support the new function. This enables rapid and efficient service expansion.

[0078] Instruction A4 states that the requested process should be broken down into tasks, and these tasks should be executed sequentially using the API while interacting with the user using common UI components. The prompts also include a reference A5 to document information 182, which describes the detailed specifications of the function to be handled; a reference A6 to API information 184, which describes the specifications of the available APIs; and a reference A7 to UI component information 186, which describes the specifications of the common UI components described later. Furthermore, rule A8 defines behavior according to the type of agent (whether it is a Type 1 agent or not), preset and confirm the task content from the input information IN, a rule to thoroughly confirm with the user at the end, and referencing user information 172 as needed.

[0079] Here, we will explain a specific example of API information 184. API information 184 is a structured document that defines, for example, the endpoint for calling the API, the HTTP method, the required parameters, and the format of the response. For example, the API information for the remittance function referenced by the "remittance agent" defines that in order to execute the remittance process, the POST HTTP method should be used and a request should be sent to a predetermined endpoint URL. At that time, it is stipulated that the request should include parameters indicating the sender's account ID, the recipient's account ID, and the remittance amount as required parameters, and that it may optionally include a parameter indicating a memo. Furthermore, API information 184 defines that a success notification will be returned as a response if the process is successful, and a failure notification will be returned if an error occurs, such as insufficient balance. For example, some parameters such as the idempotency key are system parameters and are automatically entered. The agent unit 150B collects the information necessary for these requested parameters through interaction (tasks) with the user and executes the function by sending an API request to the settlement processing unit 130, etc., according to the definition in this API information 184. Typically, the agent unit 150B may divide the task into units corresponding to the number of parameters in the API for each process (e.g., a money transfer process).

[0080] The agent unit 150B sends an agent prompt 180 with "$agnt" set to "Transfer" combined with user input information IN to the LLM server 800. Based on this information, the LLM server 800 breaks down the transfer process into multiple tasks, such as "Recipient Input Task," "Transfer Amount Input Task," "Memo Addition Task," and "Final Confirmation Task," determines the UI components to be used in each task, and returns the results to the agent unit 150B.

[0081] The agent unit 150B initiates interaction with the user terminal device 10 based on the task and UI component specifications returned from the LLM server 800. The agent unit 150B generates a UI screen by combining predefined common UI components and sends it to the user terminal device 10. In other words, the agent unit 150B, which uses the LLM server 800, is an example of a "screen generation unit". In this case, the agent unit 150B may not communicate directly with the user terminal device 10 itself, but may instead entrust communication with the user to the orchestrator unit 150A. In that case, the agent unit 150B only needs to pass on the task and UI components to the orchestrator unit 150A.

[0082] [Using common UI components] Figure 16 shows an example of common UI components defined in UI component information 186. These components include a task display box (TSK) that encloses the entire task, an image and name display component (IM), a transition button (BT) used for transitioning to the next task, a numerical input box (NI) for entering numerical values ​​such as amounts, a text box (TB) for entering text, and a search box (SB) for performing keyword searches. The agent unit 150B dynamically generates an interactive screen (server-driven UI) by combining these components. These components can be classified according to their roles. For example, the task display box (TSK) that encloses the entire task and the image and name display component (IM) are examples of "task display components". Also, the numerical input box (NI) for entering numerical values ​​such as amounts, the text box (TB) for entering text, and the search box (SB) for performing keyword searches are examples of "task processing components" used by the user to process tasks. Furthermore, the transition button (BT) used for transitioning to the next task is an example of a "task transition component".

[0083] More specifically, for example, UI component information 186 stores the definition information for each UI component in a structured data format (e.g., JSON, XML, or a database table). Each component is defined by several parameters that specify its type, appearance, and behavior. For example, UI component information 186 holds information such as at least the "Component ID," "Component Type," and "Parameter Set" for each component. The "Component ID" is an identifier that uniquely identifies each component. The "Component Type" is information that indicates which type the component belongs to, as exemplified in Figure 16, such as a task display box (TSK), a transition button (BT), or a numerical input box (NI).

[0084] The "parameter set" includes detailed parameters for controlling the specific display content and layout of a component. For example, a transition button (BT) would include parameters that define visual elements such as "display text" (e.g., "Yes", "Next"), "width", "height", "background color", and "font size". Similarly, an image and name display component (IM) would define parameters such as "image URL", "display name text", and "image size".

[0085] Furthermore, these parameters can also define "actions" that should be performed in response to user actions (e.g., tapping a button). For example, the parameters of a transition button (BT) can define the "action type" (e.g., "task completion notification," "API execution command") and the API endpoint that should be called in conjunction with that action.

[0086] The LLM server 800 refers to this UI component information 186 when breaking down tasks in response to a request from the agent unit 150B. It then dynamically constructs the layout information of the UI screen to be displayed on the user terminal device 10 by selecting the UI components required for each task and specifically setting their parameter sets. The agent unit 150B receives this layout information constructed by the LLM server 800 and transmits it to the user terminal device 10. The AI ​​assist application 20A on the user terminal device 10 receives this layout information and draws the screen accordingly. This configuration makes it possible to provide diverse and flexible interactive screens with only server-side control.

[0087] Furthermore, the large-scale language model installed in the LLM server 800 may be pre-trained (fine-tuned) based on the contents of the UI component information 186 in order to effectively utilize the common UI components used in this embodiment. This training is performed, for example, using training data that links various processes (e.g., money transfer, charging, age verification, coupon acquisition, etc.) and tasks expected within an electronic payment service with candidate UI components (included in the UI component information 186) that are most suitable for executing those processes and tasks. Here, the training data may be data that has been manually mapped in advance by the administrator of the LLM server 800, or it may be the document information 182 itself, or the document information 182 from which processes and tasks and candidate UI components are mapped. By performing such pre-training, the large-scale language model learns which UI components should be selected and combined as candidates from the UI component information 186 for which tasks. As a result, when it receives a task decomposition instruction from the agent unit 150B, the accuracy of generating efficient and appropriate UI screen layout information that is more in line with the user's intent is improved.

[0088] Furthermore, or instead of pre-training, the large-scale language model can dynamically learn the mapping between tasks and UI components from the document information 182. Specifically, when the LLM server 800 receives an instruction from the agent unit 150B to execute a specific task (e.g., "Task to input the transfer amount"), it first searches the vector database using the task name as a query. The document information 182 includes developer documentation that explains the specifications of each task, and includes descriptions such as, "In the transfer process, a numerical input box (NI) and a transition button (BT) are used to present the amount to the user and request confirmation," as well as images representing actual screen examples. Through the RAG mechanism, a chunk containing this description is obtained as a search result and provided to the LLM server 800 as prompt context information.

[0089] By referring to this contextual information, the LLM server 800 can select appropriate UI components based on the document description and generate UI screen layout information, even for unknown tasks not present in the training data. In this way, the LLM server 800 determines its operation self-referentially by using the document describing its own specifications as the learning source. This makes it possible to flexibly extend the system's behavior when adding new tasks or UI patterns by simply updating the document information 182, without having to retrain the large-scale language model.

[0090] [Specific examples of money transfer processing] The following describes a specific example of a money transfer process using the AI ​​assistance function, with reference to Figures 17 to 21. Figure 17 is a screen transition diagram showing the input task for the recipient in the money transfer process. First, the agent unit 150B executes the first task, the "recipient input task". As shown in Figure 17, the agent unit 150B generates a UI screen in which a component (USR) that displays the user's image and name, a transition button (BT1), and a search box (SB1) are placed within a task display box (TSK1), and displays it on the user terminal device 10. From the information "Mr. A" included in the user's input information IN, the agent unit 150B searches the user information 172 and displays the information of the most likely candidate "A". If no candidate is found, the agent unit 150B may display only the search box (SB1) along with text information such as "Mr. A was not found". When the user presses the "Yes" button (BT1), the task is considered complete, and the AI ​​assist app 20A sends the details of the process to the agent unit 150B.

[0091] Next, the agent unit 150B executes the "transfer amount input task". Figure 18 is a screen transition diagram showing the transfer amount input task in the transfer process. As shown in Figure 18, the agent unit 150B generates a UI screen in which a numerical input box (NI1) and a transition button (BT2) are placed within a task display box (TSK2). At this time, the information "3000 yen" included in the input information IN is pre-set in the numerical input box (NI1). When the user operates the "Next" button (BT2), the task is completed. When the user operates the "Next" button (BT2), the agent unit 150B may use an API to check whether the user's transfer amount meets the conditions (i.e., whether it is less than or equal to the charge balance) and complete the "transfer amount input task" only if the user's transfer amount meets the conditions.

[0092] Next, the agent unit 150B executes the "add memo task." Figure 19 is a screen transition diagram showing the memo addition task in the remittance process. As shown in Figure 19, the agent unit 150B generates a UI screen in which a user input text box (TB1) and a transition button (BT3) are placed within a task display box (TSK3). The user enters a memo as desired and operates the "Next" button (BT3).

[0093] Next, the agent unit 150B performs a "final confirmation task" before executing the remittance function. This is based on the rules of the agent prompt 180 (A8 in Figure 15). Figure 20 is a screen transition diagram showing the final confirmation task before executing the remittance process. As shown in Figure 20, the agent unit 150B generates a UI screen in a task display box (TSK4) that specifies the recipient and amount, and includes a "Yes" button (BT4) prompting final confirmation. When the user operates the "Yes" button (BT4), all tasks are considered complete.

[0094] Once final confirmation is obtained, the agent unit 150B calls the API for executing the remittance based on the API information 184 and requests the settlement processing unit 130 to perform the actual remittance. The settlement processing unit 130 refers to the user information 172 and performs the remittance by subtracting the remittance amount from the user's charge balance and adding the remittance amount to the recipient's charge balance. Figure 21 is a screen transition diagram that notifies the user that the remittance process is complete. Once the processing by the settlement processing unit 130 is complete, the agent unit 150B displays a screen on the user terminal device 10 notifying that the remittance is complete, as shown in Figure 21, and terminates the series of processes.

[0095] Thus, the LLM server 800 breaks down the remittance process into three tasks, excluding the final confirmation task: "Recipient Input Task," "Remittance Amount Input Task," and "Memo Addition Task." This is because the remittance API used to execute the remittance process includes three fields as parameters: "Recipient" (e.g., user's account ID), "Remittance Amount," and "Memo." Therefore, the orchestrator prompt 178 may include instructions such as, "When breaking down the tasks, refer to the parameters of the API necessary to execute the $agnt process."

[0096] [Specific examples of charging processes] Next, with reference to Figures 22 to 24, a specific example of the charge process using the AI ​​assist function will be explained. Figure 22 is a screen transition diagram showing the input task for the charge amount in the charge process. As shown in Figure 22, the user inputs input information IN, for example, "I would like to charge 3000 yen," in text or voice. The AI ​​assist application 20A sends this input information IN to the payment server 100. Next, the orchestrator unit 150A sends the received input information IN to the LLM server 800 for interpretation, and as a result selects "Charge Agent".

[0097] Agent unit 150B, which is responsible for the charge agent, breaks down the requested process into two tasks: the "charge amount input task" and the "final confirmation task". It then executes the first task, the "charge amount input task". As shown in Figure 22, agent unit 150B generates a UI screen with a numerical input box (NI2) and a transition button (BT2) placed in the task display box (TSK1), and displays it on the user terminal device 10. At this time, the information "3000 yen" included in the user's input information IN is pre-set in the numerical input box (NI2). When the user operates the "Next" button (BT2), the task is considered complete, and the processing details are sent to agent unit 150B.

[0098] Next, the agent unit 150B performs a "final confirmation task" before executing the charge process. Figure 23 is a screen transition diagram showing the final confirmation task before the charge process is executed. As shown in Figure 23, the agent unit 150B generates a UI screen in the task display box (TSK2) that clearly states the amount to be charged and includes a "Yes" button (BT4) prompting final confirmation. When the user operates the "Yes" button (BT4), all tasks are considered complete.

[0099] Once final confirmation is obtained, the agent unit 150B calls the API for charge execution based on the API information 184 and requests the payment processing unit 130 to perform the actual charge processing. Figure 24 is a screen transition diagram that notifies the user that the charge processing is complete. When the processing by the payment processing unit 130 is completed, the agent unit 150B displays a screen on the user terminal device 10 notifying that the charge is complete, as shown in Figure 24, and terminates the series of processes.

[0100] [Error handling] Although the above describes an example where a task is completed successfully, the agent unit 150B can also be configured to handle errors during task execution. More specifically, for example, the agent prompt 180 can be configured to "notify the orchestrator unit 150A with detailed error information if an API execution error occurs" and "restart the task when the orchestrator unit 150A notifies it that the error has been resolved," and the orchestrator prompt 178 can be configured to "start the error resolution process when the agent unit 150B notifies it of an error" and "notify the agent unit 150B that the error has been resolved."

[0101] Figure 25 shows an example of the processing flow when an error occurs. Figure 25 illustrates an example where a user attempts to send 3,000 yen even though they only have a charge balance of 2,000 yen. In this case, for example, an error occurs in the "Inputting the transfer amount task" because the transfer amount exceeds the charge balance, and the agent unit 150B takes over processing to the orchestrator unit 150A. As a result, the orchestrator unit 150A decides to start the process to resolve the error, i.e., to start the charge process, and requests the agent unit 150B, which is the charge agent, to perform the process.

[0102] Once the charge process is complete, the orchestrator unit 150A returns the process to the agent unit 150B, which is the remittance agent. The agent unit 150B then completes the remittance process after going through the "add memo task" and the "final confirmation task for the charge process." In Figure 25, an error occurs in the "enter remittance amount task" as an example, but it is also possible that an error may occur at the time when the remittance process is finally executed after going through the "final confirmation task for the remittance process." In that case, the process transitions from the "final confirmation task for the remittance process" to the charge process, and after the charge is completed, it returns to the "final confirmation task for the remittance process" again to complete the remittance process. In this way, by appropriately configuring the orchestrator prompt 178 and the agent prompt 180, even if an error occurs during the processing by one agent unit 150B, the process can be taken over to another agent unit 150B and the original intended process can be completed.

[0103] Figure 25 illustrates an example where the charge agent takes over processing in response to an error that occurs while the remittance agent is executing a process. However, the present invention is not limited to such a configuration. Depending on user input information IN and demands, the orchestrator unit 150A may coordinate multiple processes by multiple agent units to execute each agent unit's process sequentially. For example, if a user inputs "I want to charge 3000 yen and then send 1000 yen to person A" as input information IN, the orchestrator unit 150A may first request processing from the charge agent, and then request processing from the remittance agent. In that case, the charge agent will first execute the tasks shown in Figures 22 and 23, and then the remittance agent will execute the tasks shown in Figures 17 to 20. In this way, even if a user inputs complex input information IN containing multiple intentions, the orchestrator unit 150A's coordination allows the user to achieve their objective by processing the tasks as instructed.

[0104] [Summary of processing flow] Figure 26 is a sequence diagram showing an example of the processing flow of the AI ​​assist function. First, when the user inputs information into the AI ​​assist application 20A (S11), the AI ​​assist application 20A sends the input information to the orchestrator unit 150A of the payment server (S12). The orchestrator unit 150A sends the input information and the orchestrator prompt 178 to the LLM server 800 (S13) and requests the server to determine the agent unit 150B to which the request will be made. The LLM server 800 determines the agent unit 150B (S14) and notifies the orchestrator unit 150A (S15).

[0105] The orchestrator unit 150A passes the input information to the determined agent unit 150B and requests processing (S16). The agent unit 150B sends the input information and agent prompts to the LLM server 800 (S17) and requests that the processing be broken down into tasks and the UI components for each task be determined. The LLM server 800 performs the task breakdown and UI component determination (S18) and notifies the agent unit 150B (S19).

[0106] The agent unit 150B transmits information about the determined task and UI components to the AI ​​assist application 20A via the orchestrator unit 150A, and displays the screen (S20). When the user operates the screen and processes the task (S21), the processing details are transmitted from the AI ​​assist application 20A to the agent unit 150B (S22). The agent unit 150B relays the task processing details to the LLM server 800, and the LLM server 800, depending on the task processing details, completes the processing by coordinating with other internal functions (such as the payment processing unit 130) using an API, for example (S23), and notifies the agent unit 150B of the completion of the processing (S25). The agent unit 150B then notifies the AI ​​assist application 20A of the completion of the processing (S26), and the series of processes ends.

[0107] Note that in the sequence diagram in Figure 26, the processes from S19 to S24 are shown as a single process (i.e., a single task process). However, if there are multiple processing tasks, the processes from S19 to S24 will loop.

[0108] According to the second embodiment described above, based on the input information entered by the user of the electronic payment service, the orchestrator unit determines an appropriate agent unit from among multiple agent units and requests processing. The determined agent unit breaks down the requested processing into multiple tasks and executes the tasks while interacting with the user through a UI screen generated using common UI components. As a result, the user can use various functions of the electronic payment service, such as sending money and charging, simply by entering requests in natural language, without having to perform complex operations. In other words, according to this embodiment, the AI-assisted functions in the electronic payment service can be improved for the user.

[0109] Furthermore, according to this embodiment, since task flows and UI screens to respond to user requests are dynamically generated on the LLM server 800 side, new functions (new agent units) can be added or existing functions (existing agent units) can be flexibly modified simply by preparing the specifications for the new functions (document information 182 and API information 184) without updating the AI ​​assist application 20A, which is the client application. This increases the development efficiency and scalability of the AI ​​assist service. In other words, according to this embodiment, developers can improve the AI ​​support functions in electronic payment services.

[0110] For example, in response to questions and requests from users of electronic payment services, it was sometimes impossible to select the appropriate AI agent to provide support and execute the necessary processing, resulting in an inability to respond to user requests in the most optimal way. Furthermore, even when processing was to be performed by each AI agent, developers needed to design appropriate tasks and UI components for each AI agent, indicating room for improvement in AI support functions in electronic payment services for both users and developers. In addition, when a single platform like an electronic payment service contains a wide variety of functions (tools) such as money transfer, top-up, and coupon search, there was a challenge in how to integrate these with LLM. In particular, technologies like MCP (Model Context Protocol) presuppose the existence of a general-purpose client centered around LLM, but such a client often does not exist for proprietary services.

[0111] In the second embodiment, the AI-assisted functionality in the electronic payment service can be improved. Furthermore, since users can achieve their goals using natural language without having to learn complex screen operations, usability can be improved. In addition, developers can quickly expand functionality by simply changing server-side settings, thereby increasing development efficiency and service scalability.

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

[0113] 10. User terminal device 80 Service Delivery System 100 Payment Servers 300 Orchestrators 310 Category Identification Section 320 Information Processing Unit 332 Category Information 400 Agents 410 Processing Unit 420 Model 430 First Information Processing Unit 440 Storage section 442 Related Information 450 Model 460 Second Information Processing Unit 470 Model

Claims

1. A processing unit that acquires inquiry information provided by the user terminal device, From the service-related information stored in the memory unit, multiple pieces of related information related to the query information are obtained. A second model, which has been trained to rank related information based on its relevance when multiple related pieces of information are input, receives an instruction to rank the multiple related pieces of information based on their relevance to the intent of the inquiry, and a first information processing unit receives the multiple related pieces of information and obtains the ranking of the related information output by the second model. A second information processing unit identifies a predetermined number of related information items, including the top two or more related information items, and inputs the identified related information items, the ranking, and the query into a first model that has been trained to output a response to the query when the query is input, and provides the response output by the first model using the predetermined number of related information items, including the top two or more related information items, and the ranking to the user terminal device. An information processing device equipped with the following features.

2. The processing unit inputs the query to a third model that has been trained to output the intent for the query when the query is input, and obtains the intent information for the query output by the third model. The first information processing unit obtains a plurality of related pieces of information related to the intent information of the query from the service-related information stored in the memory unit. The information processing apparatus according to claim 1.

3. The first model and the second model are different types of models. The information processing apparatus according to claim 1 or 2.

4. The aforementioned related information includes information describing the content of the service, information including pre-prepared inquiries and answers to those inquiries, and information indicating solutions to problems. The information processing apparatus according to claim 1 or 2.

5. The aforementioned inquiry is an inquiry related to the aforementioned service, The aforementioned service is an electronic payment service. The information processing apparatus according to claim 1 or 2.

6. Computers The inquiry information provided by the user terminal device is obtained. From the service-related information stored in the memory unit, multiple pieces of related information related to the query information are obtained. When multiple pieces of related information are input, a second model, which has been trained to rank the related information based on its relevance, is given instructions to rank the multiple pieces of related information based on their relevance to the intent of the query, and the multiple pieces of related information are input, and the ranking of the related information output by the second model is obtained. The ranking identifies a predetermined number of related information items, the ranking, and the query, and the identified related information items, the ranking, and the query are input to a first model that has been trained to output a response to the query when the query is input. The response output by the first model using the ranking and the predetermined number of related information items, the ranking, is provided to the user terminal device. Information processing methods.

7. On the computer, The system retrieves the inquiry information provided by the user terminal device. From the service-related information stored in the memory unit, multiple related pieces of information related to the query information are obtained. A second model, which has been trained to rank related information based on its relevance when multiple related pieces of information are input, is given instructions to rank the multiple related pieces of information based on their relevance to the intent of the inquiry, along with the multiple related pieces of information, and the ranking of the related information output by the second model is obtained. The ranking identifies a predetermined number of related information items, the ranking, and the query, and the identified related information items, the ranking, and the query are input to a first model that has been trained to output a response to the query when the query is input. The first model then provides the response output by the first model, using the ranking and the predetermined number of related information items, to the user terminal device. program.

Images