(57)【要約】【課題】Webサーバで認識および/または可聴プロンプト機能を備えるクライアントサイドマークアップを生成するためのコントロールを提供する。【解決手段】これらのコントロールは、質問、応答、確認、コマンド、またはステートメントなどのダイアログの要素を備える。コントロール内で伝達される情報を利用して、モジュールによりダイアログを形成する。【選択図】図１０
2009059378.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ上で実行したときに、クライアント／サーバシステムにおけるクライアント用にクライアントサイドのマークアップ言語コードを生成する命令を格納するコンピュータ読み取り可能な記録媒体であって、前記命令は、
クライアントからリモートにあるサーバ上で使用されるように、かつウェブサイトについての認証ページにおけるダイアログを定義し、使用されると当該ダイアログにしたがって動的にクライアントサイドのマークアップ言語コードを生成するように構成されたコントロールのセットであって、該コントロールのセットは少なくとも、質問の可聴プロンプトに関するマークアップ言語コードを生成する質問コントロールと認識用の文法に関係するマークアップ言語コードを生成する応答コントロールとを含み、前記コントロールのセットにおけるそれぞれのコントロールが、関連する他のコントロールをアクティブ化することができるかどうかを示す属性を持ち、前記コントロールのセットにおけるコントロールは階層構造で配列され、前記ダイアログを定義するために異なる値を有する属性とともに繰り返し使用される、そのようなコントロールのセットと、
前記サーバ上で実行されたとき、前記認証ページ内の前記コントロールから直接提供された前記属性を使用して、アクティブ化されたコントロールに応じた前記ダイアログに基づいたクライアントサイドのマークアップ言語コードを生成するモジュールと、
前記クライアント上で使用されるように構成されたモジュールであって、前記クライアントで実行されたとき、前記クライアントサイドのマークアップ言語コードを使用して、アクティブ化されたコントロールに応じた前記ダイアログを生成するモジュールとを備えたことを特徴とする、コンピュータ読み取り可能な記録媒体。
【請求項２】
前記質問コントロールは、前記応答コントロールをアクティブ化することを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
【請求項３】
前記コントロールは、前記マークアップ言語コード内のナビゲーション、タスクのヘルプ、および可聴プロンプト機能の繰り返しの１つに対する文法に関係するマークアップ言語コードを生成するコマンドコントロールを含むことを特徴とする請求項２に記載のコンピュータ読み取り可能な記録媒体。
【請求項４】
前記コントロールは、認識された結果が正しいことを確認することに関係するマークアップ言語コードを生成する確認コントロールを含むことを特徴とする請求項３に記載のコンピュータ読み取り可能な記録媒体。
【請求項５】
前記確認コントロールは前記認識された結果の信頼度レベルまたは受信した結果に応じてアクティブにされることを特徴とする請求項４に記載のコンピュータ読み取り可能な記録媒体。
【請求項６】
前記応答コントロールは前記認識された結果の信頼度レベルに関係する属性を含むことを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
【請求項７】
前記確認コントロールは受理コントロールをアクティブ化して前記認識された結果を受け入れることを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
【請求項８】
前記確認コントロールは、否認コントロールをアクティブ化して前記認識された結果を否認することを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
【請求項９】
前記確認コントロールは、訂正コントロールをアクティブ化し、前記認識された結果を訂正することを特徴とする請求項５に記載のコンピュータ読み取り可能な記録媒体。
【請求項１０】
前記応答コントロールは、認識された結果を前記コントロールのセットのうちの１つと関連付けるメカニズムを備えたことを特徴とする請求項２に記載のコンピュータ読み取り可能な記録媒体。
【請求項１１】
前記メカニズムは前記認識された結果をバインドすることを備えたことを特徴とする請求項１０に記載のコンピュータ読み取り可能な記録媒体。
【請求項１２】
前記メカニズムはバインドの動作に関係するイベントを発行することを含むことを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
【請求項１３】
前記コントロールのセットをコントロールの第１のセットとし、クライアント上の視覚的レンダリングに関係するマークアップ言語コードを生成するコントロールの第２のセットをさらに備え、前記コントロールの第１のセットにおけるそれぞれのコントロールを、前記コントロールの第２のセットにおける該コントロールのうちの少なくとも１つと関連付けることを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】
コンピュータ上で実行したときに、ダイアログを定義する命令を格納するコンピュータ読み取り可能な記録媒体であって、前記命令は、
クライアントからリモートにあるサーバ上で使用されるように、かつウェブサイトについての認証ページにおけるダイアログを定義するように構成されたコントロールのセットであって、該コントロールのセットは少なくとも質問の可聴プロンプトの生成に直接関連する属性を有する質問コントロールと認識用の文法の使用に直接関連する属性を有する応答コントロールとを含み、認識用の文法の使用に直接関連する属性は認識用の文法の位置および認識のための信頼度レベルの閾値の少なくとも一つを含み、前記質問の可聴プロンプトの生成に直接関連する属性は、テキスト音声変換用のインラインテキスト、および予め録音された音声ファイルの可聴出力用および可聴再生用のデータの位置の少なくとも一つを含み、前記コントロールは、前記コントロールのセットのそれぞれのコントロールが関連する他のコントロールをアクティブ化することができるかどうかを示す属性を持ち、前記ダイアログを定義するために異なる値を有する属性とともに繰り返し使用される、そのようなコントロールのセットと、
前記サーバ上で実行されたとき、前記認証ページ内の前記コントロールから直接提供された前記属性を使用し、アクティブ化されたコントロールに応じた前記ダイアログに基づいたマークアップ言語コードを生成するモジュールであって、ネットワークを介してリモートにある前記クライアントへ送信される前記マークアップ言語コード内に認識および可聴プロンプトに直接関連する前記属性を取り入れることにより前記マークアップ言語コードを生成する、そのようなモジュールとを備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記質問コントロールは、前記応答コントロールをアクティブ化することを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１６】
前記コントロールは、前記マークアップ言語コード内のナビゲーション、タスクのヘルプ、および可聴プロンプト機能の繰り返しの１つに対する文法に関係するコードを生成するコマンドコントロールを含むことを特徴とする請求項１５に記載のコンピュータ読み取り可能な記録媒体。
【請求項１７】
前記コントロールは、認識された結果が正しいことを確認することに関係するコードを生成する確認コントロールを含むことを特徴とする請求項１６に記載のコンピュータ読み取り可能な記録媒体。
【請求項１８】
前記確認コントロールは前記認識された結果の信頼度レベルまたは受信した結果に応じてアクティブにされることを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項１９】
前記応答コントロールは前記認識された結果の信頼度レベルに関係する属性を含むことを特徴とする請求項１８に記載のコンピュータ読み取り可能な記録媒体。
【請求項２０】
前記確認コントロールは受理コントロールをアクティブ化して前記認識された結果を受け入れることを特徴とする請求項１８に記載のコンピュータ読み取り可能な記録媒体。
【請求項２１】
前記確認コントロールは、否認コントロールをアクティブ化して前記認識された結果を否認することを特徴とする請求項１８に記載のコンピュータ読み取り可能な記録媒体。
【請求項２２】
前記確認コントロールは、訂正コントロールをアクティブ化し、前記認識された結果を訂正することを特徴とする請求項１８に記載のコンピュータ読み取り可能な記録媒体。
【請求項２３】
前記応答コントロールは、認識された結果を前記コントロールのセットのうちの１つと関連付けるメカニズムを備えたことを特徴とする請求項１５に記載のコンピュータ読み取り可能な記録媒体。
【請求項２４】
前記メカニズムはバインドの動作に関係するイベントを発行することを含むことを特徴とする請求項２３に記載のコンピュータ読み取り可能な記録媒体。
【請求項２５】
前記コントロールのセットをコントロールの第１のセットとし、クライアント上の視覚的レンダリングに関係するマークアップ言語コードを生成するコントロールの第２のセットをさらに備え、前記コントロールの第１のセットにおけるそれぞれのコントロールを、前記コントロールの第２のセットにおける該コントロールのうちの少なくとも１つと関連付けることを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項２６】
認識および可聴プロンプト機能の少なくとも一方を、クライアント／サーバシステムにおけるクライアント上で実行するコンピュータに実装された方法であって、
コントロールのセットを用いてウェブサイトについての認証ページにおけるダイアログを定義するステップであって、前記コントロールのセットは、少なくとも質問の可聴プロンプトの生成に直接関連する属性を有する質問コントロールと認識用の文法の使用に直接関連する属性を有する応答コントロールとを含み、認識用の文法の使用に直接関連する属性は認識用の文法の位置および認識のための信頼度レベルの閾値の少なくとも一つを含み、前記質問の可聴プロンプトの生成に直接関連する属性は、テキスト音声変換用のインラインテキスト、および予め録音された音声ファイルの可聴出力用および可聴再生用のデータの位置の少なくとも一つを含み、前記コントロールのセットにおけるそれぞれのコントロールは、関連する他のコントロールをアクティブ化することができるかどうかを示す属性をさらに持ち、前記コントロールのセットにおけるコントロールは階層構造で配列され、前記ダイアログを定義するために異なる値を有する属性とともに繰り返し使用される、そのようなダイアログを定義するステップと、
前記クライアントからリモートにあるサーバで、前記認証ページ内の前記コントロールにしたがってマークアップ言語コード内に認識および可聴プロンプトに直接関連する属性を取り込むことにより、クライアントサイドのマークアップ言語コードを動的に生成するステップと、
前記クライアントで、前記クライアントサイドのマークアップ言語コードを受信し、アクティブ化されたコントロールに関連した前記クライアントサイドのマークアップ言語コードの実行に応じて前記クライアント上で前記ダイアログを生成するステップと
を備えることを特徴とする方法。
【請求項２７】
前記ダイアログを作成することは、前記質問コントロールを介して前記応答コントロールをアクティブ化することを含むことを特徴とする請求項２６に記載のコンピュータに実装された方法。
【請求項２８】
前記コントロールのセットは、前記マークアップ言語内のナビゲーション、タスクのヘルプ、および可聴プロンプトの繰り返しの１つに対する文法に関係するコードを生成するコマンドコントロールを含むことを特徴とする請求項２７に記載のコンピュータに実装された方法。
【請求項２９】
前記コントロールのセットは、認識された結果が正しいことを確認する操作に関係するコードを生成する確認コントロールを含むことを特徴とする請求項２８に記載のコンピュータに実装された方法。
【請求項３０】
前記ダイアログを作成するステップは、前記認識された結果の信頼度レベルに応じた前記確認コントロールのアクティブ化を含むことを特徴とする請求項２９に記載のコンピュータに実装された方法。
【請求項３１】
前記コントロールのセットをコントロールの第１のセットとし、クライアント上の視覚的レンダリングに関係するマークアップ言語コードを生成するコントロールの第２のセットをさらに備え、前記コントロールの第１のセットにおけるそれぞれのコントロールを、前記コントロールの第２のセットにおける該コントロールのうちの少なくとも１つと関連付けるステップをさらに含むことを特徴とする請求項２６に記載のコンピュータに実装された方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、特定のアプリケーションを実行するようにコンピュータをエンコードする(encoding)機能に関するものである。より具体的には、本発明は、認識および/または可聴プロンプト機能(audible prompting)に対応するクライアントサイドマークアップ(client side markup)を生成するサーバなどの認識および/または可聴プロンプト機能を実行するアプリケーションを定義するためのコントロールに関するものである。
【背景技術】
【０００２】
パーソナルデジタルアシスタント(PDA)、デバイス、および携帯電話などの小型コンピューティングデバイスは、人々の毎日の活動でますます頻繁に使用されるようになってきている。これらのデバイスを実行するために使用されるマイクロプロセッサの処理能力が向上したことにより、これらのデバイスの機能も高まり、統合されるケースも出てきた。たとえば、多くの携帯電話は、インターネットへのアクセスおよびブラウズに使用できるだけでなく、住所、電話番号などの個人情報を記憶するのにも使用することができる。
【０００３】
これらのコンピューティングデバイスがインターネットのブラウズに使用されたり、他のサーバ/クライアントアーキテクチャで使用されていたりすることを考えると、情報をコンピューティングデバイスに入力するという作業が必要である。残念なことに、携帯しやすさの面からこれらのデバイスをできる限り小型にすることが望まれているため、すべてのアルファベット文字を別々のボタンに割り当てた従来のキーボードは、コンピューティングデバイスの筐体上の有効面積が限られているせいで、通常、使用することができない。
【０００４】
このような問題に対処しようと、インターネットなどのワイドエリアネットワーク上での情報アクセスに音声を利用する技術に対する関心が高まり、そのような技術が採用されることが多くなってきた。たとえば、VoiceXML(音声拡張可能マークアップ言語(voice extensible markup language))などを使用する音声ポータル(voice portals)が進歩し、電話だけでインターネットコンテンツにアクセスできるようになっている。このアーキテクチャでは、ドキュメントサーバ(document server)(たとえば、Webサーバ)がVoiceXMLインタプリタを通じてクライアントからの要求を処理する。Webサーバは、応答としてVoiceXMLドキュメントを出力し、これを、VoiceXMLインタプリタが処理し、音声にレンダリング(rendering)してユーザに伝える。音声認識による音声コマンドを使用することで、ユーザはWebをナビゲートすることができる。
【０００５】
一般に、「音声対応(speech enabling)」情報またはWebコンテンツには2つの手法がある。第1の手法では、ディスプレイを備えたデバイスにより通常レンダリングされる既存の視覚的なマークアップ言語ページを解釈し、聴覚向けにレンダリングする。ただし、この方式では、視覚的対話操作を意図したページに、実用にかなった聴覚的ダイアログを自動的に生成するのに十分な情報が用意されていない。さらに、音声対話操作は誤りがちであり、特に、電話などの雑音の多いチャネルでは誤りが多い。視覚的形式またはその他の形式の永続的フィードバックがないと、Webサーバアプリケーションによるナビゲーションはユーザにとって極めて難しい操作になる可能性がある。この方式では、したがって、Webサイトのナビゲートを手助けするためユーザの聴覚用にレンダリングされるヘルプメッセージなどのメカニズムが必要である。これらのメカニズムは、一般に、「音声ダイアログ」と呼ばれ、たとえば、音声による対する応答として、ユーザが正しくない情報を提供したりあるいは何も情報を提供しなかったときのエラーを処理する必要もある。このメカニズムはWebページの視覚的コンテンツに一般には基づいていないので、自動的に生成することはできず、そのため、通常、アプリケーション開発者は長い開発時間を必要とする。
【０００６】
音声対応をWebコンテンツに対する第2の方法として、特定の音声ページを新しい言語で作成するという方法がある。この方式の利点として、音声対応ページに修復やナビゲーションヘルプなどの音声ダイアログに必要なすべてのメカニズムを備えられるという点が挙げられる。しかし、アプリケーションロジックを視覚的コンテンツページの場合と同じように含めるためにアプリケーションページを改造する必要があるという大きな欠点がある。つまり、視覚的コンテンツページのアプリケーションロジックは、音声対応言語の形式で書き換える必要があるということである。このプロセスを、同じ仕様から視覚的ページと音声ページとを作成するツールを使用して自動化できるとしても、視覚的ページと音声対応ページの保守を同期させることは通常、困難である。さらに、この方式では、たとえば、視覚的対話操作と音声対話操作がWebページ上に用意されている場合にマルチモードアプリケーション(multimodal applications)を簡単に実現できない。視覚的ページと音声対応ページは関連性がないため、入力ロジックと出力ロジックを連携するように調整することは容易でない。
【０００７】
現在まで、音声対話操作は、インターフェースとして現在採用されている構成または形式のせいで扱いにくいものとなっている。一般に、音声インターフェースは、アプリケーションのビジネスロジックとの結びつきが強すぎる傾向があり、他のアプリケーションでその音声インターフェースの要素を再利用することが妨げられていたり、単純化されたダイアログモデルのため音声インターフェースの制限が大きすぎたりするのである(たとえば、フォームやフィールド)。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、インターネットなどでサーバ/クライアントアーキテクチャなどのアプリケーションにより音声認識機能を提供するために使用されるアーキテクチャおよび方法に対する改善が引き続き要求されている。特に、前記の欠点の1つ、複数、またはすべてを解消し、それによりアプリケーションで音声対応認識および/または音声対応のプロンプト機能(prompting)の生成を実現する方法、システム、またはオーサリングツールが必要である。
【課題を解決するための手段】
【０００９】
Webサーバで認識および/または可聴プロンプト機能を備えるクライアントサイドマークアップを生成するためのコントロールを提示する。コントロールは、質問、応答、確認、コマンド、またはステートメントなどのダイアログの要素から成り立っている。これらのコントロールで伝達される情報利用することでダイアログをモジュール形式にする。
【００１０】
コントロールのそれぞれは、ダイアログ内である役割(role)を実行する。たとえば、ステートメントコントロールを使用して、クライアントデバイスの対応するマークアップを生成し、ユーザに情報を表示する一方で、質問コントロールによりクライアントデバイスが質問を行うためのマークアップ(markup)を生成する。応答コントロールにより、認識に使用される文法を尋ねられた質問に関係する入力フィールドと関連付けるようにクライアントデバイスのマークアップを生成する。認識された結果が正しいかどうか不明な場合、確認コントロールを起動し、認識された結果を確認するためのマークアップを生成することができる。コマンドコントロールでは、ユーザが特定の質問に対する予期される応答以外のコマンドを提供できるようにし、またユーザがたとえばWebサーバアプリケーションを通じてナビゲートできるようにするマークアップを生成する。コントロールはそれぞれ、関連するコントロールが起動できるかどうかを示す属性を含む。モジュールは、クライアントなどで実行されると、起動されるコントロールの機能として情報を求め、提供するためのダイアログを作成する。
【発明を実施するための最良の形態】
【００１１】
Webベースの認識機能のアーキテクチャおよびそのアーキテクチャを実装する方法を説明する前に、このアーキテクチャで機能するコンピューティングデバイスについて一般的に説明しておくと役立つであろう。図1を参照すると、データ管理デバイス(PIM、PDAなど)の実施例が示されている。しかし、本発明は後述の他のコンピューティングデバイスを使用しても実践することができ、とりわけ、入力ボタンなどの表面領域が限られているコンピューティングデバイスを使用して実践することができることが予期される。たとえば、電話および/またはデータ管理デバイスも本発明を活用することができる。このようなデバイスは、既存の携帯型個人情報管理デバイスやその他の携帯型電子デバイスと比較してユーティリティ機能が向上しており、このようなデバイスの機能およびコンパクトなサイズのおかげで、ユーザはこのようなデバイスを常時持ち歩く気になる可能性が高い。したがって、本発明で説明しているアーキテクチャの範囲が説明しているデータ管理またはPIMデバイス例、電話、またはコンピュータの開示により制限されることを意図していない。
【００１２】
データ管理モバイルデバイスの実施例が図1に示されている。モバイルデバイスは、ハウジング32を含み、タッチパネルとスタイラス33を使用する、ディスプレイ34を含むユーザインターフェースを備える。スタイラス３３を使用して、ディスプレイ34の指定された座標のところを押すか、またはそこに接触することで、フィールドを選択したり、カーソルの開始位置を選択的に移動したり、または身振りや手書きなどのその他の手段によりコマンド情報を伝える。それとは別に、またはそれに加えて、1つまたは複数のボタン35をナビゲーション用にデバイスに備えることもできる。さらに、回転可能なホイール、ローラなどの他の入力メカニズムも備えることができる。ただし、本発明はこのような形式の入力メカニズムにより制限することを意図していないことに注意されたい。たとえば、他の形式の入力として、コンピュータビジョンを備えることもできる。
【００１３】
図2を参照すると、ブロック図にモバイルデバイス30からなる機能コンポーネントが示されている。中央処理装置(CPU)50より、ソフトウェア制御機能が実行される。CPU 50がディスプレイ34に結合されており、制御ソフトウェアに従って生成されるテキストおよびグラフィックアイコンがディスプレイ34に表示される。スピーカを通常、デジタル-アナログコンバータでCPU 50に結合し、可聴出力を送ることができる。ユーザがモバイルデバイス30にダウンロードまたは入力したデータは、CPU 50に双方向結合されている不揮発性の読み書きランダムアクセスメモリストア54に格納される。ランダムアクセスメモリ(RAM)54は、CPU 50によって実行される命令を格納する揮発性の記憶装置であり、またレジスター値などの一時的データのための記憶装置でもある。構成オプションおよびその他の変数用の既定値は、読み取り専用メモリ(ROM)58に格納される。ROM 58は、モバイル30の基本機能およびその他のオペレーティングシステムのカーネル機能(たとえば、ソフトウェアコンポーネントをRAM 54にロードする機能)を制御するデバイス用のオペレーティングシステムソフトウェアを格納するのにも使用できる。
【００１４】
RAM 54はさらに、アプリケーションプログラムを格納するために使用されるPC上のハードディスクドライブの機能に似た方法でコードを格納するのにも使用される。不揮発性メモリは、コードを格納するために使用されるが、それとは別に、コードの実行には使用されない揮発性メモリ内に格納できることに注意されたい。
【００１５】
CPU 50に結合されている無線トランシーバ52を介してモバイルデバイスによって無線信号を送受信することができる。オプションの通信インターフェース60も、コンピュータ(たとえば、デスクトップコンピュータ)から直接、または必要ならば有線ネットワークから、データをダウンロードするために備えることができる。したがって、インターフェース60は、たとえば、赤外線リンク、モデム、ネットワークカードなどのさまざまな形態の通信デバイスを備えることができる。
【００１６】
モバイルデバイス30は、マイク29、およびアナログ-デジタル(A/D)コンバータ37、およびストア54に格納されているオプションの認識プログラム(音声、DTMF、手書き、身振り、またはコンピュータビジョン)を備える。たとえば、デバイス30のユーザからの可聴情報、命令、またはコマンドに応答して、マイク29で、A/Dコンバータ37によりデジタイズされた音声信号を送る。音声認識プログラムは、デジタイズした音声信号に対し正規化および/または特徴抽出機能を実行して、中間音声認識結果を得ることができる。無線トランシーバ52または通信インターフェース60を使用して、音声データを後述のリモート認識サーバ204に送信するが、これは、図4のアーキテクチャに示されている。その後、認識結果はモバイルデバイス30に返され、そこでレンダリング(たとえば、視覚的および/または可聴)を行い、最後にWebサーバ202(図4)に送信するが、Webサーバ202とモバイルデバイス30はクライアント/サーバ関係で動作する。類似の処理を他の形式の入力にも使用できる。たとえば、手書き入力は、デバイス30上での前処理を行って、または行わずにデジタイズすることができる。音声データのように、この形式の入力を認識サーバ204に送って認識させ、その後、認識結果をデバイス30および/またはWebサーバ202のうち少なくとも1つに返す。同様に、DTMFデータ、身振りデータ、および視覚的データも似た方法で処理できる。入力の形式に応じて、デバイス30(および後述のその他の形式のクライアント)は視覚的に入力用のカメラなどの必要なハードウェアを備える。
【００１７】
上記の携帯型またはモバイルコンピューティングデバイスに加えて、本発明は一般的なデスクトップコンピュータなどの他の多数のコンピューティングデバイスとともに使用できることも理解されるであろう。たとえば、本発明を使用すると、身体能力に制限のあるユーザにとってフルキーボードなどの従来の他の入力デバイスの操作が難しすぎるときでもテキストをコンピュータまたはその他のコンピューティングデバイスに入力することができる。
【００１８】
本発明は、さらに、他の多数の汎用または専用コンピューティングシステム、環境、または構成で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および/または構成の例として、無線または携帯電話、通常の電話(画面なし)、パソコン、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能家電製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上記システムのどれかを含む分散コンピューティング環境などがある。
【００１９】
以下では、図3に示されている汎用コンピュータ120について簡単に説明する。ただし、コンピュータ120もまた適当なコンピューティング環境の一実施例にすぎず、本発明の使用または機能の範囲に関する制限を示唆しないことを意図している。またコンピュータ120はそこに示されているコンポーネントの1つまたは組み合わせに関係する依存性または要求条件があると解釈しないものとする。
【００２０】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的文脈において説明できる。一般に、プログラムモジュールには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明はさらに、通信ネットワークを介してリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することも可能である。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。プログラムをおよびモジュールによって実行されるタスクについて図の助けを借りて以下で説明する。当業者であれば、説明と図の内容をプロセッサ実行可能命令として実装することができ、これは、任意の形態のコンピュータ可読媒体に書き込むことができる。
【００２１】
図3を参照すると、コンピュータ120のコンポーネントは、限定はしないが、処理装置140、システムメモリ150、およびシステムメモリを含むさまざまなシステムコンポーネントを処理装置140に結合するシステムバス141を備えることができる。システムバス141には、さまざまなバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種類のバス構造がある。たとえば、このようなアーキテクチャとしては、限定はしないが、業界標準アーキテクチャ(ISA)バス、ユニバーサルシリアルバス(USB)、マイクロチャネルアーキテクチャ(MCA)バス、拡張ISA(EISA)、Video Electronics Standards Association(VESA)ローカルバス、およびMezzanineバスとも呼ばれるPeripheral Component Interconnect(PCI)バスがある。コンピュータ120は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ120によってアクセスできる媒体であればどのようなものでも使用でき、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。たとえば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。コンピュータ記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリまたはその他のメモリ技術、CD-ROM、デジタル多目的ディスク(DVD)またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができコンピュータ120によりアクセスできるその他の媒体がある。
【００２２】
通信媒体は、通常、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、または搬送波またはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを実現し、情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報をエンコードする方法でその特性のうち1つまたは複数を設定または変更した信号を意味する。たとえば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および、音声FR、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれかの組み合わせもコンピュータ可読媒体の範囲に収まるであろう。
【００２３】
システムメモリ150は、読み取り専用メモリ(ROM)151およびランダムアクセスメモリ(RAM)152などの揮発性および/または不揮発性メモリの形のコンピュータ記憶媒体を備える。起動時などにコンピュータ120内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム153(BIOS)は通常、ROM 151に格納される。通常、RAM 152には、処理装置140に直接アクセス可能な、かつ/または現在操作されているデータおよび/またはプログラムモジュールを格納する。たとえば、図3は、オペレーティングシステム54、アプリケーションプログラム155、その他のプログラムモジュール156、およびプログラムデータ157を示している。
【００２４】
コンピュータ120はさらに、その他の取り外し可能/取り外し不可能な揮発性/不揮発性コンピュータ記憶媒体を備えることもできる。たとえば、図3は、取り外し不可能な不揮発性磁気媒体の読み書きを行うハードディスクドライブ161、取り外し可能な不揮発性磁気ディスク172の読み書きを行う磁気ディスクドライブ171、およびCD-ROMまたはその他の光媒体などの取り外し可能な不揮発性光ディスク176の読み書きを行う光ディスクドライブ175を示している。操作環境例で使用できる他の取り外し可能/取り外し不可能な揮発性/不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートRAM、ソリッドステートROMなどがある。ハードディスクドライブ161は、通常、インターフェース160などの取り外し不可能なメモリインターフェースを介してシステムバス141に接続され、磁気ディスクドライブ171および光ディスクドライブ175は、通常、インターフェース170などの取り外し可能なメモリインターフェースによりシステムバス141に接続される。
【００２５】
図3に示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ120用のコンピュータ読み取り可能命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。たとえば、図3では、ハードディスクドライブ161は、オペレーティングシステム164、アプリケーションプログラム165、その他のプログラムモジュール166、およびプログラムデータ167を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム154、アプリケーションプログラム155、その他のプログラムモジュール156、およびプログラムデータ157と同じである場合もあれば異なる場合もあることに注意されたい。オペレーティングシステム164、アプリケーションプログラム165、その他のプログラムモジュール166、およびプログラムデータ167に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。
【００２６】
ユーザは、キーボード182、マイク183、およびマウス、トラックボール、タッチパッドなどのポインティングデバイス181などの入力デバイスを介してコンピュータ120にコマンドおよび情報を入力できる。他の入力デバイス(図に示されていない)としては、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース180を介して処理ユニット140に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス(USB)などの他のインターフェースおよびバス構造により接続することもできる。モニタ184やその他のタイプの表示デバイスも、ビデオインターフェス185などのインターフェースを介してシステムバス141に接続される。モニタのほかに、コンピュータはさらにスピーカ187およびプリンタ186などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース188を介して接続することができる。
【００２７】
コンピュータ120は、リモートコンピュータ194などの1つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することもできる。リモートコンピュータ194は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルーター、ネットワークPC、ピアデバイス、またはその他の共通ネットワークノードでもよく、通常は、コンピュータ120に関係する上述の要素の多くまたはすべてを含む。図3に示されている論理接続は、ローカルエリアネットワーク(LAN)191とワイドエリアネットワーク(WAN)193を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、事務所、企業規模のコンピュータネットワーク、イントラネットおよびインターネットではよくある。
【００２８】
LANネットワーキング環境で使用する場合は、コンピュータ120はネットワークインターフェースまたはアダプタ190を介してローカルエリアネットワーク191に接続される。WANネットワーキング環境で使用する場合は、コンピュータ120は通常、モデム192またはインターネットなどのWAN 193上で通信を確立するためのその他の手段を備える。モデム192は、内蔵でも外付けでもよいが、ユーザ入力インターフェース180またはその他の適切なメカニズムを介してシステムバス141に接続できる。ネットワーク環境では、コンピュータ120またはその一部に関して述べたプログラムモジュールは、リモートメモリ記憶デバイスに格納できる。たとえば、図3は、リモートアプリケーションプログラム195がリモートコンピュータ194に常駐しているように示している。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのにその他手段を使用できることは理解されるであろう。
【００２９】
典型的なアーキテクチャ
図4は、本発明とともに使用できるようなWebベースの認識機能のアーキテクチャ200を示している。一般に、Webサーバ202に格納されている情報は、モバイルデバイス30(ここでは、入力形態に基づいて要求される表示画面、マイク、カメラ、タッチパネルなどを備えるコンピューティングデバイスの他の形態も表す)、または情報を可聴音でまたはキーの押下に応答して電話80により生成されるトーンを通じて要求し、またWebサーバ202からの情報を可聴音でのみユーザに送り返す電話を介して、アクセスすることができる。
【００３０】
この実施例では、アーキテクチャ200は、音声認識を使用しデバイス30で情報を取得するかそれとも電話80を介して取得するかに関係なく、単一の認識サーバ204でいずれかの動作モードをサポートできるという点で統一されている。さらに、アーキテクチャ200は、よく知られているマークアップ言語の拡張(たとえば、HTML、XHTML、cHTML、XML、WMLなど)を使用して動作する。したがって、Webサーバ202に格納されている情報も、これらのマークアップ言語に用意されているよく知られているGUI方式を使用してアクセスできる。よく知られているマークアップ言語の拡張を使用することにより、Webサーバ202上のオーサリングは簡単になり、既存のレガシーアプリケーションも音声またはその他の認識形態に対応するように簡単に修正することができる。
【００３１】
一般に、デバイス30は、Webサーバ202によって提供されるHTML+スクリプトなどを実行する。たとえば、音声認識が要求されるとき、上述のようにデバイス30により音声信号が前処理されている場合に音声信号または発話の特徴にデジタイズできる音声データが認識サーバ204に送られ、音声認識中に使用する文法または言語モデルを示す。認識サーバ204の実装にはいろいろな形態が考えられ、そのうちの1つが図に示されているが、一般的に、レコグナイザ(recognizer)211を含む。認識の結果は、デバイス30に送り返され、望ましい場合または適切な場合にローカルでレンダリングされる。認識およびグラフィカルユーザインターフェースが使用されている場合にはそれを使用して情報をコンパイルした後、デバイス30はこの情報をWebサーバ202に送り、必要に応じて他のHTMLスクリプトを処理し受け取る。
【００３２】
図4に示されているように、デバイス30、Webサーバ202、および認識サーバ204は、接続は共通であるが、ネットワーク205、ここでは、インターネットなどのワイドエリアネットワークを通じて別々にアドレス指定可能である。したがって、これらのデバイスを物理的に隣接する位置に配置する必要はない。特に、Webサーバ202は認識サーバ204を含む必要はない。この方法で、Webサーバ202でのオーサリングは対象となるアプリケーションに焦点を絞ることができ、作成者は認識サーバ204の詳細を知る必要はない。むしろ、認識サーバ204は独立に設計して、ネットワーク205に接続することができ、そのため、Webサーバ202で必要な変更をさらに行うことなく更新および改良を加えることができる。後述のように、Webサーバ202はさらに、クライアントサイドマークアップおよびスクリプトを動的に生成できるオーサリングメカニズムを備えることもできる。他の実施形態では、Webサーバ202、認識サーバ204、およびクライアント30を実装するマシンの能力に応じて見合わせることができる。たとえば、クライアントは汎用コンピュータ、たとえばパソコンを備えている場合、クライアントは認識サーバ204を備えることができる。同様に、必要ならば、Webサーバ202および認識サーバ204を単一のマシンに組み込むことができる。
【００３３】
電話80を介してWebサーバ202にアクセスする際に、電話80を有線または無線電話網208に接続し、さらにこれは電話80をサードパーティーのゲートウェイ210に接続する。ゲートウェイ210は、電話80を電話音声ブラウザ(telephony voice browser)212に接続する。電話音声ブラウザ212は、電話インターフェースおよび音声ブラウザ216を備えるメディアサーバ(media server)214を含む。デバイス30のように、電話音声ブラウザ212はWebサーバ202からHTMLスクリプトなどを受信する。一実施形態では、HTMLスクリプトはデバイス30に提供されるHTMLスクリプトと似た形式である。この方法では、Webサーバ202はデバイス30および電話80を別々にサポートしたり、さらには標準GUIクライアントを別々にサポートしたりする必要さえない。むしろ、共通マークアップ言語使用することができる。さらに、デバイス30のように、ネットワーク205を介してまたはたとえばTCP/IPを使用して専用回線207のいずれかを介して、電話80によって送信された可聴信号からの音声認識結果を音声ブラウザ216から認識サーバ204に送る。Webサーバ202、認識サーバ204、および電話音声ブラウザ212は、図3に示されている汎用デスクトップコンピュータなどの適当なコンピューティング環境で実現することができる。
【００３４】
ただし、DTMF認識が改善された場合、このような形式の認識は一般的に、認識サーバ204ではなくメディアサーバ214で実行されることに注意されたい。つまり、DTMF文法が、メディアサーバ214によって使用されるということである。
【００３５】
戻って図4を参照すると、Webサーバ202は、サーバサイドプラグインのオーサリングツールまたはモジュール209(たとえば、ASP、ASP+、Microsoft CorporationのASP.Net、JSP、Java(登録商標)beansなど)を備えることができる。サーバサイドプラグインモジュール209は、Webサーバ202にアクセスするクライアントのタイプに合わせて、クライアントサイドマークアップ、さらには特定の形式のマークアップさえも動的に生成することができる。クライアント情報を、クライアント/サーバ関係が最初に確立された後Webサーバ202に送るか、またはWebサーバ202側でクライアントデバイスの能力を検出するモジュールまたはルーチンを備えることができる。この方法で、サーバサイドプラグインモジュール209は、音声認識シナリオ、つまり電話80のみの音声またはデバイス30についてはマルチモードのそれぞれについてクライアントサイドマークアップを生成することができる。整合性のとれたクライアントサイドモデルを使用することにより、さまざまなクライアントに対するアプリケーションオーサリングは著しく簡単になる。
【００３６】
クライアントサイドマークアップを動的に生成するほかに、後述の高レベルダイアログモジュールを、ストア211に格納されるサーバサイドコントロールとして実装することができ、これをアプリケーションオーサリングで開発者が使用できる。一般に、高レベルダイアログモジュール211は、開発者が指定したパラメータに基づいて音声のみシナリオおよびマルチモードシナリオの両方でクライアントサイドマークアップおよびスクリプトを動的に生成する。高レベルダイアログモジュール211は、開発者のニーズに合わせてクライアントサイドマークアップを生成するためのパラメータを含むことができる。
【００３７】
典型的なクライアントサイド拡張
本発明の対象となるクライアントサイドマークアップの動的生成を説明する前に、まずWebベースの認識で使用するマークアップ言語の拡張形式例について説明すると役立つと思われる。
【００３８】
上記のように、HTML、XHTML、cHTML、XML、WML、またはその他のSGML派生マークアップなどのマークアップ言語は、Webサーバ202とクライアントデバイス30との対話に使用され、クライアント/サーバアーキテクチャで認識を行うコントロールおよび/またはオブジェクトを含むように拡張されている。一般に、コントロールおよび/またはオブジェクトは、レコグナイザ構成、レコグナイザ実行および/または後処理用のレコグナイザコントロールおよび/またはオブジェクト、シンセサイザー構成およびプロンプト再生用のシンセサイザーコントロールおよび/またはオブジェクト、入力文法リソースを指定するための文法をコントロールおよび/またはオブジェクト、および/または認識結果を処理するためのバインドコントロールおよび/またはオブジェクトの機能のうち1以上を含むことができる。拡張は、軽量マークアップレイヤとなるように設計されており、既存のマークアップ言語に音声、視覚、手書きなどのインターフェースの機能を追加する。したがって、これらの拡張は、拡張機能が含まれる高レベルページ、たとえばHTML、言語リソースを参照するために拡張機能が使用される低レベル形式、たとえばテキスト音声変換や文法形式、および認識サーバ204で使用される認識および音声合成の個々の特性とは独立のものとすることができる。以下で音声認識を説明するが、これ以降で説明する手法、タグ、およびサーバサイドコントロールも同様に、手書き認識、身振り認識、および画像認識にも応用できることは理解されるであろう。
【００３９】
実施例では、拡張機能(一般に「タグ」ともいう)はXML要素の小さなセットであり、関連する属性およびDOMオブジェクトプロパティ、イベントおよびメソッドを備え、これをソースマークアップドキュメントとともに使用して、認識および/または可聴プロンプトインターフェース、DTMFまたは呼び出し制御をソースページに適用することができる。拡張機能の形式と意味は、ソースドキュメントの性質とは無関係であり、したがって、それらの拡張機能はHTML、XHTML、cHTML、XML、WML、またはその他のSGML派生マークアップで等しく効果的に使用することができる。これらの拡張機能は、ドキュメントオブジェクトモデルに従っており、新しい機能オブジェクトまたは要素を、階層状に配置できる。それぞれの要素については付録で詳述しているが、一般に、これらの要素は属性、プロパティ、メソッド、イベント、および/またはその他の「子」要素を含むことができる。
【００４０】
このときに、これらの拡張機能はブラウザが実行されるデバイスの能力に応じて2種類の「モード」で解釈することができることにも注意する必要がある。第1のモード、「オブジェクトモード」では、全機能を使用できる。アプリケーションからプログラムにより拡張機能を操作できるが、これはデバイス上のプラザによって使用可能になるメカニズム、たとえば、XHTMLブラウザのJScriptインタプリタやWMLブラウザのWMLScriptインタプリタで実行される。このような理由から、拡張機能のコアプロパティおよびメソッドの小さなセットのみを定義すればよく、デバイスまたはクライアントサイドに存在するプログラムメカニズムで操作する。オブジェクトモードでは、イベント発生およびスクリプト作成の機能を備え、ダイアログ作成者が音声対話操作に対するクライアントサイドの制御をより細かに行えるという優れた機能性を実現できる。ここで使用しているように、イベントおよびスクリプト作成機能を完全にサポートするブラウザを「アップレベルブラウザ(uplevel browser)」と呼ぶ。この形式のブラウザは、拡張機能のすべての属性、プロパティ、メソッド、およびイベントをサポートする。アップレベルブラウザは、一般に、処理能力の大きなデバイスで実行される。
【００４１】
これらの拡張機能はさらに、「宣言モード」でもサポートできる。ここで使用しているように、宣言モードで動作するブラウザは「ダウンレベルブラウザ」と呼ばれ、完全なイベント発生およびスクリプト作成機能をサポートしていない。むしろ、この形式のブラウザは指定された拡張機能(つまり、コア要素および属性)の宣言的側面をサポートするが、すべてのDOM(ドキュメントオブジェクトモデル)オブジェクトプロパティ、メソッド、およびイベントをサポートするわけではない。このモードでは、もっぱら宣言的構文を使用し、さらに宣言的マルチメディア同期およびSMIL(Synchronized Multimedia Integration Language)2.0などの調整メカニズム(同期マークアップ言語)とともに使用できる。ダウンレベルブラウザは、通常、処理能力の限られているデバイスで実行される。
【００４２】
しかしここで、特定の入力モードについて説明することにする。特に、音声認識を少なくともディスプレイおよび他の実施形態ではポインティングデバイスとともに使用すると複数の入力モードとの連携の調整が可能になり、たとえば、データ入力用のフィールドを示すことができ、特に有用である。特に、このデータ入力モードでは、ユーザは一般にポインティングデバイスの動作と音声入力との連携を調整することができ、たとえば、ユーザはフィールドの選択時期の制御下に置かれ、フィールドに関連する対応する情報を入力できる。たとえば、クレジットカード送信グラフィカルユーザインターフェース(GUI)が図5に示されているが、ユーザは最初に、フィールド252にクレジットカード番号を入力する決定を下し、その後、クレジットカードの種別をフィールド250に入力し、その後、フィールド254に有効期限を入力することができる。同様に、必要ならばユーザはフィールド252に戻り、間違えた入力を訂正することもできる。音声認識と組み合わせると、簡単で自然な形のナビゲーションを実現できる。ここで使用しているように、この形式の入力は画面上でポインティングデバイスを自由形式で操作してたとえばフィールドを選択できる画面表示と認識を使用するが、これは「マルチモード(multimodal)」と呼ばれる。
【００４３】
図6を参照すると、HTMLマークアップ言語のコードが示されている。HTMLコードには、本文部分270とスクリプト部分272が含まれる。各フィールド250、252、および254への情報の入力は、それぞれ、コード部分280、282、および284により制御されるかまたは実行される。最初にコード部分280を参照すると、フィールド250を選択したときに、たとえば、デバイス30のスタイラス３３を使用することで、イベント「onClick」が起動し、スクリプト部分272で関数「talk」が呼び出されるか、または実行される。このアクションにより、フィールド250に一般に予期されるデータの種別と関連する音声認識に使用される文法が起動する。この種の対話操作は、複数の入力手法を伴い(たとえば、音声およびペンクリック/ローラ)、「マルチモード」と呼ばれる。
【００４４】
そこで文法に戻ると、文法とは限定はしないが、文脈自由文法、N文法、またはハイブリッド文法の構文法のことである。(もちろん、DTMF文法、手書き文法、身振り文法、および画像文法は、対応する認識形式が採用されていれば使用される。ここで使用しているように、「文法」は認識を実行するための情報を含み、さらに他の実施形態ではたとえば特定のフィールドに入力することが想定される入力に対応する情報を含む。)コントロール290(ここでは「reco」と呼ぶ)は、さまざまな要素を備え、そのうち2つが文法要素「grammar」と「bind」要素であり、図に示されている。一般に、Webサーバ202からクライアントにダウンロードされたコードのように、文法はWebサーバ202から始まり、クライアントにダウンロードされかつ/またはリモートサーバに転送され、音声処理が行われる。その後、文法をローカルのキャッシュ内に格納することができる。最終的に、文法は認識サーバ204に送られ、認識に使用される。文法要素を使用し、インラインまたは属性を使用して参照することで文法を指定する。
【００４５】
認識された音声、手書き、身振り、画像などに対応する認識結果を認識サーバ204から受信した後、recoコントロール290の構文が提供され、対応する結果を受け取り、それを対応するフィールドに関連付けるが、ディスプレイ34にテキストをレンダリングする機能を含むことができる。図に示されている実施形態では、音声認識が完了し、結果はクライアントに送り返されると、recoオブジェクトを非アクティブ状態にし、認識されたテキストを対応するフィールドに関連付ける。部分282および284は同様に動作し、一意的なrecoオブジェクトおよび文法がフィールド252と254のそれぞれについて呼び出され、認識されたテキストを受け取った後、フィールド252と254のそれぞれに関連付けられる。カード番号フィールド252の受信に関して、関数「handle」がカードの種別に関してカード番号の長さをチェックする。
【００４６】
クライアントサイドマークの生成
上記のように、サーバサイドプラグインモジュール209は、クライアントデバイス30に要求が送られたときにクライアントサイドマークアップを出力する。つまり、サーバサイドプラグインモジュール209では、Webサイト、したがって、アプリケーションおよびアプリケーションによって提供されるサービスを定義したり構築したりすることができる。サーバサイドプラグインモジュール209内の命令は、コンパイルされたコードである。このコードは、Web要求がWebサーバ202に到達したときに実行される。サーバサイドプラグインモジュール209は、その後、クライアントデバイス30に送られる新しいクライアントサイドマークアップページを出力する。よく知られているように、このプロセスは一般にレンダリングと呼ばれる。サーバサイドプラグインモジュール209は、マークアップ言語、したがってクライアントサイドマークアップページのコードを抽象化し、カプセル化する「コントロール」上で動作する。マークアップ言語を抽象化しカプセル化し、Webサーバ202上で動作するこのようなコントロールは、たとえば、いくつかを挙げると、「サーブレット」や「サーバサイドプラグイン」を含むか、またはそれに同等である。
【００４７】
知られているように、従来技術のサーバサイドプラグインモジュールはクライアントデバイス30との視覚的レンダリングおよび対話操作用にクライアントサイドマークアップを生成することができる。サーバサイドプラグインモジュール209を、上述のクライアントサイド拡張機能例などの認識および可聴プロンプト機能の拡張機能を含むように拡張する3種類のアプローチが提示されているが、さらに本発明の別々の態様ともなっている。図7に概略が示されている第1のアプローチでは、現在の視覚的サーバサイドコントロール(レンダリング、フォント、前景色、背景色のロケーションなどの視覚的表示のパラメータを含む)は、認識および関連する認識に対する可聴プロンプト機能のパラメータまたは属性を含むように拡張されている。たとえば、音声認識および関連する可聴プロンプト機能を使用すると、属性は一般に、プロンプトにテキスト音声変換用のインラインテキストを含めるかどうか、事前に記録されたオーディオファイル(たとえば、ウェーブファイル)の再生、可聴レンダリング用のデータ(テキスト音声変換のテキストまたは事前記録されたオーディオファイル)の保存先などの可聴プロンプト機能のパラメータに関係する。認識については、パラメータまたは属性に、認識中に使用する文法の保存先、信頼レベルしきい値などを含めることができる。サーバサイドプラグインモジュール209はクライアントサイドマークアップを生成するので、サーバサイドプラグインモジュール209のコントロールに対するパラメータおよび属性は認識および/または可聴プロンプト機能用のクライアントサイドマークアップに用意される拡張機能に関係する。
【００４８】
図7の300Aに示されているコントロールは、ASP、ASP+、ASP.Net、JSP、Java(登録商標) beansなどのWebサイトのアプリケーション開発またはオーサリングツールではよく知られているコントロールである。このようなコントロールは、特定の視覚的タスクを実行するため、一般にライブラリで形成されコントロール302により使用される。ライブラリ300Aは、目的のクライアントマークアップ、イベントハンドラなどを生成するためのメソッドを含む。視覚的コントロール302の例としては、図5のラベル「Credit Card Submission」304などの視覚的表示上の選択されたテキストラベルを実装する「Label」コントロールがある。より高いレベルの視覚的コントロール302の例としては他に、図5の250に示されているようなデータフィールドにデータを入力するための「Textbox」がある。既存の視覚的コントロール302もよく知られている。認識および/または可聴プロンプト機能を備えるようにサーバサイドプラグインモジュールコントロールを拡張する第1のアプローチでは、視覚的コントロール302のそれぞれは視覚的レンダリングに関係する属性の集合に加えて認識または可聴プロンプト機能に関係する他のパラメータまたは属性を含む。「Label」コントロールの場合、他の方法では選択したテキストを視覚的表示上に示すが、他の属性は、オーディオデータファイルをレンダリングするか、またはテキスト音声変換をこのデータファイルの保存先とともに使用するかどうかも示す。ライブラリ300Bは、ライブラリ300Aに似ており、認識および/または可聴プロンプト機能を実行するための他のマークアップ情報含む。視覚的コントロール302はそれぞれ、この情報をコントロール300Bに送り、認識または可聴プロンプト機能に安定する特定のタスクを適切に実行するようにコーディングされている。
【００４９】
他の実施例として、視覚的表示上に入力フィールドを生成し、クライアントデバイス30のユーザが情報を入力するための「Textbox」コントロールもまた、認識に使用される文法などの適切な認識または可聴プロンプト機能パラメータまたは属性を含む。認識または可聴プロンプト機能パラメータはオプションであり、認識または可聴プロンプト機能が何らかの理由で望ましくない場合には使用する必要がないことに注意されたい。
【００５０】
一般に、レベル302のコントロールに視覚的側面に関係するパラメータが含まれる場合、そのコントロールはライブラリ300Aにアクセスし使用する。同様に、コントロールに認識および/または可聴プロンプト機能に関係するパラメータが含まれる場合、コントロールはライブラリ300Bにアクセスするかまたは使用する。ライブラリ300Aおよび300Bは、ライブラリ300Bに存在する追加情報を強調するために別々に示しているのであって、ライブラリ300Aと300Bの情報を含む単一のライブラリを実装できることに注意されたい。
【００５１】
このアプローチでは、現在または従来技術の視覚的コントロール302のそれぞれが、適切な認識/可聴プロンプト機能属性を備えるように拡張されている。コントロール302は、ライブラリ形式を取ることができる。サーバサイドプラグインモジュール209は、マークアップ情報を得るためにライブラリにアクセスする。コントロールを実行すると、与えられたパラメータによりクライアントサイドマークアップページ、またはその一部が生成される。
【００５２】
図8に示されている第2のアプローチでは、新しい視覚的認識/可聴プロンプト機能コントロール304が提供され、コントロール304は視覚的コントロール302に関係するサブクラスとなり、認識/可聴プロンプト機能またはマークアップ情報はコントロール304のところで与えられる。つまり、新しいコントロールセット304が、認識/可聴プロンプト機能用に用意され、クライアントデバイス30上の認識タスクに関係する目的の認識または可聴プロンプト機能を実行するための適切なパラメータまたは属性を備える。コントロール304は、視覚的情報をレンダリングするかまたは表示を通じて取得する範囲で既存の視覚的コントロール302を使用する。たとえば、レベル304のコントロール「SpeechLabel」はレベル302の「Label」コントロールを使用して、可聴レンダリングおよび/または視覚的テキストレンダリングを行う。同様に、「SpeechTextbox」コントロールは、文法および関連する認識リソースおよび処理を入力フィールドと関連付ける。第1のアプローチのように、コントロール304の属性は、認識用の文法を保存する場所、テキスト音声変換用のインラインテキスト、または直接レンダリングされる記録済みオーディオデータファイルまたはテキストを音声変換によるテキストファイルの保存先を含む。第2のアプローチは、認識コントロール304と視覚的コントロール302との対話がパラメータまたは属性によるものであるという点で都合がよく、したがって、視覚的コントロール302の変更が生じても、コントロール304と302との間でインターフェースするパラメータまたは属性が相変わらず適切であれば、認識コントロール304の変更は不要と思われる。ただし、他の視覚的コントロール302を作成する場合、レベル304の対応する認識/可聴プロンプト機能コントロールもまた作成する必要がある。
【００５３】
第3のアプローチは図9に示されている。一般に、第3のアプローチのコントロール306は、視覚的コントロール302とは別になっているが、後述のように選択的にそれらと関連付けられている。このようにして、コントロール306は直接的には視覚的コントロール302に基づいて構築されないが、むしろ、視覚的コントロール302を作成し直すことなく認識/可聴プロンプト機能対応にできる。コントロール306は、コントロール302と同様、ライブラリ300を使用する。この実施形態では、ライブラリ300は視覚的マークアップ情報および認識/可聴プロンプト機のマークアップ情報の両方を含み、したがって、図7のライブラリ300Aおよび300Bの組み合わせとなっている。
【００５４】
この第3のアプローチには大きな利点がある。まず、視覚的コントロール300にはコンテンツの変更を必要としない。第2に、コントロール306は整合性のとれた単一モジュールを形成することができ、音声対応コントロール302の性質に従って変更する必要がない。第3に、音声対応のプロセス、つまり、明示的かつ選択的プロセスであるため、コントロール306を視覚的コントロール302に明示的に関連付ける操作が設計時に完全に開発者の管理下に置かれる。このことによりさらに、視覚的コントロールのマークアップ言語で、コントロール306によって生成されたマークアップ言語により提供される認識またはキーボードなどの従来の入力デバイスなどにより複数のソースから入力値を受け取ることが可能になる。つまり、コントロール306をサーバサイドプラグインモジュール209の視覚的オーサリングページの既存のアプリケーションオーサリングページに追加できるということである。コントロール306は、クライアントデバイス30のユーザ向けの新しい様相の対話操作機能を備えながら(つまり、認識および/または可聴プロンプト機能)、視覚的コントロールのアプリケーションロジックおよび視覚的入力/出力機能を再利用できる。コントロール306を、アプリケーションロジックをコーディングできる視覚的コントロール302と関連付けられるという点を鑑みて、コントロール306をこれ以降、「随伴コントロール306」と呼び、視覚的コントロール302を「主トロール302」と呼ぶことができる。これらの参照は、コントロール302と306を区別するために行うのであり、制限する目的のものではないことに注意されたい。たとえば、随伴コントロール306は、音声専用Webサイトなどの視覚的レンダリングを備えていないWebサイトを開発またはオーサリングする場合に使用することができる。そのような場合、特定のアプリケーションロジックを随伴コントロールロジックで実現することができる。
【００５５】
随伴コントロール306のセット例をさらに図10に示す。随伴コントロール306のセットを出力コントロール308および入力コントロール310としてグループ化することができる。出力コントロール308は、通常、記録済みオーディオファイルの再生を伴う「プロンプト機能」クライアントサイドマークアップ、またはテキスト音声変換用のテキストを提供し、データはマークアップ内に直接に含まれるか、またはURLで参照する。単一の出力コントロールはすべての可聴プロンプト機能を処理するようにパラメータで定義することができ、しがって本発明の他の態様として見なされるが、実施例では、人間用のダイアログ内の形式または種類の可聴プロンプト機能は別のコントロールとして形成される。特に、出力コントロール308は、「Question」コントロール308A、「Confirmation」コントロール308B、および「Statement」コントロール308Cを備えることができ、これらについて後述する。同様に、入力コントロール310も、人間用のダイアログを形成するかまたはそれに従い、「Answer」コントロール310Aおよび「Command」コントロール310Bを備える。入力コントロール310については後述するが、一般に、入力コントロール310は文法をクライアントデバイス30のユーザからの予想されるまたは可能な入力と関連付ける。
【００５６】
質問コントロール308A、確認コントロール308B、ステートメントコントロール308C、応答コントロール310A、コマンドコントロール310B、その他のコントロール、さらにそれらのコントロールの一般的構造、パラメータおよびイベントハンドラについて、特に随伴コントロール306としての使用に関して説明するが、それらのコントロール、一般的構造、パラメータおよびイベントハンドラは、図7および8に関して上で述べた他の2つのアプローチにより認識および/または可聴プロンプト機能を実現するように改造できる。たとえば、パラメータ「ClientToSpeechEnable」は、随伴コントロールと視覚的コントロールとの関連付けを形成する1つのメカニズム例を構成するが、これは、図7および8のアプローチで実現するときには不要である。
【００５７】
マルチモードアプリケーションでは、少なくとも出力コントロール308のうちの1つまたは入力コントロール310のうちの1つを主コントロールまたは視覚的コントロール302に関連付ける。図に示されている実施形態では、出力コントロール308および入力コントロール310は、「Question/Answer」(以下「QA」とも呼ぶ)コントロール320の下で配列または編成されている。QAコントロール320は、Webサーバ202で実行されるが、これは、サーバサイドマークアップ形式(ASP、JSPなど)を使用してWebサーバ上に保持されているアプリケーション開発Webページで定義されることを意味しているが、クライアントデバイス30に異なる形式のマークアップとして出力される。QAコントロールが出力コントロール308および入力コントロール310のすべてから形成されるように見える図10に示されているが、これらは、QAコントロールに対して1つまたは複数を含むことができる単なるオプションでることは理解されるであろう。
【００５８】
このときに、コントロール308および310の使用法をアプリケーションシナリオに関して説明すると役立つと思われる。図11を参照すると、音声専用アプリケーションでは、QAコントロール320は単一の質問コントロール308Aと応答コントロール310Aで構成できる。質問コントロール308Aは1つまたは複数のプロンプトオブジェクトまたはコントロール322を含むが、応答コントロール310Aは入力データの認識とその入力に対する関連する処理のため文法オブジェクトまたはコントロール324を通じて文法を定義することができる。線326は、QAコントロール320と使用している場合に対応する主コントロール302との関連付けを表す。マルチモードのシナリオでは、クライアントデバイス30のユーザは視覚的テキストボックスに触れることができ、たとえば、「TapEvent」を使用すると、可聴プロンプトは必要な場合がある。たとえば、クライアントデバイスのユーザが対応するフィールド内に入力する内容を示す表示を形成する視覚的テキストを備えるテキストボックスを含む主コントロールについては、対応するQAコントロール320はオーディオ再生やテキスト音声変換などの対応するプロンプトを持つ場合も持たない場合もあるが、認識用の予想される値に対応する文法、入力を処理する、または音声が検出されない、音声が認識されない、またはタイムアウトでイベントが発生するなどの他のレコグナイザイベントを処理するイベントハンドラ328を備える(以下の「イベント発生」で説明)。
【００５９】
一般に、出力コントロール308および入力コントロール310および追加ロジックによるQAコントロールは、いくつかを挙げると、出力可聴プロンプト機能を提供する、入力データを収集する、入力結果の信頼性妥当性確認を実行する、「ヘルプ」コマンドやクライアントデバイスのユーザがWebサイトの他の選択された領域にナビゲートするためのコマンドなどの追加タイプの入力を使用できるようにする、入力データの確認およびWebサイトでのダイアログの流れの制御を可能にする機能のうち1つまたは複数を実行できる。つまり、QAコントロール320は特定のトピックに関係するすべてのコントロールを含むということである。このようにして、ダイアログはトピックに関してコントロールの使用を通じて作成され、情報取得を通知する、妥当性確認を行う、あるいはダイアログを修復したり、会話のトピックを変更したりすることができる。
【００６０】
本発明の他の態様を含む一開発方法では、アプリケーション開発者は視覚的コントロール302を使用してアプリケーションの視覚的レイアウトを定義することができる。アプリケーション開発者は、その後、随伴コントロール306を使用してアプリケーションの音声インターフェースを定義することができる(QAコントロール320、または出力コントロール308および入力コントロール310として実現する)。図10および11に示されているように、随伴コントロール306のそれぞれは対応する主コントロールまたは視覚的コントロール302にリンクされるか、または他の手段で関連付けられ、認識および可聴プロンプト機能を実装する。もちろん、望むならば、アプリケーション開発者は視覚的コントロール302と随伴コントロール306との間で切り替えを行うことによりアプリケーションを定義またはエンコードし、それらの間のリンクを形成し、アプリケーションが完全に定義またはエンコードされるようにする。
【００６１】
このときに、出力コントロール308および入力コントロール310のそれぞれについて簡単に説明すると役立つと思われる。詳細な説明は、以下の付録Bで行う。
【００６２】
質問、応答、およびコマンド
一般に、上述のように、QAコントロール320内の質問コントロール308Aおよび応答コントロール310Aは主コントロール302に関連するプロンプトおよび文法リソース、および関係するバインド(認識結果をクライアントサイドマークアップページの入力フィールドに関連付ける)および処理ロジックを保持する。質問コントロール308Aと応答コントロール310Aが存在するか存在しないかにより、音声出力または認識入力がアクティブ化したときに有効になるかどうかが決まる。コマンドコントロール310Bおよびユーザイニシアチブ応答は、応答コントロール310Aとコマンドコントロール310Bに対するScopeプロパティの指定によりアクティブになる。
【００６３】
単純な音声専用アプリケーションでは、QAコントロール320は通常、1つの質問コントロールまたはオブジェクト308Aと1つの応答コントロールまたはオブジェクト310Aを保持する。以下の例では示されていないが、コマンドコントロール310Bはさらに、たとえば、Help、Repeat、Cancelなどに指定でき、これにより、特定の質問の応答に直接関係しないユーザ入力が使用可能になる。
【００６４】
音声専用ダイアログ用の代表的な「正規」QAコントロールは以下のとおりである。
【００６５】
【数１】
2009059378.tif 000003
【００６６】
(ここで示されている例は、ASP.NETフレームワークで作成されているが、例にすぎず、本発明を制限するものとみなすべきではない。)
この例では、QAコントロールを「ID」で識別することができ、QAコントロールと目的の主または視覚的コントロールと関連付けはパラメータ「ControlsToSpeechEnable」を通じて取得され、それぞれ識別子により1つまたは複数の主コントロールを識別する。必要ならば、他のよく知られている手法を使用してこの関連付けを形成することができる。たとえば、直接的な暗黙の関連付けは、上述の第1と第2のアプローチを通じて使用するか、または関連付けを保持するために別々のテーブルを作成することができる。パラメータ「runat」で、このコードをWebサーバ202で実行して正しいマークアップを生成するようWebサーバに指示する。
【００６７】
QAコントロールは、また、ステートメントコントロール308Cのみを保持することもでき、その場合、これは、アクティブな文法のないプロンプト専用コントロールである(たとえば、初期画面プロンプト)。同様に、QAコントロールは応答コントロール310Aのみを保持することができ、その場合、マルチモードコントロールとすることができ、その応答コントロール310AはGUIまたはユーザイニシアチブ用の範囲設定メカニズム(後述)からのイベントの結果として文法を直接アクティブにする。
【００６８】
なお、QAコントロール320はさらに複数の質問コントロール308Aおよび複数の応答コントロール310Aなどの複数の出力コントロール308および入力コントロール310を保持することもできる。これにより、作成者は同じQAコントロール内の同じエンティティに関して相互作用の流れを記述することができる。これは、特に、さらに複雑な音声専用ダイアログの場合に有用である。したがって、さまざまな質問と応答(たとえば、問いかけ、確認、ヘルプ提示など)を伴うミニダイアログを、ダイアログエンティティを表す視覚的コントロールと関連付けられているQAコントロールのラッパー内で指定することができる。複雑なQAコントロールを図11に示す。
【００６９】
前記はQAコントロールの主要な機能を表している。以下では各機能について機能の観点から説明する。
【００７０】
応答コントロール
応答コントロール310Aは、文法の概念、バインド、およびその他の認識処理を抽象化し、単一のオブジェクトまたはコントロールにまとめる。応答コントロール310Aを使用して、バインド宣言および関連スクリプトとともに、質問に関連する使用可能な文法セットを指定することができる。「Tap-and-Talk」などのマルチモードアプリケーション用の応答コントロールは、GUIブラウザイベントによりアクティブ化、非アクティブ化が行われる。以下の例は、マルチモードアプリケーションにおいてテキストボックス「txtDepCity」の「mouseDown」イベントで出発地の都市を選択するために使用される応答コントロールを示しており、その値を主テキストボックスコントロールに書き込む。
【００７１】
【数２】
2009059378.tif 000004
【００７２】
音声専用アプリケーションの代表的な応答コントロール310Aは、後述のように質問コントロール308Aにより直接アクティブにされる。
【００７３】
応答コントロールはさらに、受け取った結果を主コントロールに関連付けるメカニズムを備える。ここで、バインドにより値が主コントロール内に入るが、他の実施形態では、関連付けメカニズムにより主コントロールは認識された結果を見たり、または他の手段でそれにアクセスしたりすることができる。
【００７４】
質問コントロール
質問コントロール308Aは、プロンプトタグ(付録A)の概念を抽象して、可能なプロンプトとその質問への応答と見なされる応答コントロール310Aの選択を含むオブジェクトにまとめる。各質問コントロール308Aは、実行したときにアクティブにする応答コントロール310Aを指定できる。これにより、適切な応答文法を応答コントロール310Aにバンドルし、関連する質問コントロール308Aを反映するようにできる。
【００７５】
以下の質問コントロール308Aは、出発地の都市を尋ねるために音声専用アプリケーションで使用できる。
【００７６】
【数３】
2009059378.tif 000005
【００７７】
以下の例では、質問コントロール308Aの内部条件に応じて異なるプロンプトを呼び出すことができる。質問コントロール308A内でプロンプトに対し条件付きテストを指定できるため、言い回しに変更があっても、質問コントロール308Aの同じ機能ユニット内で対応できる。
【００７８】
【数４】
2009059378.tif 000006
【００７９】
【数５】
2009059378.tif 000007
【００８０】
条件付きQAコントロール
以下の例は、アプリケーションで認識できる情報に基づいてQAコントロールをアクティブにするかどうかを決定する方法を示している。例は、調査アプリケーションの一部である。調査は、仕事に使用する輸送の方法に関して従業員から情報を収集するというものである。
【００８１】
調査の一部ではまず、ユーザが通勤にバスを使用するかどうかを尋ねる。応答が次の場合:
-はい。次の質問ではユーザが先週バスに乗った日数を尋ねる。
-いいえ。「バスに乗った日数」の質問はバイパスされる。
【００８２】
【数６】
2009059378.tif 000008
【００８３】
【数７】
2009059378.tif 000009
【００８４】
【数８】
2009059378.tif 000010
【００８５】
【数９】
2009059378.tif 000011
【００８６】
上記の例では、QAコントロール「QA_DaysRodeBus」は、ブール値パラメータ「ClientTest」に基づいて実行され、この例では、関数RideBusCheck()に基づいて設定される。この関数が偽条件を返した場合、QAコントロールはアクティブにされないが、真条件が返された場合、QAコントロールはアクティブにされる。アクティブ化メカニズムを使用することにより、生成されるクライアントサイドマークアップページ内の柔軟性が増し、ダイアログの流れが向上する。付録Bに示されているように、コントロールおよびオブジェクトの多くはアクティブ化メカニズムを備える。
【００８７】
コマンドコントロール
コマンドコントロール310Bは、音声専用ダイアログで共通のユーザ発声機能であり、通常、尋ねられた質問に関してほとんど意味的な取り込みはないが、むしろ、補助または効果ナビゲーション、たとえば、ヘルプ、キャンセル、繰り返しなどの機能を求める。QAコントロール306内のコマンドコントロール310Bを使用すると、認識の文法および関連処理だけでなく(むしろ結果を入力フィールドにバインドしない応答コントロール310Aに似ている)、コンテキストおよびタイプの「範囲」も指定することができる。このため、クライアントサイドマークアップに対するグローバルな動作およびコンテキスト依存の動作の両方のオーサリングが可能である。
【００８８】
前記の説明から当業者であれば、視覚的コントロール302で使用されているのと同様にコントロール306をツリー構造に編成できることは明白であろう。各コントロール306はさらに選択された視覚的コントロール302に関連付けられるため、コントロール306の編成はコントロール302の構造に関連付けることができる。
【００８９】
QAコントロール302を使用して、アトミックコントロール(テキストボックス、ラベルなど)とコンテナコントロール(フォーム、パネルなど)の両方を音声対応にできる。これは、サブダイアログコントロールの動作の範囲を定めモジュール化する手段となっている。たとえば、この範囲により、クライアントデバイスのユーザはダイアログを終了せずにクライアントサイドマークアップページの他の部分にナビゲートすることができる。
【００９０】
一実施形態では、「範囲(Scope)」は、主コントロールツリーのノードとして決定される。以下に、2つのテキストボックスを備える、「Pnl1」コンテナコントロールのレベルで範囲設定された「ヘルプ」コマンドの例を示す。
【００９１】
【数１０】
2009059378.tif 000012
【００９２】
【数１１】
2009059378.tif 000013
【００９３】
指定されているように、「ヘルプ」文法は、「Pnl1」およびそのコンテンツに関係するすべてのQAコントロール内でアクティブになる。GlobalGiveHelpサブルーチンは、「ヘルプ」が認識されることに実行される。これを指定変更し、コンテキスト依存の動作を行わせるために、同じタイプのコマンドをコンテキストの要求されるレベルに合わせて範囲設定することができる。
【００９４】
【数１２】
2009059378.tif 000014
【００９５】
確認コントロール
QAコントロール320はさらに、共通確認サブダイアログのオーサリングを簡素化するメソッドを備えることもできる。以下のQAコントロールは、値の入力を求め、その確認を行う代表的なサブダイアログの例である。
【００９６】
【数１３】
2009059378.tif 000015
【００９７】
この例では、AnsDepCity文法に一致するがその信頼レベルはconfirmThreshold値を超えない「which city?」に対するユーザの応答により、確認コントロール308が起動する。作成者が利用できるさらに柔軟な確認方法として、複数の質問コントロールと複数の応答コントロールを使用するメカニズムがある。
【００９８】
他の実施形態では、確認コントロールに関係する追加入力コントロールに、受理コントロール、否認コントロール、および訂正コントロールが含まれる。それぞれのコントロールは、対応する確認コントロールによりアクティブにし(他のコントロールと似た方法で)、それぞれ結果を受理、否認、または訂正する文法を含めることができる。たとえば、ユーザは、「no」で応えて否認する、「yes」または「yes」+現在値(たとえば、「Do you want to go to Seattle?」「Yes, to Seattle」)で応えて受理する、「no」+新しい値(たとえば、「Do you want to go to Seattle」「No, Pittsburgh」)で応えて訂正することができる。
【００９９】
ステートメントコントロール
ステートメントコントロールを使用すると、アプリケーション開発者はクライアントデバイス30のユーザからの応答を必要としないときにクライアントサイドマークアップの実行後に出力を行うことができる。たとえば、「Welcome」プロンプトをクライアントサイドマークアップページの実行の始めに再生することができる。
【０１００】
ステートメントコントロールに属性を与え、クライアントデバイスのユーザに送られるさまざまな種類の情報を区別するようにできる。たとえば、警告メッセージまたはヘルプメッセージを表す属性を用意することができる。これらのタイプは、異なる音声などの異なるビルトインプロパティを備えることができる。必要ならば、別の形式のステートメントコントロール、つまりヘルプコントロール、警告コントロールなどを用意することもできる。別のコントロールまたはステートメントコントロールの属性として用意したどうかどうかに関係なく、異なる種類のステートメントは、作成されたダイアログの中で異なる役割を持つが、返答を期待せずにクライアントデバイスのユーザに情報を送る基本的な役割を共有する。
【０１０１】
イベント発生
図11に示されているようなイベントハンドラは、クライアントデバイス30のユーザのアクション/非アクションおよび認識サーバ204の操作のためにQAコントロール320、出力コントロール308、および入力コントロール310内に用意されるが、他のイベントについては付録Bで仕様を定めている。たとえば、いくつかを挙げると、ユーザが発話しているがその単語を音声レコグナイザ側が認識できないようなぶつぶつ言う話し方と、音声が全く検出されない無音状態は、QAコントロール320で指定する。これらのイベントでは、作成者が定義したクライアントサイドスクリプト機能を参照する。前に指定したマルチモードアプリケーションでは、エラーメッセージをテキストボックス内に出力する単純なマンブル(mumble)ハンドラを次のように作成することができる。
【０１０２】
【数１４】
2009059378.tif 000016
【０１０３】
コントロール実行アルゴリズム
一実施形態では、クライアントサイドスクリプトまたはモジュール(ここでは「RunSpeech」)をクライアントデバイスに備える。このスクリプトの目的は、クライアントデバイス30で実行したときに、つまり、そこに含まれる値に応じてクライアントで実行するためコントロールに関係するマークアップをアクティブにしたときにスクリプトで指定されたダイアログの流れをロジックを介して実行することである。このスクリプトを使用することで、ページ要求間で複数のダイアログターンが可能になり、したがって、電話ブラウザ216などの音声専用ダイアログのコントロールに特に有用である。クライアントサイドスクリプトRunSpeechは、完成フォームが送信されるか、または新しいページが他の方法でクライアントデバイス30から要求されるまでクライアントデバイス30上で実行されループする。
【０１０４】
一実施形態では、これらのコントロールはクライアント上で実行されたときに値に応じて互いをアクティブにし合うことができることに留意すべきである。(たとえば、質問コントロールが選択された応答コントロールをアクティブにする)。ただし、他の実施形態では、コントロールは適切なマークアップを生成するために互いを「アクティブ」にすることができるが、その場合、サーバサイド処理を実装できる。
【０１０５】
一般に、一実施形態では、このアルゴリズムで音声出力とユーザ入力の認識によりダイアログターンを生成する。アルゴリズムの全体的なロジックは、音声専用シナリオについて以下のとおりである。
1.次のアクティブな出力随伴コントロールを見つける。
2.それがステートメントの場合、ステートメント再生し、1に戻り、質問または確認の場合は、3に進む。
3.予想される応答を収集する。
4.コマンドを収集する。
5.出力コントロールを再生し、入力を待つ。
6.認識された応答またはコマンドオブジェクトをアクティブにするか、または何も認識されない場合はイベントを発行する。
7.1に戻る。
【０１０６】
マルチモードの場合、このロジックは次のアルゴリズムに簡素化される。
1.イベントの発生、つまりユーザがコントロールを叩くのを待つ。
2.予想される応答を収集する。
3.入力を待つ。
4.認識された応答オブジェクトをアクティブにするか、または何もなければ、イベントをスローする。
5.1に戻る。
【０１０７】
このアルゴリズムは、上述のように、コントロールにいつアクティブにできるかということに関する情報が組み込まれているため比較的単純である。また、ダイアログ内のコントロールの役割も使用する。たとえば、ステートメントを即座に再生し、その一方で、質問および確認を予想される応答が収集されたときだけ再生する。
【０１０８】
他の実施形態では、暗黙の確認を用意することができ、それによってシステムは情報断片を確認し、同時に質問を出す。たとえば、システムは旅客機の到着都市を確認し、「"When do you want to go to Seattle?」という1回の発話で旅行日を尋ねることができる(つまり、「いつ」を尋ね、暗黙のうちに「目的地:シアトル」を確認する)。ユーザが日付を指定した場合、その目的地の市が正しくなければユーザがすぐに異議申し立てするので、その目的地の市は暗黙のうちに受理されたと見なされる。このシナリオでは、質問に答えているか、あるいは値を訂正しているか、あるいはヘルプを要求しているかなど、ユーザが達成しようとしている内容がわかっていることが非常に重要であることは明白である。ダイアログでユーザ入力の役割を使用することにより、システムは値をいつ暗黙のうちに受理するかを知ることができる。
【０１０９】
要約すると、ダイアログはダイアログ内のコントロールの役割と他のコントロールとの関係に応じて作成され、アルゴリズムはそれらのコントロールを実行し、これによりそのダイアログを管理するということである。各コントロールは、クライアント側のダイアログ内のその位置で有用な目的に使用されるかどうかに応じて所定のコントロールを選択する(つまり、実行のためアクティブにする)ために実行アルゴリズムにより使用されるタイプに基づく情報を格納する。たとえば、確認コントロールは、確認する値があり、先へ進もうにもシステム内のその値が十分に信頼できるとはいえないときのみ、アクティブになる。他の実施形態では、これらの組み込まれた情報断片のほとんどは、アプリケーション開発者側で指定変更するか、または他の方法で手直しすることができる。
【０１１０】
以下の表に、コントロール、ダイアログ内での対応する役割、および他のコントロールとの関係をまとめた。
【０１１１】
【表１】
2009059378.tif 000017
【０１１２】
これらのコントロールの使用法については、単純な人間/コンピュータダイアログの図を使用して説明できる。以下のダイアログでは、システムまたはユーザの部分の各ダイアログターンは、そのダイアログの目的を反映するコントロール(かっこ内)に応じて特徴づけられる。
【０１１３】
1.システム(ステートメント):「Welcome to the travel booking service」
2.システム(質問):「Where would you like to go?」
3.ユーザ(応答):「San Francisco.」
4.システム(確認):「Did you say Seattle?」
5.ユーザ(否認):「No.」
6.システム(質問):「Where would you like to go?」
7.ユーザ(応答):「San Francisco.」
8.システム(確認):「Did you say Seattle?」
9.ユーザ(訂正):「I said San Francisco.」
10.システム(確認):「Did you say San Francisco?」
11.ユーザ(訂正):「Yes.」
12.システム(質問):「When would you like to leave?」
13.ユーザ(コマンド):「Help.」
【０１１４】
ターン1は、システムの部分のステートメントである。ステートメントコントロールに応答でアクティブにする応答コントロールがないため、システムは入力を予期しない。システムは、引き続き、ターン2で質問コントロールをアクティブにする。次に、「San Francisco」、「Seattle」などサービスを通じて利用できる市を含む文法を保持するものを含む可能な応答コントロールセットをアクティブにし、ユーザがターン3でそのような市を指定できるようにする。
【０１１５】
ユーザのターン3は、システムによって誤認識される。システムでは市に対する応答コントロールからの値があると信頼しているが、その値の信頼性は低い(間違って認識されているためまさしくそうである)。受け取ったばかりの応答コントロールのこのように低い信頼性の値は、RunSpeechがターン4で生成されるようにシステムの部分の確認コントロールを起動するには十分な情報である。次に確認コントロールは、否認コントロール、訂正コントロール、および受理コントロールをアクティブにし、ユーザの次のターンを認識するのにそれぞれの文法を使用できるようにする。ユーザのターン5、9、および11は、これらのコントロールの応答例を示している。ユーザのターン5では、値「no」を単に否認する。これは、システムから値を削除する効果があり、したがって、RunSpeechの次のアクションは、値を再取得するために再び質問することである(ターン6)。
【０１１６】
ターン7および8は、3および4の場合のように確認コントロールに戻る。
【０１１７】
ユーザターン9は、訂正コントロールであり、これもまた、確認コントロールの可能な応答としてアクティブにされている。訂正コントロールでは、確認対象の値を否認するだけでなく、新しい値をも指定する。したがって、ユーザターン9は、システムによって、正しくはことのときに「San Francisco」と認識される新しい値を持つ正しいコントロールであると認識される。
【０１１８】
しかし、新しい値に対するシステムの信頼は低く、なお他の確認コントロールがターン10で生成される。次に、応答でコントロールの受理、否認、および訂正がアクティブになり、ユーザターン11(「Yes」)は受理コントロール文法と一致する。受理コントロールの認識には取得しようとしている値に対するシステムの信頼の「グラウンディング(grounding)」の効果があり、したがって、RunSpeechは他の空の値を選択して取得することができる。ターン12で、日付の値を要求する新しい質問コントロールが出力される。今回のユーザの応答(ターン13)はコマンド「help」である。コマンドコントロール、通常、グローバルな形で、つまり、システムの部分の異なる質問コントロールおよび確認コントロールとは独立にアクティブにされる。このようにして、ユーザは、ターン13でするようにいつでもヘルプを要求することができる。コマンドコントロールはさらに、主コントロール構造の部分について話しているアクティブ化の範囲を定めるメカニズムによりさらに細かく使用可能にすることができる。
【０１１９】
またアルゴリズムを参照すると、一実施例では、クライアントサイドスクリプトRunSpeechは主コントロールのそれぞれの中の値と、QAコントロールの属性を調べ、現在のページのQAコントロールの選択テストを行い、実行用の単一QAコントロールを選択する。たとえば、選択したQAコントロール内で、単一の質問およびその対応するプロンプトが出力に対して選択され、その後、対応する質問に対する代表的な応答に関して文法がアクティブにされる。追加文法も、並行してアクティブにされ、他のコマンド(またはその他の応答)を使用できるようになり、これは許容可能であるとして示されている。認識が行われ、入力データに対する他の処理が完了していると仮定すると、クライアントサイドスクリプトRunSpeechは、再び、次に実行するQAコントロールを確認し始める。RunSpeechの実装例とアルゴリズムについて付録Bで取り上げる。
【０１２０】
コントロールおよびRunSpeechアルゴリズムまたはモジュールの使用は、上述のクライアント/サーバアプリケーションに限定されないが、むしろ他のアプリケーションの抽象化とともに使用するように手直しすることができることに注目されたい。たとえば、クライアントデバイス30でのみ実行される、VoiceXMLなどのアプリケーションは、VoiceXMLブラウザの一部としてまた同じようにして動作する上記の質問および応答などの他の要素またはコントロールをたぶん含むことができる。この場合、上述のRunSpeechアルゴリズムのメカニズムを、特別なスクリプトなしでブラウザによりデフォルトで実行することができる。同様に、有限状態機械などの他のプラットフォームを手直しして、ここで説明したコントロールおよびRunSpeechアルゴリズムまたはモジュールを含むようにできる。
【０１２１】
同期
上述のように随伴コントロール306は、主コントロール302(ページ上の既存コントロール)と関連付けられる。そのため、随伴コントロール306では、ビジネスロジックおよび主コントロール302のプレゼンテーション機能を再利用することができる。これは、主コントロール302に値を格納し、変更を主コントロール302に通知するという2つの方法で行う。
【０１２２】
随伴コントロール306は、バインドと呼ばれるメカニズムを介してその値を主コントロール302と同期させるかまたは関連付ける。バインドにより、レコグナイザから取り出された値は主コントロール302に格納され、たとえば、テキストがテキストボックスに入力されるが、これは応答コントロールの例に示されている。主コントロール302は視覚的プレゼンテーションを行う役割を持つため、マルチモードシナリオで視覚的フィードバックがユーザに送られる。
【０１２３】
随伴コントロール306は、さらに、レコグナイザを介して入力を受け取ったことを主コントロール302に通知するメカニズムも備える。これにより、主コントロール302は、ビジネスロジックを呼び出すなどのアクションを実行することができる。(通知で結局、随伴コントロール306は主コントロール302に書き込む値にコミットすることになるため、実装によりこの通知を細かく制御できるメカニズムを用意する。このコントロールは応答コントロール上のRejectThresholdおよびConfirmThresholdプロパティにより与えられ、このコントロールで音響信頼値を指定し、この数値よりも下回る値をシステムはそれぞれ拒絶するかまたは確認を試みる。)
【０１２４】
本発明は、好ましい実施形態を参照しながら説明したが、当業者は本発明の主旨と範囲を逸脱することなく形式と詳細に変更を加えられることを認識するであろう。
【０１２５】
付録A
1  はじめに
以下のタグは、ドキュメントで音声を入力または出力媒体として使用するためのマークアップ要素セットである。タグは、自己充足型のXMLとなるように設計されており、HTML、XHTML、cHTML、SMIL、WMLなどのSGML派生マークアップ言語に埋め込むことができる。ここで使用するタグは、ワシントン州レドモンドのMicrosoft Corporationが配布しているメソッド群であるSAPI 5.0と似ている。タグ、要素、イベント、属性、プロパティ、戻り値などは、例にすぎず、制限するものとみなすべきではない。ここで音声およびDTMF認識について例を挙げているが、似ているタグは他の形式の認識についても提供できる。
【０１２６】
ここ説明する主要な要素を以下に示す。
【０１２７】
【数１５】
2009059378.tif 000018
【０１２８】
2  Reco
Reco要素は、可能なユーザ入力および入力結果を処理するための手段を指定するために使用する。したがって、その主要な要素は<grammar>および<bind>であり、レコグナイザのプロパティを設定するためのリソースを含む。
【０１２９】
Reco要素は、StartおよびStopメソッドを介してアップレベルブラウザでプログラムによりアクティブにされるか、またはSMILコマンドを使用してSMIL対応ブラウザによりアクティブにされる。これらは、ページ上に存在することによりダウンレベルブラウザ(つまり、スクリプト非対応ブラウザ)で宣言的にアクティブと見なされる。複数の文法を並行してアクティブにするため、複数のReco要素を同時にアクティブであると考えることができる。
【０１３０】
Recoはさらに、特定のモード-「自動」、「単一」、「複数」-があり、使用可能にする認識シナリオの種類および認識プラットフォームの動作を区別することもできる。
【０１３１】
2.1  Recoコンテンツ
Reco要素には、1つまたは複数の文法およびオプションで認識の結果を検査し関連する部分を、含むページ内の値にコピーする一組のバインド要素が含まれる。
【０１３２】
アップレベルブラウザでは、Recoは個々の文法規則のプログラムによるアクティブ化と非アクティブ化をサポートする。また、文法のすべての上位規則は認識コンテキストに対してデフォルトでアクティブになっていることに注意されたい。
【０１３３】
2.1.1  <grammar>要素
文法要素を使用し、インラインでまたはsrc属性を使用して参照することで文法を指定する。通常、少なくとも1つの文法(インラインまたは参照)を指定する。インライン文法(Inline grammars)は、テキストベースの文法形式であり、参照文法(referenced grammars)はテキストベースまたはバイナリ型である。複数の文法要素を指定することもできる。複数の文法要素を指定した場合、文法内の規則は同じ文法内の特別規則として追加される。同じ名前の規則があれば、上書きされる。
【０１３４】
属性:
・src:インライン文法が指定されている場合、オプション。含める文法のURI。文法のすべての上位規則は認識コンテキストに対してデフォルトでアクティブになっていることに注意されたい。
・langID:オプション。音声エンジンで使用する言語を示す文字列。文字列の形式は、xml:langの定義に従う。たとえば、langID="en-us"は米国英語を表す。この属性は、langIDが文法URIで指定されていない場合にのみ有効である。指定されていない場合、米国英語がデフォルト値である。
【０１３５】
langIDが複数の場所で指定されている場合、langIDは最低範囲からの優先順位に従う-リモート文法ファイル(つまり、言語idは文法ファイル内で指定する)の後に文法要素が続き、その後にreco要素が続く。
【０１３６】
【数１６】
2009059378.tif 000019
【０１３７】
src参照文法とインライン文法の両方を指定した場合、インライン規則が参照規則に追加され、同じ名前の規則があればそれは上書きされる。
【０１３８】
2.1.2  <bind>要素
bind要素は、認識結果から値をページにバインドする場合に使用する。
【０１３９】
bind要素によって消費される認識結果は、認識結果を指定するための意味論的マークアップ言語(SML)を含むXMLドキュメントとすることができる。そのコンテンツには、意味論的値、話された実際の単語、および信頼度得点が含まれる。SMLは、さらに、他の認識選択も含むことができる(N最良認識結果の場合と同様)。発話「I'd like to travel from Seattle to Boston」のサンプルSMLドキュメントを以下に示す。
【０１４０】
【数１７】
2009059378.tif 000020
【０１４１】
文法内認識はXMLドキュメント-意味論的マークアップ言語では、SML-を出力すると仮定されているので、SMLドキュメントからバインドされる値はXPathクエリを使用して参照される。また、値がバインドされるページ内の要素は一意に識別されるため(フォームコントロールである可能性がある)、これらのターゲット要素は直接参照される。
【０１４２】
属性:
・targetElement:必須。SMLからの値内容が割り当てられる要素(W3C SMIL 2.0の場合と同様)。
・targetAttribute:オプション。SMLからの値内容が割り当てられるターゲット要素の属性(SMIL 2.0のattributeName属性の場合と同様)。指定されていない場合、「value」がデフォルト値である。
・test:オプション。認識結果を割り当てる際の条件を示すXMLパターン(W3C XML DOM仕様で規定されている)文字列。デフォルトの条件は真である。
・value:必須。ターゲット要素に割り当てる認識結果ドキュメントから値を指定するXPATH(W3C XML DOM仕様で規定されている)文字列。
【０１４３】
例:
上記のSML戻り値が与えられると、以下のreco要素はbindを使用してorigin_cityとdest_cityの中の値をターゲットページ要素txtBoxOriginおよびtxtBoxDestに転送する。
【０１４４】
【数１８】
2009059378.tif 000021
【０１４５】
このバインドは、次の例のように、条件付きの場合があり、バインド操作の事前条件としてdest_city結果の信頼属性についてテストを実行する。
【０１４６】
【数１９】
2009059378.tif 000022
【０１４７】
bind要素は、ダウンレベルブラウザまたはアップレベルブラウザ上で認識結果を処理するための単純な宣言的手段である。より複雑な処理については、アップレベルブラウザによってサポートされているreco DOMオブジェクトがonRecoイベントハンドラを実装し、プログラムによるスクリプト解析および戻された認識結果の後処理を可能にする。
【０１４８】
2.2  属性およびプロパティ
以下の属性は、すべてのブラウザでサポートされており、プロパティはアップレベルブラウザでサポートされている。
【０１４９】
2.2.1  属性
Recoの以下の属性は、ダイアログターンの音声レコグナイザを設定する場合に使用する。
・initialTimeout:オプション。認識の開始から発声の検出までのミリ秒単位の時間。この値は、認識プラットフォームに渡され、この値を超えると、認識プラットフォームからonSilenceイベントが送られる(2.4.2を参照のこと)。指定していない場合、音声プラットフォームはデフォルト値を使用する。
・babbieTimeout:オプション。レコグナイザが音声検出後結果を返さなければならないミリ秒単位の期間。recoが自動および単一モードの場合、これは音声検出から停止コールまでの期間に適用される。recoが「複数」モードの場合、このタイムアウトは音声検出から各認識の返却までの期間に適用されるが、要するに、この期間は結果またはその他のイベントを返すごとにリスタートする。この値を超えた場合、エラーが発生したかどうかに応じて異なるイベントがスローされる。レコグナイザはまだオーディオを処理している場合、たとえば、発話が例外的に長い場合、onNoRecoイベントがスローされ、ステータスコード13が返される(2.4.4を参照)。ただし、他の何らかの理由によりこのタイムアウト値を超えた場合、レコグナイザのエラーが発声する可能性が高くなり、onTimeoutイベントがスローされる。指定していない場合、音声プラットフォームは、デフォルト値として内部値を使用する。
・maxTimeout:オプション。認識開始からブラウザに結果が返されるまでのミリ秒単位の期間。この値を超えた場合、ブラウザによってonTimeoutイベントがスローされる、これにより分散環境でのネットワークまたはレコグナイザの障害に対処する。recoが「複数」モードの場合、babbleTimeoutの場合のように、各認識結果が返されるごと、または他のイベントの後にこの期間が再スタートする。maxTimeout属性はinitialTimeoutとbabbleTimeoutの合計以上でなければならないことに注意されたい。指定していない場合、この値がブラウザデフォルト値になる。
・endSilence:オプション。Recoが自動モードの場合、認識結果が返される前の音声がない状態でなければならない発話の終わりの後のミリ秒単位の無音期間。自動以外のモードのrecoについては無視される。指定されていない場合、デフォルト値はプラットフォームの内部値である。
・reject:オプション。この値よりも小さいときにプラットフォームが「no reco」イベントをスローする認識拒絶しきい値。指定していない場合、音声プラットフォームはデフォルト値を使用する。信頼度得点の範囲は0から100(整数)までである。拒絶値は間に入る。
・server:オプション。音声プラットフォームURI(タグインタプリタおよび認識プラットフォームが同じ場所に配置されていない場合に使用する)。値の例として、server=protocol://yourspeechplatformがある。アプリケーション作成者は、クエリ文字列をURI文字列に追加する、たとえばprotocol://yourspeechplatform?bargeinEnergyThreshold=0.5とすることで、音声プラットフォーム固有の設定を行うこともできる。
・langID:オプション。音声エンジンで使用する言語を示す文字列。文字列の形式は、xml:langの定義に従う。たとえば、langID="en-us"は米国英語を表す。この属性は、langIDが文法要素で指定されていない場合にのみ有効である(2.1.1を参照)。
・mode:オプション。従うべき認識モードを指定する文字列。指定されていない場合、「automatic」モードがデフォルト値である。
【０１５０】
2.2.2  プロパティ
以下のプロパティには、認識プロセスによって返される結果が格納される(これらは、アップレベルブラウザによってサポートされている)。
・recoResult読み取り専用。2.1.2で説明されているように、意味論的マークアップ言語(SML)を含むXML DOMノードオブジェクト内に保持される認識の結果。認識がない場合、プロパティはNULLを返す。
・text読み取り専用。認識された単語のテキストを保持する文字列(つまり、recoResult内のSML認識戻り値の最高レベルの要素のテキスト属性のコンテンツに対する速記)。
・status:読み取り専用。認識プラットフォームによって返されるステータスコード。可能な値は、認識成功を表す0、または-1から-4の失敗値(Startメソッド(2.3.1項)およびActivateメソッド(2.3.4項)で可能な例外で定義されている)、およびレコグナイザイベントの受け取り時に設定される-11から-15までのステータス(2.4を参照)。
【０１５１】
2.3  オブジェクトメソッド
Recoアクティブ化および文法アクティブ化は、RecoのDOMオブジェクト内の以下のメソッドを使用して制御できる。これらのメソッドを使用することで、アップレベルブラウザはRecoオブジェクトの起動および停止、進行中の認識のキャンセル、および個別の文法最上位規則のアクティブ化および非アクティブ化を実行できる(アップレベルブラウザのみ)。
【０１５２】
2.3.1  Start
Startメソッドは、明示的に非アクティブ化されていない認識コンテキストに対するすべての最上位規則をアクティブな文法として使用し、認識プロセスを開始する。
【０１５３】
構文:
Object.Start( )
戻り値:
なし。
【０１５４】
例外:
このメソッドは、0以外のステータスコードを設定し、失敗した場合にonNoRecoイベントが起動する。考えられる失敗としては、文法がない(recoステータス=-1)状況、文法をコンパイルできなかったなどさまざまな理由が考えられる文法をロードできなかった状況、URIが存在していない(recoステータス=-2)状況、または音声プラットフォームエラー(recoステータス=-3)状況がある。
【０１５５】
2.3.2  Stop
Stopメソッドは、認識プロセスを終了させる呼び出しである。Recoオブジェクトは音声記録を停止し、レコグナイザは記録が停止された時点までに受け取った音声の認識結果を返す。Recoで使用しているすべての認識リソースは解放され、その文法は非アクティブ化される。(自動モードでは標準的な認識に対してはこのメソッドを明示的に使用する必要はないが、これは、レコグナイザ自体が安全なセンテンスを認識した後終点検出時にrecoオブジェクトを停止するからであることに注目されたい。)Recoが起動されていない場合、この呼び出しは生じない。
【０１５６】
構文:
Object.Stop( )
戻り値:
なし。
【０１５７】
例外:
なし。
【０１５８】
2.3.3  Cancel
Cancelメソッドは、レコグナイザに音声を送る操作を停止し、文法を非アクティブ化し、レコグナイザを解放し、認識結果を破棄する。ブラウザは、キャンセルされた認識の認識結果を破棄する。レコグナイザが起動されていない場合、この呼び出しは生じない。
【０１５９】
構文:
Object.Cancel( )
戻り値:
なし。
【０１６０】
例外:
なし。
【０１６１】
2.3.4  Activate
Activateメソッドは、文脈自由文法(CFG)の最上位規則をアクティブにする。「開始した」認識プロセスで有効にならないので、認識が開始する前にアクティブ化を呼び出す必要がある。明示的に非アクティブ化されていない認識コンテキストに対する文法最上位規則はすべて、すでにアクティブになっているものとして扱われることに注意されたい。
【０１６２】
構文:
Object.Activate(strName);
パラメータ:
o strName:必須。アクティブにする規則名。
【０１６３】
戻り値:
なし。
【０１６４】
例外:
なし。
【０１６５】
2.3.5  Deactivate
Deactivateメソッドは、文法の最上位規則を非アクティブにする。規則が存在していない場合、このメソッドは効果がない。
【０１６６】
構文:
Object.Deactivate(strName);
パラメータ:
o strName:必須。非アクティブにする規則名。空の文字列はすべての規則を非アクティブにする。
【０１６７】
戻り値
なし。
【０１６８】
例外
なし。
【０１６９】
2.4  Recoイベント
Reco DOMオブジェクトは他のイベントをサポートしており、ハンドラはreco要素の属性として指定することができる。
【０１７０】
2.4.1  onReco:
このイベントは、レコグナイザにブラウザで利用できる認識結果がある場合に起動する。自動モードでのrecoでは、このイベントにより、認識プロセスが自動的に停止し、リソースがクリアされる(2.3.2を参照)。OnRecoは、通常、認識結果のプログラムによる分析と結果を処理してページに挿入する操作に使用される。
【０１７１】
【表２】
2009059378.tif 000023
【０１７２】
【表３】
2009059378.tif 000024
【０１７３】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる(以下の例のイベントオブジェクトの使用を参照のこと)。
【０１７４】
例
以下のHTML断片では、onRecoを使用して、認識結果を解析し、値を適切なフィールドに割り当てるスクリプトを呼び出す。
【０１７５】
【数２０】
2009059378.tif 000025
【０１７６】
【数２１】
2009059378.tif 000026
【０１７７】
2.4.2  onSilence:
onSilenceは、RecoのinitialTimeout属性で指定された持続時間の前に認識プラットフォームによって音声がないことを検出するイベントを処理する(2.2.1を参照)。自動認識モードの場合に、このイベントにより認識プロセスが自動的にキャンセルされる。
【０１７８】
【表４】
2009059378.tif 000027
【０１７９】
【表５】
2009059378.tif 000028
【０１８０】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０１８１】
2.4.3  onTimeout
onTimeoutは、通常音声プラットフォームからのエラーを反映する2種類のイベントを処理する。
【０１８２】
・認識が完了する前にmaxtime属性(2.2.1を参照)で指定されている期間が期限切れになったことを知らせるタグインタプリタによりスローされたイベントを処理する。このイベントは、通常、分散アーキテクチャで発生する可能性のある問題を反映する。
・また、(ii)認識が開始したがbabbleTimeoutによって指定された期間内に認識が行われずに処理が停止したときに音声認識プラットフォームによってスローされるイベントを処理する。
【０１８３】
このイベントにより、認識プロセスが自動的にキャンセルされる。
【０１８４】
【表６】
2009059378.tif 000029
【０１８５】
【表７】
2009059378.tif 000030
【０１８６】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０１８７】
2.4.4  onNoReco:
onNoRecoは、有効な認識結果を返すことができない場合に音声認識プラットフォームによってスローされるイベント用のハンドラである。このような状況が発生するさまざまなケースをステータスコードで区別する。このイベントにより、認識プロセスが自動的に停止される。
【０１８８】
【表８】
2009059378.tif 000031
【０１８９】
【表９】
2009059378.tif 000032
【０１９０】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０１９１】
3  プロンプト
プロンプト要素を使用して、システム出力を指定する。そのコンテンツは以下のうちの1つまたは複数である。
・韻律的なまたはその他の音声出力情報でマークアップできるインラインまたは参照テキスト。
・含有するドキュメントからレンダリング時に取り出した変数値。
・オーディオファイルへのリンク。
【０１９２】
プロンプト要素は、ダウンレベルブラウザによって宣言的に解釈するか(SMILコマンドによってアクティブにする)、またはアップレベルブラウザのオブジェクトメソッドにより宣言的に解釈することができる。
【０１９３】
3.1  プロンプトコンテンツ
prompt要素は、システム出力のリソースを、テキストまたはオーディオファイルへの参照またはその両方として含む。
【０１９４】
単純なプロンプトは、出力に必要なテキストのみを指定する必要がある。例:
【０１９５】
【数２２】
2009059378.tif 000033
【０１９６】
この単純なテキストは、後述の種類のマークアップをさらに含むことができる。
【０１９７】
3.1.1  音声合成マークアップ
音声合成マークアップ言語の形式は、プロンプト要素の内側で使用することがきる。(この形式は、3.2.1で説明している「tts」属性で指定することができる。)
以下の例は、テキスト内のいくつかの単語を強調する命令を含むテキストを示している。
【０１９８】
【数２３】
2009059378.tif 000034
【０１９９】
3.1.2  動的コンテンツ
プロンプトの実際のコンテンツはプロンプト出力する直前に計算する必要がある。たとえば、特定の値を確認するには、変数内の値の参照を解除する必要がある。value要素はこの目的にも使用できる。
【０２００】
value要素
・value:オプション。ドキュメント内の要素の値を取り出す。
【０２０１】
属性:
・targetElement:オプション。hrefまたはtargetElementのいずれかを指定する必要がある。取り出す値を含む要素のid。
・targetAttribute:オプション。値が取り出される要素の属性。
・href:オプション。オーディオセグメントのURI。hrefは、両方が存在する場合targetElementを指定変更する。
【０２０２】
targetElement属性を使用して、含むドキュメント内の要素を参照する。idがtargetElementで指定されている要素のコンテンツが合成するテキスト内に挿入される。目的のコンテンツが要素の属性内に保持されている場合、targetAttribute属性を使用して、targetElement上の必要な属性を指定することができる。これは、たとえば、HTML形式のコントロール内の値の参照を解除する場合に使用する。次の説明では、「txtBoxOrigin」および「txtBoxDest」要素の「value」属性がプロンプトの出力前にテキストに挿入される。
【０２０３】
【数２４】
2009059378.tif 000035
【０２０４】
3.1.3  オーディオファイル
またvalue要素は、合成されたプロンプト代わりに、または合成されたプロンプト内で再生するために事前記録されたオーディオファイルを参照する場合にも使用できる。以下の例では、プロンプトの終わりにビープ音を再生する。
【０２０５】
【数２５】
2009059378.tif 000036
【０２０６】
3.1.4  参照プロンプト
次のように、コンテンツをインラインで指定する代わりに、src属性を空の要素とともに使用してURI経由で外部コンテンツを参照することができる。
【０２０７】
【数２６】
2009059378.tif 000037
【０２０８】
src属性のターゲットは、インラインプロンプトに対して指定された上記のコンテンツのどれかまたはすべてを保持することができる。
【０２０９】
3.2  属性およびプロパティ
prompt要素は、以下の属性(ダウンレベルブラウザ)およびプロパティ(ダウンレベルブラウザおよびアップレベルブラウザ)を保持する。
【０２１０】
3.2.1  属性
・tts:オプション。テキスト音声合成用のマークアップ言語タイプ。デフォルトは「SAPI 5」である。
・src:インラインプロンプトが指定されている場合、オプション。参照されているプロンプトのURI(3.1.4を参照)。
・bargein:オプション。整数。プロンプトの開始から人間の聞き手が再生を中断できるまでのミリ秒単位の期間。デフォルトは無限大、つまりbargeinを許可していない。Bargein=0だと、bargeinが直ちに始まる。これは、プラットフォームでサポートしているどのような種類のbarge-inにも適用される。recoが起動したときにどれが有効になっているかに応じてキーワードまたはエネルギーベースのbargein時間をこの方法で設定できる。
・prefetch:オプション。ページがロードされたときにプロンプトを即座に合成しブラウザにキャッシュするかどうかを示すブール値のフラグ。デフォルトは偽である。
【０２１１】
3.2.2  プロパティ
アップレベルブラウザは、プロンプトのDOMオブジェクトで以下のプロパティをサポートしている。
・bookmark:読み取り専用。最後に出会った合成ブックマークのテキストを記録する文字列オブジェクト。
・status:読み取り専用。音声プラットフォームによって返されるステータスコード。
【０２１２】
3.3  プロンプトメソッド
プロンプト再生は、プロンプトのDOMオブジェクト内の以下のメソッドを使用して制御できる。この方法では、アップレベルブラウザはプロンプトオブジェクトの起動および停止、進行中のプロンプトの一時停止および再開、および合成された音声の速度と音量の変更を行うことができる。
【０２１３】
3.3.1  Start
プロンプトの再生を開始する。引数が指定されていない限り、このメソッドはオブジェクトのコンテンツを再生する。単一のプロンプトオブジェクトのみが、所定の時刻に「起動されている」と見なされ、したがって、Startを連続して呼び出すと、すべての再生が順番に実行される。
【０２１４】
構文:
Object.Start([strText]);
パラメータ:
o strText:シンセサイザーに送るテキスト。存在する場合、この引数によりオブジェクトのコンテンツが指定変更される。
戻り値:
なし。
【０２１５】
例外:
status=-1に設定すると、オーディオバッファがすでにサーバによって解放されているとしてもonCompleteイベントを起動する。
【０２１６】
3.3.2  Pause
オーディオバッファをフラッシュせずに再生を一時停止する。このメソッドは、再生が一時停止または停止状態の場合には効果がない。
【０２１７】
構文:
Object.Pause( );
戻り値:
なし。
【０２１８】
例外:
なし。
【０２１９】
3.3.3  Resume
オーディオバッファをフラッシュせずに再生を再開する。このメソッドは、再生が一時停止状態でなかった場合には効果がない。
【０２２０】
構文:
Object.Resume( );
戻り値:
なし。
【０２２１】
例外:
再開が失敗すると例外をスローする。
【０２２２】
3.3.4  Stop
再生が停止していなければ再生を停止し、オーディオバッファをフラッシュする。再生がすでに停止している場合、このメソッドは単にオーディオバッファをフラッシュするだけである。
【０２２３】
構文:
Object.Stop( );
戻り値:
なし。
【０２２４】
例外:
なし。
【０２２５】
3.3.5  Change
再生の速度および/または音量を変更する。再生中にchangeを呼び出せる。
【０２２６】
構文:
Object.Change(speed, volume);
パラメータ:
o speed:必須。変更する係数。Speed=2.0とすると現在の速度が倍になり、speed=0.5とすると現在の速度が半分になり、speed=0とするとデフォルト値に戻る。
o volume:必須。変更する係数。Volume=2.0とすると現在の音量が倍になり、Volume=0.5とすると現在の音量が半分になり、Volume=0とするとデフォルト値に戻る。
【０２２７】
戻り値:
なし。
【０２２８】
例外:
なし。
【０２２９】
3.3.6  プロンプトコントロールの例
以下の例は、上記のメソッドを使用するプロンプトのコントロールをキーワードbarge-inメカニズムをサポートしていないプラットフォームに対しオーサリングする方法を示している。
【０２３０】
【数２７】
2009059378.tif 000038
【０２３１】
3.4  プロンプトイベント
プロンプトDOMオブジェクトは他のイベントをサポートしており、ハンドラはprompt要素の属性として指定することができる。
【０２３２】
3.4.1  onBookmark
合成ブックマークが見つかったときに発生する。このイベントでは、再生の一時停止は行われない。
【０２３３】
【表１０】
2009059378.tif 000039
【０２３４】
【表１１】
2009059378.tif 000040
【０２３５】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２３６】
3.4.2  onBargein:
ユーザのbarge-inイベントが検出されたときに発生する。(barge-inイベントを構成するもの、たとえば、エネルギー検出やキーワードの認識を決定する操作はプラットフォームに任されることに注意されたい。)このイベントハンドラを指定しても、barge-inは自動的にオンにならない。
【０２３７】
【表１２】
2009059378.tif 000041
【０２３８】
【表１３】
2009059378.tif 000042
【０２３９】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２４０】
3.4.3  onComplete:
プロンプト再生が終わりに到達したか例外(上で定義したような)が発生したときに発生する。
【０２４１】
【表１４】
2009059378.tif 000043
【０２４２】
【表１５】
2009059378.tif 000044
【０２４３】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２４４】
3.4.4  ブックマークとイベントの使用
以下の例は、ブックマークイベントを使用して、プロンプト出力中にbargeinがいつ発生するかということに関してユーザ応答の意味-出発地の市への訂正または目的地の市の指定のいずれか-を判別する方法を示している。onBargeinハンドラは、プロンプトで見つかった最後のブックマークにグローバルな「マーク」変数を設定するスクリプトを呼び出し、この「マーク」の値をrecoの後処理関数(「heard」)で使用して正しい値を設定する。
【０２４５】
【数２８】
2009059378.tif 000045
【０２４６】
4  DTMF
DTMF認識オブジェクトを作成する。インラインマークアップ言語構文を使用してまたはスクリプト作成でオブジェクトをインスタンス化することができる。DTMFがアクティブにされると、プロンプトオブジェクトはbarge-inイベントを発生する。DTMF認識に関して後述するタグおよびイベント発生とセクション5で説明した呼び出しコントロールは一般に音声ブラウザ216とメディアサーバ214との間の相互作用に関係することに注意されたい。
【０２４７】
4.1  コンテンツ
・dtmf grammar:インライン文法用。
・bind:DTMF変換結果を適切なフィールドに割り当てる。
属性:
・targetElement:必須。部分的認識結果の割り当て先の要素(比較:W3C SMIL 2.0の場合と同様)。
・targetAttribute:認識結果の割り当て先のターゲット要素の属性(比較:SMIL 2.0の場合と同様)。デフォルトは「value」である。
・test:割り当ての条件。デフォルトは真である。
【０２４８】
例1:キーをテキストにマップする。
【０２４９】
【数２９】
2009059378.tif 000046
【０２５０】
「city_choice」がアクティブになると、ユーザが1を押した場合「Seattle」が入力フィールドに割り当てられ、2を押した場合「Boston」が割り当てられ、それ以外の場合は何も割り当てない。
【０２５１】
例2:複数のフィールドでDTMFを使用する方法。
【０２５２】
【数３０】
2009059378.tif 000047
【０２５３】
このコード例は、複数のフィールドに入力する方法を示している。
【０２５４】
例3:ユーザがDTMFを起動したときに音声およびDTMFの両方の入力を許可し、音声を無効にする方法。
【０２５５】
【数３１】
2009059378.tif 000048
【０２５６】
【数３２】
2009059378.tif 000049
【０２５７】
4.2  属性およびプロパティ
4.2.1  属性
・dtmfgrammar:必須。DTMF文法のURI。
【０２５８】
4.2.2  プロパティ
・DTMFgrammar読み書き。
【０２５９】
文字列変換行列(DTMF文法ともいう)へのDTMFを表すXML DOMノードオブジェクト。デフォルトの文法は以下の通りである。
【０２６０】
【数３３】
2009059378.tif 000050
【０２６１】
・flush
読み書き属性を持つ、アクティブにする前に基盤の電話インターフェースカード上のDTMFバッファを自動的にフラッシュするかどうかを示すブール値フラグ。デフォルトは偽で、先入力を有効にする。
・escape
読み書き。DTMF読み込みセッションを終了するescapeキー。escapeキーはワンキーである。
・numDigits
読み書き。DTMF読み込みセッションを終了するキーストロークの回数。escapeとlengthの両方が指定されている場合、DTMFセッションはいずれかの条件が満たされたときに終了する。
・dtmfResult
ユーザが入力したDTMFキーを格納する読み取り専用文字列。escapeを入力するとescapeが結果に含まれる。
・text
空白類で区切ったトークン文字列を格納する読み取り専用文字列であり、各トークンはDTMF文法に従って変換される。
・initialTimeout
読み書き。最初のDTMFキーストロークを受け取るミリ秒単位のタイムアウト期間。指定されていない場合、デフォルト値は電話プラットフォームの内部設定である。
・interdigitTimeout
読み書き。隣接するDTMFキーストロークに対するミリ秒単位のタイムアウト期間。指定されていない場合、デフォルト値は電話プラットフォームの内部設定である。
【０２６２】
4.3  オブジェクトメソッド:
4.3.1  Start
DTMF割り込みを有効にし、DTMF読み込みセッションを開始する。
【０２６３】
構文:
Object.Start( );
戻り値:
なし
例外:
なし
【０２６４】
4.3.2  Stop
DTMFを無効にする。ただし、ユーザが入力したキーストロークはバッファ内に残る。
【０２６５】
構文:
Object.Stop( );
戻り値:
なし
例外:
なし
【０２６６】
4.3.3  Flush
DTMFバッファをフラッシュする。Flushは、DTMFセッションでは呼び出せない。
【０２６７】
構文:
Object.Flush( );
戻り値:
なし
例外:
なし
【０２６８】
4.4  イベント
4.4.1  onkeypress
DTMFキーが押されたときに発生する。HTMLコントロールから継承されたデフォルトイベントを指定変更する。ユーザがescapeキーを押すと、onKeypressではなくonRecイベントが発生する。
【０２６９】
【表１６】
2009059378.tif 000051
【０２７０】
【表１７】
2009059378.tif 000052
【０２７１】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２７２】
4.4.2  onReco
DTMFセッションが終了したときに発生する。このイベントにより、現在のDTMFオブジェクトが自動的に無効にされる。
【０２７３】
【表１８】
2009059378.tif 000053
【０２７４】
【表１９】
2009059378.tif 000054
【０２７５】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２７６】
4.4.3  onTimeout
タイムアウトになるまでにno phrase finishイベントを受け取ると発生する。このイベントにより、認識プロセスが自動的に停止される。
【０２７７】
【表２０】
2009059378.tif 000055
【０２７８】
【表２１】
2009059378.tif 000056
【０２７９】
イベントプロパティ:
イベントハンドラはプロパティを直接には受け取らないが、ハンドラはイベントオブジェクトに対してデータについてのクエリを実行できる。
【０２８０】
5  CallControlオブジェクト
電話音声ブラウザの電話インターフェース(呼び出し、終端、および接続)を表す。このオブジェクトは、GUIブラウザのウィンドウオブジェクトと同様ネイティブである。そのため、電話オブジェクトの寿命は、ブラウザインスタンス自体と同じである。電話の音声ブラウザは、呼び出しごとに1つずつ電話オブジェクトをインスタンス化する。ユーザは、そのオブジェクトをインスタンス化したり処理したりしない。
【０２８１】
このときに、ファーストパーティ呼び出しコントロールに関係する機能のみがこのオブジェクトを通じて公開される。
【０２８２】
5.1  プロパティ
・address
読み取り専用。XML DOMノードオブジェクト。実装固有。これは、呼び出し側のアドレスである。PSTNについては、ANIとALIの組み合わせである。VoIPについては、これは、呼び出し側のIPアドレスである。
・ringsBeforeAnswer
着信呼び出しに応答するまで電話が鳴り続ける回数。デフォルトは無限大であり、開発者は特に以下のAnswer( )メソッドを使用して電話呼び出しに応答する必要がある。コールセンターではACDを使用して着信電話呼び出しをキューに入れるときに、この数値を0に設定できる。
【０２８３】
5.2  メソッド
注意:ここのメソッドはすべて同期メソッドである。
【０２８４】
5.2.1  Transfer
呼び出しを転送する。ブラインド転送では、転送が完了するとシステムは発信呼を終了し、システムリソースを解放する。
【０２８５】
構文:
telephone.Transfer(strText);
パラメータ:
o strText:必須。意図した受信者のアドレス。
【０２８６】
戻り値:
なし。
【０２８７】
例外:
呼転送が失敗したとき、たとえば、終了側がビジー状態のとき、そのような番号がないとき、ファックスまたは留守番電話が応答したときに、例外をスローする。
【０２８８】
5.2.2  Bridge
サードパーティ転送。呼び出しが転送された後、ブラウザはその呼び出しに割り当てられたリソースを解放することができる。strUIDを使用して転送された呼び出しが戻るときにセッション状態を回復するのはアプリケーション側の役目である。基本の電話プラットフォームは、戻り呼び出しを別のブラウザに回すことができる。呼び出しは、受信者がその呼び出しを終了したときのみ戻る。
【０２８９】
構文:
telephone.Bridge(strText,strUID,[imaxTime]);
パラメータ:
o strText:必須。意図した受信者のアドレス。
【０２９０】
o strUID:必須。現在の呼び出しを一意的に識別するセッションID。転送された呼び出しが送り返されるときに、strUIDがアドレス属性内に表示される。
【０２９１】
o maxTime:オプション。転送された呼び出しの秒単位の最大持続時間。指定されていない場合、デフォルト値はプラットフォームの内部値である。
【０２９２】
戻り値:
なし。
【０２９３】
例外:
なし。
【０２９４】
5.2.3  Answer
電話呼び出しに応答する。
【０２９５】
構文:
telephone.Answer( );
戻り値:
なし。
【０２９６】
例外:
接続がない場合に例外をスローする。この場合、onAnswerイベントは発生しない。
【０２９７】
5.2.4  Hangup
電話呼び出しを終了する。現在呼び出しが進行中でなければ効果はない。
【０２９８】
構文:
telephone.Hangup( );
戻り値:
なし。
【０２９９】
例外:
なし。
【０３００】
5.2.5  Connect
送出されるファーストパーティ電話呼び出しを開始する。
【０３０１】
構文:
telephone.Connect(strText,[iTimeout]);
パラメータ:
o strText:必須。意図した受信者のアドレス。
【０３０２】
o iTimeout:オプション。その試行を放棄するまでのミリ秒単位の時間。指定されていない場合、デフォルト値はプラットフォームの内部値である。
【０３０３】
戻り値:
なし。
【０３０４】
例外:
ビジー信号が発生したり、FAXまたは留守番電話につながったときなど、呼び出しを完了できないときに例外をスローする(注意:ハードウェアでこの機能をサポートしていないことがある)。
【０３０５】
5.2.6  Record
ユーザオーディオをファイルに記録する。
【０３０６】
構文:
telephone.Record(url,endSilence,[maxTimeout],[initialTimeout]);
パラメータ:
o url:必須。記録された結果のurl。
【０３０７】
o endSilence:必須。無音状態が検出された後記録を停止するまでのミリ秒単位の時間。
【０３０８】
o maxTimeout:オプション。記録の秒単位の最長時間。デフォルトはプラットフォーム固有である。
【０３０９】
o initialTimeout:オプション。記録の開始時に許されている無音状態の最長時間(ミリ秒)。
【０３１０】
戻り値:
なし。
【０３１１】
例外:
記録をそのurlに書き込めないときに例外をスローする。
【０３１２】
5.3  イベントハンドラ
電話音声ブラウザを使用するアプリケーション開発者は以下のイベントハンドラを実装することができる。
【０３１３】
5.3.1  onIncoming( )
音声ブラウザが着信電話呼び出しを受けたときに呼び出される。すべての開発者はこのハンドラを使用して、呼び出し側のアドレスを読み込んで、カスタマイズされた機能を呼び出してから、電話呼び出しに応答することができる。
【０３１４】
5.3.2  onAnswer( )
音声ブラウザが着信電話呼び出しに応答するときに呼び出される。
【０３１５】
5.3.3  onHangup( )
ユーザが電話を切ると呼び出される。このイベントは、プログラムがHangupまたはTransferメソッドを呼び出すときに自動的には発生しない。
【０３１６】
5.4  例
次の例は、電話セッションを操作する呼び出しコントロールイベントに接続されるスクリプト作成を示している。
【０３１７】
【数３４】
2009059378.tif 000057
【０３１８】
【数３５】
2009059378.tif 000058
【０３１９】
【数３６】
2009059378.tif 000059
【０３２０】
6  ダイアログの流れの制御
6.1  HTMLおよびスクリプトを使用してダイアログの流れを実装する
この例は、入力ボックスへの値の入力を求め、その入力に対するコンテキスト依存のヘルプを表示する単純なダイアログの流れを実装する方法を示している。これは、HTML入力メカニズム(視覚的ブラウザ内で「ツールチップ」メカニズムとして使用される)のtitle属性を使用して、ヘルププロンプトのコンテンツの形成を補助する。
【０３２１】
【数３７】
2009059378.tif 000060
【０３２２】
【数３８】
2009059378.tif 000061
【０３２３】
【数３９】
2009059378.tif 000062
【０３２４】
6.2  SMILを使用する
以下の例は、SMILメカニズムを使用してプロンプトおよびreco要素をアクティブする方法を示している。
【０３２５】
【数４０】
2009059378.tif 000063
【０３２６】
付録B
1  QA音声コントロール
QAコントロールは、音声機能を接続先の主コントロールに追加する。これのオブジェクトモデルは、付録Aのタグ例のコンテンツモデルの抽象化である。
【０３２７】
1.1  QAコントロール
【０３２８】
【数４１】
2009059378.tif 000064
【０３２９】
1.1.1  Coreプロパティ
string ControlsToSpeechEnable
ControlsToSpeechEnableは、音声対応にする主コントロールのIDのリストを指定する。IDはカンマで区切って並べる。
【０３３０】
1.1.2  アクティブ化メカニズム
int SpeechIndex
SpeechIndexは、QAコントロールの順序付け情報を指定する。これは、RunSpeechで使用する。注意:複数のQAコントロールに同じSpeechIndexがある場合、RunSpeechはソースの順序で実行する。SpeechIndexを指定しているQAコントロールと指定していないQAコントロールがある場合、RunSpeechはまずSpeechIndexの順序でQAコントロールを実行し、次に、ソース順序で実行する。
【０３３１】
string ClientTest
ClientTestは、QAコントロールがRunSpeechアルゴリズムによる選択に使用できると考えられる時期を判別するブール値を返すクライアントサイドスクリプトの関数を指定する。したがって、これを条件として使用してシステム戦略を変更し、QAコントロールのアクティブ化または非アクティブ化をSpeechIndexよりも細かく行うことができる。指定していない場合、QAコントロールはアクティブ化に使用できると見なされる。
【０３３２】
1.1.3  質問、ステートメント、応答、確認、およびコマンド
Question[]Questions
QAコントロールは、ダイアログ作成者によって定義された質問オブジェクトまたはコントロールの配列を含む。各質問コントロールは、通常、システムの機能に関係し、たとえば、値の入力などを求める。各質問コントロールはClientTest属性を使用してアクティブ化機能を指定できるので、アクティブなQAコントロールは別の状況で主コントロールに関する違った種類の質問を行うことができる。たとえば、主要な質問Q_Mainのアクティブ化条件は、対応する主コントロールが値を持たないことであり、Q_GiveHelpのアクティブ化条件は、ユーザがヘルプを要求したばかりであることである。各Questionでは、質問コントロールが出力されるときにアクティブにされるQAコントロール内から応答コントロールを指定できる。
【０３３３】
Statement[]Statement
QAコントロールは、ステートメントオブジェクトまたはコントロールの配列を含む。ステートメントを使用して、初期画面プロンプトなどの情報をリスナーに送る。
【０３３４】
Answer[]Answers
QAコントロールは、応答オブジェクトまたはコントロールの配列を含む。応答コントロールは、QAコントロール内の質問コントロールにより直接、または主コントロールからStartEventによりアクティブにされる。複数の応答が使用される場合、これらは、通常、システム機能への応答を反映し、たとえば、A_MainはQ_Mainへの応答として値を送り、A_ConfirmはConfirmに対しyes/no+訂正を送ることができる。
【０３３５】
Confirm[]Confirm
QAコントロールは、確認オブジェクトまたはコントロールを含むことができる。このオブジェクトは、共通の確認サブダイアログのオーサリングを簡素化するダイアログ作成者に提供されるメカニズムである。
【０３３６】
Command[]Command
Command配列には、コマンドコントロール群が保持される。Commandコントロールは、質問コントロールのない応答コントロールと考えられ、認識に対するその動作はコントロールツリーを下へたどることができる。
【０３３７】
1.2  質問コントロール
質問コントロールは、所定の主コントロールに関係する音声出力に使用される。これは、情報の表示または質問を求める複数のプロンプトと、その質問に対する応答を送ることができる応答コントロールのidのリストを含む。複数の応答コントロールを指定すると、質問がアクティブになると、これらの文法が並行してロードされる。質問コントロールで応答コントロールが指定されていない場合、例外がスローされる。
【０３３８】
【数４２】
2009059378.tif 000065
【０３３９】
string ClientTest
ClientTestは、質問コントロールがQAコントロール内でアクティブであると見なされる状況を判別するブール値を返すクライアントサイドスクリプトの関数を指定する(QAコントロール自体は、評価される質問に対してアクティブでなければならない)。所定のQAコントロールに関して、真の条件を持つ第1の質問コントロールが出力用に選択される。たとえば、この関数を使用して、値を要求する質問(「Which city do you want?」)を出力するか、または確認を試みる質問(「Did you say London?」)を出力するかを決定できる。指定していない場合、質問条件は真であると見なされる。
【０３４０】
Prompt[]Prompts
prompt配列で、後述のpromptオブジェクトのリストを指定する。promptではさらに、選択の条件を(クライアント関数を介して)指定することもでき、RunSpeechの実行中に、条件が真である最初のpromptのみが再生用に選択される。
【０３４１】
String Answers
Answersは、質問に対する可能な応答であるコントロールへのIDによる参照の配列である。質問コントロールが出したプロンプトへの応答としてそれぞれの有効な応答コントロールからの文法をアクティブにする動作をする。
【０３４２】
Integer initialTimeout
認識の開始から発声の検出までのミリ秒単位の時間。この値は、認識プラットフォームに渡され、この値を超えると、認識プラットフォームからonSilenceイベントがスローされる。指定していない場合、音声プラットフォームはデフォルト値を使用する。
【０３４３】
Integer babbleTimeout
認識サーバまたはその他のレコグナイザが音声検出後結果を返さなければならないミリ秒単位の期間。「tap-and-talk」シナリオのrecoの場合、音声検出から認識結果が使用できるようになるまでの期間に適用される。ディクテーションシナリオのrecoの場合、このタイムアウトは音声検出から各認識の返却までの期間に適用されるが、要するに、この期間は結果またはその他のイベントを返すごとにリスタートする。この値を超えると、onClientNoRecoイベントがスローされるが、異なるステータスコードも可能である。検出可能な何らかの種類の認識プラットフォームエラーが発生しており、babbleTimeout期間が経過した場合、onClientNoRecoがスローされるが、ステータスコードは-3である。そうでなければ、レコグナイザがまだオーディオを処理している場合、たとえば、発話が例外的に長い場合、またはユーザがあまりにも長い時間ペンを下げたままにしていた場合、onClientNoRecoイベントがスローされ、ステータスコード-15が返される。babbleTimeoutが指定されていない場合、音声プラットフォームは、デフォルト値として内部値を使用する。
【０３４４】
Integer maxTimeout
認識開始からクライアントデバイスのブラウザに結果が返されるまでのミリ秒単位の期間。この値を超えた場合、ブラウザによってonMaxTimeoutイベントがスローされる、これにより分散環境でのネットワークまたはレコグナイザの障害に対処する。ディクテーションシナリオのrecoの場合、babbleTimeoutの場合のように、各認識結果が返されるごとにまたは他のイベントの後にこの期間がリスタートする。maxTimeout属性はinitialTimeoutとbabbleTimeoutの合計以上でなければならないことに注意されたい。指定していない場合、この値がはブラウザデフォルト値になる。
【０３４５】
bool modal
モードが真に設定されている場合、質問に対する即時応答セット以外の応答はアクティブにされない(つまり、範囲設定されたAnswersは考慮されない)。デフォルトは偽である。たとえば、この属性を使用すると、アプリケーション開発者はクライアントデバイスのユーザに、特定の質問への応答を強制することができる。
【０３４６】
String PromptFunction(prompt)
PromptFunctionは、質問が選択されてからプロンプトが再生されるまでの間に呼び出されるクライアントサイドの関数を指定する。これにより、アプリケーション開発者は、必要になるかもしれないプロンプトに対する土壇場での修正を実行することが可能になる。PromptFunctionは、ターゲットプロンプトのIDを必須パラメータとして受け取る。
【０３４７】
string OnClientNoReco
OnClientNoRecoは、NoReco(マンブル)イベントを受け取ったときに呼び出すクライアントサイドの関数の名前を指定する。
【０３４８】
1.2.1  プロンプトオブジェクト
プロンプトオブジェクトには、プロンプトを再生する方法について情報が格納される。定義されているすべてのプロパティは読み/書きプロパティである。
【０３４９】
【数４３】
2009059378.tif 000066
【０３５０】
int count
countは、プロンプトの選択の際に使用される整数を指定する。プロンプトについて指定したcountの値が質問コントロールのcountの値と一致すると、再生用のプロンプトが選択される。正当な値は0から100である。
【０３５１】
【数４４】
2009059378.tif 000067
【０３５２】
例では、Q_Ask.countが1に等しい場合、第1のプロンプトが再生され、2に等しい(つまり、質問がすでに出力されている)場合、第2のプロンプトが再生される。
【０３５３】
string ClientTest
ClientTestは、アクティブな質問コントロール内のプロンプトが出力用に選択される状況を判別するブール値を返すクライアントサイドスクリプトの関数を指定する。所定の質問コントロールに関して、真の条件を持つ第1のプロンプトが選択される。たとえば、その関数を使用して、プロンプトのテーパリング(tapering)を実装するために使用できる(たとえば、真を返す関数について、ユーザが初心者は「Which city would you like to depart from?」、ベテランには「Which city?」)。指定していない場合、プロンプトの条件は真であると見なされる。
【０３５４】
string InlinePrompt
promptプロパティは、再生するプロンプトのテキストが格納される。これは、prompt要素のコンテンツとして定義される。これはさらに、TTSレンダリング情報や、<value>要素のようなマークアップも含む。ページのすべての部分と同様、prompt出力の動的レンダリングに対して、<script>タグ内にスクリプトコードとして指定することもできる。
【０３５５】
string Source
Sourceは、再生するプロンプトのテキストが取り出されるURLを指定する。インラインプロンプトを指定した場合、このプロパティは無視される。
【０３５６】
Bool BargeIn
BargeInは、プロンプトでbarge-in(プロンプトの再生時にクライアントデバイスのユーザが話し始めた場合)を許可するかどうかを指定する場合に使用する。デフォルトは真である。
【０３５７】
string onClientBargein
onClientBargeinは、bargeinイベントにより呼び出されるクライアントサイドスクリプト関数を指定する。
【０３５８】
string onClientComplete
onClientCompleteは、プロンプトの再生が競合していたときに呼び出されるクライアントサイドスクリプト関数を指定する。
【０３５９】
string OnClientBookmark
OnClientBookmarkは、ブックマークが見つかったときに呼び出すクライアントサイド関数の名前にアクセスする。
【０３６０】
1.2.2  プロンプトの選択
RunSpeechで実行したとき、QAコントロールにより次のようにしてプロンプトが選択される。
【０３６１】
ClientTestと各プロンプトのcount属性を順番に評価する。ClientTestとcountの両方が真である第1のプロンプトを再生する。countがない場合は真とみなす。ClientTestがない場合は真とみなす。
【０３６２】
1.3  ステートメントコントロール
ステートメントコントロールは、文法のアクティブ化が必要ないときに出力される情報提供システムに使用される。これは、音声専用ダイアログで一般的である。playOnce属性が真の場合にステートメントはページごとに1回だけ再生される。
【０３６３】
【数４５】
2009059378.tif 000068
【０３６４】
bool playOnce
playOnce属性は、1ページごとに何回もステートメントコントロールをアクティブにするかどうかを指定する。playOnceはブール値属性で、デフォルト(指定しない場合)はTRUEである、つまり、ステートメントコントロールは一回しか実行されない。たとえば、playOnce属性は、エンドユーザに電子メールメッセージを出力することが目的とするステートメントコントロールで使用することができる。playOnce="False"と設定すると、ダイアログ作成者は電子メールメッセージを読み込む「リピート」機能をページ上で実行することができる。
【０３６５】
string ClientTest
ClientTestは、ステートメントコントロールが出力用に選択される状況を判別するブール値を返すクライアントサイドスクリプトの関数を指定する。RunSpeechは、ClientTestが真に設定されている第1のStatementをアクティブにする。指定していない場合、ClientTestの条件は真であると見なされる。
【０３６６】
String PromptFunction
PromptFunctionは、ステートメントコントロールが選択されてからプロンプトが再生されるまでの間に呼び出されるクライアントサイドの関数を指定する。これにより、作成者は、必要になるかもしれないプロンプトに対する土壇場での修正を実行することが可能になる。
【０３６７】
Prompt[]Prompt
prompt配列で、promptオブジェクトのリストを指定する。promptではさらに、選択の条件を(クライアント関数を介して)指定することもでき、RunSpeechの実行中に、条件が真である最初のpromptのみが再生用に選択される。
【０３６８】
【数４６】
2009059378.tif 000069
【０３６９】
1.4  確認コントロール
確認コントロールは特別な種類の質問コントロールである。他の質問コントロールのすべてのプロパティおよびオブジェクトを保持するが、アクティブ化の仕方が異なる。RunSpeechアルゴリズムが、ControlsToSpeechEnableの応答コントロールのconfirmThresholdにある信頼度得点を確認する.この値が低すぎる場合、確認コントロールがアクティブにされる。応答コントロールの信頼度得点がconfirmThresholdよりも低い場合、バインドが実行されるが、onClientRecoメソッドは呼び出されない。ダイアログ作成者は、QAコントロールことに複数の確認コントロールを指定できる。RunSpeechはClientTestによって指定された関数に基づきアクティブにする確認コントロールを決定する。
【０３７０】
【数４７】
2009059378.tif 000070
【０３７１】
1.5  応答コントロール
応答コントロールは、音声入力リソースおよび機能を指定する場合に使用する。主コントロールに関係する一連の文法を含む。たとえばプロンプトを使用しないマルチモードアプリケーションで、または付加的な応答によってユーザイニシアチブを有効にできる電話アプリケーションで、応答は質問とは無関係に使用できることに注意されたい。応答コントロールは、質問コントロール、トリガイベント、または明示的範囲により直接アクティブにされる。質問コントロールで文法オブジェクトが指定されていない場合、例外がスローされる。
【０３７２】
【数４８】
2009059378.tif 000071
【０３７３】
string Scope
Scopeは、ページ上の名前付き要素のidを保持する。Scopeは、応答コントロール内で使用され、ユーザイニシアチブ(user initiative)(混合タスクイニシアチブ(mixed task initiative):つまり、サービスジャンプの脱線(service jump digressions))文法の使用可能な範囲を定める。応答コントロールでScopeを指定した場合、これは、コンテキストに関係するコントロールのサブツリー内の主コントロールに対応するQAコントロールがアクティブになると必ずアクティブになる。
【０３７４】
string StartEvent
StartEventは、応答コントロールをアクティブにする(Recoオブジェクトを起動する)主コントロールからのイベントの名前を指定する。通常、マルチモードアプリケーション、たとえばtap-and-talkのonMouseDownで使用される。
【０３７５】
string StopEvent
StopEventは、応答コントロールを非アクティブにする(Recoオブジェクトを停止する)主コントロールからのイベントの名前を指定する。通常、マルチモードアプリケーション、たとえばtap-and-talkのonMouseUpで使用される。
【０３７６】
string ClientTest
ClientTestは、Scopeによりまたは質問コントロールにより他の何らかの方法で選択された応答コントロールがアクティブであるとみなす状況を判別するブール値を返すクライアントサイドスクリプトの関数を指定する。たとえば、このテストは、「訂正」応答コントロールが、質問コントロールによりアクティブにされたが混合イニシアチブが望ましくない(受理/否認応答コントロールのみをアクティブのままにする)場合にそれ自体無効になるように確認時に使用することができる。または、サービスジャンプを使用できる範囲設定された応答コントロールにより、ダイアログの他の部分に応じて真または偽となるテストを指定することでより柔軟なアクティブ化の手段を決定できる。指定していない場合、応答コントロールの条件は真であると見なされる。
【０３７７】
Grammar[]Grammars
Grammarsは、文法オブジェクトのリストにアクセスする。
【０３７８】
DTMF[]DTMFs
DTMFは、DTMFオブジェクトの配列を保持する。
【０３７９】
Bind[]Binds
応答コントロールの文法結果(dtmfまたは発話結果)をコントロール値にマップするために必要なバインドオブジェクトのリストを保持する。応答に対して指定されたすべてのバインドは、関連する出力が認識されたときに実行される。バインドが指定されない場合、認識によって返されるSML出力は、QAコントロールのControlsToSpeechEnableで指定されたコントロールにバインドされる。
【０３８０】
string OnClientReco
OnClientRecoは、発話認識結果が使用可能になったときに呼び出すクライアントサイド関数の名前を指定する。
【０３８１】
string OnClientDTMF
OnClientDTMFは、DTMF認識結果が使用可能になったときに呼び出すクライアントサイド関数の名前を保持する。
【０３８２】
boolean autobind
autobindの値は、システムのデフォルトバインドを応答コントロールから返された認識結果について実装するかどうかを決定する。指定されていない場合、デフォルトは真である。  
autobindを偽に設定することは、自動バインドを実行しないようにとのシステムへの命令である。
【０３８３】
string server
server属性は、認識を実行する音声サーバのURIを指定するオプション属性である。この属性は、グローバルな音声サーバ属性のURIを指定変更する。
【０３８４】
integer ConfirmThreshold
信頼度レベルを表す値を保持する属性であって、この信頼度レベルを下回るときに、QAコントロール内で応答が認識された直後に確認コントロールの質問が自動的にトリガされる。正当な値は0-100である。
【０３８５】
bindステートメントとonClientRecoスクリプトが両方とも指定された場合、その結果のTagsは、onClientRecoで指定されたスクリプトの前にバインドが実行されるということを意味することに注意されたい。
【０３８６】
integer RejectThreshold
RejectThresholdは、認識された発話結果を返すと見なされる最低信頼度特定を指定する。全体的な信頼度がこのレベルを下回ると、NoRecoイベントがスローされる。正当な値は0-100である。
【０３８７】
1.5.1  文法
文法オブジェクトは、文法の選択結果およびコンテンツに関する情報と、認識結果を処理する手段に関する情報を格納する。定義されているすべてのプロパティは読み/書きプロパティである。
【０３８８】
【数４９】
2009059378.tif 000072
【０３８９】
string ClientTest
ClientTestプロパティは、文法がアクティブになる条件を判別するクライアントサイドのブール値関数を参照する。応答コントロール内で複数の文法を指定した場合(たとえば、システム/混合イニシアチブを実装したり、ダイアログの動作がまずいときに可能な応答の混乱を減らしたりするために)、RunSpeech実行時に、ClientTest関数が真になる第1の文法をアクティブ化のため選択する。このプロパティを指定していない場合、真が想定される。
【０３９０】
string Source
Sourceは、指定した場合に、ロードする文法のURIにアクセスする。
【０３９１】
string InlineGrammar
InlineGrammarは、インラインに指定した場合に、文法のテキストにアクセスする。このプロパティが空の場合、Source属性は無視される。
【０３９２】
1.5.2  バインド
バインドのオブジェクトモデルは、対となるクライアントサイドのタグに正確に従う。バインドは、発話された文法と単一応答コントロールで返されたDTMF認識結果の両方に対して指定できる。
【０３９３】
【数５０】
2009059378.tif 000073
【０３９４】
string Value
Valueは、ターゲット要素にバインドするテキストを指定する。これは、認識から得られたSML出力上のXPathとして指定される。
【０３９５】
string TargetElement
TargetElementは、バインドステートメントが適用される主コントロールのidを指定する。指定されていない場合、これは関連するQAコントロールのControlsToSpeechEnableであると想定される。
【０３９６】
string TargetAttribute
TargetAttributeは、値をバインドするTargetElementコントロール上の属性を指定する。指定されていない場合、これはターゲット要素のTextプロパティであると想定される。
【０３９７】
string Test
このTest属性は、バインドメカニズムで真に評価されなければならない条件を指定する。これは、認識から得られたSML出力上のXMLパターンとして指定される。
【０３９８】
1.5.2.1  自動バインド
音声対応主コントロールに返される認識結果に対するデフォルトの動作では、いくつかのプロパティをその主コントロールにバインドする。この動作は、ターン(および偶数ページ)での主コントロールからの認識結果を調べるダイアログコントロールで使用される。応答コントロールは、認識結果を受け取った後以下のアクションを実行する。
【０３９９】
1.SML出力ツリーを主コントロールのSML属性にバインドする
2.発話のテキストを主コントロールのSpokenText属性にバインドする
3.レコグナイザによって返された信頼度得点を主コントロールのConfidence属性にバインドする
autobind="False"属性が応答コントロール上で指定されていない限り、応答コントロールは主コントロールに以下のアクションを実行する。
【０４００】
1.SML出力ツリーをSML属性にバインドする
2.発話のテキストをSpokenText属性にバインドする
3.レコグナイザによって返された信頼度得点をConfidence属性にバインドする
属性内にすでに保持されている値があれば、上書きされる。自動バインドは、作成者指定のbindコマンドの前に、したがって、onClientRecoスクリプトの前に実行される(さらに、これらのプロパティにバインドすることもできる)。
【０４０１】
1.5.3  DTMF
DTMFは、電話アプリケーション内の応答コントロールで使用することができる。DTMFオブジェクトは本質的に、異なる様相の文法(音声入力文法ではなくキーパッド入力文法)を同じ応答に適用する。DTMFコンテンツモデルは、クライアントサイドで出力するTags DTMF要素のそれと非常によく一致している。DTMF返却結果のバインドメカニズムは、DTMFオブジェクトのtargetAttribute属性を使用して指定される。
【０４０２】
【数５１】
2009059378.tif 000074
【０４０３】
integer firstTimeOut
タイムアウトイベントが発生する前、アクティブ化してから最初のキーの押下まで待つミリ秒数。
【０４０４】
integer interDigitTimeOut
タイムアウトイベントが発生する前、キーの押下間に待つミリ秒数。
【０４０５】
int numDigits
DTMF認識中に許可されるキー入力の最大回数。
【０４０６】
bool flush
認識が開始する前に電話サーバのDTMFバッファをフラッシュするかどうかを指定するフラグ。flushを偽に設定すると、認識/ページ呼び出しの間にDTMFキー入力を格納し、ユーザによる「先入力」を可能にできる。
【０４０７】
string escape
DTMF認識を終了するために使用するキーの文字列値(たとえば、「#」)を保持する。
【０４０８】
string targetAttribute
TargetAttributeは、値をバインドする主コントロール上のプロパティを指定する。指定されていない場合、これは主コントロールのTextプロパティであると想定される。
【０４０９】
string ClientTest
ClientTestプロパティは、DTMF文法がアクティブになる条件を判別するクライアントサイドのブール値関数を参照する。DTMFオブジェクト内で複数の文法を指定した場合、RunSpeech実行時に、ClientTest関数が真である最初の文法のみがアクティブする対象として選択される。このプロパティを指定していない場合、真が想定される。
【０４１０】
1.5.4  DTMFGrammar
DTMFGrammarは、キーをそのキーと関連する出力値にマップする。以下の例は、「1」および「2」のキーをテキスト出力値にマップする方法を示している。
【０４１１】
【数５２】
2009059378.tif 000075
【０４１２】
1.6  コマンドコントロール
コマンドコントロールは、QAコントロール内で定義できる応答コントロールの特別なバリエーションである。コマンドコントロールは、すぐに質問に対する応答にならない、認識結果を主コントロールにバインドする必要のない形式のユーザ入力(たとえば、ヘルプ、リピート、キャンセル)である。QAコントロールでアクティブ化の範囲を指定する場合、コマンド文法がその範囲内のすべてのQAコントロールについてアクティブである。したがって、直接質問コントロールまたはイベントによりコマンドをアクティブにする必要はなく、その文法は応答コントロールの構築とは無関係に並行してアクティブにされる。範囲内で低い位置にあるQAコントロールでの同じ種類のコマンドコントロールは、コンテキストに依存する動作(さらに必要ならば、異なる/拡張文法も)で上位のコマンドを指定変更できる。
【０４１３】
【数５３】
2009059378.tif 000076
【０４１４】
string Scope
Scopeは、主コントロールのidを保持する。Scopeは、コマンド文法を使用できる範囲を定めるためにコマンドコントロール内で使用される。コマンドコントロールでScopeを指定した場合、コンテキストに関係するコントロールのサブツリー内の主コントロールに対応するQAコントロールがアクティブになると必ずコマンドの文法もアクティブになる。
【０４１５】
string type
typeは、コマンドの種類(たとえば、「help」、「cancel」など)を指定し、範囲ツリーの下位のレベルで全く同じに入力したコマンドを指定変更できるようにする。この属性では任意の文字列値が使用可能であり、作成者側でtypeを正しく使用するよう気を付ける必要がある。
【０４１６】
integer RejectThreshold
RejectThresholdは、認識でコマンドをトリガするのに必要な認識の最低信頼度レベルを指定する(これは、通常よりも高い信頼度が必要なとき、たとえば「Cancel」コマンドの結果を実行する前に、使用することが多い)。正当な値は0-100である。
【０４１７】
string onClientReco
onCommandは、コマンドコントロールの文法を認識した後実行するクライアントサイドスクリプトの関数を指定する。
【０４１８】
Grammar Grammar
コマンドの実行を監視して待っている文法オブジェクト。
【０４１９】
DTMF DTMF
コマンドをアクティブにするdtmfオブジェクト。
【０４２０】
2  イニシアチブとダイアログの流れの種類
上述のコントロールを使用して、さまざまな形式のイニシアチブを開発することができるが、そのいくつかの例を以下に示す。
【０４２１】
2.1  混合イニシアチブダイアログ
混合イニシアチブダイアログは、1回質問をするだけで複数のコントロールに対する入力を受け付けることができる。たとえば、質問「what are your travel plans」に対する応答で、出発地の市のテキストボックスコントロール、目的地の市のテキストボックスコントロール、およびカレンダーコントロール(「Fly from Puyallup to Yakima on September 30th」)に対する値を指定できる。
【０４２２】
混合イニシアチブダイアログをエンコードするには、混合イニシアチブ文法と関連するバインドステートメントを手書きし、それらを単一のコントロールに適用するのが確実な方法である。
【０４２３】
以下の例は、旅行に関する単純な混合イニシアチブ音声対話操作に使用される単一ページを示している。第1のQAコントロールは、混合イニシアチブ文法およびバインド、および2つの項目の入力を求める関連プロンプトを指定する。第2および第3のQAコントロールは、混合イニシアチブではなく、したがってデフォルトでそれぞれの主コントロールに直接バインドする(そのため、バインドステートメントは不要である)。RunSpeechアルゴリズムは、「SpeechIndex」属性およびその主コントロールが有効な値を保持しているかどうかに基づいてQAコントロールを選択する。
【０４２４】
【数５４】
2009059378.tif 000077
【０４２５】
【数５５】
2009059378.tif 000078
【０４２６】
2.2  複雑な混合イニシアチブ
アプリケーション開発者は、異なるレベルのイニシアチブの同じ質問コントロールに対し複数の応答を指定することができる。必要とされるイニシアチブ設定に応じて、質問をしたときの応答の1つを選択する条件を指定する。以下に例を示す。
【０４２７】
【数５６】
2009059378.tif 000079
【０４２８】
アプリケーション開発者は、さらに、QAコントロールで複数の質問コントロールを指定することもできる。混合イニシアチブスタイルの応答を使用できる質問コントロールもあれば、指向性の高い質問コントロールもある。これらの質問コントロールで条件をオーサリングすることにより、アプリケーション開発者はダイアログの状況に応じて質問を選択できる。
【０４２９】
以下の例では、混合イニシアチブ質問により、同時に2つのテキストボックスの値を要求し(たとえば、「what are your travel plans?」)、混合イニシアチブ応答(たとえば、「from London to Seattle」)を呼び出す。これが失敗した場合、各テキストボックスの値は別々に要求されるが(たとえば、「where do you leave from」と「where are you going to」)、条件によっては混合イニシアチブ文法をそのままアクティブにすることができ、したがってユーザは両方の値を指定できる。
【０４３０】
【数５７】
2009059378.tif 000080
【０４３１】
2.3  ユーザイニシアチブ
コマンドコントロールと同様に、標準QAコントロールもその文法のアクティブ化の範囲を指定することができる。コマンドコントロールのように、このQAコントロールでは、他のQAコントロールがこのコンテキストの範囲内でアクティブ化されると必ず、関連する応答コントロールの文法をアクティブにする。この質問コントロールは、QAコントロール自体がアクティブにされた場合にのみ実行されることに注意されたい。
【０４３２】
【数５８】
2009059378.tif 000081
【０４３３】
これは、「サービスジャンプ」、つまり質問コントロールにすぐには直接関係しないダイアログの一部分に関するユーザ応答を行えるダイアログに使用できる。
【０４３４】
2.4  短いタイムアウト確認
アプリケーション開発者は、確認を普通に作成することができるが、短いタイムアウトを設定する。タイムアウトハンドラでは、現在値を正確に受け付けるコードを用意する。
【０４３５】
【数５９】
2009059378.tif 000082
【０４３６】
2.5  動的なプロンプト構築および編集
promptFunctionスクリプトは、質問コントロールが選択されてから、プロンプトが選択され再生されるまでの間に呼び出される。このため、アプリケーション開発者は土壇場でプロンプトを構築したり修正したりすることができる。以下の例では、これを使用してユーザの経験レベルに応じてプロンプトを変更している。
【０４３７】
【数６０】
2009059378.tif 000083
【０４３８】
2.6  意味関係の使用
意味関係は、onRecoイベントハンドラ内のレコグナイザの結果を調べることにより認識し使用することができる。
【０４３９】
【数６１】
2009059378.tif 000084
【０４４０】
3  RunSpeechの実装と適用
音声専用クライアントに、音声対応ページを適切にレンダリングするのに必要な情報を提供するためのメカニズムが必要である。このようなメカニズムでは、アプリケーション開発者の仕様に従ってダイアログロジックを実行し、ユーザプロンプト機能および文法アクティブ化の状態を維持できる必要がある。
【０４４１】
このようなメカニズムは、マルチモードクライアントには必要ない。マルチモードの場合、音声対応コントロールを含むページはクライアントデバイスのユーザから見える。クライアントデバイスのユーザは、マルチモードパラダイムを使用して、望む順序で視覚的音声対応コントロールに音声入力を行うことができる。
【０４４２】
音声専用クライアントで音声対応ページをレンダリングするために使用するメカニズムが、RunSpeechスクリプトまたはアルゴリズムである。RunSpeechスクリプトは、QAコントロールと後述のSpeechGroupコントロールのSpeechIndex属性に依存する。
【０４４３】
3.1  SpeechControl
実行時に、システムは、サーバコントロールを備えるコントロールスクリプトまたはWebページを解析し、サーバコントロールのツリー構造を作成する。通常、ツリーのルートはPageコントロールである。コントロールスクリプトでカスタムまたはユーザコントロールを使用する場合、このカスタムまたはユーザコントロールの子ツリーが展開される。ツリー内のすべてのノードはIDを持ち、展開時にツリー内に名前の衝突が容易に発生する。名前の衝突の発生に対処するために、システムではというNamingContainer概念を用意している。ツリー内のノードは、NamingContainerを実装し、その子はその名前空間内に存続する。
【０４４４】
QAコントロールは、サーバコントロールツリー内のどこにでも実現できる。SpeechIndexを簡単に処理し、クライアントサイドのレンダリングを管理するために、SpeechGroupコントロールが用意されている。SpeechGroupコントロールは、アプリケーション開発者から隠されている。
【０４４５】
1つのSpeechGroupコントロールが作成され、その子ツリーにQAコントロールを含むすべてのNamingContainerノードに論理的にアタッチされる。QAおよびSpeechGroupコントロールは、その直接のNamingContainerのSpeechGroupのメンバと見なされる。最上位レベルのSpeechGroupコントロールは、Pageオブジェクトにアタッチされる。このメンバ関係により、QAコントロールとSpeechGroupコントロールのツリー-論理的音声ツリー-が論理的に構築される。
【０４４６】
単純な音声対応ページまたはスクリプト(つまり、他のNamingContainerを含まないページ)の場合、ルートのSpeechGroupコントロールのみが生成され、そのページのサーバコントロールツリー内に配置されてから、そのページが音声専用クライアントに送られる。SpeechGroupコントロールは、そのページ上のQAコントロールの個数とレンダリング順序に関する情報を保持する。
【０４４７】
QAコントロールと1つのまたは複数のNamingContainerの組み合わせを含むページでは、複数のSpeechGroupコントロールが生成され、そのページ用のSpeechGroupコントロール(上述のように)と各NamingContainer用のSpeechGroupコントロールが得られる。NamingContainerを含むページでは、ページレベルのSpeechGroupコントロールが、上述のようにQAコントロール情報とさらに複合コントロールの個数とレンダリング順序の情報を保持する。各NamingContainerと関連するSpeechGroupコントロールは各複合コントロール内のQAの個数とレンダリング順序を保持する。
【０４４８】
SpeechGroupコントロールの主な仕事は、各ページ上のQAコントロールとSpeechGroupsのリストおよび/または複合コントロールからなるQAコントロールのリストを保持することである。クライアントサイドマークアップスクリプト(たとえば、HTML)が生成されると、各SpeechGroupはクライアントサイドにQACollectionオブジェクトを書き出す。QACollectionは、QAコントロールとQACollectionsのリストを含む。これは、論理的サーバサイド音声ツリーに対応する。RunSpeechスクリプトが、ページレベルのQACollectionオブジェクトに対し、音声専用ダイアログ処理時に呼び出す次のQAコントロールについてクエリを実行する。
【０４４９】
各ページ上に配置されたページレベルのSpeechGroupコントロールは以下のものに対する役割も持つ。
・要求側クライアントが音声専用クライアントであることを判別する
・各ページ上のすべてのQAコントロールに対する共通スクリプトを生成し、構造をサポートする
第1のSpeechGroupコントロールがレンダリングを行うと、System.Web.UI.Page.Request.Browserプロパティに対し、ブラウザ文字列のクエリが実行される。このプロパティは、ページ上のQAコントロールごとにRenderSpeechHTMLおよびRenderSpeechScriPtメソッドに渡される。QAコントロールは次に、適切なクライアント(マルチモードまたは音声専用)についてレンダリングを行う。
【０４５０】
3.2  SpeechGroupコントロールの作成
サーバサイドページをロードする際に、onLoadイベントがページ上の各コントロールに送られる。ページレベルのSpeechGroupコントロールが、onLoadイベントを受け取った最初のQAコントロールによって作成される。SpeechGroupコントロールの作成は、次のようにして行われる(複合コントロールを含むページを想定する)。
【０４５１】
すべてのQAコントロールがランタイムコードからonLoadイベントを受け取る。QAのonLoad:
・QAのNamingContainer N1を取得する
・N1の子のSpeechGroupを検索する
o すでに存在している場合、QAコントロールをこのSpeechGroupに登録する。onLoadが返る。
o 見つからない場合:
・新しいSpeechGroup G1を作成し、N1の子に挿入する
・N1がPageでなければ、N1のNamingContainer N2を見つける
・N2の子の中のSpeechGroupを検索し、もし存在すれば、それがG2だとするとG1をG2に追加する。存在しなければ、新しいG2を作成し、N2の子に挿入する
・NamingContainerがPage(最上位レベル)になるまで再帰的に繰り返す
サーバサイドページをレンダリングする際に、Renderイベントが音声対応ページに送られる。ページレベルのSpeechGroupコントロールがRenderイベントを受け取ると、RunSpeech.jsを取り込むクライアントサイドスクリプトを生成し、それを最終的にクライアントデバイスに送られるページに挿入する。また、その直接のすべての子を呼び出して、音声関連のHTMLおよびスクリプトをレンダリングする。子がSpeechGroupの場合、その子は次にその子を再び呼び出す。このようにして、サーバのレンダリングはサーバサイドの論理的音声ツリーに沿って実行される。
【０４５２】
SpeechGroupがレンダリングを行うと、その子(QAまたはSpeechGroupのいずれか)が音声HTMLおよびスクリプトをそのSpeechIndexの順序でレンダリングすることができる。しかし、SpeechGroupは隠されており、当然ながらSpeechIndexを持たない。実際、SpeechGroupは、アタッチ先のそのNamingContainerと同じSpeechIndexを持つ。NamingContainerは通常、UserControlまたはその他の視覚的コントロールであり、作成者がSpeechIndexをそのコントロールに設定できる。
【０４５３】
3.3  RunSpeech
RunSpeechは、スクリプトで指定されているロジックまたはクライアント上のロジックを介してダイアログの流れを実現することを目的としている。一実施形態では、RunSpeechは外部スクリプトファイルで指定され、SpeechGroup主コントロールのサーバサイドレンダリングにより生成された単一の行でロードされる。例:
【０４５４】
【数６２】
2009059378.tif 000085
【０４５５】
RunSpeech.jsスクリプトファイルでは、クライアント上でスクリプトは正しくロードされ、正しいバージョンidをもつことなどを確認する手段を公開する必要がある。実際の確認を行うスクリプトは、そのファイルをロードしようとした後実行されるインライン関数としてページクラスにより自動的に生成される。
【０４５６】
外部スクリプトにリンクする手順は、インラインで指定する手順と動的には同等であるが、ブラウザはファイルおよびクリーナーをキャッシュでき、ページが汎用関数でバラバラにならないため、両方とも効率が良い。
【０４５７】
3.4  イベント
3.4.1  イベントの配線
Tap-and-talkのマルチモード機能は、onMouseDownイベントで文法のアクティブ化を調整することにより使用可能にできる。この作業を行う配線スクリプトは、コントロール間の関係に基づきPageにより生成される(QAコントロールのControlsToSpeechEnableプロパティで指定する)。
【０４５８】
たとえば、asp:TextBoxとその随伴QAコントロールが与えられ文法追加する場合、<input>および<reco>要素が各コントロールのRenderメソッドにより出力される。文法アクティブ化コマンドを追加する配線メカニズムは、Pageによって生成されるクライアントサイドスクリプトにより実行され、それにより主コントロールの属性が変更されアクティブ化イベント用の既存のハンドラの前にアクティブ化コマンドが追加される。
【０４５９】
【数６３】
2009059378.tif 000086
【０４６０】
デフォルトで、フックアップはonmousedownおよびonmouseupイベントを介するが、StartEventとStopEventは両方ともWebページの作成者が設定できる。textbox出力は、この修正と無関係に残り、他のハンドラが存在していた場合イベントは通常通り処理される。
【０４６１】
3.4.2  Page Classプロパティ
Pageはさらに、実行時にスクリプトから利用できる以下のプロパティを備える。
【０４６２】
SML-コントロールのIDと認識の結果返される関連するSMLの名前/値のペア。
【０４６３】
SpokenTextコントロールのIDと関連する認識された発話の名前/値のペア。
【０４６４】
Confidence-コントロールのIDとレコグナイザによって返される関連する信頼度の名前/値のペア。
【０４６５】
4  RunSpeechアルゴリズム
RunSpeechアルゴリズムを使用して、クライアントデバイス上のダイアログの流れを駆動する。これは、システムプロンプト機能およびダイアログ管理機能(通常、音声専用ダイアログ)および/または音声入力の処理(音声専用およびマルチモードダイアログ)を備えることができる。これは、すべての関連する音声対応ページ(インライン埋め込めスクリプトと同等)からのURIにより参照されるスクリプトファイルとして指定される。
【０４６６】
音声専用ブラウザ向けのページのレンダリングは、次のようにして実行する。
【０４６７】
RunSpeechモジュールまたは関数は以下のように動作する(RunSpeechはdocument.onreadystateが「complete」になったことに対して呼び出される)。
(1)音声インデックス順序で最初のアクティブなQAコントロールを見つける(QAコントロールがアクティブかどうかを判別する方法については後述する)。
(2)アクティブなQAコントロールがない場合には、そのページをサブミットする。
(3)そうでない場合、QAコントロールを実行する。
【０４６８】
QAコントロールは、次の場合かつその場合に限りアクティブであると見なされる。
(1)QAコントロールのClientTestが存在しないかまたは真の値を返し、かつ
(2)QAコントロールがアクティブな質問コントロールまたはステートメントコントロール(ソース順序でテストされる)を含み、かつ
(3)次のいずれか。
a.QAコントロールがステートメントコントロールのみを含むか、または
b.QAコントロールのControlsToSpeechEnableにより参照されているコントロールの少なくとも1つが空であるかまたはデフォルト値を持つ。
【０４６９】
質問コントロールは、次の場合かつその場合に限りアクティブであると見なされる。
(1)質問コントロールのClientTestが存在しないかまたは真の値を返し、かつ
(2)質問コントロールがアクティブなプロンプトオブジェクトを含む。
【０４７０】
プロンプトオブジェクトは、次の場合かつその場合に限りアクティブであると見なされる。
【０４７１】
(1)プロンプトオブジェクトのClientTestが存在しないかまたは真の値を返し、かつ
(2)プロンプトオブジェクトのCountが存在していないか、または親質問コントロールのCount以下である。
【０４７２】
QAコントロールは次のように実行される。
(1)どの質問コントロールまたはステートメントコントロールがアクティブであるかを判別し、そのCountをインクリメントする。
(2)ステートメントコントロールがアクティブの場合、プロンプトを再生して終了する。
(3)質問コントロールがアクティブの場合、アクティブな応答コントロールおよびコマンドコントロールごとにプロンプトを再生し、Recoを起動する。
【０４７３】
応答コントロールは、次の場合かつその場合に限りアクティブであると見なされる。
(1)応答コントロールのClientTestが存在しないかまたは真の値を返し、かつ
(2)次のいずれか。
a.応答コントロールがアクティブな質問コントロールのAnswers文字列内で参照されていたか、または
b.応答コントロールがScope内にある。
【０４７４】
コマンドコントロールは、次の場合かつその場合に限りアクティブであると見なされる。
(1)Scope内にあり、かつ
(2)範囲ツリー内に低い同じTypeの別のコマンドコントロールがない。
【０４７５】
RunSpeechは、ダイアログの駆動を続けるイベントに依存しており、これまでに説明したように、単一のQAコントロールを実行した後停止する。Prompt.OnComplete、Reco.OnReco、Reco.OnSilence、Reco.OnMaxTimeout、Reco.OnNoRecO用のイベントハンドラが含まれる。それぞれについて次に説明する。
【０４７６】
RunSpeechOnCompleteは以下のように動作する。
(1)アクティブなPromptオブジェクトでOnClientComplete関数を指定している場合、その関数が呼び出される。
(2)アクティブなPromptオブジェクトがステートメントコントロール、またはアクティブな応答コントロールを持たない質問コントロール内に含まれていた場合、RunSpeechを呼び出す。
【０４７７】
RunSpeechOnRecoは以下のように動作する。
(1)何らかのデフォルトのバインド動作が実行され、SMLツリーがSML属性にバインドされ、テキストがControlsToSpeechEnable内の各コントロールのSpokenText属性にバインドされる。
(2)認識結果の信頼度値がアクティブな応答コントロールのConfidenceThresholdよりも低い場合、確認ロジックが実行される。
(3)そうでない場合、アクティブな応答コントロールでOnClientReco関数を指定している場合、その関数が呼び出され、RunSpeechが呼び出される。
【０４７８】
RunSpeechOnRecoは、ControlsToSpeechEnableのSML、SpokenText、およびConfidenceプロパティを作成し設定する役割を持つ。SML、SpokenText、およびConfidenceプロパティは、実行時にスクリプトから利用できる。
【０４７９】
RunSpeechOnSilence、RunSpeechOnMaxTimeout、およびRunspeechOnNoRecoすべて、同じようにして動作する。
(1)該当するOnClientXXX関数が、指定されていれば呼び出される。
(2)RunSpeechが呼び出される。
【０４８０】
最後に、Confirmationロジックが以下のように動作する。
(1)アクティブな応答コントロールの親QAコントロールが確認コントロールを含む場合、最初のアクティブな確認コントロールが見つかる(確認コントロールのアクティブ化は、質問コントロールのアクティブ化と全く同じようにして判別される)。
(2)アクティブな確認コントロールが見つからない場合、RunSpeechが呼び出される。
(3)見つかった場合、QAコントロールが実行され、選択された確認コントロールをアクティブな質問コントロールとする。
【０４８１】
マルチモードブラウザでは、文法のロードとイベントのディスパッチステップのみが実行される。
【図面の簡単な説明】
【０４８２】
【図１】コンピューティングデバイスの動作環境の第1の実施形態の平面図である。
【図２】図1のコンピューティングデバイスのブロック図である。
【図３】汎用コンピュータのブロック図である。
【図４】クライアント/サーバシステムのアーキテクチャのブロック図である。
【図５】クレジットカード情報取得するための表示である。
【図６】ディスプレイおよび音声認識機能備えるクライアント上で実行可能なマークアップ言語のページ例である。
【図７】クライアントサイドマークアップで認識および可聴プロンプト機能を実現するための第1のアプローチを示すブロック図である。
【図８】クライアントサイドマークアップで認識および可聴プロンプト機能を実現するための第2のアプローチを示すブロック図である。
【図９】クライアントサイドマークアップで認識および可聴プロンプト機能を実現するための第3のアプローチを示すブロック図である。
【図１０】随伴コントロールを示すブロック図である。
【図１１】随伴コントロールを示す詳細ブロック図である。
【符号の説明】
【０４８３】
29  マイク
30  データ管理モバイルデバイス
32  ハウジング
33  スタイラス
34  ディスプレイ
35  ボタン
37  アナログ-デジタル(A/D)コンバータ
50  中央処理装置(CPU)
52  無線トランシーバ
54  不揮発性の読み書きランダムアクセスメモリストア
58  読み取り専用メモリ(ROM)
60  通信インターフェース
80  電話
120  汎用コンピュータ
140  処理装置
141  システムバス
150  システムメモリ
151  読み取り専用メモリ(ROM)
153  基本入出力システム
154  オペレーティングシステム
155  アプリケーションプログラム
156  プログラムモジュール
157  プログラムデータ
160  インターフェース
161  ハードディスクドライブ
164  オペレーティングシステム
165  アプリケーションプログラム
166  プログラムモジュール
167  プログラムデータ
170  インターフェース
171  磁気ディスクドライブ
175  光ディスクドライブ
180  ユーザ入力インターフェース
184  モニタ
185  ビデオインターフェス
186  プリンタ
187  スピーカ
188  出力周辺インターフェース
190  ネットワークインターフェースまたはアダプタ
191  ローカルエリアネットワーク(LAN)
192  モデム
193  ワイドエリアネットワーク(WAN)
194  リモートコンピュータ
195  リモートアプリケーションプログラム
200  Webベースの認識機能のアーキテクチャ
202  Webサーバ
204  リモート認識サーバ
209  サーバサイドプラグインモジュール
211  レコグナイザ(recognizer)
212  電話音声ブラウザ(telephony voice browser)
214  メディアサーバ(media server)
216  音声ブラウザ
250  フィールド
252  フィールド
254  フィールド
270  本文部分
272  スクリプト部分
280、282、284  コード部分
290  コントロール
300A  ライブラリ
302  視覚的コントロール
304  視覚的認識/可聴プロンプト機能コントロール
306  随伴コントロール
308  出力コントロール
308A  「Question」コントロール
308B  「Confirmation」コントロール
308C  「Statement」コントロール
310  入力コントロール
310A  「Answer」コントロール
310B  「Command」コントロール
320  「Question/Answer」(以下「QA」とも呼ぶ)コントロール
322  コントロール
324  コントロール
326  線
【図１】
2009059378.tif 000087
【図２】
2009059378.tif 000088
【図３】
2009059378.tif 000089
【図４】
2009059378.tif 000090
【図５】
2009059378.tif 000091
【図６】
2009059378.tif 000092
【図７】
2009059378.tif 000093
【図８】
2009059378.tif 000094
【図９】
2009059378.tif 000095
【図１０】
2009059378.tif 000096
【図１１】
2009059378.tif 000097