(57)【要約】【課題】  呼処理システムとのやりとりの失敗の尤度の考慮、当該システムを使用することに関連する期待時間またはフラストレーションに関する予測、および人間のオペレータに関する現在の負荷に応じて、自動あるいはユーザ指向の呼処理システムから人間のオペレータへ切り替えるための動的ポリシを提供する。【解決手段】  本システムおよび方法は、ログされたデータから構築されるシステムおよびユーザの振る舞いの確率モデルを活用する。自動システムから人間のオペレータへの呼の転送に関する理想的決定の決定論的分析および対応するモデルが提供される。本方法は、タッチトーンおよび音声認識に基づくシステムを含む多種多様な呼処理システムに用途がある。【選択図】  図１
2005027283.tif 000002
【特許請求の範囲】
【請求項１】
自動呼ルーティングシステムであって、
組織のメンバに入呼をルーティングし、１人または複数の発呼者に自動応答を提供する自動呼ルーティングコンポーネントと、
前記自動呼ルーティングコンポーネントに関連づけられ、前記呼をオペレータへ転送することを軽減する決定モデルと
を備えたことを特徴とするシステム。
【請求項２】
前記発呼者と通信するための音声認識コンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項３】
前記決定モデルは、前記呼ルーティングコンポーネントとの過去のアクティビティおよびやりとりのデータを記録したデータログからトレーニングされたことを特徴とする請求項１に記載のシステム。
【請求項４】
前記データログは、Speaker Found、Speaker Not Found、OperatorRequest、Help Request、Hang Up、Errorの最大数、Not Ready指示、およびUndefinedカテゴリの少なくとも１つに関係するデータを含むことを特徴とする請求項３に記載のシステム。
【請求項５】
前記決定モデルは、システムおよびユーザのアクション、セッションサマリの特徴、ｎ最良認識の特徴、および一般化された時間の特徴の少なくとも１つを含む１つまたは複数の会話の特徴を処理することを特徴とする請求項１に記載のシステム。
【請求項６】
前記ｎ最良認識の特徴を音声認識器から導出し、１つまたは複数のｎ最良リストの間の傾向をカバーするために前記一般化された時間の特徴を含むことを特徴とする請求項５に記載のシステム。
【請求項７】
前記決定モデルは、システムアクションのシーケンスを考慮して、成功の尤度を決定する確率ツリーを使用することを特徴とする請求項１に記載のシステム。
【請求項８】
前記決定モデルは、アクションシーケンスにおける総事例数にわたって、成功となった前記アクションシーケンスにおけるログされた事例の数を計数することによって、ｐ（SpeakFound｜Ｅ）を決定し、ここで、観測証拠Ｅはなされたシステムアクションを指し、ｐは確率であることを特徴とする請求項７に記載のシステム。
【請求項９】
決定モデルは、会話の特徴の１つまたは複数のカテゴリを入力変数として処理する依存関係ネットワークを使用することを特徴とする請求項１に記載のシステム。
【請求項１０】
前記決定モデルは、システムアクションのシーケンス、ｎ最良認識リスト内の代替のカウントあるいは数、ユーザが名前を言おうとした回数、呼ルーティングシステムによって割り当てられた最大スコア、および質問・回答ペアとして定義される会話の回数の少なくとも１つを処理することを特徴とする請求項９に記載のシステム。
【請求項１１】
前記決定モデルは、マルコフ依存関係ネットワークを使用することを特徴とする請求項１に記載のシステム。
【請求項１２】
周辺モデルに対して会話の回の部分モデルを押し上げるためにデータ量を増加させるためのコンポーネントをさらに備えたことを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記決定モデルは、発呼者を人間のオペレータにシフトすることのコストおよび便益に関する動的決定を実行するための確率モデルを含むことを特徴とする請求項１に記載のシステム。
【請求項１４】
前記確率モデルは、自動呼ルーティングシステムの管理者にとって発呼者を人間のオペレータに転送することに関する選好を指定することを可能にするために結果に関する予測を提供することを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記選好は、オペレータに関する現在の負荷を考慮して、発呼者が人間のオペレータを待たなければならない現在の期待時間の関数としての失敗に関する許容しきい値として表され、前記確率モデルは、コールセンタ設計にも使用することができることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記決定モデルは、自動システムについて呼のルーティングに成功する確率的パフォーマンス、待ち時間に関する選好、発呼者数の特徴づけ、およびオペレータを待つ待ち行列内の発呼者に対応するのに要する時間の少なくとも１つを考慮することによって、人員配置決定を容易にするために使用されることを特徴とする請求項１に記載のシステム。
【請求項１７】
前記待ち行列は、待ち行列理論定式化に基づいて最適化されることを特徴とする請求項１６に記載のシステム。
【請求項１８】
請求項１に記載の呼ルーティングコンポーネントおよび決定モデルの少なくとも一方を実施するためのコンピュータ可読命令が格納されたコンピュータ可読媒体。
【請求項１９】
呼ルーティングを容易にするシステムであって、
発呼者とやりとりする手段と、
前記発呼者をユーザに自動的に導く手段と、
前記発呼者をユーザに導く前に決定理論的分析を実行する手段であって、前記決定理論は、前記発呼者をオペレータに転送することの便益を評価するコスト便益分析を含む手段と
を備えたことを特徴とするシステム。
【請求項２０】
呼を自動的にルーティングする方法であって、
呼ルーティングシステムとともに使用するための効用モデルを決定することと、
過去のシステム呼アクティビティのログから前記効用モデルをトレーニングすることと、
組織メンバおよびオペレータの少なくとも一方に呼を自動的に導くことと
を備えることを特徴とする方法。
【請求項２１】
前記効用モデルは、呼ルーティングのプロセスに関連するユーザ関数ｕ（ｎ，ｍ，ｗ）に適用され、該ユーザ関数は、なされた自動会話ステップの数ｎ、自動ルーティングシステムとの間でなされることになるステップの期待される総数ｍ、および人間のオペレータへの転送のための待ち時間ｗの関数であることを特徴とする請求項２０に記載の方法。
【請求項２２】
ユーザのフラストレーションを処理することをさらに含むことを特徴とする請求項２１に記載の方法。
【請求項２３】
人間のオペレータに対比して自動システムと協働することに否定的な感情的反応を処理することをさらに備えることを特徴とする請求項２１に記載の方法。
【請求項２４】
会話の少なくとも１つのステップの数および性質を考慮して、不確実性の下でルーティングアクションのコスト便益分析を実行することをさらに備えることを特徴とする請求項２１に記載の方法。
【請求項２５】
やりとりの時間コストに従ってやりとりの効用を決定することをさらに備えることを特徴とする請求項２０に記載の方法。
【請求項２６】
ステップのやりとりの有効総時間への変換を一般化することをさらに備え、フラストレーションは特定ステップの有効総時間の増大によって捕捉されることを特徴とする請求項２５に記載の方法。
【請求項２７】
ｐ（xfer｜Ｅ，ξ）およびｐ（success｜Ｅ，ξ）＝１−ｐ（xfer｜Ｅ，ξ）を生じるように実行される事前計算をさらに備えることを特徴とする請求項２５に記載の方法。
【請求項２８】
確率分布ｐ（ｍ｜Ｅ，xfer，ξ）およびｐ（ｍ｜Ｅ，success，ξ）ならびに、それぞれ＜ｍ＞および＜ｍ’＞でラベルされた条件に対するステップの期待数の事前計算をさらに備えることを特徴とする請求項２５に記載の方法。
【請求項２９】
失敗における不確定な状況下で会話内の各時点で自動やりとりを継続することによる期待総待ち時間ｔａを次式のように求めることをさらに備え、
ｔａ＝ｐ（xfer｜Ｅ，ξ）（ｔ（＜ｍ＞）＋ｗ）
＋（１−ｐ（xfer｜Ｅ，ξ））ｔ（＜ｍ’＞）
ここで人間のオペレータとやりとりするための待ち行列に丁寧に直ちに転送することに関連する待ち時間がｗであることを特徴とする請求項２０に記載の方法。
【請求項３０】
呼処理の効用を次式のように求めること
呼処理の効用＝ｐ（xfer｜Ｅ，ξ）ｕ（ｔ（ｎ）＋ｔ（＜ｍ＞）＋ｗ），Ｃ）
＋（１−ｐ（xfer｜Ｅ，ξ））ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞）
をさらに備えることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記呼処理の効用を次式のように求めること
呼処理の効用＝
１−ｐ（fail｜Ｅ，ξ）（ｐ（xfer｜Ｅ，ξ）ｕ（ｔ（ｎ）＋ｔ（＜ｍ＞）＋ｗ，Ｃ，success）＋
（１−ｐ（xfer｜Ｅ，ξ）（ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞），０，success）
＋ｐ（fail｜Ｅ，ξ）ｕ（ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞），０，fail）
をさらに備えることを特徴とする請求項３０に記載の方法。
【請求項３２】
人間のオペレータによる呼処理のコストＣは、前記発呼者のニーズまたは目標に依存し、証拠から推論されることを特徴とする請求項３１に記載の方法。
【請求項３３】
現在までに収集された証拠を考慮してコストにわたる確率分布ｐ（Ｃ｜Ｅ，ξ）の推論を通じて期待コストを求めることをさらに備えることを特徴とする請求項３１に記載の方法。
【請求項３４】
人間のオペレータに転送されている呼に対する現在の待ち時間のオンラインセンシングを提供することをさらに備えることを特徴とする請求項２０に記載の方法。
【請求項３５】
ログ、監視、および構築モデルの少なくとも１つを継続するエンドツーエンドシステムを作成することと、
アクションの妥当性検査および監査のためにパラメータを自動設定すること、レポートを生成すること、およびトレースを生成することと
の少なくとも一方をさらに備えることを特徴とする請求項２０に記載の方法。
【請求項３６】
タッチトーンルーティングおよび音声認識の少なくとも一方を含むアプリケーションをサポートすることを特徴とする請求項２０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、デバイス、システム、プロセス、および／または個人の間のコミュニケーションを容易にするシステムおよび方法に関する。より詳細には、本発明は、成功の尤度、自動システムとのやりとりを継続することに伴う労力、および人間のオペレータの待ち行列に入ることに伴う待ち時間を考慮して、自動呼ルーティングシステムから人間のオペレータへの転送を行うための動的ポリシの採用に関する。
【背景技術】
【０００２】
電話でデータおよびサービスにアクセスするために、自動音声認識による呼ルーティングシステムを使用した経験があるユーザは多い。このようなシステムは、限定された領域でのより精度の高い音声コマンド・制御および連続音声認識システムの出現とともに、最近普及してきている。しかし、応用の範囲が限定されている場合であっても、このようなシステムは、ストレスのたまる失敗を起こすことがある。ユーザの失望に対処するため、多くの設計者は、発呼者が直ちに血の通った人間のオペレータにルーティングされるオプションを用意している。音声認識システム以外にも、押しボタン駆動型のメニューシステムを使用するような、その他の自動システムが配備されている。このようなシステムは、正しいオプションを提示したり、理解可能な関連性のあるオプションを提示したりするように思われないこと、および／または所望の設定へと迅速に収束するのではなく発呼者をいらだたしいオプションの羅列に導くように思われることがある、固定されたオプションのセットを提供することでユーザを失望させる場合がある。
【０００３】
ますます多数の組織が、押しボタン式ルーティングまたは音声認識および自然言語処理を用いるナビゲーションでユーザを支援する自動呼ルーティングシステムを使用している。自動化された方法は、オペレータへの負荷を軽減したり、または呼の受け付けおよびルーティングの職務の人員配置に伴うコストを低減したりするために使用される。しかし、自動受け付けおよびルーティングの失敗および失望により、発呼者にとっても、自動受け付けおよびルーティングを使用する組織にとっても高くつく可能性がある。というのは、発呼者がより多くの労力を投入し、より長い時間待機し、または単に失望して電話を切り、別の所とビジネスをしなければならない可能性があるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
音声認識システムを配備する普及率が最近高まっている。このようなシステムの普及の理由の１つは、押しボタン式ルーティングよりも自然なインタフェースを提供する見込みがあることである。しかし、音声ルーティングは依然として、血の通った人間のオペレータが提供することができるサービス品質に及ばないことに、いくつもの組織が気づいている。一例では、自動呼ルーティングシステムは、すべての内線電話番号案内の通話を処理する場合がある。こうしたシステムは、音声認識を使用して、会社の広域アドレス帳の数千の可能な名前エントリのうちの１つを一意的に識別しようとしている。言うまでもなく、このサイズの語彙は、音声エンジンのパフォーマンスに悪影響を及ぼすことは明らかである。
【課題を解決するための手段】
【０００５】
本発明のいくつかの態様の基本的理解を提供するために、以下に本発明の簡単な要約を提示する。この要約は、本発明の広範な概要ではない。これは、本発明の主要／不可欠な要素を特定したり、本発明の範囲を画定したりすることを意図するものではない。その唯一の目的は、後に提示するより詳細な説明への前置きとして、簡単な形で本発明のいくつかの概念を提示することである。
【０００６】
本発明は、自動呼ルーティングシステムに従って呼を誘導することに関する。当座の話し言葉による会話の状況の文脈依存分析（ｃｏｎｔｅｘｔ−ｓｅｎｓｉｔｉｖｅ  ａｎａｌｙｓｉｓ）に基づいて、進行中の自動システムから人間のオペレータへの切り替えを行うためのポリシを出力する１つまたは複数の決定モデルを提供する。また、本発明は、人と自動推論システムの理想的融合について推論するために決定理論的原理を適用することに関する。このように、呼ルーティングシステムでの発呼者の体験を、発呼者が自動システムとの共同作業において最終的に成功する（または成功しない）であろう確率、その成功に要する期待ステップ数、および人員の現在の負荷を考慮するモデルを開発することによって最適化する。一態様では、番号案内のための音声ルーティングシステムを、システムのパフォーマンスのデータログを通じて分析することが可能である。その場合、自動システムでの成功または失敗の尤度、および、やりとりが結果的に成功するであろうと仮定した場合の自動システムを使用したステップ数、全持続時間、労力、またはフラストレーションに関するデータログから、１つまたは複数の確率モデルを構築することができる。本発明は、学習モデルからのパス依存確率を決定分析と結合して、人間のオペレータへの転送に伴う期待される現在の待ち時間に関する情報を考慮して、人間のオペレータへの呼転送を最適に誘導する。
【０００７】
上記および関連する目的を達成するため、本明細書では、以下の説明および添付の図面に関連して、本発明のいくつかの例示的態様が記載されている。これらの態様は、本発明が実施され得る種々の方法を示しており、それらのすべてが本発明によって包含されることを意図している。本発明のその他の利点および新規な特徴は、本発明の以下の詳細な説明を図面とともに検討することから明らかとなるであろう。
【発明を実施するための最良の形態】
【０００８】
本発明は、呼を管理することに関連して決定理論を使用する。より詳細には、呼トラフィックの管理および特定の呼の処理は多くのビジネスにとって重要であり、本発明は、呼処理を最適化することに関連して決定理論を使用する。自動呼応答システムは、それに関連するコスト（例えば、顧客が電話を切ること）が便益（例えば、呼処理のために人間の介入を最小化すること）を圧迫するまでは使用することができる。このように、本発明によるシステムは、例えば呼応答および／または呼トラフィック処理のための特定のコンポーネント、発呼者の状態、呼を受けるエンティティの状態、帯域幅、リソース、および呼の性質等に関連する効用に基づいて、最も適当なアクション（例えば、自動呼応答システムを使用する、呼応答システムの使用を終了する、人間のオペレータに切り替える、呼を異なるサービスにルーティングする等）をとるために、決定理論に基づくフレームワークを使用する。こうして、本発明は、過去のアクティビティログからトレーニングされた１つまたは複数のモデルおよび決定理論の使用を通じて、リソースの利用を最適化する。
【０００９】
本明細書で使用される場合、「コンポーネント」、「モデル」、「システム」等の用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれであるかを問わず、コンピュータ関連のエンティティを指すことを意図している。例えば、コンポーネントは、以下のものには限定されないが、プロセッサで実行中のプロセス、プロセッサ、オブジェクト、実行可能プログラム、実行スレッド、プログラム、および／またはコンピュータであり得る。例示として、サーバで実行中のアプリケーションおよびそのサーバがコンポーネントであり得る。１つまたは複数のコンポーネントが、プロセスおよび／または実行スレッド内に存在してもよく、コンポーネントが１つのコンピュータに局在したり、および／または複数のコンピュータ間に分散したりすることが可能である。
【００１０】
本明細書で使用される場合、「推論」という用語は、一般的に、事象および／またはデータを通じて捕捉された観測値のセットからシステム、環境、および／またはユーザの状態を推定または推論するプロセスを指す。推論は、特定の文脈またはアクションを識別するために使用可能であり、あるいは、例えば状態にわたっての確率分布を生成することができる。推論は確率的であり得る。すなわち、データおよび事象の検討に基づく対象の状態にわたっての確率分布の計算であり得る。また、推論は、事象および／またはデータのセットから、より高いレベルの事象を構成するために使用される決定論的技法を含む、論理的推論を指すことも可能である。このような推論により、事象が時間的に近接して相関しているかどうか、ならびに事象およびデータが１つまたは複数のいずれの事象およびデータ源に由来しているかにかかわらず、観測された事象および／または蓄積された事象データのセットから、新たな事象またはアクションが構成される。
【００１１】
最初に図１を参照すると、本発明の一態様による呼ルーティング・決定システム１００が示されている。システム１００は、１または複数の発呼者１３０に自動応答１２０を提供するために日常的に使用される自動呼ルーティングシステム１１０を含む。これらのシステムは、処理コンポーネント、スイッチングコンポーネント、電子ディレクトリ、および、発呼者１３０と通信し、１４０で識別された個人（例えば、音声コマンドが個人の姓を示す）へ呼をルーティングするための音声認識コンポーネント等の関連するソフトウェアを含む。発呼者１３０が個人あるいは当事者と接続することができない場合、呼ルーティングシステム１１０は、発呼者にさらなる支援を提供するために、人間のオペレータ１４４に接続することができる。
【００１２】
本発明の一態様によれば、システム１００の効率的動作を促進し、発呼者と応答者の間のカップリングをより効率的にし、このようなシステムとやりとりするときに発呼者のフラストレーションを軽減するために、１つまたは複数の決定モデル１５０が呼ルーティングシステム１１０とともに使用される。一態様では、これは、呼ルーティングシステム１１０との過去のアクティビティおよびやりとりのデータが記録されたデータログ１６０によって決定モデル１５０をトレーニングすることにより達成される。そして、決定モデル１５０からの出力が、呼ルーティング判定のために使用される。このようなデータとしては、話者がどのくらいの頻度で見つかったかあるいは見つからなかったか、オペレータがどのくらいの頻度で要求されたか等の統計情報が挙げられる。このデータについては、図２に関連して以下でより詳細に説明する。決定モデルがトレーニングされた後、呼ルーティングシステム１００は、発呼者と、連絡相手となる個人との間の呼ルーティングを容易にするように、モデルと協調して機能する。以下でより詳細に説明するように、モデル１５０は、例えば発呼者を人間のオペレータに切り替えることのコストおよび便益に関連する動的ポリシに従って使用することができる。
【００１３】
次に図２を参照すると、グラフ図２００は、本発明の一態様によって分析される統計データを示している。データの種々のカテゴリがグラフ図２００に示されているが、呼ルーティングパフォーマンスに関連する他の統計カテゴリも同様に分析することができる（例えば平均接続時間）と理解される。図１に関して上記で説明したシステムの全体的パフォーマンスを査定するため、ほぼ１年の期間にわたる２５０メガバイトを超えるデータログを取得した。ログは、呼ルーティングシステムとの個別のセッションの６０，０００近いトランスクリプションを含んでおり、システムと発呼者のそれぞれのアクションを捕捉したものである。ある所与のセッションに対して、可能な結果として以下のようなものがある：
・SpeakFound：システムがディレクトリに名前を見つける。  
・SpeakNotFound：システムが、要求された人がディレクトリにないと推論し、呼をオペレータへルーティングする。  
・OperatorRequest：ユーザが「０」を押すことによってオペレータを要求する。  
・HelpRequest：ユーザが「＊」または「＃」を押すことによってヘルプを要求しようとする。  
・HangUp：ユーザがセッション中にとりやめ。  
・MaxErrors：システムが許容される間違いの最大数に達し、呼をオペレータへルーティングする。  
・NotReady：システムが一時的にサービス休止中である。  
・Undefined：ユーザが数字キーを押そうとする。
【００１４】
グラフ図２００は、すべての個別セッションをそれらの可能な結果に分けた全体的内訳を示している。サンプル会社ディレクトリの従業員名のリストが大きいことに主に起因して、関連するモデルおよびポリシのない呼ルーティングシステムの成功率は、４５％という憂鬱な結果であった。これは、ユーザが人間のオペレータにヘルプを要求しようとすることなく、システムが固有名を正確に識別した結果SpeakFoundの割合に対応している。発呼者が名前を言おうとさえしなかったセッションログを取り除くと、成功率は６６％に跳ね上がる。やりとりが試みられないという状況は、多くの発呼者がシステムとのやりとりを完全にバイパスする可能性が高いという不安な事実を明らかにしている。実際、これらの「名前なし」の試行は、全データの３１％、結果OperatorRequest全体の８５％、そして結果HangUp全体の５３％を構成していた。すなわち、ほぼ３人に１人の発呼者が、案内係モデルによる支援のないシステムとのやりとりを完全に回避することに決めている。数か月間にわたる名前なしの事例の長期的な分析によれば、ユーザは人間のオペレータを直ちに要求することを学習しているようであることが明らかとなった。実際、名前なしの状況と結果「OperatorRequest」の間の相関はρ＝．８８と有意であった。この相関は、システムの担当エンジニアが「オペレータを呼び出すには「０」を押してください」という句を導入プロンプトに追加した後ではρ＝．９０に上昇した。この句は、自動システムと協働することを回避する方法をユーザに教示する効果を有していた。これらの知見は、発呼者がより有効に自動呼ルーティングシステムとやりとりすることができるように、上記のモデルによるユーザ体験を特徴づけ、最適化するために用いられた。
【００１５】
次に図３を参照すると、本発明の一態様による１つまたは複数の会話の特徴３００が示されている。呼ルーティングシステムは通常、種々の会話の特徴から構成される手作りのルール（例えば、セッションでそれまでになされた質問の数）を用いて場当たり的にユーザをオペレータへ転送するポリシを扱っている。本発明は、ルールを構築するために直観に頼るのではなく、成功または失敗を予測する会話の特徴を発見する意図をもって、セッションログの大規模なデータベースから確率モデルを構築する。モデルを学習させるために使用される会話の特徴は、次の４つのカテゴリに大別される：
・システムおよびユーザのアクション３１０（例えば、ユーザに上位２つの推測から選び出すよう求める、ユーザがキーを押した等）
・セッションサマリの特徴３２０（例えば、検出された名前試行の数、全体の持続時間等）
・ｎ最良認識の特徴３３０（例えば、音声認識サブシステムによって割り当てられる信頼度スコアの範囲、モード、連続するスコア差の最大値、最も多い名／姓／姓名の数等）
・一般化された時間の特徴３４０（例えば、連続する回に一致する名の繰り返し数等）
【００１６】
ｎ最良認識の特徴３３０は音声認識器から導出することができ、一般化された時間の特徴３４０はｎ最良リスト間の傾向をカバーするように含められた。特徴情報の様々な量を用いて、呼ルーティングシステムとのセッションが結果的に成功または失敗に終わる尤度（ｌｉｋｅｌｉｈｏｏｄ）を推定するために、３つのクラス（３より多くても少なくてもよい）のモデルを構築した。
【００１７】
次に図４を参照すると、本発明の一態様に従って、システムアクションの任意のシーケンスが与えられた場合の成功の尤度を示す確率ツリー４００が示されている。呼ルーティングシステムがとるアクションのシーケンスを条件として、成功の尤度、すなわちｐ（SpeakFound｜Ｅ）を、そのアクションシーケンスでの総事例数にわたり結果が成功であったそのシーケンスでの事例の数を計数することによって求めることができる。ここで、観測証拠Ｅは、それまでとられたすべてのシステムアクションを指す。確率は、図４に示すように、各ブランチがシステムアクションを表すように、ツリー４００として視覚的に表示することができる。
【００１８】
下記の表１は、ツリー４００から抽出されたいくつかの会話ブランチの拡大図を提供する。ここで、ｎは、データログ内でその状態に到達した発呼者の数を指す。確率ツリー４００によれば、第１のシステムアクションである[Operator Intro]（これは、「オペレータを呼び出すには「０」を押してください」という句を付加する以外は標準的なプロンプトを与える）は、成功の確率がたった４５％である。興味深いことに、システムが続いて発呼者に名前全体を繰り返すように求め、次に発呼者に可能性のある３つの推測のうちから選び出すよう求めると、成功の尤度は６６％に上昇する。この最初のやりとりに対する成功の確率の上昇は、概して自動システムとの会話としては異常である。通常は、アクションのシーケンス、あるいはツリーに沿ったパスが長いほど、成功する可能性は低くなる。
【００１９】
表１：所与のパスの成功確率を捕捉するツリーのいくつかのブランチの拡大部分
【００２０】
【表１】
2005027283.tif 000003
【００２１】
周辺確率ツリーモデル４００の利点は単純さである。ツリー４００を構築するのに必要なデータは、それぞれのセッションに対するシステムアクションのシーケンスと、最終結果である。以下のセクションで説明するように、システムアクションのシーケンスは、成功を決定する際の最も予測的なファクタである。このモデル４００の欠点は、アクションのシーケンス、すなわちツリーを下るパスが長くなるほど、成功の尤度の頑強な予測変数(ｐｒｅｄｉｃｔｏｒ)を構築するための事例のセットが疎になることである。
【００２２】
図５は、本発明の一態様による会話の特徴の依存関係ネットワーク５００を示している。前述の会話の特徴の４つのカテゴリを活用して、本発明のもう１つの態様は、ベイズの構造学習を使用して、セッション結果を予測するための確率モデルを構築する。与えられたデータセットの異なる予測モデルに対する構造探索およびモデルスコアリングを行うベイズの学習ツールを使用して、予測モデルを学習させることができる。一例として、ＷｉｎＭｉｎｅツールキット（Chickering et al. 1997）を使用して、セッション結果およびその他の会話の特徴を入力変数として考慮し、依存関係ネットワークおよび関連する決定ツリーを構築することができる。
【００２３】
結果を予測するための上位５つの会話の特徴がダイヤグラム５００に表示されており、それらは依存関係の強さの順に以下の通りである：（１）システムアクションのシーケンス、（２）ｎ最良認識リスト内の代替のカウントあるいは数、（３）ユーザが名前を言おうとした回数、（４）システムによって割り当てられた最大の信頼度スコア、および（５）質問・回答ペアとして定義される会話の回数。
【００２４】
依存関係モデル５００は、結果との最も強いリンクを有する依存関係がシステムアクションのシーケンスであるという点で、確率ツリーにおける知見と呼応する。依存関係ネットワークに対応する決定ツリーにおいては、システムが１回の確認試行の後に固有名を識別する時または識別しない時に、第１の決定分裂（ｄｅｃｉｓｉｏｎ  ｓｐｌｉｔ）が生じることが分かった。確認が成功である場合、SpeakFoundセッションの尤度は９９％でほとんど確かである。そうでない場合、決定ツリー５００は、成功を予測するために他の会話の特徴を検討する。アクションのシーケンスが長いほど成功の確率が低くなるという考えと整合して、次の強いほうから５つのコネクションのうちの２つが、会話の長さに関係していることが分かった。残りの３つの特徴は、音声認識器によって出力されるパラメータであった。
【００２５】
成功の尤度が会話の長さと密接に結びついていると考えて、決定ルールがどのように強いほうから５番目の依存関係、すなわち会話回数を分裂するかに分析が向けられた。分裂は２つの会話回数で生じたので、データセットを回数によって分割し、第１回、第２回、および２回より多い場合についてモデルを構築した。
【００２６】
表２：会話回数が１回、２回、および２回より多い場合の上位５つの依存関係
【００２７】
【表２】
2005027283.tif 000004
【００２８】
表２は、それぞれの依存関係ネットワークモデルに対する上位５つの影響変数を表示している。なお、１回目の場合、上位５つの変数のほとんどすべてが、歪度および尖度のような信頼度スコアの分布特性を含む、音声認識器によって生成されるｎ最良認識リストに関係していることに留意されたい。しかし、２回目に移ると、会話１回目からの名または姓が２回目に再び現れる最大個数のような一般化された時間の特徴が作用し始める。２回目の後、会話の特徴はほとんど、会話の長さに関係する。
【００２９】
図６を参照すると、本発明の一態様によるマルコフ依存関係ネットワーク６００が示されている。次回におけるパフォーマンスを予測する可能性のある音声認識器からの特徴を具体化するため、ｎ最良認識リストの特徴のマルコフペアに対する時間的な依存関係ネットワークを構築した。図６は、そのマルコフ依存関係ネットワーク６００を表示している。ｎ最良認識リストの代替のカウントあるいは個数は、最も強い依存関係のうちの１つであるように一貫して選択されたので、依存関係ネットワークは、ｔ回目の代替数をｔ−１回目のｎ最良リストの特徴から予測することがいかにして可能であるかを示している。
【００３０】
上記の確率モデルの予測パフォーマンスを評価するため、学習後のモデルの分類精度を、トレーニングセットに対する実行時の統計全体を捕捉する周辺モデルと比較した。モデルは、もとのデータセットを７０対３０でトレーニングデータセットと保留（ｈｏｌｄｏｕｔ）データセットに分割して得られた。確率モデルは、迅速さに関する決定を導くことを目標としたので、結果変数は、成功（ｓｕｃｃｅｓｓ）と失敗（ｆａｉｌｕｒｅ）という２つの可能な分類状態にまとめられた。ここで成功はSpeakFound状態に対応する。下記の表３は、会話１回目、２回目、２回より多い場合、そして最後に全データセットを検査するモデルの保留データに関する分類タスクの結果を提示している。
【００３１】
部分会話（ｐａｒｔｉａｌ−ｄｉａｌｏｇ）モデルは、それぞれの会話の回のデータセットについて、完全モデルならびに周辺モデルを凌駕し、１回目の会話の精度が９４％の精度で最高である。完全モデルもまた、全体のデータセットに関して８５％を達成しているが、データセットが会話の回別に分解されると、結果が悪くなる。データ量が増加すると、周辺モデルに対して会話の回ごとの部分モデルを押し上げることになることが理解される。
【００３２】
表３：周辺、完全、および部分会話モデルの分類精度
【００３３】
【表３】
2005027283.tif 000005
【００３４】
会話の振る舞いと成功の間の確率的関係を究明するほかに、本発明の１つの目標は、発呼者を人間のオペレータにシフトすることのコストおよび便益に関する動的な決定において確率モデルを役立てることである。観測される会話の状態の関数として、自動システムとのセッションの最終的な成功の確率にアクセス可能であることにより、このような意思決定を可能にするコントロール面(control surface)が得られる。
【００３５】
定性的には、結果に関する予測を提供する能力を有する確率モデルは、自動呼ルーティングシステムの管理者にとって発呼者を人間のオペレータに転送することに関する選好を指定するための直接的方法を提供する。このような選好は、オペレータに対する現在の負荷を考慮して、発呼者が人間のオペレータを待たなければならないことになる現在の期待時間の関数としての失敗に関する許容しきい値として表現することができる。また、確率モデルは、コールセンタ設計にも使用することができる。全体的システムモデルを用いて人員配置決定を行うことが可能である。システムモデルは、自動システムが呼のルーティングに成功する確率的パフォーマンス、待ち時間に関する選好、発呼者数の特徴づけ、およびオペレータを待つ待ち行列内の発呼者に対処するのに要する時間を考慮することによって構築される。
【００３６】
待ち行列理論定式化（ｑｕｅｕｅ−ｔｈｅｏｒｅｔｉｃ  ｆｏｒｍｕｌａｔｉｏｎ）に基づいて、呼ルーティングシステム設計を最適化するという全体的課題を取り扱うためのシステムおよび方法を提供することができる。本発明において、自動システムとの会話の性質および進行に関する観測値を考慮して、発呼者の期待される待ち時間を最小化する決定理論的分析が提供される。
【００３７】
呼ルーティングのプロセスに関連するユーザの効用（ｕｔｉｌｉｔｙ）ｕ（ｎ，ｍ，ｗ）は、自動システムとの間でそれまでなされた会話のステップ数ｎ、現在の呼に対して自動ルーティングシステムとの間でとられるステップの追加的な期待総数ｍ、および転送が行われる場合に人間のオペレータへの転送に伴う待ち時間ｗの関数である。なお、一般的な場合には、全時間だけでなく、やりとりのステップの性質も考慮しなければならないことに留意されたい。一例として、たとえ全体的結果が正確であっても、システムの認識が悪ければ、人は非常に失望するかもしれない。発呼者のやりとりの効用は、回数および待ち時間以外にも、他の要因によって影響を受ける可能性がある。例えば、発呼者は、人間のオペレータに対して、自動システムと協働することに否定的な感情的反応を有する可能性がある。このような要因は、会話の各ステップの数および性質を考慮して、不確実性の下でルーティングアクションのコスト便益分析に取り込むことができる。
【００３８】
図７は、自動呼ルーティングシステムの成功という条件の下で、期待される会話ステップ数の事前分布を示すグラフ図７００である。図６に関連する検討の分析を続けるために、やりとりの効用は、そのやりとりの時間コストによって捕捉されると仮定することができる。分析は、ステップをやりとりの有効総時間に変換することで一般化することができる。ここで、フラストレーションは、特定のステップの有効総時間の増大によって捕捉される。このように、１つのクラスの解においては、ｕ（ｎ，ｍ，ｗ）が有効時間の尺度ｔ（ｎ，ｍ，ｗ）＝ｔ（ｎ）＋ｔ（ｍ）＋ｗによって捕捉されると仮定することができる。
【００３９】
自動システムの使用により結果的に成功する場合と、自動ルーティングが何らかの理由で（例えば、ユーザが人間のオペレータにアクセスするために「０」キーを押す）失敗し、ユーザが直ちに人間のオペレータにルーティングされる場合について、追加ステップの期待数を、会話内の各時点で計算することができる。図７は、０ステップ、すなわちやりとりの始めでの成功の期待ステップ数を表示している。
【００４０】
本発明では、やりとりがある時点で結果的に失敗し、ユーザがその時点で人間のオペレータに直ちにルーティングされることになる確率を、ｐ（xfer｜Ｅ，ξ）を用いて表す。やりとりの各時点で、ｐ（xfer｜Ｅ，ξ）およびｐ（success｜Ｅ，ξ）＝１−ｐ（xfer｜Ｅ，ξ）を事前に計算し利用可能にする。また、確率分布ｐ（ｍ｜Ｅ，xfer，ξ）（結果的に失敗する場合の追加ステップ数にわたる確率分布）、ｐ（ｍ｜Ｅ，success，ξ）（自動システムとのやりとりが成功する場合の追加ステップ数にわたる確率分布）、およびこれらの条件のそれぞれに対する期待ステップ数（それぞれ＜ｍ＞および＜ｍ’＞で表す）も事前に計算する。
【００４１】
失敗の場合に不確定な状況下で会話内の各時点で、自動やりとりを継続することによる期待追加待ち時間ｔａは次の通りである。
式１：
ｔａ＝ｐ（xfer｜Ｅ，ξ）（ｔ（＜ｍ＞）＋ｗ）＋（１−ｐ（xfer｜Ｅ，ξ））ｔ（＜ｍ’＞）
【００４２】
人間のオペレータとやりとりするための待ち行列に直ちに転送することに関連する待ち時間はｗである。この時間は変動し、現在の値は、最近の待ち時間の平均を測定することによって、またはオペレータを待つ発呼者の待ち行列をチェックすることによって、いつでも測定または推定することができる。会話の現在位置において、自動化されたやりとりを継続することに伴う期待待ち時間と、人間のオペレータのための待機待ち行列に直ちに自動転送する場合とを比較することができる。すなわち、ｔａ＞ｗであるかどうかを判定し続ける。ユーザが自動システムと関わり続ける場合の期待待ち時間のほうが大きい場合、ユーザを人間のオペレータの待ち行列に転送する。
【００４３】
近視眼的な分析を行う以外に、本発明は、様々な程度の先読みを行い、式１を呼び出すことにより会話内のさらに下流の時点における期待待ち時間を計算することができる。これには、ユーザが現在のパスに関して条件付けられた異なるパスをとり、それぞれの下流の時点に到達することに成功することになる不確定性を考慮に入れることができる。決定理論的尺度を使用することにより、ユーザの総待ち時間が最小化されることが見込まれる。
【００４４】
また、組織にとっての人間のオペレータによる呼処理のコストＣと、意思決定に関する組織の観点を考慮することができる。時間およびフラストレーションに関してユーザに対するコストをモデリングするだけでなく、次式のように、ユーザの時間およびフラストレーションに伴うコストの組織の評価に加えて、人間のオペレータによって呼を処理するコストの関数として、効用の組織の割当てを考慮する。
式２：
呼処理の効用＝ｐ（xfer｜Ｅ，ξ）ｕ（ｔ（ｎ）＋ｔ（＜ｍ＞）＋ｗ），Ｃ）
＋（１−ｐ（xfer｜Ｅ，ξ））ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞）
【００４５】
この態様では、効用の組織の評価ｕ（ｔ，Ｃ）を考慮する。これは、発呼者が経験する待ち時間と、呼処理の金銭的コストの関数として全コストを捕捉する。なお、コストは一定でないこともあることに留意されたい。ユーザの選択および応答に関する証拠を使用して、コストにわたる確率分布ｐ（Ｃ｜Ｅ，ξ）を更新することができ、式２において、期待コストを代わりに用いることができる。
【００４６】
もう１つの拡張として、ユーザが所在するパスと、待ち行列内の待ち時間の関数として、やりとり内の各時点においてユーザが失望して単に電話を切る尤度を取り込むことに基づいて、通信の全失敗のコストも考慮する。この拡張によれば、呼処理の期待コストについての全体的な組織の考慮は、次式のようになる。
式３：
呼処理の効用＝１−ｐ（fail｜Ｅ，ξ）（ｐ（xfer｜Ｅ，ξ）ｕ（ｔ（ｎ）＋ｔ（＜ｍ＞）＋ｗ，Ｃ，success）＋
（１−ｐ（xfer｜Ｅ，ξ）（ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞），０，success）
＋ｐ（fail｜Ｅ，ξ）ｕ（ｕ（ｔ（ｎ）＋ｔ（＜ｍ’＞），０，fail）
【００４７】
この態様では、発呼者が経験する待ち時間、呼処理の金銭的コスト、および呼が結果的に完了するか、それとも切断により失敗するかの関数としてコストについての効用の組織の評価ｕ（ｔ，Ｃ，結果）を考慮する。発呼者の損失をｐ（fail｜Ｅ，ξ）として表す。このような効用モデルは、発呼者が組織にとって永久的に失われるか、それとも次の試行がなされるまでかに関する、より詳細なモデリングを含むように拡張することができる。
【００４８】
図８は、本発明による呼ルーティングおよび意思決定の方法を示している。説明を簡単にするため、本方法は一連の行為として図示され記載されるが、本発明は行為の順序によって限定されないことは言うまでもない。本発明によれば、一部の行為は、図示され本明細書に記載されるものとは異なる順序で行われてもよく、そして／または他の行為と同時並行して行われてもよい。例えば、当業者には理解されるように、別法として、状態図におけるように一連の相互に関連する状態または事象として、方法を表現することも可能である。さらに、本発明による方法を実施するために、すべての例示されている行為が必要とは限らない。
【００４９】
８０２に進んで、本発明は、自動呼ルーティングシステムに基づく実世界の音声認識の種々のやりとりおよびパフォーマンスを考慮する。前述のように、これは、システムパフォーマンスの１つまたは複数の変数に影響を及ぼす種々のシステムコンポーネントおよびオペレータとのやりとりの分析を含み得る。８０４で、システムの種々のパフォーマンスの諸相を判定するためにデータを収集する。これは、例えば、呼応答統計、ルーティング統計、発呼者が人間のオペレータと話すための待ち行列に送られる前に待たなければならない時間のような種々の要因に基づく成功または失敗の統計を含み得る。８０８で、自動システムとのやりとりが成功するであろうかどうかのような情報を含めて、呼ルーティングシステムを通じて異なるパスの確率を提供するために使用されるデータから、１つまたは複数の確率モデルを構築することができる。８１２で、ユーザの自動ルーティングシステムとのやりとりにおける様々な時点で人間のオペレータに切り替える価値の決定理論的分析も提供される。
【００５０】
図９を参照すると、本発明の種々の態様を実施するための例示的環境９１０はコンピュータ９１２を含む。コンピュータ９１２は、処理ユニット９１４、システムメモリ９１６、およびシステムバス９１８を含む。システムバス９１８は、これに限定されないが、システムメモリ９１６を含むシステムコンポーネントを処理ユニット９１４に結合する。処理ユニット９１４は、種々の利用可能なプロセッサのいずれでもよい。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理ユニット９１４として使用可能である。
【００５１】
システムバス９１８は、さまざまな利用可能なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスを含む、いくつかのタイプのバス構造のいずれでもよい。そのようなバスアーキテクチャには、１１ビットバス、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＣＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ  ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ  Ｌｏｃａｌ  Ｂｕｓ）、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  ＳｅｒｉａｌＢｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）バス、およびＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ）があるがこれらには限定されない。
【００５２】
システムメモリ９１６は、揮発性メモリ９２０および不揮発性メモリ９２２を含む。起動中等にコンピュータ９１２内の要素間で情報を転送するための基本ルーチンが入っている基本入出力システム（ＢＩＯＳ）は、不揮発性メモリ９２２に格納される。例示として、限定ではないが、不揮発性メモリ９２２には、ＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ＰＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ  ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ  ｅｒａｓａｂｌｅ  ＲＯＭ）、またはフラッシュメモリが含まれ得る。揮発性メモリ９２０には、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）が含まれ、これは外部キャッシュメモリとして働く。例示として、限定ではないが、ＲＡＭは、ＳＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ  ＲＡＭ）、ＤＲＡＭ（ｄｙｎａｍｉｃ  ＲＡＭ）、ＳＤＲＡＭ（ｓｙｎｃｈｒｏｎｏｕｓ  ＤＲＡＭ）、ＤＤＲ  ＳＤＲＡＭ（ｄｏｕｂｌｅ  ｄａｔａ  ｒａｔｅ  ＳＤＲＡＭ）、ＥＳＤＲＡＭ（ｅｎｈａｎｃｅｄ  ＳＤＲＡＭ）、ＳＬＤＲＡＭ（Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭ）、およびＤＲＤＲＡＭ（ｄｉｒｅｃｔ  Ｒａｍｂｕｓ  ＤＲＡＭ）等の多くの形態で利用可能である。
【００５３】
また、コンピュータ９１２は、リムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体も含む。図９は、例としてディスクストレージ９２４を示している。ディスクストレージ９２４には、これらのものに限定されないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのようなデバイスが含まれる。さらに、ディスクストレージ９２４には、個別の、または他の記憶媒体と組み合わせた記憶媒体が含まれ得る。これらには、以下のものに限定されないが、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ  ｄｉｓｋ  ＲＯＭ）デバイス、ＣＤ−Ｒ（ＣＤ  ｒｅｃｏｒｄａｂｌｅ）ドライブ、ＣＤ−ＲＷ（ＶＤ  ｒｅｗｒｉｔａｂｌｅ）ドライブまたはＤＶＤ−ＲＯＭ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ  ＲＯＭ）ドライブのような光ディスクドライブ等が挙げられる。ディスクストレージデバイス９２４をシステムバス９１８に接続することを容易にするため、インタフェース９２６のようなリムーバブルまたは非リムーバブルインタフェースが通常使用される。
【００５４】
理解されるように、図９には、ユーザと、好適なオペレーティング環境９１０に記載されている基本的なコンピュータリソースとの間の媒介物として働くソフトウェアが記載されている。このようなソフトウェアには、オペレーティングシステム９２８がある。オペレーティングシステム９２８は、ディスクストレージ９２４に格納することができ、コンピュータシステム９１２のリソースを管理し、割り当てるように働く。システムアプリケーション９３０が、システムメモリ９１６またはディスクストレージ９２４のいずれかに格納されたプログラムモジュール９３２およびプログラムデータ９３４を通じて、オペレーティングシステム９２８によるリソースの管理を利用する。理解されるように、本発明は、種々のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実施することができる。
【００５５】
ユーザは、入力デバイス９３６を通じてコンピュータ９１２にコマンドまたは情報を入力する。入力デバイス９３６には、以下のものに限定されないが、マウス等のポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、ディジタルカメラ、ディジタルビデオカメラ、ウェブカメラ等がある。これらおよび他の入力デバイスは、インタフェースポート９３８経由でシステムバス９１８を通じて処理ユニット９１４に接続する。インタフェースポート９３８には、例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）がある。出力デバイス９４０は、入力デバイス９３６と同じタイプのポートのいくつかを使用する。このように、例えば、ＵＳＢポートは、コンピュータ９１２に入力を提供するため、およびコンピュータ９１２から出力デバイス９４０へ情報を出力するために使用することができる。出力デバイス９４０のうちでもとりわけ、特別のアダプタを必要とするモニタ、スピーカ、およびプリンタのような一部の出力デバイス９４０があることを例示するために、出力アダプタ９４２が提供されている。出力アダプタ９４２には、例示として、限定ではないが、出力デバイス９４０とシステムバス９１８の間の接続手段を提供するビデオカードおよびサウンドカードがある。なお、他のデバイスおよび／またはデバイスのシステムがリモートコンピュータ９４４のように入力および出力の両方の機能を提供する場合があることに留意すべきである。
【００５６】
コンピュータ９１２は、リモートコンピュータ９４４のような１つまたは複数のリモートコンピュータへの論理コネクションを用いたネットワーク環境で動作することができる。リモートコンピュータ９４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の普通のネットワークノード等であってよく、通常、コンピュータ９１２に関して説明した要素の多くまたはすべてを含む。簡単のため、メモリストレージデバイス９４６のみがリモートコンピュータ９４４とともに示されている。リモートコンピュータ９４４は、ネットワークインタフェース９４８を通じてコンピュータ９１２に論理的に接続され、通信コネクション９５０経由で物理的に接続される。ネットワークインタフェース９４８は、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）のような通信ネットワークを包含する。ＬＡＮ技術には、ＦＤＤＩ（Ｆｉｂｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ）、ＣＤＤＩ（Ｃｏｐｐｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ）、イーサネット（登録商標）／ＩＥＥＥ１１０２．３、トークンリング／ＩＥＥＥ１１０２．５等がある。ＷＡＮ技術には、以下のものに限定されないが、ポイントツーポイントリンク、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ）およびその変形形態のような回線交換ネットワーク、パケット交換ネットワーク、およびＤＳＬ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅｓ）がある。
【００５７】
通信コネクション９５０は、ネットワークインタフェース９４８をバス９１８に接続するために使用されるハードウェア／ソフトウェアを指す。通信コネクション９５０は、説明を明確にするためにコンピュータ９１２の内部に示されているが、コンピュータ９１２の外部にあってもよい。ネットワークインタフェース９４８に接続するために必要なハードウェア／ソフトウェアには、単なる例示のためであるが、通常の電話グレードのモデム、ケーブルモデムおよびＤＳＬモデム等のモデム、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カード等の、内蔵および外付け技術が含まれる。
【００５８】
図１０は、本発明がやりとりすることが可能なコンピューティング環境例１０００の概略ブロック図である。システム１０００は、１つまたは複数のクライアント１０１０を含む。クライアント１０１０は、ハードウェアおよび／またはソフトウェアのいずれ（例えば、スレッド、プロセス、コンピューティングデバイス）でもよい。また、システム１０００は、１つまたは複数のサーバ１０３０も含む。サーバ１０３０もまた、ハードウェアおよび／またはソフトウェアのいずれ（例えば、スレッド、プロセス、コンピューティングデバイス）でもよい。サーバ１０３０は、例えば本発明を使用することによって変換を実行するためのスレッドを収容することができる。クライアント１０１０とサーバ１０３０の間の可能な通信の１つは、２つ以上のコンピュータプロセス間で伝送されるように適応されたデータパケットの形態とすることができる。システム１０００は、クライアント１０１０とサーバ１０３０の間の通信を容易にするために使用することができる通信フレームワーク１０５０を含む。クライアント１０１０は、クライアント１０１０にとってローカルな情報を格納するために使用することができる１つまたは複数のクライアントデータストア１０６０に動作可能に接続する。同様に、サーバ１０３０は、サーバ１０３０にとってローカルな情報を格納するために使用することができる１つまたは複数のサーバデータストア１０４０に動作可能に接続する。
【００５９】
以上に説明したことは、本発明の例を含んでいる。もちろん、本発明を説明する目的で、コンポーネントまたは方法の考え得るあらゆる組合せを記載することはできないが、当業者には認識され得るように、本発明の多くのさらなる組合せおよび置換が可能である。したがって、本発明は、添付の請求項の精神および範囲内に入るすべてのそのような変更、修正および変形形態を包含することを意図している。さらに、「含む（ｉｎｃｌｕｄｅｓ）」という用語が詳細な説明または請求項のいずれかで使用される限りにおいて、当該用語は、「備える（ｃｏｍｐｒｉｓｉｎｇ）」が請求項で移行語として使用される時に解釈される場合の「備える」という用語と同様に包括的であることを意図している。
【図面の簡単な説明】
【００６０】
【図１】本発明の一態様による自動呼ルーティング・決定システムを示す概略ブロック図である。
【図２】本発明の一態様による呼ルーティング統計データを示すグラフ図である。
【図３】本発明の一態様による会話の特徴を示す図である。
【図４】本発明の一態様による確率ツリーを示す図である。
【図５】本発明の一態様による会話の特徴についての依存関係ネットワークを示すダイヤグラムである。
【図６】本発明の一態様によるマルコフ依存関係ネットワークを示す図である。
【図７】本発明の一態様による期待される会話のステップ数の事前分布を示す図である。
【図８】本発明の一態様による系統的自動呼ルーティングを示す流れ図である。
【図９】本発明の一態様による好適なオペレーティング環境を示す概略ブロック図である。
【図１０】本発明が相互作用することのできるコンピューティング環境例の概略ブロック図である。
【符号の説明】
【００６１】
１００  呼ルーティング・決定システム
１１０  自動呼ルーティングシステム
１２０  自動応答
１３０  発呼者
１４４  人間のオペレータ
１５０  決定モデル
１６０  データログ
３００  会話の特徴
３１０  システムおよびユーザのアクション
３２０  セッションサマリの特徴
３３０  ｎ最良認識の特徴
３４０  一般化された時間の特徴
４００  確率ツリー
５００  依存関係ネットワーク
６００  マルコフ依存関係ネットワーク
９１０  オペレーティング環境
９１２  コンピュータ
９１４  処理ユニット
９１６  システムメモリ
９１８  システムバス
９２０  揮発性メモリ
９２２  不揮発性メモリ
９２４  ディスクストレージ
９２６  インタフェース
９２８  オペレーティングシステム
９３０  システムアプリケーション
９３２  プログラムモジュール
９３４  プログラムデータ
９３６  入力デバイス
９３８  インタフェースポート
９４０  出力デバイス
９４２  出力アダプタ
９４４  リモートコンピュータ
９４６  メモリストレージデバイス
９４８  ネットワークインタフェース
９５０  通信コネクション
１０００  コンピューティング環境例（システム）
１０１０  クライアント
１０３０  サーバ
１０４０  サーバデータストア
１０５０  通信フレームワーク
１０６０  クライアントデータストア
【図１】
2005027283.tif 000006
【図２】
2005027283.tif 000007
【図３】
2005027283.tif 000008
【図４】
2005027283.tif 000009
【図５】
2005027283.tif 000010
【図６】
2005027283.tif 000011
【図７】
2005027283.tif 000012
【図８】
2005027283.tif 000013
【図９】
2005027283.tif 000014
【図１０】
2005027283.tif 000015
【外国語明細書】
2005027283000001.pdf