JP5331374B2 - 適応型通信アプリケーション・プログラミング・インタフェース - Google Patents

Description

本発明は、適応型通信アプリケーション・プログラミング・インタフェースに関するものである。

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

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

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

特許出願第09/823,678号

特許出願第09/823,531号

一実施例では、モジュール間の通信が開示されている。この方法は、コマンド定義を定義するステップを含んでいる。このコマンド定義は、複数チャネル、複数メディア（マルチメディア）、通信キューイング・システムとのインターフェースをとるためのコマンドを有する。

一態様では、この実施例は、メディア形式リスト及びコマンド・イベント・リストの要求、ドライバ・オブジェクトの生成、サービスの要求、及びドライバ・オブジェクトの解放のためのドライバ・オブジェクト・コマンドを含む。

別態様では、この実施例は、サービス・オブジェクトの解放、イベントの処理が完了した際の通知、コマンドの呼出し、ワーク・アイテムの解放、ワーク・アイテムの保留、ワーク・アイテムの再開、キューされているイベントの処理、及びキューされているイベントの取消しのためのサービス・オブジェクト・コマンドを含む。

別態様では、この実施例は、ワーク・アイテムの開始、ワーク・アイテムの解放、ワーク・アイテムの状況（context）の保存、ワーク・アイテムの状況の復旧、ワーク・アイテムのシリアル化、ワーク・アイテム・ストレージの解放、バッチ処理の開始、及びバッチ処理の終了のためのコマンドを含む。

別の実施例では、モジュール間の通信の定義が開示されている。この定義は、コマンド定義を含んでおり、このコマンド定義は、複数チャネル、複数メディア、通信キューイング・システムとのインタフェースをとるためのコマンドを有する。

この実施例の一態様では、コマンド定義は、メディア形式リスト及びコマンド・イベント・リストの要求、ドライバの生成、サービスの要求、及びドライバの解放のためのコマンドを含む。

この実施例の別態様では、コマンド定義は、サービス・オブジェクトの解放、イベント処理が完了した際の通知、コマンドの呼出し、ワーク・アイテムの解放、ワーク・アイテムの保留、ワーク・アイテムの再開、キューされているイベントの処理、及びキューされているイベントの取消しのためのサービス・オブジェクト・コマンドを含む。

この実施例の別態様では、コマンド定義は、ワーク・アイテムの開始、ワーク・アイテムの解放、ワーク・アイテムの状況の保存、ワーク・アイテムの状況の復旧、ワーク・アイテムのシリアル化、ワーク・アイテム・ストレージの解放、バッチ処理の開始、及びバッチ処理の終了のためのクライアント・オブジェクト・コマンドを含む。

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

別個の図面で類似の参照番号が用いられている場合には、類似若しくは同一のアイテムであることを示している。

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

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

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

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

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システム１０２と通信することが可能である。別の実施例では、ワーク・アイテムキューの保守、及びエージェントのワーク・アイテムへの割当てのために、サードパーティ・キューイング・システムと通信することが可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2．ループを終了する。

デフォルト設定では、エージェントはそのエージェントが属する構成に関連付けられている全てのチャネル・ドライバ１２０へのアクセスが許可されている。例えば、エージェントが「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は、主として実行時間中に更新される。エージェントがユーザ・インタフェースを用いて最初にログインした際に、そのエージェントがアクセスを許可されているメディア形式の各々に対して1レコードずつ生成される。例えば、
｛"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」は、エージェントが電話での話を開始した時間、若しくはe−メール若しくはファックス等のワーク・アイテムへの取組みを開始した時間である。

「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"｝
上記のレコードは、エージェントが内線5216で現在話し中であり、且つinfo@company.comに送信されるe−メールに取組んでいることを示している。

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

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

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

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

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

一実施例では、エージェントに対する内線リストを決定するための方法には、そのエージェントによって用いられる第1端末が特定される、ACTIVE_TELESET_IDパラメータ内にある第1Teleset 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] 第1段階、イベント・ハンドラ定義
Device = "EventRinging" メディア・イベント定義
Response = "OnInsideCallReceived" イベント応答宣言
Filter.Call = "?*" イベント・ハンドラ・パラメータ
Order = "1" イベント・ハンドラ・オーダ

[EventResponse: OnInboundCallReceived] 第2段階、イベント応答定義
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}"
各イベント・ハンドラは、チャネル・ドライバ１２０によって提供されるイベントと対応しており、イベントに対するイベント・ハンドラの間で順序が付けられている。各イベント・ハンドラは、イベント応答を有している。イベント応答は、イベント・ハンドラの間で共有可能である。1つのイベント応答が、複数のイベント・ログを有していてよいし、更に、1つのイベント・ログが複数のイベント応答の間で共有されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（汎用キューイング・システム）
UQシステム１０２によって、全ての形式のメディアに対する要求が、その要求がエージェントに割当てられるまで、キューイングされる。エージェントのログイン、タスクの完了、若しくはステート又は割当ての変更のいずれかによって、エージェントが利用可能になると、UQシステム１０２によって通信チャネルからエージェントにワーク・アイテムが転送され、且つ各キューからワーク・アイテムが除去される。一実施例では、複数のワーク・アイテムがエージェントにルーティングされた場合には、最初に到着したワーク・アイテムがそのエージェントに提出される。他のワーク・アイテムは各キューに返されて、その特定のワーク・アイテムを処理することができる次に利用可能なエージェントに再ルーティング／転送される。

UQシステム１０２は、UQサーバ３０８を介してUQエンジン３０６とのインタフェースをとるUQリクエスタ３０４及びUQ受信機３０２を含んでいる。Webサーバ１４６は、UQシステム１０２を介してメッセージを受信するように、システム１００の中に含まれていてよい。一実施例では、webサーバ１４６は、メッセージを受信して、それをEAIオブジェクト・マネージャ１９０に送信する。EAIオブジェクト・マネージャ１９０は、そのメッセージをパッケージ化して、それをUQビジネス・サービス１０６に転送する。EAIオブジェクト・マネージャ１９０を含んでいない別実施例では、このメッセージが直接的にUQビジネス・サービス１０６に送信され得る。

UQビジネス・サービス
UQシステム１０２は、UQアプリケーション・プログラミング・インタフェース（UQ API）３１４を介してUQビジネス・サービス１０６及びwebサーバ１４６とのインタフェースをとる。UQビジネス・サービス１０６は、UQシステム１０２から受信した情報を通信サーバ１０９によって利用されるデータ構造の中に配置する。更に、UQビジネス・サービス１０６は、通信サーバ１０９からの情報をUQ API３１４によって認識及び利用されるデータ構造、コマンド、及びパラメータの中に配置する。

一実施例では、UQビジネス・サービス１０６は、UQシステム１０２の初期化及び通信を行うための、括弧で示された入力及び出力のパラメータを利用する、以下の関数を含んでいる。

UQOpenConnection（UQConfigurationName, Return）
通信サーバ１０９からメッセージを受信するために、UQビジネス・サービス１０６に、必要なUQ構成パラメータを提供する。全てのUQビジネス・サービス関数において、パラメータ「Return」は、復帰の際の関数のステータスを示している（例えば、「0」は、正常終了を意味する）。

UQAssign（Return）
通信サーバ１０９と通信するために、UQビジネス・サービス１０６に、必要なUQ構成パラメータを提供する。

UQInitRules（Return）
UQOpenConnectionが呼出されると、UQビジネス・サービス１０６によって、エージェント規則、ワーク・アイテム・エスカレーション規則等の規則を更新するかが決定される。この関数は、通信サーバ１０９を開始する際に呼出される。規則が送信される場合には、この関数によって、データ・テーブルからルート規則及びエスカレーション規則が読出されて、それらがパッケージ化されてUQシステム１０２に転送される。一度、UQシステム１０２に規則がダウンロードされてしまえば、それらの規則を修正する際には、UQReplaceRules関数が呼出される。

UQReplaceRules（Return）
この関数は、例えば、通信サーバ１０９の動作中に、エージェント若しくはエスカレーション規則のセットが変更された場合のように、UQ規則の更新が必要なときに呼出される。

UQDisconnect（Return）
UQシステム１０２とwebサーバ１４６との間の接続、及びUQシステム１０２と通信サーバ１０９との間の接続を終了させるように、UQシステム１０２に対して命令する。この関数は、UQシステム１０２のサービスがもはや不要になった際に呼出される。

一実施例では、UQビジネス・サービス１０６は、更に、エージェントの初期設定及び保守のための以下の関数を含む。

AgentLogon（AgentLogin, Return, AgentState）
この関数によって、エージェントはUQシステム１０２へのログインが可能になる。一度、ログインが成功してしまえば、エージェントはワーク・アイテムを受信可能な状態になる。AgentLoginパラメータは、通信サーバ１０９に割当てられたエージェント識別番号である。AgentStateパラメータは、関数が実行された後のエージェントの状態（ステート）を示す値が設定される。

AgentLogout（AgentLogin, Return, AgentState）
この関数によって、エージェントはUQシステム１０２からログアウトが可能になる。一度、ログアウトが成功してしまえば、UQシステム１０２は、このエージェントに対してワーク・アイテムをそれ以上キューイングしない。

AgentInitAuxwork（AgentLogin, Output）
この関数は、現在のワーク・アイテムが全て終了した後に、エージェントをAuxWorkモードに設定するように、UQシステム１０２に対して要求する。AuxWorkモードでは、エージェントは、それ以上の作業を受取りはしないが、UQシステム１０２にログインした状態でとどまっている。

AgentAvailable（AgentLogin, Return, AgentState）
この関数は、エージェントを利用可能ステータスに設定するように、UQシステム１０２に対して要求する。この利用可能状態では、このエージェントは、ワーク・アイテムを受信可能な状態になっている。

RequestAgentMediaMode（AgentLogin, MediaType, Return,
AgentMediaMode）
この関数によって、クライアント１０４がエージェント・ステートを要求することが可能になる。

ChangeAgentMediaMode（AgentLogic, Return, AgentMediaMode）
この関数によって、クライアント１０４がエージェントに対するメディア・モードを変更することが可能になる。

ChangeAgentSkil（AgentLogin, Return）
この関数によって、クライアント１０４がエージェントのスキルを更新することが可能になる。エージェントのスキルが変更された後には、新しいエージェント・スキルに対して、この関数を用いてUQシステム１０２が更新される必要がある。

RequestAgentState（AgentLogin, Return, AgentState）
UQシステム１０２に現在のエージェントのステートを報告するように要求する。

RequestAgentWorkItemList（AgentLogin, Return, WorkItemID, MediaType, IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, WorkItemState, WorkItemDataProperty）
エージェントによって現在処理されている全てのワーク・アイテムのリストを返すように、UQシステム１０２に対して要求する。

RequestAgentWorkableList（AgentLogin, Return, WorkItemID, MediaType, IsScheduledTask, ScheduleStartTime, ScheduleEndTime, AgentID, WorkItemState, WorkItemDataProperty）
この関数は、エージェントが可能なワーク・アイテムのリストを返すように、UQシステム１０２に対して要求する。この関数は、エージェントがUQシステム１０２によって割当てられたワーク・アイテムではなく、特定のワーク・アイテムを選ぶことを望む場合に用いられる。

RequestWorkItemAssignment（AgentLogin, WorkItemID, Return）
この関数は、もし可能ならば、エージェントに特定のワーク・アイテムを発信するように、UQシステム１０２に対して要求する。ワーク・アイテムが利用可能な状態で残っていれば、Returnパラメータ・コードはSUCCESSとなり、このワーク・アイテムは、通信サーバ１０９を介して配信される。

RequestAgentMediaState（AgentLogin, Return, MediaType, AgentState, NumWorkItems）
この関数は、エージェントが処理可能な各メディアに対するメディア（チャネル・ステート）を報告するように、UQシステム１０２に対して要求する。

一実施例では、UQビジネス・サービス１０６は、更に、ワーク・アイテムの初期設定及び保守のための以下の関数を含む。

AddWorkItem（WorkItemID, MediaType, IsScheduledTask,
ScheduleStartTime, ScheduleEndTime, WorkItemDataProperty, Return）
この関数は、将来の発信のために、UQシステム１０２に特定のワーク・アイテムを付加するように、UQシステム１０２に対して要求する。

RequestWorkItemState（WorkItemID, Return, WorkItemState）
この関数は、ワーク・アイテムの現在のステートを要求する。

AcceptWorkItem（WorkItemID, Return）
この関数によって、クライアント１０４が、割当てられたワーク・アイテムが受入れられたことをUQシステム１０２に通知することが可能になる。結果として、ワーク・アイテムが受入れられたことを反映するように、UQシステム１０２によってエージェント・ステート及びワーク・アイテム・ステートが更新される。

RejectWorkItem（WorkItemID, AgentLogin, Reason, Return）
この関数によって、クライアント１０４が、割当てられたワーク・アイテムが拒否されたことをUQシステム１０２に通知することが可能になる。結果として、ワーク・アイテムはキューに返されて、チャネルに対するエージェント・ステートは、AuxWorkに設定される。

CompleteWorkItem（AgentLoginm WorkItemID, Return）
この関数によって、ワーク・アイテムの完了がUQシステム１０２に通知される。エージェントに対する次のステートは、Auto−Wrap設定に依存し、それは、ツール・バー１０５等のユーザ・インタフェースを介して設定することが可能である。Auto−WrapがTRUEである場合、このエージェントは、Wrapモードであり、ワーク・アイテムはwrapモードにある。Auto−WrapがFALSEである場合、このエージェントは、元の利用可能（Available）モードに設定される。

HoldWorkItem（AgentLogin, WorkItemID, Return, WorkItemState, NewAgentState）
この関数は、ワーク・アイテム１０２を保留ステータスに設定するように、UQシステムに対して要求する。

UnHoldWorkItem（AgentLogin, WorkItemID, Return, WorkItemState, NewAgentState）
この関数は、ワーク・アイテム１０２を保留ステータスから解除するように、UQシステムに対して要求する。

BlindTransferWorkItemToAgent（AgentLogin, WorkItemID, Return）
この関数は、ワーク・アイテムを他のエージェントに転送する。そのエージェントが利用可能でない場合に、このワーク・アイテムはそのエージェントに対してキューイングされてもよい。

TransferWorkItemToAgent（AgentLogin, WorkItmeID, Return）
この関数は、ワーク・アイテムをエージェントに転送するように、UQシステムに依頼する。そのエージェントが利用可能でない場合に、UQシステム１０２は、そのワーク・アイテムが配信されなかったことを、要求してきたエージェントに通知してもよい。

TransferWorkItemToRoute（AgentLogin, RouteID, Return）
この関数は、エージェントを、システム１００（図１−Ａ参照）によって規定されるルートに転送する。ルートは、ワーク・アイテムを処理するための特別の方法を示している。ワーク・アイテムをルートに転送することによって、ワーク・アイテムの特性、及びワーク・アイテムを処理するべき方法が再定義される。例えば、ワーク・アイテムが、最初は、ある領域内での知識を有するエージェントによって処理されるのが最適であると考えられていたとする。次に、別の領域内での知識を有するエージェントによって処理されるべきであると判明する。それゆえに、このワーク・アイテムは、ワーク・アイテムを処理可能なルートに転送される。

一実施例では、UQビジネス・サービス１０６は、性能の統計データを報告するための以下の関数を含む。

SetChannelStatInterval（Interval, Return）
この関数は、チャネルの実時間統計データの供給間隔を設定するのに用いられる。例えば、60秒等の所定のデフォルト値を用いることが可能である。統計データは、UQビジネス・サービス１０６に転送されて、テーブル内に記録される。

StartAgentStat（Interval, Return）
この関数は、エージェントの統計データの転送を開始するのに用いられる。データは、エージェント統計データ・テーブルに記録される。

StopAgentStat（AgentLogin, Return）
この関数は、エージェントの統計データの転送を終了するのに用いられる。

一実施例では、UQビジネス・サービス１０６は、ワーク・アイテムを処理するための以下の関数を含む。

HandleWorkItem（AgentLogin, WorkItemID, MediaType, IsScheduleTask,
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkItemState,
DataProperty, MediaType, IsScheduleTask, ScheduleStartTime,
ScheduleEndTime, AgentLogin, WorkItemState, DataProperty, Return）
この関数は、ワーク・アイテムがエージェントに割当てらていることをクライアントに通知するために用いられる。

HandleWorkItemStatus（WorkItemID, MediaType, IsScheduleTask,
ScheduleStartTime, ScheduleEndTime, AgentLogin, WorkItemState,
DataProperty, Return）
この関数は、ワーク・アイテムに対するステータスが変更されており、その結果としてクライアント１０４が必要な動作を行うことが可能であることをクライアント１０４に対して通知するのに用いられる。例えば、他のパーティがワーク・アイテムを放棄したために、ワーク・アイテム・ステータスが、警告から終了に変更される可能性がある。この場合に、クライアント１０４は、実行するのに何らかの準備動作を必要とする可能性もある。

HandleAgentStateChange（AgentLogin, AgentState, Return）
この関数は、エージェントのステータスが変更されたことをUQクライアントに通知するのに用いられる。

HandleRouteStatisticsRequest（RouteStat, TotalWorkItems,
AverageWatiTime, AverageServeTime, NlongesWaitTime, OperationMode, Return）
この関数は、ルート統計データ情報の到着をクライアント１０４に通知するのに用いられる。このメソッドは、入力統計データ情報の処理を、例えば、それをデータベースへの書込み等によって行う。

HandleAgentStatisticsRequest（AgentLogin, TotalWorkItems,
AverageServeTime, AverageWrapTime, TotalAuxTime, TotalServingTime,
TotalLoginTime, TotalServedWorkItem, Return）
この関数は、エージェント統計データ情報の到着をUQクライアントに通知するのに用いられる。このメソッドは、入力統計データ情報の処理を行う。ほとんどの場合、その情報はデータベースに書込まれる。

HandleError（MessageCode, Return）
この関数は、エラーを受信したことをUQクライアントに通知するのに用いられる。

HandleAlarm（MessageCode, Return）
この関数は、警告を受信したことをUQクライアントに通知するのに用いられる。

HandleJournal（WorkItemID, WorkItemDataProperty, AgentStateHist,
AgentLogin, AgentState, StartTime, EndTime, UQReasonCode,
AgentReasonCode, EscHist, SzStep, StartTime, EndTime, UQReasonCode,
AgentReasonCode, Return）
ワーク・アイテムが完了した際に、UQクライアントに送信されるワーク・アイテムの実行記録。UQクライアントは、その実行記録をデータベースに記録する。

前記のリストは、UQビジネス・サービス１０６に含まれてよい関数の例である。付加的に、若しくはこれらの例の代わりに、別の関数が含まれてもよい。関数によっては、要求された関数が正常終了したかどうかが示し、且つ／又はUQシステム１０２、ワーク・アイテム、若しくはエージェントのステートを示すような、復帰コード及び／又はステート・コードを含んでいる。以下のリストは、前記の関数において、パラメータとして用いられるコードの例である。

復帰コード
0 Success
1 Success_More_Status
2 Error_Uq_Initialized
3 Error_Uq_Not_Initialized
4 Error_Failed
5 Error_System_Wrong_Api
6 Error_System_Initialization_Failed
7 Error_Agent_Setting_Invalid_State
8 Error_Agent_Undefined
9 Error_Agent_Unable_To_Change_Skill
10 Error_Queue_Not_Initialized
11 Error_Queue_Undefined
12 Error_Queue_Capacity_Exceeded
13 Error_Workitem_Adding_Failed
14 Error_Workitem_Failed_Change_State
15 Error_Unknown_Media
エージェント・ステート
1 Available
2 Logout
3 Busy
4 AuxWork
5 InitAuxWork
メディア・モード
1 Available
2 Unavailable
3 Busy
4 Wrap_Up
動作理由コード
1 Setting_Invalid_State
2 Agent_Not_Available
3 Route_Undefined
ワーク・アイテム・ステート
1 Active
2 Wrap_Up
3 Alerting
4 Completed
5 Queued
6 Scheduled
7 On_Hold
8 Received
UQ構成
図１−Ａ乃至図１−Ｅ及び図３を参照すると、クライアント１０４は、UQビジネス・サービス１０６内のUQOpenConnection関数を介してUQ構成を選択する。UQシステム１０２は、「UQ受信機サーバ名」及び「UQ受信機ポート」等の情報を用いて、応答をどこに送信するかを決定する。一実施例では、EAIオブジェクト・マネージャ１９０内の複数の受信機サーバ（図示せず）が、UQシステム１０２からメッセージを受信するように接続されてもよく、それにより、UQシステム１０２と通信する各受信機によって、UQOpenConnection関数内のUQ構成パラメータが送信される。

表１は、UQシステム１０２内に記憶されており、UQOpenConnection関数を介して、通信サーバ１０９との通信の確立、及び通信サーバ１０９により要求される関数の実行に用いられるUQ構成テーブル内のパラメータの例が示されている。例えば、表１は、UQシステム１０２に対するホストを識別し、それとの通信を確立するためのパラメータを含んでいる。更に、表１は、ログイン後にauto−readyステートになっているか、ログイン後にauto−auxworkステートになっているか等のエージェント優先度に関するデフォルト設定も含んでいる。

表２は、プロパティ情報（PropertyInfo）パラメータと呼ばれる、表１内のUQ構成テーブル内のパラメータのサブセットを示しており、それらは、UQビジネス・サービス１０６内に含まれる別の関数に用いられる。

Webサーバ１４６は、EAIオブジェクト・マネージャ１９０への出力メッセージに対して適切なデータ転送プロトコルを利用してパッキング情報の処理を行う。
一実施例では、例えば、UQ API３１４へのメッセージ、及びそこからのメッセージの通信にHTTPが用いられる。Webサーバ１４６は、HTTPフォーマットの情報を、EUQビジネス・サービス１０６で使用されるようにAIオブジェクト・マネージャ１９０によってアンパッキングされる別の適切な転送プロトコルに変換する。別の実施例では、HTTPの代わりに、若しくは付加的に、当技術分野で公知の別のプロトコルが用いられてよい。

UQルーティング
UQエンジン３０６は、各ワーク・アイテムを処理するためのルートを定義する。例えば、ワーク・アイテムが、コンピュータ・ネットワーキングの知識を備えたエージェントからの応答を必要とするファックスであった場合、UQエンジン３０６によって、コンピュータ・ネットワーキングのスキルを備えたエージェントを特定するルートが定義される。エージェントは、そのワーク・アイテムに応答することが不可能な場合にはTrasnferWorkItemToRoute（Route configuration Name）関数若しくはBlindTransferWorkItemToAgent（agentID）関数を用いてルート・キューにそのワーク・アイテムを転送することが可能である。エージェントがそのワーク・アイテムに応答するためには別のスキルが必要であると判定した場合には、転送を呼出す前に、そのワーク・アイテムが必要とするスキルを変更することも可能である。

一実施例では、各々のルート・ポイントが特定のスキル要求を有する、複数のルート・ポイントが生成される。ワーク・アイテムが別のポイントに転送される場合に、転送するエージェントによって、例えば、ポップ・アップ・リストからルート・ポイントが選択されてよい。このリストには、全てのエージェント、若しくは全てのルート・ポイントのいずれかをリストするオプションが含まれていてよい。

UQシステム・シナリオ
以下の例では、クライアントからの要求が、システム１００の一実施例を通して、どのように処理されるかが示されている。

[初期設定及び規則のダウンロード]
通信サーバ・バックグラウンド・モード・サーバ１７０は、クライアントをUQシステム１０２と接続するのにUQビジネス・サービス１０６内のUQOpenConnection関数を用いる。一実施例では、UQビジネス・サービス１０６を初期化するのに、デフォルトの構成を含め、2以上の構成が用いられる。このデフォルトのUQ構成パラメータは、他の構成が1つも指定されなかった場合に用いられる。UQOpenConnectionのUQプロパティ情報パラメータには、webサーバ１４６内での第1受信機サーバの位置を特定するPrimaryReceiverName及びPrimaryReceiverPortが含まれている。

UQOpenConnectionは、webサーバ１４６内の複数の受信機サーバをUQシステム１０２に接続するように、複数回呼出すことが可能である。又、UQシステム１０２は、接続された受信機サーバへの全ての接続のリストを保持する。UQOpenConnectionが正常終了した後、エージェント・スキル情報と、エージェントのエスカレーティング及びルートの特定のための規則とをダウンロードするためにUQInitRules関数が呼出されてよい。一実施例では、UQInitRulesは、初期化の際に一度だけ呼出され、UQReplaceRulesは、一度初期化された規則を更新するのに用いられる。パラメータERROR_UQ_INITIALIZEDは、UQInitRulesが連続的に呼出された場合のエラーを示している。初期化が正常終了したかどうかのインジケータは、UQInitRules関数に関連するReturnパラメータで提供される。

[エージェント・ログオン]
新規のエージェントは、新規のエージェントが存在することをUQシステム１０２に通知するように、ビジネス・サービス１０６を通してUQOpenConnectionを呼出す。次に、AgentLogon関数が、そのエージェントをUQシステム１０２に記録するように、UQビジネス・サービス１０６によって呼出される。UQビジネス・サービス１０６は、エージェント・スキル情報を含むメッセージをUQシステム１０２に送信する。

複数の受信機サーバが接続されている場合、関数AgentLogonの各呼出しは、そのエージェントが関連付けられている受信機サーバに関する情報を含んでいる。更に、エージェント情報は、auto−available設定及びauto−wrap設定を含む情報も含んでいる。UQシステム１０２は、AgentLogonの呼出しが失敗した場合のエラー、若しくはログオン動作が正常終了した場合の新規エージェントのステートのいずれかを返す。

[Eメール到着]
通信サーバ１０９は、eメール・メッセージを受信すると、メッセージを、そのメッセージを送信したクライアントに関する関連情報と共にUQビジネス・サービス１０６に送信する。UQビジネス・サービス１０６は、AddWorkItem関数を用いて、eメール・メッセージ及び関連情報をUQシステムに転送する。UQシステム１０２は、ワーク・アイテムを受取とるかどうかを決定して、webサーバ１４６、EAIオブジェクト・マネージャ１９０、及びUQビジネス・サービス１０６を介して通信サーバ１０９に応答を発行して、それにより、HandleWorkItem関数内のステータス・パラメータを利用して、ワーク・アイテムが受取られたかどうかが示される。

[UQによるワーク・アイテムの配信]
UQシステム１０２は、ワーク・アイテムに対するエージェントを決定して、ワーク・アイテムがエージェントに割当てられたというメッセージを、そのエージェントに関連付けられている受信機サーバを介して通信サーバ１０９に送信する。次に、UQシステム１０２は、HandleWorkItem関数によって、そのエージェントに関連付けられている受信機サーバにメッセージを送信する。エージェントにメッセージを転送するように、UQビジネス・サービス１０６内のProcessEvents関数が呼出される。エージェントは、ワーク・アイテムを受信したことをUQシステム１０２に通知するために、WorkItemAccept関数を呼出す。

[UQシステムによる警告若しくはエラーの発行]
UQシステム１０２が、通信サーバ１０９にエラー若しくは警告を通知するための1つのメソッドの一例として、通信チャネルの1つにより処理され得る要求の数が所定の閾値を超過してしまったとUQシステム１０２が判定した場合を仮定する。UQシステム１０２は、HandleError関数によって受信機サーバに復帰コードを送信して、それにより、キューの容量が超過してしまったことが示される。Webサーバ１４６は、メッセージを受信して、UQビジネス・サービス１０６内の「ProcessEvents」関数を呼出す。このエラー・メッセージは、記録されてもよく、又、要求を発行していた構成要素にブロードキャストされる。警告メッセージも同様の方法で処理される。エラー／警告は、視覚的に、聴覚的に、テキスト形式で、及び／又は当技術分野で公知の任意のその他の適切な手段を用いてブロードキャストされてよい。

[UQシステムによる通信サーバへの統計データの送信]
システム１００（図１−Ａ参照）内のクライアント若しくは構成要素は、SetChannelStatInterval関数、StartAgentStat関数、及び／又はStopAgentStat関数によって、UQシステム１０２から通信チャネル、エージェント、及び／又はエージェントのルーティングに関する統計データを要求することが可能である。UQシステム１０２は、要求された統計データを生成して、それらをWebサーバ１４６に転送する。EAIオブジェクト・マネージャ１９０内の受信機サーバがそのメッセージを受信すると、その統計データの記録をとって、当技術分野で公知であるメッセージ・バー機構等のインタフェースを通してそれらをブロードキャストすることが可能である。連続的に、統計データを要求するようにエージェント構成を設定することも可能である。この統計データには、完了したワーク・アイテム、及びエージェント・キュー内にあるワーク・アイテムに関する情報が含まれ得る。

[エージェントによるワーク・アイテムの受入れ]
エージェントがAuxWorkモードである場合、このエージェントは、ツール・バー１０５等のユーザ・インタフェースを通して、キューからワーク・アイテムを選択することが可能である。ワーク・アイテムが選択されると、UQシステム１０２は、ビジネス・サービス１０６内のRequestWorkableItemList関数によって通知される。そのワーク・アイテムが利用可能である場合には、この関数によって、復帰パラメータを通して選択に問題がないことが示されて、そのワーク・アイテムはHandleWorkItem関数によって配信される。そのエージェントに対して利用可能であるワーク・アイテムが存在しない場合には、このRequestWorkableItemList関数によって、エラー・インジケータが返される。

[ルーティングの呼出し]
UQシステム１０２は、ルート要求を受信すると、ワーク・アイテムに割当てるエージェントを決定して、EAIオブジェクト・マネージャ１９０内のそのエージェントの受信サーバにその割当てエージェント及びワーク・アイテムが含まれるメッセージを送信する。UQシステム１０２が時間内に割当てるエージェントをみつけられなかった場合には、その要求は、UQエンジン３０６により実装されている待ちキューの中に配置される。市販されている多種多様のキューイング・エンジン３０６がUQシステム１０２内で利用されてよいことに留意する必要がある。

[自動着信分配装置（ACD）とUQシステムとの対話]
図１−Ａ乃至図１−Ｄ及び図３を参照すると、エージェントは、UQシステムと対話することなく、直接的にACDスイッチ１３０Ｅから呼出しを受信するように接続されてもよい。更に、エージェントは、ACDスイッチ１３０Ｅから呼出しを受信し、且つUQシステム１０２を介してその他のワーク・アイテムを受信するように接続されてもよい。この形式の構成は、補助作業モード（AuxWorkモード）と呼ばれる。エージェントが、ツール・バー１０５等のインタフェースを介して自分をAuxWorkモードに設定することも可能であるし、或いは、管理者が、そのエージェントをAuxWorkステートになるように構成することも可能である。

AuxWorkモードの一実施例では、ACDスイッチ１３０Ｅによって、エージェントに呼出しが転送されて、そのエージェントは、その呼出しに応答する際にセッション・モード通信サーバ１１０に通知を行う。次に、セッション・モード通信サーバ１１０によって、その通知がUQシステム１０２に中継される。この時点で、UQシステム１０２は、例えば、本明細書で説明されているAgentInitAuxwork関数を用いて、セッション・モード通信サーバ１１０に、エージェントが呼出しを完了した後に、そのエージェントをAuxWorkステートに設定するように依頼する。

エージェントが呼出しを完了すると、エージェントによって、セッション・モード通信サーバ１１０にその呼出しの完了が通知されて、次に、そのセッション・モード通信サーバ１１０によって、その呼出しの完了がUQシステム１０２に通知される。次に、UQシステム１０２は、エージェント構成内にあるメディア・チャネルに基づいてエージェントに割当てる適切なワーク・アイテムが存在するかどうかを決定する。ワーク・アイテムが利用可能である場合、そのワーク・アイテムは、EAIオブジェクト・マネージャ１９０内のエージェント受信機サーバを通してエージェントに送信される。エージェントは、そのワーク・アイテムが完了するとUQシステムに通知する。UQシステム１０２によって、エージェントに対するワーク・アイテムが1つも存在しないと判定されると、UQシステム１０２は、ACDスイッチ１３０Ｅを介して、エージェントのACDモードを呼出しの受信の継続が可能であると設定するように、セッション・モード通信サーバ１１０に通知する。

エージェントをAuxWorkステートに設定するために、複数の代替実施例を利用することが可能である。例えば、エージェントは、AuxWorkステートをデフォルトにしてよい。そのエージェントによって処理される必要のある呼出しをACDスイッチ１３０Ｅが受信すると、UQシステム１０２が通知されて、次に、そのエージェントは、eメール要求への応答等のワーク・アイテムの処理を保留にして、その呼出しを受けるように通知される。その呼出しが完了すると、エージェントは、UQシステム１０２に通知を行い、保留中のワーク・アイテムの処理に戻る。

[エージェント・ステートの変更]
ワーク・アイテムがエージェントに転送されると、このエージェントは、そのワーク・アイテムを受入れるように、AcceptWorkItem関数を呼出す。AceeptWorkItem関数の出力パラメータによって、新規のエージェント・ステート及びワーク・アイテム・ステートが、UQシステム１０２に通知される。エージェントがこのワーク・アイテムを完了させると、UQシステム１０２に新規のエージェント・ステート及びワーク・アイテム・ステートを通知するように、CompleteWorkItem関数が呼出される。

完了の際に、エージェントがワーク・アイテムをまとめる（wrap up）ための時間を可能にするauto−wrapオプションがエージェントの構成テーブルに設定されてもよい。エージェントは、自分がwrap−upモードから抜けており、別のワーク・アイテムを受入可能であることを示すために、AgentAvailable関数を呼出すインタフェース・オプションを選択することが可能である。UQシステム１０２によって、ワーク・アイテムのステータスが完了に変更されて、AgentInitAuxWork関数が呼出されている場合には、エージェントがAuxworkステートに設定される。AgentInitAuxWork関数が呼出されておらず、そのエージェントが処理可能な別のワーク・アイテムがキュー内に存在していれば、エージェント・ステートは、BUSY（取込み中）に設定される。そうでない場合には、このエージェントは、Available（利用可能）ステートに設定される。

［ワーク・アイテムの取消し］
エージェントにワーク・アイテムが割当てられた後で、且つエージェントがそのワーク・アイテムを受入れる前に、ワーク・アイテムが取消される場合が生じ得る。そのような状況は、例えば、呼出している人が待機中に電話を切ってしまった場合等に発生する。この場合に、UQシステム１０２は、HandleWorkItemStatusによって、クライアントにそのワーク・アイテムの取消しを通知して、且つそのワーク・アイテムが除去されたことを示すように、エージェントのユーザ・インタフェース・ディスプレイ上のボタンを点滅させる等のように信号が変更され得る。

［PBX及びEメールではPBXに高い優先度を与える］
用語「機内交換機（PBX）」は、通常、公衆交換回線網へのアクセスを含む、加入者が所有する通信交換機のことを示している。eメール及びPBXワーク・アイテムがキューイングされると、UQシステム１０２は、ルート規則に規定される優先度を用いていずれのメディアが他のものよりも高い優先度を有しているか決定する。通常、クライアント構成は、PBXワーク・アイテムにeメールよりも高い優先度を与える。

［ワーク・アイテム実行記録］
ワーク・アイテムが完了すると、UQシステム１０２は、HandleJournal関数によって、通信サーバ１０９にワーク・アイテム実行記録エントリを送信する。この実行記録エントリは、エージェント・ステート・ヒストリ及び／又はワーク・アイテムのワーク・アイテム・エスカレーション・ヒストリに関連しているかどうかを識別するための情報を含む。

［システム障害］
UQシステム１０２とセッション・モード通信サーバ１１０との間の接続に障害が発生すると、UQシステム１０２は、セッション・モード通信サーバ１１０に関連付けられている全てのエージェントを除去して、且つ全てのワーク・アイテムを障害エラー・コードと共に「完了」に設定する。

［複数の要求及び受信機］
UQビジネス・サービス１０６は、インスタンスが生成されると、送信側サーバ構成要素名及びワーク・フロー名を含むUQ構成をロードする。一実施例では、送信側サーバ構成要素は、クライアント１０４側からは見えない、EAIオブジェクト・マネージャ１９０である。EAIオブジェクト・マネージャ１９０のインスタンスが複数存在する場合、通信サーバ１０９は、その要求を通信サーバ１０９内の適切な構成要素にルーティングする。EAIオブジェクト・マネージャ１９０の複数のインスタンスの間の負荷を調整するように、ロード・バランサが含まれてもよい。

UQクライアントによって送信される各ワーク・アイテムは、ワーク・アイテムと関連付けられているログイン及びクライアントのキーが含まれる。ワーク・アイテムの問題若しくはエージェント割当てのいずれかが原因でUQシステム１０２から同一のワーク・アイテムが返された場合には、その結果を所定のクライアントにルーティングするように、ログイン及びクライアントのキーが用いられる。

［エージェントへのワーク・アイテムのブラインド転送］
エージェントは、ワーク・アイテムに応答することが不可能な場合に、若しくは別のエージェントによる応答がより適切であるとみなした場合に、BlindTransferWorkItemToAgent関数を用いて、そのワーク・アイテムを別のエージェントに転送することが可能である。転送相手のエージェントが転送されたワーク・アイテムを受取ることが不可能である場合、このワーク・アイテムはそのエージェントが利用可能状態になるまでキューイングされる。

［エージェントへのワーク・アイテムの協議転送］
エージェントは、ワーク・アイテムに関して別のエージェントと協議するために、TransferWorkItemToAgent関数を呼出してワーク・アイテムを転送することが可能である。そのエージェントが協議不可能である場合、UQシステム１０２によって、そのエージェントに別のエージェントが利用可能な状態にないことを通知する。そのエージェントは、そのワーク・アイテムを保留にするか、再試行するか、若しくはそのワーク・アイテムをルートに送信するか選択することが可能である。

［ルートへのワーク・アイテムの転送］
エージェントは、ワーク・アイテムをルートに沿って別のエージェントに転送することが可能である。これは、例えば、他のスキルを備えたエージェントによってより効果的に処理されるワーク・アイテムをエージェントが受信した場合等に、非常に効果的である。

UQ API
一実施例では、本発明に従ったクライアント・サーバ・システム１００（図１−Ａ乃至図１−Ｅ参照）は、UQシステム１０２と通信するためのUQ API３１４を含んでいる。例えば、インタフェースは、UQビジネス・サービス１０６によって利用されているシンプリファイド・オブジェクト・アクセス・プロトコル（SOAP）から、UQシステム１０２で利用されている拡張可能なマークアップ言語（XML）フォーマットへ等のように、情報を1つのフォーマットに変換することが可能である。更に、UQ API３１４は、UQビジネス・サービス１０６及びUQシステム１０２で利用されている別の適切なフォーマットの間で情報の変換を行うことも可能である。或いは、システム１００全体で同一のフォーマットを用いることも可能であり、それにより、UQ API３１４の必要性が除去される。UQ APIは、本願と同一日に提出され、同一の譲受人に譲渡された「Extensible Interface For Intermodule Communication」と題された、同時係属中の特許文献１（代理人整理番号M−11538）に説明されている。前記文献は、ここでの言及を以って本明細書の一部とする。

一実施例では、エージェント・スキルの入力及び編集のためのユーザ・インタフェースが提供されている。エージェント・スキルのグラフィカル・ユーザ・インタフェース（GUI）は、本願と同一日に提出され、同一の譲受人に譲渡された「Communication Toolbar Supporting Muliple Communicaiton Channels of Different Media Types」と題された、同時係属中の特許文献２（代理人整理番号M−11528）に説明されている。前記文献は、ここでの言及を以って本明細書の一部とする。このエージェント・スキルGUIには、名前、従業員番号、ジョブ名、ログイン名、連絡先、スキル、及び各スキル・アイテムに関する専門技術レベル等を含むエージェント情報を選択、入力、及び編集するためのフィールドが含まれている。エージェント・スキルGUIを通して、クライアントによってエージェントのスキルが更新された後、UQシステム１０２内のエージェント情報を更新するのに、UQビジネス・サービス１０６内のChangeAgentSkill関数が用いられてよい。

[UQ APIデータ構造]
図４−ａ乃至図４−ｍは、UQシステム１０２と通信サーバ１０９との間で情報を通信するためのUQ API３１４の一実施例で用いられるデータ構造が表現されたテーブルを示している。

図４−ａは、UQサーバ名、サーバ・ポート、受信機名、及び受信機ポート等のUQシステム１０２の構成パラメータが規定されるテーブルUQ_CFGを示している。図４−ｂは、構成の識別子、構成の名前等のUQシステム１０２に対する構成パラメータを含むテーブルUQ_CFG_PARAMを規定している。

図４−ｃは、異なるメディア形式、優先度、及びその他の特性に対して規定された異なるルートに関連する情報に対して用いられる。更に、図４−ｄは、ルートのデータ優先度を規定している。ルートのこの特性は、1以上のルート特性によって規定され得る。例えば、e−メールは、「受信者」、「主題」、及びカテゴリを有し得る。ファックス・メールの場合は、「DNIS」及び「ANI」である。これらの特性は、スキルに変換可能である。例えば、「受信者」＝「販売」は、「部門」＝「販売」と変換することが可能である。別の例として、「DNIS」＝「8000」は、「製品」＝「NT」と変換可能である。

図４−ｅは、ワーク・アイテムが所定時間、機能していない場合に、ワーク・アイテムの処理がどのようにエスカレートされ得るかが規定されている。各エスカレーション処理によって、ワーク・アイテムの処理方法が規定されている。概して、このエスカレーション処理は、ワーク・アイテムが機能する機会を増加させるように、必要なスキルを一般化する。

図４−ｆは、各エスカレーション規則で必要なスキルを規定している。各規則によって、ワーク・アイテムに必要なスキルが一般化される。

図４−ｇは、ルート・プロパティとスキルとの間のマップである。例えば、「DNIS」＝「8000」は、「製品」＝「NT」と変換可能である。これは、基本的には、各メディアに対して有り得るプロパティのリストである。例えば、eメールは主題、CC、及び受信者を有している。PBXはANI及び言語を有する。

図４−ｈは、エージェントが可能な各メディア形式に対するエンド・ポイントの数（セッションの最大数とも呼ばれる）を示している。

図４−ｉ乃至図４−ｋは、各々、ルート、メディア、及びエージェント統計データ情報が格納されている。一実施例では、この統計データは、UQシステム１０２に渡されるUQ構成で特定される所定の時間間隔で、UQシステム１０２から通信サーバ１０９に送信される。エージェント若しくは管理者も、所望に応じて、通信サーバ１０９を介して統計データを要求することが可能である。「平均待機時間」等の、時間に依存する統計データもあるので、時間周期もデータの一部として含まれる。

図４−Ｉでは、エラー・ログが格納されている。

図４−ｍ乃至図４−ｐでは、各ワーク・アイテムの処理履歴が格納されている。

その他のテーブルが、UQシステム１０２の一実施例に付加的に、若しくは図４−ａ乃至図４−ｐで示されるテーブルの代わりに含まれてよい。

模範的なコンピューティング及びネットワーク環境
図５は、本発明に従ったクライアント／サーバ・システム１００が実行されるネットワーク環境が図示されているブロック図である。図５に図示されているように、プライベート・ワイド・エリア・ネットワーク（WAN）若しくはインターネット等のネットワーク４５は、クライアント３５（１）乃至３５（N）によってアクセス可能な多数のネットワーク化されたサーバ２５（１）乃至２５（N）を含む。通常、クライアント・コンピュータ３５（１）乃至３５（N）とサーバ２５（１）乃至２５（N）との間の通信は、公衆交換電話網（PSTN）、DSL接続、ケームル・モデム接続、若しくは広帯域中継線（例えば、T1若しくはOC3サービスを提供する通信チャネル）等の公的にアクセス可能なネットワークの上で行われる。クライアント・コンピュータ３５（１）乃至３５（N）は、例えば、サービス・プロバイダ等を通してサーバ２５（１）乃至２５（N）にアクセスする。これは、例えば、American OnLine（登録商標）、Prodigy（登録商標）、CompuServe（登録商標）等、若しくは同様のインターネット・サービス・プロバイダ（ISP）であってよい。通常、アクセスは、クライアント・コンピュータ３５（１）乃至３５（N）のうちの所定の1つの上で、ソフトウェア特定用途向けソフトウェア（例えば、ネットワーク接続ソフトウェア及びブラウザ）を実行することによって行われる。

関連する、若しくは類似する一連の要素（例えば、サーバ及びクライアント・コンピュータ）の最後の要素をより単純に示すために（例えば、サーバ２５（１）乃至２５（N）、及びクライアント・コンピュータ３５（１）乃至３５（N））、図５のいくつかの例において、不定の識別子「N」が用いられていることに留意されたい。そのように不定の識別子を繰返し用いるのは、要素のそのようなシリーズのサイズの間に相関性があることを意味してのものではないが、そのような相関性が存在してもよい。不定の識別子をそのように用いているので、要素の各シリーズは、同じ不定識別子によって区切られている別のシリーズの要素と数が同じである必要はない。むしろ、各使用例では、「N」によって特定される不定は、同一の不定識別子が用いられている別の例と、同一若しくは異なる値が保持されていよい。

1以上のクライアント・コンピュータ３５（１）乃至３５（N）及び／又は1以上のサーバ２５（１）乃至２５（N）は、例えば、メイン・フレーム、ミニ・コンピュータ、若しくは個人のコンピュータ・システムを含む、任意の適切な設計のコンピュータ・システムであってよい。そのようなコンピュータ・システムは、通常、システム・プロセッサと関連する揮発性メモリ及び非揮発性メモリとを備えているシステム装置、１以上のディスプレイ・モニタ及びキーボード、1以上のディスク・ドライブ、1以上の固定ディスク式記憶装置、及び1以上のプリンタを含む。これらのコンピュータ・システムは、通常、ローカル若しくはリモートに、1以上のユーザにコンピューティング・パワーを提供するように設計されている情報処理システムである。更に、そのようなコンピュータ・システムは、システム・プロセッサに接続されており、且つ特定の機能を実行する、1つ若しくは複数のI／Oデバイス（即ち、周辺機器）も含んでいる。I／Oデバイスの例には、モデム、音響及びビデオの装置、並びに特定用途向け通信デバイスが含まれる。ハード・ディスク、CD−ROMドライブ、及び光磁気ディスク・ドライブ等の大容量記憶装置も、組込式に、若しくは周辺装置として設けられてよい。クライアント・コンピュータ３５（１）乃至３５（N）に関する説明がなされている、そのようなコンピュータ・システムの一例が、図６において詳細が示されている。

図６には、本発明を実行するのに適切であるコンピュータ・システム１０のブロック図、及び1以上のクライアント・コンピュータ３５（１）乃至３５（N）の例が示されている。コンピュータ・システム１０は、中央処理装置１４、システム・メモリ１６（通常は、RAMだが、ROM、フラッシュRAM、若しくは同様のものも含まれてよい）、入力／出力コントローラ１８、オーディオ出力インタフェース２２を介したスピーカ・システム２０等の外部デバイス、シリアル・ポート２８及び３０、キーボード３２（キーボード・コントローラ３３とのインタフェースをとる）、ストレージ・インタフェース３４、フロッピーディスク（フロッピー（登録商標））・ディスク３８を受取る機能を有するフロッピー・ディスク・ドライブ３６、並びにCD-ROM４２を受取る機能を有するCD-ROMドライブ４０等のコンピュータ・システムの主要なサブシステムを相互接続するバス１２を含む。同様に、マウス４６（若しくはシリアル・ポート２８を介してバス１２に接続されているポイント及びクリックを行うためのその他の装置）、モデム４７（シリアル・ポート３０を介してバス１２に接続されている）、及びネットワーク・インタフェース４８（バス１２に直接接続されている）も含まれる。

バス１２は、前述のように、読出し専用記憶素子（ROM）又はフラッシュ・メモリ（いずれも図示せず）、及びランダム・アクセス・メモリ（RAM）の両方が含まれ得るシステム・メモリ１６と中央処理装置１４との間でのデータ通信を可能にする。通常、RAMは、その中にオペレーティング・システム及びアプリケーション・プログラムがロードされる主メモリであり、少なくとも16MBのメモリ空間の余裕がある。このROM若しくはフラッシュ・メモリは、いくつものコードの中でもとりわけ、周辺構成要素と対話する等の基本的なハードウェア動作の制御を行う基本入出力システム（BIOS）を含み得る。コンピュータ・システム１０に常駐するアプリケーションは、概して、ハードディスク・ドライブ（例えば、固定ディスク４４）、光学ドライブ（例えば、CD-ROMドライブ４０）、フロッピー・ディスク装置３６、若しくはその他の記憶メディア等のコンピュータによる読出しが可能なメディアを介して記憶及びアクセスがなされる。更に、ネットワーク・モデム４７若しくはインタフェース４８を介してアクセスがなされる場合には、アプリケーションは、アプリケーション及びデータ通信技法によって変調された電子信号の形態であってもよい。

ストレージ・インタフェース３４は、コンピュータ・システム１０のその他のストレージ・インタフェースと同様に、固定ディスク・ドライブ４４等の標準的なコンピュータによる読出し可能なメディアに接続して、情報を記憶及び／又は読出しすることが可能である。固定ディスク・ドライブ４４は、コンピュータ・システム１０の一部であってもよいし、若しくは分離していて別のインタフェース・システムを通してアクセスがされてもよい。シリアル・ポート２８を介してバス１２に接続されたマウス４６、シリアル・ポート３０を介してバス１２に接続されたモデム４７、及びバス１２に直接接続されているネットワーク・インタフェース４８等のように、その他の装置が多数、接続されてよい。モデム４７によって、電話リンクを介したリモート・サーバへの直接的な接続、若しくはインタネット・サービス・プロバイダ（ISP）を介したインターネットへの直接的な接続が提供され得る。ネットワーク・インタフェース４８によって、POP（point of presence）を用いたインターネットへの直接的なネットワーク・リンクを介して、リモート・サーバへの直接的な接続が提供され得る。ネットワーク・インタフェース４８は、デジタル携帯電話接続、セルラー・デジタル・パケット・データ（CDPD）接続、デジタル衛星データ接続、若しくは同様のものを含む、無線技法を利用してそのような接続を提供することが可能である。

多数のその他のデバイス若しくはサブシステム（図示せず）が同様の方法で接続されてよい（例えば、バーコード・リーダ、ドキュメント・スキャナ、デジタル・カメラ等）。逆に言えば、本発明を実施するのに、図６に図示されている全てのデバイスが存在している必要はない。図６に示されているようなコンピュータ・システムの動作は、当技術分野では公知であり、本願ではその詳細を説明しない。本発明を実行するためのコードは、1以上のシステム・メモリ１６、固定ディスク４４、CD−ROM４２、若しくはフロッピー・ディスク３８等のコンピュータ読出し可能メディア内に記憶されてよい。更に、コンピュータ・システム１０は、任意の種類のコンピューティング装置であってもよく、パーソナル・データ支援（PDA）、ネットアプライアンス、Xウィンドウ端末若しくはその他のコンピューティング装置等が含まれる。コンピューティング装置上に提供されたオペレーティング・システム１０は、MS−DOS（登録商標）、MS−WINDOWS（登録商標）、OS／2（登録商標）、UNIX（登録商標）、Linux（登録商標）、若しくはその他の公知のオペレーティング・システムであってよい。更に、コンピュータ・システム１０は、例えば、Netscape Navigator（登録商標）3.0、Microsoft Explorer（登録商標）3.0等のJavaスクリプト・インタラプタを備えたHTTP準拠webブラウザを含む、多数のインターネット・アクセス・ツールをサポートしている。

更に、本明細書で説明されている信号に関して、当業者は、信号が第1ブロックから第2ブロックに直接的に転送されてもよいし、若しくは信号はブロックの間で変調（例えば、増幅、減衰、遅延、ラッチ、バッファ、反転、フィルタ、若しくはその他の変調）がなされてもよいことを理解するであろう。上述の実施例での信号は、1つのブロックから次のブロックに転送されるように特性が記述されているが、本発明の別の実施例では、信号の情報的な性状及び／又は機能的な性状がブロック間を転送される限りにおいては、そのような直接的な信号の転送の代わりに変調された信号が含まれてよい。第2ブロックでの信号入力は、含まれる回路の物理的な制限（例えば、回避不能な多少の減衰及び遅延等）に起因して、第1ブロックからの第1信号出力から生じる第2信号として、ある程度まではみなすことができる。それゆえに、ここで用いているように、第1信号から生じる第2信号は、第1信号を多少変化させたもの（回路の制限に起因するか、若しくは第１信号の情報的な性状及び／又は機能的な性状を変更しないその他の回路素子の通過に起因する）若しくは第1信号そのものを含んでいる。

前記では、種々の構成要素が別の種々の構成要素（例えば、コンピュータ・システム１０の構成要素として示されている種々の要素）の内部に含まれる実施例が説明された。そのようにして示されたアーキテクチャは、単に例にすぎず、同様の機能性を達成するその他多数のアーキテクチャによっても実施可能である点を理解されたい。要約して、且つ意味を明確にすると、同一の機能性を達成するための構成要素の任意の配置が効果的に「関連付け」られて、それにより、所望の機能性が達成される。それゆえに、特定の機能性を達成するように、本明細書で結び付けられている任意の2つの構成要素は、アーキテクチャ若しくは中間の構成要素には関わりなく、互いに「関連付け」られて、それにより所望の機能性が達成される。同様にして、そのように関連付けられた任意の2つの構成要素は、所望の機能性を達成するように、互いに「機能的に接続」されている、若しくは「機能的に結合」されていると見なすことができる。

図７は、ネットワーク５０が示されているブロック図であり、そこでは、コンピュータ・システム１０がインターネット６０に接続されており、インターネット６０がクライアント・システム７０及び８０、及びサーバ９０に接続されている。更に、インターネット６０（例えば、インターネット（the Internet））によって、クライアント・システム７０及び８０と、サーバ９０とを互いに接続することが可能である。コンピュータ・システム１０に関して、コンピュータ・システム１０からインターネット６０への接続性を提供するのに、モデム４７、ネットワーク・インタフェース４８、若しくはその他の何らかの方法が用いられてよい。コンピュータ・システム１０、クライアント・システム７０、及びクライアント・システム８０は、例えば、webブラウザ（図示せず）等を利用してサーバ９０上の情報にアクセスすることが可能である。そのようなwebブラウザは、クライアント・システム７０及び８０と同様に、コンピュータ・システム１０が、サーバ９０をホストとするwebサイト・ページを表現する、サーバ９０上のデータにアクセスするのを可能にする。インターネットを介したデータ交換に関するプロトコルは当業者には公知である。図７では、データ交換に関するインターネットの利用が示されているが、本発明は、インターネット若しくは何らかの特定のネットワーク・ベースの環境に制限されるものではない。

図１、図２、及び図３を参照すると、コンピュータ・システム１０上で実行されるブラウザは、例えば、HTTP「サービス」（例えば、WINDOWS（登録商標）オペレーティング・システムの下で）若しくは「デーモン」（例えば、UNIX（登録商標）オペレーティング・システムの下で）を実行可能なサーバ４０に要求を渡すのにTCP／IP接続を利用している。そのような要求は、例えば、HTTPサーバとクライアント・コンピュータとの間で通信を行うのに用いることが可能なプロトコルを利用しているHTTPサーバとコンタクトをとることによって処理し得る。次に、このHTTPサーバは、通常、「webページ」をHTMLファイル形式で送信することによって、そのプロトコルに応答する。ブラウザは、そのHTMLファイルを翻訳して、ローカル・リソース（例えば、フォント及び色）を利用して、そのHTMLファイルの視覚的表現を形成し得る。

前述の説明では、ブロック図、フローチャート、及び例示の使用を介して、本発明の種々の実施例が示されてきた。当業者には、各ブロック図の構成要素、フローチャートのステップ、並びに例を用いて図示された動作及び／又は構成要素が、多種多様のハードウェア、ソフトウェア、ファームウェア、若しくはそれらを任意に組合わせたものを用いて個別に且つ／又は集団で実行され得ることを理解するであろう。

本発明は、完全な機能を有するコンピュータ・システムに関して説明されてきたが、当業者は、本発明が、種々の形態でプログラム製品として配布可能であり、本発明が、実際に配布を実行するのに用いられる特定の種類の単一ベアリング・メディアとは無関係に等しく適用されることを理解するであろう。単一ベアリング・メディアの例には、フロッピー・ディスク及びCD−ROM等の記録可能型メディア、デジタル及びアナログの通信リンク等の転送型メディア、並びに将来的に開発されるメディア記憶装置及び配信システムが含まれる。

上述の説明は、本発明の例示が目的であり、制限することを意図したものではない。本発明の範疇に入る別の実施例も可能である。当業者は、本明細書に開示されている構成及び方法を提供するのに必要なステップを容易に実施することが可能であろう。又、当業者は、プロセスのパラメータ及びステップの手順が、例示のみを目的として提供されており、本発明の範疇内で所望の構成を達成するように変更及び修正がなされてもよいことを理解するであろう。本明細書に開示されている実施例の変更及び修正は、付随の請求項に記載されている本発明の精神及び範疇から外れずに、本明細書で示されている説明に基づいてなされてよい。

図１−Ａは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。 図１−Ｂは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。 図１−Ｃは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。 図１−Ｄは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの一実施例の線図である。 図１−Ｅは、種々のメディア形式から成る複数の通信チャネルを介して、エージェントがサポート要求及び／又は情報要求に応答することが可能であり、且つそのスケジューリングが可能であるシステムの別実施例の線図である。 図１−Ｆは、通信アプリケーション・プログラミング・インターフェースの実装において含まれる構成要素の線図である。 図１−Ｇは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。 図１−Ｈは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。 図１−Ｉは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。 図１−Ｊは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。 図１−Ｋは、通信アプリケーション・プログラミング・インターフェースの別の実装において含まれる構成要素の線図である。 図２は、図１−Ａ乃至図１−Ｋのシステムに対するデータベース・スキーマの一例である。 図２−ａは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｂは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｃは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｄは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｅは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｆは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｇは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｈは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｉは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｊは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｋは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｌは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｍは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｎは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｏは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｐは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｑは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｒは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｓは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｔは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｕは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｖは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｗは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｘは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｙは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｚは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ａａは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｂｂは、図２でのテーブル名に対応するテーブルの例を示している。 図２−ｃｃは、図２でのテーブル名に対応するテーブルの例を示している。 図３は、本発明による汎用キューイング・システムの一実施例を示している。 図４−ａは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｂは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｃは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｄは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｅは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｆは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｇは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｈは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｉは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｊは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｋは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｌは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｍは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｎは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｏは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図４−ｐは、本発明による汎用キューイング・データベース内のテーブルの例を示している。 図５は、本発明の実施例に従ってエージェントを利用可能にして、且つスケジューリング可能にするシステムを実施し得るネットワーク環境が図示されているブロック図である。 図６は、本発明の実施例を実施するのに適切なコンピュータ・システムが図示されているブロック図である。 図７は、図６のコンピュータ・システムとクライアント及びホスト・システムとの相互接続が図示されているブロック図である。

Claims (23)

1. モジュール間通信のための方法であって、
   各々が１つ以上のメディア形式による通信をサポートする複数のチャネルドライバのうちの第１チャネルドライバと、マルチチャネル・マルチメディア・通信キューイング・システムと通信するように構成された通信サーバとが、通信するステップを含み、前記通信サーバはコマンド定義を用いるように構成されており、前記第１チャネルドライバは、第１メディア形式としてのファクシミリを送信するように構成された第１通信チャネルに結合されており、
   前記複数のチャネルドライバのうちの第２チャネルドライバと、前記通信サーバとが、通信するステップを含み、前記第２チャネルドライバは、第２メディア形式としての電子メールを送信するように構成された第２通信チャネルに結合されており、前記コマンド定義は、前記マルチチャネル・マルチメディア・通信キューイング・システムとインターフェイスするためのコマンドを含み、当該コマンドは、前記第１および第２通信チャネルの第１および第２メディア形式とはそれぞれ独立であり、前記第１および第２メディア形式は互いに異なり、
   前記第１メディア形式による通信と前記第２メディア形式による通信とは、同一のチャネルドライバによってサポートされている、方法。
2. 各々が１つ以上のメディア形式による通信をサポートする複数のチャネルドライバのうちの第１チャネルドライバが通信サーバと通信するステップを含み、前記第１チャネルドライバは、第１メディア形式としてのファクシミリを送信するための第１通信装置とインターフェイスするように動作可能であり、
   前記複数のチャネルドライバのうちの第２チャネルドライバが前記通信サーバと通信するステップを含み、前記第２チャネルドライバは、第２メディア形式としての電子メールを送信するための第２通信装置とインターフェイスするように動作可能であり、前記第１および第２メディア形式は互いに異なり、
   前記通信サーバが、前記第１チャネルドライバと前記通信サーバとの間の、および、前記第２チャネルドライバと前記通信サーバとの間の通信をサポートするためのコマンド定義を用いるステップを含み、前記コマンド定義は、前記第１および第２チャネルドライバと前記通信サーバとをインターフェイスするためのコマンドを含み、前記コマンドは、前記第１および前記第２メディア形式から独立しており、
   前記第１メディア形式による通信と前記第２メディア形式による通信とは、同一のチャネルドライバによってサポートされている、方法。
3. 更に、前記通信サーバが、メディア形式リストを要求するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
4. 更に、前記通信サーバが、コマンド・イベント・リストを要求するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
5. 更に、前記通信サーバが、ドライバ・オブジェクトを生成するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
6. 更に、前記通信サーバが、サービス・オブジェクトを要求するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
7. 更に、前記通信サーバが、ドライバ・オブジェクトを解放するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
8. 更に、前記通信サーバが、イベント処理完了時に通知を発行するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
9. 更に、前記通信サーバが、ワーク・アイテムを保留にするためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
10. 更に、前記通信サーバが、ワーク・アイテムを再開するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
11. 更に、前記通信サーバが、キューイングされたイベントを処理するためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
12. 更に、前記通信サーバが、キューイングされたイベントを取消すためのコマンドを呼出すステップを有する、請求項１または２に記載の方法。
13. 更に、前記通信サーバが、キューイング・システムとのインタフェースをとるステップを有する、請求項１または２に記載の方法。
14. 更に、キューイング・システムが、通信サーバを検知するステップを有する、請求項１または２に記載の方法。
15. 更に、前記通信サーバが、第１または第２通信装置からの入力イベントを検知するステップを有する、請求項２に記載の方法。
16. 更に、前記通信サーバが、前記第１または第２通信チャネルからの入力イベントを検知するようにタスク・スレッドのインスタンスを生成するステップを有する、請求項１に記載の方法。
17. 更に、前記通信サーバが、前記第１または第２通信装置からの入力イベントを検知するようにタスク・スレッドのインスタンスを生成するステップを有する、請求項２に記載の方法。
18. 更に、
    前記通信サーバが、前記第１または第２通信チャネルからの入力イベントを検知するステップと、
    前記通信サーバが、前記イベントを処理するための関数を呼出すステップとを有する、請求項１に記載の方法。
19. 更に、
    前記第１または第２通信装置のうちの１つからの入力イベントを検知するステップと、
    前記イベントを処理するための関数を呼出すステップとを有する、請求項２に記載の方法。
20. 更に、前記通信サーバが、前記イベントをメモリ・キャッシュにキューイングするステップを有する、請求項１８または１９に記載の方法。
21. 更に、前記通信サーバが、前記イベントの到着を指摘するステップを有する、請求項２０に記載の方法。
22. 更に、前記通信サーバが、前記イベントを前記メモリ・キャッシュからデキューイングして、前記イベントを処理するステップを有する、請求項２１に記載の方法。
23. 請求項１〜２２のいずれかに記載の方法を実現するためのコンピュータ命令を含む、コンピュータ読み取り可能な記録媒体。

Images