(57)【要約】１人またはそれ以上のユーザに対する効果的な会話型コンピューティング環境を提供するために、変化している動作状態において、多モード入力データに従ってフォーカス検出、参照の曖昧性の解決、およびムード分類を実行するためのシステムおよび方法が提供される。
2004538543.tif 000002
【特許請求の範囲】
【請求項１】
多モード会話型コンピューティング・システムであって、該システムが、
ユーザ・インタフェース・サブシステムを備え、該ユーザ・インタフェース・サブシステムが、該ユーザ・インタフェース・サブシステムが配備されている環境から多モード・データを入力するように構成され、前記多モード・データが第１のモードの入力センサに関連するデータと、少なくとも第２のモードの入力センサに関連するデータとを含み、前記環境が１人またはそれ以上のユーザと前記多モード・システムによって制御することができる１つまたはそれ以上の装置とを含み、前記システムが、さらに、
少なくとも１つのプロセッサを備え、該少なくとも１つのプロセッサが前記ユーザ・インタフェース・サブシステムに動作できるように結合され、（ｉ）前記ユーザ・インタフェース・サブシステムから前記多モード入力データの少なくとも一部を受信し、（ｉｉ）前記受信した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行い、および（ｉｉｉ）前記判定された意図、前記判定されたフォーカスおよび前記判定されたムードのうちの少なくとも１つに基づいて、前記環境内に１つまたはそれ以上のアクションの実行を起こさせるように構成され、前記システムが、さらに、
前記少なくとも１つのプロセッサに動作できるように結合されているメモリを備え、該メモリが、前記プロセッサによって行われた前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるようにするために記憶するシステム。
【請求項２】
前記意図の判定が、前記受信した多モード・データの少なくとも一部に基づいて、前記環境において前記１人またはそれ以上のユーザに関連する参照の曖昧性を解決するステップを含む、請求項１に記載のシステム。
【請求項３】
前記意図の判定が、前記受信した多モード・データの少なくとも一部に基づいて、前記環境において前記１つまたはそれ以上の装置に関連する参照の曖昧性を解決するステップを含む、請求項１に記載のシステム。
【請求項４】
前記環境において１つまたはそれ以上のアクションを実行する前記ステップが、前記環境における前記１つまたはそれ以上の装置のうちの少なくとも１つを制御して、前記１人またはそれ以上のユーザの前記判定された意図、前記判定されたフォーカス、および前記判定されたムードのうちの少なくとも１つを実現するステップを含む、請求項１に記載のシステム。
【請求項５】
前記環境において１つまたはそれ以上のアクションを実行する前記ステップが、前記環境における前記１つまたはそれ以上の装置のうちの少なくとも１つを制御して、前記判定のうちの少なくとも１つを行うのを支援するためにユーザ入力をさらに要求するステップを含む、請求項１に記載のシステム。
【請求項６】
前記１つまたはそれ以上のアクションを実行する前記ステップが、さらに、前記システムが前の入力から理解したことを完了、訂正、および明確化することのうちの少なくとも１つを行うためのプロセスを起動するステップを含む、請求項１に記載のシステム。
【請求項７】
前記少なくとも１つのプロセッサが、さらに、前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データを１つまたはそれ以上のイベントに抽象化するように構成される、請求項１に記載のシステム。
【請求項８】
前記少なくとも１つのプロセッサが、さらに、前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データについて１つまたはそれ以上の認識動作を実行するように構成される、請求項１に記載のシステム。
【請求項９】
多モード会話型コンピューティング・システムであって、該システムが、
ユーザ・インタフェース・サブシステムを備え、該ユーザ・インタフェース・サブシステムが、該ユーザ・インタフェース・サブシステムが配備されている環境から多モード・データを入力するように構成され、前記多モード・データが第１のモードの入力センサに関連するデータと、少なくとも第２のモードの入力センサに関連するデータとを含み、前記環境が１人またはそれ以上のユーザと、前記多モード・システムによって制御することができる１つまたはそれ以上の装置とを備え、前記システムが、さらに、
前記ユーザ・インタフェース・サブシステムに動作できるように結合され、前記多モード入力データを１つまたはそれ以上のイベントに抽象化するように構成される入出力マネージャ・モジュールと、
前記入出力マネージャ・モジュールに動作できるように結合され、必要な場合には、前記抽象化された多モード入力データについて１つまたはそれ以上の認識動作を実行するように構成される、１つまたはそれ以上の認識エンジンと、
前記１つまたはそれ以上の認識エンジンおよび前記入出力マネージャ・モジュールに動作できるように結合され、（ｉ）前記抽象化された多モード入力データの少なくとも一部および、必要な場合には、前記認識された多モード入力データを受信し、（ｉｉ）前記受信した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図の判定を行い、および（ｉｉｉ）前記判定された意図に基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるように構成されるダイアログ・マネージャ・モジュールと、
前記１つまたはそれ以上の認識エンジンおよび前記入出力マネージャ・モジュールに動作できるように結合され、（ｉ）前記抽象化された多モード入力データおよび、必要な場合には、前記認識された多モード入力データの少なくとも一部を受信し、（ｉｉ）前記受信した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人のフォーカスおよびムードのうちの少なくとも１つの判定を行い、および（ｉｉｉ）前記判定されたフォーカスおよびムードのうちの少なくとも１つに基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるように構成されるフォーカスおよびムード分類モジュールと、
前記ダイアログ・マネージャ・モジュールと、前記１つまたはそれ以上の認識エンジンと、前記フォーカスおよびムード分類モジュールとに動作できるように結合され、前記ダイアログ・マネージャおよび前記分類モジュールによって行われた前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるように記憶するコンテキスト・スタック・メモリとを含むシステム。
【請求項１０】
コンピュータベースの会話型コンピューティング方法であって、該方法が、
１人またはそれ以上のユーザおよび１つまたはそれ以上の制御可能な装置を含む環境から多モード・データを取得するステップを含み、前記多モード・データが第１のモードの入力センサに関連するデータと少なくとも第２のモードの入力センサに関連するデータとを含み、前記方法が、さらに、
前記得られた多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行うステップと、
前記判定された意図、前記判定されたフォーカスおよび前記判定されたムードのうちの少なくとも１つに基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるステップと、
前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるように記憶するステップとを含む方法。
【請求項１１】
前記意図の判定のステップが、前記受信した多モード・データの少なくとも一部に基づいて、前記環境において前記１人またはそれ以上のユーザに関連する参照の曖昧性を解決するステップを含む、請求項１０に記載の方法。
【請求項１２】
前記意図の判定のステップが、前記受信した多モード・データの少なくとも一部に基づいて、前記環境において前記１つまたはそれ以上の装置に関連する参照の曖昧性を解決するステップをさらに含む、請求項１２に記載の方法。
【請求項１３】
前記環境において１つまたはそれ以上のアクションの実行を起こさせる前記ステップが、前記環境における前記１つまたはそれ以上の装置のうちの少なくとも１つを制御して、前記１人またはそれ以上のユーザの前記判定された意図、前記判定されたフォーカス、および前記判定されたムードのうちの少なくとも１つを実現するステップを含む、請求項１０に記載の方法。
【請求項１４】
前記環境において１つまたはそれ以上のアクションの実行を起こさせる前記ステップが、前記環境において前記１つまたはそれ以上の装置のうちの少なくとも１つを制御して、前記判定のうちの少なくとも１つを行うことを支援するためにユーザ入力をさらに要求するステップを含む、請求項１０に記載の方法。
【請求項１５】
前記１つまたはそれ以上のアクションの実行を起こさせる前記ステップが、前記システムが以前の入力から理解していることをさらに完了、訂正、および明確化することの少なくとも１つに対して処理を開始するステップを含む、請求項１０に記載の方法。
【請求項１６】
前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データを１つまたはそれ以上のイベントに抽象化するステップをさらに含む、請求項１０に記載の方法。
【請求項１７】
前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データについて１つまたはそれ以上の認識動作を実行するステップをさらに含む、請求項１０に記載の方法。
【請求項１８】
１つまたはそれ以上のプログラムを含むマシン可読媒体を備える、会話型コンピューティングを実行するための製造の物品であって、前記プログラムが、実行された場合に、
１人またはそれ以上のユーザおよび１つまたはそれ以上の制御可能な装置を含む環境から、第１のモードの入力センサに関連するデータおよび少なくとも第２のモードの入力センサに関連するデータを含む多モード・データを取得するステップと、
前記取得した多モード入力データのうちの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行うステップと、
前記判定された意図、前記判定されたフォーカスおよび前記判定されたムードのうちの少なくとも１つに基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるステップと、
前記意図、フォーカスおよびムードの判定に関連する結果のうちの少なくとも一部を以降の判定において使用することができるように記憶するステップとを実施する物品。
【請求項１９】
多モード会話型コンピューティング・システムであって、該システムが、
ユーザ・インタフェース・サブシステムを備え、該ユーザ・インタフェース・サブシステムが、該ユーザ・インタフェース・サブシステムが配備されている環境から多モード・データを入力するように構成され、前記多モード・データが少なくともオーディオ・ベースのデータと、画像ベースのデータとを含み、前記環境が１人またはそれ以上のユーザと前記多モード・システムによって制御することができる１つまたはそれ以上の装置とを含み、前記システムが、さらに、
少なくとも１つのプロセッサを備え、該少なくとも１つのプロセッサが前記ユーザ・インタフェース・サブシステムに動作できるように結合され、（ｉ）前記ユーザ・インタフェース・サブシステムから前記多モード入力データの少なくとも一部を受信し、（ｉｉ）前記受信した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行い、および（ｉｉｉ）前記判定された意図、前記判定されたフォーカスおよび前記判定されたムードのうちの少なくとも１つに基づいて、前記環境内に１つまたはそれ以上のアクションの実行を起こさせるように構成され、前記システムが、さらに、
前記少なくとも１つのプロセッサに動作できるように結合されているメモリを備え、該メモリが、前記プロセッサによって行われた前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるようにするために記憶するシステム。
【請求項２０】
前記意図の判定が、前記受信した多モード・データの少なくとも一部に基づいて、前記環境において前記１人またはそれ以上のユーザに関連する参照の曖昧性を解決するステップを含む、請求項１９に記載のシステム。
【請求項２１】
前記意図の判定が、前記受信した多モード・データの少なくとも一部に基づいて、前記環境における前記１つまたはそれ以上の装置に関連する参照の曖昧性を解決するステップを含む、請求項１９に記載のシステム。
【請求項２２】
前記ユーザ・インタフェース・サブシステムが前記画像ベースのデータを捕捉するために、前記環境において配備されている、１つまたはそれ以上の画像捕捉装置を含む、請求項１９に記載のシステム。
【請求項２３】
前記画像ベースのデータが可視波長スペクトルのうちの少なくとも１つにあり、前記可視波長スペクトルの中にはない、請求項２２に記載のシステム。
【請求項２４】
前記画像ベースのデータがビデオ、赤外線、および無線周波数ベースの画像データのうちの少なくとも１つである、請求項２２に記載のシステム。
【請求項２５】
前記ユーザ・インタフェース・サブシステムが、前記オーディオ・ベースのデータを捕捉するために、前記環境内で配備されている、１つまたはそれ以上のオーディオ捕捉装置を備える、請求項１９に記載のシステム。
【請求項２６】
前記１つまたはそれ以上のオーディオ捕捉装置が１つまたはそれ以上のマイクロホンを備える、請求項２５に記載のシステム。
【請求項２７】
前記ユーザ・インタフェース・サブシステムがグラフィカル・ユーザ・インタフェース・ベースのデータを捕捉するために、前記環境において配備されている、１つまたはそれ以上のグラフィカル・ユーザ・インタフェース・ベースの入力装置を備える、請求項１９に記載のシステム。
【請求項２８】
前記ユーザ・インタフェース・サブシステムが、手書きベースのデータを捕捉するために、前記環境において配備されている、スタイラスベースの入力装置を含む、請求項１９に記載のシステム。
【請求項２９】
前記環境における１つまたはそれ以上のアクションの実行が、前記１人またはそれ以上のユーザの前記判定された意図、前記判定されたフォーカス、および前記判定されたムードのうちの少なくとも１つを実現するために、前記１つまたはそれ以上の装置を制御するステップを含む、請求項１９に記載の方法。
【請求項３０】
前記環境における１つまたはそれ以上のアクションの実行が、前記環境において前記１つまたはそれ以上の装置のうちの少なくとも１つを制御して、前記判定のうちの少なくとも１つを行うことを支援するためにユーザ入力をさらに要求するステップを含む、請求項１９に記載の方法。
【請求項３１】
前記少なくとも１つのプロセッサが、さらに、前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データを１つまたはそれ以上のイベントに抽象化するように構成される、請求項１９に記載のシステム。
【請求項３２】
前記少なくとも１つのプロセッサが、さらに、前記１つまたはそれ以上の判定を行うステップに先立って、前記受信した多モード入力データについて１つまたはそれ以上の認識動作を実行するように構成される、請求項１９に記載のシステム。
【請求項３３】
前記１つまたはそれ以上の認識動作のうちの１つが音声認識を含む、請求項３２に記載のシステム。
【請求項３４】
前記１つまたはそれ以上の認識動作のうちの１つが話者認識を含む、請求項３２に記載のシステム。
【請求項３５】
前記１つまたはそれ以上の認識動作のうちの１つがジェスチャ認識を含む、請求項３２に記載のシステム。
【請求項３６】
前記１つまたはそれ以上のアクションの実行が、前記システムが前の入力から理解したことを完了、訂正、および明確化することのうちの少なくとも１つをさらに行うためのプロセスを起動するステップを含む、請求項１９に記載のシステム。
【請求項３７】
多モード会話型コンピューティング・システムであって、該システムが、
ユーザ・インタフェース・サブシステムを備え、該ユーザ・インタフェース・サブシステムが、該ユーザ・インタフェース・サブシステムが配備されている環境から多モード・データを入力するように構成され、前記多モード・データが少なくともオーディオ・ベースのデータおよび画像ベースのデータを含み、前記環境が１人またはそれ以上のユーザおよび前記多モード・システムによって制御することができる１つまたはそれ以上の装置を含み、前記システムが、さらに、
前記ユーザ・インタフェース・サブシステムに動作できるように結合され、前記多モード入力データを１つまたはそれ以上のイベントに抽象化するように構成される入出力マネージャ・モジュールと、
前記入出力マネージャ・モジュールに動作できるように結合され、必要な場合には、前記抽象化された多モード入力データについて１つまたはそれ以上の認識動作を実行するように構成される１つまたはそれ以上の認識エンジンと、
前記１つまたはそれ以上の認識エンジンおよび前記入出力マネージャ・モジュールに動作できるように結合され、（ｉ）前記抽象化された多モード入力データおよび、必要な場合には、前記認識された多モード入力データの少なくとも一部を受信し、（ｉｉ）前記受信した多モード入力データの少なくとも一部について前記１人またはそれ以上のユーザの少なくとも１人の意図の判定を行い、（ｉｉｉ）前記判定された意図に基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるように構成されるダイアログ・マネージャ・モジュールと、
前記１つまたはそれ以上の認識エンジンおよび前記入出力マネージャ・モジュールに動作できるように結合され、（ｉ）前記抽象化された多モード入力データの少なくとも一部および、必要な時、前記認識された多モード入力データを受信し、（ii）前記受信した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人のフォーカスおよびムードのうちの少なくとも１つの判定を行い、（iii）前記判定されたフォーカスおよびムードのうちの少なくとも１つに基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるように構成される、フォーカスおよびムード分類モジュールと、
前記ダイアログ・マネージャ・モジュール、前記１つまたはそれ以上の認識エンジンおよび前記フォーカスおよびムード分類モジュールに動作できるように結合され、前記ダイアログ・マネージャおよび前記分類モジュールによって行われた前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるように記憶するコンテキスト・スタック・メモリとを備えるシステム。
【請求項３８】
コンピュータベースの会話型コンピューティング方法であって、該方法が、
１人またはそれ以上のユーザおよび１つまたはそれ以上の制御可能な装置を含む環境から、少なくともオーディオ・ベースのデータおよび画像ベースのデータを含む多モード・データを取得するステップと、
前記取得した多モード入力データの少なくとも一部に基づいて、前記１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行うステップと、
前記判定された意図、前記判定されたフォーカスおよび前記判定されたムードのうちの少なくとも１つに基づいて、前記環境において１つまたはそれ以上のアクションの実行を起こさせるステップと、
前記意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を以降の判定において使用することができるように記憶するステップとを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多モード・データ処理技術に関し、特に、多モード入力データに従ってフォーカス検出、参照の曖昧性の解決およびムード分類を実行するためのシステムおよび方法に関する。
【背景技術】
【０００２】
種々のコンピューティング・タスクを実行するために使用することができるデータを得るために、２つ以上の入力モードを使用することが、現在のコンピュータベースの処理システムにおいてますます広く行われるようになってきている。そのような「多モードの」入力技術を使用するシステムは、１つのデータ入力モードだけを使用するシステムに比べて本来的な利点を有する。
【０００３】
例えば、ビデオ入力ソースと、より伝統的なコンピュータ・データ入力ソース、例えば、マルチウィンドウのグラフィカル・ユーザ・インタフェース（ＧＵＩ）と協調してのマウス装置および／またはキーボードの手動操作などを含むシステムがある。上記システムの例は、１９９９年６月１５日付けの、山口らの米国特許第５，９１２，７２１号に開示されている。この山口らのシステムの内容によれば、ユーザの注視点を検出することによってディスプレイ画面上の位置をユーザが指定できるようにするための装置を提供することができ、注視点はユーザが従来の入力装置のうちの１つを手動で操作する必要なしに、その画面に対するユーザの視線によって示される。
【０００４】
目の追跡に依存する他のシステムは、それ以降の処理のためのデータを得るためにビデオ以外の他の入力ソースを含むことができる。例えば、１９９６年５月１４日付けの、Kaufman他の米国特許第5,517,021号は目の動きおよび目の他のジェスチャによって生成される信号を検出するための電子視覚グラフィック(electro-oculographic)(EOG）デバイスの使用を開示している。そのようなＥＯＧ信号はある種のタスク実行機能を制御する際に使用するための入力として働く。
【０００５】
さらに他の多モード・システムは音声およびジェスチャの入力によるユーザのコマンドを受け付けることができる。１９９７年２月４日付けの、Ａｎｄｏ他の米国特許第５，６００，７６５号は、上記システムを開示しており、ポインティング入力装置を通してグラフフィクス・ディスプレイ・システムのディスプレイ画面上のディスプレイ・オブジェクトまたはディスプレイ位置のいずれかをポイントしながら、ユーザはグラフィクス・ディスプレイ上で１つのイベントを発生させるようにグラフィクス・ディスプレイ・システムに指令する。
【０００６】
音声およびジェスチャの入力を使用しているもう１つの多モード・コンピューティングの概念は、「自然コンピューティング」（natural computing）として周知である。自然コンピューティング技術によれば、ジェスチャがコマンドの一部として直接にシステムに提供される。他の方法としては、ユーザは話されたコマンドを与えることができる。
【０００７】
しかし、上記多モード・システムは１つのデータ入力モードだけを使用しているシステムに比べて本来的な利点を有するように見えるが、既存の多モードの技術は、ユーザとユーザが対話したいコンピューティング・システムとの間の効果的な対話環境の提供が大幅に不足している。すなわち、従来の多モード・システムは有効な会話型コンピューティング環境を提供することができない。例えば、上記のような、従来のシステムにおけるユーザのジェスチャまたは目の注視の使用は単に従来のＧＵＩポインティング装置の使用に対する置き換えに過ぎない。自然コンピューティング技術の場合、システムは音声ベースのコマンドを独立に認識し、ジェスチャ・ベースのコマンドを独立に認識する。したがって、従来のシステムにおいては、１つまたはそれ以上の他の入力モードによってデータ入力を明確化するか、あるいは理解するための１つまたはそれ以上の入力モードを使用するための試みがない。さらに、従来のシステムにおいてはユーザのムードまたは注目（attention）の分類を実行するために多モード入力を利用するための試みはない。さらに、データ入力モードとしてビデオを利用する従来のシステムにおいては、そのビデオ入力のメカニズムは可視波長スペクトルに限定されている。したがって、そのようなシステムの有用性は、光が豊富に利用できる環境に制限される。残念ながら、動作状態により光を豊富には利用できないか、または光のレベルがしばしば変化する場合がある（例えば、走行中の自動車内でのように）。
【特許文献１】
米国特許第５，９１２，７２１号
【特許文献２】
米国特許第５，５１７，０２１号
【特許文献３】
米国特許第５，６００，７６５号
【特許文献４】
米国特許出願番号０９／３６９，７０７（弁理士整理番号ＹＯ９９９−３１７）
【特許文献５】
米国特許出願番号０９／３６９，７０６（弁理士整理番号ＹＯ９９９−３１８）
【特許文献６】
米国特許出願番号０９／５０７，５２６（弁理士整理番号ＹＯ９９９−１７８）
【特許文献７】
米国特許出願番号６０／１２８，０８１
【特許文献８】
米国特許出願番号６０／１５８，７７７
【特許文献９】
米国特許出願番号０９／５４４，８２３（弁理士整理番号ＹＯ９９９−４７８）
【特許文献１０】
米国特許出願番号６０／１０２，９５７（弁理士整理番号ＹＯ９９９−３９２）
【特許文献１１】
ＰＣＴ／ＵＳ９９／２３００８（弁理士整理番号ＹＯ９９９−３９２）
【特許文献１２】
ＰＣＴ／ＵＳ９９／２２９２７（弁理士整理番号ＹＯ９９９−１１１）
【特許文献１３】
米国特許出願番号０９／３７１，４００（弁理士整理番号ＹＯ９９９−２２７）
【特許文献１４】
米国特許出願番号０８／７８８，４７１
【特許文献１５】
ＰＣＴ／ＵＳ９９／２２９２５（弁理士整理番号ＹＯ９９９−１１３）
【特許文献１６】
米国特許出願番号６０／０１１，０５８
【特許文献１７】
米国特許出願番号０８／７８７，０３１（米国特許第５，８９５，４４７号）
【特許文献１８】
米国特許出願番号０８／７８７，０２９
【非特許文献１】
Spoken LanguageProcessing, Sidney, Australia(ICSLP ’98)において1998年の国際学会で発表されたLincoln他による論文、「アクセントの識別のための２つの非ス−パバイザ型の方法の比較」（AComparison of Two Unsupervised Approaches to Accent Identification）という記事
【非特許文献２】
McGraw Hillから1997年に出版されたAlexBersonおよびStephen J. Smithの書籍「データ・ウェアハウジング、データ・マイニングおよびOAAP」(Data Warehousing, Data Mining and OAAP)
【非特許文献３】
Prentice Hallから1998年に出版されたCabena他の、「データ・マイニングの発見」(Discovering Data Mining)
【発明の開示】
【発明が解決しようとする課題】
【０００８】
したがって、１人またはそれ以上のユーザに効果的な会話型コンピューティング環境を提供するためには、変化する動作状態において、多モード入力データに従ってフォーカス検出、参照の曖昧性の解決およびムード分類を実行するためのシステムおよび方法を提供することは非常に有利である。
【課題を解決するための手段】
【０００９】
本発明は、１人またはそれ以上のユーザに効果的な会話型コンピューティング環境を提供するために、変化している動作状態において、多モード入力データに従って、フォーカス検出、参照の曖昧性の解決およびムード分類を実行するための技術を提供する。
【００１０】
本発明の１つの態様においては、多モード会話型コンピューティング・システムは、ユーザ・インタフェース・サブシステムを含み、そのユーザ・インタフェース・サブシステムは、それが配備されている環境から多モード・データを入力するように構成される。多モード・データは少なくともオーディオ・ベースのデータおよび画像ベースのデータを含む。その環境は１人またはそれ以上のユーザ、および本発明の多モード・システムによって制御することができる１つまたはそれ以上の装置を含む。また、そのシステムは少なくとも１つのプロセッサも含み、そのプロセッサは、ユーザ・インタフェース・サブシステムに動作できるように結合されていて、ユーザ・インタフェース・サブシステムから多モード入力データの少なくとも一部を受信するように構成される。プロセッサは、さらに、その受信した多モード入力データの少なくとも一部に基づいて、１人またはそれ以上のユーザのうちの少なくとも１人の意図、フォーカスおよびムードのうちの少なくとも１つの判定を行うように構成される。プロセッサは、さらに、その判定された意図、判定されたフォーカスおよび判定されたムードのうちの少なくとも１つに基づいて、その環境内で１つまたはそれ以上のアクションの実行が発生されるように構成される。そのシステムはさらに、少なくとも１つのプロセッサに動作できるように結合されているメモリを備え、そのメモリは以降の判定またはアクションにおいて使用することができるように、プロセッサによって行われた意図、フォーカスおよびムードの判定に関連する結果の少なくとも一部を記憶する。
【００１１】
有利なこととして、そのような多モード会話型コンピューティング・システムは、（ｉ）ユーザによってアドレスされたオブジェクト、アプリケーションまたは器具を判断するための機能と、（ii）ユーザのフォーカスを判断し、したがって、そのユーザが適当なアプリケーションにおいてアクティブにフォーカスされているかどうかを判断し、そのベースにおいて、アクションが取られるべきかどうかを判断し、（iii）誰が何を言ったか、または何を行ったか、ユーザが多モードのクエリー／コマンドを与えた時に、そのユーザのフォーカスはどうであったか、およびこれらのコマンドおよびフォーカスの履歴がどうであるかに基づいてクエリーを理解し、（iv）ユーザのムードを推定し、それに従っていくつかの動作／サービス／器具を起動し、および／または適合させる機能を提供する。また、そのコンピューティング・システムはそのユーザが対話するアプリケーションの関連するビジネス論理を変更することもできる。
【００１２】
本発明による多モードは、音声およびビデオ以外のモードの組合せを含むことができることを理解されたい。例えば、多モードはキーボード／ポインタ／マウス（または電話機のキーパッド）および他のセンサなどを含むことができる。それ故、入力を明確化し、そしてムードまたはフォーカスを推測するための少なくとも２つの異なるセンサ（および出力のためのアクチュエータ）を通してのモードの組合せについての本発明の一般的原理を、任意の上記組合せに対して一般化することができる。次に、ムードまたはフォーカスを判断するためのエンジンまたは分類器はそのセンサに固有であるが、それらを使用する方法はここで開示されているものと同じである。例示としての実施形態がオーディオおよびビデオのデータのストリームを作り出すセンサに注目している場合であっても、このことは本明細書全体を通して理解されたい。
【００１３】
本発明のこれらおよび他の目的、特徴および利点は、添付の図面を参照しながら、以下の例示としての実施形態の詳細な説明を読めば容易に理解することができるだろう。
【発明を実施するための最良の形態】
【００１４】
最初に図１について説明すると、この図は、本発明のある実施形態による多モード会話型コンピューティング・システムの一例のブロック図を示す。図に示されているように、多モード会話型コンピューティング・システム１０は入出力（Ｉ／Ｏ）サブシステム１２と、Ｉ／Ｏマネージャ・モジュール１４と、１つまたはそれ以上の認識エンジン１６と、ダイアログ・マネージャ・モジュール１８と、コンテキスト・スタック２０と、ムード／フォーカス分類器２２とを含む。
【００１５】
一般に、本発明の多モード会話型コンピューティング・システム１０は、オーディオ入力データ、ビデオ入力データ、および他のタイプの入力データの形式で多モード入力を受信し（Ｉ／Ｏサブシステム１２に従って）、その多モード・データを処理し（Ｉ／Ｏマネージャ１４に従って）、必要な場合、この処理されたデータを使用して種々の認識タスク（例えば、認識エンジン１６に従って、例えば、音声認識、話者認識、ジェスチャ認識、読唇、顔認識など）を実行する。その認識タスクの結果および／または処理されたデータそのものが次に１つまたはそれ以上の会話型コンピューティング・タスク、例えば、フォーカス検出、参照の曖昧性解決、およびムード分類を実行する（ダイヤログ・マネージャ１８、コンテキスト、スタック２０および／または分類器２２によって）ために、以下に詳細に説明されるように使用される。
【００１６】
本発明の多モード会話型コンピューティング・システムは、特定の用途には限定されないが、最初にいくつかの例示としての用途を説明しておくことは、そのシステムが提供する種々の特徴および実行することができる機能を文脈的に理解するのに役立つ。
【００１７】
したがって、最初の例示としての用途を示す方法により、多モード会話型コンピューティング・システム１０を乗り物内に使用することができる。そのような例においては、そのシステムを使用して、目が閉じられている時間が異常に長いこと、または別の方向を注視していることの検出（ビデオ入力による）、および／または注意散漫の状態または眠気を示す音声の検出（オーディオ入力による）に基づいた注意散漫な、あるいは眠気をもよおしているオペレータを検出するために使用することができ、その潜在的に危険な状態のオペレータに警告することができる。これはフォーカス検出と呼ばれる。目の状態（例えば、開いているか閉じているか）および／または顔の方向を抽出して追跡することにより、システムはそのオペレータが何に集中しているかを判定することができる。図で分かるように、システム１０は可視画像データだけでなく（あるいは、その代わりに）、赤外線（ＩＲ）のビジュアル・データなどの不可視画像データも受信して処理するように構成することができる。また（ふたたび、代わりに）、無線周波数（ＲＦ）データも受信して処理することができる。そこで、光が豊富にはない（すなわち、弱い照明の状態である）、例えば、車が夜に運転されている動作環境において多モード会話型コンピューティング・システムが使用されている場合、そのシステムはやはり多モード入力を取得し、データを処理し、必要な場合、適切な応答を出力することができる。したがって、このシステムは光がない状態においても動作することができる。
【００１８】
また、乗り物の用途は参照の曖昧性解決の概念の理解にも役立つ。乗り物の中に複数のユーザがいて、多モード会話型コンピューティング・システム１０が、システムによって受信されて処理されるユーザの入力コマンドによって制御されるいくつかの装置（例えば、電話機、ラジオ、テレビジョン、照明）に結合されている場合を考える。そのような状況においては、単に多モード入力があるのではなく、その乗り物の複数の占有者からの多モード入力があり得る。
【００１９】
したがって、システム１０はユーザの参照解決を実行することができなければならない。例えば、そのシステムは話された言葉、「私の事務所に電話して下さい」、を受信する場合があるが、そのシステムがどの占有者がこの言葉を発したかを判定することができない限り、関連するセルラー電話に電話を掛けさせるための事務所の電話番号が分からない。したがって、システム１０は音声入力データおよび画像データ入力の両方を取得し、それを処理してユーザの解決判定を行うことによって、複数のユーザに関して参照の曖昧性の解決を実行する。これは音声および画像のヒントの両方に基づいて音声のアクティビティおよび／またはユーザのアイデンティティを検出することを含むことができる。これを実行するための技術が以下に説明される。
【００２０】
同様に、ユーザは、システムに対して「それをオフにして下さい」と言うことができるが、装置参照の解決なしでは、システムはどの関連装置がオフにされるかを知ることがない。したがって、システム１０は音声入力データおよび画像データ入力の両方を取得し、それを処理して装置の解決判定を行うことにより、複数の装置に関して参照の曖昧性の解決を実行する。これは話し掛けられている方向の概略の空間的分解、あるいは身体のポーズ（例えば、指差し）を使用してその話者の頭のポーズを検出することを含むことができる。これはまた、以前に発生され、コンテキスト・マネージャ／履歴スタックの中に記憶されたＩ／Ｏ（入出力）イベントの明確化も含むことができる（例えば、ブザーが鳴って、そのユーザが「それをオフにして下さい」と要求した場合、「それ」という言葉を明確化することができる）。これを実現するための技術が以下に説明される。
【００２１】
さらに、システム１０は乗り物の占有者のムードまたは感情的な状態を判定し、次にそのような状態を変化させる他の関連装置の制御を実施することができる。例えば、システムが、そのユーザが温かいか、または冷たいかを検出する場合、システムは乗客ごとに温度を調整することができる。乗客が疲れている場合、システムは座席の調整、音楽のボリュームを上げることなどを行わせることができる。また、別の例（乗り物内のシステムとは限らない）として、アプリケーション・インタフェースの応答性をそのユーザのムードに対して合わせることができる。例えば、そのユーザが混乱しているように見える場合、システムによってヘルプを提供することができる。さらに、そのユーザが取り乱しているように見える場合、より速い実行が試みられる。さらに、そのユーザが不確定である場合、システムは確認を求めるか、あるいはユーザのガイドを提供することができる。
【００２２】
上記の例は多モード会話型コンピューティング・システム１０が乗り物の中で使用されている用途を示しているが、もう１つの構成例においては、システムはシステム１０によって制御される複数の関連装置と同様に、より広い領域、例えば、複数のビデオ入力および音声入力装置を備えた部屋の中で使用することができる。ここで発明の内容が与えられて、当業者であれば、多モード会話型コンピューティング・システムを使用することができる他の用途を実現することができる。
【００２３】
図１の多モード会話型コンピューティング・システム１０の機能的構成要素が与えられ、上記の用途例を念頭において、図２および図３の次の説明は１つまたはそれ以上のそのような用途の実行のコースの間に、システム１０の機能的構成要素の対話の一般的説明を提供する。
【００２４】
図２について説明すると、この流れ図は、参照の曖昧性の解決（例えば、ユーザおよび／または装置の明確化）が実行される多モード会話型コンピューティング・システムによって実行される方法２００の流れ図を示す。
【００２５】
最初に、ステップ２０２において、生の多モード入力データがそのシステムに関連付けられた多モード・データ・ソースから得られる。図１のコンピューティング・システム１０に関して、そのようなソースはＩ／Ｏサブシステム１２によって代表されている。上記のように、サブシステムのデータ入力部分は、そのシステム（あるいは、少なくともそのＩ／Ｏサブシステム）が配備されている環境を表しているビデオ入力データを捕捉するための１つまたはそれ以上のカメラまたはセンサを含むことができる。そのカメラ／センサは可視画像データ（可視電磁波スペクトル内の画像）だけでなく、ＩＲ（近、中および／または遠視野ＩＲビデオ）および／またはＲＦ画像データも捕捉できるものであってよい。もちろん、２台以上のカメラを備えたシステムにおいては、カメラ／センサの種々の混合を使用することができる。例えば、１つまたはそれ以上のビデオ・カメラ、１つまたはそれ以上のＩＲセンサ、および／または１つまたはそれ以上のＲＦセンサを備えているシステムが可能である。
【００２６】
１つまたはそれ以上のカメラの他に、Ｉ／Ｏサブシステム１２は、そのシステムが配備されている環境から音声入力データを捕捉するための１つまたはそれ以上のマイクロホンを備えることができる。さらに、Ｉ／Ｏサブシステムはマイクロホンによって発生された電気信号を、捕捉される発声された音声または他の音声のディジタル信号表現に変換するアナログ−ディジタル変換器も含むことができる。さらに、そのサブシステムは音声信号をサンプルし、その信号をオーバラップしているフレームに区画化し、各フレームがシステムの残りの部分によって個々に処理されるようにすることができる。
【００２７】
このように、上記の乗り物を参照して、システムが曖昧性の解決判定を行うために必要となり得るすべての視覚的アクティビティおよび音声アクティビティを完全に捕捉しようとするために、乗り物全体を通してカメラおよびマイクロホンを戦略的に配置することができることは理解される。
【００２８】
さらに、Ｉ／Ｏサブシステム１２は、また、ユーザ入力を取得するための他の代表的な入力装置、例えば、キーボード、マウスなどのＧＵＩベースの装置、および／または電子的な手書きを捕捉するためのスタイラスおよびディジタイザ・パッドなどの他の装置も備えることができる。当業者であれば、ユーザのアクティビティを捕捉するために含めることができる他のユーザ・インタフェースおよび装置を実現することができる。
【００２９】
次に、ステップ２０４において、生の多モード入力データが１つまたはそれ以上のイベントに抽象化される。図１のコンピューティング・システム１０に関して、そのデータの抽象化はＩ／Ｏマネージャ１４によって実行される。Ｉ／Ｏマネージャは生の多モード・データを受信し、そのデータを１つまたはそれ以上のイベントを表す形式、例えば、話された発声、視覚的ジェスチャなどに抽象化する。周知のように、データ抽象化の操作は、以降の操作において使用するためにデータのより一般化された表現を作り出すように、入力データのすべてまたは一部と関連する詳細の発生を含むことができる。
【００３０】
ステップ２０６において、抽象化されたデータまたはイベントは、必要な場合、次にＩ／Ｏマネージャ１４からそのイベントが認識されるようにするために、１つまたはそれ以上の認識エンジン１６に送信される。すなわち、そのイベントの性質により、１つまたはそれ以上の認識エンジンがそのイベントを認識するために使用される場合がある。例えば、そのイベントがある形式の話された発声であって、マイクロホンがその発声の可聴部分を拾い、カメラがその発声の視覚的部分（例えば、唇の動き）をピックアップする場合、その音声に関連付けられた音声入力とビデオ入力の両方を使用してそのイベントをオーディオビジュアル音声認識エンジンに送信し、その発声が認識されるようにすることができる。他の方法としては、あるいは追加的に、そのイベントをオーディオビジュアル話者認識エンジンに送信してその発声の話者を識別し、検証し、および／または認証することができる。また、音声認識および話者認識の両方を同じ発声において組み合わせることもできる。
【００３１】
そのイベントがカメラによってピックアップされたユーザの何らかの形式のジェスチャである場合、そのイベントを認識のためにジェスチャ認識エンジンに送信することができる。ふたたび、そのシステムによって提供されているユーザ・インタフェースのタイプにより、そのイベントはその認識エンジンの１つが手書き認識エンジンであるようにユーザによって提供される手書き入力を含むことができる。より一般的なＧＵＩベースの入力（例えば、キーボード、マウスなど）の場合、そのデータを必ずしも認識する必要はない。何故なら、そのデータは既に認識操作なしで識別可能だからである。
【００３２】
認識エンジン１６はオーディオビジュアル音声認識モジュールを有している。ジェスチャ認識（例えば、身体、腕および／または手の動きなどで、ユーザがシステムに対して受動的に、あるいは能動的に命令を与えるために使用する）およびフォーカス認識（例えば、ユーザの顔および目の方向）は、この認識モジュールを使用して実行することができる。しかし、フォーカス検出に関しては、分類器２２がユーザのフォーカスおよび、それに加えてそのユーザのムードを判定するために使用されることが好ましい。
【００３３】
ここで記述される２つの、それ以上の、あるいはすべての入力モードは、多モードの対話を同期化する技術によって同期化することができる
【００３４】
ステップ２０８において、認識されたイベントが認識される必要のないイベントと同様に、コンテキスト・スタック２０と呼ばれる記憶ユニットの中に記憶される。コンテキスト・スタックはユーザとシステムとの間の対話の履歴を生成するために使用され、ユーザの意図の判定時にダイアログ・マネージャ１８が参照の曖昧性の解決判定を行うのを支援するようにする。
【００３５】
次に、ステップ２１０において、システム１０は現在のイベントおよびコンテキスト・スタックの中に記憶されている履歴の対話情報に基づいてユーザの意図を判定しようとし、次に、そのユーザの意図を実現する、および／またはそのユーザのアクティビティに対して反応する１つまたはそれ以上のアプリケーション・プログラムを決定して実行する。そのアプリケーションはシステムが配備されている環境に依存する。そのアプリケーションは、任意のコンピュータ・プログラミング言語で書いて構わないが、会話型マークアップ言語（ＣＭＬ）で書かれていることが好ましい。
【００３６】
したがって、ダイアログ・マネージャは最初に現在のイベントおよび、利用できる場合はコンテキスト・スタックの中に記憶されている履歴情報（例えば、過去のイベント）に基づいて、ユーザの意図を判定しなければならない。例えば、乗り物の例に戻ると、ユーザは乗り物のラジオを指差しながら「それをオンにしてください」ということができる。したがって、ダイアログ・マネージャはその話された発声「それをオンにしてください」およびそのラジオを指差すジェスチャに関連付けられた認識されたイベントの結果を受信することになる。これらのイベントに基づいて、ダイアログ・マネージャは既存のアプリケーション、トランザクションまたは「ダイアログ」またはその一部分で、そのような発声およびジェスチャを関連付けることができるもののサーチを行う。したがって、図１に示されているように、ダイアログ・マネージャ１８は適切なＣＭＬ作成アプリケーション２４を決定する。そのアプリケーションはシステム１０上に記憶されているか、あるいはいくつかのリモートの場所からアクセスされる（例えば、ダウンロードされる）ようになっていてよい。ダイアログ・マネージャが、自分が選択するアプリケーションがユーザの望みを実現することになるものであるということをある所定の程度の確信を持って判断した場合、ダイアログ・マネージャは多モード入力に基づいてそのアプリケーションの多モード・ダイアログの次のステップを実行する（例えば、欠落しているか、曖昧であるか、または混乱している情報に対するプロンプトまたは表示を行うこと、完全に理解された多モード要求に関連するアクションの確認をユーザから求めるか、あるいはその実行を開始することなど）。すなわち、ダイアログ・マネージャは適当な装置（例えば、ラジオ）の活性化ルーチンを選択し、そのラジオを活性化するためのコマンドを出力するようにＩ／Ｏマネージャに指示する。所定の程度の確信は、受信したイベントによってそのアプリケーションの少なくとも２つの入力パラメータまたは変数が満足されるか、あるいは提供されることであってよい。もちろん、アプリケーションにより、他の信頼のレベルおよびアルゴリズムが設定されていてもよい。それらは、例えば、K. A. Papineni, S. Roukos, R. T. Wardの、「様式を使用した自由フローのダイアログ管理」(Free-flow dialog management using forms), Proc. Eurospeech, Budapest,1999;およびK. Davies他の、「金融のアプリケーションのためのIBM会話型電話システム」(The IBM conversational telephonysystem for financial applications), Proc. Eurospeech, Budapest, 1999に開示されているようなものでよい。
【００３７】
ユーザが最初に「それをオンにしてください」と言い、次に、２、３秒後にそのラジオを指差す場合を考える。ダイアログ・マネージャは「それをオンにしてください」のコマンドだけに基づいてユーザの意図を判定しようとする。しかし、オンにすることができる他の装置がその乗り物の中にあり得るので、そのユーザが指定しているものを十分な程度の確信で判定することができない場合がある。しかし、この認識された話された発声のイベントがコンテキスト・スタック上に記憶されている。次に、認識されたジェスチャ・イベント（例えば、そのラジオを指差しているイベント）が受信されると、ダイアログ・マネージャはこのイベントとコンテキスト・スタック上に記憶されていた前の話された発声のイベントとを取り、そのユーザがそのラジオをオンにすることを意図していたことの判定を行う。
【００３８】
ユーザが「それをオンにしてください」と言ったが、何もジェスチャを行わず、そして他の発声も提供しない場合を考える。この場合、ダイアログ・マネージャはそのユーザの意図を判定し（図２のステップ２１２）、そのコマンドを実施するために十分な入力を有していないと仮定する。ダイアログ・マネージャはステップ２１４において、ユーザの意図を明確化することができるようにさらにデータを入力するようユーザに要求するための出力の発生を要求する。これはダイアログ・マネージャがＩ／ＯマネージャにＩ／Ｏサブシステムが明確化のための要求を出力させるよう、指示することによって実現することができる。ある実施形態においては、Ｉ／Ｏサブシステム１２はテキストから音声への（text-to-speech）（TTS）エンジンおよび１つまたはそれ以上の出力スピーカを含むことができる。次に、ダイアログ・マネージャは「どの装置をオンにしたいですか？」などの所定の質問を発生し、それをＴＴＳエンジンが合成された発声に変換し、それがユーザに聞こえるようにスピーカから出力される。次に、ユーザはその質問を聞いて、ラジオを指差すか、あるいは「ラジオ」と言い、それによってダイアログ・マネージャに自分の要求を明確化するための追加の入力データを提供する。すなわち、図２を参照して、システム１０はふたたびステップ２０２において生の入力データを取得し、その新しいデータに基づいてプロセス２００が繰り返される。そのような繰返しはそのユーザの意図を判定するためにダイアログ・マネージャにとって必要である限り継続することができる。
【００３９】
また、ダイアログ・マネージャ１８は、より多くの情報に対する要求（ステップ２１４）と同じ方法でステップ２１６においてユーザから確認を求めた後、ステップ２１８においてその処理されたイベントを実行し、タスクをディスパッチするか、および／または何らかの他のアクションを実行する（例えば、そのラジオをオンにさせる）ことができる。例えば、システムが「ラジオをオンにしたいですか？」と出力することができる。それに対して、ユーザは「はい」で応答することができる。次に、システムはラジオをオンにさせる。さらに、ダイアログ・マネージャ１８は自分が発生するか、および／または取得する情報を後のある時点において解決または他の判断を行う際に使用するためにコンテキスト・スタック２０上に現在のイベントの処理中に情報を記憶することができる。
【００４０】
もちろん、上記の例は装置の曖昧性の解決の簡単な一例である。述べられたように、システム１０は、例えば、多モードの環境において、誰かが「私の事務所にダイヤルしてください」というような場合にユーザの曖昧性の解決判定を行うこともである。上記説明が与えられて、当業者であれば、複数のユーザの中で誰がその要求を行ったかを判定し、次にその指令を実現するために、システム１０が上記コマンドをどのように処理することができるかを理解することができるだろう。
【００４１】
また、ユーザにさらに入力を要求するための出力は、他の任意の方法で、そしてユーザとユーザに対するシステムからのフィードバックとの間の任意の回数の対話で行うことができる。例えば、Ｉ／Ｏサブシステム１２はＧＵＩベースのディスプレイを含むことができ、それによってそのディスプレイの画面上に表示されたテキスト・メッセージの形式でシステムによってその要求が行われるようにすることができる。当業者であれば、ここでの内容を実施するために他の多くの出力メカニズムがあることが分かる。
【００４２】
会話型仮想マシンを、本発明のＩ／Ｏマネージャ、認識エンジン、ダイアログ・マネージャおよびコンテキスト・スタックに対するフレームワークを提供するために使用することができることを理解されたい。そのような会話型仮想マシンについての説明が以下に提供される。
【００４３】
また、フォーカスまたは注目の検出はフォーカス／ムード分類器２２に従って実行されることが好ましいが、以下に説明されるように、そのような動作は上記のように、ダイアログ・マネージャ１８によってにも実行できることを理解されたい。
【００４４】
ここで図３について説明すると、この図は、ムード分類および／またはフォーカス検出が実行される、多モード会話型コンピューティング・システムによって実行される方法３００の流れ図を示す。システム１０は図３の方法を、図２の方法と平行して、あるいは別の時間に実行することができることを理解されたい。また、このために、コンテキスト・スタックの中に１つのプロセスによって記憶されているイベントを他のプロセスによって使用することができる。
【００４５】
ステップ３０２から３０８までは図２のステップ２０２から２０８までに類似していることを理解されたい。すなわち、Ｉ／Ｏサブシステム１２が生の多モード入力データを種々の多モードのソースから取得し（ステップ３０２）、Ｉ／Ｏマネージャ１４がその多モード入力データを１つまたはそれ以上のイベントに抽象化し（ステップ３０４）、１つまたはそれ以上の認識エンジン１６が、必要な場合、１つまたはそれ以上のイベントの性質に基づいてそのイベントを認識し（ステップ３０６）、およびイベントがコンテキスト・スタック上に記憶される（ステップ３０８）。
【００４６】
上記乗り物の例の中で記述されたように、フォーカス検出の場合、システム１０は運転のタスクに対してユーザが十分な注意を払っているかどうか（運転者であると仮定して）を判定するために、そのユーザのフォーカス（およびフォーカスの履歴）を判定することができる。そのような判定は目が異常に長く閉じられていること、あるいは別の方向を注視していることおよび／または注意散漫または眠気を示している話声に注意することによって行うことができる。次に、システムはこの潜在的に危険な状態についてオペレータに警告することができる。さらに、ムード分類に関して、システムは乗り物の占有者のムードまたは感情的な状態を判定し、その状態に影響することができる他の関連装置の制御を実行するために判定することができる。そのようなフォーカスおよびムードの判定はフォーカス／ムード分類器２２によってステップ３１０において行われる。
【００４７】
フォーカス／ムード分類器２２はイベントをＩ／Ｏマネージャ１４から直接に受信するか、あるいは必要な場合、そのイベントの性質により、分類器は１つまたはそれ以上の認識エンジン１６から認識されたイベントを受信する。例えば、乗り物の例においては、フォーカス／ムードの分類器はユーザの目および／または頭の位置を示す視覚的イベントおよびユーザが発している可能性のある音（例えば、いびき）を示すオーディオ・イベントを受信することができる。コンテキスト・スタック上に記憶されている過去の情報以外に、これらのイベントを使用して分類器はフォーカス検出および／またはムード分類の判定を行う。そのような判定の結果をコンテキスト・スタック上に記憶することもできる。
【００４８】
次に、ステップ３１２において、分類器は結果の判断によるいくつかのアクションの実行を起こさせることができる。例えば、運転者の注意が散漫になっていることが判定された場合、Ｉ／Ｏマネージャは分類器から、ＴＴＳシステムおよび１つまたはそれ以上の出力スピーカを経由してその運転者に警告メッセージを出力するよう指示されるようにすることができる。運転者が、例えば、その運転者の監視された身体の姿勢によって疲れていると判定された場合、Ｉ／Ｏマネージャは警告メッセージを提供し、車の中の温度またはラジオのボリュームを調整することなどの指示を分類器から受けることができる。
【００４９】
会話型データ・マイニング・システムを、本発明のムード／フォーカス分類器に対するフレームワークを提供するために使用することができることを理解されたい。そのような会話型データ・マイニング・システムの説明が以下に提供される。
【００５０】
参照を容易にするために、詳細な説明の残りの部分は次のセクションに分割される。それらは、（Ａ）オーディオビジュアル音声認識、（Ｂ）オーディオビジュアル話者認識、（Ｃ）会話型仮想マシン、および（Ｄ）会話型データ・マイニングである。各セクションの中で説明されるように、これらのセクションは図１に示されている多モード会話型コンピューティング・システム１０のいくつかの構成要素の詳細の好ましい実施形態を記述する。
Ａ．オーディオビジュアル音声認識
【００５１】
ここで図４について説明すると、この図は、本発明に従って受信した多モード入力データを使用して音声認識を実行するための、図１の認識モジュールの１つとして使用することができる、オーディオビジュアル音声認識モジュールの好ましい実施形態のブロック図を示す。本発明の多モード会話型コンピューティング・システムの好ましい実施形態において使用するためのそのようなオーディオビジュアル音声認識モジュールの実施形態の１つについての記述がこのセクションにおいて以下に提供される。しかし、音声認識を実行するために他のメカニズムを使用することができることを理解されたい。
【００５２】
説明されるように、この特定の例示としての実施形態は、意志決定融合法を使用したオーディオビジュアル認識を示す。ここで記述されるオーディオビジュアル音声認識モジュールが提供する利点の１つが、任意の内容のビデオを処理するための能力であることを理解されたい。すなわち、音声認識のコンテキストにおいて、ビデオ・ソースからのビジュアルな手がかりを利用しようとした以前のシステムは、制御された状態でのビデオ、すなわち、任意でない内容のビデオを利用していた。すなわち、そのビデオの内容は、大部分は雑音のない環境において短いコマンドまたは単独のワードを認識しようとするためにビジュアルな手がかりが取られた顔面のみを含んでいた。しかし、以下に詳細に説明されるように、ここで記述されるモジュールは顔面を含むだけでなく、雑音の多い環境における任意の背景オブジェクトも含むことができる任意の内容のビデオを処理できることが好ましい。任意の内容のビデオの一例は、放送のニュースのコンテキストの中にある。そのようなビデオは背景の中で任意のアクティビティおよび雑音が存在する場所において喋っているニュースキャスターを含んでいる可能性がある。そのような場合、説明されるように、そのモジュールはその話し手によって提供される付随している音声をより正確に認識することにおいて使用される関連のビジュアル情報が何であるかを判定するために、顔および、より特定すれば、口を見付けて追跡することができる。また、そのモジュールは話者の顔が見えない時（音声のみ）、またはその音声が聞き取れない時（読唇のみ）にも認識し続けることができる。
【００５３】
したがって、そのモジュールはビデオ・カメラ４０４およびマイクロホン４０６からＩ／Ｏマネージャ１４を経由してリアルタイムの任意の内容を受信することができる。カメラおよびマイクロホンはＩ／Ｏサブシステム１２の一部分であることを理解されたい。カメラ４０４から受信されたビデオ信号およびマイクロホン４０６から受信されたオーディオ信号が圧縮されずに図４の中に示されているが、それらを圧縮することができ、その場合、その適用された圧縮方式に従って解凍される必要がある。
【００５４】
カメラ４０４によって捕捉されるビデオ信号は任意の特定のタイプのビデオ信号であってよいことを理解されたい。前に述べたように、顔およびポーズの検出技術は任意の波長、例えば、可視および／または不可視の電磁波スペクトル画像であってよい。例だけの方法により、これは赤外線（ＩＲ）画像（例えば、近、中および遠視野ＩＲビデオ）および無線周波数（ＲＦ）画像を含むことができる。したがって、そのモジュールは弱い照明の状態、照明が変化している状態、あるいは光のない環境においてオーディオビジュアル音声検出および認識技術を実行することができる。例えば、改善された音声認識が実行できるように、自動車または他のいくつかの形式の乗り物およびＩＲ画像を捕捉することができる環境内にこのシステムを設置することができる。ビデオ情報（すなわち、可視および／または不可視電磁波スペクトル画像を含む）が音声認識プロセスにおいて使用されるので、オーディオ情報だけを使用する従来の認識システムを大幅に阻害する雑音の多い状態に起因する認識誤りが起きにくい。さらに、ここで記述されているビジュアル情報を処理するための方法のために、そのモジュールは正確なLVCSR（大規模語彙連続音声認識）（largevocabulary continuous speech recognition）を実行するための機能を提供する。
【００５５】
ローマ数字のＩで示されている点線はそのモジュールの内部でオーディオ情報信号が取る処理経路を表し、ローマ数字のＩＩによって示されている点線はビデオ情報信号がそのモジュールの内部で取る処理経路を表す。最初に、オーディオ信号経路Ｉが説明され、次にビデオ信号経路ＩＩが説明されてその次にこの２つのタイプの情報が組み合わされて改善された認識精度を提供する方法の説明が続く。
【００５６】
そのモジュールは聴覚的特徴抽出器４１４を含む。特徴抽出器４１４は当技術において周知のように、オーディオまたは音声の信号を受信し、その信号から一定の間隔においてスペクトル的特徴を抽出する。そのスペクトル的特徴は音響特性ベクトル（信号）の形式になっており、それが次に確率モジュール４１６に渡される。音響的ベクトルが抽出される前に、音声信号を１６キロヘルツ（kHz）のレートでサンプルすることができる。１つのフレームは持続時間が２５ミリ秒（msec）である音声のセグメントから構成することができる。そのような構成において、抽出プロセスは以下に記述されるプロセスを経由して２４次元の音響的ケプストラル・ベクトルを発生する。フレームは次に続く音響的ベクトルを得るために１０ｍｓｅｃごとに進められる。他のフレーム・サイズおよびサンプリング・レート／信号バンド幅の音響的フロントエンドも使用できることに留意されたい。
【００５７】
最初に、１つの好ましい音響特性抽出プロセスに従って、１つのフレームの中の音声データのサンプルの離散型フーリエ変換の振幅が対数的にワープされた周波数スケールにおいて考慮される。次に、これらの振幅値そのものが対数のスケールに変換される。後者の２つのステップは周波数および振幅に対する人間のヒアリングの感度が対数的であることによって動機付けられている。それ以降、離散型コサイン変換の形式での回転が適用される。そのダイナミクスを捕捉するための１つの方法は、デルタ（一次微分）およびデルタ−デルタ（二次微分）の情報を使用する方法である。動的情報を捕捉するための他の方法は、考察中のベクトルにその前および次のベクトルのセット（例えば、４）を付加し、次にそのベクトルを、判別が最も大きいとして選定された、より低い次元の空間に投影する方法である。後者の手順は線形判別解析（Linear Discriminant Analysis）（LDA）として知られており、当技術分野において周知である。
【００５８】
図４で文字Ａによって示されている音響特性ベクトルが抽出された後、確率モジュールはその抽出されたベクトルを１つまたはそれ以上の以前に記憶された、部分音声または音響単位であることが当技術分野において周知である、音素をラベル付けする。そのモジュールは、所与のコンテキストの中の音声の部分である部分音声（lefeme）でも動作する。１つまたはそれ以上の特徴ベクトルに関連付けられた各音素は、それが話された特定の音響単位であったことの尤度を示す確率を有している。したがって、確率モジュールは考察された各音素に対して確率の形式での尤度の得点を発生する。その確率は特定の音素または音響単位（ａｕ）が与えられて、音響単位が１つまたはそれ以上の音響特性ベクトルＡによって特徴付けられる発声された話声を表す確率、すなわち、言い換えれば、Ｐ（Ａ／音響単位）である。ブロック４１４および４１６の中で実行される処理は、音響特性ベクトルを抽出してラベル付けすることができる任意の従来の音響情報認識システム、例えば、Lawrence Rabiner, Biing-Hwang Juangの「音声認識の基礎」(Fundamentals of Speech Recognition), Prentice Hall, 1993のシステムによって行うことができることを理解されたい。
【００５９】
ここで、図４のビデオ信号の経路ＩＩを参照して、ビジュアル情報処理の方法が以下に説明される。オーディオビジュアル音声認識モジュール（図１からブロック１６の一部として図４で示されている）は、アクティブ話者顔面検出モジュール４１８を含む。アクティブ話者顔面検出モジュール４１８はカメラ４０４からのビデオ入力を受信する。話者の顔面検出は単にビデオ情報だけでなく、圧縮されたデータ・ドメインおよび／またはオーディオおよびビデオ情報から直接に実行することもできることを理解されたい。いずれの場合でも、モジュール４１８は任意のビデオ背景内で話者の顔面および顔の特徴を一般に見付けて追跡する。これについては以下に詳細に説明する。
【００６０】
また、認識モジュールは前向きポーズ検出モジュール４２０を含むことが好ましい。検出モジュール４２０は、ビデオ・フレーム内の話者が前向きポーズにあるかどうかを判定するのに役立つことも理解することができるだろう。これは誰かが発声している可能性が高いとき、あるいは誰かがそのモジュールによって処理されること、すなわち、モジュールによって認識されることを意味している音声を発声しようとしている可能性が高いときに、そのことを高い信頼性で判断する機能に役立つ。これは少なくともその話者の顔がカメラの１つから見える時の場合である。そうでない時、従来の音声認識を、例えば、無音検出、音声アクティビティ検出および／または雑音補正と一緒に使用することができる。それ故、背景雑音がそれがあたかも音声であるかのようには認識されず、発声の開始は誤って捨てられることはない。そのモジュールのヒアリングの範囲内で行われたすべての音声アクティビティが必ずしもそのシステムに対して意図されているものではないことを理解されたい。そのユーザがシステムに対して話していない可能性があるが、そこにいる誰かに話し掛けているか、あるいは電話機に向かって話している可能性がある。したがって、モジュールはオーディオおよびビジュアル音声認識においてある種の機能をいつ実行するかを判定するために、音声のモードに関連して画像のモードが使用されるように検出モジュールを実施する。
【００６１】
ユーザがシステムに対して話している時を判定する１つの方法は、ユーザがカメラに向かっていて、ユーザの口が音声または言葉のアクティビティを示す時を検出する方法である。これは人間の挙動をよくコピーする。すなわち、誰かが自分を見ていて、唇を動かしているとき、これは一般に、その人が自分に向かって話していることを意味する。
【００６２】
顔面検出モジュール４１８および前向きポーズ検出モジュール４２０によって、考察中のビデオ画像の中の顔のポーズの「前向き」を検出する。ユーザが、（ｉ）多少なりともカメラを見ている、あるいは、（ｉｉ）カメラを直接見ている時（「厳密な前向き」とも呼ばれる）、その顔のポーズを「前向き」であると呼ぶ。好ましい実施形態においては、顔が絶対的に前向きでない（「非前向き」とも呼ばれる）と判断することによって「前向き」を判断する。前向きでない顔のポーズは、頭の向きが厳密な前向きの向きから十分離れていて、その注視がカメラに向けられているとは解釈できないか、または多少なりともカメラに向けられているとも解釈されない時のポーズである。好ましい実施形態において前向きの顔のポーズおよび前向きでない顔のポーズとみなされるものの例が図５に示されている。ポーズＩ、ＩＩおよびＩＩＩはそのユーザの顔が前向きであると考えられる顔のポーズを示し、ポーズＩＸおよびＶはそのユーザの顔が前向きでない考えられる場合の顔のポーズを示す。
【００６３】
図６について説明すると、この図は、顔面検出および前向きポーズ検出を実行する例示としての方法の流れ図を示す。第１のステップ（ステップ５０２）はカメラ４０４から受信された任意の内容のビデオ・フレーム内の顔の候補を検出するステップである。次に、ステップ５０４において、各候補について顔の特徴、例えば、鼻、目、口、耳などを検出する。それ故、ステップ５０６において、顔の候補をそれぞれの前向きに従って刈り込む（ｐｒｕｎｅ）のに必要なすべての情報を有する。すなわち、十分な前向きの特性、例えば、十分に検出された顔の特徴およびこれらの特徴間の距離を有していない候補を取り除く。刈込み方法に対するステップ５０６における代替プロセスは、階層型テンプレート・マッチング技術を含み、これも以下に詳細に説明される。ステップ５０８において、刈込みメカニズムの後、少なくとも１つの顔の候補が存在する場合、考察中のビデオ・フレーム内に前向き顔面があることが判定される。ポーズ検出の一般的問題を解決するための方法がいくつかある。第一に、幾何学方法は、そのポーズに従って、顔の二次元表示（すなわち、カメラ画像）におけるいくつかの特徴の間の距離の変動を単純に考えることを提案する。例えば、僅かに回っている顔の画像上で、右目と鼻との間の距離は左目と鼻との間の距離とは異なっている筈であり、この差は顔の回転に伴って増加する筈である。また、顔の向きを顔の本来的な性質から評価しようとすることもできる。A. GeeおよびR. Cipllaの、「顔の単独画像からの注視の評価」(Estimating Gaze from aSingle View of a Face), Tech. Rep. CUED/F-INFENG/TR174, March 1994の記事の中で、顔の標準は顔のほとんどのポーズ不変距離比を考慮することによって推定されることが示唆されている。
【００６４】
もう１つの方法は元の画像または顔の領域上でフィルタおよび他の簡単な変換を使用する方法である。R. Brunelliの、「顔面処理のためのポース゛および照明方向の評価」(Estimation of pose and illuminant direction for face processing), Imageand Vision Computing 15, pp.741-748, 1997の記事の中で、例えば、照明に対する感度を減らす傾向がある前処理段階の後、２つの目が水平軸上に投影され、その非対称性の量が顔の回転の評価を発生する。
【００６５】
トレーニング方法とみなされる方法では、顔のいくつかの可能なポーズをモデル化することによって顔のポーズを「認識」しようとする。１つの可能性は、A. J. HowellおよびHilary Buxtonの記事、「外観ベースのモデルを使用した視覚的調停型対話に向けて」(TowardsVisually Mediated Interaction Using Appearance-Based Models), CSRP 490, June1998の中で記述されているような放射状基本関数（ＲＢＦ）ネットワークのような神経回路網の使用である。ＲＢＦネットワークは顔の低分解能画像からポーズ・クラスに関して画像を分類するために訓練される。
【００６６】
もう１つの方法は、三次元のテンプレート・マッチングを使用する方法である。N. Kruger, M.Potzch、およびC. von der Malsburgの記事、「ラベル付けされたグラフに基づいて学習された表現による顔の位置およびポーズの判定」（Determination of face position and pose with a learnedrepresentation based on labeled graphs）, Image and Vision Computing 15, pp.665-673, 1997の中で、三次元の弾力性のグラフ・マッチングを使用して顔を表現する方法が提案されている。各ノードはガボール・ジェットのセットに関連し、候補のグラフと異なるポーズに対するテンプレートとの間の類似性を、そのグラフを変形することによって最適化することができる。
【００６７】
もちろん、これらの種々の方法を組み合わせてより良い結果を得ることができる。これらの方法のほとんどすべてが、顔が画像上で以前に見付けられていることを仮定し、そしてしばしば、目、鼻などの顔の中のいくつかの特徴が検出されていることを仮定する。さらに、いくつかの技術、特に幾何学的技術は、この特徴位置検出の精度に大きく依存する。
【００６８】
しかし、画像上で顔および特徴を見付けることは、これも多くの異なる解を有する１つの問題である。好ましい実施形態においては、それを、顔のポーズを非常に正確に判定することを狙いとする一般的なポーズ検出問題より単純である２クラス検出問題として考える。２クラス検出によって、複数クラス検出とは違って、２つの選択肢、例えば、顔の存在または顔の不在、前向き顔面または非前向き顔面などの間の二者択一の判定が行われることを意味する。上記の技術のうちの１つまたはそれ以上を使用することができるが、好ましい実施形態において実施する技術が以下に説明される。
【００６９】
そのような好ましい実施形態においては、アクティブ話者の顔面検出モジュール４１８および前向きポーズ検出モジュール４２０によって顔および特徴の検出を行うために使用される主な技術は「フィッシャーの線形判別」（ＦＬＤ）解析に基づいている。ＦＬＤ解析の目標はクラス間の最大の判別を得ること、および特徴空間の次元を減らすことである。顔面検出の場合、２つのクラスを考える。それらは、（ｉ）入力クラス（顔面を含む）および、（ｉｉ）出力クラス（非顔面から構成される）である。ＦＬＤ解析の基準は、次に、以下の比を最大にする特徴空間のベクトル
【数１】
2004538543.tif 000003
は、以降ｗアローと記載する。
を見付けることである。
【数２】
2004538543.tif 000004
【００７０】
ここで、ＳＢはクラス間の散乱行列であり、ＳＷはクラス内の散乱行列である。
【００７１】
右のｗアロー（ＦＬＤと呼ばれる）を見付けて、
【数３】
2004538543.tif 000005
を計算することによってそれの上に各特徴ベクトル
【数４】
2004538543.tif 000006
は以降ｘアローと記載する。
を投影し、その結果を１つのしきい値と比較し、ｘアローが入力クラスに属するか、または出力クラスに属するかどうかを決定する。式（１）を最大にする特徴空間ｗアローのベクトルを見付ける前に、特徴空間の次元を減らすために、周知のように、主成分分析（Principal Component Analysis）(PCA)を使用することができる。例えば、P.N. Belhumeur, J. P. HespanhaおよびJ. P. Kriegmanの、「固有顔面対フィッシャー顔面：クラス固有の線形投影を使用した認識」（Eigenfacesvs. Fisherfaces:Recognition Using Class Specific Linear Projection, IEEE Transactionon Pattern Analysis and Machine Intellgence, vol.19, no.7, July 1997を参照されたい。
【００７２】
顔面検出（図６のステップ５０２）は、先ず最初にビデオ・シーケンスの第１のフレーム内の顔の位置確認を含み、その位置がビデオ・クリップ内のフレームにわたって追跡される。顔の検出は以下の方法で実行されることが好ましい。顔の位置をつきとめるためには、許容できるスケールでの画像のピラミッドが発生され、そのピラミッド内のすべての場所に対して顔の位置としての回りの領域を得点付ける。カラーが顔の存在を示す可能性のあるピラミッド内の画像領域を見付けることを狙いとするスキン・トーン・セグメンテーションのプロセスの後、その画像が部分サンプルされ、領域がＦＬＤ解析により顔面テンプレートの以前に記憶された発散トレーニング・セットと比較される。これは顔からの距離空間(Distance From Face Space)(DFFS)測度と組み合わされて顔の尤度の得点を与える得点を発生する。周知のように、ＤＦＦＳは共分散行列の固有値上での画像エネルギーの分散を考慮する。合計得点が高ければ高いほど、その考察されている領域が顔である可能性が高くなる。それ故、すべての基準について得点が高い場所が顔であると判断される。得点の高い各顔の位置に対して、１つのフレームから次のフレームへ発生する変換、スケールおよび回転の小さな変化を考慮し、これらの各変化の下での顔の領域の得点を計算し直して、これらのパラメータ（すなわち、FLDおよびDFFS）の評価値を最適化する。DFFSは、M. TurkおよびA. Pentlandの記事、「認識のための固有顔面」(Eigenfaces for Recognition), Journalof Cognitive Neuro Science, vol.3, no.1, pp.71-86,1991の中にも記述されている。本発明によって使用される可能性のある顔および特徴の発見のためのコンピュータ・ビジョン・ベースの顔面識別方法が、Andrew Seniorの、「顔面認識システムのための顔面および特徴の発見」(Face and feature finding for face rercognition system), 2nd Int. Conf.On Audio-Video based Biometric Person Authentication, Washington DC, March 1999の中で記述されている。顔の特徴を検出するために、同様な方法が適用され、統計的な位置の考察と組み合わされる（図６のステップ５０４）。この顔および特徴の検出技術は、厳密に前向き顔面だけを検出するように設計され、そのテンプレートは非顔面から厳密に前向きの顔面を区別することだけを意図しており、より一般的な前向き顔面はまったく考慮されていない。
【００７３】
もちろん、この方法は顔および特徴のテンプレートの生成を必要とする。これらは前向き顔面画像のデータベースから発生される。トレーニングの顔面または特徴のベクトルが入力クラスに追加され、いくつかの出力クラスのベクトルがそのトレーニング画像の中の背景からランダムに生成される。
【００７４】
得点のしきい値決定技術において、合計得点をしきい値と比較し、顔の候補または特徴の候補が真の顔または特徴であるかどうかを決定することができる。このＦＬＤ解析に基づいた得点は実用的なポーズ検出の問題に対して興味深い性質を有している。実際、所与のユーザに対して、そのユーザが頭を回転している際の得点が変化する。例えば、顔がより前向きである時には得点が高くなる。
【００７５】
次に、厳密に前向きの顔およびその中の特徴を検出するための方法が既にあって、その方法を２クラス検出問題に対してできるだけ近付けるように適合させる。好ましい実施形態においては、そのモジュールはその検出方法を適合させるための２つの代替方法を提供する（図６のステップ５０６）。それらは、（ｉ）刈込みメカニズム、および（ｉｉ）階層型テンプレート・マッチング技術である。
刈込みメカニズム
【００７６】
ここで、顔面検出のために既に計算されたテンプレートを再使用する。本発明の顔および特徴の検出技術は厳密に前向きの顔のトレーニング・データだけを必要とし、それ故、より広いデータベースは不要である。その方法は顔および特徴検出を組み合わせて非前向き顔面を取り除くことを含む。最初に上記アルゴリズムに従ってフレーム内の顔面を検出するが、意図的に得点のしきい値を低くする。この低いしきい値により、厳密な前向きの顔からは程遠い顔面を検出し、前向きが大きいか、あるいは小さい顔面をどれもミスしないようにすることができる。もちろん、これはいくつかのプロファイル顔面および場合によっては非顔面を発生する。次に、各候補において、その顔の特徴（目、鼻、唇など）の場所を推定する。
【００７７】
誤った候補は次の独立の計算に従って候補から外される。
i) すべての顔の特徴の得点の合計:これはFLDおよびDFFSの組合せから与えら(れる。その合計はその候補が捨てられるべきであるかどうかを判定するためにしきい値と比較される。
(ii) 良好に認識されている主な特徴の数:目、鼻および口に対する得点が低い候補を捨てる。実際に、これらは人間の顔の最も特徴的な、そして目に見える特徴であり、それらは前向き顔面と非前向き顔面との間で大きく異なる。
(iii) 各目と鼻の中央との間の距離の比。
(iv) 各目と顔面領域の側面との間の距離の比（各顔面はテンプレート・マッチングのための四角形によって区切られている。例えば、Ａ．Ｓｅｎｉｏｒ（シニア）の上記文献参照）。特に、その比率は中心軸からの右目の外側の先端の距離に対する中心軸からの左目の外側の先端の距離の比率である。その比率は見る人の透視角に依存し、したがって、１つの基準として使用することができる。
【００７８】
これらの比率は二次元投影の理由のために、その顔が非前向きであればあるほど１とは異なる。したがって、これらの比率を各顔の候補に対して計算し、それらを１と比較してその候補が捨てられるべきであるかどうかを決定する。
【００７９】
次に、１つまたはそれ以上の顔の候補が候補スタックの中に残った場合、前向き顔面がその考察されているフレームの中で検出されていると考える。
【００８０】
最後に、実際的な理由のために、バースト・メカニズムを使用して結果を滑らかにすることが好ましい。ここでは、この対話的システムの特殊性を使用する。カメラの前にいる（あるいはいない）ユーザを考えるので、時間的なその挙動を考慮に入れることができる。ビデオ・カメラが高いレート（通常、３０フレーム／秒）でユーザの画像を撮影すると思われるので、人間はフレーム・レートに比較してゆっくりと動くと考え、現在のフレーム内の結果を予測するために前のフレームの結果を使用することができる。
【００８１】
したがって、現在のフレーム内に前向きの顔面が検出されていた場合、次のｘ個のフレーム（ｘはフレーム・レートによって変わる）内でそれが前向きのままになっていると考えることができる。もちろん、これはユーザが振り向くか、あるいは立ち去る際に顔が実際に前向きから非前向きとなるいくつかの間違った肯定検出を追加することになるが、間違った否定検出がより低くなる場合、いくつかのより多い間違った肯定の検出を受け入れることができる。実際に、間違った否定の検出は間違った肯定の検出より、この人間−コンピュータ対話システムにとっては悪い。コンピュータが場合によっては聴き過ぎる場合であっても、ユーザの音声の単独ワードをミスしないことが非常に重要である。
【００８２】
この刈込み方法には多くの利点がある。例えば、それは特定のデータベースを計算する必要がない。顔面検出を行うための計算されたものを再使用することができる。また、簡単なしきい値方式に比較して、得点の高い非顔面のいくつかを捨てる。何故なら、それは顔の特徴および顔の幾何学的形状などの顔特有の事項のいくつかに依存するからである。
階層型テンプレート・マッチング
【００８３】
検出の問題を解決するためのもう１つの解決策はテンプレート・マッチング技術を修正する方法である。実際に、ＦＬＤの計算技術は「非前向き」の顔面をまったく考慮せず、入力クラスは「厳密に前向きの」顔面だけを含み、出力クラスは非顔面だけを含む。そこで、この代替実施形態に従って、以下のような他の形式のテンプレートを使用することができる。
(i) 入力クラスが、前の技術と違って、非前向き顔面以外に前向き顔面を含み、そして出力クラスが非前向き顔面を含む顔面テンプレート。
(ii) 入力クラスが厳密に前向きの顔面を含み、出力クラスが非前向き顔面を含むポーズ・テンプレート。
【００８４】
これらの２つのテンプレートを使用することによって、階層型テンプレート・マッチングを行うことができる。先ず最初に、実際の顔面らしさの得点を計算するために顔面テンプレートでのテンプレート・マッチングを行う。これは顔面（前向きまたは非前向き）または非顔面があるかどうかを示す（しきい値との比較の後に）。次に、このマッチングによって顔面が実際に検出された場合、ポーズ・テンプレートによる第２のテンプレート・マッチングを実行することができる。この場合、前向き尤度の得点を発生する。この最後のポーズ得点は前の顔面得点より非前向きから前向きまでの種々のより良い顔面を有している。
【００８５】
したがって、階層型テンプレートの方法によって、ユーザへの依存性がより少ないしきい値を容易に見付けることができ、簡単な顔面発見得点しきい値化によって問題を解くことができる。この階層型テンプレート・マッチング法の利点は、ポーズ得点（すなわち、ポーズ・テンプレート・マッチングによって与えられる得点）が非顔面（すなわち、顔面テンプレート・マッチングによって顔面として間違って検出されることになった非顔面）に対して非常に低く、これは非顔面を捨てるのに役立つ。
【００８６】
刈込み法または階層型テンプレート・マッチング法のいずれかの結果が与えられて、１つまたはそれ以上の前向きポーズの存在の評価がモジュール４２０（図４）によって出力される。これらの評価（モジュール４１８および４２０に従って計算されたＦＬＤおよびＤＦＦＳパラメータを含むことができる）は、考察中のビデオ・フレーム内に前向きポーズを有している顔面が検出されるかどうかを表す。これらの評価が、モジュール４１４の中で抽出されたオーディオ特徴ベクトルＡおよび、ビジュアル音声特性抽出器モジュール４２２（以下に説明される）の中で抽出されたビジュアル音声特性ベクトルＶと一緒に、イベントモジュール４２８によって使用される。
【００８７】
ここで図４へ戻ると、ビジュアル音声特性抽出器４２２は、アクティブ話者画面検出器４１８によってビデオ・フレームの中で検出された顔から、文字Ｖとして図４の中で示されているビジュアル音声特性ベクトル（例えば、口または唇に関連したパラメータ）を抽出する。
【００８８】
抽出することができるビジュアル音声特性の例は、口の領域のグレイ・スケール・パラメータ；口の領域の面積、高さ、幅などの幾何学的／モデル・ベースのパラメータ；曲線あてはめ、内側／外側の輪郭のスプライン・パラメータによって得られる唇の輪郭；および三次元追跡によって得られる動きのパラメータである。モジュール４２２を経由して抽出することができるさらにもう１つの特徴セットは、上記のファクタを考慮に入れる。上記技術は、「アクティブ形状」モデリングとして知られており、Iain Matthewsの博士論文、「オーディオビジュアル音声認識のための特徴」（Features for audio visual speech recognition）, School of Information Systems, Universityof East Angalia, January 1998に記載されている。
【００８９】
したがって、ビジュアル音声特性抽出器４２２は、１つまたはそれ以上の既知のビジュアル特徴抽出技術を実施することができるが、ある実施形態においては、この抽出器は画像の口の領域に関連付けられたグレイ・スケールのパラメータを抽出する。唇のコーナーの位置が与えられて、スケールおよび回転の正規化の後、四角形の中央にある唇の領域を含む四角形領域が元の解凍されたビデオ・フレームから抽出される。周知のように、主成分分析（ＰＣＡ）を使用してこのグレイ・スケール値のベクトルからより小さい次元のベクトルを抽出することができる。
【００９０】
モジュール４２２の中で実施することができるもう１つのビジュアル特徴ベクトルの抽出方法は、幾何学的特徴の抽出を含むことができる。これは唇の輪郭の幾何学形状およびその時間的ダイナミクスから音素／ビジュアル音素（visemic）情報を抽出することを含む。代表的なパラメータは口のコーナー、開口部の高さまたは面積、内側および外側の唇の曲率である。調音器官、例えば、歯および舌の位置も、それらがカメラによって見分けが付く範囲で特徴パラメータとなり得る。
【００９１】
グレイ・スケール値からこれらのパラメータを抽出する方法は、パラメータ値に関連付けられた唇の輪郭とグレイ・スケール画像との間のミスマッチを記述する関数（例えば、コスト関数）の最小化を含むことができる。これらのパラメータの抽出においてカラー情報を利用することもできる。
【００９２】
捕捉された（またはデマルチプレックスされて解凍された）ビデオ・ストリームから、境界検出を実行することができ、その究極の結果はパラメータ化された輪郭、例えば、円、放物線、楕円または、より一般的にはスプライン輪郭であり、そのそれぞれを有限のパラメータの組によって記述することができる。
【００９３】
抽出することができるさらに他の特徴としては、アニメーションの目的のためにコンピュータ・グラフィクスにおいて使用されるタイプの二次元または三次元のワイヤーフレーム・モデルベースの技術を含む。ワイヤーフレームは多数の三角形のパッチから構成することができる。これらのパッチは一緒になって口／唇／顎の領域の構造的表現を与え、そのそれぞれが読唇において有用な特徴を含んでいる。これらのパラメータも画像のグレイ・スケール値と組み合わせて使用することができ、両方の方式の相対的利点から恩恵を受けることができる。
【００９４】
抽出されたビジュアル音声特性ベクトルは次に、検出モジュール４２０によって発生された前向きポーズの評価に関してブロック４２４の中で正規化される。次にその正規化されたビジュアル音声特性ベクトルが確率モジュール４２６に提供される。１つまたはそれ以上の音素で音響特性ベクトルにラベル付けするオーディオ情報経路における確率モジュール４１６と同様に、確率モジュール４２６は１つまたはそれ以上の以前に記憶された音素でその抽出されたビジュアル音声ベクトルにラベル付けする。ふたたび、１つまたはそれ以上のビジュアル音声特性ベクトルに関連付けられた各音素は、考察中のビデオの中で話された特定の音響単位であったことの尤度を示すそれに関連付けられた確率を有する。したがって、確率モジュールは特定の音素または音響単位（ａｕ）が与えられて、その音響単位が１つまたはそれ以上のビジュアル音声特性ベクトルＶまたは、言い換えれば、Ｐ（Ｖ／音響単位）によって特徴付けられる、その発声された音声を表すことの確率の形式で考察されている各音素に対して尤度の得点を発生する。他の方法としては、ビジュアル音声特性ベクトルに、以前に述べたように、視覚的音素、すなわち、音声の発声を伴う標準形の口の形状であるビジュアル音素でラベル付けすることができる。
【００９５】
次に、モジュール４１６および４２６によって発生された確率が、Ａ，Ｖの確率モジュール４３０によって合同で使用される。モジュール４３０において、モジュール４１６および４２６からのそれぞれの確率が、信頼の測度４３２に基づいて組み合わされる。信頼の評価は認識される入力に関して判定されつつある尤度または他の信頼の測度を指す。最近、認識された音声に対する適切な信頼測度を開発するための努力が開始されている。ＮＩＳＴおよびＤＡＲＰＡによって組織化されたＬＶＣＳＲ  Ｈｕｂ５ワークショップ、Ａｐｒｉｌ  ２９−Ｍａｙ  １，１９９６，ＭＩＴＡＧＳ，ＭＤにおいて、各ワードに信頼レベルを付加するための種々の方法が提案されている。第１の方法はワード依存の特徴（発声トレーニングの量、最小および平均の三音（triphone）の発生回数、言語モデルのトレーニングにおける発生、音素／部分音声の個数、持続時間、音響的得点（高速マッチおよび詳細マッチ）、音声または非音声）、文章依存の特徴（信号対雑音比、話のレートの評価値：１秒当たりのワードの数または部分音声の数または母音の数、言語モデルによって提供される文章らしさ、言語モデルの中の三重字（trigram）の発生回数）、コンテキストの中のワードの特徴（言語モデルの中での三重字の発生回数）および話者のプロファイルの特徴（アクセント、方言、性別、年令、話しのレート、アイデンティティ、オーディオ品質、ＳＮＲなど）において訓練された判定ツリーを使用する。そのツリーの各葉に対してトレーニング・データについて誤りの確率が計算される。そのようなツリーを作るためのアルゴリズムは、例えば、Breiman他の、「分類および回帰ツリー」（Classificationand regression trees）, Chapman &Hall, 1993に開示されている。認識において、これらの特徴のすべてまたはいくつかが認識時に測定され、そして各ワードに対してその判定ツリーが、信頼レベルを提供する葉に向かって辿られる。C. Neti, S. RoukosおよびE. Eideの、「音声認識におけるスタック・サーチのためのガイドとしてのワード・ベースの信頼測度」（Word based confidence measures as a guide for stack search in speechrecognition）, ICASSP97, Munich, Germany,April, 1997の中で、ＩＢＭのスタック・レコーダによって返される得点（対数の尤度を使用する−実際にはその平均の増分的な対数の尤度、詳細マッチ、高速マッチを使用している）に全面的に依存している方法が記述されている。ＬＶＣＳＲの予稿において、信頼レベルを評価するためのもう１つの方法が線形回帰を経由して予測器を使用して行われている。使用される予測器は、ワードの持続時間、言語モデルの得点、フレーム当たりの平均の音響的得点（最良の得点）および、トップ選択と同じワードによるＮベスト・リストの一部分などである。
【００９６】
この実施形態は、音声認識に限られずに任意の変換プロセスにおける信頼度を系統的に抽出するためにこれらの２つの方法（判定ツリーを経由して測定された信頼レベル、および線形予測器を経由して測定された信頼レベル）の組合せを提供することが好ましい。間違って認識されたワードを検出するためのもう１つの方法が、「高速のワード受け入れまたはリジェクションのための、個々の、あるいは話者のクラス依存のデコーディング履歴キャッシュを含む音声認識のための装置および方法」(Apparatus and Methods for Speech Recognition Including Individualor Speaker Class Dependent Decoding History Caches for Fast Word Acceptance orRejection)という名称の米国特許第5,937,383号に開示されている。
【００９７】
したがって、信頼の測度に基づいて、確率モジュール４３０はどの確率、すなわち、ビジュアル情報経路からの確率またはオーディオ情報経路からの確率のどれに、より信頼が置けるかを判定する。この判定は次の方法で表現することができる。
【００９８】
ｗ１νＰ＋ｗ２αＰ        （２）
【００９９】
νＰはビジュアル情報に関連する確率を表し、αＰは対応しているオーディオ情報に関連付けられられた確率を表し、そしてｗ１およびｗ２はそれぞれの重みを表すことを理解されたい。したがって、信頼の測度４３２に基づいて、モジュール４３０はその確率に対して適切な重みを割り当てる。例えば、周囲の環境の雑音レベルが特に高い場合、すなわち、音響的信頼の測度が低くなる結果となる場合、音響的デコーディング経路によって発生される確率が誤りを含んでいる可能性が高い。したがって、モジュール４３０はビジュアル経路からの復号された情報をより信用してｗ１よりｗ２に対して低い重みを割り当てる。しかし、雑音レベルが低く、したがって音響的信頼の測度が比較的高い場合、モジュールはｗ２をｗ１より高く設定する可能性がある。他の方法としては、ビジュアル信頼測度を使用することができる。モジュール４３０におけるビジュアル情報とオーディオ情報との第１の組合せ使用は、判定または得点融合と呼ばれることを理解されたい。
【０１００】
次に、モジュール４３０から受信された重み付けられた確率に基づいて言語モデル（ＬＭ）によってサーチ・モジュール４３４の中でサーチが実行される。すなわち、任意の内容のビデオの中で発声されたことを表している確率が最も高いとして識別された音響単位がつなぎ合わされてワードを形成する。そのワードが復号されたシステム出力としてサーチ・エンジン４３４によって出力される。従来のサーチ・エンジンを使用することができる。この出力は上記のように、ユーザの意図を明確化する際に使用するために図１のダイアログ・マネージャ１８に提供される。
【０１０１】
好ましい実施形態においては、図４のオーディオビジュアル音声認識モジュールはイベント検出モジュール４２８も含む。前に述べたように、従来の音声認識システムの１つの問題点は、余分の可聴アクティビティ、例えば、復号されることが意図されていない背景雑音または背景音声と、復号されることが実際に意図されている音声との間の判別ができないことである。これによって、システムの不発（misfiring）および「ジャンク」（junk）認識などの問題が発生する。種々の実施形態によると、そのモジュールはビデオ経路のみからの情報、オーディオ経路のみからの情報、あるいは両方の経路からの情報を同時に使用して、情報を復号すべきかどうかを決定することができる。これはイベント検出モジュール４２８を経由して実現される。「イベント検出」は復号されるべく意図されている実際の音声イベントが発生しているか、あるいは発生しようとしているかどうかの判定を意味することを理解されたい。イベント検出モジュールの出力に基づいて、マイクロホン４０６またはサーチ・エンジン４３４をイネーブル／ディスエーブルすることができる。顔が検出されていない場合、その音声を処理して判定を行うことができることに留意されたい。
【０１０２】
ここで図７について説明すると、この図は、ビデオ経路のみからの情報を使用して検出判定を行うイベント検出方法の一例を示す。この判定を行うために、イベント検出モジュール４２８は前向きポーズ検出器４２０、ビジュアル特徴抽出器４２４（ポーズ正規化ブロック４２６を経由しての）、およびオーディオ特徴抽出器４１４からの入力を受信する。
【０１０３】
最初に、ステップ５１０において、「前向き」であるとして識別された顔の上の口の開口部が検出される。この検出はモジュール４１８および４２０に関して上記詳細に説明されたような、検出された前向き顔面に関連する顔の特徴の追跡に基づいている。口の開口部またはいくつかの口の動きが検出された場合、マイクロホン４０６がステップ５１２においてオンにされる。マイクロホンがオンにされると、そこから受信される信号がバッファの中に記憶される（ステップ５１４）。次に、口の開口部のパターン認識（例えば、周期性）がバッファされた信号に関連する口の動きについて実行され、バッファされたものが実際の音声であったかどうかが判定される（ステップ５１６）。これはビジュアル音声特性ベクトルを、音声と首尾一貫しているあらかじめ記憶されたビジュアル音声パターンと比較することによって判定される。そのバッファされたデータに音声としてタグが付けられている場合、ステップ５１８において、そのバッファされたデータが音響的経路を通して送信され、そのバッファされたデータがステップ５２０によって認識される可能性があり、復号された出力が発生される。口の開口部が検出されなくなるまで、バッファされたデータのそれ以降の各部分に対してこのプロセスが繰り返される。口の開口部が検出されなくなると、マイクロホンはその時にオフにされる。図７は入力のオーディオ信号を復号するかどうかを判定するためにビジュアル情報（例えば、口の開口部）が使用される方法の一例を示すことを理解されたい。他の方法としては、イベント検出モジュールがサーチ・モジュール４３４を制御することができる。例えば、音声イベントが検出されたかどうかに対する応答においてそれをオンまたはオフにすることができる。したがって、イベント検出モジュールは一般に、マイクロホンによって捕捉された入力信号が、音声が所与のオーディオおよび対応しているビデオの情報、すなわち、Ｐ（音声｜Ａ，Ｖ）を決定するモジュールである。
【０１０４】
また、イベント検出の方法はオーディオ経路情報のみを使用しても実行できることも理解されたい。そのような場合、イベント検出モジュール４２８は１つまたはそれ以上の音声のみをベースとして検出方法を実行することができる。それらの方法としては、例えば、信号エネルギー・レベル検出（例えば、オーディオ信号レベルが所与のレベル以上である）、信号のゼロ交差検出（例えば、十分高いゼロ交差がある）、例えば、N. R. Garner他の、「音声認識および改善のためのロバストな雑音検出」(Robust noise detection for speech recognition and enhancement),Electronics letters, Feb. 1997, vol.33, no 4, pp.270-271の中で記述されているような音声アクティビティ検出（スペクトルの非定常性）；D. K. Freeman他の、「汎ヨーロッパ・ディジタル移動電話サービスの音声アクティビティ検出器」(Thevoice activity detector of the pan-European digital mobile telephone service), IEEE1989, CH2673-2; N. R. Garnerの、「逆移動電話音響的環境における音声検出」(Speech detection in adverse mobile telephony acousticenvironments), Speech Communicationsの中の記事;B. S Atal他の、「音声認識に対する用途での有声-無声-沈黙分類に対するパターン認識方法」(A pattern recognitionapproach to voiced-unvoiced-silence classification with applications to sppechrecognition), IEEE Trans. Acoustic, Speech and Signal Processing, vol.ASSP-24n3, 1976などがある。また、L. R. Rabinerの、「音声信号のテ゛ィシ゛タル処理」(Digital processing ofspeech signals), Prentice-hall, 1978も参照されたい。
【０１０５】
ここで図８について説明すると、この図は、ビデオ経路およびオーディオ経路の両方の情報を同時に使用して検出判定を行うためのイベント検出方法の一例を示す。この流れ図は、非ス−パバイザ型発声検証方法を示す。非ス−パバイザ型のモードにおいては、発声検証はテキストが分かっておらず、そしてシステムに対して利用できる時に実行される。
【０１０６】
したがって、ステップ５２２において、検証される発声された音声は古典的な音声認識技術によって復号することができ、復号されたスクリプトおよび関連する時間のアラインメントが利用できるようにすることができる。これは音響特性抽出器４１４からの特徴データを使用して実行される。同時発生的に、ステップ５２４において、ビジュアル特徴抽出器４２２からのビジュアル音声特性ベクトルが、ビジュアル音素（visemes）のシーケンスを作り出すために使用される。
【０１０７】
次に、ステップ５２６において、そのスクリプトがビジュアル音素に位置あわせされる。２つの情報ストリームを同期化させようとするために、従来の方法で迅速（あるいは他の）アラインメントを実行することができる。例えば、ある実施形態においては、迅速アラインメントを使用することができる。次に、ステップ５２８において、アラインメントについての尤度が計算され、そのスクリプトがビジュアル・データに対してどのようによく整列されているかが判定される。その尤度の結果が次にステップ５３０において使用され、実際の音声イベントが発生したか、あるいは発生しつつあるかどうか、そしてその経路の中の情報が認識されるべきであるかどうかが判定される。
【０１０８】
図４のオーディオビジュアル音声認識モジュールはイベント検出を実行するためにイベント検出モジュール４２８の中で上記の方法の１つ、２つの組合せ、あるいは３つのすべてに適用することができる。ビデオ情報のみに基づいた検出は有用であり、音声のみの判定するには背景雑音が大き過ぎる時にモジュールが検出を行うことができる。オーディオのみの方法は顔が見えていない時に音声が発生する時に有用である。非ス−パバイザ型発声検証によって提供される組み合わされた方法は、音響的判定を改善するために正しいポーズで顔が検出できる時に判定のプロセスを改善する。
【０１０９】
認識エンジンの不発および／または「ジャンク」認識を最小化または消去することの他に、このイベント検出方法は背景雑音のより良いモデリングを提供する。すなわち、音声が検出されない時、沈黙が検出される。また、組込み型の用途に対して、そのようなイベント検出は追加の利点を提供する。例えば、組込み型の装置に関連付けられているＣＰＵは音声検出モジュールの中で実行しなければならないことの代わりの他のタスクに集中することができる。また、音声が存在しない時、音声認識エンジンおよび関連する構成要素の電源をオフにすることができるので、バッテリ電力の節約が実現される。この音声検出方法の他の一般的な用途としては、（ｉ）可視電磁波スペクトル画像、あるいは不可視電磁波スペクトル画像（例えば、遠赤外線）カメラと一緒に乗り物ベースの音声検出または雑音の多い環境における使用、（ii）ローカルまたはアレイのマイクロホンにフォーカスするための聴衆の中での話者検出、（iii）話者検出（上記文書番号ＹＯ９９９−３１８によって識別される米国特許出願の中のような）および放送のニュースまたは遠隔ビデオ会議の中でのタグ付けなどがある。当業者であれば、ここで記述された本発明の内容が与えられて他の用途を想像することができる。
【０１１０】
図４のオーディオビジュアル音声認識モジュールは、オーディオビジュアル音声検出および認識の代替実施形態を使用することができることを理解されたい。例えば、図４の実施形態は判定または得点融合の方法を示すが、そのモジュールは特徴融合の方法および／またはシリアル再得点法を使用することができる。
Ｂ．オーディオビジュアル話者認識
【０１１１】
ここで図９について説明すると、この図は、本発明に従って受信した多モード入力データを使用して話者認識を実行するために、図１の認識モジュールの１つとして使用することができるオーディオビジュアル話者認識モジュールの好ましい実施形態のブロック図を示す。本発明の多モード会話型コンピューティング・システムの好ましい実施形態の中で使用するためのそのようなオーディオビジュアル話者認識モジュールの実施形態の１つの記述が、このセクションの中で以下に提供される。しかし、話者認識を実行するための他のメカニズムを使用することができることを理解されたい。
【０１１２】
図９に示されているオーディオビジュアル話者認識および発声検証モジュールは、判定融合の方法を使用する。図４のオーディオビジュアル音声認識モジュールと同様に、図９の話者認識モジュールはカメラ６０４から同じタイプの任意の内容のビデオを受信し、マイクロホン６０６からＩ／Ｏマネージャ１４を経由してオーディオを受信することができる。カメラおよびマイクロホンの参照番号は図４の中と図９の中では異なっているが、それらは同じカメラおよびマイクロホンであってよいことを理解されたい。
【０１１３】
ローマ数字Ｉで示されている点線は、オーディオ情報信号がそのモジュールの内部で取る処理経路を表し、ローマ数字のＩＩによって示されている点線はビデオ情報信号がそのモジュールの内部で取る処理経路を表す。最初に、オーディオ信号経路Ｉが説明され、次にビデオ信号経路ＩＩが説明され、その後に２つのタイプの情報がどのように組み合わされて改善された話者認識精度を提供するかの説明が続く。
【０１１４】
このモジュールは音の特徴抽出器６１４を含む。特徴抽出器６１４は当技術分野において周知のように、オーディオまたは音声の信号を受信し、その信号から一定間隔においてスペクトルの特徴を抽出する。そのスペクトルの特徴はオーディオ話者認識モジュール６１６に対して次に渡される音響特性ベクトル（信号）の形式になっている。音響ベクトルが抽出される前に、音声信号を１６キロヘルツ(kHz)のレートでサンプルすることができる。１つのフレームは持続時間が２５ミリ秒（msec）である音声のセグメントから構成することができる。そのような構成において、抽出のプロセスは以下に記述されるプロセスを経由して２４次元の音響ケプストラル・ベクトルを発生することが好ましい。フレームは１０ｍｓｅｃごとに進められて次々の音響ベクトルが得られる。もちろん、他のフロントエンドを使用することもできる。
【０１１５】
最初に、１つの好ましい音響特性抽出プロセスに従って、１つのフレーム内の音声データのサンプルの離散型フーリエ変換の振幅が対数的にワープされた周波数スケールにおいて考慮される。次に、これらの振幅値そのものが対数スケールに変換される。後者の２つのステップは人間のヒアリングの感度が周波数および振幅に対して対数的であることによって動機付けられている。次に、離散型コサイン変換の形式での回転が適用される。そのダイナミクスを捕捉するための１つの方法は、デルタ（一次微分）およびデルタ−デルタ（二次微分）の情報を使用する方法である。動的情報を捕捉するための代替方法は、前および後のベクトルのセット（例えば、４）を、考察中のベクトルに付加し、次にそのベクトルをより低い次元の空間へ投影し、それが最も判別の大きいものとして選定される方法である。後者の手順は線形弁別解析（Linear Discriminant Analysis）(LDA)として知られ、当技術分野において周知である。特徴に関する他のバリエーション、例えば、ＬＰＣケプストラ、ＰＬＰなどを使用することができること、そして本発明がどの特定のタイプにも限定されないことを理解されたい。
【０１１６】
図９で文字Ａで示されている音響特性ベクトルが抽出された後、それらはオーディオ話者認識モジュール６１６に提供される。モジュール６１６はその抽出された音響特性ベクトルを使用して話者識別および／または話者検証を行うことができることを理解されたい。話者識別および検証のプロセスは従来の音響的情報話者認識システムを経由して実行することができる。
【０１１７】
モジュール６１６において使用するための話者識別プロセスの一例がここで説明される。このシステムの例は、H. Beigi, S. H. Maes, U. V. ChaudariおよびJ. S. Sorensonの、「IBMのモデルベースの、およびフレームごとの話者認識」(IBM model-besed andframe-by-frame speaker recognition), Speaker Recognition and its Commercial andForensic Applications, Avignon, France 1998に開示されている。この例示的な話者識別システムは２つの技術、すなわち、モデルベースの方法およびフレームベースの方法を使用することができる。ここで記述されている実験において、話者識別のためにオーディオに基づいたフレームベースの方法を使用する。フレームベースの方法は次のように説明することができる。
【０１１８】
Ｍｉをｉ番目の登録された話者に対応しているモデルあるとする。Ｍｉはパラメータ・セット
【数５】
2004538543.tif 000007
によって定義される混合のガウス・モデルによって表され、話者ｉのモデルのｎｉ構成要素のそれぞれに対する平均ベクトル、共分散行列、および混合の重みから構成される。これらのモデルはｄ次元のケプストラル特徴ベクトル
【数６】
2004538543.tif 000008
を伴う音声のＫ個のフレームのシーケンスから構成されるトレーニング・データを使用して生成される。話者識別の目標はＮ個のフレームのシーケンスによって表されるテスト・データ、
【数７】
2004538543.tif 000009
を最もよく説明するモデルＭｉを見付けることである。その判定を行うに際して、次のフレームベースの重み付けられた尤度の距離の測度、ｄｉ，ｎを使用する。
【数８】
2004538543.tif 000010
【０１１９】
テスト・データからのモデルＭｉの合計距離Ｄｉが次に、すべてのテスト・フレームにおける距離の合計であるとして取られる。
【数９】
2004538543.tif 000011
【０１２０】
したがって、上記の方法は最も近いマッチング・モデルを見付け、そしてそのモデルが表す人が、その人の発声が処理されつつある人であるとして判定される。
【０１２１】
話者検証を同様な方法で実行することができるが、入力の音響的データが、そのデータが記憶されているモデルに十分近くマッチしているかどうかを判定するために比較される。その比較結果が十分近くマッチしている場合、その音声を発声している人が検証される。そのマッチは競合しているモデルとそのマッチを比較することによって受け入れられるか、あるいはリジェクトされる。これらのモデルはクレイマント（claimant）話者に対して同様であるように、すなわち、話者独立であるように選択することができる（すなわち、１つの話者独立モデルまたは話者独立モデルのセット）。そのクレイマントが勝ちを得て、その勝ちが十分なマージン（尤度のレベルまたはモデルに対する距離において計算された）で得られた場合、そのクレイマントを受け入れる。そうでなかった場合、そのクレイマントはリジェクトされる。登録時に、入力音声が話者に対して収集されて、各話者を特徴付ける混合のガウス・モデルＭｉを構築することを理解されたい。
【０１２２】
ここで図９のビデオ信号経路ＩＩを参照して、ビジュアル情報を処理する方法が説明される。オーディオビジュアル話者認識および発声検証モジュールは、アクティブ話者顔面セグメンテーション・モジュール６２０および顔面認識モジュール６２４を含む。アクティブ話者顔面セグメンテーション・モジュール６２０は、ビデオ入力をカメラ６０４から受信する。話者顔面検出はビデオ情報からだけでなく、圧縮されたデータ・ドメインおよび／またはオーディオおよびビデオの情報から直接に実行することもできることを理解されたい。いずれの場合においても、セグメンテーション・モジュール６２０は一般に話者の顔面および顔の特徴を任意のビデオ背景の中で見付けて追跡する。これは以下に詳細に説明される。セグメンテーション・モジュール６２２から提供されたデータから、識別および／または検証の動作を、認識モジュール６２４によって実行することができ、ビデオの中の話者であると仮定される人の顔を識別および／または検証することができる。また、検証は得点のしきい値判定または競合しているモデルを追加することによっても実行することができる。したがって、話者識別のビジュアル・モードは顔面認識システムとして実施され、そこで顔がビデオ・シーケンスの中で見付けられて追跡され、候補の顔面テンプレートのデータベースと比較することによって認識される。後で説明されるように、発声検証はその人を認識するために使用された音声をその人が実際に発声したことを検証するための技術を提供する。
【０１２３】
顔面検出および認識は種々の方法で実行することができる。例えば、赤外線カメラ６０４を使用している実施形態においては、顔面の検出および識別を、Francine J. ProkoskiおよびRobert R.Riedelの、「顔および身体の部分の赤外線識別」(Infrared Identification of Faces and Body Parts),IOMETRICS, PersonalIdentification in Networked Society, Kluwer Academic Publishers, 1999に開示されているように実行することができる。好ましい実施形態においては、AndrewSeniorの「顔面認識システムのための顔面および特徴の検出」(Face and feature finding for face recognition system), 2nd Int. Conf.On Audio-Video based Biometric Person Authentication, Washington DC, March 1999の中で記述されている技術が使用されている。次はセグメンテーション・モジュール６２２および認識モジュール６２４によってそれぞれ実行される顔面検出および認識の例示的な説明である。
顔面検出
【０１２４】
顔面は、ビデオ・フレームの中で種々のスケール、場所および向きにおいて発生する可能性がある。このシステムにおいては顔は垂直に近いこと、そして高さが６６ピクセルより小さい顔はないことを仮定する。しかし、すべての残っている場所およびスケールにおいて顔をテストするために、システムは画像ピラミッド内の固定のサイズのテンプレートをサーチする。画像ピラミッドは元の画像を繰返しダウンサンプルして、元のフレームの漸進的により低い分解能の表示を与えることによって構築される。これらの部分画像のそれぞれの内部で、顔面テンプレートと同じサイズのすべての四角形の領域（通常、１１×１１ピクセル）を顔面の場所の候補として考える。領域が顔を含んでいるかどうかをテストするためにテストのシーケンスが使用される。
【０１２５】
最初に、その領域は高い割合の皮膚の色のピクセルを含んでいなければならず、そしてその候補領域の強度が訓練された顔面モデルを比較される。色相−色度−強度空間のあらかじめ定義された立方体の中に落ちるピクセルは皮膚の色であるとみなされ、そして皮膚の色のピクセルの割合がその候補領域に対してさらに考慮されるべきしきい値を超えていなければならない。
【０１２６】
その顔面モデルは切り取られ、正規化されたグレイ・スケールの顔面画像のトレーニング・セットに基づいている。これらの顔面の統計情報が収集され、そして種々の分類器がこれらの統計情報に基づいて訓練される。線形プログラムによって訓練されたフィッシャーの線形弁別(FLD)が顔と背景画像との間の区別をするために見付けられ、M. TurkおよびA. Pentlandの、「認識のための固有顔面」(Eigenfaces for Recognition),Journal of Cognitive Neuro Science, vol.3, no.1, pp 71-86, 1991に記述されているような「顔面空間からの距離」(DFFS)が第1の方法によって高い得点が与えられ、顔面の品質を得点するために使用される。これらの顔面検出器の両方からの組み合わされた高い得点は、その候補領域が実際に顔面であるこを示す。高い得点の顔面候補に対して相対的にスケール、場所および回転の小さな摂動を伴った候補の顔面領域がテストされ、そしてその摂動における最大得点の候補が選定され、これらの3つのハ゜ラメータのリファインされた評価を与える。
【０１２７】
それ以降のフレームにおいて、その顔面が新しい顔面の場所を予測するために速度評価を使用することによって追跡され、そして同様なスケールおよび回転でその予測された場所の近くの候補領域の中で顔面をサーチするためにモデルが使用される。低い得点は追跡の失敗として解釈され、そのアルゴリズムはふたたび網羅的なサーチを開始する。
顔面認識
【０１２８】
顔面が見付けられて、顔面検出のために使用されるのと同じ技術（ＬＦＤおよびＤＦＦＳ）を使用してＫ個の顔面特徴が見付けられる。階層的な方法を使用して特徴が見付けられ、大規模な特徴、例えば、目、鼻および口が先ず見付けられてから、部分的な特徴がこれらの特徴に対して相対的に見付けられる。ヘアライン、顎、耳、および、口、鼻および眉のコーナーなどの２９種類の部分特徴が使用される。顔面および特徴の位置に対して相対的にそれぞれ各特徴および部分特徴に対するサーチ領域を制限するために前の統計情報が使用される。評価された各部分特徴の場所において、L. WiskottおよびC. von derMalsburgの、「動的リンク・マッチングによる顔面の認識」(RecognizingFaces by Dynamic Link Matching), Proceedings of the International Conference onArtificial Neural Networks, pp.347-352, 1995の中で記述されるようなガボール・ジェット表示が生成される。ガボール・ジェットはガウス関数によって各正弦波が変調されている二次元のガボール・フィルタのセットである。各フィルタはスケール（正弦波の波長および固定された比率でのガウスの標準偏差）および向き（正弦波の）を有する。５つのスケールおよび８つの向きを使用し、各特徴の場所において４０個の複素係数（a(j), j=1, ..., 40）を与える。
【０１２９】
訓練された顔面に対する特徴ベクトルとテスト候補との間の距離を計算するために簡単な距離測定法が使用される。特徴ｋに対するｉ番目の訓練された候補とテスト候補との間の距離は次のように定義される。
【数１０】
2004538543.tif 000012
【０１３０】
これらの類似性の簡単な平均値
【数１１】
2004538543.tif 000013
はデータベースの中の顔面テンプレートに対するテスト顔面の類似性に対する総合的な測度を与える。したがって、この類似性の測度に基づいて、考察中のビデオ・シーケンスの中の人の識別および／または検証が行われる。
【０１３１】
次に、顔面認識モジュール６２４およびオーディオ話者認識モジュール６１６の結果がそれぞれの信頼度評価ブロック６２６および６１８に与えられ、信頼度評価が実行される。信頼度評価は認識された入力に関して判定されている尤度または他の信頼測度を指す。ある実施形態においては、信頼度評価手順はオーディオ信号およびビデオ信号にそれぞれ関連する雑音レベルの測定を含むことができる。これらのレベルはシステムに対して相対的に内部的に、あるいは外部的に測定することができる。信号に関連する雑音のレベルが高いことは、その信号に関連する認識結果に対して与えられた信頼が低いことを意味する。したがって、これらの信頼の測度が以下に説明されるビジュアルおよび音響的な結果の重み付けの間に考慮に入れられる。
【０１３２】
それぞれのモジュール６１６および６２４によって与えられたオーディオ・ベースの話者認識および顔面認識の得点が与えられて、オーディオビジュアル話者識別／検証が合同識別／検証モジュール６３０によって次のように行われる。オーディオおよびビデオのベースの識別技術の両方に基づいてトップのＮ個の得点が発生される。この２つのリストが重み付けられた合計によって組み合わされ、最高得点の候補が選定される。重みはスケーリング・ファクタまでだけに定義されてよいので、組み合わされた得点
【数１２】
2004538543.tif 000014
を単独のパラメータαの関数として定義することができる。
【数１３】
2004538543.tif 000015
【０１３３】
混合角αはオーディオ識別および顔面識別の相対的信頼性に従って選択されなければならない。これを実行するための１つの方法は、いくつかのトレーニング・データにおいてオーディオビジュアルの精度を最大にするためにαを最適化する方法である。ｎ番目のトレーニング・クリップにおいて計算されたｉ番目の登録された話者（i=1...P）に対するオーディオＩＤ（識別）およびビデオＩＤの得点としてＤｉ（ｎ）およびＳｉ（ｎ）によって示す。ｎ番目のクリップがｉ番目の話者および別の話者に属している時、変数Ｔｉ（ｎ）をゼロとして定義する。最小化されるコスト関数は、V. N. Vapnikの、「統計的学習理論の性質」（TheNature of Statistical Learning Theory), Springer, 1995に説明されているような実験的誤差であり、それは次のように書くことができる。
【数１４】
2004538543.tif 000016
【０１３４】
ここで
【数１５】
2004538543.tif 000017
【０１３５】
過剰割当てを防止するために、H.Neyの、「神経回路網の分類および弁別トレーニンク゛基準の確率的解釈について」(On the Probabilistic Interpretation of Neural NetworkClassification and Discriminative Training Criteria), IEEE Transactions onPattern Analysis and Machine Intelligence” vol.17, no.2, pp.107-119, 1995に説明されているようなスムース化された誤り率を使用することもできる。それは次のように定義される。
【数１６】
2004538543.tif 000018
【０１３６】
ηが大きい時、内部和の項目が
【数１７】
2004538543.tif 000019
を除いてすべてゼロに近付き、そしてＣ’（α）が生の誤りカウントＣ（α）に近付く。そうでない場合、すべての間違った仮説（Ｔｉ（ｎ）＝１に対するもの）が、それぞれの得点と最高得点との間の距離の減少関数である寄与を有する。最善の仮説が正しくなかった場合、それは最大の寄与を有する。したがって、後者のコスト関数を最小化することによって、トレーニング・データにおける認識の精度だけでなく、最善の得点が得られるマージンも最大化する傾向がある。また、この関数は微分的であることの利点も提供し、それはパラメータが２つ以上ある時のプロセスの最適化を容易化することができる。
【０１３７】
図９のオーディオビジュアル話者認識モジュールは前の技術によって導かれる別の判定または得点融合の技術を提供するが、トレーニングを必要としない。それはテスト時に、各クリップに対して、最高の得点とその次に高い得点との間の差を最大化する所与の範囲におけるαの値を選択することにある。対応している最善の仮説Ｉ（ｎ）が次に選定される。次のようになる。
【数１８】
2004538543.tif 000020
および
【数１９】
2004538543.tif 000021
【０１３８】
α１およびα２の値はインターバル
【数２０】
2004538543.tif 000022
に限定される。この技術の理論的説明は以下の通りである。｛Ｄｉ，Ｓｉ｝平面において、正しい判定に対して対応している点は、他の点から離れた所にあると思われる。固定された線形の重みは、他の点に対して相対的にこの点が見付けられる「方向」が常に同じであることを仮定するが、それは必ずしも成立しない。上記
【数２１】
2004538543.tif 000023
およびＩ（ｎ）に関連している式はα１とα２との間の任意の方向において他の点から最も離れている点を見付ける。
【０１３９】
もう１つの解釈は、最善の組み合わされた得点と第２の最善の得点との間の距離が、その判定の信頼度を示すということである。この方法はその信頼測度を最大化する重みを適応的に選定する。
【０１４０】
したがって、合同識別／検証モジュール６３０は話者に関して判定を行う。検証のシナリオにおいて、上記の技術の１つに基づいて、話者が音響的経路およびビジュアル経路の両方を経由して検証される場合、その話者を受け入れるための判定を行うことができる。しかし、その話者が経路の１つだけによって検証された場合は、その話者はリジェクトされる。識別のシナリオにおいて、例えば、顔面識別プロセスからのトップの３つの得点を音響的話者識別プロセスからのトップの３つの得点と組み合わせることができる。次に、最高の組み合わされた得点が話者として識別される。
【０１４１】
好ましい実施形態においては、モジュールが話者に関して最終の判定を行う前に、システムは発声検証動作を実行する。発声検証は音響特徴抽出器６１４およびビジュアル音声特性抽出器６２２からの入力に基づいて発声検証モジュール６２８（図９）によって実行されることを理解されたい。発声検証について説明する前に、ビジュアル音声特性ベクトルを抽出するための例示的な技術が以下に説明される。特に、ビジュアル音声特性抽出器６２２は、文字Ｖとして図９の中で示されているビジュアル音声特性ベクトル（例えば口または唇関連のパラメータ）を、アクティブ話者顔面セグメンテーション・モジュール６２０によってビデオ・フレームの中で検出された顔面から抽出する。
【０１４２】
抽出することができるビジュアル音声特性の例は、口の領域のグレイ・スケール・パラメータ；口の領域の面積、高さ、幅などのパラメータに基づいた幾何学的／モデル；曲線当てはめ、内側／外側の輪郭のスプライン・パラメータによって得られた唇の輪郭；および三次元的追跡によって得られる動きのパラメータである。モジュール６２２を経由して抽出することができるさらにもう１つの特徴セットは、上記のファクタを考慮に入れる。そのような技術は「アクティブ形状モデリング」として知られ、Iain Mathewsの博士論文、「オーディオビジュアル音声認識のための特徴」（Features for audio visual speech recognition）, School of Information Systems, Universityof East Angalia,January 1998に記述されている。
【０１４３】
したがって、ビジュアル音声特性抽出器６２２は、１つまたはそれ以上の既知のビジュアル抽出技術を実施することができるが、ある実施形態においては、その抽出器は画像の口の領域に関連するグレイ・スケールのパラメータを抽出する。唇のコーナーの場所が与えられて、スケールおよび回転の正規化の後、その四角形の中心にある唇の領域を含む四角形の領域が元の解凍されたビデオ・フレームから抽出される。周知のように、主成分分析（ＰＣＡ）を使用してこのグレイ・スケール値のベクトルからより小さい次元のベクトルを抽出することができる。
【０１４４】
モジュール６２２の中に実施することができるビジュアル特徴ベクトルを抽出するもう１つの方法は、幾何学的特徴の抽出を含むことができる。これは唇の輪郭の幾何学的形状およびその時間的ダイナミクスから音素／ビジュアル音素情報を抽出することを必要とする。代表的なパラメータは口のコーナー、開口部の高さまたは面積、内側および外側の唇の曲率があり得る。調音器官、例えば、歯および舌の位置も、それらがカメラによって見分けが付く範囲で特徴パラメータとなり得る。
【０１４５】
グレイ・スケール値からこれらのパラメータを抽出する方法は、パラメータ値に関連する唇の輪郭とグレイ・スケール画像との間のミスマッチを記述する関数（例えば、コスト関数）の最小化を含むことができる。これらのパラメータの抽出において、カラー情報も同様に利用することができる。
【０１４６】
捕捉された（またはデマルチプレックスされて解凍された）ビデオ・ストリームから、境界検出を実行し、その究極の結果がパラメータ化された輪郭、例えば、円、放物線、楕円または、より一般的には、スプライン輪郭であり、それらのそれぞれを有限のパラメータの組によって記述することができる。
【０１４７】
抽出することができるさらに他の特徴は、アニメーションの目的のためにコンピュータ・グラフィクスにおいて使用されるタイプの二次元または三次元のワイヤーフレーム・モデル・ベースの技術を含む。ワイヤーフレームは多数の三角形パッチから構成することができる。これらのパッチが一緒になって口／唇／顎の領域の構造的表現を与え、そのそれぞれが読唇における有用な特徴を含んでいる。また、これらのパラメータを画像のグレイ・スケール値と組み合わせて使用して両方の方式の相対的利点を得ることができる。
【０１４８】
抽出器６２２からの抽出されたビジュアル音声特性ベクトル（Ｖ）と、抽出器６１４からの音響特性ベクトル（Ａ）とが与えられて、ＡＶ発声検証器６２８が検証を実行する。検証は結果の尤度、例えば、ビジュアル音素のランダム・シーケンスにおけるオーディオのアラインメントの比較を含むことができる。周知のように、ビジュアル音素、すなわち、ビジュアル音素は音響的音素と同様に分類されてあらかじめ記憶されている音声発声を伴う一般的に標準形の口の形状である。発声検証に関連付けられている目標はオーディオ経路Ｉにおいて話者を検証するために使用される音声および、ビデオ経路ＩＩにおいて話者を検証するために使用されるビジュアルな手掛かりが相互に関係すること、あるいは正しい位置関係にあることを判定することである。これによってシステムはその話者を認識するために使用されつつある音声データが実際にその話者が発声したものであることを信頼することができる。そのような判定には多くの利点がある。例えば、発声検証から、そのユーザがシステムをだまそうとしてあらかじめ録音されたテープ再生に対して唇を合わせているかどうかを判定することができる。また、発声検証から、オーディオ・デコーディング経路における誤りを検出することができる。誤りの数により、信頼の測度を発生させてシステムによって使用することができる。
【０１４９】
ここで図１０について説明すると、この図は、発声検証の方法の流れ図を示す。発声検証は、（ｉ）ス−パバイザモード、すなわち、テキスト（スクリプト）が知られていて、システムに対して利用できる時、または（ｉｉ）非ス−パバイザモード、すなわち、テキスト（スクリプト）が分かっておらず、システムに対して利用できる時において実行することができる。
【０１５０】
したがって、ステップ７０２Ａ（非ス−パバイザモード）において、検証される発声された音声を古典的な音声認識技術によって復号し、その復号されたスクリプトおよび関連する時間的位置合わせが得られるようにすることができる。これは音響特性抽出器６１４からの特徴データを使用して実現される。同時に、ステップ７０４において、ビジュアル特徴抽出器６２２からのビジュアル音声特性ベクトルがビジュアル音素またはビジュアル音素シーケンスを作り出すために使用される。
【０１５１】
次に、ステップ７０６において、そのスクリプトがビジュアル音素と位置合わせされる。２つの情報ストリームを同期化させるために従来の方法で迅速（または他の）アラインメントを実行することができる。例えば、ある実施形態においては、迅速アラインメントを使用することができる。ス−パバイザモードにおいては、ステップ７０２Ｂがステップ７０２Ａを置き換え、復号されたバージョンのスクリプトではなく、期待されるスクリプトまたは分かっているスクリプトがステップ７０６においてビジュアル音素と整列されるようになっていることに留意されたい。次に、ステップ７０８において、その整列における尤度が計算されてそのスクリプトがビジュアル・データに対してどの程度良く合っているかが判定される。次に、その尤度の結果が判定ブロック６３２に与えられ、判定ブロック６３２は得点モジュール６３０の結果に沿って、その話者の最終配置、例えば、その話者を受け入れるかリジェクトするかを決定する。これを使用して種々の装置、アプリケーション、ファシリティなどに対するアクセスを許可するか拒否することができる。
【０１５２】
したがって、非ス−パバイザ発声検証モードにおいては、システムはユーザが再生装置を使用しながら自分の唇を動かしているのではなく、実際に話していることをチエックすることができる。また、先験的に、オーディオのデコーディングにおいて誤りが検出されることがある。ス−パバイザモードにおいては、システムは認識されたテキストが抽出された唇のパラメータに対して合っているか、あるいは十分に合っているかあるいは相互に関連付けられている場合に、そのユーザがそのテキストを発声したことを証明することができる。
【０１５３】
ス−パバイザモードにおける発声検証を使用して音声検出を実行することができることを理解されたい。実際に、音響アクティビティおよびビジュアル・アクティビティが検出された場合、それらを互いに対して検証することができる。結果の音響的発声が受け入れられる時、システムはその音声が検出されていると考える。そうでない場合、余分のアクティビティが存在するとみなされる。
【０１５４】
図９のオーディオビジュアル話者認識モジュールは、オーディオビジュアル話者認識の代替実施形態を使用することができることを理解されたい。例えば、図９の実施形態は判定または得点の融合の方法を示すが、モジュール２０は特徴融合法および／またはシリアル再得点法を使用することができる。
【０１５５】
さらに、図９のオーディオビジュアル話者認識システムの出力が上記のように、ユーザの意図を明確化するために使用するための図１のダイアログ・マネージャ１８に提供されることも理解されたい。
Ｃ．会話型仮想マシン
【０１５６】
ここで図１１および図１２について説明すると、この図は、会話型仮想マシン（ＣＶＭ）の好ましい実施形態のブロック図を示す。本発明の多モード会話型コンピューティング・システムの好ましい実施形態において使用するためのそのようなマシンの実施形態の１つの説明が、このセクションにおいて以下に提供される。しかし、本発明による会話型コンピューティングを実施するための他のメカニズムも以下に説明されるように使用できることを理解されたい。
【０１５７】
以下に説明されるＣＶＭは、図１のＩ／Ｏサブシステム１２；Ｉ／Ｏマネージャ１４；認識エンジン１６；ダイアログ・マネージャ１８およびコンテキスト・スタック２０の部分に対するフレームワークを提供するために使用することができる。以下のＣＶＭの説明全体を通して、図１のこれらの機能的構成要素を実施するために使用することができるＣＶＭの構成要素が注記される。しかし、ＣＶＭはＩ／Ｏマネージャ、モード独立のコンテキストのマネージャ（コンテキスト・スタック）、ダイアログ・マネージャ（明確化が実行される時）、分類器（ムードまたはフォーカスが判定される時）、必要なエンジンおよび、アプリケーションを実行するためのダイアログ・マネージャに対するＡＰＩ／インタフェースを実行するための機能があるので使用することができるが、本発明の多モード会話型コンピューティング・システムのこれらの機能構成要素を実施するために他のメカニズムを代わりに使用することができることに留意することが重要である。例えば、本発明の多モード会話型コンピューティング・システムの機能的構成要素は、これらの機能を実行するブラウザ、ＯＳＳ（オペレーティング・システム・サービス）層、ＶＭ（仮想マシン）またはこれらの機能をすべて実施する単なるアプリケーションでも、おそらくこれらの構成要素を明示的に識別せずに、むしろハード符号化された等価的なサービスを実施することによって実施することができる。また、その実施は音声およびビデオのモードだけをサポートすることができ、そしてそのような場合、他のモード（例えば、手書き、ＧＵＩ）などをサポートする必要はないことも理解されたい。
【０１５８】
したがって、ＣＶＭは本発明に関して上で記述された会話型コンピューティングのパラダイムに従って会話型コンピューティングを実施するためのメインの構成要素として使用することができる。ある実施形態においては、ＣＶＭは対話型のＯＳ（オペレーティング・システム）またはＲＴＯＳ（リアルタイム・オペレーティング・システム）のトップで実行されている対話型のプラットホームまたはカーネルである。また、ＣＶＭプラットホームはサーバ以外にＰｖＣ（浸透的コンピューティング）（pervasive computing）のクライアントによって実施することもでき、そして複数のシステム（クライアントおよびサーバ）にわたって分散させることもできる。一般に、ＣＶＭは会話型のサブシステム（例えば、音声認識エンジン、テキストから音声への変換など）と、会話型のおよび／または従来のアプリケーションとの間の会話型ＡＰＩ（アプリケーション・プログラミング・インタフェース）およびプロトコルを提供する。ＣＶＭはより制限されたインタフェースによって、既存のアプリケーションに対する逆方向の互換性も提供することができる。以下に詳細に説明されるように、ＣＶＭは同様にＣＶＭ層を装備しているか、あるいは少なくとも会話的に意識している（conversationally aware）複数のアプリケーションおよび装置と対話するための会話型プロトコル以外に、会話型のサービスおよび挙動を提供する。
【０１５９】
ここで説明されている種々の要素およびプロトコル／ＡＰＩは、それらが実行する機能または、それらが交換する情報のベースで定義されていることを理解されたい。それらの実際の編成または実施は変わる可能性がある。例えば、同じエンティティまたは異なるエンティティによって実施されるか、より大きい構成要素の１つの構成要素として、あるいは１つの独立にインスタンシエートされたオブジェクトとして、あるいはそのようなオブジェクトまたはクラスのファミリとして実施される。
【０１６０】
会話型コンピューティングに基づいたＣＶＭ（またはオペレーティング・システム）、ここで記述されているパラダイムによって、コンピュータまたは任意の他の対話型の装置がユーザと会話することができる。さらに、ＣＶＭによって、ユーザが、そのマシンがディスプレイまたはＧＵＩの機能を備えていないか、あるいはキーボード、ペンまたはポインティング装置をいずれも備えていないかどうかにかかわらず、マシン上で複数のタスクを実行することができる。実際に、ユーザはこれらのタスクを会話と同様に管理することができ、１つのタスクまたは複数の同時タスクを終わらせることができる。会話のようなタスクを管理するために、ＣＶＭはその種々の機能を実行するために混合されたイニシアティブ、コンテキストおよび先進のレベルの抽象化に依存する機能を提供する。混合型のイニシアティブまたは自由フロー・ナビゲーションによって、ユーザはシステムとのダイアログを経由して要求を自然に完了し、修正し、あるいは訂正することができる。また、混合型のイニシアティブはＣＶＭが特に音声イネーブル型のアプリケーションにおいて、タスクを通してユーザを積極的に助け（助けるためのイニシアティブを取り）、コーチすることができることを意味し、混合型のイニシアティブの機能はディスプレイのないシステムまたはディスプレイ機能を限定されるシステムに対して補正する自然の方法である。一般に、ＣＶＭは会話型のインタフェースおよびユーザの入力／を出力を置き換えるのではなく、それらを補完する。これが「多モード性」（multi-modality）の概念であり、それによって上記のように音声およびビデオをマウス、キーボード、およびペンなどの他の入力装置と並行して使用することができる。装置の制限によってある種のインタフェースの実施が制約される時、会話型のインタフェースを置き換えることができる。さらに、装置間の結果のインタフェースの偏在性および一様性、階層およびサービスが追加的な必須の特性である。ＣＶＭシステムは多くの範囲に対して、従来の入力および／または出力メディアで機能することができることを理解されたい。実際に、従来のモニタ・ディスプレイと結合された古典的なキーボード入力およびポインティング装置を備えたコンピュータがＣＶＭを利用することによって大幅に進歩する可能性がある。ＧＵＩのモードと音声モードとの間に緊密な同期がある真の複数モデル・アプリケーションを構築することでそれぞれのコンピュータに対して話したくないユーザでさえ、ＣＶＭイネーブル型のマシンとのそれぞれの対話に対する劇的な積極的変化を実感することもできる。
【０１６１】
ここで図１１について説明すると、この図は、好ましい実施形態によるクライアント装置またはサーバ上で実施することができるＣＶＭシステムを示すブロック図を示す。上記の乗り物の例に関して、これはシステム１０の構成要素をローカルに（その乗り物の中で）、リモートに（例えば、無線でその乗り物に接続された状態で）、またはいくつかのそれらの組合せで配置することができることを意味する。一般に、ＣＶＭは汎用の調停された多モード会話型ユーザ・インタフェース（ＣＵＩ）７８０を提供する。ＣＵＩの「多モード性」の態様は、種々のＩ／Ｏ資源、例えば、音声、キーボード、ペンおよびポインティング装置（マウス）、キーパッド、タッチ・スクリーンなど、および上記のビデオをＣＶＭプラットホームと結合して使用することができることを意味する。ＣＵＩの「汎用性」の態様は、ＣＶＭがデスクトップ・コンピュータと結合して実施されているか、制限されたディスプレイ機能のＰＤＡと接続されているか、あるいはディスプレイが提供されていない電話機と接続されているかどうかにはかかわらず、ユーザに同じＵＩ（ユーザ・インタフェース）を提供することを意味する。言い換えれば、汎用性はそのＣＶＭシステムが音声のみから、多モードの、すなわち、音声＋ＧＵＩ、純粋なＧＵＩに至るまでの範囲の機能を有する装置のＵＩを適切に扱うことができることを意味する。本発明により、ビデオ入力データを同様に含めるようにシステムを拡張することができる。したがって、汎用ＣＵＩはアクセス・モードの如何にかかわらず、すべてのユーザ相互作用に対して同じＵＩを提供する。
【０１６２】
さらに、汎用ＣＵＩの概念はコーディネートされたＣＵＩの概念まで拡張される。特に、複数の装置（複数のコンピュータの階層または内部、またはそれらにまたがっての）が同じＣＵＩを提供すると仮定して、それらを単独の対話、すなわち、コーディネートされたインタフェースを通して管理することができる。すなわち、複数の装置が会話できるように接続されている（すなわち、お互いに知っている）時、１つのインタフェース（例えば、１つのマイクロホン）を通してそれらを同時に制御することができる。例えば、汎用のコーディネートされたＣＵＩ、スマート・ホーン、ページャ、ＰＤＡ（個人用ディジタル・アシスタント）、ネットワーク型コンピュータ、ＩＶＲ（対話型音声応答）、対話できるように接続されている車に埋め込まれたコンピュータを経由して音声が自動的に制御することができる。これらのＣＵＩの概念が以下に詳細に説明される。
【０１６３】
ＣＶＭシステムは会話的に意識しているアプリケーション７８２（すなわち、会話型プロトコルを「話す」アプリケーション）および会話型アプリケーション７８４を含むアプリケーションを実行することができる。会話的に意識しているアプリケーション７８２は、会話型のアプリケーションＡＰＵＩ７８６を経由してＣＶＭのコア層（すなわち、カーネル）７８８と一緒に動作するように特別にプログラムされているアプリケーションである。一般に、ＣＶＭのカーネル７８８は、アプリケーションと装置にまたがるダイアログをそれぞれの登録された会話的機能および要件のベースで制御し、Ｉ／Ｏモードとして音声を追加するよりはるかに進んでいる統一された会話型のユーザ・インタフェースを提供し、会話型のシステム挙動を提供する。ＣＶＭシステムを従来のＯＳおよびＡＰＩ７９０および従来の装置ハードウェア７９２のトップに構築し、サーバまたは任意のクライアント装置（ＰＣ、ＰＤＡ、ＰｖＣ）の上に置くことができる。従来のアプリケーション７８４は、ＣＶＭのカーネル層７８８によって管理され、カーネル層７８８はＯＳ、ＡＰＩ、ＧＵＩメニューおよび基本となるＯＳのコマンド以外に従来のアプリケーションのコマンドにアクセスすることを担当する。ＣＶＭは対話型のサブシステム７９６（すなわち、会話型のエンジン）および従来のＯＳ  ７９０の従来のサブシステム（例えば、ファイル・システムおよび従来のドライバ）を含むすべての入出力の問題を自動的に扱う。一般に、会話型のサブシステム７９６は音声の要求を質問に変換し、出力および結果を話されたメッセージに適切なデータ・ファイル７９４（例えば、コンテキスト、有限状態の文法、語彙、言語モデル、シンボリックな質問マップなど）を使用して変換することを担当する。会話型アプリケーションＡＰＩ７８６は質問をアプリケーションの呼出しに変換し、出力をユーザに提供する前に適切に記憶されている音声に逆に変換するために、ＣＶＭ７８８にすべての情報を伝える。
【０１６４】
ここで図１２について説明すると、この図は、好ましい実施形態によるＣＶＭの抽象的プログラミング層を示す。ＣＶＭの抽象層はＣＶＭのトップにおいて実行することができる会話的に意識しているアプリケーション８００および従来のアプリケーション８０１を含む。多モードの明確化に頼る１つのアプリケーションは、ＣＶＭのトップで実行するそのような会話型アプリケーションの一例である。同様に、フォーカス情報またはムードを利用するアプリケーションをＣＶＭのトップにおける会話型アプリケーションとみなすことができる。これらのアプリケーションはシステムによって実行され、そのシステムが配備されている環境においてユーザが望む対話をユーザに提供する。上記のように、会話的に意識しているアプリケーション８００は、従来のアプリケーションＡＰＩ層８０３を経由してＣＶＭのカーネル層８０２と対話する。対話型のアプリケーションＡＰＩ層８０３は、会話型のプログラミング言語／スクリプトおよびライブラリ（会話型の基礎クラス）を包含してＣＶＭカーネル８０２によって提供される種々の特徴を提供する。例えば、会話型のプログラミング言語／スクリプトはアプリケーションの開発者が会話的に意識しているアプリケーション８００をフックする（あるいは開発する）ことができる会話型のＡＰＩを提供する。また、それらは会話型のＡＰＩ層８０３、会話型のプロトコル８０４および開発者がアプリケーションの中に会話的機能を組み込み、それを「会話的に意識している」ようにさせることができるシステム・コールをも提供する。そのアプリケーションを実施しているコード、ＡＰＩコールおよびプロトコル・コールは解釈されてコンパイルされたスクリプトおよびプログラムを、ライブラリ・リンク、会話型ロジック・エンジン・コールおよび会話型の基礎クラスと一緒に含む。
【０１６５】
より詳細には、会話型のアプリケーションＡＰＩ層８０３は複数の会話型基礎クラス８０５（または基礎ダイアログ構成要素）を含み、それらはＣＵＩまたは会話的に意識しているアプリケーション８００を構築するために使用することができるライブラリ関数を通してアプリケーション開発者に提供される。会話型基礎クラス８０５は、モードまたはモードの組合せ（手続き的または宣言的に実施することができる）とは独立に、任意のダイアログを特性付ける初歩的構成要素または会話的ジェスチャ（T. V. Ramanの、「話すコンピュータに向けての、音声のユーザ・インタフェース」（Auditory User Interfaces, Toward The Speaking Computer）, (Kluwer Academic Publishers, Boston 1997に記述されている）である。会話型基礎クラス８０５はＣＵＩのビルディングブロックおよび会話型プラットホーム・ライブラリと、ダイアログ・モジュールおよび構成要素と、ダイアログ・スクリプトおよびビーンズ（beans）とを含む。会話型基礎クラス８０５はローカルに会話型のオブジェクト８０６にコンパイルすることができる。より詳細には、会話型のオブジェクト８０５（またはダイアログ構成要素）はＪａｖａまたはＣ＋＋などのプログラミング言語などを通じて、これらのライブラリを呼び出すコードの中の異なる個々のクラスを組み合わせることによって、会話型基礎クラス８０５（基本的ダイアログ構成要素）からコンパイルされる。
【０１６６】
上で注記されたように、コーディングはそのような基本的ダイアログ構成要素を宣言的コードに埋め込むか、あるいはそれらを命令的なコードにリンクすることを含む。会話型基礎クラス８０５のネスティングおよび埋込みによって、会話型オブジェクト８０６（再使用可能であるか、そうでないかのいずれも）が特定のダイアログ・タスクまたはアプリケーションを実行するために構築される（宣言的に、あるいはコンピレーション／インタプリテーション経由のいずれかで）ようにすることができる。ＣＦＣ（会話型基礎クラス）またはＣＭＬはＣＶＭをプログラムするための唯一の方法ではない。アプリケーションＡＰＩおよびプロトコルに対してインタフェースする任意のプログラミング言語が適合する。会話型のオブジェクト８０６は、会話型ブラウザまたはビューワ８００ａによって処理またはロードされるＣＭＬ（会話型マークアップ言語）のページ（ネストされているかされていないか）などとして宣言的に実施することができる。ダイアログ・オブジェクトはＣＭＬ（会話型マークアップ言語）のページを通じて（会話型ブラウザを経由して）ロードすることができるアプレットまたはオブジェクト、ＣＶＭのトップにある（おそらくＣＶＭのトップに分配されている）命令的オブジェクト、ＣＭＬの中のスクリプト・タグおよびサーブレット（servlet）構成要素を含む。
【０１６７】
実施することができる会話的ジェスチャのいくつかの例が以下に示される。会話的ジェスチャ・メッセージは情報メッセージをユーザに伝えるためにマシンによって使用される。ジェスチャ・メッセージは表示された文字列または話されたプロンプトとして通常与えられる。話されるメッセージの部分はＣＶＭのトップにおいて実行している種々のアプリケーション／ダイアログの現在の状態の関数である可能性がある。ユーザが一組の個々の選択のセットから拾うことが期待されるダイアログをカプセル化するために、会話的ジェスチャ「セットから選択する」（select from set）が使用される。それは合法的な選択項目のセット以外に、プロンプト、デフォールトの選択をカプセル化する。対話型のジェスチャ・メッセージ「範囲から選択する」（select from range）は値の連続した範囲から１つの値をユーザが拾うことができるようなダイアログをカプセル化する。そのジェスチャは有効な範囲、現在の選択、および情報的プロンプトをカプセル化する。さらに、入力の制約がより複雑である時（あるいはおそらく存在していない時）、ユーザ入力を得るために会話的ジェスチャ入力が使用される。ジェスチャはユーザのプロンプト、要求されつつある情報のアイテムに関するアプリケーション・レベルのセマンティクス、および、おそらくはその入力の有効性をテストするための述語をカプセル化する。しかし、上記のように、会話型基礎クラスは会話的ジェスチャの概念を含み、しかもその限界を超える（すなわち、それらは会話型のタスクを実行するための規則以外に、基本的な挙動およびサービスのレベルにまで拡張する）。
【０１６８】
以下に説明されるように、プログラミング・モデルによってマスタ・ダイアログ・マネージャとエンジンとの間の会話型ＡＰＩを通してのコネクションが可能になる。そのようなマスタ・ダイアログ・マネージャを図１のダイアログ・マネージャ１８の一部として実施することができ、一方、エンジンは図１の１つまたはそれ以上の認識エンジンを含むことになることを理解されたい。任意の認識エンジンによって必要とされるデータ（例えば、文法、音響的モデル、ビデオ・パターンなど）以外に、基礎クラスのデータ・ファイルがＣＶＭ上に提供される（組込み型のプラットホームまたはクライアントのプラットホームにロード可能である）。オブジェクトのデータ・ファイルを拡張してロードすることができる。
【０１６９】
ＣＶＭによって提供される開発環境はここではＳＰＯＫＥＮ  ＡＧＥ（商標）と呼ばれる。Spoken Ageによって、開発者はＣＶＭに対する会話的に意識しているアプリケーションを作成し、シミュレートし、デバッグすることができる。ＡＰＩコールの直接実施を提供する他に、それは複数のパーソナリティとの先進の会話型インタフェースを作るためのツール、ユーザが出力を提供する音声のタイプを選択することができる音声フォント、およびポストスクリプトおよびＡＦＬ（オーディオ・フォーマッティング言語）などの会話型のプレゼンテーションを作る会話型のフォーマッティング言語も提供する。
【０１７０】
上記のように、会話型のアプリケーションＡＰＩ層８０３は、会話型のプログラミング言語および汎用の会話型の入力および出力、会話型ロジックおよび会話型のメディア情報交換プロトコルを提供するためのスクリプトを包含する。会話型のプログラミング言語／スクリプトによって、入力または出力のストリームとして任意の利用可能な資源を使用することができる。会話型のエンジン８０８（図１の認識エンジン１６）および会話型のデータ・ファイル８０９（会話型エンジンＡＰＩ８０７を経由してＣＶＭ８０２によってアクセスされる）を使用して、各入力がバイナリおよびＡＳＣＩＩ入力に変換され、それを組込みオブジェクトとしてプログラミング言語によって直接処理することができる。種々のオブジェクトと正しくインタフェースするために必要な会話型のメタ情報をオブジェクトとプロセスとの間で送信するために、コール、フラグおよびタグを自動的に含むことができる。さらに、アプリケーションまたはユーザのニーズに従って、出力ストリームを特別にフォーマット化することができる。これらのプログラミング・ツールによって多モード対話処理を容易に構築することができる。さらに、会話型クエリーの豊富さを処理するために、論理ステートメントのステータスおよび演算子が拡張される。その豊富さは、それぞれのＡＳＣＩＩ／バイナリの内容のベースで、あるいはそれらのＮＬＵ変換された（自然言語理解変換型）のクエリー（従来のおよび会話型のサブシステムの入出力）、あるいはＦＳＧベースのクエリー（システムが制限されたコマンドを使用した場合）のベースで比較することができる。そのようなシステムをテストまたは変更するために論理演算子を実施することができる。会話型論理値／演算子は、真、偽、不完全、曖昧、ＡＳＣＩＩの観点のための相違／等価、ＮＬＵの観点からの相違／等価、アクティブ・クエリー・フィールドの観点からの相違／等価、未知、矛盾、比較不能を含むように拡張する。
【０１７１】
さらに、会話型アプリケーションのＡＰＩ層８０３は、基本となるＯＳの特徴および挙動の拡張を提供するためのコードを備える。そのような拡張は、例えば、高いレベルの抽象化および任意のオブジェクトに関連する抽象カテゴリー、抽象カテゴリーの自己登録メカニズム、記憶、集計、会話型のサーチ、選択、リダイレクション、ユーザのカスタマイゼーション、訓練機能、ヘルプ、複数ユーザおよびセキュリティ機能を、基本クラス・ライブラリ以外に含む。
【０１７２】
図１２の会話型コンピューティング・システムは会話型エンジンのＡＰＩ層８０７をさらに含み、それはコア・エンジンの会話型エンジン８０８（例えば、音声認識、話者認識、ＮＬパーシング、ＮＬＵ、ＴＴＳおよび音声圧縮／解凍エンジン、ビジュアル認識）とそれらを使用しているアプリケーションとの間のインタフェースを提供する。また、エンジンのＡＰＩ層８０７はコア・エンジンとそれらがローカルであるかリモートであるかにかかわらず通信するためのプロトコルも提供する。Ｉ／ＯのＡＰＩ層８１０はキーボード、マウス、タッチ・スクリーン、キーパッドなど（多モード会話型ＵＩを提供するための）、音声Ｉ／Ｏ（オーディオ入力／オーディオ出力）を捕捉するためのオーディオ・サブシステム、およびビデオＩ／Ｏを捕捉するためのビデオ・サブシステムを提供する。Ｉ／ＯのＡＰＩ層８１０は装置の抽象化、Ｉ／Ｏの抽象化およびＵＩの抽象化を提供する。Ｉ／Ｏリソース８１１はＩ／ＯのＡＰＩ層８１０を経由してＣＶＭカーネル層８０２に登録する。Ｉ／ＯのＡＰＩ８１０は図１のＩ／Ｏマネージャ１４の一部として実施することができ、Ｉ／Ｏのリソース８１１は図１のＩ／Ｏサブシステム１２の一部として実施できることを理解されたい。
【０１７３】
コアＣＶＭカーネル層８０２は会話型アプリケーションおよび挙動／サービス・マネージャ層８１５、会話型ダイアログ・マネージャ（アービトレータ）層８１９、会話型リソース・マネージャ層８２０、タスク／ディスパッチャ・マネージャ８２１およびメタ情報マネージャ８２２などのプログラミング層を含み、それらはＣＶＭ層８０２のコア機能を提供する。これらの構成要素は図１のダイアログ・マネージャ１８の一部として実施できることを理解されたい。会話型アプリケーションおよび挙動／サービス・マネージャ層８１５は、従来のアプリケーションおよび会話的に意識しているアプリケーション８００および８０１を管理するための機能を含む。そのような管理機能は、例えば、どのアプリケーションが登録されているか（ローカルおよびネットワーク分散の両方）、そのアプリケーションのダイアログ・インタフェース（もしあれば）がどれであるか、および各アプリケーションの状態が何であるかを追跡管理することを含む。さらに、会話型アプリケーションおよびサービス／挙動マネージャ８１５は、ＣＶＭシステムによって提供される特定のサービスまたは挙動に関連するすべてのタスクを起動する。会話型のサービスおよび挙動はアプリケーションの開発者がＡＰＩを経由してアクセスできると期待することができる（そのアプリケーションの開発によって実施する必要なしに）特徴以外に、そのアプリケーションおよび対話において見付けることをユーザが期待することができる会話型ＵＩのすべての挙動および特徴である。ＣＶＭカーネル８０２によって提供される会話型のサービスおよび挙動の例としては、会話型分類およびメタ情報、会話型オブジェクト、リソースおよびファイル管理、会話型サーチ、会話型選択、会話型カスタマイゼーション、会話型セキュリティ、会話型ヘルプ、会話型優先順位付け、会話型リソース管理、出力のフォーマッティングおよびプレゼンテーション、集計、会話型の遅延されたアクション／エージェント／記憶、会話型論理およびコーディネートされたインタフェースおよび装置などがあるが、これらに限定されるわけではない。そのようなサービスは会話型アプリケーションＡＰＩ層８０３を経由してＡＰＩコールを通して提供される。会話型のアプリケーションおよび挙動／サービス・マネージャ８１５は、その装置、アプリケーションおよび／またはユーザの好みの機能および制約に対してＵＩを適合させるために必要なすべての異なる機能を実行することを担当する。
【０１７４】
会話型ダイアログ・マネージャ８１９は、ダイアログ（音声および他の多モードＩ／Ｏ、例えば、ＧＵＩキーボード、ポインタ、マウスなどをビデオ入力以外に含む会話型ダイアログ）およびアービトレーション（ダイアログ・マネージャ・アービトレータまたはＤＭＡ）を、登録されたすべてのアプリケーションにわたって管理するための機能を含む。特に、会話型ダイアログ・マネージャ８１９はどの情報をユーザが有しているか、どの入力をユーザが示すか、そしてどのアプリケーションがユーザの入力を処理するかを決定する。ＤＭＡはユーザの意図を理解するためにコンテキスト／履歴を使用して、抽象化されたＩ／Ｏイベント（Ｉ／Ｏマネージャによって抽象化された）を処理する。抽象イベントが発生すると、ＤＭＡはそのイベントのターゲットを判定し、必要な場合、確認、明確化、訂正、より詳細などを、その意図が曖昧であって完全に判定されるまで求める。次にＤＭＡはそのユーザのクエリーに関連するアクションを立ち上げる。ＤＭＡの機能は多モードＩ／Ｏイベントを処理して：（１）ターゲットのアプリケーションまたはダイアログ（またはその一部分）を決定し、（２）過去の履歴およびコンテキストを使用して：（ａ）そのユーザの意図を理解し、（ｂ）明確化し、その理解を完了し、訂正または確認するためにダイアログでフローアップし、（ｃ）または、そのユーザの意図を完全に理解したことからの結果としてのタスクをディスパッチする。
【０１７５】
会話型リソース・マネージャ８２０は、どの会話型エンジン８０８が登録されているか（ローカルの会話型リソース８０８および／またはネットワーク分散型リソースのいずれか）、登録された各リソースの機能、および登録された各リソースの状態を判定する。さらに、会話型リソース・マネージャ８２０はＣＰＵサイクルまたは入出力の優先順位の割当てを行ってアクティブのアプリケーションによって流れているダイアログを維持する（例えば、現在の入力または出力を認識または処理するために働いているエンジンは優先順位を有する）。同様に、分散型のアプリケーションの場合、アクティブなフォアグラウンド・プロセスに対するネットワーク遅延を最小化するために、そのエンジンおよび使用されるネットワーク経路のルートを決めて選択する。
【０１７６】
タスク・ディスパッチャ／マネージャ８２１はローカルおよびネットワーク型の従来のリソースおよび会話型リソースについて発生される種々のタスクおよびプロセス（ユーザおよびマシンによって）をディスパッチし、調整する。メタ情報マネージャ８２２はメタ情報リポジトリ８１８を経由してシステムに関連するメタ情報を管理する。メタ情報マネージャ８２２およびリポジトリ８１８は、会話型の対話において通常周知であると仮定されるが現在の会話型のレベルにおいては利用できないすべての情報を収集する。その例は、先験的知識、文化的、教育的仮定および永続性の情報、過去の要求、参照、ユーザに関する情報、アプリケーション、ニュースなどである。それは通常は会話型履歴／コンテキストの長さ／寿命を超えて保存され、永続性である必要がある情報および、その会話のための共通の知識であると思われ、したがって、現在の、および可能な過去の会話型の対話の間には決して定義されていない情報である。また、コマンド、リソースおよびマクロなどに対するショートカットはメタ情報マネージャ８２２によって管理され、メタ情報リポジトリ８１８に記憶される。さらに、メタ情報リポジトリ８１８はユーザのアイデンティティに基づいたユーザの使用ログを含む。ＣＶＭシステムによって提供されるいくつかのダイアログ・プロンプト（紹介、質問、フィードバックなど）以外に、会話型ヘルプおよび支援などのサービスを、メタ情報リポジトリ８１８に記憶され、そのアプリケーションに関連付けられているユーザの使用履歴に基づいて仕立て上げることができる。ユーザが所与のアプリケーションと以前に対話していた場合、それがそのユーザにとってよく知られていると仮定して説明を削減することができる。同様に、ユーザが多くの誤りを起こす場合、その説明はより複雑になる可能性がある。何故なら、複数の誤りはそのアプリケーションまたは機能についてのユーザの不確かさ、不慣れ、または理解不足／誤解として解釈されるからである。
【０１７７】
コンテキスト・スタック８１７はダイアログ・マネージャ８１９によって、ダイアログ・マネージャおよびアービトレータと対話するコンテキスト・マネージャを通しておそらく管理される。コンテキスト・スタック８１７は図１のコンテキスト・スタック２０の一部として実施することができることを理解されたい。コンテキスト・スタック８１７は１つのアプリケーションに関連するすべての情報を含む。そのような情報としては、すべての変数、状態、入力、出力および、ダイアログのコンテキストにおいて、およびダイアログ間に発生する余分のイベント内で実行されるバックエンドに対するクエリーなどがある。コンテキスト・スタックはアクティブな各ダイアログ（または延期されたダイアログ・エージェント／メモライゼーション）に対応している編成された／ソートされたコンテキストに関連付けられている。グローバル履歴８１６がＣＶＭシステム内に含まれていて、各アプリケーションのコンテキストを超えて記憶される情報を含む。グローバル履歴は、例えば、すべてのアプリケーションおよび、会話型セッション間に取られるすべてのアクションに関連する情報（すなわち、現在のセッションに対するユーザとマシンとの間の、あるいはそのマシンが活性化された時のダイアログの履歴）に関連する情報を記憶する。
【０１７８】
ＣＶＭカーネル層８０２はバックエンド抽象化層８２３をさらに含み、それによってダイアログ・マネージャ８１９を経由して（ダイアログ・マネージャ８１９をバイパスせずに）バックエンド・ビジネス論理８１３にアクセスすることができる。これによってそのようなアクセスがコンテキスト・スタック８１７およびグローバル履歴８１６に追加されるようにすることができる。例えば、バックエンド抽象化層８２３はダイアログ・マネージャ８１９との間の入力および出力をデータベースのクエリーに変換することができる。この層８２３は、ｎ個のタプル（tuple）からなる標準化された属性値をデータベースのクエリーに変換し、そのクエリーの結果をダイアログ・マネージャ８１９に戻してｎ個のタプルの値からなる属性値のテーブルまたはセットに変換する。さらに、会話型トランスコーディング層８２４がＣＶＭシステムを実行する装置のＩ／Ｏおよびエンジン機能に基づいてユーザに提示される挙動、ＵＩおよびダイアログを適合させるために提供されている。
【０１７９】
ＣＶＭシステムは、ＯＳ８１２によって提供される基本となるシステム・サービスの一部として通信スタック８１４（または通信エンジン）をさらに備える。ＣＶＭシステムは、会話型通信を提供するために、従来の通信サービスを拡張する会話型プロトコル８０４を経由して情報を送信するために通信スタックを利用する。通信スタック８１４は、会話型装置間での会話型通信交換を提供するための、周知のＯＳＩ（開放型システム相互接続）プロトコル層と接続して実施することができることを理解されたい。当技術分野において周知のように、ＯＳＩは７つの層を含み、各層がネットワーク接続型装置のネットワーク分散型の会話型アプリケーション間の通信を提供するための機能を実行する。そのような層（その機能はよく理解されている）は、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データ・リンク層および物理層を含む。アプリケーション層は会話型プロトコル８０４を経由して会話型通信ができるように拡張されている。
【０１８０】
会話型プロトコル８０４によって一般に、リモート・アプリケーションおよびリソースがそれぞれの会話型機能およびプロキシを登録する。
【０１８１】
図１の多モード会話型コンピューティング・システムの好ましい実施形態は、図１１および図１２のコンテキストにおいて上述されたようにＣＶＭベースのシステムを実施することができる。本明細書に提供された内容が与えられると、当業者であれば、本発明の多モード会話型コンピューティング・システムを実施する種々の他の方法を実現することができるだろう。
Ｄ．会話型データ・マイニング
【０１８２】
ここで図１３および図１４について説明すると、この図は、それぞれの会話型データ・マイニング・システムの好ましい実施形態のブロック図を示す。本発明によるムード分類およびフォーカス検出を実施するために他の方法も使用することができることを理解されたい。
【０１８３】
フォーカス検出は、曖昧性の解決と一緒にダイアログ・マネージャ１８（図１）によって実施することができるが、好適には、ムード／フォーカス分類器２２（図１）によって実行することが好ましく、その実施を以下に説明する。フォーカスは分類およびデータ・マイニングによって、ムードが判定されるのと、あるいはユーザが分類されるのと正確に同じ方法によって判定することができる。すなわち、ユーザの態度および動き／ジェスチャが最も確からしいフォーカス・アイテムおよびフォーカス状態を統計論的に判定するために使用される。
【０１８４】
図１３および図１４は音声ベースのイベント・データに関してムード／フォーカス分類器２２（図１）で使用することができるムード／フォーカス分類技術を一般的に説明するために使用される。しかし、ビデオベースのイベント・データに関連するモードを含むために拡張されたアプリケーションが図１５のコンテキストにおいて説明され、その中でこれらの分類技術を多モード入力に対して容易に適用できることが示されている。
【０１８５】
図１３は、本発明に従って、ユーザの声に関連するデータを収集するための装置を示す。その装置は、一般的に９００として示されている。その装置はユーザとの会話を実行するダイアログ・マネジメント・ユニット９０２を含む。ユーザ提供の入力データ・イベントが図１のＩ／Ｏマネージャ１４を経由してシステム９００に提供されることが好ましいことを理解されたい。装置９００は、さらに、ダイアログ・マネージメント・ユニット９０２に結合されていて、会話の間にユーザ９０４によって話された発声に関連する音声波形を捕捉するオーディオ捕捉モジュール９０６を含む。図１３において説明を簡単にするように示されているが、オーディオ捕捉ユニット９０６は図１のＩ／Ｏサブシステムの一部であってよい。その場合、捕捉された入力データはＩ／Ｏマネージャ１４を経由してシステム９００に渡される。本明細書に使用されているように、会話は第１の人間と第２の人間、１つのマシン、あるいはそれらの組合せとの間での、少なくとも何らかの音声を含む任意の対話を含むことを広く理解することができるだろう。ふたたび、本発明の多モード・システム１０の上記内容に基づいて、ムード分類（フォーカス検出）システム９００を拡張して同様な方法でビデオを処理することができる。
【０１８６】
装置９００は、さらに、音響的フロントエンド９０８を含み、音響的フロントエンド９０８はオーディオ捕捉モジュール９０６に結合されていて、オーディオ捕捉モジュール９０６は、ディジタル音声波形を提供するように音声波形を受信してディジタル化するように構成される。さらに、音響的フロントエンド９０８は、また、ディジタル音声波形から、少なくとも１つのユーザ属性に相関付けられる少なくとも１つの音響特性を抽出するように構成される。上記少なくとも１つユーザ属性は、次のもののうちの少なくとも１つを含むことができる。それらは、ユーザの性別、ユーザの年令、ユーザのアクセント、ユーザの母国語、ユーザの方言、ユーザの社会経済的分類、ユーザの教育レベル、およびユーザの感情状態である。ダイアログ・マネジメント・ユニット９０２は、音響的フロントエンド９０８から得られたＭＥＬケプストラなどの音響特性を使用することができ、したがって、望ましい場合、それに対する直接結合を有することができる。
【０１８７】
装置９００は、さらに、処理モジュール９１０を含み、処理モジュール９１０は音響的フロントエンド９０８に結合されていて、少なくとも１つの音響特性を解析して上記少なくとも１つのユーザ属性を判定する。さらに、装置９００は、データ・ウェアハウス９１２を含み、装置９００は処理モジュール９１０に結合されていて、それ以降でのデータ・マイニングのための形式において、少なくとも１つの識別用のインデックスと一緒に上記少なくとも１つのユーザ属性を記憶する。識別用のインデックスについては、本明細書の中のどこかで説明される。
【０１８８】
ユーザの性別は、そのユーザの声のピッチを分類することによって、あるいは単純にその特徴をクラスタ化することによって判定することができる。後者の方法においては、所与の性の話者の大規模な集合に関連する声紋が作られ、話者分類が次に２つの組のモデルについて実行される。ユーザの年令も年令グループの分類によって、性別の場合と同様に判定することができる。信頼度は制限されているが、年令の広いクラス、例えば、子供、ティーンエージャ、成人および高齢者をこの方法で分けることができる。
【０１８９】
音響特性からのアクセントの判定は当技術分野において周知である。例えば、Spoken Language Processing, Sidney, Australiaにおいて１９９８年の国際学会［以下、ICSLP ’98］で発表されたLincoln他による論文、「アクセントの識別のための2つの非ス−パバイザ型の方法の比較」(AComparison of Two Unsupervised Approaches to Accent Identification）が有用な技術を示す。ユーザの母国語はアクセントの分類と本質的に等価な方法で判定することができる。話者の母国語に対するメタ情報を追加して各アクセント／母国語のモデルを定義することができる。
【０１９０】
すなわち、各母国語に対するモデルの生成において、母国語としてその言語のタグが付けられている１人または複数の話者を使用する。やはりICSLP ’98において発表されたMatrouf他による論文、「辞書的情報を組み込んだ言語識別」(LanguageIdentification Incorporating Lexical Information）が、言語識別のための種々の技術を説明している。
【０１９１】
ユーザの方言はアクセントおよび所与の方言に固有のキーワードまたは熟語の使用から判定することができる。例えば、フランス語においては、数値９０に対して“Quatre Vingt Dix”の代わりに“nonante”を選定することは、その話者をベルギー人またはスイス人の血統であるとして識別し、フランス人またはカナダ人としては識別しないことになる。さらに、数値８０に対して“Huitante”の代わりに“quatre-vingt”を結果的に選定することは、スイス人ではなくベルギー人としてその個人を識別することになる。アメリカ英語において、“grocery bag”ではなく“grocerysack”を選定することは、その人が中西部の出身の人であり中部大西洋岸の出身ではないと識別される可能性がある。中西部対中部大西洋岸のアメリカ英語のもう１つの例は中西部におけるソフト・ドリンクに対する“pop”および中部大西洋領域に対応するソフト・ドリンクに対する“soda”の選定である。意図的なコンテキストにおいては、“vacation”ではなく、 “holiday”の使用はその人が米国出身ではなくイギリス人であるとして識別する可能性がある。このパラグラフにおいて記述された動作は以下に説明される音声認識装置１２６を使用して実行することができる。
【０１９２】
ユーザの社会経済的分類はそのユーザの人種的背景、ユーザの民族的背景、およびユーザの経済的クラス、例えば、ブルーカラー、ホワイトカラー中級または富裕などのファクタを含むことができる。そのような判定はユーザのワードの選定を調べることによる以外に、トレーニングの時点での注釈付けられたアクセントおよび方言を経由して行うことができる。ほどよい程度に信頼できるだけであるが、これらの技術はデータ・マイニングに有用であるようにそのユーザの背景に十分な洞察を与えることが信じられている。
【０１９３】
ユーザの教育レベルは、社会経済的分類に対する場合と同様な方法でワードの選定およびアクセントによって判定することができる。ふたたび、期待される信頼度は部分的であるに過ぎないが、データ・マイニングの目的に対しては十分である。
【０１９４】
音響特性からのユーザの感情状態の判定は、当技術分野において周知である。認識できる感情的なカテゴリーは、熱い怒り、冷たい怒り、パニック、恐れ、心配、悲しみ、高揚、絶望、幸福、関心、倦怠、恥ずかしさ、軽蔑、困惑、嫌悪および誇りである。関連の音響特性から感情状態を判定する方法の例は、以下の論文、すなわち、PereiraおよびWatsonの、「感情のいくつかの音響的特性」(Some AcousticCharacteristics of Emotion), AmirおよびRonの、「音声における感情の自動分類に向けて」(Towards an Automatic Classification of Emotions in Speech)、およびWhitesideの、「シミュレートされた感情:声および摂動手段の音響的研究」(SimulatedEmotions:An Acoustic Study of Voice and Perturbation Measures)に記載されており、これらの論文はすべてICSLP’98において発表されたものである。
【０１９５】
オーディオ捕捉モジュール９０６は、例えば、少なくとも１つのアナログ−ディジタル変換器ボード、対話型音声応答システム、およびマイクロホンを含むことができる。ダイアログ・マネジメント・ユニット９０２は、例えば、オーディオ捕捉を実施するために使用されるのと同じ電話の対話音声応答システムを含むことができる。他の方法としては、ダイアログ・マネジメント・ユニットは単純に人間のオペレータに対する音響的インタフェースであってよい。ダイアログ・マネージメント・ユニット９０２は、自然言語理解（ＮＬＵ）、自然言語発生（ＮＬＧ）、有限状態文法（ＦＳＧ）、および／またはテキスト音声合成（ＴＴＳ）を人間のオペレータの代わりに、あるいはそれに追加してユーザに対するマシン・プロンプトのために含むことができる。処理モジュール９１０は、ＩＶＲのプロセッサ部分の中に実施すること、あるいは適当なソフトウェアと一緒に別の汎用コンピュータの中に実施することができる。さらに、処理モジュールは、特定用途向け集積回路（ＡＳＩＣ）などの用途固有の回路を使用して実施することができるか、あるいは個々の部品を使用している用途固有の回路の中に実施することができるか、あるいは個々の構成部品および集積回路構成部品の組合せの中に実施することができる。
【０１９６】
処理モジュール９１０は、感情状態分類器９１４を含むことができる。分類器９１４は、さらに、感情状態分類モジュール９１６および感情状態のプロトタイプ・データベース９１８を含むことができる。
【０１９７】
処理モジュール９１０は、さらに、話者クラスタおよび分類器９２０を含むことができる。要素９２０は、さらに、話者クラスタリングおよび分類モジュール９２２および話者クラスのデータ・ベース９２４を含むことができる。
【０１９８】
処理モジュール９１０は、さらに、音声認識装置９２６を含むことができ、音声認識装置９２６は、さらに、それ自身が音声認識モジュール９２８および音声プロトタイプ、言語モデルおよび文法データベース９３０を含むことができる。音声認識装置９２６は、ダイアログ・マネジメント・ユニット９０２の一部であるか、あるいは、例えば、処理モジュール９１０の実施内の別の要素であってよい。さらに、処理モジュール９１０は、アクセント識別装置９３２を含むことができ、アクセント識別装置９３２は、さらに、アクセント識別モジュール９３４およびアクセント・データベース９３６を含む。
【０１９９】
処理モジュール９１０は、要素９１４，９２０，９２６および９３２のうちの任意の１つ、それらの要素のすべて、またはそれらの任意の組合せを含むことができる。
【０２００】
装置９００は、さらに、データ・ウェアハウス９１２に結合されていて、ユーザの発声を文書化し、それに対してキーワード付けを実行するように構成されるポスト・プロセッサ９３８をさらに含むことができる。図１３では別のアイテムとして示されているが、ポスト・プロセッサは処理モジュール９１０またはそのサブ構成要素のどれかの一部であってよい。例えば、それを音声認識装置９２６の一部として実施することができる。ポスト・プロセッサ９３８は、ＩＶＲのプロセッサの一部として、特定用途向け集積回路として、あるいは適切なソフトウェア・モジュールを有する汎用コンピュータ上で実施することができる。ポスト・プロセッサ９３８は音声認識装置９２６を使用することができる。また、ポスト・プロセッサ９３８は、フレーズの意味を解釈するためにセマンティック・モジュール(図示せず）を含むこともできる。セマンティック・モジュールを音声認識装置９２６によって使用し、リスト内のいくつかのデコーディング候補が無意味であり、捨てられるか、あるいは意味のある候補で置き換えるべきであることを示すことができる。
【０２０１】
音響的フロントエンド９０８は、通常、当技術分野において周知の８次元のエネルギー・フロントエンドであってよい。しかし、１３、２４、または任意の他の数の次元も使用できることを理解されたい。ＭＥＬケプストラを、例えば、１０ｍｓオーバラップしている２５ｍｓのフレームにわたって、デルタおよびデルタ・デルタのパラメータ、すなわち、一次および二次の有限微分と一緒に計算することができる。そのような音響特性を図１３に示されているような話者クラスタおよび分類器９２０、音声認識装置９２６およびアクセント識別装置９３２に供給することができる。
【０２０２】
他のタイプの音響特性を音響的フロントエンド９０８によって抽出することができる。これらはランニング平均ピッチ、ランニング・ピッチ変動、ピッチ・ジッタ、ランニング・エネルギー変動、音声レート、揺らめき、基本周波数、および基本周波数における変動などの感情状態の特徴として示すことができる。ピッチ・ジッタはピッチの一次微分の符号変化の数を指す。揺らめきはエネルギー・ジッタである。これらの特徴を音響的フロントエンド９０８から感情状態分類器９１４に供給することができる。ＭＥＬケプストラおよび感情状態の特徴などの上記音響特性は、生の、すなわち、未処理の特徴と考えることができる。
【０２０３】
ユーザのクエリーをＩＶＲまたは他の手段によって文書化することができる。音声の特徴は、先ず最初にテキスト独立の話者分類システムによって、例えば、話者クラスタおよび分類器９２０において処理することができる。これによって、それぞれの声の音響的類似性に基づいて話者を分類することができる。話者の分類はス−パバイザ型または非ス−パバイザ型であってもよい。ス−パバイザ型の場合、そのクラスは外部情報に基づいて前もって決定されている。通常、そのような分類は男性と女性、成人対子供、ネイティブ・スピーカ対種々のクラスの非ネイティブ・スピーカなどに分けることができる。この分類プロセスのインデックスが処理された特徴を構成する。このプロセスの結果は感情状態分類器９１４に供給することができ、所与のクラス、トレーニングの間、中立の感情状態に対して観察された平均に関して感情状態の特徴を正規化するために使用することができる。正規化された感情状態の特徴は感情状態分類器９１４によって使用され、感情状態分類器９１４は次に感情状態の評価を出力する。この出力は、また、処理された特徴の一部であるともみなされる。要約すると、感情状態の特徴は音声クラスタおよび分類器９２０によって作り出された各クラスに関して感情状態分類器９１４によって正規化することができる。Ｘ０を正規の頻度であるとする。Ｘｉを測定された頻度であるとする。次に、正規化された特徴はＸｉ−Ｘ０で与えられる。
【０２０４】
音声認識装置９２６はユーザからのクエリーを文書化することができる。音声認識装置９２６は話者独立の、あるいはクラス依存の大規模語彙連続音声認識であってよく、あるいはシステムは、（例えば）侮辱などを検出するためのキーワード付加器のような簡単な何かであってよい。そのようなシステムは、当技術分野において周知である。その出力は完全な文章であってよいが、より細かい粒度も、例えば、その認識されたワードの時間アラインメントも得ることができる。タイム・スタンプが付けられた転写も、処理された特徴の一部とみなすことができ、本発明による方法に関して以下にさらに説明される。それ故、トランザクションのすべてのステージからの会話を転写して記憶することができる。図１３に示されているように、適当なデータが話者クラスタおよび分類器９２０から感情状態分類器９１４および音声認識器９２６に転送される。注記されているように、ユーザからの入力音声によってアクセント、方言および言語の認識を実行することができる。認識されるアクセントが異なっている何人かの話者について、音声において連続音声認識器を訓練することができる。訓練中の各話者は、また、アクセント・ベクトルにも関連付けられ、各部分音声の各状態に関連する最も確からしい混合構成要素を表している各次元にも関連付けられる。話者はこれらのアクセント・ベクトル間の距離に基づいてクラスタ化され、そのクラスタが例えば、メンバー話者のアクセントによって識別することができる。アクセントの識別は、そのユーザの音声からアクセント・ベクトルを抽出し、それを分類することによって実行することができる。注記されているように、方言、社会経済的分類などを、そのユーザによって使用される語彙およびワード・シリーズに基づいて評価することができる。適当なキーワード、文章、文法的誤りの検出を、専門家の言語学的知識によって編集することができる。アクセント、社会経済的背景、性別、年令などはその処理された特徴の一部である。図１３に示されているように、実線の矢印によって示されている任意の処理された特徴をデータ・ウェアハウス９１２内に記憶することができる。さらに、点線で示されている生の特徴も、また、データ・ウェアハウス９１２内に記憶することができる。
【０２０５】
処理された特徴または生の特徴のどれもデータ・ウェアハウス９１２内に記憶することができ、トランザクションの編集時に、収集された他のデータと関連付けることができる。古典的なデータ・マイニング技術を次に適用することができる。そのような技術は、例えば、McGraw Hillから1997年に出版されたAlex BersonおよびStephen J. Smithの書籍「データ・ウェアハウジング、データ・マイニングおよびOAAP」(Data Warehousing,Data Mining and OAAP)、およびPrentice Hallから1998年に出版されたCabena他の、「データ・マイニングの発見」(Discovering Data Mining)に記載されている。所与のビジネス目的のために、例えば、ターゲット・マーケッティングのために、予測モデルまたは分類器が、適当なマイニング・レシピを適用することによって自動的に得られる。データ・ウェアハウス９１２内に記憶されているすべてのデータを、それらについてのそれ以降のデータ・マイニングを容易化するためのフォーマットで記憶することができる。当業者であれば、引用された２つの参考書籍内に記載されているように、発掘されるデータに対する適当なフォーマットを知っている。ビジネス目的は、例えば、所与の製品またはサービスを購入するための提案に対して誘惑されやすいユーザの検出、自動化されたシステムについて問題を有していて、オペレータへ委譲されるユーザの検出、およびそのサービスにおいて怒っていて、管理者へ委譲されるユーザの検出などを含むことができる。そのユーザは装置９００を使用するビジネスの顧客であってよく、あるいは何らかの他のタイプの機関、例えば、非営利機関、政府機関などのクライアントであってもよい。
【０２０６】
特徴を抽出し、その判定を動的にそのモデルによって返すことができる。これについて以下にさらに説明される。
【０２０７】
図１４は本発明による、ユーザとの対話のためのリアルタイムの変更可能な音声システムを示しており、それは一般的に１０００として示されている。図１３の要素に類似した図１４の要素には、その同じ参照番号に１００を加えた番号が付けられている。システム１０００は上記と同様なダイアログ・マネジメント・ユニット１００２を含むことができる。特に、図１４において提案されているように、ユニット１００２は、人間のオペレータまたは管理者またはＩＶＲ、または音声ユーザ・インタフェース（ＶＵＩ）であってよい。システム１０００は、また、上記に類似したオーディオ捕捉モジュール１００６、および音響的フロントエンド１００８（これも上記のものに類似している）も含むことができる。装置９００の場合と同様に、ユニット１００２は、必要であれば、音響的フロントエンド１００８に直接結合し、フロントエンド１００８によって判定されたＭＥＬケプストラまたは他の音響特性を使用することができる。さらに、システム１０００は、上記のものと同様な処理モジュール１０１０を含むが、それは以下に説明されるいくつかの追加の特徴を有している。処理モジュール１０１０は、ユーザの動的分類を実行する動的分類モジュール１０４０を含むことができる。したがって、処理モジュール１０１０は、ユーザの音声から抽出された少なくとも１つの音響特性に基づいて判定された少なくとも１つのユーザ属性に基づいて音声システム１０１０の挙動を変更するように構成される。システム１０１０はビジネス論理ユニット１０４２をさらに含むことができ、ビジネス論理ユニット１０４２はダイアログ・マネジメント・ユニット１００２、動的分類モジュール１０４０、およびオプションとして音響的フロントエンド１００８に結合されている。ビジネス論理ユニットはＩＶＲまたはＶＵＩの処理部分として実施することができ、適当にプログラムされた汎用コンピュータの一部、または特定用途向け回路であってよい。現在において、処理モジュール１０１０（モジュール１０４０を含む）を汎用コンピュータとして実施すること、そしてビジネス論理１０４２を対話型音声応答システムのプロセッサ部分内に実施することが好ましいと信じられる。動的分類モジュール１０４０は、ビジネス論理ユニット１０４２およびダイアログ・マネジメント・ユニット１００２にリアルタイムでフィードバックすることができるフィードバックを提供するように構成することができる。
【０２０８】
データ・ウェアハウス１０１２およびポスト・プロセッサ１０３８は、図に示されているように、オプションとして提供することができ、データ収集装置９００に関して上述されたように動作することができる。しかし、本発明のリアルタイム変更可能音声システム１０００においては、データ・ウェアハウジングはオプションであり、必要であれば、そのシステムを要素１０４０、１０４２および１００２に関して説明されたリアルタイム・フィードバックに限定することができる。
【０２０９】
処理モジュール１０１０は、少なくとも部分的に、その人間のオペレータにプロンプトを与えることによって、ダイアログ・マネジメント・ユニット１００２に接続されたフィードバック・ラインによって提案されているように、システム１０００の挙動を変更することができる。例えば、人間のオペレータはユーザの怒りの感情状態が検出された時に警告されるようにすることができ、ユーザに対してなだめる言葉を発生するようにプロンプトされ、あるいはそのユーザをより高いレベルの人間の管理者に引き渡すことができる。さらに、処理モジュール１０１０はシステム１０００のビジネス論理１０４２を修正することができる。これは例えば、処理モジュール１０１０およびビジネス論理ユニット１０４２の両方がＩＶＲシステムの部分であった時に行うことができる。ビジネス論理の変更の例は以下にさらに説明されるが、システム１０００によって検出されたユーザの属性に基づいてそのユーザに対してマーケティングの提案を仕立て上げることを含むことができる。
【０２１０】
ここで図１５について説明すると、この図は、音声およびビデオの入力イベント・データを含む多モードの環境においてムード／フォーカス分類器２（図１）によって、上記ムード／フォーカス分類技術を実施することができる方法を示すブロック図を示す。図に示されているように、図１５で示されている分類器は音声入力チャネル１０５０−１と、音声チャネル・コントローラ１０５２−１と、音声ベースのムード分類サブシステム１０５４−１とを備える。この分類器は、また、ビデオ入力チャネル１０５０−Ｎと、ビデオ・チャネル・コントローラ１０５２−Ｎと、ビデオベースのムード分類サブシステム１０５４−Ｎとを備える。もちろん、他のモードに対して分類器を拡張するために他の入力チャネルおよび対応している分類サブシステムを含むことができる。個々の各分類サブシステムは、それぞれの入力チャネルから生の特徴を受け取り、その特徴を処理するために認識および分類エンジンを使用し、次にデータ・ウェアハウス１０５８と結合して、動的分類判定を行う。これらのプロセスの詳細は、図１３および図１４に関して上述されている。ビデオの特徴は音声の特徴と同様に処理することができる。次に、総合分類判定を行うために各入力モードからのデータを使用してブロック１０５６において結合動的分類を実行することができる。ムード／フォーカス分類器によって実行されているある特定のアプリケーションに従ってプロセスを制御するために、ビジネス論理ユニット１０６０および多モード・シェル１０６２が使用される。チャネル・コントローラ１０５２−１および１０５２−Ｎが音声データおよびビデオ・データの入力を制御するためにそれぞれ使用される。
【０２１１】
したがって、ユーザのムードを判定した後、上記のようなムード分類システムは、ユーザのムードおよび／またはフォーカスを変える効果を有することになる環境内の装置、例えば、温度制御システム、音楽システムなどを調整するように、Ｉ／Ｏマネージャ１４を経由して、図１のＩ／Ｏサブシステム１２に指示することができることを理解されたい。
【０２１２】
ここで図１６について説明すると、この図は、本発明による多モード会話型コンピューティング・システムの例示としてのハードウェア実施のブロック図を示す。この特定の実施においては、図１から図１５に示されている本発明の例示としてのシステムに関連する種々の動作を制御して実行するためのプロセッサ１０９２が、メモリ１０９４およびユーザ・インタフェース１０９６に結合されている。本明細書で使用されている「プロセッサ」という用語は、例えば、ＣＰＵ（中央処理装置）および／または他の処理回路を含む任意の処理装置を含むことが意図されていることを理解されたい。例えば、プロセッサは、当技術分野において周知のディジタル信号プロセッサであってよい。また、「プロセッサ」という用語は２つ以上の個々のプロセッサを指すことができる。本明細書で使用されている「メモリ」という用語は、例えば、ＲＡＭ、ＲＯＭ、固定メモリ素子（例えば、ハード・ドライブ）、取り外し可能なメモリ素子（例えば、ディスケット）、フラッシュ・メモリなどの、プロセッサまたはＣＰＵに関連するメモリを含むことが意図されている。さらに、本明細書で使用されている「ユーザ・インタフェース」という用語は、例えば、１つまたはそれ以上の入力装置、例えば、処理装置にデータを入力するためのキーボード、および／または１つまたはそれ以上の出力装置、例えば、処理装置に関連する結果を提供するためのＣＲＴディスプレイおよび／またはプリンタを含むことが意図されている。ユーザ・インタフェース１０９６は、また、ユーザの音声を受け取るための１つまたはそれ以上のマイクロホン、および画像データを捕捉するための１つまたはそれ以上のカメラ／センサ、並びに多モード・システムにおいて使用される任意の他のＩ／Ｏインタフェース装置を含むことも意図されている。
【０２１３】
したがって、本明細書で記述されたように、本発明の方法を実行するための命令またはコードを含むコンピュータ・ソフトウェアを１つまたはそれ以上の関連するメモリ素子（例えば、ＲＯＭ、固定または移動可能なメモリ）に記憶し、利用される用意ができた時に、部分的に、または全体をロードし（例えば、ＲＡＭ内に）、ＣＰＵによって実行することができる。いずれの場合においても、図１から図１５に示された要素を、種々の形式のハードウェア、ソフトウェア、またはそれらの組合せ、例えば、メモリ付属のディジタル信号プロセッサ、特定用途向け集積回路、機能的回路、メモリ付属の１つまたはそれ以上の適当にプログラムされた汎用ディジタル・コンピュータに実施することができることを理解されたい。本明細書で与えられた本発明の内容が与えられると、当業者であれば、本発明の要素の他の実施を思い付くことができる。
【０２１４】
本発明の例示としてのいくつかの実施形態を添付の図面を参照して説明してきたが、本発明はそれらの正確な実施形態に限定されるものではないこと、および当業者であれば、種々の他の変更および修正を、本発明の範囲または精神から逸脱することなしに行うことができることを理解されたい。
【図面の簡単な説明】
【０２１５】
【図１】本発明のある実施形態による多モード会話型コンピューティング・システムを示すブロック図である。
【図２】本発明のある実施形態による多モード会話型コンピューティング・システムによって実行される参照の曖昧性解決の方法を示す流れ図である。
【図３】本発明のある実施形態による多モード会話型コンピューティング・システムによって実行されるムード／フォーカスの分類方法を示す流れ図である。
【図４】本発明のある実施形態に従って使用するためのオーディオビジュアル音声認識モジュールを示すブロック図である。
【図５】本発明のある実施形態に従って使用するための前向きの顔のポーズおよび前向きでない顔のポーズの例を示す図である。
【図６】本発明のある実施形態に従って使用するための顔／特徴および前向きポーズの検出方法の流れ図である。
【図７】本発明のある実施形態に従って使用するためのイベント検出方法の流れ図である。
【図８】本発明のある実施形態に従って使用するための発声検証を使用しするイベント検出方法の流れ図である。
【図９】本発明のある実施形態に従って使用するためのオーディオビジュアル話者認識モジュールを示すブロック図である。
【図１０】本発明のある実施形態に従って使用するための発声検証方法の流れ図である。
【図１１】本発明のある実施形態に従って使用するための会話型コンピューティング・システムを示すブロック図である。
【図１２】本発明のある実施形態に従って使用するための会話型コンピューティング・システムを示すブロック図である。
【図１３】本発明のある実施形態に従って使用するための各ムード分類システムを示すブロック図である。
【図１４】本発明のある実施形態に従って使用するための各ムード分類システムを示すブロック図である。
【図１５】本発明のある実施形態に従って使用するための各ムード分類システムを示すブロック図である。
【図１６】本発明による多モード会話型コンピューティング・システムの例示としてのハードウェア実施のブロック図である。
【図１】
2004538543.tif 000024
【図２】
2004538543.tif 000025
【図３】
2004538543.tif 000026
【図４】
2004538543.tif 000027
【図５】
2004538543.tif 000028
【図６】
2004538543.tif 000029
【図７】
2004538543.tif 000030
【図８】
2004538543.tif 000031
【図９】
2004538543.tif 000032
【図１０】
2004538543.tif 000033
【図１１】
2004538543.tif 000034
【図１２】
2004538543.tif 000035
【図１３】
2004538543.tif 000036
【図１４】
2004538543.tif 000037
【図１５】
2004538543.tif 000038
【図１６】
2004538543.tif 000039
【国際公開パンフレット】
2004538543.tif 000040
2004538543.tif 000041
2004538543.tif 000042
2004538543.tif 000043
2004538543.tif 000044
2004538543.tif 000045
2004538543.tif 000046
2004538543.tif 000047
2004538543.tif 000048
2004538543.tif 000049
2004538543.tif 000050
2004538543.tif 000051
2004538543.tif 000052
2004538543.tif 000053
2004538543.tif 000054
2004538543.tif 000055
2004538543.tif 000056
2004538543.tif 000057
2004538543.tif 000058
2004538543.tif 000059
2004538543.tif 000060
2004538543.tif 000061
2004538543.tif 000062
2004538543.tif 000063
2004538543.tif 000064
2004538543.tif 000065
2004538543.tif 000066
2004538543.tif 000067
2004538543.tif 000068
2004538543.tif 000069
2004538543.tif 000070
2004538543.tif 000071
2004538543.tif 000072
2004538543.tif 000073
2004538543.tif 000074
2004538543.tif 000075
2004538543.tif 000076
2004538543.tif 000077
2004538543.tif 000078
2004538543.tif 000079
2004538543.tif 000080
2004538543.tif 000081
2004538543.tif 000082
2004538543.tif 000083
2004538543.tif 000084
2004538543.tif 000085
2004538543.tif 000086
2004538543.tif 000087
2004538543.tif 000088
2004538543.tif 000089
2004538543.tif 000090
2004538543.tif 000091
2004538543.tif 000092
2004538543.tif 000093
2004538543.tif 000094
2004538543.tif 000095
2004538543.tif 000096
2004538543.tif 000097
2004538543.tif 000098
2004538543.tif 000099
2004538543.tif 000100
2004538543.tif 000101
2004538543.tif 000102
2004538543.tif 000103
2004538543.tif 000104
2004538543.tif 000105
2004538543.tif 000106
2004538543.tif 000107
2004538543.tif 000108
2004538543.tif 000109
2004538543.tif 000110
2004538543.tif 000111
2004538543.tif 000112
2004538543.tif 000113
2004538543.tif 000114
2004538543.tif 000115
2004538543.tif 000116
2004538543.tif 000117
2004538543.tif 000118
2004538543.tif 000119
2004538543.tif 000120
2004538543.tif 000121
2004538543.tif 000122
2004538543.tif 000123
2004538543.tif 000124
2004538543.tif 000125
2004538543.tif 000126
2004538543.tif 000127
2004538543.tif 000128
2004538543.tif 000129
2004538543.tif 000130
2004538543.tif 000131
2004538543.tif 000132
2004538543.tif 000133
2004538543.tif 000134
2004538543.tif 000135
2004538543.tif 000136
2004538543.tif 000137
2004538543.tif 000138
2004538543.tif 000139
2004538543.tif 000140
2004538543.tif 000141
2004538543.tif 000142
【国際調査報告】
2004538543.tif 000143
2004538543.tif 000144
2004538543.tif 000145