JP2019505865A - ウェブ追跡サービスを検出するための方法 - Google Patents

Abstract

関連するクライアント識別子を有するクライアントによって行われる閲覧活動の間に、ウェブ追跡サービスを検出するための方法であって、本方法は、ナビゲーションデータに含まれるキーと値のペアを抽出する段階と、上記クライアント識別子と上記キーに含まれる値との間の、１対１の対応関係を検索する段階と、少なくとも事前に決定された数のクライアントの、少なくともクライアントと値の１対１の対応関係が確認されるキーを選択する段階とを備え、上記キーは、関連するサービスを、追跡活動を行うサービスとみなす。

Description

本発明は、ウェブ追跡サービスを検出するための方法に関し、特に、ファーストパーティ追跡サービス及びサードパーティ追跡サービスを検出するための方法に関する。

追跡サービスビジネスは、ユーザに関する情報の収集に基づいている。ユーザは、閲覧しているときに、収集したデータの価値に立脚したビジネスを行う関係者によって、常に追跡されている。追跡サービスは通常、ウェブポータルにリンクしたサテライトサービスである。ユーザがポータルを訪問すると、追跡サービスは、ユーザのブラウザを使って、例えば、閲覧ページのピクセル又は広告バナーといった人為的な情報をダウンロードさせている。

ユーザがＨＴＴＰリクエストを追跡サービス宛てに生成すると、後者は、それ自体のデータベースにこの訪問を、場合によっては、ＨＴＴＰレベル（例えば、ユーザの装置にリンクしたＩＰアドレス、装置及びクライアントの種類など）及びシステムレベル（例えば、ＣＰＵ負荷、用いられるメモリ容量など）において到達可能な全ての情報と共に記録する。

過去数年の間に、これらのウェブ追跡サービスの静かな成長が見られた。ユーザのオンライン活動についての情報を収集することは、インターネットにおいて最も有益な活動の１つである。これを、自社のビジネス全体の基盤にしている会社が数百も存在する。数え切れないほどのウェブ追跡技術が用いられており、数十のビジネスモデルが、ウェブ追跡に基づいて開発されている。この現象はいたるところに見られ、大企業もほとんど知られていない企業も両方とも、ここに参加している。

追跡サービスは、通常、多くのポータルにリンクしているという事実によって、同じユーザが、様々なサイトによって監視され且つ追跡され得る。

追跡サービスは、データを収集すると、例えば、マーケティング用にユーザプロファイルを作成する、若しくは、カスタマイズされた商業広告を作り上げるといった、商業目的にそのデータを用いる、又は、データが解析担当者や広告代理店に売り渡される。

追跡サービスが、ウェブエコノミーにおいてかなり一般的であり、重要な役割を演じているという事実にもかかわらず、ユーザは、こうしたことにも、またユーザがオンライン活動中に残すデータで誰かが利益を得ることができるという事実にも、ほとんど全く気付いていない。

プライバシに関わる影響は重大である。消費者も企業も、自分が知らない間に外部の世界に公開する情報について懸念しており、こうした漏洩を防止する仕組みを求めている。

ウェブ追跡作業の使用によって、性的嗜好や宗教選択から単純な閲覧履歴に至るまで、ユーザや会社が非公開にしておきたい情報の漏洩が引き起こされる。多くの調査によって、消費者や企業が、ウェブトラッカーに公開する情報を管理したいと考えていることが示されている。政府機関や政策立案者が対策を講じて介入し、ウェブ追跡について消費者の選択を高める新たな技術的手法を提言している。

その結果、ウェブ追跡に対抗する技術的対策の構築に、多大な努力が継続的に払われている。例えば、大企業が独自の反追跡機能を提案している。ブラウザサービス及び追跡サービスの間のインタラクションを阻止するために、多くのプラグインが導入されている。これまで、研究団体は、問題の大きさを開示し定量化することに注目してきたが、この現象を防止する解決手段は、ほんのわずかしか提案されていない。

ウェブ追跡に対する最初の対策は、追跡サービス及びコンテンツをブラックリストに載せることに基づいている。ウェブ追跡は、ユーザのプライバシにどのように影響を及ぼし得るかについて、多くの懸念を引き起こしているので、ほとんどがブラウザプラグインである多くのトラッカー阻止アプリケーションが利用可能である。これらのアプリケーションは基本的に、追跡サービス向けに生成されたＨＴＴＰリクエストを選別する。これらのアプリケーションは、オフラインで形成されたブラックリストに依存し、ブラウザがウェブトラッカー向けのＨＴＴＰリクエストを生成しないようしている。しかしながら、これらのブラックリストがどのように生成されるかを知ることは不可能であり、時間が経過してもブラックリストを維持するのは困難である。

別の手法では、クッキーがどのように、どのサービスから操作されているかを解析する、ブラウザのプラグインがこれらの操作を終了する。つまり、この手法では、ユーザ識別子を含むクッキー及びＡｄｏｂｅ Ｆｌａｓｈプラグインを処理する複数のコードの所有者をトラッカーとして分類する。そのような手法は、ウェブページに含まれるＪａｖａＳｃｒｉｐｔ（登録商標）又はＦｌａｓｈコードの解析に基づいている。

しかしながら、クッキーを阻止するなどの単純な処置は、ウェブ追跡サービスによって容易に回避されてしまう。例えば、一般的な回避法は、ＨＴＴＰリクエストに含まれるＵＲＬクエリにユーザ識別子を埋め込むことである。

別の手法は、グラフ解析技法に基づいている。つまり、ウェブページの構造がグラフとしてモデル化され、機械学習技法が、ウェブページコードの構造を解析し、ユーザ情報の収集が疑われるコードの一部を検出し、こうしてウェブトラッカーを識別するために用いられる。この場合でも、追跡サービスの検出は、ウェブページ自体の解析に基づいている。

これらの方法の最大の欠点は、解析担当者による監視を必要とすることであり、解析担当者は、ウェブページを調査し、事前に定義された分類モデルを用いる。これらのモデルは、固定的であるが、時間の経過と共に変化するはずである。

したがって、何らかの追跡活動を実行するサービスを検出するための方法が必要となる。その方法は、使いやすくなければならず、作業者の支援を必要とせずに、これらのサービスを自動的に検出しなければならない。こうして、ユーザが遭遇するウェブ追跡サービスを阻止するために、どのブラウザでも利用され得る、キュレートされたブラックリストが生成される。

本発明の実施形態は、従来技術の欠点を克服する、追跡サービスを検出するための方法に関する。

１つの実施形態において、関連するクライアント識別子を有するクライアントによって行われる閲覧活動の間に、ウェブ追跡サービスを検出するための本発明の本方法は、ナビゲーションデータに含まれるキーと値のペアを抽出する段階と、上記クライアント識別子と上記キーに含まれる値との間の１対１の対応関係を検索する段階（４）と、少なくとも事前に決定された数のクライアントについて、少なくともクライアントと値の１対１の対応関係が確認されるキーを選択する段階であって、上記キーは、関連するサービスを、追跡活動を行うサービスとみなす、段階とを含む。

別の実施形態において、同じナビゲーションデータの様々な漸進的な用い方の全体にわたって、１対１の対応関係がクライアントごとに確認される。

別の実施形態において、ナビゲーションデータは、ＨＴＴＰ若しくはＨＴＴＰＳのＧＥＴリクエスト、又はＰＯＳＴリクエストを介して送信されるデータ若しくはクッキーに埋め込まれたデータである。別の実施形態において、ファーストパーティ追跡サービスが検出される。別の実施形態において、サードパーティ追跡サービスが検出される。

別の実施形態において、値がクライアントとの１対１の対応関係を表すキーの組み合わせが検出される。

別の実施形態において、事前に決定された数のクライアントは、他の種類の情報を含むキーを誤って分類しないように、且つ必ずしも存在するとは限らなくてよいサードパーティオブジェクトの大きいセットに関連する正真正銘のキーを除外しないように決定される。

本発明の他の特徴、目的、及び利点が、以下の説明から明らかになるであろう。この説明は、単に理解を助けるものであって、限定するものではなく、図を参照して読まれるべきである。

本発明による、追跡サービスを検出するための方法の各段階からなるブロック図である。 あるウェブサイトの異なる訪問におけるユーザに対して検出されたキーの一例である。

検出されたキーの数を、これらのキーが同じとなるユーザの数の関数として示すグラフである。

異なるサービスで用いられるユーザ識別キーの間のインタラクションに関する第１の例のブロック図である。 ユーザ識別キーの間のインタラクションに関するさらなる例のブロック図である。

簡潔に言うと、本発明は、アプリケーションレベルのトラフィックログを活用して、何らかの追跡活動を実行するサービスを自動的に検出し、その結果、キュレートされたブラックリストの生成を可能にする、教師なし方法に関する。本方法は、ＨＴＴＰ（又はＨＴＴＰＳ）トランザクションにおいて、ＵＲＬクエリ内に公開されたクライアント識別子を含む複数の情報を特定するアルゴリズムに立脚している。したがって、その解析は受動的であり、ＨＴＴＰ（又はＨＴＴＰＳ）トランザクションログの可用性を必要とするだけである。これに加えて、本発明の本方法は、追跡サービスによって利用されるクライアント識別子を含むフィールド又はキーのセットをあらかじめ知っている必要がないので、教師なしである。この分類の結果は、追跡サービスに向かうトラフィックを阻止するのに用いられ得るので、ユーザのプライバシが保護される。

本発明の本方法は、ファーストパーティサービス及びサードパーティサービスを両方とも検出するのに適している。以下の説明では、ＨＴＴＰトランザクションにおいてＵＲＬクエリ内に示されるクライアント識別子又はキーを参照するが、本発明の本方法は、ＨＴＴＰＳ ＧＥＴリクエスト、又はＰＯＳＴリクエストを介して送信されるか、若しくはクッキーに埋め込まれている、情報若しくはデータにも適用される。

本発明の本方法は、アプリケーションレベルのトラフィックログ、すなわち、ＨＴＴＰトランザクションのヘッダに含まれる情報を報告するトラフィックトレースの可用性に立脚している。この種類のログは、ブラウジングボット若しくはクローラによって自動的に生成されてよく、又は、クラウドソーシングによるシステムのユーザによって共有されてもよい。ブラウザがＵＲＬクエリ内に公開する、ユーザごとの一意の識別子に追跡サービスが依存することを考慮して、本発明の本方法は、ＨＴＴＰリクエストヘッダ内のＵＲＬを解析し、リクエストを生成するクライアントプロファイルとの１対１のマッピングを表す複数の情報を探す。これらの情報は、クッキー、指紋などに含まれる識別子である。

図１は、本発明による、追跡サービスを検出するための方法の各段階からなるブロック図を示す。

事前に決定されたクライアントのセット（クローラ又はユーザのブラウザ）によって生成されるＨＴＴＰトランザクションを集約するログの集合ＨＳ、及び対象のウェブサイトドメインＷが与えられると、本方法は段階２から始まり、Ｗを対象とする又はＷを参照する、すなわち、通信の「ホスト」フィールドにＷを有する各ＨＴＴＰリクエストに含まれる全てのＨＴＴＰのキーと値のペアを抽出する。Ｗが、通信の「リファラ（Ｒｅｆｅｒｅｒ）」フィールドに含まれるＷと同じ場合、又は、「リファラ」フィールドが空である場合、Ｗはファーストパーティサービスである。それとは違って、「ホスト」フィールドのＷドメインが、「リファラ」フィールドに示されるドメインと異なる場合、Ｗはサードパーティサービスである。

本明細書では、「クライアント」に言及する場合、単一のユーザではなく、単一の装置（ＰＣ、スマートフォン、タブレットなど）を意味する。

例えば、ｈｔｔｐ：／／ｗｗｗ．Ｗ．ｃｏｍ／ｑｕｅｒｙ？ｋｅｙ１＝Ｘ＆ｋｅｙ２＝Ｙで考えると、段階２で、キー１及びキー２が、それぞれ値Ｘ及びＹと共に抽出される。

次に段階４で、リクエストを生成するクライアントの本質的に既知の識別子（例えば、ブラウザプロファイル）と、キーに含まれる値との間の１対１対応が、キーごとに調査される。本方法は、値がクライアントに一意に関連付けられている、すなわち、ｉ）異なるクライアントごとに異なるが、ｉｉ）同じクライアントに対しては同じである、あらゆるキーを探す。

最後に、段階６で、少なくとも事前に決定された数のクライアント（ｍｉｎＣｌｉｅｎｔ、下記を参照のこと）について、少なくともクライアントと値の１対１対応（１対１の対応関係）が確認されるキーが選択される。上記キーは、追跡活動を行うサービス（関連サービス）を識別する。

図２は、キーの一例、すなわち、キー１、キー２、及びキー３を示す。キー１に注目すると、キー１は、異なるクライアント、すなわち、クライアント_１、クライアント_２、…、クライアント_ｎに対して異なる値を取るが、これらの値は、異なる訪問、訪問‐１、訪問‐２、及び訪問‐３の全てにわたって等しくはなく、これにより、キー１は適切なセッション識別子になる。キー２は、異なるクライアント及び異なる訪問の全体にわたって、同じ値を維持している。キー３は、その値が、異なるクライアントごとに異なるが、異なる漸進的な訪問の全体にわたって変化しない唯一のキーなので、本発明の本方法がクライアント追跡として選択するキーは、キー３である。

代替の実施形態として、ＨＴＴＰ ＧＥＴリクエストのＵＲＬクエリに埋め込まれたクライアント追跡キーに注目する代わりに、クライアントがＰＯＳＴリクエストを介してサーバへ送信するデータ、又はクッキーに埋め込まれているデータを処理することが可能である。

同様に、単一のクライアント識別キー、すなわち、リクエストを生成するクライアントとの１対１のマッピングをキーの値だけで示すキーを検出することに注目する代わりに、クライアントとの１対１対応をキーの値が表すキーの組み合わせを検出することが可能である。キーの組み合わせの使用は、ＰＯＳＴリクエストのクッキーを考慮した場合、特に適している。

以下の説明の部分において、本発明の本方法に与えるパラメータ選択の影響が開示されることになる。ｍｉｎＣｌｉｅｎｔとは、本方法が、キーをクライアント識別子として分類するために確認しなければならない、一意となるクライアントと値のペアの最小数である。特に、本方法が分類する返されたキーの数が、ｍｉｎＣｌｉｅｎｔが増えた場合に、どのように変わるかを確認することが重要である。

１つの可能性は、ｍｉｎＣｌｉｅｎｔを大きく設定することである。なぜならば、設定が小さすぎる場合、例えばセッション識別子などの、他の種類の情報を代わりに含み得るキーを誤って分類することが予想されるからである。換言すれば、ｍｉｎＣｌｉｅｎｔが小さいと、誤検出の数が増えることがある。

その一方で、ｍｉｎＣｌｉｅｎｔが大きすぎると、ポータルと関連する正しい検出（ｌｅｇｉｔ ｐｏｓｉｔｉｖｅ）を除外する可能性がある。ポータルは、必ずしも存在するとは限らなくてよいサードパーティオブジェクトの大きいセットを埋め込んでいる。例えば、ユーザによっては、新たなポータルがサードパーティ広告ａｄ_ｉを埋め込む瞬間に、所与のクライアント識別キーｋ_ｉを用いて、その新たなポータルにアクセスすることがあるが、同じポータルにアクセスする他のクライアントは、別の広告サービスａｄ_ｊに遭遇することがあり、したがって異なるキーｋ_ｊを用いる。この場合、クライアントの総数は、２等分に分割され、ｍｉｎＣｌｉｅｎｔが大きすぎると、２等分された両方が、真の検出のセットから除外される。

正しい真の検出を除外することなく、妥当な確度を保証する、ｍｉｎＣｌｉｅｎｔのトレードオフ値を評価する実験が行われている。

図３は、データセットの全てのリクエストＨＳを処理するために異なるｍｉｎＣｌｉｅｎｔ値が設定された場合に、本発明の本方法が識別するクライアント識別キーの数を報告する。

本方法が、サードパーティサービスだけへのＨＴＴＰリクエストのセット、すなわち、ウェブサイトに埋め込まれたサービスであって、そのＨＴＴＰリクエストがホストフィールド及びリファラフィールドに含まれるホスト名の間のミスマッチを示すサービス（第１の曲線５６）を処理する場合と、データセットの全てのリクエスト（すなわち、ファーストパーティ及びサードパーティの両方を考慮）（第２の曲線５２）を処理する場合の両方が検討されている。予想されるように、ｍｉｎＣｌｉｅｎｔが小さくなると、キーの数が増える。

ｍｉｎＣｌｉｅｎｔが増えると、キーの数が減り続けることが確認され得る。サードパーティの場合、ｍｉｎＣｌｉｅｎｔが１４に等しくなると、クライアント追跡と分類されるキーの数は２１０に減少し、ファーストパーティ及びサードパーティの両方を考慮すると、３２８に減少する。

同じウェブサイトに関連するサードパーティウェブサービスのプールが、異なる訪問間で実際に変化することが確認されている。したがって、反証として、第２の実験が実行された。最初に、事前に決定された数のクライアント、例えば１４のクライアントのそれぞれによって訪問が行われるサービスのセットが選択された。これにより得られるサービスのサブセットが与えられると、これらのサービスを示すリクエストだけを保持するために、最初のＨＳ集合が選別され、その結果、より小さいデータセットＨＳｃｌｉｅｎｔｓ_{＿ｓｍａｌｌ}が取得される。次に、データセットＨＳｃｌｉｅｎｔｓ_{＿ｓｍａｌｌ}は、様々なｍｉｎＣｌｉｅｎｔが段階２〜６を再度行うために用いられた。

ｍｉｎＣｌｉｅｎｔが６以上になると、キーの数は３２８で安定し、ｍｉｎＣｌｉｅｎｔが６未満の値では、いくつかの誤検出（ＨＳｃｌｉｅｎｔｓ_{＿ｓｍａｌｌ}のサービスに関連するが、大部分はセッション識別子を保持するキー）が見られることが確認されている。影響は、極めて小さいが存在する。

ｍｉｎＣｌｉｅｎｔを６に設定すると、本方法は、クライアント識別としてキーを正しく分類することができるが、その一方で、何らかのユーザ追跡機能を実際に実装する極端に活動的なウェブサービスは、除外されない。

図３に示される結果は、ファーストパーティ及びサードパーティが両方とも、クライアントを追跡するためにキーを利用することを示しており、したがって、ユーザはそれらのクライアントの背後に隠れている。実際に、ｍｉｎＣｌｉｅｎｔが６に等しくなると、１３０を超えるキーが、１２１の異なるファーストパーティサービスによって利用され、３００を超えるクライアント識別キーが、サードパーティサービスに関連していることが確認されている。

本方法は、人為的なデータセット全体にわたって行われており、何らかのクライアント識別キーを用いる１００を超えるサードパーティサービスを含んだ一覧が、確認されている。上位１０のサードパーティトラッカーは、（解析が検討されている２００のうち）２０又はそれを超えるファーストパーティに関連していると思われ、サードパーティトラッカーの大部分は、非常に限定された数のファーストパーティサービスを扱っていることが確認されている。４０を超えるトラッカーが、１つのサービスだけを扱っている。

以下において、本方法によって返されるクライアント識別キー、及びそれらのキーに含まれる値を解析すると明らかになる、いくつかの興味深い結果が示される。より詳細には、多くの場合、同じ値、すなわち、あるクライアントに関連する一意の情報が、異なるサービスによって用いられるクライアント識別キーに含まれていることが確認されている。

これらのインタラクションを表すために、図４のスキーマが利用されている。ｗｗｗ．Ｗ．ｃｏｍは、訪問されたウェブサイトであり、ｔｒａｃｋｅｒ．ＷＡ．ｃｏｍ及びｔｒａｃｋｅｒ．ＷＢ．ｃｏｍは両方とも、本方法によってトラッカーとして分類されるサービスである。キー１及びキー２はそれぞれ、クライアントを識別するために利用する追跡キーであり、Ｘは、データセットから選ばれた、キー１及びキー２の両方に含まれる、クライアント識別子のキー値（例えば、クッキーに含まれるハッシュ）である。意外にも、キー１及びキー２が、ＷＡ及びＷＢによって別々に生成されるにもかかわらず、キー１及びキー２は両方ともｘである。明らかに、これは、両者間の何らかの衝突を示している。

クライアント識別子が、いくつかのサービスにわたって共有される、３つの主なシナリオが確認されている。

最も簡単なシナリオは、図５（ａ）に図示された例に類似している。この場合、同じ企業Ｚが運営するファーストパーティサービス、ｗｗｗ．Ｗ１．ｃｏｍ、ｗｗｗ．Ｗ２．ｃｏｍ、及びｗｗｗ．Ｗ３．ｃｏｍにアクセスするユーザが、異なるキー、キー１、キー２、及びキー３をそれぞれ用いて、同じクライアント識別子の値を交換するサービスｃ１．Ｗ３．ｃｏｍ、ａ４．Ｗ１．ｃｏｍ、及びｃ．Ｗ２．ｃｏｍ（やはり、Ｚが運営する）によって追跡される。同じ企業傘下Ｚのサービスの間で共有されるクライアント識別子であるということは、同じ組織体が運営する追跡プラットフォームを示唆している。この場合は、プライバシの観点から議論を呼ぶことはないと思われる。

第２のインタラクション例は、図４のスキーマ例に非常に類似しているが、簡潔に表されてはいない。この場合、ファーストパーティサービスｗｗｗ．Ｙ．ｃｏｍにアクセスするクライアントが、サードパーティサービスｓ及びｔによって利用され且つキーｔ１に含まれる識別子を割り当てられる。

図５（ａ）に図示されたシナリオに関して、大きな違いが２つある。１つ目の違いは、同じクライアント識別子が、同じ所有者に属していない２つの異なるサードパーティサービスｓ及びｔの間で共有されていることである。２つ目の違いは、サードパーティサービスｓは、よく知られた追跡会社であり得るｔが提供するキーを利用することである。この種類のインタラクションは、２つの別々のパーティが、それぞれのユーザの識別子を同期することを可能にする作業（クッキーマッチング）の典型的な結果である。

例えば、通常、クライアントが、閲覧活動中に遭遇するいくつかのパーティからクッキーを割り当てられる。したがって、通常、２つのトラッカーが、独自の異なるクッキーを同じクライアントに割り当てる。クッキーマッチング手法のおかげで、２つのトラッカーの一方又は両方が、互いに対してマッピングされたこれらのクッキーを有することになる。クッキーマッチングは、リアルタイム入札（ＲＴＢ）手法の基本的な部分を構成し、これは、リアルタイムの自動オークションを実現する一般的なウェブ広告技法である。

通常、ＲＴＢを可能にするウェブサイトは、ＲＴＢ用語では売り手と呼ばれ、そのウェブサイトのページ上で利用可能な広告スペースを最高値で売ることを目的としている。オークションを可能とするために、他に２種類のサードパーティが関与する。つまり、オークションを取り仕切る競売業者、及び広告スペースを求めて入札を行う買い手である。ユーザが売り手のウェブサイトを訪問すると、競売業者サービスが、クッキーに含まれる識別子を異なる買い手から収集し、クッキーマッチング作業を実行する。クライアント識別子がオークション参加者の間で同期されると、競売業者は、買い手の入札を収集し、落札した買い手を選択する。したがって、後者は、広告スペースを埋めるコンテンツを提供する権限を与えられることになる。

インタラクションの最後の例が、図５（ｂ）に図示されている。このシナリオは、クッキーマッチングとＲＴＢとを組み合わせる作業を示唆している。同じクライアント識別子（ｍ．ｎｅｔ及びｒ．ｃｏｍ）が、２つの売り手であるｗｗｗ．ｆ．ｃｏｍ及びｗｗｗ．ｇ．ｃｏｍ（これらは同じ所有者によって管理されている）、競売業者、並びに５つの異なる買い手の間で共有されていることが確認されている。ＲＴＢ及びクッキーマッチングは、広告業界によって賞賛されているが、これらを実現することで、クライアント識別子が、共通の権限で管理されていない別の参加者によって扱われるというシナリオにつながる。ユーザのデータへの、この関係者を横断したアクセスは、信じられないと思われ、ユーザのプライバシに与える影響について、少なからぬ懸念を引き起こすことが考えられる。

要約すると、本発明は、ＨＴＴＰリクエスト内のＵＲＬクエリを調査し、リクエストを生成するクライアントとの１対１のマッピングを表す複数の情報を探す、今までにない教師なし方法に関する。本方法は、あらゆるクライアント追跡キーを利用するファーストパーティウェブサービス及びサードパーティウェブサービスの一覧を出力する。

本方法は、追跡サービスを自動的に捜し出すのに効果的であり、簡単なので、ウェブ内の追跡サービスを特定するために、研究者、開発者、及び専門家によって利用され得る。さらに、本方法は、ウェブトラッカーによって利用されるユーザ識別子を探すので、他の場面にも適している。

記載された説明は、最良の形態を含む様々な実施形態を開示するために、また、あらゆる装置又はシステムを作成して用いること、及びあらゆる組み込まれた方法を実行することを含めたこれらの実施形態を、当業者が実施することも可能にするために例を用いている。これらの実施形態の特許可能な範囲は、特許請求の範囲によって定められており、当業者が思いつく他の例も含まれ得る。そのような他の例は、特許請求の範囲の文字通りの言葉と変わらない構造要素を有するならば、又は、特許請求の範囲の文字通りの言葉とごくわずかな違いしかない均等な構造要素を含むならば、特許請求の範囲内にあることが意図されている。

Claims (7)

1. 関連するクライアント識別子を有するクライアントによって行われる閲覧活動の間に、ウェブ追跡サービスを検出するための方法であって、前記方法は、
   ナビゲーションデータに含まれるキーと値のペアを抽出する段階と、
   前記クライアント識別子と前記キーに含まれる前記値との間の、１対１の対応関係を検索する段階と、
   少なくとも事前に決定された数のクライアントの、少なくともクライアントと値の１対１の対応関係が確認される前記キーを選択する段階と
   を備え、
   前記キーは、関連するサービスを、追跡活動を行うサービスとみなす、方法。
2. 同じ前記ナビゲーションデータの様々な漸進的な用い方の全体にわたって、前記１対１の対応関係がクライアントごとに確認される、請求項１に記載の方法。
3. 前記ナビゲーションデータは、ＨＴＴＰ若しくはＨＴＴＰＳのＧＥＴリクエスト、又はＰＯＳＴリクエストを介して送信されるデータ若しくはクッキーに埋め込まれたデータである、請求項１又は２に記載の方法。
4. ファーストパーティ追跡サービスが検出される、請求項１又は２に記載の方法。
5. サードパーティ追跡サービスが検出される、請求項１又は２に記載の方法。
6. 値がクライアントとの１対１の対応関係を表すキーの組み合わせが検出される、請求項１から５のいずれか一項に記載の方法。
7. 前記事前に決定された数のクライアントは、他の種類の情報を含むキーを誤って分類しないように、且つ必ずしも存在するとは限らなくてよいサードパーティオブジェクトの大きいセットに関連する正真正銘のキーを除外しないように決定される、請求項１から６のいずれか一項に記載の方法。

Images