JP5088968B2 - コンテンツ配信ネットワークにおけるデータ収集方法及びシステム - Google Patents

Description

本願は２００６年８月１８日付け出願第６０／８３８，６１０号および２００６年８月１８日付け出願第６０／８３８，７３５号に基づく優先権を主張するものである。

本発明は広義には分散ネットワークにおけるデータ収集に係わる。

公知技術の簡単な説明

分散コンピュータシステムは公知である。このような分散コンピュータの１例として、サービス・プロバイダーによって運用管理される「コンテンツ配信ネットワーク」または「ＣＤＮ」がある。サービス・プロバイダーは第三者に代わってサービスを提供する。このような「分散システム]とは、種々のサービス、例えば、コンテンツの配信またはアウトソースされているサイトのインフラストラクチャーの支援などを容易にするためのソフトウェア、システム、プロトコルおよび技術をも含めて、１つまたは２つ以上のネットワークによってリンクされた自立コンピュータ群を意味する。典型的には、「コンテンツ配信」はコンテンツの蓄積、キャッシングまたは伝送、媒体のストリーミングおよびコンテンツ・プロバイダーのためのアプリケーション、例えば、ＤＮＳリクエスト処理、プロビジョニング、データ・モニターおよびリポーティング、コンテンツ・ターゲティング、パーソナリゼーション、およびビジネス・インテリジェンスなどの補助的技術をも含む。「アウトソースされたサイトのインフラストラクチャー」とはエンティティが第三者のウェブサイト・インフラストラクチャを全体的または部分的に運用および/管理できるようにする分散システムおよび関連の技術を意味する。

ウェブ・サーバーはＨＴＴＰと呼称されるプロトコルでウェブ・ブラウザーに対してウェブベースのコンテンツを配信する。ＨＴＴＰはステートレス・プロトコルであるから、既知のＨＴＴＰプロトコル・エクステンションによってウェブ・サーバーはリクエストするエンドユーザー・ウェブ・ブラウザーに状態情報を提供することができる。具体的には、ウェブ・サーバーはその回答の中に、状態情報の小ブロック（「クッキー」）を記憶すべきことを指示するとともに、今後のリクエストにその情報のコピーを含めるようクライエントに指示する。このようにすれば、ウェブ・サーバーはこのクライエント・ブラウザーに以前出会ったことがあるかどうかをトラッキングすることができ、このトラッキング情報を利用することによってブラウザー特定プロファイルを構成し、このプロファイルを利用して別の制御機能を、例えば、ブラウザーに配信されるウェブ・ページにどのようなタイプの広告を載せるべきかを示唆することができる。従来の慣行では、ウェブ・サーバーは自らのドメイン内でだけ通用するクッキーを設定することによってクッキーが発信されたのと同じウェブ・ドメインだけに返送されるようにしている。このような慣行と並行して、クッキーを多様なコンテンツ・ドメインに跨って共有することによって、ウェブ・ブラウザーを利用する個人のコンテンツの好みや関心を識別できるようにする努力がなされている。例えば、米国特許第６，０７３，２４１号においては、１組の協働するサーバーが共用のデータベースを介してクッキー情報を共有する。米国特許出願第２００２０００７３１７号の場合には、１つまたは２つ以上のクッキーにクライエント状態情報を組み込み、このクッキーが仮想のショッピングモール環境における互いに連携の無いドメインによって共有される。サーバーどうしが協働するのではなく、中間的なアプリケーションを利用することによってクライエントからのリクエストおよび回答に状態情報を付加する。

ある広告会社が広告を掲示しているサイトになじみの無いウェブ・ブラウザーがアクセスした場合、これを反映するクッキー・データを広告会社が収集し、相関させることができることも公知である。広告会社はこのデータを利用することによってエンドユーザーのプロファイルを形成することができる。

本発明は、分割できないものとして識別可能なウェブ・クライエント（「ユーザーエージェント」と呼ぶ）がコンテンツ配信ネットワーク（ＣＤＮ）のサービス・プロバイダーによって管理されている種々のドメインに亘ってＣＤＮと相互作用するとき、これらのユーザーエージェント特定の情報が得るためにＣＤＮのサービス・プロバイダーがこのコンテンツ配信ネットワークをどのように拡充する方法に係るものである。１つの実施態様として、一組のマシーン、プロセス、プログラム、およびデータがデータシステムを構成する。このシステムは好ましくはクッキーを介してユーザーエージェントをトラッキングするが、１つまたは２つ以上の受動的な技術を利用することもある。典型的な実施態様において、ユーザーエージェントはクッキー蓄積機能を有するクッキー機能付きデバイスである。ユーザーエージェントが種々のサイトに亘ってナビゲートすると、ユーザーエージェ
ントを相関させるためシステムによって利用されるＣＤＮ専用の固有の識別子（マスターＩＤ）が形成される。このユニークな識別子は暗号化されたクッキーとして記憶されることが好ましい。マスターＩＤは常に１つのユーザーエージェント（従って、１つのクッキー機能付きデバイスの蓄積手段）を表わすが、これは一人の「ユーザー」を意味するものではなく、ユーザーエージェントが一人の人物と結びつくとは限らない。システムはＣＤＮのサービスを受けるカスタマーサイト上のユーザーエージェントの挙動をトラッキングし、これらの挙動を識別可能な「セグメント」に分類する。「挙動」は（マスターＩＤのよって識別される)ユーザーエージェントがサイト上で発生させる事象である。典型的には、挙動はユーザーエージェントによるリクエストと関連する。「セグメント」はユーザーエージェントの挙動を計算によって分類したものであり、多くの場合１つまたは２つ以上の挙動を組み込んだアルゴリズムによって形成される。セグメントは１つまたは２つ以上の方法により１つまたは２つ以上の挙動を収集したものである。「ユーザー・プロファイル」は１つまたは２つ以上のセグメントの集合である。

第１の使用例は「パブリッシャー」サービスである。この使用例においては、（ＣＤＮを使用して）１組のドメインまたはプロパティーを利用する所与のＣＤＮカスタマーがこのシステムを利用することによって、これらのドメインを運用するユーザーエージェントに関する情報を得ることができる。カスタマー（またはその他）は他の目的（例えば、広告、動的コンテンツ作成、など）にもこの情報を利用することができる。

第２の使用例は「ボット軽減」サービスである。この使用例においては、取引サイト（例えば、エンドユーザーが限られた在庫しかない品目、即ち、イベント・チケット、ホテル・ルーム、航空機座席などを購入するウェブサイト）を利用する所与のＣＤＮカスタマーはこのシステムを利用することによってサイトにアクセスするユーザーエージェントに関する情報、具体的には、特定のユーザーエージェントが自動化エンティティ（例えば、ソフトウェア・ロボットまたは「ボット」）なのかどうかに関する情報を得ることができる。サイトはこの情報を利用して最も妥当と思われるユーザーエージェント（即ち、人）に最もレベルの高いサービスを提供することができる。このオペレーションはボットの軽減を容易にすると共にその他のサイト不正行為を少なくする。

第３の使用例は「パートナー」サービスである。この使用例においては、ＣＤＮサービス・プロバイダーはデータシステムを利用してＣＤＮを利用する複数のエンティティに代わって連合サービスを提供する。一例として、カスタマーＡがメーカー；カスタマーＢが新品および中古品に関する情報サービスを提供するウェブサイトとする。カスタマーＡおよびＢはビジネス関係にあり（または互いに利益を得る関係にあって）、それぞれのウェ
ブサイトにアクセスしてくるエンドユーザーに関する情報を得ることができる。この使用例において、もしカスタマーＡもカスタマーＢも共にＣＤＮを利用してそれぞれのサイトに配信すれば、データシステムを一方または双方のカスタマーが利用することでデータ共有を容易にし、その範囲を広げることができる。ＣＤＮはデータシステムを利用して両サイトにアクセスするユーザーエージェントの挙動情報を収集できるからである。

さらに他の使用例として「ターゲティング」サービスがある。この使用例では、ＣＤＮサービス・プロバイダーはデータシステムを利用することによって、例えば、ユーザーエージェントのユーザープロファイルを作成し、このプロファイルを広告サービス機関に提供することによって広告のターゲティングを容易にする。

本発明の主な構成要件を以上に説明したが、これらの構成要件は飽くまでも説明のための構成要件である。本発明を以下に述べるように異なる態様で応用するか、または変更を加えることによって、さらに多くの有益な結果が得られる。

本発明の詳細と利点を、添付の図面を参照して以下に説明する。

図１は本発明の主題を実施することができるコンテンツ配信ネットワークを示す。 図２は図１のコンテンツ配信ネットワークのエッジサーバーを示す。 図３はコンテンツ配信ネットワークに使用されるオンライン挙動データ収集アーキテクチャーのハイレベル手順を示す。 図４はオンライン挙動データ収集システムの実施例を示す詳細なブロックダイヤグラムである。 図５はエッジサーバーを起点とする一致演算と関連するプロセスフローを示す。 図６はセグメント演算と関連するプロセスフローを示す。 図７は１組のセグメントを含む代表的なユーザープロファイルを示す。

本発明は図１および２に示すようなコンテンツ配信ネットワークにおいて実施することができる。ＣＤＮに利用できるだけでなく、１つのエンティティが分散型ネットワークを操作し、この分散型ネットワークから第三者コンテンツを分散させるような環境なら如何なる環境においても実施することができる。

代表的な実施態様として、分散型コンピュータシステム１００はＣＤＮとして構成され、インターネット上に「エッジ」サーバーとして分散された１組のマシーン１０２ａ-ｎ有すると想定される。システム中の種々のマシーンの挙動を管理するにはデータ通信管制センター（ＮＯＣＣ）を利用することができる。ウェブサイト１０６のような第三者サイトは分散型コンピュータシステム１００、特に、「エッジ」サーバー１０２ａ-ｎに対してコンテンツ（例えば、ＨＴＭＬ、埋め込みページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロード、など）の配信をオフロードする。多くの場合、コンテンツ・プロバイダーはコンテンツ配信をオフロードする際に、コンテンツ・プロバイダーの所与のドメインまたはサブドメインを、サービス・プロバイダーの正規のドメイン・ネーム・サービスによって管理されているドメインであるかのように（例えば、ＤＮＳＣＮＡＭＥによって）エイリアシングする。そのようなコンテンツを求めるエンドユーザーは分散型コンピュータシステムに差し向けられてコンテンツを確実に且つより効率的に
得ることができる。詳しくは図示しないが、分散型コンピュータシステムはその他のインフラストラクチャーをも含むことがある。例えば、エッジサーバーから使用量などのデータを収集し、１つまたは２つ以上の領域に跨る分散型データを集約し、このデータを他のバックエンド・システム１１０、１１２、１１４および１１６に送ることによってモニタリング、ロギング、警告、請求書作成、管理およびその他の運転機能や運営機能を容易にすることができる収集システム１０８をも含むことがある。分散型ネットワーク・エージェント１１８はネットワークおよびサーバー負荷をモニターして、ＣＤＮの管理下にあるコンテンツ・ドメインに関して権限を有するＤＮＳ質問処理メカニズム１１５に対してネットワーク、データ通信量および負荷データを提供する。分散データ伝送メカニズム１２０を利用することによってエッジサーバーに制御情報（例えば、コンテンツを管理し、負荷平衡化を容易にするためのメタデータなど）を配分することができる。図２に示すように、所与のマシーン２００は１つまたは２つ以上のアプリケーション２０６ａ-ｎを支援する（Ｌｉｎｕｘなどのような）オペレーティングシステム２０４を運用するコモディティ・ハードウェア（例えば、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍプロセッサ）２０２を含む。コンテンツ配信サービスを容易にするため、例えば、所与のマシーンは多くの場合、１組のアプリケーション、例えば、ＨＴＴＰ Ｗｅｂプロキシ２０７、ネームサーバー２０８、ローカル・モニタリング・プロセス２１０、分散データ収集プロセス２１２、などを運用する。Ｗｅｂプロキシ２０７はこれと連携するエッジサーバー・マネジャー・プロセスを含み、コンテンツ配信ネットワークと連携する１つまたは２つ以上の機能を容易にする。

図２に示すようなＣＤＮエッジサーバーは、好ましくは構成システムによりエッジサーバーに分配される構成ファイルを利用して、好ましくはドメイン及びカスタマーを特定して１つまたは２つ以上の拡充コンテンツ配信機能を提供するように構成されている。所与の構成ファイルは好ましくはＸＭＬベースであり、１つまたは２つ以上の斬新なコンテンツ・ハンドリング機能を可能にする１組のハンドリングルールと指示を含む。構成ファイルは分散データ伝送メカニズムを介してＣＤＮエッジサーバーに配信される。米国特許第７，１１１，０５７号明細書はエッジサーバー・コンテンツ制御情報を配信・管理するのに有用なインフラストラクチャーを開示しており、この制御情報およびその他のエッジサーバー制御情報はＣＤＮサービス・プロバイダー自体、または（エクストラネットなどを介して）オリジン・サーバーを運用するコンテンツ・プロバイダー・カスタマーによって提供することができる。エッジサーバー・マネージャ・プロセス（ｇ-ホスト）がコンテンツに対するリクエストを受けると、このリクエストに関連するカスタマーのホストネームと一致するものを求めてインデックスファイルを検索する。もし一致するものがなければ、エッジサーバー・プロセスはリクエストを拒絶する。一致するものがあれば、エッジザーバー・プロセスは構成ファイルからメタデータを読取り、リクエストを如何に扱うかを決定する。このハンドリング・プロセスは米国特許第７，２４０，１００号明細書に記述されている。

本発明では、図３に示すようなオンライン挙動データ収集システムを利用することによって上記ＣＤＮを拡充することができる。図示例では、（図２に示すような)所与のエッ
ジサーバー・マシーンが所与のデータ収集ルーチン３０２を含み、ＣＤＮがエッジサーバーからのクライエント・マシーン・ユーザーエージェント挙動データを受信し、処理し、管理し、記憶する（後述する）クラスタを含むように拡充されるものと想定する。典型的な例としてはコンテンツ配信ネットワーク内に、またはこれと併用される態様を挙げることができるが、これに限定されるものではない。原理的には、クラスタは下記の機能を含む：ユーザー相関モジュール３０４、データ削除モジュール３０６、およびデータ分析モジュール３０８。結果として得られたデータはリポジトリ３１０に記憶される。

上記モジュールについて以下に説明する。

専門用語
本発明の明細書では下記のような専門用語が使用される。
・コンテンツ・ドメイン−コンテンツ・プロバイダーのドメイン。
・コンテンツ・プロバイダー（ＣＰ）−ＣＤＮのカスタマーと想定されるウェブサイト・プロバイダー。
・クロス・ドメイン・サービス−例えば、多様なウェブサイトにオブジェクトを埋め込むことによって、特定ドメインにおけるユーザー毎のクッキーを設定するサービス。例えば、１つのドメインに止まらず、多数の異なるコンテンツ・プロバイダーのウェブ・ページ内に画像を提供する広告主。これらのオブジェクトによって設定されたクッキーは「第三者クッキー」と呼称されることが多い。本願明細書ではクロス-ドメイン・サービスも、（もし存在するとして）ＣＤＮサービス・プロバイダーがクロス-ドメイン・サービスのオブジェクトが埋め込まれているウェブサイトを有するコンテンツ・プロバイダーとの間に有する関係とは無関係に、ＣＤＮカストマーであると想定する。
・コンテンツ・プロバイダー・クッキー−ユーザーエージェントをトラッキングするためコンテンツ・プロバイダーが特定ドメインに設定するクッキー。
・コンテンツ・プロバイダーＩＤ−コンテンツ・プロバイダーがユーザーに割当てる固有のＩＤ、またはＣＰＩＤ。
・マスターＩＤ−システム全体に亘ってユーザーエージェントに割当てられる固有のＩＤ。
・マスター・ドメイン−後述するように、能動的アプローチにおいてユーザーの異なるドメインＩＤを相関させるのに利用されるドメイン。
・ドメインＩＤクッキー−マスターＩＤを含むコンテンツ・ドメインのネームスペースにＣＤＮサービス・プロバイダーが設定するクッキー。
・マスターＩＤクッキー−マスターＩＤを含むマスター・ドメインに設定されるクッキー。
・ユーザーエージェント−分割できないものとして識別可能なウェブ・クライエント。多くの場合、これは特定マシーンのブラウザーに相当する。典型的には、クライエント・マシーンにおいてウェブ・ブラウザーが開かれると、ユーザーエージェントがインスタンス生成される。同じマシーンにおいて異なるブラウザー・タイプ（例えば、ＩＥブラウザーとＦｉｒｅＦｏｘブラウザー）が開かれると、２つのユーザーエージェントが存在する。例えば、ユーザーエージェントは多くの場合クッキー機能付きデータ蓄積手段（即ち、クッキーを存続させることができるデータ蓄積手段）と連携する。ここに使用する語「ユーザーエージェント」はブラウザーまたはブラウザー・プラグ-インに限定する必要は無く；アウト・オブ・ブラウザーのアプリケーション、プロセス、スレッド、またはその他のプログラムであってもよい。後述するように、システムは所与のユーザーエージェントを人間のユーザー（より一般的には「容認可能なユーザー」）と関連有りと特徴付ける能力を有する一方、自動エージェント（例えば、ボット、より一般的には「容認不能なユー
ザー」）と特徴付ける能力を有する。ユーザーエージェントを人であるか、自動エージェントであるかを特徴付ける能力は極めて有益であり、これによって、ＣＤＮサービス・プロバイダーはカスタマーに対して、カスタマー・サイトにおいて何らかのサービスをリクエストしているユーザーエージェントの素性に関する推測を提供することができる。後述するように、多くの場合、この推測は（他のＣＤＮカスタマーと関連するドメインを含めて）他のＣＤＮドメインにおけるこのユーザーエージェントの活動に係わる。推測は確信の程度を表わすユーザー正統性スコア（ＶＵＳ）の形を取ることができる。ＶＵＳは数字、パーセンテージ、コード、またはその他の適当な記号、文字またはその他の表象で表現することができる。典型的な利用例として、ユーザーエージェントがカスタマー・サイトに対してリクエストし；システムがコンテンツ・プロバイダーに対して、ユーザーエージェントが人間のユーザーであるか、自動エージェントであるかについてサービス・プロバイダーの確信の程度を示すＶＵＳを提供し；この推測に応答してカスタマーが所与のアクションを取る。ＶＵＳは２つのカテゴリー（即ち、人間かボットか）だけでなく、クライエント・マシーン・ユーザーエージェントに関するより詳細な推測を提供できるようにＶＵＳ（またはその等価物）と関連する２つ以上の「バケット」をも含むことができる。

ユーザー相関モジュール
好ましくは、本発明は能動的方法と受動的方法のいずれかを使用してサイト（またはドメイン）内で、またはサイト（またはドメイン）間でユーザーエージェントをトラッキングする。これにはユーザー相関モジュール３０４が使用される。

・能動的方法は下記のように行なわれる：
１．コンテンツ・ドメイン中のオブジェクトがリクエストされたら、ユーザーがドメインＩＤクッキーを提示したか否かをチェックする。もし提示したのであれば、このユーザーは既に識別されているから、それ以上のアクションは不要である。もし未提示ならユーザーをマスター・ドメインにリダイレクトしてマスターＩＤを入手する。
２．もしユーザーがマスターＩＤコードを提示しなければ、新しい固有のＩＤを作成し、マスター・ドメインにマスターＩＤクッキーとして設定する。ユーザーがマスターＩＤクッキーを提示すると、ＩＤを復号し、その正当性を検討し、正当性が確認されたら、これを再び暗号化し、ドメインＩＤクッキーとしてコンテンツ・ドメインに設定する。
３．マスターＩＤをドメインのネームスペース内にドメインＩＤクッキーとして設定できるような特定ＵＲＬを有するコンテンツ・ドメインにユーザーをリダイレクトする。

例えば：
１．ユーザーがこのサービスを利用してどのウェブサイトにもアクセスしたことがない、と想定する。ユーザーはそのウェブ・ブラウザーをwww.xyz.com
に対して開く。ブラウザーはhttp://www/xyz.com/foo.gifをリクエストスル際にwww.xyz.comネームプスペースにおけるドメインＩＤクッキーを提示しないから、ブラウザーは、例えば、www.abmr.net/setID?www・xyz.com/foo.gifへリダイレクトされる。
２．ユーザーはマスターＩＤクッキーを提示しないから、マスター・クッキー（例えば、２６）がwww.abmr.netのネームスペースにおけるクッキーとして設定される。
３．次いで、ブラウザーは、foo.gifサービスを提供するとともにwww.xyz.comのネームスペースにおけるドメインＩＤクッキーをも設定するwww.xyz.com/foo.gif?Master ID=26に向かって再びリダイレクトされる。

トラッキングと請求書作成のため、ＣＤＮはドメインＩＤクッキーおよび/またはマスターＩＤクッキーを、好ましくはエッジサーバーによって書き込まれたログ・ラインと一緒に記録する。エッジサーバーのログは以下に述べるようにユーザー相関モジュールによって処理される：

・受動的な方法は下記のように進行する：
１．ドメイン毎のユーザーＩＤクッキーがオブジェクトと一緒に提供されれば、（ログ・ライン中に）エッジサーバーの記録が存在する。
２．ドメイン間共通のユーザーＩＤクッキーがオブジェクトと一緒に提供されれば、（ログ・ライン中に）エッジサーバーの記録が存在する。

ユーザー・クッキーを他のクッキーから分離するには、何らかのオフライン処理を行うことによって、如何なるネーム/バリュー対が特定ドメインに関連する「ユーザーネーム＝ＩＤ」に対応するかを理解する必要がある。ＣＤＮサービス・プロバイダーはユーザー・クッキーをリアルタイムで分離するか、またはすべてのクッキーを記録してから何らかのオフライン処理によってこれらを分離することができる。使用態様から判断して、ドメイン間共通のクッキーがドメイン毎のユーザーＩＤクッキーとして同じユーザーに提供されたと判った場合には、ＣＤＮサービス・プロバイダーはドメイン毎のＩＤクッキーに対応するログ・ラインにドメイン間共通のユーザー・クッキーを記録すればよく、逆の場合も同様である。

この時点において、それぞれのドメイン毎ユーザーＩＤクッキーに関連して、(a)１組の記録されたアクションと共に、この特定ドメインに対するオブジェク提供に付随する(b
)これと連携する１組のドメイン間共通ユーザーＩＤクッキーが存在する。

ＣＤＮ全体に亘るユーザーのアクションを完全に把握するため、サービス・プロバイダーは下記の作業を行なう：
i．２つのリスト：即ち、ドメイン_クッキー（ＤＣ）およびクロス_ドメイン_クッキー（ＣＤＣ）を作成する。先ずＤＣリストに任意のドメイン毎ユーザーＩＤクッキーを播く。
ii．ＤＣリスト中のすべてのクッキーについて、これと関連するすべてのドメイン間共通ユーザーＩＤクッキーをＣＤＣリストに加える。
iii．ＣＤＣリスト中のすべてのクッキーについて、これと関連するすべてのドメイン毎ユーザーＩＤクッキーをＤＣリストに加える。
iv．ＤＣリストにもＣＤＣリストにも変化が現れなくなるまでステップ(ii)および(iii)を繰返す。

クッキーに依存しない受動的識別スキームもある。公知技術としてはＨＴＴＰヘッダー中の情報を符号化するという方法が挙げられる。幾つかの例を以下に説明する。

第１のスキームはＨＴＴＰ１．１仕様に取入れられているようにＥｔａｇ欄においてマスターＩＤを符号化する。この仕様によれば、オブジェクトを提供する際にサーバーがＥｔａｇ値をする記入すると、ＨＴＴＰＧＥＴまたはＨＥＡＤ方法でオブジェクトをリクエストする時、オブジェクトをキャッシュに格納するクライエントはこのＥｔａｇ値を指示する。即ち、１つの受動的識別スキームは下記のように行なわれる。ユーザーが所与のコンテンツ・プロバイダー・ドメイン、例えば、test.comからのオブジェクトを初めてリクエストし、ＣＤＮエッジサーバーにアクセスする、と仮定する。リクエストを処理するエッジサーバーは新しいマスターＩＤを作成する。エッジサーバーはオブジェクトを提供し、ＨＴＴＰ２００ＯＫレスポンスのＥｔａｇ欄にマスターＩＤを記入する。ブラウザーが次回にこのサイトにアクセスする時（アクセスして同じオブジェクトをリクエストする時）、ＧＥＴまたはＨＥＡＤリクエストに際して記入されたＥｔａｇヘッダーによって確認される。

マスターＩＤを日付の形で符号化する方法もある。ユーザーが初めてtest.comからのオブジェクトをリクエストし、ＣＤＮエッジサーバーにアクセスする、と仮定する。エッジサーバーはマスターＩＤを新しいマスターＩＤ、例えば、３０５を作成する。エッジサーバーはマスターＩＤを日付の形で符号化する。例えば、所与の時点からの経過秒数をマスターＩＤとする。Ｕｎｉｘ方式なら、符号化された日付は１Ｊａｎｕａｒｙ１９７０００：０５：０５のような形になる。エッジサーバーがオブジェクトを提供する場合、このように符号化されたマスターＩＤをＨＴＴＰ２００ＯＫレスポンスの日付欄に記入する。ブラウザーが次回にこのサイトにアクセスする（同じオブジェクトをリクエストする）と、ＨＴＴＰＧＥＴまたはＨＥＡＤリクエストに記入されている最新ヘッダーによって確認される。このリクエストにおいて記入されている日付を復号することによってマスターＩＤを得る。

同じくＨＴＴＰ１．１仕様に規定されているようにコンテンツ-ＭＤ５ヘッダーにおいてマスターＩＤを符号化するという実施態様もある。ここでは、初めてのユーザーがｔｅｓｔ．ｃｏｍからのオブジェクトをリクエストし、ＣＤＮエッジサーバーにアクセスする、と想定する。エッジサーバーは新しいマスターＩＤを作成し、識別子をＭＤ５ハッシュとして符号化する（例えば、マスターＩＤに関してＭＤ５ハッシュ値計算を実行する）。次いで、エッジサーバーはＨＴＴＰ２００ＯＫレスポンスのコンテンツ-ＭＤ５欄にマスターＩＤを記入してオブジェクトを提供する。ブラウザーが次回にサイトにアクセスすると（且つ同じオブジェクトをリクエストすると）、ＨＴＴＰＧＥＴまたはＨＥＡＤリクエ
ストに記入されているコンテンツ-ＭＤ５ヘッダーによって確認される。

言うまでもなく、以上は所与のＨＴＴＰヘッダー欄を利用してマスターＩＤまたはその他の情報を伝送し、データ収集を容易にする本発明の方法を説明するための実施例に過ぎない。この技術は所与のＨＴＴＰヘッダーを「オーバロード」する技術であるとも言える。即ち、所与のヘッダー欄に含まれる情報はほかの面で期待されるデータではないからである。マスターＩＤの受け渡しには他の方法（例えば、ＵＲＬに識別子を埋め込む方法）を使用することもできる。

多くの場合、所与のＣＤＮコンテンツ・ドメインにおいて能動的および/または受動的技術が採用される。しかし、プロバイダーまたはＣＤＮカスタマー、またはこの双方によって決められたサイトにおいては能動的な技術も受動的な技術も使用しないことが好ましい。

データ相関および変換
データ分析モジュール３０８はユーザーとＣＤＮとの相関に相当する一連のデータ単位を入力として受ける。それぞれの単位は例えば下記の項目を含む：
○ユーザー・マシーンのインターネット プロトコル（ＩＰ）アドレス
○ユーザーのドメインＩＤ/マスターＩＤ
○（問い合わせ文字列およびＰＯＳＴｅｄ値を含む）リクエストされたＵＲＬ
○リクエストされたオブジェクトに対応するＵＲＬ
○リクエストの日時
○例えば下記データを含む、リクエストと関連するすべてのクッキー：
・コンテンツ・プロバイダーによって設定されたクッキー
・ドメイン毎のユーザーＩＤクッキー
・ドメイン間共通のユーザーＩＤクッキー
○データはすべてリクエストに関連するユーザーに返送される

ユーザーの経時的な行動をシステムが把握できるように、上記のようなデータ単位が一括して提供されることが好ましい。

最初の処理ステップとして、データをデータ削除モジュール３０６に通すことが好ましい。このモジュールは下記データを削除する：
・個人情報（ＰＩＩ）：
○ユーザーの名前
○アドレスおよび電話番号
○クレジットカード情報
○社会保障番号
○その他

モジュールは次いでマスターＩＤに関連するプロファイルを作成および/補充する。ＰＩＩをフィルタリングする代わりに、システムはいきなり非-ＰＩＩを抽出することもできる。

CDNクラスタおよびエッジ・サービス実働化
図４は上記課題の実施態様を示す。システムは２つの主要動作部分、即ち、データ・クラスタ４００およびエッジ・サービス４０２から成る。図には１つのエッジ・サービスを例示している：このサービスがＣＤＮエッジサーバーのすべてまたは大部分に作用することはいうまでもない。（ここに使用する語「エッジ」は特定のＣＤＮ構成または構造を指すものではない）。エッジ・サービスはオンライン挙動データの捕捉に使用され、これが
データ・クラスタ４００に提供され、処理される。一般に、クラスタはエッジサーバー・マシーンのアクセス・ログ・データから情報を得る１群のマシーンである。アクセス・ログ・データを入力として受け、後述するように、いわゆる「一致」および「セグメント」データを出力として形成する。クラスタはまた、コンテンツ配信ネットワーク・サービス・プロバイダー、そのカスタマー、およびそのパートナーがシステムのデータベースを探索し、（例えば、手動または自動で）レポートを作成し、新しいおよび/または緻密なセグメント定義付けを開発するポイントを提供する。詳しくは後述するように、高性能を容易にするため、クラスタを主要な段階：データ取得、データの処理とストレージ、およびデータ検索に分けて組織することが好ましい。データ取得段階はログ・プロセッサ/ダウンロード受信データプロセッサ（ＬＰ）４１４において実行される。データ検索段階はフロント・エンド（ＦＥ）４１８において実行される。分析ノードＡＮ４２０は典型的には「オフライン」方式で機能する。ＡＮ４２０はシステムの全体的なデータ・セットの比較的大きいサブセットにおいてオフライン分析を行うためのＳＱＬ-によって機能を可能化されるウェブ・インターフェースを提供する。

データ・クラスタの構成コンポネントの詳細は後述する。

エッジ・サービス
エッジ・サービス２種類の操作、即ち、一致演算とセグメント演算が行なわれることが好ましい。これらのサービスは図４に示す識別およびセグメント・サーバー４０４によって実行される。ＩＳＳが実行するエッジ・マシーン４０６は先に述べたＨＴＴＰウェブ・プロキシ４０８およびこれと連携するサーバー・マネジャー（ｇ-ホスト)プロセス４１０を含む。上記システムを使用したいＣＤＮカスタマーはオリジンサーバー４１２を操作し、サイトに関する一致演算を可能にする。これが完了したら、カスタマーはセグメント演算を可能化することもできる。好ましくは、どちらの操作も上述したエッジサーバー・マネジャー・プロセスに提供されるメタデータを介して設定される。図４に示すように、ＩＳＳサーバー４０４はファイアウォール４２２を介して所与のクラスタ・フロント・エンドＦＥインスタンス４１８と相互作用する。但し、ファイアウォール４２２を介することは必要ではない。

これに限定されるわけではないが、ローカル・ウェブ・サーバーからのリクエストに対応するマルチスレッドＦａｓｔＣＧＩプロセスとして実行されるように構成されたＣプログラムとしてＩＳＳを実行することができる。以下に述べる機能性は２つの別々のプロセス（ＩＳＳとｇ-ホスト）で実行されるが、このＩＳＳ機能性はエッジサーバー・マネジャー・プロセスにネーティブであってもよい。

大ざっぱに言えば、識別およびセグメントの操作は、リクエストされたオブジェクトまたはＨＴＴＰリクエストの特徴（例えば、ＨＴＴＰヘッダーまたはクッキー）を利用して種々のユーザー・リクエストに対応してトリガーされる。一致演算をトリガーするリクエストに対してエッジサーバー・マネジャー・プロセスはＣＤＮＳＰ（ａｂｍｒ．ｎｅｔ）によって制御される第三者ドメインへのリダイレクト（ＨＴＴＰレスポンス・コード３０２）で回答する。これはシステムが標準マスターＩＤ（ＡＫＩＤ）クッキーを設定するドメインである。ａｂｍｒ．ｎｅｔドメインに対するリクエストはその結果として、本来のリクエストされたオブジェクトに対応するオリジナル・カスタマー・ドメインへのリダイレクトとなる。典型的には、このリダイレクトに付け加えるのはａｂｍｒ．ｎｅｔにおけるＡＫＩＤ値を変数/値対（またはペア）問い合わせ文字列としてリクエストに埋め込むことだけである。次いで、エッジサーバー・マネジャー・プロセスはａｂｍｒ．ｎｅｔにおけるＡＫＩＤと同じ値のカスタマー・ドメイン特異クッキーを設定する。ユーザーが１つのリクエストをするだけのセグメント演算は比較的簡単である。この操作においては、リクエストの結果として、エッジサーバー・マネジャー・プロセスはユーザーのセグメン
ト情報をフェッチするため順方向リクエストを発する。このリクエストに対する回答それ自体がリダイレクトであり、これに対してカスタマー・メタデータが構成されて追跡する。リダイレクトは他のエッジサーバー・マネジャー・プロセスがこのリダイレクトからセグメント情報を抽出することができ、このセグメント情報をカスタマー・オリジン・サーバーに対する最終ＨＴＴＰリクエストにおけるヘッダーとして含むことができるように構成されたリクエストであることが好ましい。

一致演算
一致演算を行なうためには、関連ページにおける適当なオブジェクトを選択し、これを「トリガー」および/または「実行」オブジェクトとして利用する。例えば、好適な候補ページは大抵のユーザーが典型的なサイト・アクセスに際して最初にアクセスする「待ち受け」ページである。例えば、有望な候補オブジェクトは呼び込みページの大部分および/または所与の属性を有するページの大部分である。「トリガー」オブジェクトは必要ではないが、エンドユーザー・ブラウザーが如何なるクッキーをも受け付けないような状況に対するガードとして利用される。トリガー・オブジェクトはカスタマー・ドメインに既知のクッキーが存在するかどうかをシステムがチェックすることを可能にする。カスタマーの属性が１つまたは２つ以上のクッキー・セット（セッション・クッキーまたは固定クッキー）を有するなら、トリガー・オブジェクトは不要となることがある。トリガー・オブジェクトを使用する場合、エッジサーバー・マネジャー・プロセスはトリガー・オブジェクトに対するリクエストが既知のクッキー/値対を含んでいるかどうかをチェックする。もし含んでいなければ、マネジャー・プロセスが適正なクッキーを適正な値に設定する。「実行」オブジェクトはサーバー・マネジャー・プロセスに命令してエンドユーザーをａｂｍｒ．ｎｅｔドメインにリダイレクトさせる。典型的には、このリダイレクトが強制されるのは（１）（「トリガー」オブジェクトに対するリクエストに設定されている、またはカスタマー・ドメインに既に設定されている）適正なクッキーを呈した場合と（２）「実行」オブジェクトがリクエストされる場合に限られる。

図５は必要なクッキー（および値）を含む実行オブジェクトに対するリクエストのフローチャートである。ブロックＣＰおよびＡＢＭＲはエッジサーバー・プロセス・マネジャー（ｇ-ホスト）の演算であるが、これらのブロックはそれぞれのドメインを意味する。この演算において、エッジサーバー・マネジャー・プロセスは実際のリダイレクト場所であるＩＳＳマシーン（そのＩＰはＣＤＮがネームを管理するＤＮＳ探索によって求めることができる）に対してリクエストを発する。このＩＳＳマシーンはユーザーをａｂｍｒ．ｎｅｔドメインへ向かわせる。リクエストは最初にリクエストされた文書またはオブジェクトのフィンガープリント、（もし存在するなら）カスタマー・ドメインにおけるユーザーのための識別子、およびカスタマー・ドメインのネームを含む暗号化された問い合わせ文字列を含む。この最後の欄、即ち、カスタマー・ドメインは属性ネームとは異なることがあり、例えば、ＣＤＮは別々に「www.example.com」および「my.example.com」を可能化することがあり、この場合、カスタマー・ドメインはｅｘａｍｐｌｅ．ｃｏｍである。図５から明らかなように、エッジサーバー・マネジャー・プロセスはＩＳＳから回答を受信し、これをエンドユーザーに転送する。

エンドユーザーはＨＴＴＰ３０２からのリダイレクトを受信し、これに従ってこのリクエストをａｂｍｒ．ｎｅｔドメインへ転送する。このリクエストは、もし存在するなら、ユーザーの現在のＡＫＩＤクッキー値を含む。ａｂｍｒ．ｎｅｔドメインのためのサーバー・プロセス（ｇ-ホスト）メタデータはＩＳＳマシーンに対してリクエストを伝送する（再び、ＣＤＮに管理ネームでＤＮＳ導出演繹によってＩＰアドレスを求める）。ＩＳＳマシーンは下記のアクションの１つを行なう：
・ＡＫＩＤをリセットする。もしユーザーがカスタマー識別子を提示すれば、
ＩＳＳはこのユーザーのための（ＣＰＩＤ、ＣＰＤＯＭＡＩＮ）対に関し
てＡＫＩＤを検索する。もしクラスタがこのユーザーのためのＡＫＩＤを
有するなら、ユーザーは
○ＡＫＩＤを持たないか、無効のＡＫＩＤをもっているか、または
○データ・クラスタ中のものよりも新しい有効なＡＫＩＤを持っている。

ＩＳＳはユーザーのＡＫＩＤをデータ・クラスタから検索されたものにリ
セットする。
さもなければ、ＩＳＳは次のケースへ降下する。
・同じＡＫＩＤを再発行する。もしユーザーが有効なＡＫＩＤを提示すると、
ＩＳＳは同じＡＫＩＤを再発行する。さもなければ、ＩＳＳは次のケース
へ降下する。
・新しいＡＫＩＤを作成する。これはデフォルト動作である。

好ましくは、ＩＳＳは「無期限」が期限切れとして、「クッキー設定」ヘッダーを送信してＡＫＩＤクッキーの値を設定する。ＩＳＳはまたＩＳＳが設定したばかりのＡＫＩＤ値と同じ値の特殊な問い合わせ文字列を含むことを除いて最初のユーザー・リクエストと同じであることが好ましいリダイレクト・ロケーションを作成する。ユーザーがこの２度目のリダイレクトに従うと、エッジサーバー・マネジャー・プロセスが一致演算のために構成されたカスタマー・メタデータの最終モードを実行する。このメタデータ・パスが問い合わせ文字列からＡＫＩＤ値を抽出し、この値を有するカスタマーに特異なＡＫＩＤクッキーを設定する。

セグメント演算
セグメント演算を可能にするためには、カスタマーがセグメント情報を要求するオリジン・サーバーに対するリクエストを先ず決定しなければならない。例えば、「ボット被害抑制」を必要とするカスタマーの場合、安全上、先ずクリック-ストリームのチェックをリクエストすることになる。他の目的（例えば、高精度の広告）に挙動データを使用したいカスタマーの場合、リクエストはすべてセグメント情報を必要とする。ほかにセグメント演算を可能にするのに必要な情報を挙げるとすれば、カスタマーおよびＣＤＮサービス・プロバイダーがオリジン・サーバーに対して送信されるすべてのセグメントを含むメッセージ・ダイジェスト・シグネチャの共有の秘密キーとして作用する符号化文字列に同意することだけである。リクエストのフローを図６に示す。

適正なリクエストに答えて、セグメント・メタデータは先ずカスタマーのリクエスト中のＡＫＩＤの存在を先ずチェックする。値が不在、または基本的な有効性試験に不合格なら、エッジサーバー・マネジャー・プロセスがリクエストされたオブジェクトを提供することによってリクエストを完了する。しかし、提示された値が有効なら、メタデータはリクエストから種々の情報片を抽出する。例えば、オリジン・ホスト；このリクエストに対するカストマーのオリジン・サーバー、リクエスト・ホストのホストネーム；オリジナル・リクエストのパス/ファイルネーム、問い合わせ文字列；オリジナル・リクエストの問い合わせ文字列、ＡＫＩＤ；オリジナル・リクエストに提示されたＡＫＩＤの値、およびカストマー・ドメイン；オリジナル・リクエストのカスタマー・ドメインのカスタマー・ドメイン。次いで、エッジサーバー・マネジャー・プロセスはリクエスト中のＨＴＴＰヘッダーに含まれる情報と一緒にａｂｍｒ．ｎｅｔドメインに対してリクエストを送信する。エッジサーバー・マネジャー・プロセスはすべてのリクエストにこのＨＴＴＰヘッダーをそのまま維持し、これは特定のエンドユーザー・リクエストについても同様である。このリクエストのためのキャッシュ・キーはカスタマー・ドメインおよびＡＫＩＤ値を含むことが好ましい。

ａｂｍｒ．ｎｅｔに対するこの「セグメント・フェッチ」リクエストはキャッシュ・ヒ
ットの結果となることがある。キャッシュ・ミスの場合、エッジサーバー・マネジャー・プロセスはＩＳＳマシーンに対してリクエストを発信する。ＩＳＳはＡＫＩＤの値を検索し、ターンアラウンドし、集中データ・クラスタからこのＡＫＩＤのためのセグメント情報をフェッチする。次いで、ＩＳＳは回答を分析して所与のカスタマー・ドメインのためのセグメントだけを供給する。最後に、ＩＳＳはセグメント応答（例えば、「セグメント_１＝値セグメント_２＝値」の形のＵＲＬ-符号化文字列）にサインする。（ａｂｍｒ．ｎｅｔドメインにおける）マネジャー・プロセスのためにＩＳＳが形成する応答は典型的に空白であり、ＨＴＴＰヘッダーはサインされ、設定されたセグメント文字列：（即ち、「セグメント_１％３Ｄ値％２０セグメント_２％３Ｄ値％２０、シグネチャ＞」）およびＨＴＴＰ応答コード（例えば、２００ＯＫ）をふくむ。エッジサーバー・マネジャー・プロセスが（ＩＳＳに対する順方向リクエストまたはキャッシュ・ヒット事象におけるキャッシュから）この応答を受信すると、ａｂｍｒ．ｎｅｔドメインのためのメタデータは一時的リダイレクトに対する応答コードを再書込みする（ＨＴＴＰ応答コード３０２）。リクエスト・ホスト、リクエスト・オブジェクト、およびＩＳＳからの応答からのセグメントヘッダーからのデータを使用してリダイレクト・ロケーションを構築するのにメタデータが利用される。カスタマー・メタデータはこれを受信（３０２）し、リダイレクトを追跡するよう指令される。エッジサーバー・マネジャー・プロセスはホストネーム「ａｂｍｒ．ｎｅｔ」をＤＮＳ導出演繹し、その結果、「ａｂｍｒ．ｎｅｔ」が他のｇ-ホスト・プロセスに変換される。マネジャー・プロセスがリクエストを発信し、これが再びａｂｍｒ．ｎｅｔメタデータによって処理される。オリジナル・リクエストと一緒にａｂｍｒ．ｎｅｔに送信されるＨＴＴＰヘッダー（即ち、セグメント情報をフェッチせよとのリクエスト）をａｂｍｒ．ｎｅｔへのこの第２のリクエストにも利用することができる。このリクエストを処理するように構成されているａｂｍｒ．ｎｅｔメタデータはこれらのヘッダーの内容を利用してオリジナル・リクエストを再構成する。即ち、先ずパス・パラメータ「ＳＥＧ」に割当てられた値を抽出する。この値は特殊なＨＴＴＰリクエスト・ヘッダー（「Ｘ-ＩＳ-Ｓｅｒｖｅｒ-Ｄａｔａ」）の形態を有する。次いで、オリジナル・リクエストを再構成する。最後に、（カスタマー・ドメインからリクエスト・ホストＨＴＴＰリクエスト・ヘッダーに供給されるように）このリクエストがオリジン・サーバーに対して発信される。この時点で、ＨＴＴＰリクエスト・ヘッダーは
「Ｘ-ＩＳ-Ｓｅｒｖｅｒ-Ｄａｔａ：セグメント_１％３Ｄ値％２０セグ
メント_２％３Ｄ値％２０、シグネチャ＞」
を含む。エッジサーバー・マネジャー・プロセスがオリジン・サーバーからの回答をエンドユーザーに提供することでセグメント演算が完結する。

データ・クラスタ
上述したように、クラスタは下記の段階に分類構成することが好ましい：データ取得、データ処理、およびデータ検索。好ましくは各段階を並列処理し、負荷に応じてスケール設定する。それぞれの段階を以下に説明する。

データ取得
クラスタがデータを取得する方法は幾つか考えられる。（ＣＤＮログ配信サービス（ＬＤＳ）４２４によって提供されるアクセス・ログはクラスタの主要なデータ・ソースである。上述したように、アクセス・ログはログ・プロセッサ（ＬＰ）４１４において処理される。ログ配信サービス（ＬＤＳ）はＦＴＰ、ｅ-メールなどのような適当なメカニズムを介してＬＰにログを配信する。ＬＰマシーンにおける第１プロセス（ｉ-ｆｔｐｄ）がこのログ・ファイルを受け、ＬＤＳがそのＥＴＰＰＵＴ演算を完了すると、第１プロセスが完成ファイルをダイレクトリに移し、ＬＰマシーンにおける第２プロセス（ｉ-ｌｐ）がこれを発見する。処理すべきファイルを発見すると、第２プロセスはファイルを開き、必要ならこれを解凍し、解析する。それぞれのログ・ラインを解析しながら、第２プロセスは好ましくは以下に列記する欄を識別する：リクエストされているＵＲＬ、リファラー
、リクエストの日時、ソースＩＰのアドレス、およびリクエストに記入されているなら、ＡＫＩＤとＣＰＩＤクッキーの値。次いで、第２プロセスはこれらの欄を１つまたは２つ以上の「挙動」としてマッピングする。挙動マップはそれぞれのコンテンツ・プロバイダー（ＣＰ）コード毎に正規表現対による（ＵＲＬ、リファラーの）１つまたは２つ以上の挙動を表す挙動マップとして構成されていることが好ましい。識別された挙動毎に、第２プロセスが挙動演算結果をデータベース・ノード（ＤＮ）に伝送して事象の発生を記録することが好ましい。ＣＰＩＤクッキーが記入されていたなら、ＬＰが補足的に一致演算を行なう。これらの演算については、詳しく後述する。挙動演算は事象の挙動名（その「挙動_ｉｄ」）、日時、ＡＫＩＤ、およびソースＩＰアドレスを特定する。一致演算はＡＫＩＤ、ＣＰＩＤ、およびＣＰＤＯＭＡＩＮを特定する。好ましくは第２プロセスが内部キャッシュを有し、これを介してこれらの演算結果をＬＲＵ-に管理されているデータ構造にまとめることが好ましい。このモデルでは、所与のＡＫＩＤ/挙動対に関する複数の演算/事象を１回の演算でまとめ、所与のキャッシュ・エヴィクション・ポリシーに従って演算結果をＤＮへ伝送する。これによってＤＮの負担が著しく軽減され、ＬＰ/ＤＮネットワークの性能条件が緩和される。

好ましくは、システムはダウンロード受信データ処理を介してオンライン・モデルのデータ取得をも支援することが好ましい。具体的には、幾つかのオブジェクトまたはコンテンツ・プロバイダー・コードに関して、ダウンロード受信データをダウンロード受信データプロセッサ（ＤＲＰ）へ伝送するように構成すればよい。リクエストされたＵＲＬ、リファー、アクセス日時、ソースＩＰアドレス、およびＡＫＩＤおよびＣＰＩＤクッキー値が受信データとして提供される。

データの処理およびストレージ
上述したように、システムはプロセス（ｉ-ｄｎ）を利用してマシーンＤＮ４１６において取得データを処理し、記憶する。

拡張を可能にするため、システムはそのデータベースを区分し、それぞれの区分を通し番号で識別することが好ましい。それぞれの通し番号はＤＮに割当てられ、ＤＮには幾つかの通し番号が割当てられることが多い。第３プロセスは２つの主要な表を保持することが好ましい：即ち、挙動データを記録する挙動表と、一致データを記録する一致表である。挙動表は特定の（ＡＫＩＤ、挙動_ｉｄ）に関して経時的な挙動データ（事象データ）を記録する挙動記録に情報を記憶する。挙動データは事象を多数の連続的なインターバルでスロットすることによって圧縮することが好ましい。一致表は（ＣＰＩＤ、ＣＰＤＯＭＡＩＮ）対とＡＫＩＤとの関連を記録する。ユーザーがそのクッキーを削除した場合、この情報を利用してユーザーの同一性を回復する。ここで使用される語「スコア」とは所与のユーザーに関する履歴データに基づく集成値である。所与のセグメントへの主たる入力はユーザーに関する挙動記録である。また、所与のユーザーに関する別のセグメントからのスコアも特定セグメントにおけるこのユーザーのスコアに影響を及ぼす可能性がある。所与のユーザー、および所与のセグメントに関して、システムは最新のスコア、スコアが更新された最後の日時、およびそのスコアの信頼度を記憶することが好ましい。セグメント情報を維持するため、ＤＮプロセスは挙動表や一致表のように区分されたセグメント表を保持する。具体的には、挙動およびセグメント情報をＡＫＩＤのハッシュにおいて通し番号に区分することが好ましい。一致データは（ＣＰＩＤ、ＣＰＤＯＭＡＩＮ）対のハッシュにおいて投資番号に区分される。ＤＮ挙動、一致およびセグメント表は別々のＤＮサービスを構成し、それぞれが独自の通し番号スペースを有することが好ましい。必要なら、それぞれのサービスを独自のＤＮセットで実行することができる。それぞれの表のそれぞれの通し番号は自前のデータベース・イメージに記憶されることが好ましい。

データ処理
ＤＮ４１６は幾つかの主な演算を支援する：即ち、挙動記録更新（「挙動演算」）、一致記録更新（「一致演算」）、セグメント問い合わせ、および一致問い合わせ。もう１つの演算、セグメント記録更新（「せぐめんと演算」）は他の演算とは非同期的に行なうことができる。これらの演算について以下に説明する。

挙動演算の結果を受信すると、ｉ-ｄｎプロセスがこの演算と関連する記録をフェッチし、今まで存在しなかった場合にはこれを作成する。処理後、ｉ-ｄｎプロセスは記録をデータベースへ返送する。次いで、プロセスはライブラリーｉ-ｓｎを呼び出してＡＫＩＤのセグメント・データを更新する。

一致演算の結果を受信すると、ｉ-ｄｎプロセスは演算と関連する記録をフェッチし、それまでに存在しなかった場合には、これを作成する。この記録は関連を記録するだけでありそれ以上の処理は不要である。ＤＮはセグメントの更新とセグメント問い合わせ支援を提供するライブラリーｉ-ｓｎとリンクしている。この演算の結果、ｉ-ｓｎライブラリーの構成ファイルに定められた規則に従って、セグメント表中の所与のＡＫＩＤの関連セグメントが更新される。

一致問い合わせを受信すると、ｉ-ｄｎプロセスはリクエストされた（ＣＰＩＤ、ＣＰＤＯＭＡＩＮ）対の記録をフェッチし、これに対応するＡＫＩＤをクライエントに提供する。セグメント問い合わせを受信すると、プロセスｉ-ｄｎはｉ-ｓｎライブラリーをよびだしてリクエストされたＡＫＩＤに関するセグメント文字列をフェッチし、これをクライエントに提供する。

データ検索
クラスタのフロント・エンド（ＦＥ）４１８はクラスタとのＨＴＴＰインターフェースとして機能する。ＣＤＮはこのインターフェースを利用してクラスタからデータをフェッチする１つまたは２つ以上の外部ネットワークを持つことができる。ＦＥは問い合わせをするクライエントがクラスタ中の何処にデータが収納されているか、即ち、どのＤＮにどんな通し番号が割当てられているかを知るのを防止するとともに、クラスタを厖大な問い合わせ（厖大なネットワーク）の負荷から保護する負荷緩衝手段としても機能する。（後述するような）エッジ・サービスＩＳＳコンポネントからの一致またはセグメント問い合わせを受信すると、ＦＥは問い合わせの情報をどのＤＮが持っているかを判断し、この問い合わせ該当ＤＮに伝え、回答を読取り、回答を暗号化し、暗号化されたデータをＩＳＳクライエントに返送する。

同じく図４に示すように、長期に亘るストレージのためにデータ・ライブラリー（ＤＬ）ノード４２６を設けてあり、収集したデータによるレポート作成を容易にするためにレポート作成ノード４２８が使用される。レポート作成ノードは多くの場合ＡＮと協働する。ＣＤＮカスタマーはこれらのシステムに通常の態様で、例えば、安全通信リンクを介してアクセスする。１つの実施形態では、収集された情報を、エクストラネットを介して、またはウェブ・サービスを介して、またはその他の便利な方法で利用することができる。

ＣＤＮサービスは適当な態様で、例えば、利用回数、ユーザーエージェントＶＵＳ、加入登録、トラッキングされたマスターＩＤ、ページ/オブジェクトの閲覧、ユーザー・プロファイル、セグメントなどに基づいてデータシステム利用料金を設定する。

ここに述べるシステムは幾つかの主要なコンポネントを有する：
（ａ）ＩＤ管理-サイト間でクライエント・マシーン・ユーザー・エージェントをトラッキングし、そのクリックストリームを把握するのに利用される。このコンポネントはカスタマーのドメインにおけるメタデータと、上記のＩＤを作成（またはリセット）するエッジ
・サービス機能性を含む。上記システムはＩＤをユーザーエージェントのクッキー・ストアに存続させるためクッキーに依存するが、これは必ずしも必須条件ではなく、その他の受動的なスキームも利用できる。
（ｂ）データの収集および処理-ログを処理してユーザー・プロファイルを作成する役割を果す。この作業はＣＤＮログ配信サービス（またはその他のソース）から配信されるログのそれぞれのラインを処理することによってリアルタイムまたは近リアルタイムで行なわれ、この処理でＵＲＬパターンを挙動の形にマッピングする。例えば、「．．．ｃｐ．ｃｏｍ/．＊とのラインはそのユーザーエージェントの「ｃｐ_ユーザー」挙動を増分することになる。
（ｃ）オフライン・データ分析-オンライン・システムからのデータをオフラインシステムにあつめ、オフラインシステムにおいてこれを他のユーザーのために処理することができる。１つの使用法としては、ＡＮを介してデータにＳＱＬインターフェースを設ける。他の使用法としては、ＣＤＮカスタマー・ポータルのためにレポートを作成する。
（ｄ）リアルタイム・プロファイル検索-この場合、エッジサーバーはデータ・クラスタからユーザーのプロファイルを検索し、この情報をカスタマー・オリジンに対するリクエストに含める。これはカスタマーが挙動データに対応策をとる方法である。

データシステムは多様なサービスに利用できる。

第１の利用例は「パプリッシャー」サービスである。この利用例では、（ＣＤＮを利用して）一連のドメインまたはプロパティーを運用する所与のＣＤＮカストマーがシステムを利用することによってこれらのドメイン全体に亘って活動するユーザーエージェントに関する情報を入手することができる。このような情報はカスタマー（またはその他）によって（例えば、広告、動的コンテンツなどのような）他の目的に利用することができる。具体例としては、ＣＤＮカスタマーが２つのサイトＡおよびＢを運営し、ＣＤＮサービス・プロバイダーがこれら２つのサイトに亘ってユーザー・エージェント・データをトラッキングする。データを分析することによって、ＣＤＮサービス・プロバイダーはサイトＡのユーザーエージェントの１０％がサイトＢにもアクセスするが、サイトＢのユーザーエージェントの３％だけがサイトＡにアクセスすることを判断することができる。他の例として、システムを利用することによって、特定の顧客が係わるリクエスト数（例えば、ユーザーの３％が１つのサイトに対するすべてのリクエストの１０％に係わる)に関する情報を提供することができる。このように、ＣＤＮカスタマーはユーザーエージェントの層、即ち、これらのサイトにアクセスすると予想される実際のユーザーに関する有用な多くのデータを得ることができる。

第２の使用例は「ボット被害抑制」サービスである。この例では、取引サイト（例えば、エンドユーザーが在庫に限度がある品目、例えば、イベント・チケット、ホテル・ルーム、航空機の座席などを購入するウェブサイト）を運営する所与のＣＤＮカスタマーはシステムを利用することによってサイトにアクセスするユーザー・エージェントに関する情報を得ることができ、特に、特定のユーザー・エージェントが（例えば、ソフトウェア・ロボットまたは「ボット」である可能性がないかどうかの情報を得ることができる。サイトはこの情報を利用することによって最も信頼性の高いユーザー・エージェント（即ち、ロボットではない本物の人間）に最高レベルのサービスを提供することができる。これによってボット被害その他の詐欺的行為を抑制し易くなる。ボット被害抑制の機能性はボットの出没が多い他のタイプのサイト（例えば、フレンド-ベースのソシアルネットワーキング・サイト）にも使用することができる。

第３の使用例は「パートナー」サービスである。この場合、ＣＤＮサービス・プロバイダーはデータシステムを利用することによって、ＣＤＮを利用する２つ以上のエンティティのために連合サービスを提供することができる。例えば、カスタマーＡは一連の製品の
メーカーであって自社製品を説明するウェブサイトを持っており、カスタマーＢはＡが製造するような新製品およびその中古品に関する情報を提供するウェブサイトである。カスタマーＡおよびＢはそれぞれのウェブサイトにアクセスするエンドユーザーに関する情報を共有するというビジネス関係を持つ（またはこのビジネス関係から利益を得る）ことになる。この使用例において、カスタマーＡとカスタマーＢの双方がＣＤＮを利用してそれぞれのサイトに配信すれば、データシステムを双方のカスタマーが利用することになり、互いのデータ共有を容易にし、且つ拡充することができる。なぜなら、ＣＤＮはデータシステムを利用してこれら両サイトにアクセスするユーザー・エージェントの挙動情報を収集することができるからである。他の使用例として、カスタマーＡがソシアルネットワーキング・サイトであり、カスタマーＢがカスタマーＡのサイトにおいてプロモートしたい所与の製品またはサービスを提供する立場にある場合が考えられる。もし両方のカスタマーＡ、Ｂが共にＣＤＮを利用してそれぞれのサイトに配信すれば、カスタマーＡがデータシステムを利用することによって、そのサイトにアクセスする所与のユーザー・エージェントがカスタマーＢのサイトにアクセスしたかどうかを識別することができる。この情報を共有することによって、（例えば、所与の広告を提供、所与の相互プロモーションなどのような）所与の活動が容易になる。

他の使用例として「ターゲッティング」サービスがある。この使用例においては、ＣＤＮサービス・プロバイダーがデータシステムを利用することによって、広告のターゲット設定を容易にする。例えば、ユーザーエージェントのユーザー・プロファイルを作成して
広告サービス機関にこのプロファイルを提供する。システムはセグメント採点ビジネス・ロジックを実行またはインターフェースすることによってそれぞれのＡＫＩＤ毎にそれぞれの「アクティブな」セグメントの関心度採点を行なうことが好ましい。所与のＡＫＩＤに関連する挙動データは下記のようにしてセグメントへマッピングすることができる。ＡＫＩＤと連携するそれぞれの挙動ＩＤは、最も新しい事象に基づく挙動ＩＤである。例えば、これらの事象が発生した時期の中間点における事象数から現時点における事象数を差引くことによってこれらの事象の寿命を判断する。その時期の事象数にその時期の崩壊関数を乗算する。この乗算の結果が問題のＡＫＩＤに関するセグメント/挙動の「強さ」である。広告選択ロジックがセグメントを分類して「強さ」が最も大きいセグメントを見出し、このセグメントから広告を選択する。

他の使用例として、検索エンジンを提供するカスタマーのためにＣＤＮサービス・プロバイダーがシステムを運用する場合がある。カスタマーのインフラストラクチャーは入札メカニズムを含むか、または入札メカニズムと連携し、これによって第三者が在庫リスト（例えば、広告、キーワード、有料テキストなど）に入札することができ、在庫リストはユーザーエージェントの問い合わせに答えてカスタマーの検索エンジンによって返送される。検索エンジンに問い合わせが入来すると、本発明のデータシステムにアクセスし、入札アルゴリズムへの入力としてユーザーエージェントに関してＣＤＮＳＰが持っているデータまたはプロファイルが提供される。カスタマーがデータシステムにアクセスする態様はいろいろである。例えば、データシステムがコンテンツ・プロバイダーのインフラストラクチャーにおいて実行するモジュールを持っているか、または情報が帯域外で受渡しされる。いずれの場合にも、カスタマーの入札メカニズム（またはアルゴリズム）には補足情報が（例えば、ユーザーのプロファイル、ＶＵＳなどのようなデータ）が加えられるから、第三者はより効率的に在庫リストに入札することができる。

出力
１つの実施形態においては、データ収集システムの出力が所与のマスターＩＤと関連する一連のネーム/値対である。このネーム/値は推測を表わす値の形を取る（例えば、男性＝０．９は男性らしいことを意味し、男性＝０．５は全く推測を意味せず、男性＝０．１は女性らしいことを意味する）および/または多くの場合確信の程度を表わすスコアを付した一般的なラベル（例えば、関心＝オリンピック、確信度＝７５％）の形を取る。これらはそれぞれが「セグメント」となり得る。

このように、プロファイルは所与のオントロジーによって定義することが好ましく、所与のデータ・スキーマと一致すればよい。考えられる属性の代表的なリストは下記の通り
である。
・綜合的な関心事（例えば、多様な階層を通しての相対的な関心値）
○スポーツ-ベースボール、フットボール、自動車レース、サッカー、バスケットボール；関連スポーツのプロ/アマ；チーム
○ニュース-国際、国内、地方
○ファイナンス
○エンターテーンメント-映画、特定のタレント
・今買いたいもの
○自動車
○家庭用電気器具
○旅行
・人口学的情報
○年齢
○性別
○収入レベル
○居住場所（例えば、郵便番号の精度）
・インターネット挙動
○１日オンラインに費やす時間
○インターネット購買の程度

典型的なユーザー・プロファイルを図７に示す。但しここに示すデータは飽くまでも１例である。尚、ユーザー・プロファイルはいかなる個人情報（ＰＩＩ）も含まない。

上記インフラストラクチャーは１つまたは２つ以上の改良型構造を含むことができる。即ち、より細部に亘る情報フィルタリングまたは処理が可能となるように機能性を拡張したい場合がある。上述したように、システムはユーザー・クラスタ化または相関機能を備えて複数のデバイスに亘ってユーザーエージェントをトラッキングすることができる。従って、もし所与のコンテンツ・プロバイダーまたは広告機関がユーザーエージェントのＩＤをＣＤＮが提供するファイルに挿入すると、上述したＣＤＮサーバー・プロバイダー構造が情報を処理し、２つの異なるクッキーＩＤ（またはその他の識別子）が実は２つの異なる場所（例えば、家庭と職場）から、またはより一般的には、２つの異なるデバイスから（全部または一部がＣＤＮにオフロードされる）所与のサイトにアクセス中の同一人物または同一エンティティであると判定できる能力を有することが好ましい。システムはサービス・プロバイダーが重複情報をフィルターアウトすることを可能にする適当な機能性（例えば、相関アルゴリズム、クラスタ化アルゴリズムなど）を含む。

ＣＤＮは（その業務の性質上）、全部または一部がＣＤＮにオフロードされているサイトにエンドユーザーがアクセスするたびに収集される厖大なデータにアクセスする。しかし、これらエンドユーザーの多くは固有のＩＰアドレスとは結びつかない。なぜなら、かれらのクライエント・マシーンはファイアウォールの背後に配置されているからである。従って、サービス・プロバイダーに（ａ）所与のリクエスト・データ流れ（企業のファイアウォールの背後からのリクエスト）をモニターさせ、（ｂ）得られたデータに対してクラスタ化アルゴリズムを実行して有用な情報、例えば、幾つの固有ＩＤがデータと結びつくか、または所与のクラスタが所与のユーザー・セットまたはサブセットに対応するか、などの情報を抽出させることによって本発明を発展拡張することができる。代表的なクラ
スタ化アルゴリズムは、例えば、ｋ-平均法、（特徴選択アルゴリズムとしてフォワード・フィッティングまたは相互情報量を利用する）ＳＶＭなどを含む。より一般的には、クラスタ化アルゴリズムは上述した一般的な技術に従って識別された所与のユーザーに関するその他の情報を抽出するのに有用である。

上述したように、本発明のデータ収集技術はマスターＩＤと連携する特定のユーザー・エージェントが自動化されたマシーン、プログラムまたはプロセスではなく人間であるがどうかを特徴付けるのに有用な情報をも提供することができる。例えば、もしマスターＩＤと連携する「エンティティ」が所与の時間をオンラインで費やし、サイトＸ、Ｙ、Ｚにアクセスし、サイトＹで物品を購入した場合、このエンティティは自動化されたプロセス（例えば、コンサート・チケットを所与のウェブサイトから転売する目的で購入するチケット・ボット）でない可能性がある。同様に、もしユーザー・エージェントが「カタログ」ページ（即ち、「購入」ページ）にアクセスした場合、ボットなら読むためにページにアクセスして時間を費やすとは考えられないから、このユーザー・エージェントはヒューマン・ユーザーである可能性が高い。この種のエンティティ弁別（例えば、エンティティがクリック詐欺、「シビル」アタックなどを企てているかどうか、など）を可能にするには、好適なソフトウェア・ルーチンを実行すればよい。１つの実施形態として、１つまたは１組のファクターを評価することによってユーザー・エージェントがチケット・ボットであるかどうかを判断する。これらのファクターは、例えば、クライエント・マシーン・ユーザー・エージェントがアクセスするＣＤＮドメインの多様性、所与のコンテンツ・プロバイダーと連携する１つまたは２つ以上のページに関する購入：カタログ比、最近のブラウジング・セッションからの経過時間量、現在のブラウジング・セッション中におけるクライエント・マシーン・ユーザー・エージェントのオンライン時間量、およびクライエント・マシーン・ユーザー・エージェントが所与の時間に亘って連携したＩＰアドレスの数などである。但し、これらのファクターは代表的なものに過ぎない。多くの場合、複数のサイトまたはドメインに亘ってユーザー・エージェントをモニターし、多数のサイトにまたがって、且つある程度の時間に亘って「真正の」（人間らしい）挙動を判定できることが望ましい。データが多ければ多いほどユーザー・エージェントが真正なユーザーと一致するとの確信を深めることができるのは言うまでもない。

具体的には、幾つものファクターに基づいてシステムはユーザーエージェントが人間のユーザーであるという確信の指標を提供する。この指標は多くの場合、真正ユーザー・スコア（ＶＵＳ）の形を取る。ＶＵＳが高ければ高いほどユーザーエージェントが人間のユーザーである可能性が高い。（ここにいう「高い」は相対的な表現であり、「最低」値が良いスコアを表わす）。１つの実施形態として、ＶＵＳは下記のように算出される。ネットワーク層からアプリケーション層までに一連のデータ・ソースがある（そのうちの１つまたは２つ以上を上述した）。システムは所定の属性を分析することによって正常な人間らしい挙動を示唆する指標を抽出する。何が「正常な人間らしい挙動」はサイトによって異なり、同じサイト内でも領域によって異なる。加重アルゴリズムを利用して１つまたは２つ以上の属性を組み合わせることによって、真正ユーザー・スコア（ＶＵＳ）を形成し、このユーザーエージェントが真正のヒューマン・ユーザーと結びつくというサービス・プロバイダーの確信度を表わす。具体的な加重アルゴリズムはファクター、サイトのタイプ、正常と思われる活動の性質などに応じて異なる。

もしボットであることが判明したら、被害抑制のアクションが取られる。具体的なアクションは極めて多様である。例えば、クライエント・マシーン・ユーザー・エージェントに所与のダミーまたは代替コンテンツを提供し、このクライエント・マシーン・ユーザー・エージェントに対して質の低いサービスを提供し、このクライエント・マシーン・ユーザー・エージェントをＣＤＮにおけるサーバーのサブセットに誘導し、（ＶＵＳスコアによって）ボットであることが特徴つけられた他のクライエント・マシーン・ユーザー・エ
ージェントとの間で資金争いを強制する、などである。クライエント・マシーン・ユーザー・エージェントに対するサービスの質をどの程度低下させるかはＶＵＳ次第である。例えば、ＶＵＳの倍だけ応答時間を調節することが考えられる。これとは逆に、クライエント・マシーン・ユーザー・エージェントと関連する特定のＶＵＳが、システムがヒューマン・ユーザーと関連すると信ずるスコアであれば、このクライエント・マシーン・ユーザー・エージェントは良質のコンテンツを受取り、上質のサービスを提供され、サーバーのうちの高性能セットへ誘導される、などの結果となる。

尚、上記ボット分析機能は所与のユーザー・エージェントのシグネチャがボットであるか否かを判定しようとするのではなく、ユーザー・エージェントが「ヒューマン」ユーザーと関連するか否かの判定に重点が置かれる。真正ユーザーを識別することを目標とするこのアプローチの方がはるかに有利である。なぜなら、ボットの開発者たちは（一旦はボットとして識別された）ボット・シグネチャを容易に変えることができるからである。ここに述べる技術は（真正なヒューマン・ユーザーの視点から見て)正常な態様で所与のサイトと相互作用できるというクレジットをシステムがユーザー・エージェントに与えることを前提としているが、典型的には、ＶＵＳはＣＤＮによって支援されている複数のサイト（またはドメイン）に亘って、恐らくは或る程度の時間に亘ってユーザー・エージェントが「正常な」人間らしい挙動を示すか、またはこのような正常な挙動であると見做されるその他の基準に従って決定される。従って、もしユーザー・エージェントが１つのサイトにおいて「正常」に（即ち、人間らしく）見えても、このユーザー・エージェントが高いＶＵＳにつながるとは断定できず、むしろ、ユーザー・エージェントは複数のサイト/ドメインに亘って、しかもおそらくは或る程度の時間に亘って「正常」に見えねばならない。即ち、ユーザー・エージェントが相互作用するサイト/ドメインが多ければ多いほどシステムはこのユーザー・エージェントがヒューマン・ユーザーと関連するに相違ないとの「確信」を深めることができる。この判定を下す際に、何が「正常な」（人間らしい）挙動であり、何が「正常な」（人間らしい）挙動でないかはサイト/ドメインによって異なり、サイトＡでは一連のアクションが正常であり、サイトＢでは別の一連のアクションが正常であるということもあり得る。

「ボット」被害抑制機能はタイプの異なるサイトに対しても利用できる。例えば、「フレンド-ベースの」ソシアルネットワーキング・サイトは真正ユーザーとのフレンドシップを求めようとする自動化エンティティである「フレンド・ボット」に感染することが少なくない。上述したボット分析およびボット被害抑制の技術はこのシナリオにおいても有用である。ここでは、ボット分析はフレンド-ボットであることを示唆する幾つかのファクター、例えば、ひたすら（真正）ユーザー・プロファイルにアクセスし、ユーザーのＩＤまたはプロファイルから得られるその他の情報を入手し、ユーザーエージェントの「フレンド」を増やそうとするユーザーエージェントを探索する。このような[フレンド増やし」アクションはフレンド・ボットと関連する場合が多い。そこで、ＣＤＮサービス・プロバイダーはソシアルネットワーキング・サイト・カスタマーにＶＵＳ（またはこれと等価のデータ)を提供することができる。ＶＵＳは特定のユーザーエージェントが[フレンド-ボット」または望ましくない自動化エンティティ（例えば、メッセージング・ボット）であるとのサービス・プロバイダーによる確信度を反映するものである。

上記の例では、ＣＤＮカスタマー・サイトのための具体的なボット被害抑制機能として、ユーザー・エージェントがサイトといかに相互作用すべきかを説明した。しかし、データシステムを利用することによって関連の他のボット被害をも抑制することができる。

ここに述べるデータシステムは所与のユーザー・エージェントを疑わしいと警告するだけの目的に使用することもできる。１つのサイトで収集されたユーザー・エージェントに関するデータは他のサイトにおけるユーザー・エージェントの挙動を分析し、予測するの
に利用することができる。例えば、チケット・ボットの場合、チケット・サイトＡにおけるＶＵＳによって識別することができる。これとは別に、サイトＡの極めて能動的なユーザーと他のチケット・サイトの極めて能動的なユーザーとの間に強い相関関係があることを発見することができる。この場合、システムはこのようなサイトＡのユーザーのリストを作成し、このリストを利用することによって他のチケット・サイトにおけるボット予測をすることができる。

データシステムはクリック詐欺や検索エンジン詐欺のような他のタイプのオンライン・サイト詐欺を識別し、その可能性を軽減するのに利用することもできる。

尚、ＣＤＮサービス・プロバイダーは１つまたは２つ以上のエンティティ（例えば、コンテンツ・プロバイダー、広告業者など）に連合サービスを提供することもできる。

以上に説明した本発明の範囲は、後記する請求項によって定義される。

Claims (8)

1. 加入コンテンツ・プロバイダーであるコンテンツ配信ネットワーク（ＣＤＮ）のカスタマーがＣＤＮサービス・プロバイダーによって管理されるコンテンツ・サーバーから配信するために所与のコンテンツをオフロードする、インターネットをベースとするＣＤＮにおけるデータ収集方法であって、
   ＣＤＮサービス・プロバイダーによって管理されている複数のコンテンツ・プロバイダー・ドメインに亘ってクライエント・マシーン・ユーザーエージェント及びその挙動をトラッキングし、
   ＣＤＮ専用の固有の識別子を各ユーザーエージェントに連携させ、
   トラッキングによって得られる情報を加入コンテンツ・プロバイダーが利用できるようにＣＤＮ専用の固有の識別子に連携する各ユーザーエージェントのプロファイルを作成するステップを含むデータ収集方法。
2. プロファイルを作成する前記ステップは個人情報を削除することにより行なわれる請求項１に記載のデータ収集方法。
3. 前記トラッキングステップは、所与のクライエント・マシーン・ユーザーエージェントをＣＤＮサービス・プロバイダーへ差し向け、所与のクッキーを設定することにより能動的に実行される請求項１に記載のデータ収集方法。
4. 前記トラッキングステップは、クッキーのデータを収集して相関することにより受動的に実行される請求項１に記載のデータ収集方法。
5. 前記プロファイルはクラスタ化アルゴリズムを用いて作成される請求項１に記載のデータ収集方法。
6. クライエント・マシーン・ユーザーエージェントが人間のユーザーかまたは自動化エージェントかを判断し、
   クライエント・マシーン・ユーザーエージェントが自動化エージェントであると判断すると、被害抑制措置を取るステップをさらに含む請求項１に記載のデータ収集方法。
7. 加入コンテンツ・プロバイダーであるコンテンツ配信ネットワーク（ＣＤＮ）のカスタマーがＣＤＮサービス・プロバイダーによって管理されるコンテンツ・サーバーから配信するために所与のコンテンツをオフロードする、インターネットをベースとするＣＤＮにおけるデータ収集システムであって、
   ＣＤＮサービス・プロバイダーによって管理されている複数のコンテンツ・プロバイダー・ドメインに亘ってクライエント・マシーン・ユーザーエージェント及びその挙動をトラッキングするコンテンツ・サーバーのトラッキング・メカニズムと、
   ＣＤＮ専用の固有の識別子を各ユーザーエージェントに連携させる識別子連携メカニズムと、
   コンテンツ・サーバーのトラッキング・メカニズムによって得られたクライエント・マシーン・ユーザーエージェントのデータを受信し、処理してＣＤＮ専用の固有の識別子に連携する各ユーザーエージェントのプロファイルを作成するするプロファイル作成メカニズムと、
   プロファイル作成メカニズムと連携して加入コンテンツ・プロバイダーに各ユーザーエージェントのプロファイルを提供するデータ検索メカニズムとから成るデータ収集システム。
8. データ検索メカニズムは、クライエント・マシーン・ユーザーエージェントが自動化エージェントでなくて人間のユーザーであるというＣＤＮサービス・プロバイダーの確信を表わすスコアを提供する請求項７に記載のデータ収集システム。