(57)【特許請求の範囲】
【請求項１】
少なくとも一つのクライアント・コンピュータ上のデータ記憶システムに保管された複数のデータ要素を識別する方法において、識別された該データ要素のそれぞれが特定のエンティティに関するデータを含んでおり、前記方法は、
（ａ）前記クライアント・コンピュータが、該データ要素を含む転送ファイルを前記クライアント・コンピュータ上に作成するステップと、
（ｂ）前記クライアント・コンピュータが、該転送ファイルを、少なくとも一つのコンピュータ・サーバを含むリポジトリに送信するステップであって、該転送ファイルをリポジトリに送信する前記ステップは、前記クライアント・コンピュータと前記コンピュータ・サーバを接続するコンピュータ通信ネットワークによって行われ、少なくとも１つの識別クラスが該リポジトリに保管されており、各識別クラスが、
（ｉ）少なくとも１つのトークンであって、各トークンが、一意的な番号を含み、各トークンが、特定のエンティティを一意的に表わす、少なくとも１つのトークンと、
（ｉｉ）該トークンが表わす該エンティティに関連するデータ要素と
を含む、送信するステップと、
（ｃ）前記リポジトリが、前記転送ファイルの前記各データ要素とリポジトリの前記識別クラスの前記データ要素をソフトウエアによって比較することによって、該転送ファイル内の該データ要素のそれぞれを、該データ要素を含む該識別クラスにマッチさせるステップと、
（ｄ）前記リポジトリが、該転送ファイル内の該データ要素のそれぞれに、そのデータ要素にマッチされた該識別クラスに含まれる該トークンの少なくとも１つを書き込むステップと、
（ｅ）前記リポジトリが、該転送ファイルを、前記コンピュータ通信ネットワークを通じて、該データ記憶システムに送り戻し、前記転送ファイルから前記データ要素及びトークンを該データ記憶システムに保管するステップと、
（ｆ）前記データ記憶システムが、該データ記憶システムに保管された全てのデータにおいて、特定のエンティティに対応するトークンを検索することによって、該特定のエンティティに関する情報を含む全てのデータ要素を識別するステップと
を含む方法。
【請求項２】
該識別クラスのそれぞれに含まれるデータが、名前エイリアス、名前変更ヒストリ、住所エイリアス、住所変更ヒストリ、代替名前綴り、および一般名前誤綴りの少なくとも１つを含み、前記マッチさせるステップが、各データ要素に対応する該識別クラス内の名前エイリアス、名前変更ヒストリ、住所エイリアス、住所変更ヒストリ、代替名前綴り、および一般名前誤綴りの少なくとも１つへの該データ要素のマッチングを含む、請求項１に記載の方法。
【請求項３】
前記書き込むステップは、前記リポジトリが、消費者に関するデータを含む該データ要素のそれぞれに、該消費者を表わす該トークンの１つを用いて書き込むステップを含む、請求項１に記載の方法。
【請求項４】
前記リポジトリが、消費者に関するデータを含む該データ要素のそれぞれに、その消費者に関連する住所を表わす該トークンの少なくとも１つを用いて書き込むステップをさらに含む、請求項３に記載の方法。
【請求項５】
前記リポジトリが、住所に関するデータを含む該データ要素のそれぞれに、該住所を表わす該トークンの１つを用いて書き込むステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記リポジトリが、住所に関するデータを含む該データ要素のそれぞれに、その住所に関連する消費者を表わす該トークンの少なくとも１つを用いて書き込むステップをさらに含む、請求項５に記載の方法。
【請求項７】
前記リポジトリが、消費者に関するデータを含む該データ要素の少なくとも１つに、その消費者に関連する占有建物を表わす該トークンの少なくとも１つを用いて書き込むステップをさらに含む、請求項３に記載の方法。
【請求項８】
前記リポジトリが、消費者に関するデータを含む該データ要素の少なくとも１つに、その消費者に関連する世帯を表わす前記トークンの少なくとも１つを用いて書き込むステップをさらに含む、請求項３に記載の方法。
【請求項９】
前記識別するステップが、リアル・タイムで実行される、請求項１に記載の方法。
【請求項１０】
前記識別するステップが、単一のエンティティに関係するデータ要素を一時に集めることを含む、請求項１に記載の方法。
【請求項１１】
前記識別するステップが、消費者入力に応答して実行される、請求項９に記載の方法。
【請求項１２】
該消費者入力が、消費者購入およびインターネット・ウェブ・ページへの消費者アクセスの１つを含む、請求項１１に記載の方法。
【請求項１３】
（ａ）１つのトークンに合併されるべきすべてのトークンのリストおよび複数のトークンに分解されるべきすべてのトークンのリストの少なくとも１つを含む、トークン・メンテナンス・ファイルを前記リポジトリが作成するステップと、
（ｂ）該リポジトリから該データ記憶システムへ、コンピュータネットワークを使用して該メンテナンス・ファイルを前記リポジトリが送信するステップと、
（ｃ）該メンテナンス・ファイルを使用して、前記クライアント・コンピュータの該データ記憶システム内の該トークンを前記データ記憶システムが更新するステップと
をさらに含む、請求項１に記載の方法。
【請求項１４】
マッチされたデータ要素に対応する該識別クラスに含まれる追加データを、前記コンピュータ・サーバの該リポジトリから前記クライアント・コンピュータの該データ記憶システムに前記リポジトリが送信するステップをさらに含む、請求項１に記載の方法。
【請求項１５】
前記コンピュータ・サーバの該リポジトリから前記クライアント・コンピュータの該データ記憶システムに送られる該追加データが、人口統計データを含む、請求項１４に記載の方法。
【請求項１６】
前記コンピュータ・サーバの該リポジトリから前記クライアント・コンピュータの該データ記憶システムに送られる該追加データが、標準化された住所および完全な住所データの少なくとも１つを含む、請求項１４に記載の方法。
【請求項１７】
前記コンピュータ・サーバの該リポジトリから前記クライアント・コンピュータの該データ記憶システムに送られる該追加データが、標準化された名前、最も多く使用される名前、および形式的な名前データの少なくとも１つを含む、請求項１４に記載の方法。
【請求項１８】
前記マッチさせるステップおよび書き込むステップが、前記クライアント・コンピュータの該データ記憶システムと前記コンピュータ・サーバの該リポジトリとの間のＯＬＴＰリンクを介して実行される、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、類似するエンティティに関するデータをリンクするシステムおよび方法を対象とする。具体的に言うと、本発明は、永久的なユニバーサルに一意のトークンを使用して、消費者、会社、住所、占有建物、および世帯に関するデータをリンクするシステムおよび方法を対象とする。
【０００２】
（背景技術）
現在、ほぼ全ての会社が、カスタマ（顧客）に関する情報を含むコンピュータ化されたデータベースを保持することが必要であることに気付いている。そのような情報は、請求書送付、セールスおよび新製品についてカスタマに知らせ続けるなど、さまざまな形で使用することができる。この情報は、通常は、コンピュータ・データベース内の一連のレコードとして電子的に保管され、各レコードが、特定のカスタマに関係する。レコードとは、当技術分野で周知の複数の方法のいずれかでコンピュータ・データベース内で実施することができる論理構造である。使用されるデータベースは、フラット、リレーショナル、または複数の他の既知の形態のいずれかとすることができる。データベース内の各レコードに、カスタマの名、姓、住所、都市、州、および郵便番号などのさまざまなフィールドを含めることができる。レコードには、カスタマの結婚状況、推定所得、趣味、購入ヒストリ（履歴）など、より複雑な人口統計データを含めることもできる。
【０００３】
会社は、一般に、複数のソースからカスタマ・データを収集する。これらのソースは、カスタマ購入などの内部ソース、または情報サービス・プロバイダによって供給されるデータなどの外部ソースである可能性がある。多数の情報サービス・プロバイダが、会社に販売またはリースすることができる、幅広いベースのカスタマ情報を有する大規模データベースを維持しており、たとえば、カタログベースの小売り会社が、特定の地理的区域の潜在的なカスタマのリストを購入することができる。
【０００４】
会社は、カスタマ・データを収集するのに変化する方法を使用するので、カスタマに関する多量の情報を含む複数の大きいが完全に独立したデータベースを有することがしばしばである。これらの会社は、特定のカスタマに関する情報のすべてを正確にリンクする手段を有しない。この問題の一般的な例が、当座預金口座所有者および貯蓄預金口座所有者のデータベース、クレジット・カード所有者に関する別のデータベース、および投資クライアントに関する別のデータベースを維持する銀行である。もう１つの一般的な例が、たとえば自動車修理、改築、従来の小売り、ｅ−コマース、および検眼サービスを含めることができる、部署または分野のそれぞれをサポートする別々のデータベースを有する大規模小売業者である。
【０００５】
複数の独立したデータベースを有する会社は、そのカスタマのうちの誰が複数のサービスについて来店したかを知ることが特に貴重であると考える場合がある。たとえば、銀行は、貯蓄預金口座に１００ドルだけを維持しているカスタマが、１０万ドルの仲買口座を維持していることも判定できる場合に、この同一のカスタマに、より高度なバンキング・サービスの組を提供することを望む可能性がある。この情報は、たとえば、抱き合わせ売り込みの機会を利用し、会社が既存のカスタマ・ベースにもっともよいサービスを提供するためにサービスの組み合わせを最適化するのを支援するのに、貴重でもある可能性がある。
【０００６】
各カスタマに関係する使用可能なすべてのデータをリンクすることによって、会社の部署のそれぞれが、各カスタマに関する最新情報にアクセスできるようにもなる。たとえば、カスタマが、結婚し、引越し、その後、この変更に関して会社の部署の１つだけに通知する可能性がある。メンフィスに住んでいるＳｕｅ  Ｓｍｉｔｈが、ミネアポリスに住むＳｕｅ  Ｔｈｏｍｐｓｏｎになると仮定する。会社のデータ処理システムの１つだけが、この変化について「知っている」場合に、他のシステムは、ミネアポリスの「新しい」カスタマＳｕｅ  Ｔｈｏｍｐｓｏｎが、メンフィスの既存のカスタマＳｕｅ  Ｓｍｉｔｈと同一人物であることを判定することができない。
【０００７】
この問題と戦うのに使用された最も古い方法の１つが、単純にすべてのカスタマに番号を割り当て、その後、その番号を使用して、マッチング動作、検索動作、およびデータ操作動作を実行することである。大規模な社内カスタマ・データベースを維持する多くの会社が、この種のシステムを実施してきた。理論上、各カスタマ番号は、カスタマが名前または住所を変更した時であっても、各カスタマについて常に同一のままになる。これらの番号は、たとえば請求およびそのカスタマに出荷されたパッケージの追跡に、内部的に使用することができる。カスタマ識別番号を使用することによって、たとえばカスタマの名前および住所がその代わりに識別子として使用される場合の潜在的な曖昧さが除去される。特に金融機関が、個人識別番号（ＰＩＮ）を使用して、各トランザクションに関係する正しいカスタマを曖昧さなしに識別してきた。
【０００８】
カスタマ番号システムは、本来、ある応用例に制限されている。カスタマ識別番号は、常に変化する全国的な広範囲の名前および住所のリストを管理することを意図されたものではない。これらの番号を維持する会社は、一般に、その会社自体のカスタマとの関係を続けることだけに関心を持っている。したがって、そのような番号の割当処理は、非常に単純である。すなわち、カスタマが、取引をするつもりでその会社に近づく時に、新しい番号がそのカスタマに割り当てられる。カスタマ番号は、所与のカスタマの住所および名前のヒストリを管理できる、広いベースの処理の結果ではない。また、カスタマ番号は、番号を作成する会社に提示された情報だけに基づいて割り当てられる。この番号は、会社の日々のトランザクションとは独立に機能する複数ソースのデータ・リポジトリから割り当てられるのではない。要するに、そのような番号の目的は、汎用データ・リンケージではなく、単にトランザクション管理である。そのような番号は、通常はある無活動期間の後に会社によって廃棄されるので、真に永久的でもない。やはり、カスタマ番号割当方式の焦点が、単に内部ビジネス・トランザクションなので、トランザクションが進行中でない番号を永久的に維持する理由はない。これらの番号は、すべての会社が異なるカスタマ番号の組を維持するので、外部でデータにリンクするのに使用することができない。
【０００９】
外部から適用されるユニバーサル・ナンバリング・システムは、消費者には使用されてこなかったが、小売り製品と共に使用するために公に使用可能にされてきた。一般に「バー・コード」として既知のｕｎｉｖｅｒｓａｌ  ｐｒｏｄｕｃｔ  ｃｏｄｅ（ＵＰＣ）システムは、食品雑貨産業ですべての製造業者に共通するコーディング・システムの必要がみられた１９７０年代初期に開始された。現在、Ｕｎｉｆｏｒｍ  Ｃｏｄｅ  Ｃｏｕｎｃｉｌ、Ｉｎｃ．（ＵＣＣ）社が、小売り製品と共に使用されるすべてのバー・コードの割当の責任を負い、これによって、製造業者に無関係にすべての製品に一意のＵＰＣ番号が維持されている。これらのコードのデータベースが、公に使用可能にされ、その結果、このコードを誰もが使用することができる。このデータベースを使用して、すべての小売業者が、店の棚にある各製品に関する価格および他の情報を追跡することができる。現在の製品流通チェーンも、製品を追跡し、ロジスティックスおよび流通チャネルに関する決断を行うのに、ＵＰＣシステムに大きく依存している。
【００１０】
ＵＰＣシステムは、大成功を収めたが、このシステムの有用性は限られている。新製品のＵＰＣ番号を得るために、製造業者は、まずＵＰＣ番号について出願し、製品および番号が、ＵＣＣデータベースに追加され、その後、製造業者が、製品を配送する前に、適当なバー・コーディングを製品に適用する。先在する製品にＵＰＣ番号を割り当てる方式はなく、ＵＰＣ番号をそれが表す製品とマッチさせる方式もない。また、各ＵＰＣ番号が、小売り販売用にパッケージ化された単一の別個の品目を表すので、単一のＵＰＣ番号が割り当てられた特定の製品のさまざまな要素を識別する方式がない。したがって、ＵＰＣシステムは、消費者および住所に関係するさまざまな先在するデータをリンクするのに使用することができない。
【００１１】
個人に関する識別番号システムの使用によって持ち出される、最後の、きわめて重要な問題が、プライバシである。カスタマ識別番号のある会社の内部のみでの使用によって生じるプライバシの懸念事項はほとんどない。しかし、個人に関するカスタマ番号またはＰＩＮの外部での使用によって、個人のプライベート・データを無許可または不法な形で簡単に共用できる危険性が高まる。したがって、不正使用の可能性があるので、カスタマ番号システムは、全米の消費者人口に関係するデータの外部分散リンキング・システムを開発しようとする情報サービス・プロバイダにとって、受け入れ不能な解決策になる。
【００１２】
識別番号システムの制限を与えられて、重複を削除し、別々のデータベースで維持されるカスタマ・データをリンク（または「統合」）する唯一の包括的な方法は、歴史的に、関係するデータベースを一から再構築することであった。多数のそのようなデータベースに、数千万個のレコードが含まれるので、データベースを完全に再構築するコストは、極端に高くなることがしばしばである。さらに、これらのデータベースは、古いカスタマが去り、新しいカスタマがその位置を占め、カスタマ情報が変化するので、常に流動しており、したがって、すべての情報を適度に新しい状態に保つために、再構築手順を周期的に繰り返さなければならない。
【００１３】
会社は、従来、データ統合および重複除去サービスについて情報サービス・プロバイダに頼ってきた。情報サービス産業は、最近に、さまざまな「ｄｅｄｕｐｉｎｇ」ソリューションの開発に膨大なリソースをささげてきた。これらのソリューションは、事後すなわち、データ所有者のシステムに重複するエントリがインスタンス化された後に実行される。メンフィスのＳｕｅ  ＳｍｉｔｈとミネアポリスのＳｕｅ  Ｔｈｏｍｐｓｏｎのデータ・レコードが、同一の人物に関係するかどうかを判定するために、ｄｅｄｕｐｉｎｇルーチンによって、無数のデータ・フィールドを分析することができるが、単純に名前および住所を比較するだけでは、マッチを達成することはできない。名前および住所が同一の場合であっても、これが、それらのレコードが同一の個人に関係することを示していない場合がある。というのは、たとえば、そのデータが、父親と、その父と同名の息子に関係する場合があるからである。多数のデータベースに、不完全なデータが大量に含まれるという事実によって、この問題の解決がさらに困難になり、多くの場合に、完全な解決が不可能になる。
【００１４】
ｄｅｄｕｐｉｎｇルーチンは、必然的に複雑であるが、非常に高速に実行されなければならない。これらのルーチンは、数千万個のレコードを有するデータベースをｄｅｄｕｐｅするのに使用される。そのように大きいデータベースに関して、ｄｅｄｕｐｉｎｇ機能を実行するソフトウェア・サブルーチンは、単一のｄｅｄｕｐｉｎｇセッション中に数百万回呼び出される可能性がある。したがって、これらのサブルーチンは、ｄｅｄｕｐｉｎｇルーチンを正当な時間で完了するのに必要な能力を有する非常に高速で高価なコンピュータ機器で実行されなければならない。重複除去は、非常にリソース集中型なので、そのようなタスクは、現在、これらのルーチンを効率的に実行するのに必要な膨大なコンピューティング・パワーにアクセスできる情報サービス・プロバイダまたはデータ所有者のみによって実行される。
【００１５】
さらに、ｄｅｄｕｐｉｎｇルーチンは、必然的に多少の当て推量を伴う。上で説明したように、重複除去は、使用可能なデータに基づくが、そのデータが不完全である可能性がある。したがって、重複除去ルーチンの結果の良さは、使用可能な情報と同程度でしかない。名前および住所の情報には固有の曖昧さがあるので、カスタマ・データベース内で重複の１００％を除去できるシステムはない。不可避的に、結果のデータベースに、同一のカスタマに関する複数のレコードのインスタンスが含まれ、複数のカスタマが、単一のカスタマであるかのように１レコードにマージされる。
【００１６】
歴史的に、情報サービス・プロバイダが会社のデータベースを統合する手順は、時間がかかり、労働集約的である。さまざまなデータベース・フォーマットが使用されているので、情報サービス・プロバイダは、まず、データベース・ソース・ファイルを処理のための標準フォーマットに変換しなければならない。その後、情報サービス・プロバイダは、上で説明した複雑なｄｅｄｕｐｉｎｇプログラムの１つを実行する。会社のデータベース内のデータを、情報の外部ソースを用いて補足して、ｄｅｄｕｐｉｎｇルーチンの精度を改善することができる。その後、結果のデータベース・ファイルが、会社のデータベース・ファイル・フォーマットに再フォーマットされて、処理が完了する。この手順全体が、情報サービス・プロバイダの技術担当者によるかなりの直接のかかわりを必要とするが、これが、このサービスのコストの重要な要因である。
【００１７】
このデータ統合方法の重要な制限が、サービスが要求されるたびに、処理全体を繰り返さなければならないことである。データ統合は、１時に単一のレコードについて、または更新されたレコードだけについて、実行することができない。これは、データ統合処理が、データ・レコードのすべてを互いに比較して、類似するレコードのグループ化を確立することに依存するからである。マッチするリンクが、通常は比較処理中に作成されるが、これらのリンクは、一時的なものであり、処理が完了した後に失われる。これらのリンクは、サービスが実行されるたびに一から再作成されなけばならない。これらのリンクは、すべての可能なカスタマの母集団にまたがって一意ではなく、情報サービス・プロバイダによって維持されないので、再利用は不可能である。
【００１８】
現在のデータ統合方法の最も重要な制限の１つが、リアル・タイムで実行することができず、その処理がバッチ・モードでのみ実行されることである。リアルタイム・データ統合は、小売業者または他のデータ所有者が特定のカスタマに関する入力に対して即座にカスタマイズされた応答を提供できるようになるので、非常に望ましい。たとえば、特定のカスタマが小売業者のウェブ・サイトを訪れた時に、そのカスタマに関するすべての使用可能な情報をリンクし、そのカスタマの興味および必要に合わせて特に調整されたウェブ・ページを表示することが望ましい。もう１つの応用例は、小売り購入が進行中である時の特定のカスタマのクレジット・カードの「走査」に応答して、カスタマイズされたクーポンまたはセールス情報を提供することである。
【００１９】
カスタマ入力に対するカスタマイズされた応答を提供する従来技術のシステムは、内部カスタマ番号のマッチングに基づく。たとえば、ある食品雑貨店が、特定のカスタマを識別するバー・コードを含む「メンバ」カードを配布する。カスタマが、レジで自分のメンバ・カードを提示する時に、カードのバー・コードがスキャンされて、カスタマの識別番号が判定される。その後、食品雑貨店のデータ処理システムが、そのカスタマの特定の購入習慣に合わせて調整されたクーポンを印刷するために、その購入ヒストリ・データベースに自動的に問い合わせる。
【００２０】
内部カスタマ番号に基づく同時記録処理は、複数の重要な制限を有する。まず、このシステムは、番号が既に割り当てられている固定客についてのみ動作する。新しいカスタマが店に入る場合に、このシステムがそのカスタマを認識する前に、そのカスタマにメンバ・カード（および対応するカスタマ識別番号）を発行しなければならない。当初、食品雑貨店は、このカスタマについて何も知らない。さらに、このシステムでのカスタマ識別番号の使用によって、上で述べた個人的プライバシの懸念に起因して、これを外部で使用することが許容されなくなる。
【００２１】
従来のデータ統合方法のもう１つの制限が、カスタマに関するデータが変化した時に各カスタマについて会社が維持するデータをリモートで自動的に更新または「拡張」する手段が提供されないことである。データの更新または拡張を提供する従来のバッチモード方法は、面倒であり、開始から終了までに数週間を必要とする場合がある。まず、データ拡張を要求する会社は、カスタマ・データベース内のレコードごとに１エントリを含む「抽出ファイル」を作成する必要がある。この抽出ファイルは、磁気テープなどのコンピュータ可読媒体に保管され、この媒体が、拡張のために情報サービス・プロバイダに出荷される。さまざまなデータベース・フォーマットが使用されているので、情報サービス・プロバイダは、まず、処理のために、抽出ファイルを情報サービス・プロバイダの内部フォーマットに変換しなければならない。この標準化された版の抽出ファイルを使用して、情報サービス・プロバイダが、会社のデータベース内の情報を情報サービス．プロバイダが維持する情報のすべてと比較するソフトウェア・アプリケーションを実行する。その後、更新データまたは拡張データが、会社の標準化された抽出ファイルにオーバーレイされる。
【００２２】
このデータ更新および拡張方法の重要な制限が、データのわずかな部分に対する更新だけが必要な時であっても、会社のデータベースを再構築しなければならないことである。たとえば、小売業者が、毎月１回、そのカスタマ・データベース内の住所の更新を望む場合がある。ほとんどのカスタマは、１ヵ月の期間のそれぞれの中で住所を変更していないが、従来の更新方法は、少数の引っ越したカスタマをつかまえるために、小売業者がデータベースを完全に再構築することを必要とする。
【００２３】
これらの理由のすべてから、データ統合、更新、および拡張を改善し、同期記録リアルタイム・データ・リンクを実行し、プライバシの問題を引き起こさずに外部から使用することができる、曖昧さのないデータリンク・システムを開発することが望ましい。
【００２４】
（発明の開示）
本発明は、永久的な「トークン」を使用して、関係付けられたデータをマッチングするための曖昧なリンク付けスキームを作成するためのシステムおよび方法を対象とする。トークンは、特定のエンティティに関係するすべてのデータにタグを付けるために使用される一意の数として実施することができる。これらのトークンは情報サービス・プロバイダによって作成され、そのカスタマが使用するために外部に配布することができる。上述のカスタマ識別番号とは異なり、トークンの作成は、データ所有者にアプローチするカスタマに依存しない。トークンを作成する情報サービス・プロバイダは、米国の全住民に関係する情報を有するデータベースをメンテナンスすることができ、トークンのリストを最新に保つため、常に住民の住所、名前、状態、および他の人口統計的データの変更を監視する。新しいトークンは、新しいエンティティが識別されると割り当てられる。
【００２５】
各トークンの一意性を維持するため、トークンは単一の中央リポジトリによってのみ作成され、これは情報サービス・プロバイダによって運用される。一時トークンを最初に、新しいエンティティに出会うときに作成することができ、情報サービス・プロバイダが追加のデータを収集して、仮の新しいエンティティがまだデータベース内にないことを確認できるようにする。しかし、情報サービス・プロバイダが、エンティティが実際に新しいと確認した後、永久トークンが割り当てられ、これが、そのエンティティに関係するデータを常にリンクさせるために使用される。情報サービス・プロバイダの情報でさえ完全にはならないので、定期的にトークン・メンテナンスを実行することが必要である可能性があり、これは、２つ以上のトークンを単一のトークンに結合するか、あるいは単一のトークンを２つの異なるトークンに分割する形式において行われる。このプロセスは単に、合併かつ分割されたトークンのリストを発行することによって実行することができ、このリストがすべてのトークン・ユーザに伝送される。このメンテナンス方法により、トークンを最新に保つためにデータベースを完全に再処理する必要がなくなる。
【００２６】
トークンが、情報サービス・プロバイダによってメンテナンスされる中央リポジトリで作成されるので、曖昧さを、従来技術のシステムよりはるかに効果的に解決することができる。中央リポジトリは識別クラスを作成することができ、これは、情報がメンテナンスされる各エンティティに関係するすべての使用可能なデータを含む。識別クラスの目的は、特定のエンティティに関するすべての使用可能なデータを、適切なトークンを使用してリンクさせることである。この情報の多くを決して配布することができないとしても、なお、これをマッチング・プロセスにおいて使用して、データ統合、更新または拡張要求に応答して正しいトークンがカスタマのデータに割り当てられることを保証することができる。識別クラスは、名前エイリアス、共通名前スペルミス、姓変更ヒストリ、住所ヒストリ、通りエイリアス、およびマッチング・プロセスに有用な他の関連情報を含むことができる。識別クラス構造により、以前可能であったよりもはるかに正確なマッチングおよび「ｄｅｄｕｐｉｎｇ」が可能となり、たとえばわかっている名前エイリアスを使用することによって、中央リポジトリは、「Ｓｕｅ  Ｃ．Ｓｍｉｔｈ」、「Ｃａｒｏｌ  Ｓｍｉｔｈ」および「Ｓｕｅ  Ｔｈｏｍｐｓｏｎ」についてのカスタマの別々のデータベース・レコードがそれぞれ実際には同じ人物を指すことを認識することができ、単一のトークンを正確に割り当てて、この人物に関するすべての関連情報をリンクさせる。
【００２７】
トークンが永久的であり、ユニバーサルに一意であるので、トークンは特定のデータ・プロバイダによる使用または特定のマッチング・セッションに限定されず、その代わりに、トークンは具体的には関連データのいかなる所有者への外部配布のためにも意図され、決して満了しない。データ所有者がトークンを受信し、これらをその既存のデータにマッチングさせた後、トークンを使用して、多数の内部データベースからのデータを高速に比較、マッチング、探索かつ統合することができ、これはバッチ・モードまたはリアルタイムのいずれにおいても、１度にわずか１レコードを使用して行われる。
【００２８】
異なるタイプのトークンを使用して、たとえばカスタマ、ビジネス、住所、世帯および居住に関連するデータをリンクさせることができる。居住トークンは、カスタマまたはビジネス、および特定のカスタマが特定の時点に住む住所についての情報をリンクさせる。世帯トークンは、世帯を共有すると決定されるすべての人物についての情報をリンクさせる。何が「世帯」を構成するかの定義は、応用例によって変わる可能性がある。したがって、同時に使用される多数のタイプの世帯トークンが存在する可能性がある。一連のリンクされた住所トークンをさらに、個人の住所ヒストリをメンテナンスするために使用することができる。住所ヒストリを使用すると、個人の間の名前の類似性によって引き起こされた曖昧さをより容易に解決することができ、正しいトークンが住所の変更にも関わらずその個人のデータにタグ付けされる。
【００２９】
上述のように、従来技術の「ｄｅｄｕｐｉｎｇ」ルーチンは複雑で、リソース集中的であり、これはそれらが使用可能なデータに限定され、１００％の精度で実行できないからである。しかし、本発明では、新しいデータをデータ処理システムに追加することは、トークンを互いに対してマッチングさせることと同じ程度に簡単である。トークン・マッチングは計算的に簡単なプロセスであり、データがデータ処理システムにリアルタイムで追加されると実行できるものである。データ更新または拡張中に不注意の重複がデータベースに追加されないので、重複を除去するための定期的な努力が不要である。
【００３０】
本発明はまたトークンを使用して、多数のデータベースがメンテナンスされる場合のデータ統合のプロセスを大幅に簡素化する。特定のエンティティについて分かっているすべての情報が必要とされるとき、データ所有者は各データベースを、関心のあるエンティティに関連付けられたトークンによってリンクされる情報について探索するだけでよい。たとえば、その情報が別々のデータベース上でメンテナンスされている２人のカスタマが実際には同じ個人であるかどうかを決定するために設計された、複雑なマッチング・アルゴリズムを実行する必要はない。したがって、トークンにより、データ所有者はその物理的なリモート・データベースのそれぞれを、特定のエンティティについてのすべての情報に容易にアクセス可能である単一の「仮想」データベースであるかのように処理することができる。
【００３１】
また、データをリンクさせるためのトークンの使用により、データ拡張、データ統合、および関係するデータ処理に関係付けられたプライバシーの懸念も著しく低減される。適切なトークンがデータ所有者のデータにマッチングされた後、更新および拡張要求を情報サービス・プロバイダへ、単純にトークンのリストとして伝送することができる。トークン自体は、それらが関係するデータに関する情報を含んでいない。したがって、内々にこのような伝送を傍受するいかなる者も、その伝送からいかなるプライベートなデータも抽出することができなくなる。加えて、トークンは単にデータ・リンクであり、ＰＩＮまたはカスタマ識別番号ではないので、トークンの外部利用に関連する個人プライバシーの危険性が増すことはない。
【００３２】
さらに、トークンにより、カスタマ入力に応答して、すべての関連データの即時収集のためのリアルタイムの同時記録リンク付けが可能となる。特定のカスタマのためのすべてのデータを収集することによって、データ所有者は「トータル・カスタマ・ビュー」を構築することができ、これはたとえば、データ所有者とそのカスタマの間の対話をカスタマイズするために使用することができる。多数のデータベースを調べてすべての関連カスタマ・データを検索しなければならない場合、各データベースを単に、関連トークンにリンクされたデータについて探索するだけでよい。データ所有者はトークンを使用してそれ自体のデータのすべてをリンクさせることができ、あるいは情報サービス・プロバイダによってメンテナンスされたデータとリンクして、特定のカスタマに関係するそのデータを即時に拡張することができる。リンク付けプロセスは、カスタマ入力が受信された瞬間に実行されるので、検索されたデータが、もっとも最近更新された使用可能なカスタマ情報となる。データ所有者のデータベースと情報プロバイダのデータベースの間のリンケージを、リンク付けトークンを使用してＯＬＴＰ（ｏｎ−ｌｉｎｅ  ｔｒａｎｓａｃｔｉｏｎａｌ  ｐｒｏｃｅｓｓｉｎｇ）によるものにすることができる。このリンケージはまた、「トリガ通知」を実行するために使用することもできる。トリガ通知は、特定のエンティティについての新しい情報が受信されたときの、あらゆるリンク付けされたデータベースへの更新メッセージの自動トリガリングである。トークンを使用して、トリガ通知をほぼ瞬時に行うことができ、たとえば、大規模な小売店のあらゆる部門が、カスタマから受信された最新情報を利用できるようになる。
【００３３】
同時記録処理のもう１つの利点は、データを情報サービス・プロバイダからそのカスタマに「プッシュ」できることである。たとえば、情報サービス・プロバイダは、特定の個人の名前が変更になったことを知ることができる。この変更を、カスタマのデータベースに自動的に「プッシュ」することができ、これは新しい情報を含むメッセージ、および、この個人に関係するすべてのデータをリンクさせるために使用されたトークンの使用を介して行う。更新プロセスにはトークンのマッチングのみが必要であるので、プロセスを自動的に、情報サービス・プロバイダまたはそのカスタマが直接介入することなく実行することができる。
【００３４】
情報サービス・プロバイダによるデータの外部配布に関連して生じる１つの懸念は、ある会社のデータをその会社の競争他社に不注意に配布することである。たとえば、会社Ａが自社データを、トークンを使用してリンクさせたいと望む可能性がある。情報サービス・プロバイダはすでにそのマッチング・データベースにおいて、会社Ａの競争他社である会社Ｂから得られた会社Ａのカスタマについての情報を有している可能性がある。情報サービス・プロバイダは会社Ｂに、そのプライベートなデータが会社Ａに配布されないことを保証できなければならない。しかし、本発明におけるトークンの使用により、この「スクリーニング」プロセスが自動になる。情報サービス・プロバイダは両方の会社のデータを、その内部トークン作成およびリンケージ・プロセスの一部として使用することができる。しかし、ある会社から受信された情報のみを、リンクされたトークンと共に戻すことによって、トークンを受信する会社はそれが所有するもの以外のいかなる者のデータも得ることはない。トークン自体はプライベートな会社情報を示さないので、別々の「スクリーニング」機能を実施する必要はない。また、情報サービス・プロバイダはすべての使用可能なデータを使用してトークンを生成かつリンクさせるので、正しいトークンをなお、互換性がないかあるいは部分的に不正確なデータを有する会社に配布することができる。
【００３５】
したがって、本発明の目的は、永久トークンを使用するデータ処理システムを提供することである。
【００３６】
本発明のさらなる目的は、ユニバーサルに一意であるトークンを使用するデータ処理システムを提供することである。
【００３７】
本発明のなおさらなる目的は、トークンを使用した多数の内部データベースに渡るデータの統合に備えることである。
【００３８】
本発明の目的はまた、トークンを使用したデータベースにおける自動重複除去に備えることである。
【００３９】
本発明のもう１つの目的は、トークンを使用したデータ更新および拡張に備えることである。
【００４０】
本発明のなおもう１つの目的は、トークンを使用したデータのリアルタイムの同時記録処理を提供することである。
【００４１】
本発明のなおもう１つの目的は、トークンを使用した、リアルタイムの、物理的に分離したデータベースからのトータル・カスタマ・ビューの作成のためのリンケージ能力を提供することである。
【００４２】
本発明のなおもう１つの目的は、トークンを使用してリアルタイムに、カスタマ入力に対してカスタマイズされた応答を作成することである。
【００４３】
本発明のなおもう１つの目的は、トークンを使用したトリガ通知を実行することである。
【００４４】
本発明のなおもう１つの目的は、トークンを使用して中央リポジトリからカスタマ・データベースへ更新データを自動的にプッシュすることである。
【００４５】
本発明のさらなる目的および利点は、以下の好ましい実施形態の詳細な説明を、以下に簡単に記載するような添付の図面と共に考察することから明らかになるであろう。
【００４６】
（発明の最良の実施形態）
このとき図１を参照して、本発明の好ましい実施形態で使用されるトークンの構造を示す。各トークン１０を、電子的に数またはコードとして格納することができる。トークン１０は、プレフィックス１２および一意の数１４からなる。プレフィックス１２は０と２５５の間の１０進数の値を有することが好ましく、したがって、コンピュータ記憶媒体上で単一のバイトによって表すことができる。プレフィックス１２の値は、トークン１０がすべての関連情報をリンクさせるエンティティのタイプを表す。たとえば、プレフィックス１２の「２５４」という値は、トークン１０がカスタマについての情報をリンクさせるために使用されることを指示することができ、「２５３」というプレフィックスの値は、トークン１０が住所についての情報をリンクさせるために使用されることを指示することができる。
【００４７】
一意の数１４は、コンピュータ記憶媒体上で４バイトによって表すことができることが好ましく、したがって、０と４，２９４，９６７，２９４の間の１０進数の値を有することができる。一意の数１４は、同じプレフィックス１２を有する各トークン１０について一意でなければならず、どのトークン１０も他のいかなるトークン１０とも等しくならないようにしなければならない。一意の数１４は、カウンタを使用して生成され、順次新しいトークン１０に、それらが生成されるときに割り当てられることが好ましい。いかなる代替方法を使用しても、各トークン１０の一意性が維持される限り、一意の数１４を生成することができる。
【００４８】
代替実施形態では、プレフィックス１２および一意の数１４をいかなるサイズにすることもでき、いかなる順序で結合してトークン１０を形成することもできる。本発明は、プレフィックス１２が必ず一意の数１４に先行するトークン１０に限定されることはなく、「プレフィックス」という用語がこのような狭い様式に読まれるべきではない。トークン１０はまた追加のフィールドを含むこともできる。
【００４９】
図２は、消費者、住所および居住トークンの間の関係を、特定の実施例を使用して例示する。テーブル１６は、夫および妻に関係するデータを示し、最初の２行は、彼らがデンバーに住んでいるときの名前および住所データを示し、最後の２行は、彼らがマイアミに引っ越した後の名前および住所データを示す。（この実施例では明確にするため、各トークン１０の一意の数１４の短縮部分のみを示す）。消費者トークン列１７は、これらの各人物が引っ越すときに消費者トークンが変わらないことを説明する。しかし、これらの人物は、住所トークン列１８に示すように新しい住所トークンに関連付けられる。居住トークン列１９は、これらのトークンがこれらの各人物および特定の期間の彼らの住所についての情報をリンクさせるために使用されるとき、居住トークンの関連付けも変わることを説明する。
【００５０】
データ所有者がそのデータを、トークン１０を使用してリンクさせることができるようになる前に、トークン１０を、関心のあるデータベース上のデータに関連付けなければならない。この最初の関連付けは、情報サービス・プロバイダによって実行される。各トークン１０を適切なデータに関連付けることに加えて、このプロセスを、関連データベース・ファイルにおける重複を除去するために使用することができる。このとき図３を参照して、このプロセスの概観を例示する。入力ファイル２０が生成され、これはデータ所有者がメンテナンスする関連データベース・ファイルからの各レコードを含む。入力ファイル２０は単一のデータベースから、あるいは独立してメンテナンスされる多数のデータベースから引き出すことができる。例示した実施例における入力ファイル２０は、別々にメンテナンスされる３つのデータベースから引き出される、同じ顧客についての情報を示す。この実施例では、名前および住所に基づいた単純なマッチングにより、これが同じカスタマであることを解決できなくなり、これはカスタマが引っ越しており、かつこれらの別々のデータベースがレコードを保持していた期間中に自分の名前を変更しているからである。しかし、リポジトリ２４を使用することによって、情報サービス・プロバイダは、これらの各レコードが単一のカスタマに関係するデータを含むと決定することができる。したがって、結果ファイル２６における各レコードがこの消費者についての同じトークン１０を含み、データ所有者はこのとき、この消費者に関するそのデータのすべてに、単にこの特定のトークン１０によってリンクされたすべてのデータを探索することによって、アクセスできるようになる。
【００５１】
このとき図４を参照して、トークン関連付けプロセスのより詳細な説明を例示する。トークン関連付けプロセスの最初のステップは、入力ファイル２０を上述のように形成することである。次いで、入力ファイル２０がマッチング・ソフトウェア２２に送り込まれ、これは情報サービス・プロバイダによってメンテナンスされたコンピュータ装置上で実行することができるが、データ所有者の所有する装置上で実行することもできる。次いで、マッチング・ソフトウェア２２が、入力ファイル２０からのデータをリポジトリ２４からのデータと比較して、マッチングを発見する。
【００５２】
リポジトリ２４は情報サービス・プロバイダによってメンテナンスされ、全国的な規模における消費者および住所に関する広範囲の情報を含む。リポジトリは単一の物理データベースにすることができ、あるいは、通信ネットワークによってリンクされた、物理的に独立したいくつかのデータベースからなる可能性がある。リポジトリ２４は、米国または他の関心のある地域に住む、実質的にすべての消費者に関係する情報を含む。
【００５３】
このとき図５を参照すると、情報がリポジトリ２４に識別クラス３０の形式で格納される。各識別クラス３０が、特定の個人に関して使用可能なすべての情報を含み、これが、消費者トークン２６を使用してリンクされる。特に、識別クラス３０は、個人によって使用された現在および以前の名前のリストである名前ヒストリ３２、個人が住んでいた住所のリストである住所ヒストリ３４、および特定の期間に渡る各名前／住所の相関に関連付けられた居住トークン２１を含む居住ヒストリ３６を含むことができる。住所ヒストリ３４を使用して居住ヒストリ３６を構築することができ、これは上述のように、居住が、個人の特定の時点の名前およびその個人がその時点に住んでいた住所の組み合わせであるからである。住所ヒストリ３４は、住所ヒストリ３４における各住所についての住所トークン２８も含むことができる。名前ヒストリ３２および住所ヒストリ３４により、マッチング・ソフトウェア２２がデータとトークン１０の正しいマッチングを、個人が自分の名前および住所を変更しているときでさえ、実行することができる。識別クラス３０は、それが関係する特定の個人に関する様々な種類の人口統計的情報も含むことができる。この追加の情報を、マッチング・ソフトウェア２２によって比較のために使用することもできる。識別クラス３０は共通名前および住所スペルミスも、名前ヒストリ３２および住所ヒストリ３４の一部として、あるいはそれらとは別々に含むことができる。
【００５４】
再度図４を参照して、マッチング・ソフトウェア２２がマッチング・プロセスを完了した後に、トークンを入力ファイル２０において対応するデータに添付するプロセスを記載する。上で説明したように、各識別クラス３０は、消費者トークン２６および少なくとも１つの住所トークン２８を含む。（識別クラス３０が過去の住所を住所ヒストリ３４において含み、追加の住所トークン２８をこれらの過去の住所にリンクさせることができる。）マッチング・ソフトウェア２２の実行の結果として、入力ファイル２０が再書き込みされて、正しい消費者トークン２６および住所トークン２８が各レコードの部分として含まれる。結果ファイル２９は、消費者トークン２６および住所トークン２８が増加された入力ファイル２０からなり、次いでこれがデータ所有者に戻される。重複除去はこのプロセスにおいて自動的に実行され、これは結果ファイル２９が、同じ個人を指す情報を含む各レコードについての等しい消費者トークン２６を有するようになるからである。たとえば、結果ファイル２９は「Ｊａｍｅｓ  Ｌ．Ｓｍｉｔｈ」および「Ｊｉｍｍｙ  Ｌ．Ｓｍｉｔｈ」についてのレコードを含むが、各レコードが同じ消費者トークン２６とマッチングされるので、データ所有者がこのとき容易に、両方のレコードが同じカスタマを指すと決定することができる。
【００５５】
入力ファイル２０および結果ファイル２９は、電子ファイルの伝送に適したいかなる方法においても伝送することができる。好ましくは、ファイルをデータ所有者と情報サービス・プロバイダの間で、ＦＴＰ（ファイル転送プロトコル）技術を使用して、遠隔通信ネットワークを介して伝送することができ、あるいは、磁気テープまたはディスクなど、電子的記憶媒体上に物理的に伝送することができる。マッチング・ソフトウェア２２はマッチングのために、入力ファイル２０自体内に含まれた類似性ではなく、リポジトリ２４における総合的なデータに依拠するので、入力ファイル２０の最低サイズにおける制限はない。入力ファイル２０は単一のレコードと同じほどに小さくすることができ、マッチング・プロセスの精度において損失がない。
【００５６】
このとき図６を参照して、本発明を使用して住所の誤りを解決するための特定の実施例を記載する。誤った入力データ４０は、夫および妻についての名前および住所情報を含む。誤った入力データ４０は、夫に関係する誤字を含み、番地「２１０」が「１２０」に置き換えられている。配達地図４６に示すように、番地「１２０」は実際には存在しない。住所は有効であるが、この特定の消費者については不正確であるので、この誤りは通常解決することが困難となり、たとえば、単にこのデータをマスタ住所に対してマッチングさせることによって誤りが明らかにはならない。加えて、リポジトリ・データ４２が正しいデータを含むとしても、トークンなしでデータをマッチングさせることは困難となり、これは「１２０」の番地が、識別クラス３０に格納された夫の住所ヒストリの一部ではないからである。
【００５７】
しかし、本発明によるトークンを使用すると、誤字を有するデータをマッチングさせる問題を、マッチング・ソフトウェア２２を使用して解決することができ、これはマッチング・ソフトウェア２２がその機能を、名前または住所だけではなく居住のマッチングに基づいて実行するので、誤字がマッチング・プロセスにおいて無視されるからである。これにより、誤字にも関わらず、結果データ４９を正しいトークンと共に戻すことが可能となる。類似の方法で、マッチング・ソフトウェア２２はリポジトリ２４における総合的なデータを利用して、住所エイリアス、多数の正しい通り名、および共通スペルミスなど、他の住所の問題を解決することができる。別法として、リポジトリ２４で発見されたような訂正された住所情報を含む結果データ４９を、トークンのリンク付けに基づいて送達することができる。加えて、結果データ４９を、入力データ４０から失われる追加の住所情報と共に送達することができ、これはたとえば、誤った入力データ４０に含まれていなかったアパートメント番号などである。
【００５８】
識別クラス３０に格納された住所トークンを使用することによって、本発明を使用してハウスホールディングを実行することができる。多数のデータ処理システムの所望の目的は、何名のカスタマが同じ世帯を共有するかを決定することである。世帯の定義はビジネスによって変わる可能性がある。あるビジネスでは、世帯を、単一のアドレスに住む普通の家族として定義する可能性がある。別のビジネスでは、２人の血縁でないルームメートを単一の世帯と見なす可能性がある。なお別のビジネスでは、別々の住所に住む、法律上は分かれているカップルを、いくつかの場合に単一の世帯として、他の場合に別々の世帯として処理する可能性がある。
【００５９】
識別クラス３０を使用して共通住所トークン２８を異なるカスタマに、通り名エイリアスおよび他の問題にも関わらず、図５および図６に例示したように割り当てることにより、ハウスホールディング・データの精度が著しく向上する。世帯のもっとも共通の定義、すなわち、同じ住所に住む人物ということを使用することにより、ハウスホールディングを、単に共通住所トークン２８を有するすべてのデータにアクセスすることによって実行することができる。ハウスホールディングの概念を他の定義に拡張することができ、これはリポジトリ２４上の識別クラス３０を、識別クラス３０に含まれた他の目標データに基づいてリンクさせることによって行い、これは分離された家族、ルームメート／親類の区別、共通の姓の結果となる名前変更、および類似の問題に直接関係のあるものである。異なるプレフィックス１２を有するトークン４０を使用して、各世帯定義に従ってデータをリンクさせることができる。たとえば、「２５０」のプレフィックス１２を、世帯の伝統的な定義に従ってすべてのデータをリンクさせるために使用されるトークン１０について使用することができ、「２４９」のプレフィックス１２を使用して、世帯のルームメート／親類の定義に従ってすべてのデータをリンクさせることができる。このようなトークン１０を、図４に示すように、結果データ４９における各レコードについての追加のリンクされたトークンとして戻すことができる。
【００６０】
このとき図７および図８を参照して、本発明の好ましい実施形態によるトークン・メンテナンスを実行する方法を記載する。リポジトリ２４は関心のある全住民（たとえば、米国における消費者）についての総合的な情報を含むが、このようなすべての人物に関するすべての所望の情報を含むことはとてもできず、これはこのような情報が常に変化し続けているからである。リポジトリ２４に新しい消費者および住所が提示されると、これはトークンを割り当てて、これらのエンティティに関連した情報をリンクさせなければならない。しかし、より多くの情報が後にそのエンティティについて収集されると、そのエンティティが実際には、すでにわかっていた古いエンティティであるが、リポジトリ２４における使用可能な情報に基づいて、単一のエンティティに解決できなかったものであるということが起こる可能性がある。この問題の解決策は、２つのトークンを単一のトークンに合併することである。同様に、類似の問題が、２つのエンティティが不正確に単一のエンティティに解決され、後に、リポジトリ２４がこれらを２つの別々のエンティティとして、２つの別々の識別クラス３０を使用してメンテナンスするべきであると決定されるときに起こる。この問題の解決策は、新しいトークンを割り当てて、分離したトークンを、データを２つの各エンティティにリンクさせるために使用できるようにすることである。
【００６１】
トークン合併および分割のプロセスでは、すでにトークンが供給されているデータ所有者がデータベースを再構築あるいは「リトークナイズ」する必要はない。その代わりに、これらのデータ所有者には単に、トークン更新のテーブルを含む電子ファイルが提供される。たとえば、図７に例示するように、リポジトリ２４は、第１の消費者５０および第２の消費者５２のための識別クラス３０をメンテナンスする。これらの２人の消費者は、それらに関連するデータをリンクさせるために割り当てられた、異なる消費者トークン「１００」および「１５０」を有する。次いで、新しい結合データ項目５４がリポジトリ２４に入力され、これが、第１の消費者５０および第２の消費者５２が実際には同じ消費者であることを指示すると仮定する。その結果は、これらの２人の消費者についての識別クラス３０を単一の識別クラス３０にマージすることであり、これが消費者５６に関連するすべての情報を含む。単一の消費者トークン「１００」がこのときこの情報のすべてをリンクさせるために使用される。他のトークン「１５０」がこのとき永久的にすべてのトークンのセットから退けられる。
【００６２】
この変更に関するデータ所有者を更新するため、情報サービス・プロバイダが合併メッセージ５８を送信する。合併メッセージ５８はデータ所有者に、退けられたトークン「１５０」をこのとき、それが生じるところで、この消費者に関して使用されていたトークン「１００」で置き換えなければならないことを通知する。このときデータ所有者は単に、退けられたトークンのすべての発生を探索してこれを新しいトークンで置き換えるソフトウェア・ルーチンを実行するだけでよい。情報サービス・プロバイダは合併メッセージ５８を、結合データ項目５４が受信されるとすぐに送信することができ、あるいはそれが定期的な合併メッセージ５８を送信することができ、これが最後の合併メッセージ５８が送信されて以来起こったすべてのトークン合併を反映する。
【００６３】
このとき図８を参照して、トークン分割を実行するためのプロセスも例として例示する。リポジトリ２４は最初に、消費者５６が単一の個人であるという情報を含み、そのためのすべての関連情報が識別クラス３０に含まれ、これにはこの消費者に関連するデータをリンクさせるために使用された単一の消費者トークン２６が含まれる。次いで、結合データ項目５４がリポジトリ２４によって受信されるが、この場合、結合データ項目５４は、消費者５６が実際には２つの異なる消費者であることを指示する。次いで、ソフトウェア・ルーチンが実行されて、消費者５６についての識別クラス３０が２つの識別クラスに分割され、一方は第１の消費者５０、他方は第２の消費者５２についてのものである。既存の消費者トークン２６を使用して、これらのエンティティのうち一方に関連するデータをリンクさせることができるが、新しい消費者トークン２６を、他方の消費者に関連するデータをリンクさせるために割り当てなければならない。
【００６４】
トークン分割に関するデータ所有者に通知するため、分割メッセージ６８が、合併メッセージ５８について上述したものと同様の方法で発行される。分割メッセージ６８および合併メッセージ５８をマージして単一のメッセージを形成することができ、これが定期的にデータ所有者に送信される。しかし、分割の場合は追加の情報が必要とされ、これはデータ所有者が、どのデータが古い消費者トークンを保持するか、およびどのデータが新しい消費者トークンでタグ付けされるかを知らなければならないからである。再処理が、特定の居住が新しいトークンでタグ付けされるかどうかを決定するために必要となる。
【００６５】
このとき図９を参照して、本発明の好ましい実施形態を使用してデータ更新を実行する利点を記載する。本発明をデータ所有者のデータ処理システムに適用するための最初のステップは、トークン１０をデータ所有者のデータ上に、上で説明したようにオーバーレイすることである。図９の実施例では、カスタマ・データ７０が、物理的に独立した４つのデータベースからのレコード、合計２３００万件のレコードを含む。カスタマ・データ７０が、合併プロセス７２およびトークン割り当て７４に入力される（これらのプロセスはマッチング・ソフトウェア２２によって、上述のように、リポジトリ２４からのデータに基づいて実行される）。別法として、合併プロセス７２をスキップすることができ、データをカスタマ・データ７０における各ソースから直接トークン割り当て７４に送ることができる。修正されたカスタマ・データ７０は、各レコードにトークン１０が追加されており、カスタマ・ファイル７６となる。この最初の構築はリソース集中的であり、これは、データ所有者のデータのすべての２３００万件のレコードを処理して最初にトークン１０をカスタマ・データ７０に割り当てなければならないからである。
【００６６】
このとき、データ所有者が毎月そのデータを更新することを望むと仮定する。すべてのカスタマ・データ７０を再処理するのではなく、更新データ７８のみを処理する必要がある。更新データ７８は、データ所有者が前月に獲得した新しいデータを表す。このデータは、たとえば、データ所有者が前月中に獲得した新しいカスタマにすることができる。図９の実施例では、更新データ７８が２つの異なるデータベースからの１５０万件のレコードのみを含む。更新データ７８は、合併プロセス７２およびトークン割り当て７４に（あるいは直接トークン割り当て７４に）、上述のように最初の構築に関して入力され、次いでカスタマ・ファイル７６と統合される。合併プロセス７２およびトークン割り当て７４がリポジトリ２４における情報に基づいており、すべてのカスタマ・データ７０に渡る名前および住所の比較には基づかないので、ファイル全体を再処理して更新手順を実行する必要はない。
【００６７】
本発明は、更新を、毎月、毎日、あるいは新しいレコードが受信されるときにリアルタイムでさえ、望む頻度で実行できることを企図する。マッチングに必要なすべての情報がリポジトリ２４に含まれており、したがってカスタマ・データ７０が相互比較のために使用されないので、更新データ７８を単一のレコードと同じほどに小さいファイルにすることができる。リアルタイム更新環境では、新しいレコードが受信されるちょうどそのとき、それが更新データ７８として情報サービス・プロバイダに送信され、これが即時にマッチング・ソフトウェア２２を実行して合併プロセス７２およびトークン割り当て７４を実行し、それによりカスタマ・ファイル７６のリアルタイム更新を可能にする。より頻繁な更新により、各更新の量が減り、それにより大規模な更新の頻繁な処理が減ることによって、計算リソースのボトルネックが軽減される。加えて、より頻繁な、あるいはリアルタイムの更新によっても、データ所有者がそのすべてのカスタマに関するもっとも正確な情報をメンテナンスすることが可能となる。
【００６８】
リンク付けトークンがデータ所有者のデータベースに配置された後、本発明の好ましい実施形態による１つの応用例はデータ統合である。今日、多数のビジネスが、「カスタマ関係管理」（ＣＲＭ）プランを実施することが有利であることを発見している。ＣＲＭプランの目標は、ビジネスがいかなる特定の顧客とのその関係をも完全に理解することである。ＣＲＭでは、ビジネスが各カスタマについてわかっているすべての情報を、このような情報が内部ソースから導出されるか外部ソースから導出されるかに関わらず、統合することを必要とする。この統合された情報がリアルタイムで使用可能となり、ビジネスがいかなる所与のカスタマによって開始された対話にも即時に応答できるようにすることが理想的である。ＣＲＭはたとえば、カスタマが関心のあるすべての製品および製品群を知ること、ビジネスの様々な部門のすべてでのカスタマの購入ヒストリを知ること、およびカスタマの関連の人口統計的（またはビジネスの場合、ｆｉｒｍｏｇｒａｐｈｉｃな）情報を知ることを含む可能性がある。このタイプの情報を使用して、ビジネスは、特定のカスタマの関心に合わせて特に調整される販売およびマーケティング努力を通じて、カスタマによりよくサービスできることを発見する。カスタマもこのプロセスが望ましいことを発見し、これはカスタマが関心のある製品およびオファーに変更されるが、カスタマが関心を表していない製品またはサービスを購入するように勧誘されないからである。
【００６９】
成功するＣＲＭプランの重要な要素は、いかなる特定のカスタマにも関する「トータル・カスタマ・ビュー」の作成である。トータル・カスタマ・ビューは、ＣＲＭを容易にする方法において配列された、いかなる数の異種情報ストアからの、カスタマについてのすべての関連情報の同化からなる。トータル・カスタマ・ビュー・システムを構築しようと試みるビジネスが直面する主要な障害は、ビジネスの情報ストアが通常は、同じカスタマについて、等しく一貫性がなく、正確でなく、最新でない重複情報を含むことである。結果として、同じ個人に関する情報が多数のデータベースまたは様々な矛盾を有する情報ストアに存在する可能性がある。これらの各データ・ストアは異なるカスタマ・ナンバリング・スキームを使用することができ、あるいは、名前および住所マッチングにのみ依拠する可能性があるので、内部情報のみを使用してこのデータのリンクを成功させることは困難であり、高いレベルの精度により実行することができない。
【００７０】
図１０は、この問題の例示的実施例を提供する。会社データ・テーブル８０の各行は、小売店の様々な部門のうちの１つによってメンテナンスされた、異なるデータベースからプルされたレコードを表す。会社データ・テーブル８０の各列は、これらのレコードにおける特定のフィールドを表し、これらは名前、住所およびカスタマの口座番号などである。この場合、情報が、小売店によってメンテナンスされた４つの異なるデータベースからプルされ、これらは自動車サービス、ホーム・サービス、小売販売およびスポーツ用品「専用メーリング・リスト」である。各データベースからのレコードが実際には同じ個人を表すが、名前のスペリングにおける変化、個人の住所変更、および各部門によって使用された異なる口座番号により、内部生成されたマッチング・ルーチンを使用してこのデータを共にマッチングさせることが不可能となる。したがって、小売店は、これが４人の異なる個人ではなく単一の個人であると決定することができなくなり、したがって、正確なトータル・カスタマ・ビューを構築することができなくなる。
【００７１】
このとき図１１を参照して、この情報をマッチングさせるためにトークンを使用した結果を、リンクされたデータ・テーブル９０と共に例示する。リンクされたデータ・テーブル９０において、会社の様々なデータベースにおける各レコードに適切なトークンが増加されている。リポジトリ２４は、カスタマＷｉｌｌｉａｍ  Ｆ．Ｓｍｉｔｈについての様々な名前のスペリングおよび住所ヒストリのすべてを含み、これらの各レコードが同じ個人を指す情報を含むと決定できるようになる。レコードに適切なトークンが「タグ付け」された後、小売店は高速かつ容易にこの個人に関するそのデータのすべてを、単純なトークン・マッチング・プロセスを介して、リンクさせることができる。小売店はまた、外部の情報サービス・プロバイダによってメンテナンスされるこのカスタマについての情報にも高速かつ容易にリンクすることができ、それにより小売店のデータの更新または拡張が可能となる。
【００７２】
このとき図１２を参照して、カスタマＷｉｌｌｉａｍ  Ｆ．Ｓｍｉｔｈについてのトータル・カスタマ・ビューを構築する方法を例示する。小売店の各部門によって累積された情報は、Ｗｉｌｌｉａｍ  Ｆ．Ｓｍｉｔｈについての消費者トークン２６でタグ付けされており、この情報がホーム・サービス・データベース１００、小売販売データベース１０２および自動車サービス・データベース１０４に含まれている。インタラクティブ・データ・アクセス・ルーチン１０９を使用することによって、小売店がカスタマＷｉｌｌｉａｍ  Ｆ．Ｓｍｉｔｈに関連するすべてのデータを探索することができ、これはそのデータをリンクさせるために使用された消費者トークン２６を探索すること、およびそのトークンでタグ付けされたすべてのレコードを検索することのみによって行う。加えて、小売店が、情報サービス・プロバイダによってメンテナンスされたリポジトリ２４に接続して、望むようにカスタマＷｉｌｌｉａｍ  Ｆ．Ｓｍｉｔｈに関する追加の情報をプルすることもできる。このトークン・マッチング・プロセスは計算上単純であるので、リアルタイムで実行することができる。その結果がトータル・カスタマ・ビュー１０１であり、これを介して小売店が即時に、このカスタマとのそのトータルの関係を決定することができる。トータル・カスタマ・ビュー１０１により、たとえば、小売店がそのマーケティング努力をこの特定のカスタマに、より効率的な方法において向けることができ、これはこのカスタマが好意を示すことがわかっている製品およびサービスに集中することによって行う。
【００７３】
図１２に例示した上述のプロセスを、カスタマ関係管理に関連するいくつかの重要なタスクに適用することができる。図１３は、大規模な小売店と、小売店のインターネットｗｅｂサイトを介して連絡を取るカスタマ１０３の実施例を例示する。カスタマ１０３が自宅用の雨樋を注文することを決定すると仮定する。次いでカスタマは、小売店がｅコマースを容易にするためにメンテナンスするインターネットｗｅｂサイトにアクセスし、これはｗｅｂサーバ１０８上でホストされている。ｗｅｂサイトにアクセスすると、カスタマは、自分の名前および住所を入力するように、ｗｅｂサーバ１０８上でメンテナンスされたソフトウェアによってプロンプト表示される。次いで、ｗｅｂサーバ１０８は、カスタマ１０３に関する情報をリンクさせるために使用された消費者トークン２６を決定する。マッチングが発見された後、次いでインタラクティブ・データ・アクセス１０９が、このトークンにマッチングするものについて小売店の様々なデータベースのすべてを探索することができ、これにはホーム・サービス・データベース１００、小売販売データベース１０２および自動車サービス・データベース１０４が含まれる。次いで、このデータがｗｅｂサーバ１０８に戻される。再度、トークンを使用してマッチングが実行されるので、このプロセスはカスタマ１０３に関するすべての関連データを、関連情報に関する特定のレコードとカスタマによって入力された名前および住所の間にマッチングするものがあるかどうかに関わらず、ｗｅｂサーバ１０８のクエリに応答して戻す。加えて、トークンを使用して追加の情報を情報サービス・プロバイダのリポジトリ２４から、リアルタイムで、リポジトリ２４との接続を介して検索することができる。リポジトリ２４とのリンケージを、ＯＬＴＰ技術によるものにすることが好ましい。次いで、小売店および情報サービス・プロバイダの結合されたデータをｗｅｂサーバ１０８によって使用して、カスタマ１０３が閲覧するためにカスタマイズされたインターネットｗｅｂページを即時に構築することができる。このカスタマイズされたｗｅｂページは、たとえば、特にそのカスタマが関心のある特別なプロモーションを表示することができる。このプロセス全体を、本発明の好ましい実施形態ではリアルタイムで実行することができ、したがってカスタマ１０３にとって顕著な遅延となる結果にはならない。
【００７４】
本発明の代替実施形態では、データ所有者が、カスタマ１０３が閲覧するためにカスタマイズされたｗｅｂページを提供することができ、これは、カスタマ１０３の、ｗｅｂサーバ１０８によるクエリに対する応答を直接、情報サービス・プロバイダのリポジトリ２４に送信することによって行う。次いで、情報サービス・プロバイダがこの情報を、リポジトリ２４におけるデータと共に使用して、カスタマ１０３についてのすべての関連情報をマッチングするために適切な消費者トークン２６を発見する。情報サービス・プロバイダからの追加の情報が要求された場合、そのデータを適切な消費者トークン２６と共にｗｅｂサーバ１０８へ戻すことができる。次いで、この消費者トークン２６を、上で説明したようなインタラクティブ・データ・アクセス１０９を使用して、小売店がカスタマ１０３についてメンテナンスするすべての情報をマッチングするために使用することができる。次いで、このデータの集合体をｗｅｂサーバ１０８が使用して、カスタマ１０３のためのカスタマイズされたｗｅｂサイトを構築することができる。このデータの集合体をまた、代替実施形態では、解析モデリング・エンジン（図示せず）に伝送して、データ・マイニングおよび他の解析機能を実行することもでき、その結果をｗｅｂサーバ１０８に戻して、カスタマ１０３のためのカスタマイズされたｗｅｂサイトの構築を支援することができる。
【００７５】
本発明により、小売店がカスタマの取引または入力を、そのカスタマに関するそのデータを更新する機会として使用できるようにすることができる。再度図１３を参照して、カスタマ１０３が最近ジャクソンヴィルからフェニックスに引っ越したと仮定する。次いで、カスタマ１０３が、新しい自宅に雨樋が必要であると決定し、インターネットで小売店のｅコマースｗｅｂサイトを介して雨樋を注文しようと試みる。再度、ｗｅｂサーバ１０８がカスタマ１０３に名前および住所情報を入力するようにプロンプト表示すると仮定する。小売店の内部データベースのいずれもがカスタマ１０３の新しい住所を含まないようになり、したがって、カスタマ１０３についてのすべての情報を、トークンなしで正確にリンクさせることが困難となる可能性がある。しかし、名前および住所が情報サービス・プロバイダに送信された場合、これがリポジトリ２４を使用してｗｅｂサーバ１０８に、カスタマ１０３についての正しい消費者トークン２６および住所トークン２８を戻すことができ、これはリポジトリ２４が、引越しを指示するデータを先に受信している場合である。次いで、小売店がトークン・マッチングを使用して、このカスタマに関連するそのすべてのデータを、データ・アクセス・ルーチン１０９を使用して検索することができ、次いでｗｅｂサーバ１０８を使用して、この情報に基づいてカスタマ１０３のためのカスタマイズされたｗｅｂページを構築することができる。カスタマ１０３によって提供された、更新された住所情報を小売店が使用して、後にクーポンおよび特別オファーをカスタマ１０３の正しい住所に向けて郵送することができる。
【００７６】
なおもう１つの実施例は、トークン１０がカスタマ関係管理のもう１つの重要な態様を容易にする方法を例示する。このとき図１４を参照すると、カスタマ１０３がサービス担当者１０５に電話をかけて、自分が注文した雨樋が時間通りに配達されなかったと訴えると仮定する。次いで、サービス担当者１０５が即時に、カスタマ１０３に関して使用可能なすべての情報を、インタラクティブ・データ・アクセス・ルーチン１０９を使用して呼び出すことができる。結果として、サービス担当者１０５は、カスタマ１０３が最近において小売店と実質的な取引を行っており、通常はスポーツ用品を購入すると決定することができるようになる。まだカスタマ１０３と通話中にこれらの事実を認識することによって、サービス担当者１０５は、最適な行動計画がカスタマ１０３に次回のスポーツ用品購入時の大幅割引用クーポンを提供することであると決定することができる。カスタマ１０３に関するすべての使用可能な情報へのアクセスを有することによって、小売店は、ある特定の取引においてサービスが不十分なことがあったにも関わらず、カスタマ１０３を保持する最適な方法を決定することができる。
【００７７】
本発明はまた、データ所有者によってメンテナンスされた様々なデータベース全体で、トリガ通知を実行するために使用することもできる。たとえば、このプロセスを図１５において、大規模な金融機関について例示する。金融機関はその様々な運用のための物理的に別々のデータベースをメンテナンスしており、これには法的サービス・データベース１４０、保険データベース１４１、小売銀行業務データベース１４２、投資銀行業務データベース１４３および会社データ・ウェアハウス１４４が含まれる。ブローカ１４８はカスタマ１０３から、カスタマが新しい家の購入を計画中であることを知る。この情報は、小売銀行業務および法的部門など、この取引に関連してそのサービスをカスタマ１０３に提供することを望む可能性のある、金融機関の他の部門にとって貴重となる可能性がある。ブローカ１４８はこの情報をメッセージング・システム１４６に入力することができ、次いでこれがマッチング・トークンを使用して、この情報を法的サービス・データベース１４０、保険データベース１４１、小売銀行業務データベース１４２、投資銀行業務データベース１４３および会社データ・ウェアハウス１４４に即時に提供する。法的および小売銀行業務部門において運用している人員はこのときこの情報へのアクセスを有するようになり、カスタマ１０３についてメンテナンスされたいかなる追加の情報をも、上に例示したようなトークンを使用したデータ統合を介して検索することができる。
【００７８】
本発明のなおもう１つの応用例は、エンティティからの、どの情報がメンテナンスされるかについての入力に応答してではなく、その代わりに新しい情報がデータ・サービス・プロバイダのリポジトリ２４に追加されるときに、カスタマ・ファイル７６上のデータを更新あるいは拡張することである。新しい情報を自動的に、情報が関係するエンティティおよびこのサービスを受信することを望むエンティティに関するレコードをメンテナンスするこれらのデータ所有者に、「プッシュ」することができる。このとき図１６を参照して、トークンを使用したプッシュ技術の一実施例を例示する。リポジトリ２４が、更新データ１５６の形式における特定のカスタマについての追加の情報により更新されると仮定する。小売店Ａはまた、このデータが関係するカスタマについての情報もそのカスタマ・ファイル７６上でメンテナンスし、これをたとえば、小売店Ａのホーム・オフィス・データ・センタでメンテナンスされたデータベースにすることができる。小売店Ａがサービスをプッシュするようにあらかじめサブスクライブしているので、情報サービス・プロバイダが小売店Ａのトークン・リスト１５２をメンテナンスしており、これには、小売店Ａが更新をプッシュすることを望むエンティティに対応するすべてのトークン１０のリストが含まれる。情報サービス・プロバイダの監視ルーチン１５０が小売店Ａのトークン・リスト１５２をチェックして、更新データ１５６がカスタマ・ファイル７６にプッシュされるべきであるかどうかを決定する。他のデータ所有者がプッシュ・サービスをサブスクライブすると仮定すると、監視ルーチン１５０は、これらの各サブスクライバに関連付けられたトークン・リストもチェックする。このプロセスを高速で実行することができ、これは監視ルーチン１５０が、更新データ１５６におけるトークンを各トークン・リストにおけるトークンと比較するだけでよいからである。監視ルーチン１５０が小売店Ａのトークン・リスト１５２においてマッチングを発見した後、次いで更新データ１５６を発行ルーチン１５４に渡し、次いでこれが更新データ１５６を小売店Ａのカスタマ・ファイル７６に通信する。この通信は、電話回線またはデータを電子的に伝送する他のいかなる手段によるものにすることもできる。カスタマ・ファイル７６における結果は、更新されたカスタマ・リスト１５８である。プッシュ・サービスをサブスクライブすることによって、小売店Ａは情報サービス・プロバイダの莫大なリソースおよび全国的な情報のデータベースへのアクセスを利用することができ、同時に、カスタマ・ファイル７６および小売店Ａのトークン・リスト１５２においてメンテナンスされたその情報によって反映されたような、そのビジネスに関連するデータの更新のためにのみ支払いを行う。
【図面の簡単な説明】
【図１】  本発明の好ましい実施形態による、データリンク付けトークンの構造を示す図である。
【図２】  本発明の好ましい実施形態による、カスタマ、住所および居住トークンの間の関係を例示するテーブルである。
【図３】  本発明の好ましい実施形態による、リンク付けトークンを小売店のカスタマ・データベースに適用した結果を例示する図である。
【図４】  本発明の好ましい実施形態による、リンク付けトークンをカスタマ・データベースに適用する手順を例示する図である。
【図５】  本発明の好ましい実施形態による、情報サービス・プロバイダのデータ・リポジトリ上に存在する識別クラス・オブジェクトの構造を示す図である。
【図６】  本発明の好ましい実施形態による、住所情報における誤りにも関わらずカスタマ・データをリンク付けするための手順を例示する図である。
【図７】  本発明の好ましい実施形態による、トークンを合併することによってトークン・メンテナンスを実行するための手順を例示する図である。
【図８】  本発明の好ましい実施形態による、トークンを分割することによってトークン・メンテナンスを実行するための手順を例示する図である。
【図９】  本発明の好ましい実施形態による、カスタマ・データベースへのトークンの最初の割り当ての処理と、同じデータベースへのトークン情報の後続の更新の間の違いを例示する図である。
【図１０】  本発明の好ましい実施形態による、トークンにタグを付ける前の、いくつかの業務部門を有する小売店についての典型的なデータのテーブルの図である。
【図１１】  本発明の好ましい実施形態による、トークンにタグを付けた後の、いくつかの業務部門を有する小売店についての典型的なデータのテーブルの図である。
【図１２】  本発明の好ましい実施形態による、トークンを使用したトータル・カスタマ・ビューを構築する方法を例示する図である。
【図１３】  本発明の好ましい実施形態による、カスタマ入力に応答して、カスタマイズされたｗｅｂページを、トークンを使用して構築する方法を例示する図である。
【図１４】  本発明の好ましい実施形態による、コール・センタ応答を、トークンを使用して改良する方法を例示する図である。
【図１５】  本発明の好ましい実施形態による、トークンを使用した「トリガ通知」カスタマ関係管理を例示する図である。
【図１６】  本発明の好ましい実施形態による、トークンを使用した「プッシュ」技術の使用を例示する図である。
【図１】
0004634685.tif 000002
【図２】
0004634685.tif 000003
【図３】
0004634685.tif 000004
【図５】
0004634685.tif 000005
【図４】
0004634685.tif 000006
【図７】
0004634685.tif 000007
【図８】
0004634685.tif 000008
【図６】
0004634685.tif 000009
【図９】
0004634685.tif 000010
【図１２】
0004634685.tif 000011
【図１０】
0004634685.tif 000012
【図１１】
0004634685.tif 000013
【図１３】
0004634685.tif 000014
【図１６】
0004634685.tif 000015
【図１４】
0004634685.tif 000016
【図１５】
0004634685.tif 000017