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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

既存の技術に関連した欠点を考慮すると、現在のインタラクションの企業の全ての部分
を更新するために不可欠なビジネス・プロセスおよびルールの統合を提供可能なシステム
に対する要望がある。また、企業全体で情報を高速かつ効率的に転送するシステムが求め
られている。更に、カスタマに関連する情報をリアルタイムで更新するシステムに対する
要望がある。また、重複データを処理可能であり、同一のカスタマに対するデータのマー
ジおよび参照を行いつつ、カスタマ・データの完全さを調和させ維持する能力を有する解
決策に対する要望がある。また、多数のチャネルまたはアプリケーションにわたってカス
タマのアクティビティを把握し、次のインタラクション・ポイントにおいて最新の関連す
るカスタマのアクティビティを利用する必要がある。

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

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

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

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

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

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

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

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

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

これより、本発明の好適な実施形態について、限定ではなく例示のために与える添付図
面に関連付けて説明する。図面において、同様の符号は同様の要素を示す。
開示するシステムの全体的な環境を示す。 開示するシステムの動作の概要を示すフローチャートである。 本発明の１実施形態に従ったサーバの様々な構成要素を示す。 本発明の１実施形態に従った問合せエンジンの動作を示すフローチャートである。 本発明の１実施形態に従った照合エンジンの動作を示すフローチャートである。 本発明の１実施形態に従ったルール・エンジンの動作を示すフローチャートである。 本発明の１実施形態に従った捕獲プロセスの動作を示すフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (14)

1. 複数のデータ・ソースを有する企業内のアクティビティを管理するコンピュータシステムであって、
   前記企業に関係付けられた顧客に関するデータの要求をアプリケーションから受信する問合せエンジンと、
   複数のデータ・ソースにおいて同一の顧客を表すために使用される顧客識別インデクスの各々に対する相互参照を維持するオブジェクト・レジストリと、
   前記顧客に関する複合オブジェクトの要求を前記問合せエンジンから受信し、相互参照のセットを取得するために前記オブジェクト・レジストリにアクセスする照合エンジンと、
   前記オブジェクト・レジストリから取得された相互参照の前記セットに基づいて、前記複数のデータ・ソースのうちの少なくとも２つから前記顧客に関するデータを収集し、当該収集されたデータを使用して前記顧客のための複合オブジェクトを作成するハーベスタと、
   前記問合せエンジンが前記複合オブジェクトを前記要求元のアプリケーションにリアルタイムで届けるようにするために、前記ハーベスタによって作成された前記複合オブジェクトを前記問合せエンジンに提供するライフサイクル・マネージャと、
   を備える、コンピュータシステム。
2. 複合オブジェクトを保存するためのキャッシュ・メモリを更に備え、
   前記ライフサイクル・マネージャは、前記問合せエンジンが前記要求を前記アプリケーションから受信すると前記キャッシュ・メモリに対して問合せを行い、特定の複合オブジェクトが前記キャッシュ・メモリの中に保存されている場合、前記問合せエンジンに提供するために当該特定の複合オブジェクトを引き出す、
   請求項１に記載のコンピュータシステム。
3. 前記問合せエンジンは、前記アプリケーションからの前記要求から前記顧客に関する顧客識別インデクスを特定し、
   前記ライフサイクル・マネージャは、前記特定された顧客識別インデクスに基づいて前記キャッシュ・メモリに対して問合せを行う、
   請求項２に記載のコンピュータシステム。
4. 前記複合オブジェクトは、前記顧客の属性のセットに関係付けられており、
   前記複合オブジェクトが前記キャッシュ・メモリに保存されるとき、前記ライフサイクル・マネージャは、前記顧客の前記属性のセットに基づくキャッシュ保有ポリシーのセットを利用することにより、前記複合オブジェクトのライフサイクルを管理する、
   請求項２又は３に記載のコンピュータシステム。
5. 前記複合オブジェクトに対してルールのセットを適用し、当該ルールのセットに従って前記複合オブジェクトを修正し、前記複合オブジェクトに対する当該修正を前記少なくとも２つのデータ・ソースに伝達するルール・エンジンを更に備える、
   請求項１乃至４のいずれか１項に記載のコンピュータシステム。
6. 様々な顧客に関する参照データを保存するための永続データ記憶装置を更に備え、
   前記ハーベスタは、前記少なくとも２つのデータ・ソースからの前記顧客に関するデータに加えて前記永続データ記憶装置から前記顧客に関する参照データを引き出すことにより、前記顧客に関するデータを収集する、
   請求項１乃至５のいずれか１項に記載のコンピュータシステム。
7. 前記参照データは、前記企業の前記複数のデータ・ソースに保存されているデータの一部を表すマスタ参照データを表す、
   請求項６に記載のコンピュータシステム。
8. 前記問合せエンジンは、前記要求を前記アプリケーションから受信した後に、前記要求から前記顧客に関する基本情報のセットを特定し、
   前記照合エンジンは、前記顧客を特定するために、前記基本情報のセットを使用して前記永続データ記憶装置の中を検索する、
   請求項６又は７に記載のコンピュータシステム。
9. 前記照合エンジンは、前記永続データ記憶装置の中に保存されている前記参照データに基づいて前記顧客が特定されなかった場合、前記永続データ記憶装置の中に前記顧客に関する新しいエントリを作成する、
   請求項８に記載のコンピュータシステム。
10. 前記基本情報のセットに部分的に一致するデータが前記永続データ記憶装置の中で特定された場合、前記照合エンジンは、将来的には重複状態を解除しなければならない潜在的な重複として前記特定されたデータをマークする、
    請求項８又は９に記載のコンピュータシステム。
11. アクティビティ・サーバのための、エンティティの企業との交渉に関するデータであって複数の分散したデータ記憶装置の中に保存されている前記データを集中管理する方法であって、前記方法は、前記アクティビティ・サーバの１以上のコンピュータにおいて、
    エンティティに関するデータの要求をアプリケーションから受信するステップと、
    前記アクティビティ・サーバの第１のデータ記憶装置から前記エンティティに関する参照データを収集し、少なくとも１つの他の第２のデータ記憶装置から前記エンティティに関する交渉データを収集するステップと、
    を含み、
    前記参照データは、前記第１のデータ記憶装置の中で前記エンティティを特定し、前記交渉データは前記エンティティと前記企業との交渉に関し、
    前記第１のデータ記憶装置は、前記第２のデータ記憶装置の中の同一のエンティティを表すために使用される相互参照を含むオブジェクト・レジストリを保存し、
    前記交渉データを収集する前記ステップは、前記オブジェクト・レジストリから前記エンティティに関する前記相互参照を取得し、当該相互参照を使用して前記第２のデータ記憶装置から前記交渉データを引き出すステップを含み、
    前記方法は、前記アクティビティ・サーバの前記１以上のコンピュータにおいて、
    前記エンティティのために、前記収集された参照データ及び交渉データをカプセル化する複合オブジェクトを作成するステップと、
    前記複合オブジェクトを前記要求元のアプリケーションにリアルタイムに届けるステップと、
    を含む、方法。
12. 前記アクティビティ・サーバの前記１以上のコンピュータにおいて、
    前記参照データ及び前記交渉データを収集する前記ステップの前に、前記エンティティのための特定の複合オブジェクトが前記アクティビティ・サーバのキャッシュ・メモリの中に存在するか否かを判定するステップと、
    前記特定の複合オブジェクトが前記キャッシュ・メモリの中に存在する場合、前記エンティティに関する前記参照データ及び前記交渉データを収集したり前記複合オブジェクトを作成したりすることなしに、前記特定の複合オブジェクトを前記アプリケーションに届けるステップと、
    を更に含む、請求項１１に記載の方法。
13. 複数の分散したデータ記憶装置を有する企業内での顧客のアクティビティを管理するシステムであって、
    顧客に関するデータの要求をアプリケーションから受信する手段と、
    第１のデータ記憶装置に保存されている参照データから前記顧客を特定する手段と、
    前記顧客の前記特定に基づいて、前記顧客の前記企業との交渉に関する交渉データを第２のデータ記憶装置から収集する手段と、
    前記収集されたデータを使用して前記顧客のための複合オブジェクトを作成する手段と、
    前記複合オブジェクトを前記要求元のアプリケーションにリアルタイムに届ける手段と、
    前記顧客の前記アプリケーションとの交渉に応えて、前記複合オブジェクトに対する変更を前記第１のデータ記憶装置と前記第２のデータ記憶装置とで同期させる手段と、
    を備える、システム。
14. 前記複合オブジェクトは、前記顧客の属性のセットに関係付けられており、
    前記システムは、前記顧客の前記属性のセットに基づくキャッシュ保有ポリシーのセットを利用することにより、キャッシュ・メモリの中の前記複合オブジェクトのライフサイクルを管理する手段を更に備える、
    請求項１３に記載のシステム。

Images