特開 2024-20889 対話方法、サーバ装置、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024020889

(43)【公開日】2024-02-15

(54)【発明の名称】対話方法、サーバ装置、およびプログラム

(51)【国際特許分類】

   G06F 16/90 20190101AFI20240207BHJP

   G10L 15/00 20130101ALI20240207BHJP

   G10L 15/10 20060101ALI20240207BHJP

   G06F 3/16 20060101ALI20240207BHJP

   G06F 3/01 20060101ALI20240207BHJP

   G06F 16/9032 20190101ALI20240207BHJP

【ＦＩ】

G06F16/90 100

G10L15/00 200J

G10L15/10 500T

G06F3/16 650

G06F3/01 510

G06F16/9032

【審査請求】有

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2022123426

(22)【出願日】2022-08-02

(71)【出願人】

【識別番号】507134068

【氏名又は名称】サウンドハウンド，インコーポレイテッド

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】内藤 正樹

【テーマコード（参考）】

5B175

5E555

【Ｆターム（参考）】

5B175EA01

5B175FA01

5E555AA46

5E555BA02

5E555BA04

5E555BA15

5E555BA23

5E555BB04

5E555BC04

5E555CA47

5E555CB64

5E555DA23

5E555EA10

5E555FA00

(57)【要約】

【課題】バーチャルアシスタントによるプロアクティブな動作をユーザにとって最適なものとするための技術を提供する。
【解決手段】対話システム１において、サーバ装置は、バーチャルアシスタントとして機能するために、クエリと条件とを含む設定表現を取得するステップと、クエリおよび条件をメモリに格納するステップと、条件によって特定される状況が発生したことに応じて、クエリを含む問合表現を出力するための制御を実施するステップと、を実施する。
【選択図】図２

【特許請求の範囲】

【請求項1】

サーバ装置によって実施される対話方法であって、
クエリと条件とを含む設定表現を取得するステップと、
前記クエリおよび前記条件をメモリに格納するステップと、
前記条件によって特定される状況が発生したことに応じて、前記クエリを含む問合表現を出力するための制御を実施するステップと、備える、対話方法。

【請求項2】

前記設定表現に対して自然言語解釈を実施することにより、前記クエリおよび前記条件を前記設定表現から抽出するステップをさらに備える、請求項１に記載の対話方法。

【請求項3】

前記設定表現を取得するステップは、前記設定表現に対応する音声を受け取ることを含む、請求項１または請求項２に記載の対話方法。

【請求項4】

特定のメッセージの入力を取得するステップをさらに備え、
前記設定表現を受け付けるステップは、前記特定のメッセージが取得されたことに応じて実施される、請求項１または請求項２に記載の対話方法。

【請求項5】

前記クエリに対して自然言語解釈を実施することにより、前記クエリが適合する文法を特定するステップと、
前記文法が属するドメインを特定するステップと、
前記ドメインが前記メモリに格納されたリストに登録されているか否かを判断するステップと、
前記ドメインが前記リストに登録されていないことに応じて、前記クエリおよび前記条件を前記メモリに登録することを回避するステップと、をさらに備える、請求項１または請求項２に記載の対話方法。

【請求項6】

前記設定表現を取得するステップは、２以上のユーザのうち前記設定表現に対応するユーザを特定する情報を受け取ることを含み、
前記リストは、２以上のユーザのうち１以上のユーザを特定する情報に関連付けられており、
前記ドメインが前記リストに登録されているか否かを判断するステップは、
前記ドメインが基づく前記設定表現に対応するユーザを特定することと、
前記ユーザに関連付けられた前記リストを特定することと、を含む、請求項５に記載の対話方法。

【請求項7】

前記設定表現に基づいて、前記クエリの種類を特定するステップと、
前記種類に基づく態様に従って、前記問合表現を生成するステップと、をさらに備える、請求項１または請求項２に記載の対話方法。

【請求項8】

前記種類に基づく態様は、前記問合表現において前記クエリに追加される内容を識別する、請求項７に記載の対話方法。

【請求項9】

前記問合表現は、肯定または否定を意味する回答を要求する質問を含む、請求項１または請求項２に記載の対話方法。

【請求項10】

前記状況は、自動車に関する状況を含む、請求項１または請求項２に記載の対話方法。

【請求項11】

前記条件は、前記状況が発生する頻度を規定する、請求項１または請求項２に記載の対話方法。

【請求項12】

サーバ装置とユーザ端末とによって実施される対話方法であって、
前記サーバ装置によって、クエリと条件とを含む設定表現を取得するステップと、
前記サーバ装置によって、前記クエリおよび前記条件をメモリに格納するステップと、
前記サーバ装置によって、前記ユーザ端末に対し、前記条件によって特定される状況が発生したことに応じて、前記クエリを含む問合表現の出力を指示するステップと、
前記ユーザ端末によって、前記サーバ装置からの指示に応じて、前記問合表現を出力するステップと、を備える、対話方法。

【請求項13】

前記ユーザ端末によって、前記設定表現を音声で受け取るステップと、
前記ユーザ端末によって、前記設定表現を前記サーバ装置へ送信するステップと、をさらに備える、請求項１２に記載の対話方法。

【請求項14】

前記ユーザ端末によって、前記条件によって特定される状況が発生したか否かを判断するためのデータを前記サーバ装置へ送信するステップを、さらに備える、請求項１２または請求項１３に記載の対話方法。

【請求項15】

プロセッサと、
前記プロセッサによって実行されることにより、前記プロセッサに請求項１または請求項２に記載の対話方法を実施させる、プログラムを格納するメモリと、を備える、サーバ装置。

【請求項16】

プロセッサによって実行されることにより、前記プロセッサに請求項１または請求項２に記載の対話方法を実施させる、プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピュータによるユーザとの対話に関する。

【背景技術】

【0002】

従来、バーチャルアシスタントのプロアクティブな動作について種々検討がなされていた。たとえば、非特許文献１（Maria Schmidt，外２名，“How Users React to Proactive Voice Assistant Behavior While Driving”，［online］，令和２年５月１１日，［令和４年６月１３日検索］，インターネット＜URL: https://aclanthology.org/2020.lrec-1.61/＞）では、音声アシスタントの受け身的な動作と積極的な動作のそれぞれに対するドライバの認識の負荷の大きさが検討されている。非特許文献２（O. Miksik，外１８名，“Building Proactive Voice Assistants: When and How (not) to Interact”，［online］，令和２年５月４日，［令和４年６月１３日検索］，インターネット＜URL: https://arxiv.org/pdf/2005.01322.pdf＞）では、音声アシスタントのプロアクティブな動作を開始する適切なタイミングが検討されている。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】Maria Schmidt，外２名，“How Users React to Proactive Voice Assistant Behavior While Driving”，［online］，令和２年５月１１日，［令和４年６月１３日検索］，インターネット＜URL: https://aclanthology.org/2020.lrec-1.61/＞

【非特許文献2】O. Miksik，外１８名，“Building Proactive Voice Assistants: When and How (not) to Interact”，［online］，令和２年５月４日，［令和４年６月１３日検索］，インターネット＜URL: https://arxiv.org/pdf/2005.01322.pdf＞

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来、バーチャルアシスタントのプロアクティブな動作自体の最適化については検討がなされていなかった。

【0005】

本開示は、係る実情に鑑み考え出されたものであり、バーチャルアシスタントによるプロアクティブな動作をユーザにとって最適なものとするための技術を提供するものである。

【課題を解決するための手段】

【0006】

本開示のある局面に従うと、サーバ装置によって実施される対話方法であって、クエリと条件とを含む設定表現を取得するステップと、前記クエリおよび前記条件をメモリに格納するステップと、前記条件によって特定される状況が発生したことに応じて、前記クエリを含む問合表現を出力するための制御を実施するステップと、備える、対話方法が提供される。

【発明の効果】

【0007】

本開示によれば、ユーザにとって最適なプロアクティブ動作を実施するバーチャルアシスタントとしての動作を提供する、対話方法が提供される。

【図面の簡単な説明】

【0008】

【図1】実施の形態における対話システムの構成の一例を示す図である。

【図2】対話システム１の動作の一例を模式的に示す図である。

【図3】メインサーバ１００のハードウエア構成の一例を示す図である。

【図4】ユーザ端末２００のハードウエア構成の一例を示す図である。

【図5】登録情報の内容の一例を表す図である。

【図6】登録情報のデータ構造の第１具体例を、設定表現とともに示す図である。

【図7】登録情報のデータ構造の第２具体例を、設定表現とともに示す図である。

【図8】登録情報のデータ構造の第３具体例を、設定表現とともに示す図である。

【図9】ポーリングクエリのフレームのデータ構造の第１具体例を示す図である。

【図10】ポーリングクエリのデータ構造の第１具体例を示す図である。

【図11】ポーリングクエリのフレームのデータ構造の第２具体例を示す図である。

【図12】ポーリングクエリのデータ構造の第２具体例を示す図である。

【図13】ポーリングクエリのフレームのデータ構造の第３具体例を示す図である。

【図14】ポーリングクエリのデータ構造の第３具体例を示す図である。

【図15】問合表現の生成方法を説明するための図である。

【図16】対話システム１が実施する処理のフローチャートである。

【図17】対話システム１が実施する処理のフローチャートである。

【図18】対話システム１が実施する処理のフローチャートである。

【図19】対話システム１が実施する処理のフローチャートである。

【発明を実施するための形態】

【0009】

以下に、図面を参照しつつ、対話方法を実現する対話システムの一実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらの説明は繰り返さない。

【0010】

［１．対話システムの構成］
図１は、実施の形態における対話システムの構成の一例を示す図である。対話システム１は、メインサーバ１００、ユーザ端末２００、ＡＰＩ（Application Programming Interface）サーバ８００、および制御サーバ９００を含む。図１では、メインサーバ１００、ユーザ端末２００、ＡＰＩサーバ８００、および制御サーバ９００のそれぞれの数量は１であるが、本開示によって説明される技術においてこれらの数量は１に制限されない。

【0011】

対話システム１では、メインサーバ１００およびユーザ端末２００は、ユーザ３００に対するバーチャルアシスタントとして機能する。メインサーバ１００には、バーチャルアシスタントとして機能するための、サーバ用のアプリケーションプログラム（サーバ用アプリ）がインストールされている。ユーザ端末２００には、バーチャルアシスタントとして機能するための、端末用のアプリケーションプログラム（端末用アプリ）がインストールされている。ユーザ端末２００は、スマートフォンであってもよいし、スマートスピーカであってもよいし、自動車に搭載された情報処理装置であってもよいし、家電機器に搭載された情報処理装置であってもよい。

【0012】

メインサーバ１００は、バーチャルアシスタントとして機能するために、必要に応じて、ＡＰＩサーバ８００に要求を送信し、ＡＰＩサーバ８００から当該要求に応じた応答を受信し、受信した応答を利用する。メインサーバ１００は、バーチャルアシスタントとして機能するために、必要に応じて、制御サーバ９００に対して指示を送信する。

【0013】

ＡＰＩサーバ８００は、たとえば、天気に関する情報を提供するサーバとして実現される。制御サーバ９００は、種々の装置の動作を制御するためのサーバとして実現される。一例では、制御サーバ９００は、自動車に搭載されたコンピュータと通信することにより、当該自動車内の要素（エアコン、ラジオ、等）の動作を制御する。他の例では、制御サーバ９００は、家電機器に搭載されたコンピュータと通信することにより、当該家電機器の動作を制御する。なお、図１では、メインサーバ１００、ユーザ端末２００、ＡＰＩサーバ８００、および制御サーバ９００は、ネットワーク５００を介して通信するように記載されているが、これらはネットワーク５００を介して通信する必要はない。たとえば、ユーザ端末２００および制御サーバ９００の双方が自動車に搭載されていてもよく、ユーザ端末２００および制御サーバ９００は、直接通信するように構成されていてもよい。

【0014】

図２は、対話システム１の動作の一例を模式的に示す図である。対話システム１は、ユーザ３００から、設定表現を取得する。設定表現は、クエリおよび条件を特定する情報を含む。対話システム１は、上記条件によって特定される状況が発生するか否かを監視する。そして、上記条件によって特定される状況が発生すると、対話システム１は、上記クエリを含む問合表現を出力する。これにより、対話システム１は、ユーザ３００が設定した条件によって特定される状況が発生したときに、ユーザ３００に対してプロアクティブな対話を開始することができる。対話システム１は、また、このようなプロアクティブな対話を、ユーザ３００が設定したクエリを含む問合表現で開始することができる。

【0015】

［２．ハードウェア構成（メインサーバ）］
図３は、メインサーバ１００のハードウエア構成の一例を示す図である。メインサーバ１００は、ＣＰＵ（Central Processing Unit）１０１と、通信Ｉ／Ｆ（インターフェース）１０２と、ストレージ１０３とを含む。ストレージ１０３は、各種のプログラムを格納するプログラム用領域１０３１、および、各種のデータを格納するデータ領域１０３２を含む。

【0016】

ＣＰＵ１０１は、ストレージ１０３または外部の記憶装置に格納されたプログラムを実行することにより、各種の演算を実行する。通信Ｉ／Ｆ１０２は、たとえばネットワークカードによって実現され、メインサーバ１００を対話システム１内の他の装置と通信させる。対話システム１において、ＡＰＩサーバ８００および制御サーバ９００は、図３に示されたメインサーバ１００と同様のハードウェア構成を有していても良い。

【0017】

［３．ハードウェア構成（ユーザ端末）］
図４は、ユーザ端末２００のハードウエア構成の一例を示す図である。ユーザ端末２００は、ＣＰＵ２０１と、ディスプレイ２０２と、マイクロフォン２０３と、スピーカ２０４と、入力デバイス２０５と、通信Ｉ／Ｆ２０６と、ストレージ２０７とを含む。ストレージ２０７は、各種のプログラムを格納するプログラム用領域２０７１、および、各種のデータを格納するデータ領域２０７２を含む。

【0018】

ＣＰＵ２０１は、ストレージ２０７または外部の記憶装置に格納されたプログラムを実行することにより、各種の演算を実行する。

【0019】

ディスプレイ２０２は、ＣＰＵ２０１から指示された画面を表示する。マイクロフォン２０３は、入力された音声をＣＰＵ２０１に入力する。スピーカ２０４は、ＣＰＵ２０１から指示された音声を出力する。入力デバイス２０５は、たとえば物理キーおよび／またはタッチセンサによって実現され、ユーザからの情報の入力を受け付ける。通信Ｉ／Ｆ２０６は、たとえばネットワークカードによって実現され、ユーザ端末２００を対話システム１内の他の装置と通信させる。

【0020】

［４．設定表現の処理］
対話システム１において、メインサーバ１００は、ユーザから設定表現を受け付けると、当該設定表現からクエリおよび条件を抽出し、登録情報として、当該クエリおよび条件をストレージ１０３に格納する。図５～図７を参照して、クエリおよび条件を設定表現から抽出して登録情報として格納するための処理について説明する。

【0021】

（登録されるデータの内容）
図５は、登録情報の内容の一例を表す図である。図５において「Ｋｅｙ」として示されるように、格納されるデータは、７種類の項目（「Query Text」「Query Type」「Query Domain」「Trigger Type」「Trigger Value」「Trigger Repeat」「Trigger Rule」）を含む。「Query Text」「Query Type」および「Query Domain」は、クエリを構成する情報である。「Trigger Type」「Trigger Value」「Trigger Repeat」および「Trigger Rule」は、条件を構成する情報である。図５には、「Ｎｏｔｅｓ」として、各項目に関する解説が付記されている。以下、各項目について説明する。

【0022】

「Query Text」は、クエリのテキストを識別する。
「Query Type」は、クエリの種類を識別する。一実現例では、クエリの種類として、「質問」および「命令」が定義される。「質問」は、ユーザが尋ねたい内容を表すクエリであることを意味する。「命令」は、ユーザが実現を希望する内容を表すクエリであることを意味する。

【0023】

「Query Domain」は、クエリが属するドメインを識別する。一実現例では、ドメインは、クエリの内容が表す分野を意味する。図５の例では、ドメインの例として、「天気」「家電制御」および「自動車制御」が示される。

【0024】

「Trigger Type」は、条件の種類を識別する。図５の例では、条件の種類の例として、「時刻」「気温」および「速度」が示される。

【0025】

「Trigger Value」は、条件を構成する値を識別する。条件を構成する値の種類は、条件の種類（「Trigger Type」）に依存する。たとえば、「Trigger Type」が時刻であれば「Trigger Value」は時刻の単位を対応する値であり、「Trigger Type」が気温であれば「Trigger Value」は温度の単位に対応する値であり、「Trigger Type」が速度であれば「Trigger Value」は速度の単位に対応する値である。

【0026】

「Trigger Repeat」は、条件によって特定される状況が発生する頻度を識別する。図５の例では、条件が発生する頻度として、「毎日」「毎週（○曜日）」「毎月（○日）」および「一時間ごと」が示される。登録情報が項目「Trigger Repeat」の値を含むことにより、登録情報に含まれる条件は、状況が発生する頻度を規定する。

【0027】

「Trigger Rule」は、「Trigger Value」が利用される規則を識別する。一実現例では、規則として、「等価」「以上」および「以下」が定義される。

【0028】

（登録されるデータの第１具体例）
図６は、登録情報のデータ構造の第１具体例を、設定表現とともに示す図である。

【0029】

図６のデータ構造は、設定表現「今日の天気はどうですか、と毎日午前８時に尋ねたいです。」から抽出されるクエリおよび条件を構成するデータを含む。

【0030】

より具体的には、図６のデータ構造は、「Query Text」として「今日の天気はどうですか」を含む。

【0031】

一実現例では、設定表現に対して自然言語解釈が実施されることにより、「Query Text」として、設定表現からクエリを表す部分「今日の天気はどうですか」が抽出される。

【0032】

たとえば、メインサーバ１００には、設定表現に対する自然言語解釈のための文法が格納されている。文法の一例は、「［第１フレーズ］、と［第２フレーズ］尋ねたいです。」である。この文法において、［第１フレーズ］および［第２フレーズ］のそれぞれは、任意のテキストを表すことが意図される。そして、設定表現がこの文法に適合した場合、［第１フレーズ］に相当する部分が、クエリを表す部分として抽出される。

【0033】

図６のデータ構造は、「Query Type」として「質問」を含む。一実現例では、設定表現が「尋ねたいです。」というフレーズを含む場合に、クエリの種類として「質問」が特定される。

【0034】

図６のデータ構造は、「Query Domain」として「天気」を含む。一実現例では、設定表現からクエリが抽出された後、当該クエリが当てはまる文法が特定され、特定された文法が属するドメインが特定される。このように特定されたドメインが、「Query Domain」の値として特定される。なお、対話システム１では、たとえばストレージ１０３に、自然言語解釈に利用される複数の文法のそれぞれが属するドメインを指し示すデータベースが格納されている。

【0035】

図６のデータ構造は、「Trigger Type」として「時刻」を含む。一実現例では、設定表現からクエリが抽出された後、設定表現のうちクエリ以外の部分に対して自然言語解釈が実施されることにより、「Trigger Type」の値が特定される。たとえば、クエリが「○○時に」（「○○」は任意の数字を表す）という文字列を含むとき、「Trigger Type」の値として「時刻」が特定される。

【0036】

図６のデータ構造は、「Trigger Value」として「08:00」を含む。一実現例では、「Trigger Value」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。より具体的には、設定表現が「午前８時に」というフレーズを含むことによって「Trigger Type」の値「時刻」が特定された場合、「Trigger Type」の値として、当該フレーズに含まれる時刻を表す部分「午前８時」に対応する数値「08:00」が特定される。

【0037】

図６のデータ構造は、「Trigger Repeat」として「毎日」を含む。一実現例では、設定表現のうちクエリ以外の部分に頻度を表す文字列が含まれる場合、当該文字列が「Trigger Repeat」として特定される。

【0038】

図６のデータ構造は、「Trigger Rule」として「等価」を含む。一実現例では、「Trigger Value」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。図６の例では、「午前８時に」というフレーズが、時間を表す「午前８時」そのものを指し示すことから、「Trigger Rule」として「等価」が特定される。

【0039】

（登録されるデータの第２具体例）
図７は、登録情報のデータ構造の第２具体例を、設定表現とともに示す図である。

【0040】

図７のデータ構造は、設定表現「気温が２５℃以上になったら、エアコンをオンにしたいです。」から抽出されるクエリおよび条件を構成するデータを含む。

【0041】

より具体的には、図７のデータ構造は、「Query Text」として「エアコンをオンにしたい」を含む。

【0042】

一実現例では、設定表現に対して自然言語解釈が実施されることにより、「Query Text」として、設定表現からクエリを表す部分「エアコンをオンにしたい」が抽出される。

【0043】

たとえば、メインサーバ１００には、設定表現に対する自然言語解釈のための文法が格納されている。文法の一例は、「［第１フレーズ］になったら、［第２フレーズ］したいです。」である。この文法において、［第１フレーズ］および［第２フレーズ］のそれぞれは、任意のテキストを表すことが意図される。そして、設定表現がこの文法に適合した場合、［第２フレーズ］に相当する部分が、クエリを表す部分として抽出される。

【0044】

図７のデータ構造は、「Query Type」として「命令」を含む。一実現例では、設定表現が「尋ねたいです。」というフレーズを含まない場合に、クエリの種類として「命令」が特定される。

【0045】

図７のデータ構造は、「Query Domain」として「家電制御」を含む。一実現例では、設定表現からクエリが抽出された後、当該クエリが当てはまる文法が特定され、特定された文法が属するドメインが特定される。このように特定されたドメインが、「Query Domain」の値として特定される。

【0046】

図７のデータ構造は、「Trigger Type」として「気温」を含む。一実現例では、設定表現からクエリが抽出された後、設定表現のうちクエリ以外の部分に対して自然言語解釈が実施されることにより、「Trigger Type」の値が特定される。たとえば、クエリが「○○℃以上になったら」（「○○」は任意の数字を表す）という文字列を含むとき、「Trigger Type」の値として「気温」が特定される。

【0047】

図７のデータ構造は、「Trigger Value」として「２５」を含む。一実現例では、「Trigger Value」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。より具体的には、設定表現が「２５℃以上になったら」というフレーズを含むことによって「Trigger Type」の値「気温」が特定された場合、「Trigger Value」の値として、当該フレーズに含まれる温度を表す部分「２５℃」に対応する数値「２５」が特定される。

【0048】

図７のデータ構造は、「Trigger Repeat」の値を含まない。これは、図７の例では、設定表現のうちクエリ以外の部分に頻度を表す文字列が含まれないことに基づく。

【0049】

図７のデータ構造は、「Trigger Rule」として「以上」を含む。一実現例では、「Trigger Rule」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。図７の例では、「２５℃以上になったら」というフレーズが、「以上」を含むことから、「Trigger Rule」として「以上」が特定される。

【0050】

（登録されるデータの第３具体例）
図８は、登録情報のデータ構造の第３具体例を、設定表現とともに示す図である。

【0051】

図８のデータ構造は、設定表現「車の速度が時速４０キロ以下になったら、ラジオをオンにしたいです。」から抽出されるクエリおよび条件を構成するデータを含む。

【0052】

より具体的には、図８のデータ構造は、「Query Text」として「ラジオをオンにしたい」を含む。一実現例では、設定表現に対して自然言語解釈が実施されることにより、「Query Text」として、設定表現からクエリを表す部分「ラジオをオンにしたい」が抽出される。

【0053】

図８のデータ構造は、「Query Type」として「命令」を含む。一実現例では、設定表現が「尋ねたいです。」というフレーズを含まない場合に、クエリの種類として「命令」が特定される。

【0054】

図８のデータ構造は、「Query Domain」として「自動車制御」を含む。一実現例では、設定表現からクエリが抽出された後、当該クエリが当てはまる文法が特定され、特定された文法が属するドメインが特定される。このように特定されたドメインが、「Query Domain」の値として特定される。

【0055】

図８のデータ構造は、「Trigger Type」として「速度」を含む。一実現例では、設定表現からクエリが抽出された後、設定表現のうちクエリ以外の部分に対して自然言語解釈が実施されることにより、「Trigger Type」の値が特定される。たとえば、クエリが「時速が○○キロ以下になったら」（「○○」は任意の数字を表す）という文字列を含むとき、「Trigger Type」の値として「速度」が特定される。

【0056】

図８のデータ構造は、「Trigger Value」として「４０」を含む。一実現例では、「Trigger Value」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。より具体的には、設定表現が「時速４０キロ以下になったら」というフレーズを含むことによって「Trigger Type」の値「速度」が特定された場合、「Trigger Type」の値として、当該フレーズに含まれる速度を表す部分「４０キロ」（４０キロメートル毎時）に対応する数値「４０」が特定される。

【0057】

図８のデータ構造は、「Trigger Repeat」の値を含まない。これは、図８の例では、設定表現のうちクエリ以外の部分に頻度を表す文字列が含まれないことに基づく。

【0058】

図８のデータ構造は、「Trigger Rule」として「以下」を含む。一実現例では、「Trigger Rule」の値は、「Trigger Type」の値の特定に利用されたフレーズを利用して特定される。図８の例では、「時速４０キロ以下になったら」というフレーズが、「以下」を含むことから、「Trigger Rule」として「以下」が特定される。

【0059】

図８に示されるデータ構造によって特定される条件は、自動車の時速が４０キロメートル以下になったことを規定する。この場合、条件によって特定される状況は、自動車の時速が４０キロメートル以下になった状況であり、自動車に関する状況の一例である。

【0060】

［５．条件に基づく問合表現の出力］
図２を参照して説明されたように、対話システム１は、条件によって特定される状況が発生したことに応じて、問合表現を出力する。

【0061】

一実現例では、対話システム１は、条件によって特定される状況が発生したか否かを判断するためのデータを定期的に収集し、当該状況が発生したか否かを判断する。上記データの収集の一例として、メインサーバ１００自身が上記データを収集する。他の例では、ユーザ端末２００が上記データを収集してメインサーバ１００に提供する。より具体的には、ユーザ端末２００は、メインサーバ１００へ、定期的にポーリングクエリを送信することにより、上記データを提供する。

【0062】

ポーリングクエリの送信に関し、メインサーバ１００は、登録情報としてストレージ１０３に格納されたデータ群の一部を利用して、ポーリングクエリのフレームを作成し、当該フレームをユーザ端末２００へ送信する。ユーザ端末２００は、定期的に、当該フレームにデータを充填することによりポーリングクエリを生成し、メインサーバ１００へ送信する。以下、ポーリングクエリの具体例を説明する。

【0063】

（ポーリングクエリおよびそのフレームの第１具体例）
図９は、ポーリングクエリのフレームのデータ構造の第１具体例を示す図である。図９の例は、設定表現として図６に示された表現が入力された場合に対応する。

【0064】

図９の例において、ポーリングクエリのフレームは、メッセージ「check_proactive_query_trigger」と、文字列「RequestInfo:{ExtraValue: {Type: Time, Value: [###]}}」とを含む。メッセージ「check_proactive_query_trigger」は、後続の文字列で特定されるデータを利用して、登録情報の中の条件によって特定された状況が発生しているか否かを判断することを指示する。文字列「RequestInfo:{ExtraValue: {Type: Time, Value: [###]}}」のうち、「Type: Time」は、収集されるデータの種類を表し、より具体的には、「時刻」を表す。メインサーバ１００は、このメッセージにおけるデータの種類として、登録情報の中の「Trigger Type」として特定される種類を設定する。「Value: [###]」は、収集されたデータを充填される部分を表す。より具体的には、「###」は、収集されたデータに置換される。

【0065】

図１０は、ポーリングクエリのデータ構造の第１具体例を示す図である。図１０のデータ構造は、図９に示されたフレームを利用して生成される。より具体的には、図１０のデータ構造は、ユーザ端末２００が、条件によって特定される状況が発生したか否かを判断するためのデータとして７時５０分という時刻を取得したことに応じて生成される。さらに具体的には、図１０のデータ構造は、図９に示されたデータ構造における「###」が、収集されたデータ（７時５０分という時刻を表す「07:50」）に置換されることによって生成される。

【0066】

以上より、図１０に示されたポーリングクエリは、「07:50」という時刻を表すデータを利用して、登録情報の中の条件によって特定される状況が発生したか否かを判断することを指示する。

【0067】

（ポーリングクエリおよびそのフレームの第２具体例）
図１１は、ポーリングクエリのフレームのデータ構造の第２具体例を示す図である。図１１の例は、設定表現として図７に示された表現が入力された場合に対応する。

【0068】

図１１の例において、ポーリングクエリのフレームは、メッセージ「check_proactive_query_trigger」と、文字列「RequestInfo:{ExtraValue: {Type: Temperature, Value: [###]}}」とを含む。「Type: Temperature」は、収集されるデータの種類を表し、より具体的には、「気温」を表す。

【0069】

図１２は、ポーリングクエリのデータ構造の第２具体例を示す図である。図１２のデータ構造は、図１１に示されたフレームを利用して生成される。より具体的には、図１２のデータ構造は、ユーザ端末２００が、条件によって特定される状況が発生したか否かを判断するためのデータとして３０℃という気温のデータを取得したことに応じて生成される。ユーザ端末２００は、たとえば、気温を計測する機器と通信することにより、上記データを取得する。そして、図１２のデータ構造は、図１１に示されたデータ構造における「###」が、収集されたデータ（３０℃という気温「30.0」）に置換されることによって生成される。

【0070】

以上より、図１２に示されたポーリングクエリは、「30.0」という気温を表すデータを利用して、登録情報の中の条件によって特定される状況が発生したか否かを判断することを指示する。

【0071】

（ポーリングクエリおよびそのフレームの第３具体例）
図１３は、ポーリングクエリのフレームのデータ構造の第３具体例を示す図である。図１３の例は、設定表現として図８に示された表現が入力された場合に対応する。

【0072】

図１３の例において、ポーリングクエリのフレームは、メッセージ「check_proactive_query_trigger」と、文字列「RequestInfo:{ExtraValue: {Type: Speed, Value: [###]}}」とを含む。「Type: Speed」は、収集されるデータの種類を表し、より具体的には、「（自動車の）速度」を表す。

【0073】

図１４は、ポーリングクエリのデータ構造の第３具体例を示す図である。図１４のデータ構造は、図１３に示されたフレームを利用して生成される。より具体的には、図１４のデータ構造は、ユーザ端末２００が、条件によって特定される状況が発生したか否かを判断するためのデータとして時速６０キローメートルという速度のデータを取得したことに応じて生成される。ユーザ端末２００は、たとえば、自動車に設置されたコンピュータとして実現され、当該自動車の速度計と通信することによって上記の速度のデータを取得する。そして、図１４のデータ構造は、図１３に示されたデータ構造における「###」が、収集されたデータ（時速６０キローメートルという速度を表す「60.0」のデータ）に置換されることによって生成される。

【0074】

以上より、図１４に示されたポーリングクエリは、「60.0」という速度を表すデータを利用して、登録情報の中の条件によって特定される状況が発生したか否かを判断することを指示する。

【0075】

［６．問合表現］
図１５は、問合表現の生成方法を説明するための図である。図１５を参照して、クエリを含む問合表現の生成方法の一例を説明する。

【0076】

図１５に示されたテーブルは、条件によって特定される状況の発生という項目を含む。この項目は、条件によって特定される状況の発生が発生しているか否かを表す。図１５に示されたテーブルは、さらに３つの項目（クエリの種類、問合表現の生成方法、および、問合表現の例）を有する。

【0077】

図１５の例において、上記状況が発生していない場合（条件によって特定される状況の発生という項目の値が「無し」の場合）、クエリの種類に拘わらず、問合表現は生成されない。

【0078】

図１５の例において、上記状況が発生した場合（条件によって特定される状況の発生という項目の値が「有り」の場合）、クエリの種類に従った態様（生成方法）で、問合表現が生成される。より具体的には、クエリの種類が「質問」である場合、登録情報において「Query Text」の値として登録されているクエリのテキストに、「と尋ねたいですか？」を付加することにより、問合表現が生成される。一方、クエリの種類が「命令」である場合、登録情報において「Query Text」の値として登録されているクエリのテキストに、「ですか？」を付加することにより、問合表現が生成される。すなわち、クエリの種類によって、問合表現を生成するためにクエリのテキストに追加される文字列（内容）が異なる。

【0079】

クエリの種類が「質問」である場合に生成される問合表現の一例は、「今日の天気はどうですか、と尋ねたいですか？」である。この問合表現は、図６に示された例に対応する。図６の例では、クエリのテキストは「今日の天気はどうですか」であり、クエリの種類は「質問」である。「今日の天気はどうですか」に、「と尋ねたいですか？」が付加されることによって、上記の問合表現が生成される。

【0080】

クエリの種類が「命令」である場合に生成される問合表現の一例は、「エアコンをオンにしたいですか？」である。この問合表現は、図７に示された例に対応する。図７の例では、クエリのテキストは「エアコンをオンにしたい」であり、クエリの種類は「命令」である。「エアコンをオンにしたい」に、「ですか？」が付加されることによって、上記の問合表現が生成される。

【0081】

生成される問合表現は、ユーザ３００に対して、肯定を意味する回答（たとえば、「はい。」）、または、否定を意味する回答（たとえば、「いいえ。」）を要求する質問であってもよい。

【0082】

［７．処理の流れ］
図１６～図１９は、対話システム１が実施する処理のフローチャートである。図１６～図１９には、メインサーバ１００において実施される処理と、ユーザ端末２００において実施される処理が示される。一実現例では、メインサーバ１００は、ＣＰＵ１０１にサーバ用アプリを実行させることによって上記処理を実施する。一実現例では、ユーザ端末２００は、ＣＰＵ２０１に端末用アプリを実行させることによって上記処理を実施する。

【0083】

図１６を参照して、ステップＳ２００にて、ユーザ端末２００は、ユーザ３００からウェイクワードを入力されたか否かを判断する。ユーザ端末２００は、ウェイクワードが入力されたと判断するまでステップＳ２００の制御を繰り返し（ステップＳ２００にてＮＯ）、ウェイクワードが入力されたと判断すると（ステップＳ２００にてＹＥＳ）、ステップＳ２０２へ制御を進める。

【0084】

ステップＳ２０２にて、ユーザ端末２００は、ユーザ３００からウェイクワードの次に入力された音声を取得する。

【0085】

ステップＳ２０４にて、ユーザ端末２００は、ステップＳ２０２において取得した音声をメインサーバ１００へ送信する。

【0086】

ステップＳ１００にて、メインサーバ１００は、ステップＳ２０４においてユーザ端末２００から送信された音声を受信する。

【0087】

ステップＳ１０２にて、メインサーバ１００は、ステップＳ１００において受信した音声が、上述の登録情報の登録を要求するためのメッセージ（登録用メッセージ）を含むか否かを判断する。登録用メッセージは、本開示における「特定のメッセージ」の一例である。登録用メッセージの一例は、「クエリと条件を設定させて。」である。一実現例では、メインサーバ１００は、音声認識技術を用いて上記音声のテキストを生成し、当該テキストが登録用メッセージのテキストを含むか否かによってステップＳ１０２の判断を実施する。メインサーバ１００は、上記音声が登録用メッセージを含むと判断するとステップＳ１０４へ制御を進め（ステップＳ１０２にてＹＥＳ）、そうでなければステップＳ１３８へ制御を進める（ステップＳ１０２にてＮＯ）。

【0088】

図１７を参照して、ステップＳ１３８にて、メインサーバ１００は、受信した音声に従った動作を実施して、処理を終了させる。

【0089】

図１６に戻って、ステップＳ１０４にて、メインサーバ１００は、ユーザ端末２００に対して、設定表現の入力を促すメッセージ（促進用メッセージ）の出力を指示する。促進用メッセージの一例は、「クエリと条件を話して。」である。

【0090】

ステップＳ２０６にて、ユーザ端末２００は、ステップＳ１０４の指示に応じて、促進用メッセージを出力する。促進用メッセージの出力の一例は、促進用メッセージを表す音声を発話することである。

【0091】

ステップＳ２０８にて、ユーザ端末２００は、ユーザ３００から入力される音声を取得する。入力される音声は、促進用メッセージの出力の後にユーザ３００の発話であり、通常は設定表現である。

【0092】

ステップＳ２１０にて、ユーザ端末２００は、ステップＳ２０８において取得した音声をメインサーバ１００へ送信する。

【0093】

ステップＳ１０６にて、メインサーバ１００は、ステップＳ２１０において送信された音声を受信する。

【0094】

ステップＳ１０８にて、メインサーバ１００は、ステップＳ１０６において受信した音声に対して音声認識を実施する。これにより、音声に対応するテキストが取得される。

【0095】

ステップＳ１１０にて、メインサーバ１００は、ステップＳ１０８において取得されたテキストに対して自然言語解釈を実施する。

【0096】

ステップＳ１１２にて、メインサーバ１００は、ステップＳ１１０における自然言語解釈の結果を利用して、設定表現（ステップＳ２０８において入力された音声）から、クエリ（「Query Text」の値）および条件（「Trigger Type」「Trigger Value」「Trigger Repeat」および「Trigger Rule」の各々の値）を抽出する。

【0097】

ステップＳ１１４にて、メインサーバ１００は、設定表現（ステップＳ２０８において入力された音声）に基づいて、クエリの種類（「Query Type」の値）を特定する。

【0098】

ステップＳ１１６にて、メインサーバ１００は、設定表現（ステップＳ２０８において入力された音声）に基づいて、クエリが対応する文法を特定する。

【0099】

ステップＳ１１８にて、メインサーバ１００は、ステップＳ１１６において特定された文法に基づいて、クエリのドメイン（「Query Domain」の値）を特定する。

【0100】

図１８を参照して、ステップＳ１２０にて、メインサーバ１００は、ステップＳ１１８において特定されたドメインがリストに含まれているか否かを判断する。リストとは、ユーザ３００に対して適用可能なドメインのリストを意味する。一実現例では、当該リストは、ストレージ１０３に格納されている。メインサーバ１００は、上記ドメインが上記リストに含まれていると判断すると（ステップＳ１２０にてＹＥＳ）、ステップＳ１２２へ制御を進める。メインサーバ１００は、上記ドメインが上記リストに含まれていないと判断すると（ステップＳ１２０にてＮＯ）、ステップＳ１４０へ制御を進める。

【0101】

図１９を参照して、ステップＳ１４０にて、メインサーバ１００は、ユーザ端末２００に対して、設定失敗の報知を指示する。その後、メインサーバ１００は処理を終了させる。

【0102】

ステップＳ２２６にて、ユーザ端末２００は、ステップＳ１４０の指示に応じて、設定失敗を報知する。設定失敗の報知の一例は、メッセージ「そのクエリは対象外です。」の出力である。他の例は、メッセージ「別のクエリを入力してください。」の出力である。

【0103】

図１８に戻って、ステップＳ１２２にて、メインサーバ１００は、ステップＳ１１２～Ｓ１１８において抽出または特定されたデータを、登録情報として、ユーザ３００に関連付けて、ストレージ１０３に格納する。

【0104】

上述のように、メインサーバ１００は、ステップＳ１２０において、上述のドメインが上述のリストに含まれているか否かを判断し、含まれていないと判断した場合、ステップＳ１２２における登録情報のデータの格納を実施することなく、処理を終了させる。この意味において、ステップＳ１２０は、登録情報（クエリおよび条件）をメモリに登録することを回避するステップの一例である。

【0105】

ステップＳ１２４にて、メインサーバ１００は、ステップＳ１１４において特定されたクエリの種類を利用して、ポーリングクエリのフレームを生成する。

【0106】

ステップＳ１２６にて、メインサーバ１００は、ステップＳ１２４において生成したポーリングクエリのフレームをユーザ端末２００へ送信する。

【0107】

ステップＳ２１２にて、ユーザ端末２００は、ステップＳ１２６において送信されたポーリングクエリのフレームを受信する。

【0108】

ステップＳ２１４にて、ユーザ端末２００は、ステップＳ２１２において受信したポーリングクエリのフレームをストレージ２０７に格納する。

【0109】

ステップＳ２１６にて、ユーザ端末２００は、ポーリングクエリ用のデータ（たとえば、図９、図１１、または図１３において「###」で表されたデータ）を収集する。

【0110】

ステップＳ２１８にて、ユーザ端末２００は、ステップＳ２１６において収集されたデータを利用してポーリングクエリを生成し、生成されたポーリングクエリをメインサーバ１００へ送信する。

【0111】

ステップＳ１２８にて、メインサーバ１００は、ステップＳ２１８において送信されたポーリングクエリを受信する。

【0112】

ステップＳ１３０にて、メインサーバ１００は、ポーリングクエリに含まれるデータを利用して、登録情報の条件によって特定される状況が発生しているか否かを判断する。メインサーバ１００は、上記状況が発生していると判断するとステップＳ１３２へ制御を進め（ステップＳ１３０にてＹＥＳ）、そうでなければ処理を終了させる（ステップＳ１３０にてＮＯ）。

【0113】

登録情報によって特定される状況の一例は、午前８時になったことである。ポーリングクエリに含まれるデータが、午前７時５０分を示す場合には、未だ午前８時は到来していないので、メインサーバ１００は、上記状況が発生していないと判断する。一方、ポーリングクエリに含まれるデータが、午前８時００分を示す場合には、メインサーバ１００は、上記状況が発生していると判断する。

【0114】

登録情報によって特定される状況の他の例は、気温が２５℃以上になったことである。ポーリングクエリに含まれるデータが、気温が２０℃であることを示す場合には、メインサーバ１００は、上記状況が発生していないと判断する。一方、ポーリングクエリに含まれるデータが、気温が３０℃であることを示す場合には、メインサーバ１００は、上記状況が発生していると判断する。

【0115】

登録情報によって特定される状況のさらに他の例は、自動車の速度が時速４０キロ以下になったことである。ポーリングクエリに含まれるデータが、自動車の速度が時速６０キロであることを示す場合には、メインサーバ１００は、上記状況が発生していないと判断する。一方、ポーリングクエリに含まれるデータが、自動車の速度が時速３０キロであることを示す場合には、メインサーバ１００は、上記状況が発生していると判断する。

【0116】

ステップＳ１３２にて、メインサーバ１００は、登録情報を利用して問合表現を生成する。

【0117】

ステップＳ１３４にて、メインサーバ１００は、ユーザ端末２００に対して、ステップＳ１３２にて生成された問合表現の出力を指示する。

【0118】

ステップＳ１３６にて、メインサーバ１００は、ストレージ１０３における、上記問合表現を利用してユーザ３００との会話状態を更新する。問合表現に対するユーザ３００の回答が肯定または否定を意味する内容のみであっても、メインサーバ１００は、更新された会話状態を参照することにより、ユーザ３００の回答内容に応じた動作を実施できる。その後、メインサーバ１００は、処理を終了させる。

【0119】

ステップＳ２２０にて、ユーザ端末２００は、ステップＳ１３４の指示を受信する。
ステップＳ２２２にて、ユーザ端末２００は、問合表現を出力し、ステップＳ２０２（図１６）へ制御を戻す。

【0120】

図１６～図１９を参照して説明された処理において、ユーザ端末２００は、定期的に、ステップＳ２１６におけるデータを収集およびステップＳ２１８におけるポーリングクエリの送信を実施する。

【0121】

［８．対話システム１における動作の具体例］
図１６～図１９を参照して説明された処理では、メインサーバ１００は、設定表現を取得し、当該設定表現から取得された登録情報をストレージ１０３に格納する。そして、メインサーバ１００は、上記登録情報の中の条件によって特定される状況が発生すると、ステップＳ１３４にて、ユーザ端末２００に対して、上記登録情報の中のクエリを含む問合表現の出力を指示する。これに応じて、ステップＳ２２２にて、ユーザ端末２００は問合表現を出力する。その後、ユーザ端末２００は、ステップＳ２０２にて、問合表現に対する回答の音声を取得すると、ステップＳ２０４にて、当該音声をメインサーバ１００へ送信する。メインサーバ１００は、ステップＳ１００にて、上記音声を受信し、ステップＳ１３８にて、当該音声に従った動作を実施する。

【0122】

上述の処理によれば、ユーザは、問合表現として出力されることを希望するクエリと、問合表現の出力を希望するタイミングを特定するための条件とを、設定表現としてサーバ装置へ提供することにより、上記条件によって特定される状況が発生したときに、上記クエリを含む問合表現の出力によって、プロアクティブな動作の提供を受けることができる。

【0123】

以下、対話システム１における動作の具体例を説明する。
（動作の第１具体例）
対話システム１における動作の第１具体例として、図６に示された登録情報が格納された場合の動作を説明する。

【0124】

図６の例に従うと、ユーザ端末２００は、ポーリングクエリとして、定期的に、時刻のデータを送信する。メインサーバ１００は、ポーリングクエリに含まれる時刻が午前８時になったかどうかを判断し、午前８時になったと判断すると、ユーザ端末２００に、問合表現の出力を指示する。メインサーバ１００は、ユーザ端末２００に問合表現の出力を指示したことに応じて、ストレージ１０３に、指示した日付を格納してもよい。メインサーバ１００は、ポーリングクエリに含まれる時刻が午前８時になったと判断した場合に、ストレージ１０３にまだ当日の日付が格納されていないことを条件として、ユーザ端末２００に問合表現の出力を指示してもよい。

【0125】

問合表現として、「今日の天気はどうですか、と尋ねたいですか？」が出力される。この問合表現に対してユーザ３００が「はい。」と回答した場合、メインサーバ１００は、この回答に従った動作を実施する。より具体的には、メインサーバ１００は、「はい。」という肯定の回答を受け付けた場合、ステップＳ１３６において格納された会話状態を参照する。会話状態は、たとえば、「Query Text」として登録されたクエリを出力されたことを指し示す情報である。そして、メインサーバ１００は、肯定の回答を受け付けたことに応じて、「Query Text」として登録されたクエリを処理する。すなわち、メインサーバ１００は、クエリ「今日の天気はどうですか？」を処理するために、天気予報用のＡＰＩサーバ８００に、ユーザ３００に関連付けられて登録されている地域の天気予報を問い合わせる。そして、天気予報用のＡＰＩサーバ８００から回答を取得し、当該回答の出力をユーザ端末２００に対して指示する。

【0126】

ユーザ３００が「いいえ。」という否定の回答を受け付けた場合、メインサーバ１００は、「ＯＫ」などの特定のメッセージの出力をユーザ端末２００に対して指示してもよい。

【0127】

ステップＳ１３６において会話状態が格納された後、メインサーバ１００は、上記のようにクエリを処理したこと、または、所与の条件が成立したことに応じて、ストレージ１０３から会話状態を消去してもよい。所与の条件の一例は、会話状態の格納から一定の期間が経過したことである。他の例は、ステップＳ１３６において会話状態が格納された後で、ステップＳ１００において受信された音声が、肯定の回答を表すメッセージ以外のメッセージであることである。

【0128】

以上より、対話システム１は、毎日８時にユーザ３００に対して問合表現「今日の天気はどうですか、と尋ねたいですか？」を出力する。そして、ユーザ３００が「はい。」と回答すると、対話システム１は、ユーザ３００に、天気予報用のＡＰＩサーバ８００からの回答を提供する。

【0129】

（動作の第２具体例）
対話システム１における動作の第２具体例として、図７に示された登録情報が格納された場合の動作を説明する。

【0130】

図７の例に従うと、ユーザ端末２００は、ポーリングクエリとして、定期的に、気温のデータを送信する。一実現例では、ユーザ端末２００は、ユーザ３００に関連付けられた居室の気温を計測する機器と通信することにより、気温のデータを取得する。メインサーバ１００は、ポーリングクエリに含まれる気温が２５℃以上であるかどうかを判断し、２５℃以上であると判断すると、ユーザ端末２００に、問合表現の出力を指示する。メインサーバ１００は、ユーザ端末２００に問合表現の出力を指示したことに応じて、ストレージ１０３に、指示した時刻を格納してもよい。メインサーバ１００は、ポーリングクエリに含まれる気温が２５℃以上であると判断した場合に、ストレージ１０３に格納された時刻から一定期間が経過したことを条件として、ユーザ端末２００に問合表現の出力を指示してもよい。

【0131】

問合表現として、「エアコンをオンにしたいですか？」が出力される。この問合表現に対してユーザ３００が「はい。」と回答した場合、メインサーバ１００は、この回答に従った動作を実施する。より具体的には、メインサーバ１００は、「はい。」という肯定の回答を受け付けた場合、ステップＳ１３６において格納された会話状態を参照する。会話状態は、たとえば、「Query Text」として登録されたクエリを出力されたことを指し示す情報である。そして、メインサーバ１００は、肯定の回答を受け付けたことに応じて、「Query Text」として登録されたクエリを処理する。すなわち、メインサーバ１００は、クエリ「エアコンをオンにしたい」を処理するために、家電制御用の制御サーバ９００に、ユーザ３００に関連付けられて登録されているエアコンのＯＮを指示する。

【0132】

以上より、対話システム１は、ユーザ３００に関連付けられた居室の気温が２５℃以上になると、ユーザ３００に対して問合表現「エアコンをオンにしたいですか？」を出力する。そして、ユーザ３００が「はい。」と回答すると、対話システム１は、制御サーバ９００を利用して、ユーザ３００に関連付けられたエアコンをオンにする。

【0133】

（動作の第３具体例）
対話システム１における動作の第３具体例として、図８に示された登録情報が格納された場合の動作を説明する。

【0134】

図８の例に従うと、ユーザ端末２００は、ポーリングクエリとして、定期的に、自動車の速度のデータを送信する。一実現例では、ユーザ端末２００は、ユーザ３００に関連付けられた車両の速度を計測する機器と通信することにより、自動車の速度のデータを取得する。メインサーバ１００は、ポーリングクエリに含まれる速度が４０ｋｍ／ｈ以下であるかどうかを判断し、４０ｋｍ／ｈ以下であると判断すると、ユーザ端末２００に、問合表現の出力を指示する。

【0135】

問合表現として、「ラジオをオンにしたいですか？」が出力される。この問合表現に対してユーザ３００が「はい。」と回答した場合、メインサーバ１００は、この回答に従った動作を実施する。より具体的には、メインサーバ１００は、「はい。」という肯定の回答を受け付けた場合、ステップＳ１３６において格納された会話状態を参照する。会話状態は、たとえば、「Query Text」として登録されたクエリを出力されたことを指し示す情報である。そして、メインサーバ１００は、肯定の回答を受け付けたことに応じて、「Query Text」として登録されたクエリを処理する。すなわち、メインサーバ１００は、クエリ「ラジオをオンにしたい」を処理するために、自動車制御用の制御サーバ９００に、ユーザ３００に関連付けられて登録されている車両のラジオのＯＮを指示する。

【0136】

以上より、対話システム１は、ユーザ３００に関連付けられた自動車の速度が４０ｋｍ／ｈ以下になると、ユーザ３００に対して問合表現「ラジオをオンにしたいですか？」を出力する。そして、ユーザ３００が「はい。」と回答すると、対話システム１は、制御サーバ９００を利用して、ユーザ３００に関連付けられた自動車のラジオをオンにする。

【0137】

［９．変形例］
上述の実施の形態では、設定表現および問合表現の双方の形態が音声であったが、これらは音声に限定されない。設定表現は、テキストとしてユーザ端末２００に入力されてもよい。この場合、ユーザ端末２００は、入力されたテキストをメインサーバ１００へ送信する。設定表現は、ユーザ端末２００を介することなく、メインサーバ１００へ直接入力されてもよい。また、問合表現も、テキストとして出力されてもよい。

【0138】

上述の実施の形態では、対話システム１は、設定表現を取得する前に、ステップＳ２０２，Ｓ２０４，Ｓ１００，およびＳ１０２において登録用メッセージを認識した後、ステップＳ２０６において催促用メッセージを出力した。なお、ユーザ３００は、登録用メッセージと設定表現とを一連の音声として発話してもよい。対話システム１は、登録用メッセージを認識した後、直後の表現を、設定表現として扱ってもよい。この場合、催促用メッセージの出力は必要とされない。

【0139】

対話システム１では、また、設定表現に対する自然言語解釈によって、設定表現からクエリおよび条件が抽出された。なお、対話システム１は、クエリおよび条件のそれぞれを入力するための複数の欄を有するユーザインターフェースを（たとえばディスプレイ２０２に）表示してもよい。対話システム１は、当該複数の欄のそれぞれにユーザ３００が入力したデータを取得してもよい。これにより、対話システム１は、設定表現に対する自然言語解釈を実施することなく、図６～図８のそれぞれに示されたような登録情報を取得できる。

【0140】

上述の実施の形態において、対話システム１には、２以上のユーザが想定されてもよい。ストレージ１０３において、２以上のユーザのそれぞれに対応する登録情報が、各ユーザに関連付けられて格納されていてもよい。図１６～図１９を参照して説明された処理は、ユーザごとに実施されてもよい。一実現例では、対話システム１において複数のユーザ端末２００が存在し、各ユーザ端末２００はメインサーバ１００に向けて各ユーザのユーザＩＤとともに情報を送信する。メインサーバ１００は、ユーザ端末２００から送信された情報に含まれるユーザＩＤを用いて、処理対象のユーザを識別する。また、メインサーバ１００は、ステップＳ１２０における判断に利用されるリストとして、２以上のリストの中から、ユーザ端末２００から送信されたユーザＩＤに基づいてリストを特定してもよい。

【0141】

今回開示された各実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。また、実施の形態および各変形例において説明された発明は、可能な限り、単独でも、組合わせても、実施することが意図される。

【符号の説明】

【0142】

１ 対話システム、１００ メインサーバ、２００ ユーザ端末、３００ ユーザ、８００ ＡＰＩサーバ、９００ 制御サーバ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】