JPH10507330A - 電話呼出しビジネス情報を交換するために複数のコンピュータをインターフェース接続する方法及び装置 - Google Patents

Abstract

(57)【要約】 一方のコンピュータが複数の電話エージェントをサービスするコンピュータ化された構内交換機（ＣＢＸ）に接続されておりかつ他方のコンピュータがＣＢＸに関する電話コール統計量を含んでいるという２つのコンピュータ間で電話コール情報を交換するための装置および方法が提案される。それぞれが、１つの電話エージェントを電話コールからのセールス値のようなビジネス値日付に関連付ける情報を含んでいるビジネス値レコードが第１のコンピュータにおいて生成されかつデータベースに記憶するために第２のコンピュータに伝送される。同様に、それぞれが、１つの電話エージェントを特定の電話コールの特性を指示するアカウントコードに関連付ける情報を含んでいるアカウントコードレコードが第１のコンピュータにおいて生成されかつ第２のコンピュータに伝送される。それぞれが、特定の電話コールセグメントに関連付けられた情報を含んでいるコールセグメントレコードも第１のコンピュータにおいて生成されかつ第２のコンピュータにおいて伝送される。第２のコンピュータは、伝送されたビジネス値、アカウントコードおよびコールセグメントレコードを受信し、これらをデータベースに記憶し、かつビジネス値、アカウントコードを固定の時間間隔および１つの又は複数の組織的階層に従って複数のレコードに亘って累積する。累積された値から使用可能なレポートを作成するためのレポートジェネレータが設けられている。

Description

【発明の詳細な説明】 電話呼出しビジネス情報を交換するために複数のコンピュータをインターフェ ース接続する方法及び装置 本発明は内容的には、米国特許出願第０８/３１８３１７号明細書に記載の“P BX DATA RETRIEVAL AND REPORTING SYSTEM AND METHOD”にも関係する。 発明の背景 1.発明の属する分野 本発明は、基本的には電話構内交換設備に関しており、詳細には１つ又は複数 のＰＢＸからの情報をそれぞれ受信できる２つのコンピュータの間での電話呼出 しに関する“ビジネス”情報交換のための装置及び方法に関する。 2.関係する情報 構内交換設備（ＰＢＸ）とは、多数の内線電話を必要する事業所において使用 される、外線から内線への電話呼出しのルーティングのための交換設備である。 単一形ＰＢＸは公衆電話網の交換局に接続され、多重形のＰＢＸは多数の電話回 線を一括して取り扱うために結び付けられている。 技術的に改善されて、ＰＢＸは、自動的に、電話コールを使用可能なエージェ ントにルーチングし、かつ各コールの持続時間のようなコール情報をモニタする ためにコンピュータ化色およびデータ記憶ファシリティーを使用して一層複雑に なっている。そのようなＰＢＸは、交換容量の低い設備と区別するために、いわ ゆるコンピュータ化構内交換設備（ＣＢＸ）とも称される。例えばこのＣＢＸは 数十または数百の航空機予約エージェントを使用している航空機予約システムな どで使用される。この場合ＣＢＸは、フリーダイヤルに対して行われた着信コー ルを対応可能なエージェントへルーティングする。エージェントは着信コールに サービスしようとする電話機からのログオンＩＤの入力によってＣＢＸへログオ ンできる。 例えば従来のＣＢＸの例では、モデル３０と８０を含んだ“ROLM 9751 family of CBXs”が挙げられる。このＣＢＸでは、過去の各発呼（コールと簡単に表す こともある）のルーティング（電話回線）、各発呼の持続時間、発呼に対する応 答前の所要時間の長さなどに関する情報が自動的に記憶可能である。これらの情 報（これらは所定の時間周期にわたって、例えば毎１５分単位で、ＣＢＸ内部に 記憶され累積されている）は、予めフォーマットされたデータレポートを使用す る管理者によって検索と監視が可能である。予めフォーマットされたデータレポ ートに基づけば、管理者は着呼負荷における変化にために要員変更を行うことが できる。 図１ａは、従来式の発呼者レコードとビジネスデー タベースと電話呼出し情報の組合せ構成を示した図である。図１ａでは第１のエ ージェント０６が、例えば航空機の予約又はカタログオーダ等の着呼を扱うため に第１の電話０４と第１のコンピュータ端末０８を操作する。第１の電話０４は 第１のＣＢＸ０２に接続される。この第１のＣＢＸ０２は、例えばＩＢＭ等の各 種メインフレームモデルのコンピュータ０１に接続される。第１の端末０８もメ インフレームコンピュータ１にレコードディスプレイ発生器１２とデータエント リプログラム１３を介して接続される。同じような接続は、第２のエージェント ０７に対して、第２の電話０５と第２のＣＢＸ０３と第２のコンピュータ端末０ ９との間で形成される。ＣＢＸ０２は例えばＣＢＸによって保持されているエー ジェント毎の費やされた会話平均時間等の所定の統計情報を収集して表示するた めに選択的にＰＣ１５に接続される。ＣＢＸ０３も自身のＰＣ１６に同じような 目的で接続される。 動作中において着呼は、ＣＢＸ０２によって電話０４にルート形成される。電 話コールが着信したとき、呼出し経過として、種々の「コールイベント」メッセ ージが自動的にＣＢＸ０２によってコンピュータ０１へ伝送される。コールイベ ントには例えば発呼者の電話番号や応答者等の特有の情報が含まれている。コー ルイベント（新しい呼出し、呼出し転送、呼出し継続等）はメインフレームコン ピュータ０１のイベントハ ンドラ１７に供給される。このイベントハンドラ１７はイベントをイベントログ １８にログし、新たなコールイベントを発呼者ルックアップ機能部１０へ配信す る。この発呼者ルックアップ機能部１０は、発呼者データベース１１を発呼者に 関する対応情報（例えばこの発呼者のアカウント情報、最新トランザクション、 メディカルレコード等）について検索する。発呼者データベース１１からの検索 によって発呼者ルックアップ機能部１０は、発呼者情報をレコードディスプレイ 発生器１２へ伝送する。このレコードディスプレイ発生器１２はディスプレイ情 報を形成し、それを端末０８に伝送してエージェント６によって見られるように する。それによりエージェントは、端末８を介して表示される発呼者に関する周 知の特有情報を踏まえて発呼者と電話０４で通話可能である。発呼者がカタログ オーダのプレーシングやエージェントからの他のサービスを要求した場合には、 エージェント０６はデータエントリプログラム１３を介して端末０８上のそのよ うな情報を入力することができる。発呼者から供給された新たな情報（クレジッ トカード情報の伴うカタログオーダ等）は、ビジネスデータベース１４内へ記憶 される。発呼者データベース１１が発呼者に関する何らかの従来情報（発呼者住 所、社会的なセキュリティーナンバ等）を含んでいない場合には、発呼者から供 給された情報に基づいて新たな情報が発呼者データベ ース１１に記憶される。図１ａ中の右側に示されている構成要素も別のエージェ ント０７によって左側に示されている構成要素と同じように動作する。 図１ａに示されている従来の構成では、セールスやビジネスデータベース１４ 内に記憶されている他のビジネス情報と、各エージェント毎又はエージェントグ ループ毎の業務統計とを相関付けることが困難である。例えば１つのエージェン トグループによってある電話での平均通話時間量とこのグループによって行われ たビジネス量との相関付けも困難である。なぜならメインフレームのコールイベ ント情報には、そのようなグループに関する情報が含まれていないからである。 ＣＢＸ０２及び０３内に保持されたその他の多数の統計データをメインフレーム コンピュータ０１に保持されているビジネス情報又は他の組織情報と相関付けす るための機構は存在していない。 例えば１つのエージェントグループに属する特定のカタログ部門によってなさ れた平均セールス量や、あるいは特定の期間における特定のエージェント毎の成 約した保険証券の平均数を自動的に識別することは望ましい。たとえ各ＣＢＸ内 へ記憶されている確かな統計データ（例えばエージェント毎の通話毎の平均通話 時間等）が各ＣＢＸからメインフレームコンピュータ０１へ直接伝送されていた としても、エージェント毎の多重ログオン識別子、ＣＢＸ間を移動する複数のエ ージェント、異なる組織階層に属する複数のエージェント、複数のエージェント グループに亘る統計データの保持等に関して問題が残される。さらにメインフレ ームコンピュータ０１は、付加的なデータ収集や記憶タスクによって動きがとれ なくなり、該コンピュータにて実行中のその他のアプリケーション速度が遅くな る。パーソナルコンピュータ１５と１６には既に局部的に所定量のＣＢＸ統計情 報が供給され、そのような機能をメインフレームコンピュータ１において反復す ることは浪費と場合によって重複につながる。従って図１ａに示されている装置 構成では所期の情報の簡単な相関付けは不可能である。 すなわち、収集された情報を相互参照するレポートを作成するために、１つ又 は複数のＣＢＸによって累積された電話起呼統計データと、１つのコンピュータ 上に通常記憶される「ビジネス」関連情報とを結合させることは満足されない要 求だった。例えば特定のセールスエージェント毎の平均通話量と、エージェント による販売成約量とを相関付けることは望ましいが、これらの２つのタイプの情 報は通例は別個のコンピュータに保持されかつ実質的に異なって編成されるので 、このようなことはこれまでにおいては困難であった。 発明の概要 上述の要求を満足するために、本発明は、１つ又は 複数のＣＢＸに接続されている第１コンピュータを同じ１つ又は複数のＣＢＸに 接続することもできる第２のコンピュータにインタフェース接続するための装置 および方法を提供するものである。ただしこの場合第１コンピュータは特定のエ ージェントトランザクションに関連する「ビジネス値」情報を記憶し、かつ第２ のコンピュータは自動的に、１つ又は複数のＣＢＸから通話統計データもしくは 統計量を収集しかつそこから効果的なレポートを作成する。本発明の種々の実施 例によれば、「ビジネス値」情報の種々の一定量（piece）がリンクを介して第 １のコンピュータから第２のコンピュータに伝送され、ここでデータは累積され かつＣＢＸから収集された関連情報と一緒に記憶される。その後、ユーザカスタ マイズドデータレポートを作成することができ、これにより組み合わされたデー タは相関付けられるようになる。 図面の簡単な説明 本発明の種々様々な対象、特徴および得られる利点は、添付図面に関連して考 察されて、本発明の以下の詳細な説明を参照して同じことが一層よく理解される ことになるとき一層完全に明らかになることであろう。図面中、 図１（ａ）は、従来の構成の概略図であり、該構成ではメインフレームコンピュ ータが１つ又は複数のＣＢＸとインタフェース接続されており、 図１（ｂ）は、従来のＣＢＸの構成の概略図であり、 図２は、本発明の種々の原理を使用した構成要素をブロック線図の形において示 す図であり、 図３は、本発明の実施例による、２つのＣＢＸおよび１つのメインコンピュータ 間でデータベースをどのように編成することができるかを示す概略図であり、 図４は、本発明の実施例による、種々のＣＢＸからデータベーススキーマ情報を どのように収集するすることができるかを示すフローチャートであり、 図５は、本発明の実施例による、複数のＣＢＸから通話データをどのように収集 するすることができるかを示すフローチャートであり、 図６は、本発明の実施例による、ユーザが収集スケジュールをエントリできるよ うにするための１つの可能なスクリーンレイアウトを示す略図であり、 図７は、本発明の実施例による、図２のデータ収集装置２１５を具体化する１つ の可能な手法を示す略図であり、 図８は、本発明の実施例による、通話統計量を各ＣＢＸにおいて認識されるグル ープ分けを超えた階層的手法で累積する１例を示す略図であり、 図９は、本発明の実施例による、組織編成を創成しかつ修正するために使用する ことができるコンピュータスクリーンの１例を示す略図であり、 図１０は、本発明の実施例による、従業員情報をエン トリするために使用することができるコンピュータスクリーンの１例を示す略図 であり、 図１１は、本発明の実施例による、組織および時間ベース統計量をデータベース １１０４におけるデータレコードにどのように累積することができるかの１例を 示す略図であり、 図１２は、本発明の実施例による、種々のレポート作成特性の１つの具体化例を 示す略図であり、 図１３は、本発明の種々の原理に従って作成されるレポートの１例を示す略図で あり、 図１４は、本発明の実施例による、ユーザが特定のレポートに対して列のレイア ウトを編集することができるようにするためのスクリーンレイアウトの１例を示 す略図であり、 図１５は、本発明の実施例による、ユーザがレポートの１つの列に対してデータ 形式およびエレメントを特定することができるようにするためのスクリーンレイ アウトの１例を示す略図であり、 図１６は、本発明の実施例による、ユーザがレポートにおける表示に対して組織 メンバーを選択することができるようにするためのスクリーンレイアウトの１例 を示す略図であり、 図１７は、本発明の実施例による、レポートの各行に対する時間間隔を含んでい る、レポートにおけるデータ詳細を特定するためのスクリーンレイアウトの１例 を示す略図であり、 図１８は、本発明の実施例による、レポートにおけるデータ判断基準を特定する ためのスクリーンレイアウトの１例を示す略図であり、 図１９は、第１のコンピュータを第２のコンピュータにインタフェース接続する ための本発明の原理をどのように具体化することができるかを示す略図であり、 ここでは第１のコンピュータおよび第２のコンピュータは別個に１つ又は複数の ＣＢＸにインタフェース接続されており、 図２０は、コールセグメント情報を図１９のコンピュータ１９０１からコンピュ ータ１９２７に伝送するための１つの可能なレコードフォーマットを示す略図で あり、 図２１は、ビジネス値情報を図１９のコンピュータ１９０１からコンピュータ１ ９２７に伝送するための１つの可能なレコードフォーマットを示す略図であり、 図２２は、課金コード情報を図１９のコンピュータ１９０１からコンピュータ１ ９２７に伝送するための１つの可能なレコードフォーマットを示す略図である。 詳細な説明 本発明は、図１９において簡単化された形において１例が示されている、イン タフェース接続方法および装置を提供するものである。しかし、本発明の範囲を 完全に明確にするために、データを種々のＣＢＸから どのように収集し、有効な方法で累積し、かつそこからレポートをどのように作 成するかについて一層詳細に説明することが必要である。この観点において、以 下の段落Ｉ（および図１（ｂ）ないし１８）ではこのような詳細が説明される。 Ｉ．ＣＢＸからのデータ収集およびレポート作成 図１ｂは、従来のＣＢＸ構成を簡単に示す。このＣＢＸは例えばＲＯＬＭ９７ ５１ファミリーの装置を有することができる。ＣＢＸ１０１は複数の入力ライン Ｌ１〜Ｌ４を受信し、これに接続された複数の電話Ｐ１〜Ｐ６を交換サービスす るための手段を有する。電話Ｐ１〜Ｐ６は自動コール分散の目的のため２つの群 Ｇ１とＧ２に分けられている。図１には単に少数の電話線しか説明のために示さ れていないが、これら電話線の数十倍を１つのＣＢＸで取り扱うのが適当である 。ＣＢＸ１０１は第１のＣＰＵ１０２を有する。このＣＰＵは、入り線からのコ ールを受信し、各コールを適切な電話線にルーティングするためのスイッチング ・ハードウェア１０３を制御するためのものである。このことは公知の基準、例 えばグループ内の最初の有用線を選択するようにして行われる。 第１のＣＰＵ１０２は第２のＣＰＵ１０４と接続されておりこれと情報交換す る。これは、コール情報、例えば各コールの開始時間と終了時間を転送するため である。ＣＰＵ１０４は、コール・バイ・コールベー スに基づいてこのようなコール情報を収集し、若干の情報を記憶し（所定機関で のすべてのコールに対する通話時間）、これを後で再生するためにディスク１０ ５に保存する。ＣＢＸ１０１はまた複数のＰＣ１０７および１０８とシリアルポ ート１０６を介して接続されている。少なくとも１つのＰＣはプリンタ１０９と 、ＰＣに表示された種々のリポートをプリント出力するために接続されている。 付加的にプリンタは直接、シリアルポート、例えば要素１０６に接続することが できる。 ＣＰＵ１０２とＣＰＵ１０４は両方とも適切なマイクロプロセッサと適切なオ ペレーティングシステムを有することができる。実施例ではＩｎｔｅｌ社のマイ クロプロセッサファミリー80486が使用され、SCO UNIXがオペレーティングシス テムとして使用される。 動作中、管理者は各ＰＣ１０７と１０８を操作し、ＣＰＵ１０４により収集さ れたコール情報、例えば単位時間当たりのコールの総数、電話群あたりのコール 総数等を監視する。管理者はコマンドを各ＰＣから入力し、このコマンドはシリ アルポート１０６からＣＰＵ１０４に転送され、第２のＣＰＵ１０４のコンピュ ータプログラム（図示せず）はコール情報をそのメモリおよび／又はディスク１ ０５から再生し、所定のフォーマットデータを、要求しているＰＣに表示のため に転送する。データは数日間、ディスク１０５に保存 され、典型的には「ローリング」タイムベースで自動的に削除される。 操作の概観 図２には、本発明の種々の原理を使用している１実施形態が示されている。第 １図のＣＢＸ２０１ａおよび第２のＣＢＸ２０１ｂは図１のＣＢＸ１０１に相応 するものである。しかし、ソフトウェアモジュール２１０ａおよび２１０ｂが付 加されている点で相異しており、これらモジュールは、以下に一層詳細に説明す るように収集コンピュータ２１４から生成されるコマンドを保存するためのデー タサーバとして動作する。各ＣＢＸは収集コンピュータ２１４（これは例えば、 ＩＢＭＲＳ／６０００ＲＩＳＣプロセッサから構成することができる）にそれぞ れシリアルラインＳ１およびＳ２を介して接続されている。第１のＣＢＸ２０１ ａはシリアルポート２０６ａを介して収集コンピュータ２１４に直接接続されて おり、一方第２のＣＢＸ２０１ｂはモデム２１１および２１２を介しておよび最 終的にはシリアルポート２０６ｂを通って接続されており、その際第２のＣＢＸ ２０１ｂは第１のＣＢＸ２０１ａから別の物理的な場所に配設することができる 。種々の実施例において、ＣＢＸと収集コンピュータ２１４との間の直接接続の ために、１９．２Ｋｂａｕｄのデータ伝送レートを使用することができ、一方モ デム接続に対して、９６００ｂａｕｄのレートを使用 することができる。図２には２つのＣＢＸ（例えば２０１ａおよび２０６ｂ）し か示されていないが、２より多くのＣＢＸを直接か又はモデムを介して収集コン ピュータ２１４に接続することができることは明かである。さらに、ＣＢＸは収 集コンピュータ２１４に、ラインドライバ、ローカルデータライン、データ通信 インタフェース（data communication interface＝ＤＣＩ）、ローカルエリアネ ットワーク、ワイドエリアネットワーク又は類似のものを有する仮想のいずれか の通信模式を介して接続することができる。 図１に示されているＰＣ１０７および１０８のようなＰＣも、図２のＣＢＸの 第１の２０１ａおよび第２の２０６ｂに接続することができる。 収集コンピュータ２１４は、種々の実施例において、データ収集装置２１５、 ユーザインタフェース２１６、レポート発ジェネレータ２１７およびデータベー ス２１８を有している。ユーザ端末Ｔはユーザがこの装置を制御することができ るようにするためにユーザインタフェース２１６に接続されている。データサー バ２１０ａおよび２１０ｂ（ＣＢＸ２０１ａおよび２０６ｂ内に図示されている ）はデータ収集装置２１５と以下に説明する方法で対話する。 データ収集装置２１５は、ユーザ定義スケジュールに従って周期的なベースに 基づいて１つ又は複数のＣＢＸから統計および構成情報を収集する。ユーザが一 旦収集スケジュールをセットアップすると、別のユーザ介入は要求されない。要 するに、データ収集装置２１５は、各ＣＢＸに対して「ログ・イン」しかつ特定 の時間間隔の間統計量を収集する。各データサーバ２１０はデータ収集装置２１ ５によって要求された情報をそのデータベース（ディスク２０５上に記憶されて いる）から抽出しかつそれを、公知のＺｍｏｄｅｍプロトコルのような通信パッ ケージを使用してデータ収集装置２１５に伝送する。種々の実施例において、各 ＣＰＵ２０４ａおよび２０４ｂは、データ収集装置２１５がオペレーティングシ ステムに「ログ・イン」することができるようにするＵＮＩＸユーザ名およびパ スワードを含んでいるように構成されている。 各ＣＢＸからのデータ収集を実施するために、データ収集装置２１５は各ＣＰ Ｕに種々のコマンドを送信しかつそこから応答を受信することができる。種々の 実施例において、次の操作のためのコマンドを次のように設定することができる ： スキーマコマンド：特定のＣＢＸに対するデータベーススキーマに関する情報を 要求する システム情報コマンド：ＣＢＸシステム構成に関する情報を要求する オープンデータコマンド：ＣＢＸがアクセスのために特定のデータベースを開く ことを要求する 宛先ファイルコマンド：受信したデータを記憶すべき であるファイ名のＣＢＸを通報する オールドデートコマンド：ＣＢＸに記憶されている統計量データベースにおける いずれかのテーブルにおける最も古いエントリの日付／時間を要求する セレクトコマンド：特定の選択判断基準を満足する特定のデータベーステーブル からデータを要求する ログオン／ログオフコマンド：ＣＢＸデータサーバに対するログオン又はログオ フのためにデータ収集装置２１５によって使用される 上記コマンドの働きは、データ収集装置２１５と各データサーバ２１０との間 のデータ収集の働きとの関連において説明する。本発明の原理は、特別に上述し たものとは異なったコマンド又はメッセージを使用して交換を実施することがで きることは明かである。 Ｚｍｏｄｅｍ（それ自体のエラーチェックプロシージャを組み込んでいる）を 介してデータベースデータを伝送する目的以外は、データ収集装置２１５と各Ｃ ＢＸとの間のコマンド応答交換はリンクを介してチェックサム又は別のエラー検 出メカニズムを利用することを要求しないが、それに代わって、各キャラクタが 送信されたときにそれを検査するために各データサーバ２１０からの全２重エコ ーを利用することによってエラーを検出することができる。データ収集装置２１ ５が１つのキャラクタが駄目になっていることを検出するとき、データ収集装置 は当該ラインをキャンセル するために特定のデータサーバにコントロールＵキャラクタを送信し、かつそれ からこのコマンドを再送信する。データ収集装置２１５はいずれか単一のＣＢＸ に対して同時に１つ以上の未決のコマンドを送信することはできない。 各ディスク２０５ａおよび２０５ｂ上に記憶されている統計量の呼び出しは、 ＩＮＦＯＲＭＩＸ^TMのような関連のデータベースに記憶することができ、かつ収 集コンピュータ２１４におけるデータベース２１８は、関連のデータベース、有 利には、コンパチビリティの理由から各ＣＢＸにおけるものと同じ型のデータベ ースを有するようにすることもできる。作動中、各ＣＢＸはそのＣＢＸによって サービスされる電話線に対する通話情報を収集しかつ記憶する。ユーザ定義スケ ジュールに従って、データ収集装置２１５は、各ＣＢＸデータサーバ２１０から 記憶されたデータの間隔を収集しかつ収集されたデータを収集コンピュータ２１ ４におけるデータベース２１８に組み込み、データベース２１８に記憶されてい る付加的な情報に基づいてレポートを作成するために使用できるようにしておく 。データサーバ２１０ａおよび２１０ｂは、コンピュータ２１６から到来するデ ータベースコマンドを受信しかつこれらをその都度それ自体のデータベースに送 り、これらを各ディスク２０５ａおよび２０５ｂ上に記憶することができる。デ ータベース結果が各ディ スク２０５ａおよび２０５ｂ上に配置されている統計量データベースから戻され るとき、データサーバ２１０ａおよび２１０ｂは、結果をＺｍｏｄｅｍのような 通信パッケージを介して収集コンピュータ２１６に送り返す。 データベース構成（コンフィギュレーション） 次に各ＣＢＸ２０１ａおよび２０１ｂおよび収集コンピュータ２１４において 記憶されている種々のデータベースを図３を参照して説明する。図３において、 データベース３０１は、図２のＣＢＸ２０１ａ内に累積された電話データを記憶 し、一方データベース３０６は、図２のＣＢＸ２０１ｂ内に累積された電話デー タを記憶する。各データベース３０１および３０６はそれぞれ、ＣＢＸ２０１ａ および２０１ｂのディスク２０５ａおよび２０５ｂに記憶することができる。種 々の実施例において、各ＣＢＸデータベースは、多重デーブルから成っていてよ い構成データベースおよび統計量データベースを含んでいる。例えば、データベ ース３０１は、構成データベース３０５および統計量データベース３０２，３０ ３，および３０４を含んでいる。各統計量データベースは、複数のレコードを有 しており、各レコードは、所定の時間間隔（例えば図３では１５ｍｉｎとして図 示されている）を介して収集された通話情報を含んでいる。テーブルは必要に応 じて種々の方法で構成することができ、かつ勿論、或 るアプリケーションにおいては唯一のテーブルにすべての情報を記憶するように しても構わない。 相応に、データベース３０６（ＣＢＸ２０１ｂにおける）はそれ自体の構成デ ータベース３１０および統計量テーブル３０７，３０８，および３０９を有して いる。これら統計学テーブルのそれぞれは、１５ｍｉｎのような所定の時間間隔 にわたって収集された通話情報を含んでいる複数のレコードを有している。いず れか１つのＣＢＸにおけるテーブルのすべては、ＩＮＦＯＲＭＩＸ^TMのような同 じ関連データベースに記憶することができる。 一般的にいえば、各構成データベースは、グループ名、エージェント名および 識別子、エージェントの、グループに対する割り当て、各グループに対して使用 されるキューイング方法および類似のものに関する情報を含んでいてよい。この 情報は一般に、ＣＢＸ内のスイッチングハードウェアをエージェント、トランク 群、エージェントグループ毎のサービスレベルおよび類似のものに関連付ける。 各統計量テーブルは、テーブルが存在しているＣＢＸに対する通話情報に関す る情報を格納している。データベース３０１に関して、統計量テーブル３０２は 、電話線の各グループに対する情報を累積するレコードを含んでいることができ る。従って、テーブル３０２における各レコードは次のような情報を含んでいる ことができる： −電話線の１つの特定の群又は複数のグループに対する１５分時間間隔毎の電話 コールの合計数 −電話線の１つの特定のグループ又は複数のグループに対する放棄された電話コ ールの合計数 第２の統計量テーブル３０３は、次のような、ＣＢＸに接続されている各エー ジェントに対する情報を累積するレコードを含んでいることができる： −１５分時間間隔毎のエージェント毎の通話の合計時間量 −１５分時間間隔毎のオフネットワーク通話合計時間 さらに第３の統計量テーブル３０４は、次のような、各トランク群に対する情 報を累積するレコードを含んでいることができる： −１５分時間間隔毎にトランク線に到来するコールの合計 −１５分時間間隔毎のトランク線で応答されないコールの合計 類似のテーブルがデータベース３０６に設けられているが、それは第２のＣＢ Ｘ２１０ｂに関するものである。 データベース３０１および３０６における統計量テーブルは、それぞれ、デー タが各ＣＢＸにおいて累積されるように、ＣＰＵ２０４ａおよび２０４ｂによっ て規則的な時間間隔において更新される。所定の時間 間隔（１４日又は４２日のような）後、最も古い日付のものが、ＣＢＸにおける 記憶スペースを確保するために、「ローリング」ベースに基づいて自動的に削除 されるようにすることができる。 本発明のデータ収集原理に従って、データベース３０１および３０２からの選 択された情報を検索しかつ図２に示されている収集コンピュータ２１４に存在す るデータベース３１１に伝送することができる（従って図３のデータベース３１ １は図２のデータベース２１８のサブセットである）。図３に示されているよう に、データベース３０１からの統計量テーブル３０４の部分が（すなわち、ＣＢ Ｘ２０１ａから）、一連のスケジュール化されたデータ収集トランザクションの 後にデータベース３１２（データベース３１１の部分）におけるテーブル３１５ に検索されている。すなわち、データベース３０１においてデータが累積されて いくに従って、累積されたデータの部分を、同じフィールドを有しているデータ ベース３１２の統計量テーブルに自動的かつ選択的にコピーすることができるが 、或数のレコードは、累積されたデータに対する種々異なった時間長に相応して 、種々異なっている可能性がある。 データベース３１１に選択的に検索されたデータは、所望の方法でレポート作 成するために最適に構成されていないかもしれない。従って、データベース３１ １は付加的な統計量テーブル３１６，３１７および３１８を含んでおり、これら テーブルは、テーブル３１５のレコードに含まれている時間間隔より長い時間間 隔にわたって累積されたレコードを有している。例えば、テーブル３１６は、テ ーブル３１５に含まれている情報を使用して「シフト」（８時間シフトのような ）に基づいて情報を累積する。すなわち、各データ収集セッションの後、テーブ ル３１５からの複数のレコードにおける情報は累積されかつテーブル３１６にお けるレコードとして記憶される。相応に、丸一日を通して累積されたデータをテ ーブル３１７におけるレコードに記憶し、かつ丸一週間にわたり累積されたデー タをテーブル３１８におけるレコードに記憶することができる。このようにして 、データはただちに、データベース３１１における種々異なった時間間隔にわた りかつ各ＣＢＸにおいて記憶しておくことができるより概して長い期間の間使用 可能である。 相応に、データベース３０６からの２つの統計量テーブルからのデータは、図 ３の下部において図示されているように選択的かつ自動的にデータベース３１３ （データベース３１１の部分）にコピーされる。テーブル３０９からのデータは テーブル３２１にコピーされ、かつテーブル３０８からのデータは、テーブル３ ２０にコピーされる。さらに、テーブル３２１からのデータはテーブル３２２， ３２３および３２４におい て累積されており（週間、月間および年間）、一方テーブル３２０からのデータ はテーブル３２５および３２６において累積されており（日間および年間の累積 ）。従って、データベース３１３における各統計量テーブルに対して、１つ又は それ以上の付加的なデータベーステーブルをデータベース３１３に設けることが でき、それらは種々の時間間隔にわたって種々のフィールドおよびレコードを累 積する。テーブル３２５において図示されているように、各レコードは複数のフ ィールド（ａないしｅ）を含んでいることができ、各フィールドは特定の統計量 （例えばグループ毎のコール総数、エージェント毎の待ちに費やした平均時間、 等）に基づいた情報を保存する。図３はＣＢＸ２０１ａ（データベース３１２） およびＣＢＸ２０１ｂからのデータ間の種々の累積パターンを示しているが、種 々の実施例において、統一性を計りかつレポート作成を容易にするために各ＣＢ Ｘに対する同一の累積パターン（すなわち、各ＣＢＸに対するキープシフト、日 間、週間、月間および年間累積テーブル）を使用する方が一層適している可能性 がある。従って、データベース３１２および３１３間のテーブル構成の際は１つ の一例として示されているに過ぎない。 構成データベース３０５および３１０もデータベース３１１（それぞれデータ ベース３１４および３１９として）にコピーされるが、これらデータベースは一 般に、時々（例えば一日１回又はそれ以下）コピーされる必要があるだけである 。その理由は、構成情報はしばしばは変化しないからである。 さらに、別個の構成データベース３２７がデータベース３１１に記憶される。 その理由は後で明らかにする。とりわけ、この別個の構成データベースは、情報 を階層的な手法で累積するために使用される組織的階層を識別する情報を含んで いる。この構成データベースは別個に記憶されているように示されているが、こ の種の構成情報すべてを、必要とされる情報を分離するために適当なレコード識 別子を用いて同じ物理的なデータベースに記憶することは勿論、本発明の範囲内 にある。 スキーマおよびスキーマ互換性 各ＣＢＸは、場合によってはそれぞれ異なるデータベーススキーマを有してい る可能性があり、そのスキーマに従ってデータが格納されている（一般的にいえ ば、１つのスキーマはフィールドの定義、各レコードに格納されているデータの 形式、ならびにデータベースのテーブルへ入れられるレコードの編成である）。 本発明は、場合によってはそれぞれ異なるデータベーススキーマをもつ種々の ＣＢＸからのデータ収集に係わるものであり、次に、そのことについて詳細に説 明する。あるＣＢＸにおける特定のデータベーステーブルに対し１セットのフィ ールドがいったん定義され てしまえば、そのデータベーステーブルに加えられるいかなる新しいフィールド も、レコード終端に加えられることになる。このことによってデータ収集装置２ １５は、それら余分なフィールドがデータ収集装置データベースにおいてサポー トされていなければ、それらのフィールドを無視できるようになる。 図４には、データ収集装置２１５の動作に関するフローチャートが示されてい る。その際、このフローチャートは、各ＣＢＸ（例えば２０１ａおよび２０１ｂ ）に保持されているデータベース３０１，３０６と収集コンピュータ２１４に格 納されているデータベース３１１の間のスキーマ互換性を識別することに関して 示されている。データ収集装置２１５が最初に各ＣＢＸに対し”ログ・オン”を するとき、ＣＢＸに格納されているデータベーステーブルに関する情報を得るた めにスキーマコマンドを発行する（ステップ４０１）。コマンドの与えられたＣ ＢＸは、以下で述べるようなスキーマ情報（ステップ４０２）を送り戻す。 スキーマコマンドによってデータベースネームとテーブルネームを指定するこ とができる。スキーマコマンドは、データベーステーブルに関する情報を検索す るため、指定したデータベースをオープンする。コマンドの実行が成功すると、 有利には各ＣＢＸは（データサーバ２１０ａ，２１０ｂ経由で）、以下のスキー マ情報を戻すことになる： １．データベース、テーブルネーム ２．フィールドのバージョン、ナンバー ３．フィールドネーム１、フィールドネーム２、．．．、フィールドネームｎ ４．フィールドタイプ１、フィールドタイプ２、．．．、フィールドタイプｎ ５．フィールド長１、フィールド長２，．．．フィールド長ｎ 上述のフィールドは以下のよう定義される： データベース：データベースネーム（例えばコンフィギュレーション又は統計 量） テーブルネーム：指定されたデータベースにおいてリクエストされるテーブル ネーム バージョン：データベーススキーマのバージョンナンバー このバージョンナンバーは、１つの特定のデータバース内のすべてのテーブル に対し同じものである。データベーススキーマが変化すれば、バージョンナンバ ーも同様に変化する。 フィールドナンバー：データベーステーブル内のフィールドナンバー（つまり 欄のナンバー）。 フィールドネーム：指定されたデータベーステーブル内のフィールドネーム、 これはテーブルに格納された順序で リストされている。 フィールドタイプ：先行の行にリストアップされた各フィールドのデータタイ プ、これは公表されたデータベース仕様に対応するものがよい。 フィールド長：各フィールドのバイト長 ここで再び図４を参照すると、ステップ４０３においてデータ収集装置２１５ は、データベース３１１と、スキーマコマンドが与えられたＣＢＸにおけるデー タベースとの間の正確なスキーマ整合があるかについての判定を下す。この場合 、最初に、ＣＢＸデータベースとデータベース３１１におけるバージョンナンバ ーの比較に基づき判定がくだされ、次に、ＣＢＸから受信したスキーマ定義とデ ータベース３１１に格納されているスキーマ定義とが比較される（つまりテーブ ルごと、フィールドごとの比較）。各スキーマが正確に一致しているならばデー タ収集装置２１５は今後は、特定のＣＢＸから受信したデータの正確なコピーを データベース３１１に格納する（ステップ４０４）。各スキーマが正確に整合し ていなければデータ収集装置２１５は、リクエストしたＣＢＸデータベースのス キーマ（ＣＢＸスキーマ）がデータベース３１１のスキーマよりも多くのフィー ルドを有しているかの判定を下す。特定のＣＢＸスキーマがデータベース３１１ のスキーマよりも多くのフィールドを有していれば、 データ収集装置２１５は今後は、ＣＢＸから受信した各レコードの終端における 余分なフィールドを無視することになるが、その際、切り捨てられたレコードを データベース３１１へ付加すべきであることを表すフラグをセットし（ステップ ４０６）、無視されたデータに応じて警告メッセージをレコードする。 各スキーマが正確に整合しておらず、かつＣＢＸスキーマがデータベース３１ １よりも多くのフィールドを有していなければ、ステップ４０８において、ＣＢ Ｘスキーマがデータベース３１１よりも僅かなフィールドしか有していないと規 定する。このような状況ではデータ収集装置２１５は今後は、ＣＢＸからの”欠 けた”フィールドをデータベース３１１においてヌルにセットし、データベース ３１１中のヌルにされたフィールドに応じて警告メッセージをレコードすること になる（ステップ４１０）。 データ収集装置２１５は、各ＣＢＸからのシステム情報に対するリクエストを 発行することもできる。このリクエストに応じて、選択されたＣＢＸは種々の変 形実施形態において以下の情報を送り戻す。 −現在日時 −統計量データベーススキーマのバージョンナンバー −構成データベーススキーマのバージョンナンバー −データサーバ・コンピュータプログラムのバージョンナンバー 上述の動作によってデータ収集装置２１５は、様々なＣＢＸにわたる種々異な るデータベースバージョンで動作できるようになる。この特徴は、様々なＣＢＸ を１つのグループとしてではなく徐々にアップグレートするような場合に殊に有 用であるし、各ＣＢＸにわたるデータベースを段階的に変更することができる。 また、上述の動作を、１つのデータベーステーブル内のフィールドの固有の順序 が固有のＣＢＸ内で生じているかが判定されるよう、容易に拡張できる。 データ収集装置２１５は、単一のデータ収集セッションにおいて統計量情報と 構成情報を得ることができるし、あるいは単一のログ・オン・セッションで１つ の情報又は他の情報だけを得ることもできる。 データ収集プロセス 次に、図５を参照して統計量データのためのデータ収集プロセスについて説明 する。この場合、各ＣＢＸにおけるデータベースとデータベース３１１との間の スキーマ互換性の度合いに関する判定を下すために、図４に示されているプロセ ス（又はそれと同等のもの）がすでに完了しているものとする。ステップ５０１ において、ユーザはデータを収集すべきＣＢＸのリストとそのための収集スケジ ュールを指定する。その際、図６に示されているようなユーザスクリーンを用い ることができ、これは図２のユーザインターフェース２１６により提供されるユ ーザインタラクションによ って行うことができる。図６に示されているように本発明は、各ＣＢＸのためと 各ＣＢＸにおける各データベースのために別個の収集スケジュールをユーザが選 択できるようにすることに係わるものである（つまり統計量データベースと構成 データベース）。変形実施形態において、X Window/Motifグラフィカルユーザイ ンターフェース規格に従って、ユーザインターフェースを実現することができる 。図６には示されていないがユーザは、それ以前はデータを収集すべきでない開 始日時を指定することもできる。換言すれば、特定のＣＢＸが過去４２日の履歴 データを有しているならば、ユーザは開始日時を指定することができ、これによ り不所望な”古い”データの収集が回避されることになる。ユーザにより指定さ れたこの時間は、セレクトコマンドのための時間パラメータを定めるため、図５ のステップ５０７に示されているようにして用いることができる。 ステップ５０２においてデータ収集装置２１５は、ユーザにより指定されたＣ ＢＸのリストから最初のＣＢＸを検索し、ステップ５０３において、現在時刻に 基づきこのＣＢＸに対しデータを収集する時刻であるかを判定する。もしそうで あればデータ収集装置２１５は選択されたＣＢＸへのログ・オンを試み（ステッ プ５０４）、そうでなければステップ５０２においてリストから次のＣＢＸが検 索される。 ステップ５０５においてデータ収集装置２１５は、ＣＢＸのデータサーバに対 し「データベース・オープン」コマンドを発行することで、統計量データベース をオープンする。次にステップ５０６において、そのＣＢＸから初めて統計量が 収集されたのかが判定される。このＣＢＸに対し初めてデータ収集が行われたの であれば、おそらくそのデータすべてを収集する必要があり、ステップ５０７に おいて、ユーザがそのデータに対し特定の開始日時（つまりそれより前はＣＢＸ に格納済みのデータを無視する時刻）を指定しているのかが判定される。そのよ うな時刻が指定されていれば、ステップ５０８において、データベース検索のた めのタイムインターバルを形成するために、指定された日時が用いられる。ユー ザによって指定時刻が選定されていなければ、ステップ５０９において、現在時 刻以後、データ収集を開始させるのかが判定され、このことはデータベース検索 のためのタイムインターバルの形成に利用される。さらに、ステップ５０６にお いて、このＣＢＸのためにはじめてデータが収集されたのではないと判定されれ ば、ステップ５１０において（内部的に記憶されているフラグを参照して）この ＣＢＸのためのデータ収集プロセスがどこで最後に終わったのかが定められる。 ステップ５１１において、ステップ５１０、５０９又は５０８により定められ たタイムインターバルを用 いて、データを収集するテーブルを選択する。変形実施形態において、データを 収集すべきテーブルのリストをデータベース３１１に格納しておくことができる 。ステップ５１２においてセレクトコマンドが生成され、これは指定されたタイ ムインターバルにわたりターゲットとなるテーブルに対し発行される。変形実施 形態によれば、１つの特定のセレクトステートメントにより検索されることにな るデータの量を制限するため、最大期間（例えば１時間）を定めることができる 。この期間を超えるタイムインターバルは最大期間に制限された小さいインター バルに分断され、すべてのデータが長い方のインターバルにわたって収集される まで、それらの小さい方のインターバルにわたデータ収集が続行される。 ステップ５１３において、指定されたテーブルからのデータが収集コンピュー タ２１４に戻された後、戻されたデータがファイルに格納され、そのファイルが データベース３１１の適切な統計量テーブルにロードさ、その際、（例えばレコ ード内のフィールドのパディング又はヌル化により）スキーマのいかなる相違点 も考慮される。ステップ５１４において、指定されたＣＢＸ内にデータを収集す べきテーブルがさらに存在するかが判定される。存在するのであればステップ５ １１に戻り、存在しないのであればステップ５１５においてそのＣＢＸに対しロ グ・オフ・コマンドが発行 されてプロセスが終了する。 データを検索すべき各テーブルに対しデータ収集装置２１５は、テーブルデー タを受け取るファイルネームを送り、データベーステーブルに対しデータを要求 するためデータサーバにセレクトステートメントを送り、ＣＢＸからのデータを 受け取るためＺｍｏｄｅｍをスタートアップさせ、収集コンピュータ２１４内の 目的ファイルにそれを格納する。 図５に示したプロセスは、ユーザにより指定されたデータ収集スケジュールの 期間にわたり繰り返される。１５分というようなデフォルトの収集インターバル を用いることができる。 セレクトコマンドとデータレコードのフォーマット 各セレクトステートメントは、特定のデータベーステーブルからデータを獲得 する。サンプルフォーマットを以下に示す： SELCT * from〈table name〉 where d time between datetime(YY-MM-DD HH:MM)and datetime（YY-MM-DD HH:MM） ［これによって特定のタイムインターバルにわたりtable nameからすべてのレ コードが選択される］ SELCT * from〈table name〉 ［これによってtable nameからすべてのレコードが選択される］ 当業者であれば上述のものはＳＱＬ互換の問合わせ の変形であるとわかり、これをINFORMIXのようなほとんどのリレーショナルデー タベースとともに用いることができる。 データサーバによりデータ収集装置２１５へ送られるデータは、ASCIIで送ら れるのが好ましい。データベーステーブルの各行に対し、改行文字で終了する１ つのレコードが送られる。これらのレコードの各々内では、テーブルに格納され ているのと同じ順序で、データベーステーブルからのフィールドのセットがリス トアップされている。レスポンスにおいてフィールドを区切るため、垂直方向の バーを用いることができる。 各データサーバは、データのパイピングによりデータベーステーブルデータを Ｚｍｏｄｅｍへダイレクトに送ることができ、周知であり広範囲に利用可能な” フリーウェア”パッケージによってシステム間でファイルを転送することができ る。Ｚｍｏｄｅｍはステータスメッセージを標準誤りディバイスへ送るので、デ ータサーバもデータ収集装置２１５も、メッセージがコンソールに現れるのを防 ぐためＺｍｏｄｅｍを呼び出す前に標準誤り出力をリダイレクトする必要がある 。 Ｚｍｏｄｅｍが終了すると、Ｚｍｏｄｅｍ伝送のスタータスを獲得するためデ ータ収集装置２１５はデータサーバに対しコマンドを送信する。エラーが検出さ れた場合、データ収集装置２１５はエラーメッセージをレコードすることになる 。データ収集装置２１５がＺｍｏｄｅｍを開始させたが、データ収集装置がＺｍ ｏｄｅｍの開始において問題に直面すると、データ収集装置２１５におけるＺｍ ｏｄｅｍはタイムアウトし、データ収集装置２１５は、データサーバにより送ら れたエラーメッセージを破棄するため、そのポートのすべてのキャラクタを「洗 い流す」必要がある。他方、データ収集装置がＺｍｏｄｅｍの始動に成功したが 、その開始において問題に直面したならば、データ収集装置２１５はＣＢＸサイ ドでのＺｍｏｄｅｍを終了させるため、control-Xのストリングをデータサーバ へ送信する必要がある。 本発明による動作を増強するため、Ｚｍｏｄｅｍ規格に対し若干の変更を加え ることができる。詳細には、Ｚｍｏｄｅｍは一般に、転送すべきファイルネーム を決定するため環境変数をチェックする。この場合、データ収集装置２１５がフ ァイルネームを指定できるようにするため、コマンドラインで指定されたファイ ルネームに対するチェックをデータサーバ側で代わりに行うよう変形することが できる。収集コンピュータ２１４側においてＺｍｏｄｅｍを、終了を行う改行復 帰と改行の送信を承認送信時に阻止するよう、僅かに変更することができ、その 際、ログエラーを収集コンピュータ２１４におけるメッセージログに変えるよう にする。さらに、ブロックサイズ定数（ＫＳＩＺＥ）を１０２４から２０４８へ 変更することによって、収集コンピュータ２１４におけるＺｍｏｄｅｍは、２０ ４８ｂｙｔｅの受信後にしかブロックを承認しないことになり、これにより僅か な承認しか必要としなくなる。当然ながら、Ｚｍｏｄｅｍ以外のその他の通信パ ッケージを使用することもできる。 各データサーバ２１０は、データ収集装置２１５がログアウト・コマンドを利 用してログ・オフしたとき、各データサーバ２１０は動作終了する。 データ収集装置の構造 図７には、図２のコンピュータ２１４における機能群およびデータ構造として 、データ収集装置２１５をどのように実現することができるかが示されている（ つまり図７のすべての機能およびデータ構造が物理的なコンピュータ２１４に属 するように構成することができる）。図７の右側から始めると、ユーザにより指 定された（ＣＢＸのリストと収集時間を含む）データ収集スケジュールが、収集 スケジュールデータ構造体７０６に格納される。スケジューラ７０５は、データ 収集セッションをいつ開始するのかを決定するため、収集スケジュール７０６を 周期的に参照する。はじめにスケジューラ７０５は、各ＣＢＸに格納されたデー タベースとデータベース２１８のそれとの間における互換性を判定するため、ス キーマ互換性判定を指示す る。一方、スキーマ互換性決定機能７０４はコマンドジェネレータ７０２に対し 、収集スケジュール７０６にリストアップされている各ＣＢＸへスキーマコマン ドを生成するよう、リクエストを発行する。コマンドジェネレータ７０２はその ようなコマンドを生成し、（Ｚｍｏｄｅｍプロトコルを有することのできる）通 信インターフェース７０１を介してそのコマンドを指定されたＣＢＸへ伝送する 。 各ＣＢＸから受け取った情報は通信インターフェース７０１を経由して送り戻 され、受信した情報を抽出するためインテグリティ・チェッカ７０８およびパー サ７０７を通すことができる（なお、コマンドに対するデータ・インテグリティ ・チェックは、各キャラクタが送信されたときに各キャラクタをチェックするた め各データサーバ２１０からの全二重エコーを用いて行うことができ、他方、デ ータベースレコードのためのデータ・インテグリティ・チェックはＺｍｏｄｅｍ 自体によって行うことができる）。通信インターフェース７０１は、コマンドジ ェネレータ７０２、データ・インテグリティ・チェッカ７０８およびパーサ７０ ７の一部を含むよう構成することができる。各ＣＢＸにおけるスキーマ・構成は スキーマ互換性決定機能部７０４へ送られ、スキーマ互換性決定機能部７０４は この情報を、各データベース・スキーマ間において生じ得る差異を調停するため 、データベースローダ７０ ９へ中継する。 特定のＣＢＸからデータを収集する時間であることがスケジューラ７０５によ り判定されると、データ収集が始められる。この点についていえば、スケジュー ラ７０５は統計インターバルジェネレータ７０３に対し、（データがその特定の ＣＢＸからすでに収集されているのかに依存して）指定されたＣＢＸからデータ を収集するための１つ又は複数のタイムインターバルを発生させるよう指示する 。コマンドジェネレータ７０２は適切なセレクトコマンドを生成し、通信インタ ーフェース７０１を介して指定されたＣＢＸへそのコマンドを送信する。 各ＣＢＸから戻されたデータはデータ・インテグリティ・チェッカ７０８およ びパーサ７０７を通過し、これによりデータがアンパックされ、目的ファイル７ １０にそれが格納される。特定の収集セッションのためのすべてのデータインタ ーバルが目的ファイル７１０に格納されると、データベースローダ７０９は目的 ファイル７１０からデータを読み出し、それをデータベース２１８へ格納し、こ れによりスキーマの差異に関するすべての必要な調整（例えばフィールドのパデ ィング又は必要に応じてフィールドの無視）が行われる。 データ同期 データを各データサーバから受信すると、データ収 集装置２１５はレコードをデータベース２１８内の相応のテーブルにロードしよ うと試みる。いくつかのレコードがロードされてエラーに直面した場合、データ 収集装置２１５は何らかのエントリが追加される前の状態までテーブルを”ロー ルバック”することになる。特定の時間インターバルからのすべてのレコードを データベース２１８のテーブルに追加する場合、データ収集装置２１５はレコー ドの”コミット”を行う。 データ収集装置２１５は１つのデータ収集セッションにおいて、他からではな くいくつかのテーブルから情報を選択することができる。この場合、目下のイン ターバルの間にどのテーブルが情報を獲得しなかったのかを見失わないようにす る必要がある。次のデータ収集セッションのための時間が到来すると、データ収 集装置２１５は、直前のインターバルで得たテーブルについては次のインターバ ルに進むが、問題に直面した別のテーブルについては先行のインターバルにとど まる。換言すれば、各データベーステーブルに対しデータ収集装置２１５は、ど のデータインターバルをＣＢＸから得る必要があるのかを見失わないようにしな ければならない。このようにすることで、問題を有していたがＣＢＸにおいて修 繕されたテーブルについて情報を検索できるようになる。そのようなテーブルに 対しデータ収集装置２１５は、以下のうちの１つが発生するまで、問題に直面し たインターバルにとどまる ： ａ．データ収集装置２１５はそのインターバルの間にデータを獲得できる、ある いは、 ｂ．データ収集装置２１５はそのインターバルの間にデータを獲得できないが、 後続のインターバルの間にデータを獲得できる。この場合、データ収集装置２１ ５は、最後の１つがその最終的なデータセッションで収集された後、そのインタ ーバルへ進む。なお、データ収集装置２１５は、データを収集できなかった各イ ンターバルごとにエラーメッセージをレコードすることができる。エラーメッセ ージには、データベースタイプ（統計量又は構成）、テーブルのデータタイプ、 テーブルネームおよび収集されなかったインターバル（例えば１：００から１： １５）を含ませることができる。データ収集装置２１５が所定の期間にわたりオ フラインとなっていてＣＢＸと再接続されることになった場合、各テーブルに対 して決められたインターバルからＣＢＸに格納されている最後のインターバルま でデータを収集できるようにする必要がある。 構成変更 変形実施形態において、各ＣＢＸに保持されている各統計量テーブル内の各レ ーコードは、ＣＢＸにおいて構成変更が行われたか（例えばエージェント又はグ ループの追加が行われたか）について指示するフィールドを有する。データ収集 装置２１５が各ＣＢＸから 統計量情報を収集するとき、そのＣＢＸに関する構成が変更されたかを判定する ため、データ収集装置は各レコードにおけるその構成変更フラグをチェックする 。変更されていれば、データ収集装置２１５はＣＢＸに格納されている構成デー タベースの転送を開始し、これによってデータベース２１８に格納されている構 成データベースとＣＢＸに格納されているものとの整合をとることができるよう になる。 組織階層の生成 本発明の変形実施形態は、各ＣＢＸ内に保持されているエージェント／グルー プ構造に付加される管理組織に関する情報の生成、修正ならびに記憶に係わるも のである。したがって、各ＣＢＸは到来する電話コールを自動的にルーティング し、エージェントとグループレベルにおける統計量を保持する目的で、特定のエ ージェントをグループに関連づける情報を保持し、他方、エージェント／グルー プ構造の頂点に１つの階層を付加するのが望ましく、この場合、その階層は任意 に定義したり変更したりすることができ、ＣＢＸレベルでは不可能なやり方で累 積電話コール統計量の基礎として利用することができる。したがって本発明は、 （図３に示されているような）時間ベースだけでなく階層ベースでの累積電話統 計量に係わるものである。次に、これについて説明する。 図８には、各ＣＢＸで認識されるグループ分けを超 えた階層手法による累積電話コール統計量の実例が示されている（各ブロック内 の数字は階層のそのレベルで受信された電話コールの数を表し、これについては 以下で詳細に説明する）。この場合、基本的に、各ＣＢＸにより認識されたグル ープ情報に実務構造情報が加えられている。図８には、架空の「ビッグバンク」 社について組織構造が示されている。この構造の「ルート」であるビッグバンク ８０１は、２つの主要な部門すなわちセールス８０２とサービス８０３に分けら れている。セールス部門はさらに２つのセクション８０４と８０５に分けられて いる。つまり一方はゴールドカードクレジット機関（ゴールドカードを利用する 小売顧客に銀行が提供するクレジットおよび金融サービス）のセールスを担当し 、他方はプラチナカードクレジット機関を担当する。 サービス部門８０３は３つのセクション８０６，８０７，８０８に分割されて おり、第１セクションはゴールドカードクレジットアカウントのサービスを担当 し、第２セクションはプラチナカードクレジットアカウントのサービスを担当し 、第３セクションはこれら両方のタイプのアカウントのサービスを担当する。こ れら３つのすべてのセクションは、コールを処理するエージェントのグループを 有している。 ゴールドカードセクション８０４は、８０９におけるエージェントの２つのグ ループによりサービスを受 ける。すなわちこれは、ＳＦＧセールス（サンフランシスコにあるサンフランシ スコゴールドセールス）とＬＡＧセールス（ロスアンゼルスにあるロスアンゼル スゴールドセールス）とにより行われる。各グループは典型的には別個のＣＢＸ と接続される。したがって図８の実例の場合、ゴールドカードセクション８０４ は、異なる２つの物理的な場所にあるエージェントを有している。図８には他の グループも示されており、この場合、エレメント８１０〜８１３内の各々のグル ープは、ある特定のＣＢＸにより認識される最も高い組織レベルである。 図８の組織構造は、以下で詳細に説明するようにして本発明に従って生成する ことができる。各組織構造は、統計量がどのように累積するかを定義するために 用いられる。 例えば図８の組織構造が形成された後、以下の組織又は集団のいずれかに関す る種々の電話コール統計量を示すレポートを作成することができる： −（エレメント８０９に含まれているサンフランシスコゴールドカードセールス のような）ある特定のグループに関する総呼数 −ゴールドカードサービス（エレメント８０６）を行うすべてのグループ間の通 話に費やされた平均時間 −プラチナカードサービス（エレメント８０７）を行うすべてのグループ間の破 棄された総呼数 −ゴールドカードセールス（エレメント８０４）を扱うすべてのグループ間での 総呼数 −全サービスグループ（エレメント８０３）間の待機に費やされた平均時間 −ビッグバンク（エレメント８０１）内のすべてのエージェントの通話に費やさ れた平均時間 統計量はグループだけでなく個々のエージェントによっても利用できるので、 特定のコールグループと結びついていない階層に基づき組織を形成することがで きる。したがって、１つのグループとしてのサンフランシスコゴールドセールス について保持されている統計量に加えて、そのグループ内の各エージェントにつ いても統計量が保持され、このため電話回線と結びついたＣＢＸグループに依存 しない手法でエージェントを「グループ化」することができる。１つの実例とし て、ある特定の年に雇用したすべてのエージェントを、彼らが異なる場所および 異なるＣＢＸにより働いていても、まとめてグループ化し、それらのエージェン トの「グループ」について自動的に統計量累積を行わせることができる。 データが収集されると、データトータルは組織の個々のメンバーおよび組織チ ャートの各レベルについてデータベースに格納されることになる。図８の場合、 各ブロック内の数字はコール数を表しており、これは（例えば１５分のような） 特定の時間周期内において 、ビッグバンク全体で２０５のコールがあった中で、この組織エンティティにつ いて処理されたものである。したがってビッグバンクのトータルは、レポートが 要求されるまで待機するのではなく、データが収集されると自動的に累積される ことになる。（例えば１年というような）長い期間にわたる累積については、デ ィスクスペースを保持するため、「生の」１５分のデータレコードはかなり前に 削除してしまうことができるが、週および月に関する中間累積データは保持して おくことができ、これによって「生の」データなしで年ごとのトータルを累積さ せることができるようになる。 本発明は、組織の「ビュー（view）」に基づき累積された情報を格納すること に係わる。ある１日についてはただ１つの組織の「ビュー」しか存在しない。最 初は「カレント・ビュー（current view）」とすることができ、組織構造に変更 が加えられると、それらの変更が「ペンディング・ビュー（pending view）」に 格納される。ペンディング・ビューは所望のように変更することができ、指定さ れた日付にペンディング・ビューの最新バージョンが現在のビューに変換される ことになる。この場合、古いカレント・ビューは「パスト・ビュー（past view ）」となり、これは１月３日〜２月２２日のような特定の日付範囲について有効 なものである。データ累積は通常はカレント・ビュー についてであるが、古いデータを収集するときにはパスト・ビューについても行 うことができる。 データは、組織のメンバーが存在している時間帯に合わせて調整することがで きる。例えば、東部時間帯にあるグループに関するデータを、太平洋沿岸の時間 帯にあるマネージメントグループに報告する場合には、時間インターバルから３ 時間差し引いて累積させることができる。図８のビッグバンクの実例の場合、９ ：００ａ．ｍ．のインターバルに関する東部時間帯のグループからのデータは、 太平洋沿岸の時間帯にあるマネージメントグループのために６：００ａ．ｍ．の インターバルに累積される。 図８に示した組織構造は、図２のユーザインターフェース２１６（これらすべ ては図２のコンピュータ２１４において処理される）によりコントロールされる スクリーンを用いて形成することができる。次に、これについて説明する。図９ には、ユーザが新たな組織を形成したり修正したりすることのできるスクリーン の実例が示されている。図９に示されている”view”は、まだ「カレント”ビュ ー”にされていないペンディング」組織である。ユーザは、情報を入力するため マウスとポップアップ・ウィンドウを用いてツリー構造に加えることができる。 組織の形成は「トップ・ダウン」手法で行うのがよく、その際、ビッグバンクグ ループを最初に形成し、次にセールスとサービスのグ ループが続くようにする、という具合である。グループの１つがハイライト表示 されていると（図９ではゴールド／プラチナ，GOLD/PLATINUM，がハイライト表 示されている）、プルダウンメニュー９０１によりユーザはグループを編集、追 加、移動又は削除することができるようになる。組織チャートに対し所望の変更 をすべて加えてしまったならば、”APPLY”ボタン９０２を選択して「ペンディ ング」組織を保存することができる。そして「ペンディング」組織は「カレント 」組織に格納され、それについて指定された日付に統計量が自動的に累積される ことになる。 図１０には、どのようにして個々の従業員情報をコンピュータスクリーンから 入力できるかが示されている。図１０を参照すると、エントリーフィールド１０ ０１は従業員氏名を入力するために用いることができ、従業員がエージェントで あれば、エージェントログ・オン識別子１００２とＡＣＤ（自動コール分類）グ ループ１００３識別子が入力される。ある特定の従業員（エージェント）は２つ 以上のログ・オン識別子をもつことができるので、そのようなログ・オン識別子 すべてを入力しそれらを指定された従業員と関連づけることで、レポート作成時 にユーザはすべてのログ・オン識別子（これらは従業員氏名ではなく各ＣＢＸに 格納されている）を指定するのではなく、従業員氏名を照会するだけでよいこと になる。また、従業員の目 下のスーパバイザ１００４も入力される。このようにして複数の従業員を入力し た後、管理階層を自動的に生成することができる。この場合、管理組織を、図９ に示した”グループ”組織とは別個に分離して設けることができる。つまり、統 計量は１つ又は複数の管理階層（管理者、マネージャ、個々の従業員等）により 累積される可能性があり、さらにそれらは１つ又は複数の実務階層（会社全体、 部門、部局、セールスグループ等）により別個に累積される可能性がある。この 場合、管理階層および実務階層が２つの特有の構造として示されており、当然な がら他の階層も可能であって、本発明はそのような観点に限定されるものではな い。例えば、ログ・オン識別子又はトランクグループに基づき階層を生成するこ とができる。各々が１つの分離した累積構造をもつ別個の階層的スキーマを用い ることで、エージェントの特定のグルーピング（例えばいずれの特定のエージェ ントが目下割り当てられているかに関係なくセールスグループ）に関してレポー トを作成することができるし、割り当てられているグループとは無関係に特定の 人物に関してレポートを作成することもできる。 図１１には、どのようにして組織構造により電話コール統計量を種々のデータ レコードに累積させることができるか示されている。図１１に示されている構成 要素（コンポーネント）はすべて、図２のコンピュー タ２１４に属するように構成できる。組織ジェネレータ１１０１は、図９および 図１０で示したスクリーンにユーザが入力した情報に従って組織情報を生成し、 情報を構成データベース３２７に格納させる。このデータベースは図３で示した 構成データベースと同じものである。この情報により、種々のレベルで統計量の 累積を行う構造が識別される。図３を参照して説明した方式によれば、種々のタ イムインターバルにおけるデータレコードが収集されて、データベース１１０４ のテーブル１１０５に入れられ、このことは例えば各ＣＢＸにより生成された情 報の１５分の要約をそれぞれ表すデータレコードを用いて行われる。なお、テー ブル１１０５内の各データレコードには複数のフィールドを含ませることができ 、各フィールドが特定の統計量の値（つまりあるグループについて受信した総呼 量あるいは待機に費やしたエージェントごとの平均時間）を保持するように構成 できる。 複数のＣＢＸからの自動化されたデータ収集プロセスの結果として、データレ コードがテーブル１１０５に格納される。データレコードが収集されると、時間 ベースのアキュムレータ１１０３はテーブル１１０５内の複数のレコードにわた る値を累積し、相応のトータルをテーブル１１０６と１１０７内のデータレコー ドに格納する。したがって、テーブル１１０６は図３のテーブル３２２に対応す るものとすることができ、 このテーブルの各レコードには週ベースで累積された統計量が含まれる一方、テ ーブル１１０７は図３のテーブル３２３に対応するものとすることができ、この テーブルの各レコードには月ベースで累積された統計量が含まれる。本発明によ れば、時間ベースのアキュムレータ１１０３は週ベースのトータルをテーブル１ １０６に格納し、月ベースのトータルをテーブル１１０７に格納する。 組織アキュムレータ１１０２は、どの組織トータルを累算すべきであるのかを 確認するために構成データベース３２７を参照し、テーブル１１０５からのデー タレコードをテーブル１１０６および１１０７の組織トータルレコードに累積さ せる。図１１に示されているように、セールス部門、サービス部門およびビッグ バンクによるトータルをレコードするため、組織階層が形成されている。このた め、組織に関するテーブル１１０６内の各レコードには、組織単位で週ごとに累 積されたトータルが含まれている。この情報はデータ収集プロセス中に自動的に 累積され、これはデータが各ＣＢＸから収集されるときにテーブル１１０６が同 じインターバルでアップデートされるようにして行われる。同様に、各ＣＢＸか らデータが収集されるときにテーブル１１０７を同じインターバルでアップデー トすることができるが、この場合には各レコードは月ごとの統計量を表している 。したがってデータは、レ ポートが作成される時点ではなくデータ収集プロセス中に増分的に所望の単位で 累積される。アキュムレータ１１０２および１１０３を１つのアキュムレータと して統合してもよい。先に述べたように、テーブル１１０５からのデータレコー ドは、ディスクスペースを保持するため周期的に（例えば４２日後の「ローリン グ・ベース」で）削除することができ、他方、テーブル１１０６で表された累積 テーブルは保持しておくことができる。このようにして、「生の」データからの 有用な情報を、実際に生データを保持しておくことなく維持し続けることができ る。 変形実施形態によれば、組織アキュムレータ１１０２はレコードを組織レベル でテーブル１１０５に格納させることができる。つまり例えば１５分のレコード を、かなり長い時間インターバルにわたりテーブル１１０６および１１０７に累 積させることに加えて、セールス、サービスおよびビッグバンクに関してそれら のデータをテーブル１１０５に格納することができる。 レポート作成 本発明の原理によれば、テーブル１１０６（及び図に示された類似のテーブル ）で生成された情報は、オンデマンドレポート又は自動的にスケジュールされた リポートを生成するために使用することができる。図１２は、本発明のレポート 作成機能の１つの可能な実 施形態を図示している。図１３〜１８は、ユーザがレポート情報を入力しレポー トを作成することができるための様々な可能なスクリーンレイアウトを図示して いる。以下の記述は、図１３〜１８のディスプレイスクリーンに関連させて図１ ２のレポート作成機能のオペレーションを適切により詳しく記述する。図１２に 図示された全ての構成エレメントは、図２のコンピュータ２１４に属することが できる。 図１２では、データベース１２０１（このデータベース１２０１は、図２のデ ータベース２１８の中に配置することができる）は、ユーザライブラリ１２０３ 、公的ライブラリ１２０５及びブランクレポートテンプレート１２０６を含むテ ンプレートライブラリ１２０２を有する。各ユーザライブラリ１２０３は、１つ 又はそれ以上のレポートテンプレート１２０４を有することができ、このレポー トテンプレート１２０４の各々は、どんなデータがディスプレイされるのか及び どのようにレポートはフォーマットされるべきかを含めた、レポートの作成に必 要な情報を含んでいる。各ユーザライブラリ１２０３は、他のユーザから個別に 保護され、この結果、指定されたアクセス特権を有する特定のユーザのみが、こ のユーザのユーザライブラリに含まれたレポートを作成することができる。した がって、例えば、微妙な取り扱いを要する情報を有するレポートを、保護機能を 有するユーザライブラリに 格納されているテンプレートを使用して生成することができる。他方で、公的ラ イブラリ１２０５は、どんなユーザもアクセスできるレポートテンプレートを有 しており、無許可のアクセスを防止するための保護が必要ない。 レポートレイアウトコントロール機能１２０７及び基準選択機能１２０８は、 様々な実施例において、内容及び特定のレポートのフォーマットをデザインする ために使用される。テンプレートジェネレータ１２０９はレイアウト及び基準情 報をレポートレイアウトコントロール機能１２０７及び基準選択機能１２０８か ら受け取り、「ブランク」テンプレート１２０６からはじめて、テンプレートラ イブラリ１２０２に格納するためのレポートテンプレートを生成する。一度レポ ートテンプレートが生成されると、レポートは、このテンプレートから、要求も しくは自動的にスケジュールされた方式に応じて生成され得る。一般的に、レポ ートレイアウトコントロール機能１２０７は、情報をフォーマットすること（例 えば、どのようにレポートが見えるか及び情報がディスプレイされるユニットが どのように見えるか）を処理し、一方で基準選択機能１２０８は、レポートにど のデータがディスプレイされるべきか（例えば、データベースのどのフィールド か、どのタイムゾーンか、など）を分類する。議論のために別個に図示したが、 これらの２つの機能は、勿 論結合させることができる。 様々な実施形態において、各レポートは、レポートヘッダ及び１つ又はそれ以 上のレポート選択を有し、各選択は、選択ヘッダ、項目ヘッダ、そしてデータの カラム及び行を有している。図１３は、レポートヘッダ１３０１、項目ヘッダ１ ３０２及び１３０３、選択ヘッダ１３０４、そして複数のデータ行１３０５を有 する見本レポートを図示しており、各行が適切な項目ヘッダの下に配置された複 数の項目数値を有する。本発明によれば、ユーザは、構造化問い合わせ言語（Ｓ ＱＬ）のようなデータベース問い合わせ言語を使用もしくは理解する必要なしに 、各レポートに含まれるレイアウト及びデータを指定することができる。 図１４は、レイアウト及びレポートに含まれるべきデータの部分をユーザが指 定することができるデータエントリスクリーンの１つの可能な実施形態を図示し ている。プルダウン(pull-down)メニュー１４０１によってユーザはデータの項 目を所望通りに生成、変出整列及び削除することができる。付加的に、ユーザは 、例えば、マウスポインタを使用して、グラフィック的に様々な項目ヘッダ１４ ０２及び１４０３を生成及び操作することができる。スクロールバー１４０４は 、ディスプレイスクリーン内で利用できるスペースの中で、生成された情報を配 置するために使用される。図１４の例においては、８つの項目が、ユーザによっ て使用された様子が図示されている。新しい項目が生成されると、レポートレイ アウトコントロール機能１２０７は、自動的にこの新しい項目をディスプレイし 、その後、有利には、図１５に図示されているセットアップ情報ディスプレイス クリーンを呼び出し、この結果、ユーザは、レポートのその項目に表示されるべ きデータに関する一定の情報を指定することができる。従って、様々な実施形態 において、図１４の各項目が生成され、ユーザが情報を適当に入力した後で、図 １５のディスプレイスクリーンが呼び出される。 図１５に関連して、エージェント又はグループのような、項目に対するデータ タイプ１５０１そして、ディスプレイされる特定データアイテムか計算値かを識 別するデータエレメントネーム１５０２を指定することができる。この計算値は 、（２つのデータアイテムの平均のような）１つ又はそれ以上の特定データアイ テムについて行われる数学的演算に相応する。ディスプレイボックス１５０３は 、ユーザによって強調された特定のデータエレメントネームのテキスト記述をデ ィスプレイすることができる。従って、ボックス１５０３のデータエレメントネ ームが、有利には図３のデータベース３１１に格納された累積レコードの中のレ コードフィールドネーム（又はこれについての計算）に相応する一方で、ディス プレイボックス１５０３によって、新参のユーザは、データエレメントの読み易 い記述（easy-to-read description）に基づいたディスプレイのためのデータエ レメントを選択することができる。ディスプレイフォーマットボックス１５０４ によって、ユーザは、フォーマット、ユニット、項目幅、そして各項目ごとの他 のフォーマッティング情報を指定することができる。タイムオフセットボックス １５０５によって、ユーザは、時間及び組織オフセットを指定することができる 。タイムオフセットは、レポートの中で並置されるフィールドのタイムシフトに 使用され、この結果、第１の項目は、今日のエージェント毎の呼び出しコールの 総数を表示することができ、他方で第１の項目の右側の第２の項目は、昨日のエ ージェント毎の呼び出しコールの総数を表示することができる。したがって、オ フセットは、異なる条件下で同一のデータエレメントを比較する容易な方法を提 供する。オフセッティングは、データベースからのデータ検索に関連して後で説 明する、図１２の上部に図示されたオフセット調整機能１２１６によって行われ る。組織オフセットは、組織階層の中の情報の異なるレベルを比較するのに使用 される（例えば、ビッグバンクのセールス部門と、エージェント毎のビッグバン クの全電話コールとを比較する）。スクリーン１４及び１５にユーザによって入 力された情報は、テンプレートジェネレータ１２０９によって生成されたテンプ レートに格納され、さらにテンプレートライブラリ１ ２０２のレポートテンプレートに格納される。 本発明の原理によれば、ユーザは、各レポートにディスプレイされる組織レベ ルを選択することもできる。図１６は、ユーザが、ディスプレイされる組織レベ ルを選択することができるために使用される１つの可能なスクリーンを図示して いる。これらは、有利には、図１１のデータベース１１０４に累積された組織レ ベルに相応する。言い換えれば、ユーザは、同一の情報を格納するために使用さ れる特定のデータベースレコード構造を理解することなしに、図１６のディスプ レイスクリーンを使用して組織レベルをグラフィック的に選択することができる 。従って、図１６は、データが（エージェントの多数のグループを表す）ゴール ドカードレベルでレポートされることを示している。図１３に図示されたレポー トは、そのデータ選択におけるデータがゴールドカード組織レベルで累積されて いることを示す選択ヘッダとしての★★ゴールドカードをディスプレイする。 図１７は、レポートの各行に対応する時間累積レベルを示す「データ詳細」を ユーザが入力できるための、１つの可能なスクリーンディスプレイを図示してい る。例えば、図１７では、“Quarter Hour“が選択されている。図１３に図示さ れたレポートは、従って、１５分の増分を表す行を含んでいる。このデータはす でに格納され、図３及び１１に図示されたテーブルに おいて適切な時間累積レベルで利用できると期待されるので、時間累積レベルは 、そこからデータが検索される特定のデータテーブルを推論的に指定する。 最後に、図１８は、組織ソートオーダー１８０１、時間修飾子１８０２、そし て“where conditions”１８０３及び１８０４を含む「データ基準」をユーザが 入力できるための１つの可能なスクリーンディスプレイを図示している。この組 織ソートオーダーは、組織データがレポートにディスプレイされる順番（order ）を指定する。各組織は、例えば、アルファベット順、逆アルファベット順又は 現在の階層順にディスプレイされる。後者の現在の階層順は、レポート選択が組 織階層の順番で表されることを示す。時間修飾子１８０２によって、ユーザは、 あたかも異なる時間帯にデータが発生したかのようにデータを表示することがで きる。この機能は、特に、異なる時間帯に配置されたマルチプルＣＢＸからデー タが集められる場合に重要である。デフォルトは「無調整（unadjusted）」にセ ットされ、このため、各レポートの時間は、それらの「固有の（native）」時間 帯に集められたように現れる。もし、レポートジェネレータがサンフランシスコ に配置され、無調整オプション（unadjusted option）が使用されるならば、レ ポートは、ユーザがデータを同一の「絶対」時間において比較しようと意図して も、異なるＣＢＸの時間帯からのデータを含む事にな るだろう。様々な実施形態においては、ユーザが複数の時間帯選択枝から選択で きるために、ポップアップウインドウがディスプレイされる。これらの時間帯の うちの１つが選択された場合、全てのデータは、ユーザが適正にデータを比較で きるように、選択された時間帯にいわば翻訳（“translate”）される。例えば 、もしデータが西海岸のＣＢＸ及び東海岸のＣＢＸから集められた場合、ユーザ は、中央標準時間帯修飾子を選択することができ、そしてそれぞれの海岸からの データは、適切にレポートに表示されるように一方から他方へ「翻訳」されるで あろう。 図１８では、様々な“where conditions”が、レポートに表示されるデータを さらに分類するために使用される。例えば、このレポートは、電話コールの平均 数が時間あたり２００を越えるデータしかディスプレイしないように制限される 。これは、ウインドウ１８０３に適切なデータエレメントネーム、演算子及び数 値を入力することによって行うことができる。それ以上に、多くの状況は、より 複雑な演算のために“ＡＮＤ”演算子又は“ＯＲ”演算子１８０５によって論理 的に結合される。 上に述べた情報がユーザによって入力された後で、テンプレートジェネレータ １２０９がレポートテンプレートを生成し、ユーザにより指定されたネームをこ のレポートテンプレートに割り当て、これをユーザラ イブラリ１２０３のうちの１つ又は公的ライブラリ１２０５に格納する。付加的 に、様々な実施形態では、レポート作成時間で検索を早めるために、テンプレー ト情報に基づく内部データ構造を予め生成しこのような構造を格納されたコント ロール構造１２１０の中に格納することが望ましい。 オンデマンドレポートコントローラ１２１２によって、ユーザは、データと、 レポートに含まれるべきデータのためのタイムレンジとを選択することができる 。これは、図１３に図示されているようなディスプレイボックス１３０６を使用 して選択される。代わりに、レポートスケジューラ１２１１が、日数単位、時間 単位などを基礎にしてレポートを「永久的に」スケジュールし、スケジュールに 合わせたデータ検索を行うために使用される。オンデマンドレポートコントロー ラ１２１２又はレポートスケジューラ１２１１は、ビルドタイムアレイ(build t ime array)機能１２１３を呼び出すために使用することができる。このビルドタ イムアレイ機能１２１３は、様々な実施形態において、タイムアレイ１２１４を 生成する。このようなタイムアレイは、要求されたデータや時間、要求された総 数のタイプ（日数単位、週単位、時間単位等々）、時間帯情報などのような情報 を保持するために使用される。 データ検索及びキャッシュローダー（cache loader ）１２１５は、レポートテンプレートからの情報に基づいた累積テーブル１２１ ８からデータを検索するための１つ又はそれ以上のＳＱＬステートメントを生成 する。要約すれば、選択された累積レベル（例えば、シフト、週、月、ゴールド カード選択、ビッグバンクなど）に基づく１つ又はそれ以上のテーブルを選択し 、選択されたデータエレメント（例えば、エージェント毎の電話コールの総数） に基づくこれらのテーブルの１つ又はそれ以上のフィールドを選択し、さらにレ ポートのために指定されたタイムレンジ（図１３のボックス１３０６）及び図１ ８で指定された（「どこで電話コールの総数が２００より多くなるか」というよ うな）幾つかの基準に基づくレコードを分類するＳＱＬステートメントが生成さ れる。前述した図から得られ、レポートテンプレートに格納される情報が、デー タベース検索のための１つ又はそれ以上のＳＱＬステートメントを形成するため に、どのように使用されるかが直ちに理解されるはずである。 ＳＱＬステートメントは、時間オフセット、組織オフセット又はレポートテン プレートに含まれる時間帯に基づくオフセット調整機能１２１６において調整さ れる。例えば、ある日の時間オフセットが、レポートの第１項目に関連する第２ 項目に指定された場合、ＳＱＬステートメントは、第１の項目に指定されたデー タから同時刻に対するデータ（しかし先行するデータ ）を検索するように調整されることになる。同様に、ユーザが、レポートの中に 表示するために「セールス」グループレベルを指定した場合、＋１の組織オフセ ットが、レポートの中で並置するために、このセールスグループよりも１つ高い レベルでデータの検索も行う。 時間帯翻訳（time zone translation）は、つぎのように行われる。異なる時 間帯のＣＢＸからの累積データを有する組織が選択された場合、データ検索及び キャッシュローダー１２１５は、各ＣＢＸテーブルに対する２つの別個のＳＱＬ ステートメント（図３参照）を生成し、１つ又はそれ以上のＳＱＬステートメン トで時間修飾子を変えて異なる時間帯を説明する。 データ検索及びキャッシュローダー１２１５は、累積テーブル１２１８を含む 、１つ又はそれ以上のテーブルからデータを検索し、この検索されたデータによ ってキャッシュ１２１７をロードする。検索されたデータをメモリ構造にロード する多くの方法があるが、様々な実施形態では、１つの例として、キャッシュ１ ２１７は、検索されたデータによって次のようにロードされる。エレメントＸ１ からＸ４までを有するＸ軸、エレメントＹ１からＹ４までを有するＹ軸，エレメ ントＺ１からＺ６までを有するＺ軸を持つ３次元構造を形成する。Ｘ軸は時間軸 （各エレメントは、一週間のような時間のユニットを表す）として使用される。 Ｙ軸は、（特定のエージェント、エージェントのグループ、又はセールスグルー プのような）組織メンバーを示すために使用される。そしてＺ軸は、（特定のエ ージェントに対する電話コールの総数のような）各レコードのフィールド数値を 表すために使用される。 キャッシュウォークスルー機能１２１９は、様々な実施形態で、キャッシュ１ ２１７の１つデータアイテムを一度に「ウォークスルー」し、このデータアイテ ムをレポートの行に入れる。幾つかのデータアイテムは、レポートフォーマッタ １２２０によってフォーマットするために、直接レポートの行に入れられる。幾 つかの「派生」データアイテムは、データエレメントカルキュレータ１２２２に よって行われるオンザフライ計算を必要とする。例えば、ユーザは、特定の項目 が特定のエージェントに対する平均会話時間を有するように指定するかもしれな い。このような数値は、どのようなデータベーステーブルのどのようなフィール ドにも直接は格納されていないが、ある特定の期間に亘るそのエージェントに対 する全会話時間をそのエージェントが受けた電話コールの数で除算することによ って得ることができる。従って、例えば、特定の期間中の特定のエージェントに 対する電話コールの総数はエレメント（Ｘ４、Ｙ１、Ｚ１）に格納され、同じ期 間中のこの同じエージェントのに対する全会話時間は、（Ｘ４、Ｙ１、Ｚ２）に 格納され、除算演算のイン ジケータは、エレメント（Ｘ４、Ｙ１、Ｚ３）に格納され得る。そしてキャッシ ュウォークスルー機能１２１９は、２つの数値を検索し、除算演算をデータエレ メントカルキュレータ１２２２に渡し、この演算を実行する。演算及びデータ値 全てが、特定のレポートの行のために検索された場合（すなわち、Ｘ及びＹの定 数を保持し、全てのＺの値をウォークスルーすること）、複数の行の値のは、レ ポートフォーマッタ１２２０に供給され、このレポートフォーマッタ１２２０は 、レポートテンプレートに格納された様々なディスプレイフォーマッティング情 報に従って、レポート１２２１の個々の行を生成する。 11.電話コール情報の交換 図１９は、本発明の原理が、それぞれ電話コール情報を格納する２つのコンピ ュータを有するコンフィグレーションにどのように適用されるかを示す。図１９ の左側に図示されたコンピュータ１９０１は、図１（ａ）のメインフレームコン ピュータ０１と同一のものであるが、簡潔に説明するように付加的なコンポーネ ントを有している。図１９には、エレメント１９０２〜１９１２、１９１４及び １９１７までが、図１（ａ）で同様にナンバリングされたエレメント（すなわち 、それぞれエレメント０２〜１２、１４、及び１７）と同一のものであり、それ に応じて処理する。 図１（ａ）に関連して説明したように、到来電話コールは、ＣＢＸ１９０２に よって電話１９０４に送られ、コール進行として様々な「コールイベント」メッ セージは自動的にＣＢＸ１９０２によってイベントハンドラ（event handler） １９１７に伝送される。このイベントハンドラ１９１７は、モディファイドイベ ントログ（modified event log）１９２２にこのイベントコールを格納する。コ ールイベントは、各々の新たなコール、コール転送、コールハングアップなどに 対して生成され、各コールイベントは、発呼者（caller）の電話番号、ぞのコー ルに応答したのは誰か、などのような特定の情報を含む。 本発明の原理によれば、図１（ａ）に図示されたデータエントリプログラム１ ３の修正バーションであるモディファイドデータエントリプログラム１９２０は 、各エージェントの電話コールに関連する「ビジネス値」を示すレコードのコピ ーをビジネスイベントハンドラ１９２１に伝送する。このビジネスイベントハン ドラ１９２１はこれらのレコードをモディファイドイベントログ１９２２に格納 する。セールスをレコードするデータエントリアプリケーションにとっては、例 えば、エージェントの電話コールの「ビジネス値」は、セールの全ドル値であり うる。宣伝用アイテムを発呼者に郵送するべきであると指示するアプリケーショ ンにとっては、このようなアイテム（あるいはこのア イテムの値）を指示するフラグは、モディファイドイベントログ１９２２に格納 される。従って、モディファイドイベントログ１９２２は、（「応答」イベント 、「放棄されたコール」イベントなどのような）電話コールイベントに関するレ コードのみを有するのではなく、特定の電話コールに関連する「ビジネス値」に エージェント情報を関連させるレコードも含む。 付加的に、モディファイドデータエントリプログラム１９２０はも「アカウン トコードレコード（account code record）」を、コールの性質又のタイプを示 すアカウントコードを有するビジネスイベントハンドラ１９２１へと伝送する。 アカウントコードは、たとえあるにしても、電話コールから生成されるいかなる ビジネス値からも完全に独立している。例えば、エージェントが保険コールをサ ービスした場合、このエージェントは、コールが自動車保険、生命保険又は住宅 保険のためのものであるかを示すキーを押せばよい。そして、このキーはアカウ ントコールに翻訳され、エージェント識別子のようなコールに関連する他の情報 を有するレコードに格納される。 従って、まとめれば、様々な実施形態において、モディファイドイベントログ １９２２は３つのタイプのレコードを有する。 （１）（コールの応答、転送又は放棄のような）一部の電話コールをエージェン トが特定のハンドリングを することに関連する情報をそれぞれ含むコールイベントレコード。 （２）エージェントの電話コールを電話コールに関連するビジネス値にそれぞれ 相互関連させるビジネス値レコード。 （３）特定のエージェントの電話コールを電話コールの性質又はタイプにそれぞ れ相互関連させるアカウントコードレコード。 本発明の実施形態が、少なくとも上述した情報の幾つかをモディファイドイベ ントログ１９２２からコンピュータ１９２７へと伝送することを意図している。 このコンピュータ１９２７において、レコードは、さらに処理される。しかし、 各電話コールは、典型的には複数の電話コールイベントを含んでおり、従って、 モディファイドイベントログ１９２２で複数のコールイベントレコードを生成す るので、コンピュータ１９２７へと伝送されるレコードの数を低減することが望 ましい。これを実施するために、コールセグメントジェネレータ１９２４は、同 一の電話コール「セグメント」に関連するコールイベントを集め、これらを「セ グメントレコード」と呼ばれるシングルレコードに統合整理する。各コールセグ メントは、ただ１人の人物又はただ１つのエージェントに関連する。コールセグ メントレコードは、電話コールが応答された時に生成され、コントロールする人 物が別の人物へのコールを コントロールする時か、又は（ハングアップ又は放棄のように）コールが終了し た時に終了される。もしコールが別のエージェントに転送されたならば、第２の コールセグメントレコードが第２のエージェントに対して生成される。言い換え れば、各レコードは、電話コールの一人のエージェントの部分にのみ関係する。 もしコールがあるエージェントから別のエージェントに転送されるならば、２つ のレコードが生成される。もしコールセグメントが異常な仕方で終了されたら（ これはシステムエラーによって発生するかもしれない）、タイムアウトスケジュ ールに従って不完全なセグメントを削除するための“flush”機能を用意する。 コンピュータ１９０１からコンピュータ１９２７まで伝送される、コールセグ メントレコードに対する１つの可能なフォーマットが、図２０（ａ）及び２０（ ｂ）に図示されている（集合的に図２０を参照）。打ち切り値のシンボル“ＮＡ ”は、フィールドがより小さくてはいけない、フィールドは妥当なデータを有す る必要がある、ということを示す。他方で、“BLANK”は、フィールド値はより 小さくても良く、１つのブランク文字が空白のフィールドを表す、ということを 示す。しかし、図２０のレコードフォーマットは、ただの一例であり、様々な他 のフォーマットを使用してもよい。さらに、図２０に図示されたフィールドの全 てを、本発明を実施するために伝送することは、必ず しも必要ない。 要約すれば、各コールセグメントレコードは、モディファイドイベントログ１ ９２２に格納された複数のコールイベントレコードの統合整理されたバージョン を有している。この統合整理は、コンピュータ１９２７に伝送されるべきデータ レコードの数を低減させるために様々な実施形態いおいて行われる。図２０のレ コードの第１のフィールドは、レコード識別のためのものであることに注意すべ きである。この場合、“Ｃ”は、このレコードがコールセグメントレコードであ ることを示す。レコードは、（pipe又は“｜”シンボルのような）セパレータキ ャラクタによって終了されたフィールドを有するＡＳＣＩＩキャラクタのシーク エンスとして伝送される。様々な実施形態においては、フィールドセパレータを 使用して空白のフィールドを圧縮することが望ましい。このような圧縮は周知で あり、ここでは詳しく述べない。 コールセグメントジェネレータ１９２４によって生成されたコールセグメント レコードは、データインターフェース１９２６を介してコンピュータ１９２７に 伝送されるために出力キュー１９２５は、配置される。全ての実施形態に出力キ ュー１９２５が要求されなくてもよいが、この出力キュー１９２５は、出力メッ セージをコンピュータ１９２７のオペレーションから隔絶させるのに役立つ。例 えば、もしコンピュータ１ ９２７が接続を切断されるか破壊されるかした場合、コンピュータ１９０９から の出力メッセージは紛失しはしないが、代わりにコンピュータ１９２７への接続 が復旧するまで程度な期間（例えば一日）の間キューに入れられることもあり得 る。さらに、様々なスタート/ストップコマンドがデータインターフェース１９ ２６及び１９２８に供給され、コンピュータ間のデータ転送の開始と終了とを調 整する。データインターフェース１９２６は、ＩＢＭで利用できるコンベンショ ナルＬＵ６.２プロトコルのような何らかの適切なコミュニケーションパッケー ジを有する。データインターフェース１９２６は、エラーチェック機能を有し、 コンピュータ１９０１とコンピュータ１９２７との間の信頼性のあるコミュニケ ーションを保証する。 ビジネスイベント検索機能１９２３は、ビジネス値レコード及びアカウントコ ードレコードをモディファイドイベントログ１９２２から検索し、これらをコン ピュータ１９２７に出力キュー１９２５を介して伝送する。図２１は、コンピュ ータ１９０１からコンピュータ１９２７へ伝送されるビジネス値レコードのため の１つの可能なフォーマットを示しており、図２２は、同じように伝送されるア カウントコードレコードのための１つの可能なフォーマットを示している。各レ コードの第１のフィールドはレコードタイプを示し、そのためコンピュータ１９ ２７がこれを受け取った時 にこのレコードタイプを識別することができることが見て取れる。コールセグメ ントレコードに関して上述したように、この特別のフィールド及びフォーマット は単なる例である。 再び図１９について言及する。ＩＢＭ ＲＳ/６０００コンピュータから構成 されうるコンピュータ１９２７は、コンピュータ１９０１から伝送されたレコー ドを受け取るためのデータインターフェース１９２８を有する。メッセージハン ドラ１９２９は、コンピュータ１９０１からのコールセグメントレコード、ビジ ネス値レコード及びアカウントコードレコードを含むレコードを受け取る。コン ピュータ１９２７のビジネス値及びアカウントコード機能部分のオペレーション を詳しく再び見る前に、データベース１９３４のデータアイテムの混合を明確に するために、データ収集装置１９３１のオペレーションをまず再び見ておく。 データ収集装置１９３１は、ＣＢＸ１９０２及びＣＢＸ１９０３からスケジュ ールされたベースに基づいて電話コール統計量を集め、この統計量をデータベー ス１９３４のテーブル１９３５のレコードの中に格納する。各レコードは、例え ば１５分間のように所定の時間間隔に亘ってまとめられた、各ＣＢＸないで認識 される、各エージェント及びエージェントの各グループ毎の統計量を含むデータ を有する。タイムベースアキュムレータ１９４０は、各データ収集サイクルの間 に、所定の時間間隔に従ってテーブル１９３５からの複数のレコードに関する統 計量を累積するために演算し、累積された値を累積テーブル１９３８に格納する 。例えば、タイムベースアキュムレータ１９４０は、テーブル１９３５の１５分 間分のデータをシフトレコード、一日単位のトータルレコード、週単位のトータ ルレコード、そして月単位のトータルレコードに累積し、このようなレコードを テーブル１９３８に格納する。 付加的に、組織アキュムレータ１９３２は、各データ収集サイクルの間に、コ ンフィグレーションデータベース１９３７に格納された組織階層に基づくテーブ ル１９３５から、複数のレコードに関する統計量を累積するために演算し、累積 された統計量を累積テーブル１９３８に格納する。組織階層は、本明細書のセク ションIで記述したように、組織ジェネレータ１９４１によって形成される。従 って、累積テーブル１９３８は、所定の期間及び所定の組織階層に亘って累積さ れたレコードを含む。そして、レポートジェネレータ１９３３が累積テーブル１ ９３８からデータを検索し、本明細書のセクションIで記述したように、様々な レポートを作成する。 コンピュータ１９０１から検索されたビジネス値レコード及びアカウントコー ドレコードは、所定の期間をベースにした情報よりもむしろコールをベースにし た情報を含んでいるので、データ収集装置１９３１によってテーブル１９３５に 格納されたデータレコードと適合するために、ビジネス値アキュムレータ１９３ ０は、各エージェント及びエージェントのグループに対するこのようなレコード を、所定の時間間隔、例えば１５分間を有するレコードに累積する。ビジネス値 アキュムレータ１９３０によって累積されたレコードはその後テーブル１９３６ に格納される。このテーブル１９３６は、テーブル１９３５とは別個のものであ るように示されているが、テーブル１９３５に含まれてもよい。従って、ビジネ ス値アキュムレータ１９３０は、ＣＢＸ１９０２及び１９０３の各々において行 われる初期累積に類似した機能を実行する。 本発明の原理によれは、タイムベースアキュムレータ１９４０もテーブル１９ ３６からビジネス値レコード及びアカウントコードレコードを累積し、相応して この累積レコードをテーブル１９３８に格納する。すなわち、ビジネス値レコー ド及びアカウントコードレコードは、エージェントをベースにして（そして、Ｃ ＢＸ１９０２及び１９０３によって認識されるグループに対するグループをベー スにして）累積され、テーブル１９３８に格納される。例えば、累積されたテー ブル１９３８の中のレコードは、さらに、一日、一週間、一ヶ月間のような所定 の期間に亘って各エージェントによって形成されたトータルビジネス値を示すフ ィールド、及び一日、一週間、一ヶ月間のような所定の期間に亘って各エージェ ントによってサービスされたアカウントコードの各々のタイプのトータルを示す フィールドを含んでいる。 同様に、組織アキュムレータ１９３２は、コンフィグレーションデータベース １９３７に格納された組織階層に従って、ビジネス値レコード及びアカウントコ ードレコードを累積する。すなわち、例えば、ビジネス値レコード及びアカウン トコードレコードは、管理者、マネージャー、重役、副社長等々（経営管理階層 ）に従って、そしてセールスグループ、部局、部門及び会社全体（会社階層）に よって累積される。ビジネス値及びアカウントコードのこのような累積によって 、依然は生成できなかったレポートをレポートジェネレータ１９３３によって生 成することができる。従って、例えば、特定のエージェント又は会社の特定の部 局等々ごとに、特定の期間中のトータルの販売高がどのくらいだったかを決定す ることもできるのである。 コールトレーサ１９４２は、１９３９を探索して特定の電話コールの運用をト レースするために使用される。例えば、特定の番号の電話コールに対してコール セグメントレコードを探索し、そのコールの運用にかかわっている全てのエージ ェントを識別することができる。コールセグメントレコードで利用可能な他のデ ータフィールド（図２０参照）は、同様に特定のコー ル又はコールセグメントを探索するために使用される。セグメントをベースにし て又はコールをベースにして格納された、このような「生の」データは、データ 収集装置１９３１によっては通常は収集されない。従って、このような「生の」 データは、コンピュータ１９２７からのデータを解析するための付加的な機能を 表す。 こうして、２つのコンピュータ間で（コールセグメント、ビジネス値及びアカ ウントコード情報を含んだ）電話コール情報を交換し、様々な時間間隔及び組織 階層に情報を累積し、この情報からレポートを作成するための、新しい有益な発 明を上に説明した。ここでハードウェア又はコンピュータプログラムに対する特 別な言及は単なる例にすぎないことを理解してほしい。ハードウェアコンポーネ ントとソフトウェアコンポーネントとの間の機能の特別なアロケーションは、特 定のインプリメンテーションに含まれる特定の要請及びエンジニアリングトレー ドオフによって指示されたものである。また、本発明の方法を実施するために使 用される様々なステップの特定の順番は、同じ又は実質上同じ結果を得るために 配列を変えてもよいと認めてほしいし、従属請求項の中のステップのナンバリン グは言及しやすいようにするために行っただけであり、この従属請求項の中のス テップのナンバリングは、本発明の方法を実施可能にする必要がない限りは、請 求されたステップの範囲を特定の順番に限定するものではない、ということを認 めてほしい。 明らかに、本発明の多くの修正及びバリエーションが上述の説明の範囲内で可 能である。特定の値、部分番号又は規格は、単なる例である。それゆえ、従属請 求項の範囲内で、本発明をここに特に記述したのとは別のやり方で実施すること ができることは理解してもらえるだろう。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ゲイル マリネリ アメリカ合衆国 95030 カリフォルニア ロス ゲイトス オークモント ドライ ヴ 19775 (72)発明者 バーバラ チン アメリカ合衆国 95051 カリフォルニア サンタ クララ ミラプラザ コート 1902 ナンバー 30 【要約の続き】 コールセグメントレコードを受信し、これらをデータベ ースに記憶し、かつビジネス値、アカウントコードを固 定の時間間隔および１つの又は複数の組織的階層に従っ て複数のレコードに亘って累積する。累積された値から 使用可能なレポートを作成するためのレポートジェネレ ータが設けられている。

Claims (1)

1. 【特許請求の範囲】 １．複数の電話エージェントをサービスするコンピュータ化された構内交換機 （ＣＢＸ）に接続されている第１のコンピュータと、データベースを有する第２ のコンピュータとの間で電話コール情報を交換する方法において、次のステップ を有する： （１）前記第１のコンピュータにおけるデータエントリプログラムに続いて複数 のビジネス値レコードを生成するステップ、この場合ビジネス値レコードはそれ ぞれ、前記電話エージェントの１つを、該１つの電話エージェントによって実施 される１つ又は複数のデータ入力操作に相応するビジネス値日付に関連付ける情 報を有しており、 （２）前記第１のコンピュータに前記複数のビジネス値レコードを記憶するステ ップ、 （３）前記記憶された複数のビジネス値レコードの１つ又は複数を検索するステ ップ、および （４）前記検索されたビジネス値レコードを前記第１のコンピュータから前記第 ２のコンピュータにリンクを介して伝送するステップ を有することを特徴とする方法。 ２．さらに次のステップを有する： （５）前記第１のコンピュータにおいて、前記ＣＢＸから、前記複数の電話エー ジェントの１つ又は複数に よって扱われた１つの電話コールにそれぞれが関連している複数の電話コールイ ベントを受信し、 （６）前記複数の電話コールイベントを前記第１のコンピュータに記憶し、 （７）前記複数の電話コールイベントを前記電話エージェントの１つに関連する コールセグメントレコード内に整理し、かつ （８）前記コールセグメントレコードを前記第１のコンピュータから前記第２の コンピュータにリンクを介して伝送する 請求項１記載の方法。 ３．さらに次のステップを有する： （５）前記第２のコンピュータにおいて前記伝送されたビジネス値レコードを受 信し、 （６）前記受信されたビジネス値レコードを前記第２のコンピュータにおける前 記データベース中に記憶し、 （７）前記複数のレコードされたビジネス値記憶を前記第２のコンピュータにお ける前記データベースから読み出し、 （８）前記データベースから読み出された複数のビジネス値レコードから抽出さ れた複数のビジネス値を累積された値に累積し、かつ （９）前記累積された値を含んでいるレポートを作成する 請求項１記載の方法。 ４．前記累積ステップは次のステップを有する： 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を第１の固定時間間隔に相応する第１の累積された値に累積しか つ該第１の累積された値を前記データベースに記憶し、かつ 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を第２の固定時間間隔に相応する第２の累積された値に累積しか つ該第２の累積された値を前記データベースに記憶する 請求項３記載の方法。 ５．前記累積ステップは次のステップを有する： それぞれが、前記ビジネス値がそれを超えたら累積されるようにする累積レベル を定める少なくとも２つのレベルを有している組織的階層を設け、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を前記組織的階層の第１のレベルに相応する第１の累積された値 に累積しかつ該第１の累積された値を前記データベースに記憶し、かつ 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を前記組織的階層の第２のレベルに相応する第２の累積された値 に累積しかつ該第２の累積された値を前記データベースに記憶する 請求項３記載の方法。 ６．前記ステップ（１）は、ビジネス値日付としての課金合計を含んでいるビ ジネス値レコードを生成するステップを有している 請求項１記載の方法。 ７．さらに次のステップを有している： （５）前記第２のコンピュータにおいて前記伝送されるビジネス値レコードを受 信し、 （６）前記受信されたビジネス値レコードを前記第２のコンピュータにおける前 記データベースに記憶し、 （７）前記複数の記憶されたビジネス値レコードを前記第２のコンピュータにお ける前記データベースから読み出し、 （８）前記データベースから読み出された複数のビジネス値レコードから抽出さ れた複数のビジネス値を第１の固定時間間隔に相応する第１の累積された値に累 積しかつ該第１の累積された値を前記データベースに記憶し、かつ （９）前記データベースから読み出された複数のビジネス値レコードから抽出さ れた複数のビジネス値を組織的階層に相応する第２の累積された値に累積しかつ 該第２の累積された値を前記データベースに記憶する請求項１記載の方法。 ８．ステップ（５）ないし（９）を複数回繰り返すステップを有しておりかつ そこから第１の数の累積された値および第２の数の累積された値を生成する 請求項７記載の方法。 ９．さらに、前記第２のコンピュータからフォーマット化されたレポートを作 成するステップを有しており、該フォーマット化されたレポートは前記第１の数 の累積された値および第２の数の累積された値を有している 請求項８記載の方法。 10．さらに次のステップを有する： （５）前記第１のコンピュータにおける前記データえんとりプログラムに続いて 、複数のアカウントコードレコードを生成するステップ、この場合アカウントコ ードレコードはそれぞれ、前記１つの電話エージェントを１つの電話コールの特 性を指示するアカウントコード日付に関連付ける情報を有しており、 （６）前記複数のアカウントコードレコードを前記第１のコンピュータに記憶す るステップ、 （７）前記複数の記憶されたアカウントコードレコードを検索するステップ、お よび （８）前記検索されたアカウントコードレコードを前記第１のコンピュータから 前記第２のコンピュータに前記リンクを介して伝送するステップ 請求項１記載の方法。 11．さらに次のステップを有する： （９）前記第２のコンピュータにおいて前記伝送されたアカウントコードレコー ドを受信し、 （10）該受信されたアカウントコードレコードを前記第２のコンピュータにおけ る前記データベースに記憶し、 （11）前記第２のコンピュータにおいて前記データベースから前記複数の記憶さ れたアカウントコードレコードを読み出し、 （12）前記データベースから読み出された前記複数のアカウントコードレコード から抽出された複数のアカウントコード値を１つ又は複数の累積されたアカウン トコード値に累積し、かつ （13）前記１つ又は複数の累積されたアカウントコード値を有するレポートを作 成する 請求項11記載の方法。 12．複数の電話エージェントをサービスするコンピュータ化された構内交換機 （ＣＢＸ）に接続されている第１のコンピュータと、データベースを有する第２ のコンピュータとの間で電話コール情報を交換する装置において、該装置は、 前記第１のコンピュータにおけるデータエントリプログラムに続いて、前記電話 エージェントの１つを、該１つの電話エージェントによって実施される１つ又は 複数のデータエントリ操作に相応するビジネス値日付 に関連付ける情報をそれぞれが有している複数のビジネス値レコードを生成する ための手段と、 前記第１のコンピュータに前記複数のビジネス値レコードを記憶するための手段 と、 前記記憶された複数のビジネス値レコードの１つ又は複数を検索するための手段 と、 前記呼び出されたビジネス値レコードを前記第１のコンピュータから前記第２の コンピュータにリンクを介して伝送するための手段と を有していることを特徴とする装置。 13．さらに、 前記第１のコンピュータにおいて、前記ＣＢＸから、前記複数の電話エージェン トの１つ又は複数によって扱われた１つの電話コールにそれぞれが関連している 複数の電話コールイベントを受信するための手段と、 前記複数の電話コールイベントを前記第１のコンピュータに記憶するための手段 と、 前記複数の電話コールイベントを前記電話エージェントの１つに関連するコール セグメントレコード内に整理するための手段と、 前記コールセグメントレコードを前記第１のコンピュータから前記第２のコンピ ュータにリンクを介して伝送するための手段と を有している 請求項12記載の装置。 14．さらに、 前記第２のコンピュータにおいて前記伝送されるビジネス値レコードを受信する ための手段と、 前記第２のコンピュータにおいて前記受信されたビジネス値レコードを該第２の コンピュータにおける前記データベース中に記憶するための手段と、 前記複数の記憶されたビジネス値レコードを前記第２のコンピュータにおける前 記データベースから読み出すための手段と、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を累積された値に累積するための手段と、 前記累積された値を含んでいるレポートを作成するための手段と を有している 請求項12記載の装置。 15．前記累積手段は、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を第１の固定時間間隔に相応する第１の累積された値に累積しか つ該第１の累積された値を前記データベースに記憶するための手段と、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を前記第１の固定時間間隔とは異なった第２の固定時間間隔に相 応する第２の累積された値に累積しかつ該第２の累積された値を前記データベー スに記憶するための手段とを有している 請求項14記載の装置。 16．前記累積手段は、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を前記組織的階層の第１のレベルに相応する第１の累積された値 に累積しかつ該第１の累積された値を前記データベースに記憶し、かつ 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を前記組織的階層の第２のレベルに相応する第２の累積された値 に累積しかつ該第２の累積された値を前記データベースに記憶するための手段と を有している 請求項14記載の装置。 17．前記ビジネス値レコードは、ビジネス値日付としての課金合計を含んでい る 請求項12記載の装置。 18．さらに、 前記第２のコンピュータにおいて前記伝送されたビジネス値レコードを受信する ための手段と、 前記受信されたビジネス値レコードを前記第２のコンピュータにおける前記デー タベースに記憶するための 手段と、 前記複数の記憶されたビジネス値レコードを前記第２のコンピュータにおける前 記データベースから読み出するための手段と、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を第１の固定時間間隔に相応する第１の累積された値に累積しか つ該第１の累積された値を前記データベースに記憶するための手段と、 前記データベースから読み出された複数のビジネス値レコードから抽出された複 数のビジネス値を組織的階層に相応する第２の累積された値に累積しかつ該第２ の累積された値を前記データベースに記憶するための手段と を有している 請求項12記載の装置。 19．累積するための前記第１の手段は第１の数の累積された値を累積しかつ記 憶しかつ累積するための前記第２の手段は第２の数の累積された値を累積しかつ 記憶する 請求項18記載の装置。 20．さらに、 前記第２のコンピュータからフォーマット化されたレポートを作成するための手 段を有しており、該フォーマット化されたレポートは前記第１の数の累積された 値および第２の数の累積された値を有している 請求項19記載の装置。 21．さらに、 前記第１のコンピュータにおいて、それぞれが、前記１つの電話エージェントを １つの電話コールの特性を指示するアカウントコード日付に関連付ける情報を有 している複数のアカウントコードレコードを生成するための手段と、 前記複数のアカウントコードレコードを前記第１のコンピュータに記憶するため の手段と、 前記複数の記憶されたアカウントコードレコードを検索するための手段と、 前記呼び出されたアカウントコードレコードを前記第１のコンピュータから前記 第２のコンピュータに前記リンクを介して伝送するための手段と を有している 請求項12記載の装置。 22．さらに、 前記第２のコンピュータにおいて前記伝送されたアカウントコードレコードを受 信するための手段と、 前記第２のコンピュータにおいて受信された前記アカウントコードレコードを前 記第２のコンピュータにおける前記データベースに記憶するための手段と、 前記第２のコンピュータにおいて前記データベースから前記複数の記憶されたア カウントコードレコードを 読み出すための手段と、 前記データベースから読み出された前記複数のアカウントコードレコードから抽 出された複数のアカウントコード値を１つ又は複数の累積されたアカウントコー ド値に累積するための手段と、 前記１つ又は複数の累積されたアカウントコード値を有するレポートを作成する ための手段と を有する 請求項21記載の装置。 23．複数の電話エージェントをサービスするコンピュータ化された構内交換機 （ＣＢＸ）に接続されている第１のコンピュータと、データベースを有する第２ のコンピュータとの間で電話コール情報を交換するための装置において、該装置 は、 前記第１のコンピュータにおけるデータ入力プログラムに接続されているビジネ スイベントハンドラを備え、該ビジネスイベントハンドラは、それぞれが、前記 電話エージェントに１つを該１つの電話エージェントによって実施された１つ又 は複数のデータエントリ操作に相応するビジネス値に関連付ける情報を含んでい る複数のビジネス値レコードを生成し、 前記複数のビジネスレコードを前記第１のコンピュータに記憶するためのイベン トログと、 前記記憶されたビジネス値レコードの１つ又は複数を前記イベントログから検索 するためのビジネスイベン ト検索機能と、 前記検索されたビジネス値レコードを前記第１のコンピュータから前記第２のコ ンピュータにリンクを介して伝送するためのデータインタフェースと を備えている ことを特徴とする装置。 24．前記ＣＢＸから複数の電話コールイベントを受信しかつ前記イベントログ に記憶するためのコールイベントハンドラを備え、該コールイベントは、前記複 数の電話エージェントの１つ又は複数によって扱われた電話コールに関連してお り、 前記イベントログに接続されているコールセグメント発生器を備え、該コールセ グメント発生器は、前記複数の電話コールイベントを前記電話エージェントの１ つに関連したコールセグメントレコード内に整理しかつ該コールセグメントレコ ードを前記データインタフェースを介して前記第２のコンピュータに伝送する 請求項２３記載の装置。 25．複数の電話エージェントをサービスするＣＢＸに接続されているコンピュ ータから伝送されるビジネス値レコードを累積するための装置において、該装置 は、 前記コンピュータから、それぞれが、前記電話エージェントの１つを前記コンピ ュータにおいて該１つの電話エージェントによって実施された１つ又は複数のデ ータエントリ操作に相応するビジネス値に関連付ける情報を含んでいる複数のビ ジネス値を受信するためのデータインタフェースと、 前記データインタフェースによって受信された前記ビジネス値レコードを前記第 ２のコンピュータにおける前記データベースに記憶するためのビジネス値アキュ ムレータと、 前記複数の記憶されたビジネス値レコードを前記データベースから読み出しかつ そこから抽出された複数のビジネス値を累積するためのタイムベースアキュムレ ータと、 前記累積されたビジネス値を含んでいるレポートを作成するためのレポートジェ ネレータと を有している 請求項25記載の装置。 26．前記時間ベースアキュムレータは、前記複数のビジネス値を前記第１の固 定時間間隔に従って第１の累積されたビジネス値に累積しかつ前記第１の累積さ れたビジネス値を前記データベースに記憶し、かつさらに、前記複数のビジネス 値を前記第２の固定時間間隔に従って第２の累積されたビジネス値に累積しかつ 前記第２の累積されたビジネス値を前記データベースに記憶する 請求項２５記載の装置。 27．さらに、 前記データベースから読み出された前記複数のビジネス値から抽出された複数の ビジネス値を組織的階層の第１のレベルに相応する第１の累積された値に累積し かつ該第１の累積された値を前記データベースに記憶し、かつ前記データベース から読み出された前記複数のビジネス値から抽出された前記複数のビジネス値を 前記組織的階層の第２のレベルに相応する第２の累積された値に累積しかつ該第 ２の累積された値を前記データベースに記憶するための組織編成アキュムレータ を有している 請求項25記載の装置。 28．前記ビジネス値レコードは、ビジネス値日付としての課金合計を含んでい る 請求項25記載の装置。 29．前記タイムベースアキュムレータは複数のビジネス累積値を生成しかつそ れに相応するレコードを前記データベースに記憶する 請求項25記載の装置。 30．前記レポートジェネレータは前記レポートをユーザ定義レポートテンプレ ートに従ってフォーマット化する 請求項25記載の装置。 31．前記データインタフェースはさらに、前記コンピュータから、それぞれが 、前記１つの電話エージェントを電話コールの特性を指示するアカウントコード 日付に関連付ける情報を含んでいる複数のアカウントコードレコードを受信し、 前記ビジネス値アキュムレータは前記複数のアカウントコードレコードを前記デ ータベースに記憶し、 前記タイムベースアキュムレータはさらに、前記複数の記憶されたアカウントコ ードレコードを前記データベースから読み出しかつそこから抽出された複数のア カウントコード値を１つの累積されたアカウントコード値に累積する 請求項25記載の装置。 32．前記複数の電話エージェントをサービスするコンピュータ化された構内交 換機（ＣＢＸ）に接続されている第１のコンピュータから電話コール情報を累積 するための装置において、 前記第１のコンピュータから、それぞれが、前記電話エージェントの１つを、該 １つの電話エージェントによって実施された１つ又は複数のデータエントリに相 応するビジネス値日付に関連付ける情報を含んでいる複数のビジネス値を受信す るための手段と、 前記ビジネス値レコードから抽出された複数のビジネス値を１つの累積されたビ ジネス値レコードに累積しかつ該累積されたビジネス値レコードをデータベース に記憶するための手段と、 前記データベースから複数の累積されたビジネス値レコードを検索しかつそこか ら累積されたビジネス値を 抽出するための手段と、 固定時間間隔に相応して、前記ビジネス値レコードから抽出された前記複数の累 積されたビジネス値を時間累積されたレコードに累積しかつ前記時間累積された レコードを前記データベースに記憶するための時間累積手段と、 組織的階層に応じて、前記ビジネス値レコードから抽出された前記複数の累積さ れたビジネス値を組織的に累積されたレコードに累積しかつ前記組織的に累積さ れたレコードを前記データベースに記憶するための組織的な累積手段と を有している ことを特徴とする装置。 33．さらに、前記時間累積されたレコードからの情報を有しているフォーマッ ト化されたレポートを作成するための手段を有している 請求項32記載の装置。 34．前記受信手段は、前記第１のコンピュータから、それぞれが、前記１つの 電話エージェントを電話コールの特性を指示するアカウントコード日付に関連付 ける情報を含んでいる複数のアカウントコードレコードを受信するための手段を 有しており、 前記累積手段は、前記アカウントコードレコードから抽出された複数のアカウン トコード値を累積しかつ前記累積されたアカウントコードレコードを前記データ ベースに記憶するための手段を有しており、 前記検索手段は、複数の累積されたアカウントコードレコードを前記データベー スから検索しかつそこから累積されたアカウントコード値を抽出するための手段 を有し、 前記時間累積手段は、前記固定時間間隔に従って、前記アカウントコードレコー ドから抽出された複数の累積されたアカウントコード値を前記時間累積されたレ コード内に累積するための手段を有しており、かつ前記組織的累積手段は、前記 組織的階層に従って、前記アカウントコードレコードから抽出された前記複数の 累積されたアカウントコード値を、前記データベース内の前記組織的に累積され たレコード内に累積するための手段を有している 請求項32記載の装置。 35．前記検索手段は、前記第１のコンピュータから、それぞれが、電話コール セグメント属性を前記エージェントの１つに関連付ける情報を含んでいる複数の コールセグメントレコードを受信するための手段を有しており、 前記装置はさらに、 受信されたコールセグメントレコードを前記データベースに記憶するための手段 と、 １つの共通の識別子を有している、前記データベースからの複数のコールセグメ ントレコードをリンクする ことによって１つの電話コールを追跡するための手段と を有している 請求項32記載の装置。