JP4763748B2

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

Info

Publication number: JP4763748B2
Application number: JP2008098792A
Authority: JP
Inventors: スティーブンティーキルシュ，; クリストファージェイリンドブラッド，
Original assignee: Rakuten Inc
Current assignee: Rakuten Group Inc
Priority date: 1998-05-01
Filing date: 2008-04-04
Publication date: 2011-08-31
Anticipated expiration: 2019-04-28
Also published as: US9497255B2; US6466966B1; US20050125416A1; JP4851636B2; US20120198072A1; DE69926459D1; EP0993726A1; JP2008226260A; US6189030B1; US6859833B2; JP4212124B2; US20150195331A1; US8543662B2; US20060253452A9; AU754298B2; US20140040348A1; CA2294935C; ES2247800T3; EP0993726B1; AU3769699A

Description

本発明は全般的にはワールドワイドウエッブ（ＷｏｒｌｄＷｉｄｅＷｅｂ）ベースのデータページをサポートするネットワーク情報サービスシステムの管理に関し、特に、外部サーバへのハイパーリンク参照を管理し、節度を保たせ、またそのような参照をアカウントする目的で、効率よくリダイレクトするためのサーバシステム及びプロセスに関する。

関連技術の説明

インターネットとして一般に知られる国際的に接続されたネットワークの近年の大幅な成長及び利用の拡大は、主としてハイパーテキスト伝送プロトコル（ＨＴＴＰ）の広範なサポートによっている。このプロトコルにより、インターネットサービスプロバイダ（ＩＳＰ）を介して接続されたクライアントシステムが、同様にインターネットに接続された地理的に散在する個々のサーバシステムにアクセスできる。ネットスケープ・コミニュケーションズ社（ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓＣｏｒｐ．）のネットスケープ・モジラ（Ｍｏｚｉｌｌａ）（登録商標）及びナビゲーター（Ｎａｖｉｇａｔｏｒ）（登録商標）、マイクロソフト・インターネットエクスプローラ（ＭｉｃｒｏｓｏｆｔＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ）（登録商標）並びにＮＣＳＡモザイク（Ｍｏｚａｉｃ）（商標）のようなクライアント側ブラウザは、ＨＴＴＰプロトコルのクライアント側部分を実行する、効率のよいグラフィカル・ユーザインターフェースベースのクライアントアプリケーションを提供する。

ＨＴＴＰサーバと総称される、サーバ側のアプリケーションプログラムはＨＴＴＰプロトコルのサーバ側部分を実行する。ＨＴＴＰサーバアプリケーションは、ネットスケープのような会社から市販品として入手でき、またＮＣＳＡからソースコードで著作権付フリーウエアとしても入手できる。
ＨＴＴＰプロトコルにより可能となった分散型通信及び情報伝送システムは、一般にワールドワイドウエッブ（ＷＷＷまたはＷ３）として、あるいは単に“ザ・ウエッブ”として知られる。クライアント側のユーザインターフェースから見ると、国際統一リソースロケータ（ＵＲＬ）システムが指名されたウエッブサーバコンピュータシステムとの個別的階層におけるトランザクション交信セッションをウエッブブラウザに確立させるために用いられる。各ＵＲＬの基本型は一般に：

http://<サーバ名>.<サブドメイン名.最上位ドメイン名>/<パス名>

である。サーバ名は通常“ｗｗｗ”であり、サブドメイン名.最上位ドメイン名は標準的なインターネットドメイン参照である。パス名はオプションで付加されるＵＲＬクオリファイアである。

クライアント側でユーザがＵＲＬを選択して特定することにより、クライアントがハイパーテキストマークアップ言語（ＨＴＭＬ）によって構成されたデフォールトの、または明示的に名付けられたデータファイルを参照するＨＴＴＰメッセージをサーバに送信するトランザクションが確立される。このデータファイルすなわちウエッブページは、サーバによる１つ以上の応答フェーズＨＴＴＰメッセージとして返され、一般にはクライアントブラウザによりディスプレイ表示される。付加された埋込イメージ参照が前記返されたウエッブページ内で照合され、引き続いて、通常は埋め込まれているグラフィックファイルを取り込むためのＨＴＭＬトランザクションをクライアントブラウザが開始する。次いで、完全に再構成されたウエッブページイメージがブラウザのグラフィカル・ユーザインターフェースを介してブラウザにより提示される。

インターネットの現存の名称識別サービス及びルート選択協定によってさらにサポートされたＵＲＬシステムによって可能となったウエッブの完全分散型クライアント／サーバ・アーキテクチャにより、ほとんど困難なくＨＴＴＰサーバが個々に設立される。従ってウエッブは、最上位ドメイン名による緩やかな束縛以外、中央のあるいは地域的なものであってさえ集中施行機関をもたない。ゆえに、ほとんど当然のことながら個々のＨＴＴＰサーバにより供給される情報あるいはその他のリソースを検索することが問題となる。包括的であり、しかも効率のよいウエッブ情報及びリソースの検索可能なデータベースを集めて整理するには時間とコストかかかる上に複雑であるため、ウエッブを介して利用できるソースＵＲＬと関連付けられた情報及びリソースの集積に対してはたらきかける検索エンジンサービスをサポートする、一般的には料金ベースのあるいは広告収入が得られる商業的インターネットビジネスサービス（ＩＢＳ）が設立されている。このような検索エンジンへのアクセスは、通常インターネットビジネスサービスにより提供される、サーバローカルウエッブページを介して行われる。検索結果は、インターネットビジネスサービスのサーバにより動的に構成される、適切に埋め込まれたリモートＵＲＬまたはハイパーリンクされたＵＲＬをもつローカルウエッブページの形態で提供される。

クライアントによる検索エンジンアクセス及び検索結果のウエッブページの取込はおそらく何度も繰り返されることから宣伝のチャンスが得られるため、他のインターネットベースサービスのプロバイダはそれぞれのウエッブページに広告を積極的に入れはじめた。広告媒体では一般的であるように、広告主に与えられる代償は通常、広告の表示頻度である。すなわち、クライアントのブラウザに広告が送られた回数だけが、どれだけ有効に宣伝が行われたかの指標となる。特定のウエッブページ上の特定の広告の有効性のより直接的な尺度は、クライアントのウエッブブラウザが広告に表われるＵＲＬをそのウエッブページから積極的に追うことを選択する回数である。よって、ハイパーリンクされた広告主のＵＲＬが選択されたときに、クライアントブラウザから得られる情報をトラッキングすることができなければならない。

ダイレクト参照情報を得る上での困難は、埋め込まれた広告及び対応するリモートＵＲＬをもつウエッブページの全てがそのウエッブページへの最初の参照においてクライアントのブラウザに提供されるという事実から生じる。次いで当然のことながら、特定の広告主のＵＲＬの選択がその広告主と関連するＨＴＴＰダイモン（ＨＴＴＰｄ）サーバに向けられた独立のトランザクションを介して行われる。
広告主が広告を出しているＨＴＴＰｄサーバは上記次段階トランザクションには組み込まれていないので、クライアントブラウザに先に提供されたウエッブページに埋め込まれた広告主のＵＲＬあるいはその他いずれかのＵＲＬに向けて実際に実行されたクライアントブラウザのハイパーリンクを広告が出されたサーバがトラッキングすることは通常は不可能である。

単純なウエッブページアクセスカウンタが比較的よく知られ、ウエッブ全体で用いられている。これらのアクセスカウンタは当今のＨＴＴＰｄサーバシステムにサポートされる共通ゲートウエイインターフェース（ＣＧＩ）機能に基づいている。ＣＧＩ機能により、クライアントのＵＲＬリクエストに応答して、少なくとも通常はファンクションによる、一般的には短いプログラムをサーバが実行することができる。すなわちＨＴＭＬウエッブページ概念規定が、提供されるウエッブページイメージを再構成するウエッブブラウザプロセスの一部としてのサーバ側ＣＧＩプログラムの実行を指定する、特定のＨＴＭＬ参照を埋め込むために与えられる。このようなＨＴＭＬ参照の形式は一般に：

<img src="http://www.target.com/cgi-bin/count.cgi">

である。すなわち、個々別々のＣＧＩプログラム（count.cgi）実行のそれぞれにより増加するカウンタ値により、再構成されたウエッブページの表示可能イメージの一部が動的に与えられる。ＨＴＴＰプロトコルの動作を介して知ることができる、時刻、リモートクライアントリクエスト者、クライアントドメイン、クライアントブラウザのタイプ及びその他の情報はＣＧＩプログラムファンクションの一部として記録することができる。従って、あるウエッブページアクセスについてアカウント及びオーディットを行う手ごろな手段が存在する。

しかしアクセスカウンタは、基本的にサーバローカルウエッブページアクセスのみを記録する。ＣＧＩプログラムに向けられたクライアントブラウザは、クライアントブラウザに最初に提供されるウエッブページに関係するクライアントにより評定される。クライアントブラウザへの最初のウエッブページ提供は接続されるが、引き続いて行われる外部サーバへのハイパーリンク参照を与えるＵＲＬの選択はどれも見ることかできず、よってＣＧＩプログラムベースのアクセスカウンタではカウントされない。アクセスカウンタのその他の限界は、ＣＧＩプログラムの実施は独立のロード−実行が可能であるという事実により生じる。ＣＧＩプログラムは、ＣＧＩプログラムへのそれぞれのＵＲＬ参照に応答してサーバコンピュータにより直接ロードされて実行されなければならない。プログラムのロード及び実行のオーバーヘッドは、個別のＣＧＩプログラム呼出のそれぞれに対しては小さいかもしれないが、繰り返されればサーバーコンピュータシステムへの重大ではないにしてもかなりの負荷となる。ＣＧＩプログラムの頻繁な実行には普通、クライアントのＵＲＬリクエストに応答するＨＴＴＰｄサーバの実効平均アクセス時間の低下がともなう。検索エンジンへのアクセスを提供しているインターネットビジネスサービスは毎日数１００万のリクエストを記録しているので、ウエッブページの提供効率が少し下がっただけでもインターネットビジネスサービスのコスト効率は大きく低下することになる。１９９５年１２月の時点で、特に、インフォシーク社（ＩｎｆｏｓｅｅｋＣｏｒｐｏｒａｔｉｏｎ）は１日あたり平均５００万の検索を扱っている。

ＣＧＩプログラムにともなう実行オーバーヘッドはかなり大きいことが多い。
ＣＧＩプログラムの多くは、パール（Ｐｅｒｌ）やＴＣＬのようなインタープリータ言語を用いて、少なくとも一部が実行される。従って、実質的な処理オーバーヘッドにはインタープリータ及びＣＧＩプログラムスクリプトをともにロードし、インタープリータを実行してプログラムスクリプトを処理し、次いで何であれ生成された有用なデータを一般には持続型大容量記憶装置に実際に記録するための、多数回の大容量記憶装置転送が含まれる。最終的に、インタープリータ及び／またはＣＧＩプログラムはアンロードされなければならない。

さらに外部ＣＧＩプログラムには、開始時及び稼働中のサーバーの構築及び管理、並びに多忙な状況下でのサーバシステムの保全を含む、保守に関してかなりの問題がある。ウエッブページ提供カウントを個別に識別するためには、個々のウエッブページのそれぞれに対して個々のＣＧＩプログラムがおそらく必要となるであろう。あるいはＣＧＩプログラムを、特定のウエッブページを識別して適切に弁別されるアクセスカウントを記録するようにこのプログラムがコールされる正確な手段を整然と実施し得るだけの複雑なものとすることもできる。大量のページアクセスが個別にカウントされるサーバシステム上のこのようなＣＧＩプログラムの保守は容易なことではない。

さらに外部プログラム、特に動的にインタープリートされるスクリプトが存在することは、保全問題が起こり得ることを表わしている。特に、インタープリートされたスクリプトのアクセス及び実行許可は、非公認のスクリプトのいずれかが実行され、よってサーバコンピュータ自体の基本的な完全性ではないとしても収集されたデータの完全性が危うくなるようなことを防止するために、注意深く管理され、また監視されなければならない。従って既知のアクセスカウンタでは、先に提供されたウエッブページからのハイパーリンクに基づく外部サーバーへのＵＲＬ参照の前記アカウントまたはオーディットの必要性に対する解決策は完全な形であるいは部分的であっても、全く得られない。

ＨＴＴＰプロトコル自体は、バージョン１．５以降のＨＴＴＰプロトコルをサポートしているサーバ及びクライアントに対して根サーバベースのＵＲＬリダイレクトシステムを提供している。ＨＴＴＰサーバにともなうコンフィギュレーションファイル（一般にsrm.conf）は：

Redirect /dir1 http://newserver.widget.com/dir1

の形をもつ指向コンフィギュレーションを用いて、サーバのローカルＵＲＬ参照ディレクトリを外部ＵＲＬ参照に効率よく割り当てる指向リダイレクトを指定することができる。バージョン１．５以降のＨＴＴＰサーバがリダイレクトのために上記のように指定されるローカルディレクトリ（/dir1）へのＵＲＬ参照を受領すると、ＵＲＬ（http://newserver.widget.com/dir1）の形で新しいロケーションを含むリダイレクトメッセージがクライアントブラウザに返される。次いでこのリダイレクトＵＲＬは、通常のクライアントのＵＲＬリクエストのための基礎としてクライアントブラウザにより使用される。

上記の現存のサーバベース・リダイレクトファンクションは、リダイレクトが、通常の形式では、共通のリダイレクトベース・ディレクトリを共有する全ディレクトリ階層のものであるため、外部サーバーへのアクセスのトラッキングをサポートするには不十分である。最も限定された形であってさえ、リダイレクトは各ディレクトリ参照ベースで行われる。すなわち、特定のウエッブページまたはグラフィックイメージまたはアクセスリクエストの特定のオブジェクトであるＣＧＩプログラムとは独立に、ディレクトリへのアクセスの全てが、弁別されることなく全くばらばらにリダイレクトされる。よって、現存サーバがリダイレクトファンクションを利用するいかなる能力も、ＨＴＴＰプロトコルが定める指向リダイレクトオペレーションにより実際上禁止されないとしても、はなはだしく制限される。

さらに、ＨＴＴＰプロトコルサーバの指向リダイレタト能力は、ＣＧＩプログラムまたはその他の実行可能なプログラムをリダイレクトの実行と同時に実行する能力をもたず、よってリダイレクトＵＲＬリクエストに関連する情報を取り込むためのいかなるアクションも実質的に妨げられる。さらに、ディレクトリコンフィギュレーション毎へのリダイレクトを指定するに必要なリソースコンフィギュレーションファイルが複雑であるため、やはり、かなりの構築、保守及び、程度は小さいが、保全問題が生じる。すなわち、サーバーリダイレクトは外部ＵＲＬハイパーリンク参照のオーディットないしアカウントをサポートするに必要な基礎的能力でさえもたない。
最後に、リダイレクトの形式は比較的複雑なＣＧＩプログラムを利用することにより得られる。このようなリダイレクトＣＧＩプログラムは、リダイレクトの目標ＵＲＬの識別に必要であるため、おそらく何らかの形で別にリソース識別を行う必要がある。唯一の目標ＵＲＬが識別されるとすれば、クライアントブラウザにリダイレクトＵＲＬを与えるに必要であるので、次いでＨＴＴＰサーバを介してＣＧＩプログラムからクライアントにリダイレクトメッセージを返すことができる。

不幸にして、このようなＣＧＩプログラムはどれも、最も簡単なアクセスカウンタプログラムにも付随する欠点の全てを包含している。構築、保守及び保全問題に加えて、実行のロード及び待ち時間の問題が残っているだけでなく、上記のようなリダイレクト提供手法には偽装アクセスに対して本質的な弱点がある。偽装アクセスは、ＣＧＩプログラムへのＨＴＭＬ照合がどの特定のウエッブページにも無関係に発せられるという事実により生ずる、特にＣＧＩプログラムにとっての問題である。従って、アクセスカウンタまたはその他のオーディットないしアカウントデータ収集プログラムを実施するＣＧＩプログラムはどれでも、適切なウエッブページとは無関係に外部からＣＧＩプログラムのＨＴＭＬ文に繰り返される参照により、アクセスカウントが不自然に増大し得る。偽装アクセスは本質的に、ＣＧＩプログラムにより集められたいずれのデータをも、その実際の完全性ではなくとも、見掛け上は傷つける。最小限、簡単なアクセスカウントでもその正確さを保証する能力がインターネットサービス広告主にとり基本的に重要であるから、基礎的なアカウントまたはオーディット機能であってもこれを提供するＣＧＩプログラムの使用には実用上限界がある。最後に、ＨＴＭＬでは、例えばサーバーＣＧＩカウンターのＵＲＬ参照に外部サーバーのＵＲＬ参照が続くような、ただ１つのＵＲＬ参照ボタンで順次アクセスされる２つのＵＲＬに対する不正防止方法は与えられていない。

すなわち、本発明の全般的目的は、外部サーバシステムへのハイパーリンク名をトラッキングし、リダイレクトする信頼性の高いシステム及び方法を提供することにある。

上記目的は、トラッキングを行うサーバシステムの外部にあるリソースに対応する予め定められたリソースロケータを参照しているクライアントシステムに応答する前記トラッキングシステムへのメッセージを用意することで、本発明により達成される。
第１のサーバシステムはクライアントシステムによる選択が可能な情報要素をクライアントシステムにウエッブページ内にもたせる。ここで前記情報要素は、コンテンツリソースロケータを利用して第２のサーバシステムから得ることができる情報コンテンツとして、クライアントシステム上でグラフィカルに識別される。クライアントシステムで情報要素が選択されるとプログラム（アプレット）が実行されて、トラッキングシステムにデータを与えるためにトラッキング情報を提供し、コンテンツシステムから情報コンテンツを得るためにコンテンツリクエストを提供する。

すなわち、本発明の利点は、クライアントユーザにはリダイレクトプロトコルの最小限の可視性を付与しながら、最終的に参照されたウエッブページを返す際に最小限の待ち時間を差し挟むような、適切な方法でＵＲＬ参照データが取り込まれることである。
本発明の別の利点は、サーバの外部サポートプログラム及び多数の外部データ参照の個別の呼出が本発明の結果として必要ではなくなり、よってウエッブサーバコンピュータシステムのＣＰＵ及びディスクの負荷増大及びその結果としての待ち時間増加を最小限に抑えることである。

本発明のさらなる利点は、参照識別子及びリダイレクト指示のいずれも、クライアントのＨＴＭＬリクエストにより、個別に提供されたＵＲＬ仕様の内で完全に維持できることである。すなわち、本発明はＣＧＩカウンタあるいはＣＧＩカウンタを組み込むいかなる方法にも要求される効率性及び保守性のいずれにおいても優れている。
本発明のまた別の利点は、本発明のプロトコルをサポートするに必要なプログラム修正がプロトコルトランザクションのサーバ側から完全に実施できることである。クライアント側は、クライアント側に定められた現存のＨＴＭＬプロトコルの範囲内でトランザクションに関わるだけである。

本発明の上記及びその他の利点及び特徴は、以下の本発明の詳細な説明を添付図面とともに考察することによってより良く理解されるであろう。添付図面において、同じ参照数字は図面全体を通じて同じ要素を表わす。

発明の実施形態

ネットワークサービスにインターネットを利用する代表的な環境１０が図１に示される。クライアントコンピュータシステム１２は直接、あるいはインターネットサービスプロバイダ（ＩＳＰ）を介してインターネット１４に接続される。
国際統一リソースロケータによる論理参照により、対応するインターネットサーバシステム１６，１８にアクセスできる。一般には閉じているハイパーテキスト伝送プロトコルトランザクションが、クライアントシステム１２上で実行されているクライアントブラウザアプリケーションとサーバシステム１６上で実行されているＨＴＴＰｄサーバアプリケーションとの間で結ばれる。本発明の好ましい実施の形態においては、サーバーシステム１６は、インターネット１４に接続されている別のＨＴＴＰｄサーバシステムへのハイパーリンク参照を埋め込み、また少なくとも論理的にはサーバシステム１６の外部にあるウエッブページをサポートすなわち提供する、インターネットビジネスサービス（ＩＢＳ）を表わす。

上記の一般的な枠組みの範囲内で、本発明はクライアントシステム１２による埋込ハイパーリンク参照の選択のトラッキングを可能にする。すなわち、埋込ハイパーリンク参照はクライアントシステム１２のユーザによる選択、すなわちクリックが可能なグラフィックシンボルあるいはその他のウエッブページ要素をともなう。クライアントシステム上でのシンボルクリックは一般に、クライアントシステムのユーザが関心をもつシンボルグラフィックにより何らかの形で識別される情報を得るためになされる。トラッキングはクライアントシステム１２に提供されるウエッブページに埋め込まれているＨＴＭＬ情報により可能となることが好ましい。この情報は先に準備されたいずれかのＨＴＴＰｄサーバシステムからクライアントシステム１２に提供される。前記の前もっての準備は、トラッキング情報が与えられた提供ページを集めるように動作する、システム１６のような、指定されたトラッキングＨＴＴＰｄサーバシステムにより提供されるウエッブページ上で、すなわち前記ＨＴＴＰｄサーバシステムに代わって、シンボルクリックをトラッキングするためにＩＢＳによりなされる。

本発明に従って埋め込まれた前記情報は、クライアントコンピュータシステム１２がＨＴＴＰｄサーバシステム１６にトラッキング情報を十分与え得るものである。後にわかるように、この情報は、直接的または間接的に、クライアントコンピュータがシンボルグラフィックにともなう情報を十分リクエストし得るものでもある。同じく後にわかるように本発明の実施には多くの可能な態様がある。
これらの実施態様は一般に、主としてサーバ側またはクライアント側のプロセスを用いるか、専用でプラグインのインタープリートされた管理プロセスを含むか、または数多くの特定のデータ伝送プロトコルのいずれを使用するかでカテゴリー分けされる。

本発明の好ましい実施の形態は、サーバシステム１６により実行されるＨＴＴＰｄサーバアプリケーションに専用修正プログラムとして組み込まれ、ＨＴＴＰ指向リダイレクトを用いるサーバ側プロセスを利用する。すなわち、サーバシステム１６またはその他のサーバシステム（図示せず）のようなＨＴＴＰｄサーバシステムによりクライアント１２に提供されるウエッブページには、論理的に外部にあるサーバシステムにより提供されるウエッブページへのＵＲＬ参照が埋め込まれている。クライアントコンピュータシステム１２のクライアントブラウザを介した前記埋込ＵＲＬの選択により、初めに前記外部サーバではなくサーバシステム１６とのＨＴＴＰトランザクションが生じる。よって、クライアントシステム１２へのウエッブページで最初に提供された前記埋込ＵＲＬにストアされた情報は、ＵＲＬの目標が明らかに外部サーバシステムであっても、ＵＲＬの選択時にサーバシステム１６に返されて与えられる。次いで、リダイレクト応答がサーバシステム１６によりクライアントシステム１２に与えられ、対応するリダイレクトＵＲＬを与える。

図２に示されるように、サーバシステム１６はサーバシステム１６内のネットワークインターフェース２２へのネットワーク接続２０を介してリダイレクトリクエスト情報を受領する。ネットワークインターフェース２２は内部バス２４を介して中央処理ユニット（ＣＰＵ）２６に接続される。ＣＰＵ２６は、ネットワークインターフェース２２及びサーバシステム１６のその他の機能面をサポートするため、ネットワークオペレーティングシステム２８を実行する。ネットワークオペレーティングシステム２８は、ネットワーク２０を介して受領したＨＴＴＰリクエストへのサーバシステム１６の応答動作を定めるＨＴＴＰｄサーバアプリケーション３０のＣＰＵ２６による実行をサポートする。最後に、ネットワークオペレーティングシステム２８は、通常のハードディスクドライブにより与えられるような持続型記憶メディアを含むことが好ましい大容量記憶装置３２にデータを一時的及び持続的にストアする。
本発明の好ましい実施の形態に従えば、ＵＲＬのＨＴＴＰリクエストの一部として与えられる前記埋込リダイレクト情報はＨＴＴＰｄサーバ３０によって処理される。ＨＴＴＰｄサーバ３０による処理は、外部ＣＧＩプログラム等のいずれかの実行とは対照的に、サーバ３０自体の実行により行われることが好ましい。

前記リダイレクト情報は、リダイレクト情報を与えた特定のＵＲＬ参照を識別し有効性を確認するために、またリダイレクト目標ＵＲＬを発生させるために、サーバ３０の実行により処理される。
本発明の好ましい実施の形態においては、リダイレクト情報を含む埋込ＵＲＬは次のようにフォーマットされる：

http://<direct_server>/redirect?<data>?http://<redirect_server>

埋込ＵＲＬのdirect_server部はクライアントシステム１２により初めに確立されるべきトランザクションの目標ＨＴＴＰサーバを指定する。残りの情報は、トラッキングサーバ、すなわちダイレクト目標サーバに与えられる。このダイレクトサーバは、本発明に従うサービスリダイレクトリクエストに指定された、クライアントシステム１２によりアクセス可能なＨＴＴＰｄサーバのいずれであってもよい。

前記埋込リダイレクトＵＲＬにある“redirect”という用語は、前記ＵＲＬが本発明に従うリダイレクトリクエストに対応することを特定するため、ＨＴＴＰｄサーバ３０に前もって識別されるキーワードである。“redirect”という用語が好ましい用語であるが、リダイレクトＵＲＬを指定するためにＨＴＴＰｄサーバ３０により唯一識別され得る用語であれば、いかなる用語またはコードを選択してもよい。用語“redirect”の認識処理は、対応する修正をＨＴＴＰｄサーバアプリケーションに施して、サーバ３０の実行により行われることが好ましい。
すなわち、ＨＴＴＰｄサーバアプリケーションは、用語“redirect”をキーワードとして認識してこの好ましい実施の形態のサーバ側プロセスを実施するためのサブプログラムを実行するように修正される。あるいは、ＨＴＴＰｄサーバアプリケーションの修正は、実質的に同じ機能を得るためにＨＴＴＰｄサーバアプリケーションに備えられる通常のインターフェースを介して動作し得る“プラグイン”バイナリプログラムとして実施することもできる。代わりに、ジャバ（Ｊａｖａ）（登録商標）またはジャバスクリプト（ＪａｖａＳｃｒｉｐｔ）（登録商標）のようなサーバアプリケーション埋込言語も、おそらく性能は低いが、キーワード“redirect”を認識し、本発明を実施するためにさらに処理を行う、サーバ側プロセスの実施に用いることができる。

前記リダイレクトＵＲＬの“data”という用語は、ＨＴＴＰｄサーバ３０へのリダイレクトＵＲＬをさらに識別し、おそらく有効性を確認するために用い得る、参照識別子データをＨＴＴＰｄサーバ３０に与える。すなわち前記データによりＨＴＴＰｄサーバ３０はリダイレクトＵＲＬのアカウントを行うことができる。
宣伝広告関係においては、前記データは、アクセスデータを保存したい特定の広告主、リダイレクトＵＲＬにともなってグラフィックイメージがクライアントシステム１２に与えられる特定の時刻、及び、おそらくは、不適切なクライアントによるリダイレクトＵＲＬの使用をＨＴＴＰｄサーバ３０が確実に弁別して捨て去ることができるようにするために提供される有効性確認コードも、エンコードすることができる。

本発明の好ましい実施の形態に従い、ＨＴＭＬを用いて構成された、リダイレクトＵＲＬの典型例は、以下の通りである：

<a href="http://www. infoseek.com/IS/redirect?NwPg-003-
AA?http://www. newspage.com">

上記リダイレクトデータの中で、データ要素“NwPg”はクライアントまたはアカウント識別子としてはたらく。データ要素“003”はクライアントシステム１２に提供されたウエッブページに埋め込まれた、リダイレクトＵＲＬにともなう特定のグラフィックイメージを示す連番識別子である。最後に、データ要素“AA”は、不適切に繰返されるサーバシステム１６へのリダイレクトＵＲＬ要請あるいは協定により今は廃止されていると決定される要請を、ＨＴＴＰｄサーバ３０が識別できるようにするようにはたらく基本的な有効性確認識別子を提供するために利用することができる。

本発明の別の実施の形態において、前記有効性確認データはリダイレクトＵＲＬを要請したクライアントシステム１２に関する情報を与えるためにＨＴＴＰプロトコルとともに用い得るデータ表現及び、オプションとして、定められた短時間内の同じクライアントシステム１２によるリダイレクトＵＲＬの繰り返し使用を制限するためのグラフィックス連番識別子データをエンコードする。すなわち、サーバシステム１６により収集されるいずれか特定のリダイレクトＵＲＬに関するデータを事実上改竄するためのサードパーティークライアントによる不適切な試みは、完璧ではないにせよある程度は確実に識別されてブロックされる。さらに、ある時間より前のデータコードをコンピュータにより無効であると宣告することができる。従って埋込リダイレクトＵＲＬのコピーは、クライアントシステム１２にストアできず、サーバコンピュータシステム１６により排他的に定められる時間より長く使用が可能なままでいることはない。

リダイレクトＵＲＬ内のデータ項のそれぞれは、埋込リダイレクトＵＲＬをもつウエッブページをクライアントコンピュータシステム１２に最初に提供するプロセスの一部として、静的または動的に、ＨＴＴＰｄサーバ３０により生成される。動的生成により、単一の広告主あるいは広告主数がどれだけであってもその中の１つに対応する相異なるグラフィックイメージを、それとは別に静的に定められたウエッブページとともに有効に提供できる。埋込リダイレクトＵＲＬのデータ項は、ＨＴＴＰｄサーバ３０による特定のウエッブページの提供と同時に行われるグラフィックイメージへの別のハイパーリンクの確立に加えて、広告主の識別情報及び前記グラフィックイメージに基づいて動的に選択される。実際、広告主及びグラフィックイメージの選択は、少なくとも部分的には、ＨＴＴＰプロトコルの通常の動作により与えられる情報を介して設定されたクライアントコンピュータシステム１２の識別情報、及び知られていればクライアントプロフィールに基づいてなされる。

有効性確認コードも動的に生成できる。本発明の別の実施の形態において、有効性確認コードは、埋込リダイレクトＵＲＬが日替りで加齢してゆくことができるだけの十分な特有性を与える、２桁の数字にエンコードされることが好ましい。識別子を生成するために、アカウント及びイメージ識別子データ項とともに、年月日表示をエンコードする。さらに有効性確認コードは日替りベースで一定のままであり、よって、１日あたり及び特定のクライアントコンピュータシステム１２あたりでの参照数もまた、ウエッブページの特定のインスタンシエーションが特定のクライアントコンピュータシステム１２に繰り返し送られる頻度を制限するように、ＨＴＴＰｄサーバ３０がトラッキングすることができる。さらにまたＨＴＴＰｄサーバ３０は、受領したリダイレクトＵＲＬに関して、対応するウエッブページがリクエスト中のクライアントコンピュータシステム１２に最近は提供されていない場合には、ブロック操作を行うことができる。

様々なビットシフト、チェックサム、及びモジューロ算法アルゴリズムが、ＨＴＴＰｄサーバ３０に知られる無矛盾の方法で有効性確認コードを生成するために利用され得るが、得られるリダイレクトＵＲＬを特定のクライアントコンピュータシステム１２が調べて有効性確認コードを見分けることは容易にできることではない。あるいは有効性確認コードは、１日から数週間あるいはさらに長いプログラム可能な期間、ＨＴＴＰｄサーバ３０により有効であると暗示的に認識される、任意に選択された値であってもよい。極端な場合に、有効性確認コードは埋込リダイレクトＵＲＬの一部として与えられる静的値であり、これは初めに述べた本発明の好ましい実施の形態と一致する。

有効性確認コードが生成される特定の方法あるいはコードがＨＴＴＰｄサーバ３０により有効であると認識される期間の指定された長さとは無関係に、リダイレクトＵＲＬのデータ項の評価はＨＴＴＰｄサーバ３０で完全に内部的に行われることが好ましい。データ項は埋込リダイレクトＵＲＬの特定のインスタンシエーションの識別において、外部プログラムのロード及び実行手段あるいは持続型記憶装置３２にストアされたルックアップファイルに問合せる手段でさえ、もしあったとしてもこれを用いる必要のない、曖味さをもたない十分完全なものであることが好ましい。従って、本発明に従うリダイレクトＵＲＬ評価の負担は本質的にほとんど全てがコンピュータにかかる。通常理解されているように、サーバコンピュータシステム１６の性能は一般にコンピュータには支配されず、むしろ持続型記憶装置３２及びネットワーク２０への入出力（Ｉ／Ｏ）アクセス速度に支配される。リダイレクトＵＲＬと関連して得られるオーディットまたはアカウントデータのセーブにのみＩ／Ｏ動作を限定するとともに、リダイレクトＵＲＬの評価をコンピュータ動作に完全にではなくとも実質的に制限することにより、サーバコンピュータシステム１６の負担の最適最小化が本発明の実施により実現される。実際、セーブされるアカウントまたはオーディットデータをネットワークオペレーティングシステム２８でキャッシュしておいて、サーバコンピュータシステム１６上で進行中の作業において余分のＩ／Ｏバンド幅が利用できるようになるまで、持続型記憶装置３２への書込Ｉ／Ｏ作業を延期することができる。

リダイレクトＵＲＬの好ましい構造の最後の要点は、第２ＵＲＬである。この第２ＵＲＬはリダイレクトのための目標サーバを直接識別することが好ましい。好ましくは、リダイレクトＵＲＬのダイレクトサーバ指定部として与えられるいかなるパス部も、リダイレクトＵＲＬのリダイレクトサーバ部のパス要素として繰り返される。しかし、パス部の同一性は必要とされない。一般に、本発明により要請されることは、前記ダイレクトサーバとリダイレクトＵＲＬのリダイレクトサーバ項との１対１の対応だけである。本発明の実施により集められるオーディットまたはアカウントデータへの影響がそれらのデータに求められる特性と矛盾しなければ、より束縛の緩い関係を用いることもできる。例えば、相異なるダイレクトサーバ指定を、埋込リダイレタトＵＲＬの特定のインスタンシエーションをさらに識別する手段として、共通リダイレクトサーバの使用と相互に関連付けることかできる。あるいは、埋込リダイレクトＵＲＬの何か別の同様なインスタンシエーションが多くのリダイレクトサーバのいずれかを参照してもよい。すなわち埋込リダイレクトＵＲＬは、最終的に情報提供を行うリダイレクトサーバへの間接参照のみを与え、前記direct_serverで参照されたサーバシステムに依存するか、あるいはリダイレクトサーバ自体が最終的に情報提供を行うリダイレクトサーバへのダイレクト参照に第２ＵＲＬを変換する。これは、共同して動作しているリダイレクトサーバに負荷を分散するか、あるいは進行中の本発明の実施により集められるオーディットまたはアカウントデータを検証するための手段を与えるためになされる。実際、リダイレクトＵＲＬの第２ＵＲＬは、無限リダイレタトループをつくらないように注意を払う必要はあるが、自身がリダイレクトＵＲＬとなることもできる。

クライアントコンピュータシステム１２によりサーバコンピュータシステム１６に与えられたリダイレクトＵＲＬの好ましい処理方法４０が図３に示される。
各クライアントからのリクエストが受領される（ステップ４２）と、そのリクエストにリダイレクトキーワードが埋め込まれているか否かを決定するためにそのリクエストの一部として与えられるデータが検査される（ステップ４４）。前記ＵＲＬデータが本発明に整合しないリダイレクトリクエストを指定していなければ、ＵＲＬデータが現存のローカルウエッブページを通常通りに指定しているか否かを決定するためにＵＲＬデータがチェックされる（ステップ４６）。前記ウエッブページが存在しないか、あるいはクライアントのＵＲＬリクエストに関連するＨＴＴＰプロトコルを介して提供されるクライアント識別データに基づいて、ある特定のクライアントが前記現存のウエッブページへのアクセスを拒否される場合は、ＨＴＴＰｄサーバ３０は対応するエラーメッセージをクライアントコンピュータシステム１２に返すことを決定する（ステップ４８）。そうでなければ、ＨＴＴＰｄサーバ３０は作業を続け、クライアントコンピュータシステム１２にローカルウエッブページを提供する（ステップ５０）。

ＵＲＬデータが少なくともリダイレクトリクエストを指定している場合は、そのＵＲＬデータの有効性がさらにチェックされる（ステップ５２）。サーバシステム１６のメモリにキャッシュされることが好ましいクライアントとグラフィックイメージ識別子の有効組合せ表を、リダイレクトリクエストの有効性を最初に確認するために用いることができる。有効性確認コードも、与えられたリダイレクトデータに基づく再計算によりチェックされるか、あるいは別の現行有効性確認コード表と対照してチェックされる。いずれの場合にも、リダイレクトリクエストの相対タイムラインが前記有効性確認コードの持続日数から定められ、よって現時点でのリダイレクトリクエストか時間的に合っているかあるいは疑わしいかを決定するための基礎としてはたらく。さらに、リクエストを行っている特定のクライアントコンピュータシステム１２にサーバコンピュータシステム１６により対応するウエッブページが実際に最近提供されていることを検証するために、サーバコンピュータシステム１６により実際に提供されたローカルウエッブページの短期記録に基づいてさらにチェックを行うこともできる。最後に、サーバコンピュータシステム１６により実施されるアクセス許可が、定められたクライアント階級へのリダイレタトをカテゴリー毎に制限するために、クライアントコンピュータシステム１２の識別情報に対照してチェックされる。前記リクエストがいずれの理由にせよ無効であると決定されると、適切な拒否メッセージが生成され発行される（ステップ４８）。

リダイレクトリクエストが有効であると決定されると、リダイレクトリクエストの一部として提供されるかあるいはＨＴＴＰプロトコルの通常動作を介してＨＴＴＰｄサーバ３０に提供されるデータのいずれかまたは全てが、以降の操作、解析及びレポート出力のためにネットワークオペレーティングシステム２８を介して持続型記憶装置３２に記録される。リダイレクトリクエストは次いで、リダイレクト目標サーバを識別する第２ＵＲＬを得るためにさらに処理される（ステップ５６）。
この第２ＵＲＬは次いで、リダイレクトメッセージ、好ましくは一時的リダイレクトメッセージのロケーションフィールドに指定され、このメッセージは初めにリダイレクトＵＲＬを発行したクライアントコンピュータシステム１２に向けて発行される（ステップ５８）。

本発明の好ましい実施の形態に従う処理４０は、実質的に全てがＨＴＴＰｄサーバ３０内で行われる。処理４０の実施は、ＨＴＴＰｄサーバ３０により実施される処理の流れを修正及び拡張し、対応するサーバソースコードを修正することにより行うことができる。これらの修正及び付加は通常のプログラミング手法を利用して行うことができる。
本発明により提供されるリダイレクト能力は、通常のＨＴＴＰｄサーバにより提供されるデファクトスタンダードの現存リダイレクト能力と完全に整合する。

処理４０のさらに詳細な部分６０が図４に示される。ＨＴＴＰｄサーバ３０の作業内で、ＵＲＬデータが受領され（ステップ６２）、まずリダイレクトキーワードが適切に存在するかを識別するために解析される（ステップ６４）。本発明の特定の形式のリダイレクトＵＲＬが識別されなければ（ステップ６６）、その他のいずれかのリダイレクト形式が適用可能であるか否かを決定するために、このＵＲＬは通常の方法でさらに処理される。さらに、通常のリダイレクト指定をもたないローカルウエッブページへの通常のアクセス特権の評価もなされて、最終的に、適切な応答メッセージが発行される（ステップ６８）。

ＵＲＬリクエストが本発明と一致する特別なリダイレクト形式をもっている特定の場合には、通常のＨＴＭＬリダイレクト能力とは対照的に、このＵＲＬデータが処理され（ステップ７０）、クライアントコンピュータシステム１２を識別するＨＴＴＰプロトコル提供データとともに、ステップ７２でデータベースレコードが持続型記憶装置３２につくられるかまたは更新される。次いで第２ＵＲＬが抽出されて（ステップ７４）、リダイレクトメッセージ、特に３０２タイプの一時的リダイレクトメッセージが作成される。前と同様に、第２ＵＲＬはダイレクトまたはリテラルＵＲＬであるか、あるいはＨＴＴＰｄサーバ３０により少なくともリダイレクト目標サーバを識別するに十分なＵＲＬに変換することができる間接リダイレクト目標サーバ識別情報である。ウエッブページに埋め込まれた第２ＵＲＬはＨＴＴＰｄサーバ３０の作業による前準備で定められるので、いずれの間接リダイレクト目標サーバ識別情報の変換も、例えばデータベースルックアップ作業により、ＨＴＴＰｄサーバ３０によって完全に決定される。
次いでロケーションフィールドを含むリダイレクトメッセージがＨＴＴＰｄサーバ３０により生成される。このロケーションフィールドには前記ダイレクトＵＲＬまたは変換されたリダイレクト目標サーバＵＲＬが与えられる。次いでこのリダイレクトメッセージは、初めにリクエストしたクライアントコンピュータシステム１２に発行される（ステップ５８）。

その他のサーバ側で動作し得る本発明の実施の形態は、トラッキング情報をクライアントシステム１２からＨＴＴＰｄサーバ３０に伝送するためにその他の特定のプロトコルを用いることができる。これらその他のＨＴＴＰプロトコル命令には、例えばＧＥＴ，ＦＯＲＭＳ，ＯＰＴＩＯＮＳ，ＨＥＡＤ，ＰＵＴ，ＤＥＬＥＴＥ，及びＴＲＡＣＥがある。これらその他のプロトコル命令の使用方法は、プロトコル命令及びウエッブページへのそれらの特定のＨＴＭＬマークアップコーディングの詳細に関して特定のブラウザをサポートするために必要な使用方法とは異なり、一般的に同じである。

上記その他のプロトコル命令の使用法の一例として、クライアントコンピュータシステムに提供されるウエッブページに以下のＨＴＭＬコードタグを埋め込むことにより、ＨＴＴＰＧＥＴ命令を実行できる。

// HTTP GET
<a href = "http://www.infoseek.com/redirect? backslash
ak = MTCH-2009-1073-GEN& backslash
rd =http://www.match.com/">
<img src = "http://www.online.com/ads/MTCHI073.gif">
</a>

このＨＴＭＬコードは“MTCH1073.gif”をウエッブページシンボルグラフィックとして、“www.infoseek.com”をダイレクトＵＲＬとして、“MTCH-2009-1073-GEN”をデータとして、また“www.match.com”をリダイレクト目標サーバとして定める。
上記ＨＴＭＬタグがクライアントコンピュータシステムに提供されると、初めのＨＴＴＰＧＥＴリクエストがシンボルグラフィックを得るために“www.online.com”に発行される。シンボルクリックに応答して、第２のＧＥＴリクエストがＵＲＬ：

/redirect?ak=MTCH-2009-1073-GEN&rd=http://www.match.com/

を用いて“www.infoseek.com”に向けられる。ＧＥＴリクエストの完全な形は：

GET /redirect?ak=MTCH-2009-1073-GEN& backslash
rd = http://www.match.com/HTTP/1.0
User-Agent: Mozilla/3.0
Accept: image/gif, image/jpeg, */*

である。

ＨＴＴＰサーバ３０は（クッキーのような）ＭＩＭＥ情報及び形状変数（この場合はａｋ及びｒｄ）の値を記録する。次いで、ＨＴＴＰリダイレクトメッセージがＨＴＴＰサーバ３０により生成されてクライアントコンピュータシステムに返される。次いで、第３で最終のＧＥＴリクエストが前記リダイレクトメッセージに応答して“www.match.com”に発行される。
別の例として、ＨＴＴＰＰＯＳＴ命令を用いることができる。ＨＴＭＬタグが埋め込まれたウエッブページは以下のようにコード化される。

// HTTP POST
<FORM method = "POST" backslash
action = "http://www.infoseek.com/redirect">
<INPUT TYPE = hidden backslash
NAME = "ak" backslash
VALUE = "MTCH-2009-1073-GEN">
<INPUT TYPE= hidden backslash
NAME = "rd" backslash
VALUE = "http://www.match.com/">
<INPUT TYPE = image backslash
SRC = "http://www.online.com/ads/MTCH1073.gif">
</FORM>

このＨＴＭＬコードにより、前記シンボルグラフィックを取り込むために“www.online.com”にＧＥＴリクエストが自動的に発行される。シンボルクリックにより、ＨＴＴＰＰＯＳＴリクエストが前記ＦＯＲＭＮＡＭＥ及びＶＡＬＵＥデータと一緒に“www.infoseek.com”に送られる。この場合、前記データはＵＲＬにエンコードされず、むしろＰＯＳＴリクエスト自体の中にエンコードされる。
この例において、ＰＯＳＴリクエストは：

POST /redirect HTTP/1.0
User-Agent: Mozilla/3.0
Accept: image/gif, image/jpeg, */*
Content-type: application/x-www-form-urlencoded
Content-length: 54
ak=MTCH-2009-1073-GEN&rd=http://www.match.com backslash

という形をもつであろう。前記返されたリダイレクトメッセージが受領されると、クライアントコンピュータシステムにより別のＧＥＴリクエストが、同じく“www.match.com”であるリダイレクト目標サーバに発行される。

本発明に従えば、クライアント側プロセスもクライアントコンピュータシステムによるウエッブページ要素選択の通知を見えない形で提供するために利用できる。図５は、本発明を実施するサーバ側及びクライアント側プロセスのいずれにも関わるデータ伝送の流れの表示７８を与える。サーバ側及びクライアント側でのプロセス実施のいずれにも共通して、クライアントコンピュータシステム８０が最初のウエッブページリクエストを（図示していない）インターネットでウエッブページサーバシステム８２に発行する。ウエッブページ要素８６を含む対応するウエッブページ８４がクライアントコンピュータシステム８０に返される。

同じく、サーバ側及びクライアント側での本発明のプロセス実施のいずれにも共通して、ウエッブページ要素８６がウエッブページ８４への情報埋込により与えられる。図６に大要を示すサーバ側プロセス環境においては、シンボルクリック（ステップ９６）に続く本発明のプロセスによりクライアントブラウザが動作する。特に、前記埋め込まれた情報が、図５に示すように、リダイレクト目標サーバシステム８８に向けて通知ＵＲＬを発行する（ステップ９８）に十分なクライアントコンピュータシステム上のウエッブブラウザの動作を管理する。前記通知ＵＲＬの受領に応答して開始されるサーバ側プロセスは、クライアントコンピュータシステム８０に返されるリダイレクトメッセージを生成する（ステップ１００）。このリダイレクトメッセージ生成に関連して、サーバシステム８８もステップ９８で発行された通知ＵＲＬの一部として受領したデータを記録して、随意に処理する。

次いで、前記リダイレクトメッセージに基づき、クライアントコンピュータシステム８０がリダイレクトメッセージに含まれる情報に基づくＨＴＴＰリクエストを発行する（ステップ１０２）ことが好ましい。図５を再び参照すると、ステップ１０２で発行されたＨＴＴＰリクエストが、クライアントコンピュータシステム８０に前記ウエッブページ要素８６から演繹して参照されたウエッブページとしてウエッブページ９２を提供することにより通常の方法で応答する別のウエッブページサーバシステム９０にインターネット１４を介して提供される（ステップ１０４）。

クライアント側プロセスを利用する本発明の方法の大要が図７に示される。ここでの例を説明する目的のため、本方法１０６はシンボルクリック（ステップ１０８）に応答して開始され、クライアントコンピュータ８０上のウエッブブラウザの動作と関連してクライアントプロセス１１０の実行を開始する。本発明の好ましい実施の形態においては、クライアントプロセス１１０はクライアントコンピュータシステム８０へのウエッブページ８４とともに与えられる。クライアントプロセス１１０はシンボルクリックに応答して呼び出され、第１に通知ＵＲＬメッセージを発行する（ステップ１１２）ために、また第２にＨＴＴＰリクエストを発行する（ステップ１１４）ために作動する。いずれのメッセージも、インターネット１４を介して、それぞれ目標サーバシステム８８及びウエッブページサーバ９０に発行される。クライアントプロセス１１０が通知ＵＲＬ１１２及びＨＴＴＰリクエスト１１４を発行する順序は重要ではない。さらに、目標サーバシステム８８からの通知ＵＲＬ受領の確認がなくとも、ＨＴＴＰリクエスト１１４を発行することができる。実際、クライアントコンピュータシステム８０のユーザには明らかなように、重要であると認められる唯一の応答はウエッブページ９２を受領する（ステップ１１６）ことである。

サーバ側プロセスの場合と同様に、クライアント側プロセス１１０は、本発明の目的のため多くの相異なる方法で実施され、いずれの方法も、目標サーバシステム８８にデータを送付し、ウエッブページ要素８６との前もって準備された対応を有するウエッブページ９２を提供するためのウエッブページサーバシステム９０にＵＲＬリクエストを送付する。特に、クライアント側プロセスはブラウザアプリケーション内に直接コード化されるか、あるいは通常のブラウザアプリケーションへのブラウザプラグインとして供給される。クライアント側プロセスはまた、ジャバ及びジャバスクリプトタイプのアプレットを用いて実施することもできる。

クライアント側プロセスの典型例はジャバアプレットを用いて実施される。本例のための、ウエッブページ８４に埋め込まれるＨＴＭＬコードは、以下の通りである：

<applet name = "ad" code = "ad.class" width = 468 height = 60>
<param name = img value = "ad.gif">
<param name = notifyurl value = "?MTCH-2009-1073-GEN">
<param name = pageurl value = "http://catalog.online.com/">
</applet>

ここで上記３つのアプレットパラメータは以下のように定義される：
“img” −広告グラフィックシンボルへのＵＲＬ参照
“notifyurl” −アカウントデータを保持する“通知”ＵＲＬ
“pageurl” −利用する“リダイレクト”ＵＲＬ

アプレットソースは以下の通りである：

import java.applet.Applet;
import java.awt.Image;
import java.awt.Graphics;
import java.net.URL;
import java.net.MalformedURLException;
import java.io.IOException;

public class ad extends Applet {
Image image;
URL notifyurl;
URL pageurl;

public void init( ) {
image = getImage(getDocumentBase( ), getParameter("img"));
try {
logurl = new URL(getDocumentBase( ), getParameter ("notifyurl"));
pageurl = new URL(getDocumentBase( ), getParameter ("pageurl"));
} catch (MalformedURLExeception e) { }
}

public void paint(Graphics g) {
g.drawImage(image, 0, 0, this);
}

public boolean mouseDown(java.awt.Event evt, int x, int y) {
try {
logurl.openStream( ).close( );
} catch (java.io.IOException e) { }
getApplet Context( ).showDocument(pageurl);
return true;
}
}

上例は、第１に“notifyurl”メッセージを発行し、第２に“pageurl”メッセージを発行するために２つのＨＴＴＰリクエストを使用している。しかし、その他の様々なプロトコルを本発明とともに用いることができる。例えば、上記ジャバアプレットはＴＣＰ接続を用いて目標サーバシステム８８に通知データを与えるように修正できる。ＴＣＰ接続を利用するアプレットの典型的実施例を以下に示す。このアプレットは４つのパラメータ：
“img” −表示する広告（ａｄ）イメージのＵＲＬ
“port” −目標サーバ上で使用するＴＣＰポート番号
“data” −目標サーバに送付するアカウントデータ
“pageurl” −利用する“リダイレクト”ＵＲＬ
をとる。

アプレットソースは以下の通りである：

import java.applet.Applet;
import java.awt.Graphics;
import java.awt.Image;
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintStream;
import java.lang.Integer;
import java.lang.String;
import java.net.MalformedURLException;
import java.net.Socket;
import java.net.URL;

public class ad extends Applet {
Image image;
String host,data;
int port;
URL url;

public void init( ) {
image = getImage(getDocumentBase( ), getParameter("img"));
host = getDocumentBase( ).getHost( );
port = Integer.parseInt(getParameter("port"));
data = getParameter("data");
try {url = new URL(getDocumentBase( ), getParameter ("pageurl"));}
catch (MalformedURLException e) { }
}

public void paint(Graphics g) {
g.drawImage(image, 0, 0, this);
}
public boolean mouseDown(java.awt.Event evt, int x, int y) {
try {
Socket socket = new Socket(host,port);
PrintStream ps = new PrintStream(socket,getOutputStream( ));
ps.print(data);
ps.close( );
} catch (java.io.IOException e) { }
getAppletContext( ).showDocument(url);
return true;
}
}

最後に、上記のアプレットはウエッブページ８４に以下のＨＴＭＬコードを埋め込むことにより実行のために参照することができる。

<applet name="ad" code="ad.class" width=468 height=60>
<param name=imag value="ad gif">
<param name=port value="21">
<param name=data value="MTCH-2009-1073-GEN">
<param name=url value="http://catalog.online.com/">
</applet>

以上、ハイパーリンクされた外部サーバに対してクライアントコンピュータシステムによりなされるアクセスをアカウントまたはオーディットするための包括的なシステム及び方法を説明した。本システムのプロセスのオーディット能力は、集められたデータが有効であることを確認でき、またリダイレクト目標サーバシステムへの善意のアクセスに対応することが合理的に保証できる一方で、リダイレクトサーバシステムには最適最小のオーバーヘッドしか負わせない。
本発明を、特に本発明の好ましい実施の形態を参照して示しまた説明したが、本発明の精神及び範囲を逸脱することなく前記実施の形態の形式及び詳細には様々な変更をなし得ることは、同業者には当然であろう。

インターネットを介して相互にネットワークされたクライアント及びサーバコンピュータシステムの概略図である。本発明の好ましい実施の形態に従うＨＴＴＰダイモン（ＨＴＴＰｄ）サーバを組み込んでいるサーバコンピュータシステムのブロック図である。クライアントのＵＲＬリクエストの受領及び処理において本発明の好ましい実施の形態に従って行われる処理を示す流れ図である。本発明の別の好ましい実施の形態に従う特別リダイレクトＵＲＬのサーバ側プロセスを示す流れ図である。本発明の別のプロセスを実施するクライアント及びサーバコンピュータシステムの一般化した処理を表わす図である。本発明の好ましい実施の形態に従うコンテンツリクエストメッセージを発行するサーバ側プロセスを示す流れ図である。本発明の好ましい実施の形態に従うトラッキングメッセージを発行するクライアント側プロセスを示す流れ図である。

Claims

トラッキングを行うトラッキングサーバシステム、第１のサーバシステム、第２のサーバシステム及び第１のサーバシステムからのウエッブページを受領するクライアントシステムがインターネットを介して接続されており、
前記トラッキングサーバシステムは、クライアントシステムのユーザによる、トラッキング対象の通知データが含まれたウエッブページの情報要素の選択を介した、対応する第２のサーバシステムのウエッブページへの参照の発生をトラッキングすると共に前記通知データの受領をし、
前記クライアントシステムは、
前記第１のサーバシステムからウエッブページを受領して、ブラウザにより該ウエッブページを表示し、表示した該ウエッブページで、前記クライアントシステムユーザによる前記ウエッブページの情報要素の選択に応答して、該ウエッブページ内のプログラムを実行して、
第２のサーバシステムに前記対応するウエッブページを要求するとともに、トラッキングサーバシステムに前記通知データを含むトラッキング情報を提供するプロセスを実現し、
よって、前記クライアントシステムユーザによる前記情報要素の選択に応答して、前記クライアントシステムユーザには見えない形でトラッキングサーバシステムに前記通知データを含むトラッキング情報を提供し、また前記第２のサーバシステムにコンテンツリクエストを提供し、
前記トラッキングサーバシステムに提供する前記通知データはアカウント識別子であり、当該アカウント識別子は前記第２のサーバシステムに要求する前記対応するウエッブページへのアクセスをアカウントするためのアカウントデータであることを特徴とする方法。
トラッキングを行うトラッキングサーバシステム、第１のサーバシステム、第２のサーバシステム及び第１のサーバシステムからのウエッブページを受領するクライアントシステムがインターネットを介して接続されており、
前記トラッキングサーバシステムは、クライアントシステムのユーザによる、トラッキング対象の通知データが含まれたウエッブページ上の情報要素の選択を介した、対応するウエッブページへの参照の発生をトラッキングすると共に前記通知データの受領をし、
前記第１のサーバシステムは、
前記クライアントシステムユーザにより選択できると共にトラッキング対象の通知データが含まれた前記ウエッブページの情報要素と、該ウエッブページの情報要素の選択に応答して実行できるプログラムとを含むウエッブページを作成し、
前記クライアントシステムに作成した前記ウエッブページを提供し、
前記プログラムは、
前記第２のサーバシステムに前記対応するウエッブページを要求するとともに、前記トラッキングサーバシステムに前記通知データを含むトラッキング情報を提供するプロセスを前記クライアントシステムで実現するものであり、
よって、前記クライアントシステムユーザによる前記情報要素の選択に応答して、前記発生が前記クライアントシステムユーザには見えない形でトラッキングサーバシステムに前記通知データを含むトラッキング情報を提供し、また前記第２のサーバシステムにコンテンツリクエストを提供し、
前記トラッキングサーバシステムに提供する前記通知データはアカウント識別子であり、当該アカウント識別子は前記第２のサーバシステムに要求する前記対応するウエッブページへのアクセスをアカウントするためのアカウントデータであることを特徴とする方法。
トラッキングを行うトラッキングサーバシステム、第１のサーバシステム、第２のサーバシステム及び第１のサーバシステムからのウエッブページを受領するクライアントシステムがインターネットを介して接続されており、
前記トラッキングサーバシステムは、クライアントシステムのユーザによる、トラッキング対象の通知データが含まれたウエッブページ上の情報要素の選択を介した、対応するウエッブページへの参照の発生をトラッキングすると共に前記通知データの受領をし、
前記第１のサーバシステムは、
前記クライアントシステムユーザにより選択できると共にトラッキング対象の通知データが含まれた前記ウエッブページの情報要素と、該ウエッブページの情報要素の選択に応答して実行できるアプレットとを含むウエッブページを作成するウエッブページ作成手段と、
前記クライアントシステムに前記作成したウエッブページを提供するウエッブページ提供手段とを備え、
前記プログラムは、
第２のサーバシステムに前記対応するウエッブページを要求するとともに、トラッキングサーバシステムに前記通知データを含むトラッキング情報を提供するプロセスを前記クライアントシステムに実現するものであり、
よって、前記クライアントシステムユーザによる前記情報要素の選択に応答して、前記発生が前記クライアントシステムユーザには見えない形でトラッキングサーバシステムに前記通知データを含むトラッキング情報を提供し、また前記第２のサーバシステムにコンテンツリクエストを提供し、
前記トラッキングサーバシステムに提供する前記通知データはアカウント識別子であり、当該アカウント識別子は前記第２のサーバシステムに要求する前記対応するウエッブページへのアクセスをアカウントするためのアカウントデータであることを特徴とする第１のサーバシステム。