JP2008518538A

JP2008518538A - Ｈｔｔｐリダイレクトリクエストをインターセプトする方法並びに前記方法を実行するためのシステム及びサーバー機器

Info

Publication number: JP2008518538A
Application number: JP2007538482A
Authority: JP
Inventors: アンヌ・ブトルー; ニコラ・セラール; エティエンヌ・アニーク
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2004-10-27
Filing date: 2005-10-25
Publication date: 2008-05-29
Also published as: EP1810483A1; WO2006045983A1; US20080195696A1

Abstract

本発明に係るリダイレクトリクエストインターセプト方法は、ユーザー端末に送信されたＨＴＴＰレスポンスを受信する段階（Ｅ１０）と、当該レスポンスに含まれるリダイレクトアドレスを取得する段階（Ｅ３０）と、代替リクエストを生成する段階（Ｅ４０）及び当該リダイレクトアドレス宛に送信する段階（Ｅ５０）と、当該代替リクエストに対するレスポンスを受信する段階（Ｅ６０）と、当該レスポンスを、前記ユーザー端末に送信する段階（Ｅ７０）とを具備する。

Description

本発明は、インターネットタイプのネットワーク上のサービスへのアクセスを改善する方法及びシステム一般に関する。

より正確には、本発明は、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）のＲＦＣ（ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔｓ）２６１６で説明されているリダイレクト機構を改善することを目的とする。当該リダイレクト機構は、当業者には公知であるが、次のように、第２ＨＴＭＬページのＵＲＬアドレスを、第１ＨＴＭＬページのｍｅｔａタグ内に含めることにより、前記第１ＨＴＭＬページを捜すユーザーを、前記第２ＨＴＭＬページへとリダイレクトする機構である。

＜ｍｅｔａｈｔｔｐ−ｅｑｕｉｖ＝ “ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝ “０；ｕｒｌ＝ｈｔｔｐ：／／ｒｅｄｉｒｅｃｔｉｏｎｐａｇｅ／”＞

前記リダイレクト機構は、特に、制限されたビットレートを提供する移動通信ネットワーク内において使用されると、深刻な欠点が顕になる。なぜなら、要求されたページを参照するために必要な使用可能ビットレートが、リダイレクトにより発生する通信量によって加重されるからである。

これらの往復通信は、通信量に重大な影響を及ぼすことに留意する必要がある。ビジネス用ネットワークに関して行われた統計的な研究により、リダイレクトは、text/HTMLタイプのリクエストの１０％以上を占めることが示唆されている。

本発明は、インターネットネットワーク上のサーバーにより、移動体装置に対して送信されるリダイレクトをバイパスして、ユーザーによって体感される遅延を低減することにより、この欠点を除去することを目的とする。

前記目的のために、本発明の第１構成においては、インターネットタイプのネットワーク内で使用可能であるＨＴＴＰリクエスト及びＨＴＴＰレスポンスを修正するためのサーバーを設ける。前記サーバーは、
ユーザー端末に送信されたＨＴＴＰレスポンス内に含まれるリダイレクトリクエストを受信する手段と、
前記ＨＴＴＰレスポンス内に含まれるリダイレクトアドレスを取得する手段と、
前記ユーザー端末に関する情報から代替リクエストを生成する手段と、
前記リダイレクトアドレス宛に前記代替リクエストを送信する手段と、
前記代替リクエストに対する応答を受信する手段と、
前記代替リクエストに対する応答を、前記ユーザー端末に送信する手段とを具備する。

以下の説明においては、簡潔を旨とするために、リクエスト及びレスポンスを修正する前記サーバーは、「修正サーバー」という。

本発明によると、前記修正サーバーは、普通に前記ユーザー端末に宛てられたリダイレクトリクエストを受信するとともに、その後前記リダイレクトアドレス上のコンテンツにアクセスし、前記コンテンツのみを前記ユーザー端末に送信する。

従って、もしユーザー端末が移動体装置であるならば、有用なコンテンツ、即ち、ユーザーが捜しているコンテンツのみが、遠距離通信ネットワークを介して送信される。

本発明による修正サーバーの好ましい実施形態では、さらに、前記ＨＴＴＰリクエスト・レスポンス修正プロトコルを実施するように構成されたクライアントを有するプロキシサーバーからクライアント端末に関連する情報を取得する手段を具備する。

前記好ましい実施形態では、クライアント端末に関連する情報は、プロキシサーバーによって、直接的又は間接的に収集され、前記修正サーバーは、上述の前記リクエストリダイレクトサービスを管理することに専念できるのが好ましい。

本発明の第２構成は、インターネットタイプのネットワーク内のユーザー端末に送信されるＨＴＴＰレスポンス内に含まれるリダイレクトリクエストをインターセプトするシステムを目的とする。前記システムは、
上記で言及されたＨＴＴＰリクエスト及び修正サーバーと、
ＨＴＴＰプロトコルを実施する手段を有するプロキシサーバーと、
ＨＴＴＰリクエスト・レスポンス修正プロトコルを実施し、リダイレクトリクエストを前記修正サーバーに送信するように構成されたクライアントとを具備する。

前記プロキシサーバーは、好ましくは、前記ユーザー端末が、リダイレクトリクエストインターセプトサービスに加入することを記録する手段を具備する。そして、プロキシサーバークライアントは、前記リダイレクトリクエストを前記修正サーバーに送信する前に、前記ユーザー端末が当該サービスに加入しているかどうか検査する。

第１実施形態において、ユーザーの加入を記録する手段は、当該ユーザーに関する情報を、例えば加入端末用質問表の形式で、直接取得するように構成される。

他の実施形態では、プロキシサーバーは、前記プロキシサーバーを通過するＨＴＴＰ通信を解析することにより、ユーザー端末に関する情報を取得する。

本発明と相互関係のある第３構成は、インターネットタイプのネットワーク内でユーザー端末に送信されるＨＴＴＰレスポンスに含まれるリダイレクトリクエストをインターセプトする方法を目的とする。前記方法は、ＨＴＴＰリクエスト・レスポンス修正サーバーによって実施されるように構成され、
ＨＴＴＰレスポンスを受信する段階と、
前記ＨＴＴＰレスポンスに含まれるリダイレクトアドレスを取得する段階と、
前記ユーザー端末に関連する情報から代替リクエストを生成する段階と、
前記代替リクエストを、前記リダイレクトアドレス宛に送信する段階と、
前記代替リクエストに対するレスポンスを受信する段階と、
前記代替リクエストへの前記レスポンスを前記ユーザー端末に送信する段階とを具備する。

前記インターセプトによる方法に固有の利点は、すでに導入された修正サーバーに係るものと同一であるが、ここではそれらについて繰り返し説明しない。

本発明の他の構成及び利点は、非限定的な実施例のみを用いて、かつ添付図面を参照しながら与えられる特定の実施形態に関する後述の説明を読むことによって、より一層明白になる。

図１は、インターネットタイプのネットワーク５内で、リダイレクトリクエストをインターセプトするシステムの好ましい実施態様を表している。

前記システムは、インターネットブラウザ１５を備えるユーザー端末１０を具備するとともに、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を実施するよう構成されたプロキシサーバー２０を経由して、インターネットタイプのネットワーク５に接続される。

ここで説明される好ましい実施形態において、プロキシサーバー２０は、ユーザー端末１０がネットワーク５にアクセスするために接続しなければならないサービスプロバイダー２５によって管理される。

サービスプロバイダー２５は、また、例えば識別子（ログイン）及びパスワードに基づいて、端末１０のユーザーを認証し、かつ前記端末がインターネットタイプのネットワーク５内を行き来できるように、インターネットプロトコル（ＩＰ）アドレスを供給する、アクセス制御サーバー３０を具備する。

一度ＩＰアドレスが割り当てされれば、ネットワーク５にアクセスするための全てのＨＴＴＰリクエストと、ユーザー端末１０によって送受信されるＨＴＴＰレスポンスとは、送信中に、プロキシサーバー２０を通過する。

ここで説明される好ましい実施態様では、プロキシサーバー２０は、ユーザー端末１０のユーザーがリダイレクトリクエストインターセプトサービスに加入することを記録する手段を具備する。

前記加入が申請されたときに、プロキシサーバー２０は、ユーザー端末１０に関連する情報（ＩＰアドレス、セッションクッキー等）を収集するとともに格納する。

代わりに、ＨＴＴＰを実施するように構成されたプロキシサーバー２０は、ＨＴＴＰ通信を解析して、ユーザー端末１０に関連する固有の情報を直接取得してもよい。

アクセスシステムは、また、ネットワーク５に接続されたサービスプロバイダー４５を具備し、プロキシサーバー２０によってリクエストＭ２の形式でフォワードされたアクセスリクエストＭ１に応答して、端末１０のユーザーにサービスを提供する。

以下では、サービスプロバイダー４５は、ユーザー端末１０に、リダイレクトリクエストを含むＨＴＴＰレスポンスＭ３を送信することにより、リクエストＭ２に応答することを前提とする。

当業者間で公知であるように、このＨＴＴＰレスポンスＭ３は、ユーザー端末１０のインターネットプロトコル（ＩＰ）アドレスを含んでいる。

本発明によるシステムは、インターネットタイプのネットワーク５に接続されるとともに、ＨＴＴＰリクエスト及びレスポンスの修正を可能にするプロトコルを実施するように構成される「リクエスト修正サーバー」５０を具備する。

ここで説明される好ましい実施形態では、リクエスト修正サーバー５０は、ユーザー端末１０に関する情報をプロキシサーバー２０から取得する手段を具備する。前記情報は、例えば、当該端末のユーザーがリダイレクトリクエストインターセプトサービスに加入申請する際にプロキシサーバー２０によって取得される。

ここで説明される好ましい実施形態では、このサーバー５０は、ＩｎｔｅｒｎｅｔＣｏｎｔｅｎｔＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ（ｉＣＡＰ）を実施するように構成されたｉＣＡＰサーバーである。

本発明によると、プロキシサーバー２０は、前記リクエスト修正サーバー５０と同一のプロトコル、即ちここでは、ｉＣＡＰを実施するように構成されたクライアント５５を具備する。

第１実施形態では、プロキシサーバー２０のｉＣＡＰクライアント５５は、ｉＣＡＰサーバー５０に対し、リダイレクトリクエストインターセプトサービスに加入しているユーザー宛のリダイレクトリクエストを含むＨＴＴＰレスポンスＭ３のみを送信するように構成される。

従って、この第１実施形態では、プロキシサーバー２０がリダイレクトリクエストを含むＨＴＴＰリクエストＭ３を発見すると、前記プロキシサーバー２０は、当該レスポンスをインターセプトし、ｉＣＡＰリクエストＭ４の形式で、ｉＣＡＰを使用してｉＣＡＰサーバー５０に当該レスポンスを送信する。

第２実施形態では、プロキシサーバー２０のｉＣＡＰクライアント５５は、ｉＣＡＰサーバー５０に対し、ユーザー端末１０宛の全てのＨＴＴＰレスポンスを送信する。

この第２実施形態では、ｉＣＡＰサーバー５０は、もしＨＴＴＰレスポンスＭ３がリダイレクトリクエストを含まない場合は、プロキシサーバー２０から受信したＨＴＴＰレスポンスＭ３を、ユーザー端末１０に対し直接送信する手段を具備する。

以下では、ｉＣＡＰサーバー５０は、ｉＣＡＰリクエストＭ４の形式でＨＴＴＰレスポンスＭ３を受信することを前提とし、このＨＴＴＰレスポンスＭ３はリダイレクトリクエスト及びユーザー端末１０のＩＰアドレスを含むことを前提とする。

本発明によると、ｉＣＡＰサーバー５０は、このＨＴＴＰレスポンスＭ３からリダイレクトＵＲＬアドレスを取得するように構成される。

本発明によると、ｉＣＡＰサーバー５０は、ユーザー端末１０に関連する情報（ＩＰアドレス、セッションクッキー等）から、ＨＴＴＰ代替リクエストＭ５を次のように生成する手段を具備する。前記ＨＴＴＰ代替リクエストＭ５の内容は、サービスプロバイダー４５によって送信されたＨＴＴＰレスポンスＭ３に応答してユーザー端末１０のインターネットブラウザ１５が生成したであろうＨＴＴＰリクエストの中身と同一である。

前記ｉＣＡＰサーバー５０は、ＨＴＴＰ代替リクエストＭ５を、インターネットタイプのネットワーク５上のアドレスが、ＨＴＴＰレスポンスＭ３内で取得されたリダイレクトＵＲＬアドレスである、ＨＴＴＰサーバー３５に対して送信する手段を具備する。

ここで説明される実施形態では、このＨＴＴＰ代替リクエストＭ５は、プロキシサーバー２０によって、ＨＴＴＰリクエストＭ６の形式で中継される。

前記ｉＣＡＰサーバー５０は、ＨＴＴＰ代替リクエストＭ５に対するＨＴＴＰレスポンスＭ７を受信する手段を具備する。前記レスポンスは、ここで説明される好ましい実施形態では、プロキシサーバー２０によって、ＨＴＴＰレスポンスＭ８の形式で中継される。

本発明によると、ｉＣＡＰサーバー５０は、このＨＴＴＰレスポンスＭ８を、ユーザー端末１０（この例では、インターネットアドレス／ｒｅｄｉｒｅｃｔｉｏｎｐａｇｅ／にあるＨＴＭＬページ）に対して、ＨＴＴＰレスポンスＭ９の形式で送信する送信手段を具備し、前記ＨＴＴＰレスポンスＭ９は、プロキシサーバー２０によって、ＨＴＴＰレスポンスＭ１０の形式で中継される。

図１に記載されているインターセプトシステムの装置間における情報の流れ、より正確に、ｉＣＡＰサーバー５０によって実施されるインターセプト方法の主要な段階は、図２及び図３を参照しながら次に説明される。

まず第１に、ユーザー端末１０のユーザーは、リダイレクトリクエストインターセプトサービスに加入するとともに、ｉＣＡＰサーバー５０は、準備段階Ｅ５の間に、プロキシサーバー２０から、前記ユーザーの個人情報（ＩＰアドレス、セッションクッキー等）を取得するものとする。

同様に、ユーザー端末１０のユーザーは、サービスプロバイダー４５により提供されるサービスにアクセスすることを望んでいるとともに、前記サービスプロバイダー４５に対するアクセスリクエストＭ１が、プロキシサーバー２０によって中継され、かつその後、前記サービスプロバイダー４５にリクエストＭ２の形式で送信されることを前提とする。

最後に、サービスプロバイダー４５が、リクエストＭ２に対し、リダイレクトリクエストを含む前記ユーザー端末１０に対するＨＴＴＰレスポンスＭ３で応答することを前提とするとともに、前記ＨＴＴＰレスポンスＭ３は、プロキシサーバー２０によってインターセプトされるとともに、ｉＣＡＰリクエストＭ４の形式で、ｉＣＡＰサーバー５０に送信されることを前提とする。

第１段階Ｅ１０の間に、ｉＣＡＰサーバー５０は、ｉＣＡＰリクエストＭ４の形式で、ＨＴＴＰレスポンスＭ３を受信する。

この受信段階Ｅ１０の次に、ＨＴＴＰレスポンスＭ３がリダイレクトリクエストを含んでいるかどうかをｉＣＡＰサーバー５０が調べるテストＥ２０が続く。

もし、含んでいない場合は、テストＥ２０の結果はネガティブとなり、このテストの次に、ｉＣＡＰサーバー５０が、ユーザー端末１０にＨＴＴＰレスポンスＭ３を送信する段階Ｅ７０が続く。

反対に、もしＨＴＴＰレスポンスＭ３が、リダイレクトＵＲＬアドレスを含んでいる場合は、テストＥ２０の結果はポジティブとなる。

その後、このテストの次に、ｉＣＡＰサーバー５０がＨＴＴＰレスポンスＭ３内からリダイレクトＵＲＬアドレスを取得する段階Ｅ３０が続く。

その後、この段階Ｅ３０の次に、ｉＣＡＰサーバー５０が、あらかじめ準備段階Ｅ５の間にｉＣＡＰサーバー５０が予め取得した固有情報（ＩＰアドレス、セッションクッキー等）から、代替リクエストＭ５を生成する段階Ｅ４０が続く。

上述のように、ＨＴＴＰ代替リクエストＭ５は、ユーザー端末１０のインターネットブラウザ１５が、サービスプロバイダー４５によって送信されたＨＴＴＰレスポンスＭ３に応答して生成したであろうＨＴＴＰリクエストに類似している。

この段階Ｅ４０の次に、代替リクエストＭ５をリダイレクトＵＲＬアドレス宛に送信する段階Ｅ５０が続く。

代替リクエストＭ５を送信する段階Ｅ５０の次に、代替ＨＴＴＰリクエストＭ５に対するレスポンスＭ７を受信する段階Ｅ６０が続く。

ここで説明される実施形態では、このＨＴＴＰレスポンスＭ７は、プロキシサーバー２０によって、ＨＴＴＰレスポンスＭ８の形式で中継される。これは、実際には、プロキシサーバー２０によって中継されたＵＲＬアドレス上に位置するＨＴＭＬページである。

ＨＴＴＰレスポンスＭ８を受信する段階Ｅ６０の次に、プロキシサーバー２０によってＨＴＴＰレスポンスＭ１０の形式で中継されるＨＴＴＰレスポンスＭ９の形式で、ユーザー端末１０に、このレスポンスを送信する段階Ｅ７０が続く。

図１は、本発明の好ましい実施形態による、リダイレクトリクエストインターセプトの好ましい実施形態を表す図である。図２は、図１に記載のシステム内で使用される、リダイレクトリクエストインターセプトの主要な段階を示すフローチャートである。図３は、図１に記載のインターセプトシステム内の種々の装置間における情報の流れを表す図である。

符号の説明

５ネットワーク
１０ユーザー端末
１５インターネットブラウザ
２０プロキシサーバー
２５サービスプロバイダー
３０アクセス制御サーバー
３５ＨＴＴＰサーバー
４５サービスプロバイダー
５０ＨＴＴＰリクエスト・レスポンス修正サーバー
５５クライアント

Claims

インターネットタイプのネットワーク（５）内で使用されるＨＴＴＰリクエスト及びレスポンスを修正するサーバーにおいて、
ユーザー端末（１０）に送信されたＨＴＴＰレスポンス（Ｍ３）に含まれるリダイレクトリクエストを受信する手段と、
前記ＨＴＴＰレスポンス（Ｍ３）に含まれるリダイレクトアドレス（ＵＲＬ）を取得する手段と、
前記ユーザー端末（１０）に関連する情報から代替リクエスト（Ｍ５）を生成する手段と、
前記リダイレクトアドレス（ＵＲＬ）宛に前記代替リクエスト（Ｍ５）を送信する手段と、
前記代替リクエスト（Ｍ５）に対するレスポンス（Ｍ８）を受信する手段と、
前記代替リクエスト（Ｍ５）に対する前記レスポンス（Ｍ８）を前記ユーザー端末（１０）に送信する手段とを具備することを特徴とするサーバー。
請求項１に記載のＨＴＴＰリクエスト・レスポンス修正サーバーにおいて、
ＨＴＴＰリクエスト・レスポンス修正プロトコルを実施するように構成されたクライアントを具備するプロキシサーバー（２０）から、クライアント端末（１０）に関連する前記情報を取得する手段をさらに具備することを特徴とするサーバー。
インターネットタイプのネットワーク（５）内で、ユーザー端末（１０）に送信されたＨＴＴＰレスポンスに含まれるリダイレクトリクエストをインターセプトするシステムにおいて、
請求項１又は請求項２に記載のＨＴＴＰリクエスト・レスポンス修正サーバー（５０）と、
プロキシサーバー（２０）とを具備し、前記プロキシサーバー（２０）は、
ＨＴＴＰプロトコルを実施するための手段と、
前記ＨＴＴＰリクエスト・レスポンス修正プロトコルを実施するとともに、前記リダイレクトリクエストを前記リクエスト・レスポンス修正サーバーに送信するように構成されたクライアント（５５）とを具備することを特徴とするシステム。
請求項３に記載のインターセプトシステムにおいて、
前記ユーザー端末（１０）のリダイレクトリクエストインターセプトサービスへの加入を記録する手段を具備するプロキシサーバー（２０）と、
前記リダイレクトリクエストを、前記ＨＴＴＰリクエスト・レスポンス修正サーバーに送信する前に、前記ユーザー端末（１０）が前記サービスに加入していることを確認するように構成されたクライアント（５５）とを具備することを特徴とするシステム。
請求項４に記載のインターセプトシステムにおいて、
前記加入を記録する手段は、前記ユーザー端末（１０）に関連する情報を取得するように構成されていることを特徴とするシステム。
請求項３又は請求項４に記載のインターセプトシステムにおいて、
プロキシサーバー（２０）がＨＴＴＰプロトコルを実施する前記手段は、前記ユーザー端末（１０）に関連する情報を取得するように構成されていることを特徴とするシステム。
インターネットタイプのネットワーク（５）内でユーザー端末（１０）に送信されるＨＴＴＰレスポンス（Ｍ３）に含まれるリダイレクトリクエストをインターセプトする方法であって、ＨＴＴＰリクエスト・レスポンス修正サーバー（５０）によって実施されるように構成され、
前記ＨＴＴＰレスポンスを受信する段階（Ｅ１０）と、
前記ＨＴＴＰレスポンス（Ｍ３）内に含まれるリダイレクトアドレス（ＵＲＬ）を取得する段階（Ｅ３０）と、
前記ユーザー端末（１０）に関連する情報から、代替リクエスト（Ｍ５）を生成する段階（Ｅ４０）と、
前記リダイレクトアドレス（ＵＲＬ）宛に前記代替リクエスト（Ｍ５）を送信する段階（Ｅ５０）と、
前記代替リクエスト（Ｍ５）に対するレスポンス（Ｍ８）を受信する段階（Ｅ６０）と、
前記代替リクエスト（Ｍ５）に対する前記レスポンス（Ｍ８）を、前記ユーザー端末（１０）に送信する段階（Ｅ７０）とを具備することを特徴とする方法。
請求項７に記載のインターセプトシステムにおいて、
前記ＨＴＴＰリクエスト・レスポンス修正プロトコルを実施するように構成されたクライアント（５５）を具備するプロキシサーバー（２０）から、クライアント端末（１０）に関連する前記情報を取得する準備段階（Ｅ５）を具備することを特徴とするシステム。