JP6803351B2 - マン・マシン・ダイアログにおけるエージェント係属の管理 - Google Patents

Description

相互参照
本出願は、２０１７年４月１２日に出願された「仮想エージェントの係属を管理するためのシステムおよび方法（SYSTEM AND METHODS FOR MANAGING THE ENGAGEMENT OF A VIRTUAL AGENT）」と題する米国仮特許出願第６２／４８４，８４５号（代理人整理番号ＳＯＵ−００４ＰＲＶ）の恩恵を主張し、その全体をここに引用により援用する。

発明の分野
本発明は、マン・マシン・ダイアログの分野に関し、特にダイアログの自然さおよび効率を改善する技術に関する。

背景
仮想エージェントとも呼ばれる仮想アシスタントは、ユーザとの自然言語対話を実行することができるコンピュータベースのエージェントである。エージェントは、通常、人間のユーザにサービスを提供する。それは、ハードウェアとソフトウェアとの組み合わせを使用して、ユーザからの自然言語要求（情報要求またはアクション要求など）に応答（または応答しようと）する。

仮想アシスタントの概念そのものは、擬人化されている。シリ、アレクサ、コルタナ、ニーナなどの親しみのあるアシスタントは、人名、人間のような声、そしておそらく何らかの人格を有する。ユーザは、人間の会話のパートナーであるかのように、アシスタントと自然な態様で対話するよう促される。アシスタントは、ユーザにとって意味をなし、内部動作がきわめて複雑であり得るシステムの残りの部分を見えないように隠す通信インターフェイスを提供する。仮想エージェントシステムの内部の複雑さを単なる詳細として別にすると、マンマシンコミュニケーションの主要な局面は係属の概念である。要するに、エージェントは、ユーザから受信した要求に基づいて行動する。

対話型音声応答（ＩＶＲ）システムでは、人間のユーザと仮想アシスタントとが電話回線を介して通信する。彼らは会話に係属しており：アシスタントは、ユーザの言うことをすべて聞いて、処理または処理しようとする。

より開けた状況では、ユーザの音声は、部屋の他の人または仮想エージェントに向けられ得る。エージェントがユーザの音声に応答する間、エージェントはダイアログに係属している。エージェントは係属しているが、ユーザの音声がエージェントを対象としていない場合、望ましくない挙動が生じる。エージェントは愚かで迷惑な答えを出し得、さらに悪ければ、ユーザが意図していない行動を取る可能性があり、その行動は望ましくない結果をもたらす可能性がある。

これは、ユーザインターフェイス設計においてミダス王効果として知られている問題を示す。この効果は、ユーザがユーザインターフェイスの活動の結果を防ぐことができないことを指す。伝説の通りでは、ミダス王は貪欲で、彼が触れたものすべてを金に変えることを望んでいた。彼の願いは文字通り与えられ、これは呪いへと進展した。彼が娘を抱きしめると、娘は金の像に変わり、彼は、自分の食べ物に触れるとそれが金になったので、餓死した。

ミダス王効果の具体例として、エージェントは「午後８時にＳＦＯにＵｂｅｒをお願い」と言われ、注文するためにＵｂｅｒにアクセスすることにより、要求に対して正しく動作するとする。エージェントが係属したままでユーザが自分の娘に「ダーリン、クローゼットから赤い靴を持って来てくれる？」と話しかける場合、エージェントは鈍い応答（「あなたが何を意味しているのかわかりません）」、ずうずうしい応答（「私をダーリンと呼びましたね。私もあなたが好きです」）、または実用的な応答（「どのクローゼットですか？」）をするかもしれないが、これらの応答はすべて不適切である。要求は実際にはユーザの娘に宛てられており、エージェントからの応答は期待されていなかった。この問題は、エージェントがＵｂｅｒ要求後に休眠状態になっていたら、回避されていたであろう。ミダス王効果は明らかに回避されなければならない。

望ましくない時間にエージェントがユーザ要求に対して動作するのを防止するために、従来のエージェントは、すべてのユーザ要求後にエージェントを係属解除する。要求を処理した後、再係属するよう強制されるまで、エージェントは新たな要求を受け入れない。すなわち、別の要求が処理され得る前に、ユーザはエージェントを「覚醒させる」必要がある。エージェントを覚醒させる一般的な方法は、“Hey Siri,”“OK, Google（登録商標）,”または"Alexa"（単一の単語または複数の単語のフレーズでもよい）のような覚醒ワードを言うことである。エージェントを覚醒させる他の方法は、クリック、タップ、プッシュが含むが、これらはハンドフリーではない。

覚醒ワード自体は要求の一部ではないことに注目されたい。それは、エージェントの注意を喚起するためだけに役立つ。これはオーバーヘッドを招き、それは、特定の人の注意を呼び出す、または発話の受信者を切り替える、などの特定の状況でのみ、覚醒ワードに相当するものが使用される、人と人との間の通常のコミュニケーションに比べて、時間の無駄である。

要求ごとに覚醒ワードを発することは、単に非効率的であるだけでなく、冗長でもある。この問題は「覚醒ワード疲労」として知られている。人々は、より良い方法がないために、毎回、エージェントを覚醒させることを、不承不承受け入れている。

要するに、ミダス王効果を防止するためのよく知られた方法は、かなりの費用がかかる。これは、マン・マシン・ダイアログを非効率的で不自然にし、覚醒ワード疲労はユーザ体験を悪いものにする。人間のユーザとその仮想エージェントとの間のより効率的で流動的で自然なコミュニケーションをサポートする方法が必要である。

発明の概要
本開示は、現在の方法を上回るマン・マシン・ダイアログの効率および流動性の改善に向けられている。ミダス王効果を避ける必要性は、従来のアプローチとは異なり、覚醒ワード疲労を引き起こさないアプローチによって対処される。記載される非従来的な係属ポリシーは、すべての要求の前にエージェントを「覚醒させる」必要性を最小限に抑えるかまたは排除するという共通の目標を有する。マン・マシン・ダイアログをより自然かつ効率的にするいくつかの係属ポリシーが開示される。

ロックされた係属ポリシーは、ユーザにエージェントの係属を明示的に制御させる。そのようなポリシーでは、発声された要求またはイベントインジケータは、エージェントを強制的に係属のロック状態にしたり、ロック状態から外したりすることができる。係属のロック状態とは、エージェントが係属したままであり、明示的にロック解除されるまで繰り返し要求を処理できる状態である。ロックされた係属は無条件で行うことができ；これは非常に重要なケースであり、なぜなら、その単純さにもかかわらず、それは覚醒ワード疲労と戦うための長い道のりになるからである。無条件のロックされた係属は、ユーザがエージェントの状態をロック解除することを選択するまで、介在する覚醒インジケータなしに、任意の長い要求のシーケンスを処理できるようにする。ロックされた係属の変形により、ユーザは係属に特定の条件（だれがいつ係属するかなど）を配することができる。条件付きのロックされた係属の更なる変形は、更新可能な期間の間、（他者を排除して）特定のユーザに対するエージェントの注意を確保し、通信オーバーヘッドはない。無条件ロックおよび確保された係属は、両方とも、覚醒ワード疲労を回避するための簡単で実用的な解決策を提供する。

別の係属ポリシーである「注意深いエージェント」ポリシーは、エージェントの、状況、ユーザ、および人間のような係属のモデルに対する知覚に基づいて、コンテキストにおいて、自律的な係属および係属解除の判断を行うエージェントの知性に依存する。注意深いエージェントは、ユーザが係属を望んでいるとそれが考えている間は、係属したままであり、それは、自然な人間の対話に関わる人々のように、注意を払って、ユーザが係属したままであることを望んでいるかどうかを各時点で判断するための多くの手がかりを利用できなければならない。最後に、ロックされた係属ポリシーを注意深いエージェントポリシーと統合するハイブリッドポリシーが定義される。

用途は、インテリジェント型アシスタントから、隔離された物のインターネット（ＩｏＴ）デバイスを含むあらゆるタイプの音声対応デバイス、潜在的に多くのセンサおよびエフェクタを伴うインテリジェントスペース、たとえば自動車、インテリジェントホーム、オフィス、店舗、ショッピングモール、ヒューマノイドロボットまでの範囲に及ぶ。

一実施形態によるマン・マシン・ダイアログにおけるパートナーを示す図である。 一実施形態による例示的マン・マシン・ダイアログを示す図である。 一実施形態による、入力および出力を有するデバイスを示す図である。 一実施形態による、入力および出力がネットワークを介してサーバに接続されるデバイスを示す図である。 一実施形態によるスマートフォンを示す図である。 一実施形態による、音声対応デスクトップコンピュータを示す図である。 一実施形態による、音声対応テレビジョンを示す図である。 一実施形態による、音声対応冷蔵庫を示す図である。 一実施形態による音声対応自動車を示す図である。 一実施形態によるインテリジェントスペース内のユーザを示す図である。 一実施形態によるインテリジェントスペース内の複数のユーザを示す図である。 Ｎａｏロボットのいくつかのセンサおよびエフェクタを示す図である。 一実施形態による、係属ポリシーの階層の図を示す図である。 一実施形態による係属状態の階層を示す図である。 一実施形態による、係属された状態およびそのすぐ近傍を示す図である。 ＦＳＡ近傍に従ってモーダルダイアログを伴う係属された状態を示す図である。 一実施形態による要求処理状態の使用を示す図である。 一実施形態による、割込みをサポートするための、図７Ｃの詳細図である。 一実施形態による係属ＦＳＡを示す図である。 一実施形態による、無条件ロック状態およびそのすぐ近傍を示す図である。 一実施形態による、条件付きロック状態およびそのすぐ近傍を示す図である。 一実施形態による、条件付きロック状態でのＦＳＡを示す図である。 一実施形態による、図９のＦＳＡの変形を示す図である。 一実施形態による、休眠状態のロジックを示す図である。 一実施形態による、ロック状態のロジックを示す図である。 一実施形態による、確保状態でのＦＳＡを示す図である。 一実施形態による、確保状態におけるロジックを示す図である。 一実施形態による、注意深い状態でのＦＳＡを示す図である。 一実施形態による、注意深い状態におけるロジックを示す図である。 一実施形態による、注意深い状態およびロック状態を有するハイブリッドＦＳＡを示す図である。 一実施形態による、図１６ＡのＦＳＡの変形例を示す図である。 一実施形態による、回転ディスクの非一時的なコンピュータ可読媒体を示す図である。 一実施形態による、フラッシュランダムアクセスメモリの非一時的なコンピュータ可読媒体を示す図である。 一実施形態による、コンピュータプロセッサベースのシステムオンチップの底面図である。 一実施形態によるサーバを示す図である。 一実施形態による、デバイスのためのシステムオンチップのブロック図である。 一実施形態による、サーバプロセッサのブロック図である。

詳細な説明
エージェントおよびユーザ
図１Ａは、ユーザ１０１およびエージェント１０２の図を示す。図１Ｂは、ユーザ１０１と、ダイアログ１０４に係属するユーザエージェントインターフェイスを提供するデバイス１０３とを示す。ユーザとエージェントとは通常、ダイアログ内で順番を交替する。本開示では、ユーザは、自然言語要求に対する応答を得るために、仮想エージェントと自然言語対話を行い得る者である。仮想エージェント（または仮想アシスタント、アシスタント、もしくは単にエージェント）は、ハードウェアとソフトウェアとの組み合わせを備え、ユーザとの自然な言語対話を実行するように設計されたシステムである。エージェントの役割は、ユーザの要求に応答して、要求された情報の検索や要求されたアクションの実行などのサービスを提供することである。

デバイスおよびセンサ
本開示では、デバイスは、仮想エージェントがユーザと通信することを可能にするユーザ対面ハードウェアである。エージェントソフトウェアは、デバイス上でローカルに実行されてもよく、または分散されて実行されてもよく、その場合には、ユーザ対面デバイスは、通常、ネットワークを介して１つ以上のサーバに接続される。

デバイスは、エージェントが必要とする機能を実行するためにソフトウェアをローカルに実行することができる。図２Ａはスタンドアロンの実施形態を示し、デバイス２００が、エージェントによって必要とされる全機能をローカルに提供する。図２Ｂは、デバイス２２０がネットワーク２４０を介してサーバ２３０に接続され、エージェントの機能がデバイス２２０上で実行されるローカル機能とサーバ２３０上で実行されるリモート機能との間で分割される分散型の実施形態を示す。

図２Ａおよび図２Ｂは、さまざまな入力および出力を有するデバイスを示している。センサ入力２２２と呼ばれる入力のいくつかは、１つ以上のマイクロフォンからのデジタル音声入力信号、１つ以上のカメラからのビデオ入力信号、タッチスクリーンからの入力など、感知的性質のものである。エフェクタ出力２２４と呼ばれるいくつかの出力は、同様に、性質が感知的なものであり、たとえば、１つ以上のスピーカに送信されるデジタル音声信号、１つ以上のビジュアルディスプレイに送信されるビデオ出力信号、ＬＥＤなどの読出に送信されるステータス信号などを含む。センサ入力２２２およびエフェクタ出力２２４に加えて、デバイス２２０は、ローカルネットワーク上の他のデバイスまたはサーバ２３０への通信リンクを含むことができる他の入力２２６および他の出力２２８を有することができる。

本開示では、デバイスは、多数のセンサおよびエフェクタを有することができるが、音声を受信する１つのマイクロフォンと、ユーザに聴覚的または視覚的な形態の応答を与えるためのスピーカまたはディスプレイとが（最低限）存在しなければならない。多くの追加のセンサおよびエフェクタが含まれてもよい。いくつかの実施形態では、センサまたはエフェクタは、ユーザが気づいていなくてもよいものを含む。

本開示では、デバイスの定義はかなり広く、多くのタイプの公知デバイスがある。デバイスは、スマートフォン３００（図３Ａ）、デスクトップコンピュータ３１０（図３Ｂ）、スマートＴＶ３２０（図３Ｃ）、およびスピーカベースの仮想アシスタント１０３（図１Ｂ）などの電子デバイスを含む。他の装置は、冷蔵庫３３０（図３Ｄ）などの音声対応家電であり、人間のユーザ３３６は冷蔵庫３３０のセンサ３３４と対話している。

本開示では、空間領域は、そのセンサおよびエフェクタが、ユーザと対話することができるルームエージェントの一部として、調整された態様で使用される場合にのみ、インテリジェントスペースと呼ばれてもよい。住宅、オフィス、公共空間は「インテリジェントスペース」と呼ぶことができる。音声対応自動車（図３Ｅ）は、センサおよびエフェクタをインテリジェントに調整する限り、インテリジェントスペースとしても機能する。

図３Ｅは、自動車３４０の一実施形態の俯瞰図を示す。これは、２つの前部座席マイクロフォン３４１、ヘッドアップディスプレイ３４２、外部カメラサブシステム３４３、前部座席内部カメラおよびマイクロフォンサブシステム３４４、ならびに後部座席内部カメラおよびマイクロフォンサブシステム３４５を備える。スピーカは、ドアおよびトランク内に取り付けられる。

図４Ａは、インテリジェントスペース４００の抽象図を示す。人間のユーザ４０２は、リビングエンクロージャ４２０内に示されている。センサ４３０，４３２，４３４（マイクロフォンおよびカメラなど）は、ローカルデバイス４１０に信号を送信する。エフェクタ４４０，４４２（スピーカおよびディスプレイなど）は、リビングエンクロージャ４２０の内部または外部に見出され得るネットワークケーブル４７０を介して、ローカルデバイス４１０から信号を受信する。ここではそれらは外側に示されている。他の実施形態（図示せず）では、インテリジェントスペース４００は、公共空間またはモールのように、部分的に開放状態であるか、部分的空間に分割されるか、または開放状態であり得る。

「ルーム」エージェントは、インテリジェントスペースの機能を制御する。ルームエージェントソフトウェアは、有線（たとえば、ネットワークケーブル４７０）または無線ローカルネットワーク（図示せず）を使用して接続される、１つ以上のローカルデバイス４１０上で動作する。多くの実施形態では、ローカルデバイス４１０はまた、グローバルネットワーク４９０を介して１つ以上のサーバ４８０に接続される。

図４Ａでは、人間のユーザ４０２は、インテリジェントスペース４００と対話する。ユーザは、ルームエージェントの注意を得るために、「やあ、ルーム」という覚醒ワードを言う。センサ４３２（いくつかのカメラのうちの１つ）またはセンサ４３０（いくつかのマイクロフォンのうちの１つ）によってキャプチャされた信号が、ローカルデバイス４１０に入力される。

図４Ｂは、別の人物４６０の「やあ、ボブ」という発話が人間のユーザ４０２に向けられ、ルームエージェントを混乱させる可能性を示す。エージェントは、別の人物４６０からの要求に応答することになっているのか、またはそれらを無視することになっているのか？仮説的実施形態では、人間のユーザ４０２がエージェントに対して先に「私の言うことを聞いて」と言っていた場合には、別の人物４６０からの発話は無視される。本開示では、現在のユーザ４０２に対してエージェントの注意（または係属）を確保する方法を検討する。

ロボットもまたデバイスである。図５は、擬人化されたモバイルの物体に格納された多数のセンサおよびエフェクタを有する典型的なロボットを示す。具体的には、それは市販のＮａｏロボットである。インテリジェントスペース（図４Ａ）も、多くのセンサおよびエフェクタを有するが、それらはユーザを取囲む空間において広く広がる傾向がある。

本開示では、デバイスが有するセンサの組は、少なくとも１つのマイクロフォンを含む。ロボットまたはインテリジェントスペースのようなデバイスは、通常、１つ以上のカメラ、おそらくはマイクロフォンアレイとして複数のマイクロフォン、およびおそらくはソナー、レーザーなどを含む、多くのセンサを有することができる。各センサは、デバイスが１つ以上のＤＳＰ（デジタル信号処理）レイヤを使用して処理できるデジタル入力信号をキャプチャする。特定のセンサには特定の処理レイヤがあり、後で説明するように、後のＤＳＰレイヤではマルチセンサ統合を達成できる。

マイクロフォンアレイ（２つ以上のマイクロフォン）の使用は、空間におけるマイクロフォンアレイの位置に対する、対象の方位の推定を可能にする。それはまた、音声をキャプチャする際の背景雑音の減衰を改善することもできる。

１つ以上のカメラの使用は、見掛けのサイズおよび形状、またはある視点からの方位など、対象の多くの特徴の測定を可能にする。複数のカメラを使用することで、奥行き及び３Ｄ形状の判断を助け；それはまた、より多くの情報をもたらす視点の選択を提供する。

技術用語集
本開示で使用される重要な技術用語をここで定義する。この用語集の用語は互いを自由に参照する。この用語集のいくつかのセクションは、本発明の重要な局面を開示し、思想のいくつかの上位の概要を提供する。

エージェント、ＦＳＡおよび係属状態
係属（Engagement）−マン・マシン・ダイアログで、係属とは、エージェントがユーザ要求を受信して処理する意欲（または見掛けの能力）を指す。要求を入力として受け取った後、要求を処理することは、通常、それを理解し、それに対して動作し、出力として返答を生成することを含む。係属しているエージェントは要求を処理する。係属解除されたエージェントは要求を処理せず、エージェントに実際に要求が聞こえているかどうかは重要ではない。一般的に言えば、係属しているエージェントは、「謹聴している」および「そのマイクロフォンをオンにしている」と言え、係属解除されたエージェントは「そのマイクロフォンがオフになっている」と言えるが、この言葉は文字通り取られてはならず、なぜならば、係属解除されたエージェントのマイクロフォンは、それが覚醒ワードを待っているとき、信号を連続的にキャプチャしているからである。単独で係属を定義するのが、要求を処理する能力である。

係属ポリシー(Engagement Policy)−係属ポリシーは、マン・マシン・ダイアログ中にエージェントの係属状態を処理する体系的な方法である。図６Ａは、以下に開示されるさまざまなポリシーの概要である。これらのポリシーは、覚醒ワード疲労の原因となるポリシーとは異なり、これらのポリシーは、いずれもそれを別の方法で置き換えようと意図されている。それらは、注意深いエージェントポリシー、３つのロックされたエージェントポリシー、無条件ロック、条件付きロック、および確保されたエージェントポリシーを含む。

ポリシー実装（Policy Implementation）−係属ポリシーは、実装の詳細にかかわらず、いつエージェントが係属しているかを判定する上位プロセスを記述する。本開示では、係属ポリシーは有限状態オートマトン（ＦＳＡ）によって記述される。ＦＳＡは、システム内で許可された状態および状態遷移を簡単な方法で伝達する、よく知られている抽象的な表現である。ＦＳＡは、本質的に等価であり、本開示の対象となる、多くの異なる方法で実施することができる。

ＦＳＡ−有限状態オートマトン（ＦＳＡ）は、ラベル付けされた状態（有向グラフのノードである）および遷移（ノード間の有向枝である）を備える。各遷移には関連付けられた条件があり、それが満足されると状態遷移が発生する。さらに、遷移はオプションで処理アクションに関連付けられる。遷移に関連付けられる処理アクションは、遷移の条件が満たされた後、かつ状態遷移が完了する前に実行される。

係属の状態（States of engagement）−エージェントの係属の状態（または単に状態）は、ユーザからの要求を処理するエージェントの準備状況を表す。本開示で考慮される係属状態には、休眠状態およびさまざまな種類の係属された状態が含まれる。これらのタイプを定義および議論する際、本開示で議論されるすべての係属状態の分類を示す図６を参照すると役立つであろう。

休眠状態（Dormant states）−エージェントが要求を処理しない状態は、休眠状態と呼ばれる。休眠しているエージェント（すなわち、休眠状態にあるエージェント）は係属解除されており、覚醒インジケータを受信せずに再係属することはない。本開示における非休眠状態はすべて係属された状態であり、図６を参照されたい。

係属された状態（Engaged states）−係属された状態のエージェントは、ユーザ要求を処理し、すなわち、それは、要求を解釈し、それらに対して動作し、応答を生成する。本開示は、異なる係属ポリシーをサポートするために、異なるクラスの係属された状態を使用する。

ワンタイム状態（One-time states）−ワンタイム状態のエージェントは係属中である。ただし、それは、１つの要求を処理した直後に係属解除され、休眠状態に入る。したがって、後続の要求が処理され得る前に覚醒インジケータが必要になる。

反復状態（Recurrent states）−反復状態のエージェントは係属中であるが、ワンタイム状態とは異なり、覚醒インジケータを必要とせずに、複数の要求を反復状態で処理することができる。エージェントは、エージェントが反復状態を出るようにする条件をエージェントが検出するまで、デフォルトで、同じ反復状態のままである。いくつかのタイプの反復状態について説明する；図６を参照されたい。

ロック状態（Locked states）−ロック状態は反復し、したがって係属中である。ロック状態は、明示的なロック要求の後に入る。エージェントは、明示的なロック解除要求またはタイムアウトに続いてロック状態を離れる。口頭であるとき、ロック要求はオプションのロック条件を指定することがある。ロック条件が指定されていない場合、ロック条件の値は真であり、状態は無条件にロックされる。ロック条件が指定されている場合、それは要求処理時に評価される。最初の要求を処理した後、ロックされたエージェントは同じ状態に留まり、ロック条件が満たされている間、明示的なロック解除要求またはタイムアウトを検出するまで、追加の要求を繰り返し処理する。

確保状態（Reserved states）−確保状態は条件付きロック状態の変形であるが、その組み込みロック条件は、基準ユーザと呼ばれる特定のユーザのためのエージェントの使用を確保し；他のユーザに要求を処理する能力を拒否する。確保状態は、確保されたエージェントポリシーをサポートする。ロック状態とは異なり、確保状態には、明示的なロック要求なしに、自動的に入る。確保状態には、任意の要求の後に入るが；確保状態に入ることは、基準ユーザを規定し特徴付ける。ロック条件は、要求を発行する後続のユーザが、処理される要求について（エージェントが分かる限り）基準ユーザと同じでなければならないことを必要とする。したがって、確保状態のエージェントは、明示的なロック解除要求またはタイムアウトまで、（基準ユーザのみからの）要求を繰り返し処理する。

注意深い状態（Attentive states）−注意深い状態は注意深いエージェントポリシーをサポートする。注意深い状態はワンタイム状態に取って代わる。ロックされたエージェントのように、注意深いエージェントは反復状態であり、状態変更なしに要求を繰り返し処理する。しかし、ロックされたエージェントとは異なり、注意深いエージェントは、知覚されたイベントに基づいて、係属解除を選択できる。タイムアウトも、係属解除を引き起こすことができる。

アクションおよびインジケータ
アクション、イベント、およびインジケータ−ユーザアクションは、状態を変更するようにユーザがエージェントに命令するために行うかまたは言うことができるなにかである。ユーザアクションには、発声された要求がエージェントの状態における変化を明示的に求めている場合を除いて、エージェントに対して発声された要求は含まれない。イベントは、エージェントによって検出される条件であり、エージェントに状態を変更させることができる。（ユーザによって発された）アクションと（エージェントによって検出された）イベントとの真の区別は難しく、なぜならば、ユーザアクションは実施されるようエージェントによって認識されなければならず、認識それ自体はイベントとなるためである。アクションとイベントとを区別しようとする際に起こる微妙な問題を避けるために、本開示を通して、「インジケータ」という用語をアクションとイベントの両方に使用する。エージェントは、ユーザが生じさせるアクションであれ、またはユーザが気付いているかもしれないし気づいていないかもしれないイベントであれ、インジケータを検出する。

指定ジェスチャ−指定ジェスチャには、ユーザがエージェントと容易に通信できるようにする、タップ、スワイプ、クリック、ボタン押下または解放、およびより複雑なジェスチャが含まれる。複雑なジェスチャには、手のジェスチャ、身体をホットスポットに向ける、ある方向に歩く、ホットスポットに向かって視線を移動させる（ロボットとのアイコンタクト行うことまたは断つことを含む）などが含まれる。ユーザ体験の質のため、特に意味合いが正しい場合、たとえば、係属を示唆するよう使用されるアイコンタクトをなすことおよび係属解除を示唆するよう使用されるアイコンタクトを断つことなど、慣れ親しんだジェスチャが好ましい。指定ジェスチャには、エージェントが検出できる任意のユーザの動きが含まれる場合がある。動きは意図的なものでなくてもよく、ユーザは検出を意識してもしなくてもよい。

ホットスポット−ホットスポットは、ロボットの目（アイコンタクトをなすこと対アイコンタクトを断つこと）、またはユーザの身体の向きをロボットまたはある空間領域に向けるかまたは変えるなど、ユーザが注意を向け得る、または向けなくてもよい領域である。ホットスポットに関連するイベントを検出するために、エージェントは視線検出、顔検出または身体検出技術を使用することができる。

指定音−指定音は、音声を含み得、発声される要求に先行することが多いが、発声される要求ではない。指定音には、覚醒ワード、ワードスポッターが識別できるその他のインジケータフレーズ、およびベル音、ドラム打音、電話着信音、音楽音など、エージェントが認識できる比較的短い音が含まれる。このリストは網羅的ではなく、子供がエデュテインメントロボットを制御するために使用するおもちゃの木琴；またはロボット犬の注意をひく口笛などを想像することができる。短い音は、レイテンシの理由から−覚醒ワードと同じくらい速く、またはそれより速く−素早く識別できれば、特に便利である。また、指定音は、ユーザにとって、それらの正しい意味合いで選択する必要があり；たとえば、高音または打奏音は、それらを覚醒インジケータとして示唆する覚醒特性を有する。

覚醒インジケータ−覚醒アクションは、エージェントに係属するようユーザが行うかまたは言うことができるなにかである。覚醒アクションには、覚醒ワードまたはその他の指定覚醒音などの音声を生成すること、タップ、スワイプ、クリック、ボタン押下または解放などの覚醒ジェスチャを行なうこと、および他の指定ジェスチャが含まれる。覚醒イベントは、エージェントが自律的に検出する条件であり、エージェントを係属させる条件である。覚醒アクションおよび覚醒イベントは両方とも覚醒インジケータである。休眠状態は複数の覚醒インジケータを有することができ、異なる覚醒インジケータは異なる状態に遷移することができる。

覚醒ワード疲労−すべての要求の前に覚醒ワードを言わなければならないことは、覚醒ワード疲労を生じる質の悪いユーザ体験をもたらす結果となる。覚醒インジケータの使用を完全に排除することは不可能かもしれないが、予測可能な慣習の下でそれらを時折使用することは覚醒ワード疲労にならないはずである。

ロックインジケータ−ロックアクションは、ロック状態に遷移するようユーザがエージェントに命令するべく行なうかまたは言うことができるなにかである。ロックアクションには、エージェントの状態をロックするために指定されたジェスチャおよび音が含まれる。ロックアクションは発声された要求であってもよい。ロックイベントは、エージェントによって自律的に検出され、エージェントをロック状態に遷移させる条件である。ロックアクションおよびロックイベントは両方ともロックインジケータである。

ロック解除インジケータ−ロック解除アクションは、ロック状態から遷移するようにユーザがエージェントに命令するべく行なうかまたは言うことができるなにかである。ロック解除アクションには、エージェントの状態のロック解除のために指定されたジェスチャおよび音が含まれる。ロック解除アクションは発声された要求であってもよい。ロック解除イベントは、エージェントによって自律的に検出され、エージェントをロック状態から遷移させる条件である。ロック解除アクションおよびロック解除イベントは両方ともロック解除インジケータである。

解放インジケータ−解放インジケータは、エージェントによって検出される条件であり、エージェントを注意深い状態から遷移させる。

ＥＯＵインジケータ−発話終了は、ユーザの音声セグメントの終わりを示し、これはダイアログ内で交替を構成すると推定される。ＥＯＵは、音声活動検出器（ＶＡＤ）を用いて、ユーザの音声発話において十分な長さの休止を見つけることによって検出され得る。休止期間閾値は、単語内隙間および単語間隙間がＥＯＵを生じさせるには短すぎるように選択される。ＥＯＵは、音声入力を実効的に終了させる、タップもしくはクリック、または物理的なボタンの押下もしくは解放などの、ユーザアクションから生じることもある。最後に、ＥＯＵは、発話の長さを特定の時間量に制限するタイムアウトから生じることがある。

音声活動検出器（ＶＡＤ）−音声信号を無音または他の非発声音から分離するために使用される信号処理技術。これは、発話などの音声セグメントの開始および終了を検出するために使用される。

ダイアログ
発話−音声活動を検出することによって開始され、ＥＯＵ（発話終了）によって終了される、ユーザの音声セグメント。覚醒ワードが存在する場合、発話は、ＶＡＤによって検出されるように、音声の開始時ではなく、覚醒ワード後に始まる。

要求−要求は、エージェントに宛てられたユーザからの発話である。要求は、通常、ユーザに代わってエージェントによって実行されるサービスを要求する。典型的な要求は、情報に対する要求およびアクションに対する要求である。

要求処理−要求を処理するステップは、発話された要求をキャプチャするステップと、発話から翻音を得るために音声認識を実行するステップと、解釈を作成するために翻音された要求を構文解析するステップと、解釈を実行するステップとを含み、それが要求を実行（または遂行）することとなってもよい。

要求実行−情報を検索することによって、またはアクションを実行することによって、解釈された要求に対して動作し、ユーザのために出力を生成する。用語「実行する」および「〜対して動作する」は、同じ意味で使用される。

モーダルダイアログ−ダイアログの過程で、ユーザとエージェントとは交代する。ＩＶＲシステムでは、エージェントにイニシアチブがあり；エージェントが質問し、ユーザが応答する。アシスタントとのダイアログでは、ユーザが一般的にイニシアチブを有し、要求を出し、それにエージェントが応答する。しかし、モーダルダイアログでは、アシスタントがイニシアチブを取り戻し、ユーザからの質問を尋ねる。

図１Ｂのダイアログにおいて、「お母さんにテキストを送って」は、ユーザからの要求である。アシスタントは、要求が不完全であると判断し、要求を完了するためにモーダルダイアログに入る。エージェントは明確にするための質問「わかりました、メッセージは何ですか？」を尋ねる。ユーザは「大好きだよ」と答える。エージェントは、元の要求が完了したことを確認し、「確かにメッセージが送信されました」と返答する。全ダイアログの間、エージェントとユーザとは係属中のままである。

基準ユーザ−エージェントとのダイアログ中、基準ユーザとは、発声された要求がエージェントによって最も最近処理されたユーザである。

新規ユーザ−マン・マシン・ダイアログにおいて、「新規ユーザ」は、エージェントによって音声が受信されている人物である。新規ユーザは、基準ユーザと同じ人であることができる。新規ユーザの発話が発声された要求として処理される場合、基準ユーザは新規ユーザになる。いくつかの実施形態では、エージェントは、係属判定を行うために、新規ユーザおよび基準ユーザの声を比較することができる。

ホットゾーン−「ホットゾーン」は、「コールド」ゾーンとは対照的に、特定のユーザアクションが起こり得る空間領域である。ホットゾーン内のユーザには、コールドゾーンのユーザにはない特権がある。ホット／コールドの区別は、カメラ、マイクロフォンアレイ、または他の適切な技術で行うことができる。

特徴−この言葉は、厳密な定義に抗う。良い辞書では、特徴を「何かの示差的な属性または側面」と定義している。感覚神経生理学では、特徴検出は、神経系が、無関係な背景や騒音に相対するものとして、関連する対象またはそれらの環境内における有機体に関連付けられる可能性が高いきっかけを抽出するために、複雑な自然刺激をフィルタ処理するプロセスである。デジタル信号処理において、特徴および特徴抽出という用語は、感知入力信号からの解析および対象識別のプロセスの一部として、ほとんど同じように使用される。特徴は階層で表示されることが多く、下位レベルの特徴は階層のボトムアップビューで上位レベルの特徴にマッピングされるか、またはその逆が行なわれる。特徴検出モジュールは、エージェントの目標に関連する対象および属性を検出するよう、そのような階層において抽象レイヤを使用して作成されことがよくある。

シーン解析−本開示では、シーン解析は、エージェントの知覚能力をサポートするためにエージェントによって実行される（主にセンサベースの）計算を指すために使用される。シーン解析機能には、下位（シーンの３次元カメラビュー内のエッジや、または音スペクトルなど）であるか、または段階的に上位であるかにかかわらず、すべての感覚的または知覚的機能が含まれる。シーン解析は複雑で多面的であるが、聴覚シーン解析、視覚シーン解析、他の信号の解析、およびセンサ融合技術を含む、十分に確立された分野である。

係属ＦＳＡの省略表現表記および規定
本開示では、エージェントの係属または係属解除の状態がＦＳＡに示されている。ＦＳＡを可能な限り単純に保つために、省略表現表記が使用されている。これらの規定は、モーダルダイアログ、要求処理、ストリーム処理に関するもので、よりコンパクトなＦＳＡを記述するために本明細書全体を通して使用される。

図７Ａは、どのような種類の係属された状態であってもよい係属された状態７００のみを示す。図６Ｂを参照されたい。状態７００には、１つ以上の以前の状態（図示せず）から、ラベル付けされていない遷移を経て、入る。係属された状態７００では、ＥＯＵインジケータ７０２が要求処理７０４をトリガし、続いて次の状態７０８に遷移する。次の状態７０８は、状態７００それ自体であってもよいし、状態７００を含む、より大きなＦＳＡにおける他の任意の状態であってもよい（図示せず）。その単純さのすべてにおいて、図７Ａは、ＦＳＡ図を単純化するために導入されるいくつかの有用な規定を利用している。

モーダルダイアログ
図７Ｂは、モーダルダイアログの使用を可能にするモーダル状態７３０およびその対応する遷移を示す（モーダルダイアログの例について図１Ｂを参照）。エージェントは、ユーザの要求を満たすのに十分な情報が不足している場合にそのようなダイアログを使用し、ユーザに不足している情報を提供するよう求める。曖昧さ除去およびスロット充填は、これの典型的な状況である。

図７Ｂは、モーダルダイアログを明示的にする効果を示す。係属された状態７２０で受信された要求が完了すると（および曖昧でない場合）、図示のように、完全な要求７２２の検出で要求処理７２４がトリガされるが、受信された要求が不完全（またはあいまい）である場合には、新たなモーダル状態７３０に遷移しユーザに質問７２８をすることによって、モーダルダイアログを開く。ユーザは回答を用意し、エージェントによるユーザ回答７３２の受信はエージェントの状態を係属された状態７２０に遷移させて戻す。

モーダル状態７３０では、ユーザはエージェントからの質問に回答することだけしかできず、さらに、モーダル状態７３０のエージェントは、係属された状態７２０に遷移して戻ることだけしかできない。（混合イニシアティブダイアログで生じる可能性のあるより複雑な状況は、ここでは論じられていない。）モーダルダイアログは、係属された状態７２０からモーダル状態７３０に、いくつかのラウンドトリップを伴う。要求を完了するために情報が欠落している間、遷移７２６が生じ、エージェントは別の質問７２８を尋ねる。モーダル状態７３０において、ユーザは質問７３２に答えなければならない（遷移）。エージェントは、モーダルダイアログ中、明らかに係属中である。モーダルダイアログは、他の遷移なしに、係属された状態７２０で開始および終了するので、全モーダルダイアログを係属された状態内に落とし込むことは正当と認められ、これは、図７Ａの係属された状態７００と同一であることが分かる。サブＦＳＡを単一の状態に落とし込むことは、オートマトンの理論では公知の操作である。これらすべての正味効果は、図７Ｂのモーダルダイアログを、図７Ａの係属された状態７００内に効果的に隠すことができることである。

本開示におけるすべてのＦＳＡの簡略化規定は、図７Ｂのように、モーダルダイアログを明示的に示す必要がないということであるが、それにもかかわらず、それらは状態７００のような任意の係属された状態でサポートされる。この省略表現は、各係属された状態について１つの状態および２つの遷移を節約するものであり、モデルダイアログを排除することなくＦＳＡを小さく保つのに必須である。

要求処理
より多くの技術的詳細、および対応する省略表現が、要求処理に適用される。実際には、要求処理は一連の段階で行われる。一実施形態によれば、発話は、まず自動音声認識（ＡＳＲ）を使用してテキストに翻音される。次に、翻音されたテキストは、構文解析および意味解釈を含む自然言語理解（ＮＬＵ）処理を用いて処理される。これに続いて、解釈された要求が実行（履行）される。エージェントは応答を作成し、それをユーザに提示する。いくつかの実施形態では、これらの段階のいくつかは、省略され、落とし込まれ、重なり合わせられ、または細分化されてもよい。一部またはすべての段階は、デバイス上でローカルに実行されてもよい。一部またはすべての段階は、リモートサーバ上で実行されてもよい。１つの段階での失敗は、後の段階の修正または省略を引き起こしてもよい。いくつかの実施形態では、作業は、デバイスとサーバとの間で分割されてもよい。

これらの状況はすべて、要求処理がノードのシーケンスにおいて表現できることを示唆している。図７Ａにおいて、要求処理７０４は、係属された状態７００から次の状態７０８への単一の遷移に関連付けられる。要求処理は複数の段階を含むが、それが遷移上で実行される場合には、それを細分することはできない。柔軟性を高めるためのステップとして、図７Ｃは、要求処理状態７５０という新たな状態を導入する。（他の実施形態では、新たな処理状態７５０をさらに分割して、要求処理のさまざまな段階を露出させることができる）。

図７Ｃにおいて、係属された状態７４０（これは、任意のタイプの係属された状態とすることができる；図６Ｂ参照）のエージェントは、ユーザ要求の完了を知らせるＥＯＵインジケータ７４２を受信し、要求処理状態７５０に遷移し、そこで、要求を処理し、応答を作成し、それをユーザに提示する。要求処理の終了は、応答完了インジケータ７５２である。

いくつかの実施形態では、ユーザに提示される応答は、書かれたテキスト；テキスト読上げモジュールによって作成された音声テキスト；音声セグメント；画像；映像セグメント；またはジェスチャによるロボットの応答など、上記および他の通信行為の任意の組み合わせを含むことができる。いくつかの実施形態では、応答完了インジケータ７５２の検出は、さまざまな要素：画面上にテキストまたはビジュアルコンテンツを表示するための最小持続時間；発声されたテキストセグメントの実際の終わり；音声または映像セグメントの終わり；ジェスチャの終わり；上記の組み合わせ（最新の時刻など）；および上記のいずれかに適用されるタイムアウトまたは遅延などに基づいてもよい。いくつかの実施形態では、エージェントのＦＳＡは、少なくとも部分的にサーバに実装され、エージェントの応答の提示はユーザ対面デバイス上でローカルに行われ；いくつかのそのような実施形態では、応答完了インジケータ７５２は、デバイス内で生じ、サーバに送信されてもよい。これらのすべての場合において、エージェントは、応答完了インジケータ７５２が検出されるまで、図７Ｃの状態７５０にあるままであり；エージェントは次いで次の状態７５４に遷移する。

図７の状態７００のような、本開示におけるすべての係属された状態に当てはまる単純化規定は、要求処理（遷移）７０４は、第１のステップとして、図７の要求処理状態７５０のような、状態および対応する遷移として、別々の処理段階を露出させるために細分されてもよい、ということである。要求処理タスクを細かく細分することで、より多くの段階を露出させることができる。

図７Ｃと比較して、図７Ａの簡略表現は、１つの状態および１つの遷移を、各係属された状態について、および状態として露出される各要求処理ステップについて節約する。この状況では、図７Ｃから図７Ａへの変換は、遷移の鎖の落とし込みを必要とする。具体的には、図７Ｃの７４２と７５２とからなる遷移鎖は、図７ＡのＥＯＵインジケータ（遷移）７０２に落とし込まれる。このような遷移シーケンス落とし込みの間、要求処理ステップは、期待される順序で連結される。当業者には、要求処理タスクのより細かい細分化を用いて同じプロセスが適用されてもよいことは明らかであろう。

割込み
図７Ｃのいくつかの実施形態では、おそらくは、長い応答が完了しておらず、応答完了インジケータ７５４がまだトリガされないため、エージェントは、状態７５０で応答しなくなり、新たな要求を、覚醒インジケータおよび他のインジケータと同様、受け入れることを停止し得る。エージェントが応答しなくなると、応答に「割込」んで中断する方法をシステムが提供しない限り、ユーザはいらいらして、ユーザ体験が悪くなる。

図７ＤのＦＳＡは、応答中に割込みを処理する。これは、図７Ｃの状態および遷移を含む、図７Ｃの番号を付け替えられたコピーを含み、参照番号は２０だけ増分されている（すなわち、係属された状態７６４、ＥＯＵ状態７６２、応答完了状態７７２、および応答後の次の状態７７４）。さらに、要求処理状態７５０は、処理状態７６４と応答状態７７０とに分割され；割込みインジケータ７７６と、応答部分を除いて要求処理が行われたときに生ずる無条件遷移７６６とを含む、新たな遷移も存在する。図７Ｄおよび図７ＣのＦＳＡは、本質的に同じように振舞うが、２つの違いがある。第１に、処理状態７６４における要求処理の完了は、応答状態７７０への遷移７６６をトリガする。第２に、応答状態７７０中に割込みインジケータ７７６を検出することは、応答活動を中断する。図７Ｄの具体的な実施形態においては、割込みは、処理が終了するとすぐに、応答がユーザに提示されている全時間の間、サポートされる。いくつかの実施形態は、より早い段階または後の段階で割込みをサポートする。

割込みインジケータを規定する基準は、実施形態によって異なる。割込みする最も一般的な方法は、新規ユーザの声が大きいときである。エージェントが音声を発している間に、エージェント自身の音声出力の上に、割込みユーザの声を聞かなければならない。いくつかの実施形態では、ユーザの声が、エージェントにその音声出力を直ちにミュートさせるのに十分なほど大きなものであれば、十分である。いくつかの実施形態では、エコー（エージェントの音声出力）を減衰させることによってユーザの音声を強調するために、エコーキャンセレーションが使用される。

いくつかの実施形態では、ユーザの音声入力は、割込みインジケータおよび発話の開始の両方とすることができ；いくつかのこのような実施形態では、割込み後の次の状態７７８は係属された状態であり、発話は要求として直ちに処理される。

いくつかの実施形態は、発声音声以外の割込みインジケータをサポートする。他のインジケータでのように、割込みインジケータには、タップ、スワイプ、クリック、ジェスチャなどのユーザアクション、またはユーザによるある特定の空間領域への出入りのような、エージェントが自律的に検出できるその他の条件が含まれる。

本開示の残りの部分では、包括的なＦＳＡを小さく保つために、割込みの可能性は明示的には考慮されないが、割込みオプションは開示されたＦＳＡと組み合わせることができることが理解される。具体的には、図７Ｄの実施形態およびその変形例は、単一の係属された状態がさまざまなより詳細なＦＳＡを表し得る図７Ａのコンパクトな構成の変形例である図７Ｃの変形例と考えることができる。

本開示の残りの部分は、要求を処理し、ユーザに対する応答を作成し、それをユーザに示すすべてのタスクが要求処理要素として単一の遷移で実行されるコンパクトＦＳＡを使用する。これにより、各要求処理遷移ごとに少なくとも１つの状態が節約される。そのような遷移部の拡大、ならびに図７Ｃおよび図７Ｄに関連付けられるすべての考慮事項は、以下に説明するＦＳＡに適用可能である。

ストリーム処理（増分処理としても知られる）
いくつかの実施形態はストリーム指向型である。ストリーム指向型の（増分的な）実施形態では、要求処理の１つ以上の段階が、通常はマルチスレッド態様で、並列で実行される。１つの段階の出力が次の段階への入力であるパイプラインでは、異なる処理段階が重複することがある。

完全に増分的な実施形態では、ＡＳＲ、構文解析、および解釈のすべての段階が重なり得る。そのような実施形態は、増分パーサーを必要とし、発話（入力発声音声ストリーム）の処理は、ＥＯＵに遭遇する前に開始される。連続する処理段階（ＡＳＲ、構文解析、解釈）が時間的に重なるとき、音声発話の開始は、ＥＯＵが生じる前に処理される。

ストリーム指向型の実施形態では、図７Ａおよび図７Ｃのそれらのような、これまでに説明したＦＳＡの適度な適合が必要である。このような実施形態では、ＥＯＵインジケータが要求処理をトリガするシーケンシャルな実施形態とは対照的に、要求処理はＥＯＵを待たない。ここで、要求処理は早期に開始され、おそらくは発話が始まるとすぐに開始される。技術的には、処理の早期開始を実際のＥＯＵインジケータとして扱うことは、本開示で使用されるＦＳＡ枠組みをストリーム指向型（増分的）実施形態に適合させるのに十分である。したがって、本開示は、ストリーム指向型の実施形態も包含し、ＥＯＵインジケータの定義における小さな拡張以外の変更はない。

図７Ａに示すようなコンパクトなＦＳＡ係属された状態の使用を可能にするために本開示で使用される簡略表現表記および規定を要約するために、
モーダルダイアログは、図７Ｂに記載されるように処理され；
要求処理の段階は、図７Ｃに記載されるように導入されてもよく；
割込みは図７Ｄに記載されるようにサポートされ；
ストリーム指向型（増分的）実施形態もサポートされる。

係属ポリシーＦＳＡ
いくつかの係属ポリシーが以下で議論される。これらのポリシーは、主に１つ以上の対応するＦＳＡを使用して記載される。参照および比較の目的で、単純な係属ポリシーが含まれている。１つ以上の対応するＦＳＡを使用して、いくつかの非従来的なポリシーが提示される。

１）ワンタイム係属ポリシーは周知であり；それは覚醒ワード疲労につながり、他のポリシーを作成する動機を与える；
２）ロックされた係属ポリシーは、エージェントの係属状態をロックおよびロック解除する要求を使用して、係属に対するユーザの明示な制御を与える；
３）確保されたエージェントポリシーは、ユーザが限られた期間の間エージェントを制御し、他のユーザを無視することを可能にする；
４）注意深いエージェントポリシーは、自律エージェントが係属および係属解除の判断を行うことを可能にする；
５）ハイブリッドポリシーは、ロックされた係属ポリシーと注意深いエージェントポリシーとを統合する。特に、ユーザはエージェントの自律的な挙動を無効にすることができる。

各ポリシーＦＳＡは、多くの可能な実施形態を有する。各々は、同じタイプのポリシーのファミリーを表わす。ポリシータイプおよびそれらの関連付けられるＦＳＡが係属挙動を決定する。

ワンタイム係属
図８は、いくつかの仮想アシスタントで使用される係属ポリシーを示す。このＦＳＡは、休眠状態８００とワンタイム状態８１０とを有する。休眠エージェントは、覚醒ワードなどの覚醒インジケータ８０４に応答して、ワンタイム状態８１０に遷移し、ワンタイム状態８１０において１つのユーザ要求を処理することができる。ワンタイム状態８１０にある間にＥＯＵ８１６を検出すると、エージェントは要求処理８１８を開始する。エージェントは直ちに休眠状態８００に戻る。別の要求を処理し得る前に新たな覚醒インジケータ８０４が必要であり、それはユーザ体験の低下及び覚醒ワード疲労に至る。

ロックされた係属ポリシー
ロックされた係属ポリシーは、ユーザにエージェントの係属のロックおよびロック解除の明示的な制御を与える。ロックされている間、エージェントは覚醒インジケータを必要としない。

無条件ロック
図９Ａは、一実施形態による、無条件ロックの図を示す。それは、ロック状態９８０および隣接する状態との間の遷移からなる、より大きなＦＳＡの小さな部分のみを示す。ロック状態９８０には、無条件のロックインジケータ９７２に続いて入る。ロック状態９８０のＦＳＡの挙動は単純である。ＥＯＵ９８３を検出すると、エージェントは要求処理９８８を実行し、ロック状態９８０に戻る。したがって、エージェントは、ロック解除インジケータ９８１またはタイムアウト９８４のいずれかを検出するまで、覚醒インジケータを必要とせずに、連続する要求を処理することができる。図９Ａでは、タイムアウトおよびロック解除インジケータが別々に示されているが、両方の遷移が同じ状態に進む場合には、タイムアウトをロック解除インジケータとマージすることが可能である。

いくつかの実施形態では、ロックインジケータ９７２は、自然言語発声要求または曖昧でない規定ジェスチャなどの明示的なユーザアクションでなければならない。これにより、エージェントを誤ってロックする可能性がなくなる。少なくとも１つのロック解除インジケータ９８１が利用可能であるため、ミダス王の運命を共有するリスクは排除される。

いくつかの実施形態では、ロックインジケータ９７２は自然言語要求である。可能なロック要求には、たとえば、「注意して」、「始めよう」または「聞いて」が含まれる。

いくつかの実施形態では、ロック解除インジケータ９８１は自然言語ユーザ要求である。可能なロック解除要求の例には、たとえば、「終わりました」または「おしまい」または「中断」または「有難う」が含まれる。

条件付きロック
ロック要求は、自然言語を使用するので、非常に表現力があり得る。「聞いて」のようにエージェントを無条件にロックする代わりに、ロック要求は、「大人の言うことを聞いて」のようにロック条件を指定できる。一般に、ロック条件の使用により、ユーザは、ロックされた係属をより正確に制御することができる。

図９Ｂは、条件付きロックの図を示す。図９ＢのＦＳＡは、図９ＡのＦＳＡのように振る舞うが、重要な違いがある。ロックインジケータ９８２は、述語である（すなわち、ブール値に評価される）関連付けられる「ロック条件」９９９を有する。ロック条件９９９は、エージェントによるその後の使用のために永続的なメモリに格納される。

ロック状態９９０では、ロック条件９９９が指定されており、エージェントは覚醒インジケータを必要とせずに、連続する要求の条件付き処理を実行する。エージェントは、ロック解除インジケータ９９１またはタイムアウトインジケータ９９４まで、要求の条件付き処理を実行し続ける。ロック解除インジケータまたはタイムアウトに続いて、エージェントはロック状態９９０を出る。要求の条件付き処理は、（ａ）指定されたロック条件９９９がまず評価されること；および（ｂ）ロック条件が満たされている場合、要求が処理されることを意味する。ロック条件が満たされない場合、要求は無視される。

ロック条件９９９は、エージェントによって必要とされるときに評価できるフォーマットで記憶される。さまざまな実施形態において、ロック条件９９９は、エージェントがロック条件を評価するために解釈できる、動的にロード可能なライブラリ、解釈可能コード、または他のデータフォーマットとして記憶される。いくつかの実施形態では、条件は、エージェントの感知入力およびその知覚解析によって決定される、外部の実世界の対象（人を含む）およびそれらプロパティの環境における存在であってもよい。そのようないくつかの実施形態では、ロック条件は、エージェントのソフトウェアの内部変数、たとえば、最後の要求から経過した時間、または対象（人を含む）およびそれらのプロパティを追跡するシーン解析モジュールによって維持される複雑な状態などにも依存する。

条件付き要求処理９９８は、以下のように動作する。現在の要求の終了を印すＥＯＵ９９３を検出すると、エージェントはロック条件９９９を評価する（９９５）。結果値が偽である場合、エージェントは条件付き要求処理９９８をバイパスし、要求を処理せずにロック状態９９０に戻る。ロック条件９９９の値が真である場合、条件付き要求処理９９８が発生し、次いで、エージェントはロック状態９９０に戻る。図９Ｂでは、タイムアウトインジケータ９９４とロック解除インジケータ９９１とは別々に示されているが、これらの２つの遷移が同じ状態に進むと、ロック解除インジケータの単なる１つのタイプとしてのタイムアウトとなる。更なる詳細は、図１１と関連して与えられる。

ロック条件とロックインジケータ９８２との関連付けはオプションである。ロック要求がロック条件を明示的に指定しない場合、ロック条件９９９は真として扱われる。この場合、図９ＢのＦＳＡは、図９Ａのそれとして振舞う。無条件ロックは、ロック条件９９９が真である、条件付きロックの特別なケースとして扱うことができる。代替的に、条件なしの場合は条件付きロックから除外することができ、その場合、図９Ａおよび図９Ｂは、異なるシナリオを表す。

ロックされた係属ＦＳＡ
図９Ｃに示すロックされた係属ポリシーは、ロック解除インジケータ９２２が検出されるまで、「エージェントの注意をロック」し、無期限に覚醒ワードの使用を回避する簡単な方法を提供する。図９ＣのＦＳＡは、図８の単純なＦＳＡの番号変更されたコピーを、図９ＢのＦＳＡ要素の番号変更されたコピーと組合わせた結果、完全なロックされた係属ＦＳＡを作成している。図９Ｂのタイムアウトインジケータ９９４は、ＦＳＡを単純化するために、ロック解除インジケータ９２２とマージされている。

図９Ｃのロックする係属ＦＳＡの各部の挙動は、図８または図９Ｂについて先に説明した。休眠状態９００では、覚醒インジケータ９０４がワンタイム状態９１０への遷移を引き起こし、その状態において、ＥＯＵインジケータ９１６が要求処理９１８をトリガし、その後休眠状態９００に戻るが、ただし、それは、ロックインジケータ９１２が検出される場合を除いてである。ロックインジケータ９１２の検出は、代わりに、ロック状態９２０への遷移を引き起こす。ロック状態９２０では、ＥＯＵインジケータ９２４に続いて、ロック条件が満たされれば（９２３）、新たな要求が処理される（９２８）。ロック解除インジケータ９２２の検出が休眠状態９００に戻る遷移を引起こすまで、ロック状態を出ることなく、条件付き要求処理が繰り返し実行される。

ロックインジケータおよびロック解除インジケータは、規定されたジェスチャ、規定された音、またはエージェントがそれのセンサおよび知覚知能、それの他の入力、およびそれの内部状態に基づいて認識できる任意のイベントであり得る。ロック解除インジケータ９２２の重要なケースは、タイムアウトの使用である。ロックインジケータ９１２およびロック解除インジケータ９２２の両方に当てはまる別の重要な特殊なケースは、エージェントの状態をロックまたはロック解除するための自然言語要求の使用である。発声によるロック要求およびロック解除要求は双方とも大きな関心事であり、なぜならば、それらは、発声によるコミュニケーションにのみ依存し、ハンズフリーの動作を提供するが、これらの要求はより多くの制御を与えるよう洗練され得るからである。自然言語ロック要求は要求処理９１８中に認識されるが、これらの特殊要求が認識されると、それらは次の遷移を休眠状態９００の代わりにロック状態９２０に向けることに注目されたい。充分な技術的正確性を期して、図９Ｃに示すように、これをより明確にするために、要求処理９１８を図７Ｃにおけるように分解することによって、図７Ｃの状態７５０に類似して、新たな要求処理状態９１８からロック状態９２０または休眠状態９００のいずれかへの遷移を露出させることができる。同様に、自然言語ロック解除要求は、要求処理９２８中に認識され、充分な技術的正確性は、図７Ｃの状態７５０に類似する状態を導入することを必要とするであろう。しかしながら、これらは充分に単純な技術であり、図９Ｃの意味は、ＦＳＡに複雑さを追加することなく明らかである。

追加のロック／ロック解除遷移
図９Ｄは、図９Ｃの番号を付け替えたコピーであり、新たなロック遷移およびロック解除遷移を伴う。図９Ｄは、ＥＯＵ９５６（図９ＣのＥＯＵ９１６と同様である）、要求処理９５８（図９Ｃの要求処理９１８と同様である）、ＥＯＵ９６４（図９ＣのＥＯＵ９２４と同様である）、条件付き要求処理９６８（図９Ｃの条件付き要求処理９２８と同様である）、およびロック条件９６９（図９Ｃのロック条件９２９と同様である）を示す。インジケータロック２ ９４８およびロック解除２ ９６６が、図９Ｃの既存のロック／ロック解除インジケータ、ロック１ ９５２およびロック解除１ ９６２に追加される。図９ＤのＦＳＡの挙動は、追加のインジケータを除き、図９Ｃのそれと同様であり、追加のインジケータの効果は自明である。図９Ｃでは、４つのロックおよびロック解除遷移はすべてオプションになり、それらを破線で示すことにより表現される事実である。追加のインジケータの使用例がいくつかの解析の後に与えられる。

ロック解除インジケータの集合は、インジケータ集合ロック解除およびロック解除２の和集合である。ＦＳＡは決定論的でなければならないので、集合ロック解除１ ９６２およびロック解除２ ９６６は互いに素である。図９Ｃまたは図９Ｄにおいて、ロック解除１ ９２２およびロック解除２ ９６２は休眠状態に遷移する。図９Ｄにおいて、ロック解除（インジケータ）９６６はワンタイム状態９５０に遷移する。これらのロック解除インジケータはすべて、ユーザが「ありがとう」、「停止」、「おしまい」、「さよなら」または「ロック解除」と言うような、発声による要求であり得る。ジェスチャ認識機能が利用可能な場合、特定のユーザジェスチャ、たとえばエージェントから身体の向きを外す、または特定の手ジェスチャ、または空間領域を出るといった全身ジェスチャなども、ロック解除インジケータであり得る。

ロック解除インジケータは、タイムアウトであることもできる。いくつかの実施形態では、タイムアウトイベントは、ユーザが要求を出したり、または何らかのアクションを取ることなく、指定された量のアイドル時間が要求と要求との間で経過したときに発生してもよい。いくつかの実施形態では、タイムアウトは、最初にロック状態に入ってから指定された合計時間が経過したときに発生する。タイムアウトは、ユーザによって開始されないインジケータである。本開示では、タイムアウトは、ロック解除インジケータ間でカウントされるなか、ＦＳＡにおいて常に明示的に示されるわけではないが、それらの使用の可能性は常に想定される。

ロックインジケータの集合は、インジケータ集合ロック１ ９５２およびロック２ ９４８の和集合である。インジケータの集合ロック１ ９５２およびロック２ ９４８は、休眠状態９４０で認識されるロック２（インジケータ）９４８は発声された要求であり得ないことを除いて、任意に選択することができ（特に、それらは重なり得る）；係属された状態単独で要求処理が可能である。したがって、ロック２（インジケータ）９４８は、規定された音または規定されたジェスチャで構成されるにすぎなくてもよく；対照的に、ロック１（インジケータ）９５２は、自然言語要求の表現力から利益を得ることができる。ロック２が空でない場合、休眠状態９４０の活動は、覚醒９４４インジケータおよびロック２ ９４８インジケータの両方を検出することを含む。

休眠状態ロジック
このセクションでは、ロックされた係属のトピックに戻る前の休眠状態ロジックを説明する。図１０は休眠状態ロジック１０００の説明であり；すべての休眠状態に広く適用することを意図している。議論は図９Ｄの議論に続き、２つ以上のインジケータおよび２つ以上の次の状態を有する休眠状態９４０が、休眠状態ロジック１０００のより一般的な表現を必要とする。

休眠エージェントは発声された要求を処理しないが、許可されたすべての遷移を検出するためにそれの入力を能動的に監視しなければならない。休眠状態９４０などの休眠状態では、音声対応エージェントは、「やあ、シリ」または「ＯＫ、グーグル」のような覚醒ワードを検出するために、少なくともその音声入力を監視しなければならない。いくつかの実施形態では、１つより多くの覚醒ワードが存在する。いくつかのそのような実施形態では、異なる覚醒ワードは、同じ遷移または異なる遷移をもたらし得る。

覚醒ワードは通常、所定の組の覚醒ワードの１つに一致するようにその音声入力を継続的に監視するワードスポッターによって検出される。高速ワードスポッティング技術のための計算上の要件は、現在の基準に従って適度である。いくつかの実施形態では、ユーザ対面デバイスが、ワードスポッティングをローカルに実装するのに十分な計算資源を有し、サーバベースの実装が伴うであろう通信コストおよびレイテンシの両方を回避する。

いくつかの実施形態では、唯一のセンサはマイクロフォンであり、覚醒インジケータは覚醒ワードである。したがって、感知入力処理１００２は、１つ以上の覚醒ワードについて、入力音声に対してワードスポッティングを実行する。そのような処理は、典型的には、一定のデューティサイクルに基づいて周期的な間隔で実行される。最低レイテンシに対しては、デューティサイクルは単一の音声サンプルと同じほど短くあり得るが、計算コストは過剰である。音声処理のためのデューティサイクルは、典型的には、たとえば１０ｍｓ〜１００ｍｓ（１００Ｈｚから１０Ｈｚまで）のように、はるかに長い。デューティサイクルの間、感知入力処理１００２の後、ステップ１００４で注意して聞かれた覚醒ワードのいずれかを認識できない場合（Ｎ出口分岐）、感知入力処理１００２は次のデューティサイクルの間継続する。ステップ１００４で覚醒ワードが認識された場合（Ｎ出口分岐）、ステップ１００６で、認識された覚醒ワードに関連付けられる状態遷移が選択され、対応する次の状態への遷移が実行される。

他の実施形態では、規定されたジェスチャまたは規定された音などの代替的な覚醒インジケータが、覚醒ワードインジケータに加えて、またはその代わりに使用される。そのような代替的な覚醒インジケータは、各々独自のタイプの処理およびデューティサイクルを有するさまざまなモダリティに属する。たとえば、キーボードの押下、マウスクリック、タッチスクリーンタップ、スワイプ、特殊音、および視線方向に基づくイベントを検出することは、インジケータとして各々が使用できる異なるモダリティに属する。（同様の注釈は他のインジケータにも適用される）。

あるインジケータは、より単純なインジケータの連結に基づくこともでき；たとえば、アイコンタクトをして同時に話し始めることは、覚醒インジケータとして扱うことができる。さらに、異なるインジケータは異なる状態への遷移を引き起こし得る。図９Ｄは、ワンタイム状態９５０に遷移する（異なる）覚醒インジケータに対する、ロック２インジケータがロック状態９６０に遷移する例を示す。

複数の感知入力処理（タスク）１００２（図１０に点線のボックスおよび線で示す）を使用すると、インジケータの検出を、そのモダリティおよびその特定のインジケータに最も適切な処理タスク（処理１００２の一部）を使用して行なうことができる。したがって、特定の実施形態に応じて、多くの感知入力処理１００２のサブタスクが並列または直列に実行されていてもよい。いくつかの実施形態では、異なるモダリティは、それらの感覚処理のために異なるデューティサイクルを有する。ステップ１００４で感知入力処理１００２のサブタスクのいずれかを使用してインジケータを認識することに失敗すると、感知入力処理１００２を継続する結果となる。逆に、並列認識タスク（ステップ１００２および１００４）のいずれかの成功は、謹聴/注目されたインジケータに対する休眠状態の走査の成功をもたらす結果となる。謹聴/注目されたインジケータが識別されると、所定の遷移がエージェントを次の状態にする。

いくつかの実施形態では、感知入力処理タスク１００２の一部またはすべてが、サーバまたは別のデバイスに委譲される。いくつかの実施形態では、インジケータの検出がリモートサーバではなくローカルに実現される場合、通信コストおよびレイテンシが最小限に抑えられる。良いユーザ体験のためには、イベント検出におけるレイテンシがかなり低いことが重要である。モダリティ、ローカル処理能力、ローカルネットワーク、リモートサーバの可用性などに応じて、多くの設計のバリエーションおよび最適化を使用できる。

無条件ロックの使用
図９Ｃにおいて、ロックインジケータ９１２は、無条件のロック要求（たとえば、「聞いて」など）であってもよい。無条件にロックされたエージェントは、ロック解除インジケータを検出するまですべての要求を処理する。ロック条件９２９が真に設定されると、図９ＣのＦＳＡは、無条件ロックを実施する。この場合、ロック条件の評価９６３は常に真を返し、要求処理９２８が常に発生する。図９Ｂの代わりに図９Ａに基づいて、図９Ｃの簡略版を描くことが可能であるが、これは必要ではなく、なぜならば、無条件ロックは条件付きロックの特別なケースとして扱うことができるからである。可能な無条件ロック要求の例には、「注意して」、「始めよう」または「聞いて」などのフレーズが含まれる。ロック解除要求の例には、「終わりました」または「おしまい」または「ありがとう」が含まれる。

無条件ロックは実際には非常に重要であり、なぜなら、それは非常に単純であるが、覚醒ワード疲労の問題に対処するために多くをなすからである。無条件にロックされた係属は、覚醒インジケータを介在させることなく、任意の長い要求のシーケンスを処理できるようにすることで、大きな価値をもたらす。

その恩恵は、わずかなコストで生じる。ロックされた係属の期間の開始および終了を区切るために、「注意して」および「おしまい」と言うなど、インジケータのロック／ロック解除の対を使用して、ロックされた要求のシーケンスをひとまとめに扱うために、なんらかのオーバーヘッドがある。ロックされた要求のシーケンスが十分に長い場合、このオーバーヘッドは無視できる。状態をロックするかどうかを決定する際に、ユーザはこのトレードオフに対して制御を有するため、それは問題ではない。ロックされた係属制御の自然さも、自然言語のロック要求およびロック解除要求に対して適切な選択が行われていれば、それほど問題にならず、ロックの概念は、それ自体、非常に自然である。その他の自然で意味のあるロック／ロック解除インジケータの対については後述する。

条件付きロック条件の使用
ロック要求は、自然言語で表現されているので、非常に表現力があり得る。ロック条件９２９を使用することにより、ユーザは係属を大きく制御することができる。概して、ＮＬＵシステムは、複雑なロック条件を表すロック要求のカスタムサブ言語（または「ミニドメイン」）を認識することができる。ある単純なスキーマは、「聞いて＜ＮＬ−条件＞」という形式をとることができ、幅広くさまざまな＜ＮＬ−条件＞自然言語表現がさまざまな有用なロック条件を指定できる。

無条件ロックは、エージェントに話しかける任意のユーザに対してエージェントをロック状態に保つが、これは常に理想的であるわけではない。たとえば、「私の言うことを聞いて」のようなロック要求は、要求を行っているユーザ（ここでは基準ユーザと呼ぶ）の利益のためにエージェントを他のすべてのユーザの排除に対して「ロック」するロックインジケータ９１２である。事実上、基準ユーザは、エージェントの注目を受ける唯一のユーザになる。

いくつかの実施形態では、エージェントは、第１の要求の時点で、基準ユーザの特徴付け（たとえば、基準特徴付け）を構築する。第２の要求の時点で、エージェントは新規ユーザの特徴付け（たとえば、新たな特徴付け）を構築する。エージェントは、第１の特徴付けを第２の特徴付けに一致させることを試みる。一致が不十分な場合、エージェントは第２の要求を無視する。

いくつかの実施形態では、基準ユーザへのロックは、声紋を用いた音声に基づいて達成されてもよい。エージェントは、第２の要求を処理するかどうかを決定するために、要求の音声から計算された声紋を基準ユーザの声紋と照合しようと試みることができる。エージェントは、声紋間に十分な一致がある場合にのみ、要求を処理する。声紋は、要求が基準ユーザからであるかどうかを確認する多くの方法の１つに過ぎない。

すべてのユーザまたは単一のユーザの代わりに、ロックされた係属の他の変形は、指定されたユーザの組を含むことができる。より複雑なロック条件の例については、「大人の言うことを聞いて」というロック要求は、大人へのロックされた係属を、子供の排除に制限し得る。ロック条件は、音声クラス、すなわち「大人」音声クラスを指定する。一実施形態では、ロック条件が満たされていることをチェックすることは、出力がたとえば３つの音声クラス前提：子供の声、大人の男性の声、および大人の女性の声を認識する３方向音声分類部の出力に基づいて実施することができる。追加の音声クラスは、たとえば、方言、幼児、１０代の若者などに基づいて識別することもできる。そのような実施形態では、ロック条件によって指定された音声クラス（「大人」など）を音声分類部からの音声クラス前提と照合することができる。いくつかの実施形態では、他の感覚モダリティは、子供と成人との間の視覚に基づく区別のような、ロック条件の評価に貢献することもできる。

ロック要求の別の例では、「３分間聴いて」は、ロック状態９２０で費やされる時間期間に対するタイムアウトを指定するロック条件９２９を作成する。タイムアウトに達すると、ロック解除インジケータ９２２がトリガされる。ロック解除要求は、ロック状態を早期に終了することにより、タイムアウトを未決にする。

この実施形態では、その後のロック要求（「５分間聞いて」）がタイマをリセットすることができ、「もう５分聞いて」のようなロック延長要求がタイマを調整することができる。

複雑な条件付きロック要求には、たとえば、「キッチンでは大人の言うことを聞きなさい」または「私が立っている限り、午前１１時までは私に注意を払いなさい」など、複数の条件が組み合わされた複合要求が含まれる。一般的なＮＬＵシステムのような実現例では、パーサーインタープリタが自然言語を認識し、それをアクション可能な形式、この場合ではロック条件９２９に変換する必要がある。示されているように、ロック条件は、要求の環境において、要求が実行されるかどうかを判断するために、評価される。

たとえば、「キッチンでは大人の言うことを聞きなさい」についてのロック条件を満足させることは、２つのより単純な条件：（１）話者が大人として識別される（これは、音声分類部、視覚シーン解析、またはそれらの２つの組み合わせを用いて判断可能である）こと；（２）話者がキッチンにいる（この次元のシーン解析は、マイクロフォンアレイ、カメラ、および他のセンサを含む任意の数のセンサに基づくことができる）ことを満たすことに依存する。同様に、「私が立っているときは、午前１１時までは私に注意を払いなさい」についてのロック条件を満たすことは、３つのより単純な条件：（１）話者が私であると識別されること；（２）時間が午前１１時より早いこと；および（３）私が立っていること、を満たすことに依存する。条件（１）は、ユーザの連続性を表し、これについては後で論ずる。条件（２）は、現在の実時間にアクセスすることに基づいている。条件（３）は、シーン解析の特定の局面、姿勢の認識を含む。

いくつかの実施形態では、条件は空間的要因に基づく。これについては後のセクションで説明する。他の区別がなされてもよい。たとえば、特定の資格情報を与えるバッジを有する人だけが、要求を出したり特定のアクションを起こすことができる。

これらの例から外挿すると、ロック条件の表現のための言語は、システム状態情報だけでなく知覚情報へのアクセス（シーン解析のさまざまな態様など）を含むべきであることは明らかである。キッチンに誰かがいるかどうかを知るには、既知のキッチン境界線に対して話者の位置を推定できるシーン解析サブシステムの一部として、マイクロフォンまたはカメラまたは他のセンサが貢献することができる。同様に、大人／子供の区別は、音声分類部の出力だけでなく、視覚データから抽出された高さ測定値、および顔認識などの視覚的特徴または対象追跡に基づくことができる。

ロック状態ロジック
図１１は、図９Ｂの包括的なロック状態９９０のようなロック状態で使用されるロジック１１００を示す。同じロジックが、必要な変更を加えて、図９Ｃの状態９２０、図９Ｄの状態９６０、図１６Ａの状態１６２０、および図１６Ｂの状態１６７０のようなロック状態の具体的な例に適用される。ロック状態９９０（図９Ｂ）では、ロックインジケータ９８２に関連付けられるロック条件が、ステップ１１０２（図１１）で受信され、オプションとして処理され、ロック条件９９９として記憶される。条件が記憶される前に、いくつかのフォーマット変更または処理が必要とされてもよい。いくつかの実施形態では、記憶されたロック条件９９９は、エージェントが別途記憶するデータを参照し；たとえば、ロック要求が「私の言うことを聞いて」であり、新規ユーザの声が基準ユーザの声と一致することをチェックするために音声照合が使用される場合、ステップ１１０２において、基準ユーザからの音声を用いて基準声紋を作成する。

次のステップ１１０４は、感知入力処理を含む。入力音声の前処理および他の入力イベントの処理は、各々がそれ自体のデューティサイクルを伴って、独立して実行される。その目標は、同時に多数の可能なインジケータに対応することである。必要なシミュレートされる並列処理のためにシングルスレッドおよびマルチスレッドの実現例が存在する。これは、図１０に関連して感覚入力処理１００２に対して論じたロジックに類似している。エージェントがステップ１１０４で検出することができるイベントは、ＥＯＵ、ならびに外部イベントおよびタイムアウトなどの内部イベントを含む他のイベントを含む。説明を簡単にするために、タイムアウトはそれらがあたかも「感覚的」な入力であるかのように扱われる。

ＥＯＵイベントが検出され、発声された要求を完了すると、ロック条件の評価１１０６が行われる。結果が真であれば、要求処理１１０８が行われる。要求がロック解除要求として認識された場合（１１１０）、エージェントは、対応する、ロックされていない次の状態に遷移する。そうでなければ、エージェントはロック状態９９０に留まり、ステップ１１０４でその感覚入力を処理し続ける。いくつかの実施形態では、感覚入力を処理するステップ１１０４は、基準ユーザの声紋を更新することを含み；言い換えると、より多くの音声入力が収集されるにつれて、基準ユーザの音声モデルが改善され適合される。

ステップ１１０４で非発声音声イベントが検出される場合、エージェントは、ロック解除インジケータ９９１またはタイムアウトインジケータ９９４が認識されるかどうかをチェックする（１１２０）。「ｙｅｓ」の場合、エージェントは対応する次の状態に遷移する。そうでなければ、エージェントはロック状態９９０に留まり、その感覚入力を処理し続ける。いくつかの実施形態では、感覚入力を処理するステップ１１０４は、（たとえば、１つ以上の視点からの方位および距離に基づいて）基準ユーザの位置および他のシーン解析パラメータを更新することを含む。したがって、基準ユーザのシーン解析記述は、より多くの発声音声入力が収集されるにつれて、改善され適合される。

ロック条件の評価１１０６は、異なる形態を取ることができる。ロック要求が「私の言うことを聞いて」である場合、ロック条件９９９は、（ロック要求を発話した）基準ユーザと（ロック状態において新たな要求を発話した）新規ユーザとが同じ人物であることを要する。この条件はユーザ連続性と呼ばれる。

ユーザ連続性
新規ユーザが基準ユーザと同じであるかどうかを見出すことは、たとえば、「私の言うことを聞いて」ロック要求の実施において、大きな関心事である。新たな発話を生成するユーザと所定の基準ユーザとの間で同一性の一致が見つかった場合、ユーザ連続性条件は成功し；そうでなければ、ユーザ非連続性が観察される。ユーザ連続性をテストすることは、「私の言うことを聞いて」などのロックコマンドで便利であるが、同じ機能が他のポリシーでさらに使用される。

いくつかの実施形態では、唯一の入力はマイクロフォンである。ユーザ連続性をテストするために、新規ユーザの声が基準ユーザの声と一致するかどうかを確認するために音声照合が使用される。これは声紋で行われる。ステップ１１０２で、基準ユーザからの音声が記憶または使用されて、必要な基準声紋を作成する。新規ユーザによる新たな発話の開始および終了が、ステップ１１０４でＶＡＤが使用されて検出され、新規ユーザの声紋が計算される。ユーザ連続性をテストするために、評価１１０６は、新規ユーザの声紋を基準ユーザの声紋と比較する。

マイクロフォンが唯一の入力である場合、声紋の使用は不可欠である。しかしながら、追加のセンサが利用可能な場合、多くの追加技術がユーザ連続性のテストに貢献できる。多くのきっかけは、基準ユーザと他のユーザと、または承認されたユーザと他のすべてのユーザとを区別することができる。たとえば、方位検出は、１つ以上のマイクロフォンまたは１つ以上のカメラを使用することができ、視覚情報および聴覚情報は、より大きな正確性を得るためにしばしば組み合わせることができる。一般に、多くのセンサ、多くの特徴、およびセンサにわたる特徴融合を含む、シーン解析のすべての局面が、関連性を持ち得る。

いくつかの実施形態では、１つ以上のカメラが使用され、エージェントはコンピュータビジョン技術を使用して基準ユーザを追跡することができる。いくつかの実施形態では、カメラおよび他のセンサがユーザの識別を可能にする。マイクロフォンおよびカメラは誰が話しているのかのＩＤを伝えることができる。そのようなユーザＩＤが分かっている場合、ユーザ連続性の問題は些細なことになる。

ユーザＩＤがなければ、マッチング技術、トラッキング技術、またはその両方の組み合わせによってユーザ連続性にアプローチすることができる。いくつかの実施形態では、エージェントは、エージェントの感覚能力および知覚能力に基づいて、新規ユーザが基準ユーザと同じ身元を有するかどうかを高い確信度で知ることができる。複数のセンサ、関連する特徴を抽出するＤＳＰレイヤー、機械学習および分類技術、音声解析、聴覚シーン解析、視覚シーン解析などは、マッチング、トラッキング、またはその両方を使用してユーザ連続性問題を解決するために必要な知覚的質問に返答することができる。

マッチング
マッチングアプローチは、利用可能な知覚特徴を利用して、２人のユーザを比較して、それら２人が同じかどうかを判断することを指す。たとえば、異なる色のシャツを有する、または起立時に同じ高さでない２人のユーザは、異なる可能性が高い。これらの特徴は容易には変わらない。一実施形態によれば、エージェントは、すべてのユーザのいくつかの衣服を認識することができ、それは、（スポーツチームが会うときのように）近くの他の人が類似の衣類を着用しない場合に特に有用である。これには、色、形、質感などが含まれる。

抽出されるすべての知覚特徴が「十分な」程度に一致する場合、２人のユーザは一致しているとみなされる。いくつかの実施形態では、「十分性」は、異なる閾値を各特徴に対して１つ用い、十分性結果の「ＡＮＤ（論理積）」をとることによって、決定される。別の実施形態では、各特徴について計算された一致スコアを組み合わせて、単一の閾値と比較される全体スコアを得る。ベイズセンサ融合技術は、この状況をより体系的に扱うことができる。すべての場合において、ｙｅｓ/ｎｏの判断を下すために少なくとも１つの閾値が関与している。

使用される場合、マッチングは、新たな要求の時点で収集される新規ユーザの特徴を、基準ユーザの特徴と比較する。いくつかの実施形態では、感覚信号は、たとえば、おおよその位置（距離測定および方位測定）、身体の形状および大きさ、衣服の色と質感、アクセサリに基づいて、声紋一致、顔認識一致、および身体特徴について使用することができる音声データおよび視覚データを含む。

十分に効果的であるためには、一致度は、近くのユーザ間のデータの多様性によって影響されるべきである。たとえば、同じスポーツチームのメンバーは、衣服で区別するのは難しくなるが、相手チームのメンバーからは簡単に区別される。ベイズモデルは、確率を有用な方法で較正するため、関連性がある。

上記の例では、異なる色のシャツの２人のユーザが異なる可能性が高いと仮定される。これは充分なヒューリスティックであり、なぜならば、人々のシャツの色は通常変わらず、ユーザがシャツを変えても、ユーザ連続性を失うことによって大きな被害はないからである。しかしながら、より容易に変化する他の特徴はどうであるか？一例は、音声、視覚または他のセンサデータから得られる部屋の中のユーザの位置である。基準ユーザの位置が最初にわかっていて、要求が新たな位置のユーザから来た場合、エージェントはユーザ連続性について自信を持って判断できるか？答えは「ノー」である：基準ユーザが新たな位置に移動したか、別のユーザがそこにいた可能性がある。基準ユーザを追跡することは、通常、この問題を克服する。

トラッキング
ユーザを追跡すること−および少なくとも基準ユーザを追跡すること−は、ユーザ連続性を確立するために不可欠な部分であり得る。トラッキングは、時間を通じて連続性をシミュレートするのに十分短い１つ以上のデューティサイクル中に実施される進行中の活動である。全対象の追跡は、より単純な特徴の追跡に依存する。エージェントは感覚入力を使用し、ＤＳＰ技法を適用して、下位の特徴を抽出する。ますます上位の特徴が計算されることもある。トラッキングは、知覚的に関連する特徴の、経時的な連続観察を行うことに基づく。１つ以上の瞬間的な特徴の観測の収集は、「スナップショット」特徴付けと呼ぶことができる。エージェントは特徴の集合を計算およびアセンブルすることによって、スナップショットの特徴付けを構築できる。この目的のために、任意の数のセンサを使用することができる。マルチモーダル特徴階層では、下位の特徴および上位の特徴をトラッキングに必要とすることができる。たとえば、（空間内の所与の視点からの）距離推定値と方位推定値（同じ視点から観察された同じ対象の方向）とを組み合わせることにより、より上位の特徴である位置推定値が得られる。距離推定値、方位推定値および位置特徴推定値を別々に追跡することが可能である。いくつかの実施形態では、シーン解析特徴は、エージェントによって直接観測されてもよく、または距離特徴および方位特徴から位置特徴を推論するような、より下位の特徴および観測から推測されてもよい。トラッキングに使用されるデューティサイクルは、モダリティによって変化し得（たとえば、マイクロフォンアレイから得られる方位計測の場合の２００ｍｓ対ビデオカメラに基づく方位計測の場合の１秒）；トラッキング間隔（デューティサイクル）は規則的であってもなくてもよい。

たとえば、エージェントは、カメラを使用して方位または距離などの知覚的特徴を周期的に測定してもよく；動いているロボットで起こるかもしれないように、カメラが動いている場合、カメラの動きを補償してもよい。３Ｄカメラまたはソナーを使用して距離を測定することができる。距離と方位が一緒になって空間内の位置を決定する。対象トラッキングは、距離、方位、または位置に基づくことができる。トラッキングは、通常、基準ユーザを追うために使用される。ユーザに関する瞬間的な観測の収集は、ユーザのスナップショットの特徴付けの一部である。この特徴付けは、音声特徴付けまたは声紋を含むこともできる。あるトラッキングモジュール（またはシーン解析サブシステムの別の部分）は、対象またはユーザがもはや可視ではないかどうかを報告することもできる。

十分な感覚データおよび計算資源が利用可能である場合、トラッキングは非常に強力であり、なぜならば、それによって、エージェントは経時的に基準ユーザの同一性を追うことができるからである（「同一性」という語の使用は、ユーザがユーザのデータベース内で識別されることを暗示するのではなく、新規ユーザが基準ユーザと同じであるとエージェントが信じるように、未確認の可能性のあるユーザが自信を持って追跡されたことを暗示するに過ぎない。

いくつかのデバイスは、トラッキングを実行するのに十分なローカルの計算資源を有する。他のデバイスは、リモートサーバに依存して必要な計算の一部を実行する。トラッキングのネットワーク帯域幅要件およびレイテンシ要件は、ローカル処理の使用を有利にするが、多くの実装アーキテクチャが可能である。

トラッキングのいくつかの実施形態では、特徴の連続値は、ユーザ連続性の証拠または反証を与える。すべての特徴の値の連続性の測定値は、ユーザ連続性の判断に積極的に寄与する。いくつかの実施形態では、寄与は二値である。１つの特徴値と次の特徴値との間の特徴空間距離の測定値が「低」（閾値より下）である場合、連続性を支持する二値の証拠が存在する。他の実施形態では、特徴の連続値は、その特徴に基づいてユーザ連続性の支持度を表す確率スコアまたは尤度スコアを決定する。尤度情報は、連続性を形成するためにいくつかの特徴から組み合わせることができる。一日の終わりに、ユーザ連続性に関して、入手可能なすべての特徴に基づいて、二値判定を行う必要がある。それは、二値サポート、１つ以上の尤度スコアのしきい値との比較、および重み付けスキームを考慮する。

トラッキング（およびすべての知覚イベント検出）のための重要な考慮事項は、エラーの可能性である。すべての信号処理技術には限界があり、偽陽性と偽陰性との両方が時間の一部で発生する可能性がある。エラーの結果に応じて、偽陽性または偽陰性を最小限に抑えるために、しきい値および重みが選択される。複数の特徴が利用可能な場合、特徴の部分集合を組み合わせて使用して連続性の判断を行うことができる。たとえば、マイクロフォンアレイが音声データからユーザの方位の推定をサポートする場合、方位における連続値間の大きな変化は連続性に反する。一方、カメラが利用可能であり、ユーザが基準ユーザの視覚方位からほぼ新規ユーザの視覚方位まで連続的に移動するのが見られる場合、音声特徴と画像特徴との組み合わせは、ユーザ連続性の判断をサポートする。

いくつかの実施形態では、判断をなすことに向けて特徴を統合することは、ハンドコードされた規則に基づいて行われる。他の実施形態では、ベイズセンサ融合フレームワークが使用される。特徴計算は、原則に基づいた特徴の統合をサポートする、分散、尤度、または確率の関連する測定値を生成する。

距離メトリックは、ベイジアンアプローチの単純化された代替物として時に使用されることがある。すべての特徴寸法は、観測点間の距離に寄与する。特徴の連続的なトラッキングに関し、重要なのは、開始特徴値と終了特徴値との間の特徴距離ではなく、連続する各観測時間で測定されるステップバイステップ距離であり；開始から終了までのエンドツーエンドの距離にかかわらず、ステップバイステップ距離が小さい場合に、トラッキングは成功する。

確保された係属
ロックする係属の変形実施形態では、ロック条件が組み込まれており、すなわち、各明示的ロック要求によって判断されるのではなく、永久的に指定される。ロック要求がない場合、第１の任意の要求はロック状態に遷移することができる。この状況は条件付きロックとは異なり、別のポリシーとして記述される。確保状態ポリシーは、暗黙的な「私の言うことを聞いて」条件付きロックの、特別目的の最適化された実現である。ロック要求およびロック解除要求も不要なので、それは、それ自体の処理に値する。

確保ポリシーは、明示的な発声要求「次のＴ秒間私の言うことを聞いて」によって表現することができるが、違いは、（１）要求は暗黙的であり省略することができ、それはユーザーの努力なしに自動的に有効になる；（２）ユーザが要求を出すたびに、新たなＴ秒タイマが起動される。タイムアウトが発生すると、エージェントは休眠状態になり、覚醒ワードが必要になる。補助的に、「私を１０に対して確保する」のように、システムパラメータとして時間Ｔを変更するオプションが必要である。

図１２は、一実施形態による確保された係属ついてのＦＳＡを示す。エージェントは休眠状態１２００で開始し；覚醒インジケータ１２０４は、エージェントを初期状態１２１０に遷移させるが、この状態は、係属かつ非反復状態である。初期状態１２１０で受信された要求は、初期要求と呼ばれる。それは任意の有効な要求であることができる。初期要求を発話したユーザは、基準ユーザとして知られる。ＥＯＵ１２１４は、要求処理１２１８をトリガする。基準ユーザ１２１６を設定することは、基準ユーザのパラメトリックモデルを作成する追加の処理を伴う。これは、基準ユーザのパラメトリックモデルが確保状態１２２０において必要とされるときに利用可能であるように行われる。確保状態１２２０において、ＥＯＵ１２２４は、エージェントにユーザ連続性１２２６をテストさせる。このテストは、先に論じたように、基準ユーザのパラメトリックモデルと新規ユーザのパラメトリックモデルとの比較に基づく。条件付き要求処理１２２８では、ユーザ連続性テストが成功すると要求が処理される。テストが失敗した場合、要求は無視される。確保状態１２２０では、エージェントがロック解除コマンドまたはタイムアウトを検出するまで、条件付き要求処理１２２８が繰り返し実行される（１２２２）。

図１３は、一実施形態による、確保状態のためのロジック１３００を示す。確保状態に入ると、感覚入力処理１３０２がトリガされ、それは、音声入力処理１３０３、内部イベント処理１３０４、およびオプションのシーン解析１３０５を含む複数のタスクを同時に実行することができる。音声入力処理１３０３は、新たな発話の開始および終了を検出し、ＥＯＵを信号送信し、それは、次いで、ユーザ連続性１３０６のテストをトリガする。テストが成功すると、要求は処理される（１３０８）。ロック解除要求が認識されると（１３１０）、エージェントは休眠状態に遷移する。他の要求（たとえば、１３１０でロック解除要求が認識されない）の場合、エージェントは確保状態に戻り、感覚入力処理１３０２を再開する。

内部イベント処理１３０４は、タイムアウトを検出することができ、それも、休眠状態への遷移引き起こす。感覚入力処理１３０２のいくつかのサブタスクの並列実行は、多くの方法で達成することができる。いくつかの実施形態では、感覚入力処理１３０２は、音声に適したデューティサイクル、たとえば１０ｍｓ〜１００ｍｓを使用する。いくつかの実施形態では、内部イベント処理１３０４によるタイムアウトの検出は、たとえば１秒のデューティサイクルを使用する。代替的に、ハードウェアタイマの割込みによってタイムアウトを検出することもできる。

いくつかの実施形態では、感覚入力処理１３０２は、オプションのシーン解析１３０５を含み、それは、追加データが収集されるにつれ適合される基準ユーザのシーン解析記述（シーンモデル１３２６）を更新して、ユーザ連続性テストの精度を向上させる。いくつかの実施形態では、音声入力処理１３０３は、基準ユーザの声紋をモデル化するためにより多くのデータを提供する。したがって、より多くの音声サンプルが利用可能である場合、基準ユーザの声のモデルを適合させることができ、声紋一致の信頼性を向上させる。図示される実施形態では、音声入力処理１３０３からのデータは、オプションのシーン解析１３０５に引き渡され、それはシーンモデル１３２６に通知しそれを更新する。（点線の矢印は状態遷移ではなくデータフロー接続である）。

このようなシーン解析記述の例には、たとえば、基準ユーザの位置（１つ以上の観測点からの方位および距離に基づくことができる）およびトラッキングに適した他のパラメータが含まれる。基準ユーザのトラッキングはユーザ連続性の判断に明らかに寄与するが、他のユーザのトラッキングも同様であり、なぜならば、ある時点で区別されると分かる２人のユーザ（「基準」対「その他」）は、トラッキングを通してこの区別を、テスト時に他の態様で確立できない場合に、保持するからである。本開示では、洗練されたシーン解析方法の利用可能性が想定されている。しかしながら、シーン解析の性質および詳細そのものは、本発明の概念に影響を与えない。

ユーザ連続性のテスト１３０６の一部として（または代替的に、音声入力処理１３０３の一部として）、エージェントは、新規ユーザ（新たな要求を発話したユーザ）のパラメトリックモデルを、新規ユーザの音声およびおそらくは他の感覚データに基づいて構築する。ユーザ連続性に関するセクションでは、ユーザ連続性のテスト１３０６を実行するために利用可能なさまざまな方法について議論する。エージェントは、２つのパラメトリックモデル（基準ユーザのものと新規ユーザのもの）を比較し、ユーザ連続性について判断することができる。しかしながら、トラッキングの可能性のため、ユーザ連続性をテストすることには、単に２つのモデルを比較することよりも重要なことがある。ユーザ連続性テストが失敗した場合、エージェントはコマンドを処理することなく感覚入力処理１３０２に戻る。

図１２に示されるエージェント確保ポリシーのいくつかの実施形態では、基準ユーザからの２つの要求の間に、指定された量のアイドル時間（たとえば、１０秒）が経過すると、タイムアウトが生じる。特に、基準ユーザから受信されたすべての要求はタイムアウトタイマをリセットするので、ユーザは、次の（たとえば）１０秒の間、エージェントの排他制御を保持する。基準ユーザが（たとえば）１０秒の間要求を出さない場合、エージェントは休眠状態１２００に戻る。それは、エージェントを初期状態１２１０に遷移させるために覚醒インジケータをとる。基準ユーザの同一性は、エージェントが休眠しているときは忘れられ、基準ユーザの変更は覚醒後に可能である。初期状態１２１０で初期要求が受信されると、新たな基準ユーザが選択される。

いくつかの実施形態では、タイムアウトは、基準ユーザ以外のユーザからの要求を含む要求と要求との間に、指定された量のアイドル時間が経過したときに発生する。これは、基準ユーザに対して、干渉後に、より多くの時間を与える。いくつかの実施形態では、ロック状態に最初に入ってから指定された総ロック時間が経過したときにタイムアウトが発生する。

いくつかの実施形態では、正常に処理できない初期要求は基準ユーザを変更せず、エージェントは初期状態１２１０に留まる。他の実施形態では、失敗した初期要求はそれでも基準ユーザを変更し、エージェントは確保状態１２２０に進む。

エージェントの注意を解放する
礼儀から、エージェントの注意を必要としなくなったユーザは、タイムアウトが発生するのを待って、他のユーザが制御を取れるようにする代わりに、他の誰かが使用できるようにエージェントを解放するべきである。「ありがとう」や「終わり」などの単純なロック解除要求がこれを行なう。これは、エージェントだけでなく他のユーザにも礼儀を示す。さらに有益な効果はミダス王の問題を避けることである。

エージェントの注意を奪う
いくつかの実施形態では、図９Ｃのロックポリシーは字義通りの方法で適用され、新規ユーザからの発話は、新規ユーザが基準ユーザと一致しない場合、完全に無視される。いくつかの実施形態では、ロックは、限られた期間だけアクティブのままである。タイムアウトの後、エージェントの係属状態は、完全に、休眠状態（図９Ｃのロック解除９２２または図９Ｄのロック解除１ ９６２を参照）、または部分的に、ワンタイム状態９５０（図９Ｄのロック解除２ ９６６）または注意深い状態１６６０（図１１Ｂのロック解除２）などの係属状態まで、下げられてもよい。これらの状況では、タイムアウトは特別な種類のロック解除インジケータとして扱われることを想起されたい。

他の実施形態では、基準ユーザに対するエージェントの注意を他のユーザの排除に制限することは、字義どおりではなく、特定の条件下で基準ユーザからエージェントの注意を奪うことができる。いくつかの実施形態では、高い権限を有するユーザに、より高いランクが付与され、エージェントの注意を奪い、より低いランクの基準ユーザによって実施されるロックを無効にする能力を与える。いくつかの実施形態では、ランク判定は、ユーザ同一性に基づく。いくつかの実施形態では、ランク判定は、空間的に決定された属性である。ユーザのランキングは、たとえば、ホットゾーンに近接しているかどうかに依存し得る。基準ユーザよりもホットゾーンに有意に近く見出されたユーザは、ロックを無効にし、エージェントの注意を奪い得る。別の例では、正しいホットスポットを注視するユーザは、エージェントの注意を奪い得る。いくつかの実施形態では、基準ユーザよりもはるかに大きな声で話すことで、エージェントの注意を奪い得る。

空間制御
一実施形態によれば、指定された空間領域に入ることは、ロックインジケータとして作用し、指定された空間領域を出ることは、ロック解除インジケータとして作用することができる。好ましい設計では、ある空間領域に入ると状態がロックされ、同じその空間領域を出るとその状態がロック解除されるべきである。この相互作用設計は、ロックされたエリアの存在を視覚化することが容易であるため、ユーザの認知負荷を最小にする。このような実施形態では、ソナー、レーザー、または３Ｄセンサのようなさまざまなセンサが、カメラの代わりに、またはカメラに加えて、空間領域を画定することができる。また、ユーザが携帯する能動的または受動的なデバイスの電磁感知もあり得る。

椅子に座る、または部屋の特定のホットスポットを注視するなど、他の形態の空間的ロック制御（または他の遷移）が存在する。家屋または自動車には多くの異なるホットスポットが存在し得る。係属は、ユーザの視線の方向によって制御することができ、より有用には、ホットスポットを注視することと、それと同時に話し始めることとの組み合わせによって、制御することができる。これは、たとえば、ロボットまたはホットスポットを有する任意のデバイスと対話するときに覚醒インジケータとして作用することができる。複数のホットスポットがある場合、ユーザの特定のホットスポットの注視による選択は、ドメイン、エージェント状態、またはエージェントプロパティの選択を制御することができる。

ユーザは、ロボットの目をホットスポットとして使用して、アイコンタクトをとることができる。アイコンタクトだけでは、ユーザがエージェントを扱いたいという証拠がおそらく不十分である。しかしながら、ユーザがエージェントに向かうか、またはホットスポット（注視方向）を見て話し始める場合には、これはユーザがエージェントと関わる自然な方法である。これは、人と接する一般的な方法を模倣し；アイコンタクトを確立しながら、人に話し始める。一実施形態によれば、エージェントは、アイコンタクトを確立する規定された時間ウィンドウ内でユーザが話し始めることに基づいて、覚醒インジケータを使用することができる。たとえば、５秒未満の間ロボットとの連続したアイコンタクトを検出した後の音声の発生は、覚醒インジケータとして働くことができる。発話された音声は、覚醒インジケータを必要としないであろう。逆に、アイコンタクトを検出することがエージェントを係属させる際に役立つ場合、視線が動いたことを検出することは、係属を解除することができる。

ミダス王問題に関する「安全性」については、ロック要求は偽陽性をまれにするはずである。良いユーザ体験のためには、それらは、自然で、習得が簡単で、見苦しくないべきである。ロック解除インジケータの場合、偽陽性はそれほど問題にならない。ロックから離脱することは、ユーザが、状態透明性の問題である、別の要求の前にエージェントを再覚醒または再ロックする必要性を認識している限り、わずかなリスクしか負わない。たとえば、（ホットスポットから離れた）「冷たい」空間領域を一瞥するだけで、ロック解除インジケータとなり得る。

状態透明性
覚醒インジケータをスキップする可能性から利益を得るために、ユーザは、覚醒インジケータが必要であるか否か、すなわち、エージェントが休眠中であるか否かを知る必要がある。場合によっては、ユーザはエージェントの状態が表示されていなくてもそれを知っている。これは、たとえば、タイムアウトがない状態において明示的なロック／ロック解除要求で起こる。状態透明性の必要性は、ユーザがエージェントの状態について確信が持てない場合に発生する。これは、たとえば、タイムアウトが発生して、ユーザアクションなしに状態変化を起こしたとき、またはユーザが不注意に境界を超えてホットゾーンに出入りしたときに、発生し得る。ユーザがエージェント状態の変化を認識できないときはいつでも、（ここに開示された方法を最大限に活用して）エージェントをユーザに露出するか、または代替的に、ユーザに状態遷移を注意喚起することが重要である。

いくつかの実施形態は、任意の適切なユーザインターフェイス手段を使用して、エージェントの現在の状態をユーザに明らかにする対話設計の実際に従う。ユーザはエージェントの状態を見ることができると、それに従って振舞うことができる。ユーザは、エージェントが休眠状態にあると見なされた場合にのみ、覚醒フレーズを使用する。このようなフィードバックをユーザに提供することなしには、エージェントは覚醒フレーズを避ける自然さを提供しない。

現在の仮想アシスタントでは、エージェントが「聴いている」、つまり係属されているかどうかを伝えるために、グラフィックアニメーションがしばしば使用される。一般に、エージェントは、エージェントが入っている状態を示す何らかの種類のフィードバックをユーザに与えるべきである。たとえば、図６ＣからのＮａｏロボットは、ソフトウェアがそれの目の色を変えることを可能にする。エージェントは、Ｎａｏに、休眠中は鈍い灰色の目、ロック時はオレンジ色の目、係属中であるがロック解除時は緑色の目を表示させる。

フィードバックインジケータは単純かつ安全でなければならない。有色光またはアイコンを表示することは良い選択であることが多いが、車内では安全ではなく、なぜならば、運転手は視覚的に注意を散らされてはならないからである。明確に識別可能な音を使用することは、車のための効果的な代替手段となり得る。たとえば、休眠状態またはロック状態に入ることは、入る状態と一意的に関連付けられる短い音によって伝達することができる。いくつかの実施形態では、視覚および聴覚の両方のきっかけが現在の状態を伝達するために使用され、ユーザは、それらのどちらでも使用して次に何をすべきかを知ることができる。

注意深いエージェント係属
注意深いエージェントポリシーは、覚醒ワード疲労を最小限に抑え、明示的なユーザ介入なしにマン・マシン・ダイアログの効率および自然性を高めることを目指す。エージェントは、これを、人間の対話挙動を模倣し、係属のきっかけを知覚し、それに応じてそれ自体の係属を制御する、それの能力に基づいて、行なう。人々は、しばしば、身体言語、アイコンタクト、およびその他の手がかりを使用して係属状態に留まる意思を伝える。注意深いエージェントは、そのような手がかりに、ユーザの知覚的観察、およびその手がかりを、係属させる、係属状態に留まる、または係属解除することに対する希望として解釈する方法のモデルに基づいて、気付く。ロックされたエージェントまたは確保されたエージェントとは対照的に、注意深いエージェントは、動的な係属および係属解除の決定を自律的に行なう。

初期覚醒インジケータの後、注意深いエージェントは、デフォルトで、すなわち、ユーザが係属解除したいことを示唆する条件を検出しない限り、係属したままである。このデフォルトの選択は、ユーザを覚醒ワード疲労から守ることを目的としている。その目的を達成するために、注意深いエージェントは、使用可能なすべての感覚能力および知覚能力を含むその能力のうちのいずれかを使用して、ユーザが係属状態に留まりたいか係属解除したいかを予測する。エージェントは、それに応じて係属状態に留まるかまたは係属解除することによって、ユーザの推定された意図と合わせる。

注意深いエージェントポリシーは、ロックされたエージェントポリシーとは異なり、ロック要求およびロック解除要求に依存しない。注意深いエージェントポリシーは、確保されたエージェントポリシーとは異なり、エージェントはその知覚に基づいていつでも自動的に係属解除できる。注意深いエージェントポリシーおよびロックされたエージェントポリシーの両方の局面を組み込んだハイブリッドポリシーについては後で説明する。

もう少しよく見ると、確率および閾値は常にエージェントの意思決定に関与する。注意深いエージェントは、（その知覚的観察に基づいて）ユーザが係属状態に留まって、別の要求を進行中のダイアログの一部として出すことを望む尤度が高い場合に、係属状態に留まるよう判断する。エージェントが反対の証拠に気づいた場合、すなわち、なんらかの要因が、ユーザが係属状態に留まりたい尤度をしきい値より下に低下させた場合、エージェントは係属解除して休眠状態に戻り、再係属に覚醒インジケータを必要とする。エージェントは、ユーザが話すときであろうと、または要求が出される前に係属解除手がかりを検出すべくエージェントがユーザの挙動を追跡している間であろうと、いつでも係属解除することを選択できる。

ユーザが係属状態に留まることを望む尤度に影響を及ぼす要素は、重要性および確定性において変動する。いくつかの要素は二値であり、他の要素は微妙で状況によって弱められ得る。これらの要素には、とりわけ、ロボットまたはホットスポットとのアイコンタクトを切断すること；頭や体を遠ざけること；最後の要求からあまりにも多くの時間を許容すること（これはアイドル時間タイムアウト、およびオプションで、時間の経過とともに減少する尤度を使用することができる）；名前で部屋の他の人に話しかけること；突然話題を変えること；またはエージェントが理解できないことを言うこと、が含まれる。（要求が誤ってはっきりと述べられた場合、ユーザはそれを言い換えて係属状態に留まる機会を必要とするが、これは即座に行う必要がある。非常に短いアイドル時間タイムアウトを設定することができ、その間、エージェントは別の試行を可能にするよう係属状態に留まる）。

図１４は、注意深いエージェント係属ポリシーの一実施形態を示す。ユーザが、任意の覚醒インジケータ１４０４を使用して、休眠状態１４００からエージェントを覚醒させた後、エージェントは注意深い状態１４１０に遷移する。いくつかの実施形態では、エージェントは知覚能力を有し、ユーザの挙動を観察して、休眠状態に遷移するか、または注意深い状態に留まるかを判断できる。エージェントによるこの選択１４１１は、ユーザ要求が受信される前に、または要求の受信で、行われることが可能である。

注意深い状態１４１０にある間、エージェントは選択を行って（１４１１）それの係属を解放し（１４１４）、休眠状態１４００に遷移することができる。エージェントが注意深い状態１４１０にある間にユーザが要求を発話した場合、ＥＯＵ１４１６を受信することも、継続される係属と休眠状態１４００への解放との間の最終的な選択のために、（エージェント）選択１４１１をトリガする。そのような解放がない場合、要求処理１４１８が発生し、エージェントは注意深い状態１４１０に留まる。

いくつかの実施形態では、エージェントは、基準ユーザのトラッキングをサポートするのに十分なセンサを有し、継続的にユーザ連続性をテストする。いくつかのそのような実施形態では、エージェントがユーザを継続的に追跡できない場合、エージェントは１４１１を選択して、その係属を直ちに解放する（１４１４）。代替的に、エージェントが解放（１４１４）を選択することなく、比較的短い非トラッキング（または信頼性の低いトラッキング）期間を許容することができる。連続性テストのさらに別の実施形態では、継続的なトラッキングの失敗はトラッキングスコアにのみ影響を及ぼすが、解放するか否かのエージェントの選択１４１１は、新たな要求が受信されたときにのみ行われる。

注意深い状態１４１０で要求が受信され、トラッキングスコアが低い（エージェントが継続的かつ確実に基準ユーザを追跡することができなかった）か、または存在しない（エージェントはユーザを追跡するのに十分な手段を持たなかった）場合、エージェントは、新規ユーザの音声を基準ユーザの音声と照合して、選択１４１１を行なって、それの係属を解放して（１４１４）、その要求を無視するよう試みてもよい。

注意深いエージェントでは、セマンティクスも係属の判断に影響を及ぼし、他の要素を無効にすることができる。そのようなケースの１つは、フォローアップ要求の使用である。たとえば、ユーザが「ニューヨークの天気はどう？」と尋ね、返答を得た後、「シカゴはどう？」と尋ねた場合、たとえ他の要素が係属解除を示唆するとしても、第２の要求（「シカゴの天気はどう？」と理解される）は第１の要求とともにグループ化され、覚醒ワードを必要としないはずである。これには、第２の要求の「peek previous」が必要である。

いくつかの実施形態は、ユーザ連続性判断を支援するために、より広い意味で要求セマンティクスを使用する。情報要求は、副作用を伴う、アクションに対する要求よりも危険性が低い。誰かが「２＋２はいくつ」や「日本の首都はどこ」と尋ねた場合、エージェントが覚醒インジケータを要求したり、またはユーザが基準ユーザであることを確認する理由はない。しかしながら、「お母さんを読んで」のようなアクション要求は、要求しているユーザが基準ユーザと同じであることを確認する必要がある。エージェントは情報要求をアクション要求から区別し、情報要求が安全であると仮定することができ、新規ユーザの声が基準ユーザの声と一致しなくても覚醒インジケータを必要としない。安全性は一般に、望ましくない副作用を回避することに対処しなければならない。アクション要求は、通常、その理由で、安全でないとみなされる。しかしながら、あるアクション要求は安全であり得（「ファンを止めて」）、ある情報要求は、それが意図しない相手に個人情報を明らかにする場合（「私の社会保障番号は何ですか？」）、危険であり得る。変形の実施形態では、安全／危険の区別は、要求を処理した結果としてなされる。自然言語処理（通常はセマンティックパーサーを使用して行われる）は、安全性インジケータを返すことができ、それは、真の場合には、覚醒インジケータを必要とせずに応答を計算してユーザに与えることができる。これも、第２の要求の「peek previous」を必要とする。

図１５は、一実施形態による、注意深い状態のロジック１５００を示す。感覚入力処理１５０２は、同様の感覚入力処理ステップ（休眠状態の場合は１００２、ロック状態の場合は１１０４、確保状態の場合は１３０２）について前述したように、シミュレートされた並列処理で１つ以上のタスクを実行する。入力処理タスクは、音声入力処理１５１０およびオプションでシーン解析１５２０を含む。音声入力処理１５１０は、新たな各発話の開始および終了を検出し、ＥＯＵをトリガする。第１のタイプの解放判断「ＥＯＵで解放」１５１２は、図１４のエージェント選択１４１１と関連して議論された。実際には、図１４の「エージェント選択１４１１」ステップは、図１５で、３つの異なる状況に対応する３つの別個の判断ステップ：「ＥＯＵで解放」１５１２、「要求後に解放」１５１６および「トラッキング中に解放」１５２８に分割される。これらの解放可能性のすべては、図１４との関連においてエージェント選択１４１１の例として導入された。すべての解放判断は、エージェントを休止状態１４００にする。

いくつかの実施形態では、セマンティック考慮事項（上で議論した）は、係属解除を引起こすであろう他の考慮事項の無効ステップ１５１１をサポートし、要求処理１５１４がＥＯＵ１５１２での完全な解放なしに進むことを可能にする。これは、新規ユーザを基準ユーザと混同する望ましくない副作用の安全性検査を伴い得る。無効がない場合（ステップ１５１１のＹ分岐）、ＥＯＵ１５１２で解放がない場合にのみ、要求処理１５１４が処理される。明示的な解放要求は、要求後に解放を引き起こし得る（１５１６）。そのような開放がない場合、エージェントは注意深いままであり、制御は注意深い状態ループの先頭に戻る。

シーン解析１５２０は、「ＥＯＵで解放」ステップ１５１２および「トラッキング中に解放」ステップ１５２８によって使用することができるシーンモデル１５２６を生成する。シーン解析は非常に複雑であり得る。本開示は、シーン解析をそのすべての複雑さにおいて記載しようとするものではない。しかしながら、２つの局面が注目に値する。第１に、特定の知覚的特徴（基準ユーザの身体位置、視線方向、身体方向、顔の向きなど）およびジェスチャを含む知覚的イベント（身体を回して逸らす、アイコンタクトを断つ）は、係属および係属解除の判断に影響を及ぼす。第２に、基準ユーザを追跡することも、係属および係属解除の判断の重要な要素であり、ライブシーン解析の一部である。いくつかの解放判断は、「トラッキング中に解放」ステップ１５２８でのトラッキングに基づいて行われ、エージェントを休眠状態に進めるかまたは注意深い状態に留まらせる。「トラッキング中に解放」ステップ１５２８は、シーン解析１５２０によって作成および更新されるシーンモデル１５２６を使用する。

ハイブリッド係属制御
ハイブリッド係属ポリシーは、先にかなり単純な態様で開示された技術を組み合わせることによって得てもよい。

図１６Ａは、ユーザ指向型方法（ロックされたエージェントポリシー）およびエージェント指向型方法（注意深いエージェントポリシー）の両方が同時に使用される係属制御のハイブリッドシステムを示す。図１６ＡのＦＳＡは、２つの単純なステップで簡単な態様で作成される：（ａ）図９ＣのロックされたＦＳＡの正確なコピーを、すべての項目参照番号が変更された状態で作成し；（ｂ）（図９Ｃからの）ワンタイム状態９１０のコピーを、図１４からの注意深い状態１４１０の、番号を付け替えられたコピーと置き換える。これは注意深い状態である。後者のステップは、注意状態１４１０からそれ自体へのセルフループをコピーすることを含む。

図１６ＡでＦＳＡの作成を見る別の方法は、図１４の注意深いエージェントＦＳＡのコピーから開始し、図９Ｃからのロック状態９２０のコピーをすべてのそれの遷移とともに追加することである。いずれにしても、これらの操作は、図９Ｃおよび図１４に基づいて「マージされた」（または「グラフトされた」）ＦＳＡを作成する。

マージされたＦＳＡ（図１６Ａ）の機能は、寄与するＦＳＡの機能に由来する。各状態は、（番号付け替えが一貫して使用されている限り）コピーによって影響を受けない、それ自体の独立したロジックを有しているため、
休眠状態１６００のロジックは休眠状態ロジックであり（図１０参照）、
注意深い状態１６１０のロジックは注意深い状態ロジックであり（図１４参照）、
ロック状態１６２０のロジックはロック状態ロジックである（図１１参照）、ということになる。

このマージされたロジックを使用することに基づいて、図１６ＡのハイブリッドＦＳＡの挙動は、前述の挙動の単純な組み合わせであることになる。たとえば、図１６Ａは、エージェント選択１６１２（図１４のエージェント選択１４１１と同様である）、解放１６１４（図１４の解放１４１６と同様である）、ＥＯＵ１６１６（図１４のＥＯＵ１４１６と同様である）、要求処理１６１８（図１４の要求処理１４１８と同様である）、要求処理１６２８（図９Ｄの要求処理９６８と同様である）、およびロック条件１６３０（図９Ｄのロック条件９６９と同様である）を示す。より短い記述で十分である。休眠状態１６００で開始し、覚醒インジケータ１６０４に応答して、エージェントは注意深い状態１６１０に入る。注意深い状態１６１０を伴う挙動は、先に説明した。ある時点で、ユーザがロック要求を行うと、エージェントはロック状態１６２０に入る。ロック状態１６２０を含む挙動は、先に説明した。注意深い状態１６１０およびロック状態１６２０は、両方とも反復性であり、すなわち覚醒なしで繰り返し要求を処理することができる。そうではあるが、注意深い状態において係属から脱却する方が容易である。さらに、ロックの後、図１６ＡのハイブリッドＦＳＡは、再係属する前に休眠状態への復帰を必要とする。この最後の局面は、図１６ＢのハイブリッドＦＳＡ‐‐追加の遷移を有する図１６Ａの変形例と異なる。

図１６Ｂは、等価である３つの態様で行うことができる：（１）図９Ｃの代わりに図９Ｄを用いてＦＳＡを図１４とマージする；（２）図１４のＦＳＡのコピーから開始し、図９Ｄからのロック状態９６０のコピーをすべてのそれの遷移とともに追加する；または単に既にマージされた図１６Ａを取り、ロック２遷移およびロック解除２遷移‐図９Ｄのロック２（遷移）９４８およびロック解除２（遷移）９６６の番号無バージョン‐を追加する。

２つのことが変更されている：（１）休眠状態１６５０からロック状態１６７０に直接進むことが可能である。ロック２は要求ではあり得ないが、それは覚醒ワードまたは他の「ロック覚醒」インジケータであり得る。ワンステップロックの使用は、いくつかの状況では便利であり得る；（２）状態をロック解除して係属されたままにすることが可能である。ロック解除２インジケータは要求を含む何でも構わない。

ハンドオーバ
１つのさらなる変形例は、確保状態またはロック状態から発声された要求は、ユーザ連続性のロック状態を可能にすることができるが、すべて休眠状態を経ることなく、新たな基準ユーザを受け入れることである。第１の変形例では、単純な「ハンドオーバ」要求は、話しているが、次のＴ１秒以内のみである第１のユーザを、基準ユーザとして受け入れる。確保されたエージェントＦＳＡでは、タイムアウトを除いて、これは、あたかも覚醒後に確保状態１２２０から初期状態１２１０への遷移が行われたかのようである。受信された第１の要求は処理され（１２１８）、新たな基準ユーザが特徴付けられて設定され（１２１６）、エージェントは更新された基準ユーザのために確保される。

第２の変形例である「＜有効化条件＞へのハンドオーバ」では、新たな基準ユーザは、Ｔ１タイムアウトの前に、有効化条件を満たし、最初に話す者である。可能な有効化条件は以下を含む：（１）特定の１人の人物（「ジョンにハンドオーバ」）または複数の特定の人物（「ゲストにハンドオーバ」、「子供達にハンドオーバ」）であること；（２）特定の場所または所与のホット領域にいること（「後部座席にハンドオーバ」）。ホットスポットは、デフォルトで既知であるか、またはハンドオーバ要求で指定されている必要がある。他の有効化条件には、性別、視覚的プロパティなど（「挙手にハンドオーバ」、「テーブル全体に亘って赤いシャツを着た男にハンドオーバ」）、またはエージェントが解釈して使用できるどのような記述も含まれ得る。

引き渡されると、上位ランキングの者がエージェントの注意を取り戻すことができる。「エージェントの注意を奪う」セクションを参照のこと。これは、たとえば、家族内における、例えば、テレビのリモコンへの言葉によるアクセスを制御する、または再生する曲を選択するなど、日常的なことに対して、当てはまる。エージェントを確保する能力のために、数多くの職場のアプリケーションが見つかる。それは、仮想マイクロフォンを握るようなものである。

コンピュータ実施形態
図１７Ａは、コンピュータプロセッサによって実行されると、コンピュータプロセッサに本明細書に記載の方法または部分的な方法ステップを実行させるコンピュータコードを格納する、非一時的なコンピュータ読み取り可能な回転ディスク媒体１７０１を示す。

図１７Ｂは、コンピュータプロセッサによって実行されると、コンピュータプロセッサに本明細書に記載の方法または部分的な方法ステップを実行させるコンピュータコードを格納する、非一時的なコンピュータ読み取り可能なフラッシュランダムアクセスメモリ（ＲＡＭ）チップ媒体１７０２を示す。

図１７Ｃは、いくつかの実施形態の構成要素を含み、コンピュータコードを実行することによって、本明細書に記載の方法または部分的な方法ステップを実行する、複数のコンピュータプロセッサコアを含むパッケージ化されたシステムオンチップ（ＳｏＣ）１７０３の底面（はんだボール）側を示す。

図１８は、さまざまな実施形態のサーバコンポーネントとして使用されるラックベースのサーバシステム１８０１を示す。

図１９は、システムオンチップ１７０３内のコアのブロック図１９００を示す。それは、マルチコアコンピュータプロセッサ（ＣＰＵ）１９０１およびマルチコアグラフィックスアクセラレータプロセッサ（ＧＰＵ）１９０２を備える。ＣＰＵ１９０１およびＧＰＵ１９０２は、ネットワーク・オン・チップ１９０３を介してＤＲＡＭインターフェイス１９０４およびフラッシュＲＡＭインターフェイス１９０５に接続されている。ディスプレイインターフェイス１９０６はディスプレイを制御する。Ｉ／Ｏインターフェイス１９０７は、ＳｏＣ１７０３によって制御されるデバイスのヒューマンマシンインターフェイスに対するセンサおよびエフェクタアクセスを提供する。ネットワークインターフェイス１９０８は、デバイスがインターネットを介してサーバと通信するためのアクセスを提供する。

図２０は、サーバシステム１８０１の一実施形態を示す。具体的には、図２０は、ボードレベル相互接続２００３を介して、コンピュータコードを記憶するＤＲＡＭサブシステム２００４と、他のサーバまたはデバイスへのインターネットアクセスを提供するネットワークインターフェイス２００５とに接続する、マルチプロセッサＣＰＵアレイ２００１およびＧＰＵアレイ２００２を含むシステム２０００を示す。

７００ 係属状態、７３０ モーダル、７５０ 要求処理、８００ 休眠状態、８１０ ワンタイム状態、９８０ ロック状態。

Claims (16)

1. マン・マシン・ダイアログ中にエージェントの係属状態を制御する方法であって、
   基準ユーザからの第１の発声された要求を受信したことに応答して、
   前記第１の発声された要求を解釈してロック条件を判定することと、
   覚醒インジケータを必要としないロック状態に入って要求を処理することとを備え、前記方法はさらに
   新規ユーザから第２の発声された要求を受信することと、
   前記ロック条件が満たされているかどうかを判定することと、
   前記ロック条件が満たされないことに応答して、前記第２の発声された要求を無視することと、
   前記第２の発声された要求が安全であるか危険であるかを区別することと、
   前記第２の発声された要求が安全であると区別された場合には、前記新規ユーザが前記基準ユーザと一致していなくても、前記第２の発声された要求を処理することと、を備える、マン・マシン・ダイアログ中にエージェントの係属状態を制御する方法。
2. 前記第２の発声された要求が安全であるか危険である否かを区別することは、前記第２の発声された要求が処理された結果に基づく、請求項１に記載の方法。
3. 前記第２の発声された要求が安全であるか危険である否かを区別することは、前記第２の発声された要求が処理された結果が個人情報を明らかにする場合に前記第２の発声された要求を危険であると区別することを含む、請求項２に記載の方法。
4. 音声分類部を前記第２の発声された要求に適用して音声クラス前提を生成することをさらに備え、
   前記ロック条件は音声クラスを指定し、
   前記音声クラス前提が、前記ロック条件によって指定される前記音声クラスと一致しない場合、前記ロック条件は満たされない、請求項１〜請求項３のいずれか１項に記載の方法。
5. 前記基準ユーザの第１の特徴付けを構築することと、
   前記新規ユーザの第２の特徴付けを構築することと、
   前記第１の特徴付けを前記第２の特徴付けと比較して、前記第１の特徴付けと前記第２の特徴付けとの間に一致または不一致があるかどうかを識別することと、
   前記第１の特徴付けと前記第２の特徴付けとの間の一致を発見しなかったことに応答して、前記ロック条件は満たされていないと判定することとをさらに備える、請求項１〜請求項３のいずれか１項に記載の方法。
6. 前記第１の特徴付けおよび前記第２の特徴付けのうちの少なくとも１つは声紋を含む、請求項５に記載の方法。
7. 前記第１の特徴付けおよび前記第２の特徴付けのうちの少なくとも１つは、１つ以上の感覚信号から抽出された１つ以上のシーン解析特徴を含む、請求項５に記載の方法。
8. 前記シーン解析特徴は方位測定値を含む、請求項７に記載の方法。
9. 前記シーン解析特徴は距離測定値を含む、請求項７に記載の方法。
10. 前記シーン解析特徴は顔認識をサポートする、請求項７に記載の方法。
11. ロック解除要求を検出したことに応答して、前記ロック状態を出ることをさらに備える、請求項１〜請求項１０のいずれか１項に記載の方法。
12. 前記ロック解除要求は前記第２の発声された要求である、請求項１１に記載の方法。
13. 前記ロック解除要求はタイムアウトである、請求項１１に記載の方法。
14. マン・マシン・ダイアログ中にエージェントの係属状態を制御する方法であって、
    第１の人物から第１の要求を受信することと、
    前記第１の人物の第１の特徴付けを構築することと、
    第２の人物から第２の要求を受信することと、
    前記第２の人物の第２の特徴付けを構築することと、
    前記第２の特徴付けを前記第１の特徴付けと比較することと、
    前記第２の特徴付けを前記第１の特徴付けと比較したことが不一致を識別したことに応答して、前記第２の要求を無視することと、
    前記第２の要求が安全であるか危険であるかを区別することと、
    前記第２の要求が安全であると区別された場合には、前記第２の特徴付けが前記第１の特徴付けと一致していなくても、前記第２の要求を処理することと、を備える、マン・マシン・ダイアログ中にエージェントの係属状態を制御する方法。
15. コンピュータの１以上のプロセッサによって実行されることにより、前記コンピュータに請求項１〜請求項１４のいずれか１項に記載の方法を実施させる、プログラム。
16. 請求項１５に記載のプログラムを格納するメモリーと、
    前記メモリに格納された前記プログラムを実行する１以上のプロセッサと、を備えたコンピュータ装置。