JP4676199B2 - カスタマのアクティビティを統合、管理、および調整するためのシステムおよび方法 - Google Patents

Description

（関連出願の参照）
本出願は、２００２年５月３１日に出願された米国仮特許出願連続番号第６０／３８４，４３４号（特許文献１）の「Ｃｕｓｔｏｍｅｒ Ａｃｔｉｖｉｔｙ Ｃｏｏｒｄｉｎａｔｉｏｎ」からの優先権を主張する。その開示は、引用により本願にも含まれるものとする。
（技術分野）
本発明は、一般に、組織において用いられる企業アプリケーションに関する。具体的には、本発明は、複数のアプリケーションおよび／またはタッチポイントを介して企業にアクセスするカスタマのアクティビティを統合、管理、および調整するためのシステムに関する。

企業アプリケーションは、会社および組織によって用いられて、それらの生産性および効率を改善し、それによって組織の利益性を増大させるツールである。これらのアプリケーションは、キャンペーン、ウエブ調査、情報、配達、サービス、およびサポート等の様々なソースを通してカスタマまたは従業員から収集された情報を用いる。通常のビジネスの過程において、会社は、そのシステムおよび従業員によって、そのカスタマと何度もインタラクトする。これらのインタラクションを用いて、カスタマとの関係を構築することができる。従業員およびカスタマから収集した情報は、関係を作り出し、維持し、成長させるために用いることができる。これは、組織にとっての利益を最大にしながらカスタマ・サービスを向上させるのに役立つ。

過去において、会社がカスタマとの関係を管理するのを支援するいくつかの企業アプリケーションが開発されている。これらのアプリケーションは、主に、販売、販売後のサービス、および調査のような特定の職務の間のインタラクションを通じて、カスタマから情報を収集する。この情報は、会社の作業、アプリケーション、製品、連絡等の具体的な改善のために分析される。

通常の企業アプリケーションは、データベースを維持する。これは、いずれかの情報が受信されるたびに更新される。情報に基づいて、アプリケーションは所望のタスクを実行する。更に、保存されたデータを分析して、カスタマ要求の重要な指標、製品の変更等を抽出する。業界には、様々な企業アプリケーションが存在する。かかるアプリケーションの例は、統合業務プランニング（ＥＲＰ：Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、カスタマ関係管理（ＣＲＭ：Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）、業務アプリケーション統合（ＥＡＩ：Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）およびその他のものである。異なるアプリケーションは、所望の結果を達成するために、異なる種類の情報を必要とする。

大企業では、多くの部署、異なるアプリケーション、およびタッチポイントがあり、様々な形態のカスタマおよび他の関係データを処理する。カスタマ・データは、電子メール、電話呼、ファクス、およびウエブ・インタフェースの形態とすることができる。更に、これらのデータは、物理的に異なる位置から生じる可能性がある。従って、データを収集および吸収し、カスタマに関するデータを必要とする全てのアプリケーションにそれを利用可能とするために、まとまりのある、インテリジェントな、一貫した通信システムが有利である。これによって、会社の従業員およびシステムは、カスタマに関するアクティビティをインテリジェントかつ予防的に調整することができる。

カスタマ・アクティビティの調整を達成するため、業界で現在用いられている手法がいくつかある。従来の手法の１つは、中央データベースの手法である。この手法では、大きい複合的なデータベースすなわち作動データ記憶装置（ＯＤＳ：Ｏｐｅｒａｔｉｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）を用いる。ＯＤＳは、統合された、サブジェクト指向の、詳細なデータの記憶装置であり、事業処理、情報収集、および意思決定をサポートするために用いられる。ＯＤＳの内容は、事業活動の過程で更新される。

しかしながら、この手法には、多くの欠点がある。第１に、これは、企業の全ての部分に現在のイベントおよびインタラクションを知らせるために不可欠な、ビジネス・プロセスおよびルールの双方向の統合を行うことができない。第２に、ＯＤＳのスケーリングは、サーバのサイズに限られ、これによって、処理する必要があるデータ量が増えた場合に、動作の複雑さが増す。第３に、ＯＤＳの使用は、抽出、ロード、および変換（ＥＴＬ：Ｅｘｔｒａｃｔｉｏｎ、Ｌｏａｄ、ａｎｄ Ｔｒａｎｓｆｏｒｍ）プロセスによって、大量ロードで、他の動作システムから情報を移動させることを必要とする。これは、プロセス時間を増し、更に、システムの動作を中断する。第４に、ＯＤＳは、リアルタイムの使用を必要とするアプリケーションからのデータ要求に対し、秒以下の問合せ応答時間を与えない。第５に、ＯＤＳが提供するセットのデータベース関連モデルは、新しいアプリケーション、タッチポイント、またはデータ・ソースに容易に対応することができないので、柔軟性が無い。

カスタマのアクティビティを調整するための別の手法は、中央データ・モデル手法である。この手法は、異なる企業のアプリケーションおよびデータベースを、１つのベンダーのアプリケーション・データ・モデルに統一することを伴う。しかしながら、この手法にはいくつかの制限がある。第１に、データ・モデルはアプリケーションに特定的であるので、異なるアプリケーションおよびデータベースの統一は複雑である。これは、既存のデータ・モデルの拡張を必要とし、これは既存のアプリケーションの複雑さを増し、アップグレードおよび移行をほとんど不可能とする。これは、更に、大量のデータ・アクセス、バッチ・データ移動、および応答を必要とし、これによってこの手法は極めて費用の高いものとなる。第２に、かかる手法は共通データ・モデルを必要とするので、これは多数の組織によって取り入れられ了解されなければならない。これは達成することが難しい場合がある。従って、この手法は、動作するようになるまでに、相当に長い時間を要する。第３に、この手法で用いられるデータ・モデルは、いったん所定の位置に固定されると、変更することが非常に難しい。また、この手法は、データの調和を実行する能力が無い。これは、一意の各従業員、パートナー、またはカスタマを認識しリンクするために、ソース・システム中で一意のＩＤを照合し相関させる能力である。

カスタマのアクティビティを調整するための別の手法は、分散型問合せ手法である。分散型問合せツールは、アドホックの問合せを規定し、システム中でデータのインスタンスを提供するために有益である。この手法は、多数のシステム間のデータを考慮する。しかしながら、かかる手法には多くの制限がある。例えば、これは、別の問合せを行うことなくマルチソースのビューを更新する方法を提供しない。また、これは、データの調和および、重複し一致しないスキーマ中での関係データの複雑なマージをサポートしない。更に、この手法は、許容可能なサービス・レベルの限界を超えることが多いカスタマ・データにアクセスする様々なアプリケーションに作業負荷をかける傾向がある。また、この手法は、所望のユーザ・アクションに対してコンテキストを提供するためのビジネス・ルールを適用しない。

カスタマ・アクティビティ調整のための更に別の手法は、分散型発表および加入イベント手法である。この手法は、ＥＡＩベンダーおよびプロセス・ツールの使用を伴う。この手法は、本質的に、２つのインタラクション・ポイント間で、逐点により、カスタマ、パートナー、チャネル、または供給業者のデータを考慮する。２つのポイント間で、ＥＡＩは、過渡的な共通のオブジェクトを用いて、差をマッピングおよび変換することができる。ＥＡＩ手法は、データ調和のための機構を提供しない。また、この手法では、プロセスは、その特定のトランザクションにとって重大なデータまたはイベントを有し得る全ての他のアプリケーションおよびタッチポイントに関連するプロファイルの完全なコンテキストを有しない。更に、この手法は、包括的かつ管理可能なカスタマ・データを提供する際にあまり効率的でない。更に、ＥＡＩ手法は、永続的であれ仮想的であれ、問合せを行って多数のソースからデータを戻すことができる保存位置を提供しない。

Ｃｏｍｐａｑ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｇｒｏｕｐ，Ｉｎｃ．（カリフォルニア州Ｃｏｕｐｅｒｔｉｎｏ）に譲渡された、「Ｅｎａｂｌｉｎｇ ａ ｚｅｒｏ ｌａｔｅｎｃｙ ｅｎｔｅｒｐｒｉｓｅ」と題するＷＩＰＯ発行番号第０２／０６３４９１ Ａ２号（特許文献２）に、カスタマ・アクティビティの調整のための方法が開示されている。この方法は、様々な企業の実体間で、リアルタイムで全ての通信を可能にしようとする。この方法は、企業全体のデータ、アプリケーション、事業トランザクション、オペレーション、および価値を統合する。企業のリアルタイム・オペレーションに関連したデータは、ＯＤＳ（Ｏｐｅｒａｔｉｏｎａｌ Ｄａｔａ Ｓｔｏｒｅ）として知られる永続的な記憶装置にロードされる。この情報は、ＥＡＩツールを用いて企業全体で同期される。ルールおよび同期ポリシーは、ＯＤＳを用いてハブにおいて実施される。これらのルールおよびポリシーによって、企業内のいずれかのアプリケーションからゼロ・レイテンシ業務（ＺＬＥ：Ｚｅｒｏ Ｌａｔｅｎｃｙ Ｅｎｔｅｒｐｒｉｓｅ）ハブに伝達されたいかなる更新も、ハブを介して、企業内の全ての他のアプリケーションにおいて情報の同期を行うことができる。

この方法は、リアルタイムでデータを調和させる能力を持っておらず、従ってデータの同期は信頼性が無い。更に、先に論じたように、データがソース・システムから複製され、データベースおよびそれをホストする垂直スケーリングを必要とするので、ＯＤＳはスケーラビリティが限られている。更に、全ての情報を中央レポジトリ（ＯＤＳ）に集めるので、システムは、ＯＤＳの故障のためシャットダウンしがちである。

特定のアプリケーションのため、上述の手法の１つ以上を利用するツールがいくつかある。ＣＲＭツールは、カスタマ・アクティビティの調整のために最も広く用いられているツールである。Ｃｏｍｐｕｄｉｇｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｌｉｍｉｔｅｄ（ニュージーランド、ウエリントン）に譲渡された、「Ｃｕｓｔｏｍｅｒ ｒｅｌａｔｉｏｎｓｈｉｐ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ」と題するＷＩＰＯ発行番号第０１／１５０３０ Ａ１号（特許文献３）は、かかる１つの例示的なＣＲＭソリューションである。このシステムは、インタラクション・データベースを維持するメモリを含むカスタマ関係管理システムを提供する。インタラクション・データベースにおけるデータは、カスタマおよび販売者間のインタラクションを表す。データは、１組の基準に基づいて検索される。このシステムは、全てのカスタマ・データについて１つの中央データベースを用いる。

しかしながら、この手法には、いくつかの欠点がある。第１に、このシステムは、単一のデータベースを用い、システムのスケーラビリティが限定される。第２に、このシステムは、リアルタイムのカスタマ・データの更新および可用性を提供しない。

カスタマ・アクティビティの調整において用いられる異なる手法に上述の欠点がある他に、カスタマ・アクティビティの調整を実行する試みに伴って、他にもいくつかの複雑さがある。１つは、同一のカスタマについての複製データの存在である。１人のカスタマは、データベースにおいて多数の位置で表され、調整において問題を生じる場合がある。このデータ複製は、カスタマが多数のシステムおよび通信チャネルを用いることの直接的な結果である可能性がある。更に、企業内の異なる組織、ビジネス・ライン、アプリケーション、およびタッチポイントは、同一のカスタマに関連するデータの断片化を増大させる恐れがある。従って、カスタマの複合的なビューを利用可能とすることは困難となる。

既存の技術に関連した欠点を考慮すると、現在のインタラクションの企業の全ての部分を更新するために不可欠なビジネス・プロセスおよびルールの統合を提供可能なシステムに対する要望がある。また、企業全体で情報を高速かつ効率的に転送するシステムが求められている。更に、カスタマに関連する情報をリアルタイムで更新するシステムに対する要望がある。また、複製データを処理可能であり、同一のカスタマに対するデータのマージおよび参照を行いつつ、カスタマ・データの完全さを調和させ維持する能力を有する解決策に対する要望がある。また、多数のチャネルまたはアプリケーションにわたってカスタマのアクティビティを把握し、次のインタラクション・ポイントにおいて最新の関連するカスタマのアクティビティを利用する必要がある。
米国仮特許出願連続番号第６０／３８４，４３４号 ＷＩＰＯ国際事務局発行第０２／０６３４９１ Ａ２号 ＷＩＰＯ国際事務局発行第０１／１５０３０ Ａ１号

本発明の目的は、アプリケーション、リソース、およびタッチポイント間で、リアルタイムに、企業のカスタマのアクティビティを調整することである。

本発明の別の目的は、企業の全ての部分に現在のインタラクションを知らせるために不可欠なビジネス・プロセスおよびルールの統合を提供することである。

本発明の更に別の目的は、企業全体に情報の高速かつ効率的な転送を提供することである。

本発明の更に別の目的は、アプリケーション、リソース、およびタッチポイントに、カスタマ情報のリアルタイムの更新を提供することである。

本発明の別の目的は、同一カスタマについてデータをマージし参照することによって、複製および一致したカスタマ・データを処理し、カスタマ・データの完全性を維持することである。

本発明の更に別の目的は、多数のチャネルおよびアプリケーションを通してカスタマ・アクティビティを捕捉し、次のインタラクション・ポイントで最も最近のカスタマ・アクティビティを利用することである。

本発明の別の目的は、企業の全てのアプリケーション、リソース、およびタッチポイントからカスタマに関するデータを蓄積し、あらゆるアプリケーション、リソース、またはタッチポイントにカスタマに関する全てのデータの複合ビューを提供することである。

カスタマ（顧客）に対応する仮想複合（合成）オブジェクトを作成することによって、企業においてカスタマのアクティビティ（行動）を統合、管理、および調整するためのシステム、方法、およびコンピュータ読取可能媒体を開示する。仮想複合オブジェクトは、カスタマに関するデータを含む。カスタマ・データは、アプリケーション、リソース、またはタッチポイントのカスタマとのインタラクションの間に取得される。アプリケーション、リソース、およびタッチポイントとのカスタマの以前のインタラクション（交渉）に関するカスタマ・データを取得した後に、仮想複合オブジェクトを作成する。仮想複合オブジェクトにおいて、カスタマ・データに、企業のポリシー、挙動、およびルールを適用する。カスタマの仮想複合オブジェクトは、カスタマの一意のカスタマ識別インデクスによって識別される。

仮想複合オブジェクトは、キャッシュ・メモリまたはサーバのクラスタに保存される。サーバは、全てのカスタマ識別インデクスのリストを維持する。また、サーバは、永続データベースにおいて全てのカスタマに関する基本カスタマ・データを保存する。この保存されたデータを用いて、カスタマの仮想複合オブジェクトを識別する。サーバは、アプリケーションから受信した問合せに基づいて、仮想複合オブジェクトついての問合せを生成することができる。問合せを生成すると、問合せされた仮想複合オブジェクトを検索し、リアルタイムで、問合せ元のサーバに送信する。問合せされた仮想複合オブジェクトがキャッシュ内に見つからない場合、ソース・アプリケーションおよびタッチポイントの問合せによって、新しい仮想オブジェクトを作成する。アプリケーション、リソース、またはタッチポイントにおいて発生するいずれかのイベントに基づいて、仮想複合オブジェクトをリアルタイムで更新する。

これより、本発明の好適な実施形態について、限定ではなく例示のために与える添付図面に関連付けて説明する。図面において、同様の符号は同様の要素を示す。

企業においてカスタマのアクティビティを調整するための方法、システム、およびコンピュータ・プログラム・プロダクトを開示する。このシステムは、複数のアプリケーションを通してデータの交換を同期させるために、企業の異なるアプリケーション間のインタフェースとして機能する。データは、データ・オブジェクトとして、中央サーバに保存される。異なるアプリケーションが、これらのオブジェクトにアクセスを有する。各カスタマは、カスタマに関連した情報の他に、彼／彼女に対応した特定のデータ・オブジェクトを有し、特定の属性を有する。これらのデータ・オブジェクトの様々な属性によって、カスタマに関連した最新のデータに対し、企業における全てのアプリケーションに対する共通アクセス・ポイントが可能となり、これによって、企業におけるカスタマ・アクティビティのリアルタイムの調整が行われる。この方法およびシステムは、本明細書中では、カスタマ・アクティビティの調整の文脈で説明するが、当業者には、本発明はカスタマ・アクティビティのみに限定されないことは明らかであるはずである。この方法およびシステムを用いて、企業におけるいかなる種類の関連データも管理することができる。例えば、開示する方法およびシステムを用いて、企業の様々な従業員およびパートナー間の関連データを管理することができる。

図１は、１つの実施形態に従ったシステムの全体的な環境を示す。企業１０２は、複数のアプリケーション１０４およびサーバ１０６を備える。サーバ１０６は、単一のサーバとすることができる。また、サーバ１０６は、互いに接続されたサーバのクラスタとすることも可能である。クラスタのサーバは、大きな企業の場合、負荷均衡化を容易にする。アプリケーション１０４は、カスタマ関係管理（ＣＲＭ）ソリューション、統合業務プランニング（ＥＲＰ）ソリューション、ｅＣｈａｎｎｅｌｓｒソリューション、および分析ソリューション等の様々な企業アプリケーションとすることができる。当業者には、言及したアプリケーションは例示的な目的のみであることは明らかであろう。企業１０２は、本発明の範囲から逸脱することなく、様々な他のアプリケーションも含むことができる。企業１０２のアプリケーション１０４は、カスタマ１０８とインタラクトする。アプリケーション１０４は、サーバ１０６と、各カスタマ１０８に関するデータを交換する。

図２は、開示するシステムの作業の概略を示すフローチャートである。カスタマが企業とインタラクトすると、サーバ１０６は、ステップ２０２において、カスタマに関連するデータを収集する。カスタマ・データは、各アプリケーション１０４によって、データ構造の形態で保存される。これらのデータ構造を、カスタマ・オブジェクトと呼ぶ。カスタマ・オブジェクトは、特徴的な特性および情報が関連付けられている。例えば、ゴールド・カスタマの場合、カスタマの特性はカスタマの重要度であり、これは、この場合、彼／彼女がゴールド・カスタマであるということである。このカスタマの様々なトランザクションの詳細が、カスタマ・オブジェクトに関する情報を形成する。これらの特性および情報は、重要なカスタマ・データを反映する。このデータは、カスタマ１０８の以前のインタラクションに関連するものとすることができる。例えば、データは、カスタマ１０８の販売前のアクティビティに関連するものとすることができる。これは、意思決定を行う前に見た異なる種類の製品に関する情報を含む場合がある。同様に、データは、販売中または販売後のカスタマ１０８の挙動に関連するものとすることができる。

カスタマ・オブジェクトは、自己記述性である。これは、カスタマ・オブジェクト自体を記述するメタデータを含む。メタデータは、実際のオブジェクト・スキーマを含む。オブジェクト・スキーマは、カスタマ・オブジェクトの構造を記述し表す。また、メタデータは、カスタマ・オブジェクトにおけるカスタマ・データがどのように他のカスタマ・オブジェクトと関連付けられているかに関する関連情報を含む。また、これは、他のカスタマ・オブジェクトにおけるカスタマ・データに対する参照を含む。また、メタデータは、どのアプリケーションが特定の属性セットについてのデータを保持するかを識別し、その属性セットにどの動作方法を適用すべきかを理解する。例えば、メタデータは、実際のデータに対する参照を提供することができる。これらの参照は、アプリケーション１０４によって用いて、問合せを行う必要がある特定の属性を識別することができる。

ステップ２０４において、異なるアプリケーションからのカスタマ・オブジェクトを用いて、１つのオブジェクトを作成する。このオブジェクトを、以降、仮想複号オブジェクトすなわちＶＣＯ（Ｖｉｒｔｕａｌ Ｃｏｍｐｏｓｉｔｅ Ｏｂｊｅｃｔ）と呼ぶ。

また、ＶＣＯは、ビジネス論理またはポリシーを含む。カスタマ１０８の状態に基づいて、ポリシーは、オブジェクト自体の更新をトリガするか、または他のオブジェクトおよびそれらのデータ、ポリシー、アプリケーション、およびプロセスに対するイベントをトリガすることができる。例えば、以下のポリシーを定義することができる。「オブジェクトを変更し、その変更がゴールド・カスタマに関連する場合、マーケティング部の部長に通知する。」

また、ＶＣＯは、挙動を含む。挙動は、特定のビジネス論理コードである。例えば、オブジェクトは、カスタマ１０８の縮小の危険をアクティブにポーリングし管理するビジネス論理を提供する挙動を有することができる。いかなるアプリケーションも、そのオブジェクトを要求し、従って、カスタマ１０８の縮小の可能性を見出すことができる。

また、ＶＣＯは、個々のデータがどのように関連付けられるか、または個々のデータがどのように他の複合オブジェクトにおけるデータを参照することができるかに関する関連情報も含むことができる。例えば、カスタマ・オブジェクトは、同じ世帯に住む別のカスタマを参照することができる。オブジェクトは、カスタマ・オブジェクトの論理モデルの構造によって、関連情報をカプセル化する。関連情報は、どのように個々のデータ片が関連付けられているか、および他の複合オブジェクトにおける属性を参照することができるかを表すことができる。例えば、ビジネス対カスタマ（Ｂ２Ｃ）組織のカスタマは、家庭に含まれることができるが、そのカスタマに対応するカスタマ・オブジェクトは、ビジネス対ビジネス（Ｂ２Ｂ）組織または経理面からの関連を有することができる。これらの関連は、メタモデルによって表すことができる。メタモデルは、論理構造モデルであり、物理データのソースに対する逆のリンクを有する。オブジェクトは、自己記述性のメタデータを含むので、オブジェクトは、内観によって発見機構をサポートする。例えば、要求元のアプリケーションがメタデータを要求し、結果として、要求することができるものに対して得られるオブジェクト・スキーマおよびＶＣＯをナビゲートするためのヒエラルキを得ることができる。これらの挙動およびポリシーは、それらのサービスを外部インタフェースに公開すると共に、他のポリシー、アプリケーション、プロセス、または他の複合オブジェクトとのインタラクションに対するイベントをトリガする。例えば、サンプルのビジネス論理は、「ユーザの気分をチェック」または「製品の推薦を提案」するための機構を提供し、次いでそのサービスをいずれかのクライアントに公開することができる。

各カスタマは、そのデータに専用のＶＣＯを有する。ＶＣＯは、そのカスタマの最新の関連する属性を全て含む。ＶＣＯは、サーバ１０６上のキャッシュ・メモリに保存される。サーバ１０６は、全てのアプリケーション１０４、リソース、およびタッチポイントに接続されている。アクティビティ・サーバとも呼ぶサーバ１０６については、図３に関連付けて詳細に説明する。

ＶＣＯは、カスタマ１０８に一意のカスタマ識別インデクスによって識別される。カスタマ識別インデクスを用いて、サーバ１０６におけるいずれかの動作の間、ＶＣＯを検索する。また、ＶＣＯは、それが表すカスタマ１０８の属性によって識別することができる。これらの属性は、いずれかの動作の間にＶＣＯを検索するために使用可能な基本情報を形成する。

１つの実施形態では、ＶＣＯは、メモリ内で動作可能となり、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標）Ｂｅａｎｓ（ＥＦＢ）コンポーネントとして現れる。それらは、対応するカスタマに関する最新の関連データを全てカプセル化する。更に、それらは、リアルタイムで更新される。アプリケーションまたはソース・システムから、特定のカスタマ・レコードに変更が行われたというメッセージが受信された場合に、ＶＣＯに対して更新が行われる。

１つの実施形態では、カスタマに対応した最も関連するアクティブ・データのみが、カスタマのＶＣＯの形態でサーバに保存される。例えば、サーバは、業界の８０／２０ルールを利用して、メモリに、企業の最もアクティブなカスタマをキャッシュする。キャッシュ内に存在しないいずれかのカスタマに対して問合せがある場合、サーバは、各アプリケーションまたはリソースに問合わせを発生することができ、これが、所望のデータを有し、そのカスタマのために動的にＶＣＯを構築する。問合せの厳密な方法は、図４に関連付けて後に説明する。最も関連するデータは、更新の詳細および最新のインタラクション、およびカスタマのトランザクションとすることができる。最も関連するデータの定義は、企業ごとに異なる場合があり、できるだけ最適な方法でカスタマに供するために最も有益なデータに対応する。ある場合には、カスタマの名前、住所、および電話番号のみが関連データとして保存されているが、別の場合には、カスタマの名前と共に、月収、取引量が関連データとして保存されている場合がある。ＶＣＯ上での選択的なデータ保存を用いることによって、余分な保存スペースの必要性が無くなる。

開示するシステムの別の実施形態では、最も重要なカスタマに対応するＶＣＯのみをサーバ１０６に保存する。関連するまたは最も重要なカスタマを識別し、かかるカスタマに関するデータを、ＶＣＯの形態でサーバ１０６上のデータベースに保持する。残りのカスタマ１０８に関するデータは、サーバ１０６に保存しない。残りのカスタマ１０８に関連する問合せを受信するたびに、そのカスタマに対応するデータが、関連ソース・システムまたはアプリケーションから蓄積される。このため、システムは、データの約１０％である参照データのみをデータベースに維持し、残りのデータはソース・システムに残す。オブジェクトが必要である場合、これは、最初にデータベースからマスタ参照データを取り入れ、次いでソース・システムに問合せを行うことによって残りのデータを蓄積する。

図３は、アクティビティ・サーバとも呼ぶサーバ１０６のブロック図を示す。サーバ１０６は、以下の主要コンポーネントを有する。ライフサイクル・マネージャ３０４、問合せエンジン３０６、照合エンジン３０８、ルール・エンジン３１０、ハーベスタ３１２、オブジェクト・レジストリ３１４、および永続データベース３１６である。これらの各々の機能を、以下に詳細に説明する。

ライフサイクル・マネージャ
ライフサイクル・マネージャ３０４は、ＶＣＯのライフサイクルを管理する。これは、新しいＶＣＯの作成、ＶＣＯのキャッシュ内へのロード、およびＶＣＯのキャッシュからの除去を担う。キャッシュされたＶＣＯは、アプリケーション１０４からの要求に応答する準備ができている。ライフサイクル・マネージャ３０４は、選択したカスタマ属性に基づいて、キャッシング保有ポリシーを利用することによって、ＶＣＯの活性化および非活性化をインテリジェントに管理する。ライフサイクル・マネージャ３０４は、いつカスタマが企業とインタラクトしたか、ある時間期間にどのくらいの頻度でカスタマが企業とインタラクトしたか、カスタマの金額的な価値は何か、カスタマが置かれた状況はどんなものか等の条件を評価する１組のビジネス・ルールを用いる。これらのビジネス・ルールは、そのカスタマに関するデータが必要とされる可能性を決定する。また、ライフサイクル・マネージャ３０４は、関連するまたは最も重要なカスタマを識別し、かかるカスタマに対応するデータをサーバ１０６に保存する。かかるカスタマの差別化を達成する１つの方法は、８０−２０ルールを利用することである。８０−２０ルールを利用することによって、ライフサイクル・マネージャ３０４は、要求されるデータの可能性をシステム・メモリ・リソースの可用性と比較検討することによって、カスタマのうち最も関連する２０％をメモリ内に保持する。

問合せエンジン
問合せエンジン３０６は、サーバ１０６の永続データベース３１６における所望のＶＣＯ参照データの位置付けを担う。ＶＣＯに対する問合せは、カスタマ識別インデクスまたはカスタマの基本的な情報もしくは属性のいずれかに基づく。問合せエンジン３０６は、ライフサイクル・マネージャ３０４および永続データベース３１６と共に機能して、キャッシュ内でＶＣＯを探し出すかまたは作成し、データを要求したアプリケーション１０４にデータを送信する。

ここで図４を参照すると、問合せエンジン３０６の動作を示すフローチャートが示されている。ステップ４０２において、問合せエンジン３０６は、サーバ１０６を介して、アプリケーション１０４から問合せ要求を受信する。ステップ４０４では、問合せエンジン３０６は、その問合せにカスタマ識別インデクスが利用可能であるか否かを調べる。カスタマ識別インデクスが利用可能でない場合、問合せエンジン３０６は、問合せに制約を与える。制約は、問合せに改良を加え、特定の結果を得るために与えられる。例えば、制約は、特定のアイテムを購入した全てのカスタマを検索することである場合がある。かかる制約を満足させるカスタマのみに関連するデータを検索する。ステップ４０８では、問合せエンジン３０６は、問合せ命令文を明確に表す。問合せ命令文は、要求されたデータの正確な記述を含み、サーバ１０６が要求を実行するために最も適切なフォーマットを有する。ステップ４１０では、サーバ１０６内のデータベースとの接続を確立し、問合せを実行する。問合せを実行することによって、関連カスタマが、カスタマ識別インデクスに従ってデータベース内で検索される。１つの実施形態では、ＳＱＬ（Ｓｅｑｕｅｎｔｉａｌ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を用いて問合せを生成する。ステップ４１２では、問合せエンジン３０６は、いずれかの関連カスタマのＶＣＯのカスタマ識別インデクスが利用可能であるか否かを検証する。関連カスタマ識別インデクスが問合せ要求によって直接利用可能でない場合、それらはこのように取得される。いったんカスタマ識別インデクスが利用可能となると、ステップ４１４において、全ての関連カスタマ識別インデクスがそれらのサイズと共に戻される。ステップ４１６では、オブジェクト・レジストリ３１４から、関連カスタマ識別インデクスに対応するＶＣＯを検索する。ステップ４１８では、問合せ要求を、いずれかの選択についてチェックする。選択は、カスタマの名前、カスタマの住所等、問合せについて選択された特定の属性または属性集合とすることができる。いずれかの選択があると、次いでステップ４２０において、選択に従ってＶＣＯをフィルタリングする。ステップ４２２では、最初に問合せ要求を送ったアプリケーション１０４に、関連ＶＣＯを戻す。このように、問合せエンジン３０６は、アプリケーション１０４またはソース・システムの問合せ要求を実行する。

照合エンジン
照合エンジン３０８は、ある属性を照合することによって、リアルタイムでカスタマの照合を行う。カスタマの照合に使用可能な、アプリケーション１０４から検索されるカスタマ属性の例は、名前、住所、電子メール、および社会保障番号である。これらの属性は、永続データベース３１６内の既存のカスタマ情報に対して照合される。

ここで図５を参照すると、照合エンジン３０８の動作を示すフローチャートが示されている。アプリケーション１０４またはサーバ１０６が、ＶＣＯのための問合せを生成する。ステップ５０２では、照合エンジン３０８が、問合せエンジン３０６から問合せを受信する。ステップ５０４では、照合エンジン３０８は、所望のＶＣＯに関する基本情報を受信する。例えば、ＶＣＯに関する基本情報は、ＶＣＯのソース・システム識別番号またはカスタマ識別インデクスを含むことができる。照合エンジン３０８は、この基本情報を、オブジェクト・レジストリ３１４から受信する。ステップ５０６では、照合エンジン３０８は、基本情報を用いて、永続データベース３１６を検索する。照合エンジン３０８は、同一のカスタマを表すために用いられる全てのローカルなカスタマ識別インデクスの相互参照を維持するオブジェクト・レジストリ３１４を利用する。相互参照は、カスタマ識別インデクスの全てを、カスタマの名前等の主要属性に対して相関させる。
ステップ５０８では、照合エンジン３０８は、利用可能な基本情報が、一致を見出すのに充分であるか否かを判定する。これが既存のカスタマとの一致を見つけた場合、次いでステップ５１２において、アプリケーション１０４からのいずれかの新しいデータを、適当な既存のカスタマ識別子とマージしてリンクする。照合エンジン３０８が一致を見つけなかった場合、次いでステップ５１４で、永続データベース３１６に新しいエントリを作成し、新しいＶＣＯを形成する。照合エンジン３０８が、照合は部分的であるが、アプリケーション１０４からの一致の可能性があると判定した場合、次いでステップ５１６で、照合エンジン３０８は、基本情報を潜在的な複製としてマークし、これは例外として処理される。ステップ５１８では、照合エンジン３０８は、反複製の一部として照合を再び試みる。反複製では、例外プロセスを利用することによって、可能な一致を検証する。例外プロセスでは、同一のレコードを識別する。同一のレコードをマージするかまたはそれらを異なるとして指定しそれらを照合エンジン３０８から除去するかの決定は、ユーザに任される。また、照合エンジン３０８は、発見的アルゴリズムを利用して、データの標準化および外部データ・ソースによる検証を行う。照合エンジン３０８は、各ソース・システムから名前、住所、電子メール、社会保障等の属性を見て、別のソース・システムと一致がありそうか否かを調べるため評価を行う。これがそうする際に、一致ＩＤを割り当て、一致識別番号が互いにどのくらい似ているかを見ることによって一致の可能性を比較する。これは、異なるアプリケーション１０４を通じてカスタマの関連を管理する際に容易な保守および柔軟性に便宜を図り、データの不一致を常に見出し訂正する。実際、そのデータベースに２０００万のカスタマ・エントリを有する企業は、１４００万のみのカスタマを有し、残りの６００万はそのデータベース内の複製エントリである場合があることがわかっている。

ルール・エンジン
ルール・エンジン３１０は、マルチスレッド・エンジンである。これは、サーバ１０６の他のコンポーネントによって用いられて、ある構成されたルールに基づいてアクションをトリガするリソースである。ここで図５を参照すると、ルール・エンジン３１０の動作を示すフローチャートが示されている。ルール・エンジン３１０は、ＶＣＯが開始されると、それらにルール論理を適用する。例えば、ルールによるポリシーをオブジェクトに適用して、カスタマがある条件に満足するか否かを個々に通知することができる。ステップ５０４では、ルール・エンジン３１０は、ＶＣＯに含まれているカスタマ属性を調べる。ステップ５０６では、ルール・エンジン３１０は、いずれかのルールをＶＣＯに適用するか否かを判定する。ステップ５０８では、適用可能なルールをＶＣＯに適用する。ルールの適用の後に、アクションのリストが来る。ステップ５１０では、適用したルールに従ってカスタマ属性を変更する。ステップ５１２では、変更したカスタマ属性をソース・アプリケーション１０４に伝達する。これは、カスタマに関する情報のためのソースである。ステップ５１４では、適用したルールに基づいて、警告があればトリガする。本発明の１つの実施形態では、Ｓａｎｄｉａ Ｎａｔｉｏｎａｌ Ｌａｂｏｒａｔｏｒｉｅｓから入手可能な「ＪＥＳＳ」ルール・エンジンを用いる。ルール・エンジン３１０は、ｉｆ−ｔｈｅｎ論理を評価することによって機能する。例えば、ルールは、「カスタマが高い値のカスタマならば、抱き合わせ販売促進を提供する」と述べることができる。

ハーベスタ
ハーベスタ３１２は、アプリケーション１０４からのカスタマ・データをアセンブルする。ハーベスタ３１２は、捕獲エージェントを用いて、非同期および同期メッセージングによりデータ収集プロセスを分散させ管理する。捕獲エージェントは、ソース・システムまたはアプリケーション１０４のコネクタへの接続を指定することによって実施される。捕獲エージェントは、問合せおよびコマンドをアプリケーション１０４に発行し、それらの応答を待つ。いったん捕獲要求に対する応答が受信されると、ハーベスタ３１２は、ＶＣＯをアセンブルし、キャッシュ内でそれを利用可能とする。ハーベスタプロセスについては、図７に関連付けて後に説明する。

オブジェクト・レジストリ
オブジェクト・レジストリ３１４は、どのサーバ１０６上でどのＶＣＯが開始されたかのリストを維持する。このレジストリを用いることによって、システムは、企業１０２全体を通してＶＣＯの唯一のインスタンスが常に用いられることを保証する。オブジェクト・レジストリ３１４に対する同時アクセスがサポートされる。オブジェクト・レジストリ３１４の複製は、過負荷を回避し、このためシステム故障を防ぐ。１つの実施形態では、オブジェクト・レジストリ３１４は、サーバ１０６を開始した場合に作成される。指定された一次および二次サーバのみがレジストリを含み、これはメモリ内複製によって同期を維持する。

永続データベース
永続データベース３１６は、未知のカスタマを照合するために用いられるカスタマに関する基本情報を保存する。また、これは、アプリケーション１０４において見つけられない導出情報を保存することができる。例えば、永続データベース３１６は、アプリケーション１０４によって提供される異なる値の総量を保存することができる。また、永続データベース３１６は、永続データベース３１６におけるカスタマを他のアプリケーション１０４におけるカスタマと照合するために用いるオブジェクト・レジストリ３１４を保存する。

上述のサーバ１０６は、４つのプロセスを実行して、ＶＣＯとデータを交換し、ＶＣＯを管理する。これらのプロセスは、捕獲、イベント聴取、ライト・バック、およびライフサイクル・キャッシングである。これらのプロセスについて、以下に詳細に説明する。

捕獲
図７は、捕獲プロセスを示すフローチャートを示す。ステップ７０２に示すように、アプリケーション１０４が、特定のＶＣＯに対する問合せを行う。ステップ７０４では、要求されたＶＣＯのカスタマ識別インデクスが既知であるか否かを識別する。カスタマ識別インデクスが既知である場合、ステップ７０６において、ライフサイクル・マネージャ３０４が、対応するＶＣＯのためキャッシュに問合せを行う。問合せは、例えば、ＸＰａｔｈ（ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ）またはＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を用いて、明確に表すことができる。ステップ７０８では、キャッシュにおいてＶＣＯをチェックする。ＶＣＯがキャッシュで発見されたら、次いでステップ７１０において、これを、ＶＣＯを要求したアプリケーション１０４に送信する。ＶＣＯがキャッシュで発見されない場合、またはカスタマ識別インデクスが未知である場合、次いでステップ７１２において、問合せされたカスタマの属性を永続データベース３１６に保存されたものと照合する。ステップ７１４では、新しいＶＣＯを作成する。ステップ７１６では、ハーベスタ３１２が、永続データベース３１６からカスタマに関する基本情報を得る。また、ハーベスタ３１２は、他のアプリケーション１０４からカスタマに関する情報を収集する。ステップ７１８では、新しいＶＣＯに企業１０２のポリシーおよびルールを適用し、これを、最初の問合せを送ったアプリケーション１０４に送信する。アプリケーション１０４またはいずれかのソース・システムの問合わせは、これがデータベース・レベルで接続されている場合は直接永続データベース３１６に送ることができるが、最も多くの場合、ソース・アプリケーションのアプリケーション・プログラミング・インタフェースを介してアクセスされる。

イベント聴取
サーバ１０６は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ）メッセージを介して公表されたイベントを聴取する。これらのイベントは、ＶＣＯのいずれかに影響を及ぼすアプリケーション１０４内で生じる動作である。サーバは、特定のトピックについてメッセージ・バスを聴取することによって、これらのイベントを相関させる。次いで、イベントは、処理する必要のある変更が生じた場合、適切なオブジェクトにルーティングされる。例えば、サーバ１０６は、既存のカスタマ・オブジェクトの消去、新しいカスタマ・オブジェクトの作成、またはカスタマ属性のいずれかの変更等のイベントを聴取する。これらのイベントに基づいて、サーバ１０６は、既存のＶＣＯを更新する。いずれかのアプリケーション１０４において新しいカスタマが作成されると、ライフサイクル・マネージャ３０４は、まず、新しいカスタマをオブジェクト・レジストリ３１４に対して照合しようとする。サイフサイクル・マネージャ３０４に充分な情報が渡されている場合、ライフサイクル・マネージャ３０４は、捕獲プロセスを開始して、残りの情報を収集し、次いでこれを再び照合しようとする。一致が発見されない場合、新しいカスタマを永続データベース３１６に追加し、新たに作成した複合オブジェクトをキャッシュにロードする。カスタマがすでに永続データベース３１６に存在する場合、ライフサイクル・マネージャ３０４は、そのＶＣＯをキャッシュにロードする。いずれかのアプリケーションまたはタッチポイントにおいて、いずれかのカスタマ・オブジェクトの属性が変化した場合、サーバ１０６は、このイベントを捕捉し、イベントおよびいずれかのポリシーからの内容の値を、対応するＶＣＯに適用する。このように、ＶＣＯは常に更新して保持される。

ライト・バック
カスタマに関するデータは、複数のアプリケーション１０４に常駐することができる。企業１０２の業務プロセスに応じて、１つのアプリケーション１０４の変更が別のアプリケーション１０４にポピュレートされるのに時間がかかる場合がある。サーバ１０６は、マルチソース・アプリケーション同期を管理するのに役立つ。サーバ１０６によって、１つのアプリケーション１０４からのＶＣＯの更新は、別のアプリケーション１０４において同じ情報を更新するために、ポリシーを適用させることができる。アプリケーション１０４のいずれかにおけるカスタマ属性のいかなる変更も、そのカスタマに割り当てられたＶＣＯにおいてリアルタイムで更新される。ＶＣＯの唯一のインスタンスが企業１０２全体を通して利用されることが保証されるので、更新される情報は他のアプリケーション１０４に即座に利用可能となる。

ライフサイクル・キャッシング
キャッシュにおけるＶＣＯのライフサイクルは、カスタマ・ルックアップを最適化するためにインテリジェントに管理される。これは、メモリに保持されるか消去されるようにＶＣＯを管理し支配するライフサイクル・ルールおよびポリシーに関連する。ライフサイクル・マネージャ３０４によって、オブジェクトを除去し、作成し、またはキャッシュにロードし、次いでキャッシュ保有ポリシーによって管理する。長期間用いられていないＶＣＯは消去し、それに含まれる情報は、この情報のソースであったアプリケーション１０４に送り返す。ＶＣＯが未使用のままとすることができる時間期間は、ユーザが確定し、必要に応じて変更可能である。開示するシステムの１つの実施形態では、ＶＣＯは、使用可能なライフサイクル・ルールおよびシステムにおいて利用可能なメモリ・リソースに基づいて、「期限が切れる」可能性がある。ライフサイクル・マネージャ３０４は、値システムを用いる。すなわち、最低の値であるオブジェクトは、最初にパージされる。ライフサイクル・マネージャ３０４は、サーバ１０６のメモリおよびリソース可用性を、メモリに維持されるオブジェクト数と比較検討する。

ＶＣＯの概念およびアクティビティ・サーバ上でのその実施について説明したので、これ以後、本発明を、例示的なＶＣＯおよびアクティビティ・サーバの実施技法によって説明する。ＶＣＯを実施し、サーバ１０６の各コンポーネントを設計するために、モデル駆動手法を用いることができる。

モデル駆動手法は、サーバ１０６を動作させるために全ての必要なモデルおよびファイルを作成、ロード、および試験するのに役立つフレームワークを利用する。フレームワークは、カスタマに特定的である完全なＶＣＯを作成するため、企業１０２における様々なアプリケーションの機能を同期させる。フレームワークは、グラフィカル・ユーザ・インタフェースを有する。企業１０２の従業員は、グラフィカル・ユーザ・インタフェースによってフレームワークを操作することができる。企業におけるいかなる変更も、このインタフェースによって従業員に伝達される。従業員は、グラフィカル・シンボルによって、またはＶＣＯに関するメッセージおよびリポートによって、ＶＣＯの状態の変更について知らされた状態を維持する。

フレームワークは、ＶＣＯを作成し管理するための５つのコンポーネントを有する。すなわち、モデル、照合、マップ、ロード、およびビューである。これらの各々について、以下で詳細に説明する。

モデル
モデルは、ＶＣＯモデルを作成するために必要な全てのツールを供給する。モデリングの手法は、従来のオブジェクト・モデリングおよびデータ・モデリングを用いる。ＶＣＯモデルは、カスタマまたは企業１０２の他のリソースに関する情報を概略を示すためのリアルタイム・モデルである。オブジェクト・モデルを利用して、リアルタイムの決定について最も良好なＶＣＯアプリケーションを組織化、視覚化、および構築する。オブジェクト・モデルは、企業のビジネス要求に基づいて、実世界のエンテイティをモデル化し、重要なデータおよび挙動をカプセル化する。好適な実施形態では、ＶＣＯは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）に基づくものであり、一貫性を提供しながら拡張性を可能にするように設計されている。

モデルは、２つのタイプ、すなわち単純および複雑というデータ定義を用いて、オブジェクト・モデルを作成する。単純タイプは、ブール、ストリング、日付等のデータ・タイプについてのシステムおよびユーザが定める定義を表す。更に、列挙、パターン化ストリング、および並べた値等の他の単純タイプも作成することができる。複雑タイプは、オブジェクト・モデルの基本的な定義を与え、単一の属性または１群の属性を表す。いったん基本的な定義を作成すると、これを、属性集合と呼ぶオブジェクト・モデルの動作上の定義において使用および再使用することができる。属性集合は、複雑タイプのインスタンスを用い、サーバ１０６が実行時に用いる追加の動作値を含む。照合、永続、捕獲、発生、ソース、優先、および要求属性は、異なるタイプの動作値であり、属性に添付される。照合という動作値は、照合のために用いる属性に関連する。永続という動作値は、照合目的のため、または、結果として得られるデータが他のいずれかのアプリケーションに存在しないため、永続データベース３１６における属性の保存に関する。捕獲という動作値は、ＶＯＣが作成された場合にソース・アプリケーションから収集される属性に関する。発生という動作値は、１対１、１対他、他対他等の属性の濃度を指定する。ソースという動作値は、属性の内容を含むソース・アプリケーション１０４を指定する。優先という動作値は、これらの属性が常駐することができるマルチソース・アプリケーション１０４の順序を指定する。要求属性という動作値は、マルチソース調和プロセスにおいてデータ・マージ機能を完了させるために必要な要求属性を指定する。いったん属性集合が作成されると、それらは、複雑タイプの同じインスタンスを用いることによって更新することができる。いったん複雑タイプを更新すると、そのインスタンスを用いる全ての属性集合は自動的に更新される。これによって、大きなオブジェクト・モデルの変更および管理がはるかに容易になる。

モデルは、定義を論理カテゴリにグループ化するのに役立つカテゴリの作成を容易にする。これによって、大きなオブジェクト・モデルをナビゲートし、変更を管理し、協調させ、および全体的に管理することを簡単にする。モデルは、ＶＣＯモデルを作成する際に使用可能な４つのタイプの関係を有する。すなわち、相続、主要キー（ＰＫ）、外部キー（ＦＫ）、および遠隔参照である。相続により、多数の複雑タイプを作成する。子の複雑タイプは、親の複雑タイプの属性を相続する。この機能は、いくつかの定義が共通の属性を共有し得る場合に、サブタイプの定義の作成を容易にする。ＰＫおよびＦＫ関係は、属性集合の定義間の従来の関係の設定を容易にする。遠隔参照は、１つのＶＣＯモデルから別のＶＣＯモデルへの属性集合定義を関連付ける。これらの全ての関係により、フレームワークのグラフィカル・ユーザ・インタフェースに完全な情報を伝達することがはるかに容易になる。

モデルは、複合オブジェクト・モデルの２つのビューを有する。「ツリー・ビュー」は、作成している進行中のモデルの「順序付けた」内容を表示し、一方、「図形ワークシート・ビュー」は、プロジェクトおよびビジネス・プランニングのために必要な属性集合、それらのデータ構造および関係の考察のための提示媒体として使用可能な複合オブジェクト・モデルのグラフィカル・ビューを提示する。ツリー・ビューまたはデフォルトのヒエラルキ図のいずれかの更新は、グラフィカル・ユーザ・インタフェースの別の１区画において自動的に反映される。

照合
フレームワークの照合コンポーネントにおいて、照合のプロセスを実行する。このプロセスは、４つのステップで実行される。第１に、ソース・レコードを標準化し、照合し、インデクスを付ける。第２に、インデクスおよび参照データの参照テーブルを構築しロードする。第３に、既存および新しいユーザを認識するための実行時照合ルールを検証し試験する。第４に、照合例外プロセスを調べて設定し、変更された全てのレコードを自動的に再検証する。

アプリケーション１０４からの未知のカスタマ・オブジェクトをＶＣＯと照合するために用いられるＶＣＯモデルからの１組の属性を、照合セットとして指定する。照合コンポーネントは、単純なユーザ・インタフェースを提供して、多数のアプリケーション１０４を通じて共通のカスタマをマッチングするための基準を設定する。照合コンポーネントを用いて、ＶＣＯモデルから基本的な属性を選択し、プロセス前ステップを適用し、照合セットの感度を選択する。次いで、適切な照合セットを選択し、照合基準またはルールを作成する。照合エンジン３０８は、３つの基準またはルールを用いて一致を査定する。照合セットの感度は、各カスタマ・オブジェクトが、一致であることを判定するためにどのくらい正確でなければならないかを示す。例えば、社会保障番号は、正確な照合であるが、カスタマの名前は正確さが低い照合とすることができる。照合基準は、照合セットを用いてオブジェクトに対する一致を判定するシーケンスを規定する、順序付けられたルールである。照合エンジン３０８は、各ルールを順次用いて一致を判定する。開示するシステムの１つの実施形態は、照合プロセスの間に照合タイプを利用する。照合タイプは、タイプを指定することによって、照合エンジン３０８が派生物および省略を認識することに役立つ場合に、追加の処理力を与える。

異なるプロセス前機能を属性に適用して、照合プロセス中に用いられる異なる属性結果を生成することができる。連結のプロセス前機能は、用いる属性を照合セットとして結合する。例えば、ファースト・ネームがＪｏｈｎ、ミドル・ネームがＨａｒｒｙ、ミドル・ネームがＯｌｉｖｅｒ、およびラスト・ネームがＳｍｉｔｈとして属性を有するカスタマ・オブジェクトでは、連結プロセスは、これらを単一の名前、すなわちＪｏｈｎ Ｈａｒｒｙ Ｏｌｉｖｅｒ Ｓｍｉｔｈに結合し、これを照合に用いる。入れ替えプロセス前機能は、照合セットとして用いる属性の結合を変える。例えば、ファースト・ネームがＪｏｈｎ、第１のミドル・ネームがＨａｒｒｙ、第２のミドル・ネームがＯｌｉｖｅｒ、およびラスト・ネームがＳｍｉｔｈとして属性を有するカスタマ・オブジェクトでは、入れ替えプロセス前機能によって、結果として、２つのアイテムすなわちＪｏｈｎ Ｈａｒｒｙ ＳｍｉｔｈおよびＪｏｈｎ Ｏｌｉｖｅｒ Ｓｍｉｔｈが得られる。

マップ
フレームワークのマップ・コンポーネントでは、アプリケーション１０４をＶＣＯモデルにマッピングする。好適な実施形態では、グラフィカルのＥｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ（ＸＳＬＴ）ツールであるｅＸｃｅｌｏｎ ＣｏｒｐｏｒａｔｉｏｎのＳｔｙｌｕｓ Ｓｔｕｄｉｏ（商標）が、アプリケーション１０４をＶＣＯモデルにマッピングするために用いられる。全てのプロジェクト・ファイルを、フレームワークを介して管理する。これによって、捕獲要求、イベント、ライト・バック、およびビューをマッピングするために全てのファイルを生成することが迅速かつ容易になる。フレームークおよび外部のアプリケーション・ソースからのサンプルＸＭＬを用いて、ＸＭＬ出力のプレビューを見ることができる。いったん全マッピングが完了すると、プロジェクトを保存し、サーバ１０６に提示することができる。

ロードおよびビュー
フレームワークのロード・コンポーネントは、照合のために用いられるカスタマの基本データを永続データベース３１６にロードするのに役立つ。いったんデータをサーバ１０６に提示すると、フレームワークのビュー・コンポーネントを用いて、カスタマ識別インデクスまたは、オブジェクト、属性集合、属性等の検索パラメータの入力のいずれかにより、ＶＣＯを検索する。検索の結果は、全ＶＣＯ内容を提示する。

コンテキストの適用および管理
ＶＣＯにより何が起こっているかを真に理解するため、ＶＣＯに、警告、シナリオ、およびポリシーを適用する。特定の企業について、警告、ルール、および条件を設定し、カスタマイズすることができる。例えば、警告を企業１０２の販売代理店に送り、カスタマの製品出荷が遅れていることを示す。この警告は永久に有効ではないので、ある時間量が経過した後、警告を非活性化することができる。警告、ルール、および条件をカスタマイズして、特定の組織に合わせることができる。

様々なビジネス・シナリオに対処するため、シナリオ・ルールを設定し、これによってＶＣＯにおける属性または１組の属性を更新することができ、またはそのために設定した値を有することができる。フレームワークは、２つのタイプのインテリジェントな値を供給する。すなわち、明示的データ値および導出データ値である。明示的データ値の例は、ある時間期間にわたって、企業１０２においてカスタマの合計購入量の現在の合計を維持することである。カスタマが製品購入を行うたびに、シナリオ・ルールは、ＶＣＯを、その期間の新しい合計で更新する。カスタマの気分は、カスタマの企業とのインタラクションの頻度および新しさならびに製品配達の状況および問題報告に基づいた、導出データ値の例である。頻度が充分であり、短期間にわたって、製品配達状況が遅れ、問題報告が保留されている場合、シナリオ・ルールを設定して、カスタマの気分は不満であり得ることを示すことができる。

企業１０２は、企業１０２内のアプリケーション１０４に常駐するカスタマ・データを有する。各アプリケーション１０４にデータを入力する方法は、そのデータを誰が入力しているかによって異なる。経理または戦略部門は完全なレコードに関心があるであろうが、販売チームは通常、電話番号、電子メール・アドレス、および名前のみを入力する場合がある。更新したデータによって異なるアプリケーション１０４をポピュレートするために要する処理時間は、システムにおいて遅延を生じる恐れがある。これは、手動でまたは、場合によっては電子メールで実行可能なプロセスである。特定のカスタマ情報を処理するため、ソース・システムが優先される。

本発明は、冗長データを捜す前に、検索する必要があるアプリケーション１０４が利用可能であることを保証する。しかし、いかなる企業でも、時に、それらのシステムは利用可能でない。それらは、情報の問合せにおいて長い遅れ時間を有する場合があり、または、それらは、保守のためダウンする場合がある。従って、識別されたソース・アプリケーションについて、あるタイムアウトがセットされる。タイムアウトの期間は、構成可能であり、ソース・システムのタイプによって様々なものにすることができる。

２つの方法を用いて、マルチソース・アプリケーション１０４からのデータを管理し、マージし、更新することができる。これらの方法は、優先およびタイム・スタンプである。優先は、ソース・システムを優先する方法に基づく。これは、一般に、第１の優先アプリケーション１０４が常に最も正確な情報を有することが確かである場合に用いられる。優先アプリケーション１０４が応答しないか、または利用可能でないならば、次の優先アプリケーション１０４に譲る。タイム・スタンプは、総合データを比較してどのアプリケーション１０４が最も最近更新されたか、すなわち最新のタイム・スタンプを判定することに基づく。これらの方法の各々により、捕獲プロセスに「待機」または「非待機」状態を置くことができる。待機状態のオプションは、適切な更新を続ける前に捕獲要求から全ての応答が戻されるまで待つ。このように、ポリシーに基づいて最も正確なデータを供給するが、これは、ＶＣＯの要求元への送信に影響を与える可能性がある。非待機状態は、性能最適化のために用いられる。適切なアプリケーション１０４のデータが収集されＶＣＯにポピュレートされる時まで、第１のアプリケーション１０４が複合オブジェクトに応答し更新する。

利点
本発明は、企業が、作動可能なリアルタイムのＶＣＯによって、カスタマの企業ビューを向上させることに役立つ。ＶＣＯは、柔軟なオブジェクト指向モデルであり、ＥＲＰ、ＣＲＭ、ｅＣｏｍｍｅｒｃｅおよびＡｎａｌｙｓｉｓアプリケーションからの重要データおよび挙動をカプセル化する。全てのアプリケーション１０４およびタッチポイントからの重要情報に対するアクセスによって、ユーザは、関連するオファーを提供し、聡明に質問に答え、迅速に問題を解決するための能力を有する。本発明は、リアルタイムの文脈上のカスタマ・ビューを迅速に構築および展開するのに役立つ。本発明において提案されるようなサーバ１０６は、クラスタ化されたマルチスレッド・エンジンであり、リアルタイムでカスタマ・セッションを捕捉する。リアルタイムのソリューションによって、企業は、カスタマとの関係を満足させ、維持し、成長させることができる。本発明は、同期および非同期の双方で、双方向通信を提供する。本発明は、問合せをアンロードすることによってカスタマ１０８から得たデータを統合し、このためアプリケーション１０４の過剰な負担を回避する。本発明は、軽量であるが、より堅固な機構であり、データを別のデータ記憶装置に複製するのではなく、データをまとめる。モデル駆動手法によって、論理モデルは、クリーンで正確なデータを双方向に同期させソース・システムに伝搬させるためのビジネス論理を容易かつ柔軟に変更する方法を提供する。また、論理モデル手法によって、固定した関連モデルとは逆に、多数の目的のために同じサーバ内で多数のモデルを作成することができる。更に、この手法は、複合データを真に見て情報を信頼性高く評価する唯一の手法である。これらの全ての利点により、本発明は、企業１０２におけるカスタマ・アクティビティを調整することによってカスタマ・プロセスを容易にする。

ハードウエアおよびソフトウエア実施
本発明のシステムは、例えば、８００ＭＨｚを有するデュアルＣＰＵまたはもっと高速のプロセッサ上で実施可能である。本発明の好適な実施形態は、２つのクラスタ・サーバを有するクラスタ・サーバ環境において実施することができる。これらのサーバは、例えば、４００ＭＨｚで動作する４ウエイＳｕｎＥ４５０サーバとすることができる。それらは、Ｏｒａｃｌｅ８iデータベースを共に、別個のサーバに対して動作することができる。サーバ１０６の全ての機能は、かかる環境において実施し、所望の結果を出すことができる。開示するシステムの実施に使用可能な様々なソフトウエアは、オペレーティング・システムとしてはＷｉｎｄｏｗｓ（登録商標）２０００サーバＳＰ２またはＳｏｌａｒiｓ８．０、永続データベース３１６としてはＭＳ−ＳＱＬ２０００またはＯｒａｃｌｅ８iである。

本発明の好適な実施形態を例示し説明してきたが、本発明はこれらの実施形態のみに限定されないことは明らかであろう。特許請求の範囲に記載された本発明の精神および範囲から逸脱することの無い、多数の修正、変更、変形、置換、および均等物は、当業者には明らかであろう。

開示するシステムの全体的な環境を示す。 開示するシステムの動作の概要を示すフローチャートである。 本発明の１実施形態に従ったサーバの様々な構成要素を示す。 本発明の１実施形態に従った問合せエンジンの動作を示すフローチャートである。 本発明の１実施形態に従った照合エンジンの動作を示すフローチャートである。 本発明の１実施形態に従ったルール・エンジンの動作を示すフローチャートである。 本発明の１実施形態に従った捕獲プロセスの動作を示すフローチャートである。

符号の説明

１０２ 企業
１０４ アプリケーション
１０６ サーバ
１０８ カスタマ
３０４ ライフサイクル・マネージャ
３０６ 問合せエンジン
３０８ 照合エンジン
３１０ ルール・エンジン
３１２ ハーベスタ
３１４ オブジェクト・レジストリ
３１６ 永続データベース

Claims (14)

1. 複数のデータ記憶装置を介する、複数の顧客と１つの企業との交渉に関するデータの統合管理方法であって、
   前記方法は、１以上のコンピュータにおいて、
   前記企業のデータ記憶装置にアクセスするアプリケーションと顧客との交渉に対応して、前記顧客に関するデータを含むオブジェクトに対する要求であって前記顧客を識別する参照データの第１のセットを含む要求を、前記アプリケーションから受け取るステップと、
   前記参照データの前記第１のセットを利用して、各顧客を一意に識別する参照データを格納する第１のデータ記憶装置から前記顧客に関する参照データの第２のセットを収集するステップと、
   前記参照データの前記第２のセットを利用して、前記顧客と前記企業との交渉に関する交渉データを少なくとも１つの第２の記憶装置から収集するステップと、
   前記収集した前記参照データの前記第２のセット及び前記交渉データを用いて、前記顧客に関するデータを含む前記オブジェクトを作成するステップと、
   前記オブジェクトを前記要求元のアプリケーションにリアルタイムに届けるステップと、
   を含み、
   前記オブジェクトは、前記顧客と前記アプリケーションとの交渉に対応して、前記収集したデータの少なくとも一部を前記アプリケーションが修正することを可能にするためのものであり、且つ、前記収集したデータに対する前記修正を前記第１及び第２のデータ記憶装置と同期させるためのものである、
   ことを特徴とする方法。
2. 前記１以上のコンピュータにおいて、前記顧客と前記アプリケーションとの交渉に対応して前記オブジェクトを更新するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. どのように前記オブジェクトの個別データが前記オブジェクトの他の個別データと関連付けられるか、または、どのように前記個別データが他の顧客の他のオブジェクトの中のデータを参照するかを特定する関連度情報を、前記オブジェクトはさらに含むことを特徴とする請求項１又は２に記載の方法。
4. 前記オブジェクトは、前記複数のデータ記憶装置を跨いで前記オブジェクトに対する変更を同期させるための１組のポリシーを伴うことを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 前記オブジェクトを作成するステップは、
   前記収集されたデータの重要度を決定するステップと、
   前記オブジェクトを作成するため、前記収集されたデータのうち重要度が高いと決定されたサブセットを使用するステップと、
   をさらに含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 複数のデータ記憶装置を介する、複数の顧客と１つの企業との交渉に関するデータの統合管理システムであって、
   前記システムは、
   顧客が前記企業のデータ記憶装置にアクセスするアプリケーションと交渉するのに対応して、前記アプリケーションから、前記顧客に関するデータを含むオブジェクトに対する要求であって前記顧客を識別する参照データの第１のセットを含む要求を受け取る手段と、
   前記参照データの前記第１のセットを利用して、各顧客を一意に識別する参照データを格納する第１のデータ記憶装置から前記顧客に関する参照データの第２のセットを収集する手段と、
   前記参照データの前記第２のセットを利用して、前記顧客と前記企業との交渉に関する交渉データを少なくとも１つの第２の記憶装置から収集する手段と、
   前記収集された前記参照データの前記第２のセット及び前記交渉データを用いて、前記顧客に関するデータを含む前記オブジェクトを作成する手段と、
   前記オブジェクトをリアルタイムで前記要求元アプリケーションに届ける手段と、
   を含み、
   前記オブジェクトは、前記顧客と前記アプリケーションとの交渉に対応して、前記収集されたデータの少なくとも一部を前記アプリケーションが修正することを可能にするためのものであり、且つ、前記収集されたデータに対する前記修正を前記第１及び第２のデータ記憶装置と同期させるためのものである、
   ことを特徴とするシステム。
7. 前記参照データの前記第２のセットは、顧客識別インデクスを含み、
   前記システムはさらに、前記第２のデータ記憶装置において同一の前記顧客を示すために使用される、前記顧客識別インデクスに対する相互参照を格納するオブジェクト・レジストリにアクセスする手段を含み、
   前記第２の記憶装置から前記交渉データを収集する前記手段は、前記オブジェクト・レジストリに格納された前記相互参照に基づいて前記交渉データを捕獲する
   ことを特徴とする請求項６に記載のシステム。
8. 前記顧客と前記アプリケーションとの交渉に対応して前記オブジェクトを更新する手段をさらに含むことを特徴とする請求項６または７に記載のシステム。
9. 前記顧客の前記データ記憶装置との交渉に関するデータと、
   前記オブジェクトを更新するためのポリシーと、
   どのように前記収集されたデータの中の個別データが他の個別データと関連付けられるか、または、どのように前記個別データが他のオブジェクトの中のデータを参照するかを特定するメタデータと、
   を用いることにより、前記オブジェクトが作成されることを特徴とする請求項６から８のいずれか１項に記載のシステム。
10. 前記オブジェクトを作成するため、前記顧客に関する前記収集されたデータの重要度を決定する手段をさらに含むことを特徴とする請求項６から９のいずれか１項に記載のシステム。
11. 複数のデータ記憶装置を介する、複数の顧客と１つの企業との交渉に関するデータの統合管理ためのコンピュータ・プログラムを保存するコンピュータ読取可能媒体であって、
    前記コンピュータ・プログラムは、少なくとも１つの演算処理器による実行のためのものであり、前記コンピュータ・プログラムは、
    前記企業の記憶装置にアクセスするアプリケーションと顧客との交渉に対応して、前記顧客に関するデータを含むオブジェクトに対する要求であって前記顧客を識別する参照データの第１のセットを含む要求を、前記アプリケーションから受け取るステップと、
    前記参照データの前記第１のセットを利用して、各顧客を一意に識別する参照データを格納する第１のデータ記憶装置から、前記顧客に関する参照データの第２のセットを収集するステップと、
    前記参照データの前記第２のセットを利用して、前記顧客と前記企業との交渉に関する交渉データを少なくとも１つの第２の記憶装置から収集するステップと、
    前記収集された前記参照データの前記第２のセット及び前記交渉データを用いて前記顧客に関するデータを含む前記オブジェクトを作成するステップと、
    前記オブジェクトを前記要求元のアプリケーションにリアルタイムに届けるステップと、
    を前記少なくとも１つの演算処理器に実行させる命令セットを含み、
    前記オブジェクトは、前記顧客と前記アプリケーションとの交渉に対応して、前記収集されたデータの少なくとも一部を前記アプリケーションが修正することを可能にするためのものであり、且つ、前記収集されたデータに対する前記修正を前記第１及び第２のデータ記憶装置と同期させるためのものである、
    ことを特徴とする媒体。
12. 前記コンピュータ・プログラムは、前記顧客と前記アプリケーションとの交渉に対応して前記オブジェクトを更新するステップを前記少なくとも１つの演算処理器に実行させる命令セットをさらに含むことを特徴とする請求項１１に記載のコンピュータ読取可能媒体。
13. 前記オブジェクトを作成するステップは、
    前記顧客の前記データ記憶装置との交渉に関するデータを取得するステップと、
    前記オブジェクトを更新するためのポリシーを取得するステップと、
    どのように前記収集された前記参照データの前記第２のセット及び前記交渉データの中の個別データが他の個別データと関連付けられるか、または、どのように前記個別データが他のオブジェクトの中のデータを参照するかを特定するメタデータを取得するステップと、
    を含むことを特徴とする請求項１１または１２に記載のコンピュータ読取可能媒体。
14. 前記コンピュータ・プログラムは、前記顧客に関する前記収集されたデータの重要度を決定するステップを前記少なくとも１つの演算処理器に実行させる命令セットをさらに含み、
    前記オブジェクトを作成するステップは、前記収集されたデータのうち重要度が高いと判定されたサブセットを使用するステップを含む
    ことを特徴とする請求項１１から１３のいずれか１項に記載のコンピュータ読取可能媒体。

Images