JP2008512789A - 機械学習 - Google Patents

Abstract

自動化応答システム（たとえば、自動化音声応答システム）は、学習戦略を利用して、自動化応答機能を開発し、または改良することができる。学習戦略は、会話における一方の当事者（カスタマーサービスエージェント）のコミュニケーション（発声、テキストメッセージなど）を用いて、会話における他方の当事者（発信者）のコミュニケーションを識別し、カテゴリ化することを含み得る。カテゴリ化されたコミュニケーションから、分類器を組み立てることができる。分類器は、会話における当事者（エージェント）の共通コミュニケーションパターンを識別するのに使うことができる。学習戦略は、選択基準（システムが、信頼できない、または重要でない例からは学習しないようにするために選ばれた選択基準）に基づいて、コミュニケーションを、自動化応答機能を改良するための学習機会として選択することも含み得る。

Description

本明細書は、自動化応答システムにおける機械学習に関する。

会話が管理されるあるアプリケーションが、顧客コンタクトセンター内にある。顧客コンタクトセンター、たとえばコールセンターは、新経済において、企業の最も重要であり動的な分野の１つとして出現した。今日の厳しい経済環境において、費用効果が高くなるように顧客にサービス提供し、つなぎ止めることが、戦略的に重要である。ほとんどの企業は、満足している顧客を保ち続けることの方が、新規顧客を獲得するよりも費用がかからないことを理解している。すべての顧客対話のうち半数を超えるものに対する企業の接点として、コンタクトセンターは、成功を収める事業戦略の土台となった。

コンタクトセンターの重要性が増しつつあるのが、最近の現象である。伝統的には、カスタマーサービスは、ほとんどの組織によって、高いにも関わらず、事業を行うのに必要なコストであり、問題および非効率性を伴うと見なされていた。大量の通話は通常、トレーニングされたスタッフを閉口させ、顧客に対して長時間話し中の待ち行列を生じさせる。不適当な情報システムは、ほとんどの発信者に対して、基本情報を何回か繰り返すことを要求する。このため、推定２０パーセントの買物客は、組織のコンタクトセンターに電話しなければならない事態に直面すると、ウェブサイトを見限り、より多くの客が、保留待ち行列または苛立たせるようなメニュー選択肢に遭遇すると、通話を諦める。さらに、顧客コンタクトセンターは、並外れた業務コストに相当し、平均的事業に対する収益の約１０パーセントを消費している。労働コストは、この支出の上位を占め、産業界の並外れて高い離職率により、新たなエージェントの採用およびトレーニングが際限なく続いている。

事業にとっては残念ながら、費用効果が高いカスタマーサービスを保証するという目標は、より困難になりつつある。インターネットにより、組織とその顧客との間のコミュニケーションの激増が推進された。顧客は、インターネット経済では、サービスに対してより高い価値を置いている。というのは、オンラインで購入される製品およびサービスが、従来の販売チャネルを通して購入されたものよりも多数の照会を生じさせるからである。コンタクトセンターの役割は、ビジネスパートナー、投資家、さらには会社の従業員など、新たな消費者へのサービス提供を含むまでに拡大した。効果の高い新規の広告およびマーケティング構想により、顧客は、情報を取得するために、既に過剰負担であるコンタクトセンターと対話するようになっている。電話の呼出しに加えて、照会は今では、ｅメール、ウェブメールおよびチャットを含む、新たなウェブベースのテキストチャネルを介して行われ、これが、カスタマーサービス業務に過大な負担をかけている。

優れたカスタマーサービスの増しつつある重要性およびそのようなサービスを実現する上での障害が結びついて、カスタマーサービスの挑戦課題となっている。

米国特許第６４０１０６１号

一態様では、本発明は、以前記録されたエージェント−発信者間会話（たとえば、人間エージェント−発信者間会話）セットに取り込まれたエージェントコミュニケーション（たとえば、発声、テキストメッセージなど）を用いて、１組のエージェント分類器をトレーニングすることを特徴とする。エージェント分類器から、発信者の発声を突き止め、クラスタ化することができる。クラスタ化された発信者の発声は、１組の発信者クラスタをトレーニングするのに使うことができる。

別の態様では、本発明は、分類器（たとえば、エージェントや発信者分類器）を使って、以前記録されたエージェント−発信者間会話におけるコミュニケーションを分類し、分類されたコミュニケーションを、関連する分類器用のトレーニングセットに追加し、分類器を組立て直すことによって、発信者クラスタを増補することを特徴とする。

別の態様では、本発明は、エージェント分類器を使って、以前記録されたエージェント−発信者間会話セットの中の共通エージェント要求パターンを識別することを特徴とする。こうした共通エージェント要求パターンは、特定の通話タイプ（たとえば、同じ初期発信者要求に関係する通話）に関連し得る。こうしたエージェント要求パターンは、たとえば、アプリケーション開発者によって、自動化応答システムの会話の流れを考案するのに使うことができる。

別の態様では、本発明は、同じ情報について尋ねる様々なフレーズのエージェント質問に対する発信者応答の分布を用いて、発信者から所望の応答を生じる可能性が最も高い、自動化応答システム用の質問の言い回しを判定することを特徴とする。

別の態様では、本発明は、第１の当事者タイプのメンバ（たとえば、人間エージェントやソフトウェアエージェント）と第２の当事者タイプのメンバ（たとえば、人間発信者）との間の１つの会話セットを受け取ることを含む方法を特徴とし、会話はそれぞれ、第１の当事者タイプのメンバのコミュニケーションと、第１の当事者タイプのメンバのコミュニケーション（たとえば、要求に対して発話された応答）に応答する、第２の当事者タイプのメンバのコミュニケーション（たとえば、発話された要求）とを含む。本方法は、第１の当事者タイプのメンバのコミュニケーションを第１のクラスタセットにグループ化すること、および次いで、第２の当事者タイプのメンバの、応答側コミュニケーションを、第１の当事者タイプのメンバのコミュニケーションのグループ化に基づいて、第２のクラスタセットにグループ化することも含む。本方法は、マシンによって、第２のクラスタセット中の１つまたは複数のクラスタ用に、１組の第２の当事者タイプ分類器（たとえば、サポートベクターマシンや決定木）を生成することも含む。

本発明のこの態様の実装形態は、以下の特徴の１つまたは複数を含む。本方法は、自動化音声応答システムや自動化テキストメッセージ通信応答システムなど、自動化応答システム用の初期アプリケーションを開発するのに用いることができる。第１の当事者タイプのメンバのコミュニケーションは、コンピュータを使って、第１のクラスタセットにグループ化することができる。たとえば、コンピュータプロセスは、最初にコミュニケーションの意味特徴を判定し、次いで、意味特徴に基づいて、コミュニケーションをクラスタにグループ化することができる。

第１グループのメンバのコミュニケーショングループは、そのコミュニケーションの意味に基づいてグループ化することができる。言い換えると、コミュニケーションは、あるグループ中のコミュニケーションすべてが同じ意味をもつが、異なる言い回しをもち得るようにグループ化することができる。第２当事者タイプのメンバのコミュニケーショングループは、第１の当事者タイプのメンバからの、情報を求める要求への応答に対応するグループにグループ化することができる。

本方法は、第１の当事者タイプのメンバと第２の当事者タイプのメンバとの間の第２組の会話セットを受け取ること、第２の当事者タイプ分類器を適用して、第２の当事者タイプのメンバのコミュニケーションをグループ化すること、およびマシンによって、クラスタ中のグループ化されたコミュニケーションに関するデータを使って、第２のクラスタセット中のあるクラスタ向けの第２の当事者タイプ分類器を生成し直すことをさらに含み得る。

別の態様では、本発明は、１組の分類器を適用して、応答側コミュニケーションも含む会話の一部である開始側コミュニケーション（たとえば、エージェントからの情報要求）をカテゴリ化すること、およびカテゴリ化されたコミュニケーションを用いて、共通のコミュニケーションパターンを識別することを特徴とする。

本発明の実装形態は、以下の特徴の１つまたは複数を含み得る。本方法は、会話セット中の会話を、主題（たとえば、コールセンターに電話した発信者の目的である主題）によってグループ化すること、および識別された共通のコミュニケーションパターンを、そのグループに関連づけることをさらに含み得る。

別の態様では、本発明は、１組の分類器（たとえば、サポートベクターマシン）を適用して、第１の当事者タイプのメンバと第２の当事者タイプのメンバとの間の会話における、第１の当事者タイプのメンバのコミュニケーションをカテゴリ化すること、および第１の当事者タイプのメンバの、カテゴリ化されたコミュニケーションの組合せまたは並びに基づいて、会話の主題を判定することを特徴とする。

本発明の実装形態は、以下の特徴の１つまたは複数を含み得る。本方法は、カテゴリ化されたコミュニケーションの並びを、既知の主題を有する会話に関連づけられた、カテゴリ化されたコミュニケーションの並びと突き合わせることも含み得る。

別の態様では、本発明は、発信者と自動化応答システム（たとえば、自動化テキストメッセージ通信応答システムや自動化音声応答システム）との間に発生したコミュニケーションの例を使って、システムの性能を向上させることを特徴とする。

別の態様では、本発明は、いくつかの選択基準に基づいて、自動化応答システム用の学習機会の例を選択することを特徴とする。選択基準は、システムが学習するための例が信用できるものであることを保証するのを助けるために、（たとえば、ユーザによってグラフィカルユーザインターフェイスを介して）選ぶことができる。選択基準は、システムが、結果としてシステムに対して有意義な改良をもたらす例のみを選択することを保証するように選ぶこともできる。結果としてシステムに対して有意義な改良をもたらさない例を無視することによって、システムは、リソース（たとえば、改良を実現する任務を負わされた処理リソースや、学習例を検討し、または承認する任務を負わされた、人間が管理するリソース）に対する負担を最小限にするのを助ける。

別の態様では、本発明は、少なくともそのいくつかが、人と、コンタクトセンターに関連するエージェント（たとえば、人間エージェントやソフトウェアエージェント）との間の一連のコミュニケーション（たとえば、発声、テキストメッセージなど）を含む会話のデジタル表現を受け取ること、ならびに１つまたは複数の選択基準が満たされる場合、あるコミュニケーションを学習機会として選択することを含む、コンタクトセンターに関連づけられた自動化応答システム用の学習機会を選択する方法を特徴とする。

実装形態は、以下の特徴の１つまたは複数を含み得る。選択基準は、コミュニケーションの後に人とエージェントの間にコミュニケーションのやり取りが続くという要件、コミュニケーションの後に人とエージェントの間の、後続の成功したいくつかのコミュニケーションやり取りが続くという要件、コミュニケーションが、エージェントによって課された満足性質問に対して、人が肯定的に応答した会話に含まれるという要件、第１の会話中のコミュニケーションが、他のいくつかの会話中に発生する同様のコミュニケーションによって確認されるという要件、またはコミュニケーションが、コミュニケーションを用いて組み立てられた１組の分類器に、以前の１組の分類器が正しく分類したコミュニケーションの分類を誤らせないという要件でよい。

いくつかの実装形態では、人とエージェントの間のコミュニケーションは、人間エージェントが人のコミュニケーションに対する応答を、自動化応答システムによって生成された、応答案のランクつきリストから選択した支援対話を含み得る。こうした支援対話に対して、選択基準は、支援対話中の選択された応答が、閾値を越えてランクづけされるという要件、または支援対話中の選択された応答が、信用できる人間エージェントから選択されるという要件を含み得る。

選択されたコミュニケーションは、選択されたコミュニケーションを用いて分類器を組み立て直し、選択されたコミュニケーションを用いて、自動音声認識エンジン用の言語モデルを生成し、または選択されたコミュニケーションを用いて有限状態ネットワークを変更することによって、システム性能を向上させるのに用いることができる。

音声応答の実装形態において、本方法は、オフラインの音声認識エンジンによって、学習機会として選択された発声に対して音声認識を実施することも含み得る。本方法は、音声認識の実施に先立って、コミュニケーションのデジタル表現に関連づけられた、発声の意味の信頼性レベルに基づいて、選択された発声に対して音声認識を実施するかどうか判定することも含み得る。

別の態様では、本発明は、発信者と、コンタクトセンターに関連づけられた１つまたは複数のエージェントとの間に起こった会話のデジタル表現を受け取ること、ならびに１つまたは複数の選択基準に基づいて、会話のデジタル表現に取り込まれた発声を転記のために選択することを含む、コンタクトセンターに関連づけられた自動化音声応答システム用の学習機会を選択する方法を特徴とする。

実装形態は、以下の特徴の１つまたは複数を含み得る。選択基準は、自動化音声応答システムによる応答の信頼性レベルが一定の値の範囲に収まるという要件、または会話中の発声に対して実施される音声認識プロセスの信頼性レベルが一定の値の範囲に収まるという要件を含み得る。本方法は、発声に対して音声認識を実施すること、および発声中の認識された単語を、システムによって会話中の発声を認識するのに用いられる音声認識プロセスによって使われる、単語の語彙集に追加することも含み得る。

別の態様では、本発明は、人と、その人のコミュニケーションに対する応答を、エージェントが、自動化応答システムによって応答案の中から選択した自動化応答システムに関連づけられた人間エージェントとの間の対話に基づいて、コミュニケーションを、自動化応答システムをトレーニングするための例として選択することを含む方法を特徴とする。

本発明の実装形態は、以下の特徴の１つまたは複数を含み得る。コミュニケーションの選択は、エージェントによって選択された応答の信頼性レベル、または応答を選択した人間エージェントの信用レベルに基づいてよい。

別の態様では、本発明は、人間エージェントによって扱われる応答を生じさせた自動化応答システムと交信する人と、自動化応答システムを、システムと交信する人からの将来の同様のコミュニケーションに対して応答するように変更するものとの間のコミュニケーションを識別する方法を特徴とする。

特定の一実装では、自動化応答システムを変更することは、システムに関連づけられた有限状態遷移ネットワークを変更することを含み得る。

別の態様では、本発明は、概念認識エンジン内の分類器用の１組のトレーニング例にコミュニケーションを追加すること、追加されたコミュニケーションを含むその１組のトレーニング例を使って、新たな分類器を生成すること、および新たな分類器に対する性能要件に基づいて、新たな分類器を無視することを含む、自動化応答システム用の学習機会を選択する方法を特徴とする。

実装形態は、以下の特徴の１つまたは複数を含み得る。性能要件は、新たな分類器が、他の少なくとも所定の数の例を正しく分類するという要件でも、新たな分類器が、以前の分類器の確定的な（ｄｅｆｉｎｉｔｉｖｅ）１組の例とは所定の量だけ異なる、新たな確定的な１組の例をもつという要件でもよい。

別の態様では、本発明は、応答側コミュニケーションの少なくとも１つのクラスタ用の１組の分類器を生成することを特徴とし、クラスタは、会話中で応答側コミュニケーションが関連づけられる、開始側コミュニケーションの１つまたは複数のクラスタに基づく。

実装形態は、以下の特徴の１つまたは複数を含み得る。開始側の会話は、第１の当事者タイプのメンバ（たとえば、カスタマーサービスセンターにいるエージェント）からでよく、応答側会話は、第２の当事者タイプのメンバ（たとえば、カスタマーサービスセンターと交信する顧客）からでよい。本方法は、少なくともそのいくつかが開始側コミュニケーションおよび関連づけられた応答側コミュニケーションを含む、１つの会話セットを受け取ることも含み得る。応答コミュニケーションのクラスタは、開始側コミュニケーションに関連づけられた応答側コミュニケーションを含み得る。

他の利点、特徴、および実装形態が、以下の説明および特許請求の範囲から明らかになるであろう。

参照によってその全体が組み込まれている特許文献１に記載されている技術などの、概念または意味に基づく自然言語処理技術は、その文字通りの言い回しではなく、情報の意味、すなわち意味的文脈に基づいて、情報とインテリジェントに対話するのに利用することができる。したがって、コミュニケーション、たとえばユーザが質問を課し、システムが返答を与えるコミュニケーションを管理するシステムを組み立てることができる。このようなシステムは、ユーザクエリから、文字通りの言い回しによらずに、キーとなる概念を自動抽出するので、極めて効果的であり、ユーザフレンドリーであり、耐障害性がある。概念認識エンジン（特許文献１に記載されている種類のもの）は、顧客が、声またはテキストベースのコミュニケーションチャネルを介した会話に基底システムを従事させるとき、顧客が尋ねていることに基づく、適切な応答の形成を可能にする。会話は、顧客を伴う同期コミュニケーション（ボイスメッセージまたはインスタントメッセージを用いるリアルタイムのダイアログや、ウェブページを介した他のコミュニケーションなど）でも、非同期コミュニケーション（ｅメールやボイスメールメッセージなど）でもよい。非同期コミュニケーションモードを用いた会話では、顧客の照会と比較して、より後の時点で応答が与えられる。

顧客コンタクトセンターの例では、ランタイムに先立って、コミュニケーション管理システムは、顧客コンタクトセンターでの、顧客と人間エージェントの間の、ログをとられた実際の会話を使って、知識ベースを作成する。このように、可能なあらゆる顧客対話に対してシステムをプログラムしようとするのではなく、ログをとられた会話を使うことによって、セットアップが容易で迅速になり、幅広いシステム管理者の能力の範囲内となる。

変化し続ける事業状況に素早く適応することができない、従来のセルフサービスシステムとは異なり、本明細書に記載されるシステムは、典型的な質問および回答のペアを直ちにモデル化し、将来の会話を自動化することができる。

システムによって（ランタイムに先立って知識ベースを組み立てるため、またはランタイムに今現在のコミュニケーションを処理するために）処理される各会話は、順序づけられた１組の状態、ならびに各状態からの遷移が顧客による質問またはステートメントおよび人間エージェントによる応答を含む他の状態への遷移（あるいは一部のケースでは、逆に質問をユーザに課すなど、質問に応答してとられるべきアクション）としてモデル化される。記録された対話からの、処理中の会話に対する象徴的な、状態−遷移−状態のシーケンスを、図１に示す。いくつかの実装形態では、顧客による各ステートメントまたはコミュニケーションあるいは人間エージェントによる応答の区切りは、沈黙期間または発話による割込みである。

こうしたステートメントまたは応答それぞれのテキストは、会話においてどのようなコミュニケーション媒体、たとえばテキストまたは発語が使われようとも、そこから抽出される。たとえば、オンライン自動音声認識（ＡＳＲ）エンジンは、発話された会話をテキストにコンバートするのに使うことができる。次に、システムは、顧客の質問またはステートメントあるいは人間エージェントの応答から、キーとなる概念を抽出する。この抽出は、特許文献１に記載されているように、テキストエレメント（Ｓ−Ｍｏｒｐｈ、すなわちＳ形態素）および１組の概念（意味要素）によるその意味ライブラリを、概念認識エンジンによって使用するための知識ベースとして作成することによって行われる。概念認識エンジンは、顧客またはエージェントからのテキストを、こうしたＳ形態素に解析し、次いで、こうしたＳ形態素に合致する概念が収集される。コミュニケーション（論じている例では、質問または応答）に対するこうしたキー概念は、順序づけられていないセットに格納することができ、「概念のバッグ」と呼ぶことができる。シンタクスまたは類似を反映する様々な構造への、概念のより高レベルの編成も可能である。ログをとられた会話（すなわち、ダイアログ）のセット全体が処理された後、各会話は、状態−遷移−状態シーケンスとして表される。システムは、会話状態遷移シーケンスをすべて、単一のグラフに蓄積し、そうすることによって、初期状態は、会話のいずれにも遷移することができるようになる。この集約型遷移グラフは次いで、重複状態および遷移を置き換えるグラフ理論技法を用いて凝縮される。システムは、所与の状態からのどの遷移が重複しているかを、遷移をその「概念」と比較することによって、再帰的に判定する。同じ状態からの重複遷移の後継状態は次いで、後継状態からの遷移すべてを有する１つの状態にマージされる。重複遷移の応答のうち１つのもののテキストは、標準応答として知識ベースに保存される。このテキストは、テキストの形の会話型やり取りの一部として、顧客に渡し戻され、または音声にコンバートされる。その結果得られる、凝縮された状態遷移グラフは、システム用の知識ベースを形成する。凝縮された状態遷移グラフの例を、図１Ａに示す。いくつかの実装形態では、この知識ベース内の情報はすべて、明確なＸＭＬ文法を用いて格納される。マークアップ言語の例は、ハイパーテキストマークアップ言語（ＨＴＭＬ）および音声拡張マークアップ言語（ＶｏｉｃｅＸＭＬ）を含む。この場合、会話マークアップ言語（ＣＭＬ）は、知識ベース用の情報を格納するのに使われる。

知識ベースが形成されると、システムは、たとえば顧客コンタクトセンターにおけるコミュニケーションを管理するのにシステムが使われる動作（ランタイム）モードに進むことができる。所与の顧客コンタクトセンター向けの知識ベースを構築するのに使われたログは、いくつかの実装形態では、その同じ顧客コンタクトセンターまたは同様の種類の会話によって特徴づけられるコンタクトセンターで発生する会話から記録されることになる。知識ベースを使って、システムは、ランタイム会話の現在の状態を、顧客コンタクトセンター用の状態遷移グラフに基づいて追跡することができる。たとえば、顧客がその第１のコミュニケーション（テキストにコンバートされる）を顧客コンタクトセンターと行った（たとえば、ユーザが任意の、自然言語で発話されたクエリを行ってもよい）後、システムは、概念認識エンジンを使って、テキストから概念を抽出する。次に、システムは、テキストからの概念を、コンタクトセンターの状態遷移グラフ中の初期状態からの遷移と突き合わせることを試みる。この突合せは、現在のコミュニケーションに関連づけられた概念セットを、知識ベースに格納された概念セットと比較することによって行われる。２つのセットが近いほど、突合せ結果の正確さの信頼性が増す。知識ベース中の最も合致する遷移が、信頼性が一定の閾値を越える顧客のテキストに合致する場合、システムは、正しい遷移を識別したと想定し、知識ベース中で、対応する応答の場所を突き止め、対応する応答を顧客に伝達する。システムは、状態遷移グラフ中の次の状態に進み、顧客の次のコミュニケーションを待つ。この一連の状態および遷移の巡回は、顧客が会話を終了するか、または状態遷移グラフが終了状態に達するまで続き得る。ただし、概念認識エンジンによって受け取られるテキスト中のエラーと、顧客による非標準的（もしくは予期されない）質問またはステートメントとは、人間エージェントによる介入を必要とし得る。顧客のコミュニケーションが発語形式のとき、発語からテキストへのコンバートは、このようなエラーを有し得る。このようなエラーが起こり得るせいで、いくつかの実装形態では、システムは、顧客への応答の完全な自動化には依拠せず、代わりに、自動化が失敗すると、人間エージェントによる手動介入に円滑に遷移する。概して、このタイプの段階的自動化は、顧客１、システム３、および人間エージェント５の間の対話を示す図２によって示されている。（本システムの他の実装形態では、自動化応答は、信頼性が高い場合に与えることができるが、応答（システムが応答することができないということを示すもの以外）はユーザに与えられない）。

いくつかの例では、システムは、音声認識技術を使って、電話による会話に顧客を従事させる。音声認識技術は、顧客の発語を、概念認識エンジンへの入力となるテキストにコンバートする。概念認識エンジンを音声認識と統合することによって、基底システムは、顧客が意味することを概念的に理解することによって、顧客が言うことを認識する。この結合により、多数のチャネルを介して、直観的で、インテリジェントな、建設的な対話にユーザを引き込むことによって、カスタマーサービスセンターにおける新たなレベルの自動化が可能になる。また、組織が多大な量の日常的顧客トランザクションを、すべてのコンタクトチャネルを介して負担させることも可能になり、かなりの支出の節約となるとともにサービスレベルが向上する。

他の実装形態では、顧客とのこうした会話は、たとえば、ＶｏｉｃｅＸＭＬブラウザを使うオーディオインターフェイス、ＨＴＭＬブラウザを使うウェブ、ＩＭアプリケーションを使うインスタントメッセンジャー、メールアプリケーションを使うｅメール、ならびにまだ使用されていない他のチャネルを介して起こり得る。

このシステムは、コンタクトセンターの応答が、顧客のコミュニケーションとは異なるコミュニケーションモードを使うことを可能にすることに留意されたい。たとえば、顧客は、声を使ってコミュニケーションを行うことができ、コンタクトセンターは、テキストで応答することができ、あるいは顧客がテキストを使ってコミュニケーションを行うことができ、コンタクトセンターが、コンピュータ生成による声で応答することができる。これは、セーブされた応答テキストを直接使うことによって、あるいはセーブされた応答テキストをコンピュータ生成による声にコンバートすることによって遂行される。

いくつかの実装形態では、本システムは、３つのタイプまたはレベルの会話管理を提供し、本システムは、所与の会話中に、こうした会話管理の間で切換えを行うことができる。

１．自動化：システムは、顧客の要求に対して適切な応答を生じ、人間エージェントに全く依存せずにトランザクションを自動化することが可能である。たとえば、顧客Ａが、新製品に対する会社の保証について照会するために、会社の顧客コンタクトセンターに電話する。顧客Ａは、自動化システムによって迎えられ、システムは、自己紹介を行い、自動化システムがどのように動くかを、サンプル照会を含んで手短に説明する。顧客は次いで、自分の照会内容を自分自身の言葉で述べるよう促される。顧客Ａは、自分の照会内容を会話様式で述べる。自動化システムは、顧客に会社の包括的な保証方針を知らせる。システムは、顧客Ａに、この解決が有用であったかどうか、また、追加の質問があるかどうか質問する。自分の質問が回答されると、顧客Ａは通話を終える。

２．融合エージェント支援：このモードでは、システムは、人間エージェントを巻き込み、顧客の照会および信頼性／類似（「一致スコア」）によってランクづけされた、いくつかの応答案を人間エージェントに提示する。人間エージェントは、応答案の１つを選択し、システムが通話を完了することを可能にする。人間エージェントは、システムに質問を入れることによって、代替応答を求めてシステム知識ベースを検索することもできる。融合エージェント支援モードでは、エージェントは、電話をとることも、顧客と直接対話することもない。合成されたモデルは、エージェントがシステムを正しい解決に素早く「向かわせる」ことを可能にすることによって、通話にかかるエージェント時間を削減することが期待される。人間エージェントは次いで、新たなトランザクションに移ることができる。たとえば、顧客Ｂが、サービスに対する支払いを翌日まで延ばすことができるアドレスを尋ねるために、会社のカスタマーサービス組織に電話する。顧客Ｂは、自動化システムで迎えられ、システムは、自己紹介を行い、顧客の名前を確認する。名前の確認が行われた後、顧客Ｂは、自動化システムがどのように動くかを、サンプル照会を含んで手短に説明される。顧客は次いで、自分の照会内容を自分自身の言葉で述べるよう促される。顧客Ｂは、自分の照会内容を会話様式で述べる。自動化システムは、顧客の質問への回答を探す間、顧客に少し待つよう依頼する。システムは、次に応対可能なエージェントに電話をかける。顧客が待っている間、システムは、応対可能な人間エージェントにつなぎ、顧客Ｂの質問を小音量で伝える。人間エージェントは、顧客の質問に対する、いくつかの応答案を有するスクリーンポップを受け取る。人間エージェントは、適切な提案された回答を選択し、「応答する」をたたき、システムが対話を完了することを可能にする。システムは、顧客Ｂとの対話を再開すると、翌日持越し用アドレスを与える。システムは、顧客Ｂに、この解決が役に立ったかどうか、また、追加の質問があるかどうか質問する。質問が回答されると、顧客Ｂは、人間エージェントが応答のうちどれを選択したことを知ることなく、通話を終える。

３．エージェント支援引継ぎ：引継ぎモデルでは、システムは、人間エージェントに拡大し、人間エージェントは通話を完全に引き継ぎ、発信者を直接会話に引き込む。引継ぎモデルは、カスタマーサービスエージェント向けの通話から会話型情報を事前収集し、エージェントが通話中にシステムの知識ベース中で情報をルックアップすることを可能にすることによって、エージェントの生産性を向上させると期待され、電話に費やすのに必要とされるよりも時間量を削減する。たとえば、顧客Ｃが、自分の口座を解約するために、会社のカスタマーサービス組織に電話する。顧客Ｃは、自動化システムで迎えられ、システムは、自己紹介を行い、顧客の名前を確認する。名前の確認が行われた後、顧客Ｃは、自動化システムがどのように動くかを、サンプル照会を含んで手短に説明される。顧客は次いで、自分の照会を自分自身の言葉で述べるよう促される。顧客Ｃは、会社の口座を解約したいと述べる。自動化システムは、口座番号を確認するよう、顧客に依頼する。顧客Ｃは、電話キーパッドで口座番号を打ち込む。システムは、顧客Ｃに、エージェントに転送される間、そのまま待つよう告げる。システムは、通話を、このトランザクション向けの適切なエージェントプールに渡す。次に応対可能なエージェントが、顧客Ｃの質問の記録を受け取り、顧客の口座情報を有するスクリーンポップを受け取る。エージェントは、通話を引き継ぐと、顧客Ｃが口座をいつ解約したいのか尋ねる。

システムは、システムの、状況を扱う能力に基づいて、３つの会話管理モードの間で切換えを行う。たとえば、自動化会話モードでは、システムが顧客の照会を、十分な信頼性をもって標準質問／応答ペアに合致させることができない場合、システムは、融合エージェント支援モードに切り換えてよい。さらに、融合エージェント支援モードでは、コンピュータ生成による応答のどれもが、顧客の照会を与えられたと仮定した場合に適切でないと人間エージェントが判定した場合、システムは、エージェント支援引継ぎ会話モードに切り換えてよく、人間エージェントが会話を完成させる。本発明の好ましい実施形態では、顧客が、会話のモードを切り換えることもできる。たとえば、顧客は、自動化会話モードから抜けるように切換えを行うことを望む場合がある。別の実施形態では、システムは、顧客のコミュニケーションを解釈する際、人間エージェントがどれだけ忙しいかに基づいて、信頼性の閾値を調整することができる。こうすることにより、顧客は、忙しい人間エージェントを待つのではなく、自動化応答を試みるという選択肢を与えられる。

人間エージェントがシステムのコミュニケーションパターンを十分経験したことがある場合、追加の会話管理モードが発生する。この場合、顧客のコミュニケーションが、信頼性レベルが低い遷移に合致すると、人間エージェントは、顧客の質問を、より成功する合致をもたらし得る代替テキストで言い換えることを決定してよい。その場合、会話は、自動化モードで継続してよい。

システムのよって、こうした３つの会話モードを使って管理される、顧客とコンタクトセンターの間の会話は、図３に示すフローチャートによってモデル化される。このフローでは、最初に、ユーザが質問またはステートメントをコンタクトセンターに伝達することによって会話を開始する（２）。次に、コミュニケーションは、テキストにコンバートされる（４）。識別された遷移は、システムによる後続の応答に関する変数データを含み得る。変数データは、顧客の名前でも、識別用番号でもよく、特定のデータタイプ｛ストリング、数字、日付など｝を有する。変数データは（存在する場合は）、顧客のコミュニケーションのテキストから抽出される（６）。変数データを識別するのに、特殊な規則を使ってよい。次に、概念認識エンジンが、残っているテキストをＳ形態素に解析し、こうしたＳ形態素に合致する「概念バッグ」を収集する（８）。次に、システムは、信頼性レベルが最も高い顧客コミュニケーションからの、抽出された概念にその概念が一致する、現在の状態からの遷移を識別する（１０）。遷移中にデータ変数が予期される場合、予期される変数のデータタイプを、抽出された変数のデータタイプと突き合わせることが、比較に含まれる。一致の信頼性が、設定された閾値より高い（１２）場合、システムは、顧客が、識別された遷移をしていると想定する。この場合、システムは、識別された遷移に合致する応答用のデータをルックアップしなければならない場合がある（１４）。たとえば、顧客のコミュニケーションが、営業時間について尋ねる質問の場合、システムは、データベース中で営業時間をルックアップし得る。次に、システムは、特別なデータが応答の一部である場合はそれとともに、合致する応答をユーザに送る（１６）。この応答は、多くの形のコミュニケーションの１つでよい。会話が電話を介したものである場合、システムの応答は、コンピュータ生成による発語でよい。会話がテキストベースの場合、応答はテキストでよい。質問が発語であっても、応答はテキストでよく、その逆でもよい。システムが、十分な信頼性をもって遷移を識別した場合（１２）、コンタクトセンターの人間エージェントは、支援を促される。人間エージェントは、ここまでの会話を提示したグラフィカルユーザインターフェイスを閲覧する（１８）。システムは、人間エージェントに、顧客のコミュニケーションと最も合致する遷移から、最も合致しないものまでの順にランクづけされた、現在の状態からの予期される遷移のリストも示す。人間エージェントは、予期される遷移の１つが、会話の文脈に適しているかどうか判定する（２０）。ある遷移が適している場合、人間エージェントは、その遷移をシステムに示し、システムは、会話を自動化モードで続ける（１４）。あるいは、人間エージェントが、どの遷移も会話の文脈に適していないと判定した場合、人間エージェントは、会話を、その完了まで直接引き継ぐ（２８）。

システムは、動作（ランタイム）モードの間、その知識ベースを拡大し続けることができる。システムは、エージェント支援引継ぎモードにあるとき、人間エージェントと顧客の間の会話のログをとる。定期的に、こうした会話は、知識ベースの初期作成中であるとして処理され、新たな状態遷移シーケンスが、知識ベースに追加される。１つ違うことは、エージェント支援引継ぎモードは一般に、初期状態の後の状態で始まることである。したがって、新たな状態遷移シーケンスの１つは一般に、非初期状態からの遷移として、集約型状態遷移グラフに追加される。新たな状態遷移シーケンスが知識ベース中の集約型状態遷移グラフに追加される度に、集約型状態遷移グラフは、前述したように凝縮される。

システムの一例の実装を、図４に示す。会話サーバ３０は、システムのランタイムエンジンである。会話サーバ３０は、Ｊ２ＥＥアプリケーションサーバ上に展開されるＪａｖａ（登録商標）２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）アプリケーションである。このアプリケーションは、会話スタジオ３２を使って会話サーバに開発され展開される。図４は、会話サーバ３０と会話スタジオ３２の間の関係を示す。

システムは、マルチチャネル会話型アプリケーションである。会話サーバ３０内では、数組の自動化ソフトウェアエージェントが、システムアプリケーションを実行する。マルチチャネルという言葉によって、ここでは、たとえば、ソフトウェアエージェントが、多数の対話チャネル、すなわち電話、ウェブ、インスタントメッセージ、およびｅメールを介して発信者と対話可能であることを意味する。会話型という言葉によって、ここでは、人間エージェントが発信者と行う会話と同様の対話型会話を、ソフトウェアエージェントが発信者と行うことを意味する。システムは、反復アプリケーション開発および実行パラダイムを用いる。上で説明したように、システムアプリケーションをサポートする発信者およびエージェントダイアログは、発信者と、コンタクトセンター内の人間顧客サポートエージェントとの間の実際のダイアログに基づく。

図４は、会話サーバとシステムの他のエレメントとの間の関係も示す。会話サーバ３０は、顧客から発せられたデータを受諾し顧客質問への応答用データを与える企業情報サーバ（３４）と対話する。エージェントワークステーション３６は、会話が融合エージェント支援モードであるときにシステム用の遷移を人間エージェントに選択させるグラフィカルユーザインターフェイスを有するソフトウェアを実行する。エージェント電話３８は、会話がエージェント支援引継ぎモードであるときに、今現在の顧客との口頭会話に人間エージェントが入ることを可能にする。

システムは、システムが展開された後でシステムが通話から学習を行うのを助けるためのプロセスを実装する学習用サーバ３１も含む。学習用サーバ３１については、後で図１７を参照してより詳しく説明する。

会話サーバ３０の内部アーキテクチャを、図５に示す。会話サーバ３０は、システムアプリケーションの論理をサポートする４つの層からなるコアセットを有する。こうした層は、ウェブアプリケーションサーバにおいて従来見られる４つの層である。こうした層は、プレゼンテーション４０、ワークフロー４２、ビジネス４４、および統合４６である。

プレゼンテーション層４０は、エンドユーザへの情報の提示を担当する。Ｊａｖａ（登録商標）Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＪＳＰ）などのサーブレットは、従来、この層で利用されるＪ２ＥＥ技術である。プレゼンテーション層は、対話チャネルサブシステム４８およびエージェント対話サブシステム５０という２つのサブシステムからなる。対話チャネルサブシステム４８は、対話チャネル、すなわちウェブ５２、ＶｏｉｃｅＸＭＬ５４、インスタントメッセンジャーチャット５６、およびｅメール５８それぞれを介した、会話サーバ３０の顧客との対話を扱う。エージェント対話サブシステムは、会話サーバ３０の、コンタクトセンター内の人間エージェントとの対話を扱う。

ワークフロー層４２は、アクションの配列決定を扱う。こうしたアクションは、ビジネス層中のビジネスオブジェクトに対するトランザクションおよびエンドユーザとの対話を含む。会話サーバ３０において、ワークフロー層４２には、顧客と行われている会話を理解するソフトウェアエージェント６０が投入される。さらに、こうしたエージェントは、ビジネス層４４中のビジネスオブジェクトと対話する。ソフトウェアエージェント６０は、会話スタジオ３２（アプリケーション開発システム）によって作られた、マークアップ言語のインタープリタである。

ビジネス層４４は、アプリケーションドメイン向けのビジネスオブジェクトを保持する。Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標）Ｂｅａｎｓ（ＥＪＢ）は、ビジネス層において従来利用されている技術である。会話サーバは、この層にシステム固有技術を導入しない。そうではなく、会話サーバは、Ｊ２ＥＥアプリケーションサーバ上で展開される他のアプリケーションにとっても使用可能な、同じコンポーネントセットを利用する。

統合層４６は、アプリケーションサーバの、データベースおよび外部システムとのインターフェイスを担当する。Ｊ２ＥＥコネクタおよびウェブサービスは、この層において利用される従来技術である。ビジネス層４４のように、会話サーバ３０は、この層にシステム固有技術を導入しない。そうではなく、会話サーバは、従来のＪ２ＥＥコンポーネントを利用する。共通統合層の価値は、外部のシステムを統合するためのどの作業も、Ｊ２ＥＥサーバ上で展開される他のアプリケーションにとって利用可能なことである。

４つの層からなるコアセットの周りに、会話サーバ３０の動作を促進する１組のサブシステムがある。こうしたサブシステムは、展開６２、ロギング６４、コンタクトサーバインターフェイス６６、統計６８、および管理７０である。

展開サブシステムは、システムアプリケーションの反復的ホットデプロイメントをサポートする。このサポートは、会話がログをとられ、会話スタジオ３２にフィードバックされる反復アプリケーション開発に調和し、ここで、コンタクトセンター内の担当者が、システムアプリケーションが理解できなかったフレーズでアプリケーションを増補することができる。

ロギングサブシステム６４は、ソフトウェアエージェント６０が顧客および顧客サポートエージェントと行った会話のログを維持する。このログは、会話スタジオ３２によってサポートされる反復アプリケーション開発プロセスへの入力である。学習用サーバ３１は、ログをとられたこうした通話を用いて、概念認識エンジン（ＣＲＥ）７４用に１つの学習機会セットを生成する。

コンタクトサーバインターフェイス（ＣＴＩ）６６は、いくつかのＣＴＩおよびコンタクトサーバ７２に、統一されたインターフェイスを提供する。

統計サブシステム６８は、人間エージェントの通話取扱い統計を維持する。こうした統計は、ＡＣＤおよび／またはコンタクトサーバ７２によって提供される統計と等価である。コールセンター業務従事者は、こうした統計を用いて、センターが予想しているトラフィックのために働く十分な人間エージェント要員を、センターが確実にもてるようにする。

管理サブシステム７０は、企業内のネットワーク管理担当者によって会話サーバ３０を管理させる。サブシステム７０は、ＳＮＭＰなどの標準ネットワーク管理プロトコルをサポートし、そうすることによって、会話サーバ３０は、ＨＰ ＯｐｅｎＶｉｅｗなどのネットワーク管理システムによって管理することができるようになる。

図６は、システムのワークフロー層４０のコンポーネントを示す。ソフトウェアエージェント６０は、ワークフロー層４０中の主要エンティティである。ソフトウェアエージェント６０は、顧客、コンタクトセンター内の人間エージェント、およびバックエンドシステムと会話をもつ自動化エンティティである。こうした会話はすべて、会話スタジオ３２によって開発され展開されるアプリケーションに従ってもたれる。

ワークフロー層４０に対する機能要件は、以下の通りである。

展開されたアプリケーションのいずれも扱うことが可能なソフトウェアエージェントを会話サーバ３０に割り振り、プールし、利用可能にする。このエージェントプール能力は、ＥＪＢのインスタンスプール能力と同様である。これも、コンタクトセンターの要員管理モデルに調和する。

対話チャネルは、ソフトウェアエージェント６０を割り振り、ソフトウェアエージェント６０が特定のアプリケーションを扱うことを要求する。ワークフロー層４０は、アプリケーションを管理するアプリケーションマネージャと対話する。アプリケーションマネージャは、アプリケーションが利用するべきバージョンを（アプリケーション開発者によって命じられるように）選択することになる。

ソフトウェアエージェント６０は、ライセンスマネージャを調べて、要求側チャネルを介して対話が確実に許可されるようにする。許可されない場合、ソフトウェアエージェント６０は、適切な応答を返す。

ソフトウェアエージェントは、一度に多数のダイアログをもつことが可能である。ソフトウェアエージェントは、応答の解決中に人間エージェントと会話しながら、少なくとも１人の顧客と会話をもってよい。この能力は、一度に多数のチャネルを介して顧客と話すエージェントをもつように拡張することができる。

ソフトウェアエージェント６０は、会話スタジオ３２において開発されたアプリケーションに従って会話をもつ。

ソフトウェアエージェント６０は、概念認識エンジン（ＣＲＥ）７４を呼び出して、顧客の入力を、受け取られた文脈において解釈し、返された結果に作用する。

各ソフトウェアエージェント６０は、それが行っている会話のトランスクリプトを維持する。このトランスクリプトは最終的に、会話ロギングサブシステムを介してログをとられる。トランスクリプトは、すべて適切にタイムスタンプされた以下の情報を含む。
・稼動されるアプリケーション
・以下のものを含む、顧客とのダイアログを通るパス。
○認識されたテキストならびに発話されたフレーズ両方としての顧客入力。
○ダイアログの状態（文脈、遷移など）
○意味認識の結果
○ソフトウェアエージェントが意味認識結果に基づいてとるアクション。
○顧客に送られる出力。

ソフトウェアエージェント６０がとり得るアクションの１つは、人間エージェントの支援を要求することである。このアクションは、人間エージェントとのダイアログに対するサブトランスクリプトを結果としてもたらす。このトランスクリプトは、以下のものを含む。
・通話の開始時点での、エージェントグループに対する待ち行列統計
・電話がかけられ、受けられた時刻
・以下のものを含む、通話に伴うエージェントのアクションのサブトランスクリプト。
○エージェントが支援するか、それとも引き継ぐか
○エージェントが支援する際にとるアクション。たとえば、ソフトウェアエージェント６０によって提示された応答リストから選択し、クエリを調整し、知識ベースを検索して、カスタム応答を作成する。
○検討するための特定の応答、およびエージェントが応答に対して記す注記に、エージェントが印をつけるかどうか。
○ソフトウェアエージェント６０に対するエージェントの命令。
・ワークフロー層４２は、ソフトウェアエージェント６０のプール（群）の統計を生じることになる。こうした統計は、統計サブシステム６８を介して公開されることになる。
・ワークフロー層４２を支配する操作パラメータ（たとえば、最小および最大エージェント／アプリケーション、成長量）が、管理サブシステム７０を介して管理される構成データベースから取得されることになる。

図６は、ワークフロー層４２を構成するコンポーネント、すなわちエージェントマネージャ７６およびエージェントインスタンスを示す。エージェントマネージャ７６は、エージェントインスタンスのプーリングと、特定のアプリケーション用のそうしたインスタンスの割振りとを扱う。エージェントマネージャ７６は、会話サーバ３２を構成する他のマネージャ／サブシステムとの対話を担当する（統計サブシステム６８とのエージェントマネージャ７６の対話については図示せず）。各エージェントインスタンス６０は、ロギングマネージャ７８を使って、会話トランスクリプトのログをとる。

プレゼンテーション層は、対話チャネル４８およびエージェント対話サブシステム５０という２つのサブシステムからなる。

会話サーバによってサポートされる対話モード、すなわちＨＴＭＬ８０、ＶｏｉｃｅＸＭＬ８２、インスタントメッセンジャー８４、およびｅメール８６それぞれに関連づけられた対話チャネルがある。対話チャネルサブシステム４８は、Ｃｏｃｏｏｎ ＸＳＰ処理インフラストラクチャを基礎として組み立てられる。対話チャネル４８の処理を、図７に示す。対話チャネルの機能要件は、以下の通りである。
・顧客（エンドユーザ）との各会話向けに対話セッションを開始し、維持し、終了する。そのセッションの一部として、対話チャネルは、顧客とのダイアログの状態を管理するエージェントインスタンスを保持することになる。
・着信ユニフォームリソースロケータ（ＵＲＬ）から、チャネルタイプおよびアプリケーションを判定する。ＵＲＬは、ｈｔｔｐ：／／ｈｏｓｔ ａｄｄｒｅｓｓ／ａｐｐｌｉｃａｔｉｏｎ ｎａｍｅ．ｍｉｍｅ ｔｙｐｅ？ｐａｒａｍｅｔｅｒｓの形をとってよく、ｈｏｓｔ ａｄｄｒｅｓｓ＝ＩＰアドレスおよびポート、ａｐｐｌｉｃａｔｉｏｎ ｎａｍｅ＝アプリケーションの展開された名称、ＭＩＭＥ ｔｙｐｅ＝チャネルタイプ（たとえば、ｈｔｍｌ、ｖｘｍｌなど）を示し、ｐａｒａｍｅｔｅｒｓ＝要求パラメータである。
・ＨＴＭＬおよびＶｏｉｃｅＸＭＬチャネルが、エージェントに処理用のＨＴＴＰ要求を渡すこと。ＩＭおよびｅメールチャネルが、等価な要求処理ステップを実施すること。
・チャネル非依存応答を、適切なドキュメント定義言語（ＨＴＭＬ、ＶｏｉｃｅＸＭＬ、ＳＩＭＰＬ、ＳＭＴＰなど）を使ってチャネル固有応答に変換すること。この変換は、ＸＳＬスタイルシートによって支配される。応答および処理用スタイルシートの定義は、アプリケーション定義の一部であり、エージェントによって、各要求処理呼出しへの返答に入れて返される。

応答およびＸＳＬスタイルシートの定義は、３つのユースケースに分かれる。対話チャネルは、こうしたユースケースを特に意識していない。

応答ドキュメントおよびＸＳＬスタイルシートは、アプリケーション用のチャネル単位で定義される。応答ドキュメントは、ＣＭＬ＜ｏｕｔｐｕｔ＞タグの内容ならびにＣＭＬから生成された他の人工物（たとえば、文法ファイル）を要求する。

「ファイル」ユースケースにおいて、ユーザは、アプリケーション内で応答ドキュメントを定義する。応答ドキュメントは、チャネルで定義されるＸＳＬスタイルシートを使って処理される。応答ドキュメントは、応答ドキュメントを支配するＤＴＤに付随しなければならない。このＤＴＤは、マルチフィールドフォームを定義させるようにする。

「オープン」ユースケースにおいて、ユーザは、応答ドキュメントならびにＸＳＬスタイルシートを定義する。いずれにドキュメントにも制約は課されず、会話サーバ３０は、応答の処理に関するどの結果についても責任をもたない。

この変換は、チャネル固有ドキュメント言語への変形およびある特定のクライアントに対する応答の印づけの両方を扱う。

ＶｏｉｃｅＸＭＬチャネル５４に対して、対話チャネル８２は、記録される顧客要求のロギングと、会話ログに含め、かつ／または人間エージェントに小声で受け渡すためのエージェントへの、記録用の場所の通知とを担当する。

前述したように、対話チャネルサブシステム４８は、Ｃｏｃｏｏｎインフラストラクチャを用いて実装される。Ｃｏｃｏｏｎインフラストラクチャは、ウェブアプリケーションサーバインフラストラクチャのプレゼンテーション層４０中でモデル−ビュー−コントローラパラダイムを提供する。

サーブレット９０（コントローラ）が、ＨＴＴＰ要求を扱い、要求を処理するためにエージェントインスタンス６０と対話する。エージェントインスタンス６０は、ドキュメントの出力に適用するための応答ＸＳＰドキュメントおよびＸＳＬスタイルシートを返す。

ＸＳＰドキュメント（モデル）は、サーブレット９２としてコンパイルされ実行される。ドキュメントは、エージェントインスタンスに対して、その出力、すなわちＸＭＬストリームを生じるためのパラメータを要求する。ＸＳＰドキュメントは、ＪＳＰドキュメントの等価物である。ＪＳＰ処理のように、ＸＳＰコンパイルは、ＸＳＰドキュメントが、最後にコンパイルされたときから変化した場合にのみ起こる。

ＸＭＬストリームは、ＸＳＬスタイルシート（ビュー）に従って、対話チャネル特有の言語（たとえば、ＨＴＭＬ、ＶＸＭＬ）に変形される。

人間エージェント対話サブシステム（ＡＩＳ）は、コンタクトセンター内の人間エージェントとのダイアログの確立、ならびに不確かな応答を解決するための、ソフトウェアエージェントと人間エージェントとの間の協調の管理を担当する。サブシステムは、アプリケーションにおいてアプリケーションの転送が要求されるときにも使われる。エージェント対話サブシステムは、ＣＴＩサーバインターフェイスと対話して、コンタクトセンター内での接続を実行する。ＣＴＩサーバインターフェイスはまた、エージェント対話サブシステムに、エージェントグループとの接続に対してその挙動を変える可能性がある待ち行列統計を提供する。

エージェント対話サブシステム（ＡＩＳ）は、以下のアクションを行う。
・問題となっている応答を解決するために、コンタクトセンター内の人間エージェントとのダイアログを開始し、維持し、終了する。人間エージェントは、この特定のアプリケーション用の解決を扱うように指定された、特定エージェントグループのメンバである。
・エージェントとのダイアログの開始の一部として、ＡＩＳは、応答の解決において人間エージェントのデスクトップアプリケーションを協働させるエージェントセッションにハンドルを割り振り、渡す。
・ＡＩＳは、人間エージェントのデスクトップアプリケーションが以下のものを取得できるためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。すなわち、顧客要求および現時点で解決を必要とする応答案と、解決要求につながった閾値設定、および解決要求が、優良応答が多過ぎることによるのか、それとも優良応答がほとんどないことによるのかということと、顧客の対話チャネルタイプと、今までの会話のトランスクリプトと、この顧客会話に関連づけられたワークフローの現在の状態、たとえば、人間エージェントがこの会話中で支援を行った回数、顧客がソフトウェアエージェントと話していた時間の長さ、顧客が会話に関わっていた状態（文脈）、可能性としては、会話の状態および時間に基づく何らかの進行測度と、現在のアプリケーション（およびネットワーク）プロパティとである。
・ＡＩＳ ＡＰＩはまた、人間エージェントに、顧客に返すべき応答を選択させ、要求を修正させＭＲＥデータベースを検索させ、可能性としては、顧客に返すべき応答を選択させ、ソフトウェアエージェントから通話を引き継がせ、検討用の要求／応答対話を会話ログ中に示させ、対話に注記を関連づけさせる。
・ＡＩＳ ＡＰＩはまた、人間エージェントをコンタクトサーバ７２にログイン／ログアウトさせ、コンタクトセンター待ち行列を参照してその作業状態を管理させるためのＪＴＡＰＩインターフェイスを公表する。
・ＡＩＳ ＡＰＩは、いくつかの実装技術からアクセスされるようにするための言語非依存フォーマットを利用する。
・ＡＩＳは、ＶｏｉｃｅＸＭＬサーバ５４からコンタクトセンターまでのボイスコールの経路指定、およびそうしたボイスコールの、特定のエージェントセッションとの後続の関連づけをサポートする。
・ＡＩＳは、アプリケーション設計者に、人間エージェントへのアプリケーションデータの提示を定義させる。この提示は、対話チャネル（８２、８４、８６、または８８）において利用される、同じＸＳＬ処理を用いるはずである。

人間エージェント対話サブシステムの一部は、コンタクトセンターエージェントに解決通話を扱わせるエージェントデスクトップアプリケーションである。このアプリケーションは、２つの形をとる。
・汎用的な人間エージェントデスクトップ：このデスクトップは、統合されていない顧客関係管理（ＣＲＭ）環境において動作し、ＣＴＩおよびＣＳサーバに接続されたエージェントのデスクトップ上で、個別プロセスとして稼動する。
・ＣＲＭコンポーネント：このデスクトップは、ＣＲＭパッケージの文脈において稼動するコンポーネント（ＡｃｔｉｖｅＸコンポーネントまたはＡｐｐｌｅｔ）としてパッケージされる。

音声認識は、人間が発話した言葉をテキストに自動コンバートする技術である。多くの音声認識システム例がある。顧客が電話を介して談話するシステムの実装形態において、（オンラインＡＳＲによって実施される）音声認識は、適切な応答を有する、顧客のコミュニケーションを突き合わせる際の第１のステップである。典型的な音声認識は、有意義な音素を抽出するための、発語への信号処理技法の適用を伴う。次に、ソフトウェア検索エンジンが、こうした音素から構成することも可能な辞書から単語を検索するのに使われる。システムの音声認識部分は、この検索を、コミュニケーションの有望な文脈の知識によってガイドする。システムのこの音声認識部分のブロック図を、図８に示す。前述したように、システムは、顧客とコンタクトコールセンターの間の標準的な会話の状態遷移グラフを定義するマークアップ言語、すなわちＣＭＬからなる知識ベースへのアクセス権を有する。ソフトウェアエージェントは、会話の現在の状態を追跡するので、この状態からの有望な遷移すべてをルックアップしてよい。こうした遷移はそれぞれ、「概念バッグ」または「Ｓ形態素バッグ」１０４を有する。こうしたＳ形態素１０４は、合致するテキスト１１２にコンバートすることができる。有望な遷移すべてからの、合致するテキストの集約は、辞書にある単語すべてのサブセットである。概して、グループ全体ではなく、グループのサブセットと突き合わせようとして検索することが、より効率的である。したがって、この音声認識装置用の検索エンジン１０２は最初に、顧客のコミュニケーションの音素を、有望な遷移すべてにあるテキスト１１２と突き合わせようと試みる。検索エンジン１０２は、このテキストと突き合わされなかった音素の、残っているどの組合せも求めて、辞書を検索する。

システムのいくつかの実装形態において使われる概念認識エンジン７４（図５に示す）は、テキストおよびオーディオソース両方にあるユーザの自然言語質問を、堅牢で言語非依存なやり方で理解するための高度な自然言語処理技術である。この技術は、文字通りの言い回しではなく、情報の意味、すなわち意味的文脈に基づいて、情報を自動的に索引づけ、対話する。概念認識エンジンは、人々が現実に話し、タイプ入力するやり方を理解し、システムがインテリジェントなやり方で、言葉遣いにも言語にもよらず、ユーザを複雑な会話に引き込むことを可能にして、所望の情報へのアクセスを容易にする。

概念認識エンジンは、フレーズの形態素レベルの分析に基づき、詰め込まれた意味の主成分の「理解」をもたらすことを可能にする。この技法は、極めて正確であり堅牢であることに加えて、計算効率がよく、従来の自然言語技術より速く、言語非依存である。

自然言語処理を適用する他のほとんどのシステムは、統語分析を用いて、ユーザの入力に対する同義フレーズを探す。分析は最初に、極めて大きい語学辞書を使って、フレーズ中のあらゆる単語、または単語の成分を識別する。次に、システムは、こうしたエレメントを、固定リスト中の具体的なエントリ（すなわち、単語またはキーワード索引）と突き合わせることを試みる。その結果、こうしたシステムは、文字列レベルに基づく一致を用いる。少なくとも一文字が目標索引エントリと異なる場合、一致は失敗する。システムのいくつかの実装形態において使われる概念エンジンを用いると、マッピングは、一定の単語、フレーズまたは単語エレメントのセットには基づかず、一定の概念セットに基づく。

意味処理に重点を置いた結果として、概念認識プロセスは、本質的に堅牢である。すなわち、このプロセスは、「ノイズのある」入力データと、極めてうまく動く。これは、システムの、発話された単語を、音声認識ソフトウェアを使って認識する能力にとって有用である。システムは、よくあるタイプミス、音声認識ソフトウェアによって生成されるエラー、または文脈に沿わない単語に関わらず、実世界での会話型対話における意味を正確に認識するためのプロセスを利用する。ユーザは、単語をどのように組み合わせて言ってもよく、システムは、ユーザの意図を理解できる程度に十分に柔軟である。

概念認識エンジンは、意味ラベルを作成し比較するアルゴリズムに基づく。任意の長さである１つのテキストに対する意味ラベルは、その意味の最も重要な成分を取り込む短いコード化である。ソースデータストア（群）内の項目は、意味タグで示されるとき、自由形式の音声またはテキストクエリあるいはこうした入力テキストソース中で実際の単語および句読法に依存しない他の入力テキストソースに選択的にマップすることによって、他のやり方で取得することも、管理することもできる。たとえば、システムに「Ｈｏｗ ｃａｎ Ｉ ｂｒｉｎｇ ｂａｃｋ ｐａｎｔｓ ｔｈａｔ ｄｏｎ’ｔ ｆｉｔ？」と尋ねるユーザには、正しい情報がどこにも「ｐａｎｔｓ」も「ｂｒｉｎｇ ｂａｃｋ」という単語も含まない場合であっても、組織のリターンポリシーデータベースにある適切な情報が与えられることになる。あるいは、同じ情報を求める言葉で表現されたユーザクエリは、入力ストリング中で使われる実際の単語によらず、同じリターンポリシーに概念的にマップされる。

この手法は、統計的言語モデル自動音声認識（ＳＬＭ ＡＳＲ）ソフトウェアの利点と、有限状態文法ＡＳＲの間の差を埋める。この技術は、自然言語処理アルゴリズムである概念認識エンジン（ＣＲＥ）と呼ばれる。

概念認識エンジン（ＣＲＥ）は、テキストおよびオーディオソース両方にあるユーザの自然言語質問の、堅牢で言語非依存なやり方での理解をもたらす。この技術は、文字通りの言い回しではなく、情報の意味、すなわち意味的文脈に基づく、情報の索引づけ、マッピングおよび対話のための高度な自然言語処理技術である。他の自然言語における取組みの大勢とは反対に、この技術は、テキストの十分な「理解」をもたらそうと試みる際、フレーズの完全な形式的言語分析に依拠しない。そうではなく、この技術は、詰め込まれた意味の主成分の「理解」をもたらすことを可能にする、フレーズの形態素レベルの分析に基づく。

形態素は、意味、すなわち意味的文脈を含む最小の言語単位と定義される。単語は、１つまたはいくつかの形態素を含んでよく、形態素はそれぞれ、単一または多数の意味を有し得る。この比較的単純な例は、ｇｅｏｇｒａｐｈｙという単語を使って示され、この単語は、地球を意味するｇｅｏ、および図を意味するｇｒａｐｈという形態素からなる。こうした別個の２つの形態素は、結合されると、地球に関する学問という概念的意味を形成する。したがって、個々の意味単位は、通常のコミュニケーションにおいて容易に理解される新たな概念を形成するように結合することができる。

この技術は、意味ラベルを作成し比較するアルゴリズムに基づく。任意の長さである所与の１つのテキストに対する意味ラベルは、その意味の最も重要な要素を取り込む短いコード化である。「データベース」中の項目は、意味タグで示されるとき、選択的に取得することも、入力ストリング中で使われる実際の単語および句読法によらない、ユーザ生成による自由形式のテキストクエリまたは他のタイプの入力テキスト列を構文解析することによって、それにマップすることもできる。

ＣＲＥは、ＳＬＭ ＡＳＲと協力して、結果として生じるエンジン出力を分析し、意味ラベルを割り当てることによって文脈を判定し、意味ラベルは次いで、会社情報の索引づけられたデータベースと比較することができる。さらに、ＣＲＥは、通常は誤認識される単語（重要でない単語）を無視し、より文脈に重点が置かれた単語をその分析において使うことによって、音声認識エラーの影響を抑えるのを助ける。したがって、ＣＲＥの影響は、よくあるタイプミスにも音声認識ソフトウェアによって生成されるエラーにも関わらず、実世界での会話型対話における意味を正確に認識するセルフサービスシステムを可能にすることである。より簡単に言うと、こうした２つの技術の組合せにより、システムが、人間が意味することを理解することによって、人間の言うことを認識することが可能になる。

設計時に、ＣＲＥは、ユーザによって検索され取得されるデータを自動的に索引づける。会話型アプリケーションでは、このデータは、コールセンターエージェントとの顧客会話の転記された記録であるが、どのテキスト情報セット（ドキュメント、よくある質問（ＦＡＱ）の列挙、データベース、チャットスレッド、ｅメール中の自由テキスト情報など）も、ＣＲＥを使って索引づけることができる。索引づけは、ＣＲＥがデータを、その概念上の類似に従ってグループ化し、または「クラスタ化」するためのプロセスである。従来のアルファベット順の索引とは違い、ＣＲＥによって作成されるクラスタは、概念空間と呼ばれる多次元空間に格納される特殊な概念参照である。こうしたクラスタは、特殊化された非常に大きい概念データベースを手作業で作成し維持する必要なく、どの概念の記述も生成するように結合することができる１つの主要原子概念セット（意味の基本ビルディングブロック）を用いて「ラベルづけ」される。概念の索引づけは、情報が、単語ではなくその意味に基づいて検索され、または管理されることを可能にするので、はるかに効率的で、耐障害性があり、インテリジェントなダイアログ管理アプリケーションを開発することができる。このクラスタ化プロセスを介して、ＣＲＥは、クラスタの間の遷移（すなわち通話の流れ）も抽出し、後で自由形式の顧客照会を、通話ログに見られるエージェント応答にマップする索引を生成する。

ランタイムには、いくつかの例では、ＣＲＥは、この同じプロセスを、顧客の照会に対してリアルタイムで実施する。ＣＲＥは、音声認識エンジンから出力を取出し、形態素分析技法を用いて、関連づけられた形態素セットに分解する。システムは、誤綴り、句読法の誤り、および文脈違いまたは語順違いを含む乱雑な入力データをうまく扱い、入力フレーズの長さに対して制限は予め設定されていない。

ＣＲＥは次いで、概念分析を用いて、形態素を上述した主要原子概念にコンバートし、この原子概念セットを、入力全体に対する単一の概念コードに組み立て、次いで、そのコードを、索引づけられたデータ中のそれと等価なコードにマップする。会話型アプリケーションでは、このプロセスは本質的に、システム応答でよいシステムダイアログ状態、既存の対話型音声応答（ＩＶＲ）メニューツリー、またはトランザクションシステムに顧客口座情報を照会するための命令に、ユーザ入力を「向ける」。

このプロセスは、コンタクトセンターセルフサービスアプリケーションの文脈においてかなり多義的な会話型ユーザクエリを自動的に認識し「理解する」堅牢な手段をもたらす。

このＣＲＥおよびＳＬＭ音声認識の組合せの影響は、自動化を介して、顧客に対して情報を利用可能にするための能力を高めることである。５つの選択肢があるＩＶＲメニューにも予め定義された発語文法にもきれいに収まらない企業情報は、会話型インターフェイスを介して利用可能にすることができる。結果として得られる顧客入力は、それに関連づけられた文脈を有するので、システムがどの程度インテリジェントなやり方で複雑な対話を扱うかに関するより多くの選択肢が利用可能になる。

単語空間ではなく意味要素空間への、ベクターモデル手法の応用は、以下の利益をもたらす。
１．単語から概念への遷移自体が、より統計的なものからより意味的なものへ移行する。
２．従来のベクターモデルはしばしば、単語の間のどの統語的または意味的関係も無視するモデルの組合せ文字を協調するための「単語モデルのバッグ」と呼ばれる。類推によって、ベクターモデルを「概念モデルのバッグ」と呼ぶことができる。従来のベクターモデルでは、自分たちの興味がある内部パラメータ、すなわち概念に統計的に関連づけられたいくつかの外部パラメータ（単語）を計算する。ベクターモデルでは、概念を直接計算する。
３．意味要素の数が、基本言語においてさえも単語の数よりはるかに少ない限り、ベクターモデルにおける計算強度は、はるかに低くなる。信頼性に基づく合致の順位を形成するのに、他の機械学習技法を用いてもよい。たとえば、決定木の導入またはサポートベクターマシンの構成を用いることもできよう。増強を用いた学習技法の組合せも可能であろう。

入力言語テキストオブジェクト＞意味ラベル＞出力言語テキストオブジェクトという、全体で２ステップのサイクルのモデル作業からなる個別部分について上述した。サイクル中の２つのステップは、明らかに独立していることに注目されたい。こうしたステップは、人間の言語のいずれにもに関連づけられない内部「言語」である意味ラベルを介してのみつなげられる。この特徴は、どのアプリケーションにおいても、入力および出力側両方において言語を変えることを可能にし、比較的容易にする。

第１のステップは、本質的に言語依存である。これは、異なる言語への切換えが、所与の言語におけるフレーズに対する意味ラベルの自動生成を必要とすることを意味する。この後で、この問題の可能な２つの解決法を説明する。第２のステップは、意味索引に基づく。索引自体は、オブジェクトの言語を気にせず、単にオブジェクトをポイントするだけであり、ポインタに関連づけられた意味ラベルは言語非依存である。意味索引には、言語固有情報はない。

第１の手法は、新たな言語用の新たなＳ形態素辞書を編纂することである。人間が書いた各言語ごとに、１つのＳ形態素セットを編纂することができる。編纂プロセスは、テキストの大きいコーパスまたはこの言語の大型辞書にある語彙の分析に基づき得る。

このような、ある言語（英語）での完全なＳ形態素セットをもつことは、別の言語での同様のＳ形態素セットの作成に有用である。開始点として、単に第２の言語における形態素上の等価物を探すことを試みてもよい。こうすることにより、第２の言語での、それ以外の労働集約的なコーパス分析の作業が削減される。これは、特に同じ言語グループ内で言語から言語へと移るときに成り立つ。というのは、このような言語は、たくさんの語彙「原料」を共有する。スペイン語のＳ形態素セットは、英語のものとほぼ同じサイズである。スペイン語のＳ形態素の例は、ＬＥＮＧＵ、ＦＲＡＳ、ＭＵＬＴＩ、ＥＳＰＡＮ、ＳＩＧＵＩである。

等価物の探索の後、Ｓ形態素識別のアルゴリズムのある程度の調和が必要となる場合がある。このアルゴリズムに関する好材料は、そのジョブのほとんどが、同じグループの言語に共通なことである。アルゴリズムを全く変えずに英語からスペイン語に切り換えるときでも、結果は満足できるものである。何らかの変更が必要とされる場合でも、印欧言語のほとんどに対しては変更はわずかである。スペイン語の実験によりシステムの言語間能力の力量が証明された。すなわち、スペイン語の形態素を編纂した後、入力言語としてのスペイン語が、以前英語用に開発されたすべてのアプリケーションに対して可能になった。

概念認識エンジンに必要とされる情報を格納するのに、言語知識ベースが使われる。この知識ベースは、３つの主成分、すなわち意味要素辞書、Ｓ形態素辞書および同義語辞書を有する。意味要素辞書の各エントリは、以下を含む。
ａ）意味要素名、
ｂ）意味要素の定義／記述、
ｃ）この意味要素を使う単語概念コードの例。
Ｓ形態素辞書の各エントリは、以下を含む。
ａ）Ｓ形態素テキスト、
ｂ）個別部分、すなわち複数の韻律単位からなる形態素の代替的意味からなる意義素を有する意味要素概念コード、
ｃ）多要素コード中に、修正を加えることができる先頭要素用のラベル。

概念認識エンジンの機能ブロック図を、図９に示す。この図のブロックは、以下のように説明される。Ｓ形態素辞書１２２および意味要素辞書１２４は、アナライザ１２８によって、１組の概念コードを生じるのに使われる。

次に、ＣＭＬファイルが、例１４２に基づいて生成される。これは、シソーラスに基づく、データ駆動型であるＣＭＬファイルを生じる。次のステップは、ＣＭＬファイルのルックアップおよび編集を行うことである。このルックアップおよび編集は、以下のステップからなる。
ａ）異なる検索基準を有するストリング発生を表示するステップ、
ｂ）新たな言換えを追加するステップ、
ｃ）新たなペアの質問と回答を追加するステップ、
ｄ）１つの言換えまたはいくつかの言換えを削除するステップ、
ｅ）１つの質問と回答ペア（すべての言換えを有する）またはいくつかのペアを削除するステップ、
ｆ）２つの質問回答ペア（入力および出力フレーズの選択を有する）をマージするステップ、
ｇ）入力および出力フレーズを割り当てることを伴う、１つのペアを２つのペアに分割するステップ、
ｈ）フレーズを編集するステップ（グループ編集を含む）。

次に、ＣＭＬファイルが、どの編集時点でも入力情報として取り出され、索引が組み立てられる。続いて、２つのエントリが突き合わされ、特定されたＣＭＬ／索引を用いた類似計算が行われる。これは、２つのフレーズと、２つの概念コードと、１つのフレーズおよび１つの概念コードと、入力の１つが毎回フィードファイルから届く周期的モードでの、２つのフレーズ、２つの概念コード、または１つのフレーズおよび１つの概念コードと、入力の１つが毎回フィードファイルから届き、結果が出力ファイルに格納される自動突合せおよび類似度計算に対して行うことができる。次に、事前分析による構文解析が、名前に対する擬似要素を作成し、単一語および複合語の個人名を処理し、単一語および複合語の事業および製品名を処理し、品詞タグを生成することによって行われる。

この時点で、アプリケーション制御およびテストが実施される。これは、以下のステップからなる。
ａ）入力会話のファイルを、周期的かつ自動的に分析し、同じファイルの以前の処理との違いが、表示され、または出力ファイルに送られる。
ｂ）類似閾値の制御、
ｃ）デルタ間隔（第１および第２の合致の間の類似の差）、
ｄ）返される合致の数の制御。

会話マークアップ言語（ＣＭＬ）の主目標は、顧客との「会話」を自動化または半自動化された方式で扱う会話サーバへの１組の命令を指定することである。自動化会話は、最初から最後まで、全体が会話サーバによって扱われるものである。半自動化会話は、最初は会話サーバによって扱われ、次いで、収集されたどの情報も伴って、人間エージェントに受け渡される。

ＣＭＬは、以下を指定するマークアップ言語である。
・会話サーバが処理することができる言換えを含む顧客入力。
・応答するべき会話サーバ出力（たとえばＴＴＳおよび／またはオーディオファイル）
・会話の流れ。この流れは、以下を含む１組の状態遷移ネットワークを使って記述される。
○各入力および出力が起こり得る文脈。
○顧客入力およびＪａｖａ（登録商標）オブジェクトからの結果に基づく、他の文脈への遷移。
○バックエンドビジネス層オブジェクトへの通話
○インライン適用論理
会話サーバとユーザの間の会話を記述するＣＭＬ言語に加えて、ＣＭＬＡｐｐ言語は、再利用可能コンポーネントからアプリケーションを構成させる。

いくつかの例では、ＣＭＬは、以下を含む、特定の顧客サポートコンタクトセンターにおいて一般に見られる要求／応答対話を記述する。
・たとえば株価、趣意書要求など、一般的な情報要求。
・たとえば勘定残高、トランザクション履歴など、顧客固有の要求。
・たとえば株／資金トランザクションなど、顧客開始したトランザクション。
・たとえばテレマーケティングなど、センターが開始した対話。
ＣＭＬは、会話サーバ（ＣＳ）によって解釈され実行されるように設計される。上で説明したように、ＣＳは、アプリケーションに基づいてＣＭＬを解釈するソフトウェアエージェントセットを有する。こうしたエージェントは、ＨＴＭＬ、ＶｏｉｃｅＸＭＬ、ＳＩＭＰＬ、ＳＭＴＰなどのチャネル固有ドキュメント言語と、ＣＭＬのチャネル非依存表現との間を、かつその逆に変換する１組の対話チャネルに対面する。

ＣＭＬドキュメント（またはアプリケーションと呼ばれる１組のドキュメント）が、ユーザとのソフトウェアエージェントのダイアログを記述する会話型状態遷移ネットワークを形成する。ユーザは常に、一度に１つの会話状態、すなわち文脈の中にいる。１組の遷移が、ダイアログが新たな文脈に移るための条件を定義する。こうした条件は、ユーザからの新たな要求、ダイアログ中の特定の状態、またはこの２つの組合せを含む。実行は、最後の文脈に到達した時点で終了する。

ソフトウェアエージェントとユーザの間のダイアログである状態遷移ネットワークを定義するのに、４つのエレメント、すなわちネットワーク、文脈、下位文脈、および遷移が使われる。

ネットワークとは、ソフトウェアエージェントがユーザと行うダイアログを定義する文脈（状態）および遷移の集合体である。各々が、参照用の一意の名前をもつ１つのＣＭＬドキュメントごとに、１つまたは複数のネットワークが存在し得る。ユーザとのダイアログのシンタクスの定義に加えて、ネットワークは、ネットワークが活動的に実行している間にアクティブである１組のプロパティを定義する。こうしたプロパティは、ユーザへの出力に提示されているデータ、ならびにネットワークの実行を支配するデータを保持する。たとえば、遷移の事前条件および文脈の事後条件は、プロパティの観点で定義される。

文脈は、ソフトウェアエージェントとユーザの間のダイアログ中の状態を表す。あらゆる文脈が、アプリケーションを別の文脈に動かす（または同じ文脈に逆戻りさせる）、定義された１組の遷移を有する。文脈は、ユーザの要求が予期され、解釈されることになる状態を表す。特定の文脈が、最終として印づけられる。最終文脈は、ネットワークによって表されるダイアログの終わりを表す。

下位文脈とは、包含側ネットワークの文脈において別のネットワークが呼び出される特殊な文脈である。下位文脈は、リンクされたサブルーチン通話であり、起呼側および非呼側ネットワークのプロパティの束縛がある。下位文脈は、モード方式でも非モード方式でもよい。モード方式の下位文脈では、その包含側ネットワーク（または上位クラス）の遷移はアクティブでない。非モード方式の下位文脈では、その包含側ネットワーク（および上位クラス）の遷移はアクティブである。

遷移は、ある文脈から別の文脈への変化を定義する。遷移は、その事前条件が満たされ、かつ／またはユーザ要求が、遷移に関連づけられた発声のクラスタに合致する場合にとられる。遷移が事前条件を定義しない場合は、ユーザ要求と遷移の発声との間の合致のみが、遷移をトリガするのに必要とされる。遷移が発声のクラスタを定義していない場合、遷移は、その事前条件が成り立つ場合は常にトリガされる。事前条件も発声のクラスタも定義されていない場合、遷移は自動的にトリガされる。遷移のトリガは、遷移のスクリプトの実行および遷移によって指示される文脈への遷移を引き起こす。

いくつかの例では、ＣＭＬアプリケーションは、単一ＣＭＬＡｐｐドキュメント、単一ＣＭＬドキュメント、および１つのクラスタドキュメントを必要とする。複数ドキュメントアプリケーションは、単一ＣＭＬＡｐｐドキュメント、単一クラスタドキュメント、多数のＣＭＬドキュメントを伴う。図１０は、ＣＭＬＡｐｐドキュメント１５０、ＣＭＬドキュメント１５４、クラスタドキュメント１５２、出力ドキュメント１５６、被参照データファイル１５８、およびビジネスオブジェクト１６０の関係を示す。

付表１は、「ａｂｃ１２ａｐｐ．ｕｃｍｌａという名称のＣＭＬＡｐｐドキュメント、「ａｂｃ１２ｃｌｕｓｔｅｒｓ．ｕｃｍｌｃ」という名称のＣＭＬクラスタドキュメント、および「ａｂｃ１２ｕｃｍｌ．ｕｃｍｌ」という名称のＣＭＬドキュメントの例のテキストを説明する。ＣＭＬＡｐｐドキュメントは、マークアップ「ｃｌｕｓｔｅｒＦｉｌｅ」を使ってクラスタファイルを、マークアップ「ｄｏｃｕｍｅｎｔ」を使ってＣＭＬファイルを指定する。ＣＭＬＡｐｐドキュメントは、マークアップ「ｃｈａｎｎｅｌ ｔｙｐｅ」を使って、顧客とのコミュニケーションチャネルも指定する。この場合、チャネルタイプは、「ＶＸＭＬ」である。最初に、クラスタドキュメントは、所与の状態または文脈からの所与の遷移用の１つのクラスタにグループ化された、顧客からの、記録されたコミュニケーションすべてのテキストを格納する。このクラスタドキュメント例では、クラスタは、ｃ１〜ｃ４１と命名される。クラスタに関連づけられたデータ変数は、マークアップ「ｖａｒｉａｂｌｅ」を使って特定され、「ｐｒｏｐｅｒＮａｍｅ」および「ｄｉｇｉｔＳｔｒｉｎｇ」のような型をもつ。こうしたクラスタは、ＣＭＬドキュメント例において参照される。ＣＭＬドキュメントは、状態遷移グラフ（またはネットワーク）を定義する。ＣＭＬドキュメント例は、１組の状態（マークアップ「ｃｏｎｔｅｘｔ ｎａｍｅ」で示す）および遷移（マークアップ「ｔｒａｎｓｉｔｉｏｎ ｎａｍｅ」で示す）を定義する。たとえば、ＣＭＬドキュメントの１１〜１６行は、以下の通りである。

１１〜１６行は、状態（または文脈）ｓ１への遷移ｔ０を有する状態（または文脈）ｓ０があることを指定する。遷移ｔ０は、顧客のコミュニケーション「ｙｅａｈ Ｉ’ｄ ｌｉｋｅ ｔｏ ｃｈｅｃｋ ｏｎ ｔｈｅ ｍｙ ａｃｃｏｕｎｔ ｂａｌａｎｃｅ ｐｌｅａｓｅ」およびコンタクトセンターの応答「ｄｏ ｙｏｕ ｈａｖｅ ｙｏｕｒ ａｃｃｏｕｎｔ ｎｕｍｂｅｒ ｓｉｒ」を有する。図１１は、ＣＭＬドキュメント例によって定義される全体的状態遷移グラフのサブセットを示す。このサブセットは、初期状態からｓ０（１６２）、次にｓ１（１６４）、次にｓ２（１６６）、次にｓ３（１６８）、次にｓ４（１７０）、次にｓ５（１７２）、次にｓ６（１７４）そして最後にｓ７（１７６）への遷移を含む。

図１２を参照すると、自動化音声応答システム用ＣＭＬアプリケーションの開発のためのプロセス１８０は、初期アプリケーション開発プロセス１８２およびランタイム学習プロセス１９０という２つの主要機械学習プロセスを含む。初期アプリケーション開発プロセス１８２は、記録された人間エージェント−発信者間の会話サンプルを使って、初期ＣＭＬアプリケーションを生成する。ランタイム学習プロセス１９０は、記録されたシステム−発信者間の会話サンプルを使って、ＣＭＬアプリケーションを絶えず改良する。

人間エージェント−発信者間の転記された会話セット１８１が、初期アプリケーション開発プロセス１８２に入力される。エージェント−発信者間の転記された会話１８１は、手動転記または自動化転記プロセス（たとえば、従来の音声認識プロセス）を用いてテキストに転記されている、人間顧客サポートエージェントと発信者の間の、記録された会話である。人間エージェントおよび発信者が電話でコミュニケーションを行ったコンタクトセンターにおいて、エージェントと発信者の間の会話のサンプルは、コンタクトセンターの品質保証音声記録機構から取得することができる。一実装形態では、サンプルである、人間エージェント−発信者間のトランスクリプトは、初期アプリケーション開発プロセス１８２に供給されるときには、インポートマークアップ言語（ＩＭＬ）ファイルの形である。

初期アプリケーション開発プロセス１８２は、サンプルトランスクリプトを使って、初期ＣＭＬアプリケーションを組み立てる。初期アプリケーション開発プロセス（図１５〜１６でより詳しく説明される例）は、以下の３つのフェーズを伴う。

１．分類器の組立て：このフェーズにおいて、エージェント発声および発信者の発声に対する１組の分類器が、記録された人間エージェント−発信者間の会話のサンプルを使って構築される。アプリケーションが展開されオンラインになると、こうした分類器は、発信者の発声を分類するのに使われる。発信者の発声が分類された後、ソフトウェアエージェントは、有限状態ネットワークを使って適切な応答を判定することができる。アプリケーションの展開に先立って、２組の分類器も、有限状態ネットワークを生成し、情報を求める有効なエージェント要求を識別し開発するのに使うことができる。

２．有限状態ネットワークの生成：このフェーズにおいて、ダイアログは、有限状態ネットワークまたは下位文脈を用いた文脈自由ネットワークとして取り込まれる。ＣＭＬエレメント、すなわち文脈（または状態）は、プリンシパル状態定義構造物である。

３．コード挿入フェーズ：このフェーズにおいて、状態ネットワークは、ダイアログに関連した自動化を有効にするように、アプリケーションに組み込まれる。分類器が組み立てられるフェーズに対して、特にコールセンターアプリケーションでは、最初にエージェント発声を１組の分類器にクラスタ化し、次いで、こうしたエージェント分類器を、発信者の発声を突き止め分類する際に使うことが有利であり得る。

コールセンターアプリケーションでは、発信者と人間エージェントの間のダイアログは一般に、エージェントによって制御される。実際、エージェントはしばしば、発信者との会話中に、標準化されたスクリプトに従うよう命じられる。こうしたスクリプトは、発信者の照会への回答が、信用できる効率的な方式で与えられるように、エージェント−発信者間の会話を指令し制約することを意図している。人間エージェントに対する共通の規則は、会話の流れの制御を決して失わないことである。

発信者およびエージェントの発声が、たとえば、Ｔｅｒｍ−Ｆｒｅｑｕｅｎｃｙ−Ｉｎｖｅｒｓｅ Ｄｏｃｕｍｅｎｔ Ｆｒｅｑｕｅｎｃｙ（ＴＦ−ＩＤＦ）アルゴリズムを使って、発声の意味に基づいてクラスタ化される場合、エージェントおよび発信者クラスタの分布は、全く異なったものとなる。

発信者の発声クラスタの分布は、非常に共通するいくつかの応答クラスタ（たとえば、発信者が番号を言い、または自分の身元を明らかにした発声クラスタ）をもつ傾向にあり、その後は、比較的少数のあまり共通しない応答に対するクラスタ頻度が急激に低下し、次いで、非常に末尾が長い単集合クラスタが続く。単集合クラスタは、一般に、発信者の全発声の半分を占め、全クラスタの約９０〜９５％を構成する。発信者の初期情報要求を表す発声（たとえば、「Ｗｈａｔ ｉｓ ｍｙ ａｃｃｏｕｎｔ ｂａｌａｎｃｅ？」）は、自動化音声応答システムの設計用の、発信者の発声の最も重要なタイプの１つを表し、一般に、発声全体のごくわずかな比率を占める（通話の長さに応じて、２０〜３０回の発声につきほぼ１）。ある特定の要求を言い表すことができる多くのやり方があるので、こうした初期発信者要求発声タイプは通常、全分布に渡って整理され、多くの発声がそれ自体の単集合カテゴリに収まる。

エージェント発声クラスタの分布は一般に、エージェント発声の転記性質のせいで、発信者の発声クラスタの分布とはかなり大きく異なる。具体的には、エージェント発声クラスタの分布（ＴＦ−ＩＤＦアルゴリズムを用いて、エージェント発声をクラスタ化する）は、発信者に対して観察される分布よりはるかに平坦であり、最も一般的な発声クラスタに対して全体的頻度がより低く、はるかに段階的にクラスタ頻度が低下する。エージェントはしばしば、発信者との会話に従事するので、エージェント発声クラスタの分布も、末尾が長い単集合を有する。コールセンター環境における、エージェントの分布と、発信者クラスタとの間のもう１つの違いは、高頻度エージェントクラスタが、情報収集クエリ（たとえば、「Ｃａｎ Ｉ ｈａｖｅ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ，ｐｌｅａｓｅ？」）を含む傾向にあることであり、こうしたクエリが、自動化音声応答システムの設計にとって最も重要な発声である。実際、重要なエージェント挙動（たとえば、エージェントの情報要求）のほぼすべてを、最高頻度２０％のクラスタを分析することによって特徴づけることが、しばしば可能である。

図１５を参照すると、初期アプリケーション開発プロセス１８２が、最初に１組のエージェント分類器を生成し、次いで、その１組のエージェント分類器を使って、１組の発信者分類器を識別し生成するエージェント中心型データマイニング技法を用いる。

初期アプリケーションプロセス１８２は、入力として、テキストに転記されている、事前記録された統計的にかなりの数の発信者−エージェント間の会話１８１を受け取る。事前記録された発信者−エージェント間の会話におけるすべてのエージェント発声が、１組のエージェントクラスタにクラスタ化され（３０２）、重大なエージェントクラスタ（たとえば、エージェントが発信者から情報を引き出す発声を有するクラスタ）が次いで、識別される。こうした重大なエージェントクラスタは次いで、機械学習プロセス、たとえばサポートベクターマシン（ＳＶＭ）をトレーニングするのに使われ（すなわち、そこに入力され）（３０４）、そこから、１組のエージェント分類器が生成される。

エージェント分類器が生成されると、こうした分類器は、転記された会話における発信者応答を突き止めるのに使われる（３０６）。こうした発信者の発声は次いで、１組の発信者クラスタにクラスタ化される（３０７）。こうしたクラスタ化された発信者の発声は次いで、機械学習プロセス、たとえばサポートベクターマシンをトレーニングする（３０８）（すなわち、そこに入力される）のに使われ、そこから、１つの発信者分類器セットが生成される。エージェントおよび発信者分類器セットは、判定された後で、新たな会話トランスクリプトにおいてエージェントおよび発信者の発声を分類するのに使うことができる。重要なエージェントクエリへの適切な発信者応答は次いで、新たなトランスクリプトから自動抽出され、発信者クラスタに追加される。こうした増補された発信者クラスタは次いで、新しい、改良された１組の発信者分類器３１０を組み立てるのに使われる。

転記された１つの会話セット、すなわち１組のエージェントおよび発信者分類器を使って分類されている発声を与えられると、規範的エージェント会話パターンを識別することができる（３１２）。規範的会話パターンは、エージェントによって、特定のタイプの発信者要求に応答する際に使われる情報要求および回答の共通パターンである。たとえば、発信者が、エージェントと交信し、自分の勘定残高を要求する場合、エージェントの共通の応答パターンは、質問Ｘ（たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｎａｍｅ？」）、その後に質問Ｙ（たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」）、その後に質問Ｚ（たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｍｏｔｈｅｒ’ｓ ｍａｉｄｅｎ ｎａｍｅ？」）を尋ねることである。一方、発信者が資料を要求する場合、エージェントの質問Ｘの後には、質問Ａ（たとえば、Ｗｈａｔ ｉｓ ｙｏｕｒ ｚｉｐ ｃｏｄｅ？」）および質問Ｂ（たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｔｒｅｅｔ ａｄｄｒｅｓｓ？」）が続き得る。こうした規範的会話パターンは、アプリケーション用の有限状態ネットワークを生成する（３１４）際に使うことができる。

さらに、転記された会話における、分類されたエージェントおよび発信者の発声ペアは、エージェントの成功した情報要求を識別する（３１６）のに使うことができる。同じ情報を引き出すことを意図した、様々な言葉で表現されたエージェント質問への発信者応答のタイプの分布の検査が、情報を求めるある尋ね方が、他のやり方より有効であることを明らかにし得る。たとえば、「Ｍａｙ Ｉ ｈａｖｅ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」で言い表される第１のエージェント要求は、発信者の社会保障番号を得ず、かなりの数の「ｙｅｓ」という発信者応答を得る可能性がある。しかし、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」で言い表されるエージェント要求を分類する別のエージェント分類器は、この質問への、非常に高い比率の発信者応答が、要求された情報（すなわち、発信者の社会保障番号）を与えたという分布をもたらし得る。

初期アプリケーション開発プロセスの一例を、図１６Ａ〜１６Ｅにより詳しく示す。

図１６Ａに示すように、初期アプリケーション開発ソフトウェアツールが、記録された人間エージェント−発信者間の会話３１８の、ランダムに選択された、等しい大きさの２つのサンプル、すなわちトレーニングセットおよびテストセットを収集する（３２２）。アプリケーション開発者は次いで、各サンプルにある通話を、発信者の初期発信者要求に従って、１組のバケットにカテゴリ化する（３２４ａ、３２４ｂ）。たとえば、発信者が自分の勘定残高を要求した通話は、あるバケットに置くことができ、発信者がアドレス変更を要求した通話は、別個のバケットに置くことができる。

アプリケーション開発者が通話をバケットにカテゴリ化した後、アプリケーション開発者は、ソフトウェアツールを使って、各通話セットごとに初期発信者要求の分布を検査する（３２６）。通話のトレーニングセットおよびテストセットの分布が類似していない場合、アプリケーション開発者は、ランダムに選択された通話のより大きなサンプルを取得し（３３０）、トレーニングセットおよびテストセットが類似した通話タイプの分布を生じるまで、バケット化プロセスを繰り返す。

トレーニングセットおよびテストセットが、類似した通話タイプの分布を有すると判定されると、アプリケーション開発者は、ソフトウェアツールを使って、トレーニングセット中の通話のエージェント発声をクラスタ化する（３３２）。エージェント発声をクラスタ化するために、ソフトウェアツールは、概念認識エンジン（上でより詳しく説明した）に発声を通して、各発声用の意味特徴リストを判定し、次いで、ＴＦ−ＩＤＦアルゴリズムを用いて、その意味特徴リストに基づいて発声をクラスタ化する。

図１６Ｂを参照すると、アプリケーション開発者は、エージェントクラスタを検査し、どの重複クラスタもマージし（３３４）、一定の数より多い発声（たとえば、４を超える発声）を有するエージェントクラスタを、分類での使用のために承認する（３３６）。アプリケーション開発者は一般に、あらゆるエージェントクラスタを分類するわけではない。というのは、発生頻度が低いクラスタは、エージェントが発信者から確かな情報を引き出したエージェント発声（たとえば、「Ｃａｎ Ｉ ｈａｖｅ ｙｏｕｒ ｎａｍｅ，ｐｌｅａｓｅ．」）である可能性が低いからである。そうではなく、低頻度のクラスタ（たとえば、単集合クラスタ）が、エージェントが発信者を会話に引き込んだエージェント発声（たとえば、「Ｈｏｗ ｉｓ ｔｈｅ ｗｅａｔｈｅｒ ｔｈｅｒｅ ｔｏｄａｙ？」）を含む可能性が高い。

アプリケーション開発者が、（たとえば、ソフトウェアツールへのグラフィカルユーザインターフェイスを使って）クラスタを承認した後、アプリケーション開発者は、承認されたクラスタ（すなわち、トレーニングデータ）中の発声の概念特徴に基づいて１組の分類器を生成するよう、ソフトウェアツールに命じる。１組の分類器は、機械学習プロセスの出力（たとえば、決定木、サポートベクターマシン）である。分類器は、トレーニングセットにあるどのクラスタに、新たな各発声が最も類似しているか判定するのに使われる。好ましい実装形態では、ソフトウェアツールは、サポートベクターマシン（ＳＶＭ）機械学習プロセスを用いて１組の分類器を組み立てる。このプロセスは、１組のペアになった判別装置を、他のすべてと比較される各クラスタに１つずつ与え、判別装置は次いで、新たな発声に適用される。最も多い数の比較に「勝つ」クラスタが、新たな発声が属すべきクラスタであると判定される。たとえば、３つのクラスタ用のＳＶＭを用いて分類器が組み立てられる場合、分類器は、クラスタ１をクラスタ２と、クラスタ１をクラスタ３と、クラスタ２をクラスタ３と比較する、ペアになった３つの判別装置からなるセットを有し得る。新たな発声が分類器に提示されると、こうした３つの比較はそれぞれ、発声の意味要素（会話認識エンジンによって判定される）に適用される。最も多い数の比較に「勝つ」どのクラスタも、発声が属すべきクラスタであると見なされる。

１組のエージェント分類器が組み立てられると、通話のトレーニングセットが、分類器の整合性を検証する（３４０）ために分類器に供給される。分類器の整合性は、分類器が、トレーニングセットのエージェント発声が属すと見なすクラスタを、エージェント分類器の生成に先立って、エージェント発声が分類されたクラスタと比較することによって調べられる。分類器がトレーニングセットを分類せず、それによりトレーニングセットが一定の認証基準（たとえば、分類器は、トレーニングセット中のエージェント発声の少なくとも９８％を、その適正なクラスタに分類しなければならない）を満たさない場合、アプリケーション開発者は、オリジナルクラスタを調整し（３４４）、エージェント分類器を組み立て直す（３３８）。

分類器が認証基準を満足すると、通話のテストセットの中のエージェント発声は、分類器を使って注釈をつけられる（３４６）。これは、エージェント発声が分類されており、発声が最も類似すると思われたクラスタを識別するタグが、各エージェント発声に関連づけられていることを意味する。たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」というエージェント発声は、エージェント発声が、発信者の社会保障番号を求めるエージェントの要求に対応するクラスタに分類されたことを示すタグ「ＲＥＱ＿ＳＳＮ」で注釈をつけることができる。

テストセットの中にあるエージェント発声に注釈をつけた後、アプリケーション開発者は、注釈を検討し（３４８）、エージェント発声が正しく分類されたかどうかに従って、注釈をつけられたテストセットにスコアをつける。たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」というエージェント発声が「ＲＥＱ＿ＡＤＤＲＥＳＳ」として分類された場合、アプリケーション開発者は、この分類を、正しくないというスコアをつける。スコア（たとえば、正しい分類の比率）が許容可能である（３５０）ことをアプリケーション開発者が確信していない場合、アプリケーション開発者は、オリジナルクラスタを調整し（３４４）、エージェント分類器を組み立て直す（３３８）。

アプリケーション開発者が、テストセットが許容可能なスコアを取得していることを確信すると、現在のエージェント分類器は、「ゴールデン」エージェント分類器として設定される。

図１６Ｃを参照すると、１組の発信者初期要求分類器を開発するプロセスを示してある。発信者の初期要求は、通話を行う発信者の主要理由（群）（たとえば、発信者の現在の勘定残高を求める要求、アドレス変更要求など）を識別する発声を指す。

図１６Ｃに示すように、通話のトレーニングセットのエージェント発声は、ソフトウェアツールを使って、「ゴールデン」エージェント分類器で注釈をつけられる（３５４）。ソフトウェアツールは次いで、発信者応答を、発信者の初期要求を求めるエージェント要求に対応するエージェント分類器（たとえば、「Ｈｏｗ ｍａｙ Ｉ ｈｅｌｐ ｙｏｕ？」に対応する分類器）にクラスタ化する（３５６）。

クラスタ化された発信者の初期要求は次いで、（たとえば、サポートベクターマシンを使って）発信者の初期要求に対する１組の分類器を組み立てる（３５８）のに用いられる。

発信者の初期要求に対応する発信者の発声の数は小さい（通常、通話当たりただ１つの初期要求）ので、アプリケーション開発者は、たとえば、通話のテキストを読み、各通話向けの初期要求（群）をあるクラスタに置くことによって、発信者要求発声を手作業で識別する（３６０）ことを選んでもよい。

発信者の初期要求分類器の初期セットが組み立てられると、分類器は、通話のトレーニングセットを分類器を介して供給すること、および分類器が、トレーニングセットの発信者の初期要求発声が属すと見なすクラスタを、発信者の初期要求分類器の生成に先立って発信者の初期要求発声が分類されたクラスタと比較することによって検証される（３６２）。分類器がトレーニングセットを分類せず、それによりトレーニングセットが一定の認証基準（たとえば、分類器は、トレーニングセット中の発信者の初期要求発声の少なくとも９５％を、その適正なクラスタに分類しなければならない）を満たさない場合、アプリケーション開発者は、元のクラスタを調整し（３６６）、発信者初期要求分類器を組み立て直す（３５８）。

認証基準が満たされると、通話のテストセットは、発信者の初期要求分類器で注釈をつけられ（３６８）、次いで、アプリケーション開発者によって検討されスコアをつけられる（３７０）。初期要求分類器が、許容可能なスコアを結果としてもたらさない場合、アプリケーション開発者は、クラスタを調整し、分類器を組み立て直す。（クラスタが、テストセットから拾われた情報に基づいて調整される場合、調整されたクラスタから組み立てられたＳＶＭの評価は、新たなテストデータセットでテストされるべきであることに留意されたい）。初期要求分類器が、許容可能なスコアを結果としてもたらすと、発信者の初期要求分類器の予備セット３７４が形成される。

図１６Ｄを参照すると、エージェントの情報要求への１組の非初期発信者応答を組み立てるプロセスを示してある。図１６Ｄに示すプロセスは、図１６Ｃに示すプロセスと同様である。図１６Ｃに示すプロセスのように、図１６Ｄに示すプロセスは、「ゴールデン」エージェント分類器を使って、発信者の発声を突き止める。ただし、図１６Ｄに示すプロセスでは、分類される発信者の発声は、非初期要求情報を求めるエージェントの要求に対応する発声（すなわち、発信者が、発信者の通話目的を求めるエージェント要求以外の情報を求める、エージェントの要求に応答した発信者の発声）である。発信者の名前、アドレス、社会保障番号、および誕生データを求めるエージェントの要求への発信者応答は、非初期要求情報を求めるエージェント要求に対応する、発信者の発声の例である。

図１６Ｄに示すように、通話のトレーニングセットのエージェント発声は、ソフトウェアツールを使って「ゴールデン」エージェント分類器で注釈をつけられる（３７６）。ソフトウェアツールは次いで、発信者応答を、発信者の初期要求以外の情報を求めるエージェント要求に対応するエージェント分類器（たとえば、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」に対応する分類器）にクラスタ化する（３７８）。

エージェントの非初期情報要求への、クラスタ化された発信者応答は次いで、（たとえば、サポートベクターマシンを用いて）発信者の非初期応答に対する１組の分類器を組み立てる（３８０）のに使われる。

発信者の非初期応答分類器の初期セットが組み立てられると、分類器は、通話のトレーニングセットを分類器を介して供給すること、および分類器が、トレーニングセットの発信者の非初期応答発声が属すと見なすクラスタを、発信者の非初期応答分類器の生成に先立って発信者の非初期応答発声が分類されたクラスタと比較することによって検証される（３８４）。分類器がトレーニングセットを分類せず、それによりトレーニングセットが一定の認証基準（たとえば、分類器は、トレーニングセット中の発信者の発声の少なくとも９８％を、その適正なクラスタに分類しなければならない）を満たさない場合、アプリケーション開発者は、元のクラスタを調整し（３８６）、発信者非初期応答分類器を組み立て直す。

認証基準が満たされると、通話のテストセットは、発信者の非初期応答分類器で注釈をつけられ（３８８）、次いで、アプリケーション開発者によって検討されスコアをつけられる（３９０）。非初期応答分類器が、許容可能なスコアを結果としてもたらさない場合、アプリケーション開発者は、クラスタを調整し（３８６）、分類器を組み立て直す。非初期応答分類器が、許容可能なスコアを結果としてもたらすと、発信者の非初期応答分類器の予備セット３９４が形成される。

非初期発信者応答分類器および初期発信者要求分類器の予備セットは、予備的な発信者分類器の結合セットを形成するように結合される（３９６）。

図１６Ｅを参照すると、予備的な発信者分類器を増補するプロセスを示してある。このプロセスにおいて、転記された人間エージェント−発信者間の通話のトレーニングセットおよびテストセットのいくつか（Ｎ個）のランダムサンプルが、分類器の性能を向上させるのに使われる。

ランダムサンプル（たとえば、ランダムに選択された１０００個のサンプル）の第１のトレーニングセットが、ソフトウェアツールを使って「ゴールデン」エージェント分類器および予備的な発信者分類器で注釈をつけられる（４００）。ソフトウェアツールは次いで、エージェントの情報要求（発信者の通話理由を求める要求、または他の情報を求めるエージェント要求）に対応する、発信者の発声のデータ（すなわち、意味特徴）を、対応する分類器の発信者クラスタに追加する。たとえば、「ｙｅａｈ，ｉｔｓ １２３−４５−６７８９．」という発信者の発声が、発信者の社会保障番号を求めるエージェント要求に応答して与えられ、発信者の発声の意味特徴が、社会保障番号の応答に対応する発信者クラスタに追加される。

サンプルセットの中にある、発信者の発声からのデータがすべて、対応するクラスタに追加されると、発信者分類器（発信者の初期要求および非初期応答分類器の両方）が、たとえばサポートベクターマシンを用いて組み立て直される（４０４）。

組み立て直されたクラスタは次いで、新たに組み立てられた分類器に、通話のトレーニングセットを供給すること、および分類器が、トレーニングセットの発信者の発声が属すと見なすクラスタを、発信者分類器の生成に先立って発信者の発声が分類されたクラスタと比較することによって検証される（４０８）。新たに組み立てられた分類器がトレーニングセットを分類せず、それによりトレーニングセットが一定の認証基準（たとえば、新規分類器は、以前の分類器よりも高い率で発信者の発声を正しく分類しなければならない）を満たさない場合、アプリケーション開発者は、クラスタを調整し（４１０）、発信者分類器を組み立て直す。

認証基準が満たされると、通話のテストセットは、発信者の分類器で注釈をつけ直され（４１０）、次いで、アプリケーション開発者によって、分類器を改良するために検討されスコアをつけられる（４１２）。（新たなデータが分類器を改良すると想定されるので、クラスタの調整は起こらない）。図１６Ｅに示すプロセスは、新たな分類器のスコアが、エージェントおよび発信者分類器の最終セットが確立される地点である漸近線に近づくまで続き得る。

エージェントおよび発信者分類器の最終セットは、アプリケーション開発者がシステム用の有限状態ネットワークを開発するのに使ってよい、規範的エージェント会話パターンを識別するのに用いることができる。たとえば、図１６Ｆに示すように、ランダムに選択されたエージェント−発信者間の１つのサンプルセット４２０が、最終エージェントおよび発信者分類器を使う分類器タグで注釈をつけられる（４２２）。通話は次いで、通話タイプによって特徴づけられる（４２４）。このステップは、注釈をつけられたエージェント−発信者間のサンプルを検討するアプリケーション開発者によって手作業で実施してもよく、各発信者の初期要求に関連づけられたネットワークパス（群）を最適化するソフトウェアプロセスによって自動的に実施していてもよい。

ソフトウェアプロセスが次いで、各通話タイプごとのエージェント要求の並びを比較することによって、各通話タイプごとの共通エージェント要求パターンを識別する（４２６）ことができる。たとえば、ある通話タイプが、勘定残高を求める要求の場合、ソフトウェアプロセスは、１つまたは複数の共通要求パターンを識別するために、勘定残高を求める要求に応答する、各エージェント要求の並びを検査することができる（たとえば、多数のエージェントが要求「Ａ」、その後に要求「Ｂ」、その後に要求「Ｃ」を行った）。ソフトウェアプロセスは次いで、識別された共通要求パターン（たとえば、各通話タイプごとに最も共通する要求パターン）を使って、予備的な有限状態ネットワークを自動生成する（４２８）。アプリケーション開発者は一般に、たとえば、システムによって理解されない応答を再度促させたり、または発信者に、システムが情報をルックアップする間待つよう依頼したりするために、予備的な有限状態ネットワークにノードを追加することになろう。

共通エージェント要求パターンを使って予備的な有限状態ネットワークを生成することに加えて、アプリケーション開発者は、共通エージェント要求パターンを使って、通話タイプを識別することもできる。たとえば、異なる通話タイプに対する１組の共通エージェント要求パターンが識別されると、分析されていないセット発信者−エージェント間の会話に、エージェント分類器を適用して、分析されていないセットの中のエージェント要求パターンを識別することができる。分析されていないセットの中にある、発信者−エージェント間の会話におけるエージェント要求パターンが、既知の通話タイプに対する共通要求パターンの１つと一致する場合、アプリケーション開発者（またはアプリケーション開発者によって使われるソフトウェアツール）は、発信者−エージェント間の会話が、共通の発信者−エージェント間の要求パターンに対応する通話タイプであると想定し得る。発信者−エージェント間の会話の通話タイプは、分類器のどの特定の順序にも依存せず、会話中に存在する１組のエージェント分類器に基づいて判定することができる。あるいは、通話タイプは、会話中に存在する一連のエージェント分類器に基づいて判定することもできる。

転記された会話中の、分類されたエージェントおよび発信者発声のペアは、成功したエージェント情報要求を識別するのに使うことができる。同じ（したがって、同じクラスタにあった）情報を引き出すことを意図した、様々な言葉で表現されたエージェント質問への発信者応答のタイプの分布が、情報を求めるある尋ね方が、他のやり方より有効であることを明らかにし得る。たとえば、「Ｍａｙ Ｉ ｈａｖｅ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」で言い表される第１のエージェント要求は、発信者の社会保障番号を得ず、かなりの数の「ｙｅｓ」という発信者応答を得る可能性がある しかし、「Ｗｈａｔ ｉｓ ｙｏｕｒ ｓｏｃｉａｌ ｓｅｃｕｒｉｔｙ ｎｕｍｂｅｒ？」で言い表されるエージェント要求を分類する別のエージェント分類器は、この質問への非常に高い比率の発信者応答が、要求された情報（すなわち、発信者の社会保障番号）を与えたという分布をもたらし得る。どの発信者応答タイプが応答を示し、どれが応答を示さないかを識別することによって、次いで、関連づけられた発信者の発声を見て、そうしたエージェント発声の言い回しが、発信者の発声の応答性に関与するかどうか判定することが可能である。

再度図１２を参照すると、初期ＣＭＬアプリケーション記述１８４は、（たとえば、図１６Ａ〜１６Ｆに示す初期開発プロセスを使って）開発されると、会話サーバ（たとえば、図５〜６に示す会話サーバ３０）に展開される（１８６）。会話サーバは好ましくは、ＣＭＬアプリケーションの「ホットデプロイメント」をサポートし、これは、ＣＭＬアプリケーション記述の新たなバージョンが、会話サーバ上で既に稼動しているときは展開し直すことができることを意味する。ホットデプロイメントは好ましくは、以下のことを保証する。（ｉ）既にアクティブなアプリケーションセッションが、完了まで稼動させられる、（ｉｉ）アプリケーションのバージョンによって利用されるすべてのリソース（たとえば、入力要求ファイルなど）が、必要とされなくなるまで、削除されることも置き換えられることもない、（ｉｉｉ）すべての新規アプリケーションセッションが、アプリケーションの最新バージョンを使用する、（ｉｖ）アプリケーションのすべての廃止バージョン、およびサポート用リソースが、アクティブなアプリケーションセッションによって必要とされなくなると、会話サーバから削除される。

ＣＭＬアプリケーション記述が会話サーバ上で展開され、通話を扱い始めた後、会話サーバは、システム−発信者間の対話をすべて、メディアリポジトリ１８７に記録し、会話ログ１８８に対話のログを生じる。

メディアリポジトリ１８７は、システム−発信者間の会話からの未加工データ（たとえば、記録された発信者−システム間の電話会話のオーディオファイル、発信者−システム間のインスタントメッセージ会話のテキストファイル）を含む。オーディオ記録サブシステム（図示せず）が、すべての顧客通話を、発生時間（システムが通話を扱い始めるとき）から、通話の終了までを記録する。エージェント引継ぎ通話に対して、音声サブシステムは、エージェント／顧客対話を、その終結まで記録し続ける。好ましい実装形態では、オーディオ記録サブシステムは、発信者が会話の中で言ったすべてのことを、あるオーディオファイルに、エージェント（群）（ソフトウェアおよび／または人間エージェント）が言ったすべてのことを別個のファイルに記録する。さらに、オーディオ記録サブシステムは好ましくは、記録された会話の中の沈黙を取り除く。

会話ログ１８８は、ロギングサブシステム６４（図５に示す）によって生成される。ロギングサブシステムは、会話サーバによって処理されるあらゆる通話に対するセッションオブジェクトを作成することによって、会話ログ６４を生成する。セッションオブジェクトは、以下のデータを含む。
・稼動されるアプリケーション（会話サーバ上で使用されている多数の会話型アプリケーションがあり得る）
・システムによって対話がどのようにして処理されたかを示すラベル（たとえば、自動化、合成、またはエージェント引継ぎ会話）
・チャネルインジケータ（電話、ウェブ、チャット／ＩＭ、ｅメール）
・音声リポジトリに格納されている、関連づけられたオーディオファイルへのリンク。
・以下を含む、時系列順での会話全体の表現
○（ｉ）スピーチエンジンによって認識された顧客入力（認識された入力）；
○（ｉｉ）十分に自動化された対話（すなわち、ソフトウェアエージェントによって完全に扱われた対話）に対して、表現は、以下も含む。
●対話の場合、各質問に与えられた回答およびその一致スコア
○（ｉｉｉ）合成された対話（すなわち、人間エージェントが、システムによって提示された回答リストから回答を選択した対話）に対して、表現は、以下も含む。
●提案された最上位の回答（群）および関連した一致スコア、
●エージェントによって選択された回答およびその一致スコアならびに提案された回答リストの中での順位づけ
○（ｉｖ）引継ぎ対話に対して、表現は、以下も含む。
●人間エージェントと顧客の間のオーディオダイアログ。
・通話発生時刻、通話が人間エージェントに上申された時刻（適用可能な場合）、および通話完了時刻を示すタイムスタンプ。
・エージェントおよび発信者が交わす会話、ならびに状態遷移を引き起こしたイベントに従った状態の並び、たとえば、人間エージェントが特定の応答を選択し、またはソフトウェアエージェントが応答を選択する。
・通話を支援し、または通話を引き継いだ人間エージェントの識別（適用可能な場合）。
・バックエンドシステム（たとえば、発信者要求に応答した情報を含むシステム）へのすべての要求の記録、およびそうした要求の結果。たとえば、アプリケーションは、顧客の勘定残高を取得する必要がある場合、バックエンドシステムへの通話を必要とする。

メディアリポジトリ１８７および会話ログ１８８は、ＣＭＬアプリケーションの調整を容易にするために、ランタイム学習プロセス１９０にとって利用可能である。

ランタイム学習プロセス１９０は、システム（交渉ログ１８８およびメディアリポジトリ１８７に取り込まれる）の実行履歴が用いられる適応型学習ループを、会話を自動化するためのシステムの能力を向上させるようにＣＭＬアプリケーションを発展させるのに用いる。より具体的には、ランタイム学習プロセスは、エージェント−発信者間の会話の履歴から、システムにとって「良好な」学習機会であると判定される特定のエージェント−発信者間の対話を選択する。選択されたエージェント−発信者間の対話は、エージェント−発信者間の会話全体である必要はなく、エージェント−発信者間の会話の一部分でよい。以下は、システムを改良するランタイム学習プロセスによって選択することができる発信者−エージェント間の対話の例である。

１．人間エージェントが、システムによって生成された、発信者の発声への応答のランクづけされたリストから応答を選択した会話において、発信者の発声の意味は、人間エージェントによって選択された応答とは、システムによって区別することができる。したがって、発信者の発声は、システムによって使われる、分類器を改良するための学習機会として選択することができる。したがって、発信者が将来同様の発声を行う場合、システムは、人間エージェントからの支援なしで、より応答しやすくなる。また、発信者の発声の認識された発語（オンラインＡＳＲ、オフラインのＡＳＲまたは手動転記によって認識することができる）は、オンラインＡＳＲによって使われる言語モデルを改良するのに用いることができる。したがって、発信者が、将来同様の発語を用いて発声を行う場合、オンラインＡＳＲは、その発語をより正確に認識しやすくなる。

２．システムが発信者の発声に自動化応答を与えた会話において、自動化応答に先行する発信者発声は、システムによって、システムの挙動を強化するための学習機会として選択することができる。この場合、発信者の発声の、認識された発語（オンラインＡＳＲ、オフラインＡＳＲ、または手動転記によって認識することができる）は、オンラインＡＳＲによって使われる言語モデルを改良し、かつ／または発信者の発声の意味を区別するのに使われる分類器を改良するのに用いることができる。

３．人間エージェントが会話を引き継いだ会話において、人間エージェント−発信者間の対話は、学習機会として選択することができる。この場合、システム管理者が、システムによって予期されなかった（したがって、システムの有限状態ネットワークの一部でない）、人間エージェント−発信者間の会話のやり取りを分析することができる。システム管理者は、人間エージェント−発信者間のやり取りを用いて、システムの有限状態ネットワークにノードを追加し、分類器を組み立てることができ、そうすることによって、発信者が将来コールセンターと交信する場合、システムは、その通話を扱う準備ができている。たとえば、印刷エラーが、ある特定の月における、顧客への無記名為替手形のメール送信につながった場合、システムは、無記名為替手形について、いくつかの発信者照会を受ける可能性がある。これはおそらく、システムによって予期されていない会話である。こうした照会のいくつかを受けた後、システム管理者は、システムが将来、同様の通話を扱うことができるように、１組の分類器を組み立て、有限状態ネットワークをアップデートすることができる（たとえば、上で図１５において説明したプロセスを用いる）。

ランタイム学習プロセスは、エージェント−発信者間の選択された対話を会話スタジオ３２（図４〜５に示す）に供給し、スタジオ３２で、対話は、分類器を組み立て直し、ランタイム音声認識によって使われる言語モデルを改良し、かつ／または状態遷移ネットワークを修正するのに使われる。

一実装形態では、ランタイム学習プロセスは、システム−発信者間の会話を、以下の学習機会用に吟味する。

１．支援：ソフトウェアエージェントが不確実なときに、人間エージェントがソフトウェアエージェントに、発信者ステートメントの適正な解釈を知らせた会話において、発信者ステートメントのエージェント解釈が、概念認識エンジンによって、発信者の発話を理解するのに使われる分類器を改良するのに用いられる。他の実装形態は、発信者ステートメントのエージェント解釈を用いて、オンラインＡＳＲによって使われる言語モデルを改良する。

２．引継ぎ：人間エージェントがソフトウェアエージェントから会話を引き継いだ会話において、人間エージェント−発信者間のやり取りは、システム管理者によって、新たな会話を識別するために分析される。新たな会話が識別された場合、新たな１組の発信者分類器およびアップデートされた有限状態ネットワークを開発して（たとえば、上の図１５で説明したプロセスを用いて）、その新たな会話をアプリケーションに追加することができる。

３．強化：ソフトウェアエージェントが発信者の１つまたは複数の発声を首尾よく認識した会話において、発信者の発声（群）は、オンラインＡＳＲ（音声認識エンジンのコンポーネントである）によって、発信者の発話を認識するのに使われる言語モデルを改良するのに用いられる。他の実装形態は、こうした会話を用いて、概念認識エンジンによって発信者の発話の意味を理解するのに使われる分類器を改良する。

ランタイム学習プロセス１９０が、エージェント−発信者間の対話を学習機会として使うとき、学習機会の対話が正しくないというリスクがある。「不良」対話（たとえば、システムが発信者の質問を誤解し、不正な応答を与えた対話）の処理は、システムの正確さおよび自動化の程度を低下させる危険性を提示する。したがって、ランタイム学習プロセスは好ましくは、そこから学習するべき「良好な」対話のみを選択することを保証するのを助ける１つまたは複数の安全機能を含む。

好ましい実施形態では、ランタイム学習プロセスは、会話スタジオ３２（図４〜５に示す）の所にあるグラフィカルユーザインターフェイスを介して、システム管理者または他のユーザによって、選択された対話が一定の選択基準を満足することを要求するように構成可能である。一実装形態では、システム管理者は、学習機会を選ぶ以下の選択基準の１つまたは複数を選択することができる。

１．エージェント−発信者間の、後続のｎ個（たとえば、ｎ＝２、３、４など）の対話が成功した（たとえば、結果として、発信者に電話を切らせることも、人間エージェントに助けを、またはエージェントと話すことを求めさせることもなかった対話）場合、エージェント−発信者間の対話を、強化学習機会として選択する。

２．発信者が、ソフトウェアエージェントまたは人間エージェントによって課された満足性質問（たとえば、「Ｄｉｄ ｔｈａｔ ａｎｓｗｅｒ ｙｏｕｒ ｑｕｅｓｔｉｏｎ？」、「Ａｒｅ ｙｏｕ ｓａｔｉｓｆｉｅｄ ｗｉｔｈ ｔｈｅ ｓｅｒｖｉｃｅ ｙｏｕ ｒｅｃｅｉｖｅｄ？」）に肯定的に応答した場合のみ、エージェント−発信者間の対話を、強化および／または支援学習機会として選択する。

３．エージェント−発信者間の対話を、他の例のうちｍ個（たとえば、ｍ＝２、３、４など）によって確認される強化および／または支援学習機会として選択する。これは、システムが、限られた数の例から推定するのを回避する。

４．ある程度の数の異なるエージェントによって確認される場合、エージェント支援対話を、学習機会として選択する。

５．支援が「信用できる」エージェントによって実施される場合、エージェント支援対話を選択する。信用できるエージェントは、エージェントとしての人の在職期間の長さや、エージェントに起因する、以前の支援学習例における累積スコアなど、何らかの「信用」測度に従って判定することができる。

６．システムによって提案された、最上位のｎ個の選択肢（たとえば、ｎ＝１、２、３など）の中にある場合のみ、エージェント支援対話を、学習機会として選択する。

７．あるクラスタへの新たな例の追加が、そのクラスタから、以前の所定の数の例にシフトすることになる場合は、学習機会としての対話の選択を回避する。たとえば、既存のあるクラスタが、すべてが「Ｉ ｗａｎｔ ｍｙ ａｃｃｏｕｎｔ ｂａｌａｎｃｅ」を意味する１００例の発声を含み、選択された対話にある、発信者の新たな発声が、そのクラスタに追加され、新たな１組の分類器が、１０１個の発声（元の１００個に新たな１つを足したもの）からなる新たなトレーニングセットを使って生成し直されると仮定する。１０１個の発声は、新たな１組の分類器がそれをどのように分類したかを見るために、新たなセット分類器に適用することができる。理想的には、新たな分類器は、そのように分類器がトレーニングされているので、１０１個の発声をすべて、「Ｉ ｗａｎｔ ｍｙ ａｃｃｏｕｎｔ ｂａｌａｎｃｅ」というクラスタに属すものとして分類するべきである。しかし、元の発声のうち特定の数（たとえば、１、２、３など）が、他の何らかのクラスタに属すものとして現在誤分類されているか、または現在多義的に分類されていることが分かった場合、これは、学習された新たな発声が、分類器の正確さを低下させており、最初の段階でこのクラスタに追加されているべきでないということを指示している。この選択基準は、クラスタに新たな例を追加し、その結果以前の所定の数の例を取り除かせることになる、より強い証拠を必要とするように、上記の選択基準３と結合することができよう。

「不良な」例からの、システムの学習低下のリスクに加えて、処理用および／または人間管理リソースを節約するために、学習機会を制限することも有利であり得る。たとえば、平均的な北米のコールセンターは、１年にほぼ３００万回の通話を扱い、１通話当たり、発信者−エージェント間の１０回のやり取りと想定すると、これは、平均的なコールセンターが、１日当たり１２０，０００個の潜在的学習イベントを生成することを意味する。多くの組織は、システムに、その挙動を、責任ある何者かの承認なしで変えさせることはない（または、合法的にそうすることができない）。自動的なシステム進化が所望される場合であっても、剪断量の例が、最終的には処理リソースに対する負担になり得る。したがって、適切または有用な例のみが処理され、かつ／または人間による検討のために提示されることを、ランタイム学習プロセスが保証することが有利な場合がある。好ましい実施形態では、ランタイム学習プロセスは、会話スタジオ３２（図４〜５に示す）の所にあるグラフィカルユーザインターフェイスを介して、システム管理者または他のユーザによって、システムおよび／またはユーザへの過負荷を回避するのを助けるために、選択された対話が、１つまたは複数の選択基準を満足することを要求するように構成可能である。

１．少なくともｎ個（たとえば、ｎ＝１、２、３など）の他の対話を分類しない対話を選択しない。というのは、それ自体の理解に寄与する対話は一般に、あまり有用でないからである。

２．対話を、それが分類する他の対話の数でランクづける。こうした最も生産的な例のうち、最上位のｎ＝１、２、３．．．個のみを学習機会として追加する。

３．少なくとも一定の閾値によって確定的セットを変えない対話を追加しない。上で説明したように、分類器は、例のトレーニングセットから作成される。トレーニングセットの中の例は、重要なものもあるが、そうでないものもある。つまり、重要でない例を取り除き、分類器を休養させることになった場合、以前と同じ分類器を入手する。実際に重要である例は、確定的セットと呼ばれる（確定的ＳＶＭ分類器セットを判定するのに用いられた既知のソフトウェアプロセス）。この選択基準は、対話が学習プロセスを介して分類器用のトレーニングセットに追加され、新たなトレーニングセットを使って新たな分類器が構築されても、確定的分類器セットが一定の閾値分変わらない（たとえば、そのメンバのほとんどが、以前と同じである）場合、分類器は、追加対話からほとんど学習していないので、無視することができる（このケースでは、元の分類器は、そのままの状態で留まることになる）ことを意味する。学習にとって有用な対話は、確定的セットに対して顕著な影響力をもつ対話である。

４．クラスタ中の例に数値または期間に関連した閾値を置くことによって、システムが保有する例の数または多様性を制限する。期間に関連した１つの閾値は、例が、他のある程度の数の例を分類するのに、最後に使われたときである。これは、最初に人間と人間の間でのデータでトレーニングされたシステムが、人間がマシンに話しかけるときに採用し得る異なるスタイルを学習しているときに特に重要であり得る。

上記の選択基準は、システム−発信者間のどの形のコミュニケーション（たとえば、発語、インスタントメッセージなど）にも当てはまるが、オンラインＡＳＲ（または、手書きを認識するケースでは、オンライン光学式文字認識（ＯＣＲ）システム）において重大な誤認識機会が起こり得る、対話媒体が発語または手書きあるいは他の様式であるとき、特殊な問題が発生する。

いくつかのケースでは、会話ログに取り込まれる発信者の発語（または手書き）の認識は、有用な例として働くには十分に正確でない場合がある。これは、発信者が言った、または書いたことをシステムが理解できなかったときに、人間エージェントが正しい解釈を供給する支援または引継ぎ学習において特に問題である。不正確に認識された発語または手書きからの学習は、システム性能を低下させ、または少なくとも、システムリソースを浪費する可能性がある。ランタイム学習システムは好ましくは、エージェント選択による回答を、システムによって提示される最上位のｎ個（たとえば、ｎ＝１、２、３．．．）の仮定のセットにあることを要求することによって、不正確に認識されたデータからの学習から保護する。システムはまた、誤認識された例からの学習を回避するために、閾値を超過するという、（オンラインまたはオフラインのＡＳＲによって生じられた）認識されたデータの何らかの内部信頼性測度を必要としてもよい。

会話ログにおける不正確に認識されたデータの脅威は相当なものである。というのは、システムは、動作しているとき、一般に、発信者が応答を数秒を越えて待ちたくないという時間の制約に直面する。これは、オンラインＡＳＲがユーザ要求を認識し分類するのに使うことができる処理量を制限する。しかし、ランタイム学習プロセスは、発信者入力を、このような厳しい時間の制約なく、学習目的のために再度認識する場合がある。このオフライン認識は、より多くのリソースを使うことによってより良好な結果を達成するのに、異なるアルゴリズムまたはモデルまたはパラメータを使うことも、同じおよび／または関連したユーザ入力の多数の受け渡しを行うことさえもできる。たとえば、発信者会話全体（すべて１０回分）を、各回を再度認識するためのトレーニングとして用いることもできよう。ランタイム学習プロセスは、オフタイム中に、超過ピーク期間容量を用いてこのタスクを実施するように設計することができる。ランタイムプロセスは、発信者入力を再度認識するのに、ネットワーク（たとえば、インターネット）を介して計算機リソースを使うこともできよう。

発信者入力（たとえば、発語）の認識は、計算集約的プロセスであり、したがって、ランタイム学習プロセスは、処理リソースを、あらゆるユーザ発声を再度認識するためのプロセスにとって利用可能にしてはならない。ランタイム学習プロセスが処理リソースを制限し得る一方法は、上記の選択基準概要の１つまたは複数を使って、学習機会として選択されているシステム−発信者間の対話を単に選択することである。上記の技法に加えて、プロセスは、対話の信頼性レベルをフィルタとして用いることができる。信頼性が高い対話は、正しいものであると推定することができ、信頼性が低い対話は、問題があり過ぎて、信用に値しない（たとえば、外部ノイズが多過ぎる）と想定することができる。適切な「高い」および「低い」閾値は、システムによって、トレーニング例から計算することができる。

さらに、認識技法はしばしば、システムの語彙の限度を知っていると想定する。特に問題となるのは、いつ、どのようにして、根本的単位からなる、システムの基本目録を拡張するべきかということである。ランタイム学習プロセスは、概念認識システムの語彙をいつ拡張するかを、異なる（通常、より大きい）語彙を用いて判定することができるオフライン認識を用いることができる。より大きな語彙により、より良好な内部および外部スコアが生じる場合、ランタイム学習プロセスは、その語彙を、概念認識エンジンにとって「より良好な」語彙であると想定し得る。ランタイム学習プロセスは、新たな項目および組合せを含めるように、たとえば、ニュース供給から新たな語彙を動的に構成することができる。低レベルの信頼性測度は、おそらくは新しい項目の領域を識別することができる。グループ化された新しい類似項目が一定の閾値を超過するとき、新しい項目の識別の支援のために、人間に依頼することができる。

最後に、多くの認識システムは、異なるタスクレベルに対して個別モデルを有する。たとえば、音声応答システムは、音レベル単位を分類するためのガウスの音響モデルと、音シーケンスを単語にマップするための辞書と、単語シーケンスをレーティングするための統計的言語モデルと、全発声を等価な意味グループに分類するためのＳＶＭとを有し得る。ランタイム学習プロセスは、選択された学習例を用いて、様々なレベルにあるモデルを、別々に、または様々な組合せでまとめてトレーニングすることができる。

図１７を参照すると、学習サーバ４５０が、ランタイム学習プロセスを実装している。この特定の実装形態において、学習サーバは、ログストリーマ４５６、学習モジュール４５８、学習データベース４６０、オーディオ取出し装置４６２、オフライン自動音声認識アプリケーション４６４、およびアプリケーションストア４６６を含む。

動作の際、システム−発信者間の会話のログは、会話サーバによって生成されると、会話ログ４５２からログストリーマ４５６にプッシュされる。会話サーバ（たとえば、図４〜５に示す会話サーバ３０）または別の機構（たとえば、別のサーバ）は、ログをログストリーマにプッシュするように構成することができる。

ログストリーマは、会話ログを受け取ると、ログを、分析のために学習モジュール４５８ａ、４５８ｂの一方に経路指定する。学習モジュールは、学習サーバに学習機能を導入するモジュール式の手法である。たとえば、一実装形態では、ある学習モジュールが、エージェント支援からの学習機会の識別専用であり、第２の学習モジュールが、強化学習機会の識別専用であり、第３の学習モジュールが、引継ぎ学習機会の識別専用である。サーバに追加されるべき新たな学習機能がある場合、新たな学習モジュールが開発され、学習サーバに導入される。したがって、たとえば、語彙学習モジュールは、システムの語彙を拡張するように、発信者の発声において使われる単語を検査するために学習サーバに追加することができよう。

学習モジュールは、会話ログおよびオーディオファイルに学習機会として取り込まれるイベントを選択するようにも機能する。システム学習モジュールは、会話ログ／オーディオファイルに取り込まれるイベントを、システム管理者によって特定された選択基準（上で論じた）に従って選択する。一部の選択基準、たとえば、学習のためのシステム−ユーザ間の対話の選択に対して、後続の一定の数のシステム−発信者間の対話が成功したかどうかは、システム−発信者間の候補対話に対応する会話ログから判定することができる。しかし、他の選択基準は、システム−発信者間の対話が選択されるべきかどうか判定するために、学習モジュールが多数の会話ログを検査することを要求する。たとえば、選択基準が、他の一定の数の例によって確認されない限りエージェント−発信者間の対話が選択されるべきでないと指定する場合、学習モジュールは、エージェント−発信者間の対話において、多数の受渡しを行うことになる。最初の受渡しにおいて、学習モジュールは、エージェント−発信者間の対話を、可能な学習機会として識別しセーブする。一定量の候補対話がセーブされた後、または一定量の時間の後、学習モジュールは、セーブされた候補対話を分析して、学習機会として最終的に選択するべき対話を選ぶ。

学習モジュールが、システム−発信者間の対話を学習機会として選択すると、選択されたシステム−発信者間の対話は、学習データベース４６０に格納される。

システム−発信者間の対話をフィルタリングする選択基準に加えて、学習モジュールは、概念認識エンジン（会話ログに含まれる）によって報告される一致スコアレベルを検査して、システム−発信者間の選択された対話をオフラインＡＳＲ ４６４または手動転記４６８のどちらに送るべきか判定するようにも構成される。一致スコアの閾値範囲は、ユーザ（たとえば、システム管理者）によって設定可能にしてもよく、予めプログラムすることもできる。一致スコアの閾値範囲は好ましくは、信頼性が非常に低いスコアを（発声に問題があり過ぎて、信用できないことを示す）および信頼性が非常に高いスコア（元の認識が正しいことを示す）を排除する。転記が、オフラインＡＳＲ ４６４を対象とする場合、オフラインＡＳＲプロセス４６４は、アプリケーションストア４６６内のアプリケーション定義にアクセスして、特定の認識状態向けに使われるＡＳＲ言語モデルを取得する（各認識状態が、１つの個別言語モデルを使う）。学習モジュールは、すべてのエージェント引継ぎ対話を、オフラインＡＳＲまたは手動転記に経路指定するように構成される。というのは、概念認識エンジンは、エージェント引継ぎの間、発信者またはエージェント発声を認識しないかっらである。一部の構成では、学習モジュールは、発信者−人間エージェント間の対話の高品質の転記を得るために、エージェント引継ぎを、オフラインＡＳＲによる自動化転記とは対照的に、手動転記に経路指定するように構成される。

最後に、アプリケーション開発者は、会話スタジオ３２上のグラフィカルユーザインターフェイスを用いて、考慮のために準備されている学習機会を取得する。アプリケーション開発者は、任意選択で、（たとえば、グラフィカルユーザインターフェイスを介して）学習機会を承認し、この承認された学習機会でアプリケーションをアップデートする。アプリケーションがアップデートされると、新たなバージョンがアプリケーションストア４６６に置かれ、会話サーバに展開される。

支援学習機会は、適切な概念クラスタに追加される発信者の新たな発声をもたらし、これは次いで、概念認識のために使われる分類器を生成し直すのに使われる。アップデートされたアプリケーションは次いで、次回発信者によって発話されるときに、同様の発声を適正に分類することが可能になる。強化学習機会は、オンラインＡＳＲの正確さを向上させるために、音声認識用に使われる言語モデルに追加される新たな発声をもたらす。引継ぎ学習機会は、有限状態ネットワークを、既存のトピック周辺の新たなトピックおよび新たな対話を扱うように拡張する。

図１３は、グラフィカルユーザインターフェイス２０８を示し、これは、人間エージェントをワークグループにログインさせ、自分の作業状態を管理させ、通話を受けさせかけさせる汎用的なエージェントデスクトップのコンポーネントであり、通話はすべて、ＣＴＩサーバとの対話を通る。ユーザインターフェイス２０８は、デスクトップアプリケーションを含むＣＴＩサーバを利用するアプリケーションをエージェントが起動するための制御パネルである。

インターフェイス２０８は、Ａｖａｙａ ＩＰ Ａｇｅｎｔデスクトップ上でモデル化される。このデスクトップの最も一般的な機能は、ツールバーを介して公表される。図１３に示すツールバーは、電話２００（選択された通話に対する制御を提供する）、ダイヤル２０２（通話をかける手段を提供する）、エージェント２０４（ＡＣＤを参照して、エージェントの作業状態を設定する手段を提供する）、およびアプリケーション２０６（インターフェイス２０８にロードされているアプリケーションを起動する手段を提供する）である。

人間エージェントがログインすると、デスクトップ用の構成がサーバからロードされる。この構成の一部は、デスクトップから起動することができるアプリケーションの定義である。アプリケーション構成は、アプリケーションを実装するクラスと、アプリケーションがロードされるネットの場所を含む。さらに、構成は、通話がアプリケーションを目標としていることを示すアプリケーションデータを含むことになる。

図１４は、解決アプリケーションまたはグラフィカルユーザインターフェイス２１０を示す。このアプリケーションは、通話が解決通話であることを示すアプリケーションデータと共に通話が届く度にトリガされる。アプリケーションユーザインターフェイスは、３つの主セクションに分けられる。提示される情報は、以下の通りである。すなわち、Ａｐｐｌｉｃａｔｉｏｎ ２１２（稼動されているＣＭＬアプリケーション）、Ｃｏｎｔｅｘｔ ２１４（アプリケーションにおける現在の状態）、Ｃｈａｎｎｅｌ ２１６（顧客がセンターと交信しているチャネル）、Ｔｈｒｅｓｈｏｌｄ ２１８（文脈用の閾値設定）、Ｏｖｅｒ／Ｕｎｄｅｒ ２２０（解決がエージェントに提示されている理由。すなわち、閾値を越える回答が多過ぎるのか、それとも閾値を越える回答が足りないのか）、Ａｓｓｉｓｔ ２２２（顧客がこのセッション中に支援された回数）、およびＴｉｍｅ ２２４（顧客がこのセッションにいる時間の長さ）。

質問解決パネル２２６において、人間エージェントは、顧客の質問への適正な回答を選択することができる。このパネルにおいてエージェントが実施し得るアクションは、Ｓｅａｒｃｈ ＫＢ ２２８（クエリを修正し、回答を求めて知識ベースを検索する）、Ｒｅｓｐｏｎｄ ２３０（ソフトウェアエージェントに、選択された回答で顧客に応答するよう命令する。クエリに合致するＡｎｓｗｅｒ ２３２が、パネルの下部にあるテーブルに表示される。各ａｎｓｗｅｒ ２３２は、文脈信頼性閾値より上か下か、その一致の順位、およびその質問の要約を示す。）、Ｔａｋｅ Ｏｖｅｒ ２３４（ソフトウェアエージェントから通話を引き継ぐ）、Ｗｈｉｓｐｅｒ ２３６（顧客の要求の記録を聞く）、およびＳｕｂｍｉｔ Ｏｒｉｇｉｎａｌ Ｑｕｅｓｔｉｏｎ ２３８（顧客の元の質問を、クエリとして知識ベースに提出する。これは、アプリケーションによって実施される初期アクションである。）である。

グラフィカルユーザインターフェイス２１０は、人間エージェントが「代替質問」というタイトルのボックスに、顧客のコミュニケーション用の代替テキストを入れることも可能にする。コンピュータ生成による応答の信頼性レベルが低い場合、人間エージェントは、顧客のコミュニケーションを、システムがよりうまく突き合わせることを人間エージェントが分かるように言い換えることを決定してよい。

ユーザインターフェイスの下部に２つの制御セット、すなわちトランスクリプトおよびデータがある。Ｔｒａｎｓｃｒｉｐｔボタン２４０は、ソフトウェアエージェントの、顧客とのダイアログのトランスクリプトをチャットスタイルのトランスクリプトで示すウェブページを起動する。このウェブページは、ソフトウェアエージェントの稼動中の会話トランスクリプトから、対話チャネルで使われる同じＣｏｃｏｏｎインフラストラクチャを介して生成される。Ｄａｔａボタン２４２は、ソフトウェアエージェントによって今までに収集されたアプリケーションデータを示すウェブページを起動する。このウェブページは、ソフトウェアエージェントのアプリケーションおよびネットワークプロパティから、対話チャネルで使われる同じｃｏｃｏｏｎインフラストラクチャを介して生成される。対話チャネルの場合と同様、このデータのアプリケーションレベル、ネットワークレベル、および／または文脈レベルでの提示を定義することが可能であり、定義は、より一般的なレベルの定義に優先するより具体的なレベルとされる。たとえば、文脈レベルでの定義が、ネットワークまたはアプリケーションレベルでの定義に優先することになる。

要約コントロールは、人間エージェントに、会話ログの中に置かれた手引きを提供させる。Ａｔｔａｃｈ Ｎｏｔｅボタン２４４は、人間エージェントに、会話ログの中のある対話に注記を添付させる。Ｍａｒｋ ｆｏｒ Ｒｅｖｉｅｗチェックボックス２４６は、ある対話が会話ログにおける検討のために印をつけられるべきであることを示すのに使われる。Ｄｏｎｅボタン２４８は、エージェントがある解決を済ませたことを示す。システムは、品質保証、論争解決および市場調査目的のために、アーカイブに入れられた、声およびテキストベースの会話を積極的に索引づけ、カテゴリ化し、監視する。これは完全に自動化されているので、システムは、顧客の通話パターンにおける偏差に対する通話アーカイブを積極的に監視することができ、通常の報告機構を介して監督者に警告する。

たとえば、会話マイニングのカテゴリでは、システムは、顧客オーディオを、後でデータマイニングするために転記する（たとえば、金融サービスのための品質管理）。これは、転記された会話をバッチ認識プロセス、すなわちログをクラスタ化するのに使われるＣＲＥから取ることを伴い、特定のトピック（すなわち販促、問題エリアなど）を求めてクラスタ内を検索する能力を提供する。システムは、特定のトピック（下位クラスタ）によって通話をクラスタ化し、下位クラスタ中の通話パターンにおける偏差を突き止め、印をつけ、管理者が、偏差が起こる、オーディオストリーム中の特定の点にアクセスするのを可能にすることもできる。この機能性は、エージェントが言うところの監査証跡を与える。たとえば、製品の返品についてのクラスタは、相異なるエージェントが顧客に、製品を相異なる場所に返すよう指示することを示し得る。こうするためには、クラスタが、マルチパスＡＳＲの前に、ログに関連づけられたデータを保有する。別の例として、クラスタは、一部のエージェントが、知識ベース中の既存の回答を、顧客質問（合成されたワークフロー）に関連づけ、他のエージェントは、通話を選び（引継ぎワークフロー）、独自の応答を与えることを示し得る。

コンタクトセンター管理への具体的な応用を含む、本発明の特定の実装形態を記載したが、他の非常に様々な実装形態も、添付の特許請求の範囲内である。

状態遷移線図を示す図である。 状態遷移グラフを示す図である。 顧客、システム、および人間エージェントの間の対話を示す図である。 フローチャートを示す図である。 ソフトウェアアーキテクチャシステムの概要を示す図である。 図４のソフトウェアアーキテクチャを示すより詳細な図である。 ワークフローコンポーネントシステムを示すブロック図である。 対話チャネルコンポーネントを示すブロック図である。 音声認識装置を示すブロック図である。 概念認識エンジンを示すブロック図である。 マークアップ言語ドキュメントの編成を示す図である。 一例のグラフに対する状態遷移グラフのサブセットを示す図である。 反復アプリケーション開発プロセスを示す図である。 スクリーンショットを示す図である。 別のスクリーンショットを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 初期アプリケーション開発プロセスを示す図である。 学習サーバを示すブロック図である。

Claims (83)

1. 第１の当事者タイプのメンバと第２の当事者タイプのメンバとの間の１つの会話セットを受け取ることであって、前記会話はそれぞれ、前記第１の当事者タイプのメンバのコミュニケーション、および前記第１の当事者タイプの前記メンバの前記コミュニケーションに応答する、前記第２の当事者タイプのメンバのコミュニケーションを含むこと、
   前記第１の当事者タイプのメンバの前記コミュニケーションを第１のクラスタセットにグループ化すること、
   前記第１の当事者タイプのメンバの前記コミュニケーションの前記グループ化に基づいて、前記第２の当事者タイプのメンバの前記応答側コミュニケーションを第２のクラスタセットにグループ化すること、ならびに
   マシンによって、前記第２のクラスタセット中の１つまたは複数のクラスタ用の１組の第２の当事者タイプ分類器を生成することを含むことを特徴とする方法。
2. 前記コミュニケーションは、発声を含むことを特徴とする請求項１に記載の方法。
3. 前記コミュニケーションは、テキストメッセージを含むことを特徴とする請求項１に記載の方法。
4. 前記第１の当事者タイプのメンバの前記コミュニケーションは、コールセンターにいる人間カスタマーサービスエージェントのコミュニケーションを含むことを特徴とする請求項１に記載の方法。
5. 前記第１の当事者タイプのメンバの前記コミュニケーションは、コールセンターと交信する人間とコミュニケーションをとるように構成されたソフトウェアエージェントのコミュニケーションを含むことを特徴とする請求項１に記載の方法。
6. 前記第２の当事者のメンバの前記コミュニケーションは、コールセンターと交信した人間のコミュニケーションを含むことを特徴とする請求項１に記載の方法。
7. 前記分類器は、サポートベクターマシンを含むことを特徴とする請求項１に記載の方法。
8. 前記分類器は、決定木を含むことを特徴とする請求項１に記載の方法。
9. 第１の当事者タイプのメンバのコミュニケーションは、コンピュータを使って、第１のクラスタセットにグループ化されることを特徴とする請求項１に記載の方法。
10. 第１の当事者タイプのメンバのコミュニケーションを第１のクラスタセットにグループ化することは、前記コミュニケーションの意味特徴を判定することを含むことを特徴とする請求項９に記載の方法。
11. 前記第１の当事者タイプのメンバのコミュニケーションを第１のクラスタセットにグループ化することは、前記第１の当事者タイプのメンバの前記コミュニケーションの意味に基づくことを特徴とする請求項１に記載の方法。
12. マシンによって、前記第１のクラスタセット中の１つまたは複数のクラスタ用の１組の第１の当事者タイプ分類器を生成することをさらに含むことを特徴とする請求項１に記載の方法。
13. 前記第１の当事者タイプのメンバのコミュニケーションを第１のクラスタセットにグループ化することは、
    前記第１の当事者タイプのメンバからの情報要求に対応するコミュニケーションを第１のクラスタセットにグループ化することを含むことを特徴とする請求項１に記載の方法。
14. 前記第２の当事者タイプのメンバの応答側コミュニケーションを、前記第１の当事者タイプのメンバの前記コミュニケーションの前記グループ化に基づいて、第２のクラスタセットにグループ化することは、
    前記第２の当事者タイプのメンバのコミュニケーションを、前記第１の当事者タイプのメンバからの前記情報要求への応答に対応するグループにグループ化することを含むことを特徴とする請求項１３に記載の方法。
15. 前記第２の当事者タイプのメンバの応答側コミュニケーションを、前記第１の当事者タイプのメンバの前記コミュニケーションの前記グループ化に基づいて、第２のクラスタセットにグループ化することは、
    前記第１の当事者タイプ分類器を使って、前記第１の当事者タイプのメンバのコミュニケーションを、前記第１の当事者タイプのクラスタに分類すること、
    前記第１の当事者タイプの前記メンバの前記分類されたコミュニケーションに続く前記第２の当事者タイプのメンバのコミュニケーションを、前記第１の当事者タイプの前記クラスタに関する前記第２の当事者タイプのクラスタにグループ化することを含むことを特徴とする請求項１３に記載の方法。
16. 前記第１の当事者タイプの前記クラスタは、前記第１の当事者タイプのメンバによって行われた情報要求に関し、前記第２の当事者タイプの前記クラスタは、前記第２の当事者タイプのメンバによって与えられた前記情報要求への応答に関することを特徴とする請求項１５に記載の方法。
17. 前記第１の当事者タイプのメンバと前記第２の当事者タイプのメンバとの間の第２の会話セットを受け取ることであって、前記会話はそれぞれ、前記第１の当事者タイプのメンバのコミュニケーション、および前記第１の当事者タイプの前記メンバの前記コミュニケーションに応答する、前記第２の当事者タイプのメンバのコミュニケーションを含むこと、
    分類器を適用して、前記第２の当事者タイプのメンバの前記コミュニケーションをグループ化すること、
    マシンによって、前記第２のクラスタセット中のクラスタ用の第２の当事者タイプ分類器を、前記クラスタ中のグループ化された前記コミュニケーションに関するデータを使って生成し直すことをさらに含むことを特徴とする請求項１に記載の方法。
18. マシンによって、１組の分類器を適用して、応答側コミュニケーションも含む会話の一部である開始側コミュニケーションをカテゴリ化すること、および
    マシンによって、前記カテゴリ化された開始側コミュニケーションを用いて、共通コミュニケーションパターンを識別することを含むことを特徴とする方法。
19. 会話を１つの会話セットにグループ化することをさらに含むことを特徴とする請求項１８に記載の方法。
20. 識別された共通コミュニケーションパターンを、会話グループに関連づけることをさらに含むことを特徴とする請求項１９に記載の方法。
21. 前記会話は、前記会話の主題によってグループ化されることを特徴とする請求項２０に記載の方法。
22. 前記コミュニケーションは、発声を含むことを特徴とする請求項１８に記載の方法。
23. 前記会話は、カスタマーサービスコールセンターに関連したエージェントからのコミュニケーションと、前記コールセンターと交信した顧客からのコミュニケーションとを含むことを特徴とする請求項２２に記載の方法。
24. 前記エージェントは、人間エージェントであることを特徴とする請求項２３に記載の方法。
25. 前記顧客の、前記コールセンターとの交信理由に従って、会話を前記会話セットにグループ化することをさらに含むことを特徴とする請求項２３に記載の方法。
26. マシンによって、分類器を適用して、第２の当事者タイプのメンバによって行われた応答側コミュニケーションも含む会話における、第１の当事者タイプのメンバによって行われた分類された１つのコミュニケーションセットを識別すること、および
    マシンによって、前記会話それぞれの主題を、会話における前記第１の当事者タイプの前記メンバの分類された前記１つのコミュニケーションセットに基づいて判定することを含むことを特徴とする方法。
27. 前記分類器は、前記コミュニケーションを、前記コミュニケーションにおける具体化された概念の表現に従って分類することを特徴とする請求項２６に記載の方法。
28. 前記第１の当事者タイプの前記メンバのカテゴリ化されたコミュニケーションの前記組合せに基づいて、前記会話の主題を判定することは、
    前記１組のカテゴリ化されたコミュニケーションを、既知の主題を有する会話に関連づけられたカテゴリ化された１つのコミュニケーションセットと突き合わせることを含むことを特徴とする請求項２７に記載の方法。
29. 前記分類された１つのコミュニケーションセットに基づいて、前記会話の前記主題を判定することは、前記セット中の前記分類されたコミュニケーションの特定のどの順序にもよらずに行われることを特徴とする請求項２６に記載の方法。
30. 前記コミュニケーションは、発声を含むことを特徴とする請求項２６に記載の方法。
31. 前記第１の当事者タイプのメンバの前記コミュニケーションは、コールセンターにいるカスタマーサービスエージェントのコミュニケーションを含むことを特徴とする請求項２６に記載の方法。
32. 前記カテゴリ化された一連のコミュニケーションは、前記カスタマーサービスエージェントにより行われる一連の要求を含むことを特徴とする請求項２６に記載の方法。
33. 前記カスタマーサービスエージェントは、人間を含むことを特徴とする請求項３１に記載の方法。
34. 前記カスタマーサービスエージェントは、人間発信者とコミュニケーションをとるように構成されたソフトウェアを含むことを特徴とする請求項３１に記載の方法。
35. 前記１組の分類器は、サポートベクターマシンを備えることを特徴とする請求項２６に記載の方法。
36. 人とコンタクトセンターに関連したエージェントとの間の一連のコミュニケーションを、少なくともそのいくつかが含む会話のデジタル表現を受け取ること、ならびに
    １つまたは複数の選択基準が満たされる場合、コミュニケーションを学習機会として選択することを含むことを特徴とするコンピュータ実施方法。
37. 前記コミュニケーションは、発声を含むことを特徴とする請求項３６に記載の方法。
38. 前記コミュニケーションは、テキストメッセージを含むことを特徴とする請求項３６に記載の方法。
39. 前記コンタクトセンターに関連した前記エージェントは、前記人とコミュニケーションをとるように構成されたソフトウェアエージェントを含むことを特徴とする請求項３６に記載の方法。
40. 前記コンタクトセンターに関連した前記エージェントは、前記人とコミュニケーションをとる人間エージェントを含むことを特徴とする請求項３６に記載の方法。
41. 前記選択基準は、
    コミュニケーションの後に、前記人と１つまたは複数のエージェントとの間のコミュニケーションのやり取りが続くという要件を含むことを特徴とする請求項３６に記載の方法。
42. 前記選択基準は、
    コミュニケーションの後に、前記人と１つまたは複数のエージェントとの間の、事前に定義された数の、後続の成功したコミュニケーションのやり取りが続くという要件を含むことを特徴とする請求項３６に記載の方法。
43. 前記選択基準は、
    前記システムによって課された満足性質問に前記人が肯定的に応答した会話にコミュニケーションが含まれるという要件を含むことを特徴とする請求項３６に記載の方法。
44. 前記選択基準は、
    第１の会話におけるコミュニケーションが、他のいくつかの会話において起こる同様のコミュニケーションによって確認されるという要件を含むことを特徴とする請求項３６に記載の方法。
45. 前記選択基準は、
    前記同様のコミュニケーションが起きた前記会話の少なくとも１つが、前記システムによって課された満足性質問に人が肯定的に応答したという指示を含むという要件を含むことを特徴とする請求項４４に記載の方法。
46. 前記人とエージェントの間の前記コミュニケーションの少なくともいくつかは、人間エージェントが人のコミュニケーションへの応答を、前記自動化応答システムによって生成された応答案のランクづけされたリストから選択した支援対話を含むことを特徴とする請求項３６に記載の方法。
47. 前記選択基準は、
    支援対話における選択された応答が、閾値を上回るようにランクづけされるという要件を含むことを特徴とする請求項４６に記載の方法。
48. 前記選択基準は、
    支援対話における選択された応答が、信用できる人間エージェントから選択されるという要件を含むことを特徴とする請求項４６に記載の方法。
49. 信用できる人間エージェントは、そのコンタクトセンターを、所定の長さの時間を超えて利用したことがあるエージェントであることを特徴とする請求項４８に記載の方法。
50. 前記選択基準は、
    コミュニケーションが、前記コミュニケーションを用いて組み立てられた１組の分類器に、以前の１組の分類器が正しく分類したコミュニケーションの分類を誤らせないという要件を含むことを特徴とする請求項３６に記載の方法。
51. 前記選択基準の１つまたは複数を、ユーザから受け取ることをさらに含むことを特徴とする請求項３６に記載の方法。
52. 前記選択基準を入れることができるようにするためのグラフィカルユーザインターフェイスを提供することをさらに含むことを特徴とする請求項５１に記載の方法。
53. 選択されたコミュニケーションを用いて、分類器を生成することをさらに含むことを特徴とする請求項３６に記載の方法。
54. 前記分類器は、サポートベクターマシンを備えることを特徴とする請求項５３に記載の方法。
55. 選択されたコミュニケーションを用いて、自動音声認識エンジン用の言語モデルを生成することをさらに含むことを特徴とする請求項３６に記載の方法。
56. 選択されたコミュニケーションを用いて、有限状態ネットワークを生じることをさらに含むことを特徴とする請求項３６に記載の方法。
57. 学習機会として選択された発声に対して、音声認識を実施することをさらに含むことを特徴とする請求項３７に記載の方法。
58. 前記音声認識の実施に先立って、前記コミュニケーションの前記デジタル表現に関連づけられた前記発声の意味の信頼性レベルに基づいて、前記選択された発声に対して音声認識を実施するべきかどうか判定することをさらに含むことを特徴とする請求項５７に記載の方法。
59. 発信者とコンタクトセンターに関連したエージェントとの間の一連の発声を含む会話のデジタル表現を受け取ること、ならびに
    デジタル表現を受け取った後、１つまたは複数の選択基準に基づいて、転記のための前記発声を選択することを含むことを特徴とするコンピュータ実施方法。
60. 前記選択基準は、
    前記自動化音声応答システムによる応答の信頼性レベルが、一定の範囲の値に収まるという要件を含むことを特徴とする請求項５９に記載の方法。
61. ユーザから、グラフィカルユーザインターフェイスを介して前記範囲の値を受け取ることをさらに含むことを特徴とする請求項６０に記載の方法。
62. 前記選択基準は、
    前記会話中に前記発声に対して実施される音声認識プロセスの信頼性レベルが、一定の値の範囲に収まるという要件を含むことを特徴とする請求項５９に記載の方法。
63. ユーザから、グラフィカルユーザインターフェイスを介して前記値の範囲を受け取ることをさらに含むことを特徴とする請求項６２に記載の方法。
64. 前記選択された発声に対して、コンピュータ実装音声認識プロセスを実施することをさらに含むことを特徴とする請求項５９に記載の方法。
65. 前記選択された発声の中の認識された単語を、前記システムによって、会話中の発声を認識するのに使われる音声認識プロセスによって使われる単語の語彙に追加することをさらに含むことを特徴とする請求項５９に記載の方法。
66. 人間エージェントが人のコミュニケーションへの応答を、自動化応答システムによって提案された応答の中から選択した、人と前記自動化応答システムに関連した前記エージェントとの間の対話に基づくこと、及び
    前記コミュニケーションを、前記自動化応答システムをトレーニングするための例として選択することを含むことを特徴とする方法。
67. 前記コミュニケーションを選択することは、
    前記選択された応答の信頼性レベルに基づいて、前記コミュニケーションを選択することを含むことを特徴とする請求項６６に記載の方法。
68. 前記選択されたコミュニケーションを用いて、分類器をトレーニングすることをさらに含むことを特徴とする請求項６６に記載の方法。
69. 前記選択されたコミュニケーションを、統計的言語モデル自動音声認識プロセスの言語モデルに追加することをさらに含むことを特徴とする請求項６６に記載の方法。
70. 前記コミュニケーションを選択することは、
    前記応答を選択した人間エージェントの信用レベルに基づいて、前記コミュニケーションを選択することを含むことを特徴とする請求項６６に記載の方法。
71. 前記コミュニケーションは、発声を含むことを特徴とする請求項６６に記載の方法。
72. マシンによって、応答システムと交信する人と、人間エージェントとの間のコミュニケーションを識別すること、ならびに
    前記自動化応答システムを、前記システムと交信する人からの将来の同様のコミュニケーションに応答するように修正することを含むことを特徴とする方法。
73. 前記自動化応答システムを、前記システムと交信する人からの将来の同様のコミュニケーションに応答するように修正することは、
    前記システムに関連づけられた有限状態遷移ネットワークを修正することを含むことを特徴とする請求項７２に記載のシステム。
74. 概念認識エンジン内の分類器用の１組のトレーニング例にコミュニケーションを追加すること、
    前記追加されたコミュニケーションを含む前記１組のトレーニング例を使って、新たな分類器を生成すること、および
    新たな分類器の性能要件に基づいて、前記新たな分類器を無視することを含むことを特徴とするコンピュータ実施方法。
75. 前記性能要件は、
    新たな分類器が、他の少なくとも所定の数の例を正しく分類するという要件を含むことを特徴とする請求項７４に記載の方法。
76. 前記性能要件は、
    新たな分類器が、以前の前記分類器の確定的な前記１組の例とは所定の量だけ異なる、確定的な新たな１組の例をもつという要件を含むことを特徴とする請求項７４に記載の方法。
77. 応答側コミュニケーションの少なくとも１つのクラスタ用の１組の分類器を生成することであって、前記クラスタは、前記応答側コミュニケーションが会話中に関連づけられる開始側コミュニケーションの１つまたは複数のクラスタに基づくことを含むことを特徴とする方法。
78. 前記開始側の会話は、第１の当事者タイプのメンバからのものであることを特徴とする請求項７７に記載の方法。
79. 前記応答側コミュニケーションは、第２の当事者タイプのメンバからのものであることを特徴とする請求項７７に記載の方法。
80. 前記第１の当事者タイプは、顧客コンタクトセンターに関連したエージェントを含むことを特徴とする請求項７８に記載の方法。
81. 前記第２の当事者タイプは、顧客コンタクトセンターと交信した顧客を含むことを特徴とする請求項７９に記載の方法。
82. 開始側コミュニケーションおよび関連づけられた応答側コミュニケーションを、少なくともそのいくつかが含む１つの会話セットを受け取ることをさらに含むことを特徴とする請求項７７に記載の方法。
83. 応答側コミュニケーションの前記クラスタは、開始側コミュニケーションに関連づけられた応答側コミュニケーションを含むことを特徴とする請求項７７に記載の方法。

Images