特許 6190817 データクラスタ化、データセグメント化、及びデータ並列化

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6190817

(24)【登録日】2017年8月10日

(45)【発行日】2017年8月30日

(54)【発明の名称】データクラスタ化、データセグメント化、及びデータ並列化

(51)【国際特許分類】

   G06F 17/30 20060101AFI20170821BHJP

【ＦＩ】

   G06F17/30 210D

   G06F17/30 110C

【請求項の数】26

【全頁数】74

(21)【出願番号】特願2014-541426(P2014-541426)

(86)(22)【出願日】2012年11月15日

(65)【公表番号】特表2014-533408(P2014-533408A)

(43)【公表日】2014年12月11日

(86)【国際出願番号】US2012065249

(87)【国際公開番号】WO2013074770

(87)【国際公開日】20130523

【審査請求日】2015年10月19日

(31)【優先権主張番号】61/560,257

(32)【優先日】2011年11月15日

(33)【優先権主張国】US

(31)【優先権主張番号】61/660,259

(32)【優先日】2012年6月15日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】509123208

【氏名又は名称】アビニシオ テクノロジー エルエルシー

(74)【代理人】

【識別番号】100107984

【弁理士】

【氏名又は名称】廣田 雅紀

(74)【代理人】

【識別番号】100102255

【弁理士】

【氏名又は名称】小澤 誠次

(74)【代理人】

【識別番号】100096482

【弁理士】

【氏名又は名称】東海 裕作

(74)【代理人】

【識別番号】100188352

【弁理士】

【氏名又は名称】松田 一弘

(74)【代理人】

【識別番号】100131093

【弁理士】

【氏名又は名称】堀内 真

(74)【代理人】

【識別番号】100150902

【弁理士】

【氏名又は名称】山内 正子

(74)【代理人】

【識別番号】100141391

【弁理士】

【氏名又は名称】園元 修一

(74)【代理人】

【識別番号】100198074

【弁理士】

【氏名又は名称】山村 昭裕

(74)【代理人】

【識別番号】100145920

【弁理士】

【氏名又は名称】森川 聡

(74)【代理人】

【識別番号】100096013

【弁理士】

【氏名又は名称】富田 博行

(72)【発明者】

【氏名】アンダーソン アーレン

【審査官】 早川 学

(56)【参考文献】

【文献】 国際公開第２０１２／１０４９４３（ＷＯ，Ａ１）

【文献】 Vernica, Rares et al.，Efficient Parallel Set-Similarity Joins Using MapReduce，Proceedings of the 2010 ACM SIGMOD International Conference on Management of data，ACM，２０１０年 ６月 ６日，pp.495-506

【文献】 成田和世、外１名，編集距離制約下におけるトライを用いた高速並列類似結合，第３回データ工学と情報マネジメントに関するフォーラム 論文集 ［ｏｎｌｉｎｅ］，電子情報通信学会データ工学専門委員会，２０１１年 ８月 ４日，Internet<URL:http://db-event.jpn.org/deim2011/proceedings/pdf/c7-4.pdf>

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

第１処理エンティティによって第１オリジナルレコードセットを処理して、前記オリジナルレコードと該オリジナルレコードそれぞれの１又は２以上のコピーとを含む第２レコードセットを生成することであって、それぞれのオリジナルレコードが１又は２以上のフィールドを含み、前記オリジナルレコードの少なくともいくつかの各レコードを処理することが、
前記オリジナルレコードの少なくとも１つのコピーを生成すること、及び
前記オリジナルレコードに第１セグメント値を関連付けるとともに、前記コピーに第２セグメント値を関連付け、前記第１セグメント値が、前記オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の最初の文字に対する偶数位置の文字に対応し、前記第２セグメント値が、前記オリジナルレコードの前記それぞれのフィールドの１又は２以上のデータ値の最初の文字に対する奇数位置の文字に対応することを含み、
前記第２レコードセットの中の前記レコードに関連付けられる前記セグメント値に基づいて、複数の受信側処理エンティティの間で前記第２レコードセットを分割し、各受信側処理エンティティにおいて、前記受信側処理エンティティにおいて受信した前記レコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行することを含む方法。

【請求項2】

セグメント値をレコードに関連付けることが、前記関連付けられたセグメント値を前記レコードの新たなフィールドに書き込むことを含む、請求項１に記載の方法。

【請求項3】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することが、第１レコードの１又は２以上のデータ値の中で出現する文字ストリングと、少なくとも第２レコードの１又は２以上のデータ値の中で出現する文字ストリングとを照合し、一致を判定することを含む、請求項１に記載の方法。

【請求項4】

照合が、近似照合である、請求項３に記載の方法。

【請求項5】

近似照合が、照合されるストリングが、指定された編集距離まで異なることを許容する、請求項４に記載の方法。

【請求項6】

近似照合が、第１レコードのデータ値と第２レコードのデータ値の間の許容される差分を定義する照合基準に基づき、それぞれのオリジナルレコードに関して、１又は２以上のデータ値の最初の文字に対する偶数位置の文字、及び前記１又は２以上のデータ値の最初の文字に対する奇数位置の文字が、前記許容される差分のいずれかによる前記１又は２以上のデータ値の変更に応答して、第１セグメント値又は第２セグメント値の少なくとも１つは変化しないように選択される、請求項４に記載の方法。

【請求項7】

許容される差分が、第１レコードのデータ値の中で出現する第１文字ストリングと第２レコードのデータ値の中で出現する第２文字ストリングの間の差分を含む、請求項６に記載の方法。

【請求項8】

許容される差分が、第１レコードのデータ値の中で出現する第１バイナリ値と第２レコードのデータ値の中で出現する第２バイナリ値の間の差分を含む、請求項６に記載の方法。

【請求項9】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することが、代替キー割り当てを含む、請求項１に記載の方法。

【請求項10】

受信側処理エンティティで生成される結果が、前記受信側処理エンティティにおいて受信した各レコードに関して、前記レコードの１又は２以上のデータ値に基づく割り当てられた代替キーで拡張された前記レコードを含む、請求項９に記載の方法。

【請求項11】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することが、前記受信したレコードを１又は２以上のクラスタにクラスタ化することを含む、請求項１に記載の方法。

【請求項12】

受信側処理エンティティにおいて生成される結果が、前記受信側処理エンティティにおいて受信した各レコードに関して、前記レコードの１又は２以上のデータ値、及び前記受信側処理エンティティにおいて受信したその他のレコードの少なくともいくつかのレコードの１又は２以上のデータ値に基づく割り当てられたクラスタで拡張された前記レコードを含む、請求項１１に記載の方法。

【請求項13】

操作が、代替キー割り当て、クラスタ化、ロールアップ、又は結合の少なくとも１つを含む、請求項１に記載の方法。

【請求項14】

第１セグメント値が、オリジナルレコードそれぞれのフィールドの複数データ値の最初の文字に対する偶数位置の文字に対応し、第２セグメント値が、前記オリジナルレコードそれぞれのフィールドの複数データ値の最初の文字に対する奇数位置の文字に対応する、請求項１に記載の方法。

【請求項15】

第２処理エンティティにおいて各受信側処理エンティティからの結果を受信すること、及び冗長な結果を削除するように前記受信した結果を処理することをさらに含む、請求項１に記載の方法。

【請求項16】

第２レコードセットが、オリジナルレコードとオリジナルレコードそれぞれの少なくとも１つのコピーとを含む、請求項１５に記載の方法。

【請求項17】

冗長な結果を削除するように受信した結果を処理することが、オリジナルレコードに関連付けられる第１結果、又は前記オリジナルレコードのコピーに関連付けられる第２結果の最大で１つを選択することを含む、請求項１６に記載の方法。

【請求項18】

第１処理エンティティにおいて各受信側処理エンティティからの結果を受信すること、及び冗長な結果を削除するように前記受信した結果を処理することをさらに含む、請求項１に記載の方法。

【請求項19】

各受信側処理エンティティが、それぞれ操作を独立に実行する、請求項１に記載の方法。

【請求項20】

受信側処理エンティティの数が、それぞれのオリジナルレコード、及び前記オリジナルレコードのコピーに関連付けられる異なるセグメント値以上である、請求項１に記載の方法。

【請求項21】

処理エンティティが、マルチコアプロセッサにおけるコアであり、さらに第１処理エンティティが、第２レコードセットから分割されたレコードを、前記マルチコアプロセッサにおける相互接続ネットワークを介して受信側処理エンティティに送信する、請求項１に記載の方法。

【請求項22】

処理エンティティが、マルチプロセッサコンピュータシステムにおけるプロセッサであり、さらに第１処理エンティティが、第２レコードセットから分割されたレコードを、前記マルチプロセッサコンピュータシステムにおける相互接続ネットワークを介して受信側処理エンティティに送信する、請求項１に記載の方法。

【請求項23】

処理エンティティが、ラックマウント型サーバシステムにおけるサーバコンピュータであり、さらに第１処理エンティティが、第２レコードセットから分割されたレコードを、前記ラックマウント型サーバシステムにおける相互接続ネットワークを介して受信側処理エンティティに送信する、請求項１に記載の方法。

【請求項24】

処理エンティティが、ネットワークを介して通信状態にあるコンピュータシステムであり、さらに第１処理エンティティが、第２レコードセットから分割されたレコードを、前記ネットワークを介して受信側処理エンティティに送信する、請求項１に記載の方法。

【請求項25】

コンピュータ可読記憶媒体上に格納されたコンピュータプログラムであって、
コンピューティングシステムに、
第１処理エンティティによって第１オリジナルレコードセットを処理して、前記オリジナルレコードと該オリジナルレコードそれぞれの１又は２以上のコピーとを含む第２レコードセットを生成させ、それぞれのオリジナルレコードが１又は２以上のフィールドを含み、前記オリジナルレコードの少なくともいくつかの各レコードを処理することが、
前記オリジナルレコードの少なくとも１つのコピーを生成すること、及び
前記オリジナルレコードに第１セグメント値を関連付けるとともに、前記コピーに第２セグメント値を関連付け、前記第１セグメント値が、前記オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の最初の文字に対する偶数位置の文字に対応し、さらに前記第２セグメント値が、前記オリジナルレコードの前記それぞれのフィールドの１又は２以上のデータ値の最初の文字に対する奇数位置の文字に対応することを含み、さらに、
前記第２レコードセットの中の前記レコードに関連付けられる前記セグメント値に基づいて、複数の受信側処理エンティティの間で前記第２レコードセットを分割させ、各受信側処理エンティティにおいて、前記受信側処理エンティティにおいて受信した前記レコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行させるための命令を含む、コンピュータプログラム。

【請求項26】

第１オリジナルレコードセットを処理して、前記オリジナルレコードと該オリジナルレコードそれぞれの１又は２以上のコピーとを含む第２レコードセットを生成するように構成された第１処理エンティティであって、それぞれのオリジナルレコードが１又は２以上のフィールドを含み、
前記オリジナルレコードの少なくともいくつかの各レコードを処理することが、
前記オリジナルレコードの少なくとも１つのコピーを生成すること、及び
前記オリジナルレコードに第１セグメント値を関連付けるとともに、前記コピーに第２セグメント値を関連付け、前記第１セグメント値が、前記オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の最初の文字に対する偶数位置の文字に対応し、さらに前記第２セグメント値が、前記オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の最初の文字に対する奇数位置の文字に対応することを含む、第１処理エンティティと、
前記第２レコードセットの中の前記レコードに関連付けられる前記セグメント値に基づいて分割された前記第２レコードセットそれぞれのサブセットを受信する複数の受信側処理エンティティとを含み、各受信側処理エンティティが、前記受信側処理エンティティにおいて受信した前記レコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行するように構成される、コンピューティングシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、参照によりそれぞれ本明細書に組み込まれている、２０１１年１１月１５日に出願した米国特許出願第６１／５６０，２５７号、及び２０１２年６月１５日に出願した米国特許出願第６１／６６０，２５９号の優先権を主張するものである。

【0002】

この説明は、データクラスタ化、データセグメント化、及びデータ並列化（parallelization）に関する。

【背景技術】

【0003】

データクラスタ化は、実質的に類似する情報が共有の識別子でラベル付けされ、その結果、後でその情報が共通のロケーションに一緒にグループ化されているかのように処理され得るようにする方法である。この情報は、例えば、財務データ又は健康管理記録などの様々なタイプの情報を含み得る。各クラスタ（複数のクラスタのセットの中の）は、いくつかの類似性基準を満たすと判定されているデータ（例えば、文書、データベースレコード、又は他のデータオブジェクト）の単位を含む。一部の技法は、データの単位をバッチとして処理してクラスタを生成する、又は既存のクラスタに追加する「オフライン」技法である。一部の技法は、データの単位を、データが受け取られるにつれてインクリメンタルに処理する「オンライン」技法である。クラスタは、１つのレベルの所与のクラスタがそれ自体、別のレベルの複数のクラスタに分割される階層型であることが可能である。場合によっては、それらのクラスタは、各データ単位が厳密にそれらのクラスタの１つに入っているデータ単位の分割に対応し、場合によっては、クラスタは、データ単位が２つ以上のクラスタのメンバである状態で重なり合うことが可能である。

【発明の概要】

【課題を解決するための手段】

【0004】

一態様では、一般に、方法が、第１処理エンティティによって第１セットのオリジナル（original）レコードを処理して、オリジナルレコードとそれぞれのオリジナルレコードの１又は２以上のコピーとを含む第２レコードセットを生成する（generate）ことを含み、それぞれのオリジナルレコードが１又は２以上のフィールドを含む。オリジナルレコードの少なくともいくつかのレコードの各レコードを処理することは、オリジナルレコードの少なくとも１つのコピーを生成し、さらにオリジナルレコードに第１セグメント値を関連付けるとともに、そのコピーに第２セグメント値を関連付け、第１セグメント値が、オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第１ポーションに対応し、第２セグメント値が、第１ポーションとは異なるオリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第２ポーションに対応することを含む。また、この方法は、第２セットの中のレコードに関連付けられるセグメント値に基づいて、複数の受信側処理エンティティの間で第２レコードセットを分割し、各受信側処理エンティティにおいて、受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行することも含む。

【0005】

態様は、以下の特徴の１又は２以上を含み得る。

【0006】

第１セグメント値は、第１データ値の中の文字の第１位置セットからとられた第１フィールドの第１データ値からの第１シーケンスの文字に対応し、第２セグメント値は、第１データ値の中の文字の第２位置セットからとられた第１データ値からの第２シーケンスの文字に対応する。

【0007】

第１位置セットは、第２位置セットとは重なり合わない。

【0008】

第１位置セットは、データ値の最初の文字に対する偶数位置であり、第２位置セットは、データ値の最初の文字に対する奇数位置である。

【0009】

セグメント値をレコードに関連付けることは、関連付けられるセグメント値をレコードの新たなフィールドに書き込むことを含む。

【0010】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することは、第１レコードの１又は２以上のデータ値の中で出現する文字ストリングと、少なくとも第２レコードの１又は２以上のデータ値の中で出現する文字ストリングとを照合し、一致を判定することを含む。

【0011】

この照合は、近似照合（approximate match）である。

【0012】

この近似照合は、照合するストリングが、指定された編集距離まで異なることを許容する。

【0013】

この近似照合は、第１レコードのデータ値と第２レコードのデータ値の間の許容される差分を定義する照合基準に基づき、それぞれのオリジナルレコードに関して、その１又は２以上のデータ値の第１ポーション、及びその１又は２以上のデータ値の第２ポーションが、許容される差分のいずれかによるその１又は２以上のデータ値の変更に応答して、第１セグメント値又は第２セグメント値の少なくとも１つは変化しないように選択される。

【0014】

許容される差分は、第１レコードのデータ値の中で出現する第１文字ストリングと第２レコードのデータ値の中で出現する第２文字ストリングの間の差分を含む。

【0015】

許容される差分は、第１レコードのデータ値の中で出現する第１バイナリ値と第２レコードのデータ値の中で出現する第２バイナリ値の間の違いを含む。

【0016】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することは、代替キー割り当てを含む。

【0017】

受信側処理エンティティで生成される結果は、受信側処理エンティティにおいて受信した各レコードに関して、レコードの１又は２以上のデータ値に基づく割り当てられた代替キーで拡張されたレコードを含む。

【0018】

受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて操作を実行することは、受信したレコードを１又は２以上のクラスタにクラスタ化することを含む。

【0019】

受信側処理エンティティにおいて生成される結果は、受信側処理エンティティにおいて受信した各レコードに関して、そのレコードの１又は２以上のデータ値、及び受信側処理エンティティにおいて受信したその他のレコードの少なくともいくつかのレコードの１又は２以上のデータ値に基づく割り当てられたクラスタで拡張されたレコードを含む。

【0020】

操作は、代替キー割り当て、クラスタ化、ロールアップ、又は結合の少なくとも１つを含む。

【0021】

第１セグメント値は、オリジナルレコードそれぞれのフィールドの複数データ値の第１ポーションに対応し、第２セグメント値は、第１ポーションとは異なるオリジナルレコードそれぞれのフィールドの複数データ値の第２ポーションに対応する。

【0022】

この方法は、第２処理エンティティにおいて各受信側処理エンティティからの結果を受信すること、及び冗長な結果を削除するようにそれらの受信した結果を処理することをさらに含む。

【0023】

第２レコードセットは、オリジナルレコードとそれぞれのオリジナルレコードの少なくとも１つのコピーとを含む。

【0024】

冗長な結果を削除するように受信した結果を処理することは、オリジナルレコードに関連付けられる第１結果、又はオリジナルレコードのコピーに関連付けられる第２結果の最大で１つを選択することを含む。

【0025】

この方法は、第１処理エンティティにおいて各受信側処理エンティティからの結果を受信すること、及び冗長な結果を削除するように受信した結果を処理することをさらに含む。

【0026】

受信側処理エンティティそれぞれは、それぞれ操作を独立に実行する。

【0027】

受信側処理エンティティの数は、それぞれのオリジナルレコード、及びそのオリジナルレコードのコピーに関連付けられる異なるセグメント値の最小値と少なくとも等しい。

【0028】

処理エンティティは、マルチコアプロセッサにおけるコアであり、さらに第１処理エンティティは、第２レコードセットからの分割されたレコードを、マルチコアプロセッサにおける相互接続ネットワークを介して受信側処理エンティティに送信する。

【0029】

処理エンティティは、マルチプロセッサコンピュータシステムにおけるプロセッサであり、さらに第１処理エンティティは、第２レコードセットからの分割されたレコードを、マルチプロセッサコンピュータシステムにおける相互接続ネットワークを介して受信側処理エンティティに送信する。

【0030】

処理エンティティは、ラックマウント型サーバシステムにおけるサーバコンピュータであり、さらに第１処理エンティティは、第２レコードセットからの分割されたレコードを、ラックマウント型サーバシステムにおける相互接続ネットワークを介して受信側処理エンティティに送信する。

【0031】

処理エンティティは、ネットワークを介して通信状態にあるコンピュータシステムであり、さらに第１処理エンティティは、第２レコードセットからの分割されたレコードを、そのネットワークを介して受信側処理エンティティに送信する。

【0032】

別の態様では、一般に、コンピュータプログラムがコンピュータ可読記憶媒体上に格納される。このコンピュータプログラムは、コンピューティングシステムに、第１処理エンティティによって第１オリジナルレコードセットを処理させて、オリジナルレコードとそれぞれのオリジナルレコードの１又は２以上のコピーとを含む第２レコードセットを生成させるための命令を含み、それぞれのオリジナルレコードが１又は２以上のフィールドを含む。オリジナルレコードの少なくともいくつかのレコードの各レコードを処理することは、オリジナルレコードの少なくとも１つのコピーを生成し、さらにオリジナルレコードに第１セグメント値を関連付けるとともに、そのコピーに第２セグメント値を関連付け、第１セグメント値が、オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第１ポーションに対応し、さらに第２セグメント値が、第１ポーションとは異なるオリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第２ポーションに対応することを含む。このコンピュータプログラムは、コンピューティングシステムに、第２セットの中のレコードに関連付けられるセグメント値に基づいて、複数の受信側処理エンティティの間で第２レコードセットを分割させ、さらに各受信側処理エンティティにおいて、受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行させるための命令を含む。

【0033】

別の態様では、一般に、コンピューティングシステムが、第１オリジナルレコードセットを処理して、オリジナルレコードとそれぞれのオリジナルレコードの１又は２以上のコピーとを含む第２レコードセットを生成するように構成された第１処理エンティティを含み、それぞれのオリジナルレコードが１又は２以上のフィールドを含む。オリジナルレコードの少なくともいくつかのレコードの各レコードを処理することは、オリジナルレコードの少なくとも１つのコピーを生成し、さらにオリジナルレコードに第１セグメント値を関連付けるとともに、そのコピーに第２セグメント値を関連付け、第１セグメント値が、オリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第１ポーションに対応し、さらに第２セグメント値が、第１ポーションとは異なるオリジナルレコードそれぞれのフィールドの１又は２以上のデータ値の第２ポーションに対応することを含む。このコンピューティングシステムは、第２セットの中のレコードに関連付けられるセグメント値に基づいて分割された第２レコードセットそれぞれのサブセットを受信する複数の受信側処理エンティティを含み、各受信側処理エンティティが、その受信側処理エンティティにおいて受信したレコードの１又は２以上のデータ値に基づいて結果を生成する操作を実行するように構成される。

【0034】

別の態様では、一般に、方法が、第１処理エンティティによってレコードセットを複数のレコードサブセットに分割すること、及びそれぞれの異なる受信側処理エンティティによってそのレコードセットの異なるサブセットを処理して、結果を、それらの受信側処理エンティティそれぞれがアクセスできるデータストレージの中に格納することを含む。各受信側処理エンティティによって処理することは、レコードの１又は２以上のフィールドの１又は２以上の値と、その受信側処理エンティティのいずれかによって保持されるローカル参照情報内のエントリ又はその他の受信側処理エンティティによって供給されたデータストレージ内のエントリとの間に近似照合が存在するか否か判定することに基づいて、そのサブセットの中の各レコードに対して操作を実行すること、及びその受信側処理エンティティによって保持されるローカル参照情報に基づいてデータストレージを更新することを含む。

【0035】

態様は、以下の特徴の１又は２以上を含み得る。

【0036】

受信側処理エンティティそれぞれがアクセスできるデータストレージは、不揮発性記憶媒体を含む。

【0037】

各受信側処理エンティティによって保持されるローカル参照情報は、揮発性記憶媒体の中に格納される。

【0038】

近似照合は、照合する値が、指定された編集距離まで異なることを許容する。

【0039】

サブセットの中の各レコードに対して操作を実行することは、代替キー割り当てを含む。

【0040】

受信側処理エンティティにおいて生成される結果は、受信側処理エンティティにおいて受信した各レコードに関して、そのレコードの１又は２以上の値に基づく割り当てられた代替キーで拡張されたレコードを含む。

【0041】

サブセットの中の各レコードに対して操作を実行することは、レコードを１又は２以上のクラスタにクラスタ化することを含む。

【0042】

受信側処理エンティティにおいて生成される結果は、受信側処理エンティティにおいて受信した各レコードに関して、そのレコードの１又は２以上の値、及び受信側処理エンティティにおいて受信したその他のレコードの少なくともいくつかのレコードの１又は２以上の値に基づく割り当てられたクラスタで拡張されたレコードを含む。

【0043】

操作は、代替キー割り当て、クラスタ化、ロールアップ、又は結合の少なくとも１つを含む。

【0044】

別の態様では、一般に、コンピュータプログラムが、コンピュータ可読記憶媒体上に格納される。このコンピュータプログラムは、コンピューティングシステムに、第１処理エンティティによってレコードセットを複数のレコードサブセットに分割させ、さらにそれぞれの異なる受信側処理エンティティによってそのレコードセットの異なるサブセットを処理させて、結果を、受信側処理エンティティそれぞれがアクセスできるデータストレージの中に格納させるための命令を含む。各受信側処理エンティティによって処理することは、レコードの１又は２以上のフィールドの１又は２以上の値と、その受信側処理エンティティによって保持されるローカル参照情報内のエントリ又はその他の受信側処理エンティティのいずれかによって供給されたデータストレージ内のエントリとの間に近似照合が存在するか否か判定することに基づいて、そのサブセットの中の各レコードに対して操作を実行すること、及びその受信側処理エンティティによって保持されるローカル参照情報に基づいてデータストレージを更新することを含む。

【0045】

別の態様では、一般に、コンピューティングシステムは、レコードセットを複数のレコードサブセットに分割するように構成された第１処理エンティティと、そのレコードセットの異なるそれぞれのサブセットを処理して、結果を、受信側処理エンティティそれぞれがアクセスできるデータストレージの中に格納するようにそれぞれが構成された複数の受信側処理エンティティとを含む。各受信側処理エンティティによって処理することは、レコードの１又は２以上のフィールドの１又は２以上の値と、その受信側処理エンティティによって保持されるローカル参照情報又はその他の受信側処理エンティティのいずれかによって供給されたデータストレージ内のエントリとの間に近似照合が存在するか否か判定することに基づいて、そのサブセットの中の各レコードに対して操作を実行すること、及びその受信側処理エンティティによって保持されるローカル参照情報に基づいてデータストレージを更新することを含む。

【0046】

態様は、以下の利点の１又は２以上を有することが可能である。

【0047】

大量のデータをクラスタ化する際、パフォーマンス及びスケーラビリティを制限する主な要因の１つが、適切な距離測定の下でいずれが近いかを判定するのにレコード間で行われなければならない計算の回数である。単純な全対全比較は、クラスタ化されているレコードの数の２乗に比例して拡大縮小する。

【0048】

改良されたアプローチは、クラスタをインクリメンタルに発見し、各クラスタを、新たなクエリレコードが近くなければならない代表的レコードで代表させてから、近くのレコードのさらなる採点が行われる。クエリレコードが新たなクラスタに属することを発見することは、既存のすべてのクラスタ代表がまず調べられてからでないと、新たなクラスタが作成され得ないため、別々のクラスタの数の２乗に比例して拡大縮小する。ビジネスの顧客データベース内で個人又は世帯をクラスタ化する場合に一般的であるように、多数の別々のクラスタに関して、このアプローチは、成り立たなくなる。

【0049】

本明細書で説明されるデータクラスタ化方法は、検索プロセスを使用して、おおよその距離測定の下で、クエリレコードがいずれかの既存のクラスタに十分に近いかどうかを判定してから、費用のかかる比較が行われる。このことは、クエリレコードが新たなクラスタの最初のレコードである以前のアプローチにおける最悪ケースを最良ケースに変換する。クエリレコードが既存のレコードと不十分な重なり合いしか有さない場合、クエリレコードは、検索から候補レコードを全く返さず、新たなクラスタのメンバであるはずである。

【0050】

本明細書で説明されるデータクラスタ化方法は、初期クエリから展開されるいくつかのクエリの組み合わせに基づいてターゲットが狭く絞られた検索を使用する。これらの複数のクエリは、検索中に検出すべきクエリ語句の変数照合を可能にするとともに、フィールドの中の複数のトークンからの、又はレコードの中の複数のフィールドからの同時のクエリを可能にする。この検索は、既存のクラスタの代表の役割をするマスタレコードのセットから、候補照合基準を満たす候補レコードを見つけ出そうとする。検索インデックスが、バッチモードで完全データセットに照らして事前計算されることが可能であり、又はインクリメンタルモードで累加的に入力される（polulated)ことが可能である。バッチモードにおいて、検索インデックスは、ビットベクトルの形態でレコードを照合するためのロケーション情報を含むことが可能である。このことは、複数の検索の結果を組み合わせるブール計算を容易にする。

【0051】

候補照合基準は、検索の組み合わせの定性的な結果を、例えば、顧客の検索がラストネームと都市の両方で照合したかどうかを符号化するコードである検索コードに関連して作成されることが可能である。各検索コードに関連付けられるサンプルレコードが、ユーザが候補照合基準を調整するのを支援するように抽出されることが可能である。また、検索コードは、一部の実施例において、候補照合基準全体を、検索結果に対するブール式として実現して、トークンがおおよそで照合するだけでよい場合に検索を非常に迅速にすることを可能にもする。

【0052】

候補照合基準を満たす候補レコードが見出された後、それらの候補レコードに関連付けられる各クラスタからの代表的レコードが、クエリレコードとの詳細な比較のために取り出される。より費用のかかる距離測定が、この比較のために使用される。検索コードと同様に、照合コードが、比較される個々のフィールド又はフィールドの組み合わせの各ペア間で見出される定性的照合、並びに特定のフィールドが、例えば、無効であったか、空白であったか、又は入力されていたかを示す、比較される個々のフィールド又はフィールドの組み合わせの入力の状態を含め、比較を定性的に要約するように構築される。照合コードからのクラスタ化の後、様々な品質の照合の数を定量化する統計が累算されることが可能である。また、各照合コードに関連付けられる決まった数のサンプルレコードが、ユーザが様々な種類の照合の品質を判断すること、及び照合結果を変えるようにそれに相応してレコードを比較するのに使用される比較関数を繰り返し調整することを支援するように抽出されることも可能である。また、レコードの入力特徴と照合結果の品質の間の相互関係が、照合コードから推論されることも可能である。

【0053】

クエリレコードと候補クラスタからの代表的レコードの間の詳細な比較のセットが、何らかの照合閾値を超える照合する最良のペアを見出すように解析されることが可能である。照合閾値を超える照合する最良のペアが存在しない場合、クエリレコードは、新たなクラスタの最初のレコードにされる。照合閾値を超える１つの照合する最良のペアが存在する場合、クエリレコードは、対応するクラスタに追加される。異なる既存のクラスタに対して照合閾値を超える複数の照合するペアが存在する場合、クエリレコードは、照合する最良のペアに関連付けられるクラスタに追加されるが、ユーザによる点検のために提供され得る代替のクラスタのセットが記録される。

【0054】

クラスタメンバシップ判定が行われ、すべてのクエリレコードがクラスタに割り当てられた後、ユーザが、クラスタ化されたレコードのネットワークを点検して、クラスタ承認プロセスにとりかかることが可能である。あいまいな照合が、点検のためにユーザに合図（flagged）される。ユーザは、クラスタ内の任意のレコードを確認することを選択することが可能であり、確認した場合、そのレコードがクラスタ化に再び差し出された場合には、そのレコードは、クラスタ化プロセスを経ることなしに同一のクラスタｉｄを受け取る。このことは、ユーザが、レコードが正しいクラスタに入っていることを手動で確認した場合、その決定が永続しなければならないというビジネス要件を満たす。

【0055】

ユーザは、レコードを、そのレコードが入れられていたクラスタから除外することを選択することが可能である。その後のクラスタ化実行時に、そのレコードは、そのクラスタに割り当てられることを阻止され、アルゴリズムによって判定された次善のクラスタに割り当てられる。

【0056】

ユーザは、レコードを新たなクラスタにマップすることを選択することが可能である。その後のクラスタ化実行時に、そのレコードは、新たなクラスタに割り当てられる。確認されていない任意のレコードが、それらのレコードが、既存の他のクラスタの中のレコードに対してよりも、そのレコードに近いという条件付きで、その新たなクラスタの中でそのレコードと一緒になることが可能である。同様に、ユーザは、選択されたレコードを、そのレコードがクラスタ化プロセスによって入れられていない、既存の異なるクラスタに再マップすることが可能である。後の実行時に、選択されたレコードは、選択されたクラスタに入れられ、そのレコードに近い任意の（確認されていない）レコードが、その選択されたレコードと一緒にその選択されたクラスタに移動する。このことは、ユーザが、少数の選択された個々のレコードを再マップすることを可能にするとともに、選択されたレコードと緊密に関係するすべてのレコードを再マップする再クラスタ化を可能にする。

【0057】

承認プロセスは、ユーザによる変更によって影響を受けるすべてのレコードを抽出し、それらのレコードをクラスタ化プロセスを介して返すプロセスによって円滑にされる。もたらされるデータクラスタは、前のデータクラスタに対して差別化され、ユーザには、その結果が示される。その後、ユーザが、行われたばかりの変更に加えてさらなる変更を適用して、それらの変更を繰り返す、又は破棄して、承認プロセスを始めからやり直すことを選択することが可能である。この承認プロセス全体が、一時作業領域で実行されることが可能であり、このプロセスが完了して、ユーザが満足すると、クラスタ化プロセスを導く基礎をなすクラスタストアが、永続的な生産領域に再び公開されることが可能である。

【0058】

本明細書で説明されるデータクラスタ化プロセスのさらなる利点は、バッチモードクラスタ化が、初期データセットに対して行われることが可能であり、将来のデータが、蓄積されたデータセット全体を再クラスタ化する必要なしに、インクリメントモードを使用して既存のクラスタに追加され得ることである。このことは、個々のレコードのクラスタメンバシップが、新たなデータが到着するにつれ、変化することがないというビジネス期待及びビジネス要件を満たす。未確認のレコードが、クラスタ承認プロセス中に可能であるように、再処理されない限り、個々のクラスタに対するそれらのレコードの割り当ては、変化し得ない。

【0059】

多国籍機関が、多数の国の個人についての情報を格納する可能性がある。これらの国は、データがどのように使用され、他国にエクスポートされ得るかを制限するデータプライバシーの法律又は規制を有することが可能である。データプライバシーの法律は、健康管理記録及び財務記録を含む多種多様な異なるタイプのデータを保護することが可能である。一部の国におけるデータ保護の法律は、いずれの他国へのデータのエクスポートも阻止する。他の国において、そのような法律は、一部の国へのデータのエクスポートを許容する一方で、他の国へのデータのエクスポートを阻止する。本明細書の用法では、いずれの他国へのデータの流れも制限する国は、データエクスポート禁止の国と呼ばれ、選択的な国へのデータの流れを制限する国は、選択的データエクスポートの国と呼ばれ、さらに制限的データエクスポートの国が、データエクスポート禁止の国と選択的データエクスポートの国をひとまとめにして指すように使用される。

【0060】

同時に、要求国が、それらの国の管轄下のエンティティから選択された情報が提供されることを要求することが可能である。例えば、米国（この例では、要求国）が、米国の管轄下の地球規模の金融機関が、所望の個人に関連付けられる銀行口座のリストを提供することを要求するが、要求されたデータは、スイス国（この例では、制限的データエクスポートの国）にあることが可能である。

【0061】

本明細書で説明されるデータクラスタ化技法は、要求国における所望の個人に関連付けられるレコードを、制限されたデータエクスポートの国におけるレコードと、それらの国々からデータをエクスポートすることなしにクラスタ化するのに使用されることが可能である。

【図面の簡単な説明】

【0062】

【図1A】クラスタ化プロセスを示すブロック図である。

【図1B】制限されたデータエクスポートの国が関与するクラスタ化プロセスを示す図である。

【図1C】クラスタ化エンジンを示すブロック図である。

【図1D】候補検索エンジンを示すブロック図である。

【図1E】変数プロファイラを示すブロック図である。

【図1F】変数ネットワークアナライザを示すブロック図である。

【図1G】クラスタ承認エンジンを示すブロック図である。

【図2A】変数−検索手順の例を示す図である。

【図2B】変数−検索手順の例を示す図である。

【図2C】変数−検索手順の例を示す図である。

【図2D】変数−検索手順の例を示す図である。

【図3A】変数ネットワークの例を示す図である。

【図3B】トークン代表ストアを入力するプロセスの例を示す図である。

【図4】レプリケートされたセグメント化を使用するクラスタ化を並列化するためのプロセスの例を示す流れ図である。

【図5A】レプリケートされたセグメント化を使用する並列クラスタ化の例を示す図である。

【図5B】レプリケートされたセグメント化を使用する並列クラスタ化の例を示す図である。

【図5C】レプリケートされたセグメント化を使用する並列クラスタ化の例を示す図である。

【図6】自然キーによる分割を伴う並列代替キー生成の例を示す図である。

【図7A】複数のフィールドからのクエリに対して検索することの例を示す図である。

【図7B】複数のフィールドからのクエリに対して検索することの例を示す図である。

【図7C】複数のフィールドからのクエリに対して検索することの例を示す図である。

【図7D】複数のフィールドからのクエリに対して検索することの例を示す図である。

【図8】変数ルックアップ手順を実施する削除−結合手順を使用することの例を示す図である。

【図9】インクリメンタルモードでクラスタ化するためのプロセスの例を示す流れ図である。

【図10A】インクリメンタルモードでクラスタ化することの例を示す図である。

【図10B】インクリメンタルモードでクラスタ化することの例を示す図である。

【図10C】インクリメンタルモードでクラスタ化することの例を示す図である。

【図10D】インクリメンタルモードでクラスタ化することの例を示す図である。

【図11A】バッチモードでクラスタ化するためのプロセスの例を示す流れ図である。

【図11B】バッチモードでクラスタ化するためのプロセスの例を示す流れ図である。

【図11C】既存のクラスタの１つのメンバに照合するクエリレコードに関するクラスタメンバシップ判定プロセスの例を示す図である。

【図11D】既存の複数のクラスタのメンバに照合するクエリに関するクラスタメンバシップ判定プロセスの例を示す図である。

【図12】複数の照合を調整するプロセスの例を示す流れ図である。

【図13A】複数の照合を調整することの例を示す図である。

【図13B】複数の照合を調整することの例を示す図である。

【図13C】複数の照合を調整することの例を示す図である。

【図14A】クラスタ承認プロセスの例を示す流れ図である。

【図14B】クラスタ承認プロセスの例を示す流れ図である。

【図15A】１つのシステム上で始まり、遠隔システム上で続くクラスタ化の例を示す流れ図である。

【図15B】１つのシステム上で始まり、遠隔システム上で続くクラスタ化の例を示す流れ図である。

【図15C】１つのシステム上で始まり、遠隔システム上で続くクラスタ化の例を示す流れ図である。

【発明を実施するための形態】

【0063】

１ 概略
１．１ 検索ベースのクラスタプロセス概略
図１Ａを参照すると、データ処理システム１０が、データソース１００からのデータをクラスタ化するのに使用される。一部の実施例において、データ処理システム１０によって実行されるクラスタ化プロセスが、場合により、無効な値を含め、それぞれのフィールド（「属性」又は「カラム」とも呼ばれる）に関する値を有するレコードとして編成されたデータ内で出現するトークンを解析する。トークンは、フィールド又はフィールドの組み合わせの中の少なくとも１つの値、又は値の少なくとも１つの断片である。ユーザ１０２が、ユーザインターフェース１０４を使用して、データソース１００、及びデータソース１００の変数関係のネットワークにおける選択されたフィールド（又はフィールドの組み合わせ）における値、トークン、並びに値及びトークンの変数のコレクションに関して、場合により、表とグラフの両方として、レポートを受信すること、変数トークン、類似した句（すなわち、マルチトークン単位）、及び類似したレコードを識別し、トークン、句、又はレコードのあいまいな照合又は偽陽性の照合を見つけ出して、解決し、さらにクラスタメンバシップ判定を行って、各レコードを１又は２以上のクラスタに割り当てるビジネス規則を作成し、保持すること、並びに変数ネットワーク接続及びクラスタメンバシップ判定を点検し、変更し、承認することを含む、クラスタ化プロセスの様々な態様を監視して、制御する。

【0064】

データソース１００は、一般に、データセットとも呼ばれる、様々な個々のデータソースを含み、これらのデータソースそれぞれが、独自の格納フォーマット及びインターフェース（例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイル、又はメインフレームによって使用されるネイティブフォーマット）を有することが可能である。個々のデータソースは、クラスタ化システム１０にローカルであることが可能であり、例えば、同一のコンピュータシステム上でホストされ、又はクラスタ化システム１０から遠隔であることが可能であり、例えば、ローカルエリアネットワーク若しくはワイドエリアネットワークを介してアクセスされる、又はクラウドにおけるウェブサービスを介してクラスタ化システム１０にアクセスする、若しくはそのようなクラスタ化システム１０によってアクセスされる遠隔コンピュータ上でホストされる。

【0065】

データソースにおけるデータは、１又は２以上のレコードとして編成されることが可能であり、各レコードは、値を含む１又は２以上のフィールドを含み、各値は、文字のストリング又はバイナリ値からなる。ストリング文字は、単一バイト又はマルチバイトの文字、例えば、ＡＳＣＩＩ又はユニコードであることが可能である。バイナリデータは、整数などの数、及び画像データなどの生のデータ及び／又は圧縮されたデータを含み得る。

【0066】

データソース１００から読み取られたデータが、変数プロファイラ１１０によって処理される。変数プロファイラ１１０は、トークンを識別し（例えば、所定の規則に基づいて）、データの中の特定のトークンの出現（例えば、特定のトークンが出現するレコードの数）をカウントし、さらに一部の実施例において、特定のトークンが出現する特定のレコードを識別する情報を格納する。また、変数プロファイラ１１０は、何らかの類似性スコアに基づいて、例えば、編集距離、音声上の類似性、又は共有される文字のシーケンスに基づく測定（例えば、「ｅｑｔｙ ｆｎｄ」は、「ｅｑｕｉｔｙ ｆｕｎｄ」に対して、「ｅｑｔｙ ｆｎｄ」のすべての文字が「ｅｑｕｉｔｙ ｆｕｎｄ」の中で同一の順序で出現するので、類似している）によって、互いの変数である識別された異なるトークンのペア（「変数トークンペア」と呼ばれる）を識別することもする。外部データ１０６が、例えば、語の辞書、同義語及び省略形のリスト、ユーザが供給した変数ペアリング（例えば、会社特有の同義語、省略形、又は頭字語）、又は名前の文化的変数ペアリング（例えば、ニックネーム、変数つづり、外来名の変数音訳など）を供給することによって、類似性スコアを使用して変数プロファイラ１１０によって識別されたトークン及び変数トークンペアのコレクションを豊富化する、又は変更するのに使用され得る。そのようなリストは、オリジナルデータセットの中に存在しないトークンを追加する、又は無関係であるトークンの間に類似性によって変数ペアリングを生じさせることが可能である。また、外部データ１０６が、変数ペアリングに関連付けられるスコアを変更するのに（スコアが近さを示すのに使用される場合、このことは、トークン間の見た目の距離を変更するのに使用され得る）、変数ペアリング（例えば、偶然に類似している辞書語間の）を断つのに、又はトークンを削除するのに使用されることも可能である。

【0067】

トークンの例が、値がスペースによって分離された複数の語からなるフィールドの中の語（スペースなしの文字のストリング）、例えば、フルネームを含むフィールドからとられた個人のファーストネーム、又はストリートアドレス（場合により、複数のフィールドを連結することによって形成された）の中の語である。トークンは、都市の名前、「Ｎｅｗ Ｙｏｒｋ」のようにスペースを含むことも可能である。トークンは、政府識別子（ｉｄ）又はインボイス番号のように、数値、場合により、バイナリであることが可能である。トークンは、１つの文字が削除されているストリング、数字が削除されている数、ストリング若しくは数からとられたｎ個の文字の隣り合ったシーケンスからなるｎグラムなどの、ストリング値又は数値の断片であることが可能である。トークンは、画像の中の領域に対応するデータのような、バイナリフィールドの断片であることも可能である。

【0068】

変数プロファイラ１１０によって識別された変数トークンのペアリング（変数トークンペアにする）は、各トークンがノードで表され、変数トークンの間のペアリングが、それらのトークンを表すノード間のエッジに対応する変数ネットワークを規定する。この変数ネットワークが、変数ネットワークアナライザ１２０によって解析されることが可能である。通常のネットワークは、接続された複数の構成要素のコレクションを含むことが可能であり、接続された各構成要素のノードはすべて、その構成要素における別のノードにエッジで接続されるが、互いに接続される、異なる構成要素におけるノードは存在しない。接続された構成要素は、エッジによって接続されたノードのセットの閉包である。定義により、異なる、接続された構成要素は、互いに素である。変数ネットワークアナライザ１２０が、ネットワークの接続された構成要素のコレクションを識別することが可能であり、１又は２以上のトークン代表を、変数ネットワークの接続された構成要素内の各トークンに関連付けることが可能である。変数ネットワークのノードを特徴付ける数量の中には、データセットの中のすべてのレコードにわたる選択されたフィールド（又はフィールドの組み合わせ）の中の関連付けられるトークンのインスタンスのカウントがあり、別個に、トークンとペアにされた変数の数、つまり、そのトークンを代表するノードに接続されたエッジの数に対応する、トークンの度数（又は配位数）が存在する。

【0069】

ユーザ１０２が、ユーザインターフェース１０４において、トークンに関する、詳細には、単一の接続された構成要素内のトークンに関する変数ペアリングのネットワークのグラフ表示を見ることが可能である。変数ネットワークの接続された構成要素の特定のサブセットが重要なものとなる可能性があり、グラフ表示の中で強調表示されてもよい。例えば、より大きいカウントを有するノードに接続されていないノードを考慮されたい。一部の実施例において、これらのノードは、接続された構成要素に関するトークン代表のコレクションとして選択され得る。等しいカウント、又はより小さいカウントのノードにだけ接続するエッジをたどることによって得られたノードのツリーからなるサブネットワークは、トークン代表の正規の近隣と呼ばれ得る。正規の近隣の中のすべてのノードが、その正規の近隣のトークン代表によって表されることが可能である。正規の近隣は、重なり合ってもよい。したがって、トークンは、そのトークンがそれ自体、トークン代表ではない場合、２つ以上のトークン代表に関連付けられることが可能である。ユーザ１０２が、グラフィカルユーザインターフェース１０４を介して正規の近隣、及び正規の近隣の重なり合いを視覚化できることが有用である。

【0070】

選択されたトークンとペアにされた変数トークンのセットは、そのトークンのローカル近隣と呼ばれる。選択されたトークンは、ローカル近隣に関するプライマリと呼ばれる。グラフ表示において、ローカル近隣は、選択された（プライマリ）ノードにエッジで接続されたノードのセットである。トークンの度数（又はグラフ的な意味における配位数）は、ローカル近隣のサイズ（トークン自体を除外するように１を引いた）である。選択されたトークンの重要度は、選択されたトークンのローカル近隣における各トークンに関する出現のカウントの合計を、少なくとも１つのトークン（その選択されたトークンが出現する所与のソース及びフィールド又はコンテキスト）を含むレコードの数で割った比のログとして計算される。この重要度は、様々なトークンの相対的重要性が比較されることを可能にし、すなわち、より高い重要度を有するトークンは、より少ないレコードの中で出現し、したがって、検索において使用される際、より区別する役割をする。

【0071】

一部の実施例において、統計試験によって特異であると識別されるトークン、例えば、カウントが、平均にローカル近隣におけるトークンのカウントの標準偏差を足した合計を超えるトークンが、「（ローカルの）陽性のトークン」と識別され得る。（正規の近隣における、又は実際、任意の近隣におけるトークンに関して同様の識別が行われ得る。）会社名又は個人名の中の個々の語から形成されたトークンに関して、陽性のトークンは、例えば、誤りで形成されたタイプ入力上の変数ではなく、統計的に「実際の」語又は名前である可能性が高い。つまり、そのトークンの出現の頻度が、十分に高く、したがって、データセット内のそのトークンの近隣のコンテキスト内で、そのトークンが偶然、出現した可能性は低い。

【0072】

陽性のトークンは、必ずしも辞書の中で見つかるものと予期されないことに留意されたい。データセットの中でつづりの間違った語が優勢である体系的な理由が存在し得る。詳細には、沢山の勝手に作られた、又は意図的につづりの誤った語が、独特の会社名を形成するのに使用される。同様に、データセットの統計がすべての辞書語の識別をサポートするわけではない可能性があるため、すべての辞書語が陽性のトークンとして認識されるわけではない。

【0073】

多くのローカル近隣は、１つの陽性のトークンを有する。陽性のトークンは、統計的な意味で、「実際の」トークンであり、その他のトークンは、比較的稀な変数である。一部のローカル近隣は、すべての変数トークンの出現の頻度が同様であるため、陽性のトークンを全く有さない可能性がある。このことは、特に、陽性のトークンを区別するのに不十分な統計しか存在しない場合に、データセットの中で稀であるトークンに関して生じ得る。陽性のプライマリトークンのローカル近隣が、２つ以上の陽性のトークンを有する場合、その他の陽性のトークンは、「偽陽性」と見なされる。つまり、それらのトークンは、統計的に、プライマリ陽性トークンの偶然の変数ではなく、他の「実際の」トークンである可能性が高い。そのような偽陽性を識別することは、そのような偽陽性が、意味上の意義に基づいてペアにされるべきではない類似性に基づいてペアにされたトークンを表すので、有用である。変数ネットワークの精度が、そのような変数ペアリングを断つことによって向上させられることが可能である。複数形のような一部の「偽」陽性は、変数として残されるべきであるため、いくらかの配慮が要求される。

【0074】

トークン代表のコンテキストにおいて、正規の近隣に関して陽性のトークンを識別することは、有用であり得る。一部の非常に一般的な個人名は、非常に類似している。例えば、「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」を考慮されたい。１つの代入だけで異なることが、「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」を変数ペアにする。所与のデータセットの中で「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」のいずれかが、他方より頻繁であり、そのいずれかが、「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」の両方を含む正規の近隣において最も頻繁に出現するトークンである可能性が高く、したがって、一部の実施例において、その正規の近隣のトークン代表である。「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」の間の結び付きを断つことによって、「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」はともに、より大きいカウントの別のトークンに結び付けられる可能性が低いトークンになり、すると、それぞれの独自の（重なり合う）正規の近隣を有するトークン代表となる。例えば、「Ｈｅｒｎａｎｄｅｚ」と「Ｆｅｒｎａｎｄｅｚ」の間の結び付き、及び他の類似したペアを断つ、さらなる剪定が、これらの正規の近隣をより完全に分離するのに必要である可能性がある。

【0075】

ユーザ１０２が、ユーザインターフェース１０４を使用して、例えば、ノード間でエッジを追加すること、若しくは削除すること、又はノードを追加すること、若しくは削除することによって、変数ネットワークを操作することが可能である。このことは、適切な外部データ１０６を供給することによって変数プロファイラ１１０によって実行される手順において行われている可能性があるのと同様に、変数ペアリングを追加すること、若しくは断つこと、又はトークンを追加すること、若しくは削除することに対応する。グラフィカルユーザインターフェース１０４が、このことを行う有用な方法をもたらす。また、グラフィカルユーザインターフェース１０４は、陽性のトークンを他のトークンからグラフィックスで区別し、陽性のトークンを接続するエッジを強調表示することも可能である。接続された陽性のトークンのすべての変数ペアをリストアップするビューが、いずれのエッジを断ち、いずれのエッジを保つかを選択する機構と一緒に与えられることが可能である。

【0076】

検索ベースのクラスタ化エンジン１３０が、一部の実施例では、並列に処理されるようにセグメントに分けられ、及び／又はプロセッサの間で分割された「トークン化されたレコード」（コンテンツがトークン化されているレコード）を処理して、類似したコンテンツを有するレコードをグループ化して（それらのレコードに対応するトークンに基づいて）、データクラスタ１８０のコレクションを生成する。クラスタ化エンジン１３０は、データソース１００におけるレコードのバッチ内のすべてのレコードが最初から比較のためにひとまとめに利用できる「バッチモード」（又は「オフラインモード」）で、又はレコードが、到着するにつれ、それまでに処理されているレコードのコレクションに照らして処理される「インクリメンタルモード」（又は「オンラインモード」）で実行されることが可能である。

【0077】

一部の実施例において、バッチモードが、初期のクラスタ化を得るのに使用され、後のレコードが、インクリメンタルモードで追加される。すると、データを追加することは、蓄積されたデータの完全なセットを最初から再クラスタ化することを要求しない。追加のレコードだけを処理する明白なパフォーマンス上の利点に加えて、このことは、クラスタに対するレコードのそれまでに決定された割り当てが、データセット全体が最初から再クラスタ化されるとした場合に生じ得るように、新たなデータが到着するにつれて変わることがあり得ないというさらなる利点を有する。このことは、クラスタ、及びクラスタのメンバが、クラスタ化プロセスとは無関係にビジネス意義を有するとともに、企業は、より多くのデータが利用可能になるというだけの理由でクラスタメンバシップが変わり得るという考え方には抵抗があるので、ビジネスコンテキストでクラスタ化を行う際に特に重要である。

【0078】

クラスタストア１７０は、検索ストア１４６及び代表的レコードストア１７８（図１Ｄ及び図１Ｇ参照）を含め、クラスタ化エンジン１３０によって保持され、クラスタプロセスに参加する。一部の実施例において、クラスタストア１７０に加えて、変数プロファイラ１１０及び変数ネットワークアナライザ１２０からの結果が、クラスタ化プロセス中に類似性に関してレコードを比較する際に考慮に入れられることが可能である。

【0079】

データクラスタは、コンテンツが十分に類似していると判断されているデータレコードのセットである。クラスタに含められたデータレコードは、そのクラスタのメンバであると言われる。一部の実施例において、クラスタの中のレコードは、そのクラスタの他のメンバと高い度合の類似性を示し、他のクラスタのメンバと低い度合の類似性を示す。

【0080】

セグメントは、クラスタにおけるメンバシップに関して互いに比較され得るデータレコードのセットである。異なるセグメントの中のレコードは、クラスタ化エンジン１３０によって比較されず、必然的に、別々のクラスタに対するメンバシップを割り当てられる。データレコードセットをセグメントに入れることは、セグメント化と呼ばれる。レコードは、２つ以上のセグメントのメンバであり得る。一部のシナリオにおいて、例えば、レコードのコレクションを、製品識別子、又は郵便番号若しくは出所の国のような地理的数量のような互いに素なセットに分割する特性を分類する、クラスタにわたって共通であると見込まれる値に基づく自然なセグメント化が存在する。一部の実施例において、データクラスタは、他の基準に基づいてセグメント化されることが可能であり、例えば、データが、政府によって割り当てられた識別子の断片に基づいてセグメント化されることが可能である。一部の実施例において、複数のレベルのセグメント化が可能である。例えば、データが、出所の国別にまずセグメント化されることが可能であり、それぞれの出所の国セグメント内のデータクラスタが、政府によって割り当てられた識別子の断片によってさらにセグメント化されることが可能である。

【0081】

一部の実施例において、並列に処理する際、各セグメントは、異なるセグメントの中のレコード間で比較は全く行われないため、別の処理パーティションに送られることが可能である。他の実施例において、検索ストアを含め、クラスタ化エンジン１３０によって使用される或るデータが、すべてのパーティションによって共有されるという条件付きで、同一のセグメントの中のデータレコードが、並列に処理されるべき別々のパーティションに分割されることが可能である。

【0082】

遠隔処理システム間の情報の制限された流れ、又は単方向の流れが関与する一部の実施例において、クエリ、並びに検索ストアエントリのような共有される情報が、制限された遠隔処理システムにおいて閲覧される結果の信頼性を損なうことなしに、制限された遠隔処理システムに単方向で送られることが可能である。例えば、一部の国々は、それらの国々の国境をまたいだ個人情報の共有を制限し、すなわち、いくつかの国は、他のすべての国へのデータエクスポートを禁止する（例えば、スイス国）一方で、他の国々は、米国を含む、選択された他の国々へのデータエクスポートを禁止する（例えば、フランス）。図１Ｂにおいて、クエリ２０が、ユーザ２２によって米国２１内で開始される。このクエリは、個人名、政府によって割り当てられた識別子、及び生年月日からなることが可能であり、このクエリの目的は、名前を指定された個人によって所有されるすべての銀行口座を見つけ出すことである。このクエリが、米国２１内で保持されるデータクラスタ２３に適用され、いくつかのレコード（候補レコードと呼ばれる）が返される。検索ストア１４６からの検索エントリ、又は代表的レコードストア１７８からの代表的レコードなどのさらなる情報が、このクエリの結果として取り出され、保持されることが可能である。このクエリ、候補レコード、及び、場合により、さらなる情報が、選択的データエクスポートの国４１内で保持されるデータクラスタ４３に照らして、ローカルユーザ４２によってローカルでクラスタ化されるように、選択的データエクスポートの国４１に送られることが可能である（４０）。同様に、このクエリ、候補レコード、及び、場合により、さらなる情報が、選択的データエクスポートの国５１内で保持されるデータクラスタ５３に照らして、ローカルユーザ５２によってローカルでクラスタ化されるように、データエクスポート禁止の国５１に送られることが可能である（５０）。クラスタ化の結果は、適切なローカルアクションのために、例えば、詐欺検知又は法律執行のために、制限されたデータエクスポートの国々の国内で利用可能となる。制限されたデータエクスポートの国がその国のデータ、又はその国の共有される情報（検索エントリ又は代表的レコードのような）をエクスポートしないことは、制限されたデータエクスポートの国におけるデータから導き出されるクラスタメンバがその国の外では見えないことを単に意味する。その制限された国の外でクラスタ化されたデータの完全性は、影響を受けない。

【0083】

一部の実施例において、レコードの類似性は、採点関数及びビジネス規則を使用して、データレコードの１又は２以上のフィールドからのトークンの比較を組み合わせてスコアにすることによって測定される。検索コード及び照合コードなどのデータパターンコードが、レコードの特性を要約し、類似性を測定するためのビジネス規則を作成する際と、結果をユーザ１０２に提示する際の両方で役立つ。例えば、レコードに関する検索コードが、レコードのセットの間で共有されるトークンの組み合わせにラベルを付けることが可能である一方で、ペアに関する照合コードが、比較されている各フィールド、又はフィールドの各組み合わせに関して照合品質、及び入力の状態を符号化することが可能である。例えば、比較されるフィールド値のペアに関する照合コード内の照合品質状態は、それらの値が同一であった場合、「厳密な照合」を含むことが可能であり、又は類似性スコアがファジー照合閾値より大きかった場合、「ファジー照合」を含むことが可能である。照合コード内の入力状態は、ペアのレコード１における値が無効又は空白（０以上のスペース文字）である場合、「入力されていない１」を含むことが可能であり、あるいはペアのレコード１における値とレコード２における値がともに入力されている、又はともに無効若しくは空白である場合、「相互に関係する入力」を含むことが可能である。検索コード又は照合コードは、検索又は照合ペアを特徴付ける様々な属性に関するそのようなコード化された状態のコレクションから組み立てられる。各検索コードを有するサンプルレコード、又は各照合コードを有する照合するペアからのサンプルレコードが、ユーザに表示され得る。このことは、ユーザが、クラスタメンバシップ判定を行うのに使用される類似性の測定を開発し、改良し、調整するのに役立ち得る。

【0084】

クラスタ承認エンジン１９０が、ユーザ対話を介してクラスタ判定を繰り返し改良するのに使用され得る。ユーザ１０２が、例えば、レコードをクラスタのメンバとして確認して、又はレコードを新たなクラスタ若しくは既存のクラスタに再マップして、ユーザインターフェース１０４を介して一連のクラスタ承認判定を行う。クラスタ全体を分割するのに、又はマージするのに、選択されたレコードがユーザ１０２によって再マップされるだけでよい。クラスタ承認判定によって潜在的に影響を受けるレコードが、クラスタ化エンジン１３０を介して識別され、取り出され、再処理されて、変更されたデータクラスタ１８０がもたらされる。個々のレコードを再マップすることは、クラスタメンバシップに対してカスケード効果を有し、影響を受けるレコードが再クラスタ化されると、既存のクラスタが分割される、又はマージされることをもたらし、つまり、クラスタのオリジナルプライマリレコードに対してよりも、再マップされるレコードに近いレコードは、再マップされるレコードと一緒に再マップされるレコードの新たなクラスタに移動する。ユーザ１０２には、ユーザによるクラスタ承認選択によって誘発された変化を検証するようにユーザインターフェース１０４においてデータクラスタの「前と後の」表現が示されることが可能である。次に、ユーザ１０２が、結果に満足するまで、クラスタを変更することを繰り返しで継続することが可能である。再マップすることによって生じるカスケード効果のため、ユーザは、個々のすべてのレコードの配置を細かく管理する必要なしに、いくつかの賢明な変更で多くのレコードの配置を操作することができる。

【0085】

１．２ クラスタ化エンジン
図１Ｃは、クラスタ化エンジン１３０の実施例の要素を図示する。一部の実施例において、データソースレコード１００又はトークン化されたレコード１１８が、セグメント化エンジン１３２によって読み取られて、セグメントに分離され、及び／又は並列パーティショナ１３４によって並列処理のために複数のプロセスの間に分割される。

【0086】

一部の実施例において、オリジナルレコード又はトークン化されたレコードのセットが、より区別しやすいレコードを先にして、レコードの識別性又は豊かさを反映する順序を課すように並べ替えられる（１３６）（各セグメント内、及び／又は各プロセス内で）ことが可能である。このことは、クラスタ化の品質を向上させ得る。識別性とは、多様な値及び複数のトークンを包含するより完全に入力されたフィールドを有するレコードが、入力されていないフィールド、及びデフォルトの値又は単一トークンで入力されたフィールドを包含する、場合により、不完全なレコードの場合と比べて、他のレコードから直観的により区別しやすいということを意図している。

【0087】

例えば、１つの識別性の基準は、レコードの特徴的入力パターンに基づくことも可能である。入力パターンコードが、例えば、レコードの中の１若しくは２以上のフィールドの選択されたセット、又はフィールドの組み合わせに関する値のセット（クラスタメンバシップと関係のある）、例えば、フィールドが入力されていない（無効、空、又は空白）場合の値「０」、フィールドがデフォルトの値を包含する場合の値「１」、フィールドにデフォルトでない値が入力されている場合の値「２」を連結することによって、レコードの入力の状態を符号化するのに使用され得る。他のより大きい値が、フィールドの入力の状態、例えば、テキストフィールドの中のトークンの数のさらなる定性的な区別を行うのに使用されることも可能である（それらの数が「９」を超え得る場合、他のコード値の表現において適切な補償を行って）。識別性のスコアが、入力パターンコードにおける様々な入力値の重み付けされたスコアとして計算されることが可能である。より高いスコアは、より区別しやすいレコードを示し、レコードを編成する並べ替え１３６は、識別性のスコアの上位の順からの並べ替えであることが可能である。（一般に、並べ替え順序は、スコアにまず変換することをしない、入力パターンコードなどの数値でない識別性の基準から決定され得る。）識別性のより正式の測定は、所与のソース及びフィールド（又はコンテキスト）における各トークンの重要度のような統計的な測定を含む変数プロファイラストア１１５の中のデータを使用して構築され得る。

【0088】

識別性の並べ替え１３６を行う目的は、そうすることが、クラスタ化メンバシップ判定プロセスがインクリメンタルであるため、すなわち、レコードが、処理されるにつれ、クラスタに割り当てられるため、より良好なクラスタ化結果につながることである。詳細には、クラスタの数は、始めには知られておらず、レコードが処理されるにつれ、新たなクラスタが発見される。識別性の順序付けは、クラスタメンバシップ判定プロセスと一緒に機能して、クラスタメンバシップ判定プロセスと適合する最大数の個別のクラスタをもたらすように設計される。より低い識別性のスコアを有し、しばしば、それに付随するより低いデータ品質を有するレコードが先に処理された場合、それらのレコードが、さもなければ区別しやすいクラスタの凝集を誘発する傾向があることを経験が示す。

【0089】

一部の実施例において、実質的に異なるデータ品質を有するレコードが別々に処理されるデータ品質カスケードでクラスタ化を実行することが好ましい可能性がある。例えば、顧客名、政府ｉｄ、及び生年月日を有する銀行レコードに関して、３つすべてのフィールドが（デフォルトでない値で）入力されているレコードのセットを、２つのフィールドが（デフォルトでない値で）入力されているレコードとは別個に、１つだけのフィールドが入力されているレコードとは別個に処理する価値がある。クラスタ化メンバシップ判定の信頼性は、レコードの完全性が低下するにつれて低下し、別々のクラスタ化動作を行うことが、ユーザがこのことの影響を理解するのを助ける可能性がある。同様に、異なる識別性のスコアのレコードが、ユーザ１０２のためにユーザインターフェース１０４においてグラフ表示で特徴付けられることも可能である。例えば、それらのレコードが、いずれのレコードの信頼性がより低いかをユーザが一目で見分けることができるように、高い識別性から低い識別性までに及ぶ階調スケールで色付けされることも可能である。また、ユーザインターフェース１０４は、やはり、ユーザが所与の品質のデータに集中することを可能にする、異なる範囲の識別性を有するトークンの表示のオンとオフを切り換えるためのスイッチを有することも可能である。ここで、識別性は、データ品質の代わりとして使用されているが、グラフ表示は、クラスタ化を駆動するのに使用される識別性のスコアとは無関係に導き出されたデータ品質の直接の測定を使用することも可能である。

【0090】

クラスタ化エンジン１３０は、比較のために利用可能なレコードのセットの中から、クエリレコードと呼ばれる、それぞれのオリジナルレコード又はトークン化されたレコードに関する候補照合を識別する候補検索エンジン１４０を含む。候補検索エンジンによってレコードが全く取り出されない場合、新たなクラスタｉｄが生成されて、そのクエリレコードに割り当てられる。その新たなクラスタについての適切な情報が、クラスタストア１７０の中に格納される。レコードが候補検索エンジンによって取り出された場合、それらのレコードは、クラスタメンバシップ判定を行うのに先立って、採点エンジン１５０によってクエリレコードに照らして詳細に採点される。クラスタメンバシップエンジン１６０が、採点されたクエリレコードのクラスタメンバシップを判定する。変数プロファイラ１１０によって生成された変数プロファイラストア１１５、及び変数ネットワークアナライザ１２０によって生成された変数ネットワークストア１２６、並びに他のクラスタストア１７０がすべて、候補レコードを識別すること、及び採点することを支援するように候補検索エンジン１４０及び採点エンジン１５０によって使用され得る。

【0091】

一部の実施例において、単一のレコードが、例えば、異なるセグメントの中で、又は異なるクラスタ戦略を用いた別々のクラスタ化動作で、複数のクラスタに割り当てられることが可能である。複数照合リコンサイラ１６５が、各レコードを単一のクラスタに関連付けるように割り当てを調整するのに使用され得る。

【0092】

一部のシナリオにおいて、複数のクラスタに対するあいまいな照合が、複数の照合が調整された後に、例えば、レコードが２つ以上のクラスタにおけるメンバシップに近い場合のように、代替の照合を区別するのに不十分な情報しか存在しない場合に、残る可能性がある。例えば、「Ａｃｍｅ Ｉｎｄｕｓｔｒｉｅｓ Ｃａｎａｄａ」という名前、及び「Ａｃｍｅ Ｉｎｄｕｓｔｒｉｅｓ Ａｕｓｔｒａｌｉａ」という名前でラベルが付けられた別々の２つのクラスタが存在するものと想定されたい。「Ａｃｍｅ Ｉｎｄｕｓｔｒｉｅｓ」というクエリレコードは、両方の名前に対して等しい照合である。他の情報がない状況において、「Ａｃｍｅ Ｉｎｄｕｓｔｒｉｅｓ」がいずれのクラスタに割り当てられるべきかは、あいまいであり、解決できない。そのような事例において、あいまいな照合が、場合により、あいまいな照合に関与するレコードに、クラスタ化される（照合する）レコードのネットワークのグラフ表示において別の色で印を付けて、ユーザインターフェース１０４においてユーザ１０２に報告され、表示されることが可能である。

【0093】

一部の実施例において、クラスタメンバシップ判定プロセスは、あいまいなレコードを、可能な代替のクラスタのセットからの１つのクラスタに割り当てることが可能である。あいまいなメンバとペアにされたクラスタメンバシップ判定に関与するクラスタの各メンバに関して、ユーザインターフェース１０４が、あいまいなレコードから、メンバシップが許可されたクラスタのペアにされたメンバに至るエッジを１つの色で表示し、メンバシップが拒否されたクラスタの対応するメンバに至る各エッジを異なる色で表示することが可能である。（例えば、図１１Ｄで、あいまいなレコード１１９０と照合するクラスタのメンバ１１９３の間のエッジが黒で示される一方で、あいまいなレコードと照合されないクラスタのメンバ１１９４の間のエッジがグレーで示される。）この表示は、ユーザ１０２が、クラスタメンバシップエンジンによって行われた判定を、クラスタメンバシップエンジンによる割り当てを受け入れる、又は変更する前に直ちに利用可能な代替から容易に区別できるようにすることが可能である。

【0094】

候補検索エンジン１４０の目的は、類似性の最低限の標準を満たすレコードだけを取り出す検索を実行することによって、クエリレコードと詳細に比較される必要があるレコードの数を減らすことである。基本的に、比較に利用できるレコードのセット（バッチ事例では、セグメントの中のすべてのレコード）には、インデックスに照らした検索が、照合である可能性が全くないレコードを破棄する計算リソースをわずかしか使用しない高速のフィルタとして使用され得るように、インデックスが付けられる。クラスタ化エンジン１３０のパフォーマンスは、候補検索エンジン１４０が、詳細に考慮されるべきレコードのセットを絞ることの成功に劇的に影響され得る。

【0095】

１．３ 候補検索エンジン
図１Ｄは、候補検索エンジン１４０の実施例の要素の概略を示す。クエリレコードが、データソースレコード１００Ｐ又はトークン化されたレコード１１８Ｐのセットから読み取られる。このクエリレコードは、オリジナルレコード又はトークン化されたレコードが、並列に処理されるようにセグメント化され、及び／又は分割されている場合、セグメントの中に、及び／又は並列パーティションの中に入っていることが可能である。クエリは、クエリレコードの１若しくは２以上のフィールド、又はフィールドの組み合わせから１若しくは２以上のトークンを選択する事前定義された、又はユーザによって指定された手順に基づき、クエリ構築手順１４２によって、選択されたトークン、又は選択されたトークンの組み合わせから生成される。一部の実施例において、生成されたクエリは、クエリ展開エンジン１４３によって、１又は２以上の特定のクエリを含む展開されたクエリに展開される。

【0096】

一部の実施例において、採点エンジン１５０によるクラスタメンバシップを判定することに関与する、採点フィールドと呼ばれるフィールドのコレクションが、採点エンジン１５０によって使用される採点規則から見出されることが可能である。採点規則は、事前定義された、又はユーザによって指定された規則セットの中で指定され、この規則セットの中で、１若しくは２以上のフィールド、又はフィールドの組み合わせが、類似性に関して別々に比較され、その後、集合的なセットの中間フィールドスコアが組み合わされて、全体的なレコードスコアが計算される。規則セットは、規則のコレクションであり、それらの規則それぞれが、入力値、定数、パラメータ、他の中間値、他の出力値、並びに１又は２以上の事例ベースの割り当てのセットの中で他のデータセットを調べることによって得られた値を組み合わせることによって、１若しくは２以上の中間値又は出力値を計算し、このことは、組み込まれた論理演算及び数学的演算、組み込まれた関数、並びにユーザによって定義された関数の組み合わせを使用することが可能である。規則セットは、いくつかがベクトルであり得る、１又は２以上の出力値を生成することが可能である。採点規則セットの中の採点規則は、入ってくるデータレコードからの選定されたフィールドを使用し、これらのフィールドが、ひとまとめに採点フィールドと呼ばれる。

【0097】

採点フィールドの中で同一の値を共有するレコードのセットは、同一のクラスタメンバシップ判定を共有する。採点フィールド重複排除モジュール１４４が、そのようなレコードセットの最初のレコードだけが採点にかけられ、後続のレコードは、そのクラスタメンバシップ結果を単に継承することを確実にする。

【0098】

検索エントリ展開エンジン１４５が、入ってくるデータソース１００全体におけるレコードに、又は既存のデータクラスタレコードのセット１８０に適用されて、検索ストア１４６が構築される。

【0099】

クエリレコードが、候補検索エンジン１４０のコア検索エンジン１４７に送られる。検索エンジン１４７は、展開された各クエリを取り込み、そのクエリレコードと識別された候補照合レコードの間の可能な候補照合の一意のレコード識別子の１又は２以上のリストを返す。これらのリストは、クラスタ候補セレクタ１４８に送られ、セレクタ１４８が、事前定義された規則及び／又はユーザによって指定された規則（例えば、規則セット）を適用して、採点エンジン１５０による詳細な採点の投資に値する最低基準を満たす候補照合レコードのリストを識別する。一部の実施例において、クエリレコードと利用可能なレコードの間で照合するトークンの組み合わせを特徴付ける検索コードが、選択プロセスを円滑にするとともに、選択プロセスを遡及的に解析するのに使用される。

【0100】

１．４ 変数プロファイラ
図１Ｅは、変数プロファイラ１１０の実施例の要素の概略を示す。変数プロファイラ１１０は、参照により本明細書に組み込まれている、「Managing an Archive for Approximate String Matching」という名称の米国特許出願公開第２００９／０１８２７２８号明細書において説明されるようなアーカイブを生成するためのプロセスを含む、変数トークンのペアリングを識別するアーカイブを生成するための様々な技法のいずれかを使用することが可能である。レコードが、データソース１００から読み取られる。それらのレコードが、スタンダダイザ１１２及びトークナイザ１１３によって処理されることを含め、データ準備モジュール１１１におけるプロファイリングのために準備される。スタンダダイザ１１２が、選択されたフィールド（又はフィールドの指定された組み合わせ）の性質及び意味に基づいて、入ってくるデータを標準化するように事前定義された規則及び／又はユーザによって指定された規則を適用する。例えば、ストリング値が、小文字に変換されることが可能であり、特定の句読文字が、削除される、スペース文字で置換される、又は削除されることと、スペース文字で置換されることの両方が行われる（場合により、複数のレコードをもたらして）ことが可能である。トークナイザ１１３が、フィールドの性質及び意義に応じて、フィールドの中の値に適用される事前定義された規則及び／又はユーザによって指定された規則に基づいて、トークンのリストを識別する。例えば、アドレスのストリートの行が、スペース文字で分割されて、語のリストになることが可能である一方で、場合により、「Ｎｅｗ Ｙｏｒｋ」のような意味単位を表す値を包含する都市フィールドは、語に分割されない。トークナイザ１１３が、クラスタ化エンジン１３０によるさらなる処理のためにトークン化されたレコード１１８のデータセット又はデータストリームを生成する。

【0101】

トークン化されたレコードの別々のトークンが、各トークンのインスタンスの数（例えば、トークンが出現するレコードの数）をカウントすることを含め、変数プロファイリングエンジン１１４によってプロファイリングされる。一部の実施例において、トークンが出現したデータソース、フィールド、及び／又はコンテキスト（フィールドの論理グループ化）を識別するキーが、そのトークンに関連付けられることが可能であり、そのトークンのインスタンスの数の対応するカウントが保持されることが可能である。このことは、異なるソース、異なるフィールド、又は異なるコンテキストにおいて出現する同一のトークンに関して別々の統計が集計されることを可能にする。一部の実施例において、所与のフィールド又はコンテキストにおいてトークンが出現するレコードを識別するロケーション情報も、トークンに関連付けられる。このロケーション情報は、トークンが出現する各レコードに関してビットが設定される、圧縮されてもよい、ビットベクトルの形態であることが可能である。それらのビットの順序は、レコードのロケーションに明示的に、又は暗黙にマップされ得る。

【0102】

変数プロファイリングエンジン１１６が、トークン類似性測定に基づいて、互いの変数であるトークンを識別することにとりかかる。多くのトークン類似性測定が可能である。１つのトークン類似性測定は、編集距離に基づいて類似性に関してトークンを比較することである。レーベンシュタイン編集距離は、１つの語を別の語に変えるのに要求される挿入、削除、及び代入の数をカウントする。２つの語がより類似しているほど、それらの語の編集距離は小さくなる。別の測定は、例えば、ＳＯＵＮＤＥＸ符号化を使用して、音声上の類似性に基づいて語を比較することである。

【0103】

第３の可能性は、共有される文字のシーケンスを比較することである。基本シーケンス類似性スコアが、共有される文字の数をカウントし、短い方のストリングの長さによって割ることによって、計算され得る。次に、完全シーケンス類似性スコアが、シーケンスの乱れた文字、及びストリングの長さの差に関して基本スコアから重み付けされたペナルティを引くことによって形成される。例えば、「ｅｑｔｙ ｆｎｄ」と「ｅｑｕｉｔｙ ｆｕｎｄ」は、それぞれ、可能な８つの文字及び１１の文字のうち、スペース文字を含め、８つの文字を共有する。基本類似性スコアは、１である。シーケンスの乱れた文字は存在せず、長さの差は、３である。したがって、０．０５という長さミスマッチの重みを用いると、シーケンス類似性スコアは、１−０．５^＊３＝０．８５である。

【0104】

一部の実施例において、変数プロファイリングエンジン１１４は、変数ペア、及び変数ペアの類似性スコアを識別するスコアアーカイブ、並びにトークンのソース−フィールド−コンテキスト出現それぞれにおけるすべてのトークン、関連付けられるカウント、ロケーション情報、及び同一のソース−フィールド−コンテキストにおける変数トークンのリスト、及びそれらのトークンのカウントを包含する変数アーカイブを含む、変数プロファイラストア１１５を生成する。変数ネットワーク１１６が、各ノードがトークンであり、各エッジが変数トークンのペアリングである変数アーカイブから計算されることが可能である。変数ネットワーク１１６は、ユーザ１０２が、場合により、変数プロファイリングエンジン１１４によって変数ペアとして識別されていないトークンを結び付けるようにエッジを追加して、又は意味に基づいてではなく、類似性に基づいてのみ変数であるトークンを接続するエッジを削除して、変数ネットワーク１１６を操作することが可能なユーザインターフェース１０４においてグラフ表示されることが可能である。

【0105】

一部の実施例において、変数プロファイラストア１１５及び変数ネットワーク１１６は、外部データ１０６を組み込むことによって豊富化され得る。外部データ１０６は、ユーザによって供給された、又は第三者から入手可能な同義語及び省略形のリストを含み得る。外部データソースの一例が、ニックネーム、代替のつづり、及び代替の音訳を含む、名前の文化的変数のリストである。例えば、そのようなデータは、外部データの中のトークンのすべて、及びそれらのトークンに伴う変数ペアを変数プロファイラストア１１５及び変数ネットワーク１１６に追加することによって、又はそのデータの中で存在するトークン間のペアリングだけを追加することによって、組み込まれ得る。外部データの中のトークンのすべて、及びそれらのトークンに伴う変数ペアを変数プロファイラストア１１５及び変数ネットワーク１１６に追加する場合、そのデータの中に存在しないトークンに関連付けられるカウントは、０でなければならない。そのようなトークンが将来の処理において生じた場合には、そのトークンのカウントが増やされることが可能であるが、他のトークンに対する暗示される結び付きは、既に存在していることになる。

【0106】

１．５ 変数ネットワークアナライザ概略
図１Ｆは、変数ネットワークアナライザ１２０の実施例の要素の概略を示す。変数ネットワーク１１６が読み取られ、ネットワーク解析エンジン１２２がネットワーク解析を行う。一部の実施例において、このネットワーク解析は、変数ネットワーク１１６内の変数トークンの接続された構成要素のセットを識別し、後段でいくつかが説明されるさらなる解析を実行することが可能である。ユーザ１０２が、各トークンがノードとして表示され、トークンの各変数ペアリングがエッジによって示される変数ネットワーク１１６のグラフ表示を、ユーザインターフェース１０４において閲覧することが可能である。このグラフ表示は、後段で列挙される例における情報などの、ノード及びエッジを特徴付ける情報で飾られることが可能である。ユーザ１０２は、ユーザインターフェース１０４を使用して、ノード若しくはエッジを追加して、若しくは削除して、又は飾られた情報を編集して、変数ネットワーク１１６を繰り返し変更することができる。

【0107】

トークンのローカル近隣が表示され得る。ネットワークアナライザ１２２によって行われる近隣解析が、陽性のトークン（ローカル近隣、又は他の近隣において他のトークンから統計的に区別可能なトークン）、及び陽性のトークンのペアを接続するエッジを識別し、さらにグラフ表示においてそれらのトークン及びエッジに印を付けることが可能である。

【0108】

各トークンのインスタンスのカウントが、その表示において示されることが可能であり、一部の実施例において、そのノードのために使用されるアイコンのサイズによって図示されることが可能である。より大きいカウントの変数に全く接続されないトークンが、それらのトークンの正規の近隣（最大カウントのトークンから始めて、等しいカウント、又はより小さいカウントのトークンに対するすべての変数ペアリングを追うことによって形成されるトークンのツリー）と一緒に識別され、表示されることが可能である。トークン代表は、選択された近隣におけるすべてのトークンを代表するように選択されたトークンである。トークン代表セレクタ１２４が、接続された各構成要素から１又は２以上のトークン代表、例えば、正規の近隣の最大カウントのトークンを選択することが可能である。トークン代表に関連付けられる正規の近隣及びその他の近隣は、重なり合う可能性がある。

【0109】

変数プロファイラストア１１５からとられたトークンの重要度が、いずれのトークンが、検索用語として使用された際、比較的より区別する役割をするかを示す。選択されたトークンの重要度は、その選択されたトークンのローカル近隣における変数のカウントから計算され、その選択されたトークンに関連付けられる。変数のペアにされたトークンは、異なるローカル近隣を有する可能性があるので、それらのトークンの重要度は、異なる可能性があり、それ故、各トークンに重要度を関連付けることが重要である。重要度は、変数ネットワークのグラフ表示において色のグラデーションで表示され得る別の特性である。

【0110】

ローカル近隣の（シンプソンの）多様度指数が、各トークンに関連付けられる別の数量である。正規化されると、シンプソンの多様度は、指定されたトークンの変数のカウントの分布の偏りを反映する。多様度の正規化されていない大きさは、ランダムに選択されたトークンの変数が有するものと予期されるカウントである。指定されたトークンの第ｋ番の変数のカウントがｎ_ｋである場合、変数（指定されたトークンを含まない）の合計数は、ｎ_ｋのｋにわたる合計である。多様度は、
多様度＝＜ｎ_ｋ＞＝Σ_{ｋ ｉｎ ｖａｒｉａｎｔｓ}ｎ_ｋｐ_ｋ＝Σ_{ｋ ｉｎ ｖａｒｉａｎｔｓ}ｎ_ｋ^２／Ｎ、
ただし、
Ｎ＝Σ_{ｋ ｉｎ ｖａｒｉａｎｔｓ}ｎ_ｋ
は、変数の合計カウントであり、さらに
ｐ_ｋ＝ｎ_ｋ／Ｎ
は、ランダムに選択された出現が第ｋ番の変数に関連付けられる確率である。示される多様度を正規化するのに、Σ_{ｋ ｉｎ ｖａｒｉａｎｔｓ}ｎ_ｋで割って、０〜１までの範囲内の量を得る。この多様度は、トークンの相互関係が低い多様度を暗示するため、互いに関係するトークンの間の結び付きを識別するために役立ち得る。このことは、陽性のトークンを識別するのに使用される測定と類似するが、異なる測定を与える。

【0111】

ネットワーク解析の結果は、一部の実施例において、トークン代表ストア１２７及び近隣解析ストア１２８を含む、ネットワーク解析ストア１２６のコレクションの中に格納され得る。トークン、及びトークンに関連付けられるトークン代表は、トークン代表ストア１２７の中に格納され得る。近隣解析ストア１２８が、陽性のトークン、陽性のトークンの変数ペア、及び正規の近隣を含め、ネットワーク解析から集められた情報を包含することが可能である。

【0112】

１．６ クラスタ承認プロセス概略
図１Ｇは、クラスタ承認エンジン１９０の実施例の要素の概略を示す。クラスタメンバシップ判定が、ユーザインターフェース１０４を使用してユーザ１０２によって点検されることが可能である。１つのレコードが、メンバであり得るように２つ以上のクラスタに十分に近い、あいまいなクラスタメンバシップ判定が、クラスタ化エンジン１３０によって合図され、ユーザ１０２によって解決されることが可能である。エンジン１９０の図示される要素は、ユーザ入力によって開始され得るアクションに対応する。

【0113】

レコードが、所与のクラスタのメンバとして確認されることが可能である（１９２）。レコードの一意のレコード識別子と、関連付けられる確認されたクラスタのクラスタｉｄをペアにする判定が、クラスタストア１７０の中で確認済み又は除外済みのストア１７２の中に格納されることが可能である。確認されたレコードが、確認済み又は除外済みのストア１７２の中にそのレコードの一意のレコード識別子が（確認されたセットの中に）存在することで明らかになることとして、クラスタ化エンジン１３０に提示された場合、その確認されたクラスタのクラスタｉｄが、さらなる処理なしに報告される。

【0114】

レコードが、所与のクラスタから除外されることが可能である（１９４）。その判定が、クラスタストア１７０の中で確認済み又は除外済みのストア１７２の中に格納されることが可能である。除外されたレコードが、クラスタ化エンジン１３０に再び提示された場合、そのレコードは、除外されたクラスタにおけるメンバシップを阻止され、必然的に、異なる、場合により、新たなクラスタに割り当てられる。

【0115】

レコードは、他のクラスタに再マップされることが可能である（１９６）。詳細には、クラスタは、１又は２以上のレコードを新たなクラスタに割り当てることによって、２又は３以上の部分に分割されることが可能である（１９７）。多くの事例において、再処理が行われた際など、選定された個別のレコードを再マップするだけでよく、オリジナルクラスタプライマリレコードと比べて、それらのレコードにより類似したレコードは、再マップされたレコードの後を追って再マップされたレコードの新たなクラスタに入る。また、クラスタは、１又は２以上のレコードを既存のクラスタに再マップすることによって１つのクラスタにマージされることも可能である（１９８）。やはり、多くの事例において、再クラスタ化に先立って、選定された個別のレコードを再マップするだけでよい。

【0116】

２ 実施例
２．１ 変数プロファイラ及び削除−結合手順
変数プロファイラ１１０が、変数のペアを識別し、それらのペアの類似性を測定し、さらに変数トークンのペア、及びそれらのペアの類似性スコアを変数プロファイラストア１２６の中に格納する。一部の実施例において、変数プロファイラ１１０が、トークンのすべてのペアの間の編集距離を計算し、編集距離（「類似性スコア」）が所定の閾値を下回るトークンのペアを格納する。レーベンシュタイン編集距離が、１つのトークンを別のトークンに変えるのに要求される最低限の数の挿入、削除、及び／又は代入をカウントし、タイプ入力上の類似性の広く使用されている測度である。残念ながら、トークンのすべてのペアを比較するアプローチは、大多数のトークンペアは、類似性を全く有さず、したがって、多量の計算労力がほとんど利益なしに費やされるため、非効率である。

【0117】

削除−結合手順が、レーベンシュタイン編集距離とほぼ同じように、タイプ入力上の変数に基づいてトークンの類似性を測定するが、比較的近いトークンだけを比較するように設計され、その結果、多数の無関係のトークンを評価する計算費用が節約される。このことは、「Managing an Archive for Approximate String Matching」という名称の米国特許出願公開第２００９／０１８２７２８号明細書においてより完全に説明される。

【0118】

一部の実施例において、削除−結合手順は、以下のように進められる。トークン辞書（すなわち、カタログ、又はトークンのリスト）の中の各トークン、又はトークン辞書の一部分（例えば、所与のソース、所与のフィールド、及び／又は所与のコンテキストに関する）に関して、そのトークンから単一の文字を削除することによって形成されるすべての変数が作られる。所与のトークンに関するこの「削除セット」は、オリジナルトークンを識別するキー（「ｔｏｋｅｎ＿ｋｅｙ」）、オリジナルトークン（「ｏｒｉｇｉｎａｌ」）、削除変数トークン（「ｄｅｌｅｔｉｏｎ＿ｖａｒ」）、及びオリジナルトークンから削除された文字の位置（「ｄｅｌｅｔｉｏｎ＿ｐｏｓ」）をそれぞれが有するエントリのリストを包含する。削除セットのコレクションは、変数プロファイラストア１１５の中にトークン辞書と一緒に格納されることが可能であり、又はやはり変数プロファイラストア１１５の中に格納される変数ペアを生成するように変数プロファイリングエンジン１１４によって使用された後、破棄されることが可能である。

【0119】

オリジナルトークンは、削除変数と一緒に削除セットの中に０という削除された文字位置で含められることが可能である。例えば、以下が、トークンＬＯＮＤＯＮに関する削除セットである。すなわち、

【0120】

【表1】

【0121】

｛ｔｏｋｅｎ＿ｋｅｙ，ｄｅｌｅｔｉｏｎ＿ｐｏｓ｝は、所与の削除変数を識別する一意の「キー」であることに留意されたい。

【0122】

削除−結合手順は、２つ以上の削除に拡張され得る。一部の実施例において、削除位置のシーケンスは、類似性を採点する際に使用するために記録されることが可能である。他の実施例において、削除位置は、保持されなくてもよく、採点は、代替の手順を使用して行われ得る。

【0123】

削除−結合手順と類似した手順が、ｄｅｌｅｔｉｏｎ＿ｖａｒトークンに対して結合（又はルックアップ）操作を実行することによって１又は２以上の辞書の中のトークンの間で変数照合を判定するのに使用され得る。結合／ルックアップ操作は、高速で、選択的である。ｄｅｌｅｔｉｏｎ＿ｖａｒトークンを共有する２つのトークンが、各トークンにおいて多くとも１回の削除（削除−結合１変数に関して）だけ異なることが可能であり、したがって、それらのトークンは、編集距離が「近い」。このことは、削除−結合手順の潜在的な利点、すなわち、採点する価値があるだけ十分に近いペアだけを識別することによって、採点を要求するペアの数を減らすことをもたらす。一部の実施例において、ｄｅｌｅｔｉｏｎ＿ｖａｒ上でペアにされたトークンの間の類似性スコアが、事前定義された、又はユーザによって指定された類似性関数を使用して、関連付けられるオリジナルトークンの間で直接に計算される。例えば、ペアにされた２つのトークンが、レーベンシュタイン編集距離又は他の何らかの編集距離測定を使用してそれらのトークンの編集距離を計算することによって比較されることが可能である。削除−結合手順のこの適用は、ユーザが、所望される任意の類似性採点手順を使用することを可能にしながら、採点すべきペアの数を減らすという潜在的な利点を有する。

【0124】

他の実施例において、変数ペアリングの品質が、削除された文字の位置を比較することによって採点される。このことは、削除−結合手順から集められた情報を活用する編集距離様の測定の高速な計算をもたらし（一方、レーベンシュタイン編集距離計算は、事実上、トークンペアに関してゼロからやり直す）、さらにペアリングの特徴を強調するスコアのカスタマイズを可能にする。類似性スコアを計算するための手順の一例において、異なるタイプの変更にポイントが以下のとおり割り当てられることが可能である。すなわち、削除（又は挿入）に関して１ポイント、最初の文字を変更することに関して１ポイント、最後の文字を変更することに関して１ポイント、削除された文字の位置が２つ以上、離隔している場合、１ポイントである。各タイプの変更に関連付けられた重みは、調整可能である。一方のトークンの削除位置が０であり、他方のトークンの削除位置がそうではない場合、このことは、単一の挿入又は単一の削除である。削除位置が同一である場合、このことは、代入である。削除位置が１だけ異なる場合、このことは、入れ換えである。同一のｔｏｋｅｎ＿ｋｅｙと、同一のｄｅｌｅｔｉｏｎ＿ｐｏｓとを有する照合は、厳密な照合であるので、無視される。また、同一のトークンの中のペアにされた文字の削除を示す照合も、厳密な照合として無視される（例えば、ＭＥＥＴが、１つのインスタンスで文字２を削除することによって、第２インスタンスにおいて文字３を削除することによってＭＥＴに変換されることが可能であり、ペアリングは、共有されるトークンＭＥＥＴを単に返す）。

【0125】

以下は、オリジナルトークンＬＯＮＤＯＮ、ＬＯＤＯＮ、ＬＯＭＤＯＮ、ＬＯＤＮＯＮ、ＬＯＤＯＯＮに関するそれぞれの削除セットからの選択されたエントリの例である。

【0126】

【表2】

【0127】

この例において、削除変数エントリの多くは、関心を引く照合につながらないため、示されていない。結合操作は、第１エントリと第２エントリを、この両方のエントリがｄｅｌｅｔｉｏｎ＿ｖａｒの同一の値を有する場合、ペアにする。オリジナルトークンのもたらされる変数ペアは、以下のとおりである。すなわち、

【0128】

【表3】

【0129】

前掲の例示的な変数照合は、それぞれ、トークン０−削除、代入、入れ換え、異なるパスによって得られた入れ換え、離隔した挿入及び削除、及びトークン０−挿入（又はトークン１−削除）である。変数照合を表すアーカイブの中のトークンの各ペアは、照合の品質を示す関連付けられる類似性スコアを有する。

【0130】

前述した採点を使用して、これらのペアに関する類似性スコアは、以下のとおりである。すなわち、

【0131】

【表4】

【0132】

これらの事例において、類似性スコアは、事実上、変数ペアの間の編集距離に対応する。単一の文字削除に基づく削除−結合手順が、すべての編集距離１変数ペア（挿入、削除、及び代入）、及びいくつかの編集距離２変数ペア（入れ換え）を見出す。離隔した挿入−削除に関するスコアは、ｄｅｌｅｔｉｏｎ＿ｐｏｓが２つ以上、離隔していたため、追加のペナルティによってカスタマイズされている。

【0133】

ペアに関して類似性スコアを計算した後、類似性スコアに閾値を適用すること、又はペアリングの性質に条件を適用することによって照合判定が行われる。例えば、この場合、類似性スコアに基づく規則は、類似性スコアが２以下である場合、変数ペアリングが変数照合を表すことであることが可能であり、その結果、離隔した挿入−削除ペアリング「ＬＯＮＤＯＮ ＬＯＤＯＯＮ」が変数照合として識別されることから除外される。

【0134】

ペアリングの性質に条件を適用することの例として、そのペアリングに挿入、削除、代入が関与しているかどうか、又は変更された文字が最初の文字又は最後の文字であったか、あるいはｄｅｌｅｔｉｏｎ＿ｐｏｓの位置が２つ以上、離隔していたかどうかの情報を符号化する、照合コードと呼ばれるコードが、構築されることが可能である。一部の実施例において、そのような照合コードは、ビット、又はビットの組み合わせが、識別された各条件に関して設定されたビットマップとして構築されることが可能である一方で、他の実施例において、そのような照合コードは、各条件を符号化するサブストリングの連結からなるストリング、又は、場合により、単に、情報を保持するレコード構造である。照合コードは、特定の重みを割り当てることも、実際のスコアを計算する関数を定義することもせずに、類似性スコアに寄与する可能性がある情報を符号化するデータパターンコードである。このことは、スコアを計算するステップを経る必要なしに、照合が照合コードに直接に適用されることを許容する、又は認めない一般的な条件を明らかにする。例えば、この場合、変数照合は、照合コードによって示される離隔した挿入−削除を有さない任意の変数ペアリングであることが可能である。

【0135】

２．２ 変数−検索
変数−検索動作が、候補検索エンジン１４０の一部の実施例の動作の基礎をなす。図２Ａ〜図２Ｄは、変数−検索動作の例を示す。図２Ａを参照すると、生のクエリ２００が処理のために読み取られる。この例において、生のクエリ２００は、値「８２５３６」を有する、政府ｉｄなどの数値フィールドである。要件は、データセット２２０の中で政府ｉｄと照合する変数を見出すことであり、政府ｉｄは、最大で１つの代入だけ生のクエリと異なる。このことは、照合する２つの政府ｉｄが１以下のハミング距離を有することを要求するのと均等である。ハミング距離は、等しい長さの整列された２つの文字シーケンス（ときとして、長さの差を足すことによって、等しくない長さの整列されたシーケンスにまで拡張される）の間の照合しない文字の数をカウントする。

【0136】

データセット２２０は、ディスク上に保持される基準データセット、又は、例えば、メモリ内の結合操作中にメモリの中に保持される一時データセットであることが可能である。

【0137】

削除−結合手順の最初のステップは、クエリ展開手順として、生のクエリ２００に適用されて、展開されたクエリ２１０と呼ばれる削除セットが生成される（２０５）。展開されたクエリ２１０は、２つの値、すなわち、ｄｅｌｅｔｉｏｎ＿ｐｏｓの値（「ｄｅｌ＿ｐｏｓ」というラベルが付けられた見出しの下の）、及びｄｅｌｅｔｉｏｎ＿ｖａｒトークン（「ｄｅｌ＿ｖａｒ」というラベルが付けられた見出しの下の）をそれぞれが含むエントリを含む。同様に、検索−エントリ展開手順が、データセット２２０の中の各エントリに適用されて、削除セット２２５が生成され、次に、削除セット２２５が検索ストア２３０に書き込まれる。

【0138】

図２Ｂを参照すると、展開されたクエリ２１０の中の各エントリが、検索ストア２３０の中で探されて、照合するエントリ２３２が見出される。次に、照合するエントリ２３２の中のキー２３５が、データセット２２０の中で探されて（２３７）、さらなる処理のためにデータセットレコードが取り出される。データセット２２０の中の照合するレコードのコレクションはすべて、ｉｄフィールドが、生のクエリｉｄ２００に対して１以下のハミング距離を有するという要件を満たす変数照合である。この例において、生のクエリｉｄ「８２５３６」は、「８２４３６」と「８２５３８」の両方に対してハミング距離１照合であるが、「８５２３６」（ハミング距離２）に対してはそうではない。

【0139】

図２Ｃを参照すると、ｉｄに対する照合要件が、削除−結合１照合を許容するように緩和される。前述したとおり、このことは、すべての編集距離１照合、並びに入れ換え及び離隔した挿入−削除を含む。生のクエリ２００及びデータセット２２０は、前の場合と同様であり、展開されたクエリ２１０と検索ストア２３０がともに、前の場合と同様に、生のクエリ２００、及びデータセット２２０の中の各ｉｄから削除セットを形成することによって構築される。この例において、展開されたクエリからのルックアップは、ｄｅｌ＿ｖａｒだけを使用する。このことは、前の両方のハミング距離１照合を見出し、さらに新たな照合２３６も見出す。照合エントリ２３６の中のキー２３７が、データセット２２０の中で探されて（２３８）、さらなる処理のためにデータセットレコードが取り出される。この例において、生のクエリｉｄ「８２５３６」は、入れ換えを伴う、データセットｉｄ「８５２３６」に対する削除−結合１照合である。

【0140】

図２Ｄは、一般的な例を図示する。生のクエリ２００Ｇが、クエリ展開２０５Ｇを経て、展開されたクエリ２１０Ｇを与える。クエリ展開２０５Ｇが、１又は２以上の検索キー、及び、場合によっては、オリジナルの生のクエリ、又は生のクエリが導き出されたクエリレコードからのさらなる情報からなる２又は３以上のエントリを生成する。データセット２２０Ｇの中の各エントリが、検索−エントリ展開手順によって、検索ストア２３０Ｇの中の２又は３以上のエントリに展開される（２２５Ｇ）。検索−エントリ展開２２５Ｇは、１又は２以上の検索キー、及び、場合によっては、データセットレコードからのさらなる情報からなる２又は３以上のエントリを生成する。検索−エントリ展開２２５Ｇは、データセット２２０の中に重複キーが存在し得るので、必ずしも、データセット２２０Ｇの中の各エントリに関して別々の検索−エントリを生成するとは限らない。検索−エントリ展開手順２２５Ｇは、必ずしも、クエリ展開手順２０５Ｇと同一の展開手順であるとは限らない。

【0141】

それぞれの展開されたクエリ検索キー２３１Ｇが、検索ストア２３０Ｇの中で変数−ルックアップ手順２３２Ｇを使用して探されて、照合するエントリ２３３Ｇが見出される。ルックアップ手順２３２Ｇは、クエリ検索キー２３１Ｇに対して計算を実行することが可能であり、したがって、必ずしも、検索−エントリ検索キー２３３Ｇと同一であるとは限らない。次に、照合された検索−エントリ検索キー２３３Ｇに対応するデータセットキー２３５Ｇが、データセット２２０Ｇの中でデータセットキー２３５Ｇを有するすべてのレコードを探して（２３６Ｇ）、取り出すのに使用される。

【0142】

２．３ 変数ネットワーク解析
２．３．１ 変数近隣
変数近隣は、同義語、省略形、文化的変数などの、外部データ１０６によって指定される変数ペアリングを場合により、含む、変数ペアリング（変数関係とも呼ばれる）のシーケンスによって関係するトークンのセットである。１つの実施例において、変数プロファイラ１１０が、多くとも１つの挿入及び１つの削除だけ異なるタイプ入力上の変数を検出し、識別するように削除−結合手順を使用してクラスタ化されるようにデータソース１００をプロファイリングする。このことは、単一の挿入、単一の削除、及び単一の代入、並びに入れ換え及び離隔した挿入／削除を範囲に含む（例えば、「ｈｅｌｌｏ」と「ｈｌｌｉｏ」は、削除−結合１変数である）。変数プロファイラストア１１５の中で、すべてのトークンは、より多くのレコードが処理されるにつれてオンラインで更新され得る１又は２以上の変数の関連付けられるリストを有する。しかし、すべての変数は、その変数自らの変数を有するトークンでもある。削除−結合手順、又は他の類似性測定によって形成された変数ペアリングのシーケンスを追うことによって得られるトークンのセットが、近隣を規定する。このセットの閉包は、閉包近隣と呼ばれ、トークンがノードであり、変数ペアリングがエッジであるグラフの変数ネットワークにおける接続された構成要素を形成する。類似性変数ペアを、外部データ１０６又はユーザによって供給された入力、例えば、同義語、代替のつづり、文化的変数などから得られる変数トークンペアで補足することが、関係するトークンのより大きい近隣につながる。

【0143】

図３Ａで、変数アーカイブ３００が、データレコードセットの中で出現するトークンのリストを包含し、各トークン（「ｔｏｋｅｎ」というラベルが付けられた）が、そのトークンがデータセットのフィールド（又はコンテキスト）の中で出現する回数の関連付けられるカウント（「ｃｏｕｎｔ」というラベルが付けられた）（例えば、そのトークンがフィールドの中で出現するレコードの数）、並びにそのトークンの変数トークンそれぞれのリスト（「ｖａｒｉａｎｔ」というラベルが付けられた）、及びそれらの変数トークンがデータセットの同一のフィールド（又はコンテキスト）の中で出現する回数（「ｖａｒｉａｎｔ＿ｃｏｕｎｔ」というラベルが付けられた）を有する。変数アーカイブ３００のコンテンツに対応する変数近隣ネットワーク図３１０が、すべてのトークンをノードとしてとり、すべてのトークンをそのトークンの変数それぞれと接続することによって構築され得る。各ノードはそのカウントに関連付けられる。一部の実施例において、より大きいカウントを有するトークンが表示上でより上にあるように（例えば、「ｃｏｕｎｔ」というラベルが付けられた垂直軸により）ノードを配置することが、一般的な語と稀な語が容易に区別されることを可能にする有用な図示をもたらす。変数近隣ネットワークの接続された構成要素は、有向非巡回グラフであり、その接続されたセットの中のトークンに関する類似性関係の推移閉包である。データセットに関する完全なネットワーク図は、この種類の接続されていない多くのグラフを含み得る。

【0144】

２．３．２ トークン代表
トークン代表は、接続された近隣の選択されたトークンである。一部の実施例において、近隣におけるすべてのトークンが、その近隣を代表するトークンによって置き換えられることが可能である。このことは、トークン代表の検索が、その近隣における任意の変数に関連付けられるすべてのレコードを返すという効果を有する。このことは、変数を対象に繰り返される変数検索中の作業負荷を低減するので、望ましい。単純な変数検索は、各トークンを検索し、その後、そのトークンの変数それぞれを検索することである。変数を対象とした繰り返しは、トークンに遭遇するたびに行われる必要がある。近隣におけるすべての変数トークンがトークン代表で置き換えられた場合、変数トークンのいずれかに遭遇するたびに、すべての変数照合を返すのにトークン代表を１回、探すだけで十分である。

【0145】

さらに、変数トークンの近隣を扱うことが、変数検索への推移性の測度を供給することが可能である。変数−ペア関係は、ＢがＡとの変数−ペアリングであり、ＣがＢとの変数−ペアリングである場合、Ｃは、必ずしもＡとの変数−ペアリングではないため、推移的ではない。例えば、削除−結合１変数ペアリングを考慮されたい。トークン「ｃｈｉｃａｇｏ」は、「ｃｈｉｃａｇｏ＃」の変数であり、「ｃｈｉｃａｇ０」は、「ｃｈｉｃａｇｏ」の変数であるが、「ｃｈｉｃａｇ０」は、「ｃｈｉｃａｇｏ＃」の削除−結合１変数ではない。

【0146】

しかし、変数検索に関して、Ａで検索を行った際に見出されるレコードのセット、又はＢで検索を行った際に見出されるレコードのセットが同一であることが望ましい。このことは、ＡがＢの稀な変数である場合、Ａによって意図される「実際の」トークンに関連付けられるレコードのより多くが、Ｂで検索することによって見出されるレコードであるためである。例えば、「ｃｈｉｃａｇｏ＃」、及び「ｃｈｉｃａｇｏ＃」の削除−結合１変数で検索することは、「ｃｈｉｃａｇｏ」照合を見出すが、「ｃｈｉｃａｇ０」のような「ｃｈｉｃａｇｏ」の他の照合を逃す。

【0147】

変数−ペアリングは、推移的ではないので、より高い推移性を実現するには、Ａ又はＢで検索を行う際に含められるトークンの近隣を拡大することしかない。その場合、近隣に関するトークン代表で検索することが、その近隣内のすべてのトークンが同一のレコードを返すことを確実にする。もちろん、この検索は、個々のトークンのローカル近隣を超えて展開されているので、取り出されるトークンの一部のペアは、それらのトークンがあまりにも類似していないため、照合しない可能性がある。このことは、関連付けられるレコードが依然として、他のフィールドからの強力な採点に基づいて照合し得るため、許容可能である。そのような照合は、検索によって適切な候補が返されなかったとすると、見出され得ないことになる。

【0148】

閉包近隣は、選ばれたトークンに関する変数関係の推移閉包によって見出される近隣であり、つまり、変数ペアリングの連鎖によって到達され得るすべてのトークンのセットである。閉包近隣におけるいずれのトークンも、そのトークンが、その近隣におけるすべてのトークンに関するトークン代表として使用される限り、トークン代表として選ばれ得る。しかし、閉包近隣は、データセットがより大きく、より多様になるにつれ、さもなければ接続されていない閉包近隣の間のギャップを埋めるより多くの変数が現れて、それらの閉包近隣を合体させるため、使用不能に大きく成長する可能性がある。このことにより、他の種類の近隣に注目することが重要になる。

【0149】

一部の実施例において、トークン代表は、より大きいカウントを有する変数を有さないトークンである。図３Ａにおいて、正規の近隣３２０が、トークン代表から始めて、１つのトークンを等しいカウント、又はより小さいカウントの別のトークンに接続する結び付きを追うことによって到達され得るすべてのトークンを含む。トークンは、２つ以上の正規の近隣に属することが可能である。そのトークンは、正規の近隣の代表トークンである。

【0150】

図３Ｂに図示される一実施例において、トークン代表及び正規の近隣が、カウントの大きい順に変数アーカイブ３００をまず並べ替え、さらにｖａｒｉａｎｔ＿ｃｏｕｎｔ＜ｃｏｕｎｔであるすべての変数を破棄して、剪定された変数アーカイブ３３０を得ることによって、計算され得る。変数を全く有さないエントリは、トークン代表であり、トークン−代表ベクトルストア３４０に即時に追加される。並べ替えられた変数アーカイブの中のレコードが処理されるにつれ、各トークンが、トークン、及びそのトークン自体からなるトークンベクトルとしてトークン−代表ベクトルに書き込まれる。それぞれの非トークン代表に関して、その非トークン代表の変数それぞれに関連付けられるトークン−代表ベクトルが、トークンファイルの中で探される（３４２）。これらのトークンベクトルの合併が計算されて、個別のトークン−代表のセットが見出され（３４４）、もたらされたトークン−代表ベクトルが、トークンと一緒にトークンファイルに書き込まれる（３４６）。

【0151】

別の実施例において、トークン代表は、何らかのトークン閾値より大きいカウントを有するすべてのトークンとして識別されることが可能であり、それらのトークンが、語幹抽出（例えば、複数形）によって関係する場合を例外とし、語幹抽出によって関係する場合、語幹関連のトークンは、同一の正規の近隣における変数として保持されることが可能であり、最大のカウントを有する語幹関連のトークンがトークン代表である。このことは、一般的なトークンの間の結び付きを断つ役割をし、正規の近隣のサイズを小さくする。トークン及び正規の近隣を見出すのに、前のアルゴリズムが、各トークンがトークン閾値を超えるカウントを有するトークンのすべてのペアリングに関して、変数ペアリングが断たれ、さらに以前にペアにされたトークンが、トークン代表として、すなわち、より大きいカウントの変数を全く有さないトークンとしてトークン−ベクトルファイルに追加されるという変更を伴って適用されることが可能である。

【0152】

この実施例の変数が、指定された辞書、又は指定されたトークンリストに属するすべてのトークンをトークン代表と定義することである（やはり、語幹関連のトークンについての注意を伴って）。その場合、トークンは、一般的でなくてもよく、トークンは、単に、何らかの権限によって別々のトークンとして認識されるだけでよい。

【0153】

一部の実施例において、同義語、省略形、文化的変数などの、外部データ１０６に基づいてペアにされた変数トークンは、それらの変数トークンがペアにされたトークンと同一の正規の近隣のメンバと見なされることが可能であり、ただし、それらの変数トークンをその正規の近隣から除外できることが貴重である状況が存在する（事実上、そのペアリングをオフにして）。トークンに、それらのトークンの出所でラベルを付けること、例えば、外部データ１０６から、又は変数プロファイラ１１０において使用された特定の類似性測定からというラベルを付けることが、任意のソースからのペアにされた変数トークンの扱いを管理する有効な手段をもたらす。

【0154】

２．４ セグメント化
図１Ｂの例において、データソース１００から、又はトークン化されたレコード１１８から読み取られたデータレコードが、処理のためにクラスタ化エンジン１３０に供給される。一部の実施例において、データレコードは、セグメント化エンジン１３２に送信されることが可能である。セグメント化エンジンが、セグメント値と呼ばれる値に基づいて、データレコードにセグメント識別子を割り当てる。次に、レコードが、それらのセグメント識別子に基づいて並列パーティショナ１３４によって分割されて、様々な受信側処理エンティティに送信されることが可能であり、ただし、同一のセグメント識別子を有するすべてのレコードは、同一の処理エンティティに送信される。処理エンティティは、例えば、ＣＰＵ（例えば、マルチコアプロセッサにおけるコア）若しくはコンピュータなど処理ノード、又はＣＰＵ上で実行される計算プロセス若しくは計算スレッドを含むことが可能である。

【0155】

一部の実施例において、セグメント値は、オリジナルレコード１００若しくはトークン化されたレコード１１８、及び／又はランタイムに供給される情報（例えば、データを処理するデータセンタのロケーション、又はデータセットの名前）に適用された、場合により、ユーザによって指定された規則セットの中で定義された関数を使用する、ユーザによって指定された式から導き出されることが可能である。同一のセグメント値を有するレコードは、同一のセグメント識別子を受ける（それらのセグメント値が、同一の式を使用して導き出される場合）が、異なるセグメント値を有するレコードは、セグメント化スキームに依存して、異なるセグメント識別子を受けることが可能であり、又は同一のセグメント識別子を受けることも可能である。例えば、セグメント値は、データレコードの出所の国を表すことが可能である（このことは、例えば、レコードを処理するデータセンタのロケーションに基づいて暗黙であることも、レコードの中のフィールドとして明示的であることも可能である）。一部の実施例において、戦略識別子が、セグメント識別子のセットを区別するのに使用される。例えば、データレコードの出所の国が、１つの戦略識別子を有することが可能である一方で、レコードの中で名前を指定された個人の出生国は、異なる戦略識別子を有することが可能である。このことは、セグメント値とセグメント識別子が、セグメント値とセグメント識別子の間の対応が保たれることが要求されることなしに、重なり合う範囲にわたることを許容する。

【0156】

セグメント化の１つの用途は、照合を見つけるように比較されなければならない（クラスタ化中に、又は他の照合動作中に）レコードの数を減らすように、レコードのより大きいセットから単一のセグメントのレコードを分離することであり、すなわち、厳密に照合するセグメント識別子（及び存在する場合、厳密に照合する戦略識別子）を有するレコードだけが、照合のための候補である。この例において、セグメント化の後に、クラスタ化アルゴリズムの並列化のためにレコードのセグメントを複数の処理エンティティに分割することが行われる。本明細書で説明されるクラスタ化アルゴリズムは、セグメント化に基づくクラスタ化アルゴリズムの並列実行にパフォーマンス上の利益があるため、セグメント化中に、レコードの数が増やされることを許容することが可能である。その結果、セグメント識別子（すなわち、同一のセグメント）を共有するレコードのセットは、レコードを分離するためにセグメント化が使用される場合と比べて、はるかに大きいことが可能である。パフォーマンス上の利益を実現するのに、別々のセグメント値の数は、分割後に処理エンティティの間でほぼバランスのとれた配分を与えるのに十分な大きさであるだけでよい。バランスのとれた配分は、一部の並列処理システムに関して、他の並列処理システムの場合と比べて、より不可欠であり得る。また、配分のいくつかの種類の偏り（一部の処理エンティティに、他の処理エンティティと比べて、より多くのレコードが割り当てられている）は、過分割によって、すなわち、処理エンティティ数よりずっと多くの分割を使用することで対処され得る。過分割では、各処理ノードは、パーティションが大きく異なるサイズのものである場合でさえ、類似した量の作業を受け取る可能性が高い。また、パーティショナが、おおよそで照合された１又は２以上のフィールド（又はそのようなフィールドに適用されたハッシュ関数）、及び厳密に照合された１又は２以上のフィールドからなるマルチパートキーによって分割を行って、潜在的な偏りを小さくすることも可能である。

【0157】

一部の実施例において、セグメント値の選択は、クラスタメンバシップ基準の一部を形成する厳密な基準に基づく。例えば、口座レコードをクラスタ化する際、個人身元フィールドに加えて、銀行は、特定のタイプの口座に関するレコードのクラスタに関心がある可能性がある。詳細には、当座預金口座（例えば、チェッキングアカウント）に関するレコードが一緒にクラスタ化されることが可能である一方で、普通預金口座に関するレコードが別々にクラスタ化されることが可能である。この種類のセグメント化は、ときとして、暗黙であり、つまり、当座預金口座レコードと普通預金口座レコードは、異なるソースに由来することが可能であり、既に分離されている。場合によっては、データレコードの中に、セグメント値として使用され得るが、口座の性質を正確に報告するものと信頼されなければならない口座タイプ識別子が存在することが可能である。

【0158】

一部の実施例において、裏付ける確認が、セグメント化の時点で、又は後にメンバシップ判定中に行われて、セグメント値が忠実であることが検証される。例えば、普通預金口座の口座番号が、特定のセットの可能性からの数字で常に始まることが可能である。このセットがランタイムに知られている場合、口座が本当に普通預金口座であるかどうかが、セグメント化より前に確認され得る。このセットが存在することが知られているが、有効な値は知られていない場合、頭に付けられた数字が、クラスタメンバシップ基準の一部とされることが可能であり、又は、実際、セグメント値の一部とされることが可能であり、クラスタの中に存在する口座番号の間の整合性が、クラスタメンバシップ判定の一環として確立されることが可能である。

【0159】

レコードが、特定のクラスタのメンバであると判定された後、そのレコードは、その特定のクラスタを識別するｃｌｕｓｔｅｒ＿ｉｄを含むように拡張されることが可能である。一部の実施例において、セグメント値（又は、ときとして、セグメント識別子自体）は、前のクラスタ化からのｃｌｕｓｔｅｒ＿ｉｄに設定されることが可能である。このことは、階層クラスタ化を可能にする。例えば、データレコードが最初に名前別にクラスタ化されていた場合、類似した名前を共有するが、別々の政府によって割り当てられた識別子を有するレコードをクラスタを見つけ出す政府によって割り当てられた識別子別のその後のクラスタ化が、名前ｃｌｕｓｔｅｒ＿ｉｄをセグメント値として使用することも可能である。類似していない名前を有するレコードは、同一のクラスタのメンバではあり得ないため、比較されなくてもよい。

【0160】

一部の実施例において、データレコードは、複数の処理エンティティにわたってセグメント識別子でハッシュ分割されることが可能であり、したがって、共通のセグメント識別子を有するすべてのレコードは、単一の処理エンティティの中に一緒に入れられる。このことは、セグメント間の通信が要求されないため、並列処理を可能にする。

【0161】

２．４．１ レプリケートされたセグメント化を介する並列化
データソースの互いに素なセグメント化が存在しない状態での並列化が、データソース１００をレプリケートすること、及び任意の２つの変数ペアレコードが少なくとも１つのセグメント値を共有しなければならないことを確実にするセグメント化の適切な選択を使用することによって実現され得る。セグメント値は、フィールド値又はフィールド値の組み合わせの１又は２以上の断片から構成され得る。セグメント値のセットは、少なくとも１つのセグメント値が、２つのレコードの間の許されるすべての変数に関して２つのレコードによって共有される場合、網羅的であると言われる。図４で、網羅的なレプリケートされたセグメント化のプロセスが図示される。データソース４００が読み取られ、すべてのデータレコード４０１に一意のレコードキーが、そのようなレコードキーが既に存在するのでない場合、割り当てられる。すべてのデータレコードが、十分な回数、レプリケートされて、網羅的なセットのセグメント値からの各セグメント値が、１つのレプリカントデータレコードに割り当てられる（４０２）。（レプリケートされるレコードの数は、各レコードの中のデータに依存することが可能である。）もたらされたデータレコードが、レプリカントに関連付けられるセグメント値で分割される（４０４）。レプリカントの結び付けられたペアのセットに関して各処理エンティティにおいて代理クラスタキーが生成される（４０６）。構造上、許容可能なすべての変数は、セグメントキーが網羅的であるため、何らかのセグメントキーのパーティションの中で検出されることになる。クラスタキーのスーパーセットは、複数照合調整手順の後に、各クラスタに関する一意のｃｌｕｓｔｅｒ＿ｋｅｙに解決される（４０８）。

【0162】

多くとも１つの代入だけ異なり得る２つの政府ｉｄを照合させる事例を考慮されたい。セグメント値の網羅的なセットがまず、政府ｉｄにおける奇数位置からの数字（又は、より一般的には、文字）をとり、その後、偶数位置から数字（又は、より一般的には、文字）をとることによって与えられる。このセットが網羅的であることは、いずれの単一の文字代入も、奇数位置であるか、偶数位置でなければならず、奇数位置と偶数位置の両方ではないため、容易に見て取れる。このため、他方のタイプのセグメント値は、単一の代入だけ異なって、２つのレコードに関して合致しなければならない。例えば、１２３４５６が、セグメントキー（１３５，２４６）を有し、１２４４５６が、セグメントキー（１４６，２４６）を有する。これらのセグメントキーは、第１セグメント値で異なるが、第２セグメント値で合致する。

【0163】

図５Ａ〜図５Ｃは、この事例における全体的なプロセスを図示する。図５Ａにおいて、データレコード７００が読み取られる。第１レコード５０１は、数値ｉｄ「１２３４５６」と、一意のレコードキー「ｒ１」とを有する。これらのレコードが、２回、レプリケートされ（５０２）、奇数位置からの文字、例えば、「１３５」からなるセグメントキー、及び偶数位置からの文字、例えば、「２４６」からなるセグメントキーが割り当てられる（５０３）。データが、セグメントキー値で分割される（５０４）。同一のセグメントキーを有するレコードは、同一のパーティションの中に入るが、同一のレコードキーを有するレコードは、同一のパーティションの中に入らなくてもよい（５０６）。例えば、セグメントキー値「１３５」は、第１パーティションの中にあるが、レコードキー「ｒ１」を有するレコードは、第１パーティションと第２パーティションの両方の中に出現することに留意されたい。

【0164】

図５Ｂにおいて、レコード５０６が、それらのレコードのパーティション５０８内でクラスタ化され、クラスタキーが割り当てられて、データクラスタ５１０がもたらされる。いくつかのレコードキーは、複数のクラスタに割り当てられることに留意されたい。例えば、レコードキー「ｒ１」を有するレコードは、クラスタ「ｋ１」とクラスタ「ｋ２」の両方の中に出現する。

【0165】

図５Ｃにおいて、この複数照合が調整される。データクラスタ５１０が読み取られ、クラスタキーの複数割り当てが解決され（５２０）、レコードに対するクラスタキーの最終的割り当てが行われる（５３０）。この解決の詳細は、後段で説明される。

【0166】

２．４．２ セグメント化なしの並列化
代替キー生成は、生成された値を、１又は２以上のフィールドから構成される自然キーの値とペアにすることである。自然キーそれぞれの個別の値は、一意の代替キー値を有する。代替キーを生成するための一方法は、ときとして、キー相互参照ファイル（略して、キーｘｒｅｆストア）と呼ばれる代替キー／自然キーペアのストアを保持することである。それぞれの新たなデータレコードが処理されるにつれ、自然キー値がこのストアの中で探され、自然キー値が見つかった場合、代替キーが返され、自然キー値が見つからなかった場合、新たな代替キーが生成される。キーｘｒｅｆストアは、現在の実行において生成された代替キーのレコードを保持するようにメモリの中で部分的に作成されることが可能であり、以前に生成された値を保持するようにディスク上に部分的に着地させられ（さらに処理の開始時にメモリに読み込まれる）ことが可能である。キーが生成された後、新たに生成された代替キーを含むキーペアが、着地させられたキーｘｒｅｆストアに追加される。ときとして、生成された最大の代替キー値は、便宜上、別に格納されて、次の実行時に、前に生成された最高のキーが、重複なしにさらなるキーを生成するための開始点として利用可能であるようにする。

【0167】

このキー生成方法を並列に適用するのに、データレコードが、自然キーで、又は分割キーと呼ばれる自然キーの何らかの断片で分割されて、その分割キーの値を共有するすべてのデータレコードが同一の処理エンティティに送信されるようにすることが可能である。このことは、自然キーを共有するすべてのレコードが、同一の処理エンティティによって扱われることを確実にする。詳細には、新たに生成されたキーの最近のメモリ内ストアに対する処理エンティティによるアクセスが可能であり、したがって、同一の自然キーを有するすべてのレコードが、同一の代替キー値を得る。何も共有しない並列アーキテクチャすなわち、プロセス間通信の全くない並列アーキテクチャにおいて、新たに生成されたキーのストアは、現在の処理エンティティによって扱われるレコードにだけ利用可能であり、したがって、同一の自然キーを有するレコードが、同一の並列実行中に異なるプロセスエンティティにおいて扱われるとした場合、それらのレコードは、異なる代替キーを得ることになる。

【0168】

一部の状況において、自然キー値の配分は、或る値を有するレコードが、他の値を有するレコードの平均数と比べて、ずっと多く存在して、不均等である可能性がある。この事例において、自然キーで分割することは（断片で分割することさえ）、データパーティションにわたるデータの偏りにつながる可能性があり、つまり、いくつかのパーティションが、他のパーティションと比べて、ずっと多くのレコードを包含することになる。このことは、処理時間が、等しい複雑度のタスク（代替キー生成のような）に関してデータ量に比例するため、並列化の効率を低下させる。この事例において、一様なデータ配分を得るようにラウンドロビン（単に、プロセスそれぞれにレコードを次々に送る）で分割してみる価値があり得る。その場合、代替キーは、前述した方法によって各プロセス内で生成されることが可能であり、代替キー生成が完了した後、同一の自然キーに対するもたらされる複数代替キー割り当てが、後処理ステップにおいて重複排除され得る。この重複排除を実行する一方法が、各パーティションの中のレコードを自然キーにロールアップして、そのパーティション内で代替キー／自然キーペアを見つけ出し、その後、その自然キーで再分割することである（今度は、その自然キーのいくつかのパーティションコピーだけが存在する）。その自然キーに対する第２ロールアップが、生成された複数の代替キーの１つ、例えば、各自然キーに関して最小の代替キーを選択することが可能である。最後に、（オリジナルのラウンドロビン分割における）レコードに対する第２走査で、それらの代替キーが選択された単一の値に更新され得る。データを２回走査することが要求されるにもかかわらず、このことは、偏りを伴った生成と比べて、よりパフォーマンスが高いことが可能である。（操作の異なる順序が関与する、大きいキーグループを扱う他の方法が存在し、例えば、自然キーを重複排除するように二重ロールアップを実行してから、代替キーを生成すること、又は他の何らかの方法を適用して、大きいキーグループを検出して、別個の処理に回すことも可能である。）

【0169】

自然キーで分割することが、並列化に関して効果的でない戦略な可能性がある第２状況は、代替キーが、必ずしも、厳密に照合する自然キーに関してではなく、おおよその（又は均等の）照合する自然キーに関して生成される場合である。この事例において、照合するすべての候補レコードを同一のプロセスに送信することが保証付きである分割キーは、存在しない可能性がある。（プロセスは、処理エンティティ内で実行される実行のインスタンスである。）このことは、照合判定は、通常、レコードの比較を含み、レコード内のデータのみに基づいて行われ得ないためである。前段で説明したマルチパスソリューションは、この事例では、重複排除プロセスが、複数の代替キーが割り当てられている場合を識別するのに自然キーに依拠するため、効果的でない。パーティションにわたって、いずれのレコードがおおよそ照合する自然キーを包含するかを識別することは、元の問題と均等である。

【0170】

両方の状況に対するソリューションが、代替キー生成の以下の例によって説明される。前述したメモリ内ストアとは異なるキーｘｒｅｆストアの異なる実施例が、最近に生成された代替キーに関して使用されることが可能である。以下の特徴を有するストアが利用可能である。すなわち、１）これらのストアは、ディスク上に保持され、１つのプロセスによって更新され得る（後尾に追加することによって）、２）これらのストアは、複数のプロセスから読み取られることが可能である（さらに、変更が行われるにつれ、更新されることが可能である）。代替キー生成手順は、以下のとおりである。パーティショナが、例えば、ラウンドロビンで、プロセスにわたる均等な配分を得るようにデータを分割する。各パーティション内で、プロセスは、各自然キーをとり、すべてのパーティションに関してキーｘｒｅｆストアに照らしてルックアップを実行し、その自然キーが１又は２以上のキーｘｒｅｆストアの中で見つかった場合、プロセスは、最小の値を有する代替キーをとり（さらに、その自然キーが２つ以上のキーｘｒｅｆストアの中に出現したかどうかの印を付け）、いずれのキーｘｒｅｆストアの中でもその自然キーが見つからなかった場合、プロセスは、新たな代替キーを生成し、このパーティションに関連付けられるキーｘｒｅｆストアを更新する。新たな代替キーがプロセスにおいて生成されるにつれ、それらの代替キーは、そのプロセスに関する関連付けられるキーｘｒｅｆストアの中でディスクに保存される。このことにより、それらのキーのすべてが生成された後にキーｘｒｅｆストアを更新する必要性が取り除かれる。さらに、そのストアを読み取るすべてのプロセスが、変更が保存された後、その変更で更新されるので、１つのプロセスにおいて最初に出現する自然キーが別のプロセスにおいて後に出現した場合、その自然キーには、その他方のプロセスで最初に割り当てられたオリジナルの代替キーが割り当てられる。

【0171】

以下の潜在的な競合条件が存在する。すなわち、同一の自然キーを有する２つのレコードが異なるプロセスに同時に到着した場合、キーｘｒｅｆストアに照らしたルックアップは、いずれのプロセスにおいても照合を示さない可能性があり、その自然キーに関して、さらなる２つの新たな異なる代替キーが生成される。このことは、ローカルキーｘｒｅｆストアが新たな代替キーで更新される前に処理されるレコードに限って生じ、これらの更新が、その他のプロセスによって読み取られる。その後のすべての自然キーには、最小の値の代替キーが割り当てられる。後のこれらのレコードに、２つ以上の自然キーが見られたという事実でさらなる印を付けることによって、事後にキー衝突を訂正するのに使用され得るマーカが配置される。このマーカ上のフィルタが、２つ以上の代替キー割り当てを有していた自然キーを見つけ出し、その後、代替の代替キーが識別されて、置き換えられることが可能である。初期の衝突が生じた場合に限って自然キーが現れた場合、それでも衝突を見逃す可能性がある。このことを確実に検出し、訂正するのに、データ（したがって、自然キー）が再びキー生成プロセスにかけられて、割り当てが訂正されることが可能であり、つまり、２回目で、あいまいな割り当ては、明白となる。この２回目の修正は、それらの自然キーがおおよそであることしか要求されない場合でさえ、照合判定が決定論的である限り、つまり、同一のデータが再判定された場合に同一の判定をする場合、信頼できることに留意されたい。このことは、２回目の開始までには、すべてのローカルキーｘｒｅｆストアに、すべてのプロセスが書き込み及び読み取りを行っているため、うまくいく。

【0172】

この並列化方法は、クラスタ化に適用されることが可能であり、他のファジーデータ操作にも適用されることが可能である。クラスタ化は、キーが厳密ではなく、均等であるに過ぎない代替キー生成の形態であると見なされ得る。ローカルストアの詳細な形態は、データ操作により異なり得るが、類似した技法が使用されることが可能である。

【0173】

図６は、自然キーで分割することなしに並列で実行される代替キー生成手順の実施例を図示する。自然キー「ｎ１」を有するレコードが、データソース６００Ｐ１においてパーティションＰａｒｔｉｔｉｏｎ１の中で最初に出現する。パーティションＰａｒｔｉｔｉｏｎ１のキーｘｒｅｆストアＸｒｅｆ１ ６０４Ｐ１、及びパーティションＰａｒｔｉｔｉｏｎ２のキーｘｒｅｆストアＸｒｅｆ２ ６０４Ｐ２が調べられ、「ｎ１」が見つからず（６０６）、したがって、代替キー「ｓ１」が生成されて、出力６２０Ｐ１に書き込まれる。その一方で、キーｘｒｅｆレコード「ｎ１ ｓ１」が、ローカルキーｘｒｅｆストアＸｒｅｆ１ ６０４Ｐ１に保存される（６０８）。後に、自然キー「ｎ１」を有するレコードが、データソース６００Ｐ２においてパーティションＰａｒｔｉｔｉｏｎ２の中で出現する（データが自然キーで分割されていたとしたら、そうなっていたであろうＰａｒｔｉｔｉｏｎ１の中にではなく）。やはりキーｘｒｅｆストアＸｒｅｆ１ ６０４Ｐ１及びＸｒｅｆ２ ６０４Ｐ２が調べられ、「ｎ１」は、Ｘｒｅｆ２ ６０４Ｐ２の中にないが、Ｘｒｅｆ１ ６０４Ｐ１の中で見出される（６１０）。代替キー「ｓ１」が、取り出され、レコード６１１に割り当てられ、さらに出力６２０Ｐ２に書き込まれる。

【0174】

２．５ 採点フィールド重複排除
セグメント化（及び並列化）の後、一部の実施例において、データソース１００、又はトークン化されたデータレコードのセット１１８Ｐからのレコードが、採点フィールド重複排除エンジン１４４に送られる。一部の実施例において、前述したとおり、クラスタメンバシップを判定する採点の際に使用されるフィールド、いわゆる採点フィールドが、ランタイムに特定されることが可能である。採点フィールド重複排除エンジン１４４が、採点フィールド上で同一の値を有するレコードのセットから１つのレコードを選択して、クラスタ化プロセスを続け、もたらされるクラスタｉｄが、そのセットの中のその他のレコードの間で共有されるようにする。これらのレコードは、クラスタメンバシップ判定プロセスの見地から同一であるので、これらのレコードのすべてに関して同一のクラスタ化判定に必然的に到達しなければならない。

【0175】

２．６ 候補検索
２．６．１ ２つのモード
データセットの中のレコードのすべてが一緒に処理されるか、又はレコードが、到着するにつれ、それまでにクラスタ化されたレコードに照らして処理されるかに依存して、検索ベースのクラスタ化プロセスのわずかに異なる２つのアプローチが可能である。そのようなレコードのすべてが一緒に処理されることは、バッチモードを説明するのに対して、レコードが、到着するにつれてそのように処理されることは、オンラインモードとして使用され得るインクリメンタルモードであるが、データのすべてが最初から利用可能である場合に適用されることも可能である。この２つのモードの間の１つの違いは、バッチモードでクラスタ化エンジンによって使用される、変数プロファイラストア１１５、変数ネットワークストア１２６及び検索ストア１４６を含む様々なストアが、前処理ステップ中に計算されるのに対して、インクリメンタルモードでは、一部のストアは、データが到着するにつれインクリメンタルで入力され得ることである。詳細には、１つのインクリメンタルモードアプローチは、データの完全なセットで変数プロファイラストア１１５及び変数ネットワークストア１２６を事前計算することである一方で、検索ストア１４６は、インクリメンタルで入力される。インクリメンタルモードで、クラスタ化結果は、レコードが処理される順序に依存することが可能である。

【0176】

２．６．２ インクリメンタルモードにおけるクラスタ発見
インクリメンタルクラスタ化プロセスにおいて、クエリレコードと呼ばれる、入ってくるレコードが、既存のクラスタの中のレコードと比較されて、そのクエリレコードがいずれのクラスタに属すべきかが判定されることが可能である。直接のアプローチにおいて、各クエリレコードが、最も近い照合を見つけ出すようにそれまでのすべてのレコードと比較されることが可能である。近い照合が全く存在しない場合、クエリレコードは、新たなクラスタの最初のメンバであり、存在する場合、クエリレコードは、そのクエリレコードが最も近く照合したレコードを包含するクラスタに追加される。このことは、単純明快であるが、潜在的に計算リソースを大量に使用する。ほとんどの比較は、否定的な結論（「このクラスタではない」）をもたらし、最悪ケースは、そのクエリレコードが新たなクラスタのメンバである場合である。このアプローチは、各クラスタから代表的なメンバを選択し、そのクエリレコードをクラスタ代表と比較することによって改良され得る。このことは、レコードの変数類似性が少なくとも部分的に推移的であるという所見を活用し、つまり、クエリレコードがクラスタ代表と十分に類似していない場合、そのクエリレコードは、クラスタの他のいずれのメンバとも十分に類似している可能性は低い（それらのメンバはすべて、そのクラスタ代表と類似しているので）。

【0177】

変数類似性は、実際には推移的ではないため（「ＡがＢと類似する」と「ＢがＣと類似する」は、「ＡがＣと類似する」を暗示しない）、ときとして、候補閾値と呼ばれる、クラスタメンバシップを判定するのに適用されるのと比べてより低い類似性閾値が、クエリレコードをクラスタ代表と比較する際に適用されることが可能である。その意図は、クラスタのメンバに対するクエリレコードの予期される類似性に関して正確な下限を設けることである。この下限は、クエリレコードが属し得ないクラスタをうまく除外するが、クエリレコードがいずれのクラスタに属するかという疑問には答えない。その理由は、２つ以上のクラスタ代表が、クエリレコードに対して、その候補閾値を超える類似性スコアを有し得ることである。これらのクラスタ代表は、ひとまとめにして候補レコードと呼ばれる。候補レコードが識別された後、クエリレコードが、何らかの候補レコードに関連付けられる各クラスタのすべてのメンバと比較されて、クエリレコードが最も近い親近性を有するクラスタが見出されることが可能である。この親近性が照合閾値を超えている場合、クエリレコードは、対応するクラスタのメンバであり、超えていない場合、クエリレコードは、新たなクラスタに割り当てられる。候補レコードが見出された後、クラスタメンバシップ判定のパフォーマンスを向上させるステップが行われることが可能であり、一部のステップについて以下に説明する。

【0178】

クエリレコードをクラスタ代表と比較する改良を用いても、新たなクラスタを識別する事例は、依然として不良であり、つまり、新たなクラスタに属するクエリレコードは、そのクエリレコードが新規であることを確認するのに既存のすべてのクラスタの代表と比較されなければならない。クラスタの数が増加するにつれ、新たなクラスタを識別するのにかかる時間が増加し、新たなクラスタを認識するのに要求される比較の数が既存のクラスタの数に比例するため、クラスタ化プロセスは、遅くなる。計算上の課題は、各クエリレコードをすべてのクラスタ代表と比較することに優る、レコードをクラスタ化する方法を見出すことである。

【0179】

検索ベースのクラスタ化アプローチは、新たなクラスタを識別する最悪ケースを最良ケースに変えようと試みることによって、この課題に取り組むことである。単純化された形態で、このことは、既存のクラスタメンバ、又はそれらのクラスタメンバのクラスタ代表から入力された検索ストアに対して検索を実行することによって行われる。クエリレコードが、検索ストアの中で探される。クエリレコードが見つからなかった場合、そのクエリレコードは、新たなクラスタに属するはずである。このプロセスは、図１Ａ及び図１Ｃに示される候補検索エンジン１４０によって行われる。このアプローチは、検索ストア１４６を入力して、検索ストア１４６の中でクエリを探すのにかかる時間が、各クエリレコードを、クラスタ代表の増大するストアに照らしてすべてのクラスタ代表と直接に比較するのにかかる時間より少ない場合、有利である。このアプローチの裏の巧妙さは、検索ストア１４６を入力する検索−エントリ展開エンジン１４５、候補検索エンジン１４０のためにクエリを構築するクエリ展開エンジン１４３、及び検索を実行する検索エンジン１４７（又は変数−ルックアップ手順）を選択することを含め、候補検索エンジン１４０によって使用されるプロセスを定義することにある。

【0180】

図２Ｄが、このプロセスの実施例を示すのに使用され得る。一部の実施例において、検索ストア２３０Ｇが、クラスタメンバからなるデータセット２２０Ｇから計算されたエントリで入力される。検索ストア２３０Ｇに照らして、展開されたクエリエントリ２１０Ｇに変数−ルックアップ手順２３２Ｇを適用することが、クラスタメンバシップ基準の何らかの必要な構成要素のプロクシを計算するのに使用され得る。プロクシは、レコードが、そのプロクシに対して少なくとも最低限のスコアに達するのでない限りクラスタのメンバであり得ない場合、良好なプロクシである。この最低限のスコア（候補閾値）が、候補照合２３２Ｇを定義する。クエリがこの要求される最低限に達するクラスタレコード２３６Ｇが候補レコードである。

【0181】

プロクシスコアの例が、２つの個人名のような、２つの複数語フィールド（又はフィールドの組み合わせ）によって共有される語の数である。２つの名前を比較するのにクラスタメンバシップ判定において使用される採点アルゴリズムは、それぞれ名前における語のセット以外も考慮に入れることが可能であり、詳細には、語の順序、及び語の位置を考慮に入れることが可能である。しかし、２つの名前は、それらの名前が語を全く共通で有さない場合、照合する可能性がなく、それらの名前が、語のほんの一部を共通で有するだけである場合、高いスコアを有する可能性は低い。２つの名前が共通で有する語の数をカウントすることが、名前スコアのプロクシであり、つまり、名前スコアほど正確ではないが、それでも信頼できる。このプロクシは、共通する語の数がそれぞれの名前における語の数との関係で知られている場合、より正確になる。この長さが、クラスタレコードを全くフェッチすることなしにプロクシスコアを計算するのに利用可能であるように、検索ストア１４６の中に格納され得る。

【0182】

一部の実施例において、クエリの初期選択は、クラスタメンバシップ基準によって導かれることが可能である。オリジナルデータレコードの最も粒度の高い分解、又は最も明確に区別する分解を与えるクラスタメンバシップ基準の構成要素が、生のクエリを構築するための基礎として使用される場合、しばしば、より良好なパフォーマンスが実現され得る。このことは、検索基準を満たすレコードの数を減らす。

【0183】

また、複数のフィールドからの値を用いたクエリが関与する複数の検索が行われることも可能であり、より絞られたセットの候補につながる可能性がある。これらの検索については、後段で説明する。ここでは、詳細がより単純であるため、単一のフィールドからとられたクエリに注目する。

【0184】

いくらかの度合の可変性をそれぞれにおいて許して、企業が、個人名、政府によって割り当てられた識別子、及び生年月日に基づいて顧客データベースから顧客を識別することを所望する例を考慮されたい。この場合、初期のクエリに関して、政府によって割り当てられた識別子が、個人名より選好されることが可能である。通常、政府によって割り当てられた識別子は、可能なあいまいさを見込んでも、個人名と比べてより特定的であり、したがって、より良好なクエリをもたらす、つまり、候補照合のセットをより迅速に絞るものと予期される。

【0185】

しかし、フィールド（又はフィールドの組み合わせ）に関連付けられる粒度は、データセット全体にわたって一定でない可能性がある。多数の関連付けられるレコードを伴って、政府によって割り当てられた識別子のいくつかに入力されるデフォルトの値（例えば、空白、又はすべて０若しくはすべて９）が存在する可能性がある。これは、レコードサブセットに関して、クエリの選択の破綻を表す。あまりにも多くのレコードが検索によって取り出される場合、採点されるべきレコードのセットを絞る検索の主要な目的は、達せられていない。このことに対処するのに、所与のクエリ検索から返される候補の数にカットオフ限度が課せられることが可能であり、すなわち、候補レコードの数が閾値を超えた場合、そのクエリは、拒否される。

【0186】

一部のシナリオにおいて、展開されたクエリからのすべてのクエリが拒否されるまで生のクエリが続けられることが可能であり、展開されたクエリからのすべてのクエリが拒否された後、クエリレコードが、代替の検索戦略を用いて再処理されなければならない。例えば、生のクエリが複数語ストリングである場合、展開されたクエリは、そのストリングの中の個々の語からなることが可能である。そのストリングの中の非常に一般的な語が、多過ぎる候補を返すものとして拒否されることが可能である一方で、残りの、頻度のより低いクエリ語は、所望される照合するレコードを見つけ出すのに妥当である。生のクエリを拒否すべきかどうかの判定は、潜在的に満足のいく照合するレコードが、拒否されるクエリからのレコードを含めないことによって見逃されるかどうかに基づくことが可能である。展開されたクエリ内に複数のクエリが埋め込まれる場合、いくつかのクエリが失敗する一方で、他のクエリが続けられることは問題ない可能性がある。複数の独立したクエリが存在しない状況では、展開されたクエリセットからの１つのクエリの拒否が、そのセット全体を拒否するのに十分である可能性がある。

【0187】

多くの事例において、検索戦略が破綻する場合に、そのことは、データにデータ品質問題があること、例えば、不完全なレコード、又は採点フィールドに予期されないデフォルトの値が入っていることを示し得るので、レコードのセットを独立に識別することが有用であり得る。レコードの本体からレコードのそのようなセットを分離することにより、データが、最終的な照合判定の一般的な信頼性を示すセットに分類される。政府によって割り当てられた識別子を全く有さない、又はデフォルトの、政府によって割り当てられた識別子しか有さないレコードは、政府によって割り当てられた識別子をともに有するレコードの間で見出されるより低い確度の照合につながるものと見込まれ得る。

【0188】

２．６．３ 複数の検索及び検索コード
検索ストア３３０Ｇは、検索エントリ３３４Ｇをペアリングキー３３３Ｇで重複排除すること、及びロケーションキー３３５Ｇを、特定の検索キー３３３Ｇを有するデータレコードに関するすべてのロケーションキーを保持するロケーション情報にロールアップすることによって改良され得る。一部の実施例において、このロケーション情報は、関連付けられるレコードの数が少ない場合、キーの単純なベクトルであることも可能である。他の実施例において、このロケーション情報は、各ビットセットが、データセット３２０Ｇの中のデータレコードを明示的に、又は暗黙に示す、ビットベクトルであることが可能である。ビットベクトルは、圧縮されてもよい。

【0189】

ロケーション情報のビットベクトル実施例を使用することにより、検索ストアのサイズが小さくなることが可能であり、ペアリングキー３３３Ｇの同一の値に対してルックアップ３３２Ｇを繰り返すことが解消され得るが、本当の利益は、複数の検索の結果を組み合わせた際にもたらされる。展開されたクエリが、生のクエリの各語に関する別々のクエリからなる複数語ストリングからなる生のクエリの例において、別々の展開されたクエリの結果が、ロケーションビットベクトルの論理積をとることによって組み合わされることが可能である。２つのロケーションビットベクトルの論理積により、両方のロケーションビットベクトルにおける同一の位置で設定されたビットが求められる。この場合、これらのビットは、それらのロケーションビットベクトルに関連付けられる両方の語を包含するレコードである。ロケーションビットベクトルの間で論理積のすべての組み合わせを形成することによって、データセット３２０Ｇのレコード３２２Ｇ中に存在する生のクエリ３００Ｇからの語のすべての組み合わせが見出されることが可能である。

【0190】

これらの組み合わせを編成することを円滑にするのに、検索コードの概念が導入され得る。検索コードは、いずれの検索クエリが最終的なロケーション情報結果に寄与するかを符号化するデータパターンコードである。一部の実施例において、ロケーション結果に寄与する生のクエリ、又は展開されたクエリの各部分に関して、ビットベクトルにおいてビットが設定されることが可能である。複数のビットセットが、各ビットセットに関連付けられる各ロケーション情報結果の論理積に対応する。２つの検索が存在したとする場合、第１ビットが、第１セットから返される結果に関して設定され、第２ビットが、第２セットに関して返される結果に関して設定され、両方のビットが、両方の検索から返される結果（各検索の結果の論理積）に関して設定される。

【0191】

単一のフィールドからの２つ以上のトークンで複数の検索を行い、それらの検索によって取り出されるロケーション情報を論理的に組み合わせるという概念は、複数のフィールド（又はコンテキスト）からのトークンで複数の検索を行い、それらの検索によって取り出されるロケーション情報を論理的に組み合わせることに一般化されることが可能である。

【0192】

図７Ａ〜図７Ｄが、実施例における検索コードの構築及び使用を示す。図７Ａで、生のクエリ７００が、データレコードの３つのフィールド、ｆｉｒｓｔ（ｎａｍｅ）、ｌａｓｔ（ｎａｍｅ）、及びｓｔｒｅｅｔからのトークンから構築される。例えば、ｌａｓｔに関するクエリは、「ｓｍｉｔ」である。生のクエリが、展開されたクエリ７０４をもたらすようにクエリ展開手順７０２によって展開される。この事例における展開されたクエリは、場合により、変数プロファイラストア１１５から獲得される、生のクエリの各部分に関する変数トークンからなる。例えば、「ｓｍｉｔ」に関連付けられる変数トークンには、「ｓｍｉｔｈ」及び「ｓｍｉｔｈｓ」が含まれる。

【0193】

図７Ｂで、データソース７１０が、４つのフィールド、「ｋｅｙ」、「ｆｉｒｓｔ」、「ｌａｓｔ」、及び「ｓｔｒｅｅｔ」からなる。検索−エントリ展開手順７１２が、この３つのクエリフィールドそれぞれに関して検索ストア７１４を入力するのに使用される。

【0194】

図７Ｃで、展開されたクエリ７０４Ａが、変数−ルックアップ手順７２０Ａによって処理されて、ロケーション結果７２４Ａがもたらされる。この事例において、変数−ルックアップ手順は、それぞれの展開されたクエリに関して検索ストア７１４の中を探すこと（７２１）から始めて、実施される。次に、それぞれの展開されたクエリからのロケーション情報結果が組み合わされて（ベクトルの合併、又はビットベクトルの論理和）、生のクエリの「ｌａｓｔ」部分に関するロケーション情報結果７２４Ａがもたらされる。このことが、「ｌａｓｔ ｎａｍｅ」というラベルが付けられた円７３０Ａとして図示される。

【0195】

「ｆｉｒｓｔ」フィールドに関する第２展開されたクエリ７０４Ｂが、変数−ルックアップ手順７２０Ｂによって処理されて、ロケーション情報結果７２４Ｂが得られる。このことが、「ｆｉｒｓｔ ｎａｍｅ」というラベルが付けられた円７３０Ｂとして図示される。「ｌａｓｔ ｎａｍｅ」円７３０Ａと「ｆｉｒｓｔ ｎａｍｅ」円７３０Ｂの共通部分は、レコード「［２，４］」７３２を包含する。

【0196】

図７Ｄで、３つすべての生のクエリの結果が示されている。各円７３０ＡＢＣが、レコードそれぞれのコレクション７２４Ａ、７２４Ｂ、７２４Ｃを包含する。例えば、「ｌａｓｔ ｎａｍｅ」円が、レコード７２４Ａ、「｛１，２，４，５，７｝」を包含する。この円に検索コード１が割り当てられ、このことが検索−コードテーブル７４０の中に記録される。同様に、「ｆｉｒｓｔ ｎａｍｅ」円に検索コード２が割り当てられ、「ｓｔｒｅｅｔ」円に検索コード４が割り当てられる。検索コード１、２、及び４はそれぞれ、共通部分を除外した領域だけでなく、対応する円領域全体を指すことが強調されなければならない。同時に満足させられる２つ以上の生のクエリに関連付けられるレコードが、対応する円形領域に関連付けられるレコードのセットを交わらせることによって見出される。その結果が、検索−コードテーブル７４０の中に記録され、結果に寄与する個々の領域の検索コードの合計によって形成される検索コードとペアにされる。この場合、検索コードは、各ビットセットがいずれの円形領域が存在するかを示すビットマップ表現として認識され得る。

【0197】

最終ステップは、いずれの検索コードが、クラスタメンバシップに関してより綿密な採点に値するクエリに対する十分な応答に対応するかを指定することである。この場合、候補選択基準７４２は、検索コードが３、５、又は７でなければならないことである。このことは、成功するクエリ候補は、ｌａｓｔ ｎａｍｅと照合する変数と、ｆｉｒｓｔ ｎａｍｅ又はｓｔｒｅｅｔ、又はｆｉｒｓｔ ｎａｍｅとｓｔｒｅｅｔの両方と照合する変数とを有さなければならないことを意味する。ｆｉｒｓｔ ｎａｍｅ及びｓｔｒｅｅｔと照合する変数では、情報と照合するいずれの単一の変数の場合にも同様であるように、不十分である。採点のために返される候補７４４は、これら３つの検索コード７４２に関連付けられるレコードの合併によって与えられる。

【0198】

２．６．４ クエリ構築
クエリ構築手順１４２において、データソース１００から、又はトークン化されたレコード１１８から読み取られたレコードの中の１若しくは２以上のフィールド又はランタイムパラメータの断片又は全体から選ばれたコンテンツから生のクエリを構築する、場合により、クエリ構築規則セットが関与するクエリ構築式をユーザが与える。生のクエリは、いくつかがベクトルであり得る、１又は２以上のクエリフィールドの値からなることが可能である。例えば、ユーザが、個人名をクエリとして使用することを所望することが可能であり、ファーストネームフィールド、ミドルネームフィールド、及びラストネームフィールドのコンテンツを、各フィールド値の間のスペースで、又はカンマとスペースで連結することによって、そのクエリを構築する規則を指定する。１又は２以上のネームフィールドが無効である、又は入力されていない場合、その名前の構築を指定するさらなる割り当て（「大文字小文字」）が与えられることが可能である。代替として、場合により、ファーストネームとミドルネームの頭文字だけが保たれ、ラストネームと連結される。生のクエリは、複数の部分から形成された構造化されたレコードであることが可能であり、例えば、個人名に関する生のクエリは、別々のファーストネームクエリフィールド、ミドルネームクエリフィールド、及びラストネームクエリフィールドからなることも可能である。単一のｆｕｌｌ＿ｎａｍｅフィールドだけがデータレコード上に存在する場合、ユーザクエリ構築式は、生のクエリの構成フィールドを入力するのにそのｆｕｌｌ＿ｎａｍｅ値をどのように構文解析すべきかを指定することが可能である。クエリ構築式は、クエリレコードの中のデータを特徴付ける１又は２以上のデータパターンコード、例えば、生のクエリの他の要素を構築するのに使用される各フィールドの入力の状態（例えば、入力されている、空白、又は無効）を示す入力パターンコードを入力することが可能である。

【0199】

一部の実施例において、変数プロファイラ１１０のデータ準備モジュール１１１におけるスタンダダイザ１１２のようなスタンダダイザが、句読文字若しくは他の指定された文字を削除すること、又はそれらの文字を代替の文字で置き換えること、数の左側を０又はスペースで埋めること、アルファベットを小文字にすることなどのような、要求されることをユーザが示すが、完全な詳細で指定しなくてもよい（これらの操作は、事前定義された操作として利用可能であり得るので）操作を使用して、生のクエリに適用されることが可能である。一部の実施例において、独立した複数の標準化が適用されて、標準化された生のクエリのベクトルがもたらされることが可能である。例えば、「＆」のような一部の句読文字が、自然な用法の範囲に及ぶように複数の様態で扱われる必要がある可能性があり、つまり、その文字は、それぞれ有用な効果を伴って、削除される、スペース文字で置き換えられる、そのままにされる、又は「ａｎｄ」という語に展開されることが独立に行われ得る。

【0200】

クエリアプローチが直面する１つの課題は、個人名又は企業名のような一部のフィールド（又はフィールドの組み合わせ）が、自由形式の性質を有することであり、つまり、２つの名前が、それらの名前が欠落した語で、又は語順で異なる場合でさえ、許容可能な照合であり得ることである（すなわち、クラスタメンバシップ処理中にトークンを比較するのに使用される類似性採点関数又は類似性採点規則が、欠落した語、又は語順の変更にペナルティを課すが、それでも、欠落した語、又は語順の変更を許容する可能性がある）。このことは、例えば、一般に、フルネーム自体は、クエリであり得ないことを暗示する、つまり、あまりにも多くの許容可能な照合が見逃される可能性がある。つまり、フルネームで直接に検索することは、重要なすべての候補によっては満足させられない可能性がある語順、及びいくつかの名前が存在することを前提とする。代わりに、フルネームは、生のクエリとして扱われ、実際のクエリは、その生のクエリを展開することによって生のクエリから生成されるようにした方がよい場合があり得る。

【0201】

２．６．５ クエリ展開
生のクエリが、クエリ展開エンジン１４３によって処理されて、展開されたクエリが生成されることが可能である。一部の実施例において、変数プロファイラ１１０のデータ準備モジュール１１１におけるトークナイザ１１３のようなトークナイザが、クエリ展開中に生のクエリの要素に適用されて、クエリが、クエリ語句と呼ばれるトークンに分割されることが可能である。

【0202】

一部の実施例において、クエリ語句は、例えば、タイプ入力上の変数、代替のつづり、及び文化的変数を含むようにさらに展開されることが可能である。例えば、「ｃｉｖｉｌｉｚａｔｉｏｎ」というクエリ語句が、「ｃｉｖｉｌｉｓａｔｉｏｎ」及び「ｃｉｖｉｌｉｚａｔｉｎ」という語句を含むように展開され得る。「Ｗｅｂｅｒ」に関するクエリが、「Ｗｅｂｂｅｒ」という語句を含むように展開され得る。また、他の展開も可能であり、例えば、１つの文字体系における名前が、別の文字体系において複数のつづりを有することが可能である（例えば、漢字からローマ字への変換）。展開の際に使用すべきタイプ入力上の変数のセットは、変数プロファイル１１０において計算され得る。前処理が変数プロファイルストアの基本セットを確立した後、新たなレコードが処理されるにつれ、さらなる変数がオンラインで検出されて、変数プロファイラストアの変数のリストに追加されることが可能である。

【0203】

一部の実施例において、各クエリ語句は、トークン−代表ストア１２７を変数ネットワークストア１２６と一緒に使用してトークン代表で置き換えられることが可能である。このことは、同一の近隣（例えば、正規の近隣）内の変数トークンが同一のトークン−代表で置き換えられ、したがって、関連付けられる変数トークンを識別することは、単に厳密なトークン−代表照合を見つけ出すことを要求するだけであるので、変数トークンの比較を円滑にする。変数トークンは、２つ以上の近隣のメンバであることが可能であり、したがって、２つ以上のトークン−代表を有することが可能である。トークンに対応するすべてのトークン代表が、置換として使用されることが可能であり、その結果、（置換される）クエリ語句の数が増加する。

【0204】

一部の実施例において、クエリ展開エンジン１４３は、場合により、トークン−代表置換の後、２つ（又は３つ以上）のクエリ語句を組み合わせることによってトークン−ペアクエリ語句を形成することが可能である。このペアリングの目的は、クエリ語句に基づいて検索から返されるレコードのセットを絞ることである。一部の実施例において、（トークン−代表で置換された）トークン−ペアクエリ語句は、アルファベット順に並べ替えられる。このことは、トークン−ペアクエリ語句を検索する際に語順の局所化された変更を検出可能にする。隣接する語の各ペアを形成する際にオリジナルの語順が格納される場合、そのようなペアのセットが、ブロック再構成まで、オリジナルの句を再構築するのに使用されることが可能である。このことは、オリジナルの語順が、語のセット自体によっては捕捉されない様態で語ペアにおいて捕捉されることを意味する。

【0205】

仲介する１つのクエリ語句を有するクエリ語句からトークン−ペアクエリ語句を作成することは、照合の可能性を完全に除外することなしにフィールド（又はフィールドの組み合わせ）から語（又は他のトークン）が欠落している可能性があり、フィールド採点アルゴリズムが、このことを許容するように設計されるため、検索を向上させる。例えば、ミドルネームは、企業名からの「ｏｆ」のような項目の場合にそうであるように、しばしば、切り詰められ、又はレコードから省略される。欠落した語の他の多くのそれほど明白ではない例が、現実のデータには生じる。三重のクエリ語句、及びよりより多重のセットのクエリ語句が、さらに絞ったクエリを形成するのに使用され得る。

【0206】

例えば、クエリ展開エンジン１４３が、「Ｊｏｈｎ Ｊａｃｏｂ Ｊｉｎｇｌｅｈｉｅｍｅｒ Ｓｃｈｍｉｄｔ」という生のクエリを受け取る。トークン−代表ストア１２７が、トークン−代表「Ｊｏｈｎ」、「Ｊａｃｏｂ」、「Ｊｉｎｇｌｅｈｅｉｍｅｒ」、「Ｓｃｈｍｉｄｔ」のリストを返す。生のクエリにおける「Ｊｉｎｇｌｅｈｉｅｍｅｒ」は、「Ｊｉｎｇｌｅｈｉｅｍｅｒ」を包含する変数の正規の近隣におけるトークン−代表である、「Ｊｉｎｇｌｅｈｉｅｍｅｒ」のより頻度の高い変数「Ｊｉｎｇｌｅｈｅｉｍｅｒ」で置換されていることに留意されたい。クエリ展開エンジン１４３が、隣接するクエリ語句、この例では、「Ｊａｃｏｂ Ｊｏｈｎ」、「Ｊａｃｏｂ Ｊｉｎｇｌｅｈｅｉｍｅｒ」、及び「Ｊｉｎｇｌｅｈｅｉｍｅｒ Ｓｃｈｍｉｄｔ」を使用して、アルファベット順に並べられた（トークン−代表で置換された）トークン−ペアクエリ語句を作成する。また、クエリ展開手順は、仲介する１つのクエリ語句を有するクエリ語句「Ｊｉｎｇｌｅｈｅｉｍｅｒ Ｊｏｈｎ」及び「Ｊａｃｏｂ Ｓｃｈｍｉｄｔ」に関してアルファベット順に並べられた（トークン−代表で置換された）トークン−ペアクエリ語句を作成することもする。

【0207】

一部の実施例において、生のクエリは、前述した変数−検索の一部として変数−ルックアップ手順におけるクエリとなるように設計された変数クエリのセットを生成するように生のクエリを体系的に変更するクエリ展開手順を適用することによって、展開され得る。例として、２つの政府によって割り当てられた識別子（「ｇｉｄｓ」）が、それらのｇｉｄｓが多くとも１文字の変更だけ異なる場合に限って、つまり、それらのｇｉｄｓが１以下のハミング距離を有する場合に、照合と見なされるものと想定されたい。削除−結合手順が、図８に示されるとおり、厳密なルックアップを介してこのことを実施するのに使用され得る。データソース８２０における各ｇｉｄが、そのｇｉｄの削除セットを形成し、さらに削除位置、削除変数、及び関連付けられるキーを含む各削除エントリを検索ストア８３０に書き込むことによって展開される（８２５）。生のクエリ８００は、ｇｉｄからなる。生のクエリ８００が、検索ストア８３０のエントリを展開する（８２５）のに使用されるのと同一の削除−結合手順を使用して、削除セット８１０に展開される（８０５）。展開されたクエリは、削除位置と削除変数の両方をキーとして使用して検索ストア８３０の中でシークされる（８３２）。このことが、変数照合のセットをもたらし、次に、変数照合のこのセットが、照合するレコードを取り出すのに使用され得る（８３７）。

【0208】

この手順の変数形態が、オリジナルの変更されていないｇｉｄを、検索ストア８３０の中に削除位置０でエントリとして含め、検索ルックアップのキーを削除変数だけに（削除位置を無視して）変えることである。このことは、単一文字挿入、単一文字削除、及び単一文字代入、並びに２文字入れ換え及び非隣接挿入／削除を含む、すべての削除−結合１変数照合を見つけ出し、つまり、これらの照合は、すべての編集距離１変更と、長さを変えない編集距離２変更（二重代入は範囲に含まれない）の大部分とを含む。

【0209】

２．６．６ 採点エンジン
クエリデータレコードと、既存のデータクラスタの中のデータレコード（インクリメンタルモードにおいて）又はデータソースにおける他のデータレコード（バッチモードにおいて）の間の類似性の測度が、採点エンジン１５０によって計算されるスコアとして表されることが可能である。採点エンジン１５０は、１若しくは２以上のフィールドの、又はフィールドの組み合わせの、例えば、名前及び／又はアドレスを個々に、又は共同で構成するフィールドのコンテンツ全体又は部分的コンテンツを比較することによって、２つのレコードを比較することが可能である。これらのコンテンツは、これらのコンテンツがレコードのフィールドの値から導き出されるので、「フィールド−値」と呼ばれることが可能である。

【0210】

一部の実施例において、フィールド−値の選択されたペアの間のスコアは、それらの値の相等性、又はそれらの値の間の編集距離などの類似性基準に基づくことが可能である（他の類似性基準には、音声上の類似性、又は画像データ（例えば、顔認証のための）に関するグラフィック上の類似性などの様々なタイプのデータに関する他の形態の類似性が含まれる）。１文字又は２文字からなる短いフィールド−値は、誤りを意図と区別するための基礎が存在しない可能性があるため、しばしば、相等性に関してしか比較されないことが可能である。別個に、一部のフィールド−値、例えば、「Ｎｅｗ Ｙｏｒｋ」を包含する都市フィールドは、スペース文字を包含するようなことがある単位としてだけ意味上の意義を有する。そのような値では、１つの値を別の値に変えるのに要求される挿入、削除、及び代入の回数をカウントする編集距離が、類似性の良好な測度であり得る。

【0211】

一部の実施例において、コンテンツが、何らかの分離記号（一般に、ただし、排他的にではなく、スペース文字）で分離されたトークンの順序付けられたセットである、フィールド−値の選択されたペアの間のスコアは、厳密に照合するトークンの数、変数照合（同一ではないが、均等である、又は類似していると認識される）であるトークンの数、並びにトークン順序及びトークン位置の一致を考慮に入れることが可能である。例えば、個人名が、スペース分離記号又はカンマ分離記号を用いたファーストネームフィールド、ミドルネームフィールド、及びラストネームフィールドの連結として構築されることが可能である。データ品質問題には、１又は２以上のフィールドが入力されていないこと、及び名前順序の変更（例えば、ファーストネームとラストネームを入れ替えること）が含まれる。

【0212】

一部の実施例において、レコードのペアの間のスコアが、異なる情報の類似性の存在、欠如、又は度合に重み付けされた重点を与えるように、条件付き規則の階層に応じて、フィールド−値のペアの間で、スコア−要素と呼ばれるスコアのセットを組み合わせることによって、事前定義された、又はユーザによって指定された採点規則（例えば、規則セットによって、又は関数によって指定された）に基づいて計算されることが可能である。例えば、アドレスレコードを比較する際、同一の住宅番号、同一のストリート、同一の都市、及び同一の郵便番号を有する２つのレコードには、通常、一方のレコードに郵便番号が欠けている、又は照合しない郵便番号のような何らかの矛盾が存在するレコードの別のペアと比べて、より高いスコアが与えられる。スコア要素は、単一のスカラ値に制限されなくてもよく、複数のフィールド、及び複数のベクトルを包含するレコードを含め、より複雑な形態をとることが可能である。

【0213】

スコアは、個々のフィールド−値ペアに関する定性的採点測定のセット（例えば、スコアが１である場合、「厳密な照合」、スコアが１未満であるが、ファジー照合閾値を超えている場合、「ファジー照合」など）、及び／又はフィールド−値の入力の状態のようなレコード特性を符号化するデータパターンコードである、照合コードを含み得る。照合コードは、前述した検索コードと似たような目的を果たす。つまり、照合コードは、数値スコアの計算を要求することなしに、採点測定のセットを編成し、定性的照合条件の指定を円滑にする。

【0214】

スコア要素は、少なくとも部分的な順序付けを有さなければならず、したがって、スコア要素は、「より高い」スコア、又は「最良の」スコアを判定するように組み合わされ、比較されることが可能である。スコア要素の部分的順序付け、及び最良のスコアを判定するスコア要素の関連付けられる比較は、順序付けられた事例ベースの規則セットが関与する、事前定義された、又はユーザによって指定された規則セットの形態をとることが可能である。

【0215】

２．６．７ インクリメンタルモードにおけるクラスタメンバシップ判定
クラスタ化プロセス全体が、クラスタメンバシップ判定において一体となる。図９が、クラスタメンバシップを判定するためのプロセスの実施例の概略を示す。データソース１００が読み取られる。生のクエリが形成され展開される前に、レコードはセグメント化され並列に分割される（図示せず）（９１０）。一部の実施例において、前述したクエリ構築手順及びクエリ展開手順は、変数プロファイラストア１１５及び変数ネットワークストア１２６から読み取る。一部の実施例において、クエリレコードは、より区別しやすいレコードを先に置くように識別性の基準１３６で並べ替えられることが可能である。生の候補レコードが、検索ストア１４６にアクセスすることによって、前述した候補検索エンジンを使用して見出される（９２０）。事前定義された条件、又はユーザによって指定された条件が関与する候補選択手順９３０が、それらの生の候補レコードに適用されて、候補レコードのセットがもたらされる。

【0216】

選択９３０の後に見出される候補レコードは、既存のクラスタのメンバであり、実際、候補クラスタレコードである、つまり、それらの候補レコードは、１又は２以上のクラスタのメンバに対する近似照合である。選択条件９３０は、クエリレコードが、より綿密な調査に値するだけクラスタに十分に近いかどうかを判定するように指定される。

【0217】

クエリレコードが、候補選択９３０の後に全く候補クラスタレコードを返さない場合（９３２）、そのクエリレコードは、既存のクラスタのいずれのメンバにも近くなく、新たなクラスタが作成される（９３４）。そのクエリレコードは、マスタレコードとしてマスタレコードストア１７６に書き込まれる。この新たなクラスタレコードが、代表的レコードストア１７８及びデータクラスタ１８０にさらに書き込まれる。この新たなクラスタレコードは、検索ストア１４６に追加された検索−エントリ展開手順９３５を使用して検索−エントリを入力するのに使用される。一部の実施例において、生の候補クラスタレコード９２０を見つけ出すのに候補検索エンジンによって使用される検索ストア１４６は、マスタレコードだけから入力される（９３５）。他の実施例において、マスタレコードに加えて、代表的レコードストア１４８の中のレコードが、検索ストアに追加されることも可能である（９５２）。

【0218】

マスタレコードは、クラスタを何らかの様態で特徴付ける特別なクラスタの代表的メンバ、例えば、クラスタの最初のメンバである。一部の実施例において、クラスタ化が始まる前にデータが並べ替えられ、したがって、新たなクラスタの最初のメンバは、そのクラスタに関して、並べ替え順序で先頭となる。例えば、銀行ローン相手方のデータセットの中で、データが、会社名における語の多い順に並べ替えられて、マスタレコードを、最も長い会社名を有するクラスタのメンバにすることが可能である。長い会社名を有するレコードが、クラスタのシードとなるように選択され得るのは、長い名前が、より多くのトークンを包含するとともに、より多様なトークンを包含するため、より短い名前と比べて、一部の類似性採点手順によって、より容易に区別され得るためである。

【0219】

クラスタは、２つ以上のマスタレコードを有し得る。この特徴は、クラスタをマージする際、及びアルゴリズムによって行われたクラスタメンバシップ判定を人によって行われた判定で変更する際のクラスタ承認プロセスにおいて後段で使用される。

【0220】

候補選択手順９３０が１又は２以上の候補レコードを返した場合、それらの候補レコードに関連付けられるすべてのデータクラスタのメンバが、クエリレコードに照らして採点されるように取り出される。これらの関連付けられるデータクラスタは、候補データクラスタと呼ばれる。一部の実施例において、すべてのクラスタメンバではなく、代表的レコードストア１７８の中に格納されたメンバだけが取り出される（９３９）。採点エンジン１５０が、クエリレコードと取り出されるすべてのクラスタメンバの間の類似性スコアを判定するのに使用される。最良のスコアが照合閾値を超えている場合、そのクエリレコードは、対応するクラスタに追加される。クエリレコードが、２つ以上のクラスタに関して照合閾値を超えている場合、そのクエリレコードは、そのクエリレコードがより高いスコアを有する方のクラスタに追加される。一部の実施例において、クエリレコードが、２つ以上のクラスタに関して同一の最良のスコアを有する場合、そのクエリレコードは、最初のクラスタに追加される。他の実施例において、クエリレコードが、２つ以上のクラスタに関して同一の最高スコアを有する場合、そのクエリレコードは、メンバシップの尤度を反映する重みと一緒にすべてのそのようなクラスタに追加されることが可能である。

【0221】

一部の実施例において、クエリレコードがデータクラスタに関連付けられた後、クラスタメンバシップを判定することを担う最良のスコアが、閾値と比較されることが可能である。最良のスコアがこの閾値を下回る場合、そのクエリレコードは、クラスタのその他のメンバと十分に異なっていると見なされ、代表的レコードストア１７８に追加される。この場合の意図は、類似性スコアの部分的推移性を活用することである。ＡがＢと非常に類似しており、さらにＣがＡと非常に類似している場合、Ｂは、Ｃと少なくとも相当に類似している。このため、ＣをＢに照らして採点することは、Ａに照らしたスコアが十分に正確であるので、必要ない可能性がある。そのような閾値は、「準重複」閾値と呼ばれることが可能であり、極めて高く設定され得る。その目的は、特に、ほぼ同一であるクラスタメンバに照らした冗長な採点を減らすことである。

【0222】

一実施例において、クエリと生の候補レコードの間の照合するトークン−ペアクエリ語句の数がカウントされることが可能であり、その数が候補閾値を超えた場合、その生の候補レコードは、候補レコードであり、関連付けられるデータクラスタは、候補クラスタと見なされる。すべての候補データクラスタが識別された後、そのクエリレコードが、それらの候補クラスタのメンバに照らして採点されて、最良のスコアが見出され、プロセスは、前述したとおり、続けられる。

【0223】

図１０Ａ〜図１０Ｄは、マルチトークンクエリフィールドに関するクラスタ化プロセスの実施例を示す図である。図１０Ａにおいて、生のクエリ１０００が、会社名、「ＡＣＭＥ−Ｍｅｔｌ Ｇｒｐ」から形成される。生のクエリ１０００は、小文字に変換すること、及び句読点を置換することによって標準化されて（１００２）、標準化された生のクエリ１００４「ａｃｍｅ ｍｅｔｌ ｇｒｐ」が与えられる。各トークンが、図３Ａ〜図３Ｂにおけるとおり、そのトークンのトークン−代表ベクトル１００６で置換される。語「ｍｅｔｌ」は、２つの正規の近隣に属し、したがって、２つのトークン「ｍｅｔａｌ」と「ｍｅｔａ」を有し、この両方が、もたらされるトークン置換された生のクエリにおいて使用される。このトークン置換された生のクエリが展開されて（１００８）、アルファベット順に並べられたトークン語ペア及び単独語トークンのリストからなる展開されたクエリ１０１０、例えば、「ａｃｍｅ ｍｅｔａｌ」、「ｇｒｏｕｐ ｍｅｔａｌ」、「ｇｒｏｕｐ ｍｅｔａ」などがもたらされる。

【0224】

図１０Ｂで、プロセスが続けられる。標準化された生のクエリ１００４は、トークン置換され（１００６）、展開されて（１００８）、展開されたクエリ１０１０をもたらしている。別個に、マスタレコードストア１０５０のエントリが、検索ストア１０５４を入力するように展開されている（１０５２）。検索ストア１０５４における変数−ルックアップは、この事例では、展開されたクエリ１０１０から各トークンペアをとり、検索ストア１０５４の中でそのトークンペアを探す（１０５６）ことによって機能する。共通のクラスタｉｄと照合するトークンペアの数がカウントされ（１０５８）、その結果が、生の候補レコードのリストの中に格納される（１０６０）。この例において、照合するトークンペアの数は、２つの会社名のスコアのプロクシである。クエリ及びマスタレコードにおけるトークンの数に対してあまりにも少ない照合するペアを有する候補を削除するように閾値が適用される（１０６２）（この目的で、マスタレコードにおける名前のトークン数単位での長さが、検索ストア１０５４の中に格納されている）。

【0225】

図１０Ｃで、候補レコード１０６１が、候補クラスタｉｄ（クラスタシーケンスを含む）１０７２に関する代表的レコードストア１０７０から代表的レコードをフェッチするように読み取られる。標準化された、入ってくるレコード１０７４に存在する採点フィールドが、各代表的レコード１０７６からの取り出されたフィールドに照らして個々に採点される（１０７８）。これらのフィールド−レベルスコア１０８０が、事例ベースのスコア規則セット１０８２において組み合わされて、比較されるレコードのスコアが計算される。この場合、スコアは、照合判定として論理の点で符号化される（１０８４）。この場合、規則は、入力条件を「論理積演算すること」、及び事例を下方に「論理和演算すること」によって読み取られる。例えば、名前スコアが、ｎｅａｒ＿ｄｕｐｌｉｃａｔｅ＿ｔｈｒｅｓｈｏｌｄより高く、ｉｄ＿ｓｃｏｒｅが１であり、さらにｄａｔｅ＿ｓｃｏｒｅが１である場合、照合判定は、「準重複」である。名前スコアがｎｅａｒ＿ｄｕｐｌｉｃａｔｅ＿ｔｈｒｅｓｈｏｌｄより低かった場合、照合する条件が、存在する場合、見出されるまで、次の行が試みられるといった具合である。一部の実施例において、この規則セットは、参照により本明細書に組み込まれている米国特許第８，０６９，１２９号明細書において説明される環境などのビジネス規則環境を使用して符号化され得る。採点規則セット１０８２の列に示されるスコア要素は、照合コードで符号化されることが可能であり、例えば、第２行は、最初の位置の「３」が、照合閾値を超えた（ただし、準重複閾値を下回る）名前スコアを示し、その他２つの位置の「１」が、ｉｄスコア及び日付スコアに関して厳密な照合を示す、「３１１」という照合コードを有することが可能である。

【0226】

図１０Ｄで、スコア規則セット１０８２において、比較されたレコードに関する照合判定１０８４が、別の事例ベースの規則セットにおいてアクション１０８８に変換される（１０８６）。異なる照合判定に関して異なるアクションが行われる。照合判定１０９０「準重複」は、名前スコアがｎｅａｒ＿ｄｕｐｌｉｃａｔｅ＿ｔｈｒｅｓｈｏｌｄを超えており（このことにより、ｍａｔｃｈ＿ｓｃｏｒｅより高いことが暗示される）、その他のスコアが１である場合、割り当てられる。もたらされるアクション１０９２は、既存のクラスタｉｄを入ってくるレコードに割り当てることである。他方、照合判定１０９３が、「照合」であった（「準重複」ではなく）場合、既存の照合閾値を割り当てることに加えて、アクション１０９４は、代表的レコードストア１０７０にレコードを追加することである。照合判定１０９５が「照合なし」であった場合、アクション１０９６〜１０９９は、新たなクラスタｉｄを生成して、そのｉｄをレコードに割り当てること、そのレコードをマスタレコードストア１０５０に追加すること、検索−エントリ展開手順１０５２をレコードに適用し、それらの結果を検索インデックス１０５４に追加すること、及びそのレコードを代表的レコードストア１０７０に追加することである。

【0227】

２．６．８ バッチモードにおけるクラスタメンバシップ判定
クラスタ化プロセスは、バッチモードにおいて、インクリメンタルモードにおけるのとは多少異なったように進められる。図１１Ａ〜図１１Ｄは、このクラスタ化プロセスを図示する。図１１Ａで、このクラスタ化プロセスの高レベルの概略が与えられる。変数プロファイラストア１１５及び変数ネットワークストア１２６が、検索−エントリ展開手順を介して読み取られ、処理されて、検索ストア１４６の中に検索−エントリ１４５が入力されることが可能である。このことは、前処理ステップとして行われる。データソース１００が読み取られる。生のクエリが、一部の実施例において、変数プロファイラストア１１５及び変数ネットワークストア１２６の中のデータを使用して、各レコードに関して生成され、展開される（１１１０）。展開されたクエリは、クラスタメンバシップ基準を満足させない可能性があるレコードを除外するようにクラスタメンバシップ基準を近似するように作成されることが可能である。展開されたクエリは、検索ストア１４６から生の候補レコードを取り出す候補検索エンジン１１２０に送られることが可能である。生の候補レコードが、候補セレクタ１１３０によってフィルタリングされて、プロクシ照合基準を満たす候補レコードが選択されることが可能である。一部の実施例において、プロクシ照合基準は、各レコードに関して行われた複数の検索の結果を符号化する、検索コードを使用して部分的に実現され得る。プロクシ照合基準を満たすすべての候補レコードが、クエリレコードに照らして詳細な採点を受けることが可能であり（１１４０）、もたらされるスコアが、変数−ペアスコアストアの中に保存されることが可能である（１１５０）。

【0228】

一部の実施例において、各ペアに、スコアの要素に関するスコア判定の品質（名前照合又は郵便番号照合の品質などの）を含む、採点判定の背後の詳細、並びにそのペアのレコードにおけるフィールド又はフィールドの組み合わせの入力の状態の符号化を符号化する照合コードが割り当てられることが可能である。

【0229】

データソース１００の中のすべてのレコードが処理され、変数−ペアスコアストア１１５０が完成した後、データソースレコード１００が再び読み取られる。データソースレコードが、クラスタメンバシップエンジンによって処理されて（１１５０）、新たなクラスタを作成すること、及びクラスタメンバシップ判定があいまいである、又は周辺的である場合に、そのことを示すことを含め、各データソースレコードがいずれのクラスタに属するかが判定されることが可能である。ユーザ１０２が、ユーザインターフェース１０４を使用して、変数−ペアスコアストア１１５０を点検することが可能である。一部の実施例において、このユーザインターフェースは、各レコードがノードであり、候補レコードの変数−ペアがエッジである、変数−ペアスコアのネットワークをグラフ表示することが可能である。このユーザインターフェースは、候補レコードのペアに関連付けられる全体的なスコア、スコア詳細（全体的なスコアに寄与する構成スコアを含む）、検索コード、及び照合コードを記録することが可能である。一部の実施例において、ユーザ１０２は、変数−ペアスコアストア１１５０を操作して、変数ペアリングの詳細を追加する、削除する、又は変更することができる。

【0230】

変数−ペアスコアストアが、データセット１００に関して完成したので（１１５０）、バッチモードクラスタメンバシップ判定は、インクリメンタルモードの場合のように、それまでに処理されているレコードだけでなく、クラスタメンバシップ判定を行うのに利用可能なレコードの完全なセットを有する。

【0231】

図１１Ｂで、クラスタメンバシップエンジンの１つのバッチモード実施例が図示される。データレコードが、変数−ペアスコアストア１１５０を得るのに処理されるのと同一のデータソース１００から読み取られる。一部の実施例において、これらのレコードは、より区別しやすいレコードを先に置くように識別性の基準に応じて並べ替えられることが可能である（１１５１）。クラスタストア１７０及びデータクラスタ１８０の入力は、インクリメンタルである。各クエリレコードが、そのクエリレコードの一意レコード識別子（一意レコード識別子が既に付加されているものと想定される）でクラスタストア１７０の中で探されて（１１５２）、既にクラスタのメンバであるかどうかが判定され、既にクラスタのメンバである場合、関連付けられるクラスタｉｄが取り出される。

【0232】

クエリレコードの一意のレコード識別子がクラスタストア１７０の中に既に存在する場合、そのクエリレコードは、以前のデータレコードの処理中にそれらのクラスタストアに追加されているはずである。クラスタｉｄを割り当て（１１５３）、データクラスタ１８０を更新する（１１５４）。

【0233】

一意のレコード識別子がクラスタストアの中に存在しない場合、その一意のレコード識別子の変数ペアのレコードが、変数−ペアスコアストア１１５０の中で見つけ出されることが可能であり（１１５５）、スコアが照合閾値を超えている変数ペアのレコードが取り出される。この照合閾値は、オリジナルレコードがクラスタのマスタレコードであったとした場合に、同一のクラスタに入るだけ十分に類似しているレコードを示す。現在の設定において、マスタレコードは、クラスタの最初のメンバであると見なされ得る。したがって、ほとんどのレコードは、それら自体はマスタレコードではなく、この照合閾値は、変数−ペアのレコードと同一のクラスタにおけるメンバシップをサポートするだけ十分に類似しているレコードを識別するのに使用される。次に、各変数−ペアのレコードが、クラスタストアの中で探されて（１３５５）、それらのレコードの１又は２以上が、クラスタに既に割り当てられているかどうかが判定されることが可能である。考慮すべき３つの事例、すなわち、変数−ペアのレコードのいずれもクラスタストアに入っていない事例、１つが入っている事例、又は多くが入っている事例が存在する。

【0234】

クラスタストアの中に既に存在している変数−ペアのレコードが全くない場合、現在のレコードは、新たなクラスタの最初のメンバシップとなるだけ十分に既存のクラスタとは異なる。新たなクラスタが、現在のレコードに基づいて作成されると（１１５６）、データクラスタは、その新たなクラスタで更新される（１１５４）。さらに、各変数−ペアのレコードの一意のレコード識別子、及び変数−ペアスコアストア１１５０からの関連付けられる採点情報を含め、照合閾値を超えている変数−ペアのレコードそれぞれが、クラスタに追加される。前述したとおり、スコアが照合閾値を超えているレコードは、現在のレコードがクラスタのマスタレコードであったとした場合と同一のクラスタに入るだけ十分に類似しており、現在のレコードは、新たなクラスタの最初のメンバであるので、クラスタのマスタレコードである。これらのレコードは、これらのレコードについての情報が不完全であるため、データクラスタ１８０を更新するのに使用され得ない。各レコードは、そのレコードがデータソース１００から読み取られ、そのレコードの一意のレコード識別子がクラスタストア１７０の中で見つけ出されると、データクラスタ１８０に追加される。

【0235】

１つの変数−ペアのレコードが既存のクラスタのメンバであることが見出された場合、現在のレコードは、クラスタのメンバの照合閾値の範囲内にあり、そのクラスタのメンバであるとされる。現在のレコードに、関連付けられるクラスタｉｄが割り当てられる（１１５３）。次に、データクラスタ１８０が、現在のレコードで更新される（１１５４）。クラスタ検索ストア１７０が、現在のレコードに関連付けられるクラスタ情報で更新されることが可能である（１１６８）。

【0236】

図１１Ｃが、１つの変数−ペアのレコードが既存のクラスタのメンバである例を与える。既存のクラスタのマスタレコード１１８０に、黒で塗りつぶされた円で印が付けられている。非マスタレコードが、グレーで塗りつぶされた円で示される。準重複閾値１１８１が、そのマスタレコードと非常に類似しており、例えば、代表的レコードストア１７８（クラスタストア１８０のいずれか）に追加されない可能性があるレコードを取り囲む。照合閾値１１８２が、直接の関連によってクラスタのメンバとなるだけマスタレコードと十分に類似しているすべてのレコードを取り囲む。第２互いに素なクラスタのマスタレコード１１８３が、そのレコードの準重複閾値境界及び照合閾値境界と一緒に示される。

【0237】

現在のレコード１１８４は、このレコード１１８４が、示される２つのクラスタの照合閾値境界の外にあるので、既存のクラスタのメンバではない。このレコード１１８４自らの照合閾値境界１１８５が、１つのデータレコード１１８６を取り囲む。このデータレコード１１８６は、このデータレコード１１８６が照合閾値の範囲内にあるため（このため、データレコード１１８４がマスタレコードであるとした場合、データレコード１１８４に関連付けられるクラスタのメンバであることになり、この場合、データレコード１１８４は、マスタレコードである）、データレコード１１８４に関する変数−ペアデータレコードである。データレコード１１８６は、既にマスタレコード１１８０に関連付けられるクラスタのメンバであり、したがって、現在のデータレコード１１８４がこのクラスタに追加される。現在のデータレコードは、照合閾値１１８２を外れているので、現在のデータレコードがクラスタメンバシップを導き出すデータレコードに対する接続を示すようにエッジ１１８７が描かれる。

【0238】

一部の実施例において、関連の連鎖を介するクラスタの成長を制限するのに、外側の疑わしい閾値境界１１８８がマスタレコード１１８０の周囲に引かれて、クラスタメンバが見出され得る領域を制限することが可能である。データレコード１１８９は、データレコード１１８４の照合閾値の範囲内にあり、現在、そのクラスタのメンバであるが、疑わしい閾値境界１１８８の外にあり、したがって、マスタレコード１１８０のクラスタにおけるメンバシップから除外される。そのような周辺的な変数−ペアリングが、この場合に破線で示されるとおり、ネットワークグラフにおいて区別されることも可能である。

【0239】

図１１Ｂに戻る。多くの変数−ペアのレコードが既存のクラスタのメンバであることが見出された場合、クラスタのセットは、重複排除される。１つだけの明確なクラスタが存在する場合、前述の事例が当てはまる。一実施例において、現在のレコードの１又は２以上の変数−ペアのレコードを包含するいくつかの別々のクラスタが存在する場合、各クラスタ内の最良のスコア、及び対応する照合する変数ペアのレコードが、クラスタメンバシップ判定のあいまいさ又は不確かさの証拠として記録される（１１６２）。最良の照合は、それぞれの別個のクラスタからの最良のスコアを比較することによって見出されることが可能である（１１６４）。引き分けが生じた場合、現在のレコードは、最も小さいクラスタｉｄを有するクラスタに割り当てられる。一部の実施例において、現在のレコードは、各クラスタの相対的スコアによって決定される重みと一緒に２つ以上のクラスタの部分的メンバにされてもよい。

【0240】

関連付けられるクラスタｉｄが、現在のレコードに割り当てられる（１１５３）。データクラスタ１８０が、現在のレコードで更新される（１１５４）。さらに、クラスタストア１７０が、割り当てられたクラスタｉｄ、及びスコアを伴う代替のクラスタメンバシップペアリングのリストを含む、現在のレコードに関連付けられるクラスタ情報で更新される（１１６８）。

【0241】

図１１Ｄが、現在のデータレコードが別々の２つのクラスタの照合閾値の範囲内にある実施例を示す。前述の場合と同様に、データレコード１１８０及び１１８３が、別々のクラスタのマスタレコードであり、データレコード１１８０及び１１８３それぞれの準重複閾値境界及び照合閾値境界が示されている。現在のデータレコード１１９０が、クラスタメンバシップに関して考慮されている。現在のデータレコード１１９０は、照合閾値の内側に２つの変数−ペアのレコード、データレコード１１９３及び１１９４を有する。データレコード１１９３は、マスタレコード１１８０に関連付けられるクラスタのメンバであり、データレコード１１９４は、マスタレコード１１８３に関連付けられるクラスタのメンバである。クラスタとこれらの変数−ペアのレコードがともに、クラスタストア１８０の中に記録されることが可能である。２つの間でより良い方のスコアが、現在のデータレコード１１９０と変数−ペアデータレコード１１９３の間のスコアであるものと想定されたい。現在のデータレコード１１９０は、マスタレコード１１８０のクラスタに割り当てられ、現在のデータレコード１１９０のデータレコード１１９３とのペアリングが、黒のエッジで印を付けられる。変数−ペアデータレコード１１９４、及び変数−ペアデータレコード１１９４に関連付けられる、マスタレコード１１８３を有するクラスタとの代替の関連付けが、グレーのエッジによって記録され、印を付けられる。

【0242】

グラフィカルユーザインターフェース１０４において、クラスタのネットワークが、各データレコードをノードとして表示されることが可能である。マスタレコードであるデータレコードが区別されることが可能である。クラスタ内のデータレコードのコレクションの回りに線を描くクラスタの境界が引かれることが可能である。クラスタメンバとの変数−ペアリングのお蔭でクラスタのメンバである照合境界の外にあるデータレコードが、エッジによって示されることが可能である。潜在的に、２つ以上のクラスタのメンバであるデータレコードが、強調表示されることが可能である。これらは、割り付けがクラスタ承認プロセス中にユーザによる点検を受ける可能性があるデータレコードであり、これらのデータレコードを区別して、複数のクラスタに対するこれらのデータレコードの結び付きを示すことは、ユーザがメンバシップに関して最終的な決定に達するのを助けることが可能である。ユーザ１０２は、ユーザインターフェース１０４を使用して、そのような決定を、後段で説明されるとおり、クラスタネットワークの点検の一環として、又はクラスタ承認プロセスの一環として行うことができる。

【0243】

２．６．９ トークン−ペアクエリ語句に関する変数−ルックアップ手順
候補レコードが、クラスタｉｄが検索結果によって参照されて出現する、異なるクエリの数に基づいてランク付けされることが可能である。例えば、クラスタ１が、３つのクエリに関する検索結果によって参照されることが可能であり、クラスタ１０が、２つのクエリに関する検索結果によって参照されることが可能であり、クラスタ１５が、４つのクエリに関する検索結果によって参照されることが可能であるといった具合である。一部の実施例において、候補レコードには、それらの候補レコードを参照する検索結果を生成したトークン−ペアクエリ語句の数対トークン−ペアクエリ語句の数の比に基づくスコアが与えられる。このスコアは、以下の式を使用して算出され得る。すなわち、
ｓｃｏｒｅ_{ｃａｎｄｉｄａｔｅ}＝ＱｕｅｒｙＰａｉｒｓ_{ｃａｎｄｉｄａｔｅ}／ＱｕｅｒｙＰａｉｒｓ
ただし、ｓｃｏｒｅ_{ｃａｎｄｉｄａｔｅ}は、クラスタのスコアである。ＱｕｅｒｙＰａｉｒｓ_{ｃａｎｄｉｄａｔｅ}は、そのクラスタを識別する検索結果を含むクエリの数である。さらに、ＱｕｅｒｙＰａｉｒｓは、検索ストアの中の展開されたクエリから探し出されたトークン−ペアクエリ語句の数である。

【0244】

候補レコードが、スコアを候補閾値と比較することによって識別されることが可能である。例えば、クエリペアの半分が照合することが、良好なスコアであることが可能である。

【0245】

一部の実施例において、いずれの候補を保持するかを決定する際に補足的な情報が使用され得る。例えば、トークン−ペアクエリ語句の数（隣接するクエリ語句、及び仲介するクエリ語句を有するクエリ語句を含む）は、クエリにおけるトークンの数Ｎの点で２Ｎ−３として表現され得る。この候補レコードは、Ｍ個のトークンを有し、したがって、２Ｍ−３個のトークン−ペアクエリ語句を有する。候補の良好なセットをもたらす例示的な基準は、照合したクエリペアの数が２^＊ｍｉｎｉｍｕｍ（Ｍ，Ｎ）−５以上であることを要求することである。この式の重要な特徴は、この式が、候補レコードが、クエリと比べて、より少ないトークン−ペアを有する可能性があり、したがって、より少ない照合ペアが、可能な照合を有することを要求されることを認識することである。他の式も可能である。

【0246】

２．６．１０ クエリ拒否処理
一部の実施例において、あまりにも多くの別々のレコードを参照する検索結果が、十分に区別する役割をしないとして破棄されることが可能である。例えば、トークン−ペアクエリ語句によって返されるレコードの最大数に関する閾値が１００であることが可能であり、このことが、トークン−ペアクエリ語句が役に立たなかった場合、時間を浪費せずに適当な数の個々のレコードが採点されることを可能にする。クラスタメンバシップは、通常、２つ以上のフィールド類似性スコアによって判定される。トークン−ペアクエリ語句が、大量のクラスタを返す場合、このことは、候補のセットにわたって、トークン−ペアクエリ語句が大きく変わらない一方で、他の何らかの値が大きく変わることを意味する可能性がある。取り出されたレコードの数が閾値に達した後、トークン−ペアクエリ語句は、他の区別に役立つ情報が効果的であるほどには効果的でない可能性があるため、ドロップされることも可能である。

【0247】

単独トークンクエリ語句に関して、閾値は、より低く設定されることが可能であり、場合により、１０未満に設定されることが可能である。その理由は、個々の単独トークンクエリ語句が、一般に、それほど区別に役立たないことであり、事実、個々の単独トークンクエリ語句は、ペアが形成され得ない場合に１語だけのトークンを包含するレコードとの照合を検出するのに最も役立つ可能性がある。単独トークンクエリ語句が明確な照合を見つけ出すことに成功しない場合、区別するのにより役立つ他の何らかの情報を使用する方が生産的であり得る。

【0248】

一部のシナリオにおいて、生のクエリが候補クエリを全くもたらさないことが可能であり、例えば、生のクエリが空白又は無効であることも可能である。又は、クエリ語句がすべて、一般的過ぎるとして拒否されることが可能であり、この場合、クエリは全く行われ得ない。両方の場合において、そのレコードは、クエリプロセスから拒否される。異なるフィールド（又はフィールドの組み合わせ）が関与する代替のクエリ構築式が、クラスタ化を駆動する役に立つクエリを作成するのに使用され得る。いずれのクエリ式の下でレコードがクラスタ化されたかを示すクラスタ戦略識別子が、レコードに印を付けるのに使用されてもよい。

【0249】

例えば、第１クラスタ化が、政府によって割り当てられた識別子に基づいており、多数のレコードが、例えば、すべて０のデフォルトの値を有するものと想定されたい。すべて０の政府によって割り当てられた識別子で（名前や生年月日のような他のフィールドで異なって）１００のクラスタが形成された後、後続のレコードは、拒否される。一部の実施例において、一般的過ぎるクエリ語句を共有するすべてのレコード、又は代表的レコードのより小さいセットが、既にクラスタ化されたレコード、及びそれらのレコードのクラスタのその他のメンバを含め、抽出される。レコードのこのコレクションが、新たなクラスタ戦略を使用して再クラスタ化される。各レコードに関する、古い戦略の下におけるオリジナルクラスタｉｄは、後の使用のために保存されることが可能である。この例において、名前に基づくクエリを使用する新たなクラスタ戦略は、レコードのこのセットに関して、区別するのにより役立つ可能性が高く、政府によって割り当てられた識別子のクラスタ戦略が失敗した場合にレコードをクラスタ化するのに使用され得る。一般に、クエリを構築するのに使用すべきフィールドは、区別するのに最も役立つものから区別するのに最も役立たないものの順に選択される。不完全なレコードは、区別するのにそれほど役立たず、潜在的に、あいまいなクラスタメンバシップ判定につながり、したがって、それらのレコードが、完全に入力されたレコードとは別にクラスタ化されることが有用である。

【0250】

第２クラスタ戦略の下でクラスタ化する際、一般的過ぎるクエリをセグメント値として使用することが有用であり得る。このことにより、一般的なクエリ値を共有するセットからのレコードに対してクラスタ化が制限される。第２クラスタ化の後、古いクラスタｉｄと新たなクラスタｉｄの複数照合調整が使用されることが可能である。最初のクラスタ化と２番目のクラスタ化は、クラスタ戦略の選択がクラスタメンバシップ判定に影響を与え得るため、異なるレコードセットをクラスタに割り当てる可能性がある。複数照合調整は、それらの異なる戦略の下におけるクラスタをマージしようと試みる。複数照合調整の詳細は、異なるが、関連付けられる脈絡において後段で説明される。

【0251】

一部の実施において、検索ストア１４６は、異なるフィールド（又はフィールドの組み合わせ）を使用するクエリに対応する複数の検索−展開手順に関する検索エントリを包含することが可能である。例えば、検索ストア１４６は、政府によって割り当てられた識別子クエリに基づくクラスタに関するエントリを包含することが可能である。これらの検索−ストアエントリが、名前ベースのクエリに関して、同一のクラスタｉｄキーを保持して、再展開され得る。つまり、政府によって割り当てられた識別子クエリを使用してクラスタ化することによって導き出されたデータクラスタをデータソースとして使用して、名前ベースのクエリ表現のための検索エントリが、展開され得る。このことは、検索ストアにインデックスを付け直すことに相当する。既存のクラスタのセットに、新たなクエリ戦略のためにインデックスが付け直された場合、拒否されたレコードを処理することは、関連付けられるレコードを抽出して、再処理することを要求せず、新たなクエリのためにインデックスが付け直された検索ストアを使用するフレッシュなクラスタ化実行として進められることが可能である。

【0252】

２．６．１１ 複数照合調整
図１２で、複数照合調整ステップ手順が図示される。クラスタがベクトル化された形態で保持される場合、つまり、複数クラスタメンバが、単一のレコードの中で一緒に保持される場合、それらのクラスタメンバが、個々のレコードに正規化される（１２００）。これらのレコードが、一意のレコードキーで分割される（１２０２）。このことが、それぞれのオリジナルデータレコードのすべてのレプリカントが同一のパーティションの中に入っていることを確実にする。それらのデータレコードが、レコードキーでロールアップされて、レコードに関連付けられる別々のクラスタキーのベクトルが得られる（１２０４）。１つのクラスタキー、例えば、最小のクラスタキーが、選好されるものとして選択される。次に、このベクトルが、選好される（この場合は、最小の）クラスタキーを他それぞれの別個のクラスタキーとペアにする、クラスタキーペアに正規化される（１２０６）。次に、推移閉包が、すべてのクラスタキーペアのセットに適用される。このことは、接続されたクラスタキーペアの各ネットワークに対する、つまり、各クラスタに対する１つのクラスタキーの割り当てをもたらし（１２０８）、次に、このクラスタキーが、各一意のデータレコードに割り当てられる（１２１０）。

【0253】

複数照合リコンサイラ１６５の一実施例が、図１３Ａ〜図１３Ｃに図示される。図１３Ａで、複数のパーティション上のレコードのクラスタ５１０が、個々のレコード１３２１に正規化される（１３２０）。最初のクラスタ１３００において、ｋ１が、２つのレコードを包含するクラスタのクラスタｉｄである。これらのレコード１３１０の最初のレコードが、セグメントキー「１３５」、ｉｄ「１２３４５６」、及びレコードキー「ｒ１」を有する。正規化の後、クラスタキーｋ１が、レコード１３１０に追加され、セグメントキーがドロップされて、レコード１３２２がもたらされる。次に、正規化されたレコード１３２１が、レコードキー１３２４で再分割される。結果１３２６は、レコードキーを共有するすべてのレコードが同一のパーティション内に存在することである。

【0254】

図１３Ｂで、レコード１３２６が、レコードキー１３２８でロールアップされて、クラスタキーのベクトル１３３０をそれぞれが包含する、一意のレコードキーを有するレコードがもたらされる。例えば、レコード１３３１が、レコードキー「ｒ１」を有する一意のレコードである。レコード１３３１は、ｉｄ「１２３４５６」と、２つのクラスタｉｄのベクトル「［ｋ１，ｋ２］」を有する。クラスタキーのペアが形成される。この場合、これらのクラスタキーは、既にペアである。ベクトルがより長い、例えば、「［ｋ１，ｋ２，ｋ５］」である場合、ペアは、以下のベクトル、すなわち、「［ｋ１，ｋ２］」、「［ｋ２，ｋ５］」における隣接する要素から形成される。推移閉包１３３２が、接続されたペアの各セットに関して一意の代表的クラスタキーを選択するように適用されて、結果としてのペアリング１３３４が与えられる。

【0255】

図１３Ｃで、レコード１３３０に、推移閉包１３３２から得られたマッピング１３３４を使用して一意のクラスタキーが割り当てられる。これらのレコードが、クラスタキー１３４０で再分割されて、クラスタキーにわたってロールアップされてデータクラスタ５３０にされる。

【0256】

２．６．１２ クラスタ承認プロセス
一部の実施例において、マスタレコードが、クラスタ化の後に行われるクラスタ承認プロセスの一環として、クラスタのメンバの中からユーザによって指定されることが可能である。クラスタは、２つ以上のマスタレコードを有し得る。同一のクラスタｉｄを有する複数のマスタレコードが、クラスタシーケンス番号で区別される。

【0257】

クラスタ承認プロセスは、ＵＩを介して、レコードのクラスタへのグループ化を点検し、所望に応じて変更を行う機会をユーザに与える。例えば、ユーザが、クラスタ中のいずれのレコード、又はいずれの複数のレコードがマスタレコードとして指定されるかを変更することを所望する可能性がある。マスタレコードは、クラスタの特別の代表の役割をし、詳細には、マスタレコードは、ときとして、表示のために使用されることが可能であり、ときとして、検索ストアエントリが形成されるマスタレコードとして使用されることが可能である。ユーザが、クラスタの最初のメンバ以外、又はクラスタの重心以外の何らかのレコードが、場合により、そのレコードが、そのレコードのフィールドのいくつかの中でより良好な値（ユーザに対して）を有するため、より良好な代表であると感じることが可能である。一部の実施例において、マスタレコードが変更されると、マスタレコードストアが、新たなマスタレコードを追加し、前のマスタレコードを無効にする、又は削除することによって変更されることが可能である。検索ストアがマスタレコードに基づく場合、検索ストアは、新たなマスタレコードに対応するエントリを追加し、さらに古いマスタレコードと関係するエントリを無効にする、又は削除するように変更される。

【0258】

また、ユーザが、１つのクラスタのクラスタｉｄが別のクラスタのクラスタｉｄの値に再マップされるべきことを手動で示すことによって、２つのクラスタをマージすることを選択することも可能である。例えば、会社名に基づくクラスタ化に関して、ユーザが、２つのクラスタ上の会社名が同一の法人を表し、同一のクラスタの中に一緒に保持されるべきことを認識することが可能である。クラスタｉｄ１２５が、「ＨＳＢＣ」に関するレコードを保持することが可能である一方で、クラスタｉｄ１９２が、「Ｍｉｄｌａｎｄ Ｂａｎｋ」に関するレコードを保持する。これらの名前は、類似性採点規則の下で照合ではないが、ユーザは、Ｍｉｄｌａｎｄ ＢａｎｋがＨＳＢＣによって買収されていることを知っており、Ｍｉｄｌａｎｄ ＢａｎｋとＨＳＢＣを一緒にクラスタ化することを所望する。ユーザが、クラスタｉｄ１９２がクラスタｉｄ１２５に再マップされるべきことを示すことが可能である。一部の実施例において、クラスタ承認変更が処理されると、マスタレコードストアが、クラスタｉｄ１９２を有するプライマリレコードのクラスタｉｄを１２５に変更し、クラスタシーケンスを次に大きい未使用の値に設定するように変更されることが可能である。また、マスタレコードに関連付けられる検索ストアエントリが、ｃｌｕｓｔｅｒ＿ｉｄを１９２から１２５に変えるように変更されることも可能である。将来のクラスタ化において、「Ｍｉｄｌａｎｄ Ｂａｎｋ」という名前を有するレコードは、クラスタｉｄ１２５において候補を見出し、クラスタｉｄ１２５において「ＨＳＢＣ」レコードと一緒にクラスタ化されることが可能である。

【0259】

ユーザが、クラスタを同様の様態で分割することを選択することが可能である。一部の実施例において、レコードには、新たなクラスタのメンバであるという印が付けられることが可能である。クラスタ承認変更が処理されると、そのレコードが、新たなクラスタのマスタレコードとしてマスタレコードストアに追加されることが可能であり、そのレコードから入力された検索−エントリが、検索ストアに追加されることが可能である。

【0260】

一部の実施例において、検索ストアエントリは、すべてのクラスタメンバから生成されたエントリの互いに素な合併で入力され、つまり、そのクラスタの何らかのメンバによる検索−エントリ展開手順によって生成されたそれぞれの別個のエントリが、そのクラスタに結び付けられたインデックスにおけるエントリとして保持される。このことは、そのクラスタの多様性を検索プロセスに公開するのに役立つ。

【0261】

一部の実施例において、さらなる情報が、候補の存立可能性の評価を容易にするように検索ストアの中に格納されることが可能である。例えば、企業名又は個人名のような複数語フィールドの中のトークンの数が、検索ストアの中に格納されることが可能である。

【0262】

図１４Ａ〜図１４Ｂは、クラスタ承認プロセスをより詳細に図示する。図１４Ａで、データクラスタ１８０からのレコードが読み取られ（１４０１）、データクラスタレコードからのクラスタｉｄ及び他の情報を含む、選択されたデータクラスタのすべてのメンバに関するレコードを包含する承認ワークシートが入力される。一部の実施例において、承認シートにおける列は、いずれのレコードが確認され、いずれのレコードがマスタレコードであるかを示すように入力され得る。ユーザ１０２が、承認変更を指定するようにユーザインターフェース１０４を介して承認ワークシートを閲覧し、編集することができる（１４２０）。

【0263】

承認ワークシートに対してユーザ１０２によって（又は何らかの自動的プロセスを介して）行われた変更が、変更された承認ワークシートをオリジナルワークシートと比較することによって検出される（１４３０）。

【0264】

一部の実施例において、ユーザ１０２が、レコードをクラスタのメンバとして確認することが可能であり、確認した場合、そのレコードは、将来、クラスタ化に差し出された場合、さらなる処理なしに現在のクラスタｉｄを受け取る。一部の実施例において、更新手順１４３２が、確認済み又は除外済みのストア１７２にレコードの一意参照キーを現在のクラスタｉｄと一緒に追加し（１４３３）、そのレコードに確認済みとして印を付けることによって、このことを実現する。また、ユーザが、以前に確認されたレコードの確認を取り消すことも可能であり、確認を取り消した場合、そのレコードは、確認済み又は除外済みのストア１７２から削除される、又は更新手順によって無効にされたという印が付けられることが可能である（１４３２）。

【0265】

一部の実施例において、ユーザが、レコードを、クラスタのメンバとして除外することが可能であり、除外した場合、そのレコードは、将来、クラスタ化に差し出された場合、さらなる処理なしに、現在のクラスタｉｄを有するクラスタにおけるメンバシップを阻止される。このことは、そのレコードに関する次善のクラスタを見つけ出すようクラスタ化アルゴリズムを仕向ける機構として使用され得る。一部の実施例において、除外は、確認と類似したプロセスによって達せられる。更新手順１４３２が、レコードの一意参照キーを現在のクラスタｉｄと一緒に確認済み又は除外済みのストア１７２に追加して（１４３３）、レコードに除外されたという印を付ける。ユーザが、前に除外されたレコードの除外を取り消すことが可能であり、除外を取り消した場合、そのレコードは、確認済み又は除外済みのストア１７２から削除される、又は更新手順によって無効にされたという印が付けられることが可能である（１４３２）。

【0266】

一部の実施例において、いずれのレコードがクラスタのマスタレコードであるかが変更されることが可能である。新たなマスタレコードは、更新されたマスタレコードストア１４４０の中に格納されることが可能であり、古いマスタレコードは、マスタレコードストア１４４０から削除される又は無効にされることが可能である。

【0267】

一部の実施例において、レコードに、新たなクラスタに再マップされるように印が付けられることが可能である。このことは、既存のクラスタを分割する効果を有する。そのような印が付けられたレコードには、新たなクラスタｉｄが割り当てられ（１４３８）、更新されたマスタレコードストア１４４０の中に新たなクラスタのマスタレコードとして格納される。現在のクラスタのマスタレコードに対してよりも、印の付けられたレコードの方に近いレコードは、後続のステップでレコードが再処理される際に、印が付けられたレコードと一緒にクラスタ化されるので、選択されたレコードにそのように印が付けられるだけでよい。

【0268】

一部の実施例において、レコードが既存のクラスタに再マップされることが可能である。このことは、２つのクラスタをマージする効果を有する。例えば、クラスタｉｄ１９２を有するレコード「Ｍｉｄｌａｎｄ Ｂａｎｋ」が、「ＨＳＢＣ」クラスタ１２５に再マップされて、その結果、これらのクラスタがマージされることが可能である。既存のクラスタにレコードをマージする際、そのレコードには、既存のクラスタｉｄが割り当てられることが可能であり、そのレコードは、そのクラスタに関する新たな、さらなるマスタレコードとなる。一部の実施例において、クラスタの異なるマスタレコードが、クラスタシーケンス番号で区別されることが可能である。新たなマスタレコードがクラスタに追加されると、最高のクラスタシーケンス番号がインクリメントされてから（１４３６）、そのレコードが、更新されたマスタレコードストア１４４０に追加される。

【0269】

確認済み又は除外済みのストア１７２及び更新されたマスタレコードストア１４４０に適切な更新が行われた後、それらの変更によって潜在的に影響を受けるすべてのレコードが、データクラスタ１８０から抽出されて（１４３４）、影響を受けるレコードのデータセット１４５０がもたらされることが可能である。一部の実施例において、影響されるレコードは、変更が開始されたクラスタの中の、又はレコードが再マップされているクラスタの中のすべてのレコードを抽出することによって識別されることが可能である。その理由は、これらのクラスタの中のレコードがすべて、クラスタメンバシップに関係のある意味で比較的近く、それでも、これらのクラスタのメンバに対する変更が他のクラスタにおけるメンバシップ判定に影響を与えないだけ十分に他のクラスタの中のレコードから離れていることである。

【0270】

図１４Ｂで、クラスタ承認変更による影響を受けるレコードを再クラスタ化するプロセスが図示される。影響を受けるレコード１４５０が読み取られ（１４５１）、検索ストア及び代表ストアに適用されて、影響を受けるレコードの中のクラスタに関連付けられるすべてのレコードが（確認されたレコード以外）削除されて（１４５２）、縮小された検索ストア１４５６及び縮小された代表ストア１４５８がもたらされる。このことは、事実上、影響を受けるレコードに関して、確認済み又は除外済みのストア１７２及び更新されたマスタレコードストア１４４０が既に入力されていること以外は、クラスタ化プロセスを初期状態に戻す。影響を受けるレコード１４５０は、確認済み又は除外済みのストア１７２、更新されたマスタレコードストア１４４０、縮小された検索ストア１４５６、及び縮小された代表ストア１４５８を使用して、図９におけるとおり読み取られ（１４５９）、再クラスタ化される。

【0271】

確認されたレコードには、それらの既存のクラスタｉｄが割り当てられる。マスタレコードである、影響を受けるレコードは、それらのレコード自体との厳密な照合であり、それらのレコードに関連付けられるクラスタｉｄを割り当てられる。除外されるレコードは、特定のクラスタから阻止され、適宜、他のクラスタに割り当てられる。この割り当ては、影響を受けるクラスタの中にないクラスタに対して行われることが可能であり、そうされる可能性が高い。そのような再割り当てが可能であるのは、更新されたマスタレコードストア１４４０、縮小された検索ストア１４５６、及び縮小された代表ストア１４５８が、他のすべてのクラスタに関するレコードを包含し、したがって、それらの他のクラスタに対する照合及び割り当てが可能であるためである。他のすべてのレコードは、通常のクラスタメンバシップ判定プロセスがそれらのレコードを連れて行く先に向かう。前のクラスタのレコードと比べて、再マップされたレコードとより類似しているレコードは、再マップされたレコードのクラスタに割り当てられる。このことは、クラスタを分割することと、マージすることの両方に関して行われる。

【0272】

レコードが処理されるにつれ、縮小された検索ストア１４５６及び縮小された代表ストア１４５８が再入力されて（１４６４）、更新された検索ストア１４６６及び更新された代表ストア１４６８がもたらされる。クラスタメンバシップ判定の結果が、変更された、影響を受けるデータクラスタのデータセットに書き込まれる（１４８０）。この結果がオリジナルデータクラスタ１８０と比較されて（１４８２）、データクラスタ差が見出されることが可能である（１４８４）。一部の実施例において、クラスタの前と後のリスト又はグラフ画像が、ユーザインターフェース１０４においてユーザ１０２に示されることが可能である。次に、ユーザ１０２が、さらなる承認変更を行い、このプロセスを繰り返すことによって反復することを選択すること、又はそれらの変更を破棄して、やり直すことを選択することが可能である。ユーザが承認変更に満足した場合、確認済み又は除外済みのストア１７２、マスタレコードストア１７４、検索ストア１４６、及び代表的レコードストア１７８を含むデータクラスタ１８０及びクラスタストア１７０が、新たなデータソースの将来のクラスタ化のために使用されるように公開されることが可能である。

【0273】

３ 遠隔システムに照らしたクラスタ化
孤立した遠隔クラスタ化システム、詳細には、データを全くエクスポートしない遠隔クラスタ化システムにおいて保持されるデータクラスタに照らしてレコードをクラスタ化することが、インクリメンタルモードにおけるクラスタメンバシップ手順の変更によって扱われることが可能である。必須の要件は、クエリに加えて、起点システム上のクラスタ化プロセス中に見出されたいくらかのさらなるデータが、遠隔クラスタ化システムに送られなければならないことである。このさらなるデータは、起点システム上の変数の範囲を代表する、トークンのレベルと候補レコードの両方のレベルで変数である。これらの変数が、遠隔システム上で包括的検索及びクラスタ照合を行うことを要求される。

【0274】

クエリには、２つの形態があり得る。クエリは、クエリレコードから形成されたクエリであることが可能であり、その場合、そのクエリレコードがそのクエリと一緒に送られる。又は、クエリは、関連付けられるクエリレコードを全く有さない孤立したクエリであることが可能であり、その場合、そのクエリ自体だけが単に送られる。このことは、このプロセスにおいて後に候補照合レコードの採点に影響を与える。

【0275】

トークンに関して、起点システムにおける各トークンが、遠隔システムにおいて、起点システムに存在しない変数トークンを有することが可能である。これらの新たな変数を見つけ出すのに、起点クラスタ化プロセスに参加するトークンと関係するすべての変数が、遠隔システムに送られなければならない。一部の実施例において、トークンの変数の全範囲を捕捉するのに、オリジナルの展開されたクエリにおけるトークンとペアにされたすべてのトークン−代表に対応するトークンの集められた近隣が取り出され、遠隔クラスタ化システムに送られる。遠隔システム上で、これらのオリジナルのトークンが変数プロファイラストア及び変数ネットワークストアに追加されて、オリジナルのシステムと遠隔システムの間で新たな変数ペアリングが判定され、更新された変数プロファイラストア及び変数ネットワークストアが書き込まれる。トークン−代表が、更新された変数ネットワークストアにおいて形成される。トークン−代表は、検索ストアにこれらのトークン−代表でインデックスが付けられるため、遠隔システム上で最初に作成されたままでなければならない。新たなオリジナルの変数トークン、すなわち、遠隔変数プロファイラストアにも、遠隔変数ネットワークストアにも既に存在しているわけではない起点システムからのトークンは、既存のトークン−代表近隣に追加される。

【0276】

すべてのオリジナルの変数を送る同様の要件が、適切に照合する候補レコード、すなわち、クエリに適切な選択基準を満たす候補レコードが特定された後に、代表的レコードストアから取り出される代表的レコードに適用される。これらの代表的レコードは、それらのクエリ選択基準を満たす起点システム上のレコードの多様性を範囲に含む。これらのレコードそれぞれが、さもなければ検出されないままになる可能性がある遠隔システム上の変数ペアリングを見つけ出すことが可能である。

【0277】

クエリと関係する変数トークンと代表的レコードの両方が、クエリと一緒に遠隔システムに送られる場合、インクリメンタルモードにおける前述したクラスタメンバシップ手順が、指定された選択基準によりクエリと照合するすべてのレコードを取り出すように適用されることが可能である。一部の応用例、例えば、詐欺検知又は法科学捜査において、クエリと関係するレコードを取り出すための選択基準は、クラスタメンバシップを判定するのに使用されるクラスタメンバシップ基準とは異なることが可能である。クラスタメンバシップは、通常、偽陽性識別、つまり、レコードを誤ったクラスタに入れることを回避するように、より制限的な基準を優先させるのに対して、法科学クエリは、偽陰性、つまり、照合であるべきレコードを見逃すことを回避するように、より緩い基準を優先させる。

【0278】

図１５Ａ〜図１５Ｃで、遠隔クラスタ化システムに照らして行われるクエリの例が図示される。図１５Ａで、ユーザインターフェース１０４Ａを使用するユーザＡ １０２Ａが、クエリ１５００をローカルクラスタ化システムにサブミットする。一部の実施例において、変数プロファイラストア１１５Ａからのレコードを利用して、生のクエリにおける各トークンとペアにされる変数トークンを見つけ出し、変数ネットワークストア１２６Ａからのレコードを利用して、例えば、展開されたクエリにおいて変数トークンに取って代わるべきトークン−代表を探し出して、そのクエリが展開されることが可能である（１５１０）。前述したとおり、変数ネットワークストア１２６Ａにおけるそれらのトークンに関するトークン−代表の近隣は、選択された変数ネットワークレコードとして抽出され、保持される（１５１４）。選択された変数ネットワークレコードにおけるすべてのトークンが、変数プロファイラストア１１５Ａから抽出され（１５１５）、選択された変数プロファイラレコードとして保持される（１５１６）ことが可能である。

【0279】

生の候補が、検索ストア１４６Ａを使用して、展開されたクエリから見つけ出される（１５２０）。使用される検索エントリが、選択された検索エントリにおいて保持されることが可能である（１５２２）。クエリ選択基準が、生の候補レコードに適用されて（１５３０）、候補レコードが選択される。候補レコードが存在する場合、それらの候補レコードに関連付けられるクラスタに包含される代表的レコードが、代表的レコードストア１７８Ａから取り出され（１５４０）、選択された代表的レコードとして保持される（１５４２）。クエリ１５００、及び、存在する場合、様々な選択されたレコード１５１４、１５１６、及び１５４２が、遠隔クラスタ化システムによる処理のために遠隔クラスタ化システムに送られて、受信される（図示せず）。

【0280】

図１５Ｂで、受信し、選択された変数プロファイラレコード１５１６が、遠隔システム上の変数プロファイラストア１１５Ｂを更新するのに使用されて（１５５１）、更新された変数プロファイラストア１５５２がもたらされる。一部の実施例において、このことは、このクエリの目的に限って使用される一時的更新であり得る。受信し、選択された変数ネットワークレコード１５１４、及び更新された変数プロファイラストア１５５２が、変数ネットワークストア１２６Ｂを更新するのに使用されて（１５５３）、更新変数ネットワークストア１５５４がもたらされる。

【0281】

図１５Ｃで、受信したクエリ１５００及び受信した、選択された代表的レコード１５４２が読み取られる。生のクエリが、それぞれの選択された代表的レコードから形成され、オリジナルクエリと一緒に、更新変数プロファイラストア１５５２及び更新された変数ネットワークストア１５５４を使用して、展開されたクエリに展開される（１５１０）。生の候補レコードが、遠隔検索ストア１４６Ｂの中で見つけ出される（１５６０）。クエリ選択基準が、生の候補レコードに適用されて、それらの選択基準を満たす候補レコードが見つけ出される（１５６５）。フィルタが適用される（１５６７）。候補が全く存在しない場合、そのことが、ユーザインターフェース１０４Ｂを介してユーザ１０２Ｂに報告される。

【0282】

候補が存在する場合、それらの候補が、代表的レコードストア１７８Ｂの中のそれらの候補に対応するクラスタから代表的レコードを取り出すのに使用され、それらの代表的レコードが、次に、現在のクエリレコードに照らして、つまり、オリジナルクエリレコード、又は現在のクエリが形成される元となったオリジナルの代表的レコードに照らして採点される。オリジナルクエリ自体が関連付けられるクエリレコードを有さなかった場合、すべての代表的レコードがとられる。一部の実施例において、オリジナルクエリに関連付けられるクエリレコードが存在する場合、そのクエリレコードもまた、取り出された代表的レコード１７８Ｂに照らして採点され、そのスコアが、現在のクエリレコードと代表的レコードの間のスコアと一緒に報告される。

【0283】

現在のクエリレコードと代表的レコード１７８Ｂの間のもたらされるスコアが、クエリ照合基準と比較され、それらの照合基準が満たされた場合（１５７５）、データクラスタレコードが、遠隔データクラスタ１８０Ｂから取り出されて（１５７７）、クエリ結果として格納される（１５８０）。次に、それらのクエリ結果が、ユーザインターフェース１０４Ｂを介してユーザ１０２Ｂに報告される。

【0284】

４ 実施例
前述したクラスタ化技法、セグメント化技法、及び並列化技法は、コンピュータ上で実行されるソフトウェアを使用して実施され得る。例えば、このソフトウェアが、少なくとも１つのプロセッサと、少なくとも１つのデータストレージシステム（揮発性メモリ及び不揮発性メモリ、及び／又は記憶素子を含む）と、少なくとも１つの入力デバイス又は入力ポートと、少なくとも１つの出力デバイス又は出力ポートとをそれぞれが含む、１又は２以上のプログラミングされた、又はプログラマブルなコンピュータシステム（分散型、クライアント／サーバ型、又はグリッド型などの様々なアーキテクチャのものであり得る）上で実行される１又は２以上のコンピュータプログラムにおける手順を形成する。このソフトウェアは、例えば、データフローグラフのデザイン及び構成と関係する他のサービスを提供するより大きいプログラムの１又は２以上のモジュールを形成することが可能である。そのグラフのノード及び要素は、コンピュータ可読媒体の中に格納されたデータ構造として、又はデータリポジトリの中に格納されたデータモデルに準拠する他の編成されたデータとして実装され得る。

【0285】

このソフトウェアは、汎用、若しくは専用のプログラマブルコンピュータによって読み取られ得る、ＣＤ−ＲＯＭなどの記憶媒体上で提供されることが可能であり、又はネットワークの通信媒体を介して、このソフトウェアが実行されるコンピュータの記憶媒体に伝送される（伝搬される信号内に符号化されて）ことが可能である。これらの機能のすべてが、専用のコンピュータ上で、又は、コプロセッサなどの専用のハードウェアを使用して実行されることが可能である。このソフトウェアは、このソフトウェアによって指定される計算の異なる部分が異なるコンピュータによって実行される分散された様態で実装されることが可能である。それぞれのそのようなコンピュータプログラムは、好ましくは、汎用、又は専用のプログラマブルコンピュータによって読み取られることが可能な記憶媒体又はストレージデバイス（例えば、ソリッドステートメモリ又はソリッドステートメディア、又は磁気媒体又は光媒体）の上に格納され、又はダウンロードされて、その記憶媒体又はストレージデバイスがそのコンピュータシステムによって読み取られると、本明細書で説明される手順を実行するようにそのコンピュータを構成する、又は動作させるようにする。また、本発明のシステムは、コンピュータプログラムを備えて構成されたコンピュータ可読記憶媒体として実装されると考えられることも可能であり、ただし、そのように構成された記憶媒体は、コンピュータシステムが、本明細書で説明される機能を実行する特定の、事前定義された様態で動作するようにさせる。

【0286】

本発明のいくつかの実施形態が説明されてきた。それでも、本発明の趣旨及び範囲を逸脱することなく、様々な変数形態が作成され得ることが理解されよう。例えば、前述したステップのうちいくつかは、順序に依存しないことが可能であり、このため、前述した順序とは異なる順序で実行されることが可能である。

【0287】

以上の説明は、添付の特許請求の範囲において規定される本発明の範囲を例示することを意図しており、限定することは意図していないことを理解されたい。例えば、前述したいくつかの機能ステップは、全体的な処理に実質的に影響を与えることなしに、異なる順序で実行されることが可能である。その他の実施形態が、以下の特許請求の範囲に含まれる。

【図1A】

【図1B】

【図1C】

【図1D】

【図1E】

【図1F】

【図1G】

【図2A】

【図2B】

【図2C】

【図2D】

【図3A】

【図3B】

【図4】

【図5A】

【図5B】

【図5C】

【図6】

【図7A-7B】

【図7C】

【図7D】

【図8】

【図9】

【図10A】

【図10B】

【図10C】

【図10D】

【図11A】

【図11B】

【図11C】

【図11D】

【図12】

【図13A】

【図13B】

【図13C】

【図14A】

【図14B】

【図15A】

【図15B】

【図15C】