JP2009500722A - 音声アプリケーションの測定およびロギング - Google Patents

Abstract

音声対応アプリケーションは、タスクに関して定義される。タスクの完了を示す情報および／またはターンデータに関連する情報は、音声対応アプリケーションが実行される時に、タスクに対して相対的に記録可能である。

Description

下の議論は、単に、全般的背景情報として提供され、請求される主題の範囲を判定する際の助けとして使用されることは意図されていない。

携帯情報端末（ＰＤＡ）、デバイス、および携帯電話機などの小型コンピューティング、デバイスは、人々によって、彼らの毎日の活動でますます高まる頻度で使用されている。現在これらのデバイスを動作させるのに使用されるマイクロプロセッサに使用可能な処理能力の向上に伴って、これらのデバイスの機能性は、高まりつつあり、いくつかの場合に、合併されつつある。たとえば、多数の携帯電話機は、現在、インターネットにアクセスし、ブラウズするのに使用することができ、住所、電話番号、および類似物などの個人情報を記憶するのに使用することができる。

したがって、これらのコンピューティングデバイスが高まる頻度で使用されつつあることを考慮すると、ユーザが情報をこれらのコンピューティングデバイスに入力する簡単なインターフェースを提供する必要がある。残念ながら、これらのデバイスを簡単に持ち運べるようにするためにこれらのデバイスをできる限り小さくすることの望みに起因して、分離されたボタンとしてアルファベットのすべての文字を有する従来のキーボードは、通常、これらのコンピューティングデバイスのハウジングで使用可能な限られた表面積に起因して、可能ではない。小型コンピューティングデバイスの例を超えてさえ、すべてのタイプのコンピューティングデバイス用のより便利なインターフェースを提供することへの関心がある。

この問題に対処するために、コンピューティングデバイス上でローカルに、ローカルネットワークを介して、または、インターネットなどの広域ネットワークを介してのいずれであれ、情報にアクセスするのにボイスまたは音声を使用することへの高まる関心および採用があった。音声認識を用いると、ダイアログ対話は、一般に、ユーザとコンピューティングデバイスとの間で行われる。ユーザは、通常は可聴におよび／または可視に情報を受け取り、プロンプトに可聴に応答するか、コマンドを発行する。しかし、しばしば、アプリケーションの開発中または展開後に、そのアプリケーションの性能を確かめることが望ましい。具体的に言うと、アプリケーションに関するユーザの使用法および／または成功率を確かめることが望ましい。そのような情報があれば、開発者は、アプリケーションのユーザの必要をよりよく満足するために、アプリケーションを「チューニングする」（すなわち、調整を行う）ことができる可能性がある。たとえば、アプリケーションとユーザとの間のダイアログのうちで、問題に出会う可能性が最も高い部分を識別することが、有用である場合がある。この形で、ダイアログのこれらの部分を、混乱を軽減するために調整することができる。

米国特許出願第２００４／０１１３９０８号明細書 米国特許出願第２００４／０２３０６３７Ａ１号明細書

アプリケーションとユーザとの間の対話データの記録またはロギングが、アプリケーションの性能を測定するために行われる。しかし、一般に、アプリケーション対話データのロギングは、たとえば（１）データを生成するのが面倒である、すなわち、アプリケーション開発者が、分析およびチューニング用の正しいデータを収集するために、コード内のさまざまな位置でアプリケーションを計測する（すなわち、システムデータのロギングに使用されるメッセージのセットを定義し、実装する）世話をしなければならず、（２）計測プロセスが、通常はアプリケーション固有の形で行われ、異なるアプリケーションにまたがってポータブルではなく、（３）ユーザの意図に関するより豊富な情報を用いてデータに注釈を付ける手動トランスクリプションプロセス（および／または他の明示的な人間による介入）が適用されない限り、対話ログデータが、限られた価値を有する、という短所のうちのいずれか１つまたはその組合せから損害を受ける場合がある。

この「発明の開示」は、下の「発明を実施するための最良の形態」でさらに説明されるいくつかの概念を単純化された形で紹介するために提供される。この「発明の開示」では、請求される主題の主要な特徴または本質的特徴を識別することは意図されておらず、請求される主題の範囲を判定する際の助けとして使用されることも意図されていない。

音声対応アプリケーションは、タスクに関して定義される。タスクの完了を示す情報および／またはターンデータ（ｔｕｒｎ ｄａｔａ）に関係する情報が、音声対応アプリケーションが実行される時にタスクに対して相対的に記録可能である。

タスクの完了を示す情報を、Ｄｉａｌｏｇデータと称する。このデータは、タスクの完了の成功または失敗を定量化する。さらに、Ｄｉａｌｏｇデータには、タスクが不成功であるまたは失敗する場合に理由を含めることができ、あるいは、適用可能な場合に、成功について複数の理由が可能である場合に成功の理由を含めることができる。追加データには、ユーザが応答を提供しなかった場合または音声リコグナイザが発話を認識できなかった場合を示す進行状況データを含めることができる。変化した入力フィールド値またはその状況のリストをも記録することができる。

Ｔｕｒｎデータは、アプリケーションとの直接対話を含み、アプリケーションによって提供されるプロンプト（応答が期待されない時）またはユーザ応答もしくはその不在に相関されたアプリケーションプロンプト、言い換えると、プロンプト／応答交換に基づいて編成される。したがって、記録できるデータの３つの領域は、プロンプトの目的を含む、アプリケーションによって提供されるプロンプトと、応答の目的を含む、ユーザによって提供される応答と、システムによって判定された認識結果とに関する情報を含む。

音声アプリケーションの計測およびログ記録ならびにこれを実施する方法を説明する前に、音声アプリケーションで使用できるコンピューティングデバイスを全般的に説明することが有用である可能性がある。ここで図１を参照すると、データ管理デバイス（ＰＩＭ、ＰＤＡ、または類似物）の例示的な形が、３０に示されている。しかし、本明細書で説明する概念を、下で述べる他のコンピューティングデバイス、具体的には入力ボタンまたは類似物のための限られた表面積を有するコンピューティングデバイスを使用して実践することもできることが、企図されている。たとえば、電話機および／またはデータ管理デバイスも、本明細書で説明される概念から利益を得る。そのようなデバイスは、既存のポータブルパーソナル情報管理デバイスおよび他のポータブル電子デバイスと比較して高められたユーティリティを有し、そのようなデバイスの機能およびコンパクトなサイズは、ユーザがそのデバイスを常時持ち運ぶことを促進する可能性がより高い。したがって、本明細書で説明される応用例の範囲が、本明細書で示される例示的なデータ管理デバイスもしくはＰＩＭデバイス、電話機、またはコンピュータの開示に限定されることは、意図されていない。

データ管理モバイルデバイス３０の例示的な形が、図１に示されている。モバイルデバイス３０は、ハウジング３２を含み、ディスプレイ３４を含むユーザインターフェースを有し、ディスプレイ３４は、スタイラス３３と共に接触感知型ディスプレイスクリーンを使用する。スタイラス３３は、指定された座標でディスプレイ３４を押すかこれに接触して、フィールドを選択し、カーソルの開始位置を選択的に移動し、またはジェスチャもしくは手書きを介するなど、他の形でコマンド情報を提供するのに使用される。その代わりにまたはそれに加えて、１つまたは複数のボタン３５を、ナビゲーションのためにデバイス３０に含めることができる。さらに、回転可能なホイール、ローラー、または類似物などの他の入力機構を設けることもできる。しかし、本発明がこれらの形の入力機構によって限定されることが意図されていないことに留意されたい。たとえば、別の形の入力に、コンピュータビジョンを介するなどのビジュアル入力を含めることができる。

ここで図２を参照すると、ブロック図に、モバイルデバイス３０を含む機能コンポーネントが示されている。中央処理装置（ＣＰＵ）５０が、ソフトウェア制御機能を実装する。ＣＰＵ ５０は、ディスプレイ３４に結合され、その結果、制御ソフトウェアに従って生成されたテキストおよびグラフィックアイコンが、ディスプレイ３４に表示されるようになる。スピーカ４３を、通常はディジタル−アナログコンバータ５９と共にＣＰＵ ５０に結合して、可聴出力を提供することができる。モバイルデバイス３０にダウンロードされるかユーザによって入力されたデータは、ＣＰＵ ５０に両方向で結合された不揮発性読み取り／書き込みランダムアクセスメモリストア５４に格納される。ランダムアクセスメモリ（ＲＡＭ）５４は、ＣＰＵ ５０によって実行される命令の揮発性ストレージと、レジスタ値などの一時的データのストレージとをもたらす。構成オプションおよび他の変数のデフォルト値は、読み取り専用メモリ（ＲＯＭ）５８に格納される。ＲＯＭ ５８は、モバイル３０の基本機能性および他のオペレーティングシステムカーネル機能（たとえば、ＲＡＭ ５４へのソフトウェアコンポーネントのロード）を制御する、デバイスのオペレーティングシステムソフトウェアを格納するのにも使用することができる。

ＲＡＭ ５４は、アプリケーションプログラムを格納するのに使用されるＰＣ上のハードドライブの機能に似た形で、コードのストレージとしても働く。不揮発性メモリが、コードの格納に使用されているが、その代わりに、コードの実行には使用されない揮発性メモリにコードを格納することができることに留意されたい。

無線信号を、ＣＰＵ ５０に結合された無線トランシーバ５２を介してモバイルデバイスによって送信／受信することができる。オプションの通信インターフェース６０を、望まれる場合に、コンピュータ（たとえば、デスクトップコンピュータ）または有線ネットワークから直接にデータをダウンロードするために設けることもできる。したがって、インターフェース６０は、さまざまな形の通信デバイス、たとえば、赤外線リンク、モデム、ネットワークカード、または類似物を含むことができる。

モバイルデバイス３０は、マイクロホン２９、アナログ−ディジタル（Ａ／Ｄ）コンバータ３７、およびストア５４に格納されたオプションの認識プログラム（音声、ＤＴＭＦ、手書き、ジェスタ、またはコンピュータビジョン）を含む。たとえば、デバイス３０のユーザからの可聴の情報、命令、またはコマンドに応答して、マイクロホン２９は、音声信号を供給し、この信号がＡ／Ｄコンバータ３７によってディジタル化される。音声認識プログラムは、ディジタル化された音声信号に対して正規化機能および／または特徴抽出機能を実行して、中間音声認識結果を得ることができる。無線トランシーバ５２または通信インターフェース６０を使用して、音声データを、下で述べる、図４のアーキテクチャに示されたリモート認識サーバ２０４に送信することができる。その後、認識結果を、モバイルデバイス３０でのレンダリング（たとえば、ビジュアルおよび／または可聴）およびウェブサーバ２０２（図４）への最終的な送信のためにモバイルデバイス３０に返すことができ、ここで、ウェブサーバ２０２およびモバイルデバイス３０は、クライアント／サーバ関係で動作する。類似する処理を、他の形の入力について使用することができる。たとえば、手書き入力を、デバイス３０での前処理を伴ってまたはこれを伴わずにディジタル化することができる。音声データと同様に、この形の入力を、認識のために認識サーバ２０４に送信することができ、ここで、認識結果は、その後、デバイス３０および／またはウェブサーバ２０２のうちの少なくとも１つに返される。同様に、ＤＴＭＦデータ、ジェスチャデータ、およびビジュアルデータを、似た形で処理することができる。入力の形に応じて、デバイス３０（および上で述べた他の形のクライアント）は、ビジュアル入力用のカメラなど、必要なハードウェアを含むはずである。

上で説明したポータブルコンピューティングデバイスまたはモバイルコンピューティングデバイスに加えて、本明細書で説明する概念を、一般的なデスクトップコンピュータなどの多数の他のコンピューティングデバイスと共に使用できることを理解されたい。たとえば、限られた身体能力を有するユーザは、フル英数字キーボードなどの他の従来の入力装置の操作が難し過ぎる場合に、コンピュータまたは他のコンピューティングデバイスにテキストを入力することができる。

本発明は、多数の他の汎用のまたは特殊目的のコンピューティングシステム、コンピューティング環境、またはコンピューティング構成と共にも動作する。本発明と共に使用するのに適切である可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例は、無線電話機またはセルラ電話機、通常の電話機（スクリーンを伴わない）、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物を含むが、これらに限定はされない。

次は、図３に示された汎用コンピュータ１２０の短い説明である。しかし、コンピュータ１２０は、やはり、適切なコンピューティング環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する限定を提案することは意図されていない。コンピュータ１２０を、その中に示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。

下の説明を、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の全体的な文脈で提供することができる。一般に、プログラムモジュールは、特定のタスクを実行するか特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。本明細書で説明される例示的実施形態は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体との両方に配置することができる。プログラムおよびモジュールによって実行されるタスクを、下で、図面の助けを得て説明する。当業者は、この説明および図面を、プロセッサ実行可能命令として実装することができ、このプロセッサ実行可能命令は、任意の形のコンピュータ可読媒体に書き込まれ得る。

図３を参照すると、コンピュータ１２０のコンポーネントは、処理ユニット１４０と、システムメモリ１５０と、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット１４０に結合するシステムバス１４１とを含むことができるが、これらに限定はされない。システムバス１４１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。限定ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。コンピュータ１２０には、通常は、さまざまなコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピュータ１２０によってアクセスすることができるすべての使用可能な媒体とすることができ、コンピュータ可読媒体には、揮発性媒体と不揮発性媒体との両方、取外し可能媒体と取外し不能媒体との両方が含まれる。限定ではなく例として、コンピュータ可読媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータなどの情報を記憶する任意の方法またはテクノロジで実施される、揮発性と不揮発性と両方の、取外し可能および取外し不能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を格納するのに使用することができ、コンピュータ１２０によってアクセスすることができるすべての他の媒体が含まれるが、これに限定はされない。

通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータを実施し、通信媒体は、すべての情報配信媒体を含む。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれなければならない。

システムメモリ１５０には、読み取り専用メモリ（ＲＯＭ）１５１およびランダムアクセスメモリ（ＲＡＭ）１５２などの揮発性および／または不揮発性のメモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１２０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１５３（ＢＩＯＳ）が、通常はＲＯＭ １５１に格納される。ＲＡＭ １５２には、通常は、即座にアクセス可能であるおよび／または処理ユニット１４０によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図３に、オペレーティングシステム１５４、アプリケーションプログラム１５５、他のプログラムモジュール１５６、およびプログラムデータ１５７を示す。

コンピュータ１２０には、他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体を含めることもできる。例としてのみ、図３に、取外し不能不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１６１、取外し可能不揮発性磁気ディスク１７２から読み取るかこれに書き込む磁気ディスクドライブ１７１、およびＣＤ−ＲＯＭまたは他の光学媒体などの取外し可能不揮発性光ディスク１７６から読み取るかこれに書き込む光学ディスクドライブ１７５を示す。この例示的オペレーティング環境で使用することができる他の取外し可能／取外し不能の揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定はされない。ハードディスクドライブ１６１は、通常は、インターフェース１６０などの取外し不能メモリインターフェースを介してシステムバス１４１に接続され、磁気ディスクドライブ１７１および光学ディスクドライブ１７５は、通常は、インターフェース１７０などの取外し可能メモリインターフェースによってシステムバス１４１に接続される。

上で述べ、図３に図示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１２０のコンピュータ可読命令、データ構造体、プログラムモジュール、および他のデータのストレージを提供する。図３では、たとえば、ハードディスクドライブ１６１が、オペレーティングシステム１６４、アプリケーションプログラム１６５、他のプログラムモジュール１６６、およびプログラムデータ１６７を格納するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１５４、アプリケーションプログラム１５５、他のプログラムモジュール１５６、およびプログラムデータ１５７と同一または異なるいずれかとすることができることに留意されたい。オペレーティングシステム１６４、アプリケーションプログラム１６５、他のプログラムモジュール１６６、およびプログラムデータ１６７は、最低限でもこれらが異なるコピーであることを示すために、本明細書では異なる符号を与えられている。

ユーザは、キーボード１８２、マイクロホン１８３、およびマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１８１などの入力デバイスを介してコンピュータ１２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１８０を介して処理ユニット１４０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続されることが可能である。モニタ１８４または他のタイプのディスプレイデバイスも、ビデオインターフェース１８５などのインターフェースを介してシステムバス１４１に接続される。モニタの他に、コンピュータに、スピーカ１８７およびプリンタ１８６など、出力周辺インターフェース１８８を介して接続することができる他の周辺出力デバイスをも含めることができる。

コンピュータ１２０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、コンピュータ１２０に関して上で説明した要素の多数またはすべてを含む。図３に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１９１および広域ネットワーク（ＷＡＮ）１９３が含まれるが、他のネットワークを含めることもできる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。

ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１２０は、ネットワークインターフェースまたはネットワークアダプタ１９０を介してＬＡＮ １９１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１２０には、通常は、インターネットなどのＷＡＮ １９３を介する通信を確立する、モデム１９２または他の手段が含まれる。モデム１９２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１８０または他の適当な機構を介してシステムバス１４１に接続することができる。ネットワーク化された環境では、コンピュータ１２０に関して示されたプログラムモジュールまたはその諸部分を、リモートメモリストレージデバイスに格納することができる。制限ではなく例として、図３に、リモートコンピュータ１９４に常駐するリモートアプリケーションプログラム１９５を示す。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用することができることを了解されたい。

例示的実施形態
図４に、本明細書で説明する概念と共に使用できるネットワークベースの認識（本明細書では広域ネットワークを用いて例示される）のアーキテクチャ２００を示す。しかし、リモートコンポーネントとの相互作用が、リコグナイザを含む音声アプリケーションを、その中にすべての必要なコンポーネントまたはモジュールが存在する単一のコンピューティングデバイス上で動作可能とすることができるという点で、１つの実施形態にすぎないことを理解されたい。

一般に、ウェブサーバ２０２に格納された情報には、モバイルデバイス３０（本明細書では、入力の形に基づいて、必要に応じてディスプレイスクリーン、マイクロホン、カメラ、接触感知型パネルなどを有する他の形のコンピューティングデバイスも表す）を介して、または電話機８０を介して（この場合に、情報は、可聴にまたは押されたキーに応答して電話機８０によって生成されるトーンを介して要求され、ウェブサーバ２０２からの情報は、可聴でのみユーザに戻って供給される）アクセスすることができる。

この例示的実施形態では、アーキテクチャ２００は、情報が音声認識を使用してデバイス３０または電話機８０のどちらを介して入手される場合であっても、単一の認識サーバ２０４が動作の両方のモードをサポートできるという点で、統一されている。さらに、アーキテクチャ２００は、周知のマークアップ音声（たとえば、ＨＴＭＬ、ＸＨＴＭＬ、ｃＨＴＭＬ、ＸＭＬ、ＷＭＬ、および類似物）の拡張を使用して動作する。したがって、ウェブサーバ２０２に格納された情報に、これらのマークアップ音声に見られる周知のＧＵＩ法を使用してアクセスすることもできる。周知のマークアップ音声の拡張を使用することによって、ウェブサーバ２０２でのオーサリングが、より簡単であり、現在存在するレガシアプリケーションを、ボイスまたは他の形の認識を含むように簡単に変更することもできる。

一般に、デバイス３０は、ウェブサーバ２０２によって供給されるＨＴＭＬ＋スクリプトまたは類似物を実行する。ボイス認識が必要な時には、たとえば、上で述べたようにオーディオ信号がデバイス３０によって前処理されている、ディジタル化されたオーディオ信号または音声特徴とすることのできる音声データが、音声認識中に使用すべき文法または言語モデルの表示と共に認識サーバ２０４に供給される。認識サーバ２０４の実施態様は、多数の形をとることができ、その１つが図示されているが、一般に、リコグナイザ２１１を含む。認識の結果を、望まれる場合または適当な場合にローカルレンダリングのためにデバイス３０に戻して供給することができる。認識および使用される場合のすべてのグラフィカルユーザインターフェースを介する情報のコンパイルの際に、デバイス３０は、さらなる処理および必要な場合のさらなるＨＴＭＬスクリプトの受け取りのために、情報をウェブサーバ２０２に送信する。

図４に示されているように、デバイス３０、ウェブサーバ２０２、および認識サーバ２０４は、一般に、ネットワーク２０５、ここではインターネットなどの広域ネットワークを介して接続され、別々にアドレッシング可能である。したがって、これらのデバイスのいずれかが、物理的に互いに隣接して配置されることは、必要ではない。具体的に言うと、ウェブサーバ２０２が認識サーバ２０４を含むことは、必要ではない。この形で、ウェブサーバ２０２でのオーサリングは、作成者が認識サーバ２０４の込み入った事情を知る必要なしに、それが意図されたアプリケーションに焦点を合わせることができる。作成者が認識サーバ２０４の込み入った事情を知る必要があるのではなく、認識サーバ２０４を、独立に設計し、ネットワーク２０５に接続することができ、これによって、ウェブサーバ２０２でのさらなる変更を必要とせずに、認識サーバ２０４を更新し、改善することができる。下で述べるように、ウェブサーバ２０２には、クライアントサイドマークアップおよびスクリプトを動的に生成できるオーサリング機構を含めることもできる。さらなる実施形態で、ウェブサーバ２０２、認識サーバ２０４、およびデバイス３０を、実装するマシンの機能に応じて組み合わせることができる。たとえば、クライアントが、汎用コンピュータ、たとえばパーソナルコンピュータを含む場合に、クライアントに、認識サーバ２０４を含めることができる。同様に、望まれる場合に、ウェブサーバ２０２および認識サーバ２０４を、単一のマシンに組み込むことができる。

電話機８０を介するウェブサーバ２０２へのアクセスは、有線または無線の電話網２０８への電話機８０の接続を含み、この接続は、電話機８０をサードパーティゲートウェイ２１０に接続する。ゲートウェイ２１０は、電話機８０をテレフォニボイスブラウザ２１２に接続する。テレフォンボイスブラウザ２１２は、テレフォニインターフェースおよびボイスブラウザ２１６を提供するメディアサーバ２１４を含む。デバイス３０と同様に、テレフォニボイスブラウザ２１２は、ウェブサーバ２０２からＨＴＭＬスクリプトまたは類似物を受信する。一実施形態で、ＨＴＭＬスクリプトは、デバイス３０に供給されるＨＴＭＬスクリプトに類似する形を有する。この形で、ウェブサーバ２０２は、デバイス３０および電話機８０を別々にサポートする必要がなく、標準ＧＵＩクライアントを別々にサポートする必要さえない。そうではなく、共通のマークアップ言語を使用することができる。さらに、デバイス３０と同様に、電話機８０によって送信される可聴信号からのボイス認識は、ボイスブラウザ２１６から認識サーバ２０４へ、たとえばＴＣＰ／ＩＰを使用して、ネットワーク２０５を介してまたは専用回線２０７を介してのいずれかで供給される。ウェブサーバ２０２、認識サーバ２０４、およびテレフォンボイスブラウザ２１２は、図３に示された汎用デスクトップコンピュータなどの任意の適切なコンピューティング環境で実施することができる。

しかし、ＤＴＭＦ認識が使用される場合に、この形の認識が、一般に、認識サーバ２０４ではなくメディアサーバ２１４で実行されることに留意されたい。言い換えると、ＤＴＭＦ文法は、メディアサーバ２１４によって使用されるはずである。

図４に戻ると、ウェブサーバ２０２には、サーバサイドプラグインオーサリングツールまたはモジュール２０９（たとえば、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＡＳＰ、ＡＳＰ＋、およびＡＳＰ．Ｎｅｔ、ＪＳＰ、Ｊａｖａ（登録商標）ｂｅａｎｓ、または類似物）を含めることができる。サーバサイドプラグインモジュール２０９は、クライアントサイドマークアップを動的に生成でき、ウェブサーバ２０２にアクセスするクライアントのタイプ用のマークアップの特定の形すら動的に生成することができる。クライアント情報は、クライアント／サーバ関係の最初の確立時にウェブサーバ２０２に供給することができ、あるいは、ウェブサーバ２０２に、クライアントデバイスの機能を検出するモジュールまたはルーチンを含めることができる。この形で、サーバサイドプラグインモジュール２０９は、ボイス認識シナリオごとに、すなわち電話機８０を介してはボイスのみまたはデバイス３０についてマルチモーダルで、クライアントサイドマークアップを生成することができる。一貫するクライアントサイドモデルを使用することによって、多数の異なるクライアント用のアプリケーションオーサリングが、大幅により単純になる。

クライアントサイドマークアップの動的生成に加えて、下で述べる高水準ダイアログモジュールを、アプリケーションオーサリングでの開発者による使用のためにストア２１１に格納されるサーバサイドコントロールとして実装することができる。一般に、高水準ダイアログモジュール２１１は、開発者によって指定されるパラメータに基づいて、ボイスのみのシナリオとマルチモーダルシナリオとの両方でクライアントサイドマークアップおよびスクリプトを動的に生成する。高水準ダイアログモジュール２１１には、開発者の必要に合わせるために、クライアントサイドマークアップを生成するためのパラメータを含めることができる。

クライアントサイドマークアップの生成
上で示したように、サーバサイドプラグインモジュール２０９は、クライアントデバイス３０から要求が行われた時に、クライアントサイドマークアップを出力する。手短に言うと、サーバサイドプラグインモジュール２０９は、ウェブサイトを、したがってアプリケーションおよびそのアプリケーションによって提供されるサービスを、定義しまたは構築することを可能にする。サーバサイドプラグインモジュール２０９内の命令は、コンパイルされたコードから作られる。このコードは、ウェブ要求がウェブサーバ２０２に達する時に実行される。次に、サーバサイドプラグインモジュール２０９が、新しいクライアントサイドマークアップページを出力し、このクライアントサイドマークアップページが、クライアントデバイス３０に送信される。周知の通り、このプロセスを、一般にレンダリングと称する。サーバサイドプラグインモジュール２０９は、マークアップ言語を抽象化し、カプセル化する「コントロール」を操作し、したがってクライアントサイドマークアップページのコードを操作する。マークアップ言語を抽象化し、カプセル化し、ウェブサーバ２０２上で動作するそのようなコントロールは、たとえば、「サーブレット」または「サーバサイドプラグイン」を含み、またはこれらと同等である。

既知の通り、従来技術のサーバサイドプラグインモジュールは、ビジュアルレンダリングおよびクライアントデバイス３０との相互作用に関するクライアントサイドマークアップを生成することができる。特許出願書に、認識拡張および可聴プロンプト拡張を含めるためのサーバサイドプラグインモジュール２０９の拡張に関する３つの異なる手法が詳細に記載されている（たとえば、特許文献１および特許文献２参照）。本発明の諸態様は、これらの手法のすべてと共に使用することができるが、１つの手法の短い説明を、例示的実施形態を説明するために下で提供する。

図５を参照すると、認識／可聴プロンプトコントロール３０６は、ビジュアルコントロール３０２と別々であるが、下で述べるように選択的にこれに関連する。この形で、コントロール３０６は、ビジュアルコントロール３０２に直接に基づいて構築されるのではなく、ビジュアルコントロール３０２を書き直す必要なしに認識／可聴プロンプト使用可能化を提供する。コントロール３０６は、コントロール３０２と同様に、ライブラリ３００を使用する。この実施形態で、ライブラリ３００は、ビジュアルプロンプトマークアップ情報と認識／可聴プロンプトマークアップ情報との両方を含む。

この手法には、大きい利益がある。第１に、ビジュアルコントロール３０２は、内容において変更される必要がない。第２に、コントロール３０６は、一貫性があり、音声対応コントロール３０２の性質に従って変更される必要がない単一のモジュールを形成することができる。第３に、音声使用可能化のプロセスすなわち、ビジュアルコントロール３０２とのコントロール３０６の明示的な関連付けは、明示的かつ選択的なプロセスなので、設計時に完全に開発者の制御の下にある。これは、ビジュアルコントロールのマークアップ言語が、コントロール３０６によって生成されたマークアップ言語によって提供される認識を介してまたはキーボードなどの従来の入力デバイスを介してなど、複数のソースからの入力値を受け取ることを可能にもする。短く言うと、コントロール３０６を、サーバサイドプラグインモジュール２０９のビジュアルオーサリングページの既存アプリケーションオーサリングページに追加することができる。コントロール３０６は、クライアントデバイス３０のユーザに対話の新しいモーダリティ（すなわち、認識および／または可聴プロンプト）を提供すると同時に、ビジュアルコントロールのアプリケーションロジックおよびビジュアル入出力機能を再利用する。コントロール３０６を、アプリケーションロジックをコーディングできるビジュアルコントロール３０２に関連付けることができることを考慮して、コントロール３０６を、以下では「コンパニオンコントロール３０６」と称し、ビジュアルコントロール３０２を、「プライマリコントロール３０２」と称する。これらの言及が、コントロール３０２および３０６を区別するために提供され、制限的であることは意図されていないことに留意されたい。たとえば、コンパニオンコントロール３０６を使用して、ボイスのみウェブサイトなどのビジュアルレンダリングを含まないウェブサイトを開発し、またはオーサリングすることができる。その場合に、ある種のアプリケーションロジックを、コンパニオンコントロールロジックで実施することができる。

コンパニオンコントロール４００の例示的セットを、図６に示す。この実施形態では、コンパニオンコントロール４００は、一般に、ＱＡコントロール４０２、Ｃｏｍｍａｎｄコントロール４０４、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロール４０６、Ｃｕｓｔｏｍ Ｖａｌｉｄａｔｏｒコントロール４０８、およびｓｅｍａｎｔｉｃ ｍａｐ４１０を含む。ｓｅｍａｎｔｉｃ ｍａｐ４１０は、概略的に示されており、ｓｅｍａｎｔｉｃ ｉｔｅｍ ４１２を含み、ｓｅｍａｎｔｉｃ ｉｔｅｍ ４１２は、ビジュアルドメインプライマリコントロール４０２（たとえば、コンパニオンコントロール４００のＨＴＭＬおよび非ビジュアル認識ドメインの間のレイヤ）を形成する、入力フィールドと考えることができる。

ＱＡコントロール４０２は、出力コントロールの機能を実行するＰｒｏｍｐｔオブジェクトを参照する、すなわち、ヒューマンダイアログ用の「プロンプトする」クライアントサイドマークアップを提供するＰｒｏｍｐｔプロパティを含み、このクライアントサイドマークアップは、通常、直接にマークアップに含まれるかＵＲＬを介して参照されるデータである事前に録音されたオーディオファイルまたはテキスト−音声変換用のテキストを再生することを含む。同様に、入力コントロールは、ＱＡコントロール４０２およびＣｏｍｍａｎｄコントロール４０４として実施され、ヒューマンダイアログにも従い、Ｐｒｏｍｐｔプロパティ（Ｐｒｏｍｐｔオブジェクトを参照する）と少なくとも１つのＡｎｓｗｅｒオブジェクトを参照するＡｎｓｗｅｒプロパティとを含む。ＱＡコントロール４０２とＣｏｍｍａｎｄコントロール４０４との両方が、クライアントデバイス３０のユーザからの期待される入力または可能な入力に文法を関連付ける。
この点で、コントロールのそれぞれの短い説明を提供することが役に立つ可能性がある。

ＱＡコントロール
一般に、ＱＡコントロール４０２は、図示のプロパティを介して、たとえば、出力可聴プロンプトの提供、入力データの収集、入力結果の信頼性妥当性検査の実行、入力データの確認の可能化、およびウェブサイトでのダイアログフローの制御の援助のうちの１つまたは複数を実行することができる。言い換えると、ＱＡコントロール４０２は、特定のトピックのコントロールとして機能するプロパティを含む。

ＱＡコントロール４０２は、他のコントロールと同様に、ウェブサーバ２０２上で実行され、これは、ＱＡコントロール４０２が、サーバサイドマークアップフォーマリズム（ＡＳＰ、ＪＳＰ、または類似物）を使用してウェブサーバ上で保持されるアプリケーション開発ウェブページで定義されるが、異なる形のマークアップとしてクライアントデバイス３０に出力されることを意味する。ＱＡコントロールがプロパティＰｒｏｍｐｔ、Ｒｅｃｏ、Ａｎｓｗｅｒｓ、ＥｘｔｒａＡｎｓｗｅｒｓ、およびＣｏｎｆｉｒｍｓのすべてから形成されるように見える図６に図示されてはいるが、これらが、単にオプションであり、これらのうちの１つまたは複数をＱＡコントロールのために含めることができることを理解されたい。

この点で、アプリケーションシナリオに関してＱＡコントロール４０２の使用を説明することが役に立つ可能性がある。図６を参照すると、ボイスのみアプリケーションにおいて、ＱＡコントロール４０２は、ダイアログ内の質問および回答として機能することができる。質問は、Ｐｒｏｍｐｔオブジェクトによって提供され、文法は、入力データの認識およびその入力に対する関連する処理のための文法オブジェクトを介して定義される。Ａｎｓｗｅｒｓプロパティは、Ａｎｓｗｅｒオブジェクトを使用して、認識された結果をＳｅｍａｎｔｉｃ Ｍａｐ ４１０内のＳｅｍａｎｔｉｃＩｔｅｍ ４１２に関連付け、Ａｎｓｗｅｒオブジェクトは、認識結果をどのように処理するかに関する情報を含む。線４１４は、Ｓｅｍａｎｔｉｃ Ｍａｐ ４１０およびその中のＳｅｍａｎｔｉｃＩｔｅｍ ４１２とのＱＡコントロール４０２の関連付けを示す。多数のＳｅｍａｎｔｉｃＩｔｅｍ ４１２が、線４１８によって表されるようにビジュアルコントロールまたはプライマリコントロール３０２に個別に関連するが、１つまたは複数のＳｅｍａｎｔｉｃＩｔｅｍ ４１２を、ビジュアルコントロールに関連せず、内部的にのみ使用されるものとすることができる。クライアントデバイス３０のユーザが、たとえば「ＴａｐＥｖｅｎｔ」を用いてビジュアルテキストボックスに触れることができるマルチモーダルシナリオでは、可聴プロンプトが、必要でない場合がある。たとえば、クライアントデバイスのユーザが対応するフィールドに何を入力しなければならないかの表示を形成するビジュアルテキストを有するテキストボックスを含むプライマリコントロールについて、対応するＱＡコントロール４０２は、オーディオ再生またはテキスト−音声変換などの対応するプロンプトを有しても有しなくてもよいが、認識に関する期待される値に対応する文法と、入力を処理するか、音声が検出されない、音声が認識されない、またはタイムアウト時に発火されるイベントなどの他のリコグナイザイベントを処理するイベントハンドラとを有する。

さらなる実施形態では、認識結果が、その認識結果が正しかったことの信頼性のレベルを示す信頼性レベル測定値を含む。確認閾値を、Ａｎｓｗｅｒオブジェクト内で、たとえば０．７と等しいＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄとして指定することもできる。確認レベルが、関連する閾値を超える場合に、その結果を、確認されたと考えることができる。

それに加えてまたはその代わりに、音声認識の文法を指定するために、ＱＡコントロールおよび／またはＣｏｍｍａｎｄコントロールが、Ｄｔｍｆ（デュアルトーン変調周波数）文法を指定して、プロンプトまたは質問に応答する電話機キーアクティブ化を認識できることにも留意されたい。

この点で、Ｓｅｍａｎｔｉｃ Ｍａｐ ４１０のＳｅｍａｎｔｉｃＩｔｅｍ ４１２が、たとえば認識を介して音声またはＤｔｍｆを充たされた時に、複数のアクションを行えることに留意されたい。第１に、値が「変更された」ことを示すイベントを、発行するか発火させることができる。確認レベルが満足されたかどうかに応じて、発行または発火できるもう１つのイベントに、対応するセマンティックアイテムが確認されたことを示す「確認」イベントが含まれる。これらのイベントは、ダイアログを制御するのに使用される。

Ｃｏｎｆｉｒｍｓプロパティには、ＳｅｍａｎｔｉｃＩｔｅｍ ４１２に関連し、望まれる場合にＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄを含むことができるという点で、Ａｎｓｗｅｒｓプロパティに関して上で説明したものに類似する構造を有する回答オブジェクトを含めることもできる。Ｃｏｎｆｉｒｍｓプロパティは、認識結果自体を含むことが意図されているのではなく、既に含まれる結果を確認し、含まれる結果が正しいかどうかをユーザから確かめることが意図されている。Ｃｏｎｆｉｒｍｓプロパティは、前に得られた結果の値が正しかったかどうかをアサートするのに使用されるＡｎｓｗｅｒオブジェクトのコレクションである。含むＱＡのＰｒｏｍｐｔオブジェクトは、これらのアイテムについて照会し、関連するＳｅｍａｎｔｉｃＩｔｅｍ ４１２から認識結果を入手し、これを「Ｄｉｄ ｙｏｕ ｓａｙ Ｓｅａｔｔｌｅ？（シアトルと言いましたか）」などの質問に形成する。ユーザが、「Ｙｅｓ（はい）」などの肯定で応答する場合に、確認済みイベントが発火される。ユーザが、「Ｎｏ（いいえ）」などの否定で応答する場合に、関連するＳｅｍａｎｔｉｃＩｔｅｍ ４１２がクリアされる。

Ｃｏｎｆｉｒｍｓプロパティは、確認プロンプトがユーザに提供された後に、訂正を受け入れることもできる。たとえば、確認プロンプト「Ｄｉｄ ｙｏｕ ｓａｙ Ｓｅａｔｔｌｅ？」に応答して、ユーザが、「Ｓａｎ Ｆｒａｎｃｉｓｃｏ（サンフランシスコ）」、または「Ｎｏ，Ｓａｎ Ｆｒａｎｃｉｓｃｏ（いいえ、サンフランシスコです）」と応答することができ、この場合に、ＱＡコントロールは、訂正を受け取っている。Ａｎｓｗｅｒオブジェクトを介してどのＳｅｍａｎｔｉｃＩｔｅｍが確認されているかに関する情報を有するので、ＳｅｍａｎｔｉｃＩｔｅｍ内の値を、訂正された値に置換することができる。望まれる場合に、「Ｗｈｅｎ ｄｉｄ ｙｏｕ ｗａｎｔ ｔｏ ｇｏ ｔｏ Ｓｅａｔｔｌｅ？（いつシアトルに行きたいですか）」などの情報に関して、さらなるプロンプトに確認を含めることができ、ここで、システムによるこのプロンプトは、「Ｓｅａｔｔｌｅ」に関する確認と、出発の日付に関するさらなるプロンプトとを含むことに留意されたい。目的地の場所に対する訂正を提供するユーザによる応答は、Ｃｏｎｆｉｒｍｓプロパティをアクティブ化して、関連するセマンティックアイテムを訂正し、出発日だけを伴う応答は、目的地の暗黙の確認を提供する。

ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、ユーザが既に行われたプロンプトまたは照会に加えて提供できるＡｎｓｗｅｒオブジェクトを、アプリケーション作成者が指定することを可能にする。たとえば、旅行指向システムが、目的地の都市に関してユーザにプロンプトを出すが、ユーザが「Ｓｅａｔｔｌｅ ｔｏｍｏｒｒｏｗ（シアトル、明日）」を示すことによって応答する場合に、当初にそのユーザにプロンプトを出したＡｎｓｗｅｒｓプロパティは、目的地都市「Ｓｅａｔｔｌｅ」を取り出し、したがってこれを適当なＳｅｍａｎｔｉｃＩｔｅｍにバインドするが、ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、次に続く日として「Ｔｏｍｏｒｒｏｗ」を処理することができ（システムが現在の日付を知っていると仮定して）、これによって、この結果をＳｅｍａｎｔｉｃ Ｍａｐ内の適当なＳｅｍａｎｔｉｃＩｔｅｍにバインドすることができる。ＥｘｔｒａＡｎｓｗｅｒｓプロパティは、ユーザがそれについても述べる可能性がある可能な余分な情報について定義された１つまたは複数のＡｎｓｗｅｒオブジェクトを含む。上で提供した例では、出発日に関しても情報を取り出したので、確認レベルが対応するＣｏｎｆｉｒｍＴｈｒｅｓｈｏｌｄを超えると仮定すると、このシステムは、この情報についてユーザに再びプロンプトを出す必要がない。確認レベルが対応する閾値を超えなかった場合には、適当なＣｏｎｆｉｒｍｓプロパティがアクティブ化されるはずである。

Ｃｏｍｍａｎｄコントロール
Ｃｏｍｍａｎｄコントロール４０４は、通常は問われた質問に関する意味的インポートをほとんど有しておらず、むしろ、たとえばヘルプ、キャンセル、繰り返しなど、援助を求めるかナビゲーションをもたらす、ボイスのみダイアログで一般的なユーザ発話である。Ｃｏｍｍａｎｄコントロール４０４には、プロンプトオブジェクトを指定するＰｒｏｍｐｔプロパティを含めることができる。さらに、Ｃｏｍｍａｎｄコントロール４０４は、文法（Ｇｒａｍｍａｒプロパティを介する）および認識に対する関連する処理（どちらかといえば、ＳｅｍａｎｔｉｃＩｔｅｍへの結果のバインディングなしのＡｎｓｗｅｒオブジェクトに似る）だけではなく、コンテキストの「スコープ」およびタイプを指定するのにも使用することができる。これは、クライアントサイドマークアップでのグローバル挙動とコンテキスト感応型挙動との両方のオーサリングを可能にする。Ｃｏｍｍａｎｄコントロール４０４は、「ヘルプ」コマンドまたは、クライアントデバイスのユーザがウェブサイトの他の選択されたエリアへナビゲートすることを可能にするコマンドなど、追加のタイプの入力を可能にする。

ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロール
ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールは、演算子に従って２つの値を比較し、適当なアクションを行う。比較される値は、整数、テキストのストリングなど、任意の形とすることができる。ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒは、妥当性検査されるＳｅｍａｎｔｉｃＩｔｅｍを示すプロパティＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅを含む。妥当性検査されるＳｅｍａｎｔｉｃＩｔｅｍを、定数または別のＳｅｍａｎｔｉｃＩｔｅｍと比較することができ、ここで、定数または他のＳｅｍａｎｔｉｃＩｔｅｍは、それぞれプロパティＶａｌｕｅｔｏＣｏｍｐａｒｅおよびＳｅｍａｔｉｃＩｔｅｍｔｏＣｏｍｐａｒｅによって供給される。ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒに関連する他のパラメータまたはプロパティには、行われる比較を定義するＯｐｅｒａｔｏｒと、たとえば整数またはセマンティックアイテムのストリングなど、値のタイプを定義するＴｙｐｅとが含まれる。

ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールに関連する妥当性検査が不合格の場合に、Ｐｒｏｍｐｔプロパティは、得られた結果が正しくなかったことをユーザに指示する、再生できるＰｒｏｍｐｔオブジェクトを指定することができる。比較の際に妥当性検査が不合格になる場合には、ＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅによって定義された関連するＳｅｍａｎｔｉｃＩｔｅｍは、システムが正しい値についてユーザに再びプロンプトを出すために、空であるものとして示される。しかし、正しくない値が、正しくない値を繰り返すユーザへのプロンプトに使用される場合に、Ｓｅｍａｎｔｉｃ Ｍａｐ内の関連するＳｅｍａｎｔｉｃＩｔｅｍの正しくない値をクリアしないことが役に立つ場合がある。アプリケーション作成者の望みに応じて、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールを、関連するＳｅｍａｎｔｉｃＩｔｅｍの値が値を変化させる時またはその値が確認された時のいずれかにトリガすることができる。

ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロール
ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールは、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロールに似ている。プロパティＳｅｍａｔｉｃＩｔｅｍｔｏＶａｌｉｄａｔｅは、妥当性検査されるＳｅｍａｎｔｉｃＩｔｅｍを示し、プロパティＣｌｉｅｎｔＶａｌｉｄａｔｉｏｎＦｕｎｃｔｉｏｎは、関連する関数またはスクリプトを介してカスタム妥当性検査ルーチンを指定する。この関数は、妥当性検査が不合格であったか否かのブール値「ｙｅｓ」もしくは「ｎｏ」またはその同等物を提供する。Ｐｒｏｍｐｔプロパティは、妥当性検査のエラーまたは不合格の表示を提供するＰｒｏｍｐｔオブジェクトを指定することができる。アプリケーション作成者の望みに応じて、ＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールを、関連するＳｅｍａｎｔｉｃＩｔｅｍの値が値を変化させる時またはその値が確認された時のいずれかにトリガすることができる。

コントロール実行アルゴリズム
クライアントサイドスクリプトまたはクライアントサイドモジュール（本明細書では「ＲｕｎＳｐｅｅｃｈ」と称する）が、図６のコントロールに関してクライアントデバイスに提供される。このスクリプトの目的は、ロジックを介してダイアログフローを実行するためであり、このロジックは、スクリプトがクライアントデバイス３０で実行される時、すなわち、コントロールに関係するマークアップがクライアントに含まれる値に起因してクライアントでの実行のためにアクティブ化される時に、スクリプトで指定される。このスクリプトは、ページ要求の間での複数のダイアログターンを可能にし、したがって、テレフォニブラウザ２１６を介するなど、ボイスのみダイアログのコントロールに特に役立つ。クライアントサイドスクリプトＲｕｎＳｐｅｅｃｈは、完成したフォームがサブミットされるか、新しいページが他の形でクライアントデバイス３０から要求されるまで、クライアントデバイス３０上でループの形で実行される。

一般に、一実施形態で、このアルゴリズムは、音声を出力し、ユーザ入力を認識することによって、ダイアログターンを生成する。このアルゴリズムの全体的なロジックは、ボイスのみシナリオについて、次の通りである（他の形で上で述べられていないプロパティまたはパラメータについては、特許出願（たとえば、特許文献１参照）を参照されたい）。
１．音声インデックス順で、第１のアクティブな（下で定義する）ＱＡコントロール、ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒコントロール、またはＣｕｓｔｏｍＶａｌｉｄａｔｏｒコントロールを見つける。
２．アクティブコントロールがない場合には、ページをサブミットする。
３．そうでない場合には、コントロールを実行する。

ＱＡは、次の場合に限ってアクティブと考えられる。
１．ＱＡのｃｌｉｅｎｔＡｃｔｉｖａｔｉｏｎＦｕｎｃｔｉｏｎが、存在しないかｔｒｕｅを返すかのいずれかであり、かつ、
２．Ａｎｓｗｅｒｓプロパティコレクションが空でない場合に、ＡｎｓｗｅｒｓのセットによってポイントされるすべてのＳｅｍａｎｔｉｃＩｔｅｍｓのＳｔａｔｅがＥｍｐｔｙであり、または、
３．Ａｎｓｗｅｒｓプロパティコレクションが空である場合に、Ｃｏｎｆｉｒｍアレイ内の少なくとも１つのＳｅｍａｎｔｉｃＩｔｅｍのＳｔａｔｅがＮｅｅｄｓＣｏｎｆｉｒｍａｔｉｏｎである。
しかし、ＱＡが、ｔｒｕｅのＰｌａｙＯｎｃｅを有し、そのＰｒｏｍｐｔが成功して実行された（ＯｎＣｏｍｐｌｅｔｅに達した）場合に、そのＱＡは、アクティブ化の候補ではない。

ＱＡは、次のように実行される。
１．これが、前のアクティブコントロールと異なるコントロールである場合には、プロンプトＣｏｕｎｔ値をリセットする。
２．Ｐｒｏｍｐｔカウント値を増分する。
３．ＰｒｏｍｐｔＳｅｌｅｃｔＦｕｎｃｔｉｏｎが指定されている場合には、その関数を呼び出し、返されたストリングをＰｒｏｍｐｔのｉｎｌｉｎｅＰｒｏｍｐｔにセットする。
４．Ｒｅｃｏオブジェクトが存在する場合には、それを開始する。このＲｅｃｏは、既にアクティブコマンド文法を含んでいなければならない。

Ｖａｌｉｄａｔｏｒ（ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒまたはＣｕｓｔｏｍＶａｌｉｄａｔｏｒのいずれか）は、次の場合にアクティブである。
１．ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅが、このバリデータによって妥当性検査されておらず、その値が変化している。

ＣｏｍｐａｒｅＶａｌｉｄａｔｏｒは、次のように実行される。
１．バリデータのＯｐｅｒａｔｏｒに従って、ＳｅｍａｎｔｉｃＩｔｅｍＴｏＣｏｍｐａｒｅまたはＶａｌｕｅＴｏＣｏｍｐａｒｅの値とＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅの値とを比較する。
２．このテストがｆａｌｓｅを返す場合には、ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅのテキストフィールドを空にし、プロンプトを再生する。
３．このテストがｔｒｕｅを返す場合には、このバリデータによって妥当性検査されたものとしてＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅをマークする。

ＣｕｓｔｏｍＶａｌｉｄａｔｏｒは、次のように実行される。
１．ＳｅｍａｎｔｉｃＩｔｅｍＴｏＶａｌｉｄａｔｅの値を用いてＣｌｉｅｎｔＶａｌｉｄａｔｉｏｎＦｕｎｃｔｉｏｎを呼び出す。
２．この関数がｆａｌｓｅを返す場合には、ｓｅｍａｎｔｉｃＩｔｅｍをクリアし、プロンプトを再生する。そうでない場合には、このバリデータによって妥当性検査される。

Ｃｏｍｍａｎｄは、次の場合に限ってアクティブと考えられる。
１．それがＳｃｏｐｅ内にあり、かつ、
２．スコープツリー内でより下に同一Ｔｙｐｅの別のＣｏｍｍａｎｄがない。

マルチモーダルの場合に、このロジックは、次のアルゴリズムに単純化される。
１．トリガするイベントすなわち、ユーザがコントロールをタップするのを待つ。
２．期待される回答を収集する。
３．入力を聴く。
４．結果をＳｅｍａｎｔｉｃＩｔｅｍにバインドする。結果がない場合には、イベントを送出する。
５．１に戻る。

マルチモーダル環境では、ユーザが結果のビジュアルプレゼンテーションに関連するテキストボックスまたは他の入力フィールドを訂正する場合に、このシステムが、値が確認されたことを示すために、関連するＳｅｍａｎｔｉｃＩｔｅｍを更新できることに留意されたい。

さらなる実施形態では、図６に示されているように、アプリケーション作成者がテレフォニトランザクションを処理する音声アプリケーションを作成することを可能にするｃａｌｌコントロール４０７、ならびに共通の音声シナリオを１つのコントロールにラップする手段を提供するａｐｐｌｉｃａｔｉｏｎコントロール４３０が設けられる。ｃａｌｌコントロール４０７およびａｐｐｌｉｃａｔｉｏｎコントロール４３０は、本発明の実線に必要ではなく、単に完全を期して言及されたものである。このそれぞれのさらなる議論は、特許出願（たとえば、特許文献１および特許文献２参照）で提供される。

ユーザ対話データの記録
例として前述の構造を使用することによって、アプリケーション開発者は、音声対応アプリケーションを開発することができる。しかし、本明細書で説明する諸態様は、開発者がユーザ対話データを記録しまたはロギングすることを可能にする。

それでも、本明細書で説明する概念は、ダイアログモデルを提供する、上で説明したダイアログオーサリング構造に限定されるのではなく、ミドルウェア、ＡＰＩ（アプリケーションプログラムインターフェース）または類似物として実装されるものなどであるがこれらに限定はされないダイアログモデルを生成する、下で説明する情報の一部またはすべてを記録するように構成された任意のオーサリングツールに適用できることを理解されたい。さらに、テレフォニアプリケーションなどの音声対応アプリケーションの機能的性質およびそのボイスユーザインターフェースの詳細は、ドメインおよびアプリケーションタイプにまたがって大きく異なる可能性があり、したがって、通常可能にされる任意の自動化ロギングは、ヒューリスティックに過ぎず、決定的ではない。この理由から、これの実装は、変更不能なプロパティではなく、オーバーライド可能なデフォルトとして自動化ログイベントプロパティを実装する可能性が高い。それでも、豊富な情報のロギングを単純化し、容易にすることは、手動オーサリングおよびプログラム的オーサリングに頼るシステムに対する大きい進歩である。

戻って図４を参照すると、ダイアログコントロール２１１に従って音声対応アプリケーションを実行するウェブサーバ２０２は、モバイルデバイス３０を介するアクセスまたは電話機８０を介するアクセスなどであるがこれらに限定されない任意のタイプのユーザのためにアプリケーションが実行される時に、ストア２１７にユーザ対話ログデータを記録する。

アプリケーションは、一般に、それほど排他的にではなく、本明細書で通常は必要に応じてＣｏｍｍａｎｄコントロール４０４、Ａｐｐｌｉｃａｔｉｏｎコントロール４３０、Ｃａｌｌコントロール４０７、ならびにバリデータ４０６および４０８と共にＱＡコントロール４０２によって例示される階層コントロールのセットとして定義され、または記述される。この階層は、完了されなければならない全体的タスクならびにその全体的タスクを完了するためのその全体的タスクのサブタスクを定義する。この階層内のレベルの個数は、アプリケーションの複雑さに依存する。たとえば、アプリケーションを、全体的に航空便予約に向ける（すなわち最上位タスク）ことができ、２つの主要なサブタスクは、出発情報および到着情報の入手に向けられる。同様に、さらなるサブタスクを、具体的には、出発／到着空港情報、出発／到着時刻などを入手するサブタスクを、出発情報の入手および到着情報の入手という主要なサブタスクのそれぞれについて定義することができる。これらのサブタスクは、それを含むタスク内のシーケンス内に現れるものとすることができる。

一般に、２タイプのデータすなわち、Ｔａｓｋ／ＤｉａｌｏｇデータおよびＴｕｒｎデータが記録される。Ｔａｓｋ／Ｄｉａｌｏｇデータから始めると、ログ内で表されるこのデータは、タスクおよびサブタスクに関するアプリケーションの階層構造またはシーケンシャル構造を取り込まなければならない。図７に、アプリケーションを作成する方法５００を示す。ダイアログオーサリングツールは、ステップ５０２で、ネストされたＴａｓｋ単位またはシーケンシャルＴａｓｋ単位に関してダイアログのオーサリングまたは定義を可能にし、その結果、開発者が音声対応アプリケーションを記述する時に、その作成者は、通常、その音声対応アプリケーションをモジュラの形で記述するようになる。すなわち、作成者は、個々のＴｕｒｎを特定のＴａｓｋを達成するセットにグループ化し、個々のタスクをより上位のＴａｓｋを達成するセットにグループ化することを奨励される。Ｔａｓｋ構造および個々のＴａｓｋに出入りするフローは、設計時に既知なので、ステップ５０４で、Ｔａｓｋに入ることまたはＴａｓｋから出ることのロギング（たとえば、ＴａｓｋＳｔａｒｔイベントおよびＴａｓｋＣｏｍｐｌｅｔｅイベントを介する）ならびにアプリケーションによって使用される入力フィールドに関してユーザから入手されるＴｕｒｎデータおよび値のロギング（本明細書では「セマンティックアイテム」として例示される）を可能にして、Ｔａｓｋ構造のシーケンスおよび／または階層の自動化ロギングを提供する。これは、ダイアログフロー、入手された値、およびＴａｓｋ構造を、イベントログから明示的に回復でき、構築できることを意味する。ステップ５０２および５０４が、これらのステップの特徴の一部またはすべてを異なる順序でまたは同時に実行できるという点で、例示のみを目的として別々に示されていることに留意されたい。

このデータは、任意の所与のタスクまたはサブタスクの完了の成功、失敗、または他（たとえば未知）という状況をも定量化する。さらに、Ｔａｓｋ／Ｄｉａｌｏｇデータは、タスクが不成功もしくは失敗の場合の理由、またはその完了状況が既知でない理由、または適用可能な場合に複数の理由が成功について可能である場合に成功の理由を含む。追加データには、ユーザが応答を供給しなかった場合または音声リコグナイザが発話を認識できなかった場合を示す進行状況データを含めることができる。プロンプトまたはユーザ応答に基づくかこれに関連する値に関してアプリケーションによって使用される入力フィールド値またはストレージロケーションのリスト、あるいは変化したその状況をも、記録することができる。

図８に、音声対応アプリケーションを実行する方法５２０を示す。方法５２０は、ステップ５２２で、１つまたは複数のＴｕｒｎを有するＴａｓｋに関して定義された音声対応アプリケーションを実行することを含む。ステップ５２４は、Ｔａｓｋ、Ｔｕｒｎ、およびセマンティックアイテムに関係する情報を記録することを含む。ステップ５２２および５２４が、これらのステップの特徴の一部またはすべてを異なる順序でまたは同時に実行できるという点で、例示のみを目的として別々に示されていることに留意されたい。

一実施形態で、Ｔａｓｋ／Ｄｉａｌｏｇデータは、次の情報の一部またはすべてを含む。
Ｔａｓｋ／Ｄｉａｌｏｇデータ
ｎａｍｅ：タスク／ダイアログの作成者定義のストリング識別子、たとえば「ｇｅｔＣｒｅｄｉｔＣａｒｄＩｎｆｏ」、「ＣｏｎｆｉｒｍＴｒａｖｅｌ」など。作成者が設計時に名前を供給しない場合には、たとえばＤｉａｌｏｇ１、Ｄｉａｌｏｇ２、ＤｉａｌｏｇＮ、…など、デフォルト名が与えられる。
ｐａｒｅｎｔ：含むダイアログの名前（ログからダイアログ階層を再構成するために）。
ＴａｓｋＳｔａｒｔ：Ｔａｓｋ／Ｄｉａｌｏｇに最初に入った時のタイムスタンプ。
ＴａｓｋＣｏｍｐｌｅｔｅ：Ｔａｓｋ／Ｄｉａｌｏｇから出た時のタイムスタンプ。このイベントは、デフォルト値を有するアプリケーションが閉じられる時のすべての開かれているダイアログについて、ボトムアップで必ず発火されなければならない（すなわち、ログに「オープンエンド」のダイアログはない）。
ｓｔａｔｕｓ：タスク／ダイアログの完了状況であり、作成者によってセット可能であり、ダイアログの実行に基づいて自動的に推論され、あるいは、作成者定義の条件に基づいて半自動的にセットされる。一実施形態で、デフォルト値状況を「ＵＮＳＥＴ」とすることができ、後続の値は、次のうちの１つとすることができる。
ＳＵＣＣＥＳＳ
ＦＡＩＬＵＲＥ
ＵＮＫＮＯＷＮ

自動タスク完了状況
ある種の場合に、上で示したように、状況を、タスク出口の性質から、その状況が成功、失敗、または未知のうちの１つであったかどうかを穏当な確かさで推論することができる。たとえば、エラーまたは例外の結果として終了するタスクを、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。同様に、キャンセルされたタスク（たとえば、Ｃａｎｃｅｌ（）がタスクオブジェクトに対して呼び出された場合）を、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。同様に、ある種の「ストライクアウト」（たとえば、下で述べるＭａｘＳｉｌｅｎｃｅｓまたはＭａｘＮｏＲｅｃｏ）カウントに達したの結果として終了するタスクを、Ｆａｉｌｕｒｅの完了状況と共に自動的にロギングすることができる。

対照的に、そのタスクで出会うまたは設計時にそのタスクに属するものとして指定されたＴｕｒｎのすべてのセマンティックアイテム（すなわち、アプリケーションの入力フィールド）が根拠のある（ユーザ入力またはそれから導出された）値を有する、自然に終了する（すなわち、キャンセルされていない）タスクは、Ｓｕｃｃｅｓｓの完了状況と共に自動的にロギングされる。

半自動化されたタスク完了
タスク状況ロギングの部分的自動化も、有用である。任意の所与のタスクについて、作成者は、満足された場合に出口の任意の点でのタスクの状況を決定する、タスクの成功または失敗に関する条件のセットをステップ５０２で指定しまたは定義することができる。これらの条件は、プログラム的（たとえば、ｆｏｏ＝＝’ｂａｒ’）とすることができ、あるいは、より役立つことに、作成者がタスクごとに１つまたは複数のセマンティックアイテム（たとえば、ｄｅｐａｒｔｕｒｅＣｉｔｙおよびａｒｒｉｖａｌＣｉｔｙについて提供される値）だけを指定する必要があるようになるように条件を単純化することができ、本システムは、これらのセマンティックアイテムが確認された値を有する時にＳｕｃｃｅｓｓを自動的にロギングし、オプションで、これらのセマンティックアイテムが確認された値を有しない時にＦａｉｌｕｒｅを自動的にロギングする。

この態様は、タスク状況ロギングがタスクからのすべての出口点でプログラム的にコーディングされる必要がないことを意味するので、有用な、時間を節約する機構である。その代わりに、条件は、エンドユーザがタスクを終了する時に、必ず自動的に評価され、状況が、判定され、余分な開発者コードなしでロギングされる。
ｒｅａｓｏｎ：作成者によってセットできる、ダイアログの完了の理由。たとえば、
Ｃｏｍｍａｎｄ − ダイアログの異なる部分に対して変更するためにユーザによって話されたコマンドおよびそのコマンドの性質（たとえば、「Ｃａｎｃｅｌ」、「Ｏｐｅｒａｔｏｒ」、「Ｍａｉｎ Ｍｅｎｕ」など）。
ｕｓｅｒＨａｎｇｕｐ − ユーザが、ハングアップするか、他の形で放棄するかあきらめた。
ａｐｐｌｉｃａｔｉｏｎＥｒｒｏｒ − アプリケーションエラーが発生した。
ｍａｘＮｏＲｅｃｏｓ − 認識に達することなく発話の最大回数に達した。
ｍａｘＳｉｌｅｎｃｅｓ − 無音ユーザ応答の最大回数に達した。

ＳｅｍａｎｔｉｃＵｐｄａｔｅ：
ｉｔｅｍｓ：新しい値および対応する状況を含む、その値／状況が変更されたすべてのセマンティックアイテムのリスト。通常、このデータは、各ダイアログターン（アプリケーションによるプロンプト／ユーザによる応答または応答の欠如）に関して、１つまたは複数のセマンティックアイテム値および／または状況が変化するという点で、下で述べるＴｕｒｎデータに相関される。しかし、いくつかの場合に、アプリケーションは、それ自体でセマンティックアイテムを変更することができる。たとえば、アプリケーションが、クレジットカード番号などの値を妥当性検査することができない場合に、そのアプリケーションは、必ずしもダイアログターンに基づくのではなく、それ自体でその値をクリアすることができる。それでも、そのような変更は記録されるはずである。

Ｔｕｒｎデータは、アプリケーションとの直接対話を含み、アプリケーションによって提供されるプロンプト（応答が期待されない場合）またはユーザ応答もしくはユーザ応答の欠如に相関されるアプリケーションプロンプト、言い換えると、プロンプト／応答交換、または必ずしもプロンプトに応答するのではなくユーザによって提供されるコマンド、または少なくともプロンプトに対する応答であると期待されない応答に基づいて編成される。したがって、記録され得るデータの３つの領域は、アプリケーションによって提供されるプロンプト、ユーザによって供給される応答（期待される応答であれ期待されない応答であれ）、およびシステムによって決定される認識結果に関係する情報を含む。一実施形態で、Ｔｕｒｎデータは、次の情報の一部またはすべてを含む。

Ｔｕｒｎデータ
ｃｏｎｆｉｇ
ｎａｍｅ：作成者定義のストリング識別子。作成者が設計時に名前を供給しない場合には、デフォルト名を与えることができる。しかし、同一のＤｉａｌｏｇ／Ｔａｓｋ内の異なるターンの間で明瞭かつ一貫して区別する必要がある。可能な技法は、プロンプトの名前およびタイプに基づくことである。
ｔｙｐｅ：特定のＴｕｒｎの目的の指定を、それに関連するセマンティックアイテムの性質から推論することができる。上の前述の説明の場合に、セマンティックアイテムは、Ａｎｓｗｅｒｓ、ＥｘｔｒａＡｎｓｗｅｒｓ、およびＣｏｎｆｉｒｍｓの概念を介してＴｕｒｎに関連する。
Ｔｕｒｎの目的の例には、次が含まれる。
新しい情報を求める（ＴｕｒｎはＡｎｓｗｅｒｓを使用可能にする）
関連情報を確認する（受け入れ／拒否、ＴｕｒｎはＣｏｎｆｉｒｍｓを使用可能にする）
情報ステートメントを与える（ＴｕｒｎはＡｎｓｗｅｒｓまたはＣｏｎｆｉｒｍｓを保持しない）。
ｐａｒｅｎｔ：含むＤｉａｌｏｇ／Ｔａｓｋの名前（ログからダイアログ階層を再構成するため）。
ｌａｎｇｕａｇｅ：使用される言語。
ｓｐｅｅｃｈ ｇｒａｍｍａｒｓ：どの音声認識文法が使用されているかに関する情報。
ＤＭＴＦ ｇｒａｍｍａｒｓ：どのＤＴＭＦ認識文法が使用されているかに関する情報。
ｔｈｒｅｓｈｏｌｄｓ：値の拒絶および／または値の確認に関する信頼性閾値。
ｔｉｍｅｏｕｔｓ：プロンプトに続く最初の無音について許容される時間期間、応答の終りを判定する終了無音、およびバブルと考えられる時間期間。

ｐｒｏｍｐｔ
ｎａｍｅ：オプション。ターンデータ名を使用できるという点で必要ではない場合がある。
ｔｙｐｅ：ダイアログモデルは、そのどれであってもアプリケーションによって選択することができ、それを使用することによってシステムが試みているものの記録を達成することを可能にする、複数の事前定義のプロンプトタイプすなわちＴｕｒｎの目的を含むことができる。
プロンプトタイプの例には、次が含まれる。
ＭａｉｎＰｒｏｍｐｔ − 質問をすること（またはステートメントを与えること）
ＨｅｌｐＰｒｏｍｐｔ − ヘルプを提供すること
ＲｅｐｅａｔＰｒｏｍｐｔ − 情報内容を繰り返すこと
ＮｏＲｅｃｏｇｎｉｔｉｏｎＰｒｏｍｐｔ − 「認識なし」に応答すること
ＳｉｌｅｎｃｅＰｒｏｍｐｔ − 無音に応答すること
ＥｓｃａｌａｔｅｄＮｏＲｅｃｏｇｎｉｔｉｏｎＰｒｏｍｐｔ − 複数の試行の後に「認識なし」に応答すること
ＥｓｃａｌａｔｅｄＳｉｌｅｎｃｅＰｒｏｍｐｔ − 複数の試行の後に無音に応答すること
これらのｔｙｐｅは、事前定義であり、任意の時の選択に使用可能なので、ｔｙｐｅによって自動的にロギングすることができ、これによって、Ｔｕｒｎの目的を達成するための所与のプロンプトの目的という概念を用いてログデータを自動的に豊かにする。
したがって、すべてがダイアログオーサリングモデルのプログラミングプリミティブであり、したがってアプリケーションが出会った時に自動的にロギングされる、Ｔｕｒｎタイプと組み合わされるプロンプトタイプは、ログ内の任意の点でのシステムの目的の豊かなビューを可能にする。
ｓｅｍａｎｔｉｃ ｉｔｅｍｓ：それに関するプロンプトを出される（質問／確認サイクルをリンクすることなどに使用される）セマンティックアイテム。
ダイアログモデルは、ダイアログフローに関してオーサリングを単純化するために、それぞれが値および状況を含むセマンティックアイテムという概念を使用する。すべてのセマンティックアイテムの変化する値および状況を自動的にロギングし、それをタスクおよびユーザ／システム移動情報と組み合わせることによって、ログが、さらに豊かにされる。
Ａｎｓｗｅｒｓ／ＥｘｔｒａＡｎｓｗｅｒｓ／Ｃｏｎｆｉｒｍｓモデルは、セマンティックアイテムをＴｕｒｎに、したがってＴａｓｋにリンクする。したがって、どのセマンティックアイテムがどのシステム移動およびユーザ移動に関係し、どのセマンティックアイテムがどのＴａｓｋに寄与するかがわかる（自動的にロギングすることができる）。
プロンプトのテキスト内容：たとえば「ｗｅｌｃｏｍｅ」。
ｂａｒｇｅｉｎ：オン／オフ／プロンプト中時間。
Ｕｓｅｒ Ｐｅｒｃｅｉｖｅｄ Ｌａｔｅｎｃｙ：ユーザの応答と次のプロンプトの再生との間の時間期間。システムが重い負荷の下にある時には、この時間期間がより長くなる場合があり、これは、アプリケーションが応答していないとユーザに思わせる可能性があるという点で、ユーザを混乱させる可能性がある。
ＴＴＳ：Ｔｒｕｅ／Ｆａｌｓｅ − テキスト−音声がプロンプトを生成するのに使用されていたかどうか。
プロンプト完了時間：プロンプトが完成された／中断された時間。
プロンプトｗａｖｅファイル：提供された実際のプロンプト。

ユーザ入力：
ｍｏｄｅ：ユーザがＤＴＭＦ／音声のどちらを提供しているか。
ｔｙｐｅ：ユーザがＣｏｍｍａｎｄを提供しているかどうか、および、そうである場合に、どのタイプ（たとえば、Ｈｅｌｐ／Ｒｅｐｅａｔ／など）か、または、ユーザがＲｅｓｐｏｎｓｅを提供しているかどうか、および、そうである場合に、どのタイプ（たとえば、Ａｎｓｗｅｒ／Ｃｏｎｆｉｒｍ／Ｄｅｎｙ）か。
ダイアログモデルは、アプリケーションの文法の機能を、応答を提供する際のユーザの目的を示すユーザ応答の異なるタイプすなわち、Ａｎｓｗｅｒ、Ａｃｃｅｐｔ、Ｄｅｎｙなどに分類する。これらのタイプは、ユーザが何を達成することを試みているとシステムが考えているかのインジケータとして直接にロギングすることができる。異なる応答タイプの例は、次の通りである。
Ａｎｓｗｅｒ − ユーザが、値を要求する質問に対する回答を提供した。
ＥｘｔｒａＡｎｓｗｅｒ − ユーザが、質問の焦点を越える回答を提供した。
Ａｃｃｅｐｔ − ユーザが、情報の１つを確認した。
Ｄｅｎｙ − ユーザが、情報の１つに異議を唱えた。
Ｈｅｌｐ Ｃｏｍｍａｎｄ − ユーザが、ヘルプを求めた。
Ｒｅｐｅａｔ Ｃｏｍｍａｎｄ − ユーザが、情報の繰り返しを要求した。
Ｏｔｈｅｒ Ｃｏｍｍａｎｄ − ユーザが、ある他の形のコマンドを発行した（明示的にタイプを指定されないが、我々は、それが上のタイプのどれでもないことを知っている）。
Ｓｉｌｅｎｃｅ − ユーザが、何も言わなかった（これは、時々、ある形の「暗黙の受け入れ」として使用される）。
これらのタイプは、特定の文法に関連するので、ユーザが対応する文法に一致する何かを言う時に、必ず、これらを自動的にロギングすることができる。多くのシステムは、単一のダイアログターンに複数のタイプを含めることを許容し、たとえば、複数のアイテムを受け入れること、または単一のターンで１つのアイテムに回答し、別のアイテムを受け入れることを許容する。
Ｓｉｌｅｎｃｅ：無音が検出される場合に、ＭａｘＳｉｌｅｎｃｅｓに対する相対的なその個数またはカウント。
ＮｏＲｅｃｏ：認識が発話について検出されない場合に、ＭａｘＮｏＲｅｃｏｓに対する相対的なその個数またはカウント。
Ｅｒｒｏｒ：エラーが発生した場合に、それがアプリケーションまたはプラットフォームによって送出されたかどうか。

ｒｅｓｕｌｔ：
Ｒｅｃｏｇｎｉｔｉｏｎ ｒｅｓｕｌｔ：システムによって返された認識結果。一般に、認識結果は、解釈された発話のセマンティックマークアップ言語（ＳＭＬ）タグを含む。さらに、Ｎ−Ｂｅｓｔ代替解釈を提供することができ、適当な場合にオーディオ記録結果を提供することができる。
さらに、解釈ごとに、
ＳＭＬタグなしの発話テキスト（音声が提供される場合）またはキー押下げ（ＤＴＭＦが提供される場合）。
ｃｏｎｆｉｄｅｎｃｅ：解釈の信頼性レベル。
ｓｅｍａｎｔｉｃ ｍａｐｐｉｎｇｓ：ＳＭＬ結果の諸部分とセマンティックアイテムとの間のリンク。言い換えると、ＳＭＬ結果からのどの値がどのセマンティックアイテムに置かれるか。
ｇｒａｍｍａｒ ｒｕｌｅ ｍａｔｃｈｅｄ：文法のどのルールがユーザ入力と一致したか。
ｃｏｎｆｉｄｅｎｃｅ：全体としての発話の信頼性。
ｂａｒｇｅｉｎ：ユーザによる会話への割込みのタイミングまたはＮＵＬＬ（会話への割込みが存在しない場合）。
認識ｗａｖｅファイル：実際に記録されたユーザ入力またはそれへのポインタ。

要約すると、ロギングされるユーザ対話データは、ダイアログを、関心を持たれているあるフィールド（たとえば、フォームフィールドまたはスロット値）を操作するタスクの階層構造またはシーケンシャル構造とみなすことを可能にし、タスク内の各ダイアログターンは、フォームフィールドに関するシステム目的（ダイアログ移動）（たとえば、値に関する質問、値の確認、値の繰り返しなど）と、音声リコグナイザがユーザ目的と考えているもの（たとえば、値の供給、値の拒否、ヘルプの要求など）との両方をロギングする。

実用的な利益が、この構造を用いて実現される。具体的に言うと、システム性能の分析は、成功または失敗のいずれかのタスク完了が、一般に明示的であり、したがって、トランザクション的成功レート報告が、非常に単純化され、タスクを完了するのに要するダイアログステップの性質が、よりよく理解される（各ステップの背後にある目的がオーサリング時に既知なので）という点で、改善される。

この形のデータロギングの実装は、これがダイアログオーサリングツールに組み込まれる形に起因して、簡単である。この計測の高水準の性質は、さまざまなアプリケーションタイプに一般的であり、ロギングの実際の詳細は、概念的にとロギングプリミティブに関してとの両方でこれがオーサリングツールに統合されることによって、オーサリング時に容易にされる。したがって、アプリケーション作成者は、タスク／サブタスクモデルを使用してアプリケーションを構造化し、タスクから出るどの遷移が成功の完了を示すかを示すことを奨励され、システム／ユーザ目的ロギングがダイアログターンオーサリングモデルに組み込まれるので、システム／ユーザ目的ロギングを明示的に計測する必要がなくなる。

上では、主題を、特定の実施形態を参照して説明したが、当業者は、添付の特許請求の範囲の趣旨および範囲から逸脱せずに、形態および詳細において変更を行えることを認めるであろう。

コンピューティングデバイスオペレーティング環境の第１実施形態を示す平面図である。 図１のコンピューティングデバイスを示すブロック図である。 汎用コンピュータを示すブロック図である。 クライアント／サーバシステムのアーキテクチャを示すブロック図である。 クライアントサイドマークアップ内で認識および可聴コンピューティングを提供する手法を示すブロック図である。 コンパニオンコントロールを示すブロック図である。 音声対応アプリケーションを作成する方法を示す流れ図である。 音声対応アプリケーションを実行する方法を示す流れ図である。

Claims (20)

1. コンピュータシステムで実行される音声対応アプリケーションでユーザ対話データをロギングするコンピュータ実施される方法（５２０）であって、
   前記コンピュータシステム上のタスクに関して定義される音声対応アプリケーションを実行すること（５２２）であって、タスクは、１つまたは複数のターンを含み、ターンは、前記音声対応アプリケーションによってユーザに提供されるプロンプトと、前記音声対応アプリケーションによって前記ユーザに提供されるプロンプトおよびそれに続く前記ユーザからの応答を含むプロンプト／応答交換とのうちの少なくとも１つを含む、実行すること（５２２）と、
   （ａ）前記アプリケーションで実行されるタスクの完了と、（ｂ）めいめいのタスクに対する相対的な対応するターンの目的と、（ｃ）前記ユーザからの応答の認識に関して変化する前記アプリケーション内で使用される値の表示とのうちの少なくとも２つを示す情報を記録すること（５２４）と
   を含むことを特徴とするコンピュータ実施される方法（５２０）。
2. 前記音声対応アプリケーションを実行すること（５２２）は、前記タスク階層構造で定義される、前記音声対応アプリケーションを実行することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
3. 各ターンの前記目的を示す情報を記録すること（５２４）は、ターンの前記目的が、前記音声対応アプリケーションが質問をすること、回答を確認すること、前記ユーザにヘルプを提供すること、およびプロンプトを繰り返すことのうちの少なくとも１つを含むかどうかを記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
4. 前記めいめいのタスクに対する相対的な各ターンに関する情報を記録すること（５２４）は、前記プロンプトがどの入力フィールドに関連するかに関する情報を記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
5. 前記めいめいのタスクに対する相対的な各ターンに関する情報を記録すること（５２４）は、前記応答がどの入力フィールドに関連するかに関する情報を記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
6. 各ターンの前記目的を示す情報を記録すること（５２４）は、ターンの前記目的が、ユーザがコマンドを提供すること、回答を提供すること、確認を受け入れること、および確認を拒否することのうちの少なくとも１つを含むかどうかを記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
7. 前記めいめいのタスクに対する相対的な各ターンに関する情報を記録すること（５２４）は、前記音声対応アプリケーションによって提供されるプロンプト、前記プロンプトに応答して前記ユーザによって提供される応答、および前記応答に関する音声リコグナイザによる認識結果に関する情報を記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
8. タスクの完了を示す情報を記録すること（５２４）は、成功、失敗、または未知の完了状況値のうちの１つを示す情報を記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
9. タスクの完了を示す情報を記録すること（５２４）は、前記タスクに関係するダイアログの完了の理由を示す情報を記録することを含むことを特徴とする請求項１に記載のコンピュータ実施される方法（５２０）。
10. 音声対応アプリケーションを作成する命令を有するコンピュータ可読媒体であって、前記命令は、
    コンピュータシステム上の階層構造内のタスクに関して音声対応アプリケーションを定義すること（５０２）と、
    前記階層構造に対して相対的に前記アプリケーション内で実行されるタスクの完了を示す情報の記録を可能にすること（５０４）と
    を含むことを特徴とするコンピュータ可読媒体。
11. 定義すること（５０２）は、１つまたは複数のターンを使用するタスクを定義することを含み、ターンは、前記音声対応アプリケーションによってユーザに提供されるプロンプトと、前記音声対応アプリケーションによって前記ユーザに提供されるプロンプトおよびそれに続く前記ユーザからの応答を含むプロンプト／応答交換とのうちの少なくとも１つを含み、情報の前記記録を可能にすることは、対応するタスクに対して相対的に１つまたは複数のターンを示す情報の記録を可能にすることを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
12. めいめいのタスクに対する相対的な各ターンに関する情報の前記記録を可能にすること（５０４）は、各ターンの目的を示す情報の記録を可能にすることを含むことを特徴とする請求項１０に記載のコンピュータ可読媒体。
13. 各ターンの前記目的を示す情報の前記記録を可能にすること（５０４）は、ターンの前記目的が、前記音声対応アプリケーションが質問をすること、回答を確認すること、前記ユーザにヘルプを提供すること、およびプロンプトを繰り返すことのうちの少なくとも１つを含むかどうかを記録することを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
14. 各ターンの前記目的を示す情報の前記記録を可能にすること（５０４）は、ターンの前記目的が、ユーザがコマンドを提供すること、回答を提供すること、確認を受け入れること、および確認を拒否することのうちの少なくとも１つを含むかどうかの記録を可能にすることを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
15. 各ターンに関する情報の前記記録を可能にすること（５０４）は、前記音声対応アプリケーションによって提供されるプロンプト、前記プロンプトに応答して前記ユーザによって提供される応答、および前記応答に関する音声リコグナイザによる認識結果に関する情報の記録を可能にすることを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
16. 前記めいめいのタスクに対する相対的な各ターンに関する情報の前記記録を可能にすること（５０４）は、前記プロンプトがどの入力フィールドに関連するかに関する情報の記録を可能にすることを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
17. 前記めいめいのタスクに対する相対的な各ターンに関する情報の前記記録を可能にすること（５０４）は、前記応答がどの入力フィールドに関連するかに関する情報の記録を可能にすることを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
18. 音声対応アプリケーションを作成する命令を有するコンピュータ可読媒体であって、前記命令は、
    コンピュータシステム上のタスクに関して音声対応アプリケーションを定義すること（５０２）であって、タスクは、１つまたは複数のターンを含み、ターンは、前記音声対応アプリケーションによってユーザに提供されるプロンプトと、前記音声対応アプリケーションによって前記ユーザに提供されるプロンプトおよびそれに続く前記ユーザからの応答を含むプロンプト／応答交換とのうちの少なくとも１つを含む、定義すること（５０２）と、
    前記音声対応アプリケーションの実行中に、前記１つまたは複数のターンのそれぞれに関するユーザおよびシステムの目的を示し、（ａ）前記アプリケーション内で実行されるタスクの完了および（ｂ）前記ユーザからの応答の認識に関して変化する前記アプリケーション内で使用される値の表示のうちの少なくとも１つに関連する情報の記録を可能にすること（５０４）と
    を含むことを特徴とするコンピュータ可読媒体。
19. タスクの完了を示す情報の前記記録を可能にすること（５０４）は、成功、失敗、または未知の完了状況値のうちの１つを示す情報の記録を可能にすることを含むことを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 情報の前記記録を可能にすること（５０４）は、プロンプトがどの入力フィールドに関連するかに関する情報の記録および応答がどの入力フィールドに関連するかに関する情報の記録を可能にすることを含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。

Images