JP2000514986A - コンピュータ―テレフォニ統合システムにおいて複数のオブジェクト状態を決定して使用する方法およびシステム - Google Patents

Abstract

(57)【要約】 報告アプリケーション（１５２，１５３）がコールセンター（１００）中のエンティティのステータスを要求アプリケーション（１５２，１５３）に柔軟性を持って報告する方法が提供される。エンティティは１つ以上の状態をとることができる。エンティティの例はディレクトリ番号（２１７，２１８，２１９，２２３，２２４）、エージェント（２３０，２３１）、グループ（２３２，２３３）、ルーティングポイント（２１４，２１５，２１６，２２１，２２２）、およびエージェント場所（２２６，２２７，２８８）である。要求アプリケーション（１５２，１５３）は、ステータス優先順位テーブルを報告アプリケーション（１５２，１５３）に送ることにより、エンティティに属するこれらの状態の優先順位を設定する。報告アプリケーション（１５２，１５３）はエンティティのアクティブ状態と優先順位テーブルに基づいてステータスを報告する。例として、報告されるステータスはテーブル中で最高の優先順位の有するアクティブ状態である。この状態は要求アプリケーション（１５２，１５３）に戻される。異なる要求アプリケーション（１５２，１５３）が異なる優先順位テーブルを表すことができることから、報告アプリケーション（１５２，１５３）は同じエンティティに対して異なる状態を報告することができる。

Description

【発明の詳細な説明】 コンピューターテレフォニ統合システムにおいて 複数のオブジェクト状態を決定して使用する方法およびシステム 発明の分野 この発明はコールセンターにおける電話通信に関し、特に、複数のオブジェク ト状態をとることができる、コールセンター中のエンティティのステータスを決 定する方法およびシステムに関する。 発明の背景 電話は、世界中で最も広く使用されている通信装置の１つである。当初電話は 人々が物理的に離れているにも関わらず通信できる単なる便利なツールであった 。最近では多くの会社が電話を使用して製品やサービスを売買し、消費者製品に 対して技術的サポートを提供し、発呼者が自分自身の金融データ等にアクセスで きるようにしている。したがって、電話は主要なビジネスおよび取引ツールとな ってきた。 ビジネスや取引目的に電話をもっと有効に使用するために、コールセンターが 開発されている。コールセンターでは、非常に多くのエージェントが発呼者との 電話通信を取扱う。発呼者とエージェント間の通話のマッチングは一般的にソフ トウェアによりなされる。ここでは簡単な例を使用してコールセンターを使用す る多くの利点の内のいくつかを説明する。コールセンターに対して通話がなされ ると、一般的に電話キャリアにより通話回線の電話番号がコールセンターに入手 可能である。この電話番号に基づいて、コールセンターのソフトウェアはデータ ベースサーバにアクセスして、その電話番号に割当てられている発呼者について の情報を得ることができる。ソフトウェアは予め定められた基準（例えば、言語 スキル、発呼者が購入した製品についての知識等）に基づいてその通話を最高に 取扱うことができるエージェントに通話をルーティングすることができる。ソフ トウェアは、エージェントにより使用されるコンピュータスクリーンに直ちに関 連情報を伝える。したがって、エージェントは通話を受ける前に発呼者について の価値のある情報を得ることができる。結果として、エージェントはさらに効果 的に電話処理を取扱うことができる。 先の例から、有効な技術は電話スイッチング技術とコンピュータ情報処理技術 の結合を必要とすることが分かるであろう。この結合された技術のために一般的 に使用される用語は、コンピューターテレフォニ統合（ＣＴＩ）である。 ルーティングの決定をする際に、ソフトウェアはすべてのエージェントの状態 を知る必要がある。例えば、エージェントがビジー状態である（例えば、他の通 話に答えている）場合には、通話はそのエージェントにルーティングされない。 従来技術のＣＴＩシステムでは、エージェントは１つの状態のみを持つ。ルーテ ィングソフトウェア（とともにシステム中の他のソフトウェア）はこの状態に基 づいて決定をする。しかしながらこのシステムには柔軟性がない。例えば、エー ジェントが何らかの仕事をしていて（例えば、緊急でない事項について同僚と会 話していて）ビジーであっても、カスタマからの通話をとるために手が空いてい る他の適任なエージェントがいない場合には、エージェントはその通話を受け入 れることができるかもしれない。したがって、コールセンターのリソースをより よく利用することができる柔軟性あるシステムを得ることが望ましい。 発明の要約 本発明は要求ソフトウェアアプリケーションに対してコールセンター中のエン ティティのステータスを柔軟性を持つて報告する方法に関係している。エンティ ティは現在、（アクティブ状態と呼ばれる）複数の可能性ある状態のうちの１つ 以上の状態に入っているかもしれない。第１の（報告）ソフトウェアアプリケー ションは、（ｉ）エンティティのアクティブ状態、および（ｉｉ）第２の（要求 ）ソフトウェアアプリケーションにより提供される優先順位リストに基づいてエ ンティティのステータスを決定する。その後この報告ソフトウェアアプリケーシ ョンはステータスを要求ソフトウェアアプリケーションに報告する。 この発明の１つの利点は、要求ソフトウェアアプリケーションが状態の優先順 位を決定することである。おそらく、各要求ソフトウェアアプリケーションには 状態情報を利用するのに最良の方法が分かっている。したがって、要求ソフトウ ェアアプリケーションが優先順位を決定できるようにすることは、同じステータ スをすべての要求ソフトウェアアプリケーションに報告するよりも非常によいこ とである。 本発明の１つの実施形態では、エンティティには物理的なエンティティ（例え ば、キューおよびルーティングポイント、エージェントディレクトリ番号、なら びにエージェント）と論理的なエンティティ（例えば、エージェント場所、およ びグループ）が含まれている。各エンティティはソフトウェアオブジェクトと関 係している。各オブジェクトは１つ以上の可能性のある状態と１つ以上のアクテ ィブ状態を持つことができる。要求ソフトウェアアプリケーションは各エンティ ティオブジェクトに対してこれらの可能性ある状態の優先順位を設定し、それら を例えばステータス優先順位テーブルの形態で表す。このテーブルは報告ソフト ウェアアプリケーションに送られる。報告ソフトウェアアプリケーションは、最 高の優先順位を持つアクティブ状態としてオブジェクトのステータスを報告する 。 本発明の他の実施形態では、要求ソフトウェアアプリケーションは報告ソフト ウェアアプリケーションに対してステータスを１度だけ報告するように要求して もよい。代わりに、要求ソフトウェアアプリケーションは連続ベースで報告する ことを要求してもよい。報告ソフトウェアアプリケーションは報告の頻度を規定 することができる。 本発明は単一の自動通話分配装置システムおよび複数の自動通話分配装置シス テムにおいて使用することができる。 本発明のこれらのおよび他の特徴は、添付した図面とともに読むと、以下の説 明から明らかになるであろう。 図面の簡単な説明 図１は、本発明の複数のオブジェクト状態決定システムを実現することができ るコールセンターのブロック図である。 図２は、本発明の複数のコールセンターシステムのスタットサーバにおいて使 用されるオブジェクトを例示した図である。 発明の詳細な説明 本発明は新規なコールセンター方法およびシステムを含んでいる。以下の説明 は、当業者が本発明を作りそして使用できるように提供されている。特定の適用 の説明は例としてのみ提供されている。好ましい実施形態に対するさまざまな修 正は当業者に容易に明らかになるであろう。また、ここに規定されている一般的 な原理は本発明の精神および範囲を逸脱することなく他の実施形態および応用に 適用してもよい。したがって、本発明は示されている実施形態に限定されること を意図しているものではなく、ここに開示されている原理および特徴と矛盾しな い最も広い範囲にしたがうものである。 図１は本発明を実現するのに使用することができるコールセンター１００のブ ロック図である。コールセンター１００は公衆電話交換ネットワーク（ＰＳＴＮ ）１０４に接続されていろ。コールセンター１００には、ＰＳＴＮ１０４からの 通話を受け入れるスイッチ１０８が含まれている。スイッチ１０８は、自動通話 分配装置（ＡＣＤ）／構内交換機（ＰＢＸ）またはＰＳＴＮスイッチとすること ができる。スイッチ１０８には、（ＰＳＴＮ１０４に接続するための）高帯域幅 ポート１１０と（ポート１１２−１１６のような）複数の低帯域幅ポートが含ま れている。これらの低帯域幅ポートのうちいくつかは音声ベースの装置に接続す ることができる。例えば、ポート１１２−１１５はそれぞれ電話機１２０−１２ ３に接続されている。エージェントはこれらの電話機を取扱うように割り当てら れる。各低帯域幅ポートには１つ以上のディレクトリ番号（“ＤＮ”）が割り当 てられている。 標準的なスイッチにより実行される機能はかなり制限され、典型的なコールセ ンターの要求には合わないことが分かった。例えば、（ワークステーション１２ ６−１２７のような）各エージェントに利用可能なワークステーションに対して 通話についての情報を提供することが好ましい。しかしながら、スイッチはデー タをサーチし、処理し、これらのワークステーションにルーティングすることが できない。結果として、音声とデジタルデータの組み合わせを所要の場所にルー ティングするために、コンピューターテレフォニ統合（ＣＴＩ）と呼ばれる新し い技術が必要とされる。 ＣＴＩを実現する方法として、コールセンター１００はＣＴＩサーバ１３２に 接続されたルーティングサブシステム１３０をさらに含んでおり、このＣＴＩサ ーバ１３２は次にＣＴＩリンク１３４を通してスイッチ１０８に接続されている 。スイッチ１０８とＣＴＩサーバ１３２との問の通信は一般的にＸ．２５プロト コルにしたがう。ＣＴＩサーバ１３２はルーティングサブシステム１３０とスイ ッチ１０８との間のインターフェイスを提供する。スイッチ１０８は、通話を受 信した時にＣＴＩサーバ１３２に通知する。ＣＴＩサーバ１３２は情報をルーテ ィングサブシステム１３０に送り、このルーティングサブシステム１３０は、予 め定められた基準にしたがって、その通話に答えるのに最も適任なエージェント を選択する。その後ＣＴＩサーバ１３２はスイッチ１０８に通知して、その通話 を選択されたエージェントの電話機（すなわち、ＤＮ）に向けさせる一方、ルー ティングサブシステム１３０は、電話をかけてきた人に関するデータを選択され たエージェントのワークステーションに向ける。 本発明の１つの実施形態では、ルーティングサブシステム１３０には、スタッ トサーバ１４０、ルーティングサーバ１４２、およびデータベース１４４が含ま れている。これらはデータ通信ネットワーク１５０を使用して相互に通信する。 スタットサーバ１４０はすべての通話に関係する履歴データ、スイッチのアクテ ィビィティ、コールセンター１００のすべてのエージェントの情報やアクティビ ィティを集めて記憶する。データベース１４４は、カスタマ、エージェント、電 話番号、およびコールセンター１００のさまざまな観点の情報を含んでいる。ル ーティングサーバ１４２はスタットサーバ１４０およびデータベース１４４のデ ータを使用して通話を取扱うのに適切なエージェントを選択する。選択後、ルー ティングサーバ１４２はコマンドをＣＴＩサーバ１３２に送り、次にＣＴＩサー バ１３２はスイッチ１０８に対して入通話を選択されたエージェントにルーティ ングするように命令する。 他のＣＴＩ関連アプリケーション（すなわち、ソフトウェアモジュール）があ ってもよく、これらはデータベース１４４とスタットサーバ１４０のリソースを 使用して、他のサービスまたは情報をコールセンター中のエージェントに提供す る。図１では、２つのアプリケーション（１５２および１５３）が示されている 。アプリケーションの例は、ジェネシス・テレコミュニケーション・ラボラトリ により販売されている“エージェントビュー”および“コールセンタービュー” である。これらのアプリケーションはデータ通信ネットワーク１５０に接続され ている。 コールセンターでは、エージェントが２台以上の電話機を管理することが普通 である。エージェントにより使用される装置は、この出願中で“エージェント場 所”と呼ばれる、（デスクのような）便利な場所に通常設置される。図１は２つ の例示的なエージェント場所１６１および１６２を示している。エージェント場 所１６１にはワークステーション１２６と２台の電話機１２０および１２１が含 まれている。同様に、エージェント場所１６２にはワークステーション１２７と ２台の電話機１２２および１２３が含まれている。エージェントがエージェント 場所を占有しているとき、エージェントはそこにある電話機あるいはワークステ ーションのいづれかを使用してログオンする。エージェントがエージェント場所 を離れる前に、エージェントは電話機あるいはワークステーションを使用してロ グアウトする。結果として、コールセンター１００は各エージェントの現在の位 置を追跡することができる。 スタットサーバ１４０は、１組のアプリケーションプログラミングインターフ ェイス（“ＡＰＩ”）コマンドを通して、ＣＴＩサーバ１３２、ルーティングサ ーバ１４２およびアプリケーション１５２−１５３と通信する。（ＣＴＩサーバ １３２とともに動作する）スタットサーバ１４０はスイッチ１０８のアクティビ ィティを監視して記憶することができる。スタットサーバ１４０はさまざまなエ ージェントのアクティビィティおよびエージェント場所も監視して記憶する。ル ーティングサーバ１４２およびアプリケーション１５２−１５３による、対象と するオブジェクト（例えば、エージェント）のステータスに関する質間に応答し て、スタットサーバ１４０は報告をルーティングサーバ１４２に提供する。１つ のスタットサーバを使用して（１つ以上のコール七ンターに位置しているかもし れない）いくつかのスイッチを管理する実施形態では、スタットサーバ１４０は すべてのスイッチのアクティビィティ、これらのスイッチにより取扱われるすべ てのエージェントおよびすべてのエージェント場所を監視して記憶する。本発明 のスタットサーバを使用するかもしれない複数のコールセンターアーキテクチャ ーの詳細な説明は、１９９７年１月１４日に出願され、本願と同じ譲受人に譲渡 された”複数のコールセンターを運用するシステムおよび方法”と題する留保中 の特許出願第０８／７８２，９８３号に開示されている。この特許出願は参照の ためにここに組み込まれている。 ほとんどのコールセンターエンティティ（例えば、電話機およびエージェント ）は同時に複数の状態をとれることが認められている。例えば、エージェントの 電話機は同時にいくつかのアクティビィティを取扱うように設計されている。し たがって、エージェントは同じ電話機を使用して１人のカスタマと話し、他の人 （例えば、同僚）を待たせてもよく、また入通話を待っていてもよい。従来技術 のシステムでは、（いくつかある状態の中から）どの状態を報告すべきかが明確 でないことから、スタットサーバが電話機の状態を他のＣＴＩアプリケーション に報告するときには、このことは報告に関する問題となる。 本発明は複数の状態を利用する方法およびシステムである。異なるＣＴＩアプ リケーションが状態関連情報を異なって使用する必要があることが分かる。例え ば、エージェントが電話で会話をしていたり、データ入力のためにワークステー ションを使用している場合には、レギュラルーティングルーチンはエージェント がビジーであると考える。しかしながら、高い優先順位の通話（例えば、緊急通 話や貴重なカスタマからの通話）を取扱うアプリケーションは、エージェントが エージェント場所にログオンしている限り同じエージェントが利用可能であると 考える。これは、緊急電話通話があった場合に、エージェントがワークステーシ ョンでの仕事を止めたり、通話を保留状態にすることができるからである。した がって、本発明によりアプリケーションがいくつかある状態のうちどれを知らせ て欲しいかを規定することができる。 本発明の実施形態をこれから説明する。この実施形態では、コールセンター中 のさまざまなエンティティがソフトウェアオブジェクトと関係している。以下の ものはこれらのオブジェクトのいくつかの例である。 （ａ）キューとルーティングポイント：これらはスイッチ中のハードウェア回 路であり、オブジェクトとして表されている。キューはハードウェア制御ＡＣＤ メカニズムを実現する。制御ディレクトリ番号（“ＣＤＮ”）として呼ばれるこ とがあるルーティングポイントは、（ルーティングルーチンのような）ソフトウ ェアアプリケーションにより制御することができる。 （ｂ）エージェントＤＮ：これらはスイッチのハードウェアポートであり、オ ブジェクトとして表されている。各ＤＮは１つ以上の特性と関係している。例え ば、ＤＮの中には他のＤＮに直接アクセスすることができるものもあり；ＤＮの 中にはキューと関係しているものもあり；ＤＮの中には出通話に制限されるもの もあり；ＤＮの中には前の通話の終了後に利用不可能な期間を持つものもある。 特定の例では、ノーザン・テレコムにより製造されたスイッチの中には基本的に ２種類のＤＮ、位置および内線を含むものがある。内線ＤＮは電話機により直接 アクセスすることができ、出通話を始めることができる。位置ＤＮは１つ以上の キューと関係している。位置ＤＮはこれらのキューを通してのみアクセスするこ とができ、出通話を始めることができない。 （ｃ）他の特定のＤＮ：これらは、ボイスメールシステム、相互対話型音声応 答ュニットなどのような特定のデバイスに接続されているＤＮである。これらの ＤＮがオブジェクトとして表されている。 （ｄ）エージェント場所：これらは論理的なスペースであり、それぞれそのス ペースと関係するアイテム（例えば、おそらく異なるスイッチやワークステーシ ョンに付けられた１つ以上のＤＮ）を含んでいる。物理的な構成では、これらの 場所はデスクとすることができる。エージェントがある場所の１つのアイテムに ログインすると、全体の場所に対して論理的にログインすることになる。各場所 はオブジェクトとして表され、場所ＩＤと関係している。 （ｅ）エージェント：エージェントＩＤにより識別される人（オブジェクト） 。エージェントは場所間をダイナミックに移動することができる。スタットサー バは、すべてのエージェントの位置をダイナミックに追跡する特別なルーチンを 持っている。例えば、エージェントは第１の場所で午前９：００から１３：００ （すなわち、午後１：００）まで働くことができ；（例えばランチのために）ロ グアウトし、１４：００に第２の場所でログインする。エージェント位置追跡ル ーチンはその情報を維持するので、ルーティングサーバ（および他のアプリケー ション）には、そのエージェントに到達するのにはどのＤＮをダイヤルするのか が分かる。また各エージェントは“本拠地”を持っていてもよく、これはエージ ェントをダイナミックに追跡できない場合のデフォルト値である。 （ｆ）グループ：任意の組み合わせの多数のエージェント。グループオブジェ クトはグループＩＤにより識別される。少なくとも２つのタイプのグループがあ る。（ここではSObjectGroupAgentsとして識別される）第１のタイプにはエージ ェントＩＤのリストが含まれている。このケースでは、スタットサーバはすべて のエージェントの移動を追跡し、含まれているエージェントに対する統計のみを 集める。例は特定のスキルを有するグルーブである。（ここではSObjectGroupPl acesとして識別される）第２のタイプにはエージェント場所（場所ＩＤ）のリス トが含まれている。このリスト中の場所の例は、トレーニングルーム、メインオ フィス、第２フロアーなどである。このケースでは、これらの場所でだれが働い ているのかは重大でないことから、スタットサーバはこのリストに含まれている 場所に関係するイベントを追跡する。 図２を使用して先に説明したオブジェクトを例示する。図３は、１つ以上のコ ールセンターの２つの物理的なスイッチをシミュレートしている２つのスイッチ オブジェクト２１２および２１３を示している。スイッチオブジェクト２１２は 以下のリソースを含んでいる：ＣＤＮオブジェクト２１４および２１５、キュー ＤＮオブジェクト２１６、およびＤＮオブジェクト２１７−２１９。同様に、ス イッチオブジェクト２１３は以下のリソースを含んでいる：ＣＤＮオブジェクト ２２１、キューＤＮオブジェクト２２２、およびＤＮオブジェクト２２３−２２ ４。これらのオブジェクトは物理的なスイッチ中の対応するＣＤＮ、キュー、お よびエージェントＤＮを表している。 エージェントＤＮオブジェクト２１７−２１９および２２３−２２４はエージ ェント場所オブジェクトにも含まれている。この例では、エージェント場所オブ ジェクト２２６にはＤＮオブジェクト２１７および２１８が含まれ、エージェン ト場所オブジェクト２２７にはＤＮオブジェクト２１９および２２３が含まれ、 エージェント場所オブジェクト２２８にはＤＮオブジェクト２２４が含まれてい る。２つの異なるスイッチからのＤＮを同じエージェント場所に関係させること ができることに留意すべきである。 エージェント場所オブジェクトの中には、互いにグループ化して場所グループ オブジェクトを形成できるものもある。図２では、１つの場所グループオブジェ クト２３２のみが示されている。 図２は、オブジェクト２３０および２３１のような複数のエージェントオブジ ェクトも示している。この例では、エージェントオブジェクト２３０は、図２に おいて破線２３５として示されている、先に言及したエージェント位置追跡ルー チンを使用してエージェント場所オブジェクト２２７にダイナミックにリンクさ れている。同様に、エージェントオブジェクト２３１は、（図２において破線２ ３６として示されている）先に言及したエージェント位置追跡ルーチンを使用し てエージェント場所オブジェクト２２８にダイナミックにリンクされている。 エージェントオブジェクトの中には、エージェントグループオブジェクトにグ ループ化することができるものもある。図２では、１つのエージェントグループ オブジェクト２３３のみが示されている。 スタットサーバ１４０は、そのクライアントに対する１組のＡＰＩを提供して 、エージェント、エージェントグループ、エージェント場所、場所グループ、ル ートポイント、キューなどと関係するオブジェクトのような、さまざまなオブジ ェクトに対する統計を得る。統計は、現在のオブジェクト状態表示（例えば、現 在のエージェントステータス、グループ中の現在のアクティブ通話数など）や履 歴状態表示とすることができる。履歴表示はある時間間隔に対する累積情報（例 えば、通話の総数、総会話時間、平均会話時間など）である。したがって、クラ イアントは対象とする時間間隔を特定しなければならない。時間間隔の例は次の 通りである： （ａ）SGrowingWindow：開始時間が固定されている（例えば、午前９：００） 一方で終了時間がスライドする（例えば、“今まで”）。例えば、クライアント は午前９：００から今までの間の総通話数を要求してもよい。 （ｂ）SShdingWindow：時間間隔が固定されている一方、開始時間および終了 時間がスライドする。例えば、過去１時間の平均通話長。 オブジェクトの説明に戻ると、各オブジェクトは１つ以上の状態を持っている 。本発明の１つの実施形態では、エージェントＤＮオブジェクトはテーブル１に 示されている状態を持っていてもよい。状態の数や性質は実施における詳細設計 事項であるので、当業者により容易に変更させることができることに留意すべき である。 テーブル１ （１）NotMonitored： ＣＴＩサーバはこのエージェントＤ Ｎのステータスを現在追跡していない。結果的に、スタットサーバはこのＤＮに 対する統計情報を累積していない。 （２）Monitored： エージェントＤＮがＣＴＩサーバに より監視されている。 （３）LoggedIn： これはエージェントがエージェント ＤＮにログインしていることを示している。 （４）OnHook： これはエージェントＤＮがオンフッ ク状態であり、通話を待っていることを示している。 （５）WaitForNextCall： このエージェントＤＮがアクティブ 通話を受けているときや、（ボイスメールメッセージを残す可能性のために）エ ージェントがいないときでさえ、これはほとんど常にアクティブである。 WaitForNextCallがアクティブでない唯一の状況は、予め定められたキーが押下 されているときである（以下のNotReadyForNextCall参照）。 （６）OffHook： これは電話の受話器がオフフック状 態であることを示している。しかしながら、受話器がオフフック状態のときでさ え（例えば、WaitForNextCall）、他の状態はアクティブの場合がある。 （７）CallDiahng： これはエージェントが通話のために ダイヤルしたが、その通話はまだ確立されていないことを示している。 （８）CallRinging： 入通話が呼出を始める瞬間からエー ジェントによりその通話を取扱う直前までにエージェントＤＮに生じているアク ションに関係している。 （９）NotReadyForNextCall： これは通話を受信するのを妨げるハ ードウェア状態に関係している。これは通常予め定められたキーを押下すること により起動される。 （１０）OfflineWorkTypel： これはタイプ１として分類できる業 務に対してエージェントがオフライン中であることを示している。 （１１）OfflineWorkType2： これはタイプ２として分類できる業 務に対しでエージェントがオフライン中であることを示している。 （１２）CallOnHoldUnknown： これは未知のタイプの通話が保留中 であることを示している。 （１３）CallOnHoldConsult： これは相談通話が保留中であること を示している。 （１４）CallOnHoldInternal： これは内部通話が保留中であること を示している。 （１５）CallOnHoldOutbound： これは出通話が保留中であることを 示している。 （１６）CallOnHoldInbound： これは入通話が保留中であることを 示している。 （１７）CallUnknown： これは通話が相談通話、内部通話、 出通話、入通話、または保留中通話であるかをＣＴＩサーバが決定できないこと を示している。 （１８）CallConsult： これは相談通話が進行中であること を示している。 （１９）CallInternal： これは２つの内線（内部通話）間の 通話が進行中（すなわち、プリフィックスが使用されていないとき）であること を示している。 （２０）CallOutbound： これは出通話が進行中であることを 示している。 （２１）CallInbound： これは入通話が進行中であることを 示している。 （２２）LoggedOut： これはエージェントがエージェント ＤＮからログアウトしたことを示している。 （２３）CallDialed： これは電話がダイヤルされたときに 成功したことを示している。 （２４）CallAbandonedFromDialing： これはダイヤルプロセス中（かつ他 の当事者が応答前）にエージェントが電話を切ったことを示している。 （２５）CallAnswered： これは通話に応答があったことを示 している。 （２６）CallAbandonedFromRinging： これは電話が鳴っている間に他の当 事者が電話を切ったことを示している。 （２７）CallAbandonedFromHolding： これは通話が保留中に他の当事者が 電話を切ったことを示している。 上記にリストアップされている状態は、エージェントＤＮにより“実行”する ことができるアクションに対応している。先に言及したように、エージェントＤ Ｎは同時に複数のこれらの状態（ここでは“アクティブ状態”と呼ぶ）をとるこ とができる。本発明の１つの実施形態では、本発明のスタットサーバは最高の優 先順位を持つアクティブ状態に等しいエージェントＤＮステータスをそのクライ アントに対して報告する。本発明では、優先順位はスタットサーバのクライアン トにより設定される。これは、エージェントＤＮのステータスの情報を要求する 際に、クライアントがステータス優先順位テーブル（“ＳＰＴ”）をパラメータ の一部としてスタットサーバに送ることによりなされる。このテーブルにはテー ブル１のリストに示されているのと同じ状態が含まれているので、これらの状態 はクライアントにより規定される優先順位で配置される。クライアントに報告す る際に、スタットサーバは、受信したＳＰＴで規定されている最高の優先順位を 持つエージェントＤＮのアクティブ状態に対応するステータスを報告する。報告 されるステータスは、ＳＰＴ上の他の優先順位に対応するアクティブ状態とする ことができることに留意すべきである。情報を要求しているクライアントがＳＰ Ｔを提供しない場合には、デフォルトＳＰＴが使用される。さらに、クライアン トは情報に対する別の要求時に異なるＳＰＴを提供してもよい。 本発明のこの観点の１つの利点は、最適であると思われる情報を各クライアン トが得ることができることである。従来技術のシステムでは、情報を要求するす べてのクライアントに対して、スタットサーバはエージェントＤＮに対する１つ のステータスのみを報告する。本発明では、スタットサーバは、クライアントに より送信されたＳＰＴパラメータに基づいて、同じエージェントＤＮに対する異 なるステータスを異なるクライアントに対して報告することができる。各クライ アントは欲しい情報を受信することから、コールセンターのリソースをさらによ く使用することができる。 先に指摘したように、各エージェントは２台以上の電話機（すなわち、エージ ェントＤＮ）にアクセスしてもよい。このケースでは、クライアントは両エージ ェントＤＮにおけるアクションの優先順位を示すエージェントＳＰＴを規定して もよい。 例として、エージェントが２つのエージェントＤＮに対するアクセスを持ち、 第１のＤＮが“OfflineWorkType1”の状態を持ち、第２のＤＮが“WaitForNextC all”の状態を持つことを仮定する。クライアントに対して報告されるエージェ ントのステータスは、これがより高い優先順位を持つ場合には“OfflineWorkTyp e1”である。他の例として、スタットサーバのクライアント（例えば、ルーティ ングサーバ１４２）は、エージェントと関係するすべてのエージェントＤＮが“ WaitForNextCall”状態を持っているときには、エージェントのステータスを“W aitForNextCall”であると考えてもよい。これはエージェントが任意のコールセ ンター関連アクティビィティ（例えば、通話に応答するまたはワークステーショ ンを使用する）をアクティブに実行していない場合のケースに相当し、結果とし て、すべてのエージェントＤＮが使用されておらず、通話を待っている。この優 先順位の構成は“WaitForNextCall”を最低の優先順位を持つアクションとして エージェントＳＰＴに入れることにより達成される。しかしながら、特別な通話 あるいは緊急な通話がある場合には、ルーティングサーバ１４２は、“WaitForN extCall”ステータスを持つエージェントに関係する少なくとも１つのエージェ ントＤＮがあれば、エージェントのステータスを“WaitForNextCall”であると 考えたいかもしれない。これは、使用されていない少なくとも１台の電話機にエ ージェントがアクセスを持つケースに対応する。 この優先順位設定は“WaitForNextCall”を最高の優先順位としてエージェント ＳＰＴに入れることにより達成される。 エージェントＳＰＴの１つの実施形態では、状態の優先順位は連続的かつコン マで区切られてリストアップされており、最低の優先順位が最初にリストアップ される。“WaitForNextCan”に対して最低の優先順位を持つエージェントＳＰＴ は、“WaitForNextCall，．．．．（他の状態）”となる。一方、“WaitForNext Call”に対して非常に高い優先順位を持つエージェントＳＰＴは、“．．．．， WaitForNextCall，Logged Out”となる。このケースでは、最高の優先順位は“L ogged Out”であり、ちようどその下の優先順位が“WaitForNextCall”である。 エージェントはグループに構成することができる。グループステータスは、含 まれているすべてのエージェントステータスに基づく。どれがエージェントＳＰ ＴとＤＮ ＳＰＮに類似しているかは“グループＳＰＴ”により決定される。例 として、“．．．．，WaitForNextCa1l”のグループＳＰＴは、少なくとも１つ の“WaitForNextCall”エージェントステータスがあれば、グループが“WaitFor NextCall”に入ることを意味している。 ルーティングポイントとキューは異なるＳＰＴに応答して異なるステータスを 異なるクライアントに送ることもできる。例示的なルーティングポイント／キュ ーの状態をテーブル２に示す。 テーブル２ （１）NotMonitored： ＣＴＩサーバはこのＤＮのステータ スを現在追跡していない。結果的に、スタットサーバはこのＤＮに対する統計情 報を累積していない。 （２）Monitored： ルーティングポイント／キューがＣ ＴＩサーバにより監視されている。 （３）NotReadyForNextCall： ルーティングまたはキューＤＮに対 して使用されるＰＢＸソースが容量に達した時にこの状態が生じる。この容量は 非常に大きく、通常は達しないことに留意すべきである。 （４）CallWait： 通話がルーティングポイント／キュ ーで保留されている。 （５）CallEntered： これは新しい通話がルーティングポ イントまたはキューにちょうど入ってきたことを示す“瞬問的な”アクションで ある。 （６）CallDistributed： これは前にルーティングポイント／ キューにあった通話がちようどエージェントに送られたことを示している。 （７）CallAbandoned： これは通話がルーティングポイント またはキューにある間にカスタマがちようど電話を切ったことを示している。 （８）WaitForNextCall： これは、ルーティングポイント／キ ューにさらに多くの通話を取扱う容量がまだあることを示している。 本発明の１つの実施形態では、クライアントがスタットサーバから統計を得る ことができるようにする２つのメイン論理コールがある。第１のコールは“SGet Stat”である。このコールはスタットサーバに対して対象とする統計を一度だけ 返すように要求する。第２のコールは“SOpenStat”である。これはクライアン トが連続ベースで統計を受信することに興味を持っていることを意味している。 クライアントはさらに、スタットサーバがクライアントに通知し、統計を報告す るために、さまざまな基準をセットアップすることができる。例えば、クライア ントは、新しい値が最後に報告された値よりも予め定められたパーセンテージだ け大きいときにのみ通知が行われるように指定することができる。代わりに、ク ライアントは予め定められた時間間隔で通知が行われるように指定することがで きる。 SgetStatコールとSopenStatコールのパラメータの１つはＳＰＴに関係してい る。本発明の１つの実施形態では、これらの各コールに対するパラメータには多 数のオプションフィールドを持つデータ構造へのポインタが含まれている。エー ジェントＤＮ、エージェント、グループおよびルーティングポイント／キューに 対するＳＰＴは、それぞれこれらのオプションフィールドの１つを占有する。し たがって、アプリケーションは適切なＳＰＴを規定して、それらをデータ構造に 組み込むことができる。このデータ構造を使用してsgetstatコールとSopenStat コールを呼び出す。 複数のスイッチが同じスタットサーバにより監視されている実施形態では、先 に言及したコールには、クライアントが対象とするスイッチを示すことができる パラメータも含まれる。 本発明はその特定の例示的な実施形態を参照して説明してきた。本発明の広い 精神および範囲を逸脱することなく、さまざまな修正および変更を本発明に対し て行ってもよい。したがって明細書および図面は、制限的な意味ではなく例示的 ものとして考えるべきであり、本発明は提供される請求の範囲によってのみ制限 される。

【手続補正書】特許法第１８４条の８第１項 【提出日】平成１０年８月７日（１９９８．８．７） 【補正内容】 請求の範囲 １．コールセンターの物理的な環境中のエンティティのステータスを報告する方 法において、 （ａ）報告アプリケーションにより、複数の可能性あるオブジェクト状態を持 つエンティティのアクティブ状態を監視し、 （ｂ）要求アプリケーションにより、可能性あるオブジェクト状態の優先順位 付リストと、少なくとも１つのアクティブ状態に対する要求を提供し、 （ｃ）報告アプリケーションにより、アクティブ状態でありかつ要求アプリケ ーションにより提供されたリスト中で最高の優先順位を持つエンティティ状態を 要求アプリケーションに提供するステップを含む方法。 ２．ステップ（ｂ）において、要求アプリケーションが１つよりも多い状態を要 求し、ステップ（ｃ）において、報告アプリケーションが最高の優先順位を持つ アクティブ状態と最高の優先順位以外の優先順位を持つアクティブ状態を提供す る請求項１記載の方法。 ３．報告アプリケーションにより要求アプリケーションに提供される状態は優先 順位の順序で最高の優先順位を持つ状態である請求項２記載の方法。 ４．報告される状態の少なくとも１つがデフォルト状態に対応している請求項２ 記載の方法。 ５．コールセンターが複数のエージェントディレクトリ番号を使用する自動通話 分配装置（ＡＣＤ）を備え、エンティティがエージェントディレクトリ番号の１ つである請求項１記載の方法。 ６．エンティティが１台以上の電話機に対するアクセスを持つエージェントであ り、各電話機が複数のエージェントディレクトリ番号の１つによりアドレスされ ている請求項１記載の方法。 ７．エージェントが少なくとも第１および第２の電話機に対するアクセスを持ち 、第１の電話機が第１のアクティブ状態であり、第２の電話機が第２のアクティ ブ状態であり、報告アプリケーションが要求アプリケーションに対して、エージ ェントステータスとして第１および第２のアクティブ状態の１つを提供する請求 項６記載の方法。 ８．コールセンターが少なくとも１つの内部ルーティングポイントを有する自動 通話分配装置を備え、エンティティが少なくとも１つのルーティングポイントで ある請求項１記載の方法。 ９．コールセンターが少なくとも１つのキューを有する自動通話分配装置を備え 、エンティティが少なくとも１つのキューである請求項１記載の方法。 １０．エンティティが複数の可能性ある状態のうちの１つ以上のアクティブ状態 にあってもよく、可能性ある状態はそれぞれコールセンター中のエンティティの 動作に関係しており、コールセンターの物理的な環境中のエンティティのステー タスを報告する方法において、 （ａ）エンティティのアクティブ状態を監視し、 （ｂ）要求アプリケーションにより、報告アプリケーションに対して、可能性 あるエンティティ状態の第１の優先順位付リストを第１の時間に提供し、 （ｃ）報告アプリケーションにより、要求アプリケーションに対して、アクテ ィブ状態でありかつ第１の優先順位付リスト中で最高の優先順位を持つエンティ ティの第１のステータスを提供し、 （ｄ）報告アプリケーションにより、要求アプリケーションに対して、可能性 あるエンティティ状態の第２の優先順位付リストを第２の時間に提供し、 （ｅ）報告アプリケーションにより、要求アプリケーションに対して、第２の 優先順位リストとエンティティのアクティブ状態とに基づいてエンティティの第 ２のステータスを提供するステップを含み、 第２のステータスが第１のステータス以外のステータスである方法。 １１．第１のステータスが第１の優先順位リスト中で最高の優先順位を持つアク ティブ状態の１つに対応し、第２のステータスが第２の優先順位リスト中で最高 の優先順位を持つアクティブ状態の１つに対応している請求項１０記載の方法。 １２．第１および第２のステータスが第１および第２のリスト中で予め定められ た優先順位を持つアクティブ状態に対応している請求項１０記載の方法。

Claims (1)

1. 【特許請求の範囲】 １．エンティティが複数の可能性ある状態のうちの１つ以上のアクティブ状態に 現在あり、可能性ある状態はそれぞれコールセンター中のエンティティの動作に 関係しており、第１のソフトウェアアプリケーションがコールセンター中のエン ティティのステータスを第２のソフトウェアアプリケーションと第３のソフトウ ェアアプリケーションに報告する方法において、 第２のソフトウェアアプリケーションにより、第１のソフトウェアアプリケー ションに対して、可能性ある状態の優先順位の第１のランキングを提供し、 第１のソフトウェアアプリケーションにより、第２のソフトウェアアプリケー ションに対して、第１の優先順位ランキングとエンティティのアクティブ状態に 基づいて、エンティティの第１のステータスを報告し、 第３のソフトウェアアプリケーションにより、第１のソフトウェアアプリケー ションに対して、可能性ある状態の優先順位の第２のランキングを提供し、 第１のソフトウェアアプリケーションにより、第３のソフトウェアアプリケー ションに対して、第２の優先順位ランキングとエンティティのアクティブ状態に 基づいて、エンティティの第２のステータスを報告するステップを含み、 第１のステータスが第２のステータスと異なっていてもよい方法。 ２．第１のステータスが第１のランキング中で最高の優先順位を持つアクティブ 状態の１つに対応し、第２のステータスが第２のランキング中で最高の優先順位 を持つアクティブ状態の１つに対応している請求項１記載の方法。 ３．第１および第２のステータスが第１および第２のランキング中で予め定めら れた優先順位を持つアクティブ状態に対応している請求項１記載の方法。 ４．第１および第２のランキングの少なくとも１つがデフォルトランキングに対 応している請求項１記載の方法。 ５．コールセンターが複数のエージェントディレクトリ番号を含む自動通話分配 装置を備え、エンティティがエージェントディレクトリ番号の１つである請求項 １記載の方法。 ６．エンティティが１台以上の電話機に対するアクセスを持つエージェントであ り、各電話機が複数のエージェントディレクトリ番号の１つに接続されている請 求項５記載の方法。 ７．エージェントが少なくとも第１および第２の電話機に対するアクセスを持ち 、第１の電話機は第１のアクティブ状態にあり、第２の電話機は第２のアクティ ブ状態にあり、エージェントはステータスを持ち、第１のソフトウェアアプリケ ーションにより第２のソフトウェアアプリケーションに報告するステップは、第 １および第２のアクティブ状態の１つをエージェントステータスとして報告する ステップを含む請求項６記載の方法。 ８．コールセンターが少なくとも１つのルーティングポイントを含む自動通話分 配装置を備え、エンティティが少なくとも１つのルーティングポイントである請 求項１記載の方法。 ９．コールセンターが少なくとも１つのキューを含む自動通話分配装置を備え、 エンティティが少なくとも１つのキューである請求項１記載の方法。 １０．エンティティが複数の可能性ある状態のうちの１つ以上のアクティブ状態 にあってもよく、可能性ある状態はそれぞれコールセンター中のエンティティの 動作に関係しており、第１のソフトウェアアプリケーションがコールセンター中 のエンティティのステータスを第２のソフトウェアアプリケーションに報告する 方法において、 第２のソフトウェアアプリケーションにより、第１のソフトウェアアプリケー ションに対して、可能性ある状態の優先順位の第１のランキングを第１の時間に 提供し、 第１のソフトウェアアプリケーションにより、第２のソフトウェアアプリケー ションに対して、第１の優先順位ランキングとエンティティのアクティブ状態に 基づいて、エンティティの第１のステータスを報告し、 第２のソフトウェアアプリケーションにより、第１のソフトウェアアプリケー ションに対して、可能性ある状態の優先順位の第２のランキングを第２の時間に 提供し、 第１のソフトウェアアプリケーションにより、第２のソフトウェアアプリケー ションに対して、第２の優先順位ランキングとエンティティのアクティブ状態に 基づいて、エンティティの第２のステータスを報告するステップを含み、 第１のステータスが第２のステータスと異なっていてもよい方法。 １１．第１のステータスが第１のランキング中で最高の優先順位を持つアクティ ブ状態の１つに対応し、第２のステータスが第２のランキング中で最高の優先順 位を持つアクティブ状態の１つに対応している請求項１０記載の方法。 １２．第１および第２のステータスが第１および第２のランキング中で予め定め られた優先順位を持つアクティブ状態に対応している請求項１０記載の方法。