JP3712598B2 - 割り当て方法及び割り当てデバイス - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はコールセンターパケットルーティングに関し、特に、インターネットコールセンターを介して処理される電子商取引及び他の消費者ベースのサービスに関する。
【０００２】
【従来の技術】
【発明が解決しようとする課題】
インターネットベースのサービスが発展するに連れて、数多くのビジネス関連及び他の企業が、発呼者及び顧客がサービスにアクセスし、情報を要求し、音声及びデータアプリケーションを協調して用いるエージェントと協同することができるような、インターネットベースのアクセス方法を積極的に開発しつつある。これらのセッションは、通常、発呼者のウェブブラウザ（web browser）からの接続要求を介して開始される。多くの企業は、その企業が非常に大規模である、実質的に大容量の処理を経験している、あるいはその企業が地理的に分散しているなどの理由から、発呼者のブラウザによって開始される接続要求を処理する目的で複数個のインターネットコールセンターを管理している。複数個のインターネットコールセンターを管理している企業は、最も効果的かつ効率的なコールセンターサービスを企業全体にまたがる規模で提供することを強く希望している。なぜなら、顧客サービス品質とリピートビジネス数量との間には強い相関が存在するからである。また、サービス品質は、発呼者を、適切なウェブベースアプリケーション、適切なコールセンター、及び、その処理を行なう適切なエージェントに対して如何に接続するかに依存している。しかしながら、現在のブラウザ起動アプリケーションは静的なルーティングアルゴリズムに依存しており、発呼者は、通常、特定の企業のウェブページに係るグラフィカルユーザインターフェースボタンをクリックして、所定のコールセンター、アプリケーション、あるいは他のサービスに接続されるようになっている。企業規模のコールセンターグループ内での別のコールセンターから、より改善されたサービス品質を、発呼者が受容できる可能性が依然として存在する。
【０００３】
【課題を解決するための手段】
インターネットコールセンターのサービス品質は、本発明の原理に従って、全ての発呼者からのブラウザ開始接続要求を単一のインターネットインターフェースコントローラに対して供給することによって、効率的かつ効果的に強化される。発呼者の接続要求を受信すると、インターネットインターフェースコントローラにおいて、ルールに基づくルーティングが適用され、企業規模のコールセンタードメインの中から当該接続要求に応じるのに最も適したコールセンターが決定される。当該接続要求に応じるのに最も適したコールセンターを適切なデスティネーションコールセンターとして識別する、予めルーティングされた接続要求が生成され、その後、コールセッションが発呼者と適切なデスティネーションコールセンターとの間で設定される。
【０００４】
インターネットインターフェースコントローラが個々のルーティング決定をなすためのルールよりなるデータベースは、その企業のコールセンターに係る特定のニーズ、プライオリティ、及び能力に従って形成される。本発明の一実施例においては、エージェントが利用可能になるまでに発呼者がキューで待機している総時間量を最小化することが望まれるため、発呼者は、企業規模のコールセンタードメインに属するコールセンターの中で最も短い待機者キューを有するコールセンターに接続される。本発明の別の実施例においては、特定のコールセンターにおいてのみ利用可能なエージェントの特別の能力あるいは専門技術を利用することが不可欠な場合には、発呼者は、他の考慮事項、例えば発呼者キューの長さなどに関わらず、その特定のコールセンターに接続される。
【０００５】
【発明の実施の形態】
図１は、本発明の原理に従った、複数個のインターネットコールセンターすなわちインターネットコールターミネーションポイント間での企業規模でのインテリジェントインターネットルーティング方式を実現するために用いられるインターネットインターフェースコントローラ（ＩＩＣ）のアーキテクチャ配置例を模式的に示すブロック図である。複数の顧客、情報要求者、協力者、及び消費者が発呼者１１０として示されており、それぞれが、企業規模のコールセンターネットワークを代表している単一あるいは複数個のコールセンター１２０に関連するエージェントすなわちサービスにアクセスすることを望んでいる。発呼者１１０は公共のインターネット１５０を介してコールセンター１２０にアクセスするように示されており、及び、インターネットインターフェースコントローラ１７０と個々のコールセンター１２０が公共のインターネット１５０を介して通信するように示されているが、本発明の原理が、企業規模のコールセンターネットワークを構成している個々のコールセンター間でのインテリジェントな協調目的でのあらゆるパケットベースのネットワークに対して等しく適用可能であることは当業者には明らかである。
【０００６】
図１には発呼者１１０の二つのタイプが示されている。発呼者１１０−１は、通常、発呼者によって選択されたインターネットサービスプロバイダ（ＩＳＰ）１５２を介して公共のインターネット１５０を介してコールセンター１２０との間でのデータ接続を設定するデータ端末、例えばＰＣ１１２、のみを用いる発呼者である。ブラウザ機能によってインターネットをアクセスすることが可能なたのデータ端末、例えばパーソナルデジタルアシスタント、もＰＣ１１２と等価なものとして企図されていることに留意されたい。発呼者１１０−２は、ＩＳＰ１５２を介して公共のインターネット１５０に接続されたデータ端末、例えばＰＣ１１２、を用いる発呼者を表わしているが、発呼者１１０−２は、公衆交換電話ネットワーク（ＰＳＴＮ）１５４へアクセスするための電話１１４をさらに有するようになっている。説明を簡潔及び明瞭にする目的で、発呼者１１０−１と発呼者１１０−２は、以下、本明細書においては、各発呼者の機能の差異が本発明の原理を理解するために重要である場合を除いては、集合的に発呼者１１０と記述される。同様に、総数でｎ個のインターネットコールセンター１２０（コールセンター１２０−１、１２０−２、．．．、１２０−ｎ）が図示されているが、企業規模のコールセンターシステム内での個々のコールセンター間の差異が本発明の原理の記述及び理解に必要とされる場合以外は、単一のコールセンター１２０に対する参照がなされる。
【０００７】
以下、発呼者１１０が、企業規模のコールセンターシステム内のコールセンター１２０のうちの一つにおけるエージェントとのセッションを開始すると仮定する。ここでは、少なくとも三つの独特の通話セッションタイプが企図されている。すなわち、ボイス・オーバー・インターネットプロトコル（ＶｏＩＰ）セッション、テキストチャットセッション、及びコールバックセッションである。企業のウェブサイトへのＶｏＩＰセッション接続は、ＶｏＩＰアプリケーションを実行しているマルチメディアＰＣ１１２から開始される。テキストチャットセッション接続は、マルチメディア機能を有さないＰＣから企業のウェブサイトへアクセスする際に用いられ、それゆえ、ＶｏＩＰ会話の代わりに、エージェントとの間の純粋なテキスト及びデータの交換のみがなされる。コールバックセッションは、発呼者１１０による、エージェントの当該発呼者１１０へのコールバック要求によって開始される。このコールバック要求は、利用可能なエージェントに関する待機が長すぎる、ＩＰネットワーク混雑があまりにも激しい、発呼者が特定のトランザクションあるいは情報交換に電話を用いることを希望する、発呼者が単一の電話回線しか有していない、あるいは単にコールバックセッションが開始された時刻が発呼者１１０にとって都合が良くないなどの理由による。
【０００８】
企業のウェブサイト（図示せず）をアクセスするためにウェブブラウザを用いる一方、発呼者１１０は、ここでのシナリオ例においては、企業のウェブサイトに係るウェブページからＶｏＩＰ通信オプション及びＣＡＬＬ＿ＵＳ要求を選択する。ＣＡＬＬ＿ＵＳ要求はコモンゲートウェイインターフェース（ＣＧＩ）スクリプトを実行するトリガーとなり、この場合のＣＧＩは、就中、通話タイプ及び当該ＣＧＩがトリガーされたウェブページのユニバーサルリソースロケータ（ＵＲＬ）などの関連する情報及びパラメータをキャプチャする。ＣＧＩスクリプトにはコールターミネーションサイトのアドレスが予めプログラムされており、発呼者の要求は、関連する情報及びパラメータと共に、ＩＳＰ１５２及び公共のインターネット１５０を介してコールターミネーションサイトに伝達される。
【０００９】
従来技術に従って、コールターミネーションサイトは、企業の複数個のコールセンターのうちの予め選択されたものである。各コールセンター１２０は、通常、インターネットコールマネージャ（ＩＣＭ）１２８、プライベートブランチ交換機（ＰＢＸ）１２２、テレフォニーサーバ（Ｔサーバ）１３０、インターネットテレフォニーゲートウェイ（ＩＴＧ）１２６、及び、少なくとも一つのエージェントワークステーション１３２を有している。エージェントワークステーションは、通常、エージェントワークステーションＰＣ１３４及びエージェント電話機１３６より構成される。代表的なＰＢＸ１２２の機能ブロックアーキテクチャには、ポートサイド機構１４６、エージェント選択エンジン１４４、コールキューバッファ１３８、コールルーティングエンジン１４０、及びＰＳＴＮ１５４との接続目的の基幹回線１４２が含まれるように例示されている。図１に示された実施例においては、オプションではあるがしばしば用いられている、企業のファイアウォール１２４が示されている。受信側コールセンター１２０においては、要求がインターネットコールマネージャ（ＩＣＭ）１２８によって受信される。ＩＣＭ１２８は、発呼側ＵＲＬ及び選択された通話タイプ（例えばＶｏＩＰ、テキストチャット、コールバックなど）などの関連する情報及びパラメータを解釈し、当該コールセンター内でのエージェントの利用可能性をチェックし、及び、この情報をコールセンターのテレフォニーサーバ（Ｔサーバ）１３０と通信する。Ｔサーバ１３０はコールセンターＰＢＸ１２２に対して組み込みコンピュータテレフォニーインテグレーション（ＣＴＩ）リンクを介して接続されてインターフェースされている。あらゆるＰＢＸあるいは交換機構におけるＣＴＩリンクは、ＰＢＸ１２２において発生する全てのコールアクティビティをモニタし、各アクティビティイベント−例えば、コール受信、エージェントのオンフックへの移行、エージェントのオフフックへの移行など−をＴサーバ１３０宛に報告する目的で用いられる。Ｔサーバ１３０は、それに応答して、コールセンター１２０における種々のエージェントの現在の状況及び他のコールアクティビティイベントに関してＩＣＭ１２８を更新する。ＩＣＭ１２８は、それがサービスを提供しているコールセンターに係る種々のアクティビティ及びパラメータ、例えば、キュー内のコール数、利用可能なエージェント数、種々のエージェントの特別の専門技術及び資格など、を管理している。ＣＡＬＬ＿ＵＳ要求がＩＣＭ１２８によって受信され、かつ、要求がＶｏＩＰコールタイプ要求であることが認識されると、ＩＣＭ１２８は、インターネットテレフォニーゲートウェイ（ＩＴＧ）１２６がコールセンター内の適切なエージェントへの関連するコールを設定することをトリガーするメッセージを、ＩＴＧ１２６のＰＢＸ１２２に対する接続が実現されているＩＳＤＮ／ＰＲＩ機構を介して送出する。データ及びテレフォニー機能を有するように設定されたマルチメディアワークステーション１３２を有するエージェントは、テレフォニー、データ（例えばテキスト）、テレフォニーとテキストの組み合わせ、コラボレーション、ウェブページプッシュなどを介して、コールに対してサービスを提供することが可能である。
【００１０】
ＩＣＭ１２８はコールを関連するコールセンターの適切なエージェントあるいはリソースにルーティングすることが可能であるが、コールセンターは、現時点では、企業のコールセンター全体の中から最も適切な企業エージェントあるいはリソースにコールをルーティングすることは不可能である。例えば、ＣＡＬＬ＿ＵＳ要求はコールセンター１２０−１によって受信され、発呼者１１０がエージェントとのインターフェースを必要としているとする。当該トランザクションを最も適切に取り扱うことができる特定の能力すなわち専門技術をそのエージェントが有している可能性もあるが、コールセンター１２０−１ではそのような特別の才能すなわち専門技術を有するエージェントが利用不可能である可能性もあり、また、このような能力すなわち専門技術を実際に有するエージェントが当該企業内の別のコールセンター、例えばコールセンター１２０−２において利用可能である可能性もある。
【００１１】
本発明は、企業のコールセンター内での特別の予め決定されたコールセンターの代わりに、新たなインターネットインターフェースコントローラ（ＩＩＣ）１７０を、ＣＡＬＬ＿ＵＳ要求の初期コールターミネーションサイトとして利用する。その結果、ＣＡＬＬ＿ＵＳ要求を受信すると、ＩＩＣは、企業全体に亘って考慮して当該コールに対してサービスを提供するのに最も適したエージェント及びコールセンターを決定し、発呼者１１０と最も適したコールセンター１２０との間のコールセッションを開始する。ここでの例では、コールセンター１２０−２が当該通話に対してサービスを提供するのに最も適した能力すなわち専門技術を持ったエージェントを有しているものと仮定されており、コールセッションが発呼者とコールセンター１２０−２におけるその特定のエージェントとの間で設定される。
【００１２】
インターネットインターフェースコントローラ（ＩＩＣ）１７０がネットワークサーバを用いて実装されるように示されているが、本発明の原理の具体化が、ストレージデバイスへのアクセス機能を有し、ネットワークを介して個々のコールセンター１２０との間で情報交換を行なうように接続された、あらゆるマイクロプロセッサデバイスを用いて実現可能であることは当業者には明らかである。図１に示された実施例においては、ＩＩＣ１７０のホストとして機能している企業サイト１６０が、コールセンター１２０−１から１２０−ｎとの間での情報交換を行なう目的で、企業ファイアウォール１６２を介してインターネット１５０に接続されている。ＩＩＣ１７０は、既存の企業コールセンター１２０のうちの一つに統合されている、あるいは、コールセンター１２０を管理しないリモートかつ共有企業サイト内に存在する、あるいは、ＩＩＣ１７０に対する専用ホストとして機能しているロケーションに位置する、もしくは、その企業ではないサービスプロバイダによって提供されるサービスとして管理されている、もしくは、本発明の原理に従って記述されているものと同一の機能及びサービスを提供することが可能な他のあらゆるロケーション及び配置を有している、ということも当業者には明らかである。
【００１３】
ここで示されているインターネットインターフェース（ＩＩＣ）１７０アーキテクチャ例には、リスナ１７２、データ貯蔵部１７４、ルールエンジン１７６、及びルーティングエンジン１７８という四つの互いに関連した基本的機能コンポーネントが含まれている。 本発明の原理に従って、ＣＡＬＬ＿ＵＳ要求が（従来技術において特徴的な、個々のコールセンター１２０の代わりに）リスナ１７２に位置するインターネットインターフェースコントローラ（ＩＩＣ）１７０によって受信される。このことは、ＣＡＬＬ＿ＵＳ要求に係るパケットアドレスを、特定の企業のコールセンター１２０のアドレスではなく、ＩＩＣ１７０のアドレスに指定することによって実現される。その後、リスナ１７２は、ＣＡＬＬ＿ＵＳ要求を解析し、解析されたデータをルーティングエンジン１７８に供給する。ルーティングエンジン１７８はその要求を受信し、それが当該要求をルールエンジン１７６によって供給されるルールベースのパラメータに従って転送すべき最も適切なコールセンターを決定し、当該要求をその最も適切なコールセンター１２０宛に転送する。ルールエンジン１７６は、ルーティングエンジン１７８に対して、ルーティング決定をなす際に用いられる種々のプログラムされたルールを供給する。ルーティングエンジン１７８は、企業システム管理によって指定されてルールエンジン１７６によって供給されるルール内に組み込まれた種々のルーティングプロパティに基づいて適切なコールセンターを決定する。例えば、ルーティング決定は、単一あるいは複数個の以下の特性のうちから、単体として採用されたもの、あるいは種々の特性の優先順位付けを行なうために重み付けアルゴリズムを用いて組み合わせられたものなどに基づいてなされる。この種の特性には、マーケッティングデータ、エージェントの専門技術、ヒストリカルな、すなわち数量化されたリアルタイムのコールセンター状況（すなわち、コールセンターのコール密度、コール長など）、発呼者によって入力された情報、要求が発せられたウェブページのＵＲＬなどが含まれる。この特性のリストは単なる例示目的のものであって、排他的なものと見なされるべきではない。従って、他の特性及びパラメータも、本発明を実現するという状況及びその原理に従って、ルーティングエンジン１７８によるルーティング決定の際に用いられうるということが企図されている。
【００１４】
データ貯蔵部１４は、個々のコールセンター１２０のインターネットコールマネージャ（ＩＣＭ）１２８から、コール記録イベント、リソース能力、リソース使用率、エージェントの専門技術、エージェントの利用可能性などに係る更新された情報を周期的に供給される。それゆえ、インターネットインターフェースコントローラ（ＩＩＣ）１７０は、発呼者１１０からのＣＡＬＬ＿ＵＳ要求（及びそれ以降に設定されるコール）を、複数個の企業コールセンター１２０−１から１２０−ｎのうちの最も効率的かつ最も効果的なコールセンターすなわちコールターミネーションポイントに振り向けるように機能する。例えば、ＣＡＬＬ＿ＵＳ要求は、スペイン語を話すエージェントが特定の企業コールセンターにおいてのみ利用可能である場合には、スペイン語を話すエージェントへの要求を、コールセンターのコール密度、容量、地理的近接性、エージェントの専門技術などに依らず、他の全ての考慮事項よりも優先する、という要求を含む可能性がある。第二の例としては、企業マネジメント及びシステム管理者が、予約要求が他のタイプのコールよりも高い優先度で処理されなければならないと決定した場合には、企業の予約ウェブページ（図示せず）から開始されたあらゆるＣＡＬＬ＿ＵＳ要求は、他のコール特性に依らず、企業全体でのあらゆるコールセンターのうちで最初に利用可能になったエージェント宛に転送される。
【００１５】
図２から図５は、本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）を用いるエンド−ツー−エンドコールフローシーケンス例を示す流れ図である。段階２０２では、発呼者１１０が、企業のウェブページから“Ｃａｌｌ Ｕｓ”ボタンを選択することによってコンタクトを開始する。この選択に応答して、サーバに存在し、発呼者１１０のブラウザインターフェースをサポートするＣＡＬＬ＿ＵＳ要求コモンゲートウェイインターフェース（ＣＧＩ）スクリプトがトリガーされる（段階２０４）。ＩＩＣ１７０のアドレスをデスティネーションアドレスとして有するＣＡＬＬ＿ＵＳ要求が、発呼者のＰＣ１１２から発呼者のインターネットサービスプロバイダ（ＩＳＰ）１５２及び公共のインターネット１５０を介して発信され、段階２０６でＩＩＣ１７０におけるリスナ１７２によって受信される。段階２０８では、ＩＩＣ１７０が適切なコールタイプを決定する。
【００１６】
リスナが適切なコールタイプを決定するために用いる一方法例が図６に示されている。段階３０２では、インターネットインターフェースコントローラ（ＩＩＣ）１７０に位置するリスナ１７２が、発呼者１１０からのＣＡＬＬ＿ＵＳ要求を受信する。このことに応答して、リスナ１７２は当該コールに係るスケルトンコール記録を生成する。スケルトンコール記録は、固有のコールパラメータ及び情報に関連する空のデータフィールドを有しており、その後、適切なパラメータ及び／あるいは情報が受信され、構文解析され、決定され、及び解釈されるに従って空のデータフィールドにデータが書き込まれる。例えば、段階３０６では、リスナがＣＡＬＬ＿ＵＳ要求に係るソースＩＰアドレスを解析する。段階３０８では、リスナは前記ソースＩＰアドレスが有効なＩＰアドレスであるか否かを決定する。なぜなら、受信されたパケットの全てが必ずしも有効なＩＰアドレスを有している必要がないからである。ソースＩＰアドレスが有効なＩＰアドレスであると決定された場合には、段階３１０において、データ貯蔵部１７４におけるメモリにストアされたコール記録の適切なデータフィールドにデータが書き込まれる。しかしながら、ソースＩＰアドレスが利用可能ではない場合、あるいは、前記ソースＩＰアドレスが有効ではないと決定された場合には、ソースＩＰアドレスはコール記録には書き込まれない。
【００１７】
ソースＩＰアドレスが利用可能であるか否か、あるいは、ソースＩＰアドレスが有効なＩＰアドレスであるか否かにかかわらず、リスナは当該コールに係るコールＩＤ／事由を決定する。このことは、コール事由を決定する目的でＣＡＬＬ＿ＵＳ要求メッセージを構文解析するによって実現される。コール事由は、通常、その要求が発せられた企業ウェブページのＣＧＩスクリプトに帰属され、ＣＧＩスクリプトを開始する動作の際にＣＡＬＬ＿ＵＳ要求内のデータフィールドに含められる。ひとたび決定されると、コールＩＤ／事由は、データ貯蔵部１７４におけるメモリ内にストアされたコール記録の適切なデータフィールドに書き込まれる（段階３１０）。
【００１８】
その後、リスナはＣＡＬＬ＿ＵＳ要求からソースユニバーサルリソースロケータ（ＵＲＬ）を構文解析する（段階３１４）。段階３１６では、ＵＲＬが非零値であるか否かが決定される。構文解析されたＵＲＬが非零値である場合には、そのＵＲＬ値がデータ貯蔵部１７４におけるメモリ内にストアされたコール記録の適切なデータフィールドに書き込まれる（段階３１０）。ゼロすなわちヌルＵＲＬ値はＵＲＬがＣＡＬＬ＿ＵＳ要求に含まれていなかったことを示しており、それゆえ、ヌル値ＵＲＬはデータ貯蔵部１７４におけるメモリ内にストアされたコール記録の適切なデータフィールドに書き込まれない。
【００１９】
構文解析されたＵＲＬが非零値であるかヌルかに依らず、ＣＡＬＬ＿ＵＳ要求はコールタイプを決定する目的で構文解析される（段階３１８）。ここで説明されている本発明の実施例においては、発呼者１１０によって特定のコールタイプが選択されていない場合には、開始側ＣＧＩスクリプトが所定のコールタイプ値をコールタイプフィールドに割り当てる。段階３２０においてリスナ１７２がコールタイプフィールドがヌル値であると決定した場合、すなわち、コールタイプが規定されていない場合には、段階３２２においてコールタイプがデフォールトのテキスト−チャットコールタイプにセットされる。その後、テキスト−チャットコールタイプの選択は、データ貯蔵部１７４におけるメモリ内にストアされたコール記録の適切なデータフィールドに書き込まれる（段階３１０）。しかしながら、コールタイプ値が非零値である場合には、段階３２４において、顧客によって入力された情報がＣＡＬＬ＿ＵＳ要求から構文解析され、データ貯蔵部１７４におけるメモリ内にストアされたコール記録の適切なデータフィールドに書き込まれる（段階３１０）。この時点において、データ貯蔵部１７４にストアされたコール記録は、着信コールに係る固有の情報の全てを表わすフィールド値を有している。さらに、コールセンターによって定義されうるパラメータが構文解析されてデータ貯蔵部内にストアされうるが、これらは当業者には明らかである。
【００２０】
図２に戻って、段階２１０では、インターネットインターフェースコントローラ（ＩＩＣ）１７０のルーティングエンジン１７８が、ＩＩＣのデータ貯蔵部１７４内にストアされたコール記録を読み出し、ＩＩＣのルールエンジン１７６からのルールベース入力と共に、企業全体に亘るコールセンター１２０のうちのいずれが当該コールに対してサービスを提供するのに最も適しているかを決定する。例えば、段階２１２では、ルールエンジン１７６がルーティングエンジン１７８に対してリアルタイムイベントデータを利用しないことを指示するようにプログラムされている場合には、ルーティングエンジンは、段階２１４において、排他的にあるいは他の以下に記述されるルーティングアルゴリズムコンポーネントと共に、イベントドリブンエンジンとして機能する。ルールエンジン１７６が、リアルタイムイベントエンジンとして用いられる際にリアルタイムデータを取得するために用いる方法の一例が、図７に示されている。
【００２１】
図７は、本発明の原理に従って、企業全体に亘るコールセンターのうちの適切なものに対するコールルーティングを決定する際にインターネットインターフェースコントローラ（ＩＩＣ）１７０によって用いられる、リアルタイムイベントエンジンメッセージングシーケンス例を示している。リアルタイムイベント情報は、企業規模のコールセンタードメインにおける個々のコールセンター１２０毎に対応するコールセンターのＴサーバ１３０によってモニタされ、当該コールセンターのインターネットコールマネージャ（ＩＣＭ）１２８に対して独立に報告されるリアルタイムデータである。イベントは、通常、コールセンターのＰＢＸ１２２あるいは他のプログラマブル交換機において発生する状態変化すなわちイベントとして特徴付けられる。コールセンターのＴサーバ１３０から対応するコールセンターのＩＣＭ１２８に報告される代表的なリアルタイムイベントには、コールセンターエージェントのログオンあるいはログオフ、コール接続、コール切断、キュー内のコール数などが含まれる。これらの列挙は例示目的のみであって、ＩＣＭ１２８に対して報告されうる状態変化の排他的なリストではない。他のイベントタイプなども状態変化として現時点でＩＣＭ１２８へ報告されうるが、これらは当業者には明らかである。
【００２２】
段階４１０においては、コールセンターＰＢＸ１２２において、特定のエージェントがログオンするといったＰＢＸ状態変化が発生したと仮定する。この状態変化は、ＰＢＸコールイベントを生成する（段階４１２）。コールセンターのＴサーバ１３０は、このコールイベントを検出する（段階４１４）。その後、コールセンターのＴサーバ１３０は、コールイベントを自身のＩＣＭ、この実施例の場合にはＩＣＭ₁に対して報告する（段階４１６）。通常、コールイベント通知を受信すると、ＩＣＭはその発生をローカルにコールヒストリログ内に記録する。本発明の原理に従って、ＩＣＭは、さらに、その状態変化を企業のインターネットインターフェースコントローラ（ＩＩＣ）１７０に通知する（段階４１８）。個々のコールセンターの状態変化がＩＩＣのリスナ１７２によって検出され、情報がＩＩＣのデータ貯蔵部１７４にストアされる（段階１７４）。ここでは、企業規模のコールセンタードメインに含まれるコールセンターの各々に対するインターネットコールマネージャ（ＩＣＭ）が、集合的に企業ＩＣＭ４５０として示されている。ここで、コールセンターの個数とＩＣＭの個数とが一対一に対応する必要が必ずしも無いことに留意されたい。例えば、図７では、総数ｎのインターネットコールマネージャ（ＩＣＭ）、ＩＣＭ₁からＩＣＭ_n、が含まれている。ＩＣＭ₁は、単一のＰＢＸを有する単一のコールセンター専用であるように図示されている。ＩＣＭ₂は、同様に単一のコールセンター（ＣＣ₂）を管理するように示されている。単一のコールセンター（ＣＣ₄）が、二つあるいはそれ以上のＩＣＭ（ＩＣＭ₃及びＩＣＭ₄）が当該コールセンターの別々のサブセクションを管理するような大きさ及び規模である可能性もある。
【００２３】
ＩＩＣ１７０において、企業規模のコールセンターの各々からのリアルタイムイベントデータを収集することにより、ＩＩＣが個々のコールに関して最も適切なコールルートをリアルタイムデータに基づいて決定することが可能になる。例えば、ルールエンジン１７６が、エージェントがコールに応答するまでの発呼者の待機時間を最小化するようにプログラムされている場合には、ＩＩＣ１７０は、個々のコールセンターにおける個々のエージェントに関するコールキューに係るリアルタイム情報を保持しており、コールを短いキュー長を有するコールセンター及びエージェントに対してルーティングすることによって、発呼者の待機時間を最小化すなわち低減するルーティング決定をする。あるエージェントが特定の能力すなわち専門技術を有する場合、例えば、外国語を話す能力、複雑なオーダーを処理するために必要とされる特別のトレーニング、あるいはある種のトランザクションに必要とされる認証あるいはライセンスを有している場合、は、コールは特定のコールセンターにおけるその特定のエージェント宛にルーティングされる。さらに、曜日、天気、株式市場指数などのリアルタイム環境状況がルーティング属性を規定するために用いられうるが、これらは当業者には明らかである。エージェント状態（ログオンしていて利用可能、あるいはそれ以外）はＩＩＣデータ貯蔵部１７４に状態変化イベントとして伝達される。当業者には明らかなように、他のリアルタイムイベント情報が特定目的達成を試行したルーティング決定をなすために用いられることが可能であり、本明細書に記載されたものは単に例示目的のみであって排他的なものではない。
【００２４】
図３に戻って、段階２１６では、ルールエンジン１７６がルーティングエンジン１７８に対してヒストリカルイベントデータを用いないように指示するようプログラムされている場合には、ルーティングエンジンがヒストリカルイベントデータをコールルーティング決定のコンポーネントとして無視する。しかしながら、ルールエンジン１７６がルーティングエンジン１７８に対してヒストリカルイベントデータを用いるように指示するようプログラムされている場合には、ルーティングエンジンは、排他的あるいは他のルーティングアルゴリズムコンポーネントと共に、ヒストリドリブンエンジンとして機能する。ルールエンジン１７６がデータを取得してヒストリカルイベントエンジンとして用いられるための方法の一例が、図８に示されている。
【００２５】
図８は、本発明の原理に従って、インターネットインターフェースコントローラ（ＩＩＣ）１７０によって企業規模のコールセンター群のうちの適切なものに対するコールルーティング決定を行なう際に用いられる、ヒストリカルイベントエンジンメッセージングシーケンス例を示す流れ図である。ヒストリカルイベント情報は、企業規模のコールセンタードメインにおける個々のコールセンター１２０毎に対応するコールセンターのＴサーバ１３０によってモニタされ、当該コールセンターのインターネットコールマネージャ（ＩＣＭ）１２８に対して独立に報告される。しかしながら、リアルタイムイベントデータの場合とは異なって、ヒストリカルイベントデータはコールセンターの現在のイベントあるいはアクティビティを反映しない。ヒストリカルイベントデータはリアルタイムイベントデータを用いることが可能であるが、将来のコールセンターのアクティビティを予測することを目的として過去のコールセンターのアクティビティを解析するために、しばしばある時間期間に亘って集積された過去のリアルタイムイベントデータを用いる。ヒストリカルイベントデータは、リアルタイムイベントデータとは異なって、状態変化に応答してＩＩＣ１７０に報告されない。ヒストリカルイベントデータは、ヒストリカルイベント情報データベースを更新する目的で、周期的にＩＩＣ１７０に対して報告される。ヒストリカルイベントデータの例には、種々の時間期間におけるコールセンター密度レポート、コールセンター毎に単位時間当たりにサービスが提供されたコール数、コールセンター密度の季節変動、コールセンター当たりの破棄されたコール数、与えられた時間期間に特定のアプリケーションによって処理されたコール数、特定のＩＰアドレスあるいはＵＲＬから受信されたコール数、顧客の好みやオーダー情報、顧客がコールを設定した回数、コールＩＤ／事由などが含まれるが、これらに限定されるわけではない。
【００２６】
段階５１０では、コールセンターＰＢＸ１２２に特定のエージェントがログオンするというＰＢＸ状態変化が発生したと仮定する。この状態変化によって、ＰＢＸコールイベントが発生される（段階５１２）。コールセンターのＴサーバ１３０はコールイベントを検出する（段階５１４）。その後、コールセンターのＴサーバ１３０が当該コールイベントをそのＩＣＭ、この例ではＩＣＭ₁、に通知する（段階５１６）。コールイベント通知を受信すると、ＩＣＭはその発生をローカルにコールヒストリログに記録する。ＩＣＭコールヒストリログは、ある時間期間に亘るコール記録の詳細及び状態変化イベントのまとめを管理している。本発明の原理に従って、ＩＣＭはそのコールヒストリログを企業インターネットインターフェースコントローラ（ＩＩＣ）１７０宛に周期的に報告する（段階５１８）。その後、サイトに固有のヒストリカル情報が、ＩＩＣのデータ貯蔵部１７４にストアされる（段階５２０）。企業規模のコールセンタードメインに含まれる個々のコールセンターに係るインターネットコールマネージャ（ＩＣＭ）は、ＩＣＭ５５０として集合的に示されている。前述されているように、コールセンターの個数とＩＣＭの個数とが一対一に対応する必要が必ずしも無いことに留意されたい。例えば、図８では、総数ｎのインターネットコールマネージャ（ＩＣＭ）、ＩＣＭ₁からＩＣＭ_n、が含まれている。ＩＣＭ₁は、単一のＰＢＸを有する単一のコールセンター専用であるように図示されている。ＩＣＭ₂は、同様に単一のコールセンター（ＣＣ₂）を管理するように示されている。単一のコールセンター（ＣＣ₄）が、二つあるいはそれ以上のＩＣＭ（ＩＣＭ₃及びＩＣＭ₄）が当該コールセンターの別々のサブセクションを管理するような大きさ及び規模である可能性もある。
【００２７】
ＩＩＣ１７０において企業規模での各々のコールセンターに係るヒストリカルイベントデータを集積することによって、ＩＩＣ１７０がこれらのヒストリカルデータに基づいて個々のコールに係る最も適切なコールルートを決定することが可能になる。例えば、ルールエンジン１７６が、エージェントがコールに応答するまでの発呼者の待機時間を最小化するようにプログラムされている場合には、ＩＩＣ１７０は、個々のコールセンターにおけるコール密度に係るヒストリカル情報を保持しており、発呼された時刻において利用可能な占有されていないエージェントスタッフを通常有していると予測されるコールセンター宛にコールをルーティングすることによって発呼者の待機時間を最小化すなわち低減するルーティング決定をする。当業者には明らかなように、他のヒストリカルイベント情報が特定目的達成を試行したルーティング決定をなすために用いられることが可能であり、本明細書に記載されたものは単に例示目的のみであって排他的なものではない。
【００２８】
図３に戻って、段階２２０においては、ルールエンジン１７６がルーティングエンジン１７８に対してルーティング決定の際にコール事由を用いないように指示するようプログラムされている場合には、ルーティングエンジンはＣＡＬＬ＿ＵＳ要求に含まれるあらゆるコールＩＤ／事由をコールルーティングのコンポーネントとして無視する。しかしながら、ルールエンジン１７６がルーティングエンジン１７８に対してルーティング決定をコールＩＤ／事由に基づいてなすように指示する場合には、ルーティングエンジン１７８は、ルーティングの際に当該コールに係る事由を、排他的あるいは他のルーティングアルゴリズムコンポーネントと共に利用する（段階２１８）。前述された本発明の一実施例においては、コールＩＤ／事由が、ＩＩＣ１７０のリスナがＣＡＬＬ＿ＵＳ要求を構文解析して当該コールに係るコール事由を決定する場合に決定される。当業者には明らかなように他の方式も用いられうるが、コール事由はその要求が発せられた企業ウェブページのＣＧＩスクリプトに帰属され、ＣＧＩスクリプトを開始する動作の際にＣＡＬＬ＿ＵＳ要求内のデータフィールドに含められる。
【００２９】
図９は、ＩＩＣ１７０によって管理されているコール事由データフィールド構造例を示している。例として、ＩＩＣ１７０向けのＣＡＬＬ＿ＵＳ要求に係るコールＩＤ／事由が第一の値（１）であると決定される場合には、ルーティングエンジン１７８は、排他的あるいは他のルーティングアルゴリズムコンポーネントと共に、コールセンターサイトＡを希望するというルーティング決定をなす。あるいは、ＩＩＣ１７０向けのＣＡＬＬ＿ＵＳ要求に係るコールＩＤ／事由が第二の値（２）であると決定される場合には、ルーティングエンジン１７８は、排他的あるいは他のルーティングアルゴリズムコンポーネントと共に、コールセンターサイトＢを希望するというルーティング決定をなす。利用可能なコールＩＤ／事由の個数は、企業のニーズに基づいて当該企業のインターネットコールセンターマネジメントによって決定される。それゆえ、図９には、総数ｎのコールＩＤ／事由が例示されている。報告されたコールＩＤ／事由に基づいた選択的ルーティングのこのタイプの例として、ＣＡＬＬ＿ＵＳ要求のコールＩＤ／事由が第一値（１）であって、この１という値が、ＣＡＬＬ＿ＵＳ要求が予約を獲得する目的でなされたものである、ということを示すものと仮定する。さらに、企業に係る全ての予約が特定の企業コールセンター、例えばコールセンターＡにおいてなされるものと仮定する。よって、予約はコールセンターＡでのみなされ得るため、ＣＡＬＬ＿ＵＳ要求はコールセンターＡに対してのみ振り向けられる。予約が他の企業コールセンターにおいてもなされ得る場合には、ルールエンジン１７６及びルーティングエンジン１７８が協調して、予約を取り扱うことが可能な全てのコールセンターから選択し、コールＩＤ／事由及び他のルーティングアルゴリズムコンポーネントの観点から最終的なルーティング決定を行なう。
【００３０】
段階２２４において、ルールエンジン１７６がルーティングエンジン１７８に対して発信ユニバーサルリソースロケータ（ＵＲＬ）の識別をルーティング決定の基礎として用いないように指示するようプログラムされている場合には、ルーティングエンジンは発信ブラウザＵＲＬアドレスをコールルーティング決定に係る基礎としては無視する。しかしながら、ルールエンジン１７６がルーティングエンジン１７８に対して発信ＵＲＬをルーティング決定の基礎とするように指示するようプログラムされている場合には、ルーティングエンジン１７８は発信ＣＡＬＬ＿ＵＳ要求のＵＲＬを排他的あるいは他のルーティングアルゴリズムコンポーネントと共に利用する（段階２２２）。前述されている本発明の一実施例においては、ＩＩＣリスナ１７２がＣＡＬＬ＿ＵＳ要求を構文解析して当該コールに係るＵＲＬを決定し、その情報をコール記録に書き込む際に決定される。
【００３１】
図１０は、ＩＩＣ１７０によって管理されているＵＲＬデータフィールドストラクチャ例を示している。例えば、ＩＩＣ１７０に振り向けられたＣＡＬＬ＿ＵＳ要求に係る発信（ソース）ＵＲＬが第一値（例えばＸＹＺ）にセットされる場合には、ルーティングエンジン１７８は、コールセンターＡを希望するように排他的あるいは他のルーティングアルゴリズムコンポーネントと共に決定を実行する。あるいは、ＩＩＣ１７０に振り向けられたＣＡＬＬ＿ＵＳ要求に係る発信（ソース）ＵＲＬが第二値（例えばＣＥＦ）にセットされる場合には、ルーティングエンジン１７８は、コールセンターＢを希望するように排他的あるいは他のルーティングアルゴリズムコンポーネントと共に決定を実行する。ルーティング決定が基づく他のＵＲＬの個数は企業のニーズに基づいて企業のインターネットコールセンターマネジメントによって決定される。それゆえ、図１０においては、ｎ個の発信ＵＲＬアドレスが示されている。発信ＵＲＬに基づく選択的ルーティングの具体例として、ＣＡＬＬ＿ＵＳ要求が第一発信ＵＲＬ値（ＸＹＺ）を有しており、ＸＹＺという値が当該ＣＡＬＬ＿ＵＳ要求が企業の予約ウェブページから発せられたことを示していると仮定する。さらに、企業の予約は、一つの特定の企業コールセンター、例えばコールセンターＡにおいてなされると仮定する。よって、予約がコールセンターＡでのみなされるため、ＣＡＬＬ＿ＵＳ要求はコールセンターＡに対して振り向けられる。予約が他の企業コールセンターにおいてもなされうる場合には、ルールエンジン１７６及びルーティングエンジン１７８が協調して、予約を取り扱うことが可能な全てのコールセンターから選択し、発信ＵＲＬアドレス及び他のルーティングアルゴリズムコンポーネントの観点から最終的なルーティング決定を行なう。
【００３２】
段階２２８において、ルールエンジン１７６がルーティングエンジン１７８に対して顧客入力情報をルーティング決定の基礎として用いないように指示するようプログラムされている場合には、ルーティングエンジンは発呼者によって入力されて返送されたＣＡＬＬ＿ＵＳ要求ＣＧＩスクリプトに含まれた情報をコールルーティング決定に係る基礎としては無視する。しかしながら、ルールエンジン１７６がルーティングエンジン１７８に対して顧客入力情報をルーティング決定の基礎とするように指示するようプログラムされている場合には、ルーティングエンジン１７８は顧客入力情報をコールをルーティングするために排他的あるいは他のルーティングアルゴリズムコンポーネントと共に利用する（段階２３０）。前述されている本発明の一実施例においては、顧客入力情報は、ＩＩＣ１７０のリスナ１７２がＣＡＬＬ＿ＵＳ要求を構文解析してその情報をコール記録に書き込む際に決定される。顧客入力情報には、e-mailアドレス、自宅の住所、発送先住所、日中及び夜間の連絡先電話番号、クレジットカード情報、発送に係るプリファレンス、顧客に係るプリファレンス、家族数、家計収入、及び／あるいは企業にとって有用かつ適切だと思われるその他のあらゆるデータなどが含まれるがそれらに限定されているわけではない。
【００３３】
図１１は、ＩＩＣ１７０によって管理されている顧客入力情報データフィールド構造を例示している。例えば、顧客入力情報の特定のデータフィールドが第一値（例えばＸ１１）にセットされる場合には、ルーティングエンジン１７８は、コールセンターＡを希望するように排他的あるいは他のルーティングアルゴリズムコンポーネントと共に決定を実行する。あるいは、顧客入力情報の特定のデータフィールドが第二値（例えばＸ１２）にセットされる場合には、ルーティングエンジン１７８は、コールセンターＢを希望するように排他的あるいは他のルーティングアルゴリズムコンポーネントと共に決定を実行する。他の顧客入力情報フィールドの個数、及びそれらのフィールドに対する値は企業のニーズに基づいて企業のインターネットコールセンターマネジメントによって決定される。それゆえ、図１１においては、ｎ個の発信顧客入力情報フィールド値が示されている。顧客入力情報に基づく選択的ルーティングの具体例として、ＣＡＬＬ＿ＵＳ要求が発呼者が特定の製品の購入を望んでいることを示す顧客入力情報を有しており、顧客入力情報フィールドにおけるＸ１１という値によって示されていると仮定する。さらに、その特定の製品に係る全ての企業セールスは、一つの特定の企業コールセンター、例えばコールセンターＡにおいてなされると仮定する。よって、その特定の製品の販売がコールセンターＡに勤めているエージェントによってのみなされるため、ＣＡＬＬ＿ＵＳ要求はコールセンターＡに対してのみ振り向けられる。その特定の製品が他の企業コールセンターにおいても販売される場合には、ルールエンジン１７６及びルーティングエンジン１７８が協調して、その製品を販売している可能な全てのコールセンターから選択し、他のルーティングアルゴリズムコンポーネントの観点から最終的なルーティング決定を行なう。ルーティング決定は他のコールタイプに関しても同様になされるが、これらは当業者には明らかである。例えば、単一のコールセンターにのみ、テキストチャットセッションを実行することが可能なエージェントが勤務している場合もありうる。
【００３４】
段階２３２においては、コールに対してサービスを提供する企業規模のコールセンターの中から適切なコールセンターを決定する目的で、前述されているいくつかのルールがルーティングエンジン１７８によって用いられる、例えば個々のルールを排他的に用いる場合あるいはルール混合すなわち重み付けアルゴリズムを利用することによって二つもしくはそれ以上のルールが協調的に利用される。段階２３４では、ＩＩＣ１７０のルーティングエンジン１７８が、前段階で決定されたコールセンター１２０に係るインターネットコールマネージャ（ＩＣＭ）１２８のアドレスを含むルーティングメッセージを生成し、元のＣＡＬＬ＿ＵＳ要求を発信した発呼者のブラウザに当該ルーティングメッセージを返送する。その後、発呼者のブラウザは、プリルーティング済みＣＡＬＬ＿ＵＳ要求のデスティネーションアドレスである前記ＩＣＭアドレスを用いて更新される（段階２３６）。その後、プリルーティング済みＣＡＬＬ＿ＵＳ要求が発呼者のブラウザから発信され、デスティネーションＩＣＭにおいて受信される（段階２３８）。
【００３５】
選択されたコールセンター１２０に係るデスティネーションＩＣＭ１２８で受信されると、ＩＣＭ１２８は当該プリルーティング済みＣＡＬＬ＿ＵＳ要求に関するコールタイプを決定する（段階２４０）。当該プリルーティング済みＣＡＬＬ＿ＵＳ要求がボイス・オーバー・インターネットプロトコル（ＶｏＩＰ）要求である場合には、ＩＣＭはＩＴＧを選択する（段階２４６）。その後、ＩＣＭ１２８は、発呼者１１０とコールセンター１２０のインターネットテレフォニーゲートウェイ１２６との間の通信を設定し、ＩＴＧ１２６は発呼者のＰＣ上のＶｏＩＰアプリケーションと接続する（段階２４７）。この種のＶｏＩＰアプリケーションの一例は、マイクロソフト（Microsoft）社のネットミーティング（NetMeeting^(R)）である。本発明の望ましい実施例においては、ＶｏＩＰアプリケーションはＨ．３２３準拠アプリケーションである。Ｈ．３２３は、サービスすなわちサービス品質を保証しないネットワーク、特にインターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、及びイントラネットなどのパケットネットワークを介したリアルタイム音声及び画像送信に係るコール制御、チャネル設定及びコーデック仕様国際通信連合通信（ＩＴＵ−Ｔ）標準である。段階２４８では、コールセンターＩＣＭ１２８によってＩＴＧ１２６からポートサイド機構１４６（通常、ＩＳＤＮ／ＰＲＩインターフェース）を介してコールセンターのプライベートブランチ交換機（ＰＢＸ）１２２へのコールが発せられる。
【００３６】
しかしながら、段階２４０でなされた決定が、着信プリルーティング済みＣＡＬＬ＿ＵＳ要求がボイス・オーバー・インターネットプロトコル（ＶｏＩＰ）要求ではなく、テキストチャット要求でもなく、チャット＆コールバック要求でもない（すなわち、コールバックのみの要求である）場合には、ＩＣＭ１２８はコール制御アプリケーションを発呼者１１０に対して返送しない。他の場合には、段階２４２で、コール制御アプリケーションが発呼者１１０に対して返送される。コール制御アプリケーションは、ひとたび発呼者とコールセンター１２０におけるエージェントとの間のセッションが設定されると、発呼者とエージェントとがテキストチャットメッセージを交換し、ＵＲＬを共有して、さらに協調することを可能にするアプリケーションである。同時に、テキストチャットあるいはコールバックに関しては、ＩＣＭ１２８は既知のファントムコール機構を介してＰＢＸ１２２宛にコールを発信する（段階２４４）。所謂ファントムコールはＩＳＤＮ／ＰＲＩポートサイド機構を利用しない。むしろ、それは音声接続を設定せずにエージェントを予約する方法であって、コールセンター１２０におけるコール容量を増大させる。
【００３７】
コール要求のタイプ、すなわち、ＶｏＩＰ、テキストチャット、あるいはコールバック、に関わらず、着信コールが振り向けられたコールセンター１２０のインターネットコールマネージャ（ＩＣＭ）１２８は、ＰＢＸすなわち交換機を介して、当該コールセンターのエージェントが着信コールにサービスすることが可能であるか否かを決定する（段階２５０）。エージェントが利用可能ではない場合には、エージェントが利用可能になるまで、当該着信コールはＰＢＸすなわち交換機においてキューに入れられる（段階２５２）。エージェントが利用可能である場合には、ＩＣＭ１２８には選択されたエージェントのＩＤが通知される（段階２５４）。その後、発呼者１１０と当該エージェントとの間の接続が設定される。発呼者に係る適切な情報を含むスクリーンポップアップメッセージがエージェントのワークステーション１３２宛に送出され（段階２５６）、発呼者／エージェントセッションがＩＣＭ１２８によってシンクロナイズされる。
【００３８】
以上の説明は、本発明の一実施例に関するもので，この技術分野の当業者であれば、本発明の種々の変形例が考え得るが、それらはいずれも本発明の技術的範囲に包含される。さらに、本明細書に記載された全ての例及び条件言語は、読者が本発明の発明者によって提供された原理及び概念を理解することを補助する教育目的のみで原則的に表現されたものであり、取り上げられた特定の実施例及び条件に限定されているものではないと解釈されるべきものである。加えて、本発明の原理、側面、及び実施例に係る、本明細書における全ての記述は、その特定の実施例と同様、構造的及び機能的等価物の双方を包含している、ということが企図されている。さらに、この種の等価物には、現在既知の等価物及び将来において開発される等価物の双方、すなわち、その構造に関わらず、同一の機能を実行するように開発されたあらゆる要素が含まれる、ということが企図されている。
【００３９】
よって、例えば、本明細書に記載されたブロック図が本発明の原理を具体化する回路例を示す概念図であることは当業者には明らかである。同様に、全ての流れ図、状態遷移図、擬似コード、及びそれらの同等物は、コンピュータによって読み取り可能な媒体において実質的に表現され、コンピュータあるいはプロセッサによって、それらが顕わに示されているか否かに関わらず、実行される種々のプロセスを表わしていることに留意されたい。
【００４０】
“プロセッサ”というラベルが付された機能ブロックを含む種々の例示及び記述された要素の機能は、専用のハードウエア及び適切なソフトウエアと関連させられてソフトウエアを実行することが可能なハードウエアの使用によって実現されうる。プロセッサによって提供される場合には、これらの機能は単一の専用プロセッサ、単一の共有プロセッサ、あるいは、そのうちのいくつかが共有されているような複数個の個別のプロセッサなどによって提供されうる。さらに、“プロセッサ”あるいは“コントローラ”という術語の使用はソフトウエアを実行することが可能なハードウエアを排他的に参照するものと解釈されるべきではなく、デジタルシグナルプロセッサ（ＤＳＰ）ハードウエア、ソフトウエアをストアするリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性記憶などを暗に含むものであるが、それらに限定されるものではない。従来技術に係るもの及び／あるいは専用品などの他のハードウエアも含まれうる。同様に、図示された交換機は概念的なものである。それらの機能は、プログラムロジックの動作、専用ロジック、プログラム制御ロジックと専用ロジックとの相互作用などを通じて、さらに、手動でさえも実行されうるが、本発明の実施者によって選択されうる特定の技法は、本明細書における記述からより詳細に理解されうる。
【００４１】
本発明の請求項においては、特定の機能を実行する手段として表現されているあらゆる要素は、例えば、ａ）当該機能を実行する回路要素の組み合わせ、あるいは、ｂ）当該機能を実現する目的でそれらを実行することが可能な適切な回路と組み合わせられたあらゆる形態すなわちファームウエア、マイクロコードなどのソフトウエア、など、その機能を実行するあらゆる手段を含んでいる。請求項に規定された本発明は、種々の例示された手段によって実現される機能が請求項によって要求される様式で組み合わせられたものであるという事実に存している。よって、本発明の発明者は、それらの機能を実現するあらゆる手段を本明細書に示されたものと等価なものと見なす。
【００４２】
【発明の効果】
以上述べたごとく、本発明によれば、インターネットコールセンターのサービス品質を効率的かつ効果的に強化する方法及びそれを実現するシステムが提供される。
【図面の簡単な説明】
【図１】 本発明の原理に従った、複数個のインターネットコールセンターすなわちインターネットコールターミネーションポイント間での企業規模でのインテリジェントインターネットルーティング方式を実現するために用いられるインターネットインターフェースコントローラ（ＩＩＣ）のアーキテクチャ配置例を模式的に示すブロック図。
【図２】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）を用いるエンド−ツー−エンドコールフローシーケンス例を示す流れ図。
【図３】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）を用いるエンド−ツー−エンドコールフローシーケンス例を示す流れ図。
【図４】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）を用いるエンド−ツー−エンドコールフローシーケンス例を示す流れ図。
【図５】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）を用いるエンド−ツー−エンドコールフローシーケンス例を示す流れ図。
【図６】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によってコール要求ルートタイプを決定する際に用いられる処理方法例を示す流れ図。
【図７】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によって適切な企業規模のコールセンター宛のコールルーティングを決定する際に用いられるリアルタイムイベントエンジンメッセージングシーケンス例を示す流れ図。
【図８】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によって適切な企業規模のコールセンター宛のコールルーティングを決定する際に用いられるヒストリカルイベントエンジンメッセージングシーケンス例を示す流れ図。
【図９】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によって管理されているコール事由データフィールド構造例を模式的に示す図。
【図１０】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によって管理されているＵＲＬデータフィールド構造例を模式的に示す図。
【図１１】 本発明の原理に従ったインターネットインターフェースコントローラ（ＩＩＣ）によって管理されている顧客入力情報データ構造例を模式的に示す図。
【符号の説明】
１１０ 発呼者
１１２ ＰＣ
１１４ 電話機
１２０ コールセンター
１２２ ＰＢＸ
１２４ ファイアウォール
１２６ インターネットテレフォニーゲートウェイ
１２８ インターネットコールマネージャ
１３０ Ｔサーバ
１３２ エージェントワークステーション
１３４ ＰＣ
１３６ 電話機
１３８ コールキューバッファ
１４０ コールルーティングエンジン
１４２ 基幹回線
１４４ エージェント選択エンジン
１４６ ポートサイド機構
１５０ 公共インターネット
１５２ インターネットサービスプロバイダ
１５４ 公衆交換電話ネットワーク
１６０ 企業サイト
１６２ ファイアウォール
１７０ インターネットインターフェースコントローラ
１７２ リスナ
１７４ データ貯蔵部
１７６ ルールエンジン
１７８ ルーティングエンジン
４５０ インターネットコールマネージャ
５５０ インターネットコールマネージャ

Claims (25)

1. ブラウザを使用して、発呼者によって開始された接続要求を複数のコールセンターの中から選択されたコールセンターへ割り当てる方法において、該方法が、
   前記接続要求を受信する段階と、
   コール記録を生成する段階と、
   要求タイプフィールドに係るタイプ値を決定するためにＩＰアドレス、ユニバーサルリソースロケータ、および要求の呼タイプを構文解析する段階を含む、前記接続要求を構文解析する段階と、
   前記ＩＰアドレスが有効であれば、前記ＩＰアドレスをコール記録に記憶し、前記ユニバーサルリソースロケータおよび前記呼タイプが非零値であれば、該ユニバーサルリソースロケータおよび該呼タイプをコール記録に記憶する段階と、
   呼を前記呼センターで設定する段階とを備え、前記呼タイプが前記タイプ値に依存しており、前記ＩＰアドレスが有効でなく、前記ユニバーサルリソースロケータおよび前記呼タイプが非零値であれば、テキストチャットセッションが前記呼のために前記呼センターで設定されており、前記方法は、
   前記複数のコールセンターのうちから前記コールセンターを選択するために、前記適用可能なルールを前記接続要求に適用する段階と、
   一組のルールの中から適用可能なルールにアクセスするためにデータベースを読み出す段階と、
   前記接続要求を開始する前記ブラウザ宛に前記コールセンターに係るアドレスを返送する段階とを含むことを特徴とする割り当て方法。
2. 請求項１の割り当て方法において、第１のタイプ値は、前記コールに対するボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）セッションを前記コールセンターで設定するために利用される、割り当て方法。
3. 請求項１の割り当て方法において、第２のタイプ値が、前記コールセンターで前記呼のためのテキストチャットセッションを設定するために利用される、割り当て方法。
4. 請求項１の割り当て方法において、第３のタイプ値が、前記コールセンターで前記呼のためのコールバックセッションを要求するために利用される、割り当て方法。
5. 請求項１の割り当て方法において、さらに、
   前記複数のコールセンターからリアルタイムイベント情報を受信する段階と、
   前記複数のコールセンターの中から前記コールセンターを選択する目的で前記適用可能なルールと共に前記リアルタイムイベント情報を前記接続要求に対して適用する段階とを有する割り当て方法。
6. 請求項１の割り当て方法において、さらに、
   前記複数のコールセンターからヒストリカルイベント情報を受信する段階と、
   前記複数のコールセンターの中から前記コールセンターを選択する目的で前記適用可能なルールと共に前記ヒストリカルイベント情報を前記接続要求に対して適用する段階とを有する割り当て方法。
7. 請求項１の割り当て方法において、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記ブラウザに関連したユニバーサルリソースロケータ（ＵＲＬ）を利用する、割り当て方法。
8. 請求項１の割り当て方法において、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記接続要求に含まれるコール事由値を利用する、割り当て方法。
9. 請求項１の割り当て方法において、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記接続要求に含まれるコール事由値を利用する、割り当て方法。
10. ブラウザを使用して、発呼者によって開始された接続要求を複数の コールセンターの中から選択されたコールセンターへ割り当てるデバイスにおいて、該デバイスが、
    前記接続要求を受信し、コール記録を生成し、ＩＰアドレス、ユニバーサルリソースロケータ、および前記接続要求のコールタイプを構文解析し、前記ＩＰアドレスが有効であれば、該ＩＰアドレスを前記コール記録に記憶し、前記ユニバーサルリソースロケータおよび前記コールタイプが非零値であれば、該ユニバーサルリソースロケータおよび該呼タイプをコール記録に記憶するよう動作できるリスナデバイスと、
    前記リスナデバイスから適切なコールセンターデータと前記発呼者から適切な接続要求データを受信するように動作できるデータ貯蔵部と、
    前記適切なコールセンターデータ及び前記適切な接続要求データを前記データ貯蔵部から読み出すように動作できるルーティングエンジンとを備え、前記ルーティングエンジンは、前記複数のコールセンターの中から選択された前記コールセンターを決定するために、前記適切なコールセンターデータ及び前記適切な接続要求データに対して１組のルールを適用するようになっていることを特徴とする割り当てデバイス。
11. 請求項１０の割り当てデバイスにおいて、前記接続要求データが、その後に設定されるコールセッションがボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）セッションであることを規定するフィールドを含む、割り当てデバイス。
12. 請求項１０の割り当てデバイスにおいて、前記接続要求データが、その後に設定されるコールセッションがテキストチャットセッションであることを規定するフィールドを含む、割り当てデバイス。
13. 請求項１０の割り当てデバイスにおいて、前記接続要求データが、その後に設定されるコールセッションがコールバックセッションであることを規定するフィールドを含む、割り当てデバイス。
14. ブラウザを使用して、発呼者によって開始された接続要求を複数のコールセンターの中から選択されたコールセンターへ割り当てるデバイスにおいて、該割り当てデバイスが、
    前記接続要求を受信する手段と、
    コール記録を生成し、ＩＰアドレス、ユニバーサルリソースロケータ、および前記接続要求のコールタイプを構文解析し、前記ＩＰアドレスが有効であれば、該ＩＰアドレスを前記コール記録に記憶し、前記ユニバーサルリソースロケータおよび前記コールタイプが非零値であれば、該ユニバーサルリソースロケータおよび該コールタイプをコール記録に記憶することによって、要求タイプフィールドに関連したタイプ値を設定するために前記接続要求を構文解析する手段と、
    コールを前記コールセンターで設定する手段とを備え、前記コールタイプは前記タイプ値に依存しており、テキストチャットセッションが記ＩＰアドレスが有効で naku
    なくかつ前記ユニバーサルリソースロケータおよび前記コールタイプが非零値でなければ、前記コールに対して前記コールセンターで設定されており、前記デバイスは、
    一組のルールの中から適用可能なルールをアクセスするためにデータベースを読み出す手段と、
    前記複数のコールセンターのうちから前記コールセンターを選択するために前記適用可能なルールを前記接続要求に適用する手段と、
    前記接続要求を開始する前記ブラウザ宛に前記コールセンターに関連したアドレスを返送する手段とを有することを特徴とする割り当てデバイス。
15. 請求項１４の割り当てデバイスにおいて、第１のタイプ値は、前記コールに対するボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）セッションを前記コールセンターで設定するために利用される、割り当てデバイス。
16. 請求項１４の割り当てデバイスにおいて、第２のタイプ値が、前記コールセンターで前記呼のためのテキストチャットセッションを設定するために利用される、割り当てデバイス。
17. 請求項１４の割り当てデバイス方法において、第３のタイプ値が、 前記コールセンターで前記呼のためのコールバックセッションを要求するために利用される、割り当てデバイス。
18. 請求項１４の割り当てデバイスにおいて、さらに、
    前記複数のコールセンターからリアルタイムイベント情報を受信する手段と、
    前記複数のコールセンターの中から前記コールセンターを選択するために前記適用可能なルールと共に前記リアルタイムイベント情報を前記接続要求に対して適用する手段とを有する割り当てデバイス。
19. 請求項１４の割り当てデバイスにおいて、さらに、
    前記複数のコールセンターからヒストリカルイベント情報を受信する手段と、
    前記複数のコールセンターの中から前記コールセンターを選択するために前記適用可能なルールと共に前記ヒストリカルイベント情報を前記接続要求に対して適用する手段とを有する割り当てデバイス。
20. 請求項１４の割り当てデバイスにおいて、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記ブラウザに関連したユニバーサルリソースロケータ（ＵＲＬ）を利用する、割り当てデバイス。
21. 請求項１４の割り当てデバイスにおいて、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記接続要求に含まれるコール事由値を利用する、割り当てデバイス。
22. 請求項１４の割り当てデバイスにおいて、前記適用可能なルールは、前記複数のコールセンターの中から前記コールセンターを選択するために、前記接続要求に含まれるコール事由値を利用する、割り当てデバイス。
23. ブラウザを使用して、発呼者によって開始された接続要求を複数のコールセンターの中から選択されたコールセンターへ割り当てる方法において、該割り当て方法が、
    前記複数のコールセンターへルーティングするコールを決定するために一組のルールを作成する段階を含み、該一組のルールはヒストリカルイベントデータ、コール事由、ユニバーサルリソースロケータルーティング、および発呼者入力情報の各々に関連したエンジンを使用することを含み、前記割り当て方法は、
    前記一組のルールをデータベース内に記憶する段階と、
    前記接続情報を受信する段階と、
    前記一組のルールの中から第１の適用可能なルールにアクセスするために前記データベースを読み出す段階と、
    前記一組のルールの中から第２の適用可能なルールにアクセスするために前記データベースを読み出す段階と、
    前記複数のコールセンターの中から前記コールセンターを選択するために、ルール混合アルゴリズムを利用する前記第１の適用可能なルールおよび第２の適用可能なルールを前記接続要求に適用する段階と、
    前記接続要求を開始する前記ブラウザへ、前記コールセンターに関連したアドレスを返送する段階とを含むことを特徴とする割り当て方法。
24. ウェブベースのブラウザを利用する発呼者と複数のインターネットコールセンターを持つ企業内に組み込まれたインターネットコールセンターとの間にインターネットコール接続を設定する方法において、該方法が、
    前記複数のインターネットコールセンターへルーティングするコールを決定するために一組のルールを作成する段階を含み、該一組のルールはヒストリカルイベントデータ、コール事由、ユニバーサルリソースロケータルーティング、および発呼者入力情報の各々に関連したエンジンを使用することを含み、前記方法は、
    前記一組のルールをインターネットインターフェースコントローラ内に含まれるデータベース内に記憶し、前記ウェブベースブラウザからインターネットを介して接続要求を発信する段階と、
    前記接続情報を前記インターネットインターフェースコントローラで受信する段階と、
    前記接続要求の中から適切なルーティング情報を構文解析する段階と、
    前記一組のルールの中から第１の適用可能なルールにアクセスするために前記データベースを読み出す段階と、
    前記一組のルールの中から第２の適用可能なルールにアクセスするために前記データベースを読み出す段階と、
    前記複数のコールセンターの中から前記コールセンターを選択するために、ルール混合アルゴリズムを利用する前記第１の適用可能なルールおよび第２の適用可能なルールを前記適切なルーティング情報に適用する段階と、
    前記適切なルーティング情報を開始する前記ブラウザへ、前記コールセンターに関連したアドレスを返送する段階と、
    前記コールセンターに関連したアドレスを含むメッセージを前記ウェブベースのブラウザへ発信する段階と、
    前記メッセージを前記ウェブベースのブラウザで受信する段階と、
    宛先アドレスとして前記コールセンターに関連した前記アドレスを含む修正プリルーティング済み接続情報を生成する段階と、
    前記ウェブベースのブラウザからインターネットを介して前記修正プリルーティング済み接続情報を発信する段階と、
    前記修正プリルーティング済み接続情報前記コールセンターで受信する段階と、
    前記コールセンターでの前記修正プリルーティング済み接続情報の受信に応答して、前記発呼者と前記コールセンターとの間にインターネット接続を設定する段階とを含むことを特徴とする方法。
25. ブラウザを使用して、発呼者によって開始された接続要求を複数の企業規模のコールセンターの中から選択されたコールセンターへ割り当てる方法において、該割り当て方法が、
    前記複数の企業規模のコールセンターへルーティングするコールを決定するために一組のルールを作成する段階を含み、該一組のルールはヒストリカルイベントデータ、コール事由、ユニバーサルリソースロケータルーティング、および発呼者入力情報の各々に関連したエンジンを使用することを含み、前記割り当て方法は、
    前記一組のルールをデータベース内に記憶する段階と、
    前記接続情報を受信する段階と、
    前記一組のルールの中から適用可能なルールにアクセスするために前記データベースを読み出す段階と、
    前記複数の企業規模のコールセンターの中から前記コールセンターを選択するために、前記接続要求に前記適用可能なルールを適用する段階と、
    前記接続要求を開始する前記ブラウザへ、前記コールセンターに関連したアドレスを返送する段階とを含むことを特徴とする割り当て方法。

Images