Information processing system, program, and data registration method

Abstract

To reduce a burden on a user when the user registers the same data in an external system.SOLUTION: The present invention is an information processing system that registers data in an external system in a chat service provided to a user, and includes a communication unit that receives the data transmitted from a user terminal, and a message creation unit that creates a communication message for registering the data in a plurality of external systems based on one piece of API setting information that is set in common for the plurality of external systems.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an information processing system, a program, and a data registration method. [Background technology]

[0002] There is known a chat system in which a chatbot, rather than an operator, replies to input statements made by a user and controls devices. The chat system replies to input statements according to a pre-prepared scenario, and registers data such as document files sent from a user terminal to an external system using an API (Application Programming Interface).

[0003] A chat system that calls an API provided by an external system is known (see, for example, Patent Document 1). Patent Document 1 discloses a technology that has a user input information to be registered, such as a name, and registers a request for information addressed to the user in the external system. Summary of the Invention [Problem to be solved by the invention]

[0004] However, the conventional technology has a problem in that even when a user wants to register the same data in multiple external systems, the user needs to register the data for each external system. In other words, the chat system has an API for registering data in each external system, so the user also needs to register the data for each external system. In addition, when an API is prepared for each external system, the administrator of the chat system needs to set up the system to call a different API for each external system, which is also a burden for the administrator.

[0005] In view of the above-mentioned problems, the present invention provides a technique for reducing the burden on a user when registering the same data in an external system. [Means for solving the problem]

[0006] In view of the above problems, the present invention is an information processing system that registers data in an external system in a chat service provided to a user, comprising a communication unit that receives the data transmitted from a user terminal, and a message creation unit that creates a communication message for registering the data in multiple external systems based on a single API setting information that is set in common for the multiple external systems. Effect of the Invention

[0007] The present invention can reduce the burden on users when they register the same data in an external system. [Brief description of the drawings]

[0008] [Figure 1] 11 is a diagram illustrating an outline of a process for registering a document in an external system using a different relay service. [Diagram 2] FIG. 1 illustrates an example of an overall configuration of a chat system. [Diagram 3] FIG. 2 is a diagram illustrating a hardware configuration of an example of a computer. [Figure 4] FIG. 2 is a diagram illustrating an example of a functional configuration of a user terminal. [Diagram 5] FIG. 2 illustrates an example of a functional configuration of an administrator terminal. [Figure 6] FIG. 2 is a diagram illustrating an example of a functional configuration of an information processing system. [Figure 7] FIG. 11 is a diagram showing an example of scenario information. [Figure 8] FIG. 11 is a diagram illustrating an example of category information. [Figure 9] FIG. 13 is a diagram showing an example of question-answer information. [Figure 10] FIG. 11 is a diagram showing an example of inquiry history information. [Figure 11] FIG. 11 is a diagram illustrating an example of dialogue history information. [Figure 12] FIG. 13 is a diagram illustrating an example of external system API setting information. [Figure 13] FIG. 2 is a diagram illustrating an example of a functional configuration of a relay service. [Figure 14] FIG. 13 is a diagram showing an example of a chat screen displayed on a user terminal. [Figure 15] 13 is a diagram illustrating an example of a custom scenario screen displayed on an administrator terminal. [Figure 16] FIG. 13 is a diagram showing an example of a scenario list screen. [Figure 17] 13A and 13B are diagrams illustrating an example of a common item setting screen and a dialog box. [Figure 18] FIG. 13 is a diagram showing an example of a custom scenario detail setting screen in the comparison technique. [Figure 19] 11A and 11B are diagrams illustrating an example of a document registration start screen and a form input screen displayed on an administrator terminal. [Figure 20] FIG. 13 illustrates an example of a form detail setting screen. [Figure 21] FIG. 13 illustrates an example of a file upload screen. [Figure 22] FIG. 13 is a diagram illustrating an example of an upload details setting screen. [Figure 23] FIG. 13 is a diagram illustrating an example of an API setting screen. [Figure 24] FIG. 13 is a diagram illustrating an example of an API detailed setting screen. [Diagram 25] FIG. 13 illustrates an example of a registration completion notification screen. [Figure 26] FIG. 13 is a diagram illustrating screen transitions when a user chats using a chat service. [Figure 27] FIG. 26 is a diagram showing an example of external system API setting information in JSON format that is set by an administrator and stored in an external system API setting DB for the screens of FIGS. 19 to 25. [Figure 28] 11 is an example of a sequence diagram illustrating a process in which a user registers a document file in an external system via a chat service. [Figure 29] 11 is a flowchart illustrating a process in which a relay service analyzes a request message; FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, as the optimal and minimal form for implementing the invention, a chat system and a data processing method performed by the chat system will be described with reference to the drawings.

[0010] <Outline of Document Saving via API> FIG. 1 is a diagram for explaining an outline of a process in which the relay service 8 of the present embodiment performs document registration in different external systems. (1) A relay service 8 is provided between the chat service 7 and a plurality of external systems 6. The administrator sets one API setting information 4 for creating an HTTP message for calling a plurality of external systems 6 in the chat service 7. Since this API setting information 4 is common to a plurality of external systems, the administrator can reduce the management effort such as adding another API setting information or scenario every time an external system is added. (2) The user selects an external system as the registration destination of the document file and gives an instruction to register the document file to the chat service 7. (3) The chat service 7 uses the API setting information 4 to create an HTTP message for calling the API of the relay service 8. A plurality of external systems specified by the user are set in the HTTP message. The chat service transmits the HTTP message to the relay service 8. (4) The relay service 8 analyzes the HTTP message, extracts external systems one by one, and registers the document file in each of the plurality of external systems 6.

[0011] As described above, in the present embodiment, since the API setting information 4 common to the plurality of external systems 6 is set in the chat service 7, the user can register the document file in the plurality of external systems 6 with a single registration operation. Also, since the API setting information 4 is common to the plurality of external systems 6, the administrator can reduce the management effort such as adding an API or a scenario every time an external system is added.

[0012] <Regarding Terms> The data registered in the external system may be any data that the user wishes to register. This data may be in a file format, for example.

[0013] An API (Application Programming Interface) is an interface that a service provider provides in order to use that service. An API that mainly uses HTTP(S) for communication is called a Web API.

[0014] A communication message is data written in a certain format that is transmitted and received using a communication protocol for data exchange between a server side and a client side. The client side is not limited to a terminal device. One communication message may be divided into multiple messages or may be used multiple times. In this embodiment, HTTP is used as the communication protocol, but the communication protocol may be selected as appropriate.

[0015] The administrator is, for example, a tenant administrator when the chat service 7 is used on a tenant-by-tenant basis. A tenant is, for example, a company, a department within a company, or other organization that has made a contract to use the chat service 7. In this embodiment, the relay service 8 absorbs the differences between multiple external systems 6, so that the burden on the administrator to manage the API in the chat service 7 can be reduced.

[0016] A user is an end user who uses the chat service. A user may belong to a tenant or may be an individual. A user can register a document file in an external system by using the chat service.

[0017] <Overall configuration example> Fig. 2 is a diagram showing an example of the overall configuration of chat system 100. Chat system 100 has an information processing system 1, a user terminal 2, an administrator terminal 3, and an operator terminal 5, which are capable of communicating with each other via a network. Of these, user terminal 2, administrator terminal 3, and operator terminal 5 do not need to be connected to the network at all times, and do not need to be included in chat system 100. Also, in Fig. 2, a plurality of external systems 6 are connected to the network so as to be capable of communicating with each other. The plurality of external systems 6 are external systems in which chat system 100 can register document files and the like.

[0018] The network N may include, for example, a LAN in a facility where the user terminal 2, the administrator terminal 3, and the operator terminal 5 are present, and may further include the Internet constructed by a provider network, etc. The network N may also include a telephone line network such as 4G, 5G, or 6G.

[0019] The information processing system 1 is one or more information processing devices that provide a chat service 7 and a relay service 8. The chat service 7 displays a chat screen 200 (described later) on a web page accessed by a user terminal, or on a transition destination of this web page. In response to an input sentence such as a question input by a user on the chat screen 200, an answer is sent to the user terminal by using various databases or AI. In addition, in response to a request from a user, or when an answer cannot be found, the chat service 7 calls an operator and shifts to manned response.

[0020] The relay service 8 relays communication between the chat service 7 and an external system. An API is set in advance in the relay service 8. In this embodiment, an administrator sets API setting information that matches this API. The chat service 7 registers a document file in the external system by calling the API of the relay service 8 using an HTTP message created based on the API details. The relay service 8 absorbs differences between the multiple external systems 6, and from the perspective of the chat service 7, even if there are changes to the multiple external systems 6, the impact on the chat service 7 can be suppressed.

[0021] In FIG. 2, the chat service 7 and the relay service 8 are arranged in the information processing system 1, but the chat service 7 and the relay service 8 may be arranged in separate server devices.

[0022] The external system 6 is a system that accepts registration of document files. The external system may be a commercial system that manages corporate file management or creates files by performing processing according to the services provided by the external system. The external system may simply be a storage service. The relay service 8 calls the APIs (not the APIs set in this embodiment) of these multiple external systems 6 to send and receive data.

[0023] The user terminal 2 is a terminal device through which a user inputs input text such as a question in the chat service 7. The user connects the user terminal 2 to a website that handles products and services, and inputs a question or the like from a chat screen 200 as necessary.

[0024] The administrator terminal 3 is a terminal device where an administrator or the like performs operations such as input to manage the chat service 7. The administrator connects the administrator terminal 3 to the information processing system 1 and performs various settings from a website for the administrator. The administrator creates API setting information for calling the API of the relay service 8 as described above.

[0025] The operator terminal 5 is a terminal device in which an operator who engages in manned chat with a user in the chat service 7 inputs answers to questions and instructs the user on how to operate the chat service. It is preferable that the operator has the operator terminal 5 connected to the information processing system 1. The operator grasps the assignment of questions sent by the information processing system 1 to the operator terminal 5, and inputs answers to questions from users to the operator terminal 5. The operator terminal 5 transmits the answers to the user terminal 2 via the information processing system 1.

[0026] The user terminal 2, the administrator terminal 3, and the operator terminal 5 are, for example, PCs (Personal Computers) or smart devices. There is no clear definition of a smart device, but it refers to a smartphone or tablet terminal that does not include an existing computer such as a PC or a server. Both the PC and the smart device can connect to the information processing system 1 using either a web browser or a native app dedicated to the information processing system 1. When a web browser is executed on the user terminal 2, the administrator terminal 3, and the operator terminal 5, the user terminal 2, the administrator terminal 3, and the operator terminal 5 execute a web app provided by the information processing system 1. A web app refers to software or a mechanism thereof that operates by cooperation between a program written in a programming language (e.g., JavaScript (registered trademark)) that runs on a web browser and a program on the web server side. The user terminal, the administrator terminal, and the operator terminal can dynamically change web pages using the web app. However, the user terminal 2, the administrator terminal 3, and the operator terminal 5 may execute a native app.

[0027] <Hardware configuration example> The information processing system 1, the user terminal 2, the administrator terminal 3, and the operator terminal 5 in Fig. 2 are realized by, for example, a computer having a hardware configuration shown in Fig. 3. Fig. 3 is a hardware configuration diagram of an example of a computer. As shown in Fig. 3, the computer 500 includes a CPU 501, a ROM 502, a RAM 503, an HD 504, an HDD controller 505 (Hard Disk Drive), a display 506, an external device connection I / F 508 (Interface), a network I / F 509, a bus line 510, a keyboard 511, a pointing device 512, an optical drive 514, and a media I / F 516.

[0028] Among these, the CPU 501 controls the operation of the entire computer. The ROM 502 stores programs such as IPL used to drive the CPU 501. The RAM 503 is used as a work area for the CPU 501. The HD 504 stores various data such as programs. The HDD controller 505 controls reading and writing of various data from and to the HD 504 under the control of the CPU 501. The display 506 displays various information such as a cursor, a menu, a window, a character, or an image. The external device connection I / F 508 is an interface for connecting various external devices. In this case, the external device is, for example, a USB (Universal Serial Bus) memory or a printer. The network I / F 509 is an interface for data communication using a communication network. The bus line 510 is an address bus, a data bus, or the like for electrically connecting each component such as the CPU 501 shown in FIG. 3.

[0029] Moreover, the keyboard 511 is a type of input means having a plurality of keys for inputting characters, numbers, various instructions, etc. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The optical drive 514 controls reading and writing of various data from an optical storage medium 513, which is an example of a removable storage medium. The optical drive 514 is a CD, DVD, Blu-Ray (registered trademark), etc. The media I / F 516 controls reading and writing (storing) of data from a storage medium 515, such as a flash memory.

[0030] <About the function> Next, functions of the chat system 100 will be described with reference to FIGS.

[0031] <<User device functions>> Fig. 4 is a diagram showing an example of the functional configuration of the user terminal 2. The user terminal 2 has a functional configuration including a communication unit 2a, a device control unit 2b, an input unit 2c, and a display unit 2d. Each functional unit of the user terminal is a function or means realized by the CPU 501 shown in Fig. 4 executing instructions included in one or more programs installed in the user terminal. This program may be a web browser or a dedicated native application.

[0032] The communication unit 2a communicates with the information processing system 1 and the like via a network. In this embodiment, the communication unit 2a receives various types of screen information displayed by Web applications and native applications from the information processing system 1. The communication unit 2a also transmits input statements such as questions entered by a user and document files to the information processing system 1.

[0033] The device control unit 2b controls the overall operation of the user terminal 2. For example, the device control unit 2b transmits and receives information, commands, and the like via the communication unit 2a. In addition, for example, the device control unit 2b controls an interactive application, which is an example of a web browser or native application for receiving a chat service 7 from the information processing system 1, according to a program.

[0034] The input unit 2c receives input of information and operations from a user and outputs them to the device control unit 2b, etc. The display unit 2d displays various screens. For example, the display unit 2d displays a screen for an interactive application, etc. The display unit 2d and the input unit 2c may be integrated.

[0035] <<Administrator terminal functions>> FIG. 5 is a diagram showing an example of a functional configuration of the administrator terminal 3. For example, the administrator terminal 3 has a communication unit 3a, a device control unit 3b, an input unit 3c, and a display unit 3d. Each functional unit of the administrator terminal 3 is a function or means realized by the CPU 501 shown in FIG. 4 executing an instruction included in one or more programs installed in the administrator terminal 3. This program may be a web browser or a dedicated native application. The device control unit 3b controls a management application, which is an example of a web browser or native application for the administrator to set in the information processing system 1, according to the program. Other than this, the functions of the administrator terminal 3 may be the same as those of the user terminal 2, so duplicated explanations will be omitted. However, the administrator terminal 3 may have a different functional configuration from that of the user terminal 2.

[0036] <<Functions of the information processing system>> FIG. 6 is a diagram showing an example of a functional configuration of the information processing system 1. The information processing system 1 has the chat service 7 and the relay service 8 as described above. The chat service 7 has a communication unit 31, an input information monitoring unit 32, a response status management unit 33, an operator status management unit 34, a user side control unit 10, a message creation unit 14, and a management side control unit 20. Each of these functional units of the chat service 7 is a function or means realized by the CPU 501 shown in FIG. 3 executing an instruction included in one or more programs installed in a computer. The chat service 7 also has various databases (hereinafter referred to as "DB"). The chat service 7 has a keyword DB 41, a synonym DB 42, a dialogue scenario DB 43, a category DB 44, a question-answer DB 45, an inquiry history DB 46, a dialogue history DB 47, and an external system API setting DB 48, etc.

[0037] The DB may exist on a network and may be configured to be referenced by the chat service 7. The DB may not be configured as shown in the figure. In other words, the DB may not have the names and numbers as shown in the figure, and it is sufficient if there is a DB showing similar contents.

[0038] The communication unit 31 (an example of a first communication unit) communicates with the user terminal 2, the administrator terminal 3, the operator terminal, and multiple external systems 6, etc., via the network N. The communication unit 31 provides the user terminal 2 and the administrator terminal 3 with a Web application for displaying screens on the user terminal 2 and the administrator terminal 3. In other words, the communication unit 31 may have a Web server function. In this embodiment, the communication unit 31 provides the administrator terminal 3 with a screen for the administrator to set external system API setting information. In addition, the communication unit 31 provides the user terminal 2 with a screen for registering a document file that uses the external system API setting information stored in the external system API setting DB 48.

[0039] The input information monitoring unit 32 acquires various information from the user terminal 2, the administrator terminal 3, etc., via the communication unit 31. For example, the input information monitoring unit 32 selects the acquired information and outputs it to the user-side control unit 10 or the management-side control unit 20, etc. Specifically, the input information monitoring unit 32 outputs information acquired via a dialogue application to the user-side control unit 10. On the other hand, the input information monitoring unit 32 outputs information acquired via a management application to the management-side control unit 20.

[0040] As functions common to the user side and the administrator side, the information processing system 1 has a response status management unit 33 and an operator status management unit 34. The response status management unit 33 stores and updates the response status. The operator status management unit 34 stores and updates the response status of each operator.

[0041] The user-side control unit 10 controls the responses of the information processing system 1 to the user, etc. For example, the user-side control unit 10 outputs to the user terminal 2 information (hereinafter referred to as "response information") that responds to information (hereinafter referred to as "input information") such as a question input by the user via the user terminal 2.

[0042] The management side control unit 20 controls input and output of the information processing system 1 for the administrator. For example, the management side control unit 20 accepts operations such as input to each DB performed by the administrator from the administrator terminal 3. Furthermore, the management side control unit 20 outputs information indicated by each DB to the administrator terminal 3 in response to a request from the administrator terminal 3.

[0043] The input information analysis unit 11 first analyzes the character string input by the user. For example, the input information analysis unit 11 performs morphological analysis to break down the character string of the question and extract words. Furthermore, the input information analysis unit 11 refers to the synonym DB 42 to extract synonyms of the extracted words. Next, the input information analysis unit 11 compares the extracted words and synonyms with the keyword DB 41 to estimate keywords.

[0044] The response processing unit 12 generates response information to the input information. For example, the response processing unit 12 generates response information to information selected on a display screen shown by the display unit 2d of the user terminal 2 and to a character string input to the user terminal 2. For example, when an option included in the scenario information is selected, the response processing unit 12 refers to the dialogue scenario DB 43 and outputs a message corresponding to the option to the user terminal 2. When a character string of a question is input, the response processing unit 12 searches for question-answer information to the question by checking the keyword estimated by the input information analysis unit 11 against the question-answer DB 45. Then, the response processing unit 12 outputs the searched question-answer information to the user terminal 2. For example, when an option included in the category information is selected, the response processing unit 12 may narrow down the search for question-answer information in the question-answer DB 45 to the selected category.

[0045] The response processing unit 12 detects that the user has requested registration of a document file, and in that case, requests the message creation unit 14 to create an HTTP message that calls the API of the relay service 8. The message creation unit 14 creates one HTTP message using the external system API setting information stored in the external system API setting DB 48. The message creation unit 14 requests registration of the document file by sending the HTTP message to the relay service 8 via the communication unit 31.

[0046] The processing content acquisition unit 13 acquires and stores the processing result by the response processing unit 12. For example, the processing content acquisition unit 13 stores the answer to the question as inquiry history information in the inquiry history DB 46. The processing content acquisition unit 13 also stores the content of the utterance input / output between the information processing system 1 and the user terminal 2, which is the process of answering the question, in the dialogue history DB 47 as dialogue history information.

[0047] The input information analysis unit 21 analyzes information such as that input to the administrator terminal 3 and outputs the analyzed information to the response processing unit 22. Specifically, the input information analysis unit 21 analyzes a character string or the like input by an administrator or the like. For example, similar to the user-side control unit 10, the input information analysis unit 21 extracts words and estimates keywords corresponding to the words and synonyms.

[0048] The response processing unit 22 changes, adds, and deletes information for each DB in response to a command input from an administrator or the like. Specifically, the response processing unit 22 changes keywords, deletes keywords, or adds new keywords, etc. to the keywords stored in the keyword DB 41 or the like. Similarly, the response processing unit 22 changes synonyms, deletes synonyms, or adds new synonyms, etc. to the synonyms stored in the synonym DB 42 or the like. Further, the response processing unit 22 edits scenarios, deletes scenarios, or adds new scenarios, etc. to the scenario information stored in the dialogue scenario DB 43. Furthermore, the response processing unit 22 changes categories, deletes categories, or adds new categories, etc. to the category information stored in the category DB 44. Also, the response processing unit 22 edits question-answer information, deletes question-answer information, or adds new question-answer information, etc. to the question-answer information stored in the question-answer DB 45. Hereinafter, "changing, adding, and deleting information" may be referred to as "editing" of information. Also, the response processing unit 22 receives external system API setting information transmitted from the administrator terminal 3.

[0049] The processing content acquisition unit 23 acquires and saves the processing result by the response processing unit 22. For example, the processing content acquisition unit 23 adds, changes, deletes (these are referred to as editing) the information set by the administrator to the keyword DB 41 or the like. Also, the processing content acquisition unit 23 saves the external system API setting information set by the administrator to the external system API setting DB 48.

[0050] <<Contents of the DB>> The keyword DB 41 stores so-called keywords, which are example characters that indicate the characteristics of the questions and answers contained in the character strings of the questions and answers in the question-answer information. Note that the keywords may be words, phrases, or sentences. The keyword DB 41 may also store keywords related to things other than the question-answer information.

[0051] For example, the user-side control unit 10 first breaks down the character string of the question input by the user into words. Next, the user-side control unit 10 detects the keyword of the question by comparing the broken down words with the character strings stored in the keyword DB 41. Furthermore, the user-side control unit 10 searches for question-answer information corresponding to the question indicated by the input information by, for example, matching the detected keyword with the character string of "question" in the question-answer DB 45.

[0052] The synonym DB 42 stores synonym information of keywords and the like indicated by the keyword DB 41. For example, the synonym information is information that associates character strings that are similar in meaning to each other. The character strings may be words, phrases, and sentences. Furthermore, character strings that are similar in meaning to each other are not limited to character strings that are similar in meaning themselves. For example, character strings that are similar in meaning to each other may be character strings in which one can be inferred from the other, may be character strings in which one is a part of the other, may be character strings in which the situations in which they are used are similar, and may be arbitrarily defined according to the usage environment.

[0053] The user-side control unit 10 first breaks down the character string of the question entered by the user into words. Next, the user-side control unit 10 checks the broken down words against the synonym DB 42 to extract character strings that are synonyms. In this way, the user-side control unit 10 estimates keywords by checking the words and synonyms of the words included in the question against the keyword DB 41, etc.

[0054] 7 shows an example of scenario information. The dialogue scenario DB 43 stores dialogue-format scenario information corresponding to input information. The user-side control unit 10 is assumed to dialogue with the user according to a scenario previously input to the dialogue scenario DB 43. For example, after receiving input information in which the user asks a question, the flow of outputting response information that answers the received question is processed according to the scenario shown in the figure.

[0055] 8 is a diagram showing an example of category information. The category DB 44 stores category information for classifying questions. For example, as shown in the figure, the category information is information that associates a character string of the name of the category that includes the question, the ID of the category information, and the update date and time of the category information.

[0056] 9 is a diagram showing an example of the question-and-answer information. The question-and-answer DB 45 stores the question-and-answer information, which is information including a question and an answer to the question. That is, the question-and-answer information is created in advance and stored in the question-and-answer DB 45.

[0057] For example, as shown in the figure, the question-answer information is information that associates a question string, an ID of the question-answer information, a string of a question similar to the question, a string of an answer to the question, an ID of a category that includes the question, and an update date and time of the question-answer information.

[0058] 10 is a diagram showing an example of inquiry history information. The inquiry history DB 46 stores inquiry history information, which is information on the history of questions input by the user. For example, as shown in the figure, the inquiry history information is information that associates an inquiry history information ID, a character string of a question input by the user, an ID of an interaction session including the question, an ID of question-answer information corresponding to the question, an ID of category information corresponding to the question-answer information, information on the user's feedback on the answer to the question, and the date and time when the question was input.

[0059] An interaction session is a set of interactions between a user and the information processing system 1. For example, interactions included in the same interaction session are interactions that take place between the time when a screen used for interaction such as chat is launched and closed on the user terminal 2, or interactions that take place between the time when the screen is launched and the time when the screen is forcibly closed due to a session timeout. A session timeout occurs when no action is taken on the user terminal 2 within a predetermined time period that is set in advance. A session timeout is a process of terminating a screen used for interaction.

[0060] Note that the interactive session is not limited to the above. For example, the interactive session may indicate an interaction between the user and the information processing system 1, ranging from input of a question by the user, to presentation of an answer to the question, and input of feedback from the user on the answer. In this case, the interactive session is completed each time feedback is obtained from the user.

[0061] 11 is a diagram showing an example of dialogue history information. The dialogue history DB 47 stores dialogue history information which is information on the history of utterance contents input to the user terminal 2 and utterance contents output from the information processing system 1 in a dialogue between a user and the information processing system 1.

[0062] For example, as shown in the figure, the dialogue history information is information that associates an ID of the dialogue history information, a string of the comment content, an ID of the dialogue session in which the comment content was sent, a sender of the comment content, a comment type of the comment content, a content ID of the comment content, and a date and time when the comment content was sent.

[0063] The statement type ID indicates the type of statement. Specifically, the statement type IDs "5-0", "5-1", and "5-2" indicate whether the statement content corresponds to a "category", "question-answer information", or "scenario", respectively. The content ID indicates the content linked to the statement type ID. For example, if the statement type is a scenario, the content ID indicates the statement set in the scenario. If the statement type is question-answer information, the content ID indicates the ID of the question-answer information. If the statement type is a category, the content ID indicates the statement for selecting a category.

[0064] 12 is a diagram showing an example of external system API setting information. The external system API setting DB 48 stores external system API setting information for the chat service 7 to call the relay service 8 when a user registers a document file in an external system. Even if there are multiple external systems, only one external system API setting information is required. The external system API setting information is registered in association with a custom scenario ID. The series of processes for registering document files in an external system is also defined in a scenario, but a scenario created by an administrator is called a custom scenario in contrast to a pre-prepared general-purpose scenario.

[0065] The link destination URL is a URL for the chat service 7 to call the relay service 8. The link destination URL is set by the administrator.

[0066] The registration destination variable name corresponds to a variable (e.g., reg_target) that receives the identification information of the external system selected by the user from the user terminal 2, and a variable (e.g., target) that the API of the relay service 8 uses to obtain the identification information of the external system 6. The registration destination variable name is set by the administrator.

[0067] The registration list is a list of external systems that users can specify. The registration list is set by the administrator.

[0068] The return value is a setting related to the return value that the chat service 7 receives from the relay service 8 when the chat service 7 requests the relay service 8 to register a document file and the relay service 8 registers the document file in an external system. date is a variable on the chat service 7 side (variable 1, an example of the third variable), and delivery_date is a variable on the relay service 8 side (variable 2, an example of the fourth variable). When registration is completed successfully, the registration date is stored in this variable 1 and returned to the chat service 7. If an abnormality occurs, the details of the abnormality may be stored in the variable.

[0069] The attachment file name is a variable that receives the file name of the document file selected by the user by the chat service 7. The chat service 7 also stores the file name of the document file in this variable and calls the relay service 8.

[0070] The file type is the type (extension) of the document file that the user can register in the external system.

[0071] The request body is the request body in the HTTP request message sent from the chat service 7 to the relay service 8. The registration destination variable name is set in the request body in JSON format.

[0072] The external system API setting information is specifically stored in JSON, XML, etc., and details are explained in Figure 27.

[0073] <<Relay service functions>> Fig. 13 is a diagram showing an example of a functional configuration of the relay service 8. The relay service 8 has a communication unit 51, a message analysis unit 52, and a registration unit 53. Each of these functional units of the relay service 8 is a function or means realized by the CPU 501 shown in Fig. 3 executing instructions included in one or more programs installed in a computer.

[0074] The communication unit (an example of a second communication unit) 51 communicates with the chat service 7 via HTTP or the like, receives HTTP messages (request messages) created based on external system API setting information from the chat service 7, and sends response messages to the chat service 7.

[0075] The message analysis unit 52 analyzes the request message sent from the chat service 7. Since reg_target (an example of a first variable) has been replaced with the identification information of the external system, the message creation unit 14 extracts the identification information of the external system from, for example, the request body.

[0076] The registration unit 53 registers the document file in the external system specified by the identification information of the external system extracted by the message analysis unit 52. The registration unit 53 creates an HTTP message in a predetermined format that calls the API of each external system. Therefore, the function of the registration unit 53 may need to be updated every time an external system is added, but this work is performed by the company that operates the information processing system 1. Therefore, the administrator of each tenant is relieved from the work of dealing with an increase in the number of types of external systems or changes to the API.

[0077] <How to set up the scenario> Next, with reference to Figs. 14 to 18, a description will be given of screens displayed by the administrator terminal 3 in a comparative technique to be compared with this embodiment.

[0078] First, Fig. 14 is an example of a chat screen 200 displayed by the user terminal 2. Several scenarios are displayed on the chat screen 200. A scenario defines the type of dialogue that will lead a user to what they want to know or do. In Fig. 14, four scenarios 201 to 204 are displayed: "Search using categories," "View frequently asked questions," "Test scenario," and "I want to register a document." The administrator can create new scenarios or edit them.

[0079] Scenarios 201 to 204 in Fig. 14 are general-purpose scenarios that are commonly used for general chats. In addition to these general-purpose scenarios, an administrator can create custom scenarios for specific purposes. A scenario for registering a document file in an external system is a custom scenario.

[0080] FIG. 15 shows a custom scenario screen 210 displayed by the administrator terminal 3. The administrator can set how the chatbot will converse with the above-mentioned "test scenario." The custom scenario screen 210 has several screen transitions. These screens are shown as screens A to I. One screen corresponds to one user operation (this is called an action. One operation roughly corresponds to one screen). In addition, when referring to individual external systems among the multiple external systems 6, they are referred to as "external systems A to C."

[0081] Screen A is a screen that allows the user to select the action "register document." The administrator can also add actions. When the "register document" button 211 is pressed, screen A transitions to screen B.

[0082] Screen B is a screen where the administrator sets how the user should select the destination for registering the document file when registering the document. For example, "Hearing" means that the user will input. When the "Hearing" button 212 is pressed, screen B transitions to screen C.

[0083] Screen C is a screen where the administrator selects a registration destination from a list of registration destinations for the document file. Three external systems A to C are displayed on screen C. The external systems in which the user can register document files are preset in the information processing system 1. The administrator inputs a display name of the external system. When buttons 213 to 215 for each external system are pressed, screen C transitions to screens D to F depending on the selected external system.

[0084] Screen D shows the API integration screen when external system A is selected. Screen E shows the API integration screen when external system B is selected. Screen F shows the API integration screen when external system C is selected. Pressing button 216 transitions screen D to screen G, pressing button 217 transitions screen E to screen H, and pressing button 218 transitions screen F to screen I.

[0085] Screens G to I are screens that indicate the completion of API integration with each of external systems A to C. An example of API integration settings will be described later (see FIG. 18), but in the comparative technology, the administrator had to configure API settings for each external system.

[0086] Figure 16 shows a scenario list screen 230 that displays a list of custom scenarios set as described above. Set scenario names 231, 232 are displayed on the scenario list screen 230. The administrator can set additional custom scenarios from this screen. When the administrator presses the common item settings tab 233, the scenario list screen 230 in Figure 16 transitions to a common item settings screen 240.

[0087] Fig. 17(a) shows a setting screen 240 for common items common to multiple custom scenarios. The common item setting screen 240 is a screen where an administrator can collectively set the contents common to multiple scenarios. Fig. 17(a) shows, as a part of the screen, a screen where settings can be made at the start of a chat. On the common item setting screen 240, the administrator can edit or select a greeting 241 at the start and options 242 presented to the user at the start.

[0088] When the administrator presses, for example, edit button 243 for "test scenario," the administrator can make settings related to the "test scenario."

[0089] 17(b) shows a dialog box 250 that is displayed on the common item setting screen 240 when the edit button 243 for "Test Scenario" is pressed. The dialog box 250 has a title field 251 and a custom scenario field 252. For example, the administrator can set (change) the title of "Test Scenario" in the title field 251. The custom scenario field 252 displays a list of custom scenarios in a pull-down menu, so the administrator can set whether or not the chatbot will display them.

[0090] FIG. 18 is a diagram illustrating a custom scenario detailed setting screen 260 in the compared technology. FIG. 18 mainly explains the differences from FIG. 15. The custom scenario detailed setting screen 260 in FIG. 18 is a screen on which API settings are made for each external system. As such, in the compared technology, API settings are required for each external system. The custom scenario detailed setting screen 260 has a linkage destination URL field 261, a method type selection field 262, a request header field 263, a request body field 264, and a response body field 265.

[0091] The URL of an external system in which a document file is registered is set in the link destination URL field 261. This is because the relay service 8 is not used in the comparison technology.

[0092] The GET method or the POST method is used in the method type selection field 262. The GET method is mainly used when the chat service 7 obtains information from an external system, and the POST method is mainly used when the chat service 7 registers information in the external system.

[0093] A request header for HTTP communication is set in the request header field 263. For example, the administrator can set variables and their values, but even if no settings are made, default values ​​normally used in request headers are automatically set.

[0094] The registration destination of the document file, etc. is set in the request body field 264. That is, the administrator needs to set information for specifying the external system individually.

[0095] In the response body column 265, the variable 2 managed by the relay service 8 and the variable 1 managed by the chat service 7 are associated with each other. In Fig. 18, the variable 1 is delivery_date and the variable 2 is date, which is an example.

[0096] <Method of setting up API integration according to this embodiment> 19 to 25, the API settings in which the administrator registers external system API setting information in the chat service 7 will be described below. A custom scenario is also created by creating external system API setting information. In the API integration settings of this embodiment, a user can register document files in multiple external systems 6 using one external system API setting information for multiple external systems.

[0097] Fig. 19 shows a document registration start screen 270 and a form input screen 280 displayed by the administrator terminal 3. When the administrator selects the "Register document" button 271 on the document registration start screen 270, the form input screen 280 is displayed. The form input screen 280 is a screen set by the administrator so that the user can select, in form format, to which external system the document file is to be registered. When the administrator presses the form input button 281, a form detail setting screen 290 shown in Fig. 20 is displayed.

[0098] 20 shows a form detail setting screen 290. The form detail setting screen 290 has a field name column 291, a form type column 292, and an option input column 293.

[0099] · In the field name column 291, the administrator sets a variable (which receives the identification information of the external system) to be set in the request body. When a user chats and registers a document file in an external system, the variable set in the field name column 291 is replaced with the identification information of the external system specified by the user (or the identification information of the external system specified by the user may be stored in the variable 9). This variable is used by the relay service 8 to determine the external system to which the document file is to be registered.

[0100] The form type field 292 is a field in which the administrator sets whether the chat service 7 is to present to the user terminal 2 a text box, a pull-down list, or a check box when the user selects an external system.

[0101] The option input field 293 is a list of external systems that the user can select as a registration destination, and the administrator sets a list of known external systems as external systems that can be specified by the chat service 7. The display name 293a may be any name, and the value 293b is the name of the external system registered with the chat service 7.

[0102] The values ​​set by the administrator on the form detail setting screen 290 are stored in the external system API setting DB 48 and are used when the chat service 7 requests the relay service 8 to register a document file.

[0103] When the input on the form details setting screen 290 is completed, a file upload screen 300 is displayed. Fig. 21 shows the file upload screen 300. The file upload screen 300 is a screen on which the administrator makes settings related to the registration of document files. When the administrator presses the file upload button 301, an upload details setting screen 310 is displayed.

[0104] 22 shows an upload detailed setting screen 310. The upload detailed setting screen 310 has a field name column 311 and a document type column 312.

[0105] The field name column 311 is a column where the administrator sets a variable that stores the file name of the document file selected by the user for upload. The chat service 7 transmits the file name of the document file stored in the variable to the relay service 8.

[0106] The document type field 312 is a field where the administrator sets the extensions of document files that users can upload. If a user selects a document file on the user terminal 2 to upload, and the selected document file has an extension that is not selected in the document type field 312, the user terminal 2 restricts the upload.

[0107] The values ​​set by the administrator on the upload detailed setting screen 310 are stored in the external system API setting DB 48 and are used when the chat service 7 requests the relay service 8 to register a document file.

[0108] When input on the upload details setting screen 310 is completed, the API settings screen 320 is displayed. Fig. 23 shows the API settings screen 320. The API settings screen 320 is a screen where the administrator sets API settings such as the request body. When a predetermined button 321 is pressed, the API details setting screen 330 is displayed.

[0109] 24 shows an API detailed setting screen 330. The API detailed setting screen 330 has a linkage destination URL field 331, a method type selection field 332, a request header field 333, a request body field 334, a response body field 335, and an attachment field 336.

[0110] In the link destination URL field 331, the administrator sets a URL for calling the relay service 8.

[0111] Either the GET command or the POST command is selected in the method type selection field 332. In the case of registering a document file, the POST command is sufficient.

[0112] A request header for HTTP communication is set in the request header field 333. For example, the administrator can set variables and their values, but even if no settings are made, default values ​​normally used in request headers are automatically set.

[0113] In the request body field 334, the administrator inputs reg_target, which the administrator specified earlier on the form detail setting screen 290, in association with a variable called "target". reg_target is a variable, and in the request message, identification information of one or more external systems selected by the user during chat is set in place of reg_target. In the request body field 334, reg_target, which the administrator specified on the form detail setting screen 290, may be transmitted to the administrator terminal 3 in association with a variable called "target". This reduces the administrator's effort in associating reg_target with "target" and manually inputting it. Note that the variable names reg_target and target are merely examples.

[0114] In the response body field 335, a variable 2 managed by the relay service 8 and a variable 1 managed by the chat service 7 are associated with each other. In the example shown in FIG. 24, variable 1 is "delivery_date" and variable 2 is "date." In other words, the relay service 8 sets the value of "delivery_date" to the variable "date" and transmits it to the chat service 7.

[0115] In the attachment file field 336, the administrator sets the document_file (an example of a second variable) that the administrator set on the upload detailed settings screen 310. In the attachment file field, the document_file set on the upload detailed settings screen 310 is displayed in a pull-down menu, so the administrator can select one.

[0116] The values ​​set by the administrator on the API detailed setting screen 330 are stored in the external system API setting DB 48 and are used when the chat service 7 requests the relay service 8 to register a document file.

[0117] By setting the external system API setting information in this way, if there are multiple document registration destinations (external systems), the administrator does not need to create APIs or scenarios to link with each external system. Users can also automatically register document files to multiple external systems6 with a single registration operation.

[0118] When input on the API detailed setting screen 330 is completed, a registration completion notification screen 340 is displayed. Fig. 25 shows the registration completion notification screen 340. The registration completion notification screen 340 is a screen where the administrator makes settings to notify the user that a document file has been registered in multiple external systems 6. The administrator can enter a message 341 such as "Registration is complete."

[0119] <User action> Next, Fig. 26 explains the screen transitions when a user chats using the chat service 7. Fig. 26(a) shows a registration destination selection screen 350. The registration destination selection screen 350 displays display names 351 of multiple external systems 6 set by the administrator on the form detail setting screen 290. The user selects one or more external systems to which he or she wishes to register a document file, checks the check boxes associated with these external systems, and presses a done button 352.

[0120] 26(b) shows a file attachment screen 360. The file attachment screen 360 has a file name field 361, a browse button 362, and a done button 363. The user presses the browse button 362 to select the document file to be registered. The files that the user can select are limited to the file format set in the document format field 312 of the API detailed setting screen 330. When the user has displayed the file name of the selected document file in the file name field 361, he or she presses the done button 363. By pressing the done button 363, the document files are registered in multiple external systems 6 at once.

[0121] When the registration is complete, a completion screen 370 in FIG. 26(c) is displayed. The completion screen 370 has a message 371 saying "Registration is complete" and a completion button 372. The user confirms the message 371 and presses the completion button 372. The message 371 is the same as the message 341 set by the administrator on the registration completion notification screen 340.

[0122] This eliminates the need for the user to perform multiple operations to register the same document file in multiple external systems 6, and allows the user to register all the document files at once with a single registration operation.

[0123] <<External system API setting information stored in the external system API setting DB>> Fig. 27 shows external system API setting information in JSON format that is set by an administrator on the screens of Fig. 19 to Fig. 25 and stored in the external system API setting DB 48. Note that Fig. 27 shows the contents of the external system API setting DB 48 in more detail, but is an excerpt of the API settings stored in the chat service 7 that are relevant to this embodiment.

[0124] Fig. 27(a) shows API settings related to the registration destination set on the form detail setting screen 290 shown in Fig. 20. In Fig. 27(a), a variable 381 set in a field name column 291, a notice 382 indicating that a checkbox has been set in a form type column 292, and identification information 383 for a plurality of external systems entered in a choice input column 293 are set.

[0125] 27(b) shows a message "Please select a registration destination" displayed on the registration destination selection screen 350 displayed on the user terminal 2. This is also stored in the external system API setting DB 48 as one of the API settings.

[0126] Fig. 27(c) shows API settings related to attachment files set on the upload details setting screen 310 shown in Fig. 22. In Fig. 27(c), a variable 384 is set in the field name column 311, and a message 385 indicating that a pdf file has been selected in the document type column 312 is set.

[0127] 27(d) shows a message "Please attach a file" displayed on the file attachment screen 360 displayed on the user terminal 2. This is also stored in the external system API setting DB 48 as one of the API settings.

[0128] 27(e) shows API settings related to the request body and the like set on the API detail setting screen 330 shown in FIG. 24. FIG. 27(e) shows the URL 386 of the relay service 8, the selection of POST 387, the contents 388 (empty in FIG. 27(e)), the variable 389, the return value variable and the external system variable 391, and the variable 392 in which the document file name is stored. The URL 386 of the relay service 8 was set on the API detail setting screen 330. The selection of POST 387 was set in the method type selection field 332. The contents 388 was set in the request header field 333. The variable in which the identification information of the external system is replaced and the variable 389 associated with this variable were set in the request body field 334. The return value variable and the external system variable 391 were set in the response body field 335. The variable 392 in which the document file name is stored was set in the attachment field 336.

[0129] 27(f) shows a message "Registration is complete" displayed on the completion screen 370 displayed by the user terminal 2. This is also stored in the external system API setting DB 48 as one of the API settings.

[0130] <Action or Processing> Next, the overall flow of processing performed by the information processing system 1 will be described with reference to Fig. 28 and Fig. 29. Fig. 28 is a sequence diagram illustrating processing in which a user registers a document file in an external system via the chat service 7.

[0131] S1: The user inputs an operation to register a document into the user terminal 2.

[0132] S2: The input unit 2c accepts the input, and the communication unit 2a transmits to the chat service 7 a message indicating that document registration has been selected.

[0133] S3: The communication unit 31 of the chat service 7 receives the notification that document registration has been selected, and identifies external system API setting information to be used for selecting an external system based on the custom scenario used by the user. This external system API setting information may be the content set on the form details setting screen 290.

[0134] S4: The communication unit 31 creates the registration destination selection screen 350 using the contents set on the form detail setting screen 290, and transmits the screen information to the user terminal 2.

[0135] S5: The communication unit 2a of the user terminal 2 receives the screen information of the registration destination selection screen 350, and causes the display unit 2d to display the registration destination selection screen 350.

[0136] S6: The user selects one or more external systems (to register).

[0137] S7: The input unit 2c accepts the selection, and the communication unit 2a transmits to the chat service 7 the registration destination (identification information of the external system).

[0138] S8: The communication unit 31 of the chat service 7 receives the registration destination (identification information of the external system). The communication unit 31 identifies the external system API setting information used to specify the document file based on the custom scenario used by the user to specify the document file. This external system API setting information may be the content set on the upload details setting screen 310.

[0139] S9: The communication unit 31 creates the file attachment screen 360 using the contents set on the upload detailed setting screen 310, and transmits the screen information to the user terminal 2.

[0140] S10: The communication unit 2a of the user terminal 2 receives the screen information of the file attachment screen 360, and causes the display unit 2d to display the file attachment screen 360.

[0141] S11: The user designates a document file to be registered.

[0142] S12: The input unit 2c accepts the selection, and the communication unit 2a transmits the document file to the chat service 7 together with a registration request.

[0143] S13: The communication unit 31 of the chat service 7 receives the registration request and the document file. The response processing unit 12 detects that it is registration of a document file, and passes the registration request and the document file to the message creation unit 14. The message creation unit 14 identifies external system API setting information based on the custom scenario used by the user.

[0144] S14: The message creation unit 14 creates an HTTP request message based on the external system API setting information acquired from the external system API setting DB 48. That is, the message creation unit 14 sets the linkage URL as the destination, and sets the identification information of the external system selected by the user instead of reg_target in association with "target" in the request body. The message creation unit 14 also sets the name of the document file to be sent as document_file, and sets document_file in the request body. There are several descriptions for sending a file in HTTP, so any method may be used for sending. For example, the message creation unit 14 may write binary data of the document file in the request body. The message creation unit 14 also describes in the request body a setting to have the value of delivery_date managed by the relay service 8 set to the variable date managed by the chat service 7 and returned.

[0145] S15: The message creation unit 14 transmits the HTTP request message set in step S14 to the relay service 8 via the communication unit 31.

[0146] S16: The communication unit 51 of the relay service 8 receives the request message, and the message analysis unit 52 analyzes the request message. Details of the analysis will be described with reference to FIG.

[0147] S17: The registration unit 53 of the relay service 8 extracts the first external system A associated with "target", calls the API of the external system A, and creates an HTTP message to transmit the document file. The registration unit 53 registers the document file in the external system A by sending the HTTP message to the external system A.

[0148] S18: The registration unit 53 of the relay service 8 extracts the second external system B associated with "target", calls the API of external system B, and creates an HTTP message to transmit the document file. The registration unit 53 registers the document file in external system B by sending the HTTP message to external system B.

[0149] S19: The registration unit 53 of the relay service 8 sets the value of delivery_date (registration date) to the variable date specified by the request message, and the communication unit 31 transmits the registration date to the chat service 7. The communication unit 31 transmits the registration date if the document file can be registered in both external systems A and B, and if the document file cannot be registered in either or both of the external systems A and B, it may specify the external systems A and B and return to the chat service 7 a message indicating that the document file cannot be registered.

[0150] FIG. 29 is a flow chart illustrating the process in which the relay service 8 analyzes a request message.

[0151] First, the communication unit 51 of the relay service 8 receives a request message sent by the POST method (S101).

[0152] The message analysis unit 52 checks the format of the request body (S102). That is, the message analysis unit 52 judges whether or not identification information of an external system is set in association with the target, for example. If the message analysis unit 52 judges that the format of the request body is invalid, the communication unit 51 returns an error to the chat service 7 (S109).

[0153] If the format of the request body is normal, the message analysis unit 52 extracts one piece of identification information of an external system associated with "target" (S103).

[0154] If the identification information of the external system is extracted, the message analysis unit 52 determines which external system has been identified (S104). After that, the registration unit 53 calls the API of the external system according to the extracted identification information of the external system (S105 to S107).

[0155] If the extracted identification information of the external system is invalid (for example, if the external system is not supported by the relay service 8), the communication unit 51 returns an error to the chat service 7 (S109).

[0156] When the message analysis unit 52 determines that the identification information of the external system associated with "target" has disappeared, the communication unit 51 sets the value of delivery_date (the date of registration) to date and returns it to the chat service 7 (S108).

[0157] <Major Effects> In this embodiment, an API common to multiple external systems 6 is set in the chat service 7, so that a user can register a document file in multiple external systems 6 with a single registration operation. In addition, because the API is common to multiple external systems 6, the administrator can reduce the effort required for management, such as adding an API or a scenario, every time an external system is added.

[0158] <Other application examples> The above describes the best mode for carrying out the present invention using examples, but the present invention is not limited to these examples in any way, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention.

[0159] For example, in the present embodiment, the file to be registered is a document file, but the file to be registered may be an image file, an audio file, a video file, etc. A plurality of files to be registered in the external system may be selected at one time.

[0160] Moreover, the configuration examples in Figs. 4 to 6 are divided according to main functions to facilitate understanding of the processing by the user terminal 2, the administrator terminal 3, and the information processing system 1. The method of dividing the processing units and their names do not limit the present invention. The processing by the user terminal 2, the administrator terminal 3, and the information processing system 1 can be divided into even more processing units depending on the processing content. Also, one processing unit can be divided so as to include even more processes.

[0161] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and a device such as an ASIC (Application Specific Integrated Circuit), a DSP (digital signal processor), an FPGA (field programmable gate array), or a conventional circuit module designed to execute each function described above.

[0162] Additionally, the devices described in the examples are merely one of a number of computing environments for implementing the embodiments disclosed herein. In one embodiment, the information processing system 1 includes a number of computing devices, such as a server cluster. The computing devices are configured to communicate with each other via any type of communication link, including a network, shared memory, and the like, and perform the processes disclosed herein.

[0163] Furthermore, the information processing system 1 can be configured to share the disclosed processing steps, for example, Fig. 28 and Fig. 29, in various combinations. For example, a process executed by a specific unit can be executed by multiple information processing devices included in the information processing system 1. Also, the information processing system 1 may be integrated into one server device, or may be divided into multiple devices.

[0164] <Additional Notes> [Claim 1] An information processing system for registering data in an external system in a chat service provided to a user, A communication unit that receives the data transmitted from a user terminal; a message creation unit that creates a communication message for registering the data in a plurality of external systems based on one API setting information that is set in common for the plurality of external systems; An information processing system having the above configuration. [Claim 2] The communication unit transmits the communication message to a relay service that relays the registration of the data; The information processing system according to claim 1 , wherein the relay service includes a registration unit that registers the data in each of the plurality of external systems based on the communication message. [Claim 3] A first variable in which the plurality of external systems designated by a user are stored is set in the one piece of API setting information, 3. The information processing system according to claim 2, wherein the message creation unit creates the communication message by storing identification information of a plurality of external systems transmitted from the user terminal in the first variable. [Claim 4] A second variable for storing a name of the data is set in the one piece of API setting information, 4. The information processing system according to claim 2, wherein the message creation unit creates the communication message for transmitting the data by storing a name of the data transmitted from the user terminal in the second variable. [Claim 5] a third variable for receiving a notification that the registration unit has registered the data in the external system, and a fourth variable managed by the external system are set in the one piece of API setting information; 5. The information processing system according to claim 2, wherein the message creating unit creates the communication message including an instruction to set the value of the fourth variable to the third variable. [Claim 6] The relay service is a message analysis unit that extracts, from the communication message, identification information of the plurality of external systems stored in the first variable; 4. The information processing system according to claim 3, wherein the registration unit registers the data in each of the plurality of external systems by transmitting a plurality of communication messages that call APIs of the respective external systems extracted by the message analysis unit. [Claim 7] The communication unit can communicate with an administrator terminal, The communication unit displays a setting screen of the first variable that stores the plurality of external systems on the administrator terminal, and receives the first variable input on the setting screen; 4. The information processing system according to claim 3, wherein the first variable is stored in the one piece of API setting information. [Claim 8] when transmitting screen information of a setting screen related to a request body of the communication message to the administrator terminal, the communication unit sets the first variable received from the administrator terminal in a setting field of the request body of the setting screen; 8. The information processing system according to claim 7, further comprising: receiving, from the administrator terminal, a setting related to the request body in which the first variable is set; and storing the setting related to the request body in the one piece of API setting information. [Explanation of symbols]

[0165] 1. Information Processing Systems 2 User terminal 3. Administrator terminal 5 Operator terminal 7. Chat Service 8. Relay Services 100 Chat System [Prior art documents] [Patent documents]

[0166] [Patent Document 1] JP 2022-036861 A

Claims

1. An information processing system for registering data in an external system in a chat service provided to a user, A communication unit that receives the data transmitted from a user terminal; a message creation unit that creates a communication message for registering the data in a plurality of external systems based on one API setting information that is set in common for the plurality of external systems; An information processing system having the above configuration.

2. The communication unit transmits the communication message to a relay service that relays the registration of the data; The information processing system according to claim 1 , wherein the relay service includes a registration unit that registers the data in each of the plurality of external systems based on the communication message.

3. A first variable in which the plurality of external systems designated by a user is stored is set in the one piece of API setting information, The information processing system according to claim 2 , wherein the message creation unit creates the communication message by storing identification information of a plurality of external systems transmitted from the user terminal in the first variable.

4. A second variable for storing a name of the data is set in the one piece of API setting information, 4. The information processing system according to claim 2, wherein the message creation unit creates the communication message for transmitting the data by storing a name of the data transmitted from the user terminal in the second variable.

5. a third variable for receiving a notification that the registration unit has registered the data in the external system, and a fourth variable managed by the external system are set in the one API setting information; 3. The information processing system according to claim 2, wherein the message creation unit creates the communication message including an instruction to set the value of the fourth variable to the third variable.

6. The relay service is a message analysis unit that extracts, from the communication message, identification information of the plurality of external systems stored in the first variable; The information processing system according to claim 3 , wherein the registration unit registers the data in each of the plurality of external systems by transmitting a plurality of communication messages that call APIs of the respective external systems extracted by the message analysis unit.

7. The communication unit can communicate with an administrator terminal, The communication unit displays a setting screen of the first variable that stores the plurality of external systems on the administrator terminal, and receives the first variable input on the setting screen; 4. The information processing system according to claim 3, wherein the first variable is stored in the one piece of API setting information.

8. when transmitting screen information of a setting screen related to a request body of the communication message to the administrator terminal, the communication unit sets the first variable received from the administrator terminal in a setting field of the request body of the setting screen; The information processing system according to claim 7 , further comprising: receiving, from the administrator terminal, a setting related to the request body in which the first variable is set; and storing the setting related to the request body in the one piece of API setting information.

9. An information processing system for registering data in an external system in a chat service provided to a user, A communication unit that receives the data transmitted from a user terminal; a message creation unit that creates a communication message for registering the data in a plurality of external systems based on one API setting information that is set in common for the plurality of external systems; A program to function as a

10. A data registration method performed by an information processing system that registers data in an external system in a chat service provided to a user, comprising: receiving the data transmitted from a user terminal; A process of creating a communication message for registering the data in a plurality of external systems based on one API setting information set in common for the plurality of external systems; A method of registering data.

11. An information processing system having a chat service that responds to inquiries from user terminals and a relay service that registers data in an external system, The chat service is A first communication unit that receives data transmitted from the user terminal; a message creation unit that creates a communication message for registering the data in a plurality of external systems based on one API setting information that is set in common to the plurality of external systems, The relay service is A second communication unit for receiving the communication message; a registration unit that registers the data in each of the plurality of external systems based on the communication message; An information processing system having the above configuration.

Images