Information processing device, information processing method, and program

Abstract

To improve AI-assisted functions in electronic payment services. [Solution] An information processing device comprising: an acquisition unit that acquires input information entered by a user of an electronic payment service; and a task execution unit that uses an AI model to decompose the processing corresponding to the input information into a plurality of tasks and executes the plurality of tasks sequentially.

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 technique for determining an AI (Artificial Intelligence) suitable for processing input information based on input information received from a user is known. For example, Patent Document 1 describes a technique for receiving a query including a prompt from a user and selecting an AI to be used for generating response information indicating a response to the prompt from among a plurality of AIs.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The technology described in Patent Document 1 selects the appropriate AI from multiple generative AIs (e.g., text generation AI, image generation AI, or multimodal generation AI). However, conventional technology does not select an appropriate AI agent to support users of electronic payment services in response to their questions and requests, and does not respond to user requests in an optimal way. Furthermore, even if each AI agent is to perform processing, developers need to design appropriate tasks and UI components for each AI agent, and there is room for improvement in the AI ​​support function of electronic payment services for both users and developers. Moreover, when a wide variety of functions (tools) such as money transfer, charging, and coupon search are contained within a single platform, as in electronic payment services, there is a challenge in how to link these to LLM. In particular, technologies such as MCP (Model Context Protocol) presuppose the existence of a general-purpose client centered on LLM, but such a client often does not exist in proprietary services.

[0005] This invention has been made in consideration of these circumstances, and one of its objectives is to provide an information processing device, an information processing method, and a program that can improve the AI ​​support function in electronic payment services. [Means for solving the problem]

[0006] One aspect of the present invention is an information processing device comprising: an acquisition unit that acquires input information entered by a user of an electronic payment service; and a task execution unit that uses an AI model to decompose processing corresponding to the input information into a plurality of tasks and sequentially executes the plurality of tasks. [Effects of the Invention]

[0007] According to one aspect of the present invention, AI-assisted functions in electronic payment services 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 simply by changing server-side settings, thereby increasing development efficiency and service scalability. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [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 configuration diagram of the payment server 100 according to the first embodiment. [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 the top screen of a payment app 20. [Figure 8] This figure shows a scene where a user launches the AI ​​assist app 20A and enters a request in natural language. [Figure 9] This figure shows an example of an orchestrator prompt 178 that the orchestrator unit 150A inputs to the LLM server 200. [Figure 10] This figure shows an example of an agent prompt 180 that agent unit 150B inputs to the LLM server 200. [Figure 11] This figure shows an example of a common UI component defined in UI component information 186. [Figure 12] This is a screen transition diagram showing the input task for the recipient during the money transfer process. [Figure 13]It is a screen transition diagram showing the input task of the transfer amount in the transfer process. [Figure 14] It is a screen transition diagram showing the additional task of the memo in the transfer process. [Figure 15] It is a screen transition diagram showing the final confirmation task before the execution of the transfer process. [Figure 16] It is a screen transition diagram for notifying the user that the transfer process has been completed. [Figure 17] It is a screen transition diagram showing the input task of the charge amount in the charge process. [Figure 18] It is a screen transition diagram showing the final confirmation task before the execution of the charge process. [Figure 19] It is a screen transition diagram for notifying the user that the charge process has been completed. [Figure 20] It is a diagram showing an example of the processing flow when an error occurs. [Figure 21] It is a sequence diagram showing an example of the processing flow of the AI assist function.

Mode for Carrying Out the Invention

[0009] Hereinafter, embodiments of an information processing apparatus, an information processing method, and a program according to the present invention will be described with reference to the drawings. 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 owner 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 application. The electronic payment service is a service that supports the settlement related to the purchase of goods and services in a store. The 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, the store is, for example, treated as belonging to a franchise (brand), and processing such as settlement when a purchase action is performed in the store is mainly carried out between the user and the franchise. Instead of this, processing such as settlement may be carried out between the user and the store.

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

[0011] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or 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] 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 perform 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 function as a web browser application that displays input / output information from the AI ​​assist function unit 150.

[0013] 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).

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

[0015] The payment server 100 implements 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, these will not be specifically distinguished, and it will be assumed that payment information is transmitted from the first store terminal device 50. The payment server 100 also communicates with the LLM server 200 via the network NW.

[0016] The LLM server 200 is a server device such as a web server. The LLM server 200 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 200 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 200 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 200 is installed outside the payment server 100, but the present invention is not limited to such a configuration, and the LLM server 200 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 200 is an example of "LLM". For the sake of brevity of explanation, even if a process is executed by the LLM server 200, 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.

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

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

[0019] 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).

[0020] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account 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.

[0021] [Payment Server] Figure 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 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.

[0022] 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, payment 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.

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

[0024] The payment 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 payment content provision unit 120 reads the necessary content from the payment content information 174 as appropriate and provides it to the user terminal device 10. 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 and other data to the payment server 100.

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

[0026] 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, telephone number, password, as well as information such 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. The user URL is used for money transfer processing between users. When registering for a new electronic payment service, registration of a telephone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can set at will (or does not have to set). Similarly, the email address and name, address, and date of birth are also information that the user can set at will (or does not have to set). 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 is 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, the store's location, and payment patterns.

[0029] The Information Management Unit 140 manages user information 172 and affiliated store / store information 176 based on information obtained from the user terminal device 10 and the second store terminal device 70. 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. For example, the value of the merchant's sales proceeds item is not used as electronic money itself, but rather the amount corresponding to the value of the sales proceeds item is transferred to the bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0031] The payment processing unit 130 performs electronic payment as follows for users whose "payment method setting" is set to "credit card payment". Credit card payment is a payment method that is carried out 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 and allows electronic payment that does not depend on the charge balance within the credit limit. In order to use the credit card payment service, it may be required to obtain a credit card provided by the operator of the electronic payment service. The amount used by credit card payment is settled in a lump sum for the month on the payment date of the following month, for example, by withdrawal from a bank account. In this case, the payment processing unit 130 performs a provisional settlement by adding the settlement amount to the amount used by credit card payment and subtracting the same amount from the available credit card balance. When the closing date arrives, it processes the payment for the current month to be withdrawn on the payment date of the following month as described above, or requests the credit card company operator to perform the said process. If the settlement amount exceeds the available credit card balance at the time of provisional settlement, an error notification is sent back to the payment app 20.

[0032] [Top screen] Figure 7 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 7, "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 (starting 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 displaying the code image used for electronic payment and the available balance. When the transition button TB2 is pressed, the user transitions to a screen displaying the available balance for either balance payment or credit payment. In Figure 7, since electronic payment using the charged balance is set, when the transition button TB2 is pressed, the available balance for balance payment is displayed.

[0033] 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 7, 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.

[0034] [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 200 and an MCP server.

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

[0036] Figure 8 shows a scene where a user launches the AI ​​Assist app 20A and enters a request in natural language. The screen shown in Figure 8 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 8, 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.

[0037] 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 200. The orchestrator unit 150A is also an example of an "acquisition unit," but the acquisition unit, which is a software function unit that receives input information IN, may be provided independently of the orchestrator unit 150A.

[0038] Figure 9 shows an example of an orchestrator prompt 178 that the orchestrator unit 150A inputs to the LLM server 200. 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 9, the available agents are defined as a help agent, a remittance agent, a charge agent, and a coupon agent. As shown in Figure 9, information A2 may include a description of the function of each agent in addition to the list of agents. Also, in Figure 9, for the sake of brevity, only the names of the available agents are listed, but in reality, the endpoint (URL) of each agent is also included.

[0039] A help agent is an agent that answers questions from users regarding electronic payment services. The help agent generates answers by referring to document information 182 and web information. A remittance agent is an agent that processes the transfer of electronic money balance from one user to another. A charge agent is an agent that processes the charging (depositing) of electronic money balance for users. A coupon agent is an agent that processes the search, acquisition, and use of coupons available for electronic payment services.

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

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

[0042] When user input information IN or an internal processing request occurs, the LLM server 200 first vectorizes the content of the request. Next, it uses this vector to search the vector database and retrieves one or more chunks that are semantically most similar (i.e., most relevant to the request) as search results. In other words, the LLM server 200 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 200 then understands processes such as money transfers and charges. With this configuration, the LLM server 200 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 200 by specifying it in the orchestrator prompt 178 or the agent prompt 180.

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

[0044] 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 9 corresponds to this. The Help Agent's primary purpose is to provide information, rather than executing APIs to change external states.

[0045] 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 9 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.

[0046] 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 200. The LLM server 200 infers the user's intent from the input information and determines the most appropriate agent unit 150B. In this embodiment, the LLM server 200 determines the "transfer agent" and returns the result to the orchestrator unit 150A.

[0047] When the orchestrator unit 150A receives a decision result of "remittance agent" from the LLM server 200, 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 200. In other words, the agent unit 150B, which uses the LLM server 200, is an example of a "task execution unit".

[0048] Figure 10 shows an example of an agent prompt 180 that the agent unit 150B inputs to the LLM server 200. The agent prompt 180 is, for example, a template format that includes 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.

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

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

[0051] 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).

[0052] The agent unit 150B sends an agent prompt 180 with "$agnt" set to "Transfer" combined with user input information IN to the LLM server 200. Based on this information, the LLM server 200 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.

[0053] 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 200. 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 200, 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.

[0054] [Using common UI components] Figure 11 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 role. 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".

[0055] 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 11, such as a task display box (TSK), a transition button (BT), or a numerical input box (NI).

[0056] 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".

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

[0058] The LLM server 200 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 200 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.

[0059] Furthermore, the large-scale language model installed in the LLM server 200 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 200, or it may be the document information 182 itself, or the document information 182 into 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.

[0060] 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 200 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 200 as prompt context information.

[0061] By referring to this contextual information, the LLM server 200 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 200 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.

[0062] [Specific examples of money transfer processing] The following describes a specific example of a money transfer process using the AI ​​assist function, with reference to Figures 12 to 16. Figure 12 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 12, 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.

[0063] Next, the agent unit 150B executes the "transfer amount input task". Figure 13 is a screen transition diagram showing the transfer amount input task in the transfer process. As shown in Figure 13, 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.

[0064] Next, the agent unit 150B executes the "add memo task." Figure 14 is a screen transition diagram showing the memo addition task in the remittance process. As shown in Figure 14, 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).

[0065] 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 10). Figure 15 is a screen transition diagram showing the final confirmation task before executing the remittance process. As shown in Figure 15, the agent unit 150B generates a UI screen in the task display box (TSK4) that specifies the recipient and amount, and places a "Yes" button (BT4) prompting final confirmation. When the user operates the "Yes" button (BT4), all tasks are considered complete.

[0066] 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 16 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 16, and terminates the series of processes.

[0067] Thus, the LLM server 200 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 for executing 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."

[0068] [Specific examples of charging processes] Next, with reference to Figures 17 to 19, a specific example of the charge process using the AI ​​assist function will be explained. Figure 17 is a screen transition diagram showing the input task for the charge amount in the charge process. As shown in Figure 17, 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 200 for interpretation, and as a result selects "Charge Agent".

[0069] 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 17, 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.

[0070] Next, the agent unit 150B performs a "final confirmation task" before executing the charge process. Figure 18 is a screen transition diagram showing the final confirmation task before the charge process is executed. As shown in Figure 18, 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.

[0071] 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 19 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 19, and terminates the series of processes.

[0072] [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."

[0073] Figure 20 shows an example of the processing flow when an error occurs. Figure 20 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.

[0074] 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 20, 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.

[0075] Figure 20 illustrates an example where the charge agent takes over processing in response to an error that occurs while the remittance agent is executing the process. However, the present invention is not limited to such a configuration. Depending on the user's input information IN and demands, the orchestrator unit 150A may coordinate multiple processes by multiple agent units to execute the processes of each agent unit in succession. 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 17 and 18, and then the remittance agent will execute the tasks shown in Figures 12 to 15. In this way, even if a user inputs complex input information IN that includes multiple intentions, the orchestrator unit 150A's coordination allows the user to achieve their objective by processing the tasks as instructed.

[0076] [Summary of processing flow] Figure 21 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 200 (S13) and requests the server to determine the agent unit 150B to which the request will be made. The LLM server 200 determines the agent unit 150B (S14) and notifies the orchestrator unit 150A (S15).

[0077] 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 200 (S17) and requests that the processing be broken down into tasks and the UI components for each task be determined. The LLM server 200 performs the task breakdown and UI component determination (S18) and notifies the agent unit 150B (S19).

[0078] 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 200, and the LLM server 200, 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.

[0079] Note that in the sequence diagram in Figure 21, 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.

[0080] According to the 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.

[0081] Furthermore, according to this embodiment, since task flows and UI screens to respond to user requests are dynamically generated on the LLM server 200 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.

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

[0083] 10. User terminal device 20 Payment Apps 20A AI Assist App 100 Payment Servers 150 AI Assist Function Unit 150A Orchestrator Section 150B Agent Department 200 LLM servers

Claims

1. An acquisition unit that acquires input information, including a request to execute a specific function of the electronic payment service, entered by a user of the electronic payment service, The system includes a task execution unit that, by inputting a prompt to an AI model containing API information defining the parameter specifications of an API (Application Programming Interface) for executing the aforementioned specific function, and the aforementioned input information, obtains a plurality of tasks that decompose the processing of the aforementioned specific function according to the parameters required in the specifications of the API information, and sequentially executes the plurality of tasks. Information processing device.

2. The task execution unit displays a UI screen for interacting with the user on the user terminal device, pre-setting the parameters included in the input information from the parameters, and by interacting with the user through the UI screen, it obtains the remaining parameters from the parameters and executes each of the multiple tasks. The information processing apparatus according to claim 1.

3. The task execution unit decomposes the process into multiple tasks equal to the number of parameters in the API. The information processing apparatus according to claim 2.

4. It further includes a storage unit that stores definition information for multiple predefined common UI components, The task execution unit selects one or more UI components from the multiple common UI components stored in the storage unit for each of the multiple tasks, and generates layout information for the UI screen that includes the selected one or more UI components. The information processing apparatus according to claim 2.

5. The common UI component includes a task display component for displaying the multiple tasks, a task processing component for processing the multiple tasks, and a task transition component for transitioning between the previous and next tasks among the multiple tasks. The information processing apparatus according to claim 4.

6. After completing all of the aforementioned tasks, the task execution unit further executes a task that requests final confirmation from the user before executing the aforementioned process. The information processing apparatus according to claim 1.

7. Computers The system acquires input information, including a request to execute a specific function of the electronic payment service, entered by a user of the electronic payment service. By inputting a prompt to the AI ​​model that includes API information defining the parameter specifications of an API (Application Programming Interface) for executing the aforementioned specific function, and the input information, the AI ​​model obtains multiple tasks that decompose the processing of the aforementioned specific function according to the parameters required in the API information specifications, and executes the multiple tasks sequentially. Information processing methods.

8. On the computer, The system obtains input information, including a request to execute a specific function of the electronic payment service, entered by a user of the electronic payment service. By inputting a prompt to the AI ​​model that includes API information defining the parameter specifications of an API (Application Programming Interface) for executing the aforementioned specific function, and the input information, the AI ​​model obtains multiple tasks that decompose the processing of the aforementioned specific function according to the parameters required in the API information specifications, and executes the multiple tasks sequentially. program.

Images