特表 2024-541996 プライバシー保護ドメインネームサービス（ＤＮＳ）

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-13

(54)【発明の名称】プライバシー保護ドメインネームサービス（ＤＮＳ）

(51)【国際特許分類】

   G09C 1/00 20060101AFI20241106BHJP

   H04L 61/4511 20220101ALI20241106BHJP

【ＦＩ】

G09C1/00 660D

G09C1/00 620Z

H04L61/4511

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024525439

(86)(22)【出願日】2021-11-02

(85)【翻訳文提出日】2024-05-22

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

(87)【国際公開番号】W WO2023078529

(87)【国際公開日】2023-05-11

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＦＡＣＥＢＯＯＫ

２．ＷＩＫＩＰＥＤＩＡ

(71)【出願人】

【識別番号】312016539

【氏名又は名称】ビットディフェンダー アイピーアール マネジメント リミテッド

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(72)【発明者】

【氏名】ブルチャヌ，エレナ

(72)【発明者】

【氏名】ボルボチャヌ，マダリナ

(72)【発明者】

【氏名】ハレー，エマヌエラ

(72)【発明者】

【氏名】ロッサ，ゲオルジーナ・ミルナ

(72)【発明者】

【氏名】ティティウ，ラドゥ

(72)【発明者】

【氏名】セベレ，ボグダン・セー

(57)【要約】

記述されているシステムおよび方法は、プライバシー保護ＤＮＳのやり取りを実行することを可能にする。いくつかの実施形態においては、クライアントマシンが、ネームサーバとの個人情報検索（ＰＩＲ）のやり取りに携わる。クライアントからの暗号化されたクエリ（そのクエリは、ドメインネームに従って定式化されている）を受信したことに応答して、ネームサーバは、それぞれのクエリを復号することなくドメインネームデータベースからレコード（たとえば、ＩＰアドレス）を抽出することが可能である。いくつかの実施形態は、準同型暗号の使用によって、そのような情報検索を達成する。

【特許請求の範囲】

【請求項1】

ドメインネームサービス（ＤＮＳ）ルックアップを実行する方法であって、コンピュータシステムの少なくとも１つのハードウェアプロセッサを用いて、
ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかを前記ドメインネームに従って決定することと、
前記プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化することであって、前記ハッシュインデックスは準同型暗号化手順に従って暗号化され、前記ハッシュインデックスは前記ドメインネームに従って決定される、定式化することと、
前記プライベートクエリを定式化したことに応答して、ネームサーバへ前記プライベートクエリを伝送することであって、前記ネームサーバは、前記プライベートクエリに従って前記ドメインネームデータベースへの暗号化されたルックアップを実行して前記レコードの暗号化を生成するように構成された、伝送することと、
前記レコードの前記暗号化を含むプライベート応答を前記ネームサーバから受信したことに応答して、準同型復号手順に従って前記プライベート応答の内容を復号することと
を行うステップを含む方法。

【請求項2】

請求項１に記載の方法であって、前記プライバシー条件が満たされているかどうかを決定したことに応答して、「いいえ」の場合には、前記コンピュータシステムの少なくとも１つのハードウェアプロセッサを用いて、
前記ドメインネームに従って別のクエリを定式化することであって、前記別のクエリの内容は、非準同型暗号化手順に従って暗号化される、定式化することと、
前記別のクエリを前記ネームサーバへ伝送することと
を行うステップをさらに含む方法。

【請求項3】

請求項１に記載の方法であって、前記ドメインネームは一連のトークンを含み、前記プライバシー条件が満たされているかどうかを決定することは、前記一連のトークンのうちの選択されたトークンがトークンの参照リストのいずれかのメンバーと一致するかどうかを決定することを含む、方法。

【請求項4】

請求項３に記載の方法であって、前記選択されたトークンは、ドメイントークンまたはプレフィックストークンを含む、方法。

【請求項5】

請求項１に記載の方法であって、前記プライバシー条件が満たされているかどうかを前記ネームサーバの権威ゾーンにさらに従って決定するステップを含む方法。

【請求項6】

請求項５に記載の方法であって、前記ネームサーバがトップレベルドメイン（ＴＬＤ）ネームサーバを含む場合に、前記プライバシー条件が満たされていないと決定するステップをさらに含む方法。

【請求項7】

請求項１に記載の方法であって、前記プライベートクエリは、前記ドメインネームデータベースを前記ネームサーバに接続された複数のドメインネームデータベースのうちから識別するバケットインデックスをさらに含む、方法。

【請求項8】

請求項１に記載の方法であって、前記レコードはインターネットプロトコル（ＩＰ）アドレスを含む、方法。

【請求項9】

請求項１に記載の方法であって、前記レコードは、前記ドメインネームによって表されているドメインにアクセスすることがユーザをコンピュータセキュリティの脅威にさらすかどうかを示すセキュリティ指標を含む、方法。

【請求項10】

少なくとも１つのハードウェアプロセッサを含むコンピュータシステムであって、前記少なくとも１つのハードウェアプロセッサは、
ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかを前記ドメインネームに従って決定することと、
前記プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化することであって、前記ハッシュインデックスは準同型暗号化手順に従って暗号化され、前記ハッシュインデックスは前記ドメインネームに従って決定される、定式化することと、
前記プライベートクエリを定式化したことに応答して、ネームサーバへ前記プライベートクエリを伝送することであって、前記ネームサーバは、前記プライベートクエリに従って前記ドメインネームデータベースへの暗号化されたルックアップを実行して前記レコードの暗号化を生成するように構成された、伝送することと、
前記レコードの前記暗号化を含むプライベート応答を前記ネームサーバから受信したことに応答して、準同型復号手順に従って前記プライベート応答の内容を復号することと
を行うように構成された、コンピュータシステム。

【請求項11】

請求項１０に記載のコンピュータシステムであって、前記少なくとも１つのハードウェアプロセッサは、前記プライバシー条件が満たされているかどうかを決定したことに応答して、「いいえ」の場合には、
前記ドメインネームに従って別のクエリを定式化することであって、前記別のクエリの内容は、非準同型暗号化手順に従って暗号化される、定式化することと、
前記別のクエリを前記ネームサーバへ伝送することと
を行うようにさらに構成された、コンピュータシステム。

【請求項12】

請求項１０に記載のコンピュータシステムであって、前記ドメインネームは一連のトークンを含み、前記プライバシー条件が満たされているかどうかを決定することは、前記一連のトークンのうちの選択されたトークンがトークンの参照リストのいずれかのメンバーと一致するかどうかを決定することを含む、コンピュータシステム。

【請求項13】

請求項１２に記載のコンピュータシステムであって、前記選択されたトークンは、ドメイントークンまたはプレフィックストークンを含む、コンピュータシステム。

【請求項14】

請求項１０に記載のコンピュータシステムであって、前記少なくとも１つのハードウェアプロセッサは、前記プライバシー条件が満たされているかどうかを前記ネームサーバの権威ゾーンにさらに従って決定するように構成された、コンピュータシステム。

【請求項15】

請求項１４に記載のコンピュータシステムであって、前記少なくとも１つのハードウェアプロセッサは、前記ネームサーバがトップレベルドメイン（ＴＬＤ）ネームサーバを含む場合に、前記プライバシー条件が満たされていないと決定するようにさらに構成された、コンピュータシステム。

【請求項16】

請求項１０に記載のコンピュータシステムであって、前記プライベートクエリは、前記ドメインネームデータベースを前記ネームサーバに接続された複数のドメインネームデータベースのうちから識別するバケットインデックスをさらに含む、コンピュータシステム。

【請求項17】

請求項１０に記載のコンピュータシステムであって、前記レコードは、インターネットプロトコル（ＩＰ）アドレスを含む、コンピュータシステム。

【請求項18】

請求項１０に記載のコンピュータシステムであって、前記レコードは、前記ドメインネームによって表されているドメインにアクセスすることがユーザをコンピュータセキュリティの脅威にさらすかどうかを示すセキュリティ指標を含む、コンピュータシステム。

【請求項19】

命令を格納している非一時的コンピュータ可読メディアであって、前記命令は、コンピュータシステムの少なくとも１つのハードウェアプロセッサによって実行されたときに、
ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかを前記ドメインネームに従って決定することと、
前記プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化することであって、前記ハッシュインデックスは準同型暗号化手順に従って暗号化され、前記ハッシュインデックスは前記ドメインネームに従って決定される、定式化することと、
前記プライベートクエリを定式化したことに応答して、ネームサーバへ前記プライベートクエリを伝送することであって、前記ネームサーバは、前記プライベートクエリに従って前記ドメインネームデータベースへの暗号化されたルックアップを実行して前記レコードの暗号化を生成するように構成された、伝送することと、
前記レコードの前記暗号化を含むプライベート応答を前記ネームサーバから受信したことに応答して、準同型復号手順に従って前記プライベート応答の内容を復号することと
を前記コンピュータシステムに行わせる、非一時的コンピュータ可読メディア。

【請求項20】

複数のクライアントとのドメインネームサービス（ＤＮＳ）トランザクションに携わるように構成されたサーバコンピュータシステムであって、前記サーバコンピュータシステムは少なくとも１つのハードウェアプロセッサを含み、前記少なくとも１つのハードウェアプロセッサは、
前記複数のクライアントのうちの１つのクライアントからプライベートクエリを受信することであって、前記プライベートクエリは、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含み、前記ハッシュインデックスは準同型暗号化手順に従って暗号化され、前記ハッシュインデックスはドメインネームに従って決定される、受信することと、
前記プライベートクエリを受信したことに応答して、前記プライベートクエリに従って前記ドメインネームデータベースへの暗号化されたルックアップを実行して前記レコードの暗号化を生成することと、
前記レコードの前記暗号化を含むプライベート応答を前記クライアントへ伝送することと
を行うように構成された、サーバコンピュータシステム。

【発明の詳細な説明】

【技術分野】

【0001】

[0001]本発明は、オンライン通信のプライバシーを保護するためのシステムおよび方法に関し、詳細には、リモートエンティティーがインターネットユーザの閲覧習慣に関する情報を取得するのを防止することに関する。

【背景技術】

【0002】

[0002]インターネットを閲覧することは、現代の生活および仕事の不可欠な構成要素になっている。インターネットアクセスにおける激増に続いて、いくつかの営利目的のならびに悪意あるエンティティーが、個々のインターネットユーザの閲覧履歴および／またはパターンにアクセスして分析することにますます関心を持っている。そしてそのような情報は、広告のターゲット設定を行うために、およびさまざまなサービスをそれぞれのユーザに届けるために使用される場合がある。しかしながら、同じタイプの情報が、性的な指向、政治的なおよび宗教的な見解、人種、薬物使用、諜報等など、ユーザの個性のより敏感な側面に従ってユーザのプロファイリングおよび／またはターゲット設定を行うために使用される場合がある。ますます多数のインターネットユーザが、プライバシーと、自分たちのオンライン行動をモニタすることを企業および／または国家に許可することが自分たちの権利にどのように影響する可能性があるか、ならびにさまざまな種類の脅威および虐待に自分たちをどのようにさらす可能性があるか、とに関して懸念を抱いている。

【0003】

[0003]ユーザの閲覧履歴が収集される一般的な様式は、ドメインネームサービス（ＤＮＳ）要求を介する。ＤＮＳは、典型的には、ドメインネームをネットワーク（たとえば、ＩＰ）アドレスへ変換するサービスを指し、そしてこれは、電子デバイスが通信ネットワークを介してデータをやり取りすることを可能にする。ＤＮＳは元来、プライバシーとは対照的に、スピードおよび利便性のために設計されたものなので、従来、ＤＮＳプロバイダおよびインターネットサービスプロバイダは、クライアントによって発行されたＤＮＳ要求に対して実質的に妨げられずにアクセスできてきた。近年においては、いくつかの取り組みが、古くからのＤＮＳに対する代替手段を提供することに向けられた。いくつかの例は、数ある中でも、「ＤＮＳ ｏｖｅｒ ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）」および「ＤＮＳ ｏｖｅｒ ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）」として知られる一連のプロトコルを含む。そのようなバージョンのＤＮＳは、クライアントからの個々の要求および／またはサーバ応答を暗号化し、それによって原則として、エンドクライアントとネームサーバとを除いたエンティティーは、それぞれのデータにアクセスできない。たとえば、そのようなプロトコルは、インターネットサービスプロバイダおよび／または悪意ある第三者がユーザのＤＮＳ要求を覗き見するのを防止することが可能である。しかしながらデータは、クライアントとネームサーバとの間における転送中にのみ暗号化されるので、そのようなプロトコルは、ＤＮＳプロバイダ自身がそれぞれのユーザの閲覧データを収集するのを防止しない。

【0004】

[0004]そのため、より有能で堅牢なプライバシー保護ドメインネームサービスを開発することには、相当な関心がある。

【発明の概要】

【0005】

[0005]一態様によれば、ドメインネームサービス（ＤＮＳ）ルックアップを実行する方法が、ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかをドメインネームに従って決定するためにコンピュータシステムの少なくとも１つのハードウェアプロセッサを採用するステップを含む。この方法はさらに、プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化するステップであって、ハッシュインデックスが、準同型暗号化手順に従って暗号化され、ハッシュインデックスが、ドメインネームに従って決定される、ステップを含む。この方法はさらに、プライベートクエリを定式化したことに応答して、プライベートクエリに従ってドメインネームデータベースへの暗号化されたルックアップを実行してレコードの暗号化を生成するように構成されたネームサーバへプライベートクエリを伝送するステップと、レコードの暗号化を含むプライベート応答をネームサーバから受信したことに応答して、準同型復号手順に従ってプライベート応答の内容を復号するステップとを含む。

【0006】

[0006]別の態様によれば、コンピュータシステムが、ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかをドメインネームに従って決定するように構成された少なくとも１つのハードウェアプロセッサを含む。少なくとも１つのハードウェアプロセッサはさらに、プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化することであって、ハッシュインデックスが、準同型暗号化手順に従って暗号化され、ハッシュインデックスが、ドメインネームに従って決定される、定式化することを行うように構成されている。少なくとも１つのハードウェアプロセッサはさらに、プライベートクエリを定式化したことに応答して、プライベートクエリに従ってドメインネームデータベースへの暗号化されたルックアップを実行してレコードの暗号化を生成するように構成されたネームサーバへプライベートクエリを伝送することと、レコードの暗号化を含むプライベート応答をネームサーバから受信したことに応答して、準同型復号手順に従ってプライベート応答の内容を復号することとを行うように構成されている。

【0007】

[0007]別の態様によれば、非一時的コンピュータ可読メディアが命令を格納しており、それらの命令は、コンピュータシステムの少なくとも１つのハードウェアプロセッサによって実行されたときに、ドメインネームの指標を受信したことに応答して、プライバシー条件が満たされているかどうかをドメインネームに従って決定することをコンピュータシステムに行わせる。それらの命令はさらに、プライバシー条件が満たされているかどうかを決定したことに応答して、「はい」の場合には、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含むプライベートクエリを定式化することであって、ハッシュインデックスが、準同型暗号化手順に従って暗号化され、ハッシュインデックスが、ドメインネームに従って決定される、定式化することをコンピュータシステムに行わせる。それらの命令はさらに、プライベートクエリを定式化したことに応答して、プライベートクエリに従ってドメインネームデータベースへの暗号化されたルックアップを実行してレコードの暗号化を生成するように構成されたネームサーバへプライベートクエリを伝送することと、レコードの暗号化を含むプライベート応答をネームサーバから受信したことに応答して、準同型復号手順に従ってプライベート応答の内容を復号することとをコンピュータシステムに行わせる。

【0008】

[0008]別の態様によれば、サーバコンピュータシステムが、複数のクライアントとのドメインネームサービス（ＤＮＳ）トランザクションに携わるように構成されている。サーバコンピュータシステムは、複数のクライアントのうちの１つのクライアントからプライベートクエリを受信することであって、プライベートクエリが、ドメインネームデータベース内のレコードのロケーションを示すハッシュインデックスの暗号化を含み、ハッシュインデックスが、準同型暗号化手順に従って暗号化され、ハッシュインデックスが、ドメインネームに従って決定される、受信することを行うように構成された少なくとも１つのハードウェアプロセッサを含む。少なくとも１つのハードウェアプロセッサはさらに、プライベートクエリを受信したことに応答して、プライベートクエリに従ってドメインネームデータベースへの暗号化されたルックアップを実行してレコードの暗号化を生成することと、レコードの暗号化を含むプライベート応答をクライアントへ伝送することとを行うように構成されている。

【図面の簡単な説明】

【0009】

[0009]本発明の前述の態様および利点は、以降の発明を実施するための形態を読めば、および図面を参照すれば、よりよく理解されるようになるであろう。

【図1】[0010]本発明のいくつかの実施形態による例示的なプライバシー保護電子通信システムを示す図である。

【図2】[0011]本発明のいくつかの実施形態による、複数の通信可能に結合されたネームサーバを含む例示的なドメインネームサービス（ＤＮＳ）サーバシステムを示す図である。

【図3】[0012]従来技術において知られている典型的なＤＮＳトランザクションを示す図である。

【図4】[0013]従来技術において知られているＤＮＳクエリおよび応答を示す図である。

【図5】[0014]本発明のいくつかの実施形態による、インターネットドメインの例示的な完全修飾ドメインネーム（ＦＱＤＮ）および複数の例示的な部分修飾ドメインネーム（ＰＱＤＮ）を示す図である。

【図6】[0015]本発明のいくつかの実施形態による例示的なドメインネーム空間を示す図である。

【図7】[0016]本発明のいくつかの実施形態によるＤＮＳトランザクションを示す図であり、そのトランザクションは、プライベートクエリおよびプライベート応答を含む。

【図8】[0017]本発明のいくつかの実施形態によるドメインネームデータベースの例示的な内容を示す図である。

【図9】[0018]本発明のいくつかの実施形態による例示的な個人情報検索（ＰＩＲ）クエリおよび例示的なＰＩＲ応答を示す図である。

【図10】[0019]本発明のいくつかの実施形態によるクライアントシステム上で実行する例示的なコンポーネントを示す図である。

【図11】[0020]本発明のいくつかの実施形態によるクライアントシステムＤＮＳリゾルバによって実行されるステップの例示的なシーケンスを示す図である。

【図12】[0021]本発明のいくつかの実施形態によるＤＮＳサーバシステム上で実行する例示的なコンポーネントを示す図である。

【図13】[0022]本発明のいくつかの実施形態によるＤＮＳサーバデータベースメンテナンスモジュールによって実行されるステップの例示的なシーケンスを示す図である。

【図14】[0023]本発明のいくつかの実施形態によるＤＮＳサーバＰＩＲモジュールによって実行されるステップの例示的なシーケンスを示す図である。

【図15】[0024]本発明のいくつかの実施形態による、ＤＮＳルックアップを実行するためにクライアントＤＮＳリゾルバによって実行されるステップの例示的なシーケンスを示す図である。

【図16】[0025]本発明のいくつかの実施形態による、クラスタへとグループ化されたドメインの例示的なセットを示す図である。

【図17】[0026]本明細書において記述されている方法およびアルゴリズムのうちのいくつかを実行するように構成されたコンピューティングアプライアンスの例示的なハードウェアコンポーネントを示す図である。

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

【0010】

[0027]以降の記述においては、構造どうしの間におけるすべての列挙されている接続は、直接の有効な接続、または中間構造を通じた間接的な有効な接続であることが可能であるということが理解される。要素のセットは、１つまたは複数の要素を含む。要素のいかなる列挙も、少なくとも１つの要素を指すものと理解される。複数の要素は、少なくとも２つの要素を含む。他に必要とされない限り、いずれの記述されている方法ステップも、必ずしも特定の示されている順序で実行される必要はない。第２の要素から導き出される第１の要素（たとえば、データ）は、第２の要素に等しい第１の要素、ならびに第２の要素および任意選択でその他のデータを処理することによって生成される第１の要素を包含する。パラメータに従って決定または決断行うことは、パラメータに従って、および任意選択でその他のデータに従って決定または決断を行うことを包含する。他に指定されない限り、ある数量／データの指標は、その数量／データそのもの、またはその数量／データそのものとは異なる指標であることが可能である。コンピュータプログラムは、タスクを実行する一連のプロセッサ命令である。本発明のいくつかの実施形態において記述されているコンピュータプログラムは、スタンドアロンのソフトウェアエンティティー、またはその他のコンピュータプログラムのサブエンティティー（たとえば、サブルーチン、ライブラリ）であることが可能である。ネットワークドメインは、コンピュータネットワークの個別の部分を形成する相互接続されたコンピューティングデバイスのグループから構成されている。インターネットドメインは、パブリックインターネットに接続されたネットワークドメインである。ドメインネームは、ネットワーク／インターネットドメインのアドレスを識別するラベル／エイリアスである。「データベース」という用語は、本明細書においては、データの任意の編成された集合を示すために使用されている。コンピュータ可読メディアは、磁気、光、および半導体ストレージメディア（たとえばハードドライブ、光ディスク、フラッシュメモリ、ＤＲＡＭ）などの非一時的メディア、ならびに導電ケーブルおよび光ファイバリンクなどの通信リンクを包含する。いくつかの実施形態によれば、本発明は、とりわけ、本明細書において記述されている方法を実行するようにプログラムされたハードウェア（たとえば１つまたは複数のプロセッサ）、ならびに本明細書において記述されている方法を実行するための命令をエンコードしているコンピュータ可読メディアを含むコンピュータシステムを提供する。

【0011】

[0028]以降の記述は、本発明の実施形態を、必ずしも限定としてではなく、例として示している。
[0029]図１は、本発明のいくつかの実施形態によるプライバシー保護電子通信システム１０を示している。一式の例示的なクライアントデバイス１２ａ～ｆが、通信リンクを介して互いと、および／またはリモートコンテンツサーバコンピュータ１６と通信して、ウェブコンテンツ、電子メッセージ、さまざまなドキュメント等などのデータをやり取りする。クライアントデバイス１２ａ～ｆは、パーソナルコンピュータシステム、企業のメインフレームコンピュータ、モバイルコンピューティングプラットフォーム（たとえば、ラップトップコンピュータ、タブレット、モバイル電話）、エンターテイメントデバイス（たとえば、ＴＶ、ゲームコンソール）、ウェアラブルデバイス（たとえば、スマートウォッチ、フィットネスバンド）、家庭用機器（たとえば、冷蔵庫、洗濯機）、ならびに、プロセッサと、メモリと、それぞれのデバイスがその他のデバイス／コンピュータシステムと通信することを可能にする通信インターフェースとを含む任意のその他の電子デバイスを含むことが可能である。

【0012】

[0030]図１の例示的な構成においては、クライアントデバイス１２ａ～ｅは、ローカルエリアネットワーク（ＬＡＮ）などのローカルネットワーク１３によって相互接続されている。１つの例示的な使用事例シナリオにおいては、デバイス１２ａ～ｅは、家庭内の電子デバイスに相当し、ローカルネットワーク１３は、ホームネットワークに相当する。別の使用事例シナリオにおいては、クライアントデバイス１２ａ～ｅは、企業のオフィスまたは部署に配置されて企業ＬＡＮによって相互接続されたコンピュータに相当することが可能である。デバイス１２ａ～ｅはさらに、ワイドエリアネットワーク（ＷＡＮ）および／またはインターネットなど、拡張ネットワーク１５に接続されることが可能である。いくつかの実施形態においては、ルータ１４が、たとえば、ローカルネットワーク１３に接続されたクライアント１２ａ～ｅにネットワークアドレスを割り振って、そのようなアドレスに従って個々の通信をルーティングすることによって、ローカルネットワーク１３内のデータトラフィックを制御および／または管理する。図１において示されているようないくつかの実施形態においては、クライアントデバイス１２ａ～ｅと拡張ネットワーク１５との間におけるネットワークトラフィックの少なくとも一部がルータ１４を通過するという意味で、ルータ１４は、ローカルネットワーク１３へのゲートウェイとして構成される。図１における例示的なデバイス１２ｆなど、その他のクライアントデバイスは、ローカルネットワーク１３に接続されないことが可能であり、代わりに、たとえばモバイルテレフォニーネットワークまたはパブリックＷｉＦｉホットスポットを経由して、拡張ネットワーク１５に直接接続することが可能である。

【0013】

[0031]本発明のいくつかの実施形態によれば、ドメインネームサービス（ＤＮＳ）サーバシステム２０が、プライバシー保護ドメインネームサービスをクライアントデバイス１２ａ～ｆに提供する。ドメインネームサービスは、本明細書においては、ドメインネームをネットワークアドレスへと、および／またはその逆へと変換することと、とりわけ、ドメイン登録データ（たとえば、ＷＨＯＩＳデータ）、および特定のドメインがドメインの特定のカテゴリー／クラスタに属するかどうか、ドメインがアダルトコンテンツを配信しているかどうか、ドメインが悪意あるアクティビティー（たとえば、ボットネット、インターネット詐欺）に携わっているかどうかなどの指標を含むその他のドメイン情報を提供することとを包含することを意図されている。ＤＮＳサーバシステム２０は、図２において示されている例示的なネームサーバ２０ａ～ｄなど、一式の通信可能に結合されたコンピュータを総称的に表す。それぞれのそのようなネームサーバの機能は、以降でさらに詳述される。要求をＤＮＳサーバシステム２０へ送信することは、それぞれの要求をネームサーバ２０ａ～ｄのうちのいずれかへ送信することを包含する。

【0014】

[0032]クライアントデバイス１２ａ～ｆとコンテンツサーバ１６との間における典型的なデータやり取りは、いくつかのステップを含む。伝送は、典型的には、コンテンツサーバ１６のネットワークアドレス（たとえば、インターネットプロトコル（ＩＰ）アドレス）の知識を必要とする。多くの場合、このアドレスは、さまざまな理由のためにクライアントデバイスに知られていない。たとえば、複数のミラーコンテンツサーバマシンがあり得、クライアントは、それぞれのミラーサーバの現在の負荷に従って、またはクライアントデバイスの現在の地理的ロケーションに従って、最も都合のよいサーバへ動的に導かれることが可能である。しかしながらクライアントデバイスは、サーバ１６のドメインネームを知ることが可能である。本明細書における「ドメインネーム」という用語は、必要とされるネットワークアドレスの任意のエイリアスを示す。コンテンツサーバ１６への接続を確立するために、それぞれのクライアントデバイス上で実行するソフトウェアエンティティーが、それゆえに、ＩＰアドレス自体の代わりに、それぞれのドメインネームにアクセスする要求を発行することが可能である。それに応答して、別のソフトウェアエンティティー（たとえば、それぞれのクライアント上で実行するオペレーティングシステムのコンポーネント）が、要求をインターセプトし、エイリアス／ドメインネームを実際のネットワークアドレスへ変換することを試み、そしてその後に要求を正しいネットワークロケーションへ伝送することが可能である。そのような変換は、図１におけるサーバシステム２０などのＤＮＳプロバイダを呼び出すことが可能である。

【0015】

[0033]図３～図４は、当技術分野において知られているＤＮＳプロトコルに従った典型的なメッセージやり取りを示している。クライアントデバイス１２は、ＤＮＳクエリ２２をＤＮＳサーバシステム２０へ伝送し、クエリ２２は、インターネットドメイン３０の指標（たとえば、図３において示されているようなドメインネーム）と、質問Ｑのタイプの指標とを含む。質問のタイプは、ＤＮＳサーバ２０によって返されるＤＮＳリソースレコードのタイプを示す。例示的な質問は、インターネットプロトコルの第４バージョン（ＩＰｖ４）において定式化されたＩＰアドレスを要求する「Ａ」、およびインターネットプロトコルの第６バージョン（ＩＰｖ６）において定式化されたＩＰアドレスを返す「ＡＡＡＡ」を含む。その他の例示的な質問／リソースレコードタイプは、「ＴＸＴ」、「ＰＴＲ」、「ＬＯＣ」などを含む。それに応答して、ＤＮＳサーバシステム２０は、要求側クライアントへＤＮＳ応答２４を返すことが可能であり、応答２４は、それぞれのドメインネーム／エイリアスに対応するリソースレコードネットワークのエンコーディングを含む。図４における例においては、レコードのタイプは、３２ビットＩＰｖ４フォーマットでのＩＰアドレス４０である。いくつかのケースにおいては、たとえばＤＮＳ ｏｖｅｒ ＨＴＴＰＳプロトコルを使用するシステムにおいては、ＤＮＳクエリ２２および／またはＤＮＳ応答２４は、暗号化されることが可能である。

【0016】

[0034]図５は、インターネットドメインの例示的なドメインネームを示している。ドメインネームは、デリミタシンボル３４（示されている例においては、ドット）によって区切られたトークン／ラベル３２ａ～ｄの順序付けられたシーケンスを通じてそれぞれのドメインを完全にかつ明確に指定する完全修飾ドメインネーム（ＦＱＤＮ）３６から構成されることが可能である。ＦＱＤＮトークン３２ａ～ｄのサブセット／サブシーケンスを含むＦＱＤＮ３６の断片は、部分修飾ドメインネーム（ＰＱＤＮ）として一般に知られている。アイテム３８ａ～ｃは、ＦＱＤＮ３６のさまざまな例示的なＰＱＤＮを示す。ＦＱＤＮ３６とは対照的に、それぞれのＰＱＤＮ３８ａ～ｃは、いくらかのレベルの曖昧さを伴ってそれぞれのドメインを指定し、すなわち、同じ特徴的なＰＱＤＮを有する複数のＦＱＤＮが存在することが可能である。

【0017】

[0035]一連のトークンとしてのドメインネーム表現（図５を参照されたい）は、図６において示されているようなドメインネーム空間のツリー状の階層表現と整合しており、ＦＱＤＮ３６のそれぞれのトークン３２ａ～ｄは、ツリーの分岐に対応し、デリミタ（たとえば、ドット）のそれぞれのインスタンスは、分岐点に対応する。ドメインネーム階層は、少なくともルートレベル（「．」）と、ｃｏｍ、ｎｅｔ、ｆａｓｈｉｏｎ、ｔｖなどのトークン、およびｒｏ、ｆｒなどの国を示すトークンなどを含むトップレベルドメイン（ＴＬＤ）レベルと、ｗｉｋｉｐｅｄｉａ、ｆａｃｅｂｏｏｋなどのトークンなどを含むドメインレベルと、さまざまなドメイン固有のプレフィックストークンを含むサブドメインレベルとを含むいくつかの注目すべきレベルを有する。個々のトークンからＦＱＤＮ３６を組み立てることは、それゆえに、図６において示されているように、ツリー階層を末端のリーフからルートまでたどることに相当する。明確にするために、ＴＬＤレベルでドメインネームを特徴付けるトークン（典型的にはＦＱＤＮ３６の最後のトークン）が、本明細書においてはＴＬＤトークンとみなされることになる。同様に、ドメインレベルでドメインネームを特徴付けるトークン（典型的にはＦＱＤＮ３６の最後から２番目のトークン）が、本明細書においてはドメイントークンとみなされることになる。最後に、ＦＱＤＮ３６においてドメイントークンに先行するすべてのトークンが、本明細書においてはプレフィックストークンとみなされることになる。

【0018】

[0036]ドメインネームサービスは、単一のネームサーバが単独で完全修飾ドメインネームを解決することができないように編成されることが可能である。代わりに、ドメインネーム空間は、複数の権威ゾーンへと分割され、それぞれの権威ゾーンは、個別のネームサーバによって解決される。典型的には、それぞれの権威ゾーンは、図６における例示的な権威ゾーン３７ａ～ｃによって示されているように、ドメインネーム階層の選択されたサブツリー／分岐を含む。示されている例においては、ネームサーバ２０ｂ－ｃ－ｄは、それぞれ権威ゾーン３７ａ－ｂ－ｃ内のドメインネームを解決する。

【0019】

[0037]いくつかの実施形態においては、ＦＱＤＮを対応するＩＰアドレスに解決することは、反復する様式で進行し、それぞれの連続した反復は、ドメインネーム階層の連続したレベルへ進展する。それぞれの連続した反復は、ＦＱＤＮ３６の個別のトークンに従って決定されることが可能である。それぞれの反復は、ＤＮＳクエリを個別のネームサーバへ送信することと、それに応答して、別のネームサーバのＩＰアドレスを指定するＤＮＳ応答を受信することとを含むことが可能である。ドメインネームのＴＬＤレベル、すなわち、「．ｏｒｇ」などのＴＬＤトークンを解決するサーバが、本明細書においてはルートネームサーバとみなされる（たとえば、ルートネームサーバ２０ｂを参照されたい）。ドメインレベルでのドメインネーム、すなわち、ＦＱＤＮ３６のドメイントークンを解決するサーバが、本明細書においてはＴＬＤネームサーバとみなされる（たとえば、「．ｏｒｇ」トップレベルドメインのドメインどうしの間において解決を行うＴＬＤネームサーバ２０ｃを参照されたい）。サブドメインレベル、すなわち、ＦＱＤＮ３６のプレフィックストークンを解決するサーバが、本明細書においては、それぞれのドメインに関する権威サーバとみなされる（たとえば、「ｗｉｋｉｍｅｄｉａ．ｏｒｇ」のサブドメインどうしの間において解決を行う権威サーバ２０ｄを参照されたい）。図６による一例においては、ドメインネーム「ｔｅｘｔ－ｌｂ．ｃｏｄｆｗ．ｗｉｋｉｍｅｄｉａ．ｏｒｇ」を解決することは、第１のＤＮＳクエリをルートネームサーバ２０ｂへ送信することと、それに応答して、「．ｏｒｇ」トップレベルドメインの権威ゾーンを解決することを担当するＴＬＤネームサーバ２０ｃのＩＰアドレスをネームサーバ２０ｂから受信することとを含む。反復の次なる段階は、第２のＤＮＳクエリをＴＬＤネームサーバ２０ｃへ送信することと、それに応答して「ｗｉｋｉｍｅｄｉａ．ｏｒｇ」ドメインの権威ネームサーバ２０ｄのＩＰアドレスをネームサーバ２０ｃから受信することとを含むことが可能である。反復のさらに別の段階は、第３のＤＮＳクエリを権威ネームサーバ２０ｄへ送信することと、それに応答して、ＦＱＤＮ「ｔｅｘｔ－ｌｂ．ｃｏｄｆｗ．ｗｉｋｉｍｅｄｉａ．ｏｒｇ」によって識別されるコンテンツサーバのＩＰアドレスをネームサーバ２０ｄから受信することとを含むことが可能である。

【0020】

[0038]いくつかの実施形態においては、反復するＤＮＳ解決のすべてのステップにおいて伝送されるクエリは、完全修飾ドメインネームを含む。代替のプライバシー強化型の実施形態においては、それぞれの反復において送信されるＤＮＳクエリは、個別のＰＱＤＮ（たとえば、単一のトークン）と、場合によっては、数ある中でもワイルドカード「＊」などの追加の文字とを含むことが可能である。たとえば、選択されたネームサーバへ送信されるＰＱＤＮは、それぞれのネームサーバの権威ゾーンよりも１トークンだけ多いところまで取り除かれたそれぞれのＦＱＤＮを含むことが可能である。図６における例においては、ルートネームサーバ２０ｂへ送信されるＤＮＳクエリは、ＰＱＤＮ「．ｏｒｇ」について問い合わせることが可能であり、その一方で、ＴＬＤネームサーバ２０ｃへ送信されるＤＮＳクエリは、ＰＱＤＮ「＊．ｗｉｋｉｍｅｄｉａ．ｏｒｇ」について問い合わせることが可能である。

【0021】

[0039]いくつかの実施形態においては、そのような反復するドメイン解決は、専用のリゾルバネームサーバ２０ａ（図２）によって実行され、そのリゾルバネームサーバ２０ａは、最近のおよび／または人気のあるＤＮＳルックアップの結果を含むＤＮＳキャッシュをさらに管理することが可能である。そのような構成においては、クライアントデバイス１２ａ～ｆは、単一のＤＮＳクエリをリゾルバネームサーバ２０ａへ伝送することが可能であり、それぞれのクエリは、完全修飾ドメインネームの解決を要求する。ネームサーバ２０ａは次いで、クライアントのためにキャッシュルックアップを実行すること、および／または必要とされる反復するＤＮＳクエリを実行することが可能である。それぞれのＦＱＤＮが完全に解決された場合には、ネームサーバ２０ａは、それぞれのＦＱＤＮに関連付けられたＩＰアドレスを要求側クライアントへ返すことが可能である。

【0022】

[0040]図７は、本発明のいくつかの実施形態による例示的なプライバシー保護ＤＮＳトランザクションを示している。このトランザクションは、第１の当事者（たとえば、クライアント）が、アイテムを求める要求を第２の当事者（たとえば、サーバ）に発行することを含み、第２の当事者は、要求されたアイテムをデータリポジトリ／データベースから検索し、その検索手順は、そのアイテムを第２の当事者に明らかにすることなく実行される。別の言い方をすれば、サーバは、どのアイテムが要求されたかを認識しないが、それでもなお、要求されたアイテムをリポジトリから検索する。以降で詳述される１つの例示的なプライバシー保護トランザクションにおいては、クライアントによって発行された要求は暗号化され、サーバは、その要求を復号することなく、要求されたアイテムの暗号化されたバージョンを検索する。そのため、クライアントのプライバシーは保護される。

【0023】

[0041]いくつかの実施形態においては、プライバシー保護ＤＮＳトランザクションは、個人情報検索手順（ＰＩＲ）に従って実行される。図７において示されている例示的なやり取りは、クライアントデバイス１２（これは、図１におけるクライアントデバイス１２ａ～ｆのうちのいずれかを総称的に表す）がプライベートクエリ（ＰＩＲクエリ５２として示されている）をＤＮＳサーバシステム２０へ伝送して、それに応答してサーバシステム２０からプライベート応答（ＰＩＲ応答５４として示されている）を受信することを含む。

【0024】

[0042]いくつかの実施形態においては、ＰＩＲ手順は、準同型暗号化を使用して、やり取りのプライバシーを確保する。準同型暗号化は、暗号化されたデータについて特定の計算（たとえば、加算および／または乗算）を実行することを可能にする特定の種類の暗号化であり、そのような計算の結果を復号することは、同じデータの暗号化されていないバージョンにそれぞれの計算を適用した場合と同じ出力を生成する。別の言い方をすれば、Ｅｎｃ（ｍ）＝ｃが準同型暗号化演算を示し、ｍが平文メッセージを表し、ｃがその対応する暗号文を示す場合には、Ｄｅｃ（ｃ）＝ｍは、それぞれのメッセージをその暗号文から復元する準同型復号演算を示し、Ｅｖａｌ（Ｆ，｛ｃ_ｉ，．．．，Ｃ_ｋ｝）＝Ｃは、暗号文ｃ_ｉのセットに関数Ｆを適用することによって、暗号化された暗号文Ｃを生成する準同型評価手順を示し、そして
Ｄｅｃ（Ｃ）＝Ｆ（ｍ_１，．．．，ｍ_ｋ）， ［１］
であり、ｍ_ｉ＝Ｄｅｃ（ｃ_ｉ）であり、ｉ＝ｌ，．．．，ｋである。正式な数学的言語では、準同型暗号化スキームの暗号化および復号手順は、平文空間と暗号文空間との間における準同型写像であると言われている。

【0025】

[0043]いくつかの準同型暗号化スキーム／暗号システムが、当技術分野において知られている。加算と乗算とのいかなる組合せに関しても準同型特性を維持するスキームが、完全準同型として一般に知られている。例は、数ある中でも、ＧＳＷ（Ｇｅｎｔｒｙ－Ｓａｈａｉ－Ｗａｔｅｒｓ）スキームを含む。その他のスキーム／アルゴリズムは、特定のタイプの演算に関してのみ、たとえば、Ｐａｉｌｌｉｅｒスキームのケースにおいては加算に関してのみ、およびＲＳＡ（Ｒｉｖｅｓｔ－Ｓｈａｍｉｒ－Ａｄｅｌｍａｎ）スキームのケースにおいては乗算に関してのみ、準同型である。そのようなスキームは、部分的準同型として当技術分野において知られている。対照的に、上述されている準同型特性を有さない暗号は、本明細書においては非準同型とみなされる。非準同型暗号の例は、高度暗号化標準（ＡＥＳ）、および、通信プロトコルのトランスポートレイヤセキュリティ（ＴＬＳ）ファミリーにおいて使用されるその他の暗号を含む。

【0026】

[0044]準同型暗号化を使用する例示的なＰＩＲ手順においては、関数Ｆは、データベースルックアップを実行することに相当する一式の演算の代わりをすることが可能である。シンプルな例においては、サーバは、３つの要素をデータベースに保持し、すなわち、Ｄ＝｛ａ，ｂ，ｃ｝である。クライアントは、第２の要素（すなわち、「ｂ」）を検索することを、その情報をサーバに漏洩することなく行うことを望んでいる。クライアントは、ルックアップインデックス、たとえば、データベースＤ内の所望の要素の位置を除くすべての場所にゼロを含むビットマップＩを使用して、所望の要素を示すことが可能である。目下の例においては、Ｉ＝｛０，１，０｝である。そしてクライアントは、それぞれのビットマップを準同型に暗号化すること、およびそれをサーバへ伝送することが可能である。次いでサーバは、暗号化されたビットマップに関数Ｆを適用することが可能である。

【0027】

Ｃ＝Ｆ［Ｅｎｃ（Ｉ）］＝Ｄ＊［Ｅｎｃ（Ｉ）］^Ｔ， ［２］
＊は行列乗算を示し、Ｔは転置を示す。そしてサーバは、結果として生じる暗号化されたベクトルＣをクライアントへ返送する。準同型特性は、Ｃを復号することが、暗号化されていないビットマップＩに関数Ｆを適用した場合と同じ結果を生み出すことを確実にする。

【0028】

Ｄｅｃ（Ｃ）＝Ｆ（Ｉ）＝Ｄ＊Ｉ^Ｔ＝｛ａ，ｂ，ｃ｝＊｛０，１，０｝^Ｔ＝ｂ ［３］
それゆえにクライアントは、ｂを検索し、その一方でサーバは、暗号化されたビットマップのみを見て、クライアントから受信された情報を復号することなくすべてのオペレーションを実行する。

【0029】

[0045]いくつかの実施形態においては、ＤＮＳサーバシステム２０は、ドメインネームに従ってインデックス付けされたレコードのセットを格納するドメインネームデータベース５０に通信可能に接続される。それぞれのレコードに付加されたインデックスは、それぞれのデータリポジトリ内のそれぞれのレコードのロケーションを示すこと、またはさもなければ、データベース５０内での／データベース５０からのそれぞれのレコードの選択的な識別／検索を可能にすることができる。データが表形式で編成されるシンプルな例においては、それぞれの行は、個別のレコードを表すことが可能であり、行は、個別の行番号および／またはラベルによってインデックス付けされる。それぞれのレコードは、それぞれのドメインのさまざまな特徴を示すエントリのセットを含むことが可能である。ＤＮＳルックアップサービスを実施する一実施形態においては、例示的なエントリは、それぞれのドメインの一部を形成するコンピュータのＩＰアドレス、および／またはネームサーバ（たとえば、図２および図６におけるネームサーバ２０ａ～ｄを参照されたい）のＩＰアドレスを含む。その他の例示的なエントリは、それぞれのドメインに関するドメイン登録データ（たとえば、所有者の身元データ、課金データ、所有者の連絡先データ、たとえば、住所、電話番号、Ｅメールアドレス、ドメインネームの有効期限、現在のドメインレジストラの識別子など）を含む。さらに他の例示的なエントリは、それぞれのドメインが特定のカテゴリーに属するか否かの指標、またはそれぞれのドメインが属するカテゴリーの指標を含むことが可能である。たとえば、エントリは、それぞれのドメインがブラックリスト／ホワイトリストに載っているかどうか、それぞれのドメインが不正なドキュメントおよび／または迷惑通信（スパム）を配信することが知られているかどうか、それぞれのドメインがボットネットの一部であるかどうか、またはサービス妨害（ＤｏＳ）攻撃に携わっているかどうかを示すことが可能である。別の例示的なエントリは、それぞれのドメインが、選択された地理的エリアまたはサブネットワーク（たとえば、ジオフェンシング）内に配置されているかどうかを示すことが可能である。さらに別の例示的なエントリは、それぞれのドメインが所有されているか、または選択された営利エンティティーに関連しているかを示すことが可能である。その他の例は、以降で論じられることになる。

【0030】

[0046]いくつかの実施形態においては、それぞれのレコードを識別するインデックスは、ドメインネームに従って決定され、それゆえに、それぞれのレコードのさまざまなエントリとドメインネームとの間における関連付けを可能にする。それぞれのドメインネームは、ＦＱＤＮまたはＰＱＤＮであることが可能である。１つの例示的なインデックスは、それぞれのドメインネームに従って算出されたハッシュを含む。本明細書におけるハッシュは、ハッシュ関数を適用した結果を示す。ハッシュ関数は、任意のサイズのデータを、所定の普遍的な上限を有する数値にマッピングする特別な種類の数学関数である。文字列は、数値として表現されることが可能であるので、ハッシュ関数は、任意の文字列を数値に、たとえば２５６ビット整数にマッピングすることも可能である。例示的なハッシュ関数は、数ある中でも、Ｈ（ｎ）＝ｎ ｍｏｄ ｍ（ｎおよびｍは、整数である）、チェックサムハッシュ（たとえば、巡回冗長検査（ＣＲＣ））、ならびに、メッセージダイジェストハッシュファミリー（たとえば、ＭＤ５）およびセキュアハッシュファミリー（たとえば、ＳＨＡ－３）などの暗号ハッシュ関数を含む。ハッシュ関数を適用した結果に従って算出されるインデックスが、本明細書においてはハッシュインデックスとみなされる。

【0031】

[0047]いくつかの実施形態においては、ドメインネームデータベース５０のレコードを識別するインデックスは、複数のハッシュ関数Ｈ_１、．．．、Ｈ_ｋを採用するカッコウハッシュスキームを使用して算出される。そのようなハッシングの例が、図８において示されており、データベース５０は、複数のハッシュテーブル５１ａ～ｃを含む。それぞれのハッシュテーブルのそれぞれの行は、それぞれのドメインネームに従ってインデックス付けされた個別のレコードを表し、ｄ_ｊ（ｊ＝１、２、．．．）として示される。それぞれのレコードは、ｅ（ｄ_ｊ）として示される少なくとも１つのエントリを含み、これは、たとえばそれぞれのドメインのＩＰアドレスを含むことが可能である。それぞれのハッシュテーブル５１ａ～ｃにおいて、それぞれのレコードを識別するインデックスは、それぞれのドメインネームにハッシュ関数を適用することによって決定される。しかしながら、それぞれのテーブル５１ａ～ｃは、個別のハッシュ関数を使用して、それぞれのインデックスを決定する。例示的なカッコウハッシュスキームにおいては、第１のハッシュ関数を使用してそれぞれのレコードに関するインデックスを算出することによって、レコードが連続的に挿入される。それぞれのインデックスによって示される行が空である場合には、現在のレコードが、その行へと挿入される。それぞれの行が既に占有されている場合には、第２のハッシュ関数に従って別のハッシュインデックスが算出される、といった具合である。すべてのハッシュ関数に従って計算されたインデックスが、既に占有されている行を指している場合には、存在しているレコードのうちの１つが、現在のレコードによって置き換えられる。そしてそれぞれの行の前の占有物は、代替のロケーションに（すなわち、異なるハッシュ関数を使用して算出されたインデックスに）置かれ、場合によっては別のレコードに取って代わる。このプロセスは、すべてのレコードがいずれかのハッシュテーブル内に場所を見つけ出すまで再帰的に継続する。しかしながら、たとえば無限ループに入ることによって、この挿入プロセスが失敗する可能性がある。このケースにおいては、ハッシュテーブルは、ハッシュ関数の新たな選択を使用して再構築される。

【0032】

[0048]図９は、本発明のいくつかの実施形態によるＰＩＲクエリ５２およびＰＩＲ応答５４の例示的な内容を示している。ＰＩＲクエリ５２は、ドメインネームデータベース５０の選択されたレコードを識別するインデックスの暗号化を含む暗号文を含むことが可能である。図９における例においては、インデックスは、ドメインネームのハッシュを含む。カッコウハッシングを使用する実施形態においては、それぞれのドメインネームに関して、クライアントデバイス１２は、個別のハッシュ関数Ｈ_ｊに従ってそれぞれが算出される複数の暗号化されたハッシュインデックスを送り出すことが可能である。そのような暗号化されたハッシュインデックスは、個々のＰＩＲクエリへとパッケージ化されること、または単一のＰＩＲクエリへとまとめられることが可能である。

【0033】

[0049]いくつかの実施形態においては、ＰＩＲクエリ５２はさらに、それぞれのハッシュインデックスを算出するために使用されるハッシュ関数の指標（本明細書においては、ｈとして示されている）を含む。たとえば、ｈは、ソフトウェアバージョン番号、または、それぞれのクライアントによって使用されるハッシュ関数が、ドメインネームデータベース５０のハッシュテーブルを構築するために使用されるハッシュ関数と一致するかどうかをＤＮＳサーバシステム２０が決定することを可能にする何らかのその他のパラメータ値を含むことが可能である。ハッシングの一貫性をチェックすることについてのさらなる詳細は、図１３に関連して、以降で提供される。

【0034】

[0050]データベース５０が、それぞれのインデックスによって識別されるレコードを含む場合には、ＰＩＲ応答５４は、それぞれのデータベースレコードの少なくとも１つのエントリｅの暗号化を含む暗号文を返すことが可能である。そのようなレコードがデータベース５０に存在しない場合には、いくつかの実施形態は、所定のダミーエントリ（たとえば、データベース５０が現在、要求されたインデックスを伴うレコードを有していないということを示す所定のシンボル）の暗号化を伴って応答することが可能である。

【0035】

[0051]図１０は、本発明のいくつかの実施形態によるクライアントデバイス１２上で実行する例示的なコンポーネントを示している。そのようなソフトウェアは、オペレーティングシステム（ＯＳ）６２を含むことが可能であり、オペレーティングシステム（ＯＳ）６２は、数ある中でも、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、ＭａｃＯＳ（登録商標）、Ｌｉｎｕｘ（登録商標）、ｉＯＳ（登録商標）、またはＡｎｄｒｏｉｄ（登録商標）などの任意の広く利用可能なオペレーティングシステムであることが可能である。ＯＳ６２は、クライアントデバイス１２のハードウェアと、数ある中でも、クライアントアプリケーション６４およびドメインネームリゾルバ６６を含む一式のアプリケーションとの間におけるインターフェースを提供する。クライアントアプリケーション６４は、数ある中でも、ワードプロセッシング、スプレッドシート、画像処理、ゲーミング、電子通信、ウェブ閲覧、およびソーシャルメディアアプリケーションなどの任意のコンピュータプログラムを総称的に表す。いくつかの実施形態においては、アプリケーション６４は、たとえば、特定のインターネットドメインへの／特定のインターネットドメインからのトラフィックをフィルタリング／ブロックすること、入ってくるおよび／または出ていく電子通信が悪意あるコードもしくは迷惑コンテンツ（スパム）を含むかどうかを決定することなどによって、それぞれのクライアントシステムにコンピュータセキュリティサービスを提供する。

【0036】

[0052]アプリケーション６４は、たとえば一式のＨＴＴＰ要求を介して、コンテンツサーバ１６に接続してデータをやり取りすることが可能である。そのようなやり取りの一部として、アプリケーション６４は、ドメインネームｄの指標をドメインネームリゾルバ６６へ伝送することと、それに応答して、それぞれのドメインを特徴付けるドメインネームデータベースエントリｅ（ｄ）をリゾルバ６６から受信することとが可能である。シンプルなＤＮＳルックアップの例においては、ｅ（ｄ）は、ドメインｄのＩＰアドレスを含むことが可能である。別の例においては、ｅ（ｄ）は、ドメインｄに関する一式の登録データ（たとえば、それぞれのドメインの所有者の身元）を含むことが可能である。さらに別の例においては、ｅ（ｄ）は、ドメインｄにアクセスすることがそれぞれのクライアントをコンピュータセキュリティの脅威にさらすかどうか、たとえばドメインｄが不正ドキュメントを配信することが知られているかどうかの指標を含むことが可能である。一般には、ｅ（ｄ）は、ドメインネームデータベース５０に格納されてドメインｄのもとでインデックス付けされた任意のデータを含むことが可能である。

【0037】

[0053]いくつかの実施形態においては、ドメインネームリゾルバ６６は、ＤＮＳサーバシステム２０とのプライバシー保護ＤＮＳトランザクションに携わるように構成されている（図８も参照されたい）。したがってリゾルバ６６は、アプリケーション６４から受信されたドメインネームに従ってＰＩＲクエリ５２を定式化して、送り出すことが可能である。リゾルバ６６はさらに、ＰＩＲ応答５４を受信し、平文データエントリｅ（ｄ）を抽出し、それをアプリケーション６４へ転送することが可能である。ドメインネームリゾルバ６６はさらに、暗号化および／または復号オペレーションを実行するように構成された暗号エンジン６８を含むことが可能である。いくつかの実施形態においては、エンジン６８は、一式の準同型暗号アルゴリズム／手順を実施する。暗号エンジン６８は、ソフトウェア、ハードウェア、またはそれらの組合せで実装されることが可能である。

【0038】

[0054]図１０において示されている実施形態に対する代替実施形態においては、ドメインネームリゾルバ６６は、クライアントデバイス１２とは別個のマシン上で、たとえば、クライアントデバイス１２を拡張ネットワーク１５（図１を参照されたい）に接続するルータ１４もしくは別のゲートウェイデバイス上で、またはリゾルバネームサーバ２０ａ（図２）上で部分的にまたは全体的に実行することが可能である。

【0039】

[0055]図１１は、本発明のいくつかの実施形態によるドメインネームリゾルバ６６によって実行されるステップの例示的なシーケンスを示している。示されているリゾルバは、アプリケーション６４および／またはリモートサーバから受信される通信などのトリガーイベントを待つことが可能である。イベントが検知された場合には、イベントのタイプに従って一連のアクションが決定される。検知されたイベントがアプリケーション６４からのドメインルックアップ要求を含む場合（ステップ２０６が「はい」を返す場合）には、次いでステップ２０８において、いくつかの実施形態は、受信されたルックアップ要求に従ってネームサーバを選択することが可能である。いくつかの実施形態においては、別々のサーバによって別々のタイプのドメインネームサービスが供給されることが可能である。たとえば、いくつかのネームサーバは、ＩＰアドレスを返すことの専用とされることが可能であり、その一方でその他のネームサーバは、コンピュータセキュリティに関連したデータベースエントリを返すことが可能である。さらに、ドメインネームサービスが、選択されたドメインのＩＰアドレスを決定することを含む場合には、いくつかの実施形態は、選択されたネームサーバにクエリを行う場合にのみＰＩＲを採用することが可能である（以降の詳細を参照されたい）。

【0040】

[0056]次にステップ２１０において、リゾルバ６６は、それぞれのドメインネームに従って少なくとも１つのＰＩＲクエリ５２を定式化することが可能である。ステップ２１０は、数ある中でも、選択されたハッシュ関数をそれぞれのドメインネームに適用することと、暗号エンジン６８を採用して、たとえば準同型暗号化手順／アルゴリズムを使用して、ハッシングの結果を暗号化することとを含むことが可能である。エンジン６８は、当技術分野において知られている任意の準同型暗号化手順、たとえばＧＳＷ（Ｇｅｎｔｒｙ－Ｓａｈａｉ－Ｗａｔｅｒｓ）などの完全準同型暗号化スキームの暗号化アルゴリズムを使用することが可能である。いくつかのそのような手順は、たとえばＨｏｆｈｅｉｎｚ Ｄ．、Ｒｏｓｅｎ Ａ．（編）Ｔｈｅｏｒｙ ｏｆ Ｃｒｙｐｔｏｇｒａｐｈｙ（暗号化の理論）、ＴＣＣ ２０１９、コンピュータサイエンスの講義ノート、ｖｏｌ １１８９２、Ｓｐｒｉｎｇｅｒ、ＣｈａｍにおけるＧｅｎｔｒｙ Ｃ．、Ｈａｌｅｖｉ Ｓ．「Ｃｏｍｐｒｅｓｓｉｂｌｅ ＦＨＥ ｗｉｔｈ Ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ ＰＩＲ（ＰＩＲへの適用を伴う圧縮可能なＦＨＥ）」において詳述されているように、クライアント側および／またはサーバ側での計算負荷を低減することを目的としたさらなるデータ操作を含む。暗号化されたＰＩＲクエリは次いで、選択されたネームサーバへ伝送される。

【0041】

[0057]トリガーイベントが、サーバからのＰＩＲ応答５４を受信することを含む場合には、ステップ２１６においてリゾルバ６６は、暗号エンジン６８を使用して、応答５４に含まれている暗号文を復号し、それゆえに、クエリされたドメインネームに関連付けられたデータベースエントリ（たとえば、ＩＰアドレス）を復元することが可能である。ドメインネームデータベース５０が、それぞれのドメインネームに関連付けられたエントリを含まない場合には、それぞれの暗号文を復号することは、失敗を示すダミーメッセージを生成する可能性がある。さらなるステップ２１８が、復号手順の結果をアプリケーション６４へ伝送することが可能である。ステップ２１６は、準同型復号手順／アルゴリズム、たとえば、Ｈｏｆｈｅｉｎｚ Ｄ．、Ｒｏｓｅｎ Ａ．（編）Ｔｈｅｏｒｙ ｏｆ Ｃｒｙｐｔｏｇｒａｐｈｙ（暗号化の理論）、ＴＣＣ ２０１９、コンピュータサイエンスの講義ノート、ｖｏｌ １１８９２、Ｓｐｒｉｎｇｅｒ、ＣｈａｍにおけるＧｅｎｔｒｙ Ｃ．、Ｈａｌｅｖｉ Ｓ．「Ｃｏｍｐｒｅｓｓｉｂｌｅ ＦＨＥ ｗｉｔｈ Ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ ＰＩＲ（ＰＩＲへの適用を伴う圧縮可能なＦＨＥ）」において記述されている完全準同型を使用する。

【0042】

[0058]図１２は、本発明のいくつかの実施形態によるＤＮＳサーバシステム２０の例示的なコンポーネントを示している。示されているコンポーネントは、単一の物理マシン上で、または別々の通信可能に結合されたマシン上で実行することが可能である。サーバシステム２０は、図２において示されている一式のネームサーバを総称的に表す。

【0043】

[0059]いくつかの実施形態においては、データベースメンテナンスモジュール２６が、新たなドメインネームに対応するレコードを挿入すること、選択されたレコードに変更をもたらすこと（たとえば、ドメイン登録データを変更すること、それぞれのドメインのクラスタ割り振りを変更すること、それぞれのドメインをブラックリストから外すことなど）、および／または期限切れのレコードを削除することによって、ドメインネームデータベース５０を最新に保つように構成されている。モジュール２６の例示的なオペレーションが、図１３において示されている。一連のステップ２２２～２２４において、モジュール２６は、データベース更新条件が満たされているかどうかをチェックすることが可能である。いくつかの実施形態は、スケジュールに従って（たとえば、１時間ごとに）またはオンデマンドでデータベースの更新を実行することが可能である。代替実施形態においては、更新エージェントが、入ってくるドメインデータ５５をキューに蓄積し、キューが満杯になったときに、更新条件が満たされていると決定することが可能である。更新条件が満たされている場合には、ステップ２２６が、たとえば一式の新たなレコードを挿入することによって、データベース５０の更新を試みることが可能である。ステップ２２６は、たとえばそれぞれの新たなドメインネームにハッシュ関数を適用することによって、ハッシュインデックスを計算することと、その新たに計算されたインデックスを伴ってレコードをテーブル行へと挿入することとを含むことが可能である。しかしながら、そのような挿入オペレーションは、たとえばハッシュコリジョンのケースにおいては、すなわち、２つの異なるドメインネームが同じインデックスにハッシュする場合には、失敗する可能性がある。カッコウハッシュスキームを使用する実施形態においては、コンフリクトは、第２のハッシュ関数などを使用して別のインデックスを計算することによって解決されることが可能である。そのような実施形態においてさえ、複数のハッシュコリジョンに起因して、特定のレコードを挿入することが可能ではない場合がある。そのような状況は、新たな一式のハッシュ関数を選択することと、その新たなハッシュ関数を使用してデータベース５０に再びインデックス付けすることとを必要とする場合がある（図１３におけるステップ２３０～２３２）。

【0044】

[0060]成功したデータベース更新に応答して、ハッシュ関数が変わった場合には、ステップ２３４が、一式の更新されたハッシュ関数仕様５６をクライアントへ配信することが可能である（たとえば、図７、図１０、および図１２を参照されたい）。それゆえにステップ２３４は、ハッシングの一貫性、すなわち、すべてのクライアントが、データベース５０にインデックス付けする際に使用されたハッシュ関数のバージョンを一貫して使用してＰＩＲ要求を定式化することを確実にすることが可能である。

【0045】

[0061]いくつかの実施形態においては、ＤＮＳサーバシステム２０のＰＩＲモジュール２８が、クエリ５２に従ってドメインネームデータベース５０への暗号化されたルックアップを実行するように構成されている。本明細書における「暗号化されたルックアップ」という用語は、暗号化された形態でＰＩＲクエリ５２に含まれているインデックスによって示されるレコードを、それぞれのインデックスを復号することなく、データベース５０から検索することを指す。暗号化されたルックアップ手順は、上記の方程式［２］によって例示されているように、暗号化されたデータに対して加算および乗算などの一式の演算を直接実行して、暗号化された結果を生み出すことを含むことが可能である。そのため、暗号化されたルックアップは、たとえばＤＮＳ－ｏｖｅｒ－ＨＴＴＰＳなどの従来のバージョンの暗号化されたＤＮＳにおいて行われることが可能であるような、最初にクエリを復号して平文インデックスを生成し、その平文インデックスをそれぞれのデータベースへとルックアップすることを包含しない。

【0046】

[0062]ＰＩＲモジュール２８の例示的なオペレーションが、図１４において示されている。一連のステップ２４２～２４４が、入ってくるＰＩＲクエリを求めてリッスンすることが可能である。クエリが受信された場合には、ステップ２４６が、ハッシングの一貫性に関してチェックを行うことが可能である。別の言い方をすれば、ステップ２４６は、それぞれのクエリが、ドメインネームデータベース５０にインデックス付けするために使用されたのと同じハッシュ関数仕様に従って定式化されたかどうかを決定することが可能である。そうでない場合には、ステップ２５４において、ＤＮＳサーバシステム２０は、エラーメッセージをそれぞれの要求側クライアントへ返すことが可能である。いくつかの実施形態はさらに、更新されたハッシュ関数仕様５６をそれぞれのクライアントへプッシュすることが可能である。

【0047】

[0063]ハッシングが一貫しているという決定に応答して、ステップ２４８が、ＰＩＲクエリ５２に従ってデータベース５０への暗号化されたルックアップを実行する。ステップ２４８は、たとえば、Ｈｏｆｈｅｉｎｚ Ｄ．、Ｒｏｓｅｎ Ａ．（編）Ｔｈｅｏｒｙ ｏｆ Ｃｒｙｐｔｏｇｒａｐｈｙ（暗号化の理論）、ＴＣＣ ２０１９、コンピュータサイエンスの講義ノート、ｖｏｌ １１８９２、Ｓｐｒｉｎｇｅｒ、ＣｈａｍにおけるＧｅｎｔｒｙ Ｃ．、Ｈａｌｅｖｉ Ｓ．「Ｃｏｍｐｒｅｓｓｉｂｌｅ ＦＨＥ ｗｉｔｈ Ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ ＰＩＲ（ＰＩＲへの適用を伴う圧縮可能なＦＨＥ）」において記述されているような、当技術分野において知られている任意の方法を採用することが可能である。一連のステップ２５０～２５２が次いで、ＰＩＲ応答５４を定式化して、応答５４をそれぞれのクライアントデバイスへ伝送することが可能である。

【0048】

[0064]さまざまなドメインネームサービスが、上述されているように、プライバシーを保護する様式で実施されることが可能である。いくつかの例示的な使用事例シナリオは、下記を含む。

【0049】

ドメインネームをアドレスに解決すること（ＩＰアドレスルックアップ）
[0065]本明細書において記述されているシステムおよび方法の１つの用途は、ＤＮＳルックアップを実行すること、すなわち、選択されたドメインネームに関連付けられたＩＰアドレスを返すことにある。そのような実施形態においては、ドメインネームデータベース５０は、ドメインネームによってインデックス付けされた一式のＩＰアドレスを格納することが可能である。ＰＩＲクエリ５２は、それぞれのドメインネームをハッシュすることによって決定されるインデックスの暗号化、および場合によってはその他のデータ（たとえば、質問Ｑのエンコーディング、たとえば図９を参照されたい）を含むことが可能である。それに応答して、ＤＮＳサーバシステム２０は、それぞれのＩＰアドレスの暗号化を含むＰＩＲ応答５４を返すことが可能である。クライアント（またはそれぞれのクライアントと通信状態にある別のマシン）は次いで、電子通信（たとえばウェブ閲覧）をルーティングするためにそれぞれのＩＰアドレスを復号して使用することが可能である。

【0050】

[0066]ドメインネーム解決（ドメインネームをＩＰアドレスにマッピングすること）を実行するように構成された一実施形態においてドメインネームリゾルバ６６によって実行されるステップの例示的なシーケンスが、図１５において示されている。ＤＮＳルックアップを最適化するために、いくつかの実施形態は、ＴＬＤおよび／または権威ネームサーバの以前に解決されたＩＰアドレスを格納するローカルキャッシュを保持することが可能である。選択されたドメインネームを解決したいという要求を受信したことに応答して、いくつかの実施形態は、ドメインネーム階層の連続したレベルを通じて反復することが可能である。それぞれのＦＱＤＮがＩＰアドレスにまだ完全には解決されていない場合には、ステップ２６８が、それぞれのドメインネームのＰＱＤＮを決定することが可能である。そのＰＱＤＮは、階層の選択されたレベルまで（たとえばＴＬＤレベル、たとえば「．ｏｒｇ」（図６を参照されたい）まで）指定されたＦＱＤＮの一部を含むことが可能である。ステップ２７０において、リゾルバ６６は、キャッシュルックアップを実行することによって、それぞれのＰＱＤＮが以前に解決されているかどうかをチェックすることが可能である。「はい」の場合には、キャッシュは、次のレベルのＦＱＤＮ３６を解決することが可能であるネームサーバに関するＩＰアドレスを保持することが可能である。「いいえ」の場合、ステップ２７２が、現在のＰＱＤＮを解決するためのネームサーバを選択することが可能である。ＰＱＤＮが「．ｏｒｇ」である一例においては、選択されるネームサーバは、ルートネームサーバ２０ｂであることが可能である、といった具合である。

【0051】

[0067]いくつかの実施形態は、ＰＩＲ手順がプロセッサ負荷および通信サイズの両方において計算コストが高いという観察に依存している。さらに、上で図６に関連して示されているように、典型的なＤＮＳルックアップは、たとえば、最初にルートネームサーバへの、そしてＴＬＤネームサーバへの、そして最終的には権威サーバへの複数の反復クエリを必要とする場合がある。別の言い方をすれば、単一のＤＮＳルックアップが、ＰＩＲ手順の多様性のコストを増加させる場合がある。問題をさらに複雑にしているのは、ＤＮＳルックアップが比較的頻繁に行われるという事実であり、たとえば、単一のウェブページにアクセスすることは、複数の連続したＤＮＳルックアップオペレーションを含む場合がある。

【0052】

[0068]いくつかの実施形態はさらに、いくつかのＦＱＤＮがその他のＦＱＤＮよりもプライバシーに敏感であるという観察に依存している。たとえば、ユーザは、自分の閲覧履歴の選択された部分（たとえば、数ある中でも、オンラインニュースまたはウィキペディアなどのリファレンスサイトにアクセスすること）を明らかにすることには、その他の部分（たとえば、アダルトコンテンツサイトにアクセスすること）とは対照的に、さほど懸念を抱かない可能性がある。さらに、ＦＱＤＮのいくつかの部分は、その他の部分よりもプライバシーに敏感である場合がある。たとえば、図６における例を使用すると、ユーザが．ｏｒｇトップレベルドメインにアクセスすることを望んでいるということを知ることは、ユーザがｗｉｋｉｍｅｄｉａ．ｏｒｇにアクセスすることを実際に試みているということを知ることに比べて、情報量またはプライバシー上の懸念がはるかに少ない。

【0053】

[0069]したがって、ＰＩＲによって生じる計算コストのうちのいくらかを軽減するために、いくつかの実施形態は、ＤＮＳクエリのサブセットに関してのみＰＩＲを意図的に使用する。ＰＩＲを使用するか否かを決定することは、プライバシー条件が満たされているかどうかを決定すること、すなわち、現在のクエリがプライバシーに敏感であるか否かを決定することを含むことが可能である。図１５における例示的なステップ２７４が、プライバシー条件を評価する。現在のクエリがプライバシーに敏感であるとみなされる場合には（ＹＥＳ分岐）、一連のステップ２７６～２７７が、準同型暗号化（ＰＩＲ）を使用して現在のクエリを定式化することが可能である。そうでない場合には、現在のクエリは、従来のＤＮＳを使用して実行されることが可能である。

【0054】

[0070]いくつかの実施形態は、プライバシー条件が満たされているかどうかを、選択されたネームサーバの権威ゾーンに従って決定する。たとえば、いくつかの実施形態は、ＰＩＲクエリをＴＬＤネームサーバ２０ｃおよび／または権威ネームサーバ２０ｄへのみ伝送し、その一方で、ルートネームサーバ２０ｂにアドレス指定されたクエリは、従来のＤＮＳを使用して定式化される。別の言い方をすれば、そのような実施形態は、従来の（非プライベート）ＤＮＳクエリを介してＦＱＤＮ３６のＴＬＤトークンを、そしてＰＩＲを使用してドメイントークンおよび／またはプレフィックストークンを解決する。

【0055】

[0071]リゾルバ６６のいくつかの実施形態は、プライバシー条件が満たされているかどうかをＦＱＤＮ３６のトークンのうちの少なくとも１つに従って決定する。たとえば、リゾルバ６６は、選択されたＰＱＤＮ、たとえば、「ｇｏｏｇｌｅ．ｃｏｍ」、「ｗｉｋｉｐｅｄｉａ．ｏｒｇ」、「ａｍａｚｏｎａｗｓ．ｃｏｍ」などを解決するために従来の（すなわち、非ＰＩＲ）ＤＮＳクエリを、そして「ｆａｃｅｂｏｏｋ．ｃｏｍ」、「ｐｏｒｎｈｕｂ．ｃｏｍ」等などのその他のＰＱＤＮを解決するためにＰＩＲクエリを使用することが可能である。そのような実施形態は、いくつかのオンラインアクティビティー（たとえば、グーグル検索を行うこと、ニュースサイトにアクセスすること、天気予報またはスポーツスコアを調べることなど）が、その他のオンラインアクティビティー（たとえば、アダルトコンテンツにアクセスすること、映画をストリーミングすること、選択された電子商取引、オンラインバンキング、またはソーシャルメディアポータルにアクセスすることなど）に比べて、プライバシー上の懸念が少ない場合があるという観察に依存している。別の例においては、ユーザがクラウドコンピューティングサービス（たとえば、Ａｍａｚｏｎ，Ｉｎｃ．からのＡｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（商標）、またはＭｉｃｒｏｓｏｆｔのＡｚｕｒｅ（商標））にアクセスしているということを知ることは、情報量またはプライバシー上の懸念があまり多くない場合がある。なぜなら、それぞれのドメインは、数千の異なるサブドメインをホストする場合があるからである。選択的なＰＩＲクエリを行うことを可能にするために、いくつかの実施形態は、プライバシーに敏感であるとみなされるＰＱＤＮのブラックリスト、および／または従来のＤＮＳを使用して検索されることが可能であるＰＱＤＮのホワイトリストを保持する。例示的なホワイトリストは、数ある中でも、検索エンジンドメイン、ニュースドメイン、オンライン広告および／またはその他のコンテンツ配信ドメイン、ならびに、さまざまなクラウドコンピューティングサービス（ファイルホスティング、サービスとしてのインフラストラクチャーなど）を提供するドメインを含むことが可能である。ステップ２７４は次いで、ホワイトリストにおける現在のＰＱＤＮ／ドメインネームトークンを調べることを含むことと、それぞれのＰＱＤＮ／トークンがホワイトリスト上にある場合には従来のクエリを、そしてそうでない場合にはＰＩＲクエリを送信することを決断することとが可能である。代替として、リゾルバ６６は、ブラックリストを調べることと、それぞれのＰＱＤＮ／トークンがブラックリスト上にある場合にはＰＩＲクエリを、そしてそうでない場合には従来のＤＮＳクエリを送信することを決断することとが可能である。

【0056】

[0072]選択的なＰＩＲクエリを行うことは、サブドメインレベルで実行されることも可能である。いくつかの実施形態は、ドメインレベルのＰＱＤＮを漏洩することが特定のプライバシー上の懸念を構成しない場合があるケース（たとえば、ｇｏｏｇｌｅ．ｃｏｍ）においては、いくつかのサブドメイントークンを漏洩することが問題となる場合があるという観察に依存している。たとえば、「ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ」は、「ｍｅｅｔ．ｇｏｏｇｌｅ．ｃｏｍ」に比べて、プライバシーに敏感ではない場合がある。そのため、いくつかの実施形態は、プレフィックストークンおよび／またはＦＱＤＮのホワイトリストおよび／またはブラックリストを保持し、ＰＩＲまたは従来のＤＮＳを使用してそれぞれの権威サーバにクエリを行うかどうかを決定する。シンプルな実施形態は、「ｗｗｗ」サブドメインを解決するためには従来のＤＮＳクエリを、そしてそれ以外の場合にはＰＩＲクエリを使用することが可能である。

【0057】

[0073]表１は、ＦＱＤＮと、それらのＦＱＤＮの関連付けられたプライバシー問題との例をさらにいくつか提供する。

【0058】

【表1】

【0059】

[0074]ＰＩＲを使用するための条件が満たされているとステップ２７４が決定した場合には、ステップ２７６において、リゾルバ６６は、サーバシステム２０との間で一式の準同型暗号化パラメータ（たとえば、キー、共有秘密、ノンスなど）をネゴシエートすることが可能である。いくつかの実施形態は、準同型暗号化スキームを使用して、プライベート／パブリックキーペア、またはおよび暗号化／復号キーペアを生成する。次いでステップ２７７が、たとえば、それぞれのＰＱＤＮをハッシュして、それぞれのハッシュと、場合によっては質問Ｑ（図９を参照されたい）の指標などのその他のデータとを、ネゴシエートされたペアのパブリックキーを使用して暗号化することによって、ＰＩＲクエリ５２を定式化することが可能である。

【0060】

[0075]ＰＩＲを使用するための条件が満たされていないとステップ２７４が決定したケースにおいては、いくつかの実施形態は、従来のＤＮＳクエリを定式化することが可能である（図３～図４を参照されたい）。ステップ２７８はさらに、たとえば、ＤＮＳ ｏｖｅｒ ＨＴＴＰｓプロトコルのもとでセッション暗号化キーのペアをネゴシエートすることと、キーペアのパブリックキーを使用してそれぞれのＤＮＳクエリを暗号化することとを含むことが可能である。いくつかの実施形態においては、従来のクエリおよびＰＩＲクエリの両方が暗号化され、ＤＮＳ ｏｖｅｒ ＨＴＴＰｓなどのプロトコルを介して送信される。そのような戦略は、それぞれの伝送のインテグリティーを確実にすることなど、前記プロトコルのその他の特徴から利益を得ることが可能である。しかしながらＰＩＲクエリは、従来のＤＮＳクエリに比較して、暗号化の追加のレイヤを含み、その追加のレイヤは、ＰＩＲを可能にする準同型暗号化に相当する。ＤＮＳ ｏｖｅｒ ＨＴＴＰｓまたは類似のプロトコルに対応する暗号化のレイヤは、サーバによって除去される。それにもかかわらず、そのような復号は、従来のＤＮＳクエリの平文バージョンを生成するが、サーバは、ＰＩＲクエリから準同型暗号化レイヤを除去せず、したがってＰＩＲクエリは、ＤＮＳサーバシステム２０によって読み取り不可能なままである。

【0061】

[0076]クエリを適切なネームサーバへ伝送すると、ステップ２８２において、リゾルバ６６は、それぞれのサーバからの応答を待つことが可能である。さらなる一連のステップ２８４～２８６が、現在のＰＱＤＮに関連付けられたＩＰアドレスをサーバの応答から抽出することが可能であり、それぞれのＩＰアドレスをさらなる使用のためにキャッシュすることが可能である。それぞれのＩＰアドレスは、現在のＦＱＤＮに関連付けられた完全に解決されたＩＰアドレスのネームサーバのアドレスを含むことが可能である。サーバの応答がＰＩＲ応答５４を含む場合には、ステップ２８４は、準同型復号手順を使用して、封入されたＩＰアドレスを復号することを含むことが可能である。

【0062】

[0077]いくつかの実施形態は、ＰＩＲの実質的な計算コストを軽減するためにさらなる最適化を実施する。そのような一例は、レコードの総数に従って、ならびに／または所望のルックアップパフォーマンスおよび／もしくは所望のプライバシーレベルに従って、ドメインネームデータベース５０をサブユニット／バケットへと分割することによってドメインネームデータベース５０のサイズを低減することを含む。そのような実施形態においては、ドメインネームの完全なデータベースを検索する代わりに、サーバは、それぞれのドメインのレコードを保持するバケット内のみを見ることになる。より小さなバケットは、ルックアップ時間におけるより大きな減少を可能にするが、それと同時に、より少ないプライバシーを提供する。なぜなら、それぞれのドメインのアイデンティティーの不確かさが低下するからである。スピードとプライバシーとの間における妥協を提供することが可能である例示的なバケットサイズは、２^１６＝６５５３６であり、すなわち、それぞれのバケットは、最大で６５５３６個の異なるドメインネームの間において解決を行うことを可能にすることができる。それぞれのバケットはさらに、図８に関連して上述されているように複数のハッシュテーブルを格納することが可能である。個々のバケットは、個別のコンピュータシステムによって操作されること、同じコンピュータの個別のプロセッサコアに割り当てられることなどが可能である。

【0063】

[0078]そしていくつかの実施形態は、ハッシュ関数（たとえば、ＦＮＶ－１などのＦｏｗｌｅｒ－Ｎｏｌｌ－Ｖｏハッシュの変形）を使用して、それぞれのレコードを保持するバケットを識別することが可能である。ハッシュ関数の出力は、モジュロ演算を適用することによってバケットの数まで切り捨てられることが可能である。サーバ側では、例示的なバケットインデックスが、下記のように算出されることが可能である。

【0064】

Ｉ^Ｂ（ｄ，Ｑ）＝Ｈ^Ｂ（［Ｑ，ｄ］）ｍｏｄＮ^Ｂ， ［４］
ｄおよびＱは、それぞれドメインネームおよび質問（たとえば、Ａ対ＡＡＡＡ）を示し、Ｈ^Ｂは、バケット化するために使用されるハッシュ関数を示し、Ｎ^Ｂは、バケット数を示し、［Ｑｄ］は、Ｑおよびｄの連結を示す。バケットインデックスを計算する示されている様式は、一例としてのみ意図されており、本発明の範囲を限定するものではないということを当業者なら理解するであろう。

【0065】

[0079]データベース５０におけるそれぞれのドメインネームに関して、データベースメンテナンスモジュール２６は、Ｉ^Ｂを算出し、インデックスＩ^Ｂを伴ってバケットにそれぞれのレコードを置くことが可能である。レコードを置くことは、上述されているように、カッコウハッシングスキームを適用して、複数のハッシュテーブルのうちの１つの中にそれぞれのレコードに関するロケーションを見つけ出すことなどを含むことが可能である。次いでクライアント側では、リゾルバ６６は、Ｉ^Ｂを算出し、それをＰＩＲクエリ５２に添付することが可能である。バケットインデックスは、平文として送信されること、または暗号化されることが可能である。ＰＩＲクエリ５２を受信した場合には、サーバ２０は、クエリ５２に従ってバケットを決定し、次いでそれぞれのバケットの内容に従ってＰＩＲを実行して、ＰＩＲ応答５４を生成することが可能である。

【0066】

コンピュータセキュリティおよび分析アプリケーション
[0080]いくつかの実施形態は、コンピュータセキュリティおよびデータ分析アプリケーションに適合されることが可能である。そのような使用事例シナリオにおいては、ドメインネームデータベース５０は、それぞれのドメインのメンバーシップを示すレコードをドメインの特定のクラスまたはカテゴリーに格納する。いくつかの実施形態においては、カテゴリーは、コンピュータセキュリティに関連している場合がある。たとえば、あるカテゴリーは、アダルトコンテンツを配信することによって特徴付けられるドメインを含む場合がある。別の例示的なカテゴリーは、詐欺的なアクティビティーに携わっていることが知られているドメインのブラックリストを含む。別の例示的なカテゴリーは、サービス妨害攻撃に関与することによって特徴付けられるドメイン（たとえば、特定のボットネットのメンバー）を含む。

【0067】

[0081]その他のカテゴリーは、データ分析のさまざまな側面に関連している場合がある。たとえば、ドメインは、コンテンツ（たとえば、ゲーミング、ニュース、リファレンス、教育など）に従ってクラス／カテゴリーへとグループ化されることが可能である。その他のグループ化／分類基準は、所有権および／または商業上の関係を含むことが可能である。たとえば、同じ企業によって、または同じコングロマリットもしくは企業連合のメンバーによって所有されているすべてのドメインは、個別のドメインカテゴリーへと、ともにグループ化されることが可能である。別の分類基準は、特定のオンラインアクティビティーにおけるメンバーシップを含む。たとえば、特定のオンラインゲームに、および／または特定のゲームメーカーによって制作されたゲームに関連付けられたすべてのドメインネームは、個別のカテゴリーにおいてともにグループ化されることが可能である。さらに別の分類基準は、ジオロケーションを含むことが可能であり、特定の地理的領域、国などからのドメインどうしは、ともにグループ化されることが可能である。その他の例示的な基準は、ドメイン年齢／最初の登録の時刻を含むことが可能である。

【0068】

[0082]分類のさらに別の例においては、共有されている特徴またはその他のタイプのドメイン間の類似性に従ってドメインどうしがクラスタへとグループ化されることが可能である。図１６は、本発明のいくつかの実施形態によるドメイン３０ａ～ｂのセットおよびクラスタ６０ａ～ｂのセットを示している。クラスタメンバーシップは排他的である必要はなく、図１６の例においては、ドメイン３０ｂはクラスタ６０ａ～ｂの両方に属する。いくつかの実施形態においては、２つのドメインの類似性は、Ｎ次元の抽象特徴空間においてそれらの２つのドメインを分離するハイパーディスタンスに従って評価されることが可能である。しかしながら類似性は、ドメインの特徴自体に基づく必要はない。そのような一例においては、２つのドメインが一連のＤＮＳクエリにおいて頻繁に一緒に出現する場合に、それらのドメインは類似しているとみなされることが可能であり、そのような２つのドメインは、同じクラスタに置かれることが可能である。別の例においては、クラスタは、教師なし学習アルゴリズムを使用するニューラルネットワーク分類器によって自動的に生成されることが可能である。個々のクラスタは、個別のドメインカテゴリーに相当する場合があり、または相当しない場合もある。たとえば、「悪意ある」ドメインカテゴリーは、複数のクラスタを含む場合があり、それぞれのクラスタは、個別のボットネットからのドメインを含む場合がある。

【0069】

[0083]ドメインのクラスタリングおよび／または分類自体（すなわち、ドメインどうしをカテゴリーまたはクラスタへとグループ化すること）は、この記述の範囲を超えており、データマイニングの技術分野において知られている任意の方法を使用して達成されることが可能である。この記述は、ＰＩＲを介して既存の分類にアクセスすることに焦点を合わせる。いくつかの実施形態においては、ドメインネームデータベース５０に格納されるレコードは、ドメインが特定のカテゴリーに属するか否かを示すブール値を含むことが可能である。代替として、レコードは、それぞれのドメインが属するカテゴリー／クラスタのラベルまたはその他の識別子を含むことが可能である。そのようなレコードは、上で概説されているＰＩＲクエリおよび応答メカニズムを使用してアクセスされることが可能である。いくつかの実施形態においては、ＰＩＲクエリ５２は、データベース５０へのインデックス（たとえば、ドメインネームのハッシュ）の暗号化を含み、その一方でＰＩＲ応答５４は、それぞれのドメインのカテゴリー／クラスタメンバーシップを示すデータベースエントリをエンコードする暗号文を含むことが可能である。

【0070】

[0084]いくつかの実施形態は、ＤＮＳルックアップに関連して上述されているバケット化戦略を採用して、セキュリティおよび／または分析アプリケーションにおけるサーバの応答をスピードアップすることも可能である。個々のバケットは、マルウェア、詐欺、ボットネット、スパム等など、個々のセキュリティカテゴリーに対応することが可能である。１つのそのようなカテゴリー内のレコードの数が所定のしきい値を超えた場合には、いくつかの実施形態は、それぞれのカテゴリーに対応するデータベースをサブバケットへと分割することと、ハッシングを使用して、それぞれの個々のレコードを含むバケットを識別することとが可能である。クエリを発行する際に、クライアントは、バケット／カテゴリーインデックスを平文または暗号文で送信することが可能である。

【0071】

[0085]図１７は、本明細書において記述されている方法のうちのいくつかを実行するようにプログラムされたコンピューティングアプライアンス８０の例示的なハードウェア構成を示している。アプライアンス８０は、クライアントデバイス１２ａ～ｆ、ルータ１４、およびサーバ２０のうちのいずれかに相当することが可能である。示されているアプライアンスは、パーソナルコンピュータであり、サーバ、モバイル電話、タブレットコンピュータ、およびウェアラブルコンピューティングデバイスなどのその他のコンピューティングデバイスは、わずかに異なる構成を有する場合がある。プロセッサ８２は、一式の信号および／またはデータを用いて計算および／または論理オペレーションを実行するように構成された物理デバイス（たとえば、マイクロプロセッサ、半導体基板上に形成されたマルチコア集積回路）を含む。そのような信号またはデータは、エンコードされて、プロセッサ命令、たとえばマシンコードの形態でプロセッサ８２へ配信されることが可能である。プロセッサ８２は、中央処理装置（ＣＰＵ）および／またはグラフィックスプロセッシングユニット（ＧＰＵ）のアレイを含むことが可能である。

【0072】

[0086]メモリユニット８４は、オペレーションを実行する過程でプロセッサ８２によってアクセスまたは生成されるデータおよび／または命令を格納する揮発性のコンピュータ可読メディア（たとえばダイナミックランダムアクセスメモリ（ＤＲＡＭ））を含むことが可能である。入力デバイス８６は、数ある中でも、ユーザがデータおよび／または命令をアプライアンス８０へと導入することを可能にするそれぞれのハードウェアインターフェースおよび／またはアダプタを含む、コンピュータキーボード、マウス、およびマイクロフォンを含むことが可能である。出力デバイス８８は、数ある中でも、モニタなどのディスプレイデバイスおよびスピーカー、ならびに、それぞれのコンピューティングデバイスがデータをユーザに通信することを可能にするグラフィックカードなどのハードウェアインターフェース／アダプタを含むことが可能である。いくつかの実施形態においては、入力および出力デバイス８６～８８は、共通のハードウェア（たとえば、タッチスクリーン）を共有する。ストレージデバイス９２は、ソフトウェア命令および／またはデータの不揮発性の格納、読み取り、および書き込みを可能にするコンピュータ可読メディアを含む。例示的なストレージデバイスは、磁気および光ディスク、ならびにフラッシュメモリデバイス、ならびに、ＣＤおよび／またはＤＶＤディスクおよびドライブなどのリムーバブルメディアを含む。ネットワークアダプタ９４は、電子通信ネットワーク（たとえば、図１におけるネットワーク１３および１５）に、ならびに／またはその他のデバイス／コンピュータシステムに結合された物理リンクを介してデータを通信するための機械回路、電気回路、およびシグナリング回路を含む。アダプタ９４は、さまざまな通信プロトコルを使用してデータを伝送および／または受信するように構成されることが可能である。

【0073】

[0087]コントローラハブ９０は、複数のシステムバス、ペリフェラルバス、および／もしくはチップセットバス、ならびに／または、プロセッサ８２とアプライアンス８０のハードウェアコンポーネントのうちの残りとの間における通信を可能にするすべてのその他の回路を総称的に表す。たとえば、コントローラハブ９０は、メモリコントローラ、入力／出力（Ｉ／Ｏ）コントローラ、および割り込みコントローラを含むことが可能である。ハードウェア製造業者によっては、いくつかのそのようなコントローラは、単一の集積回路へと組み込まれる場合があり、および／またはプロセッサ８２と統合される場合がある。別の例においては、コントローラハブ９０は、プロセッサ８２をメモリ８４に接続するノースブリッジ、ならびに／またはプロセッサ８２をデバイス８６、８８、９２、および９４に接続するサウスブリッジを含むことが可能である。

【0074】

[0088]上述されている本発明の態様は、さまざまな形態のソフトウェア、ファームウェア、およびハードウェア、またはそれらの組合せで実装されることが可能であるということも、当業者にとっては明らかであろう。たとえば、本発明の特定の部分は、１つまたは複数の機能を実行する専用のハードウェアロジックとして記述される場合がある。この専用のロジックは、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含むことが可能である。本発明の原理と整合する態様を実施するために使用される実際のソフトウェアコードまたは専用の制御ハードウェアは、本発明を限定するものではない。それゆえに、本発明の態様のオペレーションおよび動作は、特定のソフトウェアコードへの参照を伴わずに記述されたが、当業者なら、本明細書における記述に基づいて、それらの態様を実施するためのソフトウェアおよび制御ハードウェアを設計することが可能であろうということが理解される。

【0075】

[0089]上述されている例示的なシステムおよび方法は、さまざまなドメインネームサービスを、それぞれのサービスの受益者のプライバシーを保護しながら実行することを可能にする。たとえば、いくつかの実施形態は、ドメインネームとＩＰアドレスとの間における変換を可能にし、実際の変換／データベースルックアップを実行するネームサーバは、それぞれのドメインネームおよびＩＰアドレスを認識しない。いくつかの実施形態は、準同型暗号化を使用して、サーバ側での個人情報検索（ＰＩＲ）手順を可能にする。サーバは、暗号文をクライアントに返し、クライアントは次いで、それぞれの暗号文を復号して、所望のデータベースエントリ（たとえばＩＰアドレス）を生成する。

【0076】

[0090]従来のＤＮＳにおいては、クライアントクエリおよび／またはサーバ応答は暗号化されず、したがっていかなる第三者も、それぞれのＤＮＳデータを覗き見することが可能である。ＤＮＳテクノロジーにおけるさらに新たな開発は、クエリおよび／またはクライアント応答を暗号化し、それによって原則としてデータは、転送中の間は秘密に保たれる。しかしながら、ＤＮＳのそのような変種においては、ネームサーバは、依然としてＤＮＳクエリを復号して、平文のドメインネームを生成する。そのような従来のＤＮＳとは対照的に、いくつかの実施形態においては、ＰＩＲ手順は、暗号化された入力を使用するので、ネームサーバは、もはや平文でのトランザクションデータにアクセスできない。そのため、いくつかの実施形態は、従来のＤＮＳソリューションに比較して、より強力なレベルのプライバシーを確実にする。

【0077】

[0091]ＰＩＲ手順は、計算と、それぞれのクライアント／サーバトランザクションにおいてやり取りされるデータの量との点で比較的コストがかかる。コストを軽減するために、いくつかの実施形態は、ＰＩＲを使用するドメインネーム解決のすべての段階を実行するとは限らない。代わりに、クライアントは、従来のＤＮＳ、またはＤＮＳ ｏｖｅｒ ＨＴＴＰＳなどの非準同型暗号化された変種を使用してトップレベルドメイン（ＴＬＤ）ネームサーバにクエリを行うことと、ドメインネーム階層のドメインおよび／またはサブドメインレベルでそれぞれのドメインネームを解決する選択されたネームサーバにクエリを行う場合にのみＰＩＲ手順を使用することとが可能である。そのような戦略は、後者のネームサーバによって提供される情報が、たとえばドメインネームのＴＬＤ部分よりもプライバシーにとって比較的重要であるという観察に依存している。いくつかの実施形態はさらに、それぞれのＦＱＤＮの少なくとも１つのトークンに従って選択的にＰＩＲを適用する。別の言い方をすれば、特定のトークン（たとえば、「ｇｏｏｇｌｅ．ｃｏｍ」、「ｗｗｗ」等）を解決することは、従来のＤＮＳを介して行われることが可能であり、その一方でその他のさらにプライバシーに関わるトークンを解決することは、ＰＩＲを介して実行されることが可能である。

【0078】

[0092]ＤＮＳデータベースは、数百万の個別のレコードを保持することが可能である。そのようなデータベースのサイズだけでも、ＰＩＲクエリを実行不可能にする場合がある。そのような制限に対処するために、いくつかの実施形態はさらに、バケット化アプローチを採用して、データベースのサイズを、したがってＰＩＲ計算の複雑さ、ならびにクエリおよびサーバ応答のサイズを低減する。データベースサイズを６５５３６個のレコードへ低減することが、ＤＮＳルックアップを実行するために必要とされる平均時間を１ｓ以下に保つことを可能にし、それは、現在のシステムおよび方法の応用を商業的におよび技術的に実行可能にするということをコンピュータ実験が明らかにしている。このアプローチの注意事項は、データベースのサイズを低減することによって、プライバシーも本質的に低減されるということである。しかしながら、データベースサイズのいくつかの選択は、プライバシーとスピードとの間における許容可能な妥協を提供する場合がある。さらに、ＰＩＲ手順は原則として並列化可能であるので、並列コンピューティング構成を使用して、たとえば、複数の相互接続されたプロセッサコアまたはグラフィカルプロセッシングユニット（ＧＰＵ）ファームを使用してサーバ側でのＰＩＲをセットアップすることによって、スピードにおけるさらなる利得が達成されることが可能である。

【0079】

[0093]本発明のいくつかの実施形態は、コンピュータセキュリティ、アプリケーションコントロール、ペアレントコントロール等など、ドメインネーム解決とは異なるさまざまなその他のシナリオに適合されることが可能である。１つの例示的な使用事例シナリオにおいては、クライアント上で、ルータ／ネットワークゲートウェイ上で、またはリモートセキュリティサーバ上で実行することが可能であるコンピュータセキュリティコンポーネントが、それぞれのクエリを復号することなくデータベースルックアップを実行するように構成されたサーバとのＰＩＲのやり取りに携わることが可能である。データベースレコードは、特定のドメインがコンピュータセキュリティに関連する特定のカテゴリーに関連付けられているかどうか、たとえば、それぞれのドメインがブラックリストに載っているかどうか、または詐欺的なアクティビティーに携わっているかどうかなどを示すことが可能である。ペアレンタルコントロールの使用事例シナリオにおいては、データベースレコードは、たとえば、特定のドメインがアダルト素材を配信しているかどうかを示すことが可能である。アプリケーションコントロールの使用事例シナリオにおいては、データベースレコードは、それぞれのドメインが特定の種類のオンラインアクティビティー（ゲーミング、ソーシャルメディアなど）に関連付けられているかどうかを示すことが可能である。そのため、いくつかの実施形態は、特定のドメインへの、もしくは特定のドメインからのトラフィックを選択的にフィルタリングすること、またはユーザが特定のドメインにアクセスするのをブロックすることを可能にする。そのようなフィルタリング／ブロッキングは、当技術分野において知られているが、従来のトラフィック制御手順とは対照的に、本発明のいくつかの実施形態においては、実際のデータベースルックアップを実行するサーバは、それぞれの情報が要求されているドメインネームを認識しない。これは、たとえば、ユーザのプライバシーを損なうことなく、サーバおよび関連付けられているドメインネームデータベースが、セキュリティ／ペアレンタルコントロール／アプリケーションコントロールサービスのプロバイダとは異なるエンティティーによって所有および／または運用されることを可能にする。

【0080】

[0094]上記の実施形態は、本発明の範囲から逸脱することなく多くの方法で変更されることが可能であるということが当業者にとっては明らかであろう。したがって本発明の範囲は、下記の特許請求の範囲およびそれらの法的均等物によって決定されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【国際調査報告】