JP2019505937A - データベース・テーブル、テキスト・ファイル、及びデータ・フィード中のテキストのソルティング - Google Patents

Abstract

データベース・テーブル、テキスト・ファイル、及びデータ・フィードの「水平方向」ソルティングのためのシステムは、データの有用性に影響を及ぼすことなしに、キー・フィールド及びそのフィールド内の文字位置、「キー文字」、並びに少なくとも２つの状態のうちの１つ中に合法的にあり得るコンテンツを含んでいるソルティング・フィールドを利用する。データの受信側に割り当てられた一意の識別子が、２進数０又は１を表すために、ソルティング・フィールド中の状態の変動を使用することによってデータ内に隠れており、キー文字の値は、一意の識別子内の２進数０又は１のビット位置を識別する。このタイプのソルティングは、データ・ファイルの受信側に見えず、データの正確さを変更せず、データ・ファイルを受信する特定の当事者について一意にされるか、又は各データ・ファイルについて一意にされ得る。

Description

本発明の分野は、データが不適切にコピー又は使用されたどうかを決定するための、データのソルティングであり、特に、そのような目的のための消費者データのソルティングである。ソルティングは、データが漏洩された場合、データのサブセット中に含まれているデータがデータ所有者に識別され得るように、データのサブセットに一意のデータ（ソルト）を挿入する仕組みである。

この背景技術のセクションにおいて述べられる言及は、本発明に関して従来技術であると認められるものではない。

データ漏洩は、所有者又は許可されたユーザ以外の誰かによるデータの不正の使用として定義され得る。データ漏洩の財政的影響は、世界的に毎年数億ドル単位であると推定され、したがって、データ・サービス産業における非常に重要な問題を表す。データ漏洩を防ぐことを試みるソリューションが、しばらくの間存在している。これらのソリューションは、データが組織のファイアウォール外に漏洩するのを防ぐか、又はデータがファイアウォールを出て「ワイヤ上の」オープン・ネットワーク上に移動するときにデータを暗号化する。グラフィカル、ビデオ、オーディオ、又はドキュメント（すなわち、テキスト又はｐｄｆ）データが、ファイアウォール外に平文で実際に暴露された後、そのデータの所有権を主張するためのソリューションも存在しており、組織は、誤用からそれらのデータを保護するためのものとして知られる、これらの「デジタル・ウォーターマーキング」ソリューションを使用する。（「ウォーターマーキング」という用語は、印刷媒体から借用され、ウォーターマークは、真正性を検証するための印刷文書上の転写画像又はパターンからなるが、デジタル・ウォーターマークは、同じ目的をはたすためにデジタル・ファイル中に埋め込まれた一種のマーカーである。）データ所有者が法廷においてウォーターマークを所有権及び著作権侵害の証拠として使用することができるので、ウォーターマークは、データ所有者が無認可使用についての損害を回復することを可能にする。同時に、そのような法的救済が存在することは、個人又はグループが、その著作物を無料で取得し、次いで使用することを希望することを阻止する。

不幸にも、テキスト及びデータベース・ファイルのデータ漏洩は、平文で受け渡されるのか使用の時点において解読されるのかにかかわらず、未解決の問題のままである。消費者データの所有者（「データ所有者」）は、しばしば、自身のデータを、金融サービスにおけるレギュレーションＢ或いは地域、州又は連邦政府によって設定されたプライバシー法など、契約上の要件又はデータ処理規則に従って、そのデータを法的様式でのみ使用すると確信される個人又は組織（「信用できる第三者」又は「ＴＴＰ」）に与えるか、リースするか、又は販売する。このデータは、通常、一連のデータベース・テーブル（たとえば、．ｓｑｌフォーマット）、テキスト・ファイル（たとえば、．ｃｓｖ、．ｔｘｔ、．ｘｌｓ、．ｄｏｃ、及び．ｒｔｐフォーマット）として、又はリアルタイム・データ・フィード（たとえば、ＸＭＬ又はＪＳＯＮ）として送信される。これにもかかわらず、データ所有者のデータが、承知の上で又は知らないでのいずれかで適切な許可なしにさらには違法にデータを使用する他人（「バッド・アクター（Ｂａｄ Ａｃｔｏｒ）」）の手中に漏洩することがしばしば行われる（漏洩されたファイルは、本明細書では「漏洩されたサブセット」として定義される）。これは、たとえば、ＴＴＰが、承知の上でデータを公開し、それ自体がバッド・アクターであるか、ＴＴＰの従業員が承知の上で又は偶然にデータを公開するか、或いはデータ所有者自体の従業員が承知の上で又は知らないでデータを漏洩するので、起こり得る。これは、テキスト・データが、セキュア形式から、漏洩が容易に行われ得るフォーマットに移ることが、データ所有者からデータ・ユーザへの一連のステップ中の最後のステップにおいてであるので、業界において「ラスト・マイル」問題と呼ばれることがある。

データベース及びテキスト・ファイルのウォーターマーキングは、固有の課題を提示する。画像、ビデオ又はオーディオ・ファイルは、高密度で、高度に構造化される。これらのタイプのファイルは雑音耐性があるので、ファイルの情報コンテンツ又はユーザ・エクスペリエンスを劣化させることなしに、これらのファイル中にウォーターマークとして少量のデータを埋め込むことが容易である。雑音耐性ファイルは、（ウォーターマークなどの）わずかな雑音が、得られるデータを劣化させることなしに追加され得るファイルであり、たとえば、ウォーターマークは、閲覧者が変化に気づくことなしに、数ビットのデータを変更すること又は隣接フレームの順序を変更することによってビデオ・ファイルに追加され得る。同時に、このタイプのデータの高度に構造化された性質は、バッド・アクターがウォーターマークを除去することを困難にする。データベース・テーブル及びテキスト・ファイルは、それと比較して、比較的軽量であり、したがって、雑音の導入に耐えられない。たとえば、名前又は住所中の単一の文字を変更することさえ、そのレコード中のデータを無用にし得る。このタイプのデータの構造は、ウォーターマークをもろくし、検出しやすくし、したがって、データが不適切に使用されたことを立証しようとする当事者に認識不可能にするのを容易にするやり方（たとえば、列を並べ替えること、行を付加すること、行を削除すること）で、容易に操作され得る。たとえば、検出を回避するために、データ・テーブル内の要素が変更され得、データが他のデータ・ソースからのデータとマージされ得、データがサブセットに分割され及び／又は他のやり方で再構成され、操作され得る。その結果、データベース又はテキスト・ファイル（或いはそれのＪＳＯＮ又はＸＭＬ等価物）の所有権を主張すること及び／或いはデータを漏洩することの原因である当事者を検出することを希望するデータ所有者にとって著しい障害が存在する。データ所有者は、適用可能な証拠基準を満たす不法行為の証明を欠くので、訴訟（ａｃｔｉｏｎ ａｔ ｌａｗ）を通して収益減を容易に回復することもできない。その上、データ漏洩を検出するための現在の方法は、主に手動操作を通してであり、したがって、時間がかかり、労働集約的であり、費用がかかり、誤りを起こしやすい。したがって、これらのタイプのファイルにウォーターマークを入れるか又は「ソルティングする」改善されたシステム及び方法が、大いに利益になるであろう。

本発明は、本明細書では「水平方向」ソルティングと呼ばれる、データベース・テーブル、テキスト・ファイル、データ・フィード、及び同様のデータをソルティングする（又はそれらにウォーターマークを適用する）ための方法を対象とする。水平方向ソルティングは、本出願の発明者によって開発されたウォーターマーキングの仕組みであり、それにより、ごく少数の一意の及び識別可能な変更が、データのフルセット又はサブセット上で行われる。水平方向ソルティングは、データの有用性に影響を及ぼすことなしに、２つの構成要素、すなわち、評価される、キー・フィールド及びそのフィールド内の文字位置、並びに合法的に少なくとも２つの状態のうちの１つにあり得るコンテンツを含んでいるソルティング・フィールドに基づいて、データ・ファイルに影響を及ぼす。これらの構成要素は、様々な実施例では、レコード中の同じフィールド又は異なるフィールドであり得る。いくつかの実施例では、キー文字は、英数字の全範囲など、多種多様な値を有し得る。データ・ファイルが表フォーマットにおいて構成されるとき、しばしば個々の行として示されたデータの個々のレコードに対する変更が行われ、したがって、ソルティングは、操作が行ごとの方法で行われるという意味で「水平方向」であるので、「水平方向」ソルティングという用語がここで造り出される。この手法の結果は、以下で説明されるように、ソルトを見つけるためにファイル全体を分析する必要がなく、むしろ、少数の行又はいくつかの場合には１つの行のみ分析する必要があることである。これは、プロセスの計算速度を大幅に改善する。

本明細書で説明される本発明のいくつかの実装形態による水平方向ソルティング・システムは、以下の原理に従う。
１．限定的摂動。フィンガープリンティングを除く、ウォーターマーキングのあらゆる形式は、データの何らかの摂動を伴う。問題は、データの品質がデータを使用不可能にするのに十分損なわれるようになるまで、どのくらいの摂動がデータベースに挿入され得るかである。その上、データが使用不可能であるかどうかは、それの意図された使用事例に大きく依存する。たとえば、メーリング・リスト中の１つの人名を変更することでさえ、商業的結果を有し、ウォーターマーキングは、複数の名前を変更することを必要とすることがある。したがって、その使用事例では、ウォーターマーキング目的のためにこのフィールドを使用することは可能でない。しかしながら、名前が医療データの統計的分析のために使用されるデータベースの一部である場合、名前のわずかな変動が許容できる。
２．ウォーターマークの一意性。ウォーターマークは、使用事例に必要なグラニュラリティのレベルに固有であるべきである。商用システムでは、ウォーターマークは、会社による所有権を主張し、データを漏洩した可能性が最も高かった１つの個人及び会社を識別するために使用される。したがって、会社に結合されたウォーターマークが、おそらく、この使用事例におけるグラニュラリティの妥当なレベルである。あらゆるファイルについて異なるウォーターマークを有することが、さらに高い精度を提供し得るが、それは、ウォーターマークを作成及び検出するために必要とされるシステムのサイズを増加させる。スケールのあらゆる増加は、関連するコストを有し、会社レベルのウォーターマーキングで間に合うとき、ファイルレベル・グラニュラリティは、費用がかかりすぎて努力に値しないことを証明し得る。本発明のいくつかの実装形態では、システムは、ファイル・レベル又は顧客レベルのいずれかにおいて高度に一意のウォーターマークを適用することのフレキシビリティを有する。これは、以下で説明されるように、受信側ＩＤをファイル又は顧客に割り当てることによって達成される。
３．盲目。理想的には、データベース又はテキスト・ファイル中のウォーターマークを識別することは、元のウォーターマークを入れられていないデータベースの知識もウォーターマーク情報も必要とするべきでない。この性質は、データの元のソースが未知である状況においてさえデータベースのコピー中でウォーターマークが検出されることを可能にするので、重要である。本明細書で提示されるシステムは、元のウォーターマークを入れられていないデータベースの知識もウォーターマーク情報も必要としない。代わりに、システムは、ウォーターマークを検索するために、ウォーターマークを入れられたワイルド・ファイルを処理する。検出されたウォーターマーク及びそれの対応する受信側ＩＤは、ウォーターマークの所有者を検索するために、データベースに対して照合され得る。
４．非干渉。ワイルドで発見されるファイルは、２つ又はそれ以上のソースからのデータを含んでいることがあり、それらのいずれかがウォーターマークを入れられていることがある。したがって、あるウォーターマークの存在が、ファイル中の別のウォーターマークの発見に干渉するべきでない。システムは、ファイル中の２つ以上のウォーターマークを検出することが可能である。ウォーターマーク検出プロセスは、ワイルド・ファイルの所有者を検索するために、ウォーターマーク・データベースに照合するために、ワイルド・ファイルからすべての可能なウォーターマーク及び対応する受信側ＩＤを暴露することを試みる。
５．罪の法的確認（ｌｅｇａｌ ｃｏｎｆｉｒｍａｔｉｏｎ ｏｆ ｇｕｉｌｔ）についての妥当性。いかなる商用ウォーターマーキング・システムも、法廷において通用することができるウォーターマークを生成しなければならない。一意のウォーターマークは、良いスタートである。しかし、法廷では、ウォーターマークが特有の会社のファイルに属することを証明するだけでなく、検索されるウォーターマークが、別の会社のために使用されるウォーターマークと混同され得ないことをも証明する必要があり得る。システムは、検出された（１つ又は複数の）ウォーターマークを（１つ又は複数の）受信側ＩＤとともに出力する。（１つ又は複数の）受信側ＩＤは、ウォーターマークがファイルに適用されたとき、検出された受信側ＩＤがシステムによって割り当てられたことを保証するために、ウォーターマーク・データベースに照合される。単一のウォーターマークが検出された場合、データの所有者が見つけられたということが大いにあり得る。複数のウォーターマークが検出された場合、システムによって与えられる情報が、ファイル中のデータについて複数のソースを潜在的に発見することにつながるきっかけとして働く。

本明細書に記載された水平方向ソルティングの結果として、漏洩されたサブセット又は「ワイルド・ファイル」中に含まれているデータは、変更された場合でも、特有の受信側及び受信側が受信した特定のファイルに与えられたものとして識別され得る。バッド・アクター及び特有の漏洩されたデータ・セットを識別するこのプロセスは、罪の割当て（ｇｕｉｌｔ ａｓｓｉｇｎｍｅｎｔ）と呼ばれる。罪の評価（ｇｕｉｌｔ ａｓｓｅｓｓｍｅｎｔ）は、データ所有者が、データの水平方向ソルティングに基づいて、バッド・アクターをそれによって起訴する強い証拠事例を構築することを可能にする。水平ソルティングは、バッド・アクターによって検出することが困難であり、したがって、バッド・アクターが、データがソルティングされたか又はソルティングされ得たことに気づいている場合でも、バッド・アクターが除去することが困難又は不可能である。したがって、水平ソルティングは、潜在的バッド・アクターが最初に取得したデータを事実上不適切に使用する可能性を低減し、それは、そのような不適当な使用が検出され得、法的措置を生じることを知ることによるものである。

本発明のこれらの及び他の特徴、目的並びに利点は、以下で説明されるように、図面とともに、好ましい実施例の以下の詳細な説明及び添付の特許請求の範囲を考慮するとより良く理解されるようになるであろう。

本発明の一実施例による、ソルトが新しいファイルに追加されるプロセスを示す図である。 本発明の一実施例による、出所不明（ｕｎｋｎｏｗｎ ｏｒｉｇｉｎ）のファイルが、ソルトの存在のために分析されるプロセスを示す図である。 本発明の一実施例による、ソルティング・システムのインフラストラクチャ及びアーキテクチャを示す図である。

本発明がさらに詳細に説明される前に、本発明の範囲は特許請求の範囲によってのみ限定されるので、本発明が、説明される特定の実施例及び実装形態に限定されないこと、並びに特定の実施例及び実装形態を説明する際に使用される用語が、それらの特定の実施例及び実装形態を説明するためのものにすぎず、限定するものではないことを理解されたい。

本発明のいくつかの実装形態の説明を始めるために、関連する技術的記述の正確な定義が以下のように提示される。Ｄを、限定はしないが、会社Ｃによって所有されるフラット・ファイルを含む、データベースとする。Ｄは、リレーショナル形式又は構造化テキスト（たとえば、．ｃｓｖ、ＸＭＬ、又はＳＱＬデータ）におけるタプルからなる。Ｓ_ｉを、Ｄからのタプルのサブセットとする。Ｍを、Ｄ又はＤよりもはるかに小さいＳ_ｉの表現Ｗを生成するための一意の方法とする。その場合、目的は、以下のようなＷを生成することである。
１．Ｗは、所与のＭについてのＤ又はＳ_ｉの一意の「フィンガープリント」である（すなわち、Ｍは、２つの異なるＤ又はＳ_ｉのために同じＷを生成することができない）。
２．Ｗは、統計的信頼性を用いて、Ｄのコピー、又はＳ_１と部分的に重複する異なるＳ_ｉを受信する他のエージェントＡ_２、Ａ_３、．．．Ａ_ｎに対して、エージェントＡ_１が、Ｄ又はＳ_１を配信又は変更するバッド・アクターであると決定することができる。
３．Ｗは、Ｄ’、すなわちＤの第２のコピー又はサブセットがＣの同意を得ることなく作成されたことを証明するための証拠基準を満たすのに十分にロバストであることになる。これは、フォールス・ネガティブ（Ｄ’が違法でないとき、それを違法であるとして識別すること）又はフォールス・ポジティブ（Ｄ’が合法的でないとき、それを合法的として識別すること）の確率が小さくなければならないことを意味する。
４．Ｗは、バッド・アクターがＭを知っている場合でも、読取り可能でないか又は再生可能でない。
５．Ｗは、特定のＡ_ｉについて生成されるときにＤ又はＳ_ｉからの情報の損失を生じてはならない。
６．ＭがＤ中にＷを埋め込む場合、Ｗの復元は盲目的である。すなわち、Ｗは、Ｄ’とＤとが、又はそれぞれＤ及びＤ’から取られた厳密な重複ＳとＳ’とが等価である場合にのみ、Ｄを知らずにＤ’から取得され得る。
７．Ｗがそれによって作成されるプロセスは、フォールス・ネガティブを生成することなしに、ＤとＤ’との間のタプルの顕著な差（たとえば、余分のブランクスペース、データ再ソーティング、タプル削除、タプル追加）に対処するのに十分にロバストでなければならない。
８．Ｍは、ＣからのＤ_ｉが定期的に更新され、Ｄ_ｊになることを考慮に入れ、Ｄ_ｉをＤ_ｊと区別する能力を可能にしなければならない。
９．Ｍは、すぐに利用可能な計算機器を用いて計算的に実現可能でなければならない。
１０．Ｍは、Ｄ又はＳ_ｉがＤ’又はＳ_ｉ’になるとき、どんな変更がＤ又はＳ_ｉに行われたかを正確に識別する必要はないが、Ｄ’又はＳ_ｉ’の詳細な検査が、Ａ_ｉのバッド・アクター・ステータスのインジケータとしてＷについての裏付けとなる証拠を提供することができ、それを提供するべきである。

これらの要件を満たす本明細書で説明される水平方向ソルティング方法を実装することによって、データ所有者は、漏洩されたサブセットを自身のデータ・セットから発生したものとしてより頻繁に識別し、さらに、そのデータがどのＴＴＰに最初に送られたかを識別することができる。これは、データ及び受信側に一意の識別子（「ソルト」）がわずかに埋め込まれた、漏洩されたサブセット内のいくつかのデータ要素を分析することによって行われる。このソルトは、訓練されていない眼にはそれが見えないので、ソルティング機構の事前情報なしに検出され得ない。

上述のように、水平方向ソルティングは、データの有用性に影響を及ぼすことなしに、２つの構成要素、すなわち、評価される、キー・フィールド及びそのフィールド内の文字位置（「キー文字」）、並びに合法的に少なくとも２つの状態のうちの１つにあり得るコンテンツを含んでいるソルティング・フィールド（「ソルティング・フィールド」）に基づいて、ファイルに影響を及ぼす。これらの構成要素は、同じフィールド又は異なるフィールドであり得るが、しかしながら、キー文字は、ソルティング方法によって使用され得る様々な状態によって変更され得ない。理想的には、キー文字は、英数字の全範囲など、多種多様な値を有するべきである。値がより広く、より均等に分散されるほど、キー文字は、以下で説明されるように、より良くそれの目的をはたす。

ソルティング・フィールドの異なる、しかも合法的な状態は、数値の精度の変動（たとえば、１．００対１．０）、略語の使用の変動（たとえば、Ｒｏａｄ対Ｒｄ）、ピリオドなどの句読法の使用の変動（たとえば、Ｊｒ．対Ｊｒ）、敬称の使用又は不使用（たとえば、Ｊｏｈｎ Ｄｏｅ氏対Ｊｏｈｎ Ｄｏｅ）、書籍の名前におけるイタリック体などの書体変更の適用（たとえば、Ｔｈｅ Ｌｏｒｄ ｏｆ ｔｈｅ Ｒｉｎｇｓ対

）などを含み得る。データの受信側に割り当てられた一意の識別子が、２進数０又は１を表すために、ソルティング・フィールド中の状態の変動を使用することによってデータ内に隠れており、キー文字の値は、一意の識別子内の２進数０又は１のビット位置を識別する。

実例として、説明の目的で簡略化されるが、可能な受信側の極めて小さいセットのうちの１つの受信側が、２進数で値０１１０によって表される、６の一意の識別子を割り当てられ得る。受信側が、性別フィールドとセンチメートル単位の身長フィールドとを含むデータを送られ、性別フィールドが、「Ｍ」、「Ｆ」、「Ｕ」、及びブランクの可能な値を含んでおり、身長フィールドが、１００分の１センチメートルの精度をもつ値を含んでいる、と仮定する。性別フィールドにおける第１の（及び唯一の）文字が、キー文字として使用され得、「Ｍ」の値が第１のビットに、「Ｆ」が第２のビットに、「Ｕ」が第３のビットに、「 」（ブランク）が第４のビットに対応し、身長フィールドが、ソルティング・フィールドとして使用され得、１００分の１までの精度をもつ値が０の２進値を示し、１０００分の１までの精度をもつ値が１の２進値を示す。

ソルティングされたデータからの数個のレコードを検査する際に、以下が参照される。
性別、身長
Ｍ、１８３．６３
Ｆ、１７７．４２０
Ｆ、１８０．２２０
、１６６．１７
Ｍ、１７９．１１
Ｕ、１７５．１３０
Ｕ、１６８．９６０
データを検査する際に、第１のレコードが、（それが性別フィールドにおける「Ｍ」の値を有することにより）第１のビット位置に関係するソルティング・データと、（身長フィールドが１００分の１の精度を有することにより）０の値とを保持することがわかり得る。第２のレコードは、（それが性別フィールドにおける「Ｆ」の値を有することにより）第２のビット位置に関係するソルティング・データを保持し、（身長フィールドが１０００分の１までの精度を有することにより）第２のビット位置の値が１であることがわかる。レコードのさらなる分析は、０１１０のビット値をサポートし、したがって、その識別子を割り当てられた受信側にファイルが送られたことが知られる。これは単純な実例であり、ソルティングは、機構が知られると比較的容易に見つかるが、より多くのフィールドをもつ、ソルティング機構が知られていない、より大きいデータ・ファイルでは、ソルトは、手作業で識別することが非常に困難であり得る。

次に図１を参照しながら、本発明の実装形態による、ソルティングされたファイルを作成するためのシステムが、より詳細に説明され得る。ステップ１０において、キー文字及びソルティング・フィールドが、ソルティングされることになっているファイルのために決定される。上記の実例では、キー文字は性別フィールドであり、身長フィールドはソルティング・フィールドとして使用される。これは一実例にすぎず、上述されてもいるように、多くの他のタイプのフィールドが、利用可能なデータ・フィールドに応じてキー文字及びソルティング・フィールドのために使用され得る。Ａｃｘｉｏｍ社によって維持されるＩｎｆｏＢａｓｅデータベースなど、包括的な消費者データベース中に含まれているレコードなど、いくつかのタイプのデータ・レコードは、消費者又は世帯に関係する各レコードについての何百ものデータ・フィールドを含み得、そのような場合、キー文字及びソルティング・フィールドのために使用され得る多くの候補フィールドがあり、ソルティング・システムを妨害することを試みる誰かのタスクをさらに複雑にする。

ステップ１２において、受信側ＩＤがファイルに割り当てられる。この情報は、データ・プロバイダによって、ファイルに関係するデータ（作成の日付、データのタイプ、データを受信するエンティティ、及びデータについての使用など）を受信側ＩＤデータベース中の受信側ＩＤと照合するテーブル中に維持される。

ステップ１４において、ソルティングされたファイルを生じるために、ファイルがソルトを用いて変更される。このプロセスは、元のファイル中の各レコードについての反復２ステップ動作（ステップ１６）を含む。第１に、サブステップ１８において、キー文字が、ビット位置を決定するために評価される。第２に、サブステップ２０において、そのレコード中のソルティング・フィールドが、ビット位置中のビット値を反映するために更新される。ステップ１８において各レコードが処理されると、ソルティングされたファイルが完成され、ステップ２２において顧客に送られ得る。

次に図２を参照しながら、ワイルド・ファイル中のソルトの存在を決定するためのプロセスがより詳細に説明される。ステップ３０において、ファイルがデータ・プロバイダによって受信され、ステップ３２において、ファイルのフィールドが、データ・プロバイダの受信側ＩＤデータベースからの知られているキー文字及びソルティング・フィールドと比較される。これは、すべての知られている受信側ＩＤについて繰り返され、これは、バッド・アクターが複数のソルティングされたファイルをマージした場合を考慮する。ステップ３４において一致が見つからない場合、ステップ３６においてプロセスが終了し、これは、ソルトがファイル中に見つからなかったことを示す。一致が見つかった場合、ステップ３８において、ソルトのための各可能なフィールド組合せを評価するための処理が継続する。これは反復的プロセスを伴い、必要な場合、ステップ４０がファイル中の各レコードについて実行される。サブステップ４２は、ビット位置を決定するためにキー文字を評価する。サブステップ４４は、ビット位置中のビット値を決定するためにソルティング・フィールドを評価する。

ステップ４０において各レコードが処理されると、ステップ４６において、ソルトの存在又は不在を決定するための分析結果がデータ・プロバイダに返される。

次に図３を参照しながら、上記で説明されたプロセスを実装するためのコンピュータ・ネットワーク・システムのための物理的構造が次に説明され得る。（インターネットなどの）ネットワーク５０が、システムにアクセスするために使用される。仮想プライベート・ネットワーク（ＶＰＮ）５２が、「ＤＭＺ」エリア、すなわち、システムのファイアウォールの背後での進入より前に外部（ｏｕｔｓｉｄｅ）ファイルが隔離されるエリアへのセキュア接続を提供するために使用され得る。セキュア・ファイル転送プロトコル（ＳＦＴＰ）システムを使用して、ファイルがＳＦＴＰ外部ロード・バランサ５４に転送され得、ＦＴＰは、コンピュータ・ネットワーク上のクライアントとサーバとの間でコンピュータ・ファイルを転送するために使用されるよく知られているネットワーク・プロトコルである。ＵＩ／ＡＰＰ外部ロード・バランサ５６が、コンピュータ・アプリケーションによって送られるファイルを受信するために使用され得、ＡＰ外部ロード・バランサ５８が、アプリケーション・ソフトウェア間の通信を可能にするサブルーチン定義、プロトコル、及びツールを開発するためのよく知られている概念である、アプリケーション・プログラミング・インターフェース（ＡＰＩ）に従って送られるファイルを受信するために使用され得る。システムのロード・バランサは、システム中の個々のサーバがファイル要求で過負荷をかけられないことを保証する。

次にシステムのフロント・エンド・レイヤに移動すると、それ自体のＳＦＴＰサーバ復元可能ストレージ６２に関連付けられたＳＦＴＰサーバ６０が、ファイルがＤＭＺエリアから移った後、ＦＴＰによって送られたファイルを受信する。同様に、ＵＩ／ＡＰＰ内部ロード・バランサ６４が、ファイルがＤＭＺエリアを出た後、ＵＩ／ＡＰＰ外部ロード・バランサ５６からファイルを受信し、それらを１つ又は複数のＵＩ／ＡＰＰ仮想マシン（ＶＭ）６６（２つが図３に示されている）に受け渡す。サービス・エリアに移動すると、これらのサブシステムは、データをＡＰＩ内部ロード・バランサ７０に受け渡し、次いで、ＡＰＩ内部ロード・バランサ７０は、１つ又は複数のＡＰＩ ＶＭ７２（同じく、２つが図３に示されている）に情報を受け渡す。

システム・バックエンドにおいて、ＡＰＩ ＶＭ７２からのデータが、ファイル階層化推論エンジン（ＦＬＩＥ：ｆｉｌｅ ｌａｙｅｒｉｎｇ ｉｎｆｅｒｅｎｃｅ ｅｎｇｉｎｅ）内部ロード・バランサ７６に移り、ファイル階層化推論エンジン（ＦＬＩＥ）内部ロード・バランサ７６は、１つ又は複数のファイルＶＭ７８に情報を受け渡す。ＦＬＩＥシステムの目的は、入力データ・ファイルの各フィールド中のデータのタイプを自動的に識別することである。ＦＬＩＥシステムにデータを受け渡すことに加えて、ＡＰＩ ＶＭ７２は１つ又は複数のマルチテナント・データストア８４にデータを記憶するように構成された処理クラスタ及びデータストア８２にもデータを受け渡し、マルチテナント・データストア８４の各々は、データストア復元可能記憶エリア８６（各々の３つが図３に示されている）に関連付けられる。マルチテナント・データストア８４に記憶されるデータの実例としては、受信側ＩＤ及び各ファイルのウォーターマーキングに関係する他のデータがある。

本明細書で説明されるシステムを開発し、テストする際に、攻撃のいくつかのタイプが考慮された。それらのうちに含まれるのは以下である。
１．良性（ｂｅｎｉｇｎ）更新。マークされたデータが、追加されるか、削除されるか、又は更新され、これは、埋め込まれたウォーターマークを除去し得るか、又は埋め込まれたウォーターマークを検出不可能にさせ得る。
２．サブセット攻撃。データのサブセットを削除又は更新すること。
３．スーパーセット攻撃。いくつかの新しいデータ又は属性が、ウォーターマークを入れられたデータベースに追加され、これは、ウォーターマークの正しい検出に影響を及ぼすことがある。
４．共謀攻撃。この攻撃は、攻撃者が、同じファイルの複数のウォーターマークを入れられたコピーへのアクセスを有することが必要である。
これらの攻撃カテゴリーに対する有効性をテストするために、３つのテスト・シナリオが使用された。第１のシナリオでは、削除（ソルティングされたファイルからいくつかのレコードを除去することによってソルトを検出する可能性をテストすること）が採用された。これは、サブセット攻撃及び良性攻撃に関連する。第２のシナリオでは、インサート（データ・ファイルにランダムに挿入される変動する数のソルティングされていないレコードの挿入をテストすること）が採用された。これは、良性攻撃及びスーパーセット攻撃に関連する。第３のシナリオでは、混合受信側ＩＤテスト（２つ以上の受信側ＩＤから生成されたソルティングされたレコードを組み合わせることによって、ソルトを検出する可能性をテストすること）が採用された。これは共謀攻撃に関連する。

第１のシナリオでは、以下のステップが実行された。
１．２０１４年１月のＩｎｆｏＢａｓｅ １％ファイルから１００Ｋのレコードのランダム・サンプルを取る。（ＩｎｆｏＢａｓｅはＡｃｘｉｏｍ社によって維持されるファイルされた包括的な消費者データベースである。）このファイルはデータ・ファイルとして参照される。
２．完全なデータ・ファイルを水平方向にソルティングするために、１つの受信側ＩＤを使用する。
３．１０Ｋをランダムに除去することによって、データ・ファイル中のレコードの数を低減する。このファイルはワイルド・ファイルとして参照される。
４．ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。
５．受信側ＩＤビットの数が３６に等しい場合、ステップ３及び４を繰り返し、他の場合、ステップ６に進む。
６．１Ｋのレコードをランダムに除去することによって、データ・ファイル中のレコードの数を低減する。
７．ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。
８．ワイルド・ファイル中のレコードの数が１Ｋよりも大きい場合、ステップ６及び７を繰り返し、他の場合、ステップ９に進む。
９．５００のレコードをランダムに除去することによって、データ・ファイル中のレコードの数を低減する。
１０．ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。
１１．４００のレコードをランダムに除去することによって、データ・ファイル中のレコードの数を低減する。
１２．ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。

このテストの結果は、表１に示されているものであった。

１０ｋのレコードよりも大きいサイズのワイルド・ファイルの場合、識別され、一致した受信側ＩＤビットの数が３６であり、これは、６８Ｂに１つの一意性、したがって、事実上１００％の信頼区間を生じることがわかり得る。サイズ１００〜１０ｋのレコードのワイルド・ファイルの場合、識別され、一致した受信側ＩＤビットの数が、２２から３５の間であり、４ＭＭに１つの一意性、したがって、９９％を超える信頼区間を生じる。サイズ１００のレコードの極めて小さいワイルド・ファイルの場合でさえ、識別され、一致した受信側ＩＤビットの数が２１であり、２．１ＭＭに１つの一意性、したがって、約９９％の信頼区間を生じる。テスト結果は、１０Ｋが、すべての３６（すなわち０〜９、ａ〜ｚ）の受信側ＩＤビットが識別可能である最小ファイル・サイズであることを示す。すべての３６の受信側ＩＤビットが識別されるとき、３６の受信側ＩＤが６８０億に１つの一意性を表すので、ワイルド・ファイルが水平方向ソルトを含んでいる信頼区間は１００％である。ファイル・サイズが１０Ｋを下回るにつれて、受信側ＩＤビットの数が減少するが、テストは、システムが、依然として、ワイルド・ファイル中のわずか１００のレコードを用いて２１の受信側ＩＤビットを識別することができることを示す。２１の受信側ＩＤの識別は、２．１ＭＭに１つを表し、これは、９９％に近い極めて高い信頼区間を生じる。システムが罪を割り当てるために完全なファイルを処理する必要がないので、暗示は、したがって、システム処理及びスケーラビリティに関係する。システムが２１の受信側ＩＤを識別するまで、１００のバッチ中の増分レコードを処理することで十分である。

第２のシナリオでは、以下のステップが実行された。
１．所与の時間に、推定された最大数の顧客アカウントをシミュレートするために、５０００の受信側ＩＤを生成する。
２．２０１４年１月のＩｎｆｏＢａｓｅ １％ファイルから５Ｋ、５０Ｋ、及び１００Ｋのランダム・サンプルを取る。これらのファイルは、データ・ファイル１、データ・ファイル２及びデータ・ファイル３として参照される。
３．各データ・ファイルを完全に水平方向にソルティングするために、ステップ１における受信側ＩＤのうちの１つをランダムに選択する。
４．データ・ファイル１、データ・ファイル２及びデータ・ファイル３について、２０１５年１月のＩｎｆｏＢａｓｅ １％ファイルからランダムに選択された（データ・ファイル・サイズに対する）１％のソルティングされていないレコードを挿入する。これらのファイルは、ワイルド・ファイル１、ワイルド・ファイル２及びワイルド・ファイル３として参照される。
５．ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。
６．ランダムに選択された２０％、４０％、６０％及び８０％のソルティングされていないレコードを挿入することによって、ステップ３を繰り返す。
７．各区間においてワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。

このテストの結果は、表２に示されているものであった。

上記のテスト結果テーブル２から観測されるように、テスト・ファイルにわたる（３１よりも大きい）識別された高い数の受信側ＩＤビットに基づいて、テスト結果は、システムが、変動するワイルド・ファイル・サイズ及び挿入割合にわたって、ランダム・レコード挿入に対する水平方向ソルトを検出することができる、９９％を超える高い信頼性レベルを示す。

第３のシナリオでは、任意の受信側ＩＤからの未知数のソルティングされたレコードを用いて、２つ、３つ、及び５つの受信側ＩＤによって生成されたソルトを検出する能力をテストするために、以下のステップが実行された。手法は、５０００の受信側ＩＤを生成することによって５０００のクライアントがあるシナリオをシミュレートすることであった。
１．所与の時間に、推定された最大数の顧客アカウントをシミュレートするために、５０００の受信側ＩＤを生成する。
２．２０１４年１月のＩｎｆｏＢａｓｅ １％ファイルからそれぞれ１００Ｋのレコードの２つのランダム・サンプルを取る。これらのファイルは、データ・ファイル１及びデータ・ファイル２と表示される。
３．完全なデータ・ファイル１を水平方向にソルティングするために、５０００の受信側ＩＤのうちの１つを使用する。
４．完全なデータ・ファイル２を水平方向にソルティングするために、ステップ１における５０００の受信側ＩＤからランダムに選択された第２の受信側ＩＤを使用する。
５．２０１５年１月のＩｎｆｏＢａｓｅ １％ファイルからランダムに選択された１０Ｋ（元のデータ・ファイル・サイズの１０％）のソルティングされていないレコードを挿入する。
６．１００％、８０％、７０％、及び６０％の信頼区間を使用して、ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。１００％において、１又は０のいずれかである、受信側ＩＤビットは、時間の１００％、ビットが同じビットにマッピングされることによって決定される。８０％において、受信側ＩＤビットは、時間の少なくとも８０％、ビットが同じビットにマッピングされることによって決定される。残りの区間、７０％及び６０％は、同じルールに従う。
７．ステップ６における各区間について、ワイルド・ファイル中に存在する受信側ＩＤビットの数を検出し、記録する。

これらのステップを実行することの結果は、表３に示されている。

テスト結果は、ワイルド・ファイルが、２つの別個の受信側ＩＤを用いて２つのソルティングされたデータ・ファイルをマージすることの結果であったとき、システムがすべての受信側ＩＤを完全に識別することができることを示す。システムは、（５０００の中から）ワイルド・ファイル中に存在するすべての３つの受信側ＩＤを含んでいる、１０の潜在的受信側ＩＤに絞るので、極めて有効である。受信側ＩＤの数が３を超えるとき、テストは、識別されているあまりに多くの可能な受信側ＩＤがあり、これは、自動システムのために有効でないことがあることを示すが、バッド・アクターが、実生活において同じデータ・プロバイダから３つ以上のソルティングされたデータ・ファイルをマージすることは極めてありそうもないと考えられている。

このテストからの全体的結論として、水平方向ソルティングの仕組みは、レコードが挿入又は削除される場合の、並びにファイルがマージされるときの共通攻撃を容易に克服したことがわかり得る。詳細には、テスト結果は、このデジタル・ウォーターマーキング・プロセスの計算速度及び効率を増加させることをそのように行う際に、システムが、たいていの挿入／削除シナリオの下で、＞９９％の信頼性で受信側ＩＤを識別し、わずか１００のレコードを用いて約９９％の信頼性で受信側ＩＤを識別し、ワイルド・ファイルが２つの受信側ＩＤを含んでいるとき、マージ攻撃の下で１００％の信頼性で２つの受信側ＩＤを識別し、ワイルド・ファイルが３つの受信側ＩＤを含んでいるとき、すべての受信側ＩＤの９９．８％をなくすことができることを証明した。

説明される本発明の実装形態は、受信側に気づかせることなしに又はデータの有用性を妨げることなしに、所与のデータ・ファイルの受信側を決定するための一意の方法を生じることがわかり得る。さらに、システムは、スケーラブルであり、流通している潜在的に何百万もの「ワイルド」ファイルのセットの間でファイル及びそれの受信側の一意性を識別することが可能である。実際的であるために、商用等級ウォーターマーキング・システムは、１日につき何百ものファイルを処理することが可能でなければならず、これは、処理インフラストラクチャ全体が拡張可能及びスケーラブルでなければならないことを意味する。ビッグ・データのこの世代では、処理されるべきデータ・ファイルのサイズは、サイズが数メガバイトから数テラバイトまで著しく変動し、これらのファイルがシステムに流れ込む方法が、極めて予測不可能であり得る。スケーラブル・システムを構成するために、システムがこの予測不可能性を扱うようにサイズ決定されること保証するために、所与の時間における最大処理要件を推定するための予測モデルを構築しなければならない。

本明細書で説明される実装形態によるソルティング・システムは、無制限サイズのデータ・ファイル、データベース・テーブル、及びデータ・フィードをソルティングする能力を有する。しかしながら、顧客は、ファイルが配信される前にウォーターマーキングが行われるために数日又は数週間待つことができないので、処理速度も重要である。顧客は、毎日及び場合によっては一層速く、顧客の基礎をなすデータへの更新をリリースしていることがある。システムは、次のファイルの生成のサイクル時間内に、ファイルにウォーターマークを入れることが可能でなければならず、そうでなければシステムはボトルネックになり、ファイルはキューに分類され、それは、ビジネス・モデル全体を壊すことになる。したがって、実用限界生産物（ＭＶＰ：Ｍａｒｇｉｎａｌｌｙ Ｖｉａｂｌｅ Ｐｒｏｄｕｃｔ）リリースは、約２０秒中に１ＭＭのレコードの最小ソルティング・スループットを有しなければならない。ソルト検出プロセスは、ウォーターマークの存在を決定するために、ワイルド・ファイルの所与のファイル・サイズについてわずか１００のレコードを処理することを必要とする。ＭＶＰリリースにおけるウォーターマークを検出するための処理時間は数秒である。ワイルド・ファイルが盗まれたかどうかを決定するために、完全なファイルをパースすること、並びにワイルド・ファイルをマスタ・データベースと照合することが必要でないので、計算能力が低減される。このシステムを使用するソルト検出の一部として人間の対話及び検査が必要とされない。この理由で、さらなる時間及びコスト削減が実現され、エラーが低減される。

データ・ウォーターマーキングに関する調査のほとんどすべてが、データの１人又は２人の所有者及び１人又は２人のバッド・アクターについてテストされたアルゴリズムに基づいている。商用等級システムは、完全に未知のソースをもつファイルが復元される状況において、多数の顧客及び未知数のバッド・アクターについて、ウォーターマークを生成し、記憶し、検索することが可能でなければならない。たとえば、商用ウォーターマーキング会社が、それのためにファイルにウォーターマークを入れる５０００人の顧客を有することについて考える。この実例では、ウォーターマーキング会社は、盗まれたデータをファイルが含んでいないことを検証することを望む第三者からのファイルを検索する。これを決定するために、ウォーターマーキング会社は、一致を見つけるまで、各会社のウォーターマークに対してファイルをテストしなければならない。最悪の場合、ウォーターマーキング会社は、５０００回テストした後に一致を見つけず、その場合、行われ得る唯一の主張は、データがシステム中の５０００人の所有者のうちのいずれからも盗まれていないことである。いくつかの実施例によるシステムは、顧客の数に対する限定を有さず、システムは、ウォーターマーク中に表された無限個のシステム生成された一意の受信側ＩＤをサポートすることが可能である。

水平方向ソルティングは、何百万ものレコードを構文解析し、処理することとは対照的に、データ所有権を証明するために、わずか１００のランダム・レコードを必要とするにすぎない、ロバストな機構である。Ａｃｘｉｏｍの実例では、一般的なファイルは２５６ＭＭのレコードを含んでおり、この機構は、最良の場合のシナリオでは、１００／２５６ＭＭだけ（又は２．５６ＭＭ倍）検出を改善する。現在のシステム・インフラストラクチャの下で、システムがファイル中のすべてのレコードを読み取り、処理しなければならない（完全走査）、（最悪の場合の）シナリオの下で、４７５２〜１００万のレコード（表４）をもつファイル・サイズ間でソルト検出をベンチマーク評価した。ソルト検出処理の平均レートは、レコード当たり０．０００８４９８４６８１秒である。１００万のレコードをもつファイルは、より悪い場合の完全走査シナリオでは、ソルト検出のために６．９６分かかる。この機構によって適用されるソルトは見えないので、時間フレーム内の雑音の中からの抽出信号が、何らかのビジネスによって実際的であり、使用可能であると見なされる高度信号処理機構なければ、手動ソルト識別にとって実際的でなく、不可能である。

別段に明記されていない限り、本明細書で使用されるすべての技術用語及び科学用語は、本発明が属する当技術分野の当業者によって一般に理解されるものと同じ意味を有する。本明細書で説明されるものと同様の又は等価な方法及び材料が、本発明の実施又はテストにおいても使用され得るが、限られた数の例示的な方法及び材料が本明細書で説明される。はるかに多くの変更が、本明細書の発明的概念から逸脱することなく可能であることが当業者には明らかであろう。

本明細書で使用されるすべての用語は、コンテキストに一致する最も広い可能な様式で解釈されるべきである。グループ化が本明細書で使用されるとき、グループのすべての個々のメンバー並びにグループの可能なすべての組合せ及び部分組合せが個々に含まれるものとする。本明細書で範囲が明記されるとき、範囲は、範囲内のすべてのサブ範囲及び個々の点を含むものとする。本明細書で引用されるすべての参照は、本明細書の本開示との不整合がない範囲で、参照により本明細書に組み込まれる。

本発明は、例にすぎないことが意図され、添付の特許請求の範囲に記載されたような本発明の完全な範囲に限定するものではない、いくつかの好ましい実施例及び代替実施例に関して説明された。

Claims (24)

1. データ・ファイルを水平方向にソルティングするための方法であって、前記データ・ファイルが複数のレコードを含み、前記レコードの各々が複数のフィールドを含み、前記方法は、
   ａ．前記データ・ファイルの前記レコードの各々中のキー・フィールドを識別するステップであって、前記キー・フィールドが複数のキー・データ値のうちの１つを含んでいる、識別するステップと、
   ｂ．数値を前記キー・データ値の各々に関連付けるステップと、
   ｃ．前記データ・ファイルの前記レコードの各々中のソルティング・フィールドを識別するステップと、
   ｄ．前記データ・ファイル中の少なくとも１つのレコードについて、前記キー・フィールド中の前記キー・データ値に関連付けられた前記数値に基づいて、ソルトを用いて前記ソルティング・フィールドをソルティングするステップであって、前記ソルティング・フィールドが、前記ソルティング・フィールド中のソルティング・フィールド値に関連付けられた意味が不変であるような様式で変更される、ソルティングするステップと
   を含む、方法。
2. 前記ソルティング・フィールドをソルティングする前記ステップにおいて変更された前記レコードの各々を含む、ソルティングされたデータ・ファイルを出力するステップをさらに含む、請求項１に記載の方法。
3. 前記ソルティング・フィールドが、少なくとも２つの別個の状態のうちの１つを含み得、さらに、前記ソルティング・フィールドの前記別個の状態が、前記ソルティング・フィールド中の前記ソルティング・フィールド値の前記意味に影響を及ぼさないようなものである、請求項１に記載の方法。
4. 前記キー・フィールドと前記ソルティング・フィールドとが同等である、請求項１に記載の方法。
5. 前記キー・フィールドと前記ソルティング・フィールドとが別個のフィールドである、請求項１に記載の方法。
6. 前記キー・フィールドが英数字のセットのうちの１つを含む、請求項１に記載の方法。
7. 前記ソルティング・フィールドをソルティングする前記ステップが、数値の精度における複数の変動のうちの１つを割り当てるステップを含む、請求項１に記載の方法。
8. 前記ソルティング・フィールドをソルティングする前記ステップが、略語の使用における複数の変動のうちの１つを割り当てるステップを含む、請求項１に記載の方法。
9. 前記ソルティング・フィールドをソルティングする前記ステップが、句読点の使用を変動させるステップを含む、請求項１に記載の方法。
10. 句読点の前記使用を変動させる前記ステップが、ソルトとしてピリオドを含むこと又は含まないことのいずれかを行うステップを含む、請求項９に記載の方法。
11. 前記ソルティング・フィールドをソルティングする前記ステップが、敬称を含むこと又は含まないことのいずれかを行うステップを含む、請求項１に記載の方法。
12. 前記ソルティング・フィールドをソルティングする前記ステップが、書体変更を適用すること又は適用しないことのいずれかを行うステップを含む、請求項１に記載の方法。
13. 前記キー値のうちの１つに関連付けられた前記数値の各々が２進数である、請求項１に記載の方法。
14. 前記データ・ファイルの前記レコードのうちの少なくとも１つ中の、前記キー・データ・フィールド中の前記複数のキー・データ値のうちの少なくとも１つが、ブランク値である、請求項１に記載の方法。
15. 前記ソルティング・フィールドをソルティングする前記ステップが、前記データ・ファイル中のデータの値を顧慮せずに実行される、請求項１に記載の方法。
16. ａ．前記データ・ファイルの前記レコードの各々中の第２のキー・フィールドを識別するステップであって、前記第２のキー・フィールドが複数の第２のキー・データ値のうちの１つを含んでいる、識別するステップと、
    ｂ．第２の数値を前記第２のキー・データ値の各々に関連付けるステップと、
    ｃ．前記データ・ファイルの前記レコードの少なくともサブセット中の第２のソルティング・フィールドを識別するステップと、
    ｄ．前記データ・ファイル中のレコードの前記サブセット中の少なくとも１つのレコードについて、前記第２のキー・フィールド中の前記第２のキー・データ値に関連付けられた前記第２の数値に基づいて、第２のソルトを用いて前記第２のソルティング・フィールドをソルティングするステップであって、前記第２のソルティング・フィールドが、前記第２のソルティング・フィールド中の第２のソルティング・フィールド値に関連付けられた意味が不変であるような様式で変更される、ソルティングするステップと
    をさらに含む、請求項１に記載の方法。
17. 前記ソルティング・フィールドをソルティングする前記ステップと前記第２のソルティング・フィールドをソルティングする前記ステップとにおいて変更された前記レコードの各々を含む、ソルティングされたデータ・ファイルを出力するステップをさらに含む、請求項１６に記載の方法。
18. ａ．受信側ＩＤを前記データ・ファイルに割り当てるステップと、
    ｂ．前記受信側ＩＤを用いて受信側ＩＤデータベースを更新するステップであって、前記受信側ＩＤが、前記データ・ファイル、前記キー文字、及び前記ソルティング・フィールドのための識別情報を用いて、前記受信側ＩＤデータベース中に関連付けられる、更新するステップと
    をさらに含む、請求項１に記載の方法。
19. 前記データ・ファイルのための前記識別情報が前記データ・ファイルについて一意である、請求項１８に記載の方法。
20. 前記データ・ファイルのための前記識別情報が、前記データ・ファイルの単一の受信側に送られたどのデータ・ファイルについても同じである、請求項１８に記載の方法。
21. 単一のソースから発信した複数のデータ・ファイルを水平方向にソルティングするための方法であって、前記データ・ファイルが各々、複数のレコードを含み、前記レコードの各々が複数のフィールドを含み、前記方法は、
    ａ．前記データ・ファイルの各々の前記レコードの各々中のキー・フィールドを識別するステップであって、前記キー・フィールドが複数のキー・データ値のうちの１つを含んでいる、識別するステップと、
    ｂ．数値を前記キー・データ値の各々に関連付けるステップと、
    ｃ．前記データ・ファイルの各々の前記レコードの各々中のソルティング・フィールドを識別するステップと、
    ｄ．前記データ・ファイルの各々中の少なくとも１つのレコードについて、前記キー・フィールド中の前記キー・データ値に関連付けられた前記数値に基づいて、ソルトを用いて前記ソルティング・フィールドをソルティングするステップであって、前記ソルティング・フィールドが、前記ソルティング・フィールド中のソルティング・フィールド値に関連付けられた意味が不変であるような様式で変更される、ソルティングするステップと
    を含む、方法。
22. ワイルドデータ・ファイルが漏洩されたデータ・ファイルであるかどうかを決定するための方法であって、前記ワイルドデータ・ファイルが複数のレコードを含み、前記レコードの各々が複数のフィールドを含み、前記方法は、
    ａ．受信側ＩＤデータベースに記憶された受信側ＩＤレコードについて、前記受信側ＩＤに関連付けられた前記受信側ＩＤデータベースから、キー・フィールド、数値、及びソルティング・フィールドを読み取るステップと、
    ｂ．前記データ・ファイルの前記レコードのうちの少なくとも１つ中の前記キー・フィールドを識別するステップであって、前記キー・フィールドが複数のキー・データ値のうちの１つを含んでいる、識別するステップと、
    ｃ．前記数値を対応するキー・データ値に関連付けるステップと、
    ｄ．前記データ・ファイルの前記レコードのうちの少なくとも１つ中の前記ソルティング・フィールドを識別するステップと、
    ｅ．前記データ・ファイル中の前記レコードのうちの少なくとも１つについて、前記キー・フィールド中の前記キー・データ値に関連付けられた前記数値に基づいて、前記ソルティング・フィールド中のソルトの存在について検査するステップと、
    ｆ．前記ソルトが見つけられたかどうかのインジケータを返すステップと、前記インジケータを前記受信側ＩＤに関連付けるステップと
    を含む、方法。
23. 前記ステップの各々が、前記受信側ＩＤデータベース中の複数の受信側ＩＤについて繰り返される、請求項２２に記載の方法。
24. 前記ステップの各々が、前記受信側ＩＤデータベース中の前記受信側ＩＤのすべてについて繰り返される、請求項２２に記載の方法。