JP2001523363A - Strategic marketing system - Google Patents

Strategic marketing system

Info

Publication number
JP2001523363A
JP2001523363A JP54709498A JP54709498A JP2001523363A JP 2001523363 A JP2001523363 A JP 2001523363A JP 54709498 A JP54709498 A JP 54709498A JP 54709498 A JP54709498 A JP 54709498A JP 2001523363 A JP2001523363 A JP 2001523363A
Authority
JP
Japan
Prior art keywords
client
data
clue
information
clients
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP54709498A
Other languages
Japanese (ja)
Inventor
グリム，ロバート
ソーサ，ライアン
パターソン，ロナルド
トーントン，ポーラ
ゲラー，ロブ
グリーンフィールド，ローレンス
ミラー，アリス
バレット，ポール
クルーガー，アル
Original Assignee
エムシーアイ ワールドコム インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エムシーアイ ワールドコム インコーポレーテッド filed Critical エムシーアイ ワールドコム インコーポレーテッド
Publication of JP2001523363A publication Critical patent/JP2001523363A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Abstract

(57)【要約】 自動マーケティングシステムは、テレマーケティング支援に対して、全範囲のサービスを提供する。自動マーケティングシステムは、クライアントプロフィール管理システムを具備してもよい。該クライアントプロフィール管理システムは、複数のデータプロバイダから（様々なフォーマットで）データを取得し、かつ、標準化されたクライアントプロフィールデータベースへ該データを統合する。自動マーケティングシステムは、データ倉庫を具備する。該データ倉庫は、（潜在的なクライアントに関する）大量のデータを記憶する。オートメーティド糸口生成システムは、（所与のマーケティングキャンペーンに対応した特定の特徴を満たす）糸口を生成するために、データ倉庫内のデータを処理する。これらの糸口は、該糸口を使用するテレマーケッターへ送られてもよい。該結果は、糸口生成戦略を更新するために、かつ、自動マーケティングシステムによって記憶されるクライアントデータを更新するために、自動マーケティングシステムへフィードバックされてもよい。 (57) [Summary] The automatic marketing system provides a full range of services for telemarketing support. The automated marketing system may include a client profile management system. The client profile management system obtains data (in various formats) from multiple data providers and integrates the data into a standardized client profile database. The automatic marketing system has a data warehouse. The data warehouse stores large amounts of data (for potential clients). The automated clue generation system processes the data in the data warehouse to generate clues (satisfying certain characteristics corresponding to a given marketing campaign). These clues may be sent to a telemarketer that uses the clues. The results may be fed back to the automated marketing system to update clue generation strategies and to update client data stored by the automated marketing system.

Description

【発明の詳細な説明】 戦略的マーケティングシステム 技術分野 本発明は、一般的には、遠距離通信システムに関し、かつ、より詳細には、テ レマーケティングのための戦略的マーケティングシステムに関する。 発明の背景 テレマーケティングダイレクトメールおよびテレマーケティングダイレクトセ ールは、近年、ますます広まってきている。種々のビジネスが、該ビジネスの商 品およびサービスを販売するために、マーケティングを使用している。そのよう なマーケティングの目的の１つは、ビジネスの顧客基盤を拡張するために、新た な顧客を確立することである。これらのビジネスは、（マーケティングキャンペ ーンおよび接客によって最も効果的に勧誘されそうな）潜在的な顧客に狙いを付 けることを望む。 従来のシステムは、電話番号またはアドレスによって、接客のための潜在的な 顧客を識別する。一般的には、電話番号またはアドレスの一群が接客リスト上に 収められ、かつ、大規模な電話キャンペーンまたはメールキャンペーンまたは訪 問キャンペーンが行われる。残念ながら、そのような大規模なキャンペーンは、 失敗する割合が一般的に高いので、非常に効率が良いという訳ではない。加えて 、そのようなキャンペーンは、大量の資源を使用する。 従来のシステムでは、（電話番号および顧客名を含む）顧客データは、一般的 に、大規模かつ集中化されたデータベース内に記憶される。いくつかの従来の電 話キャンペーンは、顧客の電話番号（例えば、エリアコードおよび／または３桁 の市内局番）に基づいて、顧客に対するデータベースに問い合わせる。従来の電 話キャンペーンでは、（データベース内の電話番号記録に関する特定の基準につ いてデータベースに問い合わせる）新たなマーケティング戦略およびキャンペー ンが定式化される。データベースは集中化されかつ非常に大きいので、そのよう な問い合わせは、かなりの処理時間を消費し、故に、かなりの時間消費となる。 更に、そのような問い合わせによる結果を、所与の大規模な電話キャンペーンに おいて有効に使用することは、しばしば困難である。更に、マーケティング戦略 およびキャンペーンは、データベース内のデータのタイプおよび構成に制限され る。 発明の概要 本発明の第１の特徴によれば、自動マーケティングシステムが、（クライアン トプロフィールを管理するための）クライアントプロフィール管理システムを具 備する。クライアントプロフィールは、マーケティング接客のための（クライア ントについての）情報を具備する。自動マーケティングシステムは、また、（ク ライアントに関するデータを記憶するための）データ倉庫システムを具備する。 最後に、自動マーケティングシステムは、テレマーケッターによって接客するク ライアントの糸口を自動的に生成するために、データウエアハウスに問い合わせ るための接客インフラストラクチャを具備する。該問い合わせは、「生成された 糸口は、所定の特徴を具備するクライアントに対するものである」ということを 保証するために、データ倉庫内のデータを限定することを引き起こす。 本発明の他の特徴によれば、コンピュータによって実行される方法が、（潜在 的なクライアントに関するデータを記憶した）自動マーケティングシステムにお いて、実施される。テレマーケッターによって接客する潜在的なクライアントの 糸口を（記憶されたクライアントデータに基づいて）生成するための糸口生成器 が提供される。第１マーケティングキャンペーンに対する糸口を生成するために 、糸口生成器が使用される。生成された糸口に接した結果が取得される。そして 、第２マーケティングキャンペーンに対する生成器を導く糸口を生成するために 、該結果が使用される。 本発明の追加の特徴によれば、テレマーケティング接客のための潜在的なクラ イアントに関するクライアント情報がクライアント毎に提供されるように、自動 マーケティングシステムにおいて方法が実施される。テレマーケティング接客に 対する糸口リストを生成するために、クライアント情報が問い合わされる。各糸 口は、潜在的なクライアントに関連し、かつ、第１組の特徴を満たす潜在的なク ライアントに対する接客情報を具備する。そして、該糸口は、テレマーケッター へ送られる。 図面の簡単な説明 本発明の好ましい実施形態は、以下の図面に関して、以下に説明される。 図１は（本発明の好ましい実施形態を実施することに対して適切な）戦略的な マーケティングシステム（ＳａＭＳ）インフラストラクチャを図解するブロック 図である。 図２は、接客サービスインフラストラクチャ（ＣＯＮＩ）のブロック図である 。 図３は、糸口記録の例示的なデータ構造図である。 図４は、糸口分配記録の例示的なデータ構造図である。 図５は（ＣＡＲＭＡを実行することに対して適切な）コンピュータシステムの ブロック図である。 図６は、クライアントデータベースの諭理的な構造を図解する。 図７は、ＣＡＲＭＡ内のデータフローを図解する。 図８は、データを処理するためにＣＡＲＭＡによって実行されるステップを図 解するフローチャートである。 図９は、照合ルールを適用するためにＣＡＲＭＡによって実行されるステップ を図解するフローチャートである。 図１０は（ＣＡＲＭＡの照合ルールテーブル内に見られる）異なるカテゴリの ルールを図解する図である。 図１１は（ＣＡＲＭＡ内で見られる）異なるタイプのオーバーレイルールを図 解する図である。 図１２は、ＳａＭＳインフラストラクチャに対するデータフローを図解するデ ータフロー図である。 発明の詳細な説明 本発明の好ましい実施形態は（ビジネスクライアントに対する完全なマーケテ ィングサービスを提供するための）戦略的なマーケティングシステム（ＳａＭＳ ）を提供する。本発明の好ましい実施形態は、テレマーケティングに対して特に 良く適用される。ＳａＭＳは、オートメーティドデータ収集とクライアント管理 と目録分析と決定支援と糸口生成とキャンペーン管理と注文履行および準備と顧 客追跡と他の戦略的なマーケティングサービスとを提供する。ＳａＭＳは、クラ イアントプロフィールを更新するために、クライアント接客結果のオートメーテ ィドフィードバックを提供する。フィードバックは、また、いくつかの場合にお いて、新たなマーケティング糸口を生成するために、かつ、新たなマーケティン グキャンペーンを定式化するために、かつ、将来のクライアント接客を限定する ために使用される。 ＳａＭＳを伴って開発されたテレマーケティング戦略は（電話番号よりもむし ろ）個々のクライアントに向けられる。電話番号は、クライアントのプロパティ を構成する。ＳａＭＳは、クライアントプロフィール情報を管理するためのデー タベースを具備し、かつ、クライアントに関する大量の情報が、多数の様々なソ ースから受信されてもよい。データは、複数のフォーマットで受信されてもよく 、かつ、複数の異なるタイプのデータであってもよい。クライアントに関する情 報は、戦略的なマーケティングトレンドを分析するために、かつ、人々の（集団 的な）プロフィールを確立するために利用される。これらのトレンドおよびプロ フィールを使用して、エンハンスドマーケティングキャンペーンが処理されるこ とができる。結果として、従来のシステムよりも高い成功率と際立った効率とを 有する顧客糸口が生成される。 １．システム概観 図１は、ＳａＭＳ１００に対する例示的な情報システムアーキテクチャを示す 。ＳａＭＳインフラストラクチャ１００の様々な構成要素は、（ここで説明され るような）多数の目標マーケティング機能を提供するために、図１に示されるよ うに協同して相互作用する。ＳａＭＳインフラストラクチャ１００は、少なくと も３つの機能（クライアント管理と情報管理と接客サービスと）を実行する。 「クライアント管理」は、クライアントを識別し追跡し管理する処理を具備す る。「クライアント」は、現在の顧客と潜在的な顧客（または糸口）との両方を 含む。故に、多くのビジネスは、数億のクライアントを有する。クライアント管 理は、クライアントに関する記述的な行動データを、個別に取得および管理する ことを含む。ＳａＭＳインフラストラクチャ１００における（クライアント管理 のための）主要構成要素は、クライアント取得および維持管理アーキテクチャ（ ＣＡＲＭＡ）１０２である。ＣＡＲＭＡ１０２は、好ましくは、（クライアント 管理のための）データベースおよびデータ処理を提供するソフトウェアシステム である。ＣＡＲＭＡ１０２の例示的な実施形態は、以下に、より詳細に説明され る。 「情報管理」は、クライアント集団全体とトレントとを反映するデータを収集 および記憶および管理する処理である。情報管理は（未処理データを製品および マーケティング戦略のための前後関係内に配置する）判断支援機能およびツール を提供する。情報管理は、一般化されたクライアント集団に関する記述的な行動 データを扱う。情報管理のための主要構成要素は、判断支援システム（ＤＳＳ） １０４である。ＤＳＳ１０４は、大規模データ倉庫からなり、データを収集およ び記憶および管理および分配および分析するための処理を伴う。一般的に、「デ ータハウス」は、会社の外側から抽出された情報のみならず、会社内の多数の部 門（即ち「ビジネス戦略ユニット」）に対する情報の統合体である。ＤＳＳ１０ ４の例示的な実施形態は、図１２を参照して、以下に説明される。 「接客サービス」は、データハウス照会に基づく推断を行い、かつ、（マーケ ティングキャンペーンを定式化するために、かつ、糸口を生成するために）その 推断結果を使用する。この処理は、また（クライアントと行われる）全ての接客 を追跡しかつ管理する。ＣＯＮＩ１０６は、ＳａＭＳインフラストラクチャ１０ ０に対して、接客サービスを提供する。ＣＯＮＩ１０６は、好ましくは、ソフト ウェアシステムである。該ソフトウェアシステムは、ＤＳＳ１０４のデータ倉庫 から抽出されたデータを使用する。該データは、糸口を生成するために（会社の ビジネス戦略ユニットによって定式化される）特定の戦略を伴って抽出される。 ＣＯＮＩ１０６は、クライアントとの接客または糸口を（以下に説明されるよう に）管理および追跡するために、中央糸口貯蔵所（ＣＬＲ）１０８とインターフ ェースする。 （クライアントと行われる）そのような接客に関する情報は、ＳａＭＳインフ ラストラクチャ１００のクライアント管理機能へフィードバックされる。結果と して（ＳａＭＳインフラストラクチャ１００の）クライアント管理機能と情報管 理機能と接客サービス機能とは、以下の処理のくり返しである。即ち、情報管理 機能が、リサーチを実行しかつ推断しかつ戦略を形成するために、未処理データ を前後関係へ入れる。接客サービス機能が、情報管理機能の下で生成されたリサ ーチと推断と戦略とに基づいて、マーケティング戦略を定式化しかつ履行する。 クライアント管理機能が、個々を識別・追跡し、かつ、記述的な行動データを収 集し、かつ、そのようなデータを情報管理機能へフィードバックする。 様々なデータプロバイダ１１０が、データを、ＣＡＲＭＡ１０２およびＤＳＳ １０４へ提供する。データプロバイダ１１０は、クライアントに関する情報を提 供するために、ＳａＭＳインフラストラクチャ１００へのデータ入力のソースを いくつか具備する。データプロバイダ１１０は、内部データソース１１２および 外部データソース１１４の両方から成る。内部データソース１１２の一例は（課 金システムと顧客注文エントリーシステムと注文準備システムと顧客データベー スとマーケティングデータベースと顧客サービスシステムとアカウント受信可能 システムと他の多くのシステムとからの）データ供給を具備する。内部データソ ース１１２は、また、ＳａＭＳインフラストラクチャ１００の他の構成要素（例 えば、ＣＬＲ１０８）からの入力を具備してもよい。外部データソース１１４の 一例は、電話帳と合衆国郵便局名簿とクレジット会社報告と（人々に関する特定 のデータを提供する）多数の第三者データプロダクツとのファイルを具備する。 これらの第三者のデータプロダクツは、人々が購入する製品や人々が行き来する 場所や人々が利用するサービスや人々の興味・要求に関する電話調査結果のよう な情報を具備してもよい。外部データソース１１４は、また、旅客機を頻繁に利 用する乗客プログラムと自動車クラブメンバーシップとヘルスクラブメンバーシ ップと旅行クラブと雑誌購読とを具備してもよい。これらのデータは、クライア ントのメンバーシップおよび（他のビジネスへの）加入を介してクライアントを 追跡する際の手助けのために使用される。 ＣＡＲＭＡ１０２は、データプロバイダ１１０から、特定のクライアントに関 するデータを収集し、かつ（クライアントプロフィールを更新するために）該デ ータを使用する。そして、ＣＡＲＭＡ１０２は、クライアントデータにおける如 何なる変化をも、ＤＳＳ１０４へ（但し、一般化された形式で）供給する。即ち 、ＣＡＲＭＡ１０２は、特定のクライアントの氏名およびアドレスをＤＳＳ１０ ４へ送るのではなく、むしろ、一般的なクライアントのプロフィールを反映する 情報を送る。ＣＡＲＭＡ１０２は、唯一無二のクライアント識別子を、クライア ントプロフィール変化と共に送る。そのため、ＤＳＳ１０４内のデータに基づい て糸口が生成されると、該糸口は、特定の氏名，アドレス，電話番号と照合され ることができる。一般的に、クライアントは、ＳａＭＳインフラストラクチャ１ ００の下で、該ＳａＭＳインフラストラクチャ１００のクライアント識別子に基 づいて識別される。該クライアント識別子は、各クライアントに関連する（唯一 無二の）英数字コードである。クライアント識別子は、ＣＡＲＭＡ１０２および ＤＳＳ１０４で保持される。 ＤＳＳ１０４は、また、データプロバイダ１１０から、データを収集する。Ｄ ＳＳ１０４は、一般的に、特定のクライアントに関するデータではなく、どちら かと言えば、クライアントのグループに関するデータを収集する。そのようなデ ータは、ある国から他の国へ移動した人々の数、または、同じ年に車およびホー ムステレオの両方を購入した人々の数、または、仕事を持ちかつ政党のメンバー である女性の数を含んでもよい。ＤＳＳ１０４によるデータ収集に対する可能性 は、非常に高く、かつ、ＳａＭＳインフラストラクチャ１００のユーザーのビジ ネス要求に従って変化する。ＤＳＳ１０４は、また、以下に説明されるように、 ＣＡＲＭＡ１０２および他のソースから、データを収集する。 ＤＳＳ１０４は「ビジネス戦略ユニット（ＢＳＵ）１１６が、該ＢＳＵのデー タ倉庫内に記憶されたデータにアクセスする」ということを可能にする。ＢＳＵ １１６は、ビジネス戦略とマーケティング戦略とセール戦略とを定式化すること に責任を負う（会社の）部分集合であることができる。例えば、あるＢＳＵ１１ ６は、国際的なクライアントに対して責任を負うことができ、一方、他のＢＳＵ １１６は、国内のクライアントに対して責任を負うことができる。他に、ＢＳＵ １１６は（ＳａＭＳインフラストラクチャ１００を使用する）会社全体であるこ とができる。 ユーザーまたはＢＳＵ１１６は、様々な機能に対して（ＤＳＳ１０４内に記憶 された）データにアクセスする。該機能は、データ調査とデータマイニング（da ta mining）とデータドリリング（data drilling）と予測モデリングと概略照会 （general queries）と結果送付とを具備する。データ調査機能は「ＢＳＵ１１ ６が潜在的に貴重なグループのデータを識別する」ということを支援する。デー タ調査機能は「ＢＳＵ１１６が（マーケティング判断を導くために）予期しない パターンを発見する」ということを支援する。例えば（以下に説明される）デー タ市場３８８の調査は「北東部において５００００ドル以上の収入を有する人々 の８０％は、セルラーサービスを使用する」ということを発見する。ＢＳＵ１１ ６は、その後「収入的特徴および地理的特徴がなぜセルラー利用に通じるのか」 ということを判断することができる。 データ調査機能は、大きなセグメントのデータを識別・分類することを支援す る。データマイニング機能およびデータドリリング機能は、ビジネス機会を更に 識別しかつ定量化するために、これらの大きなセグメントのデータを限定する。 一旦、意味のあるパターンが確立されたならば、該パターンは、数学的モデルと して表されることができる。該数学的モデルは、ある特徴（例えば、５００００ ドルを越える収入やアメリカ北東部の人口等）と他の特徴（例えば、セルラーユ ーザー）との間における相互関係を確立する。これらのモデルに基づいて、ＢＳ Ｕ１１６は、セルラーダイレクトメールキャンペーンに対する候補者の郵送名簿 を作成できる。 概略照会機能は「ＢＳＵ１１６が、データ市場内のデータの（ＤＳＳユーザー インターフェースプロセスを介した）単純な照会を実行する」ということを可能 にする。例えば、ＢＳＵ１１６は、所与の年における総販売について、データ市 場に問い合わせることができる。結果送付機能は「ＤＳＳ１０４が、データを、 （フォーマットされたレポートや３次元グラフィック等のような）複数の方法で 送付する」ということを可能にする。 各ＢＳＵ１１６は、ＤＳＳ１０４のデータ倉庫内のデータの戦略的照会を（特 定の分析的なツールを使用して）実行する。これらの照会の結果に基づいて、Ｂ ＳＵ１１６は、マーケティングキャンペーンを定式化する。そして、ＢＳＵ１１ ６は、選択されたマーケティングキャンペーンを履行するために、ＣＯＮＩ１０ ６を使用する。以下により完全に説明されるように、ＢＳＵ１１６は、ＤＳＳ１ ０４から糸口データを抽出する際に使用する基準を、ＣＯＮＩ１０６へ指定する 。（選択されたマーケティングキャンペーンにおいて目標にされるべきクライア ントである）クライアント糸口を識別するために、糸口データが使用される。「 糸口」は、一般的に、会社の潜在的な顧客であるクライアントである。各糸口は （ＤＳＳ１０４内に記憶された）対応する唯一無二のクライアント識別子によっ て識別される。そして、ＣＯＮＩ１０６は、これらのクライアント識別子を（Ｄ ＳＳ１０４の処理中データ収集／分配プロセスを介してＣＡＲＭＡ１０２から取 得された）氏名および／またはアドレスおよび／または電話番号と照合すること によって、糸口または糸口記録を生成する。このことは、図３を参照して、以下 に説明される。 ＣＯＮＩ１０６が糸口記録を生成すると、ＣＯＮＩ１０６は、これらの記録を ＣＬＲ１０８内に収める。ＣＬＲ１０８は、糸口および（糸口上で実行される） 行動を追跡するために使用される（ＤＳＳ１０４のデータ倉庫より小さい）デー タベースである。ＣＬＲ１０８は、糸口記録および糸口分配記録の両方を記憶す る。（ＣＬＲ１０８内に記憶された）各糸口記録は、クライアント識別子と電話 番号とアドレス識別子番号とに対する欄と、おそらく、以前の接客に対する欄と を具備する。図３は、インフォーミックス（Informix）の下で構成された例示的 な（より詳細な）糸口記録を示し、多数の一般的に自己説明的な欄を示す。ＣＬ Ｒ１０８は、好ましくは、クライアント毎に１つの糸口記録のみを記憶する。Ｃ ＬＲ１０８は、また、糸口分配記録を記憶する。２以上の糸口分配記録が、各糸 口記録に関係付けられることができる。図４は、インフォーミックスの下で構成 された例示的な（より詳細な）糸口分配記録を示し、多数の一般的に自己説明的 な欄を示す。各糸口分配記録は、特定のＴＭ／ＤＭセンタ１１８や各センタへ送 られる多数の記録や日付や優先コードなどを識別するための欄を具備する。 （ＣＯＮＩ１０６によって生成され、かつ、ＣＬＲ１０８内に記憶される）糸 口記録は、ＣＯＮＩによって、１または２以上のテレマーケティング／ダイレク トメールセンタ（ＴＭ／ＤＭセンタ）１１８へ分配される。ＴＭ／ＤＭセンタ１ １８は、コールセンタを具備する。テレマーケティングエージェントは、クライ アント接客とクライアントセールとクライアントサービスとを、該コールセンタ から、電話を通して実行する。しばしば、ＴＭ／ＤＭセンタ１１８は（マーケテ ィングキャンペーンが処理される）各「セールスシティ」内に配置される。しか しながら、ＴＭ／ＤＭセンタ１１８は、該センタが置かれた都市の外側でマーケ ティングキャンペーンを処理できる。 ＴＭ／ＤＭセンタ１１８は、また、センタを具備し、ダイレクトメールキャン ペーンは、該センタから処理される。本発明は、一般的に（ＴＭ／ＤＭセンタ１ １８で実行される）テレマーケティングキャンペーンに関して以下に説明される が、当業者は「本発明の実施形態は、ダイレクトメールキャンペーンに対して、 同様に適用可能である」ということを即座に認識する。加えて、本発明は、物理 的にまたは（電子メールまたはインターネット接続を介するような）電子的にク ライアントに接客する他の方法に対して、同様に適用可能である。 ＴＭ／ＤＭセンタ１１８におけるエージェントは、クライアントを呼び出し（ または、クライアントに接客し）かつセール機能（および／または、サービス機 能）を実行するために、（ＣＯＮＩ１０６によって該エージェントに提供される ）糸口記録を使用する。エージェントは、これらの接客の結果を、ＴＭ／ＤＭセ ンタ１１８へ入力する。ＴＭ／ＤＭセンタ１１８は、該結果を、ＣＯＮＩ１０６ へ送る。ＣＯＮＩ１０６は、これらの結果に基づく情報を（データプロバイダ１ １０としての）ＣＡＲＭＡ１０２およびＤＳＳ１０４の両方へフィードバックす る。例えば、もし、クライアントが（該クライアントに長距離サービスを売るた めに）接客され、クライアントが「クライアントは、代わりに、該クライアント のローカル電話サービスプロバイダを切り換えることの方を好む」ということを 示すならば、エージェントは、この指示を、ＴＭ／ＤＭセンタ１１８において、 ファイル内に記録する。そして、クライアントのローカル電話サービスプロバイ ダを切り換えることの方を好む全てのクライアントのファイルが（データプロバ イダ１１０としての）ＣＡＲＭＡ１０２およびＤＳＳ１０４へ送られる。ＣＡＲ ＭＡ１０２は、「このクライアントは、該クライアントのローカルサービスプロ バイダを切り換えることに興味がある」ということを示すように（ファイル内に 具備された）各クライアントのプロフィールを更新するために、この情報を使用 する。そして、この情報は、ＣＡＲＭＡ１０２からＤＳＳ１０４へ、クライアン ト識別子および（ローカルサービスプロバイダを切り換えることの興味を示す） 指標の形式で送られる。この情報は、ＤＳＳ１０４内に記憶される。 ＤＳＳ１０４は、また（データプロバイダとしての）ＴＭ／ＤＭセンタ１１８ から、ＣＯＮＩ１０６を介して、情報を直接受信することができる。該情報は「 例えば、ある都市において、どれだけ多くの人々が自分のローカルサービスプロ バイダを切り換えることに興味があるのか」ということを示す。この情報に基づ いて、ＢＳＵ１１６は「ある都市においてローカルサービスプロバイダマーケテ ィングキャンペーンを計画するのに十分な興味がその都市に存在するか否か」と いうことを判断するために、ＤＳＳ１０４に問い合わせることができる。そして 、ＣＯＮＩ１０６は、ローカルサービスプロバイダキャンペーンのための糸口を 生成できる。上記例は、ＳａＭＳインフラストラクチャ１００内の多数のフィー ドバックループのうちの１つを示す。 ＴＭ／ＤＭセンタ１１８におけるエージェントが新たな顧客と購入契約をする と（または、販売すると）該エージェントは、注文を、顧客注文エントリーシス テム１２０へ直接入力する。顧客注文エントリーシステム１２０は（注文を記録 しかつ準備することに加えて）更新データをＤＳＳ１０４へ提供する。これは、 注文の結果（または、周囲の情報）を示すためである。例えば、もし、注文が長 距離サービスに対するものであるならば、顧客注文エントリーシステム１２０は 「このクライアントは、現在、長距離サービスに加入している」ということを示 すために、ＤＳＳ１０４を更新する。 長距離サービスに対する注文は、また、ナショナルＬＥＣインターフェースシ ステム（ＮＬＩＳ）およびクイックプレファードインターエクスチェンジキャリ ア（ＰＩＣ：Quick Preferred Interexchange Carrier）システム１２２へ提供 される。ＮＬＩＳおよびクイックＰＩＣシステム１２２は、注文を、クライアン トのローカル交換キャリア（ＬＥＣ）１２４へ提供する。それによって、ＬＥＣ は、クライアントのＰＩＣを、適切なローカルスイッチで変換できる。ＮＬＩＳ およびクイックＰＩＣシステム１２２は、米国特許出願”System and Method fo r Real Time Exchenge of Customer Data Between Telecommunication Companie s”（COS-96-069）において詳細に説明される。該米国特許出願は、本出願の共 通指定代理人に割り当てられる。ＴＭ／ＤＭセンタ１１８と顧客注文エントリー システム１２０とＮＬＩＳおよびクイックＰＩＣシステム１２２とのアーキテク チャは、クライアントに接客する処理と、長距離サービスをそのクライアントに 販売する処理と、長距離サービスに対する注文を記録・準備する処理と、クライ アントのＰＩＣをたった数分以内で発生する全てのものに（ＬＥＣ１２４スイッ チで）変換する処理とを可能にする。 ＮＬＩＳおよびクイックＰＩＣシステム１２２は、また、非勧誘ＰＩＣ変換の ためのデータを、ＤＳＳ１０４へ提供する。もし、長距離会社の顧客が他の会社 へ切り換えるならば、該顧客のＰＩＣ変換が、ＬＥＣ１２４によって、ＮＬＩＳ およひクイックＰＩＣシステム１２２へ提供される。ＮＬＩＳおよびクイックＰ ＩＣシステム１２２は、これらの変換のファイルを、ＤＳＳ１０４へ提供する。 今度は、ＤＳＳ１０４が、該ファイルを記憶し、かつ「ＣＯＮＩ１０６が、最近 の全てのＰＩＣ変換を抽出し、かつ、顧客取り戻しキャンペーンのための糸口を 生成する」ということを可能にする。 ２．ＣＯＮＩ 図２を参照すると、ＣＯＮＩ１０６の例示的な内部アーキテクチャが示される 。ＣＯＮＩ１０６は、ユーザーが（少なくとも２つの方法で）ＣＯＮＩと相互作 用するために、グラフィカルユーザーインターフェース（ＧＵＩ）１６０を提供 する。該２つの方法とは、糸口市場を構成することと、そのような（構成された ）糸口市場内で照会およびサーチを実行することとである。糸口市場の照会を最 初に考えると（会社のＢＳＵ１１６のような）ユーザーは、マーケティング戦略 をマーケティングキャンペーンへ転換するために、ＧＵＩを使用する。 ＢＳＵ１１６は、最初に（目標となるクライアントに対する）基準を指定する 。例えば（ＤＳＳ１０４のデータ倉庫内のデータに基づいて実行された）先の分 析に基づいて、ＢＳＵ１１６は「カリフォルニアからコロラドへ最近移動しかつ 過去１年間に車を購入した人々は、セルラーサービスへ加入しそうであり、かつ 、自分の長距離プロバイダを切り換えそうである」ということを判断する。この 判断の結果として、ＢＳＵ１１６は、テレマーケティングキャンペーンの下で、 長距離サービスパッケージおよびセルラーサービスパッケージを、これらの人々 へ提供することを望む。ＢＳＵ１１６は「ＢＳＵ１１６が、（１）カリフォルニ アからコロラドヘ移動し、かつ、（２）過去１年間に車を購入し、かつ、（３） 長距離および（会社の）セルラーサービスの両方に現在加入しているというわけ ではない全てのクライアントの記録を、引き出すことを望む」ということを入力 しかつ指定するために、ＧＵＩ１６０を使用する。 キャンペーン管理プロセス１６２は、入力データまたは基準を、ＧＵＩ１３０ から受信し、かつ、そのような基準を、糸口限定フィルター（またはファイル） へ転換する。例えば、キャンペーン管理プロセス１６２は、ストラクチャード照 会ランゲージ（ＳＱＬ：structured query language）ステートメントを使用し て、入力基準に基づいて、照会を作成する。糸口記録のリストを作成するための 照会は、ここでは（以下に説明される）「マーケティングキャンペーン」として 、一般的に説明される。 糸口限定フィルタープロセス１６４は、構成された糸口限定フィルターを、キ ャンペーン管理プロセス１６２から受信する。そして（糸口限定フィルターによ って指定される基準を満たす）クライアントのリストを抽出するために、そのよ うなフィルターを、ＤＳＳ１０４のデータ倉庫内（または、糸口市場１６６内） のデータへ適用する（このことは以下に説明される）。糸口限定フィルタープロ セス１６４は、クライアント記録を（所与のマーケティングキャンペーンのため の「糸口記録」として）抽出するために、糸口限定フィルターを使用し、かつ、 そのような糸口記録を、糸口市場１６６内に共に記憶する（このことは以下に説 明される）。 先の例において、糸口限定フィルターは、最初に、カリフォルニアからコロラ ドへ移動したクライアントに対する全てのクライアント識別子の第１糸口リスト を抽出し、そして、この第１リストに基づいて、過去１年間に車を購入した全て のクライアントの第２糸口リストを抽出してもよい。そして、この第２リストに 基づいて、糸口限定フィルターは、現在（会社の）長距離顧客およびセルラー顧 客の両方であるというわけではない全てのクライアントの（第３のより小さな） 糸口リストを抽出する。糸口限定フィルターは、また、他の望ましくない糸口を 抽出してもよい。該糸口は（接客されないことを要求したクライアント（「抑制 」）、または、年齢が１００歳より大きな（即ち、おそらく死亡している）クラ イアント等である。 一般的に、本発明の例示的な実施形態の下では、選択されたデータの（データ ベースとデータ市場とデータ倉庫とからの）照会および検索は、既知のデータベ ース照会・検索テクニックを使用して、即ち、例えば、ＳＱＬステートメント、 および、オープンデータベース接続（ＯＤＢＣ）を使用して実行される。該テク ニックは、当業者によって知られている。 糸口限定フィルタープロセス１６４は、また（ある糸口限定フィルターに基づ いてＤＳＳ１０４から抽出された）データを糸口市場１６６内に記憶するために 、糸口市場１６６を構成する。「糸口市場」１６６は、データ倉庫より小さなデ ータベースであり、データ倉庫からのデータの部分集合を具備する。一般的に、 糸口市場１６６は、個々のＢＳＵ１１６に対して（ＤＳＳ１０４から）抽出され たデータの（カスタマイズされた）収集物である。ここで説明されるように、Ｂ ＳＵ１１６は、今度は、所与のマーケティングキャンペーンに対する特定のクラ イアントリストを展開するために、糸口市場に問い合わせる。 各糸口市場１６６は、一般的には、（会社内の個々のＢＳＵ１１６のような） ユーザーの個々のグループによって使用される単一題材のデータベースである。 優先注文において、長距離会社に対するそのような糸口市場１６６の例は、パー トナープログラム（例えば、フリークエントフライヤープログラム）に基づく国 際提携の全ての顧客のデータを記憶する糸口市場と、非英語通話国へ頻繁に国際 電話をかける全ての顧客のデータを記憶するデータ市場と、英語通話国へ頻繁に 国際電話をかける全ての顧客に関するデータ市場と、他の長距離会社へ最近切り 換えた全ての以前の顧客の糸口市場と、特定のサービスの全ての顧客の大規模マ ーケット糸口市場とであることができる。これらの共通糸口市場１６６は、進行 中のマーケティングキャンペーンを管理するために、使用されることができる。 例えば、他の長距離会社へ最近切り換えた全ての以前の顧客の糸口市場１６６は 、進行中の顧客取り戻しキャンペーンを管理するために非常に有用である。糸口 市場１６６は、（サンマイクロシステムズによって製造されるSun Doxのような ）分散されたコンピュータ内に具体化されてもよいが、必ずしもそうである必要 はない。 例示的な実施形態において、糸口限定フィルタープロセス１６４は（糸口市場 １６６の）優先注文または階層を提供する。それによって、所与のクライアント は、２以上の糸口市場において識別されない（故に、様々なマーケティングキャ ンペーンの下でくり返し接客されることはない）。例えば、国際提携／協力の顧 客の糸口市場１６６は、英語通話国へ国際電話をかける顧客の糸口市場よりも高 い序列を有する。 糸口限定フィルタープロセス１６４は、名目上の（または、周期的な）処理を 実行するために、セットアップされることができる。例えば、糸口限定フィルタ ープロセス１６４は、先に生成された糸口限定フィルターに基づいてＤＳＳ１０ ４からデータを繰り返し抽出するために、生成されることができる。故に、周期 的な単位で（例えば、毎日）糸口限定フィルタープロセス１６４は（以下に説明 される）データ倉庫出力を介して、ＤＳＳ１０４から（糸口限定フィルターを満 足する）クライアント記録を、周期的に問い合わせかつ抽出し、かつ、対応する 糸口市場１６６を更新する。故に、糸口市場１６６は、現在更新されるデータを 、該糸口市場１６６内に継続的に記憶する。 ユーザーまたはＢＳＵ１１６は、また（明細なクライアントリストを生成する ための）データまたは糸口目録仕様を入力するために、ＧＵＩ１６０を使用する 。該クライアントリストは、所与のマーケティングキャンペーンを履行するため のものである。例えば、ユーザーは「毎日どれだけ多くの糸口記録がフォーマッ トされるべきであるか」ということや「あるリード記録が、どのＴＭ／ＤＭセン タ１１８へ分配されるべきか」ということ等を指定するデータを、ＧＵＩ１６０ へ入力してもよい。糸口目録管理プロセス１６７は、そのような入力データを、 ＧＵＩ１６０から受信する。そして（糸口市場１６６からの）糸口記録の抽出お よび処理を管理するために、該データを使用する。故に、糸口目録管理プロセス １６７は、糸口限定フィルタープロセス１６４に対する方法に類似した方法で、 ＧＵＩ１６０から受信されたデータに基づいて、問い合わせを行う。そして「糸 口リスト」（即ち、所与のマーケティングキャンペーンに基づいて選択された糸 口記録のリスト）を生成するために、所与のマーケティングキャンペーンに基づ いて（１または２以上の糸口市場１６６内に記憶された）糸口記録を抽出する。 糸口目録管理プロセス１６７は（結果として得られた）糸口リストおよび（対応 する）糸口記録を、ＣＬＲ１０８内に記憶する。 糸口リストが、一般的に、糸口記録のリストを具備するのに対して、各糸口記 録は、所与の糸口に対するクライアント識別子のみならず、クライアントに関す る追加情報をも具備する。該追加情報は、例えば、クライアントが接客された回 数および（関連する）日付や、クライアントが接客されたマーケティングキャン ペーンに対応するコード番号である。一般的に、糸口またはクライアントは（マ ーケティングキャンペーンが引き起こされるときに生成される）マーケティング キャンペーンコードに基づいて、ＣＯＮＩ１０６内で追跡されることができる。 更に、糸口目録管理プロセス１６７は、各マーケティングキャンペーンに対して 、糸口分配記録を記憶する。糸口分配記録は「どのＴＭ／ＤＭセンタ１１８に、 所与の糸口記録が分配されるべきか（または、分配されたか）」ということを識 別する。２以上の糸口分配記録が、１つの糸口記録に関連付けられることができ る。なぜならば、糸口記録の下のクライアントは、２以上のマーケティングキャ ンペーンに関連付けられることができるからである。糸口目録管理プロセス１６ ７は、所与のマーケティングキャンペーンに対して、糸口分配記録を生成する。 該糸口分配記録は「毎日どれだけ多くの糸口記録がフォーマットされるべきであ るか」ということや「あるリード記録が、どのＴＭ／ＤＭセンタ１１８へ分配さ れるべきか」ということ等を指定する。 糸口目録管理プロセスは、また（「複製のクライアント記録がＣＬＲ１０８内 に検索されずかつ記憶されない」ということを保証するような）あるスクリーニ ングプロセスを実行する。糸口目録管理プロセス１０７は「所与のクライアント が、２つの異なるマーケティングキャンペーンにおいて識別されることはない（ 故に、２回呼ばれることはない）」ということを保証する。糸口目録管理プロセ ス１６７は、ＣＬＲ１０８内の糸口リストに基づいて識別された各クライアント にフラグを立てる。もし、次の糸口リストが（ＣＬＲ１０８において）既にフラ グを立てられたクライアントを識別するならば、糸口目録管理プロセス１６７は 、新たな糸口リストの階層または評価を（先に所与のクライアントにフラグを立 てた）先の糸口リストの階層または評価と比較する。もし、次の糸口リストが先 の糸口リストより高い序列を有するならば、クライアントは、新たな糸口リスト について、フラグを立てられる。その後、糸口目録管理プロセスは（先の糸口リ ストに基づいてＴＭ／ＤＭセンタ１１８へ以前送られた）糸口記録を（以下に説 明される）フォーマッターを介してキャンセルする。故に、糸口目録管理プロセ ス１６７は、進行中のマーケティングキャンペーンを動的に調整できる。それに よって、より上首尾のキャンペーン（より高い優先度のキャンペーン）が、他の キャンペーンからのクライアントを、統轄しかつ集積する。 一般的に、ＣＯＮＩ１０６は、２つのタイプのデータ検索粒状度（granularit y）を、ＢＳＵ１１６へ提供する。粗い粒状度の下では、ＢＳＵ１１６は、ＧＵ Ｉ１６０とキャンペーン管理プロセス１６２と糸口限定フィルタープロセス１６ ４とを通して、ＤＳＳ１０４からクライアントデータの部分集合を抽出し、かつ 、そのようなデータを糸口市場１６６内に記憶する。より細かい粒状度プロセス において、ＢＳＵ１１６は、（あるマーケティングキャンペーンに対して）糸口 リストを生成しかつ糸口記録を抽出するために、（糸口市場１６６内に記憶され た）クライアントデータの部分集合を、ＧＵＩ１６０とプロセス１６２，１６４ とを通して生成する。 要約すると、キャンペーン管理プロセス１６２は（ＢＳＵ１１６による）照会 および基準入力に基づいて、糸口限定フィルターを生成する。糸口限定フィルタ ープロセス１６４は、今度は、（糸口市場１６６を構成するならば）ＤＳＳ１０ ４から適切なデータを抽出するために、または、（糸口リストを構成するならば ）糸口市場から適切なデータを抽出するために、そのような（生成された）糸口 限定フィルターを履行する。糸口限定フィルタープロセスがデータベース／デー タ倉庫と相互作用する間、キャンペーン管理プロセス１６２は、ＧＵＩ１６０と 糸口限定フィルタープロセス１６４との間に、インターフェースを提供する。 フォーマッタープロセス１６８は、（所与のマーケティングキャンペーンに対 する糸口リストに基づいてＣＬＲ１０８およびＤＳＳ１０４から抽出された）ク ライアントデータを受信する。フォーマッタープロセス１６８は、（クライアン トを接客するために最後に使用されるべき）適切な糸口記録を生成するために、 糸口リスト内の各エントリーのクライアント識別子を、氏名および（もし、ダイ レクトメールキャンペーンならば）アドレスおよび（もし、テレマーケティング キャンペーンならば）電話番号と照合する。フォーマッタープロセス１６８は、 クライアント識別子に対する氏名とアドレスと電話番号との割当を、ＤＳＳ１０ ４を介して、ＣＡＲＭＡ１０２から取得する。図３を参照すると、ＤＳＳ１０４ は、（以下に説明される）処理中データ記憶装置を具備する。該記憶装置は、Ｃ ＡＲＭＡ１０２からこの情報を抽出し、かつ、該情報をＣＯＮＩ１０６へ送る。 フォーマッタープロセス１６８は、結果として得られた糸口を糸口記録へフォ ーマットし、かつ、（各糸口記録が分配されるべき特定のＴＭ／ＤＭセンタ１１ ８の識別子とアドレスとを具備する）分配記録を導く。この情報は、糸口目録管 理プロセス１６７によって提供される。この例示的な実施形態では、フォーマッ タープロセス１６８は、テーブル駆動され、故に、（テンプレートに類似した） 定義ファイルを使用する。そのような定義ファイルは、ＴＭ／ＤＭセンタ１１８ におけるエージェントへの表示に対する（フォーマッタープロセス１６８によっ て検索された）データの位置を指定する。例えば、定義ファイルは、「コラム１ は電話番号を具備し、コラム２は氏名を具備する」等ということを指定できる。 テーブル駆動されることによって、もし、所与の糸口記録フォーマットが変更さ れるならば、フォーマッタープロセス１６８は、「基礎コードが変更される」と いうことを要求しない。代わりに、定義ファイルだけは、ＤＳＳ１０４から抽出 されたデータがＴＭ／ＤＭセンタ１１８において（エージェントへ）表示される 方法を変更するために、変更されることを必要とする。 ＴＭ／ＤＭセンタ１１８は、フォーマットされた糸口記録を、フォーマッター プロセス１６８から受信する。そして、ＴＭ／ＤＭセンタ１１８におけるエージ ェントは、そのような記録において識別されるクライアントと接客し、かつ、そ のような接客の結果を記録する。 接客管理プロセス１６９は、接客の結果を、ＴＭ／ＤＭセンタ１１８から受信 する。例示的な実施形態において、そのような接客の結果は、ある予め決定され たコードからなる（または、具備する）。そのようなコードは、「クライアント が抑制であるべきか否か」ということと、「クライアントが再び接客されるべき であるか否か」ということと、「いつ、どのような変更が、クライアントのプロ フィールになされるべきか」ということとを示す。故に、接客管理プロセス１６ ９は、（もし必要ならば）糸口を伴ったフォローアップのアレンジや、記憶され たデータの更新などを行う。接客管理プロセス１６９は、コードおよび／または 情報を、記憶するために、ＤＳＳ１０４のデータ倉庫へ送る。その結果、接客管 理プロセス１６９は、マーケティングキャンペーンの結果に基づくフィードバッ クを提供する。接客管理プロセス１６９によって提供されるフィードバックは、 履歴情報をＣＯＮＩ１０６へ提供する。そのような履歴データは、「所与のマー ケティングキャンペーンがどの程度成功したのか」ということを判断するために 、ＣＯＮＩ１０６を介して、ＢＳＵ１１６によってアクセスされることができる 。そして、ＢＳＵ１１６は、（もし必要ならば）所与のマーケティングキャンペ ーンの成功を改善するために、該マーケティングキャンペーンを変更できる。 ＣＯＮＩ１０６は、共に審査中の出願”System And Method For Automated Le ad Generation In Client Contact Management For Sales And Marketing Platf orm”において、より詳細に説明される。該出願は、本出願と同じ日に出願され た。該出願は、本出願と共通の指定代理人に割り当てられる。該出願は、参照と して、本出願に明示的に組み込まれる。 ３．ＣＡＲＭＡ ＣＡＲＭＡ１０２は、多数の異なるタイプのコンピュータシステム上で実行さ れてもよい。図５は、（ＣＡＲＭＡ１０２を実行するために適切な）コンピュー タシステム２４０を図解するブロック図である。（マサチューセッツ、メイナー ドのデジタルイクイップメントコーポレーション製の）ＤＥＣアルファプロセッ サを使用する中級コンピュータが、ＣＡＲＭＡ１０２を実行するのに適切である 。コンピュータシステム４０は、（コンピュータシステムの動作を監視すること に対して責任を負う）中央処理ユニット（ＣＰＵ）２４２を具備する。コンピュ ータシステム２４０は、（ビデオディスプレイ２４４および入力デバイス２４６ のような）多数の周辺デバイスを具備してもよい。コンピュータシステム２４０ は、また、（コンピュータシステムをローカルエリアネットワークとインターフ ェースするための）ネットワークアダプタ２４８を具備してもよい。従来の電話 線を通した遠隔コンピューティング資源との通信を用意にするために、モデム２ ５０がコンピュータシステム２４０内に提供されてもよい。コンピュータシステ ム２４０は、多数の異なるタイプの記憶装置２５２を具備してもよい。記憶装置 ２５２は、主要記憶装置と第２記憶装置とを具備する。記憶装置２５２は、クラ イアントデータベース２５６と（ＣＡＲＭＡのための）プログラムコード２５４ のコピーとを保持する。当業者は、「コンピュータシステム２４０は、マイクロ プロセッサシステムまたは分散システムのどちらであってもよい」ということを 認識する。本発明は、「シングルプロセッサシステム上に実現される」というこ とに限定されない。 クライアントデータベース２５６は、図６に描かれるような論理的アーキテク チャを有する。クライアントデータベース２５６は、多数の異なるテーブルを含 む。各テーブルは、クライアントに関する種々の情報を含む。各クライアントは 、唯一無二のクライアント識別子（クライアントＩＤ）を割り当てられる。この クライアント識別子は、クライアントに関する異なるテーブル内に保持された情 報をリンクする。（クライアントに対する）リンクされた記録は、集められ、該 クライアントに対するクライアントプロフィールを構成する。クライアントデー タベース２５６内の３つの主要なテーブルは、クライアントテーブル２６０とア ドレステーブル２８２と国内電話テーブル２９０とである。クライアントテーブ ル２６０内の各記録は、（クライアントＩＤと社会保障番号と氏名と職業のよう な）クライアントに関する情報を含む。アドレステーブル２８２は、クライアン トのアドレスに関する情報を保持し、一方、国内電話テーブル２９０は、クライ アントの電話番号および電話サービスに関する情報を保持する。 「クライアントテーブル２６０と国内電話テーブル２９０との間のみならず、 クライアントテーブル２６０とアドレステーブル２８２との間にも、１対多の関 係が存在する」ということが認識されるべきである。クライアントは、（該クラ イアントに関連して）複数のアドレスおよび複数の電話番号を有してもよい。各 々のアドレスは、クライアントアドレステーブル２８０内に個別の記録を有し、 かつ、各々の国内電話番号は、国内電話テーブル２９０内に個別の記録を有する 。クライアントテーブル２６０とアドレステーブル２８２とは、媒介テーブル（ クライアントアドレステーブル２８０）によってリンクされる。クライアントの 各アドレスは、クライアントアドレステーブル２８０内に記録を有する。クライ アントアドレステーブル２８０は、”cInt_idr”によって、クライアントテーブ ル２６０へリンクされている。各アドレスは、クライアントアドレステーブル２ ８０内に、ステータスインジケーター（”adr_stat”）を有する。アドレスステ ータスインジケーターは、「アクティブ」または「廃用」の値を有してもよい。 このステータスインジケーターは、クライアントがアドレス間を移動するときに 、クライアントを追跡するのに有用である。アドレス識別子（”adr_id”）は、 記録およびクライアントアドレステーブルを（アドレステーブル２８２内の）ア ドレス記録へリンクするために、クライアントアドレステーブル内に保持される 。 クライアント電話テーブル２７６は、クライアントテーブル２６０と国内電話 テーブル２９０との間において、媒介テーブルとして作用する。各電話番号また はクライアントに対して、クライアント電話テーブル２７６は、３つの欄（”np a”と”nxx”と”line”）内に電話番号を具備する。 抑制テーブルもまた、媒介テーブル（例えば、クライアントアドレステーブル ２８０およびクライアント電話テーブル２７６）を提供される。特に、クライア ントアドレスSUPPテーブル２８４は、クライアントアドレスに関する抑制情報を 保持する。同様に、クライアント電話SUPPテーブル２８８は、クライアント電話 番号に関する抑制情報を保持する。電話SUPPテーブル２９２は、国内電話テーブ ル２９０内に記憶された記録に関する抑制情報を保持する。同様に、アドレスSU PPテーブル２８８は、アドレステーブル２８２内に記憶された記録に対する抑制 情報を保持する。世帯エンハンスメント情報は、アドレスエンハンスメントテー ブル２８６内に記憶される。クライアントに対するエンハンスメント情報は、ク ライアントエンハンスメントテーブル２７４内に記憶されてもよい。 クライアントアカウントテーブル２６６は、クライアントに対する内部アカウ ント番号を追跡する。クライアントテーブル２６０とクライアントアカウントテ ーブル２６６との間には、１対多の関係が存在してもよい。言い換えると、複数 のクライアントに関する情報が、所与のクライアントに対して記憶されてもよい 。 クライアントメンバーテーブル２７０は、（提携クラブや類縁クラブや様々な 他のクラブにおける）クライアントのメンバーシップを追跡する。一例として、 エアラインフリークエントフライヤークラブや職業団体や自動車クラブやクレジ ットカードや旅行クラブやヘルスクラブ等が含まれる。クライアントメンバーテ ーブル２７０内の記録とクライアントテーブル２６０内の記録との間には関係が 存在してもよい。 クライアント管区詳細テーブル２７２は、サービスプロバイダに関する詳細検 査情報を保持する。該詳細検査情報は、例えば、クライアントの電話番号とアド レスと氏名であり、各ソースによって提供される。クライアントエンハンスメン トテーブル２７４は、クライアントに関するエンハンスメント情報を保持する。 クライアント言語テーブル２７８は、クライアントが話す（および／または、理 解する）自然言語に関する情報を保持する。一人のクライアントに対して、複数 のクライアント言語記録が提供されてもよい。クライアントリストテーブル２６ ２は、（クライアント識別子によって識別されるクライアントをリストテーブル ２６１内のリスト記録とリンクするための）媒介テーブルとして作用する。該リ ストテーブル２６１は、クライアントによって受信された全てのソース（リスト ）を定義する。 上述されたように、ＣＡＲＭＡ１０２は、複数のデータソースに対する入力デ ータを処理でき、かつ、それに応じて、クライアントデータベース２５６内のデ ータを更新できる。（新たな入力データを取り扱う）この処理が、図７および図 ８を参照して、以下に説明される。新たな入力データは、ロード処理において処 理される。最初に、未処理の入力データが、データプロバイダ１１０から、ＣＡ ＲＭＡ１０２で受信される（図８のステップ３２０）。上述されたように、デー タプロバイダは、外部および内部の両方であってもよく、かつ、様々な異なるタ イプの情報を提供してもよい。スケジューラー３００は、ＣＡＲＭＡ１０２によ って実行される処理の個々の段階を引き起こすことに対して責任を負っている。 スケジューラー３００は、データを受信すると、データロードプロセスを開始し かつ監視する。スケジューラーは、最初に、「フォーマッティングと（データの ）ウイルス予防とが、未処理入力データ上で実行される」ということを引き起こ す（図８のステップ３２２）。このフォーマッティングと（データの）ウイルス 予防とは、ステージロードプロセス３０２（図７）によって実行される。ステー ジロードプロセス３０２は、クライアントの氏名およびアドレスの標準化を実行 する。ステージロードプロセスは、「（氏名または社会保障番号または他の共通 識別子の形式における）クライアント識別子が有効であり、かつ、（郵送アドレ スのような）特定の情報が有効であり、かつ、該情報は適切なフォーマット内に 存在する」ということを保証する。 本発明の好ましい実施形態において、ＣＡＲＭＡ１０２は、ポスタルソフト（ postalSoft）の実氏名（TrueName）３０４プロダクトとＡＣＥプロダクト３０５ とを具備する。マッピングメカニズム３０３は、「プロダクト３０４およびプロ ダクト３０５のうちのどちらが使用されるのか（または、データを入力するのか ）」ということを判断する。実氏名３０４は、データブロバイダ１１０からのデ ータ入力内の氏名／アドレス情報を、標準化しかつ構文解析しかつ収集しかつ転 換しかつ添付しかつ確認する。一般的に、ポスタルソフトは、全ての課金氏名お よびアドレス情報を、標準的な氏名およびアドレスデータベースアトリビュート へ構文解析する。ＡＣＥ３０５もまた、標準課金アドレス添付機能を実行する。 該機能は、例えば、最大９桁のジップコード（zip code）と伝送ルートと地理的 照合コードと（バーコードのための）チェックデジットとの識別および付加であ る。ストリートサフィックス値ユニット指定者もまた、実氏名によって標準化さ れる。実氏名３０４は、ファーストネームの参照リストを保持し、かつ、性別コ ートを各ファーストネーム（即ち、男性および女性）と関連付ける。 本発明の好ましい実施形態は、また、（ポスタルソフトプロダクト３０４を確 立する）多数のカスタム符号化エディットまたは変換３０６を具備する。例えば 、氏名情報は、常に、出力の始めに置かれる。無効な文字は、氏名において許可 されず、かつ、余分な空白は、氏名およびアドレスにおいて除去される。「の場 合」または「に注意」のような文字は削除される。ファーストネーム欄およびラ ストネーム欄の（繰り返される）氏名は削除される。無効な氏名は除去される。 冒涜的かつ反復の文字の除去を具備してもよい。もし、ウイルス予防スコアが（ 予め定義された）スレッショルド値より下ならば、入力の氏名構成要素は取り去 られる。 ステージロードプロセス３０２は、確認され標準化されたデータを、当座デー タ記憶装置３０８へ出力する。このことは、「データが最終ロードプロセス３１ ０へ送られる前に、ユーザーが、コンピュータシステム２４０を使用して、デー タを視認しかつ認可する」ということを可能にする。最終ロードプロセス３１０ は、データがクライアントデータベース２５６へ加えられる前に、追加のデータ 処理をいくつか実行する。 最終ロードプロセス３１０は、クライアント照合アルゴリズム３１２を適用す ることを具備する。これらのクライアント照合アルゴリズム３１２は、「（提供 される）クライアント識別情報とデータとが、（クライアントデータベース内） 既存のクライアントと一致するか否か」ということを判断するために、適用され る（図８のステップ３２４）。図９は、「クライアント照合ルールがどのように して適用されるのか」ということを（より詳細に）図解するフローチャートであ る。最初に、クライアントデータベース２５６内の記録と入力データ内に含まれ る情報とに対して、クリティカル照合基準が吟味される。多数の異なる基準のそ れそれに対する照合条件を示す値が割り当てられる（図９のステップ３３４）。 クリティカル照合基準は、社会保障番号照合（ＳＳＮ）基準を具備する。社会 保障番号照合基準に対する値は、”Ｙ”であってもよく、これは、「一致が存在 する」ということを示し、かつ、「入力データおよび（クライアントデータベー ス２５６内の）記録は、共に、住居社会保障欄を具備する」ということを示す。 該値は、また、”Ｎ”であってもよく、これは、「一致が存在しないが、入力デ ータおよびデータベース記録は、社会保障番号値を具備する」ということを示す 。最後に、該値は、”Ｂ”であってもよく、これは、「入力データまたはデータ ベース記録のうちの１つまたは両方は、社会保障番号値を具備しない」というこ とを示す。 ラストネームは、ラストネーム照合（ＬＮＭ）照合基準に対する値を決定する ために比較される。ＬＮＭ基準に対する値”Ｙ”は、厳密な一致を示す。該一致 は、空白や特殊文字と識別されたミススペルと（結婚している女性のための）ハ イフン付ラストネームとを除外する。値”Ｎ”は、一致しないことを示し、かつ 、「ラストネームが、入力データとデータベース記録との両方において提供され る」ということを示す。 ファーストネームは、ファーストネーム照合（ＦＮＭ）基準のための値を取得 する際に、比較される。値”Ｙ”は、厳密な一致を示す。該一致は、等価なニッ クネームと省略と（識別された）ミススペルとを含む。厳密な一致は、また、（ 等価なニックネームと省略とを含む）ファーストネームの最初の文字が一致する 位置で発見される。但し、それは、入力データ（または、データベース記録）が ファーストネームを（イニシャルとして）有する場合のみである。最後に、もし 、ファーストネームがニックネームテーブルエントリーと一致するならば、厳密 な一致が発見されることができる。値”Ｎ”は、「一致が存在しない」というこ とを示し、かつ、「ファーストネームは、入力データおよびデータベース記録の 両方において指定される」ということを示す。 ミドルネームは、ミドルネーム照合（ＭＮＭ）基準に対する値を生成するため に比較される。ＭＮＭ基準は、値”Ｙ”を有してもよい。値”Ｙ”は、厳密な一 致と等価なニックネームと等価な省略とを示す。値”Ｎ”は、「一致が存在しな い」ということを示し、かつ、「ミドルネームは、入力データおよびデータベー ス記録の両方において指定される」ということを示す。値”Ｂ”は、「データベ ース記録内の入力データのうちの１つまたは両方が、ミドルネームを伴って占有 されない」ということを示す。 性別は、性別（ＧＤＲ）照合基準において比較される。値”Ｎ”は、「入力デ ータおよびデータベース記録の両方において、男性または女性またはカンパニー ジェンダー（company gender）の間に、照合が発見されない」ということを示す 。値”Ａ”は、「入力データまたはデータベース記録が、あいまいな性別値を伴 って占有される」ということを示す。値”Ｍ”は、「入力データおよびデータベ ース記録の両方が、男性性別コードを伴って占有される」ということを示す。値 ”Ｆ”は、「入力データおよびデータベース記録の両方が、女性性別コードを伴 って占有される」ということを示す。値”Ｃ”は、「両方のソースが、カンパニ ージェンダーコードを伴って占有される」ということを示す。 クライアントのタイトルが、タイトル（ＴＴＬ）照合基準に対する値を生成す るために比較される。値”Ｙ”は、儀礼的タイトル上の厳密な一致、または、等 価なあいまい値の一致を示す。例えば、省略”Mrs.”は”Ms．”と一致する。値 ”Ｎ”は、「一致が存在しない」ということを示し、かつ、「入力データおよび データベース記録の両方が、儀礼的タイトルを伴って占有される」ということを 示す。値”Ｂ”は、「入力データまたはデータベース記録またはその両方が、儀 礼的タイトルを伴って占有されない」ということを示す。 ジップコード（zip code）は、ジップコード照合基準（ＺＩＰ）に対する値を 生成するために比較される。値”９”は、フル９デジットジップコードの厳密な 一致を示す。値”７”は、ジップコードの最初の７デジット上の一致を示す。値 ”５”は、ジップコードの最初の５デジット上の一致を示す。値”Ｎ”は、一致 しないことを示し、かつ、「入力データおよびデータベース記録の両方が、ジッ プコードを伴って占有される」ということを示す。 ストリート名およびストリートサフィックスは、ストリート名およびストリー トサフィックス（ＳＴＲ）照合基準において比較される。値”Ｙ”は、ストリー ト名およびストリートサフィックスの厳密な一致を示す。値”Ｎ”は、一致しな いことを示し、かつ、「入力データおよびデータベース記録の両方が占有される 」ということ、または、「入力データおよびデータベース記録のうちの１つが占 有されない」ということを示す。値”Ｂ”は、「入力データおよびデータベース 記録の両方が、ストリート名またはストリートサフィックスを伴って占有されな い」ということを示す。 アドレス番号またはＰ．Ｏ．ボックス番号は、番号（ＮＢＲ）照合基準に対す る値を生成するために比較される。値”Ｙ”は、厳密な一致を示す。値”Ｎ”は 、一致しないことを示し、かつ、「入力データおよびデータベース記録の両方が 、同じタイプの情報によって、占有される」ということを示す。 区画番号は、区画（ＡＰＴ）照合基準に対する値を生成するために比較される 。値”Ｙ”は、厳密な一致を示す。値”Ｎ”は、「一致が存在しない」というこ とを示し、かつ、「入力データおよびデータベース記録の両方が、区画番号明細 を含む」ということを示す。値”Ｂ”は、「入力データまたはデータベース記録 が、区画番号を伴って占有されない」ということを示す。 電話番号は、電話番号（ＰＨＮ）照合基準に対する値を生成するために比較さ れる。値”Ｙ”は、電話番号の厳密な一致を示す。値”Ｎ”は、「一致が存在し ない」ということを示し、かつ、「入力データおよびデータベース記録の両方が 、電話番号を含む」ということを示す。値”Ｂ”は、「入力データまたはデータ ベース記録のいずれも電話番号を含まない」ということを示す。 アカウント番号は、アカウント番号（ＡＣＣ）照合基準に対する値を生成する ために比較される。値”Ｙ”は、厳密な一致を示す。該一致では、入力データお よびデータベース記録の両方が、アカウント番号を伴って占有される。値”Ｎ” は、「入力データおよびデータベース記録がアカウント番号を含む」ということ を示し、かつ、「アカウント番号間において一致が存在しない」ということを示 す。値”Ｂ”は、「入力データおよびデータベース記録のうちの１つまたは両方 が、アカウント番号を伴って占有されない」ということを示す。 メンバーシップ番号は、メンバーシップ番号（ＭＥＭ）基準に対する値を生成 するために比較される。値”Ｙ”は、特定のメンバーシップ番号上での厳密な一 致を示す。値”Ｎ”は、「一致が存在しない」ということを示し、かつ、「入力 データおよびデータベース記録の両方が、同じタイプのメンバーシップ番号を伴 って占有される」ということを示す。値”Ｂ”は、「入力データおよびデータベ ース記録のうちの１つまたは両方が、メンバーシップ番号を伴って占有されない 」ということを示す。 クライアントＩＤ（client_id）は、クライアントＩＤ照合基準に対する値を 生成するために比較されてもよい。値”Ｙ”は、厳密な一致を示す。該一致では 、入力データおよびデータベース記録の両方が、クライアントＩＤを伴って占有 される。値”Ｎ”は、「一致が存在しない」ということを示し、かつ、「入力デ ータおよびデータベース記録の両方が、クライアントＩＤを伴って占有される」 ということを示す。値”Ｂ”は、「入力データおよびデータベース記録のうちの １つまたは両方か、クライアントＩＤを伴って占有されない」ということを示す 。 「これらの照合基準の各々は、また、値”−”を呈する」ということが注意さ れるべきである。値”−”は、「一致が存在するか否かの判断が、該基準に依存 しない」ということを示す。 「一致が存在するか否か」ということを判断するために、（照合ルールテーブ ルを使用する）照合ルールを適用することによって、該値は利用される（図９の ステップ３３６）。照合ルールの一例は以下の通りである。 １ ２ ３ ４ ５ ６ ７ ８ ９ 10 11 12 13 14 シナリオ 結果− ルール − Ｙ Ｙ Ｙ Ｍ Ｂ Ｙ Ｙ Ｙ Ｙ − − − − 00113 一致 − Ｙ Ｙ Ｙ Ｍ Ｂ Ｙ Ｙ Ｙ Ｎ − − − − 00114 一致 − Ｙ Ｙ Ｙ Ｍ Ｂ Ｙ Ｙ Ｙ Ｂ − − − − 00115 一致 − Ｙ Ｙ Ｙ Ｍ Ｂ Ｙ Ｙ Ｎ Ｙ − − − − 00116 一致 − Ｙ Ｙ Ｙ Ｍ Ｂ Ｙ Ｙ Ｎ Ｂ − − − − 00118 一致 １＝ＳＳＮ ２＝ＬＮＭ ３＝ＦＮＭ ４＝ＭＮＭ ５＝ＧＤＲ ６＝ＴＴＬ ７＝ＺＩＰ ８＝ＳＴＲ ９＝ＮＢＲ 10＝ＡＰＴ 11＝ＰＨＮ 12＝ＡＣＣ 13＝ＭＥＭ 14＝ＣＬＮ 照合ルールテーブル内の各横列は、シナリオおよび結果を具備する（「シナリ オ」および「結果−ルール」とラベルが付けられた縦列に注目）。各横列は、別 々のルールとみなされてもよい。他の各縦列は、上述された１４個の照合基準の 内の１つに対して、個々の値を指定する（上記凡例を参照）。もし、基準が、縦 列において指定される値を有するならば、ルールが満たされ、かつ、該ルールの 結果が適用される。例えば、シナリオ１１３は、「もし、ラストネームが一致し （縦列２が”Ｙ”）、かつ、ファーストネームが一致し（縦列３が”Ｙ”）、か つ、ミドルネームが一致し（縦列４が”Ｙ”）、かつ、入力データおよびデータ ベース記録の両方が男性性別コードを伴って占有され（縦列５が”Ｍ”）、かつ 、１または両方のソースが儀礼的タイトルを伴って占有されず（縦列６が”Ｂ” ）、かつ、ジップコードが一致し（縦列７が”Ｙ”）、かつ、ストリート名およ びストリート名サフィックスが一致し（縦列８が”Ｙ”）、かつ、番号が一致し （縦列９が”Ｙ”）、かつ、区画が一致する（縦列１０が”Ｙ”）ならば、入力 データとデータベース記録との一致が判断される」ということを指定する。結果 として、図８のステップ３２６では、照合ルールテーブルを適用することによっ て、「一致するか否か」という判断がなされる。 「照合ルールテーブル内には（図１０に示されるカテゴリ３３９へ分類される ことができる）多数の異なる組み合わせまたはシナリオが存在する」ということ が認識されるべきである。特に、照合ルールテーブルは、以下の組み合わせ、即 ち、氏名とアドレスとの組み合わせ３４０と、氏名と電話との組み合わせ３４２ と、氏名と社会保障番号との組み合わせ３４４と、氏名とアカウントとの組み合 わせ３４６と、氏名とメンバーシップ番号との組み合わせ３４８と、氏名とクラ イアントＩＤとの組み合わせ３５０と、アドレスと電話との組み合わせ３５２と 、アドレスとアカウントとの組み合わせ３５４と、アドレスとメンバーシップ番 号との組み合わせ３５６と、電話とアカウントとの組み合わせ３５８と、電話と メンバーシップ番号との組み合わせ３６０と、アカウントとメンバーシップ番号 との組み合わせ３６２とを具備する。 ステップ３２６において、もし、「入力データと（クライアントプロフィール を保持する）全てのデータベース記録との間において一致が存在しない」という ことが判断されるならば、新たな記録が生成されてもよく、かつ、新たなクライ アント識別子が、クライアントに割り当てられる（図８のステップ３２８）。該 新たな記録は、ステージロードプロセス３０２によって処理された入力データ内 に提供されるデータで満たされる。 それとは反対に、もし、一致が発見されるならば、（入力データ内に含まれる ）クライアント情報とクライアントデータベース記録との間におけるコンフリク トを解決する方法を判断するために、オーバーレイプロセスが適用される（図８ のステップ３３０）。一般的に、以下により詳細に説明されるように、オーバー レイプロセスは、コンフリクトを解決する方法を判断するために、オーバーレイ ルールと解決ルールとを適用する。それに応じて、データは、クライアントデー タベース２５６内で更新される（図８のステップ３３２）。このオーバーレイプ ロセスは、図７において、オーバーレイ３１４として描かれ、かつ、（クライア ントデータベース２５６へ送られる）データを結果として生じる。 図１１は、（ＣＡＲＭＡ１０２によって提供される）様々な種類のオーバーレ イルール３６４を示す。クライアントオーバーレイルール３６６が存在する。ク ライアントオーバーレイルールの一般的なアプローチでは、「一致が存在する」 という表示を受信した後に、もし、入力データがより完全な情報を有するならば 、クライアントデータベース２５６内の氏名欄は、更新のみ行われる。クライア ントオーバーレイルールは、（クライアントテーブル２６０内の欄へ送られる） 特定のルールを具備する。アクティブアドレスオーバーレイルール３６８は、「 クライアントデータベース２５６内のアクティブアドレス情報が、（一致する） 入力情報に関して、どのようにオーバーレイされるべきか」ということを指定す る。国際アドレスオーバーレイルール３７０は、「国際アドレス情報が、どのよ うにしてオーバーレイされるべきか」ということを指定する。電話番号オーバー レイルール３７２は、「電話番号情報が、どのようにしてオーバーレイされるべ きか」ということを指定する。エンハンスメントオーバーレイルール３７４は、 「エンハンスメントが、どのようにしてオーバーレイされるべきか」ということ を指定する。リスト特定データベーステーブルオーバーレイルールは、「どのデ ータベーステーブルが、特定のロードフィード（load feed）に対して更新され ることを可能にされるか」ということを指定する。最後に、クライアント＿プロ バイダ＿詳細オーバーレイルールは、「データベース２５６内のクライアントプ ロバイダ情報がどのようにしてオーバーレイされるべきか」ということを示す。 一旦、クライアントデータベース２５６が更新されると、該変更は、クライア ントデータベース複製プロセス３１６によって複製されてもよく、かつ、（ＤＳ Ｓ１０４によって管理される処理中データ記憶装置３８４のための）データ収納 設備３８０へ送られてもよい。変更は、変更データキャプチャプロセス３１８に よってキャプチャされる。変更データキャプチャプロセス３１８は、該変更を、 ＤＳＳ１０４のデータ倉庫８２３のデータ収納設備３８０へ送る。 故に、ＣＡＲＭＡ１０２は、（クライアントプロフィール管理のために）統合 されたシステムを提供する。該クライアントプロフィール管理は、唯一無二の特 徴を多数提供する。ＣＡＲＭＡは、個々のクライアントを、電話番号やアドレス よりも、むしろ、個人として追跡する。それによって、電話番号またはアドレス を共有する複数のクライアントが追跡される。ＣＡＲＭＡ１０２は、（クライア ント毎に複数のアドレス、および、クライアント毎に複数の電話番号を含む）多 数の関係を保持する。このことは、複数の電話番号またはアドレスを有するクラ イアントの完全な追跡を容易にする。ＣＡＲＭＡ１０２は、クライアントの追跡 を継続的に進行し、かつ、クライアントプロフィールへの変更を直ちに容易にす る。ＣＡＲＭＡ１０２は、（全てのフォーマットにおける殆ど全てのタイプの入 力データを受け入れかつ使用するための）プロセッシング資源を具備する。更に 、ＣＡＲＭＡは、クライアントプロフィールの複製を回避するために、効果的な クライアント照合を実行する。 ４．データフロー 図１２は、ＳａＭＳインフラストラクチャ１００におけるデータフローを図解 する。図１２におけるプロセスステップおよびデータフローは、以下の（および 、図１２内の）参照番号１〜２４によって識別される。以下に示されるパラグラ フは、番号１〜２４によって示される。該番号１〜２４は、図１２に示されるデ ータフローに対応する。関連する位置または特定のハードウエアまたはプロセス もまた、データフロー１〜２４に関して説明される。 １． データプロバイダ１１０からのクライアント情報は、ＣＡＲＭＡ１０２ によって収集される。上述されたように、データプロバイダ１１０からのクライ アント情報は、（シンジケートライフスタイル情報のような）外部データのみな らず、（会社の顧客取引や課金システム記録やクライアント接客記録等のような ）内部データソースをも具備できる。ＣＡＲＭＡ１０２は、実際の如何なるフォ ーマット内のデータおよび如何なるソースからのデータをも受け入れるように設 計されている。ＣＡＲＭＡ１０２は、（該ＣＡＲＭＡ１０２のクライアントデー タベース内の）クライアントプロフィールを更新するために、入力クライアント 情報を使用する。 ２． ＣＡＲＭＡ１０２におけるクライアントプロフィールへの全ての変更（ 一般的には、データプロバイダ１１０による新たなクライアント情報入力の結果 ）は、キャプチャされかつＤＳＳ１０４へ送られる。（氏名およびアドレスのよ うな）特定のクライアント識別データは保留される。代わりに、ＣＡＲＭＡ１０ ２は、包括クライアント識別子を、ＤＳＳ１０４へ提供する。ＤＳＳ１０４は、 （ＣＡＲＭＡ１０２または他のいずれかのデータプロバイダからの）全ての入力 データを収集しかつフォーマットするために、データ収納プロセス３８０を使用 する。データ収納プロセス３８０は、データプロバイダ１１０から収集されたデ ータを識別しかつ抽出しかつ変換しかつ引き出しかつ集めかつ統合しかつ完全に チェックするためのプロセスを具備する。 識別プロセスは、「収集されたデータに対する最終的なソースを識別すること のみならず、（収集されたデータ内の）どのデータエレメントが下流のプロセス に対して必要とされているのか」ということを識別する（ここで、最初の既知の ソースは必ずしも必要ではない）。抽出プロセスは、データプロバイダ１１０か ら、適切なデータをコピーする。変換プロセスは、同じデータがデータプロバイ ダ１１０から受信されると、（該データがラベルを付けられる）様々な方法を調 和させる。例えば、クライアントの性別に対する値は、あるデータプロバイダ（ または、システム）の下では”ｍ”または”ｆ”の形式であってもよく、一方、 他のデータプロバイダからの値は”１”または”２”の形式であってもよい。変 換プロセスは、代わりに、（”male”および”female”のような）新たな値を割 り当ててもよい。 演繹プロセスは、あるデータを、他の値に変換する。例えば、クライアントに 関するデータの２または３以上の欄は、スコア（例えば、２つのデジットスコア によって組み合わされかつ表示されるクライアントのアドレスおよび収入）へ変 換されてもよい。集合プロセスは、データを、１組の処理または１組の（個々の ）クライアントの端から端まで、結合しかつ要約する。例えば、クライアントに よる総月間長距離消費は、該クライアントに対する平均月間消費値を提供するた めに、１年間を通して集められる。統合プロセスは、データを、適切なクライア ント番号と照合し、かつ、データのそれそれに対するタイムフレームを確認する 。完全性チェックプロセスは、「データ倉庫内に記憶されるデータが、適切な形 式／フォーマットで存在する」ということを保証する。 ３． データ収納プロセス３８０は、様々なデータプロバイダ１１０から、情 報を収集する。該情報に対しては、特定のクライアント識別子が必要とされない 。この情報は、一般的なトレンドを識別するために、使用されることができる。 ４． データ収納プロセス３８０は、（データ収納プロセス３８０がデータ倉 庫３８２内に収集する）全てのデータを記憶する。データ倉庫３８２は、該デー タ倉庫３８２を利用するビジネスの必要性に適合するために、様々な体系に分割 されかつ構成される。（遠距離通信会社のような）典型的なビジネスに対しては 、データ倉庫３８２は、莫大な量（おそらく、数テラバイト）のデータを記憶で きなくてはならない。データ倉庫３８２は、好ましくは、（「１００以上の」Ｉ ＢＭ ＳＰ２プロセッサのような）大規模並列処理（ＭＰＰ）プラットフォーム を使用する。（インフォーミックスコーポレーションによって提供されるような ）拡縮可能データベース管理システムが、好ましくは使用される。 ５．および６． データ出力プロセス３８６は、データ倉庫３８２から、特定 のデータを抽出し、かつ、このデータを、データ市場３８８内に配置する。デー タ市場３８８は、（データ倉庫３８０からのデータの部分集合を収容する）より 小さなデータベースであり、かつ、データ倉庫内に記憶されるデータへの（素早 くかつ簡単な）アクセスを容易にするために使用される。データ市場３８８は、 それぞれ、好ましくは、シンメトリカルな並列プロセッサ（ＳＭＰ）を使用する 。各データ市場３８８は、ＤＳＳ１０４の個々の顧客またはユーザーに対してセ ットアップされる。例えば、あるデータ市場３８８は、居住マーケティングＢＳ Ｕ１１６に対して確立されることができ、かつ、他のデータ市場は、スモールビ ジネスグループＢＳＵ１１６に対して確立されることができる。 （ＢＳＵ１１６のような）ＤＳＳ１０４のユーザーは、「該ユーザーは、どの データを、データ倉庫３８２から、該ユーザーのデータ市場３８８内に置きたい のか」ということと、「いつ置きたいのか」ということとを、データ出力プロセ ス３８６において指定する。以下に説明されるように、ＢＳＵ１１６は、そのよ うな基準を、ＤＳＳユーザーインターフェースプロセス３９０を介して指定する 。そして、データ出力プロセス３８６は、ユーザーの指定された基準に基づいて 、データ倉庫３８２から、データを周期的に抽出し、かつ、このデータを、ユー ザーのデータ市場３８８内に配置する。要約すると、データ出力プロセス３８６ は、データ収納プロセス３８０に類似したプロセスで、データを、中央データ倉 庫３８２から、部門別データ市場３８８へ移動させる（例えば、ユーザーは、要 求されたエレメントを選択でき、かつ、「データがデータ市場に記憶される前に 、変換が該データに適用される」ということを要求できる。 ７．および８． ＤＳＳユーザーインターフェースプロセス３９０は、データ 市場３８８内のデータへのアクセスと（該データの）分析とを提供するツールで ある。（ＢＳＵ１１６のような）ユーザーは、該ユーザーのデータ市場内のデー タへの照会を実行するために、（ＣＯＮＩ１０６に対して上述されたプロセスに 類似する）照会プロセスに基づいて、ＤＳＳユーザーインターフェースプロセス ３９０を使用する。例えば、データ出力プロセス３８６は、（合衆国から外国へ 最近移動した全てのクライアントを示す）データを、データ倉庫３８２から抽出 してもよく、かつ、このデータを、ＢＳＵ１１６に対するデータ市場３８８の内 の１つに配置してもよい。そして、ＢＳＵ１１６は、（カリフォルニアから日本 へ移動し、かつ、他の長距離会社を選択した）これら全てのクライアントのリス トを（このデータに基づいて）取得するために、ＤＳＳユーザーインターフェー スプロセス３９０を使用する。 一般的に、「如何なるタイプのマーケティングキャンペーンが成功することが できるか」ということを判断するために、より複雑な分析方法が使用される。Ｂ ＳＵ１１６は、（マーケティング戦略へ変換されることができる）重大なパター ンおよび関係を発見するために、該ＢＳＵのデータ市場３８８を調べる。マーケ ティング戦略を発展させるために、かつ、履行するマーケティングキャンペーン の種類を（該戦略に基づいて）判断するために、ＢＳＵ１１６は、ＤＳＳユーザ ーインターフェースプロセス３９０を使用して、照会を定式化し、かつ、（該Ｂ ＳＵ１１６のデータ市場３８８内のデータの）必要な分析を実行する。データ倉 庫３８２内のデータに対する照会は、ＳＱＬまたは他の照会言語を使用して行わ れる。 ＢＳＵ１１６は、好ましくは、（サンマイクロシステムズのＳＣ２０００／Ｓ ＰＡＲＣ２０システムのような）ミニコンピュータまたはワークステーションを 具備する。そのようなマイクロコンピュータは、好ましくは、ＵＮＩＸオペレー ティングシステムの下で動作し、かつ、インフォーミックスによって提供される ようなデータベース管理システムを実行する。（ＳａＭＳインフラストラクチャ １００内の他のエレメントのみならず）ミニコンピュータもまた、高帯域幅接続 を使用して結合される。例えば、ＢＳＵ１１６のミニコンピュータは、好ましく は、光ファイバ分配データインターフェース（ＦＤＤＩ）ローカルエリアネット ワーク接続を使用して、ＤＳＳ１０４およびＣＯＮＩ１０６へ結合される。ミニ コンピュータは、好ましくは、ＯＤＢＣを使用して、インフラストラクチャ１０ ０へ通信する。 例示的な実施形態において、ＢＳＵ１１６は、ＤＳＳ１０４および／またはＣ ＯＮＩ１０６上のハイパーテキストマークアップランゲージ（ＨＴＭＬ）アプリ ケーションにアクセスするために、ワールドワイドウェブブラウザを使用する。 ＨＴＭＬアプリケーションは、ここで説明されるように、（ＢＳＵ１１６への） ＧＵＩ環境下において、データ視認のメニューおよび他の画面を提供する。そし て、ＢＳＵ１１６は、イントラネットまたはインターネットを介して、インフラ ストラクチャ１００の各部にアクセスする。 ９． 一旦、ＢＳＵ１１６が、データを分析し、かつ、マーケティング戦略を 決定すると、該ＢＳＵ１１６は、その戦略を（特定のクライアントセグメントに 対して狙いを付けられたマーケティングキャンペーンとして）履行するために、 ＣＯＮＩ１０６を使用する。（ＣＯＮＩ１０６内の）キャンペーンマーケティン グプロセス１６２およびＧＵＩ１６０は、「ＢＳＵ１１６が、該ＢＳＵ１１６の マーケティングキャンペーンを、特定の基準として詳述する」という能力を提供 する。 １０． キャンペーン管理プロセス１６２への（ＧＵＩ１６０を通した）デー タ入力は、マーケティングキャンペーンの下で、キャンペーン管理プロセスによ って、糸口限定フィルターへ変換される。そして、糸口限定フィルターは、糸口 限定フィルタープロセス１６４へ入力される。糸口限定フィルタープロセス１６ ４は、ＤＳＳ１０４のデータ出力プロセス３８６とＣＯＮＩ１０６との間におけ るインターフェースである。糸口限定フィルターは、マーケティングキャンペー ンに含まれるために（クライアントが）満たす必要のある基準を指定する。 １１． 糸口限定フィルタープロセス１６４は、ＢＳＵ１１６のマーケティン グキャンペーンを（糸口限定フィルターの下で）示す基準に基づいて、データ倉 庫３８２からデータを抽出する。他に、糸口限定フィルタープロセス１６４は、 糸口市場１６６内に記憶されたデータを抽出するために、糸口限定フィルターを 適用する。 １２． 全ての糸口限定フィルター基準を満たすクライアント記録が、（糸口 記録に関連する）糸口市場１６６内に配置される。糸口市場１６６は、ＣＯＮＩ １０６データ市場ハウジングクライアント記録、または、特定のマーケティング キャンペーンに対する糸口記録である。糸口記録に基づいて、フォーマットされ た糸口記録が、（ここで説明されるように）生成される。多数の糸口市場１６６ が存在してもよいが、１人のクライアントの１つの記録は、好ましくは、該糸口 市場１６６のうちの１つのみに記憶される。 １３． 糸口目録管理プロセス１６４は、（糸口限定フィルターによって選択 された）糸口記録に基づいて、糸口リストを生成する。加えて、糸口目録管理プ ロセス１６４は、ＢＳＵ１１６からのデータ入力に基づく指示の下で、糸口分配 記録を生成する。該糸口分配記録は、電話または郵送に対して利用可能とされる 糸口記録の数を指定したり、または、各糸口記録を受信するＴＭ／ＤＭセンタ１ １８を指定したり、または、各ＴＭ／ＤＭセンタに割り当てる糸口記録の全体数 を指定したりする。ＢＳＵ１１６は、エージェントの技能状態や地形や利用可能 な資源などに基づいて糸口が送られる場所を指定するために、糸口目録管理プロ セス１６４を使用でき、それによって、「ＴＭ／ＤＭセンタ１１８が該資源をよ りよく管理する」ということを可能にする。糸口目録管理プロセス１６４は、ま た、「各クライアントは、全ての糸口市場１６６から一度だけ抽出される」とい うことを保証し、このことは「クライアントは様々な糸口リスト内に重複しない 」ということを保証する。 １４． 糸口目録管理プロセス１６４は、糸口リストと（関連する）糸口記録 および糸口分配記録とを、ＣＬＲ１０８内での記憶のために、供給する。ＣＬＲ １０８は、マーケティングキャンペーンを通じて、各クライアントに対する糸口 記録を管理する。該糸口記録は、（ここで説明される）フィードバックデータフ ローの下における先の接客と接客の結果とを含む。糸口目録管理プロセス１６７ は、「接客は、同じクライアントに対して頻繁には行われない」ということを保 証するために、ＴＭ／ＤＭセンタ１１８へ最近提供された（クライアントに関す る）糸口を追跡する。そして、該追跡に応じて、ＣＬＲ１０８内の糸口記録を更 新する。例えば、もし、特定のクライアントに関する糸口記録が（ある夜に）第 １ＴＭ／ＤＭセンタ１１８へ送られ、かつ、同じクライアントに関する他の糸口 記録が（次の夜に）糸口目録管理プロセス１６７からＣＬＲ１０８へ提供される ならば、ＣＬＲ１０８内の糸口記録は、「これは、同じクライアントに対する（ ２夜における）２番目の糸口記録である」ということを（２番目の糸口記録に基 づいて）示すか、または、指示は、この糸口を、他のＴＭ／ＤＭセンタ１１８へ 送らない。 １５． ＤＳＳデータ収納プロセス３８０は、（氏名およびアドレスまたは電 話番号のような）クライアント識別子に関する（または、割り当てられた）特定 のデータの供給を、ＣＡＲＭＡ１０２から収集する。 １６． この特定のデータは、処理中データ記憶装置（ＯＤＳ）３８４内に置 かれる。ＯＤＳ３８４は、データ倉庫３８２に類似しているが、一般的により非 常に小さい。ＯＤＳ３８４の目的は、データを他のプロセス（または、システム ）へ分配するために、データを一時的に記憶することである。 １７．および１８． フォーマッタープロセス１６８よって要求されると、デ ータ出力プロセス３８６は、糸口記録内のクライアント識別子に割り当てられた （氏名およびアドレスおよび電話番号のような）特定のデータを、ＯＤＳ３８４ から抽出し、かつ、このデータをフォーマッタープロセスへ提供する。フォーマ ッタープロセス１６８は、氏名および電話番号および（可能ならば）郵送アドレ スを（糸口目録管理プロセス１６４によって提供された）各クライアント識別子 へ割り当てるために、かつ、フォーマットされた糸口記録を生成するために、こ のデータを使用する。 １９． フォーマッタープロセス１６８は、糸口リストに関連する糸口記録を ＣＬＲ１０８から検索する。そして、（データ出力プロセス３８６によって提供 される）クライアントデータを使用して、フォーマットされた糸口記録を構成す る。フォーマットされた糸口記録は、以下のデータ、即ち、クライアント氏名と 電話番号とアドレスと接客履歴とＴＭ／ＤＭセンタ１１８割当と（マーケティン グキャンペーンに関する）他の情報との内のいくつか（または、全て）を具備し てもよい。フォーマッタープロセス１６８は、（糸口目録管理プロセス１６４に よって受信される）クライアント識別子を（ＣＡＲＭＡ１０２からの）氏名およ び電話番号と照合することによって、糸口記録をフォーマットする。 ２０． フォーマッター１６８は、フォーマットされた糸口記録を、糸口分配 リストに基づいて、適切なＴＭ／ＤＭセンタ１１８へ送る。ＴＭＤＭセンタ１１ ８は、そのような糸口記録を引き入れ、かつ、クライアントと接客し、かつ、（ 長距離サービスまたは製品を提供するような）マーケティングキャンペーンを行 う。 ２１． 各クライアント接客の結果は、ＴＭ／ＤＭセンタ１１８において、局 所的に記録される。 ２２． 各クライアント接客の結果は、ＴＭ／ＤＭセンタ１１８から、（ＣＯ ＮＩ１０６内の）接客管理プロセス１６９によって抽出される（または、該プロ セス１６９へ送られる）。接客管理プロセス１６９は、フォローアップ糸口をア レンジすることができ、かつ、所与のキャンペーンの状態（または、結果）を報 告できる。接客管理プロセス１６９は、ＣＬＲ１０８内に記憶された糸口記録を 、自動的に更新してもよい。 ２３． 接客管理プロセス１６９は、クライアント接客の結果を、データ収納 プロセス３８０へ提供する。それによって、データ倉庫３８２は、これらの結果 を用いて、更新されることができる。そして、データ出力プロセス３８６は、（ データ市場１７５内の）対応するデータを更新する。このことは、（ＳａＭＳイ ンフラストラクチャ１００へ作られた）多数のフィードバックループのうちの他 のループを示す。上述されたように、ＢＳＵ１１６は、マーケティングキャンペ ーンを、定式化しかつ処理する。（該キャンペーンの下での）各クライアント接 客の結果は、データ倉庫３８２へ送られる。そして、ＢＳＵ１１６は、あるクラ イアントデータの抽出をデータ出力プロセス３８６へ指定することによって、キ ャンペーン全体の結果を抽出できかつ分析できる。これに基づいて、ＢＳＵ１１ ６は、他のキャンペーンを定式化してもよく、または、既存のキャンペーンを修 正してもよく、または、以前のキャンペーンへの予期されない応答を識別しても よい。 例えば、ＢＳＵ１１６は、長距離サービスを（あるＲＢＯＣの顧客に）販売す るために、キャンペーンを定式化してもよい。多くの顧客は、ＴＭ／ＤＭセンタ によって接客されると、ローカルサービスプロバイダを切り換えることに（好ん で）応答するかも知れない。これらの応答は、ＣＬＲ１０８内に記録され、かつ 、接客管理プロセス１６９によって抽出され、かつ、データ収納プロセス３８０ によって収集され、かつ、データ倉庫３８２内に記憶される。 そして、ＢＳＵ１１６は、（ＤＳＳユーザーインターフェースプロセス３９０ を介した）該ＢＳＵ１１６のキャンペーンの結果と先に更新されたデータ市場と を分析し、かつ、「それら同じ顧客へのローカルサービスマーケティングキャン ペーンが要求される」ということを判断する。 ＴＭ／ＤＭセンタ１１８は、また、ダイレクトメールキャンペーンを実行でき る。例えば、ＣＯＮＩ１０６は、「選択されたクライアントへパンフレットを郵 送し、２週間待ち、そして、これらのクライアントに電話する」ということを、 ＴＭ／ＤＭセンタ１１８に対して指示する。 ２４． クライアント接客の結果は、「クライアントは、再び電話されないこ と（「抑制」）を要求する」というものであるかも知れない。データフロー２２ に関して上述されたように、接客管理プロセス１６９は、該クライアントに対す る抑制を示すように、ＣＬＲ１０８内の糸口記録を更新する。そして、全ての抑 制の抽出が（データプロバイダとして）ＣＡＲＭＡ１０２へ送られる。ＣＡＲＭ Ａ１０２は、同様に、これらの抑制を、クライアント識別子のみによって、デー タ倉庫３８２へ送る。そして、糸口限定フィルタープロセス１６４は、抑制指標 を有する全てのクライアントを、将来のキャンペーンにおいて、取り除くことが できる。抑制は、また、（ＬＥＣ１２４のような）外部データソース１１４から 、ＣＡＲＭＡ１０２へ提供されることができる。 本発明が、本発明の好ましい実施形態を参照して説明されたが、当業者は、「 形態および詳細における様々な変更が、添付された請求範囲に定義されたような 本発明の（意図された）範囲からはずれることなく、行われてもよい」というこ とを認識する。Description: FIELD OF THE INVENTION The present invention relates generally to telecommunications systems, and more particularly to a strategic marketing system for telemarketing. BACKGROUND OF THE INVENTION Telemarketing direct mail and telemarketing direct sales have become increasingly widespread in recent years. Various businesses use marketing to sell their products and services. One of the goals of such marketing is to establish new customers in order to expand the business customer base. These businesses want to target potential customers (most likely to be solicited by marketing campaigns and customer service). Conventional systems identify potential customers for customer service by telephone number or address. Generally, a group of telephone numbers or addresses is placed on a customer service list, and a large-scale telephone campaign or email campaign or visit campaign is conducted. Unfortunately, such large campaigns are not very efficient because of the typically high rates of failure. In addition, such campaigns use large amounts of resources. In conventional systems, customer data (including telephone numbers and customer names) is typically stored in large, centralized databases. Some conventional telephone campaigns query a database for a customer based on the customer's telephone number (eg, an area code and / or a three digit local area code). In conventional telephone campaigns, new marketing strategies and campaigns (which query the database for specific criteria regarding telephone number records in the database) are formulated. Since the database is centralized and very large, such queries consume considerable processing time, and thus consume significant time. Furthermore, it is often difficult to effectively use the results of such queries in a given large telephone campaign. Further, marketing strategies and campaigns are limited to the type and organization of the data in the database. SUMMARY OF THE INVENTION According to a first aspect of the invention, an automated marketing system comprises a client profile management system (for managing client profiles). The client profile comprises information (about the client) for marketing reception. The automated marketing system also includes a data warehouse system (for storing data about the client). Finally, the automated marketing system includes a customer service infrastructure for interrogating a data warehouse to automatically generate clues for clients serving by telemarketers. The query causes the data in the data warehouse to be limited in order to ensure that "the generated clue is for a client with certain characteristics". According to another feature of the invention, a computer-implemented method is implemented in an automated marketing system (stored data about potential clients). A clue generator is provided for generating clues (based on stored client data) of potential clients serving by telemarketers. A clue generator is used to generate clues for the first marketing campaign. The result of contact with the generated clue is obtained. The results are then used to generate clues leading to generators for the second marketing campaign. According to an additional feature of the present invention, a method is implemented in an automated marketing system such that client information regarding potential clients for telemarketing service is provided for each client. Client information is queried to generate a clue list for telemarketing customers. Each clue comprises customer service information for the potential client that is associated with the potential client and satisfies the first set of characteristics. Then, the clue is sent to a telemarketer. BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the present invention are described below with reference to the following drawings. FIG. 1 is a block diagram illustrating a strategic marketing system (SaMS) infrastructure (suitable for implementing a preferred embodiment of the present invention). FIG. 2 is a block diagram of the customer service infrastructure (CONI). FIG. 3 is an exemplary data structure diagram of a clue record. FIG. 4 is an exemplary data structure diagram of a clue distribution record. FIG. 5 is a block diagram of a computer system (suitable for implementing CARMA). FIG. 6 illustrates the intelligent structure of a client database. FIG. 7 illustrates the data flow in CARMA. FIG. 8 is a flowchart illustrating the steps performed by CARMA to process data. FIG. 9 is a flowchart illustrating the steps performed by CARMA to apply the matching rules. FIG. 10 is a diagram illustrating rules of different categories (found in the CARMA matching rule table). FIG. 11 is a diagram illustrating different types of overlay rules (seen in CARMA). FIG. 12 is a data flow diagram illustrating the data flow for the SaMS infrastructure. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiment of the present invention provides a strategic marketing system (SaMS) (to provide complete marketing services to business clients). The preferred embodiment of the present invention applies particularly well to telemarketing. SaMS provides automated data collection, client management, inventory analysis, decision support, clue generation, campaign management, order fulfillment and preparation, customer tracking, and other strategic marketing services. SaMS provides automated feedback of client attendance results to update client profiles. Feedback is also used, in some cases, to generate new marketing clues, to formulate new marketing campaigns, and to limit future client engagement. Telemarketing strategies developed with SaMS are directed to individual clients (rather than phone numbers). The phone number constitutes a client property. SaMS includes a database for managing client profile information, and large amounts of information about clients may be received from many different sources. The data may be received in multiple formats and may be multiple different types of data. Information about clients is used to analyze strategic marketing trends and to establish people's (collective) profiles. Using these trends and profiles, enhanced marketing campaigns can be processed. The result is a customer clue that has a higher success rate and outstanding efficiency than conventional systems. 1. System overview FIG. 1 shows an exemplary information system architecture for SaMS 100. The various components of the SaMS infrastructure 100 cooperate and interact as shown in FIG. 1 to provide a number of targeted marketing functions (as described herein). The SaMS infrastructure 100 performs at least three functions (client management, information management, and customer service). "Client management" comprises the process of identifying, tracking and managing clients. “Client” includes both current customers and potential customers (or clues). Hence, many businesses have hundreds of millions of clients. Client management involves individually acquiring and managing descriptive behavior data about the client. A key component (for client management) in the SaMS infrastructure 100 is the Client Acquisition and Maintenance Architecture (CARMA) 102. CARMA 102 is preferably a software system that provides database and data processing (for client management). An exemplary embodiment of the CARMA 102 is described in more detail below. “Information management” is a process of collecting, storing, and managing data that reflects the entire client group and Trent. Information management provides decision support functions and tools (laying raw data in context for products and marketing strategies). Information management deals with descriptive behavioral data about generalized client populations. A key component for information management is the Decision Support System (DSS) 104. The DSS 104 consists of a large data warehouse and involves processes for collecting and storing and managing and distributing and analyzing data. In general, a "data house" is an integrated body of information not only for information extracted from outside the company, but for many departments within the company (ie, "business strategy units"). An exemplary embodiment of the DSS 104 is described below with reference to FIG. "Customer service" makes inferences based on data house queries and uses the inference results (to formulate marketing campaigns and generate clues). This process also tracks and manages all customer service (done with the client). The CONI 106 provides a customer service to the SaMS infrastructure 100. The CONI 106 is preferably a software system. The software system uses data extracted from the DSS 104 data warehouse. The data is extracted with a specific strategy (formulated by the company's business strategy unit) to generate clues. The CONI interfaces with a central clue store (CLR) to manage and track customer service or clues (as described below). Information about such customer service (done with the client) is fed back to the client management function of the SaMS infrastructure 100. As a result, the client management function, the information management function, and the customer service function (of the SaMS infrastructure 100) are a repetition of the following processing. That is, the information management function places the raw data in context to perform and make inferences and form strategies. A customer service function formulates and implements a marketing strategy based on the research, inferences, and strategies generated under the information management function. A client management function identifies and tracks each individual, collects descriptive behavioral data, and feeds back such data to the information management function. Various data providers 110 provide data to CARMA 102 and DSS 104. The data provider 110 has several sources of data input to the SaMS infrastructure 100 to provide information about the client. Data provider 110 comprises both an internal data source 112 and an external data source 114. One example of an internal data source 112 comprises a data supply (from a billing system, a customer order entry system, an order preparation system, a customer database, a marketing database, a customer service system, an account receivable system, and many other systems). Internal data source 112 may also include inputs from other components of SaMS infrastructure 100 (eg, CLR 108). An example of an external data source 114 comprises files of a telephone directory, a US post office directory, a credit company report, and a number of third-party data products (providing specific data about people). These third party data products may include information such as products purchased by people, places where people come and go, services used by people, and telephone survey results regarding people's interests and demands. External data sources 114 may also include passenger aircraft frequent use passenger programs, car club memberships, health club memberships, travel clubs, and magazine subscriptions. These data are used to help track the client through the client's membership and subscription (to other businesses). The CARMA 102 collects data from the data provider 110 for a particular client and uses the data (to update the client profile). The CARMA 102 then provides (but in a generalized form) any changes in the client data to the DSS 104. That is, rather than sending the name and address of a particular client to DSS 104, CARMA 102 sends information that reflects the general client profile. CARMA 102 sends a unique client identifier with the client profile change. Therefore, when a clue is generated based on the data in the DSS 104, the clue can be collated with a specific name, address, and telephone number. Generally, clients are identified under the SaMS infrastructure 100 based on the client identifier of the SaMS infrastructure 100. The client identifier is a (unique) alphanumeric code associated with each client. The client identifier is held in the CARMA 102 and the DSS 104. DSS 104 also collects data from data providers 110. The DSS 104 generally collects data about a group of clients, rather than data about a particular client. Such data could be based on the number of people traveling from one country to another, or the number of people who purchased both cars and home stereos in the same year, or the number of women who have a job and are members of political parties. May include numbers. The potential for data collection by the DSS 104 is very high and varies according to the business requirements of the users of the SaMS infrastructure 100. DSS 104 also collects data from CARMA 102 and other sources, as described below. DSS 104 enables "business strategy unit (BSU) 116 to access data stored in the BSU's data repository." BSU 116 can be a (company) subset responsible for formulating business, marketing, and sales strategies. For example, one BSU 116 may be responsible for international clients, while another BSU 116 may be responsible for domestic clients. Alternatively, BSU 116 may be company-wide (using SaMS infrastructure 100). A user or BSU 116 accesses data (stored within DSS 104) for various functions. The functions include data exploration, data mining, data drilling, predictive modeling, general queries, and result delivery. The data exploration feature helps "BSU 116 identify potentially valuable groups of data." The data exploration function helps BSU 116 find unexpected patterns (to guide marketing decisions). For example, a survey of the data market 388 (discussed below) finds that "80% of people with a revenue of $ 50,000 or more in the northeast use cellular services." The BSU 116 can then determine "Why do the revenue and geographic features lead to cellular usage?" Data exploration capabilities help identify and classify large segments of data. Data mining and data drilling functions limit these large segments of data to further identify and quantify business opportunities. Once a meaningful pattern has been established, it can be represented as a mathematical model. The mathematical model establishes an interrelationship between one feature (eg, income in excess of $ 50,000 and the Northeast US population) and another feature (eg, cellular users). Based on these models, BS U 116 can create a mailing list of candidates for cellular direct mail campaigns. The summary query function allows "BSU 116 to perform a simple query (via the DSS user interface process) of the data in the data market." For example, BSU 116 can query the data market for total sales in a given year. The send results function allows the DSS 104 to send data in multiple ways (such as formatted reports, 3D graphics, etc.). Each BSU performs a strategic query (using specific analytical tools) of the data in the DSS 104 data warehouse. Based on the results of these queries, BSU 116 formulates a marketing campaign. The BSU 116 then uses the CONI 106 to fulfill the selected marketing campaign. As described more fully below, the BSU 116 specifies to the CONI the criteria to use when extracting clue data from the DSS 104. The clue data is used to identify the client clue (which is the client to be targeted in the selected marketing campaign). A “clue” is generally a client that is a potential customer of the company. Each clue is identified by a corresponding unique client identifier (stored in DSS 104). The CONI 106 may then match these client identifiers to names and / or addresses and / or telephone numbers (obtained from the CARMA 102 via the in-process data collection / distribution process of the DSS 104) to provide clues or clue records. Generate This is explained below with reference to FIG. When the CONI 106 generates clue records, the CONI 106 places these records in the CLR 108. The CLR 108 is a database (smaller than the DSS 104 data repository) used to track clues and actions (run on clues). The CLR 108 stores both the clue record and the clue distribution record. Each clue record (stored in CLR 108) includes a column for the client identifier, telephone number, and address identifier number, and possibly a column for the previous customer service. FIG. 3 shows an exemplary (more detailed) clue record constructed under Informix, showing a number of generally self-explanatory columns. The CLR 108 preferably stores only one clue record per client. The CLR 108 also stores a clue distribution record. More than one clasp distribution record can be associated with each clasp record. FIG. 4 shows an exemplary (more detailed) clue distribution record constructed under inform mix, showing a number of generally self-explanatory columns. Each clue distribution record includes a column for identifying a specific TM / DM center 118, a number of records to be sent to each center, dates, priority codes, and the like. The clue record (generated by the CONI 106 and stored in the CLR 108) is distributed by the CONI to one or more telemarketing / direct mail centers (TM / DM centers) 118. The TM / DM center 118 includes a call center. The telemarketing agent executes client reception, client sale and client service from the call center via telephone. Often, a TM / DM center 118 is located within each "sales city" (where a marketing campaign is processed). However, the TM / DM center 118 can process marketing campaigns outside the city where the center is located. The TM / DM center 118 also includes a center from which direct mail campaigns are processed. Although the present invention is described below generally with respect to telemarketing campaigns (performed at TM / DM center 118), those skilled in the art will appreciate that "embodiments of the invention apply equally to direct mail campaigns. Is possible. " In addition, the invention is equally applicable to other ways of serving clients physically or electronically (such as via an email or Internet connection). The agent at the TM / DM center 118 stores a clue record (provided to the agent by the CONI 106) to call the client (or serve the client) and perform the sale function (and / or the service function). use. The agent inputs the result of the customer service to the TM / DM center 118. The TM / DM center 118 sends the result to the CONI 106. The CONI 106 feeds back information based on these results to both the CARMA 102 (as the data provider 110) and the DSS 104. For example, if a client is serviced (to sell long distance service to the client) and the client indicates that "the client prefers to switch her local phone service provider instead" For example, the agent records this instruction in the file at the TM / DM center 118. The files of all clients that prefer to switch the client's local telephone service provider are then sent to CARMA 102 (as data provider 110) and DSS 104. CAR MA 102 uses this information to update each client's profile (provided in the file) to indicate that "this client is interested in switching the client's local service provider". use. This information is then sent from the CARMA 102 to the DSS 104 in the form of a client identifier and an indicator (indicating interest in switching local service providers). This information is stored in DSS 104. DSS 104 can also receive information directly from TM / DM center 118 (as a data provider) via CONI 106. The information indicates "for example, in a city, how many people are interested in switching their local service provider." Based on this information, the BSU 116 can query the DSS 104 to determine whether there is sufficient interest in a city to plan a local service provider marketing campaign. Then, the CONI 106 can generate clues for the local service provider campaign. The above example shows one of a number of feedback loops in the SaMS infrastructure 100. When an agent at the TM / DM center 118 makes a purchase contract (or sells) with a new customer, the agent enters orders directly into the customer order entry system 120. Customer order entry system 120 provides updated data to DSS 104 (in addition to recording and preparing orders). This is to show the result of the order (or surrounding information). For example, if the order is for long-distance service, customer order entry system 120 updates DSS 104 to indicate that "this client is currently subscribed to long-distance service." Orders for long-distance service are also provided to the National LEC Interface System (NLIS) and the Quick Preferred Interexchange Carrier (PIC) system 122. The NLIS and Quick PIC system 122 provides the order to the client's local exchange carrier (LEC) 124. The LEC can then translate the client's PIC at the appropriate local switch. The NLIS and Quick PIC system 122 is described in detail in the U.S. patent application "System and Method for Real Time Exchange of Customer Data Between Telecommunication Companies" (COS-96-069). The U.S. patent application is assigned to the commonly designated agent of the present application. The architecture of the TM / DM center 118, the customer order entry system 120, and the NLIS and quick PIC system 122 record the process of serving a client, selling long distance service to the client, and recording orders for long distance service. The process of preparing and the process of converting (with the LEC124 switch) the client's PIC into everything that occurs within just a few minutes is made possible. The NLIS and Quick PIC system 122 also provides data to the DSS 104 for unsolicited PIC conversion. If the customer of the long distance company switches to another company, the customer's PIC conversion is provided by the LEC 124 to the NLIS and the Quick PIC system 122. The NLIS and Quick PIC system 122 provide files of these transformations to the DSS 104. This time, the DSS 104 stores the file and allows the "CONI 106 to extract all recent PIC conversions and generate clues for the customer recall campaign". 2. CONI Referring to FIG. 2, an exemplary internal architecture of the CONI 106 is shown. The CONI 106 provides a graphical user interface (GUI) 160 for a user to interact with the CONI (in at least two ways). The two approaches are to construct a clue market and to perform queries and searches within such (configured) clue markets. Given a clue market query first, a user (such as a company's BSU 116) uses a GUI to convert a marketing strategy into a marketing campaign. BSU 116 initially specifies criteria (for targeted clients). For example, based on previous analysis (performed on data in the data warehouse of DSS 104), BSU 116 states that "People who have recently moved from California to Colorado and have purchased cars in the past year are likely to subscribe to cellular services. And it is likely to switch his long distance provider. " As a result of this decision, BSU 116 desires to offer long-distance and cellular service packages to these people under a telemarketing campaign. BSU 116 states that "BSU 116 has (1) traveled from California to Colorado, and (2) has purchased a car in the past year, and (3) is currently subscribing to both long distance and (company) cellular services. Use GUI 160 to enter and specify that "we want to retrieve records for all clients that are not there." The campaign management process 162 receives input data or criteria from the GUI 130 and translates such criteria into a clue limiting filter (or file). For example, the campaign management process 162 creates a query based on input criteria using a structured query language (SQL) statement. The query to create a list of clue records is generally described herein as "marketing campaign" (described below). The clue limiting filter process 164 receives the configured clue limiting filter from the campaign management process 162. Then apply such a filter to the data in the DSS 104 data warehouse (or in the clues market 166) to extract a list of clients (meeting the criteria specified by the clues-only filter). Described below). The clue-only filter process 164 uses a clue-only filter to extract client records (as “clue records” for a given marketing campaign), and places such clue records in the clue market 166. (This is described below). In the previous example, the clue-only filter first extracts a first clue list of all client identifiers for clients who have traveled from California to Colorado, and based on this first list, identifies cars in the past year. The second clue list of all the purchased clients may be extracted. Then, based on this second list, the clue-only filter extracts a (third smaller) clue list for all clients that are not currently both long-distance (company) and cellular customers. . The clue limiting filter may also extract other undesirable clues. The clue may be (a client who has requested not to be served ("suppression") or a client who is over 100 years old (i.e., is probably dead). In general, exemplary implementations of the invention Under morphology, queries and searches of selected data (from databases and data markets and data warehouses) use known database query and search techniques, ie, for example, SQL statements and open databases. Performed using connections (ODBC), the techniques of which are known by those skilled in the art The clue-filtering process 164 also converts the data (extracted from the DSS 104 based on certain clue-filters) into the clue market A clue market 166 is configured for storage in the 166. A “clue market” 166 is A database that is smaller than the data warehouse and comprises a subset of the data from the data warehouse.Typically, the clue market 166 provides a (customized) collection of extracted data (from the DSS 104) for individual BSUs 116. As described herein, the BSU 116 in turn queries the clue markets to develop a particular client list for a given marketing campaign. , Is a single-substance database used by individual groups of users (such as individual BSUs 116 within a company) In a priority order, an example of such a clue market 166 for a long-distance company is the partner program ( For example, all international partnerships based on the frequent flyer program) A clue market that stores customer data, a data market that stores data of all customers who frequently make international calls to non-English calling countries, and a data market that stores all customers that frequently make international calls to English calling countries. There can be a clue market for all previous customers who have recently switched to other long distance companies and a large market clue market for all customers for a particular service.These common clue markets 166 are ongoing. For example, the clue market 166 of all previous customers who have recently switched to other long distance companies can be used to manage ongoing customer recall campaigns. The clues market 166 is embodied in a distributed computer (such as Sun Dox manufactured by Sun Microsystems). It may be, but need not necessarily be the case. In the exemplary embodiment, the clue-limited filter process 164 provides a priority order or hierarchy (of the clues market 166). Thereby, a given client is not identified in more than one clue market (and therefore will not be served repeatedly under various marketing campaigns). For example, the international affiliate / cooperation customer clue market 166 has a higher rank than the customer clout market making international calls to English calling countries. The clue limiting filter process 164 can be set up to perform nominal (or periodic) processing. For example, a clue limiting filter process 164 can be created to repeatedly extract data from the DSS 104 based on a clue limiting filter previously generated. Thus, on a periodic basis (eg, daily), the clue filter process 164 periodically queries client records (satisfying the clue filter) from the DSS 104 via a data warehouse output (described below). And extract and update the corresponding clues market 166. Thus, the clues market 166 continuously stores the currently updated data in the clues market 166. The user or BSU 116 also uses the GUI 160 to enter data or clue specifications (to generate a detailed client list). The client list is for fulfilling a given marketing campaign. For example, the user may specify data such as "how many clue records should be formatted every day" or "to which TM / DM center 118 a certain lead record should be distributed". May be input to the GUI 160. The clue inventory management process 167 receives such input data from the GUI 160. The data is then used to manage the extraction and processing of clue records (from clue market 166). Thus, the clue inventory management process 167 makes an inquiry based on the data received from the GUI 160 in a manner similar to the method for the clue limiting filter process 164. Then, based on the given marketing campaign (stored in one or more clue markets 166) to generate a "clue list" (ie, a list of clue records selected based on the given marketing campaign). Extract the clue record). The clue inventory management process 167 stores the (resulting) clue list and (corresponding) clue record in the CLR 108. While clue lists generally comprise a list of clue records, each clue record comprises not only the client identifier for a given clue, but also additional information about the client. The additional information is, for example, the number of times and (relevant) date the client was served, or a code number corresponding to the marketing campaign in which the client was served. Generally, clues or clients can be tracked in the CONI 106 based on a marketing campaign code (generated when the marketing campaign is triggered). In addition, the clue inventory management process 167 stores a clue distribution record for each marketing campaign. The clue distribution record identifies "to which TM / DM center 118 the given clue record should be (or has been) distributed". More than one clue distribution record can be associated with one clue record. This is because a client under a clue record can be associated with more than one marketing campaign. The clue inventory management process 167 generates a clue distribution record for a given marketing campaign. The clue distribution record specifies “how many clue records should be formatted every day”, “to which TM / DM center 118 a certain lead record should be distributed”, and the like. . The clue management process also performs certain screening processes (such as to ensure that "duplicate client records are not retrieved and stored in CLR 108"). The clue management process 107 ensures that a given client will not be identified in two different marketing campaigns (and therefore will not be called twice). The clue inventory management process 167 flags each identified client based on the clue list in the CLR 108. If the next clue list identifies a client that has already been flagged (at the CLR 108), the clue inventory management process 167 may create a new clue list hierarchy or rating (first flag a given client). (Stand up) and compare with the hierarchy or rating of the previous clue list. If the next clue list has a higher rank than the previous clue list, the client is flagged for a new clue list. The clue inventory management process then cancels the clue record (previously sent to the TM / DM center 118 based on the preceding clue list) via a formatter (described below). Thus, the clue management process 167 can dynamically adjust the ongoing marketing campaign. Thereby, more successful campaigns (higher priority campaigns) govern and aggregate clients from other campaigns. In general, the CONI 106 provides two types of data retrieval granularity to the BSU 116. Under coarse granularity, the BSU 116 extracts a subset of the client data from the DSS 104 through the GUI 160, the campaign management process 162, and the clue limiting filter process 164, and places such data in the clue market 166. Remember. In a finer granularity process, the BSU 116 may use a subset of the client data (stored in the clues market 166) to generate a clue list (for a marketing campaign) and extract clue records using the GUI 160. And processes 162 and 164. In summary, the campaign management process 162 generates a clue limiting filter based on the query (by the BSU 116) and the criteria input. The clues-only filter process 164 may now either extract the appropriate data from the DSS 104 (if it comprises a clues market 166) or extract the appropriate data from the clues market (if it comprises a clues list). Implement such (generated) clue-limited filters for extraction. The campaign management process 162 provides an interface between the GUI 160 and the start-only filter process 164 while the start-only filter process interacts with the database / data repository. Formatter process 168 receives client data (extracted from CLR 108 and DSS 104 based on a clue list for a given marketing campaign). The formatter process 168 uses the client identifier of each entry in the clue list to generate a proper clue record (which should be used last to serve clients), a name and (if a direct mail campaign, ) Match with address and phone number (if telemarketing campaign). The formatter process 168 obtains the assignment of the name, address, and telephone number for the client identifier from the CARMA 102 via the DSS 104. Referring to FIG. 3, DSS 104 includes in-flight data storage (described below). The storage device extracts this information from CARMA 102 and sends the information to CONI 106. Formatter process 168 formats the resulting clues into clue records and derives distribution records (comprising the identifier and address of the particular TM / DM center 118 to which each clue record is to be distributed). . This information is provided by the clue inventory management process 167. In this exemplary embodiment, formatter process 168 is table driven and therefore uses a definition file (similar to a template). Such a definition file specifies the location of the data (retrieved by the formatter process 168) for display to the agent at the TM / DM center 118. For example, the definition file can specify that "column 1 has a telephone number and column 2 has a name." By being table driven, if a given clue recording format is changed, the formatter process 168 does not require that the "underlying code be changed". Instead, only the definition file needs to be changed to change the way the data extracted from the DSS 104 is displayed (to the agent) at the TM / DM center 118. The TM / DM center 118 receives the formatted clue record from the formatter process 168. The agent at the TM / DM center 118 then serves the client identified in such a record and records the results of such service. The service management process 169 receives the result of the service from the TM / DM center 118. In an exemplary embodiment, such customer service results consist of (or comprise) some predetermined code. Such code might say "whether the client should be restrained", "whether the client should be served again", and "when and what changes are made to the client's Should it be done in the profile? " Thus, the customer service management process 169 arranges follow-ups with clues (if necessary), updates stored data, and the like. The customer service management process 169 sends the code and / or information to the DSS 104 data warehouse for storage. As a result, the customer service management process 169 provides feedback based on the results of the marketing campaign. Feedback provided by the customer service process 169 provides historical information to the CONI 106. Such historical data can be accessed by BSU 116 via CONI 106 to determine "how successful a given marketing campaign has been". The BSU 116 can then modify the given marketing campaign (if necessary) to improve the success of the marketing campaign. The CONI 106 is described in more detail in the co-pending application “System And Method For Automated Lead Generation In Client Contact Management For Sales And Marketing Platform”. The application was filed on the same date as the present application. The application is assigned to a common designated agent with the present application. The application is expressly incorporated into this application by reference. 3. CARMA CARMA 102 may be implemented on many different types of computer systems. FIG. 5 is a block diagram illustrating a computer system 240 (suitable for implementing CARMA 102). An intermediate computer using a DEC Alpha processor (from Digital Equipment Corporation of Maynard, Mass.) Is suitable for running CARMA 102. Computer system 40 includes a central processing unit (CPU) 242 (responsible for monitoring operation of the computer system). Computer system 240 may include a number of peripheral devices (such as video display 244 and input device 246). Computer system 240 may also include a network adapter 248 (for interfacing the computer system with a local area network). A modem 250 may be provided within computer system 240 to facilitate communication with remote computing resources over a conventional telephone line. Computer system 240 may include a number of different types of storage 252. The storage device 252 includes a main storage device and a second storage device. The storage 252 holds a client database 256 and a copy of the program code 254 (for CARMA). One skilled in the art will recognize that "computer system 240 may be either a microprocessor system or a distributed system." The invention is not limited to being "implemented on a single processor system". The client database 256 has a logical architecture as depicted in FIG. Client database 256 includes a number of different tables. Each table contains various information about the client. Each client is assigned a unique client identifier (client ID). This client identifier links information held in different tables for the client. The linked records (for the client) are collected and constitute a client profile for the client. The three main tables in client database 256 are client table 260, address table 282, and domestic telephone table 290. Each record in the client table 260 contains information about the client (such as client ID, social security number, name, and occupation). Address table 282 holds information about the client's address, while national phone table 290 holds information about the client's phone number and phone service. It should be appreciated that "a one-to-many relationship exists between the client table 260 and the address table 282, as well as between the client table 260 and the domestic telephone table 290." A client may have multiple addresses (in connection with the client) and multiple telephone numbers. Each address has a separate record in the client address table 280 and each domestic telephone number has a separate record in the national telephone table 290. The client table 260 and the address table 282 are linked by an intermediary table (client address table 280). Each address of the client has a record in the client address table 280. The client address table 280 is linked to the client table 260 by “cInt_idr”. Each address has a status indicator ("adr_stat") in the client address table 280. The address status indicator may have a value of "active" or "obsolete". This status indicator is useful for tracking clients as they move between addresses. An address identifier ("adr_id") is maintained in the client address table to link the record and the client address table to the address record (in address table 282). Client telephone table 276 acts as an intermediary table between client table 260 and domestic telephone table 290. For each telephone number or client, the client telephone table 276 has telephone numbers in three fields ("npa", "nxx", and "line"). The suppression table is also provided with a mediation table (eg, client address table 280 and client phone table 276). In particular, the client address SUPP table 284 holds suppression information on the client address. Similarly, the client telephone SUPP table 288 holds suppression information on the client telephone number. The telephone SUPP table 292 holds the suppression information on the records stored in the domestic telephone table 290. Similarly, the address SUPP table 288 holds the suppression information for the record stored in the address table 282. Household enhancement information is stored in the address enhancement table 286. Enhancement information for the client may be stored in the client enhancement table 274. Client account table 266 keeps track of internal account numbers for clients. A one-to-many relationship may exist between the client table 260 and the client account table 266. In other words, information about multiple clients may be stored for a given client. Client member table 270 tracks client membership (at affiliated or affiliated clubs and various other clubs). Examples include airline frequent flyer clubs, professional associations, car clubs, credit cards, travel clubs, health clubs, and the like. A relationship may exist between a record in the client member table 270 and a record in the client table 260. The client area detail table 272 holds detailed inspection information on the service provider. The detailed inspection information is, for example, the telephone number, address, and name of the client, and is provided by each source. The client enhancement table 274 holds enhancement information on the client. Client language table 278 holds information about the natural language spoken (and / or understood) by the client. Multiple client language records may be provided for a single client. Client list table 262 acts as an intermediary table (for linking the client identified by the client identifier to the list record in list table 261). The list table 261 defines all sources (lists) received by the client. As described above, CARMA 102 can process input data for multiple data sources and update data in client database 256 accordingly. This process (handling new input data) is described below with reference to FIGS. New input data is processed in the loading process. Initially, raw input data is received at CA RMA 102 from data provider 110 (step 320 in FIG. 8). As mentioned above, a data provider may be both external and internal and may provide a variety of different types of information. Scheduler 300 is responsible for causing the individual steps of the processing performed by CARMA 102. Upon receipt of the data, scheduler 300 initiates and monitors the data loading process. The scheduler first causes that "formatting and virus prevention (of the data) are performed on the raw input data" (step 322 in FIG. 8). This formatting and virus prevention (of the data) is performed by the stage loading process 302 (FIG. 7). The stage load process 302 performs client name and address standardization. The stage loading process states that "the client identifier (in the form of a name or social security number or other common identifier) is valid, and certain information (such as a mailing address) is valid, and the information is Exists in the proper format. " In a preferred embodiment of the present invention, the CARMA 102 includes a postalSoft TrueName 304 product and an ACE product 305. The mapping mechanism 303 determines “Which of the products 304 and 305 is used (or data is input)”. The real name 304 standardizes and parses and collects, translates, attaches and verifies name / address information in the data input from the data provider 110. In general, Postal software parses all billing name and address information into standard name and address database attributes. The ACE 305 also performs a standard billing address attachment function. The function is, for example, the identification and addition of a zip code of up to 9 digits, a transmission route, a geographical verification code and a check digit (for a bar code). Street suffix value unit designators are also standardized by real name. The real name 304 holds a reference list of first names and associates a gender coat with each first name (ie, male and female). The preferred embodiment of the present invention also comprises a number of custom coding edits or transforms 306 (establishing the postal soft product 304). For example, name information is always placed at the beginning of the output. Invalid characters are not allowed in names and extra white space is removed in names and addresses. Characters such as "in case" or "attention to" are deleted. The (repeated) names in the first name field and the last name field are deleted. Invalid names are removed. Profanity and repetition of character removal may be provided. If the virus prevention score is below the (predefined) threshold value, the input name component is removed. The stage loading process 302 outputs the confirmed and standardized data to the temporary data storage device 308. This allows the user to view and authorize the data using the computer system 240 before the data is sent to the final loading process 310. Final load process 310 performs some additional data processing before data is added to client database 256. The final loading process 310 comprises applying a client matching algorithm 312. These client matching algorithms 312 are applied to determine whether "(provided) client identification information and data match existing clients (in the client database)" (FIG. 8 step 324). FIG. 9 is a flowchart illustrating (in more detail) how a client matching rule is applied. First, a critical match criterion is examined against records in the client database 256 and information contained in the input data. A value indicating a matching condition for each of a number of different criteria is assigned (step 334 in FIG. 9). The critical matching criterion comprises a social security number matching (SSN) criterion. The value for the social security number matching criterion may be "Y", which indicates that "a match exists" and that the input data and the record (in client database 256) are both It has a housing social security section. " The value may also be "N", indicating that "there is no match, but the input data and database records have social security number values." Finally, the value may be "B", indicating that "one or both of the input data or database records do not have a social security number value". The last name is compared to determine a value against a last name match (LNM) match criterion. A value “Y” for the LNM criterion indicates an exact match. The match excludes misspellings identified as blanks or special characters and hyphenated last names (for married women). The value "N" indicates no match and indicates that "the last name is provided in both the input data and the database record." First names are compared in obtaining a value for a first name match (FNM) reference. The value "Y" indicates an exact match. The match includes the equivalent nickname, abbreviation, and (identified) misspelling. An exact match is also found where the first letter of the first name (including the equivalent nickname and abbreviation) matches. However, this is only the case when the input data (or database record) has a first name (as an initial). Finally, an exact match can be found if the first name matches a nickname table entry. The value "N" indicates "no match exists" and indicates that "first name is specified in both the input data and the database record." Middle names are compared to generate values against middle name matching (MNM) criteria. The MNM criterion may have the value "Y". The value "Y" indicates an exact match, an equivalent nickname and an equivalent abbreviation. The value "N" indicates "no match exists" and indicates that "the middle name is specified in both the input data and the database record." The value "B" indicates that "one or both of the input data in the database record is not occupied with a middle name". Gender is compared in gender (GDR) matching criteria. The value "N" indicates that "in both the input data and the database records, no match is found between males or females or company genders". The value "A" indicates that "input data or database records are occupied with ambiguous gender values". The value "M" indicates that "both input data and database records are occupied with male gender codes". The value "F" indicates that "both input data and database records are occupied with female gender codes". The value "C" indicates that "both sources are occupied with company gender code". The client's title is compared to generate a value for the title (TTL) matching criteria. The value "Y" indicates an exact match on the ritual title, or an equivalent fuzzy value match. For example, the abbreviation "Mrs. "" Is "Ms. The value "N" indicates "no match exists" and indicates that "both input data and database records are occupied with a ritual title". The value "B" indicates that "input data and / or database records are not occupied with a ritual title". The zip code is compared to generate a value for a zip code matching criterion (ZIP). The value "9" indicates an exact match of the full 9 digit zip code. The value "7" indicates a match on the first 7 digits of the zip code. A value "5" indicates a match on the first 5 digits of the zip code. The value "N" indicates a mismatch and indicates that "both input data and database records are occupied with zip codes". Street names and street suffixes are compared in a street name and street suffix (STR) matching criterion. The value "Y" indicates an exact match between the street name and the street suffix. The value "N" indicates no match and indicates "both input data and database records are occupied" or "one of the input data and database records is not occupied". . The value "B" indicates that "both input data and database records are not occupied with the street name or street suffix". Address number or P.E. O. The box numbers are compared to generate a value against a number (NBR) match criterion. The value "Y" indicates an exact match. The value "N" indicates no match and indicates that "both input data and database records are occupied by the same type of information". The parcel number is compared to generate a value for the parcel (APT) matching criteria. The value "Y" indicates an exact match. The value "N" indicates "no match exists" and indicates that "both input data and database record include block number specification". The value "B" indicates that "the input data or database record is not occupied with the partition number". The telephone numbers are compared to generate a value against telephone number (PHN) matching criteria. The value "Y" indicates an exact phone number match. The value "N" indicates "no match exists" and indicates that "both input data and database records contain telephone numbers." The value "B" indicates "neither the input data nor the database record contains a telephone number." The account numbers are compared to generate values against account number (ACC) matching criteria. The value "Y" indicates an exact match. In the match, both the input data and the database record are occupied with the account number. The value "N" indicates that "the input data and the database record include an account number" and that "there is no match between account numbers". The value "B" indicates that "one or both of the input data and database records are not occupied with the account number". The membership numbers are compared to generate a value against a membership number (MEM) criterion. A value "Y" indicates an exact match on a particular membership number. The value "N" indicates "no match exists" and indicates that "both input data and database records are occupied with the same type of membership number". The value "B" indicates that "one or both of the input data and database records are not occupied with a membership number". The client ID (client_id) may be compared to generate a value for a client ID matching criterion. The value "Y" indicates an exact match. In the match, both the input data and the database record are occupied with the client ID. The value "N" indicates "no match exists" and indicates that "both input data and database records are occupied with the client ID". The value "B" indicates that "one or both of the input data and database records, not occupied with the client ID". It should be noted that "each of these matching criteria also exhibits the value"-"." The value "-" indicates that "the determination whether or not a match exists does not depend on the criterion". The value is used (step 336 in FIG. 9) by applying a matching rule (using a matching rule table) to determine whether a match exists. An example of the matching rule is as follows. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Scenario Result-Rule-YYYMBYYYYY----00113 Match-YYYMBYYYYN----00114 Match -YYYMBYYYYB----00115 Match-YYYMBYYNY----00116 Match-YYYMBYYYNB----00118 Match 1 = SSN 2 = LNM 3 = FNM 4 = MNM 5 = GDR 6 = TTL 7 = ZIP 8 = STR 9 = NBR 10 = APT 11 = PHN 12 = ACC 13 = MEM 14 = CLN Each row in the matching rule table is a scenario. And the results (note the columns labeled "Scenario" and "Result-Rule"). Each row may be considered a separate rule. Each other column specifies an individual value for one of the 14 matching criteria described above (see legend above). If the criterion has the value specified in the column, the rule is satisfied and the result of the rule is applied. For example, scenario 113 states that “if the last names match (column 2 is“ Y ”), the first names match (column 3 is“ Y ”), and the middle names match (column 4 is“ Y ”). "Y"), and both input data and database records are occupied with male gender codes (column 5 is "M") and one or both sources are not occupied with ritual titles ( Column 6 is "B"), zip codes match (column 7 is "Y"), street names and street name suffixes match (column 8 is "Y"), and numbers match. (If column 9 is "Y") and the sections match (column 10 is "Y"), then a match between the input data and the database record is determined. " As a result, in step 326 of FIG. 8, by applying the collation rule table, a determination is made as to “match or not”. It should be appreciated that "there are many different combinations or scenarios within the matching rule table (which can be categorized into category 339 shown in FIG. 10)." In particular, the matching rule table contains the following combinations: name and address combination 340, name and telephone combination 342, name and social security number combination 344, and name and account combination 346. , A combination 348 of a name and a membership number, a combination 350 of a name and a client ID, a combination 352 of an address and a telephone, a combination 354 of an address and an account, and a combination 356 of an address and a membership number. , Telephone and account combination 358, telephone and membership number combination 360, and account and membership number combination 362. At step 326, if it is determined that "there is no match between the input data and all database records (which hold the client profile)", then a new record may be created, and , A new client identifier is assigned to the client (step 328 of FIG. 8). The new record is filled with data provided in the input data processed by the stage loading process 302. Conversely, if a match is found, an overlay process is applied to determine how to resolve the conflict between the client information (included in the input data) and the client database record. (Step 330 in FIG. 8). Generally, as described in more detail below, the overlay process applies overlay rules and resolution rules to determine how to resolve conflicts. In response, the data is updated in the client database 256 (step 332 in FIG. 8). This overlay process is depicted in FIG. 7 as overlay 314 and results in data (sent to client database 256). FIG. 11 illustrates various types of overlay rules 364 (provided by CARMA 102). There is a client overlay rule 366. The general approach of the client overlay rule is that after receiving an indication that a "match exists", the name field in the client database 256 will only be updated if the input data has more complete information. . Client overlay rules comprise specific rules (sent to a column in client table 260). The active address overlay rule 368 specifies that "how active address information in the client database 256 should be overlaid with respect to (matching) input information." The international address overlay rule 370 specifies "how international address information should be overlaid." The telephone number overlay rule 372 specifies "how telephone number information should be overlaid." Enhancement overlay rules 374 specify "how enhancements should be overlaid." The list specific database table overlay rule specifies that "which database tables are allowed to be updated for a particular load feed". Finally, the Client_Provider_Detailed Overlay rule indicates "how the client provider information in the database 256 should be overlaid." Once the client database 256 has been updated, the changes may be replicated by the client database replication process 316 and the data storage facility 380 (for in-flight data storage 384 managed by the DS S104). May be sent to Changes are captured by a change data capture process 318. The change data capture process 318 sends the change to the data storage facility 380 of the data warehouse 823 of the DSS 104. Hence, CARMA 102 provides an integrated system (for client profile management). The client profile management offers a number of unique features. CARMA tracks individual clients as individuals, rather than phone numbers or addresses. Thereby, multiple clients sharing a phone number or address are tracked. CARMA 102 maintains a number of relationships (including multiple addresses per client and multiple phone numbers per client). This facilitates complete tracking of clients with multiple phone numbers or addresses. The CARMA 102 continually tracks clients and facilitates immediate changes to client profiles. The CARMA 102 has processing resources (to accept and use almost all types of input data in all formats). In addition, CARMA performs effective client matching to avoid duplicating client profiles. 4. data flow FIG. 12 illustrates the data flow in the SaMS infrastructure 100. The process steps and data flows in FIG. 12 are identified by the following reference numerals (and in FIG. 12) 1-24. The paragraphs shown below are designated by the numbers 1-24. The numbers 1 to 24 correspond to the data flows shown in FIG. Relevant locations or specific hardware or processes are also described with respect to data flows 1-24. 1. Client information from data provider 110 is collected by CARMA 102. As described above, client information from data provider 110 includes not only external data (such as syndicated lifestyle information) but also internal data (such as company customer transactions, billing system records, client customer records, etc.). A source can also be provided. The CARMA 102 is designed to accept data in any actual format and from any source. The CARMA 102 uses the input client information to update the client profile (in the CARMA 102 client database). 2. All changes to the client profile in CARMA 102 (generally the result of new client information entry by data provider 110) are captured and sent to DSS 104. Certain client identification data (such as name and address) is reserved. Instead, CARMA 102 provides the generic client identifier to DSS 104. DSS 104 uses data storage process 380 to collect and format all input data (from CARMA 102 or any other data provider). The data storage process 380 comprises a process for identifying and extracting and transforming and extracting and retrieving and collecting and integrating and integrating and thoroughly checking data collected from the data provider 110. The identification process does not only identify the ultimate source for the collected data, but also which data elements (within the collected data) are needed for downstream processes. Identify (where the first known source is not required). The extraction process copies the appropriate data from the data provider 110. The conversion process coordinates the various ways (the data is labeled) when the same data is received from data provider 110. For example, the value for a client's gender may be in the form of "m" or "f" under one data provider (or system), while the value from another data provider is "1" or "f". The format may be 2 ″. The conversion process may instead assign new values (such as "male" and "female"). The deduction process converts one data into another value. For example, two or more fields of data relating to a client may be converted into a score (eg, the client's address and revenue combined and displayed by two digit scores). The aggregation process combines and summarizes data across a set of operations or a set of (individual) clients. For example, total monthly long haul consumption by clients is collected throughout the year to provide average monthly consumption values for the client. The integration process matches the data with the appropriate client number and verifies the time frame for each of the data. The integrity check process ensures that "the data stored in the data warehouse exists in the proper format / format". 3. Data storage process 380 collects information from various data providers 110. No specific client identifier is required for this information. This information can be used to identify general trends. 4. Data storage process 380 stores all data (collected by data storage process 380 in data warehouse 382). The data warehouse 382 is divided and configured into various schemes to meet the needs of the business utilizing the data warehouse 382. For a typical business (such as a telecommunications company), the data warehouse 382 must be able to store huge amounts (perhaps several terabytes) of data. Data warehouse 382 preferably uses a massively parallel processing (MPP) platform (such as "100 or more" IBM SP2 processors). A scalable database management system (such as provided by Informix Corporation) is preferably used. 5. And 6. Data output process 386 extracts specific data from data warehouse 382 and places this data in data market 388. Data market 388 is a smaller database (containing a subset of data from data warehouse 380) and to facilitate (quick and easy) access to data stored in the data warehouse. used. The data markets 388 each preferably use a symmetric parallel processor (SMP). Each data market 388 is set up for an individual customer or user of DSS 104. For example, one data market 388 may be established for residential marketing BS U 116 and another data market may be established for small business group BSU 116. The user of the DSS 104 (such as the BSU 116) states, "What data does the user want to place in the user's data market 388 from the data warehouse 382?" Is specified in the data output process 386. As described below, BSU 116 specifies such criteria via DSS user interface process 390. The data output process 386 then periodically extracts data from the data warehouse 382 based on the criteria specified by the user and places the data in the user's data market 388. In summary, data output process 386 moves data from central data warehouse 382 to departmental data market 388 in a process similar to data storage process 380 (e.g., a user can select the requested element, And it can request that "the transformation is applied to the data before it is stored in the data market" 7. and 8. The DSS user interface process 390 accesses the data in the data market 388. And a tool that provides analysis (of the data) .The user (such as the BSU 116) can perform a query to the data in the user's data market (the process described above for the CONI 106). DSS user interface process 3 based on a query process) For example, the data output process 386 may extract data (indicating all clients recently moved from the United States to a foreign country) from the data warehouse 382, and divide this data into a data market for the BSU 116. 388. The BSU 116 may then list (based on this data) a list of all these clients (moved from California to Japan and selected another long distance company). ) Use the DSS user interface process 390 to obtain: Generally, more complex analytical methods are used to determine "what type of marketing campaign can be successful". B SU 116 is a critical (can be translated into marketing strategy) Examine the BSU's data market 388 to discover patterns and relationships.To develop a marketing strategy and determine (based on) the type of marketing campaign to be performed, the BSU 116 The DSS user interface process 390 is used to formulate the query and perform the necessary analysis (of the data in the data market 388 of the BSU 116) The query for the data in the data warehouse 382 may be in SQL or other The BSU 116 preferably comprises a minicomputer or workstation (such as Sun Microsystems' SC2000 / SPARC20 system). Such a microcomputer is preferably a UNIX Operating Operating under the system, and executes a database management system such as that provided by the informed mix. Minicomputers (as well as other elements in the SaMS infrastructure 100) are also coupled using a high bandwidth connection. For example, the BSU 116 minicomputer is preferably coupled to the DSS 104 and the CONI 106 using a fiber optic distribution data interface (FDDI) local area network connection. The minicomputer communicates to the infrastructure 100, preferably using ODBC. In the exemplary embodiment, BSU 116 uses a world wide web browser to access hypertext markup language (HTML) applications on DSS 104 and / or CONI 106. The HTML application provides data viewing menus and other screens under the GUI environment (to the BSU 116), as described herein. Then, the BSU 116 accesses each part of the infrastructure 100 via the intranet or the Internet. 9. Once the BSU 116 analyzes the data and determines a marketing strategy, the BSU 116 uses the CONI 106 to execute the strategy (as a marketing campaign targeted at a particular client segment). I do. The campaign marketing process 162 (within the CONI 106) and the GUI 160 provide the ability for "BSU 116 to elaborate its marketing campaigns as specific criteria." 10. Data entry (through the GUI 160) to the campaign management process 162 is converted to a clue-limited filter by the campaign management process under a marketing campaign. Then, the clue limiting filter is input to the clue limiting filter process 164. The clue limiting filter process 164 is an interface between the data output process 386 of the DSS 104 and the CONI 106. The clue-only filter specifies the criteria that (the client) must meet to be included in the marketing campaign. 11. The clue-filter process 164 extracts data from the data warehouse 382 based on criteria indicating (under the clue-filter) the marketing campaign of the BSU 116. Alternatively, the clue limiting filter process 164 applies a clue limiting filter to extract data stored in the clue market 166. 12. Client records that meet all the clue-specific filter criteria are placed in the clue market 166 (associated with the clue record). The clue market 166 is a CONI 106 data market housing client record or a clue record for a particular marketing campaign. Based on the clue record, a formatted clue record is generated (as described herein). Although there may be multiple clue markets 166, one record for one client is preferably stored in only one of the clue markets 166. 13. The clue inventory management process 164 generates a clue list based on the clue records (selected by the clue limiting filter). In addition, the clue inventory management process 164 generates a clue distribution record under instructions based on data input from the BSU 116. The clue distribution records may specify the number of clue records that are made available for telephone or mailing, or specify the TM / DM center 118 that receives each clue record, or each TM / DM center. For example, the total number of clue records to be assigned to the DM center is specified. The BSU 116 can use the clue inventory management process 164 to specify where clues are sent based on the agent's skill status, terrain, available resources, etc., so that the "TM / DM center 118 Better manage ". The clue inventory management process 164 also ensures that "each client is extracted only once from all clue markets 166", which means that "clients are not duplicated in various clue lists". Guarantee. 14． The clue inventory management process 164 provides a clue list and (associated) clue records and clue distribution records for storage within the CLR 108. CLR 108 manages clue records for each client through marketing campaigns. The clue record includes prior customer service and customer service results under a feedback data flow (described herein). The clue management process 167 keeps track of clues that have recently been provided to the TM / DM center 118 to ensure that "services are not frequent for the same client". Then, the clue record in the CLR 108 is updated according to the tracking. For example, if a clue record for a particular client is sent to the first TM / DM center 118 (one night), and another clue record for the same client is sent from the clue inventory management process 167 to the CLR 108 (next night). If provided, the clue record in CLR 108 will indicate (based on the second clue record) that "this is the second clue record (at two nights) for the same client", or , Does not send this clue to another TM / DM center 118. 15. The DSS data storage process 380 collects from the CARMA 102 a supply of specific data (or assigned) for a client identifier (such as a name and address or telephone number). 16. This particular data is placed in an in-process data storage (ODS) 384. ODS 384 is similar to data warehouse 382, but is generally much smaller. The purpose of ODS 384 is to temporarily store data for distribution to other processes (or systems). 17． And 18. When requested by the formatter process 168, the data output process 386 extracts from the ODS 384 specific data (such as name and address and telephone number) assigned to the client identifier in the clue record, and To the formatter process. The formatter process 168 assigns a name and phone number and (if possible) a mailing address to each client identifier (provided by the clue inventory management process 164) and generates a formatted clue record. Use this data. 19. The formatter process 168 retrieves a clue record from the CLR 108 associated with the clue list. The client data (provided by the data output process 386) is then used to construct a formatted clue record. Formatted clue records may include some (or all) of the following data: client name, phone number, address, customer service history, TM / DM center 118 assignments, and other information (for marketing campaigns). May be provided. Formatter process 168 formats the clue record by matching the client identifier (received by clue inventory management process 164) with the name and phone number (from CARMA 102). 20. Formatter 168 sends the formatted clue record to the appropriate TM / DM center 118 based on the clue distribution list. The TMDM center 118 pulls such clue records, serves clients, and conducts marketing campaigns (such as providing long-distance services or products). 21. The results of each client service are recorded locally at the TM / DM center 118. 22. The results of each client service are extracted from (or sent to) the service management process 169 (in the CONI 106) from the TM / DM center 118. The customer service management process 169 can arrange follow-up clues and report the status (or results) of a given campaign. The customer service management process 169 may automatically update the clue record stored in the CLR 108. 23. The customer service management process 169 provides the result of the client service to the data storage process 380. Thereby, the data warehouse 382 can be updated with these results. The data output process 386 then updates the corresponding data (within the data market 175). This shows another of the multiple feedback loops (made into the SaMS infrastructure 100). As described above, BSU 116 formulates and processes marketing campaigns. The results of each client service (under the campaign) are sent to the data warehouse 382. The BSU 116 can then extract and analyze the results of the entire campaign by designating certain client data extractions to the data output process 386. Based on this, the BSU 116 may formulate other campaigns, modify existing campaigns, or identify unexpected responses to previous campaigns. For example, BSU 116 may formulate a campaign to sell long-distance services (to an RBOC customer). Many customers may (preferably) respond to switching local service providers when served by a TM / DM center. These responses are recorded in the CLR 108 and extracted by the customer service process 169, collected by the data storage process 380, and stored in the data warehouse 382. The BSU 116 then analyzes the results of the BSU 116's campaign (via the DSS user interface process 390) and the previously updated data market, and states that "local service marketing campaigns to those same customers are required. It is determined. The TM / DM center 118 can also execute a direct mail campaign. For example, the CONI 106 instructs the TM / DM center 118 to "mail a brochure to selected clients, wait two weeks, and call these clients." 24. The result of client attendance may be that the client requests that it not be called again ("suppression"). As described above with respect to data flow 22, the customer service management process 169 updates the clue record in the CLR 108 to indicate suppression for the client. The extraction of all constraints is then sent to CARMA 102 (as a data provider). CARM A 102 also sends these suppressions to data warehouse 382 by client identifier only. Then, the clue-limited filter process 164 can remove all clients having the suppression index in future campaigns. Suppression can also be provided to CARMA 102 from an external data source 114 (such as LEC 124). Although the present invention has been described with reference to preferred embodiments of the invention, those skilled in the art will recognize that various changes in form and detail may be made (as intended by the invention, as defined in the appended claims). May be performed without departing from the range).

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ソーサ，ライアン アメリカ合衆国 コロラド 80920 コロ ラド スプリングス ラングホルム ドラ イヴ 2318 (72)発明者 パターソン，ロナルド アメリカ合衆国 コロラド 80920 コロ ラド スプリングス ウィスパー ハロー ドライヴ 3913 (72)発明者 トーントン，ポーラ アメリカ合衆国 コロラド 80919 コロ ラド スプリングス スピアロック パス 2523 (72)発明者 ゲラー，ロブ アメリカ合衆国 コロラド 80919 コロ ラド スプリングス アルパイン ヴュー ウェイ 8315 (72)発明者 グリーンフィールド，ローレンス アメリカ合衆国 コロラド 80126 ハイ ランズ ランチ ハンティントン ドライ ヴ 710 (72)発明者 ミラー，アリス アメリカ合衆国 コロラド 80209 デン ヴァー エス ペンシルヴァニア ストリ ート 626 (72)発明者 バレット，ポール アメリカ合衆国 コロラド 80210 デン ヴァー エス ペンシルヴァニア ストリ ート 1745 (72)発明者 クルーガー，アル アメリカ合衆国 コロラド 80132 モニ ュメント ワインディング メドー ウェ イ 175────────────────────────────────────────────────── ─── Continuation of front page    (72) Inventor Sosa, Ryan             United States Colorado 80920 Coro             Rad Springs Langholm Dora             Eve 2318 (72) Inventor Patterson, Ronald             United States Colorado 80920 Coro             Rad Springs Whisper Hello               Drive 3913 (72) Inventor Taunton, Paula             United States Colorado 80919 Colorado             Rad Springs Spearlock Pass               2523 (72) Inventor Geller, Rob             United States Colorado 80919 Colorado             Rad Springs Alpine View               Way 8315 (72) Inventor Greenfield, Lawrence             United States Colorado 80126 High             Lands Ranch Huntington Dry             Eve 710 (72) Inventor Miller, Alice             United States Colorado 80209 Den             Vers Pennsylvania Sutri             Tote 626 (72) Inventor Barrett and Paul             United States Colorado 80210 Den             Vers Pennsylvania Sutri             1745 (72) Inventor Kruger, Al             United States Colorado 80132 Moni             Winding Meadow We             B 175

Claims (1)

【特許請求の範囲】 １． クライアントプロフィールを管理するためのクライアントプロフィール 管理システムを具備する自動マーケティングシステムであって、 クライアントプロフィールは、マーケティング接客のために、クライアントに ついての情報を具備し、 該システムは、 クライアントに関するデータを記憶するためのデータ倉庫システムと、 テレマーケッターによって接客するクライアントの糸口を自動的に生成するた めに、データ倉庫に問い合わせるための接客インフラストラクチャと を具備し、 該問い合わせは、「生成された糸口は、所定の特徴を具備するクライアントに 対するものである」ということを保証するために、データ倉庫内のデータを限定 することを引き起こす ことを特徴とする自動マーケティングシステム。 ２． クライアントプロフィール管理システムは、クライアントプロフィール データベースとデータベース管理システムとを具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 ３． クライアントプロフィールは、クライアントに対して複数の電話番号を 指定するクライアントプロフィールを具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 ４． クライアントプロフィールは、クライアントに対して複数のアドレスを 指定するクライアントプロフィールを具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 ５． クライアントの内の少なくとも１つは、ビジネスである ことを特徴とする請求項１記載の自動マーケティングシステム。 ６． クライアントプロフィールは、第１クライアントに対する第１クライア ントプロフィールと、第２クライアントに対する第２クライアントプロフィール とを具備し、 第１クライアントと第２クライアントとは、第１クライアントプロフィール内 と第２クライアントプロフィール内との両方に記憶される１つの電話番号を共有 する ことを特徴とする請求項１記載の自動マーケティングシステム。 ７． クライアントプロフィールは、第１クライアントに対する第１クライア ントプロフィールと、第２クライアントに対する第２クライアントプロフィール とを具備し、 第１クライアントと第２クライアントとは、第１クライアントプロフィール内 と第２クライアントプロフィール内との両方に記憶される１つの居住アドレスを 共有する ことを特徴とする請求項１記載の自動マーケティングシステム。 ８． クライアントを接客した結果をデータ倉庫およびクライアントプロフィ ール管理システムへ送るためのフィードバックメカニズム を更に具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 ９． 選択されたクライアントが糸口として指定されることを、選択されたク ライアントを接客した結果に応じて抑制するための抑制メカニズム を更に具備する ことを特徴とする請求項８記載の自動マーケティングシステム。 １０． テレマーケティング接客の結果として生じる注文に応じて注文を準備 するためのオートメーティド注文準備システム を更に具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 １１． 生成された糸口を、テレマーケッターを有する少なくとも１つのテレ マーケティングセンタへ送付するための送付メカニズム を更に具備する ことを特徴とする請求項１記載の自動マーケティングシステム。 １２． 潜在的なクライアントに関するデータを記憶している自動マーケティ ングシステムにおいて、コンピュータによって実行される方法であって、 テレマーケッターよって接客する潜在的なクライアントの糸口を、記憶された クライアントデータに基づいて生成するための糸口生成器を提供するステップと 、 第１マーケティングキャンペーンに対する糸口を生成するために、糸口生成器 を使用するステップと、 生成された糸口に接した結果を取得するステップと、 第２マーケティングキャンペーンに対する糸口を糸口生成器によって生成する ために、取得された結果を使用するステップと を具備する ことを特徴とする方法。 １３． 生成された糸口中にクライアントが現れないよう少なくとも１つのク ライアントを抑制するために、取得された結果が使用される ことを特徴とする請求項１２記載の方法。 １４． 取得された結果は、「接客されたクライアントが、接客されたことに 応じて購入したか否か」ということを示す ことを特徴とする請求項１２記載の方法。 １５． 自動マーケティングシステムにおいて、コンピュータによって実行 されるステップを具備する方法であって、 該方法は、 テレマーケティング接客に対して、潜在的なクライアントに関するクライアン ト情報を、クライアント毎に提供するステップと、 テレマーケティング接客に対して糸口のリストを生成するために、クライアン ト情報を問い合わせるステップと、 糸口をテレマーケッターに送るステップと を具備し、 各糸口は、潜在的なクライアントに関連し、かつ、第１の組の特徴を満たす潜 在的なクライアントに対するコンタクト情報を具備する ことを特徴とする方法。 １６． 複数のデータプロバイダから、複数のフォーマットで、新たなデータ を受信するステップと、 提供されたクライアント情報を更新するために、新たなデータを、提供された クライアント情報と統合するステップと を更に具備する ことを特徴とする請求項１５記載の方法。 １７． 糸口の関連した潜在的なクライアントを接客した結果を受信するステ ップと、 該結果を、提供されたクライアント情報と共に、記憶するステップと を更に具備する ことを特徴とする請求項１５記載の方法。 １８． 該システムは、データ倉庫を具備し、 クライアント情報の内の少なくともいくつかは、データ倉庫内に記憶される ことを特徴とする請求項１５記載の方法。 １９． テレマーケティング接客に対して糸口の他のリストを生成するために 、クライアント情報を再び問い合わせるステップ を更に具備し、 各糸口は、潜在的なクライアントに関連し、かつ、第２の組の特徴を満たす潜 在的なクライアントに対する接客情報を具備する ことを特徴とする請求項１５記載の方法。 ２０． 第１の組の特徴を満たす潜在的なクライアントに対する糸口を、糸口 のリストから抑制する ことを特徴とする請求項１５記載の方法。[Claims]   1. Client profiles for managing client profiles An automatic marketing system having a management system,   Client profiles are available to clients for marketing With information about   The system is   A data warehouse system for storing data about clients,   Automatically generate clues for clients serving customers by telemarketers Customer service infrastructure to query data warehouses   With   The inquiry says, "The generated clue is sent to a client having the specified characteristics. The data in the data warehouse to ensure that Cause you to   An automatic marketing system characterized by the following.   2. Client profile management system, client profile Equipped with database and database management system   The automatic marketing system according to claim 1, wherein:   3. The client profile allows the client to enter multiple phone numbers Have a client profile to specify   The automatic marketing system according to claim 1, wherein:   4. The client profile allows multiple addresses to the client Have a client profile to specify   The automatic marketing system according to claim 1, wherein:   5. At least one of the clients is a business   The automatic marketing system according to claim 1, wherein:   6. The client profile is the first client for the first client Client profile and a second client profile for the second client With   The first client and the second client are in the first client profile Share one phone number stored both in and in the second client profile Do   The automatic marketing system according to claim 1, wherein:   7. The client profile is the first client for the first client Client profile and a second client profile for the second client With   The first client and the second client are in the first client profile One resident address stored both in and in the second client profile Share   The automatic marketing system according to claim 1, wherein:   8. The results of client service are transferred to the data warehouse and client profile. Feedback mechanism to send to the rule management system   Further comprising   The automatic marketing system according to claim 1, wherein:   9. Confirm that the selected client is designated as a clue by the selected client. Suppression mechanism to suppress the client according to the result of serving customers   Further comprising   9. The automatic marketing system according to claim 8, wherein:   10. Prepare orders according to the order resulting from telemarketing service Automated order preparation system   Further comprising   The automatic marketing system according to claim 1, wherein:   11. The generated clues are transmitted to at least one telemarketer having telemarketers. Sending mechanism for sending to marketing center   Further comprising   The automatic marketing system according to claim 1, wherein:   12. Automated marketers that store data about potential clients A computer-implemented method in an operating system, comprising:   Remember the clues of potential clients serving customers by telemarketers Providing a clue generator for generating based on the client data; ,   A clue generator to generate clues for the first marketing campaign A step using   Obtaining a result of contact with the generated clue;   Generating a clue for the second marketing campaign by a clue generator And using the obtained results to   Have   A method comprising:   13. At least one click to prevent clients from appearing in the generated clues The obtained result is used to suppress the client   13. The method of claim 12, wherein:   14． The obtained results indicate that the serviced client is Or not purchased in accordance with   13. The method of claim 12, wherein:   15. Executed by computer in an automatic marketing system A method comprising the steps of:   The method comprises:   Clients about potential clients for telemarketing services Providing client information for each client;   To generate a list of clues for telemarketing customers, the client Querying information about the   Sending the clue to the telemarketer   With   Each clue is associated with a potential client and fulfills a first set of features. Have contact information for potential clients   A method comprising:   16. New data in multiple formats from multiple data providers Receiving the   New data is provided to update the provided client information Steps to integrate with client information   Further comprising   The method of claim 15, wherein:   17． Steps to receive the results of serving potential potential clients And   Storing the result together with the provided client information;   Further comprising   The method of claim 15, wherein:   18. The system comprises a data warehouse,   At least some of the client information is stored in a data warehouse   The method of claim 15, wherein:   19. To generate other lists of clues for telemarketing service Step to query client information again   Further comprising   Each clue is associated with a potential client and fulfills a second set of features. Provide customer service information for potential clients   The method of claim 15, wherein:   20. Clues to potential clients that meet the first set of features From the list of   The method of claim 15, wherein:
JP54709498A 1997-04-29 1998-04-21 Strategic marketing system Pending JP2001523363A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US84591997A 1997-04-29 1997-04-29
US08/845,919 1997-04-29
PCT/US1998/008030 WO1998049642A1 (en) 1997-04-29 1998-04-21 Strategic marketing system

Publications (1)

Publication Number Publication Date
JP2001523363A true JP2001523363A (en) 2001-11-20

Family

ID=25296428

Family Applications (1)

Application Number Title Priority Date Filing Date
JP54709498A Pending JP2001523363A (en) 1997-04-29 1998-04-21 Strategic marketing system

Country Status (5)

Country Link
EP (1) EP0978077A1 (en)
JP (1) JP2001523363A (en)
AU (1) AU6977898A (en)
CA (1) CA2287155A1 (en)
WO (1) WO1998049642A1 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6609120B1 (en) 1998-03-05 2003-08-19 American Management Systems, Inc. Decision management system which automatically searches for strategy components in a strategy
US8364578B1 (en) 1998-03-05 2013-01-29 Cgi Technologies And Solutions Inc. Simultaneous customer/account strategy execution in a decision management system
US6546545B1 (en) 1998-03-05 2003-04-08 American Management Systems, Inc. Versioning in a rules based decision management system
US6601034B1 (en) 1998-03-05 2003-07-29 American Management Systems, Inc. Decision management system which is cross-function, cross-industry and cross-platform
US6285983B1 (en) * 1998-10-21 2001-09-04 Lend Lease Corporation Ltd. Marketing systems and methods that preserve consumer privacy
AUPP794398A0 (en) * 1998-12-24 1999-01-28 T.J. Ford & Company Pty Ltd Method for synchronising product presentation with customer needs
US7096193B1 (en) * 1999-05-21 2006-08-22 Servicemagic, Inc. Facilitating commerce among consumers and service providers by matching ready-to-act consumers and pre-qualified service providers
US6708155B1 (en) 1999-07-07 2004-03-16 American Management Systems, Inc. Decision management system with automated strategy optimization
US7076448B1 (en) * 2000-09-12 2006-07-11 Lettuce Marketing, Llc Automated communication of neighborhood property value information for real estate marketing
FR2819325A1 (en) * 2001-01-09 2002-07-12 France Telecom System for supporting commercial actions such as establishing list of prospective customers has device that may establish list of prospective customers as function at least of trading results information
US8612262B1 (en) * 2003-11-19 2013-12-17 Allstate Insurance Company Market relationship management
IT202100021776A1 (en) * 2021-08-11 2023-02-11 Socalytix S R L method for data analysis

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5353218A (en) * 1992-09-17 1994-10-04 Ad Response Micromarketing Corporation Focused coupon system
CA2234026A1 (en) * 1995-10-17 1997-04-24 Citibank, N.A. Sales process support system and method

Also Published As

Publication number Publication date
EP0978077A1 (en) 2000-02-09
CA2287155A1 (en) 1998-11-05
WO1998049642A1 (en) 1998-11-05
AU6977898A (en) 1998-11-24

Similar Documents

Publication Publication Date Title
US11373261B1 (en) Automated analysis of data to generate prospect notifications based on trigger events
US6253188B1 (en) Automated interactive classified ad system for the internet
JP5193061B2 (en) Method and system for enhancing matching from customer-driven queries
US20050086088A1 (en) Travel information method and associated system
US7340410B1 (en) Sales force automation
US7428531B2 (en) Customer information management system and method
US7343303B2 (en) Global asset risk management system and methods
WO1998049641A1 (en) System and method for automated lead generation and client contact management for a sales and marketing platform
US7783500B2 (en) Personnel risk management system and methods
JP4390402B2 (en) Knowledge information management method, knowledge information utilization method, and knowledge information management device
US20040243588A1 (en) Systems and methods for administering a global information database
JP2003518296A (en) Data linking system and method using tokens
CA2287158A1 (en) Client profile management within a marketing system
WO2001009804A1 (en) Method and system for managing magazine portfolios
JP2001523363A (en) Strategic marketing system
US20040044664A1 (en) Systems and methods for applying customer DNA to airline service and customer relationship management environments
MXPA99010032A (en) Strategic marketing system
MXPA99010031A (en) System and method for automated lead generation and client contact management for a sales and marketing platform
JP2002259659A (en) Novel client development supporting system for multilevel marketing plan
CN117290591A (en) Data integration management system for platform popularization
MXPA99010033A (en) Client profile management within a marketing system
Mertens et al. A Multi-functional Information Leitstand for Top-Management-A Proposal
McEwen Management of Data Elements in Information Processing. Proceedings of a Symposium Sponsored by the American National Standards Institute and by the National Bureau of Standards, 1974 January 24-25, NBS, Gaithersburg, Maryland.
Radak et al. Reengineering of the current process of collecting data about business customers
Rainardi Data Modeling