(57)【特許請求の範囲】
【請求項１】
第１の当事者によって維持される第１のデータベースと、
前記第１の当事者とは異なる第２の当事者によって維持される第２のデータベースと、
前記第２のデータベースに追加されるべきデータを指定する作業待ち行列手段と、
前記第１のデータベースから前記作業待ち行列手段にデータを書き込む抽出、変換およびロード手段と、
前記作業待ち行列から前記第２のデータベースにデータをインポートするデータ・インポート手段と
を備え、前記第１の当事者に、前記第２のデータベースに直接前記データを書き込む特権が与えられず、前記データ・インポート手段は、
データベース・レコードへの変化についての仕様セットと関連づけられた第１の属性セットを、前記データベース・レコードについての前記第２のデータベース内の既存の第２の属性セットと比較する動作であって、前記第１の属性セットおよび前記第２の属性セットが前記データベース・レコードと関連づけられており、ならびに前記第１の属性セットおよび第２の属性セットがタイプ２の属性を含んでいる動作と、
前記第１の属性セットが前記第２の属性セットと異なる場合に、タイプ２の属性が変化したかどうかを決定する動作であって、前記タイプ２の属性が前記第１の属性セットおよび前記第２の属性セットと関連づけられており、および前記タイプ２の属性が前記データベース・レコードに対する変化と関連づけられている動作と、
タイプ２の属性が変化しなかったときに、前記第２のデータベース内の前記データベース・レコードへのタイプ１の更新を実行する動作と、
タイプ２の属性が変化したときに、新しいデータベース・レコードを識別するために新しい代理キーを生成し、および前記新しい代理キーを含み、かつ前記第１のセットの属性により記述される前記新しいデータベース・レコードを、前記第２のデータベースに挿入する動作と、を遂行するものであるデータ処理システム。
【請求項２】
前記第１の当事者は顧客であり、前記第２の当事者は前記第２のデータベースの供給元であり、前記第１の当事者には前記第２のデータベースのセマンティクスを変更する特権が与えられておらず、前記第１の当事者には、前記第２のデータベースから既存のデータを削除し、前記第２のデータベース内の既存のデータを更新する特権が与えられておらず、前記第２の当事者には、前記第１のデータベースのセマンティクスを変更する特権が与えられておらず、
前記インポートされたデータを収容するために前記第２のデータベース内のタイプ２次元セマンティクスを変化させるセマンティクス手段
をさらに備える請求項１に記載のシステム。
【請求項３】
前記第１の当事者には、前記第２のデータベースの少なくとも選択された部分を閲覧する特権が与えられ、
前記第１の当事者によって提供される、第２の当事者によって維持される第２のデータベースを拡張する仕様と、
前記仕様を反映し、変更に対応する前記作業待ち行列手段を作成するように前記第２のデータベースを記述するデータ・モデルを変更する変更手段
をさらに備える請求項２に記載のシステム。
【請求項４】
前記作業待ち行列手段は、前記第２のデータベースにとって外部である、前記第１のデータベースへの自然キーを備え、前記データ・インポート手段は、前記自然キーを、前記第２のデータベースにとって内部であり、前記第１のデータベースにとって外部であるキーに変換し、前記変更は、
（ｉ）前記第２のデータベース内の既存のファクト表へのカスタム・ファクトの追加、
（ｉｉ）前記第２のデータベース内の既存のファクト表に対応する新しい表へのカスタム・ファクトの追加、
（ｉｉｉ）前記第２のデータベース内の既存の次元表へのカスタム属性の追加、
（ｉｖ）前記第２のデータベース内の既存の次元表に対応する新しい表へのカスタム属性の追加、および
（ｖ）カスタム表の追加
のうちの少なくとも１つである請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
（ａ）第１の当事者から、第２の当事者によって維持される第２のデータベースへの拡張を定義する仕様セットを受け取る工程と、
（ｂ）前記仕様セットに記述されるように、前記第２のデータベースに、カスタム表と表のカスタム列の少なくとも１つを含む変更を行う工程と、
（ｃ）前記変更に対応する作業待ち行列を作成する工程と、
（ｄ）前記作業待ち行列が第１のデータベースから第１のデータを受け取る工程と、
（ｅ）前記第１のデータベースと意味的に互換性があり、前記第２のデータベースと意味的に互換性がない前記第１のデータを、前記第１のデータベースと意味的に互換性がなく、前記第２のデータベースと意味的に互換性がある第２のデータを形成するように正規化する工程と、
（ｆ）前記第２のデータを、前記カスタム表と表のカスタム列の少なくとも１つに書き込む工程とを含み、この書き込む工程は、
（ｆ１）データベース・レコードへの変化についての仕様セットと関連づけられた第１の属性セットを、前記データベース・レコードについての前記第２のデータベース内の既存の第２の属性セットと比較する処理であって、前記第１の属性セットおよび前記第２の属性セットが前記データベース・レコードと関連づけられており、ならびに前記第１の属性セットおよび第２の属性セットがタイプ２の属性を含んでいる処理と、
（ｆ２）前記第１の属性セットが前記第２の属性セットと異なる場合に、タイプ２の属性が変化したかどうかを決定する処理であって、前記タイプ２の属性が前記第１の属性セットおよび前記第２の属性セットと関連づけられており、および前記タイプ２の属性が前記データベース・レコードに対する変化と関連づけられている処理と、
（ｆ３）タイプ２の属性が変化しなかったときに、前記第２のデータベース内の前記データベース・レコードへのタイプ１の更新を実行する処理と、
（ｆ４）タイプ２の属性が変化したときに、（ｆ４i）新しいデータベース・レコードを識別するために新しい代理キーを生成し、および（ｆ４ii）前記新しい代理キーを含み、かつ前記第１のセットの属性により記述される前記新しいデータベース・レコードを、前記第２のデータベースに挿入する処理と、を含む方法。
【請求項６】
作業待ち行列は、複数の仕様セットのそれぞれについて作成され、前記第１の当事者は顧客であり、前記第２の当事者は前記第２のデータベースの供給元であり、前記第１の当事者には、前記第２のデータベースのセマンティクスを直接変更する特権が与えられておらず、前記第１の当事者には、前記第２のデータベースに直接書き込む特権が与えられておらず、前記第２の当事者には、前記第１のデータベースのセマンティクスを直接変更する特権が与えられておらず、
（ｇ）前記第１の当事者が、前記第１のデータベースの選択された部分だけを閲覧することができるようにする工程
をさらに含む請求項５に記載の方法。
【請求項７】
前記変更は、
（ｉ）前記第２のデータベース内の既存のファクト表へのカスタム・ファクトの追加、
（ｉｉ）前記第２のデータベース内の既存のファクト表に対応する新しい表へのカスタム・ファクトの追加、
（ｉｉｉ）前記第２のデータベース内の既存の次元表へのカスタム属性の追加、
（ｉｖ）前記第２のデータベース内の既存の次元表に対応する新しい表へのカスタム属性の追加、および
（ｖ）カスタム表の追加
のうちの少なくとも１つである請求項５乃至６のいずれか１項に記載の方法。
【請求項８】
工程（ｅ）において、前記作業待ち行列は、前記第２のデータベースにとって外部である、前記第１のデータベースへの自然キーを備え、データ・インポート・モジュールが、前記自然キーを、前記第２のデータベースにとって内部であり、前記第１のデータベースにとって外部であるキーに変換し、
（ｇ）工程（ｂ）の後に、前記処理された仕様セットを削除する工程
をさらに含む請求項５乃至７のいずれか１項に記載の方法。
【請求項９】
請求項５に記載の前記変更は（ｉ）である請求項７に記載の方法。
【請求項１０】
請求項５に記載の前記変更は（ｉｉ）である請求項７に記載の方法。
【請求項１１】
請求項５に記載の前記変更は（ｉｉｉ）である請求項７に記載の方法。
【請求項１２】
請求項５に記載の前記変更は（ｉｖ）である請求項７に記載の方法。
【請求項１３】
請求項５に記載の前記変更は（ｖ）である請求項７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にイベント処理を対象とし、詳細には、エージェント性能の監視を対象とする。
【背景技術】
【０００２】
自動着信呼分配（ＡＣＤ）システムなどのコンタクト・センタが、多くの企業によって顧客連絡先へのサービス提供に用いられている。典型的なコンタクト・センタは、着信するパケット交換方式および／または回線交換方式のコンタクト、ならびに、着信コンタクトにサービス提供するための、人間のエージェントや自動化リソース（対話型音声応答（ＩＶＲ）ユニットなど）といった１つまたは複数のリソースを受け取り、経路指定するスイッチおよび／またはサーバを含む。コンタクト・センタは、サービス提供するために、コンタクトを、それがインバウンドであれアウトバウンドであれ、所定の基準に従って任意の適当なリソースに分配する。多くの既存のシステムでは、コンタクト・センタがコンタクトに気付いたときからそのコンタクトがエージェントに接続されるまでそのコンタクトにサービス提供するための基準は、ベクトル化という機能を介して、顧客によって指定され得る（すなわち、コンタクト・センタのオペレータによってプログラムされ得る）。通常、今日のＡＣＤにおいて、ＡＣＤシステムのコントローラは、あるエージェントがコンタクトの処理に利用できるようになっていることを検出すると、そのエージェントのすべての所定のコンタクト処理技能を（普通は何らかの優先順で）識別し、そのエージェントに、そのエージェントの最優先の技能にマッチする最優先の最も旧いコンタクトを配信する。一般に、コンタクトが利用可能なエージェントに配信されない結果になる唯一の状態は、処理されるのを待っているコンタクトがない状態である。
【０００３】
呼分配アルゴリズムを含むコンタクト・センタ管理の主要な目的は、最終的に、コンタクト・センタの性能および収益性を最大にすることである。コンタクト・センタ管理における現在の１つの課題が、コンタクト・センタ・リソースの使用を最適化し、エージェントの性能および収益性を最大にするようにエージェント挙動を監視することである。コンタクト・センタの性能を監視し、報告する現行の製品、例えば、Ａｖａｙａ，Ｉｎｃ．によるＣａｌｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（ＣＭＳ）（商標）などは、複数のソースからデータを抽出し、そのデータを正規形に変換し、通常はバッチ・スケジュールで、そのデータをデータ・ウェアハウス・データベースにロードするように構成される。バッチ・ロードの後、さらなる計算および報告が行われる。
【０００４】
一般的な種類のデータ・ウェアハウスは、次元モデリングに基づくものである。次元モデリングは、世界を測定値とコンテキストに分けるデータ・モデルである。測定値は、普通、数値であり、繰り返し取り込まれる。数値測定値はファクトである。ファクトは、そのファクトが記録されるときに存在するテキスト・コンテキストに取り囲まれている。コンテキストは、しばしば、次元に細分される。ファクト表は、次元モデリングにおいて、コンテキスト・エンティティを参照する複数の外部キーを用いて測定値を論理的にモデル化するのに使用される。コンテキスト・エンティティは、それぞれ、関連した主キーを有する。「キー」とは、表などのデータ・コレクション内のエンティティまたはレコードのインスタンスを識別するデータ要素（例えば属性や列など）である。「主キー」とは、その値が表内の行を一意に識別する列または列の組み合わせ、あるいは、エンティティの各インスタンスを一意に識別するのに最適なものとして候補キーの中から選択された属性または属性グループである。「外部キー」とは、その値が別の表の主キーとマッチさせるのに必要な列または列の組み合わせを指し、あるいはある関係を介して子エンティティの一因となる親エンティティの主キーである。主キーの種類には、自然キー、すなわちユーザにとっての意味のあるキーと、代理キー、すなわち、人為的または人工的に設けられ、ユーザにとって無意味であり、自然キーの代替物として使用されるキーとが含まれる。
【０００５】
同じエンティティ（エージェントなど）が、複数のデータ・ソース（例えば着信呼システムと発信呼システムなど）で、異なる自然キーによって表される場合、従来のデータ・ウェアハウスは、そのエンティティを識別するために代理キーを生成し、割り当てる。代理キーは、データ・ウェアハウスによって管理される内部識別子である。例えば、コンタクト・センタにおいて、あるエージェントが、あるシステムからの着信呼と、別のシステムからの発信呼を、各システム上の異なる識別情報を用いて処理するとする。データ・ウェアハウスは、一般に、各データ・ソースを独立に処理し、後で、各ソースにまたがるデータ相関を実行する。
【０００６】
データ・モデルの中には、タイプ２と呼ばれる、ゆっくりと次元を変化させる挙動を指定するものがある。タイプ２次元は、ある期間にわたってエンティティに対する変更の履歴を追跡する。あるエンティティの属性が変更されたとき、例えば、コンタクト・センタ・エージェントがその技能セットまたはグループ・メンバーシップを変更したときには、そのエンティティの新しい代理キーが生成され、新しい行がデータベースに挿入される。今度は、そのエンティティに関連付けられたファクト・データが、適切な代理キーを参照することによって、その変更の前と後とに発生したアクティビティについて別個に追跡され得る。
【０００７】
コンタクト・センタ・ソフトウェア製品、特に、次元モデリング・ソフトウェアを含む製品の供給元の前に立ちはだかる進行中の問題が、通常、他の供給元から購入される企業データベース・アプリケーション（またはアプリケーション・ソフトウェア）とコンタクト・センタ・ソフトウェアとの統合である。コンタクト・センタ・ソフトウェアの供給元は、既存の企業データベース・アプリケーション・ソフトウェアとの統合が容易であることを求めているが、ソフトウェアの統合が、誤りや、さらに悪いことには、ソフトウェア誤動作を生じ得る意味的不整合およびその他の矛盾をもたらさないよう慎重であらねばならない。
【０００８】
この問題に対処するためにいくつかの手法が用いられてきた。
１つの手法では、データベースは、個々のデータベース・ユーザが行うことのできる拡張の種類を制御するために制限された能力を提供する。例えば、あるデータベース表所有者は、既存のデータを保護するために列削除を不許可にする。また、表所有者は、表に列を追加できるようにしようとしてもよく、表ユーザが固定された列セットを追加することができるようにデータベースを構成することもできる。しかしながら、既存の列が、それらの値に対する、従来のリレーショナル・モデルを超える制約条件を有する場合、新しい列のデータがそれらの制約条件を満たすよう保証する方法がない。例えば、次元モデリングにおいて、タイプ２キーを有する次元表には、新しいキーがいつ生成されねばならないかについての特定の規則がある。基本的に、非タイプ２キー列のいずれかの値が変化する場合、新しいタイプ２キーを有する新しい行全体と、すべての最新データの完全なコピーが表に挿入される。この構成では、次元表に関連付けられた履歴情報を保存することができる。しかしながら、任意の第３者がそのような列を作成し得るようにすることは、その第３者が、そのタイプ２キー・セマンティクスに関与することを必要とする。残念ながら、データベースは、タイプ２セマンティクスを保証する方法を提供しない。例えば、顧客は、コンタクト・センタ・データベース・ソフトウェアによって行われたタイプ２キー変更を取り消すことができ、逆もまた同様である。さらに、この手法は、更新の喪失を引き起こし得る競合状態の悪影響も受けている。
【０００９】
別の手法では、表上のデータベース・トリガを使って第３者変更が監視され、第３者変更が識別されると、適切なタイプ２セマンティクスを適用するアプリケーションによって追跡される。残念ながら、そのような手法は、しばしば、適正な論理セマンティクスが維持されるのを妨げる、アプリケーションと第３者の間の競合状態をもたらすことがある。簡単にいえば、拡張された列セットへの変更に関連付けられる第３者のタイミングを制御する方法がない。しばしば、アプリケーションは、例えば、抽出、変換、およびロード（ＥＴＬ）モジュールが表から集計を算出している間、何らかの理由で表への変更を許容しようとしないことがある。
【００１０】
別の手法は、変更要求（トランザクション）が決まった期間にわたって遅延されるトランザクションまたは「データベース・ロッキング」を使用する。データベース・ロッキングは、役には立つが、完全な解決に使用するのが難しいこともある。例えば、トランザクション保持時間が永続する場合、第３者のアプリケーションまたはコンタクト・センタ・アプリケーションが行き詰まることがある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記その他の必要は、本発明の様々な実施形態および構成によって対処される。本発明は、一般に、拡張可能なデータ・モデルを対象とする。
【課題を解決するための手段】
【００１２】
本発明の一実施形態において、データ処理システムは、
（ａ）第１の当事者によって維持され、または管理される第１のデータベースと、
（ｂ）第１の当事者とは異なる第２の当事者によって維持され、または管理される第２のデータベースと、
（ｃ）第２のデータベースに追加されるべきデータを指定する作業待ち行列と、
（ｄ）第１のデータベースから作業待ち行列にデータを書き込むように動作する抽出、変換およびロード・モジュールと、
（ｅ）作業待ち行列から第２のデータベースにデータをインポートするように動作するデータ・インポート・モジュールとを含む。
【００１３】
第２のデータベースに関する第１の当事者の特権は制限される。例えば、第１の当事者には、好ましくは、第２のデータベースに直接データを書き込み（挿入、削除、および／または更新し）、あるいは第２のデータベースを定義するデータ・モデルを変更する（挿入、削除、および／または更新する）特権が与えられない。これは、第２の当事者が、第１のデータベースからカスタム・データを受け取るよう第２のデータベースをカスタマイズすることを含めて、第２のデータベースを維持し、変更する責任を負うからである。通常、第１と第２の当事者は、共通の制御下にはない、別個の、無関係な企業体であり、一方は、他方における経営実権を持たない。
【００１４】
第２のデータベースの所有スキーマを第１の当事者から保護するために、第１の当事者についての第２のデータベースの許可は、好ましくは、第１の当事者のアクセスについて読取り専用に設定される。好ましくは、第１の当事者は、このスキーマの選択された部分の閲覧を禁止される。これは、物理的な表ではなく、データベース・ビューを介してのみアクセスを許可することによってなされる。一般に、第１の当事者には、作業待ち行列表および、おそらく、指定されたカスタム表にのみ、直接データを書き込むことが許可される。
【００１５】
第２の実施形態では、
（ａ）第１の当事者から、第２の当事者によって維持される第２のデータベースへの拡張を定義する仕様セットを受け取る工程と、
（ｂ）仕様セットに記述されるように、第２のデータベースに、カスタム表、表のカスタム行、および／または表のカスタム列を含む変更を行う工程と、
（ｃ）変更に対応する作業待ち行列を作成する工程と、
（ｄ）作業待ち行列が第１のデータベースから第１のデータを受け取る工程と、
（ｅ）第１のデータを、第２のデータを形成するように正規化する工程と、
（ｆ）カスタム表、カスタム行、および／またはカスタム列に第２のデータを書き込む工程と
を含む方法が提供される。
【００１６】
この方法は、事実上、第１から第２のデータベースへのデータのマッピングを行う。第１のデータは、第１のデータベースと意味的に互換性があり、第２のデータベースとは意味的に互換性がなく、第２のデータは、第１のデータベースと意味的に互換性がなく、第２のデータベースとは意味的に互換性がある。本明細書で使用する場合、「セマンティクス」は、シンボル、文字、あるいはシンボルまたは文字のグループの、それらの意味および／または相互に対する関係をいう。この関係は、通常、それらの解釈および使用の仕方とは独立のものである。２つのシンボルまたは文字は、それらが、それらの同時使用に対応するために、まず、データベースに対する意味的変更を必要とすることなく、共通のデータベースで使用され得るときに、「互換性がある」。
【００１７】
上記の実施形態では、データベース・モデルが必要とする論理的セマンティクスの保護を提供しつつ、（潜在的に信頼されていない）非特権当事者がそのデータベース・モデルへの拡張を行えるようにすることができる。非特権当事者は、第１のデータベースの複雑な詳細について知っているが第２のデータベースについては知らず、第２の当事者は、第２のデータベースの複雑な詳細について知っているが、第１のデータベースについては知らない。上記の実施形態は、事実上、２つの当事者の知識を混合して第１と第２のデータベースを組み合わせることができ、同時に、データ競合、衝突、および第２のデータベースに対する競合する変更から生じるその他の不一致を、事実上、抑制することができる。したがって、第１の当事者が、第２のデータベース・モデルの複雑なセマンティクス、特に、タイプ２セマンティクスについて知り、それを実施しなくてもよくなる。例えば、本発明は、データベース・モデルが次元モデリングを使用する場合には、適正なタイプ２次元キーを保証する機構を提供することができる。
【００１８】
１つの構成では、本発明は、（作業待ち行列における）外部表を使って、（「保護表」と呼ばれる）アプリケーションのデータベース表へのアクセスを保護する。外部表には、企業が挿入、削除、更新を行うことのできる「サンドボックス」が含まれる。データベース・トリガまたは外部表上の類似の変更通知機構が、その後、対応する保護表への適切な変更を行うアプリケーション・ソフトウェアへの通知を提供する。この変更には、保護表でのタイプ２次元セマンティクスの実施が含まれていてもよい。
【００１９】
別の構成では、企業は、外部表に挿入するだけである。この場合、トリガは前述のように働き、保護表において適切な変更を生じさせる。それらの変更が完了すると、対応する行が外部表から削除される。このようにして、外部表は、保護表への変更のための作業要求待ち行列を実施する。
【００２０】
外部表は、非特権当事者によって設けられなくてもよい。保護表所有者は、非特権当事者によって与えられる情報に基づいて外部表を設けてもよい。例えば、この情報は、外部表がどの保護表に関連するか、外部表列が何であるか、それらの列は保護表の内部に作成されるべきか、それとも別の保護表として作成されるべきかなどを含み得る。
【００２１】
どちらの構成においても、保護表は、非特権当事者によっては変更され得ない。トリガ機構は、保護表が、常に、適正なセマンティクスを維持するように、追加のセマンティクス（タイプ２セマンティクスなど）を実施する。アプリケーションは、保護表が処理（例えば、保護表からの集計データの形成など）を受けている期間、トリガ操作を中断してもよい。その場合、非特権当事者は、外部表の内容を調べることによって、どの変更が行われているか追跡することができる。
【００２２】
表セマンティクスを保護する他の手段は、（例えば構造化照会言語（ＳＱＬ）などによる）アクセスを許容するが、それ以外の非特権当事者に、保護表セマンティクスに関与するよう要求する。これに対して、本発明は、ＳＱＬを使って非特権当事者からアクセス可能な外部作業待ち行列を提供するが、好ましくは、トリガを使って、保護表の適正なセマンティクスを保証する。よって、本発明は、非ＳＱＬ第３者アクセスを使って表を保護する必要を回避することができる。
【００２３】
上記の理由により、本発明は、リアルタイムまたはほぼリアルタイムで、２つの異なるソースからの２つの異なるデータを混合し、または多重化するインターフェースを提供することができる。一方のソースは、コンタクト・センタ・データ収集処理ソフトウェアの外部にある企業データ収集処理ソフトウェアであり、他方のソースは、コンタクト・センタ・ソフトウェア自体である。
上記その他の利点は、本明細書に含まれる本発明の開示を読めば明らかになるであろう。
【００２４】
本明細書で使用する場合、「少なくとも１つ」、「１つまたは複数」、および「および／または」は、連言的にも選言的にも効力を有する非制限的表現である。例えば、「Ａ、ＢおよびＣの少なくとも１つ」、「Ａ、ＢまたはＣの少なくとも１つ」、「Ａ、ＢおよびＣの１つまたは複数」、「Ａ、ＢまたはＣの１つまたは複数」および「Ａ、Ｂ、および／またはＣ」という表現は、それぞれ、Ａのみ、Ｂのみ、Ｃのみ、ＡもＢも、ＡもＣも、ＢもＣも、またはＡもＢもＣも、を意味する。
【００２５】
前述の実施形態および構成は、完全なものでも網羅的なものでもない。理解されるように、前述の、または以下で詳細に説明する特徴の１つまたは複数を、単独で、または組み合わせて利用する本発明の他の実施形態が可能である。
【発明を実施するための最良の形態】
【００２６】
以下は、本発明を、通信システムの例との関連で説明する。ＡＣＤや他の類似のコンタクト処理スイッチを備えるシステムなどと共に使用するのに適してはいるが、本発明は、どんな特定の種類の通信システム・スイッチやシステム要素の構成を用いた使用にも限定されない。開示の技法が、改善されたイベント（例えばコンタクト）処理を提供することが望ましい任意のアプリケーションで使用され得ることを、当分野の技術者は理解するであろう。
【００２７】
図１に、本発明の例示的実施形態を示す。コンタクト・センタ１００は、中央サーバ１１０と、コンタクトまたは顧客に関連する情報、ならびにコンタクト処理の価値および効率を高めることのできる他の情報を含むデータ・ストアまたはデータベースのセット１１４と、複数のサーバ、すなわちボイス・メール・サーバ１１８、対話型音声応答ユニット（ＩＶＲ）１２２、およびその他のサーバ１２６（プレディクティブ・ダイヤラなど）と、スイッチ１３０と、複数の作業エージェントを操作するパケット交換方式の（第１の）電気通信装置１３４／１〜Ｎ（コンピュータ・ワークステーションやパーソナル・コンピュータなど）および／または回線交換方式の（第２の）電気通信装置１３８／１〜Ｍとを備え、すべて、ローカル・エリア・ネットワーク（ＬＡＮ）（または広域ネットワーク（ＷＡＮ））１４２で相互接続されている。各サーバは、任意選択の通信回線１４６を介してスイッチ１３０に接続されていてもよい。また、理解されるように、その他のサーバ１２６には、（通常はスイッチ１３０やＷｅｂサーバに接続されない）スキャナ、ＶｏＩＰソフトウェア、ビデオ呼び出しソフトウェア、音声メッセージング・ソフトウェア、ＩＰ音声サーバ、ファックス・サーバ、Ｗｅｂサーバ、および電子メールサーバなどが含まれてもよい。スイッチ１３０は、複数の中継線１５０を介して公衆交換電話網（ＰＳＴＮ）１５４に接続され、（１つまたは複数の）リンク１５２を介して第２の電気通信装置１３８／１〜Ｍに接続される。サーバ１１０とパケット交換網１６２の間に、サーバ１１０とネットワーク１６２の間で受け渡される通信を処理するためにゲートウェイ１５８が配置される。
【００２８】
本明細書で使用する場合の「スイッチ」または「サーバ」という用語は、ＰＢＸ、ＡＣＤ、エンタープライズ・スイッチ、または他の種類の電気通信システム・スイッチまたはサーバ、ならびに、メディア・サーバ、コンピュータ、アジャンクトなど、他の種類のプロセッサベースの通信制御装置を含むものと理解すべきである。
スイッチ１３０および／またはサーバ１１０は、コンタクトを１つまたは複数の電気通信装置に宛先指定するための任意のアーキテクチャとすることができる。例えば、スイッチおよび／またはサーバは、Ａｖａｙａ  Ｉｎｃ．のＤｅｆｉｎｉｔｙ（商標）構内交換機（ＰＢＸ）ベースのＡＣＤシステム、ＭｕｌｔｉＶａｎｔａｇｅ（商標）ＰＢＸ、ＣＲＭ  Ｃｅｎｔｒａｌ２０００  Ｓｅｒｖｅｒ（商標）、Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｍａｎａｇｅｒ（商標）、Ｓ８３００（商標）メディア・サーバ、および／またはＡｖａｙａ  Ｉｎｔｅｒａｃｔｉｏｎ  Ｃｅｎｔｅｒ（商標）の変形形態とすることができる。通常、スイッチ／サーバは、従来、外部通信リンクへのインターフェース、通信スイッチング・ファブリック、サービス回路（トーン発振器、告知回路など）、制御プログラムおよびデータを格納するメモリ、格納された制御プログラムを実行してインターフェースおよびファブリックを制御し、自動コンタクト分配機能を提供するプロセッサ（すなわちコンピュータ）を含む、内蔵プログラム制御システムである。スイッチおよび／またはサーバは、通常、サービス提供対象の電気通信装置にサービスを提供するためのネットワーク・インターフェース・カード（不図示）を含む。他の種類の知られたスイッチおよびサーバは、当分野でよく知られており、したがって、本明細書では詳細に記述しない。
【００２９】
第１の電気通信装置１３４／１・・・１３４／Ｎはパケット交換方式であり、これには、例えば、Ａｖａｙａ  Ｉｎｃ．の４６００  Ｓｅｒｉｅｓ  ＩＰ  Ｐｈｏｎｅ（商標）などのＩＰハードホン、Ａｖａｙａ  Ｉｎｃ．のＩＰ  Ｓｏｆｔｐｈｏｎｅ（商標）などのＩＰソフトホン、携帯情報端末（ＰＤＡ）、パーソナル・コンピュータ（ＰＣ）、ラップトップ、パケットベースのＨ．３２０ビデオ電話機および会議用ユニット、パケットベースのボイス・メッセージングおよび応答ユニット、パケットベースの従来方式のコンピュータ電話技術アジャンクト、および他の任意の通信装置が含まれ得る。
【００３０】
第２の電気通信装置１３８／１・・・１３８／Ｍは回線交換方式であり、例えば、有線または無線電話機、ＰＤＡ、Ｈ．３２０ビデオ電話機および会議用ユニット、ボイス・メッセージングおよび応答ユニット、従来方式のコンピュータ電話技術アジャンクト、および他の任意の通信装置が含まれ得る。
【００３１】
パケット交換網１６２は、インターネットなど、任意のデータおよび／または分散処理ネットワークとすることができる。
パケット交換網１６２は、ゲートウェイ１７８を介して外部の第１の電気通信装置１７４と、回線交換網１５４を介して外部の第２の電気通信装置１８０と通信を行う。
【００３２】
図１に示すスイッチ、サーバ、ユーザ電気通信装置、およびその他の要素の構成は例示のためのものにすぎず、本発明を、各要素のどんな特定の構成にも限定するものと解釈すべきではないこと強調しておく必要がある。
【００３３】
図２を参照すると、サーバ１１０の１つの可能な構成が示されている。サーバ１１０は、（１つまたは複数の中継線、電話回線などとすることのできる）複数の顧客通信回線２００ａ〜ｙ、および（ＬＡＮ１４２や回路交換音声回線１４０などの音声／データ伝送回線とすることのできる）エージェント通信回線２０４と通信を行う。サーバ１１０は、Ｂａｓｉｃ  Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（商標）（ＢＣＭＳ）、Ｃａｌｌ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（商標）、コンタクト・センタ報告を生成する際に使用するための呼記録およびコンタクト・センタ統計を収集する、Ａｖａｙａ  Ｉｎｃ．によるＯｐｅｒａｔｉｏｎａｌ  Ａｎａｌｙｓｔ（商標）の変形形態などのイベント処理モジュール２２８を含むことができる。
【００３４】
サーバ１１０に格納されるデータの中に含まれるのが、コンタクト待ち行列のセット２０８ａ〜ｎと、それとは別のエージェント待ち行列のセット２１２ａ〜ｎである。各コンタクト待ち行列２０８ａ〜ｎは、各エージェント待ち行列２１２ａ〜ｎと同様に、異なるエージェント技能セットに対応する。従来方式では、コンタクトは、優先順位付けされ、その優先順に、個々のコンタクト待ち行列２０８ａ〜ｎにエンキューされ、または異なる優先順位に対応する複数のコンタクト待ち行列の異なるものにエンキューされる。同様に、各エージェントの技能も、エージェントのその技能の専門知識レベルに従って優先順位付けされ、各エージェントは、その専門知識レベルの順に個々のエージェント待ち行列２１２ａ〜ｎにエンキューされ、または、それぞれが異なる専門知識レベルに対応する、技能に対応した複数のエージェント待ち行列２１２ａ〜ｎの異なるものにエンキューされる。サーバ１１０内の制御プログラムの中に含まれるのが、コンタクト・ベクトル２１６である。コンタクト・センタに入ってくるコンタクトは、顧客識別情報、顧客の必要、コンタクト・センタの必要、現在のコンタクト・センタ待ち行列の長さ、顧客値、およびコンタクトの適正な処理に必要とされるエージェント技能を含むいくつかの所定の基準に基づいて、コンタクト・ベクトル２１６により、異なるコンタクト待ち行列２０８ａ〜ｎに割り当てられる。コンタクトを処理することのできるエージェントは、技能および／またはそれらのエージェントが有する技能レベルに基づいてエージェント待ち行列２１２ａ〜ｎに割り当てられる。
【００３５】
図３に、イベント処理モジュール２２８の一実施形態を示す。モジュール２２８は、企業によって制御される第１のデバイス・セット３００、すなわち、企業データベース３０４、ならびに抽出、変換およびロード（ＥＴＬ）モジュール３０８と、そのすべてが、コンタクト・センタ・ソフトウェアの製造者や、供給元や、サービス提供または管理実体などの第３者によって制御される、第２のデバイス・セット、すなわち、企業によって制御される（１つまたは複数の）仕様３１８、データ・モデル修飾子３２２、作業待ち行列３１６ａ〜ｎ、データ・インポート・モジュール３２０、供給元データベース３２４、拡張表３２８、セマンティクス・モジュール３３２、キー権限３３６、および識別情報解決サービス３４０とを備える。言い換えると、企業と第３者は、コンタクト・センタ・データベース・ソフトウェアの変更に関係する第１と第２の特権セットを有し、第１の特権セットは、コンタクト・センタ・データベース・ソフトウェアおよび／またはデータ・モデルを変更する能力を含まず、第２の特権セットはその能力を含む。「データベース・ソフトウェアおよび／またはデータ・モデルを変更すること」は、例えば、次元、キー、または属性、あるいは表の行および／または列を挿入し、削除し、かつ／または更新する能力を含む。
【００３６】
企業データベース３０４およびＥＴＬモジュール３０８は従来のものである。理解されるように、ＥＴＬモジュール３０８は、そのソースからデータを読み取り、そのデータを整理して均一に成形し、次いで、作業待ち行列３１６として示されている、ターゲット・リポジトリに書き込む。例えば、ＥＴＬモジュール３０８は、外部ソースから第３者に制御されるシステムによって認識される自然キーへの任意のキー／識別子マッピングを行う。ＥＴＬモジュール３０８は、さらに、確実に正しいデータがロードされるようにする。これは、データに関する計算またはその他の変換を実行すること、およびデータを正しいエンティティと関連付けることを含み得る。適切な企業データベース３０４ソフトウェアの例には、Ｏｒａｃｌｅ（商標）データベース製品、Ｍｉｃｒｏｓｏｆｔ（商標）ＳＱＬサーバ・データベース製品、およびＳｉｅｂｅｌ（商標）による顧客関係管理ソフトウェアが含まれ、適切なＥＴＬモジュールの例には、Ｍｉｃｒｏｓｏｆｔ（商標）、Ｏｒａｃｌｅ（商標）、ＩＢＭ（商標）、Ａｓｃｅｎｔｉａｌ  Ｓｏｆｔｗａｒｅ  Ｃｏｒｐｏｒａｔｉｏｎ（商標）、およびＨｕｍｍｉｎｇｂｉｒｄ  Ｌｔｄ（商標）によって提供されるＥＴＬシステムが含まれる。
【００３７】
企業によって制御される仕様３１８およびデータ・モデル修飾子３２２は、合わせて、企業によって要求されるように第３者によって変更され得る拡張可能なデータ・モデルを提供する。この仕様は、好ましくは、企業メタデータ仕様である。この仕様は、データ・モデルに挿入され、データ・モデルから削除され、またはデータ・モデルにおいて更新される表および列を定義する拡張可能なマークアップ言語（ＸＭＬ）ファイルである。この仕様は、好ましくは、ＸＭＬタグとそれら相互の関係のセットである。企業は、手動で、かつ／またはユーザ・インターフェースを介してこの仕様を編集する。ユーザ・インターフェースは、例えば、ユーザに、変更案に関する一連の照会を行い、仕様中のＸＭＬファイルに応答を書き込むはずである。これを可能にするために、１つの構成において、企業は、データベース３２４のデータ・モデルおよび／または物理表の選択された部分を（特権を編集せずに）閲覧することができる。データ・モデル修飾子３２２は、仕様３１８に記載されている変更を実行する。データ・モデルは、データ修飾子３２２によって、少なくとも以下のやり方で変更され得る。
１．既存のファクト表にカスタム・ファクトが追加され得る。
２．既存のファクト表に対応する新しい表にカスタム・ファクトが追加され得る。
３．既存の次元表にカスタム属性が追加され得る。
４．既存の次元表に対応する新しい表にカスタム属性が追加され得る。
５．カスタム表が追加され得る。
【００３８】
このことに留意すると、仕様は、通常、ＥＴＬモジュールから受け取られるべきデータに関する仕様を含む。そのような仕様の例には、データ・モデル３２４における次元の識別情報および他のオブジェクト（すなわち次元、キーおよび属性）に対する関係、データ・モデルにおける新しい行および列の識別情報および他のオブジェクトに対する関係、データ・モデルにおけるキーの識別情報および種類およびそれらの他のオブジェクトに対する関係、データ・モデルにおける属性の識別情報および他のオブジェクトに対する関係などが含まれる。
【００３９】
既存のファクトまたは次元表が拡張されるとき、仕様において指定された列が、修飾子３２２によって既存の表に追加される。これは、より簡単で、適切なレポート照会の実行を実現するが、ワイド表を生じることがある。この手法は、個々のデータベース実装が表において許容される列数を制限している場合には、当然ながら、制限される。
【００４０】
ワイド表制限を回避するために、データ・モデル修飾子３２２は、既存の表に対応する新しい表を作成することができる。新しい表は、カスタム列および既存の表に関連するキーを含む。この手法は、任意に拡張可能であるが、企業列にアクセスするための結合を必要とする。この手法によって作成される新しい表は、第３者によって、標準の表と同じやり方で管理される。
また、修飾子３２２は、完全に企業によって管理されるカスタム表を作成することもできる。
【００４１】
新しい表および企業表は、まとめて、拡張表３２８に含まれる。
カスタム列を有する各表ごと、各拡張表３２８ごとに、修飾子３２２は、対応する作業待ち行列３１６ａ〜ｎを作成する。各作業待ち行列は、カスタム列および自然キーを含み、供給元データベース３２４のそれぞれのカスタム列に、かつ／または対応するカスタム（拡張）表３２８にインポートするためにＥＴＬモジュール３０８からデータを受け取る。好ましくは、企業が書き込むことのできる表は作業待ち行列表と任意の企業によって制御されるカスタム表だけである。
【００４２】
データ・インポート・モジュール３２０は、適宜、作業待ち行列３１６ａ〜ｎから第３者のデータベース３２４および拡張表３２８にデータをコピーする。モジュール３２０は、作業待ち行列内のレコードを正規化イベントに変換し、必要に応じて次元更新を行う入力アダプタとして働く。「イベント」とは、出現または事件であり、「正規化イベント」とは、第３者のデータ・モデルにおけるデータ構造と整合するイベントの表現である。正規化イベントは、各更新ごとに作成され、処理のためにシステム３１２に注入される。例えば、モジュール３２０は、（任意選択の）識別情報解決サービス（ＩＲＳ）３４０およびキー権限３３６を使用して、自然キーをエンティティ識別子、すなわちコンタクト・センタ・データベース３２４内部のキーに変換する。
【００４３】
データ・インポート・モジュールは、様々なやり方でカスタム・イベントを正規化イベントに変換することができる。例えば、カスタム・イベントのＸＭＬスキーマが定義され、ＸＭＬを正規化イベントに変換するＷｅｂサービスが公開されてもよい。代替の手法は、ＥＴＬモジュール３０８からイベントを受け取り、それらを正規化イベントに変換するカスタム入力変換機構を実施するものである。さらに、標準イベント・ソースが、独自のカスタマイズ可能なイベント機能を備えていてもよい。
【００４４】
データ・インポート・モジュールは、企業によって指定された間隔（例えば、毎日、毎時、５分ごとなど）で実行されるようにスケジューリングされても、ＥＴＬモジュールが実行された後に手動で呼び出されても、データベース・トリガによって呼び出されてもよい。
【００４５】
識別情報解決サービス３４０は、エンティティ識別子、ヒント、および対応する自然キーの表を維持する。「ヒント」とは、代理キーがいつ有効になるかを示す指示の形態である。ヒントの例には、代理キーの現在の使用可能性に関するＹＥＳ／ＮＯフラグ、代理キーがその後に有効になる日付および／または時刻、キーが有効であることを示すシグニチャ、キーが有効になる前に発生しなければならない識別イベント、タイムスタンプ（エンティティ識別子（ＥＩＤ）要求のものなど）、代理キー自体、シーケンス番号などが含まれる。一実施形態において、ヒントは、キー権限によって、ＥＩＤから対応する（有効な）代理キーにマップするのに使用される。
【００４６】
キー権限３３６は、代理キーを管理する。管理変更によって新しい代理キーが生成されるときに、キー権限３２４は、識別情報解決サービス３４０に、新しい代理キーが利用可能であるというヒントと共にエンティティ識別子を送る。ＩＲＳ３４０およびキー権限３３６の構成および動作は、この参照によって本明細書に組み込まれている、２００５年８月８日に出願した、Ｂｌａｎｄらによる、「Ｄｅｆｅｒｒｅｄ  Ｃｏｎｔｒｏｌ  ｏｆ  Ｓｕｒｒｏｇａｔｅ  Ｋｅｙ  Ｇｅｎｅｒａｔｉｏｎ  ｉｎ  ａ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｐｒｏｃｅｓｓｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ」に詳細に記載されている。
【００４７】
（任意選択の）セマンティクス・モジュール３２２は、次元およびファクト・データを更新するためにオブジェクト・モデルを提示し、企業から、物理スキーマ、第３者のデータベース抽象化、およびタイプ２次元セマンティクスを含む、物理データベース実装の詳細を隠し、タイプ２次元セマンティクスを管理し（すなわち、代理キーの生成を含むタイプ２次元変更を処理し）、データ・インポート・モジュール３２０と協働して、データベースに次元およびファクト・データを書き込む。
【００４８】
第３者データベース３２４、拡張表３２８、および企業データベース３０４は、集合的に、図１のデータベース１１４を形成する。このデータベースは、顧客や、エージェントや、コンタクトまたは作業項目といったいくつかの企業オブジェクトに関するファクトおよび尺度および関連するセマンティクスと、エージェント待ち行列２０８と、コンタクト待ち行列２１２を含む。
【００４９】
次に、図４を参照して、データ・モデル修飾子３２２の動作について論じる。
プロセスは、企業によって仕様３１８にエントリが書き込まれる工程４００で開始される。
工程４０４で、修飾子３２２は、適切な技法によってエントリを検出する。この技法は、例えば、ポーリング機構としてもよく、エントリが行われた後で修飾子３２２を直接起動することによるものとしてもよい。
工程４０８で、修飾子３２２は、仕様中の次のエントリを取り出す。
工程４１２で、修飾子３２２は、エントリによって要求されるようにデータ・モデルを変更する。
工程４１６で、修飾子３２２は、処理されたエントリを仕様から削除する。
【００５０】
判断記号４２０で、修飾子３２２は、仕様に次のエントリがあるかどうか判定する。エントリがない場合、修飾子３２２は工程４００に戻る。エントリがある場合、修飾子３２２は、工程４０８に戻り、次のエントリに関して工程４０８を繰り返す。
【００５１】
一例で、修飾子３２２の動作を説明する。企業が、コンタクト・センタにおいてその各エージェントごとに内部エージェント識別子を持つために、データ・モデルにエージェント識別子を追加しようとしていると仮定する。したがって、企業は、第３者データ・モデルのエージェント次元に追加を行おうとする。企業は、「顧客ＩＤ」という列（またはタイプ２次元）がエージェント次元表に追加されることを示すＸＭＬ仕様を作成する。この列の種類は「ストリング」と呼ばれる。理解されるように、他の潜在的な列の種類には、数値、通貨、整数、浮動および日付／時刻が含まれる。このＸＭＬ仕様は以下の通りである。
＜ｔａｂｌｅ＞
＜ｎａｍｅ＞ａｇｅｎｔ  ｄｉｍｅｎｓｉｏｎ＜／ｎａｍｅ＞
＜ｃｏｌｕｍｎ＞
＜ｃｏｌｎａｍｅ＞ｃｕｓｔｏｍｅｒＩＤ＜／ｎａｍｅ＞
＜ｃｏｌｔｙｐｅ＞ｓｔｒｉｎｇ＜／ｃｏｌｔｙｐｅ＞
＜ｔｙｐｅ２ｄｉｍ／＞
＜／ｃｏｌｕｍｎ＞
＜／ｔａｂｌｅ＞
【００５２】
これに応答して、修飾子は、データ・モデルにおいて、（データベース３２４の第３者データ・モデルにおける外部キーとして）顧客ＩＤ列を含むエージェント次元表への拡張表を作成する。データは、顧客識別子の作業待ち行列に書き込まれた後で、データ・インポート・モジュール３２０によって対応する拡張表に書き込まれる。理解されるように、別個の拡張表を作成するのではなく、データベース３２４のデータ・モデルに直接新しい列が追加されてもよい。
【００５３】
次に、図５を参照して、データ・インポート・モジュール３２０、識別情報解決サービス３４０、キー権限３３６、およびセマンティクス・モジュール３３２の動作について論じる。
【００５４】
工程５００で、ＥＴＬモジュール３２０は、１つまたは複数の作業待ち行列（作業待ち行列表など）に（１つまたは複数の）レコードを書き込む。
工程５０４で、データ・インポート・モジュール３２０は、作業待ち行列内の（１つまたは複数の）新しいレコードを検出する。検出は、（データ・インポート・モジュールが（定義された間隔で）周期的に作業待ち行列に未処理のエントリに関する情報がないかポーリングする）ポーリング機構や、（作業待ち行列内のソフトウェアを始動させる、すなわち、作業待ち行列内のデータベース・コードが、作業待ち行列表の新しい行が書き込まれていると判定したときに、アプリケーション・コードを呼び出す）データベース・トリガや、待ち行列表が書き込まれた後で、企業に直接、インポート・アプリケーションを起動するなど、任意の適切な技法によって行われる。
【００５５】
工程５０８で、データ・インポート・モジュール３２０は、作業待ち行列から次の（入力）レコードを取り出す。
工程５１２で、データ・インポート・モジュール３２０は、データを正規化するために取り出されたレコードに対して任意の必要な変換を行う。例えば、企業（外部）自然キーが、（エンティティ識別子など）データベース・モデル（内部）キーに変換される。
工程５１６で、データ・インポート・モジュール３２０は、指定された内部キーについてデータベース１１４から最新の既存のレコードを読み取る。
工程５２０で、モジュール３２０は、既存のデータベース・レコードの属性を、取り出されたレコードにおける新しい属性と比較する。
【００５６】
判断記号５２４において、モジュール３２０は、任意の属性が変化しているかどうか判定する。言い換えると、モジュールは、取り出されたレコード内の属性が、指定された内部キーでのデータベース１１４内の属性と異なるかどうか判定する。
【００５７】
変化がないとき、モジュール３２０は、工程５２８で、取り出されたレコードについてデータベース１１４に変更を行わない。
変更があるとき、モジュール３２０は、判断記号５３６において、タイプ２属性が変化しているかどうか判定する。
【００５８】
タイプ２属性が変化していないとき、モジュール３２０は、工程５３２で、タイプ１更新を実行する。１つの構成では、タイプ１次元が構成されるとき、エンティティ識別子がキーとして使用され、工程５３２の更新が表の既存の行に影響を及ぼす。
【００５９】
タイプ２属性が変化しているとき、セマンティクス・モジュールは、工程５４０で、新しい代理キーを生成し、工程５４４で、データ・インポート・モジュール３２０は、新しい代理キーおよび（１つまたは複数の）新しい属性値を含む新しいレコードを挿入する。
【００６０】
１つの構成では、タイプ２次元が構成され、更新が次元に対するものであるとき、モジュール３２０および３３２は、データベースから現在の次元データを選択し（選択は、エンティティ識別子、またはエンティティ識別子を対応する代理キーにマップするためのキー権限３３６の使用に基づくものである）（工程５１６）、現在のデータを、更新のために要求された新しいデータに比較し（どの列も変更されなかった場合には、現更新は必要ない）（工程５２０）、どの列がタイプ２であるか判定し（工程５３６）、すべての変更がタイプ１列に限定されているとき、データベース内の現在の行を更新するために更新ステートメントを生成し（工程５３２）、任意のタイプ２列が変更された場合には、キー権限に新しい代理キーを要求し（工程５４０）、新しい代理キーを用いてデータベースに新しい行を挿入するために挿入ステートメントを生成する（工程５４４）。
【００６１】
タイプ２列が構成され、更新がファクトに対するものである場合、モジュール３２０および３２２は、エンティティ識別子およびヒントを使ってキー権限に代理キーを要求することによってファクトを更新し（前述のように、ヒントは、キー権限に、どの代理キーが特定のファクト更新に適用され、ＩＲＳ、データ・インポート・モジュールまたはイベント・プロセッサによって生成され、キー権限に提供されるか知らせる）（工程５４０）、キー権限によって提供された代理キーを使ってファクト・データを挿入し、または更新するための適切な構造化照会言語（ＳＱＬ）ステートメントを生成する（工程５４４）。
【００６２】
上記の例を参照して、データ入力モジュール３２０およびセマンティクス・モジュール３３２の動作の例について論じる。データベース３２４内の自然キー「１００」を持つエージェント「Ｂｏｂ  Ｓｍｉｔｈ」が、対応する顧客ＩＤ「１２３４５」を持つと仮定する。ＥＴＬモジュールは、対応する作業待ち行列に、外部キー、すなわち（第３者の自然キーに対応する）「１００」と、企業の対応する自然キー、すなわち顧客ＩＤ「１２３４５」とを書き込む。データ・インポート・モジュールは、作業表内のエントリを検出し、対応するレコード、すなわち新しいキー「１０１」を持つ「Ｂｏｂ  Ｓｍｉｔｈ」の新しいインスタンスを挿入する。というのは、変更がタイプ２変更として指定されているからである。レコードは、キー「１０１」で識別されるエージェント次元表の新しい行である。次いで、このエントリが、作業待ち行列内の表から削除される。
【００６３】
本発明のいくつかの変形形態および改変形態が使用されてもよい。本発明のいくつかの特徴を、他の特徴を提供せずに提供することも可能なはずである。
例えば、１つの代替実施形態では、本発明は、タイプ２次元モデルに限定されず、任意の次元モデルまたは他のタイプのリレーショナル（非リレーショナル）データベース・モデルに限定される。本発明は、特に、アプリケーションのデータ・モデルと、顧客が含めようとする可能性のある拡張の間に複雑なセマンティクスがある任意のアプリケーションに適用できる。タイプ２セマンティクスはかかる複雑さの好例であるが、複雑なセマンティクスを有するタイプ１次元または非次元データベースだけを伴う他のアプリケーションもあり得るはずである。
【００６４】
別の代替実施形態では、サーバおよび／またはスイッチは、ソフトウェアまたは特定用途向け集積回路（ＡＳＩＣ）を実行する処理装置（ＣＰＵ）、マイクロプロセッサ、または他の種類のディジタル・データ・プロセッサ、ならびにそのような要素の一部または組み合わせを含むソフトウェア制御のシステムとすることができる。メモリは、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、またはこれらおよびその他の種類の電子記憶装置の組み合わせとすることができる。
【００６５】
本発明は、様々な実施形態において、様々な実施形態、組み合わせの構成要素、およびそれらの部分を含めて、実質的に本明細書で図示し、説明するような構成要素、方法、プロセス、システムおよび／または装置を含む。本開示を理解すれば、当分野の技術者は、本発明をどのようにして作成し、使用するか理解するであろう。本発明は、様々な実施形態において、以前の装置またはプロセスにおいて、例えば、性能を向上させ、実装の容易さを実現し、かつ／または実装コストを下げるなどのために使用されたことのあるような項目が無い状態であることを含めて、本明細書で、または本明細書の様々な実施形態において図示せず、または説明せず、あるいは図示も説明もしない項目が無い状態の装置およびプロセスを提供することを含む。
【００６６】
本発明の上述の考察は、説明と図示のために提示されているものである。上述の考察は、本発明を本明細書で開示する１つまたは複数の形態に限定するためのものではない。例えば、上述の「発明を実施するための最良の形態」では、開示を簡素化するために、１つまたは複数の実施形態において、本発明の様々な特徴がひとまとめにされている。この開示の方法は、特許請求される発明が、各請求項に明示的に記載されているものよりも多くの特徴を必要とするという意図を表すものであると解釈すべきではない。そうではなく、添付の特許請求の範囲で表すように、発明の態様は、単一の上述の実施形態の一部の特徴に存する。よって、添付の特許請求の範囲は、各請求項が本発明の単独の好ましい実施形態として独立したものとして、この「発明を実施するための最良の形態」に組み込まれるものである。
【００６７】
さらに、本発明の記述は、１つまたは複数の実施形態およびいくつかの変形形態および改変形態の記述を含んでいるが、例えば、本開示を理解した後に、当分野の技術者の技能および知識に含まれ得る他の変形形態および改変形態も本発明の範囲内に含まれる。特許請求されるものの代替の、それらと交換可能な、かつ／またはそれらと等価の構造、機能、範囲または工程を、かかる代替の、交換可能な、かつ／または等価の構造、機能、範囲または工程が本明細書で開示されているか否かを問わず、かつどんな特許可能な対象も公に提示することを意図せずに含めて、許容される範囲で代替の実施形態を含む権利を獲得することが意図されている。
【図面の簡単な説明】
【００６８】
【図１】本発明の一実施形態によるコンタクト・センタを示すブロック図である。
【図２】本発明の一実施形態によるサーバを示すブロック図である。
【図３】イベント処理モジュールの一実施形態を示すブロック図である。
【図４】イベント処理モジュールの第１の動作実施形態を示す流れ図である。
【図５】イベント処理モジュールの第２の動作実施形態を示す流れ図である。
【図１】
0004499699.tif 000002
【図２】
0004499699.tif 000003
【図３】
0004499699.tif 000004
【図４】
0004499699.tif 000005
【図５】
0004499699.tif 000006