(57)【要約】  分析プロセスが、ログデータに適用され、ダイアログターン（ユーザ−システム間の対話）情報などのダイアログ移動情報を使用して、アプリケーション内で最も蓋然性の高い問題を明らかにし、かつ／または診断する。
2009500721.tif 000002
【特許請求の範囲】
【請求項１】
ユーザとダイアログターンを有する対話型アプリケーションとの間のダイアログを分析するコンピュータ実施される方法（６０３）であって、ターンとは、システムからのプロンプトと前記ユーザから受け取られる応答とを含み、
前記システムと少なくとも１つのユーザとの間のアプリケーション内のダイアログターンを示す情報を受け取るステップ（６０５）であって、前記ターンは、前記アプリケーションの１つまたは複数のタスクに関係する、受け取るステップ（６０５）と、
前記１つまたは複数のタスクに対する前記アプリケーションの性能の表示を入手するステップ（６０７）と、
を含むことを特徴とするコンピュータ実施される方法（６０３）。
【請求項２】
前記１つまたは複数のタスクに対する前記アプリケーションの性能の前記表示を入手するステップ（６０７）は、応答を要求するターンに対する、受け取られた応答の確認に関するターンに関する表示を入手するステップ（６１１）を含むことを特徴とする請求項１に記載のコンピュータ実施される方法（６０３）。
【請求項３】
前記１つまたは複数のタスクに対する前記アプリケーションの性能の前記表示を入手するステップ（６０７）は、タスクインスタンスに対する、受け取られた応答の要求に関するターンに関する表示を入手するステップ（６１３）であって、前記タスクインスタンスには前記情報にまたがって前記応答の前記質問が現れる、入手するステップを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（６０３）。
【請求項４】
前記１つまたは複数のタスクに対する前記アプリケーションの性能の前記表示を入手するステップ（６０７）は、前記受け取られた応答に基づいて割り当てられる値に対する、受け取られた応答の確認に関するターンに関する表示を入手するステップ（６１５）を含むことを特徴とする請求項１に記載のコンピュータ実施される方法（６０３）。
【請求項５】
前記１つまたは複数のタスクに対する前記アプリケーションの性能の前記表示を入手するステップ（６０７）は、ユーザ要求に基づいてターンを繰り返すユーザに関する表示を入手するステップ（６１７）を含むことを特徴とする請求項１に記載のコンピュータ実施される方法（６０３）。
【請求項６】
前記１つまたは複数のタスクに対する前記アプリケーションの性能の前記表示を入手するステップ（６０７）は、
応答を要求するターンに対する、受け取られた応答の確認に関するターンに関する表示を入手するステップ（６１１）と、
タスクインスタンスに対する、受け取られた応答の要求に関するターンに関する表示を入手するステップ（６１３）であって、前記タスクインスタンスには前記情報にまたがって前記応答の前記質問が現れる、入手するステップ（６１３）と、
前記受け取られた応答に基づいて割り当てられる値に対する、受け取られた応答の確認に関するターンに関する表示を入手するステップ（６１５）と、
ユーザ要求に基づいてユーザがターンを繰り返すことに関する表示を入手すること（６１７）と
のうちの２つまたはそれ以上を含むことを特徴とする請求項１に記載のコンピュータ実施される方法（６０３）。
【請求項７】
ユーザとダイアログターンを有する対話型アプリケーションとの間のダイアログを分析するコンピュータ実施される方法（６１９）であって、ターンとは、前記システムからのプロンプトと前記ユーザから受け取られる応答とを含み、
システムと音声対応アプリケーションのユーザ少なくとも１人との間のアプリケーション内のダイアログターンを示す情報を受け取るステップ（６２１）であって、前記ターンは、前記アプリケーションの１つまたは複数のタスクに関係する、受け取るステップ（６２１）と、
前記アプリケーション内の混乱を引き起こすプロンプトの表示を入手するステップ（６２３）と
を含むことを特徴とするコンピュータ実施される方法（６１９）。
【請求項８】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、前記プロンプトに続いてユーザが沈黙した回数の表示を入手するステップを含むことを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項９】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、前記プロンプトに続いてユーザが支援を要求した回数の表示を入手するステップを含むことを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項１０】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、前記プロンプトを繰り返すようにユーザが前記システムに要求する回数の表示を入手するステップを含むことを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項１１】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、前記プロンプトに対する認識された応答が取り消された回数の表示を入手するステップを含むことを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項１２】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、応答待ち時間の表示を入手するステップを含むステップを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項１３】
前記アプリケーション内の混乱を引き起こすプロンプトの前記表示を入手するステップ（６２３）は、
前記プロンプトに続いてユーザが沈黙した回数の表示を入手するステップと、
前記プロンプトに続いてユーザが支援を要求した回数の表示を入手するステップと、
前記プロンプトを繰り返すようにユーザが前記システムに要求する回数の表示を入手するステップと、
前記プロンプトに対する認識された応答が取り消された回数の表示を入手するステップと、
応答待ち時間の表示を入手するステップと
のうちの２つまたはそれ以上を含むことを特徴とする請求項７に記載のコンピュータ実施される方法（６１９）。
【請求項１４】
ユーザとダイアログターンを有する対話型アプリケーションとの間のダイアログを分析するコンピュータ実施される方法（６３１）であって、ターンとは、システムからのプロンプトと前記ユーザから受け取られる応答とを含み、
前記システムと音声対応アプリケーションのユーザ少なくとも１人との間のアプリケーション内のダイアログターンを示す情報を受け取るステップ（６２９）であって、前記ターンは、前記アプリケーションの１つまたは複数のタスクに関係する、受け取るステップ（６２９）と、
ユーザにタスクを放棄させる、前記ダイアログ内の問題の源の表示を入手するステップ（６３５〜６４７）と
を含むことを特徴とするコンピュータ実施される方法（６３１）。
【請求項１５】
前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、ダイアログターンおよび／またはタスクエントリおよび／またはタスク完了を示す状態のシーケンシャルリスト内で放棄が起きる時点を突き止めるステップ（６３５）を含むことを特徴とする請求項１４に記載のコンピュータ実施される方法（６３１）。
【請求項１６】
タスク完了は対応する成功の表示を含み、前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、成功の表示を有するタスク完了（６３９）に遭遇するまで前記放棄の時点から前記シーケンシャルリストを遡って辿るステップ（６３７）を含み、前記問題の前記源の前記表示は、その直後のターンを含むことを特徴とする請求項１５に記載のコンピュータ実施される方法（６３１）。
【請求項１７】
認識された応答は、状態の前記シーケンシャルリストに相関付けられ、前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、前記ユーザが認識された応答を受け入れるまで、または、認識された応答が確認済みの状況を達成する任意のターンまで（６４１）、前記放棄の時点から前記シーケンシャルリストを遡って辿るステップ（６３７）を含み、前記問題の前記源の前記表示は、その直後のターンを含むことを特徴とする請求項１５に記載のコンピュータ実施される方法（６３１）。
【請求項１８】
認識された応答は、状態の前記シーケンシャルリストに記録され相関付けられ、前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、ターンが記録された認識応答を拒絶するか訂正するまで、または認識応答の位置が「Ｅｍｐｔｙ」の状況をもたらしたターンまで、または記録された認識応答がその値を変更したターンまで（６４３）、前記放棄の時点から前記シーケンシャルリストを遡って辿るステップ（６３７）を含み、前記問題の前記源の前記表示は、要求するターンに応じて対応する記録された認識応答が受け取られた、直前のターンを含むことを特徴とする請求項１５に記載のコンピュータ実施される方法（６３１）。  
【請求項１９】
認識された応答は、状態の前記シーケンシャルリストに記録され相関付けられ、前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、前記ユーザが前記ユーザのステップを引き返すコマンドを供給し（６４５）、その後、前記コマンドに続いてターンの表示を確かめるまで、前記放棄の時点から前記シーケンシャルリストを遡って辿るステップ（６３７）を含み、前記問題の前記源の前記表示は、前記ターンの前記表示に対応する最も近いターンであって、前記ユーザのステップを引き返す前記コマンドよりも前のターンを、前記問題の前記源として含むことを特徴とする請求項１５に記載のコンピュータ実施される方法（６３１）。
【請求項２０】
前記ユーザに前記タスクを放棄させる前記ダイアログ内の前記問題の前記源の前記表示を入手するステップは、セッションの初めに達する（６４７）まで前記放棄の時点から前記シーケンシャルリストを遡って辿るステップ（６３７）を含み、最初の情報要求ターンが前記問題の前記源と考えられることを特徴とする請求項１５に記載のコンピュータ実施される方法（６３１）。
【発明の詳細な説明】
【背景技術】
【０００１】
下の議論は、単に、全般的背景情報として提供され、請求される主題の範囲を判定する際の助けとして使用されることは意図されていない。
【０００２】
携帯情報端末（ＰＤＡ）、デバイス、および携帯電話機などの小型コンピューティング、デバイスは、人々によって、彼らの毎日の活動でますます高まる頻度で使用されている。これらのデバイスを動作させるのに使用されるマイクロプロセッサに現在使用可能な処理能力の向上に伴って、これらのデバイスの機能性は高まりつつあり、いくつかの場合には統合されつつある。たとえば、今日の多くの携帯電話端末は、インターネットにアクセスし、ブラウズするのに使用することができ、住所、電話番号、および類似物などの個人情報を記憶するのに使用することができる。
【０００３】
したがって、これらのコンピューティングデバイスが高まる頻度で使用されつつあることを考慮すると、ユーザが情報をこれらのコンピューティングデバイスに入力する簡単なインターフェースを提供する必要がある。残念ながら、これらのデバイスを簡単に持ち運べるようにするためにこれらのデバイスをできる限り小さくすることの望みに起因して、分離されたボタンとしてアルファベットのすべての文字を有する従来のキーボードは、通常、これらのコンピューティングデバイスの筐体の使用可能な限られた表面積では、可能ではない。小型コンピューティングデバイスの例以外においても、すべてのタイプのコンピューティングデバイス用に、より便利なインターフェースを提供することに対して関心が高まっている。
【０００４】
この問題に対処するために、コンピューティングデバイス上でローカルに、ローカルネットワークを介して、またはインターネットなどの広域ネットワークを介してのいずれであれ、情報にアクセスするのにボイスまたは音声を使用することが関心を集め、また採用されるようになった。音声認識を用いると、一般に、ユーザとコンピューティングデバイスとの間でダイアログ対話が行われる。ユーザは、通常は可聴におよび／または可視に情報を受け取り、プロンプトに可聴に応答するか、コマンドを発行する。しかししばしば、アプリケーションの開発中または展開後に、そのアプリケーションの性能を確かめることが望ましい。具体的に言うと、ログされたデータからアプリケーションに関するユーザの使用法および／または成功率を確かめることが望ましい。そのような情報があれば、開発者は、アプリケーションのユーザの要請をよりよく満足するために、アプリケーションを「チューニングする」（すなわち、調整を行う）ことができる可能性がある。たとえば、アプリケーションとユーザとの間のダイアログのうちで、問題に出会う可能性が最も高い部分を識別することが、有用である場合がある。この形で、ダイアログのこれらの部分を、混乱を軽減するために調整することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
それでも、展開されたアプリケーションのログデータ（たとえば、音声およびＤＴＭＦ）からダイアログ問題を判定することは、難しい。ダイアログ問題は、本質的に、対話の流れに関するユーザ体験の問題である。ダイアログ問題は、通常、ユーザがいらいらし、その後対話を中断してしまうかオペレータ支援を要求する結果をもたらす。さらに、ダイアログ問題は、カスタマの悪感情ならびにサポート出費に関して、アプリケーションを展開する組織にとってコストが高い。
【０００６】
ダイアログ問題の症状は、かなり明瞭である（低いタスク完了率およびハングアップまたは他のキャンセルの増加）が、そのような問題の原因は、見つけることが極端に難しい可能性がある。通常、ダイアログ問題は、システムと考慮中のタスクのユーザ理解との間の不一致の結果である傾向がある。ダイアログ問題は、一般に、混乱させるプロンプトまたは誤って（システムエラーまたはユーザの誤解によって）たどられるパスなど、より低水準のアプリケーション問題から生じる。
【０００７】
通常、診断を行うのに大量のセッションデータが必要であるが、大量のセッションデータは、そのようなデータの手動分析が、長く面倒なプロセスであることを意味する。たとえば、一般に、混乱の全体像を表面化させるためには、長い一続きのダイアログが必要であり、ダイアログは複数のユーザにまたがって一般化されなければならない。さらに、問題の源の位置（混乱が始まるダイアログ状態）を正確に指摘することは、難しい。というのは、所与のハングアップまたは他のユーザキャンセルについて、問題の源が、キャンセルの数ターン前である場合があるからである。さらに、音声アプリケーションは、ユーザ対話モデルとして非常に大きく異なる傾向があるので、自動化分析の実装は、一般に、アプリケーション固有になり、拡張性において制限される。最後に、音声認識アプリケーションについて、音声認識器が不完全であるため、ユーザ挙動の真の分析は、一般に、ユーザ入力の手動トランスクリプションを基礎としなければならないことを意味し、これは、間接的で通常コストのかかるプロセスである。
【課題を解決するための手段】
【０００８】
この「発明の開示」は、下の「発明を実施するための最良の形態」でさらに説明されるいくつかの概念を単純化された形で紹介するために提供される。この「発明の開示」では、請求される主題の主要な特徴または本質的特徴を特定することは意図しておらず、請求される主題の範囲を判定する際の助けとして使用されることも意図していない。
【０００９】
音声、ＤＴＭＦ（デュアルトーン変調周波数）などであるがこれらに限定はされないユーザ／システム対話のダイアログ分析は、さまざまなアプリケーションにおいて一般的である、蓋然性の高いダイアログ問題を識別する自動化された技法を提供し、リソース／発話の記録取り(transcription)の必要を取り除くことができる。分析プロセスが、ログデータに適用され、ダイアログターン（ユーザ−システム間の対話）情報などのダイアログ移動情報を使用して、アプリケーション内で最も蓋然性の高い問題を明らかにし、かつ／または診断する。ダイアログターン情報は、ターンのタイプ（新しい情報に関して尋ねる、値の確認に関して尋ねる、情報ステートメントを与えるなど）およびプロンプトタイプ（質問、ステートメントを与えること、ヘルプの提供、情報内容の繰り返し、「認識なし」イベントへの応答、無音への応答など）などであるが、これらに限定されない。
【００１０】
たとえば、毎週数千回の呼を受ける電話システム（音声認識またはＤＴＭＦ入力を有する）を与えられて、データ分析を、１週間分の呼のログに対して実行することができ、そのデータ分析は、アプリケーションのすべてのユーザが出会う可能性が高い問題を強調することができる。データ分析は、様々な種類の問題およびその理由についても表示を提供することができる。例えば、成功／失敗率とは別に、「平均以下のパフォーマンス」、すなわち低いレベルのユーザビリティを示すダイアログ（タスク）、プロンプトがユーザを混乱させるものになっているダイアログ状態、問題が最も多数のユーザにとって表面化し始めるダイアログ状態などであるが、これらに限定されない。
【００１１】
このデータ分析の結果として、アプリケーションをチューニングしている開発者は、今や、より多くのデータまたは呼を分析することを必要とせずに、これらの問題を妥当性検査するために分析をすばやく実行し、かつ／または必要な場合にタスクおよび状態を修正することができる。これは、アプリケーションの保守およびチューニングの時間およびコストのかなりの節約を表す。
【発明を実施するための最良の形態】
【００１２】
ダイアログ分析を具体的にではあるが音声アプリケーションおよびＤＴＭＦに限定されずに説明する前に、音声アプリケーションで使用できるコンピューティングデバイスを全般的に説明することが有用であるかもしれない。ここで図１を参照すると、データ管理デバイス（ＰＩＭ、ＰＤＡ、または類似物）の例示的な形が、３０に示されている。しかし、本明細書で説明する概念を、下で述べる他のコンピューティングデバイス、具体的には入力ボタンまたは類似物のための限られた表面積を有するコンピューティングデバイスを使用して実践することもできることが、企図されている。たとえば、電話機および／またはデータ管理デバイスも、本明細書で説明される概念から利益を得る。そのようなデバイスは、既存のポータブルパーソナル情報管理デバイスおよび他のポータブル電子デバイスと比較して高められたユーティリティを有し、そのようなデバイスの機能およびコンパクトなサイズは、ユーザがそのデバイスを常時持ち運ぶことを促進する可能性がより高い。したがって、本明細書で説明される応用例の範囲が、本明細書で示される例示的なデータ管理デバイスもしくはＰＩＭデバイス、電話機、またはコンピュータの開示に限定されることは、意図されていない。
【００１３】
データ管理モバイルデバイス３０の例示的な形が、図１に示されている。モバイルデバイス３０は、ハウジング３２を含み、ディスプレイ３４を含むユーザインターフェースを有し、ディスプレイ３４は、スタイラス３３と共に接触感知型ディスプレイスクリーンを使用する。スタイラス３３は、指定された座標でディスプレイ３４を押すかこれに接触して、フィールドを選択し、カーソルの開始位置を選択的に移動し、またはジェスチャもしくは手書きを介するなど、他の形でコマンド情報を提供するのに使用される。その代わりにまたはそれに加えて、１つまたは複数のボタン３５を、ナビゲーションのためにデバイス３０に含めることができる。さらに、回転可能なホイール、ローラー、または類似物などの他の入力機構を設けることもできる。しかし、本発明がこれらの形の入力機構によって限定されることが意図されていないことに留意されたい。たとえば、別の形の入力に、コンピュータビジョンを介するなどのビジュアル入力を含めることができる。
【００１４】
ここで図２を参照すると、ブロック図に、モバイルデバイス３０を含む機能コンポーネントが示されている。中央処理装置（ＣＰＵ）５０が、ソフトウェア制御機能を実装する。ＣＰＵ  ５０は、ディスプレイ３４に結合され、その結果、制御ソフトウェアに従って生成されたテキストおよびグラフィックアイコンが、ディスプレイ３４に表示されるようになる。スピーカ４３を、通常はディジタル−アナログコンバータ５９と共にＣＰＵ  ５０に結合して、可聴出力を提供することができる。モバイルデバイス３０にダウンロードされるかユーザによって入力されたデータは、ＣＰＵ  ５０に両方向で結合された不揮発性読み取り／書き込みランダムアクセスメモリストア５４に格納される。ランダムアクセスメモリ（ＲＡＭ）５４は、ＣＰＵ  ５０によって実行される命令の揮発性ストレージと、レジスタ値などの一時的データのストレージとをもたらす。構成オプションおよび他の変数のデフォルト値は、読み取り専用メモリ（ＲＯＭ）５８に格納される。ＲＯＭ  ５８は、モバイル３０の基本機能性および他のオペレーティングシステムカーネル機能（たとえば、ＲＡＭ  ５４へのソフトウェアコンポーネントのロード）を制御する、デバイスのオペレーティングシステムソフトウェアを格納するのにも使用することができる。
【００１５】
ＲＡＭ  ５４は、アプリケーションプログラムを格納するのに使用されるＰＣ上のハードドライブの機能に似た形で、コードのストレージとしても働く。不揮発性メモリが、コードの格納に使用されているが、その代わりに、コードの実行には使用されない揮発性メモリにコードを格納することができることに留意されたい。
【００１６】
無線信号を、ＣＰＵ  ５０に結合された無線トランシーバ５２を介してモバイルデバイスによって送信／受信することができる。望まれる場合、オプションの通信インターフェース６０を、コンピュータ（たとえば、デスクトップコンピュータ）または有線ネットワークから直接にデータをダウンロードするために設けることもできる。したがって、インターフェース６０は、さまざまな形の通信デバイス、たとえば、赤外線リンク、モデム、ネットワークカード、または類似物を含むことができる。
【００１７】
モバイルデバイス３０は、マイクロホン２９、アナログ−ディジタル（Ａ／Ｄ）コンバータ３７、およびストア５４に格納されたオプションの認識プログラム（音声、ＤＴＭＦ、手書き、ジェスチャ、またはコンピュータビジョン）を含む。たとえば、デバイス３０のユーザからの可聴の情報、命令、またはコマンドに応答して、マイクロホン２９は、音声信号を供給し、この信号がＡ／Ｄコンバータ３７によってディジタル化される。音声認識プログラムは、ディジタル化された音声信号に対して正規化機能および／または特徴抽出機能を実行して、中間音声認識結果を得ることができる。無線トランシーバ５２または通信インターフェース６０を使用して、音声データを、下で述べる、図４のアーキテクチャに示されたリモート認識サーバ２０４に送信することができる。その後、認識結果を、モバイルデバイス３０でのレンダリング（たとえば、ビジュアルおよび／または可聴）およびウェブサーバ２０２（図４）への最終的な送信のためにモバイルデバイス３０に返すことができ、ここで、ウェブサーバ２０２およびモバイルデバイス３０は、クライアント／サーバ関係で動作する。類似する処理を、他の形の入力について使用することができる。たとえば、手書き入力を、デバイス３０での前処理を伴ってまたはこれを伴わずにディジタル化することができる。音声データと同様に、この形の入力を、認識のために認識サーバ２０４に送信することができ、ここで、認識結果は、その後、デバイス３０および／またはウェブサーバ２０２のうちの少なくとも１つに返される。同様に、ＤＴＭＦデータ、ジェスチャデータ、およびビジュアルデータを、似た形で処理することができる。入力の形に応じて、デバイス３０（および上で述べた他の形のクライアント）は、ビジュアル入力用のカメラなど、必要なハードウェアを含むはずである。
【００１８】
上で説明したポータブルコンピューティングデバイスまたはモバイルコンピューティングデバイスに加えて、本明細書で説明する概念を、一般的なデスクトップコンピュータなどの多数の他のコンピューティングデバイスと共に使用できることを理解されたい。たとえば、限られた身体能力を有するユーザは、フル英数字キーボードなどの他の従来の入力装置の操作が難し過ぎる場合でも、コンピュータまたは他のコンピューティングデバイスにテキストを入力することができる。
【００１９】
本発明は、多数の他の汎用のまたは特殊目的のコンピューティングシステム、コンピューティング環境、またはコンピューティング構成と共にも動作する。本発明と共に使用するのに適切である可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例は、無線電話機またはセルラ電話機、通常の電話機（スクリーンを伴わない）、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物を含むが、これらに限定はされない。
【００２０】
次は、図３に示された汎用コンピュータ１２０の短い説明である。しかし、コンピュータ１２０は、やはり、適切なコンピューティング環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する限定を提案することは意図されていない。コンピュータ１２０を、その中に示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【００２１】
下の説明を、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の全体的な文脈で提供することができる。一般に、プログラムモジュールは、特定のタスクを実行するか特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。本明細書で説明される例示的実施形態は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体との両方に配置することができる。プログラムおよびモジュールによって実行されるタスクを、下で、図面の助けを得て説明する。当業者は、この説明および図面を、プロセッサ実行可能命令として実装することができ、このプロセッサ実行可能命令は、任意の形のコンピュータ可読媒体に書き込まれ得る。
【００２２】
図３を参照すると、コンピュータ１２０のコンポーネントは、処理ユニット１４０と、システムメモリ１５０と、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット１４０に結合するシステムバス１４１とを含むことができるが、これらに限定はされない。システムバス１４１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。限定ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。コンピュータ１２０には、通常は、さまざまなコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピュータ１２０によってアクセスすることができるすべての使用可能な媒体とすることができ、コンピュータ可読媒体には、揮発性媒体と不揮発性媒体との両方、取外し可能媒体と取外し不能媒体との両方が含まれる。限定ではなく例として、コンピュータ可読媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータなどの情報を記憶する任意の方法またはテクノロジで実施される、揮発性と不揮発性と両方の、取外し可能および取外し不能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を格納するのに使用することができ、コンピュータ１２０によってアクセスすることができるすべての他の媒体が含まれるが、これに限定はされない。
【００２３】
通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータを実施し、通信媒体は、すべての情報配信媒体を含む。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＦＲ、赤外線、および他の無線媒体などの無線媒体を含む。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれなければならない。
【００２４】
システムメモリ１５０には、読み取り専用メモリ（ＲＯＭ）１５１およびランダムアクセスメモリ（ＲＡＭ）１５２などの揮発性および／または不揮発性のメモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１２０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１５３（ＢＩＯＳ）が、通常はＲＯＭ  １５１に格納される。ＲＡＭ  １５２には、通常は、即座にアクセス可能であるおよび／または処理ユニット１４０によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図３に、オペレーティングシステム５４、アプリケーションプログラム１５５、他のプログラムモジュール１５６、およびプログラムデータ１５７を示す。
【００２５】
コンピュータ１２０には、他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体を含めることもできる。例としてのみ、図３に、取外し不能不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１６１、取外し可能不揮発性磁気ディスク１７２から読み取るかこれに書き込む磁気ディスクドライブ１７１、およびＣＤ−ＲＯＭまたは他の光学媒体などの取外し可能不揮発性光ディスク１７６から読み取るかこれに書き込む光学ディスクドライブ１７５を示す。この例示的オペレーティング環境で使用することができる他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定はされない。ハードディスクドライブ１６１は、通常は、インターフェース１６０などの取外し不能メモリインターフェースを介してシステムバス１４１に接続され、磁気ディスクドライブ１７１および光学ディスクドライブ１７５は、通常は、インターフェース１７０などの取外し可能メモリインターフェースによってシステムバス１４１に接続される。
【００２６】
上で述べ、図３に図示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１２０のコンピュータ可読命令、データ構造体、プログラムモジュール、および他のデータのストレージを提供する。図３では、たとえば、ハードディスクドライブ１６１が、オペレーティングシステム１６４、アプリケーションプログラム１６５、他のプログラムモジュール１６６、およびプログラムデータ１６７を格納するものとして図示されている。これらのコンポーネントは、オペレーティングシステム１５４、アプリケーションプログラム１５５、他のプログラムモジュール１５６、およびプログラムデータ１５７と同一でも異なってもいずれでもよいことに留意されたい。オペレーティングシステム１６４、アプリケーションプログラム１６５、他のプログラムモジュール１６６、およびプログラムデータ１６７は、最低限でもこれらが異なるコピーであることを示すために、本明細書では異なる符号を与えられている。
【００２７】
ユーザは、キーボード１８２、マイクロホン１８３、およびマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１８１などの入力デバイスを介してコンピュータ１２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１８０を介して処理ユニット１４０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続されることが可能である。モニタ１８４または他のタイプのディスプレイデバイスも、ビデオインターフェース１８５などのインターフェースを介してシステムバス１４１に接続される。モニタの他に、コンピュータに、スピーカ１８７およびプリンタ１８６など、出力周辺インターフェース１８８を介して接続することができる他の周辺出力デバイスをも含めることができる。
【００２８】
コンピュータ１２０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ１２０に関して上で説明した要素の多数またはすべてを含む。図３に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１９１および広域ネットワーク（ＷＡＮ）１９３が含まれるが、他のネットワークを含めることもできる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【００２９】
ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１２０は、ネットワークインターフェースまたはネットワークアダプタ１９０を介してＬＡＮ  １９１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１２０には、通常は、インターネットなどのＷＡＮ  １９３を介する通信を確立する、モデム１９２または他の手段が含まれる。モデム１９２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１８０または他の適当な機構を介してシステムバス１４１に接続することができる。ネットワーク化された環境では、コンピュータ１２０に関して示されたプログラムモジュールまたはその諸部分を、リモートメモリストレージデバイスに格納することができる。制限ではなく例として、図３に、リモートコンピュータ１９４に常駐するリモートアプリケーションプログラム１９５を示す。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用することができることを諒解されたい。
【００３０】
例示的実施形態
図４に、本明細書で説明する概念と共に使用できるネットワークベースの認識（本明細書では広域ネットワークを用いて例示される）のアーキテクチャ２００を示す。しかし、リモートコンポーネントとの相互作用していることは１つの実施形態にすぎず、認識器(リコグナイザ：recognizer)を含めて音声アプリケーションは、その中にすべての必要なコンポーネントまたはモジュールを備えた単一のコンピューティングデバイス上で動作可能とすることができることを理解されたい。
【００３１】
一般に、ウェブサーバ２０２に格納された情報には、モバイルデバイス３０（本明細書では、入力の形に基づいて、必要に応じてディスプレイスクリーン、マイクロホン、カメラ、接触感知型パネルなどを有する他の形のコンピューティングデバイスも表す）を介して、または電話機８０を介して（この場合に、情報は、可聴にまたは押されたキーに応答して電話機８０によって生成されるトーンを介して要求され、ウェブサーバ２０２からの情報は、可聴でのみユーザに戻って供給される）アクセスすることができる。
【００３２】
この例示的実施形態では、アーキテクチャ２００は、情報が音声認識を使用してデバイス３０または電話機８０のどちらを介して入手される場合であっても、単一の認識サーバ２０４が動作の両方のモードをサポートできるという点で、統一されている。さらに、アーキテクチャ２００は、周知のマークアップ音声（たとえば、ＨＴＭＬ、ＸＨＴＭＬ、ｃＨＴＭＬ、ＸＭＬ、ＷＭＬ、および類似物）の拡張版を使用して動作する。したがって、ウェブサーバ２０２に格納された情報に、これらのマークアップ音声に見られる周知のＧＵＩ法を使用してアクセスすることもできる。周知のマークアップ音声の拡張版を使用することによって、ウェブサーバ２０２でのオーサリングが、より簡単であり、現在存在するレガシアプリケーションを、ボイスまたは他の形の認識を含むように簡単に変更することもできる。
【００３３】
一般に、デバイス３０は、ウェブサーバ２０２によって供給されるＨＴＭＬ＋スクリプトまたは類似物を実行する。ボイス認識が必要な時には、たとえば、上で述べたようにオーディオ信号がデバイス３０によって前処理されている、ディジタル化されたオーディオ信号または音声特徴とすることのできる音声データが、音声認識中に使用すべき文法または言語モデルの表示と共に認識サーバ２０４に供給される。認識サーバ２０４の実施態様は、多数の形をとることができ、その１つが図示されているが、一般に、リコグナイザ２１１を含む。認識の結果を、望まれる場合または適当な場合にはローカルに提供できるように、デバイス３０に戻して供給する。認識および使用される場合のすべてのグラフィカルユーザインターフェースを介しての情報のコンパイルの際に、デバイス３０は、さらなる処理および必要な場合のさらなるＨＴＭＬスクリプトの受け取りのために、情報をウェブサーバ２０２に送信する。
【００３４】
図４に示されているように、デバイス３０、ウェブサーバ２０２、および認識サーバ２０４は、一般に、ここではインターネットなどの広域ネットワークであるネットワーク２０５を介して接続され、別々にアドレス付与可能である。したがって、これらのデバイスのいずれかが、物理的に互いに隣接して配置されることは、必要ではない。具体的に言うと、ウェブサーバ２０２が認識サーバ２０４を含むことは、必要ではない。この形で、ウェブサーバ２０２でのオーサリングは、作成者が認識サーバ２０４の込み入った事情を知る必要なしに、それが意図されたアプリケーションに集中することができる。むしろ、認識サーバ２０４を独立に設計し、ネットワーク２０５に接続し、これによって、ウェブサーバ２０２でのさらなる変更をする必要なしに、認識サーバ２０４を更新し、改善することができる。下で述べるように、ウェブサーバ２０２には、クライアントサイドマークアップおよびスクリプトを動的に生成できるオーサリング機構を含めることもできる。さらなる実施形態で、ウェブサーバ２０２、認識サーバ２０４、およびデバイス３０を、実装するマシンの機能に応じて組み合わせることができる。たとえば、クライアントが、汎用コンピュータ、たとえばパーソナルコンピュータを含む場合に、クライアントに、認識サーバ２０４を含めることができる。同様に、望まれる場合に、ウェブサーバ２０２および認識サーバ２０４を、単一のマシンに組み込むことができる。
【００３５】
電話機８０を介するウェブサーバ２０２へのアクセスは、有線または無線の電話網２０８への電話機８０の接続を含み、この接続は、電話機８０をサードパーティのゲートウェイ２１０に接続する。ゲートウェイ２１０は、電話機８０をテレフォニボイスブラウザ２１２に接続する。テレフォンボイスブラウザ２１２は、テレフォニインターフェースおよびボイスブラウザ２１６を提供するメディアサーバ２１４を含む。デバイス３０と同様に、テレフォニボイスブラウザ２１２は、ウェブサーバ２０２からＨＴＭＬスクリプトまたは類似物を受信する。一実施形態で、ＨＴＭＬスクリプトは、デバイス３０に供給されるＨＴＭＬスクリプトに類似する形を有する。この形で、ウェブサーバ２０２は、デバイス３０および電話機８０を別々にサポートする必要がなく、標準ＧＵＩクライアントを別々にサポートする必要さえない。そうではなく、共通のマークアップ言語を使用することができる。さらに、デバイス３０と同様に、電話機８０によって送信される可聴信号からのボイス認識は、ボイスブラウザ２１６から認識サーバ２０４へ、たとえばＴＣＰ／ＩＰを使用して、ネットワーク２０５を介してまたは専用回線２０７を介してのいずれかで供給される。ウェブサーバ２０２、認識サーバ２０４、およびテレフォンボイスブラウザ２１２は、図３に示された汎用デスクトップコンピュータなどの任意の適切なコンピューティング環境で実施することができる。
【００３６】
しかし、ＤＴＭＦ認識が使用される場合に、この形の認識が、一般に、認識サーバ２０４ではなくメディアサーバ２１４で実行されることに留意されたい。言い換えると、ＤＴＭＦ文法は、メディアサーバ２１４によって使用されるはずである。
【００３７】
図４に戻ると、ウェブサーバ２０２には、サーバサイドプラグインオーサリングツールまたはモジュール２０９（たとえば、Ｍｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎによるＡＳＰ、ＡＳＰ＋、およびＡＳＰ．Ｎｅｔ、ＪＳＰ、Ｊａｖａ（登録商標）ｂｅａｎｓ、または類似物）を含めることができる。サーバサイドプラグインモジュール２０９は、クライアントサイドマークアップを動的に生成でき、ウェブサーバ２０２にアクセスするクライアントのタイプ用のマークアップの特定の形すら動的に生成することができる。クライアント情報は、クライアント／サーバ関係の最初の確立時にウェブサーバ２０２に供給することができ、あるいは、ウェブサーバ２０２に、クライアントデバイスの機能を検出するモジュールまたはルーチンを含めることができる。この形で、サーバサイドプラグインモジュール２０９は、ボイス認識シナリオごとに、すなわち電話機８０を介してはボイスのみまたはデバイス３０についてマルチモーダルで、クライアントサイドマークアップを生成することができる。一貫するクライアントサイドモデルを使用することによって、多数の異なるクライアント用のアプリケーションオーサリングが、大幅により単純になる。
【００３８】
クライアントサイドマークアップの動的生成に加えて、下で述べる高水準ダイアログモジュールを、アプリケーションオーサリングでの開発者による使用のためにストア２１１に格納されるサーバサイドコントロールとして実装することができる。一般に、高水準ダイアログモジュール２１１は、開発者によって指定されるパラメータに基づいて、ボイスのみのシナリオとマルチモーダルシナリオとの両方でクライアントサイドマークアップおよびスクリプトを動的に生成する。高水準ダイアログモジュール２１１には、開発者の必要に合わせるために、クライアントサイドマークアップを生成するためのパラメータを含めることができる。
【００３９】
クライアントサイドマークアップの生成
上で示したように、サーバサイドプラグインモジュール２０９は、クライアントデバイス３０から要求が行われた時に、クライアントサイドマークアップを出力する。手短に言うと、サーバサイドプラグインモジュール２０９は、ウェブサイトを、したがってアプリケーションおよびそのアプリケーションによって提供されるサービスを、定義しまたは構築することを可能にする。サーバサイドプラグインモジュール２０９内の命令は、コンパイルされたコードから作られる。このコードは、ウェブ要求がウェブサーバ２０２に達する時に実行される。次に、サーバサイドプラグインモジュール２０９が、新しいクライアントサイドマークアップページを出力し、このクライアントサイドマークアップページが、クライアントデバイス３０に送信される。周知の通り、このプロセスを、一般にレンダリングと称する。サーバサイドプラグインモジュール２０９は、マークアップ言語を抽象化し、カプセル化する「コントロール」を操作し、したがってクライアントサイドマークアップページのコードを操作する。マークアップ言語を抽象化し、カプセル化し、ウェブサーバ２０２上で動作するそのようなコントロールは、たとえば、「サーブレット」または「サーバサイドプラグイン」を含み、またはこれらと同等である。
【００４０】
既知の通り、従来技術のサーバサイドプラグインモジュールは、ビジュアルレンダリングおよびクライアントデバイス３０との相互作用に関するクライアントサイドマークアップを生成することができる。特許出願書に、認識拡張および可聴プロンプト拡張を含めるためのサーバサイドプラグインモジュール２０９の拡張に関する３つの異なる手法が詳細に記載されている（たとえば、特許文献１および特許文献２参照）。本発明の諸態様は、これらの手法のすべてと共に使用することができるが、１つの手法の短い説明を、例示的実施形態を説明するために以下で提供する。
【００４１】
図５を参照すると、認識／可聴プロンプトコントロール３０６は、ビジュアルコントロール３０２と別々であるが、下で述べるように選択的にこれに関連する。この形で、コントロール３０６は、ビジュアルコントロール３０２に直接に基づいて構築されるのではなく、ビジュアルコントロール３０２を書き直す必要なしに認識／可聴プロンプト使用可能化を提供する。コントロール３０６は、コントロール３０２と同様に、ライブラリ３００を使用する。この実施形態で、ライブラリ３００は、ビジュアルプロンプトマークアップ情報と認識／可聴プロンプトマークアップ情報との両方を含む。
【００４２】
この手法には、大きい利点がある。第１に、ビジュアルコントロール３０２は、内容において変更される必要がない。第２に、コントロール３０６は、一貫性があり、音声対応コントロール３０２の性質に従って変更される必要がない単一のモジュールを形成することができる。第３に、音声使用可能化のプロセスすなわち、ビジュアルコントロール３０２とのコントロール３０６の明示的な関連付けは、明示的かつ選択的なプロセスなので、設計時に完全に開発者の制御の下にある。これは、ビジュアルコントロールのマークアップ言語が、コントロール３０６によって生成されたマークアップ言語によって提供される認識を介してまたはキーボードなどの従来の入力デバイスを介してなど、複数のソースからの入力値を受け取ることを可能にもする。短く言うと、コントロール３０６を、サーバサイドプラグインモジュール２０９のビジュアルオーサリングページの既存アプリケーションオーサリングページに追加することができる。コントロール３０６は、クライアントデバイス３０のユーザに対話の新しいモーダリティ（すなわち、認識および／または可聴プロンプト）を提供すると同時に、ビジュアルコントロールのアプリケーションロジックおよびビジュアル入出力機能を再利用する。コントロール３０６を、アプリケーションロジックをコーディングできるビジュアルコントロール３０２に関連付けることができることを考慮して、コントロール３０６を、以下では「コンパニオンコントロール３０６」と称し、ビジュアルコントロール３０２を、「プライマリコントロール３０２」と称する。これらの呼称は、コントロール３０２および３０６を区別するために提供されたもので、制限的であることは意図されていないことに留意されたい。たとえば、コンパニオンコントロール３０６を使用して、ボイスのみウェブサイトなどのビジュアルレンダリングを含まないウェブサイトを開発し、またはオーサリングすることができる。その場合に、ある種のアプリケーションロジックを、コンパニオンコントロールロジックで実施することができる。
【００４３】
コンパニオンコントロール４００の例示的セットを、図６に示す。この実施形態では、コンパニオンコントロール４００は、一般に、ＱＡコントロール４０２、コマンドコントロール４０４、比較バリデータ（ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒ）コントロール４０６、カスタムバリデータ（Ｃｕｓｔｏｍ  Ｖａｌｉｄａｔｏｒ）コントロール４０８、およびセマンティックマップ４１０を含む。セマンティックマップ４１０は、概略的に示されており、セマンティックアイテム  ４１２を含み、セマンティックアイテム  ４１２は、ビジュアルドメインプライマリコントロール４０２（たとえば、コンパニオンコントロール４００のＨＴＭＬおよび非ビジュアル認識ドメインの間のレイヤを形成する、入力フィールドと考えることができる。
【００４４】
ＱＡコントロール４０２は、出力コントロールの機能を実行するＰｒｏｍｐｔオブジェクトを参照する、すなわち、ヒューマンダイアログ用の「プロンプトする」クライアントサイドマークアップを提供するプロンプト特性を有し、このクライアントサイドマークアップは、通常、直接にマークアップに含まれるかＵＲＬを介して参照されるデータである事前に録音されたオーディオファイルまたはテキスト−音声変換用のテキストを再生することを含む。同様に、入力コントロールは、ＱＡコントロール４０２およびコマンドコントロール４０４として実施され、ヒューマンダイアログにも従い、プロンプト（Ｐｒｏｍｐｔ）プロパティ（Ｐｒｏｍｐｔオブジェクトを参照する）と少なくとも１つの応答（Ａｎｓｗｅｒ）オブジェクトを参照するプロンプト（Ａｎｓｗｅｒ）プロパティとを含む。ＱＡコントロール４０２とコマンドコントロール４０４との両方が、クライアントデバイス３０のユーザからの期待される入力または可能な入力に文法を関連付ける。
【００４５】
この点で、コントロールのそれぞれの短い説明を提供することが役に立つであろう。
【００４６】
ＱＡコントロール
一般に、ＱＡコントロール４０２は、図示のプロパティを介して、たとえば、出力可聴プロンプトの提供、入力データの収集、入力結果の信頼性妥当性検査の実行、入力データの確認の可能化、およびウェブサイトでのダイアログフローの制御の援助のうちの１つまたは複数を実行することができる。言い換えると、ＱＡコントロール４０２は、特定のトピックのコントロールとして機能するプロパティを含む。
【００４７】
ＱＡコントロール４０２は、他のコントロールと同様に、ウェブサーバ２０２上で実行され、これは、ＱＡコントロール４０２が、サーバサイドマークアップフォーマリズム（ＡＳＰ、ＪＳＰ、または類似物）を使用してウェブサーバ上で保持されるアプリケーション開発ウェブページで定義されるが、異なる形のマークアップとしてクライアントデバイス３０に出力されることを意味する。ＱＡコントロールは、図６ではプロパティＰｒｏｍｐｔ、Ｒｅｃｏ、Ａｎｓｗｅｒｓ、ＥｘｔｒａＡｎｓｗｅｒｓ、およびＣｏｎｆｉｒｍｓのすべてから形成されるように図示されてはいるが、これらは単にオプションであり、ＱＡコントロールがこれらのうちの１つまたは複数を含んでいれば良いことを理解されたい。
【００４８】
この点で、アプリケーションシナリオに関してＱＡコントロール４０２の使用を説明することが役に立つであろう。図６を参照すると、ボイスのみアプリケーションにおいて、ＱＡコントロール４０２は、ダイアログ内の質問および回答として機能することができる。質問は、Ｐｒｏｍｐｔオブジェクトによって提供され、文法は、入力データの認識およびその入力に対する関連する処理のための文法オブジェクトを介して定義される。Ａｎｓｗｅｒｓプロパティは、Ａｎｓｗｅｒオブジェクトを使用して、認識された結果をセマンティックマップ４１０内のセマンティックアイテム４１２に関連付け、Ａｎｓｗｅｒオブジェクトは、認識結果をどのように処理するかに関する情報を含む。線４１４は、セマンティックマップ４１０およびその中のセマンティックアイテム４１２とのＱＡコントロール４０２の関連付けを示す。多数のセマンティックアイテム４１２が、線４１８によって表されるようにビジュアルコントロールまたはプライマリコントロール３０２に個別に関連するが、１つまたは複数のセマンティックアイテム４１２を、ビジュアルコントロールに関連せず、内部的にのみ使用されるものとすることができる。クライアントデバイス３０のユーザが、たとえば「ＴａｐＥｖｅｎｔ」を用いてビジュアルテキストボックスに触れることができるマルチモーダルシナリオでは、可聴プロンプトは必要でない場合がある。たとえば、クライアントデバイスのユーザが対応するフィールドに何を入力しなければならないかの表示をするビジュアルテキストを有するテキストボックスを含むプライマリコントロールに対しては、対応するＱＡコントロール４０２は、オーディオ再生またはテキスト−音声変換などの対応するプロンプトを有しても有しなくてもよいが、認識の期待値に対応する文法と、入力を処理する、または音声が検出されない、音声が認識されない、またはタイムアウト時に起きるイベントなどの他のリコグナイザイベントを処理する、イベントハンドラとを有する。
【００４９】
さらなる実施形態では、認識結果が、その認識結果が正しかったことの信頼性のレベルを示す信頼性レベル測定値を含む。確認閾値を、Ａｎｓｗｅｒオブジェクト内で、たとえば０．７と等しいＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄとして指定することもできる。確認レベルが、関連する閾値を超える場合に、その結果を、確認されたと考えることができる。
【００５０】
音声認識の文法を指定するのに加えてまたはその代わりに、ＱＡコントロールおよび／またはＣｏｍｍａｎｄコントロールが、Ｄｔｍｆ（デュアルトーン変調周波数）文法を指定して、プロンプトまたは質問に応答して電話機キーアクティブ化を認識できることにも留意されたい。
【００５１】
この点で、セマンティックマップ４１０のセマンティックアイテム４１２が、たとえば認識を介して音声またはＤｔｍｆによって充たされると、複数のアクションを行えることに留意されたい。第１に、値が「変更された」ことを示すイベントを、発行するか発生させることができる。確認レベルが満足されたかどうかに応じて、発行または発声させられるもう１つのイベントとして、対応するセマンティックアイテムが確認されたことを示す「確認」イベントが含まれる。これらのイベントは、ダイアログを制御するのに使用される。
【００５２】
確認（Ｃｏｎｆｉｒｍｓ）プロパティには、セマンティックアイテム４１２に関連し、望まれる場合に確認閾値（ＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄ）を含むことができるという点で、Ａｎｓｗｅｒｓプロパティに関して上で説明したものに類似する構造を有する回答オブジェクトを含めることもできる。Ｃｏｎｆｉｒｍｓプロパティは、認識結果自体を含むことが意図されているのではなく、既に含まれる結果を確認し、含まれる結果が正しいかどうかをユーザから確かめることが意図されている。Ｃｏｎｆｉｒｍｓプロパティは、前に得られた結果の値が正しかったかどうかを主張(assertするのに使用されるＡｎｓｗｅｒオブジェクトのコレクションである。含む(containing)ＱＡのＰｒｏｍｐｔオブジェクトは、これらのアイテムについて照会し、関連するセマンティックアイテム４１２から認識結果を入手し、これを「Ｄｉｄ  ｙｏｕ  ｓａｙ  Ｓｅａｔｔｌｅ？（シアトルと言いましたか）」などの質問に形成する。ユーザが、「Ｙｅｓ（はい）」などの肯定で応答する場合には、確認済みイベントが生成される。ユーザが、「Ｎｏ（いいえ）」などの否定で応答する場合には、関連するセマンティックアイテム４１２がクリアされる。
【００５３】
Ｃｏｎｆｉｒｍｓプロパティは、確認プロンプトがユーザに提供された後に、訂正を受け入れることもできる。たとえば、確認プロンプト「Ｄｉｄ  ｙｏｕ  ｓａｙ  Ｓｅａｔｔｌｅ？」に応答して、ユーザが、「Ｓａｎ  Ｆｒａｎｃｉｓｃｏ（サンフランシスコ）」、または「Ｎｏ，Ｓａｎ  Ｆｒａｎｃｉｓｃｏ（いいえ、サンフランシスコです）」と応答することができ、この場合に、ＱＡコントロールは、訂正を受け取っている。Ａｎｓｗｅｒオブジェクトを介してどのセマンティックアイテムが確認されているかに関する情報を有するので、セマンティックアイテム内の値を、訂正された値に置換することができる。望まれる場合に、「Ｗｈｅｎ  ｄｉｄ  ｙｏｕ  ｗａｎｔ  ｔｏ  ｇｏ  ｔｏ  Ｓｅａｔｔｌｅ？（いつシアトルに行きたいですか）」などの情報に関して、さらなるプロンプトに確認を含めることができ、ここで、システムによるこのプロンプトは、「Ｓｅａｔｔｌｅ」に関する確認と、出発の日付に関するさらなるプロンプトとを含むことに留意されたい。ユーザの応答が目的地の場所を訂正すると、Ｃｏｎｆｉｒｍｓプロパティをアクティブ化して、関連するセマンティックアイテムを訂正し、出発日だけを伴う応答であれば、目的地の暗黙の確認となる。
【００５４】
ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、なされたプロンプトまたは照会に加えてユーザが提供するＡｎｓｗｅｒオブジェクトを、アプリケーション作成者が指定することを可能にする。たとえば、旅行指向システムが、目的地の都市に関してユーザにプロンプトを出し、ユーザが「Ｓｅａｔｔｌｅ  ｔｏｍｏｒｒｏｗ（シアトル、明日）」を示して応答する場合に、当初にそのユーザにプロンプトを出したＡｎｓｗｅｒｓプロパティは、目的地都市「Ｓｅａｔｔｌｅ」を取り出し、これを適当なセマンティックアイテムに結び付けるが、ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、次に続く日として「Ｔｏｍｏｒｒｏｗ」を処理することができ（システムが現在の日付を知っていると仮定して）、これによって、この結果をセマンティックマップ内の適当なセマンティックアイテムに結びつけることができる。ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、ユーザが述べるかもしれない余分な情報について定義された１つまたは複数のＡｎｓｗｅｒオブジェクトを含む。上で提供した例では、出発日の情報を取り出したので、確認レベルが対応するＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄを超えたと仮定すると、このシステムはこの情報についてユーザに再びプロンプトを出す必要がない。確認レベルが対応する閾値を超えなかった場合には、適当なＣｏｎｆｉｒｍｓプロパティがアクティブ化されるはずである。
【００５５】
Ｃｏｍｍａｎｄコントロール
Ｃｏｍｍａｎｄコントロール４０４は、通常は問われた質問に関連しては意味的重要性をほとんど有さず、たとえばヘルプ、キャンセル、繰り返しなど、援助を求めるかナビゲーションをもたらす、ボイスのみダイアログで一般的なユーザ発話である。Ｃｏｍｍａｎｄコントロール４０４には、プロンプトオブジェクトを指定するＰｒｏｍｐｔプロパティを含めることができる。さらに、Ｃｏｍｍａｎｄコントロール４０４は、文法（Ｇｒａｍｍａｒプロパティを介する）および認識に対する関連する処理（どちらかといえば、セマンティックアイテムへの結果のバインディングなしのＡｎｓｗｅｒオブジェクトに似る）だけではなく、コンテキストの「スコープ」およびタイプを指定するのにも使用することができる。これは、クライアントサイドマークアップでのグローバル挙動とコンテキスト感応型挙動との両方のオーサリングを可能にする。Ｃｏｍｍａｎｄコントロール４０４は、「ヘルプ」コマンドまたは、クライアントデバイスのユーザがウェブサイトの他の選択されたエリアへナビゲートすることを可能にするコマンドなど、追加のタイプの入力を可能にする。
【００５６】
ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロール
ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールは、演算子に従って２つの値を比較し、適当なアクションを行う。比較される値は、整数、テキストのストリングなど、任意の形とすることができる。ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒは、妥当性検査されるセマンティックアイテムを示すプロパティセマンティックアイテムバリデート（ＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅ）を含む。妥当性検査されるセマンティックアイテムを、定数または別のセマンティックアイテムと比較することができ、ここで、定数または他のセマンティックアイテムは、それぞれプロパティＶａｌｕｅｔｏＣｏｍｐａｒｅおよびＳｅｍａｔｉｃＩｔｅｍｔｏＣｏｍｐａｒｅによって供給される。ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒに関連する他のパラメータまたはプロパティには、行われる比較を定義するＯｐｅｒａｔｏｒと、たとえば整数またはセマンティックアイテムのストリングなど、値のタイプを定義するＴｙｐｅとが含まれる。
【００５７】
ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールに関連する妥当性検査が不合格の場合に、Ｐｒｏｍｐｔプロパティは、得られた結果が正しくなかったことをユーザに指示する、再生できるＰｒｏｍｐｔオブジェクトを指定することができる。比較の際に妥当性検査が不合格になる場合には、ＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅによって定義された関連するセマンティックアイテムは、システムが正しい値についてユーザに再びプロンプトを出すために、空であるものとして示される。しかし、正しくない値が、正しくない値を繰り返すユーザへのプロンプトに使用される場合に、セマンティックマップ内の関連するセマンティックアイテムの正しくない値をクリアしないことが役に立つ場合がある。アプリケーション作成者の望みに応じて、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールを、関連するセマンティックアイテムの値が値を変化させる時またはその値が確認された時のいずれかにトリガすることができる。
【００５８】
ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロール
ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールは、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールに似ている。プロパティＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅは、妥当性検査されるセマンティックアイテムを示し、プロパティＣｌｉｅｎｔＶａｌｉｄａｔｉｏｎＦｕｎｃｔｉｏｎは、関連する関数またはスクリプトを介してカスタム妥当性検査ルーチンを指定する。この関数は、妥当性検査が不合格であったか否かのブール値「ｙｅｓ」もしくは「ｎｏ」またはその同等物を提供する。Ｐｒｏｍｐｔプロパティは、妥当性検査のエラーまたは不合格の表示を提供するＰｒｏｍｐｔオブジェクトを指定することができる。アプリケーション作成者の望みに応じて、ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールを、関連するセマンティックアイテムの値が値を変化させる時またはその値が確認された時のいずれかにトリガすることができる。
【００５９】
コントロール実行アルゴリズム
クライアントサイドスクリプトまたはクライアントサイドモジュール（本明細書では「ＲｕｎＳｐｅｅｃｈ」と称する）が、図６のコントロールに関してクライアントデバイスに提供される。このスクリプトの目的は、ロジックを介してダイアログフローを実行するためであり、このロジックは、スクリプトがクライアントデバイス３０で実行される時、すなわち、コントロールに関係するマークアップがクライアントに含まれる値に起因してクライアントでの実行のためにアクティブ化される時に、スクリプトで指定される。このスクリプトは、ページ要求の間での複数のダイアログターンを可能にし、したがって、テレフォニブラウザ２１６を介するなど、ボイスのみダイアログのコントロールに特に役立つ。クライアントサイドスクリプトＲｕｎＳｐｅｅｃｈは、完成したフォームがサブミットされるか、新しいページが他の形でクライアントデバイス３０から要求されるまで、クライアントデバイス３０上でループの形で実行される。
【００６０】
一般に、一実施形態で、このアルゴリズムは、音声を出力し、ユーザ入力を認識することによって、ダイアログターンを生成する。このアルゴリズムの全体的なロジックは、ボイスのみシナリオについて、次の通りである（他の形で上で述べられていないプロパティまたはパラメータについては、2004年6月17日公開の米国公開特許出願第２００４／０１１３９０８号「ウェブ可動認識及び／または可聴プロンプトのためのウェブサーバ制御」を参照されたい）。
【００６１】
１．音声インデックス順で、第１のアクティブな（下で定義する）ＱＡコントロール、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロール、またはＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールを見つける。  
２．アクティブコントロールがない場合には、ページを提出する。  
３．そうでない場合には、コントロールを実行する。
【００６２】
ＱＡは、次の場合に限ってアクティブと考えられる。  
１．ＱＡのｃｌｉｅｎｔＡｃｔｉｖａｔｉｏｎＦｕｎｃｔｉｏｎが、存在しないかｔｒｕｅを返すかのいずれかであり、かつ、
２．Ａｎｓｗｅｒｓプロパティコレクションが空でない場合に、Ａｎｓｗｅｒｓのセットによってポイントされるすべてのセマンティックアイテムの状態（Ｓｔａｔｅ）が空（Ｅｍｐｔｙ）であり、または、
３．Ａｎｓｗｅｒｓプロパティコレクションが空である場合に、Ｃｏｎｆｉｒｍアレイ内の少なくとも１つのセマンティックアイテムの状態（Ｓｔａｔｅ）が要確認（ＮｅｅｄｓＣｏｎｆｉｒｍａｔｉｏｎ）である。
【００６３】
しかし、ＱＡのＰｌａｙＯｎｃｅが真（ｔｒｕｅ）であり、そのＰｒｏｍｐｔが成功して実行された（ＯｎＣｏｍｐｌｅｔｅに達した）場合は、そのＱＡは、アクティブ化の候補ではない。
【００６４】
ＱＡは、次のように実行される。  
１．これが、前のアクティブコントロールと異なるコントロールである場合には、プロンプトＣｏｕｎｔ値をリセットする。  
２．Ｐｒｏｍｐｔカウント値を増分する。  
３．ＰｒｏｍｐｔＳｅｌｅｃｔＦｕｎｃｔｉｏｎが指定されている場合には、その関数を呼び出し、返されたストリングをＰｒｏｍｐｔのｉｎｌｉｎｅＰｒｏｍｐｔにセットする。  
４．Ｒｅｃｏオブジェクトが存在する場合には、それを開始する。このＲｅｃｏは、既にアクティブコマンド文法を含んでいなければならない。
【００６５】
バリデータ（ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒまたはＣｕｓｔｏｍＶａｌｉｄａｔｏｒのいずれか）は、次の場合にアクティブである。  
１．バリデートするセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅ）が、このバリデータによって妥当性検査されておらず、その値が変化している。
【００６６】
比較バリデータ（ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒ）は、次のように実行される。 
１．バリデータのオペレータ（Ｏｐｅｒａｔｏｒ）に従って、比較するセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＣｏｍｐａｒｅ）または比較値（ＶａｌｕｅＴｏＣｏｍｐａｒｅ）の値とバリデートするセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅ）の値とを比較する。  
２．このテストがｆａｌｓｅを返す場合には、バリデートするセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅ）のテキストフィールドを空にし、プロンプトを再生する。  
３．このテストがｔｒｕｅを返す場合には、このバリデータによって妥当性検査されたものとしてバリデートするセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅ）をマークする。
【００６７】
カスタムバリデータ（ＣｕｓｔｏｍＶａｌｉｄａｔｏｒ）は、次のように実行される。
１．バリデートするセマンティックアイテム（ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅ）の値を用いてクライアントバリデート機能（ＣｌｉｅｎｔＶａｌｉｄａｔｉｏｎＦｕｎｃｔｉｏｎ）を呼び出す。  
２．この関数がｆａｌｓｅを返す場合には、セマンティックアイテムをクリアし、プロンプトを再生する。そうでない場合には、このバリデータによって妥当性検査される。
【００６８】
コマンド（Ｃｏｍｍａｎｄ）は、次の場合に限ってアクティブと考えられる。
１．それがＳｃｏｐｅ内にあり、かつ、  
２．スコープツリー内でより下に同一Ｔｙｐｅの別のＣｏｍｍａｎｄがない。
【００６９】
マルチモーダルの場合に、このロジックは、次のアルゴリズムに単純化される。  
１．ユーザがコントロールをタップするなどの、トリガするイベントを待つ。  
２．期待される回答を収集する。
３．入力を聴く。
４．結果をセマンティックアイテムに結びつける。結果がない場合には、イベントを送出する。
５．１に戻る。
【００７０】
マルチモーダル環境では、ユーザが結果のビジュアルプレゼンテーションに関連するテキストボックスまたは他の入力フィールドを訂正する場合に、このシステムが、値が確認されたことを示すために、関連するセマンティックアイテムを更新できることに留意されたい。
【００７１】
さらなる実施形態では、図６に示されているように、アプリケーション作成者がテレフォニトランザクションを処理する音声アプリケーションを作成することを可能にする呼び出し（ｃａｌｌ）コントロール４０７、ならびに共通の音声シナリオを１つのコントロールにラップする手段を提供するアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）コントロール４３０が設けられる。ｃａｌｌコントロール４０７およびａｐｐｌｉｃａｔｉｏｎコントロール４３０は、本発明の実施に必要ではなく、単に完全を期して言及されたものである。このそれぞれのさらなる議論は、2004年6月17日公開の米国公開特許出願第２００４／０１１３９０８号「ウェブ可動認識及び／または可聴プロンプトのためのウェブサーバ制御」及び2004年11月18日公開の米国公開特許出願第２００４／０２３０６３７Ａ１号「音声対応認識のためのアプリケーション制御」で提供される。
【００７２】
ユーザ対話データの記録
例として前述の構造を使用することによって、アプリケーション開発者は、音声対応アプリケーションを開発することができる。しかし、本明細書で説明する諸態様は、開発者がユーザ対話データを記録しログすることを可能にする。
【００７３】
それでも、本明細書で説明する概念は、ダイアログモデルを提供する、上で説明したダイアログオーサリング構造に限定されるのではなく、ミドルウェア、ＡＰＩ（アプリケーションプログラムインターフェース）または類似物として実装されるものなどであるがこれらに限定はされないダイアログモデルを生成する、下で説明する情報の一部またはすべてを記録するように構成された任意のオーサリングツールに適用できることを理解されたい。さらに、テレフォニアプリケーションなどの音声対応アプリケーションの機能的性質およびそのボイスユーザインターフェースの詳細は、ドメインおよびアプリケーションタイプにまたがって大きく異なる可能性があり、したがって、通常可能にされる任意の自動化ロギングは、ヒューリスティックに過ぎず、決定的ではない。この理由から、これの実装は、変更不能なプロパティではなく、オーバーライド可能なデフォルトとして自動化ログイベントプロパティを実装する可能性が高い。それでも、豊富な情報のロギングを単純化し、容易にすることは、手動オーサリングおよびプログラム的オーサリングに頼るシステムに対する大きい進歩である。
【００７４】
戻って図４を参照すると、ダイアログコントロール２１１に従って音声対応アプリケーションを実行するウェブサーバ２０２は、モバイルデバイス３０を介するアクセスまたは電話機８０を介するアクセスなどであるがこれらに限定されない任意のタイプのユーザのためにアプリケーションが実行される時に、ストア２１７にユーザ対話ログデータを記録する。
【００７５】
アプリケーションは、一般にしかしそれほど排他的にではなく一連の階層コントロールのセットとして定義され、本明細書で通常は必要に応じてＣｏｍｍａｎｄコントロール４０４、Ａｐｐｌｉｃａｔｉｏｎコントロール４３０、Ｃａｌｌコントロール４０７、ならびにバリデータ４０６および４０８と共にＱＡコントロール４０２によって例示される階層コントロールのセットとして定義または記述される。この階層は、完了されなければならない全体的タスクならびにその全体的タスクを完了するためのその全体的タスクのサブタスクを定義する。この階層内のレベルの個数は、アプリケーションの複雑さに依存する。たとえば、アプリケーションを、全体的に航空便予約に向ける（すなわち最上位タスク）ことができ、２つの主要なサブタスクは、出発情報および到着情報の入手に向けられる。同様に、さらなるサブタスクを、具体的には、出発／到着空港情報、出発／到着時刻などを入手するサブタスクを、出発情報の入手および到着情報の入手という主要なサブタスクのそれぞれについて定義することができる。これらのサブタスクは、それを含むタスク内のシーケンス内に現れるものとすることができる。
【００７６】
一般に、２タイプのデータすなわち、Ｔａｓｋ／ＤｉａｌｏｇデータおよびＴｕｒｎデータが記録される。Ｔａｓｋ／Ｄｉａｌｏｇデータから始めると、ログ内で表されるこのデータは、タスクおよびサブタスクに関するアプリケーションの階層構造またはシーケンシャル構造を取り込まなければならない。図７に、アプリケーションを作成する方法５００を示す。ダイアログオーサリングツールは、ステップ５０２で、ネストされたＴａｓｋ単位またはシーケンシャルＴａｓｋ単位に関してダイアログのオーサリングまたは定義を可能にし、その結果、開発者が音声対応アプリケーションを記述する時に、その作成者は、通常、その音声対応アプリケーションをモジュラの形で記述するようになる。すなわち、作成者は、個々のＴｕｒｎを特定のＴａｓｋを達成するセットにグループ化し、個々のタスクをより上位のＴａｓｋを達成するセットにグループ化することを奨励される。Ｔａｓｋ構造および個々のＴａｓｋに出入りするフローは、設計時に既知なので、ステップ５０４で、Ｔａｓｋに入ることまたはＴａｓｋから出ることのロギング（たとえば、ＴａｓｋＳｔａｒｔイベントおよびＴａｓｋＣｏｍｐｌｅｔｅイベントを介する）ならびにアプリケーションによって使用される入力フィールドに関してユーザから入手されるＴｕｒｎデータおよび値のロギング（本明細書では「セマンティックアイテム(semantic item)」として例示される）を可能にして、Ｔａｓｋ構造のシーケンスおよび／または階層の自動化ロギングを提供する。これは、ダイアログフロー、入手された値、およびＴａｓｋ構造を、イベントログから明示的に回復でき、構築できることを意味する。ステップ５０２および５０４が、これらのステップの特徴の一部またはすべてを異なる順序でまたは同時に実行できるという点で、例示のみを目的として別々に示されていることに留意されたい。
【００７７】
このデータは、任意の所与のタスクまたはサブタスクの完了の成功、失敗、または他（たとえば未知）という状況をも定量化する。さらに、Ｔａｓｋ／Ｄｉａｌｏｇデータは、タスクが不成功もしくは失敗の場合の理由、またはその完了状況が既知でない理由、または適用可能な場合に複数の理由が成功について可能である場合に成功の理由を含む。追加データには、ユーザが応答を供給しなかった場合または音声リコグナイザが発話を認識できなかった場合を示す進行状況データを含めることができる。プロンプトまたはユーザ応答に基づくかこれに関連する値に関してアプリケーションによって使用される入力フィールド値またはストレージロケーションのリスト、あるいは変化したその状況をも、記録することができる。
【００７８】
図８に、音声対応アプリケーションを実行する方法５２０を示す。方法５２０は、ステップ５２２で、１つまたは複数のＴｕｒｎを有するＴａｓｋに関して定義された音声対応アプリケーションを実行することを含む。ステップ５２４は、タスク（Ｔａｓｋ）、ターン（Ｔｕｒｎ）、およびセマンティックアイテムに関係する情報を記録することを含む。ステップ５２２および５２４は、これらのステップの特徴の一部またはすべてを異なる順序でまたは同時に実行でき、例示のみのために別々に示されていることに留意されたい。
【００７９】
一実施形態で、タスク／ダイアログ（Ｔａｓｋ／Ｄｉａｌｏｇ）データは、次の情報の一部またはすべてを含む。
【００８０】
Ｔａｓｋ／Ｄｉａｌｏｇデータ
ｎａｍｅ：タスク／ダイアログの作成者定義のストリング識別子、たとえば「ｇｅｔＣｒｅｄｉｔＣａｒｄＩｎｆｏ」、「ＣｏｎｆｉｒｍＴｒａｖｅｌ」など。作成者が設計時に名前を供給しない場合には、たとえばＤｉａｌｏｇ１、Ｄｉａｌｏｇ２、ＤｉａｌｏｇＮ、…など、デフォルト名が与えられる。
ｐａｒｅｎｔ：それが含まれるダイアログの名前（ログからダイアログ階層を再構成するために）。  
ＴａｓｋＳｔａｒｔ：Ｔａｓｋ／Ｄｉａｌｏｇに最初に入った時のタイムスタンプ。 
ＴａｓｋＣｏｍｐｌｅｔｅ：Ｔａｓｋ／Ｄｉａｌｏｇから出た時のタイムスタンプ。このイベントは、デフォルト値を有するアプリケーションが閉じられる時のすべての開かれているダイアログについて、ボトムアップで必ず生成されなければならない（すなわち、ログに「オープンエンド」のダイアログはない）。  
ｓｔａｔｕｓ：タスク／ダイアログの完了状況であり、作成者によってセット可能であり、ダイアログの実行に基づいて自動的に推論され、あるいは、作成者定義の条件に基づいて半自動的にセットされる。一実施形態で、デフォルト値状況を「ＵＮＳＥＴ」とすることができ、後続の値は、次のうちの１つとすることができる。  
ＳＵＣＣＥＳＳ
ＦＡＩＬＵＲＥ
ＵＮＫＮＯＷＮ
【００８１】
自動タスク完了状況
ある種の場合に、上で示したように、状況を、タスク出口の性質から、その状況が成功、失敗、または未知のうちの１つであったかどうかを穏当な確かさで推論することができる。たとえば、エラーまたは例外の結果として終了するタスクを、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。同様に、キャンセルされたタスク（たとえば、Ｃａｎｃｅｌ（）のメソッドがタスクオブジェクトに対してコールされた場合）を、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。同様に、ある種の「ストライクアウト」（たとえば、下で述べるＭａｘＳｉｌｅｎｃｅｓまたはＭａｘＮｏＲｅｃｏ）カウントに達した結果として終了するタスクを、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。
【００８２】
対照的に、自然に終了する（すなわち、キャンセルされていない）タスクで、そのタスクで含まれるＴｕｒｎまたは設計時にそのタスクに属するものとして指定されたＴｕｒｎのすべてのセマンティックアイテム（すなわち、アプリケーションの入力フィールド）が根拠のある（ユーザ入力またはそれから導出された）値を有して終了したものは、Ｓｕｃｃｅｓｓの完了状況と共に自動的にロギングされる。
【００８３】
半自動化されたタスク完了
タスク状況ロギングの部分的自動化も、有用である。任意の所与のタスクについて、作成者は、満足された場合に出口の任意の点でのタスクの状況を決定する、タスクの成功または失敗に関する条件のセットをステップ５０２で指定しまたは定義することができる。これらの条件は、プログラム的（たとえば、ｆｏｏ＝＝’ｂａｒ’）とすることができ、あるいは、より役立つことに、作成者がタスクごとに１つまたは複数のセマンティックアイテム（たとえば、ｄｅｐａｒｔｕｒｅＣｉｔｙおよびａｒｒｉｖａｌＣｉｔｙについて提供される値）だけを指定する必要があるようになるように条件を単純化することができ、本システムは、これらのセマンティックアイテムが確認された値を有する時にＳｕｃｃｅｓｓを自動的にロギングし、オプションで、これらのセマンティックアイテムが確認された値を有しない時にＦａｉｌｕｒｅを自動的にロギングする。
【００８４】
この態様は、タスク状況ロギングがタスクからのすべての出口点でプログラム的にコーディングされる必要がないことを意味するので、有用な、時間を節約する機構である。その代わりに、条件は、エンドユーザがタスクを終了する時に、必ず自動的に評価され、状況が、判定され、余分な開発者コードなしでロギングされる。
【００８５】
ｒｅａｓｏｎ：作成者によってセットできる、ダイアログの完了の理由。たとえば、
Ｃｏｍｍａｎｄ  −  ダイアログの異なる部分に変更するためにユーザによって話されたコマンドおよびそのコマンドの性質（たとえば、「Ｃａｎｃｅｌ」、「Ｏｐｅｒａｔｏｒ」、「Ｍａｉｎ  Ｍｅｎｕ」など。  
ｕｓｅｒＨａｎｇｕｐ  −  ユーザが、ハングアップするか、他の形で放棄するかあきらめた。  
ａｐｐｌｉｃａｔｉｏｎＥｒｒｏｒ  −  アプリケーションエラーが発生した。  
ｍａｘＮｏＲｅｃｏｓ  −  認識に達することなく発話の最大回数に達した。  
ｍａｘＳｉｌｅｎｃｅｓ  −  無音ユーザ応答の最大回数に達した。
【００８６】
ＳｅｍａｎｔｉｃＵｐｄａｔｅ：
ｉｔｅｍｓ：新しい値および対応する状況を含む、その値／状況が変更されたすべてのセマンティックアイテムのリスト。通常、このデータは、各ダイアログターン（アプリケーションによるプロンプト／ユーザによる応答または応答の欠如）に関して、１つまたは複数のセマンティックアイテム値および／または状況が変化するという点で、下で述べるＴｕｒｎデータに相関される。しかし、いくつかの場合に、アプリケーションは、それ自体でセマンティックアイテムを変更することができる。たとえば、アプリケーションが、クレジットカード番号などの値を妥当性検査することができない場合に、そのアプリケーションは、必ずしもダイアログターンに基づくのではなく、それ自体でその値をクリアすることができる。それでも、そのような変更は記録されるはずである。
【００８７】
Ｔｕｒｎデータは、アプリケーションとの直接対話を含み、アプリケーションによって提供されるプロンプト（応答が期待されない場合）またはユーザ応答もしくはユーザ応答の欠如に相関されるアプリケーションプロンプト、言い換えると、プロンプト／応答交換、または必ずしもプロンプトに応答するのではなくユーザによって提供されるコマンド、または少なくともプロンプトに対する応答であると期待されない応答に基づいて編成される。したがって、記録され得るデータの３つの領域は、アプリケーションによって提供されるプロンプト、ユーザによって供給される応答（期待される応答であれ期待されない応答であれ）、およびシステムによって決定される認識結果に関係する情報を含む。一実施形態で、Ｔｕｒｎデータは、次の情報の一部またはすべてを含む。
【００８８】
Ｔｕｒｎデータ
ｃｏｎｆｉｇ
ｎａｍｅ：作成者定義のストリング識別子。作成者が設計時に名前を供給しない場合には、デフォルト名を与えることができる。しかし、同一のＤｉａｌｏｇ／Ｔａｓｋ内の異なるターンの間で明瞭かつ一貫して区別する必要がある。可能な技法は、プロンプトの名前およびタイプに基づくことである。
【００８９】
ｔｙｐｅ：特定のＴｕｒｎの目的の指定を、それに関連するセマンティックアイテムの性質から推論することができる。上の前述の説明の場合に、セマンティックアイテムは、Ａｎｓｗｅｒｓ、ＥｘｔｒａＡｎｓｗｅｒｓ、およびＣｏｎｆｉｒｍｓの概念を介してＴｕｒｎに関連する。
【００９０】
Ｔｕｒｎの目的の例には、次が含まれる。  
新しい情報を求める（ＴｕｒｎはＡｎｓｗｅｒｓを使用可能にする）  
関連情報を確認する（受け入れ／拒否、ＴｕｒｎはＣｏｎｆｉｒｍｓを使用可能にする）
情報ステートメントを与える（ＴｕｒｎはＡｎｓｗｅｒｓまたはＣｏｎｆｉｒｍｓを保持しない）。
【００９１】
ｐａｒｅｎｔ：含むＤｉａｌｏｇ／Ｔａｓｋの名前（ログからダイアログ階層を再構成するため）。
ｌａｎｇｕａｇｅ：使用される言語。
ｓｐｅｅｃｈ  ｇｒａｍｍａｒｓ：どの音声認識文法が使用されているかに関する情報。
ＤＭＴＦ  ｇｒａｍｍａｒｓ：どのＤＴＭＦ認識文法が使用されているかに関する情報。
ｔｈｒｅｓｈｏｌｄｓ：値の拒絶および／または値の確認に関する信頼性閾値。
ｔｉｍｅｏｕｔｓ：プロンプトに続く最初の無音について許容される時間期間、応答の終りを判定する終了無音、およびバブルと考えられる期間。
ｐｒｏｍｐｔ
ｎａｍｅ：オプション。ターンデータ名を使用できるので必要ではない場合がある。
ｔｙｐｅ：ダイアログモデルは、そのどれであってもアプリケーションによって選択することができ、それを使用することによってシステムが試みているものの記録を達成することを可能にする、複数の事前定義のプロンプトタイプすなわちＴｕｒｎの目的を含むことができる。
【００９２】
プロンプトタイプの例には、次が含まれる。  
ＭａｉｎＰｒｏｍｐｔ  −  質問をすること（またはステートメントを与えること）
ＨｅｌｐＰｒｏｍｐｔ  −  ヘルプを提供すること
ＲｅｐｅａｔＰｒｏｍｐｔ  −  情報内容を繰り返すこと
ＮｏＲｅｃｏｇｎｉｔｉｏｎＰｒｏｍｐｔ  −  「認識なし」に応答すること
ＳｉｌｅｎｃｅＰｒｏｍｐｔ  −  無音に応答すること
ＥｓｃａｌａｔｅｄＮｏＲｅｃｏｇｎｉｔｉｏｎＰｒｏｍｐｔ  −  複数の試行の後に「認識なし」に応答すること
ＥｓｃａｌａｔｅｄＳｉｌｅｎｃｅＰｒｏｍｐｔ  −  複数の試行の後に無音に応答すること
これらのタイプ（ｔｙｐｅ）は、事前に定義されており、任意の時に選択して使用可能なので、ｔｙｐｅによって自動的にロギングすることができ、これによって、Ｔｕｒｎの目的を達成するための所与のプロンプトの目的という概念を用いてログデータを自動的に豊かにする。
【００９３】
したがって、Ｔｕｒｎタイプと組み合わされたプロンプトタイプは、すべてがダイアログオーサリングモデルのプログラミングプリミティブであり、したがってアプリケーションが遭遇すると自動的にロギングされる。これにより、ログ内の任意の点においてもシステムの目的を表現豊かに参照することができる。
【００９４】
ｓｅｍａｎｔｉｃ  ｉｔｅｍｓ：それに関するプロンプトを出される（質問／確認サイクルをリンクすることなどに使用される）セマンティックアイテム。
【００９５】
ダイアログモデルは、ダイアログフローに関してオーサリングを単純化するために、それぞれが値および状況を含むセマンティックアイテムという概念を使用する。すべてのセマンティックアイテムの変化する値および状況を自動的にロギングし、それをタスクおよびユーザ／システム移動情報と組み合わせることによって、ログが、さらに豊かにされる。
【００９６】
Ａｎｓｗｅｒｓ／ＥｘｔｒａＡｎｓｗｅｒｓ／Ｃｏｎｆｉｒｍｓモデルは、セマンティックアイテムをＴｕｒｎに、したがってＴａｓｋにリンクする。したがって、どのセマンティックアイテムがどのシステム移動およびユーザ移動に関係し、どのセマンティックアイテムがどのＴａｓｋに寄与するかがわかる（自動的にロギングすることができる）。
プロンプトのテキスト内容：たとえば「ｗｅｌｃｏｍｅ」。
ｂａｒｇｅｉｎ：オン／オフ／プロンプト中時間。
Ｕｓｅｒ  Ｐｅｒｃｅｉｖｅｄ  Ｌａｔｅｎｃｙ：ユーザの応答と次のプロンプトの再生との間の時間期間。システムが重い負荷の下にある時には、この時間期間がより長くなる場合があり、これは、アプリケーションが応答していないとユーザに思わせる可能性があるという点で、ユーザを混乱させる可能性がある。
ＴＴＳ：Ｔｒｕｅ／Ｆａｌｓｅ  −  テキスト−音声がプロンプトを生成するのに使用されていたかどうか。
プロンプト完了時間：プロンプトが完成された／中断された時間。
プロンプトｗａｖｅファイル：提供された実際のプロンプト。
ユーザ入力：
ｍｏｄｅ：ユーザがＤＴＭＦ／音声のどちらを提供しているか。
ｔｙｐｅ：ユーザがＣｏｍｍａｎｄを提供しているかどうか、および、そうである場合に、どのタイプ（たとえば、Ｈｅｌｐ／Ｒｅｐｅａｔ／など）か、または、ユーザがＲｅｓｐｏｎｓｅを提供しているかどうか、および、そうである場合に、どのタイプ（たとえば、Ａｎｓｗｅｒ／Ｃｏｎｆｉｒｍ／Ｄｅｎｙ）か。
【００９７】
ダイアログモデルは、アプリケーションの文法の機能を、応答を提供する際のユーザの目的を示すユーザ応答の異なるタイプすなわち、Ａｎｓｗｅｒ、Ａｃｃｅｐｔ、Ｄｅｎｙなどに分類する。これらのタイプは、ユーザが何を達成することを試みているとシステムが考えているかのインジケータとして直接にロギングすることができる。異なる応答タイプの例は、次の通りである。  
Ａｎｓｗｅｒ  −  ユーザが、値を要求する質問に対する回答を提供した。
ＥｘｔｒａＡｎｓｗｅｒ  −  ユーザが、質問の焦点を越える回答を提供した。
Ａｃｃｅｐｔ  −  ユーザが、情報の１つを確認した。
Ｄｅｎｙ  −  ユーザが、情報の１つに異議を唱えた。
Ｈｅｌｐ  Ｃｏｍｍａｎｄ  −  ユーザが、ヘルプを求めた。
Ｒｅｐｅａｔ  Ｃｏｍｍａｎｄ  −  ユーザが、情報の繰り返しを要求した。
Ｏｔｈｅｒ  Ｃｏｍｍａｎｄ  −  ユーザが、ある他の形のコマンドを発行した（明示的にタイプを指定されないが、我々は、それが上のタイプのどれでもないことを知っている）。
Ｓｉｌｅｎｃｅ  −  ユーザが、何も言わなかった（これは、時々、ある形の「暗黙の受け入れ」として使用される）。
【００９８】
これらのタイプは、特定の文法に関連するので、ユーザが対応する文法に一致する何かを言う時に、必ず、これらを自動的にロギングすることができる。多くのシステムは、単一のダイアログターンに複数のタイプを含めることを許容し、たとえば、複数のアイテムを受け入れること、または単一のターンで１つのアイテムに回答し、別のアイテムを受け入れることを許容する。  
Ｓｉｌｅｎｃｅ：無音が検出される場合に、ＭａｘＳｉｌｅｎｃｅｓに対する相対的なその個数またはカウント。
ＮｏＲｅｃｏ：認識が発話について検出されない場合に、ＭａｘＮｏＲｅｃｏｓに対する相対的なその個数またはカウント。  
Ｅｒｒｏｒ：エラーが発声した場合に、それがアプリケーションまたはプラットフォームによって送出されたかどうか。
ｒｅｓｕｌｔ：
Ｒｅｃｏｇｎｉｔｉｏｎ  ｒｅｓｕｌｔ：システムによって返された認識結果。一般に、認識結果は、解釈された発話のセマンティックマークアップ言語（ＳＭＬ）タグを含む。さらに、Ｎ−Ｂｅｓｔ代替解釈を提供することができ、適当な場合にオーディオ記録結果を提供することができる。
【００９９】
さらに、解釈ごとに、
ＳＭＬタグなしの発話テキスト（音声が提供される場合）またはキー押下げ（ＤＴＭＦが提供される場合）。
ｃｏｎｆｉｄｅｎｃｅ：解釈の信頼性レベル。
ｓｅｍａｎｔｉｃ  ｍａｐｐｉｎｇｓ：ＳＭＬ結果の諸部分とセマンティックアイテムとの間のリンク。言い換えると、ＳＭＬ結果からのどの値がどのセマンティックアイテムに置かれるか。
ｇｒａｍｍａｒ  ｒｕｌｅ  ｍａｔｃｈｅｄ：文法のどのルールがユーザ入力と一致したか。
ｃｏｎｆｉｄｅｎｃｅ：全体としての発話の信頼性。
ｂａｒｇｅｉｎ：ユーザによる会話への割込みのタイミングまたはＮＵＬＬ（会話への割込みが存在しない場合）。
認識ｗａｖｅファイル：実際に記録されたユーザ入力またはそれへのポインタ。
【０１００】
要約すると、ロギングされるユーザ対話データは、ダイアログを、関心を持たれているあるフィールド（たとえば、フォームフィールドまたはスロット値）を操作するタスクの階層構造またはシーケンシャル構造とみなすことを可能にし、タスク内の各ダイアログターンは、フォームフィールドに関するシステム目的（ダイアログ移動）（たとえば、値に関する質問、値の確認、値の繰り返しなど）と、音声リコグナイザがユーザ目的と考えているもの（たとえば、値の供給、値の拒否、ヘルプの要求など）との両方をロギングする。
【０１０１】
実用的な利益が、この構造を用いて実現される。具体的に言うと、システム性能の分析は、成功または失敗のいずれかのタスク完了が、一般に明示的であり、したがって、トランザクション的成功レート報告が、非常に単純化され、タスクを完了するのに要するダイアログステップの性質が、よりよく理解される（各ステップの背後にある目的がオーサリング時に既知なので）という点で、改善される。
【０１０２】
この形のデータロギングの実装は、これがダイアログオーサリングツールに組み込まれる形に起因して、簡単である。この計測の高水準の性質は、さまざまなアプリケーションタイプに共通であり、ロギングの実際の詳細は、概念的に及びロギングプリミティブに関しての両方でこれがオーサリングツールに統合されることによって、オーサリング時に容易にされる。したがって、アプリケーション作成者は、タスク／サブタスクモデルを使用してアプリケーションを構造化し、タスクから出るどの遷移が成功の完了を示すかを示すことを奨励され、システム／ユーザ目的ロギングがダイアログターンオーサリングモデルに組み込まれるので、システム／ユーザ目的ロギングを明示的に計測する必要がなくなる。
【０１０３】
ダイアログ分析
下の説明は、全般的に、タスクレベルでの分析に言及するが、すべての原理が、タスクレベルとセッションレベル（すなわち、より下のレベルのタスク構造化が未知であるか無視される、単一タスクとしてのセッションの分析）との両方に適用される。
【０１０４】
図９を参照すると、ダイアログ分析モジュール６００は、上で説明したものなどの入力のロギングされたアプリケーションデータを受け取り、その分析を実行する。一般に、説明のために、ダイアログ分析モジュール６００には、劣悪タスク性能診断モジュール６０２、混乱させるプロンプト分析モジュール６０４、およびダイアログ問題の源を識別するモジュール６０６を含めることができる。これらは、有利に組合せで使用することができるが、各プロセスまたは各モジュールは、他のモジュールと独立に使用することもできる。下の測定の値を示すレポートまたは他の適切な出力を、提供することができる。適用可能な場合には、測定値をタスク毎に提供することができる。
【０１０５】
１．劣悪タスク性能の診断
劣悪タスク性能診断モジュール６０２および図１０のそれに対応するプロセス６０３は、分析されチューニングされなければならないアプリケーションの劣悪に動作する部分を明らかにするか識別し、かつ／または劣悪な性能の理由を示唆する。劣悪タスク性能診断モジュール６０２および図１０のそれに対応するプロセス６０３は、ステップ６０５で、ロギングされたデータから各セッションまたは各タスクを分析し（タスクは、ダイアログターン、サブタスク、またはその両方を含むダイアログの構造化されたコンポーネントである）、ステップ６０７で「タスクユーザビリティ」の測定値を推論する。この測定値、具体的には下で説明する測定値は、タスクを達成するのに使用されるダイアログ移動シーケンスのパターン（たとえばＴｕｒｎタイプまたはＲｅｓｐｏｎｓｅタイプによって示される）に基づく、ユーザ体験の成功のインジケータである。
【０１０６】
プロセス６０３は、独立にまたはタスク成功／失敗の明示的インジケータおよび／もしくはロギングされたデータ内に存在する他のメトリックと組み合わせてのいずれかで使用することができる。これらのインジケータは、タスクの状況をその完了時にどのようにロギングしなければならないか（通常は値Ｓｕｃｃｅｓｓ／Ｆａｉｌｕｒｅ／Ｕｎｋｎｏｗｎを用いて）を決定する明示的アプリケーション計測の結果であり、全体的なタスク完了率に基づくレポートを生成するのに使用される。他の明示的インジケータは、生のターンカウントおよび持続時間を含む。単独で使用される場合に、明示的インジケータは、タスクのユーザエクスペリエンスへの洞察をほとんど与えないが、本明細書で説明する分析は、より深い洞察をもたらす。この明示的インジケータは、タスクの効率およびユーザビリティの測定値を提供するので、すべてのタスク（低い完了率を有するタスクから高い完了率を有するタスクまで）にまたがってタスク性能を査定するのに貴重である。この明示的インジケータは、全体的なタスク性能の可能性の高い理由を予測するのにおよび／またはそれに基づいて性能が高められ、ユーザ体験が最適化されるメトリックスとして使用される。
【０１０７】
次のメトリックのうちの１つ、いくつか、またはすべてを、分析に使用されるデータセットにまたがる所与のタスクのすべてのインスタンスから計算することができる。
【０１０８】
確認スコア
モジュール６１０は、ステップ６１１で受け取られた応答の要求に関するターンに対する、受け取られた応答の確認に関するターンに関する表示を入手する。例示的実施形態では、モジュール６１０は、確認スコアを計算し、この確認スコアは、「Ａｓｋ」ターンに対する「Ｃｏｎｆｉｒｍ」ターンを示す値である。たとえば、比を、「Ｃｏｎｆｉｒｍ」ターンの個数を合計し、これを「Ａｓｋ」ターンの個数で割ることによって計算することができる。この形で、「１」の確認率は、タスク内のＡｓｋおよびＣｏｎｆｉｒｍの等しい個数を示す。一般に、より低い比（この例を使用して）は、より効率的なダイアログ対話を示す（いくつかのアプリケーションは、ビジネス上の理由から、すべてのＡｓｋの明示的検証を必要とする場合があるが）。高い確認レベル（すなわち、望まれるものより多くの「Ｃｏｎｆｉｒｍ」が発生すること）の理由は、劣悪に設計されたダイアログフロー、準最適信頼性閾値、および／または文法の問題を示す場合がある。当業者が了解する通り、「Ａｓｋ」に対して「Ｃｏｎｆｉｒｍ」を比較する異なる尺度を使用することができる。しかし、正規化（たとえば、スコアを判定する比の使用）が、一般に有利である。というのは、これが、プロンプトおよび回答の個数がタスクごとに異なる可能性があるという事実にかかわりなく、別のタスクに対して相対的にあるタスクを比較することを可能にするからである。
【０１０９】
セマンティックアイテムターンスコア
モジュール６１２は、ステップ６１３において受け取られた応答をデータにまたがって要求するタスクインスタンスに対する、受け取られた応答を要求することに関するターンに関する表示を得る。図示の実施形態では、モジュール６１２は、セマンティックアイテムまたは応答ターンスコアを計算し、このセマンティックアイテムまたは応答ターンスコアは、セマンティックアイテム（ＳＩ）ごとに、そのＳＩへのＡｓｋターンの回数を合計し、これを、セマンティックアイテムの要求データにまたがって現れるタスクインスタンスの個数によって割ることによって計算される（本明細書で使用されるセマンティックレコードは、ユーザによって提供された応答を記録する）。セマンティックアイテムを基礎としてこのスコアを計算することによって、このスコアは、特定のセマンティックアイテムの値を得ることの難しさへの洞察を与え、高い比は、アイテムについて尋ねる複数の試みが行われたことを示し、低い値は、少数の試みを示す。
【０１１０】
１つの例によると、このプロセスが、ユーザが多数の数字を一度に提供しなければならないので、失敗なしにクレジットカード番号を得ることが難しいということを特定する。たとえば、アプリケーションに応じて、そのようなプロンプトが、ダイアログ内の多数の位置で発生するが、同一のセマンティックアイテムが使用される場合がある。そうである場合には、解決策は、クレジットカード番号のより小さいセットについてユーザに尋ねることとすることができる。
【０１１１】
望まれる場合に、複数のＳＩ（ユーザからの応答）を有するタスクについて、単一の代表的スコアを、すべての個々のＳＩターンスコアの平均値として計算できることに留意されたい。
【０１１２】
セマンティックアイテム妥当性スコア
モジュール６１４は、ステップ６１５で受け取られた応答に基づいて割り当てられる値に対する、受け取られた応答を確認することに関するターンに関する表示を入手する。図示の実施形態では、モジュール６１４は、セマンティックアイテムまたは応答妥当性スコアを計算し、このセマンティックアイテムまたは応答妥当性スコアは、応答ごとまたはセマンティックアイテム（ＳＩ）ごとの基礎で、ＳＩの値が確認された回数を合計し、これを値がそのＳＩに割り当てられた全回数によって割ることによって計算することができる。このスコアは、そのセマンティックアイテムを入手するのに使用されたタスクの効率性への洞察すなわち、そうでなければ高いターンカウントまたはＣｏｎｆｉｒｍａｔｉｏｎスコアによって隠される可能性がある洞察を与える。セマンティックアイテム妥当性スコアの高い値は、高い受け入れ率を表すが、低い値は、高い拒絶率を表す。望まれる場合に、複数のＳＩ（ユーザからの応答）を有するタスクについて、単一の代表的スコアを、すべての個々のＳＩ妥当性スコアの平均値として計算できることに留意されたい。
【０１１３】
ユーザ繰り返し率
モジュール６１６は、ステップ６１７でのユーザ要求に基づいて、ユーザがターンを繰り返すことに関する表示を入手する。図示の実施形態では、モジュール６１６は、ユーザ反復スコアを計算し、このユーザ反復スコアは、ターンへの繰り返される進入の回数（この再進入は無音および無認識ではなくユーザ要求に起因する）を合計し、これをターンの発生の全回数によって割ることによって、ターンごとの基礎で計算される。繰り返すことのユーザ要求は、通常、コマンドＨｅｌｐ、Ｒｅｐｅａｔ、およびＧｏ  Ｂａｃｋを含むが、現在のまたは前の状態への再進入(re-entry)を直接にもたらすすべてのコマンドを含めることができる。高い値は、高いレベルの再進入を示し、これは、その状態から始まるユーザ混乱を暗示するが、低い値は、低いレベルの再進入を示す。
【０１１４】
２．混乱させるプロンプト
モジュール６０４および対応するプロセス６１９（図１１）はアプリケーション内のどのプロンプトが混乱を引き起こしているかの表示を入手するのに使用される。ステップ６２１で、ロギングされたデータを所与のＴｕｒｎのプロンプトについて受け取り、ステップ６２３で、プロンプトの言い回しが明瞭さまたは単純さについてチューニングされなければならないかどうかを判定するために、「混乱レーティング」を計算する。この例では、レーティングが高いほど、プロンプトをチューニングする必要がある可能性が高い。
【０１１５】
例示的な混乱レーティングは、次の事象から計算することができる。  
（ａ）無音カウント：プロンプトに続くユーザ無音（無入力）の回数
（ｂ）ヘルプカウント：支援に関するユーザ要求がプロンプトに続いた回数
（ｃ）繰り返しカウント：ユーザがプロンプトを繰り返すようにシステムに要求した回数
（ｄ）拒絶率：（Ｔｙｐｅ  Ａｓｋのターンについて）セマンティックアイテム値（すなわち、プロンプトに対する認識された応答）が拒絶されたか他の形でキャンセルされた回数。
【０１１６】
これらの個々の合計は、データ内のプロンプトのインスタンスの個数にまたがって合計される。異なる重み付け係数を、コンポーネント（ａ）〜（ｄ）に適用できることに留意されたい。結果のレーティングは、単独で使用することができ、あるいは、応答を理解するためのユーザの時間を反映する、より下のレベルのリコグナイザデータから計算される係数と組み合わせることができる。
【０１１７】
（ｅ）応答待ち時間  たとえば、プロンプトの終りとユーザ応答の初めとの間の平均（または他の測定）待ち時間（これは、人が、混乱させないプロンプトよりも混乱させるプロンプトに遅く応答することを前提とする）。このスコア自体は、プロンプトの混乱レーティングの表示を提供できることに留意されたい。
【０１１８】
３．ダイアログ問題の源の識別
モジュール６０６および対応するプロセス６３１（図１２）は、ユーザにタスクを放棄させる問題の源である可能性が高い状態を見つけるのに使用される。タスク放棄は、認識のタイプに対して相対的に判定される。音声およびＤＴＭＦについて、次のアクションのいずれをも、放棄と考えることができる。  
−ユーザがハングアップする
−現在のタスクをキャンセルするユーザコマンド（たとえば、「Ｃａｎｃｅｌ」）
−エージェントへの転送を要求するユーザコマンド（たとえば、「Ｏｐｅｒａｔｏｒ）
−エージェントへの転送を要求するＤＴＭＦキー押下げ（たとえば、０）
【０１１９】
プロセスまたは方法６３１は、ユーザが少なくとも１回自動化システムとの対話を試みた（すなわち、呼の開始時に放棄アクションを試みなかった）ことが既知であるセッションに適用される。このプロセスは、問題状態をそこから見つけることができる最後の既知の正しい状態を見つけることを試みる。このプロセスは、次の通りである。
【０１２０】
ユーザセッションごとに、ステップ６２９で、ロギングされたデータを受け取り、ステップ６３３に示されるように、タスク構造を平坦化する、すなわち、ダイアログターンおよび／またはタスクエントリおよび／または完了状態を、時間的に順序付けられた状態の１次元リストとして扱う。次に、
ステップ６３５で、放棄の時点を突き止め、
ステップ６３７で、次の状態の１つに遭遇するまで（下記の順序が変更され得ることに留意されたい）ダイアログターンのシーケンスを放棄アクションから遡って辿り(backtrack)、
（ａ）ステップ６３９によって示されるように、状況「Ｓｕｃｃｅｓｓ」を有するタスク完了に遭遇する場合には、その直後のターン状態が、問題の源と考えられ、
（ｂ）ステップ６４１によって示されるように、ユーザが値を受け入れる場合、またはセマンティックアイテム（Ｓｅｍａｎｔｉｃ  Ｉｔｅｍ）がその間に「Ｃｏｎｆｉｒｍｅｄ」の状況を達成したターンに遭遇する場合には、その直後のターン状態が、問題の源と考えられ、
（ｃ）ステップ６４３によって示されるように、ユーザが、値を拒絶し／訂正し、またはセマンティックアイテム（Ｓｅｍａｎｔｉｃ  Ｉｔｅｍ）がその間に「Ｅｍｐｔｙ」の状況をもたらすかその値を変更したターンに遭遇する場合には、問題のＳｅｍａｎｔｉｃ  Ｉｔｅｍがタイプ「Ａｓｋ」のターンのトピックであった最も近い前のターン状態が、問題の源と考えられ、
（ｄ）ステップ６４５によって示されるように、ユーザの「Ｇｏ  Ｂａｃｋ」またはセッション内のユーザのステップの引き返しを実施する他のコマンドに遭遇する場合に、そのＧｏ  Ｂａｃｋコマンド（またはシーケンス内の場合に複数のＧｏ  Ｂａｃｋコマンド）の名前をとり、最初のＧｏ  Ｂａｃｋコマンドの前のターンの最も近いインスタンスを、問題の源と考え、
（ｅ）ステップ６４７によって示されるように、セッションの初めに達した場合には、そのセッション内の最初の情報を要求するターン状態（すなわち、最初のＡｓｋまたはＣｏｍｍａｎｄのイネーブリング）が、問題の源であり、
（ｆ）そうでない場合には、すべての他のターンタイプについて、バックトラッキングを続ける（すなわち、ステップ６３７に戻る）。
【０１２１】
結果を、セッションにまたがって交合し、タスク放棄に寄与する尤度に関して順序付けられた状態のリストとして提示することができる。たとえば、７６回の放棄が発生したユーザのデータにまたがって、４５回が、「ＴｕｒｎＡ」状態に含まれ、１５回が「ＴｕｒｎＢ」状態に含まれ、１４回が、「ＴｕｒｎＣ」状態に含まれ、２回が、「ＴｕｒｎＤ」状態に含まれた。
【０１２２】
本発明を、特定の実施形態を参照して説明したが、当業者は、本発明の趣旨および範囲から逸脱せずに、形態および詳細において変更を行えることを認めるであろう。
【図面の簡単な説明】
【０１２３】
【図１】コンピューティングデバイスオペレーティング環境の第１実施形態を示す平面図である。
【図２】図１のコンピューティングデバイスを示すブロック図である。
【図３】汎用コンピュータを示すブロック図である。
【図４】クライアント／サーバシステムのアーキテクチャを示すブロック図である。
【図５】クライアントサイドマークアップ内で認識および可聴コンピューティングを提供する手法を示すブロック図である。
【図６】コンパニオンコントロールを示すブロック図である。
【図７】音声対応アプリケーションを作成する方法を示す流れ図である。
【図８】音声対応アプリケーションを実行する方法を示す流れ図である。
【図９】ダイアログ分析モジュールを示すブロック図である。
【図１０】劣悪な性能に関してダイアログ分析を実行する方法を示す流れ図である。
【図１１】混乱させるプロンプトに関してダイアログ分析を実行する方法を示す流れ図である。
【図１２】ダイアログ問題の源の識別に関してダイアログ分析を実行する方法を示す流れ図である。
【図１】
2009500721.tif 000003
【図２】
2009500721.tif 000004
【図３】
2009500721.tif 000005
【図４】
2009500721.tif 000006
【図５】
2009500721.tif 000007
【図６】
2009500721.tif 000008
【図７】
2009500721.tif 000009
【図８】
2009500721.tif 000010
【図９】
2009500721.tif 000011
【図１０】
2009500721.tif 000012
【図１１】
2009500721.tif 000013
【図１２】
2009500721.tif 000014