JP2022551780A - ネットワーク上の複数のノード間でクエリの匿名検証を提供するシステムおよび方法 - Google Patents

Abstract

ネットワーク内の複数のノード間でクエリの匿名検証を提供するシステムおよび方法であり、サポートノードにおいてリクエスタノードからクエリを受信し、クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの一方向性関数表現を含み、サポートサーバにおいて少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現を受信し、サポートサーバによって、リクエスタノードからのクエリを、情報の少なくとも１つのデータポイントの一方向性関数表現と比較し、アグリゲータサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定し、一致する結果をリクエスタノードに出力する。【選択図】図２

Description

［関連出願の相互参照］
本願は、２０１９年３月２５日に出願された米国特許仮出願第６２／８２３，０２８号の優先権を主張するものであり、この仮出願はその全体が参照により本明細書に組み込まれる。

［技術分野］
本発明は、データ検証の分野である。特に、本発明は、ネットワーク内の複数のノード間でクエリの匿名検証を提供することを指向している。

今日、オンラインビジネスは、強固な不正防止の必要性と、顧客に迅速、シームレス、かつユーザフレンドリな体験を提供する必要性とのバランスをとるという、深刻な課題に直面している。この課題は、このリスクの管理に個人識別情報（ＰＩＩ）データの使用が必要な場合に強調される。本明細書で理解されるＰＩＩデータとは、個人のアイデンティティを識別または追跡するために使用できる情報のことで、単独で、または他のデータセットと組み合わせて、特定の個人にリンクしているか、リンク可能な他の個人情報または識別情報と組み合わせて使用することができる。このデータは非常に機密性の高いものであるため、不完全なものが多い。その結果、企業がデータを持たない場合、正当な顧客を誤ってリスクが高いと分類してしまい、ビジネスの損失や顧客離れにつながる可能性がある。また、合成ＩＤを作成したり、盗まれたＩＤを使用したりする詐欺師の被害に遭うケースもある。このような詐欺師は、高いコストや摩擦なしに本物のＩＤと合成ＩＤを見分ける簡単な方法がないことを利用して、同じＩＤが他のオンラインサービスで既に悪質であると指摘されている場合でも、企業に高い損失をもたらす。どちらの場合も、企業は、高い摩擦を与えずに顧客のアイデンティティを確認するという課題に直面している。

この問題はさらに、本人確認にとどまらず、クレジットカード番号、銀行口座、ＩＰアドレス、電子メールアドレスなど、他のセンシティブな資産や個人を特定できる資産にまで及ぶ。さらに、これらの資産の中には、顧客の生涯を通じて変化する可能性があるものもあるため、企業は頻繁に更新される顧客記録を提供する仕組みを必要としている。特に問題となるのは、これらの資産を特定の人物や所有者に結びつけることである。例えば、支払いを行った人が提供されたクレジットカードの所有者であるかどうかを知ることができる。

この課題を解決する可能性があるのは、オンラインビジネスにおいて、信頼できる顧客に関するデータを相互に共有することで、より良いリスク管理、ビジネスの迅速な成長、そして顧客に優れたユーザ体験を提供することができる。すべてのオンラインビジネスは、より多くのデータにアクセスし、理想的には他の企業とデータを共有することで利益を得ることができるが、現在はいくつかの課題に直面しており、このようなコラボレーションを妨げている。

プライバシ：両規制（例：ＧＤＰＲ ２０１８、ＵＳ Ｐｒｉｖａｃｙ Ａｃｔ １９７４、Ｃａｌｉｆｏｒｎｉａ Ｃｏｎｓｕｍｅｒ Ｐｒｏｔｅｃｔｉｏｎ Ａｃｔ（ＣＣＰＡ）など。）および世論は、オンラインビジネスがデータのプライバシとセキュリティの保護に取り組むことを求めている。その結果、オンラインビジネスでは、データを共有したり、管理されたデータウェアハウスの外にデータをエクスポートしたりすることに消極的で、しばしば禁止されている。データの共有は、犯罪捜査や不正行為が確認された場合など、特定のケースでのみ認められており、そのような場合でも、オンラインビジネスではデータを共有する相手について非常に慎重になっている。データを共有する場合、これらの企業は、第三者のセキュリティ手段とポリシー、および共有されたデータの使用に関して責任を負う可能性がある。例えば、Ｆａｃｅｂｏｏｋ（登録商標）は５０億ドルの罰金を科せられ、悪名高いケンブリッジ・アナリティカのデータ流出に関与したことで、世間からも責任を問われた。

コラボレーション対競争：データは企業にとって「新しい石油」とも言われ、企業の競争力の源泉となっている。そのため、企業はお互いに直接データを共有することを好まず、自社のデータを完全に管理したいと考えている。しかし、潜在的なビジネス上の利益が大きい場合、企業は他の企業や競合他社とデータを共有することに同意する。通常、信頼できる第三者を通じてデータを共有するが、その際、データのソースには匿名性が確保されるため、企業秘密が守られることがある（例：ブラックリストに載ったクレジットカードの共有）。

ＩＤデータ検証問題に対する現在のソリューションは、以下のカテゴリのいずれかに分類される。

データブローカ：オンラインソースからデータを収集・集計し、および／または顧客関係を保有する企業からデータを購入する企業。このデータは後に、意思決定プロセスに使用する他の企業に販売される。

特殊なデータベンダ：特定のデータセットを集約して配布する企業で、通常、生データに加えてデータ品質の検証や衛生管理、各資産のリスクスコアリングなどを提供している。一般的な例としては次のようなものがある：メールアドレスのＥｍａｉｌａｇｅ、ＩＰ－ＧｅｏｌｏｃａｔｉｏｎデータのＭａｘＭｉｎｄとＤｉｇｉｔａｌ Ｒｅｓｏｌｖｅ、電話関連情報のＮｅｕｓｔａｒなど。

データビューロ：顧客の個人データを保有するために政府のライセンスに基づいて運営されている組織。ほとんどの場合、報告されたデータを収集し、計算されたクレジットスコアを提供することで、クレジット申請をサポートするために作成される（例：Ｅｘｐｅｒｉａｎ、ＦＩＣＯ、Ｅｑｕｉｆａｘ、ＴｒａｎｓＵｎｉｏｎ、Ｉｎｎｏｖｉｓ、ＰＲＢＣなど）。

データマーケットプレイス：データベンダとデータコンシューマとを結びつける。マーケットプレイスは、データへのアクセスや統合を簡素化することに重点を置いているが、付加価値を提供するものではない。

不正管理ツール：複数の企業のデータを利用して、アカウントやトランザクションのリスクスコアを算出するツール。

既存のソリューションは長年にわたって使用されてきたが、いずれもいくつかの本質的な欠点があり、市場での有効性と実行可能性を制限している。

断片化／網羅性：ＰＩＩデータの性質上、ほとんどのソリューションは特定の国や地域のデータしか提供していない。グローバルなビジネスでは、高いカバレッジと精度を実現するために、多くのベンダを探して統合する必要がある。

信頼度および系統性：ほとんどのデータベンダやアグリゲータは、データがどのように収集されたか、またデータ対象者から適切な許可を得たかどうかについて、限られた、あるいは全く情報を提供していない。これは、例えば、意図しないプライバシの侵害や顧客の信頼の失墜につながる可能性があり、また、データの正確性や信頼度が低い場合には、詐欺被害の拡大につながる可能性もある。

プライバシの侵害：既存のソリューションでは、リクエスタと検証サービスプロバイダとの間でデータ交換が必要である。これにより、個人情報が流出し、顧客のプライバシが侵害される可能性がある。共通のデータ交換を分析してみると、つぎのようである：

（データの）リクエスタ：企業は通常、検証目的でベンダとデータを共有する正当な理由を持っているが、ベンダがデータをどのように使用するかをコントロールすることはできない。これにより、ベンダはデータを収集した当初の目的を超えてデータを収集・使用する可能性がある。これにより、リクエスタの責任がさらに重くなり、プライバシの侵害につながる可能性がある。

（データの）プロバイダ：ユーザが自らの意思で、あるいは時には無意識のうちに、ユーザの個人情報にアクセスすることを承認した企業、ビジネス、サービスは、データブローカなど、ＰＩＩデータの収集源となることが多い。同様に、オンラインユーザは、ウェブサイトでアカウントを登録するためにＰＩＩの提供を求められることがよくある。その上で、データ収集や、データを保存することによるメリット（毎回パスワードを入力する必要がない、個人広告に効果があるなど）をユーザに伝える。しかし、これらの承認を受けた企業は、収集・保存したＰＩＩをデータブローカに販売することがあり、ほとんどの場合、ユーザの知識や同意なしに販売している。企業は、現在受け取っているデータが、必要なユーザ許可を得て取得されたものかどうかを確認できないことが多い。

規制上の問題：独立した情報源：規制上、一部のデータ要素は複数の独立した情報源によって検証される必要があり得る。しかし、実際のデータのソースは不明であるため、企業は２つの異なるサードパーティベンダに対してデータを検証しているかもしれないが、実際には、両方が同じソースからデータを購入している場合、１つのソースからのデータしか検証していないことになる。

シングル・ポイント・オブ・フェイル（単一障害点）：データの価値が高まるにつれて、このデータへの依存度も高まる。企業は、いつでもサービスを停止できる単一のソースに依存することで、重要なビジネスプロセスを正常に完了できなくなることへの懸念を強めている。

そこで必要となるのが、個人を特定できる情報（ＰＩＩ）の基本的なプライバシを損なうことなく、ユーザが他のユーザのデータを使用して、個人、支払手段、または企業に関するセンシティブでプライベートな情報を検証できるようなソリューションである。

本発明の一実施形態は、ネットワーク内の複数のノード間でクエリの匿名検証を提供する方法であり、複数のノードのうちの少なくとも１つの他のノードによるクエリの検証のために、第１のサーバにおいて、ネットワーク内のリクエスタノードからクエリを受信するステップであって、クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの符号化された表現を含み、符号化された表現は、複数のシェアの第１のセットに分割される、ステップと、第１のサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの符号化された表現を受信するステップであって、少なくとも１つのバリデータノードからの符号化された表現は、複数のシェアの第２のセットに分割される、ステップと、複数のサポートサーバによって、リクエスタノードからの複数のシェアの第１のセットと、少なくとも１つのバリデータノードの複数のシェアの第２のセットとを比較するステップと、第２のサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定するステップと、一致する結果をリクエスタノードに出力するステップと、を含む。

いくつかの実施形態では、符号化された表現は、ワンタイム暗号化を含み、ワンタイム暗号化は、リクエスタノードおよび少なくとも１つのバリデータノードによって使用される。いくつかの実施形態では、複数のシェアの第１のセットおよび第２のセットは、それぞれ各ノードに対してランダムに生成される。いくつかの実施形態では、比較するステップは、複数のシェアの第１のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信するステップと、複数のシェアの第２のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信するステップと、各サポートサーバにおいて、リクエスタノードから受信した値と、少なくとも１つのバリデータノードから受信した同等の値とを照合するステップと、をさらに含む。

いくつかの実施形態では、決定するステップは、第２のサーバによって、複数のサポートサーバの各々からの結果の値のセットを集約するステップと、複数のサポートサーバからの結果の値のセットを統合するステップと、統合に基づいて、合計がゼロになるかどうかを識別するステップと、をさらに含む。いくつかの実施形態では、少なくとも１つのデータフィールドは、顧客の身元に関する。いくつかの実施形態では、ネットワークは、クローズドネットワークであり、クローズドネットワークの各ノードは、クローズドネットワークの事前承認されたメンバである。

いくつかの実施形態では、複数のサポートサーバの各々は、一時的ノードを含み、一時的ノードは、持続的メモリまたはストレージ容量を含まない。本発明のいくつかの実施形態は、第２のサーバによって、一致した結果に関連する信頼度スコアを計算するステップと、一致した結果とともに信頼度スコアを出力するステップと、をさらに含む。

ネットワーク内の複数のノード間でクエリの匿名検証を提供するためのさらなる方法は、ネットワーク内のサポートノードにおいて、ネットワーク内のリクエスタノードからクエリを受信するステップであって、クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの一方向性関数表現を含む、ステップと、サポートサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現を受信するステップと、サポートサーバによって、リクエスタノードからのクエリを、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現と比較するステップと、アグリゲータサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定するステップと、一致する結果をリクエスタノードに出力するステップと、を含む。

上記の方法の実施形態にしたがったシステムが提供されてよい。これらのおよび他の側面、特徴、および利点は、本発明の特定の実施形態に関する以下の説明を参照して理解されるであろう。

本発明とみなされる主題は、明細書の最後の部分で特に指摘され、明確に主張されている。しかし、本発明は、その目的、特徴および利点とともに、組織および操作方法の両方について、添付の図面と合わせて以下の詳細な説明を参照することにより、最もよく理解することができる。本発明の実施形態は、限定するものではなく例示として添付図面の図に示されており、その中で同様の参照数字は、対応する、類似する、または同様の要素を示している。

図１は、本発明の少なくとも１つの実施形態による、ネットワーク内の複数のノード間でクエリの匿名検証を提供するためのシステム１００の構成例を示す高レベル線図である。 図２は、システム１００の構成例の高レベルシステムアーキテクチャの概要を示す。 図３は、本発明の少なくとも１つの実施形態による、システム１００（図１および図２参照）のエッジサーバ１７５の高レベルの構成例を示す。 図４は、本発明の少なくとも１つの実施形態による、ネットワーク内の複数のノード間でクエリの匿名検証を提供するための方法４００のフロー線図である。 図５は、本発明の少なくとも１つの実施形態による、個々のデータフィールドを検証するための方法５００のフロー線図である。

図を分かりやすくするために、図に示されている要素は必ずしも正確に描かれているわけではなく、縮尺も決まっていない。例えば、いくつかの要素の寸法を他の要素に比べて誇張してわかりやすくしたり、複数の物理的コンポーネントを１つの機能ブロックや要素に含めたりすることができる。さらに、適切と思われる場合には、対応するまたは類似の要素を示すために、図の間で参照数字を繰り返すことができる。

以下の説明では、本発明のさまざまな態様について説明する。説明のために、本発明の完全な理解を得るために、具体的な構成と詳細を示す。しかし、本発明は、ここに示された特定の詳細がなくても実施してよいことも、当業者には明らかであろう。さらに、本発明を不明瞭にしないために、よく知られた特徴を省略または簡略化してよい。

本発明の実施形態は、この点に関して限定されないが、例えば、「処理」、「計算」、「算出」、「決定」、「確立」、「分析」、「確認」などの用語を用いた議論は、コンピュータのレジスタおよび／またはメモリ内の物理的（例えば、電子的）量として表されるデータを、コンピュータのレジスタおよび／またはメモリ、またはプロセッサによって実行されるとプロセッサに動作や処理を行わせる命令を格納することができる他の情報の非一時的なプロセッサ読み取り可能な記憶媒体内の物理的量として同様に表される他のデータへ、操作および／または変換する、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、または他の電子コンピューティングデバイスの操作および／またはプロセスを指す場合がある。本発明の実施形態は、この点に関して限定されないが、本明細書で使用される「複数」および「複数」という用語は、例えば、「複数」または「２つ以上」を含み得る。本明細書では、２つ以上のコンポーネント、デバイス、エレメント、ユニット、パラメータなどを説明するために、「複数」または「複数」という用語が使用され得る。本明細書で使用されるセットという用語は、１つまたは複数のアイテムを含み得る。明示的に述べられていない限り、本明細書に記載されている方法の実施形態は、特定の順序またはシーケンスに拘束されない。さらに、説明された方法の実施形態またはその要素のいくつかは、同時に、同じ時点で、または同時進行で発生または実行されてよい。

本発明のいくつかの実施形態では、データ検証への新しいアプローチが提供され、企業が自分のデータを管理し、顧客のプライバシを保護しながら、お互いのデータ（例えば、個人、支払手段、企業などに関する機密情報やプライベートな情報）を検証することができる。これを実現するために、本発明のいくつかの実施形態では、分散化されたピアツーピアのプライベートデータ検証ネットワークが確立され、企業、個人などの各参加メンバ（以下、「要求側」、「要求側メンバ」、または「リクエスタ」）は、顧客から受信したデータをネットワークの全知識を用いて検証することができる。分散型フレームワークとして、すべてのデータはその発信元に保管され、発信元と検証者の身元確認を含め、検証交換の一環として個人データが第三者と共有、コピー、複製されることはない。データの検証は、各データ要素が完全に匿名化され、どの当事者も自分以外のＰＩＩデータに触れることがないような、安全でプライベートな方法で行い得る。リクエスタは、顧客から受信したデータ一式が有効であることの証明を受け取る一方で、ネットワークオペレータを含む他の当事者は、リクエスタが問い合わせた顧客の身元について何も知ることはない。また、他の参加メンバは、リクエスタの身元や、有効な一致が見つかったことさえも知ることができない。

データ検証ネットワークに参加しているメンバは、他のメンバからの検証データの問い合わせをサポートしたり、ネットワークにリクエストしたりすることができ、ネットワーク全体で利用可能なデータの世界を常に拡大することができる。

この新しいパラダイムにより、メンバ企業は、プライバシや規制上の要件を満たしながら、ＩＤ詐欺のリスクとエクスポージャをより良く軽減し、偽陽性率を大幅に低減することができる。ネットワークのメンバは、計算やデータの検証に参加し、いくつかの実施形態では、肯定的な一致に対して報酬を受け取ってよい。

図１は、本発明の少なくとも１つの実施形態による、ネットワーク内の複数のノード間でクエリの匿名検証を提供するためのシステム１００の構成例を示す高レベル線図である。システム１００は、ネットワーク１０５を含み、これは、プライベート運用ネットワーク、インターネット、１つ以上のテレフォニーネットワーク、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）を含む１つ以上のネットワークセグメント、１つ以上のワイヤレスネットワーク、またはこれらの組み合わせを含んでよい。いくつかの実施形態では、システム１００は、本発明の１つまたは複数の実施形態にしたがって構築されたシステムサーバ１１０を含んでよい。いくつかの実施形態では、システムサーバ１１０は、スタンドアローンのコンピュータシステムであってよい。他の実施形態では、システムサーバ１１０は、ネットワーク１０５を介して通信する、動作可能に接続されたコンピューティングデバイスの分散型ネットワークを含んでよい。したがって、システムサーバ１１０は、コンピュータ、より具体的には、据置型デバイス、モバイルデバイス、端末、および／またはコンピュータサーバ（以下、総称して「コンピューティングデバイス」という、などの他の複数の処理マシンを含んでよい。これらのコンピューティングデバイスとの通信は、例えば、ネットワーク１０５にアクセス可能なさらなるマシンを介して、直接的または間接的に行うことができる。

システムサーバ１１０は、コンピューティングデバイス、他のリモートデバイス、またはコンピューティングネットワークと通信し、電子情報を受信、送信、および保存し、本明細書でさらに説明するように要求を処理することができる任意の適切なコンピューティングデバイスおよび／またはデータ処理装置であってよい。したがって、システムサーバ１１０は、ラップトップ、デスクトップ、ワークステーション、パーソナルデジタルアシスタント、サーバ、プレドサーバ、エッジャサーバ、メインフレーム、および本明細書に記載されているシステムおよび方法を採用することができる他の適切なコンピュータおよび／またはネットワークまたはクラウドベースのコンピューティングシステムなど、さまざまな形態のデジタルコンピュータを表すことが意図されている。

いくつかの実施形態では、システムサーバ１１０は、システム１００の動作を可能にする役割を果たすさまざまなハードウェアおよびソフトウェアコンポーネントに動作可能に接続されるサーバプロセッサ１１５を含んでよい。サーバプロセッサ１１５は、本明細書でより詳細に説明した本発明の実施形態のさまざまな機能に関連するさまざまな動作を実行する命令を実行する役割を果たしてよい。サーバプロセッサ１１５は、特定の実装に応じて、１つまたは複数のプロセッサ、中央処理装置（ＣＰＵ）、グラフィックス処理装置（ＧＰＵ）、マルチプロセッサコア、またはその他のタイプのプロセッサであってよい。

システムサーバ１１０は、ネットワーク１０５に接続されたさまざまな他の装置と通信インターフェース１２０を介して通信するように構成されてよい。例えば、通信インターフェース１２０は、モデム、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）、統合ネットワークインターフェース、無線周波数送受信機（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線接続、セルラー、ＮＦＣ（Ｎｅａｒ－Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）プロトコル、衛星通信送受信機、赤外線ポート、ＵＳＢ接続、および／または、システムサーバ１１０を他のコンピューティングデバイスおよび／またはプライベートネットワークやインターネットなどの通信ネットワークに接続するための他の任意のそのようなインターフェースを含んでよいが、これらに限定されない。

特定の実装では、サーバメモリ１２５は、サーバプロセッサ１１５によってアクセス可能であってよく、それにより、サーバプロセッサ１１５が、１つ以上のソフトウェアモジュール１３０の形でメモリおよび／またはストレージに格納された、コードなどの命令を受け取り、実行することができ、各モジュールは１つ以上のコードセットを表す。ソフトウェアモジュール１３０は、本明細書に開示されたシステムおよび方法の態様のための操作を実行するために、サーバプロセッサ１１５で部分的または全体的に実行されるコンピュータプログラムコードまたは命令セットを有する１つまたは複数のソフトウェアプログラムまたはアプリケーション（「サーバアプリケーション」と総称する）を含んでよく、１つまたは複数のプログラミング言語の任意の組み合わせで書かれていてよい。サーバプロセッサ１１５は、例えば、コードまたはソフトウェアを実行することによって、本発明の実施形態を遂行するように構成されてよく、本明細書に記載されているように、モジュールの機能を実行してよい。例示的なソフトウェアモジュールは、本明細書に記載されているように、通信モジュール、およびその他のモジュールを含んでよい。通信モジュールは、サーバプロセッサ１１５によって実行されて、システムサーバ１１０と、例えば、本明細書に記載されているサーバデータベース１３５、ユーザデバイス（複数可）１４０、および／またはエッジサーバ（複数可）１７５など、システム１００のさまざまなソフトウェアおよびハードウェアコンポーネントとの間の通信を容易にし得る。

もちろん、いくつかの実施形態では、サーバモジュール１３０は、本発明のこれらの機能性および他の機能性を実現するために実行され得る、より多くのまたは少ない実際のモジュールを含んでよい。したがって、本明細書に記載されているモジュールは、本発明のいくつかの実施形態にしたがったシステムサーバ１１０のさまざまな機能性を代表するものであることが意図されている。本発明のさまざまな実施形態にしたがって、サーバモジュール１３０は、スタンドアローンのソフトウェアパッケージとしてシステムサーバ１１０上で完全に実行されてよいし、システムサーバ１１０上で一部、ユーザデバイス１４０およびエッジサーバ１７５のうちの１つ以上で一部実行されてよいし、ユーザデバイス１４０および／またはエッジサーバ１７５上で完全に実行されてよいことに留意すべきである。

サーバメモリ１２５は、例えば、ランダムアクセスメモリ（ＲＡＭ）や、その他の適切な揮発性または不揮発性のコンピュータ可読記憶媒体であってよい。また、サーバメモリ１２５は、特定の実装に応じてさまざまな形態をとることができるストレージを含んでよい。例えば、ストレージには、ハードドライブ、フラッシュメモリ、書き換え可能な光ディスク、書き換え可能な磁気テープ、またはこれらの組み合わせなど、１つまたは複数のコンポーネントまたはデバイスが含まれ得る。さらに、メモリやストレージは固定されていても、取り外し可能であっても構わない。さらに、メモリおよび／またはストレージは、システムサーバ１１０にローカルに配置されてよく、リモートに配置されてよい。

本発明のさらなる実施形態によれば、システムサーバ１１０は、例えば、ネットワーク１０５を介して直接的または遠隔的に、１つまたは複数のデータベース（複数可）１３５に接続されてよい。データベース１３５は、本明細書に記載されているようなメモリ構成のいずれかを含んでよく、システムサーバ１１０と直接または間接的に通信してよい。いくつかの実施形態では、データベース１３５は、本発明の１つまたは複数の側面に関連する情報を格納してよい。

本明細書で説明したように、ネットワーク１０５上の、またはネットワーク１０５に接続されたコンピューティングデバイスの中には、１つまたは複数のユーザデバイス１４０が含まれ得る。ユーザデバイス１４０は、任意の標準的なコンピューティングデバイスであってよい。本明細書で理解されるように、１つまたは複数の実施形態にしたがって、コンピューティングデバイスは、デスクトップコンピュータ、キオスクおよび／またはその他のマシンなどの据え置き型コンピューティングデバイスであってよく、各々が、一般に、さまざまな機能を実装するコードを実行するように構成された、ユーザプロセッサ１４５などの１つまたは複数のプロセッサと、ユーザメモリ１５５などのコンピュータ読み取り可能なメモリと、ネットワーク１０５に接続するためのユーザ通信インターフェース１５０と、ユーザモジュール１６０などの１つまたは複数のユーザモジュールと、入力デバイス１６５などの１つまたは複数の入力デバイスと、出力デバイス１７０などの１つまたは複数の出力デバイスとを備えている。例えば、入力デバイス１６５のような典型的な入力装置は、キーボード、ポインティングデバイス（例えば、マウスまたはデジタル化されたスタイラス）、ウェブカメラ、および／またはタッチセンシティブなディスプレなどを含んでよい。代表的な出力装置として、例えば出力デバイス１７０は、プリンタ、ディスプレ、スピーカ、プリンタなどの１つ以上を含んでよい。

いくつかの実施形態では、ユーザモジュール１６０は、ユーザデバイス１４０のさまざまな機能性を提供するために、ユーザプロセッサ１４５によって実行されてよい。特に、いくつかの実施形態では、ユーザモジュール１６０は、ユーザデバイス１４０のユーザが対話することができるユーザインターフェースを提供してよく、特に、システムサーバ１１０と通信してよい。

加えて、または代わりに、コンピューティングデバイスは、モバイル電子機器（「ＭＥＤ」）であってよい。このモバイル電子機器は、上述の据え置き型デバイスと同様のハードウェアコンポーネントを有し、本明細書に記載されたシステムおよび／または方法を具現化できるものとして当技術分野では一般的に理解されているが、ワイヤレス通信回路、ジャイロスコープ、慣性検出回路、ジオロケーション回路、タッチ感度などのコンポーネントをさらに含むことができる他のセンサも含まれる。典型的なＭＥＤの非限定的な例としては、スマートフォン、パーソナルデジタルアシスタント、タプレットコンピュータなどがあり、それらは、セルラーネットワークやＷｉ－Ｆｉ（登録商標）ネットワークを介して、あるいはＢｌｕｅｔｏｏｔｈ（登録商標）などの通信プロトコルを使用して通信してよい。キーボード、マイク、加速度計、タッチパネル、照度計、デジタルカメラ、さらに機器を装着するための入力端子などがあるが、これらの入力機器は、従来のＭＥＤには存在しない。

いくつかの実施形態では、ユーザ機器１４０は、「ダミー」端末であってよく、それによって、処理およびコンピューティングがシステムサーバ１１０で実行されてよく、その後、情報は、表示および／または基本的なデータ操作のために、サーバ通信インターフェース１２０を介してユーザ機器１４０に提供されてよい。いくつかの実施形態では、１つのデバイス上に存在する、および／または、１つのデバイス上で実行するように描かれたモジュールは、追加的または代替的に、別のデバイス上に存在してよく、および／または、別のデバイス上で実行してよい。例えば、いくつかの実施形態では、システムサーバ１１０上に存在し実行するものとして図１に描かれているサーバモジュール１３０の１つまたは複数のモジュールが、追加的または代替的にユーザデバイス１４０上に存在してよくおよび／または実行してよい。同様に、いくつかの実施形態では、図１でユーザデバイス１４０上に存在し実行されるものとして描かれているユーザモジュール１６０の１つ以上のモジュールが、追加的または代替的にシステムサーバ１１０上に存在してよくおよび／または実行してよい。

同様に、いくつかの実施形態では、エッジサーバ１７５は、「ダミー」端末であってもよく、それによって、処理およびコンピューティングがユーザデバイス１４０で実行されてよく、その後、情報は、表示および／または基本的なデータ操作のために、ユーザ通信インターフェース１５０を介してエッジサーバ１７５に提供されてよい。いくつかの実施形態では、１つのデバイス上に存在する、および／または、１つのデバイス上で実行するように描かれたモジュールは、追加的または代替的に、別のデバイス上に存在してよくおよび／または別のデバイス上で実行してよい。例えば、いくつかの実施形態では、図１でユーザデバイス１４０上に存在し実行されるものとして描かれているユーザモジュール１６０の１つまたは複数のモジュールが、追加的または代替的にエッジサーバ１７５上に存在してよくおよび／または実行してよい。いくつかの実施形態では、エッジサーバ１７５は、システムサーバ１１０および／またはユーザ機器１４０に関連して図１に記載されているような１つまたは複数の機能および／または性能を含んでよい。

図２は、本発明の少なくとも１つの実施形態による、ネットワーク内の複数のノード間でクエリの匿名検証を提供するためのシステム１００（図１参照）の例示的な構成の高レベルシステムアーキテクチャの概要を示す。

いくつかの実施形態では、中央に描かれているようなプライベートネットワーク１０５は、本明細書に記載されているサービスおよび／または機能性の一部またはすべてを保持してよい。いくつかの実施形態では、本明細書に記載されたサービスおよび／または機能の一部または全部が、例えば、システムサーバ１１０にホストされ、および／または、さまざまなエッジサーバ１７５および／またはユーザデバイス１４０（「顧客バックエンド」とも呼ばれる）に分散されてよい。いくつかの実施形態では、エッジサーバ１７５は、顧客／メンバ／ユーザの構内、例えば、彼らのクラウド環境上、またはメンバのデータセンターに設置されてよい。

いくつかの実施形態では、プライベートネットワーク１０５は、各メンバが例えば審査プロセスを経て、初めてエッジを展開してクローズドネットワークに接続することを許可されるクローズドネットワークであってよい。慣習上、本明細書では、各エッジサーバ１７５をネットワーク１０５上の「ノード」と呼ぶ。

いくつかの実施形態では、エッジサーバ１７５は、顧客がネットワークに問い合わせを送信し、応答（すなわち、「検証」）を受信することができることを容易にし得る。いくつかの実施形態では、各エッジサーバ１７５は、顧客が所定の応答で自分の顧客ベースを保証できるように、顧客の顧客ベースの符号化（例えば、ハッシュ化）されたバージョンを含んでよい。本明細書で理解される符号化は、元のデータの一方向マッピングまたは他の代表的な形態であり、例えば、ハッシュ化、暗号化、または他の手段を用いて実施し得る。

いくつかの実施形態では、各顧客は、提供された／インストールされたソフトウェア開発キット機器１４０にデータをアップロードして、データの適切なエンコーディングおよび／または表現（例えば、ハッシュ化、一方向マッピング、および／または他の暗号化）を確保し、その後、エッジサーバ１７５または指紋データベース１８０にＰＩＩおよび／または生データが保存されることなく、エッジサーバ１７５および／または指紋データベース１８０に保存し得る。いくつかの実施形態では、データの符号化および／または表現は、本明細書に記載されているデータのクリーンアップおよび／または正規化をさらに含んでよい。ＰＩＩおよび／または生データは、例えば、ユーザのデータベース（例えば、顧客データベース１８５）のファイアウォールの内側に保管されてよい。いくつかの実施形態では、エッジサーバ１７５および／または指紋データベース１８０は、非武装地帯（ＤＭＺ）で提供されてよく、一方、顧客バックエンド１４０および／または顧客データベース１８５は、例えば、保護が最も高いコーポレートゾーンで提供されてよい。コンピュータセキュリティにおいて、ＤＭＺ（境界ネットワークまたはスクリーニングされたサブネットと呼ばれることもある）は、組織の外部向けサービスが、信頼されていないネットワークや、信頼されているネットワーク内の信頼されていない要素に含まれたり、さらされたりする可能性のある物理的または論理的サブネットワークである。

本発明のさまざまな実施形態によれば、例えば、３つの層のデータがあってよい。

顧客のデータ（例：ＣＲＭなど）：顧客のシステムに保存されている生のＰＩＩデータ。元のフォーマットのこのデータは、顧客のセキュアゾーンに保存され、エッジサーバ１７５やネットワーク１０５には公開されない。しかし、エッジサーバ１７５のソースデータとなる。

指紋データベースには、ＳＤＫなどで処理された後の顧客のデータが含まれている。いくつかの実施形態では、ＳＤＫは、データを処理し、データのクレンジング、正規化、および／またはハッシュ化を実行し、いくつかの実施形態では、指紋データベース１８０は、データの符号化された、例えば、一方向ハッシュ化されたバージョン、またはそうでなければ不可逆的な、非識別化された表現のみを保持し得る。ここで述べたように、このデータベースは依然として顧客のセキュリティ管理下にある。

本明細書に記載されているいくつかの実施形態では、検証要求がクローズドネットワーク内の他のノードに発行されると、要求は一方向マッピングまたはエンコーディング（例えば、ハッシュなどの１つ以上のプロトコルに基づく）の第２の層を経て、最終的には要求自体が乱数のシーケンスを含み得る（指紋データベース１８０に格納されているデータの指紋エンコードバージョンではない）。重要なのは、顧客関連のデータは、たとえエンコードされた形であっても、ネットワーク１０５（またはそれに接続された他のノード）のどこにも保存されないことである。データが保存される場所は、関連する顧客エッジサーバ１７５のみである。

プライバシは、ここに記載されているシステムと方法の重要な考慮事項である。したがって、先行技術のシステムに対する実質的な改善点であり、本発明の実施形態のアーキテクチャと設計の重要な側面は、データフローの保護と、リクエスト実行に参加しているネットワークメンバの身元が、リクエスタ側からもバウチャ（バリデータ／検証者）側からも隠されていることを保証する一連のツールである。さらに、本明細書に記載されているシステムおよび方法は、最終顧客の身元およびそのデータ（ＰＩＩデータが漏洩しないことを含む）を確実に保護する。

図３は、本発明の少なくとも１つの実施形態による、システム１００（図１および図２参照）のエッジサーバ１７５の高レベルの構成例を示す。

いくつかの実施形態では、エッジサーバ１７５は、１つまたは複数のプライバシ機能を提供してよい。

１．「エッジにＰＩＩなし」：

ａ．いくつかの実施形態では、ＳＤＫは、エッジサーバ１７５にロードされたすべてのデータがクレンジング、エンコード、ハッシュ化、および／または匿名化されることを保証してよく、それにより、エッジサーバ１７５がＰＩＩおよび／または生データを含むことができないように保証する。

ｂ．いくつかの実施形態では、顧客側の誰かが（誤って）非エンコードデータをエッジサーバ１７５にロードしないように（例えば、ＳＤＫが使用されていない場合や動作していない場合に）、例えばフィルタを含むエッジサーバデータロードアプリケーションプログラミングインターフェース（ＡＰＩ）が提供されてよい。

２．「ネットワークレベル認証」：いくつかの実施形態では、エッジサーバ１７５は、ネットワークゲートウェイと呼ばれるコンポーネント、例えば、エッジネットワークゲートウェイ１８１を介して、プライベートネットワーク１０５にのみ接続してよい。クライアント側の証明書（ＴＬＳ）を使用することにより、例えば、エッジサーバ１７５は、ネットワーク１０５に接続することを認証してよく、エッジネットワークゲートウェイ１８１は、エッジサーバ１７５がネットワーク１０５にのみ接続できることを検証してよい。

３．「ネットワークの分離」：いくつかの実施形態では、エッジサーバ１７５は、ネットワーク１０５にのみ接続するように構成されてよく、さらなる実施形態では、接続されると、エッジサーバ１７５は、ネットワーク１０５によって提供されるサービスのみを見て、他のエッジサーバ（例えば、異なる顧客を表すノード）を見ないようにしてよい。いくつかの実施形態では、これは仮想ＬＡＮを使用して実装してよい。

いくつかの実施形態では、ネットワーク１０５（本明細書では「クラウド」とも呼ばれる）は、さまざまなプライバシ機能をエッジサーバ１７５に提供してよい。

１．「ネットワークレベルの認証」：いくつかの実施形態では、各エッジサーバ１７５は、クラウドＡＰＩゲートウェイ１８１と呼ばれるサービスを介してネットワーク１０５に接続してよい。このサービスは、ネットワーク側に常駐してよく、各エッジサーバ１７５を検証してよく、エッジサーバ１７５がネットワークに接続できることを保証してよい。いくつかの実施形態では、これは、例えば、クライアント側の証明書または他のＩＤ１８２を使用して実装してよい。いくつかの実施形態では、例えば、クレデンシャルおよび／または多要素認証などの代替認証方法を実装してよい。

２．「メンバ認証」：いくつかの実施形態では、リクエスト生成サービス（例えば、リクエスタ１８３）は、受信したリクエストを認証してよく、各クエリに対して一意のリクエストＩＤを生成してよい。いくつかの実施形態では、このリクエストＩＤは、リクエストのライフサイクルの間だけ存在し、その後は（例えば、自動または手動で）削除される。いくつかの実施形態では、生成者はリクエストの発信元を検証してよく、システムの不正使用の試みをブロックしてよい。

３．「リクエストの署名」：いくつかの実施形態では、リクエスト生成者がリクエストに署名はいよく、誰もリクエスト情報を改ざんしたり、不正なリクエストをネットワークに注入したりできない。

４．「キャスティングネットワークアイデンティティ」：いくつかの実施形態では、ネットワークアサイナは、１つまたは複数のシステムプロトコルにしたがって、各クエリに対して参加メンバノードを提供してよい。これらの当事者ノードは、参加しているエッジサーバ１７５（例えば、バウチャ／バリデータとして）、コンピュテーションサービス、アグリゲータサービス、および／またはスコアリングサービス（すべて本明細書に記載）を含んでよい。いくつかの実施形態では、リクエストごとに、ネットワークアサイナは、リクエスタエッジサーバ１７５（すなわち、リクエストが送信されたエッジサーバ）が、他の参加エッジサーバ１７５（バウチャ）のアイデンティティおよび／または提供されるサービスの数を知ることができないように、これらのサービスのアドホックＩＤを生成してよい。いくつかの実施形態では、クラウドＡＰＩゲートウェイは、これらのアドホックＩＤと、これらのサービスの実際のネットワークアドレスとの間のマッピングを実行してよい。

５．「匿名配信」：いくつかの実施形態では、エッジサーバ１７５がお互いに見えないことを考えると、ディスパッチャサービスというサービスがあり、これが中間者のようなサービスとして機能してよい。いくつかの実施形態では、このサービスは、ソースエッジサーバ１７５からメッセージを受け取ってよく、ターゲットエッジサーバ１７５に転送して、やはり２つのエッジサーバ１７５が直接通信できないようにして、ユーザのアイデンティティを保護する。いくつかの実施形態では、匿名配信の方法が実施されてよく、例えば、Ｄｒｏｐｂｏｘの方法、Ｔｏｒにヒントを得たプロトコルなどがある。いずれにしても、関連するエッジサーバ１７５以外のネットワークには、データは保存されない。

図４は、本発明の少なくとも１つの実施形態による、ネットワーク内の複数のノード間でクエリの匿名検証を行うための方法４００のフロー線図である。いくつかの実施形態では、方法４００は、プロセッサ（例えば、サーバプロセッサ１１５）、メモリ（例えば、サーバメモリ１２５）、およびメモリに格納されプロセッサで実行される１つまたは複数のコードセット（例えば、サーバモジュール（複数可）１３０）を有するコンピュータ（例えば、システムサーバ１１０、ユーザデバイス１４０（本明細書では、顧客デバイスまたは顧客バックエンドとも呼ばれる）、および／またはエッジサーバ１７５）で実行されてよい。この方法は、ステップ４０５で、ユーザ（例えば、オンラインストアなどのサービスプロバイダ）（以下、「リクエスタ」または「リクエスタノード」）が、新規顧客からデータ、例えば、ＰＩＩを受信／収集したときに始まる。本明細書で理解されるリクエスタとは、ネットワークのメンバ（およびそのそれぞれのノード／エッジサーバ１７５）であり、そのメンバが保持するデータ値（例えば、取得した電子メールアドレス）が、ネットワークの他のメンバのデータベースに存在するかどうかを確認することを望む。

いくつかの実施形態では、ステップ４１０において、リクエスタは、照会され、潜在的に検証されるデータの指紋を計算してよい（本明細書でさらに詳細に説明する）。いくつかの実施形態では、クエリ、すなわち指紋は、データのエンコードされた（例えば、ハッシュ化された、暗号化されたなど）プレゼンテーション、またはデータを表す他の一方向性関数であってよい。いくつかの実施形態では、指紋は、完全または部分的にハッシュ化されたプレゼンテーション、またはデータのサブセットまたは切り捨てられたバージョンであってよい。

いくつかの実施形態では、ステップ４１５で、リクエスタは、例えば、ワンタイム暗号化キーで指紋を暗号化してよく、本明細書に記載されているように、暗号化された指紋を複数のランダムなシェアに分解してよい。いくつかの実施形態では、暗号化された指紋は、複数の事前定義されたシェアに分解されてよく、まったくシェアに分解されなくてもよいことに留意すべきである。

いくつかの実施形態では、ステップ４２０で、複数のバリデータ（バウチャ）は、ワンタイム暗号化キーで自分のデータを暗号化してよく、自分のデータを複数のランダムシェアに分解してよい。本明細書で理解されるように、バリデータ（またはバウチャ）は、データベースまたは値のリストを保持するネットワークのメンバ（およびそのそれぞれのノード／エッジサーバ１７５）である。さまざまな実施形態において、プロトコルは、リクエスタが要求した「ルックアップ値」が、バリデータが保有する値のリストに存在するかどうかをチェックしてよい。なお、暗号化されたバリデータのデータは、リクエスタと同様に、あらかじめ定義された複数のシェアに分解されてよく、全くシェアに分解されなくてもよい。ルックアップ値とは、ネットワーク上の他のメンバが保持する値のリストに存在するかどうかをリクエスタがテストしたい値のことである。いくつかの実施形態では、ルックアップ値は単一の値であってよく、値のリストであってもよい。

いくつかの実施形態では、ステップ４２０および／またはステップ４２５に加えて、またはステップ４２５に代えて、ワンタイム暗号化キーは各バウチャによってのみ生成されてよく、その場合、バウチャは自分のデータをワンタイム暗号化キーで暗号化する。そのような実施形態では、バウチャとリクエスタは、「ブラインド暗号化」プロトコルまたは他の忘却メカニズム（例えば、ブラインドデジタル署名、ガーブル回路の使用など）を実行してよく、リクエスタは自分のデータやバウチャが生成したワンタイム暗号化キーを公開することなく、自分のデータの暗号化されたコピーを受け取ることができる。バウチャは、データを送信する前に、生成されたキーを削除してよい。この仕組みにより、各リクエストが異なるものであることが保証され、バリデータ以外の者が同じバリデータから送られたデータを解読することは絶対にできない。

いくつかの実施形態では、ステップ４２５で、リクエスタとバリデータの両方に使用された鍵が破壊されるか、またはその他の方法で処分される（例えば、自動または手動で）。

いくつかの実施形態では、ステップ４３０において、リクエスタおよびバリデータは、各ランダムシェアをサポートサーバまたは計算サーバと呼ばれる特別なネットワークノードに送信してよい。各ランダムデータシェアは、別のサポートサーバに送信されてよい。サポートサーバは、本明細書で理解されるように、ネットワークに計算支援を提供するサーバであってよい。例えば、さまざまな実施形態において、サポートサーバは、データの転送、データの処理、メタデータの収集など、ネットワークの運用をサポートするための追加のアクションを取ってよい。計算サーバは、自身のデータを保持せず、提供されたデータに対して事前に定義された計算を典型的に行ってよい。

いくつかの実施形態では、ステップ４３５において、各サポートサーバは、リクエスタからの値を、バリデータから受信した値と／から調整（ｒｅｃｏｎｃｉｌｅ）（例えば、減算、ＸＯＲ、除算など）してよい。

いくつかの実施形態では、ステップ４４０において、すべての結果がアグリゲータによって統合されてよい。アグリゲータは、本明細書で理解されるように、ネットワークの参加メンバ（およびそのそれぞれのノード／エッジサーバ１７５）であり、すべてのバウチャから送信されたデータを収集して蓄積するように構成されてよい。いくつかの実施形態では、アグリゲータは、データを使用して、すべてのバウチャのデータベースにルックアップ値が存在した回数をカウントしてよい。いくつかの実施形態では、アグリゲータは、サポートサーバからのすべての結果を統合してよく、一致するもの（例えば、すべての数字の合計が０）を探してよい。いくつかの実施形態では、一致は、完全に一致するのではなく、例えば、統計的な類似性や閾値の類似性などに基づいて一致とみなされてよいことに留意すべきである。

いくつかの実施形態では、実装されたプロトコルは、ステップ４３０で計算されたすべての値を、統合のためにアグリゲータに送信する前に、秘密の乱数を乗じてよい。乱数は、例えば、サポートサーバ、信頼できる第三者、またはバウチャによって生成されてよい。

いくつかの実施形態では、ステップ４４５において、一致するものが見つかった場合、元のリクエスタに通知してよく、方法を終了してよい。発信元のサービスプロバイダ（リクエスタ）は、データが有効であることを認識した上で、新規顧客へのサービス提供を継続し得る。あるいは、サービスプロバイダは、データが有効ではなく、不正確または不正である可能性があることを認識した上で、追加のステップを踏んでよい。

本明細書に記載されている本発明のさまざまな実施形態は、顧客とサービスプロバイダとの両方にとって、プライバシおよびセキュリティに大きな利益をもたらす。

プライバシ：メンバのデータウェアハウスから個人情報が流出することはない。各メンバは、メンバが顧客から明示的に受信したデータにのみアクセスできる。

匿名性：特定の顧客が特定のサービスに登録していることを誰にも知られない。

分散型：ハッキングや侵入される可能性のある集中型のデータストアはない。

レジリエンス：単一のプロバイダに依存しない。メンバがネットワークに参加したり離脱したりしても、全体としての影響はほとんどない。

ホリスティック：すべてのソースおよび地域からのすべてのデータ検証へのアクセスは、単一のインターフェースを介して実行してよい。

リアルタイム：データの検証は、顧客との関係を所有する企業が行うことができ、したがって、ファーストパーティのデータプロバイダとして機能する。

信頼度：メンバの評判はプロトコル内で処理される。

本発明のさまざまな実施形態に基づき、リクエスタ、バリデータ、サポートサーバ、およびアグリゲータについて、本明細書でより詳細に説明する。

リクエスタ：

Ａ．クエリにおける役割：アイデンティティの一部であるフィールド（電子メール、電話番号、クレジットカード番号、資金調達手段、銀行口座の詳細、バイオメトリクス、健康データなど）を検証するために検索しているメンバ（およびそれぞれのノード）。各リクエストには、一意に定義される必要のあるキーフィールドが含まれる（以下の表１参照）。

Ｂ．入力：なし

Ｃ．出力：エンコードされた（例えば、ハッシュ化された）リクエスト（例えば、クエリ）を作成し、このリクエストは、いくつかの実施形態では、複数のシェア（例えば、ランダムなシェア）に分解されてよい。また、リクエストのヒントも作成する。リクエストのヒントはバリデータに送信してよく、ランダムなデータのシェアはサポートサーバに送信してよい。

Ｄ．制限：どのノードでもリクエスタになれる。あるノードがリクエスタである場合、そのノードは、このクエリにおいて他の役割を担うことができない。

Ｅ．カーディナリティ：１つのクエリに対して１人のメンバしかリクエスタになれない。ここでいう「カーディナリティ」とは、ある値やプロパティが、リストやアイテムのセットに現れる回数のことである。例えば、リスト｛１，１，２，４，６，６，６，９｝では、値６のカーディナリティは３、値９のカーディナリティは１である。

バリデータ：

Ａ．クエリにおける役割：いくつかの実施形態では、バリデータはデータの所有者であってよい。バリデータが所有するレコードのうちの１つが、リクエスタのクエリに一致してもよい。

Ｂ．入力：キーフィールドからヒントを得たフィルタを含むリクエスト。

Ｃ．出力：バリデータのデータを暗号化（ハッシュ化）したサブセットに由来するランダムシェアのセット。サブセットは、リクエストのヒントによって定義されてよく、リクエストされたクエリと一致してもよい。

Ｄ．制限：トランザクションのバリデータは、トランザクションの計算において他の役割を担うことはできない（リクエスタ、Ｓサーバ、アグリゲータ、ネットワーク）。

Ｅ．カーディナリティ：１つのトランザクションにつき、任意の数のバリデータが存在することができる。

サポートサーバ（Ｓサーバ）：

Ａ．クエリでの役割：リクエスタから受信した値と、バリデータから受信した値のリストとを比較して、例えば、両者を調整（ｒｅｃｏｎｃｉｌｅ）する。

Ｂ．入力：リクエスタからは符号化され暗号化されたフィールドのランダムシェア、バリデータからは符号化され暗号化されたフィールドのランダムシェア（同じフィールド、同じ暗号化キーだが、同一人物ではないかもしれない）のリスト。

Ｃ．出力：リクエスタとバリデータそれぞれのランダムシェアの値の差を比較した結果のリスト。

Ｄ．制限：計算上の他の役割を持たない任意のエンティティにすることができる。いくつかの実施形態では、Ｓサーバは一時的なノードであってよく、永続的なメモリまたはストレージ容量を必要としない。

Ｅ．カーディナリティ：Ｓサーバの数は、不正使用に対する抵抗力に応じて、２以上の任意の値に設定することができる。

アグリゲータ：

Ａ．クエリでの役割：Ｓサーバからすべての結果を受け取り、どのバリデータが関連する要求値にマッチするかを決定する。その後、アグリゲータは結果をリクエスタに伝え、ビジネストランザクションを決済する。

Ｂ．入力：すべてのＳサーバからの結果のリスト。

Ｃ．出力：リクエスタに対するＹｅｓ／Ｎｏの応答（または同等のもの）、例えば、ネットワーク内でクエリに一致するものが見つかったかどうかの通知。いくつかの実施形態では、アグリゲータは、信頼度スコアを計算して提供するように構成されてよい。いくつかの実施形態では、応答には、例えば、ネットワーク上でＩＤが最初に見られたときや最後に見られたときなどのメタデータを含めてよい。

Ｄ．制限：アグリゲータは、第三者、例えば、プライベートピアツーピアネットワークのマネージャ、ホスト、またはプロバイダによって運営されてよい。

Ｅ．カーディナリティ：１つのクエリにつき、１つのアグリゲータしかない。

図５は、本発明の少なくとも１つの実施形態による、個々のデータフィールドを検証するための方法５００のフロー線図である。いくつかの実施形態では、本方法はステップ５１０で始まり、リクエスタがデータフィールド、例えば、電子メールアドレス（Ｘ）をハッシュ化し、例えば、トランザクション前の鍵（ＣＸｉ）で暗号化するように構成される。いくつかの実施形態では、バリデータごとに個別のキーが生成されてよい。つまり、クエリでリクエスタを支援するメンバ（バリデータ）ごとにキーが生成される。したがって、１つのリクエストに対して、複数の鍵を生成してよく、使用してよい。データが暗号化された後、いくつかの実施形態では、その合計が暗号化された値と等しくなるように、例えば、Ｍ個のランダムなシェア（［ＣＸｉ］ｊ）に分割してよい。

ステップ５２０において、いくつかの実施形態では、リクエスタは、別のハッシュ関数を使用して、元の電子メールから短いヒント（例えば、５ビットの長さ）を計算するように構成されてよい。いくつかの実施形態では、このヒントは、各バリデータが結果をフィルタリングするために使用されてよく、各ヒントが何十万ものＩＤにマッチする可能性を確保する方法で選択されてよい。リクエスタは、各バリデータにヒント値とバリデータごとの秘密鍵を送信してよい。

例えば、完全なデータベースを多くのより小さいデータベースに分割することによって、バリデータが処理する必要のあるレコード数を減らすために、例えば、このヒントを利用してよい。これは、短いハッシュ関数を使って行ってよい。例えば、５ビットのハッシュでは、元のデータベースが３２個のより小さいデータベースに分割される。いくつかの実施形態では、ヒントの長さは、元のデータベースのサイズに基づいて選択してよい。例えば、元のデータベースが１億レコードだった場合、上記のようなヒントを与えると、３００万レコード程度の大きさの小さいデータベースに分割される。ヒントの例は、ｈｉｎｔ＝Ｈａｓｈ（Ｘ）ｍｏｄ３０でよく、ここで、Ｈａｓｈは任意のハッシュ関数であり、ｍｏｄは３０で割ったときのリマインダである。もちろん、いくつかの実施形態では、ヒントを使用しなくてよく、すべてのレコードを処理してよい。

ステップ５３０において、いくつかの実施形態では、各バリデータは、そのレコードのセットを検索して、リクエスタから受信したヒント値と一致する関連レコード（Ｙｉ）を見つけるように構成されてよい。一致したレコードについて、バリデータはデータベース内の値のハッシュを計算してよく、秘密鍵（ＣＹｉ）を用いて暗号化してよい。暗号化された後、バリデータはＭ個のランダムシェア（［ＣＹｉ］ｊ）を選んでよく、その合計が暗号化された値と等しくなる。この操作は、（ヒントが実装されている場合）ヒントに一致するすべてのレコードで繰り返してよい。各ランダムシェアは、いずれかのＳサーバに送信され、リクエスタから受信したランダムシェアと比較されてよい。各Ｓサーバは、データの断片のみを扱ってよい。したがって、Ｓサーバ１はすべてのバリデータから第１番目のランダムシェアを受信し、Ｓサーバｍはすべてのバリデータから第ｍ番目のフラグメント（ランダムシェア）を受信してよい。なお、いくつかの実施形態では、リクエスタキーとバリデータキーの両方が、データを暗号化した直後に、例えば、自動または手動で削除される。したがって、結果は完全に匿名化され、いかなるＰＩＩデータにもリンクされない。

ステップ５４０において、いくつかの実施形態では、Ｓサーバ（サポートサーバまたは計算サーバ）は、リクエスタから受信したランダムシェアと、すべてのバリデータから受信したすべてのランダムシェアとの間の差を計算する（またはその他の方法で調整する）ように構成されてよい。その後、Ｓサーバは、アグリゲータに差分のリスト（または調整された結果）を送信してよい。

ステップ５５０において、いくつかの実施形態では、アグリゲータは、例えば、すべてのＳサーバから受信したすべての差分または結果を、例えば、レコードごとに加算し、すべての値が０に加算されるか、またはそうでなければ完全に調整されたレコードを特定するように構成されてよい。いくつかの実施形態では、合計が０の場合、リクエスタの値と一部のバリデータの値とが一致していることを示す。

最後に、ステップ５６０において、いくつかの実施形態では、アグリゲータは、結果を集約し、リクエスタに回答を送信するように構成されているかもしれない。

本発明の実施形態では、データが顧客のネットワークを離れる前に完全に匿名化される。そのため、ＰＩＩデータは一切含まれておらず、いかなる個人データも公開することはできない。以下の表１は、各参加者が計算の一部として「学習」する可能性のある内容をまとめたものである。

アイデンティティを検証するために、企業はエンティティに関連する可能な限り多くのプロパティの検証を受けたいと思うかもしれない。本発明の実施形態では、上述のプロセスと同様のプロセスを使用して、１つのクエリに関するすべてのプロパティを比較し、サインアップ時に収集された値のうちどれが実際に有効であるかを示す１つのレコードを作成する。さらに、本発明の実施形態では、値が同じエンティティに関連するかどうかと、それに関連する信頼度を指定する。

いくつかの実施形態では、バリデータは、最初のログイン時刻、最後のログイン時刻、訪問回数、不正関連の評判、資産年齢などの非ＰＩＩメタデータを記録ごとに追加で提供してよい。

いくつかの実施形態では、データポイントの履歴を提供してよい。例えば、メールアドレスが１年以上前からユーザのシステムに保存されており、顧客が２年前に特定のデバイスを使用した記録がある場合や、６ヶ月前にクレジットカードが検出された場合などが挙げられる。このようなデータは、本発明の実施形態にしたがって、顧客データ履歴に定式化してよい。

本発明のいくつかの実施形態では、データポイントの１つまたは複数に関する不正関連の評判を提供してよく、例えば、特定のクレジットカードからの不正関連チャージバックが先週検出された場合、そのクレジットカードおよび他の関連データポイントに疑わしいというフラグを立ててよい。

いくつかの実施形態では、アグリゲータが、キーフィールドがクエリフィールドと一致したことを識別できた場合、アグリゲータは、レコード全体の検証を提供することを支援してよい。例えば、バリデータが電子メールとＩＰアドレスの検証はできても、リクエストされたクレジットカード番号と住所の検証ができなかった場合、バリデータがデータベースにこれらのフィールドを持っていないことを知ることは、レコード全体の検証に役立つかもしれない。

本明細書に記載されているように、本発明の実施形態は、メンバのネットワーク上で動作する可能性のある１つ以上のプロトコルに依存しており、各メンバはプライベートな値のリストを保持している。いくつかの実施形態では、プロトコルの実装により、ネットワークのメンバがリクエスタとして動作し、ネットワークの他のメンバが保有するプライベートリスト内に特定のルックアップ値が存在するかどうかの検証を受けることを要求することができる。このような他のメンバは、（本明細書に記載されているように）バウチャとして機能する。

いくつかの実施形態では、リクエスタは、以下のプライバシ機能を維持しながら、ネットワーク内の値ｘをルックアップするとともに、値のカーディナリティを計算することができる。１．誰も（リクエスタ以外）ｘの値を知ることはない。２．リクエスタは、ネットワークのどのメンバが値ｘを保持しているかを知ることはできない。３．メンバの誰もが、自分のプライベートデータベースに値ｘが存在するかどうかを知る。

説明を簡単にするために、リクエストするメンバをリクエスタと呼び、他の各パーティをバウチャまたはバリデータと呼ぶ。ｎ＋１人のメンバからなるネットワークでは、メンバはＶ^ｐとしてマークされ、リクエスタは値ｘのルックアップクエリを生成し、各バウチャは値Ｙ^ｐ＝｛ｙ^ｐｉ｝のプライベートリストを有し得る。

以下の説明では、以下の表記を使用している。

Ｈ（ｘ）：一方向性関数。一般的には、ハッシュ関数または他の一方向性関数を指す。値ｙ＝Ｈ（ｘ）が与えられたとき、Ｈ（ｘ’）＝ｙ－Ｈ（ｘ）となるような値ｘ’を見つけることは計算上困難である。

Ｈ（ｘ，ｒａｎｄ）：ランダム化された一方向性関数であり、値ｘがハッシュ化されるか、またはランダムな値と組み合わせてエンコードする。ｒａｎｄの各選択によって、関数の結果は異なる。通常の一方向性関数と同様に、Ｈ（ｘ’，ｒ）＝ｙ＝Ｈ（ｘ，ｒ）となるような値ｘ’を、ｘとｒのすべての選択で見つけることは、計算上困難である。

ｘ：ルックアップ値

Ｙ＝｛ｙｉ｝は、値のセットまたはリストである。セット全体をＹと呼び、セット内の個々の値をｙｉと呼び、添え字はリストの値のインデックスを示している。例えば、ｙ１はリストの最初の値を表す。

ｃ＝Ｅｎｃ（ｍ，Ｋ）は、鍵Ｋを用いた暗号化関数である。この関数は，任意の平文メッセージｍを、秘密鍵Ｋを知らずにｍを見つけることが計算上困難であるような暗号化サイファーｃに変換する。

ｍ＝Ｄｅｃ（ｃ，ＳＫ）は、秘密鍵ＳＫを用いる復号関数である。この関数は、暗号化されたサイファーｃを、秘密鍵ＳＫの知識を用いることにより平文に戻すことができる。

暗号化関数Ｅ（ｍ，Ｋ）が与えられたとき、任意のメッセージｍと任意の鍵Ｋ_１、Ｋ_２のペアに対して、鍵の使用順序にかかわらず、各鍵でメッセージを２回暗号化するたびに同じ結果が得られる場合、Ｅは可換暗号化関数（Ｃｏｍｍｕｔａｔｉｖｅ Ｅｎｃｒｙｐｔｉｏｎ Ｆｕｎｃｔｉｏｎ）と呼ばれる。つまり、Ｅ（Ｅ（ｍ，Ｋ_１），Ｋ_２）＝Ｅ（Ｅ（ｍ，Ｋ_２），Ｋ_１）となる。

上付き文字：上付き文字は、計算上の異なるメンバ、またはそれらに関連する値を示す。例えば、複数のバウチャが計算に参加している場合、第１のサーバに関するデータベースはＹ^１、第２のメンバに関するデータベースはＹ^２と表示される。同様に、各メンバに秘密鍵が選択された場合、この鍵はメンバｐのＳＫ^ｐとして表記される。

値の分割：以下のいくつかの方法では、１つの値を複数の「サブ値」に分割し、それらを再結合して元の値を構築し得る。例えば、３桁の数字４６９を４、６、９に分割し得る。このような値ｖの分割は、角括弧［ｖ］_１，［ｖ］_２，［ｖ］_３，・・・で示される。上記の例では、［４６９］_１は４、［４６９］_２は６、［４６９］_３は９となる。異なるソリューションでは、値をサブ値に分割し再結合する方法が異なる場合がある。

プロトコル１

いくつかの実施形態では、データを保持しない追加の計算サーバのサービスをＣｏｍｐと呼ぶ。

１．リクエスタは、一方向性ハッシュ関数または他のエンコーディングを使用して、Ｈ_０＝Ｈ（ｘ）を計算する。

２．各バウチャＶ^ｐは、値のセットＨ^ｐｉ＝Ｈ（ｙ^ｐｉ）を計算する。

３．リクエスタは、Ｈ_０をＣｏｍｐに送信する。

４．各Ｖ^ｐは、自分のデータをＣｏｍｐに送信する。

５．Ｃｏｍｐは、Ｈ_０を各Ｖ^ｐから受信したすべての値と比較し、一致するものを探す。

６．Ｃｏｍｐは、見つかった一致する数をリクエスタに報告する。

リプレイ保護

場合によっては、同じ値ｘを複数回検索する場合がある。同じ値が検索されていることを誰にも知られないようにするために、いくつかの実施形態では、ランダムな要素をクエリに組み込んでもよい。値は、２つの要求が２つの別々のルックアップ値ｘ_１、ｘ_２から来ているのか、同じ値ｘを２回要求しているのかを盗聴者が区別できないような方法で追加し得る。

プロトコル１．１

いくつかの実施形態では、プロトコル１のバリエーションとして、リクエスタとバウチャがランダムな一方向性関数を使用してｘの元の値を難読化することを実施してもよい。関数とそのパラメータは、バウチャとリクエスタの両方に知られている。例として、ランダム化されたハッシュ関数、暗号化関数、または既知の関数のセットからランダムに選択された関数を使用し得る。

以下の説明では、既知のハッシュ関数の代わりに、ランダムな一方向性関数を使用している。

１．リクエスタはランダムな秘密のノンスを選択する。

２．リクエスタは、ランダム化された一方向性ハッシュ関数または他のエンコーディングを使用して、Ｈ_０＝Ｈ（ｘ，ｎｏｎｃｅ）を計算する。

３．リクエスタは、各バウチャＶ^ｐにｎｏｎｃｅの値を送信する。

４．各メンバＶ^ｐは、値のセットＨ^ｐｉ＝Ｈ（ｙ^ｐｉ，ｎｏｎｃｅ）を計算する。

５．リクエスタは、Ｈ_０をＣｏｍｐに送信する。

６．各Ｖ^ｐは、自分のデータをＣｏｍｐに送信する。

７．Ｃｏｍｐは、Ｈ_０を各Ｂｏｂ^ｐから受信したすべての値と比較し、一致するものを探す。

８．Ｃｏｍｐは、見つかった一致する数をリクエスタに報告する。

リンカビリティ保護

異なるバウチャ間の秘密を保持し、プライバシ規制で要求されるリンカビリティを防止するために、いくつかの実施形態では、各バウチャで生成された値は、異なることが保証され、他のバウチャで生成された値と比較することはできない。このようにして、盗聴者または好奇心の強い人は、実際のオリジナルの価値が不明なままであっても、２つ以上のバウチャがオリジナルのリストの中で同じオリジナルの値を保持しているかどうかを知ることができなくなる。

これを実現するために、いくつかの実施形態では、リクエスタといずれかのバウチャの間で、彼らだけが知っている別のランダムな秘密が生成される。さまざまな実施形態において、この値は、リクエスタ自身により、リクエスタとバウチャにより共同して、バウチャにより、第三者により、またはそれらの当事者の組み合わせにより、生成される場合がある。

いくつかの実施形態では、秘密の値は、ルックアッププロトコルを実行する前に、リクエスタとバウチャの両方により使用される任意のマッピング関数への入力として使用し得る。例として、この関数は、一方向性ランダム化ハッシュ、暗号化関数、または既知のセットからランダムに選択された関数であり得る。

プロトコル１．２

プロトコル１では、ランダム化されたハッシュ関数を使用することで、リンカビリティの保護が追加されている。リクエスタは、各メンバＶ^ｐに対して異なるｎｏｎｃｅ値を選択する。

１．リクエスタは、ランダムな秘密のｎｏｎｃｅ^ｐのセットを選択する。

２．リクエスタは、一方向性ハッシュ関数または他のエンコーディングを用いて、Ｈ^ｐ _０＝Ｈ（ｘ，ｎｏｎｃｅ^ｐ）を計算する。

３．リクエスタは、各メンバのＢｏｂ^ｐにｎｏｎｃｅ^ｐの値を送信する。

４．各バウチャＶ^ｐは、値Ｈ^ｐ _ｉ＝Ｈ（ｙ^ｐ _ｉ，ｎｏｎｃｅ^ｐ）のセットを計算する。

５．リクエスタは、セットＨ^ｐ _０をＣｏｍｐに送信する。

６．各Ｖ^ｐは、自分のデータをＣｏｍｐに送信する。

７．Ｃｏｍｐは、Ｈ^ｐ _０を各Ｖ^ｐから受信したすべての値と比較し、一致するものを探す。

８．Ｃｏｍｐは、見つかった一致する数をリクエスタに報告する。

プロトコル１．３

プロトコル１．１の方法では、ｎｏｎｃｅの秘密の値が、他の１つ以上の当事者Ｂｏｂ^ｐが関与する鍵合意法を用いて生成される。

プロトコル１．４

プロトコル１．２の方法では、ｎｏｎｃｅ^ｐの秘密の値が、リクエスタとバウチャで鍵交換メカニズム（例えば、Ｄｉｆｆｉｅ Ｈｅｉｌｍａｎ）を用いて生成される。

１．リクエスタとバウチャが鍵交換プロトコルのパラメータに合意する。

２．リクエスタとバウチャが秘密鍵交換を行い、共有秘密ｓを生成する。

３．リクエスタとバウチャは、鍵導出メカニズムを使用して、秘密のｓからＫ^ｐを計算する。

４．ｎｏｎｃｅ^ｐ値の代わりにＫ^ｐを使用して、プロトコル１．２の手順を続行する。

バリエーション１

上記のすべてのプロトコルの方法では、ランダムな一方向性関数が、ランダムな共有鍵、または上記で規定された鍵交換プロトコルを用いて生成された鍵を用いた対称鍵暗号化システムに置き換えられる。

バリエーション２

上記のすべてのプロトコルの方法では、ランダムな一方向性関数が、ランダムな共有鍵、または上記で規定された鍵交換プロトコルを用いて生成された鍵を用いた公開鍵暗号化システムに置き換えられる。

バリエーション３

上記のすべてのプロトコルの方法では、ランダムな一方向性関数が、ランダムに選択されたマッピング関数に置き換えられる。

プロトコル２

この種のプロトコルでは、値そのものを公開することなく、値を秘密裏に比較するために、可換暗号化関数が使用される。例えば、Ｅｌ－ＧａｍａｌまたはＰｏｈｌｉｇ－Ｈｅｌｌｍａｎの暗号化スキームを使用してよい。

１．Ｅ（ｍ，Ｋ）を上述の可換性を満たす（秘密鍵または公開鍵を用いた）可換暗号化システムとする。

２．リクエスタは、秘密鍵Ｋ_０を選択する。

３．リクエスタは、Ｅを使ってルックアップ値ｘをＫ_０で暗号化し、Ｅ_０＝Ｅ（ｘ，Ｋ_０）を受信する。

４．リクエスタは、ネットワーク上のすべてのメンバであるＢｏｂ^ｐにＥ_０を送信する。

５．すべてのバウチャは、秘密鍵Ｋ_ｐを選択する。

６．各バウチャは、自分の秘密鍵を使って、自分のローカルデータベースＹ^ｐを暗号化し、次式を生成する。

７．さらに，各バウチャは，受信したＥ_０を自分の鍵で暗号化して，二重暗号化された鍵Ｅ_０ｐ＝Ｅ（Ｅ_０，Ｋ_ｐ）を生成する。

８．すべてのバウチャＶ^ｐは、自分の暗号化されたデータベースＹ^ｐを、二重暗号化されたキーＥ_０ｐと一緒にリクエスタに戻す。

９．リクエスタは、自分の秘密鍵を使って、各バウチャＶ^ｐから受信したすべての値を二重に暗号化し、二重暗号化されたデータベース

を生成する。

１０．リクエスタは、各ｐについてＥ_０ｐの値とＥ^ｐ０の値とを比較することができる。見つかった一致する総数をカウントする。

代替２．１

上記のプロトコル２と同じプロセスを使用し、ステップ９で以下の代替案を使用する。

９．リクエスタは、自分の鍵を使ってＥ_０ｐの値を復号し、

を受信する。

１０．各ｐについてリクエスタは、Ｅ_ｐの値をすべての値ｙ^ｐと比較し、見つかった一致する総数をカウントする。

代替２．２

上記のプロトコル２．１と同じプロトコルであるが、第３の計算メンバであるＣｏｍｐを導入する。

上記のステップ８から開始する。

８．すべてのバウチャＶ^ｐは、その暗号化されたデータベースＹ^ｐをＣｏｍｐに送信する。

９．すべてのバウチャＶ^ｐは、二重に暗号化された鍵Ｅ_０ｐをリクエスタに返送する。

１０．リクエスタは、自分の鍵を使ってＥ_０ｐの値を復号し、

を受信する。

１１．リクエスタは、Ｅ_ｐの全キーをＣｏｍｐに送信する。

１２．Ｃｏｍｐは、各ｐについてＥ_ｐの値をすべての値ｙ^ｐと比較し、見つかった一致する総数をカウントし、その合計をリクエスタに返送する。

効率アップ

上記のすべてのプロトコルは、バウチャが値の完全なリストをスキャンし、各値に対して計算を実行し、それを他のパーティに送信することを必要とする。そのため、プロトコルを完成させるために必要な複雑さと時間は、各メンバが保有するリストのサイズに応じて線形的に成長する。

この複雑さを軽減するために、いくつかの実施形態では、リクエスタまたはバウチャがリストに有し得る値を、より小さい範囲の別の値にマッピングすることが実施され得る。このマッピングを使用して、バウチャが保有する各リストを、より小さなサイズの複数のサブリストに分割し得る。例えば、すべての値を偶数と奇数に分けて、元のリストの約半分の大きさの２つのリストを有し得る。

いくつかの実施形態では、プロトコルの最初に、リクエスタはルックアップ値ｘのマッピングを計算し得て、それをバウチャにヒントとして送信し得る。バウチャはこの値を使用し得て、自分が保持しているサブリストのうち、どのサブリストを計算に使うべきかを特定し得る。

いくつかの実施形態では、各オリジナルリストから生成されるサブリストの数を定義する効率パラメータλが実施され得る。例えば、各リストを１０個のサブリストに分割し、各々を元のリストの約１０分の１の大きさにすることが選択され得る。

いくつかの実施形態では、システムは、プライバシと効率のバランスをとるために、効率パラメータ値を随時選択し得る。この選択は、バウチャの数、各バウチャがリストに保持している値の数、人口の規模、規制上の要件などによって異なり得る。

例として、一方向性ハッシュ関数およびモジュロλを使用し得て、マッピングｇｒｏｕｐ＝Ｈ（ｙ）ｍｏｄλを使用してすべての値をサブリストに分割し得る。

プロトコル３

１．リクエスタは、ｇｒｏｕｐ＝Ｈ（ｘ）ｍｏｄλを計算する。

２．リクエスタは、すべてのバウチャＶ^ｐにｇｒｏｕｐを送信する。

３．各バウチャは、リスト内のすべてのｙ_ｉの値に対してｇｒｏｕｐ＝Ｈ（ｙ_ｉ）ｍｏｄλを計算し、ｇｒｏｕｐ_ｉ＝／ｇｒｏｕｐとなる値を破棄する。

４．上記のようにＹ^ｐではなく、より小さい値のリストにある任意のプロトコルを続行する。

効率の事前計算

いくつかの実施形態では、マッピング関数を使用したｇｒｏｕｐへの分割は、上述のようにオンザフライで行われてもよいし、事前にバウチャが計算してもよい。この場合、バウチャはリストの各値が属するｇｒｏｕｐを計算し、その結果を保存してもよい。

さらに、いくつかの実施形態では、バウチャは、値を複数のリストに分割し、各々が元のリストから同じｇｒｏｕｐに属するすべての値を含むようにしてもよい。

値の分割と再構築

値ｖの機密性をさらに保護するために、いくつかの実施形態では、値ｖをＫ個のパーツに分割し、各パーツ［ｖ］ｉが元の値ｖに関する情報をほとんど、あるいは全く含まないようにしてもよい。分割方法は可逆的である必要があり、部品のリストからｖの元の値を計算することが可能である。

いくつかの実施形態では、分割の秘匿性は、分割の１つのピース［ｖ］ｉを知ることにより明らかになり得るｖに関する情報の量を測定することによって測定され得る。いくつかの実施形態では、敵対者が、すべての部分［ｖ］ｊを利用できない限りｖの元の値に関する情報を得ることができない場合、分割は理想的であると考えられ得る。いくつかの実施形態では、ｖを再構築するためにｎ＜Ｋ個のパーツが必要であるが、ｎ個以下のパーツではｖに関する情報を得ることができない場合、分割されたｎはプライベートとみなされる。

理想的な分割と再構築の一例は、次式のような大きなモジュロＮとＫのランダム値を選択することで行うことができる。

この場合、Ｋ個以下の部分和は均等に分布しているので、ｖに関する情報は一切出てこないことがわかる。

もう１つの方法は、次式のように均等に分布した値のセットを選択することである。

もう１つの方法は、ｖのバイナリ表現を個々のビットに分割することである。

本発明の実施形態に基づくプロトコル。

このプロトコルは、最大限のプライバシと秘密を実現するために、以下の要素を１つ以上含んでよい。

・リクエストごとに新しい秘密のセットが使用される。

・リクエスタと全てのバウチャとの間には別々の秘密が使用される。

・リクエスタとバウチャは、一方向性関数を使い、共有された秘密を使ってすべてのデータをマッピングする。

・各データポイントは理想的分割法で分割される。

・分割されたデータはコンピュートサーバで処理され、分割された各部分を個別に比較する。

・比較した結果（残存データがないもの）はアグリゲータに集められ、処理される。

・アグリゲータは結果をリクエスタのみに返信する。

このプロトコルでは、Ｋ個のコンピュートサーバとアグリゲータを使用する。コンピュートサーバの数は、プロトコルのセキュリティパラメータとして選択されてよい。

１．リクエスタは、値ｘを検索したいと考える。

２．リクエスタは、ネットワーク上の各バウチャと鍵交換プロトコルを実行し、一連の秘密鍵ＳＫ^ｐを生成する。

３．リクエスタは、ヒントｇｒｏｕｐ＝Ｈ（ｘ）ｍｏｄλを計算する。

４．リクエスタは、各バウチャＶ^ｐにｇｒｏｕｐの値を送信する。

５．リクエスタは，ステップ２で生成したすべての秘密鍵ＳＫ^ｐを用いてｘの値を暗号化し、隠し値

を生成する。リクエスタはＳＫ^ｐを使用後に削除し得る。

６．リクエスタは、隠された

の値の各々を、次式

のような均等な（ｅｖｅｎ）分布から引き出されたｋ個のランダムな部分［ｘ^ｐ］ｊに分割する。

７．リクエスタは、分割されたデータをｋ個の異なるコンピュートサーバに送信し、第１のコンピュートサーバは、すべての隠れたルックアップ値

のうちの第１の分割データのみを受信する。第２のコンピュートサーバは、第２の分割データ

を受信する。

８．各バウチャは、自分のリストＹ^ｐから値ｙ^ｐ _ｉのみを選択する。ここでｇｒｏｕｐ＝Ｈ（ｙ^ｐ _ｉ）ｍｏｄλ。

９．各バウチャは、ステップ２で作成した秘密鍵を使用して各値

を暗号化し、一連の隠し値

を生成する。バウチャは、それを用いてＳＫ^ｐを削除してよい。

１０．このような

に対して、バウチャは、次式

のような均等な（ｅｖｅｎ）ランダム分布から値を選択することによって、隠し値をｋ個のパーツ

に分割する。

１１．各バウチャは、ｋ個の異なるコンピュートサーバにパーツのリストを送信し、第１のコンピュートサーバは各隠し値の第１のパーツ

を受信し、第２のコンピュートサーバは第２のパート

を受信し、以下同様である。

１２．各コンピュートサーバは、リクエスタから、バウチャの各々の隠し値

の一部を受信する。

１３．各コンピュートサーバは、各バウチャから値

のリストを受信する。

１４．コンピュートサーバｊは、リクエスタから受信した値を、それぞれのバウチャから受信した値のリストから差し引き、新しい値

のリストを生成する。

１５．コンピュートサーバｊは、差分のリストをアグリゲータに送信する。

１６．アグリゲータは、各コンピュートサーバから値のリストを受信し、それらを足し合わせて合計

のリストを作成する。

１７．アグリゲータは、ステップ１６で算出した合計がゼロになった回数をカウントする。このような合計は、ルックアップ値ｘがバウチャのリストの１つに保持されている値と一致することを示す。

１８．アグリゲータは、見つかった一致する数をリクエスタに返信する。

明示的に述べられていない限り、本明細書に記載されている方法の実施形態は、特定の順序またはシーケンスに拘束されない。さらに、ここに記載されているすべての処方は例としてのみ意図されており、他のまたは異なる処方を使用してよい。さらに、説明した方法の実施形態またはその要素のいくつかは、同じ時点で発生してよく、実行されてよい。

本明細書では、本発明の特定の特徴を図示し、説明してきたが、当業者にとっては、多くの修正、置換、変更、および等価物が生じてよい。したがって、添付の特許請求の範囲は、本発明の真の精神の範囲内にあるすべての修正および変更をカバーすることが意図されていることを理解されたい。

さまざまな実施形態が紹介されている。これらの各実施形態は、もちろん、提示された他の実施形態の特徴を含んでいてよく、また、特に説明されていない実施形態は、本明細書に記載されたさまざまな特徴を含んでいてよい。

Claims (20)

1. ネットワーク内の複数のノード間でクエリの匿名検証を提供する方法であり、
   複数のノードのうちの少なくとも１つの他のノードによるクエリの検証のために、第１のサーバにおいて、ネットワーク内のリクエスタノードからクエリを受信するステップであって、
   クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの符号化された表現を含み、
   符号化された表現は、複数のシェアの第１のセットに分割される、ステップと、
   第１のサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの符号化された表現を受信するステップであって、
   少なくとも１つのバリデータノードからの符号化された表現は、複数のシェアの第２のセットに分割される、ステップと、
   複数のサポートサーバによって、リクエスタノードからの複数のシェアの第１のセットと、少なくとも１つのバリデータノードの複数のシェアの第２のセットとを比較するステップと、
   第２のサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定するステップと、
   一致する結果をリクエスタノードに出力するステップと、
   を含む、方法。
2. 符号化された表現は、ワンタイム暗号化を含み、ワンタイム暗号化は、リクエスタノードおよび少なくとも１つのバリデータノードによって使用される、請求項１に記載の方法。
3. 複数のシェアの第１のセットおよび第２のセットは、それぞれ各ノードに対してランダムに生成される、請求項１に記載の方法。
4. 前記比較するステップは、
   複数のシェアの第１のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信するステップと、
   複数のシェアの第２のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信するステップと、
   各サポートサーバにおいて、リクエスタノードから受信した値と、少なくとも１つのバリデータノードから受信した同等の値とを照合するステップと、
   をさらに含む、請求項１に記載の方法。
5. 前記決定するステップは、
   第２のサーバによって、複数のサポートサーバの各々からの結果の値のセットを集約するステップと、
   複数のサポートサーバからの結果の値のセットを統合するステップと、
   統合に基づいて、合計がゼロになるかどうかを識別するステップと、
   をさらに含む、請求項４に記載の方法。
6. 少なくとも１つのデータフィールドは顧客の身元に関する、請求項１に記載の方法。
7. ネットワークはクローズドネットワークであり、クローズドネットワークの各ノードは、クローズドネットワークの事前承認されたメンバである、請求項１に記載の方法。
8. 複数のサポートサーバの各々は一時的ノードを含み、一時的ノードは、持続的メモリまたはストレージ容量を含まない、請求項１に記載の方法。
9. 第２のサーバによって、一致した結果に関連する信頼度スコアを計算するステップと、
   一致した結果とともに信頼度スコアを出力するステップと、
   をさらに含む、請求項１に記載の方法。
10. ネットワーク内の複数のノード間でクエリの匿名検証を提供する方法であり、
    ネットワーク内のサポートノードにおいて、ネットワーク内のリクエスタノードからクエリを受信するステップであって、
    クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの一方向性関数表現を含む、ステップと、
    サポートサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現を受信するステップと、
    サポートサーバによって、リクエスタノードからのクエリを、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現と比較するステップと、
    アグリゲータサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定するステップと、
    一致する結果をリクエスタノードに出力するステップと、
    を含む、方法。
11. ネットワーク内の複数のノード間でクエリの匿名検証を提供するシステムであり、
    プロセッサおよびメモリを有するサーバと、メモリに格納され、プロセッサで実行するように構成された１つまたは複数のコードセットとを含み、コードセットは、実行されると、プロセッサが、
    複数のノードのうちの少なくとも１つの他のノードによるクエリの検証のために、第１のサーバにおいて、ネットワーク内のリクエスタノードからクエリを受信し、
    クエリは、リクエスタノードの情報のうちの少なくとも１つのデータポイントの符号化された表現を含み、
    符号化された表現は、複数のシェアの第１のセットに分割され、
    第１のサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報のうちの少なくとも１つのデータポイントの符号化された表現を受信し、
    少なくとも１つのバリデータノードからの符号化された表現は、複数のシェアの第２のセットに分割され、
    複数のサポートサーバによって、リクエスタノードからの複数のシェアの第１のセットと、少なくとも１つのバリデータノードの複数のシェアの第２のセットとを比較し、
    第２のサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定し、
    一致する結果をリクエスタノードに出力する、
    ように構成される、システム。
12. 符号化された表現は、ワンタイム暗号化を含み、ワンタイム暗号化は、リクエスタノードおよび少なくとも１つのバリデータノードによって使用される、請求項１１に記載のシステム。
13. 複数のシェアの第１のセットおよび第２のセットは、それぞれ各ノードに対してランダムに生成される、請求項１１に記載のシステム。
14. 前記比較は、
    複数のシェアの第１のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信し、
    複数のシェアの第２のセットの各シェアを、そのセットの他のシェアとは別のサポートサーバに送信し、
    各サポートサーバにおいて、リクエスタノードから受信した値と、少なくとも１つのバリデータノードから受信した同等の値とを照合する、
    ことをさらに含む、請求項１１に記載のシステム。
15. 前記決定は、
    第２のサーバによって、複数のサポートサーバの各々からの結果の値のセットを集約し、
    複数のサポートサーバからの結果の値のセットを統合し、
    統合に基づいて、合計がゼロになるかどうかを識別する、
    ことをさらに含む、請求項１４に記載のシステム。
16. 少なくとも１つのデータフィールドは顧客の身元に関する、請求項１１に記載のシステム。
17. ネットワークはクローズドネットワークであり、クローズドネットワークの各ノードは、クローズドネットワークの事前承認されたメンバである、請求項１１に記載のシステム。
18. 複数のサポートサーバの各々は一時的ノードを含み、一時的ノードは、持続的メモリまたはストレージ容量を含まない、請求項１１に記載のシステム。
19. 第２のサーバによって、一致した結果に関連する信頼度スコアを計算し、
    一致した結果とともに信頼度スコアを出力する、
    ことをさらに構成される、請求項１１に記載のシステム。
20. ネットワーク内の複数のノード間でクエリの匿名検証を提供するシステムであり、
    プロセッサおよびメモリを有するサーバと、メモリに格納され、プロセッサで実行するように構成された１つまたは複数のコードセットとを含み、コードセットは、実行されると、プロセッサが、
    ネットワーク内のサポートノードにおいて、ネットワーク内のリクエスタノードからクエリを受信し、
    クエリは、リクエスタノードの情報の少なくとも１つのデータポイントの一方向性関数表現を含み、
    サポートサーバにおいて、複数のノードのうちの少なくとも１つのバリデータノードから、バリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現を受信し、
    サポートサーバによって、リクエスタノードからのクエリを、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントの一方向性関数表現と比較し、
    アグリゲータサーバによって、比較に基づいて、リクエスタノードの情報の少なくとも１つのデータポイントが、少なくとも１つのバリデータノードの情報の少なくとも１つのデータポイントと一致するか否かを決定し、
    一致する結果をリクエスタノードに出力する、
    ように構成される、システム。
    
    

Images