JP2018161715A - Dialogue control device and dialogue system - Google Patents

Abstract

An object of the present invention is to reduce the feeling of boredom of a customer and improve the satisfaction of dialogue. An interaction control device includes an information acquisition unit that acquires interaction scenario information for interacting with a customer who has visited a restaurant, and an interaction that performs control for causing the interaction scenario to proceed with the customer according to the interaction scenario information. The control section, the replay scenario determination section for determining whether or not the conversation scenario to be advanced is a replay scenario having the same contents as the conversation scenario executed while the customer stays at the restaurant, and is not a replay scenario A scenario correcting unit that corrects the reappearance scenario when it is determined to be a reappearance scenario. [Selection] Figure 1

Description

  The present invention relates to a dialog control apparatus and a dialog system for performing a dialog with a customer who has visited a restaurant.

  Along with remarkable progress in robot technology, research and development have been conducted on mechanisms for interaction between robots and humans in various fields. A technique has been proposed in which a plurality of robots can interact with each other and also with a human.

Japanese Patent Laying-Open No. 2015-66623

  At present, robots have much lower dialogue capabilities than the human brain. Therefore, in the above-described conventional technology, the robots or the robot and the humans have a dialogue according to a dialogue story prepared in advance.

  However, since the dialogue information included in the dialogue story is limited, the robot and the human may repeat the dialogue with the same content many times. As a result, humans get bored, can no longer enjoy the dialogue with the robot, and the interest in the dialogue with the robot is diminished.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a dialog control device and a dialog system capable of reducing the feeling of boredom of a customer and improving the satisfaction of the dialog. Is.

In order to solve the above problems, in one aspect of the present invention, an information acquisition unit that acquires dialog scenario information for interacting with a customer who has visited a restaurant;
A dialog control unit that performs control to advance a dialog scenario with the customer according to the dialog scenario information;
A replay scenario determination unit that determines whether or not the dialog scenario to be progressed is a replay scenario having the same content as the conversation scenario executed while the customer stays at the restaurant;
Dialog control comprising: a scenario correction unit that advances the dialog scenario to be advanced when it is determined that the scenario is not the repeat scenario, and corrects the repeat scenario when the scenario is determined to be the restart scenario An apparatus is provided.

A stay state determination unit for determining a stay state of the customer in the restaurant may be provided,
The scenario correction unit may correct the repeat scenario in consideration of the stay state of the customer.

  The scenario correction unit may change the utterance content uttered before the start of the re-appearance scenario according to the staying state of the customer.

  The scenario correction unit may change at least a part of the content of the repeat scenario according to the stay state of the customer.

The stay state of the customer determined by the stay state determination unit is:
A state from when the customer enters or sits in the restaurant to order food and drink;
Waiting for food and drink ordered by the customer to be provided;
The state until the customer completes eating and drinking of food and drink,
It may include at least one of a state from when the customer completes eating and drinking of food and drink until the customer leaves the store.

  When the scenario correction unit starts the progress of the return scenario before the customer finishes the order of food and drink, the utterance for notifying the start of the return scenario before starting the progress of the return scenario May be performed.

  The scenario correction unit determines whether to start the progress of the return scenario when starting the progress of the return scenario when the customer finishes the order and waits for the order to arrive. May be started, and when the customer gives an instruction to start progress of the recall scenario, the progress of the recall scenario may be started.

  The scenario correction unit may start the progress of the summary scenario that summarizes the return scenario when the customer starts the return scenario while the customer is eating.

  The dialogue control unit may cause a dialogue scenario to proceed between the robot that performs an operation according to a command signal in order to interact with the customer and the customer according to the dialogue scenario information.

In another aspect of the present invention, a robot that performs an operation according to a command signal in order to interact with a customer who has visited a restaurant,
An operation terminal for generating the command signal for operating the robot;
An information acquisition unit for acquiring dialog scenario information for interacting with the customer;
A dialog control unit that performs control to advance a dialog scenario with the customer according to the dialog scenario information;
A replay scenario determination unit that determines whether or not the conversation scenario to be advanced is a replay scenario that is a repetition of a previously executed conversation scenario;
A dialogue system comprising: a scenario correction unit that advances the dialogue scenario to be advanced when it is determined that the scenario is not the restart scenario, and corrects the restart scenario when the scenario is determined to be the restart scenario Is provided.

  The operation terminal may include the information acquisition unit, the dialogue control unit, the reoccurrence scenario determination unit, and the scenario correction unit.

  According to the present invention, since the correction process for changing the reappearance scenario is performed, the feeling of boredom of the customer can be reduced and the satisfaction of the dialogue can be improved.

The block diagram which shows the dialogue system provided with the dialogue control apparatus by embodiment of this invention. The block diagram which shows the internal structure of a scenario control part. The figure which represented typically the mode of the process from the operation of the handy terminal by the store staff to the selection of the scenario data together with the time series. The flowchart which shows the processing operation of the scenario control part by this embodiment. 5 is a flowchart showing a detailed processing operation in step S9 of FIG. The flowchart following FIG. 5A. The figure which summarized the processing operation of the flowchart of FIG. 5A and 5B. The figure which shows the example of a screen display of the operation terminal at the time of a store visit. The figure which shows the example of a screen display switched from FIG. The figure which shows the utterance example of a robot. The figure which shows the example of a screen display of the operation terminal before ordering after an order. The figure which shows the utterance example of a robot. The figure which shows the example of a screen display switched from FIG. The figure which shows the example of a screen display of the operating terminal during a meal. The figure which shows the utterance example of a robot. The block diagram which shows the dialogue system which arrange | positioned scenario DB separately from the operating terminal. The block diagram of the dialogue system which provided the scenario control part and the motion generation part in the robot.

  Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. In the drawings attached to the present specification, for the sake of illustration and ease of understanding, the scale, the vertical / horizontal dimension ratio, and the like are appropriately changed and exaggerated from those of the actual product.

  Furthermore, as used in this specification, the shape and geometric conditions and the degree thereof are specified. For example, terms such as “parallel”, “orthogonal”, “identical”, length and angle values, etc. Without being bound by meaning, it should be interpreted including the extent to which similar functions can be expected.

Hereinafter, embodiments of the present invention will be described in detail.
FIG. 1 is a block diagram showing a dialogue system 1 including a dialogue control apparatus 10 according to an embodiment of the present invention. The dialogue system 1 in FIG. 1 includes a robot 2, an operation terminal 3 which is an example of the dialogue control device 10, a handy terminal 4, and a store system 5 such as a POS (Point of Sales) system. The dialogue system 1 in FIG. 1 is a system in which, for example, a customer (hereinafter referred to as a user) visiting a restaurant interacts with the robot 2 using the operation terminal 3 that operates the robot 2.

(Robot 2)
The robot 2 in FIG. 1 may be a device having a human-like appearance and dialogue function, that is, a humanoid. Alternatively, the robot 2 may be a device having a dissimilar appearance to a human such as an animal or a doll. The robot 2 may be a virtual image robot displayed on the display unit 35 or projected in an arbitrary space.

  The robot 2 in FIG. 1 includes a robot drive unit 21 and a robot control unit 22. The robot 2 may be driven by electric power supplied from a commercial power supply, or may be driven by a battery such as a battery.

  The robot drive unit 21 includes a voice output unit that outputs the speech voice of the robot 2. By driving the robot drive unit 21 as necessary, the robot 2 can speak to perform a dialogue with the user. A drive control signal for controlling the drive of the robot drive unit 21 is input from the robot control unit 22 to the robot drive unit 21. The robot drive unit 21 is driven according to the drive control signal. In addition, the robot drive unit 21 may include an actuator that drives a part of the robot 2, a lighting control unit that turns on / off the eyeball unit of the robot 2, and the like.

  The robot control unit 22 receives a robot control command, which is an example of a command signal, from the operation terminal 3. The robot control unit 22 generates the above-described drive control signal based on the received robot control command, and outputs the generated drive control signal to the robot drive unit 21. That is, the robot 2 can operate according to the robot control command. Note that the command for causing the robot 2 to speak includes data indicating the content of the utterance (scenario data described later).

  The robot control unit 22 includes, for example, at least one memory that stores software such as an application program and an operating system that operates the application program, and a CPU (Central Processing Unit) that executes the software stored in the memory. The drive control signal may be generated by the CPU executing software stored in the memory.

(Operation terminal 3)
The operation terminal 3 is carried by the user and is, for example, a tablet terminal having a touch function. In addition, the operation terminal 3 may be a smartphone, a desktop display type terminal, or the like. As illustrated in FIG. 1, the operation terminal 3 includes an orientation sensor 31 and an operation generation unit 32 that are examples of sensors. The operation terminal 3 is supplied with power from the built-in battery and is portable.

  The orientation sensor 31 outputs an orientation detection signal indicating the orientation of the operation terminal 3 to the motion generation unit 32. The direction sensor 31 outputs a direction detection signal indicating the detected direction of the operation terminal 3 to the motion generation unit 32. For example, the motion generation unit 32 generates a robot control command for controlling the posture of the robot 2 so as to face the direction in which the operation terminal 3 exists based on the direction detection signal from the direction sensor 31.

  The motion generation unit 32 generates a robot control command for controlling the motion of the robot 2 based on the output of the direction sensor 31. The motion generation unit 32 transmits the generated robot control command to the robot control unit 22 via wireless communication such as Wi-Fi, for example. The robot control unit 22 receives the robot control command from the motion generation unit 32, and outputs a drive control signal corresponding to the received robot control command to the robot drive unit 21, thereby controlling the operation of the robot 2. Do.

  The operation of the robot 2 includes an interactive operation in which a conversation with the user is performed using voice. As a configuration for performing a dialogue between the user and the robot 2, the operation terminal 3 includes a scenario DB (database) 33, a scenario control unit 34, and a display unit 35 in addition to the motion generation unit 32 described above. And an input unit 36 such as a touch panel, and an audio output unit 37.

  The scenario DB 33 stores a plurality of pieces of dialogue scenario information for carrying out a dialogue between the user and the robot 2. The dialogue scenario information includes a plurality of dialogue scenarios. The dialogue scenario is a story of dialogue exchanged between the user and the robot 2. A customer who enters a restaurant changes a plurality of staying states after entering the restaurant and before leaving the store. Therefore, a separate dialogue scenario is accumulated in the scenario DB 33 for each transition state. Further, when a customer selects a specific option from among a plurality of options while the dialog scenario executed in a certain stay state is in progress, there may be a case of switching to another dialog scenario. Each dialogue scenario is composed of robot-side scenario data that the robot 2 uses for dialogue (ie, utterance) and user-side scenario data that the user uses for dialogue (ie, selection on the operation terminal 3). The user-side scenario data is data that collects user-side options and the like for the utterances of the robot 2 in each dialogue scenario. The user-side scenario data is used for displaying options and the like on the display unit 35 of the operation terminal 3 in accordance with the progress of the conversation scenario. The user can select a specific option from the displayed options using the input unit 36.

  Then, different (lower) robot-side scenario data different from each other are associated with each of the dialogue scenario options shown in the user-side scenario data. That is, the dialogue scenario data has a tree structure in which the robot side scenario data and the user side scenario data are alternately coupled as nodes. In the tree structure, a predetermined series of nodes ranging from the highest level to the lowest level are managed as basic scenarios used for typical dialogue, for example, and the other node groups are managed as correction scenarios for correcting the basic scenarios. May be.

  For example, the dialogue scenario data for a restaurant may be divided into a plurality of scenario groups according to the staying state of the user at the restaurant. The stay state is a state determined based on status data output from the store system 5, for example. The status data in the present embodiment is information indicating that each action of sitting, ordering, food and drink provision, meal termination, and accounting has been performed. A state between the status data is called a stay state, and the dialogue scenario data is provided from a scenario group provided for each stay state.

  The scenario control unit 34 controls the scenario based on the data output from the store system 5. FIG. 2 is a block diagram showing the internal configuration of the scenario control unit 34. As shown in FIG. 2, the scenario control unit 34 includes a reception unit 341, a stay state determination unit 342, an information acquisition unit 343, a dialogue control unit 345, a return scenario determination unit 346, and a scenario correction unit 347. And have. Further, the scenario control unit 34 may include a recommended menu providing unit 344.

  The receiving unit 341 receives information including status data output from the store system 5. The status data can be input, for example, at the handy terminal 4 for ordering carried by the store staff of the restaurant. The status data is transmitted from the handy terminal 4 to the store system 5 and then transmitted from the store system 5 to the receiving unit 341 of the scenario control unit 34. Further, the status data may be transmitted from the handy terminal 4 directly to the operation terminal 3 via the receiving unit 341 without passing through the store system 5.

  Examples of status data include, in addition to order information indicating that the user has ordered food and drink, the first state indicating that the user has entered the store, the second state indicating that the user has been seated, and the ordered food and drink. There is a third state indicating that the user has been provided to the user, a fourth state indicating that the user has finished eating and drinking food and drink. The status data is not limited to this, and the status data may include a leaving state indicating that the user has left the seat, a conversation state in which the users are having a conversation, or a state in which the user has ordered dessert after eating. Good. Thus, the status data is information indicating the staying state of the user that changes with the passage of time.

  The stay state determination unit 342 determines the stay state of the user based on the status data among the information received by the reception unit 341. When the stay state determination unit 342 receives a second state signal indicating that the user has been seated, for example, via the reception unit 341, the stay state determination unit 342 determines that the user is in the stay state before ordering after sitting. When the order information is received via the reception unit 341, the stay state determination unit 342 determines that the user is in a stay state waiting for food and drink after the order is placed. Similar to the above-described status data, the staying state is information indicating the state of the user that changes over time.

  The store staff may input status data representing the staying state of the user into the handy terminal 4, for example, and the staying state determination unit 342 may determine the staying state using this input information. In this case, the store staff may input an action such as the user seated or ordered to the handy terminal 4, or directly the state of sitting or ordering and waiting for food or drink. You may enter. In the latter case, the stay state determination unit 342 determines that the received status data itself is the stay state.

  The information acquisition unit 343 acquires dialogue scenario information corresponding to the stay state determined by the stay state determination unit 342 from the scenario DB 33. The dialogue scenario information refers to information on a scenario group that changes depending on the stay state, or individual scenario data included in the scenario group. There may be no scenario group, and the dialogue scenario information may be composed of data of a plurality of dialogue scenarios.

  The scenario group is a bundle of scenario data suitable for the staying state of the user, and includes various scenario data according to the staying state. For example, if the user's staying state is the state before ordering, the scenario group includes scenario data that presents a menu according to each time, and the scenario that the content of the conversation changes depending on the number of adults and children. Data and other scenario data according to various situations are included. Further, a plurality of dialogue scenario data that can be selected according to the operation of the operation terminal 3 may be provided even in the same staying state.

  The information acquisition unit 343 may acquire scenario data for dialogue according to the staying state of the user, or after the scenario information is acquired by the information acquisition unit 343, scenario data to be used for dialogue from the scenario group. You may make it select and output. The information acquisition unit 343 or the dialogue control unit 345 may select the scenario data used for the dialogue from the scenario group.

  Although not an essential component, the recommended menu providing unit 344 transmits recommended menu information related to the recommended menu to the information acquisition unit 343 when there is a recommended menu in the menu. The information acquisition unit 343 acquires dialogue scenario information related to the recommended menu from the scenario DB 33.

  For example, the recommended menu providing unit 344 may output the recommended menu based on the dialogue scenario information regarding the recommended menu acquired by the information acquiring unit 343 when the user is in the stay state before ordering after sitting. .

  As another method, the information acquisition unit 343 checks the recommended menu providing unit 344 for the presence or absence of a recommended menu when acquiring the dialogue scenario information. If there is a recommended menu, scenario data for recommending the recommended menu is acquired from the scenario DB 33. Then, the acquired scenario data is output to the dialogue control unit 345. When there are a plurality of recommended menus, the plurality of recommended menus may be transmitted to the information acquisition unit 343, and information that there is another recommended menu in addition to the first recommended menu is also acquired by the information acquisition unit 343. You may send to.

  The dialogue control unit 345 performs control to advance the dialogue scenario with the customer according to the dialogue scenario information acquired by the information acquisition unit 343. If necessary, the dialogue control unit 345 may output data used for the dialogue to the display unit 35 of the operation terminal 3. The data used for the dialogue is basically information on the user side scenario data used for responding to the robot side scenario data.

  The dialogue control unit 345 supplies the dialogue scenario information acquired according to the staying status of the user to the operation generation unit 32. The motion generation unit 32 generates a voice from the robot 2 by transmitting a signal obtained by converting the dialogue data into a voice to the robot control unit 22. At this time, it is also possible to send a signal for opening / closing or lighting the mouth of the robot 2 to the robot control unit 22 to open / close or light the robot 2. Further, instead of appropriately transmitting the voice data from the operation terminal 3 to the robot control unit 22 as described above, the voice data is stored in the robot 2 and an identification signal associated with each voice data is transmitted. Thus, the robot 2 may be uttered. The voice output from the robot 2 may be an utterance that includes a meaningful word, or may be an artificial sound that does not include a word.

  Note that the data output by the dialogue control unit 345 is not limited to the user-side scenario data, and when the user selects a menu, an image or video of food or drink may be output to the display unit 35. . That is, not only information about words and characters used for dialogue, but also data that can be used for display, such as images and moving images, may be output to the display unit 35 as appropriate.

  In addition, the present invention is not limited to this, and sound may be output from the operation terminal 3 or the operation terminal 3 may be vibrated as necessary. In this case, the sound data, vibration data, and the like are output. You may do it. Further, when the robot 2 utters a sound, the sound uttered by the robot 2 may be output to the display unit 35 as characters. On the other hand, the user makes an arbitrary selection at the input unit 36 from the options displayed on the display unit 35 based on the user-side scenario data displayed on the display unit 35.

  Then, the dialogue control unit 345 outputs the robot side scenario data for responding to the data selected by the user to the display unit 35 and the motion generation unit 32. At this time, the user's selection may be output as audio information from the operation terminal 3 via the audio output unit 37.

  When the recommended menu is displayed on the display unit 35 and there are a plurality of recommended menus, the dialogue control unit 345 is based on a user input indicating that another recommended menu is to be presented from the input unit 36. A signal may be output to the information acquisition unit 343 so as to present a different recommended menu.

  As described above, the scenario control unit 34 acquires suitable data from the various scenario data stored in the scenario DB 33 based on the staying state of the user input to the handy terminal 4 by the store staff, and the motion generation unit 32. And output to the display unit 35. Further, the scenario control unit 34 reads out new robot-side scenario data that responds to the dialogue scenario selected by the dialogue scenario selection signal from the scenario DB 33 in accordance with the dialogue scenario selection signal input from the input unit 36.

  Then, the scenario control unit 34 outputs the read new robot side scenario data to the motion generation unit 32 for speech. By repeating this process, it is possible to perform a dialogue between the user and the robot 2.

  The re-appearance scenario determination unit 346 in the scenario control unit 34 determines whether or not the dialog scenario to be advanced is a re-appearance scenario having the same contents as the dialog scenario that has been executed while the user stayed at the restaurant. For example, when the user and the robot 2 have a dialogue regarding menu selection, the same dialogue scenario may be repeatedly executed depending on the user's selection on the operation terminal 3. In this case, the user must repeat the same dialogue as the dialogue scenario progresses, which is tedious and may impair the sense of dialogue. Therefore, the re-appearance scenario determination unit 346 determines whether or not the interaction scenario scheduled to proceed from now on is an already-executed reappearance scenario.

  When the scenario correction unit 347 in the scenario control unit 34 determines that the scenario is not a restart scenario by the restart scenario determination unit 346, the scenario correction unit 347 advances the conversation scenario to be advanced and determines that the scenario is a restart scenario. Correct the reoccurrence scenario. As described above, if the progress of the recall scenario is started as it is, there is a possibility that the user may get bored. Therefore, the progress is started after correcting the recall scenario. As will be described later, it is desirable to correct the reappearance scenario according to the staying state in the user's restaurant.

  The scenario correction unit 347 may change the utterance content uttered before the start of the re-appearance scenario according to the staying state of the user. That is, the robot 2 may be uttered according to the staying state of the user before starting the repeat scenario. Accordingly, it is possible to notify the user in advance that the reoccurrence scenario will start.

  Moreover, the scenario correction | amendment part 347 may change at least one part of the content of the reappearance scenario according to a user's stay state. Depending on the staying state, the return scenario may be allowed to proceed as it is, or may be summarized and shortened. Therefore, the scenario correction unit 347 determines at least a part of the contents of the return scenario according to the stay state of the user. By changing, the user's feeling of boredom can be reduced while continuing the dialogue with the user.

  More specifically, the scenario correction unit 347 notifies the progress start of the reappearance scenario before starting the progress of the reappearance scenario when the user starts the reappearance scenario before finishing the order of food and drink. The robot 2 may be made to speak.

  In addition, the scenario correction unit 347 determines whether or not to start the progress of the reappearance scenario when starting the progress of the reappearance scenario while waiting for the user to finish the order and receive the ordered product. The robot 2 may be uttered to make an inquiry to the user, and then the progress of the reappearance scenario may be started when the customer gives an instruction to start the reappearance scenario.

  Moreover, the scenario correction | amendment part 347 may start the progress of the summary scenario which summarized the reappearance scenario, when starting the progress of the reappearance scenario while the user is eating.

  With the above configuration, a dialogue between the user and the robot 2 can be performed using the dialogue scenario data.

(Stay status)
FIG. 3 is a diagram schematically showing the processing from the operation of the handy terminal 4 by the store staff to the selection of the scenario data together with the time series. In FIG. 3, solid arrows indicate data and signal input / output, and broken arrows indicate the passage of time. As described above and shown in FIG. 3, the process up to the scenario data selection is executed by the store system 5, the scenario DB 33, and the scenario control unit 34.

  The status data and the transition of the scenario group will be described with reference to FIG. First, status data (first information) that the user has entered the store or status data (second information) that the user has been seated is input to the handy terminal 4 by the operation of the store staff. When the status data is transmitted to the scenario control unit 34 via the store system 5, the stay state determination unit 342 indicates that the current stay state of the user is after the user enters or sits in the restaurant. It is determined that the stay state P1 is a state until an order is placed. And the information acquisition part 343 acquires the scenario data which belongs to the scenario group 1 according to this stay state P1 from scenario DB33, and interacts with a user. When the store staff inputs status data, the handy terminal 4 may transmit, for example, a table number or the like on which the user is seated as a key. By doing so, it is possible to associate the status data typed from the handy terminal 4 with the user.

  Next, as time elapses, the store staff transmits the user's order to the store system 5 via the handy terminal 4, that is, transmits status data indicating that the order has been placed. Then, the stay state determination unit 342 waits for the food and drink ordered by the user to be provided from the stay state P1 before the order, that is, the order is provided and the food and drink are provided. It is determined that the state has shifted to the waiting stay state P2. And the information acquisition part 343 acquires the scenario data which belongs to the scenario group 2 according to this stay state P2 from scenario DB33, and performs a dialog with a user.

  Similarly, when status data indicating that the user has provided food and drink is transmitted from the handy terminal 4 to the store system 5, the stay state determination unit 342 is in a state until the user completes the food and drink. It is determined that the state has shifted to the staying state P3 during eating and drinking. Then, the information acquisition unit 343 acquires scenario data belonging to the scenario group 3 and performs a dialogue. Thereafter, when status data indicating that the user's eating and drinking has been completed is transmitted from the handy terminal 4 to the store system 5, the stay state determination unit 342 is in a state from when the user completes eating and drinking until the user leaves the store. It is determined that the state has shifted to the stay state P4. Then, the information acquisition unit 343 acquires scenario data belonging to the scenario group 4 and performs a dialogue. As described above, as the store staff appropriately inputs the user status data as time passes, the staying state changes, and a dialog using the scenario data corresponding thereto is performed.

  The type of staying state is not limited to the above. As a staying state, for example, when dessert is ordered, the waiting state is waiting for the dessert to be served, and after the ordered dessert is served, the staying state is that the dessert is being eaten or eaten. It may be included. The scenario group is not limited to the above, and may include a scenario group according to the dessert standby state, a scenario group according to the dessert eating and drinking state, and the like. As another example, when an additional order is received, the user may return to the staying state P2.

  The input of status data is not limited to that input via the handy terminal 4. For example, when the user makes a checkout and leaves the store, status data indicating that the checkout has been made may be transmitted to the operation terminal 3 from the POS terminal (store system 5) at the time of checkout. The operation terminal 3 that has received the status data indicating that the transaction has been made may return the staying state to the initial state.

FIG. 4 is a flowchart showing the processing operation of the scenario control unit 34 according to the present embodiment. This flowchart is started when the user instructs a dialogue with the robot 2 on the operation terminal 3. While the user is interacting with the robot 2, the process of FIG. 4 is repeatedly performed.
First, the stay state determination unit 342 determines the stay state of the user (step S1). For example, as shown in FIG. 3, the state P1 from when the user enters the restaurant to the end of the order, the state P2 from the end of the order to the provision of food or drink, or the state P3 during eating Or whether it is in a state P4 from the end of eating and drinking until the accounting is completed.

  Next, the information acquisition unit 343 acquires a scenario group corresponding to the staying state of the customer (step S2). For example, as illustrated in FIG. 3, one of the scenario groups 1 to 4 is acquired according to any of the stay states P1 to P4.

  Next, the content selected by the user on the operation terminal 3 is acquired via the input unit 36 (step S3). Next, the information acquisition unit 343 acquires dialogue scenario information corresponding to the customer selection content acquired in step S3 from the scenario group acquired in step S2 (step S4). One scenario group includes a plurality of pieces of dialogue scenario information, and any one piece of dialogue scenario information is acquired by the information acquisition unit 343 according to the content selected by the user on the operation terminal 3. .

  Next, the dialogue control unit 345 starts the progression of the dialogue scenario based on the dialogue scenario information acquired in step S4 (step S5). In the progress of the conversation scenario, the user side performs operations such as button selection and swipe on the operation terminal 3, and the robot 2 side responds by utterance, thereby performing a dialogue between the user and the robot 2.

  Depending on the operation on the operation terminal 3 by the user, the dialogue scenario may be changed. Therefore, the dialogue control unit 345 determines whether or not the dialogue scenario has been changed when the user performs any operation on the operation terminal 3 (step S6). The outgoing scenario determination unit 346 determines whether or not the changed dialogue scenario is a repeated scenario (step S7).

  If it is determined that the scenario is a return scenario, the stay state determination unit 342 determines the stay state of the customer again (step S8), and the scenario correction unit 347 corrects the return scenario according to the stay state of the customer. (Step S9). The correction method for the reoccurrence scenario will be described later. By correcting the reappearance scenario, it is possible to prevent the user from getting bored or feeling bored.

  Next, the dialogue control unit 345 starts the progress of the corrected reappearance scenario (step S10). On the other hand, if it is determined in step S7 that the scenario is not a repeat scenario, the progress of the dialog scenario after the change is started (step S11).

  If it is determined in step S6 that the dialogue scenario has not been changed, the dialogue scenario continues to proceed (step S12).

  5A and 5B are flowcharts showing the detailed processing operation of step S9 of FIG. FIG. 6 summarizes the processing operations of the flowcharts of FIGS. 5A and 5B.

  5A and 5B is performed by the scenario correction unit 347. First, it is determined whether or not the user is in a state before ordering (step S21). If it is a state before an order, the process of the correction mode M1 is performed (steps S22 to S24). In the correction mode M1, first, an utterance expression before ordering is acquired (step S22). The utterance expression before ordering is, for example, “I spoke a while ago, but I will say it again”. The scenario correction unit 347 may acquire the utterance expression corresponding to the stay state of the user from the utterance expression storage unit by providing an utterance expression storage unit that stores such utterance expressions of each stay state. The utterance expression storage unit may be inside the operation terminal 3, or the utterance expression storage unit is provided in a cloud environment or a server, and the scenario correction unit 347 enters the user's stay state via the communication line. A corresponding utterance expression may be acquired.

  Next, the robot 2 is made to utter the acquired utterance expression (step S23). Reducing the user's boredom by informing the robot in advance that the already executed dialogue scenario will be repeated by letting the robot 2 utter the beginning of the reoccurrence scenario before starting the reappearance scenario. can do. Next, the dialogue control unit 345 is instructed to start the re-appearance scenario (step S24).

  In this way, the reappearance scenario is allowed to proceed as it is before the user orders. Even if this is an already executed dialogue scenario, it is better to explain the menu etc. in detail to the user when the user has not placed an order, and the user rarely asks for a detailed explanation. Because it is not, execute it again without changing the reappearance scenario. However, the robot 2 is uttered with the utterance expression described above in order to inform the user in advance that it has been executed, thereby reducing the user's boredom.

  If it is determined that it is not before ordering in step S21, it is determined whether or not it is before provision of food and drink after ordering, that is, before ordering of ordered items (step S25). If it is determined that the order is not before delivery, processing in the correction mode M2 is performed (steps S26 to S30). In the correction mode M2, first, an utterance expression before ordering after ordering is acquired from the utterance expression storage unit described above (step S26), and the robot 2 is uttered (step S27). The utterance expression in this case is, for example, “I spoke a while ago but want to hear it again”. On the other hand, when the user selects one of the buttons “I want to hear” or “I quit after all” on the operation terminal 3, whether or not to start the progress of the re-appearance scenario according to the button selection content. Is determined (step S28). More specifically, when the user selects “I want to hear”, the dialogue control unit 345 is instructed to start the re-appearance scenario (step S29). On the other hand, when the user selects “quit after all”, the progress of the repeat scenario is stopped (step S30). In this case, the process proceeds to step S12 in FIG. 4 and the progress of the original dialogue scenario is continued.

  In this way, when a re-appearance scenario appears before distribution after order placement, the reason for inquiring the user whether or not to proceed with the re-appearance scenario is that the order has already been completed and the re-appearance is unconditional. Since re-execution of a scenario is not necessarily considered to be for the user, it is left to the user's will.

  If it is determined in step 25 that the order is not before serving, it is determined whether the user is eating (step S31). If it is determined that a meal is in progress, the correction mode M3 is processed (steps S32 to S35). In the correction mode M3, first, an utterance expression during a meal is acquired from the utterance expression storage unit described above (step S32). The utterance expression in this case is, for example, “Since I spoke a while ago, I ’ll say it easily”. Next, the robot 2 is made to utter the acquired utterance expression (step S33). Next, a summary process of the reoccurrence scenario is performed (step S34). In this summarization process, for example, a process of simplifying the story of the re-appearance scenario is performed. More specifically, processing such as shortening at least a part of utterance expressions included in the repeat scenario is performed. Next, the start of progress of the summarized re-occurrence scenario is instructed (step S35).

  In this way, when a reappearance scenario appears during a meal, the reason for summarizing the reappearance scenario is to have you enjoy the meal as much as possible during the meal, and shorten the re-execution period of the reappearance scenario To do.

  If it is determined in step S30 that the meal is not being eaten, it is determined that the state is after the meal, and the post-meal utterance expression is acquired from the utterance expression storage unit described above (step S36). The utterance expression in this case is, for example, “I spoke a while ago but want to hear it again”. As described above, after the meal is finished, basically the same processing is performed as after ordering and before serving (steps S36 to S40).

  In the examples of FIGS. 5A, 5B, and 6, four correction modes M1 to M4 are provided as corrections for the reoccurrence scenario. The correction mode M1 is before ordering, the correction mode M2 is before ordering, and the correction mode M3 is meal. In the middle, the correction mode M4 is associated after a meal, but the number of correction modes is not necessarily limited to four.

  In FIGS. 5A, 5B, and 6, the correction contents in the correction modes M2 and M4 are the same, but they may be different from each other. For example, since the correction mode M4 is performed after the end of the meal, the resume scenario summarization process may be performed in order to prompt the user to perform an early accounting process.

  Next, a specific example of the dialogue between the user who operates the operation terminal 3 and the robot 2 will be described. When a user who has visited a restaurant is seated, a screen as shown in FIG. This screen is for explaining the menu to the user. In the example of FIG. 7, a button B1 for selecting a main dish, a button B2 for selecting a side menu, and a button B3 for selecting dessert are displayed on the same screen. Here, when the user touches and selects the button B1, the screen is switched to a screen as shown in FIG. On this screen, today's recommended menu is displayed together with photos and illustrations, and buttons B4 and B5 for selecting other recommended menus are also displayed. At the bottom of the screen, a "Select this menu" button B4, a button B5 to return to the previous screen, a button B6 to stop selecting the main dish, a button B7 to view the selected menu, and other menus A button B8 for viewing is displayed.

  7 and 8 are specific examples of the screen on the operation terminal 3, and the display form of the screen may be arbitrarily changed.

  When the user selects the main dish button B <b> 1 in FIG. 7, the corresponding dialogue scenario information is acquired by the information acquisition unit 343. The dialogue control unit 345 advances the dialogue scenario included in the obtained dialogue scenario information. More specifically, when the user selects an arbitrary button from the screen of FIG. 8, the robot 2 speaks according to the content selected by the user.

  In this way, the user and the robot 2 continue the dialogue according to the dialogue scenario, but the same dialogue scenario may be repeated depending on the selection contents of the user. In this case, the robot 2 utters, for example, as shown in FIG. 9 before the re-execution scenario is re-executed in accordance with the processing of FIGS. FIG. 9 shows an example before ordering, and is an example of the correction mode M1 in FIG. After speaking with a predetermined speech expression, the same dialogue scenario is repeated. The example of FIG. 9 shows an example of repeating the same utterance as before: “This menu uses fresh vegetables and Japanese beef, so it is delicious and nutritious!”

  FIG. 10 is a diagram showing a screen display example of the operation terminal 3 before ordering after ordering. FIG. 10 shows an example in which a button B11 of “Let's quiz!”, A button B12 of “Let's talk”, and a button B13 of “I ’m sorry” are displayed on the screen. In this case, when the user selects the button B11, a dialogue scenario related to a quiz is executed. However, if this dialogue scenario has been executed before, the robot 2 will be shown in FIG. As shown, utterances such as “I spoke a while ago but want to hear it again?” Are spoken. Further, the screen of the operation terminal 3 is switched to a screen as shown in FIG. FIG. 12 shows an example in which a button B14 for “I want to hear” and a button B15 for “I like it” are displayed on the screen. Here, when the user selects the button B14, as shown in FIG. 11, the robot 2 starts executing the re-appearance scenario having the same contents as before, and utters the same quiz problem as before.

  FIG. 13 is a diagram showing a screen display example of the operation terminal 3 during a meal. FIG. 13 shows the same example as FIG. Note that the screens during meals and before ordering are not necessarily the same.

  When the user selects the button B11 on the screen of FIG. 13, if the dialogue scenario related to the quiz has already been executed, the robot 2 utters “Since I told you, I ’ll say it easily,” as shown in FIG. Speak a summary of quiz issues.

  Although FIG. 1 shows an example in which the scenario DB 33 is provided in the operation terminal 3, the scenario DB 33 may be arranged separately from the operation terminal 3 as shown in FIG. For example, the operation terminal 3 may access the scenario DB 33 via the network 6 and acquire necessary dialogue scenario information. Scenario DB33 should just be arranged in the environment connected to network 6, for example, may be stored in a specific server, and may be stored in an unspecified server of a cloud environment.

  In FIG. 1, the example in which the scenario control unit 34 and the motion generation unit 32 are provided in the operation terminal 3 has been described. However, the scenario control unit 34 and the motion generation unit 32 may be provided in the robot 2. FIG. 16 is a block diagram of the dialogue system 1 in which the scenario control unit 34 and the motion generation unit 32 are provided in the robot 2. In this case, the dialogue control device 10 is provided in the robot 2, and the hardware performance of the robot 2 needs to be higher than that of the robot 2 in FIG. In the case of FIG. 16, the operation terminal 3 only needs to have an operation instruction function and a display function by the user, so that the internal configuration of the operation terminal 3 can be simplified.

  Further, as shown in FIG. 16, a voice recognition unit 23 may be provided in the robot 2. By providing the voice recognition unit 23, the robot 2 can analyze and interpret the content of the user's utterance so that the user can interact with the robot 2 without operating the operation terminal 3. become.

  In FIG. 16, the scenario DB 33 is provided inside the robot 2, but the scenario DB 33 may be provided inside the operation terminal 3, or the scenario DB 33 is provided outside the operation terminal 3 and the robot 2 as shown in FIG. 15. A DB 33 may be provided and accessed via the network 6.

  As described above, in this embodiment, when the user executes a recall scenario having the same content as the previously executed dialogue scenario with the robot 2, it is executed after correcting the recall scenario. , The user is not bored, the feeling of boredom can be reduced, and the satisfaction of the dialogue can be improved. When correcting the reappearance scenario, since the correction method is changed based on the staying state in the user's restaurant, an appropriate correction process considering the staying state of the user can be performed. The user's feeling of boredom can be reduced without impairing the feeling of interaction.

  In the above-described embodiment, an example is shown in which an interaction between a customer who visits a restaurant and the robot 2 is performed. However, even when a user interacts with the robot 2 for an arbitrary purpose in an arbitrary place other than the restaurant. Applicable.

  At least a part of the dialog control device 10 and the dialog system 1 described in the above-described embodiment may be configured by hardware or software. In the case of software, the program for realizing at least a part of the functions of the dialog control apparatus 10 and the dialog system 1 may be stored in a recording medium such as a flexible disk or a CD-ROM, and read and executed by a computer. Good. The recording medium is not limited to a removable medium such as a magnetic disk or an optical disk, but may be a fixed recording medium such as a hard disk device or a memory.

  Further, a program for realizing at least a part of the functions of the dialog control apparatus 10 and the dialog system 1 may be distributed via a communication line (including wireless communication) such as the Internet. Further, the program may be distributed in a state where the program is encrypted, modulated or compressed, and stored in a recording medium via a wired line such as the Internet or a wireless line.

  The aspect of the present invention is not limited to the individual embodiments described above, and includes various modifications that can be conceived by those skilled in the art, and the effects of the present invention are not limited to the contents described above. That is, various additions, modifications, and partial deletions can be made without departing from the concept and spirit of the present invention derived from the contents defined in the claims and equivalents thereof.

  DESCRIPTION OF SYMBOLS 1 Dialog system, 2 Robot, 3 Operation terminal, 4 Handy terminal, 5 Store system, 10 Dialogue control device, 21 Robot drive part, 22 Robot control part, 31 Direction sensor, 32 Motion generation part, 33 Scenario DB, 34 Scenario control Unit, 341 reception unit, 342 stay state determination unit, 343 information acquisition unit, 344 recommended menu provision unit, 345 dialogue control unit, 346 reappearance scenario determination unit, 347 scenario correction unit

Claims (11)

An information acquisition unit that acquires dialog scenario information for interacting with a customer who has visited a restaurant;
A dialog control unit that performs control to advance a dialog scenario with the customer according to the dialog scenario information;
A replay scenario determination unit that determines whether or not the dialog scenario to be progressed is a replay scenario having the same content as the conversation scenario executed while the customer stays at the restaurant;
Dialog control comprising: a scenario correction unit that advances the dialog scenario to be advanced when it is determined that the scenario is not the repeat scenario, and corrects the repeat scenario when the scenario is determined to be the restart scenario apparatus. A stay state determination unit for determining a stay state of the customer in the restaurant;
The dialogue control device according to claim 1, wherein the scenario correction unit corrects the re-occurrence scenario in consideration of the stay state of the customer.   The dialogue control apparatus according to claim 2, wherein the scenario correction unit changes the utterance content uttered before the progress of the reappearance scenario is started according to the stay state of the customer.   The dialogue control apparatus according to claim 2, wherein the scenario correction unit changes at least a part of the content of the re-occurrence scenario according to the stay state of the customer. The stay state of the customer determined by the stay state determination unit is:
A state from when the customer enters or sits in the restaurant to order food and drink;
Waiting for food and drink ordered by the customer to be provided;
The state until the customer completes eating and drinking of food and drink,
The dialogue control device according to any one of claims 2 to 4, including at least one of a state from when the customer completes eating and drinking of food and drink until the customer leaves the store.   When the scenario correction unit starts the progress of the return scenario before the customer finishes the order of food and drink, the utterance for notifying the start of the return scenario before starting the progress of the return scenario The dialogue control device according to any one of claims 1 to 5, wherein:   The scenario correction unit determines whether to start the progress of the return scenario when starting the progress of the return scenario when the customer finishes the order and waits for the order to arrive. The progress of the recall scenario is started when an instruction to start the recall scenario is issued from the customer thereafter. The dialog control device described.   The scenario correction unit starts the progress of a summary scenario summarizing the return scenario when the customer starts the return scenario while the customer is eating. The dialogue control device according to any one of the above.   9. The dialogue control unit according to claim 1, wherein the dialogue control unit advances a dialogue scenario between the robot that performs an operation according to a command signal in order to interact with the customer and the customer according to the dialogue scenario information. The dialog control device according to item. A robot that operates in response to a command signal to interact with a customer who has visited a restaurant;
An operation terminal for generating the command signal for operating the robot;
An information acquisition unit for acquiring dialog scenario information for interacting with the customer;
A dialog control unit that performs control to advance a dialog scenario with the customer according to the dialog scenario information;
A replay scenario determination unit that determines whether or not the conversation scenario to be advanced is a replay scenario that is a repetition of a previously executed conversation scenario;
A dialogue system comprising: a scenario correction unit that advances the dialogue scenario to be advanced when it is determined that the scenario is not the restart scenario, and corrects the restart scenario when the scenario is determined to be the restart scenario .   The dialogue system according to claim 10, wherein the operation terminal includes the information acquisition unit, the dialogue control unit, the repeat scenario determination unit, and the scenario correction unit.

Images