(57)【要約】【課題】顧客と適切な対話を行うことができる対話制御装置を提供する。【解決手段】対話制御装置は、飲食店に入店した顧客との対話を行う対話シナリオ情報であって、前記顧客の前記飲食店における滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う、対話制御部と、前記顧客との対話内容に基づいて、前記顧客の前記飲食店内における滞在状態を判断する、滞在状態判断部と、を備える。【選択図】図１
2018163504.tif 000002
【特許請求の範囲】
【請求項１】
飲食店に入店した顧客との対話を行う対話シナリオ情報であって、前記顧客の前記飲食店における滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、
前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う、対話制御部と、
前記顧客との対話内容に基づいて、前記顧客の前記飲食店内における滞在状態を判断する、滞在状態判断部と、
を備える対話制御装置。
【請求項２】
前記情報取得部は、前記滞在状態判断部が判断した前記顧客の滞在状態に基づいて、対話シナリオ情報を取得する、請求項１に記載の対話制御装置。
【請求項３】
前記滞在状態判断部が判断する前の前記顧客の滞在状態と、前記滞在状態判断部が判断した前記顧客の現在の滞在状態とが異なっている場合に、前記顧客の現在の滞在状態を、前記顧客の滞在状態として更新する、滞在状態更新部をさらに備え、
前記情報取得部は、前記滞在状態更新部が更新した前記顧客の滞在状態に基づいて、対話シナリオ情報を取得する、請求項１に記載の対話制御装置。
【請求項４】
前記滞在状態判断部が判断する前記顧客の滞在状態は、時間の経過により変化する状態である、請求項１乃至請求項３のいずれか１項に記載の対話制御装置。
【請求項５】
前記滞在状態判断部が判断する前記顧客の滞在状態は、
前記顧客が前記飲食店に入店、又は、着席してから飲食物を注文するまでの状態と、
前記顧客が注文した飲食物が提供されるのを待っている状態と、
前記顧客が飲食物の飲食を完了するまでの状態と、
前記顧客が飲食物の飲食を完了してから退店するまでの状態と、
のうち、少なくとも１つの状態を含む、請求項４に記載の対話制御装置。
【請求項６】
前記滞在状態判断部は、前記顧客との対話内容がメニューに関する情報から他の情報へと遷移した場合、前記顧客の滞在状態を、前記顧客が注文した飲食物が提供されるのを待っている状態であると判断する、請求項５に記載の対話制御装置。
【請求項７】
それぞれの異なる複数の対話シナリオ情報を蓄積するシナリオ蓄積部を備え、
前記情報取得部は、前記顧客の滞在状態に応じた対話シナリオ情報を、前記シナリオ蓄積部から取得する、請求項１乃至請求項６のいずれか１項に記載の対話制御装置。
【請求項８】
前記情報取得部は、前記顧客の滞在状態に応じた対話シナリオ情報を、通信ネットワークを介して取得する、請求項１乃至請求項６のいずれか１項に記載の対話制御装置。
【請求項９】
指示信号に応じた動作を行う、ロボットと、
前記ロボットが飲食店に入店した顧客との対話を行う対話シナリオ情報であって、前記顧客の前記飲食店における滞在状態に応じた対話シナリオ情報を取得する、情報取得手段と、
前記情報取得手段で取得された対話シナリオ情報に基づいて、前記ロボットが前記顧客との対話を行う指示信号を制御する、対話制御手段と、
前記顧客と前記ロボットとの対話内容に基づいて、前記顧客の前記飲食店内における滞在状態を判断する、滞在状態判断手段と、
を備える対話システム。
【請求項１０】
前記指示信号を生成して前記ロボットに送信する操作端末であって、前記情報取得手段及び前記対話制御手段を少なくとも備える、端末装置をさらに備え、
前記顧客と前記ロボットが前記操作端末を介して前記顧客の滞在状態に応じた対話をする、請求項９に記載の対話システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、対話制御装置及び対話システムに関する。
【背景技術】
【０００２】
近年、レストランその他公共施設において、来場客の案内役としてヒューマノイド型ロボットを活用する事例が見られる。このようなロボットとのコミュニケーション（対話）を専用の操作端末を用いて行う技術が検討されており、この技術によれば、ユーザは、操作端末を介してロボットとの対話を楽しんだり、案内情報を入手したりすることができる。
【０００３】
具体的には、テーブル席に設置されたロボットと、直接的あるいはタブレット等を介して間接的に対話を行うサービスが考えられる。この場合、お薦めメニューを提示したり、雑談をしたりすることにより顧客の満足度を向上させることができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−６６６２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、このようなサービスの提供をしても、対話が現在の状況、例えば、注文前である状況、注文後であり飲食物が提供前である状況、食事中である状況等に見合ったものでないと、対話がちぐはぐなものとなり、却って顧客の満足度を下げることにもなりかねない。
【０００６】
そこで、本発明は、顧客と適切な対話を行うことができる対話制御装置及び対話システムを提供するものである。
【課題を解決するための手段】
【０００７】
一実施形態に係る対話制御装置は、飲食店に入店した顧客との対話を行う対話シナリオ情報であって、前記顧客の前記飲食店における滞在状態に応じた対話シナリオ情報を取得する、情報取得部と、前記情報取得部で取得された対話シナリオ情報に基づいて、前記顧客との対話を行う、対話制御部と、前記顧客との対話内容に基づいて、前記顧客の前記飲食店内における滞在状態を判断する、滞在状態判断部と、を備える。
【０００８】
前記情報取得部は、前記滞在状態判断部が判断した前記顧客の滞在状態に基づいて、対話シナリオ情報を取得してもよい。
【０００９】
前記滞在状態判断部が判断する前の前記顧客の滞在状態と、前記滞在状態判断部が判断した前記顧客の現在の滞在状態とが異なっている場合に、前記顧客の現在の滞在状態を、前記顧客の滞在状態として更新する、滞在状態更新部をさらに備えていてもよく、前記情報取得部は、前記滞在状態更新部が更新した前記顧客の滞在状態に基づいて、対話シナリオ情報を取得してもよい。
【００１０】
前記滞在状態判断部が判断する前記顧客の滞在状態は、時間の経過により変化する状態であってもよい。
【００１１】
前記滞在状態判断部が判断する前記顧客の滞在状態は、前記顧客が前記飲食店に入店、又は、着席してから飲食物を注文するまでの状態と、前記顧客が注文した飲食物が提供されるのを待っている状態と、前記顧客が飲食物の飲食を完了するまでの状態と、前記顧客が飲食物の飲食を完了してから退店するまでの状態と、のうち、少なくとも１つの状態を含んでいてもよい。
【００１２】
前記滞在状態判断部は、前記顧客との対話内容がメニューに関する情報から他の情報へと遷移した場合、前記顧客の滞在状態を、前記顧客が注文した飲食物が提供されるのを待っている状態であると判断してもよい。
【００１３】
それぞれの異なる複数の対話シナリオ情報を蓄積するシナリオ蓄積部を備え、前記情報取得部は、前記顧客の滞在状態に応じた対話シナリオ情報を、前記シナリオ蓄積部から取得してもよい。
【００１４】
前記情報取得部は、前記顧客の滞在状態に応じた対話シナリオ情報を、通信ネットワークを介して取得してもよい。
【００１５】
一実施形態に係る対話システムは、指示信号に応じた動作を行う、ロボットと、前記ロボットが飲食店に入店した顧客との対話を行う対話シナリオ情報であって、前記顧客の前記飲食店における滞在状態に応じた対話シナリオ情報を取得する、情報取得手段と、前記情報取得手段で取得された対話シナリオ情報に基づいて、前記ロボットが前記顧客との対話を行う指示信号を制御する、対話制御手段と、前記顧客と前記ロボットとの対話内容に基づいて、前記顧客の前記飲食店内における滞在状態を判断する、滞在状態判断手段と、を備える。
【００１６】
前記指示信号を生成して前記ロボットに送信する操作端末であって、前記情報取得手段及び前記対話制御手段を少なくとも備える、端末装置をさらに備え、前記顧客と前記ロボットが前記操作端末を介して前記顧客の滞在状態に応じた対話をしてもよい。
【発明の効果】
【００１７】
本発明によれば、顧客と適切な対話を行うことができる。
【図面の簡単な説明】
【００１８】
【図１】一実施形態に係る対話システムの一例を示すブロック図。
【図２】一実施形態に係るシナリオ制御部の一例を示すブロック図。
【図３】一実施形態に係る対話制御におけるシナリオ制御の処理を示す図。
【図４】一実施形態に係る対話制御の処理の流れを示すフローチャート。
【図５】一実施形態に係る対話の一例を示す図。
【図６】一実施形態に係るメニュー提供の対話の一例を示す図。
【図７】一実施形態に係るメニュー選択時の対話の一理を示す図。
【図８】一実施形態に係る対話の一例を示す図。
【図９】一実施形態に係る注文確定の対話の一例を示す図。
【図１０】一実施形態に係るシナリオ制御部の別の例を示すブロック図。
【図１１】一実施形態に係る対話システムの別の例を示す図。
【図１２】一実施形態に係る対話システムのさらに別の例を示す図。
【図１３】一実施形態に係る対話システムのさらに別の例を示す図。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態に係る対話システムの構成及び作用について、図面を参照しながら詳細に説明する。なお、以下に示す実施形態は、本発明の実施形態の一例であって、本発明はこれらの実施形態に限定して解釈されるものではない。また、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号又は類似の符号を付し、その繰り返しの説明は省略する場合がある。また、図面の寸法比率は、説明の都合上実際の比率とは異なる場合や、構成の一部が図面から省略される場合がある。
【００２０】
図１は、本発明の実施形態による対話システム１を示すブロック図である。図１に示すように、対話システム１は、ロボット２と、ロボット制御装置の一例である操作端末３と、ハンディ端末４と、ＰＯＳ（Point Of Sales）システムなどの店舗管理装置５と、を備える。対話システム１は、例えば、飲食店の顧客（以下、ユーザと呼ぶ）が、ロボット２を操作する操作端末３を介してロボット２と対話をするためのシステムである。ハンディ端末４は、例えば、店舗スタッフが所持している注文端末であり、店舗スタッフは、ユーザから注文を受けた場合、ハンディ端末４を介して注文を店舗管理装置５へと送信する。
【００２１】
図１におけるロボット２は、人間に似た外観及び対話機能を有する機械、すなわちヒューマノイドである。なお、ロボット２は、動物やキャラクタなどの人間と非類似の外観を有していてもよい。また、ロボット２は、表示部３５に表示された画像による仮想的なロボットであってもよい。
【００２２】
（ロボット２）
図１に示すように、ロボット２は、ロボット駆動部２１と、駆動制御部の一例である、ロボット制御部２２と、を有する。ロボット２は、商用電源から供給される電力によって駆動するものであってもよいし、電池等のバッテリにより駆動するものであってもよい。
【００２３】
ロボット駆動部２１は、ロボット２の発話音声を出力する音声出力装置を備える。ロボット駆動部２１を必要に応じて駆動させることにより、ユーザとの対話を行うためにロボット２に発話させることができる。ロボット駆動部２１には、ロボット制御部２２から、ロボット駆動部２１の駆動を制御する駆動制御信号が入力される。ロボット駆動部２１は、駆動制御信号に応じて駆動される。なお、ロボット駆動部２１は、他に、自由度を有するロボット２の部位を駆動するアクチュエータや、ロボット２の眼球部を点灯させる点灯装置等を有していてもよい。
【００２４】
ロボット制御部２２は、指令信号の一例であるロボット制御コマンドを操作端末３から受信する。ロボット制御部２２は、受信したロボット制御コマンドに基づいて、上述の駆動制御信号を生成し、生成された駆動制御信号をロボット駆動部２１へと出力する。すなわち、ロボット２は、ロボット制御コマンドに応じて動作することができる。なお、ロボット２を発話させるためのコマンドには、発話内容を示すデータ（後述するシナリオデータ）が含まれる。
【００２５】
ロボット制御部２２は、例えば、アプリケーションプログラムやこれを動作させるオペレーティングシステムなどのソフトウェアが記憶された少なくとも１つのメモリと、メモリに記憶されたソフトウェアを実行するＣＰＵ（Central Processing Unit）とを有し、メモリに記憶されたソフトウェアをＣＰＵが実行することにより駆動制御信号を生成してもよい。
【００２６】
（操作端末３）
操作端末３は、ユーザが携帯する対話制御装置であり、例えば、タッチ機能を備えたタブレット端末である。この他、操作端末３は、スマートフォンや卓上のディスプレイ型の端末などでもよい。図１に示すように、操作端末３は、センサの一例である方位センサ３１と、指令信号生成部及び送信部の一例である動作生成部３２とを有する。操作端末３は、内蔵電池から供給される電力によって駆動される。
【００２７】
方位センサ３１は、操作端末３の方位を示す方位検出信号を動作生成部３２へと出力する。方位センサ３１は、検出された操作端末３の方位を示す方位検出信号を動作生成部３２へと出力し、動作生成部３２は、例えば、この方位検出信号に基づいて操作端末３が存在する方向を向くように、ロボット２の姿勢を制御するためのロボット制御コマンドを生成する。
【００２８】
動作生成部３２は、ロボット２の動作を制御するロボット制御コマンドを生成する。動作生成部３２は、生成されたロボット制御コマンドを、例えば、Ｗｉ−Ｆｉなどの無線通信を介してロボット制御部２２へと送信する。ロボット制御部２２は、動作生成部３２からのロボット制御コマンドを受信し、受信されたロボット制御コマンドに応じた駆動制御信号をロボット駆動部２１へと出力することにより、ロボット２の動作の制御を行う。
【００２９】
ロボット２の動作としては、音声を用いてユーザと会話を行う対話動作も含まれる。ユーザとロボット２との間での対話を行うための構成として、操作端末３は、上述の動作生成部３２に加え、さらに、シナリオＤＢ（データベース）３３と、シナリオ制御部３４と、表示部３５と、タッチパネル等の入力部３６と、音声出力部３７とを備える。
【００３０】
シナリオＤＢ３３は、シナリオ蓄積部であり、ユーザとロボット２との間での対話を行うための複数の異なる対話シナリオ情報が蓄積されている。対話シナリオ情報は、複数の対話シナリオを含んでいる。対話シナリオとは、ユーザとロボット２との間でやりとりされる対話のストーリである。飲食店に入店したユーザは、入店してから退店するまでの間に複数の滞在状態を遷移する。そこでシナリオＤＢ３３には、遷移状態ごとに別個の対話シナリオが蓄積されている。また、ある滞在状態にて実行された対話シナリオの進行中に、顧客が操作端末３で複数の選択肢の中から特定の選択肢を選択した場合には、別の対話シナリオに切り替わる場合もあり得る。各対話シナリオは、ロボット２が対話（すなわち、発話）に用いるロボット側シナリオデータと、ユーザが対話（すなわち、操作端末３での選択）に用いるユーザ側シナリオデータとで構成されている。ユーザ側シナリオデータは、各対話シナリオにおけるロボット２の発話に対するユーザ側の選択肢等を集めたデータである。ユーザ側シナリオデータは、対話シナリオの進行に合わせて、操作端末３の表示部３５に選択肢等を表示するために用いられる。ユーザは、表示された選択肢の中から特定の選択肢を入力部３６にて選択することができる。
【００３１】
そして、ユーザ側シナリオデータに示される対話シナリオの選択肢のそれぞれに、互いに異なる新たな（下位の）ロボット側シナリオデータとユーザ側シナリオデータが交互にノードとして結合されたツリー構造を有する。ツリー構造のうち、最上位から最下位にわたる所定の一連のノード群は、例えば、典型的な対話に用いられる基本シナリオとして管理され、多のノード群は、基本シナリオを補正する補正シナリオとして管理されていてもよい。
【００３２】
例えば、飲食店向けの対話シナリオデータは、飲食店におけるユーザの滞在情報を示すステータスデータに応じて複数のシナリオ群に区分されていてもよい。ステータスデータとは、ユーザの滞在状態が変更されるユーザの行為を含むデータのことであり、例えば、ハンディ端末４から店舗スタッフにより送信され、又は、対話内容に基づき対話制御部３４５から送信される情報である。図１の例におけるステータスデータは、着席、注文、飲食物提供、食事終了、及び、会計の各行為をしたことを示す情報である。対話シナリオデータはこれらのステータスデータにより区分されるシナリオ群の中から提供される。
【００３３】
シナリオ制御部３４は、ユーザの滞在状態に基づいてシナリオを制御する。図２は、操作端末３のシナリオ制御部３４の構成を示すブロック図である。この図２に示すように、シナリオ制御部３４は、受信部３４１と、滞在状態判断部３４２と、情報取得部３４３と、対話制御部３４５と、を備える。なお、この図２においては、図１に示される操作端末３内の方位センサ３１及び音声出力部３７は、簡単のため省略している。
【００３４】
操作端末３の受信部３４１は、例えば、店舗管理装置５から出力されたステータスデータを含む情報を受信する。ステータスデータは、例えば、飲食店の店舗スタッフが形態する注文用のハンディ端末４にて入力可能である。このステータスデータは、ハンディ端末４から店舗管理装置５に送信され、シナリオ制御部３４の受信部３４１へと送信される。また、ステータスデータは、店舗管理装置５を経由せずに、ハンディ端末４から直接受信部３４１を介して操作端末３へと送信されるようにしてもよい。
【００３５】
なお、本実施形態においては、対話の中から滞在状態を判断するので、ハンディ端末４から送信されたステータスデータは、予備的に滞在状態を判断するために使われるものであってもよい。また、初期状態、すなわち、ユーザが入店又は着席した状態の場合に、滞在状態を初期化するためにハンディ端末４から入店又は着席した情報をステータスデータとして送信してもよい。このように、予備的に、ハンディ端末４を介して入力されたステータスデータから滞在状態を判断することにより、対話の中で滞在状態の変更が判断されなかった場合にも、ハンディ端末４から強制的に滞在状態を変更することが可能となる。
【００３６】
例えば、店舗スタッフがユーザを座席に案内した時点において、ユーザから注文が入った場合、店舗スタッフがユーザの注文をハンディ端末４に入力したタイミングにおいて、滞在状態を注文後であり飲食物の提供待ちの状態へと設定することが可能となる。また、別の例としては、ユーザとロボット２が対話中に、ユーザが店舗スタッフに対して注文をし、店舗スタッフがハンディ端末４にメニューを入力した場合、このタイミングで、滞在状態が注文前の状態であったとしても、強制的に注文後であり飲食物の提供待ち状態へと遷移するようにしてもよい。このようにすることにより、対話中では滞在状態は変化していないが、ユーザの行動により滞在状態が変化した場合にも対応することが可能となる。このように店舗スタッフにより滞在状態が更新された場合には、当該滞在状態に応じたオペレーションを行っている場合があるので、オペレーション指示を出さないようにしてもよい。
【００３７】
滞在状態判断部３４２は、ロボット２とユーザとの間で行われた対話情報に基づいて、ユーザの滞在状態を判断する。また、ハンディ端末４からのステータスデータの入力を受け付ける場合には、予備的に、受信部３４１が受信したステータスデータに基づいてユーザの滞在状態を判断するようにしてもよい。この滞在状態は、時間の経過とともに変化するユーザの状態を示す状態である。
【００３８】
情報取得部３４３は、シナリオＤＢ３３から、滞在状態判断部３４２が判断した滞在状態に応じた対話シナリオ情報を取得する。対話シナリオ情報とは、滞在状態により変化するシナリオ群の情報、又は、当該シナリオ群に含まれる個々のシナリオデータ等のことを言う。シナリオ群が存在せず、複数の対話シナリオのデータで対話シナリオ情報が構成されていてもよい。
【００３９】
シナリオ群とは、ユーザの滞在状態に適したシナリオデータの束であり、滞在状態に併せた種々のシナリオデータを含む。例えば、ユーザの滞在状態が注文前の状態である場合、シナリオ群には、それぞれの時刻に併せたメニューを提示するシナリオデータや、大人、子どもの人数により対話の内容や、話し方が変化するシナリオデータ、その他様々なシチュエーションに応じたシナリオデータが含まれている。また、同一の滞在状態であっても、操作端末３の操作に応じて選択されうる複数の対話シナリオデータを設けていてもよい。
【００４０】
情報取得部３４３は、滞在状態判断部３４２が判断したユーザの滞在状態に応じて対話するシナリオデータを取得するようにしてもよいし、情報取得部３４３がシナリオ群を取得した上で、当該シナリオ群から対話に用いるシナリオデータを選択して出力するようにしてもよい。シナリオ群から対話に用いるシナリオデータを選択するのは、情報取得部３４３であってもよいし、対話制御部３４５であってもよい。
【００４１】
対話制御部３４５は、ユーザの滞在状況に応じて取得した対話に用いるシナリオデータを含む情報を動作生成部３２へと出力する。さらに、対話制御部３４５は、必要であれば、操作端末３の表示部３５へと対話に用いるデータを出力してもよい。対話に用いるデータは、基本的には、ロボット側シナリオデータに応答するために使用するユーザ側シナリオデータの情報である。
【００４２】
なお、対話制御部３４５が出力するデータは、ユーザ側シナリオデータには限られず、ユーザがメニューを選択する際には、飲食物の画像や動画を表示部３５へと出力するようにしてもよい。すなわち、対話に用いる言葉、文字に関する情報だけではなく、適宜、画像、動画等、表示に用いることのできるデータを表示部３５へと出力するようにしてもよい。
【００４３】
また、これには限られず、必要に応じて操作端末３から音声を出力させたり、操作端末３を振動させたりしてもよく、この場合には、これらの音声データ、振動データ等を出力するようにしてもよい。また、ロボット２が音声を発する場合には、ロボット２が発する音声を文字として表示部３５へと併せて出力するようにしてもよい。一方、ユーザは、表示部３５に表示されているユーザ側シナリオデータに基づき、表示部３５に表示された選択肢の中から、入力部３６にて任意の選択を行う。
【００４４】
そして、対話制御部３４５は、ユーザに選択されたデータに応答するためのロボット側シナリオデータを表示部３５、及び、動作生成部３２へと出力する。この際、ユーザの選択を、音声出力部３７を介して操作端末３から音声情報として出力するようにしてもよい。このように、対話制御部３４５により、ユーザとロボット２との対話が繰り返し行われる。以上の構成により、対話シナリオデータを用いてユーザとロボット２との間で対話を行うことができる。
【００４５】
（店舗管理装置）
店舗管理装置５は、店舗に存在するロボット２、操作端末３、ハンディ端末４、ＰＯＳ端末等その他の店舗内の装置類を総括して管理する装置である。
【００４６】
店舗管理装置５は、送信部を備え、店舗内にある各装置へと必要となる情報を送信する。必要となるデータとは、例えば、シナリオ制御部３４の滞在状態判断部３４２においてステータスデータから滞在状態を判断するステータスデータ等である。
【００４７】
また、店舗管理装置５は、受信部を備え、店舗内にある各装置から必要となる情報を受信する。必要となるデータとは、例えば、ハンディ端末４から送信されるステータスデータや、ＰＯＳ端末から送信される会計データ等である。さらに、これら送受信に用いるデータを格納しておくデータベースを店舗管理装置５内に備えていてもよい。
【００４８】
また、店舗管理装置５は、ユーザの滞在状態が変更された場合に、店舗スタッフへと変更された滞在状態に対応するオペレーションを指示するオペレーション指示部を備えていてもよい。店舗スタッフへのオペレーション指示は、ハンディ端末４に行うほか、店舗内の所定の位置にオペレーション指示を受ける表示板等を備えるようにし、当該表示板等に表示されるようにしてもよい。
【００４９】
さらに、店舗管理装置５は、その他の店舗に関する処理を行う。例えば、ハンディ端末４を介してユーザから注文を受けた場合、当該注文を厨房に伝えることにより、飲食物を調理するスタッフにユーザの注文を伝えることができる。さらに、ユーザからの注文情報をユーザと紐付けておくことにより、ユーザが退店する際にＰＯＳ端末において各ユーザの注文した飲食物に基づいて会計処理をすることも可能となる。
【００５０】
（滞在状態）
図３は、ロボット２とユーザとの対話から、シナリオデータの選択までの処理の様子を時系列と併せて模式的に表した図である。この図３において、実線の矢印は、データ及び信号の入出力、破線の矢印は、時間の経過を表す。上述した説明、及び、この図３に示されているように、シナリオデータ選択までの処理は、店舗管理装置５と、シナリオＤＢ３３と、シナリオ制御部３４により実行される。
【００５１】
この図３を用いて滞在状態とシナリオ群の推移について説明する。まず、店舗スタッフの操作によりハンディ端末４に、ユーザが入店したという第１情報、又は、ユーザが着席したという第２情報がステータスデータ（滞在情報）として入力される。このステータスデータは、店舗管理装置５を介して操作端末３へと送信される。滞在状態判断部３４２は、このステータスデータが入力されると、ユーザの滞在状態を初期化し、ユーザが飲食店に入店、又は、着席してから注文をするまでの状態である滞在状態Ｐ１であると判断する。滞在状態判断部３４２は、情報取得部３４３へユーザの滞在状態が、滞在状態Ｐ１であることを通知する。
【００５２】
情報取得部３４３は、この滞在状態Ｐ１に応じたシナリオ群１に属するシナリオデータをシナリオＤＢ３３から取得し、ユーザとの対話を行う。
【００５３】
滞在状態Ｐ１において時間が経過し、ユーザとロボット２との間の対話からユーザが注文したい飲食物が決まったと滞在状態判断部３４２により判断されると、滞在状態判断部３４２は、ユーザが注文する飲食物を決定してから注文するまでの滞在状態である、あるいは、ユーザが注文した飲食物が提供されるのを待っている状態であると判断する。情報取得部３４３は、シナリオＤＢ３３から当該滞在状態に適したシナリオ群に属するシナリオ情報に基づいて動作生成部３２を介して当該シナリオ情報に基づいた対話をロボット２に発話させるように制御する。
【００５４】
例えば、滞在状態は、この他に、ユーザが飲食物の飲食を完了する迄の状態、ユーザが飲食物の飲食を完了してから退店するまでの状態、ユーザが食後に会話を楽しんでいる状態、ユーザがデザートの注文をした状態等の状態を備えていてもよい。
【００５５】
上記のそれぞれの滞在状態に応じてシナリオ群が選択され、ユーザとロボット２との間の対話が為される。そして、変化した滞在状態に応じた対話シナリオの選択が情報取得部３４３により為される。
【００５６】
具体的には、ユーザが前記飲食店に入店、又は、着席してから注文する飲食物を決定するまでの滞在状態においては、シナリオ群１に属するシナリオデータが取得される。同じように、例えば、ユーザが注文する飲食物を決定してから注文するまでの滞在状態及びユーザが注文した飲食物が提供されるのを待っている滞在状態であれば、シナリオ群２から、ユーザが飲食物の飲食を完了するまでの滞在状態であれば、シナリオ群３から、ユーザが飲食物の飲食を完了してから退店するまでの滞在状態であれば、シナリオ群４からシナリオデータが取得される。
【００５７】
このように時間の経過により、ユーザの滞在状態は変化する。この滞在状態の変化は、ユーザとロボット２との対話に基づいて滞在状態判断部３４２が判断するか、あるいは、補助として、店舗スタッフの所持するハンディ端末４により強制的に変更される。また、滞在状態により、所定の時間が経過した場合には、次の滞在状態へと遷移するようにしてもよい。
【００５８】
なお、これらのシナリオ群と滞在状態との対応は、一例として示したものであり、他の滞在状態及びシナリオ群が追加されたり、また、上述した滞在状態を省略したり、結合したりしてもよい。
【００５９】
（動作例）
次に、上述した処理の流れについてフローチャートを用いて説明する。図４は、本実施形態に係る処理の流れを示すフローチャートである。
【００６０】
ユーザが来店し、着席すると、シナリオ制御部３４は、店舗スタッフの所持するハンディ端末４を介して、ユーザの滞在情報が、ユーザが入店、又は、着席したステータスデータを取得する処理、すなわち、滞在情報の初期値の取得処理を行う（ステップＳ１０）。例えば、ユーザが着席したタイミングで、店舗スタッフがハンディ端末４へ当該テーブルに対応する番号にユーザが着席した旨をステータスデータとして店舗管理装置５へと送信する。そして、店舗管理装置５から受信部３４１を介して滞在状態判断部３４２が当該ステータスデータを取得することにより行われる。
【００６１】
次に、滞在状態判断部３４２は、取得したステータスデータに基づいて、ユーザの滞在状態を判断する（ステップＳ１１）。例えば、ユーザが着席した旨のステータスデータを受信した場合、滞在状態判断部３４２は、得られた滞在状態Ｐ１を、情報取得部３４３へと出力する。
【００６２】
次に、滞在状態判断部３４２は、ユーザの滞在状態が変更されたか否かを判定する（ステップＳ１２）。例えば、未入店又は未着席の状態から滞在状態Ｐ１へと変更している場合、滞在状態判断部３４２は、新たな滞在状態へと遷移したと判定し（ステップＳ１２：ＹＥＳ）、シナリオ群の選択ステップへと移行する。
【００６３】
滞在状態が変更されたと判定した滞在状態判断部３４２は、滞在状態が変更された旨を情報取得部３４３へと通知する。滞在状態が変更された旨が通知された情報取得部３４３は、更新された滞在状態に対応するシナリオ群を選択する（ステップＳ１３）。例えば、滞在状態が、図３に示す滞在状態Ｐ１から滞在状態Ｐ２へと更新されたことが通知された場合、情報取得部３４３は、シナリオデータを取得するシナリオ群を、シナリオ群１からシナリオ群２へと変更する。
【００６４】
次に、情報取得部３４３は、選択したシナリオ群から対話シナリオを取得する（ステップＳ１４）。このように、情報取得部３４３は、滞在状態に基づき適切なシナリオ群に属するシナリオデータを取得する。
【００６５】
次に、情報取得部３４３は、取得したシナリオデータを対話制御部３４５へと送信し、対話制御部３４５は、受信したシナリオデータに基づいて対話動作を行い、ロボット２は、ユーザとの対話動作へと移行する（ステップＳ１５）。なお、滞在状態が変更されていなかった場合（ステップＳ１２：ＮＯ）は、シナリオ群の選択及びシナリオの取得を行うことなく対話動作が継続される。
【００６６】
次に、対話制御部３４５は、対話内容に基づいてステータスデータを取得する（ステップＳ１５）。ステータスデータは、例えば上述したように、ユーザが注文するメニューを決定した状態、ユーザへと飲食物が提供された状態、ユーザが飲食を完了した状態、ユーザが退店しようとしている状態等の状態を示すデータである。
【００６７】
次に、対話制御部３４５は、対話内容に基づいて対話を終了させるか否かを判定する（ステップＳ１６）。対話動作を終了させると判定した場合（ステップＳ１６：ＹＥＳ）、例えば、ユーザが対話を終わらせる旨の選択をした場合や、会計をする滞在状態となった場合、対話動作を終了する。一方、対話動作を終了させないと判定した場合（ステップＳ１６：ＮＯ）、ステップＳ１５において取得したステータスデータに基づき、ステップＳ１１からの動作を繰り返すことにより、対話を継続させる。
【００６８】
次に、対話の流れ及び滞在状態の判断について、図を用いてより具体的に説明する。
【００６９】
図５は、ユーザが着席した後のロボット２と操作端末３の対話の一例を示す図である。店舗スタッフにより、ハンディ端末４にユーザが座席に着席した旨が通知されると、当該ステータスデータは、店舗管理装置５及び受信部３４１を介して滞在状態判断部３４２へと通知される。滞在状態判断部３４２は、当該ステータスデータを受信すると、滞在状態の初期値として、ユーザが座席に着席した状態であると判断する。
【００７０】
滞在状態として初期値が設定されると、ロボット２は、ユーザにメニューを見せる対話動作を開始する。なお、この際、ロボット２、店舗管理装置５又は操作端末３が保持している時刻情報に合わせて挨拶をするようにしてもよい。例えば、朝の時刻であれば、ロボット２は、「おはよう！」等の挨拶をするようにしてもよい。又は、話し始める前にロボット２の自己紹介をするようにしてもよい。例えば、挨拶と続けて、「おはよう！ロボだよ！」等と発話するようにしてもよい。そして、図５に示すように、「何を注文する？」等と発話する。
【００７１】
操作端末３は、このタイミングに合わせて、通常のメニューを参照するか又はおすすめメニューを参照するかをユーザに選択させるようにしてもよい。例えば、ユーザがおすすめメニューを参照することを選択した場合、操作端末３の表示部３５の表示は、図６に示す表示となる。
【００７２】
図６は、図５において、「おすすめメニューを教えて！」がユーザにより選択された場合の表示部３５の表示例を示す図である。この図６に示すように、本日のおすすめメニューとして、「イタリア産チーズのハンバーグ」の文字が、画像や動画とともに表示される。それとともに、その他のおすすめメニューを併せて表示するようにしてもよい。
【００７３】
図７は、おすすめメニューを選択した場合の対話例を示す図である。まず、ロボット２は、ユーザが選択したことに対して、「おすすめメニューを選んでくれたんだ。ありがとう！」等のメッセージを発話する。そして、表示部３５には、その発話に対する回答として、「もちろん！」、「やっぱり替える」と言った選択肢が表示される。ここで、「もちろん！」がユーザにより選択されると、ロボット２は、例えば、「おすすめメニューは、・・・、グッドチョイスだよ！」と発話する。続いて、「店員さんを呼んで注文しよう！」等、ユーザに注文を促すようなメッセージを発話する。
【００７４】
このロボット２の発話と並行して、対話制御部３４５は、滞在状態判断部３４２へとユーザがメニューを決めたというステータスデータを通知する。このステータスデータが通知された滞在状態判断部３４２は、ユーザの滞在状態が、ユーザが注文する飲食物を決定してから注文するまでの滞在状態であると判断する。
【００７５】
滞在状態判断部３４２は、滞在状態が変更されたと判断すると、情報取得部３４３にシナリオ群を変更するように通知する。この判断は、情報取得部３４３が行ってもよく、滞在状態が通知された情報取得部３４３が、滞在状態が変更されたことを判断し、シナリオ群の選択をするようにしてもよい。
【００７６】
情報取得部３４３は、シナリオ群の選択を行った後、ユーザとロボット２との対話を行うためのシナリオデータを当該シナリオ群に属するシナリオデータの中から取得する。
【００７７】
図７は、滞在状態が、初期状態から、ユーザが注文を決めてから注文するまでの状態へと遷移したタイミングにおける対話例である。すなわち、情報取得部３４３が初期状態とは異なる状態におけるシナリオ群からシナリオデータを取得している例である。このタイミングにおいては、ユーザが注文を完了しているか否かが不明である。そのため、例えば、ロボット２は、「まだ他のメニューも見る？」等、ユーザが注文を完了しているか否かが判断できるような質問をするようにしてもよい。
【００７８】
この状態において、「まだ見たいな」の選択肢をユーザが選択した場合、対話制御部３４５は、ユーザがメニューをまだ閲覧する、というステータスデータを発行し、滞在状態判断部３４２は、ユーザの滞在状態に変更がないと判断する。ユーザの滞在状態に変更がないため、情報取得部３４３は、シナリオデータを取得せずに対話を継続させるようにするか、又は、現状のシナリオ群に属するシナリオデータを取得することにより対話を継続する。なお、このような滞在状態が変化しない選択肢については、ステータスデータを発行しないようにしてもよい。すなわち、ユーザ側シナリオデータにおいて、ステータスデータを発行しない選択肢、例えば、「まだ見たいな」と言った選択肢が設定されていてもよい。別の方法としては、このような選択肢の場合には、ステータスデータを滞在状態判断部３４２へと送信しないようにしてもよい。
【００７９】
一方、「もう見ないよ」の選択肢をユーザが選択した場合、対話制御部３４５は、ユーザが注文を確定した、又は、ユーザが注文を完了したというステータスデータを発行し、滞在状態判断部３４２は、ユーザの滞在状態が更新されたと判断する。情報取得部３４３は、更新された滞在状態に基づいたシナリオ群から新たなシナリオデータを取得し、ロボット２は、情報取得部３４３が取得したシナリオデータに基づいて対話を行う。
【００８０】
例えば、滞在状態が、ユーザが注文を完了した後、飲食物が提供されるのを待っている状態である場合、「じゃあ、食べ物が来るまで、お話ししよう！」、「それとも何かゲームをする？」等、飲食物の提供を待っている状態に適した対話が行われるようになる。
【００８１】
なお、滞在状態の変更がどこで判断されるかは、上記のものには限られない。すなわち、対話制御部３４５がステータスデータ又は滞在状態を記憶しておき、対話において現在のステータスデータとは異なるステータスデータを取得した場合、あるいは、現在の滞在状態から異なる滞在状態へと移行させるステータスデータを取得した場合に滞在状態判断部３４２へとステータスデータを送信するようにしてもよい。
【００８２】
別の例としては、滞在状態判断部３４２において滞在状態を記憶するようにしておき、対話制御部３４５は、対話において変化するステータスデータ又は対話内容を逐次、滞在状態判断部３４２へと通知し、対話制御部３４５から通知されたステータスデータ又は対話内容により現在の滞在状態と異なる滞在状態へと移行する場合に、店舗管理装置５へと更新された滞在状態を送信するようにしてもよい。
【００８３】
さらに別の例としては、情報取得部３４３において滞在状態を記憶するようにしておき、滞在状態判断部３４２から送信される滞在状態が変更された場合に、シナリオデータを取得するシナリオ群を変更するようにしてもよい。
【００８４】
さらに別の例としては、滞在状態を格納する、滞在状態格納部（図示しない）を備えていてもよい。滞在状態判断部３４２は、所定の時間ごと、例えば、３０秒ごとや１分ごとに滞在状態格納部の滞在状態を更新する。そして、情報取得部３４３は、所定の時間ごと、例えば３０秒ごとや１分ごとに滞在状態格納部の滞在状態を参照し、滞在状態が異なる滞在状態へと更新された場合に、シナリオデータを取得するシナリオ群を変更するようにしてもよい。なお、所定の時間は、３０秒や１分に限られるものではなく、さらに短い時間間隔であっても又はさらに長い時間間隔であってもよい。
【００８５】
滞在状態の確認方法は、上述したものには限られず、対話制御部３４５が通知するステータスデータ、又は、滞在状態判断部３４２が判断する滞在状態により適切にシナリオ群が選択できるものであればどのような形態であってもよい。
【００８６】
上記の例は、対話中において注文が決まったことがユーザから明示的に示されず、ユーザの選択から予測して判断する場合であるが、注文が決まったことをユーザが明示的に選択するようにしてもよい。図９は、ユーザが明示的にステータスデータを更新することを選択させる例を示す図である。
【００８７】
例えば、ユーザが注文したいメニューとして所定数の飲食物を選択した後、ロボット２は、「注文はきまった？」と発話するようにする。そして、表示部３５には、「決まった！」、「まだ考え中」と言った選択肢が表示される。ここで、「決まった！」がユーザにより選択されると、対話制御部３４５は、メニューが確定した旨のステータスデータを滞在状態判断部３４２へと通知する。ステータスデータの通知を受けた滞在状態判断部３４２は、ステータスデータに対応する滞在状態を判断し、情報取得部３４３へと送信する。滞在状態を受信した情報取得部３４３は、シナリオデータを取得するシナリオ群を変更する。例えば、注文中である滞在状態に対応したシナリオ群から、飲食物提供待ちである滞在状態に対応したシナリオ群へと変更し、新たなシナリオデータに基づき、ロボット２に「じゃあ、店員さんを呼んで、注文してからお話ししよう！」という発話をさせた後、ロボット２とユーザとの対話を行うように制御する。
【００８８】
上記に示したように、対話している間にユーザにより、明示的又は明示的ではなくステータスデータが更新される。このステータスデータの変更は、シナリオデータに含まれるようにしてもよい。すなわち、シナリオＤＢ３３に格納されているシナリオデータは、ユーザが選ぶ選択肢と紐付けられたステータスデータを内部的に保持し、対話制御部３４５によりそのステータスデータを参照できるようにしておいてもよい。別の例としては、各選択肢に所定のステータスデータに対する点数を割り振っておきをしておき、当該ステータスデータに対する点数の累積値がしきい値を超えた場合に、対話制御部３４５がステータスデータを発行するようにしてもよい。
【００８９】
なお、上記においては、注文前後のシナリオ群に関する対話例について説明したが、これには限られず各滞在状態又はステータスデータに基づいたシナリオ群の選択が為される。
【００９０】
例えば、飲食物が提供された後、ユーザとロボット２との対話がされないような状態へと移行してもよい。この場合、シナリオデータとしては、無言のシナリオを設定するようにしてもよい。そして、操作端末３が操作されたタイミングにおいて、ユーザが飲食を終えて対話モードになったというステータスデータを通知するようにしてもよい。別の例として、飲食中には操作端末３を介して明示的に飲食が完了したというステータスデータが通知されるまでは、対話をしないようにしてもよい。
【００９１】
この他の滞在状態についても、同様である。
【００９２】
ユーザが着席したステータスデータが入力されてから、所定の時間、対話制御部３４５からステータスデータの通知が無い場合、注文が決まったか否かを確認するようなシナリオデータを準備しておき、当該シナリオデータを用いてユーザとロボット２とが対話をするようにしてもよい。
【００９３】
飲食中の滞在状態において、操作端末３を介してユーザがメニューを参照し始めた場合、追加の注文があると予測し、追加の注文がある場合に対応するシナリオ群を選択し、シナリオデータを取得するようにしてもよい。
【００９４】
飲食が完了した滞在状態においては、対話やゲームをしてもよいし、又は、適当なタイミングにおいて追加の注文があるか否かを選択させるようなシナリオデータを取得するようにしてもよい。
【００９５】
なお、滞在状態やその滞在状態に対応するシナリオ群の選択及びシナリオデータの取得は、ユーザの満足度を向上するものであれば上述したものには限られない。
【００９６】
上述したように、滞在状態ごとに対応するシナリオ群が存在し、各シナリオ群には複数の対話シナリオ情報があり、ユーザとロボット２は互いに対話を行うことで、１つの対話シナリオ情報の対話を進行させる。さらに、ユーザの選択内容等によっては、１つの対話シナリオ情報から他の対話シナリオ情報の対話シナリオに切り替わることがあってもよい。
【００９７】
以上のように、本実施形態によれば、ユーザとロボット２との間の対話の状態によりステータスデータを発行し、発行されたステータスデータにより滞在状態を判断し、判断された滞在状態に基づいてシナリオ群を選択してシナリオデータを取得することにより、ユーザは、様々な滞在状態に対応した適切な対話をロボット２との間で行うことができ、ユーザの満足度を向上することが可能となる。
【００９８】
以下、変形例について説明する。なお、以下に説明する各変形例についても、基本的な動作は同様である。
【００９９】
（第１変形例）
前述した実施形態においては、滞在状態判断部３４２が操作端末３のシナリオ制御部３４内に備えられているとしたが、これには限られない。例えば、店舗管理装置５が滞在状態判断部３４２を備えるようにしてもよい。図１０は、本変形例に係る操作端末３及び店舗管理装置５の構成を示すブロック図である。
【０１００】
店舗管理装置５は、送信部５１と、滞在状態判断部３４２とを備える。このように、滞在状態判断部３４２が店舗管理装置５に備えられている場合、ユーザとロボット２との対話におけるステータスデータ又は対話内容は、対話制御部３４５から店舗管理装置５の滞在状態判断部３４２へと送信される。ステータスデータ又は対話内容を受信した滞在状態判断部３４２は、ユーザの滞在状態を判断し、送信部５１を介して滞在状態をシナリオ制御部３４の情報取得部３４３へと送信する。
【０１０１】
このように、滞在状態判断部３４２を店舗管理装置５に備えることにより、操作端末３における処理能力やデータ領域を確保することが可能となる。一般的には、タブレット等である操作端末３よりもサーバ等である店舗管理装置５の方が、その処理能力が高く、かつ、データ領域も大きい。また、操作端末３は、ユーザが手に持って操作するため、電源等に接続されていない場合、長時間ユーザにより操作されることによって電池の蓄電量がその使用時間に応じて下がっていく。本変形例によれば、より適切な箇所において高速な処理を行うことが可能となり、操作端末３の処理を軽くするとともに、操作端末３の電池の使用状況も改善し、より長時間、ユーザが把持して使用することを可能とする。
【０１０２】
また、滞在状態の使い途は、シナリオデータの取得のみには限られない。すなわち、操作端末３以外の箇所で滞在状態を利用したい場合には、店舗管理装置５において滞在状態を判断することが好ましい場合もある。このような構成にすることにより、判断材料を店舗管理装置５に集約することが可能となり、様々な状況について管理しやすくすることを可能とする。
【０１０３】
（第２変形例）
前述した実施形態においては、対話システム１は、操作端末３を備えるものであったが、これには限られない。例えば、操作端末３が無く、音声によりユーザとロボット２との対話動作を行うようにしてもよい。図１１は、本変形例に係る対話システム１の構成を示すブロック図である。
【０１０４】
図１０に示すように、本変形例に係る対話システム１において、ロボット２は、ロボット駆動部２１と、ロボット制御部２２と、動作生成部３２と、シナリオＤＢ３３と、シナリオ制御部３４と、さらに、音声認識部２３とを備える。ロボット駆動部２１及びロボット制御部２２に関しては、前述した実施形態と同様であり、動作生成部３２と、シナリオＤＢ３３は、操作端末３を省く代わりにロボット２へと移動したものである。
【０１０５】
音声認識部２３は、ユーザからの音声を受け付けると、受け付けた音声を、音声認識手法を用いて信号に変換し、変換された信号データからユーザ側シナリオデータへと変換する。音声認識手法としては、隠れマルコフモデルをはじめとする音響モデルを用いてもよいし、文脈自由文法等をはじめとする言語モデルを用いてもよい。音声認識手法はこれらには限られず、適切に音声を文字列データへと変換できるものであればどのようなものでもよい。また、図示しないが、周りのノイズ等とユーザの音声とを区別するためにマイク等の入力装置が備えられていてもよい。
【０１０６】
音声認識部２３は、ユーザの音声が文字列のデータに変換された後、変換された文字列データを用いてユーザ側シナリオデータを抽出する。抽出されたユーザ側シナリオデータは、シナリオ制御部３４へと送信される。図１１におけるシナリオ制御部３４は、図２に示すシナリオ制御部３４と同等のものであり、滞在状態判断部３４２は、シナリオ制御部３４に備えられている。これ以降の処理は前述した実施形態と同様のものとなる。
【０１０７】
このように、操作端末３を省き、ユーザとロボット２とが音声を介して対話を行うことも可能である。このようにすることにより、ユーザは、操作端末３に表示された選択肢を選んで対話するのではなく、人間同士の会話により近い状態でロボット２と対話することが可能となり、さらに、対話システム１は、これらの会話の中からステータスデータを適切に抽出することが可能となる。
【０１０８】
なお、本変形例は、対話システム１が操作端末３を備えていない場合について説明したが、操作端末３を備えている場合においても、本変形例のように、滞在状態判断部３４２がロボット２内に備えられ得ようにしてもよい。すなわち、滞在状態判断部３４２は、第１実施形態のように操作端末３に備えられていてもよいし、第１変形例のように店舗管理装置５に備えられていてもよいし、本変形例のようにロボット２内に備えられていてもよい。これらは、各装置や端末における処理の重さ、データフロー、メモリ量、当該機能を確保するプログラムのためのデータ領域等様々な観点に基づき、搭載箇所を適切な箇所へと適宜変更可能である。
【０１０９】
（第３変形例）
前述した第２変形例においては、ロボット２内で滞在状態を判断し、シナリオデータを取得するものであったが、本変形例に係る対話システム１においては、滞在状態の判断及びシナリオデータの取得を店舗管理装置５において行おうとするものである。
【０１１０】
一般的に、ロボット２は、物理的に制御を行う機構や構造を備え、さらにそれを制御するためのデータ領域等を備えなければならず、その他の処理能力やデータ領域を確保することが困難なことがある。そこで、本変形例においては、高負荷が掛かる処理を店舗管理装置５において行う。
【０１１１】
図１２は、本変形例に掛かる対話システム１の構成を示すブロック図である。本変形例において、ロボット２は、ロボット駆動部２１と、ロボット制御部２２と、音声認識部２３とを備える。また、店舗管理装置５は、動作生成部３２と、シナリオＤＢ３３と、シナリオ制御部３４と、滞在状態判断部３４２と、を備える。
【０１１２】
ロボット２は、音声認識部２３により、ユーザの音声、すなわち、対話データを取得し他の地、店舗管理装置５の滞在状態判断部３４２へと対話データを送信する。滞在状態判断部３４２は、対話データにステータスデータが含まれる場合には、滞在状態を判断し、シナリオ制御部３４へと滞在状態を出力する。
【０１１３】
滞在状態を受信したシナリオ制御部３４は、シナリオデータを取得し、動作生成部３２がユーザとの対話動作を制御する。なお、本変形例におけるシナリオ制御部３４は、図１０に示すシナリオ制御部３４の構成と同等のものとする。
【０１１４】
以上のように、操作端末３を備えていない場合においても、高負荷な処理を行う箇所を店舗管理装置５へ備えておくことも可能である。特に、通信の帯域が十分である場合や、ロボット２の処理能力を確保したい場合に、このような構成が有効となる。
【０１１５】
（第４変形例）
前述した実施形態及び各変形例においては、シナリオＤＢ３３は、ロボット２、操作端末３又は店舗管理装置５に備えられているものであったがこれらには限られない。図１３は、本変形例に掛かる対話システム１の構成を示すブロック図である。
【０１１６】
図１３に示すように、シナリオＤＢ３３は、有線又は無線の手法により接続される通信ネットワーク６を介して別の場所にあってもよい。例えば、クラウド上の所定のデータベースに格納されていてもよいし、多数の店舗を統括するサーバ上にあってもよい。このようにシナリオＤＢ３３を配置することにより、店舗ごとにシナリオＤＢ３３を確保する必要がなくなり、また、シナリオを一元化して管理することも可能となる。
【０１１７】
なお、上述した全ての実施形態及び変形例においては、対話は、ユーザ、又は、ロボット２が何かしらの情報を出力している状態として説明したが、これには限られない。例えば、食事中であれば、ロボット２との対話の必要性は低くなるので、このような場合においては、無言のシナリオをあらかじめ準備しておき、この無言のシナリオを出力するようにしてもよい。
【０１１８】
さらに、このようにシナリオデータベースがロボット２、操作端末３及び店舗管理装置５のいずれにも備えられていない場合、種々の変形が考えられる。例えば、店舗管理装置５内に滞在状態判断部３４２を含むシナリオ制御部３４が備えられ、店舗管理装置５のシナリオ制御部３４から、シナリオＤＢ３３に対してロボット２及び操作端末３へとシナリオデータを出力する指示をするようにしてもよい。この場合、ロボット２にはロボット側シナリオデータが、動作生成部３２、表示部３５及び入力部３６を備えた操作端末３には、ユーザ側シナリオデータが、シナリオＤＢ３３から送信される。これらのシナリオデータを用いてユーザとロボット２が対話をするようにしてもよい。そして、操作端末３から、ユーザの対話内容を店舗管理装置５へと送信し、店舗管理装置５において滞在状態の判断、シナリオ群の選択、及び、どのシナリオデータを取得するかを決めるようにしてもよい。このようにすることにより、高負荷となる処理をさらに店舗管理装置５へと集約することが可能となる。
【０１１９】
上述した全ての実施形態及び変形例に掛かる対話システム１は、記述したように飲食サービスに好適に適用することができるが、飲食サービス以外の種々のサービスに適用されてもよい。
【０１２０】
本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が相当しうる種々の変形も含むものであり、本発明の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容及びその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更及び部分的削除が可能である。
【符号の説明】
【０１２１】
１  対話システム、２  ロボット、３  操作端末、３４  シナリオ制御部、３４２  滞在状態判断部、５  店舗管理装置
【図１】
2018163504.tif 000003
【図２】
2018163504.tif 000004
【図３】
2018163504.tif 000005
【図４】
2018163504.tif 000006
【図５】
2018163504.tif 000007
【図６】
2018163504.tif 000008
【図７】
2018163504.tif 000009
【図８】
2018163504.tif 000010
【図９】
2018163504.tif 000011
【図１０】
2018163504.tif 000012
【図１１】
2018163504.tif 000013
【図１２】
2018163504.tif 000014
【図１３】
2018163504.tif 000015