(57)【要約】複数の通信を処理するように構成された分散型通信センター（２３４）は、ユーザゾーン（２０４）とウェブゾーン（２０２）とネットワークゾーン（２００）とを含む。ユーザゾーン（２０４）は、通信センターの人員（２３６）及びエンドユーザらが、ウェブゾーン（２０２）を介して分散型通信センター（２３４）と遠隔でインターフェースをとることができるようにする複数の遠隔の端末（２３２）を含む。ウェブゾーン（２０２）は、設定済みの１つ又は複数のウェブサーバ（２１６）と、１つ又は複数のメールサーバ（２１８）とを含み、ユーザゾーン（２０４）内の遠隔の端末（２３２）とネットワークゾーン（２００）とのインターフェースをとる。ネットワークゾーン（２００）は、１つ又は複数の電話サーバ（２１２）と、１つ又は複数のアプリケーションサーバ（２０６）とを含む。
2005530372.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサーバを備えた通信センターであって、上記ウェブサーバは、遠隔の端末とネットワークゾーンとの間で情報を送受信するように構成された複数のアプリケーションを備えた通信センター。
【請求項２】
上記複数のアプリケーションは、上記遠隔の端末を用いて通信センターのリソースに遠隔からアクセスする試みを認証するように構成されたユーザセッションマネージャを含む請求項１記載の通信センター。
【請求項３】
遠隔からアクセスする試みを認証することは、遠隔のログインメッセージを受信して、上記受信された遠隔のログインメッセージに応答してユーザセッションを開始することを含む請求項２記載の通信センター。
【請求項４】
遠隔からアクセスする試みを認証することは、上記受信された遠隔のログインメッセージからログイン情報を抽出し、上記抽出されたログイン情報を格納することをさらに含む請求項３記載の通信センター。
【請求項５】
遠隔からアクセスする試みを認証することは、上記開始されたユーザセッションに関連した情報を追跡することをさらに含む請求項４記載の通信センター。
【請求項６】
上記ユーザセッションマネージャはさらに、ログアウトメッセージを受信し、上記受信されたログアウトメッセージに応答して、上記開始されたユーザセッションを終了させるように構成された請求項３記載の通信センター。
【請求項７】
上記複数のアプリケーションは、上記遠隔の端末に関連した状態情報を上記ネットワークゾーンに中継するように構成されたリアルタイムのユーザ状態送信アプリケーションを含む請求項１記載の通信センター。
【請求項８】
状態情報を中継することは、上記遠隔の端末から動作要求を受信することと、上記動作要求を上記ネットワークゾーンへ転送することとを含む請求項７記載の通信センター。
【請求項９】
上記リアルタイムのユーザ状態送信アプリケーションはさらに、上記受信された動作要求から動作要求情報を抽出し、上記抽出された情報をキューに格納するように構成された請求項８記載の通信センター。
【請求項１０】
上記動作要求を転送することは、上記キューから上記動作要求情報を抽出することと、これを上記ネットワークゾーンへ転送することとを含む請求項９記載の通信センター。
【請求項１１】
上記複数のアプリケーションは、上記ネットワークゾーンに関連した状態情報を上記遠隔の端末へ中継するように構成されたリアルタイムのユーザ状態受信アプリケーションを含む請求項１記載の通信センター。
【請求項１２】
状態情報を中継することは、上記遠隔の端末からの動作要求に応答して生成された上記ネットワークゾーンからのメッセージを受信することと、上記受信されたメッセージを上記遠隔の端末へ送信することとを含む請求項１１記載の通信センター。
【請求項１３】
上記リアルタイムのユーザ状態受信アプリケーションはさらに、上記遠隔の端末から照会を受信し、上記受信された照会に応答して、上記受信されたメッセージを上記遠隔の端末へ送信するように構成された請求項１２記載の通信センター。
【請求項１４】
上記リアルタイムのユーザ状態受信アプリケーションはさらに、
上記遠隔の端末から上記照会を受信し、
上記受信された照会に応答して、上記遠隔の端末へ送信されるべき任意のメッセージが存在するか否かを決定し、
送信されるべきメッセージが存在しないとき、上記遠隔の端末へ送信されるべき任意のメッセージを上記ネットワークゾーンから受信することを、設定可能な時間期間にわたって待機し、
任意の受信されたメッセージが受信されたとき、当該受信されたメッセージを送信するように構成された請求項１３記載の通信センター。
【請求項１５】
上記複数のアプリケーションは、上記遠隔の端末と上記ネットワークゾーンとの間で非リアルタイム通信の状態を中継するように構成された非リアルタイムのシステム状態送信／受信アプリケーションを含む請求項１記載の通信センター。
【請求項１６】
上記複数のアプリケーションは、上記遠隔の端末とデータベースとのインターフェースをとるように構成されたデータベースインターフェースアプリケーションを含む請求項１記載の通信センター。
【請求項１７】
上記複数のアプリケーションは、上記遠隔の端末とファイルサーバとのインターフェースをとるように構成されたＦＴＰインターフェースアプリケーションを含む請求項１記載の通信センター。
【請求項１８】
上記複数のアプリケーションは、上記遠隔の端末からのデータベース及びファイル要求とを処理するように構成された遠隔のデータベース／ファイルハンドラアプリケーションを含む請求項１記載の通信センター。
【請求項１９】
上記複数のアプリケーションは、上記ウェブサーバと上記ネットワークゾーンとの間の通信を管理するように構成されたバスサーバアプリケーションを含む請求項１記載の通信センター。
【請求項２０】
遠隔の端末を備えた通信センターであって、
上記遠隔の端末は、ウェブゾーンにアクセスして通信センターの状態情報を受信し、上記ウェブゾーン又はネットワークゾーンを介して上記遠隔の端末にルーティングされた着信する通信を処理するように構成された通信センター。
【請求項２１】
上記遠隔の端末はさらに、ブラウザアプリケーションを用いて上記ウェブゾーンにアクセスするように構成された請求項２０記載の通信センター。
【請求項２２】
上記遠隔の端末はさらに、複数のカスタマイズされたアプリケーションの１つを用いて上記ウェブゾーンにアクセスするように構成された請求項２１記載の通信センター。
【請求項２３】
上記複数のカスタマイズされたアプリケーションは、上記遠隔の端末へルーティングされた着信する通信に当該遠隔の端末が応答することを可能にするように構成された対話マネージャアプリケーションを含む請求項２２記載の通信センター。
【請求項２４】
上記複数のカスタマイズされたアプリケーションは、上記遠隔の端末又は他の遠隔の端末へルーティングされた着信する通信に当該遠隔の端末が応答することを可能にするように構成され、かつ他の遠隔の端末へルーティングされた着信する通信の処理を監督するように構成された監督マネージャアプリケーションを含む請求項２２記載の通信センター。
【請求項２５】
上記複数のカスタマイズされたアプリケーションは、着信する通信がどのようにルーティングされまた処理されるかということに関連して、上記ウェブゾーンと上記ネットワークゾーンと他の遠隔の端末とを上記遠隔の端末が構成することを可能にするように構成された管理マネージャを含む請求項２２記載の通信センター。
【請求項２６】
上記複数のカスタマイズされたアプリケーションはチャットマネージャを含む請求項２２記載の通信センター。
【請求項２７】
上記遠隔の端末はさらに、ブラウザを用いて上記ウェブゾーンにアクセスし、上記ブラウザを用いて、上記複数のカスタマイズされたアプリケーションのうちの１つ又は複数をダウンロードするように構成された請求項２２記載の通信センター。
【請求項２８】
着信する通信を受信するように構成されたウェブゾーンと、
着信する通信を受信し、上記ウェブゾーン及びネットワークゾーンによって受信された着信する通信がどのようにルーティングされるかを制御するように構成されたネットワークゾーンとを備えた通信センター。
【請求項２９】
上記ネットワークゾーンは、上記ウェブゾーン及びネットワークゾーンによって受信された着信する通信がどのようにルーティングされるかということを含む上記ネットワークゾーンの動作を制御するように構成された、複数のアプリケーションを備えた請求項２９記載の通信センター。
【請求項３０】
上記複数のアプリケーションは、上記ネットワークゾーンと、上記ウェブゾーンとインターフェースをとっている遠隔の端末との間の通信を維持するように構成されたインターネットハンドラアプリケーションを含む請求項２９記載の通信センター。
【請求項３１】
上記複数のアプリケーションは、着信するさまざまな通信のタイプのためのルーティング規則を保持するように構成された自動着信呼分配器アプリケーションを含む請求項２９記載の通信センター。
【請求項３２】
上記ネットワークゾーンは、着信する通信を受信するように構成された電話リソースを備え、
上記複数のアプリケーションは、上記電話リソースと上記複数のアプリケーションのうちの少なくともいくつかとの間の通信を維持するように構成され、かつ上記ネットワークゾーンによって受信された着信する通信のルーティングに関連した所定の態様を決定するように構成されたコンピュータインテグレータアプリケーションを含む請求項２９記載の通信センター。
【請求項３３】
上記複数のアプリケーションは、着信するチャット通信の処理に関連した上記複数のアプリケーションのうちのいくつかの間におけるインターフェースを制御するように構成されたチャットハンドラアプリケーションを含む請求項２９記載の通信センター。
【請求項３４】
上記複数のアプリケーションは、着信する電子メール通信の処理に関連した態様を制御するように構成された電子メール分配器アプリケーションを含む請求項２９記載の通信センター。
【請求項３５】
上記ネットワークゾーンはさらにデータベースを備え、
上記複数のアプリケーションは、上記ウェブゾーン及び上記ネットワークゾーンによって受信された着信する通信の処理に関連した情報を上記データベースに格納するように構成された統計値追跡器アプリケーションを含む請求項２９記載の通信センター。
【請求項３６】
上記複数のアプリケーションは、上記複数のアプリケーションのうちの少なくともいくつかに、任意のルーティング規則に係るスケジューリングされた変更について通知するように構成されたシステムスケジューラアプリケーションを含む請求項２９記載の通信センター。
【請求項３７】
上記ネットワークゾーンはさらにアウトバウンド通信を発信するように構成され、
上記複数のアプリケーションは、アウトバウンド通信を発生させるように構成された予測型発呼者アプリケーションを含む請求項２９記載の通信センター。
【請求項３８】
上記複数のアプリケーションは、上記ウェブゾーン及び上記ネットワークゾーンによって受信された着信する通信の処理に関連した情報を格納するために使用されるデータ構造を生成するように構成され、かつ着信する電子メール通信及びチャット通信のためのユーザセッションを生成するように構成されたホストマネージャを含む請求項２９記載の通信センター。
【請求項４０】
上記ネットワークゾーンはさらに、上記着信する通信を受信するように構成された電話ハードウェアを備え、
上記複数のアプリケーションは、上記電話ハードウェアを制御するように構成された呼ハンドラアプリケーションを含む請求項２９記載の通信センター。
【請求項４１】
上記ネットワークゾーンはさらに複数の電話サーバを備え、
上記複数のアプリケーションは、上記ネットワークゾーンによって受信された着信する通信の、上記複数の電話サーバにわたるルーティングを制御するように構成された呼ブリッジアプリケーションを含む請求項２９記載の通信センター。
【請求項４２】
上記複数のアプリケーションは統合メッセンジャアプリケーションを含む請求項２９記載の通信センター。
【請求項４３】
上記複数のアプリケーションは、簡易ネットワーク管理プロトコルが、通信センターの警告及び性能に係る遠隔のモニタリングと、通信センターのリソースの遠隔制御とに適合することを可能にするように構成された簡易ネットワークマネージャアプリケーションを含む請求項２９記載の通信センター。
【請求項４４】
上記複数のアプリケーションは、上記通信センターに課される使用制限を追跡し、すべての通信センターのリソースの状態を追跡するように構成されたライセンスマネージャアプリケーションを含む請求項２９記載の通信センター。
【請求項４５】
上記ネットワークゾーンはさらに複数のライセンスサーバを備え、
各ライセンスサーバは、他のライセンスマネージャアプリケーションとインターフェースをとって使用制限を追跡するように構成され、かつ他のライセンスマネージャの１つが故障すると上記他のライセンスマネージャの１つから引き継ぎを行うように構成されたライセンスマネージャアプリケーションを備えた請求項４４記載の通信センター。
【請求項４６】
上記通信センターは、複数の企業をホスティングするように構成され、
上記複数のアプリケーションのうちの少なくともいくつかは所定の企業に専用である請求項２９記載の通信センター。
【請求項４７】
複数の企業をホスティングするように構成された通信センターであって、上記通信センターはネットワークゾーンを備え、
上記ネットワークゾーンは、上記複数の企業の各々に関連付けられたデータが、上記ネットワークゾーンによって管理されることと、要求されたときに上記複数の企業のうちの他の企業に関連付けられたデータから隔離されることとを可能にするように構成された複数のデータベースを備えた通信センター。
【請求項４８】
上記複数のデータベースは、上記複数の企業の各々に対する企業データベースを含み、上記企業データベースは、関連付けられた企業に関する全情報を備えた請求項４７記載の通信センター。
【請求項４９】
上記複数のデータベースは、上記複数の企業の各々に対するユーザデータベースを含み、上記ユーザデータベースは、関連付けられた企業に関連付けられた全ユーザに関連した情報を備えた請求項４７記載の通信センター。
【請求項５０】
上記複数のデータベースは、上記複数の企業の各々に対する作業グループデータベースを含み、上記作業グループデータベースは、関連付けられた企業に対して着信する通信を処理するために上記関連付けられた企業によって確立された作業グループに関する情報を備えた請求項４７記載の通信センター。
【請求項５１】
上記複数のデータベースは、上記複数の企業の各々に対するプロジェクトデータベースを含み、上記プロジェクトデータベースは、すべての媒体の通信のルーティング方式を備えた請求項４７記載の通信センター。
【請求項５２】
上記複数のデータベースは、上記複数の企業の各々に対する対話追跡データベースを含み、上記対話追跡データベースは、関連付けられた企業に係るすべての通信イベントに関連した情報を備えた請求項４７記載の通信センター。
【請求項５３】
上記複数のデータベースは、上記複数の企業の各々に対するコンタクトデータベースを含み、上記コンタクトデータベースは、関連付けられた企業に係るすべてのコンタクト情報を備えた請求項４７記載の通信センター。
【請求項５４】
上記複数のデータベースは、上記複数の企業の各々に対する履歴データベースを含み、上記履歴データベースは、任意の顧客が関連付けられた企業との間で行った、すべての通信に関連した情報を備えた請求項４７記載の通信センター。
【請求項５５】
上記複数のデータベースは、通信センターの全品質管理記録を備えた品質管理データベースを含む請求項４７記載の通信センター。
【請求項５６】
上記複数のデータベースのうちの少なくともいくつかは遠隔に構成される請求項４７記載の通信センター。
【請求項５７】
通信ネットワークと、
複数のホストとを備えた通信システムであって、
上記複数のホストの各々は少なくとも１つのアプリケーションを実行するように構成され、上記複数のホストの各々は、上記通信ネットワークと通信可能であるように接続されたバスサーバアプリケーションを備え、
各バスサーバアプリケーションは、関連付けられたホスト上で実行されるアプリケーションが、他のホスト上で実行されるアプリケーションと通信することを、上記アプリケーションからメッセージを受信して上記メッセージを上記通信ネットワークを介してブロードキャストすることによって可能にするように構成された通信システム。
【請求項５８】
各バスサーバアプリケーションはさらに、
他のバスサーバアプリケーションによってブロードキャストされたメッセージを受信し、
受信されたメッセージが、関連付けられたホスト上に存在するアプリケーションに向かうように意図されたものであるか否かを決定し、
受信されたメッセージが常駐アプリケーションに向かうように意図されたものであると決定されたとき、上記メッセージを、意図されたアプリケーションへ送信するように構成された請求項５７記載の通信システム。
【請求項５９】
上記各バスサーバアプリケーションは、ＴＣＰ／ＩＰを用いて、上記通信ネットワークを介して通信するように構成された請求項５７記載の通信システム。
【請求項６０】
上記複数のホストの各々の上で実行される各アプリケーションは、上記複数のホストのうちの他のホスト上で実行されるアプリケーションの少なくともいくつかとは直接に通信することができない請求項５７記載の通信システム。
【請求項６１】
各バスサーバアプリケーションはさらに上記通信システムに対して登録を行うように構成された請求項５７記載の通信システム。
【請求項６２】
上記通信システムにおける各ホストは関連付けられたホストアドレスを有し、
各バスサーバアプリケーションは、上記通信システムにおける非ホストアドレスに接続して上記非ホストアドレスへ識別情報を送信することによって、登録を行うように構成された請求項６１記載の通信システム。
【請求項６３】
上記識別情報は、バスサーバ名とホスト名とホストアドレスとのうちの少なくとも１つを備えた請求項６２記載の通信システム。
【請求項６４】
各バスサーバアプリケーションはさらに、上記非ホストアドレスから、他のバスサーバアプリケーションの識別情報を受信するように構成された請求項６２記載の通信システム。
【請求項６５】
各バスサーバアプリケーションはさらに、受信されている識別情報に対する上記他のバスサーバアプリケーションのうちの１つ又は複数との通信を確立するように構成された請求項６４記載の通信システム。
【請求項６６】
登録された各バスサーバアプリケーションに関連した情報を上記通信システムに格納するように構成されたシステムデータベースをさらに備えた請求項６１記載の通信システム。
【請求項６７】
上記バスサーバアプリケーションの各々はさらに、登録されたすべてのバスサーバアプリケーションを上記システムデータベースにおいて探索し、上記システムデータベースに格納された情報を用いて上記登録されたバスサーバアプリケーションのうちの１つ又は複数との通信を確立するように構成された請求項６６記載の通信システム。
【請求項６８】
上記バスサーバアプリケーションのいくつかはマスタのバスサーバアプリケーションであるように構成され、上記バスサーバアプリケーションのいくつかはバックアップのバスサーバアプリケーションであるように構成された請求項５７記載の通信システム。
【請求項６９】
どのバスサーバアプリケーションがマスタのアプリケーションであるか、またどのバスサーバアプリケーションがバックアップのバスサーバアプリケーションであるかを指定するように構成されたライセンスマネージャアプリケーションをさらに備えた請求項６８記載の通信システム。
【請求項７０】
上記ライセンスマネージャアプリケーションはさらに、マスタのバスサーバアプリケーションの故障を検出し、バックアップのバスサーバアプリケーションに、上記マスタのバスサーバアプリケーションからの引き継ぎの実行を命令するように構成された請求項６９記載の通信システム。
【請求項７１】
通信を処理するための方法であって、
複数のユーザアプリケーションのうちの１つを用いてユーザ端末から通信センターのサーバにアクセスすることと、
上記通信センターのサーバにアクセスするために上記複数のアプリケーションのうちのどれが使用されているかに依存して、上記通信センターのサーバから、複数の着信する通信のうちの少なくともいくつかに関連した所定の情報を上記ユーザ端末においてリアルタイムで受信することとを含む方法。
【請求項７２】
ブラウザアプリケーションを用いて上記ユーザ端末から上記通信センターのサーバにアクセスすることと、
上記ユーザ端末から上記ブラウザアプリケーションを介して上記通信センターのサーバへ識別情報を提供することと、
上記通信センターのサーバから、上記複数のユーザアプリケーションのうちの１つ又は複数をダウンロードすることとをさらに含み、上記ダウンロードされるユーザアプリケーションは、上記通信センターへ提供された上記識別情報に基づいて選択される請求項７１記載の方法。
【請求項７３】
上記ユーザ端末を、上記通信センターのサーバからダウンロードされた上記１つ又は複数のユーザアプリケーションを用いて上記通信センターのサーバにアクセスするように構成することをさらに含む請求項７２記載の方法。
【請求項７４】
上記ユーザ端末を構成することは、上記ブラウザアプリケーションを、上記複数のユーザアプリケーションのうちのどれが使用されているかに依存して所定の情報を表示するように構成することを含む請求項７３記載の方法。
【請求項７５】
上記複数のユーザアプリケーションのうちの１つを用いて上記通信センターを構成することをさらに含む請求項７１記載の方法。
【請求項７６】
上記通信センターを構成することは、上記通信センターによって実施される管理機能を構成することを含む請求項７５記載の方法。
【請求項７７】
上記通信センターを構成することは、上記複数の着信する通信に関連した呼処理機能を構成することを含む請求項７５記載の方法。
【請求項７８】
上記通信センターを構成することは、上記複数の着信する通信の処理に関連した監督機能を構成することを含む請求項７５記載の方法。
【請求項７９】
上記複数のユーザアプリケーションのうちの１つを用いて、上記複数の着信する通信のうちの１つを処理することをさらに含む請求項７１記載の方法。
【請求項８０】
上記複数のユーザアプリケーションのうちの１つを用いて、上記複数の着信する通信の処理を監督することをさらに含む請求項７１記載の方法。
【請求項８１】
上記複数のユーザアプリケーションのうちの１つを用いて、上記通信センターの管理機能を制御することをさらに含む請求項７１記載の方法。
【請求項８２】
上記ユーザ端末において、上記通信センターのサーバからユーザアプリケーションの更新版を自動的に受信することと、
上記受信されたアプリケーションの更新版に基づいて上記ユーザ端末を自動的に構成することとをさらに含む請求項７１記載の方法。
【請求項８３】
複数の着信する通信を管理するように構成された通信センターであって、
通信センターのサーバと、
複数のユーザアプリケーションのうちの少なくとも１つを備えた複数のユーザ端末とを備え、
上記複数のユーザ端末の各々は、上記複数のユーザアプリケーションのうちの１つを用いて上記通信センターのサーバにアクセスし、上記通信センターのサーバにアクセスするために上記複数のアプリケーションのうちのどれが使用されているかに依存して、上記通信センターのサーバから、上記複数の着信する通信のうちの少なくともいくつかに関連した所定の情報をリアルタイムで受信するように構成された通信センター。
【請求項８４】
上記複数のユーザ端末の各々は、情報にアクセスして表示するためのブラウザアプリケーションをさらに備え、上記複数のユーザ端末の各々はさらに、
上記ブラウザアプリケーションを用いて上記ユーザ端末から上記通信センターのサーバにアクセスし、
上記ユーザ端末から上記ブラウザアプリケーションを介して識別情報を提供し、
上記通信センターのサーバから上記複数のユーザアプリケーションのうちの１つ又は複数をダウンロードするように構成され、上記ダウンロードされるユーザアプリケーションは、上記通信センターのサーバへ提供される上記識別情報に基づいて選択される請求項８３記載の通信センター。
【請求項８５】
上記１つ又は複数のダウンロードされたユーザアプリケーションは、上記ユーザ端末が、上記通信センターのサーバからダウンロードされた上記１つ又は複数のユーザアプリケーションを用いて上記通信センターのサーバにアクセスすることを可能にする請求項８４記載の通信センター。
【請求項８６】
上記１つ又は複数のダウンロードされたユーザアプリケーションを用いて上記通信センターのサーバにアクセスすることは、上記ブラウザアプリケーションを、上記複数のユーザアプリケーションのうちのどれが使用されているかに依存して所定の情報を表示するように構成することを含む請求項８５記載の通信センター。
【請求項８７】
上記複数のユーザ端末の各々はさらに、上記複数のユーザアプリケーションのうちの１つを用いて上記通信センターを構成するように構成された請求項８３記載の通信センター。
【請求項８８】
上記複数のユーザ端末のうちのいくつかは、上記通信センターによって実施される管理機能を構成する能力を有する請求項８７記載の通信センター。
【請求項８９】
上記複数のユーザ端末のうちのいくつかは、上記複数の着信する通信及び複数の発信する通信に関連した呼処理機能を構成する能力を有する請求項８７記載の通信センター。
【請求項９０】
上記複数のユーザ端末のうちのいくつかは、上記複数の着信する通信の処理に関連した監督機能を構成する能力を有する請求項８７記載の通信センター。
【請求項９１】
上記複数のユーザ端末のうちのいくつかはさらに、上記複数のユーザアプリケーションのうちの１つを用いて、上記複数の着信する通信のうちの少なくともいくつかを処理するように構成された請求項８３記載の通信センター。
【請求項９２】
上記複数のユーザ端末のうちのいくつかはさらに、上記複数のユーザアプリケーションのうちの１つを用いて、上記複数の着信する通信の処理を監督するように構成された請求項８３記載の通信センター。
【請求項９３】
上記複数のユーザ端末のうちのいくつかはさらに、上記複数のユーザアプリケーションのうちの１つを用いて、上記通信センターの管理機能を制御するように構成された請求項８３記載の通信センター。
【請求項９４】
上記複数のユーザ端末の各々はさらに、
上記ユーザ端末において、上記通信センターのサーバからユーザアプリケーションの更新版を自動的に受信し、
上記受信されたアプリケーションの更新版に基づいて上記ユーザ端末を自動的に構成するように構成された請求項８３記載の通信センター。
【請求項９５】
上記複数のユーザ端末は、ウェブブラウザを用いて上記通信センターのサーバにアクセスするように構成された請求項８３記載の通信センター。
【請求項９６】
上記通信センターはさらにデータベースを備え、
上記複数の着信する通信に関連した情報の少なくとも一部は上記データベースに格納される請求項８３記載の通信センター。
【請求項９７】
上記複数のユーザ端末のうちのいくつかは、上記複数の着信する通信を処理するように構成され、
上記通信センターは、上記着信する通信の処理に関連した情報を上記データベースに格納するように構成された請求項９６記載の通信センター。
【請求項９８】
上記複数のユーザ端末のうちのいくつかはデータベースを備え、
上記着信する通信に関連した情報の少なくとも一部、上記着信する通信の処理に関連した情報、又はこれらの両方は、上記複数のユーザ端末のデータベースに格納される請求項９７記載の通信センター。
【請求項９９】
上記通信センターのサーバは、複数の顧客の各々に着信する通信と、上記複数の顧客の各々から発信する通信とを処理するように構成された請求項８３記載の通信センター。
【請求項１００】
上記通信センターは、上記複数の顧客の各々に対するデータベースを備え、上記通信センターは、上記顧客の各々に着信する通信に関連した情報を各々のデータベースに格納するように構成された請求項９９記載の通信センター。
【請求項１０１】
上記通信センターはさらに、着信する通信を受信し、上記通信を処理するために上記複数のユーザ端末のうちの１つを選択するように構成された請求項８３記載の通信センター。
【請求項１０２】
上記通信センターはさらに、上記受信された通信を、上記選択されたユーザ端末へルーティングするように構成された請求項１０１記載の通信センター。
【請求項１０３】
上記通信センターはさらに、上記選択されたユーザ端末との通信を確立し、上記受信された通信の発信元との通信を確立し、かつ上記確立された２つの通信を中継するように構成された請求項１０１記載の通信センター。
【請求項１０４】
通信システムは、上記複数のユーザ端末のうちの１つ又は複数が、上記選択されたユーザ端末による上記受信された通信の処理を監督することを可能にするように構成された請求項１０３記載の通信センター。
【請求項１０５】
複数のユーザ端末と、
ネットワークゾーンとを備えた通信センターであって、
上記ネットワークゾーンは、複数の通信プロトコルのうちの１つを用いて着信する通信を受信し、上記着信する通信を受信するために使用された通信プロトコルに少なくとも部分的に基づいて、上記受信された通信を処理するための上記複数のユーザ端末のうちの１つを選択するように構成された通信センター。
【請求項１０６】
上記着信する通信は複数の通信タイプのうちの１つであり、
上記ネットワークゾーンはさらに、上記受信された通信の通信タイプに少なくとも部分的に基づいて、上記受信された通信を処理するための上記複数のユーザ端末のうちの１つを選択するように構成された請求項１０５記載の通信センター。
【請求項１０７】
上記ネットワークゾーンはさらに、上記通信に関連付けられた特性に少なくとも部分的に基づいて上記ユーザ端末を選択するように構成された請求項１０５記載の通信センター。
【請求項１０８】
上記ネットワークゾーンはさらに、上記ユーザ端末に関連付けられたプロファイルに少なくとも部分的に基づいて上記ユーザ端末を選択するように構成された請求項１０５記載の通信センター。
【請求項１０９】
上記ネットワークゾーンは、複数の顧客に対する着信する通信を受信し、上記受信された通信に関連付けられた顧客に基づいて上記ユーザ端末を選択するように構成された請求項１０５記載の通信センター。
【請求項１１０】
通信ネットワークにおいてリアルタイムの接続性を維持するための方法であって、
クライアントアプリケーションからマスタアプリケーションへ要求を送信することと、
上記マスタアプリケーションとバックアップアプリケーションとにおいて上記要求を受信することと、
上記マスタアプリケーションから上記要求に対する応答を送信することと、
上記マスタアプリケーションが利用不可能であると決定することと、
上記マスタアプリケーションが利用不可能であると決定した時点で、後続する任意の要求に対する応答を上記バックアップアプリケーションから送信することとを含む方法。
【請求項１１１】
上記マスタアプリケーションが利用可能であるか否かを決定することは、上記マスタアプリケーションからの状態確認情報を要求することを含む請求項１１０記載の方法。
【請求項１１２】
上記マスタアプリケーションが利用可能であるか否かを決定することは、上記マスタアプリケーションがその状態を自動的に更新することを含む請求項１１０記載の方法。
【請求項１１３】
上記通信セッションに関連した情報を格納することと、上記情報を、上記バックアップアプリケーションが利用できるようにすることとをさらに含む請求項１１０記載の方法。
【請求項１１４】
上記マスタアプリケーションが応答を送信している間には、上記バックアップアプリケーションは応答の送信を抑制することをさらに含む請求項１１０記載の方法。
【請求項１１５】
各応答に応答識別子を割り当てることと、上記マスタアプリケーションが利用不可能であると決定されたときに、上記応答識別子を用いて、上記マスタアプリケーションから送信された最後の適正な応答を決定することとをさらに含む請求項１１０記載の方法。
【請求項１１６】
上記バックアップアプリケーションから応答を送信することは、上記マスタアプリケーションから送信された上記最後の適正な応答の次の応答から、応答を送信することを含む請求項１１５記載の方法。
【請求項１１７】
要求を送信するように構成されたクライアントアプリケーションを実行するクライアントサーバと、
上記クライアントアプリケーションから上記要求を受信し、上記要求に対する応答を生成し、上記応答を上記クライアントアプリケーションへ送信するように構成されたマスタアプリケーションを実行するマスタサーバと、
上記クライアントアプリケーションから上記要求を受信し、上記要求に対する応答を生成し、上記マスタアプリケーションが利用不可能であると決定されたときに上記応答を上記クライアントアプリケーションへ送信するように構成されたバックアップアプリケーションを実行するバックアップサーバとを備えた通信システム。
【請求項１１８】
上記バックアップアプリケーション及び上記クライアントアプリケーションの少なくとも一方は、上記マスタアプリケーションに状態要求を送信して上記マスタアプリケーションの利用可能性を決定するように構成された請求項１１７記載の通信システム。
【請求項１１９】
上記マスタアプリケーションは、上記バックアップアプリケーション及び上記クライアントアプリケーションの少なくとも一方へ、利用可能性の更新を自動的に送信するように構成された請求項１１７記載の通信システム。
【請求項１２０】
上記通信システムは、上記マスタサーバ及び上記バックアップサーバに通信可能であるように接続された記憶装置をさらに備え、上記記憶装置は上記要求に関連した情報を格納するように構成され、
上記バックアップアプリケーションはさらに、上記格納された情報にアクセスして、上記バックアップアプリケーションが上記クライアントアプリケーションに応答することを可能にするように構成された請求項１１７記載の通信システム。
【請求項１２１】
各応答には応答識別子が割り当てられ、
上記バックアップアプリケーションは、上記クライアントアプリケーションへの送信に成功した最後の応答に対する上記応答識別子を決定し、上記マスタアプリケーションから送信された上記最後の成功した応答の次の応答から、応答を上記クライアントアプリケーションへ送信するように構成された請求項１１７記載の通信システム。
【請求項１２２】
上記マスタアプリケーションはさらに、上記マスタアプリケーションが利用不可能であるときに上記バックアップアプリケーションが上記クライアントアプリケーションへ応答を送信することを可能にする要求に関連した情報を、上記バックアップアプリケーションへ送信するように構成された請求項１１７記載の通信システム。
【請求項１２３】
上記通信システムは、上記クライアントサーバ、マスタサーバ及びバックアップサーバに通信可能であるように接続された複数の通信経路をさらに備え、上記複数の通信経路の各々は、上記クライアントサーバ、マスタサーバ及びバックアップサーバの互いのインターフェースをとるように構成された請求項１１７記載の通信システム。
【請求項１２４】
上記クライアントサーバ、マスタサーバ及びバックアップサーバの各々は、現在使用されている通信経路がいつ利用不可能になるかということを検出し、上記現在使用されている通信経路が利用不可能になっていることに応答して、上記複数の通信経路のうちの別のものに遷移するように構成された請求項１２３記載の通信システム。
【請求項１２５】
上記クライアントサーバ、マスタサーバ及びバックアップサーバのうちの少なくとも１つは、上記複数の通信経路の各々に関連した情報を含むメッセージルーティングテーブルを備えた請求項１２４記載の通信システム。
【請求項１２６】
上記クライアントサーバ、マスタサーバ及びバックアップサーバは、上記メッセージルーティングテーブルを用いて、利用可能な通信経路を追跡する請求項１２５記載の通信システム。
【請求項１２７】
上記バックアップアプリケーションはさらに、上記クライアントアプリケーションから上記要求を受信し、上記要求に対する応答を生成し、上記マスタアプリケーションが利用可能であると決定されたときに上記応答を上記クライアントアプリケーションへ送信するように構成された請求項１１７記載の通信システム。
【請求項１２８】
上記通信システムはライセンスマネージャアプリケーションをさらに備え、
上記ライセンスマネージャアプリケーションは、上記マスタアプリケーションが利用可能であるか否かを検出し、上記マスタアプリケーションが利用不可能であると当該ライセンスマネージャアプリケーションが検出したときに、上記クライアントアプリケーションへ応答を送信し始めるように上記バックアップアプリケーションに命令するように構成された請求項１１７記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信ネットワークに関し、特に、さまざまなファクタに基づいた複数の通信のルーティング及び処理に関する。
【背景技術】
【０００２】
本出願は、２００２年５月１０日に出願された「弾力的なリアルタイムのインターネット通信（Resilient Real-Time Internet Communications）」と題する仮特許出願シリアル番号第６０／３７９，９５５号と、２００２年３月１８日に出願された「コールセンターの実装（Call Center Implementation）」と題する仮特許出願シリアル番号第６０／３６５，８９０号と、２００２年８月２３日に出願された「コールセンターの実装（Call Center Implementation）」と題する仮特許出願シリアル番号第（未定）号（代理人整理番号０３０１８４．００１１．ＰＲＶ３）とに対して、米国特許法第１１９条に基づいて優先権を主張する。上記出願の各々は、全体を記載したものとしてそれを完全に参照したことにより、ここに含まれる。
【０００３】
今日の通信時代では、かつては対面で行っていたさまざまな取引が、電話、電子メール又は他の何らかの電子通信媒体を介して遠隔で発生する。その結果、大きな組織は、その顧客ら又は複数の構成要素との間で、例えば、電話、電子メール、ファックス、インターネットなどによるさまざまな方法で通信できなければならない。このことは、上記のような組織にとって、効率的、効果的かつ信頼性の高い方法で通信を処理（ハンドリング）する上で途方もなく大きな負担となる。その実行に失敗すると、代償は非常に大きなものになる可能性がある。例えば、組織の通信を最適に管理することに失敗した組織は、通信を処理する際の費用の増大、又は当該組織の反応が遅いことに起因した事業上の損失を被る可能性がある。従って、組織がその通信を可能な限り効果的に処理することは非常に重要である。
【０００４】
日常的な顧客の通信を超えるニーズを有する組織は、例えば典型的にはコールセンターを使用することで通信を処理しまたその販売及びサービスのチームを組織する。従来のコールセンターは、着信する複数の電話呼を受信するように構成された電話サーバを備え、上記電話呼は、さまざまなオペレータ又はエージェントにルーティングされて処理される。呼のルーティングは、多くの場合においてソフトウェアアプリケーションの制御下にあり、よって、ある程度のコンピュータ自動化を用いて達成される。簡単な一例は、着信呼を次の利用可能なエージェントへルーティングするソフトウェアプログラムである。例えば、着信する通信をスクリーニングし、それらの通信を適切な技能を有するエージェントへ転送し、着信する通信の処理に関連した記録を保持するための、より複雑なソフトウェアが構成されることも可能である。
【０００５】
従って、着信する通信がコールセンターによって受信されると、上記通信は適切なエージェントへルーティングされる。このエージェントは必然的に、上記通信を処理するための適切な機器を有している必要がある。例えば、着信する通信が電話呼であれば、エージェントはこの呼を処理する電話機器を有している必要がある。さらに、エージェントは、多くの場合、コールセンターとインターフェースをとる何らかのタイプのコンピュータ端末又はモニタを有し、当該エージェントは、上記コンピュータ端末又はモニタにおいて、着信する通信に関連した情報を受信することができ、又は、上記コンピュータ端末又はモニタを用いて、着信する通信を処理するための関連した情報へアクセスすることができる。例えば端末は、着信する電話呼に関連付けられた発信側の電話番号を表示することができる。端末はまた、発呼者に対するアカウント情報へアクセスするためにも使用可能である。
【０００６】
従って、従来のコールセンターは、一般には、着信する通信を受信してルーティングするように構成された電話サーバと、上記電話サーバとインターフェースをとりかつ呼のルーティングを自動化するためのアプリケーションを実行するように構成されたアプリケーションサーバと、通信処理機器やおそらくは何らかのタイプのデータ端末を介して上記電話サーバとインターフェースをとる複数のエージェントとを備える。典型的に従来のコールセンターとインターフェースをとっている人員には、実際には次のような３つのタイプ、すなわち、１）着信する通信を処理するエージェントと、２）エージェントをモニタリングしかつ支援するスーパーバイザ（監視者）と、３）着信する通信の処理に必要なソフトウェア及びハードウェアをインストールして設定する管理者とが存在する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来のコールセンターは、コールセンターの人員及び関連付けられた呼処理機器と端末、並びに電話及びアプリケーションサーバのすべてを収容しなければならないことから、非常に高価なものになる可能性がある。従来のコールセンターのもつこの集中化された性質は、単一の故障又はエラーがコールセンターの全体又はそのかなりの部分を停止させる可能性があるという点で、さらに別の望ましくない負の結果をもたらす可能性がある。コールセンターは多くの場合、大きな組織とその顧客ら又は複数の構成要素との間の通信の主要点であるので、停止時間は深刻な望ましくない影響を与える可能性がある。短い中断でさえも、失われる通信は非常に大きくなる可能性がある。よって、重大なサービスの中断を防止するために、コールセンターは高い信頼性を有することが重要である。
【課題を解決するための手段】
【０００８】
複数の通信を処理するように構成された分散型通信センターは、ユーザゾーンと、ウェブゾーンと、ネットワークゾーンとを含む。ユーザゾーンは複数の遠隔の端末を含み、これらの遠隔の端末は、通信センターの人員が、ウェブゾーンを介して分散型通信センターと遠隔にインターフェースをとることができるようにする。ウェブゾーンは、ユーザゾーン内の遠隔の端末とネットワークゾーンとのインターフェースをとるように構成されたウェブサーバを含む。ネットワークゾーンは、１つ又は複数の電話サーバとアプリケーションサーバとを含む。
【０００９】
ある態様において、通信センターの人員は、遠隔の端末と、簡単かつ一般的に利用可能なブラウザとを用いて、分散型通信センターと遠隔にインターフェースをとっている。遠隔通信センターの人員は、カスタマイズされたアプリケーション（特別に構成されたアプリケーション）を必要に応じて彼らの端末にダウンロードすることができる。それに代わって、彼らの端末は、必要な任意のカスタマイズされたアプリケーションをすでに備えていてもよい。従って、通信センターのリソースは、コストを低減することができかつより大量の通信のより効率的な処理をもたらすことができるような方法で、分散されることが可能である。
【００１０】
以下、「発明を実施するための最良の形態」と題するセクションにおいて、本発明のこれらの特徴、態様及び実施形態について、又は他の特徴、態様及び実施形態について説明する。
【００１１】
本発明の特徴、態様及び実施形態を、添付の図面に関連して説明する。
【発明を実施するための最良の形態】
【００１２】
図１は、ここに記載したシステム及び方法に係る例示的な実施形態に従って構成された通信システム１００を示す図である。通信システム１００は、通信センター１２８を備えている。後述する例示的な実施形態の多くの場合で、通信センター１２８は、上述のようなコールセンターである。しかしながら、以下に提示するシステム及び方法は概してコールセンターのコンテキストで説明される場合があるが、本システム及び方法は必ずしもコールセンターのアプリケーションに限定されないということは留意されるべきである。説明されるシステム及び方法の多くは、着信する大量の通信がルーティングされかつ処理される必要のある任意の通信システムに適用されることが可能である。従って、以下に提示する例は、説明したシステム及び方法を任意の特定のアプリケーションに限定するものと見なされるべきではない。
【００１３】
コールセンター１２８は複数の遠隔のサイトとインターフェースをとっているが、ここではそのうちの遠隔のサイト１１２及び１１８を例示として示している。コールセンター１２８は、１つ又は複数の通信ネットワークを介して遠隔のサイト１１２及び１１８とインターフェースをとっている。図１の例示的な実施形態では、コールセンター１２８は、公衆交換電話網（ＰＳＴＮ）１２６及びインターネット１２４を介して遠隔のサイト１１２及び１１８とインターフェースをとっている。ただし、ネットワーク１２４又は１２６は、例えば、無線ＷＡＮ等の任意のタイプの広域ネットワーク（ＷＡＮ）であるか、又は何らかの形式のより小規模のローカルエリアネットワーク（ＬＡＮ）である場合もある。
【００１４】
コールセンター１２８は、ＰＳＴＮ１２６とインターフェースをとっている電話サーバ１０４を備えている。電話サーバ１０４は、着信する複数の電話通信を受信するように構成される。コールセンター１２８はまた、電話サーバ１０４とインターフェースをとりかつコールセンター１２８の動作を管理するように構成されたアプリケーションサーバ１０６も備えている。さらにコールセンター１２８は、電話サーバ１０４とインターフェースをとりかつ着信する電話通信を受信するように構成された複数のローカルな端末１１０を備えることが可能である。例えば、端末１１０は、電話機又はファックス端末であることが可能である。
【００１５】
アプリケーションサーバ１０６は、電話サーバ１０４によって、又は後述のようにウェブサーバ１０２によって受信される特定の着信する通信をどのエージェントが処理すべきかということに関してインテリジェントな決定を下し、次いで、上記着信する通信が適切な端末へルーティングされるようにサーバ１０２及び１０４を制御するように構成されることが可能である。それに代わって、アプリケーションサーバ１０６は、特定の着信する通信を処理するために選択されたエージェントが、必ずしも上記着信する通信が受信されるときでなくとも、関連付けられた顧客とコンタクト（連絡）を有した状態にあるように、コールセンター１２８の動作を制御するように構成されることが可能である。以下、この点についてさらに詳述する。
【００１６】
アプリケーションサーバ１０６、電話サーバ１０４、ウェブサーバ１０２、並びに端末１０８及び１１０は、特に単一の建物又はキャンパスの敷地等の制御場所内に上記構成要素のすべてが収容されるような実装のために、何らかのタイプのＬＡＮを介して相互接続されることが可能である。ただし、後述のように、構成要素のいくつか又はすべてが地理的に分散されることが可能であり、この場合は、コールセンター１２８を構成する構成要素のいくつか、又はすべてをインターフェースで接続するために何らかのタイプのＷＡＮが必要とされる可能性がある。
【００１７】
従来のコールセンターとは異なり、コールセンター１２８はまた、インターネット１２４とインターフェースをとりかつ複数の着信するウェブに基づく通信又はインターネット通信を受信するように構成されたウェブサーバ１０２を備えている。ウェブサーバ１０２は、コールセンター１２８が、例えば電子メール等の非電話通信を受信できるようにし、これにより、コールセンター１２８の能力が拡張されかつコールセンター１２８にアクセスする顧客らに対してより大きな柔軟性がもたらされる。従って、ウェブサーバ１０２とインターフェースをとり、また、着信するウェブに基づく通信をアプリケーションサーバ１０６の制御下で処理するように構成された、例えばコンピュータ端末である複数のローカルな端末１０８が存在しうる。端末１０８はまた、着信する通信に関する情報を表示するように構成されることも可能であり、又は着信する通信に関連付けられた顧客に関する情報にアクセスするように構成されることも可能である。
【００１８】
図１の例では、サーバ１０２はインターネット１２４とインターフェースをとっているウェブサーバであるが、その一方、ネットワーク１２４は、一般には、任意のタイプのデータネットワークであることが可能であり、サーバ１０２は任意のタイプの関連付けられたデータサーバであることが可能である。例えば、サーバ１０２は、ＰＳＴＮ１２６などに関連付けられたより伝統的な回線交換サーバとは対照的な、パケットに基づく任意のタイプのデータサーバであることが可能である。
【００１９】
ウェブサーバ１０２を含んでいることにより、コールセンター１２８は実際に、着信するさまざまな通信を処理するように構成されることが可能である。それらの着信する通信は、複数の通信プロトコルを用いた複数の通信タイプのうちのいずれかであることが可能である。異なるタイプの通信及び／又はプロトコルの各々は、通信を処理するための特有のリソース及び方法を必要とする。いくつかの例示的な通信タイプは、電話呼、ファクシミリ（ファックス）送信、電子メール、又はワールドワイドウェブ（ウェブ）に基づくコンタクト等のインターネット通信であることが可能である。本明細書及び添付の請求の範囲の目的に沿って、可能な異なるタイプの通信のすべてを「通信」という用語を用いて総称的に呼ぶ。「対話（インタラクション）」、「連絡（コンタクト）」又は「呼（コール）」といった他の同様の総称的な用語を用いて、従来のコールセンターによって処理される異なるタイプの通信について言及することも可能であることは留意されるべきであるが、ここでは明確さ及び一貫性を期して「通信」という１つの用語を使用する。
【００２０】
ウェブサーバ１０２を含むことはまた、遠隔のサイト１１２及び１１８等の複数の遠隔の場所にコールセンターの人員を地理的に分散させることを容易にする。これは、コールセンター１２８とインターフェースをとるために簡単なウェブブラウザを使用可能であるということに起因する。従って、コールセンターの人員は、例えばウェブサーバ１０２にアクセスするように構成された端末１２０を備えた、遠隔のサイト１１８に配置されることが可能である。端末１２０は、例えば、コンピュータ、個人情報端末（Personal Digital Assistant：ＰＤＡ）、又はインターネット１２４にアクセスするように構成された他の任意の装置であることが可能である。従って、コールセンター１２８に関連付けられたエージェント、スーパーバイザ、及び管理者は、インターネット１２４へのアクセスがある限り、世界中のどこからでも彼らの役割を効果的に実行することができる。
【００２１】
端末１２０は、アプリケーションサーバ１０６の制御下で、着信するウェブに基づく通信を処理するように構成されることが可能である。端末１２０はまた、着信する通信を処理するための関連情報にアクセスするように構成されることも可能である。遠隔のサイト１１８はまた、ＰＳＴＮ１２６を介してコールセンター１２８とインターフェースをとる端末１２２を備えることが可能である。従って遠隔のサイト１１８に配置されたエージェントは、コールセンター１２８によって受信される任意のタイプの通信を、まるで当該エージェントがコールセンター１２８に配置されているかのように処理することができる。従って、コールセンター１２８は、インターネット１２４又はＰＳＴＮ１２６のいずれかを介して着信する通信を受信し、次に、処理のために、アプリケーションサーバ１０６の制御下で、例えば遠隔のサイト１１８である遠隔のサイトにおけるエージェントへ上記通信をルーティングするように構成されることが可能である。次にエージェントは、端末１２２及び／又は端末１２０を用いて通信を処理することができる。
【００２２】
従って、上述のシステム及び方法は、任意の形式の通信をパケット交換ネットワーク又は回線交換ネットワークを介して任意の通信センターの人員に向けて、当該人員の場所に関わりなくルーティングすることができるとともに、彼ら人員が集中化された通信センター１２８に配置されている場合と同様の機能及び可視性をもたらす、分散型通信センターの構成を可能にする。コールセンターの機能をこのように分散することは、ウェブサーバ１０２を含むことと、複雑又は高価な機器を必要とすることなく遠隔のサイト１１８からウェブサーバ１０２に容易にアクセス可能であるという事実とによって可能にされる。必要なものは、例えば、適切なウェブブラウザを有する端末１２０のみである。
【００２３】
図２は、ここに記載したシステム及び方法に係る１つの例示的な実施形態に従って構成された分散型通信センター２３４を示す。通信システム２３４は、３つのゾーン、すなわち、ネットワークゾーン２００とウェブゾーン２０２とユーザゾーン２０４とを備える。ネットワークゾーン２００は、通信の処理を制御するように構成されたアプリケーションサーバ２０６と、ＰＳＴＮ２３０とインターフェースをとっている電話サーバ２１２とを備えることが可能である。アプリケーションサーバ２０６及び電話サーバ２１２は、上述の方法と同じように動作することができる。ネットワークゾーン２００はまた、複数のデータベースサーバ２０８とインターフェースをとっている１つ又は複数のデータベース２１０を備えることが可能である。データベース２１０は、例えば顧客アカウント又は履歴情報を格納するように構成されることが可能である。さらにデータベース２１０は、分散型通信センター２３４によって処理される通信に関する情報を格納するように構成されることも可能である。
【００２４】
ウェブゾーン２０２はウェブサーバ２１６を備え、また、メールサーバ２１８を備えることも可能であるが、これらの２つのタイプのサーバの機能は１つの物理的なサーバに組み合わされることも可能である。顧客らと通信センターの人員とは、インターネット２２２を介してウェブサーバ２１６及び／又はメールサーバ２１８に接続することができる。ウェブサーバ２１６は、顧客ら又は通信センターの人員によって生成される、ウェブに基づく通信を処理するように構成されることが可能であり、一方、メールサーバ２１８は、電子メール通信を処理するように構成されることが可能である。サーバ２１６及び２１８は、セキュリティ及びネットワーク保護のために、ファイアウォール２１４を介してネットワークゾーン２００とインターフェースをとることが可能である。同様に、サーバ２１６及び２１８は、ファイアウォール２２０を介してユーザゾーン２００とインターフェースをとることが可能である。
【００２５】
ユーザゾーン２０４は複数の遠隔のサイトを備え、そのうちの遠隔のサイト２３６を例として図示している。通信センターの人員は、遠隔のサイト２３６からウェブゾーン２０２又はネットワークゾーン２００にアクセスすることができる。特に、遠隔のサイト２３６は、ネットワークゾーン２００にアクセスするために使用可能な、例えば図１の端末１２２等の端末機器と、ウェブゾーン２０２にアクセスするために使用可能な、例えば図１の端末１２０等の端末機器とを備えている。遠隔のサイト２３６に配置されたデータ端末、すなわち端末１２２には、ネットワークゾーン２００及びウェブゾーン２０２へ効果的にアクセスするために、１つ又は複数のカスタマイズされたアプリケーションがロードされることが可能である。例えば、通信センターの管理者は、当該管理者の端末上にロードされた管理マネージャアプリケーション２２４を有することが可能であり、スーパーバイザは、当該スーパーバイザの端末上にロードされた監督マネージャアプリケーション２２６を有することが可能であり、エージェントは、当該エージェントの端末上にロードされた対話マネージャアプリケーション２２８を有することが可能である。以下、このようなカスタマイズされたアプリケーションの例示的な機能についてより詳細に議論する。
【００２６】
通信センターの人員の端末１２０上には、カスタマイズされた任意のアプリケーションに加えて、ウェブゾーン２０２とのコンタクトを可能にするブラウザアプリケーションもロードされることが可能である。従って、例えば、エージェント等である通信センターの人員は、ブラウザアプリケーションを用いて遠隔の場所２３６からウェブサーバ２１６へアクセスすることができる。エージェントはいったんウェブサーバ２１６へアクセスすると、「ログオン」して自らをエージェントとして識別することができる。アプリケーションサーバ２０６は次に、エージェントのブラウザに所定のウェブページへアクセスさせるように、ウェブサーバ２１６に指示することができ、エージェントは、このウェブページから、顧客の通信を処理するためのカスタマイズされた対話マネージャアプリケーション２２８をダウンロードすることができる。次いで、対話マネージャアプリケーション２２８は、例えば、処理される通信に関する情報を、エージェントの端末上の所定の「ウィンドウ」内に表示するようにエージェントの端末１２０を構成することができ、もしくは、対話マネージャアプリケーション２２８は、エージェントが、所定の情報を表示するウェブサーバ２１６上のウェブページへアクセスすることを可能にすることができる。
【００２７】
ある例示的な実施形態では、ウェブサーバ２１６上に格納されたスクリプト又はＪａｖａアプレットを用いてアプリケーションをダウンロードすることができる。同様に、アプリケーションは、いったんダウンロードされると、端末１２０上に当該アプリケーションをインストールするスクリプト又はＪａｖａアプレット、及び／又は当該アプリケーションを実行するように端末１２０を構成するスクリプト又はＪａｖａアプレットを実行させることができる。
【００２８】
顧客らが、遠隔の通信センターの人員とほぼ同様の方法で顧客の場所２３２から通信センター２３４とインターフェースをとることができるということは留意されるべきである。言い換えれば、再度図１を参照すると、遠隔のサイト１１２は実際に顧客の場所を表すことが可能である。従って顧客は、例えば、電話機又はファックス端末１１６を用いて、ＰＳＴＮ１２６を介して通信センター１２８へ通信を送ることができる。それに代わって、顧客は、コンピュータ等のデータ端末１１４を用いて、例えば電子メールである通信をインターネット１２４を介して送ることができる。端末１１４はまた、例えばウェブブラウザを用いてウェブサーバ１０２上のウェブページへアクセスすることにも使用可能である。この能力により、通信センター１２８は、さまざまな非コールセンター通信と非電話通信とを処理することができる。例えば、通信センター１２８は、数例を挙げるだけでも、オンラインのクレジット認証や、商品及びサービスの発注や、予約の申し込みを処理するように構成されることが可能である。
【００２９】
インターネット１２４を用いて、又はより総称的にはパケット通信を用いて通信センター１２８に接続する能力は、広範に利用可能である標準化された通信プロトコルの使用を可能にし、これにより、カスタマイズされたプロトコル、又は所有権が占有された（プロプライエタリな）プロトコルを使用する必要性が取り除かれる。例えば、顧客ら又は通信センターの人員によるウェブサーバ１０２へのアクセスのために、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）等のインターネットプロトコル（ＩＰ）を使用可能である。ＩＰは、ウェブブラウザが、一般的に使用されかつ一般的に利用可能なハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いてウェブサーバ１０２と通信することを可能にする。従って、これらのさまざまなプロトコルは、実装及び保守のコストを低減させることができる。
【００３０】
セキュリティの観点からは、実際には、暗号化と、第三者（サードパーティー）の認証機関又は組織とを用いた安全な通信を許容する、ハイパーテキスト転送プロトコル／セキュア（Hyper Text Transfer Protocol/Secure：ＨＴＴＰ／Ｓ）を使用することが好ましい可能性がある。このようなセキュリティは、所望されかつ安全なウェブサーバ１０２のみが、例えばウェブページ等の情報を通信センターの人員及び顧客のウェブブラウザへ送信することを保証する。さらに、ベリサイン  インコーポレイテッド（Verisign, Inc.）によって提供されるもののような「指紋（フィンガープリント）」法を用いて、所望されかつ安全なウェブブラウザだけがウェブサーバ１０２からの情報を要求可能であるということを保証することもできる。
【００３１】
ＴＣＰ／ＩＰ、ＨＴＴＰ及びＨＴＴＰ／Ｓは、通信ネットワークにおいて現在使用されているいくつかの広範に受け入れられているプロトコルのうちの単なる例である。ただし、これらの例は、ここに記載したシステム及び方法を任意の特定のタイプのプロトコルに限定するものとして理解されるべきではない。
【００３２】
図３は、遠隔通信の人員が遠隔の場所２３６からウェブゾーン２０２とインターフェースをとれるようにするプロセスの一例を示すフローチャートである。本プロセスは、ステップ３０２で、遠隔の人員が例えばウェブブラウザを用いてサーバ２１６にアクセスすることから開始する。ステップ３０４で、遠隔の人員は識別情報をウェブサーバ２１６に提供する。この識別情報は、例えばユーザ名又はパスワードであることが可能である。これに対して、顧客がウェブサーバ２１６にアクセスしようとしている場合、識別情報は、例えば、アカウント情報であるか、又は、住所、電話番号、電子メールアドレスなどのような一般的なコンタクト情報であることが可能である。
【００３３】
いったん遠隔の人員が識別情報を提供すると、ウェブサーバ２１６は、彼らを、エージェント、スーパーバイザ、管理者として分類し、又は、ウェブサーバ２１６にアクセスしているのが顧客であれば顧客として分類することができなければならない。いったん遠隔の人員が分類されると、ウェブサーバ２１６は、管理マネージャアプリケーション２２４、監督マネージャアプリケーション２２６、又は対話マネージャアプリケーション２２８等の任意の必要なアプリケーションをダウンロードするように構成されることが可能である。それに代わって、ウェブサーバ２１６は、遠隔の人員を所定のウェブページに向かわせるように構成されることが可能であり、上記遠隔の人員は、そのウェブページから任意の必要なアプリケーションをダウンロードすることができる。
【００３４】
リソースの観点からは、遠隔の人員の端末で実行される任意のアプリケーションは、好適には省スペースのアプリケーションである。例えば、このことは、必要に応じたそのダウンロードをより容易かつ高速にするだけでなく、遠隔の端末の例えばメモリ及び処理パワーのようなリソースの必要条件を減少させる。これによりは、遠隔の場所２３６及び顧客の場所２３２におけるシンクライアント端末の使用が可能になる。
【００３５】
それに代わって、遠隔の人員の端末は、必要なすべてのアプリケーションをすでに備えている場合もある。この場合、ウェブサーバ２１６は、ステップ３２０において、アプリケーションの現バージョンがアクセス側の端末にロードされてからアプリケーションの何らかの更新版、すなわち新バージョンが生成されているか否かを決定するように構成されることが可能である。答えがｙｅｓであれば、ウェブサーバ２１６は、ステップ３２２においてアクセス側端末に更新版をアップロードするか、又は、更新版をダウンロード可能なウェブページへ上記端末を向かわせるように構成されることが可能である。
【００３６】
アプリケーション又は更新版をダウンロードする能力は、各遠隔の端末を構成するために技術者を各遠隔の場所２３６へ急いで派遣する必要がないことから、配備及び保守のコストを低下させる。同様に、アプリケーション又は更新版は、遠隔通信の人員又は顧客らへメールで送られたり又は配信されたりする必要がない。必要とされるものはむしろ、標準的な、広く流通したブラウザ又は同様のアプリケーションのみである。
【００３７】
ステップ３０６でアプリケーションがダウンロードされた後で、又はステップ３２２で更新版がアップロードされた後で、アクセス側端末は、ステップ３０８で上記アプリケーションを実行するように構成されることが可能である。言い換えれば、いったん端末上に新規な又は更新されたアプリケーションがロードされると、上記端末は上記アプリケーションを実行するように構成される必要がある。このことは、例えば、端末を「リブート」することにより、又は、ダウンロード／アップロードでトリガーされる例えばスクリプト又はＪａｖａアプレットを用いた端末の自己構成によって達成されることが可能である。
【００３８】
アクセス側端末にダウンロードされるアプリケーションは、端末が、アプリケーションサーバ２０６により処理されている通信に関する所定の情報及び／又はリソースを受容すること、及び／又は、受容された情報／リソースに応答して所定の機能を実行することを可能にする。また、情報／リソースの受容に関連付けられた設定も存在することが可能であり、例えば、それがどのように受容されるか、それがいつ受容されるか、又は特に何が受容されるかについての設定が存在できる。以下、これらの設定のいくつかについてより詳しく議論するが、ステップ３１０では、ステップ３０８でダウンロードされたアプリケーションを実行するように端末が構成されている時点で、このような任意の設定を構成する必要があるか否かに関して決定を下すことができる。答えがｙｅｓであれば、ステップ３１２において、端末は、ウェブブラウザ又はダウンロードされたアプリケーションの１つを用いてウェブサーバ２１６にアクセスし、ステップ３１４において設定を構成することができる。
【００３９】
いったん設定が構成された場合、もしくは設定を構成する必要がない場合、ステップ３１６において、アクセス側端末は、アプリケーションサーバ２０６により処理されている通信に関する情報を受信し始めることができる。さらにステップ３１８において、遠隔の人員又は顧客は適宜に応答することができる。例えば遠隔の人員がエージェントであれば、当該エージェントは、アプリケーションサーバ２０６による指示の下で、例えば顧客らからメールサーバ２１８を介して送信される電子メール通信を受信し始めることができる。するとエージェントは、必要であればこの電子メールに応答することが可能であり、例えば、電子メールが製品の照会であれば、エージェントはこの照会に応答することができる。これに対して、遠隔の人員がスーパーバイザであれば、当該スーパーバイザは、ウェブゾーン２０２及び／又はネットワークゾーン２００に接続されたエージェントにより処理されている通信に関する情報を受信し始めることができる。所定の実施形態では、スーパーバイザは、彼らがエージェントの「デスクトップ」をリアルタイムで見ることを可能にするアプリケーションをダウンロードすることさえもできる。この機能は、監督マネージャアプリケーション２２６に組み込まれることが可能であり、もしくは、例えばプロキシの遠隔のゲートウェイシステムのアプリケーション等の別個のアプリケーションであることも可能である。
【００４０】
管理マネージャアプリケーション２２４、監督マネージャアプリケーション２２６、及び対話マネージャアプリケーション２２８等のアプリケーションは、遠隔の通信センターの人員が、遠隔の場所からの通信センター２３４により受信される通信を、それがどのタイプの通信であるかに関わらず、すなわちそれがインターネット２２２を介して受信されるかそれともＰＳＴＮ２３０を介して受信されるかに関わらず、処理することを可能にする。例えば、対話マネージャアプリケーション２２８は、エージェントがあたかも集中化されたコールセンター１２８に控えているかのように、着信する通信に対して当該エージェントが応答することを可能にできる。図４に、対話マネージャアプリケーション２２８に関連付けられることが可能な例示的なグラフィカルユーザインターフェース（ＧＵＩ）４００のスクリーンショットを示す。従って、例えば、対話マネージャアプリケーション２２８は、ＧＵＩ４００を端末１２０上に表示するように構成されることが可能である。
【００４１】
ＧＵＩ４００は、さまざまな通信のタイプに応答するために使用可能である。例えば、いったんあるエージェントがウェブサーバ２１６にアクセスして通信センター２３４内に接続されると、アプリケーションサーバ２０６は、メールサーバ２１８を介して受信される電子メールの、このエージェントへの方向付けを開始できる。エージェントは次に、受信された電子メールに関する情報を当該エージェントのＧＵＩ４００ディスプレイで見ることができ、例えばマルチメディア対話制御ウィンドウ４０８で見ることができる。エージェントは次に、受信された電子メール通信に対して、電子メールを用いて応答することができる。それに代わって、エージェントは、送信者のコンタクト情報が利用可能であれば、電子メールの送信者に対して電話をかけることもできる。
【００４２】
顧客が通信センター２３４にアクセスする際にその顧客により入力されるコンタクト情報は、ＧＵＩ４００に表示されることが可能であり、例えばマルチメディア対話制御ウィンドウ４０８の一部に表示されることが可能である。さらに、いくつかの実施形態では、エージェントは、アカウント又はコンタクト履歴等の送信者に関する情報にアクセスすることができる。例えば、エージェントがボタン又はインジケータをクリックして送信者に関する所定の情報へアクセスすることを可能にするリソースバー４０４が、ＧＵＩ４００に含まれてもよい。
【００４３】
エージェントが電話をかけようとしているところであれば、エージェントは、例えば端末１２２のような従来の電話機を用いてＰＳＴＮ２３０を介して電話をかけることができる。それに代わって、電話機のような適切な音声入力、出力及び処理を装備した端末１２０をエージェントが使用できるようにするダイヤラアプリケーションを、対話マネージャアプリケーション２２８が含んでいてもよい。このようなダイヤラアプリケーションは、別個のダイヤラ画面を表示することが可能であり、又は、ダイヤラ画面がＧＵＩ４００に組み込まれることも可能である。図４の例では、ＧＵＩ４００は実際にダイヤラインターフェース４０２を含んでいる。
【００４４】
従って、エージェントは、応答を要求している電子メールを受信すると、例えば、ダイヤラインターフェース４０２を用いて送信者に電話をかけることができる。インターネット２２２又はパケットに基づく任意のネットワークを介して音声通信を行うためには、ボイス・オーバー・ＩＰ（ＶｏＩＰ）として知られた技術が必要とされる可能性がある。従って、対話マネージャアプリケーション２２８にダイヤラアプリケーションが含まれている場合、通信センター２３４はＶｏＩＰを処理できる必要がある。
【００４５】
送信者にかけられた電話は、さまざまな方法で処理されることが可能である。多くの場合、エージェントはＶｏＩＰを介してネットワークゾーン２００に接続され、かつネットワークゾーン２００からＰＳＴＮ２３０を介して送信者へ接続される。この場合、ネットワークゾーン２００は、回線交換通信とＶｏＩＰとの間で変換するために必要なリソースを備えるはずである。これに対して、送信者がＶｏＩＰ通信を行う能力を備えていれば、接続は純粋にインターネット２２２を介したＶｏＩＰであってよい。
【００４６】
同様に、エージェントにルーティングされた着信する通信は、電子メール通信ではなく電話による通信である可能性もある。電話通信は、伝統的な回線交換通信である場合もあり、もしくはＶｏＩＰ通信である場合もある。これが回線交換電話通信であれば、通信センター２３４は、エージェントがそのダイヤラアプリケーションを用いて通信を処理できるように、これをＶｏＩＰに変換するように構成されることが可能である。それに代わって、通信センター２３４は、ＰＳＴＮ２３０を介して呼をエージェントへルーティングするように構成されることが可能であり、上記エージェントは従来の電話機を用いて上記呼を処理することができる。後者の状況でもやはり、エージェントは、ＧＵＩ４００を用いて上記呼に関連した情報を受信する必要があり、またこの情報にアクセスできる必要がある。
【００４７】
対話マネージャ２２８を用いて受信される／処理されることが可能な他の例示的なタイプの通信は、ファックス、ボイスメール、及びインターネットのチャットセッションである。これらのうちのいくつか、又はすべては、対話マネージャアプリケーション２２８を用いて、ＧＵＩ４００又は別個の表示画面を介して直接に処理されることが可能である。例えば図５に、インターネットのチャットセッションの例示的な管理画面５００を示す。通信センター２３４によって処理される異なるタイプの通信のうちのいくつか又はすべては、ＶｏＩＰから回線交換への処理と回線交換からＶｏＩＰへの処理の場合について上述したのように、上記通信がネットワークゾーン２００を通過する際に通信センター２３４によって処理される／再符号化されることが可能である。上記処理／再符号化は、必ずしもリアルタイムで実行される必要はない。例えば、ファックス送信は、ＰＳＴＮ２３０を介して受信されて、例えばデータベース２１０に、電子的に格納されることが可能である。格納されたファックスデータは、次いでメールサーバ２１８を介して電子メールとしてエージェントに転送されることが可能である。
【００４８】
同様に、着信する通信のエージェントへのルーティングも、必ずしもリアルタイムで行われる必要はない。明らかに、電子メール通信の場合、電子メールは周期的に収集されて転送されることが可能である。電話通信の場合は、回線交換式であれＶｏＩＰであれ、着信する電話呼が受信され、発呼者の要求又はニーズが判断され、かつ上記呼の接続が断たれることが可能である。適切なエージェントを選択することが可能であり、最初の発呼者とエージェントとの間で別個の通信を確立することが可能である。いったん確立されると、２つの通信は、エージェントがそれで最初の発呼者と直接にコンタクトできる状態になるように中継される（ブリッジされる）ことが可能である。
【００４９】
ただし、ルーティングはリアルタイムでない可能性があるとしても、エージェントと発呼者との間の通信は、いったん確立されるとリアルタイム通信になるということに留意すべきである。従って、ＶｏＩＰ技術を使用する場合、リアルタイム通信が中断されないことを保証する機構が適切に設けられる必要がある。このことは、パケットネットワーク及びパケット通信の性質に起因して容易なタスクではないが、実行は可能である。以下、パケットに基づくリアルタイム通信が中断されないことを保証するためのシステム及び方法について示す。また、通信のルーティングはリアルタイムでない可能性があるとしても、通信センター２３４の分散的性質に起因した、通信を処理する際における追加の遅延が存在すべきでないということも留意されなければならない。反対に、通信の処理は、通信センター２３４と効果的に通信するより多くのエージェント及びより多くの方法を利用可能であることにより、高速化されるか又は容易化される場合が多い。
【００５０】
より多くのエージェントが利用可能となりうるのは、通信センター２３４の分散的性質により、多くのエージェントを接続することが容易になるからである。さらに、これらのエージェントは中央の場所に収容されるのではないので、これらを接続するコストは比較的低い。さらに、遠隔通信の人員の端末上で実行されるアプリケーションのシンクライアントとしての性質と、アプリケーション及び任意の更新版を配信する際の容易さと、ウェブサーバ２１６へのアクセスに使用される基本的技術、すなわちブラウザ技術の広範な利用可能性とは、通信センター２３４及びそのすべての遠隔のサイト２３６の確立及び保守のコストを低下させる。従ってまた、低下したコストにより、顧客らは、例えばエージェントであるより多くのリソースをさらに容易に利用できるようになる。
【００５１】
図４に戻ると、エージェントはＧＵＩ４００を介して他の多くのリソース及びオプションを利用可能であるということが分かる。まず、例えば処理される通信に関する状態（ステータス）を表示することができる状態領域４０６が存在する。状態領域４０６には、実際のエージェントの状態が表示されることも可能である。所定の実施形態では、遠隔のエージェントらは、対話マネージャアプリケーション２２８を用いて当該エージェントらの利用可能性を構成することができる。各エージェントによって構成される利用可能性は、次に、詳細後述するように通信のルーティングにおいて使用されることが可能である。従って、エージェントらは、好適には、新たな通信を受信するためにそれらのエージェントが利用可能であるか又は利用不可能であるように、当該エージェントの状態を構成することができる。エージェントらはまた、実施形態に依存して、当該エージェントにルーティングされた通信を受け入れるか又は拒否すること、エージェント側において通信をミュートする（無音状態にする）こと、通信を記録すること、発呼者の呼を保留すること、発呼者の呼を転送すること、電話呼をボイスメールにして送信することなどを行うことができる。エージェントはまた、例えば、受信された電子メール、ボイスメール又はファックスをチェックすることもできる。ＧＵＩ４００には、これらのタイプの動作又は活動を支援する１つ又は複数のオプションツールバーを組み込むことができる。図４の例では、領域４１０がオプションツールバー４１２と個人のオプションツールバー４１４とを備えている。
【００５２】
図６に、監督マネージャアプリケーション２２６に関連付けられることが可能な例示的なＧＵＩ６００のスクリーンショットを示す。従って、例えば、監督マネージャ２２６は、ＧＵＩ６００を端末１２０上へ表示するように構成されることが可能である。図から分かるように、ＧＵＩ６００はログイン画面６０２を備えることが可能である。スーパーバイザは、監督マネージャアプリケーション２２６を用いて通信センターのリソースにアクセスできるようになる前に、識別情報を入力するように要求される可能性がある（図３のステップ３０４）。いったんスーパーバイザがログオンされると、スーパーバイザは、エージェントによる通信処理をモニタリングすることができるようになる。スーパーバイザは、例えば、ネットワークゾーン２００及び／又はウェブゾーン２０２によって受信される通信を処理するすべてのエージェントをモニタリングするか、又はエージェントらの何らかのサブセットをモニタリングすることができる。例えば、２つ以上の企業が通信センター２３４によってホスティングされる場合、スーパーバイザは、所定の企業に関してのみ通信を処理するエージェントらをモニタリングすることを許容されてもよい。ホスティングという概念については、後により詳しく議論する。
【００５３】
ＧＵＩ６００には、エージェント状態バー６０４が含まれることが可能であり、スーパーバイザは、このエージェント状態バー６０４から、当該スーパーバイザの監督機能に関する異なるタスクを実行することができる。この状態バーは、監督マネージャアプリケーション２２６に組み込まれたか又はこれとは別個の機能であって、スーパーバイザが、所定のエージェントにより処理されている電話呼を聴くこと、所定のエージェントらが通信を処理する際に当該エージェントに指示を与える（コーチする）こと、又は所定の通信の処理に参加することを可能にする機能へアクセスするために使用可能である。
【００５４】
電話通信の場合、この指示を与える機能は、好適には、エージェントがスーパーバイザからの命令を聞くことを可能にするが、顧客がスーパーバイザからのメッセージを聴くことを防止する。非電話通信では、指示を与える機能は単に、スーパーバイザが例えば電子メール等のメッセージをエージェントへ送信できるようにすることが可能である。それに代わって、スーパーバイザは、単に非電話通信に介入してこれに応答すること、すなわち通信の処理に参加することができる。
【００５５】
エージェント状態バー６０４からアクセスされることが可能な他の機能は、単にそのいくつかを列挙すると、スーパーバイザが、非電話通信の処理を見て又はさらにエージェントの画面の制御を行なうことと、エージェントら又は顧客らへメッセージを送信することと、エージェントら又は顧客らとチャットを行うことと、すべてのエージェント及び／又はスーパーバイザに、もしくはエージェント及び／又はスーパーバイザの何らかのサブセットにメッセージをブロードキャストすることと、再度ログインするためにエージェントらがスーパーバイザにコンタクトしなければならないように当該エージェントをログアウトさせることと、エージェントの画面の画像を捕捉することと、言語的なものであれ電子的なものであれエージェントの会話を記録することと、以前に記録された会話のデータベース、例えばデータベース２１０のうちの１つを検索することとを可能にする機能を含むことができる。監督マネージャアプリケーション２２６は、これらの機能又は他の機能に関連した情報をＧＵＩ６００の表示領域６１０に表示するように構成されることが可能である。
【００５６】
ＧＵＩ６００はまた、スーパーバイザがさらなる機能又はリソースにアクセスできるようにするオプションツールバー６０６を有していてもよい。ＧＵＩ６００は、例えば、オプションツールバー６０６においてどのオプションが選択されるかということに依存して異なるツールバー６０４を表示するように構成されることが可能である。状態領域６０８では、処理される通信に関連した情報も見ることができる。
【００５７】
スーパーバイザらは、エージェントとしても動作することが許容されていてもよく、従って、監督マネージャアプリケーション２２６には、対話マネージャアプリケーション２２８が組み込まれていてもよいということを覚えておく必要がある。この場合、ＧＵＩ６００は、組み込まれた対話マネージャアプリケーションが、ＧＵＩ６００内に含まれたツールバーの１つからアクセスされうるように構成されることが可能である。それに代わって、スーパーバイザの端末１２０上に、別個の対話マネージャアプリケーション２２８がロードされる場合もある。
【００５８】
とりわけ、通信センターの管理者は、通信センター２３４の業務上のニーズに対処するインテリジェントな通信のルーティングの選択を行うように、アプリケーションサーバ２０６を構成することができる。例えば、顧客が、自動車販売会社のスペイン語を話す顧客専用の回線で電話をかけると、アプリケーションサーバ２０６は、上記自動車販売会社に指定されかつスペイン語に堪能なエージェントへ、その呼をルーティングするように構成されることが可能である。呼のルーティングに関しては後にさらに詳しく議論するが、通信センターの管理者によって構成されることが可能なアプリケーションサーバの他の能力には、エージェントのプロファイルを定義することが含まれる。エージェントのプロファイルは、技能（スキル）、アクセス権、作業グループ、スーパーバイザなどを指定することが可能であり、通信のルーティングに使用されることが可能である。作業グループは、例えば通信センター２３４によってホスティングされる特定の企業に関連付けられた通信等の、同じタイプの通信に関して作業するエージェントのグループであることが可能である。通信センターの管理者はまた、所定の通信ルーティング方法を実装するための業務上のルールや、複数のエージェント、作業グループ又は他の何らかの実在物に通信を配信するためのタッチトーンメニューや、保留音（保留時の音楽）又は呼出音等のメニュープロンプトを構成することができる。通信センターの管理者はまた、通信センター２３４がタッチトーンメニューにおいて顧客情報を収集できるようにすることと、推定された待機時間だけ顧客が聴くことを可能にすることと、顧客による自動車電話のコールバック要求を許容することと、発呼者がエージェント又は作業グループにボイスメールのメッセージを残すことを可能にすることと、通信センターのサービスレベルを管理することとが可能である。
【００５９】
サービスレベルの管理は、通信センター２３４において発生するすべての動作に係る、エージェントレベルからグローバルな概観までに及ぶリアルタイムなレポートの実行を含むことができる。通信センターの管理者はまた、最初の試みで送信に失敗した電子メール又はファックス送信等の通信を再送信するように、通信センター２３４を構成することもできる。通信センターの管理者はまた、通信のタイプ、通信の緊急性又は重要性、もしくは通信を発する顧客に基づいて呼のルーティングの優先度を設定することが可能であり、また、エージェント又は作業グループにその処理能力を超えるより多くの通信が殺到する場合のオーバーフロー手順を構成することができる。
【００６０】
当然ながら、通信センターの管理者によって実行される動作のすべては、管理マネージャアプリケーション２２４を用いて遠隔の場所から実行可能である。アプリケーションサーバ２０６を遠隔から構成する能力は、管理者がサイト上にいる必要がないので、応答時間を増大させ、またコストを低下させることができる。
【００６１】
図７に、管理マネージャアプリケーション２２４に関連付けられることが可能な例示的なＧＵＩ７００のスクリーンショットを示す。ＧＵＩ７００は、管理者が、オプションツールバー２０４におけるオプションのうちから１つを選択することにより、アプリケーションサーバ２０６の構成に使用される情報、リソース又は機能に遠隔からアクセスすることを許容するように構成されたオプションツールバー７０４を含むことが可能である。図７の例では、ＧＵＩ７００はまた表示領域７０６を含み、管理マネージャ２２４は、この表示領域７０６において、オプションツールバー７０４において選択されるオプションに関連した情報及び制御を表示するように構成されることが可能である。ＧＵＩ７００はまた、管理者がアプリケーションサーバ２０６の機能動作を構成しようとする際の対象である特定の顧客に関連した情報等の、情報を表示するように構成される状態バーを有することが可能である。
【００６２】
以下の段落では、例示を目的として、ウェブサーバ２１６等のウェブサーバ上にロードされることが可能なアプリケーションの機能編成について、図８乃至１７に関連して説明する。図８は、ウェブゾーン８０４内にウェブサーバ８１０を含む、もう１つの実施形態に係る分散型通信センター８００を示す。ウェブサーバ８１０及びウェブゾーン８０４は、図２に示すウェブサーバ２１６及びウェブゾーン２０２と同様のものであることが可能であるが、通信センター８００の分散的な性質に起因してウェブサーバ８１０は任意の場所に設けられてもよいこと、すなわちウェブサーバ８１０は必ずしもネットワークゾーン８０２と同じ場所に収容される必要のないことは、覚えておかれる必要がある。
【００６３】
ある特定の実装において、ウェブサーバ８１０は、以下のソフトウェア、すなわち、Ａ）ＢＥＡシステムズ，インコーポレイテッド（BEA System, Inc.）のウェブロジック（WebLogic：登録商標）製品等の市販のウェブサーバソフトウェアと、Ｂ）ウェブサーバ８１０からダウンロードされることが可能な、図４、図６及び図７に示したもののようなＧＵＩアプリケーションと、Ｃ）以下の段落でそのいくつかについて説明する他のソフトウェア及びアプリケーションとがロードされた、サン・マイクロシステムズ・インコーポレーテッド（Sun Microsystems, Inc.）のコンピュータを備えることが可能である。上記他のソフトウェア及びアプリケーションは、ウェブサーバ８１０が、例えば、通信センター８００の通信センター人員の端末８３０又は顧客端末と、電話サーバ８４６及びアプリケーションサーバ８４８との間のリアルタイムの通信リンクであることが可能になるように、ウェブサーバ８１０の能力を拡張するために使用可能なソフトウェアアプリケーションである「サーブレット」を含むことが可能である。
【００６４】
図８で分かるように、ウェブサーバ８１０は、インターネット８４２を介して遠隔の端末８３０とインターフェースをとり、また、有線ＬＡＮ又は無線ＬＡＮであることが可能なＬＡＮ８４４を介してネットワークゾーン８０２に接続されることが可能である。それに代わって、ＬＡＮ８４４は、通信センター８００の実装と分散度に依存して、無線ＷＡＮを含む何らかの形式のＷＡＮで置き換えられる場合もある。
【００６５】
ウェブサーバ８１０は、以下のものを含む複数の機能アプリケーションを備えることが可能である。
【００６６】
１）図９及び１０でより詳しく説明している、通信センター８００のリソースを遠隔から利用する試みを認証するように構成されることが可能な、ユーザセッションハンドラアプリケーション８１６。
２）図１１及び１２でより詳しく説明している、遠隔の端末８３０の状態を電話サーバ８４６及びアプリケーションサーバ８４８へ中継するように構成されることが可能な、リアルタイムのユーザ状態送信アプリケーション８２０。
３）図１３及び１４でより詳しく説明している、電話サーバ８４６及びアプリケーションサーバ８４８の状態を遠隔の端末８３０へ中継するように構成されることが可能な、リアルタイムのユーザ状態受信アプリケーション８２２。
４）図１６でより詳しく説明している、非リアルタイム通信の状態を、データベースインターフェースアプリケーション８２４を介して管理マネージャ４８３とシステムのデータベースサーバ８５０との間で中継し、ＦＴＰインターフェースアプリケーション８２６を介して管理マネージャ４８３とファイルサーバ８５４との間で中継するように構成されることが可能な、非リアルタイムのシステム状態送信／受信アプリケーション８１４。
５）遠隔の端末８３０とデータベースサーバ８５０とのインターフェースをとるように構成された、データベースインターフェースアプリケーション８２４。
６）遠隔の端末８３０とファイルサーバ８５４とのインターフェースをとるように構成された、ＦＴＰインターフェースアプリケーション８２６。
７）図１７でより詳しく説明している、遠隔の端末８３０からのデータベース要求及びファイル要求を処理するように構成された、遠隔のデータベース／ファイルハンドラアプリケーション８１２。
８）図１８でより詳しく説明している、ウェブサーバ８１０とネットワークゾーン８０２を含むさまざまな構成要素との間の通信を管理するように構成された、バスサーバアプリケーション８２８。実際には、バスサーバアプリケーション８２８は、図８に示すように、ネットワークゾーン８０２の構成要素又はホストの各々に含まれる場合もある。バスサーバアプリケーション８２８については、後により詳しく説明する。
【００６７】
遠隔の端末８３０上で実行されるアプリケーション、例えば、対話マネージャアプリケーション８４０、監督マネージャアプリケーション８３８、チャットマネージャアプリケーション８３６、管理マネージャアプリケーション８３４、及び遠隔のデータベース／ファイル捕捉マネージャアプリケーション８３２は、ウェブサーバ８１０上で実行されるアプリケーションとの間でインターネット８４２を介して通信し、例えば、ＨＴＴＰＳを用いて例えばポート４４３上で通信し、及び／又はＨＴＴＰを用いて例えばポート８０上で通信するように構成されることが可能である。「ポート」とは、ネットワークに出入りするポイントである。例えば、最も一般的なポートのうちの２つが、事実上あらゆるコンピュータに含まれるパラレルポート及びシリアルポートである。ポート番号は、とりわけ、ポートへのアクセスを有しうるリソースのタイプや、そのポートを介して実行される通信が暗号化されるか否かなどといったことを画定するために使用される場合が多い。
【００６８】
先に説明したように、遠隔の端末のアプリケーションは、ウェブゾーン８０４及びネットワークゾーン８０６とのリアルタイム通信の維持を必要とする場合がある。例えば、対話マネージャアプリケーション８４０が電話呼又はチャット等のリアルタイム通信の管理に携わっている場合、その通信に対してはリアルタイム制御リンクが好適である。このようなリアルタイム通信を維持するためには、ウェブサーバ８１０との永続的な非ブロッキング接続の維持を必要とする場合がある。ＨＴＴＰポートへの非ブロッキング接続の優位点は、ウェブサーバ８１０からの応答が受信されていなくても、そのポートに送信される追加メッセージのために接続を再確立する必要はないということにある。さらに、新たに接続するとその度に７秒もの時間を要する可能性があり、このことはリアルタイムの通信システムには許容できないことであるので、永続的な接続は、ウェブサーバ８１０との接続を確立するために要する時間を短縮することができる。ｗｗｗ．ｉｎｎｏｖａｔｉｏｎ．ｃｈによって公開されているもののようなＨＴＴＰクライアントは、ＧＥＴ、ＰＯＳＴ及びＰＵＴのような要求方法と、認証、リダイレクション要求及びクッキーの自動処理とを含むＨＴＴＰ  １．１プロトコルの関連した部分のほとんどを、永続的な非ブロッキング法で実装する。従って、アプリケーションに依存して、通信センター８００においてこのようなＨＴＴＰクライアントを使用することが好適である場合がある。
【００６９】
図９は、ここに記載したシステム及び方法に従って構成されたユーザセッションハンドラアプリケーション８１６の例示的なプロセスフローを示すフローチャートである。ユーザセッションハンドラアプリケーション８１６は、ウェブサーバ８１０上でユーザセッションの生成及び終了を管理するように構成されることが可能である。従って、遠隔の通信センターの人員が端末８３０を用いてウェブサーバ８１０に最初にアクセスするとき、ユーザセッションハンドラアプリケーション８１６は、ログオン及びセッション生成の機能を管理することができる。よって、図９に示すプロセスは、ステップ９０２で、端末８３０から受信されるログインメッセージを受信することによって開始することができる。
【００７０】
ステップ９０２でログインメッセージが受信されると、ユーザセッションハンドラアプリケーション８１６は、ステップ９０４で、ログインメッセージに含まれたユーザ識別情報を格納するように構成されることが可能である。次にステップ９０６において、ユーザセッションハンドラアプリケーション８１６は、ウェブサーバ８１０上でユーザセッションを生成するように構成されることが可能である。ステップ９１０において、このユーザセッションに関連した情報が、ユーザセッションハンドラアプリケーション８１６によって追跡されることが可能である。
【００７１】
ユーザセッションハンドラアプリケーション８１６は、ステップ９１２でログアウトメッセージが受信されるまで、ユーザセッションに関する情報の追跡を継続するように構成されることが可能である。ステップ９１２でいったんログアウトメッセージが受信されると、ユーザセッションハンドラアプリケーション８１６は、ステップ９１４でユーザセッションを切断し、ステップ９０２で別のログインメッセージを待機するように構成されることが可能である。ただし実際には、ウェブサーバ８１０は、同時に存在するいくつかのユーザセッションをホスティングする場合が多く、よって別のセッションを開始する前に１つのセッションを終了させる必要はない。
【００７２】
図１０は、ウェブサーバ８１０上で実行され、かつ図９に示すプロセスを実装するように構成された例示的なユーザセッションハンドラアプリケーション８１６の機能ブロックを示す。従って、ユーザ動作が発生すると、端末８３０上で実行されるアプリケーションは、ウェブサーバ８１０上で実行されているアプリケーションのＵＲＬへメッセージをポスティング（ＰＯＳＴ）することができる（ステップ９０２）。このようなＰＯＳＴメッセージは、ユーザ名、ユーザのパスワード、及び企業の別名等の、メッセージに埋め込まれたユーザ識別情報を含むことが可能である。
【００７３】
「ユーザ」という用語は、端末８３０を用いてウェブサーバ８１０にアクセスする、例えばエージェント、スーパーバイザ及び管理者である遠隔の通信センターの人員を示すように使用されていることは留意されるべきである。ある例では、この用語は顧客を示す場合もある。
【００７４】
ウェブサーバ８１０は、ユーザ識別情報をＨＴＴＰオブジェクト１００２の形式で格納する（ステップ９０４）ように構成されることが可能であり、プロキシのディスパッチハンドラ１００４は、ここからユーザ識別情報を照会しかつ抽出することができる。例えば、ユーザが、端末８３０上に表示されるログインジャバサーバページ（ＪＳＰ）において、当該ユーザのユーザ名とユーザパスワードと企業の別名の情報を入力し、ＯＫをクリックすると、その後、この情報は、プロキシのディスパッチハンドラ１００４のＵＲＬへ送信されることが可能であり、プロキシのディスパッチハンドラ１００４は、次にこの情報をプロキシのログインハンドラ１００６へ転送することができる。プロキシのログインハンドラ１００６は、ユーザ識別情報を照合するために、データベースインターフェースアプリケーション８２４を介してデータベース８５２に照会することができる。最初の照会では、ユーザの企業ＩＤを検索することができる。この情報を用いて、プロキシのログインハンドラ１００６からの第２の照会で、そのユーザに関する構成及び他の情報（例えば、実際のユーザパスワード、当該ユーザが属する作業グループ、など）を取り出すことができる。最後に、プロキシのログインハンドラ１００６は、ユーザにより提示されたパスワードが正しいか否かをチェックするように構成されることが可能である。ユーザにより提示されたユーザ名、パスワード及び企業の別名の組み合わせが正しくなければ、端末８３０上にエラーメッセージを表示することができる。
【００７５】
提示されたユーザ識別情報の正しさが確認されると、プロキシのログインハンドラ１００６は、（ユーザ）セッションオブジェクト１０１０を生成し（ステップ９０６）、ユーザセッションが持続する間に、関連したすべてのユーザセッション情報を追跡する（ステップ９１０）ように構成されることが可能である。セッションオブジェクト１０１０は、例えば一意的な６４ビットのセッションＩＤを含むことが可能である。ウェブサーバ８１０はまた、遠隔の端末８３０との間の各接続に関連した情報を追跡するウェブセッションオブジェクト１０１２を保持するように構成されることも可能である。ウェブサーバ８１０は、ウェブセッションオブジェクト１０１２からセッションＩＤを参照することができる。参照は、メモリ内のオブジェクトに係るメモリアドレスのジャバ（Ｊａｖａ）名である。
【００７６】
ユーザがログアウトを要求すると（ステップ９１２）、プロキシのログアウトハンドラ１００８は、セッションオブジェクト１０１０のタスク消去プロセスを呼び出すように構成されることが可能であり、このプロセスにより、セッションオブジェクト１０１０は効果的に消滅し（ステップ９１２）、ウェブセッションオブジェクト１０１２からセッションオブジェクト１０１０への参照が無効にされる。プロキシのログアウトハンドラ１００８はまた、電話サーバ８４６及びアプリケーションサーバ８４８からの未処理のユーザ応答を含むユーザのセッションメールボックス１４０６（図１４を参照）を空にすること、セッションに関連付けられた、例えばレコーディング、電子メール、プロンプトなどの一時的なディレクトリを削除すること、及びインターネットハンドラ機能へログアウトメッセージを送信することも可能である。これはまた、端末８３０を、ウェブサーバ８１０上のログアウトページへ向かわせることもできる。
【００７７】
図１１は、ここに記載したシステム及び方法に従って構成されたユーザ状態送信アプリケーション８２０のための例示的なプロセスフローを示すフローチャートである。通信を制御するユーザセッションを確立すると（ステップ９０６）、その後、ユーザは、ウェブサーバ８１０へ動作要求メッセージを送信することができる。これらの動作要求は、ユーザ状態送信アプリケーション８２０によって処理されることが可能である（図８を参照）。従って、ステップ１１０２において、ユーザ状態送信アプリケーション８２０は動作要求メッセージを受信することができる。このようなメッセージは、上述のような識別情報を含むことが可能であり、またさらに動作要求を含むことも可能である。ステップ１１０４では、ステップ１１０２で受信されたメッセージから動作要求が抽出される。抽出された動作要求は、次にステップ１１０６において、処理を待機するためにキュー（待ち行列）に格納されることが可能である。動作要求は次に、ステップ１１０８で、キューにおいて検索して読み出されることが可能である。動作要求は、例えばバスサーバアプリケーション８２８によって検索して読み出されることが可能であり、また、ステップ１１１０において、例えば電話サーバ８４６又はアプリケーションサーバ８４８等のネットワークゾーン８０２へ転送されることが可能である。
【００７８】
動作要求メッセージは、実際には顧客によって発生されることも可能である。この場合もやはり、動作要求が抽出されてキューに格納されることが可能であり、動作要求は、このキューから必要に応じて検索して読み出され、ネットワークゾーン８０２へ転送されることが可能である。
【００７９】
図１２は、ウェブサーバ８１０上で実行され、かつ図１１に示したプロセスを実装するように構成された例示的なユーザ状態送信アプリケーション８２０の機能ブロックを示す。ユーザは、例えば、ＧＵＩ４００、６００及び７００等のＧＵＩを用いて、「ダイヤル」、「保留」、「転送」、「指示」及び「送信」等のボタンを押すことができる。これらの動作は、ユーザ状態送信アプリケーション８２０によって受信される（ステップ１１０２）、動作要求メッセージを生成する。実際には、端末８３０からウェブサーバ８１０へ（及びこの逆に）送信される複数の命令及びデータ／応答が存在する可能性がある。上述の動作は単なる例示に過ぎない。
【００８０】
ユーザが、ある動作を、例えば当該ユーザのＧＵＩ上で実行すると、ユーザのアプリケーションは、ユーザ動作を含む要求オブジェクトを有するＰＯＳＴメッセージを、プロキシの動作ハンドラ１２０４のＵＲＬへ送信することができる。ウェブサーバ８１０は、上記要求オブジェクトをＨＴＴＰオブジェクト１２０２へ変換するように構成されることが可能である。プロキシの動作ハンドラ１２０４は次に、ＨＴＴＰオブジェクト１２０２から動作要求の部分を抽出し（ステップ１１０４）、これをメッセージ送信者オブジェクト１２０６の送信者キュー（又はキューメモリ）１２０８に格納する（ステップ１１０６）ように構成されることが可能である。格納された動作要求は次に、バスサーバアプリケーション８２８によって検索して読み出され（ステップ１１０８）、必要に応じてネットワークゾーン８０２へ送信される（ステップ１１１４）ことが可能である。
【００８１】
先に述べたように、通信センター人員の動作要求に加えて、実装に依存して顧客らもまた、リアルタイムの動作要求をウェブサーバ８１０へ送信することができる。例えば、顧客らは、例えば当該顧客らの名前及び電話番号を含むことが可能な、ウェブコールバック要求を開始することができる。このウェブコールバック要求に基づいて、通信センター８００は例えば、利用可能な適切なエージェントを選択し、このエージェントを呼び出し、顧客を呼び出し、さらに、エージェントが顧客を支援できるように両方の呼を中継するように構成されることが可能である。また、サードパーティーのアプリケーションもウェブサーバ８１０を使用することができる。例えば、端末８３０上で実行されるサードパーティーのアプリケーションは、ウェブサーバ８１０を用いて電話をかけることができる。これらのタイプの動作要求は、例えば、プロキシのダイヤルハンドラ１２１０又はプロキシのウェブコールバックハンドラ１２１２へ送信されることが可能であり、これらは、顧客又はサードパーティーのアプリケーションの動作要求を、上述の同じ送信者キュー１２０８へ転送することができる。
【００８２】
プロキシの動作ハンドラ１２０４は、所定の実装では、ユーザの動作要求に応答するように構成されることが可能である。他の実装では、応答機能は、プロキシのｐｉｎｇ（ピング）ハンドラ１４０４（図１４を参照）に委ねられる（代行される）場合がある。プロキシのｐｉｎｇハンドラ１４０４は、図１４に示すようにユーザ状態受信アプリケーション８２２の一部であってもよく、又はユーザ状態受信アプリケーション８２２とは別個のものであってもよい。従って、プロキシの動作ハンドラ１２０４は、動作要求への応答に使用されるようにユーザのセッションＩＤをプロキシのｐｉｎｇハンドラ１４０４へ送信するように、構成されることが可能である。
【００８３】
図１３は、ここに記載したシステム及び方法に従って構成された例示的なユーザ状態受信アプリケーション８２２のプロセスフローを示すフローチャートである。端末８３０によって発生された動作要求に応答して、顧客らは、又は例えば電話サーバ８４６やアプリケーションサーバ８４８であるサードパーティーのアプリケーションは、メッセージを生成して、端末８３０上で実行されているアプリケーションへ上記メッセージを送信することができる。図１３のフローチャートは、これらのメッセージを生成できるようにするプロセスの一例を示す。
【００８４】
まずステップ１３０２において、動作要求が、例えばプロキシの動作ハンドラ１２０４によって受信される。図１１で説明しているように、受信された動作要求は、要求されればステップ１１１０においてネットワークゾーン８０２へ転送されることが可能である。ネットワークゾーンは次に、応答又はメッセージが要求された場合に、ステップ１３０４において、受信された動作要求に応答してメッセージを生成することができる。いったん動作要求に応答してメッセージが生成されると、これは、動作要求を生成する端末８３０へ転送されることが可能である。図１３の例示的なプロセスフローでは、このことは、ステップ１３０６において、何らかのメッセージが存在するか否かについての照会を特定の端末８３０から受信することを含む。従ってステップ１３０８において、ステップ１３０４で生成されたメッセージは、メッセージを生成した目的となる端末であってかつステップ１３０６で照会を受信した発信元の端末である特定の端末８３０に、転送されることが可能である。当然ながら、ステップ１３０６で照会が受信される時点で待機しているメッセージがなければ、ステップ１３０８では何も転送する必要がない。
【００８５】
図１４は、ウェブサーバ８１０上で実行され、かつ図１１に示したプロセスを実装するように構成された例示的なユーザ状態受信アプリケーション８２２の機能ブロックを示す。図面から分かるように、プロキシのｐｉｎｇハンドラ１４０４は、何らかのメッセージ１４０８が生成されて存在しているか否かについての照会を端末８３０から受信する。メッセージが生成されていれば、これらはウェブサーバ８１０に格納されることが可能である。セッションメールボックス１４０６は、この格納されたメッセージ１４０８にアクセスするために使用可能である。例えば、セッションメールボックス１４０６は、異なる端末８３０又は遠隔の通信センターの人員によってそれぞれ識別される複数のベクトルを備えることが可能である。各ベクトルは、関連付けられた端末８３０に対するメッセージ１４０８が格納されるメモリアドレスを指示することができる。セッションメールボックス１４０６はハッシュテーブルと呼ばれる場合もあり、プロキシのｐｉｎｇハンドラ１４０４は、セッションＩＤを用いて、セッションメールボックス１４０６であるハッシュテーブルにアクセスするように構成されることが可能である。さらに、メッセージ１４０８は、実装に依存して、ベクトルそのものの形式であってもよい。
【００８６】
プロキシのｐｉｎｇハンドラ１４０４は次に、セッションメールボックス１４０６から取得されたベクトルを用いて、特定の端末８３０に対する全メッセージを検索して読み出し、これらを上記特定の端末８３０へ転送することができる。検索して読み出されるメッセージ１４０８は、例えばバイトアレイの形式であってもよく、又はＴＣＰ／ＩＰストリームの形式であってもよい。
【００８７】
上述のプロセスは「ｐｉｎｇプログラム実行方法」と呼ぶことが可能であり、すなわち、端末８３９は、プロキシのｐｉｎｇハンドラ１４０４に周期的にｐｉｎｇ信号を送信し（照会を行い）、各ｐｉｎｇ信号に応答して、格納された任意のメッセージを受信する。しかしながら、従来のｐｉｎｇプログラム実行方法は非効率的である場合がある。例えば、図１５Ａは従来のｐｉｎｇプログラム実行方法を示す。まず、プロキシの動作ハンドラ１２０４は、先に述べたように端末８３０から動作要求を受信する。次にプロキシの動作ハンドラ１２０４は、プロキシのｐｉｎｇハンドラ１４０４へ転送される応答代行メッセージを生成する。プロキシの動作ハンドラ１２０４が代わりに応答を処理するように構成される場合もあるということは覚えておく必要がある。プロキシのｐｉｎｇハンドラ１４０４は次に、端末８３０から周期的にｐｉｎｇ信号を受信する。プロキシのｐｉｎｇハンドラ１４０４は各ｐｉｎｇ信号に応答し、この応答は、各応答によって検索して読み出された任意のメッセージを含む。ｐｉｎｇ信号の送信周期が短い場合、例えば２秒毎である場合には、図１５Ａに示したｐｉｎｇプログラム実行方法は、過剰な量のメッセージトラフィックを発生させる可能性がある。
【００８８】
図１５Ｂのｐｉｎｇプログラム実行方法は、このトラフィックのいく分かを緩和するために使用されることが可能である。図１５Ｂでは、プロキシの動作ハンドラ１２０４は動作要求を前のものと同様に受信する。ただし、プロキシの動作ハンドラ１２０４は、応答代行メッセージを生成する代わりに、実装に依存して単に「ヌル応答」で応答するか又はまったく応答を生成しない。端末８３０は、この場合も前と同様にプロキシのｐｉｎｇハンドラ１４０４に対してｐｉｎｇ信号を送信するように構成されるが、プロキシのｐｉｎｇハンドラ１２０４は、各ｐｉｎｇ信号に応答する代わりに、ｐｉｎｇ信号を送信する端末８３０に対して生成される何らかのメッセージのための設定可能（又は設定変更可能）な時間期間だけ、例えば６０秒又はそれ未満の間だけ待機するように構成される。ウェブサーバ８１０上に存在するメッセージがあれば、プロキシのｐｉｎｇハンドラ１４０４はこれらを直ちに転送し、次いで同じ端末８３０から別のｐｉｎｇ信号を受信することが可能である。上記設定可能な時間期間内にメッセージが存在しなければ、この設定可能な時間期間が経過するまで応答を送信しない。従って、プロキシのｐｉｎｇハンドラ１２０４は、上記設定可能な時間期間が満了するまで同じ端末から別のｐｉｎｇ信号を受信することはない。このようにして、より高いメッセージ送信効率を達成しながら、同レベル又はより高いレベルの応答性を達成することができる。
【００８９】
図１６は、ウェブサーバ８１０上で実行され、かつ端末８３０からの非リアルタイムなコマンドを処理するように構成された、例示的な非リアルタイムのシステム状態送信／受信アプリケーション８１４の機能ブロックを示す。このようなコマンドは、基本的には、通信センター８００の構成データの追加、削除及び／又は変更よりなる場合が多い。ユーザが構成データの変更を行うと、プロキシのディスパッチハンドラ１００４は、例えば、必要な場合に新しいＪＳＰをユーザに提示するように構成されることが可能である。所定の実施形態では、変更又は新しい構成データは、プログラミングを行うことなく、パラメータの形式で入力されることが可能である。言い換えれば、変更又は新しいデータはいずれも、単に管理マネージャのＧＵＩ７００を介して入力され、次に、通信センター８００を自動的に構成して変更を実装するように構成されたネットワークゾーン８０２へアップロードされる。
【００９０】
従って、変更又は新しいデータは、データベース８５２等のシステムデータベースから入力される／閲覧される必要がある。よって、このような要求はいずれも、端末８３０からデータベースインターフェースアプリケーション８２４へ転送されることが可能である。データベースインターフェースアプリケーション８２４については詳細後述する。ユーザが、例えばメール、ファックス応答、ＩＶＲプロンプト、挨拶メッセージなどのシステム状態ファイルをアップロードする場合、プロキシのディスパッチハンドラ１００４は、ユーザ状態送信アプリケーション８２０内のメッセージ送信者キューにメッセージを追加するように構成されることが可能である。追加されたメッセージは、このようなファイルがＦＴＰインターフェースアプリケーション８２６を介してファイルサーバ８５４へ転送されつつあるということと、システム内のホストがそのように構成されていればファイルサーバ８５４からファイルを検索して読み出すことができるということとを、当該システム内の全ホストに通知することができる。例えば、すべての電話サーバ８４６は、それらが電話呼を受信する際により迅速に音声の挨拶メッセージを検索して読み出すことができるように、当該音声の挨拶メッセージへのローカルなアクセスを有することが望ましいという可能性がある。
【００９１】
データベースインターフェースアプリケーション８２４は、設定可能なデータベースサーバ８５０との通信専用のウェブサーバオブジェクトであることが可能な、データベースプールを備えることが可能である。専用の通信は、例えば利用されるデータベースソフトウェア製品の種類に依存して、専用のポートで発生する可能性がある。アプリケーションがデータベースサーバ８５０との通信を必要とする場合、アプリケーションは、例えばＪａｖａデータベース接続（ＪＤＢＣ）等の要求されたドライバをロードするように、ウェブサーバ８１０に求めることができる。これらのドライバは、アプリケーションがデータベースサーバ８５０と通信するために借りることができる複数の接続にてなるプールを管理するように構成されることが可能である。
【００９２】
ユーザらは、ウェブサーバ８１０を介して、ネットワークゾーン８０２へファイルをアップロードし、ネットワークゾーン８０２からファイルをダウンロードする必要のある場合がある。従って、図８に示すように、ウェブサーバ８１０上にはＦＴＰインターフェースアプリケーション８２６を含むことが可能である。ＦＴＰインターフェースアプリケーション８２６は、ネットワークゾーン８０２におけるホストすなわち構成要素からファイルをあちこちに移動させるために使用可能な、ＧＥＴ及びＰＵＴ等のリソースを提供するように構成されることが可能である。ＦＴＰインターフェースアプリケーション８２６は、ファイルを１つのサーバから別のサーバへ移動させることに加えて、ファイルの移動に関連付けられた重要な統計情報のログをデータベース８５２に記録するように構成されることも可能な、Ｊａｖａ  ＦＴＰクラスのインスタンス化であることが可能である。
【００９３】
これらに関しては、ネットワークゾーンのホストは、ファイルの受信／送信を可能にする組み込み型のＦＴＰ機能を有するオペレーティングシステムのソフトウェアを備えることが可能である。例えば、ユーザは、管理マネージャのＧＵＩ７００を用いて、顧客が通信センター８００を呼び出すと再生される、例えば「こんにちは、…へようこそ」又は「販売に関しては、１を押して…」等の挨拶メッセージをアップロードすることができる。このような挨拶メッセージを含むファイルは、例えば何らかの種類のＰＯＳＴ  ＨＴＴＰメッセージを用いてウェブサーバ８１０へアップロードされることが可能である。ここから、上記ファイルは、ＦＴＰインターフェースアプリケーション８２６により複数の電話サーバ８４６へ配信されることが可能である。次に、電話サーバ８４６は、関連付けられた電話番号に顧客の呼が着信したときに、挨拶メッセージを再生するように構成されることが可能である。
【００９４】
さらに、例えば、コールセンターのスーパーバイザは、当該スーパーバイザの監督マネージャのＧＵＩ６００を用いて、エージェントと顧客の会話を記録することが可能であり、また、スーパーバイザは、記録された会話を再生して検査することを希望してもよい。記録は、例えば、エージェントと顧客との間の通信をホスティングした電話サーバ８４６において実行されることが可能である。スーパーバイザが記録を聴く場合、ＦＴＰインターフェースアプリケーション８２６を用いて、記録されたファイルを電話ホスト８４６からウェブサーバ８１０へ移動させることが可能であり、上記ファイルはウェブサーバ８１０からスーパーバイザの端末８３０へ順次ダウンロードされることが可能である。
【００９５】
いくつかの状況では、例えばプライバシーを理由として、通信センター８００によってホスティングされる企業は、データ及び情報を通信センター８００に格納することに代えて、もしくはこれに加えて、上記データ及び情報のいく分か又はすべてを企業のシステム上に格納するように希望する場合がある。このことを達成するために、図８に示すように、ウェブサーバ８１０内に遠隔のデータベース／ファイルハンドラアプリケーション８１２を含むことができる。図１７は、ウェブサーバ８１０上で実行される、例示的な遠隔のデータベース／ファイルハンドラアプリケーション８１２の機能ブロックを示す。実装されると、例えば、ユーザが、利用可能なシステムファックス、例えば予め構成されたシステムファックスのリストを見ることを希望すれば、当該ユーザの対話マネージャアプリケーション８４０は、当該ユーザの端末８３０に含まれたローカルなデータベース１７１０に気付くことが可能である。上記ローカルなデータベース１７１０は、この場合は実際にそれ自体がサーバであることも可能である。対話マネージャ８４０は、システムのデータベース８５２ではなくローカルなデータベース１７１０に照会するように構成されることが可能であり、このこともまたシステムの性能を大幅に向上させることができる。これは、対話マネージャ８４０が、照会を実行するためにウェブゾーン８０４を介してネットワークゾーン８０２へと進み、そして再び戻ってくることを必要としないからである。
【００９６】
遠隔の端末８３０はまた、ウェブサーバ８１０上に含まれたプロキシの遠隔のＤＢハンドラ１７０２にｐｉｎｇ信号を送信して接続を認証しかつセッションを確立するように構成されることが可能な、遠隔の記憶装置ハンドラ１７０８を含むことが可能である。認証及びセッションの確立に続いて、遠隔の記憶装置ハンドラ１７０８は、ウェブサーバ８１０に対して周期的にｐｉｎｇ信号を送信して、任意の企業のユーザ／クライアントの通信に関する、例えば上記通信の発生時間、継続時間、コンタクト情報などの状態の更新情報を取得するように構成されることが可能である。プロキシの遠隔のＤＢハンドラ１７０２は、ｐｉｎｇプログラムにより送信されたｐｉｎｇ信号に応答し、データベースインターフェースアプリケーション８２４を介して情報を取得するように構成されることが可能である。遠隔の記憶装置ハンドラ１７０８は、次にその情報をその企業のローカルなデータベース１７１０に格納するように構成されることが可能である。検索して読み出された企業情報が、例えば取引同意の記録、ファックス、電子メールなどの関連付けられたファイルを有している場合、遠隔の記憶装置ハンドラ１７０８は、プロキシの遠隔のファイルハンドラ１７０４に対してｐｉｎｇ信号を送信してそのファイルを取得するように構成されることが可能である。プロキシの遠隔のファイルハンドラ１７０４は、ｐｉｎｇプログラムにより送信されたｐｉｎｇ信号に応答し、ＦＴＰインターフェースアプリケーション８２６を介してこのような任意のファイルを取得するように構成されることが可能である。遠隔の記憶装置ハンドラ１７０８は、次にこのファイルを例えばデータベース１７１０内の設定された場所に格納することができる。
【００９７】
ウェブサーバ８１０の上と、ネットワークゾーン８０２のさまざまな構成要素の上で実行されるように構成されることが可能なバスサーバアプリケーション４２８は、さまざまな構成要素が互いにリアルタイムで通信し、またさまざまな構成要素がウェブサーバ８１０とリアルタイムで通信することを可能にする上で重要である可能性がある。図１８は、バスサーバの動作を理解し易くするために提示したものである。図１８は、バスサーバアプリケーション１８１２の動作を示す論理ブロック図である。図１８が示す例には３つのホスト１８０２、１８０４及び１８０６が存在し、その各々が固有のバスサーバアプリケーション１８１２を有している。ホスト１８０２、１８０４及び１８０６は、例えば、ウェブサーバ８１０、電話サーバ８４６及びアプリケーションサーバ８４８であることが可能であるが、ホストは、複数のホストがネットワーク１８１８を介して互いにインターフェースをとっている任意のタイプの通信システムにおける、任意のタイプのホストであることも可能である。ネットワーク１８１８は、例えばＬＡＮであることが可能である。
【００９８】
まず、１つのバスサーバアプリケーション１８１２が自動的に開始されることが可能である。ここで、例えば、ウェブサーバが、その設定された起動プロセスの一部として、１つのバスサーバアプリケーション１８１２を開始することが可能であり、もしくは、アプリケーション又は電話ホストのオペレーティングシステムが、バスサーバアプリケーション１８１２がインストールされた後に、インストールされたバスサーバアプリケーション１８１２を１つのサービスとして開始することができる。ある実施形態では、最初に開始されるバスサーバアプリケーション１８１２は、例えば図１８におけるホスト１８０２のような複数のリソースを管理するように構成されたホスト上に存在する。
【００９９】
バスサーバアプリケーション１８１２はまた、例えばネットワークマネージャアプリケーション１８０８を介してまず手動で開始されることも可能である。ネットワークマネージャアプリケーション１８０８はまた、例えばアプリケーション１８１０、１８１４及び１８１６のような、システム内のいずれかの場所に存在する他のアプリケーションを開始するように構成されることも可能である。
【０１００】
特に分散型通信ネットワークである通信ネットワークでは、所定のホスト上の所定のアプリケーションがある言語で書かれる一方、他のホスト上の他のアプリケーションが別の言語で書かれていてもよい。例えば、アプリケーション１８０８、１８１０及び１８１４はＣ＋＋プログラミング言語で書かれることが可能である一方、アプリケーション１８１６はＪａｖａで書かれることが可能である。多くの場合、このことは、通信に問題を発生させる可能性がある。この問題を緩和するために、バスサーバアプリケーション１８１２は、ＬＡＮ１８１８を介したすべてのバス間通信及びアプリケーション間通信のためにＴＣＰ／ＩＰを使用するように構成されることが可能である。異なる言語で書かれたアプリケーションに関して発生する固有のネイティブ通信上の問題点は、こうして克服されることが可能である。
【０１０１】
「ネイティブ通信」という用語は、１つのアプリケーションが別のアプリケーションの方法又はプロセスを「呼び出す」という状況を記述するために使用される。２つのアプリケーションが異なる言語で書かれていれば、ネイティブ通信は妨げられる可能性がある、すなわち、ネイティブ通信問題が存在する。ネイティブ通信問題の克服は、通信センター８００の実装にとって特に重要である可能性がある。その理由は、ウェブサーバ８１０等のウェブサーバは、Ｊａｖａで書かれたコードが支配的なアプリケーションを備える場合が多い一方、電話サーバ８４６及びアプリケーションサーバ８４８は、Ｃ＋＋で書かれたコードが支配的なアプリケーションを備える場合が多いからである。従って、上述したＴＣＰ／ＩＰのバス間構成は、ネイティブ通信問題を克服する手助けとなりうることから、通信センターのアプリケーションにとって好適である可能性がある。
【０１０２】
複数のバスサーバアプリケーション１８１２は、ＬＡＮ１８１８を介して、又は、例えばポート９００１上で、他の何らかのＩＰネットワークを介して、互いに通信するように構成されることが可能である。各バスサーバアプリケーション１８１２が互いに登録した後で、これらは、所定のソケットを用いてペアになって通信するように構成されることが可能である。登録は、複数のバスサーバアプリケーションが、例えばホスト１８０２、１８０４又は１８０６等のホスト上で実行される例えばアプリケーション１８０８、１８１０、１８１４又は１８１６等のアプリケーションの通信上のニーズを当該バスサーバアプリケーションが管理していることについて互いに通知する際に使用されるプロセスである。ＩＰでは、ソケット番号が、互いの通信のために、複数のアプリケーションにてなるセットに割り当てられた仮想的なチャンネルを識別する。
【０１０３】
バスサーバアプリケーション１８１２によって実装されることが可能な登録形式の１つは、マルチキャスト登録である。マルチキャスト登録では、各ホスト１８０２、１８０４及び１８０６が、ネットワーク内のどのホストにも一致しない予め確立されたネットワークＩＰアドレスへの接続を確立する。各バスサーバアプリケーション１８１２は、次に、例えばその名前、ホスト名及びホストのＩＰアドレスを、予め確立されたネットワークＩＰアドレスへ送信することにより、それ自体を識別するように構成されることが可能である。バスサーバアプリケーション１８１２は、次に、他のバスサーバアプリケーション１８１２がそれらの情報を送信することによりそれら自体を識別することを待機するように構成されることが可能である。登録を行う最初のバスサーバアプリケーション１８１２は、それが最初に登録することにより、他のバスサーバアプリケーション１８１２から応答を受信することはない。しかしながら、登録を行う２番目のバスサーバアプリケーション１８１２は、最初に登録したバスサーバアプリケーション１８１２から識別応答を受信するはずである。第３のバスサーバアプリケーション１８１２は最初の２つのアプリケーションから応答を受信するはずである。以下同様に続く。
【０１０４】
代替として、バスサーバアプリケーション１８１２には、ユニキャストバス登録方式が実装される場合もある。この場合、各バスサーバアプリケーション１８１２は、登録されたすべてのバスサーバアプリケーション１８１２を、又はバスサーバアプリケーション１８１２を備えるホストを、データベースで探索する。
【０１０５】
バスサーバアプリケーション１８１２がネットワーク内の他のバスサーバアプリケーション１８１２に気付いた後で、これらは互いにソケット接続を確立するように構成されることが可能である。ただし、使用するソケットの個数を最小化することが望ましい可能性がある。従って、発生されるソケット通信の数を最小化するために、より小さい数のＩＰアドレスを有するバスサーバアプリケーション１８１２がより大きな数のＩＰアドレスを有するバスサーバアプリケーション１８１２が動作を実行することを常に待機するか又はその逆のことを行う方式が利用可能である。使用されるソケットの量を減少させる他の方法については、後により詳しく議論する。
【０１０６】
複数のホスト上の複数のバスサーバアプリケーション１８１２がいったん登録すると、これらはＩＰメッセージを用いてＬＡＮ１８１８を介して直接に通信するように構成されることが可能である。さらに、これらは、これらのホスト上に存在するアプリケーションのための通信コンジット（conduit；通信チャンネル）として使用可能である。例えば、ホスト１８０２上に存在するネットワークマネージャアプリケーション１８０８は、ホスト１８０４上のアプリケーション１８１４を開始するように構成されることが可能である。このことを可能にするために、ネットワークマネージャアプリケーション１８０８は、ＩＰメッセージをその対応するバスサーバ１８１２へ送信するように構成されることが可能であり、バスサーバ１８１２は次に、このメッセージを、ホスト１８０４に存在するバスサーバ１８１２へ送信する。後者のバスサーバ１８１２は、次に、受信されたＩＰメッセージに応答してアプリケーション１８１４を生み出すように構成されることが可能である。
【０１０７】
例えば上で説明したばかりのアプリケーションを開始するには、直接的なアプリケーション間通信が利用可能であるが、大規模ネットワークでは、利用可能なソケットが急速に減少するか、もしくは必要なソケット数が極端に多くなる。言い換えれば、１つのホスト上のアプリケーションが別のホスト上のアプリケーションと通信することが必要である度に１つのソケットが専用で提供されるとすると、ソケット数の制限に起因して、そのネットワークはさほど効率よくは動作しなくなる。
【０１０８】
ソケット数の制限に関連付けられた問題点を回避するために、各バスサーバアプリケーション１８１２は、同じホスト上の他のアプリケーションに向かうように意図されたものであれ、異なるホスト上の他のアプリケーションに向かうように意図されたものであれ、同じホスト上で実行される各アプリケーションからのすべての通信を受信するように構成されることが可能である。通信が、別のホスト上のアプリケーションに向かうように意図されたものであれば、バスサーバ１８１２は、ＴＣＰ／ＩＰを用いてＬＡＮ１８１８を介してメッセージをブロードキャストするように構成されることが可能である。従って、ＬＡＮ１８１８上の他のすべてのバスサーバアプリケーション１８１２はブロードキャストメッセージを受信するが、他のバスサーバアプリケーション１８１２は、受信されたメッセージが、それらに関連付けられたホスト上のアプリケーションに向かうように意図されたものでない限り、当該受信されたメッセージを無視する。
【０１０９】
従って、各アプリケーションは、他のホスト上の他の複数のアプリケーションと個々に通信するように強制されるのではなく、ここでは、単に１つのアプリケーションと通信する、すなわちそれに関連付けられたバスサーバアプリケーション１８１２と通信することができる。関連付けられたバスサーバアプリケーション１８１２は次に、そのアプリケーションから受信されたメッセージをＬＡＮ１８１８上でブロードキャストするか、又は、要求に応じて、上記受信されたメッセージを同じホスト上の他のアプリケーションへ向け直すことができる。このようなアプローチは、制限されたソケット利用可能性から発生する帯域幅制限の問題を低減させる手助けになりうる。このタイプのバス方式はまた、後述のホットバックアップのシステム及び方法の見地からも有益である。
【０１１０】
上述のバス方式を実装することは、ネットワークに対する動作オーバーヘッド、メモリ及び帯域幅の必要条件を低減させるものである。これはまた、ネットワークの動作を停止したり、再コンパイルしたり、又はそうでなければ中断させたりすることなく、ネットワーク上に新たなアプリケーションを動的に追加することを可能にする。
【０１１１】
ネットワークマネージャアプリケーション１８０８は、実際に、バスサーバアプリケーション１８１２に依存してネットワーク内におけるアプリケーション及びハードウェアの追加、変更／構成及び停止を制御することができる。ユーザは、例えば、ネットワークマネージャのＧＵＩ（図示せず。）を用いて任意の必要なシステム調整を行うことが可能であり、ネットワークマネージャアプリケーション１８０８は次に、それを、バスサーバアプリケーション１８１２を用いてシステムデータベースにリアルタイムで格納するように構成されることが可能である。さらに、バスサーバアプリケーション１８１２は、ネットワークによりすべてのアプリケーション間通信のために使用可能であるので、バスサーバアプリケーション１８１２は、リアルタイムのネットワーク情報に関する最も信頼性の高いソースである可能性がある。ネットワークマネージャアプリケーション１８１２はまた、バスサーバアプリケーション１８１２に依存して、例えば動作中や停止状態などの、ネットワーク内の与えられたアプリケーションの状態に気付くように構成されることも可能である。このような状態情報は、例えば、ネットワークマネージャのＧＵＩを用いて可視化されることが可能であり、また、システムデータベースに格納されることが可能である。
【０１１２】
バスサーバアプリケーションは、任意の手段によりネットワーク情報を受信する場合はいつでも、例えば、動作中又は停止中の所定のアプリケーション、もしくは変更されているユーザ、企業又は顧客のデータベース等の所定のデータベースである関連情報を、各アプリケーションへ分配するように構成されることが可能である。同様に、ネットワーク内で実行されている各アプリケーションは、その対応するバスサーバアプリケーション１８１２に対して、その情報ニーズについて予め通知するように構成されることが可能である。その後、対応するバスサーバアプリケーション１８１２は、さまざまなアプリケーションのニーズに基づいて情報をフィルタリングしかつフィルタリングされた情報を適宜分配するように構成されることが可能である。
【０１１３】
以上、ウェブサーバ８１０上で実行されるように構成された例示的なアプリケーションをいくつか説明したが、通信センター８００は複数の企業の通信をホスティングするように構成されることが可能であるということは指摘されるべきである。これらの通信を通信センター８００上でホスティングさせることにより、各組織は、業界で一般に顧客構内機器（Customer Premises Equipment：ＣＰＥ）と呼ばれる機器を組織自体で購入する代わりに、サービスプロバイダから設備（インフラストラクチャ）を低減されたコストで賃借することが可能になる。この趣旨に添って、通信センター８００は、Ａ）ソフトウェア及びハードウェアリソースが複数の企業にわたって共用されるか、又は一企業による独占使用に利用されることを可能にし、Ｂ）すべての企業、ユーザ及び言語を処理するためのデータベース構造を備えるように構成されることが可能である。
【０１１４】
セキュリティを理由として、通信センターのオペレータは、一企業の機密データが別の企業のデータと混合することがありえないということを保証しなければならない場合がある。従って、２つ以上の企業をホスティングすることは、データ及びリソースの隔離に関する問題を提示する可能性がある。当然ながら、ある企業は、別の企業のものと混ざり合うことを望まない情報又はデータを有している可能性がある。例えば、ある企業は、その顧客のコンタクト情報、例えば電話番号や電子メールなどが、別の企業の目にふれるようになることを希望しない可能性がある。また、ある企業は、エージェント又は他の通信センター人員が他の所定の企業の通信を処理している場合、もしくは他の所定の企業といく分かの提携関係（アフィリエイト関係）にある場合に、彼らがその通信を扱うことを希望しない可能性がある。
【０１１５】
必要とされる隔離をもたらすために、所定のハードウェア、ソフトウェア及びデータベースのリソースは、通信センター８００内で、各企業又は所定の企業が専用のリソースを有するように重複化されることが可能である。例えば、図８に示すように、電話サーバ８４６、アプリケーションサーバ８４８、データベースサーバ８５０及びファイルサーバ８５４は、実際に複数個存在することが可能である。従って、例えば必要とされる場合には、１つの電話サーバ８４６を、通信センター８００上でホスティングされる特定の顧客に専用のものにすることができる。後に説明するように、ハードウェアの重複又は冗長性は、ネットワークの弾力性を提供することも利用可能である。
【０１１６】
所定の顧客が、他の企業のソフトウェアリソースから隔離された専用のソフトウェアリソースを有するように、ソフトウェアリソースもまた重複化されることが可能である。ソフトウェアの重複又は冗長性もまた、ネットワークの冗長性を提供するために有益である可能性があり、これについては後により詳しく述べる。例示的なウェブゾーンソフトウェアアプリケーションについては、先に述べた。従って、これらのウェブゾーンアプリケーションのうちのいくつかを、所定の顧客に専用のものとすることができる。このことは、ソフトウェアアプリケーションの重複化を含むか、又は、ソフトウェアアプリケーションと、ハードウェアリソース、すなわち複数のウェブサーバ及び／又は複数のメールサーバとの両方の重複化を含む可能性がある。重複化されたリソースは、次に、複数の異なる顧客へ割り当てられることが可能である。
【０１１７】
これに対して表１は、ネットワークゾーン８０２上で実行されることが可能な、特定の実装に関するいくつかの例示的なソフトウェアアプリケーションを列挙したものである。これらのアプリケーションのうちの所定のものは、機密情報を使用するか又は機密情報にアクセスすることを理由として、所定の企業に専用のものとされることが可能である。表１はまた、同じ実装例から、いくつかの一般的に共用されるアプリケーションも挙げている。表１には、記載された例示的なアプリケーションに関するさらなる情報も併記されている。
【０１１８】
【表１】
2005530372.tif 000003
【０１１９】
情報の機密性を保証することと、通信センター８００の規模が変更可能である（スケーラブルである）ことを確実にすることとに対する必要性は、リソースのさまざまな分割及び重複化をもたらす可能性がある。例えば小規模なＣＰＥの実装においては、単一のソフトウェアアプリケーションが、ＣＴＩ、呼のハンドラ及び呼のブリッジ（中継）の機能をすべて引き受けることができる場合がある。しかしながら、情報を隔離する必要がある場合には、各企業専用のＣＴＩを有することが重要である可能性がある。逆に、システムのスケーラビリティの見地からすると、共用されかつＡＴＭスイッチの効果的な使用を制御できる、呼のブリッジが好適である可能性がある。
【０１２０】
複数の企業がホスティングされる場合、データベース８５２内の顧客データを、複数のパーティションに分割して隔離することが好適である可能性もある。このようなパーティションによる分割は、必要とされれば、複数のデータベースサーバ８５０の使用とともに実行可能であるということは留意されるべきである。パーティションによるデータの分割及び復元を支援するために、ホスティングされる各企業に一意的な企業ＩＤを割り当てることができる。この企業ＩＤは次に、関連付けられた企業に関するデータベース８５２に格納されているすべてのデータエレメントに関連付けられることが可能である。以下の段落では、通信センター８００においてデータの効果的な管理及び隔離を維持するために使用可能ないくつかの例示的なデータベースについて詳述する。従って上述の企業ＩＤは、データの適切な管理を保証するために、以下の複数のデータベース内のデータに関連付けられることが可能である。
【０１２１】
第１に、企業データベースは、ホスティングされる企業に関する全情報を含むことが可能であり、例えば、複数のユーザ、複数のコンタクト、複数の作業グループ、複数のプロジェクト、複数のライブラリ、通信情報などを含むことが可能である。企業データベース内の情報は、例えば、管理マネージャのＧＵＩ７００を介して構成されることが可能である。
【０１２２】
またユーザデータベースが含まれることも可能であり、これは、特定の企業又は企業ＩＤに関連付けられた、例えば管理者やエージェントやスーパーバイザなどであるユーザらに関連した全情報を含むかを含むことが可能である。ユーザデータベースは、エージェントの個人情報、技能の評価（格付け）、電話の譲渡、媒体の制限、ユーザ状態定義などを含むことが可能である。ユーザデータベース内の情報もまた、管理マネージャのＧＵＩ７００を介して構成されることが可能である。
【０１２３】
作業グループデータベースは、企業により、その通信を処理するように構成された作業グループに関する情報を含むことが可能である。このような情報は、例えば、作業グループへのエージェントの割り当てと、技能の割り当てと、オーバーフローのルーティングと、一意的な音声のメッセージの割り当てと、キューで待機中の発呼者のためのＡＣＤオプションとを含むことが可能である。作業グループデータベース内の情報もまた、管理マネージャのＧＵＩ７００を介して構成されることが可能である。
【０１２４】
プロジェクトデータベースは、音声、チャット、電子メール、ウェブコールバック、予測型（プレディクティブ）ダイヤリング及びプレビューダイヤリング、エージェントかメニューか又は作業グループの通信がルーティングされる方法についての命令、プロジェクトの優先度、スクリプトに利用されるＵＲＬページ、ＦＡＱ、ウェブコールバック、及びチャットのプッシュ型ページを含む、すべての媒体の通信ルーティング方式を含むことが可能である。プロジェクトデータベースもまた、管理マネージャのＧＵＩ７００を介して構成されることが可能である。
【０１２５】
対話追跡データベースは、ある企業の任意の通信イベントに関連付けられた全情報を含むことが可能である。これは例えば、プロジェクト情報、電話情報、割り当てられたエージェント、継続時間などのような情報を含むことが可能である。対話追跡データベースは、レポートを生成する目的で使用される重要なデータベースである可能性がある。対話追跡データベースは、対応する企業に関連付けられた統計値追跡器（Statistics Tracker）ソフトウェアアプリケーションを用いて更新されることが可能である。
【０１２６】
コンタクトデータベースは、ホスティングされる企業のコンタクト、例えばコールセンターの顧客に関する全情報を含むことが可能である。この情報は、コンタクト名、住所、電話番号などのデータを含むことが可能である。コンタクトデータベース内の情報は、対話マネージャのＧＵＩ４００を介して管理されることが可能である。
【０１２７】
履歴データベースは、ホスティングされる企業の顧客がその企業と行った任意の通信に関連したすべての履歴情報を含むことが可能である。この情報は、エージェント名と、通信結果と、通信のタイプと、注釈と、チャット及び電子メールのテキスト記録と、エージェントが開始した記録とを含むことが可能である。履歴データベースは、統計値追跡器を用いて更新されることが可能である。
【０１２８】
品質管理データベースは、すべてのコールセンター品質管理記録を含むことが可能である。これらの記録は、例えば対話マネージャのＧＵＩ４００を用いて開始される、エージェントによって開始される記録であることが可能であり、又は、例えば監督マネージャのＧＵＩ７００を用いて開始される、スーパーバイザによって開始される記録であることが可能である。品質管理データベースは、統計値追跡器を用いて更新されることが可能である。
【０１２９】
当然ながら、特定の実装に係る必要条件に依存して他のデータベースが含まれることも可能である。従って、データベース８５２の更新は、Ａ）管理マネージャアプリケーション８３４を介して入力された構成情報のような、もしくは対話マネージャアプリケーション８４０を介して入力されたコンタクト入力又は更新のような、直接的なユーザ入力、Ｂ）対話マネージャアプリケーション８４０又は監督マネージャアプリケーション８３４の記録のようなユーザ機能の使用に基づいた、システムによって提供された追加、又は、Ｃ）後述する統計値追跡器アプリケーションからの通信情報のような直接的なシステム入力、を含むさまざまな方法で発生する可能性がある。
【０１３０】
ここに記載したシステム及び方法を用いた場合におけるデータベース８５２の使用は、複数の設定可能な言語キーと予め記録されたプロンプトと使用することによって、例えば、英語やスペイン語などのユーザの話し言葉で提示されるＧＵＩのような、多言語サポートの提供を可能にすることもできる。このことは、Ｊａｖａのリソースバンドルを使用することによって達成されることが可能である。これらのＪａｖａのリソースバンドルは言語別に分類されることが可能であり、また、例えば、サポートされる各言語毎に、英語から外国語への翻訳、又はＫＥＹで構成されることが可能である。このようなＪａｖａのリソースバンドルは、ウェブサーバ８１０に格納されることが可能である。ユーザは、例えばユーザセッションハンドラアプリケーション８１６等のアプリケーションにログインすると、言語及び対応するＧＵＩを選択することができる。次には、メッセージがウェブサーバ８１０上のＪＳＰへ送信されることが可能になり、これは言語ＩＤをセッションに関連付ける。セッションに関連付けられた情報及びデータは、次に、言語ＩＤとともに格納されることが可能であり、よって、通信センター８００は、そのセッションと、将来に起こりうる関連したセッションとにとって適切な言語の使用を知るところとなる。
【０１３１】
Ｊａｖａのリソースバンドルは、管理マネージャアプリケーション８３４から生成されることが可能である。所定の実装では、これは、３つのデータベーステーブル、すなわちローカルキーデータベース、ローカル言語データベース及びローカル可変量データベースを使用することによって達成されることが可能である。ローカルキーデータベーステーブルは、例えば、リソースバンドルに関連付けられた情報を含むことが可能である。ホスティングされる企業の個数と通信量とに依存して、ローカルキーデータベースには何万ものオブジェクトが存在する可能性がある。ローカル言語データベースは、通信センター８００によりサポートされるすべての言語を含むことが可能である。ローカル可変量データベースは、すべての可能なリソースバンドルを含むことが可能であり、かつユーザがこれらをスクラッチから生成できるようにすることが可能である。従って、リソースバンドルと、言語と、これらの３つのデータベースからの情報とを組み合わせることにより、管理者は、例えば、管理マネージャアプリケーション８３４を用いてＪａｖａのリソースバンドルを生成することができる。
【０１３２】
以上、ウェブゾーン８０４の可能な構成及び実装について詳しく説明したが、次に、図１９の例示的な実施形態に関連して、ネットワークゾーン１９００に係るいくつかの可能な構成及び実装について説明する。図面から分かるように、ネットワークゾーン１９００は、データベースサーバ１９１２と、ファイルサーバ１９１４と、アプリケーションサーバ１９０２、１９０４及び１９０６と、電話サーバ１９０８及び１９１０とを含む。各サーバは、標準的なサーバのハードウェア及びソフトウェアを備えるとともに、ここに記載したシステム及び方法に従って構成されたハードウェア及び／又はソフトウェアを備えることが可能である。例えば、図１９に示すサーバのうちの１つ又は複数には、表１のアプリケーションを含むことが可能である。
【０１３３】
図１９の例では、ハードウェアリソース及びソフトウェアリソースの両方が、ネットワークゾーン１９００内のサーバ間で重複される及び／又は分割されることが可能であるということを説明するために、３つのアプリケーションサーバ１９０２、１９０４及び１９０６と、２つの電話サーバ１９０８及び１９１０が存在する。先に説明したように、リソースを重複させたり又は分割したりする１つの理由は、複数個の企業をホスティングすることに関連付けることができる。詳細後述するもう１つの理由は、弾力性にある。その他、可能性のある理由として、簡単なリソース管理と、システム効率とを含む可能性がある。
【０１３４】
実際には、ソフトウェア電話のリソースは電話サーバ１９０８及び１９１０上で動作し、かつソフトウェアアプリケーションのリソースはアプリケーションサーバ１９０２、１９０４及び１９０６上で動作することが好適である可能性があるが、しかしながら、ここに記載したシステム及び方法に従って設計される通信センターのリアルタイムかつ分散的な性質に起因して、ここに記載したさまざまなハードウェア及びソフトウェアは、例えば通信センター８００である通信センター内の任意の場所に存在することが可能である。従って、電話リソースは実際にアプリケーションサーバ１９０２、１９０４及び１９０６上に存在することが可能であり、アプリケーションリソースは電話サーバ１９０８及び１９１０上に存在することが可能である。さらに、ウェブゾーンリソースもまたどのタイプのサーバにも存在することが可能であり、ネットワークゾーンリソースはウェブゾーンサーバに存在することが可能である。従って、図２及び図８に示すゾーン隔離は、必要とされる物理的な世界の隔離とは対照的に、ある点では単に論理的な隔離を表すものである。
【０１３５】
ネットワークゾーン１９００内の各ホストは所定のアプリケーションを備えるものとして図示されているが、これは単に例示を目的としたものである。これらのリソースのいずれも、特定の実装による要求に従って、ネットワークゾーン１９００内の任意のホスト上に存在することができる。これらのアプリケーションのうちの最初のものは、バスサーバアプリケーション１９２０である。バスサーバアプリケーション１９２０は、先に述べたバスサーバアプリケーション１８１２と同一又は同様のものであってよい。従って、ネットワークゾーン１９００内の各ホストは、バスサーバアプリケーション１９２０を有することが可能である。さらに、ネットワークゾーン１９００内の各ホストは、ホストマネージャアプリケーション１９２２を含むことが可能であり、上記ホストマネージャアプリケーション１９２２は、例えばＦＴＰを用いて、アプリケーションサーバ１９０２、１９０４及び１９０６と、電話サーバ１９０８及び１９１０と、ファイルサーバ１９１４と、対応するウェブゾーンとに対する、またこれらからのすべてのファイル転送を行うように構成されることが可能である。多くの従来のオペレーティングシステムは、このような転送を実行する固有の能力を備えている。従って、ホストマネージャアプリケーション１９２２のいくつか、又はすべては、従来のオペレーティングシステムのリソースを備えることが可能である。
【０１３６】
ホストマネージャアプリケーションは、例えば、ネットワークマネージャアプリケーションによって生成されることが可能である。例えばネットワークマネージャアプリケーションによる生成の後、ホストマネージャアプリケーション１９２２は、その対応するホスト上にディレクトリ構造を生成しかつ指定されたファイルサーバ１９１４から必要なすべてのシステム状態ライブラリファイル１９１８（電子メール／ファックス応答、ＩＶＲプロンプト、挨拶メッセージ）をダウンロードするように構成されることが可能である。さらに、ユーザが、例えば、ネットワークゾーン１９００に格納されたライブラリに新たなファイル１９１８をアップロードすることによってシステム状態に変更を加えると、ユーザ状態送信アプリケーション８２０は、例えばＬＡＮ１９５２を介して、ネットワークゾーン１９００内の全ホストにその変更についてブロードキャストするように構成されることが可能である。各ホストは、次に、ファイルサーバ１９１４からこの変更をダウンロードすることができる。
【０１３７】
さらに、ユーザ間に、又はユーザらと顧客らとの間に通信が発生する毎に、通信センターは、例えば、いつ、どのようなタイプの通信−チャット、電子メール、電話−が発生したか、という重要な統計情報を捕捉するとともに、例えばチャットのテキスト記録や会話ノートなどのような、関連付けられた任意のファイル１９１８を捕捉するように構成されることが可能である。このような統計情報及びファイルは、ホストマネージャアプリケーション１９２２の制御下でファイルサーバ１９１４へ転送されてファイル１９１８に格納されることが可能である。
【０１３８】
アプリケーションサーバ１９０２はまた、インターネットハンドラアプリケーション１９２６を含むことが可能であり、インターネットハンドラアプリケーション１９２６は、例えば対話マネージャアプリケーション８４０や監督マネージャアプリケーション８３８や又は管理マネージャアプリケーション８３４のようなリアルタイムのユーザアプリケーションと、ネットワークゾーン１９００内の他のアプリケーションとの間の通信リンクとして動作するように構成されることが可能である。例えば、インターネットハンドラアプリケーション１９２６は、コンピュータ電話統合（Computer Telephony Integration：ＣＴＩ）アプリケーション１９３０に、あるエージェントがその対話マネージャのＧＵＩ４００上で「ミュート」を押したことについて通知するように構成されることが可能である。インターネットハンドラアプリケーション１９２６はまた、例えば、そのエージェントの対話マネージャアプリケーション８４０に、電子メール分配器アプリケーション１９３２が電子メールを当該エージェントに転送したことについて通知するように構成されることが可能である。さらにインターネットハンドラアプリケーション１９２６は、チャットハンドラ（ＣＨＡＴＨ）アプリケーション１９２４と、顧客の端末及びエージェントの端末８３０との間でチャット通信を双方向に送信するように構成されることが可能である。
【０１３９】
ＣＨＡＴＨアプリケーション１９２４は、インターネットハンドラアプリケーション１９２６を介したエージェントの端末８３０と顧客のチャットアプレットとの間の通信を促進するように構成されることが可能である。例えば、顧客がチャットを要求すると、ＣＨＡＴＨアプリケーション１９２４は、ＡＣＤ１９２８と通信することによって最適なエージェントを発見するように構成されることが可能である。ＣＨＡＴＨアプリケーション１９２４は次に、インターネットハンドラアプリケーション１９２６を用いてエージェントの端末８３０に新たな通信を提示することができる。その後、再びインターネットハンドラアプリケーション１９２６を用いて、ＣＨＡＴＨアプリケーション１９２４は、エージェントの端末８３０に対する、顧客によって入力されたチャットテキストのリフレクタとして、またこの逆として効果的に動作するように構成されることが可能である。
【０１４０】
ＣＨＡＴＨアプリケーション１９２４は、実装に依存して、アプリケーションサーバ１９０２上ではなく、例えばウェブサーバ８１０等のウェブサーバ上に存在することが可能である。このような構成の優位点は、インターネットハンドラアプリケーション１９２６がチャット通信における仲介者（go between）として動作することに関連付けられた通信遅延を回避できるということにある。このような構成において、実際に、顧客はあるウェブサーバに接続される一方、エージェントは異なるウェブサーバに接続されることが可能である。従って、２つのウェブサーバの各々に異なるＣＨＡＴＨアプリケーション１９２４が存在することが可能であり、これらは、例えばバスサーバアプリケーション８２８等のバスサーバアプリケーションを介して互いに通信するように構成されることが可能である。
【０１４１】
ＣＨＡＴＨアプリケーション１９２４は、例えばチャットがいつ発生し、誰が参加し、何が論じられたかなどといった重要なチャットの統計情報とともに、顧客とエージェントとのチャットに係るテキスト記録を、データベース１９１６又はファイル１９１８に保存することが望ましい場合がある。またこのような情報は、任意の通信センターの人員が例えば対話マネージャアプリケーション８４０を用いて任意の顧客に関する完全なエージェント通信履歴にアクセスできるように、すべての媒体に対して統合化されているより大きなグローバルデータベースの一部として格納されることが望ましい場合がある。
【０１４２】
コンピュータ電話統合（ＣＴＩ）アプリケーション１９３０は、アプリケーションサーバ１９０４上に存在することが可能であり、また、呼のハンドラ（ＣＡＬＬＨ）アプリケーション１９４８及び呼のブリッジ（ＣＡＬＬＢ）アプリケーション１９４６等のシステムリソースを制御することによって、ホスティングされた企業の電話接続をグローバルに管理するように構成されることが可能である。ＣＴＩアプリケーション１９３０は、すべての電話リソース及び電話回線について、どれが利用可能であり、あるいは使用中であるか、また誰によって使用されているかといったことに関して追跡し続けるように構成されることが可能である。ＣＴＩアプリケーション１９３０は次に、この情報を用いて、新たな通信を接続する方法に関するグローバルな決定を下すように構成されることが可能である。
【０１４３】
説明の助けとして、図２０に関連して電話サーバ２０００の構成例について簡単に述べる。まず、通信センター８００等の分散型通信センターにおける全サーバの場合のように、例えば電話サーバ２００８又は２０１０等の電話サーバは、プロセッサ２００２、サーバチップセット２００４及びメモリ２００６等の標準又はカスタムメードのハードウェア構成要素を有する、市販のサーバであることが可能である。さらに、これは、例えばＩＳ、ＰＣＩ又はコンパックＰＣＩ（CompaqPCI）である拡張スロットを含むことが可能な標準的な入力／出力（Ｉ／Ｏ）２００８を備えることが可能であり、上記拡張スロットに、例えばダイアロジック／インテル（Dialogic/Intel）の音声、ファックス又は会議ボードであるカスタムメード又は市販の電話カードを差し込むことができる。例えば、ある特定の実装において、電話サーバ２０００は、市販のコンパックコンピュータ上で動作するインテルのダイアロジックハードウェアを備える。
【０１４４】
プロセッサ２００２は、図２０では単一のデバイスとして示されているが、これは実際には複数のプロセッサ及び回路を備えることが可能であるということは留意されるべきである。例えば、プロセッサ２００２は、実装に依存して、１つ又は複数のマイクロプロセッサ及び／又はマイクロコントローラ回路と、ディジタル信号処理（ＤＳＰ）回路と、他のカスタマイズされた回路又はカスタマイズ可能な回路を備えることが可能である。これらの回路は単一の集積回路（ＩＣ）を構成することが可能であり、又は、これらのいくつか又はすべてはスタンドアロン型デバイスであることが可能である。さらにサーバチップセット２００４は、実装に依存して、単一のＩＣの一部、もしくは１つ又は複数のスタンドアロン型デバイスの一部であることが可能な、複数の回路を備えることができる。さらに、プロセッサ２００２の一部又は全体は、サーバチップセット２００４の一部又は全体と統合化されることも可能である。
【０１４５】
メモリ２００６は、複数の記憶デバイス（又は記憶装置）及び媒体を備えることが可能である。例えばこれは、ＲＯＭ  ＩＣ又はＲＡＭ  ＩＣ等のメモリ回路を備えることが可能である。一般的な例は、ＳＲＡＭ回路、ＥＰＲＯＭ回路及びフラッシュ（ＦＬＡＳＨ）回路である。これらの回路は、回路基板上に含まれてもよく、又はフラッシュに基づいたメモリカード等の着脱可能なデバイスであってもよい。メモリ２００６はまた、ハードドライブやＣＤＲＯＭドライブなどのような記憶装置ドライブを備えることが可能である。これらのドライブもまた着脱可能であってもよく、又はフロッピーディスク又はＣＤ等の着脱可能なディジタル媒体を使用してもよい。このような記憶デバイス及び媒体はすべて、本明細書及び添付の請求の範囲の目的に沿って、コンピュータが読み取り可能な媒体という用語で呼ぶこともある。
【０１４６】
電話カードは、例えばコンピュータ電話（Computer Telephony：ＣＴ）バス２０１０を介して、互いに接続されることが可能である。電話カードはまた、さまざまなタイプのＩ／Ｏ回線に接続されることが可能であり、そのうちのいくつかは、１）モジュラーシステムインターフェース（Modular System Interface：ＭＳＩ）のローカルな電話内線、２）ＬＡＮへのネットワーク接続、３）スイッチ又は別のサーバへの非同期転送モード（Asynchronous Transfer Mode：ＡＴＭ）接続、４）例えばＴ−１又はＥ−１回線等の、ローカルな電話会社の中央局により提供される電話接続、であることが可能である。Ｔ−１回線は、１．５４４Ｍｂｐｓ（毎秒１，５４４，０００，０００ビット）の全体的な信号速度を有するディジタル伝送リンクである。Ｔ−１回線は、複数の電話会社により北米の企業へ提供される標準的な接続である。
【０１４７】
電話カードは、共用された物理的回線上で複数の同時的な電話の会話が発生可能であるように、時分割多重（交換）を実行するように構成されることが可能である。例えば、Ｔ−１回線は、典型的には２４個の同時的な全二重会話を伝送することができる。全二重とは、２人の人間が同時的な双方向の会話を行えるということを意味する（彼らは、回線のどちら側でも同時に話しかつ聴いてもらうことができる）。交換ハードウェアに係るこの能力は、典型的にはチャンネル数又は時間スロット数で測定されることが可能である。例えば、Ｔ−１回線は、潜在的な各会話につき１つのチャンネルがあるように２４チャンネルを有し、また、各方向での通信につき１つの時間スロットがあるように４８個の時間スロットを有する。さらにＣＴバスは、電話カード間通信用に１，０２４個の時間スロットを有することが可能である。これらのチャンネル又は時間スロットには、特定の音声、データ、ビデオ又は他の通信を参照するために番号が付与されてもよい。
【０１４８】
ＣＴＩアプリケーション１９３０は、通信センターによってホスティングされる一企業又はいくつかの企業に専用の全機器についての集合的なチャンネル及び時間スロットを管理するように構成されることが可能である。異なる電話カードには、ＣＴバスにわたる通信のために所定範囲の時間スロットを割り当てることができる。通信の発生に伴って、ＣＴＩアプリケーション１９３０は、ＣＴバスのどの時間スロットが占有されるかということについて、また、顧客ら又は通信センター人員からの新規な呼の接続を制御するために、どのＴ−１チャンネル又は他のチャンネルが使用される可能性があるかということについて追跡するように構成されることが可能である。
【０１４９】
例えば、顧客からの呼はＴ−１回線を介して着信し、また、ＣＴバスの特定の時間スロット上でＴ−１カードを管理するＣＡＬＬＨアプリケーション１９４８によってＣＴＩアプリケーション１９３０へ提示されることが可能である。ＣＴＩアプリケーション１９３０は、次に、ＭＳＩカードを管理するＣＡＬＬＨアプリケーション１９４８に要求して、特定のコールセンターのエージェントを当該エージェントの特定の内線で呼び出させるように構成されることが可能である。ＭＳＩは次に、ＣＡＬＬＨアプリケーション１９４８の制御下で、ＣＡＬＬＨアプリケーション１９４８に、通信用のＣＴバスの時間スロットを提示することができる。ＣＴＩアプリケーション１９３０は、次に、Ｔ−１の呼のＣＴバスの時間スロットを受信して聴取するように、ＣＡＬＬＨアプリケーション１９４８を介してＭＳＩカードにコマンドを送るように構成されることが可能である。ＣＴＩアプリケーション１９３０は、次に、ＭＳＩの呼のＣＴバスの時間スロットを受信して聴取するように、ＣＡＬＬＨアプリケーション１９４８を介してＴ−１カードにコマンドを送るように構成されることが可能であり、両者は効果的に中継される。
【０１５０】
Ｔ−１の呼は、コールセンターのエージェントの電話機が接続されているものとは異なる電話サーバに着信する可能性がある。この場合には、後述するＣＡＬＬＢアプリケーション１９４６が通信の処理に関わるようになることが可能である。
【０１５１】
特定の顧客通信を処理する特定エージェントを選択することは、ＡＣＤ１９２８の主要な関心事である可能性がある。ＡＣＤ１９２８は、着信する新たな通信に対して、最良の利用可能なエージェントを割り当てるように構成されることが可能である。これを行なうために、ＡＣＤ１９２８は、エージェントらの技能と、特定の作業グループへルーティングされる呼に係る技能の必要条件とに関する情報を用いるとともに、エージェントの対話マネージャアプリケーション８４０を介して提供されるエージェントの状態情報を用いるように構成されることが可能である。ＡＣＤ１９２８はまた、呼のルーティングに際して、企業の提携及び言語能力等の情報を使用するように構成される必要がある。ここで、上記情報は、例えばデータベース１９１６に格納されることが可能である。さらにＡＣＤ１９２８は、例えば電話呼や電子メールなどのすべての媒体タイプにわたっって、ルーティング動作をリアルタイムで同時に達成するように構成されることが可能である。
【０１５２】
与えられた任意の時間において、ＡＣＤ１９２８は、１）新たな通信を待機しているいくつかの利用可能なエージェントを有するか、又は、２）次の利用可能なエージェントを待機している、キューに格納されたいくつかの通信を有する可能性がある。最初の場合では、ＡＣＤ１９２８が、新たな通信の個数より多い利用可能なエージェントを有するとき、ＡＣＤ１９２８は、すべての利用可能なエージェントのスコアを計算し、最高のスコアを有するエージェントを選択して次の通信を処理させるように構成されることが可能である。スコアは、下記の表２乃至表５に例示する方法を用いて導出されることが可能である。この方法は、着信する通信をルーティングする際に考慮すべきものとして、２つの作業グループ、すなわち作業グループ１及び作業グループ２が存在し、各作業グループにおける２つのエージェント、すなわちエージェント１及びエージェント２が存在し（簡単化のために、エージェント１及びエージェント２は実際には作業グループ１及び２の両方に使用される。）、関連した２つの技能、すなわち技能１及び技能２が存在することを仮定している。
【０１５３】
従って、表２は作業グループの関連した能力を調べたものである。次に表３は、各エージェントの関連した能力について、それらがどの程度の時間期間だけアイドル状態にあるかといったことを調べたものである。表４を使用すると、作業グループ１へルーティングされる次の通信を受信するためのエージェントを選択することができる。同様に、図５は、作業グループ２にルーティングされる次の通信を受信するエージェントを選択するために使用可能である。着信する通信を受信する作業グループは、表１に基づいて、もしくは、例えばデータベース１９１６に格納された他の基準又は設定に基づいて選択されることが可能である。
【０１５４】
【表２】
2005530372.tif 000004
【０１５５】
【表３】
2005530372.tif 000005
【０１５６】
【表４】
2005530372.tif 000006
【０１５７】
【表５】
2005530372.tif 000007
【０１５８】
これに対して、ＡＣＤ１９２８が、利用可能なエージェントより多数の着信する通信を有していれば、エージェントは、下記の基準、すなわち、
１）通信が、エージェントによってすでに処理されている通信と互換性があるということであって、例えば、理論上、エージェントが、おそらくは着信する２つの呼に対して２つの呼を同時に処理できる場合に、電子メールを処理しているエージェントが、着信する通信を受信するように選択されることが可能であるということと、
２）例えば、その時点で処理されているより低優先度の通信は、より新しい、より優先度の高い通信が処理される間は待機状態にされる可能性があるという、着信する通信に関連付けられた優先度と、
３）通信がキューに入っている時間の長さと、
４）例えば表２乃至表５の分析と同一の分析又は同様の分析に基づいた、エージェント及び／又は作業グループの相対的なスコアと、
５）最大のＩＤ番号を有する通信
とを用いて選択されることが可能である。
【０１５９】
ＡＣＤ１９２８は、どのエージェントが利用可能であるかということを、いくつかの方法で決定するように構成されることが可能である。例えば、前述のように、エージェントは、その対話マネージャアプリケーション８４０を用いて当該エージェントの利用可能性を設定することができる。このことは、エージェントの利用可能性をリアルタイムで確立する際に発生する可能性のあるレーシング状態（競合状態）が存在する場合に、重要な方法となる可能性がある。例えば、電話サーバ１９０８は、顧客の電話呼を受信すると、これを最適なエージェントに接続するように構成されることが可能である。しかしながら、そのエージェントは、当該エージェントが選択された後ではあるが実際に呼が当該エージェントにルーティングされる前に、別の電話呼を発生させようとする可能性があり、このことにより、当該エージェントは実際には、着信する電話呼を処理することに利用不可能にされる。こうした状況を検出するように電話サーバ１９０８を構成することが好適である可能性があるが、しかしながら、エージェントの利用可能性についての情報を通信センターにわたって通信する際の固有の遅延が存在する場合には、このことは困難である可能性がある。ゆえに、電話サーバ１９０８又はＡＣＤ１９２８は、エージェントの利用可能性が集中的に計算されるのではない限り、また可能なだけエージェントに近接しているのではない限り、最良のルーティング決定を下すことができない可能性がある。従ってこのような状況では、対話マネージャアプリケーション８４０が上述のようにエージェントの利用可能性を決定することが好ましい可能性がある。
【０１６０】
従って、ＡＣＤ１９２８は、例えば電話、ファックス、電子メール、ウェブコールバック、電話コールバック、ウェブチャットなどの任意のタイプの通信を最適なエージェントへルーティングするように構成されることが可能である。例えば電話呼、ウェブコールバック要求、電話コールバック要求などの電話通信の場合、エージェント及び顧客は、例えば卓上電話機、携帯電話機、ソフトウェア電話機などである彼らの電話機を用いて互いに通信することができる。クライアントがエージェントと必ずしもリアルタイムで通信しているのではない、例えば電子メール、ファックス又はボイスメール等のオフライン通信の場合、電子メール分配器アプリケーション１９３２は、インバウンド（着信）及びアウトバウンド（発信）の両方の電子メールの、エージェントの端末８３０への分配とエージェントの端末８３０からの分配とを管理するように構成されることが可能である。次にエージェントは、例えば、マイクロソフト・アウトルック（Microsoft Outlook）等の市販の強力な電子メールクライアントを用いて、通信を処理し、また顧客に応答する／顧客と通信することができる。ウェブチャットや、又はインスタントメッセージ及びショートメッセージサービス（Short Message Service：ＳＭＳ）等のウェブによって開始される同様の通信の場合、ＣＨＡＴＨアプリケーション１９２４は、エージェントら及び顧客らの間におけるリアルタイムのチャット通信を管理するように構成されることが可能である。チャットはリアルタイムで発生するので、エージェントの端末８３０は、対話マネージャアプリケーション８４０内に、又はこれとは別個に、チャットクライアントアプリケーションを含むことが好適である可能性がある。所定の実施形態では、顧客は、ウェブサーバ８１０からチャットクライアントをダウンロードしてもよい。
【０１６１】
先に述べたように、電子メール分配器アプリケーション１９３２は、通信センター８００における全電子メール通信の中心部（コア）として構成されることが可能である。電子メール分配器アプリケーション１９３２は、顧客の電子メールを、例えばＰＯＰ３メールサーバ（例えば図２のメールサーバ２１８を参照）から検索して読み出すように構成されることが可能である。着信する各電子メールに対して、電子メール分配器アプリケーション１９３２は、エージェントがＡＣＤ１９２８によって選択されることを要求するように構成されることが可能である。いったんエージェントが選択されると、電子メール分配器アプリケーション１９３２は、着信する電子メールを、選択されたエージェントへルーティングするように構成されることが可能である。
【０１６２】
所定の実装では、エージェントによって生成された電子メールはすべて、ネットワークゾーン１９００内の集中化された記憶領域をまず通過する。例えば、エージェントによって生成された電子メールにおける「Ｆｒｏｍ（差出人）」フィールドを変更することにより、エージェントの応答は共通の記憶領域へ送信されることが可能である。ただし、エージェントらは引き続き、電子メール分配器アプリケーション１９３２による介入なしに、彼らのＰＯＰ３電子メールサーバへ個人の電子メールを直接に送信してもよい。従って、エージェントの応答は、実装に依存して、システムがエージェントの応答を捕捉してこれをクライアント履歴の一部として格納できるように、エージェントから顧客へ直接には伝送されない場合がある。
【０１６３】
電子メール分配器アプリケーション１９３２は、通信センターのエージェントらに対する電子メールの配信を処理するように構成されることが可能であり、その一方、統合メッセンジャー（ＵＭＧＲ）アプリケーション１９３４は、ファックス及びボイスメールの配信に対して、それらがエージェントの内線電話機に直接に送信されたものであるか又はＡＣＤ１９２８によってルーティングされたものであるかに関わらず、責務を有するように構成されることが可能である。さらに、ＵＭＧＲアプリケーション１９３４は、エージェントらが、例えばボイスメール、ファックス、電子メールなどである彼らのメールを、電話機を用いて検索して読み出すことができるようにするために使用可能である。
【０１６４】
ボイスメール又はファックスが添付されている可能性のある電子メールの配信に失敗した場合、影響を受けるソフトウェアアプリケーション、例えば電子メール分配器アプリケーション１９３２又はＵＭＧＲアプリケーション１９３４は、その失敗したイベントのログをデータベース１９１６に記録するように構成されることが可能である。すると、通信センターの管理者は、例えば、当該管理者の管理マネージャアプリケーション８３４を用いて、上記失敗に関連した情報、例えば不良なエージェントの電子メールアドレスや不良なアドレス構文などを見ることができる。管理者はまた、その情報を編集し、失敗した通信を当該管理者の管理マネージャ８３４を用いて再送信してもよい。
【０１６５】
代替として、ＵＭＧＲアプリケーション１９３４が失敗した通信を再送信するように構成されることも可能である。このことは、ＵＭＧＲアプリケーション１９３４が、電子メールを送信する能力を有し、失敗した通信が格納されるファイルシステム１９１８へのアクセスをすでに有しているので、実際に好適である可能性がある。従って、実装に依存して、電話ハードウェアを有するすべてのホスト、又は実行中の電子メール分配器アプリケーション１９３２を上に有するすべてのホストのいずれかに、ＵＭＧＲアプリケーション１９３４を有することが望ましい可能性がある。それに代わって、ＵＭＧＲアプリケーション１９３４が除去され、その機能が、電子メール分配器アプリケーション１９３２、ＣＡＬＬＨアプリケーション１９４８又はホストマネージャアプリケーション１９２２等の別のアプリケーション内に組み込まれてもよい。実際に、図１９に示したアプリケーションのいずれも、特定の実装に依存して、別のアプリケーションの一部又はすべてを実際に備えることが可能である。
【０１６６】
上述の議論から、例えばネットワークマネージャアプリケーション１８０８等のネットワークマネージャアプリケーションは、１つ又は多数の企業の通信を処理するためにさまざまなソフトウェアリソースを生成するように構成されうることが分かる。さらに、これらの異なるリソースは多数の通信に関与することが可能である。従って、これらのリソース及び／又は通信を制限する課金戦略及び方法を有することが重要になる可能性がある。
【０１６７】
従来の通信センターは、例えばファックスのソリューション、電子メールのソリューション、予測型のソリューションなどの、所定の特定分野（ニッチ）を専門とするさまざまな企業の製品を使用する場合が多い。ここで、これらの異なる製品を統合化するために、システムインテグレータらがしばしば用いられる。その結果、企業又は通信センターのオペレータは、異なる製品の各々に関する異なるライセンスに対して支払いを行わなければならない場合が多い。言い換えれば、通信センター８００内で処理される異なるタイプの通信タイプのそれぞれに対して異なるライセンスが存在する可能性がある。当然ながらこのアプローチは、経済的見地から非効率的である可能性がある。
【０１６８】
しかしながら、ここに記載したシステム及び方法を使用すれば、必要とされるライセンス数及び／又はそれらを管理する負担を低減させる、リソースのシームレスな統合化を達成することができる。このようなシームレスな統合化は、通信が、従来のアプローチを用いた場合には単にタイプによって課金されるのに対して、この場合は量によって課金されることが可能になるので、経済的な非効率性を低減することができる。従って、ここに記載したシステム及び方法によって提供されるシームレスな統合化は、企業に対して、必要に応じて、例えば、電子メールではないファックス、又はファックス及び電子メール、もしくは単に電話であるソリューションをバンドルしかつバンドルを解除する柔軟性を与えることができる。さらに、これは、特定のソフトウェアアプリケーションの提供業者（ベンダー）に対する支払いを、タイプに関わらず通信の全体的な量によって行う能力を提供する。
【０１６９】
それでもなお、さまざまなソフトウェアアプリケーションによって取得されるライセンスは、使用上の制限を課す場合がある。ライセンスマネージャ（ＬＭＧＲ）アプリケーション１９３８は、このような制限を実施するために使用されることが可能である。任意の使用制限を実施するために、ＬＭＧＲアプリケーション１９３８は、ネットワークマネージャアプリケーション（図１９には図示せず。）によってアプリケーションが開始されるとき及び終了されるときについての通知を受けることが可能である。その結果、例えば、あるアプリケーションが、ネットワークマネージャアプリケーションによってではなく手動で追加されると、ＬＭＧＲアプリケーション１９３８は、そのリソースが正当なものではないことと、それが拒絶されるべきであることとを確認しまた確定することができる。このような状況では、ＬＭＧＲアプリケーション１９３８は、次にネットワークマネージャアプリケーションにこの拒絶されたアプリケーションについて通知するように構成されることが可能である。ＬＭＧＲアプリケーション１９３８はまた、任意のネットワークリソースによって通信が開始されるとき及び終了されるときについての通知を受けることが可能であり、これにより使用制限を効果的に実施することができる。
【０１７０】
ライセンスの効果的な実施はまた、通信センター内で例えばシリアルポートに接続されることが可能な、認証ドングル（dongle）を用いて援助されることも可能である。ソフトウェアの提供業者は、例えば、企業又は通信センターのオペレータが何に対して支払いを行ったかということに基づいて、ドングルにおいてシステム制限を暗号化することができる。例えば、ドングルは、通信センター全体により消費される可能性のある、ライセンス／通信の個数のピーク値を含むことが可能である。ホスティングされた環境においては、通信センターのオペレータは次に、実装に依存して、許容可能な通信を、ホスティングされた複数の企業間で分割することができる。ＬＭＧＲアプリケーション１９３８は、次いで、すべての制限を実施するように構成されることが可能である。
【０１７１】
ここに記載したシステム及び方法によって構成され、通信センター内に実装されることが可能なもう１つの課金の代替方法は、ある企業が必要とするだけの多数の通信又はアプリケーションを当該企業が使用できるようにすることである。このような場合、ＬＭＧＲアプリケーション１９３８は、どれだけの通信が例えば１時間当たりで使用され、またどれだけのアプリケーションリソースが例えばピーク使用量で使用されたかということを示す、暗号化されかつ署名されたレポートを周期的に生成するように構成されることが可能である。このことは、ピーク時間の消費量の予測が容易ではなく、かつ予測された制限に起因するサービスの中断は望ましくない可能性があるという場合に、特に望ましい可能性がある。
【０１７２】
ＬＭＧＲアプリケーション１９３８はまた、どのアプリケーションがマスタでありかつどれがバックアップであるかを決定するように構成されることが可能である。この機能については、ここに記載したシステム及び方法の弾力的な態様に関連して後に詳述する。
【０１７３】
ネットワークマネージャアプリケーションによってアプリケーションが開始されると、新たに開始されたアプリケーションは、データベース１９１６から大量の構成情報をダウンロードすることができる。ダウンロードされるデータ量が大きい可能性があるので、新たに開始されるアプリケーションを、そのアプリケーションの起動時にデータベース１９１６へ直接に接続するように構成することが好適である可能性がある。起動の後で、アプリケーションは、例えば通信の統計又は情報を格納するために、データベース１９１６にアクセスすることを必要とする場合がある。こうしたタイプのトランザクションのために、統計値追跡器１９３６は、アプリケーションとデータベース１９１６との間のゲートウェイとして動作するように構成されることが可能である。このようなアプローチにより、データベース１９１６が通信センターのアプリケーションとの間で保持する必要のある同時的な接続の数を最小化することができる。さらに、データベースの接続性を単一のアプリケーション内に集中させることにより、データベースの故障が、データベースアクセスを必要としない動作を阻止してしまうことを防止することができる。
【０１７４】
簡易ネットワークマネージャ（Simple Network Manager：ＳＮＭ）アプリケーション１９５４は、通信センターを、簡易ネットワーク管理プロトコル（Simple Network Management Protocol：ＳＮＭＰ）に適合させるように構成されることが可能である。従って、ＳＮＭアプリケーション１９５２はＳＮＭＰエージェントであることが可能である。ＳＮＭアプリケーション１９５２は、サードパーティーのアプリケーションによる、通信センターの動作のモニタリングを可能にするように構成されることが可能である。例えばこれは、第三者にリアルタイムの統計情報を提供することが可能である。ＳＮＭアプリケーション１９５２はまた、例えばＴ−１チャンネルがブロックされたらしいような場合に、サードパーティーのアプリケーションに対して、任意の警報を通知するように構成されることが可能である。最後に、ＳＮＭアプリケーション１９５２は、例えば警報を発生させる原因である問題点を是正するための動作を、通信センター上でサードパーティーのアプリケーションに実行させるように構成されることが可能である。
【０１７５】
システムスケジューラアプリケーション１９４２は、スケジューリングされたイベント、例えば通信センターの機能に係るスケジューリングされた変更を追跡し、かつ上記イベントに基づいて動作するように構成されることが可能である。さらに、システムスケジューラアプリケーション１９４２は、このようなシステム変更がしかるべき時に有効化されるように当該システム変更をいつ発生させるかということを、インテリジェントに予測するように構成されることが可能である。例えば、通信センター８００等の分散型通信センターは複数のゾーン又は複数の構成要素を世界中の任意の場所に備える可能性があるので、このようなスケジューリングされた動作は、タイムゾーンに敏感な方法で実行される必要のある場合がある。さらに、顧客が例えば米国の太平洋標準時（ＰＳＴ）の午後３時におけるウェブコールバックを要求し、かつ次の利用可能なエージェントの推定待ち時間が約３０分であると思われる場合には、システムスケジューラアプリケーション１９４２は、ウェブコールバックを午後２時３０分に開始するように構成される必要がある。
【０１７６】
スケジューリングされる動作の他の例は、与えられたプロジェクト用に電話番号を変更すること、顧客に対して、ＡＣＤによって制御されたウェブコールバックを発生すること、又は、エージェントによるか又はエージェントの作業グループによる顧客へのコールバックを当該エージェントにスケジューリングさせることを含むことが可能である。
【０１７７】
着信する通信をルーティングしまた処理することに加えて、ここに記載したシステム及び方法により構成された通信センターはまた、アウトバウンド通信を処理するように構成されることが可能である。例えば、通信センターは、例えば複数の世帯にその長距離電話会社の変更を勧誘するために、複数の電話番号に対する電話呼をスケジューリングして発生させるように構成されることが可能である。予測型発呼者アプリケーション１９４４は、このような動作を処理するように構成されることが可能である。このように、予測型発呼者アプリケーション１９４４は、多数のアウトバウンドの電話呼を発生させ、かつこれらを利用可能なエージェントに接続するように構成されることが可能である。従って、予測型発呼者アプリケーション１９４４は、例えば電話呼の発生回数に基づいた顧客によるその電話機の利用可能度と、通信センターのエージェントの利用可能度とを均衡させるように構成される必要がある。このような均衡化は、このようなアウトバウンドの電話呼への投資に対する収益を最適化することを保証する手助けとなる可能性がある。
【０１７８】
いくつかの例では、このようなアウトバウンドの呼に応答して、予想を上回る顧客が電話に出る場合がある。このような場合には、通信センターには、すべての通信を処理するのに十分なほど利用可能なエージェントがいない可能性もあり、例えば呼を切断する必要のある場合もある。このようにして切断された電話呼は、しばしば放棄された電話呼と呼ばれる。この状況への対処を支援するために、システムの管理者は、例えば管理マネージャアプリケーション８３４を介して、複数のパラメータを入力することにより、予測型発呼者アプリケーション１９４４の態様を構成することができる。構成されることが可能ないくつかの例示的なパラメータは、利用可能なエージェント数当たりの予測型発呼者アプリケーション１９４４による発呼回数と、発呼回数及び発呼時間を管理するための考案されたペーシング（速度調整）アルゴリズムとである。パラメータに基づくさらなる構成は、管理者がこうしたペーシングアルゴリズムにフィードバックを与えることを可能にし、例えばそれが多数の呼を発生させるレートを増大させたり又は低下させたりすることができる。
【０１７９】
予測型の呼は、必ずしもそのすべてが、顧客をエージェントに接続しようとするわけではない。例えば、医療施設の職員は、予約記録を患者に再生して見せることを所望する場合がある。彼らはさらに、患者のボイスメールの受信箱にボイスメールを上記記録とともに残せることを所望する可能性もある。予測型発呼者アプリケーション１９４４は、例えば複数のパラメータを入力することによって、このような機能も実行するように構成されることが可能である。予測型発呼者アプリケーション１９４４はまた、所定の基準に基づいて、複数のコンタクトにてなるリストを変更するように構成されることが可能である。例えば、予測型発呼者アプリケーション１９４４によって発生された電話呼がファックスマシンに到達すれば、予測型発呼者アプリケーション１９４４は、そのキャンペーンの電話番号リストからその電話番号を除去するか、又はおそらくはその後の呼をスケジューリングするように構成されることが可能である。
【０１８０】
電話サーバ１９０８及び１９１０の各々は、例えばＴ−１カードやＭＳＩカードなどである、１つ又は複数の電話カード／ハードウェアを制御するようにそれぞれ構成された１つ又は複数のＣＡＬＬＨアプリケーション１９４８を備えることが可能である。これに対して、ＡＴＭカード／ハードウェアが、専用のＣＡＬＬＢアプリケーション１９４６により制御されることも可能である。ＣＡＬＬＨアプリケーション１９４８は、例えば電話呼の着信や電話を取ることなどの、新たなイベントに対する複数のハードウェアキューをモニタリングするように、また、ＣＴＩアプリケーション１９３０からのコマンドに基づいてこのような任意のイベントのための音声の呼及びファックスのルーティングを制御するように構成されることが可能である。実装によっては、１つのＣＴＩアプリケーション１９３０が、複数のＣＡＬＬＨアプリケーション１９４８を制御するように構成されることが可能である。それに代わって、１つのＣＡＬＬＨアプリケーション１９４８が、複数のＣＴＩアプリケーション１９３０によって制御される場合もある。それの割り当てられたハードウェアを制御するために、ＣＡＬＬＨアプリケーション１９４８は、ハードウェアの製造業者によって提供されるアプリケーションプログラミングインターフェース（ＡＰＩ）を使用するように構成されることが可能である。このようなＡＰＩは、例えば、呼を制御し、会議の開催を制御し、トーンを再生し、音声のメッセージを再生し、また音声を録音するために、必要なリソースを提供することができる。従って、このようなＡＰＩは、命令セットを定義するだけでなく、また、これらの命令によって使用されることが可能な応答／データを定義する。
【０１８１】
従って、ＣＡＬＬＨアプリケーション１９４８は、とりわけ、ＣＡＬＬＨアプリケーション１９４８が電話通信を効果的にルーティングすることができるように、ホスティングされる特定企業のプロジェクト／キャンペーン、電話メニュー、作業グループ及びエージェントに関する電話／ルーティング情報について認識させられることが可能である。例えば、電話サーバ１９０８に電話呼が着信すると、ＣＡＬＬＨアプリケーション１９４８は、ＣＴＩアプリケーション１９３０に対して、電話呼が受信されたことと、どのホスト上で電話呼が受信されたかについてと、どのＴ−１チャンネル上で電話呼が受信されたかについてと、その電話呼のためにどのＣＴバスの時間スロットが使用される予定であるかについてとを伝達するように構成されることが可能である。ＣＡＬＬＨアプリケーション１９４８はまた、その電話呼に関連付けられた任意の音声を送信するように構成されることが可能である。ＣＡＬＬＨアプリケーション１９４８から情報が受信されると、ＣＴＩアプリケーション１９３０は、特定のエージェントを呼び出してそのエージェントを着信する電話呼に接続するためのコマンドを、ＣＡＬＬＨアプリケーション１９４８に対して発行するように構成されることが可能である。ＣＡＬＬＨアプリケーション１９４８は、次に、エージェントのローカルな内線電話機／遠隔の内線電話機に電話をかけるように構成されることが可能であり、これにより、ＣＴバスの時間スロットは、エージェントが通話する／送信するために割り当てられる結果となる可能性がある。ＣＡＬＬＨアプリケーション１９４８は、次に、着信する電話呼にエージェントの時間スロットを受信しかつ聴取させ、かつエージェントの電話呼に着信する電話呼の時間スロットを受信しかつ聴取させ、両者を効果的に中継するためのコマンドを、電話サーバ１９０８に対して発行するように構成されることが可能である。
【０１８２】
例によっては、電話サーバ１９０８が電話呼の半分を直接に受信しないものがある。言い換えれば、一方の当事者の呼は電話サーバ１９０８へ着信しているが、もう一方の側は別の電話サーバへ着信している。従って、電話呼の２つの片割れは２つのサーバ間で中継されなければならない。ＣＡＬＬＢアプリケーション１９４６は、このような状況では、ＡＴＭカードを制御して、１つのサーバから発信しかつ別のサーバを宛先とする呼を中継するように構成されることが可能である。従って、電話サーバ１９０８及び１９１０は、ＡＴＭカード、又は他の何らかのタイプの高速な電話接続可能であるカードを備えることが可能であり、上記カードは、外部のＡＴＭスイッチに、又はギガビットイーサネットスイッチ等の同様のタイプのスイッチに接続される。ＡＴＭスイッチは、システム内の任意の２つのカードからデータをあちこちへ移動させるように構成されることが可能である。例えば、電話サーバ１９０８内のＣＡＬＬＢアプリケーション１９４６は、電話サーバ１９０８内のＴ−１カードに到来した顧客の電話呼であってかつ電話サーバ１９１０上のＭＳＩカードから出ていかなければならない電話呼がエージェントに接続することを促進するために、ＣＴＩアプリケーション１９３０によって使用されることが可能である。
【０１８３】
従来のシステムでは、ＣＴバスにおける所定範囲の時間スロットが任意の２つのサーバ間のＡＴＭ通信用に割り当てられる。ただしこれはスケーラブルなソリューションではなく、よって必ずしも好適ではない。このことは、ＡＴＭソリューションでは、潜在的に多くの時間スロットを用いて、広い帯域幅の接続性を提供することが好適であるということに起因する。その結果、サーバ間にわたるＡＴＭ接続性のためにＣＴバスのセグメントを静的に割り当てることは、１つの電話呼も発生しない間に、ＣＴバス内の全時間スロットを短時間のうちに使用してしまう可能性すらある。しかしながら、ここに記載したシステム及び方法によって構成される通信センターは、１つのサーバからもう１つの任意のサーバへのＡＴＭ接続のための、時間スロットの動的な割り当てを可能にすることができる。
【０１８４】
この動的な割り当てを達成するために、ＣＡＬＬＢアプリケーション１９４６は、あるサーバにおける着信する電話呼のための送信時間スロットを、例えば、エージェントのＭＳＩカードが受信して聴取することになるサーバ内の、もう１つの送信スロットへ「移動させる」ように構成されることが可能である。このプロセスについては、Ｔ−１スロット上の着信呼に関する図２１のフローチャートに関連して説明することができる。まずステップ２１０２では、電話サーバ１９０８においてＴ−１電話呼に関連付けられたＣＡＬＬＨアプリケーション１９４８は、着信する電話呼及び関連付けられた時間スロットについて、アプリケーションサーバ１９０４上のＡＣＤアプリケーション１９２８に通知するように構成されることが可能である。次にステップ２１０４において、ＡＣＤアプリケーション１９２８は、どのエージェントに対してその電話呼をルーティングするかということに関する情報をＣＡＬＬＨアプリケーション１９４８へ送信するように構成されることが可能である。
【０１８５】
次にステップ２１０６では、ルーティング情報が提供されることが可能であり、例えば、ＣＡＬＬＨアプリケーション１９４８は、電話呼をエージェントへルーティングすることに関する命令の要求をＣＴＩアプリケーション１９３０へ送信するように構成されることが可能である。次にステップ２１０８において、サーバ１９０８上の着信する電話呼が割り当てられた時間スロットは、エージェントとインターフェースをとるサーバに、例えばサーバ１９１０に移動されることが可能である。ＣＴＩアプリケーション１９３０は次に、ステップ２１１０において、電話サーバ１９１０内のＣＡＬＬＢアプリケーション１９４６に命令して、この割り当てられた時間スロットを電話サーバ１９１０へ「移動させる」ように構成されることが可能である。移動は、例えば、電話サーバ１９０８内のＡＴＭスイッチを介して電話サーバ１９１０に通信し、電話サーバ１９１０に、割り当てられた時間スロットを受信しかつ聴取することと、エージェントの端末８３０から受信された情報を、割り当てられた時間スロット上で送信することとを命令することによって発生しうる。
【０１８６】
次にステップ２１１０では、電話サーバ１９１０内のＡＴＭカードが、別の時間スロットを動的に割り当て、それを用いて、電話サーバ１９０８から受信するものをエージェントの端末８３０へ送信するように構成されることが可能である。ステップ２１１２では、例えば電話サーバ１９１０上のＭＳＩカードである電話サーバ１９１０が、受信する顧客の音声を、割り当てられた第２の時間スロットを用いてエージェントの端末８３０へ送信するように構成されることが可能である。
【０１８７】
ステップ２１１４では、電話呼がまだ進行中であるか否かが決定される。進行中であれば、プロセスはステップ２１０８へ戻ることが可能である。進行中でなければ、プロセスは終了することができる。顧客にエージェントの音声を聴かせる場合にも、同様のプロセスが使用される。従って、図２１に示したもののようなプロセスを使用することによって、帯域幅に多大な負の影響を与えることなく複数のサーバ間にわたる通信を確立することができる。
【０１８８】
複数のサーバ間で呼を転送する能力は、それらのサーバが異なるタイプのサーバであっても、又は転送が１つのタイプのカードから別のタイプへのものであっても、システム内のサーバ又はスイッチが故障した際の回復に有益である可能性がある。このことは、故障の際には代替のサーバ又はスイッチを介して通信をルーティングすることが可能であることに起因する。
【０１８９】
この点に関しては、例えば電話とＩＰとの間のような、１つのタイプの通信と別のタイプの通信との間での変換の能力もまた有益となりうる。例えば、複数の遠隔のエージェントが例えば電話機等の電話機器を用いて電話呼を処理している場合であって、エージェント側の電話機器に故障が生じている場合には、通信センターは、単に、着信する電話通信を、例えばＶｏＩＰ等のＩＰに基づく通信に変換して、エージェントに通信をルーティングし続けることができる。故障は、例えば、エージェントを電話会社の中央局に接続している、例えばＰＢＸ等のローカルな構内交換機の故障を含む可能性がある。
【０１９０】
このような切り換え、すなわち電話通信受信からＶｏＩＰへの切り換えの実施を支援するために、エージェントらは、多くの場合、当該エージェントの端末８３０を再構成しなければならなくなる。このことは、いくつかの方法で発生する可能性がある。例えば、エージェントらの端末８３０には、それらをＶｏＩＰ用に構成するように要求する電子メールが送信される場合があるが、このことは、例えば対話マネージャアプリケーション８４０を用いて達成することができる。それに代わって、管理者が例えば管理マネージャアプリケーション８３４を通じて介入し、エージェントらの端末８３０をＶｏＩＰ用に再構成する場合もある。可能性のあるもう１つのアプローチとしては、ホスティングされる企業を基準として変更を管理するもの、例えばホスティングされる特定の企業に関連付けられた設定を介して変更を管理するものがある。
【０１９１】
従って、複数のサーバ間にわたって通信のルーティングを変更し、また通信のタイプを変換する能力は、ここに記載したシステム及び方法によって構成される通信センターに、ある程度の弾力性を与える。弾力性とは、変更された条件に対して、いかなるサービス低下もなしに適合化するシステムの能力を指す。先に記述した能力はまた、通信センターに対して、ある程度のスケーラビリティを、すなわち要求に合わせてシステムのサイズを拡大したり又は縮小したりする能力を与える。弾力性及びスケーラビリティはまた、他の方法を用いて提供される場合もある。これらの方法のいくつかは、ソフトウェアのホットバックアップと、ウェブサーバのホットブートと、ソフトウェア及び／又はハードウェアの冗長性と、システムの残りの部分のデフォルトとを含む。
【０１９２】
ソフトウェアのホットバックアップは、特定のソフトウェアアプリケーションの２つ以上のインスタンス化を生成し、次にそのうちの一方をマスタとなるように構成し、他方をバックアップとなるように構成することを含む。マスタアプリケーション及び任意のバックアップアプリケーションは両方とも、他のアプリケーションからメッセージを受信して応答を生成するが、実際にその応答を送信するのはマスタアプリケーションのみである。ただし、マスタアプリケーション側においてソフトウェア又は関連付けられたハードウェアのいずれかに故障が生じれば、バックアップアプリケーションが介入して送信を開始する。従って、マスタアプリケーションと任意のバックアップアプリケーションとは、異なるサーバ上に存在し、例えばその固有のアプリケーションサーバ上にそれぞれ存在することが理想的である。そうすれば、ハードウェアに故障が生じても、それに起因してマスタアプリケーション及び任意のバックアップアプリケーションが両方とも故障することはない。
【０１９３】
このようなアプローチは、図１８に関連して述べたもののようなバスアーキテクチャを使用し、またＬＭＧＲアプリケーション１９３８を使用することによって、さらに拡張されることが可能である。先に述べたように、ＬＭＧＲアプリケーション１９３８は、どのアプリケーションがマスタでありかつどれがバックアップであるかを指示するように構成されることが可能である。従って、ＬＭＧＲアプリケーション１９３８は、アプリケーションのいくつか又はすべてに係るバックアップのインスタンス化が生成されていても、割り当てられたライセンス数を超過しないことを保証することができる。
【０１９４】
さらに、各アプリケーションのための関連付けられたホストサーバは、バスサーバアプリケーション１８１２を備えることが可能であり、これは同じホスト上のアプリケーションからメッセージを受信し、これらのメッセージを、例えば異なるホストを接続したＬＡＮを介してブロードキャストする。従って、あるアプリケーションが異なるホスト上のマスタアプリケーションに対してメッセージを生成すれば、そのメッセージは、関連付けられたバスサーバアプリケーション１８１２によってＬＡＮを介してブロードキャストされる。ブロードキャストメッセージが向かうように意図された宛先であるマスタアプリケーションと、バックアップアプリケーションとの両方は、次に、それらのバスサーバアプリケーション１８１２を用いてＬＡＮからメッセージを検索して読み出すことができる。ただし、バス上でブロードキャストされることになる応答を生成できるのは、マスタアプリケーションのみである。バックアップアプリケーションは応答を生成することはできるが、ＬＭＧＲアプリケーション１９３８によって命令されるまではその応答をＬＡＮを介してブロードキャストすることはない。
【０１９５】
ＬＭＧＲアプリケーション１９３８は、マスタアプリケーションに関連した故障を多数の方法で検出するように構成されることが可能である。まず、故障したマスタアプリケーションに関連付けられたバスサーバアプリケーション１８１２は、その故障を検出して、それをＬＭＧＲアプリケーション１９３８へ報告することができる。それに代わって、アプリケーションは、それがマスタアプリケーションから応答を受信することに失敗したときにその故障を検出し、当該故障を、例えばそのバスサーバアプリケーション１８１２を介して、ＬＭＧＲアプリケーション１９３８へ報告することができる。マスタアプリケーションに関連付けられたバスサーバアプリケーション１８１２にも影響するハードウェアの故障が生じている場合には、他のバスサーバアプリケーション１８１２が、マスタアプリケーションに関連付けられたバスサーバアプリケーションがもはやネットワークにおいて登録されていないか又は動作中（アクティブ）でないということを検出するように構成されることが可能である。この状態は、次にＬＭＧＲ１８１２へ報告されることが可能である。いったん、ＬＭＧＲ１８１２が、マスタアプリケーションに関連した故障を認識するに至ると、これはバックアップアプリケーションに引き継ぎを行うように命令することができる。
【０１９６】
ただし実際には、故障がマスタアプリケーションに影響を与えているという認識と、引き継ぎを行うことについてのバックアップアプリケーションへの通知との間には遅延が存在することが多い。この遅延の間に、応答及び／又は新たなメッセージが失われる可能性がある。従って、システムが即時にクラッシュすることはないにしても、システム状態は破壊される可能性があり、これにより最終的にシステムは故障する可能性がある。さらには、故障が発生していても検出されずにいる可能性もあり、その場合には、バックアップアプリケーションに引き継ぎの命令が決して発行されないことになる。
【０１９７】
従って、例えばシステムの故障が深刻な結末をもたらすような、ミッションがクリティカルな環境においては、原因又はそれを取り巻く状況に関わらず、リソースにおける故障の検出は保証される必要があり、マスタアプリケーションからバックアップアプリケーションへの遷移の間に応答メッセージは失われてはならない。ここに記載したシステム及び方法によって構成されるシステムでは、リソース故障の検出を保証するために多数の異なる方法を使用可能である。例えば、各アプリケーションは、システム内の他のアプリケーションからの「引き続き動作中である」ことについての確認情報を周期的に要求するように構成されることが可能である。これを実装するための費用に関して有効な方法は、各アプリケーションに、このような要求を受信した時点で状態の確認情報をその関連のバスサーバアプリケーション１８１２に送信させるというものである。それに代わって、アプリケーションは、他のアプリケーションによってその状態を自動的に確認することもできる。例えば、各バスサーバアプリケーション１８１２は、その状態と、同じホスト上で実行中の任意のアプリケーションの状態とについて、システム内の他のすべてのバスサーバアプリケーション１８１２に対して自動的に確認するように構成されることが可能である。従って、リソースの故障は、故障の原因に関わらず動的に確定されることが可能である。
【０１９８】
いったん故障が検出されると、バックアップアプリケーションが応答を送信し始める際に要する時間においてメッセージが失われていないことを保証するためのステップが実施される必要がある。メッセージが失われていないことを保証するために、アプリケーションは、メッセージの識別と、メッセージの巻き戻し及び実際の再生とを実行するように構成されることが可能である。例えば、メッセージは、一意的な３２ビットのアプリケーションＩＤ番号と３２ビットのメッセージ番号とを組み合わせることによって識別されることが可能である。そうすることにより、バックアップアプリケーションは、マスタアプリケーションが送信した最後の適正なメッセージを認識できるようになり、その時点以降のその応答を続行することが可能であるが、それ以上は動作しない。従って、バックアップアプリケーションは、それがマスタアプリケーションによって送信された最後の適正なメッセージに到達するまで、当該バックアップアプリケーションによって生成されたが送信されてはいないメッセージを巻き戻し、その時点から実際に再生又は送信を開始する必要のある場合がある。このプロセスを、巻き戻し及び実際の再生と呼ぶことが可能である。
【０１９９】
システム内にバックアップを存在させるためのソフトウェアアプリケーションの重複化は、ソフトウェアの冗長性の１つの形式である。他の形式については後述する。加えて、ハードウェアの冗長性も有益である可能性がある。ハードウェアの冗長性の１つの形式は、すでに述べたように、複数のアプリケーションサーバ及び／又は電話サーバのような複数のサーバを有することである。サーバの冗長性は、弾力性の見地からも有益となる可能性がある。さらに、サーバ又はホストが他のサーバとの通信の代替ルートを有することが有益である可能性もある。従って、例えば、冗長性をＬＡＮ自体に組み込んで、故障時にはこの冗長性を活用するようにバスサーバアプリケーション１８１２を構成することが可能である。これに関して、例えば、バスサーバアプリケーション１８１２は、可能な全通信ルートを備えたメッセージルーティングテーブルを保持することができる。１つのルートに故障が検出されれば、上記テーブルから代替ルートが選択され、上記テーブルは、その故障したルートを除外するように、又はそれが故障した状態を示すように更新されることが可能である。
【０２００】
状況によっては、着信するメッセージ又はイベントはキューに格納され、即時には処理されない場合がある。従って、バックアップアプリケーションは、対応するマスタアプリケーションが何のメッセージをいつ処理しているかということについて、必ずしも認識しているわけではない。こうした状況に対処し、また必要であればバックアップアプリケーションが介入できる態勢にあることを保証するために、マスタアプリケーションは、キューからメッセージを抽出した時点で、抽出されたメッセージに関連した情報をバックアップアプリケーションへ送信するように構成されることが可能である。このようにして、バックアップアプリケーションは、常にマスタアプリケーションの動作について通知を受け、必要に応じて介入する用意を調えておくことができる。
【０２０１】
もう１つの形式に係るソフトウェアの冗長性は、ソフトウェアのホットブートと同様のものであって、単に、複製して二重になったアプリケーションに係る二重の演算がメッセージの衝突を引き起こさない限りにおいて、上記複製して二重になったアプリケーションをシステム内で動作させることである。例えば、同時に動作する２つ以上のＬＭＧＲアプリケーション１９３８が存在している可能性がある。ただし、ＬＭＧＲアプリケーション１９３８の各々は同じライセンス制限を実施しているはずである。従って、各ＬＭＧＲアプリケーション１９３８が単に動作することと、ライセンス制限の監視に関するメッセージを送信することとを許容されているだけであれば、衝突は引き起こされないであろう。１つのＬＭＧＲアプリケーション１９３８が故障しても、他のものが動作を継続し、システムは正しく機能する。
【０２０２】
実際に、複数の場所における、ライセンスを受けた複数のサーバ上で、複数のＬＭＧＲアプリケーション１９３８を同時に実行させることは、災害復旧の見地からは実際に好適である可能性がある。このことは、ハードウェアの冗長性と、ソフトウェアのホットバックアップを含むソフトウェアの冗長性とを備えることができたとしても、ＬＭＧＲアプリケーション１９３８が無力化されればどうなるか、という問題点に起因する。ライセンスを受けた複数のサーバを複数の場所で動作させれば、ライセンスを受けたサーバの１つが機能を停止しても、適正な使用制限を保証できる。従って、ある実施形態では、ライセンスを受けた各サーバ上における各ＬＭＧＲアプリケーション１９３８が、例えば地理的な場所に基づいて、システムの一部に対して使用制限を実施することができる。ただし、各ＬＭＧＲアプリケーション１９３８はまた、他のすべてのＬＭＧＲアプリケーション１９３８をスキャンして、グローバルな使用制限を決定するとともに、各ＬＭＧＲアプリケーション１９３８に対する使用制限を決定するように構成されることも可能である。ＬＭＧＲアプリケーション１９３８のうちの１つが機能を停止しても、他のものがこれを引き継ぐことができる。また、ＬＭＧＲアプリケーション１９３８は、異なる場所に設けられ、好適にはこの目的に沿って異なる地理的な場所に設けられるので、すべてのＬＭＧＲアプリケーション１９３８が同時に機能を停止する見込みを最小化することができる。
【０２０３】
ソフトウェアのホットバックアップは、例えば、ネットワークゾーンの弾力性を保証する際に効果的である可能性がある。ウェブサーバのホットブートは、ウェブゾーンの弾力性を保証する際に効果的である可能性がある。ウェブサーバのホットブートは、ウェブゾーンに含まれる複数のウェブサーバに、ハードウェアの冗長性を与えることを含む。従って、例えば、ウェブゾーン８０４には２つ以上のウェブサーバ８１０が含まれる可能性がある。第１の主要なウェブサーバが故障した場合、ユーザセッションは、標準的なＤＮＳサーバ機能を用いて代わりのウェブサーバへリダイレクトされることが可能である。インターネットマネージャアプリケーション等のネットワークゾーン８０２のアプリケーションは、代替のウェブサーバに、それが効果的に動作するために必要とする全情報をロードするように構成されることが可能である。
【０２０４】
ただし、システムのセキュリティの見地からすると、通信に係る人員の識別情報を、それらの人員が代替ウェブサーバとインターフェースをとった時点で確立することが望ましいという可能性がある。例えば、上述のユーザセッションＩＤは、この目的にのために使用可能である。このようなユーザセッションＩＤは、所定の実装では、主要なウェブサーバに関連付けられた３２ビットのウェブホストＩＤ番号と、３２ビットの乱数とで形成されることが可能である。ユーザが次にこのユーザセッションＩＤを用いて代替のウェブサーバに対し自身を認証させようと試みるとき、代替のウェブサーバは、そのユーザセッションＩＤが有効か否かについてインターネットマネージャアプリケーションに照合できるまで、ユーザのセッションを存続させるように構成されることが可能である。ユーザセッションＩＤが無効であれば、ユーザは例えばログアウト画面へ進まされる可能性がある。
【０２０５】
これに対して、ユーザセッションＩＤが有効であれば、ソフトウェアのホットバックアップのアプローチと同様のアプローチを実行することができる。例えば、ウェブサーバのホットブートでは、インターネットマネージャアプリケーションは、最初のウェブサーバについて計算された故障地点に基づいて、新たなウェブサーバに情報を送信する、すなわち新たなウェブサーバをホットブートすることができる。ソフトウェアのホットバックアップでは、上述の方法を用いてアプリケーションの故障地点を確定することができる。ウェブサーバのホットブートでは、インターネットマネージャアプリケーションが、ユーザから受信した最後の「動作」を識別することによってウェブサーバの故障時刻を確定することができる。
【０２０６】
ユーザアプリケーションはといえば、これは、ｐｉｎｇ／動作応答を最後に受信した時刻を識別することにより、ウェブサーバの故障時刻を確定することができる。従って、インターネットマネージャアプリケーション及びユーザのアプリケーションはともに、新たなウェブサーバに対するメッセージを巻き戻しまたリプレイするように構成されることが可能である。ただし、このリプレイは、必ずしも実際の再生と同一ではない。さらに、インターネットマネージャアプリケーションは、ユーザ状態メッセージを新たなウェブサーバへ送信して、ユーザのアプリケーションを最新のシステム情報で更新させるように構成されることが可能である。従って、ウェブサーバの故障にも関わらず、通信のコンテキストを保存可能であり、通信損失を防止可能であり、ユーザは故障に気づかない場合すらある。
【０２０７】
これまでに説明した方法を使用すれば、通信システムはいつまでも機能停止することなく動作状態に維持されうるということ、すなわち、故障は検出されかつバックアップは適正に処理されるということを保証できるので、例えば、ネットワークマネージャアプリケーションをリアルタイムで用いて、アプリケーションを開始させ、終了させ、また構成させることが可能である。実際には、構成メッセージを受信した後、アプリケーションは、受信された構成メッセージに基づいて即時に異なる動作を開始するように構成されることが可能である。従って、通信センター８００等のようなシステムは、例えばシステムのアップグレード又はダウングレードを実施するための停止（シャットダウン）を回避することができる。言い換えれば、少なくとも理論上は、システムを機能停止することなく永久に動作状態に維持することが可能である。このことは、機能停止することなく常に動作状態でなければならないミッションがクリティカルなシステムにとって極めて重大なことである。
【０２０８】
以上、本発明の所定の実施形態について説明したが、説明した実施形態は例示的なものにすぎないということは理解されるであろう。従って、本発明は、説明した実施形態に基づいて限定されるべきものではない。ここに記載した本発明の範囲は、上述の説明及び添付の図面に関連して考察される添付の請求の範囲に照らしてのみ限定されるべきものである。
【図面の簡単な説明】
【０２０９】
【図１】本発明に係る分散型通信センターの例示的な実施形態を示す図である。
【図２】本発明に係る分散型通信センターのもう１つの実施形態のサンプルを示す図である。
【図３】図２の分散型通信センターに含まれるウェブサーバにアクセスするための例示的な方法を示すフローチャートである。
【図４】本発明の一実施形態に係る対話マネージャに対する例示的なグラフィカルユーザインターフェースのスクリーンショットである。
【図５】本発明の一実施形態に係るチャットマネージャに対する例示的なグラフィカルユーザインターフェースのスクリーンショットである。
【図６】本発明の一実施形態に係る監督マネージャに対する例示的なグラフィカルユーザインターフェースのスクリーンショットである。
【図７】本発明の一実施形態に係る管理マネージャに対する例示的なグラフィカルユーザインターフェースのスクリーンショットである。
【図８】本発明の一実施形態に係る分散コールセンターのもう１つの例示的な実施形態を示す図である。
【図９】図８の分散型通信センターのウェブゾーンに含まれるユーザセッションハンドラアプリケーションに対する例示的な動作方法を示すフローチャートである。
【図１０】図９のフローチャートに示した動作方法を実装するように構成されたユーザセッションアプリケーションを備えることが可能な例示的な機能を示す論理ブロック図である。
【図１１】図８の分散型通信センターのウェブゾーンに含まれるユーザ状態送信アプリケーションに対する例示的な動作方法を示すフローチャートである。
【図１２】図１１のフローチャートに示した動作方法を実装するように構成されたユーザ状態送信アプリケーションを備えることが可能な例示的な機能を示す論理ブロック図である。
【図１３】図８の分散型通信センターのウェブゾーンに含まれるユーザ状態受信アプリケーションに対する例示的な動作方法を示すフローチャートである。
【図１４】図１３のフローチャートに示した動作方法を実装するように構成されたユーザ状態受送信アプリケーションを備えることが可能な例示的な機能を示す論理ブロック図である。
【図１５Ａ】図８の分散型通信センターに実装可能な従来のｐｉｎｇプログラム実行方法を示す図である。
【図１５Ｂ】本発明の一実施形態に係る図８の分散型通信センターに実装可能なｐｉｎｇプログラム実行の例示的な方法を示す図である。
【図１６】図８の分散型通信センターのウェブゾーンに含まれる非リアルタイムのシステム状態送信／受信アプリケーションを含むことが可能な例示的な機能を示す論理ブロック図である。
【図１７】図８の分散型通信センターのウェブゾーンに含まれる、遠隔のデータベース／ファイルハンドラのアプリケーションを含むことが可能な例示的な機能を示す論理ブロック図である。
【図１８】図８の分散型通信センターのウェブゾーンに含まれるバスサーバアプリケーションの例示的な実施形態の動作を示す論理ブロック図である。
【図１９】本発明の一実施形態に従って構成されて図８の分散型通信センターに含まれる例示的なネットワークゾーンを示す図である。
【図２０】図１９のネットワークゾーンに含まれる電話サーバを備えることが可能な例示的な構成要素を示す論理ブロック図である。
【図２１】図２０の電話サーバのような複数の電話サーバにわたって、着信する通信を中継する例示的な方法を示すフローチャートである。
【図１】
2005530372.tif 000008
【図２】
2005530372.tif 000009
【図３】
2005530372.tif 000010
【図４】
2005530372.tif 000011
【図５】
2005530372.tif 000012
【図６】
2005530372.tif 000013
【図７】
2005530372.tif 000014
【図８】
2005530372.tif 000015
【図９】
2005530372.tif 000016
【図１０】
2005530372.tif 000017
【図１１】
2005530372.tif 000018
【図１２】
2005530372.tif 000019
【図１３】
2005530372.tif 000020
【図１４】
2005530372.tif 000021
【図１５Ａ】
2005530372.tif 000022
【図１５Ｂ】
2005530372.tif 000023
【図１６】
2005530372.tif 000024
【図１７】
2005530372.tif 000025
【図１８】
2005530372.tif 000026
【図１９】
2005530372.tif 000027
【図２０】
2005530372.tif 000028
【図２１】
2005530372.tif 000029
【国際調査報告】
2005530372.tif 000030
2005530372.tif 000031
2005530372.tif 000032