JP7472569B2 - Information processing system, information processing method, and program - Google Patents

Description

The present invention relates to an information processing system, an information processing method, and a program.

Conventionally, a computer or other device first performs pattern recognition on text, voice, images, etc. input by a user via a network. Then, based on the results of the pattern recognition, the computer or other device responds to conversations and questions from the user, controls devices, etc., in what are known as chatbots (sometimes simply called "bots").

Specifically, first, a database or the like is prepared in advance to operate the bot. Using such a database, the bot can respond to questions entered by the user. Then, first, the bot pauses transmission when it prepares to send the response to the user. Next, the data immediately before the operator responds is checked. After this check, the bot transmits the response to the user's smartphone based on the operator's instructions. In this way, a method is known that allows the operator to check the content of the operator's response (see, for example, Patent Document 1, etc.). Also known is a bot that has a function to chat with an operator in response to user instructions, so-called manned response.

If a user forgets to ask something, the user may request another chat with a human after the chat with a human has ended. However, conventional methods often do not take into account the operator who previously handled the chat with a human. Specifically, when calling an operator in response to a request for human response, a new operator other than the one who previously handled the chat may be called. If the operator is new, the corresponding operator will not know the previous content, and the user will have to explain the previous content, etc. This places a heavy burden on the user. In this way, bots (including chats between user terminals and operator terminals. hereinafter, sometimes simply referred to as "bots") are often not very convenient.

The present invention was made in consideration of the above problems, and aims to improve the convenience of bots.

An information processing system according to an embodiment of the present invention is an information processing system having one or more information processing devices connected to a user terminal that receives input from a user and an operator terminal that receives input from an operator,
a dialogue control unit that performs a first chat between the user terminal and the operator terminal;
a storage unit that stores a history of the first chat and the operator who responded in the first chat in association with each other;
and a calling unit that calls the operator who conducted the first chat to conduct a second chat after the first chat based on the history.

This can improve the usability of the bot.

FIG. 1 is a diagram illustrating an example of an overall configuration. FIG. 2 is a diagram illustrating an example of a hardware configuration of a user terminal. FIG. 2 illustrates an example of a hardware configuration of an administrator terminal. FIG. 2 illustrates an example of a hardware configuration of a server device. FIG. 2 illustrates an example of a hardware configuration of an operator terminal. FIG. 11 is a diagram showing an example of a dialogue flow based on scenario information. FIG. 11 is a diagram illustrating an example of category information. FIG. 13 is a diagram showing an example of question-answer information. FIG. 11 is a diagram showing an example of inquiry history information. FIG. 11 is a diagram illustrating an example of dialogue history information. FIG. 2 is a diagram illustrating an example of a functional configuration. FIG. 11 is a diagram illustrating a first example of the overall process. FIG. 11 is a diagram illustrating a second example of the overall processing. FIG. 11 is a diagram illustrating a third example of the overall process. FIG. 13 is a diagram showing an example of determination of switching display. FIG. 13 is a diagram showing an example of a screen for accepting a chat request. FIG. 13 is a diagram showing an example of a screen on which a chat request is not accepted. FIG. 13 is a diagram illustrating an example of manned response settings. FIG. 13 is a diagram showing an example of a screen for notifying an operator on the operator terminal. FIG. 13 is a diagram illustrating an example of switching to manned response. FIG. 13 is a diagram showing an example of a screen for accepting an evaluation operation for a manned response. FIG. 13 is a diagram showing an example of a screen displayed on an operator terminal in manned response. FIG. 13 is a diagram illustrating an example of a history.

<Overall configuration example>
1 is a diagram showing an example of an overall configuration. For example, a chatbot system 100, which is an example of an information processing system, has a system configuration including a server device 1, a user terminal 2, an administrator terminal 3, and an operator terminal 5, which are examples of information processing devices.

Server device 1 is an example of an information processing device that provides a chatbot service.

The user terminal 2 is an information processing device on which the user performs input and other operations in the chatbot service.

The administrator terminal 3 is an information processing device on which the administrator performs input operations and the like in order to manage the server device 1 and the like.

The operator terminal 5 is an information processing device on which an operator who operates the chatbot service performs input operations and the like in the chatbot service.

The server device 1, the user terminal 2, the administrator terminal 3, and the operator terminal 5 are connected to each other, for example, via a communication network 4.

For example, the communication network 4 is the Internet or the like. However, the communication network 4 may also be a LAN (Local Area Network), a WAN, a short-distance communication network, or a combination thereof, which performs wired or wireless communication.

The server device 1 communicates with the user terminal 2, the administrator terminal 3, the operator terminal 5, etc. For example, the server device 1 provides a so-called chatbot service that responds with response information that serves as an answer to input information such as a question entered by a user.

The server device 1 also provides services such as sending and receiving messages between a user and an operator, or between multiple users, i.e., chat. In other words, the server device 1 provides instant messaging services, etc. Various services may be provided by multiple information processing devices. Below, an example in which a single server device 1 provides services will be described.

<Example of user terminal>
2 is a diagram showing an example of the hardware configuration of a user terminal. For example, the user terminal 2 has a hardware configuration including a CPU (Central Processing Unit) 201, a ROM (Read Only Memory) 202, a RAM (Random Access Memory) 203, a memory 204, a communication I/F 205, an operation I/F 206, and a display device 207. The hardware included in the user terminal 2 is connected to each other, for example, by a bus. The hardware included in the user terminal 2 may be connected to other devices, etc., by wired or wireless communication.

The user terminal 2 is, for example, an information processing device such as a PC (Personal Computer), a smartphone, or a tablet.

The CPU 201 realizes the functions of a calculation unit and a control unit. The CPU 201 is also an example of a control unit and a calculation unit.

ROM 202 is a non-volatile semiconductor memory device, etc.

RAM203 is a storage device using volatile semiconductors, etc.

The memory 204 is an example of a main storage device. For example, the memory 204 stores information acquired via the communication network 4. The user terminal 2 may further include an auxiliary storage device such as a hard disk or SSD (Solid State Drive). The ROM 202, RAM 203, and memory 204, etc., realize the function of a storage unit.

The communication I/F 205 realizes the functions of a communication unit, etc. For example, the communication I/F 205 is a connection terminal and a communication circuit, etc.

The operation I/F 206 realizes functions such as an input unit. For example, the operation I/F 206 is an input device such as a button, a keyboard, a dial, a key, a touch panel, and a microphone.

The display device 207 realizes the function of the output unit. For example, the display device 207 is an output device such as a liquid crystal panel, an organic electroluminescence (EL) display, or an inorganic EL display. The display device 207 and the operation I/F 206 may be integrated into one device, such as a touch panel.

The program may be stored in, for example, an auxiliary storage device, rather than in the ROM 202 and memory 204. The program may also be acquired via a network, etc.

<Example of administrator terminal>
3 is a diagram showing an example of the hardware configuration of an administrator terminal. For example, the administrator terminal 3 has a hardware configuration including a CPU 301, a ROM 302, a RAM 303, a memory 304, a communication I/F 305, an operation I/F 306, and a display device 307. Below, an example will be described in which the administrator terminal 3 has the same hardware configuration as the user terminal 2, and duplicated explanations will be omitted. However, the administrator terminal 3 may have a different hardware configuration from the user terminal 2 and the server device 1, etc.

<Example of a server device>
4 is a diagram showing an example of the hardware configuration of a server device. For example, the server device 1 has a hardware configuration including a CPU 101, a ROM 102, a RAM 103, a memory 104, a communication I/F 105, an operation I/F 106, and a display device 107. In the following, an example will be described in which the server device 1 has the same hardware configuration as the user terminal 2, and overlapping explanations will be omitted. However, the server device 1 may have a different hardware configuration from the user terminal 2 and the administrator terminal 3, etc.

<Example of an operator terminal>
5 is a diagram showing an example of the hardware configuration of an operator terminal. For example, the operator terminal 5 has a hardware configuration including a CPU 501, a ROM 502, a RAM 503, a memory 504, a communication I/F 505, an operation I/F 506, and a display device 507. Below, an example will be described in which the operator terminal 5 has the same hardware configuration as the user terminal 2, etc., and duplicated explanations will be omitted. However, the operator terminal 5 may have a hardware configuration different from that of the user terminal 2, etc.

<Example of a database (hereinafter referred to as "DB")>
When a chatbot service is provided by the chatbot system 100, for example, the following DBs are built in advance in the server device 1. Below, an example will be described in which the server device 1 has a keyword DB, a synonym DB, a dialogue scenario DB, a category DB, a question-answer DB, an inquiry history DB, a dialogue history DB, and a contract information DB.

The keyword DB stores example characters that indicate the characteristics of questions and answers, so-called keywords. Note that keywords may be words, phrases, and sentences. The keyword DB may also store keywords related to things other than question-answer information.

For example, the server device 1 first breaks down the character string that constitutes the question into words. Next, the server device 1 searches for the keyword of the question by comparing each word with the words stored in the keyword DB. Next, the server device 1 searches for words that match the keywords from the character string of "question" in the question-answer DB, and searches for question-answer information that corresponds to the question. In this way, the keyword DB is used to extract the keywords indicated by the question.

The synonym DB stores synonym information for keywords and the like. For example, the synonym information is information that associates character strings that are similar in meaning to each other. Note that 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. 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, character strings in which one is a part of the other, or character strings that are used in similar situations. Furthermore, the synonym information may be defined arbitrarily depending on the usage environment.

First, the server device 1 breaks down the character string that constitutes the question indicated by the input information into words. Next, the server device 1 checks each word against a synonym DB and extracts character strings that are synonyms. In this way, the server device 1 checks the words and synonyms of the words included in the question against a keyword DB or the like to estimate the keywords of the question.

The dialogue scenario DB stores scenario information that realizes a dialogue according to input information. For example, the scenario information is generated so as to realize a dialogue with the user according to a scenario that is input in advance into the dialogue scenario DB.

Figure 6 is a diagram showing an example of a dialogue flow based on scenario information. For example, when input information for a user asking a question is received, the flow of responding with response information that answers the question is assumed as follows based on the scenario information.

<Example of dialogue flow based on scenario information>
For example, scenario information is input in advance by an administrator into the chatbot system so that the flow is as shown in the figure. The chatbot system then interacts with a user based on the scenario information. Specifically, scenario information, a database, a GUI (Graphical User Interface), and the like are set in advance in the chatbot system so that communication can be performed in the flow as shown in the figure. The flow will be described in detail below.

In step S31, the chatbot system first displays a selection menu on the user terminal 2 as a method for searching for questions. For example, the selection menu is a GUI that accepts an operation to have the user select one of three options: "Search all categories," "Search by selecting a category," and "Search by frequently asked questions." Note that the selection menu may display four or more options or two or less options.

When "Search all categories" is selected from the selection menu ("Search all categories" in the figure), the chatbot system proceeds to step S32. Also, when "Search from frequently asked questions" is selected from the selection menu ("Select from frequently asked questions" in the figure), the chatbot system proceeds to step S37. In addition, when "Search by selecting from categories" ("Select from categories" in the figure) is selected from the selection menu, the chatbot system proceeds to step S39.

In step S32, the chatbot system displays a message on the user terminal 2 prompting the user to input a question in text. The chatbot system also displays a GUI such as a text box on the user terminal 2 to accept an operation to input text that will be the question. Next, when a question is input ("Enter any question text" in the figure), the chatbot system proceeds to step S33.

In step S33, the chatbot system analyzes the character string indicating the question. The chatbot system then searches the question-answer DB to extract candidates that may be answers to the question (hereinafter simply referred to as "candidates"). Note that the chatbot system may obtain multiple candidates as a result of the search.

If the search in step S33 finds one candidate ("one candidate" in the figure), the chatbot system responds with the searched candidate as response information. If the search in step S33 finds two or more candidates ("two or more candidates" in the figure), the chatbot system proceeds to step S34. If the search in step S33 finds no candidate ("no candidate detected" in the figure), the chatbot system proceeds to step S36.

In step S34, the chatbot system displays a GUI on the user terminal 2 that allows the user to perform either an operation to select one of the multiple candidates or an operation to deselect all of the candidates.

In step S35, when an operation is performed to select one of the candidates ("select candidate" in the figure), the chatbot system responds with the selected candidate as response information. On the other hand, when an operation is performed to select no selection ("no match found" in the figure), the chatbot system displays, for example, an apology message on the user terminal 2 indicating that it is not possible to display an answer to the question at this stage.

In step S36, the chatbot system displays a message on the user terminal 2 apologizing and encouraging the user to search again, and then returns to step S31.

In step S37, the chatbot system refers to the inquiry history DB and extracts one or more questions (e.g., about three) that are frequently inquired about by other users. The chatbot system then displays a list of the questions on the user terminal 2. Furthermore, the chatbot system displays a GUI on the user terminal 2 to allow the user to select other search methods.

In step S38, when a question is selected ("Select a frequently asked question" in the figure), the chatbot system responds by searching the question-answer database for an answer to the selected question as response information. On the other hand, when another search method is selected in step S38 ("Select a different search method" in the figure), the chatbot system returns to step S31.

In step S39, the chatbot system displays a list of category names on the user terminal 2. Then, when an operation is performed to select a category from the list of category names ("Select category" in the figure), the chatbot system proceeds to step S40.

In step S40, the chatbot system accepts an operation to input characters that will be a question. Next, when a question is input ("Enter any question characters" in the figure), the chatbot system obtains input information that indicates the question. The chatbot system then proceeds to step S41.

In step S41, the chatbot system searches the question-answer DB to extract candidates. Next, if there is one candidate ("one answer" in the figure), the chatbot system responds with the searched candidate as response information. If there are two or more candidates ("two or more candidates" in the figure), the chatbot system proceeds to step S42. Otherwise, if no candidate can be detected ("no candidate detected" in the figure), the chatbot system proceeds to step S44.

In step S42, the chatbot system displays a GUI on the user terminal 2 that allows the user to perform either an operation to select one of the multiple candidates or an operation to deselect all of the candidates.

In step S43, when an operation is performed to select one of the candidates ("select candidate" in the figure), the chatbot system responds with the selected candidate as response information. On the other hand, when an operation is performed to select no selection ("no match found" in the figure), the chatbot system displays, for example, an apology message on the user terminal 2 indicating that it is not possible to display an answer to the question at this stage.

In step S44, the chatbot system displays a message of apology and a message encouraging the user to search again on the user terminal 2, and then returns to step S31.

The scenario information is input, for example, assuming the dialogue flow as described above. In other words, the scenario information indicates the results of the administrator's settings regarding the types of GUIs to be used in the dialogue flow, the order in which messages and GUIs are output, etc.

The category DB stores category information for classifying questions. For example, the category information is as follows:

Figure 7 is a diagram showing an example of category information. For example, as shown in the figure, category information is information consisting of "ID", "category name", and "update date and time".

"Category name" indicates the category to which the question applies.

"ID" indicates ID (Identification), i.e., the identification information for each category.

"Update date and time" indicates the date and time each piece of information was updated.

The question-answer DB stores information that associates questions with answers to those questions (hereinafter referred to as "question-answer information"). For example, the question-answer information is created in advance by an administrator or the like, and stored in the question-answer DB. For example, the question-answer information is information such as the following:

Figure 8 is a diagram showing an example of question-answer information. For example, as shown in the figure, the question-answer information is information that is composed of "ID," "question," "similar question," "answer," "category ID," and "update date and time."

"ID" indicates the ID, i.e., the identification information of each question-answer piece of information.

"Question" indicates the content of the question.

"Similar Questions" refers to questions with similar content to the question entered in "Question".

"Answer" indicates the answer to the question.

"Category ID" indicates the category ID that identifies the category to which the question applies.

"Update date and time" indicates the date and time each piece of information was updated.

The inquiry history DB stores information indicating questions previously entered by users (hereinafter referred to as "inquiry history information"). For example, inquiry history information is information such as the following:

Figure 9 is a diagram showing an example of inquiry history information. As shown in the figure, the inquiry history information is information consisting of "ID", "session ID", "ID of the category linked to the hit question", "ID of the hit question", "user input", "feedback", and "date and time".

"ID" indicates the ID, i.e., the identification information of each inquiry history information.

"Session ID" indicates identification information that can identify the dialogue session in which the question was asked.

"Category ID associated with the hit question" indicates the category ID that identifies the category to which the question applies.

"Hit question ID" indicates the question ID.

"User Input" shows the question entered by the user.

"Feedback" indicates whether the user provided feedback in response to the question.

"Date and time" indicates the date and time the conversation took place.

An interaction session is a collection of interactions that take place between a user terminal and a server device. For example, interactions that constitute the same interaction session are interactions that take place between the time when a screen used for interaction in chat format or the like 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 preset period of time. A session timeout is a process that ends the screens and other screens used for interaction.

Note that an interactive session is not limited to the above example. For example, one interactive session may be from the input of a question, to the response of an answer, to the input of feedback by the user in response to the answer. In this case, one interactive session is completed when feedback is obtained from the user.

The dialogue history DB stores information (hereinafter referred to as "dialogue history information") indicating the history of statements input to the user terminal 2 and the contents output by the server device 1 during dialogue between the user terminal and the server device. For example, the dialogue history information is information such as the following:

Figure 10 is a diagram showing an example of dialogue history information. As shown in the figure, dialogue history information is information consisting of "ID", "session ID", "comment type", "comment content", "comment type ID", "content ID", and "date and time".

"ID" indicates the ID, i.e., the identification information of each piece of dialogue history information.

"Session ID" indicates an ID that can identify the interaction session in which the interaction took place.

"Statement type" indicates the type of person who made the comment. Specifically, either "0" or "1" is entered into "Statement type." "0" indicates that the comment was made by an administrator. On the other hand, "1" indicates that the comment was made by a user.

"Content of statement" indicates the content of what was said.

The "statement type ID" is input, for example, as "5-0," "5-1," or "5-2." Based on these inputs, the "statement type ID" indicates which of the "category," "question-answer information," or "scenario" the "statement content" corresponds to.

If the statement type is a scenario, the "content ID" indicates the statement set in the scenario. If the statement type is question-and-answer information, the "content ID" indicates the ID of the question-and-answer information. If the statement type is a category, the "content ID" indicates the statement that selects a category.

"Date and time" indicates the date and time the conversation took place.

The contract information DB stores the contents of a contract that has been concluded in advance with a user. For example, information such as whether or not a person will be available to respond and the period during which the response will be provided is entered in advance into the contract. In addition, the server device 1 may store the acquired information on the contract, etc., in association with a tenant ID, etc.

The type and configuration of the DB are not limited to the above example. That is, the DB may be in another format. Also, the DB may be configured to store data in a distributed manner across multiple devices. Furthermore, each DB is not essential. That is, as long as the data that can realize the scenario is available, the format of the DB, etc. does not matter.

<Function block diagram>
11 is a diagram showing an example of a functional configuration. For example, the chatbot system 100 preferably has a functional configuration including an input information acquisition unit 100F1, a search unit 100F2, a response unit 100F3, a dialogue control unit 100F4, a storage unit 100F5, a call unit 100F6, an evaluation unit 100F7, and a management unit 100F8.

The input information acquisition unit 100F1 performs an input information acquisition procedure to acquire input information input to the user terminal 2.

The search unit 100F2 performs a search procedure to search for response information to the input information.

The response unit 100F3 performs a response procedure to respond to the input information by sending response information to the user terminal 2.

The input information acquisition unit 100F1, the search unit 100F2, and the response unit 100F3 respond by outputting response information at the output unit 2F2 in response to the input information input via the input unit 2F1, thereby realizing a dialogue between the bot and the user, i.e., the bot. For example, the input information acquisition unit 100F1, the search unit 100F2, and the response unit 100F3 are realized by the communication I/F 105, the CPU 101, the memory 104, etc.

The dialogue control unit 100F4 performs a dialogue control procedure to realize a chat between the user terminal 2 and the operator terminal 5. For example, the dialogue control unit 100F4 is realized by the communication I/F 105, etc.

The storage unit 100F5 performs a storage procedure to store the history of the first chat and the operator who responded in the first chat in association with each other. For example, the storage unit 100F5 is realized by the memory 104, etc.

Based on the history, the calling unit 100F6 performs a calling procedure to call the operator who conducted the first chat in order to conduct the second chat. For example, the calling unit 100F6 is realized by the communication I/F 105, etc.

The evaluation unit 100F7 performs an evaluation procedure to receive the satisfaction level of the first chat. For example, the evaluation unit 100F7 is realized by the communication I/F 105, etc.

The management unit 100F8 performs various management functions for chat and other activities.

Input unit 2F1 and input unit 5F1 accept operations.

Output unit 2F2 and output unit 5F2 output various displays.

Control unit 2F3 and control unit 5F3 control each terminal.

The server device 1 may further have functions such as a calculation unit and a control unit, which are realized by the CPU 101 or the like. The server device 1 may further have functions such as an input unit, an output unit, a storage unit, and a communication unit. Furthermore, the user terminal 2 may further have functions such as a calculation unit, a control unit, a storage unit, an input unit, an output unit, and a communication unit.

<Overall processing example>
12 is a diagram showing a first example of the overall processing. The following describes an example in which the server device 1 performs processing for realizing a chatbot service by itself. In addition, in the following description, it is assumed that there are two operator terminals 5, a first operator terminal 51 and a second operator terminal 52. That is, in this example, it is assumed that the operator group is made up of two operators. The number of operator terminals 5 may be one, or three or more.

In step S101, the input unit 2F1 accepts an operation to start the chatbot. Specifically, the input unit 2F1 accepts an operation to press a specific icon included in a web page displayed in a browser or the like, an operation to start an application used for dialogue that is pre-installed in the user terminal 2, or an operation to press a specific button on an application used for dialogue.

In step S102, the input information acquisition unit 100F1 acquires a bot startup request from the user terminal 2. The input information acquisition unit 100F1 may acquire a tenant ID in the bot startup request. The following describes an example in which a tenant ID is acquired.

The tenant ID is information that is held in advance by the user terminal 2. For example, the tenant ID may be held by a browser or an application. The tenant ID is also information that identifies a subscriber (tenant).

In step S103, the management unit 100F8 acquires contract information based on the tenant ID. For example, information such as whether or not a person will be available to respond and the period during which the response will be provided is input in advance into the contract information. In addition, the DB stores the contract information in association with a session ID, etc.

In step S104, the response unit 100F3 identifies the scenario.

In step S105, the response unit 100F3 transmits the scenario information.

In step S106, the output unit 2F2 displays the scenario based on the scenario information.

In step S107, input unit 2F1 accepts input information such as a question.

In step S108, the input information acquisition unit 100F1 acquires the input information.

The input information may be information entered in a free format, in which a character string that serves as a question is entered, or information entered in a multiple-choice format, in which a choice is made from options prepared in advance in scenario information, etc.

In step S109, the input information acquisition unit 100F1 transmits the input information.

In step S110, the search unit 100F2 searches for response information to the input information.

In step S111, the response unit 100F3 responds with response information. The response unit 100F3 also transmits the items to be displayed on the screen.

Note that steps S107 to S111, i.e., the dialogue by the bot that does not include a response by an operator, may be repeated.

In step S112, the output unit 2F2 displays the response information.

In step S113, the evaluation unit 100F7 accepts the evaluation of the bot.

In step S114, the input unit 2F1 accepts a response request from the operator.

In step S115, the dialogue control unit 100F4 starts a chat between the user terminal 2 and the operator terminal 5. The dialogue control unit 100F4 also acquires a user ID, which is an example of user identification information, from the user terminal 2.

In step S116, the calling unit 100F6 accepts a call request from the operator.

In step S117, the calling unit 100F6 identifies the previously corresponding operator based on the history and user ID stored in the storage unit 100F5.

If an operator has previously handled a user, the history of the chat that took place between the user terminal and the operator terminal (hereinafter, the previous chat may be referred to as the "first chat") is stored in association with the user ID. Therefore, if a matching history is found in the search results for history using the user ID as a key, it is possible to identify the user as one who the operator previously handled, and to specify the operator who previously handled the user.

On the other hand, if you are chatting with an operator for the first time, there is no history, so it is determined that there is no relevant history.

The following describes an example of a chat that takes place after the first chat (i.e., when the history of the first chat is stored in the storage unit 100F5) (hereinafter, a chat that takes place after the first chat may be referred to as a "second chat").

In step S118, the calling unit 100F6 calls the operator associated with the history of the first chat. For example, the calling unit 100F6 displays the name of the operator corresponding to the first chat on a screen for calling the operator, and calls the operator.

In the following, it is assumed that the operator of the first operator terminal 51 is the operator who handled the first chat, and that the operator of the first operator terminal 51 responds to the call and the second chat takes place.

In step S119, the input unit 5F1 accepts a response request from the operator.

In step S120, the output unit 5F2 displays a screen for conducting the second chat.

In step S121, the dialogue control unit 100F4 notifies the first operator terminal 51 of the receipt of the request.

In step S122, the dialogue control unit 100F4 notifies the operator that dialogue is possible in response to a request for assistance from the operator.

In step S123, a chat takes place between the user terminal 2 and the first operator terminal 51. Thus, in step S123, when the user inputs a question or the like to the user terminal 2, the content of the question asked by the user is displayed on the first operator terminal 51. The answer to this question is input by the operator to the first operator terminal 51. Such questions and answers are repeated to carry out a dialogue.

In step S124, the input unit 2F1 accepts the end of the response.

In step S125, the dialogue control unit 100F4 accepts the end of the response.

In step S126, the input unit 5F1 accepts the end of the response by the operator.

In step S127, the dialogue control unit 100F4 accepts the end of the operator's response.

In step S128, the dialogue control unit 100F4 notifies the end of the response.

In step S129, the evaluation unit 100F7 accepts an evaluation of satisfaction with manned response, etc.

In step S130, the evaluation unit 100F7 stores the chat history and the operator who responded to the chat in association with it.

In this way, the chat is completed. When the chat is completed, the history and the like of the completed chat are saved, and henceforth, it becomes the "first chat". On the other hand, after the first chat, the user may start a chat again, for example, as follows. In this way, the chat that is started (in this example, step S123) becomes the "second chat".

In step S131, similar to step S106, the output unit 2F2 displays the scenario based on the scenario information.

In step S132, similar to step S115, the dialogue control unit 100F4 inputs the start of a chat between the user terminal 2 and the operator terminal 5.

In step S133, similar to step S116, the calling unit 100F6 accepts a call request from the operator.

<Modification of Overall Processing>
The overall process may be, for example, the following process: Hereinafter, the same processes as those in the first example are denoted by the same reference numerals, and duplicated explanations will be omitted.

Figure 13 is a diagram showing a second example of the overall process. Compared to the first example, it differs in that steps S107 to S113 are not included. In other words, in the second example, there is no response by a bot, and human response is provided from the start.

In this way, live response, i.e., chat with an operator, may begin at other times, not necessarily after a response by a bot.

Note that human response does not necessarily have to start from the beginning, but can occur while the bot is responding.

Figure 14 shows a third example of the overall process. Compared to the first example, steps S117 and S118 are different.

First, in the third example, when a human response is performed, the evaluation unit 100F7 accepts the satisfaction level of the human response. That is, in the first chat, the satisfaction level with the responding operator is stored in association with the history of the first chat, etc.

When conducting a second chat, it is desirable to carry out the following process to call an operator.

In step S117, the calling unit 100F6 identifies the previously responsive operator (the operator who handled the first chat) based on the history stored in the storage unit 100F5 and the user ID. Furthermore, the calling unit 100F6 obtains the satisfaction level with the first chat. Then, the calling unit 100F6 determines whether the satisfaction level with the first chat is high or low.

In step S118, if the satisfaction level with the first chat is high, the calling unit 100F6 calls the operator corresponding to the first chat (in the illustrated example, a process of calling the first operator terminal 51 is performed).

When satisfaction is high, the response from an operator who previously handled the case is often more suitable for the user requesting the response. Therefore, if the operator who previously handled the case responds again, the user can be provided with a response that is highly satisfactory.

On the other hand, if the satisfaction level for the first chat is low, the calling unit 100F6 notifies an operator other than the operator who previously handled the chat. For example, the calling unit 100F6 notifies all members of the operator group.

In addition, when notifying all of the operator group, the calling unit 100F6 may notify only the operators who have previously responded, but may also limit the notification to calling only the operators who have previously responded. In other words, operators other than the operators who have previously responded may not be called.

There may be cases where the operator who previously handled the call is currently busy with another task and is therefore unable to respond. For example, this may be the case when the operator's status is "unavailable" or the call time is long. Therefore, when it is determined that the operator who previously handled the call is unable to respond, the call unit 100F6 may notify all members of the operator group.

<Example of operator call processing>
15 is a diagram showing an example of a determination of a switching display. In order to determine whether or not to display a switching display, which is an operation screen for switching to a response by an operator when a user requests a response by an operator, for example, the following processing may be performed.

In step S201, the server device 1 determines whether the contract is one that requires "operator support." In other words, the server device 1 determines whether the contract requires the user to be supported by an operator based on the contract contents. The contract contents, etc. are input to the server device 1 in advance.

Next, if it is determined that the contract is "operator-assisted" (YES in step S201), the server device 1 proceeds to step S202. On the other hand, if it is determined that the contract is not "operator-assisted" (NO in step S201), the server device 1 proceeds to step S205.

In step S202, the server device 1 determines whether "Use manned chat support" is set to "ON."

Next, if it is determined that "Use manned chat support" is set to "ON" (YES in step S202), the server device 1 proceeds to step S203. On the other hand, if it is determined that "Use manned chat support" is not set to "ON" (NO in step S202), the server device 1 proceeds to step S205.

In step S203, the server device 1 determines whether or not there is an available operator. If there is more than one operator, the server device 1 determines that there is an available operator if there is even one operator in the "available" state (YES in step S203).

Whether an operator is available, unavailable, or currently available is set, for example, on an operation screen displayed on the operator terminal, such as the one below.

The operator terminal 5 also stores operator identification information for identifying the operator that was entered when the operator logged in to the operation screen, and transmits the operator identification information to the server device 1 together with a request to change the operator's status. Based on the request, the server device 1 changes the status of the operator corresponding to the operator identification information to "available."

The operation screen also displays a list of on-call information. The on-call information may display the question used by the bot to respond to the last user, category information of the answer information, and input information such as a question entered by the user corresponding to that answer (hereinafter referred to as "last input information"). By referring to this information, the operator can understand which answer from the bot the user wants to talk to the operator about. Then, when the operator selects the on-call information he/she wants to respond to, a reception screen is displayed and the operator can respond to the call. In response to the operator selecting the on-call information, the status of the operator is changed to "responding" and the selected on-call information is moved to the "responding to me" column. Furthermore, the operator can also respond to a call to the operator by pressing the "operator on-call" button displayed in the navigation menu on the left side of the operation screen.

In addition, this operation screen can display a list of calls currently being handled by other operators and chats currently being handled by the bot.

Next, if it is determined that an operator is available to respond (YES in step S203), the server device 1 proceeds to step S204. On the other hand, if it is determined that an operator is not available to respond (NO in step S203), the server device 1 proceeds to step S205.

In step S204, the server device 1 decides to display the switching display.

In step S205, the server device 1 decides not to display the switching display.

<Display screen example>
16 is a diagram showing an example of a screen for accepting a chat request. It is a diagram showing an example of a screen for displaying a switching display. That is, when it is determined in step S204 that the switching display is to be displayed, for example, in the case of displaying an evaluation reception screen as shown in the figure, a switching reception screen for manned response is displayed.

First, a message MES is output based on a scenario, etc., and the chatbot service begins.

Next, in step S107, input information INFI, which is a character string or the like indicating the content of the question the user wants to ask, such as "medical care," is input.

Next, response information INFA is returned in response to the input information INFI. In this example, the response information INFA is information about the URL (Uniform Resource Locator) of a useful homepage.

Note that such exchange of input information INFI and response information INFA may occur multiple times.

Then, a button for performing an evaluation operation (hereinafter referred to as the "bot evaluation button AP1") is displayed on the screen. In addition, a button for performing a switching operation to switch between the user terminal and the operator terminal so that chat can be conducted (hereinafter referred to as the "attended switching button SW") is displayed on the screen.

This screen accepts either evaluation or switching operations.

Figure 17 shows an example of a screen where a chat request is not accepted. That is, if it is determined in step S205 that the switching display should not be displayed, for example, the following display is shown. Compared to Figure 16, Figure 17 differs in that there is no manned switching button SW.

In other words, if the switching display is not displayed, the bot evaluation button AP1 is accepted and the interaction between the bot and the user ends.

Figure 18 shows an example of settings for manned response. For example, the settings are made using a GUI such as a checkbox CBX as shown in the figure.

Specifically, when the check box CBX is set to "ON" for the item "Use manned chat support," the server device 1 determines that "Use manned chat support" is set to "ON" (YES in step S202).

The setting of whether or not to provide manned chat support is not limited to input using the checkbox CBX. For example, the setting of whether or not to provide manned chat support may be set by inputting a time, etc. As shown in the figure, the end time for manned chat support may be set, such as "17:30". With such a setting, after "17:30", the server device 1 determines that "Use manned chat support" is not set to "ON" (NO in step S202). It is also possible to set types other than time.

Figure 19 is a diagram showing an example of a screen for notifying an operator terminal. A call by the calling unit is made, for example, by displaying a screen as shown in the figure on the operator terminal 5. As shown in the figure, when the operator is in a "calling state," and performs an operation to accept the call, a chat is then conducted between the user terminal 2 and the operator terminal 5.

As shown in the figure, a notification MS is sent when the call is made. Specifically, the notification MS displays information about the first chat in the "Notification of operator information and history" field.

The notification MS displays operator identification information MS1, first chat details information MS2, and history MS3, etc.

"Handling operator name" is the name or ID of the operator who handled the first chat. For example, in this way, the operator who handled the first chat is notified by the operator identification information MS1. In this way, the notified operator (in this example, "Operator A") can understand that this is a chat that should be handled as much as possible.

The notification MS may also indicate the first chat details information MS2 and history MS3, etc.

First chat detail information MS2 is an example showing the "response start time." The notification MS may also show, for example, when the first chat took place, just like the first chat detail information MS2.

History MS3 is a link to the history of the first chat. With such a GUI, it is easy to check what the first chat was about, etc.

Note that the notification MS does not have to be in the format shown in the figure. Therefore, the notification MS may include other information.

In addition, the following operations may be possible on the screen:

For example, whether an operator is available, unavailable, or currently available is received in a GUI using a button (hereinafter referred to as a "status switch SET") that can display and input the status.

The status switch SET may be set to "available", "unavailable", or "in service" by an operator. On the other hand, the operator terminal may set it to "in service" or the like based on, for example, the input of a character string indicating that the operator is responding to another user.

In addition, for example, if the operator is away from his/her desk, the status switch SET may be set to "unavailable" or the like based on the absence of input to the sensor or operator terminal for a certain period of time.

On the other hand, even if a call is "in progress," some operators may be able to handle multiple users. Therefore, even if a call is "in progress," an operator may be able to set the call to "available."

The operation screen may also display category information INFC of the question-answer information used by the bot to last answer the user, and input information such as a question entered by the user corresponding to that answer (hereinafter referred to as "last input information INFQ"). By referring to information such as category information INFC and last input information INFQ, the operator can understand which answer from the bot the user wants to discuss with the operator about.

Figure 20 shows an example of switching to manned response. As shown in the figure, the chat CT between the user and the operator is realized by an exchange of input by the user (hereinafter referred to as "user input INUR") and input by the operator (hereinafter referred to as "operator input INOP").

User input INUR is a question or the like entered on the user's terminal.

Operator input INOP is the response to a question entered at the operator terminal.

In this way, manned chat CT is carried out.

When the chat CT ends, an evaluation of the human response may be accepted separately from the evaluation of the chatbot. For example, an evaluation of the human response may be accepted on a screen like the one below.

FIG. 21 is a diagram showing an example of a screen that accepts an evaluation operation for a manned response. For example, a button for inputting an evaluation for a manned response as shown in the figure (hereinafter referred to as the "manned response evaluation button AP2") may be displayed on the user terminal 2. In other words, customer satisfaction, etc. may be evaluated separately from the bot using the manned response evaluation button AP2, etc.

For example, the result of input to the manned response evaluation button AP2, i.e., the satisfaction level with the manned response, is saved in step S130.

The notification to the operator may be changed based on the satisfaction level. For example, if the satisfaction level is low in the first chat, i.e., the previous manned response, the operator who handled the first chat may not be notified. For example, if the satisfaction level is low, in step S118, the calling unit 100F6 may notify all members of the operator group. On the other hand, if the satisfaction level is high, in step S118, the calling unit 100F6 notifies the operator who handled the first chat.

The criteria for determining whether satisfaction is high or not are set in advance.

As described above, the corresponding operator may be selected based on the level of satisfaction. In this way, if an operator who is likely to be highly satisfied is selected to provide a human response, a human response that provides high user satisfaction can be provided.

As shown in the figure, the manned response evaluation button AP2 may also have a button for chatting again with the same operator, such as "I would like to chat with the person in charge again." Specifically, when the "I would like to chat with the person in charge again" button is pressed and accepted by the operator, for example, a call screen INRE is displayed. After the call screen INRE is displayed, the chat is resumed by user input INUR, for example, in the same manner as described in FIG. 20.

Figure 22 is a diagram showing an example of a screen displayed by the operator terminal during manned response. For example, the operator terminal 5 may display a response history of responses made by a bot (hereinafter referred to as "bot response history INFB"), etc.

The bot response history INFB shows the response information given by the bot before switching to human response. With such a bot response history INFB, the operator can understand how the bot responded, etc.

Human response is performed on the human response screen INFH, etc. As described above, the ability to provide human response allows for more detailed response and increases user satisfaction.

The bot response history INFB may also include a history of human responses. Specifically, the results of input by the user and the operator in the dialogue in the first chat may also be displayed.

<Example of data stored in the server device>
The server device 1 manages the operator status and the like, for example, as shown in Table 1 below.

上記（表１）において、「オペレータＩＤ」は、オペレータを識別するＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）である。

In the above (Table 1), "operator ID" is an ID (identification) that identifies an operator.

"Status" indicates the operator's condition.

The server device 1 also has data such as that shown in Table 2 below. For example, the history of the first chat is saved as data such as that shown in Table 2 below.

The "session ID" is an ID for identifying a chat or the like.

"Status" indicates the response status.

"Operator" will show the operator on-hand if a person is present to respond to the call.

"Start date and time" indicates the date and time when support via chat, etc. began.

The "first question" is the information entered first.

"Answer category" is a category that is classified based on the input information, etc.

"User ID" is an example of user identification information that identifies a user. For example, the user ID is identification information possessed by the application software or browser used to execute the bot.

For example, when the first chat ends, the "status" in Table 2 above is set to "responded by a human." If such data is generated upon the completion of the first chat, the history corresponding to the first chat is saved.

Then, in step S117 shown in FIG. 12, a "user ID" is searched for in data with a "status" of "responded by a human." If matching data is found as a result of this search, it is determined that there is a history of the first chat. In this way, when matching data is found by searching the "user ID" of the target user, the "operator" in that data is identified as the operator who previously responded. The operator identified in this way becomes the one to be called in the second chat (step S118).

The user identification information may be an ID used for logging in when logging in to a specific service, etc., using a browser, etc., to execute the bot. If such an ID used for logging in, etc., is used as the user identification information, the user can be identified as a user with whom the user has previously chatted, even if the user terminal 2 becomes a different information processing device.

Alternatively, the user identification information may be an IP (Internet Protocol) address, etc.

Furthermore, the user identification information may be a session ID or the like. For example, since closing the browser often ends the chat and separates the session, when the first chat ends by closing the browser, etc., the user terminal 2 saves the session ID of the first chat. Then, when the second chat starts, a request to start the chat is made using the session ID of the first chat as user identification information. In this way, by using the session ID, the results of a previous chat can be identified using the above (Table 2) or the like, and it is possible to identify the user as having chatted before. In this way, the user identification information may be information that can identify whether the user is a user who has chatted before and the previous history, etc.

"History" refers to chat history, etc. For example, the history is stored in JSON (JavaScript (registered trademark) Object Notation) format as follows:

Figure 23 shows an example of a history.

"Inputter" refers to the entity that issues a question, etc. In this case, the "inputter" is a "user," a "bot," or an "operator."

"Chat content" refers to the question entered or the content of the response, etc. In this way, when the history can be identified, the operator can look at the history and understand what kind of conversation took place in the previous chat, i.e., the first chat.

"Date and time" is the date and time when the question was asked.

<Summary>
As described above, when a second chat is started after a first chat, the information processing system calls the operator who handled the first chat from among the group of operators so that the operator can respond with priority. In this way, when the operator who handled the first chat is given priority, the operator is often familiar with the contents of the first chat because he or she has responded before. Therefore, in the second chat, a highly satisfying response that takes into account the circumstances of the first chat can be realized.

When a new operator responds in the second chat, the user will have to explain the previous content, etc., since they will not know the previous content. This means the user will have to re-enter the details of what has happened up to now to the new operator, which can reduce usability. In contrast, if the operator who responded in the first chat takes priority, the user will have to do less re-entering and other work, improving the usability of the bot.

In this way, if the operator who handled the first chat, which is stored in association with the history, can also handle the second chat based on the history, the convenience of the bot can be improved.

<Other embodiments>
In the information processing system, each procedure in the information processing method described above may be performed in parallel, distributed, or redundantly by a plurality of information processing devices, etc. Furthermore, the information processing system may be configured to utilize so-called cloud computing, etc.

Furthermore, each device does not have to be a single device. In other words, each device may be a combination of multiple devices. Note that the information processing system may be configured to further include devices other than those described above.

The information processing system and the information processing device may also use AI (Artificial Intelligence) or the like. For example, the information processing system and the information processing device may be configured to perform machine learning or the like when inputting characters, etc., to improve recognition accuracy.

All or part of the processes according to the present invention may be written in a computer language and realized by a program for causing a computer to execute the information processing method. In other words, the program is a computer program for causing a computer, such as an information processing device or an information processing system, to execute the information processing method.

Therefore, when the information processing method is executed based on the program, the arithmetic unit and control unit of the computer perform calculations and control based on the program to execute each procedure. Also, the storage unit of the computer stores data used in processing based on the program to execute each procedure.

The program may also be distributed by recording it on a computer-readable storage medium. The storage medium may be a magnetic tape, flash memory, optical disk, magneto-optical disk, magnetic disk, or other such medium. Furthermore, the program may be distributed through telecommunications lines.

Although one example of an embodiment has been described above, the present invention is not limited to the above embodiment. In other words, various modifications and improvements are possible within the scope of the present invention.

1 Server device 2 User terminal 2F1 Input unit 2F2 Output unit 2F3 Control unit 3 Administrator terminal 4 Communication network 5 Operator terminal 5F1 Input unit 5F2 Output unit 5F3 Control unit 51 First operator terminal 52 Second operator terminal 100 Chatbot system 100F1 Input information acquisition unit 100F2 Search unit 100F3 Response unit 100F4 Dialogue control unit 100F5 Storage unit 100F6 Call unit 100F7 Evaluation unit 100F8 Management unit AP1 Bot evaluation button AP2 Staff response evaluation button CBX Check box CT Chat INFA Response information INFB Bot response history INFC Category information INFH Staff response screen INFI Input information INFQ Most recent input information INOP Operator input INUR User input MES Message MS Notification MS1 Operator identification information MS2 First chat detailed information MS3 History SET Status switch SW Staff switch button

JP 2018-163525 A

Claims (8)

An information processing system having one or more information processing devices connected to a user terminal that receives input from a user and an operator terminal that receives input from an operator,
a dialogue control unit that performs a first chat between the user terminal and the operator terminal;
a storage unit that stores a history of the first chat and the operator who responded in the first chat in association with each other;
a calling unit that calls the operator who conducted the first chat to conduct a second chat after the first chat based on the history,
One of the operators in the group including the operator responds via chat,
The calling unit includes:
Among the group of operators, the operator who handled the first chat is called to handle the second chat with priority;
notifying all members of the group of operators and indicating that the operator has responded to the first chat based on the history;
Information processing system. An acquisition unit that acquires input information input to the user terminal;
a search unit that searches for response information to the input information;
The information processing system according to claim 1 , further comprising a response unit that responds to the input information with the response information to the user terminal. The calling unit includes:
3. The information processing system according to claim 1, further comprising: notifying the operator who handled the first chat. 4. The information processing system according to claim 3 , wherein, when the operator who handled the first chat is unable to respond, a notification is sent to an operator other than the operator who handled the first chat, among the group of operators. The user terminal,
having user identification information for identifying the user;
The storage unit includes:
The history and the user identification information are stored in association with each other;
The calling unit includes:
Obtaining the user identification information from the user terminal;
Identifying the history by the user identification information;
The information processing system according to claim 1 , further comprising: identifying the operator who responded in the first chat corresponding to the history. An evaluation unit that receives a satisfaction level of the first chat,
The calling unit includes:
6. The information processing system according to claim 1, wherein, based on the satisfaction level, a notification is made to the operator who handled the first chat, or to all of a group of operators. An information processing method performed by an information processing system having one or more information processing devices connected to a user terminal that receives input from a user and an operator terminal that receives input from an operator, comprising:
a dialogue control procedure in which the information processing system performs a first chat between the user terminal and the operator terminal;
a storage step in which the information processing system stores a history of the first chat and the operator who responded in the first chat in association with each other;
a calling procedure for calling the operator who conducted the first chat to conduct a second chat after the first chat is conducted, based on the history,
One of the operators in the group including the operator responds via chat,
The calling procedure comprises:
Among the group of operators, the operator who handled the first chat is called to handle the second chat with priority;
notifying all members of the group of operators and indicating that the operator has responded to the first chat based on the history;
Information processing methods. A program for causing a computer to execute the information processing method according to claim 7 .

Images