JP6728125B2

JP6728125B2 - 自然言語バーチャルアシスタントでの全二重発話処理

Info

Publication number: JP6728125B2
Application number: JP2017230590A
Authority: JP
Inventors: スコット・ハルストベット; バーナード・モン−レイノー; カジ・アシフ・ワダッド
Original assignee: サウンドハウンド，インコーポレイテッド
Priority date: 2016-12-22
Filing date: 2017-11-30
Publication date: 2020-07-22
Anticipated expiration: 2037-11-30
Also published as: CN108228131B; US10311875B2; HK1256569A1; KR102192062B1; JP2018106702A; US20180182398A1; CN108228131A; KR20180073493A; US10699713B2; US20190244621A1; EP3340241A1

Description

技術分野
開示された実施形態は、概して、自然言語バーチャルアシスタントにおいて、ユーザの口語入力に対するより直観的な反応を当該ユーザに提供するための、コンピュータによって実現される方法に関する。

分類分野：７０４／２４６
背景
従来のシステムにおいては、人とバーチャルアシスタントまたは他の自然言語処理システムとの間のマン・マシン対話は、厳密な順序交代ポリシーを有する。このようなバーチャルアシスタントは、先行のクエリについてのアシスタントの応答がユーザに完全に通信されるまで、新しいクエリをユーザから受付けない。このように融通性が欠如しているため、結果として、通信が不自然になってしまう。

一実施形態に従った、クエリ処理が行なわれるシステム環境を示す図である。一実施形態に従った、クエリ処理モジュールのコンポーネントを示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。一実施形態に従った、図１のクエリ処理サーバまたはクライアントデバイスの一部またはすべてとして用いられるコンピュータの物理コンポーネントを例示するハイレベルブロック図である。

上記図は、本発明のさまざまな実施形態を例示だけを目的として示している。当業者であれば、この明細書中に例示されている構造および方法についての他の代替的な実施形態が、この明細書中に記載される本発明の原理から逸脱することなく採用され得ることを、以下の記載から容易に認識するだろう。

詳細な説明
図１は、一実施形態に従った、クエリ処理が行なわれるシステム環境を示す。クライアントデバイス１１０のユーザは、動作についての要求（たとえば、「本日の午後７時にカールとの夕食についてカレンダーのアポイントメントを作成する（create a calendar appointment for dinner with Karl at 7 PM today）」）および情報についての要求（たとえば、「ローマでは、明日、どんな天候でしょうか？（what is the weather tomorrow in Rome?）」）を含むユーザ自身の希望を表現するのにスピーチを用いる。

図１に示される実施形態においては、クエリ処理は、ネットワーク１４０上に遠隔に位置するクエリ処理サーバ１００上で行なわれる。しかしながら、他の実施形態においては、クエリ処理はローカルなものであり、たとえばクライアントデバイスにインストールされたバーチャル・アシスタント・アプリケーションの一部として、クライアントデバイス１１０上で直接行なわれる。いくつかの実施形態においては、スピーチは、サーバ１００上で実行される処理がテキストセグメント上で機能している間に、クライアントデバイス１１０上においてローカルにセグメント化されて書き起こされる（transcribed）。いくつかの実施形態においては、サーバ１００はいくつかの物理サーバにわたって分散されている。

クライアントデバイス１１０は、コンピューティングデバイスであって、たとえば、スマートフォン、タブレット、ラップトップコンピュータもしくはデスクトップコンピュータなど、またはスマート機器もしくは他のデバイス（たとえばデータ処理能力を備えた車もしくはコーヒーメーカー）など、または、自然言語クエリを入力することができるとともにクエリに応答を出力することができる他の任意のデバイスなどである。クライアントデバイス１１０は、音声を取込んでデジタルオーディオデータに変換するマイクロホンおよびＡ／Ｄ変換器などの音声入力装置１１２と、デジタルオーディオデータを対応する可聴出力に変換するＤ／Ａ変換器およびスピーカなどの音声出力装置１１３とを有する。

（図１に示されるようなネットワークが用いられている実施形態における）ネットワーク１４０は、データ伝送のための如何なる好適な通信ネットワークであってもよい。図１に例示されるような一実施形態においては、ネットワーク１４０は、標準的な通信技術および／またはプロトコルを用いており、インターネットを含み得る。別の実施形態においては、エンティティは特定用途向けのおよび／または専用のデータ通信技術を用いる。

クエリ処理サーバ１００およびクライアントデバイス１１０のシステムは、異なる実施形態においてさまざまな形態のハードウェアで実現され得る。すべての実施形態においては、クエリ処理論理は、この明細書中にさらに記載されるように、コンピュータによって実現されるアルゴリズムのセットである。最後に、以下の説明から明らかになるように、この明細書中に記載されるアルゴリズムおよびプロセスは、コンピュータシステム上で実現される必要があり、如何なる有用な実施形態においても、人による知的ステップを用いて実行することができない。

いくつかの実施形態は、クエリを形成して実行するために、クライアントデバイスを用いて発話（utterance）を取込み、サーバを用いて発話を処理する。いくつかの実施形態は、単一のデバイスにおいて取込みおよび処理を実行する。

図２は、一実施形態に従った、クエリ処理モジュール１５０のコンポーネントを示す。入力モジュール２１０は、デジタルオーディオストリームを入力として受取る。オーディオストリームは、音声入力装置１１２によって取込まれ、ユーザが話したクエリを表現し得る。「発話」はスピーチの連続セグメントである。入力モジュール２１０は入力されたオーディオを発話にセグメント化する。これを行なうために、入力モジュール２１０は、スピーチにおける一時的な停止を識別することに基づいて、または非スピーチオーディオに基づいて、または、ユーザがジェスチャ（スワイプする、ボタンを押す）もしくは他の手段を実行するなどのＵＩイベントに基づいて、各々の発話についての始まりおよび終わりを検出する。たとえば、特定のユーザが「明日、どんな天候でしょうか」と述べ、暫くの間（たとえば５００ミリ秒）一時停止し、次いで、「ローマでは」と続ける場合、スピーチ入力は、５００ミリ秒の非スピーチ部分によって分離される２つの別個の発話を含む。

図２の実施形態においては、入力モジュール２１０が発話ストリームを出力する。発話ストリームにおける各々の発話は、処理モジュール２２０によって順々に処理される。処理モジュール２２０における第１のステップは自然言語パーサ２２２を用いて解析することである。この開示においては、「解析する（parse）」「パーサ（parser）」および「解析すること（parsing）」という語は、クエリの構文を自然言語文法と照合する狭い意味で用いられるのではなく、その形式および意味の両方の観点からクエリを「認識する」というより広い意味で用いられる。このため、パーサ２２２は、意味論的パーサであって、その機能はクエリを認識することである。クエリ認識２２２は、成功した場合には、クエリの意味を表現する構造を含む。クエリの認識によりこの表現が構築され、クエリキュー２４４に追加される。

パーサ２２２はまた、構文上誤って形成されているかまたは意味論的に無意味であるクエリを拒否する。解析の試みの失敗は、さまざまな方法でさまざまなシステムによって処理される。場合によっては、エラーメッセージが応答としてユーザに送信される。他の場合には、応答が与えられない。いずれにしても、後で実行されるクエリキュー２４４にはクエリは追加されない。

処理モジュール２２０の増分的な実施形態においては、連続的な発話は、それら発話が入力モジュールから入手可能になると直ちに解析され、入力ストリームにおいて常に処理が進められる。このような実施形態においては、パーサ２２２は増分的なパーサである。増分解析のためのアルゴリズムは当業者にとって公知である。増分解析のコンテキストにおいては、「解析する」とは、クエリを行なう完全な解析とは対照的に、部分的に完了した解析を広く意味している。増分的なパーサは、入力トークンが入力ストリームから追加されるたびに（部分的な）解析を更新することにより、入力ストリームのうち実現可能なすべての解析（または十分に実現される可能性のある解析）を並列に維持する。クエリは、構文的な観点および意味論的な観点の両方から、部分的な解析のいずれかが完全な解析になると直ちに認識される。これが起こると、増分的なパーサは対応するクエリデータ構造を出力し、これをクエリキュー２４４に追加する。この時点で、パーサは、現在の解析状態から入力ストリームの処理を再開する。解析の状態は、ストリームにおけるその位置および方向と、すべての並列な部分的解析の状態とを含む。

いくつかの実施形態においては、クエリを認識するには、クエリの終端に発話の終わりの境界が存在していることが必要となる。他の実施形態においては、クエリ認識は、クエリを完了させるのに発話の終わりの境界を必要としない。後者の実施形態においては、発話ストリームから「明日、どんな天候でしょうか」を受取った後、増分的なパーサ２２２は第１のクエリ「どんな天候でしょうか」を認識することができ、解析の状態を維持しつつ、これをクエリキュー２４４に追加する。次に、「明日、どんな天候でしょうか」が第２のクエリとして認識される。（発話の終わりが必要とされる実施形態においては、第２のクエリだけが認識されるだろう。）パーサの増分的な性質により、当該パーサは、「明日、どんな天候でしょうか」という入力中の１つのクエリまたは２つのクエリを認識するために、「どんな天候でしょうか」と「明日」との間における一時停止期間などのセグメント化要因に対して高い感度を得ることができる。「ローマでは、明日、どんな天候でしょうか」（「ローマでは」の後に「明日、どんな天候でしょうか」が続いている）という拡張された入力は、追加のクエリをもたらす。この場合、３つの連続したクエリが認識され得る。

非増分的なパーサを用いる実施形態においては、同様の出力が何らかの追加処理を犠牲にして達成される。実際には、非増分的なパーサは新しい発話が連結されているとき再開される。（この開示においては、オーディオセグメントの連結を示すためにオペレータ「＋」が用いられる。）たとえば、発話Ｕ１がスピーチセグメント「どんな天候でしょうか」であり、Ｕ２が「明日」であり、Ｕ３が「ローマでは」である場合、非増分的なパーサは、３つの発話Ｕ１、Ｕ１＋Ｕ２およびＵ１＋Ｕ２＋Ｕ３の各々を入力として得るために順番に（コールドスタートから）再開させなければならない。いくつかの実施形態においては、複雑さが追加されるものの、増分的な実施形態と同様のクエリ認識能力を提供する、提示された技術の非増分的な実施形態が実現可能である。

共有のクエリ認識能力は以下のとおりである。発話のストリーム｛Ｕｉ，ｉ＝０〜Ｎ｝を入力として想定すると、パーサ２２２は（増分的であろうとなかろうと）、クエリのストリーム｛Ｑｋ，ｋ＝０〜Ｍ｝を生成することができる。この場合、クエリＱｋは、発話Ｕｉから、または発話の連結Ｕｉ＋…＋Ｕｊから認識される。

いくつかの実施形態においては、入力モジュール２１０は、自動音声認識（automatic speech recognition：ＡＳＲ）を実行し、識別されたすべての発話からテキストセグメントを書き起こし、これが入力としてパーサ２２２に提示される。この場合、パーサ２２２によって入力として受取られたストリームは、オーディオセグメントからではなく、テキストセグメントまたは場合によっては単語から作成されている。パーサ２２２はこれに従って動作する。このため、当業者であれば、このように機能するようにクエリ処理モジュール１５０を容易に適合させ得るだろう。

パーサ２２２がクエリの認識に成功すると、パーサ２２２は、実施可能なデータ構造として表現されておりクエリの意味を顕著に含むクエリデータ構造を出力として作成する。クエリデータ構造は、クエリの意味を後の実行に適した形式で符号化するだけではなく、パーサ２２２によって生成されるとともに実行以外の目的のために有用ないずれの追加データも符号化する。便宜上、「クエリを実行する」という句は、「クエリデータ構造を実行する」ことを表すか、または代替的には、「クエリの実施可能な意味を実行する」ことを表すだろう。たとえば、「明日、どんな天候でしょうか」というクエリに応答して、パーサ２２２は、「どんな天候でしょうか」という核心となる質問を符号化するクエリデータ構造と、「明日」という修飾子を含む修飾子リストとを出力する。これは、現在のコンテキストにおける「明日」（ｔｉｍｅ＿１）の値に設定されたフィールド「時（ｗｈｅｎ）」と、都市名および経緯度の対（ｌａｔ＿ｌｏｎｇ＿１）などの現在の位置にデフォルトで設定されたフィールド「場所（ｗｈｅｒｅ）」とを備えたタイプ「天候クエリ」のクエリデータ構造を作成する。クエリに応答するために、このコマンドデータ構造は、ウェブベースの天候サービスにアクセスする手続き呼出しＷＥＡＴＨＥＲ＿ＤＡＴＡ（ｌａｔ＿ｌｏｎｇ＿１，ｔｉｍｅ＿１）によって実行され得る。

いくつかのクエリを実行することは、動作を実行すること（たとえば、特定の人との特定の時間にわたるカレンダーのアポイントメントを作成すること）または情報を調べることを含む。たとえば、天候クエリを実行することによって、ウェブベースの天候サービスにアクセスされる。上述のシナリオ例においては、天候サービスは、明日の天候を「所により曇り、高くて８０低くて６０」というテキスト形式の記載として記述して、関連する画像を構築する。いくつかの実施形態においては、実行モジュール２２４によるクエリの履行がクエリ処理モジュール１５０と同じシステム上で実行される。いくつかの実施形態においては、クエリを履行するには、サービスＡＰＩモジュール２４１を介するリモートサービス（たとえばフライト予約システム）への呼出しが必要となる。

クエリの履行は、場合によっては、かなりの時間を必要とする可能性がある。この場合、クエリを並列に処理することが望ましい。処理モジュール２２０は、実行モジュール２２４の複数のインスタンスを用いることにより、複数のクエリを並列に実行することをサポートする。当然、Ｑ２の処理の開始前にＱ１が応答されていた場合、Ｑ１およびＱ２という２つのクエリを並列に実行するための機会はない。クエリが存在する場合（これはパーサ２２２によって認識されたものであり、対応するクエリデータ構造が作成されている）、そのクエリは「アクティブ」と称され、その実行モジュールは完全ではなくなる。実行が完了すると、結果クエリ２３４に登録される結果記録が生成される。並列実行のための候補は、同時にアクティブとなるクエリである。クエリが同時にアクティブになると、それらクエリの並列実行を許可する決定がクエリシリアライザモジュール２４３によって行なわれる。

クエリの実行は、ユーザに対して表示される応答を生成し得る。たとえば、情報についての要求（たとえば、「明日、どんな天候でしょうか」）は、本質的にユーザに対する応答を要求する。いくつかの実施形態においては、すべてのクエリは、結果として、応答をもたらす（たとえば、動作について要求はまた、動作が成功したか否かを示す応答を生成する）。図２の実施形態においては、これが２段階で発生する。最初に、実行モジュール２２４のインスタンスによってクエリが実行されると、結果記録が出力として作成される。第二に、出力マネージャ２３０が、結果キュー２３４からの結果記録に基づいて、ユーザに提示されるべき実際の応答を作成する。図２の実施形態においては、実行モジュール２２４のインスタンスによって作成される結果記録は、結果キュー２３４に入力され、出力マネージャ２３０が結果キュー２３４から結果記録を引出す。結果キュー２３４は、プロセス間通信キューであって、生成された結果記録のために並列−直列変換を実行する。

出力マネージャ２３０はユーザに応答データ（仮に存在していれば）を出力する。いくつかの実施形態においては、応答がそれを介して最終的にユーザに与えられるだろうクライアントデバイス１１０の能力またはデータの性質に応じて、応答データがさまざまな形式で出力される。たとえば、出力マネージャ２３０は、応答を口語形式で（たとえばテキスト−スピーチ間のアルゴリズムによって）出力させ得るか、または、（クライアントデバイス１１０がビジュアルユーザインターフェイス能力を有すると想定して）視覚的形式で出力させ得る。さらに、各々のコンポーネントはさまざまな環境下で用いられるように、短い形態および長い形態を有してもよい。出力マネージャ２３０はまた、応答が表示される順序を決定し得る。

サービスＡＰＩモジュール２４１は、ネットワークベースのサービスについてのＡＰＩ要求を用いて、特定のクエリの実行をサポートする論理を含んでいる。たとえば、「明日、どんな天候でしょうか？」というクエリは、第三者のウェブベースの天候サービスにアクセスすることによって実行される。サービスＡＰＩモジュール２４１は、特定の天候特徴（たとえば、＆ｔｉｍｅ＝ｔｏｍｏｒｒｏｗ）を表現するパラメータを含むＵＲＬに対してクエリをマッピングし得る。いくつかの実施形態においては、利用可能性および価格を含む理由から、天候サービスの１つのプロバイダに対して別のプロバイダ（one provider of weather services, ＼vs. another）、などの同様の機能を備えた競合するサービス同士の間で選択がなされる。

図２に示される実施形態においては、クエリがクエリキュー２４４に格納される。クエリは、これらクエリがパーサ２２２によって作成されると直ちにクエリキュー２４４に登録される。クエリシリアライザモジュール２４３は、どのクエリが並列で実行され得るかと、どのクエリが並列で実行され得ないかとを判断する。これについては後に説明する。クエリは、実行モジュール２２４による当該クエリの実行が完了すると、キュー２４４から削除される。クエリの実行は、対応する結果記録が結果キュー２３４に追加された時に完了する。結果キュー２３４は出力マネージャ２３０によって処理される。

一実施形態においては、クエリの並列実行が最大限にまで許可される。このような実施形態においては、処理モジュール２２０が、実行モジュール２２４の複数のインスタンスを実行することによってクエリを並列に実行する。２つのクエリは、可能であれば非同期的に実行され得る。すなわち、（１）２つのクエリがともに同時にアクティブであり（クエリキュー２４４がアクティブなクエリをすべて含んでいる）、（２）２つのクエリの並列実行を防ぐための直列の制約がない。クエリシリアライザモジュール２４３は、以下に記載されるように、アクティブなクエリ間における直列の制約の存在を判断する。これらの定義は、いくつかのアクティブなクエリの並列実行をサポートする。すべてのアクティブなクエリ間における直列の制約が判断された後では、（どのクエリが即時実行されるのに適しているかを判断する）順番付けの選択が単純になる。すなわち、先行のクエリに対する直列依存性を持たないクエリはいずれも実行するのに適している。たとえば、キューにおいてクエリＱ１、Ｑ２およびＱ３がアクティブであると想定し、直列の制約がＱ１がＱ３の前に処理されるべきであると規定しているとする。他に直列の制約は存在しない。この場合、（入力の制約を持たない）クエリＱ１およびＱ２は並列実行に適している。Ｑ３は、Ｑ１がその実行を完了するまで実行することができない。Ｑ１が終了すれば、Ｑ３は実行可能となる。Ｑ２がその時点において依然としてアクティブであれば、Ｑ３はＱ２と並列に実行されることとなる。いくつかの実施形態においては、並列性が最大限まで実施されるのを防ぐリソース制限などの他の要因によって、クエリの実行中における並列の度合いが制限される。

並列実行は多くの方法で実現することができる。一実施形態においては、複数のコンピュータを用いて、クエリストリームからのクエリを実行するために必要な並列性をサポートする。これは計算上のリソースの多用につながる。一実施形態においては、（Ｌｉｎｕｘ（登録商標）ＯＳの意味での）複数の「プロセス」が、クエリ処理において並列性をサポートするのに用いられる。一実施形態においては、（同様に、ＬｉｎｕｘＯＳの意味での）マルチスレッドプロセスが、並列性を可能にするために複数のスレッドをサポートする（軽量処理とも称される）。別の実施形態においては、並列性は、協調的なスケジューリングによって、スレッド、中断またはタイマ無しで、適切にシミュレートされる。協調的なスケジューラにおいては、タスクは（一旦アクティブにされると）、それが制御を自発的に戻すまで実行されることが許可される。協調的なスケジューリングアプローチは、適用可能であれば、低オーバヘッドという利点を有する。これはハードウェアサポートを必要とせず、小規模な組込み型システムにおいて用いることができるが、クエリ実行は、通常、複雑すぎるので、スレッドレス・スケジューラには適していない。

クエリシリアライザモジュール２４３は、２つのクエリＱ１およびＱ２が、処理モジュール２２０がクエリを処理するべき相対的順序を決定する依存関係性（直列の制約）を有するかどうかを判断する役割を果たす。クエリシリアライザモジュール２４３が、たとえば、Ｑ２の前にＱ１を実行しなければならないと判断しない限り、アクティブな２つのクエリＱ１およびＱ２は並列で実行されることが可能となるだろう。

クエリシリアライザ２４３は、その名前が示しているように、発話に対してではなくクエリに対する直列の制約についての認識を実行する。これは、発話が未翻訳のスピーチセグメントであるからである。このため、クエリと認識されるまで、発話は、直列の制約をもたらしてしまう依存関係性の検出を可能にすることができない。さらに、あたかも対応するクエリと認識されているかのように発話を参照することは好都合であり、この規定は以下のとおり採用されている。たとえば、（引用されたテキストがスピーチのセグメントを表わしている場合）「どんな天候でしょうか」という発話と、（引用された同じテキストが解析されて翻訳されたクエリを表わしている場合）「どんな天候でしょうか」というクエリとを同じように参照することは（技術的には不正確であるが）直観的である。この定義を用いれば、（１）Ｕ_１がクエリＱ１と認識され、かつ、（２）２つの連続した発話の連結Ｕ_１＋Ｕ_２がクエリＱ２と認識された場合、発話Ｕ_２がＵ_１の「続き」であると言明することは利便的であるだろう。この定義に従うと、「ローマでは」という発話は、「明日は、どんな天候でしょうか」という発話の続きとなる。なぜなら、大多数の文法に従うと、「ローマでは、明日、どんな天候でしょうか？」という連結された発話がクエリとして認識され得るからである。対照的に、「２％の利率では（at a 2% interest rate）という発話は、「明日、どんな天候でしょうか」という発話の続きではない。なぜなら、「２％の利率では、明日、どんな天候でしょうか」という発話は、大抵の文法ではクエリとして認識することができないからである。

クエリシリアライザ２４３による直列の制約の検出は、以下に説明されるように、主として論理依存性によって左右されるが、（計算上のコスト、処理遅延またはＡＰＩにアクセスするコストなどの）実用性を検討することも同様の役割を果たす。「ローマでは、どんな天候でしょうか」というクエリは、「どんな天候でしょうか」（局所的な天候についての質問）というクエリと並列に実行可能である。なぜなら、これは、ローマにおける天候が（世界の他のいずれかの地域における）局所的な天候とは無関係であることを適正に推測するからであり、かつ、ローマにいるのであれば、局所的な天候を含む２つのクエリが連続して発行されれば、これは予想外の驚くべきこととなり得るからである。ローマにおける天候と局所的な天候とが論理依存性を有していないと推測する（かまたは地理的距離を調べることによって確認する）と、これらは並列に実行することができる。

直列の制約についての認識の別の例として、「私のホテルの近くで中華料理店を見つける（Find Chinese restaurants near my hotel）」という発話の後に「そして、格付けによって分類してください（and sort them by rating）」と続く発話について検討する。この例においては、第２の発話は第１の発話の続きであるが、先行の例とは異なり、第２のクエリに対する回答は、第１のクエリに対する回答に基づいたものとして最もよく見られるものであり、したがって、直列の制約が検出されて、並列実行が防止される。（「私のホテルの近くで中華料理店を見つける」および「私のホテルの近くで中華料理店を見つけ、そして、格付けによって分類してください」という２つのクエリを並列に実行することは可能であるが、計算上それほど効率的ではない。）
一実施形態においては、クエリシリアライザ２４３は、パーサ２２２と密に一体化されており、クエリ認識中にパーサの状態に基づいて順序付け依存性がクエリＱ１とクエリＱ２との間に存在しているかどうかを判断する。先行の例は、Ｑ２が修飾子（「そして、格付けによって分類してください」）を情報探索クエリ（「私のホテルの近くで中華料理店を見つける」）に追加するたびに、クエリＱ２に対する応答が先行のクエリＱ１に対する応答に依存し得ることを示している。別の例として、「四つ星付き（with four stars）」という発話は、「ダウンタウンのサンホセにあるホテルを私に教えてください（Show me hotels in downtown San Jose）」という先行の発話の続きであり、かつ、この発話に対する修飾子として、ダウンタウンのサンホセにあり４つ星の格付けを有するホテルのサブセットを選択するという役割を果たす。

いくつかの実施形態においては、新しいクエリが先行の対話のコンテキストに依存しているとクエリシリアライザ２４３が判断すると、順序付けの制約が検出される。これは、新しいクエリが（上述のホテルの例におけるように）先行のクエリ、またはより広範には、最近のクエリに対する回答に依存している場合、起こる可能性がある。結果依存性の別の例は、「シカゴでは、気温は何度ですか？（what is the temperature in Chicago?）」の後に「ニューヨークよりも寒いですか？（is it colder in New York?）」が続くクエリである。この場合、「よりも寒い（colder）」という句は、暗黙的に先行の気温を指しており、先行の対話において言及されているものを見つけ出すことが期待されている。ここで、先行の気温は、第１のクエリが実行されるまで未知である。これは、論理（すなわちデータフロー）依存性であって、結果として、クエリ間に直列の制約をもたらして、並列実行を防止する。

一実施形態においては、依存性の照合は、会話状態（先行の対話から選択された情報を保持するデータ構造）の表現を維持して当該表現にアクセスすることに基づいている。いくつかのクエリは、会話状態に依存しているが、これは直列の制約を示唆するものではない。新しいクエリが最近のクエリに依存しているがそれに対する回答には依存していない場合、直列依存は存在しない可能性がある。たとえば、「そこでの天候はどうですか？（How is the weather there?）」などの未解決のクエリの意味を判断するために、そこでの位置が何を表わしているかを知る必要がある。同一指示の解決技術はこの問題に対応している。位置情報が無いことは、直列制約についての根拠ともなり得るが根拠にならないこともある。たとえば、「私に、土曜日のニューヨークへのフライトを見つけてください（Find me a flight to New York on Saturday）」と言った後に「そこでの天候はどうですか？」と続けた場合、直列の制約は存在しない。なぜなら、第２のクエリを解析するときに以前の対話データ（会話状態）を用いて、位置を決定することができるからである。逆に、「オバマ大統領が生まれたのはどの町でしょう（What town was President Obama born in）」と言った後に「そこでの天候はどうですか？」と続けた場合、直列の制約が存在している。なぜなら、第１のクエリを実行することによって、必要とされる位置だけを決定することができるからである。

「仮に利率が４％だったらどうでしょうか？（what if the interest rate is 4%?）」などの意味論的に不完全な別のクエリに応答するために、或る実施形態は、利率の使用を含む先行のクエリについての最近の対話を調べて、特定の利率に依存する（抵当権計算などにおいて）事前に用いられている式を見出し得る。次いで、この式が、以前の利率の代わりに４％の利率で再評価され得る。このような場合、直列の制約は存在しない。より概略的に説明すれば、結果を取得するためにクエリ実行が必要となることとは対照的に、（たとえば、結果が会話状態内にあるかまたは先行のクエリのキャッシュされた結果内にあるので）最近の対話に関する不十分なクエリの依存性を認識時間で処理することができる場合、直列の制約は存在せず、クエリ実行時間に並列性が可能となる。

クエリの認識は、クエリの実行が先行のクエリの実行に依存しているかどうかを確実に判断することができる。このことは、共有された値によって起こるものである。「そこでの天候はどうですか？」というクエリへの回答がなされた後、回答の一部として温度が予想される。「摂氏何度ですか？（what is that in Celsius?）」という後続のクエリは、先行の天候クエリの回答から温度値を用いることを必要としており、対応するクエリ間において直列の制約をもたらす。

並列−直列の変換は結果キュー２３４によって達成される。キューは、実行モジュール２２４の並列なインスタンスから非同期的に結果記録を受取り、シングルスレッドの出力マネージャ２３０がキューを連続的に処理する。結果キュー２３４におけるエントリ（結果記録）は複雑になる可能性があり、複数のマルチメディアコンポーネント、たとえば、画面上に表示される短いテキスト応答または長いテキスト応答；クライアントのテキスト−スピーチ間（text-to-speech：ＴＴＳ）ソフトウェアを用いてテキストをスピーチオーディオに変換するための、ＴＴＳマークアップ付きの短いテキスト応答またはＴＴＳマークアップ付きの長いテキスト応答；サーバのＴＴＳソフトウェアを用いて既にテキストからオーディオに変換されていた短いスピーチ応答または長いスピーチ応答；などを含み得る。さらに、ピュアオーディオセグメントまたは音楽セグメント、オーディオ有りまたはオーディオ無しのビデオセグメント、グラフィック要素、アニメーション、および、このようなすべてのコンポーネントの視覚的または聴覚的表示についてのメタデータをも含み得る。加えて、結果記録エントリが伝達し得るスクリプト、ルールまたは制約は、出力マネージャ２３０によって結果記録が好ましく使用されることに適用される。

以下は、出力マネージャ２３０のさまざまな実施形態についてのより詳細な説明である。結果記録は、複数のコンテンツコンポーネント、たとえば、印刷すべきテキスト、ＴＴＳモジュールによってオーディオに変換すべきマークアップ付きテキスト、再生されるべき記録済みオーディオ；再生されるべき静止画像、アニメーションまたは映像を含む表示用の視覚的要素；および、ＵＲＬなどの外部からの参照によってアクセス可能な一般的に任意のマルチメディアコンテンツ；などを含み得る。結果記録はまた、特定の環境下でマルチメディアデータのうちどの部分を表示しなければならないかについての詳細を含み得る。いくつかの実施形態においては、出力マネージャ２３０は、ユーザが見るかまたは聞く特定のマルチメディアコンテンツを選択する。いくつかの実施形態においては、クライアントデバイスには選択肢が全体的または部分的に残されている。

出力マネージャ２３０は、主として、コンテンツの表示の順序に関する役割を担っている。クエリを並列に処理すると、結果記録は元のクエリ順序とは異なる順序で結果キュー２３４によって受取られる。いくつかの実施形態においては、制約は、ユーザにマルチメディアコンテンツを送達する順序またはタイミングを制約するように結果記録によって特定される。出力マネージャ２３０は、特にイベントの順番付けおよび画面空間の管理の観点から、ユーザの視聴覚出力デバイスを制御する。

出力マネージャ２３０は、いずれかの一人のユーザのためにシングルスレッドである。これは、ユーザの経験により、結果として、制御された時間順序がもたらされることを確実にする。結果記録は非同期的に取得されるが、結果キュー２３４はそれらをシリアライズする。出力マネージャ２３０は、次いで、結果キュー２３４を読出すことにより、アクティブな結果のシーケンス全体にアクセスすることができる。これは、特に、出力マネージャ２３０が結果キュー２３４から結果記録をキューの順序で引出す必要がないことを意味している。

結果キュー２３４のいくつかの実施形態は共有メモリを用いて、結果記録自体を格納し、さらに、共有される結果記録に対するポインタを単にプロセス間キューに格納するだけである。プロセス間キューを実現するさまざまな方法が当業者に公知である。いくつかの実施形態はポインタおよびリンクに基づいている。いくつかの実施形態は、先頭インデックスおよび末尾インデックスを備えた円形の配列を用いる。これが実現可能となるのは、キュー要素が一定の要素サイズを有している（結果記録は一般にさまざまなサイズを有しているが、それら結果記録に対するポインタは一定のサイズを有する）場合であって、かつ、キューが、典型的には妥当である一定の最大サイズを有している場合である。なぜなら、大抵の応用例にとってはわずかな並列性だけで十分であるからである。円形配列の実施形態においては、出力マネージャ２３０は、スケジューリング選択をより適切に通知するために、キューの先頭以外の要素をピークすることができる。

出力マネージャ２３０はスケジューリングの制約を考慮に入れる。このような制約はグローバルデフォルトによって公知であり得る。たとえば、出力オーディオセグメントは、特に指定のない限り、時間が重複していない可能性がある。非重複のルールは、ＴＴＳからのオーディオと、音楽オーディオまたは他の記録されたオーディオとの両方にデフォルトで適用される。しかしながら、（ソフトバックグラウンドミュージックまたは特殊目的の音声などの）何らかのオーディオは、このルールから外されてもよく、フォアグラウンドオーディオの再生中に再生されてもよい。いくつかの実施形態においては、デフォルト制約以外の制約がマルチメディア結果記録の一部として指定される。（非重複のルールに準拠しない）バックグラウンドオーディオの特異点が結果記録において指定され得る。

スケジューリング制約は２つのタイプのイベント（すなわち、同時発生的イベントと連続的イベントと）を区別し得る。頻繁に起こるタイプの制約はイベント間の時間的関係である。「時間同時性」という制約は、特定の時点（同時発生的イベント、または連続的イベントの始まりもしくは終わり）が（イベントへの参照によって同様に定義される）別の時点と同期的にスケジューリングされるべきであることを示している。「優先順位」の制約は、イベントが別のイベントの前（または後）にスケジューリングされなければならないことを示している。連続的イベントは時間範囲を有する。制約は、連続的イベントがいくつかの条件下で、中断可能であるかまたは中断不可能であることを示し得る。制約は、連続的イベントが他のイベントと部分的に重複され得る条件を示し得る。たとえば、ＴＴＳオーディオセグメントに関連付けられたデフォルト制約は、別の任意の可聴イベントが相対的な音の大きさについての何らかの適切な定義に従って比較的静かに再生されるバックグラウンドミュージックでない限り、ＴＴＳオーディオセグメントが上記可聴イベントと重複し得ないことである。連続的イベントは以下を含む：
・オーディオ（または音楽）セグメントの再生。

・ビデオセグメントの再生。
・ＴＴＳオーディオセグメントの再生。

・表示画面上に視覚的要素（テキスト、グラフィックまたはアニメーション）を視覚可能に維持。

同時発生的イベントは同時発生性の制約および先行性の制約に従う。これらは以下を含む：
・オーディオ（または音楽）セグメントの開始［または終了］。

・ビデオセグメントの開始［または終了］。
・ＴＴＳオーディオセグメントの開始［または終了］。

・画面の一部上における何らかのテキストの出現［または消失］。
・画面の一部上における何らかのグラフィックの出現［または消失］。

・画面の一部上における何らかのアニメーションの出現［または消失］。
・特定の視覚的要素の画面からのスクロールオフ。

・上述のイベントのうちいずれかのＮ秒前またはＮ秒後の時点。
出力マネージャ２３０に与えられる制約のセットは過剰判断され得るかまたは過少判断され得る。制約のセットを処理して過剰判断された制約のセットを検出するために、出力マネージャ２３０は、以下のステップシーケンスなどの単純な手順に依拠し得る。

１）イベントを同時発生性の制約に従って同期グループにパーティショニングする。
２）イベント間の既存の先行性の制約を同期グループ間の対応する先行性の制約にマッピングする。

ａ）同期グループが別の同期グループの前および後の両方に存在しなければならない場合、グループをマージする；さらなる変更が不可能になるまでこのステップを繰返す。

３）スケジューリングの矛盾が依然として存在する場合、以下の戦略のうち１つ以上が用いられてもよい（戦略の順序および利用可能性は動作モードに依存している）。

ａ）視覚的アイコンを用いて、ユーザがオーディオセグメントの再生を制御することを可能にする（これについて以下にさらに述べる）。

ｂ）２つのオーディオセグメントが非重複テストに失敗した場合、対応するクエリと同じ順序でオーディオセグメントを再生するためのより単純なアプローチに戻るために少なくとも１つの制約を削除する。

ｃ）中断可能なオーディオセグメントをチェックし、トリミングを用いる。
スケジュールを決定するための十分な制約が結果記録から得られない場合、出力マネージャ２３０は、スケジュールを完成させるためにそれ自体の制約をさらに追加するだろう。これを行なう場合、典型的にはデフォルト戦略に依拠する。それとは逆の反対の制約が無い場合、（ＴＴＳからのオーディオを含む）オーディオセグメントはキューにおける結果記録の順序で再生される。これはデフォルト戦略である。この順序は、必ずしもクエリの元々の順序と同じであるとは限らない。後者の場合、出力マネージャ２３０は、元々の順序付けを保存しようと試みて、短時間だけ待った後、キューをピークしてもよい。

視覚的表示を管理するために、出力マネージャ２３０が使用可能な１つの戦略は、視覚的要素（テキストまたはグラフィック）を別の要素に置換えることである。この場合、タイミング制約を用いることにより、ユーザが表示を読取るのに十分な時間を得ることができる。別の戦略はスクロールすることである。これはディスプレイ装置がスクロール区域を有する場合に適用可能である。ディスプレイ装置は複数の区域に分割されていてもよく、その各々は、スクロールするものとして指定されてもよく、またはスクロールしないものとして指定されてもよい。いくつかの実施形態においては、スクロール区域が上方または下方にスクロール移動する。いくつかの実施形態においては、スクロール区域が左方または右方にスクロール移動する。視覚的要素を表示するようにとの要求が対象とする特定の地域は、スクロール移動してもよいしまたはスクロール移動しなくてもよい。いずれの場合も、要求は、その区域が表示前にクリアされることを必要とする可能性がある。

いくつかの実施形態においては、スクロールすることにより、スクロール区域の上部（または下部）において視覚的要素を追加し、新しい要素のための空間を設けるのに必要とされる限り遠くまで他の視覚的要素を移動させる。スクロール区域がフルになると、視覚的要素がスクロールされてその区域から外れてしまい、もはや視認することができなくなる。（スクロールする方向、またはフルになったときにその区域がクリアされているか否かなどのスクロール方法に関する選択が、いくつかの実施形態においては全体的に行なわれ、いくつかの実施形態においてはクエリ特有の制約によって推進される。スクロールの主な２つの変形例はスクロールされたデータの保持に応じて異なる。すなわち、「忘れる（forgetting）変形例においては、画面外に出て行ったデータは内部メモリからクリアされており、検索することができない。「記憶する（remembering）」変形例においては、画面からスクロールされて外れてしまった視覚的材料がバッファに格納され、スワイプまたは他の手段によって視界の中にスクロールして戻すことができる。いくつかの「記憶する」実施形態においては、バッファリング量の規定が制約されており、バッファデータをクリアするための環境も制約されている。

上述のとおり、オーディオセグメントは出力マネージャ２３０によって（オーディオセグメントの順序が応答としてそれらを引出したクエリの順序と一致するかどうか）決定された特定の順位で再生されるが、オーディオセグメントは、ユーザによって指定されない順序で一回だけ再生される。代替的な実施例は、オーディオセグメントに永続的アクセスを提供して、ユーザが「永続的な」オーディオセグメントを０回以上再生することを可能にする。永続的と指定されたオーディオセグメントのために、出力マネージャ２３０は、オーディオセグメントに関連付けられた視覚的ＧＵＩ要素を追加する。視覚的要素は画面等のうちクリック可能またはタップ可能な区域である。視覚的要素をクリックするかタップすることにより、ユーザは、対応するオーディオセグメントの再生をトリガすることができる。これは、オーディオが中断された場合または順序がばらばらに再生される場合に特に有用である。いくつかの実施形態においては、このような視覚的要素が、出力マネージャ２３０の動作モードに従って、忘れるタイプまたは記憶するタイプのスクロール区域において表示される。このようなモードは、各々のマルチメディア要素タイプ（テキスト、オーディオ、映像、静的グラフィック、アニメーション）に対応するデフォルトによって、または特定のクエリに対する結果記録に付与された制約によって、または、これら両方の組合せによって推進され得る。いくつかの実施形態においては、対応するＧＵＩ要素がタップされる場合には、オーディオセグメントまたはビデオセグメントが再生されるだけである。これは、より多くの詳細を得るためのオプションをユーザに与えるために、書面テキストまたはＴＴＳオーディオなどの短い応答が既に与えられた後には有用である。

図３〜図１０は、さまざまな実施形態に従った、異なるシナリオでの時間の経過に伴うユーザスピーチの処理を示す図である。時間が水平軸に沿って示されており、さまざまな動作（リスニング、ユーザスピーチ、実行および応答）が垂直軸のさまざまな部分に示されている。「リスニング」動作は、発話ストリームに新しいスピーチ発話として含めるために入力オーディオデータを受取ってセグメント化する図２の入力モジュール２１０を表わしている。「ユーザスピーチ」動作は、クライアントデバイス１１０に口語入力を提供することによって発話ストリーム入力データを作成するユーザを表わしている。「処理」動作は、図２の処理モジュール２２０の処理（認識２２２および実行２２４）を表わしている。「応答」動作は、出力マネージャ２３０による応答データの作成を表わしている。マルチメディア応答データは、口語形式または視覚的形式ならびに他の形式でユーザに提示されてもよいが、図３〜図１０においては、時間セグメントとして示されている。

図３は、図２の入力モジュール２１０がクエリの処理中および応答の出力中に追加入力を無視する「半二重」の実施形態を示す。具体的には、ユーザが発話Ｕを始める時間ｔ_１において、入力モジュール２１０は発話を規定するオーディオデータをリスニングしている。ユーザが時間ｔ_２において発話を終えたすぐ後の時間ｔ_３において、入力モジュール２１０は、発話が終了していると判断し、これにより、（１）追加の発話ストリーム入力データのリスニングを停止し、（２）識別された発話Ｕ（すなわち時間ｔ_１とｔ_２との間のオーディオ入力データ）の処理を開始する。発話Ｕの処理が時間ｔ_４において終了すると、出力マネージャ２３０は、処理の結果に基づいてオーディオ形式または視覚的形式などで応答を出力する（たとえば、Ｕが情報についての要求である場合、応答は要求された情報を表現している）。応答の出力がｔ_５において終了すると、次いで、入力モジュール２１０は再び追加の発話のリスニングを開始するだけである。

図４は、図３の実施形態に起因する発声データの損失を示す。処理が行なわれている最中のｔ_３とｔ_４との間である時間ｔ_３′において、ユーザはｔ_４まで続く追加の発話Ｕ_２（または代替例として、ｔ_５′まで続く発話Ｕ_３）を開始する。入力モジュール２１０がｔ_５になるまでリスニングを再開しないので、発話Ｕ_２のすべてが失われる（かまたは、代替例においては、Ｕ_３のうちｔ_５とｔ_５′との間の部分を除くすべてが失われる）。

図５は、いくつかの実施形態に従った、連続的なリスニングと、第２の発話に応答した第１の発話に関する不成功の動作とを示す。発話Ｕ_１が終了したことを入力モジュールが時間ｔ_３によって認識すると、処理モジュール２２０が処理Ｕ_１を開始する。Ｕ_１の処理がまだ行なわれている間の時間ｔ_４において、ユーザは第２の発話Ｕ_２を開始する。（たとえば、ユーザは「明日、どんな天候でしょうか？」（Ｕ_１）と述べ、一旦停止して、次に「ローマでは」（Ｕ_２）と続ける。）いくつかの実施形態においては、処理モジュール２２０は、Ｕ_２の始まりを検出するために処理Ｐ_１が完了する前にこの処理Ｐ_１を終了させる。他の実施形態においては、処理モジュール２２０はＵ_１の処理を完了させるが、Ｐ_１の処理が行なわれている間、Ｕ_２のリスニングも継続する。これにより、Ｕ_２が完了したときにＵ_２に対する処理Ｐ_２を実行することができるようになる。

図５の実施形態においては、Ｐ_２が完了した後、応答Ｒが提供される。Ｕ_２を認識した後に、Ｕ_２がＵ_１の続きであると図２のクエリシリアライザ２４３が判断した場合、処理モジュール２２０は、Ｕ_１およびＵ_２の連結に起因するクエリを実行し、このクエリに基づいて応答Ｒを提供して、先行の応答を出力しないことにより、Ｐ_１だけに基づいてこのような先行の応答をいずれも廃棄する。

対照的に、Ｕ_２がＵ_１の続きではなかったと処理モジュール２２０が判断した場合、処理モジュール２２０は、Ｕ_２とは別個にＵ_１を処理する。先の例に続けて、Ｕ_１が「明日、どんな天候でしょうか」であり、Ｕ_２が「カレンダーのアポイントメントを作成する」であった場合、いくつかの実施形態においては、応答Ｒは、Ｕ_１およびＵ_２の両方に対する応答（たとえば、天候の説明、およびカレンダーアポイントメントの作成が成功したかどうかの記載）を含む。（図５には示されない）他の実施形態においては、応答マネージャ２３０は、たとえば、Ｕ_２がＵ_１の続きではないと処理Ｐ_２によって判断されると直ちに、Ｐ_２に基づいて応答Ｒを出力する前に、処理Ｐ_１に基づいて応答を出力し始める。

ネットワーク待ち時間またはオペレーティングシステムのプロセス間通信待ち時間があるため、場合によっては、ユーザが第２の発話を開始した後に第１の発話の処理を開始することが可能になる。本発明は、第２の発話の損失を確実に防ぐ。処理モジュール２２０は、最終的に第２の発話についてのオーディオを受取ると、適切に動作するはずである。場合によっては、適切な動作は処理Ｐ_１をキャンセルすることである。場合によっては、適切な動作は、Ｐ_１を終了させてその結果を廃棄することである。場合によっては、適切な動作は、処理Ｐ_２の結果とは無関係にＰ_１の結果を提供することである。

図６は、一実施形態に従った並列なクエリ処理を示す。ｔ_３においてＵ_１の処理Ｐ_１を開始した後、第２の発話（Ｕ_２）が開始する。処理モジュール２２０は、Ｕ_１の処理Ｐ_１を続け、Ｕ_２の完了後にＵ_２の処理Ｐ_２を開始する。（仮にＵ_２がＵ_１の続きであったと処理モジュール２２０が判断していれば、いくつかの実施形態においては、代わりに、Ｕ_１とＵ_２との連結を処理していただろう。）処理モジュール２２０は、別個の実行スレッドで、ステップＰ_１およびＰ_２を、図６の例において時間ｔ_５と時間ｔ_４との間で行なわれているように並列に行なうことができるように、実行する。応答モジュール１３０は、それぞれの処理（すなわちＰ_１およびＰ_２）が終了した直後に、Ｕ_１およびＵ_２（すなわち、Ｒ_１およびＲ_２のそれぞれ）に対応する応答を出力する。

図７は、一実施形態に従った、処理完了の順序に基づいてクエリ応答をばらばらの順序で出力することを示す。発話Ｕ_１はＵ_２の前に始まって、これに応じてＵ_１のための処理Ｐ_１がＵ_２のためのＰ_２の前に始まるが、Ｐ_２はＰ_１よりも早く完了する（たとえば、Ｐ_２がより計算集約的であるか、またはより長い待ち時間などを有する外部サービスの使用を必要とするからである）。したがって、Ｕ_２についての応答Ｒ_２は、（ｔ_７から始まる）Ｕ_１についての応答Ｒ_１よりも早く（ｔ_５から始まる）出力される。図７に示される実施形態においては、出力マネージャ２３０は、たとえ応答Ｒ_１がより早い時間ｔ_６において準備ができていたとしても。Ｒ_２の出力が完了すると、時間ｔ_７まで応答Ｒ_１の提供の開始を遅らせる。このような遅延は、応答が聞き取れるように出力される場合などに、重複する応答の出力が逸らされるような態様でこれらの応答が出力されれば、有益である。（図７に示されない）他の実施形態においては、または、さまざまな応答がユーザに逸らされることなく重複した時間に出力され得る状況の場合（たとえば、応答が、ビジュアルユーザインターフェイスのさまざまな部分において視覚的に出力され得る場合）、より後の時間に準備のできた応答は、より早い応答が完全に出力されるまで遅らせなくてもよい。

図８は、応答が、それらの対応する発話が受取られた順序に対応する順序で出力される実施形態を示す。すなわち、Ｕ_１がＵ_２よりも前に受取られているので、対応する応答Ｒ_１はＲ_２よりも前に出力される。この場合、出力マネージャ２３０は、第１の発話Ｕ_１の処理Ｐ_１が完了するまで、如何なる応答の出力をも遅らせる。それらの対応する発話と同じ順序で結果を提供することは、結果が同様のタイプでありユーザにとって容易に識別可能とならない場合など、たとえば、Ｕ_１およびＵ_２の両方が天候状態に関係する場合などのいくつかの事例においては有益である。上述のように、いくつかの実施形態またはシナリオにおいては、Ｒ_２は、Ｒ_１と時間を部分的にまたは全体的に重複させて出力することができるかもしれない。これは、たとえば、第１の結果が天候に関するものであり第２の結果が住民数に関するものである場合などのように、上記結果が異なるタイプであるためにユーザにとって容易に識別可能である状況においては、許容可能である。

図９は、一実施形態に従った、連続する発話間の依存性に基づいて第２の応答を提供する際の遅延を示す。入力モジュール２１０が発話Ｕ_２の終わりを検出した後、処理モジュール２２０は、クエリシリアライザに関して上述したように、時間ｔ_６によって（たとえば、連結Ｕ_１＋Ｕ_２をうまく解析しようと試みることによって）Ｕ_２がＵ_１の続きであることと、Ｕ_２に対する応答がＵ_１に対する応答に依存することとを判断し得る。したがって、処理モジュール２２０は、Ｐ_１が完了する（とともに、これにより応答Ｒ_１が計算される）まで処理の実行段階を遅らせる。Ｐ_１が時間ｔ_８において完了すると、処理モジュールは、処理Ｐ_２、応答Ｒ_１を基礎として応答Ｒ_２を規定し、Ｐ_２が完了したｔ_９においてＲ_２を出力する、という実行段階を実行する。

図１０は、一実施形態に従った応答の中断を示す。パーサ２２２は、段階Ｐ_１において処理されるクエリＱ１を作成する発話Ｕ_１を処理し、時間ｔ_４までに応答Ｒ_１を生成する。出力マネージャ２３０は時間ｔ_４において応答Ｒ_１を出力し始める。より遅い時間ｔ_５において、入力モジュール２１０は第２の発話Ｕ_２を検出し、Ｕ_１＋Ｕ_２がクエリＱ_２として解析される。一実施形態においては、Ｑ_１およびＱ_２の論理関係性がクエリシリアライザ２４３によって分析されてから、時間ｔ_５において出力マネージャ２３０によって応答Ｒ_１の出力を停止させ、代わりに、時間ｔ_８で処理Ｐ_２を開始し、時間ｔ_９において結果Ｒ_２を出力する。したがって、出力マネージャ２３０はＲ_１の出力を停止させる。たとえば、Ｕ_１が「明日、どんな天候でしょうか」という句であった場合、出力モジュールは、ユーザの現在の位置について翌日の予測された天候の記述を出力し始めるが、Ｕ_２が「ローマでは」という句であった場合、（ユーザがローマまたはその付近にはいないと想定して）ユーザの現在の位置における翌日の天候は関連性がなくなるだろう。このため、出力マネージャ２３０は、局所的な天候の記述を出力するのを停止するだろう。

コンピュータアーキテクチャの例
図１１は、一実施形態に従った、図１のクエリ処理サーバ１００またはクライアントデバイス１１０の一部またはすべてとして用いられるコンピュータ１１００の物理コンポーネントを例示するハイレベルブロック図である。チップセット１１０４に結合された少なくとも１つのプロセッサ１１０２が示される。チップセット１１０４には、メモリ１１０６、ストレージデバイス１１０８、キーボード１１１０、グラフィックスアダプタ１１１２、ポインティングデバイス１１１４およびネットワークアダプタ１１１６が結合される。ディスプレイ１１１８はグラフィックスアダプタ１１１２に結合される。一実施形態においては、チップセット１１０４の機能は、メモリコントローラハブ１１２０およびＩ／Ｏコントローラハブ１１２２によって提供される。別の実施形態においては、メモリ１１０６が、チップセット１１０４の代わりにプロセッサ１１０２に直接結合される。

ストレージデバイス１１０８は、ハードドライブ、コンパクトディスク読取り専用メモリ（compact disk read-only memory：ＣＤ−ＲＯＭ）、ＤＶＤまたはソリッドステートメモリデバイスなどの任意の非一時的なコンピュータ読取り可能記憶媒体である。メモリ１１０６は、プロセッサ１１０２によって用いられる命令およびデータを保持する。ポインティングデバイス１１１４は、マウス、トラックボールまたは他のタイプのポインティングデバイスであってもよく、コンピュータ１１００にデータを入力するためにキーボード１１１０と組合わせて用いられる。グラフィックスアダプタ１１１２は画像および他の情報をディスプレイ１１１８上に表示する。ネットワークアダプタ１１１６はコンピュータ１１００をローカルエリアネットワークまたはワイドエリアネットワークに結合する。

当該技術において公知であるように、コンピュータ１１００は、図１１に示されるものとは異なるコンポーネントおよび／または図１１に示される以外のコンポーネントを含み得る。加えて、コンピュータ１１００には、図示されるいくつかのコンポーネントが含まれていない可能性がある。一実施形態においては、サーバとして機能するコンピュータ１１００には、キーボード１１１０、ポインティングデバイス１１１４、グラフィックスアダプタ１１１２および／またはディスプレイ１１１８が含まれていない可能性がある。さらに、ストレージデバイス１１０８は、（ストレージエリアネットワーク（storage area network：ＳＡＮ）内で具体化されるような）コンピュータ１１００からローカルおよび／またはリモートであってもよい。

当該技術において公知であるように、コンピュータ１１００は、この明細書中に記載される機能を提供するためのコンピュータプログラムモジュールを実行するように適合されている。この明細書中において用いられているように、「モジュール」という語は、特定の機能を提供するために利用されるコンピュータプログラム論理を指している。このため、モジュールはハードウェア、ファームウェアおよび／またはソフトウェアにおいて実現することができる。一実施形態においては、プログラムモジュールは、ストレージデバイス１１０８上に格納され、メモリ１１０６にロードされ、プロセッサ１１０２によって実行される。

他の検討事項
多くの変更例および変形例が当業者にとって明らかになるだろう。変更例および変形例は、開示された特徴の如何なる関連する組合せをも含む。明細書における「一実施形態」または「或る実施形態」についての言及は、実施形態に関連して記載された特定の機能、構造または特徴が少なくとも１つの実施形態に含まれていることを意味している。明細書のさまざまな箇所における「一実施形態における」という句は必ずしもすべてが同じ実施形態を指しているわけではない。不定冠詞「ａ」および「ａｎ」は、文脈に応じて適宜、単数形および複数形を共に含むものと理解されるべきである。このため、「ブロック」は、たとえば、「少なくとも１つのブロック」を意味するものと理解されるべきである。

なお、プロセスステップおよび命令がソフトウェア、ファームウェアまたはハードウェアで具体化されるものであり、かつ、ソフトウェアで具体化される場合には、さまざまなオペレーティングシステムによって用いられるさまざまなプラットフォーム上に常駐するようにダウンロードすることができ、さまざまなオペレーティングシステムによって用いられるさまざまなプラットフォームから動作させることができることに留意されたい。

この明細書中における動作は装置によって実行されてもよい。さらに、この明細書中において言及されるコンピュータは、シングルプロセッサを含み得るか、または、高いコンピューティング能力のために複数のプロセッサ設計を採用しているアーキテクチャであってもよい。この明細書中に記載されるように本発明の教示を実現するためにさまざまなプログラミング言語が使用され得ること、および、特定言語についての以下のいずれの言及も本発明の使用可能性および最適モードを開示するためになされたものであることが認識されるだろう。

本発明が好ましい実施形態およびいくつかの代替的な実施形態に関連付けて特別に図示および記載されてきたが、当業者であれば、形式および詳細のさまざまな変更が、本発明の精神および範囲から逸脱することなくこの明細書中でなされ得ることを理解するだろう。

最後に、明細書において用いられる言語が主に読みやすさおよび教示の目的で選択されたものであり、発明の主題を詳細に描写するかまたは限定するために選択されたものでない可能性があることに留意されたい。したがって、本発明の開示は、添付の特許請求の範囲において記載されている発明の範囲を限定するのではなく例示するものとして意図されている。

１００クエリ処理サーバ、１１０クライアントデバイス、１１２音声入力装置、１１３音声出力装置、１４０ネットワーク、１５０クエリ処理モジュール。

Claims

口語入力に対する応答を生成する、コンピュータによって実現される方法であって、前記方法は、
オーディオ入力ストリームを取得するステップと、
前記オーディオ入力ストリームにおいて第１の発話の始まりを検出するステップと、
前記オーディオ入力ストリームにおいて前記第１の発話の終わりを検出するステップと、
前記第１の発話の前記終わりを検出したことに応じて、第１のクエリを認識するために前記第１の発話の処理を開始するステップと、
前記第１の発話を処理している間、
前記オーディオ入力ストリームを受取り続けるステップと、
前記オーディオ入力ストリームにおいて第２の発話の始まりを検出するステップと、
第１の応答を決定するために前記第１のクエリを実行するステップと、
前記オーディオ入力ストリームにおいて前記第２の発話の終わりを検出するステップと、
第２のクエリを認識するために前記第２の発話を処理するステップと、
前記第１のクエリと前記第２のクエリとの間の直列の依存性を識別するステップと、
前記第２のクエリにおける要素が前記第１のクエリの実行によって決定される場合に、前記第１のクエリと前記第２のクエリが並行して実行され得ないと決定するステップと、を含み、
前記第１のクエリと前記第２のクエリが並行して実行され得ないと決定された場合に、前記第１のクエリの実行の後で前記第２のクエリが実行されるように前記第２のクエリの実行が遅らされ、前記方法は、さらに、
第２の応答を決定するために前記第２のクエリを実行するステップと、
前記第２の応答を出力するステップと、を含む、コンピュータによって実現される方法。
前記第１の応答を出力するステップは前記第２のクエリを実行するステップと同時に実行される、請求項１に記載の、コンピュータによって実現される方法。
前記第１の応答は視覚的に出力され、前記方法はさらに、
前記第１の応答が視覚的に出力されてから表示期間が経過したかどうかを判断するステップと、
前記表示期間の経過後に前記応答の視覚的な出力をクリアするステップとを含む、請求項１または２に記載の、コンピュータによって実現される方法。
発話の終わりを検出することは、口語の前記オーディオ入力ストリームにおける一時的な停止、前記オーディオ入力ストリームにおける非スピーチ部分、および、ユーザによって実施されたユーザ入力イベント、の中の少なくとも一つを識別することを含む、請求項１〜３のいずれか１項に記載の、コンピュータによって実行される方法。
前記直列の依存性を識別するステップは、前記第１のクエリと前記第２のクエリの内容に基づく、請求項１〜４のいずれか１項に記載の、コンピュータによって実行される方法。
請求項１から５のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。
請求項６に記載のプログラムを格納するように構成されたメモリと、
前記メモリに格納された前記プログラムを実行するように構成されたプロセッサとを含む、コンピュータ。
請求項６に記載のプログラムを格納するように構成されたメモリと、
前記メモリに格納された前記プログラムを実行するように構成されたプロセッサとを含む、スマート機器。
請求項６に記載のプログラムを格納するように構成されたメモリと、
前記メモリに格納された前記プログラムを実行するように構成されたプロセッサとを含む、車。