JP2009059388A

JP2009059388A - メディアに依存しない通信サーバ

Info

Publication number: JP2009059388A
Application number: JP2008310651A
Authority: JP
Inventors: Mingte Chen; チェン、ミングテ; Anil K Annadata; アンナデータ、アニル・ケイ; Leon Chan; チャン、レオン
Original assignee: Siebel Systems Inc
Current assignee: Siebel Systems Inc
Priority date: 2001-03-31
Filing date: 2008-12-05
Publication date: 2009-03-19
Anticipated expiration: 2022-03-29
Also published as: WO2002080006A1; EP1393188A1; JP4762296B2; EP1393188A4; JP2004532460A; EP1393188B1; ATE538570T1; US20030018705A1; JP4732676B2

Abstract

【課題】異なるメディア形式から成る複数の通信チャネルを用いて通信するための方法を提供する。
【解決手段】この方法は、着信通信チャネルを介して通信されるイベントを取得するステップを含んでおり、前記イベントは、エージェントが利用可能である作業項目に対応している。前記作業項目の通知は、ユーザ・インタフェースを介して提供される。この方法は、ユーザ・インタフェースの作業項目オブジェクトのアクティブ化を受信するステップを含んでいてよく、前記作業項目オブジェクトは、前記作業項目に関連付けられている。前記アクティブ化の通知及び受信は、前記通信チャネルのメディア形式とは無関係に実行される。この方法は、前記作業項目オブジェクトのアクティブ化に関連付けられているコマンドを出力通信チャネルに発行するステップを含んでいる。
【選択図】図１−Ａ

Description

本発明は、種々のメディア形式から成る複数の通信チャネルを利用した通信に関するものである。

現代の発展しつつある技術及び情報の世界では、多種多様の通信チャネルを通して、企業が自分達の顧客、潜在的な顧客、及びその他の交渉相手と相互接続されている。そのような通信チャネルには、フェース・ツー・フェース（face-to-face）、電話、ファックス、ｅ−メール、ボイス・メール、無線通信、「call me now」及び「call me later」を介したインターネット情報問合せ、インターネット連携セッション、ページング及びショート・メッセージ・サービス等が含まれる。これら全ての通信チャネルに対して、企業は、各顧客の対話（インタラクション）を管理しながら、サービス・レベルを満たし、且つ顧客を最大限満足させる作業に直面する。更に、企業は、社員を最適に配置及び教育して、これらの通信チャネルを通して、顧客サポート・センタ、テレビジネス組織、若しくはそれらの販売、マーケティング、サービスの本職のいずれかを通して、顧客を処理する作業に直面する。

現在、多くの企業は、着信自動分配装置だけでなく、個々のビジネス分野毎に設けられた専用のｅ−メール受信箱、ファックス受信箱、及びボイス・メール受信箱を備えている。エージェントと呼ばれる従業員は、各通信チャネルに対して顧客からのサポート要求をポーリングし、且つ処理するように割当てられている。従来式の着信電話呼出の呼出待ち行列と相なって、各エージェントは、全てのこれら通信チャネルを用いて自身の仕事を処理するという過酷な負担が課せられる一方で、待ち行列（キュー）の状態、各顧客のサポート要求及び／又は通信チャネルの優先順位を視認する手立てを有していない。

ほとんどの通信ソフトウェアは、単一の通信装置若しくは単一の通信チャネル形式で作動するように設計されている。企業が、種々のメディア形式の複数の通信チャネルを利用してエージェントが通信することが可能である顧客サポート・センタを実施しようとする望む場合、従来的には、この企業は、異なる通信プロトコルが使用されていることに起因して、各メディア形式を処理するために異なるソフトウェア製品を購入する必要がある。例えば、通常、ｅ−メール・サーバは、無線アクセス・プロトコルを介してデータを受信可能なソフトウェアとは、別個に市販されている。異なる製品を購入する必要があるので、エージェントは、複数の通信チャネルの各メディア形式に対して異なるユーザ・インタフェースを利用するために学習する必要も生じる。種々のメディア形式を介して顧客と通信するために種々のユーザ・インタフェースを覚えなければならないならば、エージェントの効率は、通常、低下する。

日々、非常に多数の顧客のサポート要求を処理する顧客サポート・センタに対して、秒刻みで顧客の要求の各々に応答する各エージェントの効率を増大させることは、顧客サポート・センタに対する莫大なコスト削減となり得る。

従って、要求に応じる適切な技術を備えているエージェントに、複数の通信チャネルからワーク・アイテム（作業項目）の割当て、ルーティング、及びキューイングを行うことが可能な汎用キュー・ストラテジを含むシステムを提供することが望まれる。このシステムによって、エージェントは全ての通信チャネルに対して自身のワーク・アイテムを視認し、且つ処理することが可能にされる必要がある。そのようなシステムによって、反応時間が減少され、且つ顧客の満足度が増大される。同時に、複数の通信チャネル内にあるワーク・アイテムの間での優先順位が調整される。

本発明によって、種々のメディア形式から成る複数の通信チャネルを利用する通信方法が提供される。この方法は、入力通信チャネルを介して通信されるイベントを獲得するステップを含んでおり、そのイベントはエージェントが利用可能であるワーク・アイテムに対応している。ワーク・アイテムの通知は、ユーザ・インタフェースを介して提供される。この方法は、ユーザ・インタフェースのワーク・アイテムオブジェクトがアクティブにされたことを受信するステップを含んでおり、そのワーク・アイテムオブジェクトは、ワーク・アイテムと関連付けられている。この方法は、ワーク・アイテムオブジェクトのアクティブ化と関連付けられているコマンドを出力通信チャネルに発行するステップを含んでいる。本方法を実行するためのコンピュータ・システム及びデータベースが提供されている。

前記は概要であり、それゆえに必然的に、詳説が単純化され、一般化され、且つ省略されたものが含まれている。従って、当業者は、この概要が例示だけが目的であり、何ら制限を目的としたものでないことを理解するであろう。請求項だけによって規定される、本発明の別の態様、発明の特性、及び利点は、以下で示される制限されていない詳述によって明らかになるであろう。

以下は、本発明の一例の詳述を提供することを意図したものであり、本発明自体を制限するものではない。むしろ、付随の請求項によって規定される本発明の範囲内に変形実施例がいくつ含まれてもよい。

図１−Ａ乃至図１−Ｄは、異なるメディア形式から成る複数の通信チャネルを介して、エージェントが顧客サポート要求及び／又は情報要求に応答するのを可能にするクライアント／サーバ・システムの一実施例の図である。これらのメディア形式には、電話、ｅ−メール、ファックス、web連携、インターネット「call me now」及び「call me later」、webチャット、無線アクセス・プロトコル、ページング、ショート・メッセージ・サービスが含まれる（但し、これらだけに制限されるわけではない）。本明細書で用いられている用語「顧客」は、ビジネスでの交渉相手及び個人を含んでおり、それらは、企業の顧客、潜在的な顧客、及び顧客サポート・エージェントが通信するその他の相手である。

図１−Ａには、４人の顧客がクライアント／サーバ・システム１００に顧客サポート要求を提出しており、１人のエージェントが顧客サポート要求に応答している様子が示されている。これら４人の顧客は、通信チャネル１３０Ａ、１３０Ｂ、１３０Ｃ、１３０Ｄ等の４つの通信チャネル１３０を介して顧客サポート要求を提出している。一実施例では、これら４つの通信チャネルのうちの少なくとも２つが異なるメディア形式をサポートしている。

本発明によれば、クライアント／サーバ・システム１００は、複数の通信チャネルから、顧客サポート要求に応答する適切な技能を備えているエージェントに、仕事項目の割当て、ルーティング、及びキューイングを行うことが可能な汎用キューイング（UQ）システム１０２を含んでいる。この用語「ワーク・アイテム」は、電話呼出し、ｅ−メール、ファックス、若しくは別のメディア形式から成るその他の通信の形態である顧客サポート要求への応答等の、クライアント／サーバ・システム１００によって割当てられたエージェントからの応答を要求する顧客からの要求のことを指している。ワーク・アイテムは、入力顧客サポート要求等のイベントが到着したときに、若しくはエージェントがクライアント／サーバ・システム１００へのインタフェースを利用することによって開始されてよい。

クライアント／サーバ・システム１００は、更に、エージェントが顧客との通信に異なるメディア形式の通信チャネルを利用することを可能にする通信サーバ１０９を含む。通信サーバ１０９は、例えば、チャネル・ドライバ１２０Ａ、１２０Ｂ、及び１２０Ｃのうちの１つであるチャネル・ドライバ１２０からの入力顧客サポート要求の到着等のイベントを処理する。各チャネル・ドライバ１２０は、例えば、通信チャネル１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄのうちの１つである通信チャネル１３０と通信する。

UQシステム１０２と通信サーバ１０９とのインタラクションは、例えば、通信サーバ１０９が、入力顧客要求を受信して、エージェントへの割当てのためにワーク・アイテムとしてUQシステムにルーティングを行う際に生じる。UQシステム１０２は、このワーク・アイテムにエージェントを割当てて、その割当てエージェントとの通信のために、ワーク・アイテムを通信サーバ１０９に送り返す。

Webブラウザ・クライアント１０４Ａは、クライアント・コンピュータ・システム（図示せず）上で実行される、Microsoft社のInternet Explorer等のwebブラウザ・プログラムを含む。このwebブラウザ・クライアント１０４Ａは、webサーバ１８８と通信する。クライアント／サーバ・システム１００内のアプリケーション・サーバ１２６は、情報のための機能を実行し、且つ情報をwebサーバ１８８を介してwebブラウザ・クライアント１０４Ａに送信して、それにより、表示するためのwebページをwebブラウザ・クライアント１０４Ａに提供する。Webサーバ１８８によって、Javaアプレット１１６（Java（登録商標））等のプログラム命令をwebブラウザ・クライアント１０４Ａにダウンロードすることが可能であり、それにより、ユーザ・インタフェース等の付加機能が提供される。

Webブラウザ・クライアント１０４Ａは、ツール・バー１０５を含んで示されている。当業者は、本発明の範囲内にある種々のメディア形式から成る複数の通信チャネルとインターフェースをとる多種多様な表示フォーマットが利用されている、ツール・バー１０５の機能性を提供する他のユーザ・インタフェースが実装されてもよいことを理解するであろう。ツール・バー１０５は、ユーザ・インタフェースの一部として存在している。

一実施例では、クライアント／サーバ・システム１００のアプリケーション・サーバ１２６は、オブジェクト・マネージャ１０７、セッション・モード通信サーバ１１０、要求モード通信サーバ１４０、着信通信受信機１７０、UQシステム１０２、webサーバ１８８、webサーバ１４６、エンタープライズ・アプリケーション・インタフェース（EAI）オブジェクト・マネージャ１９０、及びワークフロー・プロセス１４４を含んでいる。一実施例では、アプリケーション・サーバ１２６内の構成要素の間の通信は、当技術分野で公知の伝送制御プロトコル／インターネット・プロトコル（TCP／IP）と共に、適切なプロセス間通信プロトコルを利用して可能にされる。

UQビジネス・サービス１０６によって、通信サーバ１０９が、UQシステム１０２から情報を要求することが可能にされている。UQシステム１０２は、webサーバ１４６、及びEAIオブジェクト・マネージャ１９０を介してその情報を返す。一実施例では、セッション・モード通信サーバ１１０及び着信通信受信機１７０が共にUQシステム１０２と通信することが可能である。別の実施例では、ワーク・アイテムキューの保守、及びエージェントのワーク・アイテムへの割当てのために、サードパーティ・キューイング・システムと通信することが可能である。

通信サーバ１０９は、セッション・モード通信サーバ１１０を含む。通信サーバ１０９は、所望に応じて、要求モード通信サーバ１４０及び着信通信サーバ１７０のうちの一方、若しくは両方を含んでいてよい。サーバ１１０、１４０、及び１７０によって提供される機能が、単一のサーバ・コンピュータ・システム上に実装することも可能であり、或いは、２以上のサーバ・コンピュータ・システムに分散させることも可能であるということに留意するのは重要である。通信サーバ１０９によって、１以上のメディア形式の通信チャネル１３０を介した、エージェントと顧客との間の全ての通信の処理が行われる。通信サーバ１０９は、メディア特異性を有しておらず、且つ通信チャネル若しくはメディアの知識を有していない。

種々のメディア形式の複数の通信チャネルと通信するために、通信サーバ１０９は、例えば、チャネル・ドライバ１２０Ａ、１２０Ｂ、及び１２０Ｃのうちの１つであるチャネル・ドライバ１２０と通信するように設計されている。チャネル・ドライバ１２０は、通信アプリケーション・プログラム・インターフェース（API）に従って書かれている。通信装置及び通信ソフトウェアのサードパーティ・ベンダ（例えば、通信装置に対するミドルウェア・ベンダ）がチャネル・ドライバ１２０を提供できるように、通信API１２５によってインタフェースが提供されて、それにより、それらの製品がアプリケーション・サーバ１２６と互換性を有する。チャネル・ドライバ１２０を実装することによって、ベンダは、アプリケーション・サーバ１２６の顧客サポート・センタ管理機能及びマルチ・メディア通信チャネル能力を活用することが可能になる。

通信API１２５は、サードパーティ・ベンダの製品が組込めるようにサードパーティ・ベンダに対してフレキシビリティを提供するように設計されている。チャネル・ドライバを実装する際に、ベンダは、そのベンダの通信チャネル１３０が理解するコマンドを規定して、それにより、通信サーバ１０９は、その通信チャネル１３０が実行されるようにコマンドを発行することが可能になる。通常、これらのコマンドは、セッション・モード通信サーバ１１０がエージェントへのユーザ・インタフェースを有している際に発行されるが、場合によっては、着信通信受信機１７０がコマンドを送信することも可能である。

更に、ベンダによって、特定の通信チャネル１３０の関連するアクティビティを提供するイベントが規定される。最終的に、各コマンドを実行するための、且つ各イベントを生成及び提供するための、ダイナミック・リンク・ライブラリ（.DLLファイル）等のチャネル・ドライバの実装がベンダによって提供される。このチャネル・ドライバ１２０の実装において、ドライバ・オブジェクト及び少なくとも１つのサービス・オブジェクトのインスタンス生成を行うコードを含むことが、通信API１２５によって必要とされる。

ベンダに対して、そのベンダの通信チャネル１３０にコマンドが発行できるように、且つそのベンダの通信チャネル１３０から情報を受信できるように、通信サーバ１０９のための設備を提供することを要求することによって、通信API１２５は、通信サーバ１０９が通信チャネル１３０のメディア形式及び特定プロトコルに依存せずに動作して、そのベンダの通信装置及び通信ソフトウェアと通信することを可能にしている。

図２を参照すると、チャネル・ドライバ情報、メディア・アクセス上のエージェント制限、コマンド及びイベント、着信タスク管理、エージェント成績、エージェント・ステータス、メディア・ステータス、通信チャネル構成、複数キュー・サポート、並びにエージェント管理の記憶及び通信を行うためにクライアント／サーバ・システム１００（図１−Ａ）によって利用可能であるデータベース・スキーマ２００の一例が示されている。データベース・スキーマ２００は、構成ベース２０２、コマンド及びイベント２０４、システム・ベース２０６、応答グループ２０８、及びｅ−メール・プロフィール・アクセス制御２１０に対するデータ構造を含んでいる。

図２−ａ乃至図２−ｃｃは、図２におけるテーブル名に対応しているテーブルの例を示している。単純化のために図２はテーブル間の全ての関係を示しておらず、又、許可された通信チャネルの数及び種類に応じて、特定の構成に対して多数のテーブルの例が存在し得ることに留意されたい。更に、当業者ならば、各テーブルがパラメータを含み、且つそれらのパラメータに対して記憶空間が許可されているテーブルのこのコレクションは、データベース・スキーマがどのようにして構成されるかの一例であり、本発明に従って、別の適切な配置を用いることも可能であることを理解するであろう。

図２−ａ、図２−ｂ、図２−ｃ、及び図２−ｄのテーブルは、システム・ベース２０６の一部であり、チャネル・ドライバ情報及びチャネル・ドライバ・パラメータが記憶されている。図２−ａ及び図２−ｂのテーブルは、例えば、チャネル・ドライバ１２０Ａ、１２０Ｂ、及び１２０Ｃ等のチャネル・ドライバに対する一般的な情報を記憶しており、任意の顧客サポート・センタ構成に用いられてよい。これらのテーブルに記憶される典型的なデータは、チャネル・ドライバDLLのファイル名、関連通信チャネル１３０のメディア形式（例えば、ｅメール、ファックス等）、チャネル・ドライバに対するメディア・サービスを呼出すように実行時に通信サーバ１０９によって用いられるメディア・ストリング、チャネル・ドライバ・パラメータの完全なリスト、及び各チャネル・ドライバ・パラメータに対するデフォルト値である。テーブルCNCTR（図２−ａ参照）のパラメータINBOUND_FLG及びOUTBOUND_FLGは、チャネル・ドライバ１２０が着信及び／又は発信の通信をサポートするかどうかを示している。

類似の通信要求を有し、それにより、同じ通信チャネル１３０へのアクセスを要求するエージェント・グループを規定するような構成で、顧客サポート・センタが構築されてよい。例えば、企業内の販売員は、無線アクセス・プロトコルを介して通信する能力が必要であるのに対して、電話オペレータにそのような能力は不要である。企業内の各グループに対して１つの構成が構築されてよい。付加的なチャネル・ドライバ・プロフィールの各々がチャネル・ドライバDLLの位置等の何らかのチャネル・ドライバ・パラメータの値をオーバーライドすることによって、チャネル・ドライバ・プロフィールが、１以上の顧客サポート・センタ構成が単一のチャネル・ドライバ１２０を共有することを可能にする。例えば、企業のネットワーク・アーキテクチャが原因で、フェニックス（Phoenix）にある企業の販売員は、パロアルト（Palo Alto）の販売員とは異なるチャネル・ドライバ１２０を用いる可能性がある。チャネル・ドライバ・プロフィールによって、異なるDLLが指示される以外は、フェニックスの販売員とパロアルトの販売員とが同一のチャネル・ドライバを利用することが可能になる。本明細書中では、用語「チャネル・ドライバ１２０」は、チャネル・ドライバ・パラメータに対するデフォルト値を提供する、少なくとも１つのチャネル・ドライバ・プロフィールを含むものとして用いられている。

図２−ｃ及び図２−ｄのテーブルは、特定の顧客サポート・センタ構成に対するチャネル・ドライバ・プロフィールを記憶しており、このチャネル・ドライバ・プロフィールは、他の顧客サポート・センタ構成によって共有若しくは利用はさない。通常、管理者はテーブルCNCTR_PARMを用いて、特定の顧客サポート・センタ構成のために、チャネル・ドライバ・パラメータに対するデフォルト値をオーバーライドする。図２−ａを参照すると、可変なCNCTR_MEDIA_STRに記憶されるストリングは、チャネル・ドライバ１２０によってサポートされる通信メディア名のリストに基づいている。管理者は、メディア名をこのCNCTR_MEDIA_STRフィールドに文字列形式で入力する。このフィールドに記憶されたストリングは、そこにコマンドを発行する、若しくはそこからイベントが生じる、チャネル・ドライバ１２０を決定するのに用いられる。１つのチャネル・ドライバ１２０によって複数の種類の通信メディアがサポートされている場合、管理者は、各メディア形式毎に１レコードを生成する。以下の例は、電話、ｅメール、及びwebチャット・メディアに対してのCNCTRテーブルのパラメータを示している。

｛"XYZ Phone Driver", "Telephone", "xyz.dll", "Y", "Y", "XYZ Phone Implementation", "N"｝,
｛"XYZ Email Driver", "Email", "xyz.dll", "Y", "Y", "XYZ Email Implementation", "N"｝,
｛"XYZ Web Chat Driver", "Web Chat", "xyz.dll", "Y", "Y", "XYZ Web-Chat Implementation", "N"｝
エージェント割当てのためにワーク・アイテムがUQシステム１０２（図１−Ａ参照）に提出されると、そのメディア形式を利用する技術を備えたエージェントがUQシステム１０２により特定されるのを助けるように、このワーク・アイテムと共にCNCTR_MEDIA_STRも渡される。

特定のエージェントに対するチャネル・ドライバ１２０のリストを決定するためのアルゴリズムの一例は以下の通りである。

１．AGENTテーブル（図２−ｊ参照）を探索することによって、エージェントに対する構成IDを決定する。

２．その構成IDに関して、この構成に関連するチャネル・ドライバ・プロフィールのリストのためにCFG_PROFテーブル（図２−ｏ参照）を探索する。

３．チャネル・ドライバ１２０の各々に関して、CNCTR、CNCTR_PARM、PROF、及びPROF_PARM（図２−ａ乃至図２−ｄの各々を参照）テーブルからチャネル・ドライバ情報及びチャネル・ドライバ・パラメータをロードする。

エージェントがクライアント／サーバ・システム１００にログインするのに応じて、チャネル・ドライバ１２０のリストをロードするためのアルゴリズムの一例は、以下の通りである。

１．チャネル・ドライバ１２０の各々に対して、
ａ．DLLがまだロードされていない場合、DLLをロードする。

ｂ．チャネル・ドライバ・パラメータを渡して、チャネル・ドライバにドライバ・オブジェクトの処理を依頼する。

ｃ．エージェントと関連しているものとして、CFG_PROF（図２−ｏ参照）で特定されるチャネル・ドライバのメディア形式を渡すことによって、サービス・オブジェクトの処理を要求する。

２．ループを終了する。

デフォルト設定では、エージェントはそのエージェントが属する構成に関連付けられている全てのチャネル・ドライバ１２０へのアクセスが許可されている。例えば、エージェントが「Customer support center 1」に属する場合には、「Customer support center 1」に設定されている全てのチャネル・ドライバ・プロフィールに対してデフォルトでアクセス可能である。更に、管理者は、エージェントがアクセス不可能なチャネル・ドライバ・プロフィールをリストにしたテーブルAGENT_LIM（図２−ｍ参照）を用いて、そのエージェントのチャネル・ドライバ１２０へのアクセスを制限することも可能である。

エージェントの優先度が、中央データベース内のテーブルAGENT_PREF（図２−ｅ参照）に記憶されて、それにより、エージェントの設定が、用いられるクライアントの種類若しくは通信チャネルとは無関係に利用可能になる。更に、設定を修正するためのユーザ・インタフェースも本発明の一実施例で提供される。

本発明の実施例によって、UQシステム１０２（図１−Ａ参照）を用いたエージェント割当て及び複数の通信メディア・チャネルが支援される。テーブルAGENT_STAT（図２−ｆ参照）は、特定のエージェントの、そのエージェントが利用を許可されている全てのメディア形式に対しての現在の作業ステータスを記憶する。このテーブルから、管理者は、エージェントが現在アクセスが許可されているメディア形式と、各メディア形式のステータスとのリストを見ることが可能である。

テーブルAGENT_STAT（図２−ｆ参照）内のパラメータ「NOT_READY_FLG」によって、エージェントがワーク・アイテムを受取る準備がまだ整っていないことが示されている場合、UQシステム１０２（図１−Ａ参照）は、そのエージェントに、いずれのワーク・アイテムも割当てない。「BUSY_FLG」パラメータは、そのエージェントが取込み中であることを示す。

テーブルAGENT_STATは、主として実行時間中に更新される。エージェントがユーザ・インタフェースを用いて最初にログインした際に、そのエージェントがアクセスを許可されているメディア形式の各々に対して１レコードずつ生成される。例えば、
｛"agent_emp_id","Phone Control","","","1234",""｝,
｛"agent_emp_id","Email/Fax","","","1234",""｝,
｛"agent_emp_id","Web Chat","","","1234",""｝
これらのレコードは、エージェントの作業ステータスによって更新される。例えば、
｛"agent_emp_id","Phone Control","Y","","1234","Y"｝は、そのエージェントの準備は整っていないが、電話で話し中であることを示しており、
｛"agent_emp_id","Email/Fax","Y","","1234",""｝は、そのエージェントがEmail/Fax形式の作業を受入れる準備が整っていないことを示しており、
｛"agent_emp_id","Web Chat","N","","1234","Y"｝は、そのエージェントがwebチャット形式の作業を受入れる準備ができており、且つ彼若しくは彼女はwebチャット・セッション上で現在作業をしていることを示している。

テーブルMEDIA_STAT（図２−ｄ参照）を参照すると、電話に対するパラメータ「MEDIA_OBJECT_STR」は、エージェントの内線番号である。ファックスの場合には、ファックス番号となる。MEDIA_OBJECT_STRの内容の形式は、チャネル・ドライバ１２０の各々に対して規定される。

「WORKING_SINCE_DT」は、エージェントが電話での話を開始した時間、若しくはｅ−メール若しくはファックス等のワーク・アイテムへの取組みを開始した時間である。

「WORK_ITEM_STR」は、通信サーバ１０９によって決定されるフィールドの値及びワーク・アイテムを識別するための固有のストリングである。MEDIA_STATテーブルは、エージェントの現在の作業ステータスを反映させるように、実行時間中に更新される。実行時間中のエージェントのデータ・レコードの一例は、以下の通りである。

｛"agent_id","Phone Control","Ext.5216","6/25/2000 12:34:45","phone_item_str","1-1S2-X7E"｝,
｛"agent_id","Email","info@company.com","6/25/2000 11:34:00","email_item_str","1-1S2-X7D"｝
上記のレコードは、エージェントが内線５２１６で現在話し中であり、且つinfo@company.comに送信されるｅ−メールに取組んでいることを示している。

複数の内線及び複数のキューが、図２−ｈ、図２−ｉ、及び図２−ｊで各々示されているテーブルTELESET、EXTENSION、及びAGENT_QUEを用いてクライアント／サーバ・システム１００（図１−Ａ）内でサポートされている。以下の用語は、図２−ｈ、図２−ｉ、及び図２−ｊで参照される。用語「自動着信分配（ACD）内線」は、ACDスイッチ１３０Ｅ等のACDスイッチに関連付けられているACDキューへのログインに利用される内線形式を示している。一度、内線がACDキューにログインすると、ACDスイッチによって、顧客の呼出しがその内線に転送される。１つのACD内線は、１以上のACDキューにログインすることが可能である。

用語「標準内線（standard extension）」は、ACDキューへのログインが許可されていない電話内線形式を示している。標準内線は、主として外に電話するために、若しくは内部の呼出しに応答するために利用される。ACDスイッチによって、顧客の呼出しが標準内線に転送されることはない。

用語「エージェントID」は、エージェントを識別するためにクライアント／サーバ・システム１００によって用いられる識別子を示している。クライアント／サーバ・システム１００がエージェントの利用可能性（availability）を認識できるように、各顧客サポート・センタのエージェントにはエージェントIDが割当てられている。エージェントがACDスイッチ１３０Ｅを備えている通信チャネルにログインする際に、このエージェントIDがACDスイッチ１３０Ｅに提供される。システムの構成に応じて、ACDスイッチ１３０Ｅ若しくはUQシステム１０２が、ワーク・アイテムに対して利用可能なエージェントIDを決定する。次に、ACDスイッチ１３０Ｅが顧客の呼出しをそのエージェントIDのACD内線に転送するか、若しくはエージェントの割当てにUQシステム１０２が利用されている場合には、通信サーバ１０９がチャネル・ドライバ１２０のうちの１つを用いて顧客の呼出しをそのエージェントIDのACD内線に転送する。

「複数DN（multiple DN）」は、１つの電話端末に対して構成された、１以上の内線がACD内線である複数の内線を示している。

「複数キュー（multiple cue）」は、１つのACD内線が複数のキューにログイン可能であることを意味している。概して、ACDキューはエージェントIDのリストであるので、このエージェントIDがACDキューに受入れられる限り、任意のACD内線を用いてACDキューにログインすることが可能である。

一実施例では、エージェントに対する内線リストを決定するための方法には、そのエージェントによって用いられる第１端末が特定される、ACTIVE_TELESET_IDパラメータ内にある第１Teleset IDをみつけるために、AGENTテーブル（図２−ｊ参照）内のエージェントIDを探索するステップが含まれる。次に、内線リストが、EXTENSIONテーブル（図２−ｉ参照）内にあるDN_EXTパラメータから決定される。一度、この内線リストがみつかってしまえば、このエージェントが利用する全ての内線が、その特定のエージェントに対してAGENT_QUEテーブル（図２−ｌ参照）内で規定されている全てのACDキューにログインすることが可能になる。

上述のように、類似の通信要件を備えていて、同じ通信チャネル１３０にアクセスすることが必要とされるエージェントのグループが、顧客サポート・センタによって規定され得る。構成ベース２０２は、構成に関するテーブルを含んでいる。CFGテーブル（図２−ｎ参照）は、構成に関する情報を含んでいる。構成データは、構成名と、この構成が着信応答グループのためのものであり、着信通信受信機１７０で用いられるかどうかを示すINGRP_FLAGとを含む。CFG_PROFテーブル（図２−ｏ参照）は、各構成にいずれのチャネル・ドライバ・プロフィールが属するかが示されている構成／チャネル・ドライバ・プロフィールの関連テーブルである。各構成は、単一のチャネル・ドライバ・プロフィールを有する。

AGENT_CFGテーブル（図２−ｐ参照）は、各構成にいずれのエージェントが属するかが示されているエージェント／構成の関連テーブルである。

CFG_PARMテーブル（図２−ｑ参照）は、構成パラメータ・テーブルである。各構成パラメータに対して名前及び値が提供される。ACTIVE_FLGフィールドは、この構成パラメータの値がアクティブであるかどうかを示しているフラグである。

コマンド及びイベントのデータ構造２０４は、チャネル・ドライバ１２０によって実行されるコマンド及びイベントを説明する情報も含んでいる。この情報は、各コマンドをチャネル・ドライバ１２０と関連付ける情報、及び各イベントをチャネル・ドライバ１２０と関連付ける情報を含んでいる。

CMDテーブル（図２−ｒ参照）は、各チャネル・ドライバ１２０に対するコマンドを含んでいる。上述のように、チャネル・ドライバ１２０を提供するベンダは、そのベンダがサポートするコマンドを特定している。通信チャネル１３０を用いてコマンドを実行するように、通信サーバ１０９によって、コマンドがチャネル・ドライバ１２０に発行される。ツール・バー１０５のボタンをクリックする度に、コマンドが呼出されて、チャネル・サーバ１２０に発行される。

コマンドは、サブコマンドとして機能する関連コマンドのグループを有する。グループ・コマンドは、サブコマンド・キーワードを用いて別のコマンドを含む。

以下は、交信相手への電話呼出しをする際の単一コマンドの一例である。

[Command: MakeCalltoContact] コマンド定義
CmdData = "MakeCalltoContact" コマンド・パラメータ
DeviceCommand = "MakeCall" コマンド・パラメータ
Description = "Make Call to Contact" コマンド・パラメータ
Hidden = TRUE コマンド・パラメータ
[CmdData: MakeCalltoContact] コマンド・データ定義
BusComp = "Contact" コマンド・パラメータ
RequiredField.'Work Phone#' = "?*" コマンド・パラメータ
Param.PhoneNumber = "{Work Phone#: Lookup}" コマンド・パラメータ
以下は、交信相手への電話呼出しをする際のグループ・コマンドの一例である。

[Command: MakeCallGroup]
Hidden = TRUE
SubCommand = MakeCalltoPhone
SubCommand = MakeCalltoSRContact
SubCommand = MakeCalltoSROwner
SubCommand = MakeCalltoEmployeeHome
以下の例のコマンドは、単一コマンドにもサブコマンドにもなり得る。

[Command: MakeCalltoPhone] コマンド定義
CmdData = "MakeCalltoPhone" コマンド・パラメータ
DeviceCommand = "MakeCall" コマンド・パラメータ
Description = "Make Call to {@Phone}" コマンド・パラメータ
Hidden = TRUE コマンド・パラメータ
[CmdData: MakeCalltoPhone] コマンド・データ定義
[CmdData: MakeCalltoPhone] コマンド・データ定義
RequiredField.'Work Phone #' = "?*"
Param.PhoneNumber = {@Phone:PhoneTypeLookup}
コマンドは、チャネル・ドライバ１２０と通信するように、データ・パラメータを特定するためのCmdDataキーワードを備えたコマンド・データ・セクションを有していてよい。

顧客サポート・センタ構成が複数のチャネル・ドライバ１２０を含む場合、通信サーバ１０９は、各チャネル・ドライバ１２０によっていずれのコマンド及びイベントが処理されるかを決定することが可能である。更に、この構成は、異なる機能が実行されるコマンドに対して同一の名前を用いている、異なるベンダからのチャネル・ドライバ１２０を区別する助けになる。

以下は、CmdDataキーワードを有するデータ・セクションを備えたコマンドの一例である。

[Command: MakeCalltoContact]
CmdData = "MakeCalltoContact"
DeviceCommand = "MakeCall"
Description = "Make Call to Contact"
Hidden = TRUE
[CmdData: MakeCalltoContact]
BusComp = "Contact"
RequiredField.'Work Phone #' = "?*"
Param.PhoneNumber = "{Work Phone # : Lookup}"

イベント・テーブルは、チャネル・ドライバ１２０から通信サーバ１０９に送信されるイベントを含んでいる。ベンダによって、チャネル・ドライバ１２０に送信されるイベントが特定されている。イベント応答によって、各メディア・イベントの受信に応じて通信サーバ１０９がどのように反応するかが決定される。イベントを処理するプロセスには、以下の：イベントに対するイベント・ハンドラを探索するステップ、適切なイベント応答を決定するために顧客サポート・センタ・データベースに照会をするステップ、及びイベントをロギングするステップが含まれる。

InboundCallイベントに対するイベント、イベント・ハンドラ、イベント応答、及びイベント・ログの一例が下記に示されている。

[EventHandler: OnInboundCall] 第１段階、イベント・ハンドラ定義
Device = "EventRinging" メディア・イベント定義
Response = "OnInsideCallReceived" イベント応答宣言
Filter.Call = "?*" イベント・ハンドラ・パラメータ
Order = "1" イベント・ハンドラ・オーダ

[EventResponse: OnInboundCallReceived] 第２段階、イベント応答定義
QueryBusObj = "Contact" イベント応答パラメータ
QueryBusComp = "Contact"
QuerySpec = "'Work Phone #'='{ANI}'"
SingleView = "Service Contact Detail View"
MultiView = "Contact List View"
FindDialog = "Service Request"
FindField.CSN = "Ask Caller"
FindLog = "LogIncomingCallContactNotFound" イベント・ログ宣言
SingleLog = "LogIncomingCallContactFound" イベント・ログ宣言
Log = "LogIncomingCallContactNotFound" イベント・ログ宣言

[EventLog: LogIncomingCallContactFound] βイベント・ログ宣言
Display = "TRUE" βイベント・ログ・パラメータ
BusObj = "Action"
BusComp = "Action"
LogField.Type = "Call-Inbound"
LogField.'Account Id' = "{Contact.'Account Id'}"
LogField.'Contact Id" = "{Contact.Id}"
LogField.Description = "Inbound call"
LogField.'Call Id' = "{ConnID}"
AfterCall.'ACD Call Duration' = {@CallDuration}

各イベント・ハンドラは、チャネル・ドライバ１２０によって提供されるイベントと対応しており、イベントに対するイベント・ハンドラの間で順序が付けられている。各イベント・ハンドラは、イベント応答を有している。イベント応答は、イベント・ハンドラの間で共有可能である。１つのイベント応答が、複数のイベント・ログを有していてよいし、更に、１つのイベント・ログが複数のイベント応答の間で共有されてもよい。

セッション・モードで動作する場合には、通信サーバ１０９は、セッション・モード通信サーバ１１０の制御下にある。セッション・モード通信サーバ１１０は、顧客サポート要求等の入力イベントの受信を行い、且つそのエージェントが有するユーザ・インタフェースを制御することによって、エージェントとインタラクティブに通信する。好適には、入力顧客サポート要求は、通信サーバがその顧客サポート要求を受信したのと概ね同時にエージェントに送信される。その際の中断は、その顧客サポート要求を転送するための処理及び転送だけが可能な非常に短時間である。これによって、顧客の待機時間、特に、エージェントとの生の対話を求める顧客の要求に対する待機時間が確実に最小化される。

入力電話呼出しの到着等のイベントが発生すると、ユーザ・インタフェースは、エージェントの注意を喚起するように、ユーザ・インタフェースを変更する通知機能を用いて、エージェントへの通知を行う。例えば、エージェントに電話呼出しを通知するように、通知機能によってボタンの点滅が生じてもよい。更に、通知機能によって、別の情報、例えば、エージェントが電話に出る前に呼出している人に関する情報等が表示されてもよい。電話呼出しを受取るために、電話を保留にするために、若しくは電話を切るために、エージェントがツール・バー１０５を利用すると、ユーザ・インタフェースによって、セッション・モード通信サーバ１１０にコマンドが送信される。このセッション・モード通信サーバは、電話を制御する通信チャネルにコマンドを発行するために、チャネル・ドライバ１２０のうちの１つと通信する。

更に、セッション・モード通信サーバ１１０は、通信チャネル１３０Ａ乃至１３０Ｄ等の１以上の通信チャネル１３０への接続の確立及び保持の処理も行っている。セッション・モード通信サーバ１１０は、接続を確立するために、チャネル・ドライバ１２０Ａ等のチャネル・ドライバ１２０のうちの１つを利用している。通信チャネルへの接続を有することによって、エージェントは、そのエージェントに対して特に指定されている、ｅ−メール等の入力ワーク・アイテムをリアルタイムに受信することが可能になる。その接続は、ミドルウェア・サーバへの接続であってもよいし、webサーバへの接続であってもよいし、メディア・デバイスへの直接的な接続であってもよいし、若しくは顧客がそこから通信を受けることが可能な任意のその他の通信手段への接続であってもよい。この接続は、ミドルウェア・サーバへのTCP／IPソケット接続として、IadviseSinkインタフェース等のOLEインタフェースとして、若しくはその他の任意の適切なプロセス間通信スキーマとして、確立されてもよい。チャネル・ドライバ１２０の各々は、通信チャネル１３０との接続を確立するのに必要な全ての情報を含んでおり、それにより、通信サーバ１０９は、通信チャネル１３０を別々に作動させる。

図１−Ｂは、セッション・モード通信サーバ１１０の一実施例の詳細図を示している。セッション・モード通信サーバ１１０は、接続されているクライアント１０４（この場合は、webブラウザ・クライアント１０４Ａ）の知識を保持している。ACDスイッチ１３０Ｅ等の通信チャネル１３０からの通信を受取ると、通信サーバ１０９は、実行のためにクライアント／サーバ・システム内の適切なサーバ構成要素に要求を発信する。

セッション・スレッド１２２は、エージェントがwebブラウザ・クライアント１０４Ａを用いてクライアント／サーバ・システム１００と対話する際のセッションを表している。顧客は、通信チャネルにアクセスするのに顧客の通信装置（ここでは、電話）を用いる。同様にして、エージェントは、通信チャネルにアクセスするために電話ヘッドセット等の通信装置を用いる。

セッション・スレッド１２２は、webブラウザ・クライアント１０４Ａからの入力を待って（listen）、ACDスイッチ・ドライバ１２０Ｄからwebブラウザ・クライアント１０４Ａへのイベント通知を発信する。セッション・スレッド１２２は、ACDスイッチ・ドライバ１２０Ｄと対話するのに通信チャネル・マネージャ１２４等の通信チャネル・マネージャを利用する。各チャネル・ドライバ１２０は、クライアントと関連の通信チャネルとの間に、例えば、アクティブな接続１３３等のアクティブな接続を提供する。チャネル・ドライバ１２０は、クライアント１０４と通信チャネル１３０Ｅとの間にインタラクティブな通信のために持続的な接続を確立するように実装されてよいが、持続的な接続を設けることを通信APIが必要としているわけではない。

以下の例は、開始、初期化、及び動作の際に、webブラウザ・クライアント１０４Ａが従うプロセスを説明している。webブラウザ・クライアント１０４Ａに対するこのプロセスは、以下で更に詳しく説明がされる他の種類のクライアントに適用することも可能である。

webブラウザ・クライアント１０４Ａが実行を開始する場合には、
１．Webブラウザ・クライアント１０４Ａは、webサーバ１８８から、ツール・バー１０５（ここでは、Javaアプレット１１６を利用して実装されているのが示されている）等のwebブラウザのディスプレイ上のユーザ・インタフェースを生成するために、プログラム命令をダウンロードする。更に、webサーバ１８８が連続的にwebブラウザ・クライアント１０４Ａに情報を提供できるように、Javaアプレット１１６は、Javaアプレット１１６とwebサーバ１８８との間に持続的なHTTP接続を確立する。

２．Webブラウザ・クライアント１０４Ａは、webエンジン・セッション・スレッド１６６を介して、セッション・モード通信サーバ１１０とインターフェースをとる。オブジェクト・マネージャ１０７は、webエンジン・プラグイン１８５及びwebエンジン１１５を利用して、webブラウザ・クライアント１０４Ａとインターフェースをとるためのwebエンジン・セッション・スレッド１６６を生み出す。通信クライアント・サービス１６０によって、webブラウザ・クライアント１０４Ａのユーザ・インタフェースに関連する全ての通信が提供される。

３．通信クライアント・サービス１６０は、オブジェクト・マネージャ１０７に通信サービスを要求する。ユーザ・インタフェースに関連しない通信の全てを提供する通信サービス１１３が提供される。

４．通信サービス１１３は、コマンド、イベント、エージェントの情報及び優先度、チャネル・ドライバ情報、並びにチャネル・ドライバ・パラメータ等の構成情報をロードする。

５．通信サービス１１３は、非同期のイベントを続けて受信した際に呼出される非同期イベント受信関数をオブジェクト・マネージャ１０７に登録する。この非同期イベント受信関数は、コールバック関数とも呼ばれる。非同期イベントの受信は、以下で更に詳しく説明される。

６．通信サービス１１３は、オブジェクト・マネージャ１０７とwebエンジン・プラグイン１８５との間のアクティブな接続１３５Ａ、及び通信サービス１１３とセッション・モード通信サーバ１１０との間のアクティブな接続１３５Ｂを要求する。持続的なHTTP接続１３１と、アクティブな接続１３５Ａ及び１３５Ｂとによって、セッション・モード通信サーバ１１０がJavaアプレット１１６を利用しているツール・バー１０５にユーザ・インタフェースの変更を継続的に転送することが可能にされる。

７．セッション・モード通信サーバ１１０は、通信要求に応じて、例えば、セッション・スレッド１２２等のセッション・スレッドを生み出す。

８．セッション・スレッド１２２は、通信チャネル・マネージャ１２４を実行する。

９．通信チャネル・マネージャ１２４は、ACDスイッチ・ドライバ１２０Ｄをロードして、通信サービス１１３によって決定されたチャネル・ドライバ・パラメータを渡す。

１０．ACDスイッチ・ドライバ１２０Ｄは、ACDスイッチ１３０Ｅへのアクティブな接続１３３を確立する。チャネル・ドライバ１２０を実装するベンダによって、電話接続に関して、アクティブ接続１３３等の通信チャネル１３０への持続的な接続を提供するということが選択されてもよい。しかしながら、通信API１２５が持続的な接続を必要としているわけではない。

エージェントが、webブラウザ・クライアント１０４Ａを利用して、ツール・バー１０５上のボタンをクリックする等のコマンド実行を必要とする作業を実行する場合には、
１．通信クライアント・サービス１６０は、コマンドを呼出すために予めロードされているコマンド構成データを探索する。更に、それは、そのコマンドに関連するデータを収集して、通信サービス１１３にそのコマンド及びデータを渡す。

２．通信サービス１１３は、通信チャネル・マネージャ１２４にそのコマンド及びデータを渡す。

３．通信チャネル・マネージャ１２４は、次に、いずれのチャネル・ドライバ１２０がクライアントに要求されたコマンドを実行するかを決定して、実行のためにACDスイッチ・ドライバ１２０Ｄ等のチャネル・ドライバ１２０にコマンド及びデータを渡す。

４．ACDスイッチ・ドライバ１２０Ｄは、通信チャネル１３０にコマンドを発行する。この例では、ACDスイッチ・ドライバ１２０Ｄは、ACDスイッチ１３０Ｅにコマンドを発行している。

ACDスイッチ・ドライバ１２０Ｄ等のチャネル・ドライバ１２０が、webブラウザ・クライアント１０４Ａにイベント（ステータス・データ若しくは顧客呼出し等の入力イベント）を転送する必要がある場合には、
１．ACDスイッチ・ドライバ１２０Ｄは、イベントを受信して、そのイベントを通信チャネル・マネージャ１２４に転送する。このため、イベント転送のためにセッション・スレッド１２２での非同期の割込みが必要となる。

２．通信チャネル・マネージャ１２４は、そのイベントを通信サーバ１１３に転送する。

３．通信サービス１１３は、イベントを受信して、登録されている非同期イベント受信関数を実行する。

４．登録されている非同期イベント受信関数は、ACDスイッチ・ドライバ１２０Ｄから送信されたイベントをオブジェクト・マネージャ１０７の内部に格納されているイベント・キューの中に挿入する。

５．セッション・スレッド１２２内で実行されているフレーム・マネージャ（図示せず）が、イベント・キューからイベントを取出して、通信クライアント・サービス１６０を利用して登録されている非同期イベント受信関数を呼出す。

６．通信クライアント・サービス１６０は、通信サービス１１３にそのイベントを処理するように依頼する。

７．通信サービス１１３によってそのイベントが処理された後、通信クライアント・サービス１６０は、Javaアプレット１１６を用いて通信を継続して、ユーザ・インタフェースを変更するために、webブラウザを制御する。

図１−Ｃは、要求モード通信サーバ１４０の一実施例に含まれる構成要素を示している。要求モード通信サーバ１４０は、要求に従った、通信チャネルを介した情報の配信処理を行っている。要求モード通信サーバ１４０の動作の一例としては、例えば、セッション・モード通信サーバ１１０が要求モード通信サーバ１４０に、代わりに多数のｅメールを送信してくれるように要求を送信するといったのがあげられる。これによって、セッション・モード通信サーバ１１０は、自身のリソースをユーザ・インタフェースの制御、コマンドの発行、及びイベントの処理に充てることが可能になる。

サーバ・スレッド１４２等の要求モード・サーバ・スレッドは、要求モード通信サーバ１４０が実行を開始すると生成される。通信マネージャ１５２は、その要求に対するデータを収集するためにロードされる。要求モード通信サーバ１４０は、その要求を処理するための適切なチャネル・ドライバを決定して、通信チャネル・マネージャ１５６にｅメール・ドライバ１２０Ｅをロードするように指示する。通信チャネル・マネージャ１５６は、要求及びデータをｅメール・ドライバ１２０Ｅに発信して、ｅメール・ドライバ１２０Ｅは、その情報をｅメール通信チャネル１３０Ｆに送信する。図１−Ｃに示されている実施例では、ｅメール・ドライバ１２０Ｅは、ｅメール・サーバ１３２を介してｅメール・クライアント１３４にｅメールを送信する。

要求モード通信サーバ１４０の動作の別の例として、オブジェクト・マネージャ１０７が、１以上のワーク・アイテムをUQシステム１０２から要求モード通信サーバ１４０に送信することが可能である。前の例と同様に、要求モード・サーバ・スレッドが生成されて、その要求に対するデータを収集するように通信マネージャ１５２がロードされる。要求モード通信サーバ１４０は、その要求を処理するための適切なチャネル・ドライバを決定して、通信チャネル・マネージャ１５６にｅメール・ドライバ１２０Ｅ等の適切なドライバをロードするように指示する。通信チャネル・マネージャ１５６は、その要求及びデータをドライバに発信して、そのドライバは、その情報を通信チャネルに送信する。

図１−Ｄは、着信通信受信機１７０の実装の一例を示している。着信通信受信機１７０の一実施例は、クライアントと接続せずに、若しくはクライアントの知識なしに、着信顧客サポート要求に対して機能するように設計されている。これは、少なくとも１つのエージェントにユーザ・インタフェースを提供するように、クライアントと通信するセッション・モード通信サーバ１１０とは対照的である。一実施例では、着信通信受信機１７０が、後で処理するようにキューに保持可能であるファックス及びｅメール等の顧客サポート要求を処理するのに対して、セッション・モード通信サーバ１１０が、可能な限り早急に処理する必要のある電話呼出し等の優先度の高いサポート要求を処理して、顧客応答時間を向上させている。別の実施例では、着信通信受信機１７０及びセッション・モード通信サーバ１１０が共に優先度の高いサポート要求を処理することが可能である。

着信通信受信機１７０は、共通のソースから特定の種類の顧客サポート要求を「聞き取る（listen）」ために、ｅメール／ファックス・チャネル・ドライバ１２０Ｆ等のチャネル・ドライバ１２０を利用している。ｅメール・チャネル・ドライバ１２０Ｆは、特定のｅメール・アドレス向けの全てのｅメール・メッセージ、及び特定のファックス番号に送信された全てのファックスを処理する。エージェント間での重複を回避するために、着信通信受信機１７０は、UQシステム１０２と共に作動するように構成されてもよく、それにより、エージェントが着信顧客サポート要求（ｅメール１７３若しくはファックス１７５）に割当てられて、顧客サポート要求がクライアント等の割当てエージェントと関連のある構成要素、若しくは割当てエージェントを示す構成要素にルーティングされる。

更に、着信通信受信機１７０は、初期化の際に、顧客サポート要求を受信した等のイベントを認識して、且つ認識したイベントを処理するべく対応するチャネル・ドライバ情報及びバックグラウンド・プロフィールを含むように、構成される。バックグラウンド・プロフィールは、ｅメール・アドレス、ファックス番号、及びwebチャット・エンドポイントのリスト等の１以上の監視メディア・オブジェクト（monitored media objects）を含んでいる。例えば、ｅメール通信チャネル１３０Ｇは、info@company.comに対するバックグラウンド・プロフィールを示しており、ファックス通信チャネル１３０Ｈは、ファックス番号1−800−123−4567に対するバックグラウンド・プロフィールを示している。

着信通信受信機１７０は、顧客サポート要求等の着信イベントを処理するように、サーバ・スレッド１７４等のサーバ・スレッドを生成する。これは、セッション・モード通信サーバ１１０が、エージェントによって利用される各クライアント１０４に対して、セッション・スレッド１２２等のセッション・スレッドを生成するのと対照的である。次に、通信チャネル・マネージャ１７７が、指定されたバックグラウンド・プロフィールを用いてファックス・サービス・オブジェクト１８３Ａ、ｅメール・サービス・オブジェクト１８３Ｂ、若しくは電話サービス・オブジェクト１８３Ｃ等のサービスを初期化する。

ｅメール／ファックス・チャネル・ドライバ１２０Ｆが、例えば、新規のファックス１７５等の着信顧客サポート要求を受信すると、ファックス・チャネル・ドライバ１２０Ｆは、そのイベントを通信チャネル・マネージャ１７７に転送する。この転送によって、サーバ・スレッド１７４のアイドル状態が中断されて、そのイベントを処理するために、サーバ・スレッド１７４が、通信チャネル・マネージャ１７７を呼出す。通信チャネル・マネージャ１７７は、EVTRESPテーブル等のイベント応答テーブル内に含まれるイベント応答に基づいて、そのイベントにどのように応答するかを決定して、ファックス・サービス・オブジェクト等１８３Ａ等の適切なメディア・サービスを呼出す。イベント応答によって、UQシステム１０２へのイベント通知が指定されている場合、このイベントは、UQビジネス・サービス１０６を介してUQシステム１０２に渡される。イベント通知への応答は、UQビジネス・サービス１０６を介して着信通信受信機１７０に返される。

代替実施例では、クライアント／サーバ・システム１００が、webブラウザ・クライアント１０４Ａとは異なるハードウェア／ソフトウェア構成を備えている多種類のクライアント１０４をサポートしていてよい。図１−Ｅは、webブラウザ・クライアント１０４Ａ、シン・クライアント１０４Ｂ、及び専用クライアント１０４Ｃをサポートしている一代替実施例を図示している。

シン・クライアント１０４Ｂは、エージェントが利用するクライアント・コンピュータ・システム上にインストールされて、実行される１以上のクライアント・ソフトウェア・モジュールを含んでいる。シン・クライアント１０４Ｂによって提供されるのは最低限の機能性であり、シン・クライアント１０４Ｂの機能の大部分は、アプリケーション・サーバ１２６で実行される。たいていの場合は、アプリケーション・プログラムの更新を、各シン・クライアント１０４Ｂに対して複数回行う代わりに、中央部分で一度で行ってしまうように、シン・クライアントを利用するのが望ましい。

シン・クライアント１０４Ｂは、webブラウザ・クライアント１０４Ａよりも、より多くの機能をクライアント側に提供して、例えば、オブジェクト・マネージャ１０７のいくつかの機能を実行する等ということが可能である。更に、シン・クライアント１０４Ｂは、ツール・バー１０５を含むユーザ・インタフェースを制御することも可能である。クライアント側で実行される機能を変更する必要がある場合には、個々のエージェントのコンピュータ・システムの各々にシン・クライアント１０４Ｂの新規のコピーがインストールされる必要がある。

専用クライアント１０４Ｃは、エージェントを支援するのに必要な機能を実行するほとんどの部分を実行するソフトウェア・モジュールを含んでいる。専用クライアントは、「シン・クライアント」という名称と対照的に「ファット・クライアント」と呼ばれる場合もある。専用クライアント１０４Ｃによって提供される機能性に変更が必要な場合には、専用クライアント・ソフトウェア・モジュールの新規のコピーは、通常、クライアント・コンピュータ・システム上にインストールされる必要がある。

専用クライアント１０４Ｃによって提供される機能性は、シン・クライアントによって提供されるものよりもさらに多く、例えば、オブジェクト・マネージャ１０７、webサーバ１８８、通信クライアント・サービス１６０（図１−Ｂ参照）、及び通信サービス１１３により提供される全ての機能性が含まれる。専用クライアント１０４Ｃは、ユーザ・インタフェース及びツール・バー１０５に対する負担を全て引受けているので、専用クライアント１０４Ｃと、通信サーバ１０９、webサーバ１８８、webエンジン・プラグイン１８５、及びwebエンジン１１５（図１−Ｂ参照）との間で通信は行われない。専用クライアント１０４Ｃは、UQシステム１０２とのインタフェースをとることが可能なwebサーバ１４９と、及びチャネル・ドライバ１３０と通信するオブジェクト・マネージャ１５１とを含んでいる。

クライアント１０４Ａ、１０４Ｂ、及び１０４Ｃとは異なるハードウェア及びソフトウェアの構成要素を備えた別の種類のクライアントも、同様にしてクライアント／サーバ・システム１００に組込むことが可能であることに留意する必要がある。

（通信API）
次に、図１−Ｆ乃至図１−Ｊを参照すると、通信サーバ１０９と通信するためのチャネル・ドライバ１２０に対する本発明の一実施例において、通信APIが提供されている。通信サーバ１０９は、以下の通信API１２５の説明で、セッション・モード・サーバ１１０、要求モード通信受信機サーバ１４０、若しくは着信通信受信機１７０を示して用いられていることに留意されたい。

図１−Ｆに示されているように、通信APIの一実施例では、３種類のオブジェクト：ドライバ・オブジェクト１８９、サービス・オブジェクト１８３、及びクライアント・オブジェクト１７９を含んでいる。ドライバ・オブジェクト１８９及びサービス・オブジェクト１８３は、チャネル・ドライバ１２０でインスタンス生成がなされるが、クライアント・オブジェクト１７９は、通信サーバ１０９でインスタンス生成がなされる。通信サーバ１０９は、ドライバ・オブジェクト１８９及びサービス・オブジェクト１８３とのインタフェースをとるが、サービス・オブジェクト１８３だけがクライアント・オブジェクト１７９と通信する。

ドライバ・オブジェクト１８９は、サービス・オブジェクト１８３のインスタンシエーションを保持する。ドライバ・オブジェクト１８９内で、サービス・オブジェクト１８３を構築（construct）及び破棄（destruct）するために任意の特定ステップが実行されてもよい。異なる種類のメディアを管理するために、複数のドライバ・オブジェクト１８９が含まれてもよい。更に、単一のドライバ・オブジェクト１８９によって、１種類のサービス・オブジェクト１８３が管理されてもよいし、或いは多種類のサービス・オブジェクト１８３が管理されてもよい。例えば、単一のドライバ・オブジェクト１８９によって、電話、ｅメール、及びファックスのメディアを管理することが可能である。

ドライバ・オブジェクト１８９の動作の一例では、通信サーバ１０９が起動されると、チャネル・ドライバ１２０データ・リンク・ライブラリ（DLL）がロードされる。通信サーバ１０９によって、ドライバ・オブジェクト１８９の構築を依頼するために、チャネル・ドライバ１２０内にCreateISCSDriverInstance()が呼出される。チャネル・ドライバ１２０は、通信サーバ１０９にドライバ・ハンドルを返す。チャネル・ドライバ１２０によって、ドライバ・オブジェクト１８９をどのようにして生成するかが決定される。ドライバ・オブジェクト１８９が既に存在している場合には、例えば、このチャネル・ドライバ１２０は、新規のドライバ・オブジェクトを生成する代わりに、単に既存のドライバ・オブジェクト１８９を渡すということも可能である。

一実施例では、ドライバ・オブジェクト１８９によってサービス・オブジェクト１８３が生成されて、関連するメディア形式と対話するように、デバイス・コマンド形式の機能性が提供される。例えば、外部への呼出し、若しくは外部へのｅメール送信が、サービス・オブジェクト１８３で実行される。サービス・オブジェクト１８３は、通常、単一の種類のメディアと関連付けられている。例えば、電話メディアに対するサービス・オブジェクト１８３があってもよいし、ｅメール・メディアに対する別のサービス・オブジェクト１８３があってもよい。通信サーバ１０９は、デバイス・コマンドを呼出すために、直接的にサービス・オブジェクト１８３とのインタフェースをとる。

通信サーバ１０９は、ドライバ・ハンドルの取得後、RequestService()関数を利用して特定のメディア形式に対するサービス・オブジェクト１８３を要求する。ドライバは、対応するサービス・オブジェクト１８３のハンドルを通信サーバ１０９に返す。次に、通信サーバ１０９は、このハンドルを直接的にInvokeCommand()関数に用いて、対応するサービス・オブジェクト１８３呼出し、特定の種類の機能を実行させる。

通信サーバ１０９は、サービス・オブジェクト１８３のハンドルの取得後、サービス・オブジェクト１８３と対話するのにこのサービス・ハンドルを直接利用する。サービス・オブジェクト１８３は、ドライバ・オブジェクト１８９から機能を継承すること、及び／又はドライバ・オブジェクト１８９とリソースを共有することが可能である。例えば、ドライバ・オブジェクト１８９が、通信チャネル１３０のミドルウェア・サーバへの物理的なTCP／IP接続を確立及び保持することが可能である場合に、サービス・オブジェクト１８３は、その接続をドライバ・オブジェクト１８９と共有することが可能である。

クライアント・オブジェクト１７９は、通信サーバ１０９によってインスタンス生成されて、実行される。クライアント・オブジェクト１７９のハンドルは、サービス・オブジェクト１８３に渡される。サービス・オブジェクト１８３は、このクライアント・ハンドルを利用して、通信サーバ１０９で実行される関数を呼出すことが可能である。

一実施例では、全てのサービス・オブジェクト１８３は、対応するクライアント・オブジェクト１７９を有している。それゆえに、各クライアント・オブジェクト１７９は、その対応するサービス・オブジェクト１８３が利用するメディア形式の知識を有している。サービス・オブジェクト１８３は、種々のメディアに対して、種々のドライバDLLから各々、インスタンス生成されてよいので、この１対１の関係によって、クライアント・オブジェクト１７９が、サービス・オブジェクト１８３から通知を受信した際に、通知を開始するドライバ・オブジェクト１８９及びサービス・オブジェクト１８３を認知することが可能になる。

図１−Ｇは、チャネル・ドライバ１２０によってインスタンス生成されたドライバ・オブジェクト１８９に対するアーキテクチャの一例を示している。ドライバ・オブジェクト１８９によって、ｅメール等の同一メディア形式の３つのサービス・オブジェクト１８３Ａ−１、１８３Ａ−２、及び１８３Ａ−３が生成される。各サービス・オブジェクト１８３Ａ−１、１８３Ａ−２、及び１８３Ａ−３は、自分専用のクライアント・オブジェクト１７９Ａ−１、１７９Ａ−２、及び１７９Ａ−３を各々、有している。

図１−Ｈは、異なるメディア形式に対して３つのサービス・オブジェクト１８３Ａ、１８３Ｂ、及び１８３Ｃを生成するドライバ・オブジェクト１８９に対する代替的なアーキテクチャを示している。各サービス・オブジェクト１８３Ａ、１８３Ｂ、及び１８３Ｃは、対応するメディア形式のイベントを処理するように、自分専用のクライアント・オブジェクト１７９Ａ、１７９Ｂ、１７９Ｃを各々、有している。このアーキテクチャの一例が図１−Ｄに示されており、それは、ファックス・メディアを処理するためのクライアント・オブジェクト１７９Ａ、ｅメール・メディアを処理するためのクライアント・オブジェクト１７９Ｂ、電話メディアを処理するためのクライアント・オブジェクト１７９Ｃを含む着信通信受信機１７０に関するものである。クライアント・オブジェクト１７９Ａ、１７９Ｂ、及び１７９Ｃは、ファックス・サービス・オブジェクト１８３Ａ、ｅメール・サービス・オブジェクト１８３Ｂ、及び電話サービス・オブジェクト１８３Ｃに各々、対応している。

図１−Ｉは、チャネル・ドライバ１２０内でインスタンス生成される２つのドライバ・オブジェクト１８９Ａ、１８９Ｂを示している。各ドライバ・オブジェクト１８９Ａ及び１８９Ｂは、異なるミドルウェア・サーバに対して指定されており、ミドルウェア・サーバに依存したリソースを含んでいる。例えば、ドライバ・オブジェクト１８９Ａが、ミドルウェア・サーバＡへの接続にTCP／IP接続を利用していてもよいし、ドライバ・オブジェクト１８９Ｂが、ミドルウェア・サーバに直接接続されていてもよい。各ドライバ・オブジェクト１８９Ａ、１８９Ｂの下で生成されるサービス・オブジェクト１８３は、ドライバ・オブジェクト１８９Ａ、１８９Ｂが関連しているミドルウェア・サーバに依存する。

ミドルウェア・サーバからドライバ・オブジェクト１８９への非同期イベント通知の実装に関しては、以下を含む複数の代替実施例が存在する。

１．従来式のTCP／IPソケット。ドライバ・オブジェクト１８９は、ミドルウェア・サーバのTCP／IPポートに接続する。イベントは、TCP／IP接続を通して送信される。

２．OLEインタフェース。一例としては、OLEのIAdviseSinkインタフェース。

３．その他の任意のプロセス間通信スキーム。

代替実施例１では、ドライバ・オブジェクト１８９がDLLとして実装可能であるので、ドライバ・オブジェクトDLLによって、イベントが到着するまでselect()の呼出しをブロックするリスニング・スレッド、若しくはイベント到着に関してミドルウェア・サーバを周期的にポーリングするポーリング・スレッドのいずれかが構築される。ポーリング周期は、何秒間若しくは何分間かに及ぶので、ポーリング・スレッドは、優先度の低いメディア形式（例．ｅメール、ファックス等）に対して有効である。ポーリング・スレッドは、電話呼出し等の優先度の高いメディア・イベントを検知するのには有効でない。なぜならば、着信呼出しの到着は、随時、報告されるのが望ましいからである。リスニング・スレッドは、発生するネットワーク・トラフィックがポーリング・スレッドよりも少なく、通常は、優先度の高いメディア及び優先度が低いメディアのいずれに対しても効果的であるが、ミドルウェア・サーバによっては、リスニング・スレッドをサポートしていないことがある。

ポーリング・スレッド及びリスニング・スレッドを共に実行させるには、ドライバ・オブジェクトDLL内に「タスク」スレッドが必要となる。このタスク・スレッドは、図１−Ｊで示されているようなドライバ・オブジェクト１８９、若しくは図１−Ｋで示されているようなサービス・オブジェクト１８３の内部で実行され得る。

図１−Ｊを参照すると、ドライバ・オブジェクト１８９内で実行されるタスク・スレッド（若しくはリッスン・スレッド）は、全てのサービス・オブジェクト１８３によって「共有」されてよい。例えば、このリッスン・スレッドは、全てのサービス・オブジェクト１８３に対する全ての着信イベントをリッスンすることが可能である。一度、リッスン・スレッドがイベントを受信すると、このリッスン・スレッドは、サービス・オブジェクト１８３に実装されているイベント処理関数を呼出して、実行する。

図１−Ｋを参照すると、リッスン・スレッドがサービス・オブジェクト１８３の領域で実行されている場合には、全てのサービス・オブジェクト１８３が自分のリッスン・スレッドを構築しており、リッス・スレッドは共有されていない。リッスン・スレッドの各々は、異なるターゲットをリッスンしている。例えば、ユーザ１に対するリッスン・スレッドが第１内線（内線番号１２３４）上のイベントをリッスンしているのに対して、ユーザ２に対するリッスン・スレッドは第２内線（内線番号５６７８）上のイベントをリッスンしている。

一実施例では、クライアント・オブジェクト１７９は、通信サーバ１０９によって実装されている関数ポインタの集合であり、非同期イベント通知のためにサービス・オブジェクト１８３に渡される。一実施例では、チャネル・ドライバ１２０内のリッスン・スレッドがイベントを受信すると、以下のプロセスが実行される。

１．サービス・オブジェクト１８３が、対応するクライアント・オブジェクト１７９内に実装されているHandleEvent()関数を呼び出す。

２．クライアント・オブジェクト１７９は、このイベントをメモリ・キャッシュにキューイングする。

３．クライアント・オブジェクト１７９は、イベント到着を示すために、通信チャネル・マネージャ１７７に対するサーバ・スレッド１７４（図１−Ｄ参照）を中断するか、若しくは信号を送信する。一度、このプロセスが完了してしまえば、リッスン・スレッドは次のイベントを待つことになる。

４．サーバ・スレッド１７４の次の周期の際に、メイン・スレッドによってメモリ・キャッシュ内に利用可能なイベントが認識される。それにより、メモリ・キャッシュからイベントがデキューされて取出され、プロセスが継続される。

通信APIコマンド
通信API１２５は、クライアント／サーバ・システム１００に組込み得るアプリケーションをサードパーティが開発することを可能にするコマンド及びデータの構造を含んでいる。このデータ構造は、エージェント・キー値要素、キー値パラメータ、及びストリング・パラメータ・リスト等のデータ要素を渡すための配列を含んでいる。

以下は、通信API１２５で利用可能なランタイム・ステータス・フラグの例である：

NOTSUPPORTED = 1; コマンドはサポートされていない
DISABLED = 2; コマンドはこの時点で使用不可能である
CHECKED = 4; コマンドは「チェックされている」状態である。例えば、エージェントが取込み中の状態である場合に、「取込み中」コマンドが「チェックされている」
BLINKING = 8; これは、「応答呼出し」コマンドの点滅（blinking）を可能にする特別な効果のフラグである
NOPARAMSOK = 16; コマンドは実行するのにいずれのパラメータも必要としない
STRPARMSOK = 32; コマンドは不特定のストリング・パラメータを１つ提供することによって実行可能である。そのようなコマンドは、エージェントが通信ツール・バー１０５のエディット・コントロール内に何かをタイプして対応するボタンをクリックすると呼出される。

以下は、通信API１２５の一実施例で利用可能なコマンドの例である：

MediaType：MediaTypeコマンドは、チャネル・ドライバ１２０からメディア形式を提供するために利用される。以下の例のメディア形式ストリングのように、メディア形式のインジケータがCreateISCDriverInstance()関数でチャネル・ドライバ１２０に渡される。

PHONECONTROL = 1
CALLROUTING = 2
EMAIL = 3
FAX = 4
WEBCALL = 5
WEBCHAT = 6

CommandTypeEx：チャネル・ドライバ１２０は、通信サーバ１０９から呼出しを行う、若しくはメッセージを送信する等の種々のサービスを要求するために、このCommandTypeEx関数を用いる。

ObjectType：このObjectType関数は、以下のパラメータ値で示され得る通信オブジェクトのモニタリングに用いられる。

OB_LINK = 1
SWITCH = 2
QUEUE = 3
TELESET = 4
DN = 5
AGENT = 6
CALL = 7
CALLROUT = 8
EMAIL = 9
FAX = 10
WEBCALL = 11
WEBCHAT = 12
OTHERS = 1000

ObjectProperty：この関数ObjectPropertyは、下記のようなモニタリングされる通信オブジェクトの特性を提供するのに用いられる。

ONOFF = 1
AGENTID = 2
NOTREADY = 4
BUSY = 5
DESCRIPTION = 7
TIMEINQUEUE = 9
QUEUEID = 12

チャネル・ドライバ関数
一実施例では、各チャネル・ドライバ１２０内のドライバ・オブジェクト１８９は、以下の関数を含み得る：

FreeSCStrParamListは、最初にチャネル・ドライバ１２０によって割当てられたメモリを解放するために、通信サーバ１０９によって呼出される。

RequestMediaTypeListは、チャネル・ドライバ１２０によってサポートされるメディア形式ストリングのリストを照会するために、通信サーバ１０９によって呼出される。それはメディア形式ストリングのリストであるmediaTypleListパラメータを含んでいてよい。

FreeSCStrParamListは、メモリを解放するために、通信サーバ１０９によって呼出される。

RequestCommandEventListは、チャネル・ドライバ１２０によってサポートされている特定のメディア形式に対して実行されるコマンド及びイベントのリストを生成するために呼出される。パラメータには、メディア形式を特定する入力パラメータ、及びコマンド及びイベントのリストを含む出力パラメータが含まれる。

CreateISCDriverInstanceは、チャネル・ドライバ１２０を生成するために呼出される。以下のパラメータが利用されてよい。

mediaTypeStr：特定のドライバの実装によって定義されるメディア・ストリング
languageCode：言語ストリング。例えば、英語は「ENU」、フランス語は「FRA」、ドイツ語は「DEU」、ブラジル系ポルトガル語は「Portuguese-Brazilian」、スペイン語は「ESN」、イタリア語は「ITA」、及び日本語は「JPN」。

connectString：チャネル・ドライバ１２０に対する接続ストリング
datasetParams：構成（コンフィギュレーション）から収集されるパラメータ・リスト
handle：チャネル・ドライバ１２０によって返されるチャネル・ドライバ１２０のハンドル
RequestServiceは、チャネル・ドライバ１２０からサービス・オブジェクト１８３を要求する。以下のパラメータが利用されてよい。

clntInterface：クライアント・オブジェクト１７９でのインタフェース
connectString：サービス・オブジェクト１８３に対する接続ストリング
datasetParams：構成（コンフィギュレーション）に基づいて収集されるパラメータ・リスト
serviceHandle：ドライバ１２０によって返されるサービス・オブジェクト１８３のハンドル
ReleaseISCDriverInstanceは、パラメータとして供給されるドライバ・ハンドルで特定されるドライバ・オブジェクト１８９を解放するために、通信サーバ１０９によって呼出される。

サービス・オブジェクト関数
一実施例では、各チャネル・ドライバ１２０内のサービス・オブジェクト１８３は、以下の関数を含み得る：

ReleaseISCServiceInstanceは、サービス・オブジェクト・ハンドルを解放するために呼出される。

NotifyEventHandlingFinishedは、イベント処理が完了したこと、及びドライバ・オブジェクト１８９によるプロセスの移動若しくは継続が可能であることをドライバ・オブジェクト１８９に通知するために、通信サーバ１０９によって呼出される。この関数は、HandleEventのnotifyWhenDoneパラメータに応答するのに呼出される。以下のパラメータが利用されてよい。

Handle：サービス・オブジェクト１８３の識別子
trackingID：通信サーバ１０９がイベント処理を行っていたワーク・アイテムに対する識別子
result：チャネル・ドライバ１２０によってサポートされるメディア形式ストリングのリストのイベント処理照会の結果
InvokeCommandは、ドライバ・コマンドを呼出すために通信サーバ１０９によって呼出される。以下のパラメータ・リストが利用されてよい。

Handle：サービス・オブジェクトの識別子
clntCmdTrackID：InvokeCommand要求に対する固有のID
name：呼出すためのコマンド名
stringParam：ツール・バー１０５上の「Phone#」エディット・ボックスからのストリング
datasetParam：構成（コンフィギュレーション）に基づいて収集されたパラメータ・リスト
InvokeCommandExは、所定の種類のコマンドを呼出すために通信サーバ１０９によって呼出される。以下のパラメータ・リストが利用されてよい。

Handle：サービス・オブジェクトの識別子
clntCmdTrackID：このInvokeCommand要求に対して通信サーバ１０９によって決定される固有のID
commandType：通信サーバ１０９が実行を望んでいるコマンドの種類
datasetParam：通信サーバ１０９によって設定されている所定のパラメータ・リスト・セット
ReleaseWorkItemは、ワーク・アイテムの解放を要求するために、通信サーバ１０９によって呼出される。パラメータには、以下のものが含まれてよい。

Handle：サービス・オブジェクトの識別子
TrackingID：ワーク・アイテムの識別子
SuspendWorkItemは、ワーク・アイテムを保留するようにサービス・オブジェクト１８３に要求するために、通信サーバ１０９によって呼出される。パラメータには、以下のものが含まれてよい。

Handle：サービス・オブジェクト１８３の識別子
TrackingID：ワーク・アイテムの識別子
ResumeWorkItemは、ワーク・アイテムを再開するようにサービス・オブジェクト１８３に要求するために、通信サーバ１０９によって呼出される。パラメータには、以下のものが含まれてよい。

Handle：サービス・オブジェクト１８３の識別子
TrackingID：ワーク・アイテムの識別子
HandleQueuedEventは、UQシステム１０２内に予めキューイングされているイベントを処理のためにサービス・オブジェクト１８３に渡すために、通信サーバ１０９によって呼出される。チャネル・ドライバ１２０は、これをミドルウェア・サーバからの入力メディア・イベントとして処理することが可能である。パラメータには、以下のものが含まれてよい。

Handle：サービス・オブジェクトの識別子
name：イベント名（元のHandleEvent()呼出しから）
field：イベント属性リスト（元のHandleEvent()呼出しから）
trackingID：メディア・アイテムに対する固有のID
CancelQueuedEventは、メディア・イベントがUQシステム１０２によって取消し、解放、若しくは転送されたことをチャネル・ドライバ１２０に通知するために、通信サーバ１０９によって呼出される。この関数は、HandleQueuedEvent()の関連関数である。以下のパラメータが利用されてよい。

Handle：サービス・オブジェクトの識別子
name：イベント名（元のHandleEvent()呼出しから）
trackingID：メディア・アイテムに対する固有のID

クライアント・オブジェクト関数
以下は、クライアント・オブジェクト１７９に含まれ得る関数の例である。これらの関数へのインタフェースは、ドライバ・オブジェクト１８９を通信サーバ１０９内のいずれのライブラリにもリンクする必要がないように、関数ポインタを用いて実装されてよい。

ReleaseClientInstanceは、クライアント・オブジェクト１８９に、クライアント・オブジェクトのハンドルの解放をさせる。

BeginBatch及びEndbatchは、ネットワーク・オーバヘッドを節約するように設計されている。BeginBatch及びEndBatchの間に呼出された関数は、キャッシュされて、EndBatch呼出しで送出することが可能である。これらの２つの関数は、ドライバ・オブジェクト１８９が自己の判断で利用することが可能である。例えば、
BeginBatch_Helper(clientInterface)；
CacheCommandInformation_Helper(clientInterface,...)；←キャッシュされる
；；；／／何らかの処理
if(error)
HandleError_Helper(clientInterface,...)；←キャッシュされる
HandleEvent_Helper(clientInterface,...)；←キャッシュされる
EndBatch_Helper(clientInterface,...)；←全ての要求が１つの要求で送出される
＊／
HandleEventは、所定のフィールドを用いて、チャネル・ドライバ１２０から受信した名前の付けられているイベントを処理するのに利用される。このメソッドを呼出すことによって、チャネル・ドライバ１２０は、モニタリングしているテレセット上に呼出しが生じた等のイベントを、クライアント・オブジェクト１７９に通知する。以下は、パラメータ・リストである。

Handle：サービス・オブジェクト１８３の識別子
name：イベント名
fields：イベント属性リスト
notifyWhenDone：TRUEに設定されている場合、イベント処理が行われるとすぐに、ドライバ１２０への通知のためにクライアント・オブジェクト１７９によってnotifyEventHandlingFinished()が呼出される。

trackingID：例えば、呼出しID、ｅメールID、若しくはwebチャット・セッションID等の、このイベントが関連するワーク・アイテムを一意的に識別するID
ShowStatusTextは、クライアント・オブジェクト１７９のステータス・ラインにテキスト形式のステータス情報を表示する。以下のパラメータ・リストが利用されてよい。

Handle：サービス・オブジェクト１８３の識別子
text：クライアントのステータス・バーに表示されるテキスト
HandleErrorは、非同期のエラーを処理して、それらをエラー・ログファイルに記録する。以下のパラメータが利用されてよい。

Handle：サービス・オブジェクト１８３の識別子
clntCmdTrackID：０でない場合、InvokeCommand()の要求によって生じたエラーをそのまま反映するように、InvokeCommand()に渡されるのと同じ「clntCmdTrackID」の値である。０である場合には、原因不明（out of context）のエラーが生じている。

error：エラー・テキスト
CacheCommandInformationは、クライアント・オブジェクト１７９にコマンド・ステータス・キャッシングに関する通知を行うのに用いられる。以下のパラメータが利用されてよい。

commandNames：コマンド名のリスト
commandDescriptions：各コマンドに対する説明テキストのリスト
commandStatuses：各コマンドに対するステータス（CommandFlag）のリスト
UpdateObjectInformationは、クライアント・オブジェクト１７９にオブジェクトのステータス変更に関する通知を行うのに用いられる。以下のパラメータが利用されてよい。

trackingID：この情報更新を生じさせた呼出しを一意的に識別するID
objectType：列挙されたObjectType値
objectID：このオブジェクトに対する固有のID。電話の場合は内線。ｅメールの場合はメール・ボックス。ファックスの場合はファックス番号。

datasetInfo：更新するためのObjectProperty値のリスト。例えば、リスト｛｛"4", "TRUE"｝, ｛"9", "33"｝｝は、ISNOTREADYの値がTRUEであり、TIMEINQUEUEの値が３３秒であることを示している。

IndicateNewWorkItemは、ドライバ若しくはミドルウェアがワーク・アイテムIDの変更機能をサポートしている場合に、クライアント・オブジェクト１７９に、新規の着信ワーク・アイテム（例えば、呼出し、ｅメール、若しくはファックス）に関する通知を行う。以下のパラメータが利用されてよい。

trackingID：新規のワーク・アイテムを特定するための固有のID
oldTrackingID：旧IDを特定するためのID
WorkItemStartedは、エージェントが１つの特定のワーク・アイテムに対して作業を開始したことをクライアント・オブジェクト１７９に通知する。これは、（１）エージェントが呼出しに応答して、その呼出しが接続された場合、若しくは（２）エージェントがｅメール／ファックスのワーク・アイテムを受信した場合に発生する。それに応じて、クライアント・オブジェクト１７９が「trackingID」によって識別されるワーク・アイテムをアクティブなワーク・アイテムとして設定して、このワーク・アイテムのトラッキングを開始する。エージェントは、話し中若しくは作業中として扱われる。この作業の開始時間が、クライアント・オブジェクト１７９によって記録されてよい。以下のパラメータが利用されてよい。

trackingID：このワーク・アイテムを特定するための固有のID
oldTrackingID：関数IndicateNewWorkItem()の説明を参照されたい。

objectType：オブジェクトの種類
objectID：このワーク・アイテムに対するメディア・オブジェクト。電話の場合には、内線。ｅメールの場合には、メール・ボックス。

description：ワーク・アイテムの説明。実装ドライバは、ワーク・アイテムの説明を変更するのにUpdateObjectInformationを利用することが可能である
startTime：ワーク・アイテムが開始された時間
WorkItemReleasedは、特定のワーク・アイテムが解放されたことをクライアント・オブジェクト１７９に通知する。これは、（１）エージェントが呼出しを解放して、呼出しの接続が切られた場合、若しくは（２）エージェントがｅメール／ファックスのワーク・アイテムを完了した場合に発生する。それに応じて、クライアント・オブジェクト１７９は、このワーク・アイテムのトラッキングを停止して、このワーク・アイテムを除去する。以下のパラメータが利用されてもよい。

trackingID：解放されたワーク・アイテムを特定するための固有のID
stopTime：ワーク・アイテムが解放／停止された時間
CleanAllWorkItemsは、記憶されている全てのワーク・アイテムを除去する必要があることをクライアント・オブジェクト１７９に通知する。

WorkItemSuspendedは、ワーク・アイテムが保留されたことをクライアント・オブジェクト１７９に通知する。これは、例えば、（１）エージェントが呼出しを保留にした場合、若しくは（２）エージェントがｅメール／ファックスのワーク・アイテムを保留にした場合に発生する。実装ドライバは、保留が実行された際にこの関数を呼出す。それに応じて、クライアント・オブジェクト１７９は、この特定のワーク・アイテムの状況（context）を保存する。ワーク・アイテムを特定するために、trackingIDのパラメータが用いられてもよい。

WorkItemResumedは、保留されていたワーク・アイテムが再開されたことをクライアント・オブジェクト１７９に通知する。これは、例えば、（１）エージェントが保留を解除して呼出しが再開された場合、若しくは（２）エージェントがｅメール／ファックスのワーク・アイテムを再開した場合に発生する。ドライバ・オブジェクト１８９は、再開が完了した際に、この関数を呼出す。それに応じて、クライアント・オブジェクト１７９によって、作業状況（スクリーン＋worktrackingオブジェクト）が復旧されて、アクティブなワーク・アイテムに「trackingID」によって識別されるワーク・アイテムが設定される。trackingIDのパラメータは、ワーク・アイテムを特定するのに利用されてもよい。

本明細書でリストにされている関数の代わりに、若しくは付加的に、通信API１２５の中に別の関数及びパラメータが含まれてよいことに留意されたい。

図３は、通信サーバ１０９によるコマンド及びイベントの処理を示している。上述のように、セッション・モード通信サーバ１１０は、ワーク・アイテムの処理のためにエージェントに提供されているユーザ・インタフェースの制御を行っており、図３に示されているセッション・モード通信サーバ１１０は、webブラウザ・クライアント１０４と対話している。ユーザ・インタフェースは、異なるメディア形式から成る複数の通信チャネルを利用する通信に対しても整合性（consistent）がとれている。セッション・モード通信サーバ１１０によるイベント処理に関する以下の説明は、要求モード通信サーバ１４０及び着信通信受信機１７０に対しても適用可能である。

エージェントは、ユーザ・インタフェースのログイン・オブジェクト等のユーザ・インタフェース・オブジェクトを作動させることによって、クライアント／サーバ・システム１００にログインして、それにより、彼若しくは彼女が、顧客サポート要求に対してサポートの提供を開始可能であるということが示される。エージェントは、自分が関連付けられている顧客サポート・センタ構成に関連付けられた任意の通信チャネル１３０にログインすることが可能である。ログイン時に、webブラウザ・クライアント１０４Ａによって、図１−Ｂに示されているように、アプリケーション・サーバ１２６の中間構成要素（矢印に途切れを入れて示しているように、ここでは省略されている）を通して通信しているセッション・モード通信サーバ１１０に接続コマンドが送信される。

接続コマンドの結果として、ツール・バー１０５とセッション・モード通信サーバ１１０との間にセッションが確立される。このセッション接続によって、セッション・モード通信サーバ１１０は、通信チャネル１３０からツール・バー１０５に情報を転送することが可能にされる。通信チャネルが、生のweb連携セッション等のように、エージェントと顧客とがインタラクティブに通信できるものである場合、チャネル・ドライバ１２０は、通信チャネル１３０内に持続的な接続を保持を引受けている。

チャネル・ドライバ１２０は、通信サーバ１０９との通信のために、通信APIに従って実装されている。通信API１２５は、図１−Ａ乃至図１−Ｋに対して上記で説明がなされたように、通信サーバ１０９との通信のために、特定の通信チャネル１３０に対するベンダ提供のチャネル・ドライバ１２０に、所定の関数及びデータ構造が実装されることを必要とする。

通信API１２５の要件の１つには、通信サーバ１０９との通信のために、ドライバ・オブジェクト及びサービス・オブジェクトを生成するための命令がチャネル・ドライバ１２０によって提供されなければならないというのがある。このドライバ・オブジェクトは、通信チャネル１３０のメディア形式に依存する。ドライバ・オブジェクトによって、図１−Ｄにおける、ｅメール通信チャネル１３０Ｇに対するｅメール・サービス・オブジェクト１８３Ｂ、及びファックス通信チャネル１３０Ｈに対するファックス・サービス・オブジェクト１８３Ａ等のように、通信チャネル１３０に対するサービス・オブジェクトが生成される。

図１−Ｊ乃至図１−Ｋに関して上述されたように、チャネル・ドライバ１２０によって、通信チャネル１３０の通信動作がモニタリングされる。図１−Ｊでは、ドライバ・オブジェクト１８９が通信チャネル１３０をリッスンしており、図１−Ｋでは、サービス・オブジェクト１８３Ａ及び１８３Ｂがリッスンしている。このリッスン動作がドライバ・オブジェクト１８９を介して実行されるか、若しくはサービス・オブジェクト１８３を介して実行されるかは、チャネル・ドライバ１２０を開発するベンダによって決定される。

サービス・オブジェクト１８３は、１以上の通信チャネル１３０と通信するためのハンドシェーキング等の機能性と、通信チャネル１３０のハードウェア・デバイス及び／又はソフトウェア要素にコマンドを送信し、且つそこからイベントを受信するためのプロトコルとを実装している。

エージェントのログインに応じて、セッション・モード通信サーバ１１０によって、エージェントが利用するクライアント１０４が属する構成に関する全てのチャネル・ドライバ１２０がロードされる。次に、セッション・モード通信サーバ１１０のリッスン・スレッドは、webブラウザ・クライアント１０４Ａに対するリッスンを行い、チャネル・ドライバ・ドライバ・オブジェクト１８９若しくはサーバ・オブジェクト１８３は、チャネル・ドライバ１２０からの通信チャネル１３０の動作（activity）を示すイベントに対するリッスンを行う。

エージェントがツール・バー１０５上のユーザ・インタフェース・オブジェクトを作動させる（例えば、ワーク・アイテム受諾ボタンをクリックする等によって）と、ユーザ・インタフェース・オブジェクトのInvokeCommand関数が作動されて、それにより、セッション・モード通信サーバ１１０に発行されるコマンド名が送信される。セッション・モード通信サーバ１１０は、顧客サポート・センタ・データベース３３０への照会にユーザ・インタフェース・オブジェクトから受信したコマンド名を用いて、コマンドを発行するためのチャネル・ドライバ１２０を決定する。コマンド・テーブルCMD（図２−ｒ参照）、チャネル・ドライバ・テーブルCNCTR（図２−ａ参照）、及び構成テーブルCFG（図２−ｎ参照）は、コマンドに関連付けられているチャネル・ドライバ１２０を決定するために、セッション・モード通信サーバ１１０によって用いられ得るテーブルの例である。セッション・モード通信サーバ１１０は、CMD_PARAM（図２−ｓ参照）等のコマンド・パラメータ・テーブルからコマンドに必要なパラメータを取得して、サービス・オブジェクト１８３を利用してチャネル・ドライバ１２０にコマンド及びそれらのパラメータを提供する。チャネル・ドライバ１２０は、通信チャネル１３０にコマンドを発行する。

チャネル・ドライバ１２０からイベントが受信すると、セッション・モード通信サーバ１１０は、顧客サポート・センタ・データベース３３０を照会することによって、その通信サーバ１３０に対するイベントを発したチャネル・ドライバ１２０を決定する。複数のテーブルがある中でもチャネル・ドライバ・テーブルCNCTR（図２−ａ参照）、イベント・テーブルEVT（図２−ｔ参照）、及び構成テーブルCFG（図２−ｎ参照）等のテーブルが、チャネル・ドライバ１２０を特定するのに用いられる。

イベントを発生させたチャネル・ドライバ１２０が特定されると、セッション・モード通信サーバ１１０は、実行されるイベント応答を決定する。このイベント応答は、Javaアプレット１１６により指示されるwebブラウザ・クライアントを介して提供されるデータ・ウィンドウ形式であってもよい。他の種類のイベント応答には、エージェントが顧客に聞くための質問が表示されているダイアログの提示、動作を実行するためのソフトウェアの実行、UQビジネス・サービス１０６等のシステムのサーバ構成要素のビジネス・サービスの呼出し、及び顧客サポート・センタ・データベース３３０へのデータベース・レコードの生成が含まれる。１つのイベント応答は１つのイベントに対応している。イベント応答は、構成ユーザ・インタフェース３４０を用いて管理者により設定可能であり、EVTRESP（図２−ｙ参照）等のイベント応答テーブルに記憶される。更に、セッション・モード通信サーバ１１０は、トラッキングを目的として、EVT_LOG（図２−ａａ参照）等のイベント・ログ・テーブルにイベント応答を記録する。

通信サーバ１０９は、クライアントを介したエージェントへの情報提示を制御するように、顧客サポート・センタ・データベースからの構成データ３３２を利用する。例えば、クライアントによって表示されるツール・バーの外観は、構成データ３３２に従って決定される。出現するボタン、エージェントが各ボタンをクリックした際に呼出されるコマンド、及び入力イベントがトリガとなって生じる応答は、全て、構成データ３３２の一部として管理者によって構成ユーザ・インタフェース３４０を用いて指定される。

図４は、顧客とエージェントとの間のweb連携セッションを確立するための、クライアント／サーバ・システム１００の構成要素の動作の一例を示している。ステップ１では、顧客がエージェントとのライブweb連携セッションを要求している。Web連携ドライバ１２０Ｇは、ステップ２でWebCollabArrivedイベントを生成して、このWebCollabArrivedイベントをステップ３で示されるように、セッション・モード通信サーバ１１０に送信する。ステップ４でセッション・モード通信受信機１１０がWebCollabArrivedイベントを受信して、ステップ５で適切なイベント応答を決定する。イベント応答を決定するために、このイベントを発生させたチャネル・ドライバが、顧客サポート・センタ・データベース３３０の照会（クエリは図示せず）によって、上述のように決定される。この場合には、ステップ６で示されるようにイベント応答は通知関数の実行であり、それにより、ステップ７で示されるようにwebブラウザ・クライアントを介してエージェントへの通知が提供される。通知の一例としては、ツール・バー上のボタンを点滅させること、及び／又は顧客及びweb連携要求に関する情報を備えたデータ・ウィンドウを提供することである。

ステップ８で、エージェントは、ツール・バー１０５のワーク・アイテムオブジェクト等のユーザ・インタフェース・オブジェクトを、ワーク・アイテム受入れボタンをクリックする等してアクティブにすることによって、web連携要求を受入れる。ワーク・アイテムオブジェクトは、コマンドと関連付けられており（ここでは、AcceptWebCollabコマンド）、そのコマンドは、ステップ９でセッション・モード通信サーバ１１０に送信される。セッション・モード通信サーバ１１０は、ステップ１０で示されるように、web連携ドライバ１２０ＧにAcceptWebCollabコマンドを送信して、このweb連携ドライバ１２０Ｇは、ステップ１１で示されるように、AcceptWebCollabコマンドを実行する。この場合には、web連携ドライバ１２０Ｇによって、webサーバ１３０Ｉとwebブラウザ・クライアント１０４との間にweb連携接続４５０が動的に確立される。

ステップ１２で、web連携ドライバ１２０Ｇは、WebCollabStartedイベントを生成して、ステップ１３で、このWebCollabStartedイベントをセッション・モード通信サーバ１１０に送信する。ステップ１４で、セッション・モード通信サーバ１１０は、WebCollabStartedイベントを受信して、ステップ１５で適切なイベント応答を決定する。この場合には、イベント応答は、ステップ１６で示されるように、レコードを生成して、それを顧客サポート・センタ・データベース３３０に記憶することである。web連携セッションが完了すると、web連携ドライバ１２０Ｇは、適切なイベントを生成して、それらをセッション・モード通信サーバ１１０に送信する。セッション・モード通信サーバは、適切なイベント応答を決定してそのイベント応答を実行する。

図５は、入力電話呼出しをエージェントに割当てて、その電話呼出しを割当てエージェントにルーティングするように、図１の汎用キューイング・システムを利用しているクライアント／サーバ・システム１００の構成要素の動作の一例を示している。ステップ１で、顧客は、顧客サポート要求の提出のために1−800−会社電話番号を呼出している。呼出しが到着すると、ACDスイッチ・ドライバ１２０Ｄは、着信電話呼出しを検知して、CallArrivedイベントを生成する。ACDスイッチ１３０Ｅは、呼出しの自動的なルーティングが可能であるが、この例では、呼出しのルーティングにACDスイッチ・ドライバ１３０Ｅのハードウェア能力を利用するのではなく、むしろ着信通信受信機１７０がエージェントの自動割当てを可能にするように構成されている。

着信通信受信機１７０は、1−800−会社電話番号を含めた特定の電話番号をモニタしている。ステップ４で着信通信受信機１７０がCallArrivedイベントを受信すると、着信通信受信機１７０は、ステップ５に示されるように、発信元チャネル・ドライバ１２０Ｄを決定して、ステップ６でイベント応答を決定する。この場合には、ステップ７で示されるように、イベント応答はｅ−スクリプトの実行である。この例では、ｅ−スクリプトは、ステップ７ａでエージェント割当てを要求して、AgentAssignedメッセージが到着すると、発信元チャネル・ドライバにRouteCallコマンドを送信する（ステップ７ｂ）。ステップ８で、エージェント割当て要求がUQシステム１０２に提出されて、ステップ９で、UQシステム１０２によってエージェントの割当てが行われる。ステップ１０で、UQシステム１０２は、上述のように、着信通信受信機１７０にAgentAssignedメッセージを送信する。２つの構成要素間の矢印の線に途切れが入れて示されているように、着信通信受信機１７０とUQシステム１０２との間にあるシステム１００の複数の構成要素が図面から省かれていることに留意されたい。

着信通信受信機１７０は、ステップ１１でAgentAssignedメッセージを受信して、続くｅ−スクリプトのステップ７ｂでACDスイッチ・ドライバ１２０ＤにRouteCallコマンドを送信する。ステップ１３で、ACDスイッチ・ドライバ１２０Ｄは、TransferCallコマンドを実行して、エージェントに呼出しを転送する。ステップ１４で、エージェントの電話が鳴る。ステップ１５で、ACDスイッチ・ドライバ１２０Ｄによって、エージェントの電話端末が鳴っていることが検知されて、CallRingingイベントが生成される。ステップ１６で、ACDスイッチ・ドライバ１２０Ｄは、このCallRingingイベントを、着信電話呼出しのエージェントへの通知を処理するセッション・モード通信サーバ１１０に送信する。

ステップ１７で、セッション・モード通信サーバ１１０が、（この場合には、通知機能を実行するための）適切な応答を決定して、ステップ１８で、ツール・バー１０５に通知が送信される。ステップ１９で、ツール・バー１０５がエージェントに着信呼出しを通知して、ステップ２０で、エージェントは、ワーク・アイテム受入れオブジェクトをアクティブにすることによって、この呼出しを受諾する。ステップ２１で、セッション・モード通信サーバ１１０にAcceptCallコマンドが送信されて、ステップ２２で示されるように、セッション・モード通信サーバ１１０によって、このAcceptCallコマンドがACDスイッチ・ドライバ１２０Ｄに送信される。ステップ２３で、ACDスイッチ・ドライバ１２０Ｄは、呼出しの顧客と割当てエージェントとを接続させるように、AcceptCallコマンドを実行する。エージェントがログインしている限り、ACDスイッチ・ドライバ１２０Ｄによって、イベントの生成が継続され、且つセッション・モード通信サーバ１１０によって、イベント応答の実行が継続される。

エージェントがツール・バー１０５上のワーク・アイテム受入れオブジェクトをクリックせずに、代わりに送受話器を持上げた場合には、AcceptCallコマンドは生成されない。その代わりに、ACDスイッチ・ドライバ１２０Ｄが、ACDスイッチ１３０Ｅへのリッスンにより呼出しが接続されたことを検知する。そのような場合には、ACDスイッチ・ドライバ１２０ＤによってCallConnectedイベントが生成されて、セッション・モード通信サーバ１１０によって適切なイベント応答が実行される。

ｅメール／ファックス・サーバに対するチャネル・ドライバ１２０によって実行されるコマンドの一例は、以下の表１で提供される。

ｅメール／ファックス・サーバに対するチャネル・ドライバ１２０によって提供されるイベントの一例は、以下の表２で提供される。

本明細書で説明されているように、複数チャネルのメディア非依存型サーバによって、異なるメディア形式から成る複数の通信チャネルを介して、エージェントの入力受信及び出力送信が可能になる等の多数の利点が提供される。顧客サポート要求は、ユーザ・インタフェースを介して受信及び提示がされる。エージェントはこの情報を利用して、アクティブなワーク・アイテムの管理、ワーク・アイテムの受取り、ワーク・アイテムの解放、ワーク・アイテムの保留、及びワーク・アイテムの再開を行う。

（別実施例）
本発明は、１以上のコンピュータ・システム上で実行されるソフトウェア・アプリケーションに関連して説明がされてきた。しかしながら、当業者は、本発明が種々の形態のプログラム製品として配布され得るものであり、本発明が、実際に配布を実行するのに用いられる特定の種類の単一ベアリング・メディアとは無関係に、等しく適用可能であることを理解するであろう。単一ベアリング・メディアの例には、フロッピーディスク（フロッピー（登録商標））及びCD−ROM等の記録可能なメディア、及びデジタル及びアナログ通信リンク等の転送メディア、並びに将来的に開発されるメディア・ストレージ・システム及び配布システムが含まれる。

更に、前記の詳述では、本発明の種々の実施例がブロック図、フローチャート、及び実例を用いて示されている。当業者は、多種多様なハードウェア、ソフトウェア、ファームウェア、若しくはそれらの任意の組合わせを用いて、ブロック図、フローチャートのステップ、実例を用いて図示されている動作及び／又は要素の各々が、個々に、且つ／又は集団で実行され得ることを理解するであろう。一実施例では、本発明は、特定用途向け集積回路（ASIC）を用いて実行され得る。しかしながら、当業者は、本明細書で開示されている実施例は、その全体若しくは一部が、コンピュータ上で実行されるコンピュータ・プログラムとして、ファームウェアとして、若しくは実質的にそれらを任意に組合わせたものとして、従来式の集積回路に対しても同等に実装され得ることを理解するであろう。この開示を考慮した、回路の設計及び／又はソフトウェア若しくはファームウェアに対するプログラミング・コードの記述は、当業者には明らかであろう。

本発明は、説明された利点及び本発明に固有なその他の点を達成するようによく適合されている。本発明は、本発明の特定の実施例を参照して描写され、説明され、且つ規定されてきたが、そのような参照は、本発明の制限を意図したものではなく、且つそのような制限は推察されていない。本発明は、形態及び機能において、当業者が想定し得る種々の修正、変更、及び同等物が実施可能である。描写及び説明がされている実施例は、例示だけが目的であり、本発明の範囲を完全に網羅しているわけではない。従って、本発明は、付随の請求項の精神及び範囲だけで制限されるものであり、それにより、あらゆる点で同等物に完全な認識範囲が提供されている。

図１−Ａは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。図１−Ｂは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。図１−Ｃは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。図１−Ｄは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。図１−Ｅは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの別実施例の線図である。図１−Ｆは、通信アプリケーション・プログラミング・インターフェースの実装において含まれる構成要素の線図である。図１−Ｇは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。図１−Ｈは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。図１−Ｉは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。図１−Ｊは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。図１−Ｋは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。図２は、図１−Ａ乃至図１−Ｋのシステムに対するデータベース・スキーマの一例である。図２−ａは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｂは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｃは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｄは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｅは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｆは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｇは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｈは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｉは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｊは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｋは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｌは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｍは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｎは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｏは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｐは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｑは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｒは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｓは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｔは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｕは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｖは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｗは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｘは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｙは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｚは、図２でのテーブル名に対応するテーブルの例を示している。図２−ａａは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｂｂは、図２でのテーブル名に対応するテーブルの例を示している。図２−ｃｃは、図２でのテーブル名に対応するテーブルの例を示している。図３は、図１−Ａ乃至図１−Ｋのシステムによるコマンド及びイベントの処理が示されているブロック図である。図４は、顧客とエージェントとの間のweb共同セッションを確立するための、図１−Ａ乃至図１−Ｋのシステムの構成要素の動作の一例である。図５は、汎用キュー・システムの構成要素を利用してエージェントに着信電話呼出を割当て、ユーザ・インターフェースを介して割当エージェントへの通知を行い、更に、割当エージェントへの電話呼出のルーティングを行う図１−Ａ乃至図１−Ｋのシステムの構成要素の動作の一例である。

Claims

通信チャネルと通信するための通信サーバを有する装置であって、
前記通信サーバは、前記通信チャネルから、前記通信チャネルに通信可能に結合されたチャネル・ドライバを介して入力通信を受信して、前記チャネル・ドライバを介して前記通信チャネルに送信される出力通信を生じさせるように、動作可能であり、
更に、前記通信サーバは、前記チャネル・ドライバを介して前記通信チャネルと通信するように構成され、前記通信チャネルのメディア形式とは無関係に通信動作が可能であり、
前記チャネル・ドライバは、前記通信チャネルと通信可能となるように前記通信チャネルの前記メディア形式に対応可能であり、
前記通信チャネルの前記メディア形式は、複数のメディア形式のうちの１つのメディア形式であることを特徴とする装置。
更に、
前記チャネル・ドライバは、前記通信チャネルから前記入力通信を受信したときにイベントを提供して、前記通信チャネルに前記出力通信のコマンドを発行するように、動作可能であり、
前記入力通信を受信するように動作可能な前記通信サーバは、前記チャネル・ドライバによって提供される前記イベントを取得するように動作可能である前記通信サーバを更に有し、
送信される前記出力通信を生じさせるように動作可能な前記通信サーバは、前記チャネル・ドライバにコマンドを発行させるように動作可能な前記通信サーバを更に有することを特徴とする請求項１に記載の装置。
更に、
アクティブにされるように動作可能なユーザ・インタフェース・オブジェクトを有するユーザ・インタフェースを有し、
前記通信サーバは、前記ユーザ・インタフェース・オブジェクトがアクティブ化されるのに応じて、前記チャネル・ドライバに前記コマンドを発行させるように動作可能であることを特徴とする請求項２に記載の装置。
更に、
前記通信サーバは、前記ユーザ・インタフェース・オブジェクトのアクティブ化を受信するように動作可能であることを特徴とする請求項３に記載の装置。
更に、
前記通信サーバは、前記ユーザ・インタフェースを介して前記イベントの通知を提供するように動作可能であることを特徴とする請求項３に記載の装置。
更に、
前記通信サーバは、前記イベントが通知されるエージェントを決定して、前記ユーザ・インターフェースを介して前記エージェントに前記イベントの通知を提供するように動作可能であることを特徴とする請求項３に記載の装置。
更に、
前記ユーザ・インタフェースと前記通信チャネルとの間に接続を有する請求項３に記載の装置。
前記接続は、
前記ユーザ・インタフェースと前記通信サーバとの間の第１副接続と、
前記通信サーバと前記チャネル・ドライバとの間の第２副接続と、
前記チャネル・ドライバと前記通信チャネルとの間の第３副接続とを有し、
前記通信サーバは、更に、前記第１及び第２の副接続を用いて、前記チャネル・ドライバに前記コマンドを発行させるように動作可能であり、
前記チャネル・ドライバは、更に、前記第３副接続を用いて、前記コマンドを発行させるように動作可能であることを特徴とする請求項７に記載の装置。
更に、データベースを有し、
該データベースは、
前記イベントに関する情報を有するイベント・テーブルと、
前記コマンドに関する情報を有するコマンド・テーブルと、
前記ユーザ・インタフェース・オブジェクトに関する情報を有するユーザ・インタフェース・オブジェクト・テーブルとを有することを特徴とする請求項１に記載の装置。
前記イベントを処理するように動作可能な前記通信サーバは、更に、前記イベント・テーブルにアクセスするように動作可能であり、
前記チャネル・ドライバに前記コマンドを発行させるように動作可能な前記通信サーバは、更に、前記コマンド・テーブル及び前記ユーザ・インタフェース・オブジェクト・テーブルにアクセスして、前記チャネル・ドライバに前記コマンドを発行させるように動作可能であり、
前記コマンド・テーブル内のコマンド・データ、及び前記ユーザ・インタフェース・オブジェクト・テーブル内のユーザ・インタフェース・オブジェクト・データは、前記コマンドを発行するように、命令を発行するために用いられることを特徴とする請求項９に記載の装置。
前記通信サーバは、更に、前記チャネル・ドライバによって提供される前記イベントを取得して、イベント応答を実行するように動作可能であり、
前記データベースは、更に、前記イベントの取得に応じて実行される前記イベント応答に関する情報を含んでいるイベント応答テーブルを有することを特徴とする請求項９に記載の装置。
前記通信サーバは、更に、前記ユーザ・インタフェースを用いてエージェントに対する構成を決定するように動作可能であり、
前記データベースは、更に、前記エージェントが属する前記構成に関する情報を含んでいるエージェント構成テーブルを有することを特徴とする請求項９に記載の装置。
前記データベースは、更に、
前記構成に関する情報を含む構成テーブルと、
前記エージェントに関する情報を含むエージェント・テーブルとを有することを特徴とする請求項１２に記載の装置。
前記通信チャネルは、複数の通信チャネルのうちの１つの通信チャネルであり、
前記チャネル・ドライバは、複数のチャネル・ドライバのうちの１つのチャネル・ドライバであり、
前記通信チャネルの各通信チャネルは、前記チャネル・ドライバのうちの対応するチャネル・ドライバと関連付けられていることを特徴とする請求項２に記載の装置。
通信チャネルと通信するための通信サーバを有する装置が、前記通信チャネルを用いて通信するための方法であって、
前記通信サーバに、前記通信チャネルから、前記通信チャネルに通信可能に結合されたチャネル・ドライバを介して、イベントを受信させるステップと、
前記チャネル・ドライバを介して前記通信チャネルと通信するように構成された前記通信サーバに、前記イベントの通知を、ユーザ・インタフェースを介して提供させるステップとを有し、
前記通信サーバは、前記チャネル・ドライバを介して前記通信チャネルと通信するように構成され、前記通信チャネルのメディア形式とは無関係に通信動作が可能であり、
前記チャネル・ドライバは、前記通信チャネルと通信可能となるように前記通信チャネルの前記メディア形式に対応可能であり、
前記通信チャネルの前記メディア形式は、複数のメディア形式のうちの１つのメディア形式であることを特徴とする方法。
更に、
前記通信サーバに、前記ユーザ・インタフェースからコマンドと関連付けられているユーザ・インタフェース・オブジェクトのアクティブ化を取得させるステップと、
前記通信サーバに、前記メディア形式に従った通信で前記通信チャネルに前記コマンドを発行させるステップとを有することを特徴とする請求項１５に記載の方法。
更に、
前記通信サーバに、前記イベントが通知されるエージェントを決定させるステップを有し、
前記通信サーバに前記通知を提供させるステップは、前記通信サーバに、前記ユーザ・インタフェースを介して前記エージェントに前記通知を提供させるステップを有することを特徴とする請求項１５に記載の方法。
前記イベントは、作業項目に対応しており、
前記通信サーバに前記イベントの前記通知を提供させる前記ステップは、前記通信サーバに、前記作業項目の通知を提供させるステップを有することを特徴とする請求項１５に記載の方法。
更に、
前記通信サーバに、前記ユーザ・インタフェースと前記通信チャネルとの間の接続を確立させるステップを有し、
前記通信サーバに前記通知を提供させる前記ステップは、前記接続を介して実行されることを特徴とする請求項１５に記載の方法。
更に、
前記通信サーバに、前記メディア形式に従った通信で前記通信チャネルにコマンドを発行させるステップを有することを特徴とする請求項１５に記載の方法。
更に、
ユーザ・インタフェースのユーザ・インタフェース・オブジェクトがアクティブ化されるのに応じて、前記通信サーバに、前記メディア形式とは無関係に前記コマンドを決定させるステップを有することを特徴とする請求項２０に記載の方法。
更に、
前記イベントの受信に対するイベント応答を決定するように、前記通信サーバに、データベースにアクセスさせるステップと、
前記通信サーバに、前記メディア形式とは無関係に前記イベント応答を実行させるステップとを有することを特徴とする請求項１５に記載の方法。