JP2002511166A - マーケティングシステムにおけるクライアントプロファイル管理 - Google Patents

Abstract

(57)【要約】 コンピュータシステムには、マーケティングの接客で使われるクライアントプロファイル管理のためのデータベースと管理ソフトウェアとが含まれれる。この管理ソフトウェアは、データベースに加えられる多数のプロバイダ側からの入力データを受信し処理することができる。実行されるこの処理には、データのウィルス予防法と、データを標準的なフォーマットへと再フォーマットする運用が含まれる。この処理には、また、入力データに関連するクライアントのためのクライアントプロファイルが既に存在するかを決定する合致基準の運用が含まれる。オーバーレイ規則が、入力データに関連するクライアントのためにクライアントプロファイルが既に存在するときには、クライアントプロファイルをいかに更新するるべきかということを解決するのに使用される。この方法では、管理ソフトウェアは、多数のデータ源から受信したデータで、データベースを速やかに更新することができる。

Description

【発明の詳細な説明】 マーケティングシステムにおけるクライアントプロファイル管理 技術分野 本発明は、概ね、遠隔通信システムに関し、より詳しくは、マーケティングシ ステムにおけるクライアントプロファイル管理に関する。 発明の背景 遠隔マーケティングダイレクトメールおよび遠隔マーケティングダイレクトセ ールは、近年、ますます広まってきている。種々のビジネスが、該ビジネスの商 品およびサービスを販売するために、マーケティングを使用している。そのよう なマーケティングの目的の１つは、ビジネスの顧客インフラストラクチャを拡張 するために、新たな顧客を確立することである。これらのビジネスは、（マーケ ティングキャンペーンおよび接客によって最も効果的に勧誘されそうな）潜在的 な顧客に狙いを付けることを望む。 従来のシステムは、電話番号またはアドレスによって、接客のための潜在的な 顧客を識別する。一般的には、電話番号またはアドレスの一群が接客リスト上に 収められ、かつ、大規模な電話キャンペーンまたはメールキャンペーンまたは訪 問キャンペーンが行われる。残念ながら、そのような大規模なキャンペーンは、 失敗する割合が一般的に高いので、非常に効率が良いという訳ではない。加えて 、そのようなキャンペーンは、大量の資源を使用する。 本発明の要約 本発明は、マーケティングの活動と接客のための、より効果的な方法を与える 。本発明は、より大きなマーケティングシステムの一部である、クライアントプ ロファイル管理システムに焦点を合わせている。クライアントプロファイル管理 システムは、クライアントプロファイルのデータベースを保持している。クライ アントプロファイルには、個人と企業とが含まれる。プロファイルは、各電話あ る いは住所毎にではなく、個人毎に保持される。そのようなものとして、別々のク ライアントプロファイルは、同じ住所に住んで共通の電話番号を共有する２人の 個人用に保持される。加えて、クライアントプロファイルは、クライアント側に 変更があったときには、それを反映して更新される。例えば、電話番号の変更や 、氏名の変更、住所の変更などである。クライアントプロファイルは、多くの異 なるフォーマットによるクライアントプロファイルのデータベースに対する入力 として受信される。クライアントプロファイル管理システムは、そのような入力 値を分析しデータベースに記憶可能な標準的なフォーマットへとフォーマットす る手段を与える。 本発明の第１の面に沿って、クライアントプロファイルを保持するデータベー スを持つコンピュータシステムにおいて、一つの方法が行われる。各クライアン トプロファイルは、マーケティングが接客するクライアントに関する情報を保持 している。この方法では、クライアントに関するデータを持った入力データは、 データベースに追加可能なものとしてデータプロバイダから受信される。合致基 準は、入力されたデータが、データベース内にクライアントプロファイルを既に 持っている選ばれたクライアントのためのものかどうかを決定するために与えら れる。合致基準は、入力データ中の氏名と住所の情報は、すべて、選ばれたクラ イアントのためのクライアントプロファイル中の氏名と住所の情報と比較される 。合致基準によって入力データは、データベースにクライアントプロファイルを 既に持っている選ばれたクライアントのものでは無いと決定されると、入力デー タからデータを保持するデータベース中の選ばれたクライアントのために新しい クライアントプロファイルが作られる。他方、もし合致基準によって入力データ は、データベースにクライアントプロファイルを既に持っている選ばれたクライ アントのものであると決定されると、オーバーレイ規則が、入力データの観点か らクライアントプロファイルをいかに更新するかを決定するために与えられる。 クライアントプロファイルは、その後に更新される。 本発明の他の面に沿って、与えられた電話番号における第１のクライアントの ための第１のクライアントプロファイルがデータベース中に記憶される。データ ベースは、各クライアントプロファイルがクライアントに関する情報を記憶する ように、マーケティングでの接客のためにクライアントプロファイルを記憶する 。与えられた電話番号における第２のクライアントのための第２のクライアント プロファイルもデータベース中に記憶される。データベースには、各クライアン ト単位のクライアントプロファイルにアクセスを行う索引がある。こうして、別 々のクライアントプロファイルがデータベース中の単一の電話番号に対して与え られる。 本発明のさらなる面に沿って、第１のアドレスが、クライアントプロファイル 中の選ばれたクライアントのためにデータベース中に記憶される。データベース には、マーケティングの接客のためのクライアントプロファイルが記憶される。 選ばれたクライアントに対する第２情報のアドレスあるいは前のアドレスが、同 様にクライアントプロファイルに記憶される。要求者からの要求に応じて、クラ イアントプロファイルに記憶されたアドレスの中の一つが要求者に与えられる。 よって、データベースは、一人のクライアントに対して多数のアドレスを記憶す る。 本発明の他の付随的な面に沿って、入力データの第１の組が、コンピュータシ ステムにおいて第１のデータプロバイダから第１のフォーマットで受信される。 コンピュータシステムは、マーケティングの接客のためのクライアントに関する 情報を保持する、クライアントプロファイルを備えたデータベースを持っている 。データの第１の組は、標準的なフォーマットへと再フォーマットされ、入力デ ータの第１の組の中の少なくともいくつかのデータは、データベース中の第１の クライアントプロファイルに加えられる。入力データと第２のフォーマットの第 ２の組は、コンピュータシステムにおいて、第２のデータプロファイルから受信 される。入力データの第２の組は、標準的なフォーマットに再フォーマットされ 、入力データの第２の組の中の少なくともいくつかのデータは、データベース中 の第２のクライアントプロファイルに加えられる。コンピュータシステムは、異 なるデータフォーマットの多数のデータプロバイダからのデータを受信し蓄積す る能力を備える。 図面の簡単な説明 本発明の好ましい実施形態は、以下の図面に関して、以下に説明される。 図１は（本発明の好ましい実施形態を実施することに対して適切な）戦略的な マーケティングシステム（ＳａＭＳ）インフラストラクチャを図解するブロック 図である。 図２は、本発明の実施形態を行うのに適したコンピュータシステムのブロック 図である。 図３は、ＣＡＲＭＡデータベースの論理的構成を図示したものである。 図４は、ＣＡＲＭＡの中のデータフローを図示したものである。 図５は、ＣＡＲＭＡによってデータ処理を実行する段階を示したフローチャー トである。 図６は、合致基準を適用する段階を示したフローチャートである。 図７は、合致基準表内にある基準の異なる範疇を示した図である。 図８は、本発明の実施形態内のオーバーレイ規則の異なる種類を示した図であ る。 本発明の詳細な説明 本発明の実施形態は、クライアントの獲得および維持の管理アーキテクチャ( ＣＡＲＭＡ)を与える。ＣＡＲＭＡは、マーケティングシステムのためのクライ アント管理と情報管理と接客サービスを与える、戦略的マーケティングシステム (ＳａＭＳ)インフラストラクチャの一部である。ＣＡＲＭＡは、マーケティング と接客の機能のために、クライアント情報を収集し、追跡し、管理するものであ る。ＣＡＲＭＡは、実質的にあらゆる種類のビジネスに使用できる十分な柔軟さ を備え、クライアントに関する広範囲の情報を追跡することができる。クライア ントに関する情報は、実質的にいかなるフォーマットによるいかなる情報源から も得ることができる。ＣＡＲＭＡは、データフォーマットを標準化する処理と、 入力データのウィルス予防の実行を提供する。 以下に詳述するように、ＣＡＲＭＡには、クライアントプロファイルのデータ ベースとクライアントプロファイルを管理するプログラムコードが含まれる。Ｃ ＡＲＭＡは、多くの送信源からの入力データを受信し、その入力データを処理し てデータベース内に新しいクライアントプロファイルの記録を作る。加えて、Ｃ ＡＲＭＡは、データベース内に関連するクライアントの記録を既に持つクライア ントの入力データが受信されたか否かを決定する。ＣＡＲＭＡは、一致するもの を配置する一致技術を供給し、いかに既存のクライアントプロファイルが更新さ れるべきかを解決するオーバーレイ規則を供給する。 クライアントプロファイルは、電話単位や住所単位でなく個人単位で作られる 。多くのクライアントは、共通の電話番号や住所を共有していることがある。プ ロファイルの情報と特徴は、こうして、家族全体ではなく個人に与えられる。Ｃ ＡＲＭＡは、また、クライアント毎に多重した関係を維持し、多重した住所、多 重したアカウント番号、多重した会員番号、多重した入力源（表）の登録、クラ イアント毎の多重した電話番号を含む。ＣＡＲＭＡは、クライアントを連続的に 追跡を実行することによりクライアントプロファイルの変更を容易にする。住所 変更、電話番号変更、氏名変更、サービス接続とサービス切断が、ＣＡＲＭＡを 介して、たどることができる。 図１は、ＳａＭＳインフラストラクチャ１０を図示するブロック図である。Ｓ ａＭＳインフラストラクチャ１０には、ＣＡＲＭＡ１２とデータプロバイダ１４ とが含まれる。データプロバイダ１４は、入力データをＣＡＲＭＡ１２に与える が、これはＣＡＲＭＡによって維持されるクライアントデータベースに統合する べく処理される。インフラストラクチャの中にある入力データＳａＭＳインフラ ストラクチャ１０と内部データ源１８の外部で生じる外部データ源１６から、入 力データは生じる。ＳａＭＳインフラストラクチャ１０は、また決定支援システ ム（ＤＳＳ）を含み、これは、大規模なデータ倉庫であり、データの収集、記憶 、管理、配付、分析のためのプログラムを含んでいる。データプロバイダ１４か らのデータも、またデータ倉庫に統合するためにＤＳＳ２０へと渡される。ＣＡ ＲＭＡ１２はＤＳＳ２０と相互作用し、ここで、クライアントプロファイルの変 更分は、ＣＡＲＭＡ１２によってＤＳＳ２０へと一般的なフォーマットで渡され る。 ＤＳＳ２０は、クライアントの識別が重要でないデータプロバイダ１４からの データを収集する。そのようなデータの中には、例えば、州のある組の間で移動 する人の数や、車と家庭用ステレオを同じ年に買う人の数や、仕事を持ち政治集 会の会員である女性の数が含まれる。ＤＳＳ２０によって収集されたデータは、 ＳａＭＳインフラストラクチャ１０の使用者のビジネス上の要求に従って変化す る。ＤＳＳ２０は、ビジネス戦略ユニット（ＢＳＵ）２２によって、このデータ にアクセスする。ＢＳＵは、組織だったビジネスとマーケティングと販売戦略に 責任を負う、企業の組織である。各ＢＳＵは、ＤＳＳによって与えられる分析手 段を用いて、ＤＳＳ２０のデータ倉庫の中のデータについてデータの戦略的問い 合わせを行う。これらの問い合わせの結果は、ＢＳＵ２２によってマーケティン グ宣伝活動を規正するのに使用される。 ＳａＭＳインフラストラクチャ１０は、また接客インフラストラクチャ（ＣＯ ＮＩ）２４を含んでいる。ＣＯＮＩ２４は、マーケティングの職員が使用するこ とができる優位性を作るビジネス戦略ユニット２２からの特別な戦略に沿ってデ ータ倉庫から引き出されたデータを使用するソフトウェアシステムである。これ らの優位性は、中央優位保管庫（ＣＬＲ）２６の中に置かれる。ビジネス戦略ユ ニット２２は、ＣＯＮＩに対して判断基準を記述しており、ＣＯＮＩはＤＳＳ２ ０から優位データ抽出するのに使用するものである。優位データは、クライアン トの優位性を識別する(すなわち、マーケティング宣伝活動において目標にされ る潜在的クライアント)。クライアントの優位性は、ＤＳＳ２０の中に記憶され るクライアント識別子によって識別される。ＣＯＮＩ２４は、これらのクライア ント識別子をＣＡＲＭＡ１２から得られる名前、住所および／または電話番号と 一致させることによって優位性を生成する。ＣＯＮＩは、“販売とマーケティン グのプラットフォームのための自動優位生成と接客管理のシステムと方法”とい う題の（copending）応用でより詳細に語られる。これは、本願で共通の代理人 に割り当てられ、ここで明白に参照事項と組み合わせられるデータ上にファイル された。 ＣＯＮＩ２４により生成されＣＬＲ２６の中に記憶される優位性が、一つある いは二つ以上の遠隔マーケティング／ダイレクトメイルセンター（ＴＭ／ＤＭセ ンター）２８に配られる。これらのセンターには、そこから遠隔マーケティング の代理人が接客営業とサービスを電話を通して行う呼び出しセンターが含まれる 。これらのセンターには、また、ダイレクトメール宣伝活動の設備が含まれる。 ＴＭ／ＤＭセンター２８の代理人は、ＣＬＲ２６を経由して与えられる優位性を 使用し、ＣＬＲ内の優位性を用いて作られた接客の結果を記憶する。これらの結 果は、ＣＡＲＭＡ１２とＤＳＳ２０の両方にフィードバックされる。ＴＭ／ＤＭ センター２８のうちの一つにおける代理人が、新しい顧客と契約あるいは販売が 成立したときに、注文は、顧客注文入力システム３０に入力される。顧客注文入 力システムは、注文を記録し、注文を供給する。顧客注文入力システム３０は、 また、注文の結果を示すためにＤＳＳ２０を更新する。もし、注文が遠距離サー ビスであった場合は、注文は国内の市内交換運送（ＬＥＣ）インターフェイスシ ステム（ＮＬＩＳ）とクイックＰＩＣシステム３２へと渡される。これらのシス テム３２は、ＬＥＣがクライアントのＰＩＣを局所的クラス５のスイッチで変換 できるように、注文をクライアントのＬＥＣ３４に送る。 ＳａＭＳインフラストラクチャ１０は、“販売とマーケティングのプラットフ ォームのための自動優位生成と接客管理のシステムと方法”という題の（copend ing）応用でより詳細に語られる。これは、本願で共通の代理人に割り当てられ 、ここで明白に参照事項と組み合わせられる奇数日にファイルされた。 ＣＡＲＭＡ１２は、多数の異なるタイプのコンピュータシステム上で実行され てもよい。図２は、（ＣＡＲＭＡ１２を実行するために適切な）コンピュータシ ステム４０を図解するブロック図である。（マサチューセッツ、メイナードのデ ジタルイクイップメントコーポレーション製の）ＤＥＣアルファプロセッサを使 用する中級コンピュータが、ＣＡＲＭＡ１２を実行するのに適切である。コンピ ュータシステム４０は、（コンピュータシステムの動作を監視することに対して 責任を負う）中央処理ユニット（ＣＰＵ）４２を具備する。ＣＰＵは、（ビデオ ディスプレイ４４および入力デバイス４６のような）多数の周辺デバイスを具備 してもよい。コンピュータシステム４０は、また、（コンピュータシステムをロ ーカルエリアネットワークとインターフェースするための）ネットワークアダプ タ４８を具備してもよい。従来の電話線を通した遠隔コンピューティング資源と の通信を用意にするために、モデム５０がコンピュータシステム４０内に提供さ れてもよい。コンピュータシステム４０は、多数の異なるタイプの記憶装置５２ を具備してもよい。記憶装置５２は、主要記憶装置と第２記憶装置とを具備する 。 記憶装置５２は、クライアントデータベース５６と（ＣＡＲＭＡのための）プロ グラムコード５４のコピーとを保持する。当業者は、「コンピュータシステム２ ４０は、マイクロプロセッサシステムまたは分散システムのどちらであってもよ い」ということを認識する。本発明は、「シングルプロセッサシステム上に実現 される」ということに限定されない。 クライアントデータベース５６は、図３に描かれるような論理的アーキテクチ ャを有する。クライアントデータベース５６は、多数の異なるテーブルを含む。 各テーブルは、クライアントに関する種々の情報を含む。各クライアントは、唯 一無二のクライアント識別子（クライアントＩＤ）を割り当てられる。このクラ イアント識別子は、クライアントに関する異なるテーブル内に保持された情報を リンクする。（クライアントに対する）リンクされた記録は、集められ、該クラ イアントに対するクライアントプロファイルを構成する。クライアントデータベ ース５６内の３つの主要なテーブルは、クライアントテーブル６０とアドレステ ーブル８２と国内電話テーブル９０とである。クライアントテーブル６０内の各 記録は、（クライアントＩＤと社会保険番号と氏名と職業のような）クライアン トに関する情報を含む。アドレステーブル８２は、クライアントのアドレスに関 する情報を保持し、一方、国内電話テーブル９０は、クライアントの電話番号お よび電話サービスに関する情報を保持する。 「クライアントテーブル６０と国内電話テーブル９０との間のみならず、クラ イアントテーブル６０とアドレステーブル８２との間にも、１対多の関係が存在 する」ということが認識されるべきである。クライアントは、（該クライアント に関連して）複数のアドレスおよび複数の電話番号を有してもよい。各々のアド レスは、クライアントアドレステーブル８０内に個別の記録を有し、かつ、各々 の国内電話番号は、国内電話テーブル９０内に個別の記録を有する。クライアン トテーブル６０とアドレステーブル８２とは、媒介テーブル（クライアントアド レステーブル８０）によってリンクされる。クライアントの各アドレスは、クラ イアントアドレステーブル８０内に記録を有する。クライアントアドレステーブ ル８０は、”cInt_idr”によって、クライアントテーブル６０へリンクされてい る。各アドレスは、クライアントアドレステーブル８０内に、ステータスインジ ケーター（”adr_stat”）を有する。アドレスステータスインジケーターは、「 アクティブ」、「廃用」、「参照用」の値を有してもよい。このステータスインジ ケーターは、クライアントがアドレス間を移動するときに、クライアントを追跡 するのに有用である。アドレス識別子（”adr_id”）は、記録およびクライアン トアドレステーブルを（アドステーブル２８２内の）アドレス記録へリンクする ために、クライアントアドレステーブル内に保持される。 クライアント電話テーブル７６は、クライアントテーブル６０と国内電話テー ブル９０との間において、媒介テーブルとして作用する。各電話番号またはクラ イアントに対して、クライアント電話テーブル７６は、３つの欄（”npa”と”n xx”と”line”）内に電話番号を具備する。 抑制テーブルもまた、媒介テーブル（例えば、クライアントアドレステーブル ８０およびクライアント電話テーブル７６）を提供される。特に、クライアント アドレスSUPPテーブル８４は、クライアントアドレスに関する抑制情報を保持す る。同様に、クライアント電話SUPPテーブル８８は、クライアント電話番号に関 する抑制情報を保持する。電話SUPPテーブル９２は、国内電話テーブル９０内に 記憶された記録に関する抑制情報を保持する。同様に、アドレスSUPPテーブル８ ８は、アドレステーブル８２内に記憶された記録に対する抑制情報を保持する。 世帯エンハンスメント情報は、アドレスエンハンスメントテーブル８６内に記憶 される。クライアントに対するエンハンスメント情報は、クライアントエンハン スメントテーブル７４内に記憶されてもよい。 クライアントアカウントテーブル６６は、クライアントに対する内部アカウン ト番号を追跡する。クライアントテーブル６０とクライアントアカウントテーブ ル６６との間には、１対多の関係が存在してもよい。言い換えると、複数のクラ イアントに関する情報が、所与のクライアントに対して記憶されてもよい。 クライアントメンバーテーブル７０は、（提携クラブや類縁クラブや様々な他 のクラブにおける）クライアントのメンバーシップを追跡する。一例として、エ アラインフリークエントフライヤークラブや職業団体や自動車クラブやクレジッ トカードや旅行クラブやヘルスクラブ等が含まれる。クライアントメンバーテー ブル７０内の記録とクライアントテーブル６０内の記録との間には関係が存在し てもよい。 クライアント管区詳細テーブル７２は、サービスプロバイダに関する詳細検査 情報を保持する。該詳細検査情報は、例えば、クライアントの電話番号とアドレ スと氏名であり、各ソースによって提供される。クライアントエンハンスメント テーブル７４は、クライアントに関するエンハンスメント情報を保持する。クラ イアント言語テーブル７８は、クライアントが話す（および／または、理解する ）自然言語に関する情報を保持する。一人のクライアントに対して、複数のクラ イアント言語記録が提供されてもよい。クライアントリストテーブル６２は、（ クライアント識別子によって識別されるクライアントをリストテーブル６１内の リスト記録とリンクするための）媒介テーブルとして作用する。該リストテーブ ル２６１は、クライアントによって受信された全てのソース（リスト）を定義す る。 上述されたように、ＣＡＲＭＡ１２は、複数のデータソースに対する入力デー タを処理でき、かつ、それに応じて、クライアントデータベース５６内のデータ を更新できる。（新たな入力データを取り扱う）この処理が、図４および図５を 参照して、以下に説明される。新たな入力データは、ロード処理において処理さ れる。最初に、未処理の入力データが、データプロバイダ１４から、ＣＡＲＭＡ １２で受信される(図５のステップ１２０)。上述されたように、データプロバイ ダは、外部および内部の両方であってもよく、かつ、様々な異なるタイプの情報 を提供してもよい。スケジューラー１００は、ＣＡＲＭＡ１２によって実行され る処理の個々の段階を引き起こすことに対して責任を負っている。スケジューラ ーは、データを受信すると、データロードプロセスを開始しかつ監視する。スケ ジューラーは、最初に、「フォーマッティングと（データの）ウイルス予防とが 、未処理入力データ上で実行される」ということを引き起こす(図５のステップ １２２)。このフォーマッティングと（データの）ウイルス予防とは、ステージ ロードプロセス１０２（図４）によって実行される。ステージロードプロセス１ ０２は、クライアントの氏名およびアドレスの標準化を実行する。ステージロー ドプロセスは、「(氏名または社会保険番号または他の共通識別子の形式におけ る)クライアント識別子が有効であり、かつ、（郵送アドレスのような）特定の 情報が有効であり、かつ、該情報は適切なフォーマット内に存在する」という ことを保証する。 本発明の実施形態において、ＣＡＲＭＡ１２は、PostalSoftのTrueName製品１ ０４とACE製品１０５とを使用する。割り当て機構１０３は、製品１０４と１０ ５のいずれが入力データに(uxsed)されるべきかを決定する。PostalSoft１０４ は、データプロバイダ１４からのデータ入力における氏名／住所情報を、標準化 し、分析し、修正し、翻訳し、注釈する。概して、PostalSoftは、全ての課金氏 名と住所情報を標準的な氏名と住所データベースのアトリビュートへと分析する 。ＡＣＥ３０５は、また、標準課金住所付加機能を実行する。例えば、全９桁zi pコード、運搬ルート、地理的一致コード、バーコードのチェックディジットの 識別と付属などである。ストリート（street）添え字値ユニット指示子も、また TrueNameによって標準化される。TrueName１０４は、名前（first names）の参 照表を維持し、各名前（first names）の性別コード（例えば、男性、女性）を 関連付ける。 本発明の好ましい実施形態は、また、（PostalSoftプロダクト１０４を確立す る）多数のカスタム符号化エディットまたは変換１０６を具備する。例えば、氏 名情報は、常に、出力の始めに置かれる。無効な文字は、氏名において許可され ず、かつ、余分な空白は、氏名およびアドレスにおいて除去される。「の場合」 または「に注意」のような文字は削除される。ファーストネーム欄およびラスト ネーム欄の（繰り返される）氏名は削除される。無効な氏名は除去される。冒涜 的かつ反復の文字の除去を具備してもよい。もし、ウイルス予防スコアが（予め 定義された）スレッショルド値より下ならば、入力の氏名構成要素は取り去られ る。 ステージロードプロセス１０２は、確認され標準化されたデータを、当座デー タ記憶装置１０８へ出力する。このことは、「データが最終ロードプロセス１１ ０へ送られる前に、ユーザーが、コンピュータシステム４０を使用して、データ を視認しかつ認可する」ということを可能にする。最終ロードプロセス１１０は 、データがクライアントデータベース５６へ加えられる前に、追加のデータ処理 をいくつか実行する。 最終ロードプロセス１１０は、クライアント照合アルゴリズム１１２を適用す ることを具備する。これらのクライアント照合アルゴリズム１１２は、「(提供 される)クライアント識別情報とデータとが、（クライアントデータベース内） 既存のクライアントと一致するか否か」ということを判断するために、適用され る(図５のステップ１２４)。図６は、「クライアント照合ルールがどのようにし て適用されるのか」ということを（より詳細に）図解するフローチャートである 。最初に、クライアントデータベース５６内の記録と入力データ内に含まれる情 報とに対して、クリティカル照合基準が吟味される。多数の異なる基準のそれぞ れに対する照合条件を示す値が割り当てられる(図６のステップ１３４)。 クリティカル照合基準は、社会保険番号照合（ＳＳＮ）基準１９を具備する。 社会保険番号照合基準に対する値は、”Ｙ”であってもよく、これは、「一致が 存在する」ということを示し、かつ、「入力データおよび(クライアントデータ ベース５６内の)記録は、共に、住居社会保険欄を具備する」ということを示す 。該値は、また、”Ｎ”であってもよく、これは、「一致が存在しないが、入力 データおよびデータベース記録は、社会保険番号値を具備する」ということを示 す。最後に、該値は、”Ｂ”であってもよく、これは、「入力データまたはデー タベース記録のうちの１つまたは両方は、社会保険番号値を具備しない」という ことを示す。 ラストネームは、ラストネーム照合（ＬＮＭ）照合基準に対する値を決定する ために比較される。ＬＮＭ基準に対する値”Ｙ”は、厳密な一致を示す。該一致 は、空白や特殊文字と識別されたミススペルと（結婚している女性のための）ハ イフン付ラストネームとを除外する。値”Ｎ”は、一致しないことを示し、かつ 、「ラストネームが、入力データとデータベース記録との両方において提供され る」ということを示す。 ファーストネームは、ファーストネーム照合（ＦＮＭ）基準のための値を取得 する際に、比較される。値”Ｙ”は、厳密な一致を示す。該一致は、等価なニッ クネームと省略と（識別された）ミススペルとを含む。厳密な一致は、また、（ 等価なニックネームと省略とを含む）ファーストネームの最初の文字が一致する 位置で発見される。但し、それは、入力データ（または、データベース記録）が ファーストネームを（イニシャルとして）有する場合のみである。最後に、もし 、 ファーストネームがニックネームテーブルエントリーと一致するならば、厳密な 一致が発見されることができる。値”Ｎ”は、「一致が存在しない」ということ を示し、かつ、「ファーストネームは、入力データおよびデータベース記録の両 方において指定される」ということを示す。 ミドルネームは、ミドルネーム照合（ＭＮＭ）基準に対する値を生成するため に比較される。ＭＮＭ基準は、値”Ｙ”を有してもよい。値”Ｙ”は、厳密な一 致と等価なニックネームと等価な省略とを示す。値”Ｎ”は、「一致が存在しな い」ということを示し、かつ、「ミドルネームは、入力データおよびデータベー ス記録の両方において指定される」ということを示す。値”Ｂ”は、「データベ ース記録内の入力データのうちの１つまたは両方が、ミドルネームを伴って占有 されない」ということを示す。 性別は、性別（ＧＤＲ）照合基準において比較される。値”Ｎ”は、「入力デ ータおよびデータベース記録の両方において、男性または女性またはカンパニー ジェンダー(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）に対して更新されることを可能 にされるか」ということを指定する。最後に、クライアント＿プロバイダ＿詳細 オーバーレイルールは、「データベース５６内のクライアントプロバイダ情報が どのようにしてオーバーレイされるべきか」ということを示す。 一旦、クライアントデータベース５６が更新されると、該変更は、クライアン トデータベース複製プロセス１１６によって複製されてもよく、かつ、（ＤＳＳ ２０によって管理される処理中データ記憶装置のための）データ収納設備へ送ら れてもよい。変更は、変更データキャプチャプロセス１１８によってキャプチャ される。変更データキャプチャプロセス１１８は、該変更を、ＤＳＳ２０のデー タ倉庫のデータ収納段階９６へ送る。 故に、ＣＡＲＭＡ１２は、（クライアントプロファイル管理のために）統合さ れたシステムを提供する。該クライアントプロファイル管理は、唯一無二の特徴 を多数提供する。ＣＡＲＭＡは、個々のクライアントを、電話番号やアドレスよ りも、むしろ、個人として追跡する。それによって、電話番号またはアドレスを 共有する複数のクライアントが追跡される。ＣＡＲＭＡ１２は、（クライアント 毎に複数のアドレス、および、クライアント毎に複数の電話番号を含む）多数の 関係を保持する。このことは、複数の電話番号またはアドレスを有するクライア ントの完全な追跡を容易にする。ＣＡＲＭＡ１２は、クライアントの追跡を継続 的に進行し、かつ、クライアントプロファイルへの変更を直ちに容易にする。Ｃ ＡＲＭＡ１２は、（全てのフォーマットにおける殆ど全てのタイプの入力データ を受け入れかつ使用するための）プロセッシング資源を具備する。更に、ＣＡＲ ＭＡは、クライアントプロファイルの複製を回避するために、効果的なクライア ント照合を実行する。 本発明が、本発明の好ましい実施形態を参照して説明されたが、当業者は、「 形 態および詳細における様々な変更が、添付された請求範囲に定義されたような本 発明の（意図された）範囲からはずれることなく、行われてもよい」ということ を認識する。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 スコット，ロブ アメリカ合衆国 コロラド 80919 コロ ラド スプリングス ヴァンス コート 8420 (72)発明者 ラ リュ，リサ ゴーリング アメリカ合衆国 コロラド 80919 コロ ラド スプリングス ダーク ホース プ レイス 7120 (72)発明者 ゼルトナー，ダン アメリカ合衆国 コロラド 80863 ウッ ドランド パーク モーニング スター サークル 22 (72)発明者 スミス，ラリー アメリカ合衆国 コロラド 80919 コロ ラド スプリングス オーク ヒルズ レ ーン 7125

Claims (1)

1. 【特許請求の範囲】 １． それぞれがマーケティングの接客のためのクライアントに関する情報を保 持している、クライアントプロファイルを保持するデータベースを持つコンピュ ータシステムにおける方法であって、 データプロバイダから与えられ、前記データベースに加えることが可能な、ク ライアントに関するデータを持つ入力データを受信する段階と、 前記入力データの中の全ての氏名情報と全ての住所情報を、前記選ばれたクラ イアント用の前記クライアントプロファイルの中の全ての氏名情報と全ての住所 情報と比較し、前記入力データが既に前記データベースにクライアントプロファ イルが入っている中から選ばれたクライアントのためのものであるかどうかを決 定する合致基準を適用する段階と、 もし、前記合致基準によって前記入力データが既に前記データベースにクライ アントプロファイルが入っている中から選ばれたクライアントのためのもので無 い場合は、前記入力データからデータを保持する上記データベース中に前記選ば れたクライアント用の新しいクライアントプロファイルを作成する段階と、 もし、前記合致基準によって前記入力データが既に前記データベースにクライ アントプロファイルが入っている中から選ばれたクライアントのためのものであ る場合は、前記入力データの視点で、前記選ばれたクライアント用の前記データ ベースの中の前記クライアントプロファイルをいかに更新するかを決定するオー バーレイ規則を適用する段階と、 前記オーバーレイ規則を適用して前記データベース中の前記クライアントプロ ファイルを更新するのに、いかに決定されたかに基づいて前記データベース中の クライアントプロファイルを更新する段階との、 コンピュータで実行される段階を含むことを特徴とする方法。 ２． 前記合致基準は、前記入力データ中の全ての社会保険番号情報を、前記選 ばれたクライアント用の前記クライアントプロファイル中の全ての社会保険番号 情報と比較することを特徴とする請求項１記載の方法。 ３． 前記合致基準は、前記入力データ中の全ての電話番号を、前記選ばれたク ライアント用の前記クライアントプロファイル中の全ての電話番号と比較するこ とを特徴とする請求項１記載の方法。 ４． 前記合致基準は、前記入力データ中の全ての口座番号を、前記選ばれたク ライアント用の前記クライアントプロファイル中の全ての口座番号と比較するこ とを特徴とする請求項１記載の方法。 ５． 前記合致基準は、前記入力データ中の全ての会員番号を、前記選ばれたク ライアント用の前記クライアントプロファイル中の全ての会員番号と比較するこ とを特徴とする請求項１記載の方法。 ６． 前記入力データを、前記合致基準を適用する前の標準フォーマットへとフ ォーマットする段階を、さらに含むことを特徴とする請求項１記載の方法。 ７． 前記合致基準を適用する前に、前記入力データ中の不要なデータを取り除 くためのデータ対ウィルス予防法を適用する段階を、さらに含むことを特徴とす る請求項６記載の方法。 ８． 前記合致基準を適用する前に、前記入力データ中の不要なデータを取り除 くためのデータ対ウィルス予防法を適用する段階を、さらに含むことを特徴とす る請求項１記載の方法。 ９． データプロバイダから与えられ、前記データベースに加えることが可能な 、クライアントに関するデータを持つ入力データを受信する段階と、 前記入力データの中の全ての氏名情報と全ての住所情報を、前記選ばれたクラ イアント用の前記クライアントプロファイルの中の全ての氏名情報と全ての住所 情報と比較し、前記入力データが既に前記データベースにクライアントプロファ イルが入っている中から選ばれたクライアントのためのものであるかどうかを決 定する合致基準を適用する段階と、 もし、前記合致基準によって前記入力データが既に前記データベースにクライ アントプロファイルが入っている中から選ばれたクライアントのためのもので無 い場合は、前記入力データからデータを保持する上記データベース中に前記選ば れたクライアント用の新しいクライアントプロファイルを作成する段階と、 もし、前記合致基準によって前記入力データが既に前記データベースにクライ アントプロファイルが入っている中から選ばれたクライアントのためのものであ る場合は、前記入力データの視点で、前記選ばれたクライアント用の前記データ ベースの中の前記クライアントプロファイルをいかに更新するかを決定するオー バーレイ規則を適用する段階と、 前記オーバーレイ規則を適用して前記データベース中の前記クライアントプロ ファイルを更新するのに、いかに決定されたかに基づいて前記データベース中の クライアントプロファイルを更新する段階との、 コンピュータが実行する段階を含む方法を実行するためのコンピュータで実行 される命令を備えたコンピュータ読み取り可能な媒体。 １０． コンピュータシステムにおける方法であって、 各クライアントプロファイルが、クライアントに関する情報を収めている、マ ーケティングの接客用クライアントプロファイルを記憶しているデータベースを 供給する段階と、 前記データベース内の、或る電話番号における第１のクライアントのための第 １のクライアントプロファイルを記憶する段階と、 前記データベース内の、或る電話番号における第２のクライアントのための第 ２のクライアントプロファイルを記憶する段階と、 クライアント単位でクライアントプロファイルにアクセスするためのデータベ ースを示す段階との、 コンピュータで実行される段階を備えた方法。 １１． 前記第１のクライアントプロファイルにアクセスする要求を受信する段 階と、前記要求に応えて前記第１のクライアントプロファイルへのアクセスを認 可する段階とを、さらに備えた請求項１０記載の方法。 １２． コンピュータシステムにおける方法であって、 各クライアントプロファイルが、クライアントに関する情報を収めている、マ ーケティングの接客用クライアントプロファイルを記憶しているデータベースを 供給する段階と、 前記選ばれたクライアントのためのクライアントプロファイル中の選ばれたク ライアント用のデータベースに第１のアドレスを記憶する段階と、 前記選ばれたクライアントのためのクライアントプロファイル中の前記選ばれ たクライアント用のデータベースに第２のアドレスを記憶する段階と、 要求者からの要求に応じて、前記選ばれたクライアントに対する前記第１のア ドレスと前記第２のアドレスの内の一つを前記要求者に与える段階との コンピュータで実行される段階を備えた方法。 １３． 前記方法は、或る与えられたクライアントのための、或る与えられたク ライアントプロファイル中の、前記与えられたクライアント用のデータベース中 の第１の電話番号を記憶する段階と、前記与えられたクライアントプロファイル 中の前記与えられたクライアント用のデータベース中の第２の電話番号を記憶す る段階とをさらに備えることを特徴とする請求項１２記載の方法。 １４． マーケティングの接客のためのクライアントに関する情報を保持してい る、クライアントプロファイルを保持するデータベースを持つコンピュータシス テムにおける方法であって、 第１のデータプロバイダからの第１のフォーマットによる入力データの第１の 組を受信する段階と、 前記入力データの第１の組を標準的フォーマットに再フォーマットする段階と 、 入力データの前記第１の組の中の少なくともいくつかのデータを、前記データ ベース中の第１のクライアントプロファイルに加える段階と、 第２のデータプロバイダからの第２のフォーマットによる入力データの第２の 組を受信する段階と、 入力データの前記第２の組を前記標準的フォーマットへと再フォーマットする 段階と、 入力データの前記第２の組の中の少なくともいくつかのデータを、前記データ ベース中の第２のクライアントプロファイルに加える段階との コンピュータで実行される段階を含むことを特徴とする方法。 １５． 前記第１のフォーマットと前記第２のフォーマットは異なることを特徴 とする請求項１４記載の方法。 １６． 入力データの前記第１の組は、入力データの前記第２の組の中のデータ とは異なるデータの種類のデータを含むことを特徴とする請求項１４記載の方 法。 １７． 前記第１のデータプロバイダは、前記コンピュータシステムの外部にあ ることを特徴とする請求項１５記載の方法。