JP2002507308A - 外部サーバへのハイパーリンク照会をリダイレクトする方法及び装置 - Google Patents

Abstract

(57)【要約】 トラッキングを行うサーバシステムの外部にあるリソースに対応する既定のリソースロケータを照会しているクライアントシステムに応答してトラッキングサーバシステムにメッセージが提供される。トラッキングサーバシステムはクライアントシステムによる選択が可能な情報要素を間接的にクライアントシステムにもたせ、情報要素はコンテンツリソースロケータを用いてコンテンツサーバシステムから入手が可能な情報コンテンツにクライアントシステム上でグラフィカルに結びつけられる。情報要素はトラッキングリソースロケータ、トラッキングサーバシステム照会、及び情報要素識別データを含む。情報要素を選択すると、クライアントシステムはトラッキングサーバシステムにデータを提供するためにトラッキングリソースロケータを使用し、コンテンツサーバシステムから情報コンテンツを入手するためにコンテンツリソースロケータを使用する。

Description

【発明の詳細な説明】 外部サーバへのハイパーリンク照会をリダイレクトする方法及び装置 発明の背景 発明の属する技術分野 本発明は全般的にはワールドワイドウエッブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ ）ベースのデータページをサポートするネットワーク情報サービスシステムの管 理に関し、特に、外部サーバへのハイパーリンク照会を、管理し、節度を保たせ 、またそのような照会をアカウントする目的で、効率よくリダイレクトするため のサーバシステム及びプロセスに関する。関連技術の説明 インターネットとして一般に知られる国際的に接続されたネットワークの近年 の大幅な成長及び利用の拡大は、主としてハイパーテキスト伝送プロトコル（Ｈ ＴＴＰ）の広範なサポートによっている。このプロトコルにより、インターネッ トサービスプロバイダ（ＩＰＳ）を介して接続されたクライアントシステムが、 同様にインターネットに接続された地理的に散在する個々のサーバシステムにア クセスできる。ネットスケープ・コミニュケーションズ社（Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．）のネットスケープ・モジラ（Ｍｏ ｚｉｌｌａ）（登録商標）及びナビゲーター（Ｎａｖｉｇａｔｏｒ）（登録商標 ）、マイクロソフト・インターネットエクスプローラ（Ｍｉｃｒｏｓｏｆｔ Ｉ ｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ）（登録商標）並びにＮＣＳＡモザイク（Ｍ ｏｚａｉｃ）（商標）のようなクライアント側ブラウザは、ＨＴＴＰプロトコル のクライアント側部分を実行する、効率のよいグラフィカル・ユーザインターフ ェースベースのクライアントアプリケーションを提供する。 ＨＴＴＰサーバと総称される、サーバ側のアプリケーションプログラムはＨＴ ＴＰプロトコルのサーバ側部分を実行する。ＨＴＴＰサーバプリケーションは、 ネットスケープのような会社から市販品として入手でき、またＮＣＳＡからソー スコードで入手できる著作権付フリーウエアとしても入手できる。 ＨＴＴＰプロトコルにより可能となった分散型通信及び情報伝送システムは一 般に、ワールドワイドウエッブ（ＷＷＷまたはＷ３）として、あるいは単に“ザ ・ウエッブ”として知られる。クライアント側のユーザインターフェースから見 ると、国際統一リソースロケータ（ＵＲＬ）システムが指名されたウエッブサー バコンピュータシステムとの個別的階層におけるトランザクション交信セッショ ンをウエッブブラウザに確立させるために用いられる。各ＵＲＬの基本型は一般 に： http://<サーバ名>.<サブドメイン名.最上位ドメイン名>/<パス名> である。サーバ名は通常“ｗｗｗ”であり、サブドメイン名.最上位ドメイン名 は標準的なインターネットドメイン名である。パス名はオプションで付加される ＵＲＬクオリファイアである。 クライアント側でユーザがＵＲＬを選択して特定することにより、クライアン トがハイパーテキストマークアップ言語（ＨＴＭＬ）によって構成されたデフォ ールトの、または明示名をもつデータファイルを照会するＨＴＴＰメッセージを サーバに送信する、トランザクションが確立される。このデータファイルすなわ ちウエッブページは、サーバによる１つ以上の応答フェーズＨＴＴＰメッセージ として返され、一般にはクライアントブラウザによりディスプレイ表示される。 付加された埋込イメージ名が前記返されたウエッブページ内で照合され、引き続 いて、通常は埋め込まれているグラフィックファイルを取り込むためのＨＴＭＬ トランザクションをクライアントブラウザが開始する。次いで、完全に再構成さ れたウエッブページイメージがブラウザのグラフィカル・ユーザインターフェー スを介してブラウザにより提示される。 インターネットの現存の名称識別サービス及びルート選択協定によってさらに サポートされたＵＲＬシステムによって可能となったウエッブの完全分散型クラ イアント／サーバ・アーキテクチャにより、ほとんど困難なくＨＴＴＰサーバが 個々に設立される。従ってウエッブは、最上位ドメイン名による緩やかな束縛以 外、中央のあるいは地域的なものであってさえ集中施行機関をもたない。ゆえに 、ほとんど当然のことながら個々のＨＴＴＰサーバにより供給される情報あるい は その他のリソースを検索することが問題となる。包括的であり、しかも効率のよ いウエッブ情報及びリソースの検索可能なデータベースを集めて整理するには時 間とコストかかかる上に複雑であるため、ウエッブを介して利用できるソースＵ ＲＬと関連付けられた情報及びリソースの集積に対してはたらきかける検索エン ジンサービスをサポートする、一般的には料金ベースのあるいは広告収入が得ら れる商業的インターネットビジネスサービス（ＩＢＳ）が設立されている。この ような検索エンジンへのアクセスは通常、インターネットビジネスサービスによ り提供される、サーバローカルウエッブページを介して行われる。検索結果は、 インターネットビジネスサービスのサーバにより動的に構成される、適切に埋め 込まれたリモートＵＲＬまたはハイパーリンクされたＵＲＬをもつローカルウエ ッブページの形態で提供される。 クライアントによる検索エンジンアクセス及び検索結果のウエッブページの取 込はおそらく何度も繰り返されることから宣伝のチャンスが得られるため、他の インターネットベースサービスのプロバイダはそれぞれのウエッブページに広告 を積極的に入れはじめた。広告媒体では一般的であるように、広告主に与えられ る代償は通常、広告の表示頻度である。すなわち、クライアントのブラウザに広 告が送られた回数だけが、どれだけ有効に宣伝が行われたかの指標となる。特定 のウエッブページ上の特定の広告の有効性のより直接的な尺度は、クライアント のウエッブブラウザが広告に表われるＵＲＬをそのウエッブページから積極的に 追うことを選択する回数である。よって、ハイパーリンクされた広告主のＵＲＬ が選択されたときに、クライアントブラウザから得られる情報をトラッキングす ることができなければならない。 直接照会情報を得る上での困難は、埋め込まれた広告及び対応するリモートＵ ＲＬをもつウエッブページの全てがそのウエッブページへの最初の照会において クライアントのブラウザに提供されるという事実から生じる。次いで当然のこと ながら、特定の広告主のＵＲＬの選択がその広告主と関連するＨＴＴＰダイモン （ＨＴＴＰｄ）サーバに向けられた独立のトランザクションを介して行われる。 広告主が広告を出しているＨＴＴＰｄサーバは上記次段階トランザクションには 組み込まれていないので、クライアントブラウザに先に提供されたウエッブペー ジに埋め込まれた広告主のＵＲＬあるいはその他いずれかのＵＲＬに向けて実際 に実行されたクライアントブラウザのハイパーリンクを広告が出されたサーバが トラッキングすることは通常は不可能である。 単純なウエッブページアクセスカウンタが比較的よく知られ、ウエッブ全体で 用いられている。これらのアクセスカウンタは当今のＨＴＴＰｄサーバシステム にサポートされる共通ゲートウエイインターフェース（ＣＧＩ）機能に基づいて いる。ＣＧＩ機能により、クライアントのＵＲＬリクエストに応答して、少なく とも通常はファンクションによる、一般的には短いプログラムをサーバが実行す ることができる。すなわちＨＴＭＬウエッブページ概念規定が、提供されるウエ ッブページイメージを再構成するウエッブブラウザプロセスの一部としてのサー バ側ＣＧＩプログラムの実行を指定する、特定のＨＴＭＬ照会を埋め込むために 与えられる。このようなＨＴＭＬ照会の形式は一般に： である。すなわち、個々別々のＣＧＩプログラム（count.cgi）実行のそれぞれ により増加するカウンタ値により、再構成されたウエッブページの表示可能イメ ージの一部が動的に与えられる。ＨＴＴＰプロトコルの動作を介して知ることが できる、時刻、リモートクライアントリクエスト者、クライアントドメイン、ク ライアントブラウザのタイプ及びその他の情報はＣＧＩプログラムファンクショ ンの一部として記録することができる。従って、あるウエッブページアクセスに ついてアカウント及びオーディットを行う手ごろな手段が存在する。 しかしアクセスカウンタは、基本的にサーバローカルウエッブページアクセス のみを記録する。ＣＧＩプログラムに向けられたクライアントブラウザは、クラ イアントブラウザに最初に提供されるウエッブページに関係するクライアントに より評定される。クライアントブラウザへの最初のウエッブページ提供は接続さ れるが、引き続いて行われる外部サーバへのハイパーリンク照会を与えるＵＲＬ の選択はどれも見ることかできず、よってＣＧＩプログラムベースのアクセスカ ウンタではカウントされない。アクセスカウンタのその他の限界は、ＣＧＩプロ グラムの実施は独立のロード−実行が可能であるという事実により生じる。ＣＧ Ｉプログラムは、ＣＧＩプログラムへのそれぞれのＵＲＬ照会に応答してサーバ コンピュータにより直接ロードされて実行されなければならない。プログラムの ロード及び実行のオーバーヘッドは、個別のＣＧＩプログラム呼出のそれぞれに 対しては小さいかもしれないが、繰り返されればサーバーコンピュータシステム への重大ではないにしてもかなりの負荷となる。ＣＧＩプログラムの頻繁な実行 には普通、クライアントのＵＲＬリクエストに応答するＨＴＴＰｄサーバの実効 平均アクセス時間の低下がともなう。検索エンジンへのアクセスを提供している インターネットビジネスサービスは毎日数１００万のリクエストを記録している ので、ウエッブページの提供効率が少し下がっただけでもインターネットビジネ スサービスのコスト効率は大きく低下することになる。１９９５年１２月の時点 で、特に、インフォシーク社（Ｉｎｆｏｓｅｅｋ Ｃｏｒｐｏｒａｔｉｏｎ）は １日あたり平均５００万の検索を扱っている。 ＣＧＩプログラムにともなう実行オーバーヘッドはかなり大きいことが多い。 ＣＧＩプログラムの多くは、パール（Ｐｅｒｌ）やＴＣＬのようなインタープリ ータ言語を用いて、少なくとも一部が実行される。従って、実質的な処理オーバ ーヘッドにはインタープリータ及びＣＧＩプログラムスクリプトをともにロード し、インタープリータを実行してプログラムスクリプトを処理し、次いで何であ れ生成された有用なデータを一般には持続型大容量記憶装置に実際に記録するた めの、多数回の大容量記憶装置転送が含まれる。最終的に、インタープリータ及 び／またはＣＧＩプログラムはアンロードされなければならない。 さらに外部ＣＧＩプログラムには、開始時及び稼働中のサーバーの構築及び管 理、並びに多忙な状況下でのサーバシステムの保全を含む、保守に関してかなり の問題がある。ウエッブページ提供カウントを個別に識別するためには、個々の ウエッブページのそれぞれに対して個々のＣＧＩプログラムがおそらく必要とな るであろう。あるいはＣＧＩプログラムを、特定のウエッブページを識別して適 切に弁別されるアクセスカウントを記録するようにこのプログラムがコールされ る精確な手段を整然と実施し得るだけの複雑なものとすることもできる。大量の ページアクセスが個別にカウントされるサーバシステム上のこのようなＣＧＩプ ログラムの保守は容易なことではない。 さらに外部プログラム、特に動的にインタープリートされるスクリプトが存在 することは、保全問題が起こり得ることを表わしている。特に、インタープリー トされたスクリプトのアクセス及び実行許可は、非公認のスクリプトのいずれか が実行され、よってサーバコンピュータ自体の基本的な完全性ではないとしても 収集されたデータの完全性が危うくなるようなことを防止するために、注意深く 管理され、また監視されなければならない。従って既知のアクセスカウンタでは 、先に提供されたウエッブページからのハイパーリンクに基づく外部サーバーへ のＵＲＬ照会の前記アカウントまたはオーディットの必要性に対する解決策は完 全な形であるいは部分的であっても、全く得られない。 ＨＴＴＰプロトコル自体は、バージョン１．５以降のＨＴＴＰプロトコルをサ ポートしているサーバ及びクライアントに対して根サーバベースのＵＲＬリダイ レクトシステムを提供している。ＨＴＴＰサーバにともなうコンフィギュレーシ ョンファイル（一般にsrm.conf）は： の形をもつ指向コンフィギュレーションを用いて、サーバのローカルＵＲＬ名デ ィレクトリを外部ＵＲＬ名に効率よく割り当てる指向リダイレクトを指定するこ とができる。バージョン１．５以降のＨＴＴＰサーバがリダイレクトのために上 記のように指定されるローカルディレクトリ（/dir1）へのＵＲＬ名を受領する と、ＵＲＬ（http://newserver.widget.com/dir1）の形で新しいロケーションを 含むリダイレクトメッセージがクライアントブラウザに返される。次いでこのリ ダイレクトＵＲＬは、通常のクライアントのＵＲＬリクエストのための基礎とし てクライアントブラウザにより使用される。 上記の現存のサーバベース・リダイレクトファンクションは、リダイレクトが 、通常の形式では、共通のリダイレクトベース・ディレクトリを共有する全ディ レクトリ階層のものであるため、外部サーバーへのアクセスのトラッキングをサ ポートするには不十分である。最も限定された形であってさえ、リダイレクトは 各ディレクトリ名ベースで行われる。すなわち、特定のウエッブページまたはグ ラフィックイメージまたはアクセスリクエストの特定のオブジェクトであるＣＧ Ｉプログラムとは独立に、ディレクトリへのアクセスの全てが、弁別されること なく全くばらばらにリダイレクトされる。よって、現存サーバがリダイレクトフ ァ ンクションを利用するいかなる能力も、ＨＴＴＰプロトコルが定める指向リダイ レクトオペレーションにより実際上禁止されないとしても、はなはだしく制限さ れる。 さらに、ＨＴＴＰプロトコルサーバの指向リダイレタト能力は、ＣＧＩプログ ラムまたはその他の実行可能なプログラムをリダイレクトの実行と同時に実行す る能力をもたず、よってリダイレクトＵＲＬリクエストに関連する情報を取り込 むためのいかなるアクションも実質的に妨げられる。さらに、ディレクトリコン フィギュレーション毎へのリダイレクトを指定するに必要なリソースコンフィギ ュレーションファイルが複雑であるためやはり、かなりの構築、保守及び、程度 は小さいが、保全問題が生じる。すなわち、サーバーリダイレクトは外部ＵＲＬ ハイパーリンク名のオーディットないしアカウントをサポートするに必要な基礎 的能力でさえもたない。 最後に、リダイレクトの形式は比較的複雑なＣＧＩプログラムを利用すること により得られる。このようなリダイレクトＣＧＩプログラムは、リダイレクトの 目標ＵＲＬの識別に必要であるため、おそらく何らかの形で別にリソース識別を 行う必要がある。唯一の目標ＵＲＬが識別されるとすれば、クライアントブラウ ザにリダイレクトＵＲＬを与えるに必要であるので、次いでＨＴＴＰサーバを介 してＣＧＩプログラムからクライアントにリダイレクトメッセージを返すことが できる。 不幸にして、このようなＣＧＩプログラムはどれも、最も簡単なアクセスカウ ンタプログラムにも付随する欠点の全てを包含している。構築、保守及び保全問 題に加えて、実行のロード及び待ち時間の問題が残っているだけでなく、上記の ようなリダイレクト提供手法には偽装アクセスに対して本質的な弱点がある。偽 装アクセスは、ＣＧＩプログラムへのＨＴＭＬ照合がどの特定のウエッブページ にも無関係に発せられるという事実により生ずる、特にＣＧＩプログラムにとっ ての問題である。従って、アクセスカウンタまたはその他のオーディットないし アカウントデータ収集プログラムを実施するＣＧＩプログラムはどれでも、適切 なウエッブページとは無関係に外部からＣＧＩプログラムのＨＴＭＬ文に繰り返 される照会により、アクセスカウントが不自然に増大し得る。偽装アクセスは本 質的に、ＣＧＩプログラムにより集められたいずれのデータをも、その実際の完 全性ではなくとも、見掛け上は傷つける。最小限、簡単なアクセスカウントでも その正確さを保証する能力がインターネットサービス広告主にとり基本的に重要 であるから、基礎的なアカウントまたはオーディット機能であってもこれを提供 するＣＧＩプログラムの使用には実用上限界がある。最後に、ＨＴＭＬでは、例 えばサーバーＣＧＩカウンターのＵＲＬ名に外部サーバーのＵＲＬ名が続くよう な、ただ１つのＵＲＬ名ボタンで順次アクセスされる２つのＵＲＬに対する不正 防止方法は与えられない。 発明の概要 すなわち、本発明の全般的目的は、外部サーバシステムへのハイパーリンク名 をトラッキングし、リダイレクトする信頼性の高いシステム及び方法を提供する ことにある。 上記目的は、トラッキングを行うサーバーシステムの外部にあるリソースに対 応する既定のリソースロケータを照会しているクライアントシステムに応答する 前記トラッキングサーバシステムへのメッセージを用意することで、本発明によ り達成される。トラッキングサーバシステムはクライアントシステムによる選択 が可能な情報要素を間接的にクライアントシステムにもたせる。ここで前記情報 要素は、コンテンツリソースロケータを利用してコンテンツサーバシステムから 得ることができる情報コンテンツとクライアントシステム上でグラフィカルに結 びつけられる。情報要素は、トラッキングリソースロケータ、トラッキングサー バシステム照合、及び情報要素識別データを含む。情報要素を選択すると、クラ イアントシステムは、トラッキングサーバシステムにデータを与えるためにトラ ッキングリソースロケータを使用し、コンテンツサーバシステムから情報コンテ ンツを得るためにコンテンツリソースロケータを使用する。 すなわち、本発明の利点は、クライアントユーザにはリダイレクトプロトコル の最小限の可視性を付与しながら、最終的に照会されたウエッブページを返す際 に最小限の待ち時間を差し挟む、便宜的な方法でＵＲＬ名データが取り込まれる ことである。 本発明の別の利点は、サーバの外部サポートプログラム及び多数の外部データ 照会の個別の呼出が本発明の結果として必要ではなくなり、よってウエッブサー バコンピュータシステムのＣＰＵ及びディスクの負荷増大及びその結果としての 待ち時間増加を最小限に抑えることである。 本発明のさらなる利点は、照会識別子及び指向リダイレクトのいずれをも、ク ライアントのＨＴＭＬリクエストによりばらばらに与えられるＵＲＬ指定の内で 完全に維持できることである。すなわち、本発明はＣＧＩカウンタあるいはＣＧ Ｉカウンタを組み込むいかなる方法にも要求される効率性及び保守性のいずれに おいても優れている。 本発明のまた別の利点は、本発明のプロトコルをサポートするに必要なプログ ラム修正がプロトコルトランザクションのサーバ端から完全に実施できることで ある。クライアント側は、クライアント側で定めた現存のＨＴＭＬプロトコルの 範囲内でトランザクションに関わるだけである。 本発明のさらに別の利点は、本発明の実施により、不適切なＵＲＬ及びプロト コル名に対する実質的な保全性を得られる一方で、秘密形式のプロトコルにより 保全性へのさらなる攻撃にさらされることを最小限に抑えられることである。こ のことは、好ましくはＵＲＬ指定の内部に有効性確認コードを含めることによっ て達成される。 本発明の上記及びその他の利点及び特徴は、以下の本発明の詳細な説明を添付 図面とともに考察することによってより良く理解されるであろう。添付図面にお いて、同じ参照数字は図面全体を通じて同じ要素を表わす。 図面の簡単な説明 図１は、インターネットを介して相互にネットワークされたクライアント及び サーバコンピュータシステムの概略図である。 図２は、本発明の好ましい実施の形態に従うＨＴＴＰダイモン（ＨＴＴＦ）ｄ ）サーバを組み込んでいるサーバコンピュータシステムのブロック図である。 図３は、クライアントのＵＲＬリクエストの受領及び処理において本発明の好 ましい実施の形態に従って行われる処理を示す流れ図である。 図４は、本発明の別の好ましい実施の形態に従う特別リダイレクトＵＲＬのサ ーバ側プロセスを示す流れ図である。 図５は、本発明の別のプロセスを実施するクライアント及びサーバコンピュー タシステムの一般化した処理を表わす図である。 図６は、本発明の好ましい実施の形態に従うコンテンツリクエストメッセージ を発行するサーバ側プロセスを示す流れ図である。 図７は、本発明の好ましい実施の形態に従うトラッキングメッセージを発行す るクライアント側プロセスを示す流れ図である。 発明の詳細な説明 ネットワークサービスにインターネットを利用する代表的な環境１０が図１に 示される。クライアントコンピュータシステム１２は直接、あるいはインターネ ットサービスプロバイダ（ＩＳＰ）を介してインターネット１４に接続される。 国際統一リソースロケータによる論理名により、対応するインターネットサーバ システム１６，１８にアクセスできる。一般には閉じているハイパーテキスト伝 送プロトコルトランザクションが、クライアントシステム１２上で実行されてい るクライアントブラウザアプリケーションとサーバシステム１６上で実行されて いるＨＴＴＰｄサーバアプリケーションとの間で結ばれる。本発明の好ましい実 施の形態においては、サーバーシステム１６は、インターネット１４に接続され ている別のＨＴＴＰｄサーバシステムへのハイパーリンク名を埋め込みまた少な くとも論理的にはサーバシステム１６の外部にあるウエッブページをサポートす なわち提供する、インターネットビジネスサービス（ＩＢＳ）を表わす。 上記の一般的な枠組みの範囲内で、本発明はクライアントシステム１２による 埋込ハイパーリンク名の選択のトラッキングを可能にする。すなわち、埋込ハイ パーリンク名はクライアントシステム１２のユーザによる選択、すなわちクリッ クが可能なグラフィックシンボルあるいはその他のウエッブページ要素をともな う。クライアントシステム上でのシンボルクリックは一般に、クライアントシス テムのユーザが関心をもつシンボルグラフィックにより何らかの形で識別される 情報を得るためになされる。トラッキングはクライアントシステム１２に提供さ れるウエッブページに埋め込まれているＨＴＭＬ情報により可能となることが好 ましい。この情報は先に準備されたいずれかのＨＴＴＰｄサーバシステムからク ライアントシステム１２に提供される。前記前もっての準備は、トラッキング情 報が与えられた提供ページを集めるように動作する、システム１６のような、指 定されたトラッキングＨＴＴＰｄサーバシステムにより提供されるウエッブペー ジ上で、すなわち前記ＨＴＴＰｄサーバシステムに代わって、シンボルクリック をトラッキングするためにＩＢＳによりなされる。 本発明に従って埋め込まれた前記情報は、クライアントコンピュータシステム １２がＨＴＴＰｄサーバシステム１６にトラッキング情報を十分与え得るもので ある。後にわかるように、この情報は、直接的または間接的に、クライアントコ ンピュータがシンボルグラフィックにともなう情報を十分リクエストし得るもの でもある。同じく後にわかるように本発明の実施には多くの可能な態様がある。 これらの実施態様は一般に、主としてサーバ側またはクライアント側のプロセス を用いるか、専用でプラグインのインタープリートされた管理プロセスを含むか 、または数多くの特定のデータ伝送プロトコルのいずれを使用するかでカテゴリ ー分けされる。 本発明の好ましい実施の形態は、サーバシステム１６により実行されるＨＴＴ Ｐｄサーバアプリケーションに専用修正プログラムとして組み込まれ、ＨＴＴＰ 指向リダイレクトを用いるサーバ側プロセスを利用する。すなわち、サーバシス テム１６またはその他のサーバシステム（図示せず）のようなＨＴＴＰｄサーバ システムによりクライアント１２に提供されるウエッブページには、論理的に外 部にあるサーバシステムにより提供されるウエッブページへのＵＲＬ名が埋め込 まれている。クライアントコンピュータシステム１２のクライアントブラウザを 介した前記埋込ＵＲＬの選択により、初めに前記外部サーバではなくサーバシス テム１６とのＨＴＴＰトランザクションが生じる。よって、クライアントシステ ム１２へのウエッブページで最初に提供された前記埋込ＵＲＬにストアされた情 報は、ＵＲＬの目標が明らかに外部サーバシステムであっても、ＵＲＬの選択時 にサーバシステム１６に返されて与えられる。次いで、リダイレクト応答がサー バシステム１６によりクライアントシステム１２に与えられ、対応するリダイレ クトＵＲＬを与える。 図２に示されるように、サーバシステム１６はサーバシステム１６内のネット ワークインターフェース２２へのネットワーク接続２０を介してリダイレクトリ クエスト情報を受領する。ネットワークインターフェース２２は内部バス２４を 介して中央処理ユニット（ＣＰＵ）２６に接続される。ＣＰＵ２６は、ネットワ ークインターフェース２２及びサーバシステム１６のその他の機能面をサポート するため、ネットワークオペレーティングシステム２８を実行する。ネットワー クオペレーティングシステム２８は、ネットワーク２０を介して受領したＨＴＴ Ｐリクエストへのサーバシステム１６の応答動作を定めるＨＴＴＰｄサーバアプ リケーション３０のＣＰＵ２６による実行をサポートする。最後に、ネットワー クオペレーティングシステム２８は、通常のハードディスクドライブにより与え られるような持続型記憶メディアを含むことが好ましい大容量記憶装置３２にデ ータを一時的及び持続的にストアする。 本発明の好ましい実施の形態に従えば、ＵＲＬのＨＴＴＰリクエストの一部と して与えられる前記埋込リダイレクト情報はＨＴＴＰｄサーバ３０によって処理 される。ＨＴＴＰｄサーバ３０による処理は、外部ＣＧＩプログラム等のいずれ かの実行とは対照的に、サーバ３０自体の実行により行われることが好ましい。 前記リダイレクト情報は、リダイレクト情報を与えた特定のＵＲＬ名を識別し有 効性を確認するために、またリダイレクト目標ＵＲＬを発生させるために、サー バ３０の実行により処理される。 本発明の好ましい実施の形態においては、リダイレクト情報を含む埋込ＵＲＬ は次のようにフォーマットされる： 埋込ＵＲＬのdirect_server部はクライアントシステム１２により初めに確立 されるべきトランザクションの目標ＨＴＴＰサーバを指定する。残りの情報は、 トラッキングサーバ、すなわち直接目標サーバに与えられる。この直接サーバは 、本発明に従う送達リダイレクトリクエストに指定された、クライアントシステ ム１２によりアクセス可能なＨＴＴＰｄサーバのいずれであってもよい。 前記埋込リダイレクトＵＲＬにある“redirect”という用語は、前記ＵＲＬが 本発明に従うリダイレクトリクエストに対応することを特定するため、ＨＴＴＰ ｄサーバ３０に前もって識別されるキーワードである。“redirect”という用語 が好ましい用語であるが、リダイレクトＵＲＬを指定するためにＨＴＴＰｄサー バ３０により唯一識別され得る用語であれば、いかなる用語またはコードを選択 してもよい。用語“redirect”の認識処理は、対応する修正をＨＴＴＰｄサーバ アプリケーションに施して、サーバ３０の実行により行われることが好ましい。 すなわち、ＨＴＴＰｄサーバアプリケーションは、用語“redirect”をキーワー ドとして認識してこの好ましい実施の形態のサーバ側プロセスを実施するための サブプログラムを実行するように、修正される。あるいは、ＨＴＴＰｄサーバア プリケーションの修正は、実質的に同じ機能を得るためにＨＴＴＰｄサーパアプ リケーションに備えられる通常のインターフェースを介して動作し得る“プラグ イン”バイナリプログラムとして実施することもできる。代わりに、ジャバ（Ｊ ａｖａ）（登録商標）またはジャバスクリプト（ＪａｖａＳｃｒｉｐｔ）（登録 商標）のようなサーバアプリケーション埋込言語も、おそらく性能は低いが、キ ーワード“redirect”を認識し、本発明を実施するためにさらに処理を行う、サ ーバ側プロセスの実施に用いることができる。 前記リダイレクトＵＲＬの“data”という用語は、ＨＴＴＰｄサーバ３０への リダイレクトＵＲＬをさらに識別しおそらく有効性を確認するために用い得る、 照会識別子データをＨＲＲＰｄサーバ３０に与える。すなわち前記データにより ＨＴＴＰｄサーバ３０はリダイレクトＵＲＬのアカウントを行うことができる。 宣伝広告関係においては、前記データは、アクセスデータを保存したい特定の広 告主、リダイレクトＵＲＬにともなってグラフィックイメージがクライアントシ ステム１２に与えられる特定の時刻、及び、おそらくは、不適切なクライアント によるリダイレクトＵＲＬの使用をＨＴＴＰｄサーバ３０が確実に弁別して捨て 去ることができるようにするために提供される有効性確認コードも、エンコード することができる。 本発明の好ましい実施の形態に従い、ＨＴＭＬを用いて構成された、リダイレ クトＵＲＬの典型例は、以下の通りである： 上記リダイレクトデータの中で、データ要素“NwPg”はクライアントまたはア カウント識別子としてはたらく。データ要素“003”はクライアントシステム１ ２に提供されたウエッブページに埋め込まれた、リダイレクトＵＲＬにともなう 特定のグラフィックイメージを示す連番識別子である。最後に、データ要素“AA ”は、不適切に繰返されるサーバシステム１６へのリダイレクトＵＲＬ要請ある いは協定により今は廃止されていると決定される要請を、ＨＴＴＰｄサーバ３０ が識別できるようにするようにはたらく基本的な有効性確認識別子を提供するた めに利用することができる。 本発明の別の実施の形態において、前記有効性確認データはリダイレクトＵＲ Ｌを要請したクライアントシステム１２に関する情報を与えるためにＨＴＴＰプ ロトコルとともに用い得るデータ表現及び、オプションとして、定められた短時 間内の同じクライアントシステム１２によるリダイレクトＵＲＬの繰り返し使用 を制限するためのグラフィックス連番識別子データをエンコードする。すなわち 、サーバシステム１６により収集されるいずれか特定のリダイレクトＵＲＬに関 するデータを事実上改竄するためのサードパーティークライアントによる不適切 な試みは、完璧ではないにせよある程度は確実に識別されてブロックされる。さ らに、ある時間より前のデータコードをコンピュータにより無効であると宣告す ることができる。従って埋込リダイレクトＵＲＬのコピーは、クライアントシス テム１２にストアできず、サーバコンピュータシステム１６により排他的に定め られる時間より長く使用が可能なままでいることはない。 リダイレクトＵＲＬ内のデータ項のそれぞれは、埋込リダイレクトＵＲＬをも つウエッブページをクライアントコンピュータシステム１２に最初に提供するプ ロセスの一部として、静的または動的に、ＨＴＴＰｄサーバ３０により生成され る。動的生成により、単一の広告主あるいは広告主数がどれだけであってもその 中の１つに対応する相異なるグラフィックイメージを、それとは別に静的に定め られたウエッブページとともに有効に提供できる。埋込リダイレクトＵＲＬのデ ータ項は、ＨＴＴＰｄサーバ３０による特定のウエッブページの提供と同時に行 われるグラフィックイメージへの別のハイパーリンクの確立に加えて、広告主の 識別情報及び前記グラフィックイメージに基づいて動的に選択される。実際、広 告主及びグラフィックイメージの選択は、少なくとも部分的には、ＨＴＴＰプロ トコルの通常の動作により与えられる情報を介して設定されたクライアントコン ピュータシステム１２の識別情報、及び知られていればクライアントプロフィー ルに基づいてなされる。 有効性確認コードも動的に生成できる。本発明の別の実施の形態において、有 効性確認コードは、埋込リダイレクトＵＲＬが日替りで加齢してゆくことができ るだけの十分な特有性を与える、２桁の数字にエンコードされることが好ましい 、識別子を生成するために、アカウント及びイメージ識別子データ項とともに、 年月日表示をエンコードする。さらに有効性確認コードは日替りベースで一定の ままであり、よって、１日あたり及び特定のクライアント１２あたりでの照会数 もまた、ウエッブページの特定のインスタンシエーションが特定のクライアント １２に繰り返し送られる頻度を制限するように、ＨＴＴＰｄサーバ３０がトラッ キングすることができる。さらにまたＨＴＴＰｄサーバ３０は、受領したリダイ レクトＵＲＬに関して、対応するウエッブページがリクエスト中のクライアント １２に最近は提供されていない場合には、ブロック操作を行うことができる。 様々なビットシフト、チェックサム、及びモジューロ算法アルゴリズムが、Ｈ ＴＴＰｄサーバ３０に知られる無矛盾の方法で有効性確認コードを生成するため に利用され得るが、得られるリダイレクトＵＲＬを特定のクライアントコンピュ ータシステム１２が調べて有効性確認コードを見分けることは容易にできること ではない。あるいは有効性確認コードは、１日から数週間あるいはさらに長いプ ログラム可能な期間、ＨＴＴＰｄサーバ３０により有効であると暗示的に認識さ れる、任意に選択された値であってもよい。極端な場合に、有効性確認コードは 埋込リダイレクトＵＲＬの一部として与えられる静的値であり、これは初めに述 べた本発明の好ましい実施の形態と一致する。 有効性確認コードが生成される特定の方法あるいはコードがＨＴＴＰｄサーバ ３０により有効であると認識される期間の指定された長さとは無関係に、リダイ レクトＵＲＬのデータ項の評価はＨＴＴＰｄサーバ３０で完全に内部的に行われ ることが好ましい。データ項は埋込リダイレクトＵＲＬの特定のインスタンシエ ーションの識別において、外部プログラムのロード及び実行手段あるいは持続型 記憶装置３２にストアされたルックアップファイルに問合せる手段でさえ、もし あったとしてもこれを用いる必要のない、曖味さをもたない十分完全なものであ ることが好ましい。従って、本発明に従うリダイレクトＵＲＬ評価の負担は本質 的にほとんど全てがコンピュータにかかる。通常理解されているように、サーバ コンピュータシステム１６の性能は一般にコンピュータには支配されず、むしろ 持続型記憶装置３２及びネットワーク２０への入出力（Ｉ／Ｏ）アクセス速度に 支配される。リダイレクトＵＲＬと関連して得られるオーディットまたはアカウ ントデータのセーブにのみＩ／Ｏ動作を限定するととともに、リダイレクトＵＲ Ｌの評価をコンピュータ動作に完全にではなくとも実質的に制限することにより 、サーバコンピュータシステム１６の負担の最適最小化が本発明の実施により実 現される。実際、セーブされるアカウントまたはオーディットデータをネットワ ークオペレーティングシステム２８でキャッシュしておいて、サーバコンピュー タシステム１６上で進行中の作業において余分のＩ／Ｏバンド幅が利用できるよ うになるまで、持続型記憶装置３２への書込Ｉ／Ｏ作業を延期することができる 。 リダイレクトＵＲＬの好ましい構造の最後の要点は、第２ＵＲＬである。この 第２ＵＲＬはリダイレクトのための目標サーバを直接識別することが好ましい。 好ましくは、リダイレクトＵＲＬの直行サーバ指定部として与えられるいかなる パス部も、リダイレクトＵＲＬのリダイレクトサーバ部のパス要素として繰り返 される。しかし、パス部の同一性は必要とされない。一般に、本発明により要請 されることは、前記直行サーバとリダイレクトＵＲＬのリダイレクトサーバ項と の１対１の対応だけである。本発明の実施により集められるオーディットまたは アカウントデータへの影響がそれらのデータに求められる特性と矛盾しなければ 、より束縛の緩い関係を用いることもできる。例えば、相異なる直行サーバ指定 を、埋込リダイレタトＵＲＬの特定のインスタンシエーションをさらに識別する 手段として、共通リダイレクトサーバの使用と相互に関連付けることかできる。 あるいは、埋込リダイレクトＵＲＬの何か別の同様なインスタンシエーションが 多くのリダイレクトサーバのいずれかを照会してもよい。すなわち埋込リダイレ クトＵＲＬは、最終的に提供を行うリダイレクトサーバへの間接名のみを与える か、 あるいは最終的に提供を行うリダイレクトサーバへの直接名に第２ＵＲＬを変換 するために、前記direct_serverで識別されたサーバシステムまたはリダイレク トサーバ自体に依存する。これは、共同して動作しているリダイレクトサーバに 負荷を分散するか、あるいは進行中の本発明の実施により集められるオーディッ トまたはアカウントデータを検証するための手段を与えるためになされる。実際 、リダイレクトＵＲＬの第２ＵＲＬは、無限リダイレタトループをつくらないよ うに注意を払う必要はあるが、自身がリダイレクトＵＲＬとなることもできる。 クライアントコンピュータシステム１２によりサーバコンピュータシステム１ ６に与えられたリダイレクトＵＲＬの好ましい処理方法４０が図３に示される。 各クライアントからのリクエストが受領される（ステップ４２）と、そのリクエ ストにリダイレクトキーワードが埋め込まれているか否かを決定するためにその リクエストの一部として与えられるデータが検査される（ステップ４４）。前記 ＵＲＬデータが本発明に整合しないリダイレクトリクエストを指定していなけれ ば、ＵＲＬデータが現存のローカルウエッブページを通常通りに指定しているか 否かを決定するためにＵＲＬデータがチェックされる（ステップ４６）。前記ウ エッブページが存在しないか、あるいはクライアントのＵＲＬリクエストに関連 するＨＴＴＰプロトコルを介して提供されるクライアント識別データに基づいて 、ある特定のクライアントが前記現存のウエッブページへのアクセスを拒否され る場合は、ＨＴＴＰｄサーバ３０は対応するエラーメッセージをクライアントコ ンピュータシステム１２に返すことを決定する（ステップ４８）。そうでなけれ ば、ＨＴＴＰｄサーバ３０は作業を続け、クライアントコンピュータシステム１ ２にローカルウエッブページを提供する（ステップ５０）。 ＵＲＬデータが少なくともリダイレクトリクエストを指定している場合は、そ のＵＲＬデータの有効性がさらにチェックされる（ステップ５２）。サーバシス テム１６のメモリにキャッシュされることが好ましいクライアントとグラフィッ クイメージ識別子の有効組合せ表を、リダイレクトリクエストの有効性を最初に 確認するために用いることができる。有効性確認コードも、与えられたリダイレ クトデータに基づく再計算によりチェックされるか、あるいは別の現行有効性確 認コード表と対照してチェックされる。いずれの場合にも、リダイレクトリクエ ストの相対タイムラインが前記有効性確認コードの持続日数から定められ、よっ て現時点でのリダイレクトリクエストか時間的に合っているかあるいは疑わしい かを決定するための基礎としてはたらく。さらに、リクエストを行っている特定 のクライアントコンピュータシステム１２にサーバコンピュータシステム１６に より対応するウエッブページが実際に最近提供されていることを検証するために 、サーバコンピュータシステム１６により実際に提供されたローカルウエッブペ ージの短期記録に基づいてさらにチェックを行うこともできる。最後に、サーバ コンピュータシステム１６により実施されるアクセス許可が、定められたクライ アント階級へのリダイレタトをカテゴリー毎に制限するために、クライアントコ ンピュータシステム１２の識別情報に対照してチェックされる。前記リクエスト がいずれの理由にせよ無効であると決定されると、適切な拒否メッセージが生成 され発行される（ステップ４８）。 リダイレクトリクエストが有効であると決定されると、リダイレクトリクエス トの一部として提供されるかあるいはＨＴＴＰプロトコルの通常動作を介してＨ ＴＴＰｄサーバ３０に提供されるデータのいずれかまたは全てが、以降の操作、 解析及びレポート出力のためにネットワークオペレーティングシステム２８を介 して持続型記憶装置３２に記録される。リダイレクトリクエストは次いで、リダ イレクト目標サーバ５６を識別する第２ＵＲＬを得るためにさらに処理される。 この第２ＵＲＬは次いで、リダイレクトメッセージ、好ましくは一時的リダイレ クトメッセージのロケーションフィールドに指定され、このメッセージは初めに リダイレクトＵＲＬを発行したクライアントコンピュータシステム１２に向けて 発行される（ステップ５８）。 本発明の好ましい実施の形態に従う処理４０は、実質的に全てがＨＴＴＰｄサ ーバ３０内で行われる。処理４０の実施は、ＨＴＴＰｄサーバ３０により実施さ れる処理の流れを修正及び拡張し、対応するサーバソースコードを修正すること により行うことができる。これらの修正及び付加は通常のプログラミング手法を 利用して行うことができる。 本発明により提供されるリダイレクト能力は、通常のＨＴＴＰｄサーバにより 提供されるデファクトスタンダードの現存リダイレクト能力と完全に整合する。 処理４０のさらに詳細な部分６０が図４に示される。ＨＴＴＰｄサーバ３０の作 業内で、ＵＲＬデータが受領され（ステップ６２）、まずリダイレクトキーワー ドが適切に存在するかを識別するために解析される（ステップ６４）。本発明の 特定の形式のリダイレクトＵＲＬが識別されなければ（ステップ６６）、その他 のいずれかのリダイレクト形式が適用可能であるか否かを決定するために、この ＵＲＬは通常の方法でさらに処理される。さらに、通常のリダイレクト指定をも たないローカルウエッブページへの通常のアクセス特権の評価もなされて、最終 的に、適切な応答メッセージが発行される（ステップ６８）。 ＵＲＬリクエストが本発明と一致する特別なリダイレクト形式をもっている特 定の場合には、通常のＨＴＭＬリダイレクト能力とは対照的に、このＵＲＬデー タが処理され（ステップ７０）、クライアントコンピュータシステム１２を識別 するＨＴＴＰプロトコル提供データとともに、ステップ７２でデータベースレコ ードが持続型記憶装置３２につくられるかまたは更新される。次いで第２ＵＲＬ が抽出されて（ステップ７４）、リダイレクトメッセージ、特に３０２タイプの 一時的リダイレクトメッセージが作成される。前と同様に、第２ＵＲＬは直行ま たはリテラルＵＲＬであるか、あるいはＨＴＴＰｄサーバ３０により少なくとも リダイレクト目標サーバを識別するに十分なＵＲＬに変換することができる間接 リダイレクト目標サーバ識別情報である。ウエッブページに埋め込まれた第２Ｕ ＲＬはＨＴＴｐｄサーバ３０の作業による前準備で定められるので、いずれの間 接リダイレクト目標サーバ識別情報の変換も、例えばデータベースルックアップ 作業により、ＨＴＴＰｄサーバ３０によって完全に決定される。 次いでロケーションフィールドを含むリダイレクトメッセージがＨＴＴＰｄサ ーバ３０により生成される。このロケーションフィールドには前記直接ＵＲＬま たは変換されたリダイレクト目標サーバＵＲＬが与えられる。次いでこのリダイ レクトメッセージは、初めにリクエストしたクライアントコンピュータシステム １２に発行される（ステップ５８）。 その他のサーバ側で動作し得る本発明の実施の形態は、トラッキング情報をク ライアントシステム１２からＨＴＴＰｄサーバ３０に伝送するためにその他の特 定のプロトコルを用いることができる。これらその他のＨＴＴＰプロトコル命令 には、例えばＧＥＴ，ＦＯＲＭＳ，ＯＰＴＩＯＮＳ，ＨＥＡＤ，ＰＵＴ，ＤＥＬ ＥＴＥ，及びＴＲＡＣＥがある。これらその他のプロトコル命令の使用方法は、 プロトコル命令及びウエッブページへのそれらの特定のＨＴＭＬマークアップコ ーディングの詳細に関して特定のブラウザをサポートするために必要な使用方法 とは異なり、一般的に同じである。 上記その他のプロトコル命令の使用法の一例として、クライアントコンピュー タシステムに提供されるウエッブページに以下のＨＴＭＬコードタグを埋め込む ことにより、ＨＴＴＰ ＧＥＴ命令を実行できる。 このＨＴＭＬコードは“MTCH1073.gif”をウエッブページシンボルグラフィック として、“www.infoseek.com”を直接ＵＲＬとして、“MTCH-2009-1073-GEN”を データとして、また“www.match.com”をリダイレクト目標サーバとして定める 。 上記ＨＴＭＬタグがクライアントコンピュータシステムに提供されると、初め のＨＴＴＰ ＧＥＴリクエストがシンボルグラフィックを得るために“www.onli ne.com”に発行される。シンボルクリックに応答して、第２のＧＥＴリクエスト がＵＲＬ： を用いて“www.infoseek.com”に向けられる。ＧＥＴリクエストの完全な形は： である。 ＨＴＴＰサーバ３０は（クッキーのような）ＭＩＭＥ情報及び形状変数（この 場合はａｋ及びｒｄ）の値を記録する。次いで、ＨＴＴＰリダイレクトメッセー ジがＨＴＴＰサーバ３０により生成されてクライアントコンピュータシステムに 返される。次いで、第３で最終のＧＥＴリクエストが前記リダイレクトメッセー ジに応答して“www.match.com”に発行される。 別の例として、ＨＴＴＰ ＰＯＳＴ命令を用いることができる。ＨＴＭＬタグ が埋め込まれたウエッブページは以下のようにコード化される。このＨＴＭＬコードにより、前記シンボルグラフィックを取り込むために“www. online.com”にＧＥＴリクエストが自動的に発行される。シンボルクリックによ り、ＨＴＴＰ ＰＯＳＴリクエストが前記ＦＯＲＭ ＮＡＭＥ及びＶＡＬＵＥデ ータと一緒に“www.infoseek.com”に送られる。この場合、前記データはＵＲＬ にエンコードされず、むしろＰＯＳＴリクエスト自体の中にエンコードされる。 この例において、ＰＯＳＴリクエストは： という形をもつであろう。前記返されたりダイレクトメッセージが受領されると 、クライアントコンピュータシステムにより別のＧＥＴリクエストが、同じく“ www.match.com”であるリダイレクト目標サーバに発行される。 本発明に従えば、クライアント側プロセスもクライアントコンピュータシステ ムによるウエッブページ要素選択の通知を見えない形で提供するために利用でき る。図５は、本発明を実施するサーバ側及びクライアント側プロセスのいずれに も関わるデータ伝送の流れの表示７８を与える。サーバ側及びクライアント側で のプロセス実施のいずれにも共通して、クライアントコンピュータシステム８０ が最初のウエッブページリクエストを（図示していない）インターネットでウエ ッブページサーバシステム８２に発行する。ウエッブページ要素８６を含む対応 するウエッブページ８４がクライアントコンピュータシステム８０に返される。 同じく、サーバ側及びクライアント側での本発明のプロセス実施のいずれにも 共通して、ウエッブページ要素８６がウエッブページ８４への情報埋込により与 えられる。図６に大要を示すサーバ側プロセス環境においては、シンボルクリッ ク（ステップ９６）に続く本発明のプロセスによりクライアントブラウザが動作 する。特に、前記埋め込まれた情報が、図５に示すように、リダイレクト目標サ ーバシステム８８に向けて通知ＵＲＬを発行する（ステップ９８）に十分なクラ イアントコンピュータシステム上のウエッブブラウザの動作を管理する。前記通 知ＵＲＬの受領に応答して開始されるサーバ側プロセスは、クライアントコンピ ュータシステム８０に返されるリダイレクトメッセージを生成する（ステップ１ ００）。このリダイレクトメッセージ生成に関連して、サーバシステム８８もス テップ９８で発行された通知ＵＲＬの一部として受領したデータを記録して、随 意に処理する。 次いで、前記リダイレクトメッセージに基づき、クライアントコンピュータシ ステム８０がリダイレクトメッセージに含まれる情報に基づくＨＴＴＰリクエス トを発行する（ステップ１０２）ことが好ましい。図５を再び参照すると、ステ ップ１０２で発行されたＨＴＴＰリクエストが、クライアントコンピュータシス テム８０に前記ウエッブページ要素８６から演繹して照会されたウエッブページ としてウエッブページ９２を提供することにより通常の方法で応答する別のウエ ッブページサーバシステム９０にインターネット１４を介して提供される（ステ ップ１０４）。 クライアント側プロセスを利用する本発明の方法の大要が図７に示される。こ こでの例を説明する目的のため、本方法１０６はシンボルクリック（ステップ１ ０８）に応答して開始され、クライアントコンピュータ８０上のウエッブブラウ ザの動作と関連してクライアントプロセス１１０の実行を開始する。本発明の好 ましい実施の形態においては、クライアントプロセス１１０はクライアントコン ピュータシステム８０へのウエッブページ８４とともに与えられる。クライアン トプロセス１１０はシンボルクリックに応答して呼び出され、第１に通知ＵＲＬ メッセージを発行する（ステップ１１２）ために、また第２にＨＴＴＰリクエス トを発行する（ステップ１１４）ために作動する。いずれのメッセージも、イン ターネット１４を介して、それぞれ目標サーバシステム８８及びウエッブページ サーバ９０に発行される。クライアントプロセス１１０が通知ＵＲＬ１１２及び ＨＴＴＰリクエスト１１４を発行する順序は重要ではない。さらに、目標サーバ システム８８からの通知ＵＲＬ受領の確認がなくとも、ＨＴＴＰリクエスト１１ ４を発行することができる。実際、クライアントコンピュータシステム８０のユ ーザには明らかなように、重要であると認められる唯一の応答はウエッブページ ９２を受領する（ステップ１１６）ことである。 サーバ側プロセスの場合と同様に、クライアント側プロセス１１０は、本発明 の目的のため多くの相異なる方法で実施され、いずれの方法も、目標サーバシス テム８８にデータを送付し、ウエッブページ要素８６との前もって準備された対 応を有するウエッブページ９２を提供するためのウエッブページサーバシステム ９０にＵＲＬリクエストを送付する。特に、クライアント側プロセスはブラウザ アプリケーション内に直接コード化されるか、あるいは通常のブラウザアプリケ ーションへのブラウザプラグインとして供給される。クライアント側プロセスは また、ジャバ及びジャバスクリプトタイプのアプレットを用いて実施することも できる。 クライアント側プロセスの典型例はジャバアプレットを用いて実施される。本 例のための、ウエッブページ８４に埋め込まれるＨＴＭＬコードは、以下の通り である： ここで上記３つのアプレットパラメータは以下のように定義される： “img” −広告グラフィックシンボルへのＵＲＬ名 “notifyurl” −アカウントデータを保持する“通知”ＵＲＬ “pageurl” −利用する“リダイレクト”ＵＲＬ アプレットソースは以下の通りである： 上例は、第１に“notifyurl”メッセージを発行し、第２に“pageurl”メッセ ージを発行するために２つのＨＴＴＰリクエストを使用している。しかし、その 他の様々なプロトコルを本発明とともに用いることができる。例えば、上記ジャ バアプレットはＴＣＰ接続を用いて目標サーバシステム８８に通知データを与え るように修正できる。ＴＣＰ接続を利用するアプレットの典型的実施例を以下に 示す。このアプレットは４つのパラメータ： “img” −表示する広告（ａｄ）イメージのＵＲＬ “port” −目標サーバ上で使用するＴＣＰポート番号 “data” −目標サーバに送付するアカウントデータ “pageurl” −利用する“リダイレクト”ＵＲＬ をとる。 アプレットソースは以下の通りである： 最後に、上記のアプレットはウエッブページ８４に以下のＨＴＭＬコードを埋 め込むことにより実行のために照会することができる。 以上、ハイパーリンクされた外部サーバに対してクライアントコンピュータシ ステムによりなされるアクセスをアカウントまたはオーディットするための包括 的なシステム及び方法を説明した。本システムのプロセスのオーディット能力は 、集められたデータが有効であることを確認でき、またリダイレクト目標サーバ システムへの善意のアクセスに対応することが合理的に保証できる一方で、リダ イレクトサーバシステムには最適最小のオーバーヘッドしか負わせない。 本発明を、特に本発明の好ましい実施の形態を参照して示しまた説明したが、 本発明の精神及び範囲を逸脱することなく前記実施の形態の形式及び詳細には様 々な変更をなし得ることは、同業者には当然であろう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ

Claims (1)

1. 【特許請求の範囲】 １．トラッキングを行うサーバシステムの外部にあるリソースに対応する既定の リソースロケータを照会しているクライアントシステムに応答して前記サーバ システムにメッセージを提供する方法において、前記方法が： ａ）クライアントシステムに前記クライアントシステムによる選択が可能な 情報要素を与える工程；前記情報要素は第１のリソースロケータの使用により 第１のサーバシステムから得られた情報コンテンツと前記クライアントシステ ム上でグラフィカルに結びつけられ、また前記情報要素は第２のサーバシステ ムを照会している第２のリソースロケータ及び前記情報要素を識別しているデ ータを含む； ｂ）前記情報要素の前記選択に応答して前記第２のサーバシステムに前記デ ータを提供するために前記第２のリソースロケータを前記クライアントシステ ムに使用させる工程；及び ｃ）前記情報要素の前記選択に応答して前記第１のサーバシステムから前記 情報コンテンツを得るために前記第１のリソースロケータを前記クライアント システムに使用させる工程； を含むことを特徴とする方法。 ２．前記第１のサーバシステムから前記情報コンテンツを得るために前記第１の リソースロケータを使用する工程、及び前記第２のサーバシステムに前記デー タを提供するために前記第２のリソースロケータを使用する工程を、前記情報 要素の前記選択に応答して前記クライアントシステムが自律的に進めることを 特徴とする請求の範囲第１こう記載の方法。 ３．前記データの受領に応答して前記第１のリソースロケータを前記クライアン トシステムに提供する工程をさらに含むことを特徴とする請求の範囲第２項記 載の方法。 ４．前記クライアントシステムによる前記情報要素の前記選択に応答してクライ アントプロセスを実行させる管理プログラムを前記クライアントシステムに提 供する工程をさらに含むことを特徴とする請求の範囲第２項記載の方法。 ５．前記データが前記情報要素を識別するに十分なアカウントデータを含むこと を特徴とする請求の範囲第３項または第４項のいずれかに記載の方法。 ６．クライアントコンピュータシステムのユーザによるウエッブページシンボル のクリックを介した、対応するウエッブページへの照会の発生をトラッキング する方法で、前記発生が前記クライアントシステムユーザには見えない形でト ラッキングコンピュータがトラッキングする方法において、前記方法が： ａ）既定のクライアントコンピュータシステムにウエッブページ要素を提供 し、よって前記既定のクライアントコンピュータシステムの前記ユーザによる 前記ウエッブページ要素の選択を可能とする工程；前記ウエッブページ要素は コンテンツプロバイダコンピュータシステムと結びつけられる；及び ｂ）前記ウエッブページ情報に関連して前記クライアントコンピュータシス テムにより維持されるように既定のトラッキング情報を前記ウエッブページ要 素とともに前記既定のクライアントコンピュータシステムに提供し、よって前 記既定のクライアントコンピュータシステムの前記ユーザによる前記ウエッブ ページの選択に応答して、前記トラッキングコンピュータシステムにトラッキ ングデータを提供し、また前記コンテンツプロバイダコンピュータシステムに コンテンツリクエストを提供するために前記既定のトラッキング情報が前記ク ライアントコンピュータシステムにより自動的に用いられる工程； を含むことを特徴とする方法。 ７．前記ウエッブページ要素が前記既定のクライアントコンピュータシステムの 前記ユーザに入手できるコンテンツを識別し、前記コンテンツリクエストが前 記既定のクライアントコンピュータシステムにより前記既定のトラッキング情 報とともに維持されることを特徴とする請求の範囲第６項記載の方法。 ８．前記ウエッブページ要素の選択により、前記トラッキングコンピュータシス テムに前記既定のトラッキング情報を提出し、前記コンテンツプロバイダコン ピュータシステムに前記コンテンツリクエストを提出する、クライアント側プ ロセスが開始されることを特徴とする請求の範囲第７項記載の方法。 ９．前記コンテンツプロバイダコンピュータシステムの識別情報を前記既定のク ライアントコンピュータシステムに提供するために前記トラッキングコンピュ ータシステムが前記既定のトラッキング情報を処理し、前記既定のクライアン トコンピュータシステムが前記コンテンツプロバイダコンピュータシステムに 前記コンテンツリクエストを提出するために前記識別情報を用いることを特徴 とする請求の範囲第８項記載の方法。 10．前記クライアント側プロセスが前記トラッキングコンピュータシステムへの 前記既定のトラッキング情報の提出及び前記コンテンツプロバイダコンピュー タシステムへの前記コンテンツリクエストの提出を自律的に行い、前記コンテ ンツリクエストは前記コンテンツプロバイダコンピュータシステムに前記コン テンツリクエストを提出するに十分な前記コンテンツプロバイダコンピュータ システム識別情報を含むことを特徴とする請求の範囲第８項記載の方法。 11．前記既定のクライアントコンピュータシステムが前記ウエッブページ要素を 受領して処理するためにブラウザアプリケーションを実行し、前記クライアン ト側プロセスは前記ブラウザアプリケーションによる管理スクリプトの実行に よってなされることを特徴とする請求の範囲第１０項記載の方法。 12．前記既定のクライアントコンピュータシステムが前記ウエッブページ要素を 受領して処理するためにブラウザアプリケーションを実行し、前記クライアン ト側プロセスは前記ブラウザアプリケーションに結合されたプラグイン管理プ ログラムの実行によってなされることを特徴とする請求の範囲第１０項記載の 方法。 13．前記既定のクライアントコンピュータシステムが前記ウエッブページ要素を 受領して処理するためにブラウザアプリケーションを実行し、前記クライアン ト側プロセスは前記ブラウザアプリケーションの管理の下に前記既定のクライ アントコンピュータシステムにより実行されるアプリケーションプログラムに よってなされることを特徴とする請求の範囲第１０項記載の方法。 14．ウエッブページサーバコンピュータシステムによりクライアントコンピュー タシステムに提供されるウエッブページ上に与えられた広告シンボルのクリッ クによる選択をトラッキングする方法において、前記方法が： ａ）クライアントコンピュータシステムにより実行されるブラウザアプリケ ーションに既定のページ要素を含むウエッブページを提供する工程；前記ウエ ッブページはエンコードされた既定のアカウントデータ及び前記既定のページ 要素とともに前記クライアントコンピュータシステムによりストアされるウエ ッブページサーバコンピュータシステム識別情報を含む；及び ｂ）前記クライアントコンピュータシステムのユーザによる前記既定のペー ジ要素の選択に基づいて前記ブラウザアプリケーションとともにクライアント 側プロセスを実行する工程；前記クライアント側プロセスはオーディットコン ピュータシステムに前記エンコードされたアカウントデータを伝送し、また前 記識別情報に一致する前記ウエッブページサーバシステムに既定のウエッブペ ージリクエストを発行する； ことを特徴とする方法。