JP5795124B2 - 通信ネットワーク内でユーザがブラウジングする間にユーザを監視する方法およびサーバ - Google Patents

Description

本発明は、通信ネットワーク内でユーザがブラウジングする間にユーザを監視することに関する。

インターネットにおいて、より具体的には、ウェブとして知られているコンテンツのネットワークにおいて、ユーザに個別のサービスを提供するために、ユーザがブラウジングする間にユーザを監視する試みがなされる。

たとえば、電子商取引のサイトにおいて、ユーザは、ブラウジングする間に別々の時に複数の製品を選択し、仮想の「ショッピング・カート」にそれらを入れることができる。彼または彼女は、それらの料金を後で払うことができる。したがって、サイトは彼または彼女に個人的なショッピング・カートを割り当てるためにユーザを識別することができなければならない。

他の従来のアプリケーションでは、ユーザのプロファイルに適応したメッセージ（特に広告）を提示している。そうするために、したがって、ユーザのブラウジングを監視すること、したがって、彼または彼女が使用しているブラウザを監視する手段を持つことが重要である。

この問題への第１の解決策は、「クッキー」として知られている識別データの使用を通じて提供された。このデータは、サーバによってブラウザに送信され、ブラウザは、それが展開されている通信端末のメモリにファイルの形でこのデータを格納する。サーバに新しい要求があるたびに、アプリケーションは、このデータを添付するため、サーバによって容易かつ一意に識別される。

図１は、サードパーティー・サーバによって監視するためのこのメカニズムを示している。このサードパーティー「監視」サーバＳＴは、コンテンツ・サーバＳＣとは機能的に異なる。それは、たとえば、広告サーバの場合がある。

ブラウザＢは、ＩＥＴＦ（インターネット技術特別調査委員会）によって規定されたＨＴＴＰ（ハイパーテキスト転送プロトコル）プロトコルを使用して、コンテンツ・サーバＳＣにコンテンツ要求Ｍ１を送信する。この要求Ｍ１は、そのＵＲＬ（ユニファイド・リソース・ロケータ）を介して特定のリソース（一般的にウェブ・ページまたはマルチメディア・ファイル）を識別する。

受信すると、コンテンツ・サーバＳＣは、要求されたウェブ・ページを含む応答Ｍ２を送信する。このウェブ・ページは、監視サーバＳＴへのリンクを含む。このリンクは、そのコンテンツがその監視サーバによって提供される挿入物（たとえばバナー）の形でもよい。

この追加のコンテンツを取得するために、ブラウザＢは、今回は、この監視サーバＳＴを対象とする新しい要求Ｍ３を送信する。この要求は、応答Ｍ２内に含まれていたリソース識別子だけでなく、その監視サーバの識別データ（「クッキー」）および以前に訪問したコンテンツ・サーバＳＣの識別子も含む。

受信時に、監視サーバＳＴは、メッセージＭ４でユーザに適応した追加のコンテンツ（たとえば広告要素）を提供するためだけでなく、ユーザのプロファイルを構築するために受信した情報を保存するために識別データを使用することができる。このプロファイルは、特に、ユーザの興味の領域を決定するために、訪問されたコンテンツ・サーバＳＣを追跡することができる。

しかし、このメカニズムは問題がある。

クッキーの使用は、プライバシーに関して強く批評されてきた。このメカニズムは、圧力により取り除かれるかもしれない。しかし、最も重要なことには、ブラウザは、この識別データを送信しないように構成することができる。

Ｓａｆａｒｉなど一部のアプリケーションは、それどころか、サードパーティー（たとえば、直接訪問されてはいないが、広告を提供していたサイト）に識別データを送信しないようにデフォルトで構成されている。

さらに、ユーザ自身は、誤操作による個人データの送信を制限することによってプライバシーを保護するため、ハード・ドライブの領域を解放するため、または他の理由のために、ハード・ドライブ上に格納されたクッキーを削除することができる。

したがって、クッキー・メカニズムの欠点に取り組むために、代替案が現れ始めている。

主な代替案は、ブラウザ・タイプのフィンガープリント、およびブラウザが展開されている通信端末のＩＰアドレスに基づいている。このフィンガープリントは、ＨＴＴＰ要求で送信される情報要素から構成されている。それらは、特にブラウザ・タイプ（Ｓａｆａｒｉ、インターネット・エクスプローラ、Ｆｉｒｅｆｏｘ、Ｍｏｚｉｌｌａ、Ｃｈｒｏｍｅなど）、バージョン番号、および通信端末のプラットフォームまたはオペレーティング・システム（Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、ｉＯＳ、Ａｎｄｒｏｉｄなど）の識別子を含む。

この解決策も満足のいくものではない。

ＩＰアドレス／フィンガープリントの組み合わせが、２つの異なるブラウザ・インスタンスで同じである状況がある。

これが起きるのは、ユーザが同じマシンで２つのセッションを開始したときである。

また、これは、すべての通信端末が同じブラウザ・タイプの同じバージョンを使用するように、企業がその通信ネットワークにインストールされたソフトウェアに対してポリシーを規定しているときにも起きる。したがって、フィンガープリントは、企業の装置のすべてで同じになる。さらに、従来のネットワーク・インフラストラクチャの選択は、企業内の複数の装置が同じＩＰアドレスを持っているように外部のサーバに認識できるように、ＮＡＴ（ネットワーク・アドレス・トランスレイタ）を介して企業の通信ネットワークを公衆網にリンクさせることである。

同じ種類の状況は、自宅において通信端末（コンピュータ）の２つ以上が、同じ方法で構成されている個人宅内で発生する。外部サーバは、家族の異なるメンバーを区別することができない。

結果として、ｌＰアドレス／フィンガープリントの組み合わせが１つのブラウザ・インスタンスに対して一意の識別子を形成しないケースが多く発生する。

ＩＥＴＦ ＲＦＣ２６１６ セクション１４．９．３

本発明の目的は、新しいメカニズムを提案することによって状況を改善することである。

本発明の第１の目的は、通信ネットワークについてブラウザを監視するための方法であって、監視サーバは、監視要素の組を含み、
− ブラウザから監視要素要求を受信するステップと、
− 要求がブラウザからの最初の要求かどうかを決定するステップと、
− そうである場合、ブラウザの識別子を計算するステップと、次に、その組の各監視要素に関連するキャッシュ期間値を決定するステップと、監視要素の組および関連する値をブラウザに送信するステップと、
− そうでない場合、要求で要求された監視要素に基づいてブラウザの識別子を決定するステップと
を実装する。

本発明の異なる実施形態では、要求が最初の要求かどうかは、前述の要求で要求された監視要素の数に基づいて決定することができる。

方法は、また、ブラウザがコンテンツ・サーバにコンテンツ要求を送信し、そのコンテンツ・サーバが、要求されたコンテンツおよび監視要素につながるリンクを含む挿入物の両方を送信する、前の第１のステップを含むことができる。

識別子は、前述の要求内で送信された識別情報を含む第１の部分と、カウンターから構成された第２の部分とから構成することができる。

監視要素の組における監視要素の数は、ビットで表現された、そのカウンターの長さと等しい場合がある。

重要度ｉを持つビットｂ（ｉ）の値および位置ｉで監視要素に関連するキャッシュ期間値は、以下の関係に従う場合がある。
ｂ（ｉ）＝１の場合、ｖ（ｉ）＝ｍａｘ
ｂ（ｉ）＝０の場合、ｖ（ｉ）＝０
ここで、「ｍａｘ」は、所与のキャッシュ期間についての、最大の可能な値である。

識別子は、また、連鎖されたリダイレクトを示す第１の部分に先行されてもよい。

これらの連鎖されたリダイレクトは、その第１の部分に一致する重要度を持つビットによって示すことができる。

それらの連鎖されたリダイレクトの中の各リダイレクトは、ゼロのキャッシュ値またはキャッシュ値の、最大の可能な値に関連づけることができる。

あるいは、それらの連鎖されたリダイレクトの中の各リダイレクトは、３０１または３０２のリダイレクト・コードに関連づけることができる。

本発明の第２の目的は、上に規定された方法ならびに示された実施形態を実装するための、監視要素の組および手段を含む監視サーバである。

本発明の第３の目的は、上に規定した監視サーバおよびコンテンツ・サーバを含むサーバである。

したがって、本発明のおかげで、クッキーを使用することなく、またはより広くは、ユーザの端末にファイルまたは情報をインストールする必要なく、ユーザを識別することが可能になる。

また、単一のマシンまたは同じネットワークで展開されているブラウザの違いを見分け、そのことによってそれぞれを識別することが可能である。

ブラウザの識別子は、通信端末と監視サーバとの間のリンク上を含む、通信ネットワーク上を明示的に移動しない。その結果、本発明は、個人情報の盗難の試みおよび他の悪意のある攻撃に関して堅牢である。

本発明、その特性およびその利点は、添付の図面と共に後続する実施形態の記述から、より明白になるであろう。

上記の最新技術のメカニズムを示す図である。 本発明の２つの構成上の実施形態を示す図である。 本発明の２つの構成上の実施形態を示す図である。 本発明による監視サーバによって実装される様々なステップの流れ図である。 ２つのリダイレクト・コード値を用いるリダイレクト・メカニズムを使用する本発明の一実施形態を示す図である。

本発明の監視サーバの複数の実施形態が可能である。

監視サーバＳＴは、専用の物理サーバに展開できるソフトウェア・アプリケーションでもよく、または他のアプリケーションと共有してもよいことに注意されたい。また、分散型またはピア・ツー・ピアの運転モードに基づいて、物理マシン（「クラスタ」）の組に展開することもできる。

さらに、図２に示すように、この監視サーバＳＴは、同じ物理マシンにコンテンツ・サーバＳＣと共に、または物理マシンの同じ「クラスタ」に配置することができる。

図３において、監視サーバＳＴは、コンテンツ・サーバＳＣから離して配置されている。監視サーバＳＴは、その監視活動を専用とするマシンでもよく、または複数のソフトウェア・アプリケーションをホストするマシン（またはマシンの群）でもよい。

これらの２つの技術的なアーキテクチャは、商業における選択を反映することができる。

第１の場合には、２つのサーバは、単一の組織によって管理される。コンテンツを担当する企業は、また、監視サーバを展開することができる。該当する企業がコンテンツ・サーバを展開させるためにホストを用いる場合、そのホストは、また、監視サーバを展開させることを提供することができる。それは、請求可能または定額料金に含まれるサービスでもよい。

第２の状況は、ウェブ・サービスを専門とし、特に監視サービスを提供するサードパーティー企業に対応することができる。コンテンツ会社またはそのホストは、その訪問者をサードパーティー企業が監視するためにサービス契約を確立することができる。サードパーティー企業は次に、収集した情報および契約の条件に基づいて訪問者に関する報告を送信することができる。

第１の状況は、電子商取引サイトおよびコンテンツを担当する企業による仮想ショッピング・カートの管理に対応することができる。

本発明は、選択されたアーキテクチャおよび商業モデルに依存しない。

第１に、ブラウザ（またはブラウザ）Ｂは、コンテンツ・サーバＳＣにＵＲＬを含むコンテンツ要求Ｍ１を送信する。

コンテンツ・サーバＳＣは、要求されたコンテンツを含む１つまたは複数のメッセージＭ２で応答する。このコンテンツは、典型的には、たとえばＨＴＭＬ形式（ハイパーテキスト・マークアップ言語）のウェブ・ページである。

これは、コンテンツ・サーバＳＣに静的に格納することも、またはデータベース（ｍｙＳＱＬなど）のコンテンツおよびＰＨＰ言語スクリプトに基づいて動的にその場で構築することもできる。

このコンテンツは、監視サーバＳＴに関係する部分を含む。この部分は、コンテンツ・サーバＳＣに監視サーバＳＴによって前もって送信することも、または管理者が手作業で構成することもできる。

そのような部分の構成は、サードパーティー・コンテンツ（広告挿入物）の部分を含む大多数のウェブサイトがこの原理で動作するため、それ自体が知られている、

この挿入物のコンテンツは本発明に特有である。

本発明によると、この挿入物は、監視要素へのリンクの組を含む。これらの監視要素は、監視サーバＳＴに格納される。これらは、任意のタイプのファイルである（画像、テキストなど）。それらは、通信パフォーマンスが低下すること、および監視サーバで多くの領域を占めすぎることを避けるために、最小サイズであることが望ましい。

この挿入物は、＜ＤＩＶ＞セクションとしてＨＴＭＬ言語で書くことができる。

そのような挿入物の一例は、以下のようでもよい。
＜ＤＩＶ ｃｌａｓｓ＝ＳＴ＞
＜ｉｍｇ ｓｒｃ＝ｈｔｔｐ：／／ｗｗｗ．ｓｔ．ｃｏｍ／ｔｒａｃｋｅｒ／ｅｌｔ＿１．ｐｎｇ＞
＜ｉｍｇ ｓｒｃ＝ｈｔｔｐ：／／ｗｗｗ．ｓｔ．ｃｏｍ／ｔｒａｃｋｅｒ／ｅｌｔ＿２．ｐｎｇ＞
＜ｉｍｇ ｓｒｃ＝ｈｔｔｐ：／／ｗｗｗ．ｓｔ．ｃｏｍ／ｔｒａｃｋｅｒ／ｅｌｔ＿３．ｐｎｇ＞
＜／ｄｉｖ＞

この例では、アドレスｗｗｗ．ｓｔ．ｃｏｍは、サーバＳＴのものに対応する架空のアドレスである。クラス「ＳＴ」は、また、監視機能に対応し、スタイル・シート（．ｃｓｓファイル）を使用して＜ＤＩＶ＞セクションのグラフィック・レンダリングを制御することを可能にする内部使用のための文字列であるが、技術的な効果はない。

「ｅｌｔ＿１．ｐｎｇ」、「ｅｌｔ＿２．ｐｎｇ」、「ｅｌｔ＿３．ｐｎｇ」というファイルは、３つの監視要素であり、ここではｐｎｇ形式の画像である。

このメッセージＭ２が受信されると、ブラウザＢは、ページを生成し、それが展開される通信端末の画面上にそれを表示できるために、監視要素を取得しなければいけない。

したがって、それは監視サーバに監視要素に対する要求Ｍ３を送信する。

典型的には、この要求は、ＨＴＴＰプロトコルに従ってＧＥＴメッセージから構成され、１つのＧＥＴメッセージは１つの監視要素に対応する。

例として示すＤＩＶセクションに基づいて、ブラウザＢは、サーバｗｗｗ．ｓｔ．ｃｏｍに送られる３つのＧＥＴメッセージを形成することができる。
ＧＥＴ ｔｒａｃｋｅｒ／ｅｌｔ＿１．ｐｎｇ
ＧＥＴ ｔｒａｃｋｅｒ／ｅｌｔ＿２．ｐｎｇ
ＧＥＴ ｔｒａｃｋｅｒ／ｅｌｔ＿３．ｐｎｇ

監視要素要求を受信するこのステップは、図４の流れ図にＥ１と示されている。

この要求を受信すると、監視サーバＳＴは、その要求がブラウザＢからの最初の要求かどうかを決定する第２のステップＥ２を実装することができる。

この決定は、要求Ｍ３で要求された監視要素の数に基づいて行うことができる。監視要素の組が要求される場合、それは最初の要求である。そうでない場合、後に記述するように、それは最初の要求ではない：ブラウザのキャッシュ・メモリに、再び要求されない監視要素がある。

提示した例では、それは最初の要求である。次に、監視サーバＳＴは、以下を実装することができる。
− ブラウザＢの識別子を計算するステップＥ３、次に
− その組の各監視要素に関連するキャッシュ期間値を決定するステップＥ４、および
− ブラウザＢにこれらの監視要素の組および計算値を送信するステップＥ５。

この識別子は、新しいブラウザが監視サーバＳＴに接触するたびに増分されるカウンターでもよい。

本発明の１つの優先的な実施形態によると、この識別子は、要求Ｍ３で送信された識別情報を含む第１の部分と、そのカウンターから形成される第２の部分とから構成される。

この識別情報は、ブラウザＢのフィンガープリントでもよく、ＨＴＴＰプロトコルに従ったメッセージＭ３の「Ｕｓｅｒ Ａｇｅｎｔ」ヘッダに対応することができる。このヘッダは、ＨＴＴＰサーバに接続するために使用されるソフトウェアを指定する文字列である。上記のように、それは一般的に、ブラウザ・タイプ（Ｍｏｚｉｌｌａ、ＩＥ、Ｃｈｒｏｍｅなど）およびバージョン番号を含む。

カウンターは、同じフィンガープリントを持つブラウザを一意に区別することを可能にする。

識別子がカウンターのみから構成されている実施形態と比較して、この実装では、計測器のサイズ、したがって監視要素の数を減らすことが可能になる。したがって、送信される情報の量だけでなく、監視サーバおよびブラウザのキャッシュ・メモリのメモリ・リソースを減らすことが可能である。

また、要求Ｍ３の送信ＩＰアドレスを使用することが可能である。これにより、カウンターに必要な領域をさらに減らすことが可能になる。なぜなら、カウンターは、同じＩＰ領域に属し、同じフィンガープリントを持つブラウザを区別するため以外に、もはやいかなる目的も果たさないためである。

したがって、カウンターの長さは事前に規定されるべきであり、これは同じフィンガープリントを持ち、同じＩＰ領域に属するブラウザの予想される最大数を推定することを意味する。この数は、デフォルト値で構成することができ、管理者によって編集することができる。

この長さｎ（ビット）は、次の式によってカウンターの最大数Ｎに基づいて表現することができる。ｎ＝［ｌｏｇ２（Ｎ）］＋１

監視サーバＳＴは、ｎ個の監視要素を保存する。これらの監視要素は、異なるタイプのファイルである（画像、テキストなど）。それらは必ずしもすべて同じタイプであるとは限らない。

次のステップＥ４は、ｎ個の要素のその組において各監視要素に関連するキャッシュ期間値を決定することから構成される。

実際に、ダウンロードされた要素のすべてまたは一部をブラウザがキャッシュ・メモリに格納することを可能にするメカニズムがある。したがって、同じウェブ・ページへの２回目の訪問の間に、ブラウザは、キャッシュ・メモリに既に存在する要素を再ダウンロードしない。このメカニズムにより、送信されるデータの量を最小限にすることが可能になる。

キャッシュ・メモリは、ブラウザが展開されている通信端末のハード・ドライブまたは揮発性メモリ上にあってもよい。

一実施形態によると、キャッシュ期間値は、カウンターの２進数書き込みに基づいて決定される。

したがって、このカウンターは、ｂｎ・・・ｂ３−ｂ２−ｂ１と書き込むことができ、ここで、ｂｉは、重要度ｉを持つビットである。

重要度ｉを持つビットに対応する要素に対する値ｖ（ｉ）は、以下の式に基づいて得られる。
ｂ（ｉ）＝１の場合、ｖ（ｉ）＝ｍａｘ
ｂ（ｉ）＝０の場合、ｖ（ｉ）＝０
ここで、ｍａｘは、一定のキャッシュ期間について最大の可能な値である。また、それは、同じブラウザからの２つの要求の間にキャッシュの期限が切れないだけ十分に長い任意の長い値でもよい。

次のステップＥ５は、ブラウザＢに監視要素自体およびそれぞれの監視要素に対して決定されたキャッシュ期間値を送信することから構成される。

この送信は、要求にメッセージＭ３があるのと同数のメッセージＭ４から構成することができる。

この理由は、ＨＴＴＰプロトコルでは、各ＧＥＴメッセージは、要求された要素を含む「２００ ＯＫ」応答メッセージに対応するためである。上記の例では、したがって、監視要素ｅｌｔ＿１．ｐｎｇ、ｅｌｔ＿２．ｐｎｇ、およびｅｌｔ＿３．ｐｎｇを含む３つのメッセージがある。

各応答メッセージは、ＨＴＴＰヘッダに対応するキャッシュ期間値を含むことができる。

ｂ（ｉ）＝０の場合、このヘッダは、以下のように見える場合がある。
Ｓｔａｔｕｓ Ｃｏｄｅ：２００ ＯＫ
Ｃａｃｈｅ−ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ，ｎｏ−ｔｒａｎｓｆｏｒｍ，ｍａｘ−ａｇｅ＝０
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｔｅｘｔ／ｘｍｌ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：６７０
ｓｅｒｖｅｒ：ｊｅｔｔｙ（６．１．ｘ）

ｂ（ｉ）＝１の場合、このヘッダは、以下のように見える場合がある。
Ｓｔａｔｕｓ Ｃｏｄｅ：２００ ＯＫ
Ｃａｃｈｅ−ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ，ｎｏ−ｔｒａｎｓｆｏｒｍ，ｍａｘ−ａｇｅ＝２１４７４８３６４７
ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｔｅｘｔ／ｘｍｌ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：６７０
ｓｅｒｖｅｒ：ｊｅｔｔｙ（６．１．ｘ）

ｃａｃｈｅ−ｃｏｎｔｒｏｌ行のｍａｘ−ａｇｅパラメータは、０または最大許容値に等しい値ｖ（ｉ）を含む。このパラメータは、ＩＥＴＦのＲＦＣ２６１６のセクション１４．９．３に規定されている。

さらに、ブラウザＢとサーバとの間に配置された「プロキシー」（キャッシュ・メカニズムを実装するローカルの中間要素）が、キャッシュにこれらの監視要素を保存するのを防ぎ、それによって本発明のメカニズムに干渉するのを防ぐために、「プライベート（ｐｒｉｖａｔｅ）」パラメータを示すことが役に立つ場合がある。

このキーワードは、これらの監視要素のキャッシュ・メカニズムの管理が「プライベート」であることを示している。つまり、唯一の責任は、クライアント（ブラウザＢ）およびサーバにあることを意味する。

上に記述した３つの監視要素の例では、計算した識別子が３または２進数の「０１１」であると想定している。したがって、キャッシュ値は、ｅｌｔ＿３．ｐｎｇに対して０であり、ｅｌｔ＿２．ｐｎｇおよびｅｌｔ＿１．ｐｎｇに対してｍａｘ（つまり、この場合２１４７４８３６４７秒）である。

監視要素は、ブラウザＢのキャッシュ・メモリに保存される。

同じブラウザＢがコンテンツ・サーバＳＣに新しい要求を送信する場合、以前に記述したようにブラウザＢは監視サーバＳＴに関係する部分を受信する。それが同じページである場合、その部分は以前に受信されたものと同一の可能性がある（たとえば、それがその間に更新されたという場合でもない限り）。

それ自体が既知の方法で、ブラウザは、ページを生成し、監視要素が展開される通信端末の画面上に監視要素を表示できるように、監視要素を取得するように適応される。この取得は、キャッシュ・メモリに既に存在する要素に基づいて、および関連するキャッシュ期間値に基づいて実行される。

関連する値がサーバによって０に設定されていた場合、その要求と以前の要求との間の時間に関係なく、ブラウザは、再び監視サーバＳＴから要素を要求しなければいけない。したがってブラウザは、該当する要素を要求するＧＥＴメッセージを送信する。

関連する値が「ｍａｘ」に設定されていた場合、ブラウザＢは、ユーザにそれを提示するために保存された監視要素を使用し、監視サーバにメッセージは送信しない。

例においては、したがって、ブラウザは、サーバｗｗｗ．ｓｔ．ｃｏｍに送られる１つのＧＥＴメッセージを送信する。
ＧＥＴ ｔｒａｃｋｅｒ／ｅｌｔ＿３．ｐｎｇ

ブラウザの振る舞いは、本発明に従って監視サーバＳＴによって送信された情報によって引き起こされるが、ブラウザ自体は、ＨＴＴＰプロトコルに従ったブラウザの標準の振る舞いに従う。本発明は、ブラウザまたは通信端末への変更を含まない。

監視サーバＳＴは、ステップＥ１で、この監視要素要求を受信する。

ステップＥ２は、それが最初の要求かどうかを決定することから構成される。

監視要素のすべてが再び要求されるわけではないため（要素ｅｌｔ＿１．ｐｎｇおよびｅｌｔ＿２．ｐｎｇは要求されない）、サーバＳＴは、このことから、それが最初の要求ではなく、したがって、ブラウザＢは既に「知られている」ことを推定することができる。

次に、監視サーバＳＴは、そのブラウザの識別子を決定するステップＥ６をトリガーすることができる。

この決定は、識別子を生成するために使用されるものと反対のメカニズムによって、要求で要求された監視要素に基づいている。

記述した実装では、監視要素の位置によって、２進形で識別子を書き込むことが可能になる。要素ｅｌｔ＿１．ｐｎｇおよびｅｌｔ＿２．ｐｎｇが要求されている場合、重要度１および２を持つビットは１に設定され、要素ｅｌｔ＿３．ｐｎｇが要求されていない場合、重要度３を持つビットは０に設定される。したがって、ブラウザの識別子は、２進数の「０１１」または３と書き込まれる。

識別子が知られているため、監視サーバＳＴは、異なる監視戦略を実装することができる。それは、収集された情報、特にコンテンツ・サーバに表示されるＵＲＬアドレスを保存し、それによってブラウザのユーザのプロファイルを、彼または彼女のブラウジング履歴に基づいて構築することができる。このプロファイルに基づいて、適切な広告挿入物を決定することができる。

また、それは特定のコンテンツ・サイトまたはサイトの組の訪問者について統計を構築するために、この情報を使用することができる。

本発明の一変形形態では、カウンターの長さｎ、したがって使用する監視要素の数を減らすために、ＨＴＴＰプロトコルのリダイレクト・メカニズムを使用することが可能である。

このリダイレクト・メカニズムは、ＨＴＴＰプロトコルの、メッセージ３０２および３０７に依存している。

監視サーバＳＴに関係する部分において、アドレスＵＲＬ１を示すことができる。このアドレスＵＲＬ１は、アドレスＵＲＬ２にリダイレクトするために監視サーバＳＴで構成される。

１回目の訪問の間に、ブラウザはリダイレクトに従うが、２回目の訪問の間に、リダイレクトはブラウザによって保存され、ブラウザは次に第２のアドレスＵＲＬ２を直接的に問い合わせる。

複数のリダイレクトｒ１、ｒ２、ｒ３、ｒ４、ｒ５を連鎖させることによって、ユーザを識別するために、この振る舞いを使用することが可能である。

ユーザが初めてサイトに接続するときは常に、連鎖されたリダイレクトに従う。ｒ１−＞ｒ２−＞ｒ３−＞ｒ４−＞ｒ５。それは自動的にリダイレクト要素ｒ１、ｒ２、ｒ３、ｒ４、ｒ５をダウンロードする。

サーバは、各リダイレクト要素に対して異なるキャッシュ値を設定することができる。たとえば、ｒ２およびｒ５に対してヌル値、他の要素に対して非常に高い値である。

したがって、後の訪問の間に、ブラウザは、ｒ２によって示されたアドレスに直接的に行き、次の経路に従う。ｒ２−＞ｒ５。

したがって、これから、ブラウザはキャッシュに要素ｒ１、ｒ３、およびｒ４を持っていると推定し、この情報に基づいて、複数のユーザを区別することが可能である。

１つの代替案は、異なるキャッシュ値ではなく異なるリダイレクト・コードを使用することから構成することができる。たとえば、リダイレクト・コード３０１およびリダイレクト・コード３０２を使用することが可能である。これらで２つのコード値でリダイレクトを連鎖させることによって、図５に示すように２分木を取得することが可能である。この図において、上向きのブランチはコード値３０１に対応し、下向きのブランチはコード値３０２に対応することが想定される。

ブラウザは、一般的に、許容されるリダイレクトの数の最大値を持っている（たとえば５）。このように、このメカニズムは、限られた数のユーザ、ここでは２^５＝３２を区別することを可能にするだけである。

本発明の一実施形態によると、このメカニズムは、管理される監視要素の数を減らすために、監視要素の使用を補完するために使用される。本発明のこの実装は、それによって、サーバにおいて、ブラウザのキャッシュ・メモリで、および通信ネットワーク上の送信において、本発明に必要とされるリソースを減らすことを可能にする。

そうするために、リダイレクト要素を示す第１の部分（最上位）がブラウザの識別に先行してもよい。

監視要素に基づいて識別子を書き込むための可能な実装として以前に記述したものに類似する方法で、この第１の部分は、ｒｋ・・・ｒ３−ｒ２−ｒ１と書き込むことができ、ｒｉは重要度ｉを持つビットであり、ｋは可能なリダイレクトの数である。

連鎖されたリダイレクトは、前述の第１の部分に一致する重要度を持つビットによって示すことができる。

重要度ｉを持つビットに対応するリダイレクト要素に対する値ｖ（ｉ）は、以下の式に基づいて得られる。
ｒｉ＝１の場合、ｖ（ｉ）＝ｍａｘ
ｒｉ＝０の場合、ｖ（ｉ）＝０
ここで、ｍａｘは、一定のキャッシュ期間について最大の可能な値である。また、それは、同じブラウザからの２つの要求の間にキャッシュの期限が切れないだけ十分に長い任意の長い値でもよい。

他の可能な式は、異なるリダイレクト・コードに基づいていてもよい。
ｒｉ＝１の場合、ｖ（ｉ）＝３０１
ｒｉ＝０の場合、ｖ（ｉ）＝３０２

第１の部分を持つブラウザの識別子は、ｒｋ・・・ｒ３−ｒ２−ｒ１−ｂｎ・・・ｂ３−ｂ２−ｂ１と書き込むことができる。合計長さはｋ＋ｎに等しい。

Claims (12)

1. 通信ネットワーク（Ｎ）についてブラウザ（Ｂ）を監視するための方法であって、監視サーバは、監視要素の組を含み、
   ブラウザ（Ｂ）から監視要素要求を受信するステップ（Ｅ１）と
   前記要求が前記ブラウザからの最初の要求かどうかを決定するステップ（Ｅ２）と、
   最初の要求と決定された場合、前記ブラウザの識別子を計算するステップ（Ｅ３）と、次に、前記組の各監視要素に関連するキャッシュ期間値を決定するステップ（Ｅ４）と、前記監視要素の前記組および前記値を前記ブラウザに送信するステップ（Ｅ５）と、
   最初の要求と決定されなかった場合、前記要求で要求された前記監視要素に基づいて前記ブラウザの識別子を決定するステップ（Ｅ６）と
   を実装する、方法。
2. 要求が最初の要求かどうかは、前記要求で要求された監視要素の数に基づいて決定することができる、請求項１に記載の方法。
3. 前記ブラウザがコンテンツ・サーバにコンテンツ要求を送信し、前記コンテンツ・サーバが、前記要求されたコンテンツおよび前記監視要素につながるリンクを含む挿入物の両方を送信する、ステップを含む、請求項１または２に記載の方法。
4. 前記識別子は、前記要求で送信された識別情報を含む第１の部分と、カウンターから形成された第２の部分とから構成される、請求項１乃至３のいずれか１項に記載の方法。
5. 前記組における監視要素の数は、ビットで表現された、前記カウンターの長さに等しい、請求項４に記載の方法。
6. 重要度ｉを持つビットｂ（ｉ）の値および位置ｉで前記監視要素に関連するキャッシュ期間値は、以下の関係に従うことができ、
   ｂ（ｉ）＝１の場合、ｖ（ｉ）＝ｍａｘ
   ｂ（ｉ）＝０の場合、ｖ（ｉ）＝０
   ここで、「ｍａｘ」は、所与のキャッシュ期間についての、最大の可能な値である、請求項５に記載の方法。
7. 前記識別子は、連鎖されたリダイレクトを示す第１の部分に先行される、請求項６に記載の方法。
8. 前記連鎖されたリダイレクトは、前記第１の部分に一致する重要度を持つビットによって示される、請求項７に記載の方法。
9. 前記連鎖されたリダイレクトの中の各リダイレクトは、ゼロのキャッシュ値またはキャッシュ値の、最大の可能な値に関連づけられる、請求項７または８に記載の方法。
10. 前記連鎖されたリダイレクトの中の各リダイレクトは、３０１または３０２のリダイレクト・コードに関連づけることができる、請求項７または８に記載の方法。
11. 請求項１乃至１０のいずれか１項に記載の方法を実装するための、監視要素の組および手段を含む監視サーバ。
12. 請求項１１に記載の監視サーバおよびコンテンツ・サーバを含むサーバ。

Images