符号化されたリンクを使用するデータリンクシステムおよび方法
【課題】永続リンクを使ってデータをリンクする。
【解決手段】各エンティティに対し識別クラスを維持する中央レポジットリー内で永続リンクが作成される。識別クラスはエンティティに関するすべての利用可能な情報を含む。名前および住所の代わりにリンクを照合することにより、潜在的な不明瞭さおよびエラーの重複を除去する。クライアント固有のキーと共に外部へ配信する前に、これらリンクを符号化する。このリンクの符号化により、クライアントは不正に個人情報を使用しようとしなくなる。
【解決手段】各エンティティに対し識別クラスを維持する中央レポジットリー内で永続リンクが作成される。識別クラスはエンティティに関するすべての利用可能な情報を含む。名前および住所の代わりにリンクを照合することにより、潜在的な不明瞭さおよびエラーの重複を除去する。クライアント固有のキーと共に外部へ配信する前に、これらリンクを符号化する。このリンクの符号化により、クライアントは不正に個人情報を使用しようとしなくなる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、類似したエンティティに関するデータをリンクするためのシステムおよび方法に関する。より詳細には本発明は、リンクを生成するエンティティによる衝突を少なくするようにリンクを符号化したデータをリンクするためのシステムおよび方法に関する。
【背景技術】
【０００２】
実質的にすべての企業は顧客に関する情報を含むコンピュータ化されたデータベースを維持しなければならないと現在考えている。かかる情報は、例えば課金をしたり、販売および新製品に関して顧客に情報を与えるための種々の態様で使用できる。この情報はコンピュータデータベース内に一連の記録として一般に電子的に記憶され、各記録は特定の顧客に関係している。記録とは、当業者に周知の任意の数の方法でコンピュータデータベース内で実現できる論理的な概念である。使用されるデータベースはフラットなデータベースでもよいし、リレーショナルデータベースでもよいし、またその他のいくつかの公知のフォームの１つでよい。データベースにおける各記録は種々のフィールド、例えば顧客の姓名、住所、ストリート住所、市、州および郵便番号を含むことができる。これら記録は、より複雑なデモグラフィックデータ、例えば顧客の婚姻状態、概略の収入、趣味または購入履歴も含むことができる。
【０００３】
企業は一般に多数のソースから顧客のデータを収集する。これらソースは顧客の購入のような内的なものもあれば、情報サービスプロバイダが提供するデータのような外的なものもある。多数の情報サービスプロバイダは企業に販売したり、またはリースしたりする広範なベースの消費者情報を有する大規模なデータベースを維持している。例えばカタログ販売企業は特定の地理的エリアにおける潜在的な顧客のリストを購入できる。
【０００４】
企業は顧客データを集めるのに種々の方法を利用するので、企業は顧客に関する冗長な情報を含む、いくつかの、大規模であるが完全に独立したデータベースを持つことが多いが、これら企業は特定の顧客に関する情報のすべてを正確にリンクする手段を持っていない。この問題の１つの一般的な一例として、銀行が小切手および預金口座保持者用のデータベース、クレジットカード保持者のための別個のデータベースおよび投資クライアントのための別個のデータベースを維持する例が挙げられる。別の一般的な例として、大規模な小売業者が、例えば自動車の修理、家のリフォーム、伝統的な小売販売、電子商取引および眼鏡サービスを含む部門または営業ラインの各々をサポートする別々のデータベースを持つ例が挙げられる。
【０００５】
多数の独立したデータベースを有する企業は、顧客のうちの誰が多数のサービスを利用しようとするのかを知るのは特に有益と考えている。例えば、ある銀行が、自分の預金口座に１００ドルしか持っていない顧客が１０万ドルのブローカー口座を維持すると判断できれば、この顧客に対して豊富な銀行サービスを提供したいと考える場合がある。この情報も、例えばクロス販売の機会を活用したり、現在の顧客のベースに最良のサービスをするための種々のサービスを最適にする上で、企業を補助するのにも有効となり得る。
【０００６】
各顧客に関する有益なすべてのデータをリンクすることによって、企業の部門の各々が各顧客に関する最新の情報にアクセスできるようにもなる。例えばある顧客が結婚したり、引っ越ししたりした場合、顧客はこの転機に関する情報を企業の部門の１つにしか通知しないことがあり得る。例えばメンフィスに在住する長年の価値ある顧客であるスー・スミス（Ｓｕｅ Ｓｍｉｔｈ）さんが、ミネアポリスに在住するスー・トンプソン（Ｓｕｅ Ｔｈｏｍｐｓｏｎ）となったことを仮定すると、企業のデータ処理システムのうちの１つしかこの転機について知らなかった場合、他のシステムは、ミネアポリスのスー・トンプソン（Ｓｕｅ Ｔｈｏｍｐｓｏｎ）がメンフィスのスー・スミス（Ｓｕｅ Ｓｍｉｔｈ）と同一人物であると判断できない。この問題は顧客の価値が企業に合うものとして顧客を扱うことを阻害し得る。長い期間にわたる顧客をあたかも新しい顧客であるかのように扱うことは失礼なことになりやすく、この結果、顧客の企業を失うことにもなり得る。
【０００７】
この問題を解決するのに使用される最も古い方法の１つは、どの顧客に対してもある番号を割り当て、次にこの番号を使って照合、サーチおよびデータ操作作業をすることである。大規模な内部の顧客データベースを維持している多くの会社はこのタイプのシステムを実現している。理論的には、各顧客の番号は顧客が自分の名前または住所を変えたとしても、各顧客に対して常に同じままである。これら番号は顧客に出荷されたパッケージの課金または追跡のために内部で使用できる。例えば顧客の名前および住所を識別子として使用した場合、顧客の識別番号を使用することは潜在的な不明確さを解消する。特に金融機関は各取引に関する適正な顧客を明確に識別するために、個人識別番号（ＰＩＮ）を使用している。
【０００８】
顧客番号システムは本来は所定の用途だけに限定される。顧客識別番号は名称および住所の常に変化する国内の包括的なリストを管理するようにはなっていない。これら番号を維持する会社は一般に自分の顧客とうまくやることにしか関心がない。従って、かかる番号の割り当て方法は全く簡単である。すなわち顧客が取引を求める会社にアプローチしてきたときに、その顧客に対して新しい番号が割り当てられる。この顧客番号は所定の顧客に対する住所および名前の履歴を管理できる広範なベースのプロセスの結果として決まるものではない。重要なことに、顧客番号は、番号を作成する企業に対して顧客自身が提示した情報だけに基づいて割り当てられる。これら番号は会社の日々の取引とは独立して機能するマルチソースデータレポジットリーからは割り当てられない。端的に言って、かかる番号の目的は単に取引の管理にあり、ユニバーサルなデータのリンクにはない。かかる番号は一般に、ある期間活動がなければ、会社によって廃棄されるので、かかる番号は真に永続的なものでもない。更に、顧客番号の割り当て方針の焦点は単に営業内部の取引であるので、取引が進行しない番号を永続的に維持する理由はない。どの会社も異なる組の顧客番号を維持しているので、データを外部からリンクするのにこれら番号を使用することはできない。
【０００９】
これまで消費者に対しては外部から使用されるユニバーサルな番号割り当てシステムは使用されていないが、これらシステムは小売用製品に対して使用するのに公的に利用できる状態になっている。１９７０年代初期に「バーコード」として広く知られるユニバーサルな製品コード（ＵＰＣ）システムの使用が開始した。この時期に、すべてのメーカーに共通する符号化システムのニーズが食料雑貨店企業で生じた。今日、ユニフォームコード協議会（ＵＣＣ）が小売製品に対して使用するためのすべてのバーコードの割り当てに責任を果たしており、メーカーに関係なく、どの製品に対してもユニークなＵＰＣ番号が維持されている。誰でもコードを使用できるように、これらコードのデータベースは公的に利用可能になっている。このデータベースを使用することにより、どの小売業者も自分の店の棚にある各製品に関する価格およびその他の情報を追跡できる。今日の製品販売チェーンも製品を追跡したり、物流および販売チャンネルに関する判断をするのに、ＵＰＣシステムに大きく依存している。
【００１０】
ＵＰＣシステムは大きな成功を収めたが、このシステムの有効性は限られている。新製品に対してＵＰＣ番号を得るのに、メーカーはまずＵＰＣ番号を申請し、ＵＣＣデータベースに製品と番号を追加し、メーカーは販売前にその製品に対して正しいバーコードを添付する。既に存在する製品に対してＵＰＣ番号を割り当てる方式もなければ、ＵＰＣ番号が表示する製品とＵＰＣ番号を照合する方式もない。更に、各ＵＰＣ番号は小売販売のためにパッケージされた単一の固有の物品を示しているので、単一のＵＰＣ番号が割り当てられる特定製品の種々の要素を識別するための方式はない。従って、ＵＰＣシステムは消費者に関する既に存在する種々のデータをリンクするのには使用できない。
【００１１】
個人に対し識別番号システムを使用することによって生じる、究極的かつ極めて重要な問題はプライバシーである。顧客識別番号を会社内部でしか使用しない場合ほとんどプライバシーの問題は生じない。しかし、個人に関して顧客識別番号、すなわちＰＩＮを外部で使用した場合、個人のプライベートなデータが他人によって不正または不法に使用されたり、共用され得る危険性が増す。この問題は、自分のクライアントの顧客データベースでデータを追跡する手段として、情報サービスプロバイダが顧客識別番号、すなわちＰＩＮを発行した場合に特に問題となる。かかる会社は一般に多数のクライアントを持っておりこのうちの多くは実質的に重複した顧客リストを有することがある。これらクライアントは自分の顧客に関するより多数の情報を集めるために互いにデータを内密に共用したいことがある。かかるクライアントは顧客情報番号を単に照合することに基づき、集中的に自らの顧客データベースを併合したりまたはその他の方法で使用することは比較的簡単であると分かっている。複数のクライアントが内密でかかる努力をした場合、情報サービスプロバイダは情報がどのように使用され、共用されるかをもはや管理できなくなる。従って、情報サービスプロバイダのクライアントは情報サービスプロバイダが個人情報の不正使用を防止するためにとり得るどんな保護対策も迂回できる。
【００１２】
顧客識別番号システムの別の限界は、ファイルをマージしたり、重複したエントリーを除くために使用される方法にある。かかるシステムにおける重複を除き、別個のデータベースに維持されている顧客データをリンク（または統合）するための唯一の包括的方法は、歴史的には、最初から対応するデータベースを再構築することであった。多くのかかるデータベースは何千万もの記録を含んでいるので、データベースを完全に再構築するコストは実現不可能なほど費用がかかることが多い。更にこれらデータベースは古い顧客が離れたり、新しい顧客が生じたり、顧客情報が変わり、常に流動的であるので、すべての情報を妥当な程度に最新状態に維持するには、再構築方法を定期的に繰り返さなければならない。
【００１３】
企業はデータの統合および重複除去サービスをするのに情報サービスプロバイダに伝統的に頼っている。情報サービス企業は種々の重複除去解決方法を解決するのに、近年膨大な専用リソースを有している。これら解決方法は事後に実行される。すなわちデータ所有者のシステム内で重複しているエントリーを例示した後で実行される。メンフィスのスー・スミスとミネアポリスのスー・トンプソンに対するデータの記憶が同じ人に関するものであるかどうかを判断するには、重複除去ルーチンは多数のデータフィールドを分析しなければならない。単に名前と住所を比較するだけでは多くのケースでは一致が得られない。名称および住所が同一であるケースでも、このことは記録が同一個人に関するものであると表示できない。その理由は、例えばデータが父親および自分の父親の名前をとった息子であることがあり得るからである。多くのデータベースが不完全または不正確な多数のデータを含むという事実により、問題を有効に解決することがより困難となっており、多くのケースでは完全な解決が不可能である。
【００１４】
重複除去ルーチンは必ず複雑であるが、これらルーチンは高速度でも実行しなければならない。これらルーチンは何千万もの記録を有するデータベースの重複を除去するのに使用される。かかる大規模データベースの場合、重複除去機能を実行するソフトウェアのサブルーチンは１回の重複除去セッションの間に何百万もの回数コールされることがある。従って、これらサブルーチンは極めて高速で実行しなければならず、高価なコンピュータ機器は妥当な時間で重複除去ルーチンを完了するのに必要なパワーを有していなければならない。重複除去方法はリソース集約的であるので、かかるタスクは今日これらルーチンを効率的に実行するのに必要な膨大な計算能力にアクセスする情報サービスプロバイダまたはデータ所有者によってしか実行できない。
【００１５】
更に、重複除去ルーチンは必ずある推定作業を行う。上で説明したように、重複除去は不完全であり得る利用可能なデータに基づく。従って、重複除去ルーチンの結果は利用できる情報と同じ程度に良好であるにすぎない。名前および住所情報の固有の不明確さにより、どのシステムも顧客データベース内の重複を１００％除去することはできない。その結果、データベースは同じ顧客の多数の記録と単一の顧客であるかのように１つの記録にマージされた多数の顧客との事例を含む。この問題の結果としてよく知られていることは、メールオーダー小売業者から同じカタログを何部も顧客が受け取ってしまうようなことである。かかる経験は顧客に対してフラストレーションを与え、その結果、小売業者の費用が増すことになる。
【００１６】
歴史的に、企業用データベースを情報サービスプロバイダが統合する方法は時間がかかり、労力集約的であった。種々の広範なデータベースフォーマットが使用されているので、情報サービスプロバイダはまずデータベースのソースファイルを処理するための標準フォーマットに変換しなければならない。次に、情報サービスプロバイダは上記のように複雑な重複除去プログラムの１つを作動させる。企業用データベースにおけるデータは重複除去ルーチンの精度を改善するために情報の外部ソースで増加し得る。この結果生じるデータベースのファイルは、プロセスを完了するのに企業用データベースファイルフォーマットにフォーマット化し直される。この全手順は情報サービスプロバイダの技術員による大きな直接関与を必要とするが、このことはサービスのコストにおいて重要な要素となる。
【００１７】
このデータ統合方法の大きな限界は、サービスがリクエストされるごとに全プロセスを繰り返さなければならないことである。１つの記録に対するデータ統合は一度に実行できず、また既に更新された記録に対してしか実行できない。この理由は、データ統合プロセスは同様な（従って、重複の可能性がある）記録のグループ分けを行うのに、データの記録のすべてを互いに比較することに依拠しているからである。比較プロセス中、通常、照合リンクが作成されるが、これらリンクは一時的なものであり、プロセスが一旦完了すればなくなる。これらリンクはサービスを実行するごとに最初から作成し直さなければならない。これらリンクはすべての可能な顧客の全体を通して一義的ではなく、情報サービスプロバイダによって維持されないので、これらリンクを再使用することは不可能である。
【００１８】
現在のデータ統合方法の最も重要な限界の１つは、この方法をリアルタイムで実行できないことである。すなわちこのプロセスはバッチモードでしか実行できない。リアルタイムのデータ統合は小売業者または他のデータ所有者が特定の顧客からの入力に対して即座にカスタム化された応答をするのを可能にするので、このようなリアルタイムのデータ統合が極めて望ましい。例えば特定の顧客が小売業者のウェブサイトにアクセスした時には、その顧客に関する利用できるすべての情報をリンクし、その顧客の関心およびニーズに特に合わせたウェブページを表示することが望ましい。その他の応用例としては、小売業者での購入が進行中に特定の顧客のクレジットカードの“読み取り”に応答して、カスタム化されたクーポンまたは販売情報を提供することが挙げられる。
【００１９】
顧客入力に対し、カスタム化された応答をするための従来のシステムは、内部の顧客番号の一致に基づいている。例えばある食品雑貨店が特定の顧客を識別するのにバーコードを含むメンバーカードを配布する。顧客が自分のメンバーカードをレジカウンターで提示すると、カードのバーコードがスキャンされて、顧客の識別番号を判断する。次に、店のデータ処理システムは自動的に購入履歴データベースに相談し、顧客の固有の購入傾向に合わせたクーポンをプリントする。
【００２０】
内部顧客番号に基づく１回記録処理にはいくつかの重要な限界がある。まずこのシステムは番号を既に割り当てた確立された顧客に対してしか働かない。新しい顧客が店に入った場合、システムが顧客を認識する前に、その顧客に対してメンバーカード（および対応する識別番号）を発行しなければならない。当初、店はこの顧客に関して何も知らない。更に上記のような個人のプライバシーの問題により、顧客識別番号のこのシステムの使用は外部からの使用に対してアクセスできない。
【００２１】
従来のデータ統合方法の更に別の限界は、顧客に関するデータが変わった時に企業が各顧客に対して維持しているデータを企業が遠隔的かつ自動的に更新したり、また増強する手段を提供できないことである。更新データまたは増強データを提供する従来のバッチモードの方法は労力がかかり、スタートから最終まで数週間かかることがある。まずデータの補強を求める会社は顧客データベース内の各記録に対するエントリーを含む抽出ファイルを構築しなければならない。この抽出ファイルはコンピュータで読み取りできる媒体、例えば磁気テープに記憶され、この媒体は増強のために情報サービスプロバイダへ出荷される。広範な種々のデータベースフォーマットが使用されているので、情報サービスプロバイダはまず抽出ファイルを処理できるように情報サービスプロバイダの内部フォーマットに変換しなければならない。次に、情報サービスプロバイダは抽出ファイルのこの標準化されたバージョンを使って会社のデータベース内の情報と、情報サービスプロバイダが維持するすべての情報とを比較するソフトウェアアプリケーションを実行する。次に、会社の標準化された抽出ファイルに更新データまたは増強データが重ねられる。
【００２２】
このデータ更新および増強方法の重要な限界は、データのわずかな部分だけを更新しなければならない時でも企業のデータベースを再構築しなければならないことである。例えば毎月１回小売業者が顧客データベース内の住所を更新したいとする。ほとんどの顧客は１カ月以内に住所を変えることはない。しかしながら、従来の更新情報は、引っ越しした数人の顧客をキャッチするのに、小売業者がデータベースを完全に再構築することを求める。
【発明の概要】
【発明が解決しようとする課題】
【００２３】
このようなすべての理由から、データ統合、更新および増強を改善し、一回記録、リアルタイムのデータリンクを実行し、プライバシーの問題を引き起こすことなく、外部から使用できる明瞭なデータリンクシステムを開発することが望ましい。
【課題を解決するための手段】
【００２４】
本発明は関連するデータを照合するための不明瞭でないリンク方式を作成するのに、持続したリンクを使用するためのシステムおよび方法に関する。これらリンクは特定のエンティティに関するすべてのデータにタブを付けるのに使用される一義的な文字数字の列として実現できる。これらリンクは、情報サービスプロバイダによって作成され、符号化されたフォームでプロバイダの顧客が使用できるように外部へ配布できる。上記顧客識別番号と異なり、リンクの作成は顧客がデータ所有者にアプローチすることに依存していない。これらリンクを作成する情報サービスプロバイダは、ある国または当該エリアの全住民に関する情報と共にデータベースを維持でき、リンクのリストを最新に維持するよう、住所、名前、ステータスおよびその他のデモグラフィックデータの変更に関し、住民を常にモニタする。新しいエンティティが識別されると、新しいリンクが割り当てられる。
【００２５】
本発明は更にリンクを符号化する方法にも関する。多数のクライアントに対して同じリンクを発生することによって、情報サービスプロバイダが関与することなくクライアントが協力し合ってクライアントの間で情報を共有できるようになる。本発明によれば、リンクを外部に発行する前にリンクはクライアント固有のキーで符号化される。情報サービスプロバイダが再びその特定のクライアントデータにアクセスすると、クライアントのリンクを複号化するのにクライアント固有のキーが使用される。このように、符号化されていないリンクにより情報サービスプロバイダによる内部処理が常に実行できる。このような符号化方式により、クライアントが不正に情報を共用することは困難となる。複号化作業が十分困難なタスクとなり、複号化を商業的に不可能にできるような符号化技術が選択されている。更に本発明の一実施例は、データの不正共用をより困難にするために、多数の符号化アルゴリズムを使用している。好ましい実施例では、顧客のアイデンティティに対応するフィールドの部分だけを符号化すればよいように、リンクは種々のフィールドに分割される。
【００２６】
各リンクの一義性を維持するために、これらリンクは情報サービスプロバイダによって運用される単一の中央レポジットリーによってしか作成されず、このプロバイダによって内部で使用されるだけである。情報サービスプロバイダの情報でも完全とはならないので、２つ以上のリンクを単一リンクに組み合わせたり、また単一リンクを２つの異なるリンクに分割するような形態で、リンクの管理を定期的に実行しなければならない。このプロセスはすべてのリンクユーザーに送信される統合されたスプリットリンクのリストを発行するだけで実行できる。この管理方法によって、リンクを最新状態に維持するためのデータベースの完全な再処理が不要となる。
【００２７】
リンクは情報サービスプロバイダによって維持される中央レポジットリーによって作成されるので、従来のシステムよりも不明瞭さはより効果的に解決できる。中央レポジットリーは情報を維持する各エンティティに関するすべての利用可能なデータを含む識別クラスを作成できる。この識別クラスの目的は、適当なリンクを使って特定のエンティティに関するすべての利用可能なデータをリンクすることである。この情報の多くは配信されなくても、これら情報はデータの統合、更新または増強リクエストに応答して、正しいリンクが顧客のデータに割り当てられることを保証するために、照合プロセスで使用できる。識別クラスは名前の通称、共通する名前のミススペル、姓名の変更の履歴、住所の履歴、街路の通称および照合目的に有効なその他の対応する情報を含むことができる。この識別クラス構造によって従来可能であったよりもより正確な照合および重複除去が可能となる。例えば、知られている通称を使用することにより、中央レポジットリーは「Ｓｕｅ Ｃ．Ｓｍｉｔｈ」、「Ｃａｒｏｌ Ｓｍｉｔｈ」、「Ｓｕｅ Ｔｈｏｍｐｓｏｎ」に関する別個のデータベースの記録の各々は、同一人物を示すことを認識し、この人物に関する対応するすべての情報をリンクするために、単一リンクを割り当てる。
【発明の効果】
【００２８】
リンクは永続的であり、ドメイン内で普遍的に一義的であるので、これらリンクは特定のデータプロバイダによる使用にしか限定されていないし、また、特定の照合セッションに限定されているわけではない。むしろこれらリンクは特に対応するデータの任意の所有者に外部へ配信するようになっており、終了するものではない。データの所有者はリンクを受信し、これらを現在のデータと照合すると、一度に１つぐらいの少ない記録を使用して、バッチモードまたはリアルタイムのいずれかで、多数の内部データベースからのデータを高速で比較し、照合し、サーチし、統合するのにこれらリンクを使用できる。
【００２９】
例えば個々の顧客、企業、住所、世帯、占有に対応するデータをリンクするのに、種々のタイプのリンクを使用できる。占有リンクは顧客または企業および特定の顧客が特定の時間に在住する住所に関する情報に関するものであり、世帯リンクとは、世帯を共有すると判断されたすべての人物に関する情報に関するものである。何が世帯を構成するかの定義はアプリケーションごとに異なることがあるので、同時に使用される多数のタイプの世帯リンクがあり得る。更に個人の住所の履歴を維持するのに一連のリンクされた住所リンクを使用できる。個人の間の氏名の類似によって生じる不明瞭さは住所の履歴を使用することにより、より簡単に解決でき、住所の変更にもかかわらず、個人のデータに正しいリンクのタグを付けることができる。
【００３０】
既に上で指摘したように、従来の重複除去ルーチンは複雑であり、リソース集約的である。これらルーチンは利用可能なデータに限定されているので、１００％正確に実行することはできない。しかしながら、本発明によれば、データ処理システムに新しいデータを追加することは、リンクを互いに照合する程度に簡単である。リンクの照合はリアルタイムでデータ処理システムにデータを追加する際に実行できる計算上簡単なプロセスである。
【００３１】
本発明は多数のデータベースが維持されるデータ統合のプロセスを大幅に簡略化するためのリンクも使用する。特定のエンティティに関する既知のすべての情報が要求されると、データ所有者は当該エンティティに関連するリンクによってリンクされている情報に関する各データベースをサーチするだけでよい。例えば別個のデータベースで情報が維持されている２人の顧客が実際に同じ個人であるかどうかを判断するようになっている複雑な照合アルゴリズムを実行する必要はない。従って、これらリンクによってデータ所有者は、データベースが特定のエンティティに関する情報のすべてに容易にアクセスできる総合的に単一の仮想的データベースであるかのように、物理的に離れているデータベースの各々を扱うことができる。
【００３２】
データをリンクするためにリンクを使用することによっても、データの増強、データの統合および関連するデータ処理に関係するプライバシーの問題を大幅に少なくできる。適当なリンクが一旦データ所有者のデータに一致すると、リンクの単なるリストとして情報サービスプロバイダに更新および増強リクエストを送ることができる。これらリンク自身はリンクが関係するデータに関する情報を含んでいない。従って、かかる送信データを内密に傍受しようとする者は、送信データからプライベートなデータを抽出できない。更に、当該リンクは単なるデータリンクであり、ＰＩＮ、すなわち顧客識別番号ではないので、リンクを外部で使用することに関連した個々のプライバシーが漏れる危険が大きくなることはない。
【００３３】
これらリンクは更に顧客の入力に応答してすべての対応するデータを即座に収集できるように、リアルタイムに一度で記録のリンクを可能にする。特定の顧客のためのすべてのデータを収集することにより、データ所有者はそのデータ所有者とその顧客との間の相互対話をカスタム化するのに使用できる「顧客の全体像」を構築できる。すべての対応する顧客データを検索するために、多数のデータベースを調べなければならない場合、対応するリンクにリンクされているデータに関して各データをサーチするだけでよい。データ所有者は自分のデータのすべてをリンクするのにこれらリンクを使用したり、特定の顧客に関するデータを即座に増強するよう、情報サービスプロバイダによって維持されたデータとリンクできる。顧客のデータが受信された瞬間にリンクプロセスを実行するので、検索されたデータは利用できる最も最近に更新された顧客情報となる。データ所有者のデータベースと情報プロバイダのデータベースとの間のリンクは、これらリンクを使ったＯＬＴＰ（オンライン取引処理）で行うことができる。これらリンクは「トリガー通知」を実行するのにも使用できる。トリガー通知とは、特定のエンティティに関する新しい情報が受信された時に、リンクされているどのデータベースに対しても更新メッセージを自動的にトリガーすることである。これらリンクを使用することにより、トリガー通知はほとんど瞬間的に行うことができるので、例えば大規模な小売業者の各部門は顧客から受信した最新情報を活用できるようになる。
【００３４】
１回記録の処理の別の利点としては、情報サービスプロバイダからその顧客にデータをプッシュできることが挙げられる。例えば情報サービスプロバイダが特定の個人の名前が変わったことを知り得る。新しい情報とこの個人に関するすべてのデータをリンクするのに使用されるリンクとを含むメッセージを使用することにより、この変化を顧客のデータベースに自動的にプッシュできる。更新プロセスはリンクを照合するだけでよいので、情報サービスプロバイダまたは顧客のいずれかによる直接的な介入をすることなく、自動的にこのプロセスを実行できる。
【００３５】
情報サービスプロバイダのデータの外部への配信に関連して生じる別の問題は、ある会社のデータがその会社の競争相手に不注意で配信されることである。例えば会社Ａは多くの理由の１つからそのデータにリンクを適用させたいことがある。情報サービスプロバイダは既に会社Ｂ、すなわち会社Ａの競争相手から得た会社Ａの顧客に関する情報を照合データベース内に既に有している場合がある。この情報サービスプロバイダはプライベートなデータが会社Ａとの間で共用されないことを会社Ｂに保証できなければならない。本発明におけるリンクを使用することにより、このようなスクリーニングプロセスは自動的となる。情報サービスプロバイダはその内部リンク形成およびリンクプロセスの一部として双方の会社のデータを使用できる。しかし、リンクと共に会社から得た情報だけを戻すことにより、リンクを受信した会社は、任意の人のデータを得ることはできないが、自分のデータを得ることはできる。リンク自身はプライベートな会社の情報を開示しないので、別個のスクリーニング機能を実現するための条件はない。また、情報サービスプロバイダはリンクを発生して付加するのにすべての利用可能なデータを利用するので、不完全または部分的に不正確なデータと共に正しいリンクが会社に配信され得る。
【００３６】
従って、本発明の目的は、永続的なリンクを使ったデータ処理システムを提供することにある。
【００３７】
本発明の別の目的は、普遍的に一義的であるリンクを使用したデータ処理システムを提供することにある。
【００３８】
本発明の更に別の目的は、リンクを使用した多数の内部データベースを通してデータを統合できるようにすることにある。
【００３９】
本発明の目的は、リンクを使用してデータベースで自動的に重複を除去することができるようにすることにもある。
【００４０】
本発明の別の目的は、リンクを使用してデータの更新および増強を可能にすることにある。
【００４１】
本発明の更に別の目的は、クライアント固有のキーによりリンクを符号化することができるようにすることにある。
【００４２】
本発明の別の目的は、異なるクライアントに提供されるリンクのための複数の符号化アルゴリズムを提供することにある。
【００４３】
本発明の更に別の目的は、リンクを使用するデータのリアルタイムの１回記録の処理を提供することにある。
【００４４】
本発明の更に別の目的は、リンクを使用するリアルタイムでの物理的な別個のデータベースから顧客の全体像を作成できるリンク能力を提供することにある。
【００４５】
本発明の更に別の目的は、リンクを使用したリアルタイムでの顧客入力へのカスタム化された応答をすることにある。
【００４６】
本発明の更に別の目的は、リンクを使用してトリガー通知を実行することにある。
【００４７】
本発明の更に別の目的は、リンクを使用し、中央レポジットリーから顧客のデータベースへ更新データを自動的にプッシュすることにある。
【００４８】
以下、簡単に説明するように、添付図面に関連し、好ましい実施例の次の詳細な説明を検討することにより、本発明の別の目的および利点が明らかとなろう。
【図面の簡単な説明】
【００４９】
【図１ａ】本発明の好ましい実施例に係わるリンクの構造を示す図である。
【図１ｂ】リンク符号化方法を示す図である。
【図１ｃ】リンク複号化方法を示す図である。
【図２】本発明の好ましい実施例に係わる、顧客リンクと、住所リンクと、占有リンクとの間の関係を示す表である。
【図３】本発明の好ましい実施例による、小売業者の顧客データベースにリンクを使用した結果を示す図である。
【図４】本発明の好ましい実施例による、顧客データベースにリンクを適用するための方法を示す図である。
【図５】本発明の好ましい実施例による、情報サービスプロバイダのデータレポジットリーに常駐する識別クラスオブジェクトの構造を示す図である。
【図６】本発明の好ましい実施例による、住所情報のエラーにかかわらず、顧客データをリンクするための方法を示す図である。
【図７】本発明の好ましい実施例によりリンクを統合することにより、リンク管理を実行するための方法を示す図である。
【図８】本発明の好ましい実施例による、リンクを分割することによってリンクの管理を実行するための方法を示す図である。
【図９】本発明の好ましい実施例による、顧客データベースへのリンクの初期の割り当ての処理と、同じデータベースへのリンク情報のその後の更新と、の違いを示す図である。
【図１０】本発明の好ましい実施例による、リンクでタグを付ける前のいくつかの企業部門を有する小売業者のための代表的なデータの表である。
【図１１】本発明の好ましい実施例による、リンクでタグを付けた後のいくつかの企業部門を有する小売業者のための代表的なデータの表である。
【図１２】本発明の好ましい実施例による、リンクを使用して顧客の全体像を作成する方法を示す図である。
【図１３】本発明の好ましい実施例による、リンクを使用してカスタム化されたウェブページを作成するための、消費者入力に応答する方法を示す図である。
【図１４】本発明の好ましい実施例による、リンクを使ったコールセンターの応答を改善するための方法を示す図である。
【図１５】本発明の好ましい実施例による、リンクを使った「トリガー通知」の顧客関係管理を示す図である。
【図１６】本発明の好ましい実施例による、リンクを使ったプッシュ技術の使用を示す図である。
【発明を実施するための形態】
【００５０】
次に図１ａを参照する。この図には、本発明の実施例で使用されるリンクの構造が示されている。各リンク１０を１６桁の文字数字の列として電子的に記憶できる。リンク１０は４つの要素から構成されている。すなわち４つのキャラクターとして記憶されるドメイン１１と、２つのキャラクターとして記憶されるカントリーコード１２と、２つのキャラクターとして記憶されるタイプコード１３と、８つのキャラクターとして記憶されるリンク識別子１４とから構成されている。
【００５１】
ドメイン１１は各クライアントに対し情報サービスプロバイダが割り当てる一義的なクライアント番号を示す。各ドメイン１１は特定のクライアントに対し一義的であるので、このドメインをクライアント固有の符号化キーに対するポインタとして使用できる。ドメイン１１の一義的なクライアント番号を４つの３２進のキャラクターとして記憶することが好ましい。従って、ドメイン１１に対しては１０４８５７６個の可能な一義的な値があり、これら値は二人のクライアントが一致した組の符号化されたキーを有する危険性を生じることなく、本発明のこの実施例を使って情報サービスプロバイダが取り扱うことのできるクライアントの総数を示す。実施例では、ドメイン１１の１つの値（例えばゼロの値「００００」）は情報サービスプロバイダ自身を示し、この値は内部で使用され、よって符号化されないリンク１１に対して使用される。
【００５２】
情報サービスプロバイダが１０４８５７６よりも多い数のクライアントを有しているとしても、多数のクライアントに同じクライアント番号を割り当てることを禁止するものはないと認識すべきである。１０４８５７６番目ごとのクライアントしか一致しない組のリンク１０を有する場合、かかる２つのクライアントがこの事実を認識し、不正にデータを共有しようと試みる可能性はとるにたらないほど少ない。
【００５３】
カントリーコード１２は入力データに対する発生カントリーに対応する一義的な２つのキャラクターのコードを示す。これらコードは２桁のカントリーコードのためのＩＳＯ−２規格に対応している。カントリーコード１２は例えば対応するデータを収集した元の種々の国、または対応するデータが関係する種々の国の国内のプライバシー法に従って、情報サービスプロバイダがデータを別々に取り扱うのに重要となり得る。
【００５４】
タイプコード１３はリンク１０が示すリンクのタイプを識別する２つのキャラクターコードを示す。このタイプコード１３は２つの３２進のキャラクターとして記憶することが好ましい。従って、タイプコード１３の値は総計１０２４個が可能である。実施例では、タイプコード１３の最初の桁は当該リンク１０が（以下、より完全に説明するように）維持されているのか、または誘導されたのかのいずれかを示すのに使用され、タイプコード１３の第２桁はリンク１０が消費者リンク、住所リンク、占有リンク、世帯リンク、または同等なリンクのうちのどれであるかを示すのに使用される。例えば「０３」なるタイプコード１３は、対応するリンク１０が維持されている住所リンクであることを示すことができる。
【００５５】
リンク識別子１４は情報サービスプロバイダによって追跡される特定タイプの各エンティティに対してユニークな８つのキャラクターのコードを示す。このリンク識別子１４は８つの３２進のキャラクターとして記憶されるので、リンク識別子１４に対するユニークな値は総数１,０９９,５１１,６２７,７７６個あり得る。このリンク識別子１４は特定タイプの同じエンティティに対して発行される重複したリンク識別子１４がないように、情報サービスプロバイダによって生成される。
【００５６】
次に図１ｂを参照し、本発明の実施例に係わる、リンクを符号化する方法について説明できる。情報サービスプロバイダにより内部に維持されるリンク１０は、上記のようにドメイン１１が「００００」の値を有することが好ましい。このゼロの値はリンク１０が内部で維持されており、よって符号化されていないことを示す。リンク１０が米国（米国はＵＳのカントリーコード１２を有する）に関連するデータに対して使用されていると仮定し、更にこれが０１のタイプコード１３を有する維持された消費者リンクであると仮定する。従って、本例において「００３ＮＱＬ８Ｎ」リンク１０のこの特定の消費者情報に対する所定のリンク識別子１４は、「００００ＵＳ０１００３ＮＱＬ８Ｎ」の値を有する。
【００５７】
次に、更にデータベース統合、増強またはその他のサービスの一部として、このリンク１０をクライアントに配信するものと仮定する。リンク１０を配信すべき相手のクライアントにはクライアント固有のドメイン１１’の値である「ＢＧ４Ｆ」が割り当てられている。アルゴリズムおよびキー記憶モジュール１５はアルゴリズム／キールックアップテーブル２３を含む。ドメイン値が既に割り当てられている各クライアントにも、アルゴリズム識別子２５によって識別された特定の（しかしながら必ずしも一義的ではない）符号化アルゴリズムおよび符号化キー２７も割り当てられる。アルゴリズム／キールックアップテーブル２３は対応するドメイン値２７に従ってインデックスされる各アルゴリズム識別子２５とキー２７とのリストを含む。実施例では、アルゴリズム識別子２５は単なる８ビットの二進数として記憶され、キー２７は３２進数の５１２個のキャラクターの文字数字の列として記憶される。（簡潔にするために、キー２７は図１ｂおよび１ｃでは単なる８つのキャラクターの文字数字の列として示されている。）図示した例では、ドメイン１１’の値が「ＢＧ４Ｆ」、アルゴリズム／キールックアップテーブル２３内アルゴリズム識別子２５の値が「０００００００１」、およびキー２７の値が「８ＷＦＺＴＲＥＱ」に対応する。
【００５８】
リンク１０を符号化するために、アルゴリズムおよびキー記憶モジュール１５にドメイン値１１’が送られ、対応するアルゴリズム識別子２３および記憶２７が検索される。符号化アルゴリズムモジュール３１は入力信号としてリンク識別子１４、アルゴリズム識別子２５およびキー２７を受けとる。符号化／復号化アルゴリズムモジュール３１は符号化アルゴリズムのレパートリーのうちのどれを使用するかを決定するのに、アルゴリズム識別子２５を使用し、キー２７を使ってリンク１４上の符号化アルゴリズムを実行する。この結果得られる、符号化アルゴリズムモジュール３１の出力信号は符号化されたリンク識別子１４’となる。実施例では、符号化されたリンク識別子１４’はリンク１４と同じ基本構造である。符号化プロセスは次に符号化リンク１０’を形成するのにドメイン１１’の値、カントリーコード１２、タイプコード１３および符号化されたリンク識別子１４’を連結する。
【００５９】
次に、符号化されたリンク１０’がクライアントから情報サービスプロバイダによって受信されると仮定する。このことは、例えばクライアントが既にリンク１０’をそのデータに適用させた後のデータ増強または更新リクエストの結果として生じ得る。この処理を実行するためには、情報サービスプロバイダは符号化されたリンク１０’を複号化し、内部処理のための複号化されたリンク１０を作成しなければならない。図１ｃに示されるように、符号化されたリンク１０’からドメイン値１１’が取られ、この値はアルゴリズムおよびキー記憶モジュール１５へ送られ、対応するアルゴリズム識別子２５およびキー２７を検索する。これまで述べたのと同じように、この目的のために、アルゴリズム／キールックアップテーブル２３が使用される。符号化／復号化アルゴリズムモジュール３１は次に入力信号として符号化されたリンク識別子１４’、アルゴリズム識別子２５およびキー２７を受けとる。符号化／復号化アルゴリズムモジュール３１はアルゴリズム識別子２５を使って復号化アルゴリズムのレパートリーのうちのどれを使用するかを決定し、キー２７を使ってリンク１４’で復号化アルゴリズムを実行する。この結果得られる、符号化／復号化アルゴリズムモジュール３１の出力信号は複号化されたリンク識別子１４となる。図１ｃに示されるように、この複号化プロセスはドメイン１１のゼロ値「００００」、カントリーコード１２、タイプコード１３および複号化されたリンク識別子１４を連結し、複号化されたリンク１０を形成する。次に、本明細書で更に説明するように、内部処理を続けることができる。
【００６０】
符号化／複号化アルゴリズムモジュール３１によって使用される特定の符号化／複号化アルゴリズムは本発明には重要ではない。このことは顧客がアルゴリズムまたは対応するキー２７の知識がないために、符号化されたリンク１０’から複号化されたリンク１０を作成することは、顧客にとってかなり困難であり、よって顧客がこのようなことをすることが商業的に不可能であることが条件となる。本発明の特定の実施例におけるキー２７のサイズは、顧客によるキーの複号化を商業的に不可能にするのに必要と見なされる複雑さのレベル、および選択されるアルゴリズムの種類に応じて決まる。当業者には多数のかかるアルゴリズムが既知となっている。
【００６１】
図２は特定の例を使った消費者リンクと住所リンクと占有リンクとの間の関係を示す。表１６は夫と妻に関するデータを示しており、最初の２つの行は、デンバーに住んでいた間の彼らの名前および住所データを示し、最後の２つの行は彼らがマイアミに引っ越した後の彼らの名前および住所データを示す。（この例およびその他の次の例では、簡潔にするために、各リンク１０のリンク識別子１４の略した部分しか示されていない。）消費者リンクコラム１７が示すように、消費者リンクは個人が引っ越しした際に、これら個人の各々に対して変化しない。しかしながら、住所リンクコラム１８に示されるように、これら人物は新しい住所リンクに関連付けされている。占有リンクコラム１９はこれら個人の各々に関する情報および特定の期間の彼らの住所に関する情報をリンクするのに、これらリンクが使用されるので、占有リンクの関連も変化することを示している。
【００６２】
データ所有者がリンク１０を使ってデータをリンクする前に、当該データベース（単数または複数）上のデータにリンク１０を関連付けしなければならない。この初期の関連づけは情報サービスプロバイダによって実行される。各リンク１０と適当なデータとの関連付けの他に、このプロセスは対応するデータベースファイル内での重複を除去するのに使用できる。次に図３を参照すると、ここにはこのプロセスの概観が示されている。データ所有者によって維持されている対応するデータベースファイルからの各記録を含む入力ファイル２０が生成される。この入力ファイル２０は単一のデータベースまたは多数の別々に維持されたデータベースから引き出すことができる。図示された例における入力ファイル２０は３つの別々に維持されたデータベースから引き出された同じ顧客に関する情報を含む。この例では、名前および住所に基づく簡単な照合では、これが同じ顧客であるかどうかを解決できない。その理由は、これら別個のデータベースが記録を維持している間に顧客が引っ越ししたり、自分の名前を変えているからである。しかしながら、レポジットリー２４を使用することにより、情報サービスプロバイダはこれら記録の各々が一人の顧客に関するデータを含むと判断できる。従って、結果ファイル２９内の各記録はこの消費者に対する同じリンク１０を含み、次にデータ所有者はこの特定リンク１０によってリンクされたすべてのデータをサーチするだけで、この消費者に関するデータのすべてにアクセスできるようになる。
【００６３】
次に図４を参照すると、ここにはリンク割り当て方法のより詳細な説明が示されている。リンク関連付けプロセスにおける第１工程は、入力ファイル２０を形成することである。次に、入力ファイル２０は照合ソフトウェア２２へ送られる。このソフトウェアは情報サービスプロバイダによって維持されるコンピュータ機器で実行できるが、データ所有者自身の機器でも実行できる。次に照合ソフトウェア２２は入力ファイル２０からのデータとレポジットリー２４からのデータを比較し、一致を探す。
【００６４】
情報サービスプロバイダによって維持されているレポジットリー２４は、国内スケールでの消費者および住所に関する広いベースの情報を含む。このレポジットリーは単一の物理的データベースでもよいし、また通信ネットワークによってリンクされた多数の物理的に独立したデータベースから形成されていてもよい。レポジットリー２４は米国または当該他の領域に住む、実質的にすべての消費者に関する情報を含む。
【００６５】
次に図５を参照する。レポジットリー２４には識別クラス３０の形式で情報が記憶される。各識別クラス３０は消費者リンク２６を使ってリンクされた特定個人に関して利用できるすべての情報を含む。特に識別クラス３０は個人によって使用された現在および以前の名前のリストである名前の履歴３２と、個人が住んだ住所のリストである住所履歴３４と、特定の時間、各名前／住所の相関性に関連する占有リンク２１を含む占有履歴３６とを含むことができる。上記のように、占有とは特定時間における個人の名前と、その時間に個人が在住した住所との組み合わせであるので、占有履歴３６を構築するのに住所履歴３４を使用できる。住所履歴３４はこの住所履歴３４内の各住所に対する住所リンク２８も含むことができる。名前履歴３２と住所履歴３４によって個人が自分の名前および住所の双方を合えた時でも、照合ソフトウェア２２はデータとリンク１０との正しい照合を実行できる。識別クラス３０は個人が関連する特定個人に関する種々の種類のデモグラフィック情報も含むことができる。この追加情報は比較のために照合ソフトウェア２２によっても使用できる。識別クラス３０は名前履歴３２および住所履歴３４の一部として、または別個のものとして共通する名前および住所のミススペルも含むことができる。
【００６６】
再び図４を参照し、照合ソフトウェア２２が照合プロセスを完了した後の入力ファイル２０内の対応するデータにリンクを添付する方法について説明する。上記のように、各識別クラス３０は消費者リンク２６と、少なくとも１つの住所リンク２８とを含む。（識別クラス３０が住所履歴３４内の過去の住所を含む場合、この過去の住所に追加住所リンク２８をリンクできる。）照合ソフトウェア２２を実行する結果、各記録の一部として正しい消費者リンク２６および住所リンク２８を含むように、入力ファイル２０が再書き込みされる。次に消費者リンクおよび住所リンク２８によって補強された入力ファイル２０から成る結果ファイル２９がデータ所有者に戻される。結果ファイル２９は同じ個人に関する情報を含む各記録に対し、同一の消費者リンク２６を含むので、このプロセスでは重複除去が自動的に実行される。例えば結果ファイル２９は「Ｊａｍｅｓ Ｌ．Ｓｍｉｔｈ」と「Ｊｉｍｍｙ Ｌ．Ｓｍｉｔｈ」に対する記録を含むが、各記録は同じ消費者リンク２６に一致するので、データ所有者は双方の記録が同じ顧客に関するものであると容易に判断できる。
【００６７】
入力ファイル２０および結果ファイル２９は電子ファイルを伝送するのに適した態様で送信できる。これらファイルは通信ネットワークを通し、ＦＴＰ（ファイル転送プロトコル）技術を使ってデータ所有者と情報サービスプロバイダとの間で伝送してもよいし、磁気テープまたはディスクのような電子記憶媒体で転送できることが好ましい。照合ソフトウェア２２は入力ファイル２０自身に含まれる類似性よりも、むしろ照合のためのレポジットリー２４内の包括データに依存しているので、入力ファイル２０の最小サイズには制限がない。入力ファイル２０は照合プロセスの精度が失われない状態で単一の記録程度に小さくできる。
【００６８】
次に図６を参照し、住所エラーを解決するために本発明を使った特定の例について説明する。エラー入力データ４０は夫と妻のための名前および住所情報を含む。エラー入力データ４０は夫に関するタイプエラーを含み、「２１０」のストリート住所が「１２０」に変わっている。配送マップ４６に示されるように、ストリート住所「１２０」は実際に存在している。この住所は有効であるが、この特定の消費者に対しては正しくないので、このエラーを解決することは通常困難である。例えばこのデータとマスター住所リストとを単に照合してもエラーを示さない。更に、レポジットリーデータ４２が正しいデータを含む場合でも、リンクを用いることなく、データを照合することは困難である。その理由は、「１２０」なるストリート住所は識別クラス３０に記憶された夫の住所履歴の一部ではないからである。
【００６９】
しかしながら、本発明のリンクを使用すれば、照合ソフトウェア２２を使用することにより、データとタイプエラーとの照合の問題を解決できる。その理由は、照合ソフトウェア２２は名前または住所のいずれか単独ではなく、占有照合に基づきその機能を実行するので、照合プロセスではタイプエラーは無視されるからである。これによってタイプエラーに係わらず、正しいリンクにより得られたデータ４９を戻すことができる。同様に、住所の通称、多数の正しいストリート名および共通するミススペルのような他の住所の問題を解決するのに、照合ソフトウェア２２はレポジットリー２４内の包括的データを引き出すことができる。これとは異なり、リンクのリンキングに基づき、レポジットリー２４内で発見された訂正された住所情報を含む、その結果得られるデータ４９を送ってもよい。更に、この結果得られたデータ４９はエラー入力データ４０と共に含まれないアパート番号のような、入力データ４０からなくなった追加住所情報と共に送ってもよい。
【００７０】
識別クラス３０に記憶された住所リンクを使用することにより、世帯管理を実行するのに本発明を利用できる。多くのデータ処理システムの望ましい目的は、どれだけ多くの顧客が同じ世帯を共用しているかを判断することである。世帯の定義は企業ごとに変わり得る。世帯を１つの住所に住む通常の家族として定義する企業もあれば、２つの関連のないルームメートを単一の世帯と見なす企業もあれば、更にある場合には別の住所に住む、法律的に別居したカップルを単一の世帯として定義し、別の場合には別々の世帯として扱う企業もある。
【００７１】
道路名の通称およびその他の問題とは関係なく、図５および６に示されるように、異なる顧客に対し、共通する住所リンク２８を割り当てるのに、識別クラス３０を使用することによって世帯データの精度は大幅に高められる。世帯の最も一般的な定義、すなわち同一住所に住む人という定義を使用すると、共通住所リンク２８を有するすべてのデータにアクセスするだけで世帯管理を実行できる。別居の家族、ルームメートか親戚かの区別、姓が共通となるような名前の変更、および同様な問題に対応する、識別クラス３０に含まれる他の目的データに基づき、レポジットリー２４上の識別クラス３０をリンクすることにより、世帯の概念を他の定義まで拡張できる。各世帯の定義に従い、データをリンクするのに異なるタイプのコード１３を有するリンク１０を使用できる。例えば、世帯の従来の定義に従い、すべてのリンクをするのに使用されるリンク１０に対して、例えば「０３」のタイプコード１３を使用してもよいし、世帯のルームメート／親戚の定義に従ってすべてのデータをリンクするのに「０Ａ」のタイプコード１３も使用できる。図４に示されるように、結果として生じるデータ２９内の各記録に対する追加添付リンクとしてかかるリンク１０を戻すことができる。
【００７２】
次に図７および８を参照し、本発明に係る実施例に従って、リンク管理を実行するための方法について説明する。レポジットリー２４は全住民（例えば米国内の消費者）に関する包括的な情報を含むが、かかる情報は常に流動的であるので、かかる人のすべてに関する望ましいすべての情報を含むことはできない。レポジットリー２４に新しい消費者および住所が提示されると、レポジットリーはこれらエンティティに対応する情報をリンクするのに新しいリンク１０を割り当てなければならない。しかしながら、このエンティティに関するより多くの情報が後に収集されるにつれ、このエンティティは実際に既に旧いエンティティとなるが、その時にレポジットリー２４で利用できる情報に基づき、このエンティティを１つのエンティティに変えることはできない。この問題に対する解決案は、２つのリンクを１つのリンクに統合することである。同様に、２つのエンティティが誤って１つのエンティティに統合された時も同様な問題が生じ、後で２つの別個の識別クラス３０を使用して、これらを２つの別個のエンティティとしてレポジットリー２４が維持しなければならないと判断される。この問題に対する解決案は、これら２つののエンティティの各々にデータをリンクするのに、別個のリンクを使用できるよう、新しいリンクを割り当てることである。
【００７３】
リンク統合および分割のプロセスでは、既にリンクが供給されているデータ所有者が自分のデータベースを再構築しなくてもよい。むしろこれらデータ所有者には単にリンク更新のテーブルを含む電子ファイルが提供されるにすぎない。例えば図７に示されるように、レポジットリー２４は第１消費者５０および第２消費者５２のために識別クラス３０を維持する。これら２人の消費者は自分たちに対応するデータをリンクするのに割り当てられた「１００」および「１５０」の異なるリンク識別子１４を有する。次に、第１消費者５０と第２消費者５２とが実際には同じ消費者であることを示す新しい関連データアイテム５４が、レポジットリー２４に入力されたと仮定する。この結果、消費者５６に対応するすべての情報を含む単一の識別クラス３０となるように、これら２人の消費者のための識別クラス３０がマージされる。ここでは、この情報のすべてをリンクするのに「１００」の単一リンク識別子１４が使用され、すべてのリンクの組から永久的に「１５０」の他のリンク識別子１４が破棄される。
【００７４】
この変化に関係するデータ所有者を更新するために、情報サービスプロバイダは統合メッセージ５８を送る。「１５０」の廃棄リンク識別子１４が生じた場合にこの消費者に対してこれまで使用された「１００」のリンク識別子１４と交換しなければならない旨を、統合メッセージ５８によってデータ所有者に通知する。次に、データ所有者は廃棄したリンク１０のすべての発生をサーチするソフトウェアルーチンを作動させ、このリンクを新しいリンク１０に置換するだけでよい。情報サービスプロバイダは関連するデータアイテム５４が受信されるとすぐに、統合メッセージ５８を送ることができるし、また、最終統合メッセージ５８が送られてから生じたすべてのリンク統合を表す周期的な統合メッセージ５８を送ってもよい。
【００７５】
次に図８を参照する。ここには、例としてリンク分割を実行するためのプロセスも示されている。レポジットリー２４は最初に消費者５６が単一の個人である情報を含み、これに対し、この消費者に対応するデータをリンクするのに使用される単一消費者リンク２６を含む識別クラス３０内にすべての対応情報が含まれている。次に、レポジットリー２４により関連データアイテム５４が受信されるが、この場合、関連データアイテム５４は消費者５６が実際には２人の異なる消費者であることを表示する。次に、消費者５６のための識別クラス３０を２つの識別クラス、すなわち第１の消費者５０のためのクラスと、第２の消費者５２のためのクラスとに分割するためのソフトウェアルーチンを実行する。これらエンティティの１つに対応するデータをリンクするのに、現在の消費者リンク２６を使用できるが、他の消費者に対応するデータをリンクするのに、新しい消費者リンク２６を指定しなければならない。
【００７６】
リンクスプリットに関し、データ所有者に通知をするために、統合メッセージ５８に対してこれまで説明した方法と同じように、スプリットメッセージ６８を公開する。データ所有者に定期的に送られる単一メッセージを形成するように、スプリットメッセージ６８と統合メッセージ５８とをマージできる。スプリットの場合、別の情報が必要とされる。その理由は、データ所有者はどのデータが旧い消費者リンクに関係しているか、更にどのデータが新しい消費者リンクでタグ付けされるかを知っていなければならないからである。新しいリンクにより特定の占有にタグ付けすべきかどうかを判断するのに再処理が必要となる。
【００７７】
次に図９を参照し、本発明の好ましい実施例を使ってデータ更新を実行する利点について説明する。データ所有者のデータ処理システムに対して本発明を実施する第１工程は、上記のようにデータ所有者のデータにリンク１０を重ねることである。図９の実施例では、顧客のデータ７０は物理的に独立した４つのデータベースからの記録、すなわち総計２千３百万の記録を含む。統合プロセス７２およびリンクアサイメント７４に顧客データ７０が入力される（このプロセスはレポジットリー２４からのデータに基づき、上記のように照合ソフトウェア２２によって実行される）。これとは異なり、統合プロセス７２をスキップし、顧客データ７０内の各ソースから直接リンクアサイメント７４にデータを送ってもよい。変更された顧客データ７０は各記録に追加されたリンク１０と共に顧客ファイル７６となる。最初にリンク１０を顧客データ７０へ割り当てるのに、データ所有者のデータの２千３百万の記録のすべてを処理しなければならないので、このような初期の構築はリソース集約的である。
【００７８】
次に、データ所有者がデータの毎月の更新を望むと仮定する。顧客データ７０のすべてを再処理する代わりに、更新データ７８を処理するだけでよい。更新データ７８はデータ所有者が前月に獲得した新しいデータを示す。このデータは、例えばデータ所有者が前の月の間に獲得した新しい顧客であり得る。図９の実施例では、更新データは２つの異なるデータベースからの１５０万の記録しか含んでいない。この更新データ７８は初期の構築に関連して上で説明したように、統合プロセス７２およびリンクアサイメント７４（または直接リンクアサイメント７４）に入力され、顧客ファイル７６と統合される。統合プロセス７２およびリンクアサイメント７４はレポジットリー２４内の情報に基づいており、顧客データ７０のすべてにわたる名前と住所の比較には基づいていないので、更新手続きを実行するのにファイル全体を再処理する必要はない。
【００７９】
本発明は所望する頻度で、例えば毎月、毎日または新しい記録を受信した時にリアルタイムでも更新を実行できるようにしようとするものである。レポジットリー２４内には照合に必要な情報のすべてが含まれ、よって顧客データ７０はクロス比較には使用されないので、更新データ７８を単一の記録程度に小さいファイルとすることができる。リアルタイム更新環境では、ちょうど新しい記録が受信された時に、この記録は情報サービスプロバイダへ更新データ７８として送られ、情報サービスプロバイダは即座に統合プロセス７２およびリンクアサイメント７４を実行するように、照合ソフトウェア２２を作動させ、よって顧客ファイル７６のリアルタイムの更新を可能にする。より頻繁に更新をすれば、各更新のボリュームを小さくでき、よって大きい更新をより少ない頻度で処理することによって生じる計算上のリソースのボトルネックを軽減できる。更により頻繁に、またはリアルタイムでも更新すれば、データ所有者は顧客のすべてに関する最も正確な情報を維持できるようになる。
【００８０】
リンク用リンクがデータ所有者のデータベース内の所定位置にあると、本発明の実施例に係わる１つのアプリケーションはデータ統合となる。今日の多くの企業は「顧客関係管理」（ＣＲＭ）プランを実現することが有利であると判断している。このＣＲＭプランの目標は企業が特定の顧客との関係を完全に理解できるようにすることにある。ＣＲＭはかかる情報が内部のソースから生じているのか、または外部のソースから生じているのかにかかわらず、各顧客に関して知られているすべての情報を企業が統合することを求める。この統合された情報は企業が所定の顧客が開始した相互対話に即座に応答できるよう、リアルタイムで利用できることが理想的である。ＣＲＭは顧客が関心をもっているすべての製品および製品ラインを知ること、企業の種々の部門のすべてにより顧客の購入履歴を知ること、および顧客の対応するデモグラフィック（または企業の場合にはファーモグラフィック）情報を知ることを含む。このタイプの情報を知ることにより、企業は自らが特定の顧客の関心に対して特別に合わされた販売努力およびマーケティング努力により、顧客に良好にサービスできることを見いだす。顧客も同じようにこのプロセスが望ましいと考える。その理由は、顧客が関心をもつ製品およびオファーが通知されるが、顧客が関心がないと表明した製品またはサービスを購入させるような勧誘はないからである。
【００８１】
成功できるＣＲＭプランのキーとなる要素は、特定の顧客に関する「顧客の全体像」を形成することである。この顧客の全体像はＣＲＭを容易にするような方法で配置された任意の数の異種の情報ストアから顧客のための対応するすべての情報を同化させることから成る。顧客の全体像システムを構築しようと試みる企業に対向する主な障害は、企業の情報ストアが通常同じように一貫しておらず、正確でなく、最新でない、同じ顧客に関する重複した情報を含んでいることである。この結果、同一個人に関する情報が種々の不一致と共に多数のデータベースまたは情報ストアに存在し得る。これらデータストアの各々は異なる顧客ナンバー割り当て方式を使用したり、または単に名前および住所の照合に依拠し得るので、内部情報だけを使ってこれらデータを成功裏にリンクすることは困難であり、高いレベルの正確さで達成することはできない。
【００８２】
図１０はこの問題の図解例を示している。会社データの表８０の各行は、小売業者の種々の部門の１つによって維持された別のデータベースから引き出された記録を示す。会社のデータの表８０の各列は、これら記録、例えば名前、住所および顧客の口座番号における特定のフィールドを示す。この場合の情報は販売店−自動車サービス、ホームサービス、小売販売およびスポーツ用品の「特別メーリングリスト」によって維持される４つの異なるデータベースから引き出される。各データベースからの記録は実際には同一の個人を示すが、各部門によって使用される名前の綴りのバリエーション、個人の住所の変更および異なる口座番号によって、内部で発生された照合ルーチンを使ってこのデータを照合することができなくなっている。従って、販売店はこれが４つの異なる個人ではなく、一人の個人であると判断することはできず、よって正確な顧客の全体像を構築することもできない。
【００８３】
次に図１１を参照すると、ここにはリンクされたデータの表９０と共に、この情報を照合するためにリンクを使用した結果が示されている。リンクされたデータの表９０では、会社の種々のデータベース上の各記録は適当なリンクによって補強されている。顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対する名前の変形スペルおよび住所履歴のすべてを含むレポジットリー２４は、これら記録の各々が同一個人に関する情報を含んでいると解決できる。これら記録に一旦正しいリンクのタグ付けがされると、販売業者は簡単なリンク照合方法により、この個人に関するデータのすべてを迅速かつ容易にリンクできる。販売業者はまたバイブ情報サービスプロバイダによって維持されているこの顧客に関する情報に迅速かつ容易にリンクし、よって小売業者のデータの更新または強化を可能にできる。
【００８４】
次に図１２を参照する。この図には顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈの顧客全体像を構築するための方法が示されている。小売業者の部門の各々によって累積された情報にはＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対する顧客リンク２６のタグが付けられている。この情報はホームサービスデータベース１００、小売販売データベース１０２および自動車サービスデータベース１０４に含まれている。相互対話データアクセスルーチン１０９を使用することにより、小売業者は顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに関連するデータをリンクするのに使用される消費者リンク２６をサーチし、そのリンクのタグが付けられたすべての記録を検索するだけで、顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対応するすべてのデータをサーチできる。更に小売業者は所望するように顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに関する追加情報を引き出すよう、情報サービスプロバイダが維持するレポジットリー２４にも接続できる。このリンク照合方法は計算上簡単であるので、リアルタイムで実行できる。この結果、顧客の全体像１０１が得られ、この全体像を通して小売業者は顧客との総合的な関係を即座に決定できる。顧客の全体像１０１により、例えば小売業者は顧客が好むと分かっている既製品またはサービスに集中することにより、より効率的にこの特定の顧客に対してマーケット努力を向けることができる。
【００８５】
図１２に示され、これまで説明した方法は、顧客関係管理に対応するいくつかの重要なタスクに使用できる。図１３は小売業者のインターネットウェブサイトを通して大規模小売業者にコンタクトする顧客１０３の例を示している。顧客１０３が自家用雨樋をオーダーすることを決定したと仮定する。次に顧客は小売業者が取引を促進するために維持しているインターネットウェブサイトにアクセスする。この業者はウェブサーバー１０８のホストとなっている。ウェブサイトにアクセスした際に、ウェブサーバー１０８上に維持されているソフトウェアにより、顧客が自分の名前および住所を入力することが求められる。次にウェブサーバー１０８は顧客１０３に関する情報をリンクするのに使用される消費者リンク２６を決定する。一旦一致が発見されると、相互対話データアクセス１０９はホームサービスデータベース１００、小売販売データベース１０２および自動車サービスデータベース１０４を含む小売業者の種々のデータベースのすべてをサーチし、このリンクに対する一致があるかどうかを見つけることができる。このデータは次にウェブサーバー１０８に戻される。リンクを利用して照合が実行されるので、このプロセスは対応する情報を含む特定の記録とウェブサーバー１０８の問い合わせに応答して顧客が入力した名前および住所との一致があるかどうかとは関係なく、顧客１０３に関するすべての対応データを戻す。更に、レポジットリー２４との接続によりリアルタイムで情報サービスプロバイダのレポジットリー２４から追加情報を検索するのにリンクを使用できる。好ましいことに、レポジットリー２４とのリンクはＯＬＴＰ技術によって行うことができる。次に、顧客１０３が見るようにカスタム化されたインターネットウェブページを即座に作成するよう、小売業者と情報サービスプロバイダとの組み合わされたデータはウェブサーバー１０８によって使用できる。このカスタム化されたウェブページは、例えばその顧客が特に関心を持つ特別なプロモーションをディスプレイしてもよい。本発明の実施例では、このプロセス全体をリアルタイムで実行でき、従って顧客１０３に対し顕著な遅れは生じない。
【００８６】
本発明の別の実施例では、データ所有者はウェブサーバー１０８による問い合わせに対する顧客１０３の応答を情報サービスプロバイダのレポジットリー２４へ直接送ることにより、顧客１０３が見るためのカスタム化されたウェブページを提供できる。次に、情報サービスプロバイダはレポジットリー２４内のデータと組み合わせてこの情報を使用し、顧客０１３に関するすべての対応する情報を照合するために適当な消費者リンク２６を探す。情報サービスプロバイダからの追加情報がリクエストされた場合、そのデータを適当な消費者リンク２６と共にウェブサーバー１０８へ戻すことができる。次に、上記のように、相互対話データアクセス１０９を使って小売業者が維持する顧客１０３に関するすべての情報を照合するのに、この消費者リンク２６を使用できる。顧客１０３のためのカスタム化されたウェブサイトを作成するのに、ウェブサーバー１０８によりこのようなデータの集合を使用できる。別の実施例では、このデータの集合は分析モデル化エンジン（図示せず）にも送られ、データマイニングおよびその他の分析機能を実行する。この分析の結果はウェブサーバー１０８へ戻され、顧客１０３のためのカスタム化されたウェブサイトの作成を助ける。
【００８７】
本発明は、小売業者が顧客に関するデータを更新する機会として、顧客の取引または入力を利用できるようにするものである。再び図１３を参照して、顧客１０３がジャクソンビルからフェニックスに最近引っ越ししてきたと仮定する。顧客１０３は自分の家には雨樋が必要であると判断し、小売業者の電子取引ウェブサイトによりインターネットを通してこれら雨樋をオーダーしようとする。ウェブサーバー１０８が顧客１０３に名前と住所の情報を求めると再度仮定する。小売業者の内部データベースのいずれにも顧客１０３の新住所は入っていないので、リンクなしに顧客１０３に関するすべての情報を正しく接続することは困難である。しかしながら、情報サービスプロバイダに名前と住所が送られた場合、レポジットリー２４がこれまでに引っ越しを示すデータを受け取っていることを条件に、情報サービスプロバイダはレポジットリー２４を使って顧客１０３のための正しい消費者リンク２６および住所リンク２８をウェブサーバー１０８へ戻すことができる。次に、小売業者はデータアクセスルーチン１０９を使ってこの顧客に対応するデータのすべてを検索するようにリンク照合を使用し、次にこの情報に基づき、顧客１０３のためのカスタム化されたウェブページを作成するのにウェブサーバー１０８を使用できる。顧客１０３が提供する更新された住所情報は、顧客１０３向けのクーポンおよび特別なオファーをこの正しい住所に後で郵送するのに、小売業者によって使用される。
【００８８】
更に別の例は、顧客関係管理の別の重要な特徴をリンク１０がどのように容易にしているかを示す。次に図１４を参照し、自分のオーダーした雨樋が定刻どおりに発送されていないことを顧客１０３がサービス代表者１０５に電話していると仮定する。次にサービス代表者１０５は相互対話データアクセスルーチン１０９を使って顧客１０３に関するすべての利用できる情報を即座に呼び出すことができる。この結果、サービス代表者１０５は顧客１０３がここしばらく小売業者とかなりの取引を行い、通常スポーツ用品を購入すると判断できる。顧客１０３と話しながらこれら事実を知ることにより、サービス代表者１０５は、最も重要な行動は顧客の次のスポーツ用品の購入にかなりのディスカウントをするためのクーポンを顧客１０３に提供することであると判断できる。従って、小売業者は顧客１０３に関するすべての利用できる情報にアクセスできることにより、特定の取引における貧弱なサービスにもかかわらず、顧客１０３を維持する最良の方法を決定できる。
【００８９】
本発明はデータ所有者が維持する種々のデータベースにわたってトリガー通知を実行するのにも使用できる。例えば大規模金融機関のためのこのプロセスが図１５に示されている。金融機関は法律サービスデータベース１４０、保険データベース１４１、小口バンキングデータベース１４２、投資バンキングデータベース１４３および会社データウェアハウス１４４を含む種々の運用のための物理的に別個のデータベースを維持している。不動産業者１４８は顧客１０３が新しい家の購入を検討中であることを知る。この情報は金融機関の他の部門、例えば小口バンキング部門および法律部門にも有益であり、これら部門はこの取引に関連して顧客１０３に自分たちのサービスを提供したいことがある。不動産業者１４８はこの情報をメッセージシステム１４２に入力でき、メッセージシステム１４２は次に照合リンクを使ってこの情報を即座に法律サービスデータベース１４０、保険データベース１４１、小口バンキングデータベース１４２、投資バンキングデータベース１４３および会社データウェアハウス１４４へ提供する。次に法律部門および小口バンキング部門で営業する人はこの情報にアクセスし、上記のようにリンクを使ったデータ統合を通して顧客１０３に関して維持された追加情報を検索できる。
【００９０】
この発明の別の用途は、情報が維持されているエンティティからの入力に応答するのではなく、むしろデータサービスプロバイダのレポジットリー２４に新しい情報が追加された時に、顧客ファイル７６上のデータを更新または補強することである。この新情報は自動的にこの情報が関係し、このサービスを受けたいエンティティに関する記録を維持しているデータ所有者に自動的にプッシュできる。次に図６を参照すると、ここにはリンクを使ったプッシュ技術が示されている。更新データ１５６としての特定顧客に関する追加情報により、レポジットリー２４が更新されると仮定する。小売業者Ａは自分の顧客ファイル７６にこのデータが関係する顧客に関する情報も維持しており、このファイル２６は小売業者のホームオフィスのデータセンターに維持されたデータベースとすることができる。小売業者Ａは以前プッシュサービスに加入しているので、情報サービスプロバイダは小売業者Ａが更新のプッシュを望んでいるエンティティに対応するすべてのリンク１０のリストを含む小売業者Ａのリンクリスト１５２を維持している。情報サービスプロバイダのモニタルーチン１５０は小売業者Ａのリンクリスト１５２をチェックし、更新データ１５６を顧客ファイル７６にプッシュすべきかどうかを判断する。他のデータ所有者がプッシュサービスに加入していると仮定すると、モニタルーチン１５０は同じようにこれら加入者の各々に関連するリンクリストをチェックする。モニタルーチン１５０は更新データ１５６内のリンクと各リンクリスト内のリンクを比較するだけでよいので、このプロセスを迅速に実行できる。モニタルーチン１５０が小売業者Ａのリンクリスト１５２内で一致を見つけた場合、このルーチンは公開ルーチン１５４へ更新データ１５６を送り、公開ルーチン１５４は次に更新データ１５６を小売業者Ａの顧客ファイル７４へ伝送する。この伝送は電話回線またはデータを電子的に送る他の任意の手段で行うことができる。顧客ファイル７６内の結果は更新された顧客リスト１５８となる。小売業者Ａはプッシュサービスに加入することにより、情報サービスプロバイダの巨大なリソースを活用し、国内規模の情報データベースにアクセスできる。一方、これと同時に顧客ファイル７６および小売業者Ａのリンクリスト１５２に維持されている情報によって示される企業に対応するデータの更新だけに支払いを行うだけでよい。
【００９１】
以上で、所定の好ましい異なる実施例を参照して、本発明について説明したが、これら実施例は単なる例示にすぎず、特許請求の範囲に記載した発明の範囲を限定するものではない。
【符号の説明】
【００９２】
１０ リンク
１１ ドメイン
１２ カントリーコード
１３ タイプコード
１４ リンク識別子
１５ アルゴリズムおよびキー記憶モジュール
２０ 入力ファイル
２２ 照合ソフトウェア
２３ ルックアップテーブル
２４ レポジットリー
２５ アルゴリズム識別子
２７ キー
３０ 識別クラス
３１ アルゴリズムモジュール
３２ 名前の履歴
３４ 住所の履歴
３６ 占有履歴
【技術分野】
【０００１】
本発明は、類似したエンティティに関するデータをリンクするためのシステムおよび方法に関する。より詳細には本発明は、リンクを生成するエンティティによる衝突を少なくするようにリンクを符号化したデータをリンクするためのシステムおよび方法に関する。
【背景技術】
【０００２】
実質的にすべての企業は顧客に関する情報を含むコンピュータ化されたデータベースを維持しなければならないと現在考えている。かかる情報は、例えば課金をしたり、販売および新製品に関して顧客に情報を与えるための種々の態様で使用できる。この情報はコンピュータデータベース内に一連の記録として一般に電子的に記憶され、各記録は特定の顧客に関係している。記録とは、当業者に周知の任意の数の方法でコンピュータデータベース内で実現できる論理的な概念である。使用されるデータベースはフラットなデータベースでもよいし、リレーショナルデータベースでもよいし、またその他のいくつかの公知のフォームの１つでよい。データベースにおける各記録は種々のフィールド、例えば顧客の姓名、住所、ストリート住所、市、州および郵便番号を含むことができる。これら記録は、より複雑なデモグラフィックデータ、例えば顧客の婚姻状態、概略の収入、趣味または購入履歴も含むことができる。
【０００３】
企業は一般に多数のソースから顧客のデータを収集する。これらソースは顧客の購入のような内的なものもあれば、情報サービスプロバイダが提供するデータのような外的なものもある。多数の情報サービスプロバイダは企業に販売したり、またはリースしたりする広範なベースの消費者情報を有する大規模なデータベースを維持している。例えばカタログ販売企業は特定の地理的エリアにおける潜在的な顧客のリストを購入できる。
【０００４】
企業は顧客データを集めるのに種々の方法を利用するので、企業は顧客に関する冗長な情報を含む、いくつかの、大規模であるが完全に独立したデータベースを持つことが多いが、これら企業は特定の顧客に関する情報のすべてを正確にリンクする手段を持っていない。この問題の１つの一般的な一例として、銀行が小切手および預金口座保持者用のデータベース、クレジットカード保持者のための別個のデータベースおよび投資クライアントのための別個のデータベースを維持する例が挙げられる。別の一般的な例として、大規模な小売業者が、例えば自動車の修理、家のリフォーム、伝統的な小売販売、電子商取引および眼鏡サービスを含む部門または営業ラインの各々をサポートする別々のデータベースを持つ例が挙げられる。
【０００５】
多数の独立したデータベースを有する企業は、顧客のうちの誰が多数のサービスを利用しようとするのかを知るのは特に有益と考えている。例えば、ある銀行が、自分の預金口座に１００ドルしか持っていない顧客が１０万ドルのブローカー口座を維持すると判断できれば、この顧客に対して豊富な銀行サービスを提供したいと考える場合がある。この情報も、例えばクロス販売の機会を活用したり、現在の顧客のベースに最良のサービスをするための種々のサービスを最適にする上で、企業を補助するのにも有効となり得る。
【０００６】
各顧客に関する有益なすべてのデータをリンクすることによって、企業の部門の各々が各顧客に関する最新の情報にアクセスできるようにもなる。例えばある顧客が結婚したり、引っ越ししたりした場合、顧客はこの転機に関する情報を企業の部門の１つにしか通知しないことがあり得る。例えばメンフィスに在住する長年の価値ある顧客であるスー・スミス（Ｓｕｅ Ｓｍｉｔｈ）さんが、ミネアポリスに在住するスー・トンプソン（Ｓｕｅ Ｔｈｏｍｐｓｏｎ）となったことを仮定すると、企業のデータ処理システムのうちの１つしかこの転機について知らなかった場合、他のシステムは、ミネアポリスのスー・トンプソン（Ｓｕｅ Ｔｈｏｍｐｓｏｎ）がメンフィスのスー・スミス（Ｓｕｅ Ｓｍｉｔｈ）と同一人物であると判断できない。この問題は顧客の価値が企業に合うものとして顧客を扱うことを阻害し得る。長い期間にわたる顧客をあたかも新しい顧客であるかのように扱うことは失礼なことになりやすく、この結果、顧客の企業を失うことにもなり得る。
【０００７】
この問題を解決するのに使用される最も古い方法の１つは、どの顧客に対してもある番号を割り当て、次にこの番号を使って照合、サーチおよびデータ操作作業をすることである。大規模な内部の顧客データベースを維持している多くの会社はこのタイプのシステムを実現している。理論的には、各顧客の番号は顧客が自分の名前または住所を変えたとしても、各顧客に対して常に同じままである。これら番号は顧客に出荷されたパッケージの課金または追跡のために内部で使用できる。例えば顧客の名前および住所を識別子として使用した場合、顧客の識別番号を使用することは潜在的な不明確さを解消する。特に金融機関は各取引に関する適正な顧客を明確に識別するために、個人識別番号（ＰＩＮ）を使用している。
【０００８】
顧客番号システムは本来は所定の用途だけに限定される。顧客識別番号は名称および住所の常に変化する国内の包括的なリストを管理するようにはなっていない。これら番号を維持する会社は一般に自分の顧客とうまくやることにしか関心がない。従って、かかる番号の割り当て方法は全く簡単である。すなわち顧客が取引を求める会社にアプローチしてきたときに、その顧客に対して新しい番号が割り当てられる。この顧客番号は所定の顧客に対する住所および名前の履歴を管理できる広範なベースのプロセスの結果として決まるものではない。重要なことに、顧客番号は、番号を作成する企業に対して顧客自身が提示した情報だけに基づいて割り当てられる。これら番号は会社の日々の取引とは独立して機能するマルチソースデータレポジットリーからは割り当てられない。端的に言って、かかる番号の目的は単に取引の管理にあり、ユニバーサルなデータのリンクにはない。かかる番号は一般に、ある期間活動がなければ、会社によって廃棄されるので、かかる番号は真に永続的なものでもない。更に、顧客番号の割り当て方針の焦点は単に営業内部の取引であるので、取引が進行しない番号を永続的に維持する理由はない。どの会社も異なる組の顧客番号を維持しているので、データを外部からリンクするのにこれら番号を使用することはできない。
【０００９】
これまで消費者に対しては外部から使用されるユニバーサルな番号割り当てシステムは使用されていないが、これらシステムは小売用製品に対して使用するのに公的に利用できる状態になっている。１９７０年代初期に「バーコード」として広く知られるユニバーサルな製品コード（ＵＰＣ）システムの使用が開始した。この時期に、すべてのメーカーに共通する符号化システムのニーズが食料雑貨店企業で生じた。今日、ユニフォームコード協議会（ＵＣＣ）が小売製品に対して使用するためのすべてのバーコードの割り当てに責任を果たしており、メーカーに関係なく、どの製品に対してもユニークなＵＰＣ番号が維持されている。誰でもコードを使用できるように、これらコードのデータベースは公的に利用可能になっている。このデータベースを使用することにより、どの小売業者も自分の店の棚にある各製品に関する価格およびその他の情報を追跡できる。今日の製品販売チェーンも製品を追跡したり、物流および販売チャンネルに関する判断をするのに、ＵＰＣシステムに大きく依存している。
【００１０】
ＵＰＣシステムは大きな成功を収めたが、このシステムの有効性は限られている。新製品に対してＵＰＣ番号を得るのに、メーカーはまずＵＰＣ番号を申請し、ＵＣＣデータベースに製品と番号を追加し、メーカーは販売前にその製品に対して正しいバーコードを添付する。既に存在する製品に対してＵＰＣ番号を割り当てる方式もなければ、ＵＰＣ番号が表示する製品とＵＰＣ番号を照合する方式もない。更に、各ＵＰＣ番号は小売販売のためにパッケージされた単一の固有の物品を示しているので、単一のＵＰＣ番号が割り当てられる特定製品の種々の要素を識別するための方式はない。従って、ＵＰＣシステムは消費者に関する既に存在する種々のデータをリンクするのには使用できない。
【００１１】
個人に対し識別番号システムを使用することによって生じる、究極的かつ極めて重要な問題はプライバシーである。顧客識別番号を会社内部でしか使用しない場合ほとんどプライバシーの問題は生じない。しかし、個人に関して顧客識別番号、すなわちＰＩＮを外部で使用した場合、個人のプライベートなデータが他人によって不正または不法に使用されたり、共用され得る危険性が増す。この問題は、自分のクライアントの顧客データベースでデータを追跡する手段として、情報サービスプロバイダが顧客識別番号、すなわちＰＩＮを発行した場合に特に問題となる。かかる会社は一般に多数のクライアントを持っておりこのうちの多くは実質的に重複した顧客リストを有することがある。これらクライアントは自分の顧客に関するより多数の情報を集めるために互いにデータを内密に共用したいことがある。かかるクライアントは顧客情報番号を単に照合することに基づき、集中的に自らの顧客データベースを併合したりまたはその他の方法で使用することは比較的簡単であると分かっている。複数のクライアントが内密でかかる努力をした場合、情報サービスプロバイダは情報がどのように使用され、共用されるかをもはや管理できなくなる。従って、情報サービスプロバイダのクライアントは情報サービスプロバイダが個人情報の不正使用を防止するためにとり得るどんな保護対策も迂回できる。
【００１２】
顧客識別番号システムの別の限界は、ファイルをマージしたり、重複したエントリーを除くために使用される方法にある。かかるシステムにおける重複を除き、別個のデータベースに維持されている顧客データをリンク（または統合）するための唯一の包括的方法は、歴史的には、最初から対応するデータベースを再構築することであった。多くのかかるデータベースは何千万もの記録を含んでいるので、データベースを完全に再構築するコストは実現不可能なほど費用がかかることが多い。更にこれらデータベースは古い顧客が離れたり、新しい顧客が生じたり、顧客情報が変わり、常に流動的であるので、すべての情報を妥当な程度に最新状態に維持するには、再構築方法を定期的に繰り返さなければならない。
【００１３】
企業はデータの統合および重複除去サービスをするのに情報サービスプロバイダに伝統的に頼っている。情報サービス企業は種々の重複除去解決方法を解決するのに、近年膨大な専用リソースを有している。これら解決方法は事後に実行される。すなわちデータ所有者のシステム内で重複しているエントリーを例示した後で実行される。メンフィスのスー・スミスとミネアポリスのスー・トンプソンに対するデータの記憶が同じ人に関するものであるかどうかを判断するには、重複除去ルーチンは多数のデータフィールドを分析しなければならない。単に名前と住所を比較するだけでは多くのケースでは一致が得られない。名称および住所が同一であるケースでも、このことは記録が同一個人に関するものであると表示できない。その理由は、例えばデータが父親および自分の父親の名前をとった息子であることがあり得るからである。多くのデータベースが不完全または不正確な多数のデータを含むという事実により、問題を有効に解決することがより困難となっており、多くのケースでは完全な解決が不可能である。
【００１４】
重複除去ルーチンは必ず複雑であるが、これらルーチンは高速度でも実行しなければならない。これらルーチンは何千万もの記録を有するデータベースの重複を除去するのに使用される。かかる大規模データベースの場合、重複除去機能を実行するソフトウェアのサブルーチンは１回の重複除去セッションの間に何百万もの回数コールされることがある。従って、これらサブルーチンは極めて高速で実行しなければならず、高価なコンピュータ機器は妥当な時間で重複除去ルーチンを完了するのに必要なパワーを有していなければならない。重複除去方法はリソース集約的であるので、かかるタスクは今日これらルーチンを効率的に実行するのに必要な膨大な計算能力にアクセスする情報サービスプロバイダまたはデータ所有者によってしか実行できない。
【００１５】
更に、重複除去ルーチンは必ずある推定作業を行う。上で説明したように、重複除去は不完全であり得る利用可能なデータに基づく。従って、重複除去ルーチンの結果は利用できる情報と同じ程度に良好であるにすぎない。名前および住所情報の固有の不明確さにより、どのシステムも顧客データベース内の重複を１００％除去することはできない。その結果、データベースは同じ顧客の多数の記録と単一の顧客であるかのように１つの記録にマージされた多数の顧客との事例を含む。この問題の結果としてよく知られていることは、メールオーダー小売業者から同じカタログを何部も顧客が受け取ってしまうようなことである。かかる経験は顧客に対してフラストレーションを与え、その結果、小売業者の費用が増すことになる。
【００１６】
歴史的に、企業用データベースを情報サービスプロバイダが統合する方法は時間がかかり、労力集約的であった。種々の広範なデータベースフォーマットが使用されているので、情報サービスプロバイダはまずデータベースのソースファイルを処理するための標準フォーマットに変換しなければならない。次に、情報サービスプロバイダは上記のように複雑な重複除去プログラムの１つを作動させる。企業用データベースにおけるデータは重複除去ルーチンの精度を改善するために情報の外部ソースで増加し得る。この結果生じるデータベースのファイルは、プロセスを完了するのに企業用データベースファイルフォーマットにフォーマット化し直される。この全手順は情報サービスプロバイダの技術員による大きな直接関与を必要とするが、このことはサービスのコストにおいて重要な要素となる。
【００１７】
このデータ統合方法の大きな限界は、サービスがリクエストされるごとに全プロセスを繰り返さなければならないことである。１つの記録に対するデータ統合は一度に実行できず、また既に更新された記録に対してしか実行できない。この理由は、データ統合プロセスは同様な（従って、重複の可能性がある）記録のグループ分けを行うのに、データの記録のすべてを互いに比較することに依拠しているからである。比較プロセス中、通常、照合リンクが作成されるが、これらリンクは一時的なものであり、プロセスが一旦完了すればなくなる。これらリンクはサービスを実行するごとに最初から作成し直さなければならない。これらリンクはすべての可能な顧客の全体を通して一義的ではなく、情報サービスプロバイダによって維持されないので、これらリンクを再使用することは不可能である。
【００１８】
現在のデータ統合方法の最も重要な限界の１つは、この方法をリアルタイムで実行できないことである。すなわちこのプロセスはバッチモードでしか実行できない。リアルタイムのデータ統合は小売業者または他のデータ所有者が特定の顧客からの入力に対して即座にカスタム化された応答をするのを可能にするので、このようなリアルタイムのデータ統合が極めて望ましい。例えば特定の顧客が小売業者のウェブサイトにアクセスした時には、その顧客に関する利用できるすべての情報をリンクし、その顧客の関心およびニーズに特に合わせたウェブページを表示することが望ましい。その他の応用例としては、小売業者での購入が進行中に特定の顧客のクレジットカードの“読み取り”に応答して、カスタム化されたクーポンまたは販売情報を提供することが挙げられる。
【００１９】
顧客入力に対し、カスタム化された応答をするための従来のシステムは、内部の顧客番号の一致に基づいている。例えばある食品雑貨店が特定の顧客を識別するのにバーコードを含むメンバーカードを配布する。顧客が自分のメンバーカードをレジカウンターで提示すると、カードのバーコードがスキャンされて、顧客の識別番号を判断する。次に、店のデータ処理システムは自動的に購入履歴データベースに相談し、顧客の固有の購入傾向に合わせたクーポンをプリントする。
【００２０】
内部顧客番号に基づく１回記録処理にはいくつかの重要な限界がある。まずこのシステムは番号を既に割り当てた確立された顧客に対してしか働かない。新しい顧客が店に入った場合、システムが顧客を認識する前に、その顧客に対してメンバーカード（および対応する識別番号）を発行しなければならない。当初、店はこの顧客に関して何も知らない。更に上記のような個人のプライバシーの問題により、顧客識別番号のこのシステムの使用は外部からの使用に対してアクセスできない。
【００２１】
従来のデータ統合方法の更に別の限界は、顧客に関するデータが変わった時に企業が各顧客に対して維持しているデータを企業が遠隔的かつ自動的に更新したり、また増強する手段を提供できないことである。更新データまたは増強データを提供する従来のバッチモードの方法は労力がかかり、スタートから最終まで数週間かかることがある。まずデータの補強を求める会社は顧客データベース内の各記録に対するエントリーを含む抽出ファイルを構築しなければならない。この抽出ファイルはコンピュータで読み取りできる媒体、例えば磁気テープに記憶され、この媒体は増強のために情報サービスプロバイダへ出荷される。広範な種々のデータベースフォーマットが使用されているので、情報サービスプロバイダはまず抽出ファイルを処理できるように情報サービスプロバイダの内部フォーマットに変換しなければならない。次に、情報サービスプロバイダは抽出ファイルのこの標準化されたバージョンを使って会社のデータベース内の情報と、情報サービスプロバイダが維持するすべての情報とを比較するソフトウェアアプリケーションを実行する。次に、会社の標準化された抽出ファイルに更新データまたは増強データが重ねられる。
【００２２】
このデータ更新および増強方法の重要な限界は、データのわずかな部分だけを更新しなければならない時でも企業のデータベースを再構築しなければならないことである。例えば毎月１回小売業者が顧客データベース内の住所を更新したいとする。ほとんどの顧客は１カ月以内に住所を変えることはない。しかしながら、従来の更新情報は、引っ越しした数人の顧客をキャッチするのに、小売業者がデータベースを完全に再構築することを求める。
【発明の概要】
【発明が解決しようとする課題】
【００２３】
このようなすべての理由から、データ統合、更新および増強を改善し、一回記録、リアルタイムのデータリンクを実行し、プライバシーの問題を引き起こすことなく、外部から使用できる明瞭なデータリンクシステムを開発することが望ましい。
【課題を解決するための手段】
【００２４】
本発明は関連するデータを照合するための不明瞭でないリンク方式を作成するのに、持続したリンクを使用するためのシステムおよび方法に関する。これらリンクは特定のエンティティに関するすべてのデータにタブを付けるのに使用される一義的な文字数字の列として実現できる。これらリンクは、情報サービスプロバイダによって作成され、符号化されたフォームでプロバイダの顧客が使用できるように外部へ配布できる。上記顧客識別番号と異なり、リンクの作成は顧客がデータ所有者にアプローチすることに依存していない。これらリンクを作成する情報サービスプロバイダは、ある国または当該エリアの全住民に関する情報と共にデータベースを維持でき、リンクのリストを最新に維持するよう、住所、名前、ステータスおよびその他のデモグラフィックデータの変更に関し、住民を常にモニタする。新しいエンティティが識別されると、新しいリンクが割り当てられる。
【００２５】
本発明は更にリンクを符号化する方法にも関する。多数のクライアントに対して同じリンクを発生することによって、情報サービスプロバイダが関与することなくクライアントが協力し合ってクライアントの間で情報を共有できるようになる。本発明によれば、リンクを外部に発行する前にリンクはクライアント固有のキーで符号化される。情報サービスプロバイダが再びその特定のクライアントデータにアクセスすると、クライアントのリンクを複号化するのにクライアント固有のキーが使用される。このように、符号化されていないリンクにより情報サービスプロバイダによる内部処理が常に実行できる。このような符号化方式により、クライアントが不正に情報を共用することは困難となる。複号化作業が十分困難なタスクとなり、複号化を商業的に不可能にできるような符号化技術が選択されている。更に本発明の一実施例は、データの不正共用をより困難にするために、多数の符号化アルゴリズムを使用している。好ましい実施例では、顧客のアイデンティティに対応するフィールドの部分だけを符号化すればよいように、リンクは種々のフィールドに分割される。
【００２６】
各リンクの一義性を維持するために、これらリンクは情報サービスプロバイダによって運用される単一の中央レポジットリーによってしか作成されず、このプロバイダによって内部で使用されるだけである。情報サービスプロバイダの情報でも完全とはならないので、２つ以上のリンクを単一リンクに組み合わせたり、また単一リンクを２つの異なるリンクに分割するような形態で、リンクの管理を定期的に実行しなければならない。このプロセスはすべてのリンクユーザーに送信される統合されたスプリットリンクのリストを発行するだけで実行できる。この管理方法によって、リンクを最新状態に維持するためのデータベースの完全な再処理が不要となる。
【００２７】
リンクは情報サービスプロバイダによって維持される中央レポジットリーによって作成されるので、従来のシステムよりも不明瞭さはより効果的に解決できる。中央レポジットリーは情報を維持する各エンティティに関するすべての利用可能なデータを含む識別クラスを作成できる。この識別クラスの目的は、適当なリンクを使って特定のエンティティに関するすべての利用可能なデータをリンクすることである。この情報の多くは配信されなくても、これら情報はデータの統合、更新または増強リクエストに応答して、正しいリンクが顧客のデータに割り当てられることを保証するために、照合プロセスで使用できる。識別クラスは名前の通称、共通する名前のミススペル、姓名の変更の履歴、住所の履歴、街路の通称および照合目的に有効なその他の対応する情報を含むことができる。この識別クラス構造によって従来可能であったよりもより正確な照合および重複除去が可能となる。例えば、知られている通称を使用することにより、中央レポジットリーは「Ｓｕｅ Ｃ．Ｓｍｉｔｈ」、「Ｃａｒｏｌ Ｓｍｉｔｈ」、「Ｓｕｅ Ｔｈｏｍｐｓｏｎ」に関する別個のデータベースの記録の各々は、同一人物を示すことを認識し、この人物に関する対応するすべての情報をリンクするために、単一リンクを割り当てる。
【発明の効果】
【００２８】
リンクは永続的であり、ドメイン内で普遍的に一義的であるので、これらリンクは特定のデータプロバイダによる使用にしか限定されていないし、また、特定の照合セッションに限定されているわけではない。むしろこれらリンクは特に対応するデータの任意の所有者に外部へ配信するようになっており、終了するものではない。データの所有者はリンクを受信し、これらを現在のデータと照合すると、一度に１つぐらいの少ない記録を使用して、バッチモードまたはリアルタイムのいずれかで、多数の内部データベースからのデータを高速で比較し、照合し、サーチし、統合するのにこれらリンクを使用できる。
【００２９】
例えば個々の顧客、企業、住所、世帯、占有に対応するデータをリンクするのに、種々のタイプのリンクを使用できる。占有リンクは顧客または企業および特定の顧客が特定の時間に在住する住所に関する情報に関するものであり、世帯リンクとは、世帯を共有すると判断されたすべての人物に関する情報に関するものである。何が世帯を構成するかの定義はアプリケーションごとに異なることがあるので、同時に使用される多数のタイプの世帯リンクがあり得る。更に個人の住所の履歴を維持するのに一連のリンクされた住所リンクを使用できる。個人の間の氏名の類似によって生じる不明瞭さは住所の履歴を使用することにより、より簡単に解決でき、住所の変更にもかかわらず、個人のデータに正しいリンクのタグを付けることができる。
【００３０】
既に上で指摘したように、従来の重複除去ルーチンは複雑であり、リソース集約的である。これらルーチンは利用可能なデータに限定されているので、１００％正確に実行することはできない。しかしながら、本発明によれば、データ処理システムに新しいデータを追加することは、リンクを互いに照合する程度に簡単である。リンクの照合はリアルタイムでデータ処理システムにデータを追加する際に実行できる計算上簡単なプロセスである。
【００３１】
本発明は多数のデータベースが維持されるデータ統合のプロセスを大幅に簡略化するためのリンクも使用する。特定のエンティティに関する既知のすべての情報が要求されると、データ所有者は当該エンティティに関連するリンクによってリンクされている情報に関する各データベースをサーチするだけでよい。例えば別個のデータベースで情報が維持されている２人の顧客が実際に同じ個人であるかどうかを判断するようになっている複雑な照合アルゴリズムを実行する必要はない。従って、これらリンクによってデータ所有者は、データベースが特定のエンティティに関する情報のすべてに容易にアクセスできる総合的に単一の仮想的データベースであるかのように、物理的に離れているデータベースの各々を扱うことができる。
【００３２】
データをリンクするためにリンクを使用することによっても、データの増強、データの統合および関連するデータ処理に関係するプライバシーの問題を大幅に少なくできる。適当なリンクが一旦データ所有者のデータに一致すると、リンクの単なるリストとして情報サービスプロバイダに更新および増強リクエストを送ることができる。これらリンク自身はリンクが関係するデータに関する情報を含んでいない。従って、かかる送信データを内密に傍受しようとする者は、送信データからプライベートなデータを抽出できない。更に、当該リンクは単なるデータリンクであり、ＰＩＮ、すなわち顧客識別番号ではないので、リンクを外部で使用することに関連した個々のプライバシーが漏れる危険が大きくなることはない。
【００３３】
これらリンクは更に顧客の入力に応答してすべての対応するデータを即座に収集できるように、リアルタイムに一度で記録のリンクを可能にする。特定の顧客のためのすべてのデータを収集することにより、データ所有者はそのデータ所有者とその顧客との間の相互対話をカスタム化するのに使用できる「顧客の全体像」を構築できる。すべての対応する顧客データを検索するために、多数のデータベースを調べなければならない場合、対応するリンクにリンクされているデータに関して各データをサーチするだけでよい。データ所有者は自分のデータのすべてをリンクするのにこれらリンクを使用したり、特定の顧客に関するデータを即座に増強するよう、情報サービスプロバイダによって維持されたデータとリンクできる。顧客のデータが受信された瞬間にリンクプロセスを実行するので、検索されたデータは利用できる最も最近に更新された顧客情報となる。データ所有者のデータベースと情報プロバイダのデータベースとの間のリンクは、これらリンクを使ったＯＬＴＰ（オンライン取引処理）で行うことができる。これらリンクは「トリガー通知」を実行するのにも使用できる。トリガー通知とは、特定のエンティティに関する新しい情報が受信された時に、リンクされているどのデータベースに対しても更新メッセージを自動的にトリガーすることである。これらリンクを使用することにより、トリガー通知はほとんど瞬間的に行うことができるので、例えば大規模な小売業者の各部門は顧客から受信した最新情報を活用できるようになる。
【００３４】
１回記録の処理の別の利点としては、情報サービスプロバイダからその顧客にデータをプッシュできることが挙げられる。例えば情報サービスプロバイダが特定の個人の名前が変わったことを知り得る。新しい情報とこの個人に関するすべてのデータをリンクするのに使用されるリンクとを含むメッセージを使用することにより、この変化を顧客のデータベースに自動的にプッシュできる。更新プロセスはリンクを照合するだけでよいので、情報サービスプロバイダまたは顧客のいずれかによる直接的な介入をすることなく、自動的にこのプロセスを実行できる。
【００３５】
情報サービスプロバイダのデータの外部への配信に関連して生じる別の問題は、ある会社のデータがその会社の競争相手に不注意で配信されることである。例えば会社Ａは多くの理由の１つからそのデータにリンクを適用させたいことがある。情報サービスプロバイダは既に会社Ｂ、すなわち会社Ａの競争相手から得た会社Ａの顧客に関する情報を照合データベース内に既に有している場合がある。この情報サービスプロバイダはプライベートなデータが会社Ａとの間で共用されないことを会社Ｂに保証できなければならない。本発明におけるリンクを使用することにより、このようなスクリーニングプロセスは自動的となる。情報サービスプロバイダはその内部リンク形成およびリンクプロセスの一部として双方の会社のデータを使用できる。しかし、リンクと共に会社から得た情報だけを戻すことにより、リンクを受信した会社は、任意の人のデータを得ることはできないが、自分のデータを得ることはできる。リンク自身はプライベートな会社の情報を開示しないので、別個のスクリーニング機能を実現するための条件はない。また、情報サービスプロバイダはリンクを発生して付加するのにすべての利用可能なデータを利用するので、不完全または部分的に不正確なデータと共に正しいリンクが会社に配信され得る。
【００３６】
従って、本発明の目的は、永続的なリンクを使ったデータ処理システムを提供することにある。
【００３７】
本発明の別の目的は、普遍的に一義的であるリンクを使用したデータ処理システムを提供することにある。
【００３８】
本発明の更に別の目的は、リンクを使用した多数の内部データベースを通してデータを統合できるようにすることにある。
【００３９】
本発明の目的は、リンクを使用してデータベースで自動的に重複を除去することができるようにすることにもある。
【００４０】
本発明の別の目的は、リンクを使用してデータの更新および増強を可能にすることにある。
【００４１】
本発明の更に別の目的は、クライアント固有のキーによりリンクを符号化することができるようにすることにある。
【００４２】
本発明の別の目的は、異なるクライアントに提供されるリンクのための複数の符号化アルゴリズムを提供することにある。
【００４３】
本発明の更に別の目的は、リンクを使用するデータのリアルタイムの１回記録の処理を提供することにある。
【００４４】
本発明の更に別の目的は、リンクを使用するリアルタイムでの物理的な別個のデータベースから顧客の全体像を作成できるリンク能力を提供することにある。
【００４５】
本発明の更に別の目的は、リンクを使用したリアルタイムでの顧客入力へのカスタム化された応答をすることにある。
【００４６】
本発明の更に別の目的は、リンクを使用してトリガー通知を実行することにある。
【００４７】
本発明の更に別の目的は、リンクを使用し、中央レポジットリーから顧客のデータベースへ更新データを自動的にプッシュすることにある。
【００４８】
以下、簡単に説明するように、添付図面に関連し、好ましい実施例の次の詳細な説明を検討することにより、本発明の別の目的および利点が明らかとなろう。
【図面の簡単な説明】
【００４９】
【図１ａ】本発明の好ましい実施例に係わるリンクの構造を示す図である。
【図１ｂ】リンク符号化方法を示す図である。
【図１ｃ】リンク複号化方法を示す図である。
【図２】本発明の好ましい実施例に係わる、顧客リンクと、住所リンクと、占有リンクとの間の関係を示す表である。
【図３】本発明の好ましい実施例による、小売業者の顧客データベースにリンクを使用した結果を示す図である。
【図４】本発明の好ましい実施例による、顧客データベースにリンクを適用するための方法を示す図である。
【図５】本発明の好ましい実施例による、情報サービスプロバイダのデータレポジットリーに常駐する識別クラスオブジェクトの構造を示す図である。
【図６】本発明の好ましい実施例による、住所情報のエラーにかかわらず、顧客データをリンクするための方法を示す図である。
【図７】本発明の好ましい実施例によりリンクを統合することにより、リンク管理を実行するための方法を示す図である。
【図８】本発明の好ましい実施例による、リンクを分割することによってリンクの管理を実行するための方法を示す図である。
【図９】本発明の好ましい実施例による、顧客データベースへのリンクの初期の割り当ての処理と、同じデータベースへのリンク情報のその後の更新と、の違いを示す図である。
【図１０】本発明の好ましい実施例による、リンクでタグを付ける前のいくつかの企業部門を有する小売業者のための代表的なデータの表である。
【図１１】本発明の好ましい実施例による、リンクでタグを付けた後のいくつかの企業部門を有する小売業者のための代表的なデータの表である。
【図１２】本発明の好ましい実施例による、リンクを使用して顧客の全体像を作成する方法を示す図である。
【図１３】本発明の好ましい実施例による、リンクを使用してカスタム化されたウェブページを作成するための、消費者入力に応答する方法を示す図である。
【図１４】本発明の好ましい実施例による、リンクを使ったコールセンターの応答を改善するための方法を示す図である。
【図１５】本発明の好ましい実施例による、リンクを使った「トリガー通知」の顧客関係管理を示す図である。
【図１６】本発明の好ましい実施例による、リンクを使ったプッシュ技術の使用を示す図である。
【発明を実施するための形態】
【００５０】
次に図１ａを参照する。この図には、本発明の実施例で使用されるリンクの構造が示されている。各リンク１０を１６桁の文字数字の列として電子的に記憶できる。リンク１０は４つの要素から構成されている。すなわち４つのキャラクターとして記憶されるドメイン１１と、２つのキャラクターとして記憶されるカントリーコード１２と、２つのキャラクターとして記憶されるタイプコード１３と、８つのキャラクターとして記憶されるリンク識別子１４とから構成されている。
【００５１】
ドメイン１１は各クライアントに対し情報サービスプロバイダが割り当てる一義的なクライアント番号を示す。各ドメイン１１は特定のクライアントに対し一義的であるので、このドメインをクライアント固有の符号化キーに対するポインタとして使用できる。ドメイン１１の一義的なクライアント番号を４つの３２進のキャラクターとして記憶することが好ましい。従って、ドメイン１１に対しては１０４８５７６個の可能な一義的な値があり、これら値は二人のクライアントが一致した組の符号化されたキーを有する危険性を生じることなく、本発明のこの実施例を使って情報サービスプロバイダが取り扱うことのできるクライアントの総数を示す。実施例では、ドメイン１１の１つの値（例えばゼロの値「００００」）は情報サービスプロバイダ自身を示し、この値は内部で使用され、よって符号化されないリンク１１に対して使用される。
【００５２】
情報サービスプロバイダが１０４８５７６よりも多い数のクライアントを有しているとしても、多数のクライアントに同じクライアント番号を割り当てることを禁止するものはないと認識すべきである。１０４８５７６番目ごとのクライアントしか一致しない組のリンク１０を有する場合、かかる２つのクライアントがこの事実を認識し、不正にデータを共有しようと試みる可能性はとるにたらないほど少ない。
【００５３】
カントリーコード１２は入力データに対する発生カントリーに対応する一義的な２つのキャラクターのコードを示す。これらコードは２桁のカントリーコードのためのＩＳＯ−２規格に対応している。カントリーコード１２は例えば対応するデータを収集した元の種々の国、または対応するデータが関係する種々の国の国内のプライバシー法に従って、情報サービスプロバイダがデータを別々に取り扱うのに重要となり得る。
【００５４】
タイプコード１３はリンク１０が示すリンクのタイプを識別する２つのキャラクターコードを示す。このタイプコード１３は２つの３２進のキャラクターとして記憶することが好ましい。従って、タイプコード１３の値は総計１０２４個が可能である。実施例では、タイプコード１３の最初の桁は当該リンク１０が（以下、より完全に説明するように）維持されているのか、または誘導されたのかのいずれかを示すのに使用され、タイプコード１３の第２桁はリンク１０が消費者リンク、住所リンク、占有リンク、世帯リンク、または同等なリンクのうちのどれであるかを示すのに使用される。例えば「０３」なるタイプコード１３は、対応するリンク１０が維持されている住所リンクであることを示すことができる。
【００５５】
リンク識別子１４は情報サービスプロバイダによって追跡される特定タイプの各エンティティに対してユニークな８つのキャラクターのコードを示す。このリンク識別子１４は８つの３２進のキャラクターとして記憶されるので、リンク識別子１４に対するユニークな値は総数１,０９９,５１１,６２７,７７６個あり得る。このリンク識別子１４は特定タイプの同じエンティティに対して発行される重複したリンク識別子１４がないように、情報サービスプロバイダによって生成される。
【００５６】
次に図１ｂを参照し、本発明の実施例に係わる、リンクを符号化する方法について説明できる。情報サービスプロバイダにより内部に維持されるリンク１０は、上記のようにドメイン１１が「００００」の値を有することが好ましい。このゼロの値はリンク１０が内部で維持されており、よって符号化されていないことを示す。リンク１０が米国（米国はＵＳのカントリーコード１２を有する）に関連するデータに対して使用されていると仮定し、更にこれが０１のタイプコード１３を有する維持された消費者リンクであると仮定する。従って、本例において「００３ＮＱＬ８Ｎ」リンク１０のこの特定の消費者情報に対する所定のリンク識別子１４は、「００００ＵＳ０１００３ＮＱＬ８Ｎ」の値を有する。
【００５７】
次に、更にデータベース統合、増強またはその他のサービスの一部として、このリンク１０をクライアントに配信するものと仮定する。リンク１０を配信すべき相手のクライアントにはクライアント固有のドメイン１１’の値である「ＢＧ４Ｆ」が割り当てられている。アルゴリズムおよびキー記憶モジュール１５はアルゴリズム／キールックアップテーブル２３を含む。ドメイン値が既に割り当てられている各クライアントにも、アルゴリズム識別子２５によって識別された特定の（しかしながら必ずしも一義的ではない）符号化アルゴリズムおよび符号化キー２７も割り当てられる。アルゴリズム／キールックアップテーブル２３は対応するドメイン値２７に従ってインデックスされる各アルゴリズム識別子２５とキー２７とのリストを含む。実施例では、アルゴリズム識別子２５は単なる８ビットの二進数として記憶され、キー２７は３２進数の５１２個のキャラクターの文字数字の列として記憶される。（簡潔にするために、キー２７は図１ｂおよび１ｃでは単なる８つのキャラクターの文字数字の列として示されている。）図示した例では、ドメイン１１’の値が「ＢＧ４Ｆ」、アルゴリズム／キールックアップテーブル２３内アルゴリズム識別子２５の値が「０００００００１」、およびキー２７の値が「８ＷＦＺＴＲＥＱ」に対応する。
【００５８】
リンク１０を符号化するために、アルゴリズムおよびキー記憶モジュール１５にドメイン値１１’が送られ、対応するアルゴリズム識別子２３および記憶２７が検索される。符号化アルゴリズムモジュール３１は入力信号としてリンク識別子１４、アルゴリズム識別子２５およびキー２７を受けとる。符号化／復号化アルゴリズムモジュール３１は符号化アルゴリズムのレパートリーのうちのどれを使用するかを決定するのに、アルゴリズム識別子２５を使用し、キー２７を使ってリンク１４上の符号化アルゴリズムを実行する。この結果得られる、符号化アルゴリズムモジュール３１の出力信号は符号化されたリンク識別子１４’となる。実施例では、符号化されたリンク識別子１４’はリンク１４と同じ基本構造である。符号化プロセスは次に符号化リンク１０’を形成するのにドメイン１１’の値、カントリーコード１２、タイプコード１３および符号化されたリンク識別子１４’を連結する。
【００５９】
次に、符号化されたリンク１０’がクライアントから情報サービスプロバイダによって受信されると仮定する。このことは、例えばクライアントが既にリンク１０’をそのデータに適用させた後のデータ増強または更新リクエストの結果として生じ得る。この処理を実行するためには、情報サービスプロバイダは符号化されたリンク１０’を複号化し、内部処理のための複号化されたリンク１０を作成しなければならない。図１ｃに示されるように、符号化されたリンク１０’からドメイン値１１’が取られ、この値はアルゴリズムおよびキー記憶モジュール１５へ送られ、対応するアルゴリズム識別子２５およびキー２７を検索する。これまで述べたのと同じように、この目的のために、アルゴリズム／キールックアップテーブル２３が使用される。符号化／復号化アルゴリズムモジュール３１は次に入力信号として符号化されたリンク識別子１４’、アルゴリズム識別子２５およびキー２７を受けとる。符号化／復号化アルゴリズムモジュール３１はアルゴリズム識別子２５を使って復号化アルゴリズムのレパートリーのうちのどれを使用するかを決定し、キー２７を使ってリンク１４’で復号化アルゴリズムを実行する。この結果得られる、符号化／復号化アルゴリズムモジュール３１の出力信号は複号化されたリンク識別子１４となる。図１ｃに示されるように、この複号化プロセスはドメイン１１のゼロ値「００００」、カントリーコード１２、タイプコード１３および複号化されたリンク識別子１４を連結し、複号化されたリンク１０を形成する。次に、本明細書で更に説明するように、内部処理を続けることができる。
【００６０】
符号化／複号化アルゴリズムモジュール３１によって使用される特定の符号化／複号化アルゴリズムは本発明には重要ではない。このことは顧客がアルゴリズムまたは対応するキー２７の知識がないために、符号化されたリンク１０’から複号化されたリンク１０を作成することは、顧客にとってかなり困難であり、よって顧客がこのようなことをすることが商業的に不可能であることが条件となる。本発明の特定の実施例におけるキー２７のサイズは、顧客によるキーの複号化を商業的に不可能にするのに必要と見なされる複雑さのレベル、および選択されるアルゴリズムの種類に応じて決まる。当業者には多数のかかるアルゴリズムが既知となっている。
【００６１】
図２は特定の例を使った消費者リンクと住所リンクと占有リンクとの間の関係を示す。表１６は夫と妻に関するデータを示しており、最初の２つの行は、デンバーに住んでいた間の彼らの名前および住所データを示し、最後の２つの行は彼らがマイアミに引っ越した後の彼らの名前および住所データを示す。（この例およびその他の次の例では、簡潔にするために、各リンク１０のリンク識別子１４の略した部分しか示されていない。）消費者リンクコラム１７が示すように、消費者リンクは個人が引っ越しした際に、これら個人の各々に対して変化しない。しかしながら、住所リンクコラム１８に示されるように、これら人物は新しい住所リンクに関連付けされている。占有リンクコラム１９はこれら個人の各々に関する情報および特定の期間の彼らの住所に関する情報をリンクするのに、これらリンクが使用されるので、占有リンクの関連も変化することを示している。
【００６２】
データ所有者がリンク１０を使ってデータをリンクする前に、当該データベース（単数または複数）上のデータにリンク１０を関連付けしなければならない。この初期の関連づけは情報サービスプロバイダによって実行される。各リンク１０と適当なデータとの関連付けの他に、このプロセスは対応するデータベースファイル内での重複を除去するのに使用できる。次に図３を参照すると、ここにはこのプロセスの概観が示されている。データ所有者によって維持されている対応するデータベースファイルからの各記録を含む入力ファイル２０が生成される。この入力ファイル２０は単一のデータベースまたは多数の別々に維持されたデータベースから引き出すことができる。図示された例における入力ファイル２０は３つの別々に維持されたデータベースから引き出された同じ顧客に関する情報を含む。この例では、名前および住所に基づく簡単な照合では、これが同じ顧客であるかどうかを解決できない。その理由は、これら別個のデータベースが記録を維持している間に顧客が引っ越ししたり、自分の名前を変えているからである。しかしながら、レポジットリー２４を使用することにより、情報サービスプロバイダはこれら記録の各々が一人の顧客に関するデータを含むと判断できる。従って、結果ファイル２９内の各記録はこの消費者に対する同じリンク１０を含み、次にデータ所有者はこの特定リンク１０によってリンクされたすべてのデータをサーチするだけで、この消費者に関するデータのすべてにアクセスできるようになる。
【００６３】
次に図４を参照すると、ここにはリンク割り当て方法のより詳細な説明が示されている。リンク関連付けプロセスにおける第１工程は、入力ファイル２０を形成することである。次に、入力ファイル２０は照合ソフトウェア２２へ送られる。このソフトウェアは情報サービスプロバイダによって維持されるコンピュータ機器で実行できるが、データ所有者自身の機器でも実行できる。次に照合ソフトウェア２２は入力ファイル２０からのデータとレポジットリー２４からのデータを比較し、一致を探す。
【００６４】
情報サービスプロバイダによって維持されているレポジットリー２４は、国内スケールでの消費者および住所に関する広いベースの情報を含む。このレポジットリーは単一の物理的データベースでもよいし、また通信ネットワークによってリンクされた多数の物理的に独立したデータベースから形成されていてもよい。レポジットリー２４は米国または当該他の領域に住む、実質的にすべての消費者に関する情報を含む。
【００６５】
次に図５を参照する。レポジットリー２４には識別クラス３０の形式で情報が記憶される。各識別クラス３０は消費者リンク２６を使ってリンクされた特定個人に関して利用できるすべての情報を含む。特に識別クラス３０は個人によって使用された現在および以前の名前のリストである名前の履歴３２と、個人が住んだ住所のリストである住所履歴３４と、特定の時間、各名前／住所の相関性に関連する占有リンク２１を含む占有履歴３６とを含むことができる。上記のように、占有とは特定時間における個人の名前と、その時間に個人が在住した住所との組み合わせであるので、占有履歴３６を構築するのに住所履歴３４を使用できる。住所履歴３４はこの住所履歴３４内の各住所に対する住所リンク２８も含むことができる。名前履歴３２と住所履歴３４によって個人が自分の名前および住所の双方を合えた時でも、照合ソフトウェア２２はデータとリンク１０との正しい照合を実行できる。識別クラス３０は個人が関連する特定個人に関する種々の種類のデモグラフィック情報も含むことができる。この追加情報は比較のために照合ソフトウェア２２によっても使用できる。識別クラス３０は名前履歴３２および住所履歴３４の一部として、または別個のものとして共通する名前および住所のミススペルも含むことができる。
【００６６】
再び図４を参照し、照合ソフトウェア２２が照合プロセスを完了した後の入力ファイル２０内の対応するデータにリンクを添付する方法について説明する。上記のように、各識別クラス３０は消費者リンク２６と、少なくとも１つの住所リンク２８とを含む。（識別クラス３０が住所履歴３４内の過去の住所を含む場合、この過去の住所に追加住所リンク２８をリンクできる。）照合ソフトウェア２２を実行する結果、各記録の一部として正しい消費者リンク２６および住所リンク２８を含むように、入力ファイル２０が再書き込みされる。次に消費者リンクおよび住所リンク２８によって補強された入力ファイル２０から成る結果ファイル２９がデータ所有者に戻される。結果ファイル２９は同じ個人に関する情報を含む各記録に対し、同一の消費者リンク２６を含むので、このプロセスでは重複除去が自動的に実行される。例えば結果ファイル２９は「Ｊａｍｅｓ Ｌ．Ｓｍｉｔｈ」と「Ｊｉｍｍｙ Ｌ．Ｓｍｉｔｈ」に対する記録を含むが、各記録は同じ消費者リンク２６に一致するので、データ所有者は双方の記録が同じ顧客に関するものであると容易に判断できる。
【００６７】
入力ファイル２０および結果ファイル２９は電子ファイルを伝送するのに適した態様で送信できる。これらファイルは通信ネットワークを通し、ＦＴＰ（ファイル転送プロトコル）技術を使ってデータ所有者と情報サービスプロバイダとの間で伝送してもよいし、磁気テープまたはディスクのような電子記憶媒体で転送できることが好ましい。照合ソフトウェア２２は入力ファイル２０自身に含まれる類似性よりも、むしろ照合のためのレポジットリー２４内の包括データに依存しているので、入力ファイル２０の最小サイズには制限がない。入力ファイル２０は照合プロセスの精度が失われない状態で単一の記録程度に小さくできる。
【００６８】
次に図６を参照し、住所エラーを解決するために本発明を使った特定の例について説明する。エラー入力データ４０は夫と妻のための名前および住所情報を含む。エラー入力データ４０は夫に関するタイプエラーを含み、「２１０」のストリート住所が「１２０」に変わっている。配送マップ４６に示されるように、ストリート住所「１２０」は実際に存在している。この住所は有効であるが、この特定の消費者に対しては正しくないので、このエラーを解決することは通常困難である。例えばこのデータとマスター住所リストとを単に照合してもエラーを示さない。更に、レポジットリーデータ４２が正しいデータを含む場合でも、リンクを用いることなく、データを照合することは困難である。その理由は、「１２０」なるストリート住所は識別クラス３０に記憶された夫の住所履歴の一部ではないからである。
【００６９】
しかしながら、本発明のリンクを使用すれば、照合ソフトウェア２２を使用することにより、データとタイプエラーとの照合の問題を解決できる。その理由は、照合ソフトウェア２２は名前または住所のいずれか単独ではなく、占有照合に基づきその機能を実行するので、照合プロセスではタイプエラーは無視されるからである。これによってタイプエラーに係わらず、正しいリンクにより得られたデータ４９を戻すことができる。同様に、住所の通称、多数の正しいストリート名および共通するミススペルのような他の住所の問題を解決するのに、照合ソフトウェア２２はレポジットリー２４内の包括的データを引き出すことができる。これとは異なり、リンクのリンキングに基づき、レポジットリー２４内で発見された訂正された住所情報を含む、その結果得られるデータ４９を送ってもよい。更に、この結果得られたデータ４９はエラー入力データ４０と共に含まれないアパート番号のような、入力データ４０からなくなった追加住所情報と共に送ってもよい。
【００７０】
識別クラス３０に記憶された住所リンクを使用することにより、世帯管理を実行するのに本発明を利用できる。多くのデータ処理システムの望ましい目的は、どれだけ多くの顧客が同じ世帯を共用しているかを判断することである。世帯の定義は企業ごとに変わり得る。世帯を１つの住所に住む通常の家族として定義する企業もあれば、２つの関連のないルームメートを単一の世帯と見なす企業もあれば、更にある場合には別の住所に住む、法律的に別居したカップルを単一の世帯として定義し、別の場合には別々の世帯として扱う企業もある。
【００７１】
道路名の通称およびその他の問題とは関係なく、図５および６に示されるように、異なる顧客に対し、共通する住所リンク２８を割り当てるのに、識別クラス３０を使用することによって世帯データの精度は大幅に高められる。世帯の最も一般的な定義、すなわち同一住所に住む人という定義を使用すると、共通住所リンク２８を有するすべてのデータにアクセスするだけで世帯管理を実行できる。別居の家族、ルームメートか親戚かの区別、姓が共通となるような名前の変更、および同様な問題に対応する、識別クラス３０に含まれる他の目的データに基づき、レポジットリー２４上の識別クラス３０をリンクすることにより、世帯の概念を他の定義まで拡張できる。各世帯の定義に従い、データをリンクするのに異なるタイプのコード１３を有するリンク１０を使用できる。例えば、世帯の従来の定義に従い、すべてのリンクをするのに使用されるリンク１０に対して、例えば「０３」のタイプコード１３を使用してもよいし、世帯のルームメート／親戚の定義に従ってすべてのデータをリンクするのに「０Ａ」のタイプコード１３も使用できる。図４に示されるように、結果として生じるデータ２９内の各記録に対する追加添付リンクとしてかかるリンク１０を戻すことができる。
【００７２】
次に図７および８を参照し、本発明に係る実施例に従って、リンク管理を実行するための方法について説明する。レポジットリー２４は全住民（例えば米国内の消費者）に関する包括的な情報を含むが、かかる情報は常に流動的であるので、かかる人のすべてに関する望ましいすべての情報を含むことはできない。レポジットリー２４に新しい消費者および住所が提示されると、レポジットリーはこれらエンティティに対応する情報をリンクするのに新しいリンク１０を割り当てなければならない。しかしながら、このエンティティに関するより多くの情報が後に収集されるにつれ、このエンティティは実際に既に旧いエンティティとなるが、その時にレポジットリー２４で利用できる情報に基づき、このエンティティを１つのエンティティに変えることはできない。この問題に対する解決案は、２つのリンクを１つのリンクに統合することである。同様に、２つのエンティティが誤って１つのエンティティに統合された時も同様な問題が生じ、後で２つの別個の識別クラス３０を使用して、これらを２つの別個のエンティティとしてレポジットリー２４が維持しなければならないと判断される。この問題に対する解決案は、これら２つののエンティティの各々にデータをリンクするのに、別個のリンクを使用できるよう、新しいリンクを割り当てることである。
【００７３】
リンク統合および分割のプロセスでは、既にリンクが供給されているデータ所有者が自分のデータベースを再構築しなくてもよい。むしろこれらデータ所有者には単にリンク更新のテーブルを含む電子ファイルが提供されるにすぎない。例えば図７に示されるように、レポジットリー２４は第１消費者５０および第２消費者５２のために識別クラス３０を維持する。これら２人の消費者は自分たちに対応するデータをリンクするのに割り当てられた「１００」および「１５０」の異なるリンク識別子１４を有する。次に、第１消費者５０と第２消費者５２とが実際には同じ消費者であることを示す新しい関連データアイテム５４が、レポジットリー２４に入力されたと仮定する。この結果、消費者５６に対応するすべての情報を含む単一の識別クラス３０となるように、これら２人の消費者のための識別クラス３０がマージされる。ここでは、この情報のすべてをリンクするのに「１００」の単一リンク識別子１４が使用され、すべてのリンクの組から永久的に「１５０」の他のリンク識別子１４が破棄される。
【００７４】
この変化に関係するデータ所有者を更新するために、情報サービスプロバイダは統合メッセージ５８を送る。「１５０」の廃棄リンク識別子１４が生じた場合にこの消費者に対してこれまで使用された「１００」のリンク識別子１４と交換しなければならない旨を、統合メッセージ５８によってデータ所有者に通知する。次に、データ所有者は廃棄したリンク１０のすべての発生をサーチするソフトウェアルーチンを作動させ、このリンクを新しいリンク１０に置換するだけでよい。情報サービスプロバイダは関連するデータアイテム５４が受信されるとすぐに、統合メッセージ５８を送ることができるし、また、最終統合メッセージ５８が送られてから生じたすべてのリンク統合を表す周期的な統合メッセージ５８を送ってもよい。
【００７５】
次に図８を参照する。ここには、例としてリンク分割を実行するためのプロセスも示されている。レポジットリー２４は最初に消費者５６が単一の個人である情報を含み、これに対し、この消費者に対応するデータをリンクするのに使用される単一消費者リンク２６を含む識別クラス３０内にすべての対応情報が含まれている。次に、レポジットリー２４により関連データアイテム５４が受信されるが、この場合、関連データアイテム５４は消費者５６が実際には２人の異なる消費者であることを表示する。次に、消費者５６のための識別クラス３０を２つの識別クラス、すなわち第１の消費者５０のためのクラスと、第２の消費者５２のためのクラスとに分割するためのソフトウェアルーチンを実行する。これらエンティティの１つに対応するデータをリンクするのに、現在の消費者リンク２６を使用できるが、他の消費者に対応するデータをリンクするのに、新しい消費者リンク２６を指定しなければならない。
【００７６】
リンクスプリットに関し、データ所有者に通知をするために、統合メッセージ５８に対してこれまで説明した方法と同じように、スプリットメッセージ６８を公開する。データ所有者に定期的に送られる単一メッセージを形成するように、スプリットメッセージ６８と統合メッセージ５８とをマージできる。スプリットの場合、別の情報が必要とされる。その理由は、データ所有者はどのデータが旧い消費者リンクに関係しているか、更にどのデータが新しい消費者リンクでタグ付けされるかを知っていなければならないからである。新しいリンクにより特定の占有にタグ付けすべきかどうかを判断するのに再処理が必要となる。
【００７７】
次に図９を参照し、本発明の好ましい実施例を使ってデータ更新を実行する利点について説明する。データ所有者のデータ処理システムに対して本発明を実施する第１工程は、上記のようにデータ所有者のデータにリンク１０を重ねることである。図９の実施例では、顧客のデータ７０は物理的に独立した４つのデータベースからの記録、すなわち総計２千３百万の記録を含む。統合プロセス７２およびリンクアサイメント７４に顧客データ７０が入力される（このプロセスはレポジットリー２４からのデータに基づき、上記のように照合ソフトウェア２２によって実行される）。これとは異なり、統合プロセス７２をスキップし、顧客データ７０内の各ソースから直接リンクアサイメント７４にデータを送ってもよい。変更された顧客データ７０は各記録に追加されたリンク１０と共に顧客ファイル７６となる。最初にリンク１０を顧客データ７０へ割り当てるのに、データ所有者のデータの２千３百万の記録のすべてを処理しなければならないので、このような初期の構築はリソース集約的である。
【００７８】
次に、データ所有者がデータの毎月の更新を望むと仮定する。顧客データ７０のすべてを再処理する代わりに、更新データ７８を処理するだけでよい。更新データ７８はデータ所有者が前月に獲得した新しいデータを示す。このデータは、例えばデータ所有者が前の月の間に獲得した新しい顧客であり得る。図９の実施例では、更新データは２つの異なるデータベースからの１５０万の記録しか含んでいない。この更新データ７８は初期の構築に関連して上で説明したように、統合プロセス７２およびリンクアサイメント７４（または直接リンクアサイメント７４）に入力され、顧客ファイル７６と統合される。統合プロセス７２およびリンクアサイメント７４はレポジットリー２４内の情報に基づいており、顧客データ７０のすべてにわたる名前と住所の比較には基づいていないので、更新手続きを実行するのにファイル全体を再処理する必要はない。
【００７９】
本発明は所望する頻度で、例えば毎月、毎日または新しい記録を受信した時にリアルタイムでも更新を実行できるようにしようとするものである。レポジットリー２４内には照合に必要な情報のすべてが含まれ、よって顧客データ７０はクロス比較には使用されないので、更新データ７８を単一の記録程度に小さいファイルとすることができる。リアルタイム更新環境では、ちょうど新しい記録が受信された時に、この記録は情報サービスプロバイダへ更新データ７８として送られ、情報サービスプロバイダは即座に統合プロセス７２およびリンクアサイメント７４を実行するように、照合ソフトウェア２２を作動させ、よって顧客ファイル７６のリアルタイムの更新を可能にする。より頻繁に更新をすれば、各更新のボリュームを小さくでき、よって大きい更新をより少ない頻度で処理することによって生じる計算上のリソースのボトルネックを軽減できる。更により頻繁に、またはリアルタイムでも更新すれば、データ所有者は顧客のすべてに関する最も正確な情報を維持できるようになる。
【００８０】
リンク用リンクがデータ所有者のデータベース内の所定位置にあると、本発明の実施例に係わる１つのアプリケーションはデータ統合となる。今日の多くの企業は「顧客関係管理」（ＣＲＭ）プランを実現することが有利であると判断している。このＣＲＭプランの目標は企業が特定の顧客との関係を完全に理解できるようにすることにある。ＣＲＭはかかる情報が内部のソースから生じているのか、または外部のソースから生じているのかにかかわらず、各顧客に関して知られているすべての情報を企業が統合することを求める。この統合された情報は企業が所定の顧客が開始した相互対話に即座に応答できるよう、リアルタイムで利用できることが理想的である。ＣＲＭは顧客が関心をもっているすべての製品および製品ラインを知ること、企業の種々の部門のすべてにより顧客の購入履歴を知ること、および顧客の対応するデモグラフィック（または企業の場合にはファーモグラフィック）情報を知ることを含む。このタイプの情報を知ることにより、企業は自らが特定の顧客の関心に対して特別に合わされた販売努力およびマーケティング努力により、顧客に良好にサービスできることを見いだす。顧客も同じようにこのプロセスが望ましいと考える。その理由は、顧客が関心をもつ製品およびオファーが通知されるが、顧客が関心がないと表明した製品またはサービスを購入させるような勧誘はないからである。
【００８１】
成功できるＣＲＭプランのキーとなる要素は、特定の顧客に関する「顧客の全体像」を形成することである。この顧客の全体像はＣＲＭを容易にするような方法で配置された任意の数の異種の情報ストアから顧客のための対応するすべての情報を同化させることから成る。顧客の全体像システムを構築しようと試みる企業に対向する主な障害は、企業の情報ストアが通常同じように一貫しておらず、正確でなく、最新でない、同じ顧客に関する重複した情報を含んでいることである。この結果、同一個人に関する情報が種々の不一致と共に多数のデータベースまたは情報ストアに存在し得る。これらデータストアの各々は異なる顧客ナンバー割り当て方式を使用したり、または単に名前および住所の照合に依拠し得るので、内部情報だけを使ってこれらデータを成功裏にリンクすることは困難であり、高いレベルの正確さで達成することはできない。
【００８２】
図１０はこの問題の図解例を示している。会社データの表８０の各行は、小売業者の種々の部門の１つによって維持された別のデータベースから引き出された記録を示す。会社のデータの表８０の各列は、これら記録、例えば名前、住所および顧客の口座番号における特定のフィールドを示す。この場合の情報は販売店−自動車サービス、ホームサービス、小売販売およびスポーツ用品の「特別メーリングリスト」によって維持される４つの異なるデータベースから引き出される。各データベースからの記録は実際には同一の個人を示すが、各部門によって使用される名前の綴りのバリエーション、個人の住所の変更および異なる口座番号によって、内部で発生された照合ルーチンを使ってこのデータを照合することができなくなっている。従って、販売店はこれが４つの異なる個人ではなく、一人の個人であると判断することはできず、よって正確な顧客の全体像を構築することもできない。
【００８３】
次に図１１を参照すると、ここにはリンクされたデータの表９０と共に、この情報を照合するためにリンクを使用した結果が示されている。リンクされたデータの表９０では、会社の種々のデータベース上の各記録は適当なリンクによって補強されている。顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対する名前の変形スペルおよび住所履歴のすべてを含むレポジットリー２４は、これら記録の各々が同一個人に関する情報を含んでいると解決できる。これら記録に一旦正しいリンクのタグ付けがされると、販売業者は簡単なリンク照合方法により、この個人に関するデータのすべてを迅速かつ容易にリンクできる。販売業者はまたバイブ情報サービスプロバイダによって維持されているこの顧客に関する情報に迅速かつ容易にリンクし、よって小売業者のデータの更新または強化を可能にできる。
【００８４】
次に図１２を参照する。この図には顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈの顧客全体像を構築するための方法が示されている。小売業者の部門の各々によって累積された情報にはＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対する顧客リンク２６のタグが付けられている。この情報はホームサービスデータベース１００、小売販売データベース１０２および自動車サービスデータベース１０４に含まれている。相互対話データアクセスルーチン１０９を使用することにより、小売業者は顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに関連するデータをリンクするのに使用される消費者リンク２６をサーチし、そのリンクのタグが付けられたすべての記録を検索するだけで、顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに対応するすべてのデータをサーチできる。更に小売業者は所望するように顧客であるＷｉｌｌｉａｍ Ｆ．Ｓｍｉｔｈに関する追加情報を引き出すよう、情報サービスプロバイダが維持するレポジットリー２４にも接続できる。このリンク照合方法は計算上簡単であるので、リアルタイムで実行できる。この結果、顧客の全体像１０１が得られ、この全体像を通して小売業者は顧客との総合的な関係を即座に決定できる。顧客の全体像１０１により、例えば小売業者は顧客が好むと分かっている既製品またはサービスに集中することにより、より効率的にこの特定の顧客に対してマーケット努力を向けることができる。
【００８５】
図１２に示され、これまで説明した方法は、顧客関係管理に対応するいくつかの重要なタスクに使用できる。図１３は小売業者のインターネットウェブサイトを通して大規模小売業者にコンタクトする顧客１０３の例を示している。顧客１０３が自家用雨樋をオーダーすることを決定したと仮定する。次に顧客は小売業者が取引を促進するために維持しているインターネットウェブサイトにアクセスする。この業者はウェブサーバー１０８のホストとなっている。ウェブサイトにアクセスした際に、ウェブサーバー１０８上に維持されているソフトウェアにより、顧客が自分の名前および住所を入力することが求められる。次にウェブサーバー１０８は顧客１０３に関する情報をリンクするのに使用される消費者リンク２６を決定する。一旦一致が発見されると、相互対話データアクセス１０９はホームサービスデータベース１００、小売販売データベース１０２および自動車サービスデータベース１０４を含む小売業者の種々のデータベースのすべてをサーチし、このリンクに対する一致があるかどうかを見つけることができる。このデータは次にウェブサーバー１０８に戻される。リンクを利用して照合が実行されるので、このプロセスは対応する情報を含む特定の記録とウェブサーバー１０８の問い合わせに応答して顧客が入力した名前および住所との一致があるかどうかとは関係なく、顧客１０３に関するすべての対応データを戻す。更に、レポジットリー２４との接続によりリアルタイムで情報サービスプロバイダのレポジットリー２４から追加情報を検索するのにリンクを使用できる。好ましいことに、レポジットリー２４とのリンクはＯＬＴＰ技術によって行うことができる。次に、顧客１０３が見るようにカスタム化されたインターネットウェブページを即座に作成するよう、小売業者と情報サービスプロバイダとの組み合わされたデータはウェブサーバー１０８によって使用できる。このカスタム化されたウェブページは、例えばその顧客が特に関心を持つ特別なプロモーションをディスプレイしてもよい。本発明の実施例では、このプロセス全体をリアルタイムで実行でき、従って顧客１０３に対し顕著な遅れは生じない。
【００８６】
本発明の別の実施例では、データ所有者はウェブサーバー１０８による問い合わせに対する顧客１０３の応答を情報サービスプロバイダのレポジットリー２４へ直接送ることにより、顧客１０３が見るためのカスタム化されたウェブページを提供できる。次に、情報サービスプロバイダはレポジットリー２４内のデータと組み合わせてこの情報を使用し、顧客０１３に関するすべての対応する情報を照合するために適当な消費者リンク２６を探す。情報サービスプロバイダからの追加情報がリクエストされた場合、そのデータを適当な消費者リンク２６と共にウェブサーバー１０８へ戻すことができる。次に、上記のように、相互対話データアクセス１０９を使って小売業者が維持する顧客１０３に関するすべての情報を照合するのに、この消費者リンク２６を使用できる。顧客１０３のためのカスタム化されたウェブサイトを作成するのに、ウェブサーバー１０８によりこのようなデータの集合を使用できる。別の実施例では、このデータの集合は分析モデル化エンジン（図示せず）にも送られ、データマイニングおよびその他の分析機能を実行する。この分析の結果はウェブサーバー１０８へ戻され、顧客１０３のためのカスタム化されたウェブサイトの作成を助ける。
【００８７】
本発明は、小売業者が顧客に関するデータを更新する機会として、顧客の取引または入力を利用できるようにするものである。再び図１３を参照して、顧客１０３がジャクソンビルからフェニックスに最近引っ越ししてきたと仮定する。顧客１０３は自分の家には雨樋が必要であると判断し、小売業者の電子取引ウェブサイトによりインターネットを通してこれら雨樋をオーダーしようとする。ウェブサーバー１０８が顧客１０３に名前と住所の情報を求めると再度仮定する。小売業者の内部データベースのいずれにも顧客１０３の新住所は入っていないので、リンクなしに顧客１０３に関するすべての情報を正しく接続することは困難である。しかしながら、情報サービスプロバイダに名前と住所が送られた場合、レポジットリー２４がこれまでに引っ越しを示すデータを受け取っていることを条件に、情報サービスプロバイダはレポジットリー２４を使って顧客１０３のための正しい消費者リンク２６および住所リンク２８をウェブサーバー１０８へ戻すことができる。次に、小売業者はデータアクセスルーチン１０９を使ってこの顧客に対応するデータのすべてを検索するようにリンク照合を使用し、次にこの情報に基づき、顧客１０３のためのカスタム化されたウェブページを作成するのにウェブサーバー１０８を使用できる。顧客１０３が提供する更新された住所情報は、顧客１０３向けのクーポンおよび特別なオファーをこの正しい住所に後で郵送するのに、小売業者によって使用される。
【００８８】
更に別の例は、顧客関係管理の別の重要な特徴をリンク１０がどのように容易にしているかを示す。次に図１４を参照し、自分のオーダーした雨樋が定刻どおりに発送されていないことを顧客１０３がサービス代表者１０５に電話していると仮定する。次にサービス代表者１０５は相互対話データアクセスルーチン１０９を使って顧客１０３に関するすべての利用できる情報を即座に呼び出すことができる。この結果、サービス代表者１０５は顧客１０３がここしばらく小売業者とかなりの取引を行い、通常スポーツ用品を購入すると判断できる。顧客１０３と話しながらこれら事実を知ることにより、サービス代表者１０５は、最も重要な行動は顧客の次のスポーツ用品の購入にかなりのディスカウントをするためのクーポンを顧客１０３に提供することであると判断できる。従って、小売業者は顧客１０３に関するすべての利用できる情報にアクセスできることにより、特定の取引における貧弱なサービスにもかかわらず、顧客１０３を維持する最良の方法を決定できる。
【００８９】
本発明はデータ所有者が維持する種々のデータベースにわたってトリガー通知を実行するのにも使用できる。例えば大規模金融機関のためのこのプロセスが図１５に示されている。金融機関は法律サービスデータベース１４０、保険データベース１４１、小口バンキングデータベース１４２、投資バンキングデータベース１４３および会社データウェアハウス１４４を含む種々の運用のための物理的に別個のデータベースを維持している。不動産業者１４８は顧客１０３が新しい家の購入を検討中であることを知る。この情報は金融機関の他の部門、例えば小口バンキング部門および法律部門にも有益であり、これら部門はこの取引に関連して顧客１０３に自分たちのサービスを提供したいことがある。不動産業者１４８はこの情報をメッセージシステム１４２に入力でき、メッセージシステム１４２は次に照合リンクを使ってこの情報を即座に法律サービスデータベース１４０、保険データベース１４１、小口バンキングデータベース１４２、投資バンキングデータベース１４３および会社データウェアハウス１４４へ提供する。次に法律部門および小口バンキング部門で営業する人はこの情報にアクセスし、上記のようにリンクを使ったデータ統合を通して顧客１０３に関して維持された追加情報を検索できる。
【００９０】
この発明の別の用途は、情報が維持されているエンティティからの入力に応答するのではなく、むしろデータサービスプロバイダのレポジットリー２４に新しい情報が追加された時に、顧客ファイル７６上のデータを更新または補強することである。この新情報は自動的にこの情報が関係し、このサービスを受けたいエンティティに関する記録を維持しているデータ所有者に自動的にプッシュできる。次に図６を参照すると、ここにはリンクを使ったプッシュ技術が示されている。更新データ１５６としての特定顧客に関する追加情報により、レポジットリー２４が更新されると仮定する。小売業者Ａは自分の顧客ファイル７６にこのデータが関係する顧客に関する情報も維持しており、このファイル２６は小売業者のホームオフィスのデータセンターに維持されたデータベースとすることができる。小売業者Ａは以前プッシュサービスに加入しているので、情報サービスプロバイダは小売業者Ａが更新のプッシュを望んでいるエンティティに対応するすべてのリンク１０のリストを含む小売業者Ａのリンクリスト１５２を維持している。情報サービスプロバイダのモニタルーチン１５０は小売業者Ａのリンクリスト１５２をチェックし、更新データ１５６を顧客ファイル７６にプッシュすべきかどうかを判断する。他のデータ所有者がプッシュサービスに加入していると仮定すると、モニタルーチン１５０は同じようにこれら加入者の各々に関連するリンクリストをチェックする。モニタルーチン１５０は更新データ１５６内のリンクと各リンクリスト内のリンクを比較するだけでよいので、このプロセスを迅速に実行できる。モニタルーチン１５０が小売業者Ａのリンクリスト１５２内で一致を見つけた場合、このルーチンは公開ルーチン１５４へ更新データ１５６を送り、公開ルーチン１５４は次に更新データ１５６を小売業者Ａの顧客ファイル７４へ伝送する。この伝送は電話回線またはデータを電子的に送る他の任意の手段で行うことができる。顧客ファイル７６内の結果は更新された顧客リスト１５８となる。小売業者Ａはプッシュサービスに加入することにより、情報サービスプロバイダの巨大なリソースを活用し、国内規模の情報データベースにアクセスできる。一方、これと同時に顧客ファイル７６および小売業者Ａのリンクリスト１５２に維持されている情報によって示される企業に対応するデータの更新だけに支払いを行うだけでよい。
【００９１】
以上で、所定の好ましい異なる実施例を参照して、本発明について説明したが、これら実施例は単なる例示にすぎず、特許請求の範囲に記載した発明の範囲を限定するものではない。
【符号の説明】
【００９２】
１０ リンク
１１ ドメイン
１２ カントリーコード
１３ タイプコード
１４ リンク識別子
１５ アルゴリズムおよびキー記憶モジュール
２０ 入力ファイル
２２ 照合ソフトウェア
２３ ルックアップテーブル
２４ レポジットリー
２５ アルゴリズム識別子
２７ キー
３０ 識別クラス
３１ アルゴリズムモジュール
３２ 名前の履歴
３４ 住所の履歴
３６ 占有履歴
【特許請求の範囲】
【請求項１】
データ要素の各々が特定のエンティティに関するデータ記憶システム上に常駐する複数のデータ要素を統合する方法において、
（ａ）データ要素を含む転送ファイルを作成する工程と、
（ｂ）前記転送ファイルをレポジットリーに伝送する工程であって、前記レポジットリー上に少なくとも１つの識別クラスが常駐しており、前記各識別クラスが、
（i）各々が特定のエンティティに一義的に対応する少なくとも１つのリンクと、
（ii）前記リンクが対応するエンティティに関連するデータと、を含む前記伝送する工程と、
（ｃ）前記転送ファイル内のデータ要素の各々と対応する識別クラスとを照合する工程と、
（ｄ）前記データ要素に一致した前記識別クラス内に含まれる前記リンクの少なくとも１つを前記転送ファイル内の前記データ要素の各々に付ける工程と、
（ｅ）前記データ要素が付された前記リンクの各々を符号化する工程と、
（ｆ）前記転送ファイル内のデータ要素とリンクとを使って前記データ記憶システムを再構築する工程と、
（ｇ）前記データ記憶システム内の特定のリンクをサーチすることにより、前記特定リンクが付けられた前記データ記憶システム上に常駐するすべてのデータ要素を収集する工程と、
を備える、データ記憶システムに常駐する複数のデータ要素を統合する方法。
【請求項２】
前記識別クラスの各々に含まれる前記データが、名前の通称と、名前の変更履歴と、住所の通称と、住所変更履歴と、別の名前のスペルと共通する名前のミススペルと、のうちの少なくとも１つを含み、前記照合工程が前記各データ要素に対応する前記識別クラス内の名前の通称と、名前の変更履歴と、住所の通称と、住所変更履歴と、別の名前のスペルと、共通する名前のミススペルと、のうちの少なくとも１つと前記データ要素とを照合する工程を含む、請求項１記載の方法。
【請求項３】
データ処理システム上に少なくとも１つのデータ要素が常駐し、前記データ要素が関係する顧客に対応するリンクに各データ要素が付けられる、前記データ処理システムを使って前記顧客の全体像を構築する方法において、
（ａ）前記顧客に対応する符号化されたリンクを含む、前記顧客の全体像のための、リクエストを受信する工程と、
（ｂ）前記顧客に対応する前記リンクを複号化する工程と、
（ｃ）前記顧客に対応する前記リンクと前記顧客に関するすべてのデータ要素が付けられたリンクとを照合する工程と、
（ｄ）前記顧客に対応する前記リンクに付けられたすべてのデータ要素を検索する工程と、
（ｅ）前記検索されたデータ要素のうちの少なくとも１つに基づき、前記顧客の全体像を形成する工程と、
を備える、データ処理システムを使って顧客の全体像を構築する方法。
【請求項４】
前記データ処理システムが物理的に独立した複数のデータベースを備え、２つの物理的に独立した異なるデータベース上に前記同じ顧客に関する前記データ要素の少なくとも２つが常駐する、請求項１１記載の方法。
【請求項５】
（ａ）前記データ記憶システムからレポジットリーに前記顧客に対応する前記リンクを伝送する工程であって、前記レポジットリーに複数の識別クラスが常駐し、前記識別クラスの各々に少なくとも１つのリンクが付けられており、前記識別クラスの各々が特定の顧客に関する、前記伝送する工程と、
（ｂ）前記リンクが付けられた前記識別クラスとを照合する工程と、
（ｃ）前記照合した識別クラスから追加データを検索する工程と、
（ｄ）前記リンクを符号化する工程と、
（ｅ）検索した前記追加データから前記識別クラスに対応する前記符号化されたリンクにリンクされた前記追加データを前記レポジットリーから前記データ処理システムに伝送する工程と、
（ｆ）前記追加データの少なくとも一部を前記顧客の全体像に追加する工程と、
を更に備える、請求項３記載の方法。
【請求項６】
複数のデータ要素が各々に常駐している物理的に独立した複数のデータベースのうちの少なくとも１つを更新する方法であって、前記データ要素の各々が特定のエンティティに関し、前記データ要素の各々が前記データ要素の関係する前記エンティティに対応するリンクに付けられている、前記複数のデータベースの少なくとも１つを更新する方法において、
（ａ）メッセージセンターにおいて、前記エンティティの少なくとも１つに関係する更新データを受信する工程と、
（ｂ）前記更新データが関係する前記エンティティに対応する前記リンクを符号化する工程と、
（ｃ）前記更新データが関係する前記エンティティに対応する前記更新データおよび前記符号化リンクを前記メッセージセンターから前記データベースのうちの少なくとも１つへ伝送する工程と、
（ｄ）前記更新データが伝送された前記データベースに対し、前記更新データが関係する前記エンティティに対応する前記符号化されたリンクが付けられた前記データ要素に前記更新データを重ねる工程と、
を備えた、前記複数のデータベースのうちの少なくとも１つを更新する方法。
【請求項７】
リンクの各々が、
（ａ）クライアントのアイデンティティに対応するドメイン値と、
（ｂ）前記各リンクが関係する特定のエンティティに対応するリンク識別値と、
を備えた、データと複数のリンクとを含むデータリンクシステム。
【請求項８】
前記データが複数のデータタイプを含み、前記リンクの各々が前記データタイプの１つに対応するタイプコード値を含む、請求項７記載のデータリンクシステム。
【請求項９】
前記リンクの各々が特定のカントリーおよび地域のうちの１つに対応するカントリーコード値を更に含む、請求項８記載のデータリンクシステム。
【請求項１０】
前記リンクの各々がドメイン値とリンク識別値とを含む、クライアントが使用するためのリンクを符号化する方法において、
（ａ）前記ドメイン値を特定のクライアントに対応するドメイン値に置換する工程と、
（ｂ）前記リンク識別値を符号化する工程と、
を備えた、前記リンクを符号化する方法。
【請求項１１】
前記リンク識別値を符号化する前記工程が、クライアント固有の符号化キーを利用する符号化アルゴリズムを実行する工程を含む、請求項１０記載の方法。
【請求項１２】
前記クライアント固有の符号化キーに対応するクライアントに前記符号化されたリンクを配信する工程を更に含む、請求項１１記載の方法。
【請求項１】
データ要素の各々が特定のエンティティに関するデータ記憶システム上に常駐する複数のデータ要素を統合する方法において、
（ａ）データ要素を含む転送ファイルを作成する工程と、
（ｂ）前記転送ファイルをレポジットリーに伝送する工程であって、前記レポジットリー上に少なくとも１つの識別クラスが常駐しており、前記各識別クラスが、
（i）各々が特定のエンティティに一義的に対応する少なくとも１つのリンクと、
（ii）前記リンクが対応するエンティティに関連するデータと、を含む前記伝送する工程と、
（ｃ）前記転送ファイル内のデータ要素の各々と対応する識別クラスとを照合する工程と、
（ｄ）前記データ要素に一致した前記識別クラス内に含まれる前記リンクの少なくとも１つを前記転送ファイル内の前記データ要素の各々に付ける工程と、
（ｅ）前記データ要素が付された前記リンクの各々を符号化する工程と、
（ｆ）前記転送ファイル内のデータ要素とリンクとを使って前記データ記憶システムを再構築する工程と、
（ｇ）前記データ記憶システム内の特定のリンクをサーチすることにより、前記特定リンクが付けられた前記データ記憶システム上に常駐するすべてのデータ要素を収集する工程と、
を備える、データ記憶システムに常駐する複数のデータ要素を統合する方法。
【請求項２】
前記識別クラスの各々に含まれる前記データが、名前の通称と、名前の変更履歴と、住所の通称と、住所変更履歴と、別の名前のスペルと共通する名前のミススペルと、のうちの少なくとも１つを含み、前記照合工程が前記各データ要素に対応する前記識別クラス内の名前の通称と、名前の変更履歴と、住所の通称と、住所変更履歴と、別の名前のスペルと、共通する名前のミススペルと、のうちの少なくとも１つと前記データ要素とを照合する工程を含む、請求項１記載の方法。
【請求項３】
データ処理システム上に少なくとも１つのデータ要素が常駐し、前記データ要素が関係する顧客に対応するリンクに各データ要素が付けられる、前記データ処理システムを使って前記顧客の全体像を構築する方法において、
（ａ）前記顧客に対応する符号化されたリンクを含む、前記顧客の全体像のための、リクエストを受信する工程と、
（ｂ）前記顧客に対応する前記リンクを複号化する工程と、
（ｃ）前記顧客に対応する前記リンクと前記顧客に関するすべてのデータ要素が付けられたリンクとを照合する工程と、
（ｄ）前記顧客に対応する前記リンクに付けられたすべてのデータ要素を検索する工程と、
（ｅ）前記検索されたデータ要素のうちの少なくとも１つに基づき、前記顧客の全体像を形成する工程と、
を備える、データ処理システムを使って顧客の全体像を構築する方法。
【請求項４】
前記データ処理システムが物理的に独立した複数のデータベースを備え、２つの物理的に独立した異なるデータベース上に前記同じ顧客に関する前記データ要素の少なくとも２つが常駐する、請求項１１記載の方法。
【請求項５】
（ａ）前記データ記憶システムからレポジットリーに前記顧客に対応する前記リンクを伝送する工程であって、前記レポジットリーに複数の識別クラスが常駐し、前記識別クラスの各々に少なくとも１つのリンクが付けられており、前記識別クラスの各々が特定の顧客に関する、前記伝送する工程と、
（ｂ）前記リンクが付けられた前記識別クラスとを照合する工程と、
（ｃ）前記照合した識別クラスから追加データを検索する工程と、
（ｄ）前記リンクを符号化する工程と、
（ｅ）検索した前記追加データから前記識別クラスに対応する前記符号化されたリンクにリンクされた前記追加データを前記レポジットリーから前記データ処理システムに伝送する工程と、
（ｆ）前記追加データの少なくとも一部を前記顧客の全体像に追加する工程と、
を更に備える、請求項３記載の方法。
【請求項６】
複数のデータ要素が各々に常駐している物理的に独立した複数のデータベースのうちの少なくとも１つを更新する方法であって、前記データ要素の各々が特定のエンティティに関し、前記データ要素の各々が前記データ要素の関係する前記エンティティに対応するリンクに付けられている、前記複数のデータベースの少なくとも１つを更新する方法において、
（ａ）メッセージセンターにおいて、前記エンティティの少なくとも１つに関係する更新データを受信する工程と、
（ｂ）前記更新データが関係する前記エンティティに対応する前記リンクを符号化する工程と、
（ｃ）前記更新データが関係する前記エンティティに対応する前記更新データおよび前記符号化リンクを前記メッセージセンターから前記データベースのうちの少なくとも１つへ伝送する工程と、
（ｄ）前記更新データが伝送された前記データベースに対し、前記更新データが関係する前記エンティティに対応する前記符号化されたリンクが付けられた前記データ要素に前記更新データを重ねる工程と、
を備えた、前記複数のデータベースのうちの少なくとも１つを更新する方法。
【請求項７】
リンクの各々が、
（ａ）クライアントのアイデンティティに対応するドメイン値と、
（ｂ）前記各リンクが関係する特定のエンティティに対応するリンク識別値と、
を備えた、データと複数のリンクとを含むデータリンクシステム。
【請求項８】
前記データが複数のデータタイプを含み、前記リンクの各々が前記データタイプの１つに対応するタイプコード値を含む、請求項７記載のデータリンクシステム。
【請求項９】
前記リンクの各々が特定のカントリーおよび地域のうちの１つに対応するカントリーコード値を更に含む、請求項８記載のデータリンクシステム。
【請求項１０】
前記リンクの各々がドメイン値とリンク識別値とを含む、クライアントが使用するためのリンクを符号化する方法において、
（ａ）前記ドメイン値を特定のクライアントに対応するドメイン値に置換する工程と、
（ｂ）前記リンク識別値を符号化する工程と、
を備えた、前記リンクを符号化する方法。
【請求項１１】
前記リンク識別値を符号化する前記工程が、クライアント固有の符号化キーを利用する符号化アルゴリズムを実行する工程を含む、請求項１０記載の方法。
【請求項１２】
前記クライアント固有の符号化キーに対応するクライアントに前記符号化されたリンクを配信する工程を更に含む、請求項１１記載の方法。
【図１ａ】
【図１ｂ】
【図１ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１ｂ】
【図１ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００９−３０１５７７（Ｐ２００９−３０１５７７Ａ）
【公開日】平成２１年１２月２４日（２００９．１２．２４）
【国際特許分類】
【出願番号】特願２００９−２１７５６６（Ｐ２００９−２１７５６６）
【出願日】平成２１年９月１８日（２００９．９．１８）
【分割の表示】特願２００３−２９１２２２（Ｐ２００３−２９１２２２）の分割
【原出願日】平成１５年８月１１日（２００３．８．１１）
【出願人】（５０２２６８８６３）アクシオム コーポレイション (1)
【Ｆターム（参考）】
【公開日】平成２１年１２月２４日（２００９．１２．２４）
【国際特許分類】
【出願日】平成２１年９月１８日（２００９．９．１８）
【分割の表示】特願２００３−２９１２２２（Ｐ２００３−２９１２２２）の分割
【原出願日】平成１５年８月１１日（２００３．８．１１）
【出願人】（５０２２６８８６３）アクシオム コーポレイション (1)
【Ｆターム（参考）】
[ Back to top ]