(57)【特許請求の範囲】
【請求項１】
会話型リソースを共用することを実現するためのシステムであって、
少なくとも第１および第２のネットワーク装置を含むネットワークを含み、
前記第１および第２のネットワーク装置がそれぞれ、
会話型リソースのセットと、
会話を管理し会話型サービスを要求する呼出しを実行するためのダイアログ・マネージャと、
前記ネットワークを介し会話型プロトコルを使用してメッセージを通信するための通信スタックとを備え、前記会話型プロトコルを使用して通信される前記メッセージが、前記第１および第２のネットワーク装置それぞれに要求された会話型サービスを実施するのに必要なとき、前記第１および第２のネットワーク装置の前記ダイアログ・マネージャ間にネットワーク通信を確立して、前記第１および第２のネットワーク装置の前記会話型リソースのセットを共用するシステム。
【請求項２】
前記第１および第２のネットワーク装置の前記会話型リソースのセットが、音声認識エンジン、話者認識エンジン、ＴＴＳ（テキスト音声合成）エンジン、ＮＬＵ（自然言語理解）エンジン、ＮＬＧ（自然言語生成）エンジン、オーディオ取込みおよび圧縮／解凍エンジン、トピック認識エンジン、オーディオ／マルチメディア索引付けおよび探索エンジン、ならびにこれらの組合せのうち、少なくとも１つを含む、請求項１に記載のシステム。
【請求項３】
前記会話型プロトコルは、前記第１および第２のネットワーク装置の前記ダイアログ・マネージャがそれぞれの会話型状態、引き数、およびコンテキストを含む情報を交換し、ダイアログ・コンポーネントを交換することができるようにする、請求項１に記載のシステム。
【請求項４】
前記会話型プロトコルが、前記第１および第２のネットワーク装置の前記ダイアログ・マネージャ間でマスタ／スレーブ・ネットワーク通信とピア・ツー・ピア・ネットワーク通信のうちの一方を調整する、請求項３に記載のシステム。
【請求項５】
前記会話型プロトコルが発見プロトコルを含み、前記発見プロトコルは、前記第１および第２のネットワーク装置が、ネットワーク上で会話型と認識している装置およびアプリケーションを発見できるようにする、請求項１に記載のシステム。
【請求項６】
前記発見プロトコルが「ブロードキャストおよびリッスン」方法を実施する、請求項５に記載のシステム。
【請求項７】
前記発見プロトコルが、少なくとも前記第１のネットワーク装置と前記第２のネットワーク装置の間に動的かつ自発的なネットワークを確立するように実施される、請求項６に記載のシステム。
【請求項８】
前記会話型プロトコルが、会話型リソース、能力、および要件に関する情報を交換するための登録プロトコルを含む、請求項１に記載のシステム。
【請求項９】
前記会話型プロトコルが、前記第１のネットワーク装置と前記第２のネットワーク装置の間でそれぞれの前記会話型リソースおよび能力に基づいてネットワーク構成を確立するために情報を交換するための折衝プロトコルを含む、請求項８に記載のシステム。
【請求項１０】
前記ネットワーク構成は、前記第１のネットワーク装置と前記第２のネットワーク装置のうちの一方の前記ダイアログ・マネージャが前記第１のネットワーク装置と前記第２のネットワーク装置の両方の前記会話型リソースを制御するマスタ／スレーブ・ネットワークと、前記第１および第２の装置の前記ダイアログ・マネージャが会話型リソースを制御するために折衝するピア・ツー・ピア・ネットワークのうちの一方を含む、請求項９に記載のシステム。
【請求項１１】
前記会話型プロトコルが、圧縮音声波形、圧縮音声特徴、および圧縮結果のうちの１つを前記第１のネットワーク装置と前記第２のネットワーク装置の間で伝送するための音声伝送プロトコルを含む、請求項１に記載のシステム。
【請求項１２】
会話型リソースを共用することを実現するためのシステムにおいて、
ローカル会話型リソースを備えるクライアントであって、前記ローカル会話型リソースを管理し、会話型サービスを求める要求を処理し、前記会話型サービスを求める要求が前記ローカル会話型リソースを使用して行えるかどうかを判定するためのダイアログ・マネージャを備えるクライアントと、
サーバ会話型リソースを備えるサーバとを含むシステムであって、前記クライアントの前記ダイアログ・マネージャが、前記ローカル会話型リソースを使用して前記要求された会話型サービスを実施できない場合に、前記サーバ会話型リソースを使用して前記要求を処理するために前記サーバにアクセスするシステム。
【請求項１３】
会話型リソースをネットワーク装置間で共用することを実現する方法であって、
会話型サービスを求める要求を第１のネットワーク装置によって受け取るステップと、
前記要求された会話型サービスを、前記第１のネットワーク装置の会話型リソースを使用してローカルで処理するか、少なくとも第２のネットワーク装置の会話型リソースを使用してリモートで処理するか、あるいは前記ローカルの会話型リソースと前記リモートの会話型リソースを両方とも使用してローカルかつリモートで処理するかを、前記第１のネットワーク装置によって決定するステップと、
前記会話型サービスが少なくとも部分的に、前記少なくとも第２のネットワーク装置の前記会話型リソースを使用してリモートで処理されると決定された場合に、前記少なくとも第２のネットワーク装置と通信するステップとを含む方法。
【請求項１４】
前記会話型リソースを共用するために、会話型プロトコルを使用してメッセージを送信して、前記第１のネットワーク装置と前記少なくとも第２のネットワーク装置との間に調整されたネットワーク通信を確立するステップをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記決定するステップが、前記要求された会話型サービスを処理するのにローカル会話型リソースが利用可能かどうかを判定するステップを含み、前記方法はさらに、
前記要求された会話型サービスを処理するのに前記ローカル会話型リソースが利用可能であると判定された場合に、前記ローカル会話型リソースを使用して前記要求された会話型サービスを実行するステップと、
前記ローカル処理の結果が許容できるかどうかを判定するステップと、
前記ローカル処理の結果が許容できないと判定された場合に、前記少なくとも第２のネットワーク装置にアクセスして、前記要求された会話型サービスをリモートで処理するステップとを含む、請求項１３に記載の方法。
【請求項１６】
前記決定するステップが、前記少なくとも第２のネットワーク装置が前記会話型サービスを処理するよう前記第１のネットワーク装置によって事前指定されているかどうかを判定するステップを含む、請求項１３に記載の方法。
【請求項１７】
前記決定するステップが、前記第１のネットワーク装置と前記少なくとも第２のネットワーク装置との間のネットワーク接続使用可能度とネットワーク・トラフィックのうちの一方に基づく、請求項１３に記載の方法。
【請求項１８】
前記アクセスするステップが、
前記会話型プロトコルを使用してメッセージを送信することにより、前記少なくとも第２のネットワーク装置とのネットワーク接続を確立するステップと、
前記少なくとも第２のネットワーク装置に圧縮音声特徴と圧縮波形のうちの一方を送信するステップとを含む、請求項１４に記載の方法。
【請求項１９】
計算機によって読取り可能なプログラム記憶装置において、ネットワーク装置間で会話型リソースを共用することを実現する方法ステップを実施するために、前記計算機によって実行可能な命令のプログラムを実体として組み入れたプログラム記憶装置であって、前記方法ステップは、
会話型サービスを求める要求を第１のネットワーク装置によって受け取るステップと、
前記要求された会話型サービスを、前記第１のネットワーク装置の会話型リソースを使用してローカルで処理するか、少なくとも第２のネットワーク装置の会話型リソースを使用してリモートで処理するか、あるいはローカルの会話型リソースとリモートの会話型リソースを両方とも使用してローカルかつリモートで処理するかを、前記第１のネットワーク装置によって決定するステップと、
前記会話型サービスが少なくとも部分的に、前記少なくとも第２のネットワーク装置の前記会話型リソースを使用してリモートで処理されると決定された場合に、前記少なくとも第２のネットワーク装置に通信するステップとを含むプログラム記憶装置。
【請求項２０】
前記会話型リソースを共用するために、会話型プロトコルに従ってメッセージを送信して、前記第１のネットワーク装置と前記少なくとも第２のネットワーク装置との間に調整されたネットワーク通信を確立する前記ステップを実施する命令をさらに含む、請求項１９に記載のプログラム記憶装置。
【請求項２１】
前記決定するステップを実施する命令が、前記要求された会話型サービスを処理するのに前記ローカル会話型リソースが利用可能かどうかを判定するステップを実施する命令を含み、前記プログラム記憶装置はさらに、
前記要求された会話型サービスを処理するのに前記ローカル会話型リソースが利用可能であると判定された場合に、前記ローカル会話型リソースを使用して前記要求された会話型サービスを実行するステップと、
前記ローカル処理の結果が許容できるかどうかを判定するステップと、
前記ローカル処理の結果が許容できないと判定された場合に、前記少なくとも第２のネットワーク装置にアクセスして、前記要求された会話型サービスをリモートで処理するステップとを実施する命令を含む、請求項１９に記載のプログラム記憶装置。
【請求項２２】
前記決定するステップを実施する命令が、前記少なくとも第２のネットワーク装置が前記会話型サービスを処理するよう前記第１のネットワーク装置によって事前指定されているかどうかを判定するステップを実施する命令を含む、請求項１９に記載のプログラム記憶装置。
【請求項２３】
前記決定するステップが、前記第１のネットワーク装置と前記少なくとも第２のネットワーク装置との間のネットワーク接続使用可能度とネットワーク・トラフィックのうちの一方に基づく、請求項１９に記載のプログラム記憶装置。
【請求項２４】
前記アクセスするステップを実施する命令が、
前記会話型プロトコルを使用して、前記少なくとも第２のネットワーク装置とのネットワーク接続を確立するステップと、
前記少なくとも第２のネットワーク装置に圧縮音声特徴と圧縮波形のうちの一方を送信するステップとを実施する命令を含む、請求項２０に記載のプログラム記憶装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般に会話型システムに関し、より詳細には、ネットワーク接続された装置、サーバ、およびアプリケーションの間で会話型関数／リソースを共用するためのシステムおよび方法に関する。
【０００２】
【従来の技術】
従来の会話型システム（すなわち、純粋にボイスのＩ／Ｏを備えたシステム、またはボイスＩ／Ｏを備えたマルチモーダル・システム）は、通常、適したアーキテクチャおよび十分な処理力を有するパーソナル・コンピュータ（ＰＣ）およびローカル・計算機に限られている。一方、テレフォニー・アプリケーションでは、会話型システムは通常、サーバ（例えばＩＶＲサーバ）上にあり、従来型のセルラーホンを介してアクセス可能である。このような会話型システムがますます一般的になりつつあるものの、通常、クライアント側とサーバ側のいずれかで、すべての会話型処理が行われる（例えば、すべての構成は完全にローカルであるか、または完全にクライアント／サーバである）。
【０００３】
パーベイシブ・コンピューティングの出現に伴い、莫大な数の低リソース・クライアント装置（例えばＰＤＡ、スマートホンなど）が相互にネットワーク化されることが予想される。これらのクライアント装置のサイズが小さくなり、ユーザがこのような装置に行わせようと思うタスクが複雑になってきているせいで、ユーザ・インタフェース（ＵＩ）がクリティカルな問題となってきている。というのは、このような小さいクライアント装置上の会話型グラフィカル・ユーザ・インタフェース（ＧＵＩ）は、実用的ではないからである。この理由で、純粋に音声／オーディオのＩ／Ｏ、または音声／オーディオＩ／Ｏを備えたマルチモーダルＩ／Ｏを提供するには、会話型システムがユーザ・インタフェースの鍵の要素となることが予想される。
【０００４】
したがって、携帯クライアント装置における音声組込み会話型アプリケーションが開発されており、成熟しつつある。残念ながらリソースが限られているせいで、このようなクライアント装置は、複雑な会話型サービス、例えば、音声認識（特に語彙サイズが大きいかまたは専門化されているとき、あるいはドメイン特有／アプリケーション特有の言語モデルまたは文法が必要とされるとき）、ＮＬＵ（自然言語理解）、ＮＬＧ（自然言語生成）、ＴＴＳ（テキスト音声合成）、オーディオ取込みおよび圧縮／解凍、再生、ダイアログ生成、ダイアログ管理、話者認識、トピック認識、およびオーディオ／マルチメディア索引付けおよび探索などを行えない場合があることが予想される。例えば、装置のメモリおよびＣＰＵ（ならびに他のリソース）の制限により、そのような装置が提供できる会話型能力が制限される可能性がある。
【０００５】
さらに、ネットワーク化された装置にこれらの会話型タスクすべてを実行するのに十分な「力」が（ＣＰＵおよびメモリの点で）あったとしても、その装置は、適切なタスクを行うための適切な会話型リソース（例えばエンジン）または会話型引き数（すなわちエンジンによって使用されるデータ・ファイル）（文法、言語モデル、語彙ファイル、構文解析、タグ、声紋、ＴＴＳ規則など）を有しない場合がある。実際、いくつかの会話型関数は、所与のサービスについてあまりに特有かつ固有で、そのためネットワーク上の他の装置または計算機からしか入手可能でないバックエンド情報を必要とするものもある。例えば、クライアント装置上でのＮＬＵサービスおよびＮＬＧサービスは通常、サーバ側の補助を必要とする。というのは、ダイアログを生成するのに必要な会話型引き数または会話型関数の完全なセット（例えばパーサ、タガー、変換機構など）が、格納用メモリ（クライアント装置中で利用可能でない）を大量に必要とするか、またはクライアント側に転送するには大きすぎる（通信帯域幅の点で）からである。この問題は、クライアント装置またはローカル・アプリケーションの有するメモリまたは処理力が、複数言語で音声を処理し会話型関数を実施するのに必要な引き数を格納および処理するには不十分なとき、マルチリンガル・アプリケーションによってさらに悪化する。この代わりにユーザは、このようなタスクを行うためにリモート・サーバに手動で接続しなければならない。
【０００６】
クライアントとサーバの間の分散アーキテクチャおよび分散処理に関連する問題はまた、会話型ネットワーキングの新しい方法も必要とする。このような方法は、ネットワークにわたって分散したトラフィックおよびリソースを管理して、ネットワークにわたる会話型対話において各ユーザに対して適切なダイアログ・フローを保証することを含む。
【０００７】
【発明が解決しようとする課題】
したがって、ネットワーク化されたリソースをユーザにトランスペアレントな形で使用して、限られたリソースを有するネットワーク装置が複雑かつ特有な会話型タスクを行えるようにするシステムおよび方法が非常に望ましい。
【０００８】
【課題を解決するための手段】
本発明は、ネットワーク接続されたサーバおよび装置（およびそれらに対応するアプリケーション）の間で会話型リソースを共用することを実現するためのシステムおよび方法を対象としたものである。本発明の一実施形態によるシステムは、会話型ネットワーク・プロトコル（またはメソッド）を使用してメッセージを通信することによって相互を「会話型に認識している」ようになる、ネットワーク化された複数のサーバ、装置、またはアプリケーション、あるいはそれらすべてを含む。会話型ネットワーク・プロトコル（またはメソッド）は、会話型に認識している各ネットワーク装置が会話型リソースを共用することを可能にし、したがって、ネットワーク装置のうちの１つのインタフェースを介してシームレスな会話型インタフェースを提供する。
【０００９】
本発明の一態様によれば、会話型リソースを共用することを実現するためのシステムは、
少なくとも第１および第２のネットワーク装置を含むネットワークを含み、
第１および第２のネットワーク装置はそれぞれ、
会話型リソースのセットと、
会話を管理し、会話型サービスを要求する呼出しを実行するためのダイアログ・マネージャと、
ネットワークを介し会話型プロトコルを使用してメッセージを通信するための通信スタックとを備え、会話型プロトコルによって通信されるメッセージは、第１および第２の装置それぞれに要求された会話型サービスを実施するのに必要なとき、それらのダイアログ・マネージャ間でネットワーク通信を確立して、第１および第２のネットワーク装置の会話型リソースのセットを共用する。
【００１０】
本発明によれば、低リソースのクライアント装置がトランスペアレントに、単純なタスクをローカルで行い、かつ、複雑なタスクを、より複雑な会話型能力を有するサーバ（または他の装置）とのバイナリ接続またはアナログ接続で行うことができる。サーバ側の関数（音声認識など）は、通常のＩＰネットワークまたはＬＡＮネットワークを介して実施することができ、かつ、従来型の電話回線、またはパケット交換ネットワークを介したディジタル伝送を介して実施することができ、あるいは、無線ネットワークを介した従来型の無線データ・プロトコルのいずれかを介して実施することもできる。
【００１１】
本発明は有利にも、限られたＣＰＵ、メモリ、および電力の能力（ならびに限られた会話型リソース）で、成熟した会話型ユーザ・インタフェースまたは任意の装置（パーベイシブ組込み装置など）を提供する。これは、例えば必要な会話型引き数をネットワーク・サーバからダウンロードする必要なしに、低リソースのクライアント装置を使用して複雑な会話型サービスを提供する。ローカル能力により、ユーザは、例えば無線電話プロバイダの受信可能範囲外で、接続を必要とせずにローカル装置を利用することができる。継続接続のコストもまた削減され、そのような継続接続が失われたときの復旧の難しさも軽減することができる。
【００１２】
【発明の実施の形態】
本発明が様々な形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、またはこれらの組合せにおいて実装できることを理解されたい。好ましくは、本発明はプログラム命令を含むアプリケーションとしてソフトウェア中に実装され、このプログラム命令は、プログラム記憶装置（例えば磁気フロッピー・ディスク、ＲＡＭ、ＣＤ−ＲＯＭ、ＲＯＭ、およびフラッシュ・メモリ）上に実体として組み込まれ、１つまたは複数の中央演算処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、およびオーディオ入出力（Ｉ／Ｏ）インタフェースなどの適したアーキテクチャを備えた任意の装置や計算機で実行することができる。
【００１３】
添付の図面に示す要素システム・コンポーネントおよび方法ステップのいくつかはソフトウェア中に実装することが好ましいため、システム・コンポーネント（またはプロセス・ステップ）間のつながりは、本発明をプログラミングする仕方に応じて実際のつながりとは異なる場合があることもさらに理解されたい。当業者なら、本明細書の教示があれば、本発明のこれらおよび類似の実施態様または構成を企図することができるであろう。
【００１４】
ここで図１を参照すると、本発明の例示的な実施形態による、ネットワーク化された装置間で会話型リソースおよび会話型引き数（データ・ファイル）を共用することによって会話型サービスを提供するためのシステムがブロック図に示されている。このシステムは、オーディオ／音声入力を処理するため、およびクライアント装置１００によって生成されたオーディオ／音声を出力するための音響フロントエンド１０１を備えたローカル・クライアント装置１００を備える。クライアント装置１００は、例えばスマートホンまたは任意の音声使用可能ＰＤＡ（personal digital assistant）とすることができる。クライアント装置１００はさらに、音響フロントエンド１０１によって生成されたかまたは取り込まれた、あるいはその両方がなされた音響特徴または波形あるいはその両方を処理するため、およびユーザに出力するダイアログを生成するための、１つまたは複数のローカル会話型エンジン１０２も含む。ローカル会話型エンジン１０２は、例えば、組込み音声認識、話者認識エンジン、ＴＴＳエンジン、ＮＬＵおよびＮＬＧエンジン、オーディオ取込みおよび圧縮／解凍エンジン、ならびにその他任意のタイプの会話型エンジンを含むことができる。
【００１５】
クライアント装置１００はさらに、ローカル・ダイアログ・マネージャ１０３も備え、このローカル・ダイアログ・マネージャ１０３はタスク管理を行い、システム呼出し（ＡＰＩまたはプロトコル呼出し）を介して要求された会話型サービスを（ローカルで、またはネットワーク装置を介して）実行すること、ならびにローカルで、かつネットワーク化された装置によってダイアログを管理することの制御および調整をする。より具体的には、以下により詳細に説明するようにダイアログ・マネージャ１０３は、所与の会話型サービスをクライアント１００上でローカルに処理および実行すべきか、あるいはネットワーク接続されたリモート・サーバ（または装置）上で処理および実行すべきかを決定する。この決定は、他のネットワーク化された装置の能力と比較したクライアント１００の会話型能力、ならびに要求された会話型サービスを処理するのに必要な可能性のある利用可能なリソースおよび会話型引き数などのファクタに基づく。その他のファクタには、ネットワーク化された装置から結果を受信する際のネットワーク・トラフィックおよび予期される遅延が含まれる。ダイアログ・マネージャ１０３は、負荷管理やリソース割振りなどのタスク管理およびリソース管理のタスク、ならびにローカル会話型エンジン１０２と音声使用可能ローカル・アプリケーション１０４との間のダイアログ管理を行う。
【００１６】
一例として図１に示すように、クライアント装置１００は、ネットワーク１０５を介してサーバ１０６にネットワーク接続され、このサーバ１０６は、必要に応じてクライアント装置１００（あるいはいずれか他のネットワーク装置またはアプリケーション）に会話型サービスを提供するためのサーバ・アプリケーション１０９ならびにサーバ会話型エンジン１０７を含む。ローカル・エンジン１０２と同様、サーバ・エンジン１０７は、例えば組込み音声認識、ＴＴＳエンジン、ＮＬＵおよびＮＬＧエンジン、オーディオ取込みおよび圧縮／解凍エンジン、ならびにその他任意のタイプの会話型エンジンを含むことができる。サーバ１０６は、前述のローカル・ダイアログ・マネージャ１０３と同様の仕方で動作するサーバ・ダイアログ・マネージャ１０８を備える。例えば、サーバ・ダイアログ・マネージャ１０８は、会話型サービスを求めるローカル・ダイアログ・マネージャ１０３からの要求がサーバ１０６によって処理および実行されるべきか、あるいはネットワーク接続された別のリモート・サーバまたは装置上で処理および実行されるべきかを決定する。さらに、サーバ・ダイアログ・マネージャ１０８は、サーバ会話型エンジン１０７と音声使用可能サーバ・アプリケーション１０９との間のダイアログを管理する。
【００１７】
図１のシステムにはさらに、クライアント装置１００およびリモート・サーバ１０６がサーバ１１０にネットワーク接続されているのが示されており、このサーバ１１０は、クライアント１００およびサーバ１０６から必要に応じてアクセス可能な会話型エンジンまたは会話型引き数、あるいはその両方を有する。ネットワーク１０５は、例えばインターネット、ＬＡＮ（ローカル・エリア・ネットワーク）、団体イントラネット、ＰＳＴＮ（公衆交換電話網）、または無線ネットワーク（ＲＦ（無線周波）を介した無線通信の場合）、またはＩＲ（赤外線）とすることができる。図１にはクライアント／サーバ・システムを示してあり、この用語は当業者には理解されているが、図１のシステムは、会話型関数、引き数、およびリソースを共用することを実現するように、相互を「会話型に認識している」ネットワーク化された複数のサーバ、装置、およびアプリケーションを含むことができることを理解されたい。以下により詳細に説明するが、このような「会話型の認識」は、会話型ネットワーク・プロトコル（またはメソッド）を使用して、メッセージを送信し、それらのメッセージをそれぞれのダイアログ・マネージャによって処理して、ネットワーク化された装置が会話型リソースおよび関数を共用できるようにすることによって達成される。このような会話型調整は、１つのネットワーク装置のインタフェースを介してリモートのサーバ、装置、およびアプリケーションにアクセスするためのシームレスな会話型インタフェースを提供する。
【００１８】
具体的には、ネットワーク化された装置間で会話型調整を実現してそれらの会話型関数、リソース、および引き数を共用するために、ネットワーク化された各装置は、会話型プロトコル（またはメソッド）を使用してメッセージを通信し、それらの会話型能力および要件に関する情報を交換する。例えば図１に示すように、クライアント装置１００は、会話型プロトコル１１２、会話型発見／登録／折衝プロトコル１１３、および音声伝送プロトコル１１４（または会話型コーディング・プロトコル）を使用してメッセージを送受信するための通信スタック１１１を備える。同様に、サーバ１０６も、会話型プロトコル１１６、会話型発見／登録／折衝プロトコル１１７、および音声伝送プロトコル１１８を有するサーバ通信スタック１１５を備える。
【００１９】
簡潔に言うと、会話型プロトコル１１２、１１６は、ネットワーク化された装置（例えばクライアント１００およびサーバ１０６）またはアプリケーションが、それらの会話型状態、引き数、およびコンテキストを他のネットワーク装置のダイアログ・マネージャに登録するためのメッセージを送信できるようにするプロトコル（またはメソッド）である。会話型プロトコル１１２、１１６はまた、アプレットや、ＡｃｔｉｖｅＸコンポーネントや、装置または関連アプリケーションがマスタ／スレーブまたはピア・ツー・ピアの会話型ネットワーク構成においてそのような装置間の会話を調整できるようにするその他の実行可能コードなど、他の情報も装置が交換できるようにする。分散会話型プロトコル１１２、１１６は、マスタ／スレーブ会話型ネットワーク、ピア会話型ネットワーク、サイレント・パートナーを含めた、複数の装置またはアプリケーションに関係する会話を調整するための情報の交換を可能にする。ネットワーク化された装置間で分散会話型プロトコルを使用して交換できる情報には、データ・ファイル（引き数）へのポインタ、データ・ファイルおよびその他の会話型引き数の転送（必要なら）、入力に関する通知、出力イベントおよび認識結果、会話型エンジンＡＰＩ呼出しおよび結果、状態およびコンテキストの変化とその他のシステム・イベントの通知、登録更新、登録のためのハンドシェーク、折衝更新、折衝のためのハンドシェーク、および要求されたリソースが紛失したときの発見更新が含まれる。
【００２０】
（分散）会話型プロトコルはまた、ダイアログ・マネージャがサービス、挙動および会話型アプリケーション、Ｉ／ＯおよびエンジンＡＰＩを分散できるようにする、ダイアログ・マネージャ（ＤＭ）プロトコルも含む。例えば、ＤＭプロトコルは以下の情報を交換できるようにする。すなわち、（１）ＤＭアーキテクチャ登録（例えば各ＤＭはローカルＤＭの集合とすることができる）、（２）関連メタ情報（ユーザ、装置能力、アプリケーション・ニーズなど）へのポインタ、（３）ＤＭネットワーク・トポロジ（例えばマスタ／スレーブ、ピア・ツー・ピア）の折衝、（４）適用可能ならば、すなわちマスタＤＭによって制御されるエンジンが使用されているなら、データ・ファイル（会話型引き数）、（５）エンジンへの転送またはコンテキストへの追加あるいはその両方のためのユーザ入力やユーザへの出力などのＩ／Ｏイベントの通知、（６）認識イベントの通知、（７）エンジンからマスタＤＭへの処理済み入力の転送、（８）登録済みＤＭへの、マスタＤＭの責任の転送、（９）ＤＭ処理結果イベント、（１０）ＤＭ例外、（１１）信頼度および不明瞭さの結果、提案されたフィードバックおよび出力、提案された例外状態、提案されたアクション、提案されたコンテキスト変更、および提案された新しいダイアログ状態の転送、（１２）決定通知、コンテキスト更新、アクション更新、状態更新など、（１３）完了した、失敗した、または中断されたアクションの通知、（１４）コンテキスト変更の通知、または（１５）アクションによる、データ・ファイル、コンテキスト、および状態の更新であり、あるいはこれらすべてである。
【００２１】
例えば、マスタ・スレーブ・ネットワーク構成では、ネットワーク化された装置のうち１つだけが、いずれか所与の時に会話を駆動する。具体的には、マスタ装置（すなわちマスタ装置のダイアログ・マネージャ）が、ネットワーク装置間の会話を管理および調整し、どの装置が所与の会話型サービスまたは会話型関数を実施することになるかを決定する。この決定は、各装置または各アプリケーションから提供されたそれらの会話型能力に関する情報に基づくことができる。この決定はまた、どのスレーブ装置（必要な会話型能力を有する）が最適に所与の会話型関数を実施できるかをマスタが決定することに基づくこともできる。例えばマスタは、音声認識を行ってその結果をマスタに提供するよう複数のスレーブに要求することができる。次いでマスタは、最適な結果を選択することができる。本明細書において音声認識のレベルで述べるものは、分散ダイアログ・マネージャ間のＤＭ（ダイアログ・マネージャ）プロトコルのレベルの機構であることを理解されたい。実際、複数のダイアログ・マネージャ間でダイアログが発生するとき、マスタは、各ダイアログ・マネージャの結果スコアの測定値を得ることになり、それに応じ、音声認識の正確度だけでなくダイアログ（意味）、コンテキスト、および履歴（ならびにユーザの選好、履歴、およびアプリケーションの選好など、検討中の他のアイテム）にも基づいて、どのダイアログ・マネージャが入力を続行するかを知るために決定を行うことになる。
【００２２】
ピア・ツー・ピア接続では、各装置が、実施できる関数を決定し、そのようにする要求をログしようとすることになる。このタスクを受け入れた装置は、このようなタスクを行い、次いでその性能のスコアを得る。次いで装置は、それらのスコアに基づいて、どの装置がそのタスクを行うかを折衝する。
【００２３】
一実施形態では、分散会話型プロトコル１１２、１１６は、ＲＭＩ（リモート・メソッド呼出し）またはＲＰＣ（リモート・プロシージャ呼出し）システム呼出しを介して実施されて、アプリケーションおよび様々な会話型エンジンの間でネットワークを介して呼出しを実施する。当技術分野で周知のように、ＲＰＣは、あるアプリケーションがネットワークを横断して別のアプリケーションにサービスを要求できるようにするプロトコルである。同様に、ＲＭＩは、分散ネットワーク中でオブジェクトがそれによって対話できるメソッドである。ＲＭＩにより、１つまたは複数のオブジェクトを要求と共に渡すことができる。さらに、情報は、ＣＯＲＢＡまたはＤＣＯＭを介して交換されるオブジェクトに格納するか、または宣言型で（ＸＭＬを介するなどによって）呈示することができる。ＣＶＭ（会話型仮想計算機）シェルによってサポートされる会話型関数を、会話型ＡＰＩを介して会話型アプリケーションとＣＶＭシェルとの間で分散実装すること、または会話型エンジンＡＰＩを介してＣＶＭと会話型エンジンとの間で分散実装することを達成するために、会話型プロトコル（メソッド）（または分散プロトコル）を使用することができる。会話型エンジンＡＰＩは、コア・エンジンおよびそれらを使用するアプリケーションと、コア・エンジン（ローカルのまたはネットワーク化された、あるいはその両方の）と通信するためのプロトコルとの間のインタフェースである。会話型ＡＰＩは、会話型に認識しているアプリケーションをフック（hook）するかまたは開発するためのＡＰＩレイヤを提供し、このＡＰＩレイヤは、会話型ユーザ・インタフェースを構築するための土台のクラスおよびコンポーネントを含む。
【００２４】
同様に、本発明によるダイアログ・マネージャは、ＡＰＩを介してアプリケーションおよびエンジン（ローカルのまたはネットワーク化された、あるいはその両方の）と通信することができる。このようにしてダイアログ・マネージャは、あたかもローカル・アプリケーションであるかのようにすべてのリモート・プロシージャ（リモート・エンジンおよびリモート・アプリケーションへの手続き型呼出し）からの結果およびコール・バックに作用し、それにより、例えばアプリケーションおよびリソース（ローカルのまたはネットワーク化された、あるいはその両方の）の間を調停して、アクティブなアプリケーションを優先順位付け、決定し、どの結果をアクティブとみなすかを決定することができる。
【００２５】
会話型発見／登録／折衝プロトコル１１３、１１７は、ローカル・システムまたは会話型に認識しているネットワーク・システム（すなわち会話型プロトコルを「話す」アプリケーションまたは装置）を「発見」するのに使用されるネットワーク・プロトコル（またはメソッド）である。登録プロトコルは、装置またはアプリケーションがそれらの会話型能力、状態、および引き数を登録できるようにする。折衝プロトコルは、装置がマスタ・スレーブ、ピア・ツー・ピア、またはサイレント・パートナーのネットワークを折衝できるようにする。
【００２６】
一実施形態では、発見プロトコルは、「ブロードキャストおよびリッスン」手法を実装して、他の「ブロードキャストおよびリッスン」装置からのリアクションをトリガする。これにより、例えば、動的かつ自発的なネットワーク（以下に考察するBluetoothネットワークおよびホッピング・ネットワークなど）を生み出すことができる。別の実施形態では、異なるネットワーク装置の「アドレス」を登録するデフォルト・サーバ（おそらくはマスタ）設定を使用することができる。この実施形態では、発見は、ネットワーク中の各装置がサーバと通信して、そのような装置にどの装置が接続するかを決定するために登録済み装置のリストをチェックすることである。発見プロトコルを介して交換される情報は、以下の通りである。すなわち、（１）ハンドシェークまたは要求のリッスンに対するブロードキャスト要求、（２）装置識別子の交換、（３）最初の登録に対するハンドル／ポインタの交換、および（４）最初の折衝に対するハンドルの交換である。
【００２７】
登録プロトコルを実施する場合の一実施形態では、接続時、装置は、フラグのセットまたは装置特性オブジェクトを交換することにより、それらの会話型能力に関する情報を、事前構成済みのプロトコル（例えばＴＴＳ英語、任意のテキスト、音声認識、５００ワード＋ＦＳＧ文法、話者なし認識など）で交換することができる。同様に、アプリケーションもエンジン要件リストを交換することができる。マスタ／スレーブのネットワーク構成では、マスタ・ダイアログ・マネージャが、すべてのリストを編集し、関数およびニーズを会話型能力とマッチさせることができる。マスタ装置（ダイアログ・マネージャ）がない場合は、共通サーバを使用して、ネットワーク中の各計算機または装置に会話型情報を送信することができる。登録プロトコルによれば、以下の情報を交換することができる。すなわち、（１）定義および更新イベントを含めた、能力および負荷メッセージ、（２）エンジン・リソース（所与の装置がＮＬＵ、ＤＭ、ＮＬＧ、ＴＴＳ、話者認識、音声認識、圧縮、コーディング、記憶などを含むかどうか）、（３）Ｉ／Ｏ能力、（４）ＣＰＵ、メモリ、および負荷能力、（５）データ・ファイルのタイプ（ドメイン特有、辞書、言語モデル、言語など）、（６）ネットワーク・アドレスおよび機能、（７）ユーザに関する情報（定義および更新イベント）、（８）装置、アプリケーション、またはダイアログに対するユーザ選好、（９）カストマイズ、（１０）ユーザ経験、（１１）ヘルプ、（１２）アプリケーション（およびアプリケーション状態）ごとの能力要件（定義および更新イベント）、（１３）ＣＵＩサービスおよび挙動（ヘルプ・ファイル、範疇、会話型優先度など）に関するメタ情報（定義および更新イベント、通常はテーブルへのポインタを介する）、（１４）プロトコル・ハンドシェーク、または（１５）トポロジ折衝、あるいはこれらすべてである。
【００２８】
登録は、ＴＣＰ／ＩＰ、ＴＣＰ／ＩＰ２９、Ｘ−１０またはＣＥＢｕｓなどの従来の通信プロトコル、および装置間のソケット通信を使用して行うことができる。装置は、分散会話型アーキテクチャを使用して、それらに関連する会話型エンジンおよびダイアログ・マネージャに、それらの会話型引き数（例えばアクティブな語彙、文法および言語モデル、構文解析および変換／タグ付けモデル、声紋、合成規則、ベースフォーム（発音規則）、ボイス・フォント）を通信する。この情報は、ダイアログ・マネージャおよび会話型エンジンへのファイルまたはストリームとして、あるいはＵＲＬとして渡される。さらに、装置またはアプリケーションのコンテキスト・スタック／履歴を示すか渡すか指すことによってコンテキスト情報を送信することもでき、コントローラはそれにアクセスしてそのコンテキスト・スタックに追加することができる。装置はまた、それらのマルチモーダルＩ／ＯおよびＵＩの能力（画面／画面なし、オーディオ・イン／アウト機能、キーボードなど）に関する情報も渡す。会話型引き数により、ダイアログ・エンジンは、現在の状態およびコンテキストに基づいてＮＬＵエンジンによる新しい照会の関連性を推定することができる。
【００２９】
折衝プロトコルに関しては、ネットワーク装置およびアプリケーションは、各ネットワーク装置のニーズおよび能力の登録時に、折衝中の所与の一時構成を主張することができる。アプリケーションによって構成（すなわちトポロジ）が強いられる場合は、この決定が強いられる。そうでない場合は、マスタまたはスレーブまたはピアになることを要求することができる。要求の計数に基づいて、好ましい構成が決定され、（各装置／アプリケーションが保持する利用可能なリソースのテーブル中にある）すべての装置およびアプリケーションに通信される。システムは、その状態及び要件を変更するときは常に、ネットワーク化された他のダイアログ・マネージャ／リソースに通信して、新しい折衝を開始し、新しい状態およびコンテキスト情報を通信する。
【００３０】
音声伝送プロトコル１１４、１１８は、装置が圧縮音声またはローカル処理結果をネットワーク上の他の装置およびアプリケーションとの間で送受信できるようにする。会話型エンジン１０２、１０７は、音声（または結果）を送信用に圧縮するため、および、ネットワークを介して別の装置またはアプリケーションから得られた圧縮音声（または結果）をローカル処理用に解凍するための圧縮／解凍エンジンを含むことが好ましい。音声伝送プロトコルは、処理に向けてネットワーク化された他の装置、システム、またはアプリケーションとの間で圧縮音声を送受信するために、装置中で実行される音声伝送クライアントによって利用される。装置の音声伝送クライアントは、ネットワークを介して伝送される音声を処理するのに適した圧縮ハードウェアを使用して、圧縮、解凍、および再構築のエンジンと共に動作する。音声コーダが、圧縮音声を知覚的に許容できるかまたは理解できるように再構築すること、および会話型性能（例えば単語エラー率）を最適化することを可能にする。音声は、ネットワーク化されたそれぞれの装置上で、音響信号処理エンジン（オーディオ・サブシステム）および適したオーディオ・ハードウェアを使用して取り込まれる（かつ、特徴に変形される）。さらに、音声を処理するために、圧縮音声ファイル・フォーマットを装置間で送受信することもできる。より具体的には、音声伝送プロトコルは、装置が圧縮音声またはローカル処理結果をネットワーク上の他の装置およびアプリケーションとの間で送受信できるようにする。一実施形態では、送信装置と受信装置との間のハンドシェーク・プロセスの後、データ・ストリーム(パケット・ベース)が受信側に送信される。パケット・ヘッダが、音声（または結果）をエンコードするためのコーディング方式およびコーディング引き数（すなわちサンプリング周波数、特徴特性、次元、フロントエンドに加えられる変形、フロントエンドの性質など）を指定することが好ましい。さらに、誤り訂正情報（例えば、直前のパケットが紛失したか遅延した場合に差動デコーダを訂正するための、直前パケットの最後の特徴ベクトル）、または紛失したパケットを回復（再送）するための適切なメッセージングを導入することもできる。
【００３１】
また、ダイアログ・マネージャは、ダイアログ・マネージャ・プロトコルすなわちＤＭプロトコルを介して通信することができる。ＤＭプロトコルを使用して、どのダイアログ・マネージャがアクティブか、またはどのダイアログ・マネージャが入力を受け取るべきかを複数のダイアログ・マネージャ間で折衝する。ここでの場合、サーバ・リソースは本当に必要なときだけ「ポーリング」されるので、ＤＭプロトコルは変形形態を形成する。すなわち、ローカル・ダイアログ・マネージャは推測的に（アプリオリ）に、その関数をリモートで実施すべきかどうかを決定しようとする。間違いや疑問がある状況で、ダイアログ・マネージャはローカル・エンジンからの推測を待機し、疑問が残る場合に比較するためにサーバをポーリングすることを決定することができる。
【００３２】
したがって上の考察に基づけば、ネットワーク・プロトコルが、会話型サービスおよび会話型関数を共用するために調整（または調整されたインタフェース）をネットワーク化された装置間で可能にすることが明らかになるはずである。調整されたインタフェースという用語は、異なるアクター（装置／アプリケーション）すべてが、あたかも会話全体を理解しており、いずれか所与の時間にどれが対象とされているかが適切に分かっているかのように、それらの間で単一の会話を保持できることを意味する。各会話型システムまたはアプリケーションの挙動は、ダイアログ・マネージャ（例えばマスタ・スレーブ・モードでのマスタ）、アプリケーション（どれがマスタ、スレーブ、またはピアかを確定できるもの）、システム・ダイアログ・マネージャ（もしあれば）、アーキテクチャおよび折衝（ピア・ツー・ピア・モードで）によって制御／管理して、各会話型関数を適切なシステム上で、ユーザにはトランスペアレントに実行することができる。いくつかの会話型関数、システム、およびリソースがいくつかのネットワーク化装置（例えばセルラーホン、ページャ、ＰＤＡ）に備わっている可能性があるにもかかわらず、クライアント装置のユーザにはシームレスな会話型インタフェースが提供される（すなわち、すべての会話型対話が単一の会話型システムを介しているように見える）。
【００３３】
調整された会話型システムの一例は、ＵＣＡ（汎用会話型アプライアンス）と呼ばれるリモート制御装置である。ＵＣＡは、会話型に認識しているアプライアンスを発見する。会話型に接続された各アプライアンスは、その会話型引き数（語彙および文法）をＵＣＡに送信することになる。ＵＣＡは、このようなアプライアンスに対するマスタとして働き、ユーザによる会話型対話がそのアプライアンスへのコマンドとなったときに適切なアプライアンスを更新する。反対に、コマンドの実行時、またはアプライアンスが状態を変更した時ごとに、アプライアンスはリモート制御装置に更新を送信する。他の会話型能力を（対応する引き数以外に）有しない会話型アプライアンスは、いわゆる「サイレント・パートナー」である。
【００３４】
別の実施形態では、サーバまたは基地局が、リモート制御装置（すなわちＵＣＡ）によって実施されるオーディオ取込み／圧縮／シッピングを除いたすべての会話型関数を実施することができる。リモート制御装置はまた、いくつかのＵＩをユーザに提供して、異なるアプライアンスの状態をユーザに知らせることもできる。これは、音声、ＧＵＩ、あるいはこれらのモーダル性（またはその他）の会話型組合せのいずれかを介して行うことができる。
【００３５】
会話型ネットワーク・トポロジは図１のシステムに関して採用することもできるが、好ましいネットワーク・トポロジは、自発的な動的ネットワーキング（すなわち、ある通信範囲内の装置間で自発的に構築されるネットワーク）を実現するものである。このような自発的ネットワーキングは、現在登場しつつある「Bluetooth」ネットワーキング・プロトコルを使用して実施することができ、Bluetoothについては、例えばhttp://www.bluetooth.comに記述されている。簡潔に言えば、Bluetoothとは、その場限りの無線ネットワーク接続性を実現するネットワーク・プロトコルに対するコードネームである。より具体的には、Bluetoothは、特定の範囲内にある装置（スマートホン、セルラーホン、ページャ、ＰＤＡ、ラップトップ・コンピュータ、モバイル・ユニットなど）の間で短距離無線リンクを実現して、そのような装置間で動的かつ自発的にネットワーク（またはいわゆる「ピコネット」）を確立するプロトコルである。ピコネットとは、ネットワーク接続の残りの間でマスタとして働く各ピコネット中の１つのノードとその場限りの形で接続されたBluetooth使用可能装置（ノード）の集合を言う。２つ以上のピコネットをネットワーク接続すると、いわゆるスキャタネット（scatternet）を形成することができる。
【００３６】
本発明によれば、自発的な動的ネットワーキング・プロトコルならどれでも実装できることを理解されたい。例えば、「ホッピング」通信ネットワークに従って実装することができる。
【００３７】
次に図２を参照すると、本発明の一態様による、ネットワーク化された装置間で会話型関数を共用することを実現する方法を流れ図に示してある。具体的には、図２には、図１のシステムの動作方法の１つをより詳細に示してある。最初に、例えばディジタル化音声信号の関連特徴をディジタル化し抽出することによって事前処理されたローカル・クライアント装置に、ユーザが音声コマンドを言う（または他の方法で照会を発行する）（ステップ２００）。あるいは、ローカル・ダイアログ・マネージャが、ユーザに出力するための合成音声（ＴＴＳ）を生成する要求をローカル・アプリケーション１０４から受け取ることもできる（ステップ２００）。
【００３８】
ローカル処理が利用可能かどうか、例えば音声認識または音声合成がローカルで行えるかどうかについての判定が（ローカル・ダイアログ・マネージャ１０３を介して）なされる（ステップ２０１）。この判定のために、ローカル・ダイアログ・マネージャ１０３は、認識／合成を行わなければならないリモート・サーバを明示的に事前定義できることを理解されたい（例えば、ソケット接続用のＩＰアドレス、サーブレットを介したサーバ・ベースの記録用のＵＲＬアドレス、あるいは直接接続用またはＩＶＲへの接続用の電話番号）。さらに、タスクを行う（または効率的に行う）ための利用可能なリソースまたは引き数をローカル装置が有しないという判定を、アプリケーションによってヘッダ・ファイル中に示されるリソース要件に基づいて、ローカル・アプリケーション１０４の実行時にダイアログ・マネージャ１０３によって行うこともできる。さらに、あるコマンドまたは要求された関数で、ダイアログ・マネージャをリモート・サーバに接続させることもできる。例えば、セキュリティ・アプリケーション（例えば話者検証）をサーバ側処理に切り替え、声紋がクライアントに配信されないようにすることができる。さらに、ローカルのカー・ナビゲーション・システムを、電話またはソケット・ベースのサーバを使用してリモート・サーバ側に切り替え、ローカル装置が大量のナビゲーション情報を記憶しなくてもよいようにすることもできる。
【００３９】
ローカル処理が利用可能だと判定された場合（ステップ２０１で肯定判定）、処理は、ローカル・エンジン１０２を介してローカルで行われる（ステップ２０２）。一方、ローカル処理が利用可能でないと判定された場合（ステップ２０１で否定判定）、関連する特徴／波形／情報が、ネットワーク接続されたリモート・サーバに（ＩＰ、ＬＡＮ、Bluetooth、ＩＲ、ＲＦを介して、あるいは電話またはＩＰ電話を介して）送信され（ステップ２０４）、そこで、（おそらくはいくつかのユーザ／サーバ対話によって）リモート処理（例えば音声認識／合成）が行われる（ステップ２０５）。
【００４０】
ローカル・クライアントからネットワーク接続されたリモート・サーバへの音声の送信（またはその逆）は、様々な技術を使用して行えることを理解されたい。例えば、波形をファイル、ストリーム、またはパケットのストリームとして直接送信することができる。また、ＡＤＰＣＭやＡＰＣなどの従来の方法を使用して圧縮波形を送信することもできる。さらに、参照されるG. Ramaswamy他の「Compression Of Acoustic Features For Speech Recognition In Network Environments」Vol. 2、pp.977〜980、Proc. ICASSP、1998に開示されている方法に従って特徴のストリームを送信することもできる。この方法では、受信側での認識（音声認識、話者認識、またはＮＬＵ）はできるが、信号の再構築はできない。また、音声の送信は、圧縮した特徴およびピッチ推定に基づくコーディング方法または方式であって、理解できる再生、さらには快適な再生（再生、訂正、人間による次の処理、またはアーカイブ）に十分な質で音声信号を再構築できるようなコーディング方法または方式なら、どれを使用しても行うことができる。このようなコーディング方式は、認識性能を劣化させずに４ｋｂｉｔｓ／秒と５ｋｂｉｔｓ／秒の間の低さのデータ転送率を実現すべきである。その結果、無線モデムまたは無線データ・リンクを介してでも、バックエンド（サーバ）リソースと対話式の交換をリアルタイムで行うことができる。非常に高品質な再生を実現する同様のコーディング方式を使用した他の方式を採用することもできることを理解されたい。また、受信側での劣化を伴わないサーバ側での認識（音声、話者、ＮＬＵ）と、信号の再構築とを可能にするケプストラ（cepstra）特徴の圧縮およびピッチを可能にする方法ならどれでも本発明に関して利用することができる。この再構築は、後で録音を校正し、誤りを訂正し、あるいはプロセスを人間が監視するために、後でサーバまたはクライアント（ローカルに格納されている場合）から再生するのに有用である。適した圧縮方式（コーディング・プロトコル）ならどれでも使用できることを理解されたい。
【００４１】
圧縮またはコーディングの方式（伝送プロトコルまたはコーディング・プロトコル）は、装置間で異なる可能性があることを理解されたい。例えば、入力音声を（クライアントの）オーディオ取込みシステムからネットワーク化されたリソースに送るためのコーディングは、出力音声（例えばプロンプト、再生、またはＴＴＳ）をネットワーク化されたリソース（サーバ）からオーディオ出力（クライアント）に送るのに使用されるコーディング・プロトコルとは異なる場合がある。実際、前者の場合では、コーディングはサーバ側で良い認識性能を実現するように最適化されるべきであり、再生のための再構築は重要だが劇的に重要ではない。当然、ビット伝送速度（圧縮率）が重要である。ターゲット・ビット伝送速度に達してそれを維持するために、圧縮率におけるトレードオフを堅固さ（エラー率／特徴歪曲）と知覚品質の間で適合させることができる。また、いくつかの方式を選択して、いくつかのチャネルひずみまたはバックグラウンドひずみに堅固さを加えることもできる。一方、後者のタスク（出力信号）では、理解できることすなわち知覚品質と快適さとのために、あるいはボイスまたはオーディオのいくつかの特別な特徴を保存するためにコーディングを最適化すべきである。
【００４２】
ローカル処理（ステップ２０２）またはリモート処理（ステップ２０５）の後、処理の結果が許容できるかどうかについて（ローカル・ダイアログ・マネージャ１０３またはサーバ・ダイアログ・マネージャ１０８を介して）判定がなされる（ステップ２０３および２０６）。処理結果が許容できないと判定された場合（ステップ２０３またはステップ２０６で否定判定）、ローカル・クライアントまたはリモート・サーバは、このような処理を行うことのできるサーバに特徴または波形を（ＩＰ、ＬＡＮ、Bluetooth、ＩＲ、ＲＦを介して、あるいは電話またはＩＰ電話を介した接続を介して）転送する（ステップ２０４またはステップ２０７）。例えば、このような結果が未知であるか誤って認識されたか不明瞭である場合（または各リソース（ローカルまたはサーバ）のダイアログ・マネージャに関連付けられた信頼度基準に基づいて）、音声認識およびＮＬＵの結果の拒否が行われる場合がある。ローカル・システムまたはリモート・システムからサーバ・システムへの自動接続は、ローカル音声デコーダから返された音響およびＬＭ（言語モデル）のスコアのレベルに基づくことができることが好ましい（例えば、これらのスコアが所与のしきい値に満たないと判定されたときにリモート・サーバが接触を受ける）。会話型システムから得られた結果が許容できるか否かを判定する（許容できない場合は別のシステムを考慮する）には、信頼度を、あるいは認識された発話または照会を（ダイアログ中またはダイアログ後に）推定するのに適した基準またはアプローチならどれでも使用できることを理解されたい。
【００４３】
ＴＴＳの場合も同様に、ローカル・ダイアログ・マネージャおよびリモート・ダイアログ・マネージャ１０３、１０８は、テキストの複雑さを調べて、ＴＴＳがローカルで行われるかリモートで行われるかを決定することができる。例えば、語に対する発音規則が未知のとき、またはテキストが複雑な構文解析を必要とするときは、ＴＴＳはリモートで行われる。別の例は、ＴＴＳが異なるアクセント、方言または異なる言語で発音されなければならない場合、あるいは誰かの特定の文を模倣することになっている場合である。
【００４４】
処理がリモートで行われた後、結果がローカル・クライアントに（電話、ＩＰアドレス、ＭＡＣ（メディア・アクセス制御）アドレスなどを介して）送り返される（ステップ２０８）。出力（すなわちユーザへの音声出力）は、ローカルでもサーバ上でも合成できることを理解されたい。サーバ上で合成が行われる場合、合成音声は、ローカルで解凍されるように圧縮形式で（前述の音声伝送プロトコルを使用して）クライアントに送信することができる。コーディング方式は、音声特徴をクライアントからサーバに送信するのに使用された方式と同じでも、異なってもよいことを理解されたい。別法として音声は、クライアントからサーバへの電話呼出し（コールバック）を介して確立できる接続を使用し、例えば別のアナログＰＳＴＮ回線を介してサーバから直接に「ブロードキャスト」することもできる。
【００４５】
最近になり、認識された音声に対する適切な信頼度基準を確立する取組みが始められている。例えば、ＮＩＳＴおよびＤＡＲＰＡによって組織された米国メリーランド州ＭＩＴＡＧＳでの「LVCSR Hub5 Workshop」、１９９６年４月２９日〜５月１日では、各語に信頼度レベルを付けるための様々なアプローチが提案された。ある方法は決定ツリーを使用するもので、この決定ツリーは、語依存特徴（訓練発話の量、最小および平均トライフォン（triphone）発生、言語モデル訓練中の発生、音素／レフィーム（lefeme）の数、継続時間、音響スコア（ファスト・マッチまたは詳細マッチ）、音声非音声）、文依存特徴（信号対雑音比、話す速度の推定すなわち１秒間の語数またはレフィーム数または母音数、言語モデルから提供される文可能性、可能性比率、フレームごとの正規化された平均可能性、言語モデル中のトライグラム（trigram）発生）、コンテキスト特徴における語（言語モデル中のトライグラム発生）、ならびに話者プロファイル特徴（アクセント、方言、性別、年齢、話す速度、識別、音響品質、ＳＮＲなど）について訓練されている。訓練データに対し、ツリーの葉ごとにエラーの確率が計算される。このようなツリーを構築するためのアルゴリズムは、「Classification and Regression Trees」、Chapman & Hal、1993でBreiman他によって考察されている。認識時、これらの特徴のすべてまたはいくつかを認識中に測定し、各語について決定ツリーを葉の方に進み、そこで信頼度レベルが提供される。また、Neti他の引例「Word Based Confidence Measures As A Guide For Stack Search In Speech Recognition」、ＩＣＡＳＳＰ９７、ドイツ、ミュンヘン、１９９７年４月には、ＩＢＭスタック・デコーダから返されるスコアに完全に依拠する方法（ログ可能性、実際には平均増分ログ可能性と、詳細マッチ、ファスト・マッチを使用する）が記載されている。
【００４６】
ＬＶＣＳＲ議事録では、線形回帰を介した予測子を使用する、別の信頼度レベル推定方法も行われている。使用される予測子は、語の継続時間、言語モデル・スコア、フレームごとの平均音響スコア（最良スコア）、および、トップ選択と同じ語を有するＮＢＥＳＴリストの小部分である。本発明の一実施形態によれば、これら２つのアプローチ（決定ツリーを介して測定される信頼度レベルと、線形予測子を介して測定される信頼度レベル）が組み合わさって、音声認識に限らずどんな変換プロセスにおいても信頼度レベルが系統的に抽出されることを理解されたい。
【００４７】
この領域における過去の進歩および発達スピードに基づき、ここで、いくつかの種類の変換で、変換されるコンポーネントに信頼度の値（例えば０から１までの値であって、０は変換が行われず１は確実を意味する）を関連付けることができると言うことができる。コンポーネントは、テキスト、句、語とすることができ、より一般的には、変換する材料のどんな論理ブロックとすることもできる。前述の線形予測子と決定ツリーの結合が、本発明に採用するのが好ましい一方法である。実際、例としては、話者認識エンジンから返されるスコア（ファスト・マッチ・スコアおよび詳細マッチ・スコア、ならびに背景モデルおよびコホートのスコア）の蓄積を使用して、話者が真に正しく認証される信頼度レベルの決定ツリーまたは線形予測子、あるいはその両方を構築することができる。実際のところ、話者識別の場合、これは識別段階で得られた識別に対する検証を行うことになる。
【００４８】
リモート・サーバは、ＴＴＳ規則やベースフォーム、文法などの情報をローカル・クライアントに送信してキャッシュに格納させることができ、したがってローカル装置は、後でこうした情報を使用して同様の要求をローカルで処理できることを理解されたい。ローカル装置は必要なリソースの不足のせいであるタスクを行えない場合があるため、サーバ・ダイアログ・マネージャ１０８は、ローカル装置がリモート・サーバに接続したときにその会話型能力をリモート・サーバに（前述の登録プロトコルを介して）登録するのに基づいて、こうした処理情報をローカル・クライアントに送信する決定を行うことができる。
【００４９】
本発明は、装置が（そのダイアログ・マネージャを介して）実行する会話型関数の量が、それらの関数を適時に実行するのに必要なリソースを装置が提供できないほどの量である状況（例えばシステムによって使用される同時ポートが多すぎるＩＶＲ）で実施できることを理解されたい。したがってダイアログ・マネージャは、会話型システム管理および負荷管理を実現するように実施することができ、それによりダイアログ・マネージャは、特定の関数の実行中に別の会話型システムを利用して、要求された関数の処理を継続することを決定することができる。具体的には図３を参照すると、最初にユーザは、例えばディジタル化音声信号の関連特徴をディジタル化および抽出することによって事前処理されたローカル・クライアント装置に音声コマンドを言うことになる（ステップ３００）。あるいは、ローカル・ダイアログ・マネージャは、ローカル・アプリケーション１０４から要求を受け取って、ユーザに出力するための合成音声（ＴＴＳ）を生成することもできる（ステップ３００）。ダイアログ・マネージャは、ローカル処理が行われるべきかどうかを判定する（例えば音声認識の場合でも、ダイアログ管理の場合でも、音声合成の場合でも）（ステップ３０１）。この判定は、（前述のように）ローカルの会話型能力、引き数、およびリソースだけに依拠するのではなく、利用可能だが制約のあるローカル・リソースを使用して会話型関数を実施する際に導入される可能性のある遅延と比較した場合（ローカル装置とリモート装置が同じ関数を実施できると仮定して）の、ネットワーク・トラフィック輻輳のせいでネットワークが導入するであろう遅延の推定に基づくこともできる。したがって、例えばコマンドおよび制御関数がローカルで／ネットワークを介して遅延される危険にさらされる場合、遅延を最小限に抑えるためにリモートで／ローカルで実行することができる。実際、より長い遅延を扱う可能性のある（例えば、インターネットやオーディオ・ビジュアル探索などの遅延に対応できるバックエンド機能に関連することによる）照会を、リソースまたはコストを最適化する（ローカルのまたはネットワーク化された）システム上で実行することができる。
【００５０】
また、ネットワーク化された接続が一時的に利用不可能になった場合、あるいはネットワーク化されたリソースがない場合は、ローカルで実施できるすべての関数が実施されることになる。その他の関数は、延期モードで（後で接続が再確立されたときに）実行できる関数と、不適合な関数とに細分することができる。代表的な例は、口述を介したアドレス帳の更新、電子メールまたはメッセージへの返事、あるいは口述一般である。この場合もアプリケーションは、コマンドがローカルか、あるいは延期されるかを決定できることが好ましい。延期モードを有するピア・ツー・ピアを考慮することも可能であり、この場合、延期モード・マネージャおよびローカル・エンジンが、関数がローカルか延期されるかを決定する。
【００５１】
再び図３を参照すると、ローカル処理が適切であるとダイアログ・マネージャが判定した場合（ステップ３０１で肯定判定）、ダイアログ・マネージャは、必要な会話型エンジンをポートに割り振ることになる（ステップ３０２）。会話型エンジンをポートに割り振った後で、ダイアログ・マネージャは、元々割り振ったポートによって会話型エンジンが現在使用されていない場合に（例えば話者が現在、聞いているだけで話していないとき）そのエンジンを他のポートに割り振ることができる（ステップ３０３）。そのローカル・エンジンが再び元々割り振ったポートに必要になったときは、そのローカル・エンジンが利用可能でなければ利用可能な別のエンジンを（ローカルでまたはリモート装置上で）利用することができる（ステップ３０４）。この動的割当て処理は、ダイアログ・マネージャが関数呼出しの継続時間全体にわたり会話型エンジンを決定して各ポートに割り振る従来の負荷管理とは対照的である。
【００５２】
例えば音声をネットワーク・サーバまたはネットワーク装置に送信するための管理および決定は、システム管理／負荷平衡（クライアント上またはサーバ上のダイアログ・マネージャによる）のレベルだけでなく、ネットワークのトラフィックに基づくこともできることを理解されたい。例えば、接続（特にインターネットを介したＴＣＰ／ＩＰベースのネットワーク接続）が過負荷であると見なされた場合（ステップ３０５）、トラフィックに基づいて新しいサーバまたは装置を選択することができる（ステップ３０６）。この判定は、ＲＳＶＰ（resource reservation protocol）のような、ＶｏＩＰ（Voice Over Internet Protocol）プロトコルなどの会話型プロトコルの最上部で行うことができ、これにより、チャネルが必要なときに関連するサービス品質を適切に予約して接続することができる。そうでない場合は、前述のようにリモート処理が行われ（ステップ３０７）、その結果が返される。
【００５３】
本明細書に述べるシステムおよび方法を、音声使用可能かつ会話型の様々なアプリケーションで実施できることを理解されたい。本発明は、組込み型でパーベイシブなコンピューティングの世界ならびにＮＬＵ／ＮＬＧダイアログ・システムにおいて増大する要求を満たすのに特に有用である。しかし、本発明が、組込みシステムに限らず様々なアプリケーションに向けて展開できることを理解されたい。以下の例示的な実施形態に、本発明の利点を示す。
【００５４】
例えば、スマートホン（例えばＰＤＡ（personal digital assistant）機能付きの無線電話）で使用するための市販の組込みネーム・ダイヤラが、代表的なアプリケーションである。例えば、クライアント装置１００がネーム・ダイヤラ・ローカル・アプリケーション付きのスマートホンであると仮定する。ユーザは、所望の名前および住所のリストをスマートホンの電子アドレス帳にローカルに格納することになる。次いでユーザは、「．．．（あり得る修飾子（家、職場、セルラーホン））のだれだれ（氏名）に電話する」などのコマンドを言うことができる。コマンドが（ローカル会話型エンジン１０２を介して）認識／理解されると、スマートホンは、アドレス帳の中にある人物に関連付けられた電話番号に（ローカル・アプリケーション１０４を介して）電話をかける。一方、アドレス帳にはないが（したがって認識／理解されないが）より大きな団体（または公衆）の電話帳（リモート・サーバ１０６中に含まれる）の中にはある名前が発せられたときは、その要求を（特徴または波形で）保管して、リモート・サーバ１０６に送信し認識させることができる。次いで、リモート・サーバによって直接に、または適切な情報がリモート・サーバから受信されたときにスマートホンによって、電話がかけられる。別法としてユーザは、最初の段階でリモート・サーバに接続され、電話すべき名前を再要求するかまたはさらに情報を要求するためにダイアログを確立することもできる（ホワイト・ページまたはイエロー・ページのサービス・タイプの場合）。
【００５５】
本発明の別の有用な適用例は、市販のPointCast（http://www.pointcast.com参照）などの個人情報システムであり、これは、所定のユーザ選好に基づいて、ユーザが例えば株相場、ある主題の特定ニュース、およびその主題に関する最新発表情報を得られるようにするものである。本発明によって構築された個人情報システムでは、ユーザが株（例えばＩＢＭ）または主題（例えばケントのグリンピースの生産予想）の情報を得たいと思う場合、ユーザはクライアント装置１００に音声要求を言うことになる。「ＩＢＭ」がローカル語彙（ユーザ・プロファイル）中にある場合は即座にデコードされ、ユーザは、例えば最後の更新（PointCast）で得られた最新の照会を得る。一方、「グリンピース」に関するユーザ要求がローカル・クライアント装置１００によって理解されなかった場合は、この要求は（コンテンツ・プロバイダの）リモート・サーバ１０６に特徴ストリームとして転送され、サーバは、そのような要求をデコードする際により多くのリソースをつぎ込んで関連情報を検索し（これはいずれにしても行われていなければならない）、次いで、そのような情報をローカル・システムに送信することができる。リモート・サーバ・システムが「プッシュ・アプローチ」に従う場合、これは次の更新（例えばPointCast）時に行うことができる。
【００５６】
クライアント装置１００はまた、例えば会話型カー・ナビゲーションを実現するための音声使用可能ＰＶＡ（personal vehicle assistant）とすることもできる。例えば、ユーザがＣＤ−ＲＯＭをシステムと共に使用したくない場合（スペース不足、電力要件、重量、コスト、衝撃への耐性などの理由で）、ユーザは、ユーザが現在いる地域／場所、最近いた地域／場所、およびユーザが移動したい地域／場所に関連する語彙および地図など、限られた情報を格納することを決定することができる。この例では、ユーザ要求がローカルの語彙と地図のセットにマッチしないときは、その要求をリモート・サーバ１０６に送信しデコードして（さらには探索を絞り込むためにユーザにプロンプトを返して）、道程および地図（または地図の更新）を自動車にダウンロードすることができる。この場合も、最初はローカルの道しか必要とされないため、このようなアクションは実質上、ユーザにはトランスペアレントとなる（ダウンロードに費用がかかる場合でも）。
【００５７】
さらに、本発明によってＮＬＵ／ＦＳＧシステムを設計することもでき、したがって、ユーザの要求がＦＳＧ（有現状態文法）を必要とする場合に、その要求がより複雑かつ自然であるためにリモート・サーバに転送して認識させる必要があるのではない限り、その要求をローカルで処理することができる。
【００５８】
団体のネーム・ダイヤラ・サービスは、別の興味深い特徴ももたらす。団体は、その従業員の電話番号のアクティブなデータベースを維持することになる。これらのデータベースは常に最新である。ユーザは、そのローカル情報を団体データベースに同期させることを定期的に選択することができる。これは従来の概念である。しかし、ユーザがネーム・ダイヤラを利用しているときでＴＣＰ／ＩＰを介してサーバに接続する必要があるときに同期を（音声認識段階の間に）とり、それによりローカル・ダイヤル情報が常に更新されているようにするができる。同様に、ユーザがユーザのローカル地図に含まれない新しい場所へのナビゲーションに対する情報を要求したとき、システムは、ユーザが移動したい地域に関する音響情報ならびにナビゲーション情報のセットをローカルＰＶＡ上にダウンロードすることができる。
【００５９】
図１のシステムはまた、会話型ブラウザ・システムと共に実施することもできる。この場合、コンテンツ・プロバイダ（サーバ）から送信される（かつ会話型ブラウザによって処理される）、視覚表示用のＨＴＭＬ（ハイパーテキスト・マークアップ言語）ページに類似した概念のＣＭＬ（会話型マークアップ言語）ページを使用して、ユーザに呈示すべき会話型ＵＩを記述する。この例では、クライアント装置１００のローカル・アプリケーション１０４またはリモート（ＩＶＲ）サーバ１０６のサーバ・アプリケーション１０９、あるいはその両方を会話型ブラウザとすることができる。コンテンツ・プロバイダまたはアプリケーション開発者（またはプロキシ／トランスコーダ）は、すべてのデータをクライアント装置１００に与えてローカルに認識させるのではなく、ユーザが提供すべき所与の項目（例えば、口述を介して埋める、あるフォームまたは自由フォームのＮＬＵまたはＦＳＧ入力）がサーバ１０６上で認識されなければならないと決定することができる（タスクがローカル・リソースには複雑すぎるか、あるいはネットワークを介して非常に多くの情報を送信しなければならなくなるため）。これは例えば、処理を行うことになるサーバを識別するためのＵＲＬ（uniform resource locator）およびタグをＣＭＬファイル中に設けるか、あるいはアプレット、ＡｃｔｉｖｅＸコンポーネント、またはプラグイン（あるいはその変形なら何でも）をＣＭＬページ中にロードすることによってなされる（これは通常、ページの作成者による決定である）。これらのアプレット、ＡｃｔｉｖｅＸコンポーネント、またはプラグインは、オーディオを取り込み、おそらくはいくつかの会話型関数を実施し、それを他の関数のための他の装置に送る。この決定は、トランスコーダおよび登録機構によって行うことができ、それによりブラウザは、ＣＭＬページのフェッチ先であるサーバに対してその能力を明示的に記述する。トランスコーダを使用してブラウザの能力を追加で考慮し、そのような能力にコンテンツを適合させるとき（この能力は会話型プロキシと呼ばれる）、トランスコーダは、この場合にブラウザの能力に基づいてサーバに宛先変更するためのサーバＵＲＬを追加することができる。このような場合、クライアント装置１００によって収集された音声は、波形（圧縮済または未圧縮）として、または特徴のストリームとしてリモート・サーバ１０６またはネットワーク化されたサーバ１１０に送信することができ、そこで認識（またはＮＬＵ／ＮＬＧ）が行われる。次いで、認識結果をクライアント装置１００またはＣＭＬプロバイダ・サーバ（リモート・サーバ１０６）に送り返し、次のアクション・コースまたは次の処理を決定することができる。この場合も前述のように、所与の入力、メニュー・フォーム、またはダイアログを認識するのに使用されるリソース／エンジン／サーバまたはローカル装置のＵＲＬを直接組み込むことのできるアプリケーションによって決定することができる。また本発明は、ＣＭＬページがローカル装置１００のローカル会話型エンジン１０２には複雑すぎるサウンドまたはテキストを再生／合成しなければならない状況でも有用である。複雑すぎる部分は、特徴のストリームまたは圧縮波形として、いずれかの特定サーバ（ＣＭＬページを提供したサーバでも、そうでなくてもよい）から得ることができる。さらに、マルチリンガル・システムに関し、ＣＭＬページが異なる言語に関係する場合、適切な能力を有しないローカル・クライアント装置１００は、会話型関数をその言語で実施するようリモート・サーバに要求することができる。
【００６０】
会話型調整は、会話型ブラウザを有する分散アプリケーションにおいて採用できることを理解されたい。例えば図４を参照すると、分散システムは、プレゼンテーション・サーバ４００と、エンジン・サーバ４０１と、会話型ブラウザ４０３を有するクライアント４０２とを有する。ブラウザ４０３は、ＣＭＬフォームのページをプレゼンテーション・サーバ４００から受け取り、ＣＭＬページを処理する。ＣＭＬページには、どれに音声を送って処理させるかをブラウザ４０３が決定できるようにする情報を含めることができる。エンジン・サーバ４０１上には音声サーバが位置する。ＣＭＬページがエンジン・サーバ４０１による音声処理を必要とすると仮定した場合、ブラウザ４０３は、ＨＴＴＰ（あるいはソケットまたはＲＭＩ）を介して音声サーバに通信して（呼出しを送信して）、音声サーバにオーディオを送り、適切なデータ・ファイル命令およびエンジン呼出しを送ることができる。クライアントのブラウザ４０３は、音声処理を（音声ＡＰＩおよび音声認識エンジン４０５を介して）行うためのいくつかのローカル処理能力を有するものと仮定する。前述のように、ローカル音声処理とサーバ側の音声処理との間の移行は、プレゼンテーション・サーバ４００から受け取ったＣＭＬページによって決定される。この決定は、コンテンツ・プロバイダによって、または装置への適合によってコーディングすることができる（クライアント４０２がそのタスクを行えないと判定し、それを既知のまたは発見したサーバまたはトランスコーダに送信する）。
【００６１】
図５では、ブラウザ４０３は、クライアント４０２からアクセスされるブラウザ・サーバ４０４上に位置する（ブラウザ・サーバ４０４は、クライアント４０２とプレゼンテーション・サーバ４００との間の媒介として働く）。この場合もブラウザ４０３は、ローカル側処理とサーバ側処理のどちらを行うかを決定する。本明細書に述べる会話型コーディングを使用して、オーディオを送ることができる。
【００６２】
本発明によれば、低リソースのクライアント装置がトランスペアレントに、単純なタスクをローカルで行い、かつ、複雑なタスクを、より複雑な会話型能力を有するサーバ（または他の装置）とのバイナリ接続またはアナログ接続で行うことができる。サーバ側の関数（音声認識など）は、通常のＩＰネットワークまたはＬＡＮネットワークを介して実施することができ、かつ、従来型の電話回線、またはパケット交換ネットワークを介したディジタル伝送を介して実施することができ、あるいは、無線ネットワークを介した従来型の無線データ・プロトコルのいずれかを介して実施することもできる。アナログ／ディジタル接続の実施形態は、少なくとも２つのシナリオを記述する。第１には、モデムの等価物を実装したバイナリ接続であり、すべての関数はデータ転送関数である。また、サーバ／分散リソースが関係するとき、システムはテレフォニー・サーバをリソースとして呼び出すことができ、音声がネットワークを介して送信される（波形のデータ、またはその変形であるケプストラなどの代わりに）。このようなシナリオの一例は、ローカル音声認識機能（ネーム・ダイヤラおよびディジット・ダイヤラ）との無線接続であり、これは、ボイスによるインターネット閲覧、株／ミューチュアル・ファンド相場の入手、およびボイスによる銀行取引の実施のような他の機能のためのＩＶＲを備えたテレフォニー・サーバに通常の無線接続を介して接続するものである。この機構は、今日、いくつかの音声認識能力を装置上に搭載した既存のセルラーホンで使用することができる。
【００６３】
さらに、ネットワークを横断する会話型対話の適切なダイアログ・フローを保証するために、様々な機構を使用して、ネットワークにわたって分散したトラフィックおよびリソースを管理することもできる。このような機構には、会話型プロトコル（前述の）、オーディオ：ＲｅｃｏＶＣ（Recognition Compatible VoCoder）（再生のための再構築を可能にするピッチを伴うコーディング・プロトコル）、アプリケーションおよびメタ情報：分散アプリケーション・プロトコル、発見、登録、折衝、ダイアログ・フローを維持するためのサーバ負荷管理、ダイアログ・フローを維持するためのトラフィック平衡およびルーティング、タスク特徴および能力の要件と会話型引き数使用可能性（データ・ファイル）とに基づくエンジン・サーバ選択、会話型引き数配信：記憶、トラフィック／ルーティングおよびキャッシングが含まれる。
【００６４】
例証的な実施形態を添付の図面に関して本明細書に述べたが、本システムおよび方法がこれらの厳密な実施形態に限定されず、当業者なら本発明の範囲または主旨を逸脱することなく他の様々な変形や修正を加えることができることを理解されたい。このような変形および修正はすべて、添付の特許請求の範囲に定義するように本発明の範囲に含めるものとする。
【図面の簡単な説明】
【図１】  本発明の一実施形態による、ネットワーク化された装置間で会話型リソースを共用することによって会話型サービスを提供するためのシステムのブロック図である。
【図２】  本発明の一態様による、ネットワーク化された装置間で会話型リソースを共用することによって会話型サービスを提供するための方法の流れ図である。
【図３】  本発明の別の態様による、ネットワーク化された装置間で会話型リソースを共用することによって会話型サービスを提供するための方法の流れ図である。
【図４】  会話型ブラウザを採用する本発明の別の実施形態による、会話型サービスを提供するための分散システムのブロック図である。
【図５】  会話型ブラウザを採用する本発明の別の実施形態による、会話型サービスを提供するための分散システムのブロック図である。
【図１】
0004171585.tif 000002
【図２】
0004171585.tif 000003
【図３】
0004171585.tif 000004
【図４】
0004171585.tif 000005
【図５】
0004171585.tif 000006