特許 7438295 データを保護するためのシステムおよび方法

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

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

(11)【特許番号】

(24)【登録日】2024-02-15

(45)【発行日】2024-02-26

(54)【発明の名称】データを保護するためのシステムおよび方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20240216BHJP

   G06F 21/44 20130101ALI20240216BHJP

   H04L 9/32 20060101ALI20240216BHJP

【ＦＩ】

G06F21/62 309

G06F21/44

H04L9/32 200B

【請求項の数】 10

【外国語出願】

(21)【出願番号】P 2022137984

(22)【出願日】2022-08-31

(62)【分割の表示】P 2020535258の分割

【原出願日】2019-10-15

(65)【公開番号】P2022172251

(43)【公開日】2022-11-15

【審査請求日】2022-09-01

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ガン・ワン

(72)【発明者】

【氏名】カーティス・ライト

【審査官】小林 秀和

(56)【参考文献】

【文献】特開２００３－３４５７０７（ＪＰ，Ａ）

【文献】特開２０１２－１５５３９７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１４／０２８２９３３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０３５０２０４（ＵＳ，Ａ１）

【文献】特開２０１３－２４２８５１（ＪＰ，Ａ）

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

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ ２１／４４

Ｈ０４Ｌ ９／３２

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

【請求項1】

1つまたは複数のサーバが、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を含むデータ要求を受信するステップと、
前記1つまたは複数のサーバが、前記1つまたは複数の属性に基づいて、応答データを選択するステップと、
前記1つまたは複数のサーバが、少なくとも前記1つまたは複数の属性を暗号化して、暗号化された値を生成するステップと、
前記1つまたは複数のサーバが、前記暗号化された値を含む妥当性確認チャレンジを生成するステップであって、前記妥当性確認チャレンジは、前記妥当性確認チャレンジに対して予測される応答をさらに含み、前記予測される応答は、前記サーバによって生成され、前記妥当性確認チャレンジは、前記クライアントデバイスが前記妥当性確認チャレンジに対して正確な回答を生成するかどうかに基づいて、前記応答データに対するアクセスを制御し、前記アクセスを制御することが、
前記妥当性確認チャレンジに対して前記クライアントデバイスによって生成されたチャレンジ回答が、前記予測される応答と整合するとき、前記応答データに対するアクセスを前記クライアントデバイスに提供することであって、
前記暗号化された値は、前記クライアントデバイスにおいて解読されることで、前記妥当性確認チャレンジが前記データ要求に対応するか否かを前記クライアントデバイスが判定することを可能とするように構成され、
前記チャレンジ回答は、前記妥当性確認チャレンジが前記データ要求に対応するとの判定に応答して、前記クライアントデバイスにより生成される、提供することと、
前記クライアントデバイスによって生成された前記チャレンジ回答が、前記予測される応答と整合しないとき、前記クライアントデバイスが前記応答データにアクセスすることを防止することと
を含む、生成するステップと、
前記1つまたは複数のサーバが、前記妥当性確認チャレンジで前記応答データを保護するステップと、
前記1つまたは複数のサーバが、前記妥当性確認チャレンジで保護された前記応答データを前記クライアントデバイスに送信するステップと
を含む、方法。

【請求項2】

前記クライアントデバイスにおいて、チャレンジ応答を生成するステップと、
前記クライアントデバイスにおいて、前記チャレンジ応答が前記妥当性確認チャレンジに対する有効な応答であるかどうかを判定するステップと、
前記チャレンジ応答が前記妥当性確認チャレンジに対する有効な応答であるとの判定に応答して、前記クライアントデバイスが前記応答データにアクセスするステップと
をさらに含む、請求項1に記載の方法。

【請求項3】

前記応答データに対するアクセスを前記クライアントデバイスに提供するステップが、前記クライアントデバイスが前記妥当性確認チャレンジに対する有効な応答を生成するとき、前記クライアントデバイスが前記クライアントデバイス上で前記応答データにアクセスすることを可能にする実行可能コードを前記クライアントデバイスに提供するステップを含む、請求項1または請求項2に記載の方法。

【請求項4】

前記1つまたは複数の属性が、前記クライアントデバイスのブラウザの公開鍵、前記クライアントデバイスの公開鍵、前記クライアントデバイスのアドレス、前記サーバのクッキー名およびクッキー値、またはアプリケーション名のうちの1つまたは複数を含む、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記妥当性確認チャレンジを生成するステップが、
一意の値を生成するステップと、
前記クライアントデバイスの公開鍵を取り出すステップと、
前記クライアントデバイスの前記公開鍵を使用して、前記一意の値および前記要求の1つまたは複数の属性を暗号化するステップと、
前記暗号化された一意の値および前記暗号化された値を含む前記妥当性確認チャレンジを生成するステップと
を含む、請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記1つまたは複数のサーバが、前記妥当性確認チャレンジで前記応答データを保護するステップが、前記クライアントデバイスの公開鍵を使用して、前記応答データの少なくとも一部分を暗号化するステップを含む、請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記要求されたデータが提供されることになる前記クライアントデバイスの前記環境を特徴付ける前記1つまたは複数の属性を含む前記データ要求を受信するステップが、前記1つまたは複数の属性の少なくとも一部分を記憶する中間サーバから前記データ要求を受信するステップを含む、請求項1から6のいずれか一項に記載の方法。

【請求項8】

前記1つまたは複数のサーバが、前記妥当性確認チャレンジで保護された前記応答データを前記クライアントデバイスに送信するステップが、
前記クライアントデバイスのアドレスを前記データ要求から抽出するステップと、
前記妥当性確認チャレンジを前記クライアントデバイスの前記アドレスに送信するステップと
を含む、請求項1から7のいずれか一項に記載の方法。

【請求項9】

請求項1から8のうちのいずれか一項に記載の方法を実行するように構成された1つまたは複数のサーバを含む、システム。

【請求項10】

請求項1から8のうちのいずれか一項に記載の方法を前記1つまたは複数のサーバに実行させる命令を含む、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを保護するためのシステムおよび方法に関する。

【背景技術】

【0002】

インターネットは、多種多様なデータに対するアクセスを可能にした。状況によっては、データに対するアクセスは、たとえば、データを保護するパスワードによって制限されることがある。データに対するアクセスを制限するために、暗号化技術など、他の技術を使用することもできる。

【発明の概要】

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

【0003】

本書は、データを保護するための技法について論じる。本書を通して詳細に論じるように、データを受信するデバイス(たとえば、データに対するアクセスを要求しているデバイス)に、データに対する要求に応じて提供されるデータ内に埋め込まれたチャレンジ(challenge)に正確に応答する(たとえば、回答する)ことを要求することによって、データは保護され得る。データを受信するデバイスがそのチャレンジに対して正確な応答を生成することができる場合、そのデバイスは、そのデータを受信することが意図されたデバイスとして確認され(validate)得る。追加または代替として、デバイスがそのチャレンジに対して正確な応答を生成することができる場合、その正確な応答は、要求されたデータが意図されたように、たとえば、そのデータに対する要求内で受信された情報に従って、使用されていることを示し得る。たとえば、チャレンジに対して正確な応答を生成するために、データを受信するデバイス(たとえば、デバイスのユーザではない)は、データが実際に使用されているコンテキストがそのデータに対する要求内で指定された、提案されるコンテキストと整合することを確認することを要求され得る。言い換えれば、チャレンジは、その要求に応じてデータの配信をトリガしたサーバによるそのデータの使用に対して適切な環境と見なされた、その要求内で指定されたコンテキストが、実際に、そのデータが実際に使用されることになるコンテキストであること確実にし得る。これは、あるデバイスがその要求内で適切なコンテキスト情報を使用してそのデータに対するアクセスを要求し、次いで、そのデータを受信した後、そのデータを不適切な環境に転送するか、またはさもなければリダイレクトする、「スプーフィング」活動を防止し得る。

【0004】

いくつかの実装形態では、サーバは、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を含むデータ要求を受信する。たとえば、要求は、異なるエンティティによって配信されるコンテンツを有するリソース(たとえば、デジタル成分(digital component)を提供するエンティティとは異なるエンティティによって提供されるウェブページまたはネイティブアプリケーション)内に組み込まれることになるデジタル成分に対する要求であり得る。この例では、クライアントデバイスの環境を特徴付ける属性は、デジタル成分が提示されることになるコンテキストを指定し得る。コンテキストは、デジタル成分が提示のためにその中に組み込まれることになるアプリケーションまたはウェブページによって少なくとも部分的に定義され得る。様々な他の情報が要求の一部分であり得る。たとえば、要求は、コンテキスト情報の代わりにまたはそれに加えて、サーバがコンテキスト情報を取り出すことができるロケーションを指定し得る。1つまたは複数の属性は、クライアントデバイスのブラウザの公開鍵、クライアントデバイスの公開鍵、クライアントデバイスのアドレス、サーバのクッキー名およびクッキー値、およびアプリケーション名の任意の組合せを含み得る。

【0005】

サーバは、受信された1つまたは複数の属性に基づいて、応答データを選択する。いくつかの実装形態では、サーバは、たとえば、その要求からのコンテキスト情報を使用して、(たとえば、アプリケーションのタイプ、名称、または別の特性に基づいて)アプリケーション内でユーザに提示されることになるデジタル成分を選択することができる。いくつかの実装形態では、応答データは、妥当性確認チャレンジ(validation challenge)と組み合わせて、応答データに対するアクセスを制御するために使用される応答スクリプトと組み合わされる。

【0006】

サーバは、応答データに対するアクセスを制御する妥当性確認チャレンジを生成する。すなわち、妥当性確認チャレンジに対するクライアントデバイスの回答がその妥当性確認チャレンジに正確に回答するとき、応答データに対するアクセスがクライアントデバイスに提供される。妥当性確認チャレンジに対するクライアントデバイスの応答が妥当性確認チャレンジに正確に回答しないとき、クライアントデバイスが応答データにアクセスすることは防止される。たとえば、サーバは、クライアントデバイスのみが解読することができる暗号化された一意の値を生成し得る。いくつかの実装形態では、妥当性確認チャレンジを生成する際に、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性が使用される。特定の例では、要求の1つまたは複数の属性はまた、(たとえば、クライアントデバイスの公開鍵を使用して)一意の値とともに暗号化される。これらの属性は、妥当性確認チャレンジの背後で1つまたは複数のサーバを確認するためにクライアントデバイスによって使用され得る。いくつかの実装形態では、クライアントデバイスが妥当性確認チャレンジに正確に回答した場合ですら、クライアントデバイスが応答データをユーザに提示するために応答データの少なくとも一部分を解読することが可能である必要が依然としてあるように、応答データ自体が暗号化されたデータを含み得る。この追加の暗号化は、応答データにアクセスするために妥当性確認チャレンジを迂回することを防止し得る。

【0007】

サーバは、妥当性確認チャレンジで応答データを保護する。たとえば、受信側クライアントデバイスが、妥当性確認チャレンジを解読して処理することができるかどうか、ならびに妥当性確認チャレンジに適切に応答することができるかどうかに基づいて、選択されたデジタル成分に対するアクセスが提供され得るか、または防止され得る。上記で論じたように、いくつかの実装形態では、応答データの少なくとも一部分が(たとえば、追加の保護のために)暗号化され得る。それらの実装形態では、応答データの暗号化バージョンが妥当性確認チャレンジ内に含まれる。サーバは、次いで、妥当性確認チャレンジおよび元の要求に対する応答データをクライアントデバイスに送信し得る。たとえば、サーバは、妥当性確認チャレンジとともに、デジタル成分をクライアントデバイスに送信し得る。デジタル成分は、クライアントデバイスが妥当性確認チャレンジに正確に回答しない限り、かつそれまで、クライアントデバイスがデジタル成分にアクセスすることまたはそれを提示することができない方法で保護される。たとえば、デジタル成分パッケージは、クライアントデバイスが妥当性確認チャレンジに対する有効な応答を生成したときのみ、クライアントデバイスがクライアントデバイス上で応答データにアクセスすることを可能にする実行可能コード(たとえば、応答スクリプト)を含み得る。したがって、実行可能コードは、妥当性確認チャレンジが正確に回答された後でのみ、デジタル成分をレンダリングすることを可能にする。

【0008】

いくつかの実装形態では、デジタル成分パッケージは、妥当性確認チャレンジに対して予測される応答(たとえば、サーバによって生成される一意の値の暗号学的ハッシュ)を含む。妥当性確認チャレンジは、サーバによって生成されるが、クライアントデバイスの公開鍵で暗号化された、一意の値の別の複写を含んでもよい。いくつかの実装形態では、妥当性確認チャレンジに対して予測される応答の代わりにまたはそれに加えて、サーバは、対称鍵暗号化アルゴリズムを使用して、応答データの少なくとも一部分を暗号化し得る。

【0009】

クライアントデバイスは、たとえば、そのクライアントデバイスがそれを用いて妥当性確認チャレンジが暗号化された公開鍵に対応する秘密鍵を有する場合、妥当性確認チャレンジを受信して、それを解読する。すなわち、妥当性確認チャレンジがクライアントデバイスの公開鍵によって暗号化された場合、クライアントデバイスは、その秘密鍵を用いて妥当性確認チャレンジを解読することができる。妥当性確認チャレンジが解読されるとき、クライアントデバイスは、デジタル成分パッケージから一意の値を取り出し、その一意の値をチャレンジ回答に変換する(たとえば、解読された一意の値の暗号学的ハッシュを生成する)。たとえば、クライアントデバイスは、セキュアハッシュアルゴリズム(SHA：Secure Hash Algorithm)関数など、暗号学的ハッシュ関数を一意の値に対して実行し、暗号学的ハッシュを生成することができる。クライアントデバイスは、応答スクリプト(たとえば、デジタル成分スクリプト)を実行し、生成されたチャレンジ回答(たとえば、クライアントデバイス上で生成された一意の値の暗号学的ハッシュ)をそのスクリプトに提出することができる。このスクリプトは、提出されたハッシュを予測される応答(たとえば、サーバ上で生成された暗号学的ハッシュ)と比較する。これらのハッシュが整合する場合、クライアントデバイスは、デジタル成分にアクセスしてレンダリングする。これらのハッシュが整合しない場合、デジタル成分に対するアクセスは防止される。

【0010】

クライアントデバイスは、チャレンジ内で受信された、解読された1つまたは複数の属性を元のデータ要求の1つまたは複数の属性と比較することによって、自ら妥当性確認チャレンジを確認する。これらの属性が整合する場合、クライアントデバイスは、一意の値の暗号学的ハッシュをデジタル成分スクリプトに提出する。これらの属性が整合しない場合、クライアントデバイスは、応答スクリプトの実行を控えることができる。上述のように、たとえば、応答データを取り出すためにデジタル成分スクリプトを迂回することができないように、応答データの一部分または全体が暗号化され得る。そのような場合、クライアントデバイスがこれらのハッシュは整合すると判定したとき、クライアントデバイスは、(応答スクリプトを使用して)応答データを解読し、データをユーザに提示する。

【0011】

いくつかの実装形態では、要求はクライアントデバイス自体からではなく、中間サーバから受信される。これらの実装形態では、サーバは、クライアントデバイスのアドレスをその要求から取り出し、応答データとともに妥当性確認チャレンジをそのアドレスに送信する。これは、応答データがアプリケーション内に提示されるべきであるが、しかし、アプリケーション内のコンテキスト情報がユーザデバイスには知られていないが、アプリケーションプロバイダの中間サーバには知られている場合に有利であり得る。

【0012】

開示するデータ保護技法は、様々な利点を提供する。たとえば、開示するデータ保護技法は、要求されたデータがユーザに提示されることになる環境の妥当性の確認を可能にする。妥当性の確認は、要求に対する応答自体が、クライアントとサーバとの間の追加の通信を必要とせずに、その環境を確認する方法を含む方法で実行される。その上、この技法は、クライアントデバイスがサーバからのデータを確認して、その要求自体が、応答データを提示するための適切な環境属性を有するクライアントデバイスによって送られたこと、またはクライアントデバイスに代わって送られたことを確認することを可能にする。

【0013】

開示するデータ保護技法が提供する別の利点は、中間サーバによる攻撃および/または不正行為の試行にある。たとえば、応答データが中間サーバのネットワークを通じてサーバからクライアントデバイスに送信されるとき、中間サーバのうちの1つまたは複数が、応答データを異なるユーザおよび/または異なる環境に提示しようと試み、応答データを異なるクライアントデバイスにリダイレクトすることを試みることがあるが、異なるクライアントデバイスは、妥当性確認チャレンジに正確に回答し、それにより、応答データにアクセスすることができないことになるため、開示する技法はこの不正行為を防止する。

【0014】

本明細書で開示する技法は、データに対する不法なアクセスを防止することが所望されるいずれの適切なコンテキストに関連し得る。本開示を単により具体的に示すために、保護されるべきデータが広告データまたは旅行アプリケーション用のデータである例示的なコンテキストについて以下で論じる。これらは、本明細書で開示する技法が使用され得るコンテキストの非限定的な例であり、他のコンテキストが可能であることを諒解されよう。

【0015】

いくつかの実装形態では、1つまたは複数のサーバは、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を含むデータ要求を受信する。1つまたは複数のサーバは、1つまたは複数の属性に基づいて、応答データを選択し、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を使用して、クライアントデバイスが妥当性確認チャレンジに対して正確な回答を生成するかどうかに基づいて、応答データに対するアクセスを制御する妥当性確認チャレンジを生成し、それにより、クライアントデバイスによって生成された回答が妥当性確認チャレンジに正確に応答し、クライアントデバイスが妥当性確認チャレンジ内で指定された環境の1つまたは複数の属性を確認するとき、応答データに対するアクセスをクライアントデバイスに提供し、クライアントデバイスによって生成された回答が妥当性確認チャレンジに正確に応答しないとき、またはクライアントデバイスが妥当性確認チャレンジ内で指定された環境の1つまたは複数の属性を確認しないとき、クライアントデバイスが応答データにアクセスすることを防止する。1つまたは複数のサーバは、妥当性確認チャレンジで応答データを保護し、妥当性確認チャレンジで保護された応答データをクライアントデバイスに送信する。

【0016】

クライアントデバイスは、チャレンジ応答を生成し、チャレンジ応答が妥当性確認チャレンジに対する有効な応答であるかどうかを判定する。チャレンジ応答が妥当性確認チャレンジに対する有効な応答であるとの判定に応答して、クライアントデバイスは応答データにアクセスする。

【0017】

いくつかの実装形態では、応答データに対するアクセスをクライアントデバイスに提供することは、クライアントデバイスが妥当性確認チャレンジに対する有効な応答を生成するとき、クライアントデバイスがクライアントデバイス上で応答データにアクセスすることを可能にする実行可能コードをクライアントデバイスに提供することを含む。

【0018】

いくつかの実装形態では、1つまたは複数の属性は、クライアントデバイスのブラウザの公開鍵、クライアントデバイスの公開鍵、クライアントデバイスのアドレス、サーバのクッキー名およびクッキー値、またはアプリケーション名のうちの1つまたは複数を含む。加えて、いくつかの実装形態では、妥当性確認チャレンジを生成することは、一意の値を生成することと、クライアントデバイスの公開鍵を取り出すことと、クライアントデバイスの公開鍵を使用して、一意の値および要求の1つまたは複数の属性を暗号化することと、暗号化された一意の値と、1つまたは複数の属性のうちの1つとを含む、妥当性確認チャレンジを生成することとを含む。

【0019】

いくつかの実装形態では、1つまたは複数のサーバは、クライアントデバイスの公開鍵を使用して、応答データの少なくとも一部分を暗号化することによって、妥当性確認チャレンジで応答データを保護する。さらに、いくつかの実装形態では、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を含むデータ要求を受信することは、1つまたは複数の属性の少なくとも一部分を記憶する中間サーバからデータ要求を受信することを含む。

【0020】

いくつかの実装形態では、1つまたは複数のサーバは、クライアントデバイスのアドレスをデータ要求から抽出し、妥当性確認チャレンジをクライアントデバイスのアドレスに送信することによって、妥当性確認チャレンジで保護された応答データをクライアントデバイスに送信する。

【0021】

本明細書で説明する主題の1つまたは複数の技法の詳細について、添付の図面および以下の発明を実施するための形態に記載する。本主題の他の特徴、態様、および利点は、発明を実施するための形態、図面、および特許請求の範囲から明らかになるであろう。

【図面の簡単な説明】

【0022】

【図1】本開示で論じる技法による通信シーケンスを示す図である。

【図2】妥当性確認チャレンジで応答データを保護するためのブロック図である。

【図3】データ要求内に含まれ、サーバによって受信され得る例示的な属性を含むデータ構造を示す図である。

【図4】妥当性確認チャレンジ用のフィールドを含むデータ構造の一例を示す図である。

【図5】クライアントデバイスが妥当性確認チャレンジに対する回答を実行し得る例示的な活動のブロック図である。

【図6】応答データに対するアクセスを提供するかまたは防止するかを判定するためにスクリプトが実行し得る活動を示す図である。

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

【0023】

様々な図面における同様の参照番号および指定は、同様の要素を示す。

【0024】

図1は、本開示で論じる技法による通信シーケンスを示すシステム100を示す。システム100は、クライアントデバイス102を含む。クライアントデバイス102は、スマートフォン、電子タブレット、または別の好適なクライアントデバイスであってよい。システム100はまた、クライアントデバイスと通信するための1つまたは複数のサーバ104を含む。具体的には、1つまたは複数のサーバ104は、データ要求をクライアントから受信し、保護された応答データを含む妥当性確認チャレンジをクライアントデバイス102に送信する。データ要求は、何のユーザ入力もなしにかつ/またはそれとは無関係に、クライアントデバイス上でウェブブラウザまたは別のアプリケーションによって生成される。クライアントデバイスは、妥当性確認チャレンジを受信し、チャレンジ応答をアプリケーション106に(たとえば、応答データがユーザに提示されることになるブラウザまたは別のアプリケーションに)提出する。

【0025】

図2は、妥当性確認チャレンジで応答データを保護するためのプロセス200のブロック図である。202において、(たとえば、サーバ104の中の)1つまたは複数のサーバは、要求されたデータが提供されることになるクライアントデバイスの環境を特徴付ける1つまたは複数の属性を含むデータ要求を受信する。データ要求は、クライアントデバイスのブラウザの公開鍵、クライアントデバイスの公開鍵、クライアントデバイスのアドレス、サーバのクッキー名およびクッキー値(たとえば、応答データが提示されることになるウェブページにサービスしているサーバに対するクッキーの名称および値)、アプリケーション名、および他の好適な属性のうちの1つまたは複数を含み得る。データ要求がクライアントデバイス自体から受信される場合、クライアントデバイスは、環境のどの属性がデータ要求内に含まれる必要があるかを判定し得る。

【0026】

いくつかの実装形態では、データ要求は中間サーバによって生成されるが、これは、たとえば、中間サーバは、応答データがユーザに提示されることになるクライアントデバイスの環境に関して何らかの情報を有し得るためである。具体的には、応答データがアプリケーション内で(たとえば、クライアントデバイス上でプレイされるゲーム内で)ユーザに提示されることになる場合、クライアントデバイスは、特に、アプリケーションとデータを提供するサーバとの間の通信が暗号化されている場合、応答データが提示されることになる環境を判定するために、アプリケーションにアクセスすることができないことがある。しかしながら、アプリケーションにデータを提供している中間サーバは、その環境に関するデータを有する場合がある。たとえば、アプリケーションが旅行アプリケーションである場合、(たとえば、探索要求に応答して)旅行情報をアプリケーションに提供しているサーバは、応答データが提示されることになる環境情報に関してより良いデータを有する。すなわち、ユーザが特定の旅行ロケーションを探索している場合、その情報は中間サーバに知られているが、クライアントデバイスには知られていない。したがって、これらの実装形態では、中間サーバは、データ要求を生成して送信する。いくつかの実装形態では、中間サーバは、中間サーバが有さない可能性がある何らかの属性(たとえば、クライアントデバイス上のアプリケーションの公開鍵)についてクライアントデバイスに問い合わせる。

【0027】

図3は、データ要求内に含まれ、サーバによって受信され得る例示的な属性を含むデータ構造300を示す。公開鍵302は、クライアントデバイスが妥当性確認チャレンジを解読するために使用し得る、クライアントデバイス上の秘密鍵に対応する公開鍵である。いくつかの実装形態では、公開鍵は、デバイス自体の公開鍵である。他の実装形態では、公開鍵は、応答データがユーザに提示されることになるアプリケーションに対して生成された公開鍵である。たとえば、ウェブブラウザは、何らかのクライアントデバイス公開/秘密鍵に加えて、またはその代わりに生成された公開/秘密鍵の対を有する場合がある。したがって、応答データが(たとえば、データ要求に応答して)提示されることになるアプリケーションがブラウザである場合、データ要求は、そのブラウザ内の秘密鍵に対応する公開鍵を含み得る。サーバは、公開/秘密鍵インフラストラクチャ(PKI：public/private key infrastructure)の様々な実装形態を使用して、クライアントデバイスに対する公開鍵および秘密鍵を生成し得る。

【0028】

インターネットプロトコル(IP)アドレス304は、そこに妥当性確認チャレンジを送ることができるクライアントデバイスのIPアドレスである。要求がクライアントデバイスから受信される実装形態では、データ要求を生成するクライアントデバイス上のアプリケーションは、クライアントデバイスのIPアドレスに関して、クライアントデバイスのオペレーティングシステムに問い合わせることができる。データ要求がクライアントデバイスからではなく、たとえば、中間サーバから来る実装形態では、中間サーバは、アドレスに関してクライアントデバイスに問い合わせることができるか、または応答データが表示されることになるアプリケーションを使用して送受信された通信に基づいて、クライアントデバイスのアドレスを判定することができる。

【0029】

ユニフォームリソースロケータ(URL)306は、応答データが表示されることになるウェブページのアドレスであり得る。たとえば、応答データがブラウザ内に表示されることになる場合、URLは、ウェブサイトおよび/またはウェブページのコンテキストまたはタイプ、ならびにウェブサイトおよび/またはウェブページに関する他の情報についてサーバに知らせることができる。アプリケーション名308は、応答データが表示されることになるアプリケーション名である。フィールド310は、データ要求の一部としてサーバによって受信され得る1つまたは複数の他の属性を含み得る。他の属性は、たとえば、アプリケーション内のコンテキストを含み得る。旅行アプリケーションの場合、コンテキストは、ユーザが要求した旅行ロケーションであり得る。乗車サービスアプリケーションの場合、コンテキストは、ユーザの現在のロケーションおよび目的地、ならびに他のユーザ選好であり得る。いくつかの実装形態では、データ構造300に他の属性フィールドが追加されてよい。

【0030】

図2に戻ると、204において、(たとえば、サーバ104の)サーバは、1つまたは複数の属性に基づいて、応答データを選択する。応答データは、デジタル成分であり得る。本書を通じて使用される「デジタル成分」という句は、デジタルコンテンツまたはデジタル情報の個別単位(たとえば、ビデオクリップ、オーディオクリップ、マルチメディアクリップ、画像、テキスト、または別のコンテンツ単位)を指す。デジタル成分は、単一のファイルとして物理的メモリデバイス内にまたはファイルの収集物の中に電子的に記憶されてよく、デジタル成分は、ビデオファイル、オーディオファイル、マルチメディアファイル、画像ファイル、またはテキストファイルの形態をとってよく、広告があるタイプのデジタル成分であるように、広告情報を含み得る。いくつかの実装形態では、デジタル成分は、デジタル成分のデータをユーザに提示するためのスクリプトを含むか、またはその中に挿入されてよい。スクリプトは、妥当性確認チャレンジに対する回答が正確かどうかを判定するための実行可能命令を含み得る。

【0031】

いくつかの実装形態では、妥当性確認チャレンジは、広告のコンテキストで使用され得る。すなわち、クライアントデバイス(たとえば、スマートフォンまたは電子タブレット)上のウェブブラウザまたは別のアプリケーションは、ユーザに提示するための広告がクライアントデバイスに送られることを要求し得る。サーバは、クライアントデバイスに送信し戻すための属性(たとえば、広告が表示されることになる環境)に基づいて、広告を選択し得る。いくつかの実装形態では、広告は広告スクリプト内にカプセル化される。選択された広告を含む広告スクリプトは、妥当性確認チャレンジによって保護されることになる応答データであり得る。

【0032】

いくつかの実装形態では、妥当性確認チャレンジは、旅行のコンテキストで使用され得る。たとえば、ユーザデバイスは、ユーザが始点から終点まで旅行することを望むとき、データ要求を生成し得る。データ要求は、1つまたは複数の属性として、始点および終点を含み得る。加えて、データ要求は、ユーザおよびユーザデバイスに関する他の情報を含み得る。サーバがデータ要求を受信するとき、サーバは、クライアントデバイスに送信するための応答データ(たとえば、デジタル成分)を選択し得る。デジタル成分は、ユーザに利用可能な1つまたは複数の車両に関する情報を含み得る。デジタル成分は、旅行に対して必要とされる他の情報を含み得る。さらに、チャレンジ妥当性確認プロセスは、旅行のコンテキストで運転手に対して使用され得る。すなわち、運転手のクライアントデバイスは、その運転手がサーバに送られた運転手の環境の属性を有する運転活動に対して利用可能であることをサーバに示すデータ要求を生成し得る。これらの属性は、運転手のロケーション、運転手の識別情報、運転手のクライアントデバイスの公開鍵、および上記で論じた属性のうちのいずれかを含む他の好適な属性を含み得る。

【0033】

図2を再度参照すると、206において、(たとえば、サーバ104の)サーバは、応答データに対するアクセスを制御する妥当性確認チャレンジを生成する。妥当性確認チャレンジは、クライアントデバイスが妥当性確認チャレンジに対して正確な回答を生成するかどうかに基づいて、応答データに対するアクセスを制御する。具体的には、クライアントデバイスによって生成された回答が妥当性確認チャレンジに正確に応答するとき、応答データに対するアクセスがクライアントデバイスに提供される。クライアントデバイスによって生成された回答が妥当性確認チャレンジに対して正確に応答しないとき、クライアントデバイスが応答データにアクセスすることは防止される。サーバは、様々な方法で妥当性確認チャレンジを生成し得る。いくつかの実装形態では、サーバは、暗号化を使用して、妥当性確認チャレンジを生成することができる。サーバは、一意の値を生成し得る。一意の値は、たとえば、数値(たとえば、2桁以上の数字)、16進値、用語、句、または別の好適な一意の値であってよい。たとえば、サーバは、乱数発生器を使用して、1つまたは複数のアルゴリズムと組み合わせて一意の値を生成し得る。

【0034】

いくつかの実装形態では、一意の値は、要求の1つまたは複数のパラメータを使用して生成され得る。たとえば、サーバは、要求からのIPアドレス、要求からのURLのハッシュ、および/または要求からのアプリケーション名を使用して、一意の値を生成し得る。以下は、一意の値に対する例示的なデータ構造である：
{Unique value： …
IP Address： …
Application name： …}
データ構造は、JavaScriptオブジェクト表記法(JSON：JavaScript Object Notation)のようなフォーマットとして記憶され得る。いくつかの実装形態では、データ構造のサイズを低減するために、2進符号化方式(たとえば、プロトコルバッファまたはcbor http：//cbor.io)が適合され得る。

【0035】

いくつかの実装形態では、サーバは、クライアントデバイスの公開鍵を取り出すかまたは受信する。上記で論じたように、クライアントデバイスの公開鍵は、データ要求内に含まれてよく、したがって、サーバは、クライアントデバイスの公開鍵を要求から取り出すことができる。いくつかの実装形態では、サーバは、クライアントデバイス自体に問い合わせることによって、公開鍵をクライアントデバイスから取り出すことができる。別の例では、サーバは、クライアントデバイスの公開鍵を中間サーバから取り出すことができる。この実装形態では、必要とされる鍵がクライアントデバイス上の特定のアプリケーションからであるとき、クライアントデバイスは、その鍵に対するアクセスを有さない可能性があるが、代わりに、中間サーバがその鍵を記憶し得る。したがって、サーバは、公開鍵を中間サーバから取り出すことができる。

【0036】

サーバが、クライアントデバイスの公開鍵を取得し、一意の値を生成するとき、サーバは、クライアントデバイスの公開鍵を使用して一意の値を暗号化する。暗号化された一意の値は、妥当性確認チャレンジの一部になる。加えて、サーバは、生成された一意の値の暗号学的ハッシュを生成し得る。サーバは、セキュアハッシュアルゴリズム(SHA)関数などの暗号学的ハッシュ関数を一意の値に対して実行して暗号学的ハッシュを生成し得る。サーバは、一意の値の暗号学的ハッシュを妥当性確認チャレンジに追加する。暗号学的ハッシュは、予測される応答になる。

【0037】

いくつかの実装形態では、暗号学的ハッシュは、クライアントデバイス上で比較するためにスクリプトまたは他の実行可能コードに追加される。たとえば、スクリプトは、クライアントデバイスが妥当性確認チャレンジに対する有効な応答を生成するとき、クライアントデバイスがクライアントデバイス上で応答データにアクセスすることを可能にする実行可能コードであり得る。クライアントデバイスは、妥当性確認チャレンジに回答するとき、スクリプトを実行し得る。いくつかの実装形態では、サーバは、クライアントデバイスの公開鍵を使用して、データ要求内で受信された属性のうちの1つまたは複数を暗号化する。クライアントデバイスは、属性を解読し、これらの属性を使用して自ら妥当性確認チャレンジを確認し得る。すなわち、クライアントデバイスが、妥当性確認チャレンジがサーバによって受信された特定のデータ要求に応答しているかどうかを判定し得る。

【0038】

図2を再度参照すると、208において、(たとえば、サーバ104の)サーバは、妥当性確認チャレンジで応答データを保護する。たとえば、サーバは、(たとえば、クライアントデバイスの公開鍵を使用して暗号化された一意の値、一意の値の暗号学的ハッシュを含む予測される応答、およびいくつかの実装形態では、クライアントデバイスの公開鍵を使用して暗号化されたデータ要求内で受信された属性を含めて)応答データおよび妥当性確認チャレンジを含むデータ要求に応答して応答パッケージを生成し得る。応答パッケージは、他のデータを含んでよい。上記で論じたように、デジタル成分は、応答データまたは応答データの一部分であってよい。いくつかの実装形態では、予測される応答を妥当性確認チャレンジに追加することに加えて、またはその代わりに、サーバは、対称鍵暗号化アルゴリズムを使用して、またはクライアントデバイスの公開鍵(たとえば、クライアントデバイスのブラウザの鍵)を使用して、応答データの少なくとも一部分を暗号化し得る。クライアントデバイスは、クライアントデバイスによって返された一意の値を解読鍵として使用して、同じ対称鍵暗号化アルゴリズムを使用して応答データを解読し得る。応答データの一部分がクライアントデバイスの公開鍵を使用して暗号化されている場合、クライアントデバイスは、対応する秘密鍵を使用して、応答データのその部分を解読し得る。

【0039】

広告のコンテキストでは、応答データは、実行可能コードに加えて、ユーザに提示されるべき広告をそのスクリプト内に含むスクリプト(たとえば、広告スクリプト)を含み得る。旅行のコンテキストでは、応答データは、データ要求内で指定された始点から終点までユーザを運ぶことができる車両に関する運転手/車両情報を備えるデジタル成分を含み得る。運転手側の旅行のコンテキストでは、応答データは、運転手が所望の始点から所望の終点まで乗客を運ぶための乗客情報を備えたデジタル成分を含み得る。すべてのコンテキストで、応答データは、スクリプト内にカプセル化され得、かつ/またはクライアントデバイスの公開鍵を使用して暗号化され得る。

【0040】

いくつかの実装形態では、サーバは(たとえば、クライアントデバイスの公開鍵を使用して)応答データの少なくとも一部分を暗号化する。応答データの暗号化は、クライアントデバイス上のまたは中間サーバにおけるシステムまたはアプリケーションが、応答データの抽出を試みることによって、スクリプトを迂回すること、または妥当性確認チャレンジの打破を試みることを防止するために有用であり得る。クライアントデバイスは、応答データをユーザに提示する前に、応答データの暗号化された部分を解読し得る。図4は、妥当性確認チャレンジ内のフィールドを含むデータ構造400の一例を示す。フィールド402は、(たとえば、クライアントデバイスの公開鍵を使用して暗号化された)暗号化された一意の値を含む。フィールド404は、予測される応答(たとえば、一意の値の暗号学的ハッシュ)を含む。フィールド406は、応答データを含む。たとえば、フィールド406は、デジタル成分を含み得る。いくつかの実装形態では、フィールド404および406は、予測される応答および応答データを含むスクリプトを記憶する単一のフィールドである。フィールド408は、応答内で受信された1つまたは複数の暗号化された属性を記憶する。上記で論じたように、属性は、クライアントデバイス上で妥当性確認チャレンジを確認するために使用され得る。フィールド410が示すように、他のデータがデータ構造400内に含まれてよい。

【0041】

図2を再度参照すると、210において、(たとえば、サーバ104の)サーバは、妥当性確認チャレンジで保護された応答をクライアントデバイスに送信する。いくつかの実装形態では、サーバは、クライアントデバイスのアドレス(たとえば、IPアドレス)を要求から抽出し、妥当性確認チャレンジをクライアントデバイスのアドレスに送信する。いくつかの実装形態では、サーバは、クライアントデバイスのアドレスに対するアクセスを有さないことがある。たとえば、元のデータ要求が中間サーバから受信された場合、サーバは、クライアントデバイスにおいて最終的に受信されることになる妥当性確認チャレンジを中間サーバに送信し得る。いくつかの実装形態では、クライアントデバイスに送信される(たとえば、提供される)応答データは、クライアントデバイスが妥当性確認チャレンジに対する有効な応答を生成するとき、クライアントデバイスがクライアントデバイス上で応答データにアクセスすることを可能にする実行可能コードを含む。

【0042】

いくつかの実装形態では、サーバは、いくつかの中間サーバを介して妥当性確認チャレンジを送信する。中間サーバのうちの1つまたは複数は、応答データを傍受し、応答データを異なるクライアントデバイスにリダイレクトすることを試みることがある。しかしながら、特定のクライアントデバイスの公開鍵を使用して暗号化が実行されているため、クライアントデバイスのみが妥当性確認チャレンジに正確に回答し、応答データにアクセスすることが可能になる。

【0043】

いくつかの実装形態では、(たとえば、より遅いネットワーク上で)送信するために妥当性確認チャレンジのサイズを低減することは有用であり得る。これらのおよび他の実装形態では、妥当性確認チャレンジは、上記で論じた属性なしに(たとえば、アドレス、アプリケーション名、または他の好適な属性なしに)暗号化された一意の値を含み得る。応答データは、アルゴリズムに対する暗号鍵として一意の値の活動を用いて、対称鍵暗号化アルゴリズム(たとえば、高度暗号化標準アルゴリズム)を使用して暗号化され得る。有効なクライアントデバイスは、応答データにアクセスするために解読された一意の値と組み合わせることができるすべての他の属性情報を有することになるため、この実装形態は有用であり得る。加えて、妥当性確認チャレンジ自体が、対称鍵暗号化アルゴリズムを使用して暗号化され得る。対称鍵暗号化アルゴリズムを使用して妥当性確認チャレンジを暗号化するために、応答は、ウェブ要求(たとえば、ウェブページ内に含まれることになるデジタル成分に対する要求)であるべきである。他の要件は、サーバによって記憶されたブラウザのクッキー内にドロップされたクッキー、サーバがクッキー整合プロセスを通じてサーバ独自のクッキーを介してブラウザを認識すること、サーバがクッキーの盗難を防止するためにサーバのクッキーを適切に標示したこと、およびサーバが他の当事者とサーバのクッキー値を共有していないこと、を含み得る。また、サーバは、他の当事者がサーバのクッキー値を判定することが不可能であるように、各ブラウザを一意に識別するためのサーバのクッキー値内に十分なエントロピーを有するべきである。いくつかの実装形態では、サーバは、デマンドサイドプラットフォーム(DSP：demand-side platform)広告ネットワークの一部であってよく、応答データは、クライアントデバイス上でユーザに提示されることになる広告であってよい。

【0044】

図5は、クライアントデバイスが妥当性確認チャレンジに対する回答を実行し得る活動のブロック図である。502において、クライアントデバイスは、妥当性確認チャレンジで保護されたデータを受信する。たとえば、クライアントデバイスは、妥当性確認チャレンジを生成したサーバからまたは中間サーバから妥当性確認チャレンジを受信し得る。504において、クライアントデバイスは、クライアントデバイスの秘密鍵を使用して、妥当性確認チャレンジを解読する。妥当性確認チャレンジが正確に解読されるとき、クライアントデバイスは、妥当性確認チャレンジ内のデータを取り出すことができる。506において、クライアントデバイスは、妥当性確認チャレンジを確認する。クライアントデバイスは、妥当性確認チャレンジの一部として受信された属性をクライアントデバイスによってまたはクライアントデバイスに代わって生成された元のデータ要求の属性と比較する。妥当性確認チャレンジ内で受信された属性がデータ要求の属性(たとえば、環境の属性)と整合する場合、クライアントデバイスは、妥当性確認チャレンジがクライアントデバイスによってまたはクライアントデバイスに代わって生成されたデータ要求に対応すると判定する。妥当性確認チャレンジ内で受信された属性がデータ要求の属性と整合しない場合、クライアントデバイスは、妥当性確認チャレンジを確認しない(たとえば、妥当性確認チャレンジの処理を停止し、妥当性確認チャレンジに回答するのを控える)。508において、クライアントデバイスは、一意の値を取り出す。上記で論じたように、一意の値は、たとえば、数字、句、16進数、2桁以上の数字、語、または別の好適な値であってよい。異なるクライアントデバイスが応答データとともに妥当性確認チャレンジを受信する場合(たとえば、中間サーバが応答(すなわち、応答データおよび妥当性確認チャレンジ)を不正にリダイレクトしたために)、その異なるクライアントデバイスは、解読動作を正確に実行し、妥当性確認チャレンジに正確に回答することができないことになる。

【0045】

510において、クライアントデバイスは、一意の値をチャレンジ回答に変換する。たとえば、クライアントデバイスは、一意の値に対して暗号学的ハッシュアルゴリズムを実行し得る。変換方法は、一意の値が正確であるとき(すなわち、一意の値が、その要求内で指定されるように、応答データが使用されることになるコンテキストを表すとき)、結果として、予測される応答と同じ暗号学的ハッシュ値をもたらす。いくつかの実装形態では、変換方法は、(たとえば、同じ暗号学的ハッシングアルゴリズムを介して)サーバ変換方法と同期される。一意の値が正確でないとき、変換方法は、結果として、予測される応答と同じ暗号学的ハッシュ値をもたらさず、クライアントデバイスのコンテキストがその要求内で指定されるコンテキストとは異なることを示す。

【0046】

512において、クライアントデバイスは、チャレンジ回答を予測される応答と比較する。いくつかの実装形態では、クライアントデバイスは、妥当性確認パッケージの一部として受信されたスクリプトを取り出し、そのスクリプトを実行して比較を実行することができる。クライアントデバイスは、変換された一意の値をスクリプトに提出し得る。図6は、応答データに対するアクセスを提供するかまたは防止するかを判定するためにスクリプトが実行し得る活動を示す。602において、スクリプトは、チャレンジ応答を受信する。たとえば、スクリプトは、解読された一意の値の暗号学的ハッシュを入力として受信し得る。604において、スクリプトは、予測される応答データを取り出す。たとえば、スクリプトは、サーバ上でハッシュされた一意の値の暗号学的ハッシュを取り出すことができる。

【0047】

606において、スクリプトは、取り出された、予測される応答データをクライアントデバイスによって生成された回答とも呼ばれるチャレンジ応答と比較する。たとえば、スクリプトは、2つの暗号学的ハッシュを比較し得る。608において、スクリプトは、取り出された、予測される応答データ(たとえば、サーバによって生成された暗号学的ハッシュ)がチャレンジ応答内のデータ(たとえば、クライアントデバイス上で生成された暗号学的ハッシュ)と整合するかどうかを判定する。これらの暗号学的ハッシュが整合する場合、プロセス600は610に移り、ここで、スクリプトは、応答データに対するアクセスをクライアントデバイスに提供する。暗号学的ハッシュが整合しない場合、プロセス600は612に移り、ここで、スクリプトは、クライアントデバイスが応答データにアクセスすることを防止する。それにより、クライアントデバイスは、チャレンジ応答を生成し、チャレンジ応答が妥当性確認チャレンジに対する有効な応答であるかどうかを判定し、チャレンジ応答が妥当性確認チャレンジに対する有効な応答であるとの判定に応答して、応答データにアクセスする。

【0048】

クライアントデバイスによって生成された回答が妥当性確認チャレンジに正確に応答し、クライアントデバイスが妥当性確認チャレンジ内で指定された環境の1つまたは複数の属性を確認するとき、応答データに対するアクセスがクライアントデバイスに提供される。しかしながら、クライアントデバイスによって生成された回答が妥当性確認チャレンジに正確に応答しないか、またはクライアントデバイスが妥当性確認チャレンジ内で指定された環境の1つまたは複数の属性を確認しないとき、クライアントデバイスが応答データにアクセスすることは防止される。

【0049】

応答データの少なくとも一部分が暗号化される実装形態では、クライアントデバイス(たとえば、スクリプト)は、たとえば、対称鍵暗号化アルゴリズム(たとえば、高度暗号化標準(AES))を使用して、データを解読し得る。これらの実装形態は、要求がウェブ要求(たとえば、ウェブページ内に含まれることになるデジタル成分に対する要求)であることを必要とし得る。他の要件は、サーバによって記憶されたブラウザのクッキー内にドロップされたクッキー、サーバがクッキー整合プロセスを通じてサーバ独自のクッキーを介してブラウザを認識すること、サーバがクッキーの盗難を防止するためにサーバのクッキーを適切に標示したこと、およびサーバが他の当事者とサーバのクッキー値を共有していないこと、を含み得る。また、サーバは、他の当事者がサーバのクッキー値を判定することが不可能であるように、各ブラウザを一意に識別するためのサーバのクッキー値内に十分なエントロピーを有するべきである。いくつかの実装形態では、サーバは、デマンドサイドプラットフォーム(DSP)広告ネットワークの一部であってよく、応答データは、クライアントデバイス上でユーザに提示されることになる広告であってよい。

【0050】

応答データの少なくとも一部分が対称鍵暗号化アルゴリズムを使用して暗号化される実装形態では、クライアントデバイスは、応答データに対する解読鍵として、解読された一意の数字を使用し得る。すなわち、クライアントデバイスは、一意のデータが解読鍵である対称鍵暗号化アルゴリズムを使用して、応答データを解読し得る。

【0051】

図5を再度参照すると、514において、クライアントデバイスは、比較に基づいて、レンダリングポリシーを規定する。上記で論じたように、チャレンジ妥当性確認システムは、多くの異なるシナリオで実装され得る。レンダリングポリシーは、ブラウザまたは別のアプリケーション内に任意のタイプのデータをレンダリングするために使用され得る。たとえば、アプリケーションがゲームアプリケーションである場合、追加のゲームデータがゲームの内部にレンダリングされ得る。別の例では、チャレンジ妥当性確認システムが広告のコンテキストで実装される場合、システムは、様々な他の構成要素およびステップを含み得る。たとえば、元のデータ要求は、クライアントデバイスの広告識別子を含み得る。広告識別子は、デバイスまたはユーザ固有の情報を必要とせずに、他のシステムに対してそのデバイスを一意に識別する。スクリプトは、広告のコンテキストでは、広告に対するアクセスを可能にする広告スクリプトであり得る。したがって、レンダリングポリシーは、適切な環境の下で広告がユーザに提示されることを可能にする。すなわち、レンダリングポリシーは、広告が提示されることになる環境が元のデータ要求内の属性と整合するかどうかに基づいて、その広告がユーザに提示されること、またはそれを防止することを可能にし得る。いくつかの実装形態では、暗号学的ハッシュが整合しない場合、レンダリングポリシーは、プレースホルダがレンダリングされるべきであることを示し得る。

【0052】

チャレンジ妥当性確認システムが旅行のコンテキストで実装される場合、応答データは、クライアントデバイスのユーザを元のデータ要求内に示された始点から終点まで車で運ぶために利用可能な運転手情報を含むデジタル成分であってよい。いくつかの実装形態では、妥当性確認チャレンジが正確に回答されるとき、クライアントデバイスは、車両の運転手に連絡すること、または車両の進展に関する更新を得ることが可能にされ得る。

【0053】

いくつかの実装形態では、妥当性確認チャレンジシステムは、1つまたは複数のアプリケーションプログラミングインターフェース(API)を使用して実装され得る。クライアントデバイスとサーバの両方の上にインストールされ得るAPIが構築され得る。追加または代替として、1つがサーバ用に、もう1つがクライアントデバイス用に、2つのAPIが構築され得る。クライアントデバイス上の妥当性確認チャレンジシステムは、サーバ側のAPIにデータ要求を提出するためのプログラミングを含み得る。加えて、中間サーバがデータ要求をサーバに提出するための実行コードが作成され得る。サーバがデータ要求を受信し、妥当性確認チャレンジを生成し、妥当性確認チャレンジをクライアントデバイスに送信するための第2のAPIが作成され得る。このAPIは、いくつかの実装形態では、要求APIと組み合わされてよい。

【0054】

本明細書で説明した主題および動作の実施形態は、デジタル電子回路で、または本明細書で開示した構造およびそれらの構造的均等物を含めて、コンピュータソフトウェア、コンピュータファームウェア、もしくはコンピュータハードウェアで、あるいはそれらのうちの1つまたは複数の組合せで、実装され得る。本明細書で説明した主題の実施形態は、データ処理装置によって実行するために、またはその動作を制御するために、コンピュータ記憶媒体上で符号化された、1つまたは複数のコンピュータプログラム、すなわち、コンピュータプログラム命令の1つまたは複数のモジュールとして実装され得る。代替として、または加えて、プログラム命令は、データ処理装置によって実行するために好適な受信機装置に送信するための情報を符号化するために生成される、人工的に生成された伝搬信号、たとえば、機械生成された電子信号、光信号、または電磁信号の上で符号化され得る。コンピュータ記憶媒体は、コンピュータ可読記憶デバイス、コンピュータ可読記憶基盤、ランダムアクセスメモリアレイもしくはランダムアクセスメモリデバイスまたはシリアルアクセスメモリアレイもしくはシリアルアクセスメモリデバイス、あるいはそれらのうちの1つまたは複数の組合せであってよいか、またはその中に含まれてよい。その上、コンピュータ記憶媒体は伝搬信号でないが、コンピュータ記憶媒体は、人工的に生成された伝搬信号内に符号化されたコンピュータプログラム命令の発信元または宛先であってよい。コンピュータ記憶媒体はまた、1つまたは複数の別個の物理的な構成要素または媒体(たとえば、複数のCD、ディスク、または他の記憶デバイス)であってよいか、またはその中に含まれてよい。

【0055】

本明細書で説明した動作は、1つまたは複数のコンピュータ可読記憶デバイス上に記憶された、または他の発信元から受信されたデータに対してデータ処理装置によって実行される動作として実装され得る。

【0056】

「データ処理装置」という用語は、例として、1つのプログラマブルプロセッサ、1つのコンピュータ、1つのシステムオンチップ、もしくは複数のプログラマブルプロセッサ、複数のコンピュータ、複数のシステムオンチップ、または前述の組合せを含めて、データを処理するためのすべての種類の装置、デバイス、および機械を包含する。装置は、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)を含み得る。装置はまた、ハードウェアに加えて、当該コンピュータプログラムに対する実行環境を作成するコード、たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォーム実行環境、仮想機械、またはそれらのうちの1つまたは複数の組合せを構成するコードを含み得る。装置および実行環境は、ウェブサービス、分散型コンピューティングインフラストラクチャ、およびグリッドコンピューティングインフラストラクチャなど、様々な異なるコンピューティングモデルインフラストラクチャを実現し得る。

【0057】

コンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる)は、コンパイル型言語もしくはインタープリタ型言語、宣言型言語もしくは手続き型言語を含めて、任意の形態のプログラミング言語で書き込まれてよく、コンピュータプログラムは、スタンドアロンプログラムとして、またはモジュール、構成要素、サブルーチン、オブジェクト、もしくはコンピューティング環境で使用するのに好適な他のユニットとして、を含めて、任意の形態で展開されてよい。コンピュータプログラムは、ファイルシステム内のファイルに対応し得るが、そうでなくてもよい。プログラムは、他のプログラムまたはデータ(たとえば、マークアップ言語文書内に記憶された1つまたは複数のスクリプト)を保持するファイルの一部分の中に、当該プログラム専用の単一ファイルの中に、または複数の協調ファイル(たとえば、1つまたは複数のモジュール、サブプログラム、またはコードの部分を記憶するファイル)の中に記憶され得る。コンピュータプログラムは、1つのコンピュータ上で、または1つのサイトに位置するか、または複数のサイトにわたって分散され、通信ネットワークによって相互接続された、複数のコンピュータ上で実行されるように展開され得る。

【0058】

本明細書で説明したプロセスおよび論理の流れは、入力データに対して動作し、出力を生成することによって活動を実行するために1つまたは複数のコンピュータプログラムを実行する、1つまたは複数のプログラマブルプロセッサによって実行され得る。プロセスおよび論理の流れは、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)によって実行されてもよく、装置はそれらとして実装されてもよい。

【0059】

コンピュータプログラムの実行に好適なプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方、および任意の種類のデジタルコンピュータの任意の1つまたは複数のプロセッサを含む。概して、プロセッサは、読取り専用メモリもしくはランダムアクセスメモリまたはその両方から命令およびデータを受信することになる。コンピュータの必須要素は、命令に従って活動を実行するためのプロセッサ、および命令およびデータを記憶するための1つまたは複数のメモリデバイスである。概して、コンピュータはまた、データを記憶するための1つまたは複数の大容量記憶デバイス、たとえば、磁気ディスク、光磁気ディスク、または光ディスクを含むことになるか、あるいはそれらからデータを受信するため、もしくはそれらにデータを送信するため、またはその両方のために動作可能に結合されることになる。しかしながら、コンピュータは、そのようなデバイスを有さなくてもよい。その上、コンピュータは、別のデバイス、たとえば、ほんのいくつかを挙げると、モバイル電話、携帯情報端末(PDA)、モバイルオーディオプレーヤもしくはモバイルビデオプレーヤ、ゲームコンソール、全地球測位システム(GPS)受信機、またはポータブル記憶デバイス(たとえば、ユニバーサルシリアルバス(USB)フラッシュドライブ)の中に埋め込まれてよい。コンピュータプログラム命令およびデータの記憶に好適なデバイスは、例として、半導体メモリデバイス、たとえば、EPROM、EEPROM、およびフラッシュメモリデバイス;磁気ディスク、たとえば、内部ハードディスクもしくはリムーバブルディスク;光磁気ディスク;ならびにCD ROMディスクおよびDVD-ROMディスクを含めて、すべての形態の不揮発性メモリ、媒体およびメモリデバイスを含む。プロセッサおよびメモリは、専用論理回路によって補完されてよいか、またはその中に組み込まれてよい。

【0060】

ユーザとの対話を提供するために、本明細書で説明した主題の実施形態は、情報をユーザに表示するためのディスプレイデバイス、たとえば、CRT(陰極線管)モニタまたはLCD(液晶ディスプレイ)モニタ、それによりユーザが入力をコンピュータに提供し得るキーボードおよびポインティングデバイス、たとえば、マウスまたはトラックボールを有する電子デバイス上で実装され得る。ユーザとの対話を提供するために他の種類のデバイスを同様に使用することができ、たとえば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックであってよく、ユーザからの入力は、音響入力、音声入力、または触覚入力を含めて、任意の形態で受信され得る。加えて、コンピュータは、ユーザによって使用されるデバイスに文書を送り、そこから文書を受信することによって、たとえば、ウェブブラウザから受信された要求に応答して、ウェブページをユーザのクライアントデバイス上のウェブブラウザに送ることによって、ユーザと対話することができる。

【0061】

本明細書で説明した主題の実施形態は、たとえば、データサーバなどのバックエンド構成要素を含む、もしくは、たとえば、アプリケーションサーバなどのミドルウェア構成要素を含む、または、フロントエンド構成要素、たとえば、それを通じてユーザが本明細書で説明した主題の実装形態と対話し得るグラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータを含むコンピューティングシステム内で、あるいは1つまたは複数のそのようなバックエンド構成要素、ミドルウェア構成要素、またはフロントエンド構成要素の任意の組合せで実装され得る。システムの構成要素は、任意の形態のまたは任意の媒体のデジタルデータ通信、たとえば、通信ネットワークによって相互接続され得る。通信ネットワークの例には、ローカルエリアネットワーク(「LAN」)および広域ネットワーク(「WAN」)、インターネットワーク(たとえば、インターネット)、ならびにピアツーピアネットワーク(たとえば、アドホックピアツーピアネットワーク)がある。

【0062】

コンピューティングシステムは、クライアントとサーバとを含み得る。クライアントおよびサーバは、概して、互いと遠隔にあり、一般的に、通信ネットワークを通じて対話する。クライアントとサーバの関係は、それぞれのコンピュータ上で実行し、互いに対してクライアント-サーバ関係を有するコンピュータプログラムにより生じる。いくつかの実施形態では、サーバは、(たとえば、クライアントデバイスと対話しているユーザにデータを表示し、そこからユーザ入力を受信するために)データ(たとえば、HTMLページ)をクライアントデバイスに送信する。クライアントデバイスにおいて生成されるデータ(たとえば、ユーザ対話の結果)は、サーバにおいてクライアントデバイスから受信され得る。

【0063】

本明細書は、多くの特定の実装詳細を含むが、これらは、任意の発明のまたは特許請求され得るものの範囲に対する限定と解釈されるべきではなく、むしろ特定の発明の特定の実施形態に固有の特徴の説明と解釈されるべきである。別個の実施形態の文脈で本明細書において説明したいくつかの特徴は、単一の実施形態で組み合わせて実装されてもよい。逆に、単一の実施形態の文脈で説明した様々な特徴は、複数の実施形態の形で別個に、または任意の好適なサブコンビネーションの形で実装されてもよい。その上、特徴は、いくつかの組合せの形で動作するとして上記で説明されることがあり、またそういうものとして当初特許請求されていることがあるが、特許請求される組合せからの1つまたは複数の特徴は、場合によっては、組合せから削除されてよく、特許請求される組合せは、サブコンビネーションまたはサブコンビネーションの変形に関する場合がある。

【0064】

同様に、動作は図面において特定の順序で示されているが、これは、所望の結果を達成するために、そのような動作が示された特定の順序でまたは連続的な順序で実行されるべきであること、またはすべての示した動作が実行されるべきであることを必要とすると理解すべきではない。状況によっては、マルチタスキングおよび並列処理が有利であり得る。その上、上記で説明した実施形態における様々なシステム構成要素の分離は、すべての実施形態においてそのような分離を必要とすると理解すべきではなく、説明したプログラム構成要素およびシステムが、概して、単一のソフトウェア製品内に一緒に統合されてよいか、または複数のソフトウェア製品に梱包されてよいと理解すべきである。

【0065】

これにより、主題の特定の実施形態が説明されてきた。他の実施形態は、続く特許請求の範囲内である。場合によっては、特許請求の範囲において列挙する活動は、異なる順序で実行されてよく、依然として、所望の結果を達成する。加えて、添付の図面に示すプロセスは、所望の結果を達成するために、示される特定の順序または連続的な順序を必ずしも必要としない。いくつかの実装形態では、マルチタスキングおよび並列処理が有利であり得る。

【符号の説明】

【0066】

100 システム
102 クライアントデバイス
104 サーバ
106 アプリケーション
200 プロセス
300 データ構造
302 公開鍵
304 インターネットプロトコル(IP)アドレス
306 ユニフォームリソースロケータ(URL)
308 アプリケーション名
310 フィールド
400 データ構造
402 フィールド
404 フィールド
406 フィールド
408 フィールド
410 フィールド

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】