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