JP5010081B2 - ウェブページを仲介するシステムおよび方法 - Google Patents

Description

【０００１】
本発明は、概して、ウェブページシステムおよび方法に関し、詳細には、中間サーバにおいてウェブページをソフトウェア仲介するためのシステムおよび方法に関する。
【０００２】
（本発明の背景）
ウェブサイトが広まるになるにつれて、ウェブサイトに対する性能の目標および品質の規格を設定する関心がビジネスにおいてますます増している。これらの目的を達成するための１つの方法は、企業ウェブサイトでエンドユーザの経験をとすることである。エンドユーザの経験をシミュレートすることによって、企業は、ページのリンクおよびリソースの整合性を決定し、ビジネスによって規定される業務目標のための顧客の経験とみなされ得る。さらに、企業の情報技術部門は、決定的なウェブリソースを追跡し、測定することがより可能である。個々の顧客の経験をシミュレートすることに加えて、多数の顧客を同時にシミュレートすることによって、企業はウェブサイトにおいてストレステストを行ない、サイト性能の傾向を検出することができ、それにより、その企業は、問題が生じる前に、その問題に取り組むことができる。
【０００３】
ウェブサイトを介するユーザ経路をシミュレートする１つの方法は、ユーザによって為される全てのリクエストを記録することである。これをするためには、一般的には、中間サーバ（一般的には、プロキシサーバ）を介してユーザ要求をルーティングすることが必要である。しかし、プロキシサーバの使用は、著しい技術的経験を必要とする。なぜなら、各ブラウザはプロキシサーバを通り抜けるように個々に構成される必要があるからである。この問題は、同じブラウザの異なるバージョンが一意な構成を必要とし得るという事実によって強調される。ユーザのウェブページリクエストを追跡するためのプロキシサーバの使用に関するさらなる制限が存在する。なぜなら、ユーザのリクエストは、任意の他のプロキシサーバを通ってルーティングすることができないからである。これは、企業プロキシサーバを介してルーティングされる従業員リクエストを必要とする企業が多くなるにしたがって、ますます問題となっている。プロキシサーバを使用して、従業員がアクセスするウェブサイトを制限し、一般的なウェブサイトにキャッシュすることによる効率性を得る。ウェブサイトコンテンツがプロキシサーバにおいてキャッシュされる場合、そのウェブサイトに関するリクエストに対する任意の応答は、プロキシサーバからくるものであり、ターゲットウェブサイトからではない。したがって、リクエストは、実際には、企業サーバを越えることは決して無く、したがって、第２のプロキシサーバ（すなわち、ユーザのリクエストを追跡するサーバ）によって記録可能ではない。
【０００４】
プロキシサーバを使用することによる幾つかの不利点は、中間ウェブサーバを介したウェブページリクエストをルーティングすることによって克服することができる。ウェブページリクエストが中間ウェブサーバから作製される場合、ターゲットウェブサイトのＨＴＭＬテキストは、ターゲットウェブサイトのリンクが始めにその中間ウェブサーバを介してルーティングされるように、変更されるか、または仲介される。例えば、幾つかのウェブサイトは、ターゲットウェブサイトテキストを仲介するように開発され、それにより、そのテキストは、社会グループの方言または人気のあるマンガおよび映画の文字を反映する。さらに、これらのサイトはウェブリンクを仲介し、それにより、中間ページからリクエストされた任意のページが、また、仲介される。しかしながら、これらのウェブサイトによって使用される方法は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどの動的コンテンツ、フォーム、サイドイメージマップおよび他の本質的なウェブ技術を取り扱わない。
【０００５】
（発明の要旨）
本発明は、仲介ページに対して使用された以前に開発されたシステムおよび方法に関連する不利点および問題を実質的に取り除くか、または、減らすシステムおよび方法を提供する。
【０００６】
より詳細には、中間サーバにおいてウェブページを仲介するためのシステムおよび方法を提供する。その方法は、ウェブページがキャッシュされないことを確実にするステップと、中間サーバを参照するウェブページのリンクを変更するステップとを包含する。本発明において、その中間サーバを参照するように改変されるリンクは、絶対基準および相対基準のいずれかであり得る。
【０００７】
本発明は、動的コンテンツが仲介可能であることによって、ウェブページを仲介するために依然に開発されたシステムに対してかなりの利点を提供する。
【０００８】
本発明は、ウェブページがユーザコンピュータまたはプロキシサーバによってキャッシュされることを防ぐことによって、さらに別の重要な技術的な利点を提供する。
【０００９】
本発明は、クッキーが仲介可能であることによって、さらに別の重要な技術的な利点を提供する。
【００１０】
本発明は、依然の方法より、かなり多くの数のウェブページを仲介することが可能であることによって、さらに別の重要な技術的な利点を提供する。
【００１１】
本発明は、さらなるソフトウェアがユーザのコンピュータにインストールされる必要が無く、さらいにユーザのウェブブラウザの改変にも必要とされないので、さらに別の重要な技術的な利点を提供する。
【００１２】
本発明およびその利点をより完全に理解するために、類似の参照符号が類似の特徴を示す添付の図面に関連する以下の説明を参照する。
【００１３】
（発明の詳細な説明）
本発明の好適な実施形態を図面に図示する。類似の参照符号を用いて、異なる図面の類似および対応する部材を示す。
【００１４】
本発明の目的に対して、「コンテンツ」は、（例えば、ユーザがリンクを選択する場合）ユーザコマンドに応じるウェブページによってユーザのブラウザに戻されるＨＴＭＬおよび他のデータを指す。「静的」ウェブページは、経時的に変化しない、ユーザのブラウザに戻されるコンテンツを含む。「動的」ウェブページは、異なって、予めフォーマットされていないコンテンツを含み得るページを表す。そのページは、同じユーザのコマンドに応じて経時的に変化する。「経路」または「ウェブ経路」は、特定の順番においてなされる連続的なリクエストである。「教示セッション」は、経路が後に再生され得るようにユーザが該経路を規定することを指す。
【００１５】
本発明は、ウェブページ内に静的コンテンツおよび動的コンテンツの両方を取り扱い得る態様でターゲットウェブページを仲介するためのシステムおよび方法を提供する。図１は、本発明がウェブを介したユーザ経路を記録することができるシステムを図示したものである。ユーザは、ウェブブラウザ２０を介して中間サーバ１０においてソフトウェアプログラム５にアクセスし得る。ある実施形態において、中間サーバ１０においてソフトウェアプログラム５にアクセスした後に、ユーザは、ウェブブラウザ２０を使用して、経路名（例えば、「経路１」）および開始ＵＲＬをソフトウェアプログラム５に提供する。経路名および開始ＵＲＬはデータベース１５に保存され得る。経路名は、ユーザによって規定される特定の経路を分類するために使用され、開始ＵＲＬは、ユーザの経路の開始点である。「開始」ボタンをクリックすることによって経路を規定し始める準備していることをユーザが示すと、例えば、ソフトウェアプログラム５は、ディスプレイウィンドウにウェブブラウザ２０を開かせ得る。そのディスプレイウィンドウは、ユーザのコマンドに応じて受信されるコンテンツが表示されるブラウザ２０の新たなウィンドウである。開始ＵＲＬに対するユーザのリクエストは、ブラウザ２０からソフトウェアプログラム５に送信される。ソフトウェアプログラム５は、そのリクエストをターゲットウェブサーバ３０に転送する。ターゲットウェブサーバ３０は、開始ＵＲＬに対応するウェブページ３５を中間サーバ１０に戻す。次いで、ソフトウェアプログラム５はそのコンテンツを仲介し得、それにより、ウェブページ３５の仲介されたコンテンツからユーザによってなされた任意のさらなるリクエストは、中間サーバ１０を介してルーティングされる。そのコンテンツの仲介は、図２に関連して説明される方法にしたがってなされ得る。
【００１６】
そのコンテンツを仲介した後に、ソフトウェアプログラム５は、仲介されたコンテンツをウェブブラウザ２０のディスプレイウィンドウに通信し得る。ユーザの観点から、ウェブブラウザ２０のディスプレイウィンドウに表示されるページは、ウェブページのコンテンツが仲介されずに（すなわち、ユーザがターゲットウェブサーバ３０にアクセスする場合）表示されるページの概観と全く同一であるようにみえ得る。しかし、本発明は、ウェブブラウザ２０のディスプレイウィンドウを、ナビゲーションなしにまたはステータスバーなしに開かせ得る。これは、ディスプレイウィンドウに表示される仲介されたコンテンツを介してＵＲＬにアクセスするのではなく、ブラウザ２０のトップにおいてＵＲＬを直接的に入力することにより、プロセスを規定する経路を不注意に迂回しないように為される。
【００１７】
ユーザがウェブページ３５の仲介されたコンテンツからコマンドまたはリクエストを入力する場合、ソフトウェアプログラム５は、データベース１５にコマンドを保存する。さらに、コマンドに対応するヘッダおよびクッキーなどの他の情報が、データベース１５に格納され得る。次いで、ソフトウェアプログラム５は、新たなウェブページ３５に対するさらなるリクエストをターゲットウェブサーバ３０に転送する。例として、ユーザは、ウェブページ３５の仲介されたコンテンツからのリクエストを、ブラウザ２０のディスプレイウィンドウに作成し得、ソフトウェアプログラム５はデータベース１５においてそのリクエストを記録し得、次いで、そのリクエストをターゲットウェブサーバ３０に転送し得る。ターゲットサーバ３０からターゲットウェブページ３５のコンテンツを再び受け取ると、ソフトウェアプログラム５は、ウェブページ３５からの応答のコンテンツを仲介し、ブラウザ２０のディスプレイウィンドウにその仲介されたデータを戻す。ソフトウェアプログラム５は、また、ターゲットウェブサーバ３０によって戻されるクッキーおよびヘッダなどのコンテンツを記録する。ウェブページ３５のコンテンツは、ユーザが異なるＵＲＬに対するリクエストを作製する場合、変更し得ることに留意されたい。さらに、ターゲットウェブサーバ３０は、リクエストが新たなウェブページに対して作製される場合、変更し得る。
【００１８】
一般的には、本発明は、サーバの仲介を必要とする全てのやりとりキャプチャし得る。ユーザが経路を規定して行なう場合、ユーザは、プロセスを規定する経路を停止し得、その経路はユーザによって規定された経路名の元で保存される。
【００１９】
図２は、ソフトウェアプログラム５がウェブページ３５によって戻されるコンテンツを仲介するプロセスを図示するフローチャートである。ＨＴＭＬおよび他のコンテンツを改変して、それにより、仲介されたコンテンツからユーザによって為された多くのやりとりまたはリクエストは、ターゲットウェブサーバ３０に直接行くよりも中間サーバ１０を介してルーティングされ得る。以下のステップは、必ずしも、示される順番で行なわれる必要が無いことに留意されたい。
【００２０】
ステップ５０において、ソフトウェアプログラム５は、ターゲットウェブサーバ３０によって戻されたウェブページ３５がキャッシュされないことを確実にする。これは、幾つかの理由で為される。ユーザがウェブを介して幾つかの経路を規定することを望む場合、第１の教示セッションにおいて、特定の仲介されたＵＲＬ（例えば、「ＵＲＬ１」）は、ウェブサイトＡに行くために使用され得、第２の教示セッションにおいて、ウェブサイトＢに行くために使用され得る。経路を規定する必要があるホストの総数を減らすために、同じ仲介ＵＲＬは、連続的に規定される経路における異なるウェブページに対して使用され得る。キャッシュを防ぐことによって、本発明は、第１の教示セッションからの任意のページが第２の教示セッションに対するユーザのコンピュータのメモリに格納されないことを確実にする。キャッシュが可能であった場合、ユーザは第２の教示セッションにおいて「ＵＲＬ１」に対するリクエストを送信するとき、ユーザは、ソフトウェアプログラム５からのウェブサイトＢの仲介されたコンテンツを受け取る代わりに、ユーザのコンピュータメモリにキャッシュされたウェブサイトＡの仲介されたコンテンツを受け取る。キャッシュを防ぐことは、また、ブラウザ２０とターゲットウェブサーバ３０との間の全てのやりとりが中間サーバ１０を介して処理されることを確実にするように利用される。ウェブページ３５をユーザのコンピュータにおいてキャッシュする場合、あたらなウェブページ３５に対する後続のリクエストは、中間サーバ１０を介して行なわれるよりも、ユーザのコンピュータにおいて処理される。これが起こる場合、ソフトウェアプログラム５は、そのウェブページにおいてユーザのやりとり（すなわち、ブラウザ２０とターゲットウェブサーバ３０との間の情報）を適切に追跡することはできない。
【００２１】
一実施形態において、ソフトウェアプログラム５は、ＭＥＴＡタグのうち「ＨＴＴＰ−ＥＱＵＩＶ＝「ｅｘｐｉｒｅｓ．．．．」」または対応する期限コーディングを有するＭＥＴＡタグを除去する。その後、ソフトウェアプログラム５は、当該ページを期限切れにさせるＭＥＴＡタグを挿入することにより、キャッシングを防止する。当業者であれば、上記の例は、ウェブページを即座に期限切れにさせるための多くの方法の一例に過ぎないことを容易に理解する。他の実施形態を挙げると、キャッシュ制御ヘッダを仲介する方法などがある。
【００２２】
工程６０の後、ソフトウェアプログラム５は、中間サーバ１０を指定するウェブページ３５中のリンクを変更することができる。この工程は、ＵＲＬリンクが絶対ＵＲＬリンクまたは相対ＵＲＬリンクのどちらであっても行うことが可能である。「絶対」ＵＲＬとは、プロトコルと、ホストとポートとを含むＵＲＬのことを指す。例えば、「ｈｔｔｐ；／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ：８０／」という名称のＵＲＬの場合、ｈｔｔｐはプロトコルであり、ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍはホスト名であり、８０はポートである。ＵＲＬ中にポートが含まれていない場合、デフォルトのポートが選択される（例えば、ｈｔｔｐの場合８０、ｈｔｔｔｐｓの場合４４３）。「相対」ＵＲＬとは、ＨＴＭＬを含むディレクトリに相対するＵＲＬのことを指す。例えば、ベースＵＲＬがｈｔｔｐ；／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／であるウェブページ中のリンクが／ｉｍａｇｅｓ／ｔｅｓｔ．ｇｉｆにリンク付けされた場合、当該リンクはｈｔｔｐ；／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｉｍａｇｅｓ／ｔｅｓｔ．ｇｉｆにリンク付けされた状態と同じ状態になる。ｉｍａｇｅｓ／ｔｅｓｔ．ｇｉｆはベースＵＲＬｈｔｔｐ；／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍに相対するため、当該リンクは実際にはベースＵＲＬを参照せず、ウェブページのコンテンツ中に現れるのは「ｉｍａｇｅｓ／ｔｅｓｔ．ｇｉｆ」のみである。
【００２３】
絶対ＵＲＬの場合、ソフトウェアプログラム５は、ターゲットウェブサーバ３０の名称を、特殊識別子に後続する仲介ＵＲＬのファイル部分に埋め込む。ユーザが仲介ＵＲＬをリクエストするコマンドを送信すると、ソフトウェアプログラム５がターゲットウェブサーバ３０の名称をロケートできるように、この特殊識別子を用いる。例えば、＜ＡＨＲＥＦ＝「ｈｔｔｐ：／／ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕ」＞ＵＴ＜／Ａ＞という絶対ＵＲＬに対するリンクに関するＨＴＭＬは、＜ＡＨＲＥＦ＝「ｈｔｔｐ：／／ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍ／ｃｏｍｐａｎｙ^≠ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕ」＞ＵＴ＜／Ａ＞となり得る。この場合、ターゲットウェブサーバｗｗｗ．ｕｔｅｘａｓ．ｅｄｕに関するリクエストは、中間サーバ１０にある「ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍ」というホストを介して経路設定される。「ｐａｔｈ１．ｓｅｒｖｅｒ．ｃｏｍ」というホストを用いて、ウェブページ３５と関連付けられた特定のターゲットウェブサーバ３０を規定することができる。「ｃｏｍｐａｎｙ^≠」とは、ソフトウェアプログラム５がファイル名中からｗｗｗ．ｕｔｅｘａｓ．ｅｄｕというターゲットサーバをロケートすることを可能にする特殊なインジケータである。次いで、ソフトウェアプログラム５は、ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕというターゲットサーバに関するユーザリクエストを当該ターゲットウェブサーバに転送することができる。ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕというターゲットウェブサーバ（例えば、この特定のリクエストに関するターゲットウェブサーバ３０）は、前回のユーザリクエストに関するターゲットウェブサーバ３０と異なり得る点に留意されたい。
【００２４】
絶対ＵＲＬはｈｔｔｐプロトコルまたはｈｔｔｐｓプロトコルによって識別されるため、ソフトウェアプログラム５は、「ｈｔｔｐ：／／」または「ｈｔｔｐｓ：／／」に関するコンテンツをサーチすることにより、ウェブページ３５のコンテンツ中の絶対ＵＲＬを識別することができる。その結果、絶対ＵＲＬを識別する際に特定の種類のｈｔｍｌタグ（例えば、Ａタグ）に関するコンテンツをサーチするシステムよりも優れたシステムが得られる。なぜならば、Ｊａｖａ（Ｒ）ｓｃｒｉｐｔ、Ｖｉｓｕａｌ Ｂａｓｉｃまたは他のスクリプトに埋め込まれたＵＲＬを識別する際、ｈｔｍｌタグは必ずしも用いられないからである。プロトコル名によって絶対ＵＲＬを識別することにより、ソフトウェアプログラム５は、ＵＲＬがＪａｖａ（登録商標）ｓｃｒｉｐｔによって動的に生成された場合にも、当該ＵＲＬを仲介することができる。従って、本発明は、実質的により多数のウェブページ中の絶対ＵＲＬを識別および仲介することができる。
【００２５】
ソフトウェアプログラム５は、ウェブページ３５のコンテンツ中に返送された相対ＵＲＬを変更して、中間サーバ１０を参照することもできる。相対ＵＲＬの場合、ソフトウェアプログラム５は、ウェブページ３５のコンテンツにおいて発見された相対ＵＲＬに対してベースタグを変更または追加する。例えば、ｉｎｄｅｘ．ｈｔｍｌがｈｔｔｐ：／／ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕにおいて発見されたウェブページ３５に相対するリンクであった場合、ベースタグを挿入して、＜ＢＡＳＥ ＨＲＥＦ＝ｈｔｔｐ：／／ｗｗｗ．ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ＞と読まれるようにすることができる。ホスト名（例えば、ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍ）は、ソフトウェアプログラム５がウェブページ３５に関する特定のターゲットウェブサーバ３０を規定する際にソフトウェアプログラム５によって用いられる。この例において、ターゲットウェブサーバ３０に／ｉｎｄｅｘ．ｈｔｍｌが配置されると、ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍは、ｈｔｔｐ：／／ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕをターゲットウェブサーバ３０として規定する。その結果、ベースタグを挿入または変更することにより、相対ＵＲＬは中間サーバ１０と相対関係を持つ。
【００２６】
ソフトウェアプログラム５は、ターゲットウェブサーバ３０を規定する際、ホストに加えてポートも用いることができる。上記の例において、ソフトウェアプログラム５は、ターゲットウェブサーバｗｗｗ．ｕｔｅｘａｓ．ｅｄｕを識別する際、ｓｅｒｖｅｒ．ｃｏｍ：５００１を用いた可能性がある。相対ＵＲＬの場合、例えば、ソフトウェアプログラム５はベースタグを挿入して、＜ＢＡＳＥ ＨＲＥＦ＝ｈｔｔｐ：／／ｓｅｒｖｅｒ．ｃｏｍ：５００１／ｉｎｄｅｘ．ｈｔｍｌ＞と読まれるＵＲＬにし得る。ターゲットウェブサーバ３０を規定する際にポートを用いると、ホストを用いるよりも有利である。なぜならば、ホストを用いるのはより困難性が高く、構成の際もコストがより高くつくからである。ブラウザ２０が中間サーバ１０を発見する際に用いるドメイン名サービス（ＤＮＳ）は、ターゲットウェブサーバを識別する際に用いられる各ホスト名に関するエントリを持っていなければならない。そのため、ｗｗｗ．ｕｔｅｘａｓ．ｅｄｕがｗｗｗ．ｓｉｔｅ１．ｓｅｒｖｅｒ．ｃｏｍというホストによって識別され、ｗｗｗ．ｙａｈｏｏ．ｃｏｍがｗｗｗ．ｓｉｔｅ２．ｓｅｒｖｅｒ．ｃｏｍというホストによって識別された場合、ＤＮＳは、これらの「ｓｉｔｅ１」ホストおよび「ｓｉｔｅ２」ホスト両方に関するエントリを含んでいなければならない。さらに、各ホスト名について、よりセキュアな通信を可能にするＳＳＬ証明が設けられ得る。しかし、ユーザがｈｔｔｐの場合に８０またはｈｔｔｐｓの場合に４４３以外のポートを用いることを禁止されている場合、ターゲットウェブサーバ３０を規定する際にポートを用いるのは不適切であり得る。このような事態は、ユーザがウェブページへのアクセスを会社のプロキシサーバを通じて行おうとする場合によく発生する。
【００２７】
ステップ７０で、ソフトウェアプログラム５は、適切なカテゴリー分類のためにリソースにマークを付ける。リソースは、ウェブページ３５に関する元々のリクエストから分かれた個別のリクエストでリクエストされるために問題となる。例えば、ウェブページ３５が特定のイメージを有する場合、第１のリクエストは、ウェブページ３５に関してなされ、そして、第２のリクエストは、そのイメージを埋めるためになされる。本発明は、ウェブをわたるパスを規定するシステム内で実現され得るため、ソフトウェアプログラム５は、新たなＵＲＬ（例えば、ユーザコマンド）に関するリクエストと、リソースに関するリクエストとを区別することができなければならない。ターゲットウェブサーバ３０等のウェブサーバにより返されたリソースヘッダがしばしば、間違っている（例えば、リソースヘッダは、イメージを間違ってテキストとしてマークし得る）ため、リソースは識別が困難でもある。
【００２８】
中間サーバ１０がターゲットページ３５に関するリクエストをするときに、さらなるリクエストが生成される場合、ソフトウェアプログラム５は、そのリクエストがウェブページ３５のコンテンツ内のリソースソースタグに起因するかどうかを判定する。これにより、リソースのコンテンツを判定するために、イメージヘッダに頼ることが避けられる。リソースがイメージである場合、例えば、ソフトウェアプログラム５は、リソースソースタグ「ＩＭＧ ＳＲＣ」を識別することができる。一旦リソースが識別されると、ソフトウェアプログラム５は、リソースのサフィックスに情報を付加することができるため、ブラウザ２０がリソースに関するリクエストをすると、ソフトウェアプログラム５は、そのリクエストがリソースリクエストであり、そのパス内でのさらなるステップではないことを認識する。例えば、ウェブページ３５のコンテンツが、ソフトウェアプログラム５に、リソース「ｄｏｗｅｒｔｘ．ｇｉｆ」をリクエストさせる場合、ソフトウェアプログラム５は、ウェブページ３５のコンテンツ内のイメージリソースタグを探し得る。例えば、ウェブページ３５のコンテンツ内のＨＴＭＬは、＜ＩＭＧ ＳＲＣ＝”／ｇｒａｐｈｉｃｓ／ｄｏｗｅｒｔｘ．ｇｉｆ”ｂｏｒｄｅｒ＝０ ａｌｔ＝”Ｔｅｘａｓ”＞を含み得る。このリソースソースタグの位置を確認した後、ソフトウェアプログラム５は、ＨＴＭＬが＜ＩＭＧ ＳＲＣ＝”／ｇｒａｐｈｉｃｓ／ｄｏｗｅｒｔｘ．ｇｉｆｍｇｔ５４ｗｉ”ＢＯＲＤＥＲ＝０ ＡＬＴ＝”Ｔｅｘａｓ”＞となるように仲介し得る。ウェブページ３５の仲介されたコンテンツが、中間サーバ１０からブラウザ２０へと伝達されると、ブラウザ２０は、イメージリソースタグによって、「ｄｏｗｅｒｔｘ．ｇｉｆｔ５４ｗｉ」に関するリクエストをする。このイメージには「ｍｇｔ５４ｗｉ」のマークが付けられているため、ターゲットウェブサーバ３０が返したリソースヘッダ内に示されていることに関係なく、ソフトウェアプログラム５は、ブラウザ２０がリソースリクエストをしており、ユーザがパス内でさらなるステップを規定しようとしていないことを認識する。実際に用いられるマーカーは変わり得るが、それが、ウェブページ内で通常起こり得ないようなものであることが理解されるべきである。ブラウザ２０がリソースリクエストをしていることの認識に加えて、ソフトウェアプログラム５は、そのリソースリクエストに応答して返されたコンテンツを仲介する必要がないことを認識する。当業者には、前述のステップが、スタイルシートおよびスクリプト等の任意の他のリソースに対して用いられ得ることが明白である。
【００２９】
ステップ８０で、ソフトウェアプログラム５は、ウェブページ３５のコンテンツ内のサポートされていないリンクをエラーメッセージと置き換える。これは、ユーザが中間サーバ１０を介してルーティングされ得ないリクエストをしないようになされ得る。例えば、共通の「ｍａｉｌｔｏ」リンクは、ブラウザ２０にｅメールプログラムを起動させる。このｅメールプログラムは、ブラウザ２０で開き、ｅメールはメールサーバを介して送信されるため、ソフトウェアプログラム５は、ｅメールプログラム内のユーザのコマンドを記録することができない。それゆえ、例えば、ソフトウェアプログラム５は、ｍａｉｌｔｏ：ｔｅｓｔ＠ｆｏｏ．ｃｏｍのリンクを、「ｊａｖａ（登録商標）ｓｃｒｉｐｔ：ａｌｅｒｔ」（サポートされていないプロトコル）と置き換え得る。ユーザが、パスを規定するときに、この「ｍａｉｌｔｏ」リンクをクリックすると、次に、エラーが現われる。
【００３０】
一般に、サポートされていないリンクは、中間サーバ１０とのさらなる対話を必要としないリンク（例えば、「ｍａｉｌｔｏ」リンク）を含む。しかしながら、本発明の１つの実施形態では、リンクがｆｔｐ等の１つまたは複数の非ＨＴＴＰのプロトコルの使用を必要とする場合、ソフトウェアプログラム５はまた、エラーメッセージを返すようにリンクを仲介し得る。当業者は、本発明が種々のプロトコルを仲介するために用いられ得ることを理解するが、特定のプロトコルがサポートされないようにソフトウェアプログラム５を構成することを選択し得る。
【００３１】
ステップ９０で、ソフトウェアプログラム５は、中間サーバ１０のドメインを参照するために、ｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎスクリプトコマンドを変更する。ウェブページ３５の異なるフレーム内に表示されるウェブページが、スクリプトを介して相互に連絡するために、異なるウェブページは、同じドメイン内になければならない。さらに、ドメインは、ウェブページ３５のＵＲＬの一部でなければならない。ユーザコマンドは、実際には、中間サーバ１０を介してルーティングされるため、ソフトウェアプログラム５は、フレーム化されたウェブページが、一旦仲介されると、適切に対話するように、フレーム化されたウェブページのｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎスクリプトコマンドを変更しなければならない。例えば、ウェブページ３５のｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎが元々「ｕｔｅｘａｓ．ｅｄｕ」に設定されているが、中間サーバ１０のドメインが「ｓｅｒｖｅｒ．ｃｏｍ」である場合、ｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎスクリプトコマンドは、「ｓｅｒｖｅｒ．ｃｏｍ」に変更される。一例として、ソフトウェアプログラム５は、ウェブページ３５により返されたＨＴＭＬコンテンツを、＜ＳＣＲＩＰＴＬＡＮＧＵＡＧＥ＝Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ＞ｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎ＝”ｕｔｅｘａｓ．ｅｄｕ”；＜／ＳＣＲＩＰＴ＞から、＜ＳＣＲＩＰＴＬＡＮＧＵＡＧＥ＝Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ＞ｄｏｍａｉｎＤｉｓａｂｌｅ＝”ｕｔｅｘａｓ．ｅｄｕ”；ｄｏｃｕｍｅｎｔ．ｄｏｍａｉｎ＝”ｓｅｒｖｅｒ．ｃｏｍ”；＜／ＳＣＲＩＰＴ＞へと変更し得る。
【００３２】
ソフトウェアプログラム５はまた、後に、ユーザのパスが繰り返されたときに、中間サーバ１０が適切なクッキーをウェブページ３５に転送することができるように、クッキーを仲介することもできる。ステップ１００で、ソフトウェアプログラム５は、ウェブページ３５のコンテンツとともに送信されたクッキーの作成の詳細とともに、任意のクッキーをｈｔｔｐヘッダ内に保存することができる。ソフトウェアプログラム５は、この情報をデータベース１５内に保存する。クッキーは、一般に、ウェブページ３５がユーザのコンピュータに記憶することを要望する、日付等の特定の情報のセットを含む。さらに、クッキーは、クッキーの有効期間、クッキーが安全であるか否か、およびクッキーがどのウェブページに対して有効であるかを含み得る。ユーザが後にリクエストをするときには常に、ブラウザ２０は、そのクッキーを送信すべきであるかどうかを判定する。クッキーを送信すべき場合、ブラウザ２０は、そのクッキー内に記憶された特定の情報のセット、例えば、日付、を送信するが、作成の詳細、クッキーの有効期間、またはクッキーの有効性は送信されない。ウェブページ３５に関するターゲットウェブサーバ３０への実際のリクエストは、中間サーバー１０から送信されるため、中間サーバ１０は、特定のクッキーがウェブページ３５に送信さるべきかどうかを判定することができなければならない。
【００３３】
クッキーをウェブページ３５によってブラウザ２０中に設定し得る少なくとも２つの基本的な方法がある。第１の方法において、ターゲットウェブサーバ３０は、ｈｔｔｐ−応答ヘッダに入れてクッキーおよびそのクッキーの生成の詳細を送信する。この場合、ソフトウェアプログラム５は、直接ヘッダからクッキーおよび生成の詳細を取り込み得る。ユーザがウェブページ３５に対して中間サーバ１０を介してさらなるリクエストをする場合、ソフトウェアプログラム５は、クッキーがそのようなウェブページ３５に対するさらなるリクエストに含まれるべきかどうかをチェックし得る。第２の方法は、クッキーをＪａｖａ（登録商標）Ｓｃｒｉｐｔを使用して設定することである。例えば、ウェブページ３５中に埋め込まれたスクリプトは以下のようなものであり得る。
【００３４】
【数１】

上記の例において、まずウェブページ３５がユーザによって３月３日にロードされたならば、クッキーはこの事実を記録する。さらに、クッキーは１日で期限切れとなるように設定され得る。ユーザがウェブページに対してさらなるリクエストをしたならば、ブラウザ２０は、「受信した（ｖｉｓｉｔｅｄ）」クッキーが返信されるべきかどうかを決定する。クッキーが返信されるべきであるならば、ブラウザ２０は「３月３日」を単に返信する。しかし、中間サーバ１０はターゲットウェブサーバ３０に対してウェブページ３５の内容を実際にリクエストするので、ソフトウェアプログラム５はクッキーが返信されるべきかどうかを決定し得なければならない。受信したデータおよび期限がここでブラウザ２０上に設定されるので、ブラウザ２０はこの情報を各リクエストとともには送信しない。したがって、ソフトウェアプログラム５はスクリプトのｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ行中に含まれる受信データおよび期限情報を取り込み得なければならない。さらに、ソフトウェアプログラム５は、１）クッキーがソフトウェアプログラム５によって使用され得る他のクッキーと違い得ること、および２）クッキーはそのドメインが中間サーバ１０のドメインと一致するので送信されることを確実にするべきである。これらの目標を達成するために、ソフトウェアプログラム５はＪａｐａＳｃｒｉｐｔを仲介して２つのクッキーを設定し得る。仲介されたＪａｐａＳｃｒｉｐｔは以下の形態を取り得る。
【００３５】
【数２】

元のスクリプト中のｄｏｃｕｍｅｎｔ．ｃｏｏｋｉｅ行は、直接設定されるのではなくむしろ可変であり、ＳｅｒｖｅｒＣｏｏｋｉｅに対して変更された。ＳｅｒｖｅｒＳｅｔＣｏｏｋｉｅ機能を使用して、ウェブページ３５が設定を所望するクッキー、およびクッキーウェブページ３５に対するすべての生成の詳細（期限日、クッキーが利用可能であるべきのページ、など）を含む第２のクッキーの両方を設定し得る。再度、３月３日にウェブページ３５をリクエストしたユーザの例を使用し、仲介の前にブラウザ２０は「３月３日」を送信する。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔがソフトウェアプログラム５によって仲介された後、ブラウザ２０はクッキーの生成の詳細とともに「３月３日」を返信する。生成の詳細が含まれるので、ソフトウェアプログラム５はクッキーをウェブページ３５に送信するべきかどうかを知る。ソフトウェアプログラム５は、クッキーを送信するために使用した文字列、および現在日をデータベース１５に保存する。現在日および生成の詳細を知ることによって、ソフトウェアプログラム５は、ユーザのパスが後にリプレイされる場合にクッキーを送信するための適切な時間範囲を決定し得る。例えば、現在日が１０月１７日ならば、ソフトウェアプログラム５は、「１０月１７日」をウェブページ３５に送信し、そしてクッキーが３月４日ではなく１０月１８日に期限切れとなるようにクッキーを変更し得る。
【００３６】
ソフトウェアプログラム５はまた、ＩＩＳなどのウェブサーバ中のフォーム「ＧＥＴ」提出を表現するために使用され得る文字数についての制限を回避し得る。ウェブページ３５がフォームＧＥＴ提出を含むならば、ソフトウェアプログラム５はステップ１１０でフォーム「ＧＥＴ」をフォーム「ＰＯＳＴ」提出に変更し得る。なぜなら、ＰＯＳＴは文字数制限がないからである。ソフトウェアプログラム５はまた、どのフォーム提出がフォーム「ＧＥＴ」からフォーム「ＰＯＳＴ」へ変更されたかをマークし、ユーザのパスがリプレイされる場合に、マークされたフォーム提出がフォーム「ＰＯＳＴ」からフォーム「ＧＥＴ」に戻るよう変更され得る。このマーキングはステップ７０におけるマーキングと同じ方法で行われ得る。
【００３７】
ステップ１２０では、ソフトウェアプログラム５は、ロケーション応答ヘッダ（ＵＲＬを参照する）を仲介してブラウザ２０をターゲットウェブサーバ３０ではなく中間サーバ１０へリダイレクトする。これは、特定のウェブサイトがブラウザ２０を別のウェブサイトにリダイレクトする場合に、ブラウザ２０が代わりに中間サーバ１０にリダイレクトされ得るように行われ得る。仲介は、ステップ６０での方法と同じ方法で行われ得る。
【００３８】
ステップ５０〜１２０のすべてまたはある部分集合を行った後、ソフトウェアプログラム５はティーチングセッションを終了し得る。これは、ユーザがティーチングセッションを終了したことを（例えば、「ティーチング終了」ボタンをクリックすることによって）ユーザが示す場合、またはユーザが所定数のリクエストを行った場合に行われ得る。ティーチングプロセス全体をとおして、ソフトウェアプログラム５はデータベース１５でリクエストヒストリを集計した。リクエストヒストリは、保存されたＵＲＬリクエスト、ならびにクッキー、ヘッダおよびフォームパラメータなどの対応するデータを含む。このリクエストヒストリを後に使用して、動的および静的ウェブページの両方を介してユーザのパスをリプレイし得る。
【００３９】
本発明を詳細に記載したが、添付の請求の範囲に記載されるような本発明の精神および範囲から逸脱せずに種々の変更、置換および改変が本発明に対してなされ得ることが理解されるべきである。
【図面の簡単な説明】
【図１】 図１は、本発明がインプリメントされ得るあるシステムを図示したものである。
【図２】 図２は、中間サーバにおいてウェブページを仲介するための本発明の方法を図示するフローチャートを示す。

Claims (32)

1. ウェブページを仲介する方法であって、該方法は、中間サーバにおいてプロセッサによって実行され、該方法は、
   ウェブページに対するリクエストをユーザ経路の第１の部分として記録することと、
   ターゲットウェブサーバから該ウェブページを取り出すことと、
   該ウェブページを修正して該ウェブページがキャッシュされないことを確実にすることと、
   プロトコルに従って該ウェブページ内の絶対ＵＲＬを識別することと、
   該絶対ＵＲＬが該中間サーバを指し示すように該絶対ＵＲＬを変更することと、
   該ウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
   リソースマーキングを伴う該リソースへのリンクを仲介することであって、該リソースマーキングは、該リソースマーキングを含む後のリソースリクエストに応答して返されるリソースが仲介されるべきではないことを示す、ことと、
   該リソースに対する後のリソースリクエストを受信することと、
   該リソースを取り出し、該後のリソースリクエストを該ユーザ経路の一部として記録することなく該リソースをウェブブラウザに返すことと
   を含む、方法。
2. 相対ＵＲＬが前記中間サーバを指し示すように、前記ウェブページ内の該相対ＵＲＬを変更することをさらに含む、請求項１に記載の方法。
3. 前記プロセッサが、クッキーに関連する１組の作成情報を保存することをさらに含む、請求項１に記載の方法。
4. 前記ウェブページを修正して該ウェブページがキャッシュされないことを確実にする工程は、前記プロセッサが、該ウェブページを即座に期限切れになるように設定することを含む、請求項１に記載の方法。
5. 前記プロセッサが、相対ＵＲＬが前記中間サーバを指し示すように、前記ウェブページ内の該相対ＵＲＬを変更することをさらに含み、
   該相対ＵＲＬがベースタグを含む場合、該相対ＵＲＬが該中間サーバを指し示すように該ベースタグを修正することと、
   該相対ＵＲＬがベースタグを含まない場合、ベースタグを挿入することであって、該挿入されたベースタグにより、該相対ＵＲＬが該中間サーバを指し示す、ことと
   をさらに含む、請求項１に記載の方法。
6. ウェブページを介するユーザ経路を格納する方法であって、該方法は、中間サーバにおいてプロセッサによって実行され、該方法は、
   第１のウェブページに対するリクエストを該中間サーバにおいて受信することと、
   該リクエストをユーザ経路の第１の部分として記録することと、
   該第１のウェブページをホストしているターゲットウェブサーバからの該第１のウェブページをリクエストすることと、
   該ターゲットウェブサーバから該第１のウェブページを取り出すことと、
   該第１のウェブページを修正して該第１のウェブページがキャッシュされないことを確実にすることと、
   該第１のウェブページ内の複数のリンクの各々が該中間サーバを指し示すように該複数のリンクを変更することにより、仲介されるウェブページを作成することであって、該複数のリンクを変更することは、少なくとも１つのＵＲＬが該中間サーバを指し示すように該少なくとも１つのＵＲＬを変更することをさらに含む、ことと、
   該第１のウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
   リソースマーキングを伴う該リソースへのリンクを仲介することであって、該リソースマーキングは、該リソースマーキングを含む後のリソースリクエストに応答して返されるリソースが仲介されるべきではないことを示す、ことと、
   該仲介されるウェブページに基づく第２のウェブページに対する後のリクエストを受信することと、
   該第２のウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
   該第２のウェブページに対する後のリクエストを該ユーザ経路の第２の部分として該中間サーバにおいて記録することと、
   該リソースを取り出し、該後のリソースリクエストを該ユーザ経路の一部として記録することなく該リソースをウェブブラウザに返すことであって、該第２のウェブページをホストしているターゲットウェブサーバからの該第２のウェブページをリクエストすることを含む、ことと
   を含む、方法。
7. 前記ＵＲＬは、相対ＵＲＬであり、前記ウェブページ内の相対ＵＲＬを変更する工程は、
   該相対ＵＲＬがベースタグを含む場合、該相対ＵＲＬが前記中間サーバを指し示すように前記プロセッサが該ベースタグを修正することと、
   該相対ＵＲＬがベースタグを含まない場合、該プロセッサがベースタグを挿入することであって、該挿入されたベースタグにより、該相対ＵＲＬが該中間サーバを指し示す、ことと
   をさらに含む、請求項６に記載の方法。
8. 前記第１のウェブページを修正して該第１のウェブページがキャッシュされないことを確実にする工程は、前記プロセッサが、該ウェブページを即座に期限切れになるように設定することを含む、請求項６に記載の方法。
9. 前記ＵＲＬは、絶対ＵＲＬであり、前記プロセッサが、該絶対ＵＲＬにおいて指定されるプロトコルによって該絶対ＵＲＬを識別することをさらに含む、請求項６に記載の方法。
10. 前記ＵＲＬが前記中間サーバを指し示すようにＵＲＬを変更する工程は、ホスト名を用いて前記第１のウェブページに関連する前記ターゲットウェブサーバを規定することをさらに含む、請求項６に記載の方法。
11. 前記ＵＲＬが前記中間サーバを指し示すようにＵＲＬを変更する工程は、ポートを用いて前記第１のウェブページに関連する前記ターゲットウェブサーバを規定することをさらに含む、請求項６に記載の方法。
12. 前記プロセッサが、前記第１のウェブページ内のリソースのリソースソースタグを識別することによって該リソースのリソースタイプを識別することと、
    該プロセッサが、リソースマーキングを伴う該リソースへのリンクを仲介することであって、該リソースマーキングは、該リソースマーキングを含む後のリソースリクエストに応答して返されるリソースが仲介されるべきではないことを示す、ことと
    をさらに含む、請求項６に記載の方法。
13. 前記リソースソースタグは、リソースがイメージであることを示す、請求項１２に記載の方法。
14. 前記第１のウェブページ内の複数のリンクを変更する工程は、ドキュメントドメインスクリプトコマンドが前記中間サーバのドメインを指し示すように、前記プロセッサが、前記第１のウェブページ内の該ドキュメントドメインスクリプトコマンドを変更することをさらに含む、請求項６に記載の方法。
15. 前記プロセッサが、第１のクッキーに関連する１組の作成情報を前記中間サーバにおいて保存することをさらに含む、請求項６に記載の方法。
16. 前記１組の作成情報のソースは、ｈｔｔｐ−ヘッダである、請求項１５に記載の方法。
17. 前記プロセッサが、ブラウザに第２のクッキーを前記中間ウェブサーバへと送信させることをさらに含み、該第２のクッキーは、前記第１のクッキーに関連する前記１組の作成情報を含む、請求項１５に記載の方法。
18. 前記プロセッサが、フォーム「ＧＥＴ」提出をフォーム「ＰＯＳＴ」提出に変更することをさらに含む、請求項６に記載の方法。
19. 中間サーバにおいてウェブページを仲介するシステムであって、
    コンピュータ読み取り可能媒体と、
    該コンピュータ読み取り可能媒体に格納されたソフトウェア命令と
    を含み、該ソフトウェア命令は、
    第１のウェブページに対するリクエストを中間サーバにおいて受信することと、
    該リクエストをユーザ経路の第１の部分として記録することと、
    該第１のウェブページをホストしているターゲットウェブサーバからの該第１のウェブページをリクエストすることと、
    該ターゲットウェブサーバから該第１のウェブページを取り出すことと、
    該第１のウェブページを修正して該第１のウェブページがキャッシュされないことを確実にすることと、
    該第１のウェブページ内の複数のリンクの各々が該中間サーバを指し示すように該複数のリンクを変更することにより、仲介されるウェブページを作成することであって、該複数のリンクを変更することは、少なくとも１つのＵＲＬが該中間サーバを指し示すように該少なくとも１つのＵＲＬを変更することをさらに含む、ことと、
    該第１のウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
    リソースマーキングを伴う該リソースへのリンクを仲介することであって、該リソースマーキングは、該リソースマーキングを含む後のリソースリクエストに応答して返されるリソースが仲介されるべきではないことを示す、ことと、
    該仲介されるウェブページに基づく第２のウェブページに対する後のリクエストを受信することと、
    該第２のウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
    該第２のウェブページに対する後のリクエストを該ユーザ経路の第２の部分として該中間サーバにおいて記録することと、
    該リソースを取り出し、該後のリソースリクエストを該ユーザ経路の一部として記録することなく該リソースをウェブブラウザに返すことであって、該第２のウェブページをホストしているターゲットウェブサーバからの該第２のウェブページをリクエストすることを含む、ことと
    を行うように動作可能である、システム。
20. 前記第１のウェブページを修正して該第１のウェブページがキャッシュされないことを確実にするように動作可能なソフトウェア命令は、前記ウェブページが即座に期限切れになるようにさらに動作可能である、請求項１９に記載のシステム。
21. 前記ＵＲＬは相対ＵＲＬであり、前記ソフトウェア命令は、
    該相対ＵＲＬがベースタグを含む場合、該相対ＵＲＬが前記中間サーバを指し示すように該ベースタグを修正することと、
    該相対ＵＲＬがベースタグを含まない場合、ベースタグを挿入することであって、該挿入されたベースタグにより、該相対ＵＲＬが該中間サーバを指し示す、ことと
    を行うようにさらに動作可能である、請求項１９に記載のシステム。
22. 前記ソフトウェア命令は、ホスト名を用いて前記第１のウェブページに関連する前記ターゲットウェブサーバを規定するようにさらに動作可能である、請求項１９に記載のシステム。
23. 前記ソフトウェア命令は、ポートを用いて前記第１のウェブページに関連する前記ターゲットウェブサーバを規定するようにさらに動作可能である、請求項１９に記載のシステム。
24. 前記ＵＲＬは絶対ＵＲＬであり、前記ソフトウェア命令は、プロトコルによって該絶対ＵＲＬを識別するようにさらに動作可能である、請求項１９に記載のシステム。
25. 前記第１のウェブページ内の複数のリンクを変更するように動作可能であるソフトウェア命令は、ドキュメントドメインスクリプトコマンドが前記中間サーバのドメインを指し示すように前記ウェブページ内の該ドキュメントドメインスクリプトコマンドを変更するようにさらに動作可能である、請求項１９に記載のシステム。
26. 前記ソフトウェア命令は、第１のクッキーに関連する１組の作成情報を保存するようにさらに動作可能である、請求項１９に記載のシステム。
27. 前記ソフトウェア命令は、ｈｔｔｐ−ヘッダから前記１組の作成情報を保存するようにさらに動作可能である、請求項２６に記載のシステム。
28. 前記ソフトウェア命令は、ブラウザに第２のクッキーを前記中間ウェブサーバへと送信させるようにさらに動作可能であり、該第２のクッキーは、前記第１のクッキーに関連する前記１組の作成情報を含む、請求項２６に記載のシステム。
29. 前記ソフトウェア命令は、フォーム「ＧＥＴ」提出をフォーム「ＰＯＳＴ」提出に変更するようにさらに動作可能である、請求項１９に記載のシステム。
30. ウェブページを仲介する方法であって、該方法は、
    中間サーバにおけるプロセッサが、
    ユーザデバイス上のブラウザからウェブページリクエストを受信することと、
    該ウェブページリクエストをユーザ経路の一部として記録することと、
    該ウェブページリクエストをターゲットウェブサーバに転送することと、
    該ターゲットウェブサーバから該ウェブページを受信することと、
    サポートされたリンクが該中間サーバを指し示すように該ウェブページ内の該サポートされたリンクを変更することにより、仲介されるコンテンツを作成することであって、該サポートされたリンクを変更することは、
    該ウェブページ内のリソースのリソースソースタグを識別することによって、該リソースのリソースタイプを識別することと、
    リソースマーキングを伴う該リソースへのリンクを仲介することであって、該リソースマーキングは、該リソースマーキングを含む後のリソースリクエストに応答して返されるリソースが仲介されるべきではないことを示す、ことと
    をさらに含む、ことと、
    該仲介されるコンテンツを該ブラウザに転送することであって、該仲介されるコンテンツは該リソースマーキングを含む、ことと、
    該リソースに対する該ブラウザからの該後のリソースリクエストを受信することと、
    該リソースを取り出し、該後のリソースリクエストを該ユーザ経路の一部として記録することなく該リソースを該ウェブブラウザに返すことと
    を行うことと、
    該ユーザデバイスにおけるプロセッサが、該仲介されるコンテンツに基づいて、該リソースマーキングを含む該リソースリクエストを生成することと
    を含む、方法。
31. 前記中間サーバにおけるプロセッサが、前記リソースマーキングに基づいて、前記リソースリクエストを新しいウェブページリクエストと区別することをさらに含む、請求項３０に記載の方法。
32. 前記中間サーバにおけるプロセッサが、
    第１のクッキーに関連する作成情報を記録することと、
    前記ブラウザに、該第１のクッキーに関連する作成情報を含む第２のクッキーを該中間サーバに送信させることと
    を行うことと、
    前記ユーザデバイスにおけるプロセッサが、
    該第１のクッキーに関連する作成情報を含む該第２のクッキーを生成することと、
    該第２のクッキーを該中間サーバに送信することと
    を行うことと
    をさらに含む、請求項３０に記載の方法。

Images